JP7847099B2 - Management systems, management methods, and management programs - Google Patents

Description

This invention relates to a management system, a management method, and a management program.

Tokens and programmable money are attracting attention as means of stimulating the circulation of digital currencies. While digital currencies can only be issued by organizations with financial licenses, such as central banks and financial institutions, tokens and programmable money can be issued by companies in various industries. Furthermore, the security of tokens can be guaranteed by backing them with digital currencies. Also, because tokens have different issuing bodies, they operate on a different network than digital currencies.

Patent Document 1 discloses a technology in which, in a system where coins (digital currency) linked to cash currency and tokens are operated on different networks, the value of a token is guaranteed when an operator issues a token by having a bank lock the operator's coins equivalent to the value of that token.

Japanese Patent Publication No. 2022-167748

However, the technology described in Patent Document 1 has a problem in that, in a situation where the network operating the tokens and the network operating the digital currency are separated, even though there is no complete relationship of trust among stakeholders such as the issuer of the digital currency (e.g., a bank), the token operator, and the token user, only the issuer of the digital currency can confirm the existence of collateral backing the value of the tokens (hereinafter referred to as "token collateral").

In other words, users cannot refer to the collateral backing the tokens in the digital currency network. Therefore, users have no way to verify the true value of the tokens, and are forced to judge their value based on the credibility of the operators.

On the other hand, because fund managers rely on the issuer to manage the collateral backing the tokens, they cannot prove to users that the tokens are backed by collateral. Therefore, when entities with low social credit, such as small and medium-sized enterprises, issue tokens, there is a risk that users will not accept them. This becomes a barrier to the widespread adoption of tokens and digital currencies.

This invention has been made in view of these circumstances, and its purpose is to provide a management system, a management method, and a management program capable of providing users with a means to verify the value of tokens.

One of the present inventions for solving the above problems is a management system comprising: a receiving unit that receives a request for verification of the value of a token from a device having a processor and memory and storing information about the token; a verification unit that obtains information about the collateral assets backing the token related to the verification request from an issuer device that manages the collateral assets backing the token, and verifies the value of the token related to the verification request based on the received verification request and the acquired collateral asset information; and a transmitting unit that transmits the result of the verification to the device.

According to the present invention, a means for verifying the value of a token can be provided to the user.
Other configurations and effects will be clarified by the following description of the embodiments.

This figure shows an example configuration of the currency management system in this embodiment. This figure shows an example of the configuration of a user device. This figure shows an example of the configuration of the operator's device. This figure shows an example of the configuration of the auditor's device. This is a diagram showing an example of the configuration of an emitter device. This diagram shows an example of the configuration of a collateral verification device. This figure shows an example of a token type table. This figure shows an example of a token account table. This figure shows an example of a currency account table. This diagram illustrates how collateral is managed in a currency management system. This diagram illustrates how token collateral is verified in a currency management system. This figure shows an example of a collateral verification sequence for verifying token collateral. This is a processing flow diagram that explains the details of the collateral verification request process. This figure shows an example of a screen displaying the collateral verification results. This is a process flow diagram that explains the details of the collateral verification and management process. This diagram illustrates the overview of the individual collateral verification and management process. This is a processing flow diagram that explains the details of the individual collateral verification and management process. This diagram illustrates the overview of the batch collateral verification and management process. This is a processing flow diagram that explains the details of the batch collateral verification and management process. This is a processing flow diagram that explains the details of the token management process. This is a processing flow diagram that explains the details of the currency management process. This is a process flow diagram that explains the details of the collateral verification process.

Embodiments of the present invention will be described in detail below with reference to the drawings. The following description and drawings are illustrative for illustrating the present invention, and have been omitted and simplified as appropriate for clarity of explanation. The present invention can also be carried out in various other forms. Unless otherwise specified, each component may be singular or plural.
The positions, sizes, shapes, and ranges of the components shown in the drawings may not represent their actual positions, sizes, shapes, and ranges in order to facilitate understanding of the invention. Therefore, the present invention is not necessarily limited to the positions, sizes, shapes, and ranges disclosed in the drawings.
In the following explanation, various types of information may be described using terms such as "table,""list," and "queue," but these types of information may also be represented using other data structures. To indicate independence from data structure, "XX table,""XXlist," etc., may be referred to as "XX information." When describing identification information, terms such as "identification information,""identifier,""name,""ID," and "number" will be used, but these terms are interchangeable.
When there are multiple components with the same or similar function, they may be described using the same symbol but with different subscripts. However, if it is not necessary to distinguish between these multiple components, the subscripts may be omitted in the description.
Furthermore, while the following explanation may describe the processes performed by executing a program, the processor (e.g., CPU, GPU) executes the program, performing defined processes using memory resources (e.g., memory) and/or interface devices (e.g., communication ports) as appropriate. Therefore, the processor may be the primary entity performing the processes. Similarly, the primary entity performing the processes by executing a program may be a controller, device, system, computer, or node having a processor. The primary entity performing the processes by executing a program may be an arithmetic unit, and may include dedicated circuits (e.g., FPGAs or ASICs) that perform specific processing.
A program may be installed from its program source into a device such as a computer. The program source may be, for example, a program distribution server or a computer-readable storage medium. If the program source is a program distribution server, the program distribution server includes a processor and storage resources for storing the program to be distributed, and the processor of the program distribution server may distribute the program to other computers. Furthermore, in the following description, two or more programs may be implemented as a single program, or one program may be implemented as two or more programs.

<System Configuration>
Figure 1 shows an example of the configuration of the currency management system 100 in this embodiment.
The currency management system 100 is a system that guarantees the security of the value of tokens issued by operators by having issuers such as banks secure digital currency as the underlying asset (collateral asset) of the tokens. Operators are businesses such as power companies or retailers, and they issue and manage their own tokens.

Digital currency is a form of currency digitized by a computer system and managed, stored, or exchanged over the internet. There are multiple models of digital currency with different issuers or operational structures. For example, central bank digital currency (CBD) is a digital form of legal tender issued as a liability of the central bank. In CBD digital currency, the central bank issues the currency, and intermediaries such as banks circulate it to users. Private digital currency (PCI) is issued by private companies such as banks. In PCI digital currency, a single company or a consortium of companies issues and circulates the currency. PCI digital currency secures legal tender as backing when issuing the digital currency. Cryptocurrency is a digital currency that utilizes blockchain algorithms. Cryptocurrency is issued and circulated through a decentralized network. Cryptocurrency has no backing assets. In this embodiment, the digital currency is either a central bank digital currency with backing assets or a PCI digital currency.

A token is a digital currency to which attributes or business logic have been added. For example, a token can have functions added to a digital currency such as usage restrictions, expiration dates, or discounts applied when specific conditions are met. For instance, a food coupon that can only be used at restaurants, has an expiration date of less than one year, and offers a 10% discount can be issued as a token. Other examples include "electricity tokens" that can only be used for buying and selling electricity, or "regional development tokens" that can only be used at retail stores or restaurants in a specific area. By making tokens digital rather than paper, issuance and distribution can be made more efficient.

As shown in the figure, the currency management system 100 is configured to include a token system 110 that constitutes a token network (first communication network) for operating tokens, and a currency system 120 that constitutes a currency network (second communication network) for operating digital currency. The token system 110 and the currency system 120 are connected by a wired or wireless communication network N, such as the Internet, LAN (Local Area Network), WAN (Wide Area Network), or dedicated line.

The token system 110 comprises one or more user devices 200, operator devices 300, and auditor devices 400. The operator device 300 is an information processing device used by the operator. The user device 200 is an information processing device used by users who purchase and use tokens from the operator. The auditor device 400 is an information processing device used by auditors who, upon request from users, verify the collateral backing the value of the tokens. Each user device 200, operator device 300, and auditor device 400 communicates with each other to form a token network.

The currency system 120 comprises one or more issuer devices 500 and collateral verification devices 600. The issuer device 500 is an information processing device used by issuers such as banks that issue digital currency. The collateral verification device 600 is an information processing device used by auditors. Each issuer device 500 and collateral verification device 600 is connected to each other for communication, forming a digital currency network.

In the following, the system consisting of the auditor's device 400 and the collateral verification device 600 used by the auditor will be referred to as the management system 1000.

Figure 2 shows an example of the configuration of the user device 200 in this embodiment.
The user device 200 includes a memory 201 such as RAM (Random Access Memory) or ROM (Read Only Memory), an arithmetic unit 202 such as a CPU (Central Processing Unit), an input device 203 such as a keyboard, mouse, or touch panel, an output device 204 such as a display and touch panel, a communication device 205 consisting of a NIC (Network Interface Card), wireless communication module, USB (Universal Serial Interface) module, or serial communication module, and a storage device 206 such as an HDD (Hard Disk Drive) or SSD (Solid State Drive).

The storage device 206 stores the token type table 700, the token account table 800, the token management program 1300, and the collateral verification request program 1100. The token type table 700 holds information about the token types. Details of the token type table 700 will be described later. The token account table 800 holds information about the quantity of tokens held by the operator and each user. Details of the token account table 800 will be described later.

The token management program 1300 executes the process of transferring tokens. Transferring tokens means changing the ownership of the tokens. Details of the process executed by the token management program 1300 will be described later. The collateral verification request program 1100 sends a verification request for the value of the tokens held by the user to the auditor device 400, receives the verification result (the response to the verification request), and outputs the received verification result. Details of the process executed by the collateral verification request program 1100 will be described later. Each of the above programs on the user device 200 is executed by the arithmetic unit 202 reading them from memory 201 or storage device 206.

Figure 3 shows an example of the configuration of the operator device 300 in this embodiment.
The operator device 300 includes a memory 301 such as RAM or ROM, an arithmetic unit 302 such as a CPU, an input device 303 such as a keyboard, mouse, or touch panel, an output device 304 such as a display and touch panel, a communication device 305 consisting of a NIC, wireless communication module, USB module, or serial communication module, and a storage device 306 such as an HDD or SSD.

The storage device 306 stores the token type table 700, the token account table 800, the collateral verification request program 1100, and the token management program 1300, which will be described later. Each of these programs in the operator device 300 is executed when the arithmetic unit 302 reads them from the memory 301 or the storage device 306.

Figure 4 shows an example of the configuration of the auditor device 400 in this embodiment.
The auditor device 400 includes memory 401 such as RAM and ROM, an arithmetic unit 402 such as a CPU, an input device 403 such as a keyboard, mouse, or touch panel, an output device 404 such as a display and touch panel, a communication device 405 consisting of a NIC, wireless communication module, USB module, or serial communication module, and a storage device 406 such as an HDD or SSD.

The storage device 406 stores the token type table 700, the token account table 800, the token management program 1300, and the collateral verification management program 1200, each described later.

The collateral verification management program 1200 implements the functions of the receiving unit 1201, the management unit 1202, and the transmitting unit 1203. The receiving unit 1201 performs a receiving process to receive a verification request for the value of tokens held by the user from the user device 200. The management unit 1202 performs a request process to request the collateral verification device 600 to verify the token related to the received verification request (hereinafter referred to as the "target token"). The management unit 1202 also performs a management process to transfer the collateral asset backing the token related to the verification request from the owner to the auditor by transferring the token related to the verification request from the owner to the auditor. The transmitting unit 1203 receives the verification result from the collateral verification device 600 and performs a transmission process to transmit the received verification result to the user device 200. Details of the processes executed by the collateral verification management program 1200 will be described later. Each of the above programs in the auditor device 400 is executed by the arithmetic unit 402 reading them from memory 401 or storage device 406.

Figure 5 shows an example of the configuration of the light-emitting device 500 in this embodiment.
The issuing device 500 includes a memory 501 such as RAM or ROM, an arithmetic unit 502 such as a CPU, an input device 503 such as a keyboard, mouse, or touch panel, an output device 504 such as a display and touch panel, a communication device 505 consisting of a NIC, wireless communication module, USB module, or serial communication module, and a storage device 506 such as an HDD or SSD.

The storage device 506 stores the currency account table 900 and the currency management program 1400, respectively. The currency account table 900 holds information regarding the currency accounts of the operator and each user. Details of the currency account table 900 will be described later. The currency management program 1400 transfers the collateral backing a token when the token is transferred. Transferring collateral means changing the owner of the collateral. Details of the processing performed by the currency management program 1400 will be described later. Each of the above programs of the issuer device 500 is executed by the arithmetic unit 502 reading them from memory 501 or the storage device 506.

Figure 6 shows an example of the configuration of the collateral verification device 600 in this embodiment.
The collateral verification device 600 includes a memory 601 such as RAM or ROM, an arithmetic unit 602 such as a CPU, an input device 603 such as a keyboard, mouse, or touch panel, an output device 604 such as a display and touch panel, a communication device 605 consisting of a NIC, wireless communication module, USB module, or serial communication module, and a storage device 606 such as an HDD or SSD.

The storage device 606 stores the currency account table 900 (described later), the currency management program 1400 (described later), and the collateral verification processing program 1500, respectively.

