KR20060079138A - Electronic message delivery with evaluation approach - Google Patents

Abstract

A message delivery approach has been posted that allows the sender to ensure that the intended recipient is hoping for the sender's message. As an example, whenever a report is received by a recipient that it is an unwanted message, the sender will charge a service operator a fine for each message. For senders who agree in advance to pay such a fine, the service operator may consider it guaranteed and provide a message of special authority to bypass the "spam" filter. If the Recipient reports an unwanted message, the Service Operator may fine the sender for the agreed amount, or change the commitment rate value, rating, or other experience associated with the sender. Predictive complaint estimates for the sender may be used to determine the test results applied by the receiver.

Description

Electronic Message Delivery with Estimation Approaches}

The present invention relates to electronic message delivery in an evaluation approach. More specifically, the present invention relates to a method and system for ensuring the delivery of an electronic message.

The approaches described in this section can be pursued, but not necessarily those previously recognized or already pursued. Thus, unless stated otherwise, the approaches described in this section are not prior art to the claims of this application and are not admitted to be prior art simply by inclusion in this section.

In recent years, the use of electronic message communication systems has increased significantly. However, many users of these systems, whether they are message senders or recipients, know that these systems are inconvenient and cumbersome to use. Similar problems are involved in telephone, fax, and e-mail communications and the like.

With regard to e-mail, in one past approach, senders marketing goods or services receive and develop lists of e-mail addresses, and regularly send a large amount of unwanted e-mail messages ("spam") to all addresses in the list. Send to. Under modern electronic systems, the cost of sending millions of such messages is negligible, and a response rate of less than 1% is considered valuable. Thus, successful delivery of an unwanted message to a valid inbox of a recipient usually translates into revenue for senders.

Unfortunately, this approach allows receivers to receive unnecessary messages. The perceived direct or indirect cost of receiving "spam" is high. Thus, receivers have adopted various approaches to avoid receiving and reviewing unnecessary messages.

As one example, receivers use filtering or blocking techniques to search for a keyword in the message subject line, or to reject or constrain a message that includes a keyword that matches a list of prohibited words. As another example, the receiver uses a "blacklist" to identify or prevent display of messages from suspect senders of unsolicited messages. Some receivers extend these techniques to have a personal "white list" of friends or other allowable senders, allowing only messages from senders on the "white list". The "white list" and "black list" may come from a network source. Techniques for performing a "black list" lookup can be found online at the directory "junkmail / support /" in the web "declude.com" and at the time of this document, "ip4r.htm" and "www.scconsult. com / bill / ".

For legitimate senders, one problem is that legitimate messages do not arrive at the intended receiver by the filtering or blocking technique. On the other hand, receivers that regularly use filtering or blocking techniques do not receive legitimate messages because their filtering and blocking techniques do not adequately screen legitimate messages from unnecessary messages. Any industry-standard term, or technical abbreviation can be the same as a forbidden keyword, confusing the "spam" filter.

Furthermore, the receiver receives a large amount of unwanted messages that are not properly blocked by the "spam" filter. As a result, many receivers are now reluctant to release their addresses except in limited circumstances. As a result, many legitimate senders, such as renowned companies, have developed an “opt-in” procedure, in which the receiver's address, such as customers, is never used unless the receiver approves receiving the message. Even if this is done, even legitimate sender messages sent to receivers that allow “opt-in” can be deleted or quarantined due to filtering or blocking techniques.

As a result, the value of e-mail as a legitimate marketing tool, the means of communicating to an opt-in receiver, is diminishing. Many receivers remain virtually defenseless against the everyday indiscriminate "spam" coming into their email inbox. Although many states have enacted laws that impose civil or criminal penalties for sending “spam,” these methods are time-consuming for receivers to pursue. In addition, although many Internet service providers (“ISPs”) actively identify and refuse to communicate with or do business with those who send “spam,” cracking down on such unreasonable activities can be costly to ISPs.

ISPs also spend money processing messages sent to recipients who do not have an account with the ISP. For these recipients, the ISPs mail system typically automatically generates a "bounce" message indicating that the recipient is an unknown user. In fact, a "double bounce" may occur if a message is sent to an invalid recipient with an address of an invalid sender. There is a cost to generate bounce messages and to maintain software and equipment to send bounce messages back to the sender over the network. Thus, there is a need for a method or system that can reduce the number of “bounce” and “double bounce” events that are experienced by ISPs and that result from unwanted messages.

Thus, the problem of "spam" in the Internet e-mail environment is virtually exhausting. There are also legitimate marketing agencies that send advertising messages via bulk email, and other senders that send valid bulk messages. In general, however, no one benefits from the activity of “spammers” other than the “spammers” themselves. ISPs, business groups, and end users all suffer from inconvenience, cost, and irritation.

Furthermore, important email messages can be blocked or entered into "bulk" mail folders based on rules that appear to the end user to be complex, random, and confidential. This costs e-mail marketers and causes Senders to lose the credit they can get from e-mail marketing. Furthermore, end users need to spend time monitoring, checking, retrieving, and processing "white lists" and similar mechanisms. Even when ISPs and businesses use "spam" prevention technology, many "spam" messages still enter the end-user's inbox, or they are mistakenly stored in bulk mail folders.

Although examples of the problems described above exist in an e-mail environment, instant messaging, chat room applications, web message boards, telephones, and facsimile means of communication suffer from similar problems.

Based on the foregoing, it is clear that there is a need for an improved approach that can ensure that legitimate messages are received by appropriate receivers.

There is also a need for an approach that can punish senders for sending unwanted messages.

This application posts on an electronic message delivery approach. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, one of ordinary skill in the art would appreciate that the present invention may be practiced without these specific details. In addition, in order to avoid unnecessarily obscuring the subject matter of the present invention, well-known structures and devices have also been shown in the form of blots.

The invention is illustrated by way of example and not by way of limitation in the figures of the drawings, and like reference numerals refer to like elements.

1A is a block diagram schematically illustrating an electronic message delivery system.

FIG. 1B is a block diagram illustrating components added to the system of FIG. 1A. FIG.

2A is a flow diagram of an electronic message delivery process in accordance with one embodiment of the present invention.

2B is a flowchart illustrating a method of processing a received electronic message.

3 is a flow chart illustrating a method of reporting an unnecessary message.

4 is a block diagram of a message.

5A is a flow diagram for a message verification approach.

5B is a flow chart showing additional steps in the method of FIG. 5A.

5C is a flow chart illustrating a method of generating a confirmation message.

6 is a flowchart illustrating a procedure of confirming a message.

7A is a flowchart for confirming reporting of an unnecessary message.

7B is a flow chart showing additional steps in the method of FIG. 7A.

8 is a block diagram illustrating a banking network and related components in conjunction with the system of FIG. 1A.

9 is a block diagram illustrating a computer system implementing an embodiment of the present invention.

Fig. 10A is a flowchart showing a first step of message processing using the evaluation approach method.

Fig. 10B is a flowchart showing a second step of message processing using the evaluation approach method.

Hereinafter, embodiments of the present invention will be described in the following order.

1.0 General Overview

2.0 Electronic Message Delivery Approach

2.1 Terminology

2.2 System structure and function overview

2.3 crypto token approach

2.4 Decide whether to accept a message

2.5 handle reporting of unnecessary messages

2.6 Penalties for Senders

2.7 Evaluation Approach

3.0 Implementation Mechanisms-Hardware Overview

4.0 extensions and replacements

1.0 General Overview

The necessity of the present invention as set out in the background above, as well as other necessities, which will become apparent in the following description, and the object of the present invention are achieved by a method for delivering an electronic message provided according to one aspect of the present invention. In another aspect of the invention, the invention includes a computer device and a computer readable medium configured to deliver an electronic message.

In general, the techniques of the methods and systems disclosed herein allow message senders to send their messages to their intended recipients, as well as many network service providers currently in use. It's a technology that can ensure that it isn't blocked by a "spam" filter. In one embodiment, the sender contracts with the Bonded Sender ™ Service Operator, where the sender is fined for each message reported as unwanted or "spam" email by the intended recipient. To agree. The sender sets the amount of fines to pay per email. The sender may be subjected to a credit check or may be required to deposit funds with an escrow. Alternatively, the sender may promise to pay a special amount of fine, rather than provide funds in advance. (Bonded Sender is a trademark of IronPort System, the assignee of this application)

Next, the sender identifies when the message was sent that the message was "Bonded". In one embodiment, an encrypted token in a message identifies the message as bonded. In contrast, a bonded message is sent from a particular network address provided to a service operator when a contract agreement is made. In this way, the service operator knows that all messages with a particular source network address in the message header have been bonded.

In one embodiment, upon receiving the bonded message, the receiver performs a conventional " spam " prevention check and filtering. If the receiver determines that the message is not "spam", the receiver forwards the message to the intended recipient. If the receiver determines that the message is "spam", the receiver checks to see if the sender of the message is a bonded sender. The check may be performed by the receiver sending a query to the service operator. The query includes the sender's network address. The service operator determines whether the sender is identified in a database held by the service operator. Once identified, the service operator sends a reply to the receiver confirming that the sender is bonded. Optionally, the reply may include the amount of fines the sender agrees to in the contract, or any other amount of fines.

The receiver determines whether to accept the message. The acceptance decision may be based on whether the fine exceeds the prescribed amount or threshold. The threshold may be set in the policy of the receiver, or may be predetermined for each end user account owner accompanying the receiver or by the owner. For example, in the receiver accompanying User X, the user profile may specify that X does not accept any "spam" messages from senders that charge a fine of $ 2.5 per message. However, the user Y profile may specify that Y accepts messages that charge an amount of $ 1 per message.

Optionally, if the receiver determines to accept the message, the receiver notifies the service operator. In response, the service operator attempts to withhold the amount of fine or penalty. If the hold is successful, the service operator informs the receiver.

By using the hold and tracking the total number of holds, the service operator will either have the sender exceed the credit limit set by the service operator, or the sender will need to deposit additional bond funds to the service operator. Will be able to judge. In addition, the service operator may refuse to notify the bond state of a sender as a policy matter. In other words, the total amount of reserved fines may be refused to inform the service operator that the credit limit has been set by a certain threshold. In one embodiment, each recreation expires automatically after a certain time.

In response to receiving the hold confirmation, the receiver sends the message to the intended recipient. In addition, as an embodiment, the receiver provides the associated recipient with a method of signaling to the receiver that the user has identified a message as "spam". For example, the graphical user interface display may have a button designated as "Report Message As Unwanted." If the receiver receives a signal identifying the message as invalid, the receiver stores information about the signal and the message. Periodically, the receiver sends a report to the service operator confirming which messages are reported as "spam". In response, the service operator imposes a penalty on the sender.

In some embodiments, the penalty constitutes various capped, tiered, or timed fines. In other embodiments, the message constitutes variously an email message, instant message, chat-room posts, web message board posts, phone calls, or pager messages. As another example, a variety of financial models may be used for fines, such as sharing a fine with a receiver, sharing a fine with non-profit organizations, involving a receiver or sender, and so forth. .

2.0 Electronic Message Delivery Approach

2.1 Terminology

The following terms used throughout this specification have the following meanings as an example.

"Bond" means the quantity of value that the sender sends to the service operator before the sender sends one or more bulk messages. A bond can be money, some kind of resource, a commodity, a service, or a promise.

"Enterprise" means a business entity that does not do business primarily sending bulk messages. The employee is sometimes a recipient.

"Receiver" means a business entity, hardware device, software component, or combination thereof that receives a message and distributes the message to a recipient. For example, recipients include business enterprises, Internet service providers (ISPs), web-based email services, and the like.

"Recipient" means a personal account, computer, or end user who loses, uses, or consumes messages sent by senders. Sometimes, a receiver is also an end user opening an account with a receiver.

 "Sender" means an individual or business entity that regularly sends out large amounts of messages to actual or prospective customers, subscribers, members, or other recipients. Examples include retail businesses, ad service companies, electronic mailing list providers, including online business and brick-and-mortar business. The sender may also be an individual who registers and manages a bonded sender network address for a separate end user or system that sends or causes the message to be sent.

"Service operator" means a trusted third party acting as a provider of the functions and services defined herein.

"Spam" typically means a large amount of unwanted message, i.e. an unnecessary e-mail message.

"Submitter" means a person or business entity reporting to the service operator that one or more messages are unnecessary. The submeter may be a receiver or a receiver. A party that manufactures or sells an anti-spam filter, software, or other technology can act as a submeter to reduce the number of "false positives" generated by the technology.

2.2 System structure and function overview

1A is a block diagram schematically illustrating an electronic message delivery system. The sender 102, which owns, operates, or carries the outgoing messaging gateway 104, is in communication connection directly or indirectly via one or more networks to the message processing system 106 owned or operated by a service operator. . Receiver 108 is communicatively connected to message processing system 106. The receiver owns, operates, or accompanies the incoming messaging gateway 110. The recipient is communicatively connected to the incoming messaging gateway 110.

Each gateway 104, 110 may configure a universal messaging gateway, mail relay, email relay, email router, simple email transfer protocol (SMTP), or email gateway, also known as a message transfer agent (MTA). . These are specifically programmed to perform the functions described herein.

For the purpose of illustrating a simple example, FIG. 1A shows only one of each of the above components. In practical implementations, however, there may be any number of senders, receivers, gateways, and recipients, and even tens of millions of uses of these elements are conceivable. In a high capacity network environment, the message processing system 106 may be replicated to one or more instances or sites for scalability or load balancing purposes. Also, for purposes of illustration, some embodiments may be described towards handling email messages. However, in other embodiments, the message may be a telephone call or a pager message.

In general, in the configuration of FIG. 1A, as an embodiment, sender 102 is registered with message processing system 106 to have an account with a service operator. Optionally, receiver 108 registers or obtains an account. Sender 102 may select a dedicated source network address to be used for the bonded message and provide the selected address to message processing system 106. Then, at any time, sender 102 causes its originating messaging gateway 104 to send one or more messages. These messages contain information confirming the amount of the proposed or promised penalty and are directed to the recipient 12.

The message is received at the destination messaging gateway 110 of the receiver 108. Gateway 110 determines whether the message is bonded. The gateway 110 requests the message processing system 106 to determine whether the message originates from a party registered with the message processing system as a bonded sender. The message processing system 106 and the gateway 110 apply one or more validation tests to the information in the message or information derived from the packet carrying the message. Depending on the test results or policy decisions applied by the gateway 110, the message is passed to the recipient 112, a score value is assigned to the filter, the message is discarded, or the message is bulk. As indicated, or other action is taken.

The foregoing generally describes the operation of one embodiment provided for the purpose of familiarizing the reader to FIG. 1A. However, many variations and additional example functionality may be added.

FIG. 1B is a block diagram of a system with additional elements added to FIG. 1A. The message processing system 106 may be implemented as one or more server-class computer systems hosting a web server 122, a database 124, and a DNS server 126. The web server 122 may be configured as a combination of an HTTP server such as an Apache HTTP server and an application server such as a weblogic application server. Database 124 provides a repository for storing association information in registered senders, receivers, recipients, bonds, messages, and other metadata, and can be used as a relational database server such as Oracle 8i, Microsoft SQL Server, and the like. Can be configured. The database 124 may also include log information, such as network address history added or deleted by the sender.

The DNS server 126 may be accessed using an Internet DNS protocol request, may perform resolution of a domain name to an IP address, and provide information regarding a specific IP address and the like. For purposes of illustrating an obvious example, in some embodiments DNS and IP have been described. However, embodiments of the present invention are not limited to the use of DNS and IP for address processing. The invention is applicable to any network addressing mechanism or protocol that may be developed in the future.

As a practical implementation, the DNS server has a high capacity. For example, a suitable DNS server 126 may process 50 million units of queries per day. In addition, DNS servers should be provided that are nearly 100% available and that do not bear unreasonably latent messages.

The functions described herein may be implemented in one or more Java Server Pages (JSPs), Active Server Pages (ASPs), or other software components. For purposes of illustration, FIG. 1B shows a JSP implementation whose functions are organized into sender page 120A and management page 120B. Optionally, receiver page 120C provides a receiver function. In the implementation above, sender 102 and receiver 108 may use the functionality of system 106 using conventional web browser applications such as Microsoft Internet Explorer, Netscape Communicator, and the like. Similarly, gateway 110 can utilize the functionality of system 106 by sending an HTTP request to system 106.

In particular, the sender 102 interacts with the sender page 120A to register with the system and to determine the amount of bonds offered or promised, credit exposure, complaints received, message volume sent, and fines incurred. Get information about The administrator accompanied by the service operator registers on the administration page 120B to register and confirm the user, to provide registration sender information to the representative sender, user management, address management, system management, bond collection, billing, and accounting. It performs management functions such as review, dispute resolution, and report preparation. The receiver or receiver interacts with receiver page 120C to register with the system and perform unnecessary message reporting, credit and bond status investigations, and the like.

The message processing system 106 may also configure one or more software elements, hardware elements, or manual operations to perform the functions described herein.

2A is a flowchart illustrating an electronic message delivery process according to an embodiment of the present invention. In block 201, one or more senders contract with a service operator. In one embodiment, the sender agrees to pay a fine for sending unnecessary messages and agrees to a dispute resolution process for fraudulent reporting of unnecessary messages and false reports from recipients who have not actually received the message.

Block 201 may also include participating in a registration process in which the sender provides contract information and credit information to the service operator. In the registration process, an administrator or delegate representative of another sender or receiver may set up a password-protected account on the service operator for the purpose of introducing, updating, and reviewing information relating to interaction with the service operator.

In one embodiment, as part of block 201, the sender provides the service operator with one or more IP addresses that it wishes to bond, and DNS "A" and "PTR" records for the addresses Specifies whether it exists in the system.

In another embodiment, the terms and conditions of the agreement are specified. That is, reviewing address information provided by a service operator to confirm ownership of the IP address and proper configuration of DNS records; Send can use the system to send only messages that meet a set of criteria; Other legal limitations, conditions for registration confirmation, fees, etc. The agreement may be implemented in an "click-to-accept" online form.

In another embodiment, some or all of the above-described registration process steps are performed using a non-online communication method such as telephone, fax, and the like. In this embodiment, the representative of the sender contacts the manager of the service operator who generates the record in the system for capturing the above information. For example, the terms of the draft drafted above can be negotiated and agreed using fax communication.

Block 201 may also include the service operator verifying the network address and other information provided by the sender. For example, the administrator of the service operator performs a reverse (PTR) DNS lookup on each IP address provided by the sender and records information about each domain returned by the DNS system. The service operator performs a "whois" lookup to verify that the domain name ownership of the record matches the sender. Other tests are performed to verify that the sender is not a "spammer", or that the sender aggregates the bulk mailing list to send only non- "spam" messages to the bonded address. It can be carried out.

 In block 202, as an embodiment, the sender deposits the bond at the service operator. The deposit of the bond may form part of the contract conclusion in block 201. In some embodiments, the service operator performs a credit check of the sender and does not require a bond. In contrast, a sender who does not have sufficient credit or payment history is required to deposit a bond with a service operator. Deposited funds are deposited in a trust account, a consignment account, or a similar account that can withdraw funds only when the service operator determines that an unnecessary message has been sent.

At block 204, the sender indicates that the particular communication has been bonded and may be fined. Such indication may be provided in several ways. The first approach, as indicated by block 204A, is that the sender advertises the particular network address selected by the sender as the "bonded sender" address. As an embodiment used in a network that uses an IP address to identify the source of a message, the sender registers a particular bonded sender source IP address with the service operator and sends a bonded message only from that address. Alternatively, as in block 204B, a cryptographic approach is used. How to advertise the message source will be described later in other sections.

In block 205A, the sender indicates the amount of fines agreed to bite if any message or communication is unnecessary. As one method, the sender registers the proposed fine amount with the service operator before sending the message. Alternatively, a cryptographic approach may be used that specifies a fine. As an alternative, the sender will pay a specific penalty for unwanted messages; And a promise to the service operator that no actual transfer of funds is required prior to sending the message. In one embodiment, a fixed or penalty vlaue is imposed based on the complaint rate or other metric. For example, a sender may receive a $ 20 bill for every million more than one million complaints. Other appropriate complaint rates or penalties may be used. In one embodiment, all fines may be one specified amount without change, such as one dollar per unnecessary message. Minimum fines, maximum fines, or variable fines for specific messages or recipients can also be used. At block 205B, the sender sends a message. Block 205B may also include causing a messaging gateway to send one or more messages to the network.

2B is a flowchart illustrating a method of processing a received electronic message. First, referring to block 206, a receiver, a personal end user, an ISP, a business enterprise, or some other person or organization, receives a message from a sender.

In some embodiments, the receivers and recipients register with the service operator before sending a message to obtain the service operator's service usage rights. For example, receivers and recipients register as part of block 201 of FIG. 2A. Registration of the receiver or receiver may include providing contact information, domain name and email address information, gateway information, information regarding "spam" prevention techniques when used by the receiver, and the like. In response to the successful registration of the receiver, service operators may provide bonded sender DNS information to the receiver or receiver to configure their gateways to interact with the system.

Block 206 may also include performing a conventional "spam" prevention check using commercial "spam" prevention filtering or blocking techniques. In this embodiment, the receiver proceeds to the remaining steps of FIG. 2B only if the message is identified as "spam". If the message passes the "spam" check, the message is sent to the recipient. As another example, the remaining steps of Figure 2B are performed regardless of the results of the "spam" prevention filtering technique.

In block 207, the receiver checks the communication with respect to the bonded state. This may include some tests.

For example, at block 208 the receiver verifies the source address of the received message against a database of advertised bonded sender addresses. For example, the receiver queries the service operator in an agreed protocol and provides the source address of the message received by the receiver. In one embodiment, as in the examples of Figures 1A and 1B, block 208 has a gateway 110 that sends a DNS lookup request to DNS server 126 that includes the source address of the received message. If DNS server 126 finds the source address in its database, a first specified response value is returned. If the source address is not in the DNS database, a second specific response value is returned. In one embodiment, the first response value is "127.0.0.2" and the second response value is "127.0.0.3".

The service operator generates a response message confirming whether the source address is a registered bonded sender address and sends the response message to the receiver, as shown by block 212.

In addition, the above test may include determining a fine amount suggested by the sender for the message. The receiver may also run more, fewer, or other tests for a particular message, depending on the amount of bond or penalty offered or promised by the sender.

Depending on whether the source address identifies a registered bonded sender, the receiver takes a responsive action. For example, at block 218, if the source address is not a registered bonded sender address, as tested at block 214, the receiver may block the message, or forward it to the bulk email fold, or otherwise. Message filtering may be performed.

If the source address is verified with a registered bonded sender address, as shown in block 215, the receiver may withhold a fine amount by sending a message to the service operator in an agreed-upon protocol. . In response, the service operator generates a charge hold report in its database and sends a response message to the receiver.

In one embodiment, withholding the fine indicates that the receiver does not have any special marking or processing, i.e., does not label the message as bulk, or does not store the message in the bulk fold, and stores the message in the recipient's seal. You can configure consent to forward to the box. In this embodiment, the service operator and the receiver enter into a contract that provides and enforces such conditions. As another alternative, such rules may be enforced on the basis of a good faith relationship between the parties, without a contract.

 Further, as another embodiment, the charge hold constitutes an agreement by the service operator to pay a portion of a fine to the receiver if the recipient reports the message as unnecessary before the hold period expires. You may. Each hold is accompanied by an expiration period, after which the hold expires. The expiration period may be any time after the suspension has been issued. In one embodiment, the hold is typically one to four days after the hold is issued.

By using the hold, service operators can assess and measure the extent of their current credit risk for each sender. For example, a lot of holdings means there are many opportunities for junk reporting. Also, based on the retention volume, the service operator can request the sender to deposit additional funds or perform additional credit checks to verify that exposure to the recipient is reasonable. .

 Then, as shown by block 216, the receiver may choose to deliver the message to an inbox of a recipient.

 In another embodiment, the gateway associated with the receiver may deliver the message from a plurality of source addresses to a selected source address. In this embodiment, as part of block 201, a particular sender may register multiple delegated originating bond sender addresses. Each address may have a unique name. One or more routing rules determine how to select an originating message address based on the sender address. If the service operator determines that the Bonded Sender has sent a particular message, the service provider applies the above rules, or injection filter mechanism, to map the source address specified in the message to one of a number of registered addresses. . The service operator provides the mapped source address to the gateway, which forwards the message to that address.

In another embodiment, by prior agreement between the receiver and the service operator, the receiver is required to deliver all messages with registered bonded send addresses to the inbox of the recipient of the message.

As another example, when a receiver delivers a message with a registered bonded sender address to an inbox of a recipient of the message, the receiver marks that the message is from a registered bonded sender. For example, a graphical user interface displaying a message inbox of an account-holder may display an identification icon identifying a message originating from a registered bonded sender. Alternatively, the receiver may modify the subject line of the message to indicate that it is from a registered bonded sender.

As another example, the particular action taken by the receiver may vary, depending on the amount of bond the sender proposed or promised.

According to one embodiment of the present invention, the mail delivery approach provides a system and method in which the receiver of the unsolicited email indicates to the service operator that the message is unnecessary and implicitly requires enforcement of the bond or generation of a penalty. . In another embodiment, a third party server or system may collect such complaints from the receiver. The complaint collector may send a complaint to the service operator, or the service provider may perform any responsive action described herein that the service provider may perform as a proxy for the service operator. An example of a third party that can be used as an inhospital collector is the SPAMCOP ™ service available from SpamCop.net, Inc. in the domain spamcop.net.

In another embodiment, a zone transfer function is provided. Using the zone transfer function, a delegated individual accompanying a receiver can, in a single operation, inform the service operator that multiple servers or other facilities accompanying the receiver have moved to different ranges of addresses.

The administrator of the service operator can also generate reports for senders and receivers. For example, the report can specify the number of queries issued by the receiver, the number of individuals performing the query, which IP address is being queried, and so on.

3 is a flowchart illustrating a process of reporting an unnecessary message. At block 302, the receiver determines that a received message is unnecessary. The receiver may not want the received message for some reason. For example, the unsolicited message may be a "spam" message, the send may not request to be a "non-subscriber" from the mailing list, the sender may not follow the principles of the Direct Marketing Association (DMA), or the sender may be web This message is derived from the failure to provide a "non-subscriber" link on the site, and so on. Determining that a message is unnecessary may also include generating a report of bounced or double-bounced messages.

In block 304, the receiver reports to the service operator that the message is unnecessary. Block 304 may use any of several reporting mechanisms. For example, an enterprise recipient or ISP may report graphical buttons, clickable logos, clickable hyperlinks, and unnecessary messages in the graphical user interface used to view email inboxes. Can provide other selectivity user interface tools. The tool may be labeled, for example, as "Report As 'Spam' To Bonding Organization." Alternatively, the receiver may provide the recipient with a specific address, thus causing unnecessary messages, bounces. Or reports of double bounced messages, messages sent to accounts not intended to receive commercial email, etc. to the specific addresser, etc. The receiver may accumulate or collect these reports and submit them to the service operator in batches. .

In one embodiment, the report that the message is unnecessary includes a source address value, sender ID, recipient ID, and information identifying the claimant or reporting party. The source address value, sender ID and recipient ID can be obtained from the message by the reporting party. The information identifying the fine claimant may constitute a receiver identifier obtained from the service operator by the receiver as part of registration with the service operator.

The use of this system risks the end user falsely reporting that the message is unnecessary in order to intentionally finance the sender. As one embodiment for detecting or preventing such false reports, a verification step is provided, as shown by block 306. For example, block 306 includes displaying to the user in a dialog box that says "You have indicated that the message is unnecessary. Click Next to verify". Alternatively, the message may be provided in an e-mail message delivered to the receiver and automatically generated in response to receiving the unwanted message report.

In one embodiment, block 306 includes a message gateway 102 that performs one or more statistical tests on each message reported as unnecessary. The statistical test attempts to identify signature text in a message where the message is unnecessary and displayed. Alternatively, users can be classified as one of a number of trusted levels. Depending on the credential level involved with the user, it may be determined which test to apply if the message is actually unnecessary. In the cryptographic approach described above, the use of cryptographic tokens provides non-repudiation of the message and prevents the intentional party from falsely insisting on fines for unsent messages.

Alternatively, other security approaches can be used to facilitate nonrepudiation. For example, an SMTP authentication message can be used to verify the sender of the message.

In block 308, the service operator determines whether to impose a penalty. In one embodiment, determining whether to impose a penalty includes determining that a report of an unnecessary message has been received and that the sender of the unnecessary message involves one or more failures to comply with the bonded sender principle. For example, the sender may have previously sent an undeliverable mail that generates a bounce message, or may not provide an unsubscribe mechanism for that user. In another embodiment, determining whether to impose a penalty includes determining whether the sender has exceeded the rate of complaints allowed from all or a particular receiver. For example, the acceptable complaint rate may be one complaint per million messages sent by the sender, but two or more complaints will exceed the acceptable rate.

If the test at block 308 is positive, then at block 310 the service operator penalizes the sender. Block 308 may penalize the sender using any of the approaches described in Section 2.6 herein. This includes charging the sender in a fixed amount for each complaint that exceeds the complaint rate, and for variable amounts depending on the volume of the message.

Depending on internal criteria or economies of scale, the sender may choose to use bonded message delivery for all or selected messages. If the sender chooses not to send a bonded message, the message corresponds to the problem outlined in the background. Enterprises can bond outgoing enterprise messages to reduce the likelihood of legitimate messages being inadvertently blocked.

Accordingly, embodiments of the present invention financially select sender-selected emails so that the selected emails are delivered to the recipient inbox and not blocked by "spam" prevention filters or similar techniques or stored in bulk folds. Provides a thread that can be bonded by In addition, embodiments allow email receivers to ensure that a message required by a recipient is not blocked or stored in the bulk fold as a result of a "fall positive" determination by a "spam" protection filter or similar technique. Embodiments also provide a mechanism that allows the receiver to ensure that financial penalties are enforced for senders that post bonds and send unnecessary messages.

2.3 Cryptographic Approach for Message Source Advertising

In one approach, represented by block 204A of FIG. 2A, the sender advertises one or more network addresses that send bonded messages. In this expression, "advertisement" may consist of registering a bonded sender source address in a database maintained by a service operator. Alternatively, as in block 204B, each sender includes, in each bonded message, a specific message header that identifies that the message is a bonded message.

4 is a block diagram of an electronic message using a cryptographic message header approach. The message 400 largely constitutes a message header 402 and a message body 418. Message header 402 may be specially designed. For example, the sender may include a header designated "X-BSP" in the message. For simplicity of illustration, the message 400 is shown having only a message header 402 and a message body 418. However, in actual implementations, the message may include any number of other headers for proper purposes, such as SMTP headers, MIME headers, and so forth.

In the implementation of FIG. 4, the message header 402 constitutes a sender identifier (“ID”) value 404 and a cryptographic token 406. The sender ID value uniquely identifies the sender of the message 400 from all senders. The plaintext version of cryptographic token 406 consists of sender ID field 408, token ID 410, extinction time value 412, and proposed bond amount 414.

The token 406 also includes a recipient address value 416.

The sender ID field 408 is the same value as the sender ID value 404 and is provided to the non-repudiation base. The token ID value 410 uniquely identifies the current token from all tokens issued with the same sender ID value and the same extinction time value. The extinction time value 412 defines the maximum time that the receiver can report a companion message as unnecessary and thus attempts to penalize the sender for sending the unnecessary message.

The amount of bond 414 offered is the amount of value offered or promised by the sender as a penalty for the sender if the message is found to be unnecessary by the recipient.

In one embodiment, the token 406 encrypts using the public key cryptography principle. For example, the token 406 encrypts with a private key associated with the corresponding public key registered in the service operator.

The receiver of the e-mail message in the format of Fig. 4 obtains the sender ID and token from the message header. The receiver then verifies the message in one of several approaches.

FIG. 5A is a flow diagram of the message verification approach, and FIG. 5B is a flow diagram illustrating additional steps in the method of FIG. 5A. In block 502, the receiver generates a verification message consisting of a sender ID and a token and submits the message to the service operator for verification. In block 504, the receiver decrypts the token. At blocks 506-516, as described below, the service operator performs a series of tests on the values obtained from the decrypted token, places the result indicator in the verification verdict message, and the verification verdict message ultimately Returned to the sender.

Referring to block 506, the service operator tests whether the sender ID is valid. For example, block 506 includes testing the sender ID value 408 obtained from the decrypted token and whether the receiver matches the sender ID provided in the verification message. If there is a match, at block 508, the service operator attaches an confirm sender ID verification flag, or similar value, to the reply message. If it does not match, at block 509 a negative sender ID verification flag is included in the reply message. Alternatively, another flagging or signaling operation is performed so that the service operator verifies that the token is actually generated by the sender.

In block 510, the service operator determines if it has previously processed the same token. For example, block 510 may look up the token ID in a table or mapping maintained by the service operator. The table or mapping stores previously processed token identifiers, along with corresponding sender ID values and expiration time values. If no matching token ID value is found, the test at block 510 yields a negative result. If a matching token ID value is found, the test of block 510 has a positive result.

If a negative result is caused, at block 512, a negative response verify flag is indicated in the verify reply message. If a positive result occurs, at block 511, a positive response verify flag is indicated in the verify reply message. Alternatively, other methods of signaling the results of block 510 may be used. Thus, the verification message is to confirm that the service operator has not seen the current token ID from the current sender in any previous token with the same expiration time value.

Referring to FIG. 5B, at block 514, a test is performed to determine if the sender of the message has sufficient credits or funds deposited to satisfy or cover all existing obligations with the service operator. For example, a sender may include the total value of all proposed bond amounts involved in all messages 400 sent by the sender whose expiration time value 412 has not expired, including den-current messages. You are required to have enough credits or funds to cover this. Testing of block 514 can be facilitated by tracking the total den-current potential penalty liability for each sender and querying the data table maintained by the service operator.

If the sender has sufficient credit or deposit fund, at block 516 a positive credit verification flag is attached to the reply message. If the sender's credit is not sufficient, at block 515 a negative credit verification flag is attached to the reply message.

At block 518, the verify reply message is completed by the service operator. In block 518, for example, the extinction time value 412, the proposed bond amount 414, and the recipient address 416, all obtained from the encrypted token 406, are appended to the verification reply message.

At block 520, the verify reply message is returned to the initial message receiver. Subsequent processing by the receiver is as follows.

5B is a flow diagram illustrating another approach to verifying a message. FIG. 5B shows the steps performed by the message receiver in the format of FIG. These receivers include ISPs, enterprises, and individual end users.

5C is a flow chart for generating a verification message. In block 530 the receiver extracts the sender ID value 404 from the message header 402 of the message 400. The receiver submits the sender ID value 404 to the service operator to request the sender's public key. In response, the service operator looks up the sender's public key in a table, mapping, or database maintained by the service operator, using, for example, the sender ID value 404 as a lookup key or index.

In block 532, the receiver receives the sender's public key in a reply message from the service operator. Using the public key, the receiver reads the cipher of the token 406 of the message header 402, as shown in block 534.

At block 536, the receiver tests if the sender ID is valid. For example, at block 536, the sender ID value 408 obtained from the decrypted token matches the sender ID provided by the receiver in the verification message. If there is a match, at block 538, the receiver records data indicating that it is a positive decision. If it does not match, at block 539, a negative decision is recorded by the receiver. If the receiver has a way to remember that the token was indeed generated by the sender, then no specific data or writing mechanism is needed.

At block 540, the receiver extracts a timeout value, a proposed bond amount, and a recipient address from the cryptographically read token. In block 542, the receiver generates a verification request message that includes the sender ID value, the token ID value, and the expiration time value from the decrypted token. In block 544, the receiver sends the verification request message to a service operator.

In response, the service operator determines whether the same token has been previously processed and whether the sender has sufficient credit or deposit fund covering the den-current latent penalty liability, including all liability limits under the den-current message. . Such response processing may also include the service operator performing the steps of blocks 510-520 of FIG. 5A.

In block 546 the message receiver receives a verify reply message from the service operator. The validation verdict message indicates that in all previous tokens with the same expiration time value, the service operator has seen the den-current token ID from the den-current sender, and the credit or deposit sufficient to satisfy or cover all existing obligations of the sender of the message. It contains data that indicates whether the fund has a service operator.

After performing the approach of FIG. 5A, or the approach of FIG. 5B, the receiver may parse the verification reply message, and based on the values contained therein, the receiver sends the message to the named recipient, You can decide whether to save it in a bulk folder, discard the message, and so on. As a policy, different receivers may set different verdicts for various values of the verification verdict message.

2.4 Decide whether to accept the message

6 is a flow chart illustrating a method of determining whether a received message can be accepted. 6 illustrates a sample processing step performed by the receiver of a message after performing either of the approaches of FIG. 5A or 5B. Other receivers may choose to perform fewer steps than the steps shown in FIG. Alternatively, other processing may be performed as a whole. In addition, the steps of FIG. 6 may be executed in any order.

At block 602, the receiver determines if the expiry time of the received message is within a prescribed range. For example, the receiver may require that the decay time value 412 of the den-current message be at least N days in the future, and thus have sufficient time to allow evaluation of the message, and by the end user or the receiver of the message. You can report the unnecessaryness of a message. The N value can vary widely depending on whether the receiver is an individual end user, an ISP, an enterprise mail server, or some other device or individual. For example, N may vary in the range of 1 to 120.

If the extinction time value is not within the defined range, block 612 is controlled and the message is rejected. Here, the "decline" of the message at block 612 may include storing the message in a bulk mail folder, blocking the message, clearing the message, sending an automatic response to the sender, and the like. No specific rejection mechanism is required, and each receiver can, as a policy, select different processing mechanisms depending on different senders, recipients, or other circumstances.

In block 604, the receiver determines whether the bond amount offered or promised by the sender is greater than the prescribed amount. For example, the receiver may require that the suggested bond amount 414 is at least D when D is a prescribed value. The value of D can vary greatly depending on whether the receiver is a personal end user, an ISP, an enterprise mail server, or some other device or individual. For example, D can range from $ 1 to $ 100 (or the same amount in other currencies). If the proposed or promised bond amount is not within the defined range, block 612 is controlled and the message is rejected.

At block 606, the receiver determines whether the recipient address matches a specified address of the message. For example, the receiver compares the recipient address value 416 with the destination network address appearing elsewhere in the message header 402 or other header, such as an IP packet header. If it does not match, block 612 is controlled to reject the message.

At block 608, the receiver determines whether the verification reply message received as part of participating in the approach of FIG. 5A or 5B includes an indication of validation failure. For example, the receiver examines the various flag values in the verification reply message and determines if the test failed in the particular test of FIGS. 5A and 5B. If so, block 612 is controlled and the message is rejected.

 If all of the tests in blocks 602, 604, 606, and 608 are successful, control of block 610 is executed and the receiver treats the message as "acceptably bonded". As part of the processing, the receiver may accept the message, place the message in the inbox accompanying the recipient, or perform another action.

2.5 Handling of Unsolicited Message Reports

FIG. 7A is a flow chart for verifying unnecessary message reporting, and FIG. 7B is a flow chart showing additional steps in the method of FIG. 7A. The report may be defined as "complaint." Referring to Figure 7A, in general, if the recipient determines that the message is unnecessary, the recipient sends the message token to the service operator and requests the sender to deposit the bond. The receiver, for example, receives the message delivered by the receiver that has performed the processing of FIG. 6 and then performs the determination. The service operator examines the token and other values to determine the request and decides whether to forfeit a bond.

Referring to block 702, a report is received that a message was unnecessary. In one embodiment, the report constructs a message from the recipient to the service operator that includes a sender ID value 404, a cryptographic token 406, and a bond request for collection. The report, or complaint, also includes the network address of the recipient within the complaint message or in the header of the packet carrying the message. For example, a conventional IP packet header carries the address of a packet sender. In response, as in block 704, the service operator reads the cryptogram of the token. The service operator then performs a series of tests on the values associated with the token and the submitter.

In block 706, the service operator determines whether the token was actually generated by the initial message sender. For example, the service operator compares the sender ID value 404 with the sender ID value from the decrypted token. As a result of the comparison, the identified sender is known to have generated a cryptographic token. It is impractical for a cryptographic approach to encrypt the token 406 to be chosen such that an impure sender generates a false token or read the token to know the sender ID value 408.

If the test of block 706 is negative, block 718 (FIG. 7B) is controlled so that the service operator sends an error message to the submeter of the collection request. Here, sending an error message also includes sending an advice message to the submeter indicating that the bond will not be collected. It also includes sending a warning message to the sender of the message and recording these actions in a log or other database.

At block 708, the service operator determines whether the token has not expired. Block 708 examines the decay time value 412 and compares it with the master clock or time value. The time value is represented by Greenwich Mean Time, or the service operator may optionally perform one or more time zone conversion operations. Once the extinction time value 412 has elapsed, block 718 is controlled.

Otherwise, at block 710, the service operator determines if the submeter of the collection request is a valid owner of the intended address of the message. For example, the service operator examines the recipient address value 416 in the decrypted message token 406 and determines if the submeter owns that address. The service operator may determine effective ownership by comparing the recipient address value 416 with the known network address of the recipient based on the address value of the complaint message and the header of the complaint message. Here, judging ownership also includes determining whether a party is a valid proxy for an address. Thus, by using the recipient address identifier in the token 406 of the message 400, it is necessary to require the complaining party to verify that the sender identified in the complaint actually sent the message to the complaining party. Prevents false complaints about unwanted messages. For example, an unsuspecting user may prepare software that automatically creates a large number of identical complaints. However, if the test of block 710 determines that the recipient address value 416 does not match the actual address of the recipient, it is suspected of a fraudulent complaint and under the control of part A of FIG. 7B. Error handling will be performed.

In block 712, the service operator determines if the bond amount for the den-current message has already been forfeited. For example, block 712 checks the lookup of the token in the database of collected bonds maintained by the service operator based on its decay time value and token ID value, thereby denying the den-current token 706. This includes determining whether the bond that appears is drawn. If the bonds involved in the token were previously collected, then control of block 718 (FIG. 7B) is performed.

Referring to FIG. 7B, if all tests in blocks 706, 708, 710, and 712 are positive, then at block 714, the sender is penalized. Any of the approaches in section 2.6 can be used. In block 716, the service operator updates its database with information related to the penalty.

The tests shown in FIG. 7 may be performed in any order. The service operator may also choose to perform other tests as a policy matter.

In addition, the processing of Fig. 7 can complement the dispute resolution processing dealing with false reports of unnecessary messages or reports issued by fraudulent recipients.

2.6 Penalties for Senders

Service operators are designated as bonded but can penalize senders that send messages that constitute "spam" by any of several approaches. FIG. 8 is a block diagram of a banking network and related elements with respect to the system of FIG. 1A that may be used in any approach. The components of FIG. 8 are not necessary for any particular implementation.

The message processing system 106 is communicatively connected directly or indirectly to the banking network 802. One or more storage institutions, such as the sender's institution 804A, the service operator's storage agency 804B, and other storage institutions 804C, are connected to the network 802. Each repository institution 804A, 804B, and 804C constitutes a bank, thrifit, and other institutions that receive and maintain private funds in designated accounts, such as security brokerage. The sender's storage authority 804A sees the account owned by the sender, the service operator's storage authority 804B sees the account owned by the service operator, and the other storage authority 804C sees the receivers, recipients, Or maintain one or more accounts owned by a third party beneficiary 806.

 In one embodiment, penalizing the sender includes causing the sender to collect all or part of the bond that the sender posts with the service operator. If the sender has posted a bond with the service operator, the collection may be to perform an electronic fund move. For example, the service operator causes the sender to extract an amount of value equal to the amount of bond offered by the sender in the message token. This includes moving the fund from an account of a service operator's storage institution 804B, which includes a fund owned by the sender and owned by the service provider, to an account of the other storage authority 804B or to a designated party.

If the sender did not post a bond, penalizing the sender includes the service operator generating a bill to the sender. In response, the sender issues a check or draft of the account name of the sender's storage organization 804A to the service operator. Then, or at the same time, the service operator moves the fund to the receiver, recipient, or beneficiary.

In some embodiments, the amount of penalties imposed on a particular sender for multiple identical "spam" messages is capped to a defined maximum penalty value. For example, a service operator may penalize a sender up to $ 10,000, or some other prescribed amount, even though millions of identical "spam" messages are sent and only a few reports are received from the recipient. Alternatively, the penalty amount may cause the penalty amount to be incrementally increased upon receipt of a prescribed number of "spam" reports, or may be escalated based on the number of "spam" messages sent.

In addition, penalizing the sender may include distributing the fund by dividing the fine to one or more parties, either manually or using an electronic fund transfer or similar mechanism. For example, a fund, monetary value, or other value element representing a penalty for a sender may be sent to the service operator, to the network administrator, to the receiver, from the sender, or from an account with the sender. To the recipient, as credit for the Benefit of the account maintained by the receiver to the receiver (e.g., an end user account with the ISP), to a third-party beneficiary such as a charity, and so forth.

2.7 Evaluation Approach

In some embodiments, the amount of bond deposited in block 202 of FIG. 2A, or the amount of fines held in block 215 of FIG. 2B, or the amount of penalty applied to the sender in block 310 of FIG. It can be determined automatically using an evaluation approach that takes into account the large number of receiver complaints that are likely to be received for the current sender.

10A is a flow diagram illustrating a first method of messaging processing using an evaluation approach. The method of FIG. 10A may be performed by the message processing system 106 of FIG. 1A in response to an inquiry from the incoming messaging gateway 110. At block 1002, a receiver, such as a message gateway, receives a message to send to the recipient. In block 1004, the receiver requests the message processing system to issue advice regarding the received message.

In block 1006, the message processing system determines the amount of bond offered by the sender of the message for every message it sends. For example, block 1006 includes reading a cryptographic token written by the sender of the message that includes the proposed bond amount. In this approach, the suggested amount is not for a single message, but for the total bond amount.

In block 1008, the message processing system calculates the maximum penalty amount applicable to the sender if many or all of the messages are reported as unnecessary by the receiver. The maximum penalty amount is based on the basic penalty amount: (a) the number of complaints about unnecessary messages actually received from the sender, and (b) the estimated number of complaints not reported by the receiver and not reported in the future ("unfiled complaints"). ) Is the sum of

At block 1010, the message processing system compares the bond amount suggested from the message with the maximum penalty calculated at block 1008. If the message processing system determines that the difference between the amount of bond and the calculated penalty amount is greater than zero, as shown in block 1014, the message processing system tells the incoming messaging gateway 110 that the sender is at maximum. The possible penalty is met, that is, the sender is in bonded state. In response, the incoming messaging gateway 110 sends the received message to the recipient 112. Alternatively, if the difference is zero or less, at block 1012, the message processing system 106 informs the gateway 110 that the sender cannot satisfy the maximum prediction penalty. The gateway 110 may request the message processing system 106 to penalize the sender, send the message to the receiver 112, and block the sender.

10B is a flow diagram illustrating a first method of messaging processing using an evaluation approach. In this approach, blocks 1002, 1004, 1006 constitute the same steps as in FIG. 10A. However, at block 1020, the message processing system is responsible for the number of complaints that the sender has proposed or post, the number of complaints about unwanted messages actually received from the sender, and the estimated number of complaints that are not reported by the receiver and will not be reported in the future. The bond ratio value divided by the sum is calculated.

It is assumed that each incoming messaging gateway 110 that connects to the message processing system 106 sets and stores a defined minimum bond ratio value. In block 1022, the message processing system informs the receiver, such as the destination messaging gateway 110, of the calculated bond ratio value. In block 1024, the destination messaging gateway 110 determines whether the calculated bond ratio value is equal to or greater than the gateway's prescribed minimum bond ratio value. If equal or greater, as in block 1028, the gateway 110 accepts the received message and sends it to the recipient 112. Otherwise, as in block 1026, the gateway rejects the message, requests the message processing system 106 to penalize the sender, sends the message to the recipient 112, block forwarding, and the like. can do.

The bond value approach provides additional flexibility for the receivers because each of the incoming messaging gateways 110 of the large number of gateways involved in a different number of receivers may have its own prescribed minimum bond ratio value. For example, one ISP may require all senders to have a bond ratio of at least 10 and another ISP may require a minimum of 20. Thus, the receiver can, to some extent, customize the operation of the message processing system 106.

In addition, the bond ratio approach determines how the receiver compares the first sender to the second sender for actual complaints, rather than simply determining whether the first sender can withstand a certain penalty amount, as in the approach of FIG. 10A. It allows you to decide. For example, the receiver may rate a particular sender based on the determined bond ratio value. The bond ratio may be considered the sender's experience or rating.

Further, the bond ratio does not include the penalty amount. Thus, by using bond ratios, there is a way to apply a negative experience rating to a sender without requiring the sender to post a bond in advance and without actually charging a fund from the sender or imposing specific financial penalties on the sender. to provide. For example, as another alternative to withhold a fine of block 215 of Figure 2B, the bond ratio value of the sender is recalculated and stored. Similarly, at block 218, the bond ratio value of the sender may be recalculated to reflect the negative experience with the sender. As another example, penalizing a sender in block 310 of FIG. 3 includes recalculating and storing the bond ratio value for the sender without actually fiscal penalty on the sender. The recalculation of the bond ratio value may be performed at block 520 of FIG. 5B, or at blocks 610 and 612 of FIG. 6, or at block 7 of FIG. 7 to account for the values of sender, reply, credit verify flags. 714). As bond ratios deteriorate, the sender loses the ability to send messages through gateways that contact the message processing system.

In any of the above approaches, a number of complaints that have not yet been submitted or will not be submitted by the receiver are predicted and calculated. This calculation can be performed using several mechanisms. For example, by prescribing a certain predictive value from mapping the predicted value to the volume level, an assessment can be determined based on the volume of the message sent. Using this mechanism, a defined window tine, for example a sender that sends 1,000,000 messages in 24 hours, can be assigned an estimated number of complaints of 100. Alternatively, if the sender sends 10,000,000 messages in 24 hours, the message processing system 106 may assume that 1,500 complaints will be received in the future. Recipients require a certain amount of time to receive, read, and evaluate a message, so a prescribed time window is used because at least several to several days of delay may elapse between sending and receiving a message.

As a variant of this approach, it is possible to scale the number of evaluated complaints along the length of the time window. For example, if the time window is three days, one complaint rate can be applied to the first 24 hours, the second other complaint rate to the second 24 hours, the third other complaint rate to the third 24 hours, and these three ratios combined to average complaints When the rate is reached, multiplying this by the message volume yields a final assessment of the complaint volume.

These approaches address potential problems with how to handle senders that are newly bonded and immediately send large amounts of messages. Since such senders previously had no actual complaint rate, assuming or estimating any number of complaints for a given volume of outgoing messages can expect better operation of the message processing system and better receiver satisfaction.

Alternatively, the actual complaints may be counted over a defined time window, making an assessment that is an empirical complaint rate. The estimated assessment may apply a scaling value to the historical dissatisfaction rate in order to find the relationship between the actual number of messages sent and the dissatisfaction rate.

3.0 Implementation Mechanisms-Hardware Overview

9 is a block diagram illustrating a computer system 900 implementing an embodiment of the present invention. The computer system 900 includes a bus 902 or other communication mechanism for information communication, and a processor 904 coupled to the bus 902 for information processing. Computer system 900 also includes main memory 906 coupled to bus 902 for storing information and instructions to be executed by processor 904, such as random access memory (RAM) or other dynamic storage devices. do. The main memory 906 may be used to store temporary variables or other intermediate information during execution of instructions executed by the processor 904. Computer system 900 further includes a read only memory (ROM) or other static storage device coupled to bus 902 to store static information and instructions for processor 904. A storage device 910, such as a magnetic disk or an optical disk, is connected to the bus 902 to store information and commands.

Computer system 900 may be coupled to display 912, such as a cathod ray tube (CRT) for displaying information to a computer user, via bus 902. An input device 914 comprising alphabets, numbers, and other keys is coupled to the bus 902 to communicate information and command selections to the processor 904. Another type of user input device is a cursor control 916 for communicating directional information and command selection to the processor 904 and controlling cursor movement on the display 912, such as a mouse, trackball, stylus, or cursor arrow keys. The input device typically has two degrees of freedom, two axes that allow the device to define a position on a plane, i.

The present invention relates to the use of computer systems for electronic message delivery approaches. According to one embodiment of the invention, an electronic message delivery approach is provided by computer system 900 in response to processor 904 executing one or more sequences of one or more instructions contained in main memory 906. . Such instructions may be read into main memory 906 from other computer reading media, such as storage 910. Execution of the sequence of instructions included in main memory 906 causes processor 904 to perform the processing steps described herein. Alternatively, hard-wired circuitry may be used in place of or in combination with software instructions that implement the invention. Thus, implementations of the invention are not limited to any particular combination of hardware circuitry and software.

