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

The present invention relates to a user interface for discovering and disclosing presence information on a network.

The concept of presence has become an increasingly important issue in networking applications and real-time communication. Presence often refers to being able to detect whether a user is online and available. An example of an application that uses presence information is an instant messenger (IM) program. IM programs provide a way for users to send instant messages to other IM users on the Internet or network. IM is a type of communication service that allows users to create some sort of private chat room with another individual to communicate in real time over the Internet. IM is similar to a telephone conversation, but uses text-based communication rather than voice-based communication. In general, instant messaging systems alert users to see if anyone on their private list is online. The user can then initiate a chat session with that particular individual.

However, the presence of IM and other similar applications has been limited to presence information that is directly related to contacts already established by the user. The presence of other users than the user's listed contacts was not available. Other applications can discover what devices are on the network, but not users. The presence information provided has been displayed by an annoying or overly prominent user interface. For example, an IM application must be open, running, and visible to the user in order to display presence information.

<p> The present invention is generally intended to provide a system and method for a user interface that targets the disclosure and discovery of a user's presence information on a network.</p>

<p> This user interface is ancillary and unobtrusive about exposing local users on the network. unobtrusive) Provides notifications and also provides the presence of neighbors on the network. The present invention utilizes a sidebar provided on the desktop of a local user, including various tiles. The various tiles provide different functionality, selected by the local user. In the present invention, presence information is provided as one of the tiles in the sidebar. Therefore, the presence information is incidentally provided to other applications running on the local user's computing device. When the user enables the sidebar tile, presence information is provided and updated so that the user can always see it. However, that information is provided so that updates are not annoying to the user when the local user works on the computing device. For example, a sidebar tile may contain only the number of neighboring users. The numbers are updated as the people enter and leave the network. Therefore, the local user can notice the change in the presence information provided without forcing the presence information to be sent to the local user.</p><p> In addition, it offers the option to change aspects of the presence discovery service. Local users can enable or disable the presence discovery service from the sidebar tile, or even choose to disable the sidebar tile itself.</p><p> According to one aspect of the invention, a computer-implemented method is provided for a user interface that targets the discovery and disclosure of presence information on a network. This method determines if there are local users on the network and if there are neighboring users on the network. Part of the user interface is instantiated for incidental, unobtrusive notifications about the presence of local users on the network and the presence of neighboring users. Then, if it is determined that the local user exists on the network, the presence of the local user and the presence of neighboring users are displayed as part of the user interface.</p>

Next, the present invention will be more fully described below with reference to the accompanying drawings which form a part thereof and show, for example, specific exemplary embodiments for carrying out the present invention. However, the present invention can be implemented in many different forms and should not be construed as being limited to the embodiments described herein. Instead, such embodiments are provided to ensure that this disclosure is exhaustive and complete and that those skilled in the art are fully informed of the scope of the invention. The present invention may be practiced as a method or apparatus, among others. Therefore, the present invention may take the form of a completely hardware embodiment, a completely software embodiment, or a combination of hardware and software aspects. is there. Therefore, the following detailed description should not be construed in a limited sense.

Illustrative Operating Environment With reference to FIG. 1, one exemplary system for carrying out the present invention includes a computing device, such as the computing device 100. The computing device 100 can be configured as a client, server, mobile device, or any other computing device for discovering and disclosing presence information. In a very basic configuration, the computing device 100 typically includes at least one processor 102 and system memory 104. Depending on the exact configuration and type of computing device, the system memory 104 can be volatile (RAM, etc.), non-volatile (ROM, flash memory, etc.), or some combination of the two. is there. System memory 104 generally includes operating system 105, one or more applications 106, and may also include program data 107. In one embodiment, application 106 is a neighbor application (people near me). application) 120 is included. In FIG. 1, this basic configuration is shown by the components within the dashed line 108.

The computing device 100 may have additional features or functions. For example, the computing device 100 may include additional data storage devices (retrievable and / or non-retrievable) such as magnetic disks, optical disks or tapes. In FIG. 1, these additional storage devices are represented by Retrievable Storage 109 and Non-Retrievable Storage 110. Computer storage media are volatile and non-volatile, retrievable and non-retrievable media implemented by any method or technique for storing information such as computer-readable instructions, data structures, program modules or other data. May include. System memory 104, retrievable storage 109, and non-retrievable storage 110 are all examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROMs, and digital versatile discs (DVDs: digital versatile). Can be used to store disk) or other optical storage, magnetic cassettes, tapes, magnetic disk storage or other magnetic disk storage devices, or desired information, and can also be accessed from compute device 100. Includes any other medium that can. Any of these computer storage media can be part of device 100. The computing device 100 may also include an input device 112 such as a keyboard, mouse, pen, voice input device, touch input device, and the like. Output devices 114 such as displays, speakers, printers, etc. may also be included.

The computing device 100 also includes a communication connection 116 that allows the device to communicate, for example, with another computing device 118 over a network. The communication connection 116 is an example of a communication medium. Communication media can generally be implemented by other data in the form of computer-readable instructions, data structures, program modules, or modulated data signals such as carrier waves or other transport mechanisms, and can also deliver arbitrary information. Includes medium. The term "modulated data signal" means a signal whose characteristics have been set or modified to encode information into the signal. For example, but not for limitation, communication media include wired media such as wired networks and direct wired connections, as well as wireless media such as acoustic, RF and other wireless media. As used herein, the term computer-readable medium includes both storage and communication media.

FIG. 2 shows an alternative operating environment for mobile devices that are practically used in the present invention. In one embodiment of the invention, the mobile device 200 is incorporated as a computing device such as an integrated personal digital assistant (PDA) and a radiotelephone.

In this embodiment, the mobile device 200 includes a processor 260, a memory 262, a display device 228 and a keypad 232. Memory 262 generally includes both volatile memory (RAM, etc.) and non-volatile memory (ROM, flash memory, etc.). The mobile device 200 resides in memory 262 and also includes an operating system 264 running on processor 260. The keypad 232 can be a push-button numeric dial pad (such as a typical phone), a multi-key keyboard (such as a traditional keyboard), or included within a mobile device, considering a touch screen or stylus. It may not be possible. The display device 228 may be a liquid crystal display or any other type of display device commonly used in mobile computing devices. The display device 228 may be a touch panel type, and therefore also acts as an input device.

One or more application programs 266 are loaded into memory 262 and run operating system 264. Examples of application programs include telephone dialing programs, e-mail programs, scheduling programs, and PIM (personal information). management: Personal information management) programs, document processing programs, spreadsheet programs, internet browser programs, etc. are included. In one embodiment, application program 266 includes neighbor (PNM) application 280. The mobile device 200 also includes a non-volatile storage 268 in memory 262. Non-volatile storage 268 can be used to store persistent information that should not be lost if the mobile device 200 is powered down. Application 266 uses information such as email and other messages used by email applications, contact information used by PIM, appointment information used by scheduling programs, documents used by document processing applications, and so on. , And it can be stored in storage 268. The synchronization application also resides in the mobile device and interacts with the corresponding synchronization application residing in the host computer to convert the information stored in storage 268 to the corresponding information stored in the host computer. Keep it in sync.

The mobile device 200 includes a power supply 270 that can be implemented as one or more batteries. The power supply 270 may further include an AC adapter and an external power source such as a docking cradle with a power source that complements or charges the battery.

The mobile device 200 has also been shown to include two types of external notification mechanisms, an LED 240 and an audio interface 274. These devices remain on for the duration indicated by the notification mechanism, even if the processor 260 and other components may be shut down to save battery power when activated. Therefore, it can be directly coupled to the power supply 270. The LED 240 may remain on indefinitely until the user takes action and may be programmed to indicate the power-on status of the device. Audio interface 274 is used to provide 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, for example to facilitate a telephone conversation.

The mobile device 200 also includes a radio 272 that performs the function of transmitting and receiving radio frequency communications. The radio 272 facilitates wireless connectivity between the mobile device 200 and its outside via a telecommunications carrier or service provider. Transmission to and from radio 272 is carried out under the control of operating system 264. In other words, the communication received by the radio 272 can be propagated through the operating system 264 to the application program 266 and vice versa.

The radio 272 allows the mobile device 200 to communicate with other computing devices, for example over a network. The radio 272 is an example of a communication medium. Communication media can generally be implemented by computer-readable instructions, data structures, program modules, or other data in the form of modulated data signals such as carrier waves or other transport mechanisms, and any information delivery. Includes medium. The term "modulated data signal" means a signal whose characteristics have been set or modified to encode information into the signal. For example, but not for limitation, communication media include wired media such as wired networks and direct wired connections, as well as wireless media such as acoustic, RF and other wireless media. As used herein, the term computer-readable medium includes both storage and communication media.

Illustrative presence discovery public system The present invention generally provides a system for a user interface that targets to discover the presence information of a user's neighbors and to expose the user's presence to those neighbors. As used herein, the term "neighborhood" refers to the physical neighborhood of a person or user connected within a network. For example, people whose devices are connected within the same local area network can be considered "neighboring" to each other. Anyone whose device is connected to the same network is considered "neighborhood". In addition, people residing on a link-local network can be considered "neighborhoods". Alternatively, the presence information may include a physical location designation so that people in the same room are considered "neighborhoods". The use of "neighborhood" in this application is not limited to a single level of neighborhood, or requires that the user and the person designated as "neighborhood" be in close proximity to each other. "Neighborhood" can be specified for any relationship between users based on the physical or network location of a person or its associated device (computing device, mobile device, etc.).

FIG. 3 shows an exemplary sidebar in a desktop according to the present invention. The sidebar 310 in the desktop 300 includes tiles (such as 320) that provide various information to the user during a computing session. For example, the tiles in the sidebar 310 may contain media information, email information, schedule notifications and other information. Each tile may contain an icon and other content that differentiates the tiles from each other. According to the present invention, the PNM (Neighborhood) sidebar tile 330, which provides the user with presence information incidentally and unobtrusively, is also included.

An exemplary PNM sidebar tile 330 includes a presence indicator 332 exposed by the user, notifications 334 about the presence of other users, and selection 336 for displaying more detailed presence information. In this example, indicator 332 provides a user-selected alias that is exposed to other users on the network. Notification 334 provides a dynamically updated number of users currently considered to be in the vicinity of the user (for example, 23 neighbors). Selection 336 provides a link to more detailed information about the presence of other users on the network. For example, if the user selects selection 336, window 340 is opened to provide the user with more detailed information.

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

FIG. 4 shows a functional block diagram of a system for discovering and disclosing neighborhood presence information on a network according to the present invention. System 400 includes PNM (Neighbor Discovery) sidebar tile 410 (see Figure 3), rover 420, SSDP (simple service discovery protocol) layer 430, file system 440 and network king layer 450. .. Rover 420 includes PNM component 422.

The PNM sidebar tile 410 is a user interface that provides incidental and unobtrusive notifications to anyone who is considered to be in the vicinity of the user. The PNM sidebar tile 410 is described in more detail in connection with the discussion of Figures 7 and 8 below.

SSDP layer 430 provides a protocol for discovering and disclosing presence information on the network. SSDP layer 430 is considered to be a subset protocol of the UPnP (universal plug and play) protocol for device connectivity on the network. UPnP is based on existing protocols and technologies. For example, UPnP uses TCP / IP, UDP / IP and HTTP protocols as a basis. In addition to these underlying protocols, several other protocols are based on them to implement various steps or stages of UPnP networking, such as SSDP. The form of PNM messages sent and received according to SSDP layer 430 is described in more detail below with reference to FIG.

File system 440 provides an extensible storage location for information about the presence of the user's neighbors. In one embodiment, file system 440 is a WinFS file system created by Microsoft Corporation in Redmond, Washington. File system 440 allows PNM (neighborhood) information to be presented via two or more UIs (user interfaces) and links PNM information to other databases for use. It is composed of. For example, file system 440 may include a contacts folder in which the user's contacts are stored. PNM information can be used to indicate to the user which of the listed contacts is considered a neighbor. It can also form other relationships between PNM information and other data to enable distribution and use of PNM information across multiple applications.

Networking layer 450 includes drivers and access to the network to convey PNM information. The network may be the Internet or a private network. The user's presence information is published through the networking layer 450, and other presence information is received through the networking layer 450. The structure of the networking layer 450 can be any structure that allows the discovery and disclosure of presence information according to the present invention.

PNM component 422 in 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 an event indicating an update of presence information on the network via the SSDP layer 430. PNM component 422 also receives changes selected by the user regarding the disclosure of the user's presence, as well as changes in the display of presence information by the PNM sidebar tile 410. PNM component 422 results in changes in presence data in file system 440 in response to changes from PNM sidebar tile 410 and SSDP layer 430.

FIG. 5 shows another functional block diagram of the system for discovering and disclosing neighborhood presence information on a network according to the present invention. System 500 is similar to System 400 in FIG. 4, which shows more details about the operation of PNM (Neighborhood) functions. System 500 includes PNM sidebar tile 502, PNM publishing function 504, PNM discovery function 506, PNM persistence function 508, SSDP layer 510, networking layer 512, contact user interface 514, file system 516 and PNM folder 518.

The PNM sidebar tile 502 is similar to the PNM sidebar tile 410 shown in Figure 4, which allows the user to make PNM feature changes and to provide presence information provided by the PNM system. You can see it. In the illustrated example, the PNM sidebar tile 502 queries the file system 516 directly for the number of neighbors and other information presented by the PNM sidebar tile 502. In another embodiment, the PNM sidebar tile 502 communicates with a user interface for the contacts application (such as the contacts UI514). The contact user interface works in tandem between the PNM sidebar tile 502 and the file system 516 and uses the contact UI 514 to present PNM information.

The PNM publishing function 504 publishes data about local users on the network. The SSDP layer 510 exposes data as an alive packet indicating that the local user is online, and the data includes information such as the user's display name. Alive packets indicate that a local user exists on the network and is available. The additional information exposed in the packet contains a shared address that resolves to the local user's machine address. In additional embodiments, the alive packet may include identification verification data such as a public key and / or a private key that allows the user to verify the identification of a user present on the network. The process for identifying and verifying neighbors is discussed in more detail below in connection with the discussion in Figure 9.

A "goodbye" message is also exposed by the SSDP layer 510 in response to the local user choosing to disable the PNM service. A goodbye message refers to a notification provided to the network that the presence of local users on the network will be stopped.

In addition, other information about the SSDP protocol, such as the maximum lifetime property, will be published. The maximum lifetime property is included in the cache control header of the SSDP message and indicates the number of seconds that the local user's PNM service is active. In one example, the maximum lifetime property is provided in case the PNM service abruptly terminates without publishing a goodbye message. The time-out of the maximum lifetime property notifies other users that the presence of a particular user on the network has timed out. As long as the local user keeps the PNM service enabled, alive packets that update the maximum lifetime property are continuously published so that the display of the local user's presence on the network is maintained.

The service ID is also exposed in the cache control header of SSDP alive packets and goodbye messages. The service ID uniquely identifies each user on the network.

In an alternative embodiment, the PNM issuing function 504 exposes only part of the data provided to neighboring users on the network in the form of messages or packets. Instead, the rest of the data is provided to the neighbors using the ports established by the local users in response to requests from the neighbors. By using a combination of these communication methods to provide data to neighboring users, you can reduce packet size, increase throughput on your network, and update your presence notifications more quickly.

Various events may also require the republication of alive packets. For example, the user may choose to change its display name. Alive packets are republished with the same service ID, although the display name has changed. Therefore, the user on the network knows that the change is not the new PNM presence on the network, but the same presence with the new display name.

The PNM discovery feature 506 queries for presence information related to other neighbors on the network for display to local users. SSDP Layer 510 receives alive and goodbye messages from the network and maintains a database of currently nearby users. In response to an event on the network (such as receiving an alive packet), the SSDP layer 510 forwards the message corresponding to the event to the PNM discovery function 506. In one embodiment, the SSDP layer 510 also tracks the maximum lifetime property of each received alive packet and sends a notification to the PNM discovery function 506 when the property expires. PNM Discovery 506 forwards changes caused by events on the network to PNM Persistence 508.

PNM persistence 508 provides instructions for modification to the data stored in file system 516 and PNM folder 518. In one embodiment, the PNM folder 518 contains a list of users in the vicinity of the local user. PNM folder 518 can be linked with other folders in file system 516. An exemplary folder relationship between the PNM folder 518 and other folders within the file system 516 is illustrated below with reference to FIG.

Discussions throughout the specification and claims refer to "disclosure of presence information" and "disclosure of contacts." These representations and their variations refer to the provision of information about users on a network that can be retrieved on the network. The information disclosed includes the alive packets mentioned above, goodbye messages, identification information, general contact information (phone numbers, addresses, etc.), and any other information about any other networked entity or device. obtain.

FIG. 6 shows an exemplary file structure corresponding to a file system for storing presence information according to the present invention. The file system 600 includes a PNM folder 610, a person object 612, and a personal contacts folder 620.

The person object 612 is instantiated when the SSDP layer transfers an alive message to the rover's PNM component (see Figure 4). Data from the alive message, such as the shared address and display name, is captured within the person object 612. In some embodiments, the validation of the data in the alive message is done before it is populated into the person object 612 to ensure the reliability of the data provided. Validation prevents unauthorized browser operations by fake addresses and the storage of fake entries in local user contacts.

In one embodiment, the person object 612 is associated with the PNM folder 610 as a contact entry. Therefore, the local user can open the PNM folder 610 to see all the contact entries corresponding to other neighbors. In addition, the process can then count the number of entries in the PNM folder 610 to display the number of neighbors for the local user.

In another embodiment, a relationship may be generated between the contact entry in the personal contacts folder 620 and the contact entry in the PNM folder 610. This relationship is generated when the associated identity verification is included in the received alive message. For example, public key cryptography may have been used in connection with the alive message to verify the identity of the source of the alive message. The use of public key cryptography for PNM systems is described in more detail below with respect to Figure 9. If the identity of the user sending the alive message is verified to be an existing entry in the Personal Contacts folder 620, a link to that entry is generated instead of the new person object. Therefore, the entry in the PNM folder 610 is not a simple person object containing a display name and a shared address, but contains a wealth of content (addresses, phone numbers, images, etc.) related to the personal contacts folder 620. In addition, the relationship is interacted with the entry in the personal contacts folder 620 so that presence information (display name, online status, shared address, etc.) is shown when the entry is opened in the personal contacts folder 620.

In another embodiment, a relationship is created between the person object 612 and the personal contacts folder 620. The relationship reflects the PNM contact entry in the personal contacts folder 620, but is still identified as a PNM contact according to the PNM GUID (PNM global unique identifier). In one example, the PNM GUID is identified according to a PNM specifier that identifies all PNM entries combined with a service ID (see discussion in Figure 5). Therefore, the PNM GUID identifies the contact entry as a PNM contact and also distinguishes each PNM contact from the others. The process then processes the associated PNM to display the number of neighbors. The number of contact entries in a personal contact 620 with a GUID can be counted. In addition, by uniquely identifying the PNM entry, the personal contacts folder 620 can delete the PNM entry when the local user chooses to disable the PNM service. Therefore, the file system 600 can update the personal contacts folder 620 when a person moves in or out of the network, and when a local user enables and disables the PNM service, thus with the presence of neighbors on the network. Synchronized.

By storing PNM contacts as part of the local user's general (ie, personal) contact list, other applications can also take advantage of neighbors' presence information. For example, you can use the common contacts user interface to see a general contact list for local users. By incorporating PNM contacts into the Personal Contacts folder 620, PNM contacts are reflected within the general contacts user interface. Other applications that access your personal contacts folder 620, such as the contact picker dialogue, can also use your presence information to display people in your neighborhood on the network.

FIG. 7 shows an exemplary sidebar tile related to the disclosure and discovery of the presence of neighboring users on a network according to the present invention. Three tile scenarios are shown that provide different sidebars based on user selection and network conditions. Each scenario has a possible reduced view of the sidebar tile (such as 712), along with a possible enlarged view (such as 714). In another embodiment, each magnified view (such as 714) is a flyout or a separate window that is generated rather than within the sidebar itself.

Scenario 710 shows an exemplary UI when the PNM (Neighborhood) service is not yet enabled by the user. The reduced PNM sidebar 712 provides a choice to enable the service. The expanded PNM sidebar tile 714 offers additional options for display names that local users want to publish, as well as other options for configuring PNM services.

Scenario 720 shows an exemplary UI when the PNM (Neighborhood) service is enabled by the user. The reduced PNM sidebar tile 722 provides an indication of the number of neighbors and also provides a choice to display more detailed information about the neighbors. The expanded PNM sidebar tile 724 offers additional options for display names that local users want to publish, as well as other options for setting PNM services and displaying detailed presence information.

