Source: http://www.freepatentsonline.com/y2014/0181148.html
Timestamp: 2020-02-21 07:26:56
Document Index: 7900728

Matched Legal Cases: ['Application No. 60', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500']

Distributed Management Framework for Personal Attributes - YOUnite, Inc.
United States Patent Application 20140181148
Fitzpatrick, Mark (San Mateo, CA, US)
Siress, Anthony (Mountain View, CA, US)
14/092741
YOUnite, Inc. (Mountain View, CA, US)
Download PDF 20140181148 PDF help
1. A method, comprising: maintaining first attributes associated with a first entity of a plurality of entities and second attributes associated with a second entity of the plurality of entities; linking the first entity with a second entity; providing a first destination, associated with the first entity, for the second attributes; granting first permissions for the first attributes to the second entity; facilitating propagation of shared attributes of the first attributes and the second attributes to the first destination and a second destination associated with the second entity through the first permissions and second permissions for the second attributes to the first entity; managing subsequent changes of attributes to create a syndicated distributed secure data exchange.
2. The method of claim 1, further comprising: reading user ID and device ID from a local cache; if permissions are not stored locally, calling a server method to request permissions for the user ID; if permissions are stored locally, reading permissions from a local file.
3. The method of claim 1, further comprising: calling a server method to request a personal attribute record (PAR) if the PAR is stored remotely; reading the PAR from a local file if the PAR is stored locally.
4. The method of claim 1, further comprising: getting transactions by either requesting pending, transactions from a server or waiting or the server to send the transactions.
5. The method of claim 1, further comprising: selecting one or more grantees from a contact list; enabling attribute permissions for selected contacts; calling a server method to update permission settings on a server.
6. The method of claim 1, further comprising: updating a permissions table as specified by a grantor; for each new device owned by the grantor, sending new permission settings; for each device owned by a grantee, sending new attribute values; if the grantor is granting permission, sending the attribute value sent in an update permissions call; if the grantor is taking away permissions, sending a null value.
7. The method of claim 1, further comprising: selecting from a permissions table grantees for attributes of a grantor; joining grantees with the attribute changes; creating attribute transactions; sending the attribute transactions changes to destinations associated with the grantees.
8. The method of claim 1, further comprising: selecting from a device table devices of a grantor; joining grantees with the attribute changes; creating personal attribute record (PAR) transactions; sending PAR changes to destinations associated with the grantor.
9. The method of claim 1, wherein the first entity comprises a mobile device, and the second entity comprises a mobile device.
10. A system, comprising: means for maintaining first attributes associated with a first entity of a plurality of entities and second attributes associated with a second entity of the plurality of entities; means for linking the first entity with a second entity; means for providing a first destination, associated with the first entity, for the second attributes; means for granting first permissions for the first attributes to the second entity; means for facilitating propagation of shared attributes of the first attributes and the second attributes to the first destination and a second destination associated with the second entity through the first permissions and second permissions for the second attributes to the first entity; means for managing subsequent changes of attributes to create a syndicated distributed secure data exchange.
This patent application is a continuation of U.S. patent application Ser. No. 12/267,240, filed Nov. 7, 2008, entitled “Distributed Management Framework for Personal Attributes,” which is a continuation of U.S. patent application Ser. No. 11/397,817, filed Apr. 3, 2006, now U.S. Pat. No. 7,461,071, entitled “Distributed Management Framework for Personal Attributes,” which claims priority to U.S. Provisional Patent Application No. 60/668,302, filed Apr. 4, 2005, entitled “Secure Contact Database Synchronization,” all of which are incorporated herein by reference.
The system 500 includes a YouClient module 512 and a YouNIQ engine 524. In the example of FIG. 5 A, the YouClient module 512 includes a Me engine 526, a YouClient engine 528, and an address book 514.
In the example of FIG. 5 A, the YouNIQ engine 524 is responsible for providing a GUI to a subscriber. The subscriber can set permissions that enable other users to see information that is associated with the subscriber, such as contact information. When the subscriber using the YouNIQ engine 524 GUI clicks on an appropriate button (or performs some other action), the YouNIQ engine 524 generates a <setPermissions> transaction 570-1 and forwards the transaction 570 through the YouClient engine 528 to the YouServer dB engine 552 of the YouServer 534.
In the example of FIG. 5 A, 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. 5 A, after generating the <setData> transaction 572-1 (or at roughly the same time), the Me engine 526 generates a <setDataChk> transaction 573-1. The <setDataChk> transaction 573 is associated with a time interval of arbitrary length. If the Me engine 526 receives an indication that the <setData> transaction 571 was successful, then the <setDataChk> transaction 573 “times out.” If, on the other hand, no indication is received that the <setData> transaction 571 was successful, the Me Engine may, in an embodiment, generate a new <setData> transaction 571 or the YouClient 512 could perform some other action to determine whether a new <setData> transaction 571 should be generated or the like.
In the example of FIG. 5 A, the YouClient engine 530 generates an <awake> transaction 577-1 to ask the YouServer 534 if there are any pending <pushData> transactions 575 for the client.
In the example of FIG. 5 A, the YouClient engine 528 consumes the <awakeOK> transaction 578-2 and, after a period of time, generates another <awake> transaction 577-1. This continues until a pending <pushData> transaction 575 becomes available. It may be useful to note that the YouClient engine 528 would probably be associated with a user other than the subscriber. Thus, the <setData> transaction 572-1 described previously (and associated with a first update) would probably be generated at a different client than the client consuming the <pushData> transaction 575-2 associated with the first update. Simply put, it would not be particularly advantageous for a client to consume its own updates.
In the example of FIG. 5 A, the YouClient engine 528 pushes data associated with the <pushData> transaction 575 into the address book 514. Assuming the update is successful, the YouClient engine 528 generates a <pushDataOK> transaction 579-1, which is sent to the YouServer 534.
FIG. 7 A depicts a system on which a distributed management framework for personal attributes may be implemented. FIG. 7 A depicts a networked system 700 that includes several computer systems coupled together through a network 702, such as the Internet. The term “Internet” as used herein refers to a network of networks which uses certain protocols, such as the TCP/IP protocol, and possibly other protocols such as the hypertext transfer protocol (HTTP) for hypertext markup language (HTML) documents that make up the World Wide Web (the web). The physical connections of the Internet and the protocols and communication procedures of the Internet are well known to those of skill in the art.
In the example of FIG. 10, four examples of transactions are associated with the user engine 1080: authenticate user API 1082, find user API 1084, get unions API 1086, and get fields API 1088. This group of commands handles the management of finding users. The parameters of the authenticate user API 1082 are uid and deviceid, and the results are predictable. The parameters of the find user API 1084 may include, by way of example but not limitation, uid, deviceid, username, firstname, and lastname, and the results are 0 . . . n user items. The parameters of the get unions API 1086 are uid and deviceid, and the results are 0 . . . n user items. The parameters of the get fields API 1088 are uid and deviceid, and the result will include 1 . . . n group objects which include 1 . . . n field objects. This API is used to get field data from the field table 1104 of the server, which is separated into field groups so the client can use this for display. This will also include the attributes for the fields.
In the example of FIG. 15 A, the flowchart 1500 continues to module 1510 where grantees for attributes of the grantor are selected from a permissions table, to module 1512 where grantees are joined with attribute changes, and to module 1514 where attribute transactions are created. The flowchart 1500 continues to decision point 1516 where it is determined whether to wait for polling. If it is determined that the server should wait for polling (1516-Y), then the flowchart 1500 repeats decision point 1516 until it is determined that polling occurred. If it is determined that the server should not wait for polling (1516-N), or that polling has occurred, then the flowchart 1500 continues to module 1518 where attribute transactions changes are sent to devices of the grantee (e.g., linking server). It should be noted that although the term “sent” is used, if the client is polling, then the transaction is actually a pull transaction, rather than a push/send. The flowchart 1500 ends at 1520 with the client updating the recipient of the changed attribute.
In the example of FIG. 15 A, after changes and UID are sent from the client to the server at module 1508, the flowchart continues at module 1510 as described, but also continues to module 1522 (FIG. 15B) where a device of the grantor is selected from the device table at the server. The flowchart 1500 continues module 1524 where the server joins with the attribute changes and create PAR transactions. The flowchart 1500 continues to decision point 1526 where the server waits for polling (or not) and to module 1528 where PAR changes are sent to devices of the grantor. The flowchart 1500 ends at module 1530 with updating PAR.
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 requestor 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 requestor 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.
Previous Patent: DNA MATCHING
Next Patent: SYSTEMS AND METHODS FOR PROVIDING MULTIMEDIA