JP7402069B2 - Token generation device, token generation system, token generation method, and token generation system manufacturing method - Google Patents

Description

The present invention relates to a token generation device, a token generation system, a token generation method, and a token generation device for generating a token that is a digital certificate for the occurrence of an event such as a scoring scene in a sports match or a scene determining a winner or loser. The present invention relates to a method for manufacturing a generation system.

Blockchain, which has become widely known as a fundamental technology for crypto assets (virtual currency), has made it possible to cover a wide variety of assets as digital securities (see, for example, Non-Patent Document 1), and Consideration is underway to securitize assets such as property and corporate bonds as digital securities, but when securitizing such assets, digital title certificates called "tokens" are issued (for example, non-patent document 2). reference).

In this way, when securitizing various assets as digital securities, since tokens (digital title certificates), which are digital data, are easy to copy, it is necessary to take measures such as electronic signatures to secure and guarantee their value. is required. For example, in order to preserve the value of digital souvenirs such as photographs, an invention has been disclosed regarding a method of embedding a signer's electronic signature and generating a digital souvenir whose authenticity has been verified (see Patent Document 1). .

In addition, as a technology related to detecting the occurrence of an event such as a scoring scene in a sports match, for which tokens are issued in the present invention, when viewing content such as dramas or sports on a hard disk recorder, a specific timing An invention related to an event extraction device that detects and presents to the user before viewing is disclosed (see Patent Document 2).

Japanese Patent Application Publication No. 2016-149754 Japanese Patent Application Publication No. 2006-12012

Nihon Keizai Shimbun November 7, 2019 morning edition, “Today's Word: Digital Securities”, Nihon Keizai Shimbun, page 2 Nihon Keizai Shimbun morning edition, November 7, 2019, “Small investment in digital securities for real estate, intellectual property, corporate bonds, etc.”, Nihon Keizai Shimbun, front page

By the way, in addition to assets such as real estate and intellectual property that are being considered for the issuance of tokens (digital certificates), there are also assets such as real estate and intellectual property that are being considered for the issuance of tokens (digital certificates). A specific "moment" at which an event occurs, such as the climax or the timing when an individual arrives at a destination during a trip, has great value for those who are interested in the event. If tokens are issued for the occurrence of such events, it is possible to form a new market that responds to the latent need to own and obtain that "moment" as one's own. There is.

In order to issue tokens that target the occurrence of such events, a mechanism is required to preserve their value, but the invention described in Patent Document 1 targets digital souvenirs that are fixed in advance. Because it is a method of preserving value, it is not possible to extract a specific "moment" in which an event occurs, for which it is not clear when it will occur, as a token and apply it to a mechanism to guarantee its authenticity.

Furthermore, since the invention described in Patent Document 2 is merely a mechanism for extracting scoring scenes etc. from videos, it does not disclose a method for issuing tokens while guaranteeing the authenticity of the scenes, but does not suggest it. It's not even a thing.

The present invention has been made in order to address such issues, and is intended to generate tokens that are digital rights certificates for the occurrence of events such as scoring scenes in sports matches and scenes where winners and losers are determined. The object of the present invention is to provide a token generation device, a token generation system, a token generation method, and a method for manufacturing the token generation system.

The invention related to a token generation device that solves the problems related to the present application is a token generation device that generates a token that is a digital certificate for a predetermined event, and includes event occurrence information regarding the occurrence of an event for which a token is issued. an event occurrence information receiving unit that receives the event occurrence information, and determines the content of the event that occurred from the event occurrence information received by the event occurrence information receiving unit , generates predetermined information regarding the event , and stores it in an approver list storage unit. identify one or more approvers who require approval for the event from a list of approvers who require approval to generate a token for the event, and upon receiving information certifying approval from the approver, the token generates a token targeted at the event, which includes predetermined information regarding the event and information certifying approval from the one or more approvers; A token generation device comprising: a generation unit.

As described above, according to the token generation device according to the present invention, when an event for which a token is to be issued occurs, it identifies approvers who need approval to generate a token for the event that has occurred, and provides their approval. For example, in the case of a scoring scene in a sports match, after the score is determined, a token is generated that includes information certifying approval such as an electronic signature obtained from the person responsible for the match. By generating tokens with the approval of players, etc., it becomes possible to generate tokens that are backed by related parties and whose value is guaranteed.

Incidentally, an "event" in the present invention refers to a point in time that occurs, such as a scene where a score is scored in a sports match, a scene where a winner or loser is determined, the climax of a concert, festival, party, etc., or the timing when an individual arrives at a destination while traveling. Or, the content is undetermined and targets a specific "moment" when it has been determined.

Further, in the token generation device according to the present invention, the token generation section targets a predetermined event stored in the token generation condition storage section from one or more event occurrence information received by the event occurrence information reception section. The present invention may also be characterized in that when it is determined that a token generation condition is satisfied that makes it possible to generate a token, a token whose contents are determined from the event occurrence information is generated.

With this configuration, it becomes possible to determine whether the event targeted by the token has occurred, not only by one piece of information, but also by combining multiple pieces of information, making it possible to more accurately determine the occurrence of an event. The configuration allows for For example, in the case of a soccer goal scene, in addition to the information on the recognition of the goal determined from the video of the game captured by a camera, the audio from the match venue collected by a microphone, and the posts extracted by monitoring the SNS server, etc. By combining multiple pieces of information, it becomes possible to more accurately determine goals.

Further, in the token generation device according to the present invention, at least one approver list included in the approver list storage section includes static approvers specified in advance and dynamic approvers specified based on the content of the event that has occurred. If the dynamic approver is included in the approver list corresponding to the event that generates a token, the token generation unit generates an approver corresponding to the dynamic approver. It may also be characterized in that information certifying approval from the approver is received by specifying the event occurrence information from the event occurrence information.

In this way, by including dynamic approvers in the approver list and configuring a configuration that allows dynamic approvers to be identified when an event occurs, the approvers who need approval for an event can be determined until the event occurs. Even in cases where it is not possible to do so, for example, in the case of a soccer goal, the scorer can be identified as the approver when a goal is scored, so tokens can be generated for various events. It becomes possible to do so.

Further, the token generation device according to the present invention transmits the token generated by the token generation unit, the issuer of the token, or the issuer and purchaser of the token to a blockchain network, or The present invention may also be characterized by comprising a token issuing unit that records issuance or transaction information regarding the token by storing it in a storage device.

It is preferable that information regarding the issuance and transactions of tokens issued by the present invention be recorded on a blockchain that is extremely difficult to tamper with, but it is also possible to store and manage such information in a centralized database. be.

Further, the token generation device according to the present invention includes a purchase request processing unit that receives a purchase request from a person who wishes to purchase the token, and the token issuing unit is configured to receive the token when the token is generated by the token generation unit. For the purchase applicant who is determined to be able to purchase, issue or transaction information regarding the token will be provided to the purchase applicant as the issuer of the token or the purchaser of the token. It can also be characterized by recording.

With this configuration, for example, it is possible to accept a token purchase request while waiting for approval by an approver and sell the token to a person who wishes to purchase, so that the person who wants to purchase the token can receive the token after approval by the approver is completed. It will be possible to apply to purchase tokens at the moment when an event occurs and to acquire tokens with oneself as the issuer, without having to wait for them to be issued.

The present invention is specified as a token generation system configured by two or more computers capable of transmitting and receiving data via a network such as the Internet, using smart contract functions provided on a blockchain network, for example. You can also do that.

The invention related to a token generation system that solves the problems related to the present application is a token generated by two or more computers capable of transmitting and receiving data via a network, which generates a token that is a digital certificate for a predetermined event. The generation system includes an event occurrence information receiving unit that receives event occurrence information regarding the occurrence of an event for which a token is to be issued, and a content of the event that has occurred based on the event occurrence information received by the event occurrence information receiving unit. generates predetermined information regarding the event , and obtains approval for the event from an approver list that is stored in an approver list storage unit and defines approvers whose approval is required to generate a token for the event. When one or more approvers who require an event are identified and information certifying approval from the one or more approvers is received, predetermined information regarding the event and the approval of the one or more approvers are received. This token generation system is characterized by comprising: a token generation unit that generates a token targeted at the event that includes information proving the event.

Further, in the token generation system according to the present invention, the token generation section targets a predetermined event stored in the token generation condition storage section from one or more event occurrence information received by the event occurrence information reception section. The present invention may also be characterized in that when it is determined that a token generation condition is satisfied that makes it possible to generate a token, a token whose contents are determined from the event occurrence information is generated.

Further, the token generation system according to the present invention may be characterized in that at least a part of the processing executed by the token generation unit is executed by a smart contract on a blockchain network.

Further, the token generation system according to the present invention can also be specified as a token generation system having a configuration corresponding to each feature of the token generation device according to the present invention described above.

The present invention can also be specified as a token generation method executed by the token generation device according to the present invention.

A token generation method according to the present invention is a token generation method executed by a token generation device that generates a token that is a digital certificate for a predetermined event, wherein the token generation device an event occurrence information receiving step of receiving event occurrence information regarding the occurrence of a target event, and the token generation device determining the content of the event that has occurred based on the event occurrence information received in the event occurrence information receiving step; Generates predetermined information regarding the event , and selects a list of approvers whose approval is required for the generation of a token for the event stored in the approver list storage unit. Or, when two or more approvers are identified and information certifying approval from the one or more approvers is received , predetermined information regarding the event and proving approval from the one or more approvers are received. A token generation method is characterized in that it includes a token generation step of generating a token targeted at the event, which includes information about the event.

Furthermore, the token generation method according to the present invention can also be specified as a token generation method executed by the token generation device according to the present invention, which has a configuration corresponding to each of the features described above.

The present invention can also be specified as a token generation method executed by the token generation system according to the present invention.

The token generation method according to the present invention is performed by a token generation system composed of two or more computers capable of transmitting and receiving data via a network, which generates a token that is a digital certificate for a predetermined event. The token generation method includes an event occurrence information receiving step in which the token generation system receives event occurrence information regarding the occurrence of an event for which a token is to be issued; Approval is required to determine the content of the event that occurred from the event occurrence information received in the step , generate predetermined information regarding the event , and generate a token for the event stored in the approver list storage unit. When one or more approvers who require approval for the event are identified from the approver list that defines the approvers, and information certifying the approval from the one or more approvers is received, the a token generation step of generating a token targeted at the event, which includes predetermined information regarding the event and information certifying approval from the one or more approvers; It's a method.

Further, the token generation method according to the present invention can also be specified as a token generation method executed by the token generation system according to the present invention, which has a configuration corresponding to each of the features described above.

The present invention can also be specified as a method for manufacturing a token generation system according to the present invention.

A method for manufacturing a token generation system according to the present invention is a token generation system configured by two or more computers capable of transmitting and receiving data via a network, which generates a token that is a digital certificate for a predetermined event. , wherein the computer receives event occurrence information received by an event occurrence information receiving program installed in at least one computer constituting the token generation system and receiving event occurrence information regarding the occurrence of an event for which a token is to be issued. From the event occurrence information, determine the contents of the event that has occurred, and select the event from the approver list that is stored in the approver list storage unit and determines the approvers who need approval to generate a token for the event. When one or more approvers who require approval are identified and approval is obtained from the one or more approvers, predetermined information regarding the event and approval from the one or more approvers are obtained. The token generation system is configured such that all or part of a token generation program that generates a token targeted at the event that includes information to prove the token can be generated by the token generation program. This is a method for producing a token generation system characterized by distributing it to one or more computers.

Further, the method for manufacturing a token generation system according to the present invention can also be specified as a method for manufacturing a token generation system according to the present invention having a configuration corresponding to each of the features described above.

According to the present invention, at the timing when various events occur, such as the scoring scene in a sports match, the scene where the winner or loser is determined, the climax of a concert, festival, party, etc., or the timing when an individual arrives at a destination as a travel destination, Tokens can be issued for these events. The present invention contributes to the creation of a business that provides new value by owning a specific "moment" according to the diverse tastes of consumers, and has a wide range of application, so it can generate great economic value. There is expected.

FIG. 1 is a diagram showing an overview of an embodiment of the present invention. FIG. 1 is a block diagram showing the functional configuration of a token generation device (token generation server) according to the present invention. 2 is a flowchart showing a processing flow of token issuance by the token generation device (token generation server) according to the present invention. It is a flowchart showing a processing flow for accepting a purchase request for a token issued by a token generation device (token generation server) according to the present invention. FIG. 3 is a diagram showing an example of an approver list stored in an approver list storage unit of the token generation device (token generation server) according to the present invention. FIG. 3 is a diagram showing an example of token generation conditions stored in a token generation condition storage unit of the token generation device (token generation server) according to the present invention. FIG. 2 is a diagram showing an example of a list of prospective purchasers stored in a prospective purchaser list storage unit of the token generation device (token generation server) according to the present invention. FIG. 2 is a diagram illustrating an example of a method for recording a token issued by a token generation device (token generation server) in a blockchain according to the present invention. 1 is a diagram illustrating an overview of an embodiment of a token generation system that implements the present invention using smart contracts on a blockchain. FIG. 2 is a diagram showing the flow of a first method of obtaining approval from a plurality of approvers necessary for generating a token in the present invention. FIG. 7 is a diagram showing the flow of a second method for obtaining approval from a plurality of approvers necessary for generating a token in the present invention. In the present invention, it is a diagram showing a method of signing target data by an approver in a first method of obtaining approval from a plurality of approvers necessary for generating a token. FIG. 7 is a diagram illustrating a method for signing target data by an approver in a second method of obtaining approval from a plurality of approvers necessary for generating a token in the present invention. FIG. 3 is a diagram illustrating a first method for streamlining the signing of token target data by a plurality of approvers in the present invention. FIG. 6 is a diagram illustrating a second method for increasing the efficiency of signatures on target data of tokens by a plurality of approvers in the present invention. FIG. 2 is a diagram illustrating the flow of a method in which a plurality of approvers sign target data of a token using a blockchain according to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments for carrying out the present invention will be described in detail below using the drawings. In the following explanation, an example in which tokens are issued mainly for a soccer goal scene will be used, but this is an example of an embodiment of the present invention, and the present invention is not limited to the following embodiments. It is not limited to the form. For example, the events for which tokens are issued in the present invention are not limited to the scoring scenes of sports matches and the scenes where winners and losers are decided, but also the climax of concerts, festivals, parties, etc., and the events where individuals are traveling. It is possible to target the occurrence of various events such as the timing of arrival at a destination.

First, the significance of the tokens issued by the present invention will be explained using a soccer goal scene as an example. A goal scene in soccer is a particularly impressive moment for both the enemy team and their supporters, and the more wonderful or impressive the goal is, the more it remains in the memory, not just the record, and the more likely it is that the memory will be passed down. It is also something that tends to change over time. Although it is possible to capture such memorable goal scenes on film and reenact them, individuals cannot own the moment itself as their own property.

For example, trading cards with photos of players are issued in popular sports, not just soccer, and if these cards are made into a trading card format, they can be owned as personal assets, but the target is This is a photo of a player, not a representation of a specific "moment"

In the present invention, when a predetermined event occurs, such as a soccer goal scene, a specific "moment" at a certain location is extracted and securitized as a token, which is a digital title certificate, and the issued token is traded between users. We provide a system that allows you to In doing so, we do not simply extract and securitize specific scenes, but also the people involved in the goal (such as the player who scored the goal) and the organizations (such as the league hosting the match, the team playing the match, and the The authenticity of the generated tokens is ensured by obtaining a signature from the stadium management company, etc.

Furthermore, after a token is issued, by adopting public blockchain technology to record token transactions, it becomes virtually impossible to duplicate the issued token, and it is guaranteed that its value is preserved as an asset. Ru.

In this way, the present invention targets an event such as a soccer goal scene as a target for securitization, and generates and issues a token, which is a digital certificate whose authenticity is guaranteed, and makes it tradable. This makes it possible to provide new value by allowing consumers to own a specific "moment" that suits their diverse tastes.

FIG. 1 shows an overview of an embodiment of the invention. In FIG. 1, the token generation server corresponds to the token generation device according to the present invention. The token generation server is a computer that is connected to a network and functions as a server, and receives event occurrence information related to the occurrence of an event from an event detection device or an information providing server. Although it is assumed that the Internet is used as the network, the present invention is not limited to this, and a proprietary network constructed using Bluetooth (registered trademark), short-range wireless, infrared, etc. may also be used.

If the target of the token is a soccer goal scene or a victory/lose decision scene, event detection devices include cameras and microphones installed in the stadium, sound volume/vibration meters, switches held by the referee, and devices installed on goal posts. When an event occurs, such as a goal being scored or a game ending to determine the winner or loser, sensors such as smartphones owned by game officials and spectators can recognize images from cameras and collect sounds using microphones. The event detection device detects the occurrence of an event based on the voice recognition of the sound, the reaction of the sensor, the operation of a predetermined application on the smartphone, etc., and the event is recognized as having occurred. Event occurrence information such as a person related to the event (for example, a player who scored a goal, identified by image recognition, voice recognition, application operation, etc.) is sent to the token generation server.

Information providing servers include servers that provide SNS services, servers that are connected to event detection devices installed in stadiums, etc. By analyzing information posted on SNS, it is possible to recognize the occurrence of an event such as determining a goal or determining a winner or loser, and send the event occurrence information to the token generation server. Alternatively, information detected from event detection devices such as cameras, microphones, and sensors installed in the stadium may be aggregated on an information providing server (the information providing server may perform analysis such as image recognition and voice recognition). , it is also possible to have a configuration in which event occurrence information is transmitted from the information providing server to the token generation server.

When a certain event occurs, there may be cases where multiple event detection devices or information provision servers send multiple event occurrence information to the token generation server in response to the occurrence of the same event. The token generation server that receives the information determines whether or not to generate a token for the event based on whether or not the event occurrence information satisfies token generation conditions for generating a token. If you judge based only on one event occurrence information, there is a relatively high risk of mistakenly recognizing the occurrence of an event due to camera or sensor malfunction, etc. It is preferable to create a token after confirming the above.

When it is determined that the token generation conditions are met, the contents of the event that occurred are determined from the event occurrence information, and the token is generated by referring to the list of approvers who need to approve the token generated for that event. Identify the approvers who require the necessary approvals. The number of approvers required to approve the event specified in the approver list may be one or more. Some approvers may be identified by the occurrence of an event, such as a player who scores a goal in a soccer match, but the approver is in an undetermined state until the goal is scored. In such cases, the ``player who scored the goal'' is determined from the received event occurrence information, and the approver is dynamically identified.

When an approver is identified, approval for the event is requested from the identified approver's terminal, such as a smartphone. Each approver gives approval using an electronic signature (any method that can prove the approver's approval is not limited to an electronic signature), and the token generation server that receives the approved information from the approver first A token is generated for the confirmed event, which includes predetermined information regarding the confirmed event and the electronic signature of the approver.

A person who wishes to purchase a token for an event that has occurred notifies the token generation server of his/her wish to purchase a token from a terminal such as a smartphone. When tokens are generated by the token generation server, it is determined whether to sell the tokens to those who wish to purchase them.

The generated tokens are sent to the blockchain network along with token issuance information, including information about the token issuer, or token transaction information that transfers the token from the issuer to the buyer, and these information are transferred to the blockchain network. The issuance of the token is completed by being recorded above. Once the token issuance is complete, the token purchaser will be notified that the token has been sold.

The issued tokens are published on the network and, like other assets such as crypto assets traded on the blockchain network, are distributed from the token holder (issuer or purchaser) to other purchasers. It becomes possible to transfer. Transaction information when a token is transferred to a new holder is recorded on the blockchain network, and through this mechanism, it is possible to securitize a specific "moment" such as a soccer goal scene in the form of a token and trade it. It becomes possible. Although it is preferable to record such token transaction records on a blockchain network that is extremely difficult to tamper with, it is also possible to store and manage equivalent information in a centralized database.

FIG. 2 is a diagram showing an example of the configuration of a token generation device according to the present invention using functional blocks. In FIG. 2, the token generation server 10 corresponds to the token generation device according to the present invention.

The token generation server 10 is a computer that functions as a server connected to a network, and is equipped with a CPU, a main memory, and an auxiliary storage device such as an HDD. In the token generation server 10, a program stored in the auxiliary storage device is read into the main memory, and a predetermined function is realized by executing arithmetic processing with the CPU.

The physical configuration of the computer that constitutes the token generation server 10 is not particularly limited, and functions other than the generation and issuance of tokens and reception of token purchase requests in the present invention may be provided in the same computer. It may be. Moreover, each function necessary for the present invention may be physically realized by one computer, or may be realized by a plurality of computers working together.

The event occurrence information receiving unit 11, token generating unit 12, purchase request processing unit 13, and token issuing unit 14 of the token generation server 10 are all functionally specified, and are stored in an auxiliary storage device such as an HDD. The programs corresponding to the functions of the respective functional blocks are read into the main memory, and the CPU executes arithmetic processing to realize the functions corresponding to the respective functional blocks.

A predetermined storage area of an auxiliary storage device such as an HDD is allocated to the approver list storage section 15, token generation condition storage section 16, and purchase applicant list storage section 17 of the token generation server 10. These storage areas are not required to be physically provided in one computer, but may be provided in a distributed manner across multiple computers, such as computers configuring a database server.

The event detection devices 20, 21, 22, etc. are various devices used to detect a specific moment when a predetermined event occurs. For example, if the event occurs at a soccer goal, the event detection devices 20, 21, 22, etc. Cameras that record video, microphones that continuously collect sounds from the stadium, sound and vibration meters that continuously measure the volume and amount of vibration in the stadium, and equipment used by the referee when an event such as a goal is decided. Examples include a switch to be pressed, a sensor that can recognize when a soccer ball has passed through a goal post, and a smartphone carried by match officials and spectators that can notify the token generation server 10 of a goal decision by operating an app.

The information providing servers 30, 31, 32, etc. correspond to servers that provide SNS services, servers that are connected to event detection devices 20, 21, 22, etc. installed in stadiums, and their configurations are not particularly limited. For example, there is a function to analyze information posted on SNS and notify the token generation server 10 of the occurrence of an event, or a function to notify the token generation server 10 of the occurrence of an event, or a function detected by event detection devices 20, 21, 22, etc. installed at the stadium. A function that relays the transmission of event occurrence information related to the occurrence of an event to the token generation server 10, an event occurrence related to the occurrence of an event generated by analyzing information detected by the event detection devices 20, 21, 22, etc. It can include a function of transmitting information to the token generation server 10, etc.

The approver terminals 40, 41, 42, etc. can be connected to a network (such as the Internet) and can send and receive data to and from the token generation server 10, allowing a predetermined approver to perform an operation to approve an event that has occurred. However, its configuration is not particularly limited, and network terminals such as smartphones, tablet computers, and PCs (personal computers) can be used.

The purchaser terminals 50, 51, 52, etc. connect to a network (such as the Internet) and exchange data with the token generation server 10, which can perform operations to purchase tokens issued for a predetermined event. The network terminal is capable of transmitting and receiving information, but its configuration is not particularly limited, and network terminals such as smartphones, tablet computers, and PCs (personal computers) can be used.

The blockchain network 60 is a decentralized network that is used to record transactions of cryptographic assets, etc., and is capable of recording transactions and cannot be tampered with. Used to record information.

On the premise of the above configuration, the processing flow of the present invention will be explained along the flowcharts of FIGS. 3 and 4. First, the processing flow for issuing a token will be explained using the flowchart of FIG.

In the token generation unit 12 of the token generation server, the event occurs among the approvers who are required to approve the occurrence of the event for which the token is issued and obtain an electronic signature, depending on the type of token to be generated. A static approver that can be previously specified is specified (S1000). As shown in the example of FIG. 5, approvers who require approval are specified in the approver list stored in the approver list storage unit 15 according to the type of the target event. An approver who can be identified previously falls under a "statically identified approver." For example, in the list of approvers shown in FIG. 5, the static approvers regarding the event of determining a goal include A, the league administrator, and B, who serves as the referee for the match in question. Incidentally, if the chief referee of the match cannot be specified at this point, the chief referee may be treated as an approver who is dynamically specified as will be explained later.

The event occurrence information receiving unit 11 of the token generation server 10 monitors the occurrence of an event that is a target of a token (S1010), and an event detection device 20 consisting of a camera, a microphone, a sensor, etc. to detect the occurrence of the event. etc., collects information necessary to detect the occurrence of a predetermined event such as a goal being scored, using video and audio of a soccer match, sensing near the goal post, etc. Processing such as image recognition and voice recognition for determining that an event of determining a goal has occurred based on video, audio, etc. can be executed by the main body, such as the event detection device 20, by providing the main body with a function to process these processes. Alternatively, data such as video and audio may be transmitted to the information providing server 30 or the like and executed by the information providing server 30 or the like.

When the event detection device 20, etc. or the information providing server 30, etc. determines that an event of determining a goal has occurred, a token is generated that generates event occurrence information including the date and time of the event, the location, the player who scored the goal, etc. It is transmitted to the server 10 (S2000). Persons involved in an event, such as a player who scores a goal, may be identified, for example, from the jersey number that can be read from the video, or from the name of the player yelled by the spectators included in the audio. , a smartphone owned by a person involved in the match or a spectator may be used as the event detection device 20 or the like, and information regarding the player who scored a goal may be transmitted to the token generation server 10 by operating an application on the smartphone.

Alternatively, instead of using the event detection device 20 installed at a stadium or other site, a server that provides SNS services or a server that distributes sports news may be used as the information providing server 30, etc., and data written to these servers may be used. It is also possible to monitor the information written, and when information notifying that the goal has been determined is written, generate event occurrence information from the written information and send it to the token generation server 10.

In this way, when event occurrence information regarding a newly occurring event is transmitted from the event detection device 20 or the like or the information providing server 30 or the like, the event occurrence information receiving unit 11 is activated in the token generation server 10, and the event occurrence information is receive. If a plurality of event detection devices 20, etc., information providing servers 30, etc. are installed, it is considered that there will be many cases where a plurality of event occurrence information regarding the occurrence of the same event is received.

In the token generation server 10, which receives one or more event occurrence information at the event occurrence information receiving unit 11, the token generation unit 12 determines whether the received event occurrence information is related to the event for which a token is to be generated (here Then, it is checked whether it is related to goal determination (S1020). If it is determined that the event does not correspond to the target event, the process returns to monitoring the occurrence of the event that is the target of the token (S1010).

When it is determined that the received event occurrence information is related to an event for which a token is to be generated, the token generation condition storage unit 16 further determines whether the event occurrence information satisfies the conditions for generating a token. The determination is made by checking the token generation conditions stored in (S1030). FIG. 6 shows an example of token generation conditions stored in the token generation condition storage unit 16. For example, in order to generate a token for the occurrence of an event such as goal determination, it is necessary to The goal scene must be recognized from the images of the installed cameras, and the values detected from the sound and vibration meters must be at least a certain value corresponding to the time when the goal was determined, and the team's official website set up on SNS must be confirmed. It is specified that conditions such as posting a post indicating that a goal has been determined must be met on the page, and these token generation conditions are determined depending on the type of event. If it is determined that such token generation conditions are not satisfied, the process returns to monitoring the occurrence of an event that is a target of a token (S1010).

If the occurrence of an event is determined based on a combination of multiple event occurrence information in this way, in the case of a soccer goal, in addition to the case where a camera malfunctions, for example, it is possible to judge the occurrence of an event based on a combination of multiple event occurrence information. Even if it is confirmed that the ball has crossed the goal line, in cases where the goal was disallowed due to a foul before that, other event information (for example, posted on SNS or a switch pressed by the referee) etc.), it is possible to eliminate cases where it should not be determined that an event has occurred even if some event occurrence information is received, making it possible to more accurately determine the occurrence of an event. . Note that there are no particular limitations on what conditions to set as the token generation conditions, and it is not required that all received event occurrence information satisfy the conditions, but if a certain ratio or more is exceeded, a token will be generated. It may also be a matter of judgment.

When it is confirmed that the token generation conditions are met, the event occurs among the approvers who are required to approve the occurrence of the event for which the token is issued and obtain an electronic signature, depending on the type of token to be generated. A dynamic approver that can be specified by the information is specified (S1040). In the example of FIG. 5, in the list of approvers related to the event of determining a goal stored in the approver list storage unit 15, the player who scored the goal that requires approval is marked as "undetermined", and until such an event occurs, An approver who cannot be identified corresponds to a "dynamically identified approver." Event occurrence information includes information that identifies the player who scored the goal, such as jersey number recognized from video, player name recognized from audio, and player name posted on SNS, so it is possible to use this information to identify the player who scored the goal. Identify specific approvers. Dynamic identification of the approver may be performed by the token generation unit 12 that checks the content of event occurrence information and generates a token, but it may be performed by the event occurrence information reception unit 11 that receives the event occurrence information. information regarding the specified dynamic approver may be passed to the token generation unit 12.

In addition, if the approvers list corresponding to the type of event that occurred includes only statically identified approvers and does not include dynamically identified approvers, the Proceed to the next step of generating approval data without going through the process of dynamically identifying the approver.

As described above, once the static approvers and dynamic approvers who need to approve the content of the event that has occurred, that is, all the approvers who require electronic signatures, are identified, these approvers can Approval data for confirming the content of the event that has occurred and is to be signed is generated (S1050). The approval data includes predetermined information related to the event, such as the type of event, opponent, time and location of the event, which are necessary for the approver to confirm the details of the event that occurred, and this data is used for approval. It forms part of the token that is generated by the person signing the electronic signature.

The generated approval data is sent to the approver terminal 40, etc. owned by each approver for all approvers who require approval (static approvers and dynamic approvers). It is sent together with a notification of an approval request requesting a signature (S1060).

When each approver receives the notification of the approval request and the approval data on the approver terminal 40 or the like (S3000), the approver confirms whether there is any mistake in the content of the event that occurred that is shown in the approval data (S3010). . The approver who has confirmed that there are no mistakes in the content of the event that has occurred and that he/she is the approver related to the event applies an electronic signature to the approval data using his or her private key (S3020). . The approval data with the electronic signature is returned from the approver terminal 40 or the like to the token generation server 10 as an approval result (S3030).

If there is a mistake in the content of the event that occurred, or if you are not an approver related to the event, the approval data will not be electronically signed, and an error message will be sent from the approver terminal 40 etc. to the token generation server 10. A message is returned as an approval result (S3030). Note that some measures to make the approval process more efficient when there are multiple approvers will be described in detail later.

When the token generation server 10 receives the approval results of all approvers from the approver terminal 40 etc. (S1070), the token generation unit 12 determines whether approval has been obtained from all approvers (e.g., whether the received approval data is signed with an electronic signature) If it is determined that approval has been obtained from all approvers, the token configuration information (predetermined information regarding the event used as approval data) generated through the above process is confirmed. In addition to the electronic signature of the approver, it can also include an ID such as a unique serial number given to each token), and a tradable token is issued and published on the blockchain network 60, which is a transaction network. (S1080). The token issued here is a digital certificate consisting of predetermined information regarding the event that occurred, which is the content of the approval data, and electronic signatures proving approval from all approvers who approved the approval data. be.

If an error message is included in the approval result received from the approver terminal 40, etc., the approver who sent the approval data was not originally the target of the electronic signature, or there was an error in the content of the approval data. Therefore, the generated token is not sent to the blockchain network 60, the data of the generated token is discarded (it may be stored for a certain period of time), and the data of the event that is the object of the token is renewed. The process returns to occurrence monitoring (S1010).

Next, the processing flow for accepting the purchase of issued tokens will be described using the flowchart of FIG. 4. This processing flow is based on the premise that a purchase request is accepted before the token is issued, and the token is sold to the purchaser at the same time as the token is issued, or the token is issued with the purchaser as the issuer. However, in the case where the token is initially issued in the name of the issuer, such as the administrator of the token generation server, and the token can be bought and sold after being published on the blockchain network 60, the processing flow described here will not occur. .

In the token generation server 10, for example, at the stage when the token generation unit 12 generates approval data targeting the occurrence of some event (S1050), the token generation server 10 uses the contents of the token specified from the approval data to identify potential purchase requests. be made available to the public. After confirming this information, a purchaser who wishes to purchase newly issued tokens sends a purchase request from the purchaser terminal 50, etc., specifying the ID that identifies him/herself and indicating his/her desire to purchase. (S4000). When the purchase request processing unit 13 of the token generation server 10 receives a purchase request (S5000), the list of prospective purchasers stored in the prospective purchaser list storage unit 17 is updated by writing information regarding new prospective purchasers ( S5010). Figure 7 shows an example of a list of prospective purchasers, which includes information such as the ID of the prospective purchaser that allows identification of the prospective purchaser, information such as the amount (quantity) of the desired purchase, etc. The items are not particularly limited.

In the process flow of token generation in the token generation unit 12 described above, after receiving the approval results from the approvers (S1070), the token is generated when it is determined that approval from all necessary approvers has been obtained. However, if a person who wishes to purchase the token is recorded in the list of prospective purchasers stored in the prospective purchaser list storage unit 17, the token is recorded in the prospective purchaser list before the token is issued (S1080). (S1075), and determine the purchasers to whom the issued token will be sold (all the purchasers may be the purchasers, or some of the purchasers may be selected as the purchasers). In order to limit the number of tokens issued, it is necessary to assign and manage each token with an ID such as a serial number that can be identified), and issue the tokens (S1080). .

The purchase request processing unit 13 sends the purchase information of the token that the purchase request processing unit 13 had requested to purchase to some or all of the purchase applicants who were able to purchase the issued token (S5020), and the purchase information is received by the purchaser terminal 50 or the like owned by each purchaser (S4100).

FIG. 8 shows an example of a method for recording the token issued in S1080 on the blockchain.

As explained above, the token, which is a digital certificate of ownership, includes token configuration information that includes predetermined information about the target event used as approval data and an electronic signature by the approver, and only the token may be sent to the blockchain network 60 as a transaction target and made public (in this case, the transaction recorded on the blockchain will be information related to the issuance of the token, not the information related to the transaction of the token), but before issuance If a purchase request is received and the purchaser has been determined, transaction information for transferring the token from the issuer (X) to the purchaser (A) will be sent to the blockchain network 60 together with the token configuration information. Good too. Alternatively, the purchaser (A) may be positioned as the issuer of the token from the beginning, and the issuance information of the token with the purchaser (A) as the issuer may be transmitted to the blockchain network 60.

In the blockchain network 60 to which the token and transaction information have been sent, for example, it is possible to utilize a function called a smart contract that allows programs to be stored on the blockchain network 60, and the smart contract allows the program to be subject to transactions. In addition to storing tokens in a storage area, each token can be managed by being assigned an ID. If token IDs are recorded in transaction information related to token transactions, and these are blocked and managed in a distributed manner by computers on the blockchain network 60, the blockchain network 60 network can be used without including tokens in transaction data. It will be possible to manage the token itself and its transaction records.

In this way, by utilizing a smart contract that can store programs on the blockchain network 60, it is possible to not only manage the transactions of tokens after they are issued, but also to manage the token generation unit 12, purchase request processing unit 13, and token issuing unit. It is also possible to implement all or part of the processing executed in 14 as a smart contract.

For example, if the token generation conditions and approver list are managed by a smart contract and the event occurrence information received by the event occurrence information receiving unit 11 is sent to the blockchain network 60, the processing of the token generation unit 12 is executed by the smart contract. , it is also possible to generate tokens. The range of functions to be transferred to the smart contract is not particularly limited, and may be all of the processing of the token generation unit 12, etc., or a part of it, such as checking whether the token generation conditions are met, identifying the approver, etc. It is also possible to transfer some of the functions for storing the processes and lists necessary for these processes to a smart contract. In particular, the effect of implementing the processing of the token issuing unit 14 on a smart contract is significant, and it is a block that ensures that the issued token exists on this blockchain network 60 and that it cannot be copied and can only be transferred. Guaranteed by chain functionality. Additionally, blockchain users have addresses that only they can use. By using this, the processing by the purchase request processing unit 13 becomes easier, and the token transfer to the purchaser after the token is issued can be reliably executed. In addition, by managing the approver list recording section 15 and the token generation condition recording section 16 on a smart contract, that is, on a blockchain, a third party can also check the contents, and the list at a certain point or Since you can check the rules, it can also be used for record keeping.

FIG. 9 shows a mode in which the present invention is implemented as a token generation system consisting of two or more computers connected via a network, in which the functions of the token generation server 10 described so far are realized using smart contracts on a blockchain. Shows an overview of the system configuration. In this embodiment, all or part of the processing executed by the event occurrence receiving unit 11, the token generating unit 12, the purchase request processing unit 13, and the token issuing unit 14 in the token generating server 10 of FIG. The corresponding processing will be transferred to a smart contract on the blockchain. A smart contract is a program that operates on a node placed on a blockchain, and it includes all or part of the processing executed by the event occurrence receiving section 11, the token generating section 12, the purchase request processing section 13, and the token issuing section 14. A program (token generation program, etc.) that executes the process corresponding to the section is executed at any node (may be all nodes or may be limited to some nodes) that constitutes the blockchain network 60. The processing results executed by these nodes are mutually verified between nodes storing the smart contract program or between nodes dedicated to verification, generating and issuing tokens, and conducting transactions related to the purchase of tokens. Record.

A program corresponding to a smart contract such as such a token generation program is a program corresponding to a smart contract from a computer connected to a network such as a token generation server 10 operated by a business operator that manages tokens issued according to the present invention. is distributed to each node where it is stored.

In addition, if all or part of the processing executed by the token generation unit 12, purchase request processing unit 13, and token issuing unit 14 is transferred to the smart contract, transaction information etc. sent by the token approver or purchaser will be There will also be cases where the smart contract program is sent to the node where the smart contract program is stored without going through the token generation server 10.

Next, the approver mentioned earlier will explain the process in which the approver electronically signs the approval data from the request for approval to the approver in S1060 to the reception of the approval result in S1070, which was explained in FIG. Below are some ideas for streamlining the approval process when there are multiple people involved. There are two possible ways to improve the efficiency of the approval process: improving the procedure and improving the keys used for electronic signatures, and there are also two possible ways to improve the efficiency of the approval process.

