DETAILED ACTION
This action is in response to the claims filed 1/13/2025. Claims 1-20 are pending. Independent claims 1 and 18, and corresponding dependent claims are directed towards a method and non-transitory computer-readable medium for automatically encrypting sensitive data in a distributed microservice framework.
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.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 9 of U.S. Patent No. 12,231,412. Although the claims at issue are not identical, they are not patentably distinct from each other because of subject matter indicated below:
Application 19/018068
US Patent No. 12,231,412 B2
Claim 1
Claims 1 + Claim 9
Claim Objections
Claim 9 is objected to because of the following informalities, shown with suggested amendments: Claim 9 l. 3 “those interfaces” should be “the one or more non-privileged interfaces” for proper antecedent basis. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 19-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claims 19 l. 1 and Claim 20 l. 1 recite the limitation “The non-transitory computer-readable medium of claim 17” which lacks proper antecedent basis as claim 17 is a “method” claim and has no recitation of a “non-transitory computer-readable medium”. For purposes of applying prior art the limitation has been construed as “The non-transitory computer-readable medium of claim 1[[7]]8”.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-7, 9-13 and 15-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by White et al. (US 2020/0394317 A1), published Dec. 17, 2020.
As to claim 1, White discloses a method of protecting sensitive data in a system (White [Abstract] method), the method comprising steps of: receiving, by one or more processors, a data model comprising one or more data fields (White [0059] backend architecture configured to interact with any data model provided by a managed database; [0005] server and client field-level authenticated encryption operations); identifying, within the data model, at least one field designated as sensitive data (White [0109] JSON Schema metadata can configure in server what fields are encrypted); automatically creating an encrypted form of the sensitive data (White [0082] automatic encryption configuration specifying individual data field); and incorporating the encrypted form of the sensitive data into the data model in place of the unencrypted data (White [0007] store data field encrypted in document).
As to claim 2, White discloses the invention as claimed as described in claim 1, including wherein the automatically creating the encrypted form of the sensitive data is at a framework level without requiring an application-level encryption process (White [0004] native automatic transparently encrypted queries with no application query code changes).
As to claim 3, White discloses the invention as claimed as described in claim 1, including wherein the steps further include storing or transmitting the data model containing the encrypted form of the sensitive data within the system (White [0007] store data field encrypted in document).
As to claim 4, White discloses the invention as claimed as described in claim 1, including wherein the steps further include tagging the at least one field in the data model with an encryption indicator (White [0109] JSON Schema metadata can configure in server what fields are encrypted) prior to the step of automatically creating the encrypted form (White [0082] automatic encryption configuration specifying individual data field).
As to claim 5, White discloses the invention as claimed as described in claim 1, including wherein the steps further include allowing a privileged user to selectively convert between the encrypted form of the sensitive data and an unencrypted form in response to an authorized request (White [0049] users given permissions to access encryption keys to decrypt data at field-level).
As to claim 6, White discloses the invention as claimed as described in claim 1, including wherein the steps further include applying additional cryptographic or masking operations to the data fields designated as sensitive data based on a privilege level of a requesting user (White [0049] users given permissions to access encryption keys to decrypt data at field-level – decryption is an additional cryptographic operation after the initial encryption).
As to claim 7, White discloses the invention as claimed as described in claim 1, including wherein the step of identifying the at least one field includes parsing the data model to detect one or more fields subject to specific security criteria based on at least one rule set configured to recognize sensitive patterns (White [0162] parsing query; [0167] get JSON Schema to ask what values in BSON commands must be encrypted; [0204] mark plaintext BSON values with intent-to-encrypt marking Type 0 to process to cyphertext Type 1 + 2).
As to claim 9, White discloses the invention as claimed as described in claim 1, including wherein the steps further include detecting one or more non-privileged interfaces within the system (White Fig. 5c item 511 “Request includes data key for data field?” - No branch), and limiting access to unencrypted sensitive data via those interfaces while the encrypted form remains accessible within the data model (White Fig. 5c item 521 “Restrict access to plaintext data” and items 522&531 providing access to encrypted copies instead).
As to claim 10, White discloses the invention as claimed as described in claim 1, including wherein the steps further include exchanging the data model containing the encrypted form of the sensitive data among multiple subsystems or services in the system wherein each subsystem or service does not require direct handling of the unencrypted sensitive data (White [0049] “the database architecture passes only encrypted data to system resources (e.g., cloud hosted machines, processors, storage, etc.) outside of the client machine(s)”).
As to claim 11, White discloses the invention as claimed as described in claim 1, including wherein the steps further include selecting an encryption algorithm from a predefined set of algorithms, wherein the predefined set includes at least one of: a symmetric key algorithm (White [0100] AES encryption), an asymmetric key algorithm, and an elliptic curve cryptography (ECC) algorithm.
As to claim 12, White discloses the invention as claimed as described in claim 1, including wherein the steps further include implementing a pluggable cryptographic module configured to intercept operations involving the data model (White [0102] pluggable Searchable Symmetric Encryption (SSE) – teaches use of pluggable modules; [0140] libmongocrypt – library for encryption/decryption; [0174] driver integrates with libmongocrypt library for encryption/decryption; ), wherein the pluggable cryptographic module automatically encrypts or decrypts sensitive data fields on behalf of the computing environment without requiring direct modification by an application (White [0177], [0187]-[0193] driver using libmongocrypt to perform auto-encryption of intercepted commands transparently).
As to claim 13, White discloses the invention as claimed as described in claim 1, including wherein the data model includes an extensible schema (White [0148] JSON Schema including metadata about encrypted fields), and wherein the steps further include inserting encryption metadata into the schema to indicate whether a field is to be encrypted, hashed, or left in plain text based on at least one security policy rule (White [0109] JSON Schema specifies which fields are to be encrypted).
As to claim 15, White discloses the invention as claimed as described in claim 1, including wherein the step of storing or transmitting the data model further includes generating log entries that include only the encrypted form of the sensitive data, thereby preventing the unencrypted sensitive data from appearing in logs that might be viewed by non-privileged users (White [0197] unencrypted data does not appear in the data of any command monitoring events (i.e. logs)).
As to claim 16, White discloses the invention as claimed as described in claim 1, including wherein the steps further include applying a cryptographic signature or message authentication code (MAC) to the encrypted form of the sensitive data (White [0235] calculation of MAC of encrypted data, and appending to get C; [0101] AEAD stands for “Authenticated Encryption with Associated Data” requires generation of a MAC), and verifying the cryptographic signature or MAC when decrypting the data to ensure integrity and detect potential tampering (White [0187]-[0192] auto-decryption; [0101] AEAD requires verification of MAC prior to decryption).
As to claim 17, White discloses the invention as claimed as described in claim 1, including wherein the data model is defined using a standardized modeling language selected from the group consisting of YANG, JSON Schema (White [0148] JSON Schema), XML Schema, and Protocol Buffers, and wherein the steps further include embedding extension statements in the standardized modeling language to designate which portions of the model must be encrypted at a framework level (White [0204] showing “encrypt” statement embedding).
As to claim 18, White discloses non-transitory computer-readable medium for protecting sensitive data in a system (White [0017] medium with instructions for performing data security method), the non-transitory computer-readable medium comprising instructions that (White [0017] medium with instructions), when executed, cause one or more processors to perform steps of: receiving, by one or more processors, a data model comprising one or more data fields (White [0059] backend architecture configured to interact with any data model provided by a managed database; [0005] server and client field-level authenticated encryption operations); identifying, within the data model, at least one field designated as sensitive data (White [0109] JSON Schema metadata can configure in server what fields are encrypted); automatically creating an encrypted form of the sensitive data (White [0082] automatic encryption configuration specifying individual data field) at a framework level without requiring an application-level encryption process (White [0004] native automatic transparently encrypted queries with no application query code changes); and incorporating the encrypted form of the sensitive data into the data model in place of the unencrypted data (White [0007] store data field encrypted in document).
As to claim 19, White discloses the invention as claimed as described in claim 17, including wherein the steps further include storing or transmitting the data model containing the encrypted form of the sensitive data within the system (White [0007] store data field encrypted in document)..
As to claim 20, White discloses the invention as claimed as described in claim 17, including wherein the steps further include tagging the at least one field in the data model with an encryption indicator (White [0109] JSON Schema metadata can configure in server what fields are encrypted) prior to the step of automatically creating the encrypted form (White [0082] automatic encryption configuration specifying individual data field).
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 of this title, 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 8 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over White et al. (US 2020/0394317 A1), published Dec. 17, 2020, in view of Huey et al. “Oracle Database Advanced Security Guide 12c Release 1 (12.1)”, published June 2017.
As to claim 8, White discloses the invention as claimed as described in claim 1, including wherein the steps failing, however, to explicitly disclose automatically deleting or removing any unencrypted form of the sensitive data from transient memory or logs once the encrypted form has been incorporated into the data model. Huey describes Oracle Advance Security: Transparent Data Encryption and Oracle Data Redaction. With this in mind, Huey discloses automatically deleting or removing any unencrypted form of the sensitive data from transient memory or logs once the encrypted form has been incorporated into the data model (Huey §5.2.2 encrypted column data stays encrypted in the data files, undo logs, redo logs, and the buffer cache of the system global area (SGA) (i.e. transient memory or logs); §5.2.3 securely removing old plaintext fragments from database to prevent privileged operating system user bypassing and gaining access). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the transparent data encryption of Huey with the field-level encryption of White, such that any plaintext is prevented from being exposed, as it would advantageously prevent leaking of sensitive data (Huey §5.2.3).
As to claim 14, White discloses the invention as claimed as described in claim 1, including wherein the steps further include one or more database schemas in which fields designated as sensitive data store only the encrypted version (White [0109] JSON Schema metadata can configure in server what fields are encrypted). White fails to explicitly disclose updating, in response to the incorporation of the encrypted form of the sensitive data, one or more database schemas so that fields designated as sensitive data store only the encrypted version, and removing any previously stored unencrypted data from the database tables. Huey discloses updating one or more database schemas so that fields designated as sensitive data store only the encrypted version (Huey §3.3.5.1 ALTER TABLE – SQL statement enables encryption of columns in an existing table), and removing any previously stored unencrypted data from the database tables (Huey §5.2.3 securely removing old plaintext fragments from database to prevent privileged operating system user bypassing and gaining access). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the transparent data encryption of Huey with the field-level encryption of White, such that any plaintext is prevented from being exposed, as it would advantageously prevent leaking of sensitive data (Huey §5.2.3).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC W SHEPPERD whose telephone number is (571)270-5654. The examiner can normally be reached Monday - Thursday, Alt. Friday, 7:30AM - 5:00PM, EST.
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, Rupal Dharia can be reached at (571)272-3880. 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.
/Eric W Shepperd/Primary Examiner, Art Unit 2492
Prosecution Insights