JP7819136B2 - Information processing system, information processing method, and program - Google Patents

Description

The present invention relates to an information processing system, an information processing method, and a program.

A system for issuing and transferring tokens based on financial products on a blockchain has been disclosed (for example, Patent Document 1).

Japanese Patent Application Laid-Open No. 2021-12460

The system described in Patent Document 1 uses blockchain to enable trading of tokens based on financial products. The system provides a platform on which many financial products can be handled as security tokens. In this case, from the perspective of legal stability of transactions, it is necessary to ensure that the assignee is able to assert third-party claims when the receivable is assigned to him/her. Furthermore, from the perspectives of improving transaction efficiency, reducing transaction costs, shortening settlement periods, and mitigating operational risk, there is a need to eliminate offline work and complete the procedure for ensuring that the assignee is able to assert third-party claims solely through electronic processing in an information processing system.

However, the system described in Patent Document 1 does not include a mechanism for ensuring that the assignee is able to assert claims against third parties when a claim is assigned. Therefore, there is a need for a new mechanism for implementing an information processing system that ensures that the assignee is able to assert claims against third parties when a claim is assigned.

The present invention therefore aims to provide a system that allows the assignee of a creditor's claim to have third-party protection.

An information processing system according to one aspect of the present invention includes: a display processing unit that causes a display unit of a debtor to display an acceptance request screen that accepts operational input from the debtor regarding acceptance of an agreement for the assignment of a debt from the creditor to an assignee; an acceptance information acquisition unit that acquires acceptance information, which is information indicating acceptance of the agreement through operational input by the debtor on the acceptance request screen; and a storage execution unit that, when the acceptance information acquisition unit acquires the acceptance information, stores agreement information, which is information regarding the content of the agreement, in a database; and, when the agreement information is stored in the database, the display processing unit causes a transfer confirmation screen, on the display unit, that allows the agreement information to be confirmed based on operational input from any of the creditor, the assignee, or the debtor.

An information processing method according to one aspect of the present invention includes a computer that displays, on a display unit of a debtor, an acceptance request screen that accepts operational input from the debtor regarding acceptance of an agreement under which a debtor transfers a debt from the creditor to an assignee; acquires acceptance information, which is information indicating acceptance of the agreement through operational input by the debtor on the acceptance request screen; when the acceptance information is acquired, stores agreement information, which is information regarding the content of the agreement, in a database; and when the agreement information is stored in the database, displays, on a display unit, an assignment confirmation screen that allows confirmation of the agreement information based on operational input by any of the creditor, the assignee, and the debtor.

A program according to one aspect of the present invention causes a computer to: display, on a display unit of a debtor, an acceptance request screen that accepts operational input from the debtor regarding acceptance of an agreement for the assignment of a debt from the creditor to the assignee of the debt; acquire acceptance information, which is information indicating acceptance of the agreement through operational input by the debtor on the acceptance request screen; when the acceptance information is acquired, store agreement information, which is information regarding the content of the agreement, in a database; and when the agreement information is stored in the database, display, on a display unit, an assignment confirmation screen that allows confirmation of the agreement information based on operational input by any of the creditor, the assignee, or the debtor.

The present invention provides a system that allows assignees of creditors' claims to have third-party effectiveness.

FIG. 1 is a diagram illustrating an example of the configuration of a debt management system. FIG. 10 is a diagram showing the configuration of a bond information database D111. FIG. 10 is a diagram showing an example of an approval request screen T1. FIG. 10 is a diagram showing an example of a first transfer confirmation screen T2. FIG. 10 is a diagram showing an example of a second transfer confirmation screen T3. FIG. 10 is a diagram showing an example of a notification screen T4. 10 is a flowchart showing an example of a processing procedure of a claim management system. FIG. 10 is a diagram illustrating an example of the configuration of a claim management system according to a first modified example. 10 is a flowchart showing an example of a processing procedure of a claim management system according to a first modified example. 10 is a flowchart showing a processing procedure of a debt management system according to a second modified example. FIG. 10 is a diagram showing an example of a notification content confirmation screen T1a. FIG. 2 illustrates an example of a hardware configuration of a computer.

A preferred embodiment of the present invention (hereinafter referred to as "this embodiment") will be described with reference to the accompanying drawings. In each drawing, parts with the same reference numerals have the same or similar configurations. In this embodiment, "unit," "means," "device," and "system" do not simply mean physical means, but also include cases where the functions of the "unit," "means," "device," or "system" are realized by software. Furthermore, the functions of one "unit," "means," "device," or "system" may be realized by two or more physical means or devices, or the functions of two or more "units," "means," "device," or "system" may be realized by one physical means or device.

===Outline of Debt Management System 10===
<<Configuration Overview>>
An overview of a claim management system 10 according to this embodiment will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the configuration of the claim management system 10.

The claim management system 10 is a system that can prove the requirements for perfection against third parties regarding the transfer of a claim from a creditor to an assignee. The claim management system 10 notifies the debtor and obtains the debtor's consent regarding the transfer of a claim from the creditor to the assignee on the system. In this way, the claim management system 10 provides the assignee with the requirements for perfection against third parties. The claim management system 10 stores security tokens representing claims in the blockchain BN, and also manages information related to claims in a database.

Examples of claims include collective investment scheme interests (interests in anonymous partnerships) and trust beneficiary rights.

Security tokens are tokenized versions of, for example, trust beneficiary rights or collective investment scheme interests, and refer to "electronic record transfer rights" as defined in the Financial Instruments and Exchange Act (Article 2, Paragraph 2, each item of the Financial Instruments and Exchange Act).

Blockchain BN is a system used for trading security tokens. Blockchain BN is composed of multiple nodes (computers) and can manage ledger data in a distributed manner. The distributed ledger is managed in a way that makes it difficult to tamper with, using the so-called blockchain mechanism. Note that a detailed explanation of the distributed ledger management mechanism using blockchain will be omitted here, as it is a standard one.

The receivable management system 10 includes, for example, a receivable management device 100, a creditor terminal 200, a transferee terminal 300, a debtor terminal 400, and a financial institution terminal 500. The devices that make up the receivable management system 10 are connected to each other so that they can communicate with each other via a communications network N. The communications network N is a wired network or a wireless network.

The claim management device 100 is a device that manages information related to claims (hereinafter referred to as "claim information"). Claims are, for example, the shares held by investors in an anonymous partnership. The claim management device 100 manages claim information using a database and blockchain. The claim management device 100 also has the function of certifying the transferee's right to assert claims against third parties when a claim is transferred.

The creditor terminal 200 is a terminal device that accepts operational input from creditors. Creditors are, for example, investors in anonymous partnerships or beneficiaries of trust beneficiary rights.

The assignee terminal 300 is a terminal device that accepts operational inputs from the assignee of the claim. The assignee may be, for example, a person who receives an assignment of the shares of an anonymous partnership investor or a person who receives an assignment of a trust beneficiary right.

The debtor terminal 400 is a terminal device that accepts operational inputs from the debtor of the claim. The debtor may be, for example, a limited liability company that operates an anonymous partnership or a trustor of a trust beneficiary interest.

The creditor terminal 200, the transferee terminal 300, and the debtor terminal 400 each transmit various information related to operational inputs to the financial institution terminal 500 and the debt management device 100.

The financial institution terminal 500 is an operation terminal of the financial institution that manages the claims. Examples of financial institutions include institutions that issue security tokens representing claims, investment management companies (including asset management companies), Type 1 and Type 2 financial instruments business operators (such as securities companies), and business companies that raise funds. The financial institution terminal 500 transmits, for example, various information related to operation inputs by the operator, and various information obtained from the creditor terminal 200, the assignee terminal 300, and the debtor terminal 400, to the claim management device 100.

The receivable management device 100 may be, for example, a cloud computer, a server computer, a personal computer (e.g., desktop, laptop, tablet, etc.), a media computer platform (e.g., cable or satellite set-top box, digital video recorder), a handheld computing device (e.g., PDA, email client, etc.), or other types of computers or communications platforms. Note that at least a portion of the processing in the receivable management device 100 may be implemented by one or more computers (for example, but not limited to, cloud computing consisting of one or more computers).

The creditor terminal 200, the assignee terminal 300, the debtor terminal 400, and the financial institution terminal 500 may be, for example, a smartphone, a mobile phone (feature phone), a personal computer (e.g., a desktop, laptop, tablet, etc.), a media computer platform (e.g., a cable or satellite set-top box, a digital video recorder), a handheld computer device (e.g., a PDA (Personal Digital Assistant), an email client, etc.), a wearable device (e.g., a glasses-type device, a watch-type device, etc.), or another type of computer or communication platform.

<Processing Overview>>
Referring to FIG. 1, an overview of the processing of the claim management system 10 will be described.

In step S10, the financial institution terminal 500 acquires, from at least one of the creditor terminal 200 and the assignee terminal 300, information regarding an agreement between the creditor and the assignee regarding the transfer of a claim (e.g., an anonymous partnership interest) from the creditor to the assignee (hereinafter referred to as "agreement information"). Note that the financial institution terminal 500 may also acquire agreement information transmitted from each of the creditor terminal 200 and the assignee terminal 300.

The financial institution terminal 500 may obtain the agreement information by accepting operational input from the creditor and the assignee on the input screens provided on the creditor terminal 200 and the assignee terminal 300. The financial institution terminal 500 may also obtain the agreement information by accepting operational input from a financial institution employee based on a request form containing details of the agreement sent by at least one of the creditor and the assignee.

In step S11, upon receiving the agreement information, the financial institution terminal 500 transmits a request (hereinafter referred to as the "transfer request") to the claim management device 100 to transfer the claim from the creditor to the transferee. The transfer request includes, for example, the agreement information.

In step S12, when the receivables management device 100 accepts the transfer request, it sends information to the debtor terminal 400 to display on the display unit a screen for the debtor to consent to the transfer of the receivables (hereinafter referred to as the "consent request screen T1").

In step S13, the debtor terminal 400 displays the consent request screen T1 on the display unit. By accepting the debtor's input on the consent request screen T1, the debtor terminal 400 transmits information indicating that the debtor has consented to the transfer of the receivables (hereinafter referred to as "consent information") to the receivables management device 100.

In step S14, the claim management device 100 stores the consent information (including agreement information) in the claim information database D111. This allows the claim management system 10 to ensure that the assignee meets the requirements for perfection against third parties without the parties to the claim assignment having to go to a notary public office. Specifically, the claim management system 10 can ensure that the assignee meets the requirements for perfection against third parties in the case of the transfer of shares (claims) in an anonymous partnership, for example.

In this way, with the receivables management system 10, while it is necessary for the assignee to, for example, notify the debtor (e.g., the operator of an anonymous partnership) in a document with a fixed date, or obtain the debtor's (e.g., the operator of an anonymous partnership) consent in a document with a fixed date in order to satisfy the requirements for third-party perfection, it is possible for the assignee to satisfy these requirements.

In step S15, the receivables management device 100 transmits information to each terminal based on a request from each terminal to display a screen on the display unit on which the details of the agreement can be confirmed (hereinafter referred to as the "transfer confirmation screen T2, T3").

In step S16, the receivables management device 100 executes a smart contract (hereinafter referred to as the "transfer contract") for recording information regarding the transfer of the receivables in the blockchain BN. As a result, the receivables management device 100 stores at least a portion of the information contained in the consent information (including the agreement information) (hereinafter referred to as the "agreement-related information") in the blockchain BN.

The agreement-related information includes, for example, the date and time of the debtor's consent and information necessary for third-party assertion. The information necessary for third-party assertion may include, for example, the identification information of the security token, the address of the security token representing the claim, the name of the transferor, the name of the transferee, and the wallet addresses of the transferor and transferee.

A smart contract is a program or computer protocol that executes according to specified rules based on transactions and external information, for example, on a blockchain (BN).

As a result, the receivables management system 10 can properly and quickly transfer the receivables displayed on the security token to the transferee, while also enabling the transferee to meet third-party assertion requirements. As a result, compared to offline operations, the receivables management system 10 can improve the efficiency of receivables transactions, reduce transaction costs, shorten transaction times, and avoid operational risks.

Note that steps S14 and S16 above may be executed simultaneously. However, in the claim management system 10, when step 14 is completed, the creditor terminal 200, transferee terminal 300, and debtor terminal 400 can display an assignment confirmation screen on the display unit, as in step S15. In other words, the creditor, transferee, and debtor can confirm the assignment details by referring to the claim information database D111 before the agreement-related information is stored in the blockchain BN. This allows the claim management system 10 to prevent tampering with the assignment details and quickly provide information that allows the relevant parties to confirm the assignment details.

In addition, although the above description has been given of the financial institution terminal 500 transmitting and receiving agreement information between the creditor terminal 200 and the assignee terminal 300 and the receivables management device 100, this is not limited to this. For example, the financial institution terminal 500 may be included in the receivables management device 100. In other words, the receivables management device 100 may provide an acceptance screen to the debtor terminal 400 by receiving agreement information from the creditor terminal 200 and the assignee terminal 300 without going through a financial institution.

===Configuration of Debt Management System 10===
The configuration of the claim management system 10 will be described in detail with reference to FIG.

<<Debt management device 100>>
As shown in FIG. 1, the claim management device 100 includes, for example, a memory unit 110, a transfer request acquisition unit 120, an approval information acquisition unit 130, a display processing unit 140, a memory execution unit 150, and a matching unit 160.

The storage unit 110 includes, for example, a claim information database D111. The configuration of the claim information database D111 will be described with reference to Figure 2. Figure 2 is a diagram showing the configuration of the claim information database D111.

As shown in Figure 2, the credit information database D111 includes, for example, the following fields: [Name Change ID], [Creditor], [Wallet Address], [ST Name], [Number of Shares Held], [Name Change Reason], [Transfer Source], [Transfer Source Wallet Address], [Notification Date and Time], [Acceptance Date and Time], and [Acceptance Information].

[Name Change ID] stores, for example, an identification code that can uniquely identify each claim. [Creditor] stores, for example, information indicating the creditor's name. [Wallet Address] stores, for example, the creditor's wallet address. [ST Name] stores, for example, the name of the security token. [Number of Shares Held] stores, for example, the number of security tokens representing the claim held by the creditor. [Name Change Reason] stores, for example, information indicating the reason for the transfer of the claim (e.g., "assignment" or "forced transfer"). [Transfer Source] stores, for example, information indicating the name of the transferor of the claim. [Transfer Source Wallet Address] stores, for example, the wallet address of the transferor user. [Notification Date and Time] stores, for example, the date and time when the creditor or transferee notified the debtor at the time of the transfer of the claim. [Acceptance Date and Time] stores, for example, the date and time when the debtor accepted the transfer of the claim. In other words, the [Acceptance Date and Time] field stores information that enables the transferee to fulfill the requirements for third-party perfection. [Consent Information] stores information about the debtor's consent to the transfer of a claim from the creditor to the debtor. The consent information may also store information indicating a letter of consent issued by the debtor, for example.

The transfer request acquisition unit 120 acquires the transfer request, for example, from the financial institution terminal 500. Note that the transfer request acquisition unit 120 may also acquire the transfer request from at least one of the creditor terminal 200 and the transferee terminal 300.

The consent information acquisition unit 130 acquires consent information, for example, from the debtor terminal 400.

The display processing unit 140 generates, for example, various screens to be displayed on the display unit. The display processing unit 140 transmits information for displaying various screens on the display units of the creditor terminal 200, the transferee terminal 300, the debtor terminal 400, and the financial institution terminal 500 to each terminal. Specifically, the display processing unit 140 generates, for example, an approval request screen T1, a first transfer confirmation screen T2, a second transfer confirmation screen T3, and a notification screen T4. Note that, below, the first transfer confirmation screen T2 and the second transfer confirmation screen T3 may be collectively referred to as the transfer confirmation screens.

The various screens generated by the display processing unit 140 will be described with reference to Figures 3 to 6. Figure 3 is a diagram showing an example of an acceptance request screen T1. Figure 4 is a diagram showing an example of a first transfer confirmation screen T2. Figure 5 is a diagram showing an example of a second transfer confirmation screen T3. Figure 6 is a diagram showing an example of a notification screen T4.

As shown in Figure 3, the consent request screen T1 is a screen for the debtor to consent to the transfer of the claim from the creditor to the transferee. The consent request screen T1 is displayed, for example, based on the claim information database D111. The consent request screen T1 includes, for example, fields for the name change application registrant T10, name change originator information T11, name change recipient information T12, and claim assignment notice information T13, as well as a name change consent button T14.

Name change application registrant T10 is an area where information about financial institutions is displayed. Specifically, name change application registrant T10 includes information indicating the name of the financial instruments business operator representing the financial institution.

The name change origin information T11 is an area that displays information about the creditor to whom the claim is being transferred. Specifically, the name change origin information T11 includes the investor name, investor wallet address, ST name, ST contract address, product name, number of shares held before the name change, number of shares to be transferred, reason for the name change, and a flag indicating whether or not the transfer is forced. This allows the debtor to easily check information about the creditor to whom the claim is being transferred.

The transferee information T12 is an area that displays information about the transferee to whom the claim will be transferred. Specifically, the transferee information T12 includes the investor's name and investor wallet address.

Receivables assignment notice information T13 is an area that displays information about at least one of the notice and consent regarding the assignment of the receivable. Figure 3 shows, as an example, the items displayed in a form in which consent provides the assignee with the requirement to assert rights against third parties (hereinafter referred to as the "consent format"). Specifically, receivables assignment notice information T13 includes information about the receivables assignment consent form. The receivables assignment consent form item may display a button for downloading the consent form, etc. This allows the debtor to quickly and easily confirm the details of the assignment of the receivable from the creditor to the assignee.

The name change consent button T14 is an object that allows the debtor to consent to the transfer of the receivables. When the receivables management device 100 receives input from the debtor on the name change consent button T14, it stores consent information indicating that the debtor has consented in the memory unit 110. This enables the receivables management device 100 to prove that the debtor has consented to the transfer of the receivables.

The first transfer confirmation screen T2 is a screen displayed on the display unit of the debtor terminal 400, and displays a list of transfer records that the debtor has been notified of or has accepted. The first transfer confirmation screen T2 is displayed, for example, based on the claim information database D111. As shown in FIG. 4, the first transfer confirmation screen T2 includes, for example, fields for ST name T20 and history information T21.

ST Name T20 is the area where the name of the security token is displayed.

The history information T21 is an area that displays a list of events in which a claim was assigned. Specifically, the history information T21 includes items for confirming the details of the event, issuer/transferor, issuer/transferee, number of units, rights accrual date, processing date and time, and claim assignment notice. The processing date and time field displays the date and time when the debtor consented to the assignment. The item for confirming the details of the claim assignment notice, etc. includes a confirmation button T21a. Based on the debtor's input using the confirmation button T21a, a claim assignment consent confirmation screen T22 is displayed on the display unit.

The claim assignment consent confirmation screen T22 displays the minimum information necessary for the debtor to understand the assigned claim. Specifically, the claim assignment consent confirmation screen T22 includes the ST contract address, transfer source wallet address, transfer destination wallet address, number of transfers, claim assignment consent date and time, and claim assignment consent form. This allows the debtor to easily confirm the content of the accepted claim assignment with simple operations.

The second transfer confirmation screen T3 is a screen displayed on the display unit of the creditor terminal 200 and the transferee terminal 300, and displays a list of transfer records for which the creditor and transferee have received approval from the debtor. The second transfer confirmation screen T3 is displayed, for example, based on the credit information database D111. As shown in FIG. 5, the second transfer confirmation screen T3 includes, for example, fields for investor information T30 and holding information T31.

Investor information T30 is an area where the name of the creditor or assignee is displayed.

The holding information T31 is an area that displays a list of information related to security tokens that represent claims held by the creditor or assignee. Specifically, the holding information T31 includes items for confirming the contents of the product name, number of shares held, investment amount, rights accrual date, investment period, expected yield, pre-contract document, contract, and claim assignment notice. The item for confirming the contents of the claim assignment notice, etc. includes a confirmation button T31a. Based on the debtor's input to the confirmation button T31a, a claim assignment consent confirmation screen T32 is displayed on the display unit.

The claim assignment consent confirmation screen T32 is similar to the claim assignment consent confirmation screen T22, so its explanation will be omitted. This allows the creditor and assignee to easily confirm the contents of the claim assignment accepted by the debtor with simple operations.

The notification screen T4 is a screen for notifying the debtor that an event has occurred in which the creditor transfers the claim to the transferee. The notification screen T4 is displayed, for example, based on the claim information database D111. The notification screen T4 includes, for example, the items Notification T40 and ST List T41.

The notification screen T40 is an area that displays a list of events that have occurred related to the debt. For example, the notification screen T40 may include text T40a indicating a notification about a debt assignment event, with a link set to transition to a screen that displays details of the debt assignment event. Specifically, as shown in FIG. 6, text T40a ("Click here" in FIG. 6) for transitioning to the consent request screen T1 may be displayed. When the debtor's input to text T40a is accepted, the consent request screen T1 is displayed on the display unit. This allows the debt management system 10 to quickly notify the debtor that a debt assignment event has occurred, and further allows the debtor to easily display a screen for consenting to the debt assignment, thereby quickly completing the debt assignment within the system.

The storage execution unit 150 stores various information in the claim information database D111 and the blockchain BN. Specifically, the storage execution unit 150 stores agreement information in the claim information database D111. The storage execution unit 150 also executes a contract for the transfer of a claim (hereinafter referred to as the "transfer contract") and stores agreement-related information in the blockchain BN.

The matching unit 160 performs a matching process to check whether specified information included in the agreement information in the credit information database D111 matches specified information included in the agreement-related information of the blockchain BN. Specifically, the matching unit 160 may, for example, match the wallet address of the assignee (current creditor) included in the agreement information with the wallet address of the assignee included in the agreement-related information. Note that the matching unit 160 is only required to be able to perform a matching process to match at least some of the information included in the agreement information with at least some of the information included in the agreement-related information, and there are no particular limitations on the information items to be matched.

The matching unit 160 transmits the results of the matching (hereinafter referred to as the "matching results") to the assignee terminal 300, the debtor terminal 400, and the financial institution terminal 500. At this time, if the agreement information and the agreement-related information do not match, the matching unit 160 may transmit warning information indicating that data tampering has occurred to at least one of the creditor terminal 200, the assignee terminal 300, the debtor terminal 400, and the financial institution terminal 500. This allows the receivable management system 10 to periodically compare the information recorded in the database area with the information recorded in the blockchain area, thereby enabling early detection of data tampering. Furthermore, if the receivable management system 10 detects data tampering, it promptly notifies the relevant parties, thereby preventing the damage from spreading.

<<Creditor Terminal 200>>
Returning to Figure 1, the functional configuration of the creditor terminal 200 will be described. As shown in Figure 1, the creditor terminal 200 includes, for example, a transmission/reception unit 210 and a display unit 220. The transmission/reception unit 210 transmits and receives various information between, for example, the claim management device 100 and the financial institution terminal 500. The display unit 220 displays various screens based on information for displaying various screens transmitted from, for example, the claim management device 100.

<<Transferee Terminal 300>>
Next, the functional configuration of the transferee terminal 300 will be described. As shown in Fig. 1, the transferee terminal 300 includes, for example, a transmission/reception unit 310 and a display unit 320. The transmission/reception unit 310 transmits and receives various information between, for example, the claim management device 100 and the financial institution terminal 500. The display unit 320 displays various screens based on information for displaying various screens transmitted from, for example, the claim management device 100.

<<Obligor Terminal 400>>
Next, the functional configuration of the debtor terminal 400 will be described. As shown in Fig. 1, the debtor terminal 400 includes, for example, a transmission/reception unit 410 and a display unit 420. The transmission/reception unit 410 transmits and receives various information between, for example, the claim management device 100 and the financial institution terminal 500. The display unit 420 displays various screens based on information for displaying various screens transmitted from, for example, the claim management device 100.

<<Financial institution terminal 500>>
Next, the functional configuration of the financial institution terminal 500 will be described. As shown in FIG. 1 , the financial institution terminal 500 includes, for example, a transmission/reception unit 510 and a memory unit 520. The transmission/reception unit 510 transmits and receives various information between, for example, the claim management device 100, the creditor terminal 200, and the assignee terminal 300. The memory unit 520 stores, for example, a database similar to the claim information database D111 of the claim management device 100. Note that the financial institution terminal 500 may have at least some of the functional units of the claim management device 100. Furthermore, the financial institution terminal 500 may be a device included in the claim management device 100.

===Processing Procedure of Debt Management System 10===
The processing procedure of the claim management system 10 will be described with reference to Fig. 7. Fig. 7 is a flowchart showing an example of the processing procedure of the claim management system 10.

In step S100, at least one of the creditor terminal 200 and the transferee terminal 300 sends a transfer request to the financial institution terminal 500.

In step S101, the financial institution terminal 500 accepts operational input from the person in charge and sends a transfer request including agreement information to the receivables management device 100.

In step S102, the receivables management device 100 stores the agreement information in the receivables information database D111. The receivables management device 100 sends, for example, information to the debtor terminal 400 for displaying a notification screen T4 (simply referred to as "notification screen" in Figure 7) indicating that an event has occurred regarding the transfer of receivables from the creditor to the transferee.

In step S103, when the debtor terminal 400 receives input from the debtor into the text T40a on the notification screen T4, it sends a display request to the receivables management device 100 to display the consent request screen T1.

In step S104, the receivables management device 100 references the receivables information database D111 and sends information for displaying the consent request screen T1 (simply referred to as "consent request screen" in Figure 7) to the debtor terminal 400.

In step S105, when the debtor terminal 400 accepts the debtor's input on the consent request screen T1, it sends consent information to the receivables management device 100. This enables the receivables management system 10 to provide the assignee with third-party assertion requirements.

In step S106, the claim management device 100 stores the consent information in the claim information database D111.

In step S107, at least one of the creditor terminal 200 and the transferee terminal 300 sends an assignment confirmation request to the debt management device 100 to display the second assignment confirmation screen T3 on the display unit.

In step S108, the claim management device 100 transmits information for displaying the second transfer confirmation screen T3 (simply referred to as "second transfer confirmation screen" in Figure 7) to at least one of the creditor terminal 200 and the transferee terminal 300.

In step S109, the receivables management device 100 sends an execution request to the blockchain BN to execute the transfer contract, which causes the blockchain BN to store the agreement-related information, which is at least a portion of the information included in the acceptance information. At this time, the receivables management device 100 may include the agreement-related information in the request and send it to the blockchain BN. In step S110, the agreement-related information is recorded in the blockchain BN.

In other words, the receivables management system 10 allows the creditor, assignee, and debtor to confirm the agreement information (step S108) before storing the agreement-related information in the blockchain BN (step S109). This allows the receivables management system 10 to provide a mechanism that allows the creditor, assignee, and debtor to confirm the agreement information without waiting for the agreement-related information to be stored in the blockchain BN, thereby improving user convenience.

In step S111, the receivables management device 100 performs a matching process, for example, periodically. The receivables management device 100 sends an information request to the blockchain BN to transmit agreement-related information. The receivables management device 100 matches at least some of the information in the agreement information database D111 (for example, the ST contract address and the number of transfers) with the agreement-related information recorded in the blockchain BN.

In step S112, the receivables management device 100 stores the result of matching the agreement information with the agreement-related information in the receivables information database D111. If the receivables management device 100 obtains a matching result indicating a mismatch between the agreement information and the agreement-related information, it may send warning information to at least one of the creditor terminal 200, the assignee terminal 300, the debtor terminal 400, and the financial institution terminal 500, indicating that data may have been tampered with. This allows the receivables management system 10 to respond appropriately and quickly if information stored in a database that does not use blockchain is tampered with.

===First Modification===
<<Configuration>>
The configuration of the receivable management system 10a according to the first modification will be described with reference to Figure 8. Figure 8 is a diagram showing an example of the configuration of the receivable management system 10a according to the first modification. Note that, below, differences from the receivable management system 10 will be described, and unless otherwise specified, the receivable management system will be considered to be the same as the receivable management system 10.

As shown in FIG. 8, in the receivable management system 10a, the receivable management device 100 further includes a requirements determination unit 170.

The requirements determination unit 170 determines whether the creditor and transferee meet the requirements for transferring a security token related to a claim (hereinafter referred to as the "transfer requirements"). The requirements determination unit 170 determines whether the transfer requirements are met, for example, by referring to the whitelist HL stored in the blockchain BN.

The transfer requirements are requirements for a creditor to transfer a security token to a transferee. The transfer requirements are, for example, requirements included in the requirements for exclusion from the application of the "right to transfer electronic records" (Article 9-2 of the "Cabinet Office Ordinance on the Definitions Provided for in Article 2 of the Financial Instruments and Exchange Act"). In other words, the transfer requirements may be, for example, requirements that show that the creditor and transferee are qualified institutional investors as defined in the "Cabinet Office Ordinance on the Definitions Provided for in Article 2 of the Financial Instruments and Exchange Act," or investors within a scope similar to those eligible for special business operations for qualified institutional investors (special business eligible investors) as defined in the Financial Instruments and Exchange Act.

The whitelist HL is a list stored in the blockchain BN of information about users who meet the transfer requirements (hereinafter referred to as "acquirer information").

Based on the transfer request, the requirements determination unit 170 determines whether information about at least one of the creditor and transferee matches any of the multiple acquirer information included in the whitelist HL. Specifically, the requirements determination unit 170 may determine, for example, whether the wallet address of the transferee who wishes to transfer the claim matches multiple wallet addresses included in the whitelist HL. In other words, the requirements determination unit 170 may determine whether the wallet address of at least one of the creditor and transferee (which may be information about the creditor and transferee) is included in the whitelist HL, which is virtually impossible to tamper with.

As a result, the claim management device 100 allows the name of a claim to be changed only to creditors and transferees who meet the transfer requirements. In other words, the claim management device 100 is equipped with a mechanism that satisfies the requirements of, for example, Article 9-2, Paragraph 1, Item 1 of the Cabinet Office Ordinance on Definitions Provided for in Article 2 of the Financial Instruments and Exchange Act, by guaranteeing that a user meets the transfer requirements using an unalterable whitelist HL.

The requirements determination unit 170 may also determine, based on information indicating time restrictions (hereinafter referred to as "time restriction information"), whether the timing at which an agreement to transfer the claim is reached satisfies the time restrictions for transferring the security token. The timing at which an agreement to transfer the claim is reached may be, for example, the date and time at which the agreement included in the agreement information is established, or the date and time at which the transfer request is received. Specifically, the requirements determination unit 170 may determine that the security token cannot be transferred to the transferee if, for example, a predetermined period of time (e.g., one year as indicated by the time restriction information) has not passed since the creditor received the security token representing the claim. Note that the transfer requirements may include content indicating time restrictions (time restriction information).

As a result, the claim management system 10a allows only creditors who meet the time restrictions for the transfer procedure to transfer their claims to the transferee. In this way, the claim management system 10a does not impose time restrictions on the transfer of claims, and only creditors who meet the transfer requirements can transfer security tokens to the transferee.

If the requirements determination unit 170 determines that the transfer requirements are met, the display processing unit 140 transmits information to the debtor terminal 400 to display the consent request screen T1. Furthermore, if the requirements determination unit 170 determines that the timing at which the transfer request was acquired does not fall within the time restrictions for transferring the security token, the display processing unit 140 transmits information to the debtor terminal 400 to display the consent request screen T1.

In the modified claim management system 10a, the storage execution unit 150 may, for example, store user information of users who meet the security token transfer requirements in the blockchain BN in advance to generate a whitelist HL. The whitelist HL may store, for example, user IDs and wallet addresses. Transfer requirements and time limit information may also be stored in the whitelist HL.

Furthermore, the requirements determination unit 170 does not have to be a functional unit included in the receivable management device 100, but may be a functional unit included in the financial institution terminal 500, for example.

In addition, while the above description has been given with the requirement determination unit 170 determining whether the transfer requirements are met by referencing the whitelist HL stored in the blockchain BN, this is not limited to this. For example, the requirement determination unit 170 may use a database that stores the transfer requirements to determine whether the transfer requirements are met. This allows the claim management system 10a to have a simple system configuration without using a blockchain, and allows only creditors who meet the transfer requirements to transfer claims to transferees, without being subject to time restrictions for transferring claims.

