Information processing method, program, and information processing apparatus

Abstract

To provide an information processing method and the like capable of performing acquisition and conversion processing of accounting data from a plurality of blockchain networks.SOLUTION: An information processing method according to one aspect includes acquiring accounting data from a plurality of blockchain networks 3 configured based on different protocols, performing conversion processing on the acquired accounting data, and storing the converted accounting data in a storage unit. This makes it possible to acquire and convert the accounting data from a plurality of blockchain networks 3.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an information processing method, a program, and an information processing device. [Background technology]

[0002] In recent years, there has been active development of technologies related to accounting data using blockchain networks. For example, Patent Document 1 discloses an accounting data sharing system that includes a payment service provider terminal, a user terminal, and an expert terminal, all of which are connected to each other so that they can reference the blockchain network. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-047574 Summary of the Invention [Problem to be solved by the invention]

[0004] However, the invention of Patent Document 1 has the problem that it cannot acquire and convert accounting data from multiple blockchain networks.

[0005] One aspect is to provide an information processing method etc. that can acquire and convert accounting data from multiple blockchain networks. [Means for solving the problem]

[0006] An information processing method according to one aspect is characterized in that accounting data is acquired from multiple blockchain networks configured based on different protocols, a conversion process is performed on the acquired accounting data, and the converted accounting data is stored in a memory unit. [Effects of the Invention]

[0007] In one aspect, it will be possible to acquire and convert accounting data from multiple blockchain networks. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is an explanatory diagram showing an overview of an accounting data management system. [Figure 2] FIG. 2 is a block diagram illustrating an example of the configuration of a server. [Figure 3] FIG. 10 is an explanatory diagram showing an example of the record layout of a network DB and a wallet DB. [Figure 4] FIG. 2 is an explanatory diagram showing an example of the record layout of a balance log DB and a transaction log DB. [Figure 5] FIG. 2 is a block diagram illustrating an example of the configuration of a terminal. [Figure 6] FIG. 10 is an explanatory diagram illustrating a process for acquiring accounting data. [Figure 7] 10 is a flowchart showing the processing steps for registering a smart contract for a wallet. [Figure 8] 10 is a flowchart showing a processing procedure for obtaining a balance. [Figure 9] FIG. 10 is an explanatory diagram illustrating a process for calculating a remuneration within a predetermined period. [Figure 10] 10 is a flowchart showing a processing procedure for calculating a remuneration within a predetermined period. [Figure 11] FIG. 10 is a block diagram showing an example of the configuration of a server in the second embodiment. [Figure 12] FIG. 10 is an explanatory diagram showing an example of the record layout of an external smart computer DB and an accounting rule DB. [Figure 13] FIG. 10 is an explanatory diagram showing an example of a screen for adding a smart contract address to a second wallet. [Figure 14] FIG. 10 is an explanatory diagram showing an example of a smart contract registration screen of a second wallet. [Figure 15] FIG. 10 is an explanatory diagram showing an example of a screen displaying a list of multiple smart contracts. [Figure 16] FIG. 10 is an explanatory diagram illustrating an example of an editing screen for accounting rules. [Figure 17] FIG. 10 is an explanatory diagram showing an example of a certificate display screen. [Figure 18] 10 is a flowchart showing the processing steps for registering a smart contract in a second wallet. [Figure 19] 10 is a flowchart showing the processing steps for displaying a list of multiple smart contracts corresponding to a second wallet. [Figure 20] 10 is a flowchart showing the processing steps when adding the balance of a second wallet to the balance of a first wallet. [Figure 21] FIG. 11 is a block diagram showing an example of the configuration of a server in the third embodiment. [Figure 22] FIG. 10 is an explanatory diagram illustrating an example of a record layout of an API key DB. [Figure 23] FIG. 10 is an explanatory diagram showing an example of an API key creation screen. [Figure 24] 10 is a flowchart showing a processing procedure when an API key is issued. [Figure 25] FIG. 10 is a block diagram showing an example of the configuration of a server in the fourth embodiment. [Figure 26] FIG. 10 is an explanatory diagram illustrating an example of a record layout of a screenshot DB. [Figure 27] 10 is a flowchart showing a processing procedure for outputting a screenshot and a transaction. [Figure 28] FIG. 10 is an explanatory diagram showing an example of a screenshot. [Figure 29] FIG. 13 is an explanatory diagram showing an example of the record layout of a balance log DB and a transaction log DB in the fifth embodiment. [Figure 30] FIG. 10 is an explanatory diagram showing an example of outputting balances and transactions to a file. [Figure 31] FIG. 10 is an explanatory diagram showing an example of a balance sheet for each user. [Figure 32] FIG. 10 is an explanatory diagram showing an example of an income statement for each user. [Figure 33] 10 is a flowchart showing a processing procedure for outputting a balance sheet and an income statement. DETAILED DESCRIPTION OF THE INVENTION

[0009] The present invention will be described in detail below with reference to the drawings showing embodiments thereof.

[0010] (Embodiment 1) The first embodiment relates to a form in which accounting data is acquired from multiple blockchain networks and a conversion process is performed on the acquired accounting data.

[0011] 1 is an explanatory diagram showing an overview of an accounting data management system. The system of this embodiment includes an information processing device 1, an information processing terminal 2, and multiple blockchain networks 3, and each device transmits and receives information via a network N such as the Internet.

[0012] The information processing device 1 is an information processing device that processes, stores, and transmits / receives various types of information. The information processing device 1 is, for example, a server device or a personal computer. In the present embodiment, the information processing device 1 will be hereinafter referred to as a server 1 for the sake of simplicity.

[0013] The information processing terminal 2 is a terminal device that receives and displays accounting data. The information processing terminal 2 is an information processing device such as a personal computer terminal, tablet, smartphone, mobile phone, or wearable device such as a smart watch. For simplicity, the information processing terminal 2 will be referred to as terminal 2 below.

[0014] The blockchain network 3 is a distributed ledger technology or a distributed network. The blockchain network 3 is composed of multiple nodes 31 that execute consensus processing. Note that while FIG. 1 shows an example in which the blockchain network 3 is composed of five nodes 31, it may be composed of an appropriate number of nodes depending on the consensus algorithm or the number of network participants.

[0015] Each node 31 holds a copy of the blockchain data through the execution of the consensus process. The blockchain network 3 generates units of data called blocks at regular intervals and stores data by linking them together like a chain.

[0016] The blockchain network 3 is managed autonomously using a peer-to-peer network and a distributed timestamp server. Because it is stored in a chain, once data in a block is stored, it is difficult to retroactively change that data. The blockchain network 3 may be public, private, or consortium type. The unit of data may be individual transactions rather than blocks. Furthermore, data may be stored in a format other than a chain, such as a directed acyclic graph. For simplicity, the blockchain network 3 will be referred to as blockchain 3 below.

[0017] Currently, accounting data acquired from multiple blockchains 3 configured based on different protocols has different formats, requiring personnel to manually acquire accurate data and record evidence. This results in significant labor costs and increases the risk of errors during data acquisition. In this embodiment, accounting data is acquired from multiple blockchains 3 and a conversion process is performed on the acquired accounting data, thereby solving the above-mentioned problems.

[0018] The server 1 according to this embodiment acquires accounting data from multiple blockchains 3 configured based on different protocols. The server 1 performs a conversion process on the acquired accounting data and stores the converted accounting data in a storage unit.

[0019] 2 is a block diagram showing an example of the configuration of the server 1. The server 1 includes a control unit 11, a storage unit 12, a communication unit 13, a reading unit 14, and a large-capacity storage unit 15. Each component is connected by a bus B.

[0020] The control unit 11 includes an arithmetic processing device such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), a GPU (Graphics Processing Unit), an FPGA (Field Programmable Gate Array), a DSP (Digital Signal Processor), or a quantum processor. The control unit 11 reads and executes a control program 1P (program product) stored in the storage unit 12, thereby performing various information processing or control processing related to the server 1. The control program 1P described in this embodiment may be provided on a recording medium or may be distributed from an external computer.

[0021] It should be noted that the control program 1P can be deployed to run on a single computer, or on multiple computers located at one site, or distributed across multiple sites and interconnected by a communications network.

[0022] 2, the control unit 11 is described as a single processor, but it may be a multi-processor. The control unit 11 may execute various information processes or control processes by the same processor within the server 1, or may execute various processes by different processors within the server 1.

[0023] The storage unit 12 includes memory elements such as RAM (Random Access Memory) and ROM (Read Only Memory), and stores the control program 1P or data required for the control unit 11 to execute processing. The storage unit 12 also temporarily stores data required for the control unit 11 to execute arithmetic processing. The communication unit 13 is a communication module for performing communication-related processing, and transmits and receives information to and from the terminal 2 or the blockchain 3, etc. via the network N.

[0024] The reading unit 14 reads a portable storage medium 1a including a CD (Compact Disc)-ROM or a DVD (Digital Versatile Disc)-ROM. The control unit 11 may read the control program 1P from the portable storage medium 1a via the reading unit 14 and store it in the mass storage unit 15. Alternatively, the control unit 11 may download the control program 1P from another computer via a network N or the like and store it in the mass storage unit 15. Furthermore, the control unit 11 may read the control program 1P from the semiconductor memory 1b.

[0025] The mass storage unit 15 includes a recording medium such as a hard disk drive (HDD) or a solid state drive (SSD). The mass storage unit 15 includes a network database (DB) 151, a wallet DB 152, a balance log DB 153, and a transaction log DB 154.

[0026] The network DB 151 stores information about multiple blockchains 3. The wallet DB 152 stores information about smart contracts to which wallets are deployed. The balance log DB 153 stores balance log data. The transaction log DB 154 stores transaction log data.

[0027] In this embodiment, the storage unit 12 and the large-capacity storage unit 15 may be configured as an integrated storage device. Furthermore, the large-capacity storage unit 15 may be configured by a plurality of storage devices. Furthermore, the large-capacity storage unit 15 may be an external storage device connected to the server 1.

[0028] The server 1 may execute various information processing and control processing on a single computer, or may execute the processing in a distributed manner on multiple computers. The server 1 may also be realized by multiple virtual machines provided in a single server, or may be realized by using a cloud server.

[0029] FIG. 3 is an explanatory diagram showing an example of the record layout of the network DB 151 and the wallet DB 152. The network DB 151 includes a network ID column, a network name column, a token ID column, and a token name column. The network ID column stores the network ID of the blockchain 3 that is uniquely specified to identify each blockchain 3. The network name column stores the name of the blockchain 3. The token ID column stores the token ID that is a unique identifier of the token. The token name column stores the name of the token.

[0030] The wallet DB 152 includes a wallet ID column, a client ID column, a project ID column, a network ID column, a wallet address column, a name column, an address column, and a deployment date and time column. The wallet ID column stores a wallet ID that is uniquely specified to identify each wallet.

[0031] The client ID column stores a client ID for identifying a client (e.g., an individual or a company) that holds the wallet. The project ID column stores a project ID for identifying a project linked to the wallet. The network ID column stores a network ID for identifying the blockchain 3. The wallet address column stores a wallet address.

[0032] The name column stores the name of the wallet's smart contract. The address column stores the address of the wallet's smart contract. The deploy date column stores the date and time when the wallet's smart contract was deployed.

[0033] FIG. 4 is an explanatory diagram showing an example of the record layout of the balance log DB 153 and the transaction log DB 154. The balance log DB153 includes a balance ID column, a wallet ID column, a balance column, and a date and time column. The balance ID column stores a unique balance ID to identify the balance of each wallet. The wallet ID column stores a wallet ID to identify the wallet corresponding to the balance. The balance column stores the amount of tokens held by the wallet (token balance). The date and time column stores information on the date and time when the balance was obtained.

[0034] The transaction log DB 154 includes a transaction ID column, a block number column, a network ID column, a token ID column, a sender column, a destination column, a quantity column, a transaction type column, and a date and time column. The transaction ID column stores a unique transaction data ID to identify each transaction data. The block number column stores the block number of the block containing the transaction.

[0035] The network ID column stores a network ID for identifying the blockchain 3. The token ID column stores a token ID, which is a unique identifier for a token. The sender column stores the wallet ID of the sender that sends the token. Note that the sender column may also store the wallet address of the sender.

[0036] The destination column stores the wallet ID of the destination that will receive the tokens. The destination column may also store the wallet address of the destination. The quantity column stores the amount of tokens in the transaction. The transaction type column stores the type of transaction (international remittance, fee, etc.). The date and time column stores the date and time information when the transaction occurred.

[0037] The storage format of each DB described above is an example, and other storage formats may be used as long as the relationships between the data are maintained.

[0038] 5 is a block diagram showing an example of the configuration of the terminal 2. The terminal 2 includes a control unit 21, a storage unit 22, a communication unit 23, an input unit 24, and a display unit 25. Each component is connected by a bus B.

[0039] The control unit 21 includes an arithmetic processing unit such as a CPU or an MPU, and reads and executes a control program 2P (program product) stored in the storage unit 22 to perform various information processing and control processing related to the terminal 2. The control program 2P described in this embodiment may be provided on a recording medium or may be distributed from an external computer.

[0040] 5, the control unit 21 is described as a single processor, but it may be a multi-processor. The control unit 21 may execute various information processing or control processes by the same processor within the terminal 2, or may execute various information processing or control processes by different processors within the terminal 2.

[0041] The storage unit 22 includes memory elements such as RAM and ROM, and stores the control program 2P or data required for the control unit 21 to execute processing. The storage unit 22 also temporarily stores data required for the control unit 21 to execute arithmetic processing.

[0042] The communication unit 23 is a communication module for performing communication-related processing, and transmits and receives information to and from the server 1, etc. via the network N. The input unit 24 may be a keyboard, a mouse, or a touch panel integrated with the display unit 25. The display unit 25 is a liquid crystal display, an organic EL (electroluminescence) display, or the like, and displays various information according to instructions from the control unit 21.

[0043] Figure 6 is an explanatory diagram illustrating the process of acquiring accounting data. Accounting data includes balances, transaction amounts (e.g., token amounts), fees, etc. Note that Figure 6 illustrates an example of balances, but the same can be applied to other types of accounting data.

[0044] In this embodiment, the server 1 acquires balances as accounting data from multiple blockchains 3 configured based on different protocols at predetermined points in time through batch processing. The predetermined points in time may be designated times (e.g., 9:00, 12:00, 15:00, 18:00, and 21:00) at predetermined intervals (e.g., five times a day), or may be designated times (e.g., 23:59:59 every day).

[0045] Examples of the blockchain 3 include Numbai, Sepolia, Bitcoin (registered trademark), and Ethereum (registered trademark). Note that, although examples of the blockchain 3A, the blockchain 3B, and the blockchain 3C are described in FIG. 6, the number of the blockchains 3 is not particularly limited.

[0046] In order to automatically obtain balances through batch processing, it is necessary to register a smart contract for the wallet in advance to track balance changes, etc.

[0047] Specifically, the server 1 generates code (source code) of the smart contract (e.g., balanceContract1, balanceContract2, and balanceContract3) of the wallet to be registered. The code of the smart contract of the wallet may be manually created by the user.

[0048] The wallet smart contract code is code written in a smart contract language such as Solidity® or Vyper (derived from Python) to implement the wallet smart contract, including functionality such as transaction management, balance management (e.g., balance tracking), transaction history, security features, or event notifications.

[0049] The transaction management function is a function that manages the sending or trading of transactions, for example, using the deposit function, withdraw function, or transfer function. The balance management function is a function that tracks the balance of each address, for example, using the balances mapping. The transaction history function is a function that records the transaction history of each user, for example, using the transactions mapping.

[0050] A security function is, for example, a function that ensures that a particular function can only be called by the owner using the onlyOwner modifier. An event notification function is, for example, a function that notifies events such as transactions or balance changes using the Deposit, Withdrawal, or Transfer events.

[0051] The server 1 deploys the generated wallet smart contract code to multiple blockchains 3 configured based on different protocols. Specifically, the server 1 generates a transaction for deployment to each target blockchain 3. The transaction includes the wallet smart contract code, wallet address, signature, and the deployment destination (location) of the smart contract on the blockchain 3.

[0052] Server 1 sends the generated transaction to each blockchain 3. Each blockchain 3 receives the transaction sent from Server 1. Each blockchain 3 verifies the received transaction and adds it to a block. This deploys the wallet's smart contract code onto each blockchain 3.

[0053] When smart contract code is deployed, an ABI (Application Binary Interface) is automatically registered (generated). The ABI (blueprint data) of the deployed smart contract is the interface for communication between the smart contract and external applications. The ABI is an interface that compiles information required for calling smart contract functions, retrieving variables, or monitoring events.

[0054] Registering an ABI allows you to extract logic from smart contract code. Logic describes how a program operates. Smart contract logic can include conditional branching (If / Else), variable or state management, transaction processing, event firing, or error handling.

[0055] Information about the smart contract of the wallet deployed to each blockchain 3 is registered in the wallet DB 152 of the server 1. The information about the smart contract of the wallet includes the wallet ID, client ID, project ID, network ID, wallet address, smart contract name, smart contract address, deployment date and time, etc.

[0056] Specifically, each blockchain 3 transmits the name, address, and deployment date and time of the smart contract of the deployed wallet to the server 1. The server 1 receives the name, address, and deployment date and time of the smart contract of the wallet transmitted from each blockchain 3.

[0057] The server 1 assigns a wallet ID to the wallet. The server 1 associates the assigned wallet ID with the client ID of the client (e.g., an individual or a company) that owns the wallet, the project ID associated with the wallet, the network ID of the blockchain 3, the wallet address, the name and address of the received wallet smart contract, and the deployment date and time, and stores these as a single record in the wallet DB 152.

[0058] Then, based on the smart contract of the registered wallet, the server 1 obtains balances from the target multiple blockchains 3 (e.g., blockchain 3A, blockchain 3B, and blockchain 3C) at a predetermined time.

[0059] Specifically, based on the wallet ID, the server 1 obtains the address of the smart contract of the wallet deployed to each blockchain 3 from the wallet DB 152. Based on the obtained address of the smart contract of the wallet, the server 1 obtains the balance of the wallet from each blockchain 3 by calling a balance obtainment function (e.g., getBalance) for the smart contract of the wallet via the ABI generated when the code of the smart contract was deployed.

[0060] The server 1 performs a conversion process on the acquired balance. The conversion process includes, for example, a token unit conversion process, a currency conversion process, an exponential notation conversion process, or a precision adjustment process. The token unit conversion process is a process of converting the balance into token units. For example, if the balance is "377557249377700013333333333", the server 1 converts the balance into token units. For example, the balance after conversion is "377557249.377700013333333333 OSHI".

[0061] A currency conversion process is a process in which a balance is expressed in a particular currency and converted into another currency. For example, if the balance is expressed in US dollars, the server converts the balance expressed in US dollars into another currency, such as euros or pounds.

[0062] The exponential notation conversion process converts a balance expressed as a very large number into scientific exponential notation. For example, if the balance is greater than 1,000,000, Server 1 converts it into scientific exponential notation to simplify the balance representation.

[0063] The precision adjustment process adjusts the decimal point position. If the balance has a different number of decimal points, the decimal point position may be adjusted. For example, if the balance is displayed in a format such as 1.23456789, Server 1 reduces or increases the number of digits to improve the display.

[0064] The server 1 calculates the total post-conversion balance corresponding to each blockchain 3. The server 1 stores the calculated total post-conversion balance in the balance log DB 153. Specifically, the server 1 assigns a balance ID. The server 1 stores the wallet ID, the total post-conversion balance, and the acquisition date and time as one record in the balance log DB 153, in association with the assigned balance ID.

[0065] 7 is a flowchart showing the processing steps for registering a wallet smart contract. The control unit 11 of the server 1 generates the code of the smart contract of the wallet to be registered (step S101). The control unit 11 generates a transaction to be deployed to the target blockchain 3 (step S102). The transaction includes the code of the wallet smart contract, the wallet address, a signature, the deployment destination of the smart contract on the blockchain 3, etc.

[0066] The control unit 11 transmits the generated transaction to any one of the nodes 31 in the corresponding blockchain 3 via the communication unit 13 (step S103). The node 31 in the blockchain 3 receives the transaction transmitted from the server 1 (step S301). The node 31 verifies the received transaction (step S302) and adds it to a block (step S303).

[0067] The node 31 transmits the name, address, and deployment date and time of the deployed wallet smart contract to the server 1 (step S304). The control unit 11 of the server 1 receives the name, address, and deployment date and time of the wallet smart contract transmitted from the blockchain 3 via the communication unit 13 (step S104).

[0068] The control unit 11 of the server 1 stores (registers) information about the smart contract of the wallet deployed to the blockchain 3 in the wallet DB 152 of the mass storage unit 15 (step S105). Specifically, the control unit 11 assigns a wallet ID to the wallet. The control unit 11 associates the client ID, project ID, network ID of the blockchain 3, wallet address, name and address of the smart contract, and deployment date and time with the assigned wallet ID and stores them as one record in the wallet DB 152. The control unit 11 then terminates the process.

[0069] 8 is a flowchart showing the processing steps for obtaining a balance. The control unit 11 of the server 1 determines whether or not a predetermined time has arrived (for example, 23:59:59 every day) (step S111). If the predetermined time has not arrived (NO in step S111), the control unit 11 waits. If the predetermined time has arrived (YES in step S111), the control unit 11 obtains the address of the smart contract of the wallet deployed in each blockchain 3 from the wallet DB 152 of the mass storage unit 15 based on the wallet ID (step S112).

[0070] The control unit 11 sends a balance acquisition request to acquire the balance to any one of the nodes 31 of the corresponding blockchain 3 via the communication unit 13 (step S113). The balance acquisition request includes the wallet address, the address of the wallet's smart contract, and an instruction to call a balance acquisition function (e.g., getBalance) for the wallet's smart contract. The node 31 of the corresponding blockchain 3 receives the balance acquisition request sent from the server 1 (step S311).

[0071] Based on the received balance acquisition request, node 31 acquires the balance corresponding to the smart contract address of the wallet included in the balance acquisition request through the ABI generated when the smart contract code was deployed (step S312).Node 31 then transmits the acquired balance to server 1 (step S313).

[0072] The control unit 11 of the server 1 receives the balances transmitted from each blockchain 3 via the communication unit 13 (step S114). The control unit 11 performs a conversion process to convert the received balances into token units (step S115). The control unit 11 calculates the total of the converted balances corresponding to each blockchain 3 (step S116).

[0073] The control unit 11 stores the calculated total balance after conversion in the balance log DB 153 of the mass storage unit 15 (step S117). Specifically, the control unit 11 assigns a balance ID. The control unit 11 stores the wallet ID, the total balance after conversion, and the acquisition date and time as one record in the balance log DB 153, in association with the assigned balance ID. The control unit 11 then ends the process.

[0074] 9 is an explanatory diagram illustrating the process of calculating rewards within a predetermined period. The server 1 acquires transactions within a predetermined period (for example, the period between the current time and the time the balance was acquired the previous day, one hour, one day, one week, or one month) from multiple blockchains 3 (for example, blockchain 3A, blockchain 3B, and blockchain 3C).

[0075] Specifically, based on the wallet ID, the server 1 obtains the address of the smart contract of the wallet deployed to each blockchain 3 from the wallet DB 152. Based on the obtained address of the smart contract of the wallet, the server 1 obtains all transactions within a predetermined period from each blockchain 3 by calling a transaction obtainment function (e.g., transfer) for the smart contract of the wallet via the ABI generated when the code of the smart contract was deployed.

[0076] A transaction includes the block number, the date and time the transaction occurred, the transaction hash, the source wallet ID or wallet address, the destination wallet ID or wallet address, or the token ID, etc. The transaction hash is used to verify that the transaction is valid and immutable, and includes important information about the transaction, such as the wallet address, the amount sent, the date and time, the current status, or the type of transaction (e.g., international transfer or fee).

[0077] After obtaining all transactions within a predetermined period from each blockchain 3, the server 1 obtains the balance from each blockchain 3 based on the smart contract address of the wallet. Note that the balance obtaining process is the same as in Figure 6, so a description thereof will be omitted.

[0078] Server 1 determines the type of wallet corresponding to the balance. Wallet types include a first type and a second type. The first type is a type of wallet that generates rewards that do not involve transactions (for example, rewards from mining). For example, when rewards (block rewards and transaction fees) are paid to a node that has generated (mined) a new block, they are sent directly to a wallet of the first type.

[0079] The second type is a type of wallet in which reward acquisition including transactions occurs. Wallets of the second type correspond to wallets in which reward acquisition including transactions occurs and in which the wallet receives funds from or sends funds to other wallets.

[0080] For example, the server 1 determines the type of wallet corresponding to the balance based on the wallet transaction history stored on the blockchain 3. Specifically, if there is no transaction history for the wallet and the reward was sent directly to that wallet, the server 1 determines that the type of the wallet is the first type. Alternatively, if there is a transaction history for the wallet, the server 1 determines that the type of the wallet is the second type. The wallet type may be stored in advance in the wallet DB of the server 1.

[0081] When the server 1 determines that the wallet type is the first type, it calculates the reward for a predetermined period based on the difference in the balance and the fluctuation value due to all transactions within the predetermined period.

[0082] First, based on the balances obtained from each blockchain 3, the server 1 calculates, for example, the difference between the current balance and the balance at a predetermined point in time (for example, the time the balance was obtained the previous day). Next, the server 1 calculates the fluctuation value due to all transactions within a predetermined period. Specifically, the server 1 calculates the difference between the sender information (INPUT) and the recipient information (OUTPUT) contained in each transaction. The server 1 calculates the sum of the calculated differences for each transaction as the fluctuation value due to the transaction.

[0083] Then, the server 1 subtracts the calculated fluctuation value due to the transaction from the calculated balance difference value. The server 1 calculates the value after the subtraction as the reward for the predetermined period. The reward can be calculated using an average rate. Specifically, the server 1 obtains the average rate (moving average rate, total average rate, weighted average rate, etc.) at the time of block generation from, for example, an external information processing device or a platform provided by an exchange or the like. The server 1 calculates the reward for the predetermined period by multiplying the sum of the balance difference value and the fluctuation value due to the transaction by the obtained average rate.

[0084] Server 1 determines whether the difference between the calculated reward and the reward at a predetermined time (for example, the time the balance was obtained on the previous day) is equal to or greater than a predetermined threshold. If the difference between the calculated reward and the reward at the predetermined time is less than the predetermined threshold, Server 1 stores the transaction of receiving the reward as the closing price for that day in transaction log DB 154.

[0085] If the difference between the calculated reward and the reward at a predetermined time is equal to or greater than a predetermined threshold, the server 1 sends an alert notification including a failure to acquire the balance into the wallet to the terminal 2. The terminal 2 receives the alert notification sent from the server 1 and displays the received alert notification on the screen.

[0086] If the server 1 determines that the wallet type is the second type, it determines whether the balance difference value matches the fluctuation value due to all transactions within a predetermined period. If the balance difference value matches the fluctuation value, the server 1 stores the acquired transaction in the transaction log DB 154. If the balance difference value does not match the fluctuation value, the server 1 sends an alert notification to the terminal 2 indicating that balance acquisition for the wallet failed.

[0087] 10 is a flowchart showing the processing steps for calculating rewards within a predetermined period. Based on the wallet ID, the control unit 11 of the server 1 acquires the address of the smart contract of the wallet deployed in each blockchain 3 from the wallet DB 152 of the mass storage unit 15 (step S121).

[0088] Based on the address of the acquired wallet's smart contract, the control unit 11 calls a transaction acquisition function (e.g., transfer) for the wallet's smart contract via the ABI generated when the smart contract code was deployed, and acquires all transactions from each blockchain 3 within a predetermined period (e.g., the period between the current time and the time the balance was acquired on the previous day) via the communication unit 13 (step S122).

[0089] Based on the address of the acquired wallet's smart contract, the control unit 11 calls a balance acquisition function (e.g., getBalance) for the wallet's smart contract via the ABI generated when the smart contract code was deployed, thereby acquiring the balance of the wallet from each blockchain 3 via the communication unit 13 (step S123).

[0090] Control unit 11 calculates the difference between the current balance and the balance at a predetermined time (for example, the time when the balance was obtained on the previous day) (step S124). Specifically, control unit 11 obtains the balance at the predetermined time from balance log DB 153 in mass storage unit 15 based on the wallet ID. Control unit 11 calculates the difference between the obtained current balance and the balance at the predetermined time.

[0091] The control unit 11 calculates the fluctuation value due to all transactions within the predetermined period (step S125). Specifically, the control unit 11 calculates the difference between the sender information and the recipient information of each transaction. The control unit 11 calculates the sum of the calculated differences for each transaction as the fluctuation value due to the transaction.

[0092] The control unit 11 determines the type of wallet (first type or second type) corresponding to the balance based on the wallet transaction history stored on the blockchain 3 (step S126). Based on the determination result of the wallet type, the control unit 11 determines whether the type of the wallet is the first type (step S127). If the control unit 11 determines that the type of the wallet is the first type (YES in step S127), it calculates the reward for the predetermined period by subtracting the fluctuation value due to all transactions within the predetermined period from the balance difference value (step S128).

[0093] The control unit 11 determines whether the difference between the calculated reward and the reward at a predetermined time (for example, the time when the balance was obtained on the previous day) is equal to or greater than a predetermined threshold (step S129). If the difference between the calculated reward and the reward at the predetermined time is equal to or greater than the predetermined threshold (YES in step S129), the control unit 11 sends an alert notification to the terminal 2 via the communication unit 13, including a message indicating that the balance acquisition for the wallet has failed (step S130).

[0094] If the difference between the calculated reward and the reward at a predetermined time is less than a predetermined threshold (NO in step S129), the control unit 11 stores the transaction of receiving the reward as the closing price for that day in the transaction log DB154 of the mass storage unit 15 (step S131).

[0095] Specifically, the control unit 11 assigns a transaction ID to the transaction. The control unit 11 associates the assigned transaction ID with the block number, the network ID of the blockchain 3, the token ID, the sender, the destination, the calculated reward, the type of transaction, and the date and time of the transaction as one record in the transaction DB 154. The control unit 11 then ends the process.

[0096] If the control unit 11 determines that the wallet type is not the first type (NO in step S127), it determines whether the balance difference value matches the fluctuation value due to all transactions within a predetermined period (step S132).If the balance difference value and the fluctuation value do not match (NO in step S132), the control unit 11 proceeds to the processing of step S130.

[0097] If the balance difference value and the fluctuation value match (YES in step S132), the control unit 11 stores the acquired transaction in the transaction log DB 154 (step S133). Specifically, the control unit 11 assigns a transaction ID to the transaction. The control unit 11 stores the block number, blockchain 3 network ID, token ID, sender, recipient, remittance amount, transaction type, and date and time as one record in the transaction DB 154, in association with the assigned transaction ID. The control unit 11 then terminates the processing.

[0098] According to this embodiment, it is possible to perform conversion processing on accounting data of different formats obtained from multiple blockchain networks.

[0099] According to this embodiment, the converted accounting data is stored in a more consistent format, making it easier to analyze or process the accounting data.

[0100] According to this embodiment, when the wallet type is the first type, it is possible to calculate the reward within a predetermined period based on the difference in balance and the fluctuation value due to all transactions.

[0101] It becomes possible to obtain transactions or balances corresponding to the smart contracts of wallets deployed on each blockchain 3.

[0102] (Embodiment 2) The second embodiment relates to a form in which the balance of a second wallet different from the wallet (first wallet) in the first embodiment is obtained. Note that a description of the content that overlaps with the first embodiment will be omitted. The first wallet is, for example, a wallet managed by the company (first company) or organization that operates this accounting data management system. The second wallet is a wallet provided by an external company (second company) or organization.

[0103] FIG. 11 is a block diagram showing an example of the configuration of the server 1 in embodiment 2. Note that the same reference numerals are used to designate the same components as those in FIG. 2, and the description thereof will be omitted. The mass storage unit 15 includes an external smart contract DB 155 and an accounting rule DB 156. The external smart contract DB 155 stores information about multiple smart contracts corresponding to a second wallet provided by a second company. The accounting rule DB 156 stores accounting rules for smart contracts.

[0104] FIG. 12 is an explanatory diagram showing an example of the record layout of the external smart computer DB 155 and the accounting rule DB 156. As shown in FIG. The external smart contract DB 155 includes a smart contract ID column, a client ID column, a project ID column, a network ID column, a name column, an address column, a function name column, a parameter column, a data processing column, a type column, a difference sorting column, and a balance sorting column. The smart contract ID column stores a unique smart contract ID to identify the smart contract corresponding to each second wallet.

[0105] The client ID column stores a client ID for identifying a client (e.g., a company) that holds the second wallet. The project ID column stores a project ID for identifying a project linked to the second wallet. The network ID column stores a network ID for identifying the blockchain 3. The name column stores the name of the smart contract. The address column stores the address of the smart contract.

[0106] The function name column stores the name of the function (method) or event registered in the smart contract. The parameter column stores the parameters of the function or event. The data processing column stores the processing for the return value of the function. Details of data processing for the return value will be described later. The type column stores the type of smart contract. Smart contract types include status, progress information tracking, error processing, etc.

[0107] The differential sorting column stores differentials related to compensation or position valuation fluctuations, etc. A differential refers to a change (e.g., a change from a previous value) that occurred over a specified period or under a specific circumstance. The balance sorting column stores differentials related to valuation trends or LP (Liquidity Provider) token price fluctuations, etc.

[0108] The accounting rule DB 156 includes a smart contract ID column, a token rate column, a legal tender information column, a balance column, and a transaction column. The smart contract ID column stores a smart contract ID for identifying a smart contract.

[0109] The token rate column includes a fiat currency column, a source column, an allocation rule column, and an exception handling column. The base fiat column stores the base fiat currency of the specified exchange or platform. The source column stores the provider (e.g., website or application) that provides information on the virtual currency market. An example of the source is CoinMarketCap (registered trademark).

[0110] The allocation rule column stores a specified token rate. The token rate includes an OHLC (Open, High, Low, Close) rate or a last-minute rate. The OHLC rate includes the opening price (Open), the highest price (High), the lowest price (Low), and the closing price (Close), and is a rate that indicates the price trend within a specific period (e.g., one day, one hour, or five minutes). The last-minute rate is a rate that indicates the last recorded trading price. For example, the last-minute rate (every five minutes) is a rate that indicates the last trading price recorded in the last five minutes.

[0111] The exception handling column stores exception handling information such as stocks that cannot be acquired (for example, "acquisition price is 0 SGD / valuation amount is always 1 SGD") or stocks that can be acquired but do not have liquidity.

[0112] The legal tender information column includes a legal tender column, an acquisition source column, and an allocation rule column. The legal tender column stores a specified legal tender. The acquisition source column stores a provider (e.g., a bank or a financial holding company) that provides information on the legal tender market. The allocation rule column stores rules or regulations for allocating legal tender for specific purposes.

[0113] Allocation rules are used to allocate fiat currency to specific departments or projects for purposes such as accounting or cash management. An allocation rule may be, for example, "collect at the end of the month (manual input)."

[0114] The balance column includes an acquisition frequency column, an acquisition target column, a recognition target column, and an LP token evaluation column. The acquisition frequency column stores the balance acquisition frequency (e.g., daily, monthly, or yearly). The acquisition target column stores the token used to acquire the balance.

[0115] The recognition target column stores targets for which balance changes without transactions are recorded as rewards when certain conditions are met. The certain conditions include, for example, "Staking Reward, Staking Commission, Staking Amount, Block Miner's base currency balance," "DeFi (decentralized finance) tokens whose balance is determined by stake," "Position reward and valuation in DeFi," or "Specific state of the Vesting Contract in token allocation."

[0116] The LP token valuation column stores a calculation method for valuing the value of tokens received when participating in a liquidity pool provided by a DeFi protocol. Valuation methods include, for example, "calculating based on the valuation of tokens remaining in the LP position," "predicting transaction fees," or "token price modeling."

[0117] The transaction column includes a network column, an acquisition frequency column, and an acquisition price column. The network column stores the network IDs or network names of multiple blockchains 3 from which transactions are acquired. The acquisition frequency column stores the transaction acquisition frequency (e.g., daily, monthly, or yearly). The acquisition price column stores cost calculation logic, including a moving average rate, a total average rate, or a weighted average rate.

[0118] Next, the process of registering a smart contract in a second wallet will be described with reference to Figures 13 and 14.

[0119] 13 is an explanatory diagram showing an example of a screen for adding a smart contract address of a second wallet. The screen includes a name entry field 11a, a network entry field 11b, an address entry field 11c, and a details button 11d.

[0120] The name reception field 11a is a field that receives input of the name of the smart contract of the second wallet. The network reception field 11b is a field that receives input or selection of the blockchain 3 corresponding to the smart contract to which the second wallet is deployed. The address reception field 11c is a field that receives input of the address of the smart contract of the second wallet. The details button 11d is a button that transitions to the registration screen (Figure 14) of the smart contract of the second wallet.

[0121] When the terminal 2 receives an input operation in the name reception field 11a, it acquires the name of the input smart contract. When the terminal 2 receives an input or selection operation in the network reception field 11b, it acquires the network ID of the input or selected blockchain 3. When the terminal 2 receives an input operation in the address reception field 11c, it acquires the address of the input smart contract.

[0122] When terminal 2 receives a touch (click) operation on the details button 11d, it transmits the acquired network ID and the name and address of the smart contract of the second wallet to server 1. Based on the network ID and the name and address of the smart contract of the second wallet transmitted from terminal 2, server 1 detects the smart contract of the second wallet through the ABI generated when the code of the smart contract was deployed.

[0123] The server 1 transmits the network ID, the name and address of the detected smart contract of the second wallet, and a function list corresponding to the smart contract to the terminal 2. The terminal 2 transfers the network ID, the name, address, and function list of the smart contract of the second wallet transmitted from the server 1 to the registration screen (Fig. 14) of the smart contract of the second wallet, and transitions to the registration screen.

[0124] 14 is an explanatory diagram showing an example of a smart contract registration screen for the second wallet. The screen includes a smart contract information display field 12a, an ABI selection button 12b, an upload button 12c, a function reception field 12d, a parameter reception field 12e, a data processing reception field 12f, a difference sorting selection field 12g, a balance sorting reception field 12h, a project selection field 12i, and a registration button 12j.

[0125] The smart contract information display field 12a is a display field that displays information about the smart contract of the second wallet (network ID or network name, smart contract name and address, etc.). The ABI selection button 12b is a button that accepts the selection of an ABI file. The upload button 12c is a button that uploads the selected ABI file.

[0126] The function reception field 12d is a field that receives the selection of one or more functions to be used when obtaining the balance. Functions include, for example, name(string), getBalance(uint256), maxSupply(uint256), unitPrice, balanceOf(address), ownerToTokens(address), and withdrawable. Note that while FIG. 13 illustrates an example of a function, it is not limited to this and may also be an event, or both a function and an event.

[0127] The parameter reception field 12e is a field for receiving input of parameters (arguments) of the selected function. For example, the parameter of the ownerToTokens function is the address of the smart contract of the second wallet.

[0128] The data processing reception field 12f is a field for receiving processing for the return value of a function to be stored in the database. The processing for the return value of a function may be, for example, a conversion process such as converting from a balance to a token unit. The source code received in the data processing reception field 12f describes the processing for processing the return value of a specified function and storing the processed return value in the database.

[0129] The difference sorting selection field 12g is a field that accepts the selection of the sorting of the difference, including the reward or the position price fluctuation. The balance sorting reception field 12h is a field that accepts the selection of the sorting of the balance, including the trend of the valuation amount or the LP token price fluctuation. The project selection field 12i is a field that accepts the selection of the project linked to the second wallet. The registration button 12j is a button that registers the smart contract of the second wallet.

[0130] Terminal 2 displays the network ID, name and address of the smart contract of the second wallet, which are received from the smart contract address addition screen (Fig. 13), in the smart contract information display field 12a. Terminal 2 displays the function list, which is received from the smart contract address addition screen, in the function reception field 12d. If the function list cannot be obtained from the smart contract address of the second wallet, the function list can be obtained manually by uploading an ABI file.

[0131] Specifically, when the terminal 2 receives a touch operation on the ABI selection button 12b, it receives the selection of the target ABI file from the storage unit 22 or a portable storage medium such as a USB (Universal Serial Bus) memory or an SD card. When the terminal 2 receives a touch selection on the upload button 12c, it reads out a function list from the selected ABI file. The terminal 2 displays the read function list in the function reception field 12d.

[0132] When the terminal 2 receives a selection operation in the function reception field 12d, it acquires the selected single or multiple functions. When the terminal 2 receives an input operation in the parameter reception field 12e, it acquires the input parameters. When the terminal 2 receives an input operation in the data processing reception field 12f, it acquires the processing for the return value of the input function.

[0133] When the terminal 2 receives a selection operation in the difference classification selection field 12g, it acquires the classification of the selected difference. When the terminal 2 receives a selection operation in the balance classification reception field 12h, it acquires the classification of the selected balance. When the terminal 2 receives a selection operation in the project selection field 12i, it acquires the project ID of the selected project.

[0134] When the terminal 2 receives a touch operation of the registration button 12j (smart contract logic registration), it transmits the registration information of the smart contract in the second wallet to the server 1. The registration information includes the client ID, project ID, network ID, name and address of the smart contract, name of the function, parameters, processing for the return value of the function, type of smart contract (e.g., Status), and classification of the difference and balance.

[0135] The server 1 receives the registration information of the smart contract of the second wallet transmitted from the terminal 2. The server 1 assigns a smart contract ID to the received registration information. The server 1 stores (registers) the registration information of the smart contract of the second wallet in the external smart contract DB 155 in association with the assigned smart contract ID.

[0136] Next, we will explain the process of displaying a list of multiple smart contracts corresponding to the registered second wallet. Figure 15 is an explanatory diagram showing an example of a screen that displays a list of multiple smart contracts. This screen includes a list display field 13a and an edit button 13b. The list display field 13a is a field that displays a list of multiple smart contracts corresponding to registered second wallets. The edit button 13b is a button for transitioning to an editing screen (Figure 16) for the accounting rules for the target smart contract.

[0137] Based on the wallet ID of the second wallet, the server 1 acquires the client ID and project ID corresponding to the second wallet from the wallet DB 152. Based on the acquired client ID and project ID, the server 1 acquires registration information of multiple corresponding smart contracts from the external smart contract DB 155.

[0138] The smart contract registration information includes the smart contract ID, network name, smart contract name, function or event name, smart contract type (e.g., Status), difference classification, balance classification, etc. The server 1 transmits the acquired registration information of multiple smart contracts to the terminal 2.

[0139] Terminal 2 receives the registration information of the multiple smart contracts sent from server 1. Terminal 2 displays the received registration information of the multiple smart contracts in list display field 13a. As shown in the figure, list display field 13a displays multiple smart contracts corresponding to the second wallet (e.g., aArbUSDCn, QuickSwap, and Velodrome VotingEscrow).

[0140] In addition, for each smart contract, the network name, smart contract name, function or event name, smart contract type (e.g., Status), acquisition frequency (e.g., "daily"), difference classification (e.g., reward or position price fluctuation), and balance classification (e.g., valuation trend or LP token price fluctuation) are displayed in the list display field 13a. The acquisition frequency is initially set to, for example, "daily," and can be changed on the accounting rule editing screen (Fig. 16) described below.

[0141] When the terminal 2 receives a touch operation of the edit button 13b, it receives the selection of the smart contract to be edited. The terminal 2 passes the smart contract ID of the selected smart contract to the accounting rule editing screen (FIG. 16) and transitions to the accounting rule editing screen.

[0142] 16 is an explanatory diagram showing an example of an accounting rule editing screen. The screen includes a token rate editing field 14a, a token rate change reflect button 14b, a legal currency editing field 14c, a legal currency change reflect button 14d, a balance editing field 14e, a balance change reflect button 14f, a TX (transaction) editing field 14g, a TX change reflect button 14h, and a certificate printing button 14i.

[0143] The token rate edit field 14a is a field that accepts editing (setting) of accounting rules for token rates. The token rate change reflect button 14b is a button that updates the accounting rule DB 156 with the edited accounting rule for the token rate. The legal currency edit field 14c is a field that accepts editing of accounting rules for legal currencies. The legal currency change reflect button 14d is a button that updates the accounting rule DB 156 with the edited accounting rule for the legal currency.

[0144] The balance edit field 14e is a field that accepts editing of accounting rules for balances. The balance change reflect button 14f is a button that updates the accounting rules for the edited balance in the accounting rule DB 156. The TX edit field 14g is a field that accepts editing of accounting rules for transactions. The TX change reflect button 14h is a button that updates the accounting rules for the edited transaction in the accounting rule DB 156. The certificate print button 14i is a button that outputs a certificate that includes the accounting rules.

[0145] When the terminal 2 receives an edit operation for the token rate edit field 14a, it acquires the legal tender, the source of token acquisition, the allocation rule (e.g., "Latest rate (every 5 minutes)"), and the accounting rule for the token rate, including processing exceptions. Processing exceptions include, for example, stocks that cannot be acquired (e.g., "Acquisition price is 0 SGD / valuation amount is always 1 SGD"), stocks that can be acquired but do not have liquidity, etc.

[0146] When the terminal 2 receives a touch operation of the token rate change reflection button 14b, it transmits the accounting rule for the token rate received in the token rate edit field 14a to the server 1, in association with the smart contract ID of the smart contract. The server 1 updates (stores) the accounting rule for the token rate in the accounting rule DB 156, in association with the smart contract ID transmitted from the terminal 2.

[0147] When the terminal 2 receives an editing operation for the legal currency editing field 14c, it acquires the legal currency, the source of the legal currency, and accounting rules for the legal currency including allocation rules (for example, "acquired at the end of the month (manual input)").

[0148] When the terminal 2 receives a touch operation of the legal currency change reflection button 14d, it transmits the accounting rules for the legal currency received in the legal currency edit field 14c in association with the smart contract smart contract ID to the server 1. The server 1 updates the accounting rules for the legal currency in the accounting rule DB 156 in association with the smart contract ID transmitted from the terminal 2.

[0149] When the terminal 2 receives an edit operation for the balance edit field 14e, it acquires the accounting rules for the balance, including the balance acquisition frequency (e.g., daily acquisition), acquisition target (target token), transaction recognition target, and LP token valuation (e.g., "calculated based on the valuation amount of tokens remaining in the LP position"). Transaction recognition targets include, for example, "Staking Reward, Staking Commission, Staking Amount, Block Miner's base currency balance," or "DeFi tokens whose balance is determined by equity."

[0150] When the terminal 2 receives a touch operation of the balance change reflection button 14f, it transmits the accounting rule for the balance received in the balance edit field 14e to the server 1 in association with the smart contract smart contract ID. The server 1 updates the accounting rule for the balance in the accounting rule DB 156 in association with the smart contract ID transmitted from the terminal 2.

[0151] When the terminal 2 receives an editing operation in the TX editing field 14g, it acquires accounting rules for the transaction, including the target single or multiple networks (chains), the transaction acquisition frequency (e.g., "daily at midnight"), and the acquisition price (e.g., "moving average rate").

[0152] When the terminal 2 receives a touch operation of the balance change reflection button 14f, it transmits the accounting rules for the transaction received in the TX edit field 14g to the server 1 in association with the smart contract ID of the smart contract. The server 1 updates the accounting rules for the transaction in the accounting rule DB 156 in association with the smart contract ID transmitted from the terminal 2.

[0153] When the terminal 2 receives a touch operation of the certificate print button 14i, it outputs a certificate including the accounting rules, including the token rate, legal tender, balance, and transaction, for example, to an auditing firm, etc. The output format of the certificate may be, for example, a certificate display screen (FIG. 17) on which the certificate can be printed, or a file such as a PDF (Portable Document Format).

[0154] 16 illustrates an example of accounting rules including token rates, fiat currencies, balances, and transactions, but is not limited to these. For example, accounting rules may include fee application rules for applying fees to specific transactions, or automatic transfer rules for automatically transferring a certain amount of tokens to another wallet address when certain conditions are met.

[0155] The process of editing accounting rules for the smart contract of the second wallet described in Figure 16 can be similarly applied to the smart contract of the first wallet. That is, the accounting rules for the smart contract of the first wallet can be edited and modified or updated as necessary. This allows for flexibility and appropriate accounting processing in the smart contracts of both the first wallet and the second wallet.

[0156] 17 is an explanatory diagram showing an example of the certificate display screen. The screen includes a smart contract information display field 15a, an accounting rule display field 15b, a print button 15c, and a download button 15d.

[0157] The smart contract information display field 15a is a display field that displays information about the smart contract for which accounting rules are set. The accounting rule display field 15b is a display field that displays the accounting rules set for the smart contract. The print button 15c is a button for printing the certificate. The download button 15d is a button for downloading the certificate.

[0158] When the terminal 2 receives a touch operation of the certificate print button 14i on the accounting rule editing screen (FIG. 16), it transfers to the screen information of the smart contract for which the accounting rules are to be set, the accounting rules for the token rate accepted in the token rate editing field 14a, the accounting rules for the legal currency accepted in the legal currency editing field 14c, the accounting rules for the balance accepted in the balance editing field 14e, and the accounting rules for the transaction accepted in the TX editing field 14g, and transitions to the screen. The smart contract information includes the name of the network, the name of the smart contract, or the name of the function corresponding to the smart contract, etc.

[0159] Terminal 2 receives the smart contract information, accounting rules for token rates, accounting rules for legal tender, accounting rules for balances, and accounting rules for transactions passed from the accounting rule editing screen. Terminal 2 displays the received smart contract information in the smart contract information display field 15a. Terminal 2 displays the received accounting rules for token rates, accounting rules for legal tender, accounting rules for balances, and accounting rules for transactions in the accounting rule display field 15b.

[0160] When the terminal 2 receives a touch operation of the print button 15c, it outputs the certificate display screen to a printing device, an online printing system, etc. When the terminal 2 receives a touch operation of the download button 15d, it outputs the certificate display screen in a predetermined file format (e.g., PDF).

[0161] 18 is a flowchart showing the processing steps for registering a smart contract for a second wallet. The control unit 11 of the server 1 acquires, via the communication unit 13, from the terminal 2, the network ID of the blockchain 3 corresponding to the smart contract to which the second wallet is deployed, and the name and address of the smart contract for the second wallet (step S141).

[0162] Based on the acquired network ID, the control unit 11 generates a transaction for acquiring a function list corresponding to the smart contract of the second wallet from the corresponding blockchain 3 (step S142). Note that this is not limited to functions, and can be applied to events, or both functions and events. The transaction includes the network ID, wallet address, smart contract name and address, etc.

[0163] The control unit 11 transmits the generated transaction to one of the nodes 31 in the blockchain 3 via the communication unit 13 (step S143). The node 31 in the blockchain 3 receives the transaction transmitted from the server 1 (step S341). Based on the received transaction, the node 31 obtains a function list from the address of the smart contract via the ABI generated when the code of the smart contract in the second wallet was deployed (step S342).

[0164] The node 31 transmits the acquired function list to the server 1 (step S343). The control unit 11 of the server 1 receives the function list transmitted from the blockchain 3 via the communication unit 13 (step S144). The control unit 11 transmits the received function list to the terminal 2 via the communication unit 13 (step S145).

[0165] The control unit 11 acquires registration information from the terminal 2 via the communication unit 13, including the client ID, project ID, network ID, name and address of the smart contract, the selected single or multiple functions, function parameters, processing for the function return value, type of smart contract, difference sorting or balance sorting, etc. (step S146).

[0166] The control unit 11 stores the acquired registration information in the external smart computer DB 155 of the mass storage unit 15 (step S147). Specifically, the control unit 11 assigns a smart computer ID to the acquired registration information. The control unit 11 associates the client ID, project ID, network ID, smart contract name, smart contract address, function name, function parameters, processing for the function return value (data processing), smart contract type, difference classification, and balance classification as one record in the external smart computer DB 155 in association with the assigned smart computer ID. The control unit 11 then ends the processing.

[0167] 19 is a flowchart showing the processing steps for displaying a list of multiple smart contracts corresponding to a second wallet. Based on the wallet ID of the second wallet, the control unit 11 of the server 1 acquires the client ID and project ID corresponding to the second wallet from the wallet DB 152 of the mass storage unit 15 (step S151).

[0168] Based on the acquired client ID and project ID, the control unit 11 acquires registration information for the corresponding multiple smart contracts from the external smart contract DB 155 of the mass storage unit 15 (step S152). The registration information for the smart contract includes the smart contract ID, network name, smart contract name, function, smart contract type, difference classification or balance classification, etc.

[0169] The control unit 11 transmits the acquired registration information of the multiple smart contracts to the terminal 2 via the communication unit 13 (step S153). The control unit 21 of the terminal 2 receives the registration information of the multiple smart contracts transmitted from the server 1 via the communication unit 23 (step S251). The control unit 21 displays the received registration information of the multiple smart contracts on the display unit 25 (step S252).

[0170] The control unit 21 receives a selection of a smart contract to be edited from among a plurality of smart contracts via the input unit 24 (step S253). The control unit 21 receives an edit of the accounting rules (balance acquisition frequency, cost calculation logic, token rate acquisition source information, etc.) for the selected smart contract via the input unit 24 (step S254).

[0171] The control unit 21 associates the received accounting rules with the smart contract's smart contract ID and transmits them to the server 1 via the communication unit 23 (step S255). The control unit 11 of the server 1 receives the smart contract ID and accounting rules transmitted from the terminal 2 via the communication unit 13 (step S154). The control unit 11 updates the received accounting rules in the accounting rule DB 156 of the mass storage unit 15, associating them with the received smart contract ID (step S155).

[0172] Specifically, the control unit 11 associates with the smart contract ID and updates the accounting rules for token rates (legal currency, token acquisition source, allocation rules, processing exceptions, etc.), accounting rules for legal currency (legal currency, legal currency acquisition source and allocation rules, etc.), accounting rules for balances (acquisition frequency, acquisition target, transaction recognition target and LP token evaluation, etc.), and accounting rules for transactions (network, acquisition frequency, acquisition price, etc.) in the accounting rule DB 156. The control unit 11 ends the processing.

[0173] The control unit 21 of the terminal 2 receives an output request to output a certificate including accounting rules via the input unit 24 (step S256). In response to the received output request, the control unit 21 generates a certificate based on accounting rules including token rates, legal tender, balances, and transactions (step S257). The control unit 21 displays the generated certificate on the display unit 25 (step S258). The control unit 21 ends the processing.

