Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/10—Office automation; Time management
  • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/22—Payment schemes or models
  • G06Q20/29—Payment schemes or models characterised by micropayments

Definitions

• Phishing involves passing oneself off as a legitimate business from which a user may actually want to receive unsolicited emails. Phishing has experienced exponential growth over the Internet. Spam typically gets a response rate of 0.01%. However, phishing, because of the air of legitimacy and the strong call to action, can receive a 5% response rate.
• URL Universal Resource Locator
• a machine-implemented method where information is decrypted to acquire the identity of sender of a message; the message is directed to a recipient and a transaction occurs before the recipient receives the message from the sender.
• information is decrypted to acquire the identity of sender of a message; the message is directed to a recipient and a transaction occurs before the recipient receives the message from the sender.
• it is determined whether the sender has an account with sufficient funds to pay for the transaction or whether the sender is permitted to proceed with sending the message free of charge. Funds are acquired from the account if appropriate, and if the sender is verified a stemp is encrypted with the transaction number and an encrypted account number. The stemp is sent back to the sender to use with the message.
• a machine-implemented method where an email is received from a sender and a header of the email is inspected for a stemp. Authentication of the stemp is requested and the email is routed to a segregated inbox if the stemp was present in the header and authenticated.
• a system includes a recipient interface and a protected email service.
• the recipient interface is for requesting that the protected email service authenticate senders of emails.
• the protected email service collects payments from senders of the emails and authenticates the identities of the senders on behalf of the recipient interface.
• a machine-accessible medium having instructions embedded thereon is provided.
• the instructions when accessed by a machine routes an email from a sender to a segmented inbox in response to a stemp that was included in a header of the email.
• the instructions when accessed, also send the header to an authentication service to authenticate the identity of the sender.
• the email or information about the email is then displayed or discarded in response to information received from the authentication service.
• instructions are provided within a medium that, when accessed by a machine, supplies stemps to senders of emails directed to recipients and authenticates the stemps on behalf of the recipients.
• a number of senders may be blocked from sending their emails if so requested by the recipients.
• funds may be debited from accounts of the senders if a policy of the recipient necessitates payments.
• Figure 1 is a diagram of example micropayment system hardware.
• Figures 2A and 2B show a flowchart of an example embodiment of a basic micropayment protocol.
• Figure 3 is a drawing of an example screen shot for the user interface of an embodiment which uses split screens segregation of emails, custom indications on emails with stemps and a separate folder for micropayment email.
• Figure 4 shows an example user interface display which uses a single pane content window to display emails that either contain stemps or are from white list recipients.
• Figure 5 is a screen shot representing another class of example embodiments which requires users to ask for particular emails to be authenticated by selecting the email and selecting an authentication command and gives a user an option to opt out.
• Figures 6A and 6B are a flowchart of an example process carried out by a recipient computer and server to implement the opt-out option.
• Figure 7 is a flowchart of an example embodiment of a manual authentication process.
• Figures 8A and 8B show a flowchart of an example generic manual authentication process.
• Figures 9 A, 9B and 9C show a flowchart of the embodiment of a protocol to send and receive protected email.
• Figure 10 shows an example a table or database which can be used by a server to map from a transaction number to an identity.
• Figure 11 shows a diagrammatic representation of machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
• the sender software 4 sends an initation message to the server identifying the recipient with the sender identification information (e.g., sender identification may be provided by user name and encrypted password or by account number or by user name, password and some secure information that only an authentic sender would know) and requesting the server to send back a code (e.g., a stemp) which may cause the message to be not blocked by the recipient software 12 (step 5).
• the sender identification information e.g., sender identification may be provided by user name and encrypted password or by account number or by user name, password and some secure information that only an authentic sender would know
• a code e.g., a stemp
• this message includes a user name and password (e.g., encrypted) and this information is used to look up the sender's account number.
• this message may include the encrypted account number of the sender.
• the server uses the user name and decrypted password or the decrypted account number to determine the identity of the sender, and this process acts as an automatic authentication of the user.
• the requested code can, in some embodiments, be an encrypted TruemarkTM logo in the case of a paid email which is identified with the sender's brand. It is to be understood that the TruemarkTM may actually be any custom indication that is graphical and/or audible in nature and permits ready identification.
• the custom indication stemps may in some cases be logos or trademarks.
• the paid email generic logo type stemp may be yellow in an embodiment.
• the unpaid email from a white list (e.g., a white list stemp) may be green in an embodiment.
• different shapes can be used instead of different colors.
• the key thing is any person can distinguish the types (and the sender in the case of custom indications) with no training. Of course, with whitelist senders, the purported sender shows up in the "from column,” so odds are the recipient knows who sent the email, and can trust that "from” designation because there is also the validation of the whitelist stemp.
• the server can display anything on the recipient computer display to identify the authenticated sender for various embodiments.
• One embodiment shows the trademark registration for the logo, but generic stemps and whitelist stemps would be substantially less informative -- just showing whatever ID was used to set up the protected email account.
• White list senders get their integrity from the fact that the recipient designated who is on the white list.
• Generic stemps have a penny's worth of integrity (only a small micropayment was paid to have the generic stemp issued) — that's why they may be yellow and that is why, in some embodiments, they are not permitted. However, they may have lots of integrity; for example, they may cost $4M to send 400 million emails.
• the server receives the initiation message in step 5 and may, for example, do the following things. 1 ) It may use information in the header of the email to be sent such as the IP address of the sender and/or the sender's account number and/or the user name and decrypted password and/or other secure information only the sender would know to authenticate the sender as actually being the sender the email purports to be from (step 7). This involves decrypting the account number in the incoming message, and looking up the identity of the entity with that account number.
• step 15 the sender software 4 receives the header with the encrypted stemp in it back from the server. This header is put on the email message to be sent to recipient, and the email message is then sent to the recipient through normal channels on the Internet or some other WAN.
• the receiver software receives the email with encrypted custom indication, generic stemp or white list stemp, and retrieves the encryption key used to encrypt the custom indication, generic stemp or white list stemp.
• the custom indication, generic stemp or white list stemp may be dehashed using the reverse hash algorithm.
• the key is then used to attempt to decrypt the account number and the transaction number encoded in the custom indication, generic stemp or white list stemp, and if the custom indication, generic stemp or white list stemp decrypts properly, the transaction number should match the transaction number received from the server and the account number should match a table entry matching account numbers to custom indications (which table may be stored in the recipient computer in some embodiments). If these items match what the recipient computer has, the email is stored in an Exsis (payment service) email folder with its custom indication. The emails in this folder will be displayed whenever selection of the custom indication icon in the navigation pane of the recipient's browser or email client occurs.
• Exsis payment service
• a phisher In order to spoof this system, a phisher would have to do the following things: Spoof the server into generating a transaction number by sending a message with the proper account number of the sender the phisher wants to pretend to be and properly encrypt that account number. In other words, the phisher would have to know the account number of the business he wanted to pass him self off as and know the proper encryption algorithm and key that that business would use to encrypt its account number. Then the phisher would have to obtain the transaction number that had been sent to a recipient in response to the phisher's request or decrypt the transaction number sent from the server to the recipient.
• FIG. 3 there is shown an example drawing representing several species within a genus of browser user interfaces to segregate paid email and white list email from other email that does not fall into either of those categories because it was not sent as a result of an exchange of messages with the server. There are several species within this genus each of which will be described below by way of example.
• Figure 3 represents an example first species where both paid and white list emails are simultaneously displayed.
• the display shown in Figure 3 may represent the browser mail user interface for a computer which has been programmed with software to use segregation of paid and friends emails from other email using an email service folder in the navigation pane, and to use company custom indications on emails with stemps and tabs to segregate micropayment email from white list email.
• the browser window outline is shown at 30.
• the normal drop down menu commands such as "file", "edit” etc. are shown at 32 and 34 as examples.
• the conventional "back” and “forward” commands to navigate the browser back to the previous web page and forward to the next web page in a sequence of web pages already visited are shown at 36 and 38, respectively.
• Icons, for normal email commands such as "get email” etc., are shown at 40 and 42.
• pane 48 is displayed if the Logo Mail tab shown at 86 is selected, and the contents of pane 58 are shown if the friends tab at 88 is selected.
• both panes 48 and 58 are shown simultaneously in a split pane format as shown in Figure 3 and organized by date of the email with paid emails being shown if the Logo Mail tab is selected and white list email being shown if the friends tab is selected.
• only a single window to the right of the navigation window 44 is shown, and its contents display email with stemps if the Logo Mail tab 86 is selected and its contents display the white list emails if the friends tab 88 is selected.
• paid emails in panes 48 are segregated from unpaid "white list" emails in pane 58.
• Emails that appear in the panes 48 and 58 may be emails that have been processed by an exchange with the server. All other emails that are sent from a sender to a recipient by normal channels without an exchange with the micropayment server are the emails that show up in the recipient's inbox when the inbox icon 60 in the navigation pane 44 is selected.
• the email client or browser may invoke an add-on process implemented by recipient software.
• this add on process in the recipient computer is a plug-in which is active at all times.
• This add-on process may check the header of the incoming email for coding indicating it has a stemp or is a white list email. If it has a stemp, an authentication process to be described later herein is made, and, if the email is authentic, an entry is made in pane 48. If the email is coded as a white list email, its source is automatically authenticated in one embodiment, and, if the email is actually from the white list person or company it purports to be from, an entry is made in pane 58.
• an indication as to who the email is from is given in the email listing in pane 48. If the email is authentic and is from a white list recipient, an indication of who the email is from is displayed such as is shown by the names at 76, 78 etc.
• the server knows the entity that has the user name and password entered with the request to issue a stemp and send the user's logo.
• a person establishing the account may have to go through a due diligence investigation. This may be conducted by employees and may require evidence that the sender/user attempting to establish the account and custom indication is currently employed by a company they say they are employed by, and has the authority to establish the account on behalf of that company.
• What may distinguish a custom indication or branded stemp from trusted certificates includes the following: 1) the custom indication does not require a genius to understand it; 2) the custom indication is extremely consumer friendly; 3) the custom indication may work in Outlook and webmail whereas the trusted certificates may not; 4) the quality of trusted certificates may be variable with some certificates being not so trustworthy.
• a similar due diligence process may be performed for white list senders who wish to establish an account and use a generic logo.
• the due diligence process may be eliminated or highly attenuated in some embodiments since the phishing problem is peculiar to large companies who lend credibility to the phisher's call to action. They generally do not pass themselves off as individuals.
• a phisher may be able to establish a false account in somebody else's name and set up a user name and password, if they know enough about that person to perform an identity theft. But it is unlikely that such a spoof would pass the due diligence if the account set up was attempted by a phisher in the name of a big corporation.
• Encoding the sender's ID in the custom indication or stemp will help block phishers because even if the phisher is able to spoof the system and establish a fraudulent account, when the recipient's complain, the custom indication or generic logo will be sent back to email service and decoded to reveal the identity of the person who established the fraudulent account. This will lead to arrests and prosecutions and cause phishers to avoid an environment implementing the teachings presented herein.
• the target customers for custom indications are entities whose brand identity is being damaged by phishers.
• the functionality of the native browser or email client is used in some embodiment by the add-on process to display the subject line of each email, e.g. 80, 82 and 84, and to display conventional icons or other user interface tools such as bold or highlighting of unread messages to indicate whether a message has already been read or not.
• the add-on process may do all the work of displaying the emails including all the work normally done by the conventional browser or email client. If an email comes in, which does not have a stemp nor a coding to indicate it is from a white list recipient, it may be placed in the inbox which is displayed when the inbox icon 60 is selected.
• the add-on process executing in the recipient computer may automatically authenticate the source of the email by a process to be described below, and will not display it in pane 48 or 58 unless it is authentic.
• Authentic emails are displayed with custom indication icons in pane 48 and with whatever the recipient configures in his white list address book for white list recipients.
• FIG 4 is a diagram of an example user interface display which uses a single pane content window to display emails that either contain stemps or are from white list recipients.
• an email service icon 90 is displayed in a navigation pane 92 and is selected. This causes a content window 94 to display a single pane of emails which both contain stemps and which are from senders on the recipient's white list.
• the email from CFO.com whose custom indication is displayed at 96 (e.g., because it has been authenticated as actually being from CFO.com) is displayed along with an unpaid email from a person Bobby on the white list of the recipient, with an icon displayed at 98 indicating this email has been authenticated.
• the user interface of Figure 4 works the same way as the user interface of Figure 3 except that only a single pane of emails is displayed with stemp email mixed in with non stemp email. No Logo Mail or Friends tab is necessary therefore, and these tabs 86 and 88 from Figure 3 are omitted in the display of Figure 4.
• the content window 94 is divided into sections for emails dated today and emails dated yesterday, but in other embodiments, only a single pane with both stemp and non stemp emails mixed together is used with the ability to sort on any field.
• a common element between example embodiments of user interfaces according to one genus, two examples of which are represented by Figures 3 and 4, is that the white list emails are displayed or can be displayed in the email service folder along with the paid emails. This attracts users to click on the folder which they would be less inclined to do if they knew that the folder only contained paid emails. This gives advertisers a way to use the Internet to send cheap advertising that is known to the users to be authentic and which is segregated out from all the spam in the user's inbox by virtue of being segregated from the other email in the inbox 60 by being placed in the folder. The fact that white list emails will also be in this folder gives such advertisers a much improved chance that the users will click on the folder navigation icon 68 or 90 and have their emails viewed.
• the automatic authentication process or authentication on demand protects such users from fear they are being "phished” and further improves the chances of a response to a legitimate paid email.
• This user interface genus provides advertisers with an entirely new, less expensive, secure way to get advertising messages to a targeted list of customers or potential customers.
• the particulars of the conventional browser interface and email commands can vary from one type of browser and email client to the next, and are not critical to the example embodiments.
• the details of how the recipient computer add-on process processes incoming emails, interacts with the operating system or interacts with the conventional browser or email client are not critical to the example embodiments. It is only how the computer displays the email service icon in the navigation pane and how the paid and white list emails are segregated and displayed alone by selection or together simultaneously that constitute the user interface embodiments.
• FIG. 5 is an example screen shot representing another class of example embodiments which requires users to ask for particular emails to be authenticated by selecting the email and selecting an authentication command and gives a user an option to opt out.
• the opt out option means the user can request the server to block further emails from the sender of a particular email even if the sender attempts to attach a paid up stemp to the email.
• the options are provided in a pop up dialog box 100.
• This pop up dialog box can be caused to appear in many different ways such as by typing a hot key combination when a particular email is selected or the cursor is resting on the email or the custom indication of the email, or by clicking on the custom indication or logo of the email or by a drop down menu selection added to the conventional drop down menus. Any user interface mechanism that provides the ability of a user to select a particular email in the inbox and provides commands to authenticate or opt out will suffice.
• the pop up dialog box 100 is caused to appear when the user double clicks on the custom indications of an email he wants to have options regarding. For example, suppose a user wants to opt out of receiving any further emails from CFO.com or wants to validate an email purporting to be from amazon.com.
• the receiver software 12 in Figure 1 may include the ability to send email messages to friends, family and others the recipient wants on his white list informing them they have been placed on his white list. Simultaneously, a message may sent to the server 8 which requests the server 8 to put the friend, etc. on the recipient's white list and giving the server 8 the email address of the person or other entity to be added to the white list. The server responds by putting the email address of the sending on the white list of the recipient who sent the message requesting a particular person or entity to be added to the white list. This gives users of the system the ability to cause certain persons emails to be sent for free and to be segregated into the user's inbox.
• Step 100 represents the process of the user selecting a particular email and giving a command to cause the pop up box 100 to appear.
• both things are accomplished simultaneously by double clicking on the custom indication of the email to be subjected to the opt out process. In alternative embodiments, this may be done by clicking once on the email to be selected, typing a hot key combination to cause the dialog box 100 to appear and then double clicking on the opt out function.
• the dialog box 100 can also be made to appear in any other way such as by dragging the cursor over or double clicking on an icon on the screen somewhere or selecting it as a command bar icon or a drop down menu item from some other command bar icon such as the edit icon 34 in Figure 3.
• the Exsis server receives the opt out request message and uses the information from the header of the email selected for opt out to look up the sender of the email. Typically, this is done by using the transaction number to look up the encryption key used to encrypt the micropayment account number and using that key to decrypt the account number. Then the account number is used to look up the identity of the sender. If the account number does not decrypt properly, the email is not from whom it purports to be from, and a message is sent to the recipient computer indicating the email is not from whom it purports to be from.
• the server adds the sender's identity to an opt out list maintained on the server for the recipient.
• Step 110 is optional. If this step is performed, the server sends the opt out request message and recipient identity to the sender software of the sender computer of the sender identified in the opt out request. This allows the sender to remove this recipient from its lists of target recipients thereby saving the micropayments for emails to that recipient.
• the server After adding the sender to the recipient's opt out list, the server receives in step 112 requests from a sender process running on a computer of a blocked sender. The server then looks up the sender identity from the message received from the sender and compares that identity (after authentication) to the opt out list of the recipient to whom the sender indicated it wants to send a message. If the sender is on the opt out list of the recipient, the server refuses to send back an encrypted stemp or white list code to the sender thereby effectively blocking that sender from getting any email messages into the email service folder of the recipient, as represented by step 114. If the sender sends email anyway, the receiver process software shunts such non email into the normal inbox of the recipient email client or browser or blocks it altogether.
• Step 118 represents the process of manually launching a separate, fresh browser window by invoking a browser icon on a desktop or in an applications folder. In an embodiment, this browser should not be launched from another application such as a word processor, accounting program, etc.
• step 128 the server receives header information and dehashes the stemp. It then decrypts the transaction number encoded into the stemp and uses that transaction number to look up the decryption key used to encrypt the account number encoded into the stemp. That key is then used to decrypt the account number. Finally, in step 130 the server uses the decrypted account number to look up the identity of the sender and sends the identity back to the recipient computer.
• Step 138 represents the process of displaying on the recipient computer some user interface mechanism that the user can invoke to select a particular email and launch the authentication process. It is this manual step which is why this process is called the manual authentication process although most of the work is done by computers.
• the particular user interface mechanism selected is not important. It can be a single mouse click on a particular email or on the logo of that email followed by selection of a drop down menu command, entry of a hot key combination, or selection of a radio button. Whatever it is, two things must be accomplished, and any mechanism to do these two things will suffice: 1) selection of a particular email; and 2) giving some indication that authentication of its source is desired.
• Step 140 represents the process of responding to selection of a particular email and giving of a command to authenticate the email.
• step 146 the decrypted account number is used to look up the identity of the sender of the message to be authenticated, and a message is sent back to the recipient computer with the identity of the owner of the account.
• Figure 9 is a flowchart of an example embodiment of a protocol to send and receive protected email.
• the sender software receives a command to send email to a particular, identified recipient.
• the sender software receives keystrokes or other data to compose the email message, identify the intended recipient and supply identifying information that identifies the sender.
• the identifying information is a user name and password (encrypted) and some other secure information that only the sender would know and/or to which a phisher would not have access.
• This other information can be a key that changes over time, a fixed, secret key, or any other secret information only the authentic sender would know such as the micropayments account number, a birthplace or time of birth.
• step 164 is performed to deny the stemp request and processing returns to step 150. This part of the process may defeat any bulk spammer who decides to make the micropayments to send out the spam because the stemp policy will have limits set to bar this type of activity.
• step 166 is performed.
• the server uses an encryption key and encrypts unique information which directly or indirectly gives the identity of the sender into a stemp.
• the server also encrypts some information from the header of the proposed email message (or from the main body of the message in some embodiments where the main body or some portion thereof is sent with the initiation message) into the stemp so as to tie the stemp to the message.
• the identifying information that identifies the sender can be unique to this stemp or it can be unique to the stemp when considered in the context of other information such as the date, the account number, etc.
• the identifying information may be a transaction number which is then stored in a table in the server along with the identity of the sender, the encryption key used and the encrypted version of the stemp and any custom indication, generic logo or white list source icon associated with this particular sender.
• Figure 10 is an example of such a table or database which can be used by the server to map from a transaction number to an identity.
• Row 165 stores a record for one protected email sent by Fed Ex.
• Column 167, row 165 stores the transaction number encrypted into a stemp, and column 169, row 165 stores the encryption key used to encrypt the stemp.
• row 165, column 175 stores the identity of the Fed Ex custom indication or a pointer to its storage location.
• this protected email is from a white list member of the intended recipient.
• column 175 stores a pointer to or the identity of the white list source icon for display with the email from sender Bobbie White on the recipient computer's display of the contents of the inbox.
• the server then checks to determine if the sender is on a white list of the intended recipient, and, if so sends the encrypted stemp to the sender without deducting a micropayment amount from the sender's account. If the sender is not on a white list of the intended recipient, the server deducts the micropayment amount from the sender's account and sends the encrypted stemp back to the sender.
• the recipient computer's receiver software 12 receives the email from the sender and examines the header of the email for the presence of a stemp. If test 172 determines that no stemp is present, the email is directed in step 171 to the regular non protected email client process on the recipient computer for display in the regular, non segregated inbox. Examples of such non protected email client processes or applications are Netscape Communicator's Messenger module, Outlook Express and many other email clients.
• step 176 the server receives the validation request and uses the encrypted version of the stemp or the decrypted transaction number to search a database or table such as that shown in Figure 10 to find the unique session key used to encrypt the sender ID information encrypted into the stemp.
• step 176 represents using the encrypted version of the stemp to search the table or database to find the record which pertains to this particular protected email. That record can then be searched for the rest of the information the sender needs.
• the server uses the standard key to decrypte the first layer of the stemp to extract the transaction number. This transaction number is then used to search the database or table to find the record that pertains to this particular email. That record is then searched to
• this key is used to decrypt the stemp to recover the unique information (hereafter referred to as the transaction number) encrypted into the stemp that directly or indirectly gives the identity of the sender.
• the recipient computer receives the valid message and puts the protected email in its inbox and displays the appropriate custom indication, generic logo or white list source icon received with the valid message from the server.
• This custom indication, generic logo or white list source icon is displayed in the inbox with the protected email indicating to the user the source of the email has been validated. If a jingle or soundmark is associated with the protected email, that jingle or soundmark is played to the user when the protected email is first displayed or is selected by the user.
• Figure 11 shows a diagrammatic representation of machine in the exemplary form of a computer system 300 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
• the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
• the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
• the machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
• PC personal computer
• PDA Personal Digital Assistant
• STB set-top box
• WPA Personal Digital Assistant
• the exemplary computer system 300 includes a processor 302 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 304 and a static memory 306, which communicate with each other via a bus 308.
• the computer system 300 may further include a video display unit 310 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
• the computer system 300 also includes an alphanumeric input device 312 (e.g., a keyboard), a user interface (UI) navigation device 314 (e.g., a mouse), a disk drive unit 316, a signal generation device 318 (e.g., a speaker) and a network interface device 320.
• a processor 302 e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both
• main memory 304 e.g., RAM
• static memory 306 e.g., RAM
• machine-readable medium 322 is shown in an exemplary embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
• the term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions.
• the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.

Landscapes

• Business, Economics & Management (AREA)
• Engineering & Computer Science (AREA)
• Accounting & Taxation (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• Human Resources & Organizations (AREA)
• Theoretical Computer Science (AREA)
• General Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• Entrepreneurship & Innovation (AREA)
• Economics (AREA)
• Finance (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• Operations Research (AREA)
• Marketing (AREA)
• Data Mining & Analysis (AREA)
• Computer Hardware Design (AREA)
• Development Economics (AREA)
• Information Transfer Between Computers (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Priority Applications (1)

Applications Claiming Priority (6)

Publications (2)

Family

ID=36036985

Family Applications (1)

Country Status (2)

Cited By (4)

Family Cites Families (3)

• 2005
  • 2005-09-07 EP EP05794922A patent/EP1810159A2/de not_active Withdrawn
  • 2005-09-07 WO PCT/US2005/031901 patent/WO2006029222A2/en not_active Ceased

Also Published As

Similar Documents

Legal Events