Management device, management method, and program

Abstract

Providing a technology that enables direct communication between users participating in an event and between a user and a performer. 【Solution means】A storage unit that stores event holding information regarding an event to be held, a management unit that manages a channel, which is a communication tool opened in units of performers and events, and ticket information regarding the ticket of the event owned by the user are acquired, and by collating the acquired ticket information with the event holding information, an ownership confirmation unit that confirms that the user owns the ticket, and the management unit is provided with a management device that permits posting to the channel and viewing of posts on the channel for users who have been confirmed to own the ticket of the event and performers of 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 the performers, a mechanism that enables direct communication between users participating in the event and between users and the 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 holding information regarding an event to be held, a management unit that manages channels which are communication tools opened in units of performers and events, and an ownership confirmation unit that acquires ticket information regarding tickets of the event owned by a user, and confirms that the user owns the tickets by collating the acquired ticket information with the event holding information. The management unit permits posting to the channels and viewing of the posts in the channels for users who are confirmed to own tickets of the event and for performers of the event.

Effect of the Invention

[0007] According to the present invention, it becomes possible for users participating in an event and between a user and a performer to directly communicate with each other.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Embodiments for Carrying Out the Invention

[0009] Embodiments of the present invention will be described with reference to the accompanying drawings. In each figure, those with the same reference numerals have the same or similar configurations.

[0010] <System Configuration> FIG. 1 is a diagram showing an example of a communication management system 1 according to the present embodiment. The communication management system 1 includes a management server 10 (also referred to as 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] The communication management system 1 is a system that provides a service (hereinafter referred to as the "communication service") that enables communication between event performers and participants who purchase tickets to participate in the event, and between participants who purchase tickets to participate in the event. Heretofore, event performers have been able to convey messages to participants by transmitting information on SNS or the like. However, since the information transmitted on SNS can be viewed by not only event participants but also an unspecified number of people, there has been a problem that it is difficult to know who the information is addressed to. Also, even if an event participant posts a message on SNS, since it can be viewed by not only the performer but also an unspecified number of people, there has been a problem that information known only to event participants will be transmitted to an unspecified number of people.

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

[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 the performers or persons in charge of operating the event), and users other than the performers and related persons (hereinafter referred to as "general users"). When indicating a performer among the users, it is described as a user (performer) or a performer. When indicating a related person among the users, it is described as a user (related person) or a related person. When not distinguishing between performers, related persons, and general users, it is simply described as "user".

[0014] An "event" is an event in which a performer exists 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 events. Also, when 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] 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 can 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), and video sharing services.

[0017] The channel is opened in units of performers and events, and performers, related parties, and ticket owners can post messages including arbitrary text, images, videos, etc. For example, if there is 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 channel common to 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, a channel for performer A related to event X, a channel for performer B related to event X, and a channel for performer C related to event X may be opened respectively, or a channel common to performers A to C related to event X may be opened. 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 of performer X and tour Y, or multiple channels may be opened in units of the performer and the performance like the channel of performer X and performance A, the channel of performer X and performance B, and the channel of performer X and performance C.

[0019] Also, the timing of channel opening and closing is arbitrary. For example, the channel may be opened on the event start date or a predetermined date before the event start date, and may end a predetermined number of days after the event end date.

[0020] The management server 10 performs various processes related to the provision of the channel. For example, the management server 10 manages the posting of messages on the channel, manages accounts for using the communication management system 1, provides pages (pages to be displayed on a web page or an app screen) that users refer to, and so on.

[0021] The terminal 20 is a terminal used to access the management server 10, and examples thereof include a smartphone, a tablet terminal, a mobile phone, a personal computer (PC), and the like.

[0022] The blockchain network 30 executes a smart contract for managing NFTs (Non-Fungible Tokens). The management server 10 issues an NFT indicating that a user has participated in an event and grants it to the ticket-holding user. The NFT issued by the management server 10 may be in units of the performer and the event (i.e., channel unit), or may be in event units. By being granted the NFT, the ticket-holding user can prove that they are a fan of the performer.

[0023] <Hardware Configuration> FIG. 2 is a diagram showing an example of the hardware configuration of the management server 10. The management server 10 includes a processor 11 such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit), a memory (for example, RAM (Random Access Memory) or ROM (Read Only Memory)), a storage device 12 such as an HDD (Hard Disk Drive) and / or an SSD (Solid State Drive), a network IF (Network Interface) 13 that performs wired or wireless communication, an input device 14 that accepts input operations, and an output device 15 that outputs information. The input device 14 is, for example, a keyboard, a touch panel, a mouse, and / or a microphone, etc. The output device 15 is, for example, a display, a touch panel, and / or a speaker, etc.

