System and method for a user interface directed to discovering and publishing presence information on a network

SYSTEM AND METHOD FOR A USER INTERFACE DIRECTED TO DISCOVERING AND PUBLISHING PRESENCE INFORMATION ON A NETWORK

The concept of existence has increasingly come to the fore in networking and real-time communication of applications. Presence often refers to the ability to detect whether a user is online and available. An example of an application that uses presence information is an IM (Instant Messenger) program. An IM program provides a user with a way to send instant messages to other IM users via the Internet or a network. IM is a kind of communication service that allows a user to establish a kind of dedicated chat room with another person to communicate in real time over the Internet. IM is similar to phone calls, but uses text-based communication rather than voice-based communication. Typically, instant messaging systems alert a user whenever someone on a user-only list is online. The user can then initiate a chat session with that particular person.

However, presence for IM and other similar applications has been limited to presence information that is directly related to a contact already established by the user. The presence of other users outside the user's enumerated contacts could not be obtained. Other applications for discovering which devices are present on the network have been allowed, but not for users. Presented presence information was displayed by cumbersome or highly conspicuous user interfaces. For example, from the user's point of view, in order to display presence information, an IM application must be opened and executed.

<Summary of the invention>

The present invention relates generally to providing a system and method for a user interface directed to publish and discover presence information for users on a network. The user interface provides peripheral and unobtrusive notification of the disclosure of a local user on the network, while providing for the presence of nearby users on the network. The present invention utilizes a sidebar that is presented on the local user's desktop, containing various tiles. The various tiles provide different functionality as selected by the local user. For the purposes of the present invention, the presence information is provided as one of the tiles in the sidebar. Thus, presence information is provided locally to other applications running on the local user's computing device. When a user enables a sidebar tile, presence information is provided and updated so that it can be continuously viewed by the user. However, this information is provided so that updates do not go unnoticed by local users as they work on their computing devices. For example, the sidebar tile may simply include the number of adjacent users. This number is updated as people enter and leave the network. Accordingly, in a state in which the presence information is not forcibly pushed to the local user, the local user may notice a change in the provided presence information.

In addition, the sidebar tile provides choices for changing aspects of the presence discovery service. A local user can enable or disable the presence discovery service from the sidebar tile, or even choose to disable the sidebar tile itself.

According to one aspect of the present invention, a computer implemented method for a user interface directed to discover and publish presence information on a network is provided. The method determines whether a local user is present on a network and whether an adjacent user is present on the network. A portion of the user interface is illustrated for local and inconspicuous notifications of the presence of a local user and the presence of a nearby user on the network. The presence of the local user and the presence of the adjacent user are then displayed in a portion of the user interface when it is determined that the local user is present on the network.

1 illustrates an exemplary computing device that may be used in accordance with embodiments of the present invention.

Figure 2 actually illustrates another operating environment for a mobile device for use with the present invention.

3 shows an exemplary sidebar within the desktop.

4 shows a functional block diagram of a system for discovery and publication of adjacent presence information on a network.

5 shows another functional block diagram of a system for discovery and publication of adjacent presence information on a network.

6 shows exemplary file structures corresponding to a file system for storing existence information.

7 illustrates example sidebar tiles related to disclosure and discovery of the presence of nearby users on a network.

8 depicts an exemplary state diagram for implementing a user interface for publishing and discovering presence information on a network.

9 illustrates an exemplary identification information check for a presence notification of a nearby user, in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings, which form a part of and show, by way of example, specific embodiments for carrying out the present invention. However, since the present invention may be embodied in many other forms, it should not be construed as limited to the embodiments set forth herein, but rather these embodiments will provide a thorough and complete service to those skilled in the art. In order to fully convey the scope of the present invention to Among other things, the present invention may be embodied as methods or apparatuses. Accordingly, the present invention may take the form of an overall hardware embodiment, an overall software embodiment, or an embodiment combining software and hardware aspects. Accordingly, the following detailed description is not meant to be limiting.

<u>Exemplary operating environment</u>

Referring to FIG. 1 , one exemplary system for implementing the present invention includes a computing device, such as computing device 100 . Computing device 100 may be configured as a client, server, mobile device, or any other computing device that provides for discovery and disclosure of presence information. In a very basic configuration, computing device 100 typically includes one or more processing units 102 and system memory 104 . Depending on the exact configuration and type of computing device, system memory 104 may be volatile (such as RAM), nonvolatile (such as ROM, flash memory, etc.), or some combination of both. System memory 104 may typically include an operating system 105 , one or more applications 106 , and program data 107 . In one embodiment, the application 106 may include a people near me application (PNM) 120 . This basic configuration is illustrated in FIG. 1 by the components within dashed line 108 .

Computing device 100 may have additional features or functionality. For example, computing device 100 may include additional data storage devices (removable and/or non-removable), such as magnetic disks, optical disks, or tape. With a removable storage device 109 and a non-removable storage device 110 , this additional storage device is illustrated in FIG. 1 . Computer storage media includes 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. may include System memory 104 , removable storage 109 , and non-removable storage 110 are all examples of computer storage media. Computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. , or any other medium that can be used to store certain information and that can be accessed by the computing device 100 . Any such computer storage media may be part of apparatus 100 . Computing device 100 may also have input device(s) 112 , such as a keyboard, mouse, pen, voice input device, touch input device, and the like. Output device(s) 114 may also be included, such as displays, speakers, printers, and the like.

Computing device 100 may also include communication connections 116 that enable the device to communicate with other computing devices 118 over a network or the like. Communication connection 116 is an example of a communication medium. Communication media is typically 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 includes any information delivery media. The term "modulated data signal" means a signal that has one or more of a set of characteristics about it or has been altered in such a way as to encode information into the signal. By way of example, and not limitation, communication media includes 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 includes both storage media and communication media.

Figure 2, in effect, illustrates another operating environment for a mobile device for use with the present invention. In one embodiment of the present invention, mobile device 200 is integrated as a computing device, such as an integrated PDA and wireless telephone.

In this embodiment, the mobile device 200 has a processor 260 , a memory 262 , a display 228 , and a keypad 232 . Memory 262 generally includes both volatile memory (eg, RAM) and non-volatile memory (eg, ROM, flash memory, etc.). Mobile device 200 includes an operating system 264 resident in memory 262 and executing on processor 260 . The keypad 232 may be a numeric dial pad of push buttons (such as in a conventional telephone) or a multi-key keyboard (such as a conventional keyboard), or may not be included in the mobile device in the case of a touch screen or stylus. . Display 228 may be a liquid crystal display or any other type of display commonly used in mobile computing devices. Display 228 may be tactile and, if so, may act as an input device.

One or more application programs 266 are loaded into memory 262 and executed on operating system 264 . Examples of application programs include phone dialer programs, e-mail programs, scheduling programs, personal information management (PIM) programs, word processing programs, spreadsheet programs, Internet browser programs, and the like. In one embodiment, application programs 266 include a people near me (PNM) application 280 . Mobile device 200 also includes non-volatile storage 268 within memory 262 . The non-volatile storage device 268 may be used to store persistent information that should not be lost even if the mobile device 200 is powered down. Applications 266 include e-mail or other messages used by an e-mail application, contact information used by PIM, appointment information used by a scheduling program, and word processing application used by a word processing application. Information, such as documents to be stored, may be used and stored in storage device 268 . A synchronization application may reside on the mobile device and is programmed to interact with a corresponding synchronization application resident on the host computer to synchronize the corresponding information stored on the host computer with information stored on the storage device 268 .

The mobile device 200 has a power source 270 that may be implemented with one or more batteries. Power source 270 may additionally include an external power source, such as an AC adapter or a powered docking cradle that replenishes or charges the batteries.

Mobile device 200 is also shown having two types of external notification mechanisms: LED 240 and audio interface 274 . These devices, when activated, may be coupled directly to power source 270 such that, although processor 260 and other components are shut down to conserve power, they remain on for the duration dictated by the notification mechanism. LED 240 may be programmed to remain on until a user takes action to indicate the power-on state of the device. Audio interface 274 is used to provide audible signals to and receive audible signals from the user. For example, the audio interface 274 may be coupled to a speaker to provide an audible output and a microphone to receive an audible input, to facilitate phone calls and the like.

Also, the mobile device 200 may include a radio 272 that performs a transmission/reception function of radio frequency communication. The radio 272 facilitates a wireless connection between the mobile device 200 and the outside world, via a communication carrier or service provider. Transmission to and from the radio 272 is performed under the control of the operating system 264 . In other words, communication received by radio 272 may be disseminated to application programs 266 via operating system 264 , and vice versa.

The radio 272 allows the mobile device 200 to communicate with other computing devices over a network or the like. Radio 272 is an example of a communication medium. Communication media is typically 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 includes any information delivery media. The term "modulated data signal" means a signal that has one or more of a set of characteristics about it or has been altered in such a way as to encode information into the signal. By way of example, and not limitation, communication media includes 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 includes both storage media and communication media.

<u>Exemplary Existential Discovery and Disclosure System</u>

SUMMARY OF THE INVENTION The present invention generally provides a system for a user interface that is directed to discovering the presence information of a user and nearby people, as well as disclosing the user's presence to nearby people. As used herein, the term "proximity" refers to people who are connected within a network or physical proximity to a user. For example, people whose devices are connected within the same LAN may be considered "adjacent" to each other. Also, people whose devices are connected to the same network may be considered "adjacent" to each other. In addition, users residing on a link-local network may also be considered "adjacent". Alternatively, an indication of a physical location may be included in the presence information, such that people in the same room are considered "adjacent". The use of "adjacent" in this application is not limited to a single level of proximity, nor does it require direct access between the user and persons designated as "adjacent". "Neighborhood" may refer to any relationship between users based on a physical location or network location with respect to that person or device associated with them (eg, computing device, mobile device, etc.).

3 shows an exemplary sidebar within the desktop, in accordance with the present invention. The sidebar 310 of the desktop 300 includes tiles (eg, 320 ) that provide various information to the user during a computing session. For example, tiles in sidebar 310 may include media information, e-mail notifications, schedule notifications, as well as other information. Each tile may contain icons and other content that distinguishes the tiles from each other. In addition, according to the present invention, a people near me (PNM) sidebar tile 330 that provides presence information to the user locally and inconspicuously is also included.

The exemplary PNM sidebar tile 330 includes a presence indicator 332 published by the user, a notification 334 of the presence of other users, and a selection 336 to view more detailed presence information. In this example, indicator 332 provides an alias selected by the user, which is disclosed to other users of the network. Notification 334 provides a dynamically updated number of users considered nearby to the current user (eg, 23 users are nearby). Selection 336 provides a link to more detailed information regarding the presence of other users on the network. For example, if the user selects selection 336 , window 340 is opened to provide detailed information to the user.

Window 340 provides the user with more detailed information about nearby users on the network. In one embodiment, the information in window 340 includes presence information along with contact information provided by a contacts application associated with the computing device. For example, the detailed information of the window 340 may include a distinction between a contact that is offline and a contact that is online. Other details of users and contacts residing on the network may also be provided via window 340 . In one embodiment, window 340 is a "flyout" or window that is a component of a sidebar tile. In another embodiment, window 340 is created by the contact application and the PNM information is provided to the contact application for inclusion in the contact UI.

4 shows a functional block diagram of a system for discovery and publication of neighbor presence information on a network, in accordance with the present invention. The system 400 includes a PNM sidebar tile 410 (see FIG. 3 ), a rover 420 , a simple service discovery protocol (SSDP) layer 430 , a file system 440 , and a networking layer 450 . include The rover 420 includes a PNM component 422 .

The PNM sidebar tile 410 is a user interface that provides the user with local, inconspicuous notifications about people deemed close to the user. The PNM sidebar tile 410 is further elaborated in connection with the discussions of FIGS. 7 and 8 that follow.

The SSDP layer 430 provides a protocol for discovering and publishing presence information on a network. The SSDP layer 430 is regarded as a subset protocol of a universal plug and play (UPnP) protocol for connection of devices on a network. UPnP builds on existing protocols and technologies. For example, UPnP basically uses TCP/IP, UDP/IP, and HTTP protocols. In addition to these basic protocols, several other protocols are built upon them to implement the various stages and topologies of UPnP networking, such as SSDP. The types of PNM messages transmitted and received according to the SSDP layer 430 are further elaborated with reference to FIG. 5 below.

File system 440 provides an extensible storage location for information regarding the presence of users and people close to them. In one embodiment, file system 440 is a WinFS file system created by Microsoft Corporation of Redmond, Washington. File system 440 is arranged such that PNM information is presented through one or more user interfaces (UIs) and links PNM information to other databases for use in other databases. For example, the file system 440 may include a contact folder in which user contacts are stored. The PNM information may be used to indicate to the user which of the enumerated contacts are considered proximate to the user. Other relationships between PNM information and other data may be established to provide for the distribution and use of PNM information across multiple applications.

