Program, method, and information processing system

Abstract

This program is used for an information processing system comprising a user terminal operable by a user and a server. The program causes the server to execute: a storage step of storing cryptographic assets in a predetermined user wallet associated with the user; an allocation step of allocating a contract relating to a payment destination to the predetermined user wallet; a settlement step of performing settlement with respect to a system provided by a settlement provider in response to reception of a request related to the settlement performed by the user terminal; and a transfer step of executing processing of transferring, without obtaining approval of withdrawal corresponding to the settlement from the user, the cryptographic assets corresponding to the settlement from the user wallet on the basis of the contract.

Description

Program, method, and information processing system

[0001] The present disclosure relates to a program, a method, and an information processing system.

[0002] Credit card payment services using crypto assets are known. Patent Literature 1 discloses a technology that provides a user-friendly wallet while ensuring the authenticity of transactions between wallets.

[0003] JP 2003-030671 A

[0004] There is a problem that a highly convenient payment service using crypto assets has not been provided. Therefore, the present disclosure has been made to solve the above problem, and its purpose is to provide a highly convenient payment service using crypto assets.

[0005] A program used in an information processing system consisting of a user terminal operable by a user and a server, which causes the server to execute the following steps: a storage step of storing crypto assets in a specified user wallet associated with the user; an allocation step of storing in the user wallet the address of a collateral contract associated with a specified payee as the transfer destination of the crypto assets; a settlement step of making a payment to a payment system provided by a payment service provider in response to receiving a request for payment made by the user terminal; and a transfer step of executing a process to transfer crypto assets corresponding to the payment from the user wallet to the specified payee as a transaction on a blockchain based on the collateral contract, without obtaining approval from the user for the withdrawal corresponding to the payment.

[0006] According to the present disclosure, it is possible to provide a highly convenient payment service using crypto assets.

[0007] 1 is a block diagram showing the functional configuration of the system 1. FIG. 1 is a block diagram showing the operation of the system 1. FIG. 1 is a block diagram showing the functional configuration of the server 10. FIG. 1 is a block diagram showing the functional configuration of the user terminal 20. FIG. 1 is a diagram showing the data structure of a user table 1012. FIG. 1 is a flowchart showing the operation of an initial setting process. FIG. 1 is a block diagram showing the operation of an initial setting process. FIG. 1 is a sequence diagram showing the operation of an initial setting process. FIG. 1 is a flowchart showing the operation of a card use process. FIG. 1 is a block diagram showing the operation of a card use process. FIG. 1 is a sequence diagram showing the operation of a card use process. FIG. 1 is a flowchart showing the operation of a settlement process A (first embodiment). FIG. 1 is a block diagram showing the operation of a settlement process A (first embodiment). FIG. 1 is a sequence diagram showing the operation of a settlement process A (first embodiment). FIG. 1 is a flowchart showing the operation of a settlement process A (second embodiment). FIG. 1 is a block diagram showing the operation of a settlement process A (second embodiment). FIG. 1 is a sequence diagram showing the operation of a settlement process A (second embodiment). FIG. 1 is a flowchart showing the operation of a settlement process A (third embodiment). FIG. 1 is a block diagram showing the operation of a settlement process A (third embodiment). FIG. 1 is a flowchart showing the operation of a two-dimensional code use process. FIG. 1 is a block diagram showing the operation of a two-dimensional code use process. FIG. 1 is a sequence diagram showing the operation of a two-dimensional code use process. FIG. 1 is a flowchart showing the operation of a settlement process B (first embodiment). FIG. 1 is a block diagram showing the operation of a settlement process B (first embodiment). 1 is a sequence diagram showing the operation of settlement processing B (first embodiment). FIG. 2 is a flowchart showing the operation of settlement processing B (second embodiment). FIG. 3 is a block diagram showing the operation of settlement processing B (second embodiment). FIG. 4 is a sequence diagram showing the operation of settlement processing B (second embodiment). FIG. 5 is a flowchart showing the operation of settlement processing B (third embodiment). FIG. 6 is a block diagram showing the operation of settlement processing B (third embodiment). FIG. 7 is a sequence diagram showing the operation of settlement processing B (third embodiment). FIG. 8 is a flowchart showing the operation of transfer processing. FIG. 9 is a block diagram showing the operation of transfer processing. FIG. 10 is a flowchart showing the operation of limit change processing. FIG. 11 is a block diagram showing the operation of limit change processing. FIG. 12 is a sequence diagram showing the operation of limit change processing.FIG. 2 is a block diagram showing the basic hardware configuration of a computer 90.

[0008] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In all drawings describing the embodiments, common components are designated by the same reference numerals, and repeated description will be omitted. Note that the following embodiments do not unduly limit the content of the present disclosure described in the claims. Furthermore, not all components shown in the embodiments are necessarily essential components of the present disclosure. Furthermore, each drawing is a schematic diagram and is not necessarily a precise illustration.

[0009] <Configuration of System 1> System 1 in the present disclosure is an information processing system that provides payment services (card payment and two-dimensional code payment) secured by crypto assets. System 1 includes information processing devices, such as a server 10, a user terminal 20, a payment terminal 30, a blockchain 50, a third-party approval entity 60, a card system 70, and a two-dimensional code payment system 80, which are connected via a network N. Fig. 1 is a block diagram showing the functional configuration of system 1. Fig. 2 is a block diagram showing the operation of system 1. Fig. 3 is a block diagram showing the functional configuration of the server 10. Fig. 4 is a block diagram showing the functional configuration of the user terminal 20.

[0010] Each information processing device is configured by a computer equipped with an arithmetic unit and a storage device. The basic hardware configuration of the computer and the basic functional configuration of the computer realized by this hardware configuration will be described later. For each of the server 10, user terminal 20, payment terminal 30, blockchain 50, third-party approval entity 60, card system 70, and two-dimensional code payment system 80, descriptions that overlap with the basic hardware configuration and basic functional configuration of the computer described later will be omitted. In this disclosure, the card system 70 and two-dimensional code payment system 80 are collectively referred to as the payment system.

[0011] <Configuration of Server 10> The server 10 is an information processing device that provides payment services secured by crypto assets. Specifically, the payment services include payment using two-dimensional codes such as two-dimensional codes and card payment. The server 10 includes a memory unit 101 and a control unit 104.

[0012] <Configuration of Storage Unit 101 of Server 10 > The storage unit 101 of the server 10 includes an application program 1011 and a user table 1012 .

[0013] User table 1012 is a table that stores and manages information about member users (hereinafter referred to as users) who use the service. When a user registers to use the service, the user's information is stored in a new record in user table 1012. This allows the user to use the service according to the present disclosure. User table 1012 is a table that uses the user ID as the primary key and has columns for user ID, user name, user data, credit limit, registered cryptographic assets for payment, and unsettled balance. Figure 5 is a diagram showing the data structure of user table 1012.

[0014] The user ID is a field that stores user identification information for identifying a user. The user identification information is a field that is assigned a unique value for each user. The user name is a field that stores the user's name. The user name can be any string of characters, such as a nickname, instead of a name. User data includes the user's unique information and attribute information related to the user's characteristics and background. The user's unique information includes the user's date of birth (age), gender, etc. The user's attribute information includes the user's educational history (highest level of education, major, graduation year), occupation, work history, interests, place of residence, language, etc. The spending limit is a field that stores the maximum amount of cryptocurrency payments set by the user. This amount cannot be set to exceed the value of the cryptocurrency stored in the user wallet 501. The spending limit applies to the total amount used for card payments and two-dimensional code and amount code payments. The registered payment cryptocurrency is a field that stores the type of cryptocurrency (token) the user will use for payments. Multiple tokens can be registered, and the addresses and identifiers of each cryptocurrency asset are stored. This information is referenced during asset management in the user wallet 501 and during payment processing in the card system 70 and two-dimensional code payment system 80. Cryptocurrency assets not registered in the registered payment cryptocurrency assets cannot be used for payments, but users can freely deposit and withdraw them. The unsettled balance is a field that stores the amount of the user's card payment and two-dimensional code payment usage that has not yet been settled. This balance is the total amount of card payment and two-dimensional code payment made by the user with cryptocurrency minus the amount already settled. The settlement contract 521 or collateral contract 522 references this value during periodic settlement processing and transfers the necessary funds. The unsettled balance is also checked when the credit limit is changed, and the credit limit cannot be set lower than the unsettled balance.

[0015] The user table 1012 may also include the following payment method setting items. The payment method setting items store setting information for the payment methods available to the user. The user can select only card payment, only 2D code payment, or both payment methods. By default, both card payment and 2D code payment are enabled. This setting allows the user to control the payment method according to their own usage style. The 2D payment setting items store setting information specific to 2D code payment. Specifically, these include the selection of the 2D code generation method (fixed 2D code, dynamic 2D code), the authentication level for 2D code payment (requiring PIN entry, using biometric authentication), the 2D code payment limit (maximum amount per transaction, maximum amount per day), and automatic settlement settings for 2D code payment. These settings are managed independently of the card payment settings, allowing the user to adjust the balance between convenience and security for 2D code payment. The payment history management item allows the user to separately manage the usage history for card payment and 2D code payment. This information includes the payment type (card payment or 2D code payment), payment date and time, payment amount, merchant information, payment status (approved, rejected, waiting for settlement, settled), and in the case of 2D code payment, the type of 2D code used (static 2D, dynamic 2D, NFC). This information is referenced during settlement processing in the collateral contract 522 to transfer funds to the appropriate settlement destination depending on the payment type. It is also used to analyze user payment patterns and generate usage statistics by payment method.

[0016] <Configuration of the control unit 104 of the server 10> The control unit 104 of the server 10 includes a user registration control unit 1041. The control unit 104 executes the application program 1011 stored in the storage unit 101, thereby realizing each functional unit.

[0017] The user registration control unit 1041 performs a process of storing information about users who wish to use the service disclosed herein in the user table 1012. Information stored in the user table 1012 is generated when a user opens a webpage operated by the service provider from an information processing terminal, enters information into a predetermined input form, and transmits the information to the server 10. The user registration control unit 1041 stores the received information in a new record in the user table 1012, completing user registration. This allows the user stored in the user table 1012 to use the service. Prior to the user registration control unit 1041 registering user information in the user table 1012, the service provider may conduct a predetermined screening process to restrict whether or not the user can use the service. The user ID may be any string or number that can identify the user. It may be any string or number desired by the user, or the user registration control unit 1041 may automatically set any string or number.

[0018] <Configuration of User Terminal 20> The user terminal 20 is an information processing device operated by a user who uses a service. The user terminal 20 may be, for example, a mobile terminal such as a smartphone or tablet, or a stationary personal computer (PC) or laptop PC. It may also be a wearable terminal such as a head mounted display (HMD) or a wristwatch terminal. The user terminal 20 includes a storage unit 201, a control unit 204, an input device 206, and an output device 208.

[0019] <Configuration of Storage Unit 201 of User Terminal 20> The storage unit 201 of the user terminal 20 includes a user ID 2011, an application program 2012, and an EOA wallet 2013.

[0020] The user ID 2011 is the user's account ID. The user transmits the user ID 2011 from the user terminal 20 to the server 10. The server 10 identifies the user based on the user ID 2011 and provides the user with the services according to the present disclosure. The user ID 2011 includes information such as a session ID temporarily assigned by the server 10 to identify the user using the user terminal 20.

[0021] The application program 2012 may be stored in advance in the storage unit 201, or may be downloaded from a web server operated by a service provider via a communication IF. The application program 2012 includes an application such as a web browser application. The application program 2012 includes an interpreter-type programming language such as JavaScript (registered trademark) that is executed on a web browser application stored in the user terminal 20.

[0022] EOA Wallet 2013 (Externally Owned Account Wallet) is a software component for crypto asset management. This wallet controls Externally Owned Accounts (EOA) on the blockchain and serves as the foundation for users to securely interact with the system and the blockchain network.

[0023] <Configuration of control unit 204 of user terminal 20> The control unit 204 of the user terminal 20 includes an input control unit 2041 and an output control unit 2042. The control unit 204 executes an application program 2012 stored in the storage unit 201, thereby realizing each functional unit.

[0024] <Configuration of Input Device 206 of User Terminal 20> The input device 206 of the user terminal 20 includes a camera 2061 , a microphone 2062 , a position information sensor 2063 , a motion sensor 2064 , and a touch device 2065 .

[0025] <Configuration of Output Device 208 of User Terminal 20 > The output device 208 of the user terminal 20 includes a display 2081 and a speaker 2082 .

[0026] <Configuration of Payment Terminal 30> The payment terminal 30 is an information processing device for performing credit card payments and two-dimensional code payments at credit card member stores and two-dimensional code payment member stores (general stores, websites, etc. that sell products, services, etc.). The payment terminal 30 may be, for example, a mobile terminal such as a smartphone or tablet, or may be a stationary personal computer (PC) or laptop PC. The payment terminal 30 is equipped with a camera 3061 or a two-dimensional code scanner, etc., and includes a function for reading a two-dimensional code presented by a user, and a display 3081 for outputting a dynamic two-dimensional code including the payment amount and store information.

[0027] <Structure of Blockchain 50> Blockchain 50 is a system that implements distributed digital ledger technology. This system serves as the foundation for safely and transparently recording and managing cryptocurrency transactions and contract execution. Blockchain is maintained by multiple nodes and has a structure that makes it extremely difficult to tamper with.

[0028] <Configuration of the Third-Party Approval Entity 60> The third-party approval entity 60 is an information processing device provided by a third party different from the business providing the server. The third-party approval entity 60 is an approval authority that ensures the security and reliability of transactions in a credit card payment system secured by crypto assets. The third-party approval entity 60 provides additional approval for withdrawals of funds from the user wallet 501 and operations of the entire system. The third-party approval entity functions as part of a multi-signature process to prevent fraudulent transactions and erroneous operations. The existence of this entity strengthens the security of the entire system and increases the trust of both users and businesses.

[0029] <Configuration of Card System 70> The card system 70 is an information processing device that provides services related to conventional credit cards, such as card issuance, transaction processing, authorization, settlement, etc. The card system 70 provides a secure payment environment, including encryption of communication with affiliated stores and payment information, and fraud detection.

[0030] <Configuration of two-dimensional code payment system 80> The two-dimensional code payment system 80 is an information processing device that provides two-dimensional code payment services such as payment processing, transaction authentication, and settlement using QR codes (registered trademark) and barcodes. The two-dimensional code payment system 80 provides a secure and high-speed payment environment, including communication with affiliated stores, encryption of payment information, real-time fraud detection, and immediate payment processing.

[0031] <Operation of System 1> Each process of system 1 will now be described. FIG. 6 is a flowchart showing the operation of the initial setting process. FIG. 7 is a block diagram showing the operation of the initial setting process. FIG. 8 is a sequence diagram showing the operation of the initial setting process. FIG. 9 is a flowchart showing the operation of the card use process. FIG. 10 is a block diagram showing the operation of the card use process. FIG. 11 is a sequence diagram showing the operation of the card use process. FIG. 12 is a flowchart showing the operation of settlement process A (first embodiment). FIG. 13 is a block diagram showing the operation of settlement process A (first embodiment). FIG. 14 is a sequence diagram showing the operation of settlement process A (first embodiment). FIG. 15 is a flowchart showing the operation of settlement process A (second embodiment). FIG. 16 is a block diagram showing the operation of settlement process A (second embodiment). FIG. 17 is a sequence diagram showing the operation of settlement process A (second embodiment). FIG. 18 is a flowchart showing the operation of settlement process A (third embodiment). FIG. 19 is a block diagram showing the operation of settlement process A (third embodiment). FIG. 20 is a sequence diagram showing the operation of settlement process A (third embodiment). FIG. 21 is a flowchart showing the operation of the two-dimensional code use process. FIG. 22 is a block diagram showing the operation of the two-dimensional code use process. FIG. 23 is a sequence diagram showing the operation of the two-dimensional code use process. FIG. 24 is a flowchart showing the operation of the settlement process B (first embodiment). FIG. 25 is a block diagram showing the operation of the settlement process B (first embodiment). FIG. 26 is a sequence diagram showing the operation of the settlement process B (first embodiment). FIG. 27 is a flowchart showing the operation of the settlement process B (second embodiment). FIG. 28 is a block diagram showing the operation of the settlement process B (second embodiment). FIG. 29 is a sequence diagram showing the operation of the settlement process B (second embodiment). FIG. 30 is a flowchart showing the operation of the settlement process B (third embodiment). FIG. 31 is a block diagram showing the operation of the settlement process B (third embodiment). FIG. 32 is a sequence diagram showing the operation of the settlement process B (third embodiment). FIG. 33 is a flowchart showing the operation of the transfer process.Fig. 34 is a block diagram showing the operation of transfer processing. Fig. 35 is a sequence diagram showing the operation of transfer processing. Fig. 36 is a flowchart showing the operation of limit change processing. Fig. 37 is a block diagram showing the operation of limit change processing. Fig. 38 is a sequence diagram showing the operation of limit change processing.

[0032] <Initial Setting Processing> The initial setting processing is processing for performing initial settings when using the payment service according to the present disclosure. Fig. 6 is a flowchart showing the operation of the initial setting processing. Fig. 7 is a block diagram showing the operation of the initial setting processing. Fig. 8 is a sequence diagram showing the operation of the initial setting processing.

[0033] <Overview of Initial Setup Process> The initial setup process is a series of steps consisting of a user registration step, a user wallet creation step, a wallet information registration step, a payment cryptographic asset transfer step, a payment registration step, and a spending limit setting step.

[0034] <Details of Initial Setting Process> Details of the initial setting process will be described below.

[0035] <User Registration Step> In step S101, the user operates the input device 206 of the user terminal 20 to execute the application program 2012 (hereinafter referred to as the user application) stored in the storage unit 201, and registers the user for the payment service provided by the server 10 according to the present disclosure. The control unit 104 of the server 10 stores the user information received from the user terminal 20 in the user name and user data fields of a new record in the user table 1012. This causes the user information to be stored in the server 10.

[0036] <User Wallet Generation Step> In step S102, the user application sends a signed request for wallet generation to the EOA Wallet 2013. The EOA Wallet 2013 sends a signed transaction for wallet generation to the Wallet Factory contract 531. The Wallet Factory contract 531 generates a new user wallet 501.

[0037] <Wallet Information Registration Step> In step S103, the generated user wallet 501 sends a webhook to the server 10 to notify the completion of generation. The control unit 104 of the server 10 completes the user registration including the information of the user wallet 501, and updates the corresponding record in the user table 1012. The server 10 notifies the user terminal 20 of the completion of registration.

[0038] <Payment Crypto Asset Sending Step> In step S104, the control unit 104 of the server 10 executes a storing step of storing the crypto asset in a predetermined user wallet associated with the user. Specifically, the user sends (transfers) the payment crypto asset to the created user wallet 501. The user performs a remittance operation via the user app, and transfers the payment crypto asset from the EOA wallet 2013 to the user wallet 501. This operation causes the crypto asset for payment to be stored in the user wallet 501.

[0039] <Payee Registration Step> In step S105, the control unit 104 of the server 10 executes an allocation step of allocating a settlement contract related to the payee to a specified user wallet. Specifically, the user performs a payee registration operation using a user application. The user application sends a signature request for payee registration to the EOA wallet 2013. The EOA wallet 2013 sends a signed transaction for payee registration to the user wallet 501. The user wallet 501 registers the payee and returns the result to the user application. The server 10 records the registered payee information in the registered payment cryptographic asset field of the corresponding record in the user table 1012.

[0040] <Credit Limit Setting Step> In step S106, the user uses the user application to register a credit limit. The user application sends a signed request for credit limit registration to the EOA wallet 2013. The EOA wallet 2013 sends a signed transaction for credit limit registration to the user wallet 501. The user wallet 501 checks whether the credit limit is appropriate by comparing it with the current balance. Specifically, the credit limit cannot be set to exceed the value of the cryptocurrency stored in the user wallet 501. The server 10 registers the credit limit based on the check result and returns the result to the user application. The server 10 records the approved credit limit in the credit limit field of the corresponding record in the user table 1012. For details of the credit limit setting step, see the credit limit change process described below.

[0041] <Card Usage Processing> The card usage processing is a process in which a user purchases goods or services with a credit card at a card member store (general store) or the like. Fig. 9 is a flowchart showing the operation of the card usage processing. Fig. 10 is a block diagram showing the operation of the card usage processing. Fig. 11 is a sequence diagram showing the operation of the card usage processing.

[0042] <Outline of Card Usage Processing> Card usage processing is a series of steps consisting of a payment initiation step, an available balance confirmation step, and a sales processing step.

[0043] <Details of Card Usage Processing> Details of card usage processing will be explained below.

[0044] <Payment Start Step> In step S301, the control unit 104 of the server 10 executes a payment step of performing a card payment with a card system provided by a card payment service provider in response to receiving a card payment request made by the user terminal. Specifically, the user operates the input device 206 of the user terminal 20 to execute a user application stored in the storage unit 201 and purchases goods or services at a card affiliated store such as a shop or website by card payment. The user performs the payment operation via the user application. The control unit 204 of the user terminal 20 transmits payment information to the payment terminal 30 of the affiliated store. The payment terminal 30 of the affiliated store transmits an authorization (credit) acquisition request to the card system 70 provided by a credit card payment service provider (such as VISA, MasterCard, or JCB) that includes a user ID 2011 that can identify the user (the user ID 2011 includes information for identifying the user's credit card, such as the user's credit card number), the payment amount (the amount of the goods or services purchased), and other information necessary for credit card payment. The card system 70 transmits the received authorization request to the server 10. The control unit 104 of the server 10 receives and accepts the authorization request.

[0045] <Available Amount Confirmation Step> In step S302, the payment step executes a step of making a card payment within the upper limit set in the upper limit amount setting step. Prior to the payment step, the control unit 104 of the server 10 executes an authorization acquisition step of receiving an authorization request based on a request related to card payment. Specifically, the control unit 104 of the server 10 searches the user ID field in the user table 1012 based on the received user ID 2011 and acquires the credit limit field. The control unit 104 of the server 10 compares the amount obtained by subtracting the unsettled balance from the credit limit with the current payment amount to determine whether the payment is possible. Specifically, if the subtracted amount is greater than the payment amount, the control unit 104 determines that the payment is possible, and if the subtracted amount is less than the payment amount, the control unit 104 determines that the payment is not possible. If the control unit 104 of the server 10 determines that the payment is possible, it requests the settlement contract 521 to temporarily lock the authorized amount. The settlement contract 521 temporarily locks the authorized amount in the user wallet 501. This prevents duplicate payments. In the present disclosure, if a credit limit is set for the user, the balance of the user wallet 501 is not queried. This eliminates the need to query the user wallet, thereby improving the speed of card payment processing. The settlement contract 521 may be configured to check the balance of the user wallet 501. The control unit 104 of the server 10 confirms that the authorization amount has been successfully locked and sends a response to the card system 70 including information indicating that payment is possible. The card system 70 sends a response including payment approval to the payment terminal 30 of the affiliated store. If the control unit 104 of the server 10 determines that payment is not possible, it sends a response to the card system 70 including information indicating that payment is not possible. The card system 70 sends a response including payment denial to the payment terminal 30 of the affiliated store.

[0046] <Sales Processing Step> In step S303, if a maximum amount is set in the maximum amount setting step, the settlement step executes a step of making a card payment without querying a specific user wallet. The control unit 104 of the server 10 executes a lockstep that locks the transfer of crypto assets in the user wallet in response to the authorization acquisition request received in the authorization acquisition step. The settlement step executes a step of making a card payment after the lockstep. Specifically, the payment terminal 30 of the affiliated store sends a sales processing request to the card system 70. The card system 70 sends the received sales processing request to the server 10. The server 10 confirms the sales based on the sales processing request received from the card system 70. The server 10 updates the unsettled balance of the corresponding record in the user table 1012 to a new unsettled balance obtained by adding the current sales amount to the original unsettled balance. The server 10 requests the settlement contract 521 to lock the confirmed sales amount. The settlement contract 521 completely locks the temporarily locked authorization amount by the confirmed sales amount. The settlement contract 521 locks the confirmed sales amount in the user wallet 501, thereby holding the amount until settlement. This allows for safe and transparent payments using blockchain technology while maintaining the same convenience as regular cards. Temporary locking at the time of authorization and complete locking after the sales are confirmed allows for proper management of funds and prevents duplicate payments.

[0047] <Two-dimensional code payment processing> The two-dimensional code payment processing is a process in which a user purchases goods or services using a two-dimensional code at a two-dimensional code payment affiliated store (general store) or the like. This processing supports multiple code formats such as two-dimensional code model 2, EAN-128, NFC standard, and Bluetooth POS protocol, and can be used for both store-presented and consumer-presented payment methods. Figure 21 is a flowchart showing the operation of the two-dimensional code payment processing. Figure 22 is a block diagram showing the operation of the two-dimensional code payment processing. Figure 23 is a sequence diagram showing the operation of the two-dimensional code payment processing.

[0048] <Overview of Two-Dimensional Code Payment Processing> The two-dimensional code payment processing is a series of steps consisting of a two-dimensional code payment initiation step, an available balance confirmation step, and a payment processing step. This two-dimensional code payment processing supports payment triggers using the following various code formats: Two-dimensional code model 2: A standard QR code format used in conventional two-dimensional code payments. EAN-128: A one-dimensional barcode format widely used for product identification and logistics management. NFC standard: Payment via short-range wireless communication using Near Field Communication technology. Bluetooth POS protocol: Communication with a store terminal using Bluetooth Low Energy (BLE). For each code format, the user terminal 20 and payment terminal 30 acquire payment information using a corresponding reader function (camera 2061, NFC reader, Bluetooth module, etc.). The acquired payment information is sent to the server 10 in a unified format regardless of the code format.

[0049] <Details of Two-dimensional Code Payment Processing> Details of the two-dimensional code payment processing will be described below.

[0050] <Two-dimensional code payment start step> In step S401, the control unit 104 of the server 10 executes a payment step of performing two-dimensional code payment with a two-dimensional code payment system provided by a two-dimensional code payment business operator in response to receiving a request for two-dimensional code payment made by a user terminal. Specifically, the user operates the input device 206 of the user terminal 20 to execute a user application stored in the storage unit 201 and purchases goods or services, etc., at a two-dimensional code payment affiliated store, such as a shop or website, using two-dimensional code payment. The user performs two-dimensional code payment operation via the user application. The control unit 204 of the user terminal 20 reads the two-dimensional code generated by the affiliated store's payment terminal 30, or presents the two-dimensional code generated by the user to the affiliated store's payment terminal 30. The affiliated store's payment terminal 30 transmits a payment processing request to the two-dimensional code payment system 80 provided by the two-dimensional code payment business operator, including a user ID 2011 that can identify the user, a payment amount (the amount of the purchased goods or services, etc.), and other information necessary for two-dimensional code payment. The two-dimensional code payment system 80 transmits the received payment processing request to the server 10. The control unit 104 of the server 10 receives and accepts the payment processing request.

[0051] Specifically, when a user reads a two-dimensional code displayed on the display 3081 of the payment terminal 30 using the camera 2061 of the user terminal 20, the payment terminal 30 generates a dynamic two-dimensional code including the payment amount and store information and displays it on the display 3081. The user terminal 20 reads the two-dimensional code using the camera 2061 and acquires the payment information. This method is called a store-presented method, in which the user initiates payment by scanning the two-dimensional code provided by the store. In the store-presented method, the payment terminal 30 generates a two-dimensional code including the payment amount and store information. After the user terminal 20 reads the two-dimensional code and confirms the payment information, the user performs a payment approval operation. The user terminal 20 transmits a payment request including the read payment information and the user ID 2011 to the payment terminal 30. Alternatively, the user terminal 20 may directly transmit the user ID 2011 and payment information to the two-dimensional code payment system 80. When payment is made via the payment terminal 30, the payment terminal 30 transmits a payment request including the payment information and user ID 2011 received from the user terminal 20 to the two-dimensional code payment system 80. When payment is made directly, the user terminal 20 transmits a payment request including the payment information and user ID 2011 to the two-dimensional code payment system 80. In the store-presented type using the NFC standard, the payment terminal 30 writes the payment information to an NFC tag or NFC-compatible device, and the NFC reader of the user terminal 20 reads the information. When EAN-128 is used, the payment terminal 30 generates a barcode including the payment amount and store information, and reads it with the camera 2061 of the user terminal 20. In the Bluetooth POS protocol, the payment terminal 30 broadcasts the payment information using a BLE signal, which is received by the Bluetooth module of the user terminal 20.

[0052] Specifically, when the camera 3061 of the payment terminal 30 reads a two-dimensional code displayed on the display 2081 of the user terminal 20, the user terminal 20 generates a two-dimensional code including user identification information and payment amount information and displays it on the display 2081. The payment terminal 30 reads the two-dimensional code using the camera 3061 or a scanner, acquires user information, and then inputs the payment amount to begin payment processing. This method is called the consumer-presented method, in which the user initiates payment by having the store scan their own two-dimensional code. In the consumer-presented method, the two-dimensional code generated by the user terminal 20 includes the user ID 2011, so the payment terminal 30 identifies the user when it reads the two-dimensional code. The payment terminal 30 displays the read user information, and a store staff member inputs the payment amount via the input device 306. After the payment amount has been input, the payment terminal 30 generates a payment processing request by combining the acquired user ID 2011 with the input payment amount. In the consumer-presented type using the NFC standard, the NFC function of the user terminal 20 is used to send user identification information to the payment terminal 30, and the payment amount is entered at the payment terminal 30 to start the process. In the Bluetooth POS protocol, the user terminal 20 broadcasts user information using a BLE signal, which is received by the payment terminal 30, where the payment is processed after the amount is entered.

[0053] The payment terminal 30 of the affiliated store or the user terminal 20 transmits a payment processing request to the two-dimensional code payment system 80 provided by the two-dimensional code payment business operator, including a user ID 2011 capable of identifying the user, the payment amount (the amount of the purchased item, such as a product or service), and other information necessary for two-dimensional code payment. The two-dimensional code payment system 80 transmits the received payment processing request to the server 10. The control unit 104 of the server 10 receives and accepts the payment processing request. The two-dimensional code payment processing of the present disclosure may be performed using either a store-presented or consumer-presented method. Note that the present disclosure may also be applied to any other two-dimensional code payment processing. While the present disclosure describes typical store-presented and consumer-presented methods, the user ID 2011, identification information of the payment terminal 30, the payment amount, etc. may be configured to be transmitted to the two-dimensional code payment system 80 from any information processing terminal, such as the user terminal 20 or the payment terminal 30. The two-dimensional code payment of the present disclosure may be applied to any form of two-dimensional code payment.

[0054] <Available Amount Confirmation Step> In step S402, the payment step executes a step of performing two-dimensional code payment within the upper limit set in the upper limit amount setting step. Prior to the payment step, the control unit 104 of the server 10 executes a payment processing request reception step of receiving a payment processing request based on a request related to two-dimensional code payment. Specifically, the control unit 104 of the server 10 searches the user ID field in the user table 1012 based on the received user ID 2011 and obtains the credit limit field. The control unit 104 of the server 10 compares the amount obtained by subtracting the unsettled balance from the credit limit with the current payment amount to determine whether the payment is possible. Specifically, if the subtracted amount is greater than the payment amount, the control unit 104 determines that the payment is possible, and if the subtracted amount is less than the payment amount, the control unit 104 determines that the payment is not possible. If the control unit 104 of the server 10 determines that the payment is possible, it requests the collateral contract 522 to temporarily lock the payment amount. The collateral contract 522 temporarily locks the payment amount in the user wallet 501. This prevents duplicate payments. In the present disclosure, if a spending limit is set for a user, the balance of the user wallet 501 is not checked. This eliminates the need to check the user wallet, thereby improving the speed of the two-dimensional code payment process. The collateral contract 522 may be configured to check the balance of the user wallet 501. The control unit 104 of the server 10 confirms that the payment amount has been successfully locked and sends a response to the two-dimensional code payment system 80 including information indicating that the payment is possible. The two-dimensional code payment system 80 sends a response including payment approval to the payment terminal 30 of the affiliated store. If the control unit 104 of the server 10 determines that the payment is not possible, it sends a response to the two-dimensional code payment system 80 including information indicating that the payment is not possible. The two-dimensional code payment system 80 sends a response including payment denial to the payment terminal 30 of the affiliated store.

[0055] <Payment Processing Step> In step S403, if a maximum amount limit has been set in the maximum amount setting step, the payment step executes a step of making a two-dimensional code payment without querying a specific user wallet. The control unit 104 of the server 10 executes a lockstep that locks the transfer of crypto assets in the user wallet in response to the payment processing request received in the payment processing request receiving step. After the lockstep, the payment step executes a step of making a two-dimensional code payment. Specifically, the payment terminal 30 of the affiliated store sends a payment confirmation request to the two-dimensional code payment system 80. The two-dimensional code payment system 80 sends the received payment confirmation request to the server 10. The server 10 confirms the payment based on the payment confirmation request received from the two-dimensional code payment system 80. The server 10 updates the unsettled balance of the corresponding record in the user table 1012 to a new unsettled balance obtained by adding the current payment amount to the original unsettled balance. The server 10 requests the collateral contract 522 to lock the confirmed payment amount. The collateral contract 522 completely locks the temporarily locked payment amount by the confirmed payment amount. The collateral contract 522 locks the confirmed payment amount in the user wallet 501, thereby holding the amount until settlement. This enables safe and transparent payments using blockchain technology while maintaining the same convenience as general 2D code payments. The temporary lock at the time of payment and the complete lock after the payment is confirmed enable proper management of funds and prevention of duplicate payments.

[0056] <External System Integration via SDK / API Integration> This two-dimensional code payment process is equipped with an SDK / API mechanism that enables integration with external applications (such as POS systems, e-commerce sites, subscription services, and P2P remittance functions within social networking sites). The external system can implement the payment process using the following three API endpoints: Payment Instruction API: Receives payment requests (parameters such as code type, payment recipient, amount, and deadline) from the external system and registers a payment reservation in the collateral contract 522. Status Inquiry API: Responds to inquiries from the external system with payment status (in progress / approved / rejected) and settlement status (unpaid / settled) in real time. Settlement Processing API: Receives settlement triggers from the external system. The control unit 104 of the server 10 executing each embodiment of settlement process B internally processes payment requests received from the external system via the API in the same way as requests from the two-dimensional code payment system 80. This allows external systems to seamlessly implement a Slash-secured deferred payment experience within their own apps.

[0057] <Settlement Process A (First Embodiment)> Settlement process A (first embodiment) is a process for periodically transferring crypto assets from a user wallet in response to the user's use of card payments. Note that, when the card is issued, the user individually entrusts the business operator, third-party approval entity, and BIN sponsor with signatures for the transfer of crypto assets. This allows each entity to sign independently, ensuring security and transparency. FIG. 12 is a flowchart showing the operation of settlement process A (first embodiment). FIG. 13 is a block diagram showing the operation of settlement process A (first embodiment). FIG. 14 is a sequence diagram showing the operation of settlement process A (first embodiment).

[0058] <Outline of Settlement Process A (First Embodiment)> The settlement process A (first embodiment) is a series of processes including a usage history inquiry step, a billing aggregation step, and a transfer step.

[0059] <Details of Settlement Process A (First Embodiment)> Details of the settlement process A (first embodiment) will be described below.

[0060] <Usage History Inquiry Step> In step S501A, the card system 70 transmits a request for claiming a settlement amount including the card usage history for a predetermined period to the server 10. The request includes the user ID of the user related to the usage history (information for identifying the user, user ID 2011 in this disclosure).

[0061] In step S502A, the control unit 104 of the server 10 executes a billing aggregation step for aggregating billing amounts based on the user's card payment usage history for one or more card transactions from the card system for each predetermined period. Specifically, the control unit 104 of the server 10 searches the user ID field in the user table 1012 based on the user ID 2011 included in the received request and acquires user information. The control unit 104 of the server 10 aggregates billing data for each user based on the received usage history. The control unit 104 of the server 10 checks the usage history and the locked amount and calculates the amount to be settled (usage fee) associated with the user's card usage for the predetermined period. Specifically, the control unit 104 of the server 10 calculates the amount to be settled by adding up the amounts of all transactions within the predetermined period (total transaction amount), subtracting the amount already locked (amount locked at the time of authorization), and adding any unprocessed amounts from past settlements. In the settlement process A (first embodiment) of the present disclosure, the control unit 104 of the server 10 does not send the user a message including information indicating that payment is to be made by a predetermined payment due date. However, the control unit 104 of the server 10 may send the user a message including information indicating that payment is to be made by a predetermined payment due date. In this case, the user can perform the settlement process without waiting for the settlement due date using the settlement process A (second embodiment) or settlement process A (third embodiment) described below.

[0062] <Transfer Step> In step S503A, the control unit 104 of the server 10 executes a transfer step in which the crypto asset corresponding to the card payment is transferred from the user wallet based on the settlement contract without obtaining approval from the user for the withdrawal corresponding to the card payment. The transfer step executes a step of transferring the crypto asset from the user wallet in response to receiving approval from a third-party approval entity when transferring the crypto asset from the user wallet. The transfer step executes a step of transferring the crypto asset from the user wallet according to the billing amount tallied in the billing tally step. The transfer step executes a step of transferring the crypto asset from the user wallet to the business wallet of the business that provides the server. Specifically, when the payment due date arrives, the control unit 104 of the server 10 transfers the crypto asset to the deposit wallet using a joint signature (multi-sig method) using the private keys of the business, the third-party approval entity, and the BIN sponsor. In this case, the transfer cannot be executed using a single signature using the private key of either the business or the third-party approval entity.

[0063] Specifically, when the payment due date arrives, the control unit 104 of the server 10 transfers the crypto asset to the deposit wallet using a joint signature (multi-sig method) with the private keys of the business (the business that operates and provides the information processing system 1 according to the present disclosure), the third-party approval entity, and the BIN sponsor. In this case, the transfer cannot be made using a single signature with the private key of either the business or the third-party approval entity.

[0064] The control unit 104 of the server 10 registers a settlement process including information such as the user ID 2011, settlement amount, and settlement due date in the settlement contract 521. The control unit 104 of the server 10 sends an approval request including detailed information of the settlement process to the third-party approval entity 60. The third-party approval entity 60 sends a request to the card system 70 to inquire about the amount used by the user. The card system 70 sends a response to the third-party approval entity 60 including the amount used by the user for the requested period.

[0065] The third-party approval entity inquires with the card system about the amount used for the card payment in the payment step, and if the inquiry result is consistent with the cryptocurrency transferred from the user wallet, it outputs information indicating approval; if it is inconsistent, it does not output information indicating approval. Specifically, the third-party approval entity 60 compares the information received from the card system 70 with the settlement processing details received from the server 10 to confirm consistency. The third-party approval entity 60 confirms that the settlement period and settlement amount received from the server 10 match the usage period and usage amount received from the card system 70. Additionally, the third-party approval entity may also confirm, to the extent possible, whether each piece of transaction details (date and time, amount, affiliated store, etc.) received from the server 10 matches the usage details (date and time, amount, affiliated store, etc.) received from the card system 70. If the third-party approval entity 60 determines that the settlement processing information received from the server 10 and the usage information received from the card system 70 are consistent, it sends a signature to the settlement contract 521. On the other hand, if the third-party approval entity 60 determines that there is no consistency, it does not sign the settlement contract 521. In this case, the third-party approval entity 60 may transmit information indicating the consistency (including the user ID 2011, the content of the inconsistency, a timestamp, etc.) to the server 10 and the card system 70.

[0066] When the clearing contract 521 receives the signature of the third-party approval entity 60, it sends a signature request to the server 10. The control unit 104 of the server 10 checks the details of the clearing process, confirms its legitimacy, and then generates a signature using the business's private key. The control unit 104 of the server 10 sends the generated signature to the clearing contract 521. The clearing contract 521 confirms that both the signature of the third-party approval entity 60 and the business's signature have been received, and verifies whether the multi-signature (joint signature) requirements are met.

[0067] The settlement contract 521 verifies the requirements for the joint signature, and if signature confirmation is complete, executes a process to withdraw the usage fee from the user wallet 501. This process is performed without the user's explicit approval. This allows the user to realize a user-friendly card payment service that does not require the user to go through the trouble of approving the transfer of crypto assets for each card payment. In the present disclosure, in the transfer step, a screen for approving the transfer of crypto assets is not presented on the display 2081 of the user's user terminal 20, and the user's crypto assets are transferred without receiving any input operation for approval on the screen. The settlement contract 521 verifies the requirements for the joint signature, and if signature confirmation fails, it issues an error event and sends a message including information indicating the details of the error to the server 10.

[0068] The settlement contract 521 selects the business wallet, or the BIN sponsor's wallet if necessary, as the withdrawal destination based on the current situation (whether it is a normal settlement or a situation where funds need to be preserved by the BIN sponsor). Normally, the settlement contract 521 selects the business wallet as the withdrawal destination. In a situation where funds need to be preserved by the BIN sponsor, the settlement contract 521 selects the BIN sponsor's wallet as the withdrawal destination.

[0069] A BIN sponsor is a financial institution or authorized business entity that plays a central role in a card issuance program. The BIN sponsor owns a BIN (Bank Identification Number) assigned by an international card brand (such as Visa or Mastercard), which typically comprises the first six digits of the card number. The BIN sponsor has no capital relationship with the business that provides the information processing system 1 disclosed herein or with the third-party approval entity, and is an organization that is in a position to make independent decisions. The BIN sponsor has special authority when it determines that the right to claim settlement is necessary, and has the authority to transfer collateral crypto assets to the BIN sponsor's own wallet through a joint signature (multisig) with the third-party approval entity. The BIN sponsor enhances the security and reliability of the entire system.

[0070] The settlement contract 521 transfers crypto assets equivalent to the usage fee to the selected withdrawal destination. The settlement contract 521 generates a transaction on the blockchain and sends it including the source address (the address of the user wallet 501), the destination address (the selected withdrawal destination address), the transfer amount (the amount of crypto assets equivalent to the usage fee), and other transaction data (settlement information, timestamp, etc.). The settlement contract 521 monitors the status of the sent transaction and waits until it is confirmed on the blockchain. After the transaction is included in a block and a certain number of block confirmations have been made, the settlement contract 521 determines that the transfer is complete. The settlement contract 521 updates the balance and settled record of the user wallet 501.

[0071] The settlement contract 521 sends information indicating the completion of the transfer process to the server 10, including the user ID 2011, transfer amount, transfer destination address, transaction hash, timestamp, etc. The control unit 104 of the server 10 records the completion of the settlement process. The server 10 updates the current unsettled balance of the corresponding record in the user table 1012 to a new unsettled balance obtained by subtracting the current settlement amount (usage fee) from the current unsettled balance. This realizes a secure and highly transparent settlement process using the multi-sig method based on the user's prior signature entrustment. The involvement of a third-party approval entity and a BIN sponsor ensures the legitimacy of the process while enabling flexible fund management. Furthermore, security and transparency are ensured by each entity signing independently.

[0072] <Settlement Process A (Second Embodiment)> Settlement process A (second embodiment) is a process in which a user pays the price with cryptographic assets at any timing depending on the user's use of card payment. Specifically, the user transfers crypto assets equivalent to the usage price from any wallet to a deposit wallet managed by the business operator, BIN sponsor, and third-party approval entity using a multi-sig method by the payment due date. Fig. 15 is a flowchart showing the operation of settlement process A (second embodiment). Fig. 16 is a block diagram showing the operation of settlement process A (second embodiment). Fig. 17 is a sequence diagram showing the operation of settlement process A (second embodiment).

[0073] <Outline of Settlement Process A (Second Embodiment)> Settlement process A (second embodiment) is a series of processes including a settlement registration step, a deposit step, a settlement clearing step, and a transfer step.

[0074] <Details of Settlement Process A (Second Embodiment)> Details of the settlement process A (second embodiment) will be described below.

[0075] <Settlement Registration Step> Step S501B is the same process as step S501A, and therefore a description thereof will be omitted.

[0076] <Deposit Step> In step S502B, the user operates the input device 206 of the user terminal 20 to select, via the user app, to start the settlement process at any time (before the specified payment date). The control unit 104 of the server 10 checks the user's outstanding balance and transmits the amount to be settled to the user terminal 20, and the control unit 204 of the user terminal 20 presents the outstanding balance to the user. The user selects the cryptocurrency to use for payment. The selected cryptocurrency is a cryptocurrency supported by the system. The user transmits the selected cryptocurrency to a deposit wallet managed by the business operator, BIN sponsor, and third-party approval entity using a multi-sig scheme. The control unit 104 of the server 10 confirms receipt of the cryptocurrency in the deposit wallet. The confirmation process includes verifying the transaction, confirming the accuracy of the deposit amount, and confirming the validity of the cryptocurrency used. When the deposit is confirmed, the control unit 104 of the server 10 stores the deposit in association with the user. After confirming the payment, the control unit 104 of the server 10 sends a notification of the completion of payment to the user.

[0077] <Settlement Clearing Step> In step S503B, the control unit 104 of the server 10 instructs the settlement contract 521 to clear the settlement data. Upon receiving the clearing instruction, the settlement contract 521 checks all related data (user ID, deposit amount, deposit date and time, etc.). The settlement contract 521 checks the consistency between the amount of deposited cryptographic assets and the amount to be liquidated. If consistency is confirmed, the settlement contract 521 releases the temporary lock set on the user wallet 501. The settlement contract 521 updates the user's settlement status to "settled" and records information such as the settlement date and time and the settlement amount. The settlement contract 521 issues an event indicating the completion of the settlement data clearing on the blockchain. The settlement contract 521 notifies the control unit 104 of the server 10 of the completion of the settlement data clearing.

[0078] <Transfer Step> Step S504B is the same process as step S503A, and therefore a description thereof will be omitted.

[0079] <Settlement Process A (Third Embodiment)> Settlement process A (third embodiment) is a process in which a user pays the price in cash at any timing depending on the user's use of card payment. The user transfers money from their own bank account to the business operator's bank account by the payment due date. Fig. 18 is a flowchart showing the operation of settlement process A (third embodiment). Fig. 19 is a block diagram showing the operation of settlement process A (third embodiment). Fig. 20 is a sequence diagram showing the operation of settlement process A (third embodiment).

[0080] <Outline of Settlement Process A (Third Embodiment)> Settlement process A (third embodiment) is a series of processes including a settlement registration step, a deposit step, and a settlement clearing step.

[0081] <Details of Settlement Process A (Third Embodiment)> Details of the settlement process A (third embodiment) will be described below.

[0082] <Settlement Registration Step> Step S501C is the same process as step S501A, and therefore a description thereof will be omitted.

[0083] <Deposit Step> In step S502C, the user selects to start the settlement process at any time (before the specified payment date) through the user app. The control unit 104 of the server 10 checks the user's outstanding balance and presents the amount to be settled to the user. The user transfers cash from their own bank account to the business's bank account (business account). The control unit 104 of the server 10 confirms the deposit in the business account. When the deposit in the business account is confirmed, the control unit 104 of the server 10 stores this deposit in association with the user's records. The control unit 104 of the server 10 sends the user a notification that the deposit has been completed.

[0084] <Settlement Clearing Step> Step S503C is the same as step S503B, and therefore a description thereof will be omitted.

[0085] In settlement process A (third embodiment), no direct transfer of crypto assets takes place. By using the settlement contract 521, consistency between records on the blockchain and records in the conventional system can be maintained. Transparency and reliability of the entire system are ensured. Users can make payments via the familiar method of conventional bank transfer, so it is also suitable for users who are unfamiliar with handling crypto assets.

[0086] <Settlement Process B (First Embodiment)> Settlement Process B (First Embodiment) is a process for periodically transferring crypto assets from a user wallet in response to a user's use of two-dimensional code payment. This embodiment supports payment triggers using various code formats, such as two-dimensional code model 2, EAN-128, the NFC standard, and the Bluetooth POS protocol, and is usable for both user-presented and store-presented payment methods. Note that, when a user begins using the two-dimensional code payment service, they individually entrust the business operator, third-party approval entity, and BIN sponsor with signing for the transfer of crypto assets. This allows each entity to sign independently, ensuring security and transparency. FIG. 24 is a flowchart showing the operation of Settlement Process B (First Embodiment). FIG. 25 is a block diagram showing the operation of Settlement Process B (First Embodiment). FIG. 26 is a sequence diagram showing the operation of Settlement Process B (First Embodiment).

[0087] <Outline of Settlement Process B (First Embodiment)> The settlement process B (first embodiment) is a series of processes including a usage history inquiry step, a billing aggregation step, and a transfer step.

[0088] <Details of Settlement Process B (First Embodiment)> Details of the settlement process B (first embodiment) will be described below.

[0089] <Usage History Inquiry Step> In step S511A, the two-dimensional code payment system 80 sends a request for claiming a settlement amount including a usage history of two-dimensional code payment for a predetermined period to the server 10. The request includes the user ID of the user related to the usage history (information for identifying the user, user ID 2011 in this disclosure).

[0090] In step S512A, the control unit 104 of the server 10 executes a billing aggregation step for aggregating billing amounts based on the user's usage history of one or more two-dimensional code payments from the two-dimensional code payment system for each predetermined period. Specifically, the control unit 104 of the server 10 searches the user ID field in the user table 1012 based on the user ID 2011 included in the received request and acquires user information. The control unit 104 of the server 10 aggregates billing data for each user based on the received usage history. The control unit 104 of the server 10 checks the usage history and the locked amount and calculates the amount to be settled (usage fee) associated with the user's use of two-dimensional code payment during the predetermined period. Specifically, the control unit 104 of the server 10 calculates the amount to be settled by adding up the amounts of all transactions within the predetermined period (total transaction amount), subtracting the amount already locked (the amount locked at the time of payment approval), and adding any unprocessed amounts from previous settlements. In the settlement process B (first embodiment) of the present disclosure, the control unit 104 of the server 10 does not send the user a message including information indicating that payment is to be made by a predetermined payment due date. However, the control unit 104 of the server 10 may send the user a message including information indicating that payment is to be made by a predetermined payment due date. In this case, the user can perform the settlement process without waiting for the settlement due date using the settlement process B (second embodiment) or settlement process B (third embodiment) described below.

[0091] <Transfer Step> In step S513A, the control unit 104 of the server 10 executes a transfer step in which the crypto asset corresponding to the two-dimensional code payment is transferred from the user wallet based on the collateral contract without obtaining approval for the withdrawal corresponding to the two-dimensional code payment from the user. The transfer step executes a step of transferring the crypto asset from the user wallet in response to receiving approval from a third-party approval entity when transferring the crypto asset from the user wallet. The transfer step executes a step of transferring the crypto asset from the user wallet according to the billing amount tallied in the billing tally step. The transfer step executes a step of transferring the crypto asset from the user wallet to the business wallet of the business that provides the server. Specifically, when the payment due date arrives, the control unit 104 of the server 10 transfers the crypto asset to the deposit wallet using a joint signature (multi-sig method) using the private keys of the business, the third-party approval entity, and the BIN sponsor. In this case, the transfer cannot be executed using a single signature using the private key of either the business or the third-party approval entity.

