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 .
Claims 1 – 20 are pending for examination. Claims 1 – 2, 10 – 12, and 20 are amended.
References were cited in previous office action.
Examiner’s Note
The prior art rejection below cites particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Priority
Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e).
Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
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 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As to claim 1, the claim recites
an automated service arrangement and execution system, comprising:
a storage device, storing a plurality of modules; and:
a processor, coupled to the storage device, executing the plurality of modules, and receiving request data for executing an application programming interface (API), wherein the plurality of modules comprise a data relationship obtaining and parsing module, a calling route planning module, and an execution module,
wherein the data relationship obtaining and parsing module analyzes known data to obtain an attribute field and a data relationship between the attribute field and the API identify respective API object and input structure definitions of a plurality of API objects and API object input parameter and data source relationships, constructs the plurality of API objects according to the respective API object and input structure definitions of the plurality of API objects and the API object input parameter and data source relationships to create a calling model according to the request data, comprising a plurality of API objects and the API,
wherein the calling route planning module establishes a calling path according to the plurality of API objects and relationship information between a respective plurality of input data of the API and a plurality of input data sources,
wherein the execution module executes the plurality of API objects and the API in the calling model according to the calling path, so as to generate an execution result of the API,
wherein the execution result of the API is business data used for business operation.
Step 1: the claim is directed to a system which is one of the statutory categories of invention.
Step 2A:
Prong 1: the limitations of “wherein the data relationship obtaining and parsing module analyzes known data to obtain an attribute field and a data relationship between the attribute field and the API identify respective API object and input structure definitions of a plurality of API objects and API object input parameter and data source relationships, constructs the plurality of API objects according to the respective API object and input structure definitions of the plurality of API objects and the API object input parameter and data source relationships to create a calling model according to the request data, comprising a plurality of API objects and the API,
wherein the calling route planning module establishes a calling path according to the plurality of API objects and relationship information between a respective plurality of input data of the API and a plurality of input data sources” are functions that can be reasonably carried out in the human mind with the aid of pen and paper.
Prong 2:
The additional elements of storage device, storing a plurality of modules; and:
a processor merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea
The additional elements an automated service arrangement and execution system, coupled to the storage device, executing the plurality of modules merely link the use of the judicial exception to a particular technological environment or field of use, thus does not integrate the judicial exception into a practical application. MPEP 2106.05(h).
The additional elements receiving request data for executing an application programming interface (API), wherein the plurality of modules comprise a data relationship obtaining and parsing module, a calling route planning module, and an execution module, wherein the execution result of the API is business data used for business operation merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
Thus, these additional elements do not integrate the judicial exception into a practical application.
Step 2B:
The additional elements of storage device, storing a plurality of modules; and:
a processor merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea
The additional elements an automated service arrangement and execution system, coupled to the storage device, executing the plurality of modules merely link the use of the judicial exception to a particular technological environment or field of use, thus does not integrate the judicial exception into a practical application. MPEP 2106.05(h).
The additional elements receiving request data for executing an application programming interface (API), wherein the plurality of modules comprise a data relationship obtaining and parsing module, a calling route planning module, and an execution module, wherein the execution result of the API is business data used for business operation merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
Accordingly, the additional elements do not amount to significantly more than the abstract idea.
As to claim 2, “The automated service arrangement and execution system according to claim 1, wherein the data relationship obtaining and parsing module comprises:
“a request data analysis unit, which analyzes known data to obtain an attribute field, and provides the attribute field to a data relationship management unit with business meaning equivalence to obtain the data relationship between the attribute field and the API.
a data parsing unit, which analyzes the data relationship for executing the API to identify the respective API object and input structure definitions of the plurality of API objects and the API object input parameter and data source relationships; and
an application program execution object builder unit, which constructs the plurality of API objects according to the respective API object and input structure definitions of the plurality of API objects and the API object input parameter and data source relationships” are functions that can be reasonably carried out in the human mind with the aid of pen and paper.
As to claim 3, “The automated service arrangement and execution system according to claim 2, wherein the API object and input structure definitions comprise at least one of an API object name, an API access method, an API access address, an input parameter structure, an input parameter data hierarchy, and an input parameter field name” is mere data gathering which the courts have held to be insignificant extra-solution activity (see MPEP 2106.05(g)).
As to claim 4, “The automated service arrangement and execution system according to claim 2, wherein the API object input parameter and data source relationships comprise at least one of an API object name, a subordinate relationship between an input parameter field and the API object, a name of the input parameter field, a hierarchical description of the input parameter field in an input parameter structure, a field name of data corresponding to the input parameter field in a data source, a data source name, and a hierarchical description in the data source of a field in the data source” is mere data gathering which the courts have held to be insignificant extra-solution activity (see MPEP 2106.05(g)).
As to claim 5, “The automated service arrangement and execution system according to claim 2, wherein the API object and input structure definitions comprise an API name of the API object, an API access method, an API access address, and an API input data structure” is mere data gathering which the courts have held to be insignificant extra-solution activity (see MPEP 2106.05(g)).
As to claim 6, “The automated service arrangement and execution system according to claim 5, wherein the input data structure comprises a hierarchy of the input data, a field name of the input data, and a hierarchical subordinate relationship between fields” is mere data gathering which the courts have held to be insignificant extra-solution activity (see MPEP 2106.05(g)).
As to claim 7, “The automated service arrangement and execution system according to claim 2, wherein the API object input parameter and data source relationships comprise an API name of the API object, a subordinate relationship between an API input data field and the API object, an API input data name, a hierarchical description of the API input data field in an input data structure, a field name of the API input data field in the corresponding input data resource, a name of the input data source, and a hierarchical description in the input data source of a field in the input data source” is mere data gathering which the courts have held to be insignificant extra-solution activity (see MPEP 2106.05(g)).
As to claim 8, “The automated service arrangement and execution system according to claim 1, wherein the calling route planning module comprises:
an input data and input data source relationship builder unit, which establishes relationships between the plurality of API objects and input data field definition objects and relationships between the input data field definition objects and the plurality of input data sources according to the respective API object and input structure definitions of the plurality of API objects and the API object input parameter and data source relationships; and an execution path planning logic unit, which sorts the plurality of input data sources according to a preset rule to establish the calling path” are all functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgement and opinion.
As to claim 9, The automated service arrangement and execution system according to claim 1, wherein the execution module comprises:
“an execution data management unit, which stores the request data, and stores a plurality of output data generated by the plurality of API objects and the API” merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
“an API object execution scheduler unit, which schedules the plurality of API objects according to the calling path;
an API object input data construction unit, which constructs a plurality of input data fields according to the plurality of API objects; and
an API execution agent unit, which initiates calls of the plurality of API objects and the API, and collects the plurality of output data generated by the plurality of API objects and the API” merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 10, “The automated service arrangement and execution system according to claim 1, wherein the plurality of API objects and the API are a plurality of different business APIs” merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 11, this is a method claim of claim 1. See rejection for claim 1 above.
As to claims 12 – 20, see rejection for claims 2 – 10 above.
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, 9 – 17, and 19 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Dirac et al., (US PUB 2015/0379430 hereinafter Dirac) in view of Morton et al., (US PUB 2022/0036437 hereinafter Morton).
As to claim 1, Dirac teaches an automated service arrangement and execution system, comprising:
a storage device (“… storage devices…” para. 0085), storing a plurality of modules (“…machine learning service (MLS) designed to support large numbers of users and a wide variety of algorithms and problem sizes are described. In one embodiment, a number of MLS programmatic interfaces (such as application programming interfaces (APIs)) may be defined by the service,…” para. 0084) and (“…In system 100, the MLS may implement a set of programmatic interfaces 161 (e.g., APIs, command-line tools, web pages, or standalone GUIs) that can be used by clients 164 (e.g., hardware or software entities owned by or assigned to customers of the MLS) to submit requests 111 for a variety of machine learning tasks or operations. The administrative or control plane portion of the MLS may include MLS request handler 180, which accepts the client requests 111 and inserts corresponding job objects into MLS job queue 142…” para. 0092); and
a processor (“…processor 162...” figure1 and para. 0095), coupled to the storage device, executing the plurality of modules and receiving request data for executing an application programming interface (API) (“…In some embodiments, a single API request from a client may lead to the generation of several different job objects by the MLS…” para. 0088), wherein the plurality of modules comprise a data relationship obtaining and parsing module (“…In one embodiment, respective jobs may be generated and placed in an MLS job queue for one or more of the filtering operations. In at least some embodiments, a record parser may be used to obtain the observation records from the output of the sequence of filtering operations performed (element 2522)…” para. 0185) and (“FIG. 1 illustrates an example system environment in which various components of a machine learning service (MLS) may be implemented, according to at least some embodiments. In system 100, the MLS may implement a set of programmatic interfaces 161 (e.g., APIs, command-line tools, web pages, or standalone GUIs) that can be used by clients 164 (e.g., hardware or software entities owned by or assigned to customers of the MLS) to submit requests 111 for a variety of machine learning tasks or operations…” para. 0092), a calling route planning module (“…MLS request handler 180, which accepts the client requests 111 and inserts corresponding job objects into MLS job queue 142, as indicated by arrow 112 …” para. 0092 and figure 1), and an execution module (“...This first portion of the workflow may be initiated in response to a particular API invocation from a client 164, and may be executed…” para. 0095),
wherein the data relationship obtaining and parsing module analyzes known data to obtain an attribute field and a data relationship between the attribute field and the API (“...Some tasks (and the corresponding APIs) may involve multiple different entity types—e.g., an API requesting a creation of a data source may result in the generation of a data source entity instance as well as a statistics entity instance. Some of the tasks of a given workflow may be dependent on the results of other tasks....” para. 0087. The results of other tasks are known data) and (“..In at least one embodiment, a client may indicate, e.g., via parameters included in an API call, various elements or properties of a desired processing plan, and the MLS may take such client preferences into account...” para. 0108) and (“For many types of feature processing transformation operations, such as creating quantile bins for numeric data attributes, generating ngrams, or removing sparse or infrequent words from documents being analyzed, parameters may typically have to be selected, such as the sizes/boundaries of the bins, the lengths of the ngrams, the removal criteria for sparse words, and so on....” para. 0154), identify respective API object (“…In the depicted example, a client has invoked four MLS APIs, API1 through API4, and four corresponding job objects J1 through J4 are created and placed in job queue...” para. 0109) and input structure definitions of a plurality of API objects and API object input parameter (“…Full dependency is indicated in FIG. 5 by the parameter “dependsOnComplete” shown in the job objects—e.g., J2 is dependent on J1 completing execution, and J4 depends on J2 completing successfully. In the other type of dependency, the execution of one job Jp may be started as soon as some specified phase of another job Jq is completed. This latter type of dependency may be termed a “partial dependency”, and is indicated in FIG. 5 by the “dependsOnPartial” parameter....” para. 0110 - 0114) and data source relationships (“...As shown, a data source 1802 from which a client of the machine learning service wishes to extract observation records may comprise a plurality of data objects such as files F1, F2, F3 and F4 in the depicted embodiment....” para. 0161 - 0162), constructs the plurality of API objects (“...In at least some embodiments, a job object may be generated upon receiving the execution request 812 as described earlier, indicating any dependencies on other jobs (such as the execution of a recipe for feature processing), and the job may be placed in a queue...” para. 0126, 0129) according to the respective API object and input structure definitions of the plurality of API objects and the API object input parameter and data source relationships (“..As shown, a client 764 submits a data source creation request 712 to the MLS control plane 780 via an MLS API 761...” para. 0122) to create a calling model according to the request data (“…In some embodiments, a single API request from a client may lead to the generation of several different job objects by the MLS…” para. 0088. Note: job objects is model) and (“…The model execution request may specify the execution mode (batch, online or local), the input data to be used for the model run (which may be produced using a specified data source or recipe in some cases), the type of output (e.g., a prediction or an evaluation) that is desired, and/or optional parameters (such as desired model quality targets, minimum input record group sizes to be used for online predictions, and so on). In response the MLS may generate a plan for model execution and select the appropriate resources to implement the plan. In at least some embodiments, a job object may be generated upon receiving the execution request 812 as described earlier…” para. 0126) comprising the plurality of API objects (“…job objects…” para. 0126) and the API (…a client may indicate, e.g., via parameters included in an API call…” para. 0108),
wherein the calling route planning module establishes a calling path according to the plurality of API objects and relationship information between a respective plurality of input data of the API and a plurality of input data sources (“…In one case, termed “completion dependency”, the execution of one job Jp cannot be started until another job Jq is completed successfully (e.g., because the final output of Jq is required as input for Jp). Full dependency is indicated in FIG. 5 by the parameter “dependsOnComplete” shown in the job objects—e.g., J2 is dependent on J1 completing execution, and J4 depends on J2 completing successfully…” Para. 0110) and (“…As indicated on client timeline TL1, API1 through API4 may be invoked within the time period t0 to t1. Even though some of the operations requested by the client depend on the completion of operations corresponding to earlier-invoked APIs, the MLS may allow the client to submit the dependent operation requests much earlier than the processing of the earlier-invoked APIs' jobs in the depicted embodiment. In at least some embodiments, parameters specified by the client in the API calls may indicate the inter job dependencies. For example, in one implementation, in response to API1, the client may be provided with a job identifier for J1, and that job identifier may be included as a parameter in API2 to indicate that the results of API1 are required to perform the operations corresponding to API2. As indicated by the request handler's timeline TL2, the jobs corresponding to each API call may be created and queued shortly after the API is invoked…” para. 0111. Note: calling path is the API calls parameter which is result of previous API call and it is relationship of input and input source), wherein the execution module executes the plurality of API objects and the API in the calling model according to the calling path, so as to generate an execution result of the API (“…the results of API1 are required to perform the operations corresponding to API2…” para. 0111 - 0112),
wherein the execution result of the API is [business] data used for [business] operation (“..In particular, using text versions of model output, it may be relatively hard for some users to understand the relationships between different quality-related metrics (such as accuracy, false positive rate, false negative rate and the like), and how changing various interpretation-related settings (such as cutoff values or boundaries between classes in the case of classification models) may impact the ultimate business decisions that are made using the model...” para. 0314) and (“...For example, if the negative business consequences of false positive classifications are much higher than the negative business consequences of false negatives, the client may decide that the interpretation threshold(s) for the model should be changed in a direction such that, in general, fewer false positive decisions would be likely to occur. Consider a scenario in which a binary classification model is being used to determine whether a particular customer of an on-line business has attempted a fraudulent transaction...” para. 0330).
Dirac does not but Morton teaches business and business operation (“…Current methods of transacting business between or among a plurality of business entities involve the use of multiple software applications, application programming interfaces (APIs), or integration processes to transfer shared data among the plurality of businesses. Each of these business entities may use a different structure or method for receiving and storing the same type of information, causing each of these multiple applications, APIs, or integration processes to be customized to a particular business or group of businesses among which the same data may be shared…” para. 0020).
It 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 was made to modify Dirac by applying the teachings of Morton because Morton would provide business applications for the system to provide services to users (title, abstract and para. 0101).
As to claim 2, Dirac modified by Morton teaches the automated service arrangement and execution system according to claim 1, Dirac teaches wherein the data relationship obtaining and parsing module comprises:
a request data analysis unit, which analyzes known data to obtain an attribute field (“…A client request 111 may indicate one or more parameters…” para. 0095), and provides the attribute field to a data relationship management unit [with business meaning equivalence] to obtain the data relationship between the attribute field and the API (“…In one case, termed “completion dependency”, the execution of one job Jp cannot be started until another job Jq is completed successfully (e.g., because the final output of Jq is required as input for Jp). Full dependency is indicated in FIG. 5 by the parameter “dependsOnComplete” shown in the job objects—e.g., J2 is dependent on J1 completing execution, and J4 depends on J2 completing successfully…” Para. 0110. Note: calling path is shown in API call’s parameter is output of previous API call/input data source and used as input data of the API call);
a data parsing unit, which analyzes the data relationship for executing the API to identify respective API object and input structure definitions of the plurality of API objects and API object input parameter and data source relationships (“…analyzing the input data, recipes…” Para. 0086); and
an application program execution object builder unit, which constructs the plurality of API objects according to the respective API object and input structure definitions of the plurality of API objects and the API object input parameter and data source relationships (“The MLS programmatic interfaces may enable users to submit respective requests for several related tasks of a given machine learning workflow, such as tasks for extracting records from data sources, generating statistics on the records, feature processing, model training, prediction, and so on. A given invocation of a programmatic interface (such as an API) may correspond to a request for one or more operations or tasks on one or more instances of a supported type of entity. Some tasks (and the corresponding APIs) may involve multiple different entity types—e.g., an API requesting a creation of a data source may result in the generation of a data source entity instance as well as a statistics entity instance. Some of the tasks of a given workflow may be dependent on the results of other tasks…” para. 0087).
Dirac does not but Morton teaches with business meaning equivalence (“…The data marketplace that is being queried may provide APIs that allow a user to request say the top searches over the past period of time in an example embodiment…” para. 0101).
It 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 was made to modify Dirac by applying the teachings of Morton because Morton would provide business applications for the system to provide services to users (title, abstract and para. 0101).
As to claim 3, Dirac modified by Morton teaches The automated service arrangement and execution system according to claim 2, Dirac teaches wherein the API object and input structure definitions comprise at least one of an API object name, an API access method, an API access address, an input parameter structure (“…, MLS job queue 142 comprises five jobs, each corresponding to the invocation of a respective API by a client. Job J1 (shown at the head of the queue) was created in response to an invocation of API1. Jobs J2 through J5 were created respectively in response to invocations of API2 through API5. Corresponding to job J1, an input data cleansing plan 422 may be generated, and the plan may be executed using resource set RS1. The input data cleansing plan may include operations to read and validate the contents of a specified data source, fill in missing values, identify and discard (or otherwise respond to) input records containing errors, and so on. In some cases the input data may also have to be decompressed, decrypted, or otherwise manipulated before it can be read for cleansing purposes…” para. 0107), an input parameter data hierarchy, and an input parameter field name.
As to claim 4, Dirac modified by Morton teaches The automated service arrangement and execution system according to claim 2, Dirac teaches wherein the API object input parameter and data source relationships comprise at least one of an API object name, a subordinate relationship between an input parameter field and the API object (“…In one case, termed “completion dependency”, the execution of one job Jp cannot be started until another job Jq is completed successfully (e.g., because the final output of Jq is required as input for Jp). Full dependency is indicated in FIG. 5 by the parameter “dependsOnComplete” shown in the job objects—e.g., J2 is dependent on J1 completing execution, and J4 depends on J2 completing successfully…” Para. 0110. Note: calling path is shown in API call’s parameter is output of previous API call/input data source and used as input data of the API call), a name of the input parameter field, a hierarchical description of the input parameter field in an input parameter structure, a field name of data corresponding to the input parameter field in a data source, a data source name, and a hierarchical description in the data source of a field in the data source (only need to meet one condition).
As to claim 5, this claim recites similar scope of claim 3. See rejection for claim 3 above.
As to claim 6, Dirac modified by Morton teaches The automated service arrangement and execution system according to claim 5, Dirac teaches wherein the input data structure comprises a hierarchy of the input data (“…In one case, termed “completion dependency”, the execution of one job Jp cannot be started until another job Jq is completed successfully (e.g., because the final output of Jq is required as input for Jp). Full dependency is indicated in FIG. 5 by the parameter “dependsOnComplete” shown in the job objects—e.g., J2 is dependent on J1 completing execution, and J4 depends on J2 completing successfully…” Para. 0110. Note: calling path is shown in API call’s parameter is output of previous API call/input data source and used as input data of the API call), a field name of the input data, and a hierarchical subordinate relationship between fields.
As to claim 7, Dirac modified by Morton teaches The automated service arrangement and execution system according to claim 2, Dirac teaches wherein the API object input parameter and data source relationships comprise an API name of the API object, a subordinate relationship between an API input data field and the API object, an API input data name, a hierarchical description of the API input data field in an input data structure (“…In one case, termed “completion dependency”, the execution of one job Jp cannot be started until another job Jq is completed successfully (e.g., because the final output of Jq is required as input for Jp). Full dependency is indicated in FIG. 5 by the parameter “dependsOnComplete” shown in the job objects—e.g., J2 is dependent on J1 completing execution, and J4 depends on J2 completing successfully…” Para. 0110. Note: calling path is shown in API call’s parameter is output of previous API call/input data source and used as input data of the API call), a field name of the API input data field in the corresponding input data resource, a name of the input data source, and a hierarchical description in the input data source of a field in the input data source.
As to claim 9, Dirac modified by Morton teaches The automated service arrangement and execution system according to claim 1, Dirac teaches wherein the execution module comprises:
an execution data management unit, which stores the request data, and stores a plurality of output data generated by the plurality of API objects and the API (“…storage of the input data used for client-requested operations, as well as the processing, transfer and storage of output data produced as a result of client-requested operations…” para. 0085);
an API object execution scheduler unit, which schedules the plurality of API objects according to the calling path (“…an asynchronous approach may be taken to scheduling the tasks, in which MLS clients can submit additional tasks that depend on the output of earlier-submitted tasks without waiting for the earlier-submitted tasks to complete. For example, a client may submit respective requests for tasks T2 and T3 before an earlier-submitted task T1 completes, even though the execution of T2 depends at least partly on the results of T1, and the execution of T3 depends at least partly on the results of T2…” para. 0087);
an API object input data construction unit, which constructs a plurality of input data fields according to the plurality of API objects (“… The model developers may continue to experiment with various algorithms, parameters and/or input data sets to obtain improved versions of the underlying model…” para. 0090) and (“A client request 111 may indicate one or more parameters…” para. 0095); and
an API execution agent unit, which initiates calls of the plurality of API objects and the API, and collects the plurality of output data generated by the plurality of API objects and the API (“The MLS programmatic interfaces may enable users to submit respective requests for several related tasks of a given machine learning workflow, such as tasks for extracting records from data sources, generating statistics on the records, feature processing, model training, prediction, and so on. A given invocation of a programmatic interface (such as an API) may correspond to a request for one or more operations or tasks on one or more instances of a supported type of entity. Some tasks (and the corresponding APIs) may involve multiple different entity types—e.g., an API requesting a creation of a data source may result in the generation of a data source entity instance as well as a statistics entity instance…” para. 0087).
As to claim 10, Dirac modified by Morton teaches The automated service arrangement and execution system according to claim 1, Dirac teaches wherein the plurality of API objects and the API are a plurality of different [business] APIs (“…In some embodiments, a given job object may represent the operations to be performed as a result of a client's invocation of a particular programmatic interface, as well as dependencies on other jobs…” para. 0088).
Dirac does not but Morton teaches business (“…Current methods of transacting business between or among a plurality of business entities involve the use of multiple software applications, application programming interfaces (APIs), or integration processes to transfer shared data among the plurality of businesses. Each of these business entities may use a different structure or method for receiving and storing the same type of information, causing each of these multiple applications, APIs, or integration processes to be customized to a particular business or group of businesses among which the same data may be shared…” para. 0020).
As to claim 11, this is an automated service arrangement and execution method of claim 1. See rejection for claim 1 above.
As to claims 12 - 17, these claims recite similar scope of claims 2 - 7. See rejection for claims 2 - 7 above.
As to claim 19, this claim recites similar scope of claim 9. See rejection for claim 9 above.
As to claim 20, these claims recite similar scope of claim 10. See rejection for claim 10 above.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Dirac in view of Morton, and further in view of Farmaner et al., (US PUB 2013/0246392 hereinafter Farmaner).
As to claim 8, Dirac and Morton teaches the automated service arrangement and execution system according to claim 1, wherein the calling route planning module comprises: Dirac teaches
an input data and input data source relationship builder unit, which establishes relationships between the plurality of API objects and input data field definition objects and relationships between the input data field definition objects and the plurality of input data sources according to the respective API object and input structure definitions of the plurality of API objects and the API object input parameter and data source relationships (“…the MLS may allow the client to submit the dependent operation requests much earlier than the processing of the earlier-invoked APIs' jobs in the depicted embodiment. In at least some embodiments, parameters specified by the client in the API calls may indicate the inter job dependencies. For example, in one implementation, in response to API1, the client may be provided with a job identifier for J1, and that job identifier may be included as a parameter in API2 to indicate that the results of API1 are required to perform the operations corresponding to API2…” para. 0111); and
an execution path planning logic unit, [which sorts the plurality of input data sources according to a preset rule] to establish the calling path (“…an API requesting a creation of a data source may result in the generation of a data source entity instance as well as a statistics entity instance. Some of the tasks of a given workflow may be dependent on the results of other tasks…” para. 0087).
Dirac and Morton do not but Farmaner teaches which sorts the plurality of input data sources according to a preset rule (“…The orders the Genres appear in the user input versus the matching condition definition are not important, nor are the presence of intervening other Genres or keywords. Hence, a single rule can be written to handle both these user inputs:” para. 0074).
It 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 was made to modify Dirac and Morton by applying the teachings of Morley would provide rule to present input data as designed (para. 0074).
As to claim 18, this claim recites similar scope of claim 8. See rejection for claim 8 above.
Response to Arguments
Discussion of Claim Rejections under 35 U.S.C. 101
Applicant's arguments, regarding to 101 rejection have been fully considered but they are not persuasive.
Applicant argued
“ Independent claims I and 11 are directed to an automated system and method for arranging and executing API services. The system includes several modules that: (1) analyze known data to extract attribute fields and relationships with APIs, (2) identify and construct API objects based on input structures and data source dependencies, and (3) generate a calling model that includes the API objects and the requested API. A calling route planning module then establishes an execution path based on how input data is related, and an execution module carries out the API calls according to this path. The end result is business data that can be used for enterprise operations.
It is respectfully submitted that the steps of (i) analyzing known data to extract attribute fields and their relationships with APIs, (ii) identifying and constructing API objects using defined input structures and parameter-source mappings, (iii) building a calling model of API objects and the API, and (iv) planning the execution path based on input relationships, are not the types of functions that can reasonably be carried out by the human mind, even with pen and paper. These are structured, machine-implemented processes operating on complex interrelated data across APIs. Therefore, the features recited in claims 1 and 11 do not fall under the abstract idea category of Mental Processes.
Furthermore, Applicant respectfully submits that the claimed invention is integrated to a practical application.
In traditional systems, a common situation is that before the system calls the specific API, the system needs to construct the input data of the specific API. However, the input data of the specific API is actually the output results generated by the sequential execution of another or other APIs. Therefore, if the another API has not been executed to generate the output result, the specific API also cannot generate the desired output result. (Paragraph [0002] of as-filed application).
The claimed invention (i.e., claims 1 and 11) overcomes this by automating the entire process: the system analyzes known data to identify API object definitions and parameter relationships, constructs a calling model, determines a calling path, and then automatically executes the relevant API objects and the API to produce business data. This approach avoids static, hardcoded orchestration and instead enables data-driven, dynamic API execution. The improvement lies in enabling automated, structured service composition based on input-output data relationships, thereby improving the efficiency and flexibility of API execution to generate the execution result of the API. This constitutes a concrete technological improvement in how enterprise systems manage and execute API-based workflows. It is respectfully submitted that the improvement in the technical fields is indications of integration to a practical application.
For at least the above rationales, withdrawal of the rejections under 35 U.S.C. 101 is respectfully requested.” (pages 10 - 12 of remark).
In response,
As pointing out in the rejection above, elements analyzing, identifying, building a calling model, planning are abstract idea since they can be implemented by human being with aid of pen and paper. The execution to get known data is the additional element merely link the use of the judicial exception to a particular technological environment or field of use, thus does not integrate the judicial exception into a practical application. Therefore, the claim 1 recite abstract idea.
Discussion of Claim Rejections tinder 35 U.S.C. 102 and 35 U.S.C. 103
Applicant’s arguments, with respect to the rejections of under 102 and 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of . Dirac and Morton do not but Farmaner.
Claims 1, 9. 11 and 19 are rejected under 35 U S.C. 102(a)f1) as being anticipated by Dirac.
Claims 2 7, 10, 12 I 7 and 20 are rejected under 35 U S.C. 103 as being unpatentable over Dirac in view of Morton.
Claims 8 and 18 are rejected under 35 U S. C. 103 as being unpatentable over Dirac in view of Farmaner.
Applicant argued
Regarding independent claim 1, Applicant respectfully submits that Dirac does not anticipate the features of "wherein the data relationship obtaining and parsing module analyzes known data to obtain an at field and a data relationship between the attribute field and the API, identify respective API object and input structure definitions of a plurality of API objects and API object input parameter and data source relationships, constructs the plurality of AI objects according to the respective API object and input structure definitions of the plurality of.A PJ objects and the APJ object input parameter and data source relationships to create a calling model according to the request data comprising the plurality of API objects and the AP wherein the calling route planning module establishes a calling path according to the plurality of API objects and relationship information between a respective plurality of input data of the API and a plurality of input data sources, wherein to execution module executes the plurality of API objects ani the API in the calling model according to the calling path, so as to generate an execution result of the API" in claim 1. Applicant respectfully traverse the grounds of rejections for the following reasons.
Referring to Dirac's paragraphs [0088], [0108], [0110]-[0112], [0126] and Fig. 5, which were cited on pages 12-14 of the OA, Dirac a Machine Learning Service (MLS) system that converts incoming API calls into "job objects" representing machine learning (ML) tasks. These job objects include metadata such as input data locations, task dependencies (e.g. for JO to finish"), and operations to be performed (e.g., "remove null values"). The MILS schedules and executes these job objects in dependency order and stores the resulting outputs in an artifact repository.
Hoverer, these job objects are domain-specific constructs tied exclusively to internal ML workflows. They do not exhibit the structural or functional characteristics of the claimed APl objects. Specifically, Dirac's job objects are not constructed based on parsing structured relationships between external API inputs and data sources. Instead, they represent predefined ML operations managed internally within the MILS environment. As such, they are not equivalent to the API objects recited in the claims, which are explicitly constructed by analyzing attribute fields and identifying input structure definitions and data source relationships.
The dependencies described in Dirac are confined to internal ML job execution - that is, where one job depends on the output of another. There is no teaching or suggestion of dependencies or structured relationships among external API calls or between API objects, as required by the claimed calling model.
Moreover, although paragraph [0087] notes that the system permits submission of ML- related tasks that may depend on results of earlier tasks, this functionality pertains strictly to internal ML job requests, not to the construction of APl objects or analysis of structured relationships among APIs. Claim 1 recites generating a calling model composed of multiple API objects and the API, based on known data relationships, input parameter mapping, and data source relationships - none of which are disclosed or suggested in Dirac.
The dependencies in Dirac are limited to internal NIL jobs, and there is no teaching or suggestion of dependencies or structured relationships among API objects or between calls to external APIs. The system in Dirac does not construct or execute a calling model of API objects as recited in claim 1. As such, Dirac fails to disclose the above-mentioned features of claim 1. Withdrawal of claim rejection under 35 U S.C. 102(a)(1) to claim 1 is respectfully requested.
The dependencies described in Dirac are confined to internal ML job execution - that is, where one job depends on the output of another. There is no teaching or suggestion of dependencies or structured relationships among external API calls or between API objects, as required by the claimed calling model.
Moreover, although paragraph [0087] notes that the system permits submission of ML- related tasks that may depend on results of earlier tasks, this functionality pertains strictly to internal ML job requests, not to the construction of APl objects or analysis of structured relationships among APIs. Claim 1 recites generating a calling model composed of multiple API objects and the API, based on known data relationships, input parameter mapping, and data source relationships - none of which are disclosed or suggested in Dirac.
The dependencies in Dirac are limited to internal NIL jobs, and there is no teaching or suggestion of dependencies or structured relationships among API objects or between calls to external APIs. The system in Dirac does not construct or execute a calling model of API objects as recited in claim 1. As such, Dirac fails to disclose the above-mentioned features of claim 1. Withdrawal of claim rejection under 35 U S.C. 102(a)(1) to claim 1 is respectfully requested” (page of remark)
In response,
Amended claim 1 is taught by Dirac in view of Morton. Dirac teaches API requests with parameters indicating relationships of dependencies between data, data source, structure, etc. to create a model as rejected above. The data is results of execution of previous tasks and so, data is known data (para. 0109 – 0114, 0126, etc.).
Morton teaches data is business data. The parsing is just a basic programming technique to read code and/or software instructions. API requests are from clients 164 of figures 1 - 2 and associated text and additional para. as cited in the rejection. The API requests have to be read and/or to extract to be executed (para. 0095, 0127).
Note: amended claim 1 does not recite external API calls as argued.
Therefore, Dirac and Morton teaches amended claim 1.
Applicant argued
“Regarding independent claim 11, for the same reasons set forth above for traversal of claim 1, the independent claim 11 overcomes the rejections of the Office”.
In response,
Independent claim 11 recites similar scope of claim 1. Examiner refers response for claim 1 above.
Applicant argued
“Regarding claims 2-10 and 12-20, since these dependent claims contain all features of the as-amended claims 1 and 11 and other cited references do not cure the deficiencies of Dirac as presented above, these claims overcome the obviousness of rejections under 35 U.S.C. 103 in the Office Action as a matter of law.“ (page of remark)
In response,
Dependent claims 2-10 and 12-20 are rejected as to their independent claims.
Conclusion
The prior art made of record but not relied upon request is considered to be pertinent to applicant’s disclosure.
Mire, (US PUB 2021/0319028), discloses a method for sending and receiving content to and/or servers by making API calls (title, abstract and figures 1 – 18).
Brincho, (US PUB 2022/0245468), discloses a method for generating the module collection include receiving input data to build artifact files based on the input and the relationship between fields (title, abstract and figures 1 – 11).
Mondal, (US PUB 2021/0064667), discloses a method for obtaining a plurality of natural language input requests from one or more source to create a list of a plurality of determined states required to generate a dependency order, structured natural language response (title, abstract and figures 1 – 8).
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 PHUONG N HOANG whose telephone number is (571)272-3763. The examiner can normally be reached 9:5-30.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/PHUONG N HOANG/ Examiner, Art Unit 2194 KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights