Information and communication device and information and communication program

Abstract

An information communication device is provided that can reliably send and receive only legitimate e-mails by properly adjusting the transmission cost required for sending e-mails. [Solution] The system includes an email sending unit 23 that sends email from one account to another account, a remittance control unit 27 that generates a remittance transaction to send virtual currency from one account to another account when sending email and broadcasts it to the blockchain 12, an email receiving unit 28 that receives email sent from the other account to the one account, a reception control unit 29 that, when receiving email, accesses the blockchain 12 to confirm the deposit status of virtual currency from the other account to the one account and receives the email as a legitimate email if the confirmed deposit amount is equal to or greater than a predetermined threshold, a refund control unit 31 that refunds the virtual currency when a legitimate email is received, and a threshold control unit 32 that adjusts the threshold according to the type of email received.

Description

[Technical field]

[0001] The present invention relates to an information communication device and the like that prevents spam attacks in e-mails. [Background technology]

[0002] Emails sent in large quantities to an unspecified number of email addresses (hereinafter referred to as SPAM emails) are a nuisance for email users. Users who send large quantities of SPAM emails (hereinafter referred to as SPAMers) send large quantities of SPAM emails to an unspecified number of email addresses for various purposes, such as advertising, distributing computer viruses, and fraud. As a result, according to a survey by the FBI (Federal Bureau of Investigation), the amount of fraud damage caused by SPAM emails in 2022 is estimated to be $2.7 billion (see, for example, Internet Crime Complaint Center, 2020 Internet Crime Report, pp. 3, 2021.).

[0003] In light of the above background, Patent Document 1 and Non-Patent Document 1 have been disclosed as technologies for combating SPAM mail. The technologies disclosed in Patent Document 1 and Non-Patent Document 1 include a mail sending unit that sends electronic data to other computers, and a remittance control unit that generates a remittance transaction for accessing a digital currency blockchain and broadcasts it to the blockchain, and as the mail sending unit sends electronic data, the remittance control unit generates a digital currency remittance transaction related to the electronic data and broadcasts it to the blockchain. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 6583841 [Non-patent literature]

[0005] [Non-Patent Document 1] K. Nakayama, Yutaka Moriyama, C. Oshima, An Algorithm that Prevents SPAM Attacks using Blockchain, 2018. Summary of the Invention [Problem to be solved by the invention]

[0006] In the technology shown in Patent Document 1, payment is made in digital currency when electronic data is sent. However, if the party receiving the electronic data does not properly set the sender's transmission costs required to receive the electronic data, problems may arise such as not being able to receive legitimate electronic data or receiving illegitimate electronic data such as spam or junk mail.

[0007] The present invention has been made to solve the above-mentioned problems, and aims to provide an information and communications device that can reliably send and receive only legitimate e-mails by appropriately adjusting the transmission costs required to send e-mails. [Means for solving the problem]

[0008] The information communication device of the present invention includes an email sending means for sending an email from one account to another account, a remittance control means for generating a remittance transaction for remitting the virtual currency from the one account to the other account when the email sending means sends the email, and broadcasting the remittance transaction to a blockchain, an email receiving means for receiving the email sent from the other account to the one account, a reception control means for, when the email receiving means receives the email, accessing the blockchain to confirm a deposit status of the virtual currency from the other account to the one account, and receiving the email as a legitimate email if the confirmed deposit amount is an amount equal to or greater than a predetermined threshold, a refund control means for, when the reception control means receives the legitimate email, generating a remittance transaction for remitting the virtual currency from the one account to the other account in an amount equal to the remittance transaction generated when the email was sent, in accordance with the virtual currency remittance transaction generated when the email was sent, and broadcasting the remittance transaction to the blockchain, and a threshold control means for adjusting the threshold depending on the type of the email received.

[0009] In this way, in the information and communications device of the present invention, an email is sent from one account to another account, and when sending the email, a remittance transaction for remitting the virtual currency from the one account to the other account is generated and broadcast to the blockchain, an email sent from the other account to the one account is received, and when receiving the email, the blockchain is accessed to confirm the deposit status of the virtual currency from the other account to the one account, and if the confirmed deposit amount is an amount equal to or greater than a predetermined threshold, the email is received as a legitimate email, and when the legitimate email is received, a remittance transaction for remitting the virtual currency from the one account to the other account in an amount equal to the remittance transaction generated when the email was sent is generated and broadcast to the blockchain, and the threshold is adjusted depending on the type of the received email, thereby achieving the effect of preventing the reception of unauthorized emails without interfering with the sending and receiving of legitimate emails. [Brief description of the drawings]

[0010] [Figure 1] 1 is a system overview diagram of a SAGABC system using an information communication device according to a first embodiment of the present invention. [Diagram 2] FIG. 11 is a sequence diagram showing an example of a processing procedure of a mailer in the SAGABC system. [Diagram 3] 4 is a diagram showing expected behavior when adjusting a threshold in the information communication device according to the first embodiment of the present invention. FIG. [Figure 4] 1 is a functional block diagram showing a configuration of an information communication device according to a first embodiment of the present invention. [Diagram 5] FIG. 11 is a diagram illustrating an example of information stored in a correspondence information storage unit. [Figure 6] FIG. 4 illustrates the process of a reception control unit. [Figure 7]4 is a flowchart showing a process when sending an e-mail (when remitting via MSC) in the information communication device according to the first embodiment of the present invention. [Figure 8] 4 is a flowchart showing a process performed when an e-mail is received in the information communication device according to the first embodiment of the present invention. [Figure 9] 5 is a flowchart showing a refund process in the information communication device according to the first embodiment of the present invention. [Figure 10] 1 is an NS chart showing an experimental model of an information communication device according to the present invention. [Figure 11] FIG. 11 is a diagram showing the number of SPAM mails received by general users of the conventional SAGABC system when the utilization rate of the SAGABC system is 50%. [Figure 12] FIG. 13 is a diagram showing the results of comparing the number of spam mails received by general users of the SAGABC system by changing the threshold reduction amount and increase magnification in the information communication device according to the embodiment. [Figure 13] A figure showing the average amount of virtual currency owned by general users and a threshold value in an information communication device in an embodiment. [Figure 14] FIG. 11 is a diagram showing the results of calculating and comparing (number of received spam mails) / (number of e-mails that can be sent simultaneously) in the information communication device according to the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] (First embodiment of the present invention) The information communication device according to the present embodiment will be described with reference to Figs. 1 to 10. The information communication device according to the present embodiment uses the SPAM Attack Guard Algorithm using Block Chain (hereinafter, referred to as SAGA) developed by the inventors. BC This system is called SAGA. BC The basic concept and system configuration are described in Patent Document 1 and Non-Patent Document 1 above.