Scenario 730 shows an exemplary UI when the network is unavailable. The reduced PNM sidebar tile 732 provides a choice for displaying details about network availability. The enhanced PNM sidebar tile 734 offers an option to configure PNM services and also offers an option to repair network failures.

FIG. 8 shows an exemplary state table for implementing a user interface for publishing and discovering presence information on a network according to the present invention. The finite state machine 800 contains 10 states for presenting a PNM (neighborhood) user interface based on the state of the PNM service.

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

In state 802, the PNM sidebar tile is in standby mode waiting for further input from the local user. Local user input can be to disable the PNM sidebar tile. When the local user disables the PNM sidebar tile, state machine 800 returns to state 801. In one embodiment, the state machine 800 moves to state 803 when the PNM sidebar tile is first enabled (ie, from state 801 to state 802).

In state 803, a flyout or other external window is automatically provided to the local user so that the local user can select the first option for the PNM service (such as the display name). If the user chooses to cancel without selecting any further options, state machine 800 reverts to state 802. However, if the user selects the PNM service option, the state machine 800 proceeds to state 804.

In the alternative embodiment, state 803 is not included and its options are not provided. The local user then chooses to enable the PNM service and the state goes directly from state 802 to state 804.

The state 804 is included in the states (804, 805, 806, 807) in the state area 820. State region 820 indicates when the PNM service is being enabled or is enabled. In state 804, the PNM service is enabled. If the enable process succeeds, state machine 800 proceeds to state 805, where the PNM service is enabled and neighbors are visible to the user. However, if no network is found during the enabled process, state machine 800 moves to state 806.

If the PNM system waits for the network to come back, it goes into a wait cycle in state 806. A state 805 to 806 can also be reached if a network failure occurs while the PNM service is enabled. When the network becomes available again, the state machine 800 moves to state 805, PNM is enabled, and the neighbors are displayed.

A connection with the rover (see Figure 4) may not be established while the PNM service is being enabled in state 804. As mentioned above, the rover contains the code to implement the PNM service. If the rover is not reached after the specified count (such as 12 seconds), state machine 800 moves from state 804 to 807. In state 807, the enabled process waits 5 seconds, then returns to state 804 and retries the connection with the rover.

In some situations, during the enable process, errors can occur that are serious enough to prevent the PNM service from operating properly. If a serious error occurs, the state moves from state 804 to state 808. In state 808, the local is notified that a serious error has occurred and that the PNM service will not continue. The local user can then choose to disable the PNM sidebar tile and the state machine 800 returns to state 801.

In any of the states in the state area 820, the user may choose to undo the current operation. Canceling the current operation suspends the enablement, that is, disables the PNM service. When the PNM service is disabled, state machine 800 returns to state 802 and the PNM sidebar tile goes into standby mode, waiting for further input from the local user.

In addition, the user may choose to close the PNM sidebar tile or the sidebar itself in any of the states within the state area 820. If the user chooses to disable the PNM sidebar tile or sidebar, the state machine 800 moves to state 810. In state 810, the affected systems and folders are cleaned up, PNM sidebar tiles are disabled, and state machine 800 returns to state 801. In one embodiment, instances of PNM contacts, as well as other PNM data, are deleted from the file system when the system is cleaned up. The SSDP layer (see Figure 4) is also instructed to suspend the disclosure of the presence of local users and the discovery of presence information of other neighbors on the network.

FIG. 9 shows an exemplary identification verification of presence notification for nearby users according to the present invention. For identification verification, user 1 has a set of elements 910 associated with presence notifications (ie, alive packets). A public key (Pu1) 911 and a private key (Pr1) 912 are associated with user 1. Data (D) containing display name 913, shared address 914, time stamp 915 and hash (Pu1 + salt) 916 is sent in the presence notification. The data (D) is signed with the private key (Pr1) 911 to have the associated signature S1 (D) 917.

The display name 913 and the shared address 914 are used to allow the local user to expose the name to a neighbor who does not know the local user and to inform the neighbor that the local user has shared information. Optionally included in the presence notification. Timestamp 915 is included to provide a time interval in which signature S1 (D) is valid. Hash (Pu1 + salt) 916 is also optionally included. Hash (Pu1 + salt) 916 is a hashed version of public key (Pu1) 911 with a certain amount of random data called "salt". If the salt is included in the hash, the salt is also exposed in the data (D). Hashing the public key (Pu1) 911 prevents third parties from monitoring the public key as it is transferred between users. A third party looking at the hashed public key can only see random data that is inconsistent with the public key. By adding salt to the hashed public key, the public key becomes even more confusing and helps prevent tracking of the public key. Hashing the public key (Pu1) 911 also provides a refinement of the identification of the user public data (D). Without the hashed public key, it may be necessary to test the public key of each contact to determine who signed the data (D). With the publicly hashed public key, the contact can first be queried for a contact containing the public key that is hashed to match hash (Pu1 + salt) 916. Therefore, by exposing the hash (Pu1 + salt) 916, you can narrow down the results and speed up the verification process. In other embodiments, the public key (Pu1) 910 is not hashed, or instead, is hashed without a salt (such as a random reordering of public key bits).

When user 1 generates the private key (Pr1) 912, the public key (Pu1) 911 is also generated and associated with the private key (Pr1) 912. User 1 can then send the public key (Pu1) 911 to user 2. By distributing the public key, user 1 can sign a set of data (such as D) with the private key (Pr1) 912, which includes signature S1 (D) 917. Therefore, if the data is encrypted, only the user with the public key (Pu1) 911 associated with user 1 (such as user 2) can see the data signed with the private key (Pr1) 912. Regardless of which encryption is used, the signature S1 (D) still proves that the data (D) has not been tampered with and that the data (D) originated from user 1, therefore. User 1 identification is proved. For example, using the public key (Pu1) 911, user 2 generates an equivalent hash of the public key (such as hash (Pu1 + salt) 921) and the original hash of the public key (such as hash (Pu1 + salt) 916). ) Can be compared. If the hashes match (and the data is encrypted), user 2 knows the display name 913, shared address 914, and timestamp 915 that actually originated from user 1, not the malicious user.

Signature S1 (D) 917 prevents a malicious user from attempting to republish the data published by User 1 on another network by changing the shared address 914. Attempts to change shared address 914 destroy signature S1 (D) 917 to notify users who receive a malicious rebroadcast that their data has not been validated. In addition, the malicious user does not have the private key (Pr1) 912 and cannot re-sign the data.

In addition, including the time stamp 915 enables signature S1 (D) 917 for the specified time. At the end of that period, so will the identification verification. Timestamp 915 prevents a malicious user from rebroadcasting data unchanged after a certain period of time. Other users who receive this data simply ignore the data because the time stamp 915 has expired after that period.

In one embodiment of the present invention, even if a public key infrastructure (PKI) is used, the transmitted data corresponding to the presence of the neighboring user 1 on the network is not encrypted. Instead, the use of public and private keys is limited to verifying the identity of the user as a source of data. Although the data transmitted is written in clear text and can therefore be viewed, public key cryptography verifies the identity of the target user to whom the data is published.

As already mentioned above with reference to Figure 6, a richer set of data can be provided to the user once the identity of the user publishing the data is verified as an existing contact. , The display of PNM information to users is improved.

The above specifications, examples and data provide a complete description of the manufacture and use of the configurations of the present invention. The present invention falls within the scope of the appended claims, as many embodiments of the invention can be made without departing from the spirit and scope of the invention.

<figref num="1">It is a figure which shows the exemplary computing device which can be used according to the exemplary embodiment of the present invention.</figref><figref num="2">It is a figure which shows the alternative operating environment for the mobile device which is practically used in this invention.</figref><figref num="3">It is a figure which shows an exemplary sidebar in a desktop.</figref><figref num="4">It is a functional block diagram of a system for discovery and disclosure of neighborhood presence information on a network.</figref><figref num="5">Another functional block diagram of the system for discovering and disclosing neighborhood presence information on the network.</figref><figref num="6">It is a figure which shows the exemplary file structure corresponding to the file system for storing presence information.</figref><figref num="7">It is a figure which shows an exemplary sidebar tile related to presence disclosure and discovery of a neighbor user on a network.</figref><figref num="8">FIG. 5 shows an exemplary state table for implementing a user interface for publishing and discovering presence information on a network.</figref><figref num="9">It is a figure which shows the exemplary identification verification about the presence notification of the neighborhood user by this invention.</figref>