The term "computer-readable medium" herein refers to any medium that participates in providing instructions to the processor 904 for execution. Such media can take many forms, including but not limited to, nonvolatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical disks, such as storage 910, or mechanical disks. Volatile media includes dynamic memory, such as main memory 906. Transmission media include coaxial cables, copper wire, and optical fibers, including the wires that make up the bus 902. Or the transmission medium may take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

Conventional forms of computer readable media may include, for example, floppy disks, flexible disks, hard disks, magnetic disks, or other magnetic media, CD-ROMs, other optical media, punch cards, paper tapes, or other holes (e.g., physical media with hole patterns, RAM, PROM, EPROM, FASH-EPROM, other memory chips or cartridges, carrier waves described later, or other computer readable media.

Various forms of computer readable media are used to convey one or more sequences of one or more instructions to the processor 904 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer loads the commands into dynamic memory and sends the commands over a telephone line using a modem. A modem confined to computer system 900 receives data over a telephone line and converts the data into infrared signals using an infrared transmitter. The infrared detector receives the data contained in the infrared signal, and an appropriate circuit places this data on the bus 902. Bus 902 carries data to main memory 906, where processor 904 searches for and executes instructions. Instructions received by main memory 906 may optionally be stored in storage 910 before or after being executed by processor 904.

The computer system 900 also includes a communication interface 918 connected to the bus 902. The communication interface 918 provides a bidirectional data communication connection to a network link 920 connected to the local network 922. For example, communication interface 918 may be an integrated servies digital network (ISDN) card or modem that provides a data communication connection to a corresponding type of telephone line. As another example, communication interface 918 may be a local area network (LAN) card that provides a data communication connection to a compatible LAN. Wireless links may also be implemented. In such implementations, communication interface 918 transmits and receives electrical, electronic or optical signals that carry digital data streams representing various types of information.

Network link 920 typically provides data communication to other devices over one or more networks. For example, network link 920 may provide access to data equipment operated by host computer 924 or ISP 926 via local network 922. ISP 926 again provides data communication services via a worldwide packet data communication network (928). Local network 922 and the Internet 928 both use electrical, electromagnetic, and optical signals that carry digital data streams. The signals over the various networks, the signals on the network link 920, and the signals over the communication interface 918, which carry digital data to and from the computer system 900, are in the form of representative carrier waves that carry information.

Computer system 900 may transmit and receive data including program code via network (s), network link 920, and communication interface 918. As an Internet example, server 930 may send a request code of an application over the Internet 928, ISP 926, local network 922, and communication interface 918. In accordance with the present invention, this downloaded application enables the electronic message delivery approach described herein.

The code received as above may be executed by the processor 904 as it is received and / or stored in storage 910 or non-volatile storage for later execution.

4.0 extensions and replacements

While the invention has been described with reference to a few specific embodiments so far, those skilled in the art can make various changes and modifications to the invention without departing from the spirit and scope of the invention as defined in the appended claims. have. Accordingly, the specification and drawings are for the purpose of illustrating the invention and are not intended to limit the invention thereto.

Claims (69)

As a way to facilitate the transfer of messages from senders to receivers, The sender storing the sender ID information along with a penalty for the receiver to generate an undesired first message, Receiving an inquiry as to whether the sender of the first message satisfies a prescribed origination criterion; Determining whether the sender satisfies the prescribed calling criterion, and Sending a second message specifying whether a sender of the first message satisfies the prescribed origination criteria for use by the receiver in determining whether to accept the first message. The method according to claim 1, wherein the determining step comprises: (a) the actual number of complaints about unnecessary messages actually received from the sender and the (b) the receiver or any other receiver, in which the penalty is a basic penalty amount; Determining whether the sum is greater than the sum of the estimated number of complaints not to be multiplied. 3. The method of claim 2, further comprising: rejecting acceptance of the first message when the penalty is not greater than the basic penalty amount multiplied by the sum of (a) and (b). Way. 2. The method of claim 1, wherein the determining step further comprises determining a sender experience value for the sender of the first message, wherein the sender experience value is an actual message relating to an unnecessary message actually received from the sender. Calculating by dividing the number of complaints with an estimated number of complaints not yet or not received by the receiver or other receiver. 5. The method of claim 4, further comprising denying acceptance of the first message if the sender experience value for the sender of the first message is less than a prescribed minimum sender experience value. As a way to facilitate the transfer of messages from senders to receivers, Storing a sender ID information with a penalty value sent by the sender to the receiver and confirming the amount of money the sender is willing to pay for a particular message that the receiver does not want; Receiving an inquiry as to whether a first message from the sender corresponds to a penalty offered by the sender; Determining whether the first message corresponds to a penalty suggested by the sender, and And sending a second message that defines whether the first message corresponds to a penalty offered by the sender. 7. The method of claim 6, further comprising receiving a third message indicating that the first message is unnecessary. 8. The method of claim 7, further comprising comparing a source network address of the third message with a recipient address in the first message and verifying that the third message is a legitimate message. The method of claim 6, Receiving a third message from the receiver indicating that the first message is unnecessary; and And sending money from the sender's account in response to receiving the third message. The method of claim 6, further comprising: receiving a third message from the receiver indicating that the first message is unnecessary, and determining a sender experience value for the sender of the first message in response to receiving the third message. Further, the sender experience value is calculated by dividing the penalty by the sum of the actual number of complaints about unnecessary messages actually received from the sender and the estimated number of complaints that have not been or will not be received by the receiver or any other receiver. Characterized in that. The method of claim 6, Receiving a third message from the receiver indicating that the first message is unnecessary; and And transmitting a value from the sender in response to receiving the third message, wherein the value sent from the sender is equal to the penalty value. The method of claim 6, After sending the second message, receiving a request to hold an amount of money equal to the penalty value; In response to receiving the hold request, storing a pending penalty value with the sender ID data; Receiving a third message from the receiver indicating that the first message is unnecessary; and In response to receiving the third message, transmitting a value from the sender. The method of claim 6, Sending a penalty value as part of the second message; Receiving a third message from the receiver indicating that the first message is unnecessary; In response to receiving the third message, transmitting a value from the sender. 7. The method of claim 6, wherein said first message is an e-mail message. 7. The method of claim 6, wherein said first message is a telephone message. 7. The method of claim 6, wherein said first message is an e-mail message and said inquiry is received from an e-mail service provider. 7. The method of claim 6, wherein the first message is a telephone message and the inquiry is received from a telephone network service provider. 7. The method of claim 6, wherein the storing step is accompanied by a plurality of penalties that are sent by the sender to receivers and identify a number of different monetary values that the sender is willing to pay for messages that the receiver does not want. Storing sender ID information, wherein each of the plurality of penalty values is associated with one of a plurality of receivers. 7. The method of claim 6, wherein the storing step is accompanied by a plurality of penalties that are sent by the sender to receivers and identify a number of different monetary values that the sender is willing to pay for messages that the receiver does not want. Storing sender ID information, wherein each of the plurality of penalty values is associated with one of a plurality of categories of receivers. 7. The sender of claim 6, wherein the storing step includes a sender with a plurality of penalty values that are sent by the sender to the receiver and confirm the amount of a plurality of other monetary values that the sender is to pay for an unwanted message. Storing ID information, wherein each of the plurality of penalty values is accompanied by one of a plurality of categories of messages. 7. The sender of claim 6, wherein the storing step includes a sender with a plurality of penalty values that are sent by the sender to the receiver and confirm the amount of a plurality of other monetary values that the sender is to pay for an unwanted message. Storing ID information; Receiving a third message from the receiver indicating that the first message is unnecessary; and In response to receiving the third message, selecting a value that is less than or equal to the penalty value, and transmitting the selected value from a sender. The method of claim 6, Receiving a third message from the receiver indicating that the first message is unnecessary; and In response to receiving the third message, transmitting a value from the sender, and transmitting a portion of the value to the recipient. A method of sending a bonded message to a recipient, If the recipient receives the unnecessary bonded message, agreeing with the service operator for a penalty; Sending a bonded message to the recipient, and Paying a penalty in response to a reply indicating that the bonded message is unnecessary. A method for processing an electronic message, Receiving a first message from a sender sent to the intended recipient, Requesting a service operator to determine whether the first message is bonded; Receiving a second message from the service operator indicating that the first message is bonded; and And sending the first message to the intended recipient only when the second message indicates that the first message is bonded. A method for processing an electronic message, Receiving a first message from a sender sent to the intended recipient, Requesting a service operator to determine whether the sender of the first message satisfies a prescribed sending criterion; Receiving, from the service operator, a second message indicating that the sender meets the prescribed shipping criteria, and And sending the first message to the intended recipient only when the second message indicates that the sender of the first message satisfies the prescribed shipping criterion. 26. The method of claim 25, wherein the second message indicates, with respect to the sender, that the amount of money the sender agrees to collect is greater than the penalty, wherein the penalty is (a) to the sender. And (b) multiplying the actual number of complaints about unnecessary messages actually received by the sum of estimated complaints not yet or not yet received by the receiver or other receivers. 27. The method of claim 26, further comprising transmitting the first message only when the amount of money is greater than the penalty. 26. The method of claim 25, wherein the second message includes a sender experience value for the sender of the first message, the sender experience value being equal to the actual number of complaints about the unsolicited message actually received from the sender for the penalty. Calculating by dividing by the sum of the estimated number of complaints that have not yet or will not be received by the receiver or other receivers. 29. The method of claim 28, further comprising transmitting the first message only if the sender experience value for the sender of the first message is greater than or equal to a prescribed minimum sender experience value. 27. The method of claim 25, wherein the second message includes a penalty value for identifying the monetary penalty the sender is to pay if the recipient indicates that the first message is unnecessary. . 26. The method of claim 25, wherein the second message includes a penalty value for identifying the monetary penalty the sender is to pay if the recipient indicates that the first message is unnecessary, and the requesting step includes: Requesting a service operator to determine whether the first message is bonded by comparing the penalty value with a prescribed threshold value. 26. The method of claim 25, wherein the second message includes a penalty value for identifying the monetary penalty the sender is to pay if the recipient indicates that the first message is unnecessary, and the requesting step includes: Requesting a service operator to determine whether the first message is bonded by comparing the penalty value with a prescribed threshold value, wherein the prescribed threshold value is determined to the identity of the intended recipient. Selected based on the method. A method for managing an electronic message sent by a sender to a recipient. Receiving consent to pay the penalty from the message sender, Receiving one or more indications that a message sent by the message sender is unnecessary by one or more of the message recipients; Creating and storing one or more records of the indication, and Imposing a penalty on the message sender according to the number of indications received; The penalty is based on the determination that the one or more messages sent by the message sender to the message recipient are unnecessary by the message recipient. 34. The system of claim 33, wherein the amount of money the sender agrees to collect for the sender is based on a basic penalty amount: (a) the actual number of complaints about unnecessary messages actually received from the sender and (b) the Informing the receiver if the receiver or other receiver is greater than the product of the sum of estimated complaints that have not been or have not yet been multiplied. 34. The method of claim 33, further comprising informing the recipient of a sender experience value for the sender of the first message, wherein the sender experience value relates to an unnecessary message that actually received the penalty from the sender. Calculating by dividing the actual number of complaints with the estimated number of complaints not yet or not received by the receiver or other receiver. 34. The method of claim 33 wherein the electronic message is an email message. 34. The method of claim 33, wherein said electronic message is a telephone call. 34. The method of claim 33 wherein the electronic message is a pager message. 34. The method of claim 33, wherein the penalty is determined by multiplying the number of indications by a prescribed penalty amount. 34. The method of claim 33, wherein the penalty is limited to the maximum penalty amount specified for all indications received in a particular time period. 34. The method of claim 33, wherein the penalty is determined by multiplying the number of indications received by a penalty value selected from one of a plurality of penalty values based on the number of indications received. 34. The method of claim 33, wherein the penalty is a fixed amount per indication above an allowed complaint rate. As a way to penalize senders for sending unwanted messages to recipients, Receiving information indicating that the sender has deposited a monetary value in an account accompanying the information identifying the sender; Receiving from the sender information identifying the message known as an unnecessary message sent to the recipient from the sender; Determining that the unwanted electronic message is unnecessary, and Penalizing the sender by sending some or all of the monetary value from the account to a service operator, receiver or recipient in response to determining that the unwanted electronic message is unnecessary. Characterized in that the method. A method of operating an electronic message gateway, Receiving an electronic message from the sender, Determining whether the sender is identified in a list of known senders; Determining if the message is a large number of unwanted electronic messages, and In response to determining that the electronic message is a large number of unwanted electronic messages, some or all of the monetary value held in the account accompanying the sender may be transferred from the account accompanying the sender to the service operator, receiver, or electronic message. Issuing one or more commands to send to the recipient. A method of operating an electronic messaging system, Receiving information indicating that the sender has deposited a monetary value in an account accompanying the information identifying the sender; Receiving an electronic message from the sender, Determining whether the sender is identified in a list of known senders; Determining whether the message is an unnecessary message, and In response to determining that the electronic message is an unnecessary message, transferring some or all of the monetary value from an account associated with the sender to a service operator, receiver, or the recipient of the electronic message. Characterized in that the method. 46. The method of claim 45, further comprising directly or indirectly receiving information from the sender from the sender that identifies a message known as an unwanted message sent to the recipient, and Based on the information from the recipient, in response to determining that a message known as the unwanted message is unnecessary, some or all of the monetary value from the account may also be sent to a service operator, receiver, or the recipient. The method further comprises the step of transferring. As a way of penalizing the sender of unwanted messages that are passed to the recipient through the receiver, The sender receiving a cryptographic token provided in the message; Determining whether the sender actually generated the token based on the value of the cryptographic token, If the message is unnecessary for the recipient, determining if the sender has sufficient credit to be penalized; Sending a response message confirming that the sender actually generated the token and that the sender has sufficient credits; Receiving information indicating that the message is unnecessary, and Penalizing the sender. 48. The method of claim 47, further comprising determining in the cryptographic token whether a recipient address value matches a known network address of the recipient. 48. The method of claim 47, wherein the cryptographic token comprises a sender identifier, a token identifier, and a penalty amount suggested by the sender. 48. The method of claim 47, wherein the cryptographic token comprises a sender identifier, a token identifier, a penalty amount proposed by the sender, and an expiration time. 48. The method of claim 47, wherein the value of the cryptographic token comprises a sender identifier, a token identifier, a penalty amount offered by the sender, and a recipient address. 48. The method of claim 47, further comprising verifying that the cryptographic token has been previously processed and generating a value in the reply message indicating that the cryptographic token has been previously processed. 48. The method of claim 47 wherein the value of the cryptographic token has a decay time value, Determining whether the extinction time value has elapsed; And accepting the message only when the expiration time value has not elapsed. 48. The method of claim 47 wherein the value of the cryptographic token has a penalty amount suggested by the sender, Determining, by the sender, whether the amount of penalty offered is greater than a prescribed minimum penalty value; And the sender accepts the message only if the suggested penalty amount is greater than a prescribed minimum penalty value. 48. The method of claim 47, wherein the value of the cryptographic token comprises the recipient address value, Determining whether the recipient address value matches a destination address value of the message header; And accepting the message only if the recipient address value matches the destination address value of the message header. 48. The method of claim 47, further comprising accepting the message only if the sender actually generated the token. 48. The method of claim 47, further comprising penalizing the sender only when it is determined that the complaint message comprising the token actually originates from the recipient of the first message. 48. The method of claim 47, further comprising the step of accepting the message only if the sender has sufficient credit to cover the penalty if the message is unnecessary for the recipient. The method of claim 47, Receiving the information and the cryptographic token specifying that the message is unnecessary; And based on a sender identifier of the token, penalizing the sender only when it is determined that the sender actually generated the token. The method of claim 47, Receiving the information and the cryptographic token specifying that the message is unnecessary; Penalizing the sender only when it is determined that the token has not expired, based on the expiration time value of the token. The method of claim 47, Receiving the information and the cryptographic token specifying that the message is unnecessary; Based on the token, further comprising the step of penalizing the sender only if it is determined that the sender has not previously paid a penalty for another message accompanying the same token. 48. The sender of claim 47, wherein based on the token's recipient address, the sender is sent to the sender only if it is determined that the submeter of the information that specifies that the message is unnecessary actually owns or is accompanied by the recipient address. And further penalizing the penalties. 48. The method of claim 47, wherein penalizing the sender comprises a service operator issuing a bill to the sender to pay a fine. 48. The method of claim 47, wherein the penalizing of the sender is such that the service operator is responsible for transferring the funds previously provided by the sender from the first account associated with the service operator to the receiver, the recipient, or any beneficiary. A method comprising moving to two accounts. A computer readable medium carrying one or more sequences of instructions for carrying an electronic message, wherein the instructions, when executed by one or more processors, cause the instructions to be executed by the one or more processors. A computer readable medium, characterized in that it performs the steps of any one of claims 24, 25, 33, 42, 43, 44, 45, or 47. An apparatus for generating and storing troubleshooting information for delivering an electronic message, the apparatus comprising: 1, 6, 24, 25, 33, 42, 43, 44 45. A device comprising means for performing any of the functions of claim 45 or 47. An apparatus for delivering electronic messages, A network interface connected to a data network for receiving one or more packet flows; Processor, 47. The processor, when executed by the processor, is characterized in that the processor is one of the following claims: 1, 6, 24, 25, 33, 42, 43, 44, 45, or 47. Apparatus comprising one or more sequences of instructions to perform the steps of any one of the claims. The method of claim 1, wherein the penalty comprises money, finance, goods, service, or appointment. The method of claim 6, Receiving a third message from the receiver indicating that the first message is unnecessary; Determining whether the third message exceeds an acceptable dissatisfaction rate associated with the sender, and When the dissatisfaction rate is exceeded, claiming a value from the sender.

Images