DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are presented for the examination.
The cross reference related to the application cited in the specification must be updated (i.e. update the relevant status, with PTO serial numbers or patent numbers where appropriate, on para[0001], ln 1-2). The specification should be so revised.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 of US Patent : US 12450105 B1. Although the claims at issue are not identical, they are not patentably distinct from each other because both computer systems comprise substantially the same elements.
US Patent: US 12450105 B1 teaches providing an interface exposed to a plurality of remote systems( providing content to facilitate a user interface that may be exposed to a plurality of remote systems)
, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system(each remote system of the plurality of remote systems is located remotely from the system and is configured to perform different types of operations );
receiving, via the interface and from a first remote system, one or more selections of a first set of one or more functionalities provided by the system for use by the first remote system( receiving one or more selections corresponding to the user interface; defining a partial system integration of the at least one remote system with the system based at least in part on the one or more selections, defining a set of one or more functionalities to be used by the at least one remote system)
defining a partial integration of the first remote system with the system based at least in part on the selected first set of one or more first set of one or more functionalities( defining a set of one or more functionalities to be used by the at least one remote system after the partial system integration of the at least one remote system with the system),
generating and transmitting integration specifications to the first remote system to facilitate use of the selected first set of one or more functionalities of the system by the first remote system( generating integration specifications particularized to facilitating use of the set of one or more functionalities by the at least one remote system after the partial system integration of the at least one remote system with the system; transmitting, to the at least one remote system, the integration specifications to facilitate the partial system integration of the at least one remote system with the system)
The difference between claims 1,9, 17 of US Patent and this case are catalog interface and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, the catalog interface comprises a graphical user interface displaying selectable interface options for modules of functionalities; receiving ; defining the selected first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration and identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system. It would have been obvious to one of the ordinary skill level in the art to include above feature because this provides benefits such as an ability to execute multiple computer systems.
this is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 of US Patent 12/574,279Although the claims at issue are not identical, they are not patentably distinct from each other because both computer systems comprise substantially the same elements.
US Patent 12/574,279 teaches providing an interface exposed to a plurality of remote systems( providing content to facilitate a user interface that may be exposed to a plurality of remote systems)
, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system(each remote system of the plurality of remote systems is located remotely from the system and is configured to perform different types of operations );
receiving, via the interface and from a first remote system, one or more selections of a first set of one or more functionalities provided by the system for use by the first remote system( receiving one or more selections corresponding to the user interface; defining a partial system integration of the at least one remote system with the system based at least in part on the one or more selections, defining a set of one or more functionalities to be used by the at least one remote system)
defining a partial integration of the first remote system with the system based at least in part on the selected first set of one or more first set of one or more functionalities( defining a set of one or more functionalities to be used by the at least one remote system after the partial system integration of the at least one remote system with the system)
generating and transmitting integration specifications to the first remote system to facilitate use of the selected first set of one or more functionalities of the system by the first remote system( generating integration specifications particularized to facilitating use of the set of one or more functionalities by the at least one remote system after the partial system integration of the at least one remote system with the system; transmitting, to the at least one remote system, the integration specifications to facilitate the partial system integration of the at least one remote system with the system);
The difference between claims 1,7, 13 of the US patent and this case are catalog interface and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, wherein the catalog interface comprises a graphical user interface displaying selectable interface options for modules of functionalities, defining the selected first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system. It would have been obvious to one of the ordinary skill level in the art to include above feature because this provides benefits such as an ability to execute multiple computer systems.
this is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 of US Patent application: 19/467,039. Although the claims at issue are not identical, they are not patentably distinct from each other because both computer systems comprise substantially the same elements.
US Patent application:19/467,039 teaches transmitting integration specifications to the first remote system to facilitate use of the selected first set of one or more functionalities of the system by the first remote system (transmitting, to the remote system, integration specifications particularized to facilitating use of a set of one or more functionalities by the remote system after the partial system integration of the remote system with the system).
The difference between claims 1, 8, 15 of the copending application and this case are catalog interface and providing an interface exposed to a plurality of remote systems, receiving, via the interface and from a first remote system, one or more selections of a first set of one or more functionalities provided by the system for use by the first remote system, defining a partial integration of the first remote system with the system based at least in part on the selected first set of one or more first set of one or more functionalities , generating and transmitting integration specifications ,incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, wherein the catalog interface comprises a graphical user interface displaying selectable interface options for modules of functionalities, defining the selected first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system. It would have been obvious to one of the ordinary skill level in the art to include above feature because this provides benefits such as an ability to execute multiple computer systems.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
§ 101 2. 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, 2, 8, 9, 15, 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As to Claims 1, 8, 15 have been rejected under 35 USC 101 for abstract idea without significantly more. Under Step 2A, Prong 1, the “selections of a first set of one or more functionalities”, “ defining a partial integration of the first remote system” recite a mental process since “ Select” and “define” are functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ providing a catalog interface exposed to a plurality of remote systems, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system; receiving, via the catalog interface and from a first remote system, generating and transmitting integration specifications to the first remote system to facilitate use of the selected first set of one or more functionalities of the system by the first remote system; and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, wherein the catalog interface comprises a graphical user interface displaying selectable interface options for modules of functionalities; (i)defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system;” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ providing a catalog interface exposed to a plurality of remote systems, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system; receiving, via the catalog interface and from a first remote system” - this generally have been a mental process although the remote system could be a generic computer component if the spec describes it as actual computer hardware.
“generating and transmitting integration specifications to the first remote system to facilitate use of the selected first set of one or more functionalities of the system by the first remote system; and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system” - this is mere instructions to apply the mental process under mpep 2106.05(f), amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
As to Claims 2, 9, 16, have been rejected under 35 USC 101 for abstract idea without significantly more. Under Step 2A, Prong 1, the “ defining a second partial integration”, “ selections of a second set of one or more functionalities” recite a mental process since “ Select” and “define” are functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ providing a catalog interface exposed to a plurality of remote systems, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system; receiving, via the catalog interface and from a first remote system, generating and transmitting integration specifications to the first/second remote system to facilitate use of the selected first/second set of one or more functionalities of the system by the first remote system; and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, wherein the second set of one or more functionalities is different from the first set of one or more functionalities, (i)defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ providing a catalog interface exposed to a plurality of remote systems, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system; receiving, via the catalog interface and from a first remote system” - this generally have been a mental process although the remote system could be a generic computer component if the spec describes it as actual computer hardware.
“generating and transmitting integration specifications to the first remote system to facilitate use of the selected first/second set of one or more functionalities of the system by the first remote system; and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, (i)defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system” - this is mere instructions to apply the mental process under mpep 2106.05(f), amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application. See MPEP 2106.05(d). Thus, the claim is not patent eligible.
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.
Claim(s) 1, 8, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Stefanov(US 20180145884 A1) in view of Rao(US 20200264937 A1) and further in view of BAHRAMI(US 20220035661 A1).
As to claim 1, Stefanow teaches A system comprising: one or more processing devices and memory communicatively coupled with and readable by the one or more processing devices, the memory comprising processor-readable instructions which, when executed by the one or more processing devices( The processor 1012 of the illustrated example includes a local memory 1013 (e.g., a cache), and executes instructions to implement the example systems 100, 300 or portions thereof, such as the vA 320-324, component server 330-336, management endpoint 340-344, and management agent 350-356. The processor 1012 of the illustrated example is in communication with a main memory including a volatile memory 1014 and a non-volatile memory 1016 via a bus 1018. The volatile memory 1014 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory 1016 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 1014, 1016 is controlled by a memory controller, para[0092])
providing a catalog interface exposed to a plurality of remote systems( the service provider 410 publishes the resource definition to the catalog 480, para[0067], ln 2-5)
wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system( FIG. 1, the example cloud computing platform provider 110 may provide multiple deployment environments 112, for example, for development, testing, staging, and/or production of applications, para[0039], ln 1-6/ The service provider 410 of the illustrated example further invokes any appropriate IaaS functionality, SaaS (“Software-as-a-Service”) functionality, PaaS (“Platform-as-a-Service”) functionality and/or, more generally, any appropriate XaaS functionality to execute the operations defined by the customer for the custom resource, para[0066], ln 25-31/ the service provider 410 also publishes the lifecycle definition to the catalog lifecycle manager 470 to enable the lifecycle manager 470 to manage the lifecycle of the custom resource, para[0086], ln 2-6)
receiving, via the catalog interface and from a first remote system, one or more selections of a first set of one or more functionalities provided by the system for use by the first remote system( the service provider 410 publishes the lifecycle definition to the lifecycle manager 470 via an example API call 505 (e.g., such as an example REST API call 505) and publishes the resource definition to the catalog 480 via an example API call 510 (e.g., such as an example REST API call 510). In response to the API call 505, the lifecycle manager 470 creates (e.g., defines) a state machine modeling the lifecycle states and state transitions specified in the received lifecycle definition (e.g., such as the example lifecycle definition illustrated in Table 1). The lifecycle manager 470 also associates each state with the respective event(s) and set of available operations specified in the lifecycle definition, and then initializes the state machine to its starting lifecycle state. In response to the API call 510, the catalog 480 creates a catalog item for the custom resource using the name and details specified in the resource definition. The catalog 480 then makes the catalog item available to customers via a catalog interface, para[0072]/ Next, in response to the customer selecting a particular operation of the custom resource to be performed, the catalog 480 sends an example message 525 (e.g., a REST API call 525) to the lifecycle manager 470 identifying the selected operation of the custom resource to be performed. For example, the selected operation could be the “enable” operation for the AD User resource described above. In response to the message 525, the lifecycle manager 470 evaluates the state machine for the custom resource to verify the selected operation can be performed in the current state of the custom resource. Assuming the selected operation is verified (e.g., the “enable” operation is permitted for the AD User resource when in the “created” lifecycle state), the lifecycle manager 470 then sends an example message 530 (e.g., a REST API call 525) to the service provider 410 to instruct the service provider 410 to execute the selected operation. In response to the message 530, the service provider 410 invokes any appropriate XaaS functionality to execute the selected operation, para[0047]/ querying the lifecycle manager to obtain a first set of operations available for execution in a current lifecycle state of the custom resource, and updating the catalog item to include information specifying the first set of operations available for execution in the current lifecycle state of the custom resource. Some such disclosed example methods also include, in response to a first message from the catalog identifying a first one of the first set of operations specified in the catalog item has been selected for execution, sending a second message from the lifecycle manager to the service provider to instruct the service provider to execute the first one of the first set of operations.), para[0032], ln 8-21) ;
defining a partial integration of the first remote system with the system based at least in part on the selected first set of one or more first set of one or more functionalities( “Infrastructure-as-a-Service” (also commonly referred to as “IaaS”) generally describes a suite of technologies provided by a service provider as an integrated solution to allow for elastic creation of a virtualized, networked, and pooled computing platform (sometimes referred to as a “cloud computing platform”), para[0003], ln 1-6/ The service provider 410 of the illustrated example further invokes any appropriate IaaS functionality, SaaS (“Software-as-a-Service”) functionality, PaaS (“Platform-as-a-Service”) functionality and/or, more generally, any appropriate XaaS functionality to execute the operations defined by the customer for the custom resource, para[0066], ln 25-31/ At block 710, the service provider 410 publishes the lifecycle definition to the example lifecycle manager 470 of the vA 320, as described above. At block 715, the service provider 410 publishes the resource definition to the example catalog 480 of the vA 320, as described above. At block 720, the service provider 410 receives a message from the lifecycle manager 470 specifying a selected operation to be performed in the current state of the custom resource. At block 725, the service provider 410 invokes the appropriate XaaS functionality to perform the specified operation, para[0086], 8-19/ Some such disclosed example methods also include, in response to a first message from the catalog identifying a first one of the first set of operations specified in the catalog item has been selected for execution, sending a second message from the lifecycle manager to the service provider to instruct the service provider to execute the first one of the first set of operations, para[0032], ln 13-21)
generating and transmitting integration specifications to the first remote system to facilitate use of the selected first set of one or more functionalities of the system by the first remote system( In some disclosed examples, the extensibility service enables definitions specifying a custom resource and its lifecycle characteristics to be provided in a human-readable data format, such as YAML (Yet Another Markup Language), JSON (JavaScript Object Notation), etc., para[0029], ln 15-21/ a customer defines the AD User resource via the service provider 410 as an XaaS resource by specifying the resource definition and the lifecycle definition, para[0015], ln 10-16/ FIGS. 5 and 6, respectively. The example message sequence diagram 500 of FIG. 5 begins with the service provider 410 receiving, via the interface provided by its extensibility service, a resource definition and a lifecycle definition for a custom resource in a declarative manner, para[0069], ln 5-9/ After receiving the resource definition and the lifecycle definition for the custom resource, the service provider 410 publishes the lifecycle definition to the lifecycle manager 470 via an example API call 505 (e.g., such as an example REST API call 505) and publishes the resource definition to the catalog 480 via an example API call 510 (e.g., such as an example REST API call 510). In response to the API call 505, the lifecycle manager 470 creates (e.g., defines) a state machine modeling, para[0072], ln 1-10/ the lifecycle manager 470 then sends an example message 530 (e.g., a REST API call 525) to the service provider 410 to instruct the service provider 410 to execute the selected operation. In response to the message 530, the service provider 410 invokes any appropriate XaaS functionality to execute the selected operation, para[0074], ln 14-20)
and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface( the lifecycle definition defines the lifecycle states of the AD User resource, which include states (e.g., identified by the “id” keyword), such as “ created” (e.g., but not yet activated), “enabled” (e.g., activated), “disabled,” “destroyed,” etc. The example lifecycle definition also defines the possible transitions among the states (e.g., identified by the “transitions” keyword) as well as the events causing the defined transitions (e.g., identified by the “event” keyword). Furthermore, the example lifecycle definition defines the set of operations available at each state (e.g., identified by the “action” keyword). For example, an operation to change a user password may be available in the “enabled” state but not in the “created” state because the user password cannot be changed until the account is enabled, para[0070], ln 20-35/ hen, the lifecycle manager 470 returns the custom resource's current lifecycle state and the set of available operations defined for that lifecycle state to the catalog 480 via an example message 520 (e.g., such as a REST API call 520). In response to the message 520, the catalog 480 updates the catalog item for the custom resource to present the set of operations available for the custom resource in its current lifecycle state. For example, if the custom resource is the example AD User resource described above and its current state is “created,” the catalog item for the AD User resource may be updated to indicate the available operations are “enable” and “disable” in the resource's current state (which is “created” in this example), para[0073], ln 8-21/ allows a customer to register a custom resource for lifecycle management, and to register the custom resource's lifecycle states, transitions between states, operations available at each state, etc., in a declarative way, para[0029], ln 5-10/ the lifecycle definition further specifies respective sets of operations available for execution in respective ones of the lifecycle states supported by the custom resource, and permitted transitions among the lifecycle states supported by the custom resource. Some such disclosed example methods further include, in response to a user query of the catalog associated with the custom resource, querying the lifecycle manager to obtain a first set of operations available for execution in a current lifecycle state of the custom resource, and updating the catalog item to include information specifying the first set of operations available for execution in the current lifecycle state of the custom resource, para[0032], ln 2-16/ As disclosed in further detail below, the interface provided by the extensibility service implemented by the service provider 410 also accepts a lifecycle definition for a custom resource, which specifies, for example, customer-defined lifecycle states for custom resource, customer-defined transitions between lifecycle states, customer-defined events causing state transitions, customer-defined operation(s) available at each state, etc. The service provider 410 of the illustrated example further invokes any appropriate IaaS functionality, SaaS (“Software-as-a-Service”) functionality, PaaS (“Platform-as-a-Service”) functionality and/or, more generally, any appropriate XaaS functionality to execute the operations defined by the customer for the custom resource, para[0066], ln 18-32)
Rao teaches wherein each remote system of the plurality of remote systems is configured to perform different types of operations(The NAL 214 may perform abstraction for the infrastructure. The NAL 214 may abstract the specific processes and/or requirements associated with a specific network device such that the NAL 214 may run modular tasks on many different types of network devices. In some cases, the abstraction at the NAL 214 may allow support for new types of network devices introduced into the system, for new infrastructure architecture types, or both. For example, any device (e.g., a device that emits digital signals and can receive transmissions from the integration platform) may be added into the infrastructure 216 and handled by the NAL 214., para[0032], ln 1-12/ the integration platform may support a migration process from a first infrastructure architecture (e.g., a legacy network) to a second infrastructure architecture (e.g., a modern network). Additionally or alternatively, the integration platform may support new devices , para[0046], ln l5-21/ the NAL 214 may store network-related information for the network devices of the infrastructure 216. Each network device (e.g., each virtual server, physical server, router, connection, etc.) may be managed as a node or endpoint. The nodes may be grouped (e.g., based on type, classification, etc.) and may have one or more properties and connections, para[0033], ln 1-9/ The NAL 530 may receive, from the SCL 520, a modular task of the set of modular tasks. At 560, the NAL 530 may determine a type of infrastructure architecture associated with the integration platform. For example, the infrastructure architecture may be a “legacy” architecture, a “modern” architecture, or may be associated with a specific provider, controller, or some combination of these. At 565, the NAL 530 may modify the modular task according to the determined type of infrastructure architecture. At 570, the integration platform 505 (e.g., at the NAL 530) may execute the modified modular task on one or more network devices 515 of the infrastructure architecture. These network devices 515 may include servers, switches, access points, routers, modems, hubs, bridges, repeaters, racks, or any combination of these or other network devices 515, para[0057]/The SCL may parse the execution request to determine a set of modular tasks and may send a modular task to the NAL (e.g., via an API). In some cases, the SCL may modify one or more of the tasks based on user information received from the user device. The NAL may receive the modular task and may determine network connections between network devices in the system. In some cases, the NAL may determine a type of infrastructure architecture associated with the integration platform and may modify the modular task based on the type of infrastructure architecture. The NAL may execute the modular task on one or more network devices of the infrastructure architecture, para[0017], ln 8-23).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Stefanow with Rao to incorporate the above feature because this supports efficient and flexible modifications to applications and architecture within a system, the system may implement an integration solution to provide orchestration, automation, and integration for network infrastructure.
Bahrami teaches wherein the catalog interface comprises a graphical user interface displaying selectable interface options for modules of functionalities( FIG. 3 illustrates an example of a user interface 300 for selecting a category of tasks, in accordance with one or more embodiments of the present disclosure. For example, an administrator may be presented with the user interface 300 to facilitate the selection of an API or sample task to use as a template when generating a task. The user interface 300 may include one or more windows 310 (such as the windows 310a, 310b, 310c, and 310d) representative of a given API. In some embodiments, the information of the APIs corresponding to the windows 310 may be obtained via the API specification (e.g., an OAS of the API). Using the window 310c as an example, the window 310c may include a title 312c, a version 314c, a description 316c, and a button 318c. By invoking the button 318c, the administrator may be taken to a list of tasks that may be performed using the given API associated with the window 310c. For example, the tasks may include already-generated tasks, a template of a task associated with the API, etc, para[0060] to para[0061]/ Fig. 3/ At block 750, a graphical user interface (GUI) may be presented via which a user selects aspects of the task object. For example, the administrator may be presented with one or more elements of a GUI via which the administrator may input information regarding the task, such as a title, description, and one or more parameters or values associated with the task, para[0085]);
defining a partial integration of the first remote system with the system based at least in part on (i) defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system( The system 100 may include a task system 110 used to generate, execute, and/or combine tasks. An administrator 120 may interact with the task system 110 to generate tasks and/or facilitate combinations of tasks. An end-user 130 may interact with the task system 110 to select a task for execution. One or more API specifications 140 may be accessed by the task system 110 to obtain information regarding various APIs. An API host 150 may be accessed when executing a task to invoke the functionality of an associated API. Cloud systems 160 (such as the cloud systems 160a /160b) may represent remote systems that may be invoked by the task system 110 to execute a given task, para[0029], ln 3-16/ in some embodiments, one or more APIs may be presented to the administrator 120 for selection of an API to be associated with a new task being generated. An example of an interface illustrating such presentation is illustrated in FIG. 3. In some embodiments, the administrator 120 may select a template (or a preexisting task as a template), may select an API as the API to be used for the task, etc. , para[0032], ln 1-8/ During task execution, a user may identify a task for execution. Such execution may be performed locally or in a targeted environment (e.g., in a specific programming language, in a cloud-based service, etc.). The task may execute and provide the user with an interface via which the user may provide input to facilitate replacing any placeholder values of the task with the user-input values. The response of the task execution (e.g., the result of the specific implementation of the API call) may be returned to the user. In some embodiments, the response may be stored for other use, para[0025]/ In some embodiments, the end-user 130 may identify a particular cloud system 160 upon which the end-user 130 would like the task executed and/or in which the API call of the task is to be executed. For example, the end-user 130 may designate a task to be executed completely within a RUNMYPROCESS cloud system, an AMAZON WEB SERVICES (AWS) cloud system, a MICROSOFT cloud system, a GOOGLE cloud system, etc. In some embodiments, the entire task execution, including presenting of a user interface to obtain user input may be implemented via the cloud system 160. For example, the task system 110 may invoke an API of the cloud system 160a to cause the cloud system 160a to generate a user interface for presentation to the end-user 130 to obtain user input. The task system 110 may then generate a complete API call using the user input obtained via the cloud system 160a and the complete API call may be provided to the cloud system 160a for execution of the API call via the cloud system 160a rather than being executed via the task system 110. One example of executing the task in a cloud-based system may be described with greater detail in FIG. 10. While the cloud systems 160 are provided as one example, the end-user 130 may identify a local server (such as the task system 110), a remote server (such as the API host 150), a local computer (such as a computing device used by the end-user 130 to access the task system 110), etc., para[0042]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this supports to task generation, task execution, and/or task combination for tasks related to application programming interfaces (APIs).
As to claims 8, 15, they are rejected for the same reason as to claim 1 above. In additional, Stefanov teaches non-transitory, machine-readable media(a non-transitory computer and/or machine readable medium, para[0085], ln 21-25).
Claim(s) 2, 9, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Stefanov(US 20180145884 A1) in view of Rao(US 20200264937 A1) in view of BAHRAMI(US 20220035661 A1) and further in view of Eda(US 20170054796 A1).
As to claim 2, Eda teaches defining a second partial integration of a second remote system of the plurality of remotes systems with the system based at least in part on one or more selections of a second set of one or more functionalities provided by the system for use by the second remote system; and generating and transmitting second integration specifications to the second remote system to facilitate use of the selected second set of one or more functionalities of the system by the second remote system, wherein the second set of one or more functionalities is different from the first set of one or more functionalities( . The method used to select the storage node from the storage cluster farm may result in overall optimization by the offloaded compute execution. An intelligent middleware may be integrated with the storlet's architecture to aid in determining the node to be used for executing a specified computation workload based on the maximum data availability (i.e., reduced I/O operations) required for completing execution of the respective compute algorithm, para[0030], ln 3-15/object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming, para[0019], ln 7-14/ two entities/node groups (i.e., proxy nodes and storage nodes). Proxy nodes are used for distributed load handling/request handling nodes into the namespace and storage nodes are responsible for writing into disks/storage subsystems. The storlet architecture (i.e., embedded compute engine architecture) is a software engine present within the nodes (e.g., proxy or storage nodes) having the end user determine the computation algorithm and deploy it or pass the engine as a standard object PUT operation, para[0025], ln 1-16/ based on the identified class of object, the appreciate storage node/location may be determined. For example, the storage path for algorithm 1 may be “customer_details (computation_algorithm1): /storage/path1.”Next, the storlet engine on the nodes may be invocated based on the classification and respective storage paths configured using a share-nothing architecture. Nodes may be used for storlet invocation based on the category of computation algorithm and the localization for servicing the computation algorithm. For example, for the deployed algorithm class {‘create excel of salary paid during Q4’ } would map to computation_algorithm2 and objects would be stored in storage_node10 using the path “/storage/path2” (i.e., all objects stored in this path are striped only on disks local to storage_node10), para[0033] to para[0034]/ Users 510a-b, interact with the storlet system 500 by uploading an object or computational algorithm as described previously. In the scenario when a user 510a-b uploads an object, the load balancer 502 receives the object and sends the object to a proxy node running middleware 504. The middleware 504 may then decide on which storage node 508a-e to store the object using the object placement process 200 (FIG. 2) as described previously. Once a storage node (e.g., 508c) has been chosen, a known object service 506 (e.g., Swift) may be used to store the object on the designated storage node (e.g., 508c), para[0060]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this determines the computation algorithm and deploy it or pass the engine as a standard object PUT operation.
As to claims 9, 15, they are rejected for the same reason as to claim 2 above.
Claim(s) 3, 10, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Stefanov(US 20180145884 A1)in view of Rao(US 20200264937 A1) in view of BAHRAMI(US 20220035661 A1) and further in view of Olsen( US 7925994 B2).
As to claim 3, Olsen teaches the catalog interface comprises a graphical user interface displaying selectable interface options for modules of functionalities( and displaying the plurality of user selectable task icons corresponding to the category specific set of tasks or functions for the selected navigation category in a display area of a display window of a navigation interface display, wherein each of the user selectable task icons includes a graphical symbol associated with one of the tasks or functions of the category specific set of functions or tasks, and wherein the plurality of display formats for the plurality of user selectable task icons includes a flow chart view, showing the plurality of the user selectable task icons for the category specific set of tasks or functions corresponding to the selected navigation category in order of performance of the tasks, and a list view displaying one or more of the same user selectable task icons as the flow chart view corresponding to the selected navigation category in a list order, wherein the flow chart view and the list view are alternately displayed in the same display area depending upon the selected display format, col 11, ln 20-39).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this allow a user to select different tasks and/or functions through a user interface.
As to claims 10, 17, they are rejected for the same reason as to claim 3 above.
Claims 4, 11, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Stefanov(US 20180145884 A1) in view of Rao(US 20200264937 A1) in view of BAHRAMI(US 20220035661 A1) and further in view of Wistow(US 20170126538 A1).
As to claim 4, Wistow teaches the operations further comprising providing a sandbox environment for the first remote system to test the selected first set of one or more functionalities prior to deployment in a production environment( with specific regard to implementations of testing and evaluating content-related code such as new code to be implemented in connection with CDN 100, FIG. 1 illustrates one or more implementations of a new code diagnostic and testing system, where admin users can include (but are not limited to) individuals associated with various types of parties such as content providers, para[0026], ln 1-10/ Processing module 746 is configured to process data collected from the content delivery network and to do so, at least in part, in accordance with defined diagnostic testing, unit testing, regression testing, staging and other testing and diagnostic functions. Collected data can include data from sources and/or locations identified in connection with relevant diagnostic and testing parameters and functions, para[0040], ln 1-10/ FIGS. 4 and 5 show implementations of one or more systems on which this type of testing can be run. In system 400 of FIG. 4, the admin user 143 can utilize a user interface such as admin console 444 that allows the admin user 143 to select the testing function (e.g., unit testing, regression testing). Test data is then provided to a content delivery network “sandbox” environment 492 which can be a virtual, pseudo or actual CDN. Facsimile user requests and other preselected inputs can then be used to perform the regression testing within sandbox environment 492. One or more implementations are illustrated in FIG. 5 which shows a system 500 for testing of content-related code such as new code, para[0039], ln 1-14/ FIG. 8A is button 810 for “Code Testing” that allows an admin user to select a content-related code testing application (or suite of applications). FIG. 8B illustrates a sample target content consumption assessment application console 820 that provides an admin user with a selection of testing methodologies that can be invoked in connection with testing content-related code by choosing from among buttons 824, para[0044], ln 16-34).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this facilitates testing of content-related code (e.g., new content and new content-related code, collectively “new code”) in a content delivery network, especially new code developed and supplied by content providers.
As to claims 11, 18, they are rejected for the same reason as to claim 4 above.
Claim(s) 5, 12, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Stefanov(US 20180145884 A1) in view of Rao(US 20200264937 A1) in view of BAHRAMI(US 20220035661 A1) in view of Wistow(US 20170126538 A1) and further in view of Qureshi( US 20180196741 A1)
As to claim 5, Qureshi teaches the sandbox environment allows simulation of the selected first set of one or more functionalities and testing of one or more selected application programming interfaces for connections of the first remote system( The test container may be further configured to perform tests on the received software, such as executing a script to determine whether the received software has any software errors or defects or has any issues (e.g., compatibility) with the device 102. For example, such testing may evaluate whether the received software executes within the test container 110, responds correctly to various inputs, performs its functions within an acceptable time, is stable, and achieves the intended results. Test results may be uploaded to the deployment service 112 for further analysis, para[0024], ln 1-11/ The software package may comprise at least a portion of the files and libraries necessary to execute the packaged software, although, as will be described, in many cases, the software package may include all files necessary to execute the packaged software and the deployment service or a deployment agent on the device and/or the container encapsulation engine on the device may selectively choose which files of the set of files need to be downloaded to the device, para[0070], 8-18).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this improves the functioning of computer systems by reducing the resources required to deploy the software update by installing only those portions of the software update not already resident on the computing system.
As to claims 12, 19, they are rejected for the same reason as to claim 5 above.
Claim(s) 6, 7, 13, 14, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Stefanov(US 20180145884 A1) in view of Rao(US 20200264937 A1) in view of BAHRAMI(US 20220035661 A1) and further in view of Lusk(US 10552442 B1).
As to claim 6, Lusk teaches the integration specifications include security protocols, authentication credentials, and data mapping particularized to the selected first set of one or more functionalities(The client application 1604 invokes the API 1610 by submitting a request to the API gateway service 1602 that includes API credentials that authorize access to the API 1610. The API gateway service 1602 examines the frontend cache 1616 and determines whether the frontend cache includes a cached result for the request. If the frontend cache 1616 includes a non-expired matching request, the corresponding result is returned to the client application 1604. If the frontend cache 1616 does not include a matching request, the API gateway service invokes the API 1610., col 20, ln 62-67 to col 21, ln 1-6/ An API gateway console interfaces with the API gateway service and allows administrators to generate and manage APIs. Using the API gateway, an administrator may select an existing REST API to be modified, col 2, ln 60-65/ As the API receives requests from the client applications, the API gateway service stores the API requests and results in the frontend cache. When a client makes a call to an API, the API gateway service searches the frontend cache and determines whether the cache contains a result that matches the current call. If the cache includes a matching result and the matching result has not expired, the API gateway service returns the matching result without invoking the API, col 4, ln 43-45).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the above teaching to incorporate the above feature because this allows access to the backend credential, which is stored elsewhere.
As to claim 7, Stefanow teaches updating the partial integration and the integration specifications to facilitate use of the additional functionalities of the system( para[0032], ln 8-21) the first remote system is after the partial integration of the first remote system to facilitate use of the selected first set of one or more functionalities( col 22, ln 7-20/ col 21, ln 20-35) for the same reason as to claim 6 above.
As to claims 13, 14, 20, they are rejected for the same reasons as to claims 6, 7 above.
Response to the argument:
A. Applicant amendment filed on 06/16/2026 has been considered but they are not persuasive:
Applicant argued in substance that :
(1) “ accordingly, the claims cannot be performed mentally or in the human mind. The amended claims are directed to a concrete way of establishing and incrementally updating a partial machine integration between a system and remote systems through a graphical catalog interface and particularized APIs, not to disembodied decision-making. Furthermore, when looking at the ordered combination of the claim features, not only do the claims demonstrate that the claim as a whole amounts to significantly more than the alleged abstract idea (which allegation Applicant does not admit or agree with)”
(2) “ Stefanov and Rao fail to disclose, teach, or suggest at least: ... providing a catalog interface exposed to a plurality of remote systems, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system, wherein the catalog interface comprises a graphical user interface displaying selectable interface options for modules of functionalities; receiving, via the catalog interface and from a first remote system, one or more selections of a first set of one or more functionalities provided by the system for use by the first remote system;
defining a partial integration of the first remote system with the system based at least in part on (i) defining the first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration, and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system ”.
B. Examiner respectfully disagreed with Applicant's remarks:
As to the point (1), As to Claims 1, 8, 15 have been rejected under 35 USC 101 for abstract idea without significantly more. Under Step 2A, Prong 1, the “selections of a first set of one or more functionalities”, “ defining a partial integration of the first remote system” recite a mental process since “ Select” and “define” are functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ providing a catalog interface exposed to a plurality of remote systems, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system; receiving, via the catalog interface and from a first remote system, generating and transmitting integration specifications to the first remote system to facilitate use of the selected first set of one or more functionalities of the system by the first remote system; and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, wherein the catalog interface comprises a graphical user interface displaying selectable interface options for modules of functionalities; (i)defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system;” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ providing a catalog interface exposed to a plurality of remote systems, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system; receiving, via the catalog interface and from a first remote system” - this generally have been a mental process although the remote system could be a generic computer component if the spec describes it as actual computer hardware.
“generating and transmitting integration specifications to the first remote system to facilitate use of the selected first set of one or more functionalities of the system by the first remote system; and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system” - this is mere instructions to apply the mental process under mpep 2106.05(f), amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
As to Claims 2, 9, 16, have been rejected under 35 USC 101 for abstract idea without significantly more. Under Step 2A, Prong 1, the “ defining a second partial integration”, “ selections of a second set of one or more functionalities” recite a mental process since “ Select” and “define” are functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ providing a catalog interface exposed to a plurality of remote systems, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system; receiving, via the catalog interface and from a first remote system, generating and transmitting integration specifications to the first/second remote system to facilitate use of the selected first/second set of one or more functionalities of the system by the first remote system; and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, wherein the second set of one or more functionalities is different from the first set of one or more functionalities, (i)defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ providing a catalog interface exposed to a plurality of remote systems, wherein each remote system of the plurality of remote systems is configured to perform different types of operations and is remotely coupled with the system; receiving, via the catalog interface and from a first remote system” - this generally have been a mental process although the remote system could be a generic computer component if the spec describes it as actual computer hardware.
“generating and transmitting integration specifications to the first remote system to facilitate use of the selected first/second set of one or more functionalities of the system by the first remote system; and incrementally updating the partial integration and the integration specifications to facilitate use of additional functionalities of the system by the first remote system in response to additional selections of functionalities by the first remote system via the catalog interface, (i)defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system” - this is mere instructions to apply the mental process under mpep 2106.05(f), amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
As to the point (2), Rao teaches wherein each remote system of the plurality of remote systems is configured to perform different types of operations(The NAL 214 may perform abstraction for the infrastructure. The NAL 214 may abstract the specific processes and/or requirements associated with a specific network device such that the NAL 214 may run modular tasks on many different types of network devices. In some cases, the abstraction at the NAL 214 may allow support for new types of network devices introduced into the system, for new infrastructure architecture types, or both. For example, any device (e.g., a device that emits digital signals and can receive transmissions from the integration platform) may be added into the infrastructure 216 and handled by the NAL 214., para[0032], ln 1-12/ the integration platform may support a migration process from a first infrastructure architecture (e.g., a legacy network) to a second infrastructure architecture (e.g., a modern network). Additionally or alternatively, the integration platform may support new devices , para[0046], ln l5-21/ the NAL 214 may store network-related information for the network devices of the infrastructure 216. Each network device (e.g., each virtual server, physical server, router, connection, etc.) may be managed as a node or endpoint. The nodes may be grouped (e.g., based on type, classification, etc.) and may have one or more properties and connections, para[0033], ln 1-9/ The NAL 530 may receive, from the SCL 520, a modular task of the set of modular tasks. At 560, the NAL 530 may determine a type of infrastructure architecture associated with the integration platform. For example, the infrastructure architecture may be a “legacy” architecture, a “modern” architecture, or may be associated with a specific provider, controller, or some combination of these. At 565, the NAL 530 may modify the modular task according to the determined type of infrastructure architecture. At 570, the integration platform 505 (e.g., at the NAL 530) may execute the modified modular task on one or more network devices 515 of the infrastructure architecture. These network devices 515 may include servers, switches, access points, routers, modems, hubs, bridges, repeaters, racks, or any combination of these or other network devices 515, para[0057]/The SCL may parse the execution request to determine a set of modular tasks and may send a modular task to the NAL (e.g., via an API). In some cases, the SCL may modify one or more of the tasks based on user information received from the user device. The NAL may receive the modular task and may determine network connections between network devices in the system. In some cases, the NAL may determine a type of infrastructure architecture associated with the integration platform and may modify the modular task based on the type of infrastructure architecture. The NAL may execute the modular task on one or more network devices of the infrastructure architecture, para[0017], ln 8-23).
Bahrami teaches wherein the catalog interface comprises a graphical user interface displaying selectable interface options for modules of functionalities( FIG. 3 illustrates an example of a user interface 300 for selecting a category of tasks, in accordance with one or more embodiments of the present disclosure. For example, an administrator may be presented with the user interface 300 to facilitate the selection of an API or sample task to use as a template when generating a task. The user interface 300 may include one or more windows 310 (such as the windows 310a, 310b, 310c, and 310d) representative of a given API. In some embodiments, the information of the APIs corresponding to the windows 310 may be obtained via the API specification (e.g., an OAS of the API). Using the window 310c as an example, the window 310c may include a title 312c, a version 314c, a description 316c, and a button 318c. By invoking the button 318c, the administrator may be taken to a list of tasks that may be performed using the given API associated with the window 310c. For example, the tasks may include already-generated tasks, a template of a task associated with the API, etc, para[0060] to para[0061]/ Fig. 3/ At block 750, a graphical user interface (GUI) may be presented via which a user selects aspects of the task object. For example, the administrator may be presented with one or more elements of a GUI via which the administrator may input information regarding the task, such as a title, description, and one or more parameters or values associated with the task, para[0085]);
defining a partial integration of the first remote system with the system based at least in part on (i) defining first set of one or more first set of one or more functionalities of the system that are to be used by the first remote system after the partial integration. and (ii) identifying one or more application programming interfaces provided by the system and particularized to facilitating use of the first set of one or more functionalities by the remote system( The system 100 may include a task system 110 used to generate, execute, and/or combine tasks. An administrator 120 may interact with the task system 110 to generate tasks and/or facilitate combinations of tasks. An end-user 130 may interact with the task system 110 to select a task for execution. One or more API specifications 140 may be accessed by the task system 110 to obtain information regarding various APIs. An API host 150 may be accessed when executing a task to invoke the functionality of an associated API. Cloud systems 160 (such as the cloud systems 160a /160b) may represent remote systems that may be invoked by the task system 110 to execute a given task, para[0029], ln 3-16/ in some embodiments, one or more APIs may be presented to the administrator 120 for selection of an API to be associated with a new task being generated. An example of an interface illustrating such presentation is illustrated in FIG. 3. In some embodiments, the administrator 120 may select a template (or a preexisting task as a template), may select an API as the API to be used for the task, etc. , para[0032], ln 1-8/ During task execution, a user may identify a task for execution. Such execution may be performed locally or in a targeted environment (e.g., in a specific programming language, in a cloud-based service, etc.). The task may execute and provide the user with an interface via which the user may provide input to facilitate replacing any placeholder values of the task with the user-input values. The response of the task execution (e.g., the result of the specific implementation of the API call) may be returned to the user. In some embodiments, the response may be stored for other use, para[0025]/ In some embodiments, the end-user 130 may identify a particular cloud system 160 upon which the end-user 130 would like the task executed and/or in which the API call of the task is to be executed. For example, the end-user 130 may designate a task to be executed completely within a RUNMYPROCESS cloud system, an AMAZON WEB SERVICES (AWS) cloud system, a MICROSOFT cloud system, a GOOGLE cloud system, etc. In some embodiments, the entire task execution, including presenting of a user interface to obtain user input may be implemented via the cloud system 160. For example, the task system 110 may invoke an API of the cloud system 160a to cause the cloud system 160a to generate a user interface for presentation to the end-user 130 to obtain user input. The task system 110 may then generate a complete API call using the user input obtained via the cloud system 160a and the complete API call may be provided to the cloud system 160a for execution of the API call via the cloud system 160a rather than being executed via the task system 110. One example of executing the task in a cloud-based system may be described with greater detail in FIG. 10. While the cloud systems 160 are provided as one example, the end-user 130 may identify a local server (such as the task system 110), a remote server (such as the API host 150), a local computer (such as a computing device used by the end-user 130 to access the task system 110), etc., para[0042]).
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.
Conclusion
US 20230063160 A1 teaches A user (e.g., a developer or administrator) can then select any number and combination of the APIs provided by the API provider via the UI .
US 20220222739 A1 teaches detect a call operation by the user to call the UI-processed scene image data on the client device; detect a selection operation by the user to select the link element in the UI-processed scene image data, which has been sent to the client device and displayed thereon in response to the call operation, on the client device and acquire the selected link element from the client device; retrieve product information corresponding to the link element and send the product information to the client device.
US 20220342735 A1 teaches receives selection of a function provided by the API. The function to be selected is, for example, a function of the API used by a user. The selection of the function of the API is performed on, for example, a task selection screen. The task selection screen is an operation screen that displays a plurality of functions that may be provided by the API so that any one function may be selected from the plurality of functions.
US 20220350652 A1 teaches the reception unit may accept, in addition to the selection of the multiple APIs, designation of a function to be implemented by the multiple APIs. The designation of the function is made on, for example, the API selection screen displayed on the user terminal . The designation of the function may be made by, for example, selection or input of a function name, or may be made by selection or input of a sentence representing contents of the function.
US 20190213061 A1 teaches document and selection logic is used to detect the user access of API(s) through user interface and depending on the user's choice of operation, detection and selection logic select a corresponding API of API(s) . For example, as illustrated with reference to FIG. 3C, through user interface , the user of computing device is offered API menu and select any one of Tooling API, representational state transfer (REST) API, RESTful API, etc., depending on one or more operations the user wishes to perform as detected by detection and selection logic.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LECHI TRUONG whose telephone number is (571)272-3767. The examiner can normally be reached 10-8 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 Young Kevin can be reached on (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.
/LECHI TRUONG/ Primary Examiner, Art Unit 2194
Prosecution Insights