Source: https://insight.rpxcorp.com/pat/US7461071B2
Timestamp: 2020-04-02 12:56:03
Document Index: 799265891

Matched Legal Cases: ['art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300']

Patent US 7,461,071 B2
US 20110321119A1
US 8,726,335 B2
CONTACT DATA SHARING
US 20140372375A1
Mrinal Desai, Jorge Ferreira
US 20150128289A1
Vintela Incorporated
US 20040088695A1
creating attribute transactions;
sending the attribute transactions changes to destinations associated with the grantees.
Because the timestamps play an important role in the synchronization process, clocks in the devices may need to be accurate, aligned with one another, and unchanged. This is not always the case in, for example, mobile devices. Indeed, it is quite common for the user of a mobile device to travel to another time zone and therefore, change the time on the device'"'"'s clock. This can cause problems with synchronization. In some cases, problems with timestamps can cause devices to ignore changes in the synchronization effort, effectively losing the change.
The mobile devices 108 may include various hardware and/or software components, as described later with reference to FIGS. 7 and 8. Indeed, the clients 106 could be mobile devices. However, for illustrative purposes, the mobile devices 108 synch with the client 110 in a manner that is known in the computer arts. For example, the mobile device 108-1 may be by way of example but not limitation a mobile phone, and the mobile device 108-2 may be by way of example but not limitation a PDA, both of which can synch with, by way of example but not limitation, a Mac OS X Address Book on a user'"'"'s computer (e.g., the client 110) through an iSync mechanism, which is known in the computer arts. The client 110 would then update local databases based upon the results of the iSync. Comparable technologies exist for various AB types and various operating systems.
In operation, a subscriber executes the YouInstallWizard 222 to connect to a server, such as the server 102 (FIG. 1) to obtain, by way of example but not limitation, a UID. Alternatively, the YouInstallWizard 222 may be executed automatically when the address book 214 is updated, or in response to some other stimulus. The subscriber may also use the YouInstallWizard 222 to set up local files on the computer 210, assuming the platform allows for local files. Alternatively, the YouInstallWizard 222 may perform some or all of the requisite or desired configurations automatically or in response to some other stimulus. The subscriber may also use the YouInstallWizard 222 to get user data associated with those who have allowed for us to update our records in their databases. Alternatively, the YouInstallWizard 222 may obtain the data automatically or in response to some other stimulus. The subscriber may or may not use a GUI associated with the YouInstallWizard 222 to enter some or all of the requisite information. In an embodiment, the YouInstallWizard 222 gets a new UID and sets up local files on a client device (if the platform allows for local files). The YouInstallWizard 222 also gets users (if any) that have allowed for the subscriber to update the subscriber'"'"'s records in the users'"'"' address books.
In a non-limiting embodiment, a function of the YouServer module 334 is to respond to requests from clients, such as the client 210 (FIG. 2). The YouServer module 334 may make use of, by way of example but not limitation, an SQL database to keep track of subscribers, permissions, and pending transactions. The YouServer database 332 may or may not include the SQL database. Requests from clients may include by way of example but not limitation requests to set/change permissions of who gets copies of changes in a subscriber'"'"'s ‘me’ record, get a user-id (UID) for a new subscriber, get the UIDs of users who have given permission to a subscriber to update records associated with the subscriber in the users'"'"' address books, receive and process data transaction requests (e.g., a Me engine detects a change in a ‘me’ record and sends it to the server if permissions are appropriately set and the server checks the permissions and puts <pushData> transactions in a transaction log), receive and process <awake> transactions from clients (e.g., a client may send periodic <awake> transactions to see if there is any new <pushData> available), and responding to a client'"'"'s <awake> transaction with <pushData> if there is new data. The <awake> and <pushData> transactions are described later with reference to the example of FIGS. 5A and 5B.
In an embodiment, the YouNIQ engine 524 includes a GUI that facilitates a subscriber setting permissions. The permissions settings control what information the subscriber will share with other users. For example, if a user has permission to see the subscriber'"'"'s home email information, the user will get the current value of the subscriber'"'"'s home email when the permissions are appropriately set. Moreover, in another embodiment, the YouNIQ engine 524 may forward to users with permission any changes the subscriber makes to the home email over time. Notably, the YouNIQ engine 524 facilitates updating the subscriber'"'"'s information in the users'"'"' local address books. In another embodiment, templates and/or defaults facilitate the setting of permissions by the subscriber without requiring the subscriber set individual fields. For example, a database may include information related to fields and use templates to provide updates of relevant fields.
In an embodiment, the me engine 526 detects updates to a subscriber'"'"'s contact information on the subscriber'"'"'s local machine. The me engine 526 sends the updates on to a server, which in turn may send the updates as <pushData> transactions on to users with permission to receive the updates.
In an embodiment, the YouClient engine 528 also handles <pushData> transactions from the server and updates a user'"'"'s address book 514. For example, if a user has given a subscriber access to the subscriber'"'"'s record in the user'"'"'s address book, the YouClient engine 528 on the user'"'"'s client device can update the subscriber'"'"'s record in the user'"'"'s address book when the subscriber updates local information. Conceptually, if a subscriber is given permission by a user, the subscriber can reach into the user'"'"'s address book to change data associated with the subscriber.
In the example of FIG. 5A, the Me engine 526 is responsible for watching the fields of a subscriber'"'"'s ‘me’ record. Examples of fields of the ‘me’ record are described in more detail below with reference to FIG. 6. If the Me engine 526 detects a change to a field in the ‘me’ record, then the Me engine 526 generates the <setData> transaction 572-1. In an embodiment, the Me engine 526 only generates the <setData> transaction 572-1 if the subscriber has given permission for another user (or users) to see the updated field.
In the example of FIG. 5B, at approximately the same time as the YouServer log engine 554 records the update data associated with the <pushData> transaction 575, the YouServer log engine 554 generates a <pushDataChk> transaction 574-1 and sends the transaction 574 to itself. The <pushDataChk> transaction 576 is similar to the <setDataChk> transaction 573 discussed previously except that the <pushDataChk> transaction 576 terminates or times out when the YouServer log engine 554 receives information that the data was successfully pushed to a client. Conceptually, the YouServer log engine 554 tells itself that it just did a <pushData> transaction to a client so it should wait a while and make sure that the client replied that it received the <pushData> transaction. If the client does not reply, then the YouServer log engine 554 may or may not make a note of it. In an embodiment wherein the YouServer log engine 554 is behind a firewall, the above-described implementation works in various embodiments. However, it should be noted that the <pushDataChk> transaction 576 may not be particularly useful unless the YouServer 534 is actively pushing data, as opposed to simply responding to a client. As one of skill in the art of firewalls would be aware, the server may only be able to respond to client requests if the server is separated from the client by a firewall. Accordingly, in an embodiment, the <pushDataChk> transaction 576 would typically be used if the server and client were both deployed behind an organization'"'"'s firewall. It may be noted that the Me engine 526 may also generate a <pushDataChk> transaction 576-1, which may be consumed by the YouServer log engine 554 as described previously.
In the example of FIG. 10, three examples of transactions are associated with the permissions engine 1020: get permissions API 1022, update permissions API 1024, and request sync API 1026. This group of APIs handles the management of a user'"'"'s permissions. Permissions allow or disallow the sharing of data with other users. The get permissions API 1022 may include userid (uid) and deviceid parameters, and return a result with 0 . . . n permissions items. These permission items can be taken from the permissions table 1108. The update permissions API 1024 may include the parameters uid, deviceid, grantee id (gid), perm {field}, value {field}. The perm {field} has a value of ‘1’ if permission is granted, and ‘0’ if permission is not granted. This API should result in an entry in the permissions table 1108. It should be noted that there could be multiple levels of permissions other than just ‘0’ or ‘1’. In any given implementation, any convenient number of permission levels could be used. The request sync API 1026 may include uid and device id parameters. This API may be used to sync data to a destination that might not have a full set of shared data. The server will handle where to get the data from and the results will be passed to the new destination.
In the example of FIG. 10, three examples of transactions are associated with the personal attributes engine 1050: destination store change API 1052, confirm destination store change API 1054, and request PAR data API 1056. This group of commands handles the management of a user'"'"'s data values. These live within what is called a personal attribute record (PAR). The destination store change API 1052 may include the parameters uid, deviceid, and value {field id}. In an embodiment, multiple sets of {field id} data may be passed in a single set of parameters to the server. The server should be capable of creating an entry for the transaction table 1114. The confirm destination change API 1054 may include the parameters uid and deviceid, and has predictable results. The request for PAR data API 1056 may include the parameters uid, deviceid, and field {field id}. In an embodiment, multiple sets of {field id} data may be passed in a single set of parameters. In addition, if no sets of {field id} are passed, the server may initiate requests for all fields. This API should result in an entry in the transaction table 1114. Advantageously, the server can be asked to resend all data sent to a client, allowing repopulation of a PIM or destination store. In an embodiment, this is accomplished using a transaction history log to determine what information has been provided in the past.
Returning once again to decision point 1304, if it is determined that the user is a new user (1304-Y), then the flowchart 1300 continues to module 1316 where the client is prompted for new credentials and destination information. The flowchart 1300 continues to module 1318 where the server verifies the new credentials and destination information are valid. The flowchart 1300 continues to decision point 1320 where it is determined whether the new credentials and destination information are valid. If it is determined that the new credentials and destination information are not valid (1320-N), then the flowchart continues to decision point 1322 where it is determined whether the client intends to work offline (if not, the flowchart 1300 continues to module 1316 as described previously; if so, the flowchart 1300 continues to module 1314 as described previously). If it is determined that the new credentials and destination information are valid (1320-Y), then the flowchart 1300 continues to module 1326 where the user is added to the server'"'"'s user table, to module 1328 where the server returns UID and Device ID, to module 1330 where the client writes the data to PAR, and to module 1314, which was described previously.
In the example of FIG. 17, the grantor 1706 has presumably granted permission to some or all of the grantor'"'"'s personal attributes to the grantees 1708. The permissions are stored in the permissions database 1712. In an embodiment, the server 1702 does not include any of the personal attributes. Advantageously, this reduces the burden on the server 1702 to store large amounts of data. Also, since the server 1702 in this embodiment does not include personal data, data mining at the server (either through hacking or more legitimate means) can be less harmful.
In the example of FIG. 17, in operation, the requestor 1710 asks for permission to access some or all of the grantor'"'"'s personal attributes. Alternatively, the grantor may choose to share with the grantee (e.g., without receiving a request). The grantor 1706 or an agent of the grantor 1706 may grant permission (or permission may be granted automatically for public data, or permission may be granted in advance). Once the requestor 1710 has been granted permission, the server 1702 will attempt to obtain the information on behalf of the requester 1710. However, the personal attributes database 1716 may or may not be available. For example, the grantor 1706 may have turned off the machine on which the personal attributes database 1716 is stored, or may have lost connectivity, or the personal attributes database 1716 may not be accessible for some other reason. Advantageously, the server 1702 can access the permissions database 1712 to determine which grantee has been given permission to which information. Since the server 1702 knows which grantee has been given permission to which information, the server 1702 can facilitate providing the requester 1710 with the information from the granted personal attributes database 1718. In some cases, such as when a person switches off a computer with personal attributes and goes on vacation, the system 1700 can provide the requestor 1710 with requested data in a matter of minutes, instead days or even months.
Advantageously, a user who loses data can repopulate the data using this technique. For example, if a user'"'"'s email program became corrupted or otherwise lost data, the user would be able to reinstall and repopulate. The user could even repopulate personal data so long as another user or device had access to the data. In addition, a user who begins using a new device, but who does not have access to another device with personal data stored thereon, can populate the new device using this technique. Users who attempt to change data that was received from another user might be doing so unintentionally. Such users could receive a warning that they are changing data that is controlled by another user (and asked whether they really want to change the data).
It should be borne in mind, however, that these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system'"'"'s registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
Fitzpatrick, Mark, Siress, Anthony
707/10, 707/9, 717/168, 709/206, 713/201, 455/412.2