Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. See table below for rationale of rejection.
Claim 1:
Treated Under:
Explanation:
A method for multi cloud task orchestration, comprising:
Step 1 – MPEP § 2106.03
The claim falls into a statutory category of subject matter.
creating, by a workflow task function, a first job for a service provided on a container orchestration system, wherein the workflow task function cannot call the service directly;
Step 2A Prong 1 – MPEP § 2106.04(a)(2)
A human operator could mentally create a first job for a service by viewing data on a terminal and mentally formulating a job to perform. Further, relying on “a workflow task function” amounts to mere instructions to apply an exception. See MPEP § 2106.05(f).
forwarding, by the workflow task function, the first job to the service as a serverless task/function using a request forwarder;
Step 2A Prong 2 – MPEP § 2106.04(d)
Step 2B – MPEP § 2106.05(g)
Courts have found that “[o]btaining information about transactions using the Internet to verify credit card transactions” amounts to mere data gathering. MPEP § 2106.05(g) (CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011)). Here, the forwarding the first job corresponds to the obtaining information in CyberSource v. Retail Decisions, Inc. Accordingly, the forwarding the first job does integrate the recited abstract idea into a practical application.
Courts have found that “[o]btaining information about transactions using the Internet to verify credit card transactions” amounts to mere data gathering. MPEP § 2106.05(g) (CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011)). Here, the forwarding the first job corresponds to the obtaining information in CyberSource v. Retail Decisions, Inc. Accordingly, the forwarding the first job does not amount to significantly more than an abstract idea.
waiting, by the workflow task function, for a period of time;
Step 2A Prong 1 – MPEP § 2106.04(a)(2)
A human operator could mentally perform the waiting by viewing data on a terminal and mentally determining to wait for a period of time. Further, relying on “a workflow task function” amounts to mere instructions to apply an exception. See MPEP § 2106.05(f).
checking, by the workflow task function, a status of the first job with the serverless task/function;
Step 2A Prong 1 – MPEP § 2106.04(a)(2)
A human operator could mentally check a status by viewing data on a terminal and mentally determining the status of the first job. Further, relying on “a workflow task function” amounts to mere instructions to apply an exception. See MPEP § 2106.05(f).
receiving, by the workflow task function, the status of the first job;
Step 2A Prong 2 – MPEP § 2106.04(d)
Step 2B – MPEP § 2106.05(g)
Courts have found that “[o]btaining information about transactions using the Internet to verify credit card transactions” amounts to mere data gathering. MPEP § 2106.05(g) (CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011)). Here, the receiving the status corresponds to the obtaining information in CyberSource v. Retail Decisions, Inc. Accordingly, the receiving the status does integrate the recited abstract idea into a practical application.
Courts have found that “[o]btaining information about transactions using the Internet to verify credit card transactions” amounts to mere data gathering. MPEP § 2106.05(g) (CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011)). Here, the receiving the status corresponds to the obtaining information in CyberSource v. Retail Decisions, Inc. Accordingly, the receiving the status does not amount to significantly more than an abstract idea.
and continuing, by the workflow task function, with a second job for the service provided on the container orchestration system.
Step 2A Prong 1 – MPEP § 2106.04(a)(2)
A human operator could mentally continue with a second job by viewing data on a terminal and mentally determining a second job to perform. Further, relying on “a workflow task function” amounts to mere instructions to apply an exception. See MPEP § 2106.05(f).
Regarding claim 2, it recites sending the first job to an API, which amounts to mere data gathering for the same reason as the data gathering steps recited in claim 1. Accordingly, claim 2 is ineligible.
Regarding claim 3, it further defines serverless task/function as being a Lambda function; however, a human operator could mentally create Lambda functions. Accordingly, claim 3 is ineligible.
Regarding claim 4, it further defines the first job as being a Kubernetes job; however, a human operator could mentally create a Kubernetes job. Accordingly, claim 4 is ineligible.
Regarding claim 5, a human operator could mentally determine definitions for a Kubernetes job. Accordingly, claim 5 is ineligible.
Regarding claim 6, it further recites the request forwarder comprises a NodeJS project; however, this amounts to mere instructions to apply an exception. See MPEP § 2106.05(f).
Regarding claim 7, it further limits the request forwarder to restricting calls; however, the functions performed by the request forwarder still amount to mere data gathering for the same reason as the data gathering operations in claim 1.
Regarding claim 8, it further recites the request forwarder is integrated with an Active Directory Federation Service; however, this amounts to mere instructions to apply an exception. See MPEP § 2106.05(f).
Regarding claim 9, it further recites a Kubectl wrapper receives the Kubernetes job; however, this amounts to mere instructions to apply an exception. See MPEP § 2106.05(f).
Regarding claim 10, it further recites the Kubectl Wrapper API interfaces with a Kubernetes job API; however, this amounts to mere instructions to apply an exception. See MPEP § 2106.05(f).
Regarding claim 11, it further recites the service does not have allow-listable IP addresses; however, a human operator could still mentally create a job for a service that does not have allow-listable IP addresses. Accordingly, claim 11 is ineligible.
Regarding claims 12-20, they correspond to claims 1-11. Therefore, they are rejected for the same reasons.
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.
Claim(s) 1-5, 7, 12-15, 17, 19, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mathur (US 2021/0174941) and further in view of Ananthapur (US 2021/0157622).
Regarding claim 1, Mathur teaches: A method
creating, by a workflow task function (¶ 91, “The algorithm orchestration component 110 can include an orchestration conductor component 112 to orchestrate fulfilling the image processing requests 106 and returning request results and status notifications 108 to the medical image providers”), a first job for a service provided on a container orchestration system (¶ 106, “an algorithm/model and other tasks defined by computer executable instructions can be wrapped in a Kubernetes Job function”), wherein the workflow task function cannot call the service directly (¶ 130, “the algorithm orchestration component 110 can restrict acceptance of image processing requests 106 to only those systems/devices identified in the system/device task registry data 126”);
forwarding, by the workflow task function, the first job to the service as a serverless task/function using a request forwarder (¶ 91, “the orchestration conductor component 112 can coordinate the interaction between the image provider systems/devices 102 and the various components of the algorithm orchestration system 100 (and other systems describe herein) used to retrieve and store the medical image data to be processed using the algorithms, execute the workflows and invoke the algorithms associated therewith, and return the request results and status notifications 108”);
waiting, by the workflow task function, for a period of time (¶ 96, “A Wait node adds a delay in the workflow based on one or more defined conditions. For example, a Wait node can be used to restrict initiation of a task until completion of another task or sub-workflow”);
checking, by the workflow task function, a status of the first job with the serverless task/function (¶ 96, “Wait nodes can thus be used to track the execution of asynchronous tasks as part of the orchestration”);
receiving, by the workflow task function, the status of the first job (¶ 198, “The workflow auditing UI 1511 provides detailed information for the workflow, including the workflow name, the workflow type (e.g., which can be either a workflow or a sub-workflow), the workflow status, the workflow start time, the workflow duration, and the workflow version”); and
continuing, by the workflow task function, with a second job for the service provided on the container orchestration system (¶ 58, “The workflows can also be configured to execute asynchronous tasks and wait for the task to be completed. The workflows can also be configured to evaluate the output of a task and use it as input for another task.”).
Mathur does not teach; however, Ananthapur discloses: multi cloud task orchestration (¶ 46, “Kubernetes master node 506 is configured on one primary Kubernetes cluster and is connected to worker nodes 510, 512 configured on at least one cloud provider other than the cloud provider that provides for the cluster where the master node is located”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of multi cloud task orchestration, as taught by Ananthapur, in the same way to the method, as taught by Mathur. Both inventions are in the field of managing Kubernetes clusters, and combining them would have predictably resulted in “container orchestration using Kubernetes,” as indicated by Ananthapur (¶ 1).
Regarding claim 2, Mathur teaches: The method of claim 1, wherein the request forwarder sends the first job and/or the second job to an API associated with the service (¶ 207, “The API gateway 1704 will forward the request to the orchestration conductor component 112 that can validate the request payload and respond with an execution ID (e.g., a request ID) and a status”).
Regarding claim 3, Mathur teaches: The method of claim 1, wherein the serverless task/function comprises a Lambda function (¶ 95, “A Task node represents a task to be executed by the workflow. These can include HTTP tasks, Lambda tasks, Kubernetes jobs (e.g., commonly referred to as k8s jobs), or the like”).
Regarding claim 4, Mathur teaches: The method of claim 1, wherein the first job and/or the second job are Kubernetes jobs (¶ 95, “A Task node represents a task to be executed by the workflow. These can include HTTP tasks, Lambda tasks, Kubernetes jobs (e.g., commonly referred to as k8s jobs), or the like”).
Regarding claim 5, Mathur teaches: The method of claim 4, wherein the Kubernetes jobs comprises definitions of the Kubernetes jobs (¶ 60, “an algorithm/model and other tasks defined by computer executable instructions can be wrapped in a Kubernetes Job function and the algorithm orchestration component can execute it asynchronously inside the cluster on behalf of the user”).
Regarding claim 7, Mathur teaches: The method of claim 1, wherein the request forwarder is restricted to calls from specific APIs and/or endpoints (¶ 206, “The API gateway 1704 interfaces with the orchestration conductor component 112 that orchestrates execution of the workflow execution engine 116 and the algorithm execution engine 118 as well as the various services provided by the algorithm orchestration component 110” and ¶ 189, “The device rules component 558 can further provide for defining custom rules and restrictions for specific systems and devices regarding what types of request the algorithm orchestration component will accept (e.g., regarding image type and image study size), and rules and restrictions regarding when and how the algorithm orchestration component 110 will fulfill the requests”).
Claims 12-15, 17, 19, and 20 recite commensurate subject matter as claims 1-5 and 7. Therefore, they are rejected for the same reasons.
Claim(s) 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mathur and Ananthapur, as applied above, and further in view of Miller (US 2021/0342145).
Regarding claim 6, Mathur and Ananthapur do not teach; however, Miller discloses: the request forwarder comprises a NodeJS project (¶ 14, “The implementations described herein support languages such as JavaScript (TypeScript/Node.js), Java, APEX, and other programming languages”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the request forwarder comprises a NodeJS project, as taught by Miller, in the same way to the request forwarder, as taught by Mathur and Ananthapur. Both inventions are in the field of forwarding requests, and combining them would have predictably resulted in “deploying metadata driven serverless functions in a multitenant environment,” as indicated by Miller (¶ 1).
Claim(s) 16 recite(s) commensurate subject matter as claim(s) 6. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 8 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mathur and Ananthapur, as applied above, and further in view of Patimer (US 11,425,134).
Regarding claim 8, Mathur and Ananthapur do not teach; however, Patimer discloses: the request forwarder is integrated with an Active Directory Federation Service, wherein the Active Directory Federation Service provides authentication services (col. 5:23-28, “Microsoft Azure Active Directory—can support Microsoft Azure Active Directory using Azure AD Connect synchronization, and can also be used in combination with Active Directory Federation Services (ADFS) to authenticate via an on-premises infrastructure”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the request forwarder is integrated with an Active Directory Federation Service, wherein the Active Directory Federation Service provides authentication services, as taught by Patimer, in the same way to the request forwarder, as taught by Mathur and Ananthapur. Both inventions are in the field of forwarding requests, and combining them would have predictably resulted in “secure communication session between the client application and the corporate web application,” as indicated by Patimer (abstract).
Claim(s) 18 recite(s) commensurate subject matter as claim(s) 8. Therefore, it/they is/are rejected for the same reasons.
Claim(s) 9 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mathur and Ananthapur, as applied above, and further in view of Saxena (US 2022/0121470).
Regarding claim 9, Mathur and Ananthapur do not teach; however, Saxena discloses: a Kubectl Wrapper API receives the Kubernetes job from the request forwarder (¶ 23, “The controller node 110 is responsible for orchestration and deployment decisions for the worker nodes 120 and is the interface to a developer deploying workloads via an application programming interface (API) 102 (e.g., using kubectl in Kubernetes®)”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of a Kubectl Wrapper API receives the Kubernetes job from the request forwarder, as taught by Saxena, in the same way to the Kubernetes job, as taught by Mathur and Ananthapur. Both inventions are in the field of Kubernetes jobs, and combining them would have predictably resulted in a method that “provides cloud-specific controls to developers,” as indicated by Saxena (¶ 24).
Regarding claim 10, Saxena discloses: The method of claim 9, wherein the Kubectl Wrapper API interfaces with a Kubernetes job API (¶ 23, “The controller node 110 is responsible for orchestration and deployment decisions for the worker nodes 120 and is the interface to a developer deploying workloads via an application programming interface (API) 102 (e.g., using kubectl in Kubernetes®)”).
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mathur and Ananthapur, as applied above, and further in view of Rudraraju (US 2022/0012045).
Regarding claim 11, Mathur and Ananthapur do not teach; however, Rudraraju discloses: the service does not have an allow-listable IP address (¶ 52, “The private APIs 32 may be similar to the public APIs 32 except that the endpoints of the private APIs 32 are not publically available or accessible”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the service does not have an allow-listable IP address, as taught by Rudraraju, in the same way to the Kubernetes job, as taught by Mathur and Ananthapur. Both inventions are in the field of function orchestrators, and combining them would have predictably resulted in “security mechanisms to keep each tenant's data separate unless the data is shared,” as indicated by Rudraraju (¶ 23).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cherunni (US 2020/0412596) discloses “a container management platform, the integrated network requirement, and (5) causing a VNF to be generated in the container to fulfill the integrated network requirement” (abstract), which relates to the disclosed orchestration system.
Luo (US 2020/0322237) discloses “A traffic detection method includes obtaining a plurality of packets collected by a traffic collection device in a first time period, where the plurality of packets include packets in a first data stream and at least one other data stream collected in the first time period” (abstract), which relates to the disclosed forwarding jobs to a service and waiting for a period of time.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00.
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.
/JACOB D DASCOMB/ Primary Examiner, Art Unit 2198