DETAILED ACTION
The communication is in response to the application filed on 05/09/2024 in which claims 1-20 are pending in the application. Claims 1, 8, and 15 are independent form.
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 11/25/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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, 7, 8, 14, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Barton et al. (US 20180324279 A1), in view of Quiros (US 12003546 B1).
As per claim 1 Barton disclose
A method, comprising: [0002] “…relates to just-in-time auto-provisioning systems and methods for an information exchange platform, useful for enterprise-to-enterprise electronic data interchange.”
receiving, by an orchestration engine running on an electronic information exchange platform, an itinerary requiring a managed service provided by the electronic information exchange platform;
[0027] In some embodiments, system 110 may be configured to provide and manage (orchestrate) a very large number (e.g., 50 or more) of services (“managed services”) [0028] “system 119 of OU-A which utilize managed services provided by system 110 are client systems of system 110. Client systems 119 operating in enterprise computing environment 101 may use managed services to communicate (e.g., exchange information) with various systems and/or devices operating in computing environments 199…”
determining, by the orchestration engine, whether an adapter for the managed service is currently in use; [0011] When the trading partner of the client system is not found in the information exchange platform, the JIT provisioning subsystem is operable to automatically and programmatically provision the trading partner of the client system. The automatic and programmatic provisioning performed by the JIT provisioning subsystem includes running a JIT auto-provisioning workflow during which many pieces of information are generated and/or configured for the trading partner of the client system [0059] “JIT provisioning service 215 (which can implement an embodiment of JIT provisioning module 167 of system 110 running on Trading Grid 100 of FIG. 1) to determine whether JIT auto-provisioning is needed to provision a receiver (a TP of the client of the Trading Grid) or is the receiver already set up (provisioned) in the Trading Grid.” [0067] “If lookup service 230 finds that the receiver has already been provisioned, response 235 is generated and sent back (via, for instance, Java Messaging Service (JMS) 240) to the orchestration component (e.g., Orchestration Engine 160) to circumvent workflow 250. If lookup service 230 cannot find the receiver in the system and/or no JIT auto-provisioning process is in progress for the receiver, it puts a lock on that unique identifier for the receiver and invokes workflow 250.”
Under BRI, “adapter for the managed service” encompasses the provisioned service configuration for the Trade Partners (TP), use to determine if the receiver has been provision within the Trading Grid (TG).
Barton does not explicitly disclose
responsive to not finding the adapter for the managed service currently in use, communicating, by the orchestration engine to an auto-scaler, a need for the adapter for the managed service; and
responsive to the need for the adapter, automatically scaling up, by the auto-scaler, deployment of the adapter to a minimum of two computing units.
However, Quiros discloses “responsive to not finding the adapter for the managed service currently in use, communicating, by the orchestration engine to an auto-scaler, a need for the adapter for the managed service;” [col 13 lines 3-13] “As an example, with reference to FIG. 8, such a microservices environment 800 may include request initiators 602, security controllers 604, a load balancer 802, a service 804 including one or more systems forming auto-scale group 806, an auto-scale controller 808, or other components. For a given service 622, the number of containers running at a point in time may be determined by an auto-scaling controller that monitors the load on the service (e.g., a load per system of the systems comprising the service) and adds or subtracts containers from the service to modify (e.g., match the load.” (See Fig 8) [col 28 lines 29-37] “Process 1200 may begin at operation 1202. In operation 1202, data flows may be monitored for an instruction to perform a scale-in process. In some embodiments, when the load per system or container (e.g., including the newly added systems) falls below a preset threshold (e.g., 75% or less of the corresponding system's processing capacity, 90% or less of the corresponding system's processing capacity, etc.), auto-scale controller 808 may be configured to initiate a “scale-in” process.” (See Fig 12)
“responsive to the need for the adapter, automatically scaling up, by the auto-scaler, deployment of the adapter to a minimum of two computing units.” [col 13 lines 45-54] “Auto-scale controller 808 may further be configured to monitor the load on the systems the containers are running on so that one or more containers are added to a lightly loaded system and/or one or more containers are removed from a heavily loaded system. Auto-scale controller 808 may ensure that there are the right number of containers to meet the load, and that the systems the containers run on have sufficient capacity to run those containers.”
Both Barton and Quiros are in similar field of endeavor, as they both are in transmission of digital information and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Barton, and with the teachings of Quiros to communicate the need for the adapter for the managed service and to further automatically scaling up, by the auto-scaler, deployment of the adapter to a minimum of two computing units.
Motivation to combine would be to improve the reliability and availability of the managed services of the information exchange system by guaranteeing that the adapter deployments are automatically scaled to multiple computing unit as needed.
As per claim 8, it has similar limitation as claim 1, therefore is rejected under the same rationale.
As per claim 15, it has similar limitation as claim 1, therefore is rejected under the same rationale.
As per claim 7
Barton further disclose “, wherein the itinerary defines a process model specific to a document type and wherein the managed service is one of a plurality of managed services provided by the electronic information exchange platform” [0033] “Orchestration Engine 160 may process the document based on itinerary 165. As an example, itinerary 165 may indicate that the document is to be processed by decompression, translation, formatting, and validation services.” [0081] “In this example, management UI 400 may comprise Tuple Grid 401 for displaying solution-specific tuples 410a . . . 410n. Each managed service is defined in an itinerary for a tuple…. for completing a data flow within a custom solution. For instance, itinerary 420 specifies what services are to be used for processing tuple 410b of Doc Type 460 from a client system at customer address 440 to a trading partner's system at partner address 450.”
As per claim 14 it has similar limitation as claim 7, therefore is rejected under the same rationale.
As per claim 20, it has similar limitation as claim 7, therefore is rejected under the same rationale.
Claims 2, 6, 9, 13, 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Barton et al. (US 20180324279 A1), in view of Quiros (US 12003546 B1), in view of Biswas et al (US 20230232195 A1).
As per claim 2 Barton and Quiros disclose the method of claim 1 detailed above.
Barton and Quiros does not explicitly disclose
wherein the automatically scaling up comprises making a call to an application programming interface (API) of a Kubernetes cluster, wherein the API is operable to deploy the minimum of two computing units for the adapter.
However, Biswas discloses “wherein the automatically scaling up comprises making a call to an application programming interface (API) of a Kubernetes cluster, wherein the API is operable to deploy the minimum of two computing units for the adapter.” [0033] “handles conversion of data between the Kubernetes cluster and the front-end load balancer. In some embodiments, the ingress controller 120 is implemented on one or more Pods in the Kubernetes cluster 105. This ingress controller 120 listens to a Kubernetes API server and translates Kubernetes data (e.g., the ingress object 125, service objects, etc.) into the data model used by the front-end load balancer. The ingress controller 120 communicates the translated information to the load balancer controller 115 via API calls in some embodiments to automate the implementation of this configuration by the load balancer data plane 110.” [0040] “the metrics receiver 210 receives API schema information for the front-end load balancer from the ingress controller and uses this API information to retrieve the traffic metrics from the load balancer controller via API calls... As these metrics are retrieved, the metrics receiver 210 provides the metrics to the auto-scaling and deployment module 215” [0041] “The auto-scaling and deployment module 215 uses the scaling factors computed by the modeler 205 to determine, in real-time, whether any of the services in the service chain need to be scaled (e.g., either instantiation of additional Pods or removal of Pods) based on the traffic metrics. The capacity of each Pod is specified for each service (the capacity can vary between services) for one or more metrics (e.g., requests per unit time) and provided to the auto-scaling and deployment module 215…. The current value for this metric (as received from the load balancer controller and multiplied by the scaling factor for a given service) is divided by the Pod capacity for the service to determine the number of Pods that will be required for the service. If the actual number of Pods is less than the required number of Pods, then the auto-scaling and deployment module 215 manages the deployment of additional Pods for the service.
Barton, Quiros and Biswas are in similar field of endeavor, as they are all in transmission of digital information and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Barton, with the teachings of Quiros, and with the teachings of Biswas to automatically scaling up by making a call to an application programming interface (API) of a Kubernetes cluster, wherein the API is operable to deploy the minimum of two computing units for the adapter.
Motivation to combine would be to improve the scalability by automatically deploying additional computing unit as needed for the adapter.
As per claim 9, it has similar limitation as claim 2 therefore is rejected under the same rationale.
As per claim 16, it has similar limitation as claim 2 therefore is rejected under the same rationale.
As per claim 6,
Biswas further disclose “wherein each of the computing units comprises a pod, a container, or a set of tightly coupled containers.”
[0041] “The auto-scaling and deployment module 215 uses the scaling factors computed by the modeler 205 to determine, in real-time, whether any of the services in the service chain need to be scaled (e.g., either instantiation of additional Pods or removal of Pods) based on the traffic metrics. The capacity of each Pod is specified for each service (the capacity can vary between services) for one or more metrics (e.g., requests per unit time) and provided to the auto-scaling and deployment module 215….”
As per claim 13, it has similar limitation as claim 6 therefore is rejected under the same rationale.
As per claim 19, it has similar limitation as claim 6 therefore is rejected under the same rationale.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Barton et al. (US 20180324279 A1), in view of Quiros (US 12003546 B1), in view of Wiseman et al (WO 02103491 A2).
As per claim 3 Barton and Quiros disclose the method of claim 1 detailed above.
Barton and Quiros does not explicitly disclose
“generating and sending an alert message about the adapter through a channel internal to the electronic information exchange platform.”
However, Wiseman discloses “generating and sending an alert message about the adapter through a channel internal to the electronic information exchange platform.” [0010] “a system for facilitating the exchange of information among applications may include a plurality of process models, each defining one or more conditions for sending a business event from an application to one or more other applications…. a plurality of transformer classes configured to translate data object from a format used by one or more applications into the common format or vice versa, and a plurality of controller classes configured to route data objects to associated transformer classes. [0011] “The system also may include an acknowledgement class configured to exchange status messages among applications and/or to perform exception handling. [0034] “For example, each time a business event is received by an enterprise application, the receiving application invokes an acknowledgement class to signal either that the transfer was successful or that a particular error occurred. Upon occurrence of error, the acknowledgement class can trigger an appropriate error-handling procedure.” (See Fig 2 & Fig 2E-1) [0038] “The transformer classes operate by applying formatting and translation logic to the data before loading them into an application or business event. ….. The transformers include exception handling and acknowledgement classes that capture errors and publish them to an acknowledgement channel or error log.” [0039] The communicator infrastructure 310 provides transactional synchronous and/or asynchronous message structure for communicating between the integration hub 300 and the enterprise applications. [0066] “The error information may include the name of the failed event, the name of the application for which the connector belongs, the error message, and a flag to denote a success or failure. This information is packaged within an event that is sent to the Acknowledgement channel 612.” (See Fig 6)
Barton, Quiros and Wiseman are all concerned about managing information within the information exchange platform and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Barton, with the teachings of Quiros, and with the teachings of Wiseman to generate and send an alert message about the adapter through a channel internal to the electronic information exchange platform.
Motivation to combine would be to improve the reliability and efficiency by ensuring that any errors are resolved in a timely manner, which would further reduce escalation within the platform.
As per claim 10, it has similar limitation as claim 3 therefore is rejected under the same rationale.
As per claim 17, it has similar limitation as claim 3 therefore is rejected under the same rationale.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Barton et al. (US 20180324279 A1), in view of Quiros (US 12003546 B1), in view of Kamath et al. (US 20210004245 A1)
As per claim 4 Barton and Quiros disclose the method of claim 1 detailed above.
Barton and Quiros does not explicitly disclose
“queuing a service request message for the managed service in a service request queue, wherein the service request message is consumed by the adapter once the two computing units are deployed to the adapter so as to support the managed service.”
However, Kamath discloses “queuing a service request message for the managed service in a service request queue, wherein the service request message is consumed by the adapter once the two computing units are deployed to the adapter so as to support the managed service.” [0010] “In response to the received request, the composer container may determine whether the adapter device has sufficient computing resources to support a service container to provide the requested adapter service. “[0029] “Block 420 may include receiving, by the composer container in the adapter device, a plurality of adapter service requests from the host device. As used herein, an “adapter service request” is a request that causes a service container to be deployed in an adapter device.” [0030] “Block 430 may include, in response to the plurality of adapter service requests, the composer container deploying a plurality of service containers in the adapter device, where each service container is to provide a particular processing service to the host device, and where each service container is allocated a subset of the plurality of computing resources of the adapter device.”
Barton, Quiros and Kamath are in similar field of endeavor, as they are all in transmission of digital information and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Barton, with the teachings of Quiros, and with the teachings of Kamath to queue a service request message for the managed service in a service request queue, wherein the service request message is consumed by the adapter once the two computing units are deployed to the adapter so as to support the managed service.
Motivation to combine would be to improve the reliability and reduce delays in initiating the computing unit by automatically consuming the queued request and supporting the managed service by ensuring requests are not lost if computing unit are not yet deployed.
As per claim 11, it has similar limitation as claim 4 therefore is rejected under the same rationale.
As per claim 18, it has similar limitation as claim 4 therefore is rejected under the same rationale.
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Barton et al. (US 20180324279 A1), in view of Quiros (US 12003546 B1), in view of Ford et al. (US20170041296 A1)
As per claim 5 Barton and Quiros disclose the method of claim 1 detailed above.
Barton and Quiros does not explicitly disclose
“wherein the orchestration engine operates in a zone of the electronic information exchange platform.”
However, Ford discloses “wherein the orchestration engine operates in a zone of the electronic information exchange platform.” [0083] “The secure exchange system 102 may be deployed alone, or it may be deployed in a hybrid situation with the orchestration services 165. The intermediate host may also manage the orchestration services 165, such as by the service manager 112B and/or by interacting with various interfaces or APIs of the orchestration services 165 that are designed to enable use of the various services….” [0084] “The orchestration services may include various data stores that may be used by or in connection with uses of the orchestration services 165 for exchange services and storage 166, such as a workflow queue and instance store 182…. “[0087] “For example, a user device 120 may include a secure viewer 122 as described in more detail elsewhere in this disclosure, by which a user may have access to data in various parts of the on enterprise premises system 110, such access being managed by the secure exchange system 102 and/or the orchestration services 165 in various embodiments, such as to confirm the identity of the user of a user device 120, to confirm the authorization of the user and device to access particular data….”
Under BRI, Ford disclose a secure exchange system that read electronic information exchange platform ([0066], [0068]). Ford further disclose that an “orchestration engine” is orchestration service operate in a specific zone “premises” within the secure exchange system.
Barton, Quiros and Ford are in similar field of endeavor, as they are all in transmission of digital information and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Barton, with the teachings of Quiros, and with the teachings of Ford for the orchestration engine operates in a zone of the electronic information exchange platform.
Motivation to combine would be to improve the security by placing the orchestration engine within specific zone and/or bounded area of the electronic information exchange platform, making control and access easier.
As per claim 12 Barton and Quiros disclose the system of claim 8 detailed above.
Ford further discloses “wherein the determining and the communicating are performed by an orchestration engine operating in a zone of the electronic information exchange platform.” [0082] “The orchestration services 165 may include a service manager 112B, which may interact with a similar service manager 112A located in the on enterprise premises system 110, as well as with capabilities and services of the secure exchange system 102, to deploy, track, manage, and report on the activities of one or more of the services, applications, engines and the like described herein.”[0092] “ …orchestration layer to receive multiple search tickets needed to retrieve the data from the various data sources….The browser may then send an application-specific message to an application server, which creates an orchestration region composite request. A composite proxy may then validate the message for correct application signing, and the basic schema of composite message. It may also invoke an evaluative entitlement function, and reject any requests that the entitlement service deems to be unauthorized.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Fernandes; Ricardo Zanini (US-20220391255-A1) disclose a container-orchestration system reads specification data associated with a third-party resource used by a managed resource.
Filiz; Onur et al (US-11392422-B1) disclose container orchestration service may generate and submit a request to a serverless container management service that can not only acquire compute resources on behalf of the container orchestration service but also manage the compute resources.
Gunuganti; Ramakanth (US-20230333904-A1) disclose a metrics engine that collects metrics for components of the datapath and provides the metrics to the cloud resource inventory engine, which informs communications to the orchestration service, and the node provisioning engine autoscales components of the datapath.
Maes; Stephane Herman (US-20150163179-A1) disclose a service exchange includes an orchestrator to execute a workflow that involves a plurality of applications and services of a plurality of data centers.
Mohammad; Arifulla Baig (US-12095775-B1) disclose an interconnection platform for an exchange, an interconnection token representing authorization for an interconnection to or from a resource of the exchange.
Mellquist; Peter Erik (US-20210397465-A1) disclose a CaaS controller of a managed container service monitors a metric of a cluster deployed on behalf of a customer within a container orchestration system.
Tummala; Aparna Kumar (US-20230359513-A1) disclose a communication between clients and providers, all communicating in different formats and protocols and having different security requirements.
Cotugno; Lauren Ann (US-20100332629- A1) disclose a secure custom application cloud computing architecture which facilitates virtually seamless migration of custom applications to and from a cloud computing environment in response to user needs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ASHMEED ACHILLE whose telephone number is (571)272-9437. The examiner can normally be reached Monday-Friday 7am -4pm.
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, PIERRE VITAL can be reached at (571)272-4215. 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.A./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights