DETAILED ACTION
Introduction
1. This office action is in response to Applicant’s submission filed on 12/20/2024. Claims 1-20 are pending in the application and have been examined.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Drawings
3. The drawings filed on 12/20/2024 have been accepted and considered by the Examiner.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
4. Claim(s) 1-20 is/are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Zhou et al., (Zhou, B., Wang, X., Xu, S., Yao, Y., Pan, M., Xu, F., & Ma, X. (2023, August). Hybrid api migration: A marriage of small api mapping models and large language models. In Proceedings of the 14th Asia-Pacific Symposium on Internetware (pp. 12-21)), hereinafter referred to as ZHOU.
With respect to Claim 1, ZHOU discloses:
1. A method, comprising:
generating, by the one or more computing devices, a connectivity model comprising a set of pre-configured functions defining a connectivity language (See e.g., “…a hybrid approach that combines small API mapping models with Large Language Models (LLMs)… small API mapping model is employed to embed API semantics through their usages and declarations…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4);
PNG
media_image1.png
471
823
media_image1.png
Greyscale
translating, by the one or more computing devices, an artifact for an external platform into the connectivity language using the connectivity model (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4);
generating, by the one or more computing devices, a connector based on the translated artifact (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4); and connecting, by the one or more computing devices, to the external platform via the connector adapted by a platform adapter (See e.g., “…inferred mappings are subsequently used as part of the prompts to guide LLMs to generate the target API code corresponding to the source API code…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 2, ZHOU discloses:
2. The method of claim 1, wherein the translating comprises translating connectivity parameters defined by the artifact for connecting to the external platform, the artifact being an API specification, wherein the connecting to the external platform is based on the connectivity parameters (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…”; and also see e.g., “…to achieve conciseness, we parse each code file into a simplified AST. Compared to the corresponding complete AST, a simplified AST contains only tokens related to API and control structures. It removes AST tokens that are not directly related to the APIs of interest (e.g., ImportDeclaration, FieldDeclaration, and VariableDeclaration) and possible language-dependent features such as the type of the returned object and the parameters. To preserve expressiveness, we extract API usage sequences from the simplified AST using the structure-based traversal (SBT) algorithm [24]. Consequently, the extracted sequences contain some additional structure signs (e.g., cond-end and if-end) as shown in Figure 3. Straightforward traversals (e.g., depth-first traversal) could result in the same sequence for two different simplified ASTs…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 3, ZHOU discloses:
3. The method of claim 2, wherein the connectivity parameters comprise a type, a connection, and operations for connecting to the external platform(See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…”; and also see e.g., “…to achieve conciseness, we parse each code file into a simplified AST. Compared to the corresponding complete AST, a simplified AST contains only tokens related to API and control structures. It removes AST tokens that are not directly related to the APIs of interest (e.g., ImportDeclaration, FieldDeclaration, and VariableDeclaration) and possible language-dependent features such as the type of the returned object and the parameters. To preserve expressiveness, we extract API usage sequences from the simplified AST using the structure-based traversal (SBT) algorithm [24]. Consequently, the extracted sequences contain some additional structure signs (e.g., cond-end and if-end) as shown in Figure 3. Straightforward traversals (e.g., depth-first traversal) could result in the same sequence for two different simplified ASTs…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 4, ZHOU discloses:
4. The method of claim 2, wherein the connectivity parameters comprise at least one of connection testing, triggers, value providers, dynamic metadata providers, paginated operations, sample data providers, or a query builder for connecting to the external platform (See e.g., “…API Mapping via Similarity Computation. When given a query API at the inference stage, we identify the corresponding target API as follows. First, we split the names of both source API 𝐴𝑃𝐼𝑠 and candidate target API 𝐴𝑃𝐼𝑡 into subwords and obtain their learned embeddings from the learned model above. Then, we compute the similarity between these two APIs…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 5, ZHOU discloses:
5. The method of claim 1, wherein the connectivity language is agnostic from a language used by the external platform (See e.g., “…to assist LLMs in recalling its pre-training knowledge, prompts are developed as an input format or template for downstream tasks. In our API migration task, we design the prompt to contain both the natural language descriptions of the migration task, and the mapped APIs obtained from our first step… prompt template begins with natural language descriptions of both the mapped source API sig nature and the target API signature, followed by a mapped pair of…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-6).
With respect to Claim 6, ZHOU discloses:
6. The method of claim 1, further comprising: translating, by the one or more computing devices, an updated artifact from the external platform into the connectivity language; and connecting, by the one or more computing devices, to the external platform via an updated connector for the updated translated artifact using the platform adapter (See e.g., “…natural language descriptions of both the mapped source API sig nature and the target API signature, followed by a mapped pair of instance signatures. We then provide LLMs with further descriptions of our API migration task, such as source API code, source library/language, and target library/language. In the example of Figure 6, we first provide the source API signature belonging to the junit library and the target API signature belonging to the testing library, along with the corresponding pair of API signatures in a structured way… we describe the API migration task to LLMs and encourage them to utilize the mapped API signatures. The source code and structured prompt information are presented in the prompt in the same format as the mapped API signatures…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-6).
With respect to Claim 7, ZHOU discloses:
7. The method of claim 1, further comprising: updating, by the one or more computing devices, the set of pre-configured functions with customized functions (See e.g., “…natural language descriptions of both the mapped source API sig nature and the target API signature, followed by a mapped pair of instance signatures. We then provide LLMs with further descriptions of our API migration task, such as source API code, source library/language, and target library/language. In the example of Figure 6, we first provide the source API signature belonging to the junit library and the target API signature belonging to the testing library, along with the corresponding pair of API signatures in a structured way… we describe the API migration task to LLMs and encourage them to utilize the mapped API signatures. The source code and structured prompt information are presented in the prompt in the same format as the mapped API signatures…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-6).
With respect to Claim 8, ZHOU discloses:
8. A system, comprising: a memory configured to store operations; and one or processors configured to perform the operations, the operations comprising: generating a connectivity model comprising a set of pre-configured functions defining a connectivity language (See e.g., “…a hybrid approach that combines small API mapping models with Large Language Models (LLMs)… small API mapping model is employed to embed API semantics through their usages and declarations…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4); translating an artifact for an external platform into the connectivity language using the connectivity model (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4); generating a connector based on the translated artifact (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4); and connecting to the external platform via the connector adapted by a platform adapter (See e.g., “…inferred mappings are subsequently used as part of the prompts to guide LLMs to generate the target API code corresponding to the source API code…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 9, ZHOU discloses:
9. The system of claim 8, wherein the translating comprises translating connectivity parameters defined by the artifact for connecting to the external platform, the artifact being an API specification, wherein the connecting to the external platform is based on the connectivity parameters (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…”; and also see e.g., “…to achieve conciseness, we parse each code file into a simplified AST. Compared to the corresponding complete AST, a simplified AST contains only tokens related to API and control structures. It removes AST tokens that are not directly related to the APIs of interest (e.g., ImportDeclaration, FieldDeclaration, and VariableDeclaration) and possible language-dependent features such as the type of the returned object and the parameters. To preserve expressiveness, we extract API usage sequences from the simplified AST using the structure-based traversal (SBT) algorithm [24]. Consequently, the extracted sequences contain some additional structure signs (e.g., cond-end and if-end) as shown in Figure 3. Straightforward traversals (e.g., depth-first traversal) could result in the same sequence for two different simplified ASTs…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 10, ZHOU discloses:
10. The system of claim 9, wherein the connectivity parameters comprise a type, a connection, and operations for connecting to the external platform (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…”; and also see e.g., “…to achieve conciseness, we parse each code file into a simplified AST. Compared to the corresponding complete AST, a simplified AST contains only tokens related to API and control structures. It removes AST tokens that are not directly related to the APIs of interest (e.g., ImportDeclaration, FieldDeclaration, and VariableDeclaration) and possible language-dependent features such as the type of the returned object and the parameters. To preserve expressiveness, we extract API usage sequences from the simplified AST using the structure-based traversal (SBT) algorithm [24]. Consequently, the extracted sequences contain some additional structure signs (e.g., cond-end and if-end) as shown in Figure 3. Straightforward traversals (e.g., depth-first traversal) could result in the same sequence for two different simplified ASTs…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 11, ZHOU discloses:
11. The system of claim 9, wherein the connectivity parameters comprise at least one of connection testing, triggers, value providers, dynamic metadata providers, paginated operations, sample data providers, or a query builder for connecting to the external platform (See e.g., “…API Mapping via Similarity Computation. When given a query API at the inference stage, we identify the corresponding target API as follows. First, we split the names of both source API 𝐴𝑃𝐼𝑠 and candidate target API 𝐴𝑃𝐼𝑡 into subwords and obtain their learned embeddings from the learned model above. Then, we compute the similarity between these two APIs…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 12, ZHOU discloses:
12. The system of claim 8, wherein the connectivity language is agnostic from a language used by the external platform (See e.g., “…to assist LLMs in recalling its pre-training knowledge, prompts are developed as an input format or template for downstream tasks. In our API migration task, we design the prompt to contain both the natural language descriptions of the migration task, and the mapped APIs obtained from our first step… prompt template begins with natural language descriptions of both the mapped source API sig nature and the target API signature, followed by a mapped pair of…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-6).
With respect to Claim 13, ZHOU discloses:
13. The system of claim 8, further comprising: translating an updated artifact from the external platform into the connectivity language; and connecting to the external platform via an updated connector for the updated translated artifact using the platform adapter (See e.g., “…natural language descriptions of both the mapped source API sig nature and the target API signature, followed by a mapped pair of instance signatures. We then provide LLMs with further descriptions of our API migration task, such as source API code, source library/language, and target library/language. In the example of Figure 6, we first provide the source API signature belonging to the junit library and the target API signature belonging to the testing library, along with the corresponding pair of API signatures in a structured way… we describe the API migration task to LLMs and encourage them to utilize the mapped API signatures. The source code and structured prompt information are presented in the prompt in the same format as the mapped API signatures…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-6).
With respect to Claim 14, ZHOU discloses:
14. The system of claim 8, wherein the generating further comprises: updating the set of pre-configured functions with customized functions (See e.g., “…natural language descriptions of both the mapped source API sig nature and the target API signature, followed by a mapped pair of instance signatures. We then provide LLMs with further descriptions of our API migration task, such as source API code, source library/language, and target library/language. In the example of Figure 6, we first provide the source API signature belonging to the junit library and the target API signature belonging to the testing library, along with the corresponding pair of API signatures in a structured way… we describe the API migration task to LLMs and encourage them to utilize the mapped API signatures. The source code and structured prompt information are presented in the prompt in the same format as the mapped API signatures…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-6).
With respect to Claim 15, ZHOU discloses:
15. A non-transitory computer-readable storage device having instructions stored thereon, execution of which, by one or more processing devices, causes one or more processors to perform operations comprising: generating a connectivity model comprising a set of pre-configured functions defining a connectivity language (See e.g., “…a hybrid approach that combines small API mapping models with Large Language Models (LLMs)… small API mapping model is employed to embed API semantics through their usages and declarations…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4); translating an artifact for an external platform into the connectivity language using the connectivity model (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4); generating a connector based on the translated artifact (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4); connecting to the external platform via the connector adapted by a platform adapter (See e.g., “…inferred mappings are subsequently used as part of the prompts to guide LLMs to generate the target API code corresponding to the source API code…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 16, ZHOU discloses:
16. The non-transitory computer-readable storage device of claim 15, wherein the translating comprises translating connectivity parameters defined by the artifact for connecting to the external platform, the artifact being an API specification, wherein the connecting to the external platform is based on the connectivity parameters (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…”; and also see e.g., “…to achieve conciseness, we parse each code file into a simplified AST. Compared to the corresponding complete AST, a simplified AST contains only tokens related to API and control structures. It removes AST tokens that are not directly related to the APIs of interest (e.g., ImportDeclaration, FieldDeclaration, and VariableDeclaration) and possible language-dependent features such as the type of the returned object and the parameters. To preserve expressiveness, we extract API usage sequences from the simplified AST using the structure-based traversal (SBT) algorithm [24]. Consequently, the extracted sequences contain some additional structure signs (e.g., cond-end and if-end) as shown in Figure 3. Straightforward traversals (e.g., depth-first traversal) could result in the same sequence for two different simplified ASTs…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 17, ZHOU discloses:
17. The non-transitory computer-readable storage device of claim 16, wherein the connectivity parameters comprise a type, a connection, and operations for connecting to the external platform (See e.g., “…small API mapping model is employed to embed API semantics through their usages and declarations, enabling accurate inference of API mappings across different libraries and programming languages…”; and also see e.g., “…to achieve conciseness, we parse each code file into a simplified AST. Compared to the corresponding complete AST, a simplified AST contains only tokens related to API and control structures. It removes AST tokens that are not directly related to the APIs of interest (e.g., ImportDeclaration, FieldDeclaration, and VariableDeclaration) and possible language-dependent features such as the type of the returned object and the parameters. To preserve expressiveness, we extract API usage sequences from the simplified AST using the structure-based traversal (SBT) algorithm [24]. Consequently, the extracted sequences contain some additional structure signs (e.g., cond-end and if-end) as shown in Figure 3. Straightforward traversals (e.g., depth-first traversal) could result in the same sequence for two different simplified ASTs…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 18, ZHOU discloses:
18. The non-transitory computer-readable storage device of claim 16, wherein the connectivity parameters comprise at least one of connection testing, triggers, value providers, dynamic metadata providers, paginated operations, sample data providers, or a query builder for connecting to the external platform (See e.g., “…API Mapping via Similarity Computation. When given a query API at the inference stage, we identify the corresponding target API as follows. First, we split the names of both source API 𝐴𝑃𝐼𝑠 and candidate target API 𝐴𝑃𝐼𝑡 into subwords and obtain their learned embeddings from the learned model above. Then, we compute the similarity between these two APIs…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-4).
With respect to Claim 19, ZHOU discloses:
19. The non-transitory computer-readable storage device of claim 15, further comprising: translating an updated artifact from the external platform into the connectivity language; and connecting to the external platform via an updated connector for the updated translated artifact using the platform adapter (See e.g., “…natural language descriptions of both the mapped source API sig nature and the target API signature, followed by a mapped pair of instance signatures. We then provide LLMs with further descriptions of our API migration task, such as source API code, source library/language, and target library/language. In the example of Figure 6, we first provide the source API signature belonging to the junit library and the target API signature belonging to the testing library, along with the corresponding pair of API signatures in a structured way… we describe the API migration task to LLMs and encourage them to utilize the mapped API signatures. The source code and structured prompt information are presented in the prompt in the same format as the mapped API signatures…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-6).
With respect to Claim 20, ZHOU discloses:
20. The non-transitory computer-readable storage device of claim 15, further comprising: updating the set of pre-configured functions with customized functions (See e.g., “…natural language descriptions of both the mapped source API sig nature and the target API signature, followed by a mapped pair of instance signatures. We then provide LLMs with further descriptions of our API migration task, such as source API code, source library/language, and target library/language. In the example of Figure 6, we first provide the source API signature belonging to the junit library and the target API signature belonging to the testing library, along with the corresponding pair of API signatures in a structured way… we describe the API migration task to LLMs and encourage them to utilize the mapped API signatures. The source code and structured prompt information are presented in the prompt in the same format as the mapped API signatures…” ZHOU, Abstract, §§3, 3.1-3.3, Figs. 1-6).
Conclusion
5. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mishchenko et al., (U.S. Patent: 11,922,144), discloses an architecture comprising, see e.g., “…a method … receiving a first input at the natural language model user interface, determining the first input includes a request to integrate the particular external application programming interface (API) with the natural language model user interface, identifying the particular external API based on the received input, integrating the particular external API with the natural language model user interface, accessing the particular external API based on the first input or a second input at the natural language model user interface, and transmitting, based on the accessing, a response message to the natural language model user interface, the response message including a result of the accessing…” (See e.g., Mishchenko et al., Abstract, Fig. 1).
Please, see PTO-892 for more details.
6. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Edgar Guerra-Erazo whose telephone number is (571) 270-3708. The examiner can normally be reached on M-F 7:30a.m.-5:00p.m. EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Bhavesh Mehta can be reached on (571) 272-7453. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
7. 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.
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.
/EDGAR X GUERRA-ERAZO/Primary Examiner, Art Unit 2656
Prosecution Insights