[0092] Specifically, when the payment due date arrives, the control unit 104 of the server 10 transfers the crypto asset to the deposit wallet using a joint signature (multi-sig method) with the private keys of the business (the business that operates and provides the information processing system 1 according to the present disclosure), the third-party approval entity, and the BIN sponsor. In this case, the transfer cannot be made using a single signature with the private key of either the business or the third-party approval entity.

[0093] The control unit 104 of the server 10 registers the settlement process including information such as the user ID 2011, settlement amount, and settlement due date in the collateral contract 522. The control unit 104 of the server 10 sends an approval request including detailed information of the settlement process to the third-party approval entity 60. The third-party approval entity 60 sends a request to the two-dimensional code payment system 80 to inquire about the usage amount of the user. The two-dimensional code payment system 80 sends a response to the third-party approval entity 60 including the usage amount of the user for the requested period.

[0094] The third-party approval entity queries the two-dimensional code payment system for the amount used for the two-dimensional code payment in the payment step, and if the query result is consistent with the cryptocurrency to be transferred from the user wallet, outputs information indicating approval; if not, it does not output information indicating approval. Specifically, the third-party approval entity 60 compares the information received from the two-dimensional code payment system 80 with the settlement processing details received from the server 10 to confirm consistency. The third-party approval entity 60 confirms that the settlement period and settlement amount received from the server 10 match the usage period and usage amount received from the two-dimensional code payment system 80. Additionally, the third-party approval entity may also confirm, to the extent possible, whether each of the transaction details (date and time, amount, affiliated store, etc.) received from the server 10 matches the usage details (date and time, amount, affiliated store, etc.) received from the two-dimensional code payment system 80. If the third-party approval entity 60 determines that the settlement processing information received from the server 10 and the usage information received from the two-dimensional code payment system 80 are consistent, it sends a signature to the collateral contract 522. On the other hand, if the third-party approval entity 60 determines that there is no consistency, it does not sign the collateral contract 522. In this case, the third-party approval entity 60 may transmit information indicating the consistency (including the user ID 2011, the details of the consistency, a timestamp, etc.) to the server 10 and the two-dimensional code payment system 80.

[0095] When the collateral contract 522 receives the signature of the third-party approval entity 60, it sends a signature request to the server 10. The control unit 104 of the server 10 checks the details of the settlement process, confirms its legitimacy, and then generates a signature using the business's private key. The control unit 104 of the server 10 sends the generated signature to the collateral contract 522. The collateral contract 522 confirms that both the signature of the third-party approval entity 60 and the business's signature have been received, and verifies whether the multi-signature (joint signature) requirements are met.

[0096] The collateral contract 522 verifies the requirements for the joint signature, and if signature confirmation is complete, executes a process to withdraw the payment from the user wallet 501. This process is performed without the user's explicit approval. This allows the user to realize a user-friendly two-dimensional code payment service that does not require the user to approve the transfer of crypto assets for each two-dimensional code payment. In the present disclosure, in the transfer step, a screen for approving the transfer of crypto assets is not presented on the display 2081 of the user's user terminal 20, and the user's crypto assets are transferred without receiving any input operation for approval on the screen. If the collateral contract 522 verifies the requirements for the joint signature and signature confirmation fails, it issues an error event and sends a message including information indicating the details of the error to the server 10.

[0097] The collateral contract 522 selects the operator wallet, or if necessary, the BIN sponsor's wallet, as the withdrawal destination based on the current situation (normal settlement or a situation requiring fund preservation by the BIN sponsor). Normally, the collateral contract 522 selects the operator wallet as the withdrawal destination. In a situation requiring fund preservation by the BIN sponsor, the collateral contract 522 selects the BIN sponsor's wallet as the withdrawal destination.

[0098] A BIN sponsor is a financial institution or authorized business entity that plays a central role in the two-dimensional code payment program. The BIN sponsor owns a payment identification number assigned by the international payment network. The BIN sponsor has no capital relationship with the business that provides the information processing system 1 disclosed herein or with the third-party approval entity, and is an organization that is in a position to make independent decisions. The BIN sponsor has special authority when it determines that the right to claim settlement money needs to be preserved, and has the authority to transfer collateral crypto assets to the BIN sponsor's own wallet through a joint signature (multisig) with the third-party approval entity. The BIN sponsor enhances the security and reliability of the entire system.

[0099] The collateral contract 522 transfers crypto assets equivalent to the usage fee to the selected withdrawal destination. The collateral contract 522 generates a transaction on the blockchain and sends it including the source address (the address of the user wallet 501), the destination address (the selected withdrawal destination address), the transfer amount (the amount of crypto assets equivalent to the usage fee), and other transaction data (settlement information, timestamp, etc.). The collateral contract 522 monitors the status of the sent transaction and waits until it is confirmed on the blockchain. After the transaction is included in a block and a certain number of block confirmations have passed, the collateral contract 522 determines that the transfer is complete. The collateral contract 522 updates the balance and settled record of the user wallet 501.

[0100] The collateral contract 522 sends information indicating the completion of the transfer process to the server 10, including the user ID 2011, transfer amount, transfer destination address, transaction hash, timestamp, etc. The control unit 104 of the server 10 records the completion of the settlement process. The server 10 updates the current unsettled balance of the corresponding record in the user table 1012 to a new unsettled balance obtained by subtracting the current settlement amount (usage fee) from the current unsettled balance. This realizes a secure and highly transparent settlement process using the multi-sig method based on the user's prior signature entrustment. The involvement of a third-party approval entity and a BIN sponsor ensures the legitimacy of the process while enabling flexible fund management. Furthermore, security and transparency are ensured by each entity signing independently.

[0101] <Settlement Process B (Second Embodiment)> Settlement Process B (Second Embodiment) is a process in which a user pays with crypto assets at any time depending on the user's use of two-dimensional code payment. This embodiment is configured to allow the user to select settlement with stablecoins such as USDC from another non-custodial wallet, which constitutes one element of structurally avoiding applicability as a prepaid payment instrument. Specifically, the user transfers crypto assets equivalent to the usage fee from any wallet to a deposit wallet managed by the business operator, BIN sponsor, and third-party approval entity using a multi-sig method by the payment due date. Figure 27 is a flowchart showing the operation of Settlement Process B (Second Embodiment). Figure 28 is a block diagram showing the operation of Settlement Process B (Second Embodiment). Figure 29 is a sequence diagram showing the operation of Settlement Process B (Second Embodiment).

[0102] <Outline of Settlement Process B (Second Embodiment)> Settlement process B (second embodiment) is a series of processes including a settlement registration step, a deposit step, a settlement clearing step, and a transfer step.

[0103] <Details of Settlement Process B (Second Embodiment)> Details of the settlement process B (second embodiment) will be described below.

[0104] <Settlement Registration Step> Step S511B is the same process as step S511A, and therefore a description thereof will be omitted.

[0105] <Deposit Step> In step S512B, the user operates the input device 206 of the user terminal 20 to select, via the user app, to start the settlement process at any time (before the specified payment date). The control unit 104 of the server 10 checks the user's outstanding balance and transmits the amount to be settled to the user terminal 20, and the control unit 204 of the user terminal 20 presents the outstanding balance to the user. The user selects the cryptocurrency to use for payment. The selected cryptocurrency is a cryptocurrency supported by the system. The user transmits the selected cryptocurrency to a deposit wallet managed by the business operator, BIN sponsor, and third-party approval entity using a multi-sig scheme. The control unit 104 of the server 10 confirms receipt of the cryptocurrency in the deposit wallet. The confirmation process includes verifying the transaction, confirming the accuracy of the deposit amount, and confirming the validity of the cryptocurrency used. When the deposit is confirmed, the control unit 104 of the server 10 stores the deposit in association with the user. After confirming the deposit, the control unit 104 of the server 10 sends the user a notification of deposit completion.

[0106] <Settlement Clearing Step> In step S513B, the control unit 104 of the server 10 instructs the collateral contract 522 to clear the settlement data. Upon receiving the clearing instruction, the collateral contract 522 checks all related data (user ID, deposit amount, deposit date and time, etc.). The collateral contract 522 checks the consistency between the amount of deposited cryptocurrency and the amount to be cleared. If consistency is confirmed, the collateral contract 522 releases the temporary lock set on the user wallet 501. The collateral contract 522 updates the user's settlement status to "settled" and records information such as the settlement date and time and the settlement amount. The collateral contract 522 issues an event on the blockchain indicating the completion of the settlement data clearing. The collateral contract 522 notifies the control unit 104 of the server 10 of the completion of the settlement data clearing.

[0107] <Transfer Step> Step S514B is the same process as step S513A, and therefore a description thereof will be omitted.

[0108] <Settlement Process B (Third Embodiment)> Settlement process B (third embodiment) is a process in which a user pays in cash at any timing depending on the user's use of two-dimensional code payment. This embodiment enables off-chain settlement using fiat, etc., and is an important component that structurally avoids applicability as a prepaid payment instrument. The user deposits money from their own bank account into the business operator's bank account by the payment due date. Figure 30 is a flowchart showing the operation of settlement process B (third embodiment). Figure 31 is a block diagram showing the operation of settlement process B (third embodiment). Figure 32 is a sequence diagram showing the operation of settlement process B (third embodiment).

[0109] <Outline of Settlement Process B (Third Embodiment)> Settlement process B (third embodiment) is a series of processes including a settlement registration step, a deposit step, and a settlement clearing step.

[0110] <Details of Settlement Process B (Third Embodiment)> Details of the settlement process B (third embodiment) will be described below.

[0111] <Settlement Registration Step> Step S511C is the same process as step S511A, and therefore a description thereof will be omitted.

[0112] <Deposit Step> In step S512C, the user selects to start the settlement process at any time (before the specified payment date) through the user app. The control unit 104 of the server 10 checks the user's outstanding balance and presents the amount to be settled to the user. The user transfers cash from their own bank account to the business's bank account (business account). The control unit 104 of the server 10 confirms the deposit in the business account. When the deposit in the business account is confirmed, the control unit 104 of the server 10 stores this deposit in association with the user's records. The control unit 104 of the server 10 sends the user a notification that the deposit has been completed.

[0113] <Settlement Clearing Step> Step S513C is the same as step S513B, and therefore a description thereof will be omitted.

[0114] In settlement process B (third embodiment), crypto assets are not directly transferred. The use of the collateral contract 522 ensures consistency between records on the blockchain and records in the conventional system. This ensures transparency and reliability throughout the system. Users can make payments via traditional bank transfers, a familiar method, even for users unfamiliar with crypto assets. Even with two-dimensional code payment, settlement can be performed using traditional payment methods while enjoying the convenience of payments, enabling the provision of services to a wide range of users. The collateral contract manages the consistency between two-dimensional code payment usage history and cash settlement records, achieving both the transparency of blockchain technology and compatibility with conventional financial systems. The first, second, and third embodiments of settlement process B ensure freedom of settlement method selection, thereby establishing practical specifications that do not fall under the category of prepaid payment instruments or electronic payment instruments. Furthermore, because funds are transferred based on the user's signature, the system is structurally excluded from the category of a funds transfer business.

[0115] <External System Integration via SDK / API Integration> Settlement Process B is equipped with an SDK / API mechanism that enables integration with external applications (POS systems, e-commerce sites, subscription services, P2P remittance functions within social media, etc.). External systems can implement a secured deferred payment experience within the app by using three endpoints: a payment instruction API (for sending parameters such as code type, payment target, amount, and deadline), a status inquiry API (for checking the unpaid / settled status), and a settlement processing API (for executing a settlement trigger). In response to a settlement request from an external system, the settlement processing API executes one of three modes: the first mode (regular automatic settlement), the second mode (cryptocurrency settlement at any time), or the third mode (cash settlement). The settlement results are notified to the external system via webhook or API and are reflected in billing processing and UX updates. This allows for general-purpose deferred payment infrastructure. The provided SDK allows external systems to implement payment flows compatible with a variety of code formats (QR Code (registered trademark), NFC, EAN-128, Bluetooth POS, etc.) using a unified interface.

[0116] <Technological advantages of being independent of international card brands> Settlement Process B does not rely on international card brand payment networks (such as VISA and MasterCard), and can build an independent infrastructure that achieves full integration with code payments such as QR / NFC. Autonomous settlement processing using collateral contract 522, decentralized governance using a multi-sig method, and decentralized management of payment records using a blockchain platform realize a highly flexible payment UX that is not restricted by international card brand payment networks. This allows it to function as a comprehensive payment solution, from in-store payments at convenience stores and other locations, to code payments between individuals, and even API integration in D2C apps and SaaS.

[0117] <Transfer Processing> The transfer processing is a series of processes in which a user withdraws funds from the contract wallet (user wallet 501). This processing consists of three main steps: a transfer instruction step, a balance check step, and a transfer step. Figure 33 is a flowchart showing the operation of the transfer processing. Figure 34 is a block diagram showing the operation of the transfer processing. Figure 35 is a sequence diagram showing the operation of the transfer processing.

[0118] <Transfer Process Overview> The transfer process is a series of steps including a withdrawal instruction from the user, confirmation of the payment cryptographic assets and balance check, and the actual transfer of funds. In this process, the user wallet, EOA wallet, and withdrawal destination wallet work in conjunction with each other.

[0119] <Transfer Instruction Step> In step S701, the user performs a withdrawal operation from the user wallet 501 via the user application by operating the input device 206 of the user terminal 20. The user specifies the withdrawal destination wallet and the withdrawal amount via the user application by operating the input device 206 of the user terminal 20. The user application sends a signature request for the withdrawal operation to the EOA wallet 2013. The EOA wallet 2013 sends a signed transaction for the withdrawal operation to the user wallet 501.

[0120] <Balance Check Step> In step S702, the user wallet 501 checks whether the cryptographic asset for which withdrawal is requested is registered as a payment cryptographic asset. If it is registered as a payment cryptographic asset, the user wallet 501 checks whether the amount obtained by subtracting the requested withdrawal amount from the current balance is equal to or greater than the usage limit. If the check shows that the amount is below the usage limit, the user wallet 501 rejects the withdrawal and ends the process. If the user wallet 501 is not registered as a payment cryptographic asset, the user wallet 501 does not check the balance and proceeds to the next step.

[0121] <Transfer Step> In step S703, the user wallet 501 executes the withdrawal based on the result of the balance check step. If the withdrawal is approved, the user wallet 501 transfers the cryptographic assets to the specified destination wallet. After the transfer is complete, the user wallet 501 sends a withdrawal completion notification to the user application. The user application displays the withdrawal completion notification to the user. The settlement contract 521 records the completion of the transfer process and issues an event as necessary. The control unit 104 of the server 10 updates the balance information of the corresponding user in the user table 1012.

[0122] <Amount Limit Change Processing> The amount limit change processing is a process for setting the upper limit amount for card payments and two-dimensional code payments. Fig. 36 is a flowchart showing the operation of the amount limit change processing. Fig. 37 is a block diagram showing the operation of the amount limit change processing. Fig. 38 is a sequence diagram showing the operation of the amount limit change processing.

[0123] <Outline of Limit Change Processing> The limit change processing is a series of steps consisting of a limit change operation step, a balance check, and a limit update step.

[0124] <Details of Limit Change Processing> Details of limit change processing will be described below.

[0125] <Limit Change Operation Step> In step S901, the user operates the input device 206 of the user terminal 20 to change the spending limit via the user application of the user terminal 20. The user specifies a new spending limit. The user application sends a signature request for the limit change operation to the EOA wallet 2013. The EOA wallet 2013 sends a signed transaction for the limit change operation to the user wallet 501.

[0126] <Balance Check Step> In step S902, the user wallet 501 checks whether the requested new limit does not exceed the wallet balance. If the new limit exceeds the wallet balance, the change request is rejected and the user is notified. The user wallet 501 queries the settlement contract 521 about the outstanding amount. The settlement contract 521 confirms the outstanding amount for the user and returns it to the user wallet 501. The user wallet 501 confirms that the new limit is equal to or greater than the outstanding amount.

[0127] <Limit Update Step> In step S903, if all checks in the balance check step are successful, the user wallet 501 sets a new spending limit. When the update is complete, the user wallet 501 sends a limit change completion notification to the user application. The user application displays the results of the limit change to the user. The settlement contract 521 records the completion of the limit change and issues an event as necessary. The control unit 104 of the server 10 updates the corresponding user's spending limit item in the user table 1012. This limit change process allows users to flexibly manage their spending limits. Consistency between the wallet balance and the outstanding balance is maintained, ensuring system security. Users can conveniently make card payments and two-dimensional code payments within the limit amount. Furthermore, since there is no need to query the user wallet when making card payments or two-dimensional code payments, the speed of card payments and two-dimensional code payment processing can be improved.

[0128] 39 is a block diagram showing the basic hardware configuration of a computer 90. The computer 90 includes at least a processor 901, a main storage device 902, an auxiliary storage device 903, and a communication IF 991 (interface). These components are electrically connected to one another by a communication bus 921.

[0129] The processor 901 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, registers, peripheral circuits, and the like.

[0130] The main storage device 902 is for temporarily storing programs, data to be processed by the programs, etc. For example, it is a volatile memory such as a DRAM (Dynamic Random Access Memory).

[0131] The auxiliary storage device 903 is a storage device for saving data and programs, such as a flash memory, a hard disk drive (HDD), a magneto-optical disk, a CD-ROM, a DVD-ROM, or a semiconductor memory.

[0132] The communication IF 991 is an interface for inputting and outputting signals for communicating with other computers via a network using a wired or wireless communication standard. The network is composed of the Internet, a LAN, various mobile communication systems constructed using wireless base stations, etc. For example, the network includes 3G, 4G, and 5G mobile communication systems, LTE (Long Term Evolution), and wireless networks (e.g., Wi-Fi (registered trademark)) that can connect to the Internet via a predetermined access point. In the case of a wireless connection, communication protocols include, for example, Z-Wave (registered trademark), ZigBee (registered trademark), and Bluetooth (registered trademark). In the case of a wired connection, the network also includes a network that is directly connected using a USB (Universal Serial Bus) cable, etc.

[0133] It should be noted that the computer 90 can be virtually realized by distributing all or part of each hardware configuration across multiple computers 90 and interconnecting them via a network. In this way, the concept of the computer 90 includes not only a computer 90 housed in a single housing or case, but also a virtualized computer system.

[0134] <Basic Functional Configuration of Computer 90> A description will be given of the functional configuration of the computer realized by the basic hardware configuration (FIG. 39) of the computer 90. The computer includes at least the functional units of a control unit, a storage unit, and a communication unit.

[0135] The functional units of the computer 90 can also be realized by distributing all or part of the functional units among multiple computers 90 interconnected via a network. The computer 90 is a concept that includes not only a single computer 90 but also a virtualized computer system.

[0136] The control unit is realized by the processor 901 reading various programs stored in the auxiliary storage device 903, loading them into the main storage device 902, and executing processing in accordance with the programs. The control unit can realize functional units that perform various types of information processing depending on the type of program. In this way, the computer is realized as an information processing device that performs information processing.

[0137] The functions performed by the components described herein may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (Central Processing Units), conventional circuits, and / or combinations thereof, programmed to perform the described functions. Processors include transistors and other circuits and are considered circuitry or processing circuitry. A processor may also be a programmed processor that executes a program stored in memory. In this specification, a circuit, unit, or means is hardware that is programmed to perform or executes the described functions. The hardware may be any hardware disclosed herein or any hardware known to be programmed to perform or execute the described functions. When the hardware is a processor, which is considered a type of circuitry, the circuit, means, or unit is a combination of hardware and software used to configure the hardware and / or processor.

[0138] The storage unit is realized by a main storage device 902 and an auxiliary storage device 903. The storage unit stores data, various programs, and various databases. The processor 901 can allocate a storage area corresponding to the storage unit in the main storage device 902 or the auxiliary storage device 903 in accordance with the programs. The control unit can cause the processor 901 to add, update, and delete data stored in the storage unit in accordance with the various programs.

[0139] The term "database" refers to a relational database, which manages data sets called tables and masters in a tabular format structurally defined by rows and columns, by associating them with each other. In a database, a table is called a table, a master, a column in a table is called a column, and a row in a table is called a record. In a relational database, relationships between tables and masters can be established and associated. Typically, each table and each master is assigned a column that serves as a primary key to uniquely identify a record, but assigning a primary key to a column is not required. The control unit can cause the processor 901 to add, delete, or update records in specific tables and masters stored in the storage unit according to various programs. Furthermore, by storing data, various programs, and various databases in the storage unit, the information processing device and information processing system according to the present disclosure can be considered to have been manufactured.

[0140] Note that the databases and masters in this disclosure may include any data structure in which information is structurally defined (such as a list, dictionary, associative array, or object). The data structure also includes data that can be considered as a data structure by combining data with functions, classes, methods, etc. written in any programming language.

[0141] The communication unit is realized by the communication IF 991. The communication unit realizes the function of communicating with other computers 90 via a network. The communication unit can receive information transmitted from other computers 90 and input the information to the control unit. The control unit can cause the processor 901 to execute information processing on the received information in accordance with various programs. Furthermore, the communication unit can transmit information output from the control unit to other computers 90.

[0142] <Additional Notes> The matters described in the above embodiments will be added below.

[0143] (Supplementary Note 1) A program used in an information processing system comprising a user terminal operable by a user and a server, the program causing the server to execute the following steps: a storage step (S104) of storing crypto assets in a specified user wallet associated with the user; an allocation step (S105) of storing in the user wallet the address of a collateral contract associated with a specified payee as the transfer destination of the crypto assets; a settlement step (S301, S401) of making a payment to a payment system provided by a payment service provider in response to receiving a payment request made by the user terminal; and a transfer step (S503, S513) of executing a process of transferring crypto assets corresponding to the payment from the user wallet to the specified payee as a transaction on a blockchain based on the collateral contract, without obtaining approval from the user for the withdrawal corresponding to the payment. This enables a highly convenient payment service using crypto assets. Specifically, a user-friendly payment service can be realized that does not require the user to approve the transfer of crypto assets for each payment.

[0144] (Supplementary Note 2) The program according to Supplementary Note 1, wherein the payment step (S301) is a step of performing a card payment to a payment system provided by a card payment business in response to receiving a request for card payment made by a user terminal. This improves the security and reliability of the system. It is possible to detect fraudulent transactions, operational errors, etc.

[0145] (Supplementary Note 3) The program according to Supplementary Note 1, wherein the payment step (S401) is a step of performing a two-dimensional code payment to a payment system provided by a two-dimensional code payment business in response to receiving a request for two-dimensional code payment made by a user terminal. This allows the transfer of crypto assets to be carried out appropriately, improving the reliability of the system.

[0146] (Supplementary Note 4) The program according to Supplementary Note 1, wherein the information processing system includes a third-party approval entity, which is an information processing device provided by a third party different from the business providing the server, and the transfer step (S503, S513) is a step of transferring crypto assets from the user wallet in response to receiving approval from the third-party approval entity when transferring crypto assets from the user wallet. This allows the user to conveniently make two-dimensional code payments within the upper limit amount.

[0147] (Supplementary Note 5) The program according to Supplementary Note 4, in which the third-party approval entity queries the payment system for the amount used for the payment in the payment step, and outputs information indicating approval if the query result matches the cryptocurrency to be transferred from the user wallet, and does not output information indicating approval if the query result does not match. This eliminates the need to query the user wallet, thereby improving the speed of the two-dimensional code payment process.

[0148] (Supplementary Note 6) The program according to Supplementary Note 1 causes the server to execute an upper limit amount setting step (S901) in which a user sets an upper limit amount for payment, and a payment step (S302, S402) in which payment is made within the upper limit amount set in the upper limit amount setting step. This can improve the security of transactions and the reliability and stability of the system.

[0149] (Supplementary Note 7) The program according to Supplementary Note 6, wherein the settlement step (S303, S403) is a step of making a settlement without checking a specific user wallet if an upper limit amount is set in the upper limit amount setting step. Periodic billing aggregation allows multiple small transactions to be processed collectively. By reducing the number of transactions on the blockchain, the efficiency and economy of the entire system can be improved.

[0150] (Supplementary Note 8) The program according to Supplementary Note 1, which causes a server to execute, before a payment step, an authorization acquisition step (S302, S402) of receiving an authorization acquisition request based on a request related to payment, and a lock step (S303, S403) of locking the transfer of crypto assets in a user wallet in accordance with the authorization acquisition request received in the authorization acquisition step, wherein the payment step (S303, S403) is a step of making a payment after the lock step. This enables the transfer of crypto assets from the user wallet to the business operator's wallet.

[0151] (Supplementary Note 9) The program according to Supplementary Note 1 causes the server to execute a billing aggregation step (S502, S512) of aggregating billing amounts according to the user's usage history for one or more payments from the payment system at predetermined intervals, and a transfer step (S503, S513) of transferring crypto assets from the user wallet according to the billing amounts aggregated in the billing aggregation step. This improves the security and reliability of the system. It is also possible to detect fraudulent transactions, operational errors, etc.

[0152] (Supplementary Note 10) The program according to Supplementary Note 1, wherein the transfer step (S503, S513) is a step of transferring crypto assets from the user wallet to the business wallet of the business that provides the server. This enables a highly convenient two-dimensional code payment service using crypto assets to be realized.

[0153] (Supplementary Note 11) The information processing system includes a BIN sponsor, which is an information processing device provided by a party other than the business that provides the server, and the transfer step (S503, S513) is a step of transferring crypto assets from the user wallet in response to receiving approval from the BIN sponsor when transferring crypto assets from the user wallet, according to the program described in Supplementary Note 1. This makes it possible to realize a highly convenient two-dimensional code payment service using crypto assets.

[0154] 1 System, 10 Server, 101 Memory unit, 104 Control unit, 106 Input device, 108 Output device, 20 User terminal, 201 Memory unit, 204 Control unit, 206 Input device, 208 Output device, 30 Payment terminal, 301 Memory unit, 304 Control unit, 306 Input device, 308 Output device, 50 Blockchain, 501 Memory unit, 504 Control unit, 506 Input device, 508 Output device, 60 Third-party approval entity, 601 Memory unit, 604 Control unit, 606 Input device, 608 Output device, 70 Card system, 80 Two-dimensional code payment system, 701 Memory unit, 704 Control unit, 706 Input device, 708 Output device

Claims

1. An information processing system comprising a user terminal operable by a user and a server, wherein the server comprises: a storage means for storing crypto assets in a specified user wallet associated with the user; an allocation means for storing in the user wallet the address of a collateral contract associated with a specified payee as the transfer destination of the crypto assets; a payment means for making a payment to a payment system provided by a payment service provider in response to receiving a request for payment made by the user terminal; and a transfer means for executing a process to transfer the crypto assets corresponding to the payment from the user wallet to the specified payee as a transaction on a blockchain based on the collateral contract, without obtaining approval from the user for the withdrawal corresponding to the payment.

2. The information processing system according to claim 1, wherein the payment means is a means for making a card payment to the payment system provided by a card payment business operator in response to receiving a request for card payment made by the user terminal.

3. The information processing system according to claim 1, wherein the payment means is a means for making a two-dimensional code payment to the payment system provided by a two-dimensional code payment business operator in response to receiving a request for two-dimensional code payment made by the user terminal.

4. The information processing system of claim 1, wherein the information processing system includes a third-party approval entity which is an information processing device provided by a third party other than the operator that provides the server, and the transfer means is a means for transferring crypto assets from the user wallet in response to receiving approval from the third-party approval entity when transferring crypto assets from the user wallet.

5. The information processing system of claim 4, wherein the third-party approval entity queries the payment system for the amount used for payment by the payment means, and outputs information indicating approval if the query result matches the cryptocurrency to be transferred from the user wallet, and does not output information indicating approval if the query result does not match.

6. The information processing system according to claim 1, wherein the server comprises: an upper limit setting means for setting an upper limit for the payment from the user; and the payment means is a means for making a payment within the upper limit set by the upper limit setting means.

7. The information processing system according to claim 6, wherein the settlement means is a means for making a settlement without checking the specified user wallet when an upper limit amount has been set by the upper limit amount setting means.

8. The information processing system of claim 1, wherein the server comprises: an authorization acquisition means, before the payment means, that receives an authorization acquisition request based on a request regarding the payment; and a locking means that locks the transfer of crypto assets in the user wallet in response to the authorization acquisition request received by the authorization acquisition means, and the payment means is a means for making the payment after the locking.

9. An information processing system as described in claim 1, wherein the server is provided with a billing aggregation means for aggregating billing amounts from the payment system according to the user's usage history for one or more payments at predetermined intervals, and the transfer means is a means for transferring crypto assets from the user wallet according to the billing amounts aggregated by the billing aggregation means.

10. The information processing system according to claim 1, wherein the transfer means is a means for transferring crypto assets from the user wallet to an operator wallet of an operator that provides the server.

11. The information processing system of claim 1, wherein the information processing system includes a BIN sponsor, which is an information processing device provided by a party other than the business providing the server, and the transfer means is a means for transferring crypto assets from the user wallet in response to receiving approval from the BIN sponsor when transferring crypto assets from the user wallet.

12. A method executed by an information processing system consisting of a user terminal operable by a user and a server, wherein the server executes the following steps: a storage step of storing crypto assets in a specified user wallet associated with the user; an allocation step of storing a collateral contract associated with a specified payee as the transfer destination of the crypto assets in association with the user wallet; a settlement step of making a payment to a payment system provided by a payment service provider in response to receiving a request for payment made by the user terminal; and a transfer step of executing a process to transfer crypto assets corresponding to the payment from the user wallet to the specified payee as a transaction on a blockchain based on the collateral contract, without obtaining approval from the user for the withdrawal corresponding to the payment.

13. A program used in an information processing system consisting of a user terminal operable by a user and a server, which causes the server to execute the following steps: a storage step of storing crypto assets in a specified user wallet associated with the user; an allocation step of storing in the user wallet the address of a collateral contract associated with a specified payee as the transfer destination of the crypto assets; a settlement step of making a payment to a payment system provided by a payment service provider in response to receiving a request for payment made by the user terminal; and a transfer step of executing a process to transfer crypto assets corresponding to the payment from the user wallet to the specified payee as a transaction on a blockchain based on the collateral contract, without obtaining approval from the user for the withdrawal corresponding to the payment.

Images