DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 09/17/2025. Claims 1-39 cancelled. Claims 40, 46, 49, 55, and 58 are amended. Claims 40-58 are pending in this examination.
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. This examination is in response to US Patent Application No. 17/913,906.
Examiner Note
Applicant’s amendment to claims 40, 46, 49, and 58, obviates previously raised claims 40-58, 35 USC 112(b), second paragraph, rejection.
Applicant’s amendment to claims 40, 49, and 58, obviates previously raised claims 40-58, 35 USC 112(a), first paragraph, rejection.
Response to Arguments
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant's arguments filed 09/17/2025 have been fully considered but they are not persuasive:
Applicant submits on pages 2-3 of remarks filed on 09/17/2025 that the combination of Fenoglio in view of Garipally does not disclose or suggest the newly presented features of "wherein the first entity initiates transmission of the one or more updated capture filters towards the one or more second entities for use by the one or more second entities to capture the traffic between the microservices" of amended independent Claims 40, 49, and 58.
Examiner respectfully disagrees with applicant argument for claims 40, 49, and 58 filed on 09/17/2025 on pages 2-3 of remarks.
While Fenoglio discloses this limitation as: [ Abstract, presented herein are techniques for detecting anomalies in micro-service communications that are indicative of security issues/problems for the application. More specifically, a computing device receives a plurality of micro-service communication records each associated with traffic sent between pairs of executables (nodes) that are related to a micro-services application. Each of the micro-service communication records includes a time series entry and an associated trace sequence identifier and each of the micro-service communication records are generated during a time period. The computing device analyzes the plurality of micro-service communications to detect possible anomalous communication patterns associated with the micro-services application during the time period], and [Col 3 lines 8-16, In certain examples presented herein, a computing device ( equated to first entity) receives a plurality of micro-service communication records ( equated to traffic) and analyzes these communication records to detect possible anomalous communication patterns associated with the micro-services application. Each micro-service communication record includes a time series entry S={S.sub.1, . . . , S.sub.N} of length N and an associated trace sequence identifier of the captured network traffic (i.e., flow characteristics of data exchanged between pairs of executables)], and [Col. 4 lines 39-50, More specifically, shown in FIG. 1 is a computing device 142 that includes a micro-service monitoring module 144( equated to first entity) . As described further below, the computing device 142 is configured to receive records 160 of the communications/traffic associated with (i.e., sent from and/or to) the micro-services 134(1)-134(3) (collecting captured traffic). Using these micro-service communication records 160, the micro-service monitoring module 144 is configured to detect deviations( equated to change in data) from typical communication patterns associated with the application 150 (i.e., detect anomalies in the communication patterns) that are indicative of security issues/problems affecting the application], and [ see FIG. 1 and corresponding text for more details, [ Col. 4 lines 15-24, The micro-services 134(1)-134(3) within containers 135(1)-135(3) collectively form an application 150. That is, the application 150 is formed by a plurality of container-based micro-services that are distributed across the servers 130(1), 130(2), and 130(3) (equated to second entities) (i.e., across the compute cluster 132). Since the application 150 is formed by a plurality of micro-services 134(1)-134(3), the application 150 is sometimes referred to herein as a “micro-service application.” Application program interfaces (APIs) are used for the communications (i.e., sending of packets) between the micro-services 134(1)-134(3)], and [ see FIG. 1 and corresponding text for more details], and (Col 5 lines 56-67- Col. 7 lines 1-53, lines in the example of FIG. 2, the micro-service communication records 160 are generated by the various micro-services 134(1)-134(3), and the micro-service communication records 160 include fields gathered doing container introspection. Each packet sent or received by a micro-service is associated with a binary executable (process) that is uniquely identified by a unique cryptographic signature, such as a Secure Hash Algorithm 1 (SHA-1), but any other secure algorithms can also or alternative be used, within a container…. FIG. 2 illustrates at least one probe 158 at each of the servers 130(1), 130(2), and 130(3) (equated to second entities) configured to perform container introspection and to provide micro-service communication records 160 to the micro-services monitoring module 144(equated to first entity). As noted, each micro-service communication record 160 is associated with communications/traffic (i.e., one or more packets) sent from and/or to a micro-service 134(1), 134(2), or 134(3) in web application 150.
As noted, FIG. 3A illustrates an example format for a micro-service communication record, while FIG. 3B illustrates an example format for a flow volume record. FIGS. 4A, 4B, and 4C illustrate specific examples of completed micro-service communication records 460(A), 460(B), and 460(C), respectively, associated with the arrangement shown in FIG. 2.) Referring first to FIG. 4A, the micro-service communication record 460(A) includes a time stamp 461(A) given as “Time 1,” a source cryptographic signature 462(A) given as “SHA-1 (client 151),” a destination cryptographic signature 463(A) given as “SHA-1 (web server),” a flow volume 464(A) given as “FV.sub.X”, and a flow duration 465(A) given as “FD.sub.X”. As such, the micro-service communication record 460(A) is associated with traffic sent from a binary executable of client device 151 to a binary executable of the web server micro-service 134(1) at a time identified as “Time 1,” which included “FV.sub.X” packets/bytes of data and a flow duration of “FD.sub.X” seconds. In FIG. 2, this traffic is represented by arrow 154(1). Referring next FIG. 4B, the micro-service communication record 460(B) includes a time stamp 461(B) given as “Time 2,” a source cryptographic signature 462(B) given as “SHA-1 (web server),” a destination cryptographic signature 463(B) given as “SHA-1 (business logic),” a flow volume 464(B) given as “FV.sub.Y”, and a flow duration 465(B) given as “FD.sub.Y”. As such, the micro-service communication record 460(B) is associated with traffic sent from a binary executable of the web server micro-service 134(1) to a binary executable of the business logic micro-service 134(2) at a time identified as “Time 2,” which included “FV.sub.Y” packets/bytes of data and a flow duration of “FD.sub.Y” seconds. In FIG. 2, this traffic is represented by arrow 154(2). Referring next FIG. 4C, the micro-service communication record 460(C) includes a time stamp 461(C) given as “Time 3,” a source cryptographic signature 462(C) given as “SHA-1 (business logic),” a destination cryptographic signature 463(C) given as “SHA-1 (database),” a flow volume 464(C) given as “FV.sub.Z”, and a flow duration 465(C) given as “FD.sub.Z”. As such, the micro-service communication record 460(C) is associated with traffic sent from a binary executable of the business logic micro-service 134(2) to a binary executable of the database micro-service 134(3) at a time identified as “Time 3,” which included “FV.sub.Z” packets/bytes of data and a flow duration of “FD.sub.Z” seconds. In FIG. 2, this traffic is represented by arrow 154(3). Returning to FIG. 2, the micro-service communication records 460(A) (FIG. 4A), 460(B) (FIG. 4B), and 460(C) (FIG. 4C) correspond to the traffic 154(1), 154(2), and 154(3) shown in FIG. 2. FIG. 2 also illustrates traffic 156(1), 156(2), and 156(3) which may also result in the generation of similar micro-service communication records. The micro-service communication records are sent (e.g., via probes 158) to the micro-services monitoring module 144. As such, the micro-services monitoring module 144 receives a plurality of micro-service communication records (e.g., records 460(A), 460(B), and 460(C)). The micro-services monitoring module 144 is configured to analyze the time series entries S within the records to determine the behavior of the web application 150 during the associated time period and to analyze the trace sequence identifiers (forming a trace sequence) to determine the pattern of traffic between well identified source and destination nodes]. [see claim 2].
Furthermore, Garipally discloses: [ Col. 2 lines 8-21, (8) The method may include communicating, by the device, the first set of endpoint information to each of one or more packet engines of the device. The packet engines may be configured to manage network traffic to a current set of instances of microservices. The method may include determining, by the one or more packet engines, a change between the first set of endpoint information and a second set of endpoint information configured on the one or more packet engine for each instance of the microservice in the current set of instances of microservices. The method may include updating, by the one or more packet engines based at least on the change, the configuration of the one or more packet engines to manage the desired set of instances of microservices], and [ Col. 2 lines 45-60, Described herein is a system for updating configuration of a device based on changes to microservices. The system may include a device comprising one or more processors, coupled to memory and intermediary to a plurality of clients and microservices. The device may be configured to receive a request via a desired state application programming interface (API) to update a configuration of the device to manage a desired set of instances of microservices. The device may be configured to identify from the request, a first set of endpoint information for each instance of a microservice in the desired set of instances of microservices. The first set of endpoint information may include an internet protocol (IP) address and port of an endpoint of a respective instance of the microservice. The first set or second set of endpoint information may include a weight for each instance of the microservice], and [Col. 18 lines 4-22, From the determine change, the packet engine 420 may identify or determine one or more endpoints in both the new set and the current set of endpoint information. The endpoints that are in both sets may correspond to instances of microservices 425 that are to continue running and receive network traffic after the application of the update to the microservices 425. In updating the configuration, the packet engine 420 may maintain the configuration on the packet engine 420 corresponding to the endpoints for microservices 425 that in both sets. By maintaining, the packet engine 402 may continue to use the same configuration as prior to the application of the update by the API server 435 to the cluster 430 of microservices 425. In this manner, the packet engine 420 may continue routing the network traffic to the microservice 425 corresponding to the endpoint in both the new set and the current set of endpoint information. The maintained configuration may correspond to an endpoint in the desired set of instances of microservices 425 as identified in the received request].
Examiner note: As mentioned in Fenoglio application, the computing device 142(equated to first entity) is configured to receive records 160 of the communications/traffic associated with (i.e., sent from and/or to) the micro-services 134(1)-134(3) (collecting captured traffic). Using these micro-service communication records 160, the micro-service monitoring module 144 is configured to detect deviations (equated to change in data) from typical communication patterns associated with the application 150 (i.e., detect anomalies in the communication patterns) that are indicative of security issues/problems affecting the application, and Garipally discloses the method of updating, by the one or more packet engines based at least on the change It would have been obvious to one of ordinary skill in the art to combine these two references to update the configuration when there is change or deviation detected the communication/traffic.
Examiner maintains the rejection.
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.
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 40-58 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US10484410) issued to Fenoglio (Filed within IDS 09/23/2022), and in view of Garipally (US11057271),
Regarding claims 40, and 49, Fenoglio discloses a method for use in capturing traffic in a network, the method performed by a first entity, the method comprising:
[Abstract, presented herein are techniques for detecting anomalies in micro-service communications that are indicative of security issues/problems for the application. More specifically, a computing device (equated to first entity) receives a plurality of micro-service communication records each associated with traffic sent between pairs of executables (nodes) that are related to a micro-services application. Each of the micro-service communication records includes a time series entry and an associated trace sequence identifier and each of the micro-service communication records are generated during a time period. The computing device analyzes the plurality of micro-service communications to detect possible anomalous communication patterns associated with the micro-services application during the time period], and [Col.2 lines 64-67, Col. 3 lines 1-7, Presented herein are techniques for securing an application that includes micro-services, such as downloaded container-based micro-services. In particular, the techniques presented herein monitor micro-service communications/traffic (i.e., packets/bytes sent to and/or from micro-services within the application) to detect any deviation from a nominal/typical behavior of the application in terms of the communication patterns (i.e., detect an anomaly in the micro-service communications). Deviations from the typical behavior (communication patterns) are indicative of security issues/problems affecting the application]; and
in response to a first request to initiate a session in which to capture traffic between microservices that are distributed across a plurality of nodes in the network,
initiating transmission of a second request towards one or more second entities, wherein: the second request is a request that the one or more second entities initiate the session, the second request comprises one or more capture filters generated for use by the one or more second entities to capture the traffic between the microservices; the first entity is at least one of: a server, a virtual machine, or a controller; the one or more second entities are at least one of: a server, a virtual machine, or a network agent
[ Abstract, presented herein are techniques for detecting anomalies in micro-service communications that are indicative of security issues/problems for the application. More specifically, a computing device receives a plurality of micro-service communication records each associated with traffic sent between pairs of executables (nodes) that are related to a micro-services application. Each of the micro-service communication records includes a time series entry and an associated trace sequence identifier and each of the micro-service communication records are generated during a time period. The computing device analyzes the plurality of micro-service communications to detect possible anomalous communication patterns associated with the micro-services application during the time period], and [Col 3 lines 8-16, In certain examples presented herein, a computing device ( equated to first entity) receives a plurality of micro-service communication records ( equated to traffic) and analyzes these communication records to detect possible anomalous communication patterns associated with the micro-services application. Each micro-service communication record includes a time series entry S={S.sub.1, . . . , S.sub.N} of length N and an associated trace sequence identifier of the captured network traffic (i.e., flow characteristics of data exchanged between pairs of executables)], and [Col. 4 lines 39-50, More specifically, shown in FIG. 1 is a computing device 142 that includes a micro-service monitoring module 144( equated to first entity) . As described further below, the computing device 142 is configured to receive records 160 of the communications/traffic associated with (i.e., sent from and/or to) the micro-services 134(1)-134(3) (collecting captured traffic). Using these micro-service communication records 160, the micro-service monitoring module 144 is configured to detect deviations( equated to change in data) from typical communication patterns associated with the application 150 (i.e., detect anomalies in the communication patterns) that are indicative of security issues/problems affecting the application], and [ see FIG. 1 and corresponding text for more details, [ Col. 4 lines 15-24, The micro-services 134(1)-134(3) within containers 135(1)-135(3) collectively form an application 150. That is, the application 150 is formed by a plurality of container-based micro-services that are distributed across the servers 130(1), 130(2), and 130(3) (equated to second entities) (i.e., across the compute cluster 132). Since the application 150 is formed by a plurality of micro-services 134(1)-134(3), the application 150 is sometimes referred to herein as a “micro-service application.” Application program interfaces (APIs) are used for the communications (i.e., sending of packets) between the micro-services 134(1)-134(3)], and [ see FIG. 1 and corresponding text for more details], and (Col 5 lines 56-67- Col. 7 lines 1-53, lines in the example of FIG. 2, the micro-service communication records 160 are generated by the various micro-services 134(1)-134(3), and the micro-service communication records 160 include fields gathered doing container introspection. Each packet sent or received by a micro-service is associated with a binary executable (process) that is uniquely identified by a unique cryptographic signature, such as a Secure Hash Algorithm 1 (SHA-1), but any other secure algorithms can also or alternative be used, within a container…. FIG. 2 illustrates at least one probe 158 at each of the servers 130(1), 130(2), and 130(3) (equated to second entities) configured to perform container introspection and to provide micro-service communication records 160 to the micro-services monitoring module 144(equated to first entity). As noted, each micro-service communication record 160 is associated with communications/traffic (i.e., one or more packets) sent from and/or to a micro-service 134(1), 134(2), or 134(3) in web application 150. As noted, FIG. 3A illustrates an example format for a micro-service communication record, while FIG. 3B illustrates an example format for a flow volume record. FIGS. 4A, 4B, and 4C illustrate specific examples of completed micro-service communication records 460(A), 460(B), and 460(C), respectively, associated with the arrangement shown in FIG. 2.) Referring first to FIG. 4A, the micro-service communication record 460(A) includes a time stamp 461(A) given as “Time 1,” a source cryptographic signature 462(A) given as “SHA-1 (client 151),” a destination cryptographic signature 463(A) given as “SHA-1 (web server),” a flow volume 464(A) given as “FV.sub.X”, and a flow duration 465(A) given as “FD.sub.X”. As such, the micro-service communication record 460(A) is associated with traffic sent from a binary executable of client device 151 to a binary executable of the web server micro-service 134(1) at a time identified as “Time 1,” which included “FV.sub.X” packets/bytes of data and a flow duration of “FD.sub.X” seconds. In FIG. 2, this traffic is represented by arrow 154(1). Referring next FIG. 4B, the micro-service communication record 460(B) includes a time stamp 461(B) given as “Time 2,” a source cryptographic signature 462(B) given as “SHA-1 (web server),” a destination cryptographic signature 463(B) given as “SHA-1 (business logic),” a flow volume 464(B) given as “FV.sub.Y”, and a flow duration 465(B) given as “FD.sub.Y”. As such, the micro-service communication record 460(B) is associated with traffic sent from a binary executable of the web server micro-service 134(1) to a binary executable of the business logic micro-service 134(2) at a time identified as “Time 2,” which included “FV.sub.Y” packets/bytes of data and a flow duration of “FD.sub.Y” seconds. In FIG. 2, this traffic is represented by arrow 154(2). Referring next FIG. 4C, the micro-service communication record 460(C) includes a time stamp 461(C) given as “Time 3,” a source cryptographic signature 462(C) given as “SHA-1 (business logic),” a destination cryptographic signature 463(C) given as “SHA-1 (database),” a flow volume 464(C) given as “FV.sub.Z”, and a flow duration 465(C) given as “FD.sub.Z”. As such, the micro-service communication record 460(C) is associated with traffic sent from a binary executable of the business logic micro-service 134(2) to a binary executable of the database micro-service 134(3) at a time identified as “Time 3,” which included “FV.sub.Z” packets/bytes of data and a flow duration of “FD.sub.Z” seconds. In FIG. 2, this traffic is represented by arrow 154(3). Returning to FIG. 2, the micro-service communication records 460(A) (FIG. 4A), 460(B) (FIG. 4B), and 460(C) (FIG. 4C) correspond to the traffic 154(1), 154(2), and 154(3) shown in FIG. 2. FIG. 2 also illustrates traffic 156(1), 156(2), and 156(3) which may also result in the generation of similar micro-service communication records. The micro-service communication records are sent (e.g., via probes 158) to the micro-services monitoring module 144. As such, the micro-services monitoring module 144 receives a plurality of micro-service communication records (e.g., records 460(A), 460(B), and 460(C)). The micro-services monitoring module 144 is configured to analyze the time series entries S within the records to determine the behavior of the web application 150 during the associated time period and to analyze the trace sequence identifiers (forming a trace sequence) to determine the pattern of traffic between well identified source and destination nodes], and [see claim 2]; and
the first request is transmitted to the first entity by a fourth entity, and the fourth entity is an application programming interface (API) server; initiating transmission of a message to the fourth entity, wherein the message comprises information associated with the traffic captured between the microservices during the session, and wherein the information associated with the traffic captured between the microservices during the session comprises [Col. 4 lines 15-38, (21) The micro-services 134(1)-134(3) within containers 135(1)-135(3) collectively form an application 150. That is, the application 150 is formed by a plurality of container-based micro-services that are distributed across the servers 130(1), 130(2), and 130(3) (i.e., across the compute cluster 132). Since the application 150 is formed by a plurality of micro-services 134(1)-134(3), the application 150 is sometimes referred to herein as a “micro-service application.” Application program interfaces (APIs) are used for the communications (i.e., sending of packets) between the micro-services 134(1)-134(3) …. As such, in the example of FIG. 1, the techniques presented herein utilize the micro-service communications/traffic (i.e., the APIs) to protect the container-based micro-services 134(1)-134(3)), and thus the micro-service application 150, from security threats], and [Col. 5 lines 13-24, (25) As noted above, the micro-services 134(1)-134(3) within web application 150 communicate with one another (e.g., via APIs). Communication between micro-services 134(1)-134(3) is referred to herein as intra-application communications/traffic. In addition, certain micro-services, such as web server 134(1), may communicate externally (i.e., send/receive traffic to/from devices outside of the web application 150), such as with one or more of client devices 151 and/or 153. The intra-application traffic and the traffic sent external to/from external devices (i.e., “external traffic”) are collectively and generally referred to herein as “micro-service communications” or “micro-service traffic.”]; and
Examiner Note: Garipally also discloses [Abstract, Described herein are systems and methods for updating configuration of a device based on changes to microservices. A device may receive a request via a desired state application programming interface (API) to update a configuration of the device to manage a desired set of instances of microservices. The device may identify from the request, a first set of endpoint information for each instance of a microservice in the desired set of instances of microservices. The first set of endpoint information may include an internet protocol (IP) address and port of an endpoint of a respective instance of the microservice…], and [Col. 2 lines 45-67, Col. 3 lines 1-9, Described herein is a system for updating configuration of a device based on changes to microservices. The system may include a device comprising one or more processors, coupled to memory and intermediary to a plurality of clients and microservices. The device may be configured to receive a request via a desired state application programming interface (API) to update a configuration of the device to manage a desired set of instances of microservices. The device may be configured to identify from the request, a first set of endpoint information for each instance of a microservice in the desired set of instances of microservices. The first set of endpoint information may include an internet protocol (IP) address and port of an endpoint of a respective instance of the microservice. The first set or second set of endpoint information may include a weight for each instance of the microservice. The device may be configured to communicate the first set of endpoint information to one or more packet engines of the device configured to manage network traffic to a current set of instances of microservices. … The device may be configured to receive the request from a controller of a cluster of microservices. The controller may be configured to receive information for the request from an API server for the microservices], and [Col. 4 lines 24-52, In further detail, the controller 440 of the cluster 430 of microservices 425 may manage each microservice 425 in the cluster 430. In managing the microservices 425 of the cluster 430, the controller 440 may communicate with the API server 435 for the microservices 425. In some embodiments, the API server 435 may be a part of the controller 440. The API server 435 may facilitate management of the cluster 430 of microservices 425. For example, the API server 435 may manage the microservices 425 of the cluster 430 in accordance with the Kubernetes orchestration system. The API server 435 may perform an update to the instances of the microservices 425 in the cluster 430. In conjunction with the update, the controller 440 may receive, retrieve, or otherwise identify a new set of endpoint information on each microservice 425 in the cluster 430. In some embodiments, the controller 440 may monitor for updates to the microservices 425 in the cluster 430. In response to detecting the update, the controller 440 may identify the set of endpoint information. In some embodiments, the new set of endpoint information may be received by the controller 440 from the API server 435. The new set of endpoint information for each microservice 425 may include an Internet Protocol (IP) address and a port of an endpoint of an instance of the microservice 425 in the cluster 430. In some embodiments, the endpoint information may include a weight for the instance of the microservice 425 in the cluster 430. The weight for the instance of the microservice 425 may correspond to a level of priority of the microservice 425 within the cluster 430].
one or more keys used to encrypt the traffic captured between the microservices during the session [ claim 7. The method of claim 1, wherein each of the trace sequence identifiers in the plurality of micro-service communication records and the one or more micro-service communication records comprises: a time stamp, a cryptographic signature identifier of a source executable that sent the associated traffic, and a cryptographic signature identifier of a destination executable that received the associated traffic]; and
information identifying the microservices between which the traffic is captured during the session [Col.4 lines 39-67, shown in FIG. 1 is a computing device 142 that includes a micro-service monitoring module 144. As described further below, the computing device 142 is configured to receive records 160 of the communications/traffic associated with (i.e., sent from and/or to) the micro-services 134(1)-134(3) ...], and [Col. 8 lines 7-19, More specifically, as shown by arrow 566 in FIG. 5, the micro-services monitoring module 144 receives a plurality of micro-service communication records (e.g., micro- service communication records 460(A), 460(B), 460(C), etc.) generated during a time period. As noted above, each of the micro-service communication records represented by arrow 566 include a trace sequence identifier (I) and a time series entry (S). As such, the plurality of micro-service communication records collectively represents a trace sequence {Id.sub.i.sup.2, Id.sub.i.sup.3}, shown as 566.2 and comprising the source and destination cryptographic signatures, and a time series (S.sub.i) 566.1, which comprises the flow volume and the flow duration at a given time {Id.sub.i.sup.1}]; and
information identifying one or more instances of the microservices between which the traffic is captured during the session [Col.4 lines 39-67, shown in FIG. 1 is a computing device 142 that includes a micro-service monitoring module 144. As described further below, the computing device 142 is configured to receive records 160 of the communications/traffic associated with (i.e., sent from and/or to) the micro-services 134(1)-134(3) ...].
in response to a change in data identifying the traffic to be captured, updating the one or more capture filters based on the changed data, wherein the first entity initiates transmission of the one or more updated capture filters towards the one or more second entities for use by the one or more second entities to capture the traffic between the microservices
While Fenoglio discloses this limitation as: [ Abstract, presented herein are techniques for detecting anomalies in micro-service communications that are indicative of security issues/problems for the application. More specifically, a computing device receives a plurality of micro-service communication records each associated with traffic sent between pairs of executables (nodes) that are related to a micro-services application. Each of the micro-service communication records includes a time series entry and an associated trace sequence identifier and each of the micro-service communication records are generated during a time period. The computing device analyzes the plurality of micro-service communications to detect possible anomalous communication patterns associated with the micro-services application during the time period], and [Col 3 lines 8-16, In certain examples presented herein, a computing device ( equated to first entity) receives a plurality of micro-service communication records ( equated to traffic) and analyzes these communication records to detect possible anomalous communication patterns associated with the micro-services application. Each micro-service communication record includes a time series entry S={S.sub.1, . . . , S.sub.N} of length N and an associated trace sequence identifier of the captured network traffic (i.e., flow characteristics of data exchanged between pairs of executables)], and [Col. 4 lines 39-50, More specifically, shown in FIG. 1 is a computing device 142 that includes a micro-service monitoring module 144( equated to first entity) . As described further below, the computing device 142 is configured to receive records 160 of the communications/traffic associated with (i.e., sent from and/or to) the micro-services 134(1)-134(3) (collecting captured traffic). Using these micro-service communication records 160, the micro-service monitoring module 144 is configured to detect deviations( equated to change in data) from typical communication patterns associated with the application 150 (i.e., detect anomalies in the communication patterns) that are indicative of security issues/problems affecting the application], and [ see FIG. 1 and corresponding text for more details, [ Col. 4 lines 15-24, The micro-services 134(1)-134(3) within containers 135(1)-135(3) collectively form an application 150. That is, the application 150 is formed by a plurality of container-based micro-services that are distributed across the servers 130(1), 130(2), and 130(3) (equated to second entities) (i.e., across the compute cluster 132). Since the application 150 is formed by a plurality of micro-services 134(1)-134(3), the application 150 is sometimes referred to herein as a “micro-service application.” Application program interfaces (APIs) are used for the communications (i.e., sending of packets) between the micro-services 134(1)-134(3)], and [ see FIG. 1 and corresponding text for more details], and (Col 5 lines 56-67- Col. 7 lines 1-53, lines in the example of FIG. 2, the micro-service communication records 160 are generated by the various micro-services 134(1)-134(3), and the micro-service communication records 160 include fields gathered doing container introspection. Each packet sent or received by a micro-service is associated with a binary executable (process) that is uniquely identified by a unique cryptographic signature, such as a Secure Hash Algorithm 1 (SHA-1), but any other secure algorithms can also or alternative be used, within a container…. FIG. 2 illustrates at least one probe 158 at each of the servers 130(1), 130(2), and 130(3) (equated to second entities) configured to perform container introspection and to provide micro-service communication records 160 to the micro-services monitoring module 144(equated to first entity). As noted, each micro-service communication record 160 is associated with communications/traffic (i.e., one or more packets) sent from and/or to a micro-service 134(1), 134(2), or 134(3) in web application 150.
As noted, FIG. 3A illustrates an example format for a micro-service communication record, while FIG. 3B illustrates an example format for a flow volume record. FIGS. 4A, 4B, and 4C illustrate specific examples of completed micro-service communication records 460(A), 460(B), and 460(C), respectively, associated with the arrangement shown in FIG. 2.) Referring first to FIG. 4A, the micro-service communication record 460(A) includes a time stamp 461(A) given as “Time 1,” a source cryptographic signature 462(A) given as “SHA-1 (client 151),” a destination cryptographic signature 463(A) given as “SHA-1 (web server),” a flow volume 464(A) given as “FV.sub.X”, and a flow duration 465(A) given as “FD.sub.X”. As such, the micro-service communication record 460(A) is associated with traffic sent from a binary executable of client device 151 to a binary executable of the web server micro-service 134(1) at a time identified as “Time 1,” which included “FV.sub.X” packets/bytes of data and a flow duration of “FD.sub.X” seconds. In FIG. 2, this traffic is represented by arrow 154(1). Referring next FIG. 4B, the micro-service communication record 460(B) includes a time stamp 461(B) given as “Time 2,” a source cryptographic signature 462(B) given as “SHA-1 (web server),” a destination cryptographic signature 463(B) given as “SHA-1 (business logic),” a flow volume 464(B) given as “FV.sub.Y”, and a flow duration 465(B) given as “FD.sub.Y”. As such, the micro-service communication record 460(B) is associated with traffic sent from a binary executable of the web server micro-service 134(1) to a binary executable of the business logic micro-service 134(2) at a time identified as “Time 2,” which included “FV.sub.Y” packets/bytes of data and a flow duration of “FD.sub.Y” seconds. In FIG. 2, this traffic is represented by arrow 154(2). Referring next FIG. 4C, the micro-service communication record 460(C) includes a time stamp 461(C) given as “Time 3,” a source cryptographic signature 462(C) given as “SHA-1 (business logic),” a destination cryptographic signature 463(C) given as “SHA-1 (database),” a flow volume 464(C) given as “FV.sub.Z”, and a flow duration 465(C) given as “FD.sub.Z”. As such, the micro-service communication record 460(C) is associated with traffic sent from a binary executable of the business logic micro-service 134(2) to a binary executable of the database micro-service 134(3) at a time identified as “Time 3,” which included “FV.sub.Z” packets/bytes of data and a flow duration of “FD.sub.Z” seconds. In FIG. 2, this traffic is represented by arrow 154(3). Returning to FIG. 2, the micro-service communication records 460(A) (FIG. 4A), 460(B) (FIG. 4B), and 460(C) (FIG. 4C) correspond to the traffic 154(1), 154(2), and 154(3) shown in FIG. 2. FIG. 2 also illustrates traffic 156(1), 156(2), and 156(3) which may also result in the generation of similar micro-service communication records. The micro-service communication records are sent (e.g., via probes 158) to the micro-services monitoring module 144. As such, the micro-services monitoring module 144 receives a plurality of micro-service communication records (e.g., records 460(A), 460(B), and 460(C)). The micro-services monitoring module 144 is configured to analyze the time series entries S within the records to determine the behavior of the web application 150 during the associated time period and to analyze the trace sequence identifiers (forming a trace sequence) to determine the pattern of traffic between well identified source and destination nodes]. [see claim 2].
As mentioned above while Fenoglio discloses “in response to a change in data identifying the traffic to be captured, updating the one or more capture filters based on the changed data” as [Col.2 lines 64-67, Col. 3 lines 1-7, Presented herein are techniques for securing an application that includes micro-services, such as downloaded container-based micro-services. In particular, the techniques presented herein monitor micro-service communications/traffic (i.e., packets/bytes sent to and/or from micro-services within the application) to detect any deviation from a nominal/typical behavior of the application in terms of the communication patterns (i.e., detect an anomaly in the micro-service communications). Deviations from the typical behavior (communication patterns) are indicative of security issues/problems affecting the application], and [Col. 4 lines 39-50, More specifically, shown in FIG. 1 is a computing device 142 that includes a micro-service monitoring module 144(equated to first entity). As described further below, the computing device 142 is configured to receive records 160 of the communications/traffic associated with (i.e., sent from and/or to) the micro-services 134(1)-134(3) (collecting captured traffic). Using these micro-service communication records 160, the micro-service monitoring module 144 is configured to detect deviations (equated to change in data) from typical communication patterns associated with the application 150 (i.e., detect anomalies in the communication patterns) that are indicative of security issues/problems affecting the application].
However, Fenoglio does not explicitly disclose this limitation and Garipally discloses [ Col. 2 lines 8-21, (8) The method may include communicating, by the device, the first set of endpoint information to each of one or more packet engines of the device. The packet engines may be configured to manage network traffic to a current set of instances of microservices. The method may include determining, by the one or more packet engines, a change between the first set of endpoint information and a second set of endpoint information configured on the one or more packet engine for each instance of the microservice in the current set of instances of microservices. The method may include updating, by the one or more packet engines based at least on the change, the configuration of the one or more packet engines to manage the desired set of instances of microservices], and [ Col. 2 lines 45-60, Described herein is a system for updating configuration of a device based on changes to microservices. The system may include a device comprising one or more processors, coupled to memory and intermediary to a plurality of clients and microservices. The device may be configured to receive a request via a desired state application programming interface (API) to update a configuration of the device to manage a desired set of instances of microservices. The device may be configured to identify from the request, a first set of endpoint information for each instance of a microservice in the desired set of instances of microservices. The first set of endpoint information may include an internet protocol (IP) address and port of an endpoint of a respective instance of the microservice. The first set or second set of endpoint information may include a weight for each instance of the microservice], and [Col. 18 lines 4-22, From the determine change, the packet engine 420 may identify or determine one or more endpoints in both the new set and the current set of endpoint information. The endpoints that are in both sets may correspond to instances of microservices 425 that are to continue running and receive network traffic after the application of the update to the microservices 425. In updating the configuration, the packet engine 420 may maintain the configuration on the packet engine 420 corresponding to the endpoints for microservices 425 that in both sets. By maintaining, the packet engine 402 may continue to use the same configuration as prior to the application of the update by the API server 435 to the cluster 430 of microservices 425. In this manner, the packet engine 420 may continue routing the network traffic to the microservice 425 corresponding to the endpoint in both the new set and the current set of endpoint information. The maintained configuration may correspond to an endpoint in the desired set of instances of microservices 425 as identified in the received request].
Fenoglio does not explicitly disclose , however Garipally discloses one or more ports exposed by the microservices in transmitting the traffic captured during the session [ Abstract, The first set of endpoint information may include an internet protocol (IP) address and port of an endpoint of a respective instance of the microservice], and [Col. 16 lines 12-24, In determining the risk score, the configuration engine 410 may determine whether the IP address or port in the new set of endpoint information is valid. For example, the new set of endpoint information may include invalid IP addresses or ports that does not correspond to any of the microservices 425. In such scenarios, the configuration engine 410 may generate a relatively high-risk score. On the other hand, the new set of end point information may include valid IP addresses or ports. In this case, the configuration engine 410 may calculate a relatively lower risk score. Based on the determination, the configuration engine 410 may calculate, generate, or determine the risk score for the new set of endpoint information], and [Col. 17 lines 19-37]; and
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Fenoglio by incorporating “packet engine on each appliance”, as taught by Garipally. One could have been motivated to do so in order to use the configuration of the packet engine to route the network traffic to the instance of the microservice corresponding to the endpoint as referenced by the IP address and the port [ Garipally, Col. 17 lines 19-67- Col.18 lines 1-3].
Regarding claims 41, and 50, Fenoglio discloses wherein the message further comprises the traffic captured between the microservices during the session; or one or more references or links for downloading the traffic captured between the microservices during the session [Col. 8 lines 7-19, More specifically, as shown by arrow 566 in FIG. 5, the micro-services monitoring module 144 receives a plurality of micro-service communication records (e.g., micro-service communication records 460(A), 460(B), 460(C), etc.) generated during a time period. As noted above, each of the micro-service communication records represented by arrow 566 include a trace sequence identifier (I) and a time series entry (S). As such, the plurality of micro-service communication records collectively represents a trace sequence {Id.sub.i.sup.2, Id.sub.i.sup.3}, shown as 566.2 and comprising the source and destination cryptographic signatures, and a time series (S.sub.i) 566.1, which comprises the flow volume and the flow duration at a given time {Id.sub.i.sup.1}].
Regarding claims 42, 51, wherein the one or more capture filters are generated based on data identifying the traffic that is to be captured, wherein the data identifying the traffic that is to be captured comprises: data identifying the microservices between which the traffic is to be captured; data indicative of the plurality of nodes across which the microservices are distributed; Even though, Fenoglio discloses, [Col.4 lines 39-67, shown in FIG. 1 is a computing device 142 that includes a micro-service monitoring module 144. As described further below, the computing device 142 is configured to receive records 160 of the communications/traffic associated with (i.e., sent from and/or to) the micro-services 134(1)-134(3)...], and [Col. 8 lines 7-19, More specifically, as shown by arrow 566 in FIG. 5, the micro-services monitoring module 144 receives a plurality of micro-service communication records (e.g., micro-service communication records 460(A), 460(B), 460(C), etc.) generated during a time period. As noted above, each of the micro-service communication records represented by arrow 566 include a trace sequence identifier (I) and a time series entry (S). As such, the plurality of micro-service communication records collectively represents a trace sequence {Id.sub.i.sup.2, Id.sub.i.sup.3}, shown as 566.2 and comprising the source and destination cryptographic signatures, and a time series (S.sub.i) 566.1, which comprises the flow volume and the flow duration at a given time {Id.sub.i.sup.1}.
Fenoglio, does not explicitly disclose, however, Garipally discloses: data indicative of one or more ports exposed by the microservices in transmitting the traffic that is to be captured; and/or data indicative of one or more protocols used by the microservices to transmit the traffic that is to be captured [Abstract, described herein are systems and methods for updating configuration of a device based on changes to microservices. A device may receive a request via a desired state application programming interface (API) to update a configuration of the device to manage a desired set of instances of microservices. The device may identify from the request, a first set of endpoint information for each instance of a microservice in the desired set of instances of microservices. The first set of endpoint information may include an internet protocol (IP) address and port of an endpoint of a respective instance of the microservice. The first set or second set of endpoint information may include a weight for each instance of the microservice], and [Col. 17 lines 52-67- Col.18 lines 1-3, Based on the change determined between the new set and the current set, the packet engine 420 may update the configuration of the packet engine 420 itself to manage the desired set of microservices 425 in the cluster 430 as identified in the received request. In some embodiments, the packet engine 420 may reconfigure the packet engine 420 itself in accordance with the determined change. The configuration of the packet engine 420 may be used to route the network traffic to the instance of the microservice 425 corresponding to the endpoint as referenced by the IP address and the port. The update to the configuration may cause the packet engine 420 to change the routing of the network traffic to the instances of microservices 425 in the cluster 430 in accordance with the new set of endpoint information identified from the request. The update in the configuration of the packet engines 420 may be performed without any synchronization, thereby allowing for a seamless transition between updates to the cluster 430 of microservices 425]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Fenoglio by incorporating “packet engine on each appliance”, as taught by Garipally. One could have been motivated to do so in order to the configuration of the packet engine to be used to route the network traffic to the instance of the microservice corresponding to the endpoint as referenced by the IP address and the port [ Garipally, Col. 17 lines 19-67- Col.18 lines 1-3].
Regarding claims 43, and 52, Fenoglio discloses, further comprising retrieving the data identifying the traffic that is to be captured [Col.4 lines 39-67, shown in FIG. 1 is a computing device 142 that includes a micro-service monitoring module 144. As described further below, the computing device 142 is configured to receive records 160 of the communications/traffic associated with (i.e., sent from and/or to) the micro-services 134(1)-134(3) ...].
Regarding claims 44, and 53, Fenoglio discloses further comprising generating the one or more capture filters for use by the one or more second entities [Col. 8 lines 7-19, More specifically, as shown by arrow 566 in FIG. 5, the micro-services monitoring module 144 receives a plurality of micro-service communication records (e.g., micro-service communication records 460(A), 460(B), 460(C), etc.) generated during a time period. As noted above, each of the micro-service communication records represented by arrow 566 include a trace sequence identifier (I) and a time series entry (S). As such, the plurality of micro-service communication records collectively represents a trace sequence {Id.sub.i.sup.2, Id.sub.i.sup.3}, shown as 566.2 and comprising the source and destination cryptographic signatures, and a time series (S.sub.i) 566.1, which comprises the flow volume and the flow duration at a given time {Id.sub.i.sup.1}.
Regarding claims 45, and 54, Fenoglio discloses, further comprising initiating transmission of a third request towards one or more third entities, wherein the third request is a request that the one or more third entities monitor traffic flows between the microservices during the session, and wherein the one or more third entities is at least one of: a server, a virtual machine, or a traffic capture sidecar that runs in the microservices [Col. 8 lines 7-19, More specifically, as shown by arrow 566 in FIG. 5, the micro-services monitoring module 144 receives a plurality of micro-service communication records (e.g., micro-service communication records 460(A), 460(B), 460(C), etc.) generated during a time period. As noted above, each of the micro-service communication records represented by arrow 566 include a trace sequence identifier (I) and a time series entry (S). As such, the plurality of micro-service communication records collectively represents a trace sequence {Id.sub.i.sup.2, Id.sub.i.sup.3}, shown as 566.2 and comprising the source and destination cryptographic signatures, and a time series (S.sub.i) 566.1, which comprises the flow volume and the flow duration at a given time {Id.sub.i.sup.1}], and [Col 5 lines 56-67- Col. 7 lines 1-53].
Regarding claims 46, and 55, Fenoglio discloses, further comprising, in response to a fourth request to terminate the capture of traffic, acquiring, from the one or more second entities, the traffic captured between the microservices during the session to store the traffic captured in a common place in order to correlate and render the traffic captured [Col. 8 lines 7-19, More specifically, as shown by arrow 566 in FIG. 5, the micro-services monitoring module 144 receives a plurality of micro-service communication records (e.g., micro-service communication records 460(A), 460(B), 460(C), etc.) generated during a time period. As noted above, each of the micro-service communication records represented by arrow 566 include a trace sequence identifier (I) and a time series entry (S). As such, the plurality of micro-service communication records collectively represents a trace sequence {Id.sub.i.sup.2, Id.sub.i.sup.3}, shown as 566.2 and comprising the source and destination cryptographic signatures, and a time series (S.sub.i) 566.1, which comprises the flow volume and the flow duration at a given time {Id.sub.i.sup.1}.
Regarding claims 47, and 56, Fenoglio discloses, wherein the traffic to be captured during the session comprises encrypted traffic, wherein the method further comprises acquiring, from one or more third entities, details for decrypting the encrypted traffic, wherein the details comprise a private key and/or a pre-master secret key used to encrypt the traffic captured during the session [Col. 5 lines 56-67- Col. 6 lines 1-25, Each packet sent or received by a micro-service is associated with a binary executable (process) that is uniquely identified by a unique cryptographic signature, such as a Secure Hash Algorithm 1 (SHA-1), but any other secure algorithms can also or alternative be used, within a container. FIG. 3A is a schematic diagram illustrating the format/arrangement of a micro-service communication record 360 in accordance with certain examples presented herein. In this example, the micro-service communication record 360 comprises a trace identifier (Id) and a time series entry (S). As such, the micro-service communication record 360 is defined as {Id,S}, a (3+D)-dimensional micro-service communication data. Each trace sequence identifier is given as: Id.sub.i={Id.sub.i.sup.1, Id.sub.i.sup.2, Id.sub.i.sup.3}, and is represented by a time stamp (Id.sub.i.sup.1=TS.sub.i) 361, a source cryptographic signature (Id.sub.i.sup.2=SCS.sub.i) 362, and a destination cryptographic signature (Id.sub.i.sup.3=DCS.sub.i) 363], and [ Col. 5 lines 63-67- Col. 7 lines 1-8, Referring first to FIG. 4A, the micro-service communication record 460(A) includes a time stamp 461(A) given as “Time 1,” a source cryptographic signature 462(A) given as “SHA-1 (client 151),” a destination cryptographic signature 463(A) given as “SHA-1 (web server),” a flow volume 464(A) given as “FV.sub.X”, and a flow duration 465(A) given as “FD.sub.X”. As such, the micro-service communication record 460(A) is associated with traffic sent from a binary executable of client device 151 to a binary executable of the web server micro-service 134(1) at a time identified as “Time 1,” which included “FV.sub.X” packets/bytes of data and a flow duration of “FD.sub.X” seconds. In FIG. 2, this traffic is represented by arrow 154(1)].
Regarding claims 48, and 57, Fenoglio discloses, wherein the information further comprises details for decrypting the encrypted traffic, wherein the details comprise a private key and/or a pre-master secret key used to encrypt the traffic captured during the session [Col. 5 lines 56-67- Col. 6 lines 1-25, Each packet sent or received by a micro-service is associated with a binary executable (process) that is uniquely identified by a unique cryptographic signature, such as a Secure Hash Algorithm 1 (SHA-1), but any other secure algorithms can also or alternative be used, within a container. FIG. 3A is a schematic diagram illustrating the format/arrangement of a micro-service communication record 360 in accordance with certain examples presented herein. In this example, the micro-service communication record 360 comprises a trace identifier (Id) and a time series entry (S). As such, the micro-service communication record 360 is defined as {Id,S}, a (3+D)-dimensional micro-service communication data. Each trace sequence identifier is given as: Id.sub.i={Id.sub.i.sup.1, Id.sub.i.sup.2, Id.sub.i.sup.3}, and is represented by a time stamp (Id.sub.i.sup.1=TS.sub.i) 361, a source cryptographic signature (Id.sub.i.sup.2=SCS.sub.i) 362, and a destination cryptographic signature (Id.sub.i.sup.3=DCS.sub.i) 363], and [ Col. 5 lines 63-67- Col. 7 lines 1-8, Referring first to FIG. 4A, the micro-service communication record 460(A) includes a time stamp 461(A) given as “Time 1,” a source cryptographic signature 462(A) given as “SHA-1 (client 151),” a destination cryptographic signature 463(A) given as “SHA-1 (web server),” a flow volume 464(A) given as “FV.sub.X”, and a flow duration 465(A) given as “FD.sub.X”. As such, the micro-service communication record 460(A) is associated with traffic sent from a binary executable of client device 151 to a binary executable of the web server micro-service 134(1) at a time identified as “Time 1,” which included “FV.sub.X” packets/bytes of data and a flow duration of “FD.sub.X” seconds. In FIG. 2, this traffic is represented by arrow 154(1)].
Regarding claim 58, this claim is interpreted and rejected for the same rational set forth in claim 40.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See form 892 for more relevant references.
Guo (US10205648) [ Abstract, A request is obtained at a monitoring controller to provide a monitoring function for at least one subject virtual processing element (e.g., VM) in a virtualized information processing system. The monitoring controller selects and/or provisions at least one traffic capture appliance configured to capture traffic associated with the subject virtual processing element. The monitoring controller requests the virtualized information processing system to forward a copy of traffic associated with the subject virtual processing element, using traffic mirroring and an encapsulated tunnel, to the traffic capture appliance for analysis].
Ahuja (US2018/0083985) [¶43, In an embodiment, TCP/IP microservices 210 and 212 are stateless, but may benefit from the context X generation performed by interface microservice 202. For example, whichever of TCP/IP microservices 210 and 212 receives packet A may disassemble the packet to extract the data associated with the packet and conduct security processing on the data. TCP/IP reassembly generally consists of associating packets with flows (e.g., identified by source and destination IP and port values) ], and [¶53, In the example above of a port scan, a subevent processing microservice 340 may detect each of the client requests received by a host server as an individual subevent (e.g., in response to receiving a notification of the corresponding network messages from one or more microservices 310-332). As described in more detail in subsequent sections, a subevent processing microservice 340 may further match the detected subevents against one or more configured “security event” definitions to determine if and when the series of client requests indicates an occurrence of a “port scan” security event], and [¶55, In an embodiment, a security event processing microservice 350 performs one or more actions in response to detection of security events by a subevent processing microservice 340. Referring again to the example of a port scan described above, in response to a subevent processing microservice 340 determining that a particular pattern of subevents corresponds to an occurrence of a port scan security event, the subevent processing microservice 340 generates security event data to report the security event occurrence to a security event processing microservice 350. For example, in response to receiving an indication of a “port scan” security event, a security event processing microservice 350 may perform one or more network security actions including adding or modifying firewall security rules, running a security scan on relevant servers, or any other network security function], and [¶52].
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 SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights