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 .
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-3 are rejected under 35 U.S.C. 103 as being unpatentable over Poornachandran et al (US 11,561,868), in view of Shpilyuck et al (US 2023/0205578).
Regarding claim 1, Poornachandran teaches a system comprising:
a service stack comprising a plurality of layers to provide microservices corresponding to an application, wherein the service stack comprises application services, a container environment, a virtualized infrastructure and a physical infrastructure (Poornachandran fig.4 and col.14 lines 1-25 provides “…a block diagram illustrating dependency graphs within a microservices service stack 400 for alternative hardware/software service instances of a service offered by a service provider according to some embodiments. In the context of the present example, microservices service stack 400 is shown including a device layer 450 (e.g., connecting to the heterogeneous hardware devices (e.g., XPUs, SSDs, etc. shown in FIG. 1), a microservices layer 410, a container layer 420, a VM layer 430, and a VMM layer 440 (which may be referred to herein collectively as microservices service stack layers). Each of the layers of the microservices service stack layers may implement one or more redundancy features, for example, a given layer may include zero or failover agents. In order to take advantage of the finer granularity of both hardware and software components in a disaggregated computing environment in which a microservices-based services is implemented, it is desirable to address errors (e.g., take corrective action and/or implement failover/takeover operations) at the lowest possible layer of microservices service stack 400. As such, in embodiments described herein, each of the layers implementing a redundancy feature may take policy-based actions as information regarding the occurrence of an error is propagated through the layers”);
a plurality of collector agents located in the container environment, the virtualized infrastructure and the physical infrastructure to collect data representing interlayer dependencies (Poornachandran col.12 lines 25-55 provides “Returning to SMC 340 it may represent a non-limiting example of SMC 170 of FIG. 1. In the present example, SMC 340 is shown including a controller 350 and an evaluator 360. In one embodiment, controller 350 may perform various tasks to facilitate microservice failover/takeover. For example, controller 350 may include a discovery service 356, a recommendation service 352, a failover service, and an XPU manager 358. Discovery service 356 may be responsible for discovery of the functionality, health, and availability of XPUs for use by a service instance, discovery of redundancy features (e.g., failover agents) supported by the infrastructure and the microservices architecture of the service at issue. For example, microservices may expose their capabilities (including support for failover agents) in a microservices registry database (not shown) accessible to the discovery service. Discovery service 356 may also be responsible for determining whether compatible software versions of microservices are available for the particular datacenter environment and available XPUs. In one embodiment, during a discovery phase, discovery service 356 may create an interdependency flow matrix of all microservices that are stitched together to provide the service and may create various dependency graphs representing various options for deploying the service and/or one or more contingency plans should failures occur at a layer of the microservices service stack layers. The information collected during the discovery phase may be useful in connection with understanding good matches between a particular microservice and a particular processing resource to facilitate placement decisions that may be made by recommendation service 352”).
Poornachandran teaches the above including receiving data from the plurality of collector agents (Poornachandran col.12 lines 25-55), but Poornachandran does not explicitly teach a map generation engine to: based on the interlayer dependencies, generate data representing a map of the service stack and dependency topology of the service stack, wherein the service stack to allow an issue associated with the application services, the virtualized infrastructure or the physical infrastructure to be traced via the map to identify a root cause of the issue. However, in a similar field of endeavor, Shpilyuck teaches teach a map generation engine to: based on the interlayer dependencies, generate data representing a map of the service stack and dependency topology of the service stack, wherein the service stack to allow an issue associated with the application services, the virtualized infrastructure or the physical infrastructure to be traced via the map to identify a root cause of the issue (Shpilyuck [0018] provides “…in a microservices architecture can be to use container health and connectivity graph analysis (where microservices are hosted in containers) to aggregate health information and detect issues deep within a call chain, and adjust load balancing to avoid forwarding calls to potentially error-prone targets”; [0039-0043] provides “Identifying a microservices request chain for a particular external API call can be implemented as follows. A tracing system can trace a full request path of an API call. A tracing system can comprise a client-side library that intercepts calls that arrive to a microservice, adds a correlation ID (where one exists) to the request context, and propagates this correlation ID further down the request chain. In other examples, an application can add the correlation ID. A central tracing server can be contacted by a client-side library in order to save request information for further retrieval (alternatively, the information can be harvested from logs and traces). Eventually, a full request chain (e.g., involved microservices and corresponding Uniform Resource Locators (URLs)) can be obtained from a tracing server based on a correlation ID… Path information can comprise a sub-graph of a cluster connectivity graph… This information can be stored by a health analyzer component in the form of a map”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of mapping microservice dependencies as taught by Shpilyuck in the Poornachandran system to be able to identify an intersection of “involved microservices” and “unhealthy microservices” once dependencies and issues are both identified.
Regarding claim 2, the system of claim 1, wherein the root cause comprises the most probable root cause of the issue, and wherein the service stack comprises a full-service stack (Shpilyuck [0018] provides “…in a microservices architecture can be to use container health and connectivity graph analysis (where microservices are hosted in containers) to aggregate health information and detect issues deep within a call chain, and adjust load balancing to avoid forwarding calls to potentially error-prone targets”; [0039-0043] provides “Identifying a microservices request chain for a particular external API call can be implemented as follows. A tracing system can trace a full request path of an API call). Motivation provided with reference to claim 1.
Regarding claim 3, the system of claim 1, wherein: the container environment is associated with an orchestrated container cluster (Poornachandran col.11 lines 39-44 provides “The service may be orchestrated and managed using service management component (SMC) 340, which may be complementary to a container orchestration platform (not shown). SMC 340 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware”); the virtualized infrastructure comprises a virtual machine that hosts a worker node of the orchestrated container cluster (Poornachandran col.10 lines 25-40 provides “A hypervisor 213 (also known as a virtual machine monitor (VMM)) may comprise logic to create and run guest systems 222. The hypervisor 213 may present guest operating systems run by virtual machines with a virtual operating platform (i.e., it appears to the virtual machines that they are running on separate physical nodes when they are actually consolidated onto a single hardware platform) and manage the execution of the guest operating systems by platform resources 210. Services of hypervisor 213 may be provided by virtualizing in software or through hardware-assisted resources that utilize minimal software intervention, or both. Multiple instances of a variety of guest operating systems may be managed by the hypervisor 213. Each platform 202 may have a separate instantiation of a hypervisor 213”); and the plurality of collector agents comprises a given collector agent to provide data identifying the virtual machine (Poornachandran fig.4 and col.14 lines 1-25 provides “…a block diagram illustrating dependency graphs within a microservices service stack 400 for alternative hardware/software service instances of a service offered by a service provider according to some embodiments. In the context of the present example, microservices service stack 400 is shown including a device layer 450 (e.g., connecting to the heterogeneous hardware devices (e.g., XPUs, SSDs, etc. shown in FIG. 1), a microservices layer 410, a container layer 420, a VM layer 430, and a VMM layer 440 (which may be referred to herein collectively as microservices service stack layers)”).
Claims 4, 9 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Poornachandran et al (US 11,561,868), in view of Shpilyuck et al (US 2023/0205578), further in view of Denneman et al (US 2023/0035310).
Regarding claim 4, Poornachandran-Shpilyuck teaches the system of claim 1, but Poornachandran-Shpilyuck does not explicitly teach wherein: the container environment comprises a worker node; the virtualized infrastructure comprises a virtual machine that hosts the worker node; the virtual machine comprises a given collector agent of the plurality of collector agents to provide data associating virtual resources with the virtual machine. However, in a similar field of endeavor, Denneman teaches wherein: the container environment comprises a worker node (Denneman [0081] provides “A Kubernetes management node further includes an etcd key-value data store 2010 and a cloud-controller manager 2012, which includes multiple controllers that manage cloud-hosted Kubernetes cluster components. The above-discussed logical components of a master node are implemented above the computational resources 2014 provided by a virtual machine or physical server. A worker node 2020 includes a Kubelet agent 2022 that manages pods running within the worker node in cooperation with the control plate, with which the Kubelet agent communicates via the Kubernetes API, as indicated by dashed arrow 2024. In addition, a worker node includes a container run time 2026, such as the Docker container runtime, and one or more pods 2028-2030 that execute using the computational resources 2032 provided by a virtual machine or physical server”); the virtualized infrastructure comprises a virtual machine that hosts the worker node (Denneman [0081] provides “A Kubernetes management node further includes an etcd key-value data store 2010 and a cloud-controller manager 2012, which includes multiple controllers that manage cloud-hosted Kubernetes cluster components. The above-discussed logical components of a master node are implemented above the computational resources 2014 provided by a virtual machine or physical server. A worker node 2020 includes a Kubelet agent 2022 that manages pods running within the worker node in cooperation with the control plate, with which the Kubelet agent communicates via the Kubernetes API, as indicated by dashed arrow 2024. In addition, a worker node includes a container run time 2026, such as the Docker container runtime, and one or more pods 2028-2030 that execute using the computational resources 2032 provided by a virtual machine or physical server”); the virtual machine comprises a given collector agent of the plurality of collector agents to provide data associating virtual resources with the virtual machine Denneman [0081] provides “A Kubernetes management node further includes an etcd key-value data store 2010 and a cloud-controller manager 2012, which includes multiple controllers that manage cloud-hosted Kubernetes cluster components. The above-discussed logical components of a master node are implemented above the computational resources 2014 provided by a virtual machine or physical server. A worker node 2020 includes a Kubelet agent 2022 that manages pods running within the worker node in cooperation with the control plate, with which the Kubelet agent communicates via the Kubernetes API, as indicated by dashed arrow 2024. In addition, a worker node includes a container run time 2026, such as the Docker container runtime, and one or more pods 2028-2030 that execute using the computational resources 2032 provided by a virtual machine or physical server”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of the entities as taught by Denneman in the Poornachandran-Shpilyuck system to be able to identify entities with assigned roles to collect interlayer dependency data.
Regarding claim 9, Poornachandran-Shpilyuck teaches the system of claim 1, but Poornachandran-Shpilyuck does not explicitly teach wherein: the container environment comprises a worker node; the worker node is hosted on a computer platform; and the computer platform comprises a given collector agent of the plurality of collector agents to provide data associating resources with the computer platform. However, in similar field of endeavor, Denneman teaches wherein: the container environment comprises a worker node (Denneman [0081]; the worker node is hosted on a computer platform (Denneman [0081]); and the computer platform comprises a given collector agent of the plurality of collector agents to provide data associating resources with the computer platform (Denneman [0081] provides “A Kubernetes management node further includes an etcd key-value data store 2010 and a cloud-controller manager 2012, which includes multiple controllers that manage cloud-hosted Kubernetes cluster components. The above-discussed logical components of a master node are implemented above the computational resources 2014 provided by a virtual machine or physical server. A worker node 2020 includes a Kubelet agent 2022 that manages pods running within the worker node in cooperation with the control plate, with which the Kubelet agent communicates via the Kubernetes API, as indicated by dashed arrow 2024. In addition, a worker node includes a container run time 2026, such as the Docker container runtime, and one or more pods 2028-2030 that execute using the computational resources 2032 provided by a virtual machine or physical server”); the virtual machine comprises a given collector agent of the plurality of collector agents to provide data associating virtual resources with the virtual machine Denneman [0081] provides “A Kubernetes management node further includes an etcd key-value data store 2010 and a cloud-controller manager 2012, which includes multiple controllers that manage cloud-hosted Kubernetes cluster components. The above-discussed logical components of a master node are implemented above the computational resources 2014 provided by a virtual machine or physical server. A worker node 2020 includes a Kubelet agent 2022 that manages pods running within the worker node in cooperation with the control plate, with which the Kubelet agent communicates via the Kubernetes API, as indicated by dashed arrow 2024. In addition, a worker node includes a container run time 2026, such as the Docker container runtime, and one or more pods 2028-2030 that execute using the computational resources 2032 provided by a virtual machine or physical server”). Motivation provided with reference to claim 4.
Regarding claim 11, Poornachandran-Shpilyuck teaches the system of claim 1, but Poornachandran-Shpilyuck does not explicitly teach wherein: the microservices are distributed across a distributed system of computer systems; and each computer system of the distributed system comprises components associated with the plurality of layers. However, in a similar field of endeavor, Denneman teaches wherein: the microservices are distributed across a distributed system of computer systems (Denneman [0054-0055]); and each computer system of the distributed system comprises components associated with the plurality of layers (Denneman [0054-0055]). Motivation provided with reference to claim 4.
Regarding claim 12, Poornachandran-Shpilyuck-Denneman teaches the system of claim 11, wherein: a first computer system of the distributed system is associated with a public cloud (Denneman [0066]); and a second computer system of the distributed system other than the first computer system is associated with a private cloud (Denneman [0066] provides “In FIG. 10, seven different cloud-computing facilities are illustrated 1002-1008. Cloud-computing facility 1002 is a private multi-tenant cloud with a cloud director 1010 that interfaces to a VI management server 1012 to provide a multi-tenant private cloud comprising multiple tenant-associated virtual data centers. The remaining cloud-computing facilities 1003-1008 may be either public or private cloud-computing facilities and may be single-tenant virtual data centers, such as virtual data centers 1003 and 1006, multi-tenant virtual data centers, such as multi-tenant virtual data centers 1004 and 1007-1008, or any of various different kinds of third-party cloud-services facilities, such as third-party cloud-services facility 1005”). Motivation provided with reference to claim 4.
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Poornachandran et al (US 11,561,868), in view of Shpilyuck et al (US 2023/0205578), in view of Denneman et al (US 2023/0035310), further in view of Tang (US 2016/0259659).
Regarding claim 5, Poornachandran-Shpilyuck-Denneman teaches the system of claim 4, but Poornachandran-Shpilyuck-Denneman does not explicitly teach wherein the data associating the virtual resources with the virtual machine comprises data representing a virtual local area network (VLAN) identifier. However, in a similar field of endeavor, Tang teaches wherein the data associating the virtual resources with the virtual machine comprises data representing a virtual local area network (VLAN) identifier (Tang [0017] provides “The virtual device module 601 running on the virtual machine 210 maintains an internal communication (such as a TCP connection to a known port) with the device binding module 600 to obtain the application specific connectivity information received from the management module 610. Such information instructs the virtual device module (601) to create an application specific aNIC 612 on top of the VF102.1 with specified MAC address and other properties such as virtual LAN (vlan) and maximum transmit unit. All packets sent out the aNIC 612 will have the unique MAC address (612) as source MAC that can be used to implement application aware network policy, such as MAC based vlan or Qos policy. An application specific block storage interface aHBA 613 is also created by the virtual device module (601) with unique worldwide port name (WWPN) that is mapped to N_port ID of the VF103.1. This WWPN is used for storage area network (SAN) zoning and LUN presentation which simplifies the implementation of application aware storage policy in SAN or at storage devices”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of the entities as taught by Tang in the Poornachandran-Shpilyuck-Denneman system to divide a physical LAN into multiple logical networks and reduce traffic while increasing security.
Regarding claim 6, Poornachandran-Shpilyuck-Denneman teaches the system of claim 5, but Poornachandran-Shpilyuck-Denneman does not explicitly teach wherein the data associating the virtual resources with the virtual machine comprises data representing a logical storage unit (LUN) identifier. However, in a similar field of endeavor, Tang teaches wherein the data associating the virtual resources with the virtual machine comprises data representing a logical storage unit (LUN) identifier (Tang [0017] provides “The virtual device module 601 running on the virtual machine 210 maintains an internal communication (such as a TCP connection to a known port) with the device binding module 600 to obtain the application specific connectivity information received from the management module 610. Such information instructs the virtual device module (601) to create an application specific aNIC 612 on top of the VF102.1 with specified MAC address and other properties such as virtual LAN (vlan) and maximum transmit unit. All packets sent out the aNIC 612 will have the unique MAC address (612) as source MAC that can be used to implement application aware network policy, such as MAC based vlan or Qos policy. An application specific block storage interface aHBA 613 is also created by the virtual device module (601) with unique worldwide port name (WWPN) that is mapped to N_port ID of the VF103.1. This WWPN is used for storage area network (SAN) zoning and LUN presentation which simplifies the implementation of application aware storage policy in SAN or at storage devices”). Motivation provided with reference to claim 5.
Claims 7 is rejected under 35 U.S.C. 103 as being unpatentable over Poornachandran et al (US 11,561,868), in view of Shpilyuck et al (US 2023/0205578), in view of Denneman et al (US 2023/0035310), in view of Tang (US 2016/0259659), further in view of Parakh et al (US 2015/0006729).
Regarding claim 7, Poornachandran-Shpilyuck-Denneman-Tang teaches the system of claim 5, but Poornachandran-Shpilyuck-Denneman -Tang does not explicitly teach wherein the data associating the virtual resources with the virtual machine comprises data associating the virtual machine with a network overlay. However, in a similar field of endeavor, Parakh teaches wherein the data associating the virtual resources with the virtual machine comprises data associating the virtual machine with a network overlay (Parakh [0128-0130] provides “…the leasing system 224 may select a producer virtual machine 1162 to lease to a consumer virtual machine 1142 based on the overlay network with which the producer virtual machine 1162 and the consumer virtual machine 1142 are associated”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of the entities as taught by Parakh in the Poornachandran-Shpilyuck-Denneman-Tang system as a network overlay allows virtual machines (VMs) a software-defined network layer on top of the physical (underlay) network, thereby enabling VMs to communicate as if they were on a single, unified network, even if they are physically separated or on different hosts.
Claims 8 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Poornachandran et al (US 11,561,868), in view of Shpilyuck et al (US 2023/0205578), in view of Denneman et al (US 2023/0035310), further in view of Steinberg (US 10,108,446).
Regarding claim 8, Poornachandran-Shpilyuck-Denneman teaches the system of claim 4, but Poornachandran-Shpilyuck-Denneman does not explicitly teach wherein the virtual machine comprises a guest operating system kernel and the given collector agent is part of the operating system kernel. However, in a similar field of endeavor, Steinberg teaches wherein the virtual machine comprises a guest operating system kernel and the given collector agent is part of the operating system kernel (Steinberg col.8 lines 50-57 provides “Alternatively, the threat protection component may examine directly the memory used by the guest O/S (i.e., virtual machine introspection) to determine locations (and layout) of the process table 245 so as to determine the ID of the guest process 240. Illustratively, threat protection component 354 may communicate with the guest operating system kernel 230 (i.e., the agent 360) over a defined application programming interface (API) 365”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of the entities as taught by Steinberg in the Poornachandran-Shpilyuck-Denneman system to allow collection of data for performance monitoring, security analysis, and debugging.
Regarding claim 10, Poornachandran-Shpilyuck-Denneman teaches the system of claim 9, but Poornachandran-Shpilyuck-Denneman does not explicitly teach wherein: the computer platform comprises a host operating system kernel; and the host operating system kernel comprises the given collector agent. However, in a similar field of endeavor, Steinberg teaches wherein: the computer platform comprises a host operating system kernel; and the host operating system kernel comprises the given collector agent (Steinberg col.8 lines 19-35 provides “For example, identification (ID) of each guest process 240 running in the guest operating system may be obtained from process IDs stored in a data structure, e.g., the process table 245, of the guest operating system. Accordingly, instead of having to know a location and format of that data structure, the threat protection component 354 can instruct the agent to examine the process table 245 and provide the ID of the guest process 240. That is, the agent 360 operating in the guest mode may act on behalf callers (e.g., guest monitor 352) operating in the host mode to access data structures in the guest mode. Alternatively, the threat protection component may examine directly the memory used by the guest O/S (i.e., virtual machine introspection) to determine locations (and layout) of the process table 245 so as to determine the ID of the guest process 240. Illustratively, threat protection component 354 may communicate with the guest operating system kernel 230 (i.e., the agent 360) over a defined application programming interface (API) 365”). Motivation provided with reference to claim 8.
Claims 13 is rejected under 35 U.S.C. 103 as being unpatentable over Poornachandran et al (US 11,561,868), in view of Shpilyuck et al (US 2023/0205578), in view of Denneman et al (US 2023/0035310), further in view of Lee et al (US 2023/0171205).
Regarding claim 13, Poornachandran-Shpilyuck- Denneman teaches the system of claim 12, but Poornachandran-Shpilyuck-Denneman does not explicitly teach wherein: a first microservice of the microservices is deployed on the first computer system and provides machine learning model-based processing; and a second microservice of the microservices is deployed on the second computer system and provides input for the machine learning model-based processing. However, in a similar field of endeavor, Lee teaches wherein: a first microservice of the microservices is deployed on the first computer system and provides machine learning model-based processing; and a second microservice of the microservices is deployed on the second computer system and provides input for the machine learning model-based processing (Lee [0006] provides “The present disclosure in its one aspect provides an information processing apparatus comprising a controller comprising at least one processor, the controller being configured to execute: acquiring a plurality of datasets, each of the datasets being configured with a combination of training data and a correct answer label; and implementing machine learning of an estimation model using the acquired plurality of datasets, wherein the training data includes workload information about an application constructed based on a microservice architecture and resource use information about resources used for each of components included in the application, in a learning target environment, the correct answer label is configured to show a true value of quality of service of the application, and the machine learning comprises training the estimation model such that, for each of the datasets, an estimated value of the quality of service calculated with the estimation model based on the training data corresponds to the true value shown by the correct answer label”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of the entities as taught by Lee in the Poornachandran-Shpilyuck-Denneman system as data collection and model application being split between two devices helps balance performance, efficiency, and practicality.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Yang et al US 2019/0335004.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ISHRAT RASHID whose telephone number is (571)272-5372. The examiner can normally be reached 10AM-6PM EST M-F.
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, Tonia L Dollinger can be reached at 571-272-4170. 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.
/I.R/Examiner, Art Unit 2459 /SCHQUITA D GOODWIN/Primary Examiner, Art Unit 2459
Prosecution Insights