The networking layer 450 includes drivers and accesses the network for communication of PNM information. The network may be the Internet or a private network. A user's presence is disclosed via networking layer 450 while others' presence information is received via networking layer 450 . The structure of the networking layer 450 may be any structure that enables discovery and disclosure of presence information in accordance with the present invention.

The PNM component 422 of the rover 420 provides coordination and communication between the PNM sidebar tile 410 , the SSDP layer 430 , and the file system 440 . The PNM component 422 receives events indicative of updates to presence information on the network via the SSDP layer 430 . The PNM component 422 also receives changes selected by the user regarding the disclosure of user presence and changes to the display of presence information by the PNM sidebar tile 410 . PNM component 422 provides changes to the presence data in file system 440 in response to changes from PNM sidebar tile 410 and SSDP layer 430 .

5 shows another functional block diagram of a system for discovery and publication of neighbor presence information on a network, in accordance with the present invention. System 500 , shown in more detail with respect to the operation of the PNM function, is similar to system 400 of FIG. 4 . The system 500 includes a PNM sidebar tile 502 , a PNM public function 504 , a PNM discovery function 506 , a PNM persist function 508 , an SSD layer 510 , a networking layer ( 512 ), a contact user interface 514 , a file system 516 , and a PNM folder 518 .

The PNM sidebar tile 502 is similar to the PNM sidebar tile 410 shown in FIG. 4 , and is used to allow the user to make changes to PNM functionality and view presence information provided by the PNM system. In the example shown, the PNM sidebar tile 502 directly queries the file system 516 for the number of people in the vicinity and other information presented by the PNM sidebar tile 502 . In another embodiment, the PNM sidebar tile 502 communicates with a user interface for a contact application (eg, contact UI 514 ). The contact user interface coordinates between the PNM sidebar tile 502 and the file system 516 to present PNM information using the contact UI 514 .

The PNM publish function 504 publishes data about a local user on the network. The SSDP layer 510 publishes data indicating that the local user is online as an live packet, and the data includes information such as the user's display name. The active packet indicates that the local user is present and available on the network. Additional information published in the active packet includes a shared address that is translated into the local user's machine address. In a further embodiment, the active packet may include identifying information verification data, such as a public key and/or a private key, that enables the user to verify the user's identification information residing on the network. A process for verifying identification information of adjacent people is described below in more detail with respect to the discussion of FIG. 9 .

Also, in response to the local user choosing to disable the PNM service, a "bye-bye" message is published by the SSDP layer 510 . The bye-bye message means a notification provided to the network that the presence of a local user on the network is being discontinued.

In addition, other information regarding the SSDP protocol, such as maximum lifetime characteristics, is also disclosed. The maximum lifetime characteristic is included in the cache control header of the SSDP message and means the number of seconds that the local user's PNM service is valid. In one example, the maximum lifetime characteristic is provided when the bye-bye message is not published and the PNM service is abruptly terminated. Expiration of the maximum lifetime feature notifies other users that a given user's presence on the network has expired and no longer exists. As long as the local user keeps the PNM service enabled, active packets that update the maximum lifetime characteristic are continuously published over the network, thereby maintaining indications of the local user's presence on the network.

In addition, the service ID is disclosed in the cache control header of SSDP active packets and bye-bye messages. The service ID uniquely identifies each of the users present on the network.

In another embodiment, the PNM public function 504 discloses only a portion of data to be provided to neighboring users on the network in the form of messages or packets. Instead, the rest of the data is provided to the neighboring user using a dedicated port established by the local user in response to a request by the neighboring user. Using these combined communication methods to provide data to nearby users reduces the size of packets and increases processing speed over the network, allowing presence notifications to be updated more quickly.

Also, various events may request that the active packet be republished. For example, a user may choose to change their display name. The active packet with the changed display name and the same service ID is republished. Thus, users on the network will know that this change is not a new PNM presence on the network, but the same entity with a new display name.