<<Processing Procedure>>
Next, an example of the processing procedure of the claim management system 10a according to the first modified example will be described with reference to Fig. 9. Fig. 9 is a flowchart showing an example of the processing procedure of the claim management system 10a according to the first modified example. In Fig. 9, the processing after step S205 is the same as the processing after step S102 in the flowchart shown in Fig. 7, and therefore a description thereof will be omitted.

In step S200, the creditor terminal 200 accepts operational input from the creditor and transmits information about the creditor (hereinafter referred to as "creditor information") to the financial institution terminal 500. Similarly, the transferee terminal 300 transmits information about the transferee (hereinafter referred to as "transferee information") to the financial institution terminal 500.

In step S201, the financial institution terminal 500 displays the creditor information and transferee information on the display unit. The financial institution terminal 500 accepts operational input from the person in charge and sends an assignment request including the creditor information and transferee information to the credit management device 100.

In step S202, the claim management device 100 refers to the whitelist HL to determine whether the creditor and transferee meet the transfer requirements. The claim management device 100 transmits information indicating whether the transfer requirements are met (hereinafter referred to as "transferability information") to the financial institution terminal 500.

As a result, the receivables management system 10a uses a whitelist HL in which users who meet the transfer requirements are registered in an area that cannot be tampered with, allowing users who comply with laws and regulations to transfer and receive receivables when a receivables transfer event occurs. In other words, the receivables management system 10a is equipped with a mechanism that meets the requirements of Article 9-2, Paragraph 1, Item 1 of the Cabinet Office Ordinance on Definitions Provided for in Article 2 of the Financial Instruments and Exchange Act.

In step S203, if the financial institution terminal 500 obtains transferability information indicating that the transfer requirements are met, it transmits consent information to the claim management device 100 indicating consent that the financial institution can transfer the claim from the creditor to the transferee.

In step S204, the receivables management device 100 stores the consent information in the memory unit 110. In other words, the receivables management system 10a is equipped with a mechanism that meets the requirements of Article 9-2, Paragraph 1, Item 2 of the Cabinet Office Ordinance on Definitions Provided for in Article 2 of the Financial Instruments and Exchange Act.

In step S205, if the receivables management device 100 acquires consent information, it may store the creditor information, assignee information, and consent information in the whitelist HL of the blockchain BN. At this time, it may also associate time limit information with the assignee information and store it. From this point on, processing is executed from step S102 shown in Figure 7.

This allows the receivable management system 10a to transfer security tokens between users in accordance with laws and regulations regarding the transfer of security tokens. In other words, the receivable management system 10a can provide a mechanism that meets the requirements of Article 9-2, Paragraph 1, Items 1 and 2 of the Cabinet Office Ordinance on Definitions Provided for in Article 2 of the Financial Instruments and Exchange Act.

In the above, it has been described that step S201 is executed by the financial institution terminal 500, but this is not limited to this. For example, step S201 may be executed by the claim management device 100. In other words, the claim management device 100 may obtain creditor information and transferee information from the creditor terminal 200 and transferee terminal 300.

===Second Modification===
Next, the configuration of the receivable management system 10b according to the second modification will be described. Note that the following will focus on differences from the receivable management system 10 and the receivable management system 10a, and unless otherwise specified, the receivable management system will be considered the same as the receivable management system 10 and the receivable management system 10a.

Unlike the debt management system 10a, the debt management system 10b notifies the debtor that a debt assignment event has occurred, instead of requiring consent from the debtor.

The processing procedure of the receivable management system 10b will be described with reference to Figure 10. Figure 10 is a flowchart showing the processing procedure of the receivable management system 10b according to the second variant. Note that in Figure 10, steps S200 to S205 shown in Figure 9 may be executed before step S300.

In step S300, at least one of the creditor terminal 200 and the transferee terminal 300 sends a transfer request to the financial institution terminal 500.

In step S301, the financial institution terminal 500 accepts operational input from the person in charge and sends a transfer request including agreement information to the receivables management device 100.

In step S302, the receivables management device 100 stores the agreement information in the receivables information database D111. The receivables management device 100 references the receivables information database D111 and sends information for displaying the notification screen T4 (simply referred to as "Notification screen" in Figure 10) to the debtor terminal 400. In this case, the notification screen T4 may be, for example, "The name change has been carried out. Please confirm. The name change list is here," instead of "There is an unexecuted name change application. Please execute the name change. The name change application list is here," as shown in Figure 6. In other words, the notification screen T4 in the second variant may be configured to display a screen for confirming that the receivable has been transferred. In addition, instead of sending the notification screen T4, the receivables management device 100 may notify the debtor terminal 400 by email.

In step S303, when the debtor terminal 400 receives an input from the debtor regarding text T40a on the notification screen T4 in the second variant, which contains a link to display the first transfer confirmation screen T2, the debtor terminal 400 sends a display request to the receivables management device 100 to display the first transfer confirmation screen T2.

In step S304, the receivables management device 100 sends information for displaying the first transfer confirmation screen T2 (simply referred to as "first transfer confirmation screen" in Figure 10) to the debtor terminal 400.

In step S305, the debtor terminal 400 displays the first transfer confirmation screen T2 on the display unit. The debtor terminal 400 transmits information indicating that the debtor has viewed the first transfer confirmation screen T2 (hereinafter referred to as "confirmation information") to the debt management device 100.

In step S306, the claim management device 100 stores the confirmation information in the claim information database D111.

This allows the debt management system 10b to provide the assignee with third-party assertion. The processing from step S306 onwards is the same as the processing from step S104 onwards in the flowchart shown in Figure 7, so a description of that processing will be omitted.

The receivables management system 10b may further have a function (for example, a processing switching unit (not shown)) that can switch between the consent method (processing of steps S104 to S106 in FIG. 9) that obtains consent from the debtor in the receivables management system 10a, and the above-mentioned method of notifying the debtor (hereinafter referred to as the "notification method") (processing of steps S304 and S303 in FIG. 10).

In this case, for example, the receivables management device 100 acquires information specifying either the consent method or the notification method (hereinafter referred to as "designated information") from the financial institution terminal 500. When the receivables management device 100 acquires the designated information, it executes the notification method or the consent method processing based on the designated information.

Referring to Figure 11, the notification content confirmation screen T1a for the notification format will be described. Figure 11 is a diagram showing an example of the notification content confirmation screen T1a. Below, only differences from the acceptance request screen T1 shown in Figure 3 will be described, and unless otherwise noted, it will be considered the same as the acceptance request screen T1. As shown in Figure 11, the notification content confirmation screen T1a displays the claim assignment notification information T13a, which adds the "claim assignment notification date and time" to the claim assignment notification information T13 in Figure 3, changes the "claim assignment acceptance" in Figure 3 to the "claim assignment notice," and changes the "name change acceptance button" in Figure 3 to the "notification content confirmation button." Furthermore, in this case, when the notification format is specified, the claim management device 100 changes the "claim assignment acceptance content confirmation screen" in Figures 4 and 5 to the "claim assignment notification content confirmation screen," changes the "claim assignment acceptance date and time" on the "claim assignment acceptance content confirmation screen" to the "claim assignment notification date and time," and changes the "claim assignment acceptance" to the "claim assignment notice."

In other words, the receivables management device 100 can display confirmation screens corresponding to the consent type and notification type based on the specified information. This allows the receivables management system 10b to switch processing procedures and screen displays depending on whether or not the debtor's consent is required when transferring a security token (for example, when dealing with electronic record transfer rights, the debtor's consent is not required and only notification is required, whereas when dealing with exempt electronic transfer rights, the debtor's consent is required), making it possible to perform appropriate processing with simple operations.

===Hardware Configuration===
12, an example of a hardware configuration for implementing the claim management device 100, creditor terminal 200, assignee terminal 300, debtor terminal 400, and financial institution terminal 500 using a computer 1000 will be described. Note that the various functions of the claim management device 100, creditor terminal 200, assignee terminal 300, debtor terminal 400, and financial institution terminal 500 can be implemented by dividing them into multiple devices.

Figure 12 is a diagram showing an example of the hardware configuration of a computer. As shown in Figure 12, the computer 1000 includes, for example, a processor 1001, memory 1002, a storage device 1003, an input I/F unit 1004, a data I/F unit 1005, a communication I/F unit 1006, and a display unit 1007.

The processor 1001 is a control unit that controls various processes in the computer 1000 by executing programs stored in the memory 1002.

Memory 1002 is a storage medium such as RAM (Random Access Memory). Memory 1002 temporarily stores program code for programs executed by processor 1001 and data required when executing the programs.

The storage device 1003 is a non-volatile storage medium such as a hard disk drive (HDD) or flash memory. The storage device 1003 stores the operating system and various programs for implementing the above configurations.

The input I/F unit 1004 is a device for receiving input from the user. Specific examples of the input I/F unit 1004 include a keyboard, mouse, touch panel, various sensors, and wearable devices. The input I/F unit 1004 may be connected to the computer 1000 via an interface such as a USB (Universal Serial Bus).

The data I/F unit 1005 is a device for inputting data from outside the computer 1000. A specific example of the data I/F unit 1005 is a drive device for reading data stored on various storage media. The data I/F unit 1005 may also be provided outside the computer 1000. In that case, the data I/F unit 1005 is connected to the computer 1000 via an interface such as a USB.

The communication I/F unit 1006 is a device for performing data communication via the Internet N with devices external to the computer 1000, either wired or wirelessly. The communication I/F unit 1006 may also be provided external to the computer 1000. In that case, the communication I/F unit 1006 is connected to the computer 1000 via an interface such as a USB.

The display unit 1007 is a device for displaying various types of information. Specific examples of the display unit 1007 include a liquid crystal display, an organic EL (Electro-Luminescence) display, and a wearable device display. The display unit 1007 may be provided external to the computer 1000. In that case, the display unit 1007 is connected to the computer 1000 via, for example, a display cable. Furthermore, if a touch panel is used as the input I/F unit 1004, the display unit 1007 can be configured as an integrated unit with the input I/F unit 1004.

===Summary===
The claim management system 10 includes a display processing unit 140 that displays an acceptance request screen T1 on the debtor's display unit, which accepts input from the debtor regarding acceptance of an agreement for the assignment of a claim from the creditor to the assignee; an acceptance information acquisition unit 130 that acquires acceptance information, which is information indicating acceptance of the agreement via input from the debtor on the acceptance request screen T1; and a memory execution unit 150 that, when the acceptance information acquisition unit 130 acquires, stores agreement information, which is information regarding the content of the agreement, in a claim information database D111 (database).When the agreement information is stored in the claim information database D111 (database), the display processing unit 140 displays first and second assignment confirmation screens T2 and T3 (assignment confirmation screens) on the display unit, on which the agreement information can be confirmed, based on input from any of the creditor, assignee, and debtor.This enables the claim management system 10 to appropriately and quickly assign a claim from the creditor to the assignee and to prepare the assignee for third-party assertion. Furthermore, compared to offline operations, the receivables management system 10 can improve the efficiency of receivables transactions, reduce transaction costs, shorten the time required for transactions, and avoid operational risks.

In addition, in the claim management system 10, the storage execution unit 150 stores a security token indicating agreement-related information, which is at least part of the information included in the agreement information, in the blockchain BN, and the information processing system further includes a comparison unit 160 that checks whether specified information included in the agreement information stored in the claim information database D111 (database) matches specified information included in the agreement-related information stored in the blockchain BN. This allows the claim management system 10 to quickly detect data tampering by comparing the information recorded in the claim information database D111 (database) with the information recorded in the blockchain area.

The receivables management system 10 also includes an assignment request acquisition unit 120 that acquires an assignment request, including agreement information, from at least one of the debtor and the assignee, indicating that the receivables are to be assigned from the creditor to the assignee. When an assignment request is acquired by the assignment request acquisition unit 120, the display processing unit 140 displays a notification screen T4 on the debtor's display unit that includes a notice to the debtor regarding their consent. This allows the receivables management system 10 to quickly notify the debtor that a receivables assignment event has occurred, and further allows a screen for the debtor to consent to the receivables assignment to be displayed with a simple operation, thereby quickly completing the receivables assignment within the system.

In addition, in the receivables management system 10, when the display processing unit 140 receives an input from the debtor in response to text T40a (object) on the notification screen T4 indicating a notice to the debtor regarding consent, the display processing unit 140 displays the consent request screen T1 on the debtor's display unit. This allows the receivables management system 10 to display a screen for the debtor to consent to the receivables assignment with a simple operation, thereby enabling the receivables assignment to be completed quickly on the system.

In addition, in the claim management system 10a, the memory execution unit 150 stores acquirer information, which is information about acquirers who meet the transfer requirements for being able to transfer a claim, in at least one of the claim information database D111 (database) or the blockchain BN. The claim management system 10 further includes an assignment request acquisition unit 120 that acquires an assignment request from at least one of the creditor and assignee to assign the claim to the assignee, and a requirements determination unit 170 that determines, based on the assignment request, whether the information about the assignee matches any of the multiple acquirer information stored in at least one of the claim information database D111 (database) or the blockchain BN. If the requirements determination unit 170 determines that the information about the assignee matches any of the multiple acquirer information, the display processing unit 140 displays the consent request screen T1 on the debtor's display unit. This allows the claim management system 10 to change the name of a claim only to creditors and assignees who meet the transfer requirements.

In addition, in the claim management system 10a, the memory execution unit 150 associates time restriction information, which is information regarding the time restriction within which the acquirer can transfer the claim, with the acquirer information and stores it in at least one of the claim information database D111 (database) or the blockchain BN, the requirements determination unit 170 determines whether the timing at which the agreement to transfer the claim was made falls under the time restriction corresponding to the creditor based on the time restriction information, and the display processing unit 140 displays the consent request screen T1 on the debtor's display unit if the requirements determination unit 170 determines that the timing at which the agreement to transfer the claim was made does not fall under the time restriction. As a result, the claim management system 10 allows only creditors who meet the time restrictions regarding the transfer procedure to transfer their claims to the assignee.

The above-described embodiments are intended to facilitate understanding of the present invention and are not intended to limit the scope of the present invention. The elements of the embodiments, as well as their arrangement, materials, conditions, shape, size, etc., are not limited to those illustrated and can be modified as appropriate. Furthermore, configurations shown in different embodiments can be partially substituted or combined.

10...Debt management system, 100...Debt management device, 110...Memory unit, 120...Transfer request acquisition unit, 130...Consent information acquisition unit, 140...Display processing unit, 150...Memory execution unit, 160...Collation unit, 170...Requirements determination unit, 200...Creditor terminal, 300...Transferee terminal 300, 400...Debtor terminal, 500...Financial institution terminal.

Claims (7)

a display processing unit that displays an acceptance request screen on a display unit of the debtor, the acceptance request screen receiving an operation input regarding acceptance by the debtor of the claim, regarding an agreement for the transfer of the claim from the creditor of the claim to an assignee;
an approval information acquisition unit that acquires approval information, which is information indicating approval of the agreement by the debtor through an operation input on the approval request screen;
a storage execution unit that, when the consent information acquisition unit acquires the consent information, stores consent information, which is information regarding the content of the agreement, in a database and stores a security token, which indicates agreement-related information, which is at least a portion of the information included in the consent information, in a blockchain;
a verification unit that verifies whether predetermined information included in the agreement information stored in the database matches predetermined information included in the agreement-related information stored in the blockchain, and if the agreement information and the agreement-related information do not match, transmits warning information indicating that data tampering has occurred to at least one of the creditor terminal, the assignee terminal, the debtor terminal, and the financial institution terminal ;
When the agreement information is stored in the database, the display processing unit displays an assignment confirmation screen on the display unit, on which the agreement information can be confirmed, based on an operation input by any one of the creditor, the assignee, and the debtor.
Information processing system. an assignment request acquisition unit that acquires, from at least one of the debtor and the assignee, an assignment request including the agreement information indicating that the claim is to be assigned from the creditor to the assignee;
When the transfer request acquisition unit acquires the transfer request, the display processing unit displays a notice screen including a notice regarding acceptance by the debtor on the display unit of the debtor.
The information processing system according to claim 1 . the display processing unit, when receiving an operation input from the debtor on an object on the notification screen indicating a notification regarding the debtor's acceptance, causes the acceptance request screen to be displayed on the display unit of the debtor;
The information processing system according to claim 2 . The storage execution unit stores acquirer information, which is information about an acquirer who satisfies the transfer requirements that are requirements for allowing the claim to be transferred, in at least one of a database or a blockchain;
The information processing system includes:
an assignment request acquisition unit that acquires an assignment request for assigning the claim to the assignee from at least one of the creditor and the assignee;
a requirement determination unit that determines, based on the transfer request, whether information about the transferee matches any of the multiple pieces of acquirer information stored in at least one of the database or the blockchain;
Furthermore,
the display processing unit displays the consent request screen on the display unit of the debtor when the requirements determination unit determines that the information on the transferee matches any of the plurality of acquirer information.
The information processing system according to claim 1 . the storage execution unit stores time limit information, which is information regarding a time limit during which the acquirer can transfer the claim, in at least one of the database or the blockchain in association with the acquirer information;
The requirement determination unit determines, based on the time limit information, whether or not the timing at which the agreement to transfer the claim is made falls under the time limit corresponding to the creditor;
the display processing unit displays the consent request screen on the display unit of the debtor when the requirements determination unit determines that the timing at which the agreement to transfer the claim was made does not fall under the time limit.
The information processing system according to claim 4 . The computer
displaying an approval request screen on a display unit of the debtor for accepting an operation input regarding approval by the debtor of the claim regarding an agreement for the transfer of the claim from the creditor of the claim to the transferee;
acquiring consent information which is information indicating consent to the agreement by the debtor through an operation input on the consent request screen;
When the consent information is acquired, store agreement information, which is information regarding the content of the agreement, in a database , and store a security token, which indicates agreement-related information, which is at least a portion of the information included in the agreement information, in a blockchain.
Verify whether predetermined information included in the agreement information stored in the database matches predetermined information included in the agreement-related information stored in the blockchain, and if the agreement information and the agreement-related information do not match, send warning information indicating that data tampering has occurred to at least one of the creditor terminal, the assignee terminal, the debtor terminal, and the financial institution terminal;
When the agreement information is stored in the database, displaying an assignment confirmation screen on a display unit, on which the agreement information can be confirmed, based on an operation input by any one of the creditor, the assignee, and the debtor;
An information processing method that performs the above. On the computer,
displaying an approval request screen on a display unit of the debtor for accepting an operation input regarding approval by the debtor of the claim regarding an agreement for the transfer of the claim from the creditor of the claim to the transferee;
acquiring consent information which is information indicating consent to the agreement by the debtor through an operation input on the consent request screen;
When the consent information is acquired, store agreement information, which is information regarding the content of the agreement, in a database , and store a security token, which indicates agreement-related information, which is at least a portion of the information included in the agreement information, in a blockchain.
Verify whether predetermined information included in the agreement information stored in the database matches predetermined information included in the agreement-related information stored in the blockchain, and if the agreement information and the agreement-related information do not match, send warning information indicating that data tampering has occurred to at least one of the creditor terminal, the assignee terminal, the debtor terminal, and the financial institution terminal;
When the agreement information is stored in the database, displaying an assignment confirmation screen on a display unit, on which the agreement information can be confirmed, based on an operation input by any one of the creditor, the assignee, and the debtor;
A program that executes the following.