DETAILED ACTION
This communication is responsive to Applicant’s amendment for application 17/113,993 dated 22 September 2025, responding to the 21 May 2025 Office Action provided in the rejection of claims 1-31, wherein claims 1, 5, 8-9, and 17-25 have been amended.
Claims 1-31 remain pending in the application and have been fully considered by the examiner.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular paragraphs or columns and lines in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submissions of the Information Disclosure Statements dated 19 May 2025 and 28 July 2025 are acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Response to Arguments
Applicant’s primary argument is directed to:
(A) Claim 1 is patentable over the cited references because they do not disclose “causing, in response to a first application programming interface (API) call, the one or more processors to provide one or more attributes of one or more descriptors received as a result of one or more calls to one or more second APIs” (see Applicant’s remarks, pages 9-12), independent claims 9, 17, and 25 are patentable for similar reasons, and claims 2-8, 10-16, 18-24, and 26-31 are patentable as depending upon claims 1, 9, 17, and 25, respectively.
Regarding (A), Examiner respectfully disagrees with this argument. Applicant argues that Sharma at paragraphs [0140]-[0141] describes "data dependency specified in a test case data set can be used for API calls, test tool related operations, web browser related operations.", urging that using a data dependency is distinct from using an API call to "provide one or more attributes of one or more descriptors received as a result of one or more calls" to a second API. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Specifically, Examiner has not applied paragraphs [0140]-[0141] of Sharma in rejecting the claim language at issue, but rather paragraph [0035] (see for example Sharma, this limitation is disclosed such that a first API call is performed at runtime, where values are extracted from test data available in a first test step as test results obtained by the first API. These values (i.e. attributes) are then used to populate one or more dependency data fields (i.e. descriptors) and made available outside the first test step as input data to a second API (i.e. the second API is performed based on one or more attributes of one or more descriptors defined by one or more other APIs) in another test step; paragraph [0035]). Therefore, this argument is unpersuasive.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 9, 17-18, and 25-26 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sharma et al. (U.S. 2019/0065349) (Hereinafter Sharma – art made of record).
As per claim 9, Sharma discloses causing, in response to a first application programming interface (API) call, one or more processors to provide one or more attributes of one or more descriptors received as a result of one or more calls to one or more second APIs (see for example Sharma, this limitation is disclosed such that a first API call is performed at runtime, where values are extracted from test data available in a first test step as test results obtained by the first API. These values (i.e. attributes) are then used to populate one or more dependency data fields (i.e. descriptors) and made available outside the first test step as input data to a second API with a second API call (i.e. the second API is performed based on one or more attributes of one or more descriptors defined by the first API, thus the second API of Sharma corresponds to Applicant’s claimed first API and the first API of Sharma corresponds to Applicant’s one or more second APIs) in another test step; paragraph [0035]).
Regarding claim 17, it is a processor claim having similar limitations cited in claim 9. Thus, claim 17 is also rejected under the same rationales as cited in the rejection of claim 9.
As per claim 18, Sharma discloses the processor of claim 17, wherein the first API is to be determined based, at least in part, on the one or more attributes of the one or more descriptors indicate by the one or more second APIs (see for example Sharma, this limitation is disclosed such that the computing processors perform receiving test case data set including test step data that specifies the dependency data fields populated with values obtained by the first API; paragraph [0035], clm.17 and associated text).
Regarding claim 25, it is a system claim having similar limitations cited in claim 9. Thus, claim 25 is also rejected under the same rationales as cited in the rejection of claim 9.
As per claim 26, Sharma discloses the system of claim 25, wherein the one or more second APIs indicates indicate a set of data values to the first API, the set of data values usable to indicate one or more operations (see for example Sharma, this limitation is disclosed such that the dependency data fields (i.e. descriptors) are populated with values (i.e. attributes of the one or more descriptors indicate one or more data values); paragraph [0035]).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-3 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma (U.S. 2019/0065349) in view of Smart, James Winston (U.S. 7,921,431) (Hereinafter Smart – art made of record).
As per claim 1, Sharma discloses providing one or more attributes of one or more descriptors received as a result of one or more calls to one or more second APIs (see for example Sharma, this limitation is disclosed such that a first API call is performed at runtime, where values are extracted from test data available in a first test step as test results obtained by the first API. These values (i.e. attributes) are then used to populate one or more dependency data fields (i.e. descriptors) and made available outside the first test step as input data to a second API (i.e. the second API is performed based on one or more attributes of one or more descriptors defined by one or more other APIs) in another test step; paragraph [0035]).
Sharma does not explicitly teach a non-transitory machine-readable medium having stored thereon an application programming interface (API), which if performed, at least in part, by one or more processors.
However, Smart discloses a non-transitory machine-readable medium having stored thereon a first application programming interface (API), which if performed, at least in part, by one or more processors (see for example Smart, this limitation is disclosed such that a non-transitory storage medium stores an application programming interface (API) which includes functions that are executed by a processor (i.e. API performed by one or more processors); clm.1 and associated text)
Sharma in view of Smart is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by having a medium soring an API as taught by Smart because it would enhance the teaching of Sharma with an effective means of enabling a processor to execute the functions of an API (as suggested by Smart, see for example clm.1 and associated text).
As per claim 2, Sharma in view of Smart discloses the non-transitory machine-readable medium of claim 1, further comprising instructions which, if performed by the one or more processors cause the one or more processors to: receive the one or more attributes of the one or more descriptors associated with a portion of the one or more second APIs (see for example Sharma, this limitation is disclosed such that the computing processors perform receiving test case data set including test step data that specifies the dependency data fields populated with values obtained by the first API; paragraph [0035], clm.17 and associated text).
As per claim 3, Sharma in view of Smart discloses the non-transitory machine-readable medium of claim 2, wherein the one or more attributes of the one or more descriptors indicate one or more data values usable by the portion of the one or more second APIs (see for example Sharma, this limitation is disclosed such that the dependency data fields (i.e. descriptors) are populated with values (i.e. attributes of the one or more descriptors indicate one or more data values); paragraph [0035]).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma (U.S. 2019/0065349) in view of Smart (U.S. 7,921,431) as applied to claim 2 above, and further in view of Shivnath et al. (U.S. 7,499,834) (Hereinafter Shivnath).
As per claim 4, Sharma in view of Smart discloses the non-transitory machine-readable medium of claim 2 (see rejection of claim 2 above), but does not explicitly teach identifying one or more optimizations to be applied to one or more descriptors; and generating one or more operations based, at least in part, on applying the one or more optimizations to the one or more attributes of the one or more descriptors.
However, Shivnath discloses identifying one or more optimizations to be applied to one or more descriptors; and generating one or more operations based, at least in part, on applying the one or more optimizations to the one or more attributes of the one or more descriptors (see for example Shivnath, this limitation is disclosed such that a management application identifies corresponding parameters in the API of each vendor, and employs the corresponding parameters in computing derived fields to compute derived parameters correctly despite dissimilar APIs and labels of API obtained fields; col.8 lines {5}-{35}).
Sharma in view of Smart is analogous art with Shivnath because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma in view of Smart by identifying and correctly deriving different API parameters as taught by Shivnath because it would enhance the teaching of Sharma in view of Smart with an effective means of coalescing dissimilar API parameters (as suggested by Shivnath, see for example col.8 lines {5}-{35}).
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma (U.S. 2019/0065349) in view of Smart (U.S. 7,921,431) as applied to claim 1, and further in view of Salli et al. (U.S. 9,323,680) (Hereinafter Salli).
As per claim 5, Sharma in view of Smart discloses the non-transitory machine-readable medium of claim 1 (see rejection of claim 1 above), but does not explicitly teach transmitting a first set of computational options using a first API; and, receiving a second set of computational options usable to configure a portion of the one or more second APIs, the second set of computational options a subset of the first set of computational options.
However, Salli discloses transmitting a first set of computational options using a first API; and, receiving a second set of computational options usable to configure a portion of the one or more second APIs, the second set of computational options a subset of the first set of computational options (see for example Salli, this limitation is disclosed such that a first and second set of parameters are established and fetched (i.e. transmitting) for an API; col.5 lines {3}-{18}; clm.11 and associated text)
Sharma in view of Smart is analogous art with Salli because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma in view of Smart by fetching API parameters as taught by Salli because it would enhance the teaching of Sharma in view of Smart with an effective means of accessing data (as suggested by Salli, see for example clm.11 and associated text).
As per claim 6, Sharma in view of Smart discloses the non-transitory machine-readable medium of claim 1 (see rejection of claim 1 above), but does not explicitly receiving one or more precomputed data values to be used in conjunction with the one or more second APIs; and associating the one or more precomputed data values with the one or more second APIs.
However, Salli discloses receiving, one or more precomputed data values to be used in conjunction with the one or more second APIs; and associating the one or more precomputed data values with the one or more second APIs (see for example Salli, this limitation is disclosed such that parameters are established and pre-fetched (i.e. precomputed data values) for the API; clm.11 and associated text)
Sharma in view of Smart is analogous art with Salli because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma in view of Smart by fetching API parameters as taught by Salli because it would enhance the teaching of Sharma in view of Smart with an effective means of accessing data (as suggested by Salli, see for example clm.11 and associated text).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma (U.S. 2019/0065349) in view of Smart (U.S. 7,921,431) as applied to claim 1 above, and further in view of Bardasz et al. (U.S. 5,689,711) (Hereinafter Bardasz).
As per claim 7, Sharma in view of Smart discloses the machine-readable medium of claim 1 (see rejection of claim 1 above), but does not explicitly teach receiving a set of pointers to user-allocated memory to be used in conjunction with one or more second APIs; and associating the set of pointers to user-allocated memory with a portion of the one or more second APIs.
However, Bardasz discloses receiving a set of pointers to user-allocated memory to be used in conjunction with one or more second APIs; and associating the set of pointers to user-allocated memory with a portion of the one or more second APIs (see for example Bardasz, this limitation is disclosed such that an associative API processor receives nil pointers for a user and creates a graph setting pointers to memory locations; col.14 line {65} – col.15 line {36}).
Sharma in view of Smart is analogous art with Bardasz because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma in view of Smart by an API reading and setting pointers for memory locations for a user as taught by Bardasz because it would enhance the teaching of Sharma in view of Smart with an effective means of a user entering commands (as suggested by Bardasz, see for example col.14 line {65} – col.15 line {36}).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma (U.S. 2019/0065349) in view of Smart (U.S. 7,921,431) as applied to claim 1 above, and further in view of Milkovich et al. (U.S. 2019/0026836) (Hereinafter Milkovich).
As per claim 8, Sharma in view of Smart discloses the machine-readable medium of claim 1 (see rejection of claim 1 above), but does not explicitly teach the limitation wherein an API is associated with a deep neural network library and one or more second APIs comprise neural network operations performed by the deep neural network library as a result of the API call.
However, Milkovich discloses the limitation wherein an API is associated with a deep neural network library and one or more second APIs comprise neural network operations performed by the deep neural network library as a result of the API call (see for example Milkovich, this limitation is disclosed such that an extensible capability library exposed by an API is based on a neural network and provided as part of an [API] call; paragraph [0033]).
Sharma in view of Smart is analogous art with Milkovich because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma in view of Smart by using a neural network with API calls as taught by Milkovich because it would enhance the teaching of Sharma in view of Smart with an effective means of extending capabilities (as suggested by Milkovich, see for example paragraph [0033]).
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma (U.S. 2019/0065349) as applied to claim 9 above, and further in view of Rajasekar, Manikandan (U.S. 2020/0167172) (Hereinafter Rajasekar).
As per claim 10, Sharma discloses the method of claim 9 (see rejection of claim 9 above), but does not explicitly teach determining one or more operations based, at least in part, on one or more attributes of one or more descriptors indicated by one or more second APIs.
However, Rajasekar discloses determining one or more operations based, at least in part, on one or more attributes of one or more descriptors indicated by one or more second APIs (see for example Rajasekar, this limitation is disclosed such that two or more APIs are invoked in order to execute a configuration task, a response of a first API being provided as a request to a second API (i.e. performing at least a portion of a first API, indicated by a second API). The respective APIs invoked and the order of invoking the APIs is provided by configuration descriptors (i.e. a configuration descriptor disclosing an indication), a configuration descriptor defining for each of the first and second API an expected request and response format (i.e. the request provided by the first API to the second API is indicated by the second API); paragraphs [0015], [0034], clm.6-8 and associated text. A configuration descriptor is received, the descriptor to be processed by a configuration executor to execute a portion of a configuration task invoking a response of a first API being provided as a request to a second API; paragraph [0003]).
Sharma in view of Rajasekar is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by configuring an order of invoking with API descriptors as taught by Rajasekar because it would enhance the teaching of Sharma with an effective means of providing APIs that can be described as atomic operations, optimizing configurations (as suggested by Rajasekar, see for example paragraph [0020]).
As per claim 11, Sharma discloses the method of claim 9 (see rejection of claim 9 above), but does not explicitly teach generating, by the first API, an indication based, at least in part, on a determination that one or more operations indicated to the second API are valid; and transmitting the indication using the first API.
However, Rajasekar discloses generating, by the first API, an indication based, at least in part, on a determination that one or more operations indicated to the second API are valid; and transmitting the indication using the first API (see for example Rajasekar, this limitation is disclosed such that parameter types being used with an API are authenticated, and authentication type is use for respective API execution in response structure format; paragraphs [0032]-[0036]).
Sharma in view of Rajasekar is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by authenticating API parameter types as taught by Rajasekar because it would enhance the teaching of Sharma with an effective means of providing APIs that can be described as atomic operations, optimizing configurations (as suggested by Rajasekar, see for example paragraph [0020]).
Claims 12, 19-20, and 27 are rejected under 35 U.S.C. 103 as being unpatentable Sharma (U.S. 2019/0065349) as applied to claims 9, 18, and 25 above, respectively, and further in view of Shivnath (U.S. 7,499,834).
As per claim 12, Sharma discloses the method of claim 9 (see rejection of claim 9 above), but does not explicitly teach generating, by the first API, an operation set based, at least in part, on applying one or more performance optimizations to one or more operations indicated to the second API, the one or more performance optimizations indicated by a third API; and performing, by the first API, the operation.
However, Shivnath discloses generating, by the first API, an operation set based, at least in part, on applying one or more performance optimizations to one or more operations indicated to the second API, the one or more performance optimizations indicated by a third API; and performing, by the first API, the operation (see for example Shivnath, this limitation is disclosed such that a management application identifies corresponding parameters in the API of each vendor, and employs the corresponding parameters in computing derived fields to compute derived parameters correctly despite dissimilar APIs and labels of API obtained fields; col.8 lines {5}-{35}).
Sharma in view of Shivnath is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by identifying and correctly deriving different API parameters as taught by Shivnath because it would enhance the teaching of Sharma with an effective means of coalescing dissimilar API parameters (as suggested by Shivnath, see for example col.8 lines {5}-{35})
As per claim 19, Sharma discloses the processor of claim 18 (see rejection of claim 18 above), but does not explicitly teach a set of operations is to be determined based, at least in part, on applying one or more optimizations to the first API, the optimizations to be indicated by a third API; and the one or more circuits perform the first API as a result of the one or more attributes of the one or more descriptors defined by the one or more second APIs.
However, Shivnath discloses a set of operations is to be determined based, at least in part, on applying one or more optimizations to the first API, the optimizations to be indicated by a third API; and the one or more circuits perform the first API as a result of the one or more attributes of the one or more descriptors defined by the one or more second APIs (see for example Shivnath, this limitation is disclosed such that a management application identifies corresponding parameters in the API of each vendor, and employs the corresponding parameters in computing derived fields to compute derived parameters correctly despite dissimilar APIs and labels of API obtained fields; col.8 lines {5}-{35}).
Sharma in view of Shivnath is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught Sharma by identifying and correctly deriving different API parameters as taught by Shivnath because it would enhance the teaching of Sharma with an effective means of coalescing dissimilar API parameters (as suggested by Shivnath, see for example col.8 lines {5}-{35}).
As per claim 20, Sharma discloses the processor of claim 18 (see rejection of claim 18 above), but does not explicitly teach the limitation wherein the one or more attributes of the one or more descriptors comprise a set of parameter descriptors and a set of operation descriptors, and the first API is to be indicated by the one or more second APIs, based, at least in part, on the set of parameter descriptors and the set of operation descriptors.
However, Shivnath discloses the limitation wherein the one or more attributes of the one or more descriptors comprise a set of parameter descriptors and a set of operation descriptors, and the first API is to be indicated by the one or more second APIs, based, at least in part, on the set of parameter descriptors and the set of operation descriptors (see for example Shivnath, this limitation is disclosed such that a management application identifies corresponding parameters in the API of each vendor, and employs the corresponding parameters in computing derived fields to compute derived parameters correctly despite dissimilar APIs and labels of API obtained fields; col.8 lines {5}-{35}).
Sharma in view of Shivnath is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by identifying and correctly deriving different API parameters as taught by Shivnath because it would enhance the teaching of Sharma with an effective means of coalescing dissimilar API parameters (as suggested by Shivnath, see for example col.8 lines {5}-{35}).
Regarding claim 27, it is a system claim having similar limitations cited in claim 12. Thus, claim 27 is also rejected under the same rationales as cited in the rejection of claim 12.
Claims 13, 21-22, and 28-29 are rejected under 35 U.S.C. 103 as being unpatentable Sharma (U.S. 2019/0065349) as applied to claims 9, 17, and 25 above, respectively, and further in view of Dolfini, Danilo (U.S. 2020/0383002) (Hereinafter Dolfini – art made of record).
As per claim 13, Sharma discloses the method of claim 9 (see rejection of claim 9 above), but does not explicitly teach transmitting, by a third API, a first set of computational options associated with one or more operations indicated to the second API; receiving, from a fourth API, a second set of computational options, the second set being a subset of the first set; and associating the second set of computational options with the one or more operations.
However, Dolfini discloses transmitting, by a third API, a first set of computational options associated with one or more operations indicated to the second API; receiving, from a fourth API, a second set of computational options, the second set being a subset of the first set; and associating the second set of computational options with the one or more operations (see for example Dolfini, this limitation is disclosed such that in a system with a first API, second API, third API, and fourth API (paragraphs [0084]-[0088]), metrics and parameters are sent and received by the APIs, metrics and parameters including subsets of arguments; paragraphs [0164]-[0167, [0186]).
Sharma in view of Dolfini is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by fetching API parameters as taught by Dolfini because it would enhance the teaching of Sharma with an effective means of using API modules to exchange data (as suggested by Dolfini, see for example paragraph [0082]).
As per claim 21, Sharma discloses the processor of claim 17 (see rejection of claim 17 above), but does not explicitly the limitation wherein a first set of computational parameters are indicated by a third API and second set of computational parameters are indicated by a fourth API, and the first API is performed based, at least in part, on the second set of computational parameters.
However, Dolfini discloses the limitation wherein a first set of computational parameters are indicated by a third API and second set of computational parameters are indicated by a fourth API, and the first API is performed based, at least in part, on the second set of computational parameters (see for example Dolfini, this limitation is disclosed such that in a system with a first API, second API, third API, and fourth API (paragraphs [0084]-[0088]), metrics and parameters are sent and received by the APIs, metrics and parameters including subsets of arguments; paragraphs [0164]-[0167, [0186]).
Sharma in view of Dolfini is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by fetching API parameters as taught by Dolfini because it would enhance the teaching of Sharma with an effective means of using API modules to exchange data (as suggested by Dolfini, see for example paragraph [0082]).
As per claim 22, Sharma discloses the processor of claim 17 (see rejection of claim 17 above), but does not explicitly teach the limitation wherein one or more precomputed data items are indicated by a third API, and the first API is performed using the one or more precomputing data items.
However, Dolfini discloses the limitation wherein one or more precomputed data items are indicated by a third API, and the first API is performed using the one or more precomputing data items (see for example Dolfini, this limitation is disclosed such that in a system with a first API, second API, third API, and fourth API (paragraphs [0084]-[0088]), metrics and parameters are sent and received by the APIs, metrics and parameters including subsets of arguments; paragraphs [0164]-[0167, [0186]. Values are assigned (i.e. data being precomputed); paragraphs [0271]-[0273]).
Sharma in view of Dolfini is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by fetching API parameters as taught by Dolfini because it would enhance the teaching of Sharma with an effective means of using API modules to exchange data (as suggested by Dolfini, see for example paragraph [0082]).
Regarding claim 28, it is a system claim having similar limitations cited in claim 13. Thus, claim 28 is also rejected under the same rationales as cited in the rejection of claim 13.
Regarding claim 29, it is a system claim having similar limitations cited in claim 13. Dolfini further discloses that procedures depend on values assigned, and values are assigned (paragraphs [0271]-[0273], i.e. information used include data dependencies, data being precomputed). Thus, claim 29 is also rejected under the same rationales as cited in the rejection of claim 13.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable Sharma (U.S. 2019/0065349) as applied to claim 9 above, further in view of Bardasz (U.S. 5,689,711), and further in view of Salli (U.S. 9,323,680).
As per claim 14, Sharma discloses the method of claim 9 (see rejection of claim 9 above), but does not explicitly teach determining one or more data dependencies associated with one or more operations indicated to the second API; transmitting the one or more data dependencies using the first API; and storing one or more precomputed data values in association with the one or more operations, the one or more precomputed data values indicated to the first API as a result of transmitting the one or more data dependencies.
However, Bardasz discloses determining one or more data dependencies associated with one or more operations indicated to the second API (see for example Bardasz, this limitation is disclosed such that an associated API is used to construct dependency entities; Fig.5 and associated text, col.4 line {56} – col.5 line {5}).
Sharma in view of Bardasz is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by an API reading and setting pointers for memory locations for a user as taught by Bardasz because it would enhance the teaching of Sharma with an effective means of a user entering commands (as suggested by Bardasz, see for example col.14 line {65} – col.15 line {36}).
Sharma in view of Bardasz does not explicitly teach transmitting the one or more data dependencies using the first API; and storing one or more precomputed data values in association with the one or more operations, the one or more precomputed data values indicated to the first API as a result of transmitting the one or more data dependencies.
However, Salli discloses transmitting the one or more data dependencies using the first API; and storing one or more precomputed data values in association with the one or more operations, the one or more precomputed data values indicated to the first API as a result of transmitting the one or more data dependencies (see for example Salli, this limitation is disclosed such that parameters are established and pre-fetched (i.e. precomputed data values) for the API; clm.11 and associated text)
Sharma in view of Bardasz is analogous art with Salli because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma in view of Bardasz by fetching API parameters as taught by Salli because it would enhance the teaching of Sharma in view of Bardasz with an effective means of accessing data (as suggested by Salli, see for example clm.11 and associated text).
Claims 15 and 30 are rejected under 35 U.S.C. 103 as being unpatentable Sharma (U.S. 2019/0065349) as applied to claims 9 and 25 above, respectively, and further in view of Bardasz (U.S. 5,689,711).
As per claim 15, Sharma disclose the method of claim 9 (see rejection of claim 9 above), but does not explicitly teach receiving, by the first API, a set of data pointers usable by one or more operations indicated to the second API.
However, Bardasz discloses receiving, by the first API, a set of data pointers usable by one or more operations indicated to the second API (see for example Bardasz, this limitation is disclosed such that an associative API processor receives nil pointers for a user and creates a graph setting pointers to memory locations; col.14 line {65} – col.15 line {36}).
Sharma in view of Bardasz is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by an API reading and setting pointers for memory locations for a user as taught by Bardasz because it would enhance the teaching of Sharma with an effective means of a user entering commands (as suggested by Bardasz, see for example col.14 line {65} – col.15 line {36})
As per claim 30, Sharma discloses the system of claim 25 (see rejection of claim 25 above), but does not explicitly teach to receive one or more references to user-allocated memory regions indicated by a third API and perform one or more operations indicated to the one or more second APIs using the one or more references to user-allocated memory regions.
However, Bardasz discloses to receive one or more references to user-allocated memory regions indicated by a third API and perform one or more operations indicated to the one or more second APIs using the one or more references to user-allocated memory regions (see for example Bardasz, this limitation is disclosed such that an associative API processor receives nil pointers for a user and creates a graph setting pointers to memory locations; col.14 line {65} – col.15 line {36}).
Sharma in view of Bardasz is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by an API reading and setting pointers for memory locations for a user as taught by Bardasz because it would enhance the teaching of Sharma with an effective means of a user entering commands (as suggested by Bardasz, see for example col.14 line {65} – col.15 line {36}).
Claims 16, 23-24, and 31 are rejected under 35 U.S.C. 103 as being unpatentable Sharma (U.S. 2019/0065349) as applied to claims 9, 17, and 25 above, respectively, and further in view of Milkovich (U.S. 2019/0026836)
As per claim 16, Sharma disclose the method of claim 9 (see rejection of claim 9 above), but does not explicitly teach the limitation wherein the first API is associated with a deep neural network library and one or more operations indicated to the second API are neural network operations to be performed by the deep neural network library using one or more parallel processing units.
However, Milkovich discloses the limitation wherein the first API is associated with a deep neural network library and one or more operations indicated to the second API are neural network operations to be performed by the deep neural network library using one or more parallel processing units (see for example Milkovich, this limitation is disclosed such that an extensible capability library exposed by an API is based on a neural network and provided as part of an [API] call; paragraph [0033]).
Sharma in view of Milkovich is analogous art because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by using a neural network with API calls as taught by Milkovich because it would enhance the teaching of Sharma with an effective means of extending capabilities (as suggested by Milkovich, see for example paragraph [0033]).
Regarding claim 23, it is a system claim having similar limitations cited in claim 16. Thus, claim 23 is also rejected under the same rationales as cited in the rejection of claim 16.
Regarding claim 24, it is a system claim having similar limitations cited in claim 16. Thus, claim 24 is also rejected under the same rationales as cited in the rejection of claim 16.
As per claim 31, Sharma discloses the system of claim 31 (see rejection of claim 31 above), but does not explicitly teach the limitation wherein the first API is provided by a deep neural network library and one or more operations indicated to the second API are performed based, at least in part, by the deep neural network library using one or more graphics processing units.
However, Milkovich discloses the limitation wherein the first API is provided by a deep neural network library and one or more operations indicated to the second API are performed based, at least in part, by the deep neural network library using one or more graphics processing units (see for example Milkovich, this limitation is disclosed such that an extensible capability library exposed by an API is based on a neural network and provided as part of an [API] call; paragraph [0033]).
Sharma is analogous art with Milkovich because they are from the same field of endeavor, configuration management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Sharma by using a neural network with API calls as taught by Milkovich because it would enhance the teaching of Sharma with an effective means of extending capabilities (as suggested by Milkovich, see for example paragraph [0033]).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONATHAN R LABUD whose telephone number is (571)270-5174. The examiner can normally be reached Monday - Thursday 10am-4pm.
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, APRIL BLAIR can be reached at (571)270-1014. 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.
/J.R.L/ Examiner, Art Unit 2196
/APRIL Y BLAIR/ Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights