Management device, management method, and program

Abstract

To provide technology that enables direct communication between users participating in an event, as well as between users and performers. [Solution] The management device includes a storage unit that stores event information relating to an event to be held, a management unit that manages channels, which are communication tools established on a per-performer and per-event basis, and an ownership verification unit that acquires ticket information relating to tickets for the event owned by a user, and confirms that the user owns a ticket by matching the acquired ticket information with the event information, wherein the management unit grants permission to post to and view posts on the channels to users and performers of the event who have been confirmed to own tickets for the event.

Description

Technical Field

[0001] The present invention relates to a management device, a management method, and a program.

Background Art

[0002] Currently, various events using real venues such as live shows and sports are being held. Also, when issuing tickets for events, concerts, etc., a ticket issuing system that enables easy receipt of tickets has been disclosed (Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] By purchasing tickets for an event and participating in the event, users can feel the presence of the performers. Such a real experience can only be obtained by users who actually participate in the event. Also, in order for users participating in the event to feel the presence of the performers more closely and to reduce the distance between users and the distance between users and performers, a mechanism that enables direct communication between users participating in the event and between users and performers is required.

[0005] Therefore, an object of the present invention is to provide a technology that enables direct communication between users participating in an event and between users and performers.

Means for Solving the Problems

[0006] A management device according to one aspect of the present invention includes a storage unit that stores event information relating to an event to be held, a management unit that manages channels, which are communication tools established on a per-performer and per-event basis, and an ownership verification unit that acquires ticket information relating to tickets for the event owned by a user, and confirms that the user owns a ticket by matching the acquired ticket information with the event information, wherein the management unit grants permission to post to and view posts on the channels to users and performers of the event who have been confirmed to own tickets for the event. [Effects of the Invention]

[0007] According to the present invention, it becomes possible for users participating in an event to communicate directly with each other, and for users to communicate directly with performers. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an example of a communication management system according to this embodiment. [Figure 2] This figure shows an example of the hardware configuration of the management server. [Figure 3] This figure shows an example of the functional block configuration of the management server. [Figure 4] This figure shows an example of an event management database. [Figure 5] This figure shows an example of an account management database. [Figure 6] This figure shows an example of a ticket management database. [Figure 7] This figure shows an example of a channel management database. [Figure 8] This figure shows an example of a post management database. [Figure 9] This figure shows an example of the processing procedure performed by the management server. [Figure 10] This figure shows an example of the processing procedure performed by the management server. [Figure 11] This is a diagram showing an example of a screen for registering tickets. [Figure 12] This is a diagram showing an example of a post display screen. [Modes for carrying out the invention]

[0009] Embodiments of the present invention will be described with reference to the attached drawings. In each drawing, components denoted by the same reference numerals have the same or similar configurations.

[0010] <System Configuration> Figure 1 shows an example of a communication management system 1 according to this embodiment. The communication management system 1 includes a management server 10 (also called a management device), one or more terminals 20, and a blockchain network 30. The management server 10, one or more terminals 20, and the blockchain network 30 are connected via a wireless or wired communication network N and can communicate with each other.

[0011] Communication Management System 1 is a system that provides a service (hereinafter referred to as "communication service") that enables communication between event performers and participants who purchase tickets to attend the event, and among participants who purchase tickets to attend the event. Previously, it was possible for event performers to convey messages to participants by posting information on social media, etc. However, information posted on social media can be viewed by a large number of people, not just event participants, making it difficult to determine who the information is intended for. Also, even if event participants post on social media, it can be viewed by a large number of people, not just performers, so information that only event participants would know can be disseminated to a large number of people.

[0012] Therefore, the communication management system 1 according to the present embodiment enables direct communication between participants who have been confirmed to own tickets for participating in an event and performers, and between participants who have been confirmed to own tickets, while providing a state where the content of the communication is made public externally or a state where the content of the communication is not made public externally.

[0013] In the following description, a user who uses a communication service is referred to as a user. Users include performers of an event, related persons (managers of performers or persons in charge of event operation), and users other than performers and related persons (hereinafter referred to as "general users"). Also, when indicating a performer among users, it is described as user (performer) or performer. When indicating a related person among users, it is described as user (related person) or related person. Also, when not distinguishing between performers, related persons, and general users, it is simply described as "user".

[0014] An "event" is an event in which there is a performer and a person who owns a ticket for the event can participate. Specifically, events include live shows, concerts, stage performances, movies, plays, talk shows, sports games, e-sports games, etc. Note that a stage performance means that a performer performs at a specific place during a specific period. In addition to events held at an actual venue, events held online may also be included in the event. Also, in the case where multiple stage performances are held under the same title like a tour, the event may be in units of the tour or in units of the stage performance.

[0015] Also, among general users, a user who has been confirmed to own a ticket for participating in an event is referred to as a "ticket-owning user", and a user who has not been confirmed to own a ticket and a user who does not own a ticket are referred to as a "non-ticket-owning user".

[0016] In this embodiment, the management server 10 provides a tool (hereinafter referred to as "channel") on the Internet to realize two-way communication between performers and ticket owners. The channel may be any as long as it can post text, images, audio, videos, etc. The channel includes, for example, social media, bulletin boards, SNS (Social Networking Service), video sharing services, and the like.

[0017] The channel is opened in units of performers and events, and performers, related persons, and ticket owners can post messages including arbitrary text, images, videos, etc. For example, if there are Event X (e.g., Live X) held in Tokyo where Performer A (e.g., Artist A) performs and Event Y (e.g., Live Y) held in Osaka where Performer B (e.g., Artist B) performs, different channels will be opened respectively.

[0018] In addition, when multiple performers perform in one event, different channels may be opened for each performer, or a common channel for multiple performers may be opened. For example, when the same Event X (e.g., rock festival, etc.) where Performers A, B, and C perform is held, channels for Performer A related to Event X, channels for Performer B related to Event X, and channels for Performer C related to Event X may be opened respectively, or a common channel for Performers A to C related to Event X may be opened. In addition, when the performer is a group of multiple people, channels may be opened for each performer, or channels may be opened in units of groups. Also, when Performer X conducts Tour Y including Performances A, B, and C, the channel may be opened one in units of the performer and the tour, like the channel for Performer X and Tour Y, or may be opened multiple in units of the performer and the performance, like the channel for Performer X and Performance A, the channel for Performer X and Performance B, and the channel for Performer X and Performance C.

[0019] Furthermore, the timing of channel creation and termination is arbitrary. For example, a channel may be created on the event start date or a predetermined date before the event start date, and terminated a predetermined date after the event end date.

[0020] The management server 10 performs various processes related to the provision of channels. For example, the management server 10 manages the posting of messages on the channels, manages accounts for using the communication management system 1, and provides pages that users refer to (web pages or pages displayed on application screens).

[0021] Terminal 20 is a device used to access the management server 10, and examples include smartphones, tablet devices, mobile phones, and personal computers (PCs).

[0022] The blockchain network 30 executes smart contracts that manage NFTs (Non-Fungible Tokens). The management server 10 issues NFTs to ticket holders to indicate participation in an event. The NFTs issued by the management server 10 may be on a per-performer and per-event basis (i.e., per channel), or per event. Ticket holders can prove they are fans of the performers by receiving the NFTs.

[0023] <Hardware Configuration> Figure 2 shows an example of the hardware configuration of the management server 10. The management server 10 has a processor 11 such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit), a storage device 12 such as memory (e.g., RAM (Random Access Memory) or ROM (Read Only Memory)), an HDD (Hard Disk Drive) and / or an SSD (Solid State Drive), a network interface 13 for wired or wireless communication, an input device 14 for receiving input operations, and an output device 15 for outputting information. The input device 14 is, for example, a keyboard, a touch panel, a mouse and / or a microphone. The output device 15 is, for example, a display, a touch panel and / or a speaker.

[0024] <Functional Block Configuration> Figure 3 shows an example of the functional block configuration of the management server 10. The management server 10 includes a storage unit 100, a management unit 101, an ownership verification unit 102, an assignment unit 103, and a display control unit 104. The storage unit 100 can be implemented using a storage device 12 provided by the management server 10. The management unit 101, the ownership verification unit 102, the assignment unit 103, and the display control unit 104 can be implemented by the processor 11 of the management server 10 executing a program stored in the storage device 12. This program can be stored in a storage medium. The storage medium storing this program may be a non-transitory computer-readable medium. The non-transitory storage medium is not particularly limited, but may be, for example, a USB (Universal Serial Bus) memory or a CD-ROM (Compact Disc Read-Only Memory).

[0025] The memory unit 100 stores an event management DB 100a that stores information about events to be held (event information), an account management DB 100b that manages accounts for accessing the website provided by the management server 10, a ticket management DB 100c that manages information about tickets owned by general users, a channel management DB 100d that manages information about channels that are currently open, and a post management DB 100e that stores data posted to channels (text, image data, video data, etc.).

[0026] The management unit 101 manages channels, which are communication tools established on a per-performer and per-event basis. Specifically, the management unit 101 manages posting to and viewing of channel posts. When the management unit 101 receives a post to a channel, it stores the posted data in the post management DB 100e. When the management unit 101 receives a request to view posted data in a channel, it retrieves the posted data from the post management DB 100e and displays it on the screen of terminal 20.

[0027] Furthermore, when accepting a post to a channel or viewing a post to a channel, the management unit 101 verifies whether the user has the necessary permissions. For example, the management unit 101 grants permission to post to a channel and view a post to a channel to ticket holders and event performers who have been confirmed to possess event tickets.

[0028] The ownership verification unit 102 obtains ticket information related to event tickets owned by users participating in the event, and verifies that the user owns the ticket by matching the obtained ticket information with the event holding information.

[0029] The granting unit 103 instructs a smart contract operating on the blockchain network 30 to issue an NFT indicating participation in the event. The granting unit 103 also grants the blockchain wallet of a ticket-owning user, who is determined to possess an event ticket, an NFT containing information about participation in the event (e.g., event name, event date and time, and performer names). The granting unit 103 also grants the ticket-owning user a badge image as information about participation in the event. The badge image may also be called an icon.

[0030] The display control unit 104 displays various screens on the terminal 20 to realize communication services. The display control unit 104 may also be included in the management unit 101.

[0031] Figure 4 shows an example of the event management DB 100a. The Event ID is an ID that uniquely identifies the event being held. The Event Information includes specific information that uniquely identifies the event being held. The Date and Time of the Event indicates the date and start time of the event. The Location of the Event indicates the location where the event is being held. The Event Name indicates the name of the event. The Performer ID is an ID that uniquely identifies the performer. The Performer ID may also include the performer's name corresponding to the Performer ID. The Seat Number List shows information about all the seat numbers provided at the event venue (for example, seats 1 to 30 exist for each of rows A to F).

[0032] Figure 5 shows an example of the account management DB100b. The User ID is an ID that uniquely identifies a user registered with the communication service. Login information is the login information (e.g., login ID and password) for logging into the communication service. User attributes are the attributes of the user (either performer, related party, or general user). If a general user has been assigned an NFT indicating participation in an event, the Digital Badge Information (NFT) will store the token ID of the assigned NFT. If no NFT has been assigned, nothing will be stored in the Digital Badge Information (NFT). The Digital Badge Information (Badge Image) will store the ID of the badge image that indicates which event the general user participated in. The badge image will be displayed in association with the general user on the communication service screen. If no badge has been assigned, nothing will be stored in the Digital Badge Information (Badge Image).

[0033] Figure 6 shows an example of the ticket management DB 100c. The User ID (general user) is an ID that uniquely identifies a general user. The Ticket Ownership Status indicates whether or not it has been confirmed that a general user owns a ticket. "Confirmed" indicates that it has been confirmed that a general user owns a ticket. "Under Confirmation" indicates that it is being confirmed that a general user owns a ticket, such as when the uploaded ticket image data is being analyzed or when an administrator is reviewing it. "Error" indicates that it was not possible to confirm that a general user owns a ticket. The Event ID is the ID of the event identified from the event identification information described later. The Ticket Information stores various information about the ticket owned by the user. The Event Identification Information is event identification information that uniquely identifies the event, read from the ticket image data. The specific contents of the event identification information will be described later. The Seat Number is the seat number written on the ticket. The Ticket Image Data stores the image data uploaded to the management server 10.

[0034] Figure 7 shows an example of the channel management DB 100d. The channel ID is an ID that uniquely identifies the channel to be opened. The user ID (performer, related party) is an ID that uniquely identifies the performer and related party among the users registered in the communication management system 1. The event ID is an ID that uniquely identifies the event. The URL is the URL for accessing the channel to be opened. The start date and time is the date and time when the channel is opened. The end date and time is the date and time when the channel is closed. In the case of an event with multiple performers, a channel may be opened for each performer, or a channel may be opened for all performers in common. In the former case, multiple different channel IDs will be associated with the same event ID. In the latter case, one channel ID will be associated with the same event ID.

[0035] Figure 8 shows an example of the post management DB100e. The Channel ID is an ID that uniquely identifies the channel being created. The Post ID is an ID that uniquely identifies the posted data. The Post Date and Time indicates the date and time the posted data was posted to the channel. The User ID (Poster) stores the ID of the user who posted the data to the channel. For example, if a performer posts, the Poster ID will store the performer's User ID. Also, if a ticket-owning user posts, the Poster ID will store the ticket-owning user's User ID.

[0036] The viewing restriction indicates whether or not viewing of a post is restricted. In this embodiment, posts to a channel include posts that can only be viewed by limited users (hereinafter referred to as "restricted posts") and posts that are not restricted in viewing (hereinafter referred to as "regular posts"). If a post is a regular post, "None" is set, and if a post is a restricted post, "Restricted" is set. The post data stores the posted text data, image data, audio data and / or video data, etc. Note that restricted users (hereinafter referred to as "restricted users") may be ticket holders and event performers. Alternatively, restricted users may be ticket holders, event performers and people related to the event. In other words, "restricted users" may be defined as restricted users including ticket holders and event performers.

[0037] The "Post Attributes" column indicates the attributes of the post. In this embodiment, posts to a channel may include special posts and non-special posts. Special posts may be messages that can be posted by paying a fee. For example, a special post may be a message that includes images, audio, or video, but is not limited to this. For example, a special post may be a post that is displayed preferentially over non-special posts on a screen that lists posts. On the other hand, non-special posts may be messages that can be posted normally without paying a fee. For example, a non-special post may be a text-only message that does not include images, audio, or video, but is not limited to this. The "Post Attributes" column for special posts stores "Special" as the attribute of the post. The "Post Attributes" column for non-special posts stores "Normal" as the attribute of the post.

[0038] Whether a post is special or not applies to both regular posts and restricted posts. In other words, in this embodiment, posts may be divided into four types: regular posts that are not special, restricted posts that are not special, special regular posts, and special restricted posts.

[0039] <Processing Procedure> Figure 9 shows an example of the processing procedure performed by the management server 10. Using Figure 9, we will explain the various processes performed on the communication service provided by the management server 10.

[0040] In step S100, the management unit 101 receives login information from a user using the communication service and performs the login process. The management unit 101 performs the login process by matching the entered login ID and password with the account management DB 100b. If the login is successful, the process proceeds to step S101; if the login fails, the process terminates.

[0041] If the logged-in user selects ticket registration by operating the screen in step S101, the process proceeds to step S102. If ticket registration is not selected, the process proceeds to step S104.

[0042] In step S102, the ownership verification unit 102 obtains ticket information from the terminal 20 used by the user and verifies whether the user owns a ticket. Specifically, the user uploads (registers) image data of a paper ticket or a screenshot of an electronic ticket from the terminal 20 to the management server 10. The ownership verification unit 102 obtains image data of the ticket owned by the user. Subsequently, the ownership verification unit 102 reads the characters written on the ticket by processing the ticket image data with OCR (Optical Character Recognition), and extracts ticket information by performing named entity recognition processing on the read string. Alternatively, instead of processing the image data with OCR, the ownership verification unit 102 may extract ticket information using a learning model that has been trained to output ticket information when ticket image data is input. Alternatively, the administrator of the communication service may visually read the ticket information. In this case, the ownership verification unit 102 may accept input of the visually read ticket information from the administrator of the communication service.

[0043] Furthermore, if ticket purchases are possible within the communication service, that is, if the management server 10 issues a ticket itself, the ownership verification unit 102 may retrieve the ticket information of the ticket owned by the user from the database that manages the information of the issued ticket.

[0044] Furthermore, if it is possible to obtain ticket purchase data from another server that manages ticket sales information (for example, a server of a ticket agency operated by another company), the ownership verification unit 102 may also obtain ticket information of the tickets owned by the user from the other server that manages information on issued tickets.

[0045] Next, the ownership verification unit 102 matches the event identification information, which uniquely identifies the event and is included in the ticket information read from the image data, with the event holding information included in the event management DB 100a. If the event identification information matches the identification information included in the event holding information (i.e., the event can be uniquely identified), it determines that the user owns a ticket for the event.

[0046] On the other hand, the ownership verification unit 102 may determine that it could not confirm that the user owns an event ticket if the event identification information does not match the identification information included in the event holding information (i.e., the event cannot be uniquely identified). In this case, the ownership verification unit 102 may further request the administrator of the communication service to visually check the image data of the ticket. If the ownership verification unit 102 receives notification from the administrator that the user owns an event ticket, it determines that it has been confirmed that the user owns an event ticket.

[0047] Furthermore, the ownership verification unit 102 retrieves the event ID corresponding to the ticket from the event management DB 100a for ticket-owning users whose ownership has been confirmed. Subsequently, the management unit 101 stores the retrieved event ID, event identification information, and ticket seat number in the record of the ticket-owning user in the ticket management DB 100c.

[0048] The event identification information read from the ticket image data and the specific information included in the event management DB 100a's event holding information may be, for example, the date and time of the event, the venue, and / or the event name. For example, the ownership verification unit 102 may determine that the user has been confirmed to own an event ticket when the event identification information read from the ticket image data (event date and time, venue, and event name) matches the specific information included in the event management DB 100a's event holding information (event date and time, venue, and event name). Alternatively, the ownership verification unit 102 may determine that the user has been confirmed to own an event ticket when the event identification information read from the ticket image data (event date and time and event name) matches the specific information included in the event management DB 100a's event holding information (event date and time and event name). Alternatively, for example, the ownership verification unit 102 may determine that the user owns a ticket to the event if the event identification information (event name) read from the ticket image data matches the identification information (event name) included in the event holding information in the event management DB 100a.

[0049] Furthermore, the specific information included in the event identification information and event holding information may also include performers. For example, the ownership verification unit 102 may determine that the user has been confirmed to own an event ticket if the performer's name read from the ticket image data is included in the performers listed in the event holding information of the event management DB 100a.

[0050] Furthermore, the specific information included in the event identification information and event holding information may also include the seat number. For example, the ownership verification unit 102 may further determine that the user has acquired a ticket for the event if the seat number read from the ticket image data is included in the list of seat numbers in the event holding information of the event management DB 100a. This makes it possible to eliminate fraudulent tickets that have non-existent seat numbers.