[0174] 20 is a flowchart showing the processing steps when adding the balance of the second wallet to the balance of the first wallet. The control unit 11 of the server 1 determines whether or not a predetermined time point has arrived (for example, 23:59:59 every day) (step S161). If the predetermined time point has not arrived (NO in step S161), the control unit 11 waits.

[0175] When the predetermined time point has arrived (YES in step S161), the control unit 11 acquires the balance of the first wallet from multiple blockchains 3 based on the address of the smart contract of the first wallet (step S162). Note that the process of acquiring the balance of the first wallet (first balance) is the same as in Fig. 8, so its explanation will be omitted. The control unit 11 performs a conversion process to convert the acquired first balance into token units (step S163).

[0176] The control unit 11 obtains the balance of the second wallet (second balance) from the corresponding blockchain 3 based on the second wallet ID (step S164). Specifically, the control unit 11 obtains the address of the smart contract of the second wallet from the external smart contract DB 155 of the mass storage unit 15 based on the smart contract ID of the smart contract. The control unit 11 sends a balance obtainment request to obtain the balance of the second wallet to any one of the nodes 31 of the corresponding blockchain 3 via the communication unit 13. The balance obtainment request includes the address of the smart contract of the second wallet and an instruction to call a balance obtainment function (e.g., getBalance) for the smart contract of the second wallet.

[0177] The node 31 of the corresponding blockchain 3 receives the balance acquisition request sent from the server 1. Based on the received balance acquisition request, the node 31 acquires the balance corresponding to the smart contract address of the second wallet included in the balance acquisition request via the ABI generated when the smart contract code was deployed. The node 31 then transmits the acquired balance of the second wallet to the server 1.

[0178] The control unit 11 performs a conversion process to convert the acquired second balance into token units (step S165). The control unit 11 adds the acquired second balance to the first balance (step S166). The control unit 11 stores the added balance in the balance log DB 153 of the mass storage unit 15 (step S167).

[0179] Specifically, the control unit 11 assigns a balance ID. The control unit 11 stores the wallet ID of the first wallet, the added balance (the sum of the first balance and the second balance), and the acquisition date and time in association with the assigned balance ID in the balance log DB 153 of the mass storage unit 15. Note that both the wallet ID of the first wallet and the wallet ID of the second wallet may be stored in the balance log DB 153. The control unit 11 ends the process.

[0180] According to this embodiment, it is possible to obtain the total balance of the first wallet and the second wallet at a predetermined point in time.

[0181] According to this embodiment, it becomes possible to accept edits of accounting rules for smart contracts in the second wallet.

[0182] According to this embodiment, it is possible to output a certificate including accounting rules.

[0183] (Embodiment 3) The third embodiment relates to a form in which an interface authentication key for accessing target accounting data is issued. Note that a description of the content that overlaps with the first and second embodiments will be omitted. Note that, for the sake of brevity, the interface authentication key will be read as an API (Application Programming Interface) key hereinafter.

[0184] Fig. 21 is a block diagram showing an example of the configuration of the server 1 in embodiment 3. Note that the same reference numerals are used to denote the same parts as in Fig. 11, and the description thereof will be omitted. The mass storage unit 15 includes an API key DB 157. The API key DB 157 stores information related to API keys.

[0185] 22 is an explanatory diagram showing an example of a record layout of the API key DB 157. The API key DB 157 includes a key column, a name column, a client ID column, a project ID column, a database column, an IP address column, an authority column, and a creation date column.

[0186] The key column stores an API key for accessing the target accounting data. The name column stores the name of the API key. The client ID column stores a client ID for identifying the client. The project ID column stores a project ID for identifying the project.

[0187] The database column stores the name of the database for storing the target accounting data (e.g., balance or transaction) for which an API key is issued. The IP address column stores the IP addresses that can access the target accounting data. The permissions column stores access permissions to the accounting data. Access permissions include, for example, READ or WRITE. The creation date and time column stores the creation date and time of the API key.

[0188] An API key is authentication information for accessing accounting data provided by this system. An API key is issued for each client based on the target accounting data, the IP address that can access that accounting data, and the access permissions.

[0189] When Server 1 receives a connection request from an IP address specified by a client, it authenticates whether the client has legitimate authority in this system based on the API key issued to the client. If authentication is successful, Server 1 permits access to the accounting data, and if authentication fails, it denies access to the accounting data.

[0190] 23 is an explanatory diagram showing an example of an API key creation screen, which includes a key name entry field 16a, an IP address entry field 16b, an authority entry field 16c, and an API creation button 16d.

[0191] The key name acceptance field 16a is a field for accepting input of the name of the API key. The IP address acceptance field 16b is a field for accepting input of one or more IP addresses that can access the target accounting data. The authority acceptance field 16c is a field for accepting authority information including the project ID, the name of the DB for storing the target accounting data, and authority (e.g., READ or WRITE). The API creation button 16d is a button for issuing an API key.

[0192] When the terminal 2 receives an input operation in the key name reception field 16a, it acquires the name of the input API key. When the terminal 2 receives an input operation in the IP address reception field 16b, it acquires the input IP address. When the terminal 2 receives an input operation in the authority reception field 16c, it acquires the input or selected project ID, the name of the DB for storing the target accounting data, and the authority.

[0193] When the terminal 2 receives a touch operation on the API creation button 16d, it transmits the acquired API key name, IP address, and authority information (project ID, DB name, authority, etc.) in association with the client ID and project ID to the server 1. The server 1 receives the client ID, project ID, API key name, IP address, and authority information transmitted from the terminal 2.

[0194] Based on the name, IP address, and permission information of the received API key, the server 1 issues an API key for accessing a DB that stores the target accounting data. The server 1 associates the issued API key with the client ID and project ID and stores it in the API key DB 157. The server 1 transmits the issued API key to the terminal 2. The terminal 2 receives the API key transmitted from the server 1 and displays the received API key on its screen.

[0195] 24 is a flowchart showing the processing steps when issuing an API key. The control unit 21 of the terminal 2 accepts input (selection) of the API key name, IP address, and authority information via the input unit 24 (step S271). The authority information includes the project ID, the name of the DB for storing the target accounting data, authority, etc. The control unit 21 associates the accepted API key name, IP address, and authority information with the client ID and project ID and transmits them to the server 1 via the communication unit 23 (step S272).

[0196] The control unit 11 of the server 1 receives the client ID, project ID, API key name, IP address, and authority information sent from the terminal 2 via the communication unit 13 (step S171). Based on the received API key name, IP address, and authority information, the control unit 11 issues an API key for accessing the DB that stores the target accounting data (step S172).

[0197] The control unit 11 associates the issued API key with the client ID and project ID and stores the issued API key in the API key DB 157 of the mass storage unit 15 (step S173). Specifically, the control unit 11 stores the issued API key, the name of the API key, the client ID, the project ID, the name of the DB (for example, balance log), the IP address, the authority (READ or WRITE), and the creation date and time as one record in the API key DB 157.

[0198] The control unit 11 transmits the issued API key to the terminal 2 via the communication unit 13 (step S174). The control unit 21 of the terminal 2 receives the API key transmitted from the server 1 via the communication unit 23 (step S273). The control unit 21 displays the received API key on the display unit 25 (step S274). The control unit 21 ends the process.

[0199] Next, we will explain the process of outputting the target accounting data in a specified file format using the issued API key.

[0200] When the terminal 2 receives a request from a client to access accounting data, it sends the received access request to the server 1. The access request includes, for example, an API key and a private key. The server 1 receives the access request sent from the terminal 2. The server 1 performs authentication processing using the API key and private key included in the received access request.

[0201] If authentication is successful, the server 1 outputs the target accounting data (balance, transaction, etc.) corresponding to the API key to a file in a predetermined file format. The file format includes, for example, CSV (Comma-Separated Values), JSON (JavaScript Object Notation), XML (eXtensible Markup Language), or Excel (registered trademark) files. For example, if the accounting data is a balance, the output file includes a balance ID, a wallet ID corresponding to the balance, the balance (amount of tokens), or the date and time the balance was obtained.

[0202] According to this embodiment, by issuing an API key for accessing the target accounting data, it is possible to protect the data from unauthorized access or security breaches.

[0203] According to this embodiment, if authentication using the issued API key is successful, the target accounting data can be output in a specified file format.

[0204] (Embodiment 4) The fourth embodiment relates to an embodiment in which screenshots including transactions are acquired to verify accounting data. Note that a description of content that overlaps with the first to third embodiments will be omitted.

[0205] Figure 25 is a block diagram showing an example configuration of the server 1 in embodiment 4. Note that the same reference numerals are used to designate the same parts as in Figure 21, and the description thereof will be omitted. The mass storage unit 15 includes a screenshot DB 158. The screenshot DB 158 stores screenshots, including transactions for verifying accounting data.

[0206] 26 is an explanatory diagram showing an example of a record layout of the screenshot DB 158. The screenshot DB 158 includes a screenshot ID column, a client ID column, a project ID column, a screenshot column, and an acquisition date and time column.

[0207] The screenshot ID column stores a unique screenshot ID to identify screenshots for proving each accounting data. The client ID column stores a client ID for identifying a client. The project ID column stores a project ID for identifying a project. The screenshot column stores screenshots containing transactions. The capture date / time column stores the date and time when the screenshot was captured.

[0208] 27 is a flowchart showing the processing steps for outputting screenshots and transactions. The control unit 11 of the server 1 obtains transaction status display data for verifying accounting data from the blockchain 3 via the communication unit 13 (step S181). The status display data may be written in HTML format, for example. The HTML format data includes the transaction status (success or failure, etc.) of the transaction, the sender's address, the destination's address, the amount, the block number, and data indicating a deposit or withdrawal.

[0209] The control unit 11 acquires a screenshot including the transaction based on the acquired transaction status display data (step S182). The screenshot displays the transaction status, sender and destination addresses, remittance amount, block number, and data indicating deposit or withdrawal. The control unit 11 stores the acquired screenshot in the screenshot DB 158 of the mass storage unit 15 (step S183).

[0210] Specifically, the control unit 11 assigns a screenshot ID to the acquired screenshot, and stores the client ID, project ID, screenshot, and acquisition date and time in the screenshot DB 158 as one record in association with the assigned screenshot ID.

[0211] The control unit 11 outputs a list of transactions, including the type of blockchain 3, the type of token, the sender's address, the destination's address, and the amount, to a file in a predetermined file format (step S184). The file format includes, for example, CSV, JSON, XML, or Excel files. The control unit 11 transmits the acquired screenshot and a file including the list of transactions to the terminal 2 via the communication unit 13 (step S185).

[0212] The control unit 21 of the terminal 2 receives the screenshot and file transmitted from the server 1 via the communication unit 23 (step S281). The control unit 21 displays the received screenshot and file on the display unit 25 (step S282). The control unit 21 ends the process.

[0213] 28 is an explanatory diagram showing an example of a screenshot. The screenshot includes multiple transactions. Each transaction is displayed in the transaction display field 17a.

[0214] Note that Figure 28 illustrates an example in which the transaction type is Transfer, but it can also be applied to other types of transactions such as Approval, Token Minting, Token Swap, or Fee Payment.

[0215] As shown in the figure, each transaction display field 17a displays information indicating the success or failure of the transaction (e.g., "Transaction Success"), the transaction hash, the sending wallet address, the destination wallet address, the amount sent (amount of tokens), the transaction type (e.g., "Transfer"), the transaction type (e.g., TX Fee), the block number, the date and time the transaction occurred (e.g., "4 hours ago"), and the type of deposit / withdrawal (e.g., "IN" or "OUT").

[0216] According to this embodiment, it is possible to accumulate (store) screenshots including transactions to verify accounting data in the screenshot DB 158.

[0217] According to this embodiment, by sending a screenshot containing the transaction and a file containing a list of transactions to terminal 2, it is possible to see a visual representation of the transaction and to check multiple transactions at once.

[0218] (Embodiment 5) The fifth embodiment relates to a form in which a balance sheet and a profit and loss statement for a target year are issued (output) for each user. Note that a description of the contents that overlap with the first to fourth embodiments will be omitted.

[0219] 29 is an explanatory diagram showing an example of the record layout of the balance log DB 153 and the transaction log DB 154 in embodiment 5. Note that the same reference numerals are used to designate the same contents as in FIG. 4, and the description thereof will be omitted.

[0220] The balance log DB153 includes a token type column, a moving average unit price (moving average rate) column, a market value column, and a market value valuation column. The token type column stores the token type (token name or identifier, etc.) that is the subject of the balance. The moving average unit price column stores the moving average token price over a predetermined period (for example, 7 days or 30 days).

[0221] The current value column stores the current value (market price) of each token. The current value valuation column stores the total valuation based on the current value, which is calculated by multiplying the number of tokens held by the user by the current value. In other words, the total valuation is calculated by "number of tokens x current value."

[0222] The process of storing the balance in the balance log DB 153 is the same as in embodiment 1. Specifically, the server 1 obtains the address of the smart contract of the wallet deployed in each blockchain 3 from the wallet DB 152 based on the wallet ID. The server 1 sends a balance obtainment request to obtain the balance to one of the nodes 31 in the corresponding blockchain 3.

[0223] Based on the balance acquisition request sent from Server 1, Node 31 of the relevant blockchain 3 acquires the balance corresponding to the smart contract address of the wallet included in the balance acquisition request via the ABI generated when the smart contract code was deployed. Node 31 then sends the acquired balance to Server 1.

[0224] The server 1 receives the balances sent from each blockchain 3. The server 1 performs a conversion process to convert the received balances into token units. Note that the conversion process is the same as in the first embodiment, so a description thereof will be omitted. The server 1 calculates the sum of the converted balances corresponding to each blockchain 3.

[0225] The server 1 stores the calculated total balance after conversion in the balance log DB 153. Specifically, the server 1 assigns a balance ID. The server 1 stores the wallet ID, type of each token, total balance after conversion, acquisition date and time, moving average unit price, current price, and current price valuation amount (quantity of tokens × current price) in association with the assigned balance ID in the balance log DB 153 as one record.

[0226] The transaction log DB154 includes a token type column, a deposit / withdrawal column, a current value column, and a transfer price column. The token type column stores the type of token associated with each transaction. The deposit / withdrawal column stores information indicating whether the transaction is a deposit (IN) or a withdrawal (OUT). The current value column stores the current value of the token at the time each transaction was executed. The transfer price column stores the moving average price for a specified period when the transaction was executed.

[0227] The process of storing transactions in the transaction log DB 154 is the same as in embodiment 1. Specifically, the server 1 obtains the address of the smart contract of the wallet deployed in each blockchain 3 from the wallet DB 152 based on the wallet ID.

[0228] Based on the address of the acquired wallet's smart contract, the server 1 calls a transaction acquisition function (e.g., transfer) for the wallet's smart contract via the ABI generated when the smart contract code was deployed, thereby acquiring all transactions from each blockchain 3 within a predetermined period (e.g., the period between the current time and the time the balance was acquired on the previous day).

[0229] The server 1 stores the acquired transaction in the transaction log DB 154. Specifically, the server 1 assigns a transaction ID to the transaction. The server 1 stores the following as one record in the transaction DB 154, in association with the assigned transaction ID: the block number, the network ID of the blockchain 3, the token ID, the type of token, the deposit / withdrawal ("IN" or "OUT"), the sender, the destination, the quantity of tokens, the type of transaction, the date and time, the current price of the token at the time the transaction was executed, and the moving average price over a predetermined period.

[0230] The above-mentioned current price and moving average unit price may be obtained from accounting rules stored in the accounting rule DB 156 of the mass storage unit 15 or from an external information processing device.

[0231] Typically, the documents required to calculate the unrealized gain tax include a balance sheet and an income statement. A balance sheet is a financial statement that shows the user's financial status for a specified period (e.g., 2023), and is a table that shows assets, liabilities, and capital investments (net assets).

[0232] Assets are recorded as the amount after deducting the manager's fees, partner fees, realized profit tax, etc. from the total crypto assets held by the user. Liabilities are the amount of debts that the user must pay within a specified period, such as unpaid amounts to the user, unpaid expenses, deposits, suspense tax or fees, etc. Capital contributions are the amount after deducting the accumulated dividend amount from the total amount of received capital contributions, contribution deposits, accumulated profits and losses carried forward, and current profits and losses.

[0233] An income statement is a financial statement that shows the revenue, expenses, and profits and losses from the management of crypto assets for each user. Revenue is recorded as profits earned from the sale and management of crypto assets. Expenses are recorded as compensation to managers or partners, fees related to transactions, etc. Profit and loss is calculated by subtracting expenses from revenue to determine the profit (or loss) for each user.

[0234] In the third embodiment, the API key can be used to output the target accounting data (balance, transaction, etc.) corresponding to the API key to a file in a predetermined file format (for example, CSV).

[0235] FIG. 30 is an explanatory diagram showing an example of outputting balances and transactions to a file. When terminal 2 receives a request from a user (client) to access accounting data, it sends the received access request to server 1. The access request includes, for example, an API key and a private key. Server 1 receives the access request sent from terminal 2. Server 1 performs authentication processing using the API key and private key included in the received access request.

[0236] If the authentication is successful, the server 1 outputs the target accounting data (balance, transaction, etc.) corresponding to the API key to a file in a predetermined file format (for example, CSV, JSON, or XML, etc.).

[0237] 30A is an explanatory diagram showing an example of a balance file. When the accounting data is a balance, the server 1 obtains balance data for the target period from the balance log DB 153 based on the user's wallet ID. The server 1 outputs the obtained balance data to a CSV file. As shown in the figure, the output file includes the time of acquisition, wallet ID, token type, token balance (amount held), moving average price, current price, and current market value.

[0238] FIG. 30B is an explanatory diagram showing an example of a transaction file. When the accounting data is a transaction, the server 1 acquires transaction data for the target period from the transaction log DB 154 based on the user's wallet ID. The server 1 outputs the acquired transaction data to a CSV file. As shown in the figure, the output file includes the transaction type, deposit / withdrawal ("IN" or "OUT"), token type, token quantity, current price, and moving price (moving average price), etc.

[0239] Typically, a user manually compiles the necessary information from the CSV file and creates a balance sheet and an income statement. This requires organizing a huge amount of data, which takes time and effort, making it inefficient and increasing the risk of errors. In this embodiment, the necessary information can be automatically compiled from the CSV file, and a balance sheet and an income statement can be automatically created.

[0240] First, the process of generating a balance sheet will be explained. The server 1 acquires balance data from the balance file for a target period. The target period is the period for which balance data is acquired, and includes, for example, a month, a quarter, or a year. The balance data includes the time the balance was acquired, the type of token, the token balance, the moving average price, the market value, the market value valuation, etc.

[0241] Server 1 calculates the total crypto assets held by each user from the acquired balance data. The total crypto assets is the total value of all crypto assets (tokens) held by the user. Specifically, Server 1 aggregates the quantity (held amount) of all tokens, including different types of tokens (BTC, ETH, XRP, etc.), from the balance data based on the user's wallet ID. Server 1 calculates the valuation value of each token based on the aggregated quantity of each token and the current market value corresponding to that token. Server 1 calculates the total crypto assets as the sum of the calculated valuation values ​​of each token.

[0242] The server 1 acquires the manager's fees, the partner's fees, and the realized gain tax levied on the profits obtained from the sale of assets or investments. Specifically, with regard to the manager's fees, the server 1 acquires the fees to be paid to the manager from the storage unit 12 or the mass storage unit 15. The fees to be paid to the manager may be a fixed amount, or may be calculated based on pre-set contract terms, etc.

[0243] Regarding the reward to the partner, the server 1 obtains the reward to be paid to the partner from the memory unit 12 or the mass storage unit 15. The reward to be paid to the partner may be a fixed amount, or may be calculated based on the pre-set terms and conditions of the partnership.

[0244] Realized gain tax is usually levied on profits obtained through sales or investments. For example, Server 1 calculates the amount of profit obtained from the sale or investment of crypto assets. The amount of profit is calculated by deducting the acquisition price (cost) and related expenses from the revenue from the sale or investment of crypto assets. Server 1 calculates the amount of realized gain tax by multiplying the calculated amount of profit by the applicable tax rate (e.g., income tax).

[0245] Server 1 obtains the asset pool amount obtained by deducting the reward for the acquired manager, the reward for the partner, and the realized profit tax from the calculated total crypto assets for each user. Server 1 calculates the asset pool ratio for each user based on the calculated total crypto assets and asset pool. In other words, the asset pool ratio is calculated as "asset pool / total crypto assets x 100%".

[0246] Based on the calculated asset pool ratio for each user, the server 1 calculates the ratio of crypto assets held by each user to the total crypto assets as equity data. Based on the calculated equity data and the moving average rate included in the accounting rules stored in the accounting rule DB 156, the server 1 calculates the crypto assets held by each user for each predetermined period (e.g., month) in the target year (e.g., 2023).

[0247] The server 1 generates a balance sheet for the relevant year for each user based on the calculated crypto asset holdings for each predetermined period. The server 1 transmits the generated balance sheet to the terminal 2 of the relevant user.

[0248] FIG. 31 is an explanatory diagram showing an example of a balance sheet for each user. The balance sheet is a comparison table showing the balance status of crypto assets (investments, surplus funds, and other assets) held by each user. As shown in the figure, the balance sheet shows the amount of each item for a predetermined period (e.g., month) over a predetermined period (e.g., January to December 2023). Items include assets, liabilities, and capital investments.

[0249] The total investment amount is calculated each month from the crypto assets (investments, surplus funds, and other assets) held by the user, taking into account the allowance for doubtful accounts. The allowance for doubtful accounts is an amount set aside to estimate the amount that may not be collected in the future for the accounts receivable or loans held by the user. The allowance for doubtful accounts may be stored in advance in the memory unit 12 or the mass storage unit 15.

