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 .
Response to Amendment
The amendment filed on 12/01/2025 has been accepted and considered in this office action. Claims 1, 15 and 21 have been amended. Claims 2-4, 7, 13-14, 16-18 have been cancelled. Claims 22 and 23 have been newly added.
Response to Arguments
Applicant’s arguments, see Remarks, filed 12/01/2025, with respect to the amended limitation of the independent claims have been fully considered and are persuasive.
However, upon further consideration, a new ground(s) of rejection is made in view of discovery of new prior art WO 2022081408 A1 to Parekh as set forth below.
Claim Interpretation
Claims 1-23 are directed to the system, a method of the system, and CRM with instructions for implementing the system, in particular the system comprising a storage and processors disposed in a network operated by and controlled by a first entity. This system generally acts as an intermediary between a client and a ‘computational instance’, where the ‘computational instance’ is not on the same network nor controlled by the first entity (“…computational instance operated by a second entity”; “wherein the computational instance is physically distinct from the network”; claim 1, representative). However, claim 1 then recites limitations attempting to limit the ’computational instance’ which are i) not within the scope of any of the claims; and ii) presumably completely outside of the applicant’s control and at least outside the first entity’s control. In particular, the claims have been amended to recite “the one or more cryptographic keys are not accessible to the computational instance” and “…keys controlled by the first entity and not available to the computational instance”. However, this is conclusory language about an external entity outside of applicant (or the first entity’s) control. Nowhere do the claims recite any function or step within the scope of the claimed system to achieve this conclusory result. Therefore, the examiner finds that these clauses do not limit the scope of the claimed inventions. Furthermore, turning to applicant’s specification, there does not appear to be any discussion of any features within the control of the first entity for achieving the grandiose results of an external entity not having access to something.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 5, 15 and 21 is/are rejected under 35 U.S.C. 102 (a)(1) and (a)(2) as being anticipated by Parekh (WO 2022081408 A1).
Regarding Claim 1, Parekh teaches:
A system comprising: persistent storage disposed within a network operated by a first entity and containing one or more cryptographic keys controlled by the first entity (Fig. 9, Parekh discloses Organization device 190 and Encryption server 110 is a part of a network; Fig.3, Parekh discloses that the cryptographic operation is performed only in Encryption server 110 and not in Encryption database 120. Encryption database 120 is used as a storage of the encrypted data and does not have access to the keys);
receiving, from a client device, a request for an encrypted record stored within a computational instance operated by a second entity, wherein the request includes a first plaintext value, (Para 36, Parekh discloses that the organization device 190 sends 305 a TED (token encrypted data) to encryption server 110. para 26, Parekh discloses the TED may be <blue-plate-3851@token. example. com> or <56789@token.com>; Fig.3, Parekh discloses that the cryptographic operation is performed in Encryption server 110 and the storage of the encrypted data in Encryption database 120.);
and wherein the computational instance is physically distinct from the network (Fig. 9, Parekh discloses Organization device 190 and Encryption server 110 is a part of a network, Encryption database 120 is not on the network and thus physically distinct from the network);
and the one or more cryptographic keys are not accessible to the computational instance (Fig.3, Parekh discloses that the cryptographic operation is performed only in Encryption server 110 and not in Encryption database 120. Encryption database 120 is used as a storage of the encrypted data and does not have access to the keys.);
obtaining a hash value by applying a one-way hash function to the first plaintext value (Para 36, Parekh discloses Encryption server 110 generates 310 a hash of the TED; para 28, Parekh discloses the hash function may be a one-way function.);
transmitting, to the computational instance, the hash value; wherein receipt of the hash value causes the computational instance to look up encrypted records with fields that matches the hash value, wherein the encrypted record contains a field that matched the hash value (Para 36, Parekh discloses Encryption server 110 generates 310 a hash of the TED and sends 315 the TED hash to encryption database 120; Parekh further discloses the encryption database 120 uses the hash (e.g., as a database key) to identify/locate an encrypted OUD (Original unencrypted data) related to the TED.);
receiving, from the computational instance, the encrypted record in response to the hash value (Para 36, Parekh discloses Encryption database 120 sends 325 the encrypted OUD to encryption server 110.);
obtaining a second plaintext value by applying a cryptographic function to the encrypted
record, wherein applying the cryptographic function includes use of a cryptographic key of the one or more cryptographic keys controlled by the first entity and not available to the computational instance (Para 37, Parekh discloses the Encryption server 110 decrypts 330 the OUD; Fig.3, Parekh discloses that the cryptographic operation is performed in Encryption server 110 and not in the encryption database.);
and transmitting, to the client device, second plaintext value (Para 38, Parekh discloses Encryption server 110 sends 335 the decrypted OUD to organization device 190).
Regarding Claim 5, Parekh teaches the system of claim 1:
wherein the cryptographic function is from a symmetric cryptosystem (Para 28, Parekh discloses the TED (token encrypted data) may be used as the key for the encryption algorithm to encrypt the OUD (original unencrypted data). The TED may also be used to decrypt the OUD.);
and wherein the encrypted record was created by the one or more processors applying the cryptographic function to the unencrypted version of the encrypted record (Para 45, Parekh discloses encryption server 110 encrypts the OUD (e.g., <E><real@original. example. com> — > “lod982njASD~!”)).
Regarding Claim 15, Parekh teaches:
A computer-implemented method comprising: receiving, by one or more processors disposed within a network and from a client device, a request for an encrypted record stored within a computational instance operated by a second entity, wherein the request includes a first plaintext value, (Para 36, Parekh discloses that the organization device 190 sends 305 a TED (token encrypted data) to encryption server 110. para 26, Parekh discloses the TED may be <blue-plate-3851@token. example. com> or <56789@token.com>; Fig.3, Parekh discloses that the cryptographic operation is performed in Encryption server 110 and the storage of the encrypted data in Encryption database 120.);
wherein the computational instance is physically distinct from the network (Fig. 9, Parekh discloses Organization device 190 and Encryption server 110 is a part of a network, Encryption database 120 is not on the network and thus physically distinct from the network);
and wherein persistent storage disposed within the network is operated by a first entity and contains one or more cryptographic keys controlled by the first entity and the one or more cryptographic keys are not accessible to the computational instance (Fig. 9, Parekh discloses Encryption server 110 and Organizational device 190 are operated in a network; Fig.3, Parekh discloses that the cryptographic operation is performed only in Encryption server 110 and not in Encryption database 120. Encryption database 120 is used as a storage of the encrypted data and does not have access to the keys.);
obtaining a hash value by applying a one-way hash function to the first plaintext value (Para 36, Parekh discloses Encryption server 110 generates 310 a hash of the TED; para 28, Parekh discloses the hash function may be a one-way function.);
transmitting, to the computational instance, the hash value; wherein receipt of the hash value causes the computational instance to look up encrypted records with fields that matches the hash value, wherein the encrypted record contains a field that matched the hash value (Para 36, Parekh discloses Encryption server 110 generates 310 a hash of the TED and sends 315 the TED hash to encryption database 120; Parekh further discloses the encryption database 120 uses the hash (e.g., as a database key) to identify/locate an encrypted OUD (Original unencrypted data) related to the TED.);
receiving, from the computational instance, the encrypted record in response to the hash value (Para 36, Parekh discloses Encryption database 120 sends 325 the encrypted OUD to encryption server 110.);
obtaining a second plaintext value by applying a cryptographic function to the encrypted
record, wherein applying the cryptographic function includes use of a cryptographic key of the one or more cryptographic keys controlled by the first entity and not available to the computational instance (Para 37, Parekh discloses the Encryption server 110 decrypts 330 the OUD; Fig.3, Parekh discloses that the cryptographic operation is performed in Encryption server 110 and not in the encryption database.);
and transmitting, to the client device, second plaintext value (Para 38, Parekh discloses Encryption server 110 sends 335 the decrypted OUD to organization device 190).
Regarding Claim 21, Parekh teaches:
A non-transitory computer-readable medium, storing program instructions that, when executed by one or more processors of a computing system, cause the computing system to perform operations comprising: receiving, from a client device, a request for an encrypted record stored within a computational instance operated by a second entity, wherein the request includes a first plaintext value instance (Para 36, Parekh discloses that the organization device 190 sends 305 a TED (token encrypted data) to encryption server 110. para 26, Parekh discloses the TED may be <blue-plate-3851@token. example. com> or <56789@token.com>; Fig.3, Parekh discloses that the cryptographic operation is performed in Encryption server 110 and the storage of the encrypted data in Encryption database 120.);
and wherein the computational instance is physically distinct from the computing system (Fig. 9, Parekh discloses Organization device 190 and Encryption server 110 is a part of a network, Encryption database 120 is not on the network and thus physically distinct from the network);
and wherein persistent storage disposed within the computing system is operated by a first entity and contains one or more cryptographic keys controlled by the first entity and the one or more cryptographic keys are not accessible to the computational instance (Fig. 9, Parekh discloses Encryption server 110 and Organizational device 190 are operated in a network; Fig.3, Parekh discloses that the cryptographic operation is performed only in Encryption server 110 and not in Encryption database 120. Encryption database 120 is used as a storage of the encrypted data and does not have access to the keys.);
obtaining a hash value by applying a one-way hash function to the first plaintext value (Para 36, Parekh discloses Encryption server 110 generates 310 a hash of the TED; para 28, Parekh discloses the hash function may be a one-way function.);
transmitting, to the computational instance, the hash value; wherein receipt of the hash value causes the computational instance to look up encrypted records with fields that matches the hash value, wherein the encrypted record contains a field that matched the hash value (Para 36, Parekh discloses Encryption server 110 generates 310 a hash of the TED and sends 315 the TED hash to encryption database 120; Parekh further discloses the encryption database 120 uses the hash (e.g., as a database key) to identify/locate an encrypted OUD (Original unencrypted data) related to the TED.);
receiving, from the computational instance, the encrypted record in response to the hash value (Para 36, Parekh discloses Encryption database 120 sends 325 the encrypted OUD to encryption server 110.);
obtaining a second plaintext value by applying a cryptographic function to the encrypted
record, wherein applying the cryptographic function includes use of a cryptographic key of the one or more cryptographic keys controlled by the first entity and not available to the computational instance (Para 37, Parekh discloses the Encryption server 110 decrypts 330 the OUD; Fig.3, Parekh discloses that the cryptographic operation is performed in Encryption server 110 and not in the encryption database.);
and transmitting, to the client device, second plaintext value (Para 38, Parekh discloses Encryption server 110 sends 335 the decrypted OUD to organization device 190).
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parekh (WO 2022081408 A1) in view of Varnamkhasti (US 10541983 B1) in view of Ahmed (US 20190386814 A1).
Regarding Claim 6, Parekh teaches the system of claim 1,
Wherein the data is second plaintext value (Para 38, Parekh discloses decrypted OUD (original unencrypted data));
Parekh does not explicitly teach; However, Ahmed teaches:
wherein the cryptographic function is from an asymmetric cryptosystem, (Ahmed, para 368, discloses the computation services on data encrypted using a user's public key 408 (under a public-key or asymmetric cryptography scheme)).
wherein the cryptographic key is a private key (Ahmed, para 369, discloses the processed encrypted output 430 is then communicated to the user 435 who decrypts the output 430 using a private key 432.).
wherein the encrypted record was created in part by the one or more processors applying an inverse of the cryptographic function to the data (Ahmed, para 368 discloses the data entities 405 encrypt data 406 using the public key 408 before uploading the data );
wherein the cryptographic function includes use of a public key that is mathematically linked to the private key in accordance with the asymmetric cryptosystem. (Ahmed, para 222, discloses the public key is made available to anyone (often by means of a digital certificate). A sender encrypts data with the public key and only the holder of the private key can decrypt this data; Ahmed, para 368, discloses the computation services on data encrypted using a user's public key 408 (under a public-key or asymmetric cryptography scheme))
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Ahmed’s asymmetric cryptosystem (public/private key pair). Doing so would improve Parekh’s system by eliminating distribution of shared decryption keys to untrusted components. One would be motivated to perform such modification on Parekh’s system to reduce key-management risk, strengthen the existing trust boundary and support third party data ingestion without sharing shared secrets.
Claim(s) 8, 19 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parekh (WO 2022081408 A1) in view of Varnamkhasti (US 10541983 B1) in view of Chilakapati (US 9819648 B1).
Regarding Claim 8, Parekh teaches the system of Claim 1,
Parekh does not explicitly teach; However, Varnamkhasti teaches:
wherein the one or more processors are further configured to perform prior to receiving the request for the encrypted record, operations comprising: receiving an authorization request, wherein the authorization request includes sensitive information (Varnamkhasti, Col 8, lines 16-31, discloses receiving authorization information (token) from identity provider that implements OAuth, OASIS SAML along with the storage request 102 which may include sensitive information (Col 3, lines 39-41));
obtaining an encrypted version of the information by applying the cryptographic function to the
information, wherein applying the cryptographic function includes use of the cryptographic key (Varnamkhasti, Col 10, lines 8-11, discloses encrypting the information using cryptographic key);
transmitting, to the computational instance, the encrypted version of the sensitive information (Varnamkhasti, Col 10, lines 8-11, discloses providing the encrypted information to the secure data storage (part of the computational instance));
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Varnamkhasti’s technique of receiving authorization information including sensitive information and encrypting that information providing it to the storage system. One would be motivated to perform such modification on Parekh’s system to extend Parekh’s data protection architecture to authorization information as well, thereby improving confidentiality of sensitive information communicated for storage and reducing risk of unauthorized disclosure.
Varnamkhasti does not explicitly teach; However, Chilakapati teaches:
and receiving, from the computational instance, a first acknowledgment that the encrypted version of the sensitive information has been stored as the encrypted record. (Chilakapati, Col 18, lines 28-31, provides teaches the encrypted transcoded media files may be stored in a single data object and therefore a single acknowledgement may be transmitted from the data storage service 306 to the transcoding workflow service 316).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Chilakapati’s storage acknowledgement. Doing so would confirm durability, enables retry/back off on failure and provides audit trails for compliance. One would be motivated to perform such modification on Parekh’s system to reduce the risk of silent data loss or partial writes before later retrieval requests and ensure the encrypted record exists and is consistent prior to subsequent authorization or search workflows.
Regarding Claim 15, Parekh teaches the computer-implemented method of Claim 15,
Parekh does not explicitly teach; However, Varnamkhasti teaches:
prior to receiving the request for the encrypted record: receiving an authorization request, wherein the authorization request includes sensitive information (Varnamkhasti, Col 8, lines 16-31, discloses receiving authorization information (token) from identity provider that implements OAuth, OASIS SAML along with the storage request 102 which may include sensitive information (Col 3, lines 39-41));
obtaining an encrypted version of the information by applying the cryptographic function to the
information, wherein applying the cryptographic function includes use of the cryptographic key (Varnamkhasti, Col 10, lines 8-11, discloses encrypting the information using cryptographic key);
transmitting, to the computational instance, the encrypted version of the sensitive information (Varnamkhasti, Col 10, lines 8-11, discloses providing the encrypted information to the secure data storage (part of the computational instance));
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Varnamkhasti’s technique of receiving authorization information including sensitive information and encrypting that information providing it to the storage system. One would be motivated to perform such modification on Parekh’s system to extend Parekh’s data protection architecture to authorization information as well, thereby improving confidentiality of sensitive information communicated for storage and reducing risk of unauthorized disclosure.
Varnamkhasti does not explicitly teach; However, Chilakapati teaches:
receiving, from the computational instance, a first acknowledgment that the encrypted version of the sensitive information has been stored as the encrypted record. (Chilakapati, Col 18, lines 28-31, provides teaches the encrypted transcoded media files may be stored in a single data object and therefore a single acknowledgement may be transmitted from the data storage service 306 to the transcoding workflow service 316).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Chilakapati’s storage acknowledgement. Doing so would confirm durability, enables retry/back off on failure and provides audit trails for compliance. One would be motivated to perform such modification on Parekh’s system to reduce the risk of silent data loss or partial writes before later retrieval requests and ensure the encrypted record exists and is consistent prior to subsequent authorization or search workflows.
Regarding Claim 21, Parekh teaches the non-transitory computer-readable medium of Claim 21,
Parekh does not explicitly teach; However, Varnamkhasti teaches:
prior to receiving the request for the encrypted record, operations comprising: receiving an authorization request, wherein the authorization request includes sensitive information (Varnamkhasti, Col 8, lines 16-31, discloses receiving authorization information (token) from identity provider that implements OAuth, OASIS SAML along with the storage request 102 which may include sensitive information (Col 3, lines 39-41));
obtaining an encrypted version of the information by applying the cryptographic function to the
information, wherein applying the cryptographic function includes use of the cryptographic key (Varnamkhasti, Col 10, lines 8-11, discloses encrypting the information using cryptographic key);
transmitting, to the computational instance, the encrypted version of the sensitive information (Varnamkhasti, Col 10, lines 8-11, discloses providing the encrypted information to the secure data storage (part of the computational instance));
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Varnamkhasti’s technique of receiving authorization information including sensitive information and encrypting that information providing it to the storage system. One would be motivated to perform such modification on Parekh’s system to extend Parekh’s data protection architecture to authorization information as well, thereby improving confidentiality of sensitive information communicated for storage and reducing risk of unauthorized disclosure.
Varnamkhasti does not explicitly teach; However, Chilakapati teaches:
and receiving, from the computational instance, a first acknowledgment that the encrypted version of the sensitive information has been stored as the encrypted record. (Chilakapati, Col 18, lines 28-31, provides teaches the encrypted transcoded media files may be stored in a single data object and therefore a single acknowledgement may be transmitted from the data storage service 306 to the transcoding workflow service 316).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Chilakapati’s storage acknowledgement. Doing so would confirm durability, enables retry/back off on failure and provides audit trails for compliance. One would be motivated to perform such modification on Parekh’s system to reduce the risk of silent data loss or partial writes before later retrieval requests and ensure the encrypted record exists and is consistent prior to subsequent authorization or search workflows.
Claim(s) 9, 12, 20 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parekh (WO 2022081408 A1) in view of Varnamkhasti (US 10541983 B1) in view of Chilakapati (US 9819648 B1) in view of Wang (CN 113660208 B).
Regarding Claim 9, Parekh/Varnamkhasti/Chilakapati teach the system of Claim 8,
Varnamkhasti teaches:
one or more processors are further configured to perform, in response to receiving the authorization request operations comprising: transmitting, to an authorization server, a representation of the authorization request (Varnamkhasti, Col 8, lines 16-31, discloses before receiving the authorization token from the authorization servers that implement OAuth, OASIS SAML, a client is required to authenticate themselves with the identity provider, which implies sending an authorization request to the Authorization server);
receiving, from the authorization server, a result of the authorization request; (Varnamkhasti, Col 8, lines 16-31, discloses receiving authorization token from identity provider that implements OAuth, OASIS SAML.);
obtaining an encrypted version of the information by applying the cryptographic function to the
information, wherein applying the cryptographic function includes use of the cryptographic key (Varnamkhasti, Col 10, lines 8-11, discloses the intermediate encryption retrieval system can obtain the cryptographic key and encrypting the information using cryptographic key);
transmitting, to the computational instance, the encrypted version of the information (Varnamkhasti, Col 10, lines 8-11, discloses providing the encrypted information to the secure data storage (part of the computational instance));
Wherein the information comprises the authorization result (Varnamkhasti, Col 8, lines 16-31, discloses receiving authorization token from identity provider that implements OAuth, OASIS SAML);
and providing, in response to the authorization request, the result (Varnamkhasti, Col 8, lines 16-31, discloses before receiving the authorization token from the authorization servers that implement OAuth, OASIS SAML, a client is required to authenticate themselves with the identity provider, which implies sending an authorization request to the Authorization server; Col 8, lines 16-31, Varnamkhasti discloses receiving authorization token from identity provider that implements OAuth, OASIS SAML.);
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Varnamkhasti’s technique of authorization interaction and encryption. One would be motivated to perform such modification on Parekh’s system to enable authenticated access control and secure handling of authorization tokens while storing or transmitting information to remote storage, thereby improving the security and reliability of the system.
Varnamkhasti does not explicitly teach; However, Wang teaches:
receiving, from the computational instance, a second acknowledgment that the encrypted version of the result has been stored; (Wang, page 17, para 94, discloses the eTKB SDK performs cryptographic operations on the password input by the user, encrypts the operation result, and transmits the encrypted operation result to the eTKB server);
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Wang’s storage acknowledgement of the result. Doing so provides a closed loop confirmation that encrypted authorization outcome has been durably persisted by the computational instance, which improves transactional integrity. One would be motivated to perform such modification on Parekh’s system to enable safe retries and idempotent writes and strengthens auditability and compliance logging.
Regarding Claim 12, Parekh/Varnamkhasti/Chilakapati/Wang teaches the system of Claim 9,
Varnamkhasti teaches:
wherein the result is either that the authorization request was authorized or that the
authorization request was denied. (Varnamkhasti, Col 8, lines 21-31, provides teaches that the system require authorization token to be provided and that upon confirmation of the authorization token by the intermediate encryption retrieval system 100, the system 100 can cause storage and indexing of the received information. The process of "confirmation" is a clear example of an authorization step. This implies, the token is either confirmed (authorized) or not confirmed (denied)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Varnamkhasti’s technique of authorization confirmation mechanism. One would be motivated to perform such modification on Parekh’s system so that the information is stored or processed only after the authorization token is validated, thereby providing authenticated access control and improving the security and reliability of handling information communicated to remote storage system.
Regarding Claim 20, Parekh/Varnamkhasti/Chilakapati teaches the computer-implemented method of Claim 19,
Parekh does not explicitly teach; However, Varnamkhasti teaches:
prior to receiving the request for the encrypted record: receiving an authorization request, wherein the authorization request includes sensitive information (Varnamkhasti, Col 8, lines 16-31, discloses receiving authorization information (token) from identity provider that implements OAuth, OASIS SAML along with the storage request 102 which may include sensitive information (Col 3, lines 39-41));
obtaining an encrypted version of the information by applying the cryptographic function to the
information, wherein applying the cryptographic function includes use of the cryptographic key (Varnamkhasti, Col 10, lines 8-11, discloses encrypting the information using cryptographic key);
transmitting, to the computational instance, the encrypted version of the sensitive information (Varnamkhasti, Col 10, lines 8-11, discloses providing the encrypted information to the secure data storage (part of the computational instance));
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Varnamkhasti’s technique of receiving authorization information including sensitive information and encrypting that information providing it to the storage system. One would be motivated to perform such modification on Parekh’s system to extend Parekh’s data protection architecture to authorization information as well, thereby improving confidentiality of sensitive information communicated for storage and reducing risk of unauthorized disclosure.
Varnamkhasti does not explicitly teach; However, Chilakapati teaches:
and receiving, from the computational instance, a first acknowledgment that the encrypted version of the sensitive information has been stored as the encrypted record. (Chilakapati, Col 18, lines 28-31, provides teaches the encrypted transcoded media files may be stored in a single data object and therefore a single acknowledgement may be transmitted from the data storage service 306 to the transcoding workflow service 316).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Chilakapati’s storage acknowledgement. Doing so would confirm durability, enables retry/back off on failure and provides audit trails for compliance. One would be motivated to perform such modification on Parekh’s system to reduce the risk of silent data loss or partial writes before later retrieval requests and ensure the encrypted record exists and is consistent prior to subsequent authorization or search workflows.
Regarding Claim 23, Parekh/Varnamkhasti/Chilakapati teach the non-transitory computer-readable medium of Claim 22,
Varnamkhasti teaches:
transmitting, to an authorization server, a representation of the authorization request (Varnamkhasti, Col 8, lines 16-31, discloses before receiving the authorization token from the authorization servers that implement OAuth, OASIS SAML, a client is required to authenticate themselves with the identity provider, which implies sending an authorization request to the Authorization server);
receiving, from the authorization server, a result of the authorization request; (Varnamkhasti, Col 8, lines 16-31, discloses receiving authorization token from identity provider that implements OAuth, OASIS SAML.);
obtaining an encrypted version of the information by applying the cryptographic function to the
information, wherein applying the cryptographic function includes use of the cryptographic key (Varnamkhasti, Col 10, lines 8-11, discloses the intermediate encryption retrieval system can obtain the cryptographic key and encrypting the information using cryptographic key);
transmitting, to the computational instance, the encrypted version of the information (Varnamkhasti, Col 10, lines 8-11, discloses providing the encrypted information to the secure data storage (part of the computational instance));
Wherein the information comprises the authorization result (Varnamkhasti, Col 8, lines 16-31, discloses receiving authorization token from identity provider that implements OAuth, OASIS SAML);
and providing, in response to the authorization request, the result (Varnamkhasti, Col 8, lines 16-31, discloses before receiving the authorization token from the authorization servers that implement OAuth, OASIS SAML, a client is required to authenticate themselves with the identity provider, which implies sending an authorization request to the Authorization server; Col 8, lines 16-31, Varnamkhasti discloses receiving authorization token from identity provider that implements OAuth, OASIS SAML.);
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Varnamkhasti’s technique of authorization interaction and encryption. One would be motivated to perform such modification on Parekh’s system to enable authenticated access control and secure handling of authorization tokens while storing or transmitting information to remote storage, thereby improving the security and reliability of the system.
Varnamkhasti does not explicitly teach; However, Wang teaches:
receiving, from the computational instance, a second acknowledgment that the encrypted version of the result has been stored; (Wang, page 17, para 94, discloses the eTKB SDK performs cryptographic operations on the password input by the user, encrypts the operation result, and transmits the encrypted operation result to the eTKB server);
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system by incorporating Wang’s storage acknowledgement of the result. Doing so provides a closed loop confirmation that encrypted authorization outcome has been durably persisted by the computational instance, which improves transactional integrity. One would be motivated to perform such modification on Parekh’s system to enable safe retries and idempotent writes and strengthens auditability and compliance logging.
Claim(s) 10 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parekh (WO 2022081408 A1) in view of Varnamkhasti (US 10541983 B1) in view of Chilakapati (US 9819648 B1) in view of Wang (CN 113660208 B) in view of Barouch (US 20200320219 A1).
Regarding Claim 10, Parekh/Varnamkhasti/Chilakapati/Wang teaches the system of Claim 9,
Varnamkhasti teaches:
wherein transmission and storage of the encrypted version of the sensitive information is accompanied by a unique identifier and (Varnamkhasti, Col 4, lines 25-37, discloses storing encrypted form and associating each item with unique identifier as well as transmitting those unique identifiers with the encrypted data between the search system and the data storage systems);
wherein the record is the result (Varnamkhasti, Col 8, lines 16-31, discloses receiving authorization token from identity provider that implements OAuth, OASIS SAML);
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system to incorporate the identifier association technique taught by Varnamkhasti. One would be motivated to perform such modification on Parekh’s system to enable reliable tracking and retrieval of encrypted records using associated identifiers while securely handling authorization tokens during storage and transmission, thereby improving organization, lookup efficiency, and secure management of encrypted information within the system.
Varnamkhasti does not explicitly teach; However, Barouch teaches:
transmission and storage of the encrypted version of the record are each accompanied by a unique identifier (Barouch, para 6-8, discloses the identity further includes a unique identifier and both the encrypted device information and the encrypted user information are stored in association with the unique identifier; para 28, Barouch discloses request/transmission includes the unique identifier.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh/Varnamkhasti/Chilakapati/Wang’s system by incorporating Barouch’s teaching of storing encrypted data association with a unique identifier and including that identifier in requests/transmission. One would be motivated to perform such modification on Parekh/Varnamkhasti/Chilakapati/Wang’s system to enable consistent identification, tracking, and retrieval of encrypted records during transmission and storage operations, thereby improving the organization and management of encrypted data within distributed storage system.
Regarding Claim 11, Parekh/Varnamkhasti/Chilakapati/Wang/Barouch teaches the system of Claim 9,
Varnamkhasti teaches:
wherein transmission and storage of the encrypted version of the sensitive information is accompanied by a further hash value that was obtained by applying the one-way hash function to at least part of the sensitive information and (Varnamkhasti, Col 12, lines 42-57, discloses the cryptographic hash information 112 and order-preserved items of information 124A, 124B, can then be provided by the intermediate encryption retrieval system 100 to the insecure indexing system 150.);
Wherein the hash function comprises one-way hash function (Varnamkhasti, Col 8, lines 66-67, provides teaches using SHA-3 hash function which is one way hash function to generate hash value.);
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh’s system to incorporate the technique to provide the hash information together with related encrypted information to an indexing system as taught by Varnamkhasti. One would be motivated to perform such modification on Parekh’s system to allow hashed representations of information to accompany encrypted data during transmission and storage so that indexing, lookup, and referencing operations can be performed efficiently while maintaining confidentiality of the underlying information, thereby improving the secure management and retrieval of encrypted records.
Varnamkhasti does not explicitly teach; However, Barouch teaches:
transmission and storage of the encrypted version of the result is accompanied by a further hash value that was obtained by applying the hash function to at least part of the sensitive information. (Barouch, para 6-8, discloses storage of hashes associated with both the encrypted device information and the encrypted user information which is considered as sensitive (para 64); para 28, Barouch discloses request/transmission includes the unique identifier and hashes)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to have modified the Parekh/Varnamkhasti/Chilakapati/Wang’s system by incorporating Barouch’s teaching of storing encrypted data association with a unique identifier and including that identifier in requests/transmission. One would be motivated to perform such modification on Parekh/Varnamkhasti/Chilakapati/Wang’s system so that hash values derived from sensitive information accompany encrypted results during storage and transmission, thereby enabling efficient indexing, verification, and retrieval of encrypted records while maintaining confidentiality of the underlying sensitive information using well known hash-based data management techniques.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIT KHADKA whose telephone number is (703)756-1440. The examiner can normally be reached Monday - Friday, 8:00 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.
/AMIT KHADKA/Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
