DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication No. 2020/0186344 by Shockley et al.
As to claim 1, Shockley discloses a system comprising:
a user device configured to generate and store a zero-knowledge cookie (zkCookie) (Shockley: Page 7, Sec 91; “Illustratively, the techniques described herein may be performed by hardware, software, and/or firmware, such as in accordance with the “zero-knowledge data management” process 248, which may include computer executable instructions executed by a processor 220 (of a particular correspondingly operative device 200) to perform functions relating to the techniques described herein, e.g., in conjunction with other devices which may have a correspondingly configured zero-knowledge data management process 248 depending upon the functionality of the device, as described below (e.g., a source device, a storage server, a recipient device, a controller device, an attestation service, and so on).”; and
a cloud platform configured to validate user queries using a zero-knowledge proof derived from the zkCookie, wherein the cloud platform is restricted from identifying a user or determining whether multiple queries originate from the same user (Shockley: Page 7-8, Sec 92; “perationally, the techniques herein are based on a collection of devices participating in a data storage system (e.g., a zero-knowledge data management network). With reference generally to the simplified data storage system 400 in FIG. 4, a source device 410 communicates with a storage server 420 and a recipient device 430, similar to as shown in FIG. 3 above. System 400 of FIG. 4 also specifically includes a “controller device” 440, which may be any device (e.g., a “controller device”) that is involved in some way in an interaction that is primarily between the source device 410, storage server 420, and recipient device 430. That is, controller device 440 is a device that may be involved in the overall transaction of the raw data described herein (e.g., dictating the secure data collection by source devices and/or initiating secure data exchanges, and so on), but according to the techniques herein, is not privy to accessing the raw data. In one example, the controller device 440 may be the bank in the illustration above, with the source device 410 being the user's device and the recipient device 430 being the regulatory servers configured to receive reports on large financial transactions. Any other arrangement and purpose of the source, server, recipient, and controller devices may be configured and used herein, and the financial institution and reporting example herein is merely for illustrative discussion herein.” and Pages 33-34, Sec 261; “FIG. 32 illustrates another example simplified procedure for zero-knowledge data management in accordance with one or more embodiments described herein, particularly from the perspective of obtaining attestation from an attestation service. For example, a non-generic, specifically configured device (e.g., storage server 420) may perform procedure 3200 by executing stored instructions (e.g., zero-knowledge data management process 248 on the storage server). The procedure 3200 may start at step 3205, and continues to step 3210, where, as described in greater detail above, information is stored on a third-party server, where the third-party server and an attestation service cannot read the stored information. Also, in step 3215, the third-party server stores a re-encryption key that converts the stored information to a format readable to only the attestation service. To request, in step 3220, that the attestation service provide an attestation of whether the stored information is correct, the third-party server applies the re-encryption key to the stored information and sends the stored information, in the format readable to only the attestation service, to the attestation service. Accordingly, in step 3225, the third-party server receives, from the attestation service, an indication as to whether the stored information, which cannot be read by the third-party server, is attested as correct by the attestation service, and can then provide the indication as to whether the stored information is attested as correct by the attestation service to an interested device in step 3030, without the third-party server knowing the information. Note that in one embodiment, the interested device cannot read the stored information, while in another embodiment, it can (e.g., storing, on the third-party server, a second re-encryption key that converts the stored information to a format readable to only the interested device, applying the second re-encryption key to the stored information, and sending the stored information, in the format readable to only the interested device, to the interested device). Also as described above, in one example embodiment, the stored information comprises personally identifying information, and the interested device comprises a regulatory organization device. The illustrative procedure 3200 may end in step 3235.”).
As to claim 2, Shockley further discloses further comprising a zero-knowledge virtual machine (zkVM) guest executed on the user device, wherein the zkVM guest is configured to manage a state machine associated with the zkCookie (Shockley: Pages 36-37; Sec 272; “Furthermore, while the embodiments may have been demonstrated with respect to certain communication environments, physical environments, or device form factors, other configurations may be conceived by those skilled in the art that would remain within the contemplated subject matter of the description above. For example, while different functions have been described as being performed on various servers or devices, certain functions may be performed on the same physical server or on the same virtual server (e.g., the storage server 420 and attestation server 1510 may be different co-located functions on a same physical/virtual server). Also, some functions which were described separately (e.g., and distributed between different servers) may be performed by a single process (e.g., a single software program configured to perform multiple functions described herein).”).
As to claim 3, Shockley further discloses wherein the state machine indicates that the zkCookie is associated with the user (Shockley: Page 10; Sec 112; “FIG. 7 illustrates another representation 700 of the concepts described in greater detail above. In particular, user data 710 (e.g., source data 415) and the user's public key 715 (e.g., source encryption key 411) serve as inputs to an encrypting combination 720 to result in cipher data 725 (e.g., source-encrypted source data 417). Additionally, the user's private key 730 (e.g., source decryption key 412) and the recipient's public key 735 (e.g., recipient device public key 431) server as inputs to a second encrypting combination 740 to result in the rekeying key 745 (e.g., recipient-based rekeying key 418). By then providing the cipher data 725 and the rekeying key 745 into another “re-” encrypting combination 750, the result is the new cipher data 755 (e.g., recipient-based encrypted source data 427). Accordingly, by supplying the recipient's private key 760 into a decrypting combination 765 for the new cipher data 755 results in the decrypted user's raw data 710.”).
As to claim 4, Shockley further discloses wherein the state machine includes one or more of a timestamp, a nonce, and arbitrary internal data (Shockley: Page 10; Sec 112; “FIG. 7 illustrates another representation 700 of the concepts described in greater detail above. In particular, user data 710 (e.g., source data 415) and the user's public key 715 (e.g., source encryption key 411) serve as inputs to an encrypting combination 720 to result in cipher data 725 (e.g., source-encrypted source data 417). Additionally, the user's private key 730 (e.g., source decryption key 412) and the recipient's public key 735 (e.g., recipient device public key 431) server as inputs to a second encrypting combination 740 to result in the rekeying key 745 (e.g., recipient-based rekeying key 418). By then providing the cipher data 725 and the rekeying key 745 into another “re-” encrypting combination 750, the result is the new cipher data 755 (e.g., recipient-based encrypted source data 427). Accordingly, by supplying the recipient's private key 760 into a decrypting combination 765 for the new cipher data 755 results in the decrypted user's raw data 710.”).
As to claim 5, Shockley further discloses wherein user interactions with the zkCookie are mediated through the zkVM guest to ensure integrity and compliance with cloud platform policies (Shockley: Page 16, Sec 143; “ In one embodiment, the list 1300 and associated policies may be statically configured, such as where an administrator sets the list in advance of operation, and only during updates or routine maintenance are the entries 1310 (and/or actions 1320) updated. In another embodiment, the list may be dynamically configured, changing over time as threats are detected, policies are changed, tolerances are adjusted, and so on. (Note, too, that both static and dynamic configurations may occur within a same list, i.e., where at least a portion of the list is statically configured, and at least a portion of the list is dynamically configured). For example, the storage server 420 may receiving one or more of the entries 1310 for the list from a controller device 440, in order for the storage server to determine authorizations for devices to receive the source data (e.g., where the controller device directs the collection of the source data). The list may also be based on users at the source devices 410 providing access to data, such as through clickwrap or clickthrough agreements on particular applications (i.e., a digital prompt that offers individuals the opportunity to accept or decline a digitally-mediated policy) or other user-based access control.”).
As to claim 6, Shockley further discloses wherein the cloud platform is further configured to reject the user queries without identifying the user (Shockley: Page 16, Sec 142; “Notably, the list 1300 (or generally, any suitable access control mechanism) may be based on credentials, device identifications (e.g., specific recipient devices), and/or network domains (e.g., known attacking networks, address prefixes, autonomous systems, uniform resource locators (URLs), and so on), as well as other factors such as geography. In addition to simple listing of allow/deny entries, the techniques herein also allow for authorization policies to be defined, such as time of day, day of week, size of data, frequency of data sharing, and many others. Further, whether the particular recipient device is authorized to receive the source data may be based on combinations of factors, such as defining relationships between particular source devices being asked to send to particular recipient devices (e.g., some recipient devices are acceptable for some source devices but not others, such as making the list 1300 specific to individual source devices), particular source data being sent to particular recipient devices (e.g., certain types of data are allowable to certain recipients but not others, such as preventing medical information from being sent to financial institutions). Still other entries may simply correspond to particular recipient devices itself (e.g., never allow data to be sent to certain recipients). Many different types of authorization policies can be configured, including parental controls, one-time access limits, and so on, and those shown herein are merely examples.”).
As to claim 7, Shockley discloses a method comprising:
initializing a zero-knowledge cookie (zkCookie) on a user device associated with a user (Shockley: Page 16, Sec 142-143; [0142] Notably, the list 1300 (or generally, any suitable access control mechanism) may be based on credentials, device identifications (e.g., specific recipient devices), and/or network domains (e.g., known attacking networks, address prefixes, autonomous systems, uniform resource locators (URLs), and so on), as well as other factors such as geography. In addition to simple listing of allow/deny entries, the techniques herein also allow for authorization policies to be defined, such as time of day, day of week, size of data, frequency of data sharing, and many others. Further, whether the particular recipient device is authorized to receive the source data may be based on combinations of factors, such as defining relationships between particular source devices being asked to send to particular recipient devices (e.g., some recipient devices are acceptable for some source devices but not others, such as making the list 1300 specific to individual source devices), particular source data being sent to particular recipient devices (e.g., certain types of data are allowable to certain recipients but not others, such as preventing medical information from being sent to financial institutions). Still other entries may simply correspond to particular recipient devices itself (e.g., never allow data to be sent to certain recipients). Many different types of authorization policies can be configured, including parental controls, one-time access limits, and so on, and those shown herein are merely examples.
[0143] In one embodiment, the list 1300 and associated policies may be statically configured, such as where an administrator sets the list in advance of operation, and only during updates or routine maintenance are the entries 1310 (and/or actions 1320) updated. In another embodiment, the list may be dynamically configured, changing over time as threats are detected, policies are changed, tolerances are adjusted, and so on. (Note, too, that both static and dynamic configurations may occur within a same list, i.e., where at least a portion of the list is statically configured, and at least a portion of the list is dynamically configured). For example, the storage server 420 may receiving one or more of the entries 1310 for the list from a controller device 440, in order for the storage server to determine authorizations for devices to receive the source data (e.g., where the controller device directs the collection of the source data). The list may also be based on users at the source devices 410 providing access to data, such as through clickwrap or clickthrough agreements on particular applications (i.e., a digital prompt that offers individuals the opportunity to accept or decline a digitally-mediated policy) or other user-based access control.);
authenticating, at the user device, a user using the zkCookie in a privacy mode (Shockley: Page 16, Sec 142-143; [0142] Notably, the list 1300 (or generally, any suitable access control mechanism) may be based on credentials, device identifications (e.g., specific recipient devices), and/or network domains (e.g., known attacking networks, address prefixes, autonomous systems, uniform resource locators (URLs), and so on), as well as other factors such as geography. In addition to simple listing of allow/deny entries, the techniques herein also allow for authorization policies to be defined, such as time of day, day of week, size of data, frequency of data sharing, and many others. Further, whether the particular recipient device is authorized to receive the source data may be based on combinations of factors, such as defining relationships between particular source devices being asked to send to particular recipient devices (e.g., some recipient devices are acceptable for some source devices but not others, such as making the list 1300 specific to individual source devices), particular source data being sent to particular recipient devices (e.g., certain types of data are allowable to certain recipients but not others, such as preventing medical information from being sent to financial institutions). Still other entries may simply correspond to particular recipient devices itself (e.g., never allow data to be sent to certain recipients). Many different types of authorization policies can be configured, including parental controls, one-time access limits, and so on, and those shown herein are merely examples.
[0143] In one embodiment, the list 1300 and associated policies may be statically configured, such as where an administrator sets the list in advance of operation, and only during updates or routine maintenance are the entries 1310 (and/or actions 1320) updated. In another embodiment, the list may be dynamically configured, changing over time as threats are detected, policies are changed, tolerances are adjusted, and so on. (Note, too, that both static and dynamic configurations may occur within a same list, i.e., where at least a portion of the list is statically configured, and at least a portion of the list is dynamically configured). For example, the storage server 420 may receiving one or more of the entries 1310 for the list from a controller device 440, in order for the storage server to determine authorizations for devices to receive the source data (e.g., where the controller device directs the collection of the source data). The list may also be based on users at the source devices 410 providing access to data, such as through clickwrap or clickthrough agreements on particular applications (i.e., a digital prompt that offers individuals the opportunity to accept or decline a digitally-mediated policy) or other user-based access control.);
causing a user session to be validated at the cloud platform without revealing an identity of the user (Shockley: Page 16, Sec 142-143; [0142] Notably, the list 1300 (or generally, any suitable access control mechanism) may be based on credentials, device identifications (e.g., specific recipient devices), and/or network domains (e.g., known attacking networks, address prefixes, autonomous systems, uniform resource locators (URLs), and so on), as well as other factors such as geography. In addition to simple listing of allow/deny entries, the techniques herein also allow for authorization policies to be defined, such as time of day, day of week, size of data, frequency of data sharing, and many others. Further, whether the particular recipient device is authorized to receive the source data may be based on combinations of factors, such as defining relationships between particular source devices being asked to send to particular recipient devices (e.g., some recipient devices are acceptable for some source devices but not others, such as making the list 1300 specific to individual source devices), particular source data being sent to particular recipient devices (e.g., certain types of data are allowable to certain recipients but not others, such as preventing medical information from being sent to financial institutions). Still other entries may simply correspond to particular recipient devices itself (e.g., never allow data to be sent to certain recipients). Many different types of authorization policies can be configured, including parental controls, one-time access limits, and so on, and those shown herein are merely examples.
[0143] In one embodiment, the list 1300 and associated policies may be statically configured, such as where an administrator sets the list in advance of operation, and only during updates or routine maintenance are the entries 1310 (and/or actions 1320) updated. In another embodiment, the list may be dynamically configured, changing over time as threats are detected, policies are changed, tolerances are adjusted, and so on. (Note, too, that both static and dynamic configurations may occur within a same list, i.e., where at least a portion of the list is statically configured, and at least a portion of the list is dynamically configured). For example, the storage server 420 may receiving one or more of the entries 1310 for the list from a controller device 440, in order for the storage server to determine authorizations for devices to receive the source data (e.g., where the controller device directs the collection of the source data). The list may also be based on users at the source devices 410 providing access to data, such as through clickwrap or clickthrough agreements on particular applications (i.e., a digital prompt that offers individuals the opportunity to accept or decline a digitally-mediated policy) or other user-based access control.); and
updating, by the user device, a state of the zkCookie using a signed message from the cloud platform (Shockley: Page 16, Sec 142-143; [0142] Notably, the list 1300 (or generally, any suitable access control mechanism) may be based on credentials, device identifications (e.g., specific recipient devices), and/or network domains (e.g., known attacking networks, address prefixes, autonomous systems, uniform resource locators (URLs), and so on), as well as other factors such as geography. In addition to simple listing of allow/deny entries, the techniques herein also allow for authorization policies to be defined, such as time of day, day of week, size of data, frequency of data sharing, and many others. Further, whether the particular recipient device is authorized to receive the source data may be based on combinations of factors, such as defining relationships between particular source devices being asked to send to particular recipient devices (e.g., some recipient devices are acceptable for some source devices but not others, such as making the list 1300 specific to individual source devices), particular source data being sent to particular recipient devices (e.g., certain types of data are allowable to certain recipients but not others, such as preventing medical information from being sent to financial institutions). Still other entries may simply correspond to particular recipient devices itself (e.g., never allow data to be sent to certain recipients). Many different types of authorization policies can be configured, including parental controls, one-time access limits, and so on, and those shown herein are merely examples. [0143] In one embodiment, the list 1300 and associated policies may be statically configured, such as where an administrator sets the list in advance of operation, and only during updates or routine maintenance are the entries 1310 (and/or actions 1320) updated. In another embodiment, the list may be dynamically configured, changing over time as threats are detected, policies are changed, tolerances are adjusted, and so on. (Note, too, that both static and dynamic configurations may occur within a same list, i.e., where at least a portion of the list is statically configured, and at least a portion of the list is dynamically configured). For example, the storage server 420 may receiving one or more of the entries 1310 for the list from a controller device 440, in order for the storage server to determine authorizations for devices to receive the source data (e.g., where the controller device directs the collection of the source data). The list may also be based on users at the source devices 410 providing access to data, such as through clickwrap or clickthrough agreements on particular applications (i.e., a digital prompt that offers individuals the opportunity to accept or decline a digitally-mediated policy) or other user-based access control. And Page 17, Sec 146; “In addition to the list-based approach, the techniques herein may also confirm whether a particular recipient device is authorized to receive the source data using a credential-based exchange between the storage server 420 and the particular recipient device 430. For instance, in embodiments where the particular recipient devices are not pre-authorized (e.g., not merely a select few systems participating in the storage system, but rather allowing for any device to be a possible recipient device), the techniques herein may have the storage server request authentication credentials from the particular (potential) recipient device, which after the potential recipient device provides those authentication credentials 1430 to the storage server (e.g., passwords, access codes, attestation signatures to prove they are who they say they are, etc.), then the storage server can confirm (or deny) the authentication credentials from the particular recipient device, accordingly.”).
As to claim 8, Shockley further discloses wherein initializing the zkCookie comprises creating a new zkCookie or updating a state of an existing zkCookie (Shockley: Page 16, Sec 142-143).
As to claim 9, Shockley further discloses wherein the zkCookie is initialized upon absence or expiration of a previous zkCookie (Shockley: Page 16, Sec 142-143 and Page 28, Sec 214).
As to claim 10, Shockley further discloses wherein the zkCookie is initialized based on a handshake between the cloud platform and the user device (Shockley: Pages 7-8, Sec 92 and Page 34, Sec 260).
As to claim 11, Shockley further discloses further comprising validating the state of the zkCookie to confirm that the update is permitted by the cloud platform without disclosing an update history (Shockley: Pages 7-8, Sec 92 and Page 34, Sec 260).
As to claim 12, Shockley further discloses wherein content of the zkCookie remains hidden from the cloud platform (Shockley: Page 16, Sec 142-143).
As to claim 13, Shockley further discloses a computer program product comprising a non-transitory computer readable medium having computer readable program code stored thereon, the computer readable program code configured to:
initialize a zero-knowledge cookie (zkCookie) associated with a user (Shockley: Page 16, Sec 142-143; [0142] Notably, the list 1300 (or generally, any suitable access control mechanism) may be based on credentials, device identifications (e.g., specific recipient devices), and/or network domains (e.g., known attacking networks, address prefixes, autonomous systems, uniform resource locators (URLs), and so on), as well as other factors such as geography. In addition to simple listing of allow/deny entries, the techniques herein also allow for authorization policies to be defined, such as time of day, day of week, size of data, frequency of data sharing, and many others. Further, whether the particular recipient device is authorized to receive the source data may be based on combinations of factors, such as defining relationships between particular source devices being asked to send to particular recipient devices (e.g., some recipient devices are acceptable for some source devices but not others, such as making the list 1300 specific to individual source devices), particular source data being sent to particular recipient devices (e.g., certain types of data are allowable to certain recipients but not others, such as preventing medical information from being sent to financial institutions). Still other entries may simply correspond to particular recipient devices itself (e.g., never allow data to be sent to certain recipients). Many different types of authorization policies can be configured, including parental controls, one-time access limits, and so on, and those shown herein are merely examples.
[0143] In one embodiment, the list 1300 and associated policies may be statically configured, such as where an administrator sets the list in advance of operation, and only during updates or routine maintenance are the entries 1310 (and/or actions 1320) updated. In another embodiment, the list may be dynamically configured, changing over time as threats are detected, policies are changed, tolerances are adjusted, and so on. (Note, too, that both static and dynamic configurations may occur within a same list, i.e., where at least a portion of the list is statically configured, and at least a portion of the list is dynamically configured). For example, the storage server 420 may receiving one or more of the entries 1310 for the list from a controller device 440, in order for the storage server to determine authorizations for devices to receive the source data (e.g., where the controller device directs the collection of the source data). The list may also be based on users at the source devices 410 providing access to data, such as through clickwrap or clickthrough agreements on particular applications (i.e., a digital prompt that offers individuals the opportunity to accept or decline a digitally-mediated policy) or other user-based access control.);
authenticate a cloud platform session using the zkCookie (Shockley: Page 16, Sec 142-143; [0142] Notably, the list 1300 (or generally, any suitable access control mechanism) may be based on credentials, device identifications (e.g., specific recipient devices), and/or network domains (e.g., known attacking networks, address prefixes, autonomous systems, uniform resource locators (URLs), and so on), as well as other factors such as geography. In addition to simple listing of allow/deny entries, the techniques herein also allow for authorization policies to be defined, such as time of day, day of week, size of data, frequency of data sharing, and many others. Further, whether the particular recipient device is authorized to receive the source data may be based on combinations of factors, such as defining relationships between particular source devices being asked to send to particular recipient devices (e.g., some recipient devices are acceptable for some source devices but not others, such as making the list 1300 specific to individual source devices), particular source data being sent to particular recipient devices (e.g., certain types of data are allowable to certain recipients but not others, such as preventing medical information from being sent to financial institutions). Still other entries may simply correspond to particular recipient devices itself (e.g., never allow data to be sent to certain recipients). Many different types of authorization policies can be configured, including parental controls, one-time access limits, and so on, and those shown herein are merely examples.
[0143] In one embodiment, the list 1300 and associated policies may be statically configured, such as where an administrator sets the list in advance of operation, and only during updates or routine maintenance are the entries 1310 (and/or actions 1320) updated. In another embodiment, the list may be dynamically configured, changing over time as threats are detected, policies are changed, tolerances are adjusted, and so on. (Note, too, that both static and dynamic configurations may occur within a same list, i.e., where at least a portion of the list is statically configured, and at least a portion of the list is dynamically configured). For example, the storage server 420 may receiving one or more of the entries 1310 for the list from a controller device 440, in order for the storage server to determine authorizations for devices to receive the source data (e.g., where the controller device directs the collection of the source data). The list may also be based on users at the source devices 410 providing access to data, such as through clickwrap or clickthrough agreements on particular applications (i.e., a digital prompt that offers individuals the opportunity to accept or decline a digitally-mediated policy) or other user-based access control.);
generate and transmit a zero-knowledge proof about a state of the zkCookie in response to a user query (Shockley: Page 16, Sec 142-143; [0142] Notably, the list 1300 (or generally, any suitable access control mechanism) may be based on credentials, device identifications (e.g., specific recipient devices), and/or network domains (e.g., known attacking networks, address prefixes, autonomous systems, uniform resource locators (URLs), and so on), as well as other factors such as geography. In addition to simple listing of allow/deny entries, the techniques herein also allow for authorization policies to be defined, such as time of day, day of week, size of data, frequency of data sharing, and many others. Further, whether the particular recipient device is authorized to receive the source data may be based on combinations of factors, such as defining relationships between particular source devices being asked to send to particular recipient devices (e.g., some recipient devices are acceptable for some source devices but not others, such as making the list 1300 specific to individual source devices), particular source data being sent to particular recipient devices (e.g., certain types of data are allowable to certain recipients but not others, such as preventing medical information from being sent to financial institutions). Still other entries may simply correspond to particular recipient devices itself (e.g., never allow data to be sent to certain recipients). Many different types of authorization policies can be configured, including parental controls, one-time access limits, and so on, and those shown herein are merely examples.
[0143] In one embodiment, the list 1300 and associated policies may be statically configured, such as where an administrator sets the list in advance of operation, and only during updates or routine maintenance are the entries 1310 (and/or actions 1320) updated. In another embodiment, the list may be dynamically configured, changing over time as threats are detected, policies are changed, tolerances are adjusted, and so on. (Note, too, that both static and dynamic configurations may occur within a same list, i.e., where at least a portion of the list is statically configured, and at least a portion of the list is dynamically configured). For example, the storage server 420 may receiving one or more of the entries 1310 for the list from a controller device 440, in order for the storage server to determine authorizations for devices to receive the source data (e.g., where the controller device directs the collection of the source data). The list may also be based on users at the source devices 410 providing access to data, such as through clickwrap or clickthrough agreements on particular applications (i.e., a digital prompt that offers individuals the opportunity to accept or decline a digitally-mediated policy) or other user-based access control.); and
update the zkCookie using a signed message from the cloud platform (Shockley: Page 16, Sec 142-143; [0142] Notably, the list 1300 (or generally, any suitable access control mechanism) may be based on credentials, device identifications (e.g., specific recipient devices), and/or network domains (e.g., known attacking networks, address prefixes, autonomous systems, uniform resource locators (URLs), and so on), as well as other factors such as geography. In addition to simple listing of allow/deny entries, the techniques herein also allow for authorization policies to be defined, such as time of day, day of week, size of data, frequency of data sharing, and many others. Further, whether the particular recipient device is authorized to receive the source data may be based on combinations of factors, such as defining relationships between particular source devices being asked to send to particular recipient devices (e.g., some recipient devices are acceptable for some source devices but not others, such as making the list 1300 specific to individual source devices), particular source data being sent to particular recipient devices (e.g., certain types of data are allowable to certain recipients but not others, such as preventing medical information from being sent to financial institutions). Still other entries may simply correspond to particular recipient devices itself (e.g., never allow data to be sent to certain recipients). Many different types of authorization policies can be configured, including parental controls, one-time access limits, and so on, and those shown herein are merely examples.
[0143] In one embodiment, the list 1300 and associated policies may be statically configured, such as where an administrator sets the list in advance of operation, and only during updates or routine maintenance are the entries 1310 (and/or actions 1320) updated. In another embodiment, the list may be dynamically configured, changing over time as threats are detected, policies are changed, tolerances are adjusted, and so on. (Note, too, that both static and dynamic configurations may occur within a same list, i.e., where at least a portion of the list is statically configured, and at least a portion of the list is dynamically configured). For example, the storage server 420 may receiving one or more of the entries 1310 for the list from a controller device 440, in order for the storage server to determine authorizations for devices to receive the source data (e.g., where the controller device directs the collection of the source data). The list may also be based on users at the source devices 410 providing access to data, such as through clickwrap or clickthrough agreements on particular applications (i.e., a digital prompt that offers individuals the opportunity to accept or decline a digitally-mediated policy) or other user-based access control.).
As to claim 14, Shockley further discloses wherein the computer program code is further configured to: enforce constraints that prevent the cloud platform from tracking, identifying, or correlating the user query (Shockley: Page 16, Sec 142-143).
As to claim 15, Shockley further discloses wherein the zkCookie is initialized upon absence or expiration of a previous zkCookie (Shockley: Page 16, Sec 142-143 and Page 28, Sec 214).
As to claim 16, Shockley further discloses wherein the zkCookie is initialized based on a handshake between the cloud platform and the application (Shockley: Pages 7-8, Sec 92 and Page 34, Sec 260).
Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. 2017/0004323 by Balachandran et al. discloses secure data storage
U.S. Patent Application Publication No. 2018/0013562 by Haider et al. discloses zero knowledge data sharing
U.S. Patent Application Publication No. 2019/0253431 by Atanda discloses personal information management
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL S MCNALLY whose telephone number is (571)270-1599. The examiner can normally be reached Monday-Friday, 8:30 AM - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey L Nickerson can be reached at (469)295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
MICHAEL S. MCNALLY
Primary Examiner
Art Unit 2432
/Michael S McNally/Primary Examiner, Art Unit 2432
Prosecution Insights