[0051] Furthermore, when selling tickets within a communication service, it is possible to include an event ID on the ticket. In this case, if an event ID is included on the ticket, the specific information included in the event identification information and event holding information may be considered to be the event ID. In this case, the ownership verification unit 102 may determine that the user has been able to confirm ownership of the event ticket if the event identification information (event ID) read from the ticket image data matches the specific information (event ID) included in the event holding information in the event management DB 100a.

[0052] Furthermore, if ticket sales are conducted within the communication service, or if ticket purchase data can be obtained from another server that manages ticket sales information, the ownership verification unit 102 may assume that the user possesses the ticket, omit the processing steps in step S102, and proceed to the processing steps in step S103.

[0053] Here, the ownership verification unit 102 may further use the ticket's seat information to confirm that the uploaded ticket is not already registered. Alternatively, if the ownership verification unit 102 confirms that the uploaded ticket is not already registered, it may determine that the user owns the event ticket.

[0054] Specifically, the ownership verification unit 102 may further determine that a user owns a ticket to an event if the seat information, which uniquely identifies a seat at the event and is included in the ticket information, is not the same as the seat information identified from the image data of a ticket obtained from another user (i.e., the seat information is not duplicated). Alternatively, the ownership verification unit 102 may determine that a user does not own a ticket to an event if the seat information, which uniquely identifies a seat at the event and is included in the ticket information, is the same as the seat information identified from the image data of a ticket obtained from another user (i.e., the seat information is duplicated). This prevents multiple users from registering the same ticket multiple times.

[0055] In step S103, the management unit 101 retrieves the event ID corresponding to the ticket owned by the ticket owner user from the ticket management DB 100c, for the ticket owner user whose ownership was confirmed in the processing procedure of step S102. Next, the management unit 101 accesses the channel management DB 100d, retrieves the URL of the channel corresponding to the event ID, and sends the retrieved URL to the ticket owner user's terminal 20. If multiple channels are opened for the same event, the management unit 101 will retrieve multiple URLs. For example, in the example in Figure 7, if the event ID is E100, the management unit 101 will retrieve two URLs: the URL of the channel with channel ID C110 and the URL of the channel with channel ID C210. ​​Next, the management unit 101 sends the retrieved URLs to the ticket owner user's terminal 20. If multiple URLs are retrieved, the management unit 101 sends all of the URLs to the ticket owner user's terminal 20.

[0056] In addition to sending a URL to the terminal 20, the management unit 101 may also display a channel list screen on the terminal 20 that lists the channels corresponding to the tickets owned by the user.

[0057] In step S104, if the user chooses to view channels, that is, if they access a URL or select a channel from the channel list screen, the management unit 101 proceeds to the processing procedure in step S105. If the user does not choose to view channels, the process proceeds to the processing procedure in step S109.

[0058] In step S105, the management unit 101 accepts the user's selection of the channel they wish to view. For example, the management unit 101 may recognize that the user has selected the channel at the URL when the user accesses the URL. Alternatively, the management unit 101 may accept the user's selection of the channel they wish to view from a channel list screen. If the user accesses the URL of a channel that has not yet started or has already ended, the management unit 101 may display a message on the terminal 20's screen indicating that the accessed channel has not yet started or has ended.

[0059] In step S106, the management unit 101 displays the posted messages on the selected channel on the screen of terminal 20. Specifically, the management unit 101 retrieves the posted data and the settings for viewing restrictions for the channel selected in step S105 from the post management DB 100e. Subsequently, the management unit 101 displays the posted data in a list on the screen of terminal 20.

[0060] Here, the management unit 101 may allow restricted users of the target channel to view both regular and restricted posts. Alternatively, the management unit 101 may allow users other than restricted users of the target channel (i.e., users without tickets) to view regular posts, but not restricted posts.

[0061] When the management unit 101 displays a list of posted data on the terminal 20 screen, it accesses the channel management DB 100d to obtain the event ID and user ID of the performer for the channel to be viewed. Subsequently, the management unit 101 checks the user's attributes by referring to the account management DB 100b.

[0062] If the user's attribute is "general user," the management unit 101 further checks whether the general user is a ticket owner or not for the channel being viewed by referring to the "ticket ownership status" in the ticket management DB 100c. For example, the management unit 101 may determine that a general user whose "ticket ownership status" is "confirmed" for the event ID record of the channel being viewed is a ticket owner, and a general user whose "ticket ownership status" is "under review" or "error" is a ticket owner. Alternatively, the management unit 101 may determine that a general user for whom there is no record matching the event ID and user ID of the channel being viewed in the ticket management DB 100c is a ticket owner.

[0063] Furthermore, if the user's attribute is "performer" or "related party," the management unit 101 refers to the channel management DB 100d to check whether the user's user ID is included in the "User ID (performer, related party)" of the channel being viewed. If it is included, the management unit 101 determines that the user is a performer or related party of the channel being viewed; if it is not included, the management unit 101 determines that the user is neither a performer nor a related party of the channel being viewed. In the latter case, the management unit 101 may treat the user as a user without a ticket in the channel being viewed.

