The present invention relates generally to presence services for mobile devices and, more particularly, to a presence model for instant messaging between mobile users, or between mobile and fixed users.
Cellular networks were originally developed to provide primarily voice services over circuit-switched networks. Although circuit-switched networks are still in widespread use, the current trend is toward packet-switched networks that provide high speed packet data services in addition to voice services. The high-speed packet data services currently offered enable mobile users to surf the web, read e-mail, download video and audio files, and do other things that Internet users can do on fixed networks.
Consumer demand for mobile data services is growing rapidly. One of the services in greatest demand by mobile users is instant messaging (IM). Desktop IM over fixed network has gained widespread acceptance. Currently, there are more than 100 million registered users of instant messaging services and more than 50 million regular users. Based on the success and adoption rate of desktop instant messaging, wireless service providers are hoping to capitalize on the demand for IM services by extending the same services to mobile users.
Most of the presence models for IM evolved in the context of fixed networks and have been adapted to the usage patterns of PC users. One problem in extending IM services to mobile users is that existing presence models do not fit the usage patterns of mobile users. For instance, the status “away” is generally taken to mean that the user is away from the computer and consequently unavailable to engage in instant messaging conversations. In the mobile environment, the status “away” may not be very relevant since mobile users typically carry their devices with them. Similarly, the “on line” and “off line” statuses, which indicate the connection state of the user, may not accurately reflect the connection state of a mobile user due to the integration of instant messaging and presence services with other applications (e.g., presence enhanced phone book, threaded conversations in the message inbox, etc.). With this integration, the connection state of the user becomes more complex. The user is not always required to log in or log out of the instant messaging application. Instead, the mobile device may transparently log in during power up and log out during power down without any user intervention. Thus, the instant messaging and presence application may run in the background even when the mobile user is not actively engaged in instant messaging conversations. Thus, the “on line” and “off line” statuses may not accurately reflect the status of a mobile user.
Because the usage patterns of mobile and PC users are different, new presence models are needed for mobile users to more accurately reflect the status of mobile users.
The present invention provides a method and apparatus for maintaining presence information. In one exemplary embodiment, a presence server comprising a finite state machine and a mapper is provided. The finite state machine maintains current machine states for a plurality of users and outputs state updates indicative of the current machine states of said users responsive to state transitions. The mapper receives state updates from the state machine and maps said current machine states of said users to corresponding presence statuses. In a preferred embodiment, the machine state for each user is maintained by a separate dedicated instance of the finite state machine.
In one exemplary embodiment, the current states of the state machine include the “Available” state, the “Inactive” state, and the “Unavailable” state. The state machine is configured to enter the “Available” state when the corresponding user logs into the presence server. The state machine transitions from the “Available” state to the “Inactive” state when the user is inactive for a first predetermined period of time, and transitions from the “Inactive” state to the “Unavailable” state when the user is inactive for a second predetermined period of time. The state machine may further include an “Active” state. The state machine may be configured to enter the “Active” state when the corresponding user logs into the presence server in response to an invitation from another user. The state machine may also be configured to transition from the “Inactive” state or the “Available” state to the “Active” state responsive to the detection of user instant messaging activity, and to transition from the “Active” state to the “Available” state when the user is inactive for a third predetermined period of time.
In one embodiment, the state machine further generates message delivery rules responsive to state transitions. The message delivery rules include instant message rules for delivering instant messages and presence update rules to control presence updating behavior. The instant message rules may include an “online messaging” rule for directing an instant messaging application to use online messaging, an “offline messaging rule” for directing an instant messaging application to store instant messages for subsequent online delivery, and an alternative messaging rule for an instant messaging application to use an alternative delivery method (e.g., SMS) to deliver instant messages. The message delivery rules may further include presence update rules for reporting presence information. The presence update rules may include a “standard update” rule for configuring the presence server to provide presence updates at a default reporting frequency, a “reduced update” rule to configure the presence server to provide presence updates at a reporting frequency lower than the default reporting frequency, and a “no update” rule to configure the presence server to suspend presence updates.
The present invention provides a method and apparatus for implementing instant messaging and presence service (IMPS) to enable the exchange of instant messages between mobile users, or between mobile users and fixed users. The IMPS solution according to the present invention defines and implements a presence model specifically adapted for mobile users.
The mobile devices 100 have an IMPS client (not shown) for communicating with the IMPS server 200. The IMPS client is a software application that is executed on a processor and provides support for IMPS services to user applications, such as an instant messaging (IM) application or presence enhanced phone book. The users of the mobile devices 100 may register with the IMPS server 200 for instant messaging and presence services. A user can have one of three registrations states: registered, unregistered and pre-registered. The registrations states and events or conditions that cause transitions between registration states are shown in
Once registered, the mobile devices 100 can exchange instant messages, publish presence information, and subscribe to presence updates from other IMPS users. Presence information may, for example, reflect the current availability and/or willingness of the IMPS user to engage in an IM conversation. IMPS users may elect to make their presence status available to other IMPS users. IMPS users that provide presence information to other users are referred to as presentities. A user that wants to receive presence information from another user may subscribe to receive presence updates from the presentity of that user. An IMPS user that subscribes to receive presence updates from a presentity is referred to as a watcher. An IMPS user can be both a presentity and a watcher.
The IMPS server 200 maintains presence information for IMPS users and serves as an intermediary between presentities and watchers for publishing presence information. The IMPS server 200 implements a presence model described herein that is used to determine the presence states of presentities.
The service elements 204 include a presence service element 204A, an instant messaging service element 204B, a group service element 204C, and a content service element 204D. The presence service element 204A implements the presence model described herein and provides functionality for presence services. The instant messaging service element 204B provides functionality for sending and receiving instant messages between IMPS users. The group service element 204C provides functionality for defining and managing groups for IMPS users. The content service element 204D provides functionality for sharing content, such as images and documents between IMPS users. The IMPS server preferably complies with the Open Mobile Alliance (OMA) standard IMPS Architecture (OMS-AD-IMPS-V1—3-20051011-C), which is incorporated herein by reference.
The machine states 212 are defined by the presence model at a functional level without inferring them from presence statuses defined at the technology enabler level. At any given instant in time, the current state of the user is represented by one machine state 212. When a predetermined event occurs, or a predetermined condition is satisfied, the state machine 210 transitions between machine states 212. In response to a state transition, the state machine 210 outputs the current machine state 212 to the mapper 220. This output is referred to herein as a state update. The mapper 220, in turn, maps the current machine state 212 to a corresponding presence status.
Table 1 below lists eight machine states 212 for one exemplary embodiment of the invention. The list of machine states 212 is illustrative only and those skilled in the art will recognize that additional machine states 212 may be defined. Each machine state corresponds to only one registration state. A registration, however, may have a plurality of corresponding machine states 212. Thus, the relationship between registration states and machine states 212 is one-to-many. The machine states 212 and corresponding registration states are shown in
The finite state machine 210 for a given user transitions between machine states 212 when certain events occur, or when certain conditions are satisfied. Some events may be the result of intentional user action, such as launching an application, and logging into or out of the IMPS server. Other events may occur without user awareness. For example, the user may move into or out of coverage, or the mobile device may transparently log into or log out of the IMPS server 200 without user intervention. In a preferred embodiment of the invention, users may also have an option to declare their presence status. For example, the IM application on a mobile device 100 may have an option allowing users to make themselves “invisible’ so that they appear to be offline. As another example, a user may invoke a “do-not-disturb” function that makes the user appear “busy” to other users.
Table 2 below lists a number of events that can trigger a state transition in one exemplary embodiment. The list is intended to be illustrative and other events and other transitions may be defined.
The event list shown in Table 2 assumes two types of IMPS clients, referred to herein as manual clients and background clients. With a manual client, the user must manually launch an instant messaging application in order to access to the IMPS server 200. For example, a JAVA client that is not automatically launched at power up is a manual client. In contrast, a background client is one that automatically launches and logs into the IMPS server 200 at device power up and automatically logs out and shuts down at power down. A background client is persistent and runs in the background even when the user is not engaged in an instant messaging conversation. For example, many mobile devices include a presence enhanced phone book. In this case, the IMPS client runs in the background to provide presence updates to the phone book even when the user is not engaged in an instant message conversation.
The output of the finite state machine 210 comprises state updates and message delivery rules. When the finite state machine 210 transitions between machine states 212, the finite state machine 210 outputs a state update to the mapper 220 reflecting the current machine state of the user. Because there is not a one-to-one correspondence between machine states 212 and presence statuses, the mapper 220 performs a consolidation in which multiple machine states 212 are mapped into a single presence status. The consolidation rules can be applied system wide, or, more preferably, may be dependent on specific user categories. The output of the mapper 220 is the current presence status of the user.
The message delivery rules are a second form of output from the state machine 210. The message delivery rules specify how and whether instant messages and/or presence updates are delivered. When the finite state machine 210 transitions between states, a message delivery rule for instant messages, referred to herein as an instant message rule, may be output to the instant messaging service element 204B. Presence update rules are also defined to determine when the presence service element 204A delivers presence updates. Table 3 lists message delivery rules and their corresponding states.
Some standardization bodies have already defined a set of presence statuses to be supported by IM clients or to be conveyed over interconnect interfaces. For example, the GSM Association (GSMA) standard IM SPT Phase 1 recommends the following presence statuses: on-line, on-line but unavailable, and off-line. The OMA standard for IMPS (OMA-IMPS-WV-PA-V1—2-20050125-A) defines two relevant presence attributes: OnlineStatus and UserAvailability. The OnlineStatus attribute is a Boolean value that indicates whether the user is currently online. The OnlineStatus attribute takes the following values:
The mapper 220 can accommodate different presence statuses defined by different standardization bodies. Such flexibility may be necessary because some IMPS clients may be limited to a defined set of presence statuses. For example, the IM client for a user or mobile operator providing service may support only the GSMA presence statuses. Table 4 illustrates one possible mapping of machine states into presence statuses/attributes for GSMA and OMA IMPS.
It has been assumed that the events and transitions are predefined and static. Increasing the number of conditions and/or system events can increase significantly the complexity of the state machine 210. Rather than defining statically the events and conditions when transitions shall occur between machine states 212, the state machine 210 could include logic to learn user behaviors and to adapt transitions between states accordingly. For example, the state machine 210 could implement a neural network to learn user behaviors. To illustrate the learning process, consider the scenario in which User A goes to a recurrent meeting every Monday morning. The state machine 210 logic initially provides that if the user is having a meeting (according to user's agenda in the phone), the user should be shown as unlikely to respond. However, during Monday morning meetings, User A typically responds to instant messages. The state machine 210 dynamically learns this behavior and, as a consequence, changes its internal logic so that during Monday morning meetings, the status of User A is shown as ‘likely to respond’. Now assume that User A has another recurrent meeting on Tuesday mornings. However, during this meeting, User A never responds to instant messages. The system also dynamically learns this behavior and adapts the presence status shown to others.
The present invention may, of course, be carried out in other specific ways than those herein set forth without departing from the scope and essential characteristics of the invention. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.
This application claims the benefit of U.S. Provisional Patent Application 60/867,862, filed Nov. 30, 2006, which is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
60867862 | Nov 2006 | US |