The PNM discovery function 506 queries presence information about other nearby users on the network for display to the local user. SSDP layer 510 receives active messages and bye-bye messages from the network and maintains a database of currently adjacent users. In response to events on the network (eg, reception of an active packet), the SSDP layer 510 forwards a message corresponding to the event to the PNM discovery function 506 . In one embodiment, SSDP layer 510 tracks the maximum lifetime characteristic of each received active packet and sends a notification to PNM discovery function 506 when the characteristic expires. The PNM discovery function 506 forwards changes due to events on the network to the PNM adhering function 508 .

The PNM Advanced function 508 provides instructions for making changes to the data stored in the file system 516 and the PNM folder 518 . In one embodiment, PNM folder 518 contains a list of local users and nearby users. The PNM folder 518 may be linked with other folders in the file system 516 . Exemplary folder relationships between the PNM folder 518 and other folders in the file system 516 are further elaborated in FIG. 6 below.

The discussion throughout the detailed description and claims refers to "disclosure of presence information" and "disclosure of contacts". These phrases and their variants are meant to provide over a network searchable information about a user on the network. Published information includes such active packets, bye-bye messages, identification information, general contact information (eg, phone numbers, addresses, etc.), and other information about an entity or device connected to the network. may include

6 shows exemplary file structures corresponding to a file system for storing existence information according to the present invention. The file system 600 includes a PNM folder 610 , a person object 612 , and a personal contact folder 620 .

When the SSDP layer forwards an active message to the rover's PNM component (see FIG. 4 ), a person object 612 is initiated. The person object 612 is populated with data from the active message, such as a shared address and display name. In one embodiment, data verification in the active message to verify the authenticity of the provided data is performed prior to being populated with the person object 612 . Verification prevents unauthorized browser operations due to incorrect addresses and incorrect entries being stored in the local user's contact.

In one embodiment, person object 612 is associated with PNM folder 610 as a contact entry. Thus, the local user can open the PNM folder 610 to view all contact entries corresponding to other adjacent users. Further, the process may then count the number of entries in the PNM folder 610 to provide the local user with a display of the number of people in the vicinity.

In another embodiment, a relationship may be created between the contact entries in the personal contacts folder 620 and the contact entries in the PNM folder 610 . This relationship is created when a received active message has an associated identifying information confirmation. For example, public key cryptography may be used in connection with an active message to verify identification information about the source of the active message. The use of public key encryption in the PNM system is further elaborated with reference to FIG. 9 below. If the identification information of the user sending the active message is identified as an existing entry in the personal contact folder 620, a link is created with that entry rather than a new person object. Thus, the entry in the PNM folder 610 is not a simple Person object with a display name and a shared address, but rather rich content associated with the Personal Contacts folder 620 (eg, addresses, phone numbers, pictures). etc.) are included. Also, since the relationship with the entry in the personal contact folder 620 is exchanged, when the entry in the personal contact folder 620 is opened, presence information (eg, display name, online status, shared address, etc.) is displayed.

In another embodiment, a relationship between the person object 612 and the personal contact folder 620 is created. Due to this relationship, the PNM contact entries are reflected in the personal contacts folder 620 while remaining identified as a PNM contact according to the PNM GUID. In one example, the PNM GUID is identified according to a PNM indicator that identifies all PNM entries associated with the service ID (see discussion of FIG. 5 ). Thus, the PNM GUID identifies the contact entry as a PNM contact and distinguishes each PNM contact from one another. The process may then count the number of contact entries in the personal contacts folder 620, with the associated PNM GUID, to display the number of adjacent people. Also, due to uniquely identifying PNM entries, personal contacts folder 620 may remove PNM entries when a local user chooses to disable the PNM service. Thus, as people enter and exit the network, and as local users enable and disable the PNM service, the personal contacts folder 620 may be updated, so that the file system 600 is synchronize

Also, by storing PNM contacts as part of the local user's general (ie, personal) contact list, other applications may also use presence information about nearby people. For example, a generic contact user interface may be used to view a list of local users of a generic contact. By populating the personal contacts folder 620 with PNM contacts, the PNM contacts are reflected in the general contacts user interface. Other applications accessing personal contacts folder 620 (eg, contact picker dialogs) may also use presence information and display nearby people on the network.

7 illustrates exemplary sidebar tiles related to disclosure and discovery of the presence of nearby users on a network in accordance with the present invention. Three tile scenarios are shown providing different sidebar tiles based on user selections and the state of the network. In each scenario, a possible collapsed view (eg 712 ) of a sidebar tile is provided along with a possible expandable view (eg 714 ). In other embodiments, each expandable view (eg, 714 ) may be a separate window or flyout that is created outside of the sidebar itself.

Scenario 710 illustrates an example UI for a case where the PNM service has not yet been enabled by the user. A collapsed PNM sidebar tile 712 provides a choice for enabling the service. The expandable PNM sidebar tile 714 provides additional options regarding the display name that the local user wants to be published and other options for configuring the PNM service.

Scenario 720 illustrates an example UI for a case where the PNM service is enabled by the user. The collapsed PNM sidebar tile 722 provides an indication of the number of people in the vicinity and also provides a choice to view more detailed information about the people in the vicinity. The expandable PNM sidebar tile 724 provides additional options regarding the display name that the local user wants to be published and other options for configuring the PNM service and viewing more detailed presence information.

Scenario 730 illustrates an example UI for when a network is unavailable. A collapsed PNM sidebar tile 732 provides a choice to view details of network invalidities. The extended PNM sidebar tile 734 provides options for configuring PNM services while also providing options for checking for network failures.

8 shows an exemplary state diagram for implementing a user interface for the discovery and publication of presence information on a network in accordance with the present invention. The finite state machine 800 includes ten states for the presentation of the PNM user interface based on the state of the PNM service.

Initially, the monitoring application of the mobile device is in state 801, indicating that neither the PNM service nor the PNM sidebar tile is enabled and the bar tile is not visible. When the PNM sidebar tile is enabled, state machine 800 moves to state 802 .

In state 802, the PNM sidebar tile is in a standby mode, waiting for additional input from a local user. The local user's input may be disabling the PNM sidebar tile. If the local user disables the PNM sidebar tile, state machine 800 returns to state 801 . In one embodiment, when the PNM sidebar tile is first enabled (ie, when state 801 is reached to state 802 ), state machine 800 moves to state 803 .

In state 803, a flyout or other external window is automatically presented to the local user so that the local user can select initial options (eg, display name) regarding the PNM service. If the user chooses to cancel without selecting additional options, state machine 800 returns to state 802 . However, if the user selects options for the PNM service, state machine 800 proceeds to state 804 .

In another embodiment, state 803 is not included and no options are provided. Next, the local user can choose to enable the PNM service and the state moves directly from state 802 to state 804.

State 804 is included among states 804 , 805 , 806 , 807 in state area 820 . The status area 820 indicates that the PNM service is being enabled or is enabled. In state 804, the PNM service is being enabled. If the enable process is successful, the state machine 800 moves to state 805 where the PNM service is enabled and nearby people are displayed to the user. However, if no network is found during the enabling process, state machine 800 moves to state 806 .

At state 806, the PNM system enters a standby cycle waiting for the network to return. State 806 can be reached from state 805 even if a network failure occurs while the PNM service is enabled. When the network becomes available again, state machine 800 moves to state 805 where PNM is enabled and displays nearby people.

While the PNM service is enabled in state 804, a connection to the rover (see FIG. 4) may not be established. As mentioned above, the rover contains code for implementing the PNM service. If the rover is not reached after a certain count (eg, 12 seconds), state machine 800 moves from state 804 to state 807 . At state 807, the enable process waits 5 seconds and then returns to state 804 to retry the connection to the rover.

In certain circumstances, during the enable process, a critical error sufficient to cause the PNM service to operate incorrectly may occur. When a critical error occurs, the state moves from state 804 to state 808. In state 808, the local user is notified of a critical error and that the PNM service cannot continue. The local user can then choose to disable the PNM sidebar tile and state machine 800 returns to state 801 .

From any of the states in the state area 820, the user may choose to cancel the current operation. Canceling the current operation stops the enable state or disables the PNM service. When the PNM service is disabled, state machine 800 returns to state 802 in standby mode where the PNM sidebar tile awaits further input from the local user.

Also, from any of the states in the status area 820, the user may choose to close the PNM sidebar tile or the sidebar itself. If the user chooses to disable the PNM sidebar tile or sidebar, state machine 800 moves to state 810 . In state 810 , the affected systems and folders (eg, contacts folder) are corrected and the PNM sidebar tile is disabled, and state machine 800 reverts to state 801 . In one embodiment, when the system is corrected, instances of PNM contacts and other PNM data are removed from the file system. Also, the SSDP layer (see FIG. 4 ) is instructed to stop disclosing the presence of local users and discovering the presence information of other nearby users on the network.

9 illustrates an exemplary identification information check for a presence notification of a nearby user, in accordance with the present invention. For identification verification, user 1 has a set of elements 910 (ie, active packets) associated with presence notifications. A public key (Pu1; 911) and a private key (Pr1; 912) are associated with user 1. Data D including a display name 913 , a shared address 914 , a timestamp 915 , and a hash (Pu1+salt) 916 is sent as a presence notification. Data (D) is signed with the public key (Pr1; 911) and has an associated signature (S1 (D); 917).

Display name 913 and shared address 914 exist to allow a local user to disclose the name to nearby users who do not know the local user and notify nearby users that the local user has been sharing information. optionally included in the notice. Timestamp 915 is included to provide the time at which signature S1(D) is valid. A hash (Pu1+salt) 916 is also optionally included. The hash (Pu1+salt) 916 is a version of the public key (Pu1; 911) hashed along an irregular amount of data called "salt". If "salt" is included in the hash, "salt" is also disclosed in the data (D). By hashing the public key (Pu1; 911), it is possible to ensure that a third party cannot monitor the public keys as they are passed between users. A third party looking at the hashed public key will only see random data unrelated to the public key. By adding a "salt" to the hashed public key, the public key can become more complex and helps prevent tracking of the public key. Hashing the public key (Pu1; 911) also provides restrictions on the identification information of the user who is disclosing the data (D). If there is no hashed public key, it may be necessary to try each contact's public key to determine who signed the data (D). Since the hashed public key is public, the contact can be queried first for a contact with the public key hashed to a matching hash (Pu1+salt) 916 . Thus, by publishing the hash (Pu1+salt) 916, the results can be defined and the speed of the verification process is increased. In other embodiments, the public key (Pu1) 910 is not hashed or is hashed without a "salt" (eg, random reordering of the public key bits).

When user 1 generates a private key (Pr1; 912), a public key (Pu1; 911) may also be generated and associated with the private key (Pr1; 912). User 1 can then send the public key (Pu1; 911) to User 2. By disseminating the public key, user 1 can sign the data set (eg D) with the private key (Pr1; 912), so this data includes the signature (S1(D); 917). Thus, if the data is encrypted, only users with the public key (Pu1; 911) associated with user 1 (eg, user 2) can see the data signed with the private key (Pr1; 912). Regardless of the encryption used, the signature S1(D) still proves the identification of user 1 by proving that data D has not been tampered with and that data D originates from user 1. For example, with the public key (Pu1; 911), user 2 can use an equivalent hash of the public key (e.g., hash(Pu1+salt) 916) for comparison with the original hash of the public key (e.g. , a hash (Pu1+salt) 921) may be generated. If the hashes match (and if the data is encrypted), then user 2 knows that the display name 913 , shared address 914 , and timestamp 915 really came from user 1 and not from the malicious user. can

Signature S1(D) 917 prevents a malicious user from republishing data published by user 1 over another network by changing the shared address 914 . An attempted change to the shared address 914 destroys the signature S1(D) 917 , so a user receiving a malicious rebroadcast will know that the data has not been verified. Also, since the malicious user does not have the secret key (Pr1; 912), he cannot re-sign the data.

Also, by including the timestamp 915, the signature S1(D) 917 can be valid for a certain amount of time. When the time expires, the identification information check also expires. Timestamp 915 prevents malicious users from rebroadcasting data without change after a predetermined time has elapsed. Other users receiving this data will blindly ignore the data after this time has elapsed since timestamp 915 has expired.

In one embodiment of the present invention, data transferred in response to the presence of adjacent User 1 on the network is not encrypted, even when a public key infrastructure (PKI) is used. Instead, the use of public and private keys is limited to verifying the user's identifying information as a source of data. The transmitted data is written in plain text and therefore can be viewed, but public key cryptography verifies the identity of the user to whom the data is to be disclosed.

As described above with reference to FIG. 6 , when identification information of a user who is disclosing data is confirmed as an existing contact, a richer data set is provided to the user, thereby improving the display of PNM information for the user.

The above description, examples, and data provide a complete description of the make and use of the construction of the present invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention is determined by the claims appended hereto.