[0064] Next, the management unit 101 retrieves the post data and viewing restriction settings for the target channel from the post management DB 100e. Subsequently, if the user is a "performer," "related party," or "ticket holder" of the target channel, the management unit 101 displays the post data from the target channel that has viewing restrictions set to "none" and "limited" on the terminal 20 screen. On the other hand, if the user is a "non-ticket holder" of the target channel, the management unit 101 displays the post data from the target channel that has viewing restrictions set to "none" on the terminal 20 screen, and does not display the post data that has been set to "limited" on the terminal 20 screen. The management unit 101 may also display the post data with viewing restrictions set to "limited" on the terminal 20 screen in a manner that allows the existence of the post data to be recognized, but makes it impossible to view or output the post data itself (for example, by masking the text or images).

[0065] Furthermore, the management unit 101 may allow both restricted users and non-restricted users (i.e., all users) of the channels being viewed to view both regular posts and special regular posts.

[0066] In step S107, if the user selects to post a message by operating the screen, the management unit 101 proceeds to the processing procedure in step S108. If the user does not select to post a message, the management unit 101 proceeds to the processing procedure in step S109.

[0067] In step S108, the management unit 101 receives a submission from a user. The management unit 101 associates the submission data obtained from the user's terminal 20 with the user ID of the user (submitter) and stores it in the submission management DB.

[0068] Here, the management unit 101 allows restricted users of the channel to be viewed (which may also be called the channel to be posted) to post new regular posts and new restricted posts to the channel. On the other hand, the management unit 101 may not allow users other than the restricted users of the channel to be viewed (users without tickets) to post either regular posts or restricted posts to the channel.

[0069] The management unit 101 checks the attributes of the logged-in user by referring to the account management DB 100b. If the user's attributes are those of a general user, the management unit 101 also checks whether the user is a ticket owner or not for the channel being viewed by referring to the ticket management DB 100c. Subsequently, if the user is a performer, related party, or ticket owner for the channel being viewed (i.e., a restricted user), the management unit 101 receives a selection from the user regarding whether to post a restricted post or a regular post, and stores the accepted viewing restriction setting and post data in the post management DB 100e. On the other hand, if the user is a ticket owner for the channel being viewed (i.e., a user other than a restricted user), the management unit 101 prevents the user from posting.

[0070] Furthermore, the management unit 101 may allow users to submit regular posts, special regular posts, regular limited posts, or special limited posts if the user is a performer, related party, or ticket holder of the channel being viewed (i.e., a restricted user). The management unit 101 associates the viewing restriction settings, post attribute settings, and post data and stores them in the post management DB 100e.

[0071] Furthermore, the management unit 101 may allow users who do not possess a ticket for the channel in question to post regular posts to that channel, but not to post restricted posts. In addition, the management unit 101 may allow users who do not possess a ticket for the channel in question to post regular posts that are not special, but not to post special regular posts.

[0072] In step S109, the management unit 101 terminates the process if the user selects to log out, and returns to step S101 if the user does not select to log out.

[0073] Figure 10 shows an example of the processing procedure performed by the management server 10. Using Figure 10, we will explain the processing procedure by which the management server 10 grants a badge to a ticket-holding user indicating participation in an event. Note that the timing of executing the processing procedure in Figure 10 is arbitrary; for example, it may be executed when closing the channel, or it may be executed between the end of the event and the closing of the channel. In the following explanation, we will assume that the badge is granted when closing the channel.

[0074] In step S200, the allocation unit 103 extracts users who own tickets corresponding to the channel to be closed. Specifically, the allocation unit 103 refers to the channel management DB 100d and obtains the event ID corresponding to the channel to be closed. Next, the allocation unit 103 refers to the ticket management DB 100c and extracts users whose "ticket ownership status" corresponding to the obtained event ID is "confirmed".

[0075] In step S201, the allocation unit 103 checks whether the extracted ticket-owning user has already opened a blockchain wallet. For example, the allocation unit 103 may display a screen on the extracted ticket-owning user's terminal 20 for inputting the blockchain wallet address. If the ticket-owning user enters a wallet address, the allocation unit 103 determines that the ticket-owning user has already opened a wallet and proceeds to step S202. If the ticket-owning user selects that they do not have a wallet address, the allocation unit 103 determines that the ticket-owning user has not opened a wallet and proceeds to step S203. Alternatively, the allocation unit 103 may check whether the extracted ticket-owning user has already opened a blockchain wallet by referring to the account management DB 100b to see if the wallet address is registered.

[0076] In step S202, the granting unit 103 grants the ticket-owning user's blockchain wallet an NFT containing information about their participation in the event. Specifically, the granting unit 103 generates an NFT by issuing a method to issue an NFT to the smart contract of the blockchain network 30, and stores the token ID of the generated NFT in the digital badge information (NFT) of the ticket-owning user's record in the account management DB 100b. The granting unit 103 also grants the ticket-owning user a badge image. Specifically, the granting unit 103 stores the image ID corresponding to the badge image in the "digital badge information (badge image)" of the ticket-owning user's record in the account management DB 100b.

