Source: http://www.google.com/patents/US20090119266?ie=ISO-8859-1&dq=6,712,702
Timestamp: 2014-09-19 23:22:23
Document Index: 337554643

Matched Legal Cases: ['art 1200', 'art 1200', 'art 1200', 'art 1200', 'art 1200', 'art 1200', 'art 1200', 'art 1200', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1300', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1600', 'art 1600', 'art 1600', 'art 1600', 'art 1600', 'art 1600', 'art 1600', 'art 1600', 'art 1600', 'art 1600', 'art 1600']

Patent US20090119266 - Distributed management framework for personal attributes - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign in<nobr>Advanced Patent Search</nobr>PatentsA technique for distributed management of attributes includes propagating attributes based upon attribute-granularity permissions. An example of a system according to the technique may include a server, coupled to a first client and a second client, that includes a module that receives attribute data...http://www.google.com/patents/US20090119266?utm_source=gb-gplus-sharePatent US20090119266 - Distributed management framework for personal attributesAdvanced Patent SearchPublication numberUS20090119266 A1Publication typeApplicationApplication numberUS 12/267,240Publication dateMay 7, 2009Filing dateNov 7, 2008Priority dateApr 4, 2005Also published asCA2602376A1, EP1872284A2, US7461071, US8620866, US20060224597, US20090125523, US20140181148, WO2006108012A2, WO2006108012A3Publication number12267240, 267240, US 2009/0119266 A1, US 2009/119266 A1, US 20090119266 A1, US 20090119266A1, US 2009119266 A1, US 2009119266A1, US-A1-20090119266, US-A1-2009119266, US2009/0119266A1, US2009/119266A1, US20090119266 A1, US20090119266A1, US2009119266 A1, US2009119266A1InventorsMark Fitzpatrick, Anthony SiressOriginal AssigneeYounite, Inc.Export CitationBiBTeX, EndNote, RefManClassifications (16), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetDistributed management framework for personal attributesUS 20090119266 A1Abstract A technique for distributed management of attributes includes propagating attributes based upon attribute-granularity permissions. An example of a system according to the technique may include a server, coupled to a first client and a second client, that includes a module that receives attribute data from the first client; a permissions database where first permissions associated with the first client are set at the individual attribute level for the second client; an engine for updating the permissions database and for validating the first permissions for the second client; and an engine for distributing first client updates based on validated permissions to destinations associated with the one or more second destination stores.
CROSS-REFERENCE TO RELATED APPLICATIONS This patent application is a Continuation of U.S. patent application Ser. No. 11/397,817, filed Apr. 3, 2006, which claims priority to U.S. Provisional Patent App. No. 60/668,302, filed Apr. 4, 2005, which are both incorporated herein by reference.
FIG. 12 depicts a flowchart 1200 of an example of a method for startup in a distributed management of personal attributes framework. In the example of FIG. 12, the flowchart 1200 starts at module 1202 with reading UID and DeviceID from local or remote cache, file, database, or the like. The flowchart 1200 continues at module 1204 with calling a server method to request permissions for the UID. If the server cannot be contacted, but permissions are stored locally (1206�Y), then the flowchart 1200 continues at module 1208 with reading permissions from a local file. In either case, the flowchart 1200 continues to decision point 1210 where it is determined whether PAR data is stored locally. If PAR data is not stored locally (1210�N), then the flowchart 1200 continues to module 1212 where a server method is called to request PAR data. If PAR data is stored locally (1210�Y), then the flowchart 1200 continues to module 1214 where PAR data is read from a local file. In either case, the flowchart 1200 continues to module 1216 where, depending on client device type or settings, transactions destined for this device are acquired from the server by either: (1216-1) requesting pending transactions from the server or (1216-2) waiting for the server to send the transactions.
FIG. 13 depicts a flowchart 1300 of an example of a method for adding a user or destination in a distributed management of personal attributes framework. In the example of FIG. 13, the flowchart 1300 starts at decision point 1302 where it is determined whether credentials are stored locally. If the credentials are stored locally (1302�Y), then the flowchart 1300 continues to module 1308 where the server verifies that the credentials are valid. If the credentials are not stored locally (1302�N), then the flowchart 1300 continues to decision point 1304 where it is determined whether the user is a new user. The case where the user is a new user (1304�Y) is described later. If it is determined that the user is not a new user (1304�N), then the flowchart 1300 continues to module 1306 where the user is prompted for credentials at the client, and the flowchart 1300 continues to module 1308 where the server verifies that the credentials are valid. The flowchart 1300 continues from the module 1308 to decision point 1310 where it is determined whether the credentials are valid. If the credentials are valid (1310�Y), then the flowchart 1300 ends at module 1314 where a client communications service and/or UI is started. In an alternative, the client service may already be running, obviating the need to start the client service at module 1314. This may allow multiple clients to connect through a single client service (e.g., a linking server). If the credentials are not valid (1310�N), then the flowchart 1300 continues to decision point 1312 where it is determined whether the client intends to work offline. If the client does not intend to work offline (1312�N), then the flowchart continues from module 1306 as described previously. If the client intends to work offline (1312�Y), then the flowchart 1300 ends at module 1314 as described previously.
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.
FIGS. 15A and 15B depict a flowchart 1500 of an example of a method for changing attributes in a distributed management of personal attributes framework. In the example of FIG. 15A, the flowchart 1500 starts at module 1502 whether a grantor updating one or more attributes in their PAR. The flowchart 1500 continues to decision point 1504 where it is determined whether permissions have been cached. If permissions have been cached (1504�Y), then the flowchart 1500 continues to decision point 1506 where it is determined whether permission has been granted (if not, the flowchart 1500 ends; if so, the flowchart 1500 continues to module 1508). If permissions have not been cached (1504�Y), then the flowchart 1500 continues to module 1508 where changes and UID are sent from the client to the server.
In the example of FIG. 15A, 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.
FIG. 16 depicts a flowchart 1600 of an example of a method for making connections in a distributed management of personal attributes framework. In the example of FIG. 16, the flowchart 1600 starts at module 1602 where a requester enters a username into a UI or a lookup is performed at a client. The flowchart 1600 continues to module 1604 where a contact is added at the client. The flowchart 1600 continues to decision point 1606 where it is determined whether the requestee has the requester on a do not call list. If so (1606�Y), the flowchart ends and the requestor may or may not receive notification. If not (1606�N), then the server sends a request to the requestee. The flowchart 1600 continues to modules 1610 where the requestee is prompted, and to module 1612 where the requestee sends a response to the server.
In the example of FIG. 16, the flowchart 1600 continues to decision point 1614 where it is determined whether the requestee accepted the request. If so (1614�Y), then the flowchart 1600 continues to module 1616 where the contact flag is set at the server, and the flowchart 1600 ends at module 1618 where devices owned by grantor and grantee are informed. If not (1614�N), then the flowchart 1600 continues to decision point 1620 where it is determined whether the requestee not only declines the request but also adds the requestor to a do not call list. If it is determined that the requestor is not to be added to the do not call list (1620�N) then the flowchart 1600 ends with the requestee not honoring the request. If it is determined that the requestor is to be added to the do not call list (1620�Y) then the flowchart 1600 ends at module 1622 with setting the do not call flag.
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 requester 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 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 requester 1710 with requested data in a matter of minutes, instead days or even months.
Classifications U.S. Classification1/1, 707/E17.005, 707/E17.054, 707/999.003, 707/999.009International ClassificationG06F17/30, G06F7/06Cooperative ClassificationY10S707/99939, G06F21/6245, G06F2221/2141, G06F2221/2145, G06F17/30575, G06F21/6218, G06F17/3007European ClassificationG06F21/62B5, G06F17/30S7Legal EventsDateCodeEventDescriptionJan 21, 2009ASAssignmentOwner name: YOUNITE, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FITZPATRICK, MARK;SIRESS, ANTHONY;REEL/FRAME:022135/0201;SIGNING DATES FROM 20090116 TO 20090120Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FITZPATRICK, MARK;SIRESS, ANTHONY;SIGNING DATES FROM 20090116 TO 20090120;REEL/FRAME:022135/0201RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google