JP4681812B2 - Method and apparatus for storing and managing contacts in a distributed collaboration system - Google Patents

Description

  The present invention relates to distributed and peer-to-peer collaboration systems and to a method and apparatus for storing and managing contact information in such systems.

  Collaboration refers to the ability of each member in a group of members called “collaborators” to automatically send information to and receive information from other collaborators in the group. In order to facilitate such collaboration, various systems have been developed that allow such information to be transmitted between personal computer systems, communication devices, or other communication devices including handheld devices and wireless devices. It was. These devices will be collectively referred to herein as “computers”.

  Computer collaboration can be performed locally between users connected to or operating on a single computer or server. Alternatively, collaboration may occur over a network, for example over the Internet, in which case each user is located on a computer connected to the network. Servers are also connected to the network. Several collaboration models are currently being implemented as networked computer collaboration systems. One of these models is the client-server model, where all collaborators are connected to the central server via the network. The information generated by each collaborator is transmitted over the network to a server, which broadcasts the information to each other collaborator over the network. In one version of this system, data that is being changed by collaboration is stored centrally on the server. Next, each collaborator attempting to change the data sends a command to the server to cause the server data to be changed. Each collaborator can display the data locally by changing the copy of the data and sending information representing the “view” of the changed data to all collaborators.

  In addition to this, in a system using a server, a local data copy is held in each collaboration computer in addition to a data copy held in the server. Each collaborator who wants to change the data sends a command to the server to make changes to the server data. The server changes the data copy and then broadcasts the command to all collaborators. Each collaborator uses a command to update the local data copy. This local data copy is displayed locally. Examples of this model are Lotus Notes (registered trademark) and Lotus Sametime (registered trademark) sold by IBM in Armonk, New York, and Exchanges sold by Microsoft in Redmond, Washington. Is mentioned.

  Another collaboration model is the “peer-to-peer model”, where a direct connection is established over the network between each collaborating computer. Information generated by each collaborator is transmitted directly to each other collaborator. In such a system, collaborators communicate in a private “virtual” shared space created and maintained by the collaboration system. When the collaborator participates in the collaboration, the shared space attributes and information are “serialized” and then transmitted over the network to the new collaborator. When this information arrives, it is “deserialized” and used to create a shared space on the new collaborator's computer.

  A centralized data repository is not required in a peer-to-peer collaboration system because each collaborator has a local copy of the data that is modified by the collaboration. To change the data, the collaborator generates a data change request, or “delta”, and forwards it to each other collaborator. The incoming data change request is used by each collaborator to change his local data copy. An example of this type of collaboration system is the Groove Workspace collaboration system developed and sold by Groove Networks, Inc., 0190015 Beverly, Massachusetts, 100 Cummings Center, Suite 535Q. For details on this, refer to http: // www. groove. net. See also US Pat. No. 6,446,113B1.

  For the convenience of the user, all of the aforementioned collaboration systems have a provision for storing contact information. Contacts are people with whom users share a common interest and therefore need to communicate, and can be work colleagues, stakeholders, friends, and family members. Stored contact information (hereinafter referred to as contact information) generally includes information necessary to communicate with the contact by various means such as telephone or e-mail. The saved contact information eliminates the need for the user to store information or retrieves information from other information sources, thereby increasing the speed and convenience of the collaboration system.

  The information stored for each contact typically includes visual information that the contact has determined to share with other contacts, eg, by “vCard” or other distribution mechanism. However, contact information can be, for example, device information about the device used to contact the contact, relay server information, authentication information or verification information such as a digital signature, digital fingerprint, or an encryption key to enable confidential communication with the contact Non-visual information may also be included.

  Typically, contact information is maintained in a contact directory or contact list that can be searched and identified. Contact lists are referenced and maintained by many subsystems. For example, a contact list can be referenced by identity, contact list tool, shared space member subsystem, message store. All of these lists are stored in separate locations and maintained by separate subsystems. Because there are many different lists and thus many “sources” of contact information, it is difficult to distribute updates or keep all of the contact information up to date.

  For example, a change in contact information in the shared space needs to be propagated by a “contact change” delta sent to each member of the shared space. If the user is participating in many shared spaces, processing these deltas in all shared spaces can be a time consuming task. Further, if the same contact as the user participates in many shared spaces together, the contact will receive the same update of the user's contact information from each of the shared spaces.

  Similarly, instant messenger contact information is updated only when the user sends an instant message to the contact. As such, a user is not guaranteed to have the latest version of information for any contact. Not only will the user's visual information become obsolete, but the non-visual list of client devices or relays may change, making future communications impossible without updating contact information.

  In accordance with the principles of the present invention, each user stores all of the contact information in a local contact store to provide a single location for all of the contact information for that user. Each subsystem that maintains contact information, such as a shared space or contact list, i.e., serves as a "source" of contact information, stores only information identifying the contact in the contact store, such as a URL. Therefore, in order to keep the contact information up-to-date, it is only necessary to update the information in the contact store.

  To ensure that communication with the contact is not lost due to failure to receive contact communication information, the local contact store is updated with a two-way subscription using identity messages. More specifically, when adding information about a contact to a user's local contact store, a subscription request message is sent to the contact. The subscription request message includes the user's contact information and a request to add the user to the subscription list for that contact. Later, if the contact updates his or her contact information, the update information is automatically sent to each person on the subscription list. In order for a user to receive such future updates, the contact needs to maintain up-to-date contact information about the user. That is, the subscription must be “two-way” requiring the user to add the contact to the user's own subscription list and the contact automatically receive all updates for the user.

  In one embodiment, a contact may reject a request to add a user to his or her subscription list. In this case, the user does not add the contact to the user's own subscription list.

  In another embodiment, even if the recipient of the subscription request message does not have any source that requires the requesting contact information to be present in the recipient's contact store. The contact information within is added to the contact store as a “sourceless” contact, but this is only added to implement a two-way subscription.

  In yet another embodiment, a list of information sources about contacts is maintained in the contact store. If a new source requires that contact information be added to the contact store (eg, a user subscribes to a shared space that has that contact as a member), if the contact information already exists in the contact store, Information is not added to the contact store. Instead, the information in the contact store is updated and the contact source is added to the list (if the information from the new source is newer than the information in the contact store). Similarly, when a contact source is deleted (eg, when a user leaves the shared space with that contact as a member), the contact source is deleted from the list, but contact information is not deleted from the contact store. If the list is empty, the contact is a sourceless contact.

  In yet another embodiment, in order to prevent information about inactive sourceless contacts from accumulating in the contact store, contacts with each sourceless source are regularly contacted within a predetermined time limit. If there is no response, the contact information is deleted from the contact store.

  In another implementation, the subscription request may include only the name of the contact and not the complete “vCard” information. In this case, the flag “name only” is set in the vCard information so that only the selected information is transmitted to the subscriber during the contact information update.

  FIG. 1A is a schematic block diagram of a collaboration system 100, such as the previously described groove collaboration system. Although FIG. 1A shows three collaboration devices 102, 104, 106, these may be computers, PDAs, laptop computers, set-top boxes, web-viewable mobile phones or other communication devices. Only three collaboration devices are shown, but there are additional devices. When the groove software is loaded on the device, databases such as databases 108, 110, 112 are created on the devices 102, 104, 106, respectively. Each of these databases maintains a local copy of the data processed by the collaborator. As will be described later, the databases 108, 110, and 112 also hold information related to the operations of the collaboration apparatuses 102, 104, and 106.

  The collaboration software also creates transceivers such as transceivers 114, 116, 118, etc. on devices 102, 104, 106, respectively. Each transceiver is responsible for creating a data change request called a delta and transmitting it between collaborators as schematically shown by arrows 122, 124, 126. Typically, these data change requests are sent over the Internet 120 as illustrated in FIG. 1A, but can also be sent over another network, such as a LAN network. Data change requests are used for a number of purposes, such as adding and removing collaborators from the system, and updating local data copies at each collaboration device to synchronize data copies.

  In order to use the collaboration software described above, the user sets up one or more accounts. In general, an account corresponds to a user information file commonly found in other systems, such as an identity file. Each account includes information about the user, such as an email address and other ways to contact the user. Account information is encrypted and signed and stored in a database such as databases 108, 110, 112, etc. that is password protected and maintained by the collaboration system. Such a database 128 is illustrated in more detail in FIG. 1B.

  More particularly, the system database 128 includes an account database 130, which stores user private data regarding accounts. For example, a user may have multiple identities, such as a professional identity used in the office and a personal identity used with family and friends for the purpose of sharing images and vacation plans. The account data includes a list 134 of these identities, data for each identity, and a list of shared spaces associated with the account. The account database includes a separate data store associated with each shared space of which the user is a member, of which data stores 148, 150, 152 are shown. Data stores 148, 150, 152 may include local data copies associated with the shared space and other information associated with the shared space. Account database 130 further includes a contact store 140 that stores contact information for each identity in the account and contact information for other contacts. Finally, the account database also includes other information, such as a message store 154 that stores instant messages and invitations.

  Each identity data includes a private part 156 that is not publicly available and contact information that is a public part 158 that is publicly available. The private portion 156 includes a URL, etc., that uniquely identifies the identity, and an encryption / signature private key of the public / private key pair that the identity uses to encrypt and sign the message. Public contact information 158 includes a contact URL that uniquely identifies the contact, which is typically the same as the identity URL for that identity. The contact information also includes the contact sequence number. The sequence number is an integer that is set to zero when the contact is created. The contact sequence number is increased (hereinafter incremented) by a predetermined large number (for example, 1,000) when a new device is added to the contact information. The contact sequence number (hereinafter referred to as contact sequence number) is incremented by a predetermined small number (eg, 1) when the contact information is changed for some other reason (eg, the contact vCard information is updated). Note that since all contact information is signed with the identity's private key, only the identity that “owns” the contact information can update the information. Furthermore, contact information can only be updated by one of the account devices.

  The contact information further includes contact vCard information (personal and work data including name, phone number, facsimile number, email address, etc.). The vCard information also includes a bit “name only” for a vCard containing only the contact name. The contact information further includes a list of devices with an identity that “owns” the contact information, a list of relay devices, typically servers, and sensitive data. The confidential data can include the public key of the above-mentioned public key / private key pair, a key algorithm, and self-signed information.

  In accordance with the principles of the present invention, all contact information, including contact information for the identity associated with the account, is stored in a contact store illustrated in more detail in FIG.

  More particularly, contact store 200 has a set of contact store entries, of which entry 1 (202) and entry N (204) are shown. One skilled in the art will appreciate that a contact store can include one or more entries. Each contact store entry, eg, entry 202 contains contact information, etc., which includes contact URL 206, contact sequence number 208, contact vCard information 210, and an identity that “owns” the contact information. A device list 212, a relay device list 214, and public secret data 216 are included. The contact store entry also includes a list of sources 220 that is a list of URLs that identify the “owner” of the contact information for that entry. When a new source of contact information is added, the source is added to the source list 220, and when the source of contact information is deleted, it is deleted from the list 220. Contact information can be marked for deletion by a contact store entry deletion flag 221 as will be described later.

  In accordance with the principles of the present invention, the contact store entry (eg, contact store entry 202) corresponding to the identity of the account also includes a subscription list 218, described in more detail below. The subscription list 218 includes information about each device of the contact that subscribed to the contact URL identifying the contact being subscribed to and contact information in the contact store entry. As described below, list 218 is used to send contact update information to each device in the list when the contact information for that entry is changed. The devices on the list include all devices (except relay devices) that have subscribed to the contact information. Subscription list 218 includes a list of subscribed devices, including entries for each subscribed device, for each device that subscribed to contact information in the contact store entry, of which entries 222 and 224 are shown. Each subscribed device entry has a device URL 226 that uniquely identifies the device, a device status field 228, a name-only flag 230 indicating whether this device should receive a name-only version of the contact information associated with the identity, pin count Contains field 232 These fields will be described later.

  The device status field 228 of the subscribed device entry holds a device status number that identifies one of the six states in which the subscribed device is placed. The six types of device states and their definitions are as follows.

Status: Definition 1: One or more identities of the current account have a source of contact information for the contact, and the contact has contact information for one or more identities of the current account. Have a source.
2: One or more identities of the current account have a source of contact information for the contact, but the contact does not have a source of contact information for any identity of the current account.
3: No identity in the current account has a source of contact information for the contact, but the contact has a source of contact information for one or more identities of the current account.
4: No identity in the current account has a source of contact information for the contact, and the contact does not have a source of contact information for any identity in the current account.
5: One or more identities of the current account have a source of contact information about the contact, but the contact refuses a subscription request for contact information.
6: None of the identities in the current account have a source of contact information about the contact, and the contact refuses a subscription request for contact information.

  Six types of contact device states 300-310 are shown in FIG. FIG. 3 also illustrates the state transitions that occur due to the contact propagation message received by the user. The state transition and contact propagation message will be described in detail below.

  In the preferred embodiment, the account and contact store are implemented as XML documents stored in an encrypted XML object store, such as database 200. An exemplary format for these XML documents is shown below.

account
{identities}
identity_1
private signing key (for Identity 1)
private encryption key (for Identity 1)
identity_2
...
{spaces}
{contacts}
entry_1
contact information
URL
sequence number
vCard information
devices
relay servers
public key algorithms
public signing key
public encryption key
status word
subscriptions
subscription 1 contactURL
devices
device1 DeviceURL State NameOnly PingCount
device2 DeviceURL State NameOnly PingCount
...
subscription2 contactURL
...
sources
source_1 URL
source_2 URL
deleted flag
entry_2
...

  Contact Store 200 provides centralized (per account) storage for all contacts associated with an account, so copies of contacts are consumed in various locations such as personal contact lists, message stores, etc. Significantly reduce the amount of space to play. In addition, the contact store 200 provides a single point for updating any contact information. Furthermore, contact store 200 allows contact store clients to associate any data with any contact in the contact store. Changes to that data can optionally be distributed to all account devices. This arbitrary data can be used to add a comment to the contact or prevent spoofing of the contact.

  Contact store 200 is not an engine, but by another engine, such as an account engine or a shared space member engine, to distribute changes to any data associated with a contact to all of the devices associated with the account. A local storage that can be maintained. This distribution is done by obtaining a property list stored in the account store and associated with contacts in the contact store. This property list is provided by the property list provider for the contact. For example, the account engine can be such a provider. That is, contact information is stored locally, but related data can be transmitted transparently throughout the account device.

  In accordance with the principles of the present invention, all engines that have previously maintained a copy of contact information in their data stores (eg, message stores and member managers) are modified and stored in those data stores. The contact URL is stored instead of the complete contact information. The data store contains only a URL, but when the data created by the engine is serialized as part of shared space serialization for propagation to other shared space members, the contact URL in the data is used. Actual contact information is obtained from the contact store, and the contact information is included in the serialized data. Conversely, when deserializing data received from another shared space member as part of shared space deserialization, the contact information in the deserialized data is added to the contact store and associated. Only the contact URL stored in the shared space data store is stored.

  As previously mentioned, the contact store can be maintained by an existing engine, such as an account engine or a shared space member engine. The engine has the ability to update a contact in response to a message received from another user. These messages include the following message formats:

  Subscription request message—This message format requires the sender to be added to the recipient's subscription list in order to automatically receive updates of the recipient's identity and contact information. The subscription request message contains either the complete vCard information about the recipient or the vCard saying “only the name” of the recipient. In either case, for security purposes, this message contains sufficient information, such as a digital signature, for the recipient to verify and authenticate the sender.

  Request rejection message—This message is sent back to the sender of the subscription request message if the recipient of the subscription request message rejects the update request. Subscription requests can be rejected using a user interface screen that sets permissions.

  A message that the sender does not have a source of contact ── This message is sent to each device on the subscription list when contact information about the subscriber is removed from the contact store, and the sender is the subscriber Indicates that it has no other source of contact information.

  A message that the contact has been updated ── This message is sent to all contacts in the subscription list when the contact information for a given identity changes, causing the recipient to update the contact information about the sender. This message contains the sender's self-signature, and during the update, for security purposes, the message processing engine detects whether the self-signature has been verified. If the self-signature is not confirmed, the contact information is discarded and an error occurs.

  The message “Contact updated” also includes the sender's vCard information. If the only name bit for a contact in the subscription list is set, the vCard information includes only the sender's name and information sufficient to communicate with the contact for update purposes. The name only bit is set in the subscription list if the subscription request message to place a contact in the subscription list contains a vCard with only the name. Later, when the message sender contacts the recipient, he can receive the sender's complete vCard information, but to change the subscription list entry from the name-only vCard information to the complete vCard information, the recipient A new subscription request message containing complete vCard information needs to be sent. Changing the LAN / directory public mode to “name only” will not affect users who already have complete vCard information, but if the update is not the result of a notification message, all contact updates will be resubscribed. I need it.

  Device erasure message-This message is sent to all subscribed devices on the subscription list when the identity associated with the contact store entry that the subscription list is part of is permanently invalidated or when the device is erased. Sent to. The recipient of this message deletes the sender's device from the subscription list regardless of the previous subscription status.

  Ping message—This message is used to check if the recipient is still valid. To avoid storing contact information in the contact store for contact with no source that is no longer valid, the contact store periodically sends a ping message to each sourceless contact in the subscription list. Send. If there is no response to a predetermined number of pin messages, the contact without that source is marked for deletion. At this point, the contact information in the contact store corresponding to the subscriber device in the subscription list in state 4 or state 6 is deleted. Similarly, contact information corresponding to a subscriber who does not have a device is marked for deletion by setting a deletion flag 221. If the contact information is marked for deletion, the subscriber device is assumed to be in state 4.

  Pong message--This message is sent from the recipient of the message to the sender of the ping message, indicating that the recipient is still active.

  The processing performed by the contact store to maintain contact information will be described in detail with reference to FIGS. FIG. 4 illustrates the steps of an exemplary procedure for adding a new contact source to the identity contact store. This process is performed when the contact source is not internal and the contact information is not owned by one of the identities in the current account. Processing begins at step 400 and proceeds to step 402 where a determination is made as to whether a contact source already exists in the contact store. If the contact does not yet exist in the contact store, processing proceeds to step 404 where contact information is added to the contact store.

  Next, at step 408, all devices related to the contact are added to the subscription list associated with all of the identity's account identities. The value of the state variable for each added device is set to state 2. Next, at step 416, a subscription request message is sent by identity to each of the contact's devices that are adding information to the contact store, and the identity is added to the contact's subscription list, thereby making the subscription interactive. . The process ends at step 420.

  Otherwise, if it is determined in step 402 that information about the contact exists in the contact store, then processing proceeds to step 406 where any of the contact devices in the identity subscription list are in state 3 or state 4. Find out if it is. If no device is in either state 3 or state 4, the process ends at step 420. However, if it is determined that one or more devices are in either state 3 or state 4, processing proceeds to step 410 where the contact record is marked for deletion by checking the deletion flag. Determine whether it has been. If the contact record has been marked for deletion, at step 414 the contact record is unmarked for deletion (by resetting the deletion flag), and at step 418 all of the devices associated with the contact information are removed. Added to the identity subscription list and the value of the state variable is set to state 2. This operation corresponds to the state transition 328 between the state 306 and the state 302 as shown in FIG. The process ends at step 420.

  Otherwise, if it is determined at step 410 that the contact record is not marked for deletion, the value of the state variable for each device in the identity subscription list is changed from state 3 to state 1. This operation corresponds to the state transition 314 between the state 300 and the state 304 as shown in FIG. Next, at step 416, a subscription request message is sent by identity to each of the contact's devices that are adding information to the contact store, and the identity is added to the contact's subscription list, thereby making the subscription interactive. . The process ends at step 420.

  FIG. 5 illustrates an exemplary process performed by the contact store when the contact source is removed from the contact store. This process occurs when the contact source is not internal and the contact information is not one of the identities in the current account, starting at step 500 and proceeding to step 502 where the contact to be removed. A determination is made whether the information is the last source for this contact information in the contact store. If this contact information is not the last source, the process ends at step 514. Otherwise, if the contact information is the last source, the process proceeds to step 504 where it is determined whether all contact devices have been processed. If all devices have been processed, processing ends at step 514.

  Otherwise, if it is determined in step 504 that all contact devices have not been processed, the value of the state variable associated with the next device is set to state 1 or state 2 in step 506. Check to see if it shows. If the device is not in state 1 or state 2, processing returns to step 504 where it is checked if there are additional devices to process.

  If the next device is in state 1 or state 2, if it is determined in step 506, the process proceeds to step 508, where the message "Sender does not have a source of contact" is sent to the device. Sent to the associated contact. This message indicates that the contact has no source in the identity's contact store. If the contact information for an identity becomes sourceless in the contact store of the recipient contact, they can delete the other name from their subscription list and the other contact has been deleted in the contact store Can be marked as

  Next, at step 510, for all devices in state 1, the value of the state variable associated with the device is changed from 1 to 3 in the subscription list in all account identities. This operation corresponds to the state transition 312 from the state 300 to the state 304 in FIG. Next, at step 512, all devices in state 2 are removed from the identity subscription list. This operation corresponds to the state transition 316 from the state 302 to the state 306 in FIG. In addition, all devices in state 5 are removed from the identity subscription list. This operation corresponds to the state transition 330 from the state 308 to the state 310 in FIG. Processing ends at step 514. Note that when deleting each device, the processing shown in FIG. 7 and described later is executed.

  FIG. 6 illustrates an exemplary process performed by the contact store that notifies all subscribers when information in the contact store is updated. The process begins at step 600 and proceeds to step 602 where it is determined whether the contact information that is to be updated is held by one of the identities in the current account. If such contact information is being updated, in step 608, the message “Contact has been updated” is sent to all of the devices in states 1, 2, or 3 that are in the subscription list for the account. Send to. This notifies each subscriber that the contact information must be updated.

  In addition, in step 602, it is determined that a contact information change has been made to contact information that is not owned by the identity, and the process proceeds to step 604 where an update is received from another contact. It is determined whether or not it is due to a “contact update” message. If the update is the result of such an update message, the process ends at step 614.

  If the update is not the result of an incoming update message, then at step 606, whether the new contact sequence number is greater than the current sequence number recorded in the contact record in the contact store (or the new contact sequence number) If is equal to the current sequence number, the stored contact is different). If the new sequence number is not greater than the current sequence number or the stored contacts are different, the process ends at step 614. However, if the contacts stored with the new sequence number greater than the current sequence number are the same, in step 610, a subscription request message is sent to the contact requesting the update of contact information. At step 612, the message “Sender does not have a source of contacts” is sent to all devices in the contact's subscription list in state 3. Processing ends at step 614.

  FIG. 7 illustrates an exemplary process performed by the contact store when a contact device is removed from the subscription list. The process begins at step 700 and proceeds to step 702 where it is determined whether the deleted device was the last device associated with the contact and whether the contact is currently a source. If so, processing proceeds to step 704 where the associated contact is marked for deletion and processing ends at step 706. Otherwise, if the deleted device is not the last device associated with the contact, the process proceeds directly from step 702 to step 706 and ends.

  FIG. 8 shows an exemplary process performed by the contact store periodically, eg, one week after the last time point, to exclude sourceless contacts that are no longer active. The process begins at step 800 and proceeds to step 802 where each contact in the contact store is examined. If all contacts have been processed, processing ends at step 804. Otherwise, if there are more contacts to process, processing proceeds to step 806 where, for any contact, all devices associated with that contact in the subscription list are examined. In step 806, if there are no more devices in the subscription list to be processed, all devices in the subscription list associated with the contact have been processed, and the process returns to step 802 for processing. Check to see if there are any more contacts left.

  If it is determined in step 806 that there are more devices to process, processing proceeds to step 808 where the next device status is checked. If the next device is not in state 3, indicated by the value of the state variable associated with that device, processing returns to step 806 where a check is made to see if there are more devices to process. Otherwise, if it is determined in step 808 that the device being examined is in state 3, the process proceeds to step 810 where the pin count variable associated with the device is incremented. Next, in step 812, it is determined whether the incremented pin count variable value is greater than a predetermined limit, for example, four. If the value of the pin count variable is less than or equal to the predetermined limit, at step 816, a pin message is sent to the device. If the device is active, it returns a pong message upon receipt of the ping message. Processing returns to step 806 to see if further contacts need to be processed.

  However, if, at step 812, the pin count variable value exceeds the predetermined limit, then at step 814, the device is removed from the subscription list for all account identities. Processing returns to step 806 to check if there are any more contacts to process.

  9A and 9B illustrate an exemplary process performed by the contact store to process messages received from other contacts when collocated. The first step in this process is to check what kind of message has been received. This first step is illustrated in FIGS. 9A and 9B. Processing begins at step 900 and proceeds to step 902 where some initial checks are made to see if the message is a contact propagation message, that the sender's contact information has been successfully authenticated, and that the sender's signature is Verify that the sender matches any signature already on the file. If these initial checks fail, the process proceeds via interpage connections 926 and 930 and ends at step 938.

  In addition, if the initial check passes in step 902, the message is examined to determine the format of the received message. In step 904, a check is made to see if the message is a subscription request message. If so, the subscription request message routine processing 906 is executed.

  If the message is not a subscription request message, processing proceeds to step 908 where a check is made to see if the message is a request rejection message. If so, request rejection message routine processing 910 is executed.

  If the message is not a request rejection message, processing proceeds to step 912 where a check is made to see if the message is a message that the sender is no source of contact. If so, a no source message routine process 914 is performed.

  If the message is not a message that the sender is no source of contact, processing proceeds to step 916 where a check is made to see if the message is a contact updated message. If so, contact updated message routine processing 918 is performed.

  If the message is not a contact updated message, processing proceeds to step 920 where a check is made to see if the message is a pin message. If so, the pin message routine process 922 is executed.

  If the message is not a ping message, processing proceeds to step 932 through interpage connections 924 and 928, where it checks to see if the message is a pon message. If so, the Pong message routine process 934 is executed.

  Finally, if the message is not a Pong message, it should be a device delete message, so device delete message routine processing 936 is performed. In either case, processing ends at step 938.

  The subscription request message subroutine 906 process is illustrated in more detail in FIG. This process begins at step 1000 and proceeds to step 1002, where it is checked whether the requester is permitted to subscribe. As described above, a user interface selection can be provided to set permissions for subscription renewals for the identity information of the owner. These permissions are checked at step 1002 to see if the message sender has permission to subscribe to contact information updates.

  If the permission prevents the sender from subscribing to the update, the sender's contact information is removed from the message recipient's contact store at step 1004 and a request rejection message is sent to the message sender at step 1010. The subroutine returns to step 1022.

  Otherwise, if the sender allows the subscription by permission as determined in step 1002, the process proceeds to step 1006 where a determination is made as to whether the sender's contact information exists in the recipient's contact store. I do. If the contact information is not in the contact store, at step 1008, the contact information is added to the contact store. Processing then proceeds to step 1020 where the sender's device is added to the recipient's subscription list and the state variable is set to state 3. The subroutine returns to step 1022.

  If it is determined at step 1006 that the contact information already exists in the recipient's contact store, at step 1012 a check is made to see if the contact is marked for deletion. If so, at step 1016, the contact record is unmarked for deletion and processing proceeds to step 1020 where the sender's device is added to the recipient's subscription list and the value of the state variable is set to state 3. The subroutine returns to step 1022. This operation corresponds to the transition 318 from the state 4 (306) to the state 3 (304) shown in FIG.

  Otherwise, if it is determined in step 1012 that the contact has not been marked for deletion, processing proceeds to step 1014 where all account identities are in the subscription list corresponding to the sender's contact device. The value of the variable is changed from 2 to 1 or from 5 to 1. These operations correspond to the state transition 325 from the state 302 to the state 300 and the state transition 322 from the state 308 to the state 300, respectively. Next, at step 1018, the sender's device pin counter is set to zero for all account identities. The subroutine then returns to step 1022.

  The request rejection message processing subroutine 910 is illustrated in more detail in FIG. The process begins at step 1100 and proceeds to step 1102 where a determination is made as to whether the message sender's contact information exists in the recipient's contact store. If this information does not exist in the contact store, the subroutine returns to step 1106.

  Otherwise, if it is determined in step 1102 that the sender's contact information is present in the contact store, the entire sender's device is processed with each of the account identities. First, in step 1104, a check is made to see if there are still device records to be processed for the sender. If there remains a device record to be processed, a check is made at step 1108 to see if the value of the state variable in the next device record to be processed is 1 or 2. If the value of the state variable is 1 or 2, the process proceeds to step 1110 where the value of the state variable in the sender's device record in the recipient's subscription list for all account identities is changed to 5. This operation corresponds to the state transition 324 from the state 300 to the state 308 and the state transition 326 from the state 302 to the state 308 in FIG.

  Otherwise, if the value of the state variable in the sender's device record is not 1 or 2, in step 1112, a check is made to see if the value of the state variable is 3. If the value is not 3, processing returns to step 1104 to see if there are more device records to process. However, if the value of the state variable is 3, step 1114 deletes device records for all account identities. This operation corresponds to the state transition 332 from the state 304 to the state 310 in FIG. The process returns to step 1104 to check whether there is a device record to be further processed. When all the records have been processed, the subroutine returns to step 1106.

  The no source message processing subroutine 914 is illustrated in more detail in FIG. The process begins at step 1200 and proceeds to step 1202 where it checks whether the contact information of the message sender is present in the recipient's contact store. If the information does not exist in the contact store, the subroutine returns to step 1206.

  Alternatively, if it is determined in step 1202 that the sender's contact information exists in the contact store, the entire sender's device is processed with each of the account identities. First, in step 1204, a check is made to see if there is still a device record on the sender side to be processed. If there is a device record to be processed, a check is made at step 1208 to check whether the value of the state variable of the next device record to be processed is 1. If the value of the state variable is 1, the process proceeds to step 1210 where the value of the state variable is changed to 2 in the sender's device record in the recipient's subscription list for all account identities. This operation corresponds to the state transition 323 from the state 300 to the state 302 in FIG.

  Otherwise, if the state variable value is not 1 in the sender's device record, in step 1212 a check is made to see if the state variable value is 3. If the value is not 3, the process returns to step 1204 to check whether there are more device records to be processed. However, if the value of the state variable is 3, in step 1214, device records are deleted for all account identities. This operation corresponds to the state transition 320 from the state 304 to the state 306 in FIG. The process returns to step 1204 to check whether there are more device records to be processed. When all records have been processed, the subroutine returns to step 1206.

  The contact updated message processing subroutine 918 is illustrated in more detail in FIG. The process begins at step 1300 and proceeds to step 1302, where it checks whether the contact information of the message sender is present in the recipient's contact store. If this information does not exist in the contact store, the subroutine returns to step 1310.

  In addition, if it is determined in step 1302 that the sender's contact information exists in the contact store, then in step 1304, it is checked whether the sender's contact sequence number has been changed. If this sequence number has been changed, the sender's contact information in the recipient's contact store is updated at step 1306 and processing proceeds to step 1308. However, if this sequence number has not been changed, the process proceeds directly to step 1308.

  At step 1308, the pin counter of the sender's device in the subscription list for all account identities is set to zero. The subroutine returns to step 1310.

  The pin message processing subroutine 922 is illustrated in more detail in FIG. The process begins at step 1400 and proceeds to step 1402, where it checks whether the contact information of the message sender exists in the recipient's contact store. If this information does not exist in the contact store, the subroutine returns to step 1408.

  Otherwise, if it is determined in step 1302 that the sender's contact information exists in the contact store, then in step 1304, the sender's device record is checked to see if the value of its state variable is 2. If the value of the state variable is 2, a pong message is returned to the sender. If the device record is not in state 2, the subroutine returns to step 1408.

  Pong message processing subroutine 924 is illustrated in more detail in FIG. The process begins at step 1500 and proceeds to step 1502, where it checks whether the contact information of the message sender exists in the recipient's contact store. If this information does not exist in the contact store, the subroutine returns to step 1512.

  If the information is present in the recipient's contact store, a check is made at step 1504 to see if the contact is marked for deletion. If so, at step 1506, the contact record is unmarked and processing proceeds to step 1508 where the sender's device is added to the recipient's subscription list for all account identities and the value of the state variable. Is set to state 3. This operation corresponds to the state transition 318 from state 4 (306) to state 3 (304) shown in FIG. Otherwise, if it is determined in step 1510 that the contact has not been marked for deletion, processing proceeds directly to step 1510.

  Next, in step 1510, the pin counter is set to zero in the sender's device record for all account identities. The subroutine ends in step 1512.

  The device deletion message processing subroutine 936 is illustrated in more detail in FIG. The process begins at step 1600 and proceeds to step 1602, where it checks whether the contact information of the message sender is present in the recipient's contact store. If this information does not exist in the contact store, the subroutine returns to step 1610.

  Otherwise, if it is determined in step 1602 that the sender's contact information exists in the contact store, then step 1604 checks to see if all identities in the current account have been processed. If so, the process ends at step 1610. If not, at step 1606, a subscription list associated with the message sender is obtained, and at step 1608, the device described in the message is deleted from the subscription list. Processing returns to step 1604 to see if all identities have been processed. If all identities have been processed, processing ends at step 1610.

  The other two processes are used to maintain the contact store. These processes are performed when the account is imported to another device and when the account is deleted from the device. The first process is illustrated in FIG. 17 and begins at step 1700 when the account is imported to another device. The process proceeds to step 1702, where all contact store entries in the contact store for that account are examined. If there remains an entry to be processed as determined in step 1702, then in step 1706, the next entry is selected for processing. In step 1708, the entry list is examined to see if the entry is for a no-source contact. If the contact has no source as determined at step 1708, all devices on the subscription list for that contact are processed. More specifically, it is checked in step 1710 whether all devices have been processed. If not, step 1714 selects the next device to process. In step 1718, a “subscription request” message is sent to the selected device. In step 1722, a message “The sender has no source of contact” is sent to the selected device. Processing returns to step 1710 to check if all devices have been processed. If all devices have been processed as determined at step 1710, processing returns to step 1702 to see if all contact store entries have been processed. Once all entries have been processed as determined at step 1702, the process ends at step 1704.

  Returning to step 1708, if the contact is not sourceless as determined in step 1708, processing proceeds to step 1712 where the entry is for a contact owned by an identity in the account. Check out. If the contact information is owned by the identity, processing returns to step 1702 to see if all entries have been processed.

  In addition, if it is determined in step 1712 that the contact information is not owned by the identity, all devices on the subscription list for that contact are processed. More specifically, step 1716 checks whether all devices have been processed. If not, step 1720 selects the next device for processing. In step 1724, a “subscription request” message is sent to the selected device. Processing returns to step 1716 to check if all devices have been processed. Once all devices have been processed as determined at step 1716, processing returns to step 1702 to see if all contact store entries have been processed.

  The processing performed when an account is deleted from the device is illustrated in FIGS. 18A and 18B. The process begins at step 1800 and proceeds to step 1802, where it is examined whether all entries in the account's contact store have been processed. If all entries have not been processed as determined in step 1802, the next unprocessed entry is selected in step 1806. Next, step 1808 checks to see if the entry is owned by one of the identities associated with the account. If not, the process returns to step 1802 to check whether all entries have been processed. Otherwise, if step 1808 determines that the entry is owned by the identity, step 1810 checks to see if all subscription lists for that entry have been processed. If the entire list has not been processed as determined at step 1810, then at step 1812, the next unprocessed list is selected for processing.

  Next, in step 1814, it is checked whether all subscribers of the selected list have been processed. If not, select the next outstanding subscriber in the list. Processing proceeds to step 1826 via inter-page connections 1820 and 1824, where it is determined whether all devices have been processed for the selected subscriber by examining the device list in the subscriber entry. If not, in step 1828, the next unprocessed device is selected. Step 1830 checks to see if the selected device is in state 1, 2 or 3. If not, the process returns to step 1826 to check whether there are any more devices to be processed.

  In addition, if it is determined in step 1830 that the selected device is in one of states 1, 2, or 3, a “device deletion” message is sent to the selected device in step 1832. Send. Processing returns to step 1826 to see if there are any more devices to process. Once all devices have been processed, as determined at step 1826, processing returns to step 1814 via interpage connections 1822 and 1818 to see if there are more subscribers to be processed in the selected list. If all the subscribers have been processed as determined in step 1814, the process returns to step 1810 to check whether there is still a subscription list to be processed.

  Once all subscription lists have been processed as determined at step 1810, the process returns to step 1802 to see if there are any more entries to process. If it is determined in step 1802 that all entries have been processed, processing ends in step 1804.

  A software implementation of the foregoing embodiments may be fixed on a tangible medium such as a computer readable medium such as a diskette, CD-ROM, ROM memory, or fixed disk, or a modem or other interface on the medium. Contains a series of computer instructions that can be transferred to the computer system via the device. The medium may be a tangible medium including but not limited to optical or analog communication lines, or implemented in wireless technology including but not limited to microwave, infrared or other transmission technologies. The medium can also be the Internet. The series of computer instructions implements all or part of the functionality previously described herein with respect to the present invention. Those skilled in the art will appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, including but not limited to current or future semiconductor, magnetic, optical or other memory devices, or current or future light, infrared, microwave, Alternatively, transmission may be performed using any communication technology including but not limited to other transmission technologies. Such computer program products are distributed on removable media with printed or digitized documents, for example as shrink wrap software, installed in computer systems such as system ROM or fixed disk, or server or electronic It is intended that it can be distributed from the bulletin board on the network, for example, on the Internet or the World Wide Web.

  While exemplary embodiments of the present invention have been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made to realize some of the advantages of the present invention without departing from the spirit and scope of the invention. I will. For example, it will be apparent to those skilled in the art that other implementations may perform different protocols and transformations than those shown. Other aspects, such as, for example, a particular process flow, the order of steps shown, and other modifications to the inventive concepts are intended to be encompassed by the appended claims.

FIG. 1A is a schematic block diagram of a prior art distributed collaboration system. FIG. 1B is a more detailed block diagram of a system database in one of the collaborator computers of FIG. 1A. FIG. 2 is a more detailed block diagram of the database account store illustrated in FIG. 1B. FIG. 3 is a state diagram showing transitions between various states of contact device records in the subscription list and states caused by various operations. FIG. 4 is a flowchart illustrating exemplary process steps for adding contact information to a contact store. FIG. 5 is a flow chart illustrating steps of an exemplary process for removing contact information from the contact store. FIG. 6 is a flowchart illustrating exemplary process steps for updating contact information in a contact store. FIG. 7 is a flowchart illustrating exemplary process steps for deleting a contact device from a subscription list. FIG. 8 is a flowchart illustrating exemplary process steps for performing periodic checks to determine if a sourceless contact is still valid. FIG. 9A and FIG. 9B constitute a flowchart illustrating exemplary processing steps for processing a contact propagation message received from a contact when juxtaposed. FIG. 10 is a flowchart illustrating the steps of an exemplary subroutine for processing a subscription request message. FIG. 11 is a flowchart illustrating the steps of an exemplary subroutine for processing a request rejection message. FIG. 12 is a flowchart illustrating the steps of an exemplary subroutine for processing a message that the sender has no source. FIG. 13 is a flow chart showing the steps of an exemplary subroutine for processing a message saying contact updated. FIG. 14 is a flowchart illustrating the steps of an exemplary subroutine for processing a ping message. FIG. 15 is a flowchart illustrating the steps of an exemplary subroutine for processing a pong message. FIG. 16 is a flowchart illustrating the steps of an exemplary subroutine for processing a device erase message. FIG. 17 is a flowchart illustrating the steps of an exemplary subroutine for processing a contact store entry when an account is imported into the device. 18A and 18B are flowcharts illustrating exemplary processing that is performed when an account is deleted from a device when juxtaposed.

