DETAILED ACTION
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 .
Response to Amendment
This office action is in reply to Applicant’s Response dated 01/06/2026. Claims 1-5, 8, 11, 14 and 17 are amended. Claims 18-20 are new. Claims 1-20 are pending in the application.
Response to Arguments
The Applicant argues (see page 7), with respect to the claim interpretation under 35 U.S.C. 112(f), that the claim terms are not generic nonce terms but are well-recognized structural designations in the field of computer systems and cloud architecture. A "console" is understood as a dedicated interface or subsystem for management. A "manager" is understood as a software component responsible for controlling and coordinating specific tasks or resources. Paragraphs 58 & 63-68 (Figs. 3-4) detail the cloud management console comprising distinct sub-modules like an authentication management console, authority management console, service management console, and demo management console. Paragraphs 77-83 (Figs. 3-4) detail the API service manager comprising distinct, interoperable sub-modules like an API authentication interworking module, API endpoint, job manager (itself containing a job management module and job status check module), and API execution request module. Applicant respectfully asserts that the claims do not invoke the claim interpretation under 35 U.S.C. § 112 (f).
In response to the Applicant’s argument, the Examiner respectfully disagrees. First, in response to the Applicant’s assertion that "console" is understood as a dedicated interface or subsystem for management and a "manager" is understood as a software component responsible for controlling and coordinating specific tasks or resources, the claims are construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The specification does not disclose that a "console" is understood as a dedicated interface or subsystem for management and a "manager" is understood as a software component.
Second, the Applicant argues that paragraphs 58 & 63-68 (Figs. 3-4) detail the cloud management console comprising distinct sub-modules like an authentication management console, authority management console, service management console, and demo management console and console, service management console, and demo management console and paragraphs 77-83 (Figs. 3-4) detail the API service manager comprising distinct, interoperable sub-modules like an API authentication interworking module, API endpoint, job manager (itself containing a job management module and job status check module), and API execution request module. However, the terms disclose in these paragraphs and as pointed out by the Applicant are “console”, “sub-modules”, “module”, “endpoint” and “manager”, which would invoke 35 U.S.C. 112(f). These paragraphs and figures do not disclose the corresponding structures for “console”, “sub-modules”, “module” and “manager”.
The Applicant has not shown or provided supporting evidence that the limitations: “cloud management console” in claims 1 and 17; “API service manager” in claims 1-5, 8 11 and 14; “API authentication interworking module” in claims 5, 8, 11 and 13; “demo management console” in claim 14, “a user management module“ in claim 4; “an API execution request module” in claims 5 and 7-12; “job management module” in claims 6 and 7; “job status check module” in claim 6-7; and “API authentication module” in claims 3 and 17 connote sufficient structure to one of ordinary skill in the art. Therefore, the claim interpretation under 35 U.S.C. 112(f) is maintained.
In response to the Applicant’s argument (see page 8) with respect to the rejection under 35 U.S.C. 101 that claim 17 has been amended to recite "non-transitory", the rejection under 35 U.S.C. 101 has been withdrawn in view of the amendment. However, claims 17 is now rejected under 35 U.S.C. 112(b) as a result of the amendments made to the claim.
The Applicant argues (see pages 9-10), with respect to claim 1, that While
MacCarthaigh allows a customer to call a failover API, it does not teach the specific integrated authentication loop required by Claim 1, where: (1) A Cloud Management Console (Control Plane) issues authentication information (Claim 1, line 3). (2) The API Service Manager (Data Plane) receives the call directly (Claim 1, last clause).
(3) The API Service Manager performs authentication (Claim 1, element 2) (implicitly by interworking with the control plane as clarified in dependent claims and the specification).
In response to the Applicant’s argument, MacCarthaigh is relied upon to teach “the call message is received by the API manager belonging to a data plane without via the control plane.” MacCarthaigh teaches that when the customer calls a failover service data plane or similar API, the failover service data plane can reply with an identifier acknowledging that the write operation (for example, the requested state change) was registered successfully in the failover service servers and that the customer may call the failover service data plane API for the write operation. The call may only return a success response if the failover service 302 committed the request (MacCarthaigh, see paragraphs 0145-0146). Thus, MacCarthaigh teaches “the call message is received by the API manager belonging to a data plane without via the control plane.” Shtarbev is relied upon to teach the other limitations in the claim. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
The Applicant argues (see page 9-10), with respect to claim 1, that there is lack of motivation to combine and the rationale does not explain why one skilled in the art would modify the Shtarbev architecture to bypass its own API Gateway. To strip away the Gateway's function and allow direct access to an internal manager (as taught by MacCarthaigh's specific failover context) would defeat the security centralization purpose of Shtarbev.
In response to the Applicant’s argument, the Examiner respectfully disagrees. First, the claim does not define the term “control plane” nor does it specify which terminals or components are included in the control plane. Second, paragraphs 0020 and 0022 of Shtarbev discloses that user IDs and passwords for accessing (i.e., logging into) cloud platform 12 through UI 11 are set up for the tenant and that CSP ID service 110 manages authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15. Access through UI 11 is authenticated if login credentials entered by the user are valid. API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110. It is clear here that API gateway 15 (control plane) can be bypassed while maintaining security because access can be performed through UI 11 instead of via the control plane (API gateway 15). It is noted that paragraph 0015 of Shtarbev teaches that a user interface (UI) or an application programming interface (API) that interacts with cloud platform 12 is depicted in FIG. 1 1 as UI 11, and therefore, UI 11 is an API. Hence, API calls can be made through UI 11.
Therefore, modifying Shtarbev to include features from MacCarthaigh would not strip away the security features of Shtarbev. Instead, the modification would provide the advantage of enabling the customers of Shtarbev to model failover workflows in an automated, predictable manner and have control over which application cells serve traffic for the application and which cells do not (MacCarthaigh, see paragraphs 0015 and 0031). Accordingly, the combination of Shtarbev and MacCarthaigh is reasonable.
The Applicant argues (see page 10) that Alrabady teaches "by-passing a security
code" for developmental software [Source 193]. This is distinct from the claimed "demo
management console" which allows a user to select an API and receive a trial result.
Alrabady is about installing firmware on a controller, not a cloud-based API trial service.
The specific interaction where a Management Console (Control Plane) triggers a demo on the AP/ Service Manager (Data Plane) without requiring the user to submit an auth key is not taught by the prior art.
In response to the Applicant’s argument, the Examiner respectfully disagrees. Claim 14 is rejected using the combination of three references: Ramakrishna, Shtarbev and Alrabady. Ramakrishna and Shtarbev are cited to teach limitations that included the “API selected” or “selected API” features. Alrabady is cited to teach the limitation that requires “configured not to require authentication information…”. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “cloud management console” in claims 1 and 17; “API service manager” in claims 1-5, 8, 11, and 19; “API authentication interworking module” in claims 5, 8, 11 and 13; “demo management console” in claim 14, “a user management module“ in claim 4; “an API execution request module” in claims 5 and 7-12; “job management module” in claims 6 and 7; “job status check module” in claim 6-7; “API authentication module” in claims 3 and 17; and “system” in claim 20.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation: "(e.g., a memory, a processor, etc.) interacting with each other” (see paragraph 0052 of the specification as filed).
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 17 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 17 recites “A non-transitory computer-readable recording medium storing a computer program coupled to a computing device to execute:…” However, claim 17 does not recite that the computer program is executed by the computing device. Therefore, it is unclear how the computer program can perform the steps in the claim without being executed by the computing device. This rejection may be overcome by amending the claim to recite “A non-transitory computer-readable recording medium storing a computer program coupled to a computing device that when the computer program is executed by the computing device causes the computing device to execute:…”
Claims 14 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 14 recites “the API manager is configured not to…”. Claims 4 and 14 have been amended to recite “”API service manager”. Therefore, there is insufficient antecedent basis for the limitation “the API manager” in the claim. The Examiner suggests amending claim 14 to recite “the API service manager is configured not to…” to overcome this rejection.
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, 3-5, 8, 15, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Shtarbev et al. (U.S. PGPub 2024/0020143) in view of MacCarthaigh et al. (U.S. PGPub 2021/0157692).
Regarding claim 1, Shtarbev teaches A cloud-based application programming interface (API) service providing system comprising: a cloud management console issuing authentication information for a requested API among a plurality of APIs; (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...)
an API service manager receiving a call message for a specific API, which comprises authentication information, from a user’s terminal, (Shtarbev, see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...)
performing authentication using the authentication information in the call message, and (Shtarbev, see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...)
requesting the execution of the specific API based on the authentication result; and (Shtarbev, see paragraphs 0022-0023 Access through UI 11 is authenticated if login credentials entered by the user are valid. API calls made to the cloud services...entitlement service 120 executes as a cloud service of cloud platform 12 that interacts with endpoint software in a data center to apply subscription entitlement(s) to the endpoint software....)
an API execution engine generating the result of executing the specific API in response to a request from the API service manager, (Shtarbev, see paragraph 0024 When the task is completed by the management appliance, entitlement agent 116 invokes an API of scheduler service 140 to report the completion of the task…)
wherein the cloud management console is a module belonging to a control plane, and (Shtarbev, see fig. 1; see paragraph 0013 employ a cloud control plane for managing the configuration of SDDCs...configuration operations to services running in a local SDDC control plane…)
However, Shtarbev does not explicitly teach the call message is received by the API service manager belonging to a data plane without via the control plane.
MacCarthaigh teaches the call message is received by the API service manager belonging to a data plane without via the control plane. (MacCarthaigh, see paragraphs 0145-0146 when the customer calls a failover service data plane or similar API, the failover service data plane can reply with an identifier acknowledging that the write operation (for example, the requested state change) was registered successfully in the failover service servers. The failover service data plane may work on performing the registered task and the customer can use the identifier to query a status of the registered task at a later time. In some embodiments, the status may comprise one or more of “in queue”, “write successful”... the customer can call the failover service data plane API for a write operation....the customer may call the failover service data plane API for the write operation. The call may only return a success response if the failover service 302 committed the request.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev and MacCarthaigh to provide the technique of the call message is received by the API service manager belonging to a data plane without via the control plane of MacCarthaigh in the system of Shtarbev in order to enable the customers to model failover workflows in an automated, predictable manner (MacCarthaigh, see paragraphs 0015 and 0031).
Regarding claim 3, Shtarbev-MacCarthaigh teaches further comprising an API authentication module belonging to the control plane, wherein the API service manager performs the authentication by interworking with the API authentication module. (Shtarbev, see fig. 1; see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...; see paragraph 0033 implements an orchestration control plane, such as Kubernetes®,...)
Regarding claim 4, Shtarbev-MacCarthaigh teaches further comprising a user management module belonging to the control plane, (Shtarbev, see fig. 1; see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...; see paragraph 0033 implements an orchestration control plane, such as Kubernetes®,...)
wherein the API service manager checks the user’s authority to use the specific API by interworking with the user management module and requests the execution of the specific API based further on the checking result. (Shtarbev, see fig. 1; see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...; see paragraph 0033 implements an orchestration control plane, such as Kubernetes®,...; see paragraph 0020 the URL of the tenant's AAA (authentication, authorization and accounting) server 101, is collected, and user IDs and passwords for accessing...; see paragraph 0032 configured to implement an SSO platform for authenticating users...)
Regarding claim 5, Shtarbev-MacCarthaigh teaches wherein the API service manager comprises: an API authentication interworking module performing the authentication by interworking with the control plane; (Shtarbev, see fig. 1; see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...; see paragraph 0033 implements an orchestration control plane, such as Kubernetes®,...)
a job manager creating a job for the specific API based on the call message and inserting the job into a queue; and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...)
an API execution request module retrieving the job from the queue and requesting the API execution engine to execute the specific API. (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
Regarding claim 8, Shtarbev-MacCarthaigh teaches wherein the API service manager comprises: an API authentication interworking module performing the authentication by interworking with the control plane; (Shtarbev, see fig. 1; see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...; see paragraph 0033 implements an orchestration control plane, such as Kubernetes®,...)
a job manager creating a job for the specific API based on the call message; and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...)
an API execution request module separating the job into tasks based on a preset criterion and requesting the API execution engine to execute the specific API on a task-by-task basis. (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
Regarding claims 15 and 17, Shtarbev teaches A cloud-based API service providing method performed by at least one computing device and comprising: performing authentication of the user using authentication information in the call message; (Shtarbev, see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...)
obtaining the result of executing the specific API through an API execution engine if the authentication is successfully performed; and (Shtarbev, see paragraph 0024 When the task is completed by the management appliance, entitlement agent 116 invokes an API of scheduler service 140 to report the completion of the task…)
providing the execution result to the user’s terminal, wherein the call message comprises the authentication information, the authentication information is issued by the cloud management console, and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0024 When the task is completed by the management appliance, entitlement agent 116 invokes an API of scheduler service 140 to report the completion of the task…; see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...)
the authentication is performed in conjunction with an API authentication module belonging to the control plane. (Shtarbev, see fig. 1; see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...; see paragraph 0033 implements an orchestration control plane, such as Kubernetes®,...)
However, Shtarbev does not explicitly teach receiving a call message for a specific API from a user’s terminal without via a control plane to which a cloud management console belongs;
MacCarthaigh teaches receiving a call message for a specific API from a user’s terminal without via a control plane to which a cloud management console belongs; (MacCarthaigh, see paragraphs 0145-0146 when the customer calls a failover service data plane or similar API, the failover service data plane can reply with an identifier acknowledging that the write operation (for example, the requested state change) was registered successfully in the failover service servers. The failover service data plane may work on performing the registered task and the customer can use the identifier to query a status of the registered task at a later time. In some embodiments, the status may comprise one or more of “in queue”, “write successful”... the customer can call the failover service data plane API for a write operation....the customer may call the failover service data plane API for the write operation. The call may only return a success response if the failover service 302 committed the request.)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev and MacCarthaigh to provide the technique of receiving a call message for a specific API from a user’s terminal without via a control plane to which a cloud management console belongs of MacCarthaigh in the system of Shtarbev in order to enable the customers to model failover workflows in an automated, predictable manner (MacCarthaigh, see paragraph 0015).
Regarding claim 19, Shtarbev-MacCarthaigh teaches wherein the call message comprises storage information indicating an upload location of analysis data in a storage, and (MacCarthaigh, see fig. 4; see a paragraph 0158 perform a network-based services request, a network-based services client may assemble a message including the request and convey the message to an addressable endpoint (e.g., a Uniform Resource Locator (URL)) corresponding to the network-based service...; see paragraph 0137 identify the states for the partitions associated with the respective hosts. As such, at (2), each of the hosts of the first partition will send a polling request to the failover service 302 that include the name of the application 305...each host will receive a value corresponding to its state, as determined by the failover service 302 (for example, as stored in the storages 304 of the failover service)) The motivation regarding to the obviousness to claim 1 is also applied to claim 19.
wherein the API service manager is configured to download the analysis data from the storage based on the storage information and transmit the downloaded analysis data to the API execution engine. (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task (analysis data) corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message (analysis data) in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
Claims 2, 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Shtarbev-MacCarthaigh in view of Chatzistamatiou et al. (U.S. PGPub 2023/0410543).
Regarding claim 2, Shtarbev-MacCarthaigh teaches wherein the specific API is an API for a data analysis function, and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
wherein the specific API is an API for a data analysis function, and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
the API service manager downloads analysis data from a storage and transmits the analysis data to the API execution engine. (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task (analysis data) corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message (analysis data) in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
However, Shtarbev-MacCarthaigh does not explicitly teach wherein the APIs comprise APIs for artificial intelligence (AI)-based character recognition, AI-based text analysis, and AI-based image analysis functions and
the API execution engine runs on a graphic processing unit (GPU)-based worker node and
Chatzistamatiou teaches wherein the APIs comprise APIs for artificial intelligence (AI)-based character recognition, AI-based text analysis, and AI-based image analysis functions and (Chatzistamatiou, see paragraph 0035 where incorporated in an Application Programming Interface (API) service, which can be called by an orchestration layer 220 during deployment. In FIG. 2, an input image 210 is received by the orchestration layer 220 (e.g., the machine learning text analysis system...send an API call 230 to document reader API 250. In one example, the document reader API 250 is published as a microserver, such as (but not limited to) on a Tornado™ server. The document reader API 250 can perform a sequence of steps to extract table context 240, including image-preprocessing, text extraction, table extraction and segmentation...)
the API execution engine runs on a graphic processing unit (GPU)-based worker node and (Chatzistamatiou, see paragraph 0084 The processor...a graphics processing unit (GPU); see paragraph 0035 where incorporated in an Application Programming Interface (API) service, which can be called by an orchestration layer 220 during deployment. In FIG. 2,…)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh and Chatzistamatiou to provide the technique of the APIs comprise APIs for artificial intelligence (AI)-based character recognition, AI-based text analysis, and AI-based image analysis functions and the API execution engine runs on a graphic processing unit (GPU)-based worker node of Chatzistamatiou in the system of Shtarbev-MacCarthaigh in order to improve accuracy of and verification data and allow the system to be more robust to noisy, imprecise, or incomplete data (Chatzistamatiou, see paragraph 0082).
Regarding claim 16, Shtarbev-MacCarthaigh teaches wherein the cloud management console issues authentication information for a plurality of APIs comprising the specific API, and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
wherein the specific API is an API for a data analysis function, and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
However, Shtarbev-MacCarthaigh does not explicitly teach the APIs comprise APIs for AI-based character recognition, AI-based text analysis and AI-based image analysis functions and
the API execution engine runs on a GPU-based worker node.
Chatzistamatiou teaches the APIs comprise APIs for AI-based character recognition, AI-based text analysis and AI-based image analysis functions and (Chatzistamatiou, see paragraph 0035 where incorporated in an Application Programming Interface (API) service, which can be called by an orchestration layer 220 during deployment. In FIG. 2, an input image 210 is received by the orchestration layer 220 (e.g., the machine learning text analysis system...send an API call 230 to document reader API 250. In one example, the document reader API 250 is published as a microserver, such as (but not limited to) on a Tornado™ server. The document reader API 250 can perform a sequence of steps to extract table context 240, including image-preprocessing, text extraction, table extraction and segmentation...)
the API execution engine runs on a GPU-based worker node. (Chatzistamatiou, see paragraph 0084 The processor...a graphics processing unit (GPU); see paragraph 0035 where incorporated in an Application Programming Interface (API) service, which can be called by an orchestration layer 220 during deployment. In FIG. 2,…)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh and Chatzistamatiou to provide the technique of the APIs comprise APIs for artificial intelligence (AI)-based character recognition, AI-based text analysis, and AI-based image analysis functions and the API execution engine runs on a graphic processing unit (GPU)-based worker node of Chatzistamatiou in the system of Shtarbev-MacCarthaigh in order to improve accuracy of and verification data and allow the system to be more robust to noisy, imprecise, or incomplete data (Chatzistamatiou, see paragraph 0082).
Regarding claim 18, Shtarbev-MacCarthaigh teaches wherein the API service manager runs on a Central Processing Unit (CPU) worker node, and (Shtarbev, see figs. 1 and 2; see paragraph 0026 embodiments described herein may be implemented...one or more central processing units (CPUs) 260, system memory (e.g., random access memory (RAM) 262), one or more network interface controllers (NICs) 264, and optionally local storage 263. CPUs 260 are configured to execute instructions, for example, executable instructions that perform one or more operations described herein,...)
However, Shtarbev-MacCarthaigh does not explicitly teach the API execution engine runs on a Graphic Processing Unit (GPU) worker node.
Chatzistamatiou teaches the API execution engine runs on a Graphic Processing Unit (GPU) worker node. (Chatzistamatiou, see paragraph 0084 The processor...a graphics processing unit (GPU); see paragraph 0035 where incorporated in an Application Programming Interface (API) service, which can be called by an orchestration layer 220 during deployment. In FIG. 2,…)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh and Chatzistamatiou to provide the technique of the API execution engine runs on a Graphic Processing Unit (GPU) worker node of Chatzistamatiou in the system of Shtarbev-MacCarthaigh in order to improve accuracy of and verification data and allow the system to be more robust to noisy, imprecise, or incomplete data (Chatzistamatiou, see paragraph 0082).
Claims 20 rejected under 35 U.S.C. 103 as being unpatentable over Shtarbev-MacCarthaigh-Chatzistamatiou in view of Wang (CN 110502340, see the English translated copy).
Regarding claim 20, Shtarbev-MacCarthaigh-Chatzistamatiou teaches all of the features of claim 2. However, Shtarbev-MacCarthaigh-Chatzistamatiou does not explicitly teach wherein the system is configured to perform auto- scaling to increase or decrease a number of the GPU-based worker nodes based on resource usage of the GPU-based worker nodes.
Wang teaches wherein the system is configured to perform auto- scaling to increase or decrease a number of the GPU-based worker nodes based on resource usage of the GPU-based worker nodes. (Wang, see page 5, paragraphs 4-6 to shorten training time, can increase resource...in detecting the target training task of current resource usage information, GPU utilization is too high, is more than 90%, and there is idle GPU resources in cluster information of idle resource, then can increase the CPU number of the target training task, the resource use condition if the adjusted front is 1GPU, 1 CPU, 2G memory, the generated adjusting information is increasing the adjusting information of 1 GPU, the resource use condition after adjustment is 2GPU, 1CPU, 2G memory...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh-Chatzistamatiou and Wang to provide the technique of performing auto- scaling to increase or decrease a number of the GPU-based worker nodes based on resource usage of the GPU-based worker nodes of Wang in the system of Shtarbev-MacCarthaigh-Chatzistamatiou in order to shorten processing time (Wang, see page 5, paragraphs 4-5).
Claims 6-7 and 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Shtarbev-MacCarthaigh in view of Seetharaman et al. (U.S. PGPub 20210/406102).
Regarding claim 6, Shtarbev-MacCarthaigh teaches all of the features of claim 5. However, Shtarbev-MacCarthaigh does not explicitly teach wherein the job manager comprises: a job management module creating a job for the specific API and issuing an ID of the job; and
a job status check module checking a processing status of the job using a polling method by using the ID of the job.
Seetharaman teaches wherein the job manager comprises: a job management module creating a job for the specific API and issuing an ID of the job; and (Seetharaman, see figs. 3 and 6; see paragraph 0038 an API call in the form of an HTTP “POST” command. That request is received by API gateway... API gateway 410 transmits a job ID for a job, e.g., job J1, to be added to the job queue. Asynchronizer bus 420C adds job J1 to the job queue, and notifies API gateway 410 that the job ID has been added to the job queue...; see paragraphs 0007-0008 a job request as an API call, which is shown in FIG. 3 ... sent a request for a job update, as an API call, e.g., HTTP GET command, to the API gateway...forwards the “pending” status to the API gateway)
a job status check module checking a processing status of the job using a polling method by using the ID of the job. (Seetharaman, see figs. 3 and 6; see paragraph 0038 an API call in the form of an HTTP “POST” command. That request is received by API gateway... API gateway 410 transmits a job ID for a job, e.g., job J1, to be added to the job queue. Asynchronizer bus 420C adds job J1 to the job queue, and notifies API gateway 410 that the job ID has been added to the job queue...; see paragraphs 0007-0008 a job request as an API call, which is shown in FIG. 3 ... sent a request for a job update, as an API call, e.g., HTTP GET command, to the API gateway...forwards the “pending” status to the API gateway)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh and Seetharaman to provide the technique of the job manager comprises: a job management module creating a job for the specific API and issuing an ID of the job and a job status check module checking a processing status of the job using a polling method by using the ID of the job of Seetharaman in the system of Shtarbev-MacCarthaigh in order to provide quick responses to a user with respect to a job that they submitted (Seetharaman, see paragraph 0047).
Regarding claim 7, Shtarbev-MacCarthaigh-Seetharaman teaches wherein the job management module receives the result of executing the specific API from the API execution request module, stores the execution result in a database and updates the processing status of the job to a completed status, and (Seetharaman, see figs. 3 and 6; see paragraph 0038 an API call in the form of an HTTP “POST” command. That request is received by API gateway... API gateway 410 transmits a job ID for a job, e.g., job J1, to be added to the job queue. Asynchronizer bus 420C adds job J1 to the job queue, and notifies API gateway 410 that the job ID has been added to the job queue...; see paragraphs 0007-0008 a job request as an API call, which is shown in FIG. 3 ... sent a request for a job update, as an API call, e.g., HTTP GET command, to the API gateway...forwards the “pending” status to the API gateway)
the job status check module obtains the execution result from the database if the processing status of the job is the completed status and sends the execution result to the user’s terminal. (Seetharaman, see figs. 3 and 6; see paragraph 0038 an API call in the form of an HTTP “POST” command. That request is received by API gateway... API gateway 410 transmits a job ID for a job, e.g., job J1, to be added to the job queue. Asynchronizer bus 420C adds job J1 to the job queue, and notifies API gateway 410 that the job ID has been added to the job queue...; see paragraphs 0007-0008 a job request as an API call, which is shown in FIG. 3 ... sent a request for a job update, as an API call, e.g., HTTP GET command, to the API gateway...forwards the “pending” status to the API gateway) The motivation regarding to the obviousness to claim 6 is also applied to claim 7.
Regarding claim 11, Shtarbev-MacCarthaigh teaches wherein the API service manager comprises: an API authentication interworking module performing the authentication by interworking with the control plane; (Shtarbev, see fig. 1; see paragraph 0022 authentication of access to cloud platform 12 through UI 11 or through an API call made to one of the cloud services via API gateway 15...API calls made to the cloud services via API gateway 15 are authenticated if they contain CSP access tokens issued by CSP ID service 110... if the request contains valid credentials...; see paragraph 0033 implements an orchestration control plane, such as Kubernetes®,...)
a job manager creating a job for the specific API based on the call message; and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...)
an API execution request module requesting the API execution engine to execute the specific API in order to process the job, (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...)
However, Shtarbev-MacCarthaigh does not explicitly teach wherein if the specific API is an asynchronous API, the job manager sends an ID of the job to the user’s terminal before the job is processed.
Seetharaman teaches wherein if the specific API is an asynchronous API, the job manager sends an ID of the job to the user’s terminal before the job is processed. (Seetharaman, see figs. 3 and 6; see paragraph 0038 an API call in the form of an HTTP “POST” command. That request is received by API gateway... API gateway 410 transmits a job ID for a job, e.g., job J1, to be added to the job queue. Asynchronizer bus 420C adds job J1 to the job queue, and notifies API gateway 410 that the job ID has been added to the job queue...; see paragraphs 0007-0008 a job request as an API call, which is shown in FIG. 3 ... sent a request for a job update, as an API call, e.g., HTTP GET command, to the API gateway...forwards the “pending” status to the API gateway)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh and Seetharaman to provide the technique of if the specific API is an asynchronous API, the job manager sends an ID of the job to the user’s terminal before the job is processed of Seetharaman in the system of Shtarbev-MacCarthaigh in order to provide quick responses to a user with respect to a job that they submitted (Seetharaman, see paragraph 00047).
Regarding claim 12, Shtarbev-MacCarthaigh-Seetharaman teaches wherein the job manager receives the result of executing the specific API from the API execution request module and uploads the execution result to storage accessible by the user’s terminal. (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
Regarding claim 13, Shtarbev-MacCarthaigh-Seetharaman teaches wherein the API authentication interworking module receives a query request comprising the ID of the job and the authentication information for the specific API, authenticates a requestor using the authentication information in the query request and provides a query result for the ID of the job to the requestor if the requestor is authenticated, and (Seetharaman, see figs. 3 and 6; see paragraph 0038 an API call in the form of an HTTP “POST” command. That request is received by API gateway... API gateway 410 transmits a job ID for a job, e.g., job J1, to be added to the job queue. Asynchronizer bus 420C adds job J1 to the job queue, and notifies API gateway 410 that the job ID has been added to the job queue...; see paragraphs 0007-0008 a job request as an API call, which is shown in FIG. 3 ... sent a request for a job update, as an API call, e.g., HTTP GET command, to the API gateway...forwards the “pending” status to the API gateway) The motivation regarding to the obviousness to claim 11 is also applied to claim 13.
the query result comprises processing status information of the job or the result of executing the specific API. (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Shtarbev-MacCarthaigh in view of Jensen et al. (U.S. PGPub 2007/0294695).
Regarding claim 9, Shtarbev-MacCarthaigh teaches wherein the specific API is an API for a data analysis function, and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
However, Shtarbev-MacCarthaigh does not explicitly teach the API execution request module verifies the job based on at least one of a size, extension and filename of an analysis data file and processes the job by separating the job into tasks if the job is valid.
Jensen teaches the API execution request module verifies the job based on at least one of a size, extension and filename of an analysis data file and processes the job by separating the job into tasks if the job is valid. (Jensen, see fig. 3; see paragraph 0041 computing job is divided into micro-jobs. The micro-jobs are of a size such that execution of the micro-jobs utilizes a sufficiently small amount of resources so as to not significantly impact performance of other jobs in the computer system... API calls to the MJS that request permission to execute a micro-job; see paragraph 0026)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh and Jensen to provide the technique of the API execution request module verifies the job based on at least one of a size, extension and filename of an analysis data file and processes the job by separating the job into tasks if the job is valid of Jensen in the system of Shtarbev-MacCarthaigh in order to avoid significantly impacting the performance of other applications and jobs (Jensen, see paragraph 0001).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Shtarbev-MacCarthaigh in view of Kunimatsu et al. (U.S. PGPub 2020/0257479).
Regarding claim 10, Shtarbev-MacCarthaigh teaches wherein the specific API is an API for a data analysis function, and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.)
However, Shtarbev-MacCarthaigh does not explicitly teach the API execution request module separates the job into the tasks based on the number of files or pages of analysis data.
Kunimatsu teaches the API execution request module separates the job into the tasks based on the number of files or pages of analysis data. (Kunimatsu, see fig. 5; see paragraph 0068 generates the first divided print job and the second divided print job based on the print parameters and the print data (S11)... amount of the first divided print job which uses the first port to 50% of a printing amount of the original print job, and sets a printing amount of the second divided print job which uses the second port to 50% of the printing amount of the original print job....the print data and if the set number is more than two (i.e., two or more copies are required by the print parameters or the command), the supporting program 42 divides the number of copies in to a first number of copies and a second number of copies such that they becomes 50% of the number of copies of the original print job...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh and Kunimatsu to provide the technique of the API execution request module separates the job into the tasks based on the number of files or pages of analysis data of Kunimatsu in the system of Shtarbev-MacCarthaigh in order to complete the job faster (Kunimatsu, see paragraph 0049).
Claims 14 is rejected under 35 U.S.C. 103 as being unpatentable over Shtarbev-MacCarthaigh in view of Ramakrishna et al. (U.S. PGPub 2008/0098465) further in view of Alrabady et al. (U.S. PGPub 2014/0075517).
Regarding claim 14, Shtarbev-MacCarthaigh teaches the demo management console obtains the result of executing the selected API by requesting the API service manager for the result of executing, and (Shtarbev, see figs. 1-2 and 4-5; see paragraph 0023 entitlement service 120 creates a task corresponding to the entitlement command and makes an API call to task service 130 to perform the task (“entitlement task”). Task service 130 then schedules the task to be performed with scheduler service 140, which then creates a message containing the task to be performed and inserts the message in a message queue managed by MB service 150...After scheduling the task to be performed with scheduler service 140, task service 130 periodically polls scheduler service 140 for status of the scheduled task.; see paragraph 0024 When the task is completed by the management appliance, entitlement agent 116 invokes an API of scheduler service 140 to report the completion of the task…)
However, Shtarbev-MacCarthaigh does not explicitly teach wherein the cloud management console comprises a demo management console which provides, on a trial basis, the result of executing an API selected by a specific user from the APIs,
Ramakrishna teaches wherein the cloud management console comprises a demo management console which provides, on a trial basis, the result of executing an API selected by a specific user from the APIs, (Ramakrishna, see paragraph 0058 validation module for the application with the JVM, via a Java.TM. Application Programming Interface (API)…indicates a trial version of the application), a license type ("timebased"), and a value ("1daplogin") indicating that a login with LDAP credentials is required to access the application...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh and Ramakrishna to provide the technique of the cloud management console comprises a demo management console which provides, on a trial basis, the result of executing an API selected by a specific user from the APIs of Ramakrishna in the system of Shtarbev-MacCarthaigh in order to provide an incentive for customers to obtain a service or product (Ramakrishna, see paragraph 0003).
However, Shtarbev-MacCarthaigh-Ramakrishna does not explicitly teach the API manager is configured not to require authentication information for an API requested by the demo management console.
Alrabady teaches the API manager is configured not to require authentication information for an API requested by the demo management console. (Alrabady, see abstract by-passing a security code to allow developmental software to be installed on a production controller without having to authenticate the software…; see paragraph 0017 by-passing a security authentification process employed by a production controller for allowing developmental software files to be installed in the controller...)
It would have been obvious to one of ordinary skill in the art, at the time the invention was filed, to combine Shtarbev-MacCarthaigh and Alrabady to provide the technique of the API manager is configured not to require authentication information for an API requested by the demo management console of Alrabady in the system of Shtarbev-MacCarthaigh in order to allow for product development in a more easy, cost effective and friendly manner (Alrabady, see paragraph 0027).
Conclusion
Applicant's 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MENG VANG whose telephone number is (571)270-7023. The examiner can normally be reached M-F 8AM-2PM, 3PM-5PM.
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, NICHOLAS TAYLOR can be reached at (571) 272-3889. 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.
/MENG VANG/Primary Examiner, Art Unit 2443
Prosecution Insights