JP7224653B2 - Electronic ticket management system, electronic ticket management method and electronic ticket management program - Google Patents

Description

The present invention relates to an electronic ticket management system, an electronic ticket management method, and an electronic ticket management program.

In recent years, attempts have been made to manage admission tickets for event venues on electronic devices. With ticket management using paper media, it is difficult to take measures to prevent resale, and the steep rise in ticket prices is also cited as a problem. ing.

In Patent Document 1, a sale request reception unit that receives a sale request for selling an electronic ticket containing at least information specifying an event to participate from a first purchaser who purchased the electronic ticket, and a sale request reception unit that receives the sale request. after that, the invalidation unit that transmits information for restricting the use of the electronic ticket to the authentication device that authenticates the electronic ticket; When the electronic ticket is sold by presenting the electronic ticket to the purchaser of the second purchaser, the sales department that transmits information about the electronic ticket to the second purchaser, and after the electronic ticket is sold has been reported a technology related to an electronic ticket vending device including a validation unit that transmits information for enabling the use of the electronic ticket to an authentication device that authenticates the electronic ticket.

JP 2018-26078

However, when processing related to electronic ticket management, including ticket transfer, event site entry, and event site settlement, is performed by the management server group, various information related to the processing can be tampered with by malicious users. There is fear.

The tampering resistance of electronic ticket management systems can be improved by introducing hash chains including blockchains.

However, if approval work on the blockchain related to ticket transactions is performed based on consensus building by public nodes, the immediacy of the approval work related to the transaction cannot be maintained, and the ticket transfer or entrance can be performed smoothly. may not be possible.

SUMMARY OF THE INVENTION The present invention has been made in view of the circumstances as described above, and an object to be solved is to realize an electronic ticket management system having tamper resistance and immediacy.

In order to solve the above problems, an electronic ticket management system according to the present invention comprises a user terminal and a node group,
The user terminal generates a terminal signature based on the user terminal information and adds it to a block on the main chain; terminal registration means;
a transaction submission means for generating an owner signature and adding it to a block on the main chain;
The group of nodes has transaction approval means for generating administrator signatures and adding them to blocks on the main chain, and generating transaction approver signatures and adding them to blocks on the sub-chain,
the main chain has a block containing a hash value based on the device signature, the owner signature, the administrator signature, and the blocks on the sub-chain;
A subchain is characterized by having blocks containing hash values based on transaction approver signatures and transaction attribute information.

With such a configuration, electronic ticket management can be performed based on a plurality of private chains having falsification resistance and immediacy. The main chain according to the present invention is used for managing ownership of electronic tickets or deposit processing such as security deposits. Further, the sub-chain according to the present invention is used for management of admission processing to the event venue associated with the electronic ticket or payment processing within the event venue.

In a preferred form of the invention, the transaction approval means adds an administrator signature to a block on the main chain, generates a hash value based on the block, and adds a block containing the hash value to the main chain. Characterized by
With such a configuration, it is possible to record a history of electronic commerce including ticket transfer in the form of a hash chain.

In a preferred form of the invention, the transaction approval means adds a transaction approver signature to a block on the subchain;
The transaction application means is characterized by generating a hash value based on the block to which the transaction approver signature has been added, and adding a block containing the hash value to the subchain.
By adopting such a configuration, it is possible to record, in the form of a hash chain, a history related to electronic commerce including ticket admission or payment processing in the event hall. In addition, since block generation of the sub-chain is performed by the user terminal 2 , the sub-chain is made permanent for the user terminal 2 .

In a preferred form of the present invention, the transaction approval means generates electronic ticket identification information based on a hash value generated using at least one of event information, date information, and seat information related to the electronic ticket, and It is characterized by associating information related to chains with electronic ticket identification information.
With such a configuration, information held by blocks on the main chain and sub-chains according to the present invention can be associated with electronic tickets.

In a preferred embodiment of the present invention, the transaction approval means generates an administrator signature based on the result of signature verification by decryption processing relating to the terminal signature and/or the result of signature verification by decryption processing relating to the owner signature. characterized by
By adopting such a configuration, the transaction approval processing on the main chain according to the present invention can be performed based on the result of the verification processing regarding the user terminal and the ticket owner.

In a preferred embodiment of the present invention, the transaction approval means accepts the transaction approver's signature based on the result of signature verification by the decryption process related to the terminal signature and/or the result of signature verification by the decryption process related to the manager's signature. characterized by generating
With such a configuration, the transaction approval processing on the subchain according to the present invention can be performed based on the result of the verification processing regarding the user terminal and the ticket owner.

In a preferred form of the present invention, the main chain includes blocks containing hash values based on terminal signatures, owner signatures, administrator signatures, blocks on subchains, user attribute information, and user public keys. have
The terminal registration means adds user attribute information including at least one of a user face image, user personal information and user biometric information to a block on the main chain.
By adopting such a configuration, it is possible to record on the main chain information used for verification processing related to the user terminal or the ticket owner when the transaction approval means generates the administrator signature.

A preferred embodiment of the present invention is characterized in that the transaction approval means generates a transaction approver signature based on location authentication processing and/or identity authentication processing for a user who has entered an intention related to transaction application processing. .
With such a configuration, the verification processing related to the ticket owner performed when the transaction approval means generates the transaction approver signature and adds it to the subchain can be replaced with the location authentication processing and/or the identity authentication processing. can be done based on

A preferred embodiment of the present invention is characterized in that the location authentication process is performed based on the signal reception history of the user terminal.
With such a configuration, the position authentication processing can be performed based on various signals received by the user terminal in indoor positioning or outdoor positioning.

A preferred embodiment of the present invention is characterized in that the signal reception history indicates information transmitted and received by wireless communication via a node group, or information on signal strength related to wireless communication.
By adopting such a configuration, the position authentication processing can be performed based on information or signal strength of various signals received by the user terminal in indoor positioning or outdoor positioning.

A preferred embodiment of the present invention is characterized in that wireless communication uses at least one of radio waves, ultrasonic waves and visible light waves.
With such a configuration, wireless communication in indoor positioning or outdoor positioning can be performed by a combination of radio waves, ultrasonic waves and visible light waves. A ticket management system can be realized.

A preferred embodiment of the present invention is characterized in that the identity authentication processing is performed based on similarity detection processing between the user face image captured by the node group and the user face image added on the main chain. do.
By adopting such a configuration, it is possible to generate a transaction approver signature by the transaction approval means and add the transaction approver signature to the sub-chain after performing identity authentication processing by face authentication.

In a preferred embodiment of the present invention, the transaction application means accepts input of intentions related to transaction application processing, generates electronic signatures related to the main chain and sub-chains, and uses the output of the user's private key as a turning point. It is characterized by suppressing the generation of a hash value related to
By adopting such a configuration, it is possible to prevent unauthorized entry of a ticket due to leakage of a key by deterring update processing related to sub-chains.

In a preferred form of the present invention, when a block on the main chain contains an owner signature and does not contain an administrator signature, the transaction application means generates an electronic signature and a hash value for the sub-chain. characterized by deterrence.
By adopting such a configuration, when the transfer of the electronic ticket is not completed, it is possible to suppress the update processing of the sub-chain including the entrance to the event venue using the electronic ticket.

In a preferred embodiment of the present invention, the transaction attribute information indicates an entry/exit history of a user who has entered an intention related to transaction application processing, or a payment history of the user, at the event site associated with the electronic ticket. Characterized by
By adopting such a configuration, it is possible to manage admission to the event venue or payment processing within the event venue by updating the subchain associated with the electronic ticket.

In a preferred form of the present invention, the group of nodes includes one or more main nodes that generate administrator signatures;
one or more subnodes for generating transaction approver signatures;
one or more main nodes are placed on a public network,
One or more subnodes are characterized by being located on a private network.
By adopting such a configuration, when it is difficult to connect to the public network for reasons such as the event venue associated with the electronic ticket having radio wave blocking properties, processing related to electronic ticket management can be performed via the private network. It becomes possible.

In a preferred form of the invention, one or more main nodes and one or more subnodes are interconnected over a private network,
A private network is characterized by being a mesh network.
By adopting such a configuration, when it is difficult to connect to the public network for reasons such as the event venue associated with the electronic ticket having radio wave blocking properties, processing related to electronic ticket management can be performed via the private network. It becomes possible.

An electronic ticket management method according to the present invention includes:
a terminal registration step of generating a terminal signature based on user terminal information and adding it to a block on the main chain;
a transaction submission step that generates an owner signature and adds it to a block on the main chain;
a transaction approval step of generating an administrator signature and adding it to a block on the main chain and generating a transaction approver signature and adding it to a block on the sub-chain;
the main chain has a block containing a hash value based on the device signature, the owner signature, the administrator signature, and the blocks on the sub-chain;
A subchain is characterized by having blocks containing hash values based on transaction approver signatures and transaction attribute information.

An electronic ticket management program according to the present invention comprises:
a terminal registration means for generating a terminal signature based on the user terminal information and adding the computer to a block on the main chain;
a transaction submission means that generates an owner signature and adds it to a block on the main chain;
Act as a transaction approval means that generates an administrator signature and adds it to a block on the main chain, and generates a transaction approver signature and adds it to a block on the sub-chain,
the main chain has a block containing a hash value based on the device signature, the owner signature, the administrator signature, and the blocks on the sub-chain;
A subchain is characterized by having blocks containing hash values based on transaction approver signatures and transaction attribute information.

According to the present invention, an electronic ticket management system having falsification resistance and immediacy can be realized based on a private chain.

1 is a schematic diagram of an electronic ticket management system according to Embodiment 1 of the present invention; FIG. 1 is a functional block diagram and a hardware configuration diagram according to Embodiment 1 of the present invention; FIG. FIG. 4 is a schematic diagram showing a processing flowchart relating to a ticket transfer process and a ticket admission process, and information possessed by a main chain and sub-chains according to Embodiment 1 of the present invention; FIG. 4 is a schematic diagram showing an overview of chain update in the main chain or sub-chain according to Embodiment 1 of the present invention; FIG. 3 is a schematic diagram showing a processing flowchart for terminal signature and terminal registration, and a processing flowchart for owner signature and transferee signature in Embodiment 1 of the present invention. FIG. 4 is a schematic diagram showing an outline of user verification processing based on the existence proof protocol according to the first embodiment of the present invention; It is a functional block diagram and a hardware configuration diagram in Embodiment 2 of the present invention. FIG. 10 is a schematic diagram showing a processing flowchart relating to a settlement assurance process and information possessed by a main chain and sub-chains according to Embodiment 3 of the present invention;

<Embodiment 1>
Embodiment 1 of the electronic ticket management system 1 according to the present invention will be described below with reference to the drawings. The embodiments shown below are examples of the present invention, and the present invention is not limited to the following embodiments, and various configurations can be adopted.

For example, in Embodiment 1, the configuration and operation of the electronic ticket management system 1 will be described, but a method, server device, computer program, recording medium, etc. having the same configuration can also achieve the same effect.

Also, the program may be stored in a recording medium. Using this recording medium, a program can be installed in a computer, for example. Here, the recording medium storing the program may be a non-transitory recording medium such as a CD-ROM.

In Embodiment 1, information related to electronic tickets is managed in the form of a distributed database using a plurality of computer devices 10 as a node group and one or more user terminals 2 (FIG. 1(a)), A process related to ticket transfer (FIG. 1(b)) and a process related to ticket admission (FIG. 1(c)) are performed. Ticket transfer refers to the transfer of ticket ownership.

In Embodiment 1, a node group includes one or more main nodes 3 and one or more subnodes 4 . At this time, the node group may include a computer device 10 that does not include the functions of the main node 3 or the functions of the subnodes 4 .

Further, in the first embodiment, the intention input by the user is performed using an application stored in the user terminal 2 . The user's intention input related to electronic ticket management is not limited to this, and various methods such as sending an e-mail to the user's e-mail address, SMS, etc. can be used.

FIG. 2 shows part of a functional block diagram and a hardware configuration diagram of the electronic ticket management system 1 according to the embodiment of the present invention.

As shown in FIG. 2(a). The electronic ticket management system 1 includes a user terminal 2 , a main node 3 and subnodes 4 .

The user terminal 2 and the main node 3 can perform data communication via the public network NW1 using, for example, TCP/IP (Transmission Control Protocol/Internet Protocol) as a communication protocol. The public network NW1 is based on various lines such as CATV (Community Antenna Television) lines and mobile communication networks.

The user terminal 2, main node 3 and subnode 4 are preferably capable of mutual communication via the private network NW2. At this time, the private network NW2 has a network configuration of a short-distance communication system such as a wireless LAN (Local Area Network), Bluetooth (registered trademark), Zigbee (registered trademark), or the like. Also, the private network NW2 may be in the form of a mesh network based on P2P (Pear to Pear) communication.

FIG. 2B is a diagram showing an example of the hardware configuration of the user terminal 2. As shown in FIG. The user terminal 2 includes an arithmetic device (CPU 201), a main memory device (RAM 202), an auxiliary memory device (recording device 203) such as a HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, etc., and a public network. It comprises a communication device 204, an input device 205, and an output device 206, which are interfaces for communicating via the NW1 and/or the private network NW2.

The recording device 203 records an operating system 207 and an electronic ticket management program 208 that cooperates with the system to achieve its functions.

It is preferable that the input device 205 in the first embodiment is configured as an input device such as a touch panel, and the output device 206 is configured as a display or the like.

In the first embodiment, the main node 3 and the subnodes 4 are configured to include various sensor devices for user verification processing based on the existence proof protocol described later, in addition to the hardware configuration of the user terminal 2. is preferred. At this time, the user terminal 2, the main node 3, and the subnode 4 may be terminals such as smartphones.

The user terminal 2 has terminal registration means 21 and transaction application means 22 . The main node 3 has terminal approval means 31 and transaction approval means 32 . Subnode 4 has transaction approval means 41 .

A ticket transfer process including transfer request processing and transfer approval processing in the first embodiment is performed on the main chain M0.

The main chain M0 has a hash value MH obtained by encrypting an electronic signature related to the ticket transfer process, the electronic signature, information related to the public key, and information related to the ticket owner. At this time, the hash value MH indicates a hash value MH obtained by encrypting the information of the immediately preceding block in the main chain M0.

The electronic signature possessed by the block B0 on the main chain M0 is generated based on the terminal signature SGN1 generated based on the user secret key K20 and the user terminal information UD, the user secret key K20 and part of the user attribute information UM. a transferee signature SGN3 generated based on the user private key K25 associated with the transferee and the user attribute information UM held by the main node 3; and the main node held by the main node 3 and an administrator signature SGN4 generated based on the private key K30.

The information related to the ticket owner held by the block B0 on the main chain M0 includes the user public key K21 associated with the user secret key K20 held by the user terminal 2, the user face image UF, the user personal information UP, and the user biometric information. User attribute information UM including at least one of UB.

Note that the finality on the main chain M0 in the first embodiment is obtained each time the chain update (step MX) is completed, and the block immediately before the additional block B1 is treated as a fixed block.

A ticket admission process including admission application processing and admission approval processing in the first embodiment is performed on the sub-chain S0.

The sub-chain S0 has an electronic signature related to the ticket entry process and a hash value SH obtained by encrypting the electronic signature and the entrance/exit information ETR. At this time, the hash value SH indicates the encrypted hash value SH of the previous block in the subchain S0.

The electronic signature possessed by block B0 on subchain S0 refers to transaction approver signature SGN5 generated based on subnode private key K40 possessed by subnode 4 .

Note that the finality on the sub-chain S0 in the first embodiment is obtained each time the chain update (step SX) is completed, and the block immediately before the additional block B1 is treated as a fixed block.

Next, the functions related to the transaction application means 22 and the transaction approval means 32 and 41 in the first embodiment will be explained using the processing flowcharts related to the ticket transfer process and the ticket entry process.

FIG. 3 shows a processing flowchart (FIG. 3(a)) relating to the ticket transfer process and the ticket entrance process, and a schematic diagram of the main chain M0 and the sub-chain S0 (FIG. 3(b)).

First, a processing flowchart on the main chain M0 relating to the ticket transfer process will be described. In Embodiment 1, the main chain M0 is associated with each ticket, and the main chain M0 is updated each time the ticket is transferred.

In the ticket transfer process, when the ticket is transferred, the terminal signature SGN1 is added to the generation block by the terminal registration means 21 after the chain is updated (step MX), and the terminal approval process is performed by the terminal approval means 31 (step M10 ).

Next, the addition of the owner signature SGN2 by the transaction application means 22 and the addition of the transferee signature SGN3 by the transaction approval means 32 are performed (step M20).

Next, the administrator signature SGN4 is added by the transaction approval means 32 (step M30).

Finally, the generated block (block B0) on the main chain M0 is encrypted to generate a hash value MH (step MX). A series of procedures is repeated each time the electronic ticket is transferred. For example, the process (step M20) related to the terminal signature in FIG. 3(a) is represented as steps M20A and M20B.

As shown in FIG. 3B, the main chain M0 includes the plurality of electronic signatures described above, the hash value of the previous block, the user public key K21, the user attribute information UM and information related to the sub-chain S0, including. At this time, the main chain M0 is associated with the electronic ticket identification information TCK.

Electronic ticket identification information TCK is individually assigned to electronic tickets in order to prevent duplicate tickets on the electronic ticket management system 1 . The electronic ticket identification information TCK includes a hash value generated by unidirectional conversion based on at least one of unique information associated with the electronic ticket, such as event venue, start time, and seat. .

In the first embodiment, in the form of a distributed Key-Value Store (distributed KVS), information related to block B0 on main chain M0 and sub-chain S0, electronic ticket identification information TCK, and databases DB2, DB3 and DB4. is preferably stored in the . At this time, the key associated with the main chain M0 in the distributed KVS is the electronic ticket identification information TCK.

In the first embodiment, the information related to the block B0 on the main chain M0 and the sub-chain S0 stored in the database DB2 is information related to the electronic ticket associated with the user terminal 2 having the database DB2. preferable.

Next, details of each step related to the ticket transfer process shown in FIG. 3(a) will be described.

FIG. 4 is a processing flowchart (FIG. 4(a)) relating to updating of the main chain M0 (step MX) and updating of the sub-chain S0 (step SX), which will be described later, and signature information, etc. possessed by blocks on the main chain M0. The schematic diagram (FIG.4(b)) is shown.

As shown in FIG. 4A, chain update (step MX) consists of encryption of block B0 on main chain M0 (step MX1) and generation of fixed/additional block B1 of block B0 (step MX2). It is performed by a series of processing procedures.

Transaction approval means 32 encrypts block B0 on main chain M0 based on one-way function F0 to generate hash value MH (step MX1).

It is preferable that the one-way conversion performed when generating the hash value is performed by an encryption method such as the RSA method, the DSA method, the Schnorr method, or the like. The encryption processing may be configured to be performed by multiple times of unidirectional conversion, or may be configured to add a random number or metadata when performing the unidirectional conversion.

After generating the hash value MH (step MX1), the transaction approval means 32 generates an additional block B1 (step MX2). The hash value MH is added to the additional block B1, and the chain update process (step MX) is completed.

As shown in FIG. 4B, the hash value MH in the chain update (step MX) is the terminal signature SGN1, the owner signature SGN2, the assignee signature SGN3, the administrator signature SGN4, the , user attribute information UM, user public key K21, and block B0 on subchain S0 are generated by encryption. At this time, the block B0 on the sub-chain S0 includes at least the hash value SH obtained by encrypting the block on the sub-chain S0 and the entry/exit information ETR.

Based on the one-way function F0, the hash value MH obtained by encrypting the information relating to the aforementioned block B0 is added to the additional block B1. At this time, it is preferable that the information related to the sub-chain S0 is also added to the additional block B1.

Note that the transaction approval means 32 generates genesis blocks in the main chain M0. Added to the genesis block is at least the encrypted hash value MH of the administrator signature SGN4.

FIG. 5(a) shows a processing flowchart relating to terminal registration/signature (step M10).

When the user terminal 2 cannot refer to the user secret key K20 and the user public key K21 (No (N) in step M101), the terminal registration means 21 generates the user secret key K20 and the user public key K21 (step M102). ). At this time, it is preferable that the user secret key K20 is generated based on a random number, a character string input by a user operation, or the like. The user public key K21 is preferably generated based on the user secret key K20. As with step MX, there is no particular restriction on the type of encryption method used in encryption generation.

If the user secret key K20 and the user public key K21 can be referred to (Yes (Y) in step M101), the user secret key K20 and the user public key K21 are not generated.

The terminal registration means 21 generates the terminal signature SGN1 (step M103) after the processing relating to the user secret key K20 and the user public key K21 (steps M101 and M102).

In generating the terminal signature SGN1, the user secret key K20 is used to unidirectionally convert at least the user terminal information UD. The user terminal information UD preferably includes information such as a terminal identifier UDID for identifying the user terminal 2 and an application identifier UAID individually assigned to the electronic ticket management program 208 .

Also, after generating/adding the terminal signature SGN1, the user sends user personal information UP including identification information ID, user attribute information UM including at least one of user face image UF and user biometric information UB to the main It is transmitted to the node group including node 3 and subnode 4 (step M104). The transmitted user attribute information UM is stored sequentially.

After transmitting the user attribute information UM (step M104), the terminal registration means 21 sends the user personal information UP and reference information such as a link related to the user face image UF to the block B0 on the main chain M0. to add. At this time, it is preferable that the reference information is stored as a value in the distributed KVS.

The terminal approval means 31 performs signature verification on the added terminal signature SGN1 and user attribute information UM (step M105). In this verification, the user public key K21 is used to decrypt the terminal signature SGN1, and the validity of the user terminal information UD is verified. Also, in the verification, the validity of the user's identification information ID is verified. When the validity is confirmed by the verification, the user terminal 2 is notified of the validity confirmation. The notification may be done via a distributed KVS.

In the first embodiment, when the validity of the terminal signature SGN1 and the user terminal 2 is confirmed by the decryption process of the terminal signature SGN1, the terminal approval means 31 generates the administrator signature SGN4. may be configured.

With the notification of the validity of the terminal signature SGN1 and the user attribute information UM as a turning point, the terminal registration means 21 adds the user public key K21 to the block B0 on the main chain M0, and registers the terminal signature/ Complete the registration (step M10).

FIG. 5(b) shows a processing flowchart for adding the owner signature SGN2 and the assignee signature SGN3 to the block B0 on the main chain M0 (step M20).

The ticket transfer process is started with input of intention by the user as a turning point. The transaction application means 22 first makes a determination regarding writing out the user secret key K20 possessed by the user terminal 2 (step M201). If the user secret key K20 has been written (Yes (Y) in step M201), the state transitions to the state immediately before step M201, and acceptance of any intention input related to the ticket transfer process is suppressed.

If the user secret key K20 has not been written out (No (N) in step M201), the transition is made to the subsequent steps, and the user terminal 2 of the user who holds the ticket (hereinafter referred to as the transferor) sends the relevant A process related to ticket transfer is executed for another user terminal 2 owned by the user or another user (hereinafter referred to as a transferee).

Transaction application means 22 generates owner signature SGN2 based on user secret key K20 (step M202). At this time, the owner signature SGN2 preferably has a configuration in which the content of the transaction including the information on the transferee who is the transferee of the ticket is encrypted.

After generating the owner signature SGN2 (step M202), the transaction application means 22 invalidates the electronic signature including the terminal signature SGN1 in the block B0 on the main chain (step M203). Preferably, the invalidation process is performed by updating the distributed KVS, and when the invalidation process is performed, the node group is notified via the distributed KVS. The invalidation of the terminal signature SGN1 by the invalidation process is used for suppressing the admission approval process related to the ticket admission process, which will be described later.

When the owner signature SGN2 is notified, the transaction approval means 32 identifies the transferee of the ticket transfer (step M204). It is preferable that the identification is performed based on the details of the transaction obtained by decrypting the owner signature SGN2. At this time, the content of the transaction may include information indicating the payment history related to the ticket transfer.

The transaction approval means 32 generates/adds the transferee signature SGN3 (step M205) with the notification of the invalidation processing of the electronic signature including the terminal signature SGN1 in the block B0 on the main chain M0. ). At this time, the assignee signature SGN3 is generated by the node group based on the user secret key K25 that the main node 3 has. The user secret key K25 is generated individually according to the user terminals 2 possessed by the transferor and the transferee in the electronic ticket management system 1. FIG.

In Embodiment 1, the user private key K20 and the user public key K21 are generated in advance in the user terminal 2 owned by the transferee, and the user private key K20 and K21 are generated at the time of the ticket transfer process, with input of the transferee's intention as a turning point. The assignee signature SGN3 may be generated based on K20. At this time, it is preferable that the user secret key K20 is generated in the terminal signature/registration (step M10) relating to the user terminal 2 owned by the assignee.

Finally, the information related to generation/addition related to the assignee signature SGN3 is applied to the distributed KVS, the notification related to the assignee signature SGN3 is made, and the processing related to the owner signature SGN2 and the assignee signature SGN3 (step M20) to complete.

Based on at least the terminal signature SGN1, the owner signature SGN2 and the assignee signature SGN3, the transaction approval means 32 generates the administrator signature SGN4 and adds the administrator signature SGN4 to the block B0 on the main chain M0 ( step M30). Note that the administrator signature SGN4 is generated based on the main node private key K30.

The transaction approval unit 32 verifies the electronic signature through decryption processing using the user public key K21, and performs approval work. In order to ensure the immediacy of the electronic ticket management system, the verification and approval are preferably performed only at one or more limited specific nodes.

Approval for administrator signature SGN4 is based on continuity of hash values on main chain M0. Continuity in the first embodiment refers to consistency between the result of decryption processing of hash values in adjacent blocks and signatures and the like possessed by the blocks.

If there is an illegitimate hash value without continuity or an illegitimate electronic signature whose validity is not recognized on the main chain M0, the transaction approval means 32 does not approve it on the main chain M0. At this time, the transaction approval means 41 that generates/adds the transaction approver signature SGN5 related to the ticket admission process described later does not perform approval on the sub-chain S0. This suppresses acceptance of transaction including transfer/entrance related to the electronic ticket associated with the chain and intention input related to the transaction.

Next, a processing flowchart on the sub-chain S0 relating to the ticket entry process will be described. In Embodiment 1, the sub-chain S0 is individually associated with the electronic ticket, and chain update (step SX) including block addition on the sub-chain S0 is performed each time the ticket is entered.

As shown in FIG. 3(a), in the ticket admission process based on the sub-chain S0, the entry application is first performed by the transaction application means 22 with the intention input by the user's operation as a turning point (step S10).

Next, verification processing based on the existence proof protocol is performed for the user who applied for entry (step S20). In the user verification process, an identity authentication process A10 and a position authentication process A20 relating to the user are performed.

The transaction approval means 41 generates a transaction approver signature SGN5 based on the result of the user verification process based on the existence proof protocol, and adds it to the block B0 on the subchain S0 (step S30). Finally, the ticket entry process is completed by updating the chain of the sub-chain S0 (step SX).

As shown in FIG. 4(a), in the chain update of sub-chain S0 (step SX), block B0 on sub-chain S0 is encrypted (step SX1), and finalized/additional block B1 of block B0 is generated (step SX2). ) and a series of processes are performed by the transaction application means 22 .

Transaction application means 22 encrypts block B0 on subchain S0 based on one-way function F0 to generate hash value SH (step SX1).

After generating the hash value SH (step SX1), the transaction application means 22 generates an additional block B1 (step SX2). The hash value SH is added to the additional block B1, and the chain update (step SX) is completed.

The hash value SH is generated by encrypting the transaction approver's signature SGN5, the hash value SH and the entrance/exit information ETR of the previous block in the block B0 on the subchain S0.

Next, the details of each step related to the ticket entry process shown in FIG. 2(a) will be described.

If the user secret key K20 has not been written out, the transaction application means 22 accepts the input of the user's intention regarding the entry application, and starts the entry application (step S10). The entry application may be configured to be notified to the node group via the distributed KVS.

The transaction application means 22 instructs the user to present a content indicating the identification information ID, with the reception of the user's intention input related to the entry application as a turning point. At this time, the subnode 4 may be configured to read the contents via the face authentication camera CAM.

In addition, in the first embodiment, the intention input by the user regarding the entry application is performed via the input device 205 . At this time, the MEMS (Micro Electro Mechanical Systems) device including the gyro sensor may be configured such that the intention input is performed by detecting an external force such as vibration as a turning point.

In addition, a two-dimensional code may be displayed on the user terminal 2 as a manifestation of intention by the user related to the entry application. At this time, the scanning of the two-dimensional code by the node group may be used as a turning point for inputting the intention to apply for admission.

The transaction approval means 41 performs validity verification of the terminal signature SGN1 of the electronic ticket associated with the admission application with reference to the distributed KVS and disclosure to the user, using the notification of the admission application as a turning point. and a decryption process based on the key K21.

If the terminal signature SGN1 is invalidated when applying for admission in the ticket admission process, the subsequent steps are not performed.

Next, the user verification process (step S20) based on the existence proof protocol in the ticket entry process will be described with reference to FIG.

FIG. 6 shows a schematic diagram (FIG. 6A) and a processing flowchart (FIG. 6B) relating to user verification processing based on the existence proof protocol in the first embodiment.

User verification processing based on the existence proof protocol in the first embodiment includes, as shown in FIG. 6B, an identity verification process A10 including face recognition and a location verification process A20 including verification by positioning.

Positioning related to the position authentication process A20 in Embodiment 1 is performed based on the signal reception history that the user terminal 2 has.

The main node 3 and the subnodes 4 in the first embodiment may include in their hardware configuration a positioning device and/or a face authentication device used for user verification processing based on the existence proof protocol.

The user verification process is preferably configured to be performed based on Bluetooth (registered trademark) communication including Bluetooth Low Energy (registered trademark) possessed by a smartphone, tablet, or the like, or on the basis of imaging results obtained by an image sensor or the like.

As shown in FIG. 6A, positioning related to the location authentication process A20 is performed by one or more unidirectional communication beacons BCN and/or one or more bidirectional communication routers RTR. In addition, personal identification is performed based on the user's face image captured by the face authentication camera CAM.

In the identity authentication process A10, the subnode 4 is equipped with similarity detection between the user face image captured by the face authentication camera CAM and the user face image UF included in the user attribute information UM in the block B0 on the main chain M0. streaming processing using an image processing library such as DLIB.

