Information communication device and information communication program

Abstract

To provide an information communication device that can reliably send and receive only legitimate emails by properly adjusting the transmission cost required for sending emails.SOLUTION: An information communication device includes: an email sending unit 23 that sends an email from one account to another account; a remittance control unit 27 that generates a remittance transaction for sending virtual currency from the one account to the other account when sending the email and broadcasts it to a block chain 12; an email receiving unit 28 that receives an email sent from the other account to the one account; a reception control unit 29 that, when receiving the email, accesses the block chain 12 to confirm a deposit status of the virtual currency from the other account to the one account and receives the email as a legitimate email if a confirmed deposit amount is equal to or greater than a predetermined threshold; a refund control unit 31 that refunds the virtual currency when the legitimate email is received; and a threshold control unit 32 that adjusts the threshold according to the type of the received email.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to an information communication device or 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") are a nuisance for email users. Users who send large quantities of SPAM (hereinafter referred to as "SPAMers") send large quantities of SPAM to an unspecified number of email addresses for various purposes, such as advertising, distributing computer viruses, and committing fraud. As a result, according to a survey by the FBI (Federal Bureau of Investigation), fraud losses caused by SPAM emails in 2022 amounted to $2.7 billion (see, for example, Internet Crime Complaint Center, 2020 Internet Crime Report, p. 3, 2021).

[0003] Taking the above background into consideration, Patent Document 1 and Non-Patent Document 1 disclose technologies relating to measures against SPAM emails. The technologies disclosed in Patent Document 1 and Non-Patent Document 1 include an email 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 email sending unit sends the 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 appropriately 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 communication 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 comprises: mail sending means for sending an email from one account to another account; 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 transaction to a blockchain; mail receiving means for receiving emails sent from the other account to the one account; reception control means for, when the email receiving means receives the email, accessing the blockchain to confirm the 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 equal to or greater than a predetermined threshold; 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 for the virtual currency generated when the email was sent and broadcasting the transaction to the blockchain; and threshold control means for adjusting the threshold depending on the type of email received.

[0009] In this way, the information communication device of the present invention sends an email from one account to another account, and when sending the email, generates a remittance transaction for remitting the virtual currency from the one account to the other account and broadcasts it to the blockchain; receives an email sent from the other account to the one account; when receiving the email, accesses the blockchain to confirm the deposit status of the virtual currency from the other account to the one account; if the confirmed deposit amount is equal to or greater than a predetermined threshold, receives the email as a legitimate email; when receiving the legitimate email, generates a remittance transaction for remitting the virtual currency from the one account to the other account in an amount equal to the remittance transaction for the virtual currency generated when the email was sent, and broadcasts it to the blockchain; and adjusts the threshold depending on the type of email received, thereby achieving the effect of eliminating the reception of invalid emails without interfering with the sending and receiving of legitimate emails. [Brief explanation 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. [Figure 2] FIG. 10 is a sequence diagram showing an example of a processing procedure of a mailer in the SAGABC system. [Figure 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. [Figure 5] FIG. 10 is a diagram illustrating an example of information stored in a correspondence information storage unit. [Figure 6] FIG. 10 is a diagram illustrating the processing of a reception control unit. [Figure 7]4 is a flowchart showing processing performed when sending an e-mail (when remitting MSC money) in the information communication device according to the first embodiment of the present invention. [Figure 8] 5 is a flowchart showing a process performed when an email 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. 10 is a diagram showing the number of spam emails received by general users of the conventional SAGABC system when the utilization rate of the SAGABC system is 50%. [Figure 12] FIG. 10 is a diagram showing the results of comparing the number of spam emails received by general users of the SAGABC system when the threshold reduction amount and increase magnification are changed in the information communication device according to the embodiment. [Figure 13] 10 is a diagram showing the average amount of virtual currency held by a general user and a threshold value in an information communication device according to an embodiment. FIG. [Figure 14] FIG. 10 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 INVENTION

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

[0012] SAGABC In this system, the cost of sending emails is mutually paid using virtual currency (digital currency) to prevent spam attacks. Generally, when legitimate emails are sent to legitimate email addresses, they are 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 legitimately received. 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 in virtual currency, which is returned if the email is received properly. In other words, ordinary users who send emails that are received properly do not incur any virtual currency costs under this system, but users such as spammers who send large volumes of emails that are not received properly must pay the cost of replenishing their virtual currency. As a result, it is possible to prevent spam attacks by spammers.

[0014] Here, definitions of terms used in this embodiment are provided below. A "blockchain" is a type of distributed database that stores data sequentially in units called blocks. Each block records hash values ​​up to the block immediately preceding it. 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 Decentralized Generalized 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, from web wallets that store virtual currencies online to cold wallets that store virtual currencies on devices that are disconnected from the network. Virtual currency users manage their virtual currencies in wallets, and sending and receiving virtual currencies is done 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 sending cryptocurrency signs a transaction that lists 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 a single block that can be recorded on the blockchain and recording it at the beginning 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 the transaction on the blockchain, the transaction history is confirmed in an irreversible form. It takes several minutes from the issuance of a transaction to its confirmation.

[0020] Next, SAGA BC The system configuration will be described. Figure 1 shows the SAGA system using the information communication device according to this embodiment. BC This is a system overview diagram of the SAGA system. BC The system 1 comprises information 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 the information communication devices 10a, 10b.

[0021] For example, when an email is sent from an email address set in one email account used by one user as a sender to an email address set in another email account used by another user as a recipient, i.e., when an email is sent from information communication device 10a to information communication device 10b as shown in FIG. 1, the email created by information communication device 10a is sent to information communication device 10b via email sending server 11a for the sender and email receiving server 11b for the recipient. This series of email transmissions is performed using a typical method, for example, via an SMTP server or a POP3 server. At the same time as sending the email, information communication device 10a generates a virtual currency remittance transaction and broadcasts it to the blockchain 12. The remittance transaction generated at this time indicates the transfer of a predetermined amount of virtual currency from the wallet of the sender, who is the user of information communication device 10a, to the wallet of the recipient, who is the user of information communication device 10b.

[0022] The information communication device 10b receives the email (provisionally received at this stage) and accesses the blockchain 12 to check the deposit status of the email, such as whether the virtual currency has been deposited into the recipient's wallet or whether the deposit amount is equal to or greater than a predetermined amount. Only when the deposit status is appropriate, such as when the deposit is confirmed or when a deposit of a predetermined amount or more is confirmed, is the email received as a legitimate email and displayed in the inbox. If the deposit status is inappropriate, such as when the deposit is not confirmed or when the deposit is less than a predetermined amount, the email may be unconditionally discarded or moved to the trash, or it may be displayed in the inbox once and then displayed in a way that makes it clear to the recipient that the email does not contain any virtual currency (for example, by displaying an alert, highlighting, or displaying in a different color).

[0023] For ease of understanding, the above description is of one-way information communication in which an email is sent and virtual currency is transferred from information communication device 10a, on which one account (one email account and one wallet account) used by one user is set as the sender, to information communication device 10b, on which another account (another email account and another wallet account) used by another user is set as the receiver, and email is received and the deposit of virtual currency is confirmed on information communication device 10b used by the other user. However, both information communication device 10a used by one user and information communication device 10b used by the other user have the function of sending and receiving emails in both directions, as well as the function of transferring virtual currency and confirming the deposit, etc.

[0024] SAGA shown in Figure 1 BC System 1 links an email account for sending and receiving emails with a wallet account for accessing 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 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 emails (transferring money when sending emails or refunding money when receiving legitimate emails). Note that existing virtual currencies such as Bitcoin and Ethereum may also be used as 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-mails, and manages sending and receiving from one or more e-mail addresses. BC In System 1, a general mailer is used as an extension to SAGA 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 email, it has the function of checking the wallet account corresponding to the destination email address. (4) Incoming mail and deposit MSC support function It has the function of matching received emails with deposited MSCs, and the function of storing that data. (5) Spam filtering function Depending on the amount of MSC deposit for each received email, the email can be displayed, sorted into a spam folder, or deleted. (6) Money transfer function It has the function to send MSC from a Weret account corresponding to one's own email account, and the function to determine the amount to send (hereinafter referred to as the amount of MSC to be sent). (7) Mining function When there is a shortage of MSC to transfer when sending an email, MSC is replenished by mining MSC transactions issued by many users. SPAMers can also replenish MSC using this function, but this requires a large amount of computational cost.

[0028] The processing procedure of the above mailer 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 email, 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 email address. When receiving the email, if the sending MSC amount sent from the email sender is less than the receiving MSC threshold set by the receiving mailer, the receiving mailer classifies the email as invalid (e.g., spam email, junk email). If the sending MSC amount is equal to or greater than the receiving MSC threshold, the received email is considered valid (e.g., email to be confirmed, displayed, saved, replied to, etc.) and the MSC is refunded directly to the sender's wallet account depending on the user's operation on the email (e.g., delete, save, reply, etc.). For example, if an email received as valid is deleted or moved to a spam folder, the refund amount is set to 0. If the email is opened and not deleted or moved to a spam folder for a certain period of time, an amount equal to the sending MSC amount is refunded 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 there is no wallet account registered to the recipient's email address). Therefore, in such a case, it is acceptable to send a regular 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 Support Function above to check that the MSC corresponding to the received email has not been deposited. Also, (1) Account Management Function can be used to check 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 in association with 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 receiver are SAGA BC If System 1 is not implemented, normal emails will be sent and received without the ability to verify that they are not malicious emails.

[0032] The above SAGA BC In System 1, the cost of sending emails is reciprocally paid using MSCs. The important values ​​to be adjusted here are the sending MSC amount transferred when sending emails and the receiving MSC threshold, which is a reference value for the amount of MSC required to receive emails as legitimate. If these values ​​are inappropriate, problems such as legitimate emails not being delivered or invalid emails being delivered may occur, so an algorithm for adjusting these values ​​is required. In this embodiment, of the sending MSC amount and the receiving MSC threshold, only the receiving MSC threshold is focused on. This is because, as will be described later, the sending mailer can check the receiving MSC threshold before remittance, and there is no benefit in remittance of virtual currency exceeding the threshold.

[0033] In the information communication device 10 according to this embodiment, the reception MSC threshold is adjusted by the algorithm shown in the following equation (1). This algorithm is a congestion control algorithm for avoiding and mitigating congestion in TCP, called SAGA. BCThis method is applied to System 1 and is based on the Additive-Increase / Multiplicative-Decrease (AIMD) control (YR Yang, SS Lam, General AIMD congestion control, 2000) method 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 method incrementally 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 equation (1), the receiving MSC threshold is additively decreased until an inappropriate email such as a spam email is received, and then the receiving MSC threshold is multiplicatively increased when a spam email 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 equation (1). When the receiving MSC threshold is adjusted according to the algorithm of equation (1), the behavior will be as shown in Figure 3. As a result of adjusting the receiving MSC threshold, the sending MSC amount (the amount of MSC sent when sending an email) 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 email 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 by the sender of the email, an outgoing email creation unit 22 that creates an email to be sent in response to the input operation, an email sending unit 23 that sends the created outgoing email to the email sending server 11a, a correspondence information storage unit 24 that stores the email addresses of the sender and the recipient (the email address of the sender who is the sender and the email address of the recipient who is the recipient) in association with wallet accounts, 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 up a wallet account on the recipient side of the outgoing email to receive the outgoing email as a legitimate email. and a remittance control unit 27 that reads the wallet accounts of the sender and 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 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 email.

[0037] Here, the processing of the remittance amount confirmation unit 26 and the remittance control unit 27 will be explained in more detail. When sending an email, the remittance amount confirmation unit 26 queries the blockchain 12 to confirm the reception MSC threshold set in the wallet account corresponding to the recipient's email address, and acquires the reception MSC threshold. As described above, the reception MSC threshold is a threshold set on the recipient's side. If the amount of transmission MSC remitted from the sender's side is less than the reception MSC threshold, the email is classified as an invalid email (junk mail, SPAM mail, etc.), and if the amount is equal to or greater than the reception MSC threshold, the received email is determined to be legitimate. 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, passes information to the remittance control unit 27 indicating that the MSC cannot be remitted. If the amount of MSC held is equal to or greater than the reception MSC threshold, passes the acquired information on the reception MSC threshold to the remittance control unit 27.

[0038] The remittance control unit 27 performs a remittance process of the MSC from the sender's wallet to the receiver's wallet in accordance with 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. The correspondence information storage unit 24 stores email addresses, which are identification information for identifying the sender and receiver of an email, and wallet accounts, which are identification information required to access the blockchain 12, in one-to-one correspondence. If the remittance control unit 27 receives information from the remittance amount confirmation unit 26 indicating that the MSC cannot be remitted, the remittance control unit 27 does not perform the remittance process. If the remittance control unit 27 receives information on the receiving MSC threshold from the remittance amount confirmation unit 26, the remittance control unit 27 performs a remittance process for an amount equal to the receiving MSC threshold. Specifically, the remittance control unit 27 extracts the corresponding wallet account from the sender's email address, which is the sender of the outgoing email created by the outgoing email creation unit 22. The remittance control unit 27 also extracts the corresponding wallet account from the destination email address, which is the recipient of the outgoing email. Using these wallet accounts, the remitter's wallet account and the remittee's wallet account are identified, and a remittance transaction is created in which the remittance amount is equal to the receiving MSC threshold.

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

[0040] Next, the processing when receiving an email will be described. In Fig. 4, the information communication device 10 includes a mail receiving unit 28 that receives an email addressed to the recipient from the mail receiving server 11b, a reception control unit 29 that reads from the correspondence information storage unit 24 the wallet account corresponding to the sender's email address from the email received by the mail receiving unit 28, and queries the blockchain 12 to confirm whether or not an MSC remittance has been made by the sender and / or the remittance amount, and a received email processing unit 30 that displays the received email as a legitimate email if an MSC remittance has been made by the sender or if the remittance amount is equal to or greater than the received MSC threshold, and otherwise performs processing such as discarding the received email as an invalid email. These components function in the processing when receiving an email.

[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 reception unit 28. At the same time, it extracts the wallet account from the recipient's own email address, which is the destination, who is the recipient. 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 email and the deposit status, performs a predetermined process (for example, displaying the email in the inbox normally, displaying the email in the inbox together with information about whether or not a deposit has been made or whether or not a deposit of a predetermined amount has been made) on the received email depending on the deposit status (for example, displaying the email in the inbox normally, displaying the email in the inbox together with information about whether or not a deposit has been made or the amount of the deposit, discarding the email in the trash, discarding the email completely, or treating the email as spam). The process of the received mail processing unit 30 may also be determined depending on the amount of the deposited MSC. For example, the email may be sorted into folders depending on the amount of the deposit, or may be highlighted if a deposit of a predetermined amount or more has been made, and displayed normally 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 send a larger amount of MSC to encourage the user to check the email as a priority.

[0043] Next, the processing for refunding when an email 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 sending the MSC from the wallet account of the destination (receiver) to the wallet account of the sender (sender) in order to refund the MSC deposited when the email was received, depending on the processing content of the received email executed by the received email processing unit 30 and the operation content performed by the recipient at the input / output unit 21, and signs the generated remittance transaction using private key information stored in the private key memory unit 25 and broadcasts it to the blockchain 12, and a threshold control unit 32 that calculates a received MSC threshold based on the algorithm of the above-mentioned equation (1), and broadcasts it to the blockchain 12 for update.

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

[0045] The refund process by the refund control unit 31 is similar to the remittance process performed when sending an email, and the refund control unit 31 accesses the correspondence information storage unit 24 and extracts the wallet account from the email address of the sender who is the sender of the received email. A remittance transaction (hereinafter referred to as a refund transaction) for the refund amount determined above is generated from the recipient's own wallet account, which is the destination of the email, to the sender's wallet account, and 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 this.

[0046] The threshold control unit 32 calculates the receiving MSC threshold when the refund control unit 31 determines whether to perform the refund process. Specifically, the receiving MSC threshold is calculated according to the above formula (1). When the refund process is performed, that is, when a legitimate email to be displayed or confirmed is received, the receiving MSC threshold is decreased by a predetermined value. On the other hand, when the refund process is not performed, that is, when an invalid email that is not even displayed in the inbox or an email that is received but the contents of the email are not displayed / confirmed is received, the receiving MSC threshold is increased by multiplying it by a predetermined value. Information about the calculated receiving 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 emails are sent, the higher the receiving MSC threshold set by the recipient will increase exponentially, which increases the sending cost for spammers and ultimately reduces the amount of spam.On the other hand, for regular email users who are not spammers, 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 processing performed when an email is sent (when an MSC remittance is performed) in the information communication device according to this embodiment. In FIG. 7, first, the outgoing email creation unit 22 creates an outgoing email in response to an operation of the input / output unit 21 performed by the sender (S1). The email sending unit 23 sends the created outgoing email to the email sending server 11a (S2). At the same time that the outgoing email is handed over to the email sending unit 23 in S2, the remittance control unit 27 receives the email address of the destination, which is the recipient of the outgoing email (S3). The remittance control unit 27 accesses the correspondence information storage unit 24 and extracts wallet accounts corresponding to the email addresses of the destination, which is the recipient, and the sender, which is the sender's email address (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 in the wallet account of the sender 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 obtained is passed to the remittance control unit 27.

[0049] When the remittance control unit 27 receives the information on the received MSC threshold, it generates a remittance transaction for sending 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 email sending process.

[0050] FIG. 8 is a flowchart showing the process of receiving an email in the information communication device according to this embodiment. In FIG. 8, first, the email receiving unit 28 receives an email from the email receiving server 11b (S1). The reception control unit 29 receives the email address of the sender of the received email (S2). The reception control unit 29 accesses the correspondence information storage unit 24 and extracts wallet accounts corresponding to the email addresses of the sender (the sender) and the user's own email address (the recipient) (S3). The reception control unit 29 queries the blockchain 12 about the status of MSC deposits from the sender's wallet account (the sender) to the user's own wallet account (the recipient) (S4). The reception control unit 29 determines whether the amount of the deposited MSC is equal to or greater than the received MSC threshold set by the reception control unit 29 (S5) and passes the result of this determination to the received email processing unit 30. If the received email processing unit 30 receives a determination result indicating that the amount of the deposited MSC is equal to or greater than the received MSC threshold, the reception control unit 30 executes processing to display the received email as a legitimate email (S6). If the determination result is that the amount of the deposited MSC is less than the received MSC threshold, the received email is treated as an invalid email and processing is executed to prevent the email from being displayed (S7), and the email reception processing is completed.

[0051] FIG. 9 is a flowchart showing a refund process in the information communication device according to this embodiment. In FIG. 9, first, the refund control unit 31 receives the processing mode of the received email processing unit 30 or the processing mode of the input / output unit 21 when receiving an email (S1). The refund control unit 31 determines whether the received processing mode corresponds to the processing mode when a legitimate email is received (S2). If the refund control unit 31 determines in S2 that the received processing mode corresponds to the processing mode when a legitimate email is received, it sets the refund amount to an amount equal to the MSC deposited when the email is received (S3). On the other hand, if the refund control unit 31 determines in S2 that the received processing mode does not correspond to the processing mode when a legitimate email is received, it sets the refund amount to 0 (S4). Furthermore, if the threshold control unit 32 determines in S2 that the processing mode received by the refund control unit 31 corresponds to the processing mode when a legitimate email is received, it decreases the received MSC threshold by a predetermined value (S5). On the other hand, if the refund control unit 31 determines in S2 that the processing mode received by the refund control unit 31 does not correspond to the processing mode when a legitimate email is received, it increases the received 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 (the sender) and its own email address (the recipient) (S7). It generates a refund transaction for sending the MSC from its own wallet account (the recipient) to the wallet account of the sender (the sender) (S8). It reads private key information from the private key storage unit 25 and signs the generated refund transaction (S9). The generated refund transaction is then broadcast to the blockchain 12, and the threshold control unit 32 broadcasts information for updating the information on 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 email account. For example, a lower deposit amount may be sufficient for a wallet account corresponding to a sender's email account that is registered in the address book, has a history of sending and receiving emails in the past, or is regularly used to send and receive emails, while a higher deposit amount may be desired for a wallet account corresponding to a sender's email account that is receiving emails for the first time. By setting a receiving MSC threshold for each email account or for each type of email account (for example, type with or without a history of sending and receiving emails), senders who send spam emails will incur high costs, and as a result, the number of inappropriate emails such as spam emails can be reduced.

[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 may be used to process remittances and refunds on a blockchain, and a correspondence information storage unit 24 may be provided on the blockchain 12, with a contract fulfillment unit that executes contract processing related to the transfer of MSC on the blockchain 12.

[0055] Furthermore, in the email sending process of Fig. 7, a processing mode is shown in which email can be sent when the MSC is in an unsent state, but an email cannot be sent when the MSC is in an unsent state. Specifically, in S2, the processing up to S6 may be performed before the outgoing email is sent to the email sending server 11a, and based on the result, the outgoing email may be sent to the email 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 received MSC threshold calculated by the threshold control unit 32 to the blockchain 12, but a processing mode in which the threshold control unit 32 passes information on the received MSC threshold calculated to the refund control unit 31, and the refund control unit 31 broadcasts information on the received MSC threshold along with the refund transaction to the blockchain 12 may also be used.

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

[0058] Furthermore, although the receiving MSC threshold is managed on the blockchain 12 in the above configuration, information on the receiving MSC threshold may be managed by each user in the information communication device 10 that they use. Specifically, for example, in addition to the correspondence information between the email addresses of each sender and each wallet account (hereinafter simply referred to as correspondence information) stored in the correspondence information storage unit 24, the receiving MSC threshold may be further associated and stored. In this case, if the receiving MSC threshold is to be set uniformly, the same receiving MSC threshold may be associated with all correspondence information. However, if the receiving MSC threshold is to be set individually for each sender, a different receiving MSC threshold value may be associated with each correspondence information. In this case, when sending an email, in S5 of FIG. 7, the remittance amount confirmation unit 26 does not inquire about the blockchain 12 as shown in FIG. 4, but rather inquires about the recipient's mailer via the mail sending server 11a. In response to the sender's inquiry, the recipient's mailer replies with information on the receiving MSC threshold stored in the correspondence information storage unit 24, allowing the sender to know the amount of sending MSC required when sending an email. In addition, regarding the update of the receiving MSC threshold, in S10 of Figure 9, the threshold control unit 32 of Figure 4 does not broadcast information to the blockchain 12 to update the information of the receiving MSC threshold calculated in S5 and S6 of Figure 9, but rather updates the value of the receiving MSC threshold stored in the correspondence information storage unit 24.

[0059] As described above, the information communication device according to this embodiment includes a mail sending unit 23 that sends an email 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 email and broadcasts the transaction to the blockchain 12, a mail receiving unit 28 that receives an email sent from another account (e.g., the other mail account) to the one account (e.g., the one mail account), and a remittance control unit 27 that broadcasts the email to the blockchain 12 when the mail sending unit 23 receives an email. The system includes a reception control unit 29 that accesses the blockchain 12 to confirm the status of MSC deposits 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 equal to or greater than a predetermined MSC receiving threshold; a refund control unit 31 that, when the reception control unit 29 receives a legitimate email, generates a remittance transaction for remitting 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 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 email to a recipient, the sender simultaneously transfers the MSC. If the email is deemed legitimate by the recipient, the MSC is returned to the sender. This minimizes the increase or decrease in the MSC as long as normal email is sent and received. However, if an unauthorized email is sent, the email is not received as legitimate, and the sender's MSC decreases. In other words, while normal email exchanges do not incur any costs, senders such as spammers require significant MSC costs. This ultimately reduces the amount of unauthorized email, such as spam. The amount of the sending MSC required when sending email is important. The information communication device 10 according to this embodiment can adjust this amount of the sending MSC using a receiving MSC threshold, thereby maintaining an appropriate amount of the sending MSC and eliminating the reception of unauthorized email without interfering with the transmission and reception of legitimate email.

[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 amount of sending MSC can be appropriately adjusted using 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 email according to the type of operation performed by the recipient who received the email, it is possible to accurately determine whether the received email is legitimate or illegitimate according to the type of operation performed by the recipient.

[0063] Furthermore, the threshold control unit 32 adjusts the receiving MSC threshold to be smaller when the receiver'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 receiver'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 the received e-mail is legitimate or illegitimate depending on the receiver's operation type, while appropriately adjusting the amount of sending MSC using the receiving MSC threshold, and to eliminate the reception of illegitimate e-mail without interfering with the sending and receiving of legitimate e-mail.

[0064] Furthermore, if the type of email is legitimate email, the threshold control unit 32 subtracts the receiving MSC threshold to adjust the receiving MSC threshold to a smaller value, and if the type of email is illegitimate email, the threshold control unit 32 multiplies the receiving MSC threshold to adjust the receiving MSC threshold to a larger value, thereby reducing illegitimate emails 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. [Example]

[0066] SAGA BC A simulation experiment was conducted using the information communication device 10 according to the present invention in a system. Here, the SAGA algorithm was used, using the algorithm of the above formula (1). BC We verified whether spam mails can be reduced when the system usage rate is 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 Sn be spammers and (Nn-Sn) be general users. (2) Sending and Remittance: A general user sends an email to a randomly selected recipient, excluding themselves and spammers, and simultaneously transfers MSC. At this time, the recipient's receiving MSC threshold is checked, and if the recipient's MSC is equal to or greater than the recipient's receiving MSC threshold, the sending MSC amount is set to the same value as the recipient's receiving MSC threshold. In other words, an MSC equal to the receiving MSC threshold is transferred. If the recipient's MSC is less than the recipient's receiving MSC threshold, the email is not sent. (3) Refund: All emails sent by (Nu-Su) general users will be deemed to be non-SPAM emails, and the equivalent amount of MSC will be refunded after the funds are transferred to the wallet account corresponding to the recipient's email account. (4) Threshold update: The user who received 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 do not participate in mining. (6) Sending and Remittance: The spammer sends emails and transfers money to the MSC. BC General users of System 1 (Nu-Su) and SAGA BC A recipient is randomly 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 emails sent by spammers will be considered spam, and any MSCs sent by spammers 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) Spammer loop: (6) to (10) are repeated for all spammers. (12) Unit time loop: (2) to (11) are counted as one unit time and are repeated. The time based on this is represented by t.

[0068] In this example, SAGA BC Percentage of users of System 1 (SAGA BC The experiment is conducted with a usage rate of 50%. Therefore, the experimental parameters are set to Nu = 100, Su = 1, Nn = 100, and Sn = 0. The revenue b earned 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 algorithm that does not use the threshold adjustment algorithm in the information communication device 10 of the present invention was used. BC In System 1, SAGA BC SAGA when System 1 is 50% utilized 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 decreasing 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 varied the decrease width x of the receiving MSC threshold and the increase magnification y of the receiving MSC threshold in formula (1) to calculate 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 values ​​of the number of spam emails that arrived in the last 20 unit hours over 100 trials. The verification results in Figure 12 revealed that the number of spam emails received decreases when the decrease in the receiving MSC threshold x is small and the increase magnification y is large.

[0073] Next, we focus on the receiving MSC threshold and the amount of MSC held by general users when the decrease in the receiving MSC threshold x and the increase factor y are changed. Figure 13 shows the average amount of virtual currency held by general users and the receiving MSC threshold. Figure 13(A) shows the average amount of virtual currency held by general users at 100 executions, Figure 13(B) shows the average final receiving MSC threshold of general users at 100 executions, and Figure 13(C) shows the final amount of virtual currency held by general users at 100 executions divided by the receiving MSC threshold. If the receiving MSC threshold exceeds the amount of virtual currency held, i.e., if the value in Figure 13(C) is less than 1, general users will not be able to send emails to each other. In other words, as shown in Figure 13(C), when the increase factor y is 2.64 or greater, the ratio (amount of virtual currency held) divided by the receiving MSC threshold will fall below 1, making it impossible for general users to exchange emails.

[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. However, considering the daily use of email, it is thought that it would be problematic if the amount of virtual currency held divided by the received MSC threshold was about 1, meaning that only about one email could be sent and received at a time. Therefore, (number of spam emails received) divided by (number of emails that can be sent simultaneously) was calculated and compared. The results of this calculation are shown in Figure 14. From the results in Figure 14, it is possible to keep the number of spam emails received low while using SAGA. BC In order to maintain a certain level of emails that can be sent and received between general users of System 1, it can be concluded that in this simulation, it is best to set the decrease x to 0.008 and the increase magnification 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 mails, etc. However, it became clear that the information communication device 10 of the present invention can effectively prevent spam mails, etc. by using a receiving MSC threshold and varying the receiving MSC threshold using the algorithm of formula (1).

[0076] In addition, by appropriately setting the decrease and increase ratio of the receiving MSC threshold in formula (1), it is possible to reduce the reception of unjustified emails due to SPAM emails while maintaining a stable SAGA so that there is no disruption to the sending and receiving of emails by general users. BC It became clear that System 1 could be put into operation. [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 Correspondence 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 Unit 32 Threshold control section

Claims

1. an email sending means for sending email from one account to another; 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 transaction to a blockchain; an email receiving means for receiving emails sent from another account to one account; a reception control means for, when the email receiving means receives the email, accessing the blockchain to check the 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 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 in an amount equal to the amount of the remittance transaction from the one account to the other account in accordance with the virtual currency remittance transaction generated when the email was sent, and broadcasting the generated transaction to the blockchain; An information communication device comprising: a threshold control means for adjusting the threshold in accordance with the type of the received email.

2. 2. The information communication device according to claim 1, An information communication device characterized in that the threshold control means adjusts the threshold to be smaller when the type of the received email is a legitimate email, and adjusts the threshold to be larger when the type of the received email is an invalid email.

3. 3. The information communication device according to claim 1, The information communication device, wherein the threshold control means specifies the type of the email in accordance with the type of operation performed by the recipient who received the email.

4. 4. The information communication device according to claim 3, An information communication device characterized in that the threshold control means adjusts the specified threshold to be smaller when the recipient's operation type is one operation type including viewing, saving, and / or replying to the email, and adjusts the specified threshold to be larger when the recipient's operation type is another operation type including discarding the email or recognizing it as spam.

5. 3. The information communication device according to claim 2, The information communication device is characterized in that the threshold control means adjusts the threshold to be smaller by subtracting it when the type of the email is the legitimate email, and adjusts the threshold to be larger by multiplying it when the type of the email is the invalid email.

6. 3. The information communication device according to claim 1, An information communication device, wherein the threshold is set for each user account or each type of account.

7. An email sending means for sending email from one account to another; 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 transaction to a blockchain; An email receiving means for receiving emails sent to one account from another account; a reception control means for, when the email receiving means receives the email, accessing the blockchain to confirm the 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 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 in an amount equal to the amount of the remittance transaction from the one account to the other account in accordance with the virtual currency remittance transaction generated when the email was sent, and broadcasting the transaction to the blockchain; An information communication program that causes a computer to function as threshold control means that adjusts the threshold in accordance with the type of the received email.

Images