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 .
This is a non-final office action in response to applicant’s communication filed on 8/29/2024.
Claims 1-21 are pending and being considered.
Priority
This application is a continuation in part (CIP) of 18/199,321, filed on 5/18/2023.
Drawings
The drawings are objected to because:
Fig. 1 missing numerical references 100 (data plane), 104 (sidecar proxy), according to para. [0043].
Fig. 5, inconsistency between the Drawing and Specification. For instance, para. [0051] states: “WASM 110 or native module 210”, whereas the Drawing shows “SENTRY”; “a metrics module 118” whereas the Drawing shows “Prometheus Open Telemetry”; etc.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
Para. [0051] references sidecar as “111”, and [0060] references bootstrapping layer as “111”.
Para. [0061] uses term “YAML”. Applicant is suggested to define what YAML stands for.
Appropriate correction is required.
Claim Objections
Claims 1, 3, 6, 10-11, 13-14, 16, 19 are objected to because of the following informalities:
Claims to have consistent indentation. For instance, claim 3 may read,
3. The method according to claim 2, further comprising:
mapping service interactions between the first microservice and the second microservice; and
annotating the service interactions with tracing that is indicative of sensitive data.
Similarly, for claim 14.
Claim 1 line 7, “evaluating service mesh data …” may read “evaluating the service mesh data …”. Last line, “detected patterns in the service mesh data” may read “detected the patterns in the service mesh data”.
Claim 11 line 2, “… does not include sensitive information” may read “… does not include the sensitive information”.
Claim 12 lines 3-4, “… installed on a sidecar of the compatible node” may read “… installed on a sidecar of the each compatible node”.
Similarly, for claim 18 line 2, “the compatible node” may read “the each compatible node”.
Claim 15 line 2, “… when received from …” may read “… when the security policy is received from …”.
Appropriate correction is suggested.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7-11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 7 lines 1-2 recites “sensitive information the service mesh data …”. It is not clear the sensitive information is, of the service mesh data, or in the service mesh data, or from the service mesh data, rendering the claim indefinite. Applicant is suggested to clarify the claim language.
Claims 8-11 depend on claim 7, therefore are also rejected for the same reason set forth above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 12-21 are rejected under 35 USC § 101 because the claimed invention is directed to non-statutory subject matter. The claims are not statutory as they are drawn as a whole to a software per se.
Claim 12 recites a system comprising a “native module”, “command module”, and “data lake scanner”. The claim does not fall within at least one of the four categories of patent eligible subject matter because the claim is directed to a software per se. The “native module”, “command module”, and “data lake scanner” in light applicant’s specification, can be understood being software modules. To overcome the rejection above, applicant is suggested to include at least one hardware component in the claim.
Claims 13-21 depend on claim 12, therefore are also rejected with the same reason set forth above.
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.
Claims 1, 12 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over the corresponding claims of US Application No. 18/199,321 (hereinafter “’321”), in view of Ranjan et al (US20210334384A1).
Claim 1 (or claim 11) of ‘321 discloses all of the limitations recited in claim 1 (similarly claim 12) of the instant application, as seen in the table below except limitation(s) as highlighted in bold, in the same field of endeavor Ranjan teaches:
native module (Ranjan, discloses system and method for detecting security leak by microservice, see [Abstract]. And [0055] The various managers, engines, and creators described above with reference to FIGS. 1A-C and the processing described below with reference to the flow diagrams of FIG. 2-5 may be implemented in the form of executable instructions (i.e., native module)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Ranjan in the data plane management of ‘321 by testing a microservice to determine whether the microservice leaks sensitive information. This would have been obvious because the person having ordinary skill in the art would have been motivated to use security leak detection engine as native module instead of WASM for testing microservice to determine whether the microservice leaks sensitive information with applied security rules (Ranjan, [Abstract]).
Claim Comparison
Instant Application 18/819,954
Co-pending 18,199,321
1. A method for data plane management, the method comprising:
deploying, in a service mesh, a native module comprising natively compiled code, the native module being embedded in a service routing layer of the service mesh;
assigning a security policy to the native module from a bootstrapping layer of the service mesh, the security policy enabling the native module to detect patterns in service mesh data that are indicative of sensitive information;
evaluating service mesh data by the native module with the security policy;
and transmitting telemetry to a cloud-based command module when the native module has detected patterns in the service mesh data.
1. A method for data plane management, the method comprising:
deploying, in a service mesh, a WebAssembly (WASM) that is embedded in a service routing layer of the service mesh;
assigning a security policy to the WASM from a bootstrapping layer of the service mesh, the security policy enabling the WASM to detect patterns in service mesh data that are indicative of sensitive information;
receiving, from the WASM, telemetry comprising an indication that the service mesh data possesses the patterns indicative of the sensitive information;
evaluating service mesh data by the WASM with the security policy;
and transmitting telemetry to a cloud-based command module when the WASM has detected patterns in the service mesh data.
12. A system, comprising:
a native module comprising natively compiled code, the native module deployed in each compatible node of a service mesh, the native module being installed on a sidecar of the compatible node and being configured to apply a security policy that is used to search raw data for patterns that are indicative of sensitive data;
a command module that:
assigns the security policy to the native module;
receives telemetry data from the native module, the telemetry data comprising an indication that the raw data possesses patterns that are indicative of sensitive data;
and verify that the raw data includes the sensitive data;
and a data lake scanner that is configured to evaluate stored data of the service mesh for sensitive information.
11. A system, comprising:
a WebAssembly (WASM) deployed in each WASM compatible node of a service mesh, the WASM being installed on a sidecar of the each WASM compatible node and being configured to apply a security policy that is used to search raw data for patterns that are indicative of sensitive data;
a memory comprising instructions stored thereon; a processor configured to be capable of executing the stored instructions to:
assign, using a command module, that: assigns the security policy to the WASM;
receive, using the command module, receives telemetry data from the WASM, the telemetry data comprising an indication that the raw data possesses patterns that are indicative of sensitive data;
and verify, using the command module, that the raw data includes the sensitive data;
and a data lake scanner that is configured to evaluate stored data of the service mesh for sensitive information.
Examiner Notes
Examiner cites particular paragraphs, columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ranjan et al (US20210334384A1-IDS, hereinafter, “Ranjan”).
Regarding claim 1, Ranjan teaches:
A method (Ranjan, discloses system and method for detecting security leak by microservice, see [Abstract]) for data plane management, the method comprising:
deploying, in a service mesh, a native module comprising natively compiled code, the native module being embedded in a service routing layer of the service mesh (Refer to Fig. 1, and [0051] … the security leak detection system also includes a production system 150 including a security leak detection engine 151, …, a security leak alert manager 157… And [0052] the security leak detection engine 151 is deployed in the form of a microservice within protection system 150 to periodically run a security detection process to cause the security leak testing engine 155 to monitor one or more microservices making up a production application (e.g., application 170) (i.e., embedded in a service routing layer of the service mesh). And [0055] The various managers, engines, and creators described above with reference to FIGS. 1A-C and the processing described below with reference to the flow diagrams of FIG. 2-5 may be implemented in the form of executable instructions (i.e., native module comprising natively compiled code));
assigning a security policy to the native module from a bootstrapping layer of the service mesh, the security policy enabling the native module to detect patterns in service mesh data that are indicative of sensitive information (Refer to Fig. 1A, and [0022] For example, the system may analyze various pre-defined data sets produced by microservices to scan them for pre-defined security leak patterns. And [0037] FIG. 1A is a block diagram conceptually illustrating various components that may be used to set up a security leak detection system (i.e., bootstrapping layer of the service mesh) … a security administrator 101 may interact with a service registry manager 110, a security dataset manager 112 and a security rules manager 114 to persist information to a service and relationships database 111, a dataset to be observed 113, and a security rules database 115. And [0040] The security rules manager 114 may be responsible for defining a set of security rules to which the dataset produced by the microservices are to be subjected (i.e., assigning a security policy));
evaluating service mesh data by the native module with the security policy (Fig. 2, 4 and 5 show microservice testing processing);
and transmitting telemetry to a cloud-based command module when the native module has detected patterns in the service mesh data (Fig. 4, at 480, and [0085] At block 480, violations of the security rules are reported. For example, if any string patterns and/or regular expressions corresponding to the rules listed above in block 470 are found in the generated datasets, appropriate personnel may be alerted (e.g., via email, text message or otherwise). And Fig. 4 at 524, and [0091] At block 524, violations of the security rules are reported. For example, if any string patterns and/or regular expressions corresponding to the security rules are found in the generated datasets, appropriate personnel may be alerted).
Regarding claim 2, Ranjan teaches the method according to claim 1,
Ranjan further teaches: further comprising monitoring the service mesh data between a first microservice and a second microservice (e.g., [0022] Embodiments described herein relate to an adaptable security leak detection system that may itself be deployed in the form of a microservice along with microservices to be observed/tested for potential leakage of sensitive information. For example, the system may analyze various pre-defined data sets produced by microservices to scan them for pre-defined security leak patterns. And [0039] The security dataset manager 112 may be responsible for defining sets of data 113 produced by microservices to be observed for leak detection. A dataset may be common across a majority of services, in which case, the files, logs, failed call stack traces and the like, may be predefined).
Regarding claim 3, Ranjan teaches the method according to claim 2,
Ranjan further teaches: further comprising: mapping service interactions between the first microservice and the second microservice; and annotating the service interactions with tracing that is indicative of sensitive data (e.g., [0022] Embodiments described herein relate to an adaptable security leak detection system that may itself be deployed in the form of a microservice along with microservices to be observed/tested for potential leakage of sensitive information. For example, the system may analyze various pre-defined data sets produced by microservices to scan them for pre-defined security leak patterns. Predefined data sets can be service logs, call stack traces, API responses during positive as well as negative use cases).
Regarding claim 4, Ranjan teaches the method according to claim 1,
Ranjan further teaches: wherein deploying comprises distributing the native module to a virtual machine or container of each microservice or sidecar in the service mesh ([0052] According to one embodiment, the security leak detection engine 151 is deployed in the form of a microservice within protection system 150 to periodically run a security detection process to cause the security leak testing engine 155 to monitor one or more microservices. And [0055] The various managers, engines, and creators described above with reference to FIGS. 1A-C… For example, processing may be performed by one or more virtual or physical computer systems of various forms).
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Ranjan as applied above to claim 1, in view of Sun et al (US20240354379A1, hereinafter, “Sun”).
Regarding claim 5, Ranjan teaches the method according to claim 1,
While Ranjan does not teach the following, in the same field of endeavor Sun teaches:
wherein the native module is an input guardrail for an artificial intelligence application (Sun, discloses method of guarding an automated software by training a guardrail machine learning model, see [Abstract]. And [0032] and a trained guardrail model 214 … The generative artificial intelligence 212 (e.g., large language model) operationally generates training data sets for the trained guardrail model 214, and the trained guardrail model 214 operationally verifies that output from the automated software 210 complies with rules).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Sun in the detecting a potential security leak of Ranjan by using guardrail machine learning model for guarding automated software. This would have been obvious because the person having ordinary skill in the art would have been motivated to use the guardrail model to determine whether the generated output from automated software violates rule and preventing from transmitting output that violates the rule (Sun, [Abstract]).
Regarding claim 6, Ranjan teaches the method according to claim 1,
While Ranjan does not teach the following, in the same field of endeavor Sun teaches:
wherein the native module is an output guardrail for an artificial intelligence application (Sun, discloses method of guarding an automated software by training a guardrail machine learning model, see [Abstract]. And [0032] and a trained guardrail model 214 … The generative artificial intelligence 212 (e.g., large language model) operationally generates training data sets for the trained guardrail model 214, and the trained guardrail model 214 operationally verifies that output from the automated software 210 complies with rules).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Sun in the detecting a potential security leak of Ranjan by using guardrail machine learning model for guarding automated software. This would have been obvious because the person having ordinary skill in the art would have been motivated to use the guardrail model to determine whether the generated output from automated software violates rule and preventing from transmitting output that violates the rule (Sun, [Abstract]).
Claims 7, 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Ranjan as applied above to claim 1, in view of Yannuzzi et al (US20240012921A1, hereinafter, “Yannuzzi”).
Regarding claim 7, Ranjan teaches the method according to claim 1,
While Ranjan does not teach the following, in the same field of endeavor Yannuzzi teaches:
further comprising verifying an existence of sensitive information the service mesh data by the cloud-based command module (Yannuzzi, discloses method of dynamic resolution and enforcement of data compliance of endpoint, see [Title]/[Abstract]. And [0185] In various embodiments, the application may be reconfigured to prevent the endpoint from accessing the sensitive data based on a new location (e.g., a location that violates and/or is likely to violate a data compliance policy) of the endpoint. In such examples, reconfiguring may include pushing a filter to a sidecar proxy of the application. The application may be executed in a distributed data mesh across multi-cloud and edge environments).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Yannuzzi in the detecting a potential security leak of Ranjan by reconfiguring sidecar proxy with filter. This would have been obvious because the person having ordinary skill in the art would have been motivated to identify sensitive data within the application service to which the data compliance policy applies (Yannuzzi, [Abstract]).
Regarding claim 9, Ranjan-Yannuzzi combination teaches the method according to claim 7,
Ranjan further teaches: further comprising generating, by the cloud-based command module, a dashboard that includes information pertaining to the service mesh data that comprises the sensitive information ([0039] The security dataset manager 112 may be responsible for defining sets of data 113 produced by microservices to be observed for leak detection. A dataset may be common across a majority of services, in which case, the files, logs, failed call stack traces and the like, may be predefined. Some specific services may have additional datasets. For example, the security administrator 101 may wish to perform security leak detection on data being displayed to the end user for a user interface (UI) based microservice).
Regarding claim 10, Ranjan-Yannuzzi combination teaches the method according to claim 7,
Yannuzzi further teaches: further comprising redacting the sensitive information from the service mesh data ([0044] a data team and/or application manager 304 may be provided with a mechanism to change the associations created by application developers 312 or even associate more than one category of sensitive data to a given data type (e.g., a data team and/or application manager 304 may associate certain data with both “Employee PII” and “Confidential Data”)... In general, a data team and/or application manager 304 may be able to Create, Read, Update, or Delete (CRUD) any association between the metadata provided by application developers 312 and categories of sensitive data). Same motivation as presented in claim 7 would apply.
Claims 12, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ranjan et al (US20210334384A1, hereinafter, “Ranjan”), in view of Yannuzzi et al (US20240012921A1, hereinafter, “Yannuzzi”).
Regarding claim 12, Ranjan teaches:
A system (Ranjan, discloses system and method for detecting security leak by microservice, see [Abstract]), comprising:
a native module comprising natively compiled code, the native module deployed in each compatible node of a service mesh, the native module being installed on [a sidecar of the compatible node] and being configured to apply a security policy that is used to search raw data for patterns that are indicative of sensitive data (Refer to Fig. 1, and [0051] … the security leak detection system also includes a production system 150 including a security leak detection engine 151, …, a security leak alert manager 157… And [0052] the security leak detection engine 151 is deployed in the form of a microservice within protection system 150 to periodically run a security detection process to cause the security leak testing engine 155 to monitor one or more microservices making up a production application (e.g., application 170). And [0055] The various managers, engines, and creators described above with reference to FIGS. 1A-C and the processing described below with reference to the flow diagrams of FIG. 2-5 may be implemented in the form of executable instructions (i.e., native module comprising natively compiled code)); (see Yannuzzi below for teaching of limitation in bracket)
a command module that: assigns the security policy to the native module (See Fig. 1A, B, C, Security Administrator 101, or DevOps Administrator 121. And [0022] For example, the system may analyze various pre-defined data sets produced by microservices to scan them for pre-defined security leak patterns. And [0037] FIG. 1A is a block diagram conceptually illustrating various components that may be used to set up a security leak detection system … a security administrator 101 may interact with a service registry manager 110, a security dataset manager 112 and a security rules manager 114 to persist information to a service and relationships database 111, a dataset to be observed 113, and a security rules database 115);
receives telemetry data from the native module, the telemetry data comprising an indication that the raw data possesses patterns that are indicative of sensitive data; and verify that the raw data includes the sensitive data (Fig. 4, at 480, and [0085] At block 480, violations of the security rules are reported. For example, if any string patterns and/or regular expressions corresponding to the rules listed above in block 470 are found in the generated datasets, appropriate personnel may be alerted (e.g., via email, text message or otherwise). And Fig. 4 at 524, and [0091] At block 524, violations of the security rules are reported. For example, if any string patterns and/or regular expressions corresponding to the security rules are found in the generated datasets, appropriate personnel may be alerted);
and a data lake scanner that is configured to evaluate stored data of the service mesh for sensitive information (e.g., Fig. 1C Security Leak Testing Engine. And Fig. 2, 4 and 5 show microservice testing processing).
While Ranjan teaches the main concept of the claimed invention but does not teach the following, in the same field of endeavor Yannuzzi teaches:
a sidecar of the compatible node (Yannuzzi, discloses method of dynamic resolution and enforcement of data compliance of endpoint, see [Title]/[Abstract]. And [0185] In various embodiments, the application may be reconfigured to prevent the endpoint from accessing the sensitive data based on a new location (e.g., a location that violates and/or is likely to violate a data compliance policy) of the endpoint. In such examples, reconfiguring may include pushing a filter to a sidecar proxy of the application. The application may be executed in a distributed data mesh across multi-cloud and edge environments).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Yannuzzi in the detecting a potential security leak of Ranjan by reconfiguring sidecar proxy with filter. This would have been obvious because the person having ordinary skill in the art would have been motivated to identify sensitive data within the application service to which the data compliance policy applies (Yannuzzi, [Abstract]).
Regarding claim 19, Ranjan-Yannuzzi combination teaches the system according to claim 12,
Ranjan further teaches: wherein the command module is configured to generate a dashboard that includes information pertaining to the service mesh data that comprises the sensitive information Ranjan further teaches: further comprising generating, by the cloud-based command module, a dashboard that includes information pertaining to the service mesh data that comprises the sensitive information ([0039] The security dataset manager 112 may be responsible for defining sets of data 113 produced by microservices to be observed for leak detection. A dataset may be common across a majority of services, in which case, the files, logs, failed call stack traces and the like, may be predefined. Some specific services may have additional datasets. For example, the security administrator 101 may wish to perform security leak detection on data being displayed to the end user for a user interface (UI) based microservice).
Regarding claim 20, Ranjan-Yannuzzi combination teaches the system according to claim 12,
Yannuzzi further teaches: wherein the command module is configured to redact the sensitive information from the service mesh data ([0044] a data team and/or application manager 304 may be provided with a mechanism to change the associations created by application developers 312 or even associate more than one category of sensitive data to a given data type (e.g., a data team and/or application manager 304 may associate certain data with both “Employee PII” and “Confidential Data”)... In general, a data team and/or application manager 304 may be able to Create, Read, Update, or Delete (CRUD) any association between the metadata provided by application developers 312 and categories of sensitive data). Same motivation as presented in claim 12 would apply.
Claims 11, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Ranjan-Yannuzzi as applied above to claim 10, 12 respectively, further in view of Dixit et al (US20240232419A1, hereinafter, “Dixit”).
Regarding claim 11, Ranjan-Yannuzzi combination teaches the method according to claim 10,
While the combination of Ranjan-Yannuzzi does not teach the following, in the same field of endeavor Dixit teaches:
further comprising replacing the sensitive information with a string of characters that does not include sensitive information (Dixit, discloses method of sensitive data classification for micro-service applications, see [Title]/[Abstract]. And [0050] For privacy reasons or concerns, in some implementations the sensitive data classifier 54 may not provide the actual data items 65 to the collector service 33. And [0067] The sensitive data classifier 88 operates as described above with regard to the sensitive data classifier 54. The sensitive data classifier 88 analyzes the information received from the agent 85 to determine if the information contains sensitive data… As an example, if a response includes an actual social security number (SSN), the sensitive data classifier 88 may remove the SSN from the information and replace it with an SSN_ID indicating that an SSN was in the information).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Dixit in the detecting a potential security leak of Ranjan-Yannuzzi by replacing sensitive such as SSN with SSN_ID. This would have been obvious because the person having ordinary skill in the art would have been motivated to classify sensitive data and replace sensitive data for privacy or concern (Dixit, [Abstract], [0050]).
Regarding claim 21, Ranjan-Yannuzzi combination teaches the system according to claim 12,
While the combination of Ranjan-Yannuzzi does not teach the following, in the same field of endeavor Dixit teaches:
wherein the command module is configured to replace the sensitive information with a string of characters that does not include sensitive information (Dixit, discloses method of sensitive data classification for micro-service applications, see [Title]/[Abstract]. And [0050] For privacy reasons or concerns, in some implementations the sensitive data classifier 54 may not provide the actual data items 65 to the collector service 33. And [0067] The sensitive data classifier 88 operates as described above with regard to the sensitive data classifier 54. The sensitive data classifier 88 analyzes the information received from the agent 85 to determine if the information contains sensitive data… As an example, if a response includes an actual social security number (SSN), the sensitive data classifier 88 may remove the SSN from the information and replace it with an SSN_ID indicating that an SSN was in the information).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Dixit in the detecting a potential security leak of Ranjan-Yannuzzi by replacing sensitive such as SSN with SSN_ID. This would have been obvious because the person having ordinary skill in the art would have been motivated to classify sensitive data and replace sensitive data for privacy or concern (Dixit, [Abstract], [0050]).
Claims 13, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ranjan-Yannuzzi as applied above to claim 12, further in view of Fong et al (US20230403301A1, hereinafter, “Fong”).
Regarding claim 13, Ranjan-Yannuzzi combination teaches the system according to claim 12,
The combination of Ranjan-Yannuzzi does not specifically teaches the following, in the same field of endeavor Fong teaches:
wherein the security policy is disseminated by a random native module of the service mesh (Fong, discloses infrastructural edge security as a service, see [Title] and [Abstract] Security policies can be selectively distributed to the hosts and localized at the hosts. And [0019] allow administrators to set, delete, change, monitor, and revoke security policies from a centralized location for distributed infrastructure. The control plane 102 allows an administrator to centrally manage and distribute security policies to any number of hosts).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Fong in the detecting a potential security leak of Ranjan-Yannuzzi by selectively distributing security policies to distributed infrastructure of data processing hosts . This would have been obvious because the person having ordinary skill in the art would have been motivated to provide security services at an infrastructure level and to edge security as a service (Fong, [Abstract], [0001]).
Regarding claim 15, Ranjan-Yannuzzi combination teaches the system according to claim 12,
The combination of Ranjan-Yannuzzi does not specifically teaches the following, in the same field of endeavor Fong teaches:
wherein a random native module is configured to distribute the security policy when received from the command module (Fong, discloses infrastructural edge security as a service, see [Title] and [Abstract] Security policies can be selectively distributed to the hosts and localized at the hosts. And [0019] allow administrators to set, delete, change, monitor, and revoke security policies from a centralized location for distributed infrastructure. The control plane 102 allows an administrator to centrally manage and distribute security policies to any number of hosts).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Fong in the detecting a potential security leak of Ranjan-Yannuzzi by selectively distributing security policies to distributed infrastructure of data processing hosts . This would have been obvious because the person having ordinary skill in the art would have been motivated to provide security services at an infrastructure level and to edge security as a service (Fong, [Abstract], [0001]).
Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Ranjan-Yannuzzi as applied above to claim 12, further in view of Sun et al (US20240354379A1, hereinafter, “Sun”).
Regarding claim 16, Ranjan-Yannuzzi combination teaches the system according to claim 12,
While the combination of Ranjan-Yannuzzi does not teach the following, in the same field of endeavor Sun teaches:
wherein the native module is an input guardrail for an artificial intelligence application (Sun, discloses method of guarding an automated software by training a guardrail machine learning model, see [Abstract]. And [0032] and a trained guardrail model 214 … The generative artificial intelligence 212 (e.g., large language model) operationally generates training data sets for the trained guardrail model 214, and the trained guardrail model 214 operationally verifies that output from the automated software 210 complies with rules).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Sun in the detecting a potential security leak of Ranjan-Yannuzzi by using guardrail machine learning model for guarding automated software. This would have been obvious because the person having ordinary skill in the art would have been motivated to use the guardrail model to determine whether the generated output from automated software violates rule and preventing from transmitting output that violates the rule (Sun, [Abstract]).
Regarding claim 17, Ranjan-Yannuzzi combination teaches the system according to claim 12,
While the combination of Ranjan-Yannuzzi does not teach the following, in the same field of endeavor Sun teaches:
wherein the native module is an output guardrail for an artificial intelligence application (Sun, discloses method of guarding an automated software by training a guardrail machine learning model, see [Abstract]. And [0032] and a trained guardrail model 214 … The generative artificial intelligence 212 (e.g., large language model) operationally generates training data sets for the trained guardrail model 214, and the trained guardrail model 214 operationally verifies that output from the automated software 210 complies with rules).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Sun in the detecting a potential security leak of Ranjan-Yannuzzi by using guardrail machine learning model for guarding automated software. This would have been obvious because the person having ordinary skill in the art would have been motivated to use the guardrail model to determine whether the generated output from automated software violates rule and preventing from transmitting output that violates the rule (Sun, [Abstract]).
Claims 8, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ranjan-Yannuzzi as applied above to claim 7, 12 respectively, further in view of Tembey et al (US20240348657A1, hereinafter, “Tembey”).
Regarding claim 8, Ranjan-Yannuzzi combination teaches the method according to claim 7,
While the combination of Ranjan-Yannuzzi does not teach the following, in the same field of endeavor Tembey teaches:
further comprising rate limiting a set of traffic moving through a sidecar, based on the verifying (Tembey, discloses system and method to enforce and update security policies for cloud-native application stacks deployed across multiple providers using a distributed control plane architecture, see [Abstract]. And [0071] For other controls, such as when rate limits need to be added to specific microservices to safeguard against denial-of-service attacks, both the data plane sidecar 224 and the local control plane 112 may be updated with additional customized network filters that can rate-limit the requests in the data plane while relying on state maintained in the local control plane for request rate accounting and limiting. In this case, the update manifest includes details about other container images that should be downloaded within the local control plane 112 to enable rate-limiting functionality and specific data plane configurations so that the rate limits can be enforced at runtime).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Tembey in the detecting a potential security leak of Ranjan-Yannuzzi by rate-limiting the requests in the data plane. This would have been obvious because the person having ordinary skill in the art would have been motivated to enforce and update security policies for cloud-native application stacks (Tembey, [Abstract]).
Regarding claim 18, Ranjan-Yannuzzi combination teaches the system according to claim 12,
While the combination of Ranjan-Yannuzzi does not teach the following, in the same field of endeavor Tembey teaches:
wherein the command module is configured to case a native module to rate limit the compatible node based on the verifying (Tembey, discloses system and method to enforce and update security policies for cloud-native application stacks deployed across multiple providers using a distributed control plane architecture, see [Abstract]. And [0071] For other controls, such as when rate limits need to be added to specific microservices to safeguard against denial-of-service attacks, both the data plane sidecar 224 and the local control plane 112 may be updated with additional customized network filters that can rate-limit the requests in the data plane while relying on state maintained in the local control plane for request rate accounting and limiting. In this case, the update manifest includes details about other container images that should be downloaded within the local control plane 112 to enable rate-limiting functionality and specific data plane configurations so that the rate limits can be enforced at runtime).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Tembey in the detecting a potential security leak of Ranjan-Yannuzzi by rate-limiting the requests in the data plane. This would have been obvious because the person having ordinary skill in the art would have been motivated to enforce and update security policies for cloud-native application stacks (Tembey, [Abstract]).
Allowable Subject Matter
Claim 14 is objected to as being dependent upon a rejected base claim(s), but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims as well as resolving of any outstanding informalities and 35 USC 101 presented in this office action.
The following is a statement of reasons for the indication of allowable subject matter:
Claim 14 depends on claim 12, further specifies, “wherein the command module is configured to: map service interactions between two or more compatible nodes of the service mesh; annotate the service interactions with tracing that is indicative of sensitive data; and provide the annotated service interactions on a dashboard”.
The prior arts identified, Ranjan, Yannuzzi, Fong, Sun, Dixit, Tembey, either singularly or in combination fails to anticipate or render obvious the claimed limitations of claim 14, shown above.
Citation of References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following references are cited but not been replied upon for this office action:
Yang et al (US20210383014A1) discloses method for deep learning-based detection and data loss prevention of image-borne sensitive documents.
Golway et al (US20240364720A1) discloses method for detecting microservice security
attacks based on metric sensitive dependencies.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL M LEE whose telephone number is (571)272-1975. The examiner can normally be reached on M-F: 8:30AM - 5:30PM.
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, Shewaye Gelagay can be reached on (571) 272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL M LEE/Primary Examiner, Art Unit 2436