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 .
DETAILED ACTION
This is the initial Office action based on the application filed on March 28, 2024.
Claims 1-20 are presently pending in the application have been examined below, of which, claims 1, 10, and 19 are presented in independent form.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 2A, Prong 1
Claim 1 recites a computer-implemented method, comprising:
identifying a language structure field and an application programming interface (API) schema field;
determining a determined language structure field associated with an API under test based on a mapping of the language structure field to the API schema field; and
generating, by the processor set, a mock data set based on the determined language structure field for testing the API under test.
These steps collectively describe analyzing information, mapping data structures, and generating test data based on analysis, which constitutes a mental process and data analysis that can be performed mentally or manually (e.g., by a developer creating testing data after reviewing an API schema and a software application).
Accordingly, the recited claim limitations encompass a human mind carrying out the steps through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas under Prong 1 Step 2A. See MPEP 2106.04(a)(2)III.
Step 2A, Prong 2
This judicial exception is not integrated into a practical application. The claim recites the following additional elements “a computer-implemented method” and “a processor set”. The elements 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).
Step 2B
The claim recites the following additional elements “A computer-implemented method” and “a processor set”.
A ”computer-implemented method” and “a processor set” 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. See MPEP § 2106.05(d)
Accordingly, these additional elements do not amount to significant more than the judicial exception. The claim is therefore directed to an abstract idea.
Dependent claims 1-9, further recite only abstract idea-mental process with more detailed descriptions, which do not integrate the recited judicial exception into a practical application or not amount to significant more than the judicial exception.
Claims 10-18 are computer program product claims corresponding to method claims 1-9. Therefore, they are rejected under the same rational set forth in the rejections of claims 1-9.
Claims 19-20 are system claims corresponding to method claims 1 and 6. Therefore, they are rejected under the same rational set forth in the rejections of claims 1 and 6.
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 of this title, 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, 10-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0034505 (hereinafter "Wackerly”) in view of US 2020/0233789 (hereinafter “Battaglia”).
In the following claim analysis, Applicant’s claim limitations are presented in bold text, the Examiner’s explanations, notes, and remarks are enclosed in square brackets; and emphasized portions are underlined.
As to claim 1, Wackerly discloses A computer-implemented method (Wackerly, Fig. 1, ¶ 13), comprising:
identifying, by a processor set (Wackerly, Fig. 1, ¶ 12, the processing resource 102), a language structure field (Wackerly, Fig. 1, ¶ 15, receive an original executable 130 to be tested [including a language structure field for testing] … The original executable 130 may be a script (e.g., a Python script) or may be a pre-compiled executable (e.g., an executable Java Archive, or JAR, file)) and an application programming interface (API) field (Wackerly, Fig. 1, ¶ 16, the original executable 130 may make calls to production APIs [i.e., the calls to the APIs field]);
determining, by the processor set (Wackerly, Fig. 1, ¶ 12, the processing resource 102), a determined language structure field associated with an API under test (Wackerly, Fig. 2, ¶ 17, generating a modified executable may include replacing [after determining], in part or in whole, some or all calls [language structure field] to production APIs [an API under test] in the original executable 130 with calls to mock APIs) based on [an association] of the language structure field to the API field (Wackerly, Fig. 2, ¶ 17, generating a modified executable may include replacing [after determining], in part or in whole, some or all calls [associated language structure field] to production APIs in the original executable 130 with calls to mock APIs [mapped API fields] … stepping through a copy of the executable 130 and replacing identifiable production API calls with mock API calls); and
generating, by the processor set (Wackerly, Fig. 1, ¶ 12, the processing resource 102), a mock set based on the determined language structure field for testing the API under test (Wackerly, ¶ 18, for either script or pre-compiled executables, replacing an API call may include changing a “context” of the call to a context associated with mock API behavior. For example, context may be based on a session, username, process space, etc.; ¶ 21, Use of the shadow database 142 may be limited to the modified executable 132, and vice versa, by associating the shadow database 142 with a context dedicated to mock execution and configuring the mock APIs to use that context; ¶ 22, A mock API call may include one or more of a variety of modes of behavior; Fig. 3, ¶ 60, at block 408, the network device executes [tests] the modified executable using a shadow database that is synchronized one-way from a live database that supports operation of the network device. At block 410, the network device records information associated with execution of the modified executable on the network device for post-execution analysis).
Wackerly does not appear to explicitly disclose an application programming interface (API) schema field, a mapping of the language structure field to the API schema field, and a mock data set. However, in an analogous art to the claimed invention in the field of API testing, Battaglia teaches an application programming interface (API) schema field (Battaglia, ¶ 14, receive behavior parameters with requests for resources of the API specification [an API schema]; ¶ 15, A mocking server parses an API specification to generate a parsed model [with API schema fields] of the API specification and generates a mock implementation of the API specification based on the parsed model), a mapping of the language structure field to the API schema field (Battaglia, ¶ 26, a server hosting a mocking service may receive mock requests [from the language structure field] and generate mock responses [as a mapping to the API schema field] based on an API specification), and a mock data set (Battaglia, ¶ 36, a mock request 245 may not include data, and instead the API specification 230 may define values to use as mock data when performing testing on the API. To handle a mock request 245 sent by the user device 210).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wackerly’s teaching with the teaching taught by Battaglia. The modification would be obvious because one of ordinary skill in the art would be motivated to test an application programming interface (API) by creating a mock implementation of the API using a mocking service provided by the mocking server. The mocking server may generate a mock implementation of the API based on an API specification and expose an endpoint of the mock implementation for the user to perform testing (Battaglia, Abstract).
As to claim 2, the rejection of claim 1 is incorporated. Wackerly as modified further discloses The computer-implemented method of claim 1, wherein the identifying comprises identifying the language structure field and the application programming interface schema field of an application programming interface operation (Wackerly, Fig. 1, ¶ 16, the original executable 130 may make calls to production APIs).
As to claim 3, the rejection of claim 1 is incorporated. Wackerly as modified further discloses The computer-implemented method of claim 1, wherein the identifying comprises identifying the language structure field from a plurality of language structure fields and identifying the application programming interface schema field from a plurality of application programming interface schema fields (Wackerly, Fig. 2, ¶ 17, generating a modified executable may include replacing, in part or in whole, some or all calls to production APIs in the original executable 130 with calls to mock APIs … for a script-type of original executable 130, functionality 114 may include stepping through a copy of the executable 130 and replacing identifiable production API calls with mock API calls).
As to claim 4, the rejection of claim 1 is incorporated. Wackerly as modified further discloses The computer-implemented method of claim 1, further comprising mapping the language structure field (Wackerly, Fig. 2, ¶ 17, generating a modified executable may include replacing [after determining], in part or in whole, some or all calls to production APIs in the original executable 130 with calls to mock APIs … for a script-type of original executable 130, functionality 114 may include stepping through a copy of the executable 130 and replacing identifiable production API calls with mock API calls) to the application programming interface schema field (Battaglia, ¶ 26, a server hosting a mocking service may receive mock requests and generate mock responses based on an API specification). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 5, the rejection of claim 4 is incorporated. Wackerly as modified further discloses The computer-implemented method of claim 4, further comprising monitoring the mapping to identify an application programming interface operation associated with the language structure field or the application programming interface schema field (Battaglia, ¶ 26, a server hosting [monitoring] a mocking service may receive mock requests and generate mock responses [application programming interface operation] based on an API specification; ¶ 27, ).
As to claim 6, the rejection of claim 1 is incorporated. Wackerly as modified further discloses The computer-implemented method of claim 1, wherein: the language structure field comprises a first language structure field (Wackerly, Fig. 2, ¶ 17, generating a modified executable may include replacing, in part or in whole, some or all calls [including a language structure field] to production APIs [including a ] in the original executable 130 with calls to mock APIs); the API schema field comprises a first API schema field (Wackerly, Fig. 2, ¶ 17, generating a modified executable may include replacing, in part or in whole, some or all calls [including a language structure field] to production APIs [including a first API schema field] in the original executable 130 with calls to mock APIs); and the determining comprises excluding a second language structure field and a second application programming interface schema field from the determined language structure field (Wackerly, Fig. 2, ¶ 45, generate a modified executable by replacing calls in the original executable [i.e., excluding a second language structure field that does not invoke any APIs] to production APIs [i.e., excluding a second application programming interface schema field that is not a callee from the original executable) with calls to mock APIs).
As to claim 7, the rejection of claim 1 is incorporated. Wackerly as modified further discloses The computer-implemented method of claim 1, wherein: the language structure field comprises a first language structure field; the API schema field comprises a first API schema field; and the generating comprises generating the mock data set based on the determined language structure field comprising excluding a second language structure field and a second application programming interface schema field (Battaglia, ¶ 26, a server hosting a mocking service may receive mock requests [from the language structure field and exclude a second language structure field that is not a caller to any API] and generate mock responses [as a mapping to the API schema field and excluding a second application programming interface schema field that is not a callee] based on an API specification; ¶ 36, a mock request 245 may not include data, and instead the API specification 230 may define values to use as mock data when performing testing on the API). The motivation to combine the references is the same as set forth in the rejection of claim 1.
As to claim 8, the rejection of claim 1 is incorporated. Wackerly as modified further discloses The computer-implemented method of claim 1, wherein the generating the mock data set based on the determined language structure field comprises generating the mock data set based on the determined language structure field comprising metadata associated with the language structure field and the application programming interface schema field (Battaglia, ¶ 25, The cloud platform 115 may include a server, such as a mocking server, which hosts an API mocking service … The mocking service may expose an endpoint of the API to a user … The user may use the endpoint to test the API prior to full implementation (e.g., publishing) of the API. The testing may be based on an API specification and its underlying metadata. An API specification may refer to a document or program that defines at least a portion of the functionality of an API (e.g., including any combination of behaviors, definitions, documentation, etc., for the API)). The motivation to combine the references is the same as set forth in the rejection of claim 1.
Claims 10-17 are essentially the same as claims 1-8, except it is set forth the claimed invention as a computer program product. And Wackerly as modified discloses one or more computer readable storage media having program instructions collectively stored on the one or more computer readable storage media (Wackerly, claim 15). Therefore, they are rejected with the same reasoning set forth in the rejections of claims 1-8.
Claims 19-20 are essentially the same as claims 1 and 6, except it is set forth the claimed invention as a system. And Wackerly as modified discloses A system comprising: a processor set, one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media (Wackerly, claim 1). Therefore, they are rejected with the same reasoning set forth in the rejections of claims 1 and 6.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0034505 (hereinafter "Wackerly”) in view of US 2020/0233789 (hereinafter “Battaglia”) and further in view of US 2023/0083724 (hereinafter “Cella”).
As to claim 9, the rejection of claim 1 is incorporated. Wackerly as modified does not appear to explicitly disclose The computer-implemented method of claim 1, wherein the generating the mock data set comprises data synthesis via a generative adversarial network. However, in an analogous art to the claimed invention in the field of Electric Digital Data Processing, Cella teaches The computer-implemented method of claim 1, wherein the generating the mock data set comprises data synthesis via a generative adversarial network (Cella, ¶ 2078, a Generative Adversarial Networks (GAN) may be used to generate synthetic data for the real-world environment).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wackerly’s teaching as modified with the teaching taught by Cella. The modification would be obvious because one of ordinary skill in the art would be motivated to employ a Generative Adversarial Networks (GAN) to generate synthetic data for the real-world environment to avoid use of real data for testing.
As to claim 18, the claim is corresponding to method claim 9. Therefore, it is rejected under the same rational set forth in the rejection of claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2020/0233786 teaches A system may include a mocking server and one or more tenants served by the mocking server. A tenant may test an application programming interface (API) using a mocking service; and
US 2004/0148612 generating an application programming interface (API) comprising parsing a schema defining a description language data structure, automatically creating an accessible data structure reflecting all relationships depicted in the parsed schema, and automatically generating code for at least one function based on the parsed schema.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAXIN WU whose telephone number is (571) 270-7721. The examiner can normally be reached on M-F (7 am - 11:30 am; 1:30- 5 pm).
If attempts to reach the examiner by telephone are unsuccessful, the examiner' s supervisor, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/DAXIN WU/
Primary Examiner, Art Unit 2191