DETAILED ACTION
1. This action is responsive to the communications filed on 02/17/2026.
2. Claims 1, 3, 7-11, 17-27, are pending in this application.
3. Claims 1, 3, 7, 9-11, 17, 19, 20, have been amended.
4. Claims 2, 4-6, 12-16, have been previously cancelled.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
5. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/17/2026 has been entered.
Response to Arguments
6. Applicant’s argument with respect to claims 1, 3, 7-11, 17-27 have been considered but are moot in view of the new ground(s) of rejection.
Although a new ground of rejection has been used to address additional limitations that have been added to the claims, a response is considered necessary for several of applicant's arguments since reference S et al. (US 2022/0224637), will continue to be used to meet several claimed limitations. In the remarks, applicant argued that:
a. Applicant does not agree the above passage is relevant to the claimed subject matter but, to advance prosecution, has further amended claim 1 to set forth, "configuring, by the mesh agent based on determining the service is a virtual machine service being provided by a virtual machine, a service proxy for execution by the NIC to proxy the service in a service mesh." As explained earlier in this response, S [0113] describes service discovery. S [0113] also describes updating the sidecar proxies with microservices that have been discovered. None of this is relevant to "determining the service is a virtual machine service being provided by a virtual machine." Therefore there is no appropriate combination of Lenrow and S that teaches "configuring ... a service proxy ... to proxy the service in a service mesh" in any way "based on determining the service is a virtual machine service being provided by a virtual machine," as set forth in claim 1 as amended (Applicant’s remarks, page 9).
In response: The examiner respectfully disagrees.
S disclosed that a microservice catalog is used to discover an available microservice on endpoints. These endpoints are considered pods, and pods are launched within VMs (Paragraphs 25, 45, 113). By consulting the microservice catalog and selecting an endpoint on which the target microservice runs, the mesh agent effectively determines that the service is a virtual machine hosted service (as the selected endpoint is a VM) and uses this determination to drive configuration.
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.
The factual inquiries 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.
7. Claims 1, 3, 7-11, 17-27 are rejected under 35 U.S.C. 103 as being unpatentable over Lenrow et al. (US 2023/0047880) in view of Robinson et al. (US 2004/0128670) and S et al. (US 2022/0224637).
Regarding claim 1, Lenrow disclosed:
A method comprising:
obtaining (Paragraph 14, receiving a request), by a mesh agent (Figure 3, SMG 104) executing on a network interface card (NIC) (Paragraph 26, NIC) of a computing device (Figure 3, Non-Sidecar system 102), a service discovery request (Paragraph 14, request) or service registry advertisement sent by a service provided by a virtual machine (Figure 3, VM 306A) executing on the computing device (Paragraph 14, service mesh gateway (SMG) receives a request to instantiate a proxy for a non-sidecar application. The request may come from a virtual machine instance, the instance including pods, with each pod including an application and corresponding proxy itself. Paragraph 22, non-sidecar system comprises a plurality of physical computing devices such as servers. Paragraph 26, Figure 3, SMG is implemented as part of a network interface card (NIC) in the non-sidecar system 102. Paragraph 33, the proxies (with the virtual machines) perform functions such as service discovery. Paragraph 58, the request for a proxy includes a VLAN identifier which identifies the VM, a proxy type, a control plane technology, a control plane identifier, a pod identifier, a port list, a list of service labels, and security parameters);
determining, by the mesh agent, that the service is provided by a virtual machine (Paragraph 25, the SMG connected to the service mesh controller, allowing the SMG to participate in messaging with the mesh controller. Paragraphs 30, 35, the mesh controller is coupled to the SMG and provides an external user interface with the SMG facilitating communications between the non-sidecar system and the mesh controller. Paragraph 64, advertising the VM by transmitting details of the VM and/or proxy to a service mesh controller); and
configuring (Paragraph 15, instantiate), by the mesh agent, a service proxy (Figure 3, proxy 302A) for execution by the NIC to proxy the service in a service mesh (Paragraph 15, in response to the instantiation request, the SMG can instantiate the proxy, wherein the proxy is configured to monitor data communications to and from the non-sidecar application. Paragraph 43, the proxies 302A-302N include capabilities to communicate with the service mesh. Paragraph 62, instantiating the proxy by creating a sidecar proxy in the SMG).
While Lenrow disclosed aspects of service discovery and service registry advertisements (Paragraphs 33, 42), Lenrow did not explicitly disclose determining, by the mesh agent based on the service discovery request or service registry advertisement, the service that sent the service discovery request or service registry advertisement is a virtual machine service being provided by a virtual machine.
However, in an analogous art, Robinson disclosed determining, by the mesh agent based on the service discovery request or service registry advertisement, the service that sent the service discovery request or service registry advertisement is a virtual machine service being provided by a virtual machine (Paragraph 14, a registry facilitates advertising, discovering, and providing/using services and resources. Paragraph 23, Figure 2, VMs offer services and the VM may also have services desired by itself or other VMs. The offered/desired services are identified as services 212-216. The services are registered with the UDDI protocol to a registry 204. Paragraph 24, the VMs advertise, discover, and provide and/or use services and resources).
One of ordinary skill in the art would have been motivated to combine the teachings of Lenrow with Robinson because the references involve utilizing virtual machine discovery, and as such, are within the same environment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the service discovery request of Robinson with the teachings of Lenrow in order to allow the usage of registries to benefit failure detection, failover, and load balancing (Robinson, Paragraph 24).
Lenrow and Robinson did not explicitly disclose configuring, by the mesh agent based on determining the service is a virtual machine service being provided by a virtual machine, a service proxy for execution by the NIC to proxy the service in a service mesh.
However, in an analogous art, S disclosed this limitation. Specifically, S disclosed a service discovery request (Paragraph 113, consumes) or a service registry advertisement sent by a service provided by a virtual machine executing on the computing device (Paragraph 113, proxy manager 816 consumes (i.e., requests) information from a service registry that includes a listing of available/running services/microservices from a microservice catalog. In order to consume this information, a request would be sent for the information. Figure 7 showing the microservice discovery circuitry as part of the compute node 500. Figure 5, the compute node 500 having a NIC 520);
determining, by the mesh agent based on the service discovery request or service registry advertisement, the service is provided by a virtual machine (Paragraph 113, performing microservice discovery, utilizing the microservice catalog to discover an available (i.e., provided by) microservice on another endpoint (i.e., virtual machine) (see Paragraph 25, stating that endpoints are pods. Paragraph 45, stating that pods are launched within VMs);
configuring, by the mesh agent based on determining the service is a virtual machine service being provided by a virtual machine, a service proxy for execution by the NIC to proxy the service in a service mesh (Paragraph 117, the microservice catalog management circuitry 708 modifies the service catalog with information about the discovered microservice by updating the catalog to list information regarding the microservices, which is then made accessible to a given sidecar proxy 802B).
One of ordinary skill in the art would have been motivated to combine the teachings of Lenrow and Robinson with S because the references involve utilizing sidecar proxies, and as such, are within the same environment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the configuring a service proxy of S with the teachings of Lenrow and Robinson in order to improve the efficiency of using a computing device by enabling the ability for proxies on mesh networks to facilitate direct communication and selection of microservices across multiple domain namespaces (S, Paragraph 186).
Regarding claims 11, 20, the claims are substantially similar to claim 1. Claim 11 recites a processor and memory (Lenrow, Paragraph 103, processors and memory). Claim 20 recites containers containing services and service proxies, the services and service proxies being associated with a control plane of a service mesh (Lenrow, Figure 2, containerized system that includes applications (i.e., services) and proxies. Paragraph 17, the SMG transmitting data over the control plane that is coupled to the proxy and mesh controller); and a server comprising: a virtual machine configured to provide a service (Lenrow, Figure 3, non-sidecar system including a server 304A, VM 306A and includes SMG 104). Therefore, the claims are rejected under the same rationale.
Regarding claims 3, the limitations of claims 1, have been addressed. Lenrow, Robinson, and S disclosed:
wherein determining the service is a virtual machine service being provided by the virtual machine includes looking up a service entry in a registry by the mesh agent (Lenrow, Paragraph 30, a mesh controller 208 coupled to the SMG 104. Paragraph 83, having a mesh controller query a service registry. Paragraph 84, the service registry acts as a clearinghouse storing a mapping of different network functions. Robinson, Paragraph 24, the VMs advertise, discover, and provide and/or use services and resources).
For motivation, please refer to claim 1.
Regarding claims 7, 17, the limitations of claims 1, 11, have been addressed. Lenrow, Robinson, and S disclosed:
further comprising provisioning, by a mesh provisioner at an edge services controller, the mesh agent executed by the NIC with a mesh controller address, certificates and tokens (Lenrow, Paragraph 76, the mesh controller performs end to end protocol specific orchestration with the SMG that is associated with the destination endpoint. Paragraph 85, the mesh controller instructs the SMG to instantiate a proxy and determines certificate parameters and OAuth token validation parameters).
Regarding claims 8, 18, the limitations of claims 1, 11, have been addressed. Lenrow, Robinson, and S disclosed:
wherein the service proxy is associated with multiple services provided by the virtual machine (Lenrow, Paragraph 14, virtual machines including a containerized environment with a plurality of pods. Paragraph 31, each pod can execute multiple applications).
Regarding claims 9, 19, the limitations of claims 1, 11, have been addressed. Lenrow, Robinson, and S disclosed:
further comprising connecting, by the service proxy, to a mesh control plane controller that authenticates the service proxy using configuration data received by the service proxy from the mesh agent of a mesh provisioner (Lenrow, Paragraph 33, the proxies perform functions such as authentication and authorization. Paragraph 53, the control plane data comprises service mesh control plane data transmitted over a control plane to a service mesh controller. The control plane can specify authentication policies. Paragraph 82, SMG transmits parameters to the mesh controller, the parameters include network policy parameters. The parameters include security protocol information, such as information for authorization and authentication).
Regarding claims 10, 26, the limitations of claims 1, 11, have been addressed. Lenrow, Robinson, and S disclosed:
further comprising connecting the service proxy, the service proxy executed at the NIC for the service provided by the virtual machine to another service proxy in the service mesh (Lenrow, Figure 6, showing the proxy 612A connected to proxy 616A of the sidecar capable system (i.e., another service proxy)).
Regarding claims 21, 24, the limitations of claims 1, 11, have been addressed. Lenrow, Robinson, and S disclosed:
wherein determining the service is a virtual machine service being provided by a virtual machine comprises comparing a network address of the virtual machine to one or more network addresses for respective containers in a list of container-registered services (Lenrow, Paragraph 31, each application comprises a containerized application. Paragraphs 82-83, the SMG transmits parameters of the connection to the mesh controller including network policy parameters. The parameters include network addresses such as IP or FQDN (i.e., network address) of the destination device, a data protocol, and any security protocols or information. The mesh controller queries a service registry (i.e., list) using the supplied network identifier provided by the SMG to retrieve details of the destination (i.e., comparing). Robinson, Paragraph 24, the VMs advertise, discover, and provide and/or use services and resources).
For motivation, please refer to claim 1.
Regarding claims 22, 25, the limitations of claims 1, 11, have been addressed. Lenrow, Robinson, and S disclosed:
wherein determining the service is a virtual machine service being provided by a virtual machine comprises: sending, by the mesh agent, a probe to a target service included in the service registry advertisement (Lenrow, Paragraph 27, the SMG has one or more ports connected to the non-sidecar system such that communications are sent/received between each VM hosting a service in the non-sidecar system. The SMG also includes ports that are connected to the side-car capable system. Robinson, Paragraph 24, the VMs advertise, discover, and provide and/or use services and resources); and
determining a response to the probe does not come from a container network (Lenrow, Paragraph 40, an orchestrator in the non-sidecar system handles the communication with the VMs. An orchestrator for the sidecar capable system handles the communications from the containerized cluster. Figure 4, step 404 showing that if proxying is needed (i.e., from the VMs) then to process the packets a certain way. If no proxying is needed (i.e., from the containers) the packets are processed differently).
For motivation, please refer to claim 1.
Regarding claims 23, 27, the limitations of claims 1, 11, have been addressed. Lenrow, Robinson, and S disclosed:
wherein obtaining the service discovery request or service registry advertisement includes sniffing the service discovery request or service registry advertisement (Lenrow, Paragraph 15, monitoring data communications to and from the non-sidecar application. Paragraph 29, the proxies are configured to monitor traffic at various network levels, such as between layers 2 and 7 of an OSI model network stack. S, Paragraph 113, proxy manager 816 consumes information from a service registry that includes a listing of available/running services/microservices (i.e., service registry advertisement) from a microservice catalog).
For motivation, please refer to claim 1.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Steven C. Nguyen whose telephone number is (571)270-5663. The examiner can normally be reached M-F 7AM - 3PM and alternatively, through e-mail at Steven.Nguyen2@USPTO.gov.
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, Christopher Parry can be reached at 571-272-8328. 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.
/S.C.N/Examiner, Art Unit 2451
/JOHN B WALSH/Primary Examiner, Art Unit 2451