Communication management using a token action log

[0001] This application is related to and claims the benefit of U.S. Provisional Application No. 60/415,321, filed Sep. 30, 2002, for “Function and Use of a Token Action Log,” with inventor Scott E. Sampson, which application is incorporated herein by reference in its entirety.

[0002] © 2003 Scott E. Sampson. A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 37 CFR § 1.71(d).

[0003] The present invention relates generally to communication systems. More specifically, the present invention relates to a system and method for managing communications using a token action log.

[0004] With the recent explosion of new communication options, including email, instant messaging, and cellular telephony, a greater need exists for ways to manage the myriad of communications that a person receives each day. Unfortunately, unsolicited commercial solicitations, often referred to as “spam,” make communication management difficult.

[0005] Internet Service Providers (ISPs) and other businesses lose millions of dollars and countless hours of lost productivity as a result of unsolicited commercial email. Spam clogs the Internet, computer systems, and email accounts, slowing down operations and, at times, causing system shutdowns and failures. Expenses include the cost of new computer hardware to handle the increased flow of email created by spam, filtering software to cut down the flow of spam, and staff time spent identifying and deleting junk email.

[0006] Spam also hurts consumers. Many people still pay hourly rates for Internet access, including those who use wireless Internet services and business travelers who download email while on the road. These consumers have to pay for the time they spend downloading these unsolicited messages to their computer from the Internet.

[0007] Most ISPs also limit the space available in account mailboxes for consumers to store email messages. Spam fills mailbox space that consumers could utilize for other purposes. It also becomes inconvenient to sort through when an individual is checking for personal messages in an email account.

[0008] The content of spam is also a troublesome issue. While some spam messages are from legitimate businesses, a majority of these emails are promoting various scams and schemes or sexually oriented Web sites. Many people become victims of the “get rich quick” schemes in these emails. In other situations, pornographic images and messages end up in the mailboxes of unsuspecting families with children.

[0009] Current technical solutions are generally regarded as inadequate to stop the flow of spam and other unsolicited communications. Most technical solutions attempt to find a balance between spam elimination and reducing false positives (i.e. removal of legitimate messages). However, no prior solution is perfect. Aggressive spam-elimination systems result in too many false positives, while more conservative systems fail to block a large number of spam messages.

[0010] Of course, unsolicited communications are not limited to the Internet. Many people still receive unsolicited telephone calls and facsimiles, despite tougher legislation and state and national do-not-call lists.

[0011] A further problem is found in the great quantities of desirable communication that is received. Even though much communication is desired, excessive communication can lead to “information overload.” One effect of this problem is an inordinate amount of time that it takes to sort through and process the desirable communication. Mechanisms are needed for more effectively managing all types of communication that is received, both desirable and undesirable communication.

[0012] In one embodiment, a communication system includes a token generator to create one or more tokens and a token action log to associate each token with a customizable set of one or more actions. Each token is to trigger the associated set of one or more actions in response to accompanying a communication that experiences an event. The event may be receiving the communication within the communication system. Other events are contemplated, however, such as deleting the communication, reading the communication, printing the communication, forwarding the communication, replying to the communication, and archiving the communication.

[0013] In addition to a code, symbol, or other identifier, tokens may include or be associated with various other information, such as an indication of an issuer of the token, an indication of one or more entities to whom the at least one token is issued, and/or an indication of an intended purpose for the at least one token.

[0014] The communication system may be embodied as any audio, video, or text messaging system, non-exhaustive examples of which include an email system, a telephone system, an instant messaging system, and a short text messaging system.

[0015] In one embodiment, the communication system also includes a token distributor to make the one or more tokens available for distribution to entities potentially desiring to communicate with the communication system.

[0016] Each token may correspond to a group of entities. For example, tokens may correspond to groups of entities including family members, friends, business associates, and students within a particular class.

[0017] The token distributor may distribute the tokens to the corresponding groups of entities in various ways. For example, the token distributor may publish at least a subset of the tokens in a document viewable by entities potentially desiring to communicate with a user of the communication system. An example of this document may include an online directory, a printed directory, a business card, or a course syllabus.

[0018] The token distributor may also transmit at least a subset of the tokens in a communication to one or more entities potentially desiring to communicate with the communication system. The communication may be an email message, telephone call, or other type of communication.

[0019] In one embodiment, the system also includes a communication receiver to receive a communication accompanied by a specific token previously generated within the communication system. A lookup module within the system searches the token action log for a set of one or more actions associated with the specific token.

[0020] The system further includes an action manager to execute the set of one or more actions found by the lookup module. Various actions are possible within the scope of the invention. For example, one action may be presenting the communication to an operator of the communication system (e.g., receiving the communication into an inbox). Other actions may include, without limitation, rejecting the communication, sending a reply to the communication, tagging the communication with an identifier, deleting the communication, forwarding the communication to a recipient, activating a device, audibly alerting the user of the communication system, visually alerting the user of the communication system, extracting information from the communication, modifying the token action log, generating a new token, and sending a previously generated token.

[0021] In certain embodiments, an action includes conditional (if-then-else) logic. Moreover, a token may include or be associated with a set of parameters, in which case the action manager is to execute the set of one or more actions by calling an appropriate function with the set of parameters.

[0022] In one implementation, tokens may include or be associated with conditions for token use, and the system is to perform one or more operations (such as rejecting the communication) in response to the conditions. The conditions for use may include, for example, an expiration date or a set number of uses of the token.

[0023] Where a communication is accompanied by an additional token, the lookup module is to search the token action log for a second set of one or more actions associated with the additional token, after which the action manager is to execute the second set of one or more actions.

[0024] In certain embodiments, a token distributor may receive a communication that does not include a token. In response, the token distributor may request an acknowledgement from the sender of the communication. Thereafter, the token distributor may transmit a token to the sender only in response to receiving the requested acknowledgement. The acknowledgement may be required to include a statement of the sender's purpose for the communication, in which case a user of the communication system may be prompted to decide whether a token is to be issued.

[0025] To prevent automatic acknowledgements, the token distributor may send a communication to the sender including an image attachment (e.g., GIF, JPEG) that depicts a code. The message may further instruct the sender to send an acknowledgement including the depicted code, in which case a token is sent only if the acknowledgement includes the code.

[0026] In some cases, the token distributor may automatically assign a token to a communication that did not arrive with a token. This may occur, for example, where the return address for the communication is found in an address book of a user of the communication system.

[0027] Additional aspects and advantages of this invention will be apparent from the following detailed description of preferred embodiments, which proceeds with reference to the accompanying drawings.

[0060] Reference is now made to the figures in which like reference numerals refer to like elements. For clarity, the first digit or digits of a reference numeral indicates the figure number in which the corresponding element is first used.

[0061] In the following description, numerous specific details of programming, software modules, user selections, network transactions, database queries, database structures, etc., are provided for a thorough understanding of the embodiments of the invention. However, those skilled in the art will recognize that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc.

[0062] In some cases, well-known structures, materials, or operations are not shown or not described in detail to avoid obscuring aspects of the invention. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0063] While the following description uses numerous examples involving communication management, those of skill in the art will recognize that the principles disclosed herein are also applicable to other fields. Similarly, while the following description makes frequent mention of “messages,” other types of “objects” are included within the scope of the invention.

[0064] Referring to FIG. 1, a token issuer may have a message device 102, such as a cellular telephone, an email client, a web server, etc. As described in greater detail below, the message device 102 includes a token action log manager (TLM), which is typically a software module for creating token action log entries, issuing tokens and managing any actions associated with the tokens in the token action log. The TLM may be part of a communication system, such as an email system, a telephone system, an instant messaging system, or a paging system.

[0065] The token issuer creates tokens and issues 104 specific tokens to specific potential token users. The users may correspond to a particular group or class, i.e. family members, friends, business associates, and students within a particular class. However, unique tokens can be issued to individual users. Multiple tokens with different purposes may be distributed to one or more entities.

[0066] In some situations, the token user might be the same as the token issuer, or might be a separate process running on the token issuer's message device 102. However, usually the token user is some other entity that desires to communicate or otherwise interact with the token issuer. When a new token is created by the token issuer, the token and a corresponding set of one or more actions are recorded in the issuer's token action log.

[0067] In one embodiment, the set of actions is customizable, i.e., a user may specify or select various actions to be associated with a particular token. As described below, certain actions may be able to spawn one or more other actions. In addition, certain actions may include conditional (if-then-else) logic. Various actions are possible within the scope of the invention, examples of which include rejecting a communication, sending a reply to a communication, tagging a communication with an identifier, deleting a communication, forwarding a communication to a recipient, activating a device, audibly alerting a user of a communication system, visually alerting a user of a communication system, extracting information from a communication, modifying a token action log, generating a new token, and sending a previously generated token.

[0068] In one embodiment, a token action log is a list of tokens that have been issued, including conditions under which they can be validly used and actions that they motivate. A token action log may also contain other information, such as the actual purpose of the token and the communicated purpose, as well as conditions under which a given token is valid. Other possible names for a token action log include “token repository,” “token registery,” “token register,” etc. However, the term “token action log” will be used herein, or “token log” for short.

[0069] When a token user's message device 106 receives a new token, the received token may be kept in an address book or in some other token store. Note that this token store is different from a token action log. A token action log contains tokens issued by that person. A token store, or address book, contains tokens issued by others.

[0070] When appropriate, the token user returns 108 one or more tokens issued by a token issuer back to the token issuer, usually as part of some message (or other object). When previously issued tokens are received by the issuer, the issuer's message device 102 takes appropriate actions as noted in the issuer's token action log.

[0071] As described in greater detail below, receiving a communication with a token is only one “event” that may cause an associated action to be performed. Other events that may trigger actions include deleting the communication, reading the communication, printing the communication, forwarding the communication, replying to the communication, and archiving the communication.

[0072] For clarity, FIG. 1 does not depict encryption or complex authentication in the communication. Certainly, issued tokens or tokens being used can be encrypted to prevent interception in route. In addition, methods can be employed to verify that the token user is in fact the entity the user purports to be. Various encryption and authentication methods could be used for that purpose.

[0073] FIG. 2 describes a process for issuing tokens. The procedure begins by the issuer desiring to have a token issued 202. Perhaps an individual desires to communicate with the issuer, and realizes that effective communication requires tokens. Alternatively, the issuer is expecting a message from a company or individual, but does not want to receive subsequent messages from that company or individual (e.g., junk messages or “spam”).

[0074] In this context, a “token” is a symbol that potentially initiates action on the token issuer's message device. The precise format of tokens is not crucial. For example, a token may be an series of alphanumeric characters surrounded by XML tags <token> and </token>. A token used in telephone communication may be be a series of numbers that could be sent with a phone number. A given phone number might be followed by #token, such as 555-1212#8793, where 8793 is the token used by that token user. In still other embodiments, a token may be a series of alphanumeric characters preceded by some unique tag such as the letters “tk.”

[0075] For email systems, the token might be included in the MIME headers (i.e. in a “token:” header field), in the subject of the message, in the body of the message, or as part of the token issuer's email address. The RFC822 email address specification allows for an email user's name, the email address, and a comment in parenthesis. Hence, the token may be included in the comment portion of the email address. An advantage of that method is that those comments are often captured in email client address books, for later use.

[0076] Tokens may also come in a message that includes data that serves as parameters to be used by the token actions. Token parameters may be specified in various data formats. The following are some examples . . . .

[0077]

	tk123abc:purposes(parameter_type:parameters)
	tk123abc:purposes(cgi-get:user=samp22
	tk123abc(xml:token_data)

This last example may point to parameters embedded in some XML tags in the message (e.g., <token_data>parameters</token_data>).

[0078] An XML data type definition (DTD) for formatting tokens is shown by the following example:

[0079]

	<?xml?>
	<tokens>
	<token value=‘abc123’>
	<parameters>
	<parameter>
	<name>user</name><value>Smith22</value>
	</parameter>
	<parameter>
	<name>group</name><value>members</value>
	</parameter>
	</parameters>
	</token>
	</tokens>

[0080] Of course, email address specifications may be augmented to allow tokens to be embedded in email addresses, an example of which may be: “#token#[email protected].” This builds upon the idea that the use of a TLM system can be viewed as a token issuer giving different people “different” email addresses for contacting the issuer (but with just one general email account).

[0081] Regardless of the format of tokens, they are created using any suitable method 204. For example, a token could be created as a series of random alphanumeric characters. Alternatively, it could be created from some pre-determined sequence of characters. The token may be given by an operator or may be given by another entity authorized by the operator.

[0082] In one embodiment, the created token is checked to ensure that it is unique—i.e. does not already exist in the issuer's token log. Nevertheless, this check of uniqueness might be omitted if the created tokens are sufficiently random and if the cardinality of possible tokens is sufficiently large. For example, if tokens are defined as a random sequence of six lower-case letters, then there are 26 raised to the 6^th power, or 308,915,776 possible tokens. Even if the issuer has already had 1,000 other unique tokens in the token action log, there is still only a 1 in 308,915.776 chance of a new random token being identical to a previously logged token.

[0083] When a new token is created, it is recorded in the token action log 206. The token action log may also include conditions under which the token is valid, such as date ranges or number of times it can be used. Further, the token action log entry indicates what actions are associated with the given token. The concept of token actions will be apparent in the further explanation of the token handling processes. The issuer has the opportunity to change token action log entries at any time.

[0084] For illustrative purposes, the following are some sample token actions that would be relevant in an email client that incorporates a TLM.

[0085]

TABLE 1
Action	Description
accept;	accepts new message into mail in-box
reject;	avoids receiving the message
prompt;	prompt whether to actually take the
	other specified actions
font(field,attribute[,attribute...])	enclose the field in font attributes, e.g.,
	font(subject,bold)
file(folder name);	files the message in a named folder
reply(message[,email_address[,	sends an email message to
first_name]]);	email address
issue(token,message[,email_ad	issues a given token (or
dress[,first_name]]);	a new token if blank)
set(field,value);	sets the given message field to the given
	value, e.g., set(category,school);
append(field,value);	appends the given field with the given
	value (comma delimited)
record(type,file)	record data in a file using template
	(such as survey response data)
log(type,file)	logs data in a file (again, such as
	survey response data)
run(program,parameters,...)	runs a program
play(multimedia file)	plays music or video
alert(message)	displays a message for the issuer
if_confirm(message)?;	prompt to continue,
delete(message|token);	deletes the message or token
beep(type)	Makes an audible signal
x10(housecode,modulecode,	Sends an X10 command to control
command)	a home device
decrease(token,uses);	Decrease the token “uses” field
cancel;	cancel the requested function (if the
	event is before that function was per-
	formed-otherwise it is probably too late
	to cancel the function)
if_match(messagefield,/re/)?;	Compares a field to a regular expression
else;	Indicates actions if the comparison does
	not match
end_if;	Indicates the end of the “if”
	statement block
treat(standard_treatment);	Use the given actions from the
	standard treatments token action log.

[0086] It is possible that a token issuer may want to have multiple entries for a given token in a given token action log, perhaps with different conditions under which they match or are valid. For example, the token “abc123” might exist in the token action log first as used by person “[email protected]” and second as used by “[email protected].” Yet, it may be more convenient to give those two users their own unique tokens.

[0087] A determination 208 is made whether the issuer desires that the token be sent somewhere, since one use of tokens is for them to be subsequently returned to the issuer. If not, the procedure might simply report 210 that the new token was created, which method is described below.

[0088] Often, new tokens are sent 212 or otherwise communicated to some other individual or entity (specific token “users”) who may desire to communicate with the issuer and can return the tokens to the issuer with future messages. Tokens may be sent any number of ways, such as via email or telephone.

[0089] In certain configurations, tokens may be published in a document viewable by entities potentially desiring to communicate with the issuer. The document may be physical or electronic, and may include, for example, a directory, a business card, or a course syllabus.

[0090] In one embodiment, a token includes an indication of an explanation of what the token is and why it needs to be attached to a subsequent message. Optionally, a token might be sent with an explanation of the intended purpose of the token. Examples of message token purposes may include:

• • [0091] acknowledge receipt of message
  • [0092] answer a question
  • [0093] ask a question
  • [0094] check schedule
  • [0095] identify a general class of token users
  • [0096] request another token
  • [0097] confirm receipt of message
  • [0098] conversation
  • [0099] general purpose
  • [0100] RSVP a meeting request
  • [0101] schedule a meeting
  • [0102] send information
  • [0103] send newsletter
  • [0104] send urgent message
  • [0105] submit survey answers
  • [0106] identify junk email
  • [0107] request authorization of a financial transaction

[0108] The intended purpose of a token might be recorded in the token file. However, it might not always be desirable to make the purpose of the token publicly known. For example, a “delete this message” token might be given to a retailer who is likely to send junk email. The intended purpose of the token is to eliminate messages, but the token issuer would not necessarily want to say that to token users. Instead, the token issuer might want to say that the purpose of the token is “for any messages.” That is the “disclosed purpose.”

[0109] Both the intended purpose and the disclosed purpose might be recorded in the token action log. The disclosed purpose would also be sent with the message when the token is issued or reissued.

[0110] When a new token is sent to a user, it may be desirable to record 214 in the token action log or the token itself an indication of to whom the token was sent. This is useful should the issuer desire to identify who might be impacted should specific tokens be changed. The token action log and/or the token itself may also include an indication of the token issuer.

[0111] FIG. 3 describes one use of tokens—sending them in a message back to the token issuer. In this case, the message sender (i.e. token “user”) sends 302 a message to a receiver who is the token “issuer.” The message is received 304 by the receiver's message device. The receiver's message device contains a token log manager (TLM), which is part of a message processor or works with the message processor (e.g., email client).

[0112] The TLM is called upon to check 306 for actions that correspond to any tokens that are included with the message, given the event of “before message accepted.” The processing of tokens, is described in detail in later figures. The TLM may determine 308 from actions in the token action log that the function to accept the message should be canceled, in which case the message is not accepted and that occurrence is reported 310.

[0113] If the token action log actions do not indicate to cancel the function (or reject the message), then the message processor can perform the function to accept the message (e.g., receive it into the in-box) 312. Thereafter, the TLM again checks the token action log for actions for after the message is accepted 314.

[0114] Referring to FIG. 4, the general use of token action logs can be described via a “Function Initiated” procedure, where a “function” can be any function of the token issuer's device. Functions of message devices include placing calls, filing messages, replying to messages, etc. For message functions, the execution of functions is generally the responsibility of the message processor. For token functions, such as creating a token or deleting a token, the function processing is generally the responsibility of the TLM. Nevertheless, in many cases the TLM is an integral part of the message processor, or it is called by the message processor.

[0115] The procedure begins when a function is initiated 402. The TLM is first called upon to “use the token action log” with the event “before [the given function]” 404. This checks for token actions to be performed before the given function is initiated, which is described in detail in subsequent figures. The token may actually cancel the function 406, in which case the function is not performed and the canceling of the function is possibly reported 408.

[0116] If the function is not canceled, the TLM or message processor initiates the function 410. For example, the message processor may be an email client that has a subroutine that deletes messages. If the TLM determines (via information in the token action log) that the delete function should be canceled, then the email client should not delete the message.

[0117] After a function is performed 410, the TLM again uses the token action log with the event “after [the given function]” 412, which checks for token actions to be performed after that function is performed.

[0118] For example, when a new token is created, the TLM is accessed with the event “after token created” for the new token. Or, if a new token is about to be sent to a potential token user, the TLM is accessed with the event “before token sent.” After the token is sent to the potential user, the TLM is accessed with the event “after token sent.” In this case, we are referring to sending the issuer's token, not a token received from another issuer. The TLM only acts on tokens which are recorded in the communication system's token action log. This includes tokens which were previously created and distributed by the TLM, as well as tokens accepted by the TLM from authorized other entities.

[0119] FIG. 5 shows a “Function Initiated” example of the TLM action to be taken if a previously issued token is re-issued. In this case, the event is a token event, since it was not received as part of a message, at least not until it is attached to a message to be sent to a potential token user.

[0120] As another “Function Initiated” example, FIG. 6 shows the TLM action to be taken if a survey is being sent by a token issuer's message device. In this case, the event is a message event, with the message being the survey. The survey may be sent with a new token or a previously issued token. That token action log may specify actions for the attached token corresponding to the function “before survey sent,” such as to record that the survey is being sent in some list of survey subjects. The token action log might also specify that after the survey is sent with that token the copy of the sent message should be deleted from the sent-items mail box.

[0121] As another “Function Initiated” example, FIG. 7 shows the TLM action on a telephone device when a call comes in. In this example, the incoming phone call is the “message” being processed. The TLM checks the token action log before the call is received (i.e. before it is passed through to the answerer), as well as after it is received. The “function” is receiving an incoming call. The presence of tokens accompanying the incoming call may trigger such token action log actions as loud ringing of important calls, forwarding of calls to other numbers, or playing a prerecorded message to the caller.

[0122] Referring to FIG. 8, there are two general classes of events involving tokens. The first is an object (such as a message) event which an event involving an object that may have one or more tokens attached. Examples of message-object events include: “after message received,” “after message replied,” “before message deleted,” etc.

[0123] The second is a token event which is an event involving a token record in a token action log, independent of any other object, which is called a “token event.” An example will be given below.

[0124] If an object event occurs 802, the object (such as a received message) with any attached tokens are sent to the TLM. The TLM extracts any token(s) attached to the object 804. Then, the TLM looks up the token(s) in the token action log(s) 806. The TLM checks any matching tokens to see if they are expired or not 808, then identifies relevant actions 810. The TLM clarifies the relevant token actions to be performed, as necessary 812. The resulting actions are processed 814. Finally, the outcome is reported to the token issuer, as desired 816.

[0125] As mentioned, it is possible that an event occurs that involves a token itself, but no other object 818. For example, if a token issuer attempts to delete a token, the event “before token deleted” occurs. In this case, the TLM is called with no other object except for the token (or tokens) itself. The “object” is “null,” meaning there is no object 820. The TLM does not need to get the token 804, since the token is already determined. Instead, the token is assumed to be the given token, which is looked up in the token action logs 822. Otherwise, the procedure continues as usual with checking the token match for validity 808, etc.

[0126] The range of possible events triggering the use of a TLM is as wide as the range of possible applications. The events are typically affiliated with functions of the system of application. An event “before [function]” might occur before a function is performed, and an event “after [function]” might occur after the function is performed.

[0127] As an example, an email system might have “before . . . ” and “after . . . ” events corresponding to the following types of functions:

• • [0128] message accepted—a new message is received and accepted.
  • [0129] message deleted—a message is deleted.
  • [0130] message filed—a message is moved to a folder.
  • [0131] message replied—a reply is given to a received message.
  • [0132] message printed—a given message is printed.
  • [0133] message archived—the message is copied to an archive location.
    Any functions of any object processor could trigger an event of relevance to the TLM.

[0134] FIG. 9 is one embodiment of the “get object token(s)” procedure 804. This and subsequent figures consider the “object” being a “message,” even though the object could be something besides a message. Without loss of generality, the term “object” or the name of another object could be substituted for “message” in this and subsequent figures.

[0135] A message (again, this can be read “object”) experiences some event, causing this procedure to be called 902. The message is checked to see if it has one or more tokens 904. If no token is found attached to the object 904, then the “token” is considered to be “(blank)” 906. A “(blank)” token is a token designated to match for messages that have no token. This allows us to look up relevant actions for messages that have no token attached.

[0136] If there are more than one token attached to the message, then it may be necessary to consider each. We begin with the first token present 908. In the case of a “(blank)” token, the first message token is that “(blank)” token. Each token may include parameters 910, which should be noted by the TLM in case they are needed in processing the actions of the token.

[0137] We then look up the token in the token action log(s) and process the relevant actions 914, which is detailed in subsequent figures. If there are no more tokens with this message 914, the procedure ends 916. If there are more tokens, the token issuer (i.e. the person configuring the TLM) may have set a setting to not handle multiple tokens 918, in which case the procedure ends 920. Otherwise, the next message token is retrieved 922 and the procedure repeats by cycling at the point of noting the subsequent token's parameters 910.

[0138] In many applications, it is sufficient for a token user to include one of the token issuer's tokens with a given message. However, other applications may benefit from multiple tokens being sent. The means for dealing with multiple tokens can vary, depending on the implementation. Alternatives include:

• • [0139] The tokens can be processed in the order the appear in the sender's message.
  • [0140] The tokens can be processed in an order based on a priority indicated in the receiver's token action log.

[0141] FIG. 10 is one embodiment of the “look up token(s)” procedure 806. The procedure of FIG. 10 is called when a token has been identified and the token needs to be looked up in the token issuer's token action log(s). We begin this procedure by having a identified token 1002 that needs to be looked up in the token action log(s). (Or the “(blank)” token meaning no token was attached to the message.) We look in the appropriate token action log to see if the token exists there 1004.

[0142] In one embodiment, a TLM may have multiple token action logs. A TLM will typically have one (or more) primary token action log(s), and at one (or more) “Standard Treatments” log. “Standard treatments” is a token action log that defines actions for classes of tokens, rather than for individual tokens. Of course, a “Standard Treatments” log need not be implemented as a token action log.

[0143] For example, as shown in FIG. 26, standard treatments may contain an entry for “important” that treats messages as important. The “token” in the standard treatments file may be the “treatment” name (e.g., “important”). One valuable “treatment” is “default” which specifies default actions for messages tokens that have no actions for a specific event and/or token status defined. Therefore, if this procedure is to look use “standard treatments” as the token action log, then the specific treatment name is used as the “token” to search for.

[0144] The following is an example of standard (default) treatment for a personal email client. For sake of the example, we assume the action entries for each given token in the token action log take the following form:

[0145]

	### event 1 ###
	(default actions for event 1
	[[[token status 1]]]
	(actions for event 1 token status 1
	[[[token status 2]]]
	(actions for event 1 token status 2
	...
	### event 2 ###
	...

[0146] As such, a default treatment entry for an email system might be the following:

[0147]

	### after message received ###
	[[[valid token]]]
	decrease (token,uses);
	accept;
	[[[expired token]]]
	reply (expired);
	reject;
	[[[blank token]]]
	if_match (subject,/{circumflex over ( )}request.*?token/);
	prompt ({from} requesting token: {subject});
	reply (issue);
	reject;
	else;
	reply (suggest);
	reject;
	end_if;
	[[[invalid token]]]
	reply (invalid);
	reject;
	### after message displayed ###
	set (read, yes);

[0148] The reply actions refer to standard form-messages that are sent, such as the following:

• • [0149] reply(expired)—sends “The token you sent is expired. Please contact the person by other means if you need a new token . . . .”
  • [0150] reply(issue)—creates a new token and sends “The this person has issued you a token ‘abc123’ that you should send with future correspondence.
  • [0151] a reply(suggest)—sends “This person uses a token email system that requires you to include a token when you send messages. To obtain a token, send a message with the subject line ‘requesting a token . . . ,’ and . . . .”
  • [0152] reply(invalid)—sends “The token you sent is invalid. If this is in error . . . .”
    This is a simple example, and is meant to illustrate default token behavior for one application of TLM system.

[0153] A “token match” is an entry in a token action log that matches the given token. That means that it matches not only the token (or, in the case of standard treatments, the treatment), but also other conditions such as a pattern for the message sender's email address. This allows the token action log to require tokens to only be valid if they appear to be coming from specific senders or domains.

[0154] Referring to FIG. 10, if the token is not found in the token action log 1006, then the TLM checks to see if the token is “(blank),” meaning there was no token attached to the message 1008. If the token is “(blank)” then the TLM attempts to initiate a default treatment for this token given the token status “blank token” 1010, which is detailed in a subsequent figure. If the token is not blank, then the TLM attempts to initiate the default treatment for that token given the token status “invalid token” 1012.

[0155] In one embodiment, when the TLM considers a token attached to an object (or an independent token), it determines the token status. A number of status values are possible within the scope of the invention:

• • [0156] blank token—since no token is attached to the message being process the (blank) token is considered, and the (blank) token is valid.
  • [0157] invalid token—the token (blank or non-blank) was not found in the token action log.
  • [0158] expired token—the token (blank or non-blank) was found in the token action log, but it was expired.
  • [0159] valid token—the token (blank or non-blank) was found in the token action log, and it was not expired.
  • [0160] misused token—a non-blank token that exists in the token action log but does not meet basic conditions for use.
  • [0161] expired token—a non-blank token that exists in the token action log but is expired.
  • [0162] invalid blank token—a blank token with no blank token entry in the token action log.
  • [0163] misused blank token—a blank token that exists in the token action log but does not meet basic conditions for use.
  • [0164] expired blank token—a blank token that exists in the token action log but is expired.
  • [0165] valid blank token—a blank token that is found in the token action log and meets all criteria for use (and is not expired).

[0166] There may be other specific token states representing specific ways a given token could be invalid. A general approach would be to have two primary token status values: valid and invalid. Then, there could be any number of secondary token status values for invalid tokens, specifying why the token is considered invalid, e.g.:

• • [0167] invalid: not found—token not found in the token action log
  • [0168] invalid: bad user—token being used by an authorized user
  • [0169] invalid: expired date—the token expiration date has passed
  • [0170] invalid: expired uses—the token uses is less than one

[0171] An advantage of that token status scheme is that it can easily employ wildcard characters in the token actions recorded in the token action log. For example, a given token action log entry might specify one action for invalid tokens due to an expired date (such as sending a message about when that expiration date was) and another action for all other invalid token status values. The token action log might include a first action entry (for the given function event) for “[[[invalid: expired date]]]” and a subsequent action entry for “[[[invalid: *]]]” where “*” is a wildcard indicating any match. (So-called “regular expressions” could also be used.) If the TLM system is configured to only act on the first matching action for a given token, then this setup of token actions will accomplish the desired system behavior.

[0172] Further, the token status could be multi-dimensional. The token status could contain the following elements:

• • [0173] validity=valid or invalid
  • [0174] violation=reason(s) for invalidity
  • [0175] presence=blank or non-blank.

[0176] Then, in the token action log the actions could be specified according to these elements, utilizing wildcards as desired (and default token status elements as appropriate). An identifier format in the token action log action could be [[[validity (violation) presence token]]], indicating action matches such as the following:

• • [0177] [[[valid blank token]]] matches a blank token that is found in the token action log.
  • [0178] [[[valid*token]]] matches a blank or non-blank token.
  • [0179] [[[invalid (*) non-blank token]]] matches any invalid non-blank token.
  • [0180] [[[invalid (expired date|expired uses)*token]]] matches any blank or non-blank token in the token action log that has an expired date or expired uses.

[0181] The appropriate token status value for a given token is determined by the procedures of the TLM. Whether such a more extensive list of possible token values would be beneficial depends on the context for TLM implementation.

[0182] In some cases, more than one entry in the token action log may match the given token. The TLM considers that possibility, and may begin with the first match 1014. A major action of the TLM is to check the token to assure it is not expired, and to process the relevant actions 1016, which is detailed in subsequent figures.

[0183] If there are no more matching entries in the token action log 1018, the procedure ends 1020. Otherwise, if the TLM administrator has set the TLM to handle not handle multiple matches 1022, the procedure ends 1024. If not, the TLM gets the next token action log entry match 1026 and repeats at 1016.

[0184] FIG. 11 is one embodiment of the “check token match” procedure 808. Having a token match 1102 means that one or more entries in the token file matched the token under consideration (which could be a blank token or a non-blank token).

[0185] One purpose of the “check token match” procedure 808 is to determine whether the token has expired 1104, and to identify the correct token status. There are various ways a token can expire. For example, the expiration date on the token may have passed. Alternatively, the token may be authorized for only a set number of uses, and which number has been exceeded.

[0186] If the token match is expired by any expiration criteria, the token status is “expired token” 1106 and we go to the procedure to identify appropriate actions for that token status 1116 which is detailed in subsequent figures. If the token match does not meet expiration criteria, then we either leave the token status as it is 1108, or, if the token status is not set, we set the token status to the appropriate valid value. If the token is blank 1110, then the token status should reflect that the token is blank 1112. Note that a token status of “blank token” has the meaning “blank token that is valid (i.e. found in token action log and not expired).” If, however, the token is not blank, then the token status becomes “valid token” 1114, which has the meaning “non-blank token that is valid (i.e. found in token action log and not expired).” Regardless of the token status, the procedure proceeds to identify and process token actions 1116.

[0187] FIG. 12 shows one embodiment of the “identify token actions” procedure 810 and proceeds from step 1116 of FIG. 11. A purpose of this procedure is to identify an action set for the given event and token status. This includes looking for default actions, where appropriate.

[0188] A first possibility is if the token match itself contains actions for the given event and token status 1204. If there are actions defined in the token match, then we proceed to the next procedure to clarify then process the actions 1206.

[0189] If the token match does not have actions defined for the given token match, there is still the possibility of default actions. First, the TLM can look for default actions for the given event 1208, which are invoked regardless of the token status. If none are found then the TLM can look for default actions for the given token status 1210, regardless of the event. Note that these last two steps can possibly be switched, should the system designer prefer to have token status take precedence over event in searching for default actions.

[0190] If none of those default actions are found in the given token action log, the procedure might still look for a default action in the “standard treatments” token action log 1212, which is described in the next figure.

[0191] This procedures may be called from the prior procedure 1302 if it is desirable to check the “standard treatments” token action log for default actions. Since the prior procedure may already be looking in the “standard treatments” token action log, there may be a need to abandon this search 1304 to avoid infinite recursion. In other words, if no default treatment was found in the “standard treatments” token action log, then options for default actions have been exhausted, and the TLM may report such 1306.

[0192] If the TLM has not already checked for a default treatment in the “standard treatments” token action log, then it can look for such simply by calling the “look up token” procedure (described in a prior figure), specifying to look in “standard treatments” for the “default” treatment. Again, that is the last resort, so the TLM returns after that attempt 1310. This “return” means to return an indicator as to whether or not the relevant token action resulted in canceling the action. As used herein, the term “return” is used in a computer programming sense—to finish a sub-process and return to the calling process.

[0193] FIG. 14 shows one embodiment of the “clarify actions” procedure 812. In one embodiment, certain actions may point to other actions. For example, the actions may point to a standard treatment 1404. If they do, then we will use the relevant actions from the “standard treatments” token action log which correspond to the given treatment 1406. In one implementation, we keep track of which treatments have been called for the given token, so that a treatment does not inadvertently wind up calling itself and thus causing infinite recursion. One method is to prevent entries in the “standard treatments” file from calling other standard treatments.

[0194] If a standard treatment is specified, but a match cannot be found for that treatment in “standard treatments,” then this is a problem that might be reported 1410. If the standard treatment is found 1408, then that standard treatment action is used as appropriate 1412.

[0195] Another purpose of the FIG. 14 procedure is to allow for the possibility of a token issuer (i.e. the person whose device has the TLM system) prompted actions 1414. If the issuer has specified to be prompted for actions, then the action set to be performed 1420 is limited by the indicated preferences of the issuer 1418. Whatever actions result from this clarification are then processed 1416, which is detailed in the subsequent figure.

[0196] FIG. 15 corresponds to the “process actions” procedure 814. The procedure begins with a list of actions 1502, such as obtained from the procedure of the prior figure. Since there may be multiple actions, we start at the top of the action list 1504. If there are no more actions on the list 1506 then we are done and can report what happened 1508.

[0197] If there are more actions to be processed, we get the next action on the list 1510. If it happens to be a conditional branch 1512, we determine the condition that causes the branch 1514 and branch as appropriate 1516. An example of a conditional branch is “if the message has an attachment then save the attachment, otherwise skip the save-attachment command.” (The verb “branch” is used in the programming sense: to proceed with a different command in the action list.) If it is an unconditional branch action 1518, the branch is taken 1516 without the need to check a condition.

[0198] As another example of a special action, the TLM considers if the current action is a “cancel function” action 1520, which means the function that initiated the event should not be performed. If such was the command, it is noted 1522, so that this information can be returned back to the calling procedure (and the function can indeed be canceled). Another special action not shown in this figure might be a “un-cancel function” action which would reverse the effect of a “cancel function” action (by resetting the note to cancel the function).

[0199] There could be any number of other actions that might be specified in a token action log entry. An example list is shown elsewhere in this disclosure. Generically, the actions are performed 1524. Note that the actions may possibly utilize parameters that came with the token and which were noted previously, or may utilize token conditions recorded in the specific token action log entry. This procedure repeats itself until all actions on the action list have been appropriately addressed.

[0200] FIG. 16 corresponds to the “report occurrence” procedure 816. This procedure provides for the opportunity of reporting any TLM occurrence that may occur. In one embodiment, the procedure begins by being given a specific occurrence to possibly report 1602.

[0201] Two possible ways of “reporting” are considered here, although there may be others. First, the occurrence might be logged 1604, which is to note the occurrence in some type of log file 1606. Second, the user (i.e. token issuer) might desire to be notified of this given type of occurrence 1608. For example, the TLM might notify the user 1610 by sounding a beep and displaying a message, etc. In other cases, no reporting is done.

[0202] After reporting the occurrence as desired, the procedure returns to the calling procedure 1612. As mentioned previously, this may include returning a flag or other indicator about whether the token actions specified to cancel the initiating function.

[0203] FIG. 17 describes one embodiment of a TLM system to filter email. The token issuer desires to request a price quote from a company, realizing that companies often use email addresses they receive to subsequently send unsolicited email (spam). Even worse, some companies sell email lists to other companies who use them to promote products. The token issuer desires to avoid these subsequent spam emails.

[0204] This is accomplished by issuing Company XYZ a token with a fixed number of times it can be used. The action for the token is shown in the top token action log of the figure. (The “uzp314” issued token is highlighted with an arrow.) The action for a valid token is to decrease the number of available token uses, to accept the message, and send a thank you auto-reply message. If the token is received after it is expired (i.e. after the first use), an appropriate “expired” message is sent and the message is rejected.

[0205] When Company XYZ returns the quote, it includes the token. Since the token still has one use, it is valid and the message is received. However, if the company sends spam including that token at some later time, the “number of uses remaining” condition in the token action log has already reduced to zero, and the spam is rejected.

[0206] As an extension, a person might issue “high priority” tokens to relevant message senders. The actions associated with receiving the token might include displaying the message in a bold font, causing an audible notification, paging the person, etc. If such sender includes that token with a message, those actions will be taken. Other possible applications to email are almost limitless.

[0207] FIG. 18 describes the use of a TLM system as a telephone filter. In this case, the token issuer desires Company XYZ to call him back by Aug. 10^th, 2002. This expiration is recorded in the token action log (under token 36314, highlighted with an arrow in the figure). Since this is an important call, the receipt of the valid token has action to ring the phone loudly.

[0208] If the company attempts to call the token issuer with that token after the token expiration date, the token status is registered as expired, resulting in an auto-reply message and the rejection of the call. Thus, calls from that company using that token are filtered after the token expiration date.

[0209] In a general application, people calling a cell phone might be required to include a token, which might simply be a numerical code in addition to the phone number. If a caller calls without including such a message token, the phone system can automatically notify the caller that a token is required. People calling from certain phone numbers can be allowed to pass without a token (i.e. with a blank token). Callers can request a token, which are issued at the discretion of the receiver. When a given token is received, special actions might be taken such as letting the call ring through to the receiver, playing a special ring melody, flashing a light, etc.

[0210] FIG. 19 is an example application using token action logs in the context of course management. An instructor is teaching a course in which she will communicate with students via email. The instructor prints her email address in the course syllabus.

[0211] She also creates two tokens for the course. One is for general questions of possible interest to the entire class. Incoming messages (student questions) including that token will be automatically posted onto the class discussion forum. Outgoing messages (instructor answers) with that token will also be posted onto the class discussion form. The second token is for student-specific issues. Incoming messages with that token will “beep” the instructor and be automatically filed in a “course in-box.” These two course tokens are also listed in the course syllabus, and students are instructed to use one or the other in any email being sent to the instructor.

[0212] The instructor can allow the token to be sent from any email address at any domain, or she can restrict it to the university domain. Also, she can flag that the tokens are only valid through the end of the semester—after that time the senders could be automatically sent a “this token has expired” message.

[0213] FIG. 20 shows an automated survey logger application example. It utilizes an action called “log” that logs results in a survey log file.

[0214] A surveyor may desire to survey others via email. A token might be created with an action for messages received of automatically logging the survey responses in a data file. The surveyor then emails the survey form to the survey subjects with that token included with the “reply to” address. The subject completes the survey and emails it back to the surveyor. The surveyor's email system recognizes that token and automatically parses the responses and records them in a survey response file.

[0215] FIG. 21 is an example of a home control device utilizing a TLM. A person is going on an extended vacation, and does not know whether it will be necessary to run the automatic lawn sprinklers while he is gone. So, he creates a token in his home telephone's token system before he goes. The action for the token is to turn on the automatic sprinkler system when the token is received as part of a message. When he is on vacation he can check the weather of his home town in the newspaper. If it is necessary to water the lawn, he can call his home phone and include the special token—turning on his sprinkler system.

[0216] FIG. 22 is an example of a situation where a token issuer is the token user. In this case, a token is set so that it cannot be inadvertently deleted. The token event “before token deleted” has actions that prompt the user then cancels the function.

[0217] In view of the foregoing, the use of a token action log can be beneficial even Without communicating tokens with others. Tokens may be created by a user (and record in his or her token action log) that act as indicators of specific attributes of messages to which the tokens are attached. For example, a person may create ad hoc tokens that are recorded in the token action log with the action that objects or messages they are attached to cannot be deleted. When the user attempts to delete a message with such a token attached, the message device will detect the token, look up the action in the token action log for the event “before message deleted,” and prevent the person from deleting the message. Therefore, the way to delete such a message would be to change the action of the token (recorded in the token action log) to allow deletion, to remove the token from the message before deleting it, or to delete the token from the token action log (which would instead motivate an “invalid token” response to that message).

[0218] FIG. 23 is an example of using a TLM in the context of a website trial. For this example, the message device is a company's web server. A token is distributed to customers on a document contained inside of the product packaging. When the token is initially submitted by the customer to the company's web server, the TLM in the web server recognizes that it is an invalid token, but is a valid product serial number. Thus, the default action becomes creating a new entry in the token action log for the given token with an expiration date 30 days into the future. For those 30 days, the person is considered to be a trial user of the website, and is thus authenticated to access the website features (by submitting that token at the website). After 30 days the person is not granted access to the website with that token, but is rather sent an automatic message encouraging her to send money to purchase a full subscription to the website services.

[0219] Examples 24 and 25 show the object not being a message, but being a non-message object. For the example of FIG. 24, the auto parts retailer desires to order parts from one of many wholesalers, and does not want to receive any items not ordered. When the order is placed, the token issuer includes a newly created token with the order. Of course, this token is recorded in the issuer's token action log. Subsequently, when an item is shipped from the wholesaler it should include that token. When the item is received and the token is validated, the system automatically initiates payment for the item.

[0220] If the wholesaler accidentally or knowingly ships an unordered part in the future, using the prior-used token or no token, the token issuer's TLM will recognize this problem and initiate return of the part. Thus, the TLM system prevents the token issuer from receiving parts that were not ordered.

[0221] The example of FIG. 25 shows the non-message object being a car, or more particularly a token user in a car. The user purchases a “token” online, that allows him to enter the parking lot a given number of times. The parking lot gate contains a TLM that checks tokens entered by potential parkers. By entering a valid and unexpired token at the parking lot gate, the user is given access to the parking lot. If the token is not valid or is expired, the TLM restricts access to the parking lot, and may ask for more money.

[0222] This application of TLM systems to access control has similar application in many other areas including:

• • [0223] School lunch—kids prepay to get a token for lunches.
  • [0224] Gym membership—valid members have a token to enter the facility.
  • [0225] Automatic car wash—this example was describe earlier in this document.
  • [0226] Prescription refilling—doctors provide tokens with prescriptions that have limited use and are validated by EDI at the pharmacy.
  • [0227] Keyless hotel room locks—hotel customers are given a token that will open the room door during their stay. Other token-action log actions might include, for example, turning on the lights or adjusting the temperature according to the customer's preferences.
  • [0228] Rental car locks—conceivably a rental car could have a similar feature that only allows it to start with the token issued to the customer.
  • [0229] or other services that specific customers are allowed to use for specific times.

[0230] FIG. 27 shows a procedure for handling unsolicited email or other communications. For example, XYZ company may send an unsolicited email to a user having a TLM. Since the email does not include a token, the TLM finds a standard treatment in the token action log for a blank token. A number of example actions are illustrated.

[0231] In one embodiment, the TLM sends a reply to XYZ company stating that it must first request a token. The form of XYZ company's acknowledgement may be stipulated. For example, XYZ company may need to reply with a subject line beginning “requesting token:.” In addition, XYZ company may be required to provide a statement of the purpose of the communication, e.g., “requesting a token to send you a recall notice.”

[0232] An example procedure for requesting a token is shown in FIG. 28. In one embodiment, when the token request is received, the TLM may prompt the user to accept the communication. For example, the TLM may allow the user to (1) issue a token, (2) reject the communication, or (3) ignore the communication.

[0233] If the user accepts the communication, a token is issued and sent to XYZ company. Thereafter, XYZ company may send the original message with the token to the user, which may be accepted by the TLM into the user's inbox.

[0234] Conceivably, a spammer may configure an automated e-mail “robot” to send a token request with a bogus statement of purpose. To prevent this, the TLM may send a communication to XYZ company that includes an image depicting a code. The image may be embodied, for example, as a GIF or JPEG image. In one embodiment, the code may be any alphanumeric code that is readable by a human being. However, the code may be depicted within the image using an unusual font, shading, placement, and/or spacing to prevent optical character recognition (OCR). In one embodiment, an XYZ company representative may be required to visually discern the, code and include the code in its token request before a token is issued, effectively preventing fully automated spamming.

[0235] In one embodiment, a token may be automatically assigned to any communication that does not already include a token when received by a communication system or in response to another event. For example, a communication may be received having a return address that is in a TLM user's address book. Rather than requiring the sender to request a token as shown in FIG. 28, the sender's communication may be automatically given a token. This may be accomplished, in one embodiment, using a standard treatment. Tokens may be automatically assigned to communications in response to other conditions, which may be programmed by the token issuer.

[0236] As illustrated in FIG. 29, a token action log 2900 may be embodied as a data table including the following types of information:

• • [0237] The token 2902 (or treatment, in the case of a standard treatments token action log), or a token pattern.
  • [0238] Conditions 2904 under which the token use is valid, such as an expiration date or a limit on the number of uses.
  • [0239] The purpose(s) 2906 of the token, including the intended purpose and/or the purpose communicated to the user.
  • [0240] Actions 2908 initiated by this token. The actions normally are specified according to function event and token state.
  • [0241] Meta data 2910 about the token 2902. Examples might include the create date of the token 2902 or a list of users this token has been sent to. It would also be valuable to include a date stamp indicating when the token was most recently used. That information would be helpful in identifying old token entries that might be cleaned out (removed or archived) from the token action log.

[0242] Of course, the token action log 2900 may be implemented using various types of data structures known to those of skill in the art. For example, the token action log 2900 may be embodied as an XML document, one or more tables in a database, or the like.

[0243] FIG. 30 illustrates modules of a token log manager (TLM) 3000 according to an embodiment of the invention. Each of the modules described herein may be implemented using any suitable combination of software and/or hardware. In certain embodiments, the functionality of two or more modules may be combined into a single module. Alternatively, two or more modules may be used to implement the described functions of a single module.

[0244] In the depicted embodiment, the TLM 3000 includes a token generator 3002 to create one or more tokens 2902. As previously noted, tokens 2902 may be arbitrary symbols in any suitable format. The token generator 3202 might generate tokens as random sequences of symbols, or might receive the token symbols from the system operator or some other authorized source.

[0245] The TLM 3000 may also include or have access to a token action log 2900 for associating each token 2902 with a customizable set of one or more actions. In addition, the TLM 3000 may include a token distributor 3004 for distributing created tokens 2902 to entities potentially desiring to communicate with a user of the TLM 3000.

[0246] In one embodiment, the TLM 3000 includes a communication receiver 3006 to receive a communication 3008 accompanied by a specific token 2902 previously generated by the token generator 3002. The communication receiver 3006 may be coupled to a lookup module 3010 for searching the token action log for a set of one or more actions associated with the specific token 2902 received with the communication 3008.

[0247] As illustrated, an action manager 3012 within the TLM 300 may execute the set of one or more actions identified by the lookup module 3010. In one embodiment, the action may be receiving the communication 3008 into an inbox 3014 or the like.

[0248] FIG. 31 shows one embodiment of a TLM system to manage financial transactions and prevent fraud. In this example, the TLM is embedded in a mobile phone that is operated by a financial card holder (credit card or debit card). The card holder desires to make a purchase at a business that is hypothetically called “Burgers, Inc.”

[0249] The card holder indicates his request 3102 and is told the price 3204. The card holder then initiates the TLM on his communication device (i.e. cell phone) by selecting a function to issue a transaction-authorization token 3106. The TLM responds by creating a new token for the purpose of transaction authorization, and allowing the TLM operator to specify conditions for use of that token (e.g. transaction value limit, valid vendor name pattern, etc.) 3108. The TLM may require the operator to enter an authorization code in order to prevent unauthorized operators from issuing transaction authorization tokens on that message device. The card holder reads the token off of the message device screen 3108, and presents it with the card for the transaction 3110. The restaurant employee processes the card as usual, except for also entering the transaction token as required (or having the customer enter the transaction token).

[0250] The authorization system sends information about the transaction to the card clearinghouse 3114. The transaction authorization system at the card clearinghouse recognizes that this particular card number requires token transaction authorization from the card holder's message device 3116. This includes knowing the address of the message device, which for a mobile phone would be the phone number.

[0251] The clearinghouse system automatically contacts the card holder's message device 3118 with the transaction information including the token. As usual, the TLM looks up the token in the token action log and performs the appropriate actions, which for a valid set of token parameters would be to authorize the transaction 3120. The TLM may log that the transaction was authorized, but otherwise may not need to bother the card holder. The clearinghouse 3122 would then provide the usual authorization information to the company seeking transaction authorization. In certain embodiments, the TLM may actually be stored within the clearinghouse.

[0252] In the case of invalid token transaction parameters 3118, the TLM would instead respond by sending an “not authorized” message. For example, if someone steals the card and attempts to authorize another transaction, the TLM will reject the authorization request. This rejection will occur even if a transaction-authorization token is also stolen and included with the transaction authorization request, if the conditions for use of that token are not met.

[0253] If the card holder's message device is unavailable to handle an authorization request 1593, then the card clearinghouse may optionally provide a temporary authorization of the transaction to the business. Nevertheless, the effectiveness of this system is much greater if the card holder's message device is available to handle incoming messages with tokens attached. Therefore, the card clearinghouse may only provide temporary authorization of financial transactions under a certain amount.

[0254] FIG. 32 show a similar embodiment as FIG. 31, except for describing an online transaction. The FIG. 32 procedure is very similar to that of the prior figure. The real risk in online transactions is that the customer does not have to present the physical card in order to initiate the purchase. There are frequently stories in the news about people breaking in to merchant computer systems and compromising the safety of credit card numbers. With the embodiment of FIG. 32, stolen credit card numbers would be of little concern.

[0255] The legitimate customer places an online order 3202, such as by completing an online “shopping cart.” The online merchant system indicates the purchase total 3204 and requests payment. The legitimate customer initiates an “Issue transaction token” function of the TLM on her message device 3206. The TLM creates a token with appropriate conditions for use and actions 3208, and either presents it to the customer for distribution or simply distributes it directly to the merchant 3210.

[0256] The merchant seeks credit card number authorization 3212 by sending the transaction information to the card clearinghouse 3214. The card clearinghouse recognizes that the transaction must have token authorization from the given message device 3216, and sends the token and transaction parameters to the token device 3218. The TLM processes the token message in the usual manner, authorizing the transaction 3220 if appropriate. The clearinghouse can authorize the transaction to the online merchant 3222, who could then forward confirmation information to the customer 3224.

[0257] The embodiments of FIG. 31 and FIG. 32 could also involve various authentication and encryption methods as are commonly employed in communication systems. Such, for example, could prevent a criminal from “spoofing” (acting as) the appropriate message device and giving false transaction authorization. With appropriate authentication and encryption in place, the only way to authorize a transaction involving a stolen credit card number would be to also steal token authorization information before it becomes invalid, or to “hack” the TLM (which could be kept secure).

[0258] While specific embodiments and applications of the present invention have been illustrated and described, it is to be understood that the invention is not limited to the precise configuration and components disclosed herein. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and systems of the present invention disclosed herein without departing from the spirit and scope of the invention.