SYSTEM FOR IMMEDIATE POPUP MESSAGING ACROSS THE INTERNET

Abstract: A system for sending immediate popup messages between Internet (100) users, the system including a user (102) interface for sending messages and displaying messages in popup windows; a method and infrastructure for continuously tracking and reporting the online status of users (102), the infrastructure comprising servers and client software; and a method for communicating to users behind firewalls.

Description: SYSTEM FOR IMMEDIATE POPUP MESSAGING ACROSS THE INTERNET Background of the Invention The invention relates to a system for performing immediate point-to-point messaging over the Internet. Communication over the Internet takes on several forms-principally e-mail, chat, video and audio. These forms of communication are used in a variety of different contexts. E-mail is generally not perceived as "realtime" or "immediate"; messages may be read hours or days after they are sent. Chat is principally used as a social medium or for information sharing -- not for point-to-point communication. Video and audio are both real-time, but they are both relatively difficult to use, and widespread acceptance requires improvements in existing technology and user interfaces. There exists, on a limited basis, an additional form of communication -- popup messaging. A user A can send a popup message to another user B; the message immediately "pops up" on B's screen. The prototypical popup messaging system is the Zephyr system on MIT's campus computer network, Athena. Zephyr permits any Athena user to send popup messages to any other Athena user, but not to any user across the Internet. inPopup by Microsoft Corp. is a Windows utility to send popup messages between users; however, WinPopup, too, only permits messaging between users on the same network, and is not capable of sending messages across the Internet. Further, both Zephyr and WinPopup are not scaleable to high user volumes; they are designed for self-contained environments with a small or moderate number of users. Firewalls are machines commonly used for enforcing corporate network security policies; at least half of all Internet users and most business users connect to the Internet through a firewall. Firewalls represent a key impediment for real-time communication between Internet users. Firewall designs generally prohibit external entities on the Internet from connecting to internal entities protected by the firewall. While this is designed to prevent external entities from maliciously manipulating internal entities, it also has the side- effect of preventing asynchronous communication to an internal entity. Current forms of real-time Internet messaging are generally incapable of working through a firewall, without explicit firewall policy modifications by systems administrators. Summary of the Invention In general, in one aspect, the invention features a system for popup messaging between a plurality of Internet users. The invention includes a set of servers for managing, storing and routing communication between users, client software associated with individual users, a message protocol that defines the format and effect of each message in the system, and a user interface for sending messages and receiving popup messages . Preferred embodiments include the following features. The set of servers includes an unlimited set of Home Servers that permanently "own" individual users, and a Global Server that serves as a repository of permanent user information. The current status of each user is maintained by the user's Home Server. To send a popup message from one user to another, the sender's client first forwards the message to its Home Server, which then determines the identity of the recipient's Home Server, querying the Global Server if necessary. Subsequently, the sender's Home Server delivers the message to the recipient's Home Server, which then delivers the message to the recipient. In general, in another aspect, the invention features a system for tracking the online status of users. The invention features a contact list of correspondents maintained by each user, a continuously updated client "window" informing the user of the online status of each correspondent in the contact list, and the ability to receive a notification when any correspondent in the contact list logs in or logs off. Preferred embodiments include the following features. A user logs in by contacting his/her Home Server. The Home Server maintains a list of users who have the user on their contact list; upon user login, the Home Server notifies each of these users about the user's having logged in. Similarly, when the user logs off or otherwise aborts, the users Home Server notifies all interested users about the user's having logged off. In general, in still another aspect, the invention features a method for sending an asynchronous message in real time to a recipient behind a firewall. In preferred embodiments, when a user logs in by contacting his/her Home Server, the Home Server opens a dedicated "back connection" to the user, over which all subsequent messages are sent from the Home Server to the user. The Home Server employs a "MIME-multipart push" technique for instantly sending messages as parts of an arbitrarily long multipart message. The Home Server also regularly sends blank messages over the connection to keep the firewall connection active. One advantage of the invention is that it is capable of scaling to arbitrarily large numbers of users over the Internet . Other advantages and features will become apparent from the following description of the preferred embodiment and from the claims. Brief Description of the Drawing Fig. 1 shows the context of the system ("Flash") within the Internet. Fig. 2 shows the components of the Flash system, and the key functions performed by each component. Fig. 3 shows the steps involved in sending a flash message from a user A to another user B. Figs. 4A-E show the operation of a Flash client behind a firewall . Fig. 5 shows the data maintained by different components of the Flash system. Description of the Preferred Embodiment Referring to Figure 1, the Flash system consists of a network of Flash servers 100 interspersed through the Internet, and client software 101, with each user 102 possessing one instance of a client. When a user A sends a message to another user B, the client software for A, A', delivers the message, in general, to the network of Flash servers 100, which, after appropriate processing and routing, delivers it on to the client B' used by B. In the following discussion, the terms "user" and "client" will be used interchangeably for clarity; the meaning should follow from the context. Figure 2 illustrates the structure of the network of Flash servers, which consists of a single Global Server 200 and an arbitrarily large set of Home Servers 201. At the time of initial registration, each user U is permanently assigned a unique integer identifier UID (U) , and is also assigned to a particular Home Server HS (U) chosen from within the set of Home Servers. The Global Server 200 serves as a repository of all user information of a permanent nature. The most important function of the Global Server is to store the assignments of users to their Home servers; thus, it stores the mapping U → HS (U) for every user U registered with the Flash system. The other function is to store and provide searchable profile information for each user, so that users can "find" other users. This profile information generally includes the full name, address, phone number, etc. for each user. This profile information enables, for instance, a user to search for any "Bob Jones" registered on the Flash system, or to search for all the Smiths living in Florida. The purpose of a Home Server HS is to "own" a set of users -- set of users permanently assigned to HS . For any user U thus owned by it , a Home Server stores the current login status of U (i.e. "logged in" or "logged off), manages all communication to and from U, and stores messages intended for U but which cannot be immediately delivered to U (e.g., if U is not logged on when someone sends U a message) . It also stores a list of other users that U wishes to regularly keep in touch with (a "contact list"), and a list of users that have U on their contact list (a "contacter list"). There is no fundamental limit to the number of Home Servers in the Flash system; the system can handle an arbitrarily large number of Home Servers. Since each Home Server is designed to own at least 10,000 users, the Flash system scales up to an arbitrarily large number of users . Given that Internet users number in the tens of millions, the Global Server must withstand millions of queries a day. As will be described later, the Home Server must constantly "poll" (send regular messages to) each of its active users. Consequently, both the Global Server and Home Server must be high-end machines. In the preferred embodiment, the Global Server is a 200 MHz dual-processor Pentium Pro with 256 MB RAM, a replicated 10-Gigabyte hard drive, and a 100 Mbps Ethernet card with a T-3 Internet connection. The Home Server is a 200 -MHz dual-processor Pentium Pro with 128 MB RAM, a 4-Gigabyte hard drive, and a 10 Mbps Ethernet card with a T-l Internet connection. Figure 3 summarizes the operation of the Flash system with respect to sending messages from one user to another. When a user A sends a message M to a user B (by pressing the "Send" button on the message being composed), A' s client connects to A' s Home Server HS (A) and transmits M to it 300. Based on B's unique ID UID(B), HS(A) determines HS (B) as follows: if HS (A) is not already aware of HS (B) , it queries the global server GS for the identity of HS (B) 301. HS (A) then connects to HS(B) and transmits M to HS (B) 302. HS (B) then determines whether B is logged in. If B is logged in, HS(B) transmits M to B 303, in a manner that will be described; if B is not logged in, HS (B) stores the message for B and delivers it to B as soon as B next logs in. When the client B receives the message from HS (B) , it opens a popup window on the user's screen using standard user interface techniques. For instance, on Windows systems, the client calls functions resident in the Microsoft Foundation Classes (MFC) supplied by Microsoft Corp., to create a window of a specified size, display it on the screen, overlay it on top of the other applications, and paint the message content as well as some action buttons (e.g. "Done", "Reply", etc.) on the windo . The last step 303 in the above-described sequence of operations for sending a message M from A to B -- that of delivering the message to B -- requires a special technique if B is behind a firewall. The Flash system incorporates this special technique by default, as described in the following section, thus enabling any user behind a firewall to seamlessly use the system as though they were directly connected to the network. Figure 4A depicts a client C 403, a firewall F 401 and a generic external machine E 400 outside the firewall that intends to deliver a message M to C. If F were not present between E and C, E could directly connect to C and deliver M. Firewalls like F expressly prohibit external entities like E from connecting "inward" to internal entities like C asynchronously. Firewalls also commonly restrict connections from internal entities like C "outward" to external entities like E. Firewalls restrict such connections to a small set of Internet protocols; for instance, at one "Big Six" accounting firm, the only protocol allowed by the firewall for connections to external entities is HTTP, the Hyper Text Transport Protocol . Because most firewalls do allow HTTP and there is no other suitable protocol generally allowed by firewalls, all communication within the Flash system between a "firewalled" client and a Flash server must follow the HTTP convention. The special firewall technique employed in Flash works as depicted in Figures 4B-E. As shown in Figure 4B, when a client C behind a firewall F logs on to the Flash system, it connects to its Home Server HS (C) through F 411-412. Subsequently, as shown in Figure 4C, C sends HS(C) an HTTP POST message 421. As shown in Figure 4D, when HS (C) receives this request, it marks the state of user C as "logged in", and sends it an HTTP response 431 with the MIME-type-field set to "multipart/x-mixed-replace" . This is a commonly used technique for "pushing" information to HTTP clients, and is defined in the MIME specification, Internet RFC 1341. Unlike existing push products, Flash uses multipart sequences to send messages to a client. The HTTP response with "multipart/x-mixed-replace" signifies that the response is the first in an arbitrarily long series of messages; as shown in Figure 4E, HS (C) has now established a back connection 440 to C over which it can send further messages. Since multipart messages are a part of the HTTP specification, and since firewalls are usually compliant with HTTP, HS(C) usually succeeds in establishing a communications channel (the back connection) with C. Further, HS(C) can, at any time, send a message to C over the back connection; the only requirements are that the back connection be open (the connection will close if the client or server explicitly closes it, e.g. if the client logs out or if there are certain types of network errors) and that the message be formatted in the particular manner illustrated in 431, 442 and 444. With respect to the chain of events that occurs when a user A sends a flash message to user B (summarized in Figure 3) , when HS (B) needs to deliver a message to a logged-in user B, it formats the message in the required manner 442 and sends it on the back connection to B. Once every 4 minutes, HS (C) sends C a "blank" message 444. This keeps the firewall connection active; if HS(C) doesn't send C such a message, the firewall might time out and close the connection. The interval of 4 minutes has been found, by experimentation, to be the maximal interval that is generally accepted by firewalls without timing out. In the Flash system described above, each message from a user A to another user B passes through HS (B) . While this is necessary if B is behind a firewall, direct communication between A and B is possible if B is not behind a firewall. The preferred embodiment also covers optimizations of the basic model described above; in these optimizations, a message is delivered to the intended recipient through the most direct route possible. For each logged-in user U, HS (U) also stores information on the nature of the connection at U - i.e., the U's current IP address, and whether U is behind a firewall. Based on that information, a message to U can either be sent on the back connection to U, if U is behind a firewall, or directly to U at its IP address, if U is not behind a firewall. Figure 5 illustrates all the data maintained by Home Servers required to enforce such optimizations. Besides conveying messages between users, another pivotal function performed by the Flash system is managing a "contact list" of other users that a certain user intends to correspond with. The contact list is akin to a phone book that is initially empty and gradually accumulates contact information for correspondents. Initially, a user A's contact list is empty. For A to send a message to another user B, A must first add B to A's contact list. After being initially added to A's contact list, B stays on the list unless explicitly removed by A later. Thus, the contact list is persistent through logoffs and subsequent logins by A. Another important function performed by the Flash system is tracking members of the contact list. For each user B x on A's contact list, A is continually kept up-to- date on B x 's login status. This is important for A to know because if B 1 is not logged in at a particular instant, B x cannot receive a message immediately, and will only receive it the next time B 1 logs in. A's maintains a "contact window" that displays A's contact list, and next to each member B of the contact list, displays whether is logged in. When any user B x logs in or logs off, A's window immediately changes the displayed status for B . Figure 5 illustrates how Flash manages contact list information and tracking, by specifying the data maintained by different components of the Flash system. For a user A, HS (A) stores A's contact list (more precisely, the UID of each member Bi on A's contact list), A's contacter list (the UID of each member C that has A on his/her contact list), and A's current login status (whether "logged in" or "logged off). As described previously, A connects to HS (A) to log into the Flash system. Upon successful login, HS (A) sends a message to HS(C 1 ) for each user C x in A's contacter list. If x is logged in HS (C.) in turn sends the message to C 1 . The client C x updates the contact window to show A as logged in. Thus, when A logs in, every user C x who is logged in and who is on A's contacter list is informed of A's logging in. Similarly, when A logs out, A notifies HS (A) , which sends a message to HS (Cj for each user C x in A's contacter list. HS (C , in turn, informs C 1 . This is the desired logoff sequence, and is termed a "graceful logoff . The Flash system must also handle "nongraceful logoffs," in which a client A suddenly "dies" without contacting the server HS (A) . Such situations can arise in several ways, such as a user's machine crashing, the user's abruptly shutting off his/her machine, network failure, etc. The Flash system handles such occurrences through the "blank message" mechanism 444. If a client A crashes suddenly, the next blank message sent by HS (A) to A cannot be delivered, and the underlying TCP/IP stack will inform HS (A) of the fact. HS (A) will then conclude that A is logged off, and will inform each member C 1 of A's contacter list immediately, through the member's home server HS (C . Thus, users are provided with a constantly up-to- date status of every member in their contact list. A user C x may also request notification through a flash message when a user A on his/her contact list logs in or logs off. The client C i# upon receiving notification from HS(CJ in the manner described above, "pops up" a flash message on CJs screen, informing C of the new status of A.

Claims: What is claimed is: 1. A system for popup messaging across the Internet, the system comprising: a set of Home Servers associated with a plurality of individual users, to track the login status of users, and manage communication to and from the users; a Global Server that stores the associations between Home Servers and users, and stores profile information for users; client software that sends and receives communication to/from each of the users; a method for tracking the online status of users; and a method for asynchronously sending messages to users behind firewalls. 2. The messaging system of claim 1 wherein said Home Server routes a message from one of its users to another recipient by first determining the identity of the recipient's Home Server and then sending the message to that Home Server, which then forwards it on to the recipient . 3. The messaging system of claim I wherein said tracking of the online status of a user is accomplished by that user's Home Server, which detects the user's logging in and logging off, and informs the Home Server of each user that has this particular user on his/her contact list of the updated status of this user. 4. The messaging system of claim I wherein said asynchronous messaging through firewalls occurs through the Home Server's establishing a MIME-multipart connection to the user at the time of login, and sending subsequent messages to the user over this connection. 5. The method of claim 4 wherein said connection is kept active by the Home Server's sending a blank message to the user over said connection at regular intervals .

Inventors: AGGARWAL SUDHANSHU, BEEBEE PETER, KONIARIS KLEANTHES, SURATI RAJEEV, AGGARWAL, SUDHANSHU, BEEBEE, PETER, KONIARIS, KLEANTHES, SURATI, RAJEEV
Applicants: FLASH COMMUNICATIONS INC, FLASH COMMUNICATIONS, INC.
Application year: 1998
Main classification: G06F11
IPC codes: G06F11, G06Q10, H04L12, H04L29