Information processing methods and computer programs

Abstract

To provide an application performance processing method, an application performance processing system, and an application linking method that realize information sharing between applications using a blockchain system.SOLUTION: In an application performance processing method, a device that provides an application acquires application account data of a user of the application and blockchain account data of the user in a blockchain system, and transmits a request to the blockchain system in which a token based on the user's usage performance linked to the application is imparted to the blockchain account data of the user. The blockchain system accepts a request to confirm the presence or absence of a token for the user, the amount of tokens, and contents or condition data of the token.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] This application claims the benefit of priority of U.S. Provisional Patent Application No. 62 / 953,738, filed on December 26, 2019, which is incorporated herein by reference in its entirety.

[0002] The present invention relates to the use of blockchain Information processing methods and computer programs thereof.

Background Art

[0003] In recent years, regarding digital content (games, animations, TV content, radio content, comics, magazines, newspapers, etc.), not only individual consumption of primary content (playing games, watching animations, watching TV content, listening to radio content, reading comics, reading magazines, reading newspapers, etc.), but also n - th content consumption by communities has been actively carried out. That is, the secondary business circle of digital content is expanding. Also, in parallel, due to the diversification of media through which individuals (content creators, sports players, entertainers, etc.) can transmit content, for these individuals as well, the range of content consumption has widened as in the case of the digital content (watching the private life of professional sports players through a YouTube (registered trademark) channel, etc.).

[0004] Moreover, in that secondary business circle, it is constructed across a plurality of applications (for example, in the case of games, the game itself, video distribution platforms, SNS, etc.). In the cross - application in the secondary business circle, information cooperation between applications becomes an issue. In order to implement cooperation by reducing the activities in one application to the activities in the other application, it is necessary to link the accounts of a specific user in each application between the applications.

[0005] In traditional application integration, one application has developed and provided an API (Application Programming Interface) to provide user information (e.g., Patent Document 1). [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2019-057778 [Overview of the Initiative] [Problems that the invention aims to solve]

[0007] When integrating through API provision, challenges include reducing API development and operation costs, as well as security risks.

[0008] This invention was made in view of these circumstances, and realizes information sharing between applications using a blockchain system. Information processing methods and computer programs The purpose is to provide. [Means for solving the problem]

[0009] An application performance processing method according to one embodiment of the present disclosure involves an application provider acquiring the application account data of the application user and the blockchain account data of the user in a blockchain system, sending a request to the blockchain system to grant tokens based on the user's usage history associated with the application to the user's blockchain account data, and the blockchain system receiving a request to confirm data regarding the existence of the tokens for the user, the amount of the tokens, and the content or conditions of the tokens. [Effects of the Invention]

[0010] According to this disclosure, it is possible to use a blockchain system to connect applications in a low-cost and secure manner without the development and operation costs of APIs. [Brief explanation of the drawing]

[0011] [Figure 1] This is an overview diagram of the system disclosed. [Figure 2] This is a sequence diagram illustrating the basics of application integration processing within a system. [Figure 3] This is a sequence diagram showing the processing procedure of an existing method for application integration in a comparative example. [Figure 4] This is a block diagram showing the configuration of an information terminal device. [Figure 5] This is a block diagram showing the configuration of the control device. [Figure 6] This is a block diagram showing the configuration of nodes in a blockchain system. [Figure 7] This sequence diagram shows an example of the authentication process procedure in application integration. [Figure 8] This is a sequence diagram showing an example of the procedure for verifying the contents of a token. [Figure 9] This is a sequence diagram illustrating an example of processing execution based on ticket-type tokens. [Figure 10] This is a schematic diagram of the system in Example 1. [Figure 11] This is a sequence diagram showing an example of the inter-application communication procedure in Example 1. [Figure 12] This is a sequence diagram showing an example of the inter-application communication procedure in Example 1. [Figure 13] This is a schematic diagram showing the structure of the rights token corresponding to the nth-order usage-related rights in Example 2. [Figure 14] This is a schematic diagram of the system in Example 2. [Figure 15] This is a sequence diagram showing an example of the inter-application communication procedure in Example 2. [Figure 16] It is a sequence diagram showing an example of the cooperation procedure between applications in Example 2.

Embodiments for Carrying Out the Invention

[0012] The present disclosure will be specifically described with reference to the drawings showing its embodiments.

[0013] In the present disclosure, a "blockchain system" refers to a system that includes a plurality of computers capable of communicating with each other and a network connecting the plurality of computers, and creates a blockchain by distributed processing of the plurality of computers. Transactions required are executed in the blockchain, and the results are incorporated.

[0014] As an example of secondary business circle content consumption, playing a game, which is primary content, is distributed on a video distribution platform. Video distribution of game play, especially live distribution, enables consumption such as "watching with other viewers" the secondary content of "game play videos of others" and "the distributor and viewers chatting on SNS" with the secondary content as the theme to be completed and established online. The total viewing time of the distributed videos is estimated to reach hundreds of millions of hours per month on major video distribution platforms, and the secondary business circle of the primary content of games is actually showing a great upsurge.

[0015] For businesses that produce or operate games, which are the primary content, the importance of metrics related to the secondary market, such as the number of viewers for each game in live streams, is increasing. For example, some online games with hundreds of millions of players have set such metrics as KPIs (Key Performance Indicators) and have incorporated official partner programs centered on live streaming to intentionally stimulate the secondary market. An official partner program, for example, treats high-quality streamers who meet certain conditions as partners and supports their online social activities with various non-financial benefits.

[0016] However, the challenge in revitalizing secondary markets built across different applications such as the game itself, distribution platforms, and social media is information sharing between applications. Even in the example of game streaming mentioned above, cross-platform interaction occurs between the "game" application itself and the application for the video distribution platform. If a game operator wants to evaluate video streaming activities related to a particular game and provide some kind of reward (such as item granting) to streamers when they play that game, they need to link the streamer's account between the game and the video distribution platform.

[0017] When integrating applications, the party providing user information, including usage history and performance data linked to an account—in the example above, the video streaming platform—generally needs to develop and operate an API accessible to the party requesting the information. Furthermore, this API must implement authentication and authorization compliant with appropriate protocols (such as OAuth or OpenID Connect) to control access to the API. This is where the development and operation costs and security risks of the API become a challenge. In particular, even for large organizations, a large-scale data breach of user information such as accounts can result in significant damage, so increasing security risks should be avoided as much as possible.

[0018] The party requesting user information and accessing the API—in the example above, the operator of the specific game—is also subject to development and operational costs and security risks. For example, as a security risk, if the authorization protocol such as OAuth is adopted, the party requesting user information must store confidential information (access token) to access the user information. Storing confidential information poses a significant risk if it is leaked. Security risks and development and operational costs tailored to the API specifications of the integrated applications can become enormous, proportional to the number of integrated applications.

[0019] Given this situation, in order to revitalize the secondary market for content built across applications, a low-cost and secure method of sharing user information (primarily activity records that contribute to the revitalization of the secondary market) is required.

[0020] The application linking method of this disclosure involves an information terminal device storing the application account data of users of the first application and the second application, and the blockchain account data of the user in the blockchain system, sending a request for linking the first and second applications to a first device that provides the first application, or a second device that provides the second application, in association with the blockchain account data, causing the first device to send a request to the blockchain system for the granting of tokens to the blockchain account data based on the user's usage history of the first application, which is associated with the application account data, and causing the second device to obtain data on the presence or absence of the tokens granted to the blockchain account data, the amount of the tokens, and the content or conditions of the tokens.

[0021] In the application integration method disclosed here, publicly available digital assets are tokenized and shared between different applications. Digital assets are things like performance and rights tied to each application program, and are different from cryptocurrencies such as BTC or ETH. The asset of a user's usage history in one application is recorded in the blockchain system and can be confirmed in the other application, which allows the user to exercise their rights in the other application.

[0022] Data recorded in a blockchain system has a high degree of tamper resistance due to its data structure, making it extremely difficult to manipulate recorded data (such as granting rights). Therefore, it enables extremely secure sharing. Costs can also be reduced because there are no API development or operation costs.

[0023] The following will explain in detail how to integrate these applications.

[0024] Figure 1 is a schematic diagram of the system 100 of this embodiment. The system 100 includes a first user information terminal device 1 outside the blockchain system 300, and management devices 2A and 2B for different applications A and B, respectively. In the following embodiment, the cooperation between two applications will be described as an example, but the same applies to cooperation between three or more applications.

[0025] Management device 2A can communicate with an instance based on the program for application A on information terminal device 1 via a network N outside the blockchain system 300, in a client-server relationship. Similarly, management device 2B can communicate with an instance based on the program for application B on information terminal device 1. Management devices 2A and 2B may be implemented by instances of applications A and B on information terminal device 1, respectively.

[0026] In the system 100 of this embodiment, the user has an account (hereinafter referred to as an application account) that allows them to sign in (log in) to either application A or application B on the information terminal device 1. The information terminal device 1 stores sign-in data for each application A and B either in advance or through user input.

[0027] The information terminal device 1 also stores account data in the blockchain system 300 (hereinafter referred to as blockchain accounts) and has access to the blockchain system 300. In this disclosure, "blockchain system" refers to a system that includes multiple computers that can communicate with each other and a network connecting the multiple computers, and creates a blockchain through distributed processing of the multiple computers.

[0028] Management devices 2A and 2B hold blockchain accounts and can broadcast transactions to the blockchain system 300 and view data within blocks incorporated into the blockchain system 300.

[0029] The system 100 of this embodiment utilizes a blockchain system 300 as a digital asset management platform, allowing users to share publicly available user activity records as digital assets between different applications A and B used by the user, by tokenizing them. Here, digital assets are achievements or rights tied to an application, and are different from crypto assets.

[0030] Activity records and digital assets corresponding to rights are implemented as smart contracts in blockchain system 300 and are deployed according to the execution and use of user applications A and B. The status of token ownership in blockchain system 300 is managed by the smart contracts of the digital assets. The smart contracts corresponding to the digital assets will be hereinafter referred to as token contracts.

[0031] In system 100, management devices 2A and 2B each have an account management function that authenticates the user's blockchain account and a digital asset management function that tokenizes the performance in applications A and B as digital assets.

[0032] In the account management function, when the management devices 2A and 2B of applications A and B respectively receive an account linking request from the user's information terminal device 1, they each execute a process to authenticate the existence of the user's blockchain account.

[0033] The management devices 2A and 2B may implement the functions of holding blockchain accounts (including private keys as described later), broadcasting transactions to the blockchain system 300, and viewing data within blocks incorporated into the blockchain system 300 separately from the applications provided by the management devices 2A and 2B. Functions related to the blockchain system 300 (account management function, digital asset management function) may be provided as SaaS or PaaS implemented between the management devices 2A and 2B and the blockchain system 300. These functions may also be available to users through applications running on the information terminal device 1.

[0034] Figure 2 is a sequence diagram illustrating the basics of application integration processing in system 100.

[0035] In system 100, the user's information terminal device 1 sends an application linkage request, including the account data of application A, to the management device 2A through a program for one of the applications A (step S1).

[0036] The authentication process for the user's blockchain account is performed between the information terminal device 1, the management device 2A, and the blockchain system 300 (step S2).

[0037] Based on its digital asset management function, the management device 2A creates a transaction to assign publicly available activity records (excluding crypto assets) in application A linked to the user's account data to the user's blockchain account as digital assets (step S3). The management device 2A broadcasts the created transaction to the blockchain system 300 (step S4).

[0038] In the blockchain system 300, upon receiving a transaction from management device A (step S5), the transaction is verified (step S6) and accepted (step S7). In step S7, the user's token contract updates the token holdings status.

[0039] The user's information terminal device 1 sends an application linkage request, including the account data for application B, to the management device 2B through the program for application B to be linked (step S8).

[0040] The authentication process for the user's blockchain account is performed between the information terminal device 1, the management device 2B, and the blockchain system 300 (step S9).

[0041] The management device 2B verifies the contents of the token associated with the user's blockchain account (step S10) and performs a linking process based on the information verified in step S10 for the user's application account (step S11). The digital assets within the blocks incorporated into the blockchain system 300 can be verified from different applications A and B. Therefore, achievements in application A can be tokenized and used as a basis for redemption in application B.

[0042] Through this procedure, the operators of applications A and B only need to implement authentication and management functions based on the user's blockchain account, eliminating the need to operate APIs for integration with other applications. Since this involves token verification within the blockchain system 300, it can also be implemented securely.

[0043] In the processing procedure shown in the sequence diagram of Figure 2, an application linkage request is sent to the management device 2A when the user's information terminal device 1 receives a user operation. However, the request for linkage is not limited to this; it can be sent at any time, or it can be started during the processing of applications A and B. Alternatively, a request to start linkage may be sent to application A when the request is sent to the management device 2B.

[0044] Figure 3 is a sequence diagram showing the processing steps of an existing method for application integration in a comparative example. The sequence diagram in Figure 3 shows the processing of "OAuth 2.0 Authorization Code Grant". In the existing method, as shown in the sequence diagram in Figure 3, triggered by the integration request, the client used by the user is responsible for redirecting the sending and receiving of authorization requests and authorization codes between applications X and Y. After the authorization code is passed to the target application Y, application X passes an access token to application Y after the authorization code has been verified, application Y sends a request to retrieve user information in application X, and in response, application X sends user information to application Y.

[0045] As shown in Figure 3, existing methods require authentication and authorization using an appropriate protocol, followed by the exchange of access tokens (confidential information). Since application Y must store the access tokens, the operator of application Y not only faces the risk of leakage, but this risk and the development costs of the integration process increase in proportion to the number of integrated applications. On the application X side, as shown in Figure 3, there are development and operation costs for APIs to provide user information, as well as the risk of leakage of user information, which also increase in proportion to the number of integrated applications. In order to promote integration, these increases in risks and costs should be avoided. On the application X side, as shown in Figure 3, the development and operation costs for APIs to provide user information increase in proportion to the number of integrated applications. In order to promote integration, this increase in costs should be avoided.

[0046] The following describes the specific configuration of a system that enables inter-application communication without using APIs or access tokens, as shown in Figure 3.

[0047] Figure 4 is a block diagram showing the configuration of the information terminal device 1. The information terminal device 1 is, for example, a smartphone or a tablet device. The information terminal device 1 may also be a personal computer. The information terminal device 1 can be any device that can communicate data between the electronic signature processing using a private key (Figure 7) described later and the management devices 2A and 2B that perform authentication. The information terminal device 1 may be implemented as a combination of a device (hardware wallet) that specializes in private key management and electronic signature processing and a smartphone or personal computer.

[0048] The information terminal device 1 comprises a processing unit 10, a storage unit 11, a communication unit 12, a display unit 13, and an operation unit 14. The processing unit 10 uses a processor such as a CPU (Central Processing Unit) or GPU (Graphics Processing Unit), and memory, etc. The processing unit 10 may be configured as a single hardware (SoC: System On a Chip) integrating the processor, memory, and further the storage unit 11 and the communication unit 12.

[0049] The storage unit 11 uses flash memory and stores programs and data referenced by the processing unit 10, including the information terminal program 1P. The information terminal program 1P is a program that causes the computer to function as the information terminal device 1 of the system 100 of this disclosure. The storage unit 11 stores blockchain accounts. The storage unit 11 also stores application accounts for each application, including different applications A and B, and it is possible to sign in to the applications using this account data.

[0050] The information terminal program 1P stored in the storage unit 11 may be an information terminal program 8P that was stored on a storage medium 8 readable by a computer, which the processing unit 10 reads and stores in the storage unit 11.

[0051] As shown in Figure 4, the memory unit 11 may store the user's private key in the blockchain system 300. The private key may be stored in the memory of the processing unit 10 or in the memory unit 11 in a way that prevents rewriting (wallet chip). The private key may also be managed in a dedicated hardware wallet for private keys, as described above.

[0052] The communication unit 12 is a communication module that enables communication connections with management devices 2A and 2B and other communication devices. The communication unit 12 uses a network card, a wireless communication device, or a carrier communication module. The communication unit 12 may also use a module that enables communication with the communication units 22 of management devices 2A and 2B via near-field communication.

[0053] The display unit 13 uses a display device such as a liquid crystal panel or an organic EL display. The operation unit 14 is an interface that accepts user operations and uses physical buttons, a touch panel device built into the display, a speaker, and a microphone. The operation unit 14 may accept operations on the screen displayed on the display unit 13 via physical buttons or a touch panel, or it may recognize the operation content from the input voice via the microphone and accept operations in an interactive format with the voice output by the speaker.

[0054] Figure 5 is a block diagram showing the configuration of management devices 2A and 2B. Management devices 2A and 2B may be server computers, desktop or laptop personal computers, or communication terminals such as smartphones or tablet devices. Management devices 2A and 2B are not limited to devices capable of long-distance communication via a network such as the so-called Internet, but may also be devices that communicate data with information terminal device 1 via short-distance communication.

[0055] Management devices 2A and 2B each comprise a processing unit 20, a storage unit 21, and a communication unit 22, respectively. Figure 5 shows only management device 2A. The configuration of management device 2B is the same as that of management device 2A, so a detailed explanation is omitted.

[0056] The processing unit 20 uses a processor such as a CPU or GPU, and memory. Based on the management program 2P stored in the storage unit 21, the processing unit 20 implements authentication functions and asset management functions in the blockchain system 300, including transaction creation and transaction execution. The storage unit 21 uses a hard disk or flash memory to store programs and data referenced by the processing unit 20, including the management program 2P.

[0057] The management program 2P stored in the memory unit 21 may be a management program 9P that was stored on a storage medium 9 read from a computer, which the processing unit 20 reads and stores in the memory unit 21.

[0058] The communication unit 22 is a communication module that enables communication with the information terminal device 1 or the blockchain system 300. The communication unit 22 uses a network card, a wireless communication device, or a carrier communication module. The communication unit 22 may also use a module that enables communication with the communication unit 12 of the information terminal device 1 via short-range communication.

[0059] Figure 6 is a block diagram showing the configuration of a node 30 in a blockchain system 300. A node 30 may be a server computer, a desktop or laptop personal computer, or a communication terminal device such as a smartphone. A node 30 comprises a processing unit 31, a storage unit 32, and a communication unit 33. Furthermore, any device comprising at least a processing unit 31 and a communication unit 33 can have a portion of the processing unit 31 constitute part or all of the node.

[0060] The processing unit 31 uses a processor such as a CPU or GPU, and memory, etc. The processing unit 31 may be configured as a single piece of hardware integrating the processor, memory, and also the storage unit 32 and the communication unit 33. The memory of the processing unit 31 may store the private key that each node 3 uniquely owns. The processing unit 31 then executes various processes based on the node program stored in the storage unit 32, causing the general-purpose computer to function as a node in the blockchain system 300.

[0061] The storage unit 32 uses a hard disk or flash memory to store programs and data referenced by the processing unit 31, including the node program. The storage unit 32 stores the blockchain. The node program includes a program to function as a smart contract (a processing unit 31 that performs predetermined arithmetic operations on a transaction), which will be described later. The aforementioned private key may be stored in the storage unit 32. The storage unit 32 may also store a public key and address based on the private key.

[0062] The communication unit 33 is a communication module that enables communication between the nodes 30. The communication unit 33 uses a network card, an optical communication device, or a wireless communication device, etc.

[0063] The application integration in the system 100 configured in this way will be explained in detail with reference to the sequence diagram.

[0064] Before the basic processing, users acquire digital assets based on their activity history in applications A and B. The user's information terminal device 1 stores blockchain accounts for managing these digital assets. Since a typical blockchain account is associated with one or more asymmetric key pairs, in step S2 of the basic processing, the management devices 2A and 2B for applications A and B can use this to authenticate the user (to verify whether they are truly the owner of that blockchain account).

[0065] The following describes challenge-response authentication using asymmetric keys. Figure 7 is a sequence diagram showing an example of the authentication process in application integration. The steps shown in the sequence diagram of Figure 7 correspond to the details of the "account authentication process" in the process shown in the sequence diagram of Figure 2.

[0066] The processing unit 10 of the information terminal device 1 transmits the blockchain account identifier to the management devices 2A and 2B in response to the account linking request (S1) (S101).

[0067] When the processing unit 20 of the management device 2A (or 2B) receives the blockchain account identifier from the communication unit 22 (step S201), it queries the blockchain system 300 for the existence of the blockchain account (step S202).

[0068] In step S202, the processing unit 20 may determine whether the identifier received in step S201 exists as an account in the blockchain system 300 and whether it holds any tokens. In step S202, the processing unit 20 obtains from the blockchain system 300 the public key itself associated with the blockchain account identifier transmitted from the information terminal device 1, or the information necessary to calculate it.

[0069] The processing unit 20 of the management device 2A (or 2B) generates a pseudo-random number (step S203) and transmits the generated pseudo-random number to the information terminal device 1 that requested the linkage (step S204).

[0070] The processing unit 10 of the information terminal device 1 receives a pseudo-random number from the management device 2A (or 2B) (step S102), and generates an electronic signature for the received pseudo-random number using the private key associated with the user's blockchain account (step S103). The processing unit 10 then sends the generated electronic signature to the management device 2A (or 2B) that sent the pseudo-random number (step S104).

[0071] The processing unit 20 of the management device 2A (or 2B) receives the digital signature (step S205) and determines the public key from the identifier received in step S201 (step S206). In step S206, the processing unit 20 reads the public key if it has obtained the public key itself, or calculates the public key if it has obtained the information necessary for calculation.

[0072] The processing unit 20 uses the pseudorandom number generated in step S203 and the public key determined in step S206 to verify the validity of the digital signature in step S205 (step S207). If it is determined to be valid in step S207, the management device 2A (or 2B) determines that it has successfully authenticated the blockchain account of the user of the information terminal device 1 that sent the cooperation request.

[0073] In the basic processing, in step S3 (see Figure 2), if authentication is successful, the management device 2A or management device 2B grants the user requesting application integration a token related to application A or application B.

[0074] The nature of the tokens to be granted, the conditions for granting the tokens, or the process are not particularly restricted. The patterns of the tokens to be granted are listed below.

[0075] The nature of tokens can be broadly categorized into the following three axes.

[0076] [Substitutability] It may be a fungible token (FT) or a non-fungible token (NFT).

[0077] [Transferability] The tokens granted may be transferable or non-transferable.

[0078] [Incineration feasibility] The tokens granted may or may not be burnable within the blockchain system 300. If incineration is possible, it may be done in a manner that allows the token issuer (management devices 2A, 2B) to do so, or it may be done by the user holding the token (as long as it is possible under certain conditions). "Incineration" may be represented by reducing the amount of tokens, or by metadata such as an incineration flag.

[0079] The basic properties of a token can be defined by a combination of choices along the three axes described above. For example, a token corresponding to some kind of achievement (performance, accomplishment, etc.) in Application A is unique to the holder and cannot be transferred to others. It is desirable that it be usable semi-permanently, so it is reasonable to implement it as non-transferable, non-fungible, and non-burnable. In the case of non-fungible tokens, unit tokens can be identified by data such as token-specific identification information and a unique image created by Application A. If the token is fungible, since the concept of quantity exists, upper limits may be set on the amount of tokens issued or the amount that each blockchain account can hold, transfer, or burn. In addition, metadata related to the token (e.g., relatively large data such as images of achievement assets and detailed descriptions) may be held within the blockchain system 300 or outside of the blockchain system 300. If held outside of the blockchain system 300, one possible method is to publish the metadata in JSON format, for example, using specific link information (URL), and record that link information linked to the token within the blockchain system 300.

[0080] As mentioned above, tokens may be implemented as token contracts. In this case, if the token is non-fungible and non-transferable, the deployed token contract should, for example, have transfer calls disabled. Conversely, if the token is transferable, it should be deployed in a state where transfer calls are possible and the amount can be specified.

[0081] The conditions for granting tokens can be set in conjunction with the concepts and metrics of each application A and B.

[0082] The token granting (S3) process may be implemented, for example, by transferring tokens previously issued by the management device 2A of application A and held in a blockchain account owned (manageable) by the management device 2A to the user's blockchain account. Alternatively, the management device 2A may directly issue tokens to the user's blockchain account. These transfers or issuances may be performed by the management device 2A at any time, or may be performed when a token grant request is received, including application integration by a user who meets the granting conditions.

[0083] In the basic process, step S10 (see Figure 2) involves the processing unit 20 of the linked management device 2B verifying the contents of the token associated with the user's blockchain account. This verification process can be performed at any time once the blockchain account has been authenticated, by referencing the token information held in the user's blockchain account on the blockchain system 300. While the timing can be arbitrary, there are three possible patterns for the timing of token verification. (1) Timing of receiving a request from information terminal device 1 (user) (2) When application B needs to refer to (3) When a token is granted to a user

[0084] The timing of (3) will be explained with reference to the sequence diagram. Figure 8 is a sequence diagram showing an example of the processing procedure for verifying the contents of the token. The entity performing the verification is the management device 2B of application B. The sequence diagram in Figure 8 is performed up to step S9 of the basic processing in Figure 2, that is, when the blockchain account authentication process has been completed on both the cooperating management device 2A and management device 2B.

[0085] The processing unit 20 of the management device 2B determines whether a predetermined monitoring timing has arrived (step S401). If it is determined that the monitoring timing has not arrived (S401: NO), the processing unit 20 returns to step S401 and waits until it is determined that the timing has arrived. The predetermined monitoring timing is, for example, the arrival of a certain period of time. The arrival of the monitoring timing may also be determined by some other event.

[0086] If it is determined that a predetermined monitoring timing has arrived (S401:YES), it is determined whether or not a token has been granted to the user's blockchain account on the blockchain system 300 by the management device 2A of application A (step S402). If it is determined that a token has been granted (S402:YES), it is determined that the verification has been completed (step S403).

[0087] If it is determined in step S402 that no token has been assigned (S402: NO), the processing unit 20 returns to step S401.

[0088] While step S401 is continuously repeated, as shown in the basic processing in Figure 2, when the asset grant transaction is approved by steps S3 to S7 and incorporated into a block in the blockchain system 300, it is determined in step S402 that the grant has been made, and the token grant can be detected.

[0089] In this case, by appropriately setting the monitoring timing, it becomes possible for the management device 2B of application B to immediately detect when a token is issued to a user by the management device 2A of application A.

[0090] First of all, smart contracts (token contracts) operating on the blockchain system 300 have difficulty directly accessing devices outside the blockchain system 300. It is difficult for nodes 3 and other devices within the blockchain system 300 to notify the management device 2B of application B of token allocation. Therefore, if it is necessary to grasp information updates on the blockchain system 300 in as close to real-time as possible, this can be achieved by continuously monitoring updates to the data related to the target blockchain account or target token, as shown in Figure 8.

[0091] As described above, the tokens granted in this embodiment are achievements or rights issued in conjunction with an application, and are different from so-called crypto assets such as BTC and ETH. Therefore, the management device 2A of application A, which is the issuer of the token, or the business operator that manages application A, influences the value of the token. In such cases, it is important to be able to verify not only the ownership of the token but also its issuer during the verification process.

[0092] Blockchain transactions are essentially approved (accepted) after verification of the digital signature generated based on the private key associated with the blockchain account executing the transaction. Therefore, the blockchain account that executed the transaction issuing the token is cryptographically verifiable. In other words, if application A, the token issuer, or the business managing application A, publishes the private key used for token issuance and the corresponding public key (blockchain account address, data that can calculate the public key), application B, the partner application, or its managing business can accurately verify the token issuer. This verification may be carried out in a format that allows for verification of the issuer. For the business of application B, simply confirming the granting of tokens to the user's blockchain account may not be sufficient for approval. Because the token is linked to the blockchain account, it is possible to verify whether the token was legitimately granted by the business of application A, thus enabling verification of the issuer.

[0093] In the basic process, step S11 (see Figure 2) authorizes some kind of processing by the management device 2B of the linked application B based on the rights associated with the verified token. There are two main types of rights associated with a token: (1) A pattern that allows for the exercise of rights indefinitely (membership type) (2) A pattern in which the right is lost after a certain number of exercises (ticket type)

[0094] For the membership type (1), once the authentication process in steps S2 and S9 and the token verification process in step S10 are executed, the rights can be exercised at any time thereafter. For the ticket type (2), the management device 2B needs to store data on whether the rights can be exercised, such as recording the number of times the rights can be exercised or the number of times the rights have been exercised in some form. For example, the number of times the rights can be exercised based on the amount of tokens held can be stored in a memory device inside or outside the management device 2B, and the number can be reduced each time the rights are exercised within application B. If the tokens that are the basis for the exercise of the rights are partially or completely burned each time the rights are exercised, the remaining number of times the rights can be exercised can be reliably managed on the blockchain system 300.

[0095] Figure 9 is a sequence diagram showing an example of processing execution based on ticket-type tokens. Based on the tokens granted based on performance in Application A, the following processing is executed in response to a request from the user's information terminal device 1 who desires processing in Application B.

[0096] The processing unit 10 of the information terminal device 1 transmits the user's blockchain account identifier to the management device 2B of application B based on the user's operation (intention to exercise rights) on the user's operation unit 14 (step S111).

[0097] The processing unit 20 of the management device 2B receives the identifier of the user's blockchain account (step S411), and confirms (acquires) the existence, quantity, or conditions of the token associated with the received identifier (step S412).

[0098] The processing unit 10 of the information terminal device 1 creates a transaction to burn the tokens granted by application A in an amount corresponding to the desired exercise of rights (step S112).

[0099] The processing unit 10 broadcasts (sends) the transaction created in step S112 to the blockchain system 300 (step S113).

[0100] In the blockchain system 300, the transaction broadcast in step S113 is received (step S301). The blockchain system 300 verifies the received transaction against the user's blockchain account (step S302) and accepts it (step S303).

[0101] Upon acceptance in step S303, the transaction is incorporated into the block, and the tokens from application A, which were associated with the user's blockchain account, are burned in the amount specified in step S112.

[0102] After a predetermined time has elapsed since step S412, or in response to a notification from the information terminal device 1, the processing unit 20 of the management device 2B confirms (acquires) the existence, quantity, or conditions of the token associated with the identifier received in step S411 (step S413).

[0103] The processing unit 20 compares the presence, quantity, or conditions of the tokens obtained in step S413 with the presence, quantity, or conditions of the tokens obtained in step S413 to determine whether some or all of them have been incinerated (step S414).

[0104] If it is determined that the material has not been incinerated (no change) (S414: NO), the processing unit 20 returns to step S413 and checks again after a predetermined time has elapsed or triggered by a notification event from the information terminal device 1.

[0105] If it is determined that the token has been incinerated (changed) (S414: YES), the processing unit 20 executes a process that provides benefits to the user in application B according to the content, quantity, or conditions of the requested and incinerated token (step S415), and then terminates the process.

[0106] As shown in the sequence diagram in Figure 9, the tokens granted to the user based on their performance in application A are burned, and the user is given a reward, similar to a ticket, in exchange for the burnt tokens.

[0107] The ticket-type rights exercise shown in the sequence diagram of Figure 9 is basically carried out through communication between the information terminal device 1 used by the user who is the subject of the rights exercise and the management devices 2A and 2B that confirm the exercise of rights. Of course, the exercise of rights is not limited to long-distance communication, including the so-called internet, between the information terminal device 1 and the management devices 2A and 2B. Specific examples of applications for management devices 2A and 2B include devices that perform payment-related rights exercise linked to a POS register, devices that perform rights exercise (unlocking) linked to a smart lock device, and devices that perform rights exercise (unlocking doors or starting the engine) linked to a connected car. These may also be carried out through short-range communication. Furthermore, such ticket-type rights exercise is compatible with trial-type rights (such as the right to view content provided on a monthly subscription-based media or community with time or frequency restrictions), and if the tokens are transferable, diffusion through liquidity can be expected, so it may be implemented in combination with marketing measures.

[0108] These rights are exercised by the communication of digitized information between the information terminal device 1 and the management devices 2A and 2B, but the scope of the rights exercised as a result does not need to be entirely digital. For example, in an environment where the Internet of Things (IoT) is highly developed (such as a smart city), tokens may be issued representing the right to receive personalized services through facilities and mobility within that environment. For example, this could be the right to preferential use of facilities and equipment provided within them (elevators, air conditioning equipment, lighting equipment, internet connection equipment, etc.) or mobility (taxis, buses, etc.). Furthermore, if the facility is a retail store, inventory management may be carried out taking into account the rights held by specific customers.

[0109] The application integration described above will be explained in detail with reference to several examples.

[0110] [Example 1] Example 1 explains application integration using the example of a campaign or loyalty program that takes into account results in the secondary market. In the digital content business, utilizing the secondary market is a crucial challenge. Therefore, with the aim of solving this challenge, it is possible to build a campaign or loyalty program that evaluates not only primary market activities (activities completed within the game, in the case of a game) but also secondary market activities (distribution of gameplay videos), and provides rewards for these activities.

[0111] Figure 10 is an overview diagram of System 100 in Example 1. In Example 1, Application A is a video distribution platform (application), and Application B is an application related to services provided by game operators in the primary market area. Figure 10 corresponds to the overview of System 100 shown in Figure 1, with Applications A and B being a video distribution platform and a game, respectively.

[0112] In the case of streaming gameplay videos, user activity on the video streaming platform corresponds to secondary commercial activity. Therefore, by tokenizing the activity record on that video streaming platform and allowing game operators to refer to those tokens, a system can be built to grant campaigns or loyalty rewards.

[0113] Figures 11 and 12 are sequence diagrams illustrating an example of the inter-application cooperation procedure in Embodiment 1. The sequence diagrams in Figures 11 and 12 show the cooperation between a game and a video distribution platform. Among the processing procedures shown in the sequence diagrams in Figures 11 and 12, procedures that are unchanged from the basic processing procedure shown in Figure 2 are denoted by the same reference numerals and detailed explanations are omitted.

[0114] When an application linkage request is sent from the information terminal device 1 (S1), an authentication process is performed between the management device 2A, which provides the video distribution platform, the information terminal device 1, and the blockchain system 300 (S2).

[0115] Once the authentication process is complete, the processing unit 20 of the management device 2A determines whether the user's usage history of the video distribution platform meets certain conditions, based on the user's application account (service account) included in the linkage request (step S221).

[0116] If the processing unit 20 determines that certain conditions are not met (S221:NO), it returns to step S221 and waits until the conditions are met. If it determines that certain conditions are not met (S221:NO), it is preferable to notify the information terminal device 1 that the cooperation conditions are not met and terminate the process.

[0117] In step S221, the processing unit 20 may determine whether certain conditions are met based on the duration of video streaming, the number of video streams, the number of viewers of the video stream, the number of viewers during live streaming, the number of comments, etc. Alternatively, the processing unit 20 may make a determination based on the duration of video viewing, the number of video views, and the total amount of "donations" for the video. The certain conditions may be stored in the memory unit 21 in advance and may be rewritable by the administrator. The certain conditions may include whether the streamed video contains a game application, or whether the viewed video contains a game application.

[0118] If it is determined that certain conditions are met (S221: YES), the processing unit 20 creates a transaction to grant assets (performance) as performance tokens to the blockchain account received in steps S1 and S2, based on the usage history of the video distribution platform (step S222). The processing unit 20 broadcasts the created transaction (S4).

[0119] The broadcasted transaction is received (S5), verified (S6), and accepted (S7) by blockchain system 300.

[0120] The processing unit 10 of the information terminal device 1 sends an application linkage request to the game application management device 2B (S8). As a result, authentication processing is performed between the management device 2B, the information terminal device 1, and the blockchain system 300 (S9).

[0121] The processing unit 20 of the management device 2B verifies the performance token associated with the blockchain account (S421) after the authentication process for the user's blockchain account has been completed. If the performance token cannot be verified in step S421, the linkage process is interrupted at this point. In this case, it is desirable that the information terminal device 1 be notified that the linkage has failed.

[0122] Once the contents have been confirmed, the processing unit 20 of the management device 2B of the game application in Example 1 creates a transaction to grant the user's blockchain account a rights token for rights that can be exercised in the game application or the linked video distribution platform thereafter (step S422).

[0123] The processing unit 20 of the management device 2B broadcasts (sends) the transaction created in step S422 to the blockchain system 300 (step S423).

[0124] The transaction sent in step S423 is received by the blockchain system 300 (step S321), verified (step S322), and accepted (step S323).

[0125] This allows users to obtain rights tokens that can be used later in the game application based on their usage history on the video streaming platform. No APIs are used in this process, and the blockchain system 300 only needs to receive, verify, and accept the transaction (assets are implemented as token contracts), eliminating the need for a large-scale process.

[0126] Rights tokens may not only be returned to users as exerciseable within the game application, but may also be rights usable in applications other than game applications, including video streaming platforms. For example, a right may be the right to receive a certain discount on an e-commerce site that sells merchandise related to the game application. Alternatively, a right may be the right to participate in a beta test of another game application (which may be a sequel) provided by the same business operator related to the game application. Alternatively, a right may be the right to participate in a community (group chat, salon) related to the game application. Alternatively, a right may be the right to enter a specific facility (which may be physical or virtual) related to the game application.

[0127] Providers of game applications can freely combine such achievements and rights to build campaigns and royalty systems that revitalize the secondary market for their games. Of course, achievements or rights related to games are not limited to the examples given above. In addition to using a video distribution platform, an achievement could be made by designating a related application to the game application as Application A and purchasing a certain amount of game-related goods on an e-commerce site accessed from that related application. Alternatively, an achievement could be made by designating a social networking service (SNS) application as Application A and making a certain number of posts with hashtags related to the game application on SNS. Furthermore, an achievement could be made by designating a system related to the operation of an eSports tournament as Application A and achieving a certain level of performance in a specific tournament.

[0128] Thus, any valuable activity that occurs in applications other than games (secondary market areas) can be considered an achievement related to the game application. Naturally, the same approach can be used to stimulate the secondary market areas for non-game related activities as well.

[0129] In addition to leveraging achievements in the secondary market, it is also possible to revitalize the secondary market by utilizing achievements in the primary market. By rewarding achievements in the game application (clearing specific stages, achieving a certain score, ranking high) with rights as described in Example 1, it is expected that engagement with the game will be enhanced from multiple angles, spanning both in-game and external aspects.

[0130] Furthermore, a third party, neither the provider of the application that generates the achievements (such as a video streaming platform) nor the provider of the application that directly utilizes the achievements (such as a game application), may provide a dedicated achievement management application to users who possess achievements. Of course, such an achievement management application may be able to manage achievements related to multiple applications, not just those related to a single application.

[0131] [Example 2] Example 2 explains the use of the application for secondary use of copyrighted works (such as posting illustrations). The application linkage method of this embodiment can contribute to revitalizing the appropriate distribution of digital content while preventing the illegal digitization and free distribution of copyrighted works such as manga, illustrations, and videos.

[0132] Given the current situation where various digital content is distributed across diverse applications, managing the nth-stage use of copyrighted works such as manga requires coordination between multiple applications. However, designing, developing, and operating coordination between each application incurs enormous costs. While a model in which each application connects to some kind of common platform system is conceivable, if that common platform system is managed and operated by a single business or organization, that single business or organization becomes the system's SPOF (Single Point of Failure). Furthermore, there is a risk that the business or organization, with its administrator privileges, could arbitrarily infringe upon the interests of other stakeholders. In this case, the risk becomes more serious as the number of applications connecting to the common platform system increases. In other words, future management systems for the nth-stage use of copyrighted works that span many applications require application coordination methods that solve the issues of cost, redundancy, and reliability.

[0133] Therefore, in Example 2, we will explain an example of applying the application linkage method of this embodiment to the management of the nth-th use of the original work.

[0134] Figure 13 is a schematic diagram showing the structure of a rights token corresponding to the nth-order use-related rights in Example 2. As shown in Figure 13, multiple rights tokens can be issued for the ID of the original work, "Content". The "ID" is an identifier (hereinafter referred to as Content ID) that can uniquely identify the digital content (data) of the original work. Specific examples of Content IDs include URLs, DIDs (Decentralized IDentifiers), IPFS (Interplanetary File System) content addresses, or combinations thereof, or the hash of the content itself.

[0135] In Example 2, tokens are managed in a token contract deployed within the blockchain system 300, linked to a content ID for each piece of digital content. This enables the revitalization of the commercial area based on n-th secondary use rights.

[0136] Figure 14 is an overview diagram of System 100 in Example 2. In Example 2, Application A is a publisher system (an application related to content permission management), and Application B is an application for using a social networking service (SNS) that allows posting of content such as images and videos (hereinafter simply referred to as SNS). Figure 14 corresponds to the overview of System 100 shown in Figure 1, with Applications A and B being the publisher system and SNS, respectively.

[0137] Figures 15 and 16 are sequence diagrams illustrating an example of the inter-application collaboration procedure in Embodiment 2. The sequence diagrams in Figures 15 and 16 show the collaboration between the publishing system and the SNS platform. Among the processing steps shown in the sequence diagrams in Figures 15 and 16, steps that are unchanged from those shown in the basic processing procedure in Figure 2 are denoted by the same reference numerals, and detailed explanations are omitted.

[0138] The publisher's system management device 2A provides (transmits) manga data (digital content) to management device 2B so that the data can be reused on social media (step S231).

[0139] The SNS management device 2B receives the manga data (step S431) and stores it (step S432).

[0140] Then, on social media, a user who wishes to use the manga data provided in step S231 sends an application linkage request from the information terminal device 1 (S1). Authentication processing is performed between the management device 2A, which provides system services for the publisher system, the information terminal device 1, and the blockchain system 300 (S2).

[0141] Once the authentication process is complete, the processing unit 20 of the management device 2A determines, based on the user's application account (service account) included in the linkage request, whether the user has paid a certain fee to the publisher system (usage rights management) and whether other conditions are met (step S232).

[0142] If the processing unit 20 determines that certain conditions are not met (S232:NO), it returns to step S232 and waits until the conditions are met. If it determines that certain conditions are not met (S232:NO), it is preferable to notify the information terminal device 1 that the cooperation conditions are not met and terminate the process.

[0143] In step S232, the processing unit 20 may make a decision based on certain conditions, such as the user's payment of fees for using the content, or ownership of points or rights tokens in the service.

[0144] If it is determined that certain conditions are met (S232: YES), the processing unit 20 creates a transaction to grant rights tokens to the blockchain account received in steps S1 and S2, conditional on payment of consideration (step S233). The processing unit 20 broadcasts the created transaction (S4).

[0145] The broadcasted transaction is received (S5), verified (S6), and accepted (S7) by blockchain system 300.

[0146] The processing unit 10 of the information terminal device 1 sends an application linkage request to the SNS management device 2B (S8). As a result, authentication processing is performed between the management device 2B, the information terminal device 1, and the blockchain system 300 (S9).

[0147] The processing unit 20 of the management device 2B verifies the rights token associated with the blockchain account (S433) after the authentication process for the user's blockchain account has been completed. If the rights token cannot be verified in step S433, the linkage process is interrupted at this point. In this case, it is desirable that the information terminal device 1 be notified that the linkage has failed.

[0148] Once the contents have been confirmed, the processing unit 20 of the SNS management device 2B in Example 2 grants permission on the SNS to access the manga data received in step S431 for the user's application account data (step S434), and then terminates the process.

[0149] Step S434 allows users to access and post manga data on social media. For example, users are permitted to publish parody manga with altered dialogue or illustrations with modified panels on social media.

[0150] As explained with reference to the sequence diagrams in Figures 15 and 16 in Example 2, the publisher system that manages the rights to use the manga data tokenizes and grants secondary use rights to the manga to users who meet the conditions, and provides the manga data to applications that want to use the manga. This makes it possible for users to utilize secondary use rights across applications. As shown in the sequence diagrams in Figures 15 and 16, secondary use rights for manga data can be utilized on social networking services (SNS), for example, allowing users to publish derivative content using that manga data.

[0151] In Example 2, we used digital manga content as an example, but of course, it is not limited to this. Various forms of images, audio, and video (illustrations, music, animation, TV programs, etc.) can be considered examples of digital content. The use of secondary usage rights is not limited to social networking services (SNS). Other examples include digital content creation platforms and video distribution platforms (audio distribution applications, radio distribution applications, short-form video SNS, live streaming applications).

[0152] Tokenizing various rights, not just those related to secondary use, and managing them across applications could potentially solve monetization challenges. For example, token contracts could implement token sales and trading functions, automatically sending sales profits and transaction fees to the original author's blockchain account. This would enable the payment of fair compensation to legitimate original authors through the sale and distribution of various forms of digital content usage rights. These content usage rights could include, for example, viewing / watching rights, secondary use rights such as live streaming, and early access rights to content before its public release.

[0153] The token contract itself, which is linked to the ID of each piece of content and manages the rights to each piece of content, could implement monetization features so that when the rights token is used, crypto assets equivalent to sales profits and transaction fees are sent to the original author's blockchain account. This would allow the original author to monetize even in secondary markets.

[0154] As explained in detail above, the application that provides tokens as digital assets (management device 2A) does not need to develop or operate an API to obtain (provide) information about the tokenized and shared digital assets. Since no API is used, there is no risk of security vulnerabilities.

[0155] Applications (management device 2B) that utilize tokenized digital assets do not need to change their implementation to match the applications they interact with, as long as they build a token contract. This avoids the increased development costs associated with an increasing number of interacting applications. When accessing information publicly available on the blockchain, the confidential information required for OAuth is not needed, thus eliminating the security risks associated with managing such information.

[0156] By implementing a system that allows for verification of the token issuer, token forgery becomes virtually impossible. Therefore, the likelihood of users of digital assets being deceived by false digital asset data can be significantly reduced.

[0157] As explained above, the application integration method disclosed here utilizes blockchain system 300, a highly transparent, decentralized system without a single managing entity, as the management platform for digital assets. This significantly mitigates the redundancy and reliability issues that arise when using a platform system managed by a single organization. Furthermore, the data recorded in blockchain system 300 has a high degree of tamper resistance due to its data structure, making it extremely difficult to manipulate the recorded data (such as granting rights). Such a platform system makes application integration (joint use of content) among competing stakeholders realistically possible.

[0158] The embodiments disclosed above are illustrative in all respects and not restrictive. The scope of the present invention is indicated by the claims, and all modifications within the meaning and scope equivalent to the claims are included. [Explanation of symbols]

[0159] 1. Information terminal device 10 Processing Unit 11 Storage section 13 Display section 14 Control section 1P Information Terminal Program 2 Management device (1st device, 2nd device) 20 Processing Units 21 Memory section 2P Management Program 300 Blockchain Systems

Claims

1. The user's information terminal device and the computer connected to the blockchain system The blockchain account data of the aforementioned user in the blockchain system is obtained, The amount of tokens issued for the user's blockchain account data, the content or conditions of the tokens, Based on the verified token ownership status of the user, permission is granted to use the content associated with the token. Information processing methods.

2. The aforementioned token is granted to the user's blockchain account data based on the user's performance with a specific service. The information processing method according to claim 1.

3. The aforementioned track record refers to the usage record of applications related to digital content corresponding to the aforementioned specific service. The information processing method according to claim 2.

4. Use of the aforementioned content is viewing the aforementioned content. The information processing method according to claim 1.

5. The aforementioned computer, Depending on the user's token holdings, permission will be granted to post content associated with the token. The information processing method according to claim 1.

6. On the user's information terminal device and the computer connected to the blockchain system, The blockchain account data of the aforementioned user in the blockchain system is obtained, The amount of tokens issued for the user's blockchain account data, the content or conditions of the tokens, Based on the verified token ownership status of the user, permission is granted to use the content associated with the token. A computer program that executes a process.

Images