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 .
Claims 1-25 have been examined.
Response to Arguments
Applicant's arguments filed on 2/2/26 have been fully considered but they are not persuasive.
Regarding applicant’s remarks, applicant mainly argues that the prior art of record does not disclose “identifying API traffic that contains user data identified as sensitive user data…by parsing the API request or the API response to detect a metadata associated with the API request or API response, and wherein the metadata is parsed to determine whether the API request or the API response includes sensitive user data.” Applicant asserts that Srivanivan’s disclosure of parsing a query to identify the data fields that is used to access the data catalog in order to determine whether the data field includes sensitive data fields is different from the claimed metadata associated with the API request or API response. The examiner disagrees for the following reasons.
The examiner relies on Srinivasan for disclosure of parsing query transmitted through API to identify metadata associated with the query (i.e. field names, parameters, and the conditions) in order to detect or identify sensitive information (Srinivasan: Abstract; [0042]: parse the query to identify the data fields in the query, which are then analyzed for sensitive information). The data fields or information identified by parsing the query corresponds to metadata obtained by parsing the API request/response, which is used to determine whether it contains sensitive information. The data catalog of Srinivasan is not relied upon by the examiner as information that is parsed from the request or response. Furthermore, the claims are recited at a high level of generality (i.e. API traffic, API request/response, metadata, etc.). Without sufficient clarification or context associated with the steps, parsing or extracting data from network traffic communicated through API between two devices for analysis of sensitive data, as taught or suggested by the combination of prior art, reasonably corresponds to the process as currently claimed.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 8-12, 15-19, and 22-25 are rejected under 35 U.S.C. 103 as being unpatentable over Nguyen et al. U.S. Pub. No. 2024/0126916 (hereinafter Nguyen) in view of Srinivasan et al. U.S. 2024/0411922 (hereinafter Srinivasan).
As per claim 1, 8 and 15, Nguyen discloses a method/medium/system for tracing sensitive data flow, comprising:
one or more servers, wherein each server includes a memory and a processor (Nguyen: Fig. 1); and
one or more modules stored in the memory and executed by at least one of the one or more processors to
intercept API traffic between a client and a plurality of application services, the API traffic including API requests and API responses associated with at least one user (Nguyen: Figs. 1 and 2: intelligent machine learning agent and detect/encrypt framework at API gateway; [0106]: interception and inspection can be performed by either agent installed at client device, or by detection and encryption framework at API gateway or various Kubernetes clusters/application services) ,
identify API traffic that contains user data identified as sensitive user data at one of the plurality of application services (Nguyen: Figs. 1 and 2; [0100] and [0106]: detect sensitive data by machine learning intelligent agent, or by detection and encryption framework),
apply a blocking rule, at the one of the plurality of application services, to the API traffic that contains user data identified as sensitive user data (Nguyen: [0105]: detect sensitive data and prevent transmission of sensitive data),
modify a response, based on the blocking rule, to redact the identified sensitive user data from being included within the response to the identified API traffic (Nguyen: Fig. 3; [0106]-[0107]: redaction of data can be performed by machine learning intelligent engine of Fig. 1 or by detection and encryption framework of Fig. 2), and
transmitting the modified response (Nguyen: [0107]: transmitting response after sensitive data is protected).
Nguyen discloses implementing machine learning intelligent engine at various nodes in a network, including Kubernetes clusters (Nguyen: Fig. 2). Nguyen does not explicitly disclose implementation of the steps, including removing sensitive data, at microservices level. However, Srinivasan discloses parsing the API request or the API response to detect a metadata associated with the API request or the API response, and wherein the metadata is parsed to determine whether the API request or the API response includes sensitive user data. Specifically, Srinivasan discloses detecting and tracking sensitive data access by parsing query (i.e. request or response) to detect metadata and identify whether sensitive data is contained in the metadata, wherein the detection and classification is performed at microservice level (Srinivasan: [0041]-[0042]: detect sensitive data by parsing query to identify data field names, the parameters, and the conditions used in the query, i.e. metadata; [0047]-[0048]: detect sensitive data at microservice level for systems such as Kubernetes). It would have been obvious to one having ordinary skill in the art to implement the sensitive data identification and sanitation process at microservices level through deployment within Kubernetes framework of Nguyen because Nguyen and Srinivasan are analogous art involving redacting/removing sensitive data through Kubernetes/microservices platform. The motivation to combine would be that it is well known in the art to distribute and enforce network policies at various point of network traffic.
As per claim 2, 9 and 16, Nguyen as modified discloses the limitations of claims 1, 8 and 15 respectively. Nguyen as modified further discloses wherein intercepting API traffic is performed by a tracing agent installed at each of the plurality of microservices (Nguyen: Fig. 2: application clusters include the detection and encryption framework to enforce the policies; [0097]: API gateway can invoke one or more agents of the network 130 to obtain traffic events associated with the network).
As per claim 3, 10 and 17, Nguyen as modified discloses the limitations of claims 2, 9 and 16 respectively. Nguyen further discloses wherein the blocking rules are provided to each of the plurality of tracing agents by a remote application (Nguyen: Figs. 1 and 2; [0109]: centralized repository maintains security compliance requirements and updates to be enforced by local agents in Figs 1 and 2).
As per claim 4, 11 and 18, Nguyen as modified discloses the limitations of claims 2, 9 and 16 respectively. Nguyen further discloses wherein the blocking rules are applied by the tracing agent at the one of the plurality of microservices (Nguyen: Fig. 2 and [0100]-[0103]: Kubernetes clusters each host detection and encryption framework to enforce the policies distributed by Kubernetes master node).
As per claim 5, 12 and 19, Nguyen as modified discloses the limitations of claims 1, 8 and 15 respectively. Nguyen further discloses wherein user data is identified as sensitive user data based on a predefined data type or by an administrator rule (Nguyen: [0103]-[0106]).
As per claim 22, Nguyen as modified discloses the method of claim 1. Nguyen as modified further discloses performing heuristics on the API request or the API response to detect if the API request or the API response contains sensitive user data based on heuristic data associated with other API requests or API responses (Srinivasan: [0041]-[0042]). Same rationale applies here as above in rejecting claim 1.
As per claim 23, Nguyen as modified discloses the method of claim 1. Nguyen as modified further discloses detecting whether the API request or the API response is directed to an untrusted destination; in response to determining that the destination is untrusted applying the blocking rule to the API request or the API response; and modifying the API request or the API response to remove the identified sensitive user data from being included within the API request or the API response (Srinivasan: [0041]: sensitive-data removing component). It would have been obvious to one having ordinary skill in the art to remove and modify the requests/responses that contain sensitive data because they are analogous art involving redacting/removing sensitive data through Kubernetes/microservices platform. The motivation to combine would be to prevent exposure of sensitive data.
As per claim 24, Nguyen as modified discloses the method of claim 1. Nguyen as modified further discloses wherein the API traffic is intercepted at a microservice of the plurality of microservices, and wherein the microservice of the plurality of microservices modifies the response (Nguyen: Figs. 1 and 2: intelligent machine learning agent and detect/encrypt framework at API gateway; [0106]: interception and inspection can be performed by either agent installed at client device, or by detection and encryption framework at API gateway or various Kubernetes clusters/application services; Srinivasan: [0055]). Same rationale applies here as above in rejecting claim 1.
As per claim 25, Nguyen as modified discloses the method of claim 1. Nguyen as modified further discloses deploying a tracing agent to each microservice of the plurality of microservices for real-time sensitive data tracing and filtering (Nguyen: Figs. 1 and 2: intelligent machine learning agent and detect/encrypt framework at API gateway; [0106]: interception and inspection can be performed by either agent installed at client device, or by detection and encryption framework at API gateway or various Kubernetes clusters/application services).
Claims 6, 7, 13, 14, 20 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Nguyen in view of Srinivasan and further in view of Subbarayan et al. U.S. Pub. No. 20180115578 (hereinafter Subbarayan).
As per claim 6, 13 and 20, Nguyen as modified discloses the limitations of claims 1, 8 and 15 respectively. Nguyen discloses training machine learning models to detect sensitive data in application traffic (Nguyen: [0087]-[0088]). Nguyen as modified does not explicitly disclose the one or more modules further executable to generate a user model based on the intercepted API traffic, the user model including user geographic information, user typical API requests, and user API baseline activity, and determine non-compliance of user sensitive data flow based on the user model and data compliance rules. However, Subbaryan discloses training machine learning model to identify non-compliance of sensitive data flow based on API traffic analysis, wherein the analysis identifies deviation from normal traffic parameter baselines including geolocation, type of requests and activities (Subbarayan: [0004]: machine learning model to detect threat based on API traffic; and [0062]: traffic parameter baselines). It would have been obvious to one having ordinary skill in the art to monitor and analyze API traffic to generate machine learning model for detecting non-compliance of API traffic because Nguyen and Subbarayan are analogous art involving monitoring API/application security. The motivation to combine would be to further identify potential threat.
As per claim 7, 14 and 21, Nguyen as modified discloses the limitations of claims 1, 8 and 15 respectively. Nguyen discloses training machine learning models to detect sensitive data in application traffic (Nguyen: [0087]-[0088]). Nguyen as modified does not explicitly disclose the one or more modules further executable to generate a user model based on the intercepted API traffic, the user model including user geographic information, user typical API requests, and user API baseline activity, and determine that a current user session is a breach of a user account based on the user model and intercepted API request and API response data. However, Subbaryan discloses training machine learning model to identify non-compliance of sensitive data flow based on API traffic analysis, wherein the analysis identifies deviation from normal traffic parameter baselines including geolocation, type of requests and activities (Subbarayan: [0004]: machine learning model to detect threat based on API traffic; and [0062]: traffic parameter baselines). It would have been obvious to one having ordinary skill in the art to monitor and analyze API traffic to generate machine learning model for detecting non-compliance of API traffic because Nguyen and Subbarayan are analogous art involving monitoring API/application security. The motivation to combine would be to further identify potential threat.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rosenthal et al. U.S. 2017/0091680 discloses discovery of sensitive data location in data sources using business/enterprise application data flows, wherein API request is parsed to identify relevant data source items that contains sensitive information ([0046]).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIN HON (ERIC) CHEN whose telephone number is (571)272-3789. The examiner can normally be reached Monday to Thursday 9am- 7pm.
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, Lynn Feild can be reached at 571-272-2092. 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.
/SHIN-HON (ERIC) CHEN/ Primary Examiner, Art Unit 2431