[0250] Surplus includes cash and deposits (excluding capital contribution deposits), capital contribution deposits, etc. Other assets include advances, prepaid expenses, advance taxes, advance consumption taxes, and other accrued or unexpensed items.

[0251] Liabilities indicate the amount that the user has an obligation to pay in the future, and include liabilities to be paid within a specified period, such as accounts payable, accrued expenses, deposits, suspense tax received, and other (e.g., short-term liabilities). Capital investment is the amount remaining after deducting the accumulated dividend amount from the total amount of received capital investment, investment deposits, accumulated profit and loss carried forward, and current profit and loss.

[0252] When the surplus funds, debts, and capital contributions are stored in the mass storage unit 15 of the server 1, the server 1 acquires the surplus funds, debts, and capital contributions from the mass storage unit 15. The server 1 may also acquire the surplus funds, debts, and capital contributions from a system or platform that provides the surplus funds, debts, and capital contributions.

[0253] The server 1 generates a balance sheet including the total investment amount, total surplus funds, total other assets, total current liabilities, capital received, accumulated profit and loss carried forward, current profit and loss, and accumulated dividends.

[0254] Next, the process of generating a profit and loss statement will be explained. The server 1 acquires transaction data from the transaction file for a target period. The target period is the period for which transaction data is acquired, and includes, for example, a month, a quarter, or a year. The transaction data includes the transaction type (e.g., transaction fee or reward), deposits and withdrawals ("IN" or "OUT"), token type, token quantity, current price, and moving price (moving average current price), etc.

[0255] Similar to the process described above, the server 1 calculates the proportion of crypto assets held by each user relative to the total crypto assets as share data. Based on the calculated share data and a specified fee, the server 1 calculates the profit and loss for each specified period in the target year for each user. Based on the calculated profit and loss for each specified period, the server 1 generates a profit and loss statement for the target year for each user. The server 1 transmits the generated profit and loss statement to the terminal 2 of the corresponding user.

[0256] 32 is an explanatory diagram showing an example of an income statement for each user. As shown in the figure, the income statement shows the amount of profit or loss for each item for a predetermined period (e.g., month) over a predetermined period (e.g., January to December 2023). Items include investment profit or loss, other profit or loss, unrealized profit or loss adjustment, and current profit or loss.

[0257] Investment profit and loss is calculated by aggregating transaction fees or commission-related items to determine the final investment-related profit and loss. Other profit and loss is calculated by aggregating various expenses such as partnership management fees, partnership expenses, legal fees, paid fees, taxes and public charges, and remittance fees. Unrealized profit and loss adjustments include unrealized profit and loss at the beginning and end of the period. Current profit and loss is the final profit and loss for each specified period.

[0258] Server 1 acquires transaction data from the transaction file. The transaction data includes the transaction type, deposits and withdrawals, token type, token quantity, current value, and transfer value. Server 1 calculates investment profit and loss based on the acquired transaction data. Investment profit and loss includes investment income, investment costs, and fees paid. Investment costs include investment sales costs, fees paid, stock sales commissions, and investment amortization losses.

[0259] Profit and loss are calculated by subtracting predetermined fees or expenses (e.g., partnership management fees or remittance fees, etc.) from the income (e.g., fees or sales profits) related to the user's equity data (assets held). For example, the server 1 records a predetermined fee (e.g., stock sales commission) that has been withdrawn ("OUT") as "investment cost of sales" or "investment amortization loss." Alternatively, the server 1 classifies received dividends and other payments ("IN") as "other income" and records them as income.

[0260] The server 1 calculates the final profit and loss (current profit and loss) by adding up the amounts of each item for each predetermined period (for example, month). The server 1 generates a profit and loss statement for each month during the predetermined period, including investment profit and loss, other profit and loss, unrealized profit and loss adjustment amount, and current profit and loss.

[0261] 33 is a flowchart showing the processing steps for outputting a balance sheet and a profit and loss statement. The control unit 11 of the server 1 acquires balance data and transaction data from a CSV file as accounting data for a target year (for example, 2023) (step S191). Note that the data is not limited to the target year, and may be a target month or quarter, etc.

[0262] The balance data includes the time of balance acquisition, the type of token, the token balance, the moving average price, the current price, the current price valuation, etc. The transaction data includes the type of transaction, deposits and withdrawals, the type of token, the token quantity, the current price, the moving current price, etc.

[0263] The control unit 11 calculates the total crypto assets (total amount of crypto assets) held by each user from the acquired balance data based on the user's wallet ID (step S192). The control unit 11 calculates the asset pool (step S193). Specifically, the control unit 11 obtains the rewards to the manager, the rewards to the partner, and the realized profit tax levied on profits obtained from the sale or investment of assets. The control unit 11 obtains the amount obtained by deducting the acquired rewards to the manager, the rewards to the partner, and the realized profit tax from the calculated total crypto assets for each user as the asset pool.

[0264] Based on the calculated total crypto assets and asset pool, the control unit 11 calculates the asset pool ratio for each user using the formula "asset pool / total crypto assets x 100%" (step S194). Based on the calculated asset pool ratio for each user, the control unit 11 calculates the ratio of crypto assets held by each user to the total crypto assets as equity data (step S195).

[0265] The control unit 11 calculates the crypto asset holdings for each user for each predetermined period (e.g., month) in the target year (step S196) based on the calculated ownership data and the moving average rate included in the accounting rules stored in the accounting rule DB 156. The control unit 11 generates a balance sheet for the target year for each user based on the calculated crypto asset holdings for each predetermined period (step S197).

[0266] The control unit 11 acquires a predetermined fee from the memory unit 12 or the mass storage unit 15 (step S198). The fee includes a stock selling fee or a remittance fee. The control unit 11 calculates the profit and loss for each predetermined period in the target year for each user based on the calculated equity data and the acquired predetermined fee (step S199). The control unit 11 generates a profit and loss statement for the target year for each user based on the calculated profit and loss for each predetermined period (step S200).

[0267] The control unit 11 transmits the generated balance sheet and profit and loss statement to the terminal 2 of the corresponding user via the communication unit 13 (step S201). The control unit 11 then ends the process.

[0268] According to this embodiment, it is possible to improve the efficiency of operations by automatically creating a balance sheet and an income statement for the target year for each user.

[0269] The embodiments disclosed herein are to be considered in all respects as illustrative and not restrictive. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the meaning and scope of the claims.

[0270] The matters described in each embodiment can be combined with each other. Furthermore, the independent claims and dependent claims described in the claims can be combined with each other in any and all combinations, regardless of the reference format. Furthermore, the claims use a format in which a claim references two or more other claims (multiple claim format), but this is not limited to this. A multiple claim (multi-multi claim) that references at least one other multiple claim may also be used. [Explanation of symbols]

[0271] 1. Information processing device (server) 11 Control section 12 Storage section 13 Communications Department 14 Reading unit 15 Mass storage 151 Network DB151 152 Wallet DB 153 Balance Log DB 154 Transaction Log DB 155 External Smartphone DB 156 Accounting Rules DB 157 API Key DB 158 Screenshot DB 1a Portable storage media 1b semiconductor memory 1P control program 2. Information processing terminal (terminal) 21 Control section 22 Memory section 23 Communications Department 24 Input section 25 Display section 2P control program 3 (3A, 3B, 3C) Blockchain Network (Blockchain) 31 nodes

Claims

1. Acquire accounting data from multiple blockchain networks based on different protocols, Convert the acquired accounting data, The converted accounting data is stored in the storage unit. Information processing methods.

2. Obtaining balances from the plurality of blockchain networks as the accounting data at a predetermined time. The information processing method according to claim 1 .

3. Obtaining transactions within a predetermined period from the plurality of blockchain networks; determining a wallet type corresponding to the balance; If the wallet type is a first type, calculate the reward for the predetermined period based on the difference in the balance and the fluctuation value due to all transactions; If the wallet type is the second type, it is determined whether the difference in the balance matches the fluctuation value due to all transactions. The information processing method according to claim 2 .

4. storing information about smart contracts of wallets corresponding to the balances deployed to each blockchain network in the storage unit; Obtaining the transaction or balance corresponding to said smart contract The information processing method according to claim 2 .

5. Obtaining, at a predetermined time, from the plurality of blockchain networks, a balance of a second wallet provided by a second company other than the first company, the second wallet being different from the wallet managed by the first company; Add the acquired balance of the second wallet to the balance of the first wallet. The information processing method according to claim 3 .

6. receiving a blockchain network and address corresponding to the second wallet; Obtaining a plurality of smart contracts corresponding to the second wallet based on the received blockchain network and address; Listing multiple retrieved smart contracts The information processing method according to claim 5 .

7. Accepting a selection of a smart contract to be edited from the plurality of smart contracts; For accepted smart contracts, edits can be made to accounting rules, including balance retrieval frequency, cost calculation logic, or token rate source information. The accepted accounting rules are stored in the storage unit. The information processing method according to claim 6.

8. Output a certificate containing the accounting rules The information processing method according to claim 7.

9. Accept the target accounting data, the IP addresses that can access the accounting data, and the settings of access rights; Based on the accepted target accounting data, IP address, and authority, an interface authentication key is issued for accessing the target accounting data in response to a connection request from the IP address.

3. The information processing method according to claim 1 or 2.

10. If authentication is successful using the issued interface authentication key, the target accounting data is output in a specified file format. The information processing method according to claim 9.

11. From the target accounting data, calculate the total crypto assets held by each user, The asset pool is calculated by subtracting the rewards to the manager, the rewards to the partners, and the realized gain tax imposed on the profits obtained from the sale or investment of assets from the calculated total crypto assets for each user, and the asset pool ratio for each user is calculated based on the calculated total crypto assets and the asset pool. Based on the calculated asset pool ratio for each user, the ratio of crypto assets held by each user to the total crypto assets is calculated as equity data. The information processing method according to claim 1 .

12. Calculate the cryptocurrency held by each user for each predetermined period in the target year based on the calculated ownership data and the moving average rate included in the accounting rules stored in the storage unit, Based on the calculated crypto assets held for each specified period, a balance sheet for the target year is generated for each user, Print the generated balance sheet The information processing method according to claim 11.

13. Calculating profits and losses for each user for each predetermined period in the target fiscal year based on the calculated equity data and a predetermined fee; Generate an income statement for the target year for each user based on the calculated profit and loss for each predetermined period; Print the generated income statement The information processing method according to claim 11.

14. obtaining screenshots containing transactions to substantiate said accounting data; The acquired screenshot is stored in the storage unit.

3. The information processing method according to claim 1 or 2.

15. The transaction, including the type of blockchain network, the type of token, the sender, the recipient, and the amount, is output as a list in a predetermined file format. The information processing method according to claim 14.

16. Acquire accounting data from multiple blockchain networks based on different protocols, Convert the acquired accounting data, The converted accounting data is stored in the storage unit. A program that causes a computer to perform a process.

17. An information processing device including a control unit, The control unit Acquire accounting data from multiple blockchain networks based on different protocols, Convert the acquired accounting data, The converted accounting data is stored in the storage unit. Information processing device.

Images