WO2023007867A1 - チケット管理システム、プログラム、および方法 - Google Patents

チケット管理システム、プログラム、および方法 Download PDF

Info

Publication number
WO2023007867A1
WO2023007867A1 PCT/JP2022/016695 JP2022016695W WO2023007867A1 WO 2023007867 A1 WO2023007867 A1 WO 2023007867A1 JP 2022016695 W JP2022016695 W JP 2022016695W WO 2023007867 A1 WO2023007867 A1 WO 2023007867A1
Authority
WO
WIPO (PCT)
Prior art keywords
ticket
user
electronic
processor
owner
Prior art date
Application number
PCT/JP2022/016695
Other languages
English (en)
French (fr)
Inventor
圭史 伊藤
Original Assignee
ｐｌａｙｇｒｏｕｎｄ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ｐｌａｙｇｒｏｕｎｄ株式会社 filed Critical ｐｌａｙｇｒｏｕｎｄ株式会社
Priority to JP2023538277A priority Critical patent/JPWO2023007867A1/ja
Publication of WO2023007867A1 publication Critical patent/WO2023007867A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services

Definitions

  • This disclosure relates to a ticket management system, program, and method.
  • Patent Literature 1 discloses a system that provides benefits by purchasing an electronic ticket for an event.
  • Such electronic tickets are also being applied to online live performances, but in general, electronic tickets for online events are treated as "individual viewing rights", and the connection between ownership and user ID is immutable. It is linked and managed on the intermediate table. In this case, a viewing button is provided on a page such as my page that can be accessed only by the owner.
  • the user ID is associated with the intermediate table, and the intermediate table is associated with digital content such as event moving images to be distributed.
  • the purpose of this disclosure is to provide a ticket management system that can ensure the liquidity of electronic tickets for online events.
  • a ticket management program is a program that is executed by a ticket management system that includes a processor and manages electronic tickets for goods, services, and various benefits provided incidental thereto, wherein the processor a step of acquiring a user ID that identifies a user; A program for executing a step of mutably associating IDs and storing them in a database.
  • FIG. 1 is a block diagram showing the configuration of a ticket system according to a first embodiment
  • FIG. 2 is a block diagram showing the configuration of a user terminal according to the first embodiment
  • FIG. 2 is a block diagram showing the configuration of a ticket management server according to the first embodiment
  • FIG. 3 is a diagram showing an example of data structures of a user database, a ticket database, and a content database stored by the ticket management server
  • FIG. 4 is a flowchart of user registration processing according to the first embodiment
  • 4 is a flowchart of ticket issuing processing according to the first embodiment
  • 6 is a flowchart of transfer processing according to the first embodiment
  • It is a flow chart of ticket inspection processing of a 1st embodiment.
  • FIG. 12 is a block diagram showing the configuration of a ticket management ledger according to the second embodiment
  • FIG. 11 is a diagram illustrating the configuration of an external server and a ticket management ledger according to the second embodiment
  • FIG. 10 is a diagram showing an example of data structures of a user database, a ticket database, and a content database managed in the second embodiment
  • FIG. FIG. 12 is a block diagram showing the configuration of a ticket management ledger according to the second embodiment
  • FIG. 11 is a diagram illustrating the configuration of an external server and a ticket management ledger according to the second embodiment
  • FIG. 10 is a diagram showing an example of data structures of a user database, a ticket database, and a content database managed in the second embodiment
  • FIG. 13 is a diagram showing another configuration example of the ticket management ledger of the second embodiment; It is a block diagram which shows the structure of the ticket system of 3rd Embodiment.
  • FIG. 13 is a diagram illustrating the configuration of an external server and a ticket management ledger according to the third embodiment; It is a figure which shows an example of the data structure of the user database, ticket database, and event database which are managed in 3rd Embodiment.
  • FIG. 10 is a diagram showing a configuration example in which digital content as a privilege is set in an electronic ticket;
  • FIG. 1 is a block diagram showing the configuration of a ticket management system 1 of this embodiment.
  • the ticket management system 1 is a system that manages electronic tickets (hereinafter simply referred to as tickets) relating to goods and services, and various benefits provided accompanying them.
  • An electronic ticket is an electronic certificate that certifies the right to purchase or receive goods, services, and various benefits (hereafter referred to as content in this explanation, and in particular, content realized by electronic media is referred to as digital content). is. Possession of the electronic ticket proves that payment has been made.
  • an electronic ticket which is a certificate relating to the right to view an online event via an electric communication line, will be described.
  • the ticket management system 1 includes a user terminal 10 and a ticket management server 20 .
  • the user terminal 10 and the ticket management server 20 are connected via a network (for example, the Internet or an intranet) NW.
  • NW a network
  • a plurality of user terminals 10 are connected to the ticket management server 20 according to the number of users.
  • the user terminal 10 is an information processing device.
  • the user terminal 10 is configured to request ticket data related to an online event distributed (held) in an online environment or held in the server space from the ticket management server 20 .
  • the user terminal 10 can also be called a ticket purchase terminal.
  • Digital content managed by the ticket management system 1 according to the first embodiment includes videos of online events, movies provided online, videos of various broadcasts, electronic comics, electronic books, and various other content provided via digital communication. contains the content of
  • the information processing device is, for example, a smartphone, a tablet terminal, a personal computer, a server computer (for example, a web server, an application server, a database server, or a combination thereof), a wearable device (for example, a smart watch, or a smart glasses), etc.
  • the user terminal 10 will be described using a smart phone, which is a mobile computer connectable to the network NW, as an example.
  • Ticket data is information about a ticket.
  • ticket data includes information that identifies the ticket, information about the authority that the ticket certifies (e.g., information about the online event covered by the ticket), the name of the ticket owner, information about the ticket owner (such as user ID), or a combination thereof, or code information encoding them (eg, a QR code, or other one- or two-dimensional code).
  • a ticket is an image of ticket data (that is, an electronic ticket) displayed on the user terminal 10 held by the user.
  • the ticket management server 20 is an information processing device.
  • the ticket management server 20 is configured to issue a ticket (that is, issue ticket data) in response to a request from the user terminal 10 . Further, the ticket management server 20 is configured to manage issued ticket data.
  • FIG. 2 is a block diagram showing the configuration of the ticket purchase terminal of this embodiment.
  • the user terminal 10 includes a storage device 11, a processor 12, an input/output interface 13, and a communication interface 14.
  • User terminal 10 is connectable to at least one of input device 15 and output device 16 .
  • the storage device 11 is configured to store programs and data.
  • the storage device 11 is, for example, a combination of ROM (Read Only Memory), RAM (Random Access Memory), and storage (eg, flash memory or hard disk).
  • Programs include, for example, the following programs. ⁇ OS (Operating System) program ⁇ Application (for example, web browser) program that executes information processing
  • the data includes, for example, the following data. ⁇ Databases referenced in information processing ⁇ Data obtained by executing information processing (that is, execution results of information processing)
  • the processor 12 is configured to implement the functions of the user terminal 10 by activating programs stored in the storage device 11 .
  • Processor 12 is an example of a computer.
  • the input/output interface 13 acquires signals (e.g., user instructions, sensing signals, or combinations thereof) from the input device 15 and outputs signals (e.g., image signals, audio signals, or combinations thereof) to the output device 16. ).
  • signals e.g., user instructions, sensing signals, or combinations thereof
  • signals e.g., image signals, audio signals, or combinations thereof
  • the input device 15 is, for example, a keyboard, pointing device, touch panel, physical button, sensor (eg camera, vital sensor, or a combination thereof), or a combination thereof.
  • the output device 16 is, for example, a display, a speaker, a printer, or a combination thereof.
  • the communication interface 14 is configured to control communication between the user terminal 10 and an external device (for example, the ticket management server 20).
  • FIG. 3 is a block diagram showing the configuration of the ticket management server 20 of this embodiment.
  • the ticket management server 20 includes a storage device 21, a processor 22, an input/output interface 23, and a communication interface 24.
  • the ticket management server 20 is connectable with at least one of an input device 25 and an output device 26 .
  • the storage device 21 is configured to store programs and data.
  • Storage device 21 is, for example, a combination of ROM, RAM, and storage (eg, flash memory or hard disk).
  • Programs include, for example, the following programs. ⁇ OS program ⁇ Application program that executes information processing
  • the data includes, for example, the following data. ⁇ Databases referenced in information processing ⁇ Execution results of information processing
  • the processor 22 is configured to implement the functions of the ticket management server 20 by activating the programs stored in the storage device 21 .
  • Processor 22 is an example of a computer.
  • Input/output interface 23 acquires signals (e.g., user instructions, sensing signals, or combinations thereof) from input device 25 and outputs signals (e.g., image signals, audio signals, or combinations thereof) to output device 26 . ).
  • signals e.g., user instructions, sensing signals, or combinations thereof
  • signals e.g., image signals, audio signals, or combinations thereof
  • the input device 25 is, for example, a keyboard, pointing device, touch panel, sensor, or a combination thereof.
  • the output device 26 is, for example, a display, a speaker, or a combination thereof.
  • the communication interface 24 is configured to control communication between the ticket management server 20 and an external device (eg, the user terminal 10).
  • ticket-related data requested by a user to be obtained is associated with a changeable user ID as an owner ID that identifies the owner of the ticket, and stored in a database.
  • the acquisition request includes the following aspects. ⁇ Purchase of tickets by users ⁇ Granting of tickets as benefits for the purchase of other tickets or related goods ⁇ Granting of tickets as benefits when other certain conditions are met
  • the unused portion of the tickets purchased by the user will be transferred to other users as necessary.
  • a user can purchase a plurality of tickets when purchasing a ticket, and separately transfer at least a portion of the purchased tickets to another user.
  • Other users receive the ticket data using communication means via message tools such as e-mail and SNS.
  • a viewing button for starting viewing of digital content (hereinafter simply referred to as content), which is the content of the online event, is displayed.
  • content which is the content of the online event.
  • the user displays the face of the ticket owned by the user on the display of the user terminal 10, and taps or clicks the viewing button included in the face of the ticket, thereby viewing the digital content related to the online live.
  • FIG. 4 is a diagram showing an example of the data structure of the user database, ticket database, and content database stored by the ticket management server 20. As shown in FIG. 4
  • the user database includes a "user ID” field, a "login PASS” field, a "user name” field, a "user attribute” field, a "contact” field, and a "payment method”. field and .
  • a user ID is stored in the "user ID" field.
  • a user ID is information for identifying a user.
  • the "login PASS" field stores information about the login password that the user is required to enter when logging into the ticket management server 20.
  • the "user name” field stores the name of the user corresponding to the user ID.
  • the "user attribute” field stores information indicating the attribute of the user corresponding to the user ID.
  • User attributes include age, date of birth, gender, occupation, nationality, area of residence (address), or a combination thereof.
  • the "contact information” field stores information indicating the contact information of the user corresponding to the user ID.
  • Contact information may be, for example, an email address, phone number, account information for a Social Networking Service (SNS) or other messaging-enabled application, or a combination thereof.
  • SNS Social Networking Service
  • Contact information is not limited to the examples given here and can include any type of information that can be used to send real-time notifications to viewers via user terminal 10 .
  • the "payment method” field stores information about the payment method used by the user corresponding to the user ID to make an electronic payment when purchasing a ticket. Payment methods Credit card payment, payment by direct debit, payment by various electronic payment applications, etc. are included.
  • Ticket data is stored in the ticket database shown in FIG. 4B.
  • the ticket database includes a "ticket ID” field, a “content ID” field, an "owner ID” field, a “transfer status” field, and a "usage status” field.
  • the "ticket ID" field stores the ticket ID.
  • a ticket ID is information for identifying a ticket.
  • the "content ID” field stores the content ID that indicates the content of the online event corresponding to the ticket ID.
  • the "owner ID" field stores the user ID that indicates the owner of the ticket corresponding to the ticket ID.
  • a ticket holder is primitively a ticket purchaser. The ticket owner can be changed to the transfer destination user by transfer after purchasing the ticket.
  • a book database may be provided together with the ticket database.
  • the book database stores a book ID indicating a book ID that treats a plurality of electronic tickets as one spelling, and an owner ID indicating the book ID. If a book database is provided, the ticket database will include a "book ID" field for storing book IDs instead of the "owner ID” field.
  • Various types of information used to specify a ticket ID, such as the book ID, are called ticket-related data.
  • Ticket-related data includes, for example: ⁇ Ticket ID ⁇ Book ID (an ID specified as an intermediate step to specify the ticket ID) ⁇ Management ledger ID (ID that identifies the management ledger in which the ticket ID is stored)
  • the management ledger ID may be used, for example, when managing the owner of the ticket using a blockchain, which is a distributed management ledger.
  • the ticket-related data is not limited to the above-described book ID, and also includes data specifying the ticket ID with a hierarchical data structure. That is, the ticket-related data is not limited by the data structure, and includes various data groups held to identify the ticket ID.
  • the "transfer status" field stores information indicating the transfer history of the ticket corresponding to the ticket ID.
  • the transfer history includes, for example, "before transfer” and "after transfer”. Transferring the ticket updates the status.
  • information indicating the number of times of transfer may be managed. In the ticket management system 1, it is possible to limit the number of times a ticket can be transferred based on the transfer status. That is, a setting can be made so that a ticket that has already been transferred (or a ticket that has already been transferred N times) cannot be transferred again.
  • the "usage status” field stores information indicating the usage status of the ticket corresponding to the ticket ID.
  • the usage status of the ticket includes "before use” and “after use”. After the ticket is stolen, the ticket status is rewritten to "used".
  • the content database shown in FIG. 4C stores information about contents.
  • the content database includes a "content ID” field, an "event name” field, an "operating company” field, an "event type” field, a “performer” field, and a "distribution start date and time.” , a 'delivery end date and time' field, and a 'content address' field.
  • a content ID is stored in the "content ID" field.
  • a content ID is information for identifying various types of content.
  • the "event name” field stores the event name.
  • the event name is information indicating the name of the online event identified by the content ID.
  • Information about the operating company is stored in the "operating company" field.
  • the information about the operating company is information indicating the operating company of the event identified by the content ID.
  • the information about the operating company may include the name of the operating company, the location of the operating company, and the contact information of the person in charge.
  • Event type Information about the event type is stored in the "event type" field.
  • the information about the event type is information indicating an overview of the online event identified by the content ID. For example, event types include “online live”, “online manzai”, and “online fan exchange meeting”.
  • Performer information is stored in the "Performer" field.
  • the performer information is information indicating performers for the online event identified by the content ID.
  • Performer information includes individuals or groups (group names, team names, combination names, unit names, band names, etc.).
  • the "delivery start date and time” field stores the delivery start date and time.
  • the distribution start date and time is information indicating the date and time when distribution of the content of the online event identified by the content ID is started. That is, the distribution start date and time indicates the first date and time when the content can be viewed.
  • the "delivery end date and time” field stores the delivery end date and time.
  • the delivery end date and time is information indicating the date and time when the delivery of the content of the online event identified by the content ID ends. That is, the delivery start date and time indicates the last date and time when the content can be viewed.
  • a content address is stored in the "content address" field.
  • the content address is information that can identify the digital content, such as the address of the server where the content of the online event identified by the content ID is stored. By accessing the address, the content can be distributed.
  • FIG. 5 is a flowchart of user registration according to this embodiment. As shown in FIG. 5, first, by operating the user terminal 10, the user inputs attribute information such as name and registration information including payment information to apply for user registration (step S100).
  • attribute information such as name and registration information including payment information to apply for user registration (step S100).
  • the ticket management server 20 accepts an application for user registration (step S101). After step S101, the ticket management server 20 issues a user ID and a login password (step S102). At this time, the ticket management server 20 records the registration information input by the user, the user ID and password as a new record in the user database.
  • step S102 the user terminal 10 receives the issued user ID and login password (step S103). With the above, the user registration processing ends.
  • FIG. 6 is a flowchart of the ticket issuing process of this embodiment.
  • the user terminal 10 accepts a purchase operation (S110).
  • the processor 12 receives, via the input/output interface 13 , an operation related to purchase made on the input device 15 .
  • the user can select the tickets to be purchased and input the number of tickets to be purchased as an operation related to purchase.
  • An operation related to purchase may include, for example, inputting a user ID, selecting an event, selecting a date and time, specifying the number of tickets to purchase, pressing a purchase button (button object or physical button), or a combination thereof.
  • the user terminal 10 issues a ticket issue request (S111).
  • processor 12 generates a ticket issuance request by referring to the content of the purchase operation received in step S110.
  • the ticket issuance request includes, for example, information specifying the type of ticket requested to be issued (for example, information specifying performance, date and time, and seat type).
  • the processor 12 transmits a ticket issue request to the ticket management server 20 via the communication interface 14 .
  • the ticket management server 20 performs ticket issuing processing (step S112). Specifically, the processor 22 of the ticket management server 20 allocates tickets to be sold based on the purchase information transmitted from the user terminal 10 . Processor 22 acquires the transmitted user ID. The processor 12 also acquires ticket data of a ticket that the user wishes to purchase.
  • the ticket management server 20 updates the ticket database (S113). Specifically, the processor 22 newly registers and stores the user ID included in the ticket issuance request in the ticket database in association with the unissued ticket ID. The user ID can be changed in the ticket database. This makes it possible to identify the owner of the ticket based on the ticket ID.
  • the processor 12 associates the ticket data with information that can identify the digital content and stores the ticket data in the database. Specifically, the content ID of the content database is newly registered in the ticket database.
  • the ticket management server 20 provides ticket data (S114). Specifically, the processor 22 generates ticket data by referring to the updated contents of the database in step S113.
  • the ticket data includes the ticket ID newly registered in step S113. Additionally, the ticket data may include at least one of the ticket holder's user IDs. Some or all of the information contained in the ticket data may be encoded in, for example, a QR code or other code information.
  • Processor 22 provides the generated ticket data to the ticket owner. As an example, processor 22 transmits to user terminal 10 via communication interface 24 .
  • step S114 the user terminal 10 saves the ticket data (S115). Specifically, the processor 12 obtains the ticket data provided in step S114. The processor 12 stores the acquired ticket data in the storage device 11 . This allows the processor 12 to display the ticket data as desired. With the above, the ticket issuing process is completed.
  • FIG. 7 is a flowchart of transfer processing according to the present embodiment.
  • the user who wants to transfer part or all of the tickets to be purchased logs in with the user ID and login PASS, and then inputs information about the transfer and instructs the transfer (step S120). .
  • the user specifies the ticket to be transferred according to a predetermined input format.
  • the event to be ticketed and the number of tickets may be specified.
  • the information of the user to whom the ticket is to be transferred is input.
  • the transferee of the ticket may be designated by designating the contact information of the message tool of the user who will be the transferee.
  • the ticket management server 20 accepts a transfer instruction (step S121). Specifically, the ticket management server 20 receives transfer instruction information via the communication interface 24 .
  • the ticket management server 20 confirms the transfer instruction (step S122). Specifically, the processor 22 of the ticket management server 20 identifies the ticket ID of the ticket to be transferred and the transferee of the ticket.
  • the ticket management server 20 updates the ticket database (step S123). Specifically, the processor 22 of the ticket management server 20 updates the ticket database using the ticket ID of the identified ticket to be transferred and the information on the transferee of the ticket. At this time, the user database is referred to identify the owner ID of the new owner, and the "owner ID" field of the ticket database is updated. As a result, the owner ID of the transferred ticket is rewritten to the transferee. Processor 22 also updates the transfer status in the ticket database. After the ticket is transferred, the ticket data of the ticket is not displayed on the user terminal 10 of the user who transferred the ticket.
  • the ticket management server 20 transmits the ticket data (step S124). Specifically, the processor 22 generates ticket data by referring to the updated contents of the database in step S123. Additionally, the ticket data may include the ticket owner's user ID. Some or all of the information contained in the ticket data may be encoded in, for example, a QR code or other code information. Processor 22 provides the generated ticket data to the ticket assignee. As an example, processor 22 transmits to another user terminal 10 that is the assignee via communication interface 24 . At this time, the processor 22 issues the URL created using the ticket data to the contact information of the transferee's message tool.
  • step S125 another user terminal 10 receives the ticket data (step S125).
  • the processor 12 in the other user terminal 10 acquires the ticket data provided in step S124. Specifically, the URL sent from the processor 22 is clicked to obtain the ticket data.
  • the processor 12 stores the acquired ticket data in the storage device 11 . This allows the processor 12 to display the ticket data as desired.
  • the ticket receiving operation shown in step S125 may be omitted.
  • the user who transfers the ticket designates the contact information of the transferee, such as the transferee's email address or telephone number, and unilaterally owns the ticket without accepting the transferee's explicit receipt operation.
  • a process to change the person to the transferee may be performed. In this case, if necessary, the transferee may be notified that the ownership of the ticket has been transferred (that the ticket has been transferred). With the above, the transfer processing ends.
  • FIG. 8 is a flow chart of the ticket inspection process of this embodiment.
  • the user viewing the online event operates the user terminal 10 to give a viewing instruction (step S130). Specifically, the processor 12 of the user terminal 10 causes the user terminal 10 to display the ticket face of the ticket data stored in the storage device 11 in response to the viewer's instruction to display the ticket face. At this time, a viewing button is displayed on the face of the ticket. The viewer presses the displayed viewing button.
  • step S130 the ticket management server 20 executes ticket identification (S131).
  • the ticket management server 20 determines whether viewing is possible (S132). Specifically, the processor 22 refers to the ticket data read in step S130 to determine whether or not the viewer can view the program. Specifically, the ticket database is queried for the ticket data for which the viewing button has been pressed, and it is determined whether or not the ticket data is proper ticket data with viewing authority.
  • step S132 if the read ticket data is not appropriate ticket data, or if the identity of the viewer and the ticket owner cannot be confirmed, the ticket management server 20 executes viewing error processing.
  • step S132 if the read ticket data is appropriate ticket data and if the identity of the viewer and the ticket owner could be confirmed, the ticket management server 20 detects the use of the ticket (S135), a so-called " Execute "Migiri processing".
  • Processor 22 may create or update the check-in list during step S133.
  • the check-in list is information relating to a result list of the ticket inspection process for each viewer.
  • the check-in list includes at least one of the following elements as an example. ⁇ Viewing start time ⁇ Ticket ID of the ticket used by the viewer ⁇ User ID associated with the ticket ID - User name associated with user ID - Result of determination of whether or not viewing is permitted (step S133) (viewing permission/viewing refusal)
  • the ticket management server 20 changes the display mode of the ticket as the ticket is used (step S134). Specifically, for example, a stamp image indicating that the ticket has been used is added to the ticket surface, the ticket surface is illuminated, the color of the ticket surface is changed, and the like. Further, as a change in the display form of the ticket face, information regarding viewing conditions may be displayed on the ticket face upon detection of tearing. The viewing conditions in an online event indicate the position of the camera that captures the stage, the angle with respect to the stage, or the sound quality of the reproduced sound. After step S134, the display of the face of the ticket displayed on the user terminal 10 changes (step S135).
  • the ticket management server 20 guides the content data (step S136). Specifically, the content ID associated with the ticket ID is referenced from the content database, and the user terminal 10 is connected to the content address corresponding to the content ID.
  • step S136 the user terminal 10 reproduces the content (step S137). Specifically, the processor 12 of the user terminal 10 causes the user terminal 10 to reproduce the content saved at the content address. Thus, the ticket inspection process is completed.
  • FIG. 9 is a diagram showing a first screen example and a second screen example.
  • the first screen example shown in FIG. 9A is an example screen when purchasing a ticket.
  • the event content, price, and purchase quantity are displayed. The purchase is made by the user entering the quantity and applying for purchase.
  • the second screen example shown in FIG. 9B is a screen example for displaying ticket data for which ticketing has been completed.
  • a viewing button symbol A
  • Viewing is started by pressing the viewing button after the distribution start date and time.
  • a transfer instruction button symbol B
  • the screen transitions to a screen for selecting the contact information of another user to be the transfer destination.
  • the display can be switched for each owned ticket. Note that this screen example describes a user interface that transfers tickets for each ticket, but a user interface that allows the user to specify the event for which the ticket is to be transferred and then the number of tickets to be transferred is adopted. You may
  • the user ID is stored in association with the ticket data in a changeable manner, and the ticket data is stored in association with the content data. Therefore, the owner of the ticket can be changed by changing the user ID.
  • the ticket can be arbitrarily transferred by the owner. By doing so, it is possible to secure the liquidity of tickets.
  • unused electronic tickets can be individually transferred in the same way as paper tickets, improving the experience of electronic ticket purchasers. For example, you can purchase an electronic ticket for a friend or family member together with your own electronic ticket, or you can gift an electronic ticket to an acquaintance if you have to give up watching an online live performance due to urgent business. In this way, it becomes possible to transfer electronic tickets, and by securing the circulation of tickets, the management side has more options for marketing measures.
  • the ticket management system 1 accepts input of the number of tickets to be purchased as an operation related to ticket purchase, it is possible to give flexibility to the form of ticket purchase and improve convenience for the user.
  • the viewing button may be displayed on the surface of the electronic ticket.
  • the user can easily give an instruction to start viewing.
  • this display form of the viewing button is only an example, and for example, the viewing button may be displayed on the My Page associated with the user ID, or the viewing button may be displayed on both the face of the electronic ticket and the My Page. may In this case, viewing can be started by clicking the viewing button on My Page.
  • the use of the electronic ticket is detected in response to the user pressing the viewing button, so it is possible to reliably perform the tear-off process, which is the detection of use.
  • the ticket management system 1 changes the display mode of the child ticket according to the detection of the use of the ticket, so that the user can easily recognize whether the ticket has already been used.
  • the ticket management system 1 changes the user ID associated with the ticket data to another user to whom the ticket is to be transferred, according to the user's operation regarding the transfer of the ticket. This makes it possible to quickly change the owner of the ticket.
  • the ticket management system 1 accepts input of the number of electronic tickets to be transferred as an operation related to transfer, it is possible to give a degree of freedom to the form of ticket transfer, improving user convenience.
  • the ticket management system 1 transmits information on electronic tickets that are the target of operations related to transfer to other users using telecommunication lines.
  • the ticket can be easily and reliably transferred using communication means such as e-mail.
  • the ticket management system 2 uses blockchain to manage electronic tickets. That is, the ticket management system 2 manages each data included in the ticket database on the block chain for each ticket ID.
  • the user terminal 10 and the ticket management server 30 in the ticket management system 2 are connected to the ticket management ledger 40 via the network NW.
  • the ticket management server 30 stores a user database and a content database
  • the ticket management ledger 40 stores a ticket database.
  • FIG. 11 is a diagram showing the configuration of the ticket management ledger 40. As shown in FIG.
  • the ticket management ledger 40 is a distributed system comprising signal processors 40A-40E functioning as nodes.
  • the signal processing devices 40A to 40E are, for example, personal computers each connected to a network.
  • the network may be a LAN, or a public network such as the Internet or a communication network provided by a telecommunications carrier.
  • the signal processing devices 40A to 40E are connected to a network, for example, by wire or wirelessly.
  • the signal processors 40A-40E communicate with each other using a peer-to-peer scheme.
  • the signal processing devices 40A to 40E implement the ticket management ledger 40 using blockchain technology. Further, the signal processing devices 40A to 40E, for example, the signal processing device 40A of any one of the signal processing devices 40A to 40E, acquires data relating to ticket transactions to be recorded. The signal processing device 40A creates a block containing the acquired data and adds it to the blockchain. The signal processing device 40A transmits the added block information to the other signal processing device 40A. The other signal processors 40B-40E verify the correctness of the received blocks and add them to the blockchain once the correctness is verified. The signal processors 40A-40E determine the block chain according to, for example, the number of blocks to be linked (the number of approvals). As a result, the same ticket management ledger 40 is saved in the signal processing devices 40A to 40E. Note that the stored data may be encrypted as appropriate.
  • the configuration of the ticket management ledger 40 is not limited to that shown in FIG.
  • the number of signal processing devices 40A included in the ticket management ledger 40 may be any number as long as it is two or more.
  • the signal processing device 40A includes a storage device 41, a processor 42, an input/output interface 43, and a communication interface 44.
  • the signal processing device 40A is connectable with at least one of the input device 45 and the output device 46 .
  • the storage device 41 is configured to store programs and data.
  • the storage device 41 is, for example, a combination of ROM (Read Only Memory), RAM (Random Access Memory), and storage (eg, flash memory or hard disk).
  • Programs include, for example, the following programs. ⁇ OS (Operating System) program ⁇ Application (for example, web browser) program that executes information processing
  • the data includes, for example, the following data. ⁇ Databases referenced in information processing ⁇ Data obtained by executing information processing (that is, execution results of information processing)
  • the processor 42 is configured to realize the functions of the signal processing device 40A by activating the program stored in the storage device 41.
  • Processor 42 is an example of a computer.
  • Input/output interface 43 acquires signals (e.g., user instructions, sensing signals, or combinations thereof) from input device 45 and outputs signals (e.g., image signals, audio signals, or combinations thereof) to output device 46 . ).
  • signals e.g., user instructions, sensing signals, or combinations thereof
  • signals e.g., image signals, audio signals, or combinations thereof
  • the input device 45 is, for example, a keyboard, pointing device, touch panel, physical button, sensor (eg camera, vital sensor, or combination thereof), or a combination thereof.
  • the output device 46 is, for example, a display, a speaker, a printer, or a combination thereof.
  • the communication interface 44 is configured to control communication between the signal processing device 40A and an external device (eg, at least one of the user terminal 10 and the ticket management server 30).
  • an external device eg, at least one of the user terminal 10 and the ticket management server 30.
  • the ticket management server 30 shown in FIG. 10 includes at least a storage unit and a communication interface.
  • the ticket management server 30 is a server device realized by distributed applications (DApps), for example.
  • the ticket management server 30 is connected to a content management server 50 storing digital content.
  • the content management server 50 is managed by, for example, a content management company that manages digital content. Specifically, a management server that manages electronic books published by a publisher (content management company) corresponds to the content management server 50 .
  • the communication interface is configured to control communication between the ticket management server 30 and an external device (at least one of the user terminal 10 and the ticket management ledger 40).
  • the ticket management server 30 may realize the functions of the ticket management server 30 .
  • the ticket management ledger 40 is associated with the digital content of the content management server 50 via the content database recorded in the ticket management server 30.
  • the ticket management ledger 40 is implemented by a blockchain, which is a distributed management ledger.
  • electronic tickets are managed by a distributed management ledger.
  • the ticket can refer to the transaction history associated with the transfer of ownership, which will be described later. By referring to all transaction histories related to a certain ticket, the owner of the ticket can be identified.
  • a blockchain is composed of blocks that constitute contract data, and blocks that contain at least hash values and transaction data. As tickets are transferred between users, new transaction data is generated and new blocks are added after verification by the signal processing devices 40A to 40E shown in FIG.
  • the blockchain uses a public blockchain and a private blockchain. For normal transactions, the transaction history is recorded on the private blockchain, and the latest information is periodically reflected on the public blockchain.
  • the configuration may be such that there are multiple hierarchies.
  • the ticket management system 2 manages at least a user database, a ticket database, and a content database.
  • the user database shown in FIG. 13A has the same configuration as that of the first embodiment, and thus the description thereof is omitted.
  • the ticket database shown in FIG. 13B includes a "ticket ID” field, a “content ID” field, an “owner ID” field, a “browsing status” field, and a “loan status” field.
  • the "ticket ID” field stores the ticket ID.
  • a ticket ID is information for identifying a ticket.
  • the ticket ID also works with the ledger ID that indicates the blockchain address.
  • the "content ID” field stores the ID of the content indicating the content of the electronic comic corresponding to the ticket ID.
  • the "owner ID" field stores the user ID that indicates the owner of the ticket corresponding to the ticket ID.
  • a ticket holder is primitively a ticket purchaser. The ticket owner can be changed to the transfer destination user by transfer after purchasing the ticket.
  • the "browsing status” field stores information indicating whether or not the user has already browsed. If it has been viewed, the status is "viewed", and if it has not been viewed yet, it is "before viewing”. When the status is "viewed”, for example, the book is treated like a used book, and a lower price may be set for transfer to another user. Also, the following functions may be implemented depending on the viewing status. ⁇ If the status becomes "viewed”, it will not be possible to transfer it after that ⁇ If the status becomes "viewed”, the content that can be viewed will be restricted (limited content that can only be viewed in the state before viewing becomes unviewable, etc.) ⁇ When the status becomes "viewed", the displayed content changes (e.g., changing the value by displaying that it has been viewed)
  • the "loan status” field stores information indicating whether or not the user who owns the electronic comic has lent it to another user. If it is lent to another user, the status becomes “on loan”, and if it is not lent to another user, the status becomes "not lent". When the lending status is "on loan”, the user who owns the electronic comic cannot view the loaned electronic comic.
  • the content database includes a "content ID” field, a "comic title” field, a “publisher” field, a “type” field, an "author” field, and a “publication date” field. , a “rental terms” field and a “contents address” field.
  • a content ID is stored in the "content ID" field.
  • the content ID is information for identifying various types of electronic comic content.
  • the "comic title” field stores the work title of the electronic comic corresponding to the content ID.
  • the "publisher” field stores information about the publishing company that publishes the electronic comic corresponding to the content ID.
  • the publication of electronic comics refers to the act of editing and reviewing the contents of electronic comics, putting them on electronic media, and releasing them to the market.
  • the information about the publisher may include the name of the publisher, the location of the publisher, and the contact information of the person in charge.
  • Information on the type of electronic comic corresponding to the content ID is stored in the "comic type” field.
  • comic types in addition to types based on assumed user groups such as “boy comics”, “girl comics”, “youth magazines”, “history”, “sports”, “school stuff”, “romance”, etc. , information indicating the main theme in the content of the electronic comic.
  • the "author” field stores information about the author of the electronic comic corresponding to the content ID.
  • the information about the author may include the author's personal information such as the real name in addition to the pseudonym.
  • the "publication date” field stores the publication date of the electronic comic corresponding to the content ID, that is, the distribution start date. After the date of publication, the user can purchase and view the electronic comic.
  • the "resale conditions" field stores information about conditions (usage conditions) such as price when the electronic comic corresponding to the content ID is used secondarily by resale.
  • Use of electronic comics includes purchases from publishers and purchases by resale from other users. That is, the purchase price stored as the resale condition may include a resale price when reselling an electronic comic once viewed to another user in addition to the price when newly purchasing from a publisher.
  • Motives for purchasing electronic comics by resale include the fan psychology of wanting to obtain the limited number of first edition bound electronic comics or electronic comics with special benefits.
  • resale conditions information such as "no resale” that prohibits resale or information about "usage period" for content that can be viewed for a limited time may be stored. Also, when the number of lending times exceeds a predetermined number of times, resale may be permitted. Note that resale conditions may be set for each ticket ID in the ticket database.
  • the "rental conditions" field stores various conditions (usage conditions) required when a user who has purchased an electronic comic corresponding to a content ID makes secondary use such as lending it to another user.
  • Various conditions required for lending include a fee for lending, a loan amount, a lending period, a date and time when lending is possible, and the like.
  • a condition for prohibiting lending in the first place may be stored. Note that the lending conditions may be set for each ticket ID in the ticket database.
  • the "content address” field stores information about the address on the content management server 50 where the content data, which is the content of the electronic comic corresponding to the content ID, is stored.
  • a content address is information that can specify a digital content. By accessing the address, the content can be distributed.
  • the ticket management server 30 issues a data update instruction to the ticket management ledger 40 at the timing when the data in the ticket database needs to be updated. As a result, the information of the ticket database in the ticket management ledger 40 is updated, and the owner of the ticket is updated.
  • FIG. 14 is a diagram showing another structural example of content data.
  • the content data according to the modification is stored in the ticket management ledger as part of the blockchain.
  • digital content and ticket database information are recorded in the ticket management ledger, which is a blockchain.
  • the ticket management system 3 uses blockchain to manage electronic tickets for concerts held at actual event venues. That is, the ticket management system 3 manages electronic tickets related to content (events) that do not correspond to digital content on the blockchain. Therefore, the ticket management system 3 manages each data included in the ticket database on the block chain for each ticket ID.
  • the user terminal 10 and the ticket management server 30 in the ticket management system 3 are connected to the ticket management ledger 40 and the administrator terminal 60 via the network NW.
  • the ticket management server 30 stores a user database and a content database
  • the ticket management ledger 40 stores a ticket database. Since the configuration of the ticket management ledger 40 is the same as that of the second embodiment, the description thereof will be omitted.
  • the administrator terminal 60 is a terminal operated by an administrator who manages electronic tickets using the ticket management server 30 .
  • the ticket management server 30 shown in FIG. 15 includes at least a storage unit and a communication interface.
  • the ticket management server 30 is a server device realized by distributed applications (DApps), for example.
  • the communication interface is configured to control communication between the ticket management server 30 and an external device (at least one of the user terminal 10 and the ticket management ledger 40). Note that the ticket management server 30 may realize the functions of the ticket management server 30 .
  • the ticket management ledger 40 is associated with the content database recorded in the ticket management server 30.
  • the ticket management ledger 40 is implemented by a blockchain, which is a distributed management ledger.
  • electronic tickets are managed by a distributed management ledger.
  • the ticket can refer to the transaction history associated with the transfer of ownership, which will be described later. By referring to all transaction histories related to a certain ticket, the owner of the ticket can be identified.
  • a blockchain is composed of blocks that constitute contract data, and blocks that contain at least hash values and transaction data. As tickets are transferred between users, new transaction data is generated and new blocks are added after verification by each node.
  • the blockchain uses a public blockchain and a private blockchain. For normal transactions, the transaction history is recorded on the private blockchain, and the latest information is periodically reflected on the public blockchain.
  • the configuration may be such that there are multiple hierarchies.
  • the ticket management system 3 manages at least a user database, a ticket database, and a content database.
  • the user database shown in FIG. 17A has the same configuration as that of the first embodiment, and thus the description thereof is omitted.
  • the ticket database includes a "ticket ID” field, an "event ID” field, an "owner ID” field, a "transfer status” field, a “usage status” field, and a “transfer condition” field. ” field.
  • the "ticket ID" field stores the ticket ID.
  • a ticket ID is information for identifying a ticket.
  • the "event ID” field stores the ID of the event corresponding to the ticket ID.
  • the "owner ID" field stores the user ID that indicates the owner of the ticket corresponding to the ticket ID.
  • a ticket holder is primitively a ticket purchaser. The ticket owner can be changed to the transfer destination user by transfer after purchasing the ticket.
  • the "transfer status" field stores information indicating the transfer history of the ticket corresponding to the ticket ID.
  • the transfer history includes, for example, "before transfer” and "after transfer”. Transferring the ticket updates the status.
  • information indicating the number of times of transfer may be managed. In the ticket management system 1, it is possible to limit the number of times a ticket can be transferred based on the transfer status. That is, a setting can be made so that a ticket that has already been transferred (or a ticket that has already been transferred N times) cannot be transferred again.
  • the "usage status” field stores information indicating the usage status of the ticket corresponding to the ticket ID.
  • the usage status of the ticket includes "before use” and “after use”. After the ticket is stolen, the ticket status is rewritten to "used".
  • the “transfer condition” field stores a condition (usage condition) set for secondary use by transfer of the electronic ticket corresponding to the ticket ID.
  • the conditions regarding the transfer of the electronic ticket refer to the conditions set in advance regarding the transfer of the electronic ticket, and include, for example, the following.
  • the predetermined action is, for example, related to the event Includes actions that contribute to sales promotion of the event, such as writing comments, spreading information about the event on SNS (tweeting, etc.), purchasing goods at the event site, and visiting a specific booth within the event site.
  • the content database includes an "event ID” field, an "event name” field, an "operating company” field, an "event type” field, a “performer” field, and an "event venue” field. field, "Date” field, and "Terms of Transfer” field.
  • the "event ID” field stores an ID that identifies the event.
  • the "event name” field stores the name of the event corresponding to the event ID.
  • the event name is information indicating the name of the event identified by the content ID.
  • the "Operating Company" field stores information about the event's operating company.
  • the information about the operating company is information indicating the operating company of the event identified by the content ID.
  • the information about the operating company may include the name of the operating company, the location of the operating company, and the contact information of the person in charge.
  • the "event type” field stores information about the type of event corresponding to the event ID.
  • event types include “Budokan Live”, “Tokyo Dome Performance”, and the like.
  • Performer information is stored in the "Performer" field.
  • the performer information is information indicating the performers of the event corresponding to the event ID.
  • Performer information includes individuals or groups (group names, team names, combination names, unit names, band names, etc.).
  • the "event venue” field stores the distribution start date and time.
  • the distribution start date and time is information indicating the date and time when distribution of the content of the online event identified by the content ID is started. That is, the distribution start date and time indicates the first date and time when the content can be viewed.
  • the date of the event corresponding to the event ID is stored in the "date" field.
  • the "transfer conditions" field stores the same items as the transfer conditions stored in the ticket database. That is, in the ticket database, ticket transfer conditions are set for each ticket, and in the content database, ticket transfer conditions are set for each event.
  • the ticket management server 30 issues a data update instruction to the ticket management ledger 40 at the timing when the data in the ticket database needs to be updated.
  • the ticket management server 30 updates the information in the ticket database in the ticket management ledger 40 and updates the owner of the ticket.
  • the ticket management server 30 instructs the ticket management ledger 40 to update the data.
  • the ticket management system 3 accepts operations related to setting and changing usage conditions from the administrator terminal. This allows the administrator to set the ticket transfer conditions for each ticket ID or each event ID. For example, the user can transfer (resell) the used electronic ticket to another user from the timing when the administrator approves the resale of the used electronic ticket.
  • the electronic ticket After the event is held, the electronic ticket will function as a proof of participation in the event. For this reason, possessing a used electronic ticket (especially an electronic ticket with a seat number) to which an electronic stamp has been affixed by the pick-up process is proof of an indirect relationship with the event. Even if you didn't actually participate in the event, it will inspire some fans to collect. For this reason, used electronic tickets after the event is held are subject to transaction.
  • the administrator has set the transfer of the used electronic ticket as a condition related to use, with the detection processing of the use of the electronic ticket as a trigger, the user can pick up the electronic ticket at the event venue. By doing this, this transfer condition is satisfied, and the transfer of the electronic ticket at a later date is permitted.
  • FIG. 18 is a diagram showing a configuration example in which digital content as a privilege is set in an electronic ticket.
  • the privilege content that is the privilege of the electronic ticket is stored in the ticket management ledger as part of the blockchain.
  • digital content and ticket database information are recorded in the ticket management ledger as a blockchain.
  • a management server that manages privilege content and a ticket management ledger 40 are linked via the ticket management server 30 .
  • a "privilege address" field is added to the content database, and a privilege that is uniformly given to electronic tickets related to the event ID is set.
  • a privilege may be set individually for each ticket ID.
  • the privilege contents include digital images, digital sound sources, digital videos, etc. related to the event.
  • the privilege content may be triggered by the detection of some process (for example, the use of the electronic ticket), and the content may be switched.
  • the digital content which was merely image data showing the surface of the electronic ticket until the electronic ticket was peeled off, detects that the electronic ticket has been peeled off, and is treated as a privilege. may be changed to other content data.
  • the privilege address itself shown in FIG. 18C may be changed, or the digital content data stored on the server corresponding to the privilege address may be changed.
  • the electronic tickets handled by the ticket management system are not limited to the above-mentioned online events, e-books, and tickets for events held at event venues.
  • Electronic tickets are, for example, sports competitions, other events such as game withdrawals, admission tickets to theme parks, tickets related to the use of transportation means, etc. It can be applied arbitrarily to anything related to benefits.
  • the electronic ticket may be free of charge, regardless of whether it is charged.
  • the storage device 11 of the user terminal 10 may be connected to the user terminal 10 via the network NW.
  • the storage device 21 of the ticket management server 20 may be connected to the ticket management server 20 via the network NW. Further, the storage device 21 of the ticket management server 20 may be composed of a plurality of storage devices.
  • the ticket inspection process described above may be performed by the ticket management server 20 alone as described above, or may be performed in cooperation with the ticket management server 20 and another device (for example, an external ticket inspection device).
  • the content is distributed to the viewer when the identity is confirmed.
  • the ticket management system 1 may distribute the content data when the viewing button is pressed without confirming the identity of the ticket owner and the viewer of the content data.
  • confirmation of the identity of the ticket owner and the viewer may be performed by personal authentication required when accessing the ticket data.
  • the identity of the ticket owner and the viewer may be confirmed by account information, SMS authentication, terminal ID authentication, etc. that the user inputs when displaying the ticket data.
  • the user ID and password are used for authentication.
  • other biometric feature amounts eg, fingerprint, palm print, iris, vein, myoelectric potential, etc.
  • User-specific information may also be acquired by other sensors such as infrared, RFID, sound wave, and laser type one-dimensional bar code readers. Further, it is also possible to determine whether or not the viewer can view the content using a plurality of types of feature amounts.
  • the feature amount can be acquired at the time of user registration.
  • the timing of acquiring the feature amount is not limited to this. For example, after the ticket is issued, a process of transitioning from the face of the ticket displayed on the user terminal 10 to a screen for inputting the feature amount may be performed. Also, after purchasing the ticket, before issuing the ticket, the feature quantity acquired by the user terminal 10 may be input.
  • the ticket is an authentication information carrier that carries authentication information.
  • the authentication information carrier may also be the viewer's biometric.
  • the authentication information carrier may be the viewer's face or the viewer's palm.
  • Such an authentication information carrier holds, as authentication information, information regarding the viewer's feature amount.
  • the ticket management server 30 can acquire the feature amount of the viewer and use the feature amount as a clue to identify the ticket ID that identifies the ticket purchased by the viewer. That is, the ticket database stores the biometric information (including the feature amount) of the user who purchased the ticket instead of the ticket ID.
  • the ticket management server 20 transmits ticket data to the user terminal 10 .
  • the ticket management server 20 may transmit resource information (for example, URL (Uniform Resource Locator)) for referencing the resource in which the ticket data is stored to the user terminal 10 .
  • the viewer can display the ticket data on the display of the user terminal 10 by accessing the resource indicated by the resource information using his/her own user terminal 10 .
  • some or all of the information included in the ticket data is coded into a two-dimensional code including, for example, a QR code (registered trademark), or other code information.
  • the ticket may include a QR code as the ticket ID and reference string.
  • the ticket ID may be associated with the owner ID and the owner feature amount, or only one of the owner ID or the owner feature amount may be associated with the ticket ID. That is, when purchasing or transferring a ticket, only one of the owner ID and the owner feature amount may be registered in the database.
  • the process of updating the ticket database by the operation of the transferring user has been described, but the ticket database may be updated in response to the receiving process by another user who is the transferee. In this case, the ownership of the ticket remains undetermined until another user performs the receiving process.
  • the user terminal 10 of the user who transfers the ticket may display that the status of the ticket is "transferred” (or “distributed") or "transferred” (or “distributed”). After that, the other user confirms the transfer according to the receipt process, and the user who transferred the ticket is in a state where the information about the ticket is not displayed.
  • the image of the face of the electronic ticket for a certain online live is not limited to one type, and may be of multiple types.
  • an object for example, a viewing start button or a transfer button
  • a user who has purchased multiple electronic tickets can: To surely use or keep an electronic ticket with a face of one's preference and to transfer the rest of the electronic ticket to an acquaintance.
  • the data managed as the owner ID is replaced by the user ID on the blockchain. It may be the user's wallet ID that can identify the user.
  • Appendix 1 A program to be executed by a ticket management system comprising a processor and managing electronic tickets for goods, services, and various benefits provided incidental to them, to the processor, obtaining a user ID that identifies the user; A step of correlating ticket-related data for identifying a ticket ID identifying an electronic ticket requested by a user to a changeable user ID as an owner ID identifying the owner of the ticket, and storing the data in a database. and the program that causes it to run.
  • (Appendix 2) The processor The program according to (Appendix 1), causing execution of a step of storing in a database the same number of ticket IDs as the number of tickets purchased and user IDs as owner IDs that are changeably associated with each other.
  • (Appendix 6) The processor The program according to any one of (Appendix 1) to (Appendix 5), which sets a condition regarding use of an electronic ticket for a ticket ID or content corresponding to the ticket ID.
  • (Appendix 10) Electronic tickets relate to the viewing of online events
  • the processor Any one of (Appendix 1) to (Appendix 9) according to any one of (Appendix 1) to (Appendix 9), wherein a step of displaying a viewing button for accepting input of an operation to start playing back digital content related to an online event to the user terminal on the face of the electronic ticket is executed. program.
  • a method performed by a ticket management system comprising a processor and managing electronic tickets for goods, services, and various benefits provided therewith, comprising: the processor obtaining a user ID that identifies the user; A step of correlating ticket-related data for identifying a ticket ID identifying an electronic ticket requested by a user to a changeable user ID as an owner ID identifying the owner of the ticket, and storing the data in a database. and the program to run.
  • a ticket management system comprising a processor and managing electronic tickets for goods, services, and various benefits provided therewith,
  • the processor means for acquiring a user ID that identifies a user;
  • a ticket management system comprising:
  • Ticket management system 10 Ticket purchase terminal 11 : Storage device 12 : Processor 13 : Input/output interface 14 : Communication interface 15 : Input device 16 : Output device 20 : Ticket management server 21 : Storage device 22 : Processor 23 : Input/output Interface 24: communication interface 25: input device 26: output device

Landscapes

  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

プロセッサを備え、商品、役務、およびそれらに付随して提供される各種の便益に関する電子チケットを管理するチケット管理システムに実行させるプログラムであって、プロセッサに、ユーザを識別するユーザＩＤを取得するステップと、ユーザが取得を要求した電子チケットを識別するためのチケット関連データに、当該チケットの所有者を識別する所有者ＩＤとしてユーザＩＤを変更可能に対応づけて、データベースに記憶させるステップと、を実行させるプログラム。

Description

チケット管理システム、プログラム、および方法
　本開示は、チケット管理システム、プログラム、および方法に関する。
　従来から、イベントの電子チケットを発券するシステムが知られている。
　特許文献１には、イベントの電子チケットを購入することで、特典を提供すシステムが開示されている。
特開２０２０－９８６４５号公報
　このような電子チケットをオンラインライブに適用することも行われているが、一般に、オンラインイベントの電子チケットは「個人の視聴権利」として扱われており、所有権とユーザＩＤはつながりが不可変な中間テーブル上にて紐付いて管理されている。この場合にはマイページ等、当該所有者のみがアクセス可能なページに視聴ボタンが設けられている。そして、ユーザＩＤと、中間テーブルと、が紐づけられ、中間テーブルと、配信されるイベント動画などのデジタルコンテンツが紐づけられている。
　このように、ユーザＩＤが、中間テーブルを介して、デジタルコンテンツと対応づけられて管理されている場合には、ユーザが、電子チケットが有する視聴する権利を他人に譲渡することができなかった。すなわち、従来の例えば紙のチケットのように、複数のチケットを購入して、そのうちの一部を他人に譲ることができず、それぞれのユーザが購入する必要がある。このため、チケットの流通性が阻害されるという懸念があった。
　本開示の目的は、オンラインイベント用の電子チケットの流動性を確保することができるチケット管理システムを提供することを目的とする。
　本開示の一態様に係るチケット管理プログラムは、プロセッサを備え、商品、役務、およびそれらに付随して提供される各種の便益に関する電子チケットを管理するチケット管理システムに実行させるプログラムであって、プロセッサに、ユーザを識別するユーザＩＤを取得するステップと、ユーザが取得を要求した電子チケットを識別するチケットＩＤを特定するためのチケット関連データに、当該チケットの所有者を識別する所有者ＩＤとしてユーザＩＤを変更可能に対応づけて、データベースに記憶させるステップと、を実行させるプログラム。
　本開示によれば、オンラインイベント用の電子チケットの流動性を確保することができる。
第１実施形態のチケットシステムの構成を示すブロック図である。 第１実施形態のユーザ端末の構成を示すブロック図である。 第１実施形態のチケット管理サーバの構成を示すブロック図である。 チケット管理サーバが記憶するユーザデータベース、チケットデータベース、およびコンテンツデータベースのデータ構造の一例を示す図である。 第１実施形態のユーザ登録処理のフローチャートである。 第１実施形態の発券処理のフローチャートである。 第１実施形態の譲渡処理のフローチャートである。 第１実施形態の検札処理のフローチャートである。 第１実施形態の第１画面例および第２画面例を示す図である。 第２実施形態のチケットシステムの構成を示すブロック図である。 第２実施形態のチケット管理台帳の構成を示すブロック図である。 第２実施形態の外部サーバとチケット管理台帳の構成を説明する図である。 第２実施形態において管理されるユーザデータベース、チケットデータベース、およびコンテンツデータベースのデータ構造の一例を示す図である。 第２実施形態のチケット管理台帳の他の構成例を示す図である。 第３実施形態のチケットシステムの構成を示すブロック図である。 第３実施形態の外部サーバとチケット管理台帳の構成を説明する図である。 第３実施形態において管理されるユーザデータベース、チケットデータベース、およびイベントデータベースのデータ構造の一例を示す図である。 電子チケットに特典となるデジタルコンテンツが設定されている構成例を示す図である。
（第１実施形態）
　以下、本発明の第１実施形態について、図面に基づいて詳細に説明する。なお、実施形態を説明するための図面において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。
（１）チケット管理システム１の構成
　チケット管理システム１の構成について説明する。図１は、本実施形態のチケット管理システム１の構成を示すブロック図である。チケット管理システム１は、商品および役務、およびそれらに付随して提供される各種の便益に関する電子チケット（以下、単にチケットという）を管理するシステムである。
　電子チケットは、商品、役務、および各種の便益（以下、この説明においてコンテンツといい、特に電子的な媒体により実現されるコンテンツをデジタルコンテンツという）の購入又は受給する権利を証明する電子的な証票である。電子チケットを所有することにより、対価の支払いが済んでいることが証明される。
　第１実施形態では、オンラインイベントを、電気通信回線を介して視聴する権利に関する証票である電子チケットについて説明する。
　図１に示すように、チケット管理システム１は、ユーザ端末１０と、チケット管理サーバ２０と、を備える。
　ユーザ端末１０、およびチケット管理サーバ２０、はネットワーク（例えば、インターネットまたはイントラネット）ＮＷを介して接続されている。ユーザ端末１０は、ユーザの数に応じて、複数の端末がチケット管理サーバ２０と接続される。
　ユーザ端末１０は、情報処理装置である。ユーザ端末１０は、チケット管理サーバ２０に対してオンライン環境下で配信（開催）される、又はサーバ空間において開催されるオンラインイベントに関するチケットデータを要求するように構成される。ユーザ端末１０は、チケット購入端末と言い換えることもできる。
　第１実施形態に係るチケット管理システム１が管理するデジタルコンテンツには、オンラインイベントの動画、オンラインで提供される映画、各種放送動画、電子コミック、電子書籍等、デジタル通信を介して提供される各種のコンテンツが含まれる。
　以降の説明において、情報処理装置は、例えば、スマートフォン、タブレット端末、パーソナルコンピュータ、サーバコンピュータ（例えば、Ｗｅｂサーバ、アプリケーションサーバ、データベースサーバ、またはそれらの組み合わせ）、ウェアラブルデバイス（例えば、スマートウォッチ、またはスマートグラス）、などの種々のコンピュータを含み得る。本実施形態では、ユーザ端末１０は、ネットワークＮＷに接続可能なモバイルコンピュータであるスマートフォンを例に挙げて説明する。
　チケットデータは、チケットに関する情報である。具体的には、チケットデータは、チケットを識別する情報、チケットが証明する権限に関する情報（例えば、チケットの対象となるオンラインイベントに関する情報）、チケットの所有者の氏名、チケットの所有者に関する情報（例えばユーザＩＤ）、もしくはそれらの組み合わせ、またはそれらを符号化したコード情報（例えば、ＱＲコード（登録商標）、または他の１次元もしくは２次元コード）を含み得る。
　チケットは、ユーザが保持するユーザ端末１０に表示されたチケットデータの画像（つまり電子チケット）である。
　チケット管理サーバ２０は、情報処理装置である。チケット管理サーバ２０は、ユーザ端末１０からの要求に応じて、発券（つまりチケットデータの発行）を行うように構成される。また、チケット管理サーバ２０は、発行したチケットデータを管理するように構成される。
（１－１）ユーザ端末１０の構成
　ユーザ端末１０の構成について説明する。図２は、本実施形態のチケット購入端末の構成を示すブロック図である。
　図２に示すように、ユーザ端末１０は、記憶装置１１と、プロセッサ１２と、入出力インタフェース１３と、通信インタフェース１４と、を備える。ユーザ端末１０は、入力デバイス１５および出力デバイス１６の少なくとも１つと接続可能である。
　記憶装置１１は、プログラムおよびデータを記憶するように構成される。記憶装置１１は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、および、ストレージ（例えば、フラッシュメモリまたはハードディスク）の組合せである。
　プログラムは、例えば、以下のプログラムを含む。
・ＯＳ（Operating System）のプログラム
・情報処理を実行するアプリケーション（例えば、ウェブブラウザ）のプログラム
　データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）
　プロセッサ１２は、記憶装置１１に記憶されたプログラムを起動することによって、ユーザ端末１０の機能を実現するように構成される。プロセッサ１２は、コンピュータの一例である。
　入出力インタフェース１３は、入力デバイス１５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス１６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。
　入力デバイス１５は、例えば、キーボード、ポインティングデバイス、タッチパネル、物理ボタン、センサ（例えば、カメラ、バイタルセンサ、またはそれらの組み合わせ）、または、それらの組合せである。
　出力デバイス１６は、例えば、ディスプレイ、スピーカ、印刷装置、またはそれらの組み合わせである。
　通信インタフェース１４は、ユーザ端末１０と外部装置（例えば、チケット管理サーバ２０）との間の通信を制御するように構成される。
（１－２）チケット管理サーバ２０の構成
　チケット管理サーバ２０の構成について説明する。図３は、本実施形態のチケット管理サーバ２０の構成を示すブロック図である。
　図３に示すように、チケット管理サーバ２０は、記憶装置２１と、プロセッサ２２と、入出力インタフェース２３と、通信インタフェース２４とを備える。チケット管理サーバ２０は、入力デバイス２５および出力デバイス２６の少なくとも１つと接続可能である。
　記憶装置２１は、プログラムおよびデータを記憶するように構成される。記憶装置２１は、例えば、ＲＯＭ、ＲＡＭ、および、ストレージ（例えば、フラッシュメモリまたはハードディスク）の組合せである。
　プログラムは、例えば、以下のプログラムを含む。
・ＯＳのプログラム
・情報処理を実行するアプリケーションのプログラム
　データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理の実行結果
　プロセッサ２２は、記憶装置２１に記憶されたプログラムを起動することによって、チケット管理サーバ２０の機能を実現するように構成される。プロセッサ２２は、コンピュータの一例である。
　入出力インタフェース２３は、入力デバイス２５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス２６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。
　入力デバイス２５は、例えば、キーボード、ポインティングデバイス、タッチパネル、センサ、または、それらの組合せである。
　出力デバイス２６は、例えば、ディスプレイ、スピーカ、またはそれらの組み合わせである。
　通信インタフェース２４は、チケット管理サーバ２０と外部装置（例えば、ユーザ端末１０）との間の通信を制御するように構成される。
（２）実施形態の概要
　本実施形態の概要について説明する。
　本実施形態のチケット管理システム１では、ユーザが取得を要求したチケット関連データに、当該チケットの所有者を識別する所有者ＩＤとしてユーザＩＤを変更可能に対応づけて、データベースに記憶させる。ここで、取得の要求とは、以下の態様を含む。
・ユーザによるチケットの購入
・他のチケット又は関連グッズの購入に対する特典としてのチケットの付与
・その他の一定の条件を満たした場合の特典としてのチケットの付与
　また、ユーザが購入したチケットのうちの未使用分を、必要に応じて他のユーザに譲渡する。ユーザは、チケット購入時に複数枚のチケットを購入し、別途、購入したチケットのうちの少なくとも一部を、他のユーザに譲渡することができる。他ユーザは、電子メールやＳＮＳ等のメッセージツールを介した連絡手段を用いてチケットデータを受け取る。
　また、チケット管理システム１が発券するチケットの券面には、オンラインイベントの内容であるデジタルコンテンツ（以下、単にコンテンツという）の視聴を開始するための視聴ボタンが表示される。ユーザは、ユーザ端末１０のディスプレイに自己の所有するチケットの券面を表示させ、当該券面に含まれる視聴ボタンをタップ、またはクリックすることで、オンラインライブに関するデジタルコンテンツを視聴できる。
（３）データ構造
　本実施形態のデータベースについて説明する。これらのデータベースは、チケット管理サーバ２０の記憶装置２１に記憶される。ただし、以下のデータベースの少なくとも一部の複製が、外部の記憶装置にも記憶されてもよい。
　各データベースの構成例について説明する。図４は、チケット管理サーバ２０が記憶するユーザデータベース、チケットデータベース、コンテンツデータベースのデータ構造の一例を示す図である。
（３－１）ユーザデータベース
　ユーザデータベースの構成例について説明する。
　図４Ａに示すユーザデータベースには、ユーザ情報が格納される。
　図４Ａに示すように、ユーザデータベースは、「ユーザＩＤ」フィールドと、「ログインＰＡＳＳ」フィールドと、「ユーザ氏名」フィールドと、「ユーザ属性」フィールドと、「連絡先」フィールドと、「支払方法」フィールドと、を含む。
　「ユーザＩＤ」フィールドには、ユーザＩＤが格納される。ユーザＩＤは、ユーザを識別する情報である。
　「ログインＰＡＳＳ」フィールドには、ユーザがチケット管理サーバ２０にログインをする際に入力が要求されるログインパスワードに関する情報が格納される。
　「ユーザ氏名」フィールドには、ユーザＩＤに対応するユーザの氏名が格納される。
　「ユーザ属性」フィールドには、ユーザＩＤに対応するユーザの属性を示す情報が格納される。ユーザの属性としては、年齢、生年月日、性別、職業、国籍、居住地区（住所）、またはそれらの組み合わせ等を含む。
　「連絡先」フィールドには、ユーザＩＤに対応するユーザの連絡先を示す情報が格納される。連絡先情報としては、例えば、メールアドレス、電話番号、ＳＮＳ（Social Networking Service）もしくは他のメッセージング可能なアプリケーションのアカウント情報、またはそれらの組み合わせである。連絡先情報は、ここで挙げた例に限られず、ユーザ端末１０を介して視聴者にリアルタイムに通知を送信するために利用可能な任意の種別の情報を含むことができる。
　「支払方法」フィールドには、ユーザＩＤに対応するユーザが、チケットを購入する際に電子決済を行うための決済手段に関する情報が格納される。決済手段クレジットカード決済、口座引き落としによる決済、各種の電子決済アプリによる決済等が含まれる。
（３－２）チケットデータベース
　チケットデータベースの構成例について説明する。
　図４Ｂに示すチケットデータベースには、チケットデータが格納される。
　図４Ｂに示すように、チケットデータベースは、「チケットＩＤ」フィールドと、「コンテンツＩＤ」フィールドと、「所有者ＩＤ」フィールドと、「譲渡ステータス」フィールドと、「使用ステータス」フィールドと、を含む。
　「チケットＩＤ」フィールドには、チケットＩＤが格納される。チケットＩＤは、チケットを識別するための情報である。
　「コンテンツＩＤ」フィールドには、チケットＩＤに対応するオンラインイベントの内容を示すコンテンツのＩＤが格納される。
　「所有者ＩＤ」フィールドには、チケットＩＤに対応するチケットの所有者を示すユーザＩＤが格納される。チケット所有者とは、原始的にはチケット購入者を指す。チケット所有者は、チケットの購入後の譲渡により、譲渡先のユーザに変更可能となっている。
　なお、チケットデータベースとともに、ブックデータベースを備えてもよい。ブックデータベースには、複数枚の電子チケットを一つの綴りとして扱うブックのＩＤを示すブックＩＤと、当該ブックＩＤを示す所有者ＩＤと、が記憶されている。ブックデータベースが設けられる場合には、チケットデータベースは、「所有者ＩＤ」フィールドに代えて、ブックＩＤを記憶する「ブックＩＤ」フィールドを含むこととなる。
　このブックＩＤのように、チケットＩＤを特定するために用いられる各種の情報をチケット関連データという。チケット関連データには、例えば以下が含まれる。
・チケットＩＤ
・ブックＩＤ（チケットＩＤを特定する中間段階として特定されるＩＤ）
・管理台帳ＩＤ（チケットＩＤが保存される管理台帳を特定するＩＤ）
　このうち、管理台帳ＩＤは、例えば分散管理台帳であるブロックチェーンを用いてチケットの所有者を管理する際に用いられてもよい。
　なお、チケット関連データには、前述のブックＩＤに限られず、更に階層的なデータ構造により、チケットＩＤを特定するデータも含まれる。すなわち、チケット関連データとは、データ構造によって限定されず、チケットＩＤを特定するために保持される各種のデータ群が含まれる。
　「譲渡ステータス」フィールドには、チケットＩＤに対応するチケットの譲渡履歴を示す情報が格納される。譲渡履歴としては、例えば、「譲渡前」、「譲渡後」が含まれる。チケットの譲渡により、ステータスが更新される。なお、譲渡履歴としては、譲渡された回数を示す情報を管理してもよい。チケット管理システム１では、譲渡ステータスを条件として、譲渡できる回数を制限することができる。すなわち、既に譲渡されたチケット（又は既にＮ回譲渡されたチケット）は、再度譲渡することができないという設定を行うことができる。
　「使用ステータス」フィールドには、チケットＩＤに対応するチケットの使用状態を示す情報が格納される。チケットの使用状態としては、「使用前」、「使用後」が含まれる。チケットのもぎり後に、チケットの状態は「使用後」に書き換えられる。
（３－３）コンテンツデータベース
　図４Ｃに示すコンテンツデータベースには、コンテンツに関する情報が格納される。
　図４Ｃに示すように、コンテンツデータベースは、「コンテンツＩＤ」フィールドと、「イベント名称」フィールドと、「運営会社」フィールドと、「イベント種別」フィールドと、「出演者」フィールドと、「配信開始日時」フィールドと、「配信終了日時」フィールドと、「コンテンツアドレス」フィールドと、を含む。
　「コンテンツＩＤ」フィールドには、コンテンツＩＤが格納される。コンテンツＩＤは、各種のコンテンツを識別する情報である。
　「イベント名称」フィールドは、イベント名称が格納される。イベント名称は、コンテンツＩＤによって識別されるオンラインイベントの名称を示す情報である。
　「運営会社」フィールドには、運営会社に関する情報が格納される。運営会社に関する情報とは、コンテンツＩＤによって識別されるイベントの運営会社を示す情報である。運営会社に関する情報は、運営会社の名称の他、運営会社の所在地や担当者の連絡先の情報を含んでもよい。
　「イベント種別」フィールドには、イベント種別に関する情報が格納される。イベント種別に関する情報は、コンテンツＩＤによって識別されるオンラインイベントの概要を示す情報である。例えば、イベント種別として、「オンラインライブ」「オンライン漫才」「オンラインファン交流会」等が挙げられる。
　「出演者」フィールドには、出演者情報が格納される。出演者情報は、コンテンツＩＤによって識別されるオンラインイベントへの出演者を示す情報である。出演者情報には、個人または団体（グループ名、チーム名、コンビ名、ユニット名、バンド名等）が含まれる。
　「配信開始日時」フィールドには、配信開始日時が格納される。配信開始日時は、コンテンツＩＤによって識別されるオンラインイベントのコンテンツの配信が開始される日時を示す情報である。すなわち、配信開始日時は、コンテンツを視聴可能となる最初の日時を指す。
　「配信終了日時」フィールドには、配信終了日時が格納される。配信終了日時は、コンテンツＩＤによって識別されるオンラインイベントのコンテンツの配信が終了される日時を示す情報である。すなわち、配信開始日時は、コンテンツを視聴可能となる最後の日時を指す。
　「コンテンツアドレス」フィールドには、コンテンツアドレスが格納される。コンテンツアドレスは、コンテンツＩＤによって識別されるオンラインイベントのコンテンツが格納されるサーバのアドレス等の、デジタルコンテンツを特定可能な情報である。当該アドレスにアクセスすることで、コンテンツの配信を受けることができる。
（４）チケット処理
　本実施形態のチケット処理について説明する。
（４－１）ユーザの登録処理
　本実施形態の発券処理について説明する。図５は、本実施形態のユーザ登録のフローチャートである。
　図５に示すように、まず、ユーザ端末１０を操作して、ユーザが氏名等の属性情報、および支払情報を含む登録情報を入力して、ユーザ登録の申請を行う（ステップＳ１００）。
　ステップＳ１００の後に、チケット管理サーバ２０は、ユーザ登録の申請を受け付ける（ステップＳ１０１）。
　ステップＳ１０１の後に、チケット管理サーバ２０は、ユーザＩＤおよびログインパスワードを発行する（ステップＳ１０２）。この際、チケット管理サーバ２０は、ユーザから入力された登録情報と、ユーザＩＤおよびパスワードをユーザデータベースにおける新たなレコードとして記録する。
　ステップＳ１０２の後に、ユーザ端末１０は、発行されたユーザＩＤおよびログインパスワードを受領する（ステップＳ１０３）。以上により、ユーザ登録の処理が終了する。
（４－２）発券処理
　図６は、本実施形態の発券処理のフローチャートである。
　図６に示すように、ユーザ端末１０は、購入操作の受付（Ｓ１１０）を実行する。
　具体的には、プロセッサ１２は、入力デバイス１５に対してなされた購入に関する操作を、入出力インタフェース１３を介して受け付ける。この際、ユーザは、購入に関する操作として、購入対象となるチケットを選択し、購入する枚数を入力することができる。
　購入に関する操作は、例えば、ユーザＩＤの入力、興行の選択、日時の選択、購入枚数の指定、購入ボタン（ボタンオブジェクトまたは物理ボタン）の押下、またはそれらの組み合わせを含み得る。
　ステップＳ１１１の後に、ユーザ端末１０は、発券の要求（Ｓ１１１）を実行する。
　具体的には、プロセッサ１２は、ステップＳ１１０において受け付けた購入操作の内容を参照して発券要求を生成する。発券要求は、一例として発券を要求するチケットの種別を特定する情報（例えば、興行、日時および座席種別を特定する情報）を含む。プロセッサ１２は、通信インタフェース１４を介して、チケット管理サーバ２０へ発券要求を送信する。
　ステップＳ１１１の後に、チケット管理サーバ２０は、発券処理（ステップＳ１１２）を行う。具体的には、チケット管理サーバ２０のプロセッサ２２は、ユーザ端末１０から送信された購入に関する情報に基づいて、販売するチケットを割り当てる。プロセッサ２２は、送信されたユーザＩＤを取得する。また、プロセッサ１２は、ユーザが購入を希望するチケットのチケットデータを取得する。
　ステップＳ１１２の後に、チケット管理サーバ２０は、チケットデータベースの更新（Ｓ１１３）を実行する。
　具体的には、プロセッサ２２は、未発行のチケットＩＤに関連付けて、発券要求に含まれるユーザＩＤをチケットデータベースに新規登録して記憶させる。チケットデータベースにおいて、ユーザＩＤは変更可能となっている。これにより、チケットＩＤを元に、チケットの所有者を特定することが可能となる。
　また、プロセッサ１２は、チケットデータに、デジタルコンテンツを特定可能な情報と対応づけて、データベースに記憶させる。具体的には、チケットデータベースに対して、コンテンツデータベースのコンテンツＩＤを新規登録する。
　ステップＳ１１３の後に、チケット管理サーバ２０は、チケットデータの提供（Ｓ１１４）を実行する。
　具体的には、プロセッサ２２は、ステップＳ１１３におけるデータベースの更新内容を参照して、チケットデータを生成する。チケットデータは、ステップＳ１１３において新規登録したチケットＩＤを含む。
　さらに、チケットデータは、チケット所有者のユーザＩＤの少なくとも１つを含むことができる。チケットデータに含まれる情報の一部または全部は例えばＱＲコード（登録商標）または他のコード情報に符号化されてもよい。プロセッサ２２は、生成したチケットデータを、チケットの所有者に提供する。一例として、プロセッサ２２は、通信インタフェース２４を介してユーザ端末１０へ送信する。
　ステップＳ１１４の後に、ユーザ端末１０は、チケットデータの保存（Ｓ１１５）を実行する。
　具体的には、プロセッサ１２は、ステップＳ１１４において提供されたチケットデータを取得する。プロセッサ１２は、取得したチケットデータを記憶装置１１に保存する。これにより、プロセッサ１２は、必要に応じて、チケットデータを表示できる。
　以上により、発券処理が終了する。
（４－３）譲渡処理
　本実施形態の譲渡処理について説明する。図７は、本実施形態の譲渡処理のフローチャートである。
　図７に示すように、購入するチケットの一部、又は全部を譲渡するユーザは、ユーザIＤおよびログインＰＡＳＳによりログインをした後に、譲渡に関する情報を入力して、譲渡の指示を行う（ステップＳ１２０）。具体的には、ユーザは、所定の入力形式に沿って、譲渡対象となるチケットを特定する。その際、チケットの対象となるイベントとチケット枚数を指定してもよい。そして、チケットを譲渡する譲渡先のユーザの情報を入力する。この際、例えば、譲受人となるユーザのメッセージツールの連絡先を指定することで、チケットの譲渡先を指定してもよい。
　ステップＳ１２０の後に、チケット管理サーバ２０は、譲渡指示を受け付ける（ステップＳ１２１）。具体的には、チケット管理サーバ２０は、通信インタフェース２４を介して、譲渡指示の情報を受信する。
　ステップＳ１２１の後に、チケット管理サーバ２０は、譲渡指示を確認する（ステップＳ１２２）。具体的には、チケット管理サーバ２０のプロセッサ２２は、譲渡対象となるチケットのチケットＩＤおよびチケットの譲受人を特定する。
　ステップＳ１２２の後に、チケット管理サーバ２０は、チケットデータベースの更新を行う（ステップＳ１２３）。具体的には、チケット管理サーバ２０のプロセッサ２２は、特定した譲渡対象となるチケットのチケットＩＤおよびチケットの譲受人に関する情報を用いて、チケットデータベースの更新を行う。この際、ユーザデータベースを参照して、新たな所有者の所有者ＩＤを特定し、チケットデータベースの「所有者ＩＤ」フィールドを更新する。これにより、譲渡されたチケットの所有者ＩＤが譲受人に書き換えられる。
　また、プロセッサ２２は、チケットデータベースにおける譲渡ステータスを更新する。ケットの譲渡後は、譲渡したユーザのユーザ端末１０では、当該チケットのチケットデータは表示されない状態となる。
　ステップＳ１２３の後に、チケット管理サーバ２０は、チケットデータの送信を行う（ステップＳ１２４）。具体的には、プロセッサ２２は、ステップＳ１２３におけるデータベースの更新内容を参照して、チケットデータを生成する。さらに、チケットデータは、チケット所有者のユーザＩＤを含むことができる。チケットデータに含まれる情報の一部または全部は例えばＱＲコード（登録商標）または他のコード情報に符号化されてもよい。プロセッサ２２は、生成したチケットデータを、チケットの譲受人に提供する。一例として、プロセッサ２２は、通信インタフェース２４を介して、譲受人である他のユーザ端末１０へ送信する。この際、プロセッサ２２は、譲受人のメッセージツールの連絡先に対して、チケットデータを用いて作成したＵＲＬを発行する。
　ステップＳ１２４の後に、他のユーザ端末１０は、チケットデータを受け取る（ステップＳ１２５）。他のユーザ端末１０におけるプロセッサ１２は、ステップＳ１２４において提供されたチケットデータを取得する。具体的には、プロセッサ２２から送付されたＵＲＬをクリックして、チケットデータを取得する。
　プロセッサ１２は、取得したチケットデータを記憶装置１１に保存する。これにより、プロセッサ１２は、必要に応じて、チケットデータを表示できる。
　なお、ステップＳ１２５に示したチケット受け取り操作については、省略してもよい。すなわち、チケットを譲渡するユーザが、譲受人のメールアドレス又は電話番号等の譲受人の連絡先に関する情報を指定し、譲受人の明示的な受け取りに関する操作を受け付けることなく、一方的にチケットの所有者を譲受人に変更する処理を行ってもよい。この場合、譲受人には必要に応じて、チケットの所有権が移転された旨（チケットを譲受した旨）を通知してもよい。
　以上により、譲渡処理が終了する。
（４－４）検札処理
　本実施形態の検札処理について説明する。図８は、本実施形態の検札処理のフローチャートである。
　図８に示すように、オンラインイベントを視聴するユーザは、ユーザ端末１０を操作して、視聴指示を行う（ステップＳ１３０）。具体的には、視聴者からのチケット券面の表示指示により、ユーザ端末１０のプロセッサ１２が、記憶装置１１に記憶したチケットデータの券面をユーザ端末１０に表示させる。この際、券面には視聴ボタンが表示されている。視聴者は、表示された視聴ボタンを押下する。
　ステップＳ１３０の後に、チケット管理サーバ２０は、チケットの特定（Ｓ１３１）を実行する。
　ステップＳ１３０およびステップＳ１３１の後に、チケット管理サーバ２０は、視聴可否の判定（Ｓ１３２）を実行する。
　具体的には、プロセッサ２２は、ステップＳ１３０において読み取ったチケットデータを参照して、視聴者の視聴可否を判定する。
　具体的には、視聴ボタンが押下されたチケットデータをチケットデータベースに照会し、チケットデータが視聴する権限のある適切なチケットデータであるかどうかを判定する。
　ステップＳ１３２において、読み取ったチケットデータが適切なチケットデータではない場合、又は視聴者とチケット所有者の同一性が確認できない場合には、チケット管理サーバ２０は、視聴エラー処理を実行する。
　ステップＳ１３２において、読み取ったチケットデータが適切なチケットデータであり、かつ視聴者とチケット所有者の同一性が確認できた場合には、チケット管理サーバ２０は、チケット使用の検出（Ｓ１３５）、いわゆる「もぎり処理」を実行する。
　プロセッサ２２は、ステップＳ１３３の際に、チェックインリストを作成、または更新してもよい。
　チェックインリストは、各視聴者に対する検札処理の結果一覧に関する情報である。チェックインリストは、一例として以下の要素の少なくとも１つを含む。
・視聴開始時刻
・視聴者の使用したチケットのチケットＩＤ
・チケットＩＤに関連付けられるユーザＩＤ
・ユーザＩＤに関連付けられるユーザ名
・視聴可否の判定（ステップＳ１３３）の結果（視聴許可／視聴拒否）
　ステップＳ１３３の後に、チケット管理サーバ２０は、チケット使用に伴うチケット券面の表示態様を変更する（ステップＳ１３４）。具体的には、例えば、チケット券面に使用済みを示すスタンプ画像の付与、チケット券面の発光、チケット券面の色の変化等を行う。また、チケット券面の表示形態の変更として、もぎりの検出により、チケット券面に視聴条件に関する情報を表示してもよい。なお、オンラインイベントにおける視聴条件とは、ステージを撮影するカメラの位置やステージとのアングル、又は再生される音の音質を示す。
　ステップＳ１３４の後に、ユーザ端末１０に表示されたチケットの券面の表示が変化する（ステップＳ１３５）。
　ステップＳ１３５の後に、チケット管理サーバ２０は、コンテンツデータの案内を行う（ステップＳ１３６）。具体的には、チケットＩＤと紐づいたコンテンツＩＤをコンテンツデータベースから参照し、コンテンツＩＤと対応するコンテンツアドレスにユーザ端末１０を接続する。
　ステップＳ１３６の後に、ユーザ端末１０はコンテンツを再生する（ステップＳ１３７）。具体的には、ユーザ端末１０のプロセッサ１２は、コンテンツアドレスに保存されたコンテンツを、ユーザ端末１０に再生する。
　以上により、検札処理が終了する。
（５）画面例
　次に、チケット管理システム１におけるユーザ端末１０での画面例について説明する。図９は、第１画面例および第２画面例を示す図である。図９Ａに示す第１画面例は、チケットを購入する際の画面例である。
　図９Ａに示すように、チケットを購入する際には、イベント内容、価格、購入数量が表示されている。ユーザは数量を入力し、購入申請を行うことで、購入が行われる。
　図９Ｂに示す第２画面例は、発券が完了したチケットデータを表示する画面例である。
　図９Ｂに示すように、チケットの券面には、視聴ボタン（符号Ａ）が表示されている。配信開始日時の後に、視聴ボタンを押下することで、視聴が開始される。
　また、チケットの券面には、譲渡指示のボタン（符号Ｂ）が表示されている。譲渡指示のボタンを押下することで、譲渡先となる他のユーザの連絡先を選択する画面に遷移する。
　また、複数のチケットを所有している場合には、例えばユーザ端末１０の画面に対してスワイプ操作を行うことで、所有しているチケット毎に表示を切り替えることができる。
　なお、この画面例では、チケットの譲渡をチケット毎に行うユーザインタフェースについて説明しているが、チケットの対象となるイベントを指定し、その後に譲渡するチケットの枚数を指定するようなユーザインタフェースを採用してもよい。
（６）効果
　以上説明したように、チケット管理システム１では、ユーザＩＤが変更可能にチケットデータと対応づけられて記憶され、チケットデータがコンテンツデータと対応づけられて記憶されている。このため、ユーザＩＤを変更することでチケットの所有者を変更することができる。このように、従来のオンラインイベント用のチケットと異なり、ユーザＩＤに対して個別に設けられた中間テーブル（マイページ）にコンテンツデータを対応付ける構造と異なり、チケットを所有者が任意に譲渡可能となることで、チケットの流動性を確保することができる。
　すなわち、紙チケットと同様に未使用の電子チケットを個別に譲渡することが可能となるので、電子チケットの購入者の体験が向上する。例えば、友人・家族の電子チケットを自らの電子チケットとまとめて購入したり、急用でオンラインライブの視聴を断念する場合に知人に電子チケットを贈与したりすることができる。このように、電子チケットの譲渡が可能になり、チケットの流通性を確保することで、運営側もマーケティング施策の選択肢が広がる。
　また、チケット管理システム１では、チケットの購入に関する操作として、チケットの購入枚数の入力を受け付けるので、チケット購入の態様に自由度を与えることができ、ユーザの利便性が向上する。
　また、チケット管理システム１では、視聴ボタンを、電子チケットの券面に表示してもよい。この場合には、視聴開始の指示をユーザが容易に行うことができる。
　なお、この視聴ボタンの表示形態はあくまで一例であり、例えばユーザＩＤに紐づくマイページ上に視聴ボタンを表示してもよいし、電子チケットの券面とマイページ上の双方に視聴ボタンを表示してもよい。この場合には、マイページ上の視聴ボタンのクリックにより、視聴を開始することもできる。
　また、チケット管理システム１では、ユーザが、視聴ボタンを押下することに応じて、電子チケットの使用を検出するので、使用の検出であるもぎり処理を確実に行うことができる。
　また、チケット管理システム１では、チケットの使用の検出に応じて、子チケットの券面の表示態様を変化させるので、既に使用したチケットかどうかをユーザが把握しやすくなる。
　また、チケット管理システム１では、ユーザからのチケットの譲渡に関する操作に応じて、チケットデータに対応づけられたユーザＩＤを、チケットの譲渡先となる他のユーザに変更する。これにより、速やかにチケットの所有者を変更することができる。
　また、チケット管理システム１では、譲渡に関する操作として、電子チケットを譲渡する枚数の入力を受け付けるので、チケット譲渡の態様に自由度を与えることができ、ユーザの利便性が向上する。
　また、チケット管理システム１では、譲渡に関する操作の対象となる電子チケットに関する情報を、電気通信回線を用いて他のユーザに送信する。これにより、電子メール等の通信手段を用いて簡単かつ確実に、チケットの譲渡を行うことができる。
（第２実施形態）
　次に、チケット管理システムの第２実施形態について説明する。この説明において、第１実施形態と同一の構成については同一の符号を付し、その説明を省略する。
　第２実施形態に係るチケット管理システム２では、ブロックチェーンを用いて、電子チケットの管理を行っている。すなわち、チケット管理システム２では、チケットデータベースに含まれる各データをチケットＩＤごとにブロックチェーン上で管理する。
　図１０に示すように、チケット管理システム２におけるユーザ端末１０およびチケット管理サーバ３０は、チケット管理台帳４０とネットワークＮＷを介して接続されている。
　チケット管理サーバ３０は、ユーザデータベースおよびコンテンツデータベースを記憶し、チケット管理台帳４０は、チケットデータベースを記憶する。
　図１１は、チケット管理台帳４０の構成を示す図である。チケット管理台帳４０は、ノードとして機能する信号処理装置４０Ａ～４０Ｅを備える、分散型システムである。
　信号処理装置４０Ａ～４０Ｅは、ネットワークにそれぞれ接続された、例えば、パーソナルコンピュータである。本実施形態では、ネットワークは、ＬＡＮであってもよく、インターネット、および通信事業者が提供する通信網等の公開されているネットワークであってもよい。信号処理装置４０Ａ～４０Ｅは、ネットワークと、例えば、有線または無線により接続されている。信号処理装置４０Ａ～４０Ｅは、ピア・ツー・ピア方式を利用して互いに通信する。
　信号処理装置４０Ａ～４０Ｅは、チケット管理台帳４０を、ブロックチェーン技術を用いて実現している。また、信号処理装置４０Ａ～４０Ｅは、例えば、信号処理装置４０Ａ～４０Ｅのいずれか１つの信号処理装置４０Ａは、記録すべきチケットの取引に関するデータを取得する。信号処理装置４０Ａは、取得したデータを含むブロックを作成し、ブロックチェーンに追加する。信号処理装置４０Ａは、追加したブロックの情報を他の信号処理装置４０Ａへ送信する。他の信号処理装置４０Ｂ～４０Ｅは、受信したブロックの正しさを検証し、正しさが検証されると、ブロックチェーンに追加する。信号処理装置４０Ａ～４０Ｅは、例えば、連結されるブロックの数（承認数）に従ってブロックチェーンを確定する。これにより、信号処理装置４０Ａ～４０Ｅで、同一のチケット管理台帳４０が保存されることになる。なお、保存されるデータは、適宜に暗号化されてもよい。
　なお、チケット管理台帳４０の構成は、図１１に示されるものに限定されない。例えば、チケット管理台帳４０が備える信号処理装置４０Ａの台数は、２台以上であれば何台でも構わない。
　信号処理装置４０Ａは、記憶装置４１と、プロセッサ４２と、入出力インタフェース４３と、通信インタフェース４４と、を備える。信号処理装置４０Ａは、入力デバイス４５および出力デバイス４６の少なくとも１つと接続可能である。
　記憶装置４１は、プログラムおよびデータを記憶するように構成される。記憶装置４１は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、および、ストレージ（例えば、フラッシュメモリまたはハードディスク）の組合せである。
　プログラムは、例えば、以下のプログラムを含む。
・ＯＳ（Operating System）のプログラム
・情報処理を実行するアプリケーション（例えば、ウェブブラウザ）のプログラム
　データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）
　プロセッサ４２は、記憶装置４１に記憶されたプログラムを起動することによって、信号処理装置４０Ａの機能を実現するように構成される。プロセッサ４２は、コンピュータの一例である。
　入出力インタフェース４３は、入力デバイス４５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス４６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。
　入力デバイス４５は、例えば、キーボード、ポインティングデバイス、タッチパネル、物理ボタン、センサ（例えば、カメラ、バイタルセンサ、またはそれらの組み合わせ）、または、それらの組合せである。
　出力デバイス４６は、例えば、ディスプレイ、スピーカ、印刷装置、またはそれらの組み合わせである。
　通信インタフェース４４は、信号処理装置４０Ａと外部装置（例えば、ユーザ端末１０、およびチケット管理サーバ３０の少なくとも１つ）との間の通信を制御するように構成される。
　図１０に示すチケット管理サーバ３０は、少なくとも記憶部と、通信インタフェースと、を備えている。チケット管理サーバ３０は、例えば分散型アプリケーション（ＤＡｐｐｓ）により実現されるサーバ装置である。
　チケット管理サーバ３０は、デジタルコンテンツが格納されたコンテンツ管理サーバ５０と接続されている。コンテンツ管理サーバ５０は、例えばデジタルコンテンツの運営を行うコンテンツ運営会社により管理される。具体的には、出版社（コンテンツ運営会社）が出版する電子書籍を管理する管理サーバがコンテンツ管理サーバ５０に相当する。
　通信インタフェースは、チケット管理サーバ３０と外部装置（ユーザ端末１０、又はチケット管理台帳４０の少なくとも１つ）との間の通信を制御するように構成される。
　なお、チケット管理サーバ３０の機能をチケット管理サーバ３０が実現してもよい。
　図１２に示すように、チケット管理台帳４０は、チケット管理サーバ３０に記録されたコンテンツデータベースを介して、コンテンツ管理サーバ５０のデジタルコンテンツと関連付けられている。チケット管理台帳４０は、分散管理台帳であるブロックチェーンにより実現されている。言い換えれば、電子チケットは分散管理台帳により管理されている。チケットは、後述する所有権の移転に伴う取引履歴を参照可能となっている。あるチケットに関する全ての取引履歴を参照することで、当該チケットの所有者を特定することができる。
　ブロックチェーンは、コントラクトデータを構成するブロックと、ハッシュ値およびトランザクションデータを少なくとも含むブロックと、により構成されている。ユーザ間でのチケットの移転に伴い、新たなトランザクションデータが生成され、図１１に示す信号処理装置４０Ａ～４０Ｅによる検証の後に、新たなブロックが追加される。
　なお、ブロックチェーンは、パブリックなブロックチェーンとプライベートなブロックチェーンとを用い、通常の取引はプライベートなブロックチェーン上で取引履歴を記録し、定期的にパブリックなブロックチェーンに対して最新情報を反映するなど、複数階層を伴うような構成であってもよい。
　本実施形態では、デジタルコンテンツとして電子コミックのチケットを管理する態様について説明する。チケット管理システム２は、少なくともユーザデータベース、チケットデータベース、およびコンテンツデータベースを管理する。このうち、図１３Ａに示すユーザデータベースについては、第１実施形態と同一の構成であるため、その説明を省略する。
　図１３Ｂに示すチケットデータベースは、「チケットＩＤ」フィールドと、「コンテンツＩＤ」フィールドと、「所有者ＩＤ」フィールドと、「閲覧ステータス」フィールドと、「貸与ステータス」フィールドと、を含む。
　「チケットＩＤ」フィールドには、チケットＩＤが格納される。チケットＩＤは、チケットを識別するための情報である。チケットＩＤは、ブロックチェーンのアドレスを示す台帳ＩＤをしても機能する。
　「コンテンツＩＤ」フィールドには、チケットＩＤに対応する電子コミックの内容を示すコンテンツのＩＤが格納される。
　「所有者ＩＤ」フィールドには、チケットＩＤに対応するチケットの所有者を示すユーザＩＤが格納される。チケット所有者とは、原始的にはチケット購入者を指す。チケット所有者は、チケットの購入後の譲渡により、譲渡先のユーザに変更可能となっている。
　「閲覧ステータス」フィールドには、ユーザによる閲覧が既に行われたかどうかを示す情報が格納される。閲覧がされた場合には、ステータスが「閲覧済み」となり、未だ閲覧がされていない状態では、「閲覧前」となる。ステータスが「閲覧済み」の状態では、例えば古本と同じような扱いになり、他のユーザへの譲渡の際の金額が低く設定されるといった機能を採用してもよい。また、閲覧ステータスの状態により、以下の機能を実現してもよい。
・ステータスが「閲覧済み」になった場合は、その後の譲渡ができなくなる
・ステータスが「閲覧済み」になった場合は、閲覧できるコンテンツに制限がかかる（閲覧前の状態でのみ視聴できる限定コンテンツが視聴できなくなる等）
・ステータスが「閲覧済み」となった場合は、表示されるコンテンツが変化する（閲覧済である旨を表示することで価値を変容させる等）
　「貸与ステータス」フィールドには、当該電子コミックを所有するユーザから他のユーザへの貸与が行われているかどうかを示す情報が格納される。他のユーザへの貸与が行われている場合には、ステータスが「貸与中」になり、他のユーザへの貸与が行われていない場合には、ステータスが「未貸与」となる。貸与ステータスが「貸与中」の場合には、当該電子コミックを所有するユーザは、貸与中の電子コミックを閲覧できない状態となる。
　当該電子コミックを所有するユーザから他のユーザへの貸与では、貸与期間と貸与金額に関して他のユーザとの合意が取れた場合に、貸与期間中において、当該電子コミックを視聴する権利が他のユーザに移転される。また、貸与金額の一部に相当する手数料を、チケット管理サーバ３０を運営する事業者に支払うといった機能が採用されてもよい。なお、貸与期間および貸与金額については、予め設定されていてもよい。
　図１３Ｃに示すコンテンツデータベースには、コンテンツに関する情報が格納される。
　図１３Ｃに示すように、コンテンツデータベースは、「コンテンツＩＤ」フィールドと、「コミックタイトル」フィールドと、「出版社」フィールドと、「種別」フィールドと、「作者」フィールドと、「出版日」フィールドと、「貸与条件」フィールドと、「コンテンツアドレス」フィールドと、を含む。
　「コンテンツＩＤ」フィールドには、コンテンツＩＤが格納される。コンテンツＩＤは、各種の電子コミックのコンテンツを識別する情報である。
　「コミックタイトル」フィールドは、コンテンツＩＤに対応する電子コミックの作品タイトルが格納される。
　「出版社」フィールドには、コンテンツＩＤに対応する電子コミックを出版する出版会社に関する情報が格納される。ここで電子コミックの出版とは、電子コミックの内容の編集や校閲を行い、電子媒体にのせて市場に公開する行為を指す。出版社に関する情報は、出版社の名称の他、出版社の所在地や担当者の連絡先の情報を含んでもよい。
　「コミック種別」フィールドには、コンテンツＩＤに対応する電子コミックの種別に関する情報が格納される。例えば、コミック種別として、「少年漫画」「少女漫画」「青年誌」等の想定されるユーザ層による種別の他、「歴史」、「スポーツ」、「学園もの」、「恋愛」等のような、電子コミックの内容における主たるテーマを示す情報であってもよい。
　「作者」フィールドには、コンテンツＩＤに対応する電子コミックの作者に関する情報が格納される。作者に関する情報は、ペンネームの他、本名等の作者の個人情報を含んでもよい。
　「出版日」フィールドには、コンテンツＩＤに対応する電子コミックの出版日、すなわち、配信開始日が格納される。出版日以降に、ユーザは当該電子コミックの購入および閲覧をすることができる。
　「転売条件」フィールドには、コンテンツＩＤに対応する電子コミックを転売により二次的に利用する際の価格等の条件（利用条件）に関する情報が格納される。電子コミックの利用には、出版社からの購入、および他のユーザからの転売による購入が挙げられる。すなわち、転売条件として格納される購入価格としては、新たに出版社から購入する際の価格の他に、一度閲覧した電子コミックを他のユーザに転売する際の転売価格が含まれてもよい。なお、電子コミックを転売により購入する動機としては、数量限定の初版に付された装丁又は特典付きの電子コミックを入手したいというファン心理が挙げられる。
　また、その他の転売条件として、転売を禁止する「転売不可」といった情報や期間限定で閲覧可能なコンテンツに対して、「利用期間」に関する情報が格納されてもよい。また、貸与回数が所定回数を超えた場合に、転売可能としてもよい。
　なお、転売条件は、チケットデータベースにおいて、チケットＩＤごとに設定されてもよい。
　「貸与条件」フィールドには、コンテンツＩＤに対応する電子コミックを購入したユーザが、他のユーザに貸与するといった二次的な使用を行う際に要求される各種の条件（利用条件）が格納される。貸与する際に要求される各種の条件としては、貸与の手数料、貸与金額、貸与期間、貸与が可能となる日時等が含まれる。また、そもそも貸与を禁止する旨の条件が格納されてもよい。
　なお、貸与条件は、チケットデータベースにおいて、チケットＩＤごとに設定されてもよい。
　「コンテンツアドレス」フィールドには、コンテンツＩＤに対応する電子コミックの内容となるコンテンツデータが格納された、コンテンツ管理サーバ５０上のアドレスに関する情報が記憶される。コンテンツアドレスは、デジタルコンテンツを特定可能な情報である。当該アドレスにアクセスすることで、コンテンツの配信を受けることができる。
　チケット管理システム２では、第１実施形態と同様に、ユーザ端末１０とチケット管理サーバ３０との間で、チケットの発券、譲渡、閲覧に関する処理が行われる。そして、チケット管理システム２では、チケットデータベースへのデータの更新が必要なタイミングで、チケット管理サーバ３０からチケット管理台帳４０に対して、データ更新の指示が行われる。これにより、チケット管理台帳４０におけるチケットデータベースの情報が更新され、チケットの所有者が更新される。
　図１４は、コンテンツデータの他の構造例を示す図である。
　図１４に示すように、変形例に係るコンテンツデータは、ブロックチェーンの一部として、チケット管理台帳に格納されている。この場合には、デジタルコンテンツおよびチケットデータベースの情報が、ブロックチェーンであるチケット管理台帳に記録されていることとなる。
（第３実施形態）
　次に、チケット管理システムの第３実施形態について説明する。この説明において、第１実施形態と同一の構成については同一の符号を付し、その説明を省略する。
　第３実施形態に係るチケット管理システム３では、ブロックチェーンを用いて、現実のイベント会場において開催されるコンサートに関する電子チケットの管理を行っている。すなわち、チケット管理システム３では、デジタルコンテンツに該当しないコンテンツ（イベント）に関する電子チケットを、ブロックチェーン上で管理する。このため、チケット管理システム３では、チケットデータベースに含まれる各データをチケットＩＤごとにブロックチェーン上で管理する。
　図１５に示すように、チケット管理システム３におけるユーザ端末１０およびチケット管理サーバ３０は、チケット管理台帳４０および管理者端末６０とネットワークＮＷを介して接続されている。
　チケット管理サーバ３０は、ユーザデータベースおよびコンテンツデータベースを記憶し、チケット管理台帳４０は、チケットデータベースを記憶する。チケット管理台帳４０の構成は、第２実施形態と同一であるための、その説明を省略する。
　管理者端末６０は、チケット管理サーバ３０により電子チケットを管理する管理者が操作する端末である。
　図１５に示すチケット管理サーバ３０は、少なくとも記憶部と、通信インタフェースと、を備えている。チケット管理サーバ３０は、例えば分散型アプリケーション（ＤＡｐｐｓ）により実現されるサーバ装置である。
　通信インタフェースは、チケット管理サーバ３０と外部装置（ユーザ端末１０、又はチケット管理台帳４０の少なくとも１つ）との間の通信を制御するように構成される。
　なお、チケット管理サーバ３０の機能をチケット管理サーバ３０が実現してもよい。
　図１６に示すように、チケット管理台帳４０は、チケット管理サーバ３０に記録されたコンテンツデータベースと関連付けられている。チケット管理台帳４０は、分散管理台帳であるブロックチェーンにより実現されている。言い換えれば、電子チケットは分散管理台帳により管理されている。チケットは、後述する所有権の移転に伴う取引履歴を参照可能となっている。あるチケットに関する全ての取引履歴を参照することで、当該チケットの所有者を特定することができる。
　ブロックチェーンは、コントラクトデータを構成するブロックと、ハッシュ値およびトランザクションデータを少なくとも含むブロックと、により構成されている。ユーザ間でのチケットの移転に伴い、新たなトランザクションデータが生成され、各ノードによる検証の後に、新たなブロックが追加される。
　なお、ブロックチェーンは、パブリックなブロックチェーンとプライベートなブロックチェーンとを用い、通常の取引はプライベートなブロックチェーン上で取引履歴を記録し、定期的にパブリックなブロックチェーンに対して最新情報を反映するなど、複数階層を伴うような構成であってもよい。
　本実施形態では、コンテンツとしてイベント会場において開催されるコンサートのチケットを管理する態様について説明する。チケット管理システム３は、少なくともユーザデータベース、チケットデータベース、およびコンテンツデータベースを管理する。このうち、図１７Ａに示すユーザデータベースについては、第１実施形態と同一の構成であるため、その説明を省略する。
　図１７Ｂに示すように、チケットデータベースは、「チケットＩＤ」フィールドと、「イベントＩＤ」フィールドと、「所有者ＩＤ」フィールドと、「譲渡ステータス」フィールドと、「使用ステータス」フィールドと、「譲渡条件」フィールドと、を含む。
　「チケットＩＤ」フィールドには、チケットＩＤが格納される。チケットＩＤは、チケットを識別するための情報である。
　「イベントＩＤ」フィールドには、チケットＩＤに対応するイベントのＩＤが格納される。
　「所有者ＩＤ」フィールドには、チケットＩＤに対応するチケットの所有者を示すユーザＩＤが格納される。チケット所有者とは、原始的にはチケット購入者を指す。チケット所有者は、チケットの購入後の譲渡により、譲渡先のユーザに変更可能となっている。
　「譲渡ステータス」フィールドには、チケットＩＤに対応するチケットの譲渡履歴を示す情報が格納される。譲渡履歴としては、例えば、「譲渡前」、「譲渡後」が含まれる。チケットの譲渡により、ステータスが更新される。なお、譲渡履歴としては、譲渡された回数を示す情報を管理してもよい。チケット管理システム１では、譲渡ステータスを条件として、譲渡できる回数を制限することができる。すなわち、既に譲渡されたチケット（又は既にＮ回譲渡されたチケット）は、再度譲渡することができないという設定を行うことができる。
　「使用ステータス」フィールドには、チケットＩＤに対応するチケットの使用状態を示す情報が格納される。チケットの使用状態としては、「使用前」、「使用後」が含まれる。チケットのもぎり後に、チケットの状態は「使用後」に書き換えられる。
　「譲渡条件」フィールドには、チケットＩＤに対応する電子チケットの譲渡による二次的な使用に関して設定される条件（利用条件）が格納される。電子チケットの譲渡に関する条件とは、電子チケットの譲渡に関して、予め設定されている条件を指し、例えば、以下が挙げられる。
・電子チケットのもぎり（検札処理）による使用の検出後に譲渡可能（譲渡の許可）
・電子チケットのもぎり（検札処理）による使用の検出後に譲渡不可（譲渡の制限）
・開催日から一定期間経過後に譲渡可能
・オンラインイベントの場合には、視聴完了後に譲渡可能
・もぎり処理＋ユーザの所定のアクションの検出により譲渡可能
　ここで、所定のアクションとは、例えば、イベントに関するコメントの記入、イベントに関するＳＮＳでの拡散（ツイート等）、イベント会場でのグッズの購入、イベント会場内の特定ブースへの立ち寄り等、イベントの興行の販促に寄与する行動を含む。
　図１７Ｃに示すコンテンツデータベースには、コンテンツに関する情報が格納される。
　図１７Ｃに示すように、コンテンツデータベースは、「イベントＩＤ」フィールドと、「イベント名称」フィールドと、「運営会社」フィールドと、「イベント種別」フィールドと、「出演者」フィールドと、「イベント会場」フィールドと、「開催日」フィールドと、「譲渡条件」フィールドと、を含む。
　「イベントＩＤ」フィールドには、イベントを識別するＩＤが格納される。
　「イベント名称」フィールドは、イベントＩＤに対応するイベントの名称が格納される。イベント名称は、コンテンツＩＤによって識別されるイベントの名称を示す情報である。
　「運営会社」フィールドには、イベントの運営会社に関する情報が格納される。運営会社に関する情報とは、コンテンツＩＤによって識別されるイベントの運営会社を示す情報である。運営会社に関する情報は、運営会社の名称の他、運営会社の所在地や担当者の連絡先の情報を含んでもよい。
　「イベント種別」フィールドには、イベントＩＤに対応するイベントの種別に関する情報が格納される。例えば、イベント種別として、「武道館ライブ」「東京ドーム公演」等が挙げられる。
　「出演者」フィールドには、出演者情報が格納される。出演者情報は、イベントＩＤに対応するイベントの出演者を示す情報である。出演者情報には、個人または団体（グループ名、チーム名、コンビ名、ユニット名、バンド名等）が含まれる。
　「イベント会場」フィールドには、配信開始日時が格納される。配信開始日時は、コンテンツＩＤによって識別されるオンラインイベントのコンテンツの配信が開始される日時を示す情報である。すなわち、配信開始日時は、コンテンツを視聴可能となる最初の日時を指す。
　「開催日」フィールドには、イベントＩＤに対応するイベントの開催日が格納される。
　「譲渡条件」フィールドには、チケットデータベースに格納された譲渡条件と同じ項目が格納される。すなわち、チケットデータベースでは、チケット毎にチケットの譲渡条件が設定され、コンテンツデータベースには、イベント毎にチケットの譲渡条件が設定されている。
　チケット管理システム３では、第１実施形態と同様に、ユーザ端末１０とチケット管理サーバ３０との間で、チケットの発券、譲渡、閲覧に関する処理が行われる。そして、チケット管理システム３では、チケットデータベースへのデータの更新が必要なタイミングで、チケット管理サーバ３０からチケット管理台帳４０に対して、データ更新の指示が行われる。これにより、チケット管理サーバ３０により、チケット管理台帳４０におけるチケットデータベースの情報が更新され、チケットの所有者が更新される。また、譲渡条件は、チケット管理サーバ３０からチケット管理台帳４０に対して、データ更新の指示が行われる。
　チケット管理システム３では、管理者端末から、利用に関する条件の設定、および変更に関する操作を受け付ける。これにより、チケットＩＤ毎、又はイベントＩＤ毎に、チケットの譲渡条件を管理者が設定することができる。例えば、管理者が電子チケットの使用後の転売を認めたタイミングから、ユーザは使用済みの電子チケットを他のユーザに譲渡（転売）できるようになる。
　ところで、イベント開催後において、電子チケットには当該イベントに参加したことを示す証明としての機能を発揮する。このため、もぎり処理により電子スタンプが付された使用済みの電子チケット（特に席番がついている電子チケット）を所有することは、当該イベントと間接的な関わりがあることの証明となり、仮に本人が当該イベントに実際に参加していなかったとしても、一部のファンの収集意欲を掻き立てる。このため、イベント開催後の使用済みの電子チケットは、取引の対象となる。
　そして、例えば管理者が、利用に関する条件として、電子チケットの使用の検出処理をトリガーとして、使用済みの前記電子チケットの譲渡を設定している場合には、ユーザがイベント会場で電子チケットのもぎり処理を行われることにより、この譲渡条件を満たすこととなり、後日の電子チケットの譲渡が許可される。
　図１８は、電子チケットに特典となるデジタルコンテンツが設定されている構成例を示す図である。
　図１８Ａに示す例では、電子チケットの特典となる特典コンテンツが、ブロックチェーンの一部として、チケット管理台帳に格納されている。この場合には、デジタルコンテンツおよびチケットデータベースの情報が、ブロックチェーンとして、チケット管理台帳に記録されていることとなる。
　次に、図１８Ｂに示す他の構成例では、特典コンテンツを管理する管理サーバと、チケット管理台帳４０と、がチケット管理サーバ３０を介して紐づけられている。この場合には、図１８Ｃに示すように、コンテンツデータベースに「特典アドレス」フィールドが追加され、イベントＩＤに関する電子チケットに対して、一律に付与される特典が設定される。なお、「特典アドレス」フィールドを、電子チケットデータベースに設けることで、チケットＩＤに対して個別に特典を設定してもよい。
　なお、特典コンテンツとしては、イベントに関係のあるデジタル画像、デジタル音源、デジタル動画等が挙げられる。
　また、特典コンテンツは、何らかの処理の検出（たとえば当該電子チケットの使用）をトリガーにして、その内容が切り替わってもよい。具体的には、電子チケットのもぎり処理がされるまでは、単なる電子チケットの券面を示す画像データであったデジタルコンテンツが、電子チケットにもぎり処理が行われたことを検出して、なんらかの特典となるコンテンツデータに変更されてもよい。この場合には、図１８Ｃに示す特典アドレスそのものを変更してもよいし、特典アドレスに相当するサーバ上に格納されたデジタルコンテンスのデータを変更してもよい。
（変形例）
　本実施形態の変形例について説明する。
　チケット管理システムが扱う電子チケットは、前述したオンラインイベント、電子書籍、およびイベント会場でのイベントに関するチケットに限られない。電子チケットは、例えば、スポーツ大会、ゲーム退会のようなその他の興行、テーマパークへの入場チケット、交通手段の利用に関するチケット等、各種の商品、役務、およびそれらに付随して提供される各種の便益に関するものに対して、任意に適用することができる。この際、電子チケットは有償であることを問わず、無償であってもよい。
　ユーザ端末１０の記憶装置１１は、ネットワークＮＷを介して、ユーザ端末１０と接続されてもよい。チケット管理サーバ２０の記憶装置２１は、ネットワークＮＷを介して、チケット管理サーバ２０と接続されてもよい。また、チケット管理サーバ２０の記憶装置２１は、複数の記憶装置により構成されてもよい。
　上記の検札処理は、前述のようにチケット管理サーバ２０が単独で行ってもよいし、チケット管理サーバ２０と他の装置（例えば外部の検札装置）とが協同して行ってもよい。
　実施形態では、チケットの所有者とコンテンツデータの視聴者の同一性を確認したうえで、同一性が確認された際に、視聴者に対してコンテンツを配信する構成を説明した。しかしながら、チケット管理システム１は、チケットの所有者とコンテンツデータの視聴者の同一性を確認することなく、視聴ボタンの押下に伴って、コンテンツデータを配信してもよい。
　また、チケットの所有者と、視聴者の同一性の確認は、チケットデータへのアクセスの際に要求される本人認証により行ってもよい。具体的には、ユーザがチケットデータを表示させる際に入力するアカウント情報、ＳＭＳ認証、端末ＩＤ認証などにより、チケットの所有者と、視聴者の同一性の確認を行ってもよい。
　実施形態では、ユーザＩＤおよびパスワードにより認証をおこなっているが、例えば顔の特徴量を用いて視聴者の視聴の可否を判定してもよい。この場合には、顔の特徴量に代えて他のバイオメトリクス（例えば、指紋、掌紋、虹彩、静脈、筋電位など）に関する特徴量を用いて視聴者の視聴の可否を判定してもよい。
　また、赤外線、RFID、音波、レーザ型の一次元バーコードリーダー等のその他のセンサにより、ユーザ固有の情報を取得してもよい。
　また、複数種類の特徴量を用いて視聴者の視聴の可否を判定してもよい。
　ユーザの顔の特徴量をチケットの認証に用いる場合には、ユーザ登録の際に特徴量を取得することができる。なお、特徴量を取得するタイミングについては、この限りではない。例えば、チケット発券後に、ユーザ端末１０に表示されたチケット券面から特徴量の入力を行う画面に遷移する処理を行ってもよい。
　また、チケット購入後、チケットの発券前に、ユーザ端末１０により取得した特徴量の入力を行ってもよい。
　実施形態では、チケットが、認証情報を担う認証情報担体である例を示した。しかしながら、認証情報担体は、視聴者の生体であってもよい。具体的には、認証情報担体は、視聴者の顔、または視聴者の掌であってもよい。かかる認証情報担体は、視聴者の特徴量に関する情報を認証情報として保持している。この場合に、チケット管理サーバ３０は、視聴者の特徴量を取得し、当該特徴量を手掛かりとして当該視聴者の購入したチケットを識別するチケットＩＤを特定可能である。すなわち、チケットデータベースは、チケットＩＤに代えて、購入したユーザの生体情報（その特徴量を含む）を記憶することとなる。
　実施形態では、チケット管理サーバ２０が、チケットデータをユーザ端末１０に送信する例を示した。しかしながら、チケット管理サーバ２０は、チケットデータの代わりに、当該チケットデータの保存されたリソースを参照するためのリソース情報（例えば、ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ））をユーザ端末１０へ送信してもよい。視聴者は、自らのユーザ端末１０によってリソース情報の示すリソースにアクセスすることで、当該ユーザ端末１０のディスプレイにチケットデータを表示させることができる。
　実施形態では、チケットデータに含まれる情報の一部または全部は例えばＱＲコード（登録商標）を含む二次元コード、または他のコード情報に符号化される例を示した。一例として、チケットは、チケットＩＤと参照用文字列とがＱＲコード（登録商標）を含むことができる。
　また、チケットＩＤに所有者ＩＤおよび所有者特徴量を関連付けてもよいし、チケットＩＤに所有者ＩＤまたは所有者特徴量の一方のみを関連付けてもよい。つまり、チケットの購入、譲渡時に、所有者ＩＤまたは所有者特徴量の一方のみがデータベースに登録されてよい。
　実施形態では、譲渡するユーザの操作により、チケットデータベースが更新される処理について説明したが、譲受人である他のユーザによる受取処理に応答して、チケットデータベースが更新されてもよい。この場合には、他のユーザが受取処理を行うまでは、チケットの所有権が未確定の状態となる。譲渡するユーザのユーザ端末１０には、当該チケットの状態に関して、「譲渡中」（又は「分配中」）、「譲渡済み」（又は「分配済み」）である旨の表示をしてもよい。その後、他のユーザが受取処理に応じて譲渡が確定し、チケットを譲渡したユーザでは、当該チケットに関する情報が表示されない状態となる。
　あるオンラインライブを対象とする電子チケットの券面の画像は、１種類に限らず複数種類であってもよい。図９Ｂのようにユーザの所有する電子チケット毎に券面および操作を受け付けるオブジェクト（例えば、視聴開始ボタン、または譲渡ボタン）を同一画面に表示することで、複数枚の電子チケットを購入したユーザは、自らの好みの券面の電子チケットを確実に使用、または手元に残し、残りの電子チケットを知人に譲渡することができる。
　また、第２実施形態および第３実施形態のように、電子チケットのデータをブロックチェーン上で管理する場合には、所有者ＩＤとして管理されるデータは、ユーザＩＤにかえて、ブロックチェーン上でユーザを特定可能な当該ユーザのウォレットＩＤであってもよい。
　また、第２実施形態および第３実施形態のように、電子チケットのデータをブロックチェーン上で管理する場合には、チケットの使用に関して更新される視聴開始時刻、閲覧ステータス、貸与ステータス、使用ステータス、譲渡条件等の各トランザクションデータは、当該電子チケットと紐づく別のデータベース上で管理されてもよい。これにより、ブロックチェーン上でチケットＩＤ（台帳ＩＤ）に紐づいて管理されるデータの容量を抑えることができる。
　以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更が可能である。また、上記の実施形態および変形例は、組合せ可能、またはその一部を省略可能である。
（７）付記
　実施形態および変形例で説明した事項を、以下に付記する。
（付記１）
　プロセッサを備え、商品、役務、およびそれらに付随して提供される各種の便益に関する電子チケットを管理するチケット管理システムに実行させるプログラムであって、
　プロセッサに、
　ユーザを識別するユーザＩＤを取得するステップと、
　ユーザが取得を要求した電子チケットを識別するチケットＩＤを特定するためのチケット関連データに、当該チケットの所有者を識別する所有者ＩＤとしてユーザＩＤを変更可能に対応づけて、データベースに記憶させるステップと、を実行させるプログラム。
（付記２）
　プロセッサは、
　購入枚数と同数のチケットＩＤに、所有者ＩＤとしてユーザＩＤを変更可能に対応づけてデータベースに記憶させるステップを実行させる、（付記１）に記載のプログラム。
（付記３）
　プロセッサは、
　電子チケットの所有者であるユーザからの当該電子チケットの譲渡に関する操作に応じて、チケットデータに対応づけられたユーザＩＤを、当該電子チケットの譲渡先となる他のユーザに変更するステップを実行させる、（付記１）又は（付記２）に記載のプログラム。
（付記４）
　プロセッサは、譲渡に関する操作として、電子チケットを譲渡する枚数の入力を受け付けるステップを実行させる、（付記３）に記載のプログラム。
（付記５）
　プロセッサは、譲渡に関する操作の対象となる電子チケットに関する情報を、メッセージツールを用いて他のユーザに送信する、（付記３）又は（付記４）に記載のプログラム。
（付記６）
　プロセッサは、
　チケットＩＤまたはチケットＩＤに対応するコンテンツに対して、電子チケットの利用に関する条件を設定する、（付記１）から（付記５）のいずれかに記載のプログラム。
（付記７）
　利用に関する条件とは、
　電子チケットの譲渡および貸与を含む二次的な使用に関する条件を指す、（付記６）に記載のプログラム。
（付記８）
　プロセッサに、
　利用に関する条件として、
　電子チケットの使用の検出処理をトリガーとして、使用済みの電子チケットの譲渡を許可又は制限するステップを実行させる、（付記６）又は（付記７）に記載のプログラム。
（付記９）
　プロセッサに、
　電子チケットを管理する管理者が使用する管理者端末から、利用に関する条件の設定、および変更に関する操作を受け付けるステップを実行させる、（付記６）から（付記９）のいずれかに記載のプログラム。
（付記１０）
　電子チケットは、オンラインイベントの視聴に関するものであり、
　プロセッサは、
　ユーザ端末へのオンラインイベントに関するデジタルコンテンツの再生を開始する操作の入力を受け付ける視聴ボタンを、電子チケットの券面に表示するステップを実行させる、（付記１）から（付記９）のいずれかに記載のプログラム。
（付記１１）
　プロセッサは、
　電子チケットを保有するユーザが、視聴ボタンを押下することに応じて、電子チケットの使用を検出する、（付記１１）に記載のプログラム。
（付記１２）
　プロセッサは、
　電子チケットの使用の検出に応じて、電子チケットの券面の表示態様を変化させる、（付記１１）に記載のプログラム。
（付記１３）
　プロセッサを備え、商品、役務、およびそれらに付随して提供される各種の便益に関する電子チケットを管理するチケット管理システムが実行する方法であって、
　プロセッサが、
　ユーザを識別するユーザＩＤを取得するステップと、
　ユーザが取得を要求した電子チケットを識別するチケットＩＤを特定するためのチケット関連データに、当該チケットの所有者を識別する所有者ＩＤとしてユーザＩＤを変更可能に対応づけて、データベースに記憶させるステップと、を実行するプログラム。
（付記１４）
　プロセッサを備え、商品、役務、およびそれらに付随して提供される各種の便益に関する電子チケットを管理するチケット管理システムであって、
　プロセッサは、
　ユーザを識別するユーザＩＤを取得する手段と、
　ユーザが取得を要求した電子チケットを識別するチケットＩＤを特定するためのチケット関連データに、当該チケットの所有者を識別する所有者ＩＤとしてユーザＩＤを変更可能に対応づけて、データベースに記憶させる手段と、を備えるチケット管理システム。
１　　　　：チケット管理システム
１０　　　：チケット購入端末
１１　　　：記憶装置
１２　　　：プロセッサ
１３　　　：入出力インタフェース
１４　　　：通信インタフェース
１５　　　：入力デバイス
１６　　　：出力デバイス
２０　　　：チケット管理サーバ
２１　　　：記憶装置
２２　　　：プロセッサ
２３　　　：入出力インタフェース
２４　　　：通信インタフェース
２５　　　：入力デバイス
２６　　　：出力デバイス

 

Claims (14)

  1. 　プロセッサを備え、商品、役務、およびそれらに付随して提供される各種の便益に関する電子チケットを管理するチケット管理システムに実行させるプログラムであって、
    　前記プロセッサに、
    　ユーザを識別するユーザＩＤを取得するステップと、
    　前記ユーザが取得を要求した電子チケットを識別するチケットＩＤを特定するためのチケット関連データに、当該チケットの所有者を識別する所有者ＩＤとして前記ユーザＩＤを変更可能に対応づけて、データベースに記憶させるステップと、を実行させるプログラム。
  2. 　前記プロセッサは、
    　前記購入枚数と同数のチケットＩＤに、前記所有者ＩＤとして前記ユーザＩＤを変更可能に対応づけて前記データベースに記憶させるステップを実行させる、請求項１に記載のプログラム。
  3. 　前記プロセッサは、
    　前記電子チケットの所有者であるユーザからの当該電子チケットの譲渡に関する操作に応じて、前記チケットデータに対応づけられたユーザＩＤを、当該電子チケットの譲渡先となる他のユーザに変更するステップを実行させる、請求項１又は２に記載のプログラム。
  4. 　前記プロセッサは、前記譲渡に関する操作として、前記電子チケットを譲渡する枚数の入力を受け付けるステップを実行させる、請求項３に記載のプログラム。
  5. 　前記プロセッサは、前記譲渡に関する操作の対象となる電子チケットに関する情報を、メッセージツールを用いて前記他のユーザに送信する、請求項３又は４に記載のプログラム。
  6. 　前記プロセッサは、
    　前記チケットＩＤまたは前記チケットＩＤに対応するコンテンツに対して、前記電子チケットの利用に関する条件を設定する、請求項１から５のいずれか１項に記載のプログラム。
  7. 　前記利用に関する条件とは、
    　前記電子チケットの譲渡および貸与を含む二次的な使用に関する条件を指す、請求項６に記載のプログラム。
  8. 　前記プロセッサに、
    　前記利用に関する条件として、
    　前記電子チケットの使用の検出処理をトリガーとして、使用済みの前記電子チケットの譲渡を許可又は制限するステップを実行させる、請求項６又は７に記載のプログラム。
  9. 　前記プロセッサに、
    　前記電子チケットを管理する管理者が使用する管理者端末から、前記利用に関する条件の設定、および変更に関する操作を受け付けるステップを実行させる、請求項６から８のいずれか１項に記載のプログラム。
  10. 　前記電子チケットは、オンラインイベントの視聴に関するものであり、
    　前記プロセッサは、
    　ユーザ端末への前記オンラインイベントに関するデジタルコンテンツの再生を開始する操作の入力を受け付ける視聴ボタンを、前記電子チケットの券面に表示するステップを実行させる、請求項１から９のいずれか１項に記載のプログラム。
  11. 　前記プロセッサは、
    　前記電子チケットを保有するユーザが、前記視聴ボタンを押下することに応じて、前記電子チケットの使用を検出する、請求項１０に記載のプログラム。
  12. 　前記プロセッサは、
    　前記電子チケットの使用の検出に応じて、前記電子チケットの券面の表示態様を変化させる、請求項１１に記載のプログラム。
  13. 　プロセッサを備え、商品、役務、およびそれらに付随して提供される各種の便益に関する電子チケットを管理するチケット管理システムが実行する方法であって、
    　前記プロセッサが、
    　ユーザを識別するユーザＩＤを取得するステップと、
    　前記ユーザが取得を要求した電子チケットを識別するチケットＩＤを特定するためのチケット関連データに、当該チケットの所有者を識別する所有者ＩＤとして前記ユーザＩＤを変更可能に対応づけて、データベースに記憶させるステップと、を実行するプログラム。
  14. 　プロセッサを備え、商品、役務、およびそれらに付随して提供される各種の便益に関する電子チケットを管理するチケット管理システムであって、
    　前記プロセッサは、
    　ユーザを識別するユーザＩＤを取得する手段と、
    　前記ユーザが取得を要求した電子チケットを識別するチケットＩＤを特定するためのチケット関連データに、当該チケットの所有者を識別する所有者ＩＤとして前記ユーザＩＤを変更可能に対応づけて、データベースに記憶させる手段と、を備えるチケット管理システム。
PCT/JP2022/016695 2021-07-30 2022-03-31 チケット管理システム、プログラム、および方法 WO2023007867A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023538277A JPWO2023007867A1 (ja) 2021-07-30 2022-03-31

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-124992 2021-07-30
JP2021124992 2021-07-30

Publications (1)

Publication Number Publication Date
WO2023007867A1 true WO2023007867A1 (ja) 2023-02-02

Family

ID=85087792

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/016695 WO2023007867A1 (ja) 2021-07-30 2022-03-31 チケット管理システム、プログラム、および方法

Country Status (2)

Country Link
JP (1) JPWO2023007867A1 (ja)
WO (1) WO2023007867A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7435890B1 (ja) 2023-07-24 2024-02-21 Ｔｏｐｐａｎホールディングス株式会社 ユーザ認証システム、ユーザ認証装置、ユーザ認証方法、およびプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018032378A (ja) * 2016-08-17 2018-03-01 Ｅｍｔｇ株式会社 プログラム、情報処理装置、及び情報処理システム
JP2018128779A (ja) * 2017-02-07 2018-08-16 ｐｌａｙｇｒｏｕｎｄ株式会社 興行品質制御装置及びプログラム
JP2020095590A (ja) * 2018-12-14 2020-06-18 日本電気株式会社 チケット譲渡装置、チケット譲渡方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018032378A (ja) * 2016-08-17 2018-03-01 Ｅｍｔｇ株式会社 プログラム、情報処理装置、及び情報処理システム
JP2018128779A (ja) * 2017-02-07 2018-08-16 ｐｌａｙｇｒｏｕｎｄ株式会社 興行品質制御装置及びプログラム
JP2020095590A (ja) * 2018-12-14 2020-06-18 日本電気株式会社 チケット譲渡装置、チケット譲渡方法及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: ""LINE LIVE-VIEWING" How to purchase and watch tickets on your smartphone", LINE BLOG, 5 August 2020 (2020-08-05), pages 1 - 13, XP093029537, Retrieved from the Internet <URL:https://lineblog.me/livepress/archives/13260943.html> [retrieved on 20230307] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7435890B1 (ja) 2023-07-24 2024-02-21 Ｔｏｐｐａｎホールディングス株式会社 ユーザ認証システム、ユーザ認証装置、ユーザ認証方法、およびプログラム

Also Published As

Publication number Publication date
JPWO2023007867A1 (ja) 2023-02-02

Similar Documents

Publication Publication Date Title
US11544729B2 (en) Blockchain-enabled crypto asset compliance system for tracking asset allocation
US20210166203A1 (en) System and process for tokenization of digital media
JP7216770B2 (ja) チケットシステム、プログラム、および方法。
US20190279241A1 (en) Content-based mining via blockchain
US10432693B2 (en) System, method and computer program for signing and dedicating information objects
US20180232828A1 (en) Apparatus and method for providing and/or for processing information for, regarding, and/or for facilitating, the commercialization, development, marketing, sale, transfer, licensing, and/or monetization, of intellectual property
US20050273805A1 (en) Methods and apparatus for a title transaction network
US20050246193A1 (en) Methods and apparatus for enabling transaction relating to digital assets
KR102093291B1 (ko) 블록체인 기반의 문화콘텐츠 관리 시스템
JP4898699B2 (ja) ライセンスセントリックでコンテンツを使用するシステムおよび共有ライセンスレポジトリ
CN113656767A (zh) 利用分布式网络及分布式id的作者认证装置及方法
US20140222607A1 (en) Systems and Methods for Distributing Limited Edition Digital Artwork
US20110238588A1 (en) Registration of product information and authenticity certification
US20150193895A1 (en) Apparatus and method for providing and/or for processing information for, regarding, and/or for facilitating, the commercialization, development, marketing, sale, transfer, licensing, and/or monetization, of intellectual property
WO2006009716A2 (en) Methods and apparatus for enabling transactions in networks
WO2023007867A1 (ja) チケット管理システム、プログラム、および方法
Sulaiman et al. Reshaping the future of recruitment through talent reputation and verifiable credentials using blockchain technology
EP2369540A1 (en) Registration of product information and authenticity certification
WO2023082008A1 (en) Systems and methods for providing a digital media rental platform
Rafati Niya et al. DeTi: A Decentralized Ticketing Management Platform
JP4852550B2 (ja) ライセンスされたコンテンツをレンダリングする方法
JP6047076B2 (ja) Ｄｒｍシステムを備える装置及びライセンスリポジトリ
JP5923958B2 (ja) ノベルティ配布システム、ノベルティ配布サーバ装置、電子商取引サーバ装置
JP7237233B1 (ja) ギフティングを行うための装置、方法及びそのためのプログラム
Bachmann et al. Deti: A decentralized ticketing management platform

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22848950

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023538277

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22848950

Country of ref document: EP

Kind code of ref document: A1