Digital postcard, digital mail system, and information processing system

Abstract

To make a postcard EM (postcard token) recorded on a block chain part coexist both in the case of emphasizing anonymity and in the case of being useful to specify a false caller of crime prevention.SOLUTION: An EM is stored in a block chain part 30DLR about a postcard data EM to be stored in block data of a block chain part of a node 3A. The data EM records / includes a digital signature part ETHCAS by a certificate derived from a user private key to be used in a block chain or a signature part CAPCAS by a certificate (e.g.: a certificate of an ID card and a private key) by the outside. The ETHACAS may form a circle of trust in the form of registering a registered user in a list through authentication between users.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] This application relates to a computer, computer system, computer network system, information processing system, program, etc., for providing digital postcards using a distributed ledger system. It also relates to a distributed SNS system. [Background technology]

[0002] For example, paper mail may be lost in a fire or damaged by rain, and the mail may not reach the intended user. Providing digital postcards is one possible solution to this problem, but if digital postcards are sent from a user terminal and a central server, data may be erased or tampered with due to mismanagement.

[0003] Therefore, we propose a postcard system using distributed ledger technology (DLT). For example, the digital postcard is assigned an individual token ID for each postcard data and each transaction in the form of a non-fungible token (NFT), and sender B of the digital postcard can issue the token to recipient A and send and assign the postcard data.

[0004] (Blockchain technology and blockchain networks such as those described in Non-Patent Document 1 are well known, and smart contract programs are stored in the data blocks of the blockchain. For example, NFTs can be assigned to users, dynamic code generation, and other processes can be performed.)

[0005] <Digital postcards> It is publicly known that non-fungible tokens (NFTs) can be issued and sent to specific user identifiers on a distributed ledger system / blockchain, but in this application we propose an information processing system (as a digital postcard system) that can hold message data (even short text) and issue the NFTs as one form of decentralized SNS.

[0006] <Verifying the identity of the sender of a digital postcard / user authentication> Distributed ledger technology creates a user identifier, public key account, and wallet from a private key. However, it may be necessary to verify whether the user identifier and wallet belong to an actual user. For example, private keys can be generated randomly, but they can be generated by a bot program rather than by human hands, and a machine user may be able to impersonate a human and send digital postcards or post on the system's SNS.

[0007] User authentication is necessary to prevent social media users from being AI bots, and to prevent topics on social media from being unintentionally created (or to provide data to determine whether a user is a bot). In this proposal, we propose a system that can authenticate the user identifier, public key account, and wallet for a user terminal that has a private key through face-to-face code authentication.

[0008] Specifically, an authentication code that can be generated by having a private key is generated based on the dynamic code generation and authentication unit 30APP-OTP-AUTH and outputted to the display device / output device of the user terminal of the person to be authenticated that has the private key (has access to the private key), and the authentication code is read by the authenticating user terminal to authenticate the user identifier of the person to be authenticated (and that the user terminal can generate a code for dynamic code authentication using the private key, and that it possesses and can use the private key). [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] Ethereum Whitepaper, https: / / ethereum.org / en / whitepaper / Summary of the Invention [Problem to be solved by the invention]

[0010] The problem to be solved by this application is to make it easy to check whether a user has been authenticated when decrypting and opening an encrypted message M in a digital postcard EM when providing the postcard. When building a postcard system in which sender information and a signature section of the postcard are attached, user authentication is necessary, and it is preferable to make it easy to perform face-to-face user authentication (user authentication at a facility counter such as a post office). Also, to provide an SNS that can be a short message or postcard style. Another issue is preventing digital mail from being tampered with or lost. For example, it is necessary to prevent mail from being lost due to fire or damaged by rain, preventing the mail from being delivered from the sender to the intended user. In the digital field, it may also be necessary to protect mail from being erased or tampered with due to data management errors. [Means for solving the problem]

[0011] In order to facilitate face-to-face user authentication and user authentication at facility counters such as post offices, user authentication and whitelist creation are performed according to the sequence shown in Fig. 6. In addition, the user authentication unit (program / smart contract), the authentication result, and the whitelist unit 30APPEM-WL based on the result 30DLR-LIST-AP are stored in the blockchain unit and are tamper-resistant and fault-tolerant. * Figure 1 is an explanatory diagram of a digital postcard EM. Figure 1 shows the memory unit EM of the data memory unit that constitutes the digital postcard. *The message data M stored in the memory unit EM of the digital postcard may be encrypted. The data M may be a mixture of plain text and cipher text. (When reproducing a letter mail in which a paper letter is stored in an envelope and sealed, using a digital postcard EM, M containing cipher text is required.) *The sender digital signature / electronic signature section CAS included in the memory section of the digital postcard may include the following (1) and (2): (1) ETHCAS, a signature using a private key based on the user identifier EOA, and (2) CAPCAS, an electronic signature / digital signature using a public / private digital certificate. The inclusion of the signature CAS makes it possible to identify, distinguish, and detect the sender / signer even if a dispute arises between the message sender and the message recipient.

[0012] * Figure 3 shows an EM selection unit, sorting unit, and selector unit 30APPEM-SELECTOR-WL-ACCOUNT for identifying, distinguishing, and detecting registered senders and signers. The selector unit 30APPEM-SELECTOR-WL-ACCOUNT uses the whitelist 30APPEM-UL / 30APPEM-WL to determine whether the postcard EM or postcard EM transaction is affixed with a digital signature ETHACAS by a user identifier / EOA registered in the list, sorts and sorts the postcard EM sent by the registered EOA, and may notify the addressee's user identifier that a postcard EM has arrived or mediate the viewing and downloading of the postcard EM. (The selector unit 30A PEM-SELECTOR-WL-ACCOUNT may be disposed in the node 3A or in the user terminal 1.) *The selector unit 30A EM-SELECTOR-WL-ACCOUNT may detect whether a signature unit that has been added to an authenticated whitelist is recorded in the EM. *Furthermore, for digital postcard data EM / data storage unit EM that does not include a signature CAS, a blockchain node unit that is not stored in the blockchain storage unit 30DLR of the blockchain unit may be included in the computer network system. The sender digital signature based on a public or private digital certificate as referred to in (2) above may have a memory and data portion that is unencrypted and has a readable digital signature based on the sender's digital certificate.

[0013] If CAPCAS is, for example, unencrypted and in plain text or signed data using a readable public digital certificate, the recipient can recognize and detect the sender's CAPCAS signature. If a sender encrypts a problematic message EVILM, stores it in M, and sends it to a recipient, and the recipient decrypts M using a key, sees EVILM, and wishes to protest, and makes a request to an investigative agency, it is expected that by presenting the above-mentioned signature CAPCAS to the investigative agency, it will be possible to identify, detect, and recognize the sender, making it easier for the agency to take action to resolve the dispute against the sender. Also, including a message with CAPCAS on a digital postcard EM may create responsibility when sending a message and give people time to think about whether they really should send the message.

[0014] Even if the electronic signature / digital signature section using a public / private digital certificate as described in (2) above is not provided, if the signature using an EOA as described in (1) is provided, data may be stored in the blockchain section. After a certain period of time (days, weeks, months, or years), the data may be deleted from the blockchain data section.

[0015] <Functions related to postcards and communications, payment functions, digital ID and account applications> The two-dimensional code authentication function using the authentication unit (30APP-STORESCAN, 30APP-OTP-AUTH) in the smart contract unit may provide face-to-face authentication, electronic payment, and new user invitation functions.

[0016] Digital postcards EM with CAPCAS·ETHACAS may include payment instruction data. For example, when a farmer sells rice grains and agricultural products produced by the farmer through alley sales or the like, the purchaser may be provided with instruction data MNYD (for example, a password granting the right to transfer the account, one-time password data) for transferring the balance of the purchaser's own account to the account of the selling farmer in data M. With the purchaser as the sender and the seller as the recipient, (further including a postcard·message regarding the purchase gratitude in data M,) it is sent, and the recipient may instruct the transfer of the account balance from MNYD of M of the received EM and make a payment.

[0017] <Application of payment function, digital ID·account in SNS and communication fields> In this proposal, due to the blockchain-based (private key type account), NFTs and digital goods used by users within the SNS are exchangeable. For communication such as giving a stamp that can be used as a postcard to the other party in the SNS or making a donation tip, an SNS using a private key may be used.

[0018] <Blockchain account authentication and signature by account> *CAPCAS is preferably an electronic certificate issued by a public or private organization. However, when CAPCAS is privately issued, it incurs costs to maintain. Also, when it is desired to avoid the need for signatures in daily communication between friends with a private key of a public (authentication level equivalent to a seal impression) public or private identity certificate (in the case of daily use), a simple electronic certificate and private key may be desired. Therefore, ETHCAS may be linked to the user at a location where actual users authenticate or at a location for authentication (such as in CVS, luggage collection scenes, identity confirmation mail, post offices, educational sites such as schools, and locations where ETHCAS keys are linked to student IDs or employee IDs). (It is grasped by linking that the owner of ETHCAS is not a bot and that ETHCAS is at least by an EOA authenticated by a certain person.) A digital postcard system may be configured that uses face-to-face code authentication and store-scan code authentication to verify the existence of each other's EOA and EOA private key, creates a whitelist of authenticated EOAs and users, and gives priority to displaying postcard EMs signed with the keys of EOAs on that list.

[0019] In this application, we attempt to implement the web of trust method in PGP (in which a signature is given to each other to guarantee that the public key is the legitimate owner. Even if it is the first time a public key is received, if it contains the signature of a trusted user, the public key is considered legitimate) using the blockchain's EOA and private key, a blockchain-based code authentication unit, a store-scan type face-to-face code authentication unit, an authentication smart contract, and a list of the results of face-to-face authentication (A-with-B). *ETHCAS may be provided using the PGP web of trust method, and CAPCAS may be provided using the S / MIME method using a separate third-party certificate.

[0020] *When using the web of trust method with blockchain, blockchain-based dynamic code authentication can be performed, private keys can be stored between users using the store scan method, and the authentication code read from the smart contract of the dynamic authentication code driven by the private key can be read and authenticated, allowing the terminal held by the user, the user, and the EOA to be authenticated between users.

[0021] For example, two users with user identifiers A and B read the codes displayed on each other’s devices and perform OTP authentication, and the result (A-with-B) that their EOAs (A and B) authenticated each other face-to-face is stored in the authentication contract. The postcard application APP-EM reads and records the result (A-with-B) recorded in the authentication contract, and then when postcard EM is delivered from B to A with ETHCAS signed with the private key of user identifier B, user A's application APP-EM determines from the result (A-with-B) that postcard EM with B's ETHCAS is a postcard within the whitelist (one that has been simply authenticated in person), and even if there is encrypted text inside EM, it decrypts it and displays it so that A can view it.

[0022] *Using the OTP generation contract and authentication contract described in Patent Application No. 2021-004788, a store-scan authentication code can be displayed and read between two smartphones or terminals, OTP authentication can be performed, and the user can be confirmed as a natural person and not a bot. An EOA list of users who have been authenticated in person can be formed using store-scan code authentication, and a user whitelist can be created by referring to this list. (As described in Patent Application No. 2021-004788, if the dynamic authentication code generation unit, which can be generated by having a private key, is included in the blockchain unit used in a digital postcard system, for example, the code generation authentication unit, code calculation unit, and calculation algorithm unit cannot be tampered with, and the calculation algorithm can be updated, which may eliminate the need to install an external server that generates and authenticates dynamic authentication codes.)

[0023] For example, face-to-face OTP authentication is performed when an inviter invites a guest, and the EOA of the authenticated user is recorded in the OTP authentication contract 30APP-OTP-AUTH (30APP-STORESCAN). A list of EOAs authenticated in face-to-face is formed using store scan code authentication, and a whitelist of users is created by referring to this list. (D1 in Figure 6 and Figure 2) Thereafter, for the authenticated user, a digital postcard application 10APPEM·30APPEM, a message M in a short text format that can be viewed by anyone, and a message SNS 30APPEM using a postcard that is not encrypted in plain text and a public ledger 30DLR are preferentially displayed.

[0024] We propose a memory unit for NFT-application postcards and an information processing system / computer system having said memory unit. In postal mail, letters and postcards are sent with a stamp attached. This proposed super app may also be able to send encrypted messages by consuming blockchain internal tokens (equivalent to ETH) instead of stamps. - A decentralized SNS for publishing short messages using published NFT postcards may be created. Unencrypted NFT postcards may be used like comments or tweets on the blockchain. If the blockchain does not have the ability to remove outdated NFT postcard data, the content of the NFT postcard cannot be tampered with and will remain, so postcard writers are advised to be careful. *NFT postcards can be encrypted and the decryption key given to some participants to view them. *SNS-specific chains can be divided into private consortium chains and public chains, and the private part can be constructed by encrypting internal messages in the public chain. *Real postcards require the sender's address to be written, and have the advantage that handwriting and fingerprints are recorded on mail. In order to prevent the postcard system of this application from becoming a communication tool for crime when there is no signature CAPCAS / ETHCAS, 10APPEM / 30APPEM may be configured to collect and track data such as the user identifier EOA, sensor values, device ID, and IP address of the user's terminal, after disclosing the data to be collected to the user and obtaining consent. *To prevent the postcard system proposed in this application from being used for criminal purposes, it is preferable to check whether the EM has a CAPCAS signature or a whitelisted ETHCAS, and if the CAPCAS signature or the ETHCAS signature included in the whitelist has been attached, the postcard viewing application 10APPEM performs processing to allow the EM to be viewed preferentially. (For example, if it is a newly arrived EM and it is unopened, it prompts the user to open and view it, and if there is encrypted data with AKTB inside, it prompts the user to input a separate AKTB, performs decryption processing, and allows the user to view it.) Or, to prevent its use for criminal purposes, EM that is not signed by an EOA listed on the whitelist or registered can be chosen not to be stored in the ledger unit 30DLR. In that case, 30APPEM-SELECTOR-WL-ACCOUNT detects whether the EM can be recorded in the ledger (i.e., whether it is an EM by a whitelisted net user), selects whether to store it in the ledger, and stores it if it is a net user. *In the postcard system of the present application, user terminals are authenticated between users through code authentication using a camera and scanner as shown in Figures 1 to 4, forming a web of trust / whitelist, and postcards with signatures based on the whitelist are given priority for viewing by the user. *The user terminal 1 may be equipped with a blockchain node app 30APPEM or a browser / front-end app unit 10APPEM, which is a control unit that erases, mutes, or prioritizes not allowing users to view NFTs without sender information.

[0025] Now, in the event of a disaster, communication of information via SNS and text messages can reduce data traffic more than audio and video. Therefore, SNS may be useful for communicating information between disaster victims. The postcard system of this application is intended to be a short text-based, decentralized, blockchain-based means of communication, but verification is required.

[0026] For example, in the event of a disaster on the ground, there is a risk that the power and communication networks between ground stations will be cut off. To counter this, it may be effective to provide a high altitude platform (HAPS) or a means of communication between a satellite constellation and user terminals (provision of a communication network). In addition, it would be preferable if user terminals could be charged by solar cells, electric vehicles, or automobile engine generators even in emergencies. If the power and communications mentioned above can be secured and the proposed postcard system can be used even in the event of a disaster, communication may be possible. Effect of the Invention

[0027] With regard to the digital postcard EM of the present application, if the sender is not anonymous but an authenticated user registered on a whitelist whose identity can be traced, and the message contains the signature of the authenticated user, then even if a problem arises at a later date, the sender can be traced from the signature or the EM user identifier, making it possible to resolve the dispute. In addition, the sender is responsible for the contents of the message because a signature section is required. On the other hand, this system allows messages to be sent anonymously, but since there is no signature section when the message is opened, the user can leave the EM unopened and decrypt it without opening it. In order to achieve both anonymity and security, a signature section is attached to the postcard EM, and users who have signed the postcard EM are registered on a whitelist. The EM, signature section, whitelist, user authentication program, and digital ID storage section can be stored in the blockchain section (node ​​section 3A), allowing for decentralized management by multiple organizations rather than a centralized system. This can reduce the cost per company and per user when managing the postcard EM, digital ID storage section, and computer network system, while providing resistance to tampering and fault tolerance. The proposed system uses a distributed ledger system, blockchain, and can store and keep data that needs to be protected from tampering, such as digital postcard EM, user authentication programs, and whitelists of authenticated users, on the blockchain. In addition, user identifiers in the blockchain can be authenticated by the authentication program section, whitelists can be created, and these can be used as digital ID wallets. (As a specific example, this will result in the effect of being able to sell stamp tokens and verify users using POS registers at transportation companies, communication companies, and post offices, or through employees' smartphone cameras and scanners.) The proposed digital postcard system will not lose data in fires or get damaged by rain like paper mail, and will be tamper-resistant and fault-tolerant due to the blockchain. When an EM is sent, a timestamp within the blockchain (a record of the block number at the time of sending) is automatically added (and stamps are used as stamp tokens, with postmarks on stamps being automatically created within the digital system), making it possible to provide digital postcards and letters. (Note that in this application, the key AKTB may be shared between users 1A and 1B by using paper correspondence. Existing postal services that can be used to send sealed paper letters may be used in this application when sharing a key for encrypting a message. *Paper mail has the advantage that letters can be sealed and sealed. If it is possible to provide similar confidentiality, it is acceptable to generate and prepare a key for quantum key distribution or a key for encrypting a message using public key cryptography. * The proposed system has not been determined to use post offices or postal infrastructure. The use of postal infrastructure is not limited to this system. The proposed system is an electronic communication system devised with the image of mail in mind, and has some differences from postcards that handle actual mail and paper documents. *For example, store scan-based user authentication (D1) is expected to be implemented at post office counters as an extension of existing postcard mailing, but it may also be implemented at delivery and home delivery company bases, convenience stores, ATMs, ticket gates, ticket-related devices, and counters installed in train stations, commercial facilities, and public facilities. *For example, the key AKTB may be stored in an envelope and sent using a delivery or courier service equivalent to letter mail. [Brief description of the drawings]

[0028] [Figure 1] An explanatory diagram of postcard data EM. On the left (A), the EM has the digital signature (HMAC, etc. can be used) part CAPCAS using an external digital certificate, and on the right (B), the EM has the key used for the blockchain part, the distributed ledger system, the signature using a digital certificate ETHCAS, and the user identifier. [Diagram 2] Diagram of a user and a computer. [Diagram 3] An explanatory diagram of the apps 30APPEM and 10APPEM. [Figure 4] FIG. 13 is an explanatory diagram of a storage unit for a list used to calculate a net available user list. [Diagram 5] An explanatory diagram of a node terminal 3A and a blockchain type data storage unit 30DLR. [Figure 6]An explanatory diagram of the sequence for user authentication of the addressee 1B from the sender terminal 1A and creating a whitelist via an authentication server 3A having an OTP / dynamic code authentication unit and a whitelist memory unit 30APPEM-WL, which may be recorded in a blockchain type memory unit. [Figure 7] An explanatory diagram of the sequence in which a digital postcard EM is transmitted from a sender terminal 1A to an addressed recipient 1B via a postcard server 3A that includes a blockchain-type memory unit. (The postcard server 3A also serves as a user authentication server and a server that stores the whitelist of EOA / account / digital ID.) DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] The information contained in a postcard EM is shown in Figure 1. A signature section CAPCAS / ETHCAS using the user's private key is provided on the postcard, allowing the sender to attach a signature and clearly express their intention to send a message, and this is used to distinguish that the postcard EM was sent responsibly. The postcard app verifies whether the signature is registered on a whitelist. In addition, just like existing paper postcards, the recipient's name, recipient's address, recipient's user identifier, the sender's name, sender's address, sender's user identifier, transaction ID, cost spent on the transaction, network gas fee, amount of stamp tokens, and the sending date when the transaction was sent to the blockchain can be written on the postcard. Figure 2 is an explanatory diagram of users and computers. It shows a sender user 1A, a recipient user 1B, and a blockchain node 3A that mediates between them (3A may also include individual services other than the blockchain, such as an online video distribution site). An example of face-to-face code authentication is shown in Figure D1 on the right side of Figure 2. In face-to-face code authentication, an OTP authentication code is generated by a blockchain-based smart contract, and the code is displayed and read by a store scan method. For example, according to the sequence diagram in Figure 6, user 1A authenticates user 1B by reading the code authenticated by 1B (A->auth->B). Then, authenticated users are recorded in a list (30DLR-LIST-AP, 30APPEM-WL, 30APPEM-UL), which is used to check whether ETHCAS in Figure 1 is an authenticated user identifier. 3 is an explanatory diagram of ledger unit 30DLR including EM and EM contained therein. It is also an explanatory diagram of how the EM is selected and sorted by whitelists 30APPEM-WL and 30APPEM-UL and 30APPEM-SELECTOR-WL-ACCOUNT and delivered to the user. It is also an explanatory diagram of applications 30APPEM and 10APPEM. Although not explicitly stated, 30APPEM and 10APPEM are provided with a processing unit and a storage unit for operating the application. Figure 4 is an explanatory diagram of how a user list is created. Authenticated users are transferred from list 30DLR-LIST-AP to 30APPEM-WL and then to 30APPEM-UL. Along the way, the net current user list 30APPEM-UL is created by combining information stored in the revoked user list 30APPEM-RL and the ETHCAS list / protection list 30DLR-LIST-CA-ET, which cannot be revoked without a signature from CAPCAS. 30APPEM-UL is transmitted to the selection unit 30APPEM-SELECTOR-WL-ACCOUNT. In addition, the registered user list or revocation list for CAPCAS is obtained from an external server, and the net current user list for CAPCAS 30CAPCAS-LIST is also stored in terminal 3A or user terminal 1 and transmitted to selection unit 30APPEM-SELECTOR-WL-ACCOUNT. FIG. 5 is an explanatory diagram of the node terminal 3A and the block chain type data storage unit 30DLR. FIG. 6 is a sequence diagram showing the process of user authentication using the store scan method. Figure 7 shows the sequence of events that occur when a digital postcard EM is transmitted from the sender to the intended recipient. EXAMPLES

[0030] <<User authentication>> FIG. 6 shows an explanatory diagram of the sequence for user authentication of the addressee 1B from the sender terminal 1A and creating a whitelist via an authentication server 3A having an OTP / dynamic code authentication unit and a whitelist memory unit 30APPEM-WL, which may be recorded in a blockchain type memory unit. In FIG. 6, in step S-PA1, user terminal 1B uses private key 10KEY held by 1B and user identifier B based on the private key, and accesses blockchain node 3A using the private key and identifier, and generates and calls up an authentication code (one-time password) using dynamic code authentication program 30APP-OTP-AUTH stored in ledger unit 30DLR of 3A. In the step of S-PA2, after S-PA1, a dynamic code (OTP) is generated by, for example, 30APP-OTP-AUTH, which is a dynamic code generation authentication program stored in the smart contract. For example, authentication code: authentication code 142845. In step S-PA3, after S-PA2, the authentication code acquired by terminal 1B and a series of software 30APP-STORESCAN for performing store scans on 1B, 3A, etc. are used to cause user terminal 1B to output the authentication code from an output device (for example, output in the form of a two-dimensional code / barcode on the display of 1B). As an example, D1-BRCD-DATA containing the authentication code is generated and displayed / output as data to be read by user 1A during store scan. For example, in S-PA3, a two-dimensional barcode containing the information authentication code / authentication data D1-BRCD-DATA="EOA user identifier: B. Authentication code 142845." is displayed on the display of terminal 1B. In this case, when exchanging business cards or authenticating the user name and user ID, the code may contain, for example, User name: Bob@3891..., or user information (user name, user ID / domain, user identifier, user's real name and address, telephone number, email address, affiliated organization, personal promotional comment, face photo, optional image and text of the business card) or business card information. In step S-PA4, terminal 1A, which reads the code by store scanning, reads the authentication code and authentication data D1-BRCD-DATA using an input device such as a camera or barcode scanner. (At this time, user A and user terminal 1A may be able to visually recognize user terminal 1B and user B to be authenticated, and may also be able to visually recognize and photograph their appearance. Data obtained when photographing the code of terminal 1B may be used for crime prevention purposes.) In step S-PA5, the authentication code contained in the read code D1-BRCD-DATA (e.g. authentication code 142845) is input to the code authenticity determination unit / code verification unit 30APP-OTP-AUTH contained in node 3A, where it is verified, and the result is obtained as a return value or response. In step S-PA6, after the operation of 30APP-STORESCAN·30APP-OTP-AUTH, if the authentication result is correct, the result (A->Auth->B) is Store in 30DLR-LIST-AP. In step S-PA7, 30APPEM-WL / UL is created using 30DLR-LIST-AP.

[0031] <<Postcard>> Figure 7 shows an explanatory diagram of the sequence in which a digital postcard EM is transmitted from a sender terminal 1A to an addressed recipient 1B via a postcard server 3A that includes a blockchain-type memory unit. In Fig. 7, S-POST1 is necessary when encrypting a message M of EM. A shared key or an asymmetric key is shared and held between users A and B. <1. Sending Postcard EM> S-POST2 secures the ETHCAS and CAPCAS used for the address and signature, the message M, the attachment or the destination for the attachment (such as the URL link to the destination such as IPFS or cloud storage, or the password for the file), the postage token required for the message, and launches the postcard software 10APPEM. In S-POST3, a postcard EM transaction is created. A digital signature is made in the ETHCAS section of the EM using user A's key ETHCASK, the sender section is written, and the recipient's user identifier B is written in the address section. *Also, in normal blockchain systems (such as Ethereum), the EOA user identifier of the transaction's destination and sender is automatically assigned to the transaction, so this part can also be considered as the addressee and sender information part. In S-POST4, a transaction is sent from 1A via the network to node 3A of the blockchain network, and is stored in the blockchain type storage unit 30DRL based on the consensus algorithm. <2. Receiving Postcard EM> In S-POST5, User B and User Terminal 1B access 3A to search and search for the EM sent in S-POST4 to see if it has arrived at their own account / EOA (just as paper mail goes around to collect mail from post office boxes / postboxes that they manage), or to inquire and request 3A to see if there is a new EM. *Although not shown in Figure 7, terminal 3A may have an app (email daemon, mailer software, webmail) that monitors new postcards and sends notifications to user 1B's email address, SMS, or smartphone, and notifies the user of the presence or absence of new mail in real time. A server or site that is a blockchain explorer may be configured to monitor whether a transaction related to the arrival of a new EM has been received for its own EOA, and thus notify the user of the presence or absence of new mail. Figure 7 shows an image of a user inquiring about the presence or absence of mail in a private mailbox, and collecting mail that has arrived. In S-POST6, the user side postcard application 10APPEM or the server side postcard application 30APPEM selects and reads the postcard EM in 30DLR in response to a user inquiry. In S-POST7, 10APPEM and 30APPEM check whether the digital signature CAPCAS and ETHCAS assigned to the EM and the sender's user identifier are recorded and registered in the whitelists 30APPEM-WL and 30APPEM-UL. If they are registered, the EM is displayed to user 1B as a signed EM that may be opened (hoping that the sender of the EM has signed the message M responsibly and is not a mischievous EM or bot's EM), and the EM is waited for to be opened and the message decrypted. In S-POST8, if the message M is encrypted, it is decrypted using the key AKTB. (Open the message) S-POST 9 outputs the content message M of the EM to the user (outputs it to the user's input / output device 12). It processes the EM so that it can display text and images on a display, read out messages aloud, and use images, videos, audio, and content data attached to or linked to the EM. *For example, a link to the cloud storage where a home video file is recorded, a hash value / digest of the file, and a login password for the cloud storage may be displayed or automatically linked to play the video file.

[0032] <*Other use cases> The postcard system of the present application and the digital ID system used for code authentication, which may be face-to-face with its EOA, may be effective in functioning not only for postal and correspondence but also as an identification card. For example, at a party or social gathering, users could scan each other's ID and contact information in a store-like fashion, reading and confirming authentication codes, which could be used for ID exchange, such as exchanging business cards. *In this application, user information (user name, user ID / domain, user identifier, user's real name and address, telephone number, email address, affiliated organization, personal PR comment, face photo, optional image / optional text on business card) or business card information exchanged by postcard may be exchanged according to the sequence shown in Fig. 6. The business card information may be stored as 10EOA-USERNAME-LIST / 10EOA-NAMECARD-LIST in the memory unit 10 of each user terminal 1 (1A and 1B). *Also, in the configuration of Fig. 6, it may be used as a terminal that reads an ID card and an ID card in addition to a business card. As ID card data (EOA's private key ETHCASK is kept secret in the ID card data, and for example, the key ETHCASK is stored in a tamper-resistant area and locked with a PIN or the like), the EOA identifier and name, address, date of birth, gender, and face photo (biometric characteristics that can be distributed) information 10EOA-IDCARD may be stored in the user terminal 1. Then, it may be a user terminal 1 or server 3A used for identity verification and ID management that reads and lists 10EOA-IDCARD and stores it in 10EOA-IDCARD-LIST·30EOA-IDCARD-LIST.

[0033] <Maintenance of the system's servers, communication network, and software> This invention consists of a communications network (wired infrastructure, wireless infrastructure, and frequency bands), servers, and user terminals, and it is necessary to maintain the network by inputting computer terminals, maintenance personnel, electricity, etc. to keep it running. In order to maintain this economically (for example, in the face of inflation due to natural disasters and war damage), we believe that it is appropriate for the nodes of this network and the network to be maintained by multiple corporations. *For example, the corporation may be a consortium of businesses including post offices, transportation companies, and information and communications companies (as well as simple post offices run by certified individuals or groups of individuals), and each group constituting the consortium may each share node 3A and maintain network 20 to constitute the computer network system 20EM for postcards of the present application. *This application uses a blockchain, but the data block linking consensus algorithm may be a known method such as PoS, PoA (Proof-of-Authority), istanbul BFT, or Raft. When PoA is used as the consensus algorithm, the internal tokens are assumed to be held initially by each organization, and then given to users as compensation for paying legal tender for postcards. (It is assumed that the internal tokens are given from each organization's EOA wallet to the user's user identifier EOA wallet as a means of payment, token, or coin for correspondence.)

[0034] <Circulation and consumption of internal tokens equivalent to stamps> *The proposed postcard system may be designed to consume fees, tokens, and digital stamps each time an EM is sent, just like paper mail. *To send a postcard EM transaction, an internal token must be obtained and consumed. The internal token may be transferred between user identifiers, for example, as a so-called fungible token, or may be procured from a part or place that issues new tokens. *Tokens can be given to node operators using PoW or the PoS method, which provides internal tokens, or they can be managed using the PoA method. *The proposed system has the feature that users cannot send postcard EM unless they obtain internal tokens from third parties (such as mining from the system or third-party users). Internal tokens are expected to be purchased from users at post offices, convenience stores, and second-hand dealers, for example. Stamp tokens may also be sold by credit card, etc. (In this case, token sales may also be conducted in the form of face-to-face code authentication and code payment, with the user terminal scanned by a scanner at the store's POS register, and the token may be given to the EOA scanned as payment. Stamp tokens may be sold at post office counters while verifying the customer through so-called code payment. Stamp tokens may be sold and given to EOAs registered on the whitelist by credit card.)

[0035] *Even if a user is a bot, anonymous, or whitelisted user, sending EM requires the consumption of an internal token (or an ERC20 token, for example, if such a token is created within an existing blockchain network such as Ethereum). * Depending on the design of 30APPEM or the distributed ledger system, if the addressee and other necessary information for postal delivery are written on the envelope, and a stamp or stamp token is consumed, the postcard or letter envelope may be delivered to the addressed user even if it is anonymous (sender unknown). However, it is up to the user to decide whether to open the envelope or not. After checking whether the EM has the signature section CAPCAS / ETHCAS, it is up to the user to decide whether to open an anonymous EM that does not have it. In this application, by including a store-scan type code authentication section that may be an OTP method, it is easier to register in a whitelist between users in person, and it is intended to make it easier to check the ETHCAS signature of the EOA registered in the whitelist and make anonymous EM difficult to see, or to make it easier to process when processing to warn the app 30APPEM that it is anonymous. The intention is to help distinguish whether an EM has a signature or not.

[0036] <Hardware configuration of the present invention> The computer configuration is shown in Figure 2. The computer, user terminal, and node terminal each have a control processing unit (11, 31), a memory unit (10, 30), and an input / output device or communication device (12, 32), and are connected to a communication path 20 and a communication network. As described in D1, for example, user terminals equipped with a camera (an example of an input device 14) and a display (an example of an output device 15) (users holding user terminals in their hands) can authenticate users by the store-scan method using the sequence described in Figure 6. Each terminal includes the five major devices of a computer and has a power supply, electric circuits, and buses. In the hardware of a typical smartphone terminal in this application, the control processing unit may be a system-on-chip SoC that may include a CPU, a GPU for graphic processing or a processor for AI processing, and a controller unit for IO and communication. RAM and ROM are used in the storage unit. NAND flash memory and SSDs are used as ROM or non-volatile memory. Wireless modems and wireless chips are used in communication devices, and in the case of server terminals, wired connections are also used. <Hardware configuration for store scanning> In D1, a camera or a display is used, but other devices may be used as long as they can perform user authentication equivalent to that in the example of D1. For example, a scanner, a handheld scanner, or a POS register scanner may be used instead of a camera. In D1, User A may be a human or an ATM device equipped with a camera, scanner, and display and capable of personal identification. It may also be a digital certificate of the official ID or an ATM device or ATM user terminal capable of data communication with the official ID, so that a correspondence list can be created between the official ID, its key CAPCASK, and the key ETHCASK or EOA on the blockchain. The ATM devices are installed in facilities such as convenience stores, post offices, stations, and government offices, and are assumed to be used by users in the city to register as users and register on whitelists using unmanned ATM devices. [Industrial Applicability]

[0037] A digital ID system using the postcard system of the present application and a user identifier used in the postcard system, which may be a face-to-face EOA code authentication and whitelist registration system, may be effective in functioning not only for postal and correspondence but also as an identification card. [Explanation of symbols]

[0038] <Figure 1> EM: Postcard data. In the present application, the postcard data EM is stored and recorded in a data block as multiple EMs in the blockchain-based recording unit 30 / memory unit 30 of the memory device 30 inside the node server 3A of the distributed ledger system / blockchain network. Address information RESU: EOA user identifier A, (address, name A). Address section of postcard Message M: Message data M or content data M. M can be a mixture of plaintext data and ciphertext data. Any type of data may be included in the message. For example, audio, image, and video data may be included. Content data such as audio and video may be stored in a different storage, and a link or access means to the storage may be recorded, or a hash value of the content data may be included in M. For example, message M may be a picture postcard or a digital postcard with video and audio, and for video data, the hash value and a link destination of the video data (or an identifier in a file distribution service such as IPFS) may be stored. The ciphertext data is decrypted or generated by encryption using a key such as AKTB. Sender information TRAU: EOA user identifier B, (address, name B), digital signature section. Postcard sender section Sender digital signature / electronic signature CAS: Example (1) Signature using EOA's private key ETHCAS (2) Public / private electronic certificate CAPCAS. For individuals, it is assumed that the electronic certifier on the Individual Number Card or any certificate issued by a public or private organization will be used, and for corporations, electronic certificates based on commercial registration, etc. may be used. Transaction cost, stamp token section: If necessary, the amount, gas amount, and fee for the transaction may be stored (corresponding to the stamp-sticking section of a postal item) Transaction ID, specific record tracking label section: This is the management ID when EM is used for one postcard correspondence transaction, and is the transaction ID when a user terminal in the blockchain sends a transaction to the Node 3A blockchain system. (Equivalent to the management ID section and label section for specific record and registered mail on mail) Figure 1 (A): Digital postcards with electronic signatures, digital correspondence EM, trusted postcards *Digital signatures are available using public and private digital certificates, and senders can be traced to prevent crime. Encryption text can also be installed. Figure 1(B): Digital postcard without electronic signature, for use on social media with some anonymity (*If the private key of the EOA can be generated randomly, an EM is sent from the anonymous EOA. On the other hand, since the message is anonymous and uncertified, it is unclear whether the sender of the EM is a real person or not. There is also the possibility of it being a bot. However, for purposes where a certificate cannot be attached, such as purposes where you want to send a message anonymously (such as anonymous word-of-mouth or whistle-blowing), the configuration of (B) may be necessary, so in this application, an EM with the configuration of (B) may also be used.) *In (A) of Figure 1, CAPCAS is used, which includes encrypted data in message M (similar to the state of a letter in paper mail when it is placed in an envelope so that it cannot be read by anyone other than the recipient). By doing so, even if EM contains an encrypted threat to recipient A, the CAPCAS of sender B is included in EM, so recipient A can be notified of the type of threatening letter that has been delivered via sender B's CAPCAS. *In this invention, postcards and letters with CAPCAS attached have the advantage that they cannot be tampered with in the blockchain and are saved and stored in the ledger while being given time information and a time stamp. *If the EM contains a CAPCAS / ETHCAS signature, the EM is stored on the blockchain, is difficult to tamper with, has a time stamp, and can be submitted as evidence to investigative agencies, making it more difficult for sender B to write threatening messages, etc., and it is expected that sender B will take responsibility for the message. On the other hand, as shown in (B) of Figure 1, postcard EMs may be stored anonymously on the blockchain without CAPCAS, but in that case, postcard viewing apps, etc. may warn users that there is a risk because the EM has no signature and the sender is unknown. *In addition, since the unsigned EM is anonymous, unsigned, and low importance data, the period for which it is recorded and stored in the ledger unit 30DLR of node 3A may be shortened, or it may be deleted or made inaccessible. <Figure 2> 1. User terminal, user computer 1A User terminal that wants to transmit EM and M data, postcard recipient user terminal 1B User terminal that creates EM and M data, signs using CAPCAS, etc., and sends to 3A, postcard sender user terminal 10 Storage device (including operating software such as basic software, browser, etc.) 10KEY: Private key information recording means (for accessing 3A's 30DLR) 11 Processing equipment 10CVM Execution environment in user terminal (including encryption and decryption of message M) 16 External storage device, external recording means 20 Networks, communication paths, information transmission (distribution) paths 3 Server (user terminal 1 may be the server) *1 or 1A, 3 or 3A computer, in which the storage devices 10 and 30, the processing devices 11 and 31, and the communication devices and input / output devices 12 and 32 are connected by electrical circuits, communication paths, buses, etc. 3A: A node terminal of a distributed ledger system; 3B: Other nodes equivalent to 3A 30 Storage section 31 Control and processing section 3C Server, 3D Server (may be offline) 30KEY Encryption / decryption key information recording means *Tamper-resistant is acceptable 30CVM·30CVMU An execution environment capable of decrypting encrypted data inside message M (using keys ETHACASK, 10KEY, 30KEY, or a slightly external key AKTB, etc., as encryption or decryption keys) 30 UI User terminal interface (browser, etc.) 30PVM The first execution environment for reading plaintext data 30DLR The record and ledger part of the distributed ledger system DLS. Specifically, the blockchain part CA: Digital signature, electronic signature key or certificate CAPCASK: Public / Private Digital Certificates / Private Keys (Public / Private Digital Certificates / Private Keys CAPKEY) CAPCAS: Digital signature by CAPCASK ECA: Electronic signature key or certificate for an EOA or a certain user identifier ETHCASK: EOA or a user identifier's private key (EOA or a user identifier's private key: ETHKEY) ETHCAS: Digital Signatures by ETHCASK AKTB: Optional password / key (a password that may be transmitted via a communication path other than the network 20, quantum cryptography communication, telephone, oral communication, sealed letter, mail, etc., and may be the decryption key AKTB of the encrypted message included in the EM.) D1: Example of face-to-face code authentication <Figure 3> 30APP-STORESCAN: Storescan format dynamic code authentication program (included in user terminal 1, server 3, and 3A) 30APP-OTP-AUTH: Dynamic code authentication program (may be a dynamic code authentication program using the blockchain smart contract disclosed in Japanese Patent Application No. 2021-004788) 30DLR: A storage unit of the blockchain system. A ledger unit. 30DLR may be a public type. For example, 30DLR included in server 3A may be viewed and data copied to user terminal 1 via a network. Also, because it is a public type, when a user stores EM in 30DLR, the user must encrypt part of the message of EM in order to conceal the contents of the postcard. *If encrypted data is always stored on the blockchain, there is a risk that it may be decrypted in the future if a computer with high computing power capable of breaking through the encryption appears, so it may be preferable to use a blockchain platform that deletes data EM on the blockchain that is more than 10 years old, for example. *It is preferable that the contents of the 30DLR can be partially deleted or forgotten according to demand or user request. A mechanism for deleting unnecessary 30DLR data may be provided in a system that uses the postcard EM of the present application. *It is a blockchain type, and the internal token KITT (postage stamp type token KITT) is consumed when recording EM to 30 DLR. The blockchain system node 3A sends a transaction to incorporate EM into the blockchain unit 30DLR by consuming the token KITT held by the user / user identifier, regardless of whether the signature CAPCAS or ETHCAS is present or whether the message M is encrypted (is it a personal letter message or a tweet on SNS?), and the EM is incorporated. *To prevent malicious EM and DOS attacks, only user identifiers who have purchased or obtained the internal token for sending digital postcards of the present application with economic value can send transactions including EM to the blockchain. (Internal tokens have the characteristic that they can be traced by tracing back the history of granting, exchanging, and transferring on the blockchain. Even if an anonymous user identifier X encrypts a message M and tries to send EM, it cannot be sent if there is no balance of internal tokens. X needs to obtain internal token gas by some means, and when obtaining it, X must have contact with the token holder. Tokens may be generated by giving authority to specific users, or they may be obtained as a reward for maintaining a node like PoW or PoS.) *In addition to internal tokens (internal stamp tokens), fungible tokens such as ERC20 type tokens may be used, or non-fungible tokens with individual images and face value data like paper stamps may be used. 30DLR-PLOPAL: A memory section of 30DLR that stores digital postcards EM, which may contain encrypted messages M. (Blockchain public ledger of postcards and letters) Regarding transactions stored in the data blocks of 30DLR-PLOPAL and 30DLR, and postcards EM and messages M contained therein, if M is not encrypted in whole or in part, its contents can be read by external users, and the fact that it has been read can be treated as a tweet or comment that can be viewed by all other users on the SNS. On the other hand, by encrypting message M with a key such as AKTB, the contents can be made confidential, just like sealing a postcard EM in an envelope. 30DLR-LIST-AP: A list storage unit for the correspondence between the authenticating party and the authenticated party in a dynamic code authentication program. (The storage unit may be stored as a data block in a blockchain or as list data in a smart contract.) 30APPEM-WL: Whitelist created from 30DLR-LIST-AP. In this case, revoked EOA and user identifiers cannot be counted, so the revocation list 30APPEM-RL below is also required. 30APPEM-RL: Revocation list of user identifiers. User identifiers are revoked depending on the presence or absence of a transaction signed by CAPCAS. It is preferable to store the correspondence between ETHCASK and CAPCASK in the ledger 30DLR in advance. (For example, if there is a private key CAPCASK-KAZ for a public certificate of a user named KAZ, it is preferable to store the correspondence between the public key CAPCAP-KAZ or its identifier and the public key ETHCAP-KAZ or identifier of the blockchain private key ETHCASK-KAZ. If the key ETHCASK-KAZ is leaked to a third party or needs to be updated periodically, a transaction to revoke the correspondence between the public key CAPCAP-KAZ and the public key ETHCAP-KAZ or identifier is stored in the ledger, and the revocation result can be read on 30APPEM.) *As for revoking a public key ETHCAP, it may also be possible to revoke it by collecting revocation designations from multiple EOAs / identifiers and requesting a revocation vote. 30APPEM-UL: Net whitelist, net user list. This list may be recorded in the same blockchain as 30APP-OTP-AUTH and 30DLR-LIST-AP. It may also be recorded in another blockchain network, or in a certain server 3A or user terminal 1. When recorded in 1 or 3A, it is preferable that the whitelist is provided with a digital signature or timestamp to prevent tampering. 30APPEM, 10APPEM: Demon software (guardian software) and resident program for digital postcards on user terminal 1, server 3, 3A, etc. 30APPEM-SELECTOR-WL-ACCOUNT: A part that selects whether or not the sender of a postcard EM is a postcard from a sender listed on the whitelist, or selects and allows the user terminal to view EMs that fall under the whitelist. (This is a part that prioritizes and transmits to the user digital postcard EMs whose senders are users listed on the whitelist / user list such as 30APPEM-UL when recipient A searches for postcards addressed to recipient A or requests postcard data acquisition.) 30CVM: Execution environment virtual machine software. It may include a decryption unit for the encrypted message M. The key AKTB may be used to decrypt M. 30APPEM-MAIN: Postcard viewing software, browser software. The main program for viewing postcards. 30-UI: User interface. It can be the UI of a browser software. 30APPEM-ETC:Other software, variables, functions, keys, etc. EX-CONTENTS: External link contents and attachments included in EM 30EOA-USERNAME-LIST: A list of user names, domain names, and user identifiers, similar to the list of domain names and IP addresses in the Domain Name System. As in the example of D1: Face-to-face code authentication, when user A scans user B and user B's terminal for code authentication, the list reads the user identifier and user name displayed on user B's terminal and records the correspondence. If the same user name is already registered in the list, it may be registered by adding the suffix of the user identifier, etc. Users may transfer and grant user names and domains to each other, as in the well-known domain name service system. D1-BRCD-DATA: Information contained in the authentication code exchanged between users when performing code authentication A->auth->B in scene D1 (e.g., EOA user identifier: B, user name: Bob@389, authentication code 142845) <Figure 4> 30 DLR-LIST-AP: A list storage unit for storing correspondence between the authenticating party and the authenticated party using the dynamic code authentication program. 30APPEM-WL: Whitelist. 30APPEM's whitelist WL or trust list TL, a list of authenticated users, LIST-AUTH-PAIR such as user A authenticating user B with a store scan. This may be recorded in 30DLR, or 30APPEM may refer to it from 30DLR and use it when the app is running. The list may also be copied or copied to 30APPEM. *The whitelist may be created by users interacting with each other, or may be confirmed by an organization or public office. For example, if there is an identifier P for an organization that handles postal and home delivery services, then user P, an employee of the organization, may go to the front door of each address for users AAA to FFF, perform a store scan of the user's device, and create a WL. Alternatively, when an address is changed, a store scan may be performed at a government office, and the user may be authenticated and added to the WL. Alternatively, user P of a government office, company, or organization may authenticate the user at the office and add the user to the WL. *Example explanation <wl>In this case, X's device has not been store scanned, so (X is <list-auth-pair>X is not on the whitelist WL (since it is recorded by the WL but not by any device that scanned X's device). 30APPEM-RL: Revocation list. A list of user identifiers for which revocation has been instructed and instructions for user identifiers that should be revoked. To revocation, a CAPCAS signature is attached using a certificate issued by a public or private third party, and the user who wishes to revoke the identifier sends a transaction requesting revocation to the identifier to be revoked. Alternatively, the user identifier (identifier C in the figure) managed by the service provider / organization that provides the postcard system at node 3A revokes the identifiers of the users that it wishes to revoke (B and D in the figure). *Alternatively, 30APPEM-RL may be programmed to revoke user identifiers registered in 30APPEM-WL after a specified time (several months, several years, 5 years) and automatically add user identifiers that should be executed over time. In the case of automatic revocation, the user may be required to generate a new user identifier and key before revocation, perform code authentication as described in D1, and register the key and EOA again in 30DLR-LIST-AP and 30APPEM-WL. *Even in the case of automatic revocation, it is also possible to use 30DLR-LIST-CA-ET and not revoke the EOA unless there is a CAPCAS-signed instruction. 30DLR-LIST-CA-ET: A list that associates CAPCAS and ETHCAS users. Or, a list / protected list of ETHCAS that will not be revoked unless ETHACAS and CAPCAS are linked by this list and a revocation command signed by that CAPCAS is received. A CAPCAS listed on this list is used when revoking the corresponding ETHCAS. (To revoke an ETHCAS that is not on this list, user identifier C, managed by the service provider / organization that provides the postcard system at node 3A, revokes the user identifier (B, C in the diagram) that is to be revoked. (In the diagram, for example, identifier C and its private key are accounts that can be used as administrators in postal organizations, public offices, etc.) 30APPEM-UL: Currently available net user list. Calculated from 30APPEM-WL, 30APPEM-RL, and 30DLR-LIST-CA-ET. The above three lists may be searched and calculated each time a user requests it, but in order to save computational and communication resources, it may be calculated periodically (for example, at 1:00 every day, once a month, once a year, etc.) and recorded as 30APPEM-UL in 3A or 30DLR. The calculation unit 30APPEM-UL may be accessed by the user. <Figure 5> 30A·31A: Memory unit and processing unit of a node terminal of a distributed ledger system 30DLR: Recording unit of distributed ledger system, 31DLR: Control unit and processing unit of distributed ledger system a1,a2,a3,a4,,,an: Block data a1,a2,a3,,,an a1h, a2h, a3h, a4h, anh: hash values ​​and digest data of data blocks a1, a2, a3, a4, an a1: Genesis block (a0h: Genesis block data) EM: Postcard data EM. This may be a block of data equivalent to one transaction sent from a user terminal to node 3A in a blockchain. EMs: A memory section that contains multiple postcard data EMs 30DLSC·31DLSC: Node client program storage section·control section management section 30PVM·31PVM: Program memory section of execution environment·Execution environment control section 30ETC·31ETC: Software for other control units·Other control units <Fig. 6> and <Fig. 7> are explained in Example 1.

[0039] <Document Name> Abstract <Summary> In a digital postcard system, a memory unit having a digital signature is provided to provide security, and a processing / control unit is provided that does not input postcard data EM that does not have the memory unit into the blockchain unit / ledger unit 30DLR, and a viewing unit is provided that is not visible to the user even after input, thereby protecting recipient users who view the postcard data. <Challenge> Regarding postcard data EM (postcard token, transaction) recorded in the blockchain, we would like to have both cases that emphasize anonymity and cases that are useful for identifying the sender for crime prevention coexist. <Solution> For postcard data EM to be stored in block data of the blockchain section of node 3A, EM is stored in the blockchain section 30DLR. The data EM is recorded and includes a digital signature section ETHCAS based on a certificate derived from a user's private key held in the blockchain, or a signature section CAPCAS based on an external certificate (e.g., certificate and private key of an ID card). ETHACAS may form a circle of trust by registering registered users in a list through authentication between users using, for example, blockchain-based two-dimensional code authentication. <<Claims>> <Claim 1> A computer network system including a communication path, a sender / sender user terminal, a recipient / receiver user terminal, a blockchain node terminal, a detection unit that detects the presence or absence of a sender / sender user signature attached to a message data / transaction, or a node terminal having said detection unit, and a selection unit that selects a message data / transaction with the sender / sender user signature, or a node terminal having said selection unit, The message data or the data transaction is stored in the block data of the blockchain unit of the blockchain node terminal, and the message data or the data transaction is stored in the block data of the blockchain unit of the blockchain node terminal. The ... Or, the transaction includes a signature part based on a private key for sending the transaction to the blockchain, a private key that is the basis of a blockchain user identifier, and a blockchain user identifier, The selection unit or a node terminal having the selection unit stores a list of authenticated user identifiers and electronic certificates corresponding to the private keys, and uses the selection unit to select message data and transactions signed by user identifiers and electronic certificates stored in the stored list, and transmits and allows the recipient and recipient user terminal user to view the message data and transactions. <Claim 2> The computer network system described in claim 1, wherein the list of authenticated user identifiers and electronic certificates corresponding to the private keys is created by performing a store scan between a sender / sender user terminal and a recipient / receiver user terminal, and the authentication code for the store scan is generated by a smart contract of a blockchain section stored in a blockchain node terminal. <Claim 3> The computer network system of claim 2, wherein the message data transaction includes an encrypted message M. <Claim 4> A computer network system as described in claim 3, wherein a key AKTB for decrypting and encrypting the encrypted message M is transmitted to a recipient and a recipient user terminal using a communication path via letter mail and envelope delivery.

[0040] Although the embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. < / wl>

Claims

1. A computer network system including a communication path, a sender / sender user terminal, a recipient / receiver user terminal, a blockchain node terminal, a detection unit that detects the presence or absence of a sender / sender user signature attached to a message data / transaction, or a node terminal having said detection unit, and a selection unit that selects a message data / transaction with the sender / sender user signature, or a node terminal having said selection unit, The message data or the data transaction is stored in block data of a blockchain unit of a blockchain node terminal, and the message data or the data transaction includes a signature part based on a private key of a public certificate, a third-party electronic certificate, or a private key for sending a transaction to the blockchain, a private key that is the basis of a blockchain user identifier, and a blockchain user identifier; The selection unit or a node terminal having the selection unit stores a list of authenticated user identifiers and electronic certificates corresponding to the private key, and uses the selection unit to select message data / transactions signed by the user identifiers and electronic certificates stored in the stored list, and transmits / allows the recipient / receiver user terminal user to view the message data / transactions.

2. The list of authenticated user identifiers and digital certificates corresponding to the private keys is It has the characteristic that it is created by performing a store scan between the sender / sender user terminal and the recipient / recipient user terminal, The computer network system according to claim 1 , wherein the authentication code for the store scan is generated by a smart contract of a blockchain section stored in a blockchain node terminal.

3. 3. The computer network system of claim 2, wherein the message data transaction includes an encrypted message M.

4. 4. The computer network system according to claim 3, wherein the key AKTB for decrypting and encrypting the encrypted message M is transmitted to the recipient / receiver user terminal using a communication path based on letter mail / sealed letter delivery.

Images