[0024] <Functional block configuration> FIG. 3 is a diagram showing 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 confirmation unit 102, a granting unit 103, and a display control unit 104. The storage unit 100 can be realized using the storage device 12 provided in the management server 10. Also, the management unit 101, the ownership confirmation unit 102, the granting unit 103, and the display control unit 104 can be realized by the processor 11 of the management server 10 executing a program stored in the storage device 12. Further, the program can be stored in a storage medium. The storage medium storing the program may be a non-transitory computer-readable medium. The non-transitory storage medium is not particularly limited, but may be, for example, a storage medium such as a USB (Universal Serial Bus) memory or a CD-ROM (Compact Disc Read-Only Memory).

[0025] The storage unit 100 stores an event management DB 100a that stores information about events to be held (event holding 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 open, and a post management DB 100e that stores data (text, image data, video data, etc.) posted to channels.

[0026] The management unit 101 manages channels, which are communication tools opened for each performer and event. Specifically, the management unit 101 manages posts to channels and viewing of posts to channels. Also, when the management unit 101 receives a post to a channel, it stores the posted post data in the post management DB 100e. Further, when the management unit 101 receives a request to view post data posted to a channel, it acquires the post data from the post management DB 100e and displays it on the screen of the terminal 20.

[0027] Also, when receiving a post to a channel and a request to view a post to a channel, the management unit 101 checks for the existence of permissions. For example, the management unit 101 permits posts to channels and viewing of posts to channels for ticket-owning users who have been confirmed to own tickets for the event and for performers of the event.

[0028] The ownership confirmation unit 102 acquires ticket information regarding tickets for events owned by users participating in the event, and confirms that the user owns the tickets by comparing the acquired ticket information with the event holding information.

[0029] The awarding unit 103 instructs the smart contract operating on the blockchain network 30 to issue an NFT indicating that it has participated in the event. In addition, the awarding unit 103 awards an NFT containing information related to participation in the event (such as the event name, event date and time, and names of performers, etc.) to the blockchain wallet of the ticket-owning user determined to own the event ticket. Further, the awarding unit 103 awards the ticket-owning user an image of a badge as information related to participation in the event. The image of the badge may also be referred to as an icon.

[0030] The display control unit 104 causes the terminal 20 to display various screens for realizing the communication service. Note that the display control unit 104 may be included in the management unit 101.

[0031] FIG. 4 is a diagram showing an example of the event management DB 100a. The event ID indicates an ID that uniquely identifies the event to be held. The event holding information includes specific information that uniquely identifies the event to be held. The holding date and time indicate the date on which the event is held and the event start time. The holding location indicates the location where the event is held. The event name indicates the name of the event. The performer ID indicates an ID that uniquely identifies the performer. Note that the performer ID may further include the name of the performer corresponding to the performer ID. The seat number list indicates information regarding all the seat numbers provided in the event venue (for example, there are seats numbered 1 to 30 for each of columns A to F).

[0032] FIG. 5 is a diagram showing an example of the account management DB 100b. The user ID indicates an ID that uniquely identifies a user registered in the communication service. The login information indicates login information (e.g., login ID and password) for logging in to the communication service. The user attribute indicates the attribute of the user (either a performer, a person related to the event, or a general user). In the digital badge information (NFT), when an NFT indicating that a general user has participated in an event is granted, the token ID of the granted NFT is stored. If no NFT is granted, nothing is stored in the digital badge information (NFT). In the digital badge information (badge image), the ID of the image of the badge indicating which event a general user has participated in is stored. The image of the badge is displayed corresponding to the general user on the screen of the communication service. If no badge is granted, nothing is stored in the digital badge information (badge image).

[0033] FIG. 6 is a diagram showing an example of the ticket management DB 100c. The user ID (general user) indicates an ID that uniquely identifies a general user. The ticket ownership status indicates whether it has been confirmed that a general user owns a ticket. "Confirmed" indicates a state where it has been confirmed that a general user owns a ticket. "In progress" indicates that it is being confirmed whether a general user owns a ticket, such as when the image data of the uploaded ticket is being analyzed or when the administrator is checking. "Error" indicates that it has not been possible to confirm that a general user owns a ticket. The event ID indicates the ID of the event specified from the event specification information described later. The ticket information stores various information related to the tickets owned by the user. The event specification information indicates event specification information read from the ticket image data that uniquely identifies an event. The specific content of the event specification information will be described later. The seat number indicates the seat number described on the ticket. The ticket image data stores the image data uploaded to the management server 10.

[0034] FIG. 7 is a diagram showing an example of the channel management DB 100d. The channel ID indicates an ID that uniquely identifies the channel to be opened. The user ID (performer, related person) indicates an ID that uniquely identifies the performers and related persons among the users registered in the communication management system 1. The event ID indicates an ID that uniquely identifies the event. The URL indicates a URL for accessing the channel to be opened. The start date and time indicate the date and time when the opening of the channel starts. The end date and time indicate the date and time when the opening of the channel ends (is closed). Note that in the case of an event in which a plurality of performers appear, the channel may be opened for each performer or may be opened commonly for a plurality of performers. In the former case, a plurality of different channel IDs are associated with the same event ID. On the other hand, in the latter case, one channel ID is associated with the same event ID.

[0035] FIG. 8 is a diagram showing an example of the post management DB 100e. The channel ID indicates an ID that uniquely identifies the channel to be opened. The post ID indicates an ID that uniquely identifies the post data. The post date and time indicate the date and time when the post data was posted to the channel. The user ID (poster) stores the ID of the user who posted the post data to the channel. For example, when a performer posts, the user ID of the performer is stored in the poster ID. Also, when a ticket owner user posts, the user ID of the ticket owner user is stored in the poster ID.

[0036] The viewing restriction indicates whether the viewing of a post is restricted. In this embodiment, posts to a channel include posts that can be viewed only by limited users (hereinafter referred to as "restricted posts") and posts whose viewing is not restricted (hereinafter referred to as "normal posts"). When a post is a normal post, "none" is set, and when a post is a restricted post, "restricted" is set. Post data stores the posted text data, image data, audio data, and / or video data, etc. Note that the limited users (hereinafter referred to as "restricted users") may be ticket-owning users and event performers. Or, the limited users may be ticket-owning users, event performers, and event-related persons. That is, the "restricted users" may be defined as limited users including ticket-owning users and event performers.

[0037] "Post attribute" indicates the attribute of a post. In this embodiment, posts to a channel may include special posts and non-special posts. A special post may be a message that can be posted by paying money. As an example, a special post may be a message including an image, audio, or video, but is not limited thereto. As another example, a special post may be a post that is preferentially displayed over non-special posts on the screen for listing posts. On the other hand, a non-special post may be a message that can be normally posted without paying money. As an example, a non-special post may be a message of only text without including an image, audio, and video, but is not limited thereto. In the "post attribute" column of a special post, "special" is stored as the attribute of the post. Also, in the "post attribute" column of a non-special post, "normal" is stored as the attribute of the post.

[0038] Whether it is a special post or not is applicable to both normal posts and restricted posts. That is, in this embodiment, posts may be divided into four types: non-special normal posts, non-special restricted posts, special normal posts, and special restricted posts.

[0039] <Processing procedure> FIG. 9 is a diagram showing an example of a processing procedure performed by the management server 10. Using FIG. 9, various processes performed on the communication service provided by the management server 10 will be described.

[0040] In step S100, the management unit 101 performs a login process by receiving an input of login information from a user who uses the communication service. The management unit 101 performs a login process by comparing the input login ID and password with the account management DB 100b. If the login is completed, the process proceeds to step S101, and if the login fails, the process ends.

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

[0042] In step S102, the ownership confirmation unit 102 acquires ticket information from the terminal 20 used by the user and confirms whether the user owns the ticket. Specifically, the user uploads (registers) image data of a photographed paper ticket or a screenshot of an electronic ticket from the terminal 20 to the management server 10. The ownership confirmation unit 102 acquires the image data of the ticket owned by the user. Subsequently, the ownership confirmation unit 102 performs OCR (Optical Character Recognition) processing on the image data of the ticket to read the characters described on the ticket, and performs specific expression extraction processing on the read character string to extract ticket information. Note that the ownership confirmation unit 102 may extract ticket information by using a learning model trained to output ticket information when the image data of the ticket is input instead of performing OCR processing on the image data. Also, the administrator of the communication service may visually read the ticket information. In this case, the ownership confirmation unit 102 may be configured to receive an input of the ticket information visually read by the administrator of the communication service.

[0043] Also, when ticket purchase is possible within the communication service, that is, when the management server 10 issues tickets itself, the ownership confirmation unit 102 may obtain the ticket information of the tickets owned by the user from the database that manages the information of the issued tickets.

[0044] Also, when it is possible to obtain the ticket purchase data from another server that manages the ticket trading information (for example, the server of a play guide operated by another company, etc.), the ownership confirmation unit 102 may obtain the ticket information of the tickets owned by the user from another server that manages the information of the issued tickets.

[0045] Subsequently, the ownership confirmation unit 102 compares the event specific information that uniquely identifies the event, which is included in the ticket information read from the image data, with the event holding information included in the event management DB 100a. When the event specific information matches the specific information included in the event holding information (that is, when the event can be uniquely identified), it is determined that the user owns the ticket for the event.

[0046] On the other hand, when the event specific information does not match the specific information included in the event holding information (that is, when the event cannot be uniquely identified), the ownership confirmation unit 102 may determine that it cannot be confirmed that the user owns the ticket for the event. In this case, the ownership confirmation unit 102 may further request the administrator of the communication service to visually confirm the image data of the ticket. When the ownership confirmation unit 102 receives a notification from the administrator that the user owns the ticket for the event, it is determined that it can be confirmed that the user owns the ticket for the event.

[0047] In addition, the ownership confirmation unit 102 acquires the event ID corresponding to the ticket from the event management DB 100a for the ticket-owning user whose ownership of the ticket has been confirmed. Subsequently, the management unit 101 stores the acquired event ID, event identification information, and the seat number of the ticket 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 holding information of the event management DB 100a may be, for example, the event holding date and time, the holding location, and / or the event name. For example, when the event identification information (event holding date and time, holding location, and event name) read from the ticket image data by the ownership confirmation unit 102 matches the specific information (event holding date and time, holding location, and event name) included in the event holding information of the event management DB 100a, the user may be determined to have been confirmed to own the event ticket. Also, for example, when the event identification information (event holding date and time and event name) read from the ticket image data by the ownership confirmation unit 102 matches the specific information (event holding date and time and event name) included in the event holding information of the event management DB 100a, the user may be determined to have been confirmed to own the event ticket. Also, for example, when the event identification information (event name) read from the ticket image data by the ownership confirmation unit 102 matches the specific information (event name) included in the event holding information of the event management DB 100a, the user may be determined to have been confirmed to own the event ticket.

[0049] In addition, the specific information included in the event identification information and the event holding information may further include the performers. For example, when the performer name read from the ticket image data by the ownership confirmation unit 102 further includes the performers included in the event holding information of the event management DB 100a, the user may be determined to have been confirmed to own the event ticket.

[0050] In addition, the specific information included in the event identification information and the event holding information may further include seat numbers. For example, when the seat number read from the image data of the ticket is included in the list of seat numbers included in the event holding information of the event management DB 100a, the ownership confirmation unit 102 may be configured to determine that the user owns the event ticket. This makes it possible to eliminate fraudulent tickets with non-existent seat numbers.

[0051] When selling tickets within the communication service, it is possible to record the event ID on the ticket. Therefore, when the event ID is recorded on the ticket, the specific information included in the event identification information and the event holding information may be the event ID. In this case, when the event identification information (event ID) read from the image data of the ticket matches the specific information (event ID) included in the event holding information of the event management DB 100a, the ownership confirmation unit 102 may be configured to determine that the user owns the event ticket.

[0052] Also, when selling tickets within the communication service, or when it is possible to obtain the ticket purchase data from another server that manages the ticket transaction information, the ownership confirmation unit 102 may consider that the user holds the ticket, omit the processing procedure of step S102, and proceed to the processing procedure of step S103.

[0053] Here, the ownership confirmation unit 102 may further use the seat information of the ticket to confirm that the uploaded ticket is not a previously registered ticket. Also, when the ownership confirmation unit 102 can confirm that the uploaded ticket is not a previously registered ticket, it may be configured to determine that the user owns the event ticket.

[0054] Specifically, when the seat information included in the ticket information that uniquely identifies the seat in the event is not the same as the seat information identified from the image data of the ticket obtained from another user (that is, when the seat information does not overlap), the ownership confirmation unit 102 may determine that the user owns the event ticket. Further, when the seat information included in the ticket information that uniquely identifies the seat in the event is the same as the seat information identified from the image data of the ticket obtained from another user (that is, when the seat information overlaps), the ownership confirmation unit 102 may determine that the user does not own the event ticket. Thereby, it is possible to prevent a plurality of users from registering the same ticket redundantly.

[0055] In step S103, the management unit 101 acquires, from the ticket management DB 100c, the event ID corresponding to the ticket owned by the ticket-owning user who has been confirmed to own the ticket in the processing procedure of step S102. Subsequently, the management unit 101 accesses the channel management DB 100d, acquires the URL of the channel corresponding to the event ID, and transmits the acquired URL to the terminal 20 of the ticket-owning user. When a plurality of channels are opened for the same event, the management unit 101 will acquire a plurality of URLs. For example, in the example of FIG. 7, when the event ID is E100, the management unit 101 will acquire two URLs, namely, the URL of the channel with the channel ID C110 and the URL of the channel with the channel ID C210. Subsequently, the management unit 101 transmits the acquired URLs to the terminal 20 of the ticket-owning user. When there are a plurality of acquired URLs, the management unit 101 transmits the plurality of URLs to the terminal 20 of the ticket-owning user.

[0056] In addition to or instead of transmitting the URL to the terminal 20, the management unit 101 may cause the terminal 20 to display a channel list screen that displays a list of channels corresponding to the tickets owned by the user.

[0057] In step S104, when the management unit 101 determines that the user has selected to view a channel, that is, when the user accesses a URL or selects a channel from the channel list screen, the process proceeds to the processing procedure of step S105. If the user does not select to view a channel, the process proceeds to the processing procedure of step S109.

[0058] In step S105, the management unit 101 accepts the selection of the channel that the user wishes to view. For example, when the user accesses a URL, the management unit 101 may recognize that the channel corresponding to the URL is selected. Alternatively, the management unit 101 may accept the selection of the channel that the user wishes to view from the channel list screen. When the user accesses the URL of a channel that has not started or has ended, the management unit 101 may cause a message indicating that the accessed channel has not started or has ended to be displayed on the screen of the terminal 20.

[0059] In step S106, the management unit 101 causes the posted messages posted to the selected channel to be displayed on the screen of the terminal 20. Specifically, the management unit 101 obtains the posting data and the setting value of the viewing restriction for the channel selected in step S105 from the posting management DB100e. Subsequently, the management unit 101 displays the posting data in a list on the screen of the terminal 20.

[0060] Here, the management unit 101 may permit the viewing of normal posts and restricted posts for the restricted users of the channel to be viewed. In addition, the management unit 101 may permit the viewing of normal posts for users other than the restricted users of the channel to be viewed (that is, users who do not hold tickets) and not permit the viewing of restricted posts.

[0061] When the management unit 101 displays the posting data in a list on the screen of the terminal 20, it accesses the channel management DB100d to obtain the event ID of the channel to be viewed and the user ID of the performer. Subsequently, the management unit 101 checks the user attributes by referring to the account management DB100b.

[0062] When the attribute of the user is "general user", the management department 101 further refers to the "ticket ownership status" in the ticket management DB 100c to confirm whether the general user is the ticket owner user or the non-ticket owner user of the channel to be viewed. For example, for the record of the event ID of the channel to be viewed, the management department 101 may determine that a general user with a "ticket ownership status" of "confirmed" is a ticket owner user, and a general user with a "ticket ownership status" of "under confirmation" or "error" is a non-ticket owner user. Also, a general user for whom there is no record in the ticket management DB 100c that matches the event ID and user ID of the channel to be viewed may be determined to be a non-ticket owner user.

[0063] Also, when the attribute of the user is "performer" or "related person", the management department 101 refers to the channel management DB 100d to confirm whether the user ID of the user is included in the "user ID (performer, related person)" of the channel to be viewed. If it is included, the user is determined to be a performer or related person of the channel to be viewed, and if it is not included, the user is determined not to be a performer or related person of the channel to be viewed. In the latter case, the management department 101 may handle the user as a non-ticket owner user in the channel to be viewed.

[0064] Subsequently, the management unit 101 acquires the posted data and the set values of viewing restrictions in the channel to be viewed from the post management DB 100e. Subsequently, when the user is an "actor", "related person", or "ticket owner user" of the channel to be viewed, the management unit 101 causes the posted data with viewing restrictions set to "none" and "limited" among the posts of the channel to be viewed to be displayed on the screen of the terminal 20. On the other hand, when the user is a "user without a ticket" of the channel to be viewed, the management unit 101 causes the posted data with viewing restrictions set to "none" among the posts of the channel to be viewed to be displayed on the screen of the terminal 20, and does not cause the posted data with viewing restrictions set to "limited" to be displayed on the screen of the terminal 20. Note that the management unit 101 may cause the posted data with viewing restrictions set to "limited" to be displayed on the screen of the terminal 20 in a manner that it can recognize the existence of the posted data but cannot view or output the posted data itself (for example, masking text or images).

[0065] Also, the management unit 101 may permit the viewing of normal posts and special normal posts that are not special for both restricted users and non-restricted users (i.e., all users) of the channel to be viewed.

[0066] In step S107, when the user selects a message post by operating the screen, the management unit 101 proceeds to the processing procedure of step S108. If the message post is not selected, the process proceeds to the processing procedure of step S109.

[0067] In step S108, the management unit 101 accepts the post from the user. The management unit 101 stores the posted data acquired from the user's terminal 20 in association with the user ID of the user (the poster) in the post management DB.

[0068] Here, the management unit 101 permits a new normal post and a new restricted post to be posted to the channels to be viewed (which may also be referred to as the posts target) by the restricted users of the channels to be viewed. On the other hand, the management unit 101 may not permit either a normal post or a restricted post to be posted to the channels to be viewed by users other than the restricted users of the channels to be viewed (users without tickets).

[0069] The management unit 101 checks the attributes of the logged-in user by referring to the account management DB 100b. Also, when the user's attribute is a general user, the management unit 101 checks whether the user is a ticket owner user or a non-ticket owner user of the channels to be viewed by referring to the ticket management DB 100c. Subsequently, when the user is a performer, a related person, or a ticket owner user of the channels to be viewed (i.e., a restricted user), the management unit 101 accepts the selection from the user as to whether to post a restricted post or a normal post, and associates the received viewing restriction setting with the post data and stores it in the post management DB 100e. On the other hand, when the user is a non-ticket owner user of the channels to be viewed (i.e., a user other than a restricted user), the management unit 101 does not accept the post.

[0070] Also, when the user is a performer, a related person, or a ticket owner user of the channels to be viewed (i.e., a restricted user), the management unit 101 may accept the posting of a normal post that is not special, a special normal post, a restricted post that is not special, or a special restricted post. The management unit 101 associates the viewing restriction setting, the post attribute setting, and the post data and stores them in the post management DB 100e.

[0071] In addition, the management unit 101 may permit ordinary posts to the channel for users who do not own tickets for the channel to be browsed, but not permit limited posts. Further, the management unit 101 may permit ordinary non-special posts for users who do not own tickets for the channel to be browsed, but not permit special ordinary posts.

[0072] In step S109, when the user selects logout, the management unit 101 ends the process, and when the user does not select logout, it returns to step S101.

[0073] FIG. 10 is a diagram showing an example of a processing procedure performed by the management server 10. Using FIG. 10, the processing procedure when the management server 10 assigns a badge indicating that a ticket-owning user has participated in an event will be described. Note that the timing of executing the processing procedure in FIG. 10 is arbitrary. For example, it may be executed when closing a channel, or may be executed between the end of an event and the closing of the channel. In the following description, it will be described as assigning a badge when closing a channel.

[0074] In step S200, the awarding unit 103 extracts users who own tickets corresponding to the channel to be closed. Specifically, the awarding unit 103 refers to the channel management DB 100d to obtain the event ID corresponding to the channel to be closed. Subsequently, the awarding 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 granting unit 103 checks whether the extracted ticket-owning user has already opened a blockchain wallet. For example, the granting unit 103 may display a screen for inputting the address of the blockchain wallet on the terminal 20 of the extracted ticket-owning user. When the ticket-owning user inputs the wallet address, the granting unit 103 determines that the ticket-owning user has already opened the wallet and proceeds to step S202. When the ticket-owning user selects that they do not own the wallet address, the granting unit 103 determines that the ticket-owning user has not opened the wallet and proceeds to step S203. Alternatively, the granting unit 103 may check whether the extracted ticket-owning user has already opened a blockchain wallet by referring to whether the wallet address is registered in the account management DB100b.

[0076] In step S202, the granting unit 103 grants an NFT containing information regarding participation in the event to the blockchain wallet of the ticket-owning user. Specifically, the granting unit 103 generates an NFT by issuing a method for issuing the 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 record of the ticket-owning user in the account management DB100b. In addition, the granting unit 103 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 record of the ticket-owning user in the account management DB100b.

[0077] In step S203, the granting unit 103 refers to the account management DB100b and records in the "digital badge information (NFT)" of the user's record that the NFT can be issued. Further, the granting unit 103 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 record of the ticket-owning user in the account management DB100b.

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

[0079] <Example of screen display> FIG. 11 is a diagram showing an example of a screen for registering a ticket. The screen W10 is a screen for accepting the registration of a ticket. When B10 is pressed, a screen for selecting an image of the taken ticket is displayed. The selected ticket image is displayed in the image display area P10. When the send button B11 is pressed, the ticket image is uploaded to the management server 10. When the registration of the ticket is completed and it is confirmed that the user owns the ticket, the screen transitions to the screen W20. A list of channels of events that can be participated in with the registered ticket is displayed on the screen W20.

[0080] FIG. 12 is a diagram showing an example of a post display screen. Posts of the channel selected on the screen W20 in FIG. 11 are listed in chronological order on the post display screen W30. Post messages M30 and M31 are post messages of normal posts, and post message M32 is a post message of a restricted post. Since the post message M32 is restricted from being viewed, the post content is not displayed. For example, when the user is a ticket owner user, a performer, or a related person, a button B32 for displaying a message restricted from being viewed is displayed in the post message M32. Also, when the user is a non-ticket owner user, the button B32 may not be displayed in the message M32, or may be displayed in a state where it cannot be pressed (grayed out), or the content of the post message M32 may not be displayed even if the button B32 is pressed.

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

[0082] Also, when the user is a ticket owner user, a performer, or a related person, a message post button B30 and a special message post button B31 are displayed on the post display screen W30. On the other hand, when the user is a non-ticket owner user, the buttons B30 and B31 may not be displayed, or may be displayed in a state where they cannot be pressed (grayed out), or the post screen W50 may not transition even if the buttons B30 and B31 are pressed.

[0083] When the message post button B30 or the special message post button B31 is pressed, the screen transitions to the post screen W50. An area N50 for inputting the content to be posted is displayed on the post screen W50. Also, on the post screen W50, when the user is a ticket owner user, a performer, or a related person, a button B50 for posting a message restricted from being viewed and a button B51 for posting a message not restricted from being viewed are displayed in the post message M32.

[0084] <Modification Example> (Modification Example 1) The ownership confirmation unit 102 may further confirm that the user who owns the ticket actually participated in the event. Also, a user who owns a ticket and for whom it can be confirmed that they actually participated in the event is referred to as an "event participant", and a user for whom it cannot be confirmed that they own a ticket and a user who owns a ticket but did not participate in the event are referred to as "non - event participants". Further, in the various processes described in this embodiment, the ticket - owning user and the non - ticket - owning user may be replaced with the event participant and the non - event participant, respectively.

[0085] In the processing procedure of step S102, the terminal 20 may upload information in addition to the ticket image that can confirm that the user actually participated in the event. Also, the ownership confirmation unit 102 may confirm that the user participated in the event by confirming that the information in addition to the ticket image that can confirm that the user actually participated in the event is correct information.

[0086] The information that can confirm that the user actually participated in the event may be, for example, information specified in advance for each event venue. Specifically, it may be an image taken from a specified position in a specified direction within the event venue, or an image taken of a specified object existing within the event venue (for example, a seat number described on a seat map or a chair). Also, the event holding information in the event management DB100a stores information specified in advance for each event venue, and the ownership confirmation unit 102 compares the information uploaded from the terminal 20 with the information specified in advance for each event venue stored in the event holding information, and if the two match, it may be determined that the user actually participated in the event.

[0087] (Modification Example 2) The login process in step S100 may also be executed on a server different from the management server 10. For example, in this embodiment, the login process for each user may be realized by using an external SSO (Single Sign On) service. Further, the management unit 101 may transfer the login information received from a user who uses the communication service to another server and obtain the login result (success / failure) from the other server.

[0088] (Modification Example 3) In this embodiment, instead of the "seat number", by using information that can uniquely identify a ticket, it is possible to prevent a plurality of users from registering the same ticket repeatedly. That is, the "seat number" in this embodiment may be read as "information that can uniquely identify a ticket". The information that can uniquely identify a ticket may be composed of, for example, a combination of a character string and / or numbers. Further, the information that can uniquely identify a ticket may be a sorting number. The sorting number is a different number for each ticket described on the ticket, and is used, for example, when specifying the order of entry when a visitor enters the venue.

[0089] (Modification Example 4) In this embodiment, it may be possible to automatically open a wallet for a user who uses the communication service. For example, in order to create an account for the communication service, it may be essential to open a wallet. In this case, the processing procedures of steps S200, S201, S203, and S204 in FIG. 10 may be omitted.

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

[0091] <Summary> According to the embodiments described above, the management server 10 manages channels, which are communication tools opened in units of performers and events, and enables users who have confirmed that they own event tickets and event performers to post to and view posts on the channels. As a result, it becomes possible for users participating in the event and between users and performers to communicate directly with each other.

[0092] In addition, the management server 10 is configured to read ticket information from the image data of the ticket. By reading the ticket information from the image data of the ticket, it becomes possible to obtain the ticket information even when the ticket media differs for each company that issues the ticket. For example, when the ticket is a paper medium, the management server 10 can read the ticket information from an image of the ticket taken by the camera provided in the terminal 20. Also, when the ticket is an electronic ticket, the management server 10 can read the ticket information from an image obtained by the screenshot function provided in the terminal 20.

[0093] In addition, the management server 10 enables both normal posts and restricted posts to be posted to the channel. For restricted posts, only restricted users (for example, performers and ticket-owning users) can view them, and users other than restricted users (users who do not own tickets) cannot view them. As a result, performers and ticket-owning users can, for example, share information that only they know, such as information about performers or users who actually participated in the event, making the performers feel closer and enabling closer communication among the users who participated in the event.

[0094] The embodiments described above are for facilitating the understanding of the present invention and are not for limiting and interpreting the present invention. The flowcharts, sequences, each element included in the embodiments, and their arrangements, materials, conditions, shapes, sizes, etc. illustrated in the embodiments are not limited to those illustrated and can be changed as appropriate. Also, it is possible to partially replace or combine the configurations shown in different embodiments.

Description of Symbols

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

Claims

1. A storage unit that stores event information related to an event to be held; An administration department that manages channels, which are communication tools set up for each performer and event; an ownership confirmation unit that acquires ticket information relating to a ticket for the event owned by a user and verifies that the user owns the ticket by comparing the acquired ticket information with the event information; having The management unit permits users who have been confirmed to own tickets to the event and performers of the event to post to the channel and view posts on the channel; The event information includes identification information that uniquely identifies the event, The ownership confirmation unit is Acquire image data of a ticket owned by the user; comparing event identification information uniquely identifying the event included in the ticket information read from the image data with the event holding information; If the event identification information matches identification information included in the event hosting information, it is determined that the user owns a ticket to the event. Management device.

2. The ownership confirmation unit further if seat information included in the ticket information that uniquely identifies a seat for the event is not identical to the seat information identified from image data of a ticket obtained from another user, it is determined that the user owns a ticket for the event; If seat information that uniquely identifies a seat at the event and that is included in the ticket information is identical to the seat information identified from image data of a ticket obtained from another user, it is determined that the user does not own a ticket for the event. The management device according to claim 1 .

3. The posts on the channel include limited posts that can be viewed only by limited users, including users who have been confirmed to own tickets to the event and performers of the event, and normal posts that are not restricted in viewing; The management unit permits the limited user to view the normal posts and the limited posts, and permits users other than the limited user to view the normal posts but not the limited posts. The management device according to claim 1 .

4. The management unit permits the limited user to post normal posts and restricted posts to the channel, and does not permit users other than the limited user to post normal posts and restricted posts to the channel. The management device according to claim 3 .

5. The regular posts of the channel include special regular posts that can be posted by the limited users, The management unit permits the limited users and users other than the limited users to view the special normal post. The management device according to claim 3 .

6. An assigning unit that assigns an NFT including information regarding participation in the event to a blockchain wallet of a user who is determined to own a ticket for the event. The management device according to claim 1 .

7. storing event information relating to an event to be held in a storage unit; Managing channels, which are communication tools established for each performer and event; acquiring ticket information relating to a ticket for the event owned by a user, and verifying that the user owns the ticket by comparing the acquired ticket information with the event information; Including, The step of managing includes allowing users who have been confirmed to have tickets to the event and performers of the event to post on the channel and view posts on the channel; The event information includes identification information that uniquely identifies the event, The step of checking includes: Acquire image data of a ticket owned by the user; comparing event identification information uniquely identifying the event included in the ticket information read from the image data with the event holding information; If the event identification information matches identification information included in the event hosting information, it is determined that the user owns a ticket to the event. A management method performed by a management device.

8. On the computer, storing event information relating to an event to be held in a storage unit; Managing channels, which are communication tools established for each performer and event; acquiring ticket information relating to a ticket for the event owned by a user, and verifying that the user owns the ticket by comparing the acquired ticket information with the event information; Run the command, The step of managing includes allowing users who have been confirmed to have tickets to the event and performers of the event to post on the channel and view posts on the channel; The event information includes identification information that uniquely identifies the event, The step of checking includes: Acquire image data of a ticket owned by the user; comparing event identification information uniquely identifying the event included in the ticket information read from the image data with the event holding information; If the event identification information matches identification information included in the event hosting information, it is determined that the user owns a ticket to the event. program.

Images