Abstract:
A system and method supporting instant messaging which removes many of the problems and barriers to the use of instant messaging through the use of universally unique identifiers to web pages for instant messaging sessions, with recipients invited to the instant messaging session via email.

Description:
TECHNICAL FIELD  
         [0001]    This invention relates to initiation of an Instant Messaging (IM) session between two or more parties and communication using a “standard/standalone” Instant Messaging paradigm with or without email integration.  
         BACKGROUND ART  
         [0002]    There are at least four major problems that are common in today&#39;s Instant Messaging (IM) systems including: “screen name” namespace problems, privacy problems, lack of acceptable and automated Instant Messaging message archiving, and service provider compatibility/software deliverability problems.  
           [0003]    The namespace problem can be broken down into three sub-problems, as follows:  
           [0004]    “Screen names” are not unique across IM providers. In today&#39;s Instant Messaging software, each Instant Messaging service provider maintains a separate and proprietary “screen name” namespace. This leads to users of one Instant Messaging service not being able to freely communicate with the users of a different Instant Messaging service provider because names in each namespace are not universal, so, for example, the user “Johril” in AOL&#39;s Instant Messenger (AIM) might refer to John Smith, while “John P in Yahoo&#39;s Messenger might refer to John Jones.  
           [0005]    Obtaining a desired name is difficult, and will only get more difficult. The namespaces available within each Instant Messaging provider are extremely crowded. For example, when signing up with the largest of the Instant Messaging providers, AOL&#39;s Instant Messenger (AIM) service, a typical user would rarely succeed with their first choice for a screen name because there are over 90 million names already in use. In the case of AOL, this problem will only get worse as over 3 million new users sign up for AIM each month.  
           [0006]    “Screen names” frequently have little or no connection to a person&#39;s “real” name. Most Instant Messaging screen names are names like “doglover3”, “corvette33”, etc., since, as described above, names like “John Smith” have all been taken. Therefore users end up with screen names which are hard for others to remember. This problem is of particular concern in the business world where universal and recognizable user names are essential for conducting business.  
           [0007]    The privacy problem can be seen as follows. In the Instant Messaging environments available by current Instant Messaging providers a particular user&#39;s presence online can easily, or even automatically, be detected by others. When a user begins an Instant Messaging session using one of these Instant Messaging providers, all other users who are interested in this user are notified that the he just went “online”. Some Instant Messaging providers do provide some protection against this “presence detection”. They may allow users to set an option to either let “no one” know that they are online, or to block certain people from knowing they are online. Unfortunately, these type of features are cumbersome to use since they are not automatic and force users to constantly manage who can “see” them and who can&#39;t.  
           [0008]    The Instant Messaging messaging archiving problem can be seen as follows. Some currently available Instant Messaging client software allows users to save transcripts of an Instant Messaging session as a file on their computer disk. But the client software does not allow them to file these sessions away, title them, etc., as they would with email, and the feature is cumbersome enough that most users either don&#39;t know it exists, or simply don&#39;t use it. This gives Instant Messaging a disadvantage when compared to email because it does not allow the user to maintain an automatic archive of what was discussed in the Instant Messaging session.  
           [0009]    There are several problems associated with Instant Messaging service provider compatibility and software delivery. Today, Instant Messaging service providers require users download a particular piece of software to execute on their computer. This type of Instant Messaging software causes at least three major problems.  
           [0010]    Lack of interoperability causes a significant problem. Each Instant Messaging service provider only supports its own Instant Messaging protocol and client software. Clients from one Instant Messaging service provider, using that service provider&#39;s Instant Messaging software can typically only communicate with other people who use the same service provider and software. A person cannot arbitrarily send an Instant Message to another person, unless that other person uses the same Instant Messaging service provider and software that they do. For example, “Joe” uses AOL&#39;s Instant Messenger, and “Jane” uses Yahoo&#39;s Messenger. Even if Joe and Jane know each other&#39;s screen names, they cannot communicate with each other since they are using different Instant Messaging service providers.  
           [0011]    Lack of platform independence is another problem. Today&#39;s Instant Messaging service providers and software typically will only execute on a limited number of hardware platforms, so users on non-supported platforms will not be able to communicate with users on supported platforms.  
           [0012]    The inability to work through network “firewalls ” causes additional problems. The current Instant Messaging service providers and software offerings will typically not work through “firewalls”. Since most business enterprises have firewalls in place, these programs preclude users inside the organization from communicating with users outside of the organization. Additionally, as home networks become more prevalent, the use of firewalls will become more common and the significance of this problem will increase.  
         SUMMARY OF THE INVENTION  
         [0013]    Certain embodiments of the present invention are directed to a system supporting the initiation of an Instant Messaging (IM) session between two or more parties through the use of email programs and standard web browsers. Additionally, it allows users to communicate using a “standard/standalone” Instant Messaging paradigm (i.e. without email integration) which affords users the features of today&#39;s popular Instant Messaging services, but also provides at least the additional benefits listed in the summary.  
           [0014]    Regarding the namespace problem, users are not required to use proprietary “screen names”. Instead, the inventive system allows the parties to use their email address as their “screen name”. Email addresses have the advantages that they are much more pervasive and established than typical Instant Messaging “screen names”, and valid email addresses are guaranteed to be universally unique names.  
           [0015]    The present invention details a process whereby a computer user may send an “IM Enhanced” or “Live” email to another person, using a standard email program, by knowing only the recipient&#39;s email address.  
           [0016]    Regarding the privacy problem, when an Instant Messaging session is initiated via email, strict privacy rules are enforced in a non-intrusive manner; one user cannot “blindly” initiate a messaging session with another user, unless the second user accepts the Instant Messaging invitation. Furthermore, the initial chat request is not delivered via an Instant Message, rather, it is delivered in an email. Upon receipt of the email invitation, the recipient initiates an Instant Messaging conversation with the sender (who&#39;s acceptance is implicit since the sender initiated the Instant Messaging request). When an Instant Messaging session is initiated via the “standalone” Instant Messaging web page, the user is able to control presence detection in the same sorts of ways as most commonly available Instant Messaging software allows.  
           [0017]    The present invention also details the process whereby users may indicate that presence detection is allowed only to certain individuals simply by sending those individuals an email/IM invitation. This email becomes the implicit “permission” for the recipient to converse with the sender, so no other action is required on the part of the sender. This provides a very dynamic and powerful means of granting “permission” to message, and the permissions may even be email message specific. This means that if Joe sends Jane an IM-enhanced email, Jane would be able to communicate to Joe through that email, but if Jane used the standalone Instant Messaging service, she may not by able detect Joe&#39;s presence, assuming Joe has “total privacy” selected.  
           [0018]    The sender is not able to initiate the Instant Messaging conversation in any way other than through an email. This prevents users from getting Instant Messaging “spam”. If the recipient accepts the Instant Messaging invitation included in the email, they can begin a conversation with the sender (who is assumed to have implicitly accepted IMs from the recipient). Since these Instant Messaging conversations are initiated via email, the spam problem is also addressed by leveraging all of the protections already in place for protecting users against email spam, this includes existing legislation, filtering software, etc.  
           [0019]    Regarding the problem of Instant Messaging message archiving, users may choose to permanently save Instant Messaging sessions in much the same way that they save email. The Instant Messaging session might even be saved as part of the email. This allows Instant Messaging archives to be referred back to in the future. Additionally, if there was an Instant Messaging session as a result of an email, that Instant Messaging session will be automatically saved in conjunction with the email, so that anytime in the future the user chooses to read that particular piece of email, they will also see the associated messaging.  
           [0020]    Upon receiving such an email, the recipient will be able to read the email “body” as they always have, and below the email body will be an area in which to participate in an Instant Messaging conversation with the sender.  
           [0021]    As the Instant Messaging session proceeds, it is constantly being saved on the server computer, which provides the Instant Messaging support. This allows users to file away emails as always, and at any future time, when they view the email, the full transcript of the Instant Messaging session will also appear. This allows users to both maintain conversations about the email together with the email, as well as to maintain an automatic archive of their Instant Messaging session (users would, of course, be able to disable this feature).  
           [0022]    Regarding Instant Messaging service provider compatibility and software delivery problems, no explicit signup or software is needed. Sender and recipient need not be signed up with a common Instant Messaging service provider, or any service provider at all in order to message each other. Users may “message” each other without the need for explicit client software downloads. Messaging is performed with standard DHTML within an email window [though the Instant Messaging part of this invention can also be utilized in an “IM only” mode, without the use of email].  
           [0023]    This “IM area” is rendered within the email message, using only generally available browser technologies, such as DHTML. No other software is required for the user to download, and no “plugins” are required. This allows any user with a popular browser to immediately, and seamlessly, participate in an Instant Messaging session.  
           [0024]    The whole Instant Messaging session takes place using only the publicly-defined internet protocol known as HTTP allowing Instant Messaging conversations to take place across firewalls. The present invention also details the process whereby a computer user may send or receive “standard” Instant Messages, from a web-based Instant Messaging web page/application. The implementation of this “standalone” web page uses the same software “engine” as the software described above, which allows users to Instant Messaging each other within their emails. Though there are many benefits to the email/Im solution, a standalone solution is required as well, since the sender needs a way to communicate with the recipient once the recipient chooses to initiate an Instant Messaging session. Additionally, users often choose to communicate only via Instant Messages, and not use email. It is in the standalone incantation of this software where the privacy and presence-hiding and http presence-detection features of this software shine.  
           [0025]    These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0026]    [0026]FIG. 1 depicts a system comprising a server  100  communicatively coupled to associated client computers used by users supporting email communications and web browser compliant communications to provide instant messaging between at least two of the users;  
         [0027]    [0027]FIG. 2A depicts a detail flowchart of server program system  1000  of FIG. 1 for supporting instant messaging between at least two of the users;  
         [0028]    [0028]FIG. 2B depicts a detail flowchart of operation  1012  of FIG. 2A for creating the instant messaging session;  
         [0029]    [0029]FIG. 3 depicts a detail flowchart of operation  1022  of FIG. 1 for providing the instant messaging session;  
         [0030]    [0030]FIG. 4A depicts a detail flowchart of operation  1122  of FIG. 3 for transferring the at least one received communication from the first member;  
         [0031]    [0031]FIG. 4B depicts a detail flowchart of server program system  1000  of FIG. 1 for supporting instant messaging between at least two users;  
         [0032]    [0032]FIG. 5A depicts a detail flowchart of operation  1192  of FIG. 4B for maintaining the database referencing the history;  
         [0033]    [0033]FIG. 5B depicts a detail flowchart of operation  1172  of FIG. 4A for sending the at least one processed communication from the first member;  
         [0034]    [0034]FIG. 5C depicts a detail flowchart of operation  1212  of FIG. 5A for maintaining the history;  
         [0035]    [0035]FIG. 6 is a refinement of FIG. 1 showing server  100  coupled  102  to instant messaging session  130  and further coupled  104  to database  150 ;  
         [0036]    [0036]FIG. 7A depicts a detail flowchart of operation  1262  of FIG. 5C for maintaining the communication history;  
         [0037]    [0037]FIG. 7B depicts a detail flowchart of operation  1272  of FIG. 7A for creating the instant messaging session with the universally unique identifier;  
         [0038]    [0038]FIG. 7C depicts a detail flowchart of operation  1192  of FIG. 4B for maintaining the database;  
         [0039]    [0039]FIG. 8B depicts a detail flowchart of operation  1342  of FIG. 8A for creating the history;  
         [0040]    [0040]FIG. 9 depicts a detail flowchart of operation  1172  of FIG. 4A for sending the instant messaging invitation email message to the associated email address designated for each of the recipients;  
         [0041]    [0041]FIG. 10A depicts a detail flowchart of client program system  2000  of FIGS. 1 and 6 for controlling the associated client computer based upon the use by the user and the communicatively coupled server  100 ;  
         [0042]    [0042]FIG. 10B depicts a detail flowchart of operation  2012  of FIG. 10A for support of email and web browser compliant communication;  
         [0043]    [0043]FIG. 10C depicts a detail flowchart of operation  2012  of FIG. 10A for providing support for email communication and for web browser compliant communication;  
         [0044]    [0044]FIG. 11A depicts a detail flowchart of operation  2042  of FIG. 10B for receiving the instant messaging invitation email message;  
         [0045]    [0045]FIG. 11B depicts a detail flowchart of operation  2052  of FIG. 10C for receiving the transferred communication;  
         [0046]    [0046]FIG. 12A depicts a detail flowchart of operation  2072  of FIG. 11A for using the received instant messaging invitation email message by the recipient;  
         [0047]    [0047]FIG. 12B shows a refinement of the relationships involved with database  150  of FIG. 6 regarding references involved with it and its components; and  
         [0048]    [0048]FIG. 13 depicts an application of the instant messaging system in a situation where different users prefer multiple languages.  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0049]    [0049]FIG. 1 depicts a system comprising a server  100  communicatively coupled to associated client computers used by users supporting email communications and web browser compliant communications to provide instant messaging between at least two of the users.  
         [0050]    The server computer  110  delivers formatted web pages to the client computer providing an area for the user of the client computer to participate in an Instant Messaging session. Each Instant Messaging session has a universally unique identifier, which the server computer uses to identify and store individual Instant Messages.  
         [0051]    Server  100  communicatively couples  224  to client computer  210  used by user  200  supporting email communications and web browser compliant communications. Similarly, server  100  communicatively couples  324  and  424  to client computers  310  and  410  user by users  300  and  400 , respectively.  
         [0052]    Server  100  includes server computer  110  accessibly coupled  122  to server memory  120 . Server program system  1000  operates server  100  and is comprised of program steps residing in server memory  120 .  
         [0053]    Each client computer  210 ,  310 , and  410 , is accessibly coupled  222 ,  322  and  422  to a respective memory  220 ,  320 , and  420 . In certain embodiments of the invention, program system  2000  operates the associated client computer based upon the interaction of the user and communications with server  100 .  
         [0054]    Each user may employ at least one of acoustic and tactile input to the associated client computer in its use. The usage may vary. By way of example, user  200  may use  212  tactile input such as a keyboard and pointing device. User  300  may use  312  acoustic input exclusively. User  400  may user  412  a combination of acoustic and tactile input.  
         [0055]    User presentation of instant messaging communication as well as alerts regarding instant messaging invitations may be presented in at least one of the following ways: visually, acoustically, and tactilely.  
         [0056]    By way of example, the visual alert may include an icon presented on a view screen, or by turning on a light. The acoustic alert may emit at least one of the following: an alert sound or an alert audio message. A tactile alert may include raising or lowering a tactile output member, such as found on a Braille keyboard. Any of these alerts may include a representation of the first user, the time of receipt of the invitation, as well as other information which may be part of the invitation, such as the intended topic or agenda of the instant messaging session.  
         [0057]    By way of example, the areas of a web page may be associated with distinct voices by which contented presented in an area may be acoustically presented to the user. The acoustic presentation may follow the order of receipt of the transferred communication, or the user may specify that a priority scheme by which various transferring communications received within a period of time are ordered for presentation. The user may further specify that differing voices may be presented louder or softer. The user may silence a voice.  
         [0058]    Note that the server  100  communicatively coupled to the associated client computer used by the user may further support a version of TCP-IP compliant protocols in communication with the user, for at least one of the users.  
         [0059]    Server  100  communicatively coupled to the associated client computer used by the user may further support at least one of the following:  
         [0060]    a version of Wireless Application Protocol (WAP) compliant protocols in communication with the user;  
         [0061]    a version of Bluetooth compliant protocols in communication with the user;  
         [0062]    a version of HTTP compliant protocols in communication with the user; and  
         [0063]    a version of XML compliant protocols in communication with the user.  
         [0064]    Instant messaging session  130  involves a universally unique identifier  132  and web page  140  based upon that universally unique identifier, initiated by a first user  134  involving at least one recipient  136  contacted by email through their email address. Each recipient  136  is sent an instant messaging invitation email message.  
         [0065]    The first user  134  is a member of the audience collection  138 . When and if a recipient  136  responds to the instant messaging invitation email message, it becomes a member of the audience collection  138 .  
         [0066]    When a communication  142  is received from a first member of the audience collection  138 , a transferred communication  144  from the first member is sent to all audience collection members.  
         [0067]    Upon receipt of communication  142 , it may be processed to create the processed communication  142  from the first member, which is then sent to all audience collection members as the transferred communication  144 .  
         [0068]    [0068]FIG. 2A depicts a detail flowchart of server program system  1000  of FIG. 1 for supporting instant messaging between at least two of the users.  
         [0069]    Arrow  1010  directs the flow of execution from starting operation  1000  to operation  1012 . Operation  1012  performs creating an instant messaging session with a universally unique identifier initiated by a first of the users for recipients designated as at least one of the remaining of the users. Arrow  1014  directs execution from operation  1012  to operation  1016 . Operation  1016  terminates the operations of this flowchart.  
         [0070]    Arrow  101010  directs the flow of execution from starting operation  1000  to operation  101012 . Operation  101012  performs providing the instant messaging session identified by the universally unique identifier as a formatted web page to each of the designated recipients and to the first user. Arrow  101014  directs execution from operation  101012  to operation  1016 . Operation  1016  terminates the operations of this flowchart.  
         [0071]    [0071]FIG. 2B depicts a detail flowchart of operation  1012  of FIG. 2A for creating the instant messaging session.  
         [0072]    Arrow  1050  directs the flow of execution from starting operation  1012  to operation  1052 . Operation  1052  performs receiving an instant messaging session request from the first user for recipients each designated by an associated email address for the at least one of the remaining users. Arrow  1054  directs execution from operation  1052  to operation  1056 . Operation  1056  terminates the operations of this flowchart.  
         [0073]    Arrow  1060  directs the flow of execution from starting operation  1012  to operation  1062 . Operation  1062  performs assigning the universally unique identifier based upon the instant messaging session request. Arrow  1064  directs execution from operation  1062  to operation  1056 . Operation  1056  terminates the operations of this flowchart.  
         [0074]    Arrow  1070  directs the flow of execution from starting operation  1012  to operation  1072 . Operation  1072  performs sending an instant messaging invitation email message to the associated email address designated for each of the recipients. Arrow  1074  directs execution from operation  1072  to operation  1056 . Operation  1056  terminates the operations of this flowchart.  
         [0075]    [0075]FIG. 3 depicts a detail flowchart of operation  1022  of FIG. 1 for providing the instant messaging session.  
         [0076]    Arrow  1090  directs the flow of execution from starting operation  1022  to operation  1092 . Operation  1092  performs creating the web page referenced based upon the universally unique identifier. Arrow  1094  directs execution from operation  1092  to operation  1096 . Operation  1096  terminates the operations of this flowchart.  
         [0077]    Arrow  1100  directs the flow of execution from starting operation  1022  to operation  1102 . Operation  1102  performs providing the web page with an area associated with the first user for participation. Arrow  1104  directs execution from operation  1102  to operation  1096 . Operation  1096  terminates the operations of this flowchart.  
         [0078]    Arrow  1110  directs the flow of execution from starting operation  1022  to operation  1112 . Operation  1112  performs providing the web page with another area associated with the recipient for participation upon response to the instant messaging invitation email message, for each of the recipients. Arrow  1114  directs execution from operation  1112  to operation  1096 . Operation  1096  terminates the operations of this flowchart.  
         [0079]    As used herein, an audience collection will include the first user and each of the recipients responding to the instant messaging invitation email message.  
         [0080]    Arrow  1120  directs the flow of execution from starting operation  1022  to operation  1122 . Operation  1122  performs transferring at least one received communication from the associated client computer operated by a first of the members of the audience collection to all of the members of the audience collection to create a transferred communication as content in the area associated with the first member. Arrow  1124  directs execution from operation  1122  to operation  1096 . Operation  1096  terminates the operations of this flowchart.  
         [0081]    [0081]FIG. 4A depicts a detail flowchart of operation  1122  of FIG. 3 for transferring the at least one received communication from the first member.  
         [0082]    Arrow  1150  directs the flow of execution from starting operation  1122  to operation  1152 . Operation  1152  performs receiving at least one communication from the first member of the audience collection to create at least one received communication. Arrow  1154  directs execution from operation  1152  to operation  1156 . Operation  1156  terminates the operations of this flowchart.  
         [0083]    Arrow  1160  directs the flow of execution from starting operation  1122  to operation  1162 . Operation  1162  performs processing at least one received communication from the first member to create at least one processed communication from the first member. Arrow  1164  directs execution from operation  1162  to operation  1156 . Operation  1156  terminates the operations of this flowchart.  
         [0084]    Arrow  1170  directs the flow of execution from starting operation  1122  to operation  1172 . Operation  1172  performs sending at least one processed communication from the first member to create the transferred communication as content in the area associated with the first member to all audience collection members. Arrow  1174  directs execution from operation  1172  to operation  1156 . Operation  1156  terminates the operations of this flowchart.  
         [0085]    [0085]FIG. 4B depicts a detail flowchart of server program system  1000  of FIG. 1 for supporting instant messaging between at least two users.  
         [0086]    Arrow  1190  directs the flow of execution from starting operation  1000  to operation  1192 . Operation  1192  performs maintaining a database referencing a history of the instant messaging session with the universally unique identifier. Arrow  1194  directs execution from operation  1192  to operation  1196 . Operation  1196  terminates the operations of this flowchart.  
         [0087]    [0087]FIG. 5A depicts a detail flowchart of operation  1192  of FIG. 4B for maintaining the database referencing the history.  
         [0088]    Arrow  1210  directs the flow of execution from starting operation  1192  to operation  1212 . Operation  1212  performs maintaining the history of the instant messaging session with the universally unique identifier for the audience collection. Arrow  1214  directs execution from operation  1212  to operation  1216 . Operation  1216  terminates the operations of this flowchart.  
         [0089]    [0089]FIG. 5B depicts a detail flowchart of operation  1172  of FIG. 4A for sending at least one processed communication from the first member.  
         [0090]    Arrow  1230  directs the flow of execution from starting operation  1172  to operation  1232 . Operation  1232  performs sending the processed communication from the first member as content in the area associated with the first member to the history of the instant messaging session with the universally unique identifier. Arrow  1234  directs execution from operation  1232  to operation  1236 . Operation  1236  terminates the operations of this flowchart.  
         [0091]    [0091]FIG. 5C depicts a detail flowchart of operation  1212  of FIG. 5A for maintaining the history.  
         [0092]    Arrow  1250  directs the flow of execution from starting operation  1212  to operation  1252 . Operation  1252  performs receiving the transferred communication from the first member at the history to create a history-received communication from the first member. Arrow  1254  directs execution from operation  1252  to operation  1256 . Operation  1256  terminates the operations of this flowchart.  
         [0093]    [0093]FIG. 6 is a refinement of FIG. 1 showing server  100  coupled  102  to instant messaging session  130  and further coupled  104  to database  150 .  
         [0094]    Note that in certain embodiments of the invention, there is no database  150 , when it is required that no lasting record of the instant messaging session, is kept. Such embodiments enforce the instant messaging session confidentiality cannot be broken at a later time.  
         [0095]    When there is a database  150 , it references  152  history  154  of the instant messaging session  130 . History  154  may reference  156  universally unique identifier  158 , which is based upon universally unique identifier  132  of instant messaging session  130 . Note that history  154  may persist after instant messaging session  130  has ended. In some circumstances, history  154  may be built from instant messaging session  130 . Such a build process may occur when the session was initiated or later, possibly when the session ends.  
         [0096]    History  154  may also reference  160  audience list  162  based upon audience collection  138 .  
         [0097]    History  154  may also reference  164  a communication history  166 , which further references communications records  168 , each of which may be based upon at least one of the received communication  142 , processed communication  144 , and transferred communication  146 .  
         [0098]    Depending upon the options the initial sender  134  setup when Instant Messaging session  130  was initiated, the server  100  may retain the complete transcript  166  of the Instant Messaging session.  
         [0099]    This is a simple matter for server  100  to do, since each and every Instant Messaging  130  has a unique ID  132 . Communication  142  between users  200 ,  300 , and  400  must pass through the server  100  prior to delivery and is uniquely bound to its Instant Messaging session  130  via a unique ID  132 .  
         [0100]    This is a powerful feature, in that the URL contained in the email initiating the whole Instant Messaging session  130  always contains that unique ID  132 . The user whenever looking at that email at any time in the future, will trigger the server  100  to attempt fetching all the Instant Messaging messages  168  has stored for that email. The email will then continue to display to the user the complete Instant Messaging transcript associated with the email.  
         [0101]    [0101]FIG. 7A depicts a detail flowchart of operation  1262  of FIG. 5C for maintaining the communication history.  
         [0102]    Arrow  1270  directs the flow of execution from starting operation  1262  to operation  1272 . Operation  1272  performs creating a new communication record containing the first member history-received communication as the communication from the first member. Arrow  1274  directs execution from operation  1272  to operation  1276 . Operation  1276  terminates the operations of this flowchart.  
         [0103]    Arrow  1280  directs the flow of execution from starting operation  1262  to operation  1282 . Operation  1282  performs adding the new communication record to the communication history. Arrow  1284  directs execution from operation  1282  to operation  1276 . Operation  1276  terminates the operations of this flowchart.  
         [0104]    [0104]FIG. 7B depicts a detail flowchart of operation  1272  of FIG. 7A for creating the instant messaging session with the universally unique identifier.  
         [0105]    Arrow  1310  directs the flow of execution from starting operation  1272  to operation  1312 . Operation  1312  performs sending the database an initiating request for the instant messaging session with the universally unique identifier by the first user for the recipients. Arrow  1314  directs execution from operation  1312  to operation  1316 . Operation  1316  terminates the operations of this flowchart.  
         [0106]    [0106]FIG. 7C depicts a detail flowchart of operation  1192  of FIG. 4B for maintaining the database.  
         [0107]    Arrow  1330  directs the flow of execution from starting operation  1192  to operation  1332 . Operation  1332  performs receiving the initiating request for the instant messaging session with the universally unique identifier by the first user for the recipients at the database. Arrow  1334  directs execution from operation  1332  to operation  1336 . Operation  1336  terminates the operations of this flowchart.  
         [0108]    Arrow  1340  directs the flow of execution from starting operation  1192  to operation  1342 . Operation  1342  performs creating the history of the instant messaging session with the universally unique identifier from the initiating request for the instant messaging session with the universally unique identifier by the first user for the recipients. Arrow  1344  directs execution from operation  1342  to operation  1346 . Operation  1346  terminates the operations of this flowchart.  
         [0109]    [0109]FIG. 8B depicts a detail flowchart of operation  1342  of FIG. 8A for creating the history.  
         [0110]    Arrow  1370  directs the flow of execution from starting operation  1342  to operation  1372 . Operation  1372  performs creating an audience list containing references to each member of the audience collection. Arrow  1374  directs execution from operation  1372  to operation  1376 . Operation  1376  terminates the operations of this flowchart.  
         [0111]    Arrow  1380  directs the flow of execution from starting operation  1342  to operation  1382 . Operation  1382  performs creating a first of the communication records in the communication history based upon the initiating request. Arrow  1384  directs execution from operation  1382  to operation  1376 . Operation  1376  terminates the operations of this flowchart.  
         [0112]    Note that various embodiments of the invention may implement one or both of the operations of FIG. 8B.  
         [0113]    [0113]FIG. 9 depicts a detail flowchart of operation  1172  of FIG. 4A for sending the instant messaging invitation email message to the associated email address designated for each of the recipients.  
         [0114]    Arrow  1410  directs the flow of execution from starting operation  1172  to operation  1412 . Operation  1412  performs sending the instant messaging invitation email message containing a body further including the web page referenced by the universally unique identifier actively embedded in the body to the associated email address designated for at least one of the recipients. Arrow  1414  directs execution from operation  1412  to operation  1416  Operation  1416  terminates the operations of this flowchart.  
         [0115]    Arrow  1420  directs the flow of execution from starting operation  1172  to operation  1422 . Operation  1422  performs sending the instant messaging invitation email message containing a body further including a link to the web page referenced by a URL based upon the universally unique identifier to the associated email address designated for at least one of the recipients. Arrow  1424  directs execution from operation  1422  to operation  1416 . Operation  1416  terminates the operations of this flowchart.  
         [0116]    Arrow  1430  directs the flow of execution from starting operation  1172  to operation  1432 . Operation  1432  performs sending the instant messaging invitation email message containing a body further including an icon referenced by the universally unique identifier to the associated email address designated for at least one of the recipients. Arrow  1434  directs execution from operation  1432  to operation  1416 . Operation  1416  terminates the operations of this flowchart.  
         [0117]    Note that in various situations, a combination of the operations of FIG. 9 may be performed to send instant messaging invitations to a collection of recipients.  
         [0118]    An email with an integrated Instant Message may be created in one of two methods:  
         [0119]    The first method uses a web based email program including a typical email “body”, an area for users to Instant Message each other, and a unique identifier (ID)  132  appended to the URL of the email, and serves to differentiate this email (and potential Instant Messaging session) from all others.  
         [0120]    The second method uses a supported 3rd-party client email program, such as Microsoft Outlook, Eudora and Netscape Communicator. Under this scenario an “Embeddable IM” icon may added to the email program&#39;s toolbar, allowing users to drag the icon down and “drop” it into their email.  
         [0121]    This invokes software embeding a URL to the Instant Messaging facility in the client&#39;s email. This URL is based upon unique identifier  132 .  
         [0122]    In either case, the URL which is generated, either for the web based email, or as an Instant Messaging URL inserted into a “standard” email, will be tagged with an ID  132  for the sender and with a flag indicating that it is an “email IM”. In this way the recipient is supported in Instant Messaging with the sender regardless of which users the sender has given “presence detection” permission to.  
         [0123]    In any case, the sender&#39;s email address must also be included as part of the email (or server form submission). This is so that when the recipient responds the response can be correctly routed to the sender. This can be viewed as a return address. The very first time that a user sends an IM-enriched email they may have to type in their email address, but after that the email address may preferably be stored in a cookie on their computer so that all subsequent Instant Messaging emails can automatically contain it.  
         [0124]    When responding to IM-enriched emails, the recipient&#39;s email address must be included with the IM, either in the URL or the Instant Messaging itself. This is the recipient&#39;s return address and is required for the same reasons above. The return address will be obtained from the recipient as described above.  
         [0125]    If an email is sent in the first method, the email body is sent by the client browser code up to the server computer  110 . Server computer  110  then may preferably store this email message in the server-side database  150 , allowing for future retrieval via URL.  
         [0126]    When the recipient receives an email via either of the methods described above, it contains a standard email subject line and body, but may preferably contains a text area allowing the recipient to communicate with the sender.  
         [0127]    If the recipient chooses not to communicate with the sender, no further action is taken, and the email may be handled/disposed of as the client user wishes.  
         [0128]    If the recipient does choose to utilize the preferably built-in instant messaging feature, they simply input their message into the text area, and activate a Send button near the text area. This preferably causes client-side DHTML (HTML and JavaScript) to be invoked sending the message, via HTTP, back to the server computer  110 .  
         [0129]    Upon receiving this client request  1152 , the server preferably checks the database  150  to see if it recognizes any Instant Messaging sessions  130  with that particular ID  132 .  
         [0130]    If it does, it preferably associates this message  142  with that unique ID, and stores it in the server-side database in some form  168 . This approach allows the system to operate on virtually any hardware platform, operate through firewalls, etc.  
         [0131]    Normally, when an Instant Messaging is received  1152  by the server computer  110 , it compares the source of the email against the target user&#39;s the Instant Messaging list of acceptable senders, and only delivers the Instant Messaging if the target user is willing to accept it.  
         [0132]    The exception to occurs when an Instant Messaging comes in from an email source. The server computer  110  knows that the message is coming from an email source, because when the Instant Messaging URL  140  was first generated for insertion into the email, the URL was tagged with an ID  132  for the sender and with a flag indicating that it is an “email IM”. In this case, the server  100  knows that the recipient is allowed to Instant Messaging with the sender regardless of which users the sender has given “presence detection” permission to. If the recipient does not have permission to detect the sender&#39;s presence using standalone software, they would still not be able to do that. They would only be able to participate in Instant Messaging with the sender within the context of this particular email message.  
         [0133]    The ability to temporarily disable presence detection restrictions allows individuals like the sender to maintain a high degree of overall privacy without making it cumbersome to disable the privacy feature when having specific conversations with specific individuals. The procedure is not cumbersome because the act of sending the email automatically and implicitly grants the recipient Instant Messaging permissions in this particular case.  
         [0134]    From the sender&#39;s side, if the sender of the email is using the standalone web page version of the Instant Messaging software, that standalone client software is constantly (every few seconds) making HTTP requests to the server asking if any new data has arrived for it. The server makes a note of the last time the client made such a request of it. On one of these requests, after the server has received an Instant Messaging from the recipient and stored it in the database, the server computer responds to the sending client&#39;s request with any newly received IMs. The server then marks those IMs in the database as “delivered”.  
         [0135]    If the sender of the email does not have the standalone web page version of the Instant Messaging software running, then when the server gets the Instant Messaging from the email recipient, it notices that the email sender&#39;s client software has not asked it for any messages in too long of a period of time (i.e. it has not been making requests every few seconds).  
         [0136]    The server knows this since it keeps track of client data requests. In such a case, the server automatically composes an email and sends it to the Instant Messaging target user. The email contains the IM, as well as the standard Instant Messaging text area so that when the email is received, the Instant Messaging session may commence directly from the received email. Under this scenario, both client users are utilizing the software via email.  
         [0137]    Following all of the above, the sender can Instant Messaging a response back to the recipient, and the same process takes place again, in reverse.  
         [0138]    [0138]FIG. 10A depicts a detail flowchart of client program system  2000  of FIGS. 1 and 6 for controlling the associated client computer based upon the use by the user and the communicatively coupled server  100 .  
         [0139]    Arrow  2010  directs the flow of execution from starting operation  2000  to operation  2012 . Operation  2012  performs providing support for email communication and for web browser compliant communication used by the user with the communicatively coupled server based upon at least one of tactile input from the user and acoustic input from the user. Arrow  2014  directs execution from operation  2012  to operation  2016 . Operation  2016  terminates the operations of this flowchart.  
         [0140]    [0140]FIG. 10B depicts a detail flowchart of operation  2012  of FIG. 10A for support of email and web browser compliant communication.  
         [0141]    Arrow  2030  directs the flow of execution from starting operation  2012  to operation  2032 . Operation  2032  performs sending the instant messaging session request initiated by the first user for the designated recipients to the communicatively coupled server. Arrow  2034  directs execution from operation  2032  to operation  2036 . Operation  2036  terminates the operations of this flowchart.  
         [0142]    Arrow  2040  directs the flow of execution from starting operation  2012  to operation  2042 . Operation  2042  performs receiving the instant messaging invitation email message for the user as the recipient from the communicatively coupled server to create a received instant messaging invitation email message. Arrow  2044  directs execution from operation  2042  to operation  2036 . Operation  2036  terminates the operations of this flowchart.  
         [0143]    Various embodiments of the invention may support one or both of the operations  2032  and  2042  operating the associated client computer used one of the users.  
         [0144]    [0144]FIG. 10C depicts a detail flowchart of operation  2012  of FIG. 10A for providing support for email communication and for web browser compliant communication.  
         [0145]    Arrow  2050  directs the flow of execution from starting operation  2012  to operation  2052 . Operation  2052  performs receiving the transferred communication from the first member to create a received-transferred communication from the first member. Arrow  2054  directs execution from operation  2052  to operation  2056 . Operation  2056  terminates the operations of this flowchart.  
         [0146]    [0146]FIG. 11A depicts a detail flowchart of operation  2042  of FIG. 10B for receiving the instant messaging invitation email message.  
         [0147]    Arrow  2070  directs the flow of execution from starting operation  2042  to operation  2072 . Operation  2072  performs using the received instant messaging invitation email message by the recipient to create an instant messaging response sent to the communicatively coupled server. Arrow  2074  directs execution from operation  2072  to operation  2076 . Operation  2076  terminates the operations of this flowchart.  
         [0148]    Arrow  2080  directs the flow of execution from starting operation  2042  to operation  2082 . Operation  2082  performs alerting the recipient of the received instant messaging invitation email message employing at least one member of a user output collection including visual output, acoustic output and tactile output. Arrow  2084  directs execution from operation  2082  to operation  2086 . Operation  2086  terminates the operations of this flowchart.  
         [0149]    [0149]FIG. 11B depicts a detail flowchart of operation  2052  of FIG. 10C for receiving the transferred communication.  
         [0150]    Arrow  2090  directs the flow of execution from starting operation  2052  to operation  2092 . Operation  2092  performs presenting the received-transferred communication from the first member as content in the area associated with the first member. Arrow  2094  directs execution from operation  2092  to operation  2096 . Operation  2096  terminates the operations of this flowchart.  
         [0151]    [0151]FIG. 12A depicts a detail flowchart of operation  2072  of FIG. 11A for using the received instant messaging invitation email message by the recipient.  
         [0152]    Arrow  2110  directs the flow of execution from starting operation  2072  to operation  2112 . Operation  2112  performs activating the embedded web page referenced by the universally unique identifier contained in the received instant messaging invitation email message by the recipient to create an instant messaging response sent to the communicatively coupled server. Arrow  2114  directs execution from operation  2112  to operation  2116 . Operation  2116  terminates the operations of this flowchart.  
         [0153]    Arrow  2120  directs the flow of execution from starting operation  2072  to operation  2122 . Operation  2122  performs activating the link to the web page referenced by the URL based upon the universally unique identifier contained in the received instant messaging invitation email message by the recipient to create an instant messaging response sent to the communicatively coupled server. Arrow  2124  directs execution from operation  2122  to operation  2116 . Operation  2116  terminates the operations of this flowchart.  
         [0154]    Arrow  2130  directs the flow of execution from starting operation  2072  to operation  2132 . Operation  2132  performs activating the icon referenced by the universally unique identifier contained in the received instant messaging invitation email message by the recipient to create an instant messaging response sent to the communicatively coupled server. Arrow  2134  directs execution from operation  2132  to operation  2116 . Operation  2116  terminates the operations of this flowchart.  
         [0155]    [0155]FIG. 12B shows a refinement of the relationships involved with database  150  of FIG. 6 regarding references involved with it and its components.  
         [0156]    In certain embodiments of the invention, database  150  may contain history  154  of the instant messaging session  130 .  
         [0157]    History  154  may contain the referenced universally unique identifier  158  based upon universally unique identifier  132  of instant messaging session  130 .  
         [0158]    History  154  may contain referenced audience list  162  based upon audience collection  138 .  
         [0159]    History  154  may also contain the referenced communication history  166 , which further contain the referenced communications records  168 , each of which may be based upon at least one of the received communication  142 , processed communication  144 , and transferred communication  144 .  
         [0160]    Note that for the sake of simplicity of discourse, these references are all shown individually as container relationships, though in practice any combination of them may be container relationships. Note that in other embodiments, these referenced relationships may be part of an inferential database  150 , where the relationships are of an implicative rather than container basis.  
         [0161]    [0161]FIG. 13 depicts an application of the instant messaging system in a situation where different users prefer multiple languages.  
         [0162]    Note that in certain embodiments of the invention, at least two members of the audience collection may have at least one associated language. Collectively, the communications between members of the audience collection may require more than one language.  
         [0163]    As an example, assume that user1  200  prefers language  230 , user2  300  prefers language  330  and user3  400  prefers language  430 , which are different. These distinct languages may be differing versions of the same basic human language, or may differ in terms of the basic human languages. Note that as used herein, a basic language such as English may have several versions, such as US, UK and Australian English.  
         [0164]    Note that the received communication  142  may be in first language  230 , and that the processed communication  144  may be in at least a second language  330 . The processed communication may be more than one language, by way of example, a third language  430 .  
         [0165]    Note that the transferred communication  146  would involve all the languages preferred by the audience collection members.  
         [0166]    The preceding embodiments have been provided by way of example and are not meant to constrain the scope of the following claims.