The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This communication is responsive to Amendment filed 05/26/2026.
Claims 1-26 have been examined.
Response to Amendment
In the instant amendment, claims 1, 3, 5-6, 11, 13, and 15-10 have been amended.
Allowable Subject Matter
Claims 3-5, 13-15 and 19-22 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 7, 9-11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over US 2017/0244593 to Rangasami et al. (hereafter “Rangasami”) and in further view of US 2019/0379578 to Mishra et al. (hereafter “Mishra”), US 2013/0227562 to Tsirkin et al. (hereafter “Tsirkin”), and US 2021/0240540 to Wang et al. (hereafter “Wang”)
As per claim 1, Rangasami discloses a method for implementing a microservice architecture for a management application (FIGs. 1-2; paragraphs 0036-0037: “The various microservices expose interfaces that enable the microservices to invoke one another to exchange data and perform the respective sets of functions in order to create one or more overall applications. Each of the microservices may adhere to a well-defined Application Programming Interface (API) and may be orchestrated by invoking the API of the microservice.”), the method comprising:
deploying a first service of the management application on a first container running on a container host (FIG. 1; paragraphs 0036-0037: “each cloud service 124 may host or include a plurality of containers 126, 129 that each provides an execution environment for at least one application (e.g., microservice) deployed by enterprise 116.” [Wingdings font/0xE0] cloud service provider as container host as claimed);
employing a service-to-service communication mechanism to control communication between the first service and a second service of the management application (FIGs. 1, 3 and 5; paragraphs 0032, 0036-0037 and 0078: “Applications executing on containers 125 may communicate with applications executing on containers 126, 129 via virtual circuits 127A, 127B (“virtual circuits 127”) provisioned for cloud exchange 102 to interconnect enterprise 116 with cloud services 124. DR manager 140 of cloud exchange 102 may provision virtual circuits 127 in networking platform 108 of cloud exchange 102, to transport data packets between containers 126 of the first cloud service 124A and containers 129 of the second cloud service 124B. DR manager 140 of cloud exchange 102 may communicate code and state from the containers 126 of the first cloud service 124A to the containers 129 of the DR infrastructure layers 144 of the second cloud service 124B via virtual circuits 127.”);
employing a proxy to control communication between the first service and an external application in an external device (FIGs. 1, 3 and 5; paragraphs 0059-0061: “As another example, routers 110 of networking platform 108 may be configured to redirect application traffic from container 126A at first cloud service 124A to container 129A at second cloud service 124B. For instance, router 110A may be configured to send application traffic addressed to subnet 128A via DR virtual circuit 127B to subnet 128B of cloud service 124B.”); and
enabling a container orchestrator (FIG. 1; paragraphs 0032, 0039 and 0043-0044: Cloud exchange 102 (container orchestrator as claimed) including interconnection platform 103, API 105, Orchestration Engine 106 and virtual network circuit) to monitor and manage the first service (FIGs. 1, and 5-6; paragraphs 0058, 0061-0064, 0100, 0102 and 0110) through the service-to-service communication mechanism (FIGs. 1, 3 and 5; paragraphs 0032, 0036-0037 and 0078: “Applications executing on containers 125 may communicate with applications executing on containers 126, 129 via virtual circuits 127A, 127B (“virtual circuits 127”) provisioned for cloud exchange 102 to interconnect enterprise 116 with cloud services 124. DR manager 140 of cloud exchange 102 may provision virtual circuits 127 in networking platform 108 of cloud exchange 102, to transport data packets between containers 126 of the first cloud service 124A and containers 129 of the second cloud service 124B. DR manager 140 of cloud exchange 102 may communicate code and state from the containers 126 of the first cloud service 124A to the containers 129 of the DR infrastructure layers 144 of the second cloud service 124B via virtual circuits 127.” [Wingdings font/0xE0] cloud exchanger 102 using virtual circuits for service-to-service communication), and the inter-process communication mechanism (paragraphs 0039-0040 and 0044: cloud exchanger 102 using interconnection platform including API 105).
Rangasami does not explicitly disclose employing an inter-process communication mechanism to control communication between the first service and the container host using named pipes that are mounted from the container host to the first container; and enabling a container orchestrator to monitor and manage the first service through the proxy.
Mishra further discloses employing an inter-process communication mechanism to control communication between the first service and the container host using named pipes (FIG. 7; paragraphs 0081-0082: in view of the instant specification, the named pipe is a queue [Wingdings font/0xE0] Mishra FIG. 7 paragraphs 0081-0082 teaches “FIG. 7 also illustrates a set of message queues 773 for communicating between the service VM and the service containers.”) [Wingdings font/0xE0] container service (as service) and service VM as a container host)
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Mishra into Rangasami’s teaching because it would provide for the purpose of allocates memory to a service DCN that operates a set of containers for providing partner network services for data messages received by the service DCN. The service DCN and the containers share the allocated memory and the method stores data messages received by the service DCN in the allocated memory (Mishra, paragraph 0005).
Tsirkin further discloses named pipes that are mounted from the container host to the first container (FIG. 1; paragraphs 0016-0018: “During operation, each guest 140 interacts with the host OS 120 via a virtual machine 130 and communicates requests to the hypervisor 125 via the queues 140.” [Wingdings font/0xE0] VM 130 having a plural of VCPU 1-n connected with host OS 120 using queues 140 including queues 1-n)
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Tsirkin into Rangasami’s teaching and Mishra’s teaching because it would provide for the purpose of each one of the VCPUs can submit request to any one of the queues, depending on the load executing on the respective VCPU (Tsirkin, paragraph 0016).
Wang further discloses enabling a container orchestrator to monitor and manage the first service through the proxy (paragraph 0021: “a service mesh layer can be added to a container orchestration platform to connect, manage, and secure networks of different microservices. An example of a service mesh is Istio. The service mesh may be open source. The service mesh can configure, monitor, and manage interactions between containers comprising a cluster. The service mesh allows a developer to set a single policy that configures connections between containers without having to configure each connection individually. The service mesh works natively with a container orchestration engine by adding an envoy—a per-microservice “sidecar” proxy container that handles ingress/egress traffic between microservices in a cluster and from a microservice to external services.”).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Wang into Rangasami’s teaching, Mishra’s teaching, and Tsirkin’s teaching because it would provide for the purpose of a service mesh layer can be added to a container orchestration platform to connect, manage, and secure networks of different microservices (Wang, paragraph 0021).
As per claim 7, Rangasami discloses configuring a common data model (CDM) that is shared between the first container and a second container that runs a second service of the management application (FIG. 3; paragraphs 0083, and 0087-0089), wherein the CDM comprises configuration data of the first service and second service (FIG. 3; paragraphs 0083, and 0087-0089).
Rangasami does not explicitly disclose wherein the CDM comprises database.
Mishra further discloses wherein the CDM comprises database (FIG. 3; paragraph 0034, 0066, and 0072-0075).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Mishra into Rangasami’s teaching because it would provide for the purpose of allocates memory to a service DCN that operates a set of containers for providing partner network services for data messages received by the service DCN. The service DCN and the containers share the allocated memory and the method stores data messages received by the service DCN in the allocated memory (Mishra, paragraph 0005).
As per claim 9, Rangasami does not explicitly disclose wherein the container host comprises a physical server or a virtual machine running on the physical server.
Mishra further discloses wherein the container host comprises a physical server or a virtual machine running on the physical server (FIG. 5; paragraph 0025-0027).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Mishra into Rangasami’s teaching because it would provide for the purpose of allocates memory to a service DCN that operates a set of containers for providing partner network services for data messages received by the service DCN. The service DCN and the containers share the allocated memory and the method stores data messages received by the service DCN in the allocated memory (Mishra, paragraph 0005).
As per claim 10, Rangasami discloses wherein the first container and a second container that runs the second service are deployed in a server management appliance, an on-premises physical server, a cloud server, or any combination thereof (FIG. 1; paragraphs 0035-0037).
As per claim 11, it is medium claim, which recite(s) the same limitations as those of claim 1. Accordingly, claim 11 is rejected for the same reasons as set forth in the rejection of claim 1.
As per claim 17, it is medium claim, which recite(s) the same limitations as those of claim 7. Accordingly, claim 17 is rejected for the same reasons as set forth in the rejection of claim 7.
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Rangasami and in further view of Mishra, Tsirkin and Wang, as applied to claims 1 and 11, and further in view of US 2021/0141645 to Kramer et al. (hereafter “Kramer”) and US 2011/0126275 to Anderson et al. (hereafter “Anderson”)
As per claim 2, Rangasami does not explicitly disclose wherein deploying the first service on the first container comprises:
obtaining information about the first service of the management application, wherein the obtained information comprises dependency data of the first service;
based on the obtained information about the first service, generating a container file including instructions for building the first container that executes the first service;
based on the container file, creating a container image for the first service; and
based on the container image, deploying the first container for execution on the container host.
Kramer further discloses wherein deploying the first service on the first container comprises:
obtaining information about the first service of the management application, wherein the obtained information comprises dependency data of the first service (paragraphs 0025, and 0027-0029: dependency info from manifest of dependencies);
based on the obtained information about the first service, generating a container file including instructions for building the first container that executes the first service (paragraphs 0025, and 0027-0029: building an application backages based dependency info from manifest of dependencies).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Kramer into Rangasami’s teaching, Mishra’s teaching, Tsirkin’s teaching and Wang’s teaching because it would provide for the purpose of Enhancing the bootstrap execution environment based on the manifest of dependencies may include installing application dependencies (Kramer, paragraph 0005).
Anderson further discloses based on the container file, creating a container image for the first service (paragraphs 0073 and 0079: building an image of VM 114b from the container); and
based on the container image (paragraphs 0073 and 0079), deploying the first container for execution on the container host (paragraph 0073 and 0079).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Anderson into Rangasami’s teaching, Mishra’s teaching, Tsirkin’s teaching, Wang’s teaching Kramer’s teaching because it would provide for the purpose of manage development and deployment for services and applications provisioned in the infrastructure (Anderson, paragraph 0072).
As per claim 12, it is medium claim, which recite(s) the same limitations as those of claim 2. Accordingly, claim 12 is rejected for the same reasons as set forth in the rejection of claim 2.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Rangasami and in further view of Mishra, Tsirkin and Wang, as applied to claims 1 and 11, and further in view of US 2015/0317088 to Hussain et al. (hereafter “Hussain”)
As per claim 6, Rangasami does not explicitly disclose wherein employing the inter-process communication mechanism to control communication between the first service and the container host using the named pipes amounted from the container host to the first container comprises:
transmitting a command that need to be executed on the container host from the first container to the container host through a first named pipe; and
transmitting a result associated with an execution of the command from the container host to the first container through a second named pipe.
Tsirkin discloses the named pipes amounted from the container host to the first container (FIG. 1; paragraphs 0016-0018: “During operation, each guest 140 interacts with the host OS 120 via a virtual machine 130 and communicates requests to the hypervisor 125 via the queues 140.” [Wingdings font/0xE0] VM 130 having a plural of VCPU 1-n connected with host OS 120 using queues 140 including queues 1-n)
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Tsirkin into Rangasami’s teaching and Mishra’s teaching because it would provide for the purpose of each one of the VCPUs can submit request to any one of the queues, depending on the load executing on the respective VCPU (Tsirkin, paragraph 0016).
Hussain further discloses wherein employing the inter-process communication mechanism to control communication between the first service and the container host (FIGs. 1-3; paragraph 0025: VM 110 with driver/application in block 100 (container host/system/environment)) comprises:
transmitting a command that need to be executed on the container host from the first container to the container host through a first named pipe (FIGs. 1-3; paragraph 0025: in view of the instant specification, the named pipe is a queue); and
transmitting a result associated with an execution of the command from the container host to the first container through a second named pipe (FIGs. 1-3; paragraph 0025: in view of the instant specification, the named pipe is a queue).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Hussain into Rangasami’s teaching, Mishra’s teaching, Tsirkin’s teaching, and Wang’s teaching because it would provide for the purpose of each of the VMs running on the host has its own namespace(s) and can access its storage devices directly through its own virtual NVMe controller (Hussain, paragraph 0011).
As per claim 16, it is medium claim, which recite(s) the same limitations as those of claim 6. Accordingly, claim 16 is rejected for the same reasons as set forth in the rejection of claim 6.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Rangasami and in further view of Mishra, Tsirkin, and Wang, as applied to claim 1, and further in view of US 2021/0406386 to Ortiz et al. (hereafter “Ortiz”)
As per claim 8, Rangasami discloses when the first service and the second service are running on different server platforms (FIG. 1).
Rangasami does not explicitly disclose generating an encrypted overlay network that spans the different server platforms to enable communication between the first service and the second service.
Ortiz further discloses generating an encrypted overlay network that spans the different server platforms to enable communication between the first service and the second service (paragraph 0014).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Ortiz into Rangasami’s teaching, Mishra’s teaching, Tsirkin’s teaching and Wang’s teaching because it would provide for the purpose of A trusted, neutral, cross-party platform spanning across multiple services and interaction points is desirable to provide a scalable, un-biased solution providing transparent levels of control to stakeholders (Ortiz, paragraph 0014).
Claims 18 and 24-26 are rejected under 35 U.S.C. 103 as being unpatentable over Rangasami in further view of Mishra, Tsirkin, Wang, US 2020/0233692 to Kandula and US 2018/0268115 to Zhang et al. (hereafter “Zhang”)
As per claim 18, Rangasami discloses A computer system for implementing a microservice architecture for a management application (FIGs. 1-2; paragraphs 0036-0037: “(FIGs. 1-2; paragraphs 0036-0037: “The various microservices expose interfaces that enable the microservices to invoke one another to exchange data and perform the respective sets of functions in order to create one or more overall applications. Each of the microservices may adhere to a well-defined Application Programming Interface (API) and may be orchestrated by invoking the API of the microservice.”), comprising:
a container platform to execute containerized services of a management application (FIG. 1; paragraphs 0036-0037: “each cloud service 124 may host or include a plurality of containers 126, 129 that each provides an execution environment for at least one application (e.g., microservice) deployed by enterprise 116.”), wherein the container platform comprises a plurality of containers, each container executing a containerized service (FIG. 1; paragraphs 0036-0037: “each cloud service 124 may host or include a plurality of containers 126, 129 that each provides an execution environment for at least one application (e.g., microservice) deployed by enterprise 116.” [Wingdings font/0xE0] cloud service provider as container host as claimed);
a service discovery module to control communication between the containerized services within the container platform using an application programming interface (API)-based communication ((FIGs. 1-2; paragraphs 0036-0037: “The various microservices expose interfaces that enable the microservices to invoke one another to exchange data and perform the respective sets of functions in order to create one or more overall applications. Each of the microservices may adhere to a well-defined Application Programming Interface (API) and may be orchestrated by invoking the API of the microservice.”)”);
a proxy running on the container platform to control communication between the containerized services and an external device (FIGs. 1, 3 and 5; paragraphs 0059-0061: “As another example, routers 110 of networking platform 108 may be configured to redirect application traffic from container 126A at first cloud service 124A to container 129A at second cloud service 124B. For instance, router 110A may be configured to send application traffic addressed to subnet 128A via DR virtual circuit 127B to subnet 128B of cloud service 124B.”); and
a container orchestrator to monitor and manage the containerized services (FIGs. 1, and 5-6; paragraphs 0058, 0061-0064, 0100, 0102 and 0110).
Rangasami does not explicitly disclose a daemon running on the container platform to orchestrate communication between the containerized services and the container platform using named pipes that are mounted from the container platform to the plurality of containers executing the respective containerized services; and a container orchestrator to monitor and manage the containerized services through the service discovery module, the daemon, and the proxy.
Mishra further discloses a daemon (FIGs. 7-8: Photon OS and service VM) running on the container platform to orchestrate communication between the containerized services and the container platform using named pipes (FIG. 7-8; paragraphs 0081-0083: in view of the instant specification, the named pipe is a queue [Wingdings font/0xE0] Mishra FIG. 7 paragraphs 0081-0082 teaches “FIG. 7 also illustrates a set of message queues 773 for communicating between the service VM and the service containers.”) [Wingdings font/0xE0] container service (as service) and service VM as a container host)
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Mishra into Rangasami’s teaching because it would provide for the purpose of allocates memory to a service DCN that operates a set of containers for providing partner network services for data messages received by the service DCN. The service DCN and the containers share the allocated memory and the method stores data messages received by the service DCN in the allocated memory (Mishra, paragraph 0005).
Tsirkin further discloses named pipes that are mounted from the container platform to the plurality of containers executing the respective containerized services (FIG. 1; paragraphs 0016-0018: “During operation, each guest 140 interacts with the host OS 120 via a virtual machine 130 and communicates requests to the hypervisor 125 via the queues 140.” [Wingdings font/0xE0] VM 130 having a plural of VCPU 1-n connected with host OS 120 using queues 140 including queues 1-n)
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Tsirkin into Rangasami’s teaching and Mishra’s teaching because it would provide for the purpose of each one of the VCPUs can submit request to any one of the queues, depending on the load executing on the respective VCPU (Tsirkin, paragraph 0016).
Wang further discloses a container orchestrator to monitor and manage the containerized services through the proxy (paragraph 0021: “a service mesh layer can be added to a container orchestration platform to connect, manage, and secure networks of different microservices. An example of a service mesh is Istio. The service mesh may be open source. The service mesh can configure, monitor, and manage interactions between containers comprising a cluster. The service mesh allows a developer to set a single policy that configures connections between containers without having to configure each connection individually. The service mesh works natively with a container orchestration engine by adding an envoy—a per-microservice “sidecar” proxy container that handles ingress/egress traffic between microservices in a cluster and from a microservice to external services.”).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Wang into Rangasami’s teaching, Mishra’s teaching, and Tsirkin’s teaching because it would provide for the purpose of a service mesh layer can be added to a container orchestration platform to connect, manage, and secure networks of different microservices (Wang, paragraph 0021).
Kandula further discloses a container orchestrator to monitor and manage the containerized services through the service discovery module (paragraph 0039: “The application metric metadata service 316 stores application signature information and metrics that need to be collected for each application running in the VMs, which are used by the service discovery modules of the monitoring agents in the VMs to identify applications running in their respective VMs.”)
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Kandula into Rangasami’s teaching, Mishra’s teaching, Tsirkin’s teaching, and Wang’s teaching because it would provide for the purpose of managing a monitoring agent in an operating system of a virtual computing instance uses a monitoring agent lifecycle service of the monitoring agent that is started as part of a startup process of the operating system of the virtual computing instance (Kandula, paragraph 0004).
Zang further discloses a container orchestrator to monitor and manage the containerized services through the daemon (paragraphs 0021 and 0025)
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Zang into Rangasami’s teaching, Mishra’s teaching, Tsirkin’s teaching, Wang’s teaching and Kandula’s teaching because it would provide for the purpose of managing a monitoring agent in an operating system of a virtual computing instance uses a monitoring agent lifecycle service of the monitoring agent that is started as part of a startup process of the operating system of the virtual computing instance (Kandula, paragraph 0004).
As per claim 24, Rangasami discloses configuring a common data model (CDM) that is shared between the first container and a second container that runs a second service of the management application (FIG. 3; paragraphs 0083, and 0087-0089), wherein the CDM comprises configuration data of the first service and second service (FIG. 3; paragraphs 0083, and 0087-0089).
Rangasami does not explicitly disclose wherein the CDM comprises database.
Mishra further discloses wherein the CDM comprises database (FIG. 3; paragraph 0034, 0066, and 0072-0075).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Mishra into Rangasami’s teaching because it would provide for the purpose of allocates memory to a service DCN that operates a set of containers for providing partner network services for data messages received by the service DCN. The service DCN and the containers share the allocated memory and the method stores data messages received by the service DCN in the allocated memory (Mishra, paragraph 0005).
As per claim 25, Rangasami does not explicitly disclose wherein the container host comprises a physical server or a virtual machine running on the physical server.
Mishra further discloses wherein the container host comprises a physical server or a virtual machine running on the physical server (FIG. 5; paragraph 0025-0027).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Mishra into Rangasami’s teaching because it would provide for the purpose of allocates memory to a service DCN that operates a set of containers for providing partner network services for data messages received by the service DCN. The service DCN and the containers share the allocated memory and the method stores data messages received by the service DCN in the allocated memory (Mishra, paragraph 0005).
As per claim 26, Rangasami discloses wherein the first container and a second container that runs the second service are deployed in a server management appliance, an on-premises physical server, a cloud server, or any combination thereof (FIG. 1; paragraphs 0035-0037).
Claims 23 are rejected under 35 U.S.C. 103 as being unpatentable over Rangasami in further view of Mishra, Tsirkin, Wang, Kandula and Zhang, as applied to claim 18, and further in view of Ortiz.
As per claim 23, Rangasami discloses the containerized services (FIG. 1) and when the containerized services are running on different server platforms (FIG. 1).
Rangasami does not explicitly disclose an encrypted overlay network that spans the different server platforms to enable communication between the containerized services.
Ortiz further discloses an encrypted overlay network that spans the different server platforms to enable communication between the containerized services (paragraph 0014).
It would have been obvious to a person having ordinary skill in the art before the effective filling date of the claimed invention to combine a teaching of Ortiz into Rangasami’s teaching, Mishra’s teaching, Tsirkin’s teaching, Wang’s teaching, Kandula’s teaching and Zhang’s teaching because it would provide for the purpose of A trusted, neutral, cross-party platform spanning across multiple services and interaction points is desirable to provide a scalable, un-biased solution providing transparent levels of control to stakeholders (Ortiz, paragraph 0014).
Response to Arguments
Applicants’ arguments have been considered but are moot in view of the new ground(s) of rejection. Applicants’ amendment necessitated the new ground(s) of rejection presented in this Office action.
Conclusion
Applicants’ amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication should be directed to examiner Tuan Dao, whose telephone/fax numbers are (571) 270 3387 and (571) 270 4387, respectively. The examiner can normally be reached on every Monday-Thursday and the second Friday of the bi-week from 7:30AM to 5:00PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Pierre Vital, can be reached at telephone number (571) 272 4215.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273 8300.
Any inquiry of a general nature of relating to the status of this application or proceeding should be directed to the TC 2100 Group receptionist whose telephone number is (571) 272 2100.
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.
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TUAN C DAO/Primary Examiner, Art Unit 2198
Prosecution Insights