DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Applicant’s Amendment and Remarks filed on 29 June 2026.
Claims 1-15 are pending for examination.
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-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1, Statutory Category: Yes, the claim 1 is a computer-implemented method for automatically generating a representational state transfer, REST, application programming interface, API, specification based on a plain-text user story that recites a series of steps and therefore falls in the statutory category of a process.
Step 2A- Prong 1: Judicial Exception Recited: Yes, the claim recites: “b) identifying a number of nouns and a number of verbs in the received plain-text user story; c) matching the identified number of verbs to one of a plurality of Hyper Text Transfer Protocol (HTTP) methods; d) matching the number of identified nouns to a number of HTTP)resources; e) building a REST path using the matched HTTP method and the number of matched HTTP resources; and f) generating a REST API specification that comprises at least the built REST path.”. As drafted, the claim as a whole recites a method including steps that could be performed in the human mind, but for the recitation of generic computing components. The human mind can easily judging/evaluating/identifying a number of nouns and a number of verbs in the received plain-text user story, determining/comparing/matching the identified number of verbs to one of a plurality of HTTP methods; determining/comparing/matching the number of identified nouns to a number of HTTP resources, creating/building/generating (i.e., by pen and paper) a REST path using the matched HTTP method and the number of matched HTTP resources; and creating/building/generating (by pen and paper) a REST API specification that comprises at least the built REST path.” Therefore, but for the recitation of generic computing components, these steps may be a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion).
Therefore, yes, the claims do recite judicial exceptions.
Step 2A- Prong 2: Integrated into a practical Application: No, this judicial exception is not integrated into a practical application. In particular, the claim recites an additional limitations that “a) receiving, as input, the plain-text user story comprising a number of plain-text sentences that constitute a requirements definition for an API-driven control application to be developed” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)). In addition, “a computer-implemented method for automatically generating a representational state transfer, REST, application programming interface, API, specification based on a plain-text user story” is an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). Further, the limitation of “outputting a REST API specification” which is insignificant extra solution activity (i.e., transmitting data) See MPEP 2106.05(g). Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to the abstract idea.
Step 2B: Claim provides an Inventive Concept: No. The additional element “a computer-implemented method for automatically generating a representational state transfer, REST, application programming interface, API, specification based on a plain-text user story” is an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). In addition, the limitation of “outputting a REST API specification”” (insignificant extra solution activity (i.e., transmitting data) See MPEP 2106.05(g)) and the limitation of “a) receiving, as input, the plain-text user story comprising a number of plain-text sentences that constitute a requirements definition for an API-driven control application to be developed” (insignificant pre-solution data gathering (see MPEP § 2106.05(g))) which are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))). These additional elements and combination of the elements does not amount to significant more than the exception itself or provide an inventive concept in Step 2B.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Here, the “receiving” and “outputting” steps were considered to be extra-solution activity in Step 2A as insignificant data gathering and communication and are well understood, routine, conventional activity in the field. The “receiving” and “outputting” steps are for the purpose of “communication” and “transmitting the data” and these can be reached on one of court case (Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) see MPEP § 2106.05(d) II). Accordingly, a conclusion that “receiving” and “outputting” are well understood, routine, conventional activity is supported under Berkheimer options 2.
For these reasons, there is no inventive concept in the claim, and thus the claim is ineligible.
Independent claims 12, 13 and 15 are rejected for the same reason as claim 1 above. Claim 12 further recites “a computer program product comprising a non-transitory computer readable storage medium having a program code for executing”; and Claim 15 further recites “A system comprising a software execution environment to which one or more API-driven control applications for controlling one or more industrial devices are deployable”. These additional elements are directed to generic computing components/functions merely applying the abstract idea (MPEP § 2106.05(f)).
With respect to the dependent claim 2, the claim elaborates that the method of wherein in step b), the number of nouns and the number of verbs are identified by comparing each word comprised by each of the number of plain-text sentences with a predetermined list of verbs and a predetermined list of nouns (“identified by comparing each word comprised by each of the number of plain-text sentences with a predetermined list of verbs and a predetermined list of nouns” are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind. Further, the claim as a whole is a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion)).
With respect to the dependent claim 3, the claim elaborates that wherein in step b), the number of nouns and the number of verbs are identified through natural language processing (“identified through natural language processing” are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 4, the claim elaborates that wherein if in step b), a plurality of verbs are identified, a relevant verb of the plurality of verbs is identified based on its position within the plain-text user story, and the relevant verb is matched to one of the plurality of HTTP methods in step c) (“a most relevant verb of the plurality of verbs is identified based on its position within the plain-text user story, and the most relevant verb is matched to one of the plurality of HTTP methods in step c)” are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind. Further, the claim as a whole is a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion)).
With respect to the dependent claim 5, the claim elaborates that wherein in step c), the relevant verb is matched to a library in which each HTTP method is associated with a number of verbs (these limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 6, the claim elaborates that wherein, if in step b), a plurality of nouns are identified, in step d), one of the plurality nouns is identified as a HTTP root resource to be used in the REST path, and a number of the plurality of nouns are identified as sub-resources, based on criteria including one or more of:- a position of the respective noun in the plain-text user story;- a frequency of occurrence of the respective noun in the plain-text user story; - a positional or grammatical relationship of the respective noun with the one of the number of plurality of verbs that was matched to the HTTP method (these limitations are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind. Further, the claim as a whole is a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion)).
With respect to the dependent claim 7, the claim elaborates that wherein, if the number of nouns identified as sub-resources is greater than a predetermined threshold, the number of nouns identified as sub-resources is further subdivided, based on the criteria, into a first number of nouns to be used as HTTP sub-resources in the REST path and a second number of nouns to be used as sub-resources in a request body description, and the REST API specification generated in step f) further comprises the request body description. (these limitations are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind. Further, the claim as a whole is a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion)).
With respect to the dependent claim 8, the claim elaborates that wherein, if in step b), a plurality of nouns are identified as HTTP sub-resources to be used in the REST path, in step e), a plurality of REST paths is generated, each of the plurality of REST paths comprising the HTTP root resource and, in an order that differs for each of the plurality of REST paths, the HTTP sub-resources, and in step f), the plurality of REST paths is included in the REST API specification. (these limitations are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind. Further, the claim as a whole is a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion)).
With respect to the dependent claim 9, the claim elaborates that validating the API-driven control application prior to its deployment to an industrial control system, the validating comprising: g) receiving, as input, source code of the API-driven control application, h) generating a REST API specification based on the received source code of the API-driven control application, i) validating the API-driven control application under a condition that the REST API specification generated in step h) based on the source code of the API-driven control application matches the REST API specification generated in step f) based on the plain-text user story (“receiving” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)). “generating” and “validating” are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind. Further, the claim as a whole is a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion)).
With respect to the dependent claim 10, the claim elaborates that j) building the API-driven control application from the received source code only if the validation step i) is successful. (“building the API-driven control application” is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)) The claim does not define any particular machine to “building” this “API-driven control application” and no details what so ever on how the claimed function will occur.
With respect to the dependent claim 11, the claim elaborates that k) deploying the API-driven control application to the industrial control system only if the validation step i) is successful (“deploying” which is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)). The claim does not define any particular machine to “deploying” this “API-driven control application” and no details what so ever on how the claimed function will occur.
Dependent claim 14 recite the same features as applied to claim 9 above, therefore it is also rejected under the same rationale.
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.
Claims 4-5 are rejected under 35 U.S.C. 112(b), 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 pre-AIA the applicant regards as the invention.
As per claims 4-5:
Lines 2-3, “relevant verb” is a relative term which renders the claim indefinite. The term “relevant verb " is indefinite and are not defined in the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention (i.e., the claim does not provide any explanation what position makes that “verb” “relevant”. Therefore, the scope of the claimed “relevant verb” is unclear). Also applies to claim 5, line 2.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8, 12-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lipka (US Pub. 2022/0405293 A1) in view of Alurralde Iturri et al. (US Pub. 2020/0218515 A1; hereafter Alurralde).
Lipka and Alurralde were cited in the previous Office Action.
As per claim 1, Lipka teaches the invention substantially as claimed including A computer-implemented method for automatically generating a representational state transfer, REST, application programming interface, API, specification based on a plain-text user story (Lipka, Abstract, lines 1-6, Methods, systems, and devices for generating a unique resource identifier (as REST API specification) are described. According to the techniques described herein, a device (e.g., an application server) may receive a natural language query indicating a query for a value of one or more data records stored in a database table; [0014] lines 2-3, accessible via representational state transfer (REST) application program interface (API)), the method comprising:
a) receiving, as input, the plain-text user story comprising a number of plain-text sentences that constitute a requirements definition (Lipka, Fig. 8, 805; [0016] lines 1-24, server (e.g., a database server, an application server) of a database system may receive natural language queries (e.g., a submitted question, a submitted search phrase, etc.) and may use machine learning models to determine a unique resource identifier for a target API…the user may input a natural language query “show me the price of item 2 of order 42.” (as plain-text user story comprising a number of plain-text sentences that constitute a requirements definition (i.e., show me)); The server may parse the natural language query to identify the resources “order” and “item.”; also see [0033] parse each query of the set of queries (as comprising a number of plain-text sentences) to identify a set of resources of the target API and a set of values corresponding to the set of resources.);
b) identifying a number of nouns and a number of verbs in the received plain-text user story (Lipka, [0017] lines 17-43, The server may use a list of known nouns and a list of known verbs (e.g., list of actions). When the nouns in the command are identified, the server may derive the respective parameters for each noun. In the example of natural language query “show me the price of item 2 of order 42,” the server may identify parameter “42” for noun “order,” parameter “2” for noun “item” and noun “price.” The server may then employ an iterative process to identify the hierarchy of the set of resources. Upon identifying the hierarchy of the set of resources, the techniques depicted herein provide for generation of a unique resource identifier of the target API to determine a value of the data record (“price” in the example of the natural language query “show me the price of item 2 of order 42”). Thus, the server may generate, from the natural language query and based on the hierarchy of the set of resources, the unique resource identifier for the target API to access the value of the one or more data records indicated in the query; [0036] lines 21-29, the data preprocessor 230 may identify verbs in the natural language query. In addition, the data preprocessor 230 may identify one or more actions from the natural language query (e.g., an action in the query “show me category foo” is “/category/foo: whereas an action in the query “search for category bar” is “/category_search/bar”). For example, the data preprocessor 230 may determine, based on the metadata, that the natural language query includes an action from a list of actions);
c) matching the identified number of verbs to one of a plurality of Hyper Text Transfer Protocol (HTTP) methods (Lipka, [0036] lines 21-29, the data preprocessor 230 may identify verbs in the natural language query. In addition, the data preprocessor 230 may identify one or more actions from the natural language query (e.g., an action in the query “show me category foo” is “/category/foo: whereas an action in the query “search for category bar” is “/category_search/bar”). For example, the data preprocessor 230 may determine, based on the metadata, that the natural language query includes an action from a list of actions; [0037] lines 6-9, the data preprocessor 230 may use a list of known nouns (e.g., based on a dictionary or a user input list) and a list of known verbs (e.g., list of actions and list of verbs such as “get,” “show,” “search,” “find” “delete,” etc.);
d) matching the number of identified nouns to a number of HTTP resources (Lipka, [0017] lines 21-25, the server may identify parameter “42” for noun “order,” parameter “2” for noun “item” and noun “price.” The server may then employ an iterative process to identify the hierarchy of the set of resources; also see [0037] when the nouns in the command are identified, the data preprocessor 230 may derive the respective parameters for each noun. In the example of natural language query “show me the price of item 2 of order 42,” the data preprocessor 230 may identify the following parameter and noun pairs: [0038] “order”—42 [0039] “item”—2 and [0040] “price”; [0041] The data preprocessor 230 may then employ an iterative process to identify the hierarchy of the set of resources. For example, the data preprocessor 230 may send messages to the target API using different combinations of possible resource-value pairs to iteratively determine the hierarchy of the resources in the data table. Additionally or alternatively, the data preprocessor 230 may try different unique resource identifiers with an API and determine whether they denote a valid resource. For example, the data preprocessor 230 may perform the first test using a single noun as the following: [0042] /order/42 [0043] /item/2 [0044] /price; [0048] If both the options return valid results (with the former returning the total price of the order), the data preprocessor 230 may go on to test using; (as matching the number of identified nouns to a number of HTTP resources));
e) building a REST path using the matched HTTP method and the number of matched HTTP resources (Lipka, [0036] lines 16-20, The data preprocessor 230 may build a unique resource identifier for the target API based on receiving the natural language query. In some examples, the unique resource identifier may include nouns as well as verbs (such as “/category/search/foo” or “/category_search/bar”) (as REST path) [0052] lines 6-10, Thus, the resource identifier generator 235 may generate, from the natural language query and based on the hierarchy of the set of resources, the unique resource identifier for the target API to access the value of the one or more data records indicated in the query); and
f) generating and outputting a REST API specification that comprises at least the built REST path. (Lipka, Fig. 4, 435; [0065] lines 3-6, At 435, the server 410 may transmit the generated unique resource identifier for display at the user device 405).
Although, Lipka teaches receiving, as input, the plain-text user story comprising a number of plain-text sentences that constitute a requirements definition, Lipka fails to specifically teach the plain-text user story is for an API-driven control application to be developed.
However, Alurralde teaches the plain-text user story is for an API-driven control application to be developed (Alurralde, Abstract, An example system and method provides an enhancement to a software editor, enabling a user (e.g., developer) to visualize a REST API (also called a REST service herein) as a list of resources presented in a flat structure, i.e., a simple list of resources containing operations. The software editor may be a fully JS/HTML/CSS (JavaScript, HyperText Markup Language, Cascading Style Sheets) compliant editor that lets the user define connectors to REST API's in an easy and fluid way; [0011] lines 1-12, The REST editor and accompanying simplified model or structure for describing a REST API interface, facilitate construction of REST API connectors used to connect steps (e.g., corresponding to flow elements) of process-based software applications to external services to be called by the steps. The developed REST API connectors may be available to other software application developers via a catalog of connectors. A user, e.g., developer, can now readily develop, use, and share REST API connectors for virtually any of REST API or service without needing to know details of the underlying WADL file or other interface description characterizing the exposed interface of the REST API or service; [0017] define specific REST connectors usable for implementing flow elements (e.g., steps) of a process-based software application).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lipka with Alurralde because Alurralde’s teaching of developing REST API connectors for implementing flow elements (e.g., steps) of a process-based software application would have provided Lipka’s system with the advantage and capability to allow the system to readily develop, use, and share REST API connectors for virtually any of REST API or service without needing to know details of the underlying WADL file or other interface description characterizing the exposed interface of the REST API or service in order to improving the system performance and efficiency (see Alurralde, [0011]).
As per claim 2, Lipka and Alurralde teach the invention according to claim 1 above. Lipka further teaches wherein in step b), the number of nouns and the number of verbs are identified by comparing each word comprised by each of the number of plain-text sentences with a predetermined list of verbs and a predetermined list of nouns (Lipka, [0017] lines 17-43, The server may use a list of known nouns and a list of known verbs (e.g., list of actions). When the nouns in the command are identified, the server may derive the respective parameters for each noun. In the example of natural language query “show me the price of item 2 of order 42,” the server may identify parameter “42” for noun “order,” parameter “2” for noun “item” and noun “price.” The server may then employ an iterative process to identify the hierarchy of the set of resources. Upon identifying the hierarchy of the set of resources, the techniques depicted herein provide for generation of a unique resource identifier of the target API to determine a value of the data record (“price” in the example of the natural language query “show me the price of item 2 of order 42”). Thus, the server may generate, from the natural language query and based on the hierarchy of the set of resources, the unique resource identifier for the target API to access the value of the one or more data records indicated in the query).
As per claim 3, Lipka and Alurralde teach the invention according to claim 1 above. Lipka further teaches wherein in step b), the number of nouns and the number of verbs are identified through natural language processing (Lipka, [0016] A server (e.g., a database server, an application server) of a database system may receive natural language queries (e.g., a submitted question, a submitted search phrase, etc.) and may use machine learning models to determine a unique resource identifier for a target API. In particular, the system (e.g., database server, application server) described herein may receive, via a user interface, a natural language query indicating a query for a value of a data record stored in a database. That is, a server may receive a natural language query indicating a query for a value of one or more data records stored in a database table. As depicted herein. the database table may be accessible via a target API that is configured as a resource oriented API. For example, the data resource may be accessed via a REST API (or a similarly configured API) configured as a resource oriented API. The database server may then parse the natural language query to identify a set of resources and a set of values corresponding to the set of resources. For instance, the database server may parse the natural language query to identify (as through natural language processing) a set of resources of the target API and a set of values corresponding to the set of resources. The parsing operation may be based on a first configuration. In one example, the user may input a natural language query “show me the price of item 2 of order 42.” The server may parse the natural language query to identify the resources “order” and “item.” The server may also identify parameters related to each resource. That is, in the natural language query “show me the price of item 2 of order 42,” the server may determine that “2” is the value of the resource “item” and “42” is the value of the resource “order.”).
As per claim 4, Lipka and Alurralde teach the invention according to claim 1 above. Lipka further teaches wherein if in step b), a plurality of verbs are identified, a relevant verb of the plurality of verbs is identified based on its position within the plain-text user story, and the relevant verb is matched to one of the plurality of HTTP methods in step c). (Lipka, [0017] lines 17-43, The server may use a list of known nouns and a list of known verbs (e.g., list of actions). When the nouns in the command are identified, the server may derive the respective parameters for each noun. In the example of natural language query “show me the price of item 2 of order 42,” the server may identify parameter “42” for noun “order,” parameter “2” for noun “item” and noun “price.”; [0036] lines 21-29, the data preprocessor 230 may identify verbs in the natural language query. In addition, the data preprocessor 230 may identify one or more actions from the natural language query (e.g., an action in the query “show me category foo” is “/category/foo: whereas an action in the query “search for category bar” is “/category_search/bar”). For example, the data preprocessor 230 may determine, based on the metadata, that the natural language query includes an action from a list of actions; [0037] lines 6-9, the data preprocessor 230 may use a list of known nouns (e.g., based on a dictionary or a user input list) and a list of known verbs (e.g., list of actions and list of verbs such as “get,” “show,” “search,” “find” “delete,” etc.) (as matching one of a plurality of HTTP methods (i.e., a list of known verbs (e.g., list of actions and list of verbs such as “get,” “show,” “search,” “find” “delete,” etc.) [Please notes: the method of claim 4, include contingent limitation “if” which means that it does not need to be actually happening, see MPEP 2111.04, II]).
As per claim 5, Lipka and Alurralde teach the invention according to claim 4 above. Lipka further teaches wherein in step c), the relevant verb is matched to a library in which each HTTP method is associated with a number of verbs (Lipka, [0037] lines 6-9, the data preprocessor 230 may use a list of known nouns (e.g., based on a dictionary or a user input list) and a list of known verbs (e.g., list of actions and list of verbs such as “get,” “show,” “search,” “find” “delete,” etc.) also see [0036] the data preprocessor 230 may identify one or more actions from the natural language query (e.g., an action in the query “show me category foo” is “/category/foo: whereas an action in the query “search for category bar” is “/category_search/bar”) (as the most relevant verb is matched to a library in which each HTTP method is associated with a number of verbs).
As per claim 6, Lipka and Alurralde teach the invention according to claim 1 above. Lipka further teaches wherein, if in step b), a plurality of nouns are identified, in step d), one of the plurality nouns is identified as a HTTP root resource to be used in the REST path, and a number of the plurality of nouns are identified as sub-resources, based on criteria including one or more of:- a position of the respective noun in the plain-text user story;- a frequency of occurrence of the respective noun in the plain-text user story; - a positional or grammatical relationship of the respective noun with the one of the number of plurality of verbs that was matched to the HTTP method (Lipka, [0017] lines 21-25, the server may identify parameter “42” for noun “order,” parameter “2” for noun “item” and noun “price.” The server may then employ an iterative process to identify the hierarchy of the set of resources; also see [0037] when the nouns in the command are identified, the data preprocessor 230 may derive the respective parameters for each noun. In the example of natural language query “show me the price of item 2 of order 42,” the data preprocessor 230 may identify the following parameter and noun pairs: [0038] “order”—42 [0039] “item”—2 and [0040] “price”; [0041] The data preprocessor 230 may then employ an iterative process to identify the hierarchy of the set of resources. For example, the data preprocessor 230 may send messages to the target API using different combinations of possible resource-value pairs to iteratively determine the hierarchy of the resources in the data table. Additionally or alternatively, the data preprocessor 230 may try different unique resource identifiers with an API and determine whether they denote a valid resource. For example, the data preprocessor 230 may perform the first test using a single noun as the following: [0042] /order/42 [0043] /item/2 [0044] /price; [0050] /order/42/item/2/price (as one of the plurality nouns is identified as a HTTP root resource to be used in the REST path, and a number of the plurality of nouns are identified as sub-resources and a position of the respective noun in the plain-text user story).
As per claim 8, Lipka and Alurralde teach the invention according to claim 6 above. Lipka further teaches wherein, if in step b), a plurality of nouns are identified as HTTP sub-resources to be used in the REST path, in step e), a plurality of REST paths is generated, each of the plurality of REST paths comprising the HTTP root resource and, in an order that differs for each of the plurality of REST paths, the HTTP sub-resources, and in step f), the plurality of REST paths is included in the REST API specification (Lipka, [0041] The data preprocessor 230 may then employ an iterative process to identify the hierarchy of the set of resources. For example, the data preprocessor 230 may send messages to the target API using different combinations of possible resource-value pairs to iteratively determine the hierarchy of the resources in the data table. Additionally or alternatively, the data preprocessor 230 may try different unique resource identifiers with an API and determine whether they denote a valid resource. For example, the data preprocessor 230 may perform the first test using a single noun as the following: [0042] /order/42 [0043] /item/2 [0044] /price (as a plurality of REST paths is generated, each of the plurality of REST paths comprising the HTTP root resource); [0045] When one of the options results in a valid resource, the data preprocessor 230 may test using additional nouns to construct a sub-resource. Assuming only “/order/42” was valid, the data preprocessor 230 may test using: [0046] /order/42/price [0047] /order/42/item/2; [0048] If both the options return valid results (with the former returning the total price of the order), the data preprocessor 230 may go on to test using [0049] /order/42/price/item/2 [0050] /order/42/item/2/price (as each of the plurality of REST paths comprising the HTTP root resource and, in an order that differs for each of the plurality of REST paths, the HTTP sub-resources, and in step f), the plurality of REST paths is included in the REST API specification; see Fig. 4, 435)); [0051] The third test may result in the second form being a valid resource. Thus, the data preprocessor 230 may iteratively generate, based on the set of transformation rules, a set of unique resource identifiers based on at least one of the first noun, the first value corresponding to the first noun, the second noun, the second value corresponding to the second noun, or a combination thereof [Please notes: the claim includes contingent limitation “if” which means that it does not need to be actually happening, see MPEP 2111.04, II]).
As per claim 12, it is a computer program product claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
As per claim 13, it is a computing device claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
As per claim 15, it is a system claim of claim 13 (i.e., claim 1) above. Therefore, it is rejection for the same reasons as claim 13 (i.e., claim 1) above.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Lipka and Alurralde, as applied to claim 6 above, and further in view of Gaddam et al. (US Pub. 2023/0055595 A1).
Gaddam was cited in the previous Office Action.
As per claim 7, Lipka and Alurralde teach the invention according to claim 6 above. Lipka further teaches wherein, if the number of nouns identified as sub-resources, the number of nouns identified as sub-resources is further subdivided, based on the criteria, into a first number of nouns to be used as HTTP sub-resources in the REST path and a second number of nouns to be used as sub-resources in a request body description, and the REST API specification generated in step f) further comprises the request body description (Lipka, [0041] The data preprocessor 230 may then employ an iterative process to identify the hierarchy of the set of resources. For example, the data preprocessor 230 may send messages to the target API using different combinations of possible resource-value pairs to iteratively determine the hierarchy of the resources in the data table. Additionally or alternatively, the data preprocessor 230 may try different unique resource identifiers with an API and determine whether they denote a valid resource. For example, the data preprocessor 230 may perform the first test using a single noun as the following: [0042] /order/42 [0043] /item/2 [0044] /price [0045] When one of the options results in a valid resource, the data preprocessor 230 may test using additional nouns to construct a sub-resource (as if the number of nouns identified as sub-resources). Assuming only “/order/42” was valid, the data preprocessor 230 may test using: [0046] /order/42/price [0047] /order/42/item/2; [0048] If both the options return valid results (with the former returning the total price of the order), the data preprocessor 230 may go on to test using [0049] /order/42/price/item/2 [0050] /order/42/item/2/price [0051] The third test may result in the second form being a valid resource. Thus, the data preprocessor 230 may iteratively generate, based on the set of transformation rules, a set of unique resource identifiers based on at least one of the first noun, the first value corresponding to the first noun, the second noun, the second value corresponding to the second noun, or a combination thereof (as into a first number of nouns to be used as HTTP sub-resources in the REST path and a second number of nouns to be used as sub-resources in a request body description, and the REST API specification generated in step f) further comprises the request body description (i.e., see [0049] /order/42/price/item/2 [0050] /order/42/item/2/price); [Please notes: the claim includes contingent limitation “if” which means that it does not need to be actually happening, see MPEP 2111.04, II]).
Lipka and Alurralde fail to specifically teach the number of nouns identified as sub-resources is greater than a predetermined threshold.
However, Gaddam teaches the number of nouns identified as sub-resources is greater than a predetermined threshold (Gaddam, [0040] lines 10-20, parse message 118 to identify nouns, verbs, and other parts of speech within the content of message 118. Content analysis unit 216 may compare the nouns and verbs to lists of words associated with individual categories. Content analysis unit 216 may determine that the content of message 118 is associated with a specific category if message 118 contains at least a given number of nouns or verbs associated with the specific category or a ratio of nouns and verbs associated with the specific category compared to nouns and verbs associated with other categories is greater than a predetermined threshold).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lipka and Alurralde with Gaddam because Gaddam’s teaching of determining that number of nouns is greater than a predetermined threshold would have provided Lipka and Alurralde’s system with the advantage and capability to allow the system to identifying the different categories of the received input messages which improving the system performance and efficiency.
Claims 9 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Lipka and Alurralde, as applied to claims 1 and 13 respectively above, and further in view of Palanki et al. (US Patent. 11,687,656 B2) and Mehmedagic et al. (US Pub. 2021/0029029 A1).
Palanki and Mehmedagic were cited in the previous Office Action.
As per claim 9, Lipka and Alurralde teach the invention according to claim 1 above. Lipka teaches the REST API specification generated in step f) based on the plain-text user story (Lipka, Fig. 4, 435; [0065] lines 3-6, At 435, the server 410 may transmit the generated unique resource identifier for display at the user device 405). In addition, Alurralde teaches API-driven control application (Alurralde, Abstract, An example system and method provides an enhancement to a software editor, enabling a user (e.g., developer) to visualize a REST API (also called a REST service herein) as a list of resources presented in a flat structure, i.e., a simple list of resources containing operations. The software editor may be a fully JS/HTML/CSS (JavaScript, HyperText Markup Language, Cascading Style Sheets) compliant editor that lets the user define connectors to REST API's in an easy and fluid way; [0011] lines 1-12, The REST editor and accompanying simplified model or structure for describing a REST API interface, facilitate construction of REST API connectors used to connect steps (e.g., corresponding to flow elements) of process-based software applications to external services to be called by the steps. The developed REST API connectors may be available to other software application developers via a catalog of connectors. A user, e.g., developer, can now readily develop, use, and share REST API connectors for virtually any of REST API or service without needing to know details of the underlying WADL file or other interface description characterizing the exposed interface of the REST API or service; [0017] define specific REST connectors usable for implementing flow elements (e.g., steps) of a process-based software application).
Lipka and Alurralde fail to specifically teach validating the API-driven control application prior to its deployment to an industrial control system, the validating comprising: g) receiving, as input, source code of the API-driven control application, h) generating a REST API specification based on the received source code of the API-driven control application, i) validating the API-driven control application under a condition that the REST API specification generated in step h) based on the source code of the API-driven control application matches the REST API specification.
However, Palanki teaches validating the API-driven control application prior to its deployment to system, the validating comprising (Palanki, Col 7, lines 46-52, Prior to creation (e.g., compilation) or deployment (e.g., sending a web-page containing client-side executable script to a web server) of the application, the build service 169 may send a request to the validation client 166 to determine whether the component files 129 are permitted to be included in or deployed with the application):
g) receiving, as input, source code of the API-driven control application (Palanki, Col 3, lines 34-45, A component file 129 can be any file that would be integrated into an application. A component file 129 can be a binary file comprising machine-readable instructions executable by a processor of a computing device or a human readable source code file (as source code of the API-driven control application, please note: API-driven control application was taught by Alurralde). In those implementations where the component file 129 is a human readable source code file, the component file 129 may be written in a language that uses an interpreter to convert the human readable source code into an executable binary form at runtime (e.g., JAVASCRIPT®, PYTHON®, etc.). The component file 129 may represent a library, plug-in, or module that provides functionality for an application; Col 7, lines 11-12, The validation node 103 can then verify that the component files 129 received from the validation client 166; also see Col 11, lines 27-31, the build service 169 can send a request to the validation client 166 for permission to include the identified component files 129 in the application. The request can include the identity of the component file 129 or the component file 129 itself),
h) generating a REST API specification based on the received source code of the API-driven control application (Palanki, Col 7, lines 23-40, Assuming that the component file(s) 129 comply with one or more security policies 123, the distributed agent 163 can create an endorsed application component records 119 and save it to the distributed ledger 116…the distributed agent 163 could generate file signatures 136 for individual component files 129 and an endorsement signature 149 for the endorsed application component record 119 (as generating a REST API specification based on the received source code),
i) validating the API-driven control application under a condition that the REST API specification generated in step h) based on the source code of the API-driven control application matches the REST API specification (Palanki, Col 3 line 58- Col 4, line 2, The file signature 136 can represent the cryptographic signature of a respective component file 129 generated by a public key 126 of a validation node 103 or the cryptographic hash of the respective component file 129 generated using a cryptographic hash algorithm (e.g., message digest 5 (md5), secure hash algorithm 1 (SHA-1), one of the secure hash algorithm 2 (SHA-2) algorithms, the secure hash algorithm 3 (SHA-3), etc.). The file signature 136 can be generated when the endorsed application component record 119 is stored in the distributed ledger 116 to verify whether subsequently analyzed component files 129 match those stored as a part of the endorsed application component record 119; also see Col 11, lines 27-31, the build service 169 can send a request to the validation client 166 for permission to include the identified component files 129 in the application. The request can include the identity of the component file 129 or the component file 129 itself; Col 11, lines 46-55, The build service 169 may verify the endorsed application component record 119 for the respective component files 129. For example, the build service 169 could use the endorsement signature 149 to verify the identity of the endorsed application component record 119. As another example, the build service 169 could use the file signatures 136 to verify that the component file(s) 129 being used are the same as the ones that were verified or validated by a distributed agent 163 executing on a validation node 103 (as validating the API-driven control application under the condition that the REST API specification generated in step h) based on the source code of the API-driven control application matches).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lipka and Alurralde with Palanki because Palanki’s teaching of validating the source code (i.e., component files) of the application prior to deploy the application would have provided Lipka and Alurralde’s system with the advantage and capability to allow the system to ensuring the received source code is matching with the record for later application deployment in order to improving the system reliability and performance (see Col 13, lines 50-55 “for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids”).
Lipka, Alurralde and Palanki fail to specifically teach deployment to an industrial control system.
However, Mehmedagic teaches deployment to an industrial control system (Mehmedagic, [0046] lines 1-4, This disclosure describes an architecture of a Software-Defined Network (SDN) for an industrial environment (“industrial SDN”) and deployment of industrial SDN in a Software Defined Automation (“SDA”) system; [0048] lines 1-4, The industrial SDN deployed in an SDA system further enhances the SDA system via an industrial SDN application enabling the system to automate tasks that typically require great deal of network expertise, planning and time).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lipka, Alurralde and Palanki with Mehmedagic because Mehmedagic’s teaching of industrial SDN deployed in an SDA system would have provided Lipka, Alurralde and Palanki’s system with the advantage and capability to allow the system to enhance the SDA system via an industrial SDN application enabling the system to automate tasks that typically require great deal of network expertise, planning and time (see Mehmedagic, [0048]).
As per claim 14, it is a computing device claim of claim 9 above. Therefore, it is rejected for the same reason as claim 9 above.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Lipka, Alurralde, Palanki and Mehmedagic, as applied to claim 9 above, and further in view of Pastor et al. (US Patent. 6,681,383 B1).
Pastor was cited in the previous Office Action.
As per claim 10, Lipka, Alurralde, Palanki and Mehmedagic teach the invention according to claim 9 above. Lipka, Alurralde, Palanki and Mehmedagic fail to specifically teach j) building the API-driven control application from the received source code only if the validation step i) is successful.
However, Pastor teaches j) building the API-driven control application from the received source code only if the validation step i) is successful (Pastor, Col 3, lines 32-46, validated for correctness and completeness. In addition, a translator is provided to automatically generate a complete, robust software application based on the validated formal specification. By generating the application code from the validated formal specification, error-free source code strategies can be employed, freeing the developer from having to manually produce the source code or extend an incomplete prototype. Therefore, the error-prone, manual programming phase of the traditional software engineering process is eliminated, and the testing and debugging time is greatly reduced. In one example, the software development time of an application was reduced to 27% of the original time. Software maintenance is also reduced, because the traditional coding, testing, and revalidation cycles is eliminated; please note: API-driven control application was taught by Alurralde).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lipka, Alurralde, Palanki and Mehmedagic with Pastor because Pastor’s teaching of building/generating the application only the validation is successfully would have provided Lipka, Alurralde, Palanki and Mehmedagic’s system with the advantage and capability to allow the system to have error-free application execution which improving the system performance and reducing the software maintenance (see Pastor, Col 3, lines 32-46).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Lipka, Alurralde, Palanki and Mehmedagic, as applied to claim 9 above, and further in view of Douglas et al. (US Patent. 12,468,519 B2).
Douglas was cited in the previous Office Action.
As per claim 11, Lipka, Alurralde, Palanki and Mehmedagic teach the invention according to claim 9 above. Mehmedagic teaches deploying the API-driven control application to the industrial control system (Mehmedagic, [0046] lines 1-4, This disclosure describes an architecture of a Software-Defined Network (SDN) for an industrial environment (“industrial SDN”) and deployment of industrial SDN in a Software Defined Automation (“SDA”) system; [0048] lines 1-4, The industrial SDN deployed in an SDA system further enhances the SDA system via an industrial SDN application enabling the system to automate tasks that typically require great deal of network expertise, planning and time).
Lipka, Alurralde, Palanki and Mehmedagic fail to specifically teach when deploying, it is only if the validation step i) is successful.
However, Douglas when deploying, it is only if the validation step i) is successful (Douglas, Claim 1, generating a software application based on the source code, wherein the software application is validated based on executing the automated tests and the software application comprises the automated tests; deploying the software application to the production environment).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lipka, Alurralde, Palanki and Mehmedagic with Douglas because Douglas’s teaching of validating before deploying would have provided Lipka, Alurralde, Palanki and Mehmedagic’s system with the advantage and capability to allow the system to validating the application before it is actually deployed in order to improving the system reliability and performance.
Response to Arguments
In the remark applicant’s argue in substance:
(a), none of these limitations recite abstract ideas on their own or per se-they do not recite mathematical concepts, methods of organizing human activity, or mental processes. Rather, the claims recite an improved method for automatically generating a representational state transfer, REST, application programming interface, API, specification based on a plain-text user story. The Examiner alleges that certain method steps could represent mental processes. However, the claims as a whole are not directed to mental processes, but rather recite steps of receiving input, building a REST path using HTTP methods and resources, and generating and outputting a REST API specification. These are not mental processes. While the rejection asserts that these steps could be accomplished using a pen and paper, such a characterization ignores the technical specificity of the claimed embodiments. The recited steps are not generic evaluation or judgment, but instead involve matching linguistic elements to specific technical protocol constructs (HTTP methods such as GET, HEAD, POST, PUT, DELETE, CONNECT, TRACE, PATH) and generating a machine-readable REST API specification. These are operations tied to specific technical protocols that cannot practically be performed in the human mind.
(b), Applicant's claimed embodiments provide just such an improvement in the relevant technological field and thus demonstrate integration into a practical application. As explained in Applicant's Specification, conventional methods require human expertise and are prone to errors. Published Specification, at [0006]. Further, these errors either lead to an application that does not function or are undiscovered within the application until the industrial control system operates incorrectly. Id. at [0007]-[0008]…In contrast to the conventional methods, Applicant's claimed embodiments provide improved reliability, provide increased suitability of the generated API specifications for the requirements specified by the user, provide for exploration of different path options, provide for validation, etc. Id. at [0009], [0011], [0041], [0045]-[0048]… Moreover, MPEP § 2106.04(a)(1) provides that "If a claim recites an abstract idea, but the claim as a whole is directed to an improvement or otherwise clearly does not seek to tie up the abstract idea, then the claim is not directed to an abstract idea."
(c), Applicant respectfully contends that the claims as a whole contain significantly more and are directed to a technical solution. Further, as discussed in more detail below, the claims are novel and non-obvious over the cited art. While Applicant recognizes that the search for an inventive concept under § 101 is not equivalent to analysis under § 102 or § 103, the fact that the claims are novel and non-obvious weighs against any finding that the elements are merely well known, routine, and/or conventional.
(d), Lipka fails to disclose at least the following features: 1) Input as requirements definition for an application to be developed. As discussed above, Lipka's input is a query against an existing system, not requirements for a new system.
(e) Matching verbs to HTTP methods. Neither reference teaches automatically selecting an HTTP method (GET, POST, PUT, DELETE, etc.) based on a verb identified in natural language text. Lipka maps verbs to URI path segments while in Alurralde users/developers manually specify operations.
(f) Building a REST path using the matched HTTP method. Neither reference teaches constructing a REST path that incorporates a matched HTTP method together with matched HTTP resources derived from noun identification.
(g) Generating a REST API specification. Again, Lipka outputs a single URI for data retrieval. The secondary reference to Alurralde generates interface descriptions, but from manual developer input, not from automated processing of a plain-text user story. For example, Alurralde explains that the user may define resources and operations within resources. See Alurralde, at [0010]. Thus, neither reference teaches generating a REST API specification automatically from a plain-text user story.
(h),Applicant's embodiments are directed to an end-to-end automated process: a plain-text user story is received, nouns and verbs are identified, verbs are matched to HTTP methods and nouns are matched to HTTP resources, a REST path is built using the matched methods and resources, and a REST API specification is generated.
(i),The references solve different technical problems. Lipka solves the problem of querying existing data via natural language while Alurralde solves the problem of simplifying developer interaction with REST API definitions. Neither addresses the problem of automatically generating an API specification from requirements for a new application to be developed as contemplated by Applicant's embodiments.
(j),Further, the different solutions presented by the references have incompatible operational contexts. Lipka operates at runtime, during which it receives a user's data query and generates a URI to fetch data from an existing database. Contrarily, Alurralde is directed to development and helps users/developers manually define REST connectors for process-based applications. Combining the references does not logically lead to the claimed embodiments, which operate at requirements/design time and which automatically translate user requirements into an API specification for a new application as discussed above.
(k),Moreover, one of skill in the art would not be provided with any teaching, suggestion, or motivation to combine the references to arrive at the claimed embodiments. One of skill starting with Lipka's natural language query processing would not be motivated to use it to generate an API specification for a new application. Instead, Lipka's entire system/disclosure presupposes an existing API with an existing resource hierarchy that must be discovered. Turning to Alurralde, one of skill in the art would not be motivated to replace the manual developer UI input of the reference with Lipka's natural language parsing, because Lipka's parsing is designed for data retrieval queries, not for generating requirements documents.
(l), Accordingly, even if presented with the references, one of skill in the art would not find any teaching, suggestion, or motivation to arrive at the claimed embodiments. Instead, the proffered rejection appears to be based on impermissible hindsight bias, namely, the Examiner's familiarity with Applicant's own disclosure and claims and reading those teachings back into the references.
Examiner respectfully disagreed with Applicant’s argument for the following reasons:
As to point (a), Examiner respectfully disagreed. First, Examiner has clearly identified claimed steps of “identifying a number of nouns and a number of verbs in the acquired plain-text user story; c) matching the identified number of verbs to one of a plurality of HTTP methods; d) matching the number of identified nouns to a number of HTTP resources; e) building a REST path using the matched HTTP method and the number of matched HTTP resources; and f) generating” under Step 2A-Pron 1. Examiner does NOT evaluating “receiving” step under Step 2A-Pron 1.
That’s it, the human mind can easily judging/evaluating/identifying a number of nouns and a number of verbs in the received plain-text user story, (i.e., human mind can easily identifying the number of nouns and number of verbs by just observing the received plain-text), determining/comparing/matching the identified number of verbs to one of a plurality of HTTP methods by just simply observation, determining/comparing/matching the number of identified nouns to a number of HTTP resources by simply observation, creating/building/generating (i.e., by pen and paper) a REST path using the matched HTTP method and the number of matched HTTP resources (i.e., this is no more than using a pen and paper to write down the REST path based on previous matching); and creating/building/generating (by pen and paper) a REST API specification that comprises at least the built REST path. It is unclear how that operations cannot practically be performed in the human mind. Thus, applicant’s argument has not been found to be persuasive.
As to point (b), in response to applicant’s argument that “Applicant's claimed embodiments provide just such an improvement in the relevant technological field and thus demonstrate integration into a practical application…”. Examiner respectfully disagreed. MPEP 2106.05(a) discloses that “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements. See the discussion of Diamond v. Diehr, 450 U.S. 175, 187 and 191-92, 209 USPQ 1, 10 (1981)) in subsection II, below. In addition, the improvement can be provided by the additional element(s) in combination with the recited judicial exception”.
Here, the claim further recites “a) receiving, as input, the plain-text user story comprising a number of plain-text sentences that constitute a requirements definition for an API-driven control application to be developed” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)), and “outputting a REST API specification” which is insignificant extra solution activity (i.e., transmitting data) See MPEP 2106.05(g). which are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))). These additional elements and combination of the elements does not amount to significant more than the exception itself or provide an inventive concept in Step 2B. Further, examiner has provided that the “receiving” and “outputting” steps are for the purpose of “communication” and “transmitting the data” and these can be reached on one of court case (Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) see MPEP § 2106.05(d) II). Accordingly, a conclusion that “receiving” and “outputting” are well understood, routine, conventional activity is supported under Berkheimer options 2.
Therefore, the claim does NOT providing any meaning limitations other than the generic computing components/Functions that perform the abstract idea (i.e., a computer implemented) with “receiving” and “outputting” which are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Therefore, the claim cannot provide the improvement. Thus, applicant’s argument has not been found to be persuasive.
As to point (c), please refers to point (A) and (b) above. Also see 101 rejection above.
As to point (d), in response to applicant’s argument that “Lipka fails to disclose… Input as requirements definition for an application to be developed. As discussed above, Lipka's input is a query against an existing system, not requirements for a new system”.
Examiner would like to remind applicant that the rejection is based on 103 rejection using multiple references. Examiner would like to point out that Lipka teaches “input as requirements definition” (See Lipka, Fig. 8, 805; [0016] lines 1-24, server (e.g., a database server, an application server) of a database system may receive natural language queries (e.g., a submitted question, a submitted search phrase, etc.) and may use machine learning models to determine a unique resource identifier for a target API…the user may input a natural language query “show me the price of item 2 of order 42.” (as plain-text user story comprising a number of plain-text sentences that constitute a requirements definition); The server may parse the natural language query to identify the resources “order” and “item.”; also see [0033] parse each query of the set of queries (as comprising a number of plain-text sentences) to identify a set of resources of the target API and a set of values corresponding to the set of resources.).
In addition, , Alurralde teaches the plain-text user story is for an API-driven control application to be developed (Alurralde, Abstract, An example system and method provides an enhancement to a software editor, enabling a user (e.g., developer) to visualize a REST API (also called a REST service herein) as a list of resources presented in a flat structure, i.e., a simple list of resources containing operations. The software editor may be a fully JS/HTML/CSS (JavaScript, HyperText Markup Language, Cascading Style Sheets) compliant editor that lets the user define connectors to REST API's in an easy and fluid way; [0011] lines 1-12, The REST editor and accompanying simplified model or structure for describing a REST API interface, facilitate construction of REST API connectors used to connect steps (e.g., corresponding to flow elements) of process-based software applications to external services to be called by the steps. The developed REST API connectors may be available to other software application developers via a catalog of connectors. A user, e.g., developer, can now readily develop, use, and share REST API connectors for virtually any of REST API or service without needing to know details of the underlying WADL file or other interface description characterizing the exposed interface of the REST API or service; [0017] define specific REST connectors usable for implementing flow elements (e.g., steps) of a process-based software application).
The examiner reminds the applicants that 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). Therefore, applicant’s argument has not been found to be persuasive.
As to point (e), in response to applicant’s argument that “Neither reference teaches automatically selecting an HTTP method (GET, POST, PUT, DELETE, etc.) based on a verb identified in natural language text”. Examiner would like to point out that the claim does not recites “selecting an HTTP method”. The claim recites “matching…verbs to HTTP methods”. “matching” does not mean “selecting”. This is totally different definition. And the concept (i.e., matching the identified number of verbs to one of a plurality of HTTP methods) is clearly taught by Lipka (see Lipka, [0036] lines 21-29, the data preprocessor 230 may identify verbs in the natural language query. In addition, the data preprocessor 230 may identify one or more actions from the natural language query (e.g., an action in the query “show me category foo” is “/category/foo: whereas an action in the query “search for category bar” is “/category_search/bar”). For example, the data preprocessor 230 may determine, based on the metadata, that the natural language query includes an action from a list of actions; [0037] lines 6-9, the data preprocessor 230 may use a list of known nouns (e.g., based on a dictionary or a user input list) and a list of known verbs (e.g., list of actions and list of verbs such as “get,” “show,” “search,” “find” “delete,” etc.). Therefore, applicant’s argument has not been found to be persuasive.
As to point (f), in response to applicant’s argument that “Neither reference teaches constructing a REST path that incorporates a matched HTTP method together with matched HTTP resources derived from noun identification”. Again, the claim does NOT require constructing a REST path that incorporates a matched HTTP method together with matched HTTP resources derived from noun identification. In fact, the claim only require “Building a REST path using the matched HTTP method”, it does not necessary mean that when building a REST path, that REST path need to include/incorporates matched HTTP method. Using does NOT mean “incorporates”. Again, Lipka teaches building a REST path using the matched HTTP method and the number of matched HTTP resources (see Lipka, [0036] lines 16-20, The data preprocessor 230 may build a unique resource identifier for the target API based on receiving the natural language query. In some examples, the unique resource identifier may include nouns as well as verbs (such as “/category/search/foo” or “/category_search/bar”) (as REST path, the claim does NOT define what is REST path) [0052] lines 6-10, Thus, the resource identifier generator 235 may generate, from the natural language query and based on the hierarchy of the set of resources, the unique resource identifier for the target API to access the value of the one or more data records indicated in the query). Therefore, applicant’s argument has not been found to be persuasive.
As to point (g), Lipka clearly teaches generating and outputting a REST API specification that comprises at least the built REST path. (Lipka, Fig. 4, 435; [0065] lines 3-6, At 435, the server 410 may transmit the generated unique resource identifier for display at the user device 405). That is, the generated URI for display at the user device which including the built REST path (i.e., such as “/category/search/foo” or “/category_search/bar”, which is based on received user input (i.e., a natural language query “show me the price of item 2 of order 42.” i.e., from a plain-text user story)). Therefore, applicant’s argument has not been found to be persuasive.
As to point (h), Please see 103 rejection and point (d) to (g) above.
As to point (i). please see point (d) to (h) above.
As to point (j), In response to applicant's argument that “Combining the references does not logically lead to the claimed embodiments”, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). Here, the examiner only relies on Alurralde for teaching that the plain-text user story is for an API-driven control application to be developed (see Alurralde, Abstract, An example system and method provides an enhancement to a software editor, enabling a user (e.g., developer) to visualize a REST API (also called a REST service herein) as a list of resources presented in a flat structure, i.e., a simple list of resources containing operations. The software editor may be a fully JS/HTML/CSS (JavaScript, HyperText Markup Language, Cascading Style Sheets) compliant editor that lets the user define connectors to REST API's in an easy and fluid way; [0011] lines 1-12, The REST editor and accompanying simplified model or structure for describing a REST API interface, facilitate construction of REST API connectors used to connect steps (e.g., corresponding to flow elements) of process-based software applications to external services to be called by the steps. The developed REST API connectors may be available to other software application developers via a catalog of connectors. A user, e.g., developer, can now readily develop, use, and share REST API connectors for virtually any of REST API or service without needing to know details of the underlying WADL file or other interface description characterizing the exposed interface of the REST API or service; [0017] define specific REST connectors usable for implementing flow elements (e.g., steps) of a process-based software application). That is, the examiner are not importing Alurralde’s entire REST-editor environment, it is only relies on Alurralde for teaching that plain-text user story is for an API-driven control application to be developed. Again, the plain-test user story was taught by Lipka.
Therefore, applicant’s argument has not been found to be persuasive.
As to point (k), In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007).
In this case, examiner only relies on Alurralde for teaching that the plain-text user story is for an API-driven control application to be developed (see Alurralde, Abstract, An example system and method provides an enhancement to a software editor, enabling a user (e.g., developer) to visualize a REST API (also called a REST service herein) as a list of resources presented in a flat structure, i.e., a simple list of resources containing operations. The software editor may be a fully JS/HTML/CSS (JavaScript, HyperText Markup Language, Cascading Style Sheets) compliant editor that lets the user define connectors to REST API's in an easy and fluid way; [0011] lines 1-12, The REST editor and accompanying simplified model or structure for describing a REST API interface, facilitate construction of REST API connectors used to connect steps (e.g., corresponding to flow elements) of process-based software applications to external services to be called by the steps. The developed REST API connectors may be available to other software application developers via a catalog of connectors. A user, e.g., developer, can now readily develop, use, and share REST API connectors for virtually any of REST API or service without needing to know details of the underlying WADL file or other interface description characterizing the exposed interface of the REST API or service; [0017] define specific REST connectors usable for implementing flow elements (e.g., steps) of a process-based software application).
Examiner has established that it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lipka with Alurralde because Alurralde’s teaching of developing REST API connectors for implementing flow elements (e.g., steps) of a process-based software application would have provided Lipka’s system with the advantage and capability to allow the system to readily develop, use, and share REST API connectors for virtually any of REST API or service without needing to know details of the underlying WADL file or other interface description characterizing the exposed interface of the REST API or service in order to improving the system performance and efficiency (see Alurralde, [0011]).
As to point (I), please see point (K) above.
For the reasons above, Applicant’s argument has not been found to be persuasive, and therefore the rejections are maintained.
Conclusion
THIS ACTION IS MADE FINAL. 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 ZUJIA XU whose telephone number is (571)272-0954. The examiner can normally be reached M-F 9:30-5:30 EST.
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, Aimee J Li can be reached at (571) 272-4169. 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.
/ZUJIA XU/Primary Examiner, Art Unit 2195
Prosecution Insights