JP2024059549A - Artificial intelligence systems, how artificial intelligence systems learn - Google Patents

Abstract

[Problem] To provide a computer network system using a blockchain and a machine learning method for artificial intelligence, which allows the learning process of artificial intelligence to be analyzed and verified from the outside. [Solution] To provide a computer network system that forgets and erases machine learning data to save storage space in a storage device of a computer terminal. [0023] A method for verifying the continuity of block data even when part of the block data in the blockchain section has been removed (when data has been forgotten), in which a first blockchain section and a second blockchain section including hash value and digest data of the first blockchain of a blockchain recording section 30DLR2 are both stored in the storage device. [Selected Figure] Figure 9

Description

This application (application for utility model registration or patent application) relates to a computer system, program execution unit, data structure, and method for executing and storing program units (smart contracts) in the ledger record unit 30DLR (30DLR in the drawings, such as FIG. 1) of a distributed ledger system.

The present application relates to an environment and method in which encrypted data is included in ledger 30DLR, the encrypted data is decrypted, and a program included in the decrypted data is executed.
4A, 4B, and 4C are explanatory and conceptual diagrams of one-time password authentication using the method claimed in the present application.

The present application also proposes a ledger recording unit 30DLR2 including a first blockchain (30DLR2-1ST) and a second blockchain (30DLR2-2ND).
FIG. 5 shows an explanatory diagram and a conceptual diagram of the ledger recording unit 30DLR2 proposed in this application.

<Background to the proposal>
According to the invention of Non-Patent Document 1, a smart contract (hereinafter referred to as a contract or a smart contract) equipped with a variable function in a distributed ledger system DLS and an execution environment/virtual machine (EVM in Non-Patent Document 2) that executes the smart contract as a program are used to issue tokens/NFTs used on the DLS and provide various services. (For example, a smart contract that generates dynamic codes that can be used for dynamic passwords is disclosed in U.S. Patent Specification 200244457, the specification portion of Patent Document 1, and JP Patent Publication No. 2021-004788.)

●However, in known distributed ledger systems, the ledger data is public (visible to anyone around the world) (for the sake of transaction transparency and crime prevention), and there is a risk that the instruction codes, functions, and variables within smart contracts can be deciphered from the outside.
●Therefore, this application proposes a method and computer system in which the one-time password (OTP) calculation key variables, functions/procedures, and data groups that are to be kept confidential and encrypted from the one-time password (OTP) authentication program claimed in Patent Publication 2022-091158 are encrypted and recorded in 30DLR, and the recorded encrypted data is then decrypted in an execution environment 30CVMU/30CVM (virtual machine 30CVM) that is capable of decrypting encrypted data on a user terminal or server, and the programs contained in the decrypted data (in particular, the OTP calculation, OTP generation program, and OTP verification/authentication program) are executed.

●Also, tokens (or digital assets or digital currencies) that are allocated, purchased, traded, transferred or circulated on the distributed ledger system are recorded in a smart contract in the form of a token with a certain token number corresponding to a user identifier (or a certain user's public key or identifier information), and the token holdings status of a user can be seen from outside. (*Therefore, in the current situation, privacy can be maintained by not disclosing the correspondence between user identifiers and users in the real world to others.) (Also, the correspondence can be kept secret by intermediating securities companies, exchanges, etc.)
●In order to transfer tokens between individual users, it may be necessary for them to present their user identifiers to each other. This means that, for example, a transaction from user identifier A to user identifier B will be recorded in the ledger. While this maintains transparency, it may reduce privacy.
●Therefore, this application proposes an execution unit that reads mixed plaintext and ciphertext data on the blockchain as plaintext, regarding information related to user identifier A recorded on the ledger, and variables and functions that one wishes to partially hide when running a smart contract, and proposes decrypting the encrypted data using a decryption key (by recognizing, identifying, selecting, etc., portions of the encrypted data) from the data contained in the read mixed plaintext and ciphertext data, and also discloses a dynamic password authentication method using the decryption method.

● According to this proposal, in a publicly known distributed ledger system equipped with an execution unit 30PVM (e.g., Ethereum's EVM, Ethereum Virtual Machine) that reads data on the blockchain that is a mixture of plaintext and ciphertext, the proposed method can be implemented by providing an execution environment 30CVM/30CVMU (*30CVMU is specifically an execution environment within a user terminal) or virtual machine 30CVM that reads and decrypts encrypted data contained in plaintext in the node unit of the blockchain or the user terminal software/storage unit/processing unit, thereby claiming the effect of being able to use existing systems with a proven track record as is. (The advantage is claimed to be compatibility with existing blockchain/distributed ledger systems.)

<Existing concealment methods>
A well-known distributed ledger system that conceals transactions is Quorum, a distributed ledger system platform for businesses. It is equipped with a mechanism that uses private and public transactions. In Quorum, transactions are shared with those who wish to share them using a manager unit (execution unit) called Tessera that supports encryption. The Quorum system sends encrypted transactions via the Tessera API, which has encryption capabilities.

●In this application, we seek a solution different from Quorum mentioned above, by recording some encrypted data in the existing public ledger data section that can be seen by anyone (or by providing a code for reading the encrypted data that indicates the start and end of the encrypted data, so that the part that executes the data (execution environment, execution section, execution machine, execution virtual machine) can read the encrypted data (like the start and stop codons of a gene).
●Furthermore, a function that serves as a caller or getter for the encrypted data can be provided in a smart contract that stores encrypted data and plain data, and the encrypted data can be called from the blockchain, input into the second execution unit 30CVM of the server 3C or the second execution environment 30CVMU of the user terminal 1A, decrypted using a decryption key, and used for other or the next process.

●The Quorum system (from the inventor's point of view) uses one execution environment with encryption functionality. In contrast, in this application, data read in a plaintext-only execution environment (first execution environment) is decrypted as necessary and then executed in an execution environment with encrypted data decryption functionality (second execution environment), with the intention of providing a second execution environment in the form of a web app or the like in a distributed ledger system that only has a widespread first execution environment, making it possible to read blockchain data that is a mixture of plaintext and ciphertext.

In the present application, according to the processing of ECMAScript included in a web page as the second execution environment, there may be 1) a process for reading mixed data of ciphertext and plaintext from the blockchain, or for selecting, distinguishing, and identifying data including ciphertext from the blockchain and reading it, 2) a processing unit for decrypting the read encrypted data, and 3) a processing unit for performing the next processing (such as processing for various services) according to the decrypted data.
In this application, Figures 4B and 4C show examples of flow diagrams of a process for performing an OTP generation process (Figure 4B) and an OTP authentication process (Figure 4C) during OTP authentication (with a web browser, web page, or web application as the second execution environment 30CVMU) in accordance with the processing of ECMAScript contained in a web page (downloaded or distributed to a user terminal and loaded) as the second execution environment.

JP 2022-091158 A

Vitalik Buterin, "Ethereum White Paper A NEXT GENERATION SMART CONTRACT & DECENTRALIZED APPLICATION PLATFORM", [online], [Retrieved November 16, 2020], Internet <URL: https://cryptorating.eu/whitepapers/Ethereum/Ethereum_white_paper.pdf> Ethereum EVM illustrated [2022 AD, retrieved September 3, 2022], Internet <URL: https://takenobu-hs. github. io/downloads/ethereum_evm_illustrated. pdf

The problems that this application seeks to solve are described below.
1: Find a way to conceal or encrypt Smarttract internal variables, procedures, and functions.
1-A: In a smart contract-based OTP authentication system, keeping variable functions, etc. used in calculations confidential.
1-B: Find a way to conceal users’ transaction history and the correspondence between tokens they hold.

Here, the inventor believes that by encrypting and concealing the data, a third party cannot distinguish whether the contents of the transaction are DOS attack data or normal user data. (Normally, when fees, tokens, and gas are consumed in a transaction, DOS attacks are economically prevented, but here we assume that an attack is possible.) There is a concern that meaningless encrypted transactions due to DOS attacks will accumulate in the ledger and put pressure on the server's storage space. Therefore, the following problem is separately set, and a blockchain data structure (30DLR2, etc.) that addresses this issue is proposed.
2: Find a data structure that can verify the continuity of the blockchain while deleting past data blocks after a certain set time. (Consider a blockchain method that can forget some data blocks.)
2-A: Find a data structure that can verify the connections of the blockchain even if some of the data blocks are missing.
*Forgetting past block data prevents the data volume in the ledger from increasing.

The inventors wanted to create a blockchain system, distributed ledger system, and tamper-resistant data ledger system that can forget past data blocks, like official documents with a storage period.
We believe that if it is possible to realize a data structure that allows a data block to be separated from the blockchain when its storage period expires (or when demand disappears), blockchain will become easier to use in areas where data volumes are large and data storage periods are limited, such as official document data, web services such as SNS that include daily communication data, securities trading, and logistics service records, and we disclose the blockchain data structure claimed in this application.

<Issue 1: How to conceal and encrypt SmartLact internal variables, internal processing procedures, and functions>
1. Two types of program execution units (virtual machine, program execution unit/execution virtual machine, in the embodiment, a web application/web page having an ECMAScript execution unit) are used to execute smart contracts.
One is a virtual machine 30PVM (see, e.g., FIG. 1, FIG. 4B, etc.) that executes smart contracts using the code written in the blockchain section as plain text.
The other is a virtual machine 30CVM or execution environment 30CVM/30CVMU (Figures 1, 4B, etc.) that reads and decrypts the encrypted code written in the blockchain section and executes the smart contract.
- A functional unit 30CVMU (Figure 4B, etc.) corresponding to a virtual machine that reads and decrypts the encrypted code written in the blockchain unit 30DLR and executes a smart contract may be included in the user terminal in the form of a program, memory unit, and processing unit.

FIG. 1 shows a blockchain node terminal 3A, a service providing server terminal 3C (which performs OTP authentication and provides services after OTP authentication), and a user terminal 1A connected via a communication path 20.
Using the user's private key 10AKEY (if the private key 10AKEY is necessary), the ledger recorder 30DLR, the plaintext execution environment 30PVM (execution unit 30PVM), the decryption key 30CKEY, and the encrypted data decryption execution environment 30CVM (execution unit 30CVM),
The following describes, as an explanatory diagram, a system for decrypting and executing the encrypted data body 30DLR-CDATA-BODY of the tamper-resistant ciphertext/plaintext mixed data 30DLR-DATA.
●It is preferable that the encrypted data body 30DLR-CDATA-BODY contained in the ledger recording unit 30DLR is equipped with parts and means that can distinguish, identify, and recognize encrypted data and plain data within 30DLR, as shown in Figures 3A and 3B, and that encryption and decryption processes can be performed using a key.
FIG. 3B is an explanatory diagram of a case where the server 3C serves as a user terminal, is equipped with 30CVM and 30CVMU, and provides a service using encrypted data to the user terminal.
Figures 4A, 4B, and 4C are explanatory diagrams illustrating one-time password authentication performed by a distributed ledger recording unit 30DLR (blockchain-type recording unit 30DLR) including encrypted data and plaintext data and a second execution unit 30CVMU.
(The user terminal 1A may be connected to the server terminal 3D, which operates even when the Internet is offline, via a path 20-1A3D that directly connects the user terminal 1A and the server terminal 3D. The path 20-1A3D may be a wired contact type or a wireless contactless type.)

<Fig. 1 to Fig. 2>
Figure 1 illustrates (1) the case where encrypted data read from DLR 30 is decrypted by 30CVM and 30CVMU in user terminal 1A (30CVMU and user interface 30UI in the user terminal on the left side of Figure 1A), and (2) the case where encrypted data read from DLR 30 is decrypted by 0CVM and 30CVMU in servers 3C and 3D (server section, center of Figure 1A).
FIG. 1A shows an example in which a node 3A includes a first execution unit PVM that supports plaintext and a second execution unit 30CVM that supports encryption.
FIG. 1B shows an example in which a user terminal 1A includes a second execution unit 30CVMU.
FIG. 2 is an explanatory diagram of a computer used in the present application and a connection diagram of the computer.

<Figures 3A and 3B>
FIG. 3A is an explanatory diagram of the part 30DLR-CDATA-PS (the start of the encrypted data) and 30DLR-CDATA-PE (the end of the encrypted data) that identify the encrypted data 30DLR-CDATA-BODY from the data 30DLR-DATA recorded in the block chain recording unit 30DLR.
3A and 3B are explanatory diagrams showing how the encrypted data is read from the mixed data 30DLR-DATA of plain text and cipher text using the identifying portion, how the second execution unit 30CVM/30CVMU decrypts the data, and how the decrypted data is used or a program is executed. In the computer system of the present application, the identifying portion may be added to the encrypted data.
The 30DLR-DATA decryption unit F3B3 in FIG. 3B inputs 30DLR-DATA, which may be either encrypted data or plain data (a mixture of encrypted data and plain data) of the ledger recording unit 30DLR of the DLS, in a data input processing unit F3B1, and then detects identification parts 30DLR-CDATA-PS and 30DLR-CDATA-PE for detecting the encrypted data body 30DLR-CDATA-BODY in an input data analysis unit F3B2 (encrypted data identification unit, selection unit, and recognition unit F3B2), and detects the data part and range of the encrypted data body.

*In addition to this method, an array, mapping type, structure, etc. that sequentially stores and records encrypted data in 30DLR can be formed in advance using a smart contract, and this can be set as the storage location for the encrypted data. The encrypted data can then be called from the array, mapping type, structure, etc. in which the encrypted data is stored using ECMAScript and the DLS access API (30CVMU-W3J). Even in this case, the part that defines the type and variables of the encrypted data, such as the array and mapping, is equivalent to the part 30DLR-CDATA-PS and 30DLR-CDATA-PE that distinguishes, recognizes, and identifies plaintext data and encrypted data.
In the present application, it is preferable to provide a means for distinguishing, recognizing, and identifying the encrypted data body 30DLR-CDATA-BODY from 30DLR, which is a mixture of plain data (or data encrypted with decryption key B) and encrypted data (or data encrypted with decryption key A).
It is preferable to have a portion that can identify the encrypted data to be decrypted among the plaintext or encrypted data with different encryption key data.
*Even if there is no plaintext data and the stored encrypted data is encrypted with several decryption keys in the 30DLR, it is preferable to have an identifier such as 30DLR-CDATA-PS that distinguishes between data with different encryption keys.
--------------------------------------------------

●※The inventors consider it preferable to record the user identifier (30DLR-CDATA-ADDRESS) who deployed the smart contract in the contract of a certain block of data of 30DLR, and to be able to search for the contract using a blockchain explorer, etc.
For example, a corporation S wants to provide a SNS service using 30DLR, and the corporation has registered a contract address 30DLR-CDATA-ADDRESS with a public institution, etc., and records an array or the like for storing encrypted data at that contract address. The user identifier, etc., and the user's communication details and content recorded within the 30DLR contract can be encrypted and decrypted using the encryption key and decryption key managed by the corporation S and the web application type execution unit 30CVMU, and provided to users as SNS content.
(The operation diagram of the data processing of the SNS application is explained in FIG. 3B, FIG. 3C, FIG. 1, FIG. 1B, and FIG. 4A, FIG. 4B, and FIG. 4C in which a processing unit such as an OTP calculation unit of the OTP authentication service is used as a processing unit for the SNS service, and the like, are used as a processing unit storage unit for the SNS. The ledger recording unit 30DLR2 capable of deleting block data as shown in FIG. 5 etc. may be used as the block chain unit.)
If an incident or dispute occurs regarding the data contained in the contract of the contract address or the SNS service, corporation S that deployed contract address 30 DLR-C DATA-ADDRESS can disclose the encryption key/decryption key and web application type execution unit 30 CVMU that it manages to investigative authorities, etc., decrypt the encrypted data, disclose it to investigative authorities, etc., and work to resolve the incident or dispute.
●The SNS mentioned above was mentioned as an example of disclosure to investigative authorities, but similar disclosure and response to incidents and disputes can also be considered for banking services, securities services, financial services, and game services that use contracts. (The corporation that deployed the contract manages the keys and apps.)

For crime prevention purposes, the execution unit 30CVMU is used in conjunction with the block chain recording unit 30DLR2 in FIG. 5 described below, and when the contract address contains encrypted data based on the user identifier of an authenticated individual or corporation, the data is retained and left in the ledger.
Contracts containing encrypted data from unauthorized user identifiers may also be used in blockchain systems that restrict the use of encrypted data by preventing the node's client software/virtual machine from accepting deployments (or deleting deployed encrypted data blocks).
--------------------------------------------------

*Even if encryption is used, it is preferable to attach the representative's address (for example, a contract address containing transaction data of an exchange where NFTs are issued, transmitted, and traded) to the transaction. If all transaction data is transmitted in encrypted form, there is a risk that the transparency of the recording unit 30 DLR (or the ability to grasp, investigate, and audit the contents of the ledger from outside) will be zero.
* Encrypted data can be placed after the sender user identifier information, specifying who made the data secret, and if the issuer is, for example, the address of an authenticated company, the encrypted data that follows may not be a virus even if it is executed.
*There is a patent US20210042137 regarding assigning identifiers to data on the blockchain in order to execute it conditionally based on different programming languages, and there is a US patent example in which the EVM or C language execution environment is indicated by 01 or 03 at the beginning of the execution code of the smart computer. In this application, an identifier/data is assigned to the beginning of the encrypted data body to distinguish it from the encrypted data.
--------------------------------------------------

The data execution unit F3B13 stores the decrypted data F3B9 in the memory unit F3B10, processes it in the processing unit F3B11, and stores the processed information in the memory unit or outputs it as a processing result/response F3B12. It is output to the outside via the output processing unit F3B14. The output destination is the user terminal 1A, the server 3C, etc., or the recording unit 30DLR of the blockchain node terminal.
●The data execution unit F3B13 is preferably included in a virus-resistant execution unit F3B8 that includes a countermeasure part that can isolate or stop the virus, etc., in response to the operation of a virus that may be included in the data after decryption such as a sandbox when decrypting encrypted data and executing a program. (The 30DLR-CDATA decryption unit F3B3, etc. may also be included in F3B8. 30CVM and 30CVMU may also be included in the virus-resistant execution unit F3B8.)
Examples of processing results and responses F3B12 are: 1. Returning a return value (e.g., outputting to terminal 1A the dynamic code calculated according to the smart contract contained in the decrypted execution data), 2. Using functions and variables related to processing for calling and calculating from 30DLR-CDATA of another block number, 3. Sending a transaction to 30DLR, sending a transaction to the distributed ledger system/blockchain, concatenating plaintext/ciphertext data to a block, and 4. Other post-execution processing in the virtual machine/execution environment.
The execution units 30CVM and 30CVMU may be provided with an encryption part F3B15, the processing result and response F3B12 may be encrypted by F3B15, and the encrypted data may be output to the user terminal 1A, the server 3C, or the like, or the 30DLR of the node 3A.

3C is an explanatory diagram of a server terminal 3C that performs a service (OTP authentication, etc.) in the configuration of FIG. 3B (the user terminal does not have the execution unit 30CVM/30CVMU, and the execution unit 30CVM is included in the server 3C that can communicate with the user terminal) (or the user terminal is a server for services).
●Figure 3C shows an example in which the execution environment 30PVM is included in the backend section (web server terminal 3C or terminal 3D), the user terminal 1A accesses terminal 3C or 3D, and the user terminal 1A follows the web page or ECMAScript procedure sent by 3C or 3D, or the user terminal 1A makes input or requests to the execution sections 30CVMU and 30CVM running inside the servers 3C and 3D, which process the results and display and use them on the user terminal 1A.
● Smart contract provision unit front end F3C1. [Example: Smartphone-type OTP authentication and post-authentication service web application front end unit and execution unit 30CVM (execution unit 30CVMU when the execution unit is downloaded by the user)],
The F3C1 may be the front-end part of a web page or web application, or the HTML5+ECMAScript part (the so-called web page part).
It serves as a user interface and accepts requests for communication with the block chain unit 30DLR and node 3A according to user requests. For example, it receives a request to generate an OTP code, or a request to input an OTP code and perform authentication.
●The 30CVM management unit F3C3 (the part that rewrites and reads the 30DLR in response to instructions from the terminal 1A; the back-end part) is a processing unit on the server 3C side that can access the DLS and blockchain 30DLR which are normally inaccessible to the user terminal 1A because there is no means of access to them (or because APIs, etc. are not intentionally made public to prevent access from general users, or because access is specified or limited), and when a node 3A that 3C can access is installed, 3C accesses the 30DLR of the 3A and reads data including encrypted data, or writes data to the 30DLR.
301C is a program and recording section for services implemented by 3C, and 311C is a service processing section for 3C. 30DLR-C is data read by 3C from 30DLR and stored therein.
F3C5 is the program part that allows access to the blockchain (it can also be client software (node communication part)). 3C may be part of the DLS just like node 3A.
●F3C4 is the key data/key management unit (tamper-resistant storage area possible).

1A illustrates a configuration in which encrypted data read from DLR 30 is decrypted by 30CVM in server 3A. (Server 3A may also include 30PVM.)
FIG. 1B illustrates the execution environment 30CVMU (virtual machine 30CVMU) provided on the user terminal and the plaintext reading virtual machine PVM reading encrypted data from block data including encrypted data, decrypting it, executing the data, generating a return value, and writing the data to the ledger.

As an advanced version and embodiment of Figure 1B, the explanatory diagram of the present application in Figure 4B asserts that when a web application execution unit 30CVMU-APP (processing unit/storage unit of a web browser) is stored in a user terminal and a processing unit 31CVMU-APP by 30CVMU-APP is provided in the user terminal, the processing unit 30CVMU-APP reads data from 30DLR, decrypts the encrypted data using decryption key F4B-9 to obtain decrypted data F4B-11, and inputs plain data F4B-12 and the decrypted data F4B-11 to an OTP calculation unit F4B-15 to perform an OTP calculation.
FIG. 4B shows an execution section for calculating and generating an OTP and storing/recording it in a recording means or a storage device, and FIG. 4C shows an execution section for verifying and authenticating the input OTP.

<Problem 2: A data structure that can verify the continuity of a blockchain while deleting past data blocks after a certain set time in the blockchain>
Regarding the first (30DLR2-1ST) and second (30DLR2-2ND) blockchains, we also propose that the second blockchain contains a hash value of a block of the first blockchain, so that even if a block of the first blockchain is deleted, the second blockchain containing the hash value makes it possible to verify the continuity of the blockchains.

Figures 5 (a) and (b) are explanatory diagrams showing that for the first (30DLR2-1ST) and second (30DLR2-2ND) blockchains, the second blockchain contains a hash value of a block of the first blockchain, so that even if a block of the first blockchain is deleted, the second blockchain containing the hash value makes it possible to verify the continuity of the blockchain.
FIG. 5(c) is an explanatory diagram of a case where a third blockchain is provided in addition to the first and second blockchains (or a third, fourth, fifth, ..., nth blockchain is provided), each of which has a hash value sharing portion (30DLR-SHA, 30DLR-SHA-n ..., etc.).

* When the ledger recording unit 30DLR2 includes a first block chain (30DLR2-1ST) that links blocks at a short interval (e.g., every 5 seconds) and a second block chain (30DLR2-2ND) that links blocks at a long interval (e.g., every 50 minutes), as shown in FIG. 5B,
For a set number (e.g., 50 minutes ÷ 5 seconds = 300, m = 300) of data blocks (e.g., when data block an is from a301 to a600) in the first blockchain,
A data block sAn (here, sA2 as an example) of a second blockchain is formed, and the hash values of each of the number of data blocks (e.g., 300) set in the data block of the second blockchain are stored in sAn (here, sA2);
The hash value sAnh (here, sA2h) of the data block sAn is stored in the next data block sA(n+1) (here, sA3),
The process is repeated by linking the number of data blocks set in the first blockchain (e.g., 300 blocks, from a601 to a900).
(When each block of the first and second blockchains is expressed as a paper page block, a contract seal (actually a hash value, digest, fingerprint, characteristic data) is stamped on the boundary of each block.)

<Storage of the block hash value of the second blockchain in a block of the first blockchain [Storage of the block hash value of the nth blockchain in a block of the (n-1)th blockchain]>
In data block a4 in (b) of Figure 5, in addition to the hash value a3h of data block a3 in the previous first blockchain, the hash value sA1h of the previous block sA1 in the second chain may be stored, incorporated, or incorporated into data block a4.
(The block hash value of the nth blockchain may be stored in a block of the (n-1)th blockchain.)
By incorporating the hash value sA1h of the second blockchain into the data block a4 of the first blockchain, the data block of the first blockchain can reflect (or link) the data in the second blockchain.
Alternatively, by incorporating hash values, the first and second hash values can be generated in a mutually altered way, allowing the data to be intertwined. Elements of the first and second blockchains are interconnected.
(When the hash function used by the first chain, the imported data blocks, and the concatenation order are known, the hash values that appear in each block of the blockchain can be guessed.
However, if the hash value of a block of the second chain is incorporated into the first chain (incorporated in a feedback manner), a new element (a second chain element) is added to the first chain, and the hash value that appears in each block of the blockchain may become more difficult to guess.

<Environment 30CVM for executing encrypted data as shown in FIG. 1, FIG. 4B, etc.>
1-1. Plain data and encrypted data can be recorded together in a smart contract and can be read, executed, and written. As a result, information that needs to be kept secret, such as key variables for OTP calculations and user identifiers, can be kept secret.
1-2. For example, when trading tokens and NFTs between different user identifiers, they can be encrypted and traded. (However, a server 3C and a user terminal 1A having an execution environment 30CVM/30CVMU that can use the decryption key are required.)
The user identifier can also be kept anonymous when a token is stored and transferred in the presence of an administrator (transfer institution) that removes a certain token of a certain user from the user identifier and assigns it to another user identifier.
1-3. When used in social networking services, etc., if there is data that should be kept secret in comments between users, the data can be hidden.

<Blockchain data structure 30DLR2 described in FIG. 5 etc.>
2-1. Only blocks in demand included in the first blockchain are left, and when there is a request for deletion due to low demand or the data block containing personal information in plain text, the corresponding data block is deleted or archived on an external storage device such as a magnetic tape and removed from the node terminal 3A. The existence of the second blockchain may have the effect of verifying the continuity between data blocks from the first and second genesis blocks.
2-2. The data structure 30DLR2 having the first and second blockchains shown in FIG. 5 etc. may be used to record content.
For example, when a social networking service records interactions such as comments between users in a ledger, if some block data is forgotten in the existing ledger recording unit 30DLR, it may be impossible to verify the continuity of the chain.
In the 30DLR2 of FIG. 5 of the present application, even if some data is deleted or forgotten, the continuity of the chain can be verified and the system can continue to operate.
When it becomes necessary for users to delete comments on a social networking service (SNS) or the like for some reason, the client software in 30DLR2 of node terminal 3A can delete a data block that includes the comment to be deleted.
2-3. The data structure having the first and second blockchains shown in Fig. 5 and other figures can be used in a distributed ledger system, as well as in an artificial intelligence system that performs machine learning, which can store learning data in the latest data block and learn while forgetting data blocks that meet specified conditions, as well as in the recording section and database section of the learning data of the artificial intelligence. Fig. 9 is an explanatory diagram of this.

In the example of Figure 9, the dataset, learning method, and processing unit lead to AI that is tamper-resistant and transparent.
・It will also lead to the construction of memory, processing, and computer systems that can forget what has been learned in the past, or determine that what has been learned in the past is the same. (The use of blockchain is proposed when there is a need to make the machine learning process/data/model creation method, etc., transparent.
- When using blockchain, as long as the artificial intelligence system is running, learning data continues to be imported into the conventional blockchain unit 30DLR (which is a single chain type), and the amount of data continues to increase, but with the 30DLR2 proposed in this application, duplicate data, data that has aged, and blocks of data that are no longer in demand can be deleted, which may be useful for reducing the storage area and storage volume of computers and devices equipped with artificial intelligence (AI), robots, home appliances, production machinery, transportation equipment, etc.)
・AI that has learned learning data from the blockchain's genesis block to the data blocks one after another can have its learning process analyzed by a third party from the blockchain's data blocks. This may be useful for analyzing the learning, growth, and behavior of AI to determine how to make AI reproducible.

<Explanation of FIG. 9>
In 30DLR2 of Figure 9, data sensed or acquired from the input source 4IN by the input device 104 of the automobile 4CAR, which is the artificial intelligence system 4 (or data obtained by the communication device 102, including data obtained by communication with other computer terminals via the Internet when the device 102 is connected to the network 20) is recorded in the data block of 30DLR2 as shown in Figure 5 (Figures 5 to 8).
Thereafter, the memory unit and the processing unit use the output device 105 and the communication device 102 to output a response as an artificial intelligence based on the input source 4IN and other set data, learning data, etc. as an output result 4OUT.

Machine learning is performed according to the machine learning software unit 30STUDY and the machine learning processing unit 31STUDY. The learning data is recorded in 30DLR2.
● The frequency of use of each data block is recorded in the data demand recording unit 30DEMAND of each block of learning data. Example: The number of transactions such as functions belonging to the data block or the contract address in the data block that are called. (If tamper resistance is required for the demand recording unit, the demand recording unit 30DEMAND may record in a recording unit having a blockchain structure.)
*The above-mentioned parts (machine learning software part 30STUDY, and machine learning processing part 31STUDY, 30DEMAND, 31DEMAND-FORGET, etc. in FIG. 9) are parts related to information stimulated and stored in the human brain (parts that attempt to imitate the characteristics of living things with a machine). They are processing, memory, and software parts that attempt to reproduce, with a computer, the processing part that stimulates the brain and strongly memorizes things when living things such as humans and monkeys are trained repeatedly to remember things well (or when they are stimulated and memorize things by learning fear, or when they are stimulated and memorize things by following a desire, etc.). (They are also parts that attempt to forget data blocks that are not in demand or have not been used for a long time.)
A processing unit 31DEMAND-FORGET for storing or deleting learning data on demand uses a demand recording unit 30DEMAND or a unit 30DEMAND for recording data to be deleted or forgotten, to delete data blocks to be deleted or forgotten from the storage device.
●The data recording unit 30DEMAND may store, in addition to information on the frequency of use of data blocks, information that the administrator of the artificial intelligence system 4 determines should be deleted (e.g., personal information, privacy information) or information that has passed the number of years or time specified by the administrator.
(In this application, old data blocks are deleted, and the phenomenon in which humans forget what they have memorized over time, and the phenomenon in which memories are organized during sleep, are reproduced by a computer.)

In the example of Figure 9, the linking of blocks is performed by the control unit of the system. This is different from the examples of Figures 1 and 2, where multiple servers in the distributed ledger system reach a consensus through voting and other processes.
Figure 9 shows a case where 30DLR2 is included in the memory device of a single robot, unmanned aerial vehicle, drone, automobile, airplane, or transportation equipment.
For example, if there is an artificial intelligence system 4CAR for an automobile that may go offline, and the 4CAR has a processing unit, a memory unit, an input/output device, and a communication device for machine learning, and the memory unit is equipped with 30DLR2, consensus formation via a network 20 such as DLS is not necessary. (However, if the artificial intelligence system 4 is a computer network system consisting of multiple nodes 4SEVER, a processing unit/functional unit related to consensus formation/consensus for linking block data is necessary in the blockchain unit 30DLR2.)

<Regarding the hash values anh and sAnh recorded in the first and second (nth) blockchains and the values anh and sAnh summarizing data blocks>
In the example of Fig. 5(b), three block hashes of 30DLR2-1ST are stored in one block of 30DLR2-2ND. It is not limited to the three (integer m = 3), but a predetermined integer m can be set (in the blockchain client software, node software 30DLSC), or the integer m can be determined by voting between node terminals, and the m block hashes of 30DLR2-1ST can be stored in one block of 30DLR2-2ND.
*For example, if m = 100 and the time to increase m by 1 (the time to increase An by 1 block) is 5 seconds, then the condition of m = 100 means that when linked to an over a period of 500 seconds, the hash values of each of the 100 block data are stored in one data block of sAn and linked to the second blockchain.
*When the time to increase m by 1 for An is 5 seconds, if sAn is increased every 10 hours, then m = 7200. In a system in which a copy of the balance is kept in sAn every 10 hours for the purposes shown in FIG. 10 below, 7200 block hash values are stored in one block, along with the closing balance of the user for that period. (The latest balances of all users who have made a transaction may be stored.)

The hash value anh·sAnh recorded in the blockchain in FIG. 5(b) is obtained by inputting the data blocks an·sAn into a hash function.
The hash value anh·sAnh is a summary of the data block an·sAn, and anh·sAnh is data summarizing the data block an·sAn.
5B anh·sAnh may include fingerprint data, summary data, or feature data and·sAnd that represent (summarize) the features of the data blocks an·sAn, and the feature data may be extracted from the target content using a feature extraction program and saved or recorded in the data block together with anh·sAnh (for example, the hash value a3h of a3 and the feature data a3d of a3 recorded in a4 in FIG. 5B).
[*It is publicly known that a feature extraction program is used to extract the feature data from the target content, and the feature data is used to detect illegal content in video data provided on video sites and video viewing services. (Example: NTT Data Corporation's service https://www.nttdata.com/jp/ja/news/release/2010/081600/ accessed October 16, 2022, Internet)]
(If and·sAnd is data that can be used to detect tampering in the same way as the hash value, it may be possible to use it instead of the hash values anh·sAnh.)

●Data blocks may store data necessary for machine learning.
- It may include training data in supervised learning and human-assigned correct label data/annotations corresponding to the training data.
The learning data used in unsupervised learning may include processing procedures and programs that analyze features, regularities, correlations, characteristics, specificities, trends, etc., without providing correct answers to the learning data. The processing procedures and learning data may store the laws of nature (laws of physics, laws of natural science). Content related to humans and society, such as the laws of each country, processing procedures for complying with the laws, and other data that must be complied with even if the machine is in a human society, may be stored (for example, a processing procedure for blacking out images that cannot be handled).

The contents may include audio data and video data. It may also include data obtained by sensing the learning source 4IN by a sensor.
In particular, in the usage example of Figure 9, when the automobile 4CAR, the unmanned aerial vehicle 4DRONE, or the robot 4ROBOT uses 30DLR2, the feature data And/sAnd can be extracted using a feature extraction program from video data/sensing data captured/sensed by a camera or sensor of the outside world (the behavior of people walking on the road, the driving conditions of cars and bicycles, and sounds on the road) while the 4CAR, etc. is moving, and the feature data can be saved/recorded in a data block together with anh/sAnh.
Then, machine learning is performed on the recorded data using 30STUDY and 31STUDY, and if any data to be saved is generated after the learning, it is stored in 30DLR2.
An automobile 4CAR, which is also an artificial intelligence system 4, performs machine learning while sensing a learning destination 4IN, which is an external system to 4, and makes a response 4OUT based on the information stored in 30DLR2.

<Explanation of FIG. 10>
* Figure 10 shows a case where transaction data, address type data, and unused transaction output UTXO data (input data and output data) are stored in the first blockchain data, and the first blockchain data and the account type data at the time of the latest block of the second blockchain are stored in the latest block sAn (sA2 in the figure) of the second blockchain. A third (nth) blockchain that stores the hash value of the second blockchain may be provided.

<30 DLR other than blockchain>
When using the execution environment 30CVU claimed in the present application in Figures 1, 4B, 4C, etc. to encrypt and decrypt part of the recorded contents of the recording unit 30DLR of the distributed ledger for use, the 30DLR may use asymmetric encryption and cryptographically linked data blocks in addition to a blockchain-based method. It may also be a directed graph in which data blocks/data groups such as a directed acyclic graph are linked.
Considering the concept of the first blockchain and the second blockchain (and data structures having a third, nth, or third blockchain, if necessary) as shown in (b) of FIG. 5, if the first blockchain of 30DLR2 is a data structure that is not a blockchain (e.g., in the case of a data structure an that is an asymmetric cryptography and cryptographically linked data blocks, a directed graph, or a directed acyclic graph), 30DLR2 may include another data structure sAn that is formed separately to store hash values, summary values, fingerprints, and feature data of m linked data blocks at a certain time.

<Drawing Description>
<Figure 1> An explanatory diagram of the program execution units 30CVM and 30CVMU that decrypt encrypted data in the record section of the distributed ledger and execute a program. <Figure 1A> An explanatory diagram showing that, upon receiving access from a user terminal, the execution environment 30CVM (virtual machine 30CVM) and the plaintext reading virtual machine PVM can access the ledger data section 30DLR, and that the 30CVM decrypts the encrypted data of block data that includes encrypted data and executes it as a smart contract (the plaintext reading virtual machine PVM is an example in which the EVM in Ethereum is realized).
(Alternatively, FIG. 1A is an explanatory diagram of a system including virtual machines for executing two smart contracts. Of the two virtual machines, one is a virtual machine PVM that writes plain text to the blockchain section, and the other is a virtual machine CVM that writes encrypted data to the blockchain section.) (In the system of FIG. 1A, the blockchain section is usually made available to other companies via the virtual machine PVM, allowing plain text and encrypted data to be read. To decrypt and read encrypted data, the decryption key for the encrypted data is input to the virtual machine CVM, etc., for viewing.)
In the figure, BDCn: data, data block, or transaction including encrypted, coded, or concealed data (n is an integer), BDPn: data including plaintext data, etc. (n is an integer).
<Fig. 1B> An explanatory diagram of the execution environment 30CVMU (virtual machine 30CVMU) and the plaintext reading virtual machine PVM reading encrypted data from block data including encrypted data, decrypting it, executing the data, generating a return value, and writing the data to the ledger (or Fig. 1B is an explanatory diagram of the case where the user terminal includes a function similar to the virtual machine CVM in the scene of Fig. 1A. In the system of Fig. 1A, the data encrypted by the virtual machine PVM is written to the blockchain, and then when desired to use it, the encrypted data is read directly from the blockchain by the virtual machine PVM, and the encrypted data including the encrypted smart contract is temporarily stored in the user terminal, and the smart contract is executed using the encrypted data decryption unit and smart contract execution unit installed in the user terminal.)
<Fig. 2> Example of computer and computer network used in this application <Fig. 3A> An explanatory diagram of the encrypted data body 30DLR-CDATA-BODY and its associated data, the encryption start part 30DLR-CDATA-PS, and the end part 30DLR-CDATA-PE in the data 30DLR-DATA containing encrypted data (an explanatory diagram of the part for selecting, identifying, distinguishing, and picking out the encrypted data 30DLR-CDATA-BODY from 30DLR)
<Fig. 3B> An explanatory diagram of the part for selecting, identifying, and distinguishing the encrypted data 30DLR-CDATA-BODY from 30DLR. <Fig. 3C> An explanatory diagram of the case where the service providing server 3C (for example, the server 3C that generates OTP and provides authentication services for OTP authentication and services after authentication), the user terminal 1A, and the node terminal 3A (30DLR of 3A) decrypt the encrypted data obtained by 3C from 3A at the request of the user terminal 1A and provide services such as OTP authentication. <Fig. 4A> Computer connection diagram during OTP authentication by the web application execution unit 30CVMU. *20-1A3D is a communication path 20-1A3D (wired/wireless communication path) when the user terminal 1A wants to communicate with the offline-compatible authentication terminal 3D because the communication path 20 such as the Internet cannot be used.
<FIG. 4B> Example of the present application regarding OTP generation/calculation during OTP authentication by the web application execution unit 30CVMU. 1. The server terminals 3C and 3D that provide services for web pages and web applications,
Sending a web page application 30CVMU-APP with OTP generation software including an OTP calculation algorithm to the user terminal 1A;
2. The user terminal receives, stores, and executes the 30CVMU-APP;
3. The 30CVMU-APP receives private key information F4B-2 for accessing the user's 30DLR, signature processing using the private key, and input and processing of the user's token number (individual number of the OTP token) and other arguments, and uses the 30CVMU-W3J to download and store information 30DLR-DATA including encrypted data from the 30DLR to the user terminal (this includes the following: F4B-24: encrypted key value CKC, encrypted function Cfp, etc., and F4B-25: plain data, TIDA, Bn, etc.).
4. The encrypted data is decrypted by the encrypted data decryption unit F4B-10. Identification information for distinguishing between plaintext data and encrypted data, or between encrypted data with different encryption keys, may be provided in the 30DLR in relation to F4B-10, and the identification information may be used for identification and detection by the functional units of F4B-10 and F4B-26, and plaintext data and encrypted data may be separated as in F4B-26.
5. The encrypted data is decrypted with the decryption key F4B-9 to obtain decrypted data F4B-11.
6. The decrypted data F4B-11 (KC obtained by decrypting CKC, function fp obtained by decrypting Cfp, etc.) and plain text data F4B-12 (block number Bn, token number TIDA, etc.) are input to the OTP calculation unit F4B-15, which performs OTP calculation and outputs/generates the OTP (F4B-16). After that, the OTP is recorded on a printed matter or display device (F4B-6), or stored in a storage device of the user terminal (F4B-5). In F4B-6, the OTP output by the computer is written by the user or photographed and recorded in another recording means, which is also considered as the recording means F4B-6 of the present application.
*It is preferable that the application data is provided with a tamper detection means or a digital signature. Alternatively, it is preferable that the application data is recorded on a medium that is difficult to tamper with. For example, the web application/application data 30CVMU-APP may be recorded in a smart contract of a blockchain. (If the ECMAScript portion is tampered with, it becomes difficult to calculate and generate a correct OTP and operate the web application. Also, a digital certificate for the application data is required to prevent application spoofing.) The application data may be transmitted via a route encrypted by SSL, TLS, etc.
The web application/application data may be provided with means for detecting tampering with certificates, digital signatures, HMACs, hash values, etc.
<<Relationship to Patent Application No. 2021-004788>>
*The content asserted in Patent Application No. 2021-004788 may be implemented in this application. In Patent Application No. 2021-004788, the execution unit of the smart contract was the plaintext execution unit 30PVM (particularly the Ethereum Virtual Machine) defined in this application, but this application proposes using the execution unit 30CVM and execution unit 30CVMU that correspond to data containing ciphertext.
In Japanese Patent Application No. 2021-004788, a process for changing the display period and input standby time of the OTP when calculating the OTP, and a process for increasing or decreasing the number of digits and data amount of the OTP are disclosed, but in this application, for example, the OTP calculation unit F4B-15 of 30CVMU may be provided with a part that performs the above-mentioned processes. It may include a process for using a known OTP.
* In the case of Figure 4C or Figure 4B, only the variable KC is secret (hidden in the form of encrypted data CKC), but the token ID and user identifier A can be made public, so that an outsider can sense, for example, that an NFT has been transferred. There are also cases where the user identifier A is additionally hidden.
<FIG. 4C> An embodiment of the present application regarding OTP comparison, verification, and authentication during OTP authentication by the web application execution unit 30 CVMU. This is the same as FIG. 4B.
In FIG. 4C, the application is provided in the authentication terminals 3C and 3D, and the OTP is input to F4C-9 using the OTP recording means. In FIG. 4B, the user terminal downloads an application that generates an OTP, accesses 30DLR using the private key it holds, and calls a variable function to calculate the OTP.
<Figure 5> Figures 5 (a) and (b) are explanatory diagrams showing that for the first (30DLR2-1ST) and second (30DLR2-2ND) blockchains, the second blockchain contains a hash value of a block of the first blockchain, so that even if a block of the first blockchain is deleted, the second blockchain containing the hash value makes it possible to verify the continuity of the blockchain.
- A block hash of the second blockchain may be incorporated into a block of the first blockchain to correlate (link) the first and second.
FIG. 5(c) is an explanatory diagram when a third blockchain is provided in addition to the first and second blockchains (or a third, fourth, fifth, ..., nth blockchain is provided), each of which has a hash value sharing part (30DLR-SHA, 30DLR-SHA-n).
<Figure 6> Figure 6 is an explanatory diagram of the first (30DLR2-1ST) and second (30DLR2-2ND) blockchains in the blockchain data of Figure 5, where the second blockchain (30DLR2-2ND) contains the hash values A3h and A4h of A2 and A4, so that even if the data of A2 and A4 has been deleted, the second blockchain containing A3h and A4h makes it possible to verify the continuity between the remaining blocks of the second blockchain and the first blockchain.
<Fig. 7> Fig. 7 is an explanatory section of the terminal 3A in Fig. 5. An explanatory section of the control section, processing section and storage section of the node terminal 3A of the distributed ledger system using 30DLR2.
<Figure 8> Figure 8 is an explanatory diagram of one procedure for linking the first and second blockchains in Figure 5.
<Fig. 9> Fig. 9 shows examples of a computer 4 or an artificial intelligence system 4 having the block chain recording unit 30DLR2 in Fig. 5, or a server 4SERVER, a robot 4ROBOT, a transport device (4CAR), an unmanned aerial vehicle (4DRONE), an agricultural machine (4AGRI), a production machine (4Production), etc. (Examples of devices that do not necessarily use the network 20)
*The computer described in Figure 9 obtains learning data from the input source information 4IN, records the learning data 30STUDY-DATA in a tamper-resistant blockchain-type recording unit 30DLR2, and uses it for machine learning using the machine learning unit (31STUDY).
(For machine learning, known methods such as deep learning may be used, and for learning data, known methods such as supervised data may be used.)
* After learning, the learning data is stored in the storage device with data on frequency of use and recency (demand data 30 DEMAND) corresponding to the learning data.
*The learning data is deleted from the part (31DEMAND-FORGET) that stores or deletes the learning data according to demand and from the first block chain part (30DLR2) according to demand data.
*By making the data block forget, the artificial intelligence system 4 forgets that it has once recorded it. Even if the system forgets the data, the past hash values or parts summarizing the data (a1h, a2h, a3h, ..., anh) remain in the data blocks (sA1, sA2, sA3, ..., sAn) of the second blockchain, so there is no need to worry about tampering and it is clear that the data has already been learned once.)
<Figure 10> An explanatory diagram of the case where UTXO type transaction data or account type transaction data is stored in a data recording unit 30DLR2 including the first, second, ..., nth blockchains.
*This is an explanatory diagram of the case where the latest block sAn of the second (third, nth) blockchain records a balance list for each account in the first blockchain or a balance list based on a user's UTXO.

An explanatory diagram of the program execution units 30CVM and 30CVMU that decrypt encrypted data in the record section of the distributed ledger and execute the program. An explanatory diagram of the operation of the execution environment 30CVM (virtual machine 30CVM) with encrypted data decryption function of the node terminal 3A and the plain text reading type virtual machine 30PVM. A diagram for explaining the reading, decryption, and data execution of encrypted data from 30DLR by the execution environment 30CVMU in the user terminal and the plaintext reading virtual machine 30PVM, and writing to 30DLR. Examples of Computers and Computer Networks Used in This Application An explanatory diagram of a part for selecting, identifying, and distinguishing the encrypted data 30DLR-CDATA-BODY from 30DLR. A diagram for explaining the process of selecting, identifying, and distinguishing the encrypted data 30DLR-CDATA-BODY from 30DLR and encrypting and decrypting it. FIG. 13 is an explanatory diagram of a case where the service providing server 3C decrypts the encrypted data obtained from 3A and provides a service such as OTP authentication. Computer connection diagram for OTP authentication using the web application execution unit 30CVMU Example of the present application regarding OTP generation and calculation during OTP authentication by the web application execution unit 30CVMU Example of the present application regarding OTP comparison, verification, and authentication during OTP authentication by the web application execution unit 30CVMU An explanatory diagram of a recording unit 30DLR2 having a second and a first block chain. An explanatory diagram showing how, in 30DLR2 of Figure 5, when a portion of the first blockchain is deleted, it is possible to verify the continuity between the remaining blocks of the second blockchain and the first blockchain. FIG. 7 is an explanatory section of the processing section and storage section of the node terminal 3A, the computers or servers 3C and 3D, the artificial intelligence system 4, etc., which perform the processing of FIG. FIG. 8 is an explanatory diagram of an example of a procedure for linking the first and second blockchains of FIG. FIG. 9 is an example of a computer 4 or artificial intelligence system 4 having the blockchain recording unit 30DLR2 of FIG. FIG. 13 is an explanatory diagram of a case where UTXO type transaction data or account type transaction data is stored in a recording unit 30DLR2.

In implementing the execution units 30CVM and 30CVMU in this application, the computers, computer network systems, computer processing units and storage units shown in Figures 1, 1A, 1B, 2, 4A, 4B and 4C are used.
Moreover, the recording unit 30DLR2 of the present application uses the configurations shown in FIG. 5(b) or (c).

By providing execution units 30CVMU and 30CVMU in user terminal 1A, servers 3C and 3D, and node 3A, the present application makes it possible to decrypt encrypted data from data that is a mixture of plain text data and encrypted data recorded in the recording section of the distributed ledger section.
Representative diagrams for executive units 30CVMU-30CVMU are FIGS. 1, 1A, 1B, 3A, 3B, 4A, 4B, and 4C.

<The part that distinguishes between plaintext and encrypted data (and between encrypted data) and decrypts and executes it>
The present application relates to a data ledger recording unit 30DLR,
30PVM for reading data 30DLR-DATA recorded in 30DLR;
Included in the 30DLR-DATA shown in FIG.
The start of encryption 30 DLR-CDATA-PS;
Represents the end portion 30 DLR-CDATA-PE;
detection means for detecting a crypto zone identifier;
Or a part that specifies the encrypted part (30DLR-CDATA-PS·PE,
30 DLR-CDATA-ADDRESS,
30 DLR-CDATA-ANNOTATION) and
The detection means shown in FIG. 3B analyzes and recognizes the encrypted portion,
A process F3B2 for selecting the encrypted portion;
A means for decrypting the encrypted data 30DLR-CDATA-BODY recorded in the encryption section;
or as the means, a processing unit F3B3, a processing key F3B4, and a key calculation unit F3B5;
The decoding means
The encrypted data is decrypted to obtain decrypted data F3B9,
Executing the decoded data as instructions;
A computer (which may be a node 3A, and is preferably a user terminal or a server 3C or 3D) having an execution unit 30CVM, 30CVMU, or F3B13.
We propose a virtual machine, execution environment, or execution unit 30 CVM/CVMU that decrypts and executes encrypted data included in the ledger data section of the distributed ledger system.
An example of a service provided by the execution units 30CVMU and 30CVM is an OTP authentication service, which performs the OTP generation and authentication services shown in Figs. 4B and 4C.

The 30CVM may be executable software 30CVMU (application browser web page web application, 30CVMU-APP) formed using the memory and processing unit of the user terminal.
●30PVM is specifically the Ethereum Virtual Machine EVM in Ethereum, and in this application, while maintaining compatibility with the EVM, in order to handle encrypted data, the data in 30DLR is read by 30PVM, and then the data is input to program execution units called 30CVM and 30CVM, and if the input data contains encrypted data, it is decrypted and the decrypted data is executed or utilized.

<<Web browser-based execution environment with encrypted data decryption function>>
●As one of the 30CVMUs, the execution environment 30CVMU-HTMLJS in a web browser may be used.
4A, 4B, and 4C show a connection diagram of an electronic computer when using the web application execution unit 30CVMU-HTMLJS of a web browser, and, as an example of operation, a flow diagram of the operation of an execution environment that calculates, generates, and outputs a one-time password OTP, and an execution environment that compares and verifies the input OTP and authenticates it.
●In the configurations of Figures 4A, 4B, and 4C, the EVM is used as an execution environment (first program execution environment) for reading plain text, which may be mixed with encrypted data in the blockchain record section, and the web application execution section 30CVMU-HTMLJS of a web browser having an encrypted data decryption section is used as the second program execution environment.

In Figures 4B and 4C, as a specific form of 30CVMU, a processing unit is provided within the web browser execution environment 30CVMU-HTMLJS (30CVMU-APP) that calls up encrypted data CKC of the variable KC for OTP calculation, the token number TIDA, and the block number Bn from the blockchain in the form of ECMAScript.
The CKC is decrypted using an asymmetric key cipher or symmetric key cipher with a decryption key to obtain data KC, and the group of variables KC, TIDA, and Bn are input to a hash function or an OTP calculation function according to the OTP calculation procedure and algorithm of the 30CVMU-HTMLJS internal ECMAScript.
In the figure, there is a case where an OTP is calculated and generated and output (FIG. 4B),
A case where the input OTP is verified and authenticated (FIG. 4C) is proposed as a first embodiment.
(In FIG. 4B and FIG. 4C, the variable KC obtained by decrypting the variable CKC with the decryption key, the token number TIDA, and the block number Bn are input to the hash function fh, and the OTP is calculated through processes such as finding a hash value.)

● In this proposal, it may be used in the form of a web application 30CVMU-APP (or an executable format such as a downloaded local HTML/JS file/EXE file that runs offline), but may also include a hash value of 30CVMU-APP and the creator's electronic signature information 30CVMU-APP-SIGN. 30CVMU-APP and 30CVMU-APP-SIGN may be stored in another blockchain (or a medium or repository that can detect tampering) and may be downloaded by the user and used on a user terminal. It is preferable that the software data of the second execution environment has not been tampered with, and a means for identifying the identity of the file creator (the origin of the file) may be added, and it is preferable that the correctness and authenticity of the web application/second execution environment 30CVM/30CVMU and its creator can be verified using an electronic signature, digital signature, HMAC, hash value, etc.

The second execution environment may manage the user's private keys. For example, the second execution environment may be in the form of wallet software.
The second execution environment 30CVM/30CVMU may be provided with a decryption key. The second execution environment may be capable of inputting and outputting the decryption key. The private key and the decryption key may be stored in a tamper-resistant storage device.
●If possible, it is preferable that private keys and decryption keys be stored and recorded in a tamper-resistant memory area.

This application uses the blockchain recording unit 30DLR2 to make it possible to verify the continuity of the data in 30DLR2 even if the block data in the first blockchain is deleted or forgotten, because the hash value and characteristic data of the first blockchain are stored in the second blockchain. The explanatory diagrams of the blockchain recording unit 30DLR2 are shown in Figures 5, 6, 7, and 8, and the explanatory diagram of a system that uses 30DLR2 is shown in Figure 9.

<Function to erase some blocks>
The contents of blocks containing encrypted data are kept secret, and it is impossible to distinguish whether the contents are data that someone needs or data that has been accumulated through a DoS attack. Therefore, this application considers and devises a function to forget old blocks in the blockchain. The blockchain data structure of this application is proposed for distributed ledger technology that erases part of a data block (has the function to forget), but it can also be used for content data that can be detected by tampering and for storage of artificial intelligence.

<Use of 30DLR2 in artificial intelligence system 4 (Figure 9)>
-As artificial intelligence learns, the content it has memorized will be linked from the past to the future like a blockchain, making it possible for third parties to track the accumulation of data as the artificial intelligence learns.
(For example, when analyzing the learning process of artificial intelligence from the outside, learning data will be accumulated according to the block links of the blockchain, so it may be possible to verify which data block's learning results are contributing to processing improvements.)
- In addition, in the blockchain data structure 30DLR2 of the present application, data on the first blockchain may be forgotten from the node terminal 3A/system 4.
Even in the case of an AI based on a computer node 3A installed in transportation equipment or home appliances that have limited memory space and external communication, the processing system can forget data, and by forgetting, the memory space can be re-acquired and used for learning again.

<Example 3> Figure 10 shows an example of 30DLR2 in which the second blockchain section is equipped with a section that can record a balance list of each user for NFT/FT, digital assets, securities data, digital currency, and distributed ledger fee tokens for each specified number of blocks in the first blockchain. For example, even if block data in the first blockchain, in which data blocks are accumulated every minute, is lost, the second blockchain, in which data blocks are accumulated every hour, day, or year, records balance data for each of the aforementioned time periods, and transaction balances are backed up.

<Transaction type>
In the implementation of this application, the transaction type may be a UTXO-based transaction or an address/account-based transaction.
<Address/account-based transactions and use of account encryption>
When storing and distributing NFTs, NFTs with OTP functions, FTs, utility tokens, governance tokens, and security tokens, an execution environment that supports encryption such as the 30CVMU-HTMLJS is used to conceal the internal programs of the tokens, and the user identifiers, token numbers, and token holding relationships recorded in the smart contract are encrypted and concealed.

For example, it may be necessary to make it difficult for anyone other than the administrator to track who purchased NFTs, which are unique and irreplaceable, and to whom they were transferred.
・In the case of a stock registry-type smart contract, where a smart contract records the correspondence between user identifiers (names) and token numbers, such as a token holder register (or stock registry), and the number of shares is determined by counting the number of token numbers belonging to a user identifier, data A-CRPT, which is an encrypted version of the user identifier assigned to a certain token number, is recorded in the block data of the blockchain.
We propose to use an execution environment that supports encryption such as the 30CVMU-HTMLJS, a decryption key/encryption key, and the data A-CRPT to read and decrypt the block data recorded in the blockchain to obtain user identifier A, process which token number/ID user identifier A holds and to whom to send it, encrypt the processing result, write it to the (latest) block data of the blockchain, and handle the encrypted data.

<UTXO Transactions and Crypto Use>
In the present application, in a system using the 30CVM, 30CVMU, 30DLR, or 30DLR2, the transaction type stored in the 30DLR or 30DLR2 can be either the UTXO type or the account type, and is not limited. (*UTXO: Unused Transaction Output) The data structure may be a blockchain type or DAG type distributed ledger. A system using an encrypted data execution environment such as the 30CVMU may use the DAG type in addition to the blockchain type.

<Anonymity> In order to maintain the anonymity of data, a part of the information may be encrypted and concealed using the method of the first embodiment of the present invention (e.g., the user identifier of the token holder, the token ID, the balance, etc.).
The user's privacy is protected by encrypting and recording the user identifier of the token holder. User information is kept confidential when tokens are exchanged between different users or when tokens are assigned.

<Storage and Transfer> By operating the contract from a user terminal that manages the contract, a token with a certain token number can be removed from a certain user identifier A and assigned to another user identifier B, thereby transferring the token (storage transfer) while hiding the user identifier.
*The third embodiment may be a combination of the first and second embodiments.

<<Other matters regarding Example 1>>
<Confidentiality, Encryption, and Coding> This application relates to a method for partially encrypting, encoding, and concealing the blockchain portion or the ledger data portion of a distributed ledger system. Specifically, we propose the execution environment 30CVM/30CVMU that reads and executes encrypted data on the blockchain.
The execution environment 30CVM may include a means for decrypting encrypted data and a decryption key or a key input unit. The key may be input from the user terminal 1A or may be included in the execution environment 30PVM.

●In FIG. 3C, for example, when the execution environment (30CVMU) is included in the front-end part of the user terminal 1A (HTML, ECMAScript displayed and used in a web browser), the back-end part F3C3 (an environment in which programs written in PHP, Python, Ruby, etc. run, the systems of each service provider, and an environment based on a distributed ledger system) may be connected to the server terminal 3C or other servers 3A and 3D connected to the server terminal 3C. (In the figure, 3C is connected to 3A, and 3C calls the data of 30DLR.)

4B and 4C are specific examples claimed in this application.
For example, a method has been devised in which a smart contract as described in Patent Application No. 2021-004788 etc. calculates an OTP using a hash function and a key variable as its argument, in which a variable KC as a key value, a block number Bn as a variable that changes over time, and a token ID variable TIDA corresponding to the serial number of the generator that generates the OTP are substituted into a hash function fh to calculate fh(Bn, TIDA, KC), and the OTP is calculated.
In the present application, the key value during OTP calculation can be kept confidential by performing encryption (which may be post-quantum encryption, which will be described later).
- In addition, smart contracts are executed and variables and data are read using existing EVMs, etc., and then processed by 30CVM/30CVMU, so it is compatible with existing systems.

After encrypting the variable KC to CKC and recording the CKC in the blockchain,
The following procedure is devised as a method for reading the encrypted data and calculating the OTP with 30CVM/30CVMU.
(1) Read the following three variables from the blockchain section to 30CVM and 30CVMU.
1. variable Bn, 2. variable TIDA, 3. encrypted variable CKC (key CKC obtained by encrypting key KC)
(2) Decryption is performed by the execution units 30CVM and 30CVMU.
The variable KC (key CKC), which is the encrypted data 30DLR-CDATA, is
Decryption is performed using a decryption key (a decryption key stored in the front-end unit, a recording means, or a terminal 3A, a terminal 3C, a terminal 3D, etc.) to obtain a key KC (variable KC, data KC). (3) The variable Bn, the variable TIDA, the decrypted key KC, and the variable KC are input to the OTP calculation unit and calculated. The variable Bn, the variable TIDA, and the decrypted key KC and variable KC are input to the hash function and OTP calculation unit in the processing procedure of ECMAScript to calculate the OTP, and the calculation result and processing result (calculated OTP) are output to the storage device of the user terminal 1A. The calculation result (OTP) may be sent to a terminal that can communicate with the user terminal 1A, the server terminal 3C, and output. The output OTP may be printed on paper or the like using an output device, displayed on a display, and the output OTP (by an output method for communicating with a person, such as audio output, braille output, image output, etc.) may be confirmed by the user, written on a recording medium, or recorded on an NFC tag, or transmitted to another device by communication.

● Either symmetric key/shared key encryption or asymmetric key/public key encryption may be used for encryption. The decryption key 30CKEY (F3B5, F4B-9) may be an encryption key/decryption key used in post-quantum cryptography, or asymmetric key/public key encryption. Symmetric key/shared key encryption may also be used. Shared key methods include AES, and public key methods include ECDSA, RSA, etc.

In this application, quantum-resistant public key cryptography, which is one of asymmetric key cryptography and public key cryptography, may be used. (Quantum-resistant public key cryptography: A type of public key cryptography in which the cryptographic algorithm is designed based on problems that quantum computers are thought to have difficulty with.)
Among the post-quantum public key cryptography technologies, there is a method (CRYSTALS, etc.) that uses lattice problems. (CRYSTALS: Cryptographic Suite for Algebraic Lattice)
In this application, data recorded in a block of a blockchain may be encrypted using (lattice-based) asymmetric key/public key encryption using a lattice problem. Hash-based asymmetric key/public key encryption may also be used. (NIST has announced the lattice-based CRYSTALS-KYBER, CRYSTALS-Dilithium, FALCON, and hash-based SPHINCS+ methods as candidates.)

● In this application, the KC, which is the variable/data key for OTP authentication, and the CKC that encrypts it, are expected to have a small data size (for example, several times the amount of 32 bytes), and since the data volume of the key value is small, it is expected that the processing time for encryption/decryption using quantum-resistant cryptography will be short.

<<Other matters in Example 2>>
<Discarding data blocks after a specified period of time> In order to conceal transaction history and reduce ledger data, we propose a blockchain structure that can show the continuity of the blockchain even if some past data blocks are deleted after a specified time has passed. We propose a method that allows data blocks to be deleted, erased, or forgotten after a specified period of time has passed.
For example, we propose a blockchain structure that allows data blocks in the blockchain that are seven years old to be deleted (and cannot be referenced in plain text) while verifying the continuity from the genesis block to the latest block.

<Searching for data blocks after a specified period of time> We propose a virtual machine/execution unit that does not search for data blocks after a specified period of time. We propose a virtual machine/execution unit that searches/does not search for data blocks depending on the transaction frequency/usage frequency of accounts in a data block after a specified period of time. We propose a virtual machine/execution unit that searches/does not search for encrypted data blocks after a specified period of time.

<<Other matters in Example 3>> We propose a measure (1) for identifying the sender of concealed data, and a measure (2) for what to do when encrypted data accumulates and the ledger data increases.

(1) Adding address and other data to encrypted data Address information and identifier information 30DLR-CDATA-ADDRESS and information 30DLR-CDATA-ANNOTATION for handling encrypted data may be tagged and arranged/recorded in the encrypted data 30DLR-CDATA-BODY. 30DLR-CDATA-ANNOTATION may be related to the certificate data and verification data of the concealed/encrypted data 30DLR-CDATA-BODY, such as an electronic signature, a hash value, or a MAC.
*This application intends to conceal the internal variables and functions of the OTP generation contract for OTP authentication and the OTP authentication unit in Patent Application No. 2021-004788. However, the inventors do not intend to encrypt and hide the information of the contract creator.
For example, it would be preferable to store the contract address of the OTP generation token smart contract and the user identifier who deployed it (the user identifier of the contract owner) together with the encrypted data, and to store the identifier of the creator of the encrypted data and the encrypted data itself.

For example, a contract address, a contract deploy user address 30DLR-CDATA-ADDRESS, or other information for handling encrypted data 30DLR-CDATA-ANNOTATION may be placed immediately before the start portion identifier 30DLR-CDATA-PS of the encrypted data 30DLR-CDATA-BODY or immediately after the end portion identifier 30DLR-CDATA-PE of 30DLR-CDATA-BODY.
When searching within the ledger record section (30DLR, etc.), 30DLR-CDATA-ADDRESS and other information for handling encrypted data 30DLR-CDATA-ANNOTATION can be used as search keywords (so that a block or contract containing the desired encrypted data can be found by search), and the data in 30DLR2 may store a user identifier, contract address, hash tag, token name, etc. when handling tokens, etc.

(2) A method for verifying the continuity of blockchains using a first blockchain (main chain) and a second blockchain (a blockchain that summarizes the blockchain for each section of a specified block number). In FIG. 5 of the drawings, there is a first blockchain 30DLR2-1ST with a data block linkage interval of T1, and a second blockchain 30DLR2-2ND with a linkage interval of T2 that holds the hash values of each block data of 30DLR2-1ST, and the time relationship between T1 and T2 is T1<T2.
The 30DLR2-2ND has the feature of storing the hash values and characteristic data of each of the data blocks (m data blocks) of the 30DLR2-1ST included in a certain time T2.
●When the third blockchain 30DLR2-3RD has a connection interval of T3, and the connection interval of the even higher order mth blockchain 30DLR2-n is Tn, the time relationship is T1<T2<T3<...<Tn.

<<Claims>>
Claim 1: In a computer network system including a node 3A of a distributed ledger system using a blockchain, a user terminal U, and a network 20,
The computer network system includes a virtual machine 30PVM or an execution unit 30PVM that can read data stored in block data of the blockchain 30DLR or execute the data as a program after reading the data;
decrypting the encrypted data; and using data obtained by decrypting the encrypted data.
A program execution unit 30CVM or a program execution unit 30CVMU of a user terminal capable of executing a smart contract or a program;
A computer network system comprising:
Claim 2: A computer network system as described in claim 1, using a blockchain data structure 30DLR2, in which the blockchain data structure includes structures of a first blockchain and a second blockchain, and the blocks of the second blockchain include respective hash values of a specified number of blocks of the first blockchain.
Claim 3: The computer network system described in claim 2, having a feature in which information based on transaction data of the first blockchain or asset balance information based on the transaction data is recorded in a block of the second blockchain, having a feature enabling data encryption within the blockchain, and a feature enabling data of the first blockchain to be deleted.
Claim 4: A dynamic password authentication system using the computer network system according to claim 1.
Claim A: A data structure of a blockchain, the data structure including a first blockchain and a second blockchain in a blockchain portion, the data blocks of the second blockchain including respective hash values of a specified number of data blocks of the first blockchain.
Claim B: An artificial intelligence system having the feature of storing learning data for machine learning in the blockchain data structure described in claim A.

<Example 1> When using the data recording section of a public distributed ledger system, we provide a program/software that is difficult to tamper with and whose operation is kept confidential.
Programs for services can be executed using encrypted data, variables, and functions stored in the distributed ledger system in a form that is difficult to tamper with, protecting user privacy while also concealing and protecting program operation.
- Conceal and protect programs in OTP authentication services using a distributed ledger system.
Example 2: Data blocks can be deleted from the blockchain on demand.
In addition to being used as a distributed ledger system for exchanging existing tokens, it is envisioned that it will also be used for services that require a large amount of data to be stored but have a limited storage period, such as transaction history, product tracking data, and social networking applications.
- As the AI learns, it is possible to realize an AI that can forget data that is not in demand while preventing tampering with and forgetting data blocks that are in demand or specified.
- The learning data for machine learning will be stored in a blockchain format, and by linking it from the past to the future and learning from it, it may be possible for third parties to track the accumulation of data as the artificial intelligence learns.
<Example 3> Provide a program/software whose operation is concealed. In that case, the block chain unit, which is a recording medium, has a function to delete data blocks, suppressing the increase in the volume of transaction data for some assets or products, for example.
In addition, a balance certificate summarizing the transaction progress and balance in the data blocks of the first blockchain for a certain period in the past and a summary of transaction history can be stored in the second blockchain, which helps users check their assets and their progress.
- The balance certificate and summary of transaction history are stored in a second blockchain in a manner that makes it difficult to tamper with, thereby protecting the records of users' assets.

<Fig. 1 to Fig. 2>
1A User terminal, user computer 10A Storage device (including operating software such as basic software, browser, etc.)
10AKEY Private key information recording means (for accessing 3A's 30DLR)
11A Processing device 16A External storage device, external recording means 100 Storage device, 101 Processing device, 10WIR Internal wiring, bus 102 Communication device, 104 Input device, 105 Output device 20 Network, communication path, information transmission (distribution) path 3A Distributed ledger system node terminal, 3B Other node equivalent to 3A 30 Memory unit 31 Control unit / processing unit 3C Server, 3D Server (can be offline)
30CKEY: Encryption/decryption key information recording means *Tamper-resistant possible 30CVM/30CVMU: Second execution environment capable of decrypting encrypted data for user terminal 30UI: User terminal interface (browser, etc.)
30PVM: First execution environment for reading plaintext data 30DLR: Recording unit/ledger unit of distributed ledger system DLS, specifically, blockchain unit 30DLR-DATA: Data including encrypted data contained in 30DLR 30DLR-CDATA-BODY: Encrypted data body <Figures 3A to 3C>
30DLR-CDATA-ADDRESS (30DLR-CDATA-ANNOTATION) Identifier given to data including encrypted data (user identifier, contract address, etc. Identifier used when searching for data in a blockchain explorer, etc.)
30DLR-CDATA-PS: start of encrypted data, a portion that distinguishes the encrypted data from other data; 30DLR-CDATA-BODY: encrypted data body; 30DLR-CDATA-PE: end of encrypted data, the portion that distinguishes the encrypted data; 30DLR-PDATA: plaintext data (or other data);
F3B1 data input processing unit, F3B2 input data analysis unit (identification unit, detection unit, and analysis unit that distinguish encrypted data from other data. 30 DLR-CDATA-PS/PE detection unit)
F3B3 Decryption section, F3B4 Encryption key/Decryption key management section, F3B5 Key/Key calculation method storage section F3B6 Decryption key input means (e.g., obtains key from 1A, 16A, 3A, 3C, 30DLR, etc.)
F3B7 Private key etc. 30 DLR access means F3B8 Virus-resistant execution unit, F3B9 Decrypted data, F3B10 Memory unit, F3B11 Processing unit, F3B12 Processing result response, F3B14 Output processing unit, F3B15 Encrypted portion F3C1 Smart contract provision unit (Web application front end)
F3C2 Cryptographic Virtual Machine Execution Unit (CVM)
F3C3 30 CVM Management Unit (Backend, Server 3C, 3D, 3A side)
F3C4 Key data/key management section (tamper-resistant storage possible)
F3C5 Blockchain client software (node communication part)
30 DLR-C Blockchain data recording unit (or read ledger data including encrypted data)
<Explanation of Figs. 4B and 4C>
<<Figure 4B>>
F4B-1 Data group for input to web application, data for accessing DLS F4B-2 User private key F4B-3 Decryption key for application input, etc. F4B-4 Software for executing web application Data section Browser, 30 CVMU-W3J may be included F4B-5 Calculated OTP
F4B-6 Recording means (including printed matter and display surface)
F4B-7 Calculated OTP
F4B-8 Web application execution unit 30CVMU-HTMLJS (processing unit and storage unit of web browser)
Distributed web application data, 30CVMU-APP (ECMAScript format, OTP generation section)
F4B-9 Decryption key (Example: CKC decryption key)
F4B-10 Encrypted data decryption unit (may include a processing unit that distinguishes, identifies, selects, and selects encrypted data and plain data, and a processing unit that decrypts encrypted data.)
*
F4B-11 decoded data Example: Data KC obtained by CKC decoding, function fp obtained by Cfp decoding
F4B-12 plaintext data example: Bn, TIDA
F4B-13 Hash function fh (or one-way function fh, or procedure function for OTP calculation), fh argument example: fh (KC, Bn, TIDA)
F4B-14 function fp
F4B-15 OTP calculation unit F4B-16 <Process of generating OTP> Returns the calculated OTP as a return value F4B-17 30CVMU-APP-SIGN (certificate, digital signature, hash value), data related to means for detecting and verifying the correctness of web application data. Digital signature, HMAC, timestamp, etc. (e.g. hash value of 30CVMU-APP, etc.), 30CVMU-APP has 30CVMU-APP-SIGN if necessary.
*When 30CVMU-APP is distributed or transmitted to a user terminal or server via communication, the contents of the communication may be encrypted and made confidential. (In the case of electrical communication, for example, encrypted communication may be performed using SSL/TLS communication. In the case of communication, 30CVMU-APP (and 30CVMU-APP-SIGN) may be recorded on a recording means such as optical media, a magnetic recording device, or a semiconductor memory and sent to the user terminal and the user by mail.) When transmitting, 30CVMU-APP-SIGN may be attached to 30CVMU-APP.
F4B-18 User terminal 1A
F4B-19 Server 3C, 3D
F4B-20 DLS Node 3A
F4B-21 30DLR
The data block or smart contract includes encrypted variables CKC and A-CRPT, encrypted function Cfp, token number (NFT ID) TIDA, user identifier A, and block number Bn. (The token number (NFT ID) TIDA may be encrypted and recorded as the variable CTIDA.)
F4B-22 30PVM Plaintext Read Virtual Machine PVM. Example: Ethereum Virtual Machine EVM
F4B-23 30CVMU-W3J, a means of accessing a distributed ledger system. Example: API for accessing blockchain (Web3.js, etc.)
*30CVMU-APP and 30CVMU-APP-SIGN may have the same correspondence as the block data and hash value of the blockchain, and the 30CVMU-APP and 30CVMU-APP-SIGN may be placed in the storage device and processing unit of 1A by user 1A reading 30CVMU-APP, which is also a data block of the blockchain, and its hash value 30CVMU-APP-SIGN from the blockchain recording unit 30DLR of node 3A (3C).
※<Function fp> Example: Remaining procedure for calculating OTP from hash value <<Fig. 4C>>
F4C-1 Decryption key (Example: CKC decryption key)
F4C-2 Encrypted data decryption section F4C-3 Decrypted data KC. Example: Data KC obtained by decrypting CKC
F4C-4 Plain data. Example: Bn, TIDA, etc. F4C-5 Hash function fh. fh(KC, Bn, TIDA)
F4C-6 OTP calculation unit, OTP comparison verification authentication unit F4C-7 Stored variables and functions for authentication F4C-8 OTP comparison/verification, authentication unit F4C-9 OTP authentication input unit F4C-10 Input data at the time of authentication (token number TIDA, etc.)
F4C-11 30DLR-PDATA Example: Plaintext token number variable TIDA, plaintext block number Bn, etc. F4C-12 30DLR-CDATA Example: Encrypted key value CKC, encrypted data of user identifier A A-CRPT, etc. F4C-13 "API for block chain access (Web3.js, etc.)" or means for introducing or changing/updating "F4C-7 stored authentication variables and functions" into the terminal * F4C-15 (authentication terminal) in FIG. 4C can be either an online server 3C or an offline server 3D, and in the case of 3C, the authentication variable function can be called via the network using the API. (In the case of 3D, there may be a means for introducing F4C-7 from outside, recording it, and updating it.)
F4C-14 Web application execution unit 30CVMU-HTMLJS (processing unit and storage unit of web browser)
F4C-15 Authentication terminal Example: Terminal 1A, 3D, 3C. *3D may store the OTP calculation key and calculation procedure in advance. (To enable authentication even when offline)
F4C-16 User terminal 1C, server 3C
F4C-17 Application data Example: Application including ECMAScript OTP authentication part F4C-18 DLS, node 3A (including encrypted data similar to F4B-21 30 DLR)
F4C-19 User terminal F4C-20 Calculated OTP
F4C-21 Recording means F4C-22 Calculated OTP (may contain other information required for authentication)
F4C-23 Response or return value according to authentication result <Figure 5>
30DLR: Distributed ledger system tamper-resistant recording unit 30DLR1: Blockchain unit consisting of one blockchain unit 30DLR2: Blockchain unit consisting of two (two or more) blockchains claimed in this application 30DLR2-1ST: First blockchain (a1, a2, a3, ... an, e.g., block generation time every 5 seconds)
30DLR2-2ND Second blockchain (sA1, sA2, sA3, sAn, e.g., blocks are generated every 5 minutes or every 5 hours) *Second blockchain that includes the hash value of each block included in the specified number of blocks in the first blockchain 30DLR2-3RD(n) Third [or nth] blockchain (ssA1, ssA2, ssA3, ssAn [nsA1, nsA2, nsA3, nsAn], e.g., blocks are generated every 5 hours or every 5 years)
anh is the hash value anh of blocks a1, a2, a3, ..., an in the first blockchain (a1h to a6h in the figure)
and characteristic data or fingerprint of the block data of the first blockchain (a3d in the figure).
sAnh Hash value sAnh of blocks sA1, sA2, . . . sAn of the second blockchain (sA1h to sA2h in the figure)
sAnd characteristic data of the block data of the second blockchain ssAnh hash value of the block of the third blockchain ssAnh
30DLR2-SHA The part where the first and second blockchains share hash values (the part where the hash values between 1ST and 2ND are mutually recorded)
30DLR2-SHA-n Part of the second and third blockchains that share a hash value (part of the nth and n+1th blockchains that share a hash value)
30 DLR2-F (Forget-old-Block-Data) When block data of the first block chain is deleted 31 DLSC node client control unit/management unit 31 PVM execution environment control unit 31 ETC other control unit 31 DLR2
31DLR2-LINK data block linking unit 31DLR2-1ST2ND-LINK data block linking unit (data block linking processing unit for the first and second blockchains. Includes processing related to 30DLR2-SHA, which links block data and stores hash values in blocks by treating the two chains 30DLR2-1ST and 30DLR2-2ND as one chain)
31 DLR2-SHA 30 DLR2-SHA is calculated 30 DLR2-SHA is stored in 30 DLR2 31 DLR2-ETC Other control units (hash value calculation unit, continuity verification unit, consensus formation unit, etc.)
31 DLR2-1ST first block chain control unit 30 DLR2-1ST control unit (a1, a2, 23,...an)
31 DLR2-2ND second block chain control unit 30 DLR2-2ND control unit (sA1, sA2, sA3, . . . sAn)
31DLR2-N (when necessary) nth blockchain control unit <<deletion condition part>>
<Demand Department>
30BdFG-DEMAND Blockchain Demand Storage (when necessary) (including deletion requests and designation of data blocks with negative demand)
<Erasing section>
31BdFG: A part that makes it possible to erase block data (depending on demand or specified data) after a certain period of time (data utilization such as 30BdFG) In AI system 4, this is a part for storing frequently used data and block data 30BdFG: A program that makes it possible to erase block data after a certain period of time 30BdFG-VAR: Variables, thresholds, and data for erasure, or data that sets a certain period of time until erasure 30BdFG-EXCVAR: Variables, thresholds, and data that are exceptions to erasure (for a data block with a certain block number, the number of transactions is above a threshold (demand is present), etc. Or the number of user votes or accesses is above a threshold, etc.) In AI system 4, this is a part in the human brain that stores frequently used data. (This part may reproduce the part of the human brain where neurons are frequently used and memories remain strong.)
*It may be preferable to record the above-mentioned deletion condition portions 31BdFG, 30BdFG-VAR, 30BdFG-EXCVAR and the demand portions 30BdFG-DEMAND, 30BdFG-VAR, etc. in a recording section that is difficult to tamper with (or is difficult to tamper with but will be forgotten over the long term) such as a blockchain.
30 DLSC Node Client Software <Fig. 9>
4 Artificial intelligence system 4 CAR 4 Automobile 4 DRONE 4 Unmanned aerial vehicle 4 AGRI 4 Agricultural machine 4 Production 4 Production machine 4 ROBOT 4 Robot 4 SEVER 4 Server 4 IN Learning source, learning subject, or learning destination such as the Internet Communication destination 42 Communication device 44 Input device of 4 (mainly sensor)
4OUT: Result output by the artificial intelligence system 4 performing machine learning. Output response 45: Output device 41 of 4: Processing device 40 of 4: Storage device 30 of 4: DLR2: Blockchain recording unit (here, data inside the storage device 40)
30STUDY-DATA Learning data stored in the data section 30DLR2 of the storage device 4 30STUDY Machine learning section, software section 30DEMAND Data demand recording section for each block of learning data 31STUDY Machine learning processing section 31DEMAND-FORGET Section for saving or deleting learning data according to demand 31DLR2 Blockchain processing section 30DATA Other data <Fig. 10>
Txn transaction data (integer n=1, 2, 3, . . .)
TxnC encrypted transaction data (integer n)
UTXOn UTXO data (integer n)
UTXOnC Encrypted UTXO data (integer n)
NFTLIST User's NFT balance (latest balance proof data at the time of forming sA2)
USERBalanceLIST
UTXO ALL USER BALANCE LIST UTXO balance (latest balance proof data)
Account ALL USER Balance LIST Balance (latest balance certificate data)

Claims (2)

In a computer network system in which a user terminal (1A) as a node terminal and a node terminal (3A) of a distributed ledger system using a blockchain are connected via a network (20),
A computer network system, wherein the user terminal (1A) includes an execution unit (30CVM) capable of reading data stored in block data of a block chain unit (30DLR) of the node terminal (3A) and executing the data as a program, the data stored in the block data of the user terminal (1A) includes encrypted data, the execution unit (30CVM) has a key for decrypting the encrypted data, and the user terminal (1A) has an execution unit capable of decrypting the encrypted data using the execution unit (30CVM) and executing a program using data obtained by decrypting the encrypted data,
The node terminal (3A) records and stores both a first block chain part and a second block chain part in a storage device of the node terminal (3A), and a certain block data of the second block chain part contains each hash value of a designated number of block data of the first block chain part, the artificial intelligence system using a computer network system,
A machine learning method using an artificial intelligence system having the characteristic of storing learning data necessary for machine learning in block data of the first blockchain section or block data of the second blockchain section of the node terminal (3A) of the computer network system. The machine learning method of claim 1, further comprising a step of deleting the content recorded in the first blockchain.

Images