Personal presentity presence subsystem

A personal presentity presence service provides support for heterogeneous presentities. Presentity types including personal presentities are registered with a presentity manifest store that includes information such as type names, addresses of applications associated with actions related to the presentity type, application parameters, icons for watcher application, and the like. Personal presentity service identifies the personal presentity types associated with the user and automatically organizes these into a personal presence group for management and presentation purposes. Users (watchers) can then register for different groups of personal presentities, which are devices and systems personally associated with the user, based on a type of presentity and receive updated presence information.

RELATED APPLICATIONS

The present application may be found to be related to U.S. patent application entitled: “DYNAMICALLY CONFIGURABLE PRESENCE SERVICE”, Ser. No. 11/525,008, filed with the USPTO on the same day as this patent application.

TECHNICAL FIELD

Embodiments are related to presence services. More particularly, the disclosed subject matter is related to computer-implemented methods, configurations, systems, and computer program products for facilitating support for dynamic grouping and presentation of personally associated presentity types based on their type.

BACKGROUND

Today's presence standards, models, and presence service implementations typically do not address dynamic categorization of presentities into presentity groups. Many presence applications allow users to manually group presentities into buddy lists such as “my family”, “my fellow gamers”, “my colleagues”, and the like. This may be due to presence services typically assuming a homogeneous presentity population, addressing only one type of presentity, usually persons.

On the other hand, computer technology has evolved sufficiently such that “smart” technology is available in many homes today. From appliances to monitoring systems, many devices are capable of performing multiple tasks, interact with users, and communicated over various types of networks.

SUMMARY

Consistent with embodiments described herein, systems and methods are disclosed for providing support for dynamic categorization and presentation of personally associated presentities based on presentity type(s). Key features or essential features of the claimed subject matter are not necessarily identified in this summary portion.

A presence service is arranged to register and maintain updated information on different presentity types. Embodiments are directed to a personal presence subsystem that is capable of dynamically grouping these different presentities for presentation and management purposes based on their presentity type. In particular, the subsystem can identify and group devices and systems personally associated with a user into a “Personal Presentity” group. “Personal Presentity” types may include devices such as monitoring and entry systems that are typically associated with one individual. Presence applications may be provided presentity type information such that they can subscribe to monitor presence information and associated presentities with groups for presentation and management purposes.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only, and should not be considered restrictive of the scope of the invention, as described and claimed. Further, features and/or variations may be provided in addition to those set forth herein. For example, embodiments of the invention may be directed to various combinations and sub-combinations of the features described in the detailed description.

DETAILED DESCRIPTION

FIG. 1and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. With reference toFIG. 1, a conceptual diagram of a presence service architecture100, where example embodiments may be implemented, is shown. A presence system allows users to subscribe to each other and be notified of changes in state and, typically, for users to exchange a communication with each other. A presence service has two distinct sets of “clients”. One set of clients, called “presentities”, provides presence information to be stored and distributed. The other set of clients, called “watchers”, receives presence information from the service.

Architecture100includes at a base level watcher applications120and presentities130that connect to the backbone of the presence system through IP network112or other network(s)114of the connectivity and access layer110. Watcher applications120provide an interface for watcher(s)122. There are two kinds of watchers, called “fetchers”124and “subscribers”128. Fetcher124simply requests the current value of some presentity's presence information from the presence server102. In contrast, subscriber128may request notification from the presence server102about changes in a presentity's presence information including future changes. A special kind of fetcher124is one that fetches information on a regular basis. This is called a “poller”126.

In a conventional presence system, watcher applications120may be executed on computing devices such as cellular phones, Personal Digital Assistants (PDAs), and the like, providing watcher(s)122information about the presentities130that are typically associated with a particular watcher122. In a typical presence system scenario, the presentities130may include people in a phone subscriber's “buddy list” with the system providing information about location or contact information of the people on the buddy list to the subscriber and enabling the subscriber to contact the presentities130through various means. Thus, the presentities130in a typical presence system are homogeneous (all persons). Furthermore, the presence services generally operate by registering the presentities130along with their attributes requiring a reconfiguration of the buddy list when a new presentity is added or one removed.

According to some embodiments, presentities130may include different types of personal presentities130such as interface devices (and applications) that may provide a service to the watcher122. For example, a personal presentity130may include a monitoring or entry system configured to provide triggering event(s) to the watcher122and facilitate actions in response to the triggering event(s) and the watcher's selection.

Connectivity and access layer110includes network infrastructure that is used to provide interconnection between presentity/watcher applications and presence applications at application layer105of the system. Connectivity layer110may include IP network112and other network114or a combination of networks. These network(s)112and/or114may include a secure network such as a home network or an enterprise network, or an unsecure network such as a wireless open network. The networks112and/or114provide communication between the applications described above. By way of example, and not limitation, the networks112and/or114may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

Presence services may be a service component deployed within an IP Multimedia System (IMS) framework. Control and session layer108is arranged to facilitate communication sessions between the physical devices and the applications, as well as between the applications and any network resources such as data stores of the IMS framework. IMS is an open-systems architecture that supports a range of IP-based services over both packet switch and circuit switch networks, employing both wireless and fixed access technologies.

IMS provides services and control such as adding call session control to the packet network, enabling peer-to-peer real-time services such as voice or video over a packet-switched domain, and scalable common service control (based on SIP) for giving the ability to manage parallel user services. In a mixed multimedia environment, IMS may provide the ability to pick and mix various multimedia flows in single or multiple sessions and can handle real-time voice, video, and data. IMS also provides access to IP based services independent of the underlying access technology (mobile or fixed). IMS applications and drivers may include voice telephony (VoIP), video telephony, web browsing, presence-based services, push-to media services (e.g. push-to-talk, push-to-view, push-to-video, etc.), group chat, instant messaging, multimedia conferencing, content sharing/data transfer, and the like.

Control and session layer108within an IMS framework may include components such as proxy-call state control function (“P-CSCF”), which is typically a first point of contact and may provide privacy control, quality of service (“QoS”), authorization of local services, and similar functionalities. P-CSCF may interacts through SIP with interrogating-call state control function (“I-CSCF”), which may provide an access point functionality to the network and enable protection of a topology and configuration of the network. I-CSCF may interact through SIP with serving-call state control function (“S-CSCF”), which provides session control services such as registration, accounting, and the like. Both I-CSCF and S-CSCF may interact with a home subscriber service (“HSS”), which can be used as a data store service for storing presence information, e.g. where the user can be reached. An IMS architecture may include additional components such as a subscriber locating function, a trunking signaling gateway, a media resource function controller, and the like. Furthermore, control and session layer108may also be embodied within a framework other than IMS.

At an application layer105of architecture100are presence server102, presence list server104, and presentity store106. The application layer105may also include one or more applications associated with providing additional services to the watchers122integrated with the unified presence service.

Presence server102is arranged to coordinate exchange of information between the presentities130and watchers122, as well as different data stores of the system. For example, presence server102may receive information associated with a location of a watcher122and notify the watcher122through an application (or device) based on the watcher's location about status of the watcher's registered presentities130. Presence list server104may maintain a list of the presentities130associated with each watcher122and update presentity store106, where information about the presentities130and their attributes are stored.

According to some embodiments, watcher application120may provide one or more user interfaces (“UIs”) to enable the watchers122and the presentities130to receive and provide information, such as VoIP communications, action selections, alphanumeric entries, and the like.

Interface devices executing watcher122and presentity130applications as well as servers of the application layer105may include or may be part of a computing device. Such a computing device may include, but is not limited to, a handheld computer, a Personal Digital Assistant (PDA), a TV, an MP3 player, a smart remote control device, and the like. Computing devices typically include a processing device and a system memory. Computing devices may also include additional processing devices, which may be dedicated processors or enable distributed processing by coordinating with a main processing device. The system memory may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. System memory typically provides an environment for an operating system to be executed for controlling the operation of the computing device and execution of other programs (applications). The watcher application120, a subscriber location application, two-way communication applications, imaging or video communication applications are examples of programs or program modules that may be executed in the system memory. These applications may be an integrated part of a single program or separate applications. They may communicate with other applications running on the computing device or on other devices.

The computing devices may have additional features or functionality. For example, the computing devices may also include data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The system memory and storage devices are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computing device. Any such computer storage media may be part of the computing device.

Computing devices may also include input devices such as a keyboard, a keypad, a voice input device, a touch input device, a camera etc. Furthermore, output devices such as a display, a speaker, a printer, etc. may also be included. These devices are well known in the art.

Communication connections may be included in the computing devices to allow the device to communicate with other computing devices executing above described applications, such as over a network in a distributed computing environment, for example, an intranet or the Internet. Communication connections may include media that may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and include any information delivery media.

By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein refers to both storage media and communication media. The implementation of embodiments for interface devices and servers of a personal presentity presence subsystem is not limited to the computing devices described above. Other computing devices with different components, configurations, and the like, may be used to execute computer readable instructions implementing embodiments described herein without departing from a scope and spirit of the disclosed subject matter.

FIG. 2illustrates main components of an example personal presentity presence subsystem200. According to some embodiments, a personal presentity presence subsystem200may provide for real time configurability of a presence service to dynamically determine and configure the actions that can be taken when a presence notification has been received. In particular, certain presentities130are identified as “personal presentities” and are automatically grouped into a personal presentity group. According to other embodiments, the system may support different types (heterogeneous) of presentities130which may have different associated service actions.

The support for heterogeneous presentities130with different associated service actions may be accomplished by employing a presentity manifest. For each presentity a presentity manifest including a type of the presentity, a list of associated actions, a presentity group information, and a list of authorized watchers122may be stored and maintained by the presence server102. Furthermore, the list of associated actions may include for each action a network address of an application or system to connect to, one or more parameters for the application or system associated with the action, and presentation information (e.g. icons to be used in a UI for the action).

In an operation, presence application232may monitor presence of presentities such as presentity130and update presence server102with the status of monitored presentities130. Presence application232may also register any new presentity type with presentity service management component234. Moreover, presence application232may optionally register presentities130with directory service236.

Presence service management component234may register any applications associated with presentities130with presence server102as well as register any new presentities130with directory service236. According to some embodiments, presence service management component234may store new presentity types and manifests of the presentities130with presentity manifest store240.

Watcher application120may be dynamically reconfigured based on the presentity manifests in presentity manifest store240. For example, profiles, associated actions, and icons for each presentity130displayed on a watcher application UI may be updated when the presentity manifest is modified in presentity manifest store240. Watcher application120also subscribes to selected presentities130with the presence server102and receives updates on presence information (e.g. location, status of a presentity). Watcher application120may receive the updates from presence server102, directly from presentity store106, or from presentity group management component238.

Presentity group management component238is configured to categorize presentities based on their types and manage the groups in coordination with presence server102. In addition, directory service236may optionally coordinate operations of presentity group management component238as well.

Presence server102, in coordination with directory service236, manages presentity store106where status information associated with registered presentities130is stored. Essentially, presence server102enforces rules of the service provider on categorizing presentities, while watcher application120enforces client (user) rules. As mentioned above, the interactions between the components of the personal presentity presence subsystem may be facilitated within an IMS framework using SIP sessions. A basic example scenario is provided below for illustration purposes.

According to the example scenario, a presence service may support two types of personal presentities130: a monitoring system interface device (car alarm equipped with a camera) and entry system interface devices (doorbells equipped with visual and audio communication devices). The presentities130are personal presentity, because they are personally associated with the user. They are not a generic resource that may be shared by subscribers of a presence service. Each type of personal presentity has different actions associated with it such as “take picture” for car alarm, and “audio call” or “video call” for the doorbell. Thus, each type of personal presentity has different applications that need to be activated to perform the associated action(s). When the personal presentities are added to the system, their manifests includes their types (e.g. car alarm, doorbell), which identifies them as personal presentity types. The network addresses of the associated applications (e.g. IP addresses for client image acquisition application, VoIP call client, video conference client, and the like), any parameters associated with the applications, and icons for the actions may also be stored in presentity manifest store240.

Under each type, there may be numerous presentities130(e.g. three separate car alarms, front and back doorbells, etc.). Each presentity130within a group (type) may have differing configurations, but their essential structure is similar enough to group them together. For example, the front doorbell presence hardware may include a display for video communication, but the back doorbell presence hardware may lack the display. Presence server102in coordination with presentity group management238may categorize added personal presentities once they are registered with the presence server102by presence application232. When the presentity manifest store240is updated, watcher application120may be dynamically updated to reflect the latest configuration for different presentity types.

Watcher application120then receives updates on the personal presentities from the presence server102. In response to the received updates, watcher application120may select an associated action (e.g. initiate an audio call with a person at the door in response to the doorbell being rung). Presence server102in coordination with presence application232may then manage activation of the appropriate client application and facilitate the execution of the action.

The architecture and scenarios described inFIG. 1andFIG. 2are for illustration purposes only and do not constitute a limitation on embodiments. Other configurations of a personal presentity presence subsystem may be implemented without departing from a scope and spirit of the present invention.

FIG. 3illustrates action flows in the example personal presentity presence subsystem ofFIG. 2. The interactions are between components the doorbell presence service described above in detail.

The action flow begins with action301, where presence application232performs an initial registration of a personal presentity type that includes the manifest information discussed above in conjunction withFIG. 2. The presence application232registers the personal presentity type with presence service management component234. Presence application232then stores the manifest information with presentity manifest store240in action302. Actions303and304are respective responses of presentity manifest store240and presence service management component234that registration is complete. Upon receiving the registration complete message, presence application232registers a personal presentity with presence service management component234in action305. In response, presence service management component234registers the personal presentity with directory service236in action306. Following that, directory service236registers the personal presentity with presentity store106in action307and receives a registration complete message in action308. The involvement of the directory service236is optional according to some embodiments. The registration complete message is forwarded to presence service management component234in action309and from there to presence application232in action310.

In the meantime, watcher application120retrieves personal presentities or other classes of presentities130from presentity store106in actions311. Watcher application120then subscribes to presentities130by type with presence server102in action312. Following the subscription, watcher application120retrieves the manifest(s) for the subscribed presentities130from presentity manifest store240in actions313. The retrieval of the updated manifests results in dynamic reconfiguration of the watcher application120in action314, which may include updating one or more UIs, application parameters, links, and the like.

According to some embodiments, watcher application120may request subscription to a buddy list with group management subsystem238in action315. Upon receiving this request, group management subsystem238may subscribe the watcher application120to personal presentities in the requested buddy list in action316. This may result in a dynamic reconfiguration of the watcher application120based on the types of presentities130in the buddy list in action317. The term “buddy list” is used herein in a generic sense to describe a group within a particular type of presentities130. For example, a user may be authorizes to car alarms for a fleet of automobiles including personal vehicles and vehicles of his organization. The user may then define a “buddy list” of his/her personal cars within the car alarm type of presentities130.

In action318, presentity130provides presence application232with presence information. This may include information such as a doorbell ringing status, a car alarm status, availability of a person for phone call, and the like. The presence application232updates presence server102with the information from the personal presentity in action319. Presence server102then updates watcher application120in action320. Operations associated with personal presentities are not limited to those described above. Additional actions may be included within the actions described here or after the last action. For example, the user may select an action associated with the received presence information. The selection may then be forwarded to presence application, which may activate one or more applications to execute the user selected action.

FIG. 4illustrates a diagram of a personal presentity presence service with personal presentities130and a watcher122. Presence server102and presentity store106are as described inFIG. 1. Presence application232manages associated personal presentities130and facilitates execution of a user selected action in response to provided presence information. Presence server102, presentity store106, and presence application232communicate with each other, with watcher application120, and with presentities130through presence network452. As discussed previously, presence network452may include an SIP session IMS infrastructure, wired or wireless networks, and the like.

Presentities130may include a number of personal presentities associated with watcher122personally. Examples of personal presentities130represented in the diagram are doorbell presence hardware432, monitoring system434, and car alarm436. Any other type of device or system that is personally associated with watcher122and can provide presence information to the watcher122may be a personal presentity130. In a conventional presence system, presentities130may be persons. Thus presentation of presentities130in watcher application120may be accordingly. For example, watcher application120may provide choices to the watcher to establish a phone call, a video call, or display a location of the presentity person.

On the other hand, presentation of personal presentities130may be associated with significantly different choices for the watcher122. The selection of actions in response to presence information may typically depend on capabilities and features of a specific personal presentity. For example, a monitoring system may be set up to monitor several equipment and processes. Thus, personal presentities within the group of monitoring presentities may have different features depending on what is being monitored. A test equipment monitoring device may provide results of tests, duration of tests, and the like. Associated actions may include recording the readings, resetting the test equipment, modifying parameters of the test equipment, and the like. In another example, the personal presentity may include a weather monitoring device that provides automatic updates on weather conditions such as temperature, humidity, precipitation, and the like. Upon registering the type of presentity130and subscribing the watcher to it, the presence server102may reconfigure the watcher application120(or the watcher application can automatically reconfigure itself) to present a selection of actions associated with the weather monitoring presentity. The actions may include resetting modules of the presentity130, changing recording parameters, and the like.

According to some embodiments, users may override or regroup personal presentities identified by the system into customizable groups for presentation and/or management purposes. In the other words, the system may identify personal presentities and place them into the user's personal presentity group or into subgroups like “office”, “home”, and the like.

FIG. 5illustrates a logic flow diagram for a process500of providing personal presentity presence service according to one embodiment. Process500may be implemented in presence server102.

Process500begins with operation502, where presence service management component234registers a personal presentity type in response to receiving a request for registering the presentity type from presence application232. The registration may include storing information associated with the presentity type such as name of the type, addresses of applications associated with related actions, icons to be presented in a watcher application UI for the presentity type, and the like. Processing moves from operation502to operation504. Presence service management component234may register the information with presentity manifest store240.

At operation504, the presence service management component234registers a presentity130of a registered type with presentity store106in response to a request to register a new presentity130from the presence application232. Processing moves from operation504to operation506.

At operation506, presentity store106provides a list of available presentities and groups of categorized presentities to watcher application120. According to some embodiments, presence application232may filter the list based on an authorization attribute associated with each presentity130. For example, personal presentities may be made available only to users associated with those personal presentities. Watcher application120may then provide a request for subscription to selected presentities130. Processing moves from operation506to operation508.

At operation508, the presence service management component234subscribes the watcher application120with the requested personal presentities in presentity store106and confirms the subscription to the requesting watcher application120. Processing moves from operation508to operation510.

At operation510, presentity manifest store240provides the manifests of the personal presentities in the list of subscribed presentities to the watcher application120. Upon receiving the manifests of the personal presentities, the watcher application120may be dynamically configured based on the types of presentities130in the subscribed list. Processing moves from operation510to optional operation512.

At optional operation512, the presence service management component234subscribes the watcher application120with one or more requested buddy lists comprising a plurality of personal presentities and confirms the subscription to the requesting watcher application120. Processing moves from optional operation512to optional operation514.

At optional operation514, presentity manifest store240provides the manifests of the personal presentities in the subscribed buddy list to the watcher application120. Upon receiving the manifests of the personal presentities in the buddy list, the watcher application120may be dynamically reconfigured based on the types of presentities130in the subscribed buddy list. Processing moves from optional operation514to operation516.

At optional operation516, presence server102provides updates received from various presentities130to presence application232, which in turn provides them to watcher application120. The updates may include presence information such as location or availability of a presentity130, a trigger event associated with the presentity130, and the like. Processing moves from operation516to operation518.

At operation518, presence application232facilitates an action selected by the watcher122in response to the updated presence information. Facilitating the action may include, as described previously, activating one or more client applications that perform tasks such as establishing communications, activating controls, and the like. After operation518, processing moves to a calling process for further actions.

The operations included in process500are for illustration purposes. Providing personal presentity presence service may be implemented by similar processes with fewer or additional steps, as well as in different order of operations using the principles described herein.