First, as for improving the procedure, there are two methods: one in which all approvers who require electronic signatures individually apply their electronic signatures, and the other in which the electronic signatures are performed in a certain order. FIGS. 10 and 11 show the flow of each electronic signature. Note that some processes are omitted in these figures to clearly show the framework of the approval process.

FIG. 10 shows the flow of processing when approvers individually apply electronic signatures. The token generation server 10 notifies each approver's approver terminal 40 of the approval request. Each approver checks the contents of the received approval data, and when they confirm that there are no errors in the contents, each approver signs an electronic signature using the private key that each approver owns. When the electronic signature is completed, each signer returns the signed approval data to the token generation server 10 from the approver terminal 40 or the like. Thereafter, the token generation server 10 proceeds with the token generation process using the received signed approval data.

FIG. 11 shows the flow of processing when each approver sequentially applies an electronic signature to approval data. Approver A, who has received a notification from the token generation server 10 of a request for electronic approval of the approval data, attaches an electronic signature to the approval data, and then requests the next approver to give an electronic signature to the approval data. After the final approver signs the electronic signature, the final approver sends the approval data with the electronic signature as a processing result to the token generation server 10. In addition, although the flow shown in FIG. 10 is to request the next approver for an electronic signature in order, if some kind of problem occurs that causes the electronic signature process to diverge, the request is sent to the token generation server 10 instead of the next approver. The order in which the information is transmitted between approvers may be changed depending on the actual operation.

FIGS. 12 and 13 show images of approval data with electronic signatures generated by the flows of FIGS. 10 and 11, respectively. Although the ultimately generated data structure looks the same, the content of the data will be different because the subject of the electronic signature is different.

Next, we will explain how to devise a key for use in electronic signatures. With either of the two methods described below, the number of electronic signatures can be limited to one at the minimum, allowing multiple people to send and receive electronic signatures with just one signature, and the number of electronic signatures sent and received in the electronic signature process This makes it possible to reduce the amount of data used.

The first method utilizes a mechanism similar to PKI (Public Key Infrastructure). In an example targeting a soccer goal scene, the league administrator, who is the first approver, becomes the root certification authority, and out of the key pairs used for signatures by each team, the league administrator's electronic certificate is used for the public key. Have it signed. In addition, the key used by the player who scores a goal to make an electronic signature will be affixed with an electronic signature by the team. This makes it possible to reduce the number of approvers who must provide electronic signatures. FIG. 14 shows an image of this hierarchical relationship of keys. By assigning relationships to the keys used for electronic signatures in this way, it is possible to suppress the amount of data generated by electronic signatures.

The second method is to generate a special key for use in digitally signing a token, and an image of this method is shown in FIG. 15. Each approver has a key pair used for electronic signatures. In this method, a dedicated key for use in digitally signing a token is newly generated from the signature keys of multiple approvers, and the digital signature is performed using that key. If such a key can be generated, the electronic signature process itself only needs to be processed once, the data with an electronic signature is limited to one item, and it is also possible to guarantee that all approvers have applied electronic signatures. In addition, if the public key required to verify the contents of this electronic signature can be derived from the public key held by each approver, there is no need to hold the generated private key pair itself. It disappears. If a service exists that safely stores the approver's key information, it would not be so difficult to collect the approver's private key, and the process of generating the private key would also prevent the private key information from being leaked to the outside. It is possible to safely generate and discard keys without any problems.

The method described above is the basic pattern of a process in which an approver applies an electronic signature to approval data. It is possible to use these methods individually or in combination depending on the actual operation, but the signature method to be adopted can be maintained as a system setting value, or it can be stored in a token. It may also be set in the generation unit 12 or the token generation condition storage unit 16.

Furthermore, a smart contract placed on the blockchain network 60 and a transaction record function of the blockchain network 60 can also be used in the process in which the approver electronically signs the approval data. FIG. 16 shows an example of this method, and in this example, it is assumed that tokens are issued using a smart contract. Note that when making a processing request (transaction transmission) to the blockchain network 60, the processing requester signs the transaction. A case in which this signature is treated as one for a token and approvers sign in order as shown in FIG. 11 (FIG. 13) will be described.

When token configuration information is generated by the token generation server 10, the administrator of the token generation server 10, which is the issuer of the token, electronically signs the token issuance transaction that includes the token configuration information and transfers the information to the blockchain network. Send to 60. In the blockchain network 60, token configuration information is stored in a predetermined storage area by a smart contract, and a unique ID (token ID) that can uniquely distinguish the token is assigned (when multiple tokens are issued for the same event). A unique token ID is issued for each token), and a token is issued. The token holder at this point is the token issuer, such as the administrator of the token generation server 10. When the token is issued in this manner, a token issuance completion notification including the assigned token ID is sent to the token generation server 10.

When the token generation server 10 receives the token issuance notification including the token ID, the token generation server 10, which is the issuer of the token, sends the token ID and the transaction information specifying the league administrator who is the first approver as the transmission destination. 10 administrators etc. provide electronic signatures and send the information to the blockchain network 60. In the blockchain network 60, transaction information is written into blocks as transaction records and is managed in a distributed manner. As a result, the token identified by the token ID is transferred from the token issuer to the league manager (ownership of the token is transferred from the token issuer to the league manager). When the recording of the transaction is completed, a notification to that effect is sent to the approver terminal 40 of the league manager designated as the destination.

The league administrator's approver terminal 40, etc., which receives the notification that the transaction recording has been completed, enters the token ID and the transaction information that specifies the player who scored the goal, who is the second approver, as the destination. The league administrator, who is the approver, signs the digital signature and sends the information to the blockchain network 60. In the blockchain network 60, transaction information is written into blocks as transaction records and is managed in a distributed manner. As a result, the token identified by the token ID is transferred from the league manager to the player who scored the goal (ownership of the token is transferred from the league manager to the player who scored the goal). When the recording of the transaction is completed, a notification to that effect is sent to the approver terminal 40 of the player who scored the goal designated as the destination.

The approver terminal 40 of the player who scored the goal, which has received the notification that the transaction recording has been completed, sends the second approver, the goal, to the token ID and the transaction information that specifies the token purchaser as the destination. The selected player signs an electronic signature and transmits the information to the blockchain network 60. In the blockchain network 60, transaction information is written into blocks as transaction records and is managed in a distributed manner. When the recording of the transaction is completed, a notification to that effect is sent to the purchaser terminal 50 or the like of the purchaser designated as the destination. In this way, the purchaser who desired to purchase the token becomes the owner of the token identified by the newly issued token ID.

Through the flow explained above, by utilizing the smart contract functions of the blockchain network 60, the issued tokens are approved by the approver, and the issued tokens are transferred to the purchaser in this flow. is also possible. Since there is no need to send token configuration information such as event information to the approver, this method is suitable for suppressing the amount of data sent and received in the electronic signature process. Similarly, since the signature information included in the token configuration information can be replaced with the signature added to the transaction sent to the blockchain, the amount of data to be managed can be reduced.

Note that the program for executing the above-mentioned approval process etc. operates on a node on the blockchain 60 where the program corresponding to the smart contract is stored, but it does not operate on the node on the blockchain 60 where the program corresponding to the smart contract is stored. Communication such as sending and receiving transaction information with the player's approver terminal 40, etc., and the purchaser's purchaser terminal 50, etc. does not go through the token generation server 10, but instead is carried out by the node storing the program corresponding to the smart contract or its This can be done via a computer connected to the node.

The tokens issued by the present invention are published on the blockchain network 60 and can be traded, allowing users to own a specific "moment" such as a soccer goal scene and make it the subject of trading. become. Token holders may, for example, be provided with some kind of service related to the event for which the token is being used (e.g., allowing them to view a video related to the event, or providing autographs from players related to the event). It is also conceivable that the value of the tokens can be further increased by providing discounts on viewing fees for games of teams related to the event, granting reservation rights to view future content related to the event, etc.).

10 Token generation server 11 Event occurrence information reception section 12 Token generation section 13 Purchase request processing section 14 Token issuing section 15 Approver list storage section 16 Token generation condition storage section 17 Purchase applicant list storage section 20 Event detection device 21 Event detection device 22 Event detection device 30 Information provision server 31 Information provision server 32 Information provision server 40 Approver terminal 41 Approver terminal 42 Approver terminal 50 Purchaser terminal 51 Purchaser terminal 52 Purchaser terminal 60 Blockchain network

Claims (10)

A token generation device that generates a token that is a digital certificate of ownership for a predetermined event,
an event occurrence information receiving unit that receives event occurrence information regarding the occurrence of an event for which a token is to be issued;
The event occurrence information receiving unit determines the content of the event that occurred based on the event occurrence information received, generates predetermined information regarding the event , and generates a token for the event stored in the approver list storage unit. Information that identifies one or more approvers who require approval for the event from an approver list that specifies approvers whose approval is required for generation, and proves approval from the one or more approvers. a token generation unit that generates a token targeted at the event that includes predetermined information regarding the event and information certifying approval of the one or more approvers;
A token generation device comprising: The token generation unit generates a token that can be determined to be capable of generating a token targeting a predetermined event stored in the token generation condition storage unit, based on one or more event occurrence information received by the event occurrence information reception unit. 2. The token generation device according to claim 1, wherein the token generation device generates a token for an event whose content is determined from the event occurrence information when it is determined that generation conditions are satisfied. At least one approver list included in the approver list storage unit includes a static approver specified in advance and a dynamic approver specified by the content of the event that has occurred,
If the dynamic approver is included in the approver list corresponding to the event for which a token is to be generated, the token generation unit identifies the approver corresponding to the dynamic approver from the event occurrence information. 3. The token generating device according to claim 1, wherein the token generating device receives information certifying approval from the approver. The token generated by the token generation unit, the issuer of the token, or information regarding the issuer and purchaser of the token are transmitted to a blockchain network or stored in a predetermined storage device to issue the token. 4. The token generating device according to claim 1, further comprising a token issuing unit that records transaction information. It is equipped with a purchase request processing unit that accepts purchase requests from those who wish to purchase tokens,
When the token is generated by the token generation unit, the token issuing unit determines whether or not a person who wishes to purchase the token can purchase the token, and if it is determined that the person who wants to purchase the token is able to purchase the token, the person who wants to purchase the token is 5. The token generating device according to claim 4, wherein issuing or transaction information regarding the token is recorded as a token issuer or a purchaser of the token. A token generation system consisting of two or more computers capable of transmitting and receiving data via a network, which generates tokens that are digital rights certificates for predetermined events,
an event occurrence information receiving unit that receives event occurrence information regarding the occurrence of an event for which a token is to be issued;
The event occurrence information receiving unit determines the content of the event that occurred based on the event occurrence information received, generates predetermined information regarding the event , and generates a token for the event stored in the approver list storage unit. Information that identifies one or more approvers who require approval for the event from an approver list that specifies approvers whose approval is required for generation, and proves approval from the one or more approvers. a token generation unit that generates a token targeted at the event that includes predetermined information regarding the event and information certifying approval of the one or more approvers;
A token generation system comprising: The token generation unit generates a token that can be determined to be capable of generating a token targeting a predetermined event stored in the token generation condition storage unit, based on one or more event occurrence information received by the event occurrence information reception unit. 7. The token generation system according to claim 6, wherein the token generation system generates a token for an event whose content is determined from the event occurrence information when it is determined that generation conditions are satisfied. 8. The token generation system according to claim 6, wherein at least a part of the processing executed by the token generation unit is executed by a smart contract on a blockchain network. A token generation method executed by a token generation device that generates a token that is a digital certificate for a predetermined event, the method comprising:
an event occurrence information receiving step in which the token generation device receives event occurrence information regarding the occurrence of an event for which a token is to be issued;
The token generation device determines the content of the event that occurred from the event occurrence information received in the event occurrence information receiving step , generates predetermined information regarding the event , and generates the event stored in the approver list storage unit. Identify one or more approvers who require approval for the event from the approver list that specifies the approvers whose approval is required to generate a token for a token generation step of generating a token targeted at the event that includes predetermined information regarding the event and information certifying approval from the one or more approvers; ,
A method for generating a token, characterized by having the following. A method for generating a token, which generates a token that is a digital certificate of ownership for a predetermined event, and is executed by a token generation system composed of two or more computers capable of transmitting and receiving data via a network, the method comprising:
an event occurrence information receiving step in which the token generation system receives event occurrence information regarding the occurrence of an event for which a token is to be issued;
The token generation system determines the content of the event that occurred from the event occurrence information received in the event occurrence information receiving step , generates predetermined information regarding the event , and generates the event stored in the approver list storage unit. Identify one or more approvers who require approval for the event from the approver list that specifies the approvers whose approval is required to generate a token for a token generation step of generating a token targeted at the event that includes predetermined information regarding the event and information certifying approval from the one or more approvers; ,
A method for generating a token, characterized by having the following.

Images