In the identity authentication process A10, the transaction approval means 41 further collates the presented user identification information ID with the user personal information UP included in the user attribute information UM on the block B0 in the main chain M0, Validity verification of the identification information ID is performed.

When presenting the content indicating the identification information ID, the identification information ID is read by the machine learning library, the hash value based on the description content is compared with the hash value based on the user personal information UP, and the identification authentication process A10 is performed. It is good also as a structure which performs an identity verification.

It should be noted that the identity verification in the identity authentication process A10 may be configured to be performed based on biometric information including at least one of a fingerprint, voiceprint, iris pattern, and vein pattern. At this time, the sensor device used for sensing the biological information is installed in a state of network connection with the main node 3 or the subnode 4 .

In the location authentication process A20, the user terminal 2 receives an RSSI (Received Signal Strength Indicator) value and/or a UUID ( Acquire location information based on Universally Unique Identifier).

The transaction application means 22 generates a hash value by encrypting the position information based on the signal received via the one-way communication beacon BCN, and transmits the hash value to the node group. At this time, the hash value may be included in the entrance/exit information ETR in the sub-chain S0. Transaction approval means 41 validates the location information based on the hash value.

Also, in the location authentication process A20, the user terminal 2 acquires location information via the two-way communication router RTR. At this time, the medium used for information transmission by the two-way communication router RTR includes not only radio waves including millimeter waves, but also ultrasonic waves, visible light waves, and the like.

Considering the variety of event contents held at the event venue, it is desirable that the media used for wireless communication for positioning be also diverse. There are no particular restrictions on

In the first embodiment, the position authentication process A20 may be performed by GPS (Global Positioning System) positioning by satellite communication.

The transaction application means 22 generates a hash value based on the position information obtained via the two-way communication router RTR, and transmits it to the node group. At this time, the hash value may be included in the entrance/exit information ETR in the sub-chain S0. Transaction approval means 41 validates the location information based on the hash value.

Information acquired by one-way communication beacon BCN and two-way communication router RTR used for positioning related to user verification processing based on existence proof protocol, and face recognition camera CAM used for face recognition is transmitted via the private network NW2 or the public network NW1 in the event hall associated with the electronic ticket.

When the identity authentication process A10 and the location authentication process A20 related to the user verification process based on the existence proof protocol are performed, if the sensor device group, the user terminal 2 and the subnode 4 are not connected to the public network NW1, the private network NW2 is used. It is preferable to update the distributed KVS or the like via the KVS.

The position information related to the position authentication process A20 in Embodiment 1 may include information related to the movement route obtained based on the signal reception history of the user terminal 2 .

Next, generation/addition of transaction approver signature SGN5 (step S30) in the ticket entry process will be described.

The transaction approval means 41 generates the transaction approver signature SGN5 using the subnode private key K40 based on the result of the user verification process (step S20) based on the existence proof protocol.

When generating the transaction approver signature SGN5, the transaction approval means 41 uses at least the location information of the user terminal 2 and/or the similarity detection result related to the face image obtained by the user verification process based on the existence proof protocol. Based on this, the user's whereabouts are determined, and the transaction approver signature SGN5 is added to block B0 on subchain S0.

Authentication of the ticket owner by verification processing based on the existence proof protocol in Embodiment 1 may be configured to be performed through weighting of various information obtained in the verification process. For example, a parameter related to reliability is given to various weighted information, and if the sum of the parameters exceeds a predetermined threshold, the result of the verification is positive, that is, the location of the ticket owner at the event venue. admit.

With the addition of the transaction approver signature SGN5 to block B0 on subchain S0 by transaction approval means 41 as a turning point, transaction application means 22 performs update processing including block generation/addition in subchain S0 (step SX). I do. The ticket entry process is completed by notifying the subnode 4 of the update process through the distributed KVS, and the information on the entry permission for the user is determined. At this time, according to the determination, it may be configured to manage the entry of the user to the event venue in the form of an electronic pick-up.

In the chain update (step SX) on the sub-chain S0, the transaction application means 22 updates the entrance/exit information ETR. Furthermore, information related to block B0 on sub-chain S0 is various information related to user verification processing based on an electronic signature or existence proof protocol in block B0 on sub-chain S0, using entrance/exit information ETR as a key in distributed KVS. is stored as a Value. This suppresses simultaneous generation of blocks including block branches in the sub-chain S0.

The ticket transfer process and the ticket admission process in Embodiment 1 may be configured such that one electronic ticket is associated with one user indicating information on a plurality of visitors. At this time, the admission permission in the ticket admission process is determined individually for a plurality of visitors.

When one electronic ticket is associated with one user indicating information about a plurality of visitors, face authentication according to the identity authentication process A10 is performed for a specific visitor among the plurality of visitors. It is preferable to take a face image and detect the degree of similarity with the user face image UF. At this time, a user face image UF of a specific visitor is registered during terminal registration/authentication (step M10).

In the first embodiment, the writing of the user secret key K20 is displayed or printed in the form of a two-dimensional code or a character code, with the intention input related to the writing as a turning point.

When the user secret key K20 is written out, the user secret key K20 is input to a different user terminal 2, and the generation/addition relating to the terminal signature SGN1 is performed again (step M10). Completion of the authentication enables transfer/entrance of the electronic ticket associated with the user secret key K20 immediately before being written out. Therefore, if the identity information is not registered after the user attribute information UM is registered, the approval process based on the electronic signature using the user secret key K20 in the first embodiment is not completed.

The update process on the sub-chain S0 in the first embodiment may be configured to be performed when the user leaves the event site.

<Embodiment 2>
An electronic ticket management system 1 according to Embodiment 2 of the present invention will be described below. In addition, the same code|symbol is attached|subjected about the structure similar to Embodiment 1, and the description is abbreviate|omitted.

As shown in FIG. 7, the node group 5 in the second embodiment has both functions related to the main node 3 and the subnodes 4 . In addition, the database DB5 has various information that the databases DB3 and DB4 in the first embodiment have.

It is preferable that the node group 5 is connected to the public network NW1, and update processing including block generation/addition on the main chain M0 and sub-chain S0 is immediately reflected. At this time, a sensor device group related to user verification processing based on the existence proof protocol may be included in the hardware configuration of the node group 5 .

<Embodiment 3>
An electronic ticket management system 1 according to Embodiment 3 of the present invention will be described below. In addition, the same code|symbol is attached|subjected about the structure similar to Embodiment 1 or 2, and the description is abbreviate|omitted.

The main chain M0 and sub-chain S0 in Embodiment 3 are used for the settlement guarantee process. The payment guarantee process in the present invention involves depositing a security deposit when entering the event venue, recording a transaction history related to small-value payments within the event venue, and using exit from the event venue as a turning point, performing payment processing based on the transaction history. Refers to a series of processes to be performed. Note that the small amount payment in the third embodiment refers to a payment in which the payment amount does not exceed the security deposit.

Deposits of security deposits in the settlement guarantee process are preferably configured to be based on electronic commerce using various fiat or cryptocurrencies. At this time, there is no particular restriction on the type of currency used in the electronic commerce.

In the third embodiment, it is preferable that the main chain M0 is updated each time a deposit process is performed.

In the settlement guarantee process in the third embodiment, an electronic signature is generated for approval of deposit processing of the guarantee money on the main chain M0, and an event associated with an electronic ticket is generated on the subchain S0. Electronic signature generation and the like are performed for managing the transaction history related to small-value payments made in the venue.

A hardware configuration diagram and a functional block diagram relating to the electronic ticket management system 1 according to the third embodiment have the same configuration as those of the first or second embodiment.

FIG. 8 illustrates a processing flowchart relating to the settlement guarantee process in Embodiment 3, and various types of information held by the main chain M0 and the sub-chain S0.

As shown in FIG. 8A, chain update (step MX) in the third embodiment includes terminal signature/registration by terminal registration means 21 (step M10), generation/addition of owner signature by transaction application means 22 (step M21 ) and generation/addition of administrator signature by transaction approval means 32 (step M30).

It is preferable that the chain update (step MX) in the third embodiment is performed through the same processing procedure as the chain update (step MX) in the first or second embodiment. However, various types of information possessed by block B0 on main chain M0 comply with the configuration shown in FIG.

Owner signature generation/addition (step M21) in the third embodiment is performed by the transferee signature SGN3 among the processing procedures included in the owner signature/transferee signature generation/addition (step M20) in the first or second embodiment. Refers to a series of processing procedures excluding the processing procedures related to However, when the owner signature SGN2 is generated, it is preferable that the encrypted transaction content is information indicating the electronic commerce transaction history related to the aforementioned deposit.

In the generation/addition of the administrator signature (step M30) in the third embodiment, when the decryption process related to the owner signature SGN2 is performed, the main node 3 adds A configuration that verifies the validity of such information and generates an administrator signature SGN4 is preferred. At this time, the electronic signature generated by the terminal owned by the trading partner related to the electronic commerce history may be included in the block B0 on the main chain M0.

In Embodiment 3, it is preferable that the sub-chain S0 is updated each time a user makes a small payment within the event hall.

In the third embodiment, updating the chain on the sub-chain S0 (step SX) includes settlement application by the transaction application means 22 (step S10), user verification processing by the transaction approval means 41 (step S20), and transaction approval by the transaction approval means 41. Configuration via generation/addition of approver signature SGN5 is preferred. At this time, the chain update (step SX) is performed by the transaction application means 22 .

The user operation for payment application in the third embodiment preferably has the same procedure as the user operation for admission application in the first or second embodiment. At this time, the transaction application means 22 may be configured to display information related to the payment application in the form of a two-dimensional code or the like.

The block B0 on the main chain M0 in the third embodiment includes a terminal signature SGN1, an owner signature SGN2, an administrator signature SGN4, user attribute information UM, a user public key K11, and blocks on the main chain M0. and block B0 on subchain S0.

The block B0 on the sub-chain S0 in the third embodiment contains the transaction approver signature SGN5 generated based on the sub-node private key K40, the deposit information DPT, and the hash value SH obtained by encrypting the block on the sub-chain S0. , has The security deposit information DPT indicates information relating to the security deposit balance calculated based on the transaction history relating to the small payment.

The user verification process (step S20) in the third embodiment is performed based on the existence proof protocol. In the third embodiment, the user verification process is based on at least a part of the various information verified in the identity verification process A10 and the location verification process A20 in order to easily manage small payments made within the event venue. Configurations made are preferred.

When the transaction approval means 41 generates/adds the transaction approver signature SGN5 (step S30), the terminal signature SGN1 possessed by the block B0 on the main chain M0 and the deposit information possessed by the block B0 on the sub-chain S0 are , is preferably based on the settlement history obtained through the decryption process for the hash value SH.

The transaction approval means 32 and 41 in the third embodiment respectively verify the continuity of the hash values MH and SH possessed by the block B0 on the main chain M0 or the sub-chain S0, and perform processing related to generation/addition of electronic signatures. I do.

In the third embodiment, the transaction approval means 32 suppresses the update process related to the main chain M0 and the sub-chain S0 when the user leaves the event site. At this time, the transaction approval means 32 may be configured to generate an administrator signature based on the information indicating the suppression and the main node private key K30.

In the third embodiment, the information about the block B0 on the sub-chain S0 used for the approval of small-value payments and the storage of transaction history is included in the block B0 on the sub-chain S0 in the first or second embodiment. may be configured. At this time, it is preferable that the block B0 on the main chain M0 has various information related to the ticket transfer process and various information indicating the electronic commerce history related to the security deposit. In addition, the information related to the sub-chain S0 used for small-value payment management and the information related to the sub-chain S0 used for entrance/exit management may be included in blocks on the main chain M0. .

According to the present invention, an electronic ticket management system having falsification resistance and immediacy can be realized based on a plurality of private chains and sensor fusion.

According to the present invention, ticket entrance management can be performed without requiring a large-sized device such as a ticket gate.

According to the present invention, it is possible to manage processes related to ticket purchase/entrance/in-venue settlement related to user participation in an event on a private chain that is resistant to tampering and immediacy, contributing to favorable event management. can.