The collateral verification processing program 1500 implements the functions of the verification unit 1501. The verification unit 1501, in response to a request from the auditor device 400, obtains information on the collateral backing the target token from the issuer device 500, verifies the value of the target token, and performs verification processing to transmit the verification result to the auditor device 400. Details of the processing performed by the collateral verification processing program 1500 will be described later. Each of the above programs of the collateral verification device 600 is executed by the arithmetic unit 602 reading them from memory 601 or storage device 606.

Each program for the device described above can be recorded and distributed, for example, on a portable or fixed recording medium.

(Token Type Table)
Figure 7 shows an example of a token type table 700. The token type table 700 has the following data items: token ID 701, which sets the token ID of each token type; operator ID 702, which sets the user ID of each operator; collateral ID 703, which sets the type of digital currency that serves as collateral for the tokens; collateral ratio 704; collateral management method 705, which sets the method of managing the collateral; and unit price 706, which sets the current price per unit quantity.

The collateral ratio 704 sets the minimum price percentage that must be secured relative to the current price of the token as collateral. Furthermore, the collateral management method 705 is set to either the first collateral management method "Individual" or the second collateral management method "All". Collateral management method "Individual"
In the "Individual" collateral management method, there is a separate currency account for each token owner (user or operator) and for each type of token. For example, in the "Individual" collateral management method, there is a separate currency account for each token owner and for each type of token, such as a currency account for user A's electricity tokens, an account for user B's electricity tokens, and so on. On the other hand, in the "All" collateral management method, there is a separate currency account for each type of token, for each type of token. For example, in the "All" collateral management method, there is a separate currency account for each type of token, such as a currency account for electricity tokens, a currency account for local shopping street tokens, and so on, for each type of token, belonging to the operator who issues the tokens. In other words, in the "All" collateral management method, collateral is centrally managed in the currency account of the operator who issues the tokens.

(Token Account Table)
Figure 8 shows an example of a token account table 800. The token account table 800 has the following data items: User ID 801, which is set to a user ID that identifies each user or operator; Token ID 802, which is set to a token ID; and Token Quantity 803, which is set to the quantity of tokens held by the user or operator.

(Currency Account Table)
Figure 9 shows an example of a currency account table 900. The currency account table 900 has data items such as User ID 901, which is set to the user ID; Currency ID 902, which is set to the type of digital currency; Balance 903, which is set to the balance of the digital currency; and Attribute Tag 904, which is set to the token ID.

In this embodiment, we will describe the case where the token network in which each user device 200, operator device 300, and auditor device 400 participate is a distributed ledger network such as a blockchain. Therefore, the data in the token type table 700 and the token account table 800 stored in each user device 200, operator device 300, and auditor device 400 are all identical.

Furthermore, this embodiment describes a case where the currency network in which each issuer device 500 and collateral verification device 600 participates is a distributed ledger network such as a blockchain. Therefore, the data in the currency account table 900 stored by each issuer device 500 and collateral verification device 600 are all identical.

Next, we will explain the processes performed in the currency management system 100.

<Collateral management method>
Figure 10 illustrates the method of managing collateral in the currency management system 100. This figure shows the method of managing collateral when the collateral management method is "Individual".

The token network N1, which manages tokens issued by the operator, consists of an operator device 300 and one or more user devices 200. For the sake of clarity, the user device 200 used by user A will be designated "A" and referred to as user device 200A, and the user device 200 used by user B will be designated "B" and referred to as user device 200B, thus distinguishing each user device 200. When user devices 200A and 200B are not specifically distinguished, the "A" and "B" designations will be omitted, and the devices will simply be referred to as "user device 200" or "each user device 200." Meanwhile, the currency network N2, which manages the digital currency that serves as collateral backing the tokens, consists of one or more issuer devices 500.

(Token issuance)
First, the operation of the currency management system 100 when the operator issues tokens will be explained. When the operator device 300 issues tokens, it sends a token issuance request to the issuer device 500 (S1). The token issuance request includes the operator's user ID, the token ID of the token to be issued, and the quantity of tokens to be issued. When the issuer device 500 receives the token issuance request, it secures digital currency equivalent to the amount of the tokens to be issued as collateral in the operator's currency account (S2). The currency account is a virtual account for storing the user's funds. Specifically, the issuer device 500 adds the amount of the tokens to the balance 903 of the currency account table 900 corresponding to the user ID and token ID related to the token issuance request. In the illustrated example, the issuer device 500 secures digital currency equivalent to the price "50" of the tokens issued by the operator device 300 as collateral in the operator's currency account.

(Token purchase)
Next, we will explain the operation of the currency management system 100 when user A purchases tokens from the operator. First, user device 200A sends a token purchase request to operator device 300 requesting the purchase of tokens and pays the price of the tokens to be purchased, "10", in cash or other currency (S11). Operator device 300 sends a quantity of tokens equivalent to the price of "10" paid to user device 200A. At this time, operator device 300 subtracts the quantity of tokens sold to user A from the quantity of tokens held by the operator. Then, operator device 300 sends a token transfer instruction to issuer device 500 instructing the transfer of tokens (S12). The token transfer instruction includes the user ID of the operator who is the source of the transfer, the user ID of user A who is the destination, the token ID of the tokens sold, and the quantity of tokens sold. When the issuer device 500 receives a token transfer instruction, it transfers digital currency at a price of "10" equivalent to the tokens sold by the operator from the operator's currency account to user A's currency account (S13). Specifically, the issuer device 500 transfers the balance 90 of the currency account table 900 corresponding to the user ID and token ID of the transfer source related to the token transfer instruction.
The token sales amount is subtracted from the value of 3, and the token sales amount is added to the value of balance 903 in currency account table 900 corresponding to the user ID and token ID of the transfer destination related to the token transfer instruction.

(Token transfer)
Next, the operation of the currency management system 100 when transferring tokens from user A to user B will be explained. First, user device 200A transmits the tokens to be transferred to user device B. Then, user device 200A transmits a token transfer instruction to issuer device 500 (S21). The token transfer instruction includes the user ID of user A, the source of the transfer, the user ID of user B, the destination of the transfer, the token ID of the transferred tokens, and the quantity of tokens transferred. Upon receiving the token transfer instruction, issuer device 500 transfers digital currency with a price of "10" equivalent to the tokens transferred from user A to user B from user A's currency account to user B's currency account (S22). Specifically, issuer device 500 subtracts the amount of the transferred tokens from the balance 903 value of the currency account table 900 corresponding to the user ID and token ID of the source of the transfer instruction, and adds the amount of the transferred tokens to the balance 903 value of the currency account table 900 corresponding to the user ID and token ID of the destination of the token transfer instruction. In other words, the issuing device 500 transfers the digital currency that is being used as collateral when the tokens are transferred.

Furthermore, communication between the devices constituting the token network N1 and the devices constituting the currency network N2 may be relayed by a relay device that can connect to both the token network N1 and the currency network N2.

On the other hand, if the collateral management method is "All", the issuer device 500 does not transfer the digital currency. For example, in the above example, if the collateral management method is "All", even if tokens are purchased or transferred, the digital currency equivalent to the issued tokens at a price of "50" remains in the operator's currency account and is not transferred to the currency account of user A or user B.

In the currency management system 100 that manages token collateral using the collateral management method described above, only the issuer device 500, which participates in the currency network N2, can confirm the existence of the digital currency backing the tokens. That is, the operator device 300 and the user device 200 do not participate in the currency network N2 and therefore cannot confirm the existence of the digital currency backing the tokens. Therefore, in this embodiment, the value of the tokens held by the user is made verifiable through the auditor device 400 used by the auditor and the collateral verification device 600.

<Overview of the process>
Figure 11 illustrates a method for verifying token collateral in the currency management system 100. As shown in the figure, the auditor device 400 can communicate with the token network N1, which is composed of the operator device 300 and the user device 200. The collateral verification device 600 can communicate with the currency network N2, which is composed of the issuer device 500.

Figure 12 shows an example of a collateral verification sequence for verifying token collateral. Referring to Figures 11 and 12, the operation of the currency management system 100 when user B verifies the value of tokens equivalent to price "10" that they hold will be explained. First, the collateral verification request program 1100 of the user device 200B sends a first collateral verification request to the auditor device 400, specifying the tokens held by user B to be used to verify the value of the collateral (S101). Details of the first collateral verification request will be described later.

The collateral verification management program 1200 of the auditor device 400 retrieves information on the target token specified in the received first collateral verification request from the token type table 700, including the operator ID 702, collateral ID 703, collateral ratio 704, collateral management method 705, and unit price 706. Then, the collateral verification management program 1200 of the auditor device 400 transmits a second collateral verification request containing the retrieved information to the collateral verification device 600 (S102). Details of the second collateral verification request will be described later.

The collateral verification processing program 1500 of the collateral verification device 600, based on the received second collateral verification request, communicates with the issuer device 500 and refers to the currency account table 900 to verify whether there are assets in the currency account that exceed the lower limit price of collateral for the target token. The lower limit price of collateral is the price obtained by multiplying the current price of the target token (the token quantity multiplied by the unit price) by the collateral ratio. The collateral verification processing program 1500 of the collateral verification device 600 determines the verification result as "successful" if the price of the collateral backing the specified token in the referenced currency account is greater than the lower limit price, and as "failed" if the price of the collateral backing is less than or equal to the lower limit price. Details of the collateral verification method will be described later.

The collateral verification processing program 1500 of the collateral verification device 600 then returns the collateral verification result, which is the result of the verification, to the auditor device 400 (S103). Details of the collateral verification result will be described later. The collateral verification management program 1200 of the auditor device 400 then forwards the received collateral verification result to the user device 200B (S104). The user device 200B outputs the received collateral verification result to the output device 204.

This allows user B to verify the value of their tokens. In other words, user B can confirm, through the auditor, whether their tokens truly have value.

Next, we will explain the details of the processes performed by each device in the collateral verification sequence described above.

<Processing of collateral verification request>
Figure 13 is a processing flow diagram illustrating the details of the collateral verification request processing S1100. The collateral verification request processing S1100 shown in this figure is the processing (S110) that the user device 200 collateral verification request program 1100 executes in the collateral verification sequence described above, from the time it sends the first collateral verification request in S101 until it receives the collateral verification result in S104.

First, the collateral verification request program 1100 displays a form screen on the output device 204 that accepts input of the user's user ID and the token ID of the token to be verified as collateral (S1101).

Next, the collateral verification request program 1100 receives input from the user via the input device 203 on the form screen displayed in S1101, and obtains the user's user ID and the token ID of the token to be verified as collateral (S1102).

Next, the collateral verification request program 1100 searches the token account table 800 using the user ID and token ID obtained in S1102 as keys, and retrieves the corresponding record (hereinafter referred to as the "token account record") (S1103).

Then, the collateral verification request program 1100 extracts the token quantity 803 from the token account record obtained in S1103 (S1104).

Next, the collateral verification request program 1100 generates a first collateral verification request (S1105) that includes the user ID obtained in S1102, the token ID obtained in S1102, and the token quantity obtained in S1104.

Then, the collateral verification request program 1100 transmits the first collateral verification request generated in S1105 to the auditor device 400 (S1106).

Subsequently, the collateral verification request program 1100 receives the collateral verification result, which is the response to the collateral verification request transmitted in S1106, from the auditor device 400 (S1107).

Next, the collateral verification request program 1100 displays the collateral verification result display screen 2000, which shows the collateral verification result received in S1107, on the output device 204 (S1108). After that, the collateral verification request program 1100 terminates this collateral verification request process S1100.

(Collateral Verification Results Display Screen)
Figure 14 shows an example of the collateral verification result display screen 2000. The collateral verification result display screen 2000 includes an area 2001 for displaying the collateral verification result. Area 2001 displays the user ID included in the first collateral verification request, the token ID included in the first collateral verification request, the token quantity included in the first collateral verification request, and the collateral verification result for the first collateral verification request ("success" or "failure"). A collateral verification result of "success" indicates that there is collateral equivalent to the price of the token quantity held by the user for the token specified in the first collateral verification request. On the other hand, a collateral verification result of "failure" indicates that there is no collateral equivalent to the price of the token quantity held by the user for the token specified in the first collateral verification request.

<Collateral Verification and Management Processing>
Figure 15 is a processing flow diagram illustrating the details of the collateral verification management process S1200. The collateral verification management process S1200 shown in this figure is the process (S111) that the collateral verification management program 1200 of the auditor device 400 executes in the collateral verification sequence described above, from the time it receives the first collateral verification request in S101 until it transmits the collateral verification result in S104.

First, the collateral verification management program 1200 receives the first collateral verification request from the user device 200 (S1201).

Next, the collateral verification management program 1200 searches the token type table 700 using the token ID included in the first collateral verification request received in S1201, and retrieves the corresponding record (hereinafter referred to as the "token type record") (S1202).

Next, the collateral verification management program 1200 extracts the operator ID 702, collateral ID 703, collateral ratio 704, collateral management method 705, and unit price 706 from the token type record obtained in S1202 (S1203).

Next, the collateral verification management program 1200 determines whether the collateral management method extracted in S1203 is "Individual" or "All" (S1204).

The collateral verification management program 1200 executes the individual collateral verification management process described later (S1205) when the collateral management method is "Individual".

On the other hand, the collateral verification management program 1200, when the collateral management method is "All",
The batch collateral verification management process described later is executed (S1206).

Subsequently, the collateral verification management program 1200 transmits the collateral verification results received from the collateral verification device 600 to the user device 200 in either the individual collateral verification management process (S1205) or the batch collateral verification management process (S1206) (S1207). Afterward, the collateral verification management program 1200 terminates this collateral verification management process S1200.

<Individual Collateral Verification and Management Processing>
Figure 16 is a diagram illustrating the outline of the individual collateral verification management process S1205. When the collateral management method is "Individual," the auditor device 400 and the collateral verification device 600 verify whether collateral is secured for each user and for each type of token.

First, the auditor device 400 transfers the target token held by the user to the auditor in order to verify that collateral exists in the user's currency account (S41). The target token is the token specified in the first collateral verification request. Each device transfers the token by executing the token management program 1300. Details of the token transfer process by the token management program 1300 will be described later. Furthermore, the token management program 1300, in conjunction with the transfer of the target token, executes the currency management program 1400, thereby transferring the collateral backing the target token from the user's currency account to the auditor's currency account in the currency network N2 (S42). Details of the collateral backing process by the currency management program 1400 will be described later. This allows the collateral verification device 600 used by the auditor to access the collateral backing the target token in the auditor's currency account.

Furthermore, to guarantee the verification process, the auditor device 400 transfers audit tokens equivalent to the current price of the target token from the auditor to the user (S43). In the illustrated example, since the price of the target token is "10," the auditor device 400 transfers audit tokens equivalent to the price of "10" from the auditor to the user.

Audit tokens are tokens whose use is limited to security deposits for collateral verification. That is, audit tokens can only be used as security deposits for the verification of target tokens. Audit tokens are accompanied by specific information indicating that their use is limited to security deposits for the verification of target tokens. When a device receives a request to use an audit token, it will only process the transaction if the use is indeed a security deposit for the verification of the target token, based on the information attached to the token. Therefore, audit tokens cannot be used for payment of goods or services. Transferring audit tokens to users provides users with a sense of security regarding the transfer of target tokens to the auditor. Furthermore, because the use of audit tokens is limited to security deposits for collateral verification, it prevents users from using audit tokens for other purposes during collateral verification.

The collateral verification device 600 verifies the collateral of the target token by executing the collateral verification processing program 1500, referencing the auditor's currency account (the record of the auditor's user ID in the currency account table 900). Details of the collateral verification process by the collateral verification processing program 1500 will be described later. Then, upon receiving the collateral verification results from the collateral verification device 600, the auditor device 400 executes the token management program 1300, returning the target token transferred to the auditor from the auditor to the user, and returning the audit token transferred to the user from the user to the auditor.

Figure 17 is a processing flow diagram illustrating the details of the individual collateral verification management process S1205. First, the collateral verification management program 1200 generates a token transfer request for the target token (S1211). The token transfer request includes the token ID "Token ID included in the first collateral verification request", the token quantity "Token quantity included in the first collateral verification request", and the sender "
The user ID included in the first collateral verification request and the recipient's user ID ("Auditor's User ID") are set.

Next, the collateral verification management program 1200 calls (executes) the token management program 1300 of the operator device 300 to transfer the target token from the user to the auditor (S1212). At this time, the collateral verification management program 1200 sends the token transfer request generated in S1211 to the token management program 1300 of the operator device 300.

Next, the collateral verification management program 1200 calculates the quantity of audit tokens equivalent to the current price of the target token quantity (S1213). Specifically, the collateral verification management program 1200 calculates the quantity of audit tokens by multiplying the target token quantity by the unit price of the target token and then dividing the result by the unit price of the audit tokens.

Next, the collateral verification management program 1200 generates a token transfer request for the audit token (S1214). The token transfer request is set with the token ID "Audit", the token quantity "the quantity of audit tokens calculated in S1213", the sender "the auditor's user ID", and the recipient "the user ID included in the first collateral verification request".

Next, the collateral verification management program 1200 executes the token management program 1300 to transfer the audit token from the auditor to the user (S1215). At this time, the collateral verification management program 1200 sends the token transfer request generated in S1214 to the token management program 1300.

Next, the collateral verification management program 1200 generates a second collateral verification request based on the first collateral verification request (S1216). This second collateral verification request includes the following fields: User ID ("User ID included in the first collateral verification request"), Token ID ("Token ID included in the first collateral verification request"), Token Quantity ("Token Quantity included in the first collateral verification request"), Collateral ID ("Collateral ID of the token type record"), Collateral Ratio ("Collateral Ratio of the token type record"), Collateral Management Method ("Individual"), and Unit Price ("Unit Price of the token type record").

Next, the collateral verification management program 1200 transmits the second collateral verification request generated in S1216 to the collateral verification device 600 (S1217).

Subsequently, the collateral verification management program 1200 receives the collateral verification result, which is the response to the second collateral verification request transmitted in S1217, from the collateral verification device 600 (S1218).

Next, the collateral verification management program 1200 generates a token transfer request for the target token (S1219). This token transfer request includes the token ID ("Token ID included in the first collateral verification request"), the token quantity ("Token quantity included in the first collateral verification request"), the sender ("Auditor's User ID"), and the recipient ("User ID included in the first collateral verification request").

Next, the collateral verification management program 1200 calls (executes) the token management program 1300 of the operator device 300 to transfer the target token from the auditor to the user (S1220). At this time, the collateral verification management program 1200 sends the token transfer request generated in S1219 to the token management program 1300 of the operator device 300.

Next, the collateral verification management program 1200 generates a token transfer request for the audit token (S1221). This token transfer request is set with the token ID "Audit", the token quantity "the quantity of audit tokens calculated in S1213", the sender "the user ID included in the first collateral verification request", and the recipient "the auditor's user ID".

Next, the collateral verification management program 1200 executes the token management program 1300 to transfer the audit token from the user to the auditor (S1222). At this time, the collateral verification management program 1200 sends the token transfer request generated in S1221 to the token management program 1300. Afterward, the collateral verification management program 1200 terminates this individual collateral verification request processing.

In the processing flow described above, the collateral verification management program 1200 calls the token management program 1300 of the operator device 300 in S1212 and S1220 to transfer the target token. However, it is not limited to this method; the target token may also be transferred by executing its own token management program 1300.

<Bulk Collateral Verification Management Process>
Figure 18 is a diagram illustrating the overview of the batch collateral verification management process S1206. When the collateral management method is "All", the auditor device 400 and the collateral verification device 600 refer to the operator's currency account (the record of the operator's user ID in the currency account table 900) to verify whether the necessary price collateral is secured for the total supply of the target tokens.

If the collateral management method is "All", the auditor device 400 searches the token account table 800 using the token ID included in the first collateral verification request and aggregates the total supply of the target tokens (S51). Meanwhile, the collateral verification device 600 refers to the operator's currency account and verifies whether there is collateral at the required price (lower limit price) for the total supply of the target tokens (S52).

Figure 19 is a processing flow diagram illustrating the details of the batch collateral verification management process S1206. First, the collateral verification management program 1200 searches the token account table 800 using the token ID included in the first collateral verification request and retrieves all matching records (S1231).

Next, the collateral verification management program 1200 extracts the token quantity 803 from all acquired records and calculates the total issued amount of the target token ID by summing the extracted token quantities (S1232).

Next, the collateral verification management program 1200 generates a second collateral verification request based on the first collateral verification request (S1233). The second collateral verification request includes the user ID "operator ID of the token type record", the token ID "token ID included in the first collateral verification request", the token quantity "total issued amount aggregated in S1232", the collateral ID "collateral ID of the token type record", the collateral ratio "collateral ratio of the token type record", and the collateral management method "All".
The unit price, "Unit price for token type record," is also set.

Next, the collateral verification management program 1200 transmits the second collateral verification request generated in S1233 to the collateral verification device 600 (S1234).

Subsequently, the collateral verification management program 1200 receives the collateral verification result, which is the response to the second collateral verification request transmitted in S1234, from the collateral verification device 600 (S1235). Afterward, the collateral verification management program 1200 terminates this batch collateral verification request processing.

<Token Management Processing>
Figure 20 is a processing flow diagram illustrating the details of the token management process S1300. The token management process S1300 shown in this figure is a process executed by the token management program 1300 when a token is transferred in steps S1212, S1215, S1220, and S1222 of the collateral verification management process S1200 described above.

First, the token management program 1300 receives a token transfer request from the collateral verification management program 1200 (S1301).

Next, the token management program 1300 extracts the "token ID," "token quantity," "sender," and "destination" from the token transfer request received in S1301 (S1302).

Next, the token management program 1300 searches the token type table 700 using the token ID extracted in S1302 and retrieves the corresponding record (S1303).

Next, the token management program 1300 extracts the operator ID 702, collateral ID 703, and collateral ratio 704 from the record obtained in S1303 (S1304).

Next, the token management program 1300 searches the token account table 800 and retrieves a record where the user ID is "the user ID of the sender of the token transfer request" and the token ID is "the token ID of the token transfer request" (hereinafter referred to as the "sender token account record") (S1305).

Next, the token management program 1300 subtracts the amount of tokens to be transferred from the amount of tokens in the source token account record obtained in S1305 (S1306).

Next, the token management program 1300 searches the token account table 800 and retrieves a record where the user ID is the "user ID to which the token transfer request is sent" and the token ID is the "token ID of the token transfer request" (hereinafter referred to as the "destination token account record") (S1307).

Next, the token management program 1300 adds the quantity of tokens to be transferred to the quantity of tokens in the destination token account record obtained in S1307 (S1308).

Next, the token management program 1300 generates a currency transfer request (S1309) requesting the transfer of the digital currency that serves as collateral for the transferred tokens. This currency transfer request includes a currency ID ("collateral ID"), an amount ("current price equivalent to the token quantity"), a sender ("sender's user ID"), and a recipient ("recipient's user ID").

Next, the token management program 1300 calls (executes) the currency management program 1400 of the issuer device 500 to transfer the digital currency that serves as collateral for the token from the sender to the recipient (S1310). At this time, the token management program 1300 sends the currency transfer request generated in S1309 to the currency management program 1400 of the issuer device 500.

Next, the token management program 1300 sends the token transaction result, which is the result of transferring the tokens, to the sender of the token transfer request (S1311). The token transaction result includes, for example, information indicating whether the token transfer was successful or unsuccessful. Afterward, the token management program 1300 terminates this token management process S1300.

<Currency Management Processing>
Figure 21 is a processing flow diagram illustrating the details of the currency management process S1400. The currency management process S1400 shown in this figure is a process executed by the currency management program 1400 of the issuer device 500 when transferring digital currency in S1310 of the token management process S1300 described above.

First, the currency management program 1400 receives a currency transfer request from the token management program 1300 (S1401).

Next, the currency management program 1400 extracts the "currency ID," "amount," "sender," and "destination" from the currency transfer request received in S1401 (S1402).

Next, the currency management program 1400 searches the currency account table 900 and retrieves a record where the user ID is "the user ID of the currency transfer request sender" and the currency ID is "the currency ID of the currency transfer request" (hereinafter referred to as "the sender currency account record" (S1403)).

Next, the currency management program 1400 subtracts the amount to be transferred from the balance of the source currency account record obtained in S1403 (S1404). The amount to be transferred is the amount extracted from the currency transfer request in S1402.

Next, the currency management program 1400 searches the currency account table 900 and retrieves a record (hereinafter referred to as the "destination currency account record") where the user ID is "the user ID to whom the currency transfer request is sent" and the currency ID is "the currency ID of the currency transfer request" (S1405).

Next, the currency management program 1400 adds the amount to be transferred to the balance of the destination currency account record obtained in S1405 (S1406).

Next, the currency management program 1400 transmits the currency transaction result, which is the result of transferring the digital currency, to the sender of the currency transfer request (S1407). The currency transaction result includes, for example, information indicating whether the transfer of the digital currency was successful or unsuccessful. Afterward, the currency management program 1400 terminates this currency management process S1400.

<Collateral Verification Process>
Figure 22 is a processing flow diagram illustrating the details of the collateral verification process S1500. The collateral verification process S1500 shown in this figure is the process (S112) that the collateral verification program 1500 of the collateral verification device 600 executes in the collateral verification sequence described above, from the time it receives the second collateral verification request in S102 until it transmits the collateral verification result in S103.

First, the collateral verification processing program 1500 receives a second collateral verification request from the collateral verification management program 1200 of the auditor device 400 (S1501).

Next, the collateral verification processing program 1500 extracts the "User ID," "Token ID," "Token Quantity," "Collateral ID," "Collateral Ratio," "Collateral Management Method," and "Unit Price" from the second collateral verification request received in S1501 (S1502).

Next, the collateral verification processing program 1500 calculates the lower limit price of the collateral by multiplying the current price of the token quantity extracted in S1502 by the extracted collateral ratio (S1503). At this time, the collateral verification processing program 1500 calculates the current price of the token quantity by multiplying the token quantity by the unit price.

