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 . 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 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.
Response to Arguments
Applicant’s arguments, see page 9-10, filed 10/16/2025, with respect to claim 1 have been fully considered and are persuasive. The rejection under 35 USC § 112 (a) of 08/05/2025 has been withdrawn.
Applicant's arguments filed 10/16/2025 have been fully considered but they are not persuasive. Applicant argues on page 10 “Chitkara also does not disclose the above amended features at least for the same reasons”
Examiner respectfully disagree. Chitkara expressly teaches that the encryption key hierarchy includes “column encryption key(s)” as one of the encryption key types. See Chitkara ¶35 (“Examples of such encryption key types can include … column encryption key(s) …”). A person of ordinary skill in the art would therefore understand that any set of encryption keys drawn from Chitkara’s hierarchy can include one or more column encryption keys, as now recited, and that this is a routine design choice within the disclosed key hierarchy.As to the applicant’s arguments with regards to: “However, Chitkara operates in an exact opposite direction. Chitkara discusses that "when a data encryption key is encrypted with master key, master key needs to be accessible at the target server." (Chitkara, [0070].) Thus, in Chitkara's system, the master key is moved to the target server and there is no need to decouple the at least one KEK and the at least one DEK from the master key. Accordingly, Chitkara teaches away from "decrypt one or more encryption keys of the first master database and the first user database using a first master key of the first master database, wherein the one or more encryption keys include at least one key encryption key (KEK) of the first user database and at least one data encryption key (DEK) of the first master database," as required by independent claim 1 and similarly required by independent claims 11 and 16. ”
Examiner respectfully disagrees. Chitkara ¶70 merely describes one implementation in which the master key is made accessible at the target server so that DEKs encrypted with that master key can be used there; it does not criticize, discourage, or exclude alternative implementations in which keys encrypted by the master key are first decrypted and then re-encrypted under a different protection scheme. In fact, Chitkara already contemplates additional layers of protection for keys (e.g., encrypting master keys and DEKs using an external keystore/HSM), which shows flexibility in how keys may be protected and transferred rather than a rigid requirement to always move the master key itself.
Moreover, Antonopoulos expressly teaches decrypting data encryption keys using a master key before use. See Antonopoulos ¶86 (database application “may decrypt the encrypted data encryption keys … using a master key”). A person of ordinary skill in the art would have found it obvious to apply this well-known technique in the context of Chitkara’s database migration—namely, to decrypt DEKs and other encryption keys with the master key and then, as taught by Woo, re-encrypt those keys using a public key for secure transfer and later decryption with the corresponding private key.
Accordingly, even if Chitkara alone does not implement the claimed decrypt-then-re-encrypt flow, it does not teach away from it, and the combined teachings of Chitkara, Antonopoulos, and Woo render obvious “decrypt[ing] one or more encryption keys of the first master database and the first user database using a first master key … [including] at least one KEK … and at least one DEK …” as recited in claims 1, 11, and 16.
Applicant’s arguments with respect to claim(s) 1, 11 that have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
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) 1-4, 8, 11-15 are rejected under 35 U.S.C. 103 as being unpatentable over Chitkara et al (U. S. PGPub. No. 2021/0143989 A1) (hereinafter ("Chitkara") in view of WOO et al. (U. S. PGPub. No. 2022/0209940 A1) (hereinafter “Woo”) and Antonopoulos et al. (U.S. PGPub. No. 2016/0292430 A1) (hereinafter “Antonopoulos”) and Ahmed (U. S. PGPub. No. 2019/0036678 A1) (hereinafter “Ahmed”); and in further of Wisniewski et al. (U. S. PGPub. No. 2020/0053065 A1) (hereinafter “Wisniewski”)
Regarding Claim 1, Chitkara teaches:
a first database server comprising: a first memory configured to store (Chitkara: [0203], Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501) a first master database ; (Chitkara: FIG.7 and [0076] SAP ASE treats database encryption keys (DEK) a specific manner Database encryption keys reside in the master database only. Importing the DEK creates the DEK at the target server in master database encrypted with master key of master database. Where the master key of the master database does not exist on the target server, then the server produces an error because DEK cannot be kept encrypted with user password. [0123] of an entire encrypted database; [0124] from the source ASE server having the master key of the master database encrypted with the key from external keystore, [0125] to the target ASE server having a different key from a different external keystore);
at least a first processor coupled to the first memory and configured to (Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501):
PNG
media_image1.png
858
896
media_image1.png
Greyscale
wherein the one or more encryption keys include at least one data encryption key (DEK) of the first master database that are encrypted by a first master key of the first master database (Chitkara: [0066] Specifically, a master key encrypts data encryption keys (master key encrypts KEK), which in turn are used to encrypt data. In order to impart additional security, the ASE environment may encrypt the master keys, the data encryption keys, or both, using keys in an external keystore [0067] a Hardware Security Module (HSM) Device). [0076] SAP ASE treats database encryption keys (DEK) a specific manner Database encryption keys reside in the master database only. [0122], The DEK present in the master database is encrypted with master key),
wherein the set of encryption keys includes one or more column encryption keys (Chitkara: [0035] Encryption keys of various types 132 may be members of different key hierarchies. Examples of such encryption key types can include but are not limited to: [0036] external key(s) [0037] master key(s) [0038] database encryption key(s) [0039] column encryption key(s) (=one or more column encryption keys) [0040] service key(s) [0041] dual master key(s) [0042] recovery key(s) [0043] log encryption key(s) [0044] proprietary logic encryption key(s) [0045] backup encryption key(s) [0046] application data encryption key(s); and [0047] others);
generate a database backup file based on data content of the first user database and the one or more encryption keys, wherein the data content is encrypted by at least one DEK of first master database (Chitkara: [0069] In order to migrate encrypted data from one database server to another, a quantity of data is taken and loaded at the target server. To access the encrypted data at the target server, the hierarchy of encryption keys must be accessible at the target server. [0122] FIG. 7 shows a simplified schematic view of a second, more complex use case. This second use case involves transfer (=Examiner interpreting transferring process as a backup processes of the database) generating backup of the source encrypted database at the target server in target encrypted database): [0123] of an entire encrypted database; [0124] from the source ASE server having the master key of the master database encrypted with the key from external keystore, [0125] to the target ASE server having a different key from a different external keystore. And
PNG
media_image2.png
812
823
media_image2.png
Greyscale
and transmit the database backup file to a second database server (Chitkara: [0022], The source database may access backup 117 resources in order to preserve data outside of the database environment. One or more aspects of these external links to the source database may be controlled by security keys belonging to the hierarchy. [0057] At 206, in response to the transfer command (=transmit), the first security key is communicated securely according to the SQL command details, to a target database also receiving encrypted information loaded from the source database. [0069] In order to migrate encrypted data (=transmit encrypted back up file) from one database server to another, a quantity of data is taken and loaded at the target server (=second database server). To access the encrypted data at the target server (=second database server), the hierarchy of encryption keys must be accessible at the target server);
and the second database server comprising: a second memory configured to (Chitkara: [0201] Rather, alternative embodiments could leverage the processing power of an in-memory database engine (e.g., the in-memory database engine of the HANA in-memory database available from SAP SE), in order to perform various functions); store a second master database and a second user database (Chitkara: [0136] At the target ASE database (=second database server), per the following pseudocode the DEK will be transferred using the file (1a in FIG. 7) and encrypted with the master key of the master database on the target ASE (1b in FIG. 7) as part of TRANSFER ENCRYPTION KEY statement. [0137] use master [0138] create encryption key target_hsm_key on external keystore [0139] create encryption key master with external key [0140] transfer encryption key dek [0141] with passwd ‘mysecret8’ [0142] from ‘/path/to/file’ [0143] create database target_encrdb encrypt with dek [0144] load database target_encrdb from ‘/path/to/dumpfile’ [0145] online database target_encrdb);
receive the database backup file from the first database server (Chitkara: [0058] Once transferred, the security key can be referenced to decrypt encrypted information (=encrypted backup file) at the target database, upon receiving a query from a user);
decrypt the data content of the first user database using the at least one decrypted DEK (Chitkara: [0058] Once transferred, the security key can be referenced to decrypt encrypted information (=encrypted backup file) at the target database, upon receiving a query from a user);
and generate data content of the second user database (Chitkara: [0054] Returning to FIG. 1, upon receipt of the encryption key the target server stores that key within the target key hierarchy 152. The key may be referenced by the target server (=second user database) in decrypting database data (=data content) (e.g., in response to a query), that has been loaded from the source database in encrypted form (as part of database migration). [0057] At 206, in response to the transfer command, the first security key is communicated securely according to the SQL command details, to a target database (=second user database) also receiving encrypted information loaded from the source database (=first user database). and the decrypted data content of the first user database (Chitkara: [0058] Once transferred, the security key can be referenced to decrypt encrypted information (=decrypted data content) at the target database, upon receiving a query from a user)
PNG
media_image3.png
832
801
media_image3.png
Greyscale
(Chitkara: [0041] dual master key(s) (=a second master key). [0172], [0173] of a cleartext database containing master key encrypted with key from external keystore, [0174] from the source ASE server)
Chitkara does not explicitly disclose:
wherein a set of encryption keys of the first user database is encrypted by the at least one KEK;
generate at least one further encrypted KEK by encrypting the at least one decrypted KEK
wherein the one or more encryption keys include at least one key encryption key (KEK) of the first user database
generate at least one encrypted KEK and at least one encrypted DEK by encrypting the at least one decrypted KEK and the at least one decrypted DEK using a public key;
and wherein the database backup file includes the set of encryption keys, the at least one encrypted DEK, the at least one encrypted KEK, and the public key;
retrieve the at least one encrypted DEK, the at least one encrypted KEK, and the public key from the database backup file;
retrieve a plurality of private keys from the second memory;
determine that a private key of plurality of private keys matches the public key;
generate the at least one decrypted DEK and the at least one decrypted KEK by decrypting the at least one encrypted DEK and the at least one encrypted KEK using the private key;
generate at least one further encrypted KEK by encrypting the at least one decrypted KEK
generate data content of the second user database based on the at least one further encrypted KEK and the decrypted data content of the first user database.
However, in an analogous art, Woo teaches:
wherein a set of encryption keys of the first user database is encrypted by the at least one KEK (Woo: [0102], In an embodiment, the at least one processor 232 may encrypt the KEK using a third symmetric key or a unique public key of the IoT device 230.);
generate at least one further encrypted KEK by encrypting the at least one decrypted KEK (Woo: [0145], In an embodiment, in operation 980, the at least one processor 232 may encrypt the decrypted KEK (=further encryption = re-encryption) using a public key of an app of the user terminal 220)
wherein the one or more encryption keys include at least one key encryption key (KEK) of the first user database (Woo: [0104], In an embodiment, when a client application 621 in the user terminal 220 receives the KEK from the device management server 611, the at least one processor 222 may store the KEK in a key storage 622. In an embodiment, the memory 223 may include the key storage 622)
generate at least one encrypted KEK (Woo: [0102], In an embodiment, the at least one processor 232 may encrypt the KEK using a third symmetric key or a unique public key of the IoT device 230.).
generate (Woo: [0077], A data encryption key (DEK) according to various embodiments of the disclosure may include a content key capable of encrypting or decrypting data or content… In a case of using an asymmetric key according to various embodiments of the disclosure, a public key may be used for encryption);
generate the at least one decrypted DEK (Woo: [0077], a secret key capable of encrypting or decrypting a DEK. In a case of using an asymmetric key according to various embodiments of the disclosure, a public key may be used for encryption, and a secret key may be used for decryption);
retrieve the at least one encrypted DEK (Woo: [0164], In an embodiment, in operation 1255, the user terminal 220 may download the encrypted clip and the DEK corresponding thereto from the clip storage address), the at least one encrypted KEK (Woo: [0102], In an embodiment, the encrypted KEK may be transmitted together with a request to store the KEK, and at least one identifier corresponding to the request to store. [0187], The at least one processor 232 may transfer the encrypted KEK to the user terminal 220 through the communication circuit 231), and the public key from the database backup file (Woo: [0104], In an embodiment, the memory 223 may include the key storage 622. In an embodiment, the key storage 622 may store a key pair (a public key and a secret key) of the user terminal 220 in which the client application 621 is installed);
generate (Woo:[0105], In an embodiment, the at least one processor 232 may decrypt the encrypted KEK using a secret key)
generate at least one further encrypted KEK by encrypting the at least one decrypted KEK (Woo: [0145], In an embodiment, instead of operation 965 to operation 980, the at least one processor 232 may encrypt a KEK stored in the memory 233. [0146], In an embodiment, in operation 990, the at least one processor 222 may decrypt the encrypted KEK using a secret key of the app of the user terminal 220).
(Woo: [0181], In an embodiment, the at least one processor 232 may encrypt the newly generated KEK (=further encrypted KEK) using a public key of an app of the user terminal 220, which is included in the terminal certificate chain, and then may transfer the encrypted KEK to the user terminal 220 through the communication circuit 231.).
generate data content of the second user database (Woo: [0165], In an embodiment, in operation 1270, if the input unit 225 of the user terminal 220 senses (e.g., receives) an input, the at least one processor 222 may reproduce the decrypted clip (=Data content) through the display 224. In an embodiment, clip decryption of operation 1265 and/or decrypted clip reproduction of operation 1270 may be performed without a user's input) based on the at least one further encrypted KEK (Woo: [0187]. The at least one processor 232 may transfer the encrypted KEK to the user terminal 220 through the communication circuit 231. In an embodiment, the at least one processor 222 of the user terminal 220 may decrypt the newly generated encrypted KEK (=further encrypted key) transferred from the IoT device 230, using the secret key of the app of the user terminal 220. In an embodiment, the at least one processor 222 may update the memory 223 with the decrypted new KEK.) and the decrypted data content of the first user database (Woo: [0100] In an embodiment, the at least one processor 222 may reproduce the decrypted video clip 521 and display same through the display 224).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Chitkara’s method of generating backup database by transmitting or migrating or receiving encrypted database from source server to target server and decrypt encrypted back up at the target server by applying Woo’s method of encrypting KEK and DEK using public key and decrypting KEK and DEK using private key in order to provide high security for data transmission.
Chitkar in view of Woo does not explicitly disclose:
decrypt one or more encryption keys of the first master database and the first user database using a first master key of the first master database (Antonopoulos: [0086], Note that the received data encryption key(s) (=one or more encryption keys which includes DEK) may be encrypted, and therefore, prior to using, the database application may decrypt the encrypted data encryption key(s) (=one or more encryption keys which includes DEK) using a master key… [0057] As shown in FIG. 3, key store (=master database) 314 includes a master key 316, a first key 318a, a second key 318b, and any additional number of encryption keys)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Woo by applying the well-known technique as disclosed by Antonopoulos of decrypting data encryption keys using a master key. The motivation is to protect against data leakage or malicious corruption (Antonopoulos: [0002]).
Chitkara in view of Woo and Antonopoulos does not explicitly disclose:
retrieve a plurality of private keys from the memory;
determine that a private key of the plurality of private keys matches the public key.
However, in an analogous art, Ahmed teaches:
retrieve a plurality of private keys from the memory (Ahmed: [0202], obtain unique private keys);
determine that a private key of the plurality of private keys matches the public key (Ahmed: [0544], in RSA, each public key is matched with just one unique private key. More specifically, in the RSA algorithm, the public key is (e, n) and private key is (d, n). The key pair is always unique for each user. It means that for each public key there always exist a unique private key and for every private key there exist a unique public key);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Woo and Antonopoulos by applying the well-known technique as disclosed by Ahmed of obtaining unique private key and determining that unique private kay matched with public key in order to enabling secure, authenticated communication and ensuring confidentiality, authenticity, and integrity for data exchange like HTTPS, secure email, and blockchain. The motivation is to process encrypted data efficiently without requiring excessive amounts of computing power or memory relative to the processing of the underlying encrypted data (Ahmed: [0010]).
Chitkara in view of Woo, Antonopoulos and Ahmed does not explicitly disclose following claim limitations but Wisniewski teach:
wherein the database backup file includes the set of encryption keys, the at least one encrypted DEK, the at least one encrypted KEK, and the public key (Wisniewski: [0037], [0037] In some cases, durable copies of the key may only be stored in the HSMs 205… The current BYOK KEK copy may be exportable, but only by operation of the key management system 200, and then only if wrapped with the public key of another, authorized HSM 205… [0046] The cloud storage 270 may store offline backups of data from the database 215. The data may be encrypted a second time (e.g., using a backup key stored in the HSMs 205) before being written to the cloud storage 270. The cloud storage 270 may also be used to store offsite backups of the encrypted HSM configuration)
wherein the one or more encryption keys include at least one key encryption key (KEK) of the first user database (Wisniewski: US 2020/0053065 A1): [0083], a set of encryption keys encrypted by the first KEK. [0041] A client 235 may be an example of a tenant of the database 215 (=first user database). The client 235 may provide a set of encryption keys to the database 215 to be managed by the key management system 200 (examiner interpreting that the client provides a set of encryption keys it means it is “a set of key encryption leys of the user database”))
wherein a set of encryption keys of the first user database is encrypted by the at least one KEK (Wisniewski et al (US 2020/0053065 A1): [0083], a set of encryption keys encrypted by the first KEK. [0041] A client 235 may be an example of a tenant of the database 215 (=first user database). The client 235 may provide a set of encryption keys to the database 215 to be managed by the key management system 200 (examiner interpreting that the client provides a set of encryption keys it means it is “a set of key encryption leys of the user database”));
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Woo, Antonopoulos and Ahmed by applying the well-known technique as disclosed by Wisniewski of encrypting a set of encryption keys by using the first KEK. The motivation is to encrypting data stored within the system to enhance security (Wisniewski: [0004]).
Regarding claim 2, Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski teaches:
The system of claim 1 (see rejection of claim 1 above),
wherein to select the one or more encryption keys, the at least the first processor is further configured to (Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501) select the at least one KEK from the first user database (Chitkara: [0076] SAP ASE treats database encryption keys (DEK) a specific manner Database encryption keys reside in the master database only. [0136] At the target ASE database, per the following pseudocode the DEK will be transferred (=DEK (=encryption key) is getting selected and transfer to the target server) using the file (1a in FIG. 7) and encrypted with the master key of the master database on the target ASE (1b in FIG. 7) as part of TRANSFER ENCRYPTION KEY statement),
wherein the at least one KEK is encrypted by the master key of the first master database (Chitkara: Examiner interpreting the first master database as the master database at the source sever in the Chitkara Prior art) in the [0070] Thus, when a data encryption key is encrypted with master key, master key needs to be accessible at the target server. Where the master key is encrypted with a key from external keystore at the source server, and the external keystore is not accessible at the target server, a mechanism is required to securely transfer the data encryption key and/or master key from the source server to the target server);
Regarding Claim 3, Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski teaches:
The system of claim 1 (see rejection of claim 1 above),
wherein to select the one or more encryption keys, the at least the first processor is further configured to: (Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501) select the at least one DKE from the first master database (Chitkara: Examiner interpreting first master database is same as master database as cited in Claim 1) [0076] SAP ASE treats database encryption keys (DEK) a specific manner Database encryption keys reside in the master database only. [0136] At the target ASE database, per the following pseudocode the DEK will be transferred (=DEK (=encryption key) is getting selected and transfer to the target server) using the file (1a in FIG. 7) and encrypted with the master key of the master database on the target ASE (1b in FIG. 7) as part of TRANSFER ENCRYPTION KEY statement), wherein the at least one DEK is encrypted by the master key of the first master database (Chitkara: [0070] Thus, when a data encryption key is encrypted with master key, master key needs to be accessible at the target server. Where the master key is encrypted with a key from external keystore at the source server, and the external keystore is not accessible at the target server, a mechanism is required to securely transfer the data encryption key and/or master key from the source server to the target server);
Regarding claim 4, Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski teaches:
The system of claim 1 (see rejection of claim 1 above),
wherein the at least the first processor is further configured to (Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501):
encrypt the one or more encryption keys (Chitkara: [0070] Thus, when a data encryption key is encrypted with master key, master key needs to be accessible at the target server. Where the master key is encrypted with a key from external keystore at the source server, and the external keystore is not accessible at the target server, a mechanism is required to securely transfer the data encryption key and/or master key from the source server to the target server);
and generate the database backup file based on data content of the first user database and the encrypted one or more encryption keys (Chitkara: [0172] FIG. 9 shows a simplified schematic view of a fourth and final use case. This use cases involves the transfer: [0173] of a cleartext database containing master key encrypted with key from external keystore, [0174] from the source ASE server, [0175] to the target ASE server having different key from a different external keystore. In this fourth use case, CEK in the database is encrypted with master key of the database [0188] Per the following pseudocode, at the target ASE database a master key will be transferred using the file (2a in FIG. 9) and encrypted with key from external keystore (2b in FIG. 9) on the target ASE as part of TRANSFER ENCRYPTION KEY statement. [0189] use master [0190] create encryption key target_hsm_key on external keystore [0191] create database target_db [0192] load database target_db from ‘/path/to/dumpfile’ [0193] online database target_db [0194] use target_db [0195] transfer encryption key master [0196] with passwd ‘mysecret8’ [0197] from ‘/path/to/file’ [0198] with override).
Regarding Claim 8, Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski teaches:
The system of claim 1 (see rejection of claim 1 above), The system of claim 1,
wherein the at least the second processor is further configured to (chitkara: [0069] In order to migrate encrypted data from one database server to another, a quantity of data is taken and loaded at the target server. To access the encrypted data at the target server, the hierarchy of encryption keys must be accessible at the target server. Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information):
determine the master key of the second master database (Chitkara: [0074] In the ASE database environment, importing master key in a particular database will create the master key at the target server encrypted with the key from external keystore. [0075] Also, importing data encryption keys in a particular ASE database will create the data encryption keys at the target server encrypted with the master key of the corresponding database);
encrypt the at least one DEK of the one or more encryption keys using the master key of the second master database (Chitkara: [0066] Specifically, a master key encrypts data encryption keys, which in turn are used to encrypt data. [0076] SAP ASE treats database encryption keys (DEK) a specific manner Database encryption keys reside in the master database only. Importing the DEK creates the DEK at the target server in master database encrypted with master key of master database);
and store the encrypted at least one DEK of the one or more encryption keys in the second master database (Chitkara: [0122], The DEK present in the master database is encrypted with master key. [0136] At the target ASE database, per the following pseudocode the DEK will be transferred using the file (1a in FIG. 7) and encrypted with the master key of the master database on the target ASE (1b in FIG. 7) as part of TRANSFER ENCRYPTION KEY statement).
Regarding Claim 11, this claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (computer-readable medium). For this reason, the same grounds of rejection are applied to claim 11.
Regarding Claim 12, this claim contains identical limitations found within that of claim 2 above albeit directed to a different statutory category (computer-readable medium). For this reason, the same grounds of rejection are applied to claim 12.
Regarding Claim 13, this claim contains identical limitations found within that of claim 3 above albeit directed to a different statutory category (computer-readable medium). For this reason, the same grounds of rejection are applied to claim 13.
Regarding Claim 14, this claim contains identical limitations found within that of claim 5 above albeit directed to a different statutory category (computer-readable medium). For this reason, the same grounds of rejection are applied to claim 14.
Regarding Claim 15, this claim contains identical limitations found within that of claim 6 below albeit directed to a different statutory category (computer-readable medium). For this reason, the same grounds of rejection are applied to claim 15.
Claim(s) 5-7, 9, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Chitkara et al (U. S. PGPub. No. 2021/0143989 A1) (hereinafter ("Chitkara") in view of WOO et al. (U. S. PGPub. No. 2022/0209940 A1) (hereinafter “Woo”) and Antonopoulos et al. (U. S. PGPub. No. 2016/0292430 A1) (hereinafter “Antonopoulos”) and Ahmed (U. S. PGPub. No. 2019/0036678 A1) (hereinafter “Ahmed”) and Wisniewski et al. (U. S. PGPub. No. 2020/0053065 A1) (hereinafter “Wisniewski”); and further in view of Ford et al (U. S. Pat. No. 9,904,629 B2) (hereinafter “Ford”).
Regarding Claim 5, Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski teaches:
The system of claim 4 (see rejection of claim 4 above),
Chitkara in view of Woo, Ahmed and Wisniewski does not explicitly disclose:
wherein to encrypt the one or more encryption keys,
However, in an analogous art, Ford teaches:
wherein to encrypt the one or more encryption keys (Ford: [Col 6, lines 7-11], These HSMs, in some embodiments, are located in a secure and controlled environment, and each of the HSMs is a physical device capable of performing asymmetric cryptography with its own public/private key pair. [Col 11, lines 57-61], The encryption function 600, in some embodiments, is an asymmetric encryption function, such as RSA, DSS, elliptic curve encryption, etc., and may be the same as the encryption function 500 of FIG. 5).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Woo, Antonopoulos, Ahmed, and Wisniewski by applying the well-known technique as disclosed by Ford of asymmetric encryption function. The motivation is to store the confidential data in such a way that the data is protected from attackers (Ford: Col 1, lines 13-14].
Regarding Claim 6, Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski and Ford teaches:
(Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501):
The system of claim 5 (see rejection of claim 5 above),
wherein to encrypt the one or more encryption keys using asymmetric cryptography, (Ford: [Col 6, lines 7-11], These HSMs, in some embodiments, are located in a secure and controlled environment, and each of the HSMs is a physical device capable of performing asymmetric cryptography with its own public/private key pair. [Col 11, lines 57-61], The encryption function 600, in some embodiments, is an asymmetric encryption function, such as RSA, DSS, elliptic curve encryption, etc., and may be the same as the encryption function 500 of FIG. 5):
encrypt the one or more encryption keys using a public key (Ford: [Col 1, lines 64-67]], (5) In order for a device to access the keybag in order to use the backup to restore the confidential data items, several copies of the master recovery key (=one or more encryption keys) are encrypted with the public keys of the different devices that share some or all of the confidential data items).
wherein the database backup file further includes the public key or a file path of the public key (Ford: [Col 8, lines 30-43], The new device then generates the escrow key from this passcode, and transmits this to the secure servers in an attempt to access the recovery key associated with the selected device, and thereby access the master recovery key stored with the backup (and subsequently, the backup keybag encrypted with the master recovery key). (38) In some embodiments, any device can access the backup storage 120 to request the encrypted backup data 135, the keybag encrypted with the master recovery key 140, and the master recovery keybag 145 (or one of the entries therein), as the device will not be able to recover the data without the recovery key 210 (or one of the other recovery keys) anyway),
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski by applying the well-known technique as disclosed by Ford of encrypting master recovery keys (=encryption keys) using public key. The motivation is to allow the transmission of the encrypted recovery key back to the new device by the secure servers (Ford: Col 2, lines 34-39].
Regarding Claim 7, Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski and Ford teaches:
The system of claim 6 (see rejection of claim 6 above),
wherein the at least the second processor is further configured to (Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501):
retrieve the public key based on the database backup file (Ford: [col 1, lines 64-67] – [Col 2, lines 1-6], (5) In order for a device to access the keybag in order to use the backup to restore the confidential data items, several copies of the master recovery key are encrypted with the public keys of the different devices that share some or all of the confidential data items. As part of the data sharing process, the set of related devices share their public keys with each other, and these public keys (which are each part of a separate public/private key pair generated by their respective device) are used to encrypt the master recovery key. (Ford: [Col 7, lines 42-44], The HSM then sends the recovery key 210 to the new device 200 via the secure channel. [Col 7, lines 29-33], The set of secure servers then transmits the recovery key 210 (still encrypted with the private escrow key, in some embodiments) to the new device, so that the new device can use the private escrow key to decrypt the recovery key]. [Col 19, lines 60-65], Next, the process 1200 retrieves (at 1235) the backup keychain data, encrypted keybag, and at least one master recovery object from the backup storage. As mentioned, the backup storage may be a local drive owned by the user of the new device, or could be located in cloud storage associated with a user account to which the user has already logged in);
determine the private key based on the public key (ford: [col 3, lines 19-25], The set of data is used to generate a private key, which in turn is used to generate a public key. The public key is used to encrypt various data (e.g., the keybag encrypted with the public master recovery key, the master recovery key copies encrypted with the public keys of the devices, etc.), while the private key is used to decrypt data encrypted with its corresponding public key);
and decrypt the one or more encryption keys using the private key (Ford: [Col 2, lines6-8], As such, any of the devices can decrypt one of the copies of the master recovery key (=encryption key) using its own private key).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Woo, Ahmed and Wisniewski by applying the well-known technique as disclosed by Ford of decrypting master recovery key (encryption keys) using private key in order to any of the devices can decrypt one of the copies of the master recovery key using its own private key, and thereby access the keybag and confidential data items (Ford: [Col 2, lines 6-8])
Regarding Claim 9, Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski teaches:
The system of claim 1 (see rejection of claim 1 above),
wherein to generate the data content of the second user database (Chitkara: [0054] Returning to FIG. 1, upon receipt of the encryption key the target server stores that key within the target key hierarchy 152. The key may be referenced by the target server (=second user database) in decrypting database data (=data content) (e.g., in response to a query), that has been loaded from the source database in encrypted form (as part of database migration). [0057] At 206, in response to the transfer command, the first security key is communicated securely according to the SQL command details, to a target database (=second user database) also receiving encrypted information loaded from the source database (=first user database)), at least the second processor is further configured to (Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501):
determine the master key of the second master database (Chitkara: [0074] In the ASE database environment, importing master key in a particular database will create the master key at the target server encrypted with the key from external keystore).
encrypt the first KEK using the master key of the second master database (Chitkara: [0066] Specifically, a master key encrypts data encryption keys, which in turn are used to encrypt data. [0076] SAP ASE treats database encryption keys (DEK) a specific manner Database encryption keys reside in the master database only. Importing the DEK creates the DEK at the target server in master database encrypted with master key of master database);
Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski does not explicitly disclose:
retrieve a first KEK of the one or more encryption keys from the database backup file; and update the data content by replacing a second key encryption key of the data content of the second user database with the first key encryption key.
However, Ford teaches:
retrieve a first KEK of the one or more encryption keys from the database backup file (Ford: [Col 1, lines53-56], Each of the pieces of confidential data is encrypted with a data encryption key (or item key). As such, recovering the stored backup also requires access to the data encryption keys);
and update the data content by replacing a second KEK of the data content of the second user database with the first KEK (Ford: FIG 17 explains the updating a backup data process and [Col 25, lines 43-48], The transaction log 1850 of some embodiments stores a log of changes to the keychain data in some embodiments. These changes may include the addition, removal, or changing of keychain data (changes to a keychain data item may, in some embodiments, be treated as a removal of the data item with a subsequent addition of a new data item). [Col 27, lines 6-8], (125) The process also adds (at 1735) item keys for the new items to the keybag and removes item keys that are no longer needed).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski by applying the well-known technique as disclosed by Ford of updating the content of back up data using encryption key, in order to update a backup that was previously created for the set of devices (or for a particular view), or the device that created the backup automatically updates the backup. The motivation is rather than deleting an existing backup and re-creating the backup with the entire set of synchronization data, some embodiments use a transaction log to update the backup by only modifying the backup based on changes since the backup was created (or last updated). (Ford: [Col 25, lines 4-12].
Claim(s) 10, are rejected under 35 U.S.C. 103 as being unpatentable over Chitkara et al (U. S. PGPub. No. 2021/0143989 A1) (hereinafter ("Chitkara") in view of WOO et al. (U. S. PGPub. No. 2022/0209940 A1) (hereinafter “Woo”); Antonopoulos et al. (U. S PGPub. No. 2016/0292430 A1) (hereinafter “Antonopoulos”), Ahmed (U. S. PGPub. No. 2019/0036678 A1) (hereinafter “Ahmed”) and further of Wisniewski et al. (U. S. PGPub. No. 2020/0053065 A1) (hereinafter “Wisniewski”), and in view of Ford et al (U. S. Pat. No. 9,904,629 B2) (hereinafter “Ford”);
Regarding Claim 10, Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski and ford teaches:
The system of claim 9 (see rejection of claim 9 above),
wherein to generate the data content of the second user database (Chitkara: [0054] Returning to FIG. 1, upon receipt of the encryption key the target server stores that key within the target key hierarchy 152. The key may be referenced by the target server (=second user database) in decrypting database data (=data content) (e.g., in response to a query), that has been loaded from the source database in encrypted form (as part of database migration). [0057] At 206, in response to the transfer command, the first security key is communicated securely according to the SQL command details, to a target database (=second user database) also receiving encrypted information loaded from the source database (=first user database)), the at least the second processor is further configured to (Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501):
(Ford: [Col 1, lines 18-25], a method for backing up data synchronized between a set of related devices such that the backup data is only accessible by providing a code associated with one of the devices. Specifically, some embodiments store (i) the set of backup data encrypted with a set of data encryption keys (=one or more encryption keys), [Col 4, lines 18-20], FIG. 4 conceptually illustrates a process of some embodiments for creating a backup for a set of confidential data items shared among multiple associated devices).
Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski and ford does not explicitly teach:
encrypt the updated data content
However, in an analogous art Welingkar teaches:
encrypt the updated data content (Welingkar: [0061] The transmitted data is indicative of changes made to the data file on device 100, and may be in any of a plurality of forms, such as the updated data blocks or records themselves (e.g., only data blocks or records within the data file which have been updated or changed since a previous backup transmission), a compressed form of the updated data blocks or records, encrypted, converted to a database file format, or otherwise processed)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Woo, Antonopoulos, Ahmed and Wisniewski and ford by applying the well-known technique as disclosed by Welingkar of encrypting the updated data block. The motivation is to restore the backed-up data to the same device in the event of data loss or to a new computing device in the case of the user acquiring a replacement or upgraded device (Welingkar: [0002]).
Claim(s) 16, 17, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Chitkara et al (U. S. PGPub. No. 2021/0143989 A1) (hereinafter ("Chitkara") in view of Welingkar et al (U. S. PGPub. No. 2009/0307284 A1) (hereinafter “Welingkar”); further in view of Ahmed (2019/0036678 A1) (hereinafter “Ahmed”).
Regarding Claim 16, Chitkara teaches:
A database server, comprising (Chitkara: a database environment 102 comprises a source server 104, storing encrypted information for access by a customer)
a memory configured to store a master database and a user database (Chitkara: [0201] Rather, alternative embodiments could leverage the processing power of an in-memory database engine (e.g., the in-memory database engine of the HANA in-memory database available from SAP SE), in order to perform various functions)
and at least one processor coupled to the memory and configured to (Chitkara: [0203] An example computer system 500 is illustrated in FIG. 5. Computer system 510 includes a bus 505 or other communication mechanism for communicating information, and a processor 501 coupled with bus 505 for processing information. Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501)
decrypt the data content using the at least one decrypted DEK of the one or more encryption keys (Chitkara: [0058] Once transferred, the security key can be referenced to decrypt encrypted information (=encrypted backup file) at the target database, upon receiving a query from a user).
and one or more encryption keys of (Chitkara: [0069], To access the encrypted data at the target server, the hierarchy of encryption keys must be accessible at the target server. [0070] Thus, when a data encryption key is encrypted with master key, master key needs to be accessible at the target server. Where the master key is encrypted with a key from external keystore at the source server, and the external keystore is not accessible at the target server, a mechanism is required to securely transfer the data encryption key and/or master key from the source server to the target server and see Fig 9 below).
PNG
media_image4.png
885
836
media_image4.png
Greyscale
wherein the set of encryption keys is encrypted by the at least one KEK, wherein the set of encryption keys includes one or more column encryption keys (Chitkara: [0035] Encryption keys of various types 132 may be members of different key hierarchies. Examples of such encryption key types can include but are not limited to: [0036] external key(s) [0037] master key(s) [0038] database encryption key(s) [0039] column encryption key(s) (=one or more column encryption keys) [0040] service key(s) [0041] dual master key(s) [0042] recovery key(s) [0043] log encryption key(s) [0044] proprietary logic encryption key(s) [0045] backup encryption key(s) [0046] application data encryption key(s); and [0047] others),
and wherein the at least one encrypted DEK and the at least one encrypted KEK were decrypted by a master key of the prior version of the database server or the second database server and re-encrypted by the public key (Woo: [0146], In an embodiment, in operation 990, the at least one processor 222 may decrypt the encrypted KEK using a secret key (=master key). [0077], a secret key capable of encrypting or decrypting a DEK. In a case of using an asymmetric key according to various embodiments of the disclosure, a public key may be used for encryption, and a secret key may be used for decryption);
The Chitkara does not disclose:
receive a database backup file, wherein the database backup file includes data content
generate an updated data content of the user database based on the at least one further encrypted KEK and the decrypted data content; and store the updated data content in the user database.
However, in an analogous art, Welingkar teaches:
receive a database backup file, wherein the database backup file includes data content (Welingkar: [0068], If the data file has previously been backed up from this device, at step 416, the previously backed-up database file is retrieved from memory. [0080] Module 515, under control of a processor or data processor 517, is configured to receive the backup data from module 513 and identify any full data files corresponding to received data indicative of updates):
generate an updated data content of the user database based on the at least one further encrypted KEK (Welingkar: [0059], Device 100 may then be configured to receive and store changes or updates to the data file (step 302), such as data additions, data deletions, data edits, etc., made to data blocks, records or other portions of the data file. Device 100 is configured to change or update the data file to create a changed or updated data file. [0061] The transmitted data is indicative of changes made to the data file on device 100, and may be in any of a plurality of forms, such as the updated data blocks or records themselves (e.g., only data blocks or records within the data file which have been updated or changed since a previous backup transmission), a compressed form of the updated data blocks or records, encrypted, converted to a database file format, or otherwise processed. The update data transmission may comprise an incremental, data file, a differential data file, a delta data file, etc. to indicate changes made to the data file on device 100. The preceding steps may be repeated serially or in parallel for different data files to be backed up (e.g. one or more databases of user data, data files for other applications, etc.) and the decrypted data content (Welingkar: [0065], decrypt the data if it has been encrypted, and/or provide other processing steps on the data, as shown in greater detail in FIG. 4A below. [0068], If the data file has previously been backed up from this device, at step 416, the previously backed-up database file is retrieved from memory and decrypted);
and store the updated data content in the user database (Welingkar: [0059], Device 100 may further be configured to store an indication that a change or update has occurred to the data file).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Chitkara’s method of generating encrypted back up of the “source database” in to the target server as a “target database” by applying Welingkar’ s method of decrypting updated encrypted back up data and store it back into the database. The motivation is to restore the backed-up data to the same device in the event of data loss or to a new computing device in the case of the user acquiring a replacement or upgraded device (Welingkar: [0002]).
Chirkara in view of Welingkar does not disclose:
retrieve a plurality of private keys from the memory;
determine that a private key of the plurality of private keys matches the public key;
However, in analogous art, Ahmed teaches:
retrieve a plurality of private keys from the memory (Ahmed: [0202], obtain unique private keys);
determine that a private key of the plurality of private keys matches the public key (Ahmed: [0544], in RSA, each public key is matched with just one unique private key. More specifically, in the RSA algorithm, the public key is (e, n) and private key is (d, n). The key pair is always unique for each user. It means that for each public key there always exist a unique private key and for every private key there exist a unique public key);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Welingkar by applying the well-known technique as disclosed by Ahmed of obtaining unique private key and determining that unique private kay matched with public key in order to enabling secure, authenticated communication and ensuring confidentiality, authenticity, and integrity for data exchange like HTTPS, secure email, and blockchain. The motivation is to process encrypted data efficiently without requiring excessive amounts of computing power or memory relative to the processing of the underlying encrypted data (Ahmed: [0010]).
Regarding Claim 17, Chitkara in view of Welingkar and Ahmed teaches:
The database server of claim 16 (see rejection of claim 16 below),
wherein the at least one processor is further configured to (Chitkara: [0203], Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501):
Chitkara in view of Welingkar and Ahmed does not explicitly teaches:
wherein the one or more encryption keys are encrypted by the public key,
wherein the database backup file includes the public key or a file path of the public key,
However, Ford teaches:
wherein the one or more encryption keys are encrypted by a public key (Ford: [Col 1, lines 64-67], In order for a device to access the keybag in order to use the backup to restore the confidential data items, several copies of the master recovery key are encrypted with the public keys of the different devices that share some or all of the confidential data items),
wherein the database backup file includes the public key or a file path of the public key (Ford: [Col 6, lines 27-36], the encrypted backup data 135 may include various pieces of confidential data, including various usernames and passwords, account numbers, cryptographic keys and/or seeds from which such keys can be generated, and even files (photos, documents, etc.) that the user wishes to securely back up. Some embodiments encrypt each data item (e.g., each password, each username/password combination, each cryptographic key, etc.) with the public key of a separate item key pair (also referred to as a data encryption key pair),
This claim contains identical limitations found within that of claim 7 above albeit directed to a different statutory category (computer-readable medium). For this reason, the same grounds of rejection are applied to claim 17.
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Chitkara in view of Welingkar and Ahmed by applying the well-known technique as disclosed by Ford of decrypting master recovery key (encryption keys) using private key in order to any of the devices can decrypt one of the copies of the master recovery key using its own private key, and thereby access the keybag and confidential data items (Ford: [Col 2, lines 6-8]).
Regarding Claim 18, Chitkara in view of Welingkar and Ahmed teaches:
The database server of claim 16 (see rejection of claim 16 cited above),
However, Chitkara teaches:
wherein the at least one processor is configured to (Chitkara: [0203], Computer system 510 also includes a memory 502 coupled to bus 505 for storing information and instructions to be executed by processor 501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 501):
determine the master key of the master database (Chitkara: [0074] In the ASE database environment, importing master key in a particular database will create the master key at the target server encrypted with the key from external keystore. [0075] Also, importing data encryption keys in a particular ASE database will create the data encryption keys at the target server encrypted with the master key of the corresponding database);
encrypt the at least one DEK of the one or more encryption keys using the master key of the master database (Chitkara: [0066] Specifically, a master key encrypts data encryption keys, which in turn are used to encrypt data);
and store the encrypted at least one DEK of the one or more encryption keys in the master database (Chitkara: [0122], The DEK present in the master database is encrypted with master key. [0136] At the target ASE database, per the following pseudocode the DEK will be transferred using the file (1a in FIG. 7) and encrypted with the master key of the master database on the target ASE (1b in FIG. 7) as part of TRANSFER ENCRYPTION KEY statement)).
Regarding Claim 19, this claim contains identical limitations found within that of claim 9 above albeit directed to a different statutory category (computer-readable medium). For this reason, the same grounds of rejection are applied to claim 19.
Regarding Claim 20, this claim contains identical limitations found within that of claim 10 above albeit directed to a different statutory category (computer-readable medium). For this reason, the same grounds of rejection are applied to claim 20.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
ITAMAR et al. (U. S. PGPub. No. 2018/0123790 A1): A granular encryption database management system characterized by hierarchical internal key management using asymmetric encryption of the user's keys, which are stored within a (local) encryption key table. Data is encrypted, decrypted, stored, and accessed from rows within the database (hereinafter ‘instances’). Instances are ordered in categories called Types. Instances are encrypted with Instance keys. All instances of the same type have their Instance keys generated by means of a hash function of their common Type's key, while Type keys are generated from the key of the higher category which is often the Master key of the
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437