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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/29/2024 and 10/23/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-9 and 11-20 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Caldato et al. (US20190102280A1).
Regarding Claim 1, Caldato teaches a method for debugging microservices in a containerized service-based application, the method comprising:
obtaining a request from a debugging system, the request indicating that a communication pipeline to the debugging system is to be established ([0008] "a method of providing runtime debugging for containerized services in container environments may include receiving a request for a service at a container environment … The method may also include determining that the request should be routed to a debug instance of the service … The method may additionally include routing, by the service mesh, the request to the debug instance." [0009-0011] discuss various embodiments centered around routing to debug instance. [0127-0128] “FIG. 25 illustrates a block diagram of a system for instantiating a debug instance of a service 2502, according to some embodiments. The cloud computing platform 202 can receive normal requests from regular clients 2204, 2206. These normal requests can be routed through the load balancer 2208 and the service mesh 2210 to a particular service. That service may have multiple instances 2214, 2216, 2218, and a load balancer 2212 for that service can route requests such that the load at each service instance is balanced. In addition to receiving normal requests from the regular clients 2204, 2206, some embodiments may also receive debug request 2506 from a debug client 2504. The debug client 2504 may be identical to the regular clients 2204, 2206, and thus may comprise a desktop computer, laptop computer, workstation, server, mobile computing device, smart phone, PDA, tablet computer, laptop computer, smart watch, and so forth. However, the debug client 2504 may be specifically identified as a client device that provides debug messages to the cloud computing platform 202. A debug request 2506 may be identical to normal requests sent from the regular clients 2204, 2206. However the debug request 2506 may be specifically provided by the debug client 2504 to go to a debugging instance of the service rather than the normal instances of the service 2214, 2216, 2218”).
initiating performance of a containerized service-based process based on the request ([0008] "instantiating the debug instance of the service" and [0129] “When the service mesh 2210 receives the debug request 2506, it can determine whether or not a debugging instance of the service is currently operating in the container platform 210. If there is no debug instance of the service currently operating on the container platform 210, the service mesh 2210 can send a message to the API registry 404 to generate alternatively, the service mesh 2210 can initiate a message to a scheduler for the cloud computing platform 202 to generate a debugging instance of the service in embodiments that do not use the API registry 404”).
while the containerized service-based process is performed:
identifying, by a listener configured to monitor traffic being directed to a microservice of the microservices, that a portion of the traffic was initiated based on the request from the debugging system ([0011] "Determining that the request should be routed to the debug instance of the service may include identifying a source of the request. Determining that the request should be routed to the debug instance of the service may include recognizing a header in the request that designates the request as a debug request. The request may be forwarded to the debug instance of the service without interrupting the routing of other requests to the service" Also, Fig. 25 and [0127-0128])
redirecting the portion of the traffic from the microservice to a replicated instance of the microservice that is hosted by the debugging system to obtain the communication pipeline between the microservice and the debugging system (([0118] "a debug client can send specific debug requests that are routed through a load balancer and directed by a service mesh to a debug instance of the service. This allows requests from other clients to pass through the same load balancer and service mesh while continuing to be routed directly to normal instances of the service" and [0124] "The operation of the service itself may be considered a clone of the other normal instances of the service 2214, 2216, 2218 from FIG. 22").
performing a debugging process using the communication pipeline and the replicated instance of the microservice to identify and correct an undesired operation of the microservice ([0124-0126] "In addition to the container 2302, the pod 2300 may include a specific debug build of the service itself. For example, one or more of the services 320, 322, 324, 326 may be built or compiled using a debug configuration such that the source code of the services 320, 322, 324, 326 includes interfaces for a debugger process 2310 to operate with the debug build of the service. One or more of the services 320, 322, 324, 326 would thus be able to provide variable values and pause execution based on interactions with the debugger 2310. The operation of the service itself may be considered a clone of the other normal instances of the service 2214, 2216, 2218 from FIG. 22. Thus, the debug build of the service illustrated in the pod 2300 of FIG. 23 can be used to reliably debug the normal instances of the service 2214, 2216, 2218 from FIG. 22. … Additionally, the debug daemon 2304, debug login 2308, debugger 2310, and/or additional debug utilities 2306 may also be included in the container 314 in any combination and without limitation. It will be understood that none of these debug utilities is required for a specific embodiment, and therefore some embodiments may omit any of the debug utilities described above. … The debug instance of the service may receive regular and/or specialized request traffic in a manner similar to that of the normal service instances 2214, 2216, 2218. This allows real transactions to be debugged in a production environment in real-time without interrupting the regular operation of the normal service instances 2214, 2216, 2218").
providing computer implemented services using the corrected microservice ([0117] " using real-time, live data that may be optimal for re-creating errors and determining whether fixes/patches for these errors work properly without interfering with the expected operation of the service").
Regarding claim 2, Caldato teaches the method of claim 1. Caldato further teaches wherein the containerized service-based application is hosted by a deployment, and the debugging system is used by an entity tasked with managing operation of the containerized service-based application by providing debugging services for the microservices (Please refer to Fig. 25 below for a representation containerized services as well as the debug instance being managed by the service mesh as described by the following disclosures. [0056] “In a another example, the service 114 can be deployed to a container platform 210. The container platform differs from the virtual machines 208 in a number of important ways. First, the container platform 210 packages individual services into containers as described in greater detail below in FIG. 3. Each container shares a host operating system kernel, and they also share binaries, libraries, and other read-only components. This allows containers to be exceptionally light—often only a few megabytes in size. Additionally, a lightweight container is very efficient, taking just seconds to start versus the minutes required to boot up a virtual machine. Containers also reduce management overhead by sharing the operating system and other libraries that can be maintained together for the entire set of containers in the container platform 210” and [0118] “The embodiments described herein make changes to the cloud computing platform 202 such that a debug build of the service can be deployed with a debugger in the production/deployment environment 104 to receive real-time, live data from actual request traffic. In some embodiments, a debug client can send specific debug requests that are routed through a load balancer and directed by a service mesh to a debug instance of the service. This allows requests from other clients to pass through the same load balancer and service mesh while continuing to be routed directly to normal instances of the service. In some embodiments, the service mesh can receive requests from any client and clone the requests to be sent to the debug instance of the service. These embodiments allow a debug instance of the service to operate in the cloud computing platform 202 of the production/deployment environment 104 alongside the normal instances of the service. These embodiments also solve the technical problems described above by routing real-time, live requests to the debug instance of the service without interrupting the normal operations of other service instances”).
PNG
media_image1.png
645
878
media_image1.png
Greyscale
Regarding claim 3, Caldato teaches the method of claim 2. Caldato further teaches wherein the debugging system and the deployment are distinguishable hardware devices, and the debugging system and the deployment are operably connected to each other (Each of the constituents are run in separate pods and nodes, see Fig. 25, and [0060] “A number of different pods can be deployed to a container node 302. Generally, pods run within nodes. A node represents a worker machine (either virtual or physical) in the container platform. Each node is managed by a “master” that automatically handles scheduling pods within each of the nodes. Each node can run a process that is responsible for communication between the master and the node and for managing the pods in containers on the machine represented by the node”).
Regarding claim 4, Caldato teaches the method of claim 1. Caldato further teaches wherein the communication pipeline is a logical entity adapted to:
identify data that is relevant to the request and directed to the microservice, and redirect the identified data from the microservice to the debugging system ([0118] "a debug client can send specific debug requests that are routed through a load balancer and directed by a service mesh to a debug instance of the service. This allows requests from other clients to pass through the same load balancer and service mesh while continuing to be routed directly to normal instances of the service." [0132-0133] “the API registry 404 may provide the endpoint to the service mesh 2210. The service mesh 2210 can then use the endpoint to route the debug message 2506 to the debug instance of the service 2502. This endpoint does not need to be published because only the service mesh 2210 needs to send any messages to the debug instance. However, some embodiments may make this endpoint available to other services that access the debug information during runtime. FIG. 26 illustrates a block diagram of the container platform 210 routing debug requests to the debug instance of the service 2502, according to some embodiments. When the debug request 2506 is received by the service mesh 2210, the service mesh 2210 can identify the debug request 2506. The debug request 2506 may be distinguished from normal requests from the regular clients 2204, 2206 in a number of different ways. For example, the service mesh 2210 can identify the debug request 2506 by virtue of a sender, namely the debug client 2504. When the service mesh 2210 recognizes an address of the debug client 2504, the service mesh 2210 can designate the request as a debug request 2506. This allows the service mesh 2210 to identify debug requests by virtue of their source”).
Regarding claim 5, Caldato teaches the method of claim 1. Caldato further teaches wherein initiating performance of the containerized service-based process comprises:
sending a communication to at least one microservice of the microservices of the containerized service-based application ([0127] "FIG. 25 illustrates a block diagram of a system for instantiating a debug instance of a service 2502, according to some embodiments" and [0129] "When the service mesh 2210 receives the debug request 2506, it can determine whether or not a debugging instance of the service is currently operating in the container platform 210. If there is no debug instance of the service currently operating on the container platform 210, the service mesh 2210 can send a message to the API registry 404 to generate alternatively, the service mesh 2210 can initiate a message to a scheduler for the cloud computing platform 202 to generate a debugging instance of the service in embodiments that do not use the API registry 404").
Regarding claim 6, Caldato teaches the method of claim 5. Caldato further teaches wherein the communication comprises:
communication information for the debugging system ([00134] “the debug request 2506 may include a payload within the request that includes a predetermined value that is only used by debug requests”)
a unique identifier for the request from the debugging system ([0133-0134] "When the debug request 2506 is received by the service mesh 2210, the service mesh 2210 can identify the debug request 2506. The debug request 2506 may be distinguished from normal requests from the regular clients 2204, 2206 in a number of different ways. For example, the service mesh 2210 can identify the debug request 2506 by virtue of a sender, namely the debug client 2504. When the service mesh 2210 recognizes an address of the debug client 2504, the service mesh 2210 can designate the request as a debug request 2506. This allows the service mesh 2210 to identify debug requests by virtue of their source. In some embodiments, the service mesh 2210 can identify the debug request 2506 using any information embedded within the debug request 2506. For example, the debug request 2506 may have unique header information or one or more flag settings within the debug request 2506 that identify it as a debug request").
Regarding claim 7, Caldato teaches the method of claim 6. Caldato further teaches wherein identifying that the portion of the traffic was initiated based on the request from the debugging system comprises:
obtaining information regarding content of the traffic, the information being usable to identify whether the unique identifier is present in the content of the traffic ([0133] “When the debug request 2506 is received by the service mesh 2210, the service mesh 2210 can identify the debug request 2506. The debug request 2506 may be distinguished from normal requests from the regular clients 2204, 2206 in a number of different ways. For example, the service mesh 2210 can identify the debug request 2506 by virtue of a sender, namely the debug client 2504. When the service mesh 2210 recognizes an address of the debug client 2504, the service mesh 2210 can designate the request as a debug request 2506. This allows the service mesh 2210 to identify debug requests by virtue of their source”).
making a determination regarding whether the content comprises any instances of the unique identifier ([0133-0134] "The debug request 2506 may be distinguished from normal requests from the regular clients 2204, 2206 in a number of different ways. For example, the service mesh 2210 can identify the debug request 2506 by virtue of a sender, namely the debug client 2504. When the service mesh 2210 recognizes an address of the debug client 2504, the service mesh 2210 can designate the request as a debug request 2506. This allows the service mesh 2210 to identify debug requests by virtue of their source. In some embodiments, the service mesh 2210 can identify the debug request 2506 using any information embedded within the debug request 2506. For example, the debug request 2506 may have unique header information or one or more flag settings within the debug request 2506 that identify it as a debug request. In another example, the debug request 2506 may include a payload within the request that includes a predetermined value that is only used by debug requests").
Regarding claim 8, Caldato teaches the method of claim 1. Caldato further teaches wherein the traffic comprises messages sent between the microservices to support operation of the containerized service-based application ([0008] "The container environment may include a service mesh and a plurality of services encapsulated in a plurality of containers." EN: Wikipedia’s definition of a service mesh is: In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between services or microservices using a proxy. https://en.wikipedia.org/wiki/Service_mesh ).
Regarding claim 9, Caldato teaches the method of claim 1. Caldato further teaches wherein redirecting the portion of the traffic comprises:
forwarding the portion of the traffic to an interceptor service ([0133-0134] "When the debug request 2506 is received by the service mesh 2210").
forwarding, by the interceptor service, the portion of traffic to the replicated instance of the microservice hosted by debugging system ([0118] “The embodiments described herein make changes to the cloud computing platform 202 such that a debug build of the service can be deployed with a debugger in the production/deployment environment 104 to receive real-time, live data from actual request traffic. In some embodiments, a debug client can send specific debug requests that are routed through a load balancer and directed by a service mesh to a debug instance of the service. This allows requests from other clients to pass through the same load balancer and service mesh while continuing to be routed directly to normal instances of the service. In some embodiments, the service mesh can receive requests from any client and clone the requests to be sent to the debug instance of the service. These embodiments allow a debug instance of the service to operate in the cloud computing platform 202 of the production/deployment environment 104 alongside the normal instances of the service. These embodiments also solve the technical problems described above by routing real-time, live requests to the debug instance of the service without interrupting the normal operations of other service instances” and [0135] "the service mesh 2210 can then route the debug request 2506 to the debug instance of the service 2502. When future debug requests are received from the debug client 2504 or other clients designated as debug clients, the service mesh 2210 can also route these requests to the debug instance of the service 2502").
Regarding claim 11, Caldato teaches the method of claim 1. Caldato further teaches wherein the undesired operation of the microservice is observed in past operation of the microservice, and the undesired operation is a basis for performing the debugging process ([0117] "Prior to this disclosure, a debug build of the service with the debugger 110 would be run in the IDE using dummy data or preconfigured inputs to try and simulate the real-world flow of request traffic that the service receives in the production/deployment environment 104. However, this prevents the service from using real-time, live data that may be optimal for re-creating errors and determining whether fixes/patches for these errors work properly without interfering with the expected operation of the service").
Regarding claim 12, Caldato teaches a non-transitory machine-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations for debugging microservices in a containerized service-based application, the operation comprising ([0009] “In some embodiments, a non-transitory, computer-readable medium may include instructions that, when executed by one or more processors, causes the one or more processors to perform operations including receiving a request for a service at a container environment”).
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Claims 13-16 are medium claims reciting limitations similar to claims 2-5 respectively and are rejected under the same rationale.
Regarding claim 17, Caldato teaches a data processing system, comprising:
a processor; and
a memory coupled to the processor to store instructions, which when executed by the processor, cause the processor to perform operations for debugging microservices in a containerized service-based application, the operations comprising: ([0010] “a system may include one or more processors and one or more memory devices comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including receiving a request for a service at a container environment”).
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Claims 18-20 are system claims reciting limitations similar to claims 2-4 respectively and are rejected under the same rationale.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Caldato et al. (US20190102280A1) in view of Pieczul et al. (US20220191248A1)
Regarding claim 10, Caldato teaches the method of claim 9. Caldato however does not teach wherein the replicated instance of the microservice is subject to reduced security standards when compared to the microservice hosted by the deployment, and the reduced security standards facilitates extraction of information regarding the service that is relevant for debugging purposes
Pieczul teaches wherein the replicated instance of the microservice is subject to reduced security standards when compared to the microservice hosted by the deployment, and the reduced security standards facilitates extraction of information regarding the service that is relevant for debugging purposes (Pieczul teaches two policies one more permissive than the other for testing before deployment. [0040] “the test subsystem 108 performs additional processing to check if the network path violates a pre-defined network security policy 117 (also referred to herein as a coarse-grained network security policy) defined for the test environment/application. The set of pre-defined network security polices 117 may be defined, for example, by the user of the enterprise and these policies reflect general network traffic expectations of the flow of network traffic between the components of the application in the test environment. Examples of coarse-grained polices defined for an application are described in FIG. 4. If it is determined that the coarse-grained network security policy is not violated by any network path identified for the component, the test system 108 generates a component-specific network security policy for the component.” Also, see [0074-0075] and [0058-0059] “A coarse-grained policy, based on “zone labels” as depicted in table 402 in FIG. 4 may allow the containerized application to operate/execute correctly with either version of the component and with both versions of the components running together. However, such a coarse-grained policy may not be considered sufficiently secure as it allows communication that is not part of regular system operation. At the same time, the user (e.g., a system administrator) would prefer that any policy would be contained in the boundaries defined by the coarse-grained policy. A fine-grained policy, for example, based on “app labels” as depicted in table 404, will result in a containerized application that initially allows traffic from the user-service component 208 to the database component 212 only. This policy will prevent the updated version of the user-service component 208 to communicate with the message-queue component 214 after the updated version is deployed”).
Caldato and Pieczul are analogous art because they are from the same field of endeavor in microservice testing and deployment. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Caldato and Pieczul to incorporate Pieczul’s configurable multi-level security policy to perform the debugging access required by Caldato’s debugging tools. “The techniques additionally include capabilities for enabling different network policies to be generated for the different versions of the component, where each component has potentially different network requirements.” (Pieczul [0033]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hossain et al. (US-20120131555-A1): discloses remote debugging proxying and session routing with various access levels.
Tongchen et al. (WO-202310372-A1): discloses routing a portion of traffic to support local side debugging of a microservice that’s part of a Kubernetes cloud based cluster of services.
Irtiza (Kubernetes Pod Security Policy): discloses setting restrictive vs permissible security policies to facilitate varying access levels.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Emerson Puente can be reached on 571-272-3652. 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.
/A.E.D./Examiner, Art Unit 2187
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199