[0077] In step S203, the granting unit 103 refers to the account management DB 100b and records in the "Digital Badge Information (NFT)" of the user's record that an NFT can be issued. The granting unit 103 also grants a batch image to the ticket-owning user. Specifically, the granting unit 103 stores the image ID corresponding to the batch image in the "Digital Badge Information (Badge Image)" of the ticket-owning user's record in the account management DB 100b.

[0078] In step S204, the granting unit 103 sends a message to the user's terminal 20 prompting them to open a wallet.

[0079] <Screen display example> Figure 11 shows an example of a ticket registration screen. Screen W10 is the screen for accepting ticket registration. When B10 is pressed, a screen for selecting an image of the ticket is displayed. The selected ticket image is displayed in the image display area P10. When the submit button B11 is pressed, the ticket image is uploaded to the management server 10. Once ticket registration is complete and it is confirmed that the user owns the ticket, the screen transitions to screen W20. Screen W20 displays a list of event channels that can be accessed with the registered ticket.

[0080] Figure 12 shows an example of a post display screen. Posts from the channel selected on screen W20 in Figure 11 are displayed in chronological order on the post display screen W30. Post messages M30 and M31 are regular posts, while post message M32 is a restricted post. Post message M32 is not displayed because it is restricted from being viewed. For example, if the user is a ticket holder, performer, or related party, a button B32 that displays the restricted message will be displayed on post message M32. If the user is not a ticket holder, the button B32 may not be displayed on message M32, or it may be displayed in a way that makes it unclickable (grayed out), or even if the button B32 is pressed, the content of post message M32 may not be displayed.

[0081] When button M32 is pressed, the content of the posted message M32 is displayed as shown on the posted message display screen W40.

[0082] Furthermore, if the user is a ticket holder, performer, or related party, the message posting button B30 and the special message posting button B31 will be displayed on the posting display screen W30. On the other hand, if the user is not a ticket holder, buttons B30 and B31 may not be displayed, or they may be displayed in a way that makes them unclickable (grayed out), or even if buttons B30 and B31 are pressed, the user may not be redirected to the posting screen W50.

[0083] When the message posting button B30 or the special message posting button B31 is pressed, the user is taken to the posting screen W50. The posting screen W50 displays an area N50 where the user enters the content to be posted. Additionally, if the user is a ticket holder, performer, or related party, the posting screen W50 displays a button B50 for posting a message that is restricted from being viewed, and a button B51 for posting an unrestricted message, both within the message posting section M32.

[0084] <Variation> (Variation 1) The ownership verification unit 102 may further verify that the user who owns the ticket actually participated in the event. Users who own a ticket and have been confirmed to have actually participated in the event may be referred to as "event participants," while users who have not been confirmed to own a ticket and users who own a ticket but did not participate in the event may be referred to as "non-event participants." In addition, in the various processes described in this embodiment, ticket owners and non-ticket owners may be replaced with event participants and non-event participants, respectively.

[0085] In the processing procedure of step S102, terminal 20 may upload information that confirms actual participation in the event in addition to the ticket image. Alternatively, ownership verification unit 102 may verify that the user participated in the event by confirming that the information confirming actual participation in the event, in addition to the ticket image, is correct.

[0086] Information that can confirm actual participation in an event may be, for example, information pre-specified for each event venue. Specifically, this could be an image taken from a specified location in a specified direction within the event venue, or an image taken of a specified object present within the event venue (for example, a seating chart or seat numbers written on chairs). In addition, the event management DB 100a stores pre-specified information for each event venue in its event information, and the ownership verification unit 102 may compare the information uploaded from the terminal 20 with the pre-specified information for each event venue stored in the event information, and if the two match, it may be determined that the user actually participated in the event.

[0087] (Modification 2) The login process in step S100 may be performed on a server other than the management server 10. For example, in this embodiment, the login process for each user may be implemented using an external SSO (Single Sign On) service. Alternatively, the management unit 101 may forward the login information received from users using the communication service to another server and obtain the login result (success / failure) from that server.

[0088] (Variation 3) In this embodiment, instead of "seat number," information that uniquely identifies the ticket may be used to prevent multiple users from registering the same ticket multiple times. In other words, "seat number" in this embodiment may be read as "information that uniquely identifies the ticket." The information that uniquely identifies the ticket may consist of, for example, a combination of a string and / or numbers. Alternatively, the information that uniquely identifies the ticket may be a reference number. The reference number is a different number printed on each ticket and is used, for example, to specify the order in which visitors enter the venue.

[0089] (Modification 4) In this embodiment, a wallet may be automatically opened for users of the communication service. For example, opening a wallet may be required to create an account for the communication service. In this case, the processing steps S200, S201, S203, and S204 in Figure 10 may be omitted.