[0012] SAGABC In this system, the cost of sending emails is mutually paid with virtual currency (digital currency) to prevent spam attacks. Generally, when a legitimate email is sent to a legitimate email address, the email is legitimately received, so the number of emails sent matches the number of emails received. On the other hand, many of the emails sent in large quantities by spammers to random addresses are not received legitimately. As a result, the number of emails sent by spammers does not match the number of emails received.

[0013] SAGA BC focuses on the difference between the number of emails sent and the number of emails received, and uses blockchain technology to pay the cost of sending emails with virtual currency, which is returned if the email is received properly. In other words, general users who send emails that are received properly do not incur any virtual currency costs from this system, but users such as spammers who send large volumes of emails that are not received properly must incur the cost of replenishing their virtual currency. As a result, it is possible to prevent spam attacks by spammers.

[0014] Here, the definitions of terms used in this embodiment are shown below. A "blockchain" is a type of distributed database, and data is stored in units called blocks in sequence. Each block records a hash value up to the previous block. This makes it difficult to tamper with data in a blockchain, since in order to tamper with data midway, it is necessary to calculate hash values ​​for all data following the block to be tampered with.

[0015] "Virtual currency" is a digital currency realized by blockchain technology. Commonly known virtual currencies include Bitcoin (Reference: S. Nakamoto, Bitcoin: A Peer-to-peer Electronic Cash System. 2008.) and Ethereum (Reference: GJ Wood, Ethereum: A Secure Decentralised Generalised Transaction Ledger, Ethereum project yellow paper, 151, pp. 1-32, 2014.), which have actual monetary value, but there are also many virtual currencies that have no value. Blockchain technology has made it possible to create virtual currencies that are difficult to counterfeit or replicate.

[0016] "Wallet" is a general term for a mechanism for managing virtual currencies. There are various types of wallets, from web wallets that store cryptocurrencies online to cold wallets that store cryptocurrencies on a device that is isolated from the network. Virtual currency users manage their virtual currencies in their wallets, and sending and receiving virtual currencies is carried out between wallets (Reference: A. Hayes, What factors give cryptocurrencies their value: An empirical analysis. 2015.).

[0017] A "wallet account" is an ID that identifies a blockchain wallet. Each user manages virtual currency through a unique wallet account. In Bitcoin and Ethereum, wallet accounts are created based on the public key used in public key cryptography. Virtual currency users manage their remaining virtual currency balances on a per-wallet account basis.

[0018] A "transaction" is cryptocurrency transaction data recorded on the blockchain. Generally, it is data that records a transfer from one wallet account to another. A transaction is issued when a wallet account that transfers cryptocurrency signs a transaction that describes its own wallet account and the destination wallet account with its own private key and sends it.

[0019] "Mining" is the process of compiling multiple issued transactions into one block that can be recorded on the blockchain and recording it at the top of the blockchain (Reference: M. Omri, A conceptual framework for the regulation of cryptocurrencies, U. Chi. L. Rev. Dialogue, Vol. 82, pp. 53-68, 2015.). By recording it on the blockchain, the transaction history is confirmed in an irreversible manner. It takes several minutes from the issuance of a transaction to its confirmation.

[0020] Next, SAGA BC The configuration of the system will be described. FIG. 1 shows the SAGA system using the information communication device according to the present embodiment. BC This is a system overview diagram of the SAGA system. BC System 1 comprises information and communication devices 10 (10a, 10b) used by users to send and receive e-mails via the Internet 13, a mail server 11 (mail sending server 11a, mail receiving server 11b) that manages the sending and receiving of e-mails used by each user, and a blockchain 12 of virtual currency exchanged between each user of information and communication devices 10a, 10b.

[0021] For example, when an e-mail is sent from an e-mail address set in one e-mail account used by one user as a sender to an e-mail address set in another e-mail account used by another user as a receiver, that is, when an e-mail is sent from the information communication device 10a to the information communication device 10b as shown in FIG. 1, the outgoing e-mail created by the information communication device 10a is sent to the information communication device 10b via the e-mail sending server 11a for the sender and the e-mail receiving server 11b for the receiver. This series of e-mail transmissions is performed by a general method, for example, via an SMTP server or a POP3 server. In the information communication device 10a, a remittance transaction of virtual currency is generated at the same time as the e-mail is sent, and is broadcast to the blockchain 12. The remittance transaction generated at this time indicates the remittance of a predetermined amount of virtual currency from the wallet of the sender, who is the user of the information communication device 10a, to the wallet of the receiver, who is the user of the information communication device 10b.

[0022] The information communication device 10b receives the e-mail (temporarily received at this stage) and accesses the blockchain 12 to check the deposit status of the e-mail, such as whether the virtual currency has been deposited in the user's wallet or whether the deposit amount is a predetermined amount or more. Only when the deposit status is appropriate, such as when the deposit is confirmed or when the deposit is more than a predetermined amount, the e-mail is received as a legitimate e-mail and displayed in the inbox. Note that when the deposit status is inappropriate, such as when the deposit is not confirmed or the deposit is less than a predetermined amount, the e-mail may be unconditionally discarded or moved to the trash, or may be displayed in the inbox once and then displayed in a manner that the recipient can understand that the e-mail does not contain any deposit of virtual currency (for example, an alert display, a highlight display, a display in a different color, etc.).

[0023] In the above, for the sake of clarity, one-way information communication has been described in which an information communication device 10a in which one account (one mail account and one wallet account) used by one user is set as the sender sends e-mail and transfers virtual currency to an information communication device 10b in which another account (another mail account and another wallet account) used by another user is set as the receiver, and e-mail is received and the deposit of virtual currency is confirmed by the information communication device 10b used by the other user. However, both the information communication device 10a used by the one user and the information communication device 10b used by the other user have the function of sending and receiving e-mail in both directions, and also have the function of transferring virtual currency and confirming the deposit, etc.

[0024] SAGA shown in Figure 1 BC In System 1, an email account for sending and receiving emails is linked to a wallet account for accessing the blockchain 12. SAGA BC In System 1, a wallet account is assigned to each email account held by an email client. In other words, the email client links the virtual currency wallet account to the email address set in the email account.

[0025] SAGA BC A unique virtual currency called MSC (Mail Send Coin) is created and used as the virtual currency implemented in System 1. This MSC is not intended to have monetary value, but is a virtual currency that is added when sending e-mail (transferred when sending e-mail, or refunded when receiving legitimate e-mail). Note that existing virtual currencies such as Bitcoin and Ethereum may be used as the MSC.

[0026] SAGA BCThe main functions of the system 1 are implemented in a mailer installed in the information communication devices 10a and 10b. A typical mailer is software for sending and receiving e-mail, and manages sending and receiving from one or more e-mail addresses. BC In system 1, a general mailer is used with SAGA as an extension. BC Implement the functions required for System 1. The main contents of the extended functions are specifically shown below.

[0027] (1) Account management function It has the function of managing wallet accounts corresponding to users' email accounts. (2) Account registration function It has the function of associating the hash value of an email address with a wallet account and registering it on the blockchain. (3) Account Verification Function When sending an e-mail, it has the function of verifying the wallet account corresponding to the destination e-mail address. (4) Incoming mail / deposit MSC support function It has the function of matching received e-mails with deposited MSCs, and the function of storing that data. (5) Spam filtering function Depending on the amount of the MSC deposit corresponding to each received email, the email can be displayed, sorted into the spam folder, or deleted. (6) Money transfer function It has the function of sending MSC from a wallet account corresponding to one's own email account, and the function of determining the amount to be sent (hereinafter, the amount of MSC to be sent). (7)Mining function When there is a shortage of MSC to send when sending an email, the MSC is replenished by mining transactions of MSC issued by many users. SPAMers can also replenish their MSC using this function, but this requires a lot of computational cost.

[0028] The process of the mailer described above is explained below. Figure 2 shows the SAGA BC This is a sequence diagram showing an example of a mailer processing procedure in the system. In FIG. 2, when sending an e-mail, the sending mailer issues a remittance transaction of the sending MSC amount from its own wallet account to the wallet account corresponding to the destination e-mail address. When the sending MSC amount sent from the mail sender is less than the receiving MSC threshold set by the receiving mailer, the receiving mailer classifies the e-mail as an invalid e-mail (e.g., SPAM mail, junk mail). When the sending MSC amount is equal to or greater than the receiving MSC threshold, the received e-mail is considered to be a valid e-mail (e.g., an e-mail to be confirmed / displayed / saved / replied with, etc.), and the MSC is returned to the sender's wallet account as it is according to the user's operation on the e-mail (e.g., delete / save / reply, etc.). For example, when an e-mail received as a valid e-mail is deleted or moved to a junk mail folder, the refund amount is set to 0. When the e-mail is opened and not deleted or moved to a junk mail folder for a certain period of time, the same amount as the sending MSC amount is returned to the sender's wallet account.

[0029] The sequence diagram shown in Figure 2 uses SAGA on both the sending and receiving sides. BC This shows the process when System 1 is installed. For example, only the sender is SAGA BC If System 1 is installed, the account confirmation function described above in (3) will confirm that the recipient (sender) is SAGA BC It is possible to confirm that System 1 has not been implemented (that a wallet account linked to the recipient's email address has not been registered). Therefore, in such a case, it is acceptable to send only a normal email without generating an MSC remittance transaction.

[0030] Also, for example, only the receiver is SAGA BCIf you have introduced System 1, you can use the (4) Incoming Email / Deposit MSC Response Function above to confirm that the MSC corresponding to the received email has not been deposited. Also, the (1) Account Management Function can confirm that the email account from which the email was sent is SAGA BC It is possible to confirm that the sender is not using system 1 (that there is no wallet account registered to the sender's email address). Therefore, in such a case, it is possible to process the email as a normal received email without being able to confirm that it is not an unauthorized email.

[0031] Furthermore, for example, both the sender and the receiver use SAGA BC If System 1 is not implemented, normal e-mail transmission will occur without the ability to verify that the e-mail is not malicious.

[0032] The above SAGA BC In the system 1, the cost of sending an e-mail is paid mutually by the MSC, but the important values ​​to be adjusted here are the sending MSC amount transferred when sending an e-mail and the receiving MSC threshold, which is the reference value of the MSC amount required to receive an e-mail as a legitimate e-mail. If these values ​​are inappropriate, problems such as legitimate e-mail not being delivered / illegal e-mail being delivered may occur, so it is necessary to introduce an algorithm to adjust these values. In this embodiment, of the sending MSC amount and the receiving MSC threshold, only the receiving MSC threshold is focused on. The reason for this is that the sending mailer can check the receiving MSC threshold before remittance, as described later, and there is no benefit in remittance of virtual currency exceeding the threshold.

[0033] In the information communication device 10 according to the present embodiment, the reception MSC threshold is adjusted by the algorithm shown in the following formula (1). This algorithm is a congestion control algorithm for avoiding and mitigating congestion in TCP, called SAGA. BCThis is applied to System 1, and is based on Additive-Increase / Multiplicative-Decrease (AIMD) (YR Yang, SS Lam, General AIMD congestion control, 2000) control in Loss-based congestion control (Dah-Ming Chiu, Raj Jain, Analysis of the increase and decrease algorithms for congestion avoidance in computer networks, 1989.). This is a control method that additively increases the congestion window size until packet loss occurs, and then multiplicatively decreases the congestion window size when packet loss occurs.

[0034]

number

[0035] As shown in formula (1), the receiving MSC threshold is additively decreased until an inappropriate e-mail such as a spam mail is received, and the receiving MSC threshold is multiplicatively increased when a spam mail is received. That is, the receiving MSC threshold b at time t is d For (t), the received MSC threshold b updated at time t+1 d (t+1) will be the value shown in formula (1). When the receiving MSC threshold is adjusted according to the algorithm of formula (1), the behavior will be as shown in Figure 3. As a result of adjusting the receiving MSC threshold, the sending MSC amount (MSC amount sent when sending an e-mail) will also change accordingly.

[0036] Fig. 4 is a functional block diagram showing the configuration of an information communication device according to this embodiment. First, the process when sending an e-mail will be described. In Fig. 4, the information communication device 10 includes an input / output unit 21 that inputs and outputs information in response to an operation of the sender of the e-mail, an outgoing e-mail creation unit 22 that creates an e-mail to be sent in response to the input operation, an e-mail sending unit 23 that sends the created e-mail to be sent to the e-mail sending server 11a, a correspondence information storage unit 24 that stores the respective e-mail addresses of the sender and the recipient (the e-mail address of the sender who is the sender and the e-mail address of the recipient who is the recipient) in association with a wallet account, a private key storage unit 25 that stores a private key required as a signature when accessing the blockchain 12, and a wallet account setting unit 26 that sets the wallet account of the recipient of the outgoing e-mail so that the outgoing e-mail is received as a legitimate e-mail. and a remittance control unit 27 that reads out the wallet accounts of the sender and the recipient stored in the correspondence information storage unit 24 from the email address of the sender who is the sender of the outgoing email and the email address of the destination who is the recipient, generates a remittance transaction for remitting an amount of sending MSC equal to (or greater than) the receiving MSC threshold from the sender's wallet to the recipient's wallet, and also signs the generated remittance transaction using private key information stored in the private key storage unit 25 and broadcasts it to the blockchain 12. These components function in the process of sending an email.

[0037] Here, the processing of the remittance amount confirmation unit 26 and the remittance control unit 27 will be described in more detail. The remittance amount confirmation unit 26 makes an inquiry to the blockchain 12 to confirm the reception MSC threshold set in the wallet account corresponding to the destination email address of the recipient when sending an email, and acquires the reception MSC threshold. As described above, the reception MSC threshold is a threshold set on the recipient side, and if the amount of the transmission MSC remitted from the sender side is less than the reception MSC threshold, it is classified as an inappropriate email (junk mail, SPAM mail, etc.), and if it is equal to or greater than the reception MSC threshold, it is a standard value for determining that the received email is a legitimate email. The remittance amount confirmation unit 26 compares the acquired reception MSC threshold with the amount of MSC held in the sender's wallet, and if the amount of MSC held is less than the reception MSC threshold, it passes information to the remittance control unit 27 that the MSC cannot be remitted. If the amount of MSC held is equal to or greater than the reception MSC threshold, it passes information on the acquired reception MSC threshold to the remittance control unit 27.

[0038] The remittance control unit 27 performs a remittance process of the MSC from the wallet of the sender to the wallet of the receiver according to the information received from the remittance amount confirmation unit 26. FIG. 5 is a diagram showing an example of information stored in the correspondence information storage unit 24. In the correspondence information storage unit 24, email addresses, which are identification information for identifying each of the sender and the receiver of the e-mail, and wallet accounts, which are identification information required for accessing the blockchain 12, are stored in a one-to-one correspondence. When the remittance control unit 27 receives information from the remittance amount confirmation unit 26 that the MSC cannot be remitted, the remittance control unit 27 does not perform the remittance process. When the remittance control unit 27 receives information on the reception MSC threshold from the remittance amount confirmation unit 26, the remittance control unit 27 performs a remittance process of the amount equal to the reception MSC threshold. Specifically, the remittance control unit 27 extracts the corresponding wallet account from the email address of the sender of the transmission email created by the transmission email creation unit 22. In addition, the remittance control unit 27 extracts the corresponding wallet account from the email address of the destination, which is the receiver of the transmission email. Using these wallet accounts, the remittance source wallet account and the remittance destination wallet account are identified, and a remittance transaction is created in which the remittance amount is equal to the reception MSC threshold.

[0039] Then, when a remittance transaction is created, the created remittance transaction can be broadcast to the blockchain 12 by signing it with the private key information stored in the private key storage unit 25, and remittance information (remittance history) can be written to the blockchain 12. Since it is extremely difficult to tamper with the blockchain 12, the remittance information written here becomes highly reliable and can function as the value of the sent email.

[0040] Next, the process when receiving an e-mail will be described. In FIG. 4, the information communication device 10 includes a mail receiving unit 28 that receives an e-mail sent to the recipient from the mail receiving server 11b, a reception control unit 29 that reads out the wallet account corresponding to the sender's e-mail address from the corresponding information storage unit 24 from the e-mail received by the mail receiving unit 28, and queries the blockchain 12 to confirm the presence or absence of an MSC remittance from the sender and / or the remittance amount, and a received e-mail processing unit 30 that displays the received e-mail as a legitimate e-mail if there is an MSC remittance from the sender or if the remittance amount is equal to or exceeds the received MSC threshold, and otherwise performs a process such as discarding the received e-mail as an unauthorized e-mail. These configurations function in the process when receiving an e-mail.

[0041] Each processing unit will be described in more detail. FIG. 6 is a diagram showing the processing of the reception control unit 29. As shown in FIG. 6, the reception control unit 29 extracts the corresponding wallet account from the email address of the sender who is the sender of the email received by the email receiving unit 28. At the same time, it extracts the wallet account from the recipient's own email address which is the destination of the email. From these extracted wallet accounts, an inquiry is made to the blockchain 12 to confirm the deposit status of the MSC from the sender's wallet account to the recipient's own wallet account. Information on the confirmed deposit status is passed to the received email processing unit 30 together with information on the received email.

[0042] The received mail processing unit 30, which has received the information about the e-mail and the information about the deposit status, performs predefined processing (for example, displaying the e-mail in the inbox normally, displaying the e-mail in the inbox together with information about the deposit status or the amount of the deposit, discarding the e-mail in the trash, discarding the e-mail completely, processing the e-mail as spam, etc.) according to the deposit status (whether or not a deposit has been made, or whether or not a deposit of a predetermined amount or more has been made). The processing of the received mail processing unit 30 may be defined according to the amount of the deposited MSC. For example, the e-mail may be sorted into different folders according to the amount of the deposit, or a highlighted display may be displayed if a deposit of a predetermined amount or more has been made, and a normal display may be displayed if the deposit of less than the predetermined amount has been made. In this way, if there is an urgent matter, it is possible to encourage the user to check the e-mail as a priority by sending a larger amount of MSC.

[0043] Next, the process of refunding when an e-mail is received will be described. In Fig. 4, the information communication device 10 is equipped with a refund control unit 31 that generates a remittance transaction for remitting the MSC from the wallet account of the destination (recipient) to the wallet account of the sender (sender) in order to refund the MSC deposited when the e-mail is received, according to the process contents of the received e-mail executed by the received e-mail processing unit 30 and the operation contents performed by the recipient at the input / output unit 21, and signs the generated remittance transaction using the private key information stored in the private key storage unit 25 and broadcasts it to the blockchain 12, and a threshold control unit 32 that calculates the received MSC threshold based on the algorithm of the above-mentioned formula (1), and broadcasts it to the blockchain 12 for updating.

[0044] The refund control unit 31 performs a process of refunding the MSC deposited when the e-mail is received, depending on the process performed by the received e-mail processing unit 30 on the received e-mail and the operation performed by the recipient at the input / output unit 21. Specifically, for example, if the received e-mail is determined to be a SPAM e-mail (unauthorized e-mail) by the standard functions of the mail server or mailer and is discarded by the received e-mail processing unit 30, no refund process is performed. Also, if the e-mail is received as a legitimate e-mail and displayed in the inbox, but the recipient does not operate the input / output unit 21 and does not refer to the contents, or refers to the contents but ultimately discards them, no MSC refund is performed. If the recipient ultimately refers to the contents of the received e-mail and saves them, or creates and sends a reply e-mail to the received e-mail, a process of refunding all the MSC deposited at the time of reception is performed.

[0045] The refund process by the refund control unit 31 is similar to the remittance process performed when sending an e-mail, and the refund control unit 31 accesses the correspondence information storage unit 24 and extracts a wallet account from the email address of the sender who is the sender of the received e-mail. A remittance transaction (hereinafter referred to as a refund transaction) of the refund amount determined above is generated from the recipient's own wallet account, which is the destination of the e-mail, to the sender's wallet account, and is signed with the private key information stored in the private key storage unit 25. The generated refund transaction is broadcast to the blockchain 12 to execute the refund process. Note that when a refund process occurs, the sender may be notified of the occurrence.

[0046] The threshold control unit 32 calculates the reception MSC threshold at the timing when the refund control unit 31 judges whether to perform the refund process. Specifically, the reception MSC threshold is calculated according to the above formula (1). When the refund process is performed, that is, when a legitimate e-mail to be displayed or confirmed is received, the reception MSC threshold is decreased by subtracting a predetermined value. On the other hand, when the refund process is not performed, that is, when an unjust e-mail that is not even displayed in the inbox, or an e-mail that is received but the contents of the e-mail are not displayed / confirmed, is received, the reception MSC threshold is multiplied by a predetermined value to increase it. Information on the calculated reception MSC threshold is broadcast to the blockchain 12 by the threshold control unit 32 and managed on the blockchain 12.

[0047] By adjusting the receiving MSC threshold, the more spam mail is sent, the higher the receiving MSC threshold set by the recipient will rise exponentially, which increases the sending cost for the spammer, and ultimately reduces the amount of spam mail.On the other hand, for non-spammers who use regular email, the MSC values ​​they possess do not fluctuate significantly, and the receiving MSC threshold gradually decreases, allowing them to send and receive emails stably.

[0048] Next, the operation of the information communication device according to this embodiment will be described. FIG. 7 is a flowchart showing the process of sending an e-mail (MSC remittance) in the information communication device according to this embodiment. In FIG. 7, first, the sending e-mail creation unit 22 creates a sending e-mail in response to the operation of the input / output unit 21 performed by the sender (S1). The e-mail sending unit 23 sends the created sending e-mail to the e-mail sending server 11a (S2). At the same time that the sending e-mail is handed over to the e-mail sending unit 23 in S2, the remittance control unit 27 receives the e-mail address of the destination, which is the recipient of the sending e-mail (S3). The remittance control unit 27 accesses the correspondence information storage unit 24, and extracts wallet accounts corresponding to the respective e-mail addresses from the e-mail address of the destination, which is the recipient, and the sender's own e-mail address, which is the sender (S4). The remittance amount confirmation unit 26 queries the blockchain 12 to obtain the receiving MSC threshold set on the recipient's side (S5), and compares the MSC amount held by the wallet account on the sender's side with the receiving MSC threshold (S6). If the amount of MSC held is less than the receiving MSC threshold, the sending process ends with the MSC not yet remitted. If the amount of MSC held is equal to or greater than the receiving MSC threshold, the information on the received MSC threshold is passed to the remittance control unit 27.

[0049] When the remittance control unit 27 receives information on the received MSC threshold, it generates a remittance transaction for remitting the MSC from its own wallet account as the sender to the wallet account of the destination as the receiver (S7). It reads private key information from the private key storage unit 25 and signs the generated remittance transaction (S8). Then, the generated remittance transaction is broadcast to the blockchain 12 (S9), completing the e-mail transmission process.

[0050] FIG. 8 is a flowchart showing a process when an e-mail is received in the information communication device according to the present embodiment. In FIG. 8, first, the e-mail receiving unit 28 receives an e-mail from the e-mail receiving server 11b (S1). The reception control unit 29 receives the e-mail address of the sender of the received e-mail (S2). The reception control unit 29 accesses the correspondence information storage unit 24 and extracts wallet accounts corresponding to the respective e-mail addresses from the e-mail address of the sender as the sender and the e-mail address of the recipient as the destination (S3). The reception control unit 29 queries the blockchain 12 about the deposit status of the MSC from the wallet account of the sender as the sender to the wallet account of the recipient as the destination (S4). The reception control unit 29 judges whether the deposit amount of the MSC is equal to or greater than the reception MSC threshold set by the reception control unit 29 (S5), and passes the judgment result to the reception e-mail processing unit 30. When the reception e-mail processing unit 30 receives the judgment result that the deposit amount of the MSC is equal to or greater than the reception MSC threshold, the reception e-mail processing unit 30 executes a process to display the received e-mail as a legitimate e-mail (S6). If a determination result is received that the amount of the deposited MSC is less than the received MSC threshold, the received e-mail is treated as an unauthorized e-mail and processing is executed so that the e-mail is not displayed (S7), and the e-mail reception processing is completed.

[0051] FIG. 9 is a flowchart showing the refund process in the information communication device according to the present embodiment. In FIG. 9, first, the refund control unit 31 receives the processing mode of the received mail processing unit 30 or the processing mode of the input / output unit 21 in the process when receiving an e-mail (S1). The refund control unit 31 judges whether the received processing mode is the processing mode when a legitimate e-mail is received (S2). If the refund control unit 31 judges in S2 that the received processing mode is the processing mode when a legitimate e-mail is received, it sets the refund amount to an amount equal to the MSC deposited when the e-mail is received (S3). On the other hand, if the refund control unit 31 judges in S2 that the received processing mode is not the processing mode when a legitimate e-mail is received, it sets the refund amount to 0 (S4). Also, if the threshold control unit 32 judges in S2 that the processing mode received by the refund control unit 31 is the processing mode when a legitimate e-mail is received, it reduces the receiving MSC threshold by subtracting a predetermined value (S5). On the other hand, if the refund control unit 31 judges in S2 that the processing mode received by the refund control unit 31 is not the processing mode when a legitimate e-mail is received, it increases the receiving MSC threshold by multiplying it by a predetermined value (S6).

[0052] The refund control unit 31 accesses the correspondence information storage unit 24 and extracts the wallet accounts corresponding to the respective email addresses from the email address of the sender as the sender and the email address of the recipient as the destination (S7). A refund transaction is generated for sending the MSC from the wallet account of the recipient as the destination of the received email to the wallet account of the sender as the sender (S8). The private key information is read from the private key storage unit 25 and the generated refund transaction is signed (S9). Then, the generated refund transaction is broadcast to the blockchain 12, and the threshold control unit 32 broadcasts information for updating the information of the reception MSC threshold calculated in S5 and S6 to the blockchain 12 (S10), completing the refund process and the update of the reception MSC threshold.

[0053] The above-mentioned receiving MSC threshold may be set to a different value for each sender's mail account. For example, a lower deposit amount may be sufficient for a wallet account corresponding to a sender's mail account that is registered in an address book, has a history of sending and receiving e-mails in the past, or is used to send and receive e-mails on a regular basis, while a higher deposit amount may be desired for a wallet account corresponding to a sender's mail account that is receiving e-mail for the first time. By setting a receiving MSC threshold for each mail account or for each type of mail account (for example, type of mail account with or without a history of sending and receiving), senders who send spam mails will incur a large cost, and as a result, it is possible to reduce inappropriate mails such as spam mails.

[0054] Furthermore, each of the above-mentioned functions may be realized as the information communication device 10 by installing a mailer (including an extended function of the mailer) on the user's computer, or may be realized by implementing a processing unit that performs processing other than sending and receiving emails (all processing related to MSC) in the mail sending server 11a or the mail receiving server 11b in Fig. 4. Furthermore, a so-called smart contract that performs remittance and refund processing on the blockchain may be used, a correspondence information storage unit 24 may be provided on the blockchain 12, and a contract execution unit that executes contract processing related to the transfer of MSC on the blockchain 12 may be provided.

[0055] Furthermore, in the e-mail sending process in Fig. 7, a processing mode is shown in which e-mail can be sent when the MSC is in an unsent state, but a processing mode in which e-mail cannot be sent when the MSC is in an unsent state may be used. Specifically, in S2, the processing up to S6 may be performed before the outgoing e-mail is sent to the e-mail sending server 11a, and based on the result, the outgoing e-mail may be sent to the e-mail sending server 11a or may not be sent.

[0056] Furthermore, in the refund processing of Figure 9, a processing mode is shown in which the threshold control unit 32 broadcasts the receiving MSC threshold calculated by the threshold control unit 32 to the blockchain 12, but the processing mode may also be such that the threshold control unit 32 passes information on the receiving MSC threshold calculated to the refund control unit 31, and the refund control unit 31 broadcasts the information on the receiving MSC threshold to the blockchain 12 along with the refund transaction.

[0057] Furthermore, in the above description, one wallet account is associated with one mail account, but one wallet account may be associated with multiple mail accounts, or multiple wallet accounts may be associated with one mail account.

[0058] Furthermore, in the above, the receiving MSC threshold is managed on the blockchain 12, but the information on the receiving MSC threshold may be managed by each user in the information communication device 10 that he or she uses. Specifically, for example, in addition to the correspondence information between the email addresses of the sender and the wallet accounts of the sender and the recipient stored in the correspondence information storage unit 24 (hereinafter simply referred to as correspondence information), the receiving MSC threshold may be further associated and stored. In this case, when the receiving MSC threshold is set uniformly, the same receiving MSC threshold may be associated with all the correspondence information, and when it is desired to set the receiving MSC threshold individually for each sender, a receiving MSC threshold of a different value may be associated with each correspondence information. In this case, when sending an e-mail, in S5 of FIG. 7, the remittance amount confirmation unit 26 does not make an inquiry to the blockchain 12 as shown in FIG. 4, but makes an inquiry to the mailer on the receiver side via the mail sending server 11a. In response to an inquiry from the sender side, the mailer on the receiver side replies with the information on the receiving MSC threshold stored in the correspondence information storage unit 24, so that the sender side can know the amount of sending MSC required when sending an e-mail. In addition, regarding the update of the receiving MSC threshold, in S10 of Figure 9, instead of broadcasting information for updating the receiving MSC threshold information calculated by the threshold control unit 32 of Figure 4 in S5 and S6 of Figure 9 to the blockchain 12, the value of the receiving MSC threshold stored in the correspondence information storage unit 24 is updated.

[0059] As described above, the information communication device according to this embodiment includes a mail sending unit 23 that sends e-mail from one account (e.g., one mail account) to another account (e.g., the other mail account), a remittance control unit 27 that generates a remittance transaction for sending an MSC from one account (e.g., one wallet account) to another account (e.g., the other wallet account) when the mail sending unit 23 sends an e-mail and broadcasts the transaction to the blockchain 12, a mail receiving unit 28 that receives e-mail sent from the other account (e.g., the other mail account) to the one account (e.g., one mail account), and a remittance control unit 27 that broadcasts the transaction to the blockchain 12 when the mail sending unit 23 receives an e-mail. a reception control unit 29 that accesses the blockchain 12 to confirm the status of a deposit of an MSC from one account (e.g., one wallet account) to one account (e.g., one wallet account) and receives the email as a legitimate email if the confirmed deposit amount is an amount equal to or greater than a predetermined receiving MSC threshold; a refund control unit 31 that, when the receiving control unit 29 receives a legitimate email, generates a remittance transaction for remitting an MSC in the same amount as the remittance transaction from one account (e.g., one wallet account) to another account (the other wallet account) in accordance with the MSC remittance transaction generated when the email was sent and broadcasts the remittance transaction to the blockchain 12; and a threshold control unit 32 that adjusts the receiving MSC threshold according to the type of email received.

[0060] Therefore, when a sender sends an e-mail to a recipient, the sender transfers the MSC at the same time, and if the e-mail is deemed legitimate by the recipient, the MSC is returned to the sender as is. This prevents the increase or decrease in the MSC as long as normal e-mail is sent and received. However, when an unauthorized e-mail is sent, the e-mail is not received as a legitimate e-mail, and the sender's MSC decreases. That is, while normal e-mail exchanges do not incur any cost, senders such as SPAMers require a large MSC cost, and as a result, unauthorized e-mails such as SPAM mails can be reduced. At this time, the amount of the sending MSC required when sending e-mail is important. In the information communication device 10 according to this embodiment, the amount of the sending MSC can be adjusted by the receiving MSC threshold, so that the amount of the sending MSC can be kept appropriate and the reception of unauthorized e-mails can be eliminated without interfering with the sending and receiving of legitimate e-mails.

[0061] Furthermore, in the information communication device of this embodiment, the threshold control unit 32 adjusts the receiving MSC threshold to be smaller when the type of received e-mail is legitimate e-mail, and adjusts the receiving MSC threshold to be larger when the type of received e-mail is illegitimate e-mail, so that the sending MSC amount can be appropriately adjusted with the receiving MSC threshold and the reception of illegitimate e-mail can be eliminated without interfering with the sending and receiving of legitimate e-mail.

[0062] Furthermore, since the threshold control unit 32 identifies the type of e-mail according to the type of operation by the recipient who received the e-mail, it is possible to accurately determine whether the received e-mail is legitimate or illegitimate according to the type of operation by the recipient.

[0063] Furthermore, the threshold control unit 32 adjusts the receiving MSC threshold to be smaller when the recipient's operation type is one operation type including viewing, saving, and / or replying to an e-mail, and adjusts the receiving MSC threshold to be larger when the recipient's operation type is another operation type including discarding the e-mail or identifying it as spam.Therefore, it is possible to accurately determine whether a received e-mail is legitimate or illegitimate according to the recipient's operation type, while appropriately adjusting the sending MSC amount with the receiving MSC threshold, and to eliminate the reception of illegitimate e-mails without interfering with the sending and receiving of legitimate e-mails.

[0064] Furthermore, when the type of e-mail is a legitimate e-mail, the threshold control unit 32 subtracts the receiving MSC threshold to adjust the receiving MSC threshold to a smaller value, and when the type of e-mail is an invalid e-mail, the threshold control unit 32 multiplies the receiving MSC threshold to adjust the receiving MSC threshold to a larger value, thereby making it possible to reduce invalid e-mails by referring to a congestion control algorithm that avoids and alleviates congestion in TCP.

[0065] Furthermore, since the receiving MSC threshold is set for each sender's email account or type of email account, an appropriate receiving MSC threshold can be set based on the history of previous sending and receiving and the relationship between users. EXAMPLES

[0066] SAGA BC A simulation experiment was conducted using the information communication device 10 according to the present invention in the system. Here, the SAGA algorithm was used, based on the above formula (1). BC We verified whether spam mails could be reduced when the system usage rate was 50%. Figure 10 is an NS chart showing the experimental model.

[0067] (1) Initial setting: SAGA in the virtual space BC Create Nu users for System 1. Among them, the number of spammers is Su, and the number of general users is (Nu-Su). Also, SAGA BCCreate Nn non-users of System 1. Among them, let the number of spammers be Sn, and the number of general users be (Nn-Sn). (2) Sending and Remittance: A general user sends an e-mail to a randomly selected addressee from among users other than himself or herself and spammers, and simultaneously transfers MSC. At that time, the receiving MSC threshold of the destination is checked, and if the MSC held is equal to or greater than the receiving MSC threshold of the destination, the amount of MSC sent is set to the same value as the receiving MSC threshold of the destination. In other words, an amount of MSC equal to the receiving MSC threshold is transferred. If the MSC held is less than the receiving MSC threshold of the destination, the e-mail is not sent. (3) Refund: All e-mails sent by (Nu-Su) general users will be deemed to be non-SPAM e-mails, and the equivalent amount of MSC will be refunded after the funds are transferred to the wallet account corresponding to the destination e-mail account. (4) Threshold update: The user who receives the email lowers the threshold according to formula (1). (5) General user loop: (2) to (3) are repeated for (Nu-Su) general users. Note that general users are not expected to mine. (6) Sending and Remittance: The SPAMer sends emails and transfers MSC money. SAGA BC General users of System 1 are (Nu-Su) people and SAGA BC A random recipient is selected from among the general users (Nn-Sn) who are not using System 1, and one spam email is sent to that recipient, and a payment is made at the same time. At this time, the recipient's receiving MSC threshold is checked, and if the recipient does not have the MSC required for the payment, the email is not sent. (7) Refunds: All e-mails sent by a SPAMer will be considered SPAM e-mails, and any MSC payments sent by the SPAMer will not be refunded. (8) Revenue: For each spam email sent, the spammer earns revenue b with probability p. The spammer earns MSCs equal to revenue b through mining. (9) Threshold update: The user who received the email increases the threshold according to formula (1). (10) Spam mail sending loop: (6) to (9) are repeated T times. In other words, each spammer sends T spam mails per unit time. (11) SPAMer loop: (6) to (10) are repeated for all SPAMers. (12) Unit time loop: (2) to (11) are counted as one unit time, and the loop is repeated. The time based on this is represented as t.

[0068] In this example, SAGA BC Percentage of users of System 1 (SAGA BC The experiment is conducted with a utilization rate of 50%. Therefore, the experimental parameters are set to Nu = 100, Su = 1, Nn = 100, and Sn = 0. The revenue b obtained by the spammer is calculated according to the following formula (2).

[0069]

number

[0070] Here, C is a constant (27) and the value of p is a uniformly distributed random number satisfying 0 < p < 330.

[0071] The simulation results are shown below. First, the conventional SAGA without the threshold adjustment algorithm in the information communication device 10 of the present invention is used. BC In System 1, SAGA BC SAGA with System 1 utilization rate of 50% BC Figure 11 shows the number of spam emails received by general users of System 1. In Figure 11, SAGA BC If the threshold adjustment process is not performed when the utilization rate of system 1 is 50%, SAGA BC The number of spam emails received by general users of System 1 shows a downward trend up to t=4, but after that it gradually increases and stagnates at around 50 emails.

[0072] Next, we verified the behavior when the threshold adjustment algorithm of the above-described formula (1) was introduced. In the verification, we changed the decrease width x of the receiving MSC threshold and the increase magnification y of the receiving MSC threshold in formula (1) and performed the SAGA BC We compared the number of spam emails received by general users of System 1. The results are shown in Figure 12. Figure 12(A) is shown in table format, and Figure 12(B) is shown in contour graph format. Note that the values ​​in the table shown in Figure 12(A) and the values ​​in the graph shown in Figure 12(B) are the average numbers of spam emails that arrived in the last 20 unit hours in 100 trials. The verification results in Figure 12 make it clear that the number of spam emails received decreases when the decrease in the receiving MSC threshold x is small and the increase rate y is large.

[0073] Next, we focus on the reception MSC threshold of general users and the amount of MSC held by general users when the decrease width x of the reception MSC threshold and the increase magnification y are changed. Figure 13 shows the average amount of virtual currency held by general users and the reception MSC threshold. Figure 13 (A) shows the average amount of virtual currency held by general users in 100 executions, Figure 13 (B) shows the average final reception MSC threshold of general users in 100 executions, and Figure 13 (C) shows the final virtual currency held by general users in 100 executions ÷ reception MSC threshold. If the reception MSC threshold exceeds the amount of virtual currency held, that is, if the value in Figure 13 (C) is less than 1, email cannot be sent even between general users. In other words, as shown in Figure 13 (C), when the increase magnification y is 2.64 or more, a state occurs in which (amount of virtual currency held) ÷ (reception MSC threshold) is less than 1, and it becomes clear that email cannot be exchanged between general users.

[0074] As shown in Figure 13, by setting the increase factor y to less than 2.64, it is possible for general users to send and receive emails between each other. However, considering the daily use of email, it is thought that problems will arise if the amount of virtual currency held divided by the received MSC threshold is about 1, i.e., only one email can be sent at a time. Therefore, (number of spam emails received) divided by (number of emails that can be sent at the same time) is calculated and compared. The results of this calculation are shown in Figure 14. The results in Figure 14 show that it is possible to use SAGA while keeping the number of spam emails received low. BC In order to maintain a certain level of email that can be sent and received between general users of system 1, it can be concluded that in this simulation, the reduction rate x should be set to 0.008 and the increase rate y to 1.74.

[0075] From the above, the conventional SAGA BC In System 1, the SAGA BC When the utilization rate of system 1 was 50%, it was difficult to prevent spam mail and the like. However, in the information communication device 10 of the present invention, it became clear that by using a receiving MSC threshold and varying the receiving MSC threshold according to the algorithm of formula (1), spam mail and the like can be effectively prevented.

[0076] In addition, by appropriately setting the decrease and increase ratios of the receiving MSC threshold in formula (1), it is possible to reduce the reception of unauthorized e-mails due to spam e-mails while stably controlling the SAGA so that there is no disruption to the sending and receiving of e-mails by general users. BC It became clear that System 1 could be operated. [Explanation of symbols]

[0077] 1 SAGA BC system 10 (10a, 10b) Information and communication equipment 11 Mail Server 11a Mail sending server 11b Mail receiving server 12. Blockchain 13. Internet 21 Input / output section 22 Sending Email Creation Section 23 Email sending section 24 Corresponding information storage unit 25 Private key storage 26 Remittance amount confirmation section 27 Remittance Control Unit 28 Mail Receiving Section 29 Reception control section 30 Incoming mail processing section 31 Refund Control Section 32 Threshold control section

Claims

1. An email sending means for sending email from one account to another account; A remittance control means for generating a remittance transaction for remitting virtual currency from the one account to the other account when the email sending means sends the email, and broadcasting the transaction to a blockchain; An email receiving means for receiving emails sent to one account from another account; A reception control means for accessing the blockchain to check the deposit status of the virtual currency from the other account to the one account when the email receiving means receives the email; a mail processing means for determining whether the received email is a legitimate email or an illegitimate email depending on whether the amount of the virtual currency in the deposit status confirmed by the reception control means is equal to or exceeds a predetermined threshold, and for executing a predetermined process for the received email depending on the determination result; a refund control means for generating a remittance transaction for remittance of the virtual currency from the one account to the other account based on the virtual currency remittance transaction generated when the email was sent, when the email processing means identifies the received email as a legitimate email, and broadcasting the generated remittance transaction to the blockchain; An information communication device characterized by comprising a threshold control means that adjusts the threshold value to be smaller when the refund process is performed by the refund control means, and adjusts the threshold value to be larger when the refund process is not performed by the refund control means.

2. 2. The information communication device according to claim 1, The refund control means An information communication device characterized in that it determines whether or not to perform the refund process based on the type of operation performed by a recipient of the email on the email, in addition to the result of the identification performed by the email processing means.

3. 3. The information communication device according to claim 2, The refund control means is The mail processing means performs a refund process when the received e-mail is identified as a legitimate e-mail and the operation type of the recipient is one of the operation types including referring to, storing, and / or replying to the e-mail; An information and communication device characterized in that the email processing means does not perform a refund process if the received email is identified as an unauthorized email or if the recipient's operation type is another operation type including an operation to discard the email or to identify it as spam.

4. 3. The information communication device according to claim 1, The threshold control means adjusts the threshold to be smaller by subtracting it when the refund control means performs a refund process, and adjusts the threshold to be larger by multiplying it when the refund control means does not perform a refund process.

5. 3. The information communication device according to claim 1, An information communication device, characterized in that the threshold value is set for each user account or each type of account.

6. A mail sending means for sending an e-mail from one account to another account; a remittance control means for generating a remittance transaction for remitting virtual currency from the one account to the other account when the email sending means sends the email, and broadcasting the transaction to a blockchain; An email receiving means for receiving emails sent to one account from another account; a reception control means for accessing the blockchain to check the deposit status of the virtual currency from the other account to the one account when the email receiving means receives the email; a mail processing means for identifying whether the received e-mail is a legitimate e-mail or an illegitimate e-mail depending on whether the amount of the virtual currency deposited in the deposit status confirmed by the reception control means is equal to or exceeds a predetermined threshold, and for executing a predetermined process for the received e-mail depending on the identification result; a refund control means for generating a remittance transaction for remittance of the virtual currency from the one account to the other account based on the virtual currency remittance transaction generated when the email was sent, when the email processing means identifies the received email as a legitimate email, and broadcasting the generated remittance transaction to the blockchain; An information and communication program characterized by making a computer function as a threshold control means that adjusts the threshold value to be smaller when the refund process is performed by the refund control means, and adjusts the threshold value to be larger when the refund process is not performed by the refund control means.

Images