1 Electronic Ticket Management System 2 User Terminal 3 Main Node 4 Subnode 5 Node Group 10 Computer Device 21 Terminal Registration Means 22 Transaction Application Means 31 Terminal Approval Means 32 Transaction Approval Means 41 Transaction Approval Means NW1 Public Network NW2 Private Network DB2, DB3, DB4 , DB5 Database 201 CPU
202 RAMs
203 Recording device 204 Communication device 205 Input device 206 Output device 207 Operating system 208 Electronic ticket management program M0 Main chain S0 Sub chain SGN1 Terminal signature SGN2 Owner signature SGN3 Assignee signature SGN4 Manager signature SGN5 Transaction approver signature K20, K25 User Secret keys K21, K26 User public key UD User terminal information UDID Terminal identifier UAID Application identifier UM User attribute information UP User personal information UF User face image UB User biometric information K30 Main node secret key K31 Main node public key K40 Subnode secret key K41 Subnode Public keys MH, SH Hash value B0 Block B1 Additional block F0 One-way function TCK Electronic ticket identification information ETR Entrance/exit information DPT Deposit information A10 Identity authentication process A20 Location authentication process One-way communication beacon BCN
Two-way communication router RTR
Face recognition camera CAM
Identification information ID

Claims (19)

An electronic ticket management system,
comprising a user terminal and a node group,
The user terminal generates a terminal signature based on the user terminal information and adds it to a block on the main chain; terminal registration means;
a transaction application means for generating an owner signature and adding it to a block on the main chain;
The group of nodes has transaction approval means for generating an administrator signature and adding it to a block on the main chain, and generating a transaction approver signature and adding it to a block on the sub-chain,
the main chain has a block containing a hash value based on the terminal signature, the owner signature, the administrator signature, and blocks on the sub-chain;
The electronic ticket management system, wherein the subchain has a block containing a hash value based on the transaction approver signature and transaction attribute information. The transaction approval means adds the manager signature to a block on the main chain, generates a hash value based on the block, and adds a block containing the hash value to the main chain. The electronic ticket management system according to claim 1. The transaction approval means adds the transaction approver signature to a block on the subchain;
3. The method according to claim 1, wherein said transaction application means generates a hash value based on said block to which said transaction approver signature has been added, and adds a block including said hash value to said subchain. Electronic ticket management system as described. The transaction approval means generates electronic ticket identification information based on a hash value generated using at least one of event information, date information, and seat information related to the electronic ticket, and information related to the main chain and sub-chain. , and the electronic ticket identification information are associated with each other. The transaction approval means generates the administrator signature based on the result of signature verification by the decryption process related to the terminal signature and/or the result of signature verification by the decryption process related to the owner signature. The electronic ticket management system according to any one of claims 1 to 4. The transaction approval means generates the transaction approver signature based on the result of signature verification by the decryption process related to the terminal signature and/or the result of signature verification by the decryption process related to the administrator signature. The electronic ticket management system according to any one of claims 1 to 5, characterized by: The main chain has a block containing a hash value based on the terminal signature, the owner signature, the administrator signature, blocks on the sub-chain, user attribute information, and a user public key. ,
7. The terminal registration means adds the user attribute information including at least one of a user face image, user personal information and user biometric information to a block on the main chain. The electronic ticket management system described in 1. 8. The transaction approval means generates the transaction approver's signature based on location authentication processing and/or identity authentication processing for a user who has entered an intention related to transaction application processing. The electronic ticket management system according to any one of . 9. The electronic ticket management system according to claim 8, wherein said position authentication processing is performed based on a signal reception history relating to said user terminal. 10. The electronic ticket management system according to claim 9, wherein the signal reception history indicates information transmitted/received by wireless communication via the node group or information on signal strength related to the wireless communication. 11. The electronic ticket management system according to claim 10, wherein said wireless communication uses at least one of radio waves, ultrasonic waves and visible light waves. 8. The identity authentication processing is performed based on similarity detection processing between the user face image captured by the node group and the user face image added to the main chain. 12. The electronic ticket management system according to any one of -11. With the output of the user private key as a turning point, the transaction application means accepts an intentional input related to transaction application processing, generates an electronic signature related to the main chain and sub-chains, and a hash value related to the main chain and sub-chains. 13. The electronic ticket management system according to any one of claims 1 to 12, which suppresses the generation of The transaction application means suppresses generation of an electronic signature and a hash value related to the sub-chain when a block on the main chain contains the owner signature but does not contain the administrator signature. The electronic ticket management system according to any one of claims 1 to 13, characterized by: 2. The transaction attribute information indicates an entrance/exit history of a user who has entered an intention related to transaction application processing or a payment history of the user at the event venue associated with the electronic ticket. 14. The electronic ticket management system according to any one of 14. The node group includes one or more main nodes that generate the administrator signature;
one or more subnodes for generating the transaction approver signature;
one or more of the main nodes are placed on a public network;
The electronic ticket management system according to any one of claims 1 to 15, characterized in that one or more of said subnodes are placed on a private network. one or more of the main nodes and one or more of the subnodes interconnected over the private network;
17. The electronic ticket management system according to claim 16, wherein said private network is a mesh network. An electronic ticket management method,
A terminal registration step in which the user terminal generates a terminal signature based on the user terminal information and adds it to a block on the main chain;
a transaction application step in which the user terminal generates an owner signature and adds it to a block on the main chain;
a transaction approval step in which nodes generate and add an administrator signature to blocks on the main chain and generate and add transaction approver signatures to blocks on the sub-chain;
the main chain has a block containing a hash value based on the terminal signature, the owner signature, the administrator signature, and blocks on the sub-chain;
The electronic ticket management method, wherein the sub-chain has a block containing a hash value based on the transaction approver's signature and transaction attribute information. An electronic ticket management program,
a terminal registration means for generating a terminal signature based on the user terminal information and adding the computer to a block on the main chain;
a transaction submission means for generating an owner signature and adding it to a block on said main chain;
a transaction approval means for generating an administrator signature and adding it to a block on the main chain and generating a transaction approver signature and adding it to a block on the sub-chain;
the main chain has a block containing a hash value based on the terminal signature, the owner signature, the administrator signature, and blocks on the sub-chain;
The electronic ticket management program, wherein the sub-chain has a block containing a hash value based on the transaction approver signature and transaction attribute information.

Images