DETAILED ACTION Claims 1-8 rejected under 35 USC § 101. Claims 1-8 rejected under 35 USC § 103. 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. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-8 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 1 and 7-8 [Step 1] Claims 1 and 7-8 recite a method, system, and/or medium for performing a process comprising steps of (1) acquiring an orchestrator data model and API specification , (2) performing schema matching between schema of the data model and schema of the API specification to generate a conversion rule (3) generate API adapter code based on the conversion rule. [Step 2A – Prong One] The process recited in claims 1 and 7-8 are directed to an abstract idea. The recited limitations (1), (2), and (3) are a process that, under its broadest reasonable interpretation, covers mental processes including "observations, evaluations, judgments, and opinions" that "can be performed in the human mind, or by a human using a pen and paper" MPEP 2106.04(a)(III). The step of (1) is accomplished by a human reading documentation defining the orchestrator and API specification. The step of (2) is accomplished by a human using pattern recognition to map two different entities as referring to the same entity (e.g., orchestrator calls VM instance using ‘VM,’ while the cloud calls VM instance using ‘EC2.’). The step of (3) is accomplished by a human writing down instructions to map an orchestrator call to an API call (e.g., if orchestrator is calling VM instance at cloud provider, then convert ‘VM’ to ‘EC2’). [Step 2A – Prong Two] Claims 1 and 7-8 do not recite additional elements that integrate the judicial exception into a practical application. The additional elements recited include computer hardware (e.g. processor and memory); these additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d). Further, the claim limitations attempt to cover any solution for adapting orchestrator calls for a different API , without providing a particular solution or way to achieve a desired outcome. See MPEP 2106.05(f)(1). [Step 2B] Claims 1 and 7-8 do not recite a combination of elements that amount to significantly more than the judicial exception itself. The broadest reasonable interpretation of the process comprising limitations (1), (2), and (3) is a mental process. The additional elements recited are merely instructions to implement the mental process on a computer. Accordingly, these limitations are not enough to qualify as "significantly more" when recited with a judicial exception (i.e. the mental process). MPEP 2106.05(A). Further, these claim limitations fail to improve the functioning of the computer itself, because "a claim whose entire scope can be performed mentally, cannot be said to improve computer technology." See MPEP 2106.05(a)(I). The additional elements outputting the source code are recognized as well-understood, routine, and conventional activity of storing and retrieving information in memory. See MPEP 2106.05(d)(II)(iv). Claims 2-3 The additional steps of defining that the schema represents resources, parameters, and parameter values does not render the judicial exception as a practical limitation or make a combination that is significantly more than the judicial exception because the step is drawn to an abstract idea as a mental process. This step is recited without any functions specific to computer technology, thus the broadest reasonable interpretation of the step includes the mental process of a human reading any arbitrary schema comprising of resources, parameters, and parameter values from a piece of paper. Claim 4 The additional step of defining the output as written into a template does not render the judicial exception a practical limitation or make a combination that is significantly more than the judicial exception because the step is drawn to an abstract idea as a mental process. This step is recited without any functions specific to computer technology, thus the broadest reasonable interpretation of the step includes the mental process of a human entering the output onto a paper form. Claims 5-6 The additional step of calculating similarity does not render the judicial exception as a practical limitation or make a combination that is significantly more than the judicial exception because the step is drawn to an abstract idea as a mental process. The similarity is calculated based on an arbitrary “a value indicating similarities,” which encompasses all ways of determining similarity. This step is recited without any functions specific to computer technology, thus the broadest reasonable interpretation of the step includes the mental proce ss of determining similarity by any mental means. 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. Claims 1-8 are rejected under 35 U.S.C. 103 as being unpatentable over Chari et al., U.S. Patent No. 11,537,448 B1, in view of Chang et al., U.S. PG-Publication No. 2018/0212896 A1. Claim 1 Chari discloses an application programming interface (API) adapter generation device . Chari discloses a “system 100” for providing “services to companies by integrating the APIs” of multiple companies that reduces “the burden of integrating one or more APIs by automating aspects of the integration process.” Chari , 5:3-11. The adaption of “an internal API call to one or more external API calls … may be performed … to generate computer code” (i.e., generate an API adapter). Id. at 14:8-16; See Also Id. at 18:14-20:43; FIG. 9 (describing “method for generating computer code for static adaption of internal API calls to external API calls). Provider 130 comprises “infrastructure for providing services to companies,” and comprises “an API adapter 138 … used to adapt internal API calls to external API calls of … other companies.” Id. at 6:43-56. Chari discloses a conversion rule calculation unit, implemented using one or more computing devices , configured to: acquire a data model … and an API specification to be managed . The system acquires a data model: “an internal API schema may be selected or created.” Id. at 12:25-36 . The system acquires an API specification to be managed: customer provides “a specification or documentation of its external API so that it may be used by provider 130.” Chari discloses the conversion rule calculation unit configured to: perform schema matching based on a data schema [of a data model] … and a data schema of the API specification to calculate a model conversion rule . Chari discloses that “adapting an internal API call to an external API call” includes “mapping the internal API schema to the external API schemas.” Id. at 7:6-14. Processing semantic representations of schemas is used to facilitate mapping between APIs. A “semantic representation may be computed for schema properties of a first API” (i.e., data schema of a data model) and “for schema properties of a second API” (i.e., data schema of the API specification) “and the semantic representations may be used to map properties between the two APIs” (i.e., perform schema matching). Id. at 8:12- 10:22. FIG. 9 illustrates a “method for generating computer code for static adaptation of internal API calls to external API calls.” The method obtains a “directed graph corresponding to an external API” and “computer code is generated corresponding to actions on the selected path” (action on the selected path → model conversion rule). Id. at 18:14-67. Chari discloses a generation unit, implemented using one or more computing devices, configured to rewrite a source code of an API call logic unit describing an API adapter execution logic based on the model conversion rule . The inputs and outputs of the generated code “correspond to with internal schema properties or to external schema properties.” The generated computer code is stored, and later “retrieved from storage and used to adapt an internal code to an external API call.” Id. at 20:21-43. Chari does not expressly disclose acquire a data model of an orchestrator ; perform schema matching based on a data schema of the orchestrator ; and an API adapter generation unit, implemented using one or more computing devices, configured to generate an API adapter to be managed based on the API call logic unit in which the source code is rewritten . Chang discloses acquire a data model of an orchestrator ; perform schema matching based on a data schema of the orchestrator . Chang discloses a “distributed hybrid orchestration model,” wherein an “Intercloud Fabric Director (ICFD)” functions as “a pure hybrid cloud management platform for use in conjunction with various ICR provider platforms” that provides “translation logic necessary to convert VM images and resolve infrastructure difference.” Chang, ¶ 14. A platform infrastructure adapter module 105D provides a cloud adapter layer “for translating infrastructural orchestration functions into VMM/cloud specific APIs … and submitting API requests to target VMM/cloud API endpoints” (matching orchestration functions to API endpoint → perform schema matching). Id. at ¶ ¶ 18, 21. Chang discloses an API adapter generation unit, implemented using one or more computing devices, configured to generate an API adapter to be managed based on the API call logic unit in which the source code is rewritten . The model uses an IVF Provider Platform (ICFPP 113) (i.e., API adapter) that comprises “core API translation logic module 113C” (i.e., API call logic unit) that “provides API translation between ICF Cloud API 113A and a given cloud environment, such as Cloud 2 Datacenter 112.” Id. at ¶ 20 ; FIG. 1. The model “enables direct communication between different ICFPP instances instantiated at different datacenters, thereby enabling direct cloud-to-cloud migrations” (instantiate ICFPP → generate API adapter). Id. at ¶ 25 It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the API mapping based on schema matching of Chari to incorporate an orchestrator that translates API calls as taught by Chang. One of ordinary skill in the art would be motivated to integrate an orchestrators that translates API calls into Chari , with a reasonable expectation of success, in order to improve performance because “processing overhead for image transportation can be greatly reduced,” and the ICFPP “provides an effective way to scale ICF deployments, and therefore, for diagnosing infrastructure related problems.” See Chang, ¶ 37. Claim 2 Chari discloses wherein the conversion rule calculation unit is configured to calculate the model conversion rule by performing schema matching on the data model of the orchestrator and the API specification to be managed in units of at least one of resources or parameters . Chari discloses that semantic representations are used to facilitate mapping between APIs. The semantic representation may manage “a schema entity … computed from the name of the entity in the schema,” or “a schema property … computed from … the property name … a description of the property, or a combination thereof.” Semantic representation may include entities, properties of entities, or values of a property (e.g., resources or parameters). Chari , 8:12-9:5. Claim 3 Chari discloses wherein the conversion rule calculation unit is configured to: aggregate a plurality of resources included in the API specification to be managed into one resource by performing matching using a variable contribution rate and dependency relationship graph information . Chari discloses that semantic representations are “computed using techniques, such as word embeddings, GloVe, and word2vec” by processing data with a “recurrent neural network … or a transformer neural network.” The semantic representation “may be computed from …. Information … such as a description of the entity in the documentation for the API” (i.e., resources included in an API specification). The semantic representation may be computed “as the average or concatenation of the semantic representations of the entity name and the entity description” (average or concatenation of semantic representations of entity → variable contribution rate). Chari , 8:23-56. Figure 6 illustrates a “method for adapting internal API calls to external API calls.” At 640, “a directed graph is generated for describing relationships between external schema properties” (directed graph → dependency relationship graph). At 650, “internal API calls are adapted to external API calls using the schema mappings and the directed graph.” Id. at 12:61-13-29, FIG. 6; See Also 13:30-60, FIG. 7 (“directed graph … used to adapt an internal API call to an external API call”). Further, Chari discloses that “there may not be a one-to-one correspondence between properties of two schemas,” wherein “the mapping may be one-to-many or many-to-one and include computations, such as splitting a full name into a first name and a last name or concatenating a first name and a last name into a full name” (e.g., aggregate a plurality of resources). Id. at 7:60-8:4. Chang discloses perform schema matching based on (i) the data schema of the API specification to be managed after the resources are aggregated and (ii) the data schema of the orchestrator . Chang discloses a “distributed hybrid orchestration model,” wherein an “Intercloud Fabric Director (ICFD)” functions as “a pure hybrid cloud management platform for use in conjunction with various ICR provider platforms” that provides “translation logic necessary to convert VM images and resolve infrastructure difference.” Chang, ¶ 14. A platform infrastructure adapter module 105D provides a cloud adapter layer “for translating infrastructural orchestration functions” (i.e., data schema of the orchestrator) “into VMM/cloud specific APIs … and submitting API requests to target VMM/cloud API endpoints” (i.e., data schema of the API specification to be managed). Id. at ¶¶ 18, 21. Claim 4 Chang discloses wherein the generation unit is configured to generate generates the API call logic unit by setting a template of a predetermined source code and rewriting the predetermined source code by writing at least one of resources, parameter names, or parameter values of the API specification to be managed in the template . Chang discloses that “infrastructure orchestration module 105C can be used to provide low-level abstractions of infrastructure orchestrations, such as … template creation.” Chang, ¶ 18. The platform can be used to “perform a workload migration” from one cloud datacenter to another, wherein the VM image is transformed to the proper destination format and “used to build a VM template for instantiating a new VM instance on the destination datacenter.” Id. at ¶¶ 23, 31. The orchestration model “ can perform processing necessary to transform the image into a local format, and use the image to build a new VM template that is specific for the local cloud environment.” Then, the “newly created VM template can then be used to instantiate the corresponding VM workload, and notification can be provided back … indicating that the migration has completed.” Id. at ¶ 36. Claim 5 Chari discloses an information extraction unit, implemented using one or more computing devices, configured to extract instance information and a configuration information graph from information of an orchestrator AP included in the orchestrator . Chari discloses that semantic representations are “computed using techniques, such as word embeddings, GloVe, and word2vec” by processing data with a “recurrent neural network … or a transformer neural network.” The semantic representation “may be computed from …. Information … such as a description of the entity in the documentation for the API” (i.e., resources included in an API specification). The semantic representation may be computed “as the average or concatenation of the semantic representations of the entity name and the entity description” (average or concatenation of semantic representations of entity → variable contribution rate). Chari , 8:23-56. Figure 6 illustrates a “method for adapting internal API calls to external API calls.” At 640, “a directed graph is generated for describing relationships between external schema properties” (directed graph → configuration information graph). At 650, “internal API calls are adapted to external API calls using the schema mappings and the directed graph.” Id. at 12:61-13-29, FIG. 6; See Also 13:30-60, FIG. 7 (“directed graph … used to adapt an internal API call to an external API call”). Chari discloses a similarity calculation unit, implemented using one or more computing devices, configured to calculate a value indicating similarities between respective resources included in the orchestrator AP based on the configuration information graph . When comparing semantic representations, “two words may have similar meanings when their numerical representations are close to each other” (numerical representation → value indicating similarities). Id. at 8:23-32. The method computes “distances … between the semantic representation of the first internal schema property and the semantic representations of the external schema properties,” and these distances are “used to identify one or more external schema properties whose semantic representations are closest (e.g., according to a distance, such as Euclidian distance) to the semantic representation of the first internal schema property.” Id. at 9:25-36. Chari discloses wherein the conversion rule calculation unit is configured to generate generates the model conversion rule based on the instance information and the value indicating similaritie s . FIG. 9 illustrates a “method for generating computer code for static adaptation of internal API calls to external API calls.” The method obtains a “directed graph corresponding to an external API” and “computer code is generated corresponding to actions on the selected path” (action on the selected path → model conversion rule). Id. at 18:14-67. Claim 6 Chari discloses wherein the schema matching uses at least one of a graph method . Chari discloses that semantic representations are “computed using techniques, such as word embeddings, GloVe, and word2vec” by processing data with a “recurrent neural network … or a transformer neural network.” The semantic representation “may be computed from …. Information … such as a description of the entity in the documentation for the API” (i.e., resources included in an API specification). The semantic representation may be computed “as the average or concatenation of the semantic representations of the entity name and the entity description” (average or concatenation of semantic representations of entity → variable contribution rate). Chari , 8:23-56. Figure 6 illustrates a “method for adapting internal API calls to external API calls.” At 640, “a directed graph is generated for describing relationships between external schema properties” (directed graph → configuration information graph). At 650, “internal API calls are adapted to external API calls using the schema mappings and the directed graph.” Id. at 12:61-13-29, FIG. 6; See Also 13:30-60, FIG. 7 (“directed graph … used to adapt an internal API call to an external API call”). Chang discloses wherein the schema matching uses an instance based Instance based method, or a hybrid "Hybrid" method that combines the instance based Instance based method and schema information . Chang discloses that “infrastructure orchestration module 105C can be used to provide low-level abstractions of infrastructure orchestrations, such as … template creation.” Chang, ¶ 18. The platform can be used to “perform a workload migration” from one cloud datacenter to another, wherein the VM image is transformed to the proper destination format and “used to build a VM template for instantiating a new VM instance on the destination datacenter.” Id. at ¶¶ 23, 31. The orchestration model “ can perform processing necessary to transform the image into a local format, and use the image to build a new VM template that is specific for the local cloud environment.” Then, the “newly created VM template can then be used to instantiate the corresponding VM workload, and notification can be provided back … indicating that the migration has completed.” Id. at ¶ 36. Claim 7 Claim 7 is rejected utilizing the aforementioned rationale for Claim 1 ; the claim is directed to a method performed by the system. Claim 8 Claim 8 is rejected utilizing the aforementioned rationale for Claim 1; the claim is directed to a medium storing instructions corresponding to the method. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Examiner name" \* MERGEFORMAT FRANK D MILLS whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (571)270-3194 . The examiner can normally be reached FILLIN "Work Schedule?" \* MERGEFORMAT M-F 10-6 ET . 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, FILLIN "SPE Name?" \* MERGEFORMAT KEVIN YOUNG can be reached at FILLIN "SPE Phone?" \* MERGEFORMAT (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. /FRANK D MILLS/ Primary Examiner, Art Unit 2194 March 31, 2026