Claims (20)

A computer-implemented method for causing a collaboration computer to perform each step when the collaboration computer is executed, the method comprising a plurality of collaboration computers connected by a network, each collaboration computer comprising: A local data store, the local data store having a plurality of entries, each of the entries storing information about other collaboration computers, wherein the collaboration computer A method for storing and managing contact information in a distributed collaboration system characterized by exchanging data change requests to keep the data store synchronized, comprising:
(A) when contact information for a contact is received at a collaboration computer, the contact information and a unique contact reference are associated with a single contact in the local data store associated with the collaboration computer. a storing in the store, the contact information for each contact in said single contact store, the steps identified by unique contact reference,
(B) storing the contact reference in each of a plurality of entries instead of the contact information;
(C) When an output data change request is generated by the collaboration computer, it uses the unique contact reference from the local data store to retrieve contact information from the single contact store. the method comprising responsible to extract the data change request that is the output is a step including contact information
A method comprising the steps of: 2. The method according to claim 1, further comprising the step of: (d) transmitting a message requesting update of the contact information to the contact when the contact information about the contact is received from the contact by the collaboration computer. the method of. The method of claim 2, wherein each collaboration computer has an identity for at least one account corresponding to a user of the collaboration computer.
(E) The method of claim 2, wherein the further comprising the steps of placing the contact information for the identity in the contact store.   The method of claim 3, wherein the message includes the contact information for the identity. (F) further comprising, upon receipt of the message, the contact stores the contact information for the identity in a contact store in the local data store associated with a collaboration computer used by the contact. The method according to claim 4. (G) storing said contact information to said contact in a store when the received contact information from the first source,
(H) a step of creating a list of sources of the contact information in the storage and contact the information,
(I) a step of adding the source to the list of sources when received in collaboration computer from a different second source is said contact information the first source,
(J) and further comprising the step of removing the source from the list of the sources of the first and request the removal of one contact information from a second source when received by the collaboration computer The method according to claim 5. (K) from the contact store in the local data store where the list of sources is empty and the contact information for the identity is associated with a collaboration computer used by the contact The method of claim 6, further comprising the step of deleting the contact information from the contact store when deleted. Each collaboration computer has at least one account area in the local data store associated therewith, and step (a) includes: (a1) the contact information and a unique contact reference in the account area; The method of claim 1 including the step of storing: And (d) of claim 1, in response to a message received from the collaboration computer, characterized in that it further comprises a step of deleting to update the contact information. The method of claim 9, wherein the contact information has a state associated therewith, and step (d) includes the step of changing the state in response to the message. An apparatus for causing a collaboration computer to execute each means when the collaboration computer is executed. The apparatus includes a plurality of collaboration computers connected by a network, and each collaboration computer is a local computer. A data store, wherein said local data store has a plurality of entries, each of said entries storing information about other collaboration computers, said collaboration computer comprising said local data store An apparatus for storing and managing contact information in a distributed collaboration system characterized by exchanging data change requests to keep the store synchronized,
Operates when contact information about a contact is received at a collaboration computer and displays the contact information and a unique contact reference in a single contact store within the local data store associated with the collaboration computer. storage and contact information for each contact in said single contact store includes means for being identified by a unique contact reference,
Means for storing the contact reference in each of the plurality of entries instead of the contact information;
Using the local data store, the collaboration computer generates an output data change request and uses the unique contact reference in the local data store to generate the single contact Means for retrieving contact information from the store and storing the contact information in the output data change request. 12. A means for operating upon receiving contact information about a contact from a contact at a collaboration computer, further comprising means for sending a message requesting an update of the contact information to the contact. The device described in 1. 13. The apparatus of claim 12, wherein each collaboration computer has an identity for at least one account corresponding to a user of the collaboration computer, wherein the apparatus is in the contact store. The apparatus of claim 12, further comprising: means for locating contact information about the identity.   The apparatus of claim 13, wherein the message includes the contact information for the identity. The identity for the identity in a contact store in the local data store that operates when receiving a message at a collaboration computer used by the contact and is associated with the collaboration computer used by the contact The apparatus of claim 14, further comprising means for storing contact information. Means for storing the contact information in the contact store when receiving contact information from a first source;
Means for creating a list of sources of the contact information in the stored contact information;
Means for adding a source to the list of sources when the contact information is received at a collaboration computer from a second source different from the first source;
Means for removing a source from the list of sources when a request to remove contact information from one of the first and second sources is received at the collaboration computer;
The apparatus of claim 15 further comprising: The list of sources is emptied and the contact information for the identity has been deleted from the contact store in the local data store associated with the collaboration computer used by the contact The apparatus of claim 16, further comprising means for sometimes deleting the contact information from the contact store. Each collaboration computer has at least one account area in the local data store associated with it and stores the contact information and a unique contact reference in a single contact store The apparatus of claim 11, wherein the means for storing includes means for storing the contact information and a unique contact reference in the account area. The apparatus of claim 11, further comprising means for updating and deleting the contact information in response to a message received from the collaboration computer. The contact information has a state associated therewith, and the means for updating and deleting the contact information includes means for changing the state in response to the message. The apparatus of claim 19.

Images