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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for 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 cited 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 or disclosed by the examiner.
Response to Amendment
The amendment filed 12/23/2025 has been entered. Claims 6-25 remain pending in the present Office Action.
The Amendments to claims 12 and 22 have been fully considered an are sufficient to overcome the rejection under 35 U.S.C. 112(b). The rejections of claims 12 and 22 under 35 U.S.C. 112(b) have been withdrawn.
Claim Rejections - 35 USC § 103
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 6, 8-10, 13-16, 18-20 and 23-25 are rejected under 35 U.S.C. 103 as being unpatentable over MacLeod (U.S. Pub. No. 2020/0226002) in view of Carrier et al. (U.S. Pub. No. 2018/0284975), hereinafter Carrier.
Regarding claim 6, MacLeod teaches a server (FIG. 8, [0037] – “hosted remotely at a server”; [0070] – “a server computing system”), comprising:
one or more processors (FIG. 8, 804); and
one or more memories operationally coupled to the one or more processors (FIG. 8, 806, [0067] – “computing platform 800 performs specific operations by processor 804 executing one or more sequences of one or more instructions stored in system memory 806”), wherein the one or more processors are configured to:
receive data and a user request ([0061] – “user inputs that may be configured to transmit data instructions to application interface design program 720. In some cases, user 702 may transmit data 723 representing a search request to access a consolidated data store including records or other data structures […] Data 725 representing search results may be retrieved responsive to searching a consolidated data store. Next, consider computing device causes generation of a new API and causes transmission of both API data and a "commit" instruction as data 721 to version control application 724.”; [0052] – “a user 472 inputs search criteria via computing device 474 to identify records with which to generate an API. For example, consider that user 472 specifies a search that includes data representing a "path" object including "/GET" or "/PUT," and additionally may include search criteria specifying a text search for string "customer." As such, search results may include references to records 452 and 462, both of which include data originating from distinctive repositories. Next, consider that user 472 accesses a user interface 490 configured to build a new API via data selected with user inputs 491 via a design catalog generator 416”; [0056]-[0057] – “data representing search criteria may be received […] data stored in a consolidated repository may be retrieved responsive to receiving data representing the search criteria. At 608, data retrieved responsive to a search may be presented in a user interface configured to generate an application interface (e.g., a newly-generated API) based on retrieved data”), via an application programming interface (API) of a computer aided design (CAD) application (FIG. 7, [0058] – “an application interface development system 701”; [0037] – “application interface design program 220, which, in tum, may include a definition editor 208 and a code generator 209, either of which may be disposed locally on a computing device or hosted remotely at a platform server. Definition editor 208 may be an application configured to generate a user interface to facilitate entry of various inputs structured to populate an application interface specification, such as the OpenAPI specification, with data to create an application interface definition (e.g., an API definition). In some cases, definition editor 208 may present an API editor in a WYSIWYG-like user interface to generate operations (e.g., requests and responses relative to endpoints), models, and references to models, among other this. Examples of application interface design program 220 and/or definition editor 208 include StopLight Design Module or Stoplight API Design Studio™ (or API Designer) of Stoplight, Inc., Austin, Tex., U.S.A. In some examples, application interface design program 220 may be implemented as application interface design program 720 as depicted in FIG. 7.”; [0039] – “definition editor 208 may be configured to generate an API as an application interface definition”; [0042] – “An application interface, according to some examples, may be implemented as an application program interface ("API"), which may be a set of programming instructions formed to specify interoperability of one or more software components, any of which may be different applications”),
create a data processing pipeline […] ([0059] – “workflow engine 730 may be an application configured to operate as a "continuous integration pipeline" in which processes of workflow engine 730 may be triggered by trigger data 731 to automatically generate an application interface, test the application interface build, validate the application interface build, and deploy the application interface for use in production.”; [0062] – “Upon validation, workflow engine 730 may generate data 739 requesting creation of an endpoint based on a new, validated API.”) based on the data and the user request ([0052] – “build a new API via data selected with user inputs”; [0056]-[0057] – “data representing search criteria may be received into, for example, a search application. In various examples, search criteria may include one or more of (1) data representing data patterns, (2) data representing objects, (3) data representing parameters, ( 4) data representing properties, (5) data representing text strings, (6) data representing 'endpoints,' (7) data representing API documentation or other electronic documentation, (8) data representing 'models,' and the like, or any other API-related data. At 606, data stored in a consolidated repository may be retrieved responsive to receiving data representing the search criteria. At 608, data retrieved responsive to a search may be presented in a user interface configured to generate an application interface (e.g., a newly-generated API) based on retrieved data”),
process the data through the data processing pipeline ([0052] – “user 472 accesses a user interface 490 configured to build a new API via data selected with user inputs 491 via a design catalog generator 416 […] generate, build, test, validate, and deploy a new API based on data in a consolidated data store under control of a centralized design manager application.”; [0056]-[0057] – “data stored in a consolidated repository may be retrieved responsive to receiving data representing the search criteria […] generate an application interface (e.g., a newly-generated API) based on retrieved data”; [0059] – “generate an application interface, test the application interface build, validate the application interface build, and deploy the application interface for use in production.”), and
return a response to the user request as output of the data processing pipeline via the API of the CAD application ([0052], [0059], [0062] – “deploy the new API by transmitting API service data 761 to one or more computing devices or repositories to implement the new API "in production." Thus, API service data 761 may be accessible by any other deployed API for performing API-related functions by any other entity, enterprise, organization, or person.”).
MacLeod fails to expressly teach creating a data processing pipeline, comprising a plurality of API endpoints, based on the data and the user request.
However, Carrier teaches creating a data processing pipeline, comprising a plurality of API endpoints, based on the received data and user request (FIGS. 2, 4 and 7; [0059] – “Initially, a user uploads input data to server systems 10 representative of the type and/or context associated with data that the user wants to process using an API service pipeline at step 510.”; [0063]-[0064] – “orchestrator 26 may periodically search API registry 22 and/or one or more service API catalogs for one or more service APIs related to a specific input data format and/or context (e.g., medical, legal, financial, etc.). Based on the search results, orchestrator 26 may further construct and/or update one or more template pipelines associated with a specific input data format and/or context by appending one or more service APIs to an existing template pipeline registered in service pipeline catalog 24 or chaining together one or more service APIs to construct a template pipeline for processing documents related to the specific format and/or context. Orchestrator 26 may forward the representative input data, along with a request to process the representative input data, to an API service pipeline selected and/or constructed by orchestrator 26 at step 550. The selected API service pipeline may process the representative input data, in a manner as shown in FIG. 4, to generate a response object based on the representative input data at step 560, and may forward the generated response object to client systems 14”; [0041]-[0042] – “Once the APIs are registered, pipelines are defined at step 410. A pipeline definition may be created via selection of registered APIs from a GUI on a client system 14, or via a command entered on a client system 14 (e.g., which may be generated by a user […] By way of example, an HTTP PUT method may be used to define a pipeline template and enable placement of the corresponding pipeline template definition in pipeline catalog 24. The PUT method receives the API keys for the pipeline key (in a desired order of execution) and a URL for the pipeline manager API with the pipeline key to call or invoke the pipeline manager API to store the pipeline template definition in pipeline catalog 24. The pipeline key is appended at the end of the URL to create a new endpoint for the pipeline.”; [0029]-[0030] – “Pipeline manager API 250 receives a processing request 205 for pipeline 240. […] The request includes a pipeline key 210 identifying pipeline 240, and corresponding data 215 to be processed (e.g., input text, etc.) by the pipeline (e.g., in a container object 320 of the request). The text may be received as plain text or in a JSON object. The pipeline manager API retrieves the pipeline definition from pipeline catalog 24 based on pipeline key 210 to determine the APIs (e.g., APIs 220A, 220B, 220C) in pipeline 240. […].”; [0032] – “Resulting response object 230 provides results of the pipeline.”; [0015] – “A pipeline key is a uniform resource locator (URL) endpoint to which requests may be sent for the pipeline (e.g., via an HTTP POST method).”; [0049] – “The API information includes the URL (or location) of the API to be executed.” The URL retrieved for each API, e.g., see step 430 in FIG. 4, in the pipeline is the “endpoint” for each API.).
MacLeod and Carrier are considered to be analogous art to the claimed invention because they are in the same field of implementing computer-aided design applications (e.g., computer-implemented applications which assist a user in designing and generating an API and/or an API pipeline), in client-server environments. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of MacLeod to incorporate the teachings of Carrier such that the created pipeline may comprise a plurality of API endpoints as taught by Carrier. The methods of combining multiple APIs which perform specific functions to produce an API pipeline (referenced by its own pipeline endpoint), wherein the pipeline comprising a plurality of APIs, each of which can be invoked via respective endpoints of the APIs, as taught by Carrier allows for a complex operation to be dynamically formed from existing and cataloged API functions without requiring a user to manage the underlying routing of data between API functions (Carrier: [0002] and [0020]).
Regarding claim 8, the combination of MacLeod in view of Carrier teaches the server of claim 6. MacLeod further teaches wherein the data is included in a file configured according to a file type associated with the CAD application, and the file type is different from a file extension ([0024] – “identify application interface files and data components in consolidated data source 118 that may be relevant to the design of application interface 122a”; [0056] – “data stored in a consolidated repository may be retrieved responsive to receiving data representing the search criteria”; [0035] – “an application interface design program to generate application interfaces (e.g., APIs) as application interface definitions (e.g., API definitions)” [0037] – “Definition editor 208 may be an application configured to generate a user interface to facilitate entry of various inputs structured to populate an application interface specification, such as the OpenAPI specification, with data to create an application interface definition (e.g., an API definition). […] Referring back to FIG. 2, code generator 209 may be configured to generate API definitions in any specification-compliant format, such as JSON, YAML, RAML, XML, etc., which may be compliant with OpenAPI specifications.”; [0039] – “an application interface, such as an API, may be designed to include data representing any number of objects, properties, parameters, etc., and may be created as an application interface definition formatted in an application interface description language in accordance, for example, with an application interface specification. In some examples, definition editor 208 may be configured to generate an API as an application interface definition. An API description language may facilitate generation of a machine-readable description of the functionalities of an API as an API definition file. An API (e.g., an API definition file) may include data configured to drive execution or performance of any number of electronic or software-based processes and methods at a referent network location (e.g., a target network location, such as an endpoint, to which a reference points).” Data in the application interface design management platform is stored in files configured as API definitions (a “file type”), which may be of various different file extensions, e.g. .json, .yaml, .raml, .xml, etc.).
Regarding claim 9, the combination of MacLeod in view of Carrier teaches the server of claim 8. MacLeod further teaches wherein the file is accessed programmatically as an object ([0027] – “identify portions 114 (e.g., divisible and identifiable based on being an object, property, method, model, parameter, attribute, etc.) of extracted application interfaces 122b, 123b, 124b, and 125b. As shown in diagram 100, identified portions 114 may be decomposed, distilled, or separated into constituent components 114 of API or API data.”; [0039] – “an application interface, such as an API, may be designed to include data representing any number of objects, properties, parameters, etc., and may be created as an application interface definition formatted in an application interface description language in accordance, for example, with an application interface specification. […] An API description language may facilitate generation of a machine-readable description of the functionalities of an API as an API definition file.”; [0049] – “a record may be defined by an amount of source data (e.g., JSON data) associated with an API object, which may be used to demarcate and decompose each portion of an API into API data components.”; [0056] – “the search of the data associated with the multiple repositories may be performed on extracted application interface data components stored in a consolidated data repository […] search criteria may include […] (2) data representing objects” The APIs/API definition files may be decomposed into records defining components of the API, such as objects, which are searched and retrieved (“accessed”) in response to the search request.).
Regarding claim 10, the combination of MacLeod in view of Carrier teaches the server of claim 9. MacLeod further teaches wherein the object:
is at least one of a variable, a data structure, a function, or a method ([0027] – “identify portions 114 (e.g., divisible and identifiable based on being an object, property, method, model, parameter, attribute, etc.)”; [0028] – “API component data 114 to describe one or more of an object type (e.g., a GET operation, or URL path), a property type (e.g., an object description or data type), a parameter, and a string (e.g., a string "payment" or string "customer" in, for example, an objection description)."; [0043] – “data structures (e.g., different records of file system in a consolidated data store).”),
is represented in the one or more memories ([0063] – “computing platform 800 may be used to implement computer programs, applications, methods, processes, algorithms, or other software, as well as any hardware implementation thereof, to perform the above-described techniques.”; [0067] – “computing platform 800 performs specific operations by processor 804 executing one or more sequences of one or more instructions stored in system memory 806 […] Such instructions or data may be read into system memory 806 from another computer readable medium, such as storage device 808, or any other data storage technologies”; [0069] – “Received program code may be executed by processor 804 as it is received, and/or stored in memory 806”), and
is referenced with an identifier ([0028] – “associate or link a unique identifier to distinctly identify each portion 114 of the application interfaces that may be stored as a unit (e.g., as a record) of API component data 119b in a consolidated data storage device (e.g., repository 118). […] unique identifiers to a subset of attribute data that may describe a corresponding subset (or record) of API component data 114. In at least one implementation, unique identifiers may be generated as a key or a "hash" based on performing a hash function on a corresponding subset of attribute data to uniquely identify and locate a record of API component data 119b.”; [0044] – “Each unique identifier may be used to distinctly identify and access corresponding data records in a consolidated data store.” The record for each API component, such as an object, may have a unique identifier used to access the record. [0028] – “may identify attributes of a subset of API component data 114 to describe one or more of an object type (e.g., a GE T operation, or URL path), a property type (e.g., an object description or data type), a parameter, and a string (e.g., a string "payment" or string "customer" in, for example, an objection description). Identified attributes may thereby be used to characterize a subset of API component data 114 for identification purposes during a search, and, in some cases, the identified attributes may be stored as "fields"”; [0030] – “search application 117 may include data representing search criteria, such as data representing […] a string (e.g., a description specifying text strings including “’credit' 'card' 'payment' 'information'," etc .).” Alternatively, attributes of an object may include strings by which the object/record corresponding to the object can be searched for and identified, making the attribute/string “an identifier” by which the object can be “referenced”.).
Regarding claim 13, the combination of MacLeod in view of Carrier teaches the server of claim 6. MacLeod further teaches wherein the CAD application is configured as a common core (FIG. 7, Application Interface Integration Design Management Platform/application interface integration design manager 710), below a plurality of sub-applications (FIG. 7, application interface design program 720, a version control application 724, a workflow engine 730, and an application interface endpoint service module 760), the plurality of sub-applications corresponding to respective features of the CAD application ([0058] – “an example of an application interface development system implementing an application interface integration design management platform, according to some examples. Diagram 700 depicts an application interface development system 701 including an application interface design program 720, a version control application 724, a workflow engine 730, an application interface integration design manager 710, and an application interface endpoint service module 760”; [0059]-[0062] – describes the features provided by application interface design program 720, version control application 724, workflow engine 730, and application interface endpoint service module 760).
Regarding claim 14, the combination of MacLeod in view of Carrier teaches the server of claim 13. MacLeod further teaches wherein the plurality of sub-applications utilize native functions of the common core ([0060] – “application interface integration design manager 710 may include a discovery module 711, which may include a repository analyzer 712. Discovery module 711 may include logic configured to discover automatically changes or updates to APIs and their constituent components (e.g., API artifacts) using, for example, repository analyzer 712, which may have one or more functionalities as described herein. Application interface integration design manager 710 is also shown to include a design catalog generator 716, which may operate as described herein, and a test simulator 717. Test simulator 717 may be an application configured to instantiate one or more "mock" or virtual servers to test and/or validate operability of the newly-designed API or build.” FIG. 7, Application Interface Integration Design Management Platform 710 includes “native functions” implemented by discovery module 711, repository analyzer 712, design catalog generator 716 and test simulator 717, which are used by at least the workflow engine 730 and version control application 724 as shown with arrows in FIG. 7.).
Regarding claim 15, the combination of MacLeod in view of Carrier teaches the server of claim 13. MacLeod further teaches wherein the common core lies above an operating system kernel ([0042] – “An application interface, according to some examples, may be implemented as an application program interface ("API"), which may be a set of programming instructions formed to specify interoperability of one or more software components, any of which may be different applications that perform on different operating systems”; [0070] – “System memory 806 may include an operating system (''O/S") 832, as well as an application 836 and/or logic module(s) 859. In the example shown in FIG. 8, system memory 806 may include any number of modules 859, any of which, or one or more portions of which, can be configured to facilitate any one or more components of a computing system (e.g., a client computing system, a server computing system, etc.) by implementing one or more functions described herein.”; [0071] – “the described techniques may be implemented as a computer program or application (hereafter "applications")”. Applications, such as Application Interface Integration Design Management Platform/application interface integration design manager 710, are performed on operating systems, such as OS 832 of the server.).
Claims 16, 18-20, and 23-25 are directed to a method, operational at a server, comprising: the functions implemented by the processor of the server of claims 6, 8-10, and 13-15, respectively. Accordingly, claims 16, 18-20, and 23-25 are rejected as being unpatentable over MacLeod in view of Carrier for the same reasons presented with respect to claims 6, 8-10, and 13-15.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over MacLeod in view of Carrier as applied to claims 6 and 16, and further in view of Martori et al. (U.S. Pub. No. 2017/0192803), hereinafter Martori.
Regarding claim 7, the combination of MacLeod in view of Carrier teaches the server of claim 6, but fails to teach wherein the one or more processors are further configured to: send a query to a client device via the API, prior to performing a local computation at the server, to determine if a client device processor and a client device memory are sufficient to perform the local computation.
However, Martori teaches wherein the one or more processors are further configured to: send a query to a client device via the API, prior to performing a local computation at the server, to determine if a client device processor and a client device memory are sufficient to perform the local computation ([0203] – “the process 900 receives (at 910) an instruction on a client device to invoke a function of an application locally or remotely. In some embodiments, the function is an API request that is invoked by an application. The application code (e.g., a JavaScript file or JavaScript/JSON model) may include a hook, or interceptor call, that requests a dynamic determination on whether to invoke the API request locally or remotely. That is, the application makes a first call to determine whether to invoke the function locally or remotely (based on, e.g., a set of current operating conditions), then dynamically uses the result of this determination to invoke one of two function calls embedded in the code.”; [0207] – “current operating conditions on the device. For example, in some embodiments the current processing load of the client device CPU (e.g., from other applications, etc.) and/or the current memory usage.”; [0005] – “the conditions assessed […] include one or more of […] (2) a computational expense of processing the function on the client (e.g., the higher the computational expense of executing the function on the client, the more likely the application is to request that the server process the function); (3) a memory usage required to process the function on the client (e.g., the higher the memory usage on the client, the more likely the application is to request that the server process the function)”; [0009] – “calls (API requests)”).
Martori is considered to be analogous art to the claimed invention because it is in the same field of implementing computer-aided design applications in client-server environments. Martori is also considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of accessing applications using resource constrained devices. Therefore, it would have been obvious to apply the teachings of Martori such that the applications executing on the server of the MacLeod in view of Carrier determine if a client device processor and a client device memory are sufficient to perform the local computation before the server executes the computation. Doing so enables better management of resources for applications implemented in client-server environments (see Martori: [0206]-[0207]).
Claim 17 is directed to a method comprising the functions implemented by the server of claim 7. Accordingly, claim 17 is rejected as being unpatentable over MacLeod in view of Carrier as applied to claim 16, and further in view of Martori for the same reasons presented with respect to claim 7.
Claims 11 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over MacLeod in view of Carrier as applied to claims 6 and 16, and further in view of Nelson et al. (U.S. Pub. No. 2018/0321833), hereinafter Nelson.
Regarding claim 11, the combination of MacLeod in view of Carrier teaches the server of claim 6. MacLeod further teaches wherein the one or more processors are further configured to: [use] a scripting language associated with an application for CAD ([0037] – “application layer 203f may also include an application interface design program 220, which, in turn, may include a definition editor 208 and a code generator 209 […] code generator 209 may be configured to generate responses and requests in a variety of programming languages and formats, including cURL (created by Daniel Stenberg of Sweden and is maintained at curl( dot)haxx( dot) se), Python, JavaScript, Java, PHP, etc. Platform layer 203g and application layer 203f may be coded using, for example, Java®, JavaScript®, Ruby (e.g., Ruby on Rails), CSS, C+, C++, C#, C, Python™, Microsoft® .NE T, PHP, Node.js, or any other structured or unstructured programming language, or any combination thereof.”)
The combination of MacLeod in view of Carrier fails to expressly teach the one or more processors are further configured to execute a script obtained via the API and written using a scripting language.
However, Nelson teaches execute a script obtained via the API and written using a scripting language ([0067] – “During the flow plan execution phase, the automation system may execute a run-time version of the design-time flow plan using one or more flow engines. As used herein, the term “run-time flow plan” refers to a run-time engine implementation of a flow plan operating during execution phase and after being converted (e.g., compiled) by a flow plan builder API. In one embodiment, the run-time flow plan can be implemented as Java® Script Object Notation (JSON) document that includes a plurality of definitions”; [0169] – “Persons of ordinary skill in the art are aware that software programs may be developed, encoded, and compiled in a variety computing languages for a variety software platforms and/or operating systems and subsequently loaded and executed by processor 3205. In one embodiment, the compiling process of the software program may transform program code written in a programming language to another computer language such that the processor 3205 is able to execute the programming code.”; [0105] – “The flow engines 514 and 518 execute the run-time flow plan (e.g., JSON document)”).
Nelson is considered to be analogous art to the claimed invention because it is in the same field of using computer-aided design applications in client-server environments, and specifically using computer-aided design applications in generating processing pipelines. Therefore, it would have been obvious to one of ordinary skill in the art to have incorporated the teachings of Nelson into the server of MacLeod in view of Carrier to simplify the process for a user to design, run, and manage automated processes with minimized custom scripting and coding (see Nelson: [0005], [0007], and [0057]).
Claim 21 is directed to a method comprising the functions implemented by the server of claim 11. Accordingly, claim 21 is rejected as being unpatentable over MacLeod in view of Carrier as applied to claim 16, and further in view of Nelson for the same reasons presented with respect to claim 11.
Claims 12 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over MacLeod in view of Carrier as applied to claims 6 and 16, and further in view of Nelson et al. (U.S. Pub. No. 2018/0321833), hereinafter Nelson and Wibbeler (U.S. Pub. No. 2014/0033276).
Regarding claim 12, the combination of MacLeod in view Carrier teaches the server of claim 6, but fails to expressly teach wherein the one or more processors are further configured to: execute a script obtained via the API, wherein the script cannot be called by other scripts or called in a command line.
However, Nelson teaches wherein the one or more processors are further configured to: execute a script obtained via the API ([0067] – “During the flow plan execution phase, the automation system may execute a run-time version of the design-time flow plan using one or more flow engines. As used herein, the term “run-time flow plan” refers to a run-time engine implementation of a flow plan operating during execution phase and after being converted (e.g., compiled) by a flow plan builder API. In one embodiment, the run-time flow plan can be implemented as Java® Script Object Notation (JSON) document that includes a plurality of definitions”; [0169] – “Persons of ordinary skill in the art are aware that software programs may be developed, encoded, and compiled in a variety computing languages for a variety software platforms and/or operating systems and subsequently loaded and executed by processor 3205. In one embodiment, the compiling process of the software program may transform program code written in a programming language to another computer language such that the processor 3205 is able to execute the programming code.”; [0105] – “The flow engines 514 and 518 execute the run-time flow plan (e.g., JSON document)”).
Nelson is considered to be analogous art to the claimed invention because it is in the same field of using computer-aided design applications in client-server environments, and specifically using computer-aided design applications in generating processing pipelines. Therefore, it would have been obvious to one of ordinary skill in the art to have incorporated the teachings of Nelson into the server of MacLeod in view of Carrier to simplify the process for a user to design, run, and manage automated processes with minimized custom scripting and coding (see Nelson: [0005], [0007], and [0057]).
The combination of MacLeod in view of Carrier and Nelson fails to expressly teach wherein the script cannot be called by other scripts or called in a command line.
However, Wibbeler teaches wherein the script cannot be called by other scripts or called in a command line (Claim 1 – “receiving a script for execution within a scripting host of an application executing on a processor of a computing device; identifying, by the scripting host, a function called within the script and a context from which the identified function is called; retrieving, by the scripting host, from a memory, a security setting representation of the identified function based at least in part on the context from which the identified function is called; and the scripting host, based on the security setting representation indicating that the identified function is not allowed in the context from which the identified function is called, preventing execution of the identified function in the context from which the identified function was called”; [0012] – “A "function," as used herein, refers to a set of instructions that performs a specific task when executed […] the function may be directly interpreted by an interpreter, such as a scripting host, where the set of instructions is in scripting language or in extension language. The function may be exposed or made available for execution by way of, for example, a dynamic link library, an API”; [0014] – “a context from which the function call 102 is received, such as in a batch processing context, a command line context, a context where the function call is embedded within a script or compiled application, and other context from which the function call 102 may be received.”; [0025] – “Preventing 308 execution of the identified 304 function may include returning an exception in the received 302 script or halting further execution of the received 302 script entirely.” The “function” may be a set of instructions in a scripting language, i.e., a “script”, and may be prevented from being executed (“cannot be executed”) based on the function call being received from a command line or being embedded in a script (“other scripts”).).
Wibbeler is considered to analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of executing scripts obtained via an API. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of MacLeod in view of Carrier and Nelson to incorporate the teachings of Wibbeler. Restricting the execution of a script, e.g. preventing execution when the script is called from a command line or from other scripts, as taught by Wibbeler may improve security and reduce exposure to potential vulnerabilities by preventing scripts from being executed in a context where they are believed to be exploitable for nefarious purposes (Wibbeler: [0011] and [0022]).
Claim 22 is directed to a method comprising the functions implemented by the server of claim 12. Accordingly, claim 22 is rejected as being unpatentable over MacLeod in view of Carrier as applied to claim 16, and further in view of Nelson and Wibbeler for the same reasons presented with respect to claim 12.
Response to Arguments
Applicant’s arguments, see page 7 of the Remarks, filed 12/23/2025, with respect to the rejection of claims 12 and 22 under 35 U.S.C. 112(b) have been fully considered and are persuasive. The rejection of claims 12 and 22 under 35 U.S.C. 112(b) has been withdrawn.
Specifically, as amended, claims 12 and 22, although reciting a negative limitation, clearly set forth the metes and bounds of the claimed subject matter, and therefore are not considered to be indefinite.
Applicant’s arguments with respect to claim 6 and 16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argues MacLeod fails to teach the pipeline “comprising a plurality of API endpoints” as recited by amended claims 6 and 16. However, the Examiner has relied upon new reference Carrier (U.S. Pub. No. 2018/0284975) to teach the created pipeline “comprising a plurality of API endpoints” as recited by amended claims 6 and 16.
See the rejection of claim 6 under the section titled Claim Rejections - 35 USC § 103 for specific details regarding the rejection of claims 6 and 16 as being unpatentable over MacLeod in view of Carrier.
No additional specific arguments were presented with respect to dependent claims 7-11, 13-15, 17-21, and 23-25.
Applicant’s arguments with respect to claim 12 and 22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argues none of the previously cited references (MacLeod, Martori, nor Nelson) teach “wherein the script cannot be called by other scripts or called in a command line” as recited by amended claims 12 and 22. However, the Examiner has relied upon new reference Wibbeler (U.S. Pub. No. 2014/0033276) teaches executing a script, “wherein the script cannot be called by other scripts or called in a command line”.
See the rejection of claim 12 under the section titled Claim Rejections - 35 USC § 103 for specific details regarding the rejection of claims 12 and 22 as being unpatentable over MacLeod in view of Carrier, Nelson and Wibbeler.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
CARROLL et al. (U.S. Pub. No. 2023/0064770) teaches an API endpoint is generally identified by a URL (see [0011]).
Mantin et al. (U.S. Patent No. 10,917,401) teaches an API endpoint is the location where an API can be accessed, and an API endpoint is often provided in the form of a URL (see Col. 1, lines 34-40).
Banks et al. (U.S. Pub. No. 2020/0342148) teaches an API for a CAD application, wherein the API comprises a plurality of functions, each corresponding to a parameter of a simulation file, where inputs to the API from the application are used to create and edit the simulation file, and the API is used to then run the simulation file (see Abstract, [0016], [0019] and [0037]-[0039]).
Swope et al. (U.S. Patent No. 10,521,195) teaches a software-based workflow design tool which enables the specification and execution of workflows, where the workflows may be sequences of actions that invoke and utilize functions provided by one or more APIs through their URL (see Abstract, Col. 1, lines 7-52).
Rappoport et al. (U.S. Patent No. 7,099,803) teaches an API used for exchanging computer aided design data between distinct CAD systems (see Col. 1, lines 29-32, and Col. 2, line 61-Col. 3, line 3).
Malaugh et al. (U.S. Patent No. 6,445,974) teaches an API comprising a library of generic CAD functions, each for directing a graphical manipulation process, and each based on a platform-specific CAD function (see Abstract, Col. 4, lines 12-22).
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 JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 9:00 am - 5:00 pm.
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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194