DETAILED ACTION
Claims 1-20 are pending. This is in response to the application filed on August 5, 2024.
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 .
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.
Claims 1-3 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Patent 12542660 (hereinafter Nix) in view of Patent 10491576 (hereinafter Pfannenschmidt)
Regarding claim 1, Nix discloses a process, for migrating controlled data from an existing controlled data environment (CDE) to a new CDE (Summary section on col. 4 and Fig. 1i and related text on col. 42, disclose a machine-to-machine communication for a secure connection data transfer system utilizing asymmetric and symmetric key generation for a secure and efficient communication between servers where each server comprising more than one module to perform various functions) , comprising:
generating first security keys (“1st Keys”); wherein the 1st Keys include a first public key (1PUK) and a first private key (1PRK); generating an encryption context (EC); generating, based on the EC, second security keys (“2nd Keys”) (col. 7, lines 17-51 discloses a message sent from one machine to a server can be encrypted with a public key (lines 28-29) or a symmetric key (lines 23-24) and the symmetric key is derived based on public keys as the encryption context (lines 31-34)).
Nix does not disclose wherein the 2nd Keys include an encrypted 2nd Key (e2SEK) and an unencrypted 2nd Key (u2SEK). However, encrypting a wrap key is known art where a wrap is key is a symmetric key used to wrap/encrypt an encryption key. Pfannenschmidt discloses when generating a pluralities of wrap keys, they can be in both forms of plain wrap keys and encrypted wrap keys (Fig. 6 and step. 603). Therefore, it would have been obovious before the effective filing date of the claimed invention to modify Nix with Pfannenschmidt to further teach the forementioned feature. One would have done so to protect data from unauthorized data breaches for key management service (Pfannenschmidt, Background section).
Pfannenschmidt discloses encrypting, using the u2SEK, the 1PRK to generate an encrypted 1PRK (“e1PRK”) (as presented above, the wrap key is to encrypt the encryption key which is the public key of Nix);
Nix discloses:
generating a migration request; wherein the migration request requests transfer of controlled data from an existing data store (EDS) to a new data store (NDS); wherein the EDS is controlled by the existing CDE; and wherein the NDS is controlled by the new CDE; communicating, by the new CDE, the migration request and the 1PUK to the existing CDE; wherein, the existing CDE utilizes the 1PUK to encrypt the controlled data and output encrypted controlled data in a transfer file; receiving the transfer file from the existing CDE; upon receiving the transfer file: decrypting the transfer file; and storing the transfer file in the NDS (Fig. 3 at steps 314-316 for decrypting the message comprising data sensor and storing in a database).
Regarding claim 2, Nix discloses wherein the 1st Keys are asymmetrical keys; and wherein the 2nd Keys are symmetrical keys (see claim 1 rejection).
Regarding claim 3, Nix discloses wherein the 2nd Keys are generated by a key management system (KMS); and wherein the KMS is operated independently of the existing CDE and the new CDE (Fig. 1g discloses the cryptographic algorithms 141 at a server (Figs. 1d-f) functions as a KMS to generate keys).
Regarding claim 18, Nix discloses receiving at least one operational parameter (OPPS) for the new CDE; and wherein the EC is generated based on the OPPS (Fig. 6a discloses the message comprises parameters shown in 126 (SHA256, 1-week TTL, etc.) as operational parameters).
Regarding claim 19, Nix discloses generating a globally unique identifier for an encrypted storage token (EST); storing, based on the EST, the e2SEK and the e1PRK; and storing, based on the OPPS, the EST in the NDS (Fig. 6a and related text discloses a token value to make each response unique and to avoid any replay attacks. Note that the token is encrypted since the message in transit is encrypted).
Regarding claim 20, the combination of Nix and Pfannenschmidt discloses: retrieving, based on the EST, the e2SEK and the e1PRK; generating, based on the OPPS, generating a second instance of the EC (EC-2); generating a second instance of the u2SEK (u2SEK-2) based on the EC-2; and wherein the decrypting of the transfer file further comprises: decrypting, using the u2SEK-2, the e1PRK to generate a second instance of the 1PRK (1PRK-2); decrypting the transfer file, using the 1PRK-2, to generate a second instance of the controlled data; and wherein the storing of the transfer file in the NDS further comprises storing the second instance of the controlled data in the NDS (this is the reverse process to retrieve encrypted data with both the public key and the wrap key are encrypted).
Claims 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over Nix in view of Pfannenschmidt and further in view of Pub 20140013452 (hereinafter Aissi)
Regarding claim 7, Nix discloses the invention for communication in M2M environment that can apply to various applications (Technical field section from col. 1-2) but neither Nix nor Pfannenschmidt discloses wherein the encrypted controlled data in the transfer file includes corresponding user data (CUD); wherein the CUD includes user data (UD) filtered, by the existing CDE, from multiple UD entries provided in the EDS; and wherein the CUD includes UD that corresponds to at least one criteria specified in the migration request. Aissi discloses this feature (Figs. 8-10 and related text discloses certain data field(s) (e.g. 16-digit credit card number, social security, etc.) to be hashed, tokenized or encrypted based on policy parameters included in the request). Therefore, it would have been obovious before the effective filing date of the claimed invention to modify Nix and Pfannenschmidt with Aissi to further teach the forementioned feature. One would have done so to protect data with data protection policy can satisfy to a compliance standard or data protection law such as PCI DSS, HIPAA, etc. (Aissi, par. [0040]-[0041]).
Regarding claim 8, Aissi discloses wherein the encrypted controlled data in the transfer file includes corresponding user data (CUD) set forth in two or more rows (Figs. 8-10 and 14 discloses migration data can be a database, hence there can be more than two rows of records to be pulled for migration).
Regarding claim 9, Aissi discloses wherein each row of the two or more rows includes personally identifiable data (PID) for a given user; wherein the PID includes data that is payment card industry (PCI) compliant; wherein the existing CDE is an existing PCI Compliant Controlled Data Environment (EPCI-CDE); wherein the new CDE is a new PCI Compliant Controlled Data Environment (NPCI-CDE); and wherein the transfer file is a PCI compliant transfer file (PTF) (par. [0041] discloses data protection policy may include some or all aspects of a compliance standard or data protection law, such as the Payment Card Industry Data Security Standard (PCI DSS) which includes secure processing, storage and transmission).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Nix in view of Pfannenschmidt and further in view Pub 20110305342 (hereinafter Manaka)
Regarding claim 4, Nix and Pfannenschmidt do not disclose wherein the EC identifies the NDS as a designated storage location for the transfer file. Manaka discloses this feature (par. [0025] discloses a storage location associated with encrypted content and a device key used in generation of the encrypted content). Therefore, it would have been obovious before the effective filing date of the claimed invention to modify Nix and Pfannenschmidt with Manaka to further teach the forementioned feature. One would have done so using known location-base for key generation process to arrive at the claimed invention with reasonable expectation of success.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Nix in view of Pfannenschmidt, Manaka and further in view Pub 11822699 (hereinafter Heart)
Regarding claim 5, Nix and Pfannenschmidt do not disclose discarding the 1PRK; storing the e1PRK in a staging vault controlled by the new CDE; and storing the e2SEK in the staging vault. Heart discloses a system to prevent unauthorized access to files where a public key and a symmetric key are used in encrypting files and encrypting encryption key. Both keys are destroyed after the encryption and only the encrypted keys are kept in a location (col. 32, line 60 col. 34, line 6). Therefore, it would have been obovious before the effective filing date of the claimed invention to modify Nix, Pfannenschmidt and Manaka with Heart to further teach the forementioned feature. One would have done so providing countermeasures employed in some implementations to inhibit an attacker, including disabling direct access to storage devices and preventing third-party applications from linking to system library functions that permit direct access to storage devices (Heart: col. 5, lines 63-65).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Nix in view of Pfannenschmidt, Manaka and Heart and further in view Patent 12367146 (hereinafter Boles)
Regarding claim 6, Nix, Pfannenschmidt, Manaka and Heart do not disclose wherein the receiving of the transfer further comprises: receiving, by the new CDE from the existing CDE, a message indicating that a first transfer of the transfer file from an existing CDE data store (EDS) to a first secure file transfer data store (1SFT) associated with the existing CDE has occurred; second instructing the 1SFT to second transfer the transfer file from the 1SFT to a second secure file transfer data store (2SFT) associated with the new CDE; and third instructing the 2SFT to third transfer the transfer file from the 2SFT to a staging vault associated with the new CDE. Boles discloses this features (Fig. 10 and related text on col. 8-9 discloses when data sent from the Host A to the Host B to another device it goes from Host A (e.g. CDE) to a S/W controlled memory (e.g. 1SFT) then to Host B cache (e.g. 2SFT) to Host B (e.g. staging vault). Therefore, it would have been obovious before the effective filing date of the claimed invention to modify Nix, Pfannenschmidt, Manaka and Heart with Boles to further teach the forementioned feature. One would have done so utilizing share data between host computers using remote direct memory access (RDMA) to migrate data from the memory of one computer into that of another without involving either one's operating system (Boles, col. 3, lines 52-62).
8. Claims 10-11 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Nix in view of Pfannenschmidt, Aissi and further in view of Patent 12518034 (hereinafter Boesgaard)
Regarding claim 10, Aissi discloses encrypting data for migration between hubs in database format but does not at a detail level how each is encrypted. Boesgaard discloses each row of data can be encrypted with different key and each row would have a Key column to identify whether a row is encrypted or not (Fig. 4 and related text on col. 8). Hence, when data is transferred in Aissi it will be decrypt using the same encryption public key then each row can be encrypted as taught in Boesgaard. Therefore, it would have been obovious before the effective filing date of the claimed invention to modify Nix, Pfannenschmidt, and Aissi with Boesgaard to further teach wherein the decrypting of the transfer file, uses a second instance of the 1PRK (1PRK-2), to generate a second instance of the controlled data and further comprises operations including: generating third security keys (“3rd Keys”); and for a given row of the two or more rows in the transfer file: separately decrypting the given row to generate a given row of unencrypted CUD; re-encrypting, using the 3rd Keys, the given row of unencrypted CUD to generate a given 3rd Key encrypted row of CUD; storing the given 3rd Key encrypted row of CUD in a staging vault (SV); and publishing a row identifier (RID) for the, as stored, given 3rd Key encrypted row of CUD; and repeating the operations above for each of the two or more rows. One would have done so to improve security, improve protection of personal information, aid complying with privacy regulations, reduce the risk of data leak as desired in Boesgaard.
Regarding claim 11, Nix, Pfannenschmidt, Aissi and Boesgaard discloses wherein the 3rd Keys are symmetric keys and include an encrypted 3rd Key (e3SEK) and an unencrypted 3rd Key (u3SEK) (Nix can encrypt data in either with a symmetric key or a public key. Pfannenschmidt discloses encrypted and unencrypted symmetric keys as presented in claim 1 rejection).
Regarding claim 13, Aissi discloses wherein each row includes personally identifiable data (PID) for a given user (Fig. 8 discloses social security number).
Allowable Subject Matter
Claims 12 and 14-17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Inquiry communication
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRI M TRAN whose telephone number is (571)270-1994. The examiner can normally be reached Mon-Fri: 9am-5pm.
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 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.
/TRI M TRAN/Primary Examiner, Art Unit 2432