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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/15/2025 has been entered.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 05/31/2023 and 03/13/2024 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Arguments
Applicant’s arguments, see page 10, filed 2/12/2026, with respect to the rejection of claims 1-3, 6-10, 13-17, and 20-26 under 35 USC 112(a) have been fully considered.
Regarding claims 1, 8, and 15:
The provided arguments are persuasive, and these rejections are withdrawn.
Regarding claims 7, 14, and 20:
These rejections were not addressed in arguments or by amendments to the claims. These rejections are maintained.
Applicant’s arguments, see page 10, filed 2/12/2026, with respect to the rejection of claims 1-3, 6-10, 13-17, and 20-26 under 35 USC 112(b) have been fully considered and are persuasive. This rejection has been withdrawn.
Applicant’s arguments, see pages 10-11, filed 2/12/2026, with respect to the rejection of claims 1-3, 6-10, 13-17, and 20-26 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of BEVERIDGE et al (Doc ID US 20230412629 A1), VENKATRAMANI et al (Doc ID US 20170163666 A1), and CASCAVAL et al (Doc ID US 20180124018 A1).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 7, 14, and 20 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
Regarding claims 7, 14, and 20:
Claim 7 recites, “… generating a new attack vector based on the marked span …”. Claims 14 and 20 recite similar language. This limitation is not adequately described in the specification, and is in fact contradicted by the specification. Paragraph 27 of the specification recites, “… when applicable, notify the need for creating new attack vectors in the local database 208.” Paragraphs 42 and 44 are similar. The specification is explicit that the invention may notify of the need for creating new attack vectors, it does not describe any method, either explicitly or implicitly, by which the invention can generate the new attack vectors itself. This rejection can be overcome by amending the claims such that the limitation is supported by adequate written description (i.e. “… generating a notification indicating the need for a new attack vector based on the marked span …”).
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.
Claim(s) 1-3, 6-10, 13-17, and 20-26 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.
Regarding claims 1, 8, and 15:
The amendments to the claims have rendered the claims convoluted to the point that they are indefinite. A summary of the limitations is given here with examiner comments to capture the issues preventing a clear interpretation of the claims. Limitation summaries are listed at the (#) lines, and examiner comments are given on ‘a-z.’ lines.
The “System” (SY) analyzes communication between “microservices” (MS), and identifies “spans” (s), which each represent an “invocation path.”
This indicates that spans and invocation paths are functionally the same, as neither spans nor invocation paths are given any further definition in the claims to differentiate them from each other.
SY stores s1 … sn as “contexts” (c) in a “context catalog” (CC).
This indicates that spans are also functionally equivalent to contexts. So spans = invocation paths = contexts.
SY receives “telemetry” (t), “corresponding to” an “invoked service call” (i), from a MS.
Note that it is not clear whether an “invoked service call” is meant to be equivalent to an “invocation path.”
It is also unclear whether the receiving is meant to take place as part of the earlier analysis, or whether this is a separate step of receiving a singular piece of data.
SY determines whether CC contains a c which “corresponds to” i.
Because ambiguity of the previous limitation, it is not clear whether this step is describing simply matching a received path to a path in a saved list (context catalog), or some other action.
Designating the s “associated with” i as marked when i is not found in CC.
The claims have earlier established that spans are the same as contexts, and contexts are the same as invocation paths. The claims have not established a way in which a “span” is associated with an “invoked service call.”
Conduct a “root cause analysis” to identify the marked s as an attack.
It is unclear of what effect this analysis determines the root cause. “Root cause analysis” typically refers to a process which looks backward from a specific event to determine its originating event; however, given that the originating microservice of each invocation is already known, it begs the question of what purpose or intent the root cause analysis serves.
Additional limitations do not add to or detract from the clarity of the claim, and will not be included here.
It is only the examiner’s assumption based on previous claim drafts and context from the specification that overall method steps of the claims are intended to be the same as previous drafts, and prior art will be applied, where possible, with this context in mind. However, this rejection can be overcome only by amendments to the claims which positively link the various recited terminology and steps in such a way that the metes and bounds of the claim are made clear.
Regarding claims 2, 3, 6, 7, 9, 10, 13, 14, 16, 17, and 20-26:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
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.
Claims 1-3, 6-10, 13-17, and 20-26 are rejected under 35 U.S.C. 103 as being unpatentable over VASUDEVA et al (Doc ID US 20210334374 A1), and further in view of BEVERIDGE et al (Doc ID US 20230412629 A1), VENKATRAMANI et al (Doc ID US 20170163666 A1), and CASCAVAL et al (Doc ID US 20180124018 A1) .
Regarding claim 1:
VASUDEVA teaches:
A system, comprising: one or more processors; and one or more computer-readable non-transitory storage media comprising instructions that, when executed by the one or more processors, cause one or more components of the system to perform operations comprising ([0112] "… any operation ... may be implemented by a computing system using corresponding instructions stored on or in a non-transitory computer-readable medium accessible by a processing system."):
conducting a root cause analysis to determine that the marked span should be classified as an attack by a span inspector module ([0098] "The process 700 then determines whether a malware attack is underway based on a pattern analysis ..."),
in response to determining that the marked span should be classified as an attack, determining that the marked span engaged with data corresponding to one or more application services defining the marked span ([0075] "When the protection agent 300 has made a corroborated detection of a malware attack ..., the protection agent 300 uses the suspicious file log 310, the file event log 318, or both to identify the one or more files that are potentially impacted.");
designating the data corresponding to the one or more application services as compromised ([0075] "… protection agent 300 may also identify ... files that are potentially impacted. More particularly, the protection agent 300 may ... provide a recovery option for each individual file ... impacted by the malware attack ..."); and
BEVERIDGE teaches the following limitation(s) not taught by VASUDEVA:
analyzing communication pathways between a plurality of microservices to identify a plurality of spans, wherein each of the plurality of spans represents an invocation path (Fig. 2 and [0027] "... anomaly detection system 200 includes a plurality of collection agents 202(1)-(N) coupled with respective microservices 102(1)-(N) ..." and [0030] "… FIG. 2, … each collection agent 202 can collect traces of API calls made by its corresponding microservice 102 … and can send the API call traces to analytics platform 204.");
storing the plurality of spans as a plurality of contexts, respectively, in a context catalog (Fig. 2 and [0031] "At steps (2) and (3) ..., individual API call pre-processor 208 ... can receive the API call traces transmitted by collection agents 202(1)-(N) and can pre-process the traces so that they are appropriate for ingestion ...");
receiving, from a microservice, telemetry information corresponding to an invoked service call, wherein the invoked service call requests access to application data (Fig. 6 and [0056] "At steps (1) and (2) … individual API call feature extractor 602 can receive an API call trace pre-processed by individual API call pre-processor 208 …");
Deciding whether suspicious data constitutes an attack, determining what other data was in contact with the suspicious data, and identifying that data as compromised as well are known techniques in the art, as demonstrated by VASUDEVA. Further, receiving and storing service requests among microservices is a known technique in the art, as demonstrated by BEVERIDGE. It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to modify the attack data tracing of VASUDEVA with the microservice request monitoring of BEVERIDGE with the motivation to narrow the scope of the system to monitoring microservice requests. It would be obvious for one looking to identify anomalous service requests to arrive at this method.
VENKATRAMANI teaches the following limitations not taught by the combination of VASUDEVA and BEVERIDGE:
determining that a context corresponding to the invoked service call is not stored in the context catalog ([0144] "… Context information is received (524) and combined (526) with the activity data to form an activity record …" and [0145] "The incoming activity record(s) are compared (528) against the set of baseline signatures.");
designating, in response to determining that the context corresponding to the invoked service call is not stored in the context catalog, a span associated with the invoked service call as a marked span ([0145] "… Larger deviations from matching the baseline signatures can indicate an anomalous condition.");
Identifying a service request as anomalous when it does not match the signature for previously processed requests is a known technique in the art, as demonstrated by VENKATRAMANI. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the microservice request attack identification of VASUDEVA and BEVERIDGE with the service request anomaly identification of VENKATRAMANI with the motivation to limit anomaly scanning to only those requests which are previously unseen, as previously processed requests are assumed to be benign. It would be obvious for one looking to streamline the processing of a large quantity of calls to focus on only new calls whose status is unknown.
CASCAVAL teaches the following limitations not taught by the combination of VASUDEVA, BEVERIDGE, and VENKATRAMANI:
in response to determining that the marked span should be classified as an attack, denying the microservice access to the application data ([0031] "… If an attack or a non-benign behavior is detected by a downstream micro-security application, the micro-security application may drop the downstream request and notify the upstream micro-security application.");
inhibiting a subsequent invoked service call, wherein a span associated with the subsequent invoked service call is the marked span ([0031] "… In particular, the upstream micro-security application may observe an anomalous request and temporarily block it from reaching its micro-service application.").
Stopping a service call, which has been identified as anomalous, from proceeding to its target, and blocking the request altogether if the request is identified as an attack, are known techniques in the art, as demonstrated by CASCAVAL. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the microservice request attack identification of VASUDEVA, BEVERIDGE, and VENKATRAMANI with the anomaly and attack remediation of CASCAVAL with the motivation to prevent suspicious or hostile service requests from being processed by their target. It would be obvious, to one looking to go beyond mere identification to actually stopping the request, to arrive at this method.
Regarding claim 2:
The combination of VASUDEVA, BEVERIDGE, VENKATRAMANI, and CASCAVAL teaches:
The system of claim 1, the operations further comprising: designating another span associated with the invoked service call as another marked span (VENKATRAMANI [0145] "… Larger deviations from matching the baseline signatures can indicate an anomalous condition.");
Flagging data associated with telemetry suspicious or anomalous is a known technique in the art, as demonstrated by VENKATRAMANI. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the anomalous telemetry tracing and blocking of VASUDEVA, BEVERIDGE, VENKATRAMANI, and CASCAVAL with the suspicious telemetry flagging of VENKATRAMANI with the motivation to flag all telemetry which may be suspicious, even if it is ultimately found to be benign.
conducting the root cause analysis to determine that the other marked span should not be classified as the attack (VASUDEVA Fig. 7 and [0098] "… If a malware attack is not confirmed as being underway, the process 700 returns to operation 702 described above."); and
removing metadata corresponding to a flag for the other marked span (VASUDEVA Fig. 7 and [0098] "… If a malware attack is not confirmed as being underway, the process 700 returns to operation 702 described above.").
Examiner notes that the method of the prior art simply proceeds to the next potentially suspicious file once it is determined that the file is not in indication of an attack. This is equivalent in function to removing a flag.
Regarding claim 3:
The combination of VASUDEVA, BEVERIDGE, VENKATRAMANI, and CASCAVAL teaches:
The system of claim 1, the operations further comprising: notifying an associated data controller in response to a determination that the marked span did engage with said data (VASUDEVA [0075] "… the protection agent 300 uses the suspicious file log 310, the file event log 318, or both to identify the one or more files that are potentially impacted.").
Regarding claim 6:
The combination of VASUDEVA, BEVERIDGE, VENKATRAMANI, and CASCAVAL teaches:
The system of claim 1, the operations further comprising accessing a local database storing one or more known attack vectors (VASUDEVA [0073] "… the pattern analyzer 319 may include a plurality of templates, each corresponding to a profile of a malware attack.").
Regarding claim 7:
The combination of VASUDEVA, BEVERIDGE, VENKATRAMANI, and CASCAVAL teaches:
The system of claim 6, the operations further comprising: comparing the marked span to the one or more known attack vectors for overlapping points of attack (VASUDEVA [0073] "… The file analyzer 319 may look for activity that matches one or more templates of this plurality of templates."); and
generating a new attack vector based on the marked span for storage in the local database (VASUDEVA [0073] "… a new template may be uploaded for use by the pattern analyzer 319 when a new type of malware attack … is identified or when new malware characteristics are identified.").
Regarding claims 8-10, 13-17, and 20:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 1-3, 6, and 7 above.
Regarding claim 21:
The combination of VASUDEVA, BEVERIDGE, VENKATRAMANI, and CASCAVAL teaches:
The system of claim 1, the operations further comprising: accessing the context catalog comprising the contexts that are associated with the received telemetry information, wherein the context catalog further comprises key-value pairs (KVPs) and additional metadata that is used to describe the contexts (BEVERIDGE [0062] "... steps 702 and 704, individual API call feature extractor 602 can receive an API call trace and can parse the trace into a plurality of blocks corresponding to different types of API call metadata ..." and [0064] "... individual API call feature extractor 602 can use key-value extraction to extract one or more key-value based features from the block.").
Storing request information as a series of key-value-pairs is a known technique in the art, as demonstrated by BEVERIDGE. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the anomalous telemetry tracing and blocking of VASUDEVA, BEVERIDGE, VENKATRAMANI, and CASCAVAL with the key-value-pairs of BEVERIDGE with the motivation to simplify the matching process of identifying known and unknown service requests. It would be obvious to one looking to make an easily searchable array of request data to use this method.
Regarding claims 22 and 23:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claim 21 above.
Regarding claim 24:
The combination of VASUDEVA, BEVERIDGE, VENKATRAMANI, and CASCAVAL teaches:
The system of claim 1, the operations further comprising: receiving the marked span that has been flagged for inspection (VASUDEVA [0098] "The process 700 then determines whether a malware attack is underway based on a pattern analysis ...").
Regarding claims 25 and 26:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claim 24 above.
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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON BINCZAK whose telephone number is (703)756-4528. The examiner can normally be reached M-F 0800-1700.
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 on (571) 270-5143. 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.
/BB/Examiner, Art Unit 2437
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437