Next, the collateral verification processing program 1500 determines whether the extracted collateral management method is "Individual" or "All" (S1504).

The collateral verification processing program 1500, when the collateral management method is "Individual," searches the currency account table 900 to retrieve the record of the currency account managing the collateral transferred from the user to the auditor (S1205). The conditions for searching the currency account table 900 at this time are the user ID "Auditor's User ID," the currency ID "Collateral ID extracted in S1502," and the attribute tag "Token ID extracted in S1502."

On the other hand, the collateral verification processing program 1500, when the collateral management method is "All",
The currency account table is searched to retrieve the record of the currency account that manages the fund manager's collateral (S1506). The conditions for searching the currency account table 900 at this time are the user ID "Fund Manager's User ID", the currency ID "Collateral ID extracted in S1502", and the attribute tag "Token ID extracted in S1502".

Subsequently, the collateral verification processing program 1500 extracts the "balance" from the record obtained in S1505 or S1506 (S1507).

Next, the collateral verification processing program 1500 determines whether the balance extracted in S1507 is greater than the lower limit price of the collateral calculated in S1503 (S1508).

The collateral verification processing program 1500 sets the collateral verification result to "success" (S1509) if the balance is greater than the lower limit price of the collateral (S1508: Yes).

On the other hand, if the collateral verification processing program 1500 finds that the balance is below the minimum collateral price (S1508: No), it sets the collateral verification result to "failure" (S1510).

Subsequently, the collateral verification processing program 1500 transmits the collateral verification result to the collateral verification management program 1200 of the auditor device 400, the source of the second collateral verification request (S1511). Afterward, the collateral verification processing program 1500 terminates this collateral verification process S1500.

In the processing flow described above, the collateral verification program 1500 sets the collateral verification result to "success" when the balance is greater than the lower limit price of the collateral. However, the criteria for verifying the value of the token are not limited to this. For example, the collateral verification program 1500 may verify the value of the token using other criteria, such as setting the collateral verification result to "success" when the balance of the currency account is equal to or greater than the current price of the token.

Furthermore, while the collateral verification processing program 1500 sets the collateral verification result to "success" or "failure" in the processing flow described above, it is not limited to this. Other information related to verification, such as the current price of the target token or the balance of the currency account, may also be included in the collateral verification result.

Furthermore, in the processing flow described above, the collateral verification processing program 1500 calculates the current price of the target token by multiplying the token quantity by the unit price. However, it is not limited to this method; the current price of the target token may also be obtained from a website or other source that provides the current price of the target token.

As described above, the management system 1000 of this embodiment (auditor device 400 and collateral verification device 600) receives a request to verify the value of a token from a device (user device 200 or operator device 300) that stores token information, obtains information on the collateral assets (backing collateral) that back the token (target token) related to the verification request from the issuer device 500 that manages the collateral assets backing the token, verifies the value of the token related to the verification request based on the received verification request and the acquired collateral asset information, and transmits the verification result to the device (user device 200 or operator device 300).

In other words, the management system 1000 of this embodiment can notify the user device 200 or the operator device 300 of the results of verifying the value of the token based on the token verification request received from the user device 200 or the operator device 300 and the collateral asset information obtained from the issuer device 500. This allows the user device 200 or the operator device 300 to verify the value of the token via the auditor device 400 and the collateral verification device 600, even if the issuer device 500 cannot directly access the token's collateral. Therefore, users or operators can easily confirm the value of their tokens by sending a token verification request from the user device 200 or the operator device 300 to the auditor device 400. Because the token's value can be verified, users can use tokens issued by organizations with low social credibility with confidence. This contributes to financial inclusion, which is the purpose of introducing digital currency.

Furthermore, the management system 1000 of this embodiment determines that verification is successful if the price of the acquired collateral asset is higher than the lower limit price based on the current price of the token related to the verification request.

This configuration ensures successful verification if the underlying collateral for the target token exceeds a lower price limit based on the target token's current price. This allows for flexible adaptation to price fluctuations of the target token. Therefore, users can confirm the existence of collateral corresponding to the target token's current price.

Furthermore, the management system 1000 of this embodiment calculates a lower limit price based on the collateral ratio of the token related to the verification request, which is obtained by referring to the token type table 700 that stores the collateral ratio for each token type, and the current price of the token related to the verification request.

This configuration ensures successful verification if the underlying collateral for the target token exceeds the minimum price based on the target token's collateral ratio. This allows for flexible adjustment of the proportion of collateral assets required, depending on the token's characteristics.

Furthermore, the management system 1000 of this embodiment receives a verification request accompanied by information about the token owner, and verifies the value of the token related to the verification request based on the information about the collateral assets of the token owner related to the verification request, obtained by referring to the currency account table 900 which stores information about the collateral assets for each token owner.

With this configuration, the "Individual" collateral management method, which manages collateral assets for each token owner, verifies the value of the target token by referencing the collateral assets in the token owner's currency account. This allows for accurate verification of the target token's value, even when collateral assets are managed for each token owner.

Furthermore, the management system 1000 of this embodiment transfers the token related to the verification request from the owner to the auditor, thereby transferring the collateral assets backing the token related to the verification request from the owner to the auditor, and verifies the value of the token related to the verification request by referring to the auditor's collateral asset information.

This configuration transfers the collateral assets of the target token to the auditor, allowing the token to be verified by referencing the auditor's currency account. Therefore, since it is not necessary to refer to the currency account of the token's owner (user or operator) during verification, owner privacy is preserved and security is enhanced.

Furthermore, in this embodiment, when the management system 1000 transfers the token related to the verification request from the owner to the auditor, it also transfers the audit token corresponding to the token related to the verification request from the auditor to the owner.

This configuration ensures that when the target token is transferred, an equivalent audit token is also transferred to the owner (user or operator). This provides owners with a sense of security when transferring the target token to the auditor. Therefore, it can alleviate owners' psychological resistance to transferring the target token.

Furthermore, audit tokens are only available when their purpose is to provide security for the verification of tokens related to verification requests.

This prevents the owner (user or operator) from using the audit token for other purposes while the target token is being verified.

Furthermore, the management system 1000 of this embodiment receives a verification request accompanied by information on the token type, and by referring to a token type table that stores operator information for each token type, it identifies the operator corresponding to the token type related to the verification request. It then verifies the value of the token related to the verification request by referring to the collateral asset information of the identified operator.

This configuration allows for a collateral management method called "All" that manages collateral assets according to token type.
This method verifies the value of the target token by referencing the collateral assets in the token operator's currency account. This allows for accurate verification of the target token's value, even when collateral assets are managed separately for each type of token.