[0090] (Modification 4) In this embodiment, the term "stakeholders" may be omitted. In this case, there will be two types of users who use the communication service: performers and general users.

[0091] <Summary> According to the embodiment described above, the management server 10 manages channels, which are communication tools established on a per-performer and per-event basis, and enables users who have been confirmed to own event tickets and event performers to post to and view posts in those channels. This makes it possible for users participating in the event, as well as users and performers, to communicate directly with each other.

[0092] Furthermore, the management server 10 is configured to read ticket information from the ticket image data. By reading ticket information from the ticket image data, it becomes possible to obtain ticket information even if the ticket medium differs depending on the company issuing the ticket. For example, if the ticket is in paper format, the management server 10 can read ticket information from an image taken of the ticket with the camera on the terminal 20. Also, if the ticket is an electronic ticket, the management server 10 can read ticket information from an image obtained using the screenshot function on the terminal 20.

[0093] Furthermore, the management server 10 allows both regular and restricted posts to be posted to the channel. Restricted posts can only be viewed by restricted users (e.g., performers and ticket holders), and cannot be viewed by other users (users without tickets). This allows performers and ticket holders to share information that only performers and users who actually attended the event would know, making the performers feel more accessible and enabling closer communication among users who attended the event.

[0094] The embodiments described above are provided to facilitate understanding of the present invention and are not intended to limit its interpretation. The flowcharts, sequences, elements, and their arrangement, materials, conditions, shapes, and sizes described in the embodiments are not limited to those exemplified and can be modified as appropriate. Furthermore, configurations shown in different embodiments can be partially substituted or combined. [Explanation of symbols]

[0095] 1 Communication management system, 10 Management server, 11 Processor, 12 Storage device, 13 Network interface, 14 Input device, 15 Output device, 20 Terminal, 30 Blockchain network, 10 Management server, 100 Storage unit, 101 Management unit, 102 Ownership verification unit, 103 Assignment unit, 104 Display control unit

Claims

1. A memory unit that stores event information about events that will be held, The management department manages the channels, which are communication tools established on a per-performer and per-event basis. An ownership verification unit obtains ticket information relating to the event tickets owned by the user, and verifies that the user owns the tickets by matching the obtained ticket information with the event information. It has, The management department shall grant permission to users who have been confirmed to possess tickets for the event and performers of the event to post to and view posts on the channel. Management device.

2. The aforementioned event information includes specific information that uniquely identifies the event. The aforementioned ownership verification unit is Obtain image data of the ticket owned by the aforementioned user, The event identification information, which uniquely identifies the event and is included in the ticket information read from the image data, is matched with the event holding information. If the event identification information matches the identification information included in the event holding information, the user will be determined to possess a ticket for the event. The control device according to claim 1.

3. The aforementioned ownership verification unit further, If the seat information that uniquely identifies the seat for the event, included in the ticket information, is not the same as the seat information identified from the ticket image data obtained from another user, then the user is determined to possess the ticket for the event. If the seat information that uniquely identifies a seat at the event, included in the ticket information, is identical to the seat information identified from image data of a ticket obtained from another user, then it is determined that the user does not possess a ticket for the event. The control device according to claim 2.

4. The posts on the aforementioned channel include restricted posts that can only be viewed by a limited number of users, including users who have been confirmed to own tickets to the event and performers at the event, and regular posts that are not restricted in their viewing. The management unit permits the restricted users to view both regular posts and restricted posts, and permits users other than the restricted users to view regular posts but not restricted posts. The control device according to claim 1.

5. The management unit permits the restricted users to post regular posts and restricted posts to the channel, and does not permit users other than the restricted users to post regular posts and restricted posts to the channel. The control device according to claim 4.

6. The regular posts on the aforementioned channel include special regular posts that can be posted by the aforementioned limited users. The management unit grants the limited users and users other than the limited users permission to view the special regular posts. The control device according to claim 4.

7. The blockchain wallet of a user determined to possess a ticket to the aforementioned event is provided with an NFT containing information about their participation in the event, and the blockchain wallet has a granting unit. The control device according to claim 6.

8. The steps include storing event information about the event to be held in the memory unit, The steps involve managing channels, which are communication tools established on a per-performer and per-event basis, The process involves obtaining ticket information related to the event tickets owned by the user, and verifying that the user owns the tickets by matching the obtained ticket information with the event information. Includes, The aforementioned management step grants permission to users who have been confirmed to possess tickets for the event and performers of the event to post to and view posts on the channel. The management method performed by the management device.

9. On the computer, The steps include storing event information about the event to be held in the memory unit, The steps involve managing channels, which are communication tools established on a per-performer and per-event basis, The process involves obtaining ticket information related to the event tickets owned by the user, and verifying that the user owns the tickets by matching the obtained ticket information with the event information. Make it run, The aforementioned management step grants permission to users who have been confirmed to possess tickets for the event and performers of the event to post to and view posts on the channel. program.

Images