Furthermore, the management system 1000 of this embodiment verifies the value of the tokens related to the verification request based on the price of the total issued tokens related to the verification request and the price of the collateral assets of the identified operator.

This configuration verifies that collateral equivalent to the current price of the total issued token exists in the operator's currency account. This ensures that even when the token is purchased by multiple users and there are multiple owners, each user can confirm that collateral corresponding to their total issued token exists.

Furthermore, the management system 1000 of this embodiment includes an auditor device 400, which is communicatively connected to a device storing token information via a token network N1 and comprises a receiving unit 1201 and a transmitting unit 1203; and a collateral verification device 600, which is communicatively connected to an issuer device 500 via a currency network N2 and comprises a verification unit 1501.

In this configuration, even if the token network N1 and the currency network N2 are separated, and the user device 200 or the operator device 300 cannot directly access the collateral backing the tokens, the user device 200 or the operator device 300 can still verify the value of the tokens via the auditor device 400 and the collateral verification device 600.

The present invention is not limited to the embodiments described above, and without departing from its spirit,
It can be implemented using any components. The embodiments and modifications described above are merely examples, and the present invention is not limited to these, as long as the features of the invention are not impaired. Furthermore, although various embodiments and modifications have been described above, the present invention is not limited to these. Other embodiments that can be conceivable within the scope of the technical idea of the present invention are also included within the scope of the present invention.

For example, some of the hardware components of each device in this embodiment may be provided in other devices.

Furthermore, each program of the auditor device 400 or the collateral verification device 600 may be provided on other devices, a program may consist of multiple programs, or multiple programs may be integrated into a single program.

Furthermore, although this embodiment describes an example where the auditor device 400 and the collateral verification device 600 are separate devices, a single device may possess the functions of both the auditor device 400 and the collateral verification device 600.

Furthermore, while this embodiment describes the case where the collateral backing the target token is digital currency, the collateral backing the target token is not limited to digital currency; it may also be other assets such as physical currency, bank deposits, or securities.

Furthermore, while this embodiment describes the case where the token network N1 and currency network N2 are distributed ledger networks, the embodiment is not limited to this; they may be networks centrally managed by a predetermined server device or cloud. For example, if the token network N1 is centrally managed by the operator device 300, only the operator device 300 stores the token type table 700 and the token account table 800. In this case, the auditor device 400 accesses the token type table 700 or the token account table 800 by querying the operator device 300. Similarly, if the currency network N2 is centrally managed by the issuer device 500, only the issuer device 500 stores the currency account table 900. In this case, the collateral verification device 600 accesses the currency account table 900 by querying the issuer device 500.

Furthermore, while this embodiment describes an example where the user verifies the token's value, it is not limited to this. The operator device 300 may also transmit a first collateral verification request, allowing the operator to verify the token's value.

100 Currency Management System, 200 User Devices, 300 Operator Devices, 400 Auditor Devices, 500 Issuer Devices, 600 Collateral Verification Devices, 700 Token Type Table, 800 Token Account Table, 900 Currency Account Table, 1000 Management System, 1100 Collateral Verification Request Program, 1200 Collateral Verification Management Program, 1200 Token Management Program, 1400 Currency Management Program, 1500 Collateral Verification Processing Program, N1 Token Network, N2 Currency Network

Claims (11)

It has a processor and memory,
A receiving unit that receives a request to verify the value of a token from a device that stores information about the token,
A verification unit obtains information on the collateral assets backing the token related to the verification request from an issuer device that manages the collateral assets backing the token, and verifies the value of the token related to the verification request based on the received verification request and the acquired collateral asset information.
A transmitting unit that transmits the results of the verification to the device,
Equipped with,
The verification unit determines that the verification was successful if the price of the acquired collateral asset is higher than the lower limit price based on the current price of the token related to the verification request.
Management system. The verification unit calculates the lower limit price based on the collateral ratio, which is the percentage of collateral to be secured relative to the token price, obtained by referring to a token type table stored for each token type, and the current price of the token related to the verification request.
The management system according to claim 1. The receiving unit receives a verification request accompanied by information of the token owner,
The verification unit verifies the value of the token related to the verification request based on the information of the collateral assets of the token owner related to the verification request, which is obtained by referring to a currency account table that stores information of collateral assets for each token owner.
The management system according to claim 1. The system includes a management unit that transfers the token related to the verification request from the owner to the auditor, thereby transferring the collateral assets contained in the token related to the verification request from the owner to the auditor.
The verification unit verifies the value of the token related to the verification request by referring to the collateral asset information of the auditor instead of the collateral asset information of the owner of the token related to the verification request.
The management system according to claim 3. When the management unit transfers the token related to the verification request from the owner to the auditor, it also transfers the audit token corresponding to the token related to the verification request from the auditor to the owner.
The management system according to claim 4. The aforementioned audit token is only available if its purpose is to serve as a security deposit for the verification of the token related to the verification request.
The management system according to claim 5. The receiving unit receives a verification request accompanied by information about the type of token,
The verification unit identifies the operator corresponding to the token type related to the verification request by referring to a token type table that stores information on the operators issuing the tokens for each token type, and verifies the value of the token related to the verification request by referring to the collateral asset information of the identified operator.
The management system according to claim 1. The verification unit verifies the value of the tokens related to the verification request based on the price of the total supply of the tokens related to the verification request and the price of the collateral assets of the identified operator.
The management system according to claim 7. An auditor device comprising a receiving unit and a transmitting unit, which is connected to a device storing token information via a first communication network,
The issuing device and the collateral verification device, which is connected to the issuing device via a second communication network and includes the verification unit,
Equipped with,
The management system according to claim 1 , wherein the auditor device and the collateral verification device are communicated to each other via a third communication network . Information processing device,
A receiving process that receives a request to verify the value of a token from a device that stores information about the token,
A verification process is performed to obtain information on the collateral assets backing the token related to the verification request from the issuer device that manages the collateral assets backing the token, and to verify the value of the token related to the verification request based on the received verification request and the acquired collateral asset information.
A transmission process that transmits the results of the verification to the device,
The process of determining that verification has been successful is performed if the price of the acquired collateral asset is higher than the lower limit price based on the current price of the token related to the verification request.
Management method. In an information processing device,
A receiving process that receives a request to verify the value of a token from a device that stores information about the token,
A verification process is performed to obtain information on the collateral assets backing the token related to the verification request from the issuer device that manages the collateral assets backing the token, and to verify the value of the token related to the verification request based on the received verification request and the acquired collateral asset information.
A transmission process that transmits the results of the verification to the device,
The system executes a determination process that determines that verification is successful if the price of the acquired collateral asset is higher than the lower limit price based on the current price of the token related to the verification request.
Management program.