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 a first Office Action for application 18/794,743, filed on 08/05/2024. Claims 1-22 are pending and examined below.
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)(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.
Claim(s) 1-2, 6-8, 12-13, 17-19 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Kumar et al. (US Pub. 2024/0095127).
Regarding claim 1, Kumar teaches
A system for automatic ingestion of data using a rate-limited application programming interface (API), the system comprising a computing device having a memory for storing computer-executable instructions (Fig. 12 #1214) and a processor (Fig. 12 #1203) that executes the computer-executable instructions to: create a plurality of structured query objects, each comprising instructions for retrieving data from a repository using the rate-limited API; (Fig. 4; Par. [0074-6] the fleetwide adaptive rate limiting gatekeeper (FARLG) uses a token vendor used to gate requests (i.e. is used for creating a plurality of queries) to ensure that clients can adhere to rate-limits and retry-after guidance, and prevent repeat requests that violate rate-limits)
request data from the repository via the rate-limited API using the plurality of structured query objects and a plurality of API access tokens, wherein the computing device: a) generates a plurality of data requests, each comprising one of the structured query objects, (Fig. 4; Par. [0074-6] the fleetwide adaptive rate limiting gatekeeper (FARLG) uses a token (i.e. plurality of API access tokens) vendor to ensure that clients can adhere to rate-limits and retry-after guidance, and prevent repeat requests that violate rate-limits)
b) determines a transmission delay for each of the plurality of API access tokens based upon a current rate limit for the API access token imposed by the rate-limited API, (Fig. 4; Par. [0074-6] the fleetwide adaptive rate limiting gatekeeper (FARLG) uses a token vendor to ensure that clients can adhere to rate-limits (i.e. determine transmission delays to keep them below a threshold value) and retry-after guidance, and prevent repeat requests that violate rate-limits)
c) transmits each data request to the repository via the rate-limited API using one of the plurality of API access tokens that has a transmission delay below a threshold value, and (Fig. 4; Par. [0074-6] the fleetwide adaptive rate limiting gatekeeper (FARLG) uses a token vendor to ensure that clients can adhere to rate-limits (i.e. determine transmission delays to keep them below a threshold value) and retry-after guidance, and prevent repeat requests that violate rate-limits)
d) processes data received from the repository via the rate-limited API in response to each data request; (Fig. 4; Par. [0074-6] the fleetwide adaptive rate limiting gatekeeper (FARLG) uses a token vendor to ensure that clients can adhere to rate-limits and retry-after guidance, and prevent repeat requests (i.e. process data from the repository) that violate rate-limits)
wherein the computing device repeats steps b) through d) until data responsive to each data request is received via the rate-limited API. (Fig. 4; Par. [0074-6] the fleetwide adaptive rate limiting gatekeeper (FARLG) uses a token vendor to ensure that clients can adhere to rate-limits and retry-after guidance (i.e. repeating steps b through d), and prevent repeat requests that violate rate-limits)
Regarding claim 2, Kumar teaches claim 1 as shown above, and further teaches
The system of claim 1, wherein determining the transmission delay comprises requesting the current rate limit for the API access token from the rate-limited API and calculating the transmission delay based upon the current rate limit. (Fig. 4; Par. [0074-6] the fleetwide adaptive rate limiting gatekeeper (FARLG) uses a token vendor (e.g. that creates a plurality of queries) to ensure that clients can adhere to rate-limits and retry-after guidance, and prevent repeat requests that violate rate-limits as well as ensure that requests adhere to published (i.e. calculating the transmission delay based upon the published rate limit), configured, or inferred rate limits)
Regarding claim 6, Kumar teaches claim 1 as shown above, and further teaches
The system of claim 1, wherein the computing device inserts one or more data elements received from the repository in response to a first data request into a subsequent data request as a query variable. (Par. [0430-1] the FARLG database can keep track of various parameters (i.e. data elements) for communication (i.e. inserts data elements) with other nodes and databases)
Regarding claim 7, Kumar teaches claim 1 as shown above, and further teaches
The system of claim 1, wherein processing data received from the repository via the rate-limited API comprises: storing the data in a first data store; (Par. [0430-1] the FARLG database can retain (i.e. store) information obtained from FARLG component (i.e. first store)))
extracting one or more data elements from the data based upon one or more data processing rules; and (Par. [0430-1] the FARLG database can retain information obtained (i.e. extracted) from FARLG component)
storing the extracted data elements in a second data store. (Par. [0430-1] the FARLG database can retain (i.e. second store) information obtained from FARLG component (i.e. first store))
Regarding claim 12, while worded slightly differently, is rejected under the same rationale as claim 1.
Regarding claim 13, while worded slightly differently, is rejected under the same rationale as claim 2.
Regarding claim 17, while worded slightly differently, is rejected under the same rationale as claim 6.
Regarding claim 18, while worded slightly differently, is rejected under the same rationale as claim 7.
Regarding claim 19, while worded slightly differently, is rejected under the same rationale as claim 8.
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.
Claim(s) 3-5, 8, 10-11 and 14-16, 19 and 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (US Pub. 2024/0095127) in view of Williams et al. (US Pub. 2024/0281410).
Regarding claim(s) 3, Kumar teach claim 1 as shown above, but does not explicitly teach
The system of claim 1, wherein the data received from the repository via the rate-limited API in response to one or more data requests comprises a pagination value.
However, from the same field Williams teaches
The system of claim 1, wherein the data received from the repository via the rate-limited API in response to one or more data requests comprises a pagination value. (Par. [0592] a fetch field allows for options including pagination of return results)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the pagination of Williams into the FARLG system of Kumar. The motivation for this combination would have been to improve the functioning of computer systems by providing more personalized, context dependent search results as explained in Williams (Par. [0014]).
Regarding claim(s) 4, Kumar and Williams teach claim 3 as shown above, and Williams further teaches
The system of claim 3, wherein the data comprises a pagination value, the computing device stores the data in an output file that is named according to the pagination value. (Par. [0592] a fetch field allows for options including pagination of return results (i.e. output file according to the pagination value))
Regarding claim(s) 5, Kumar and Williams teach claim 3 as shown above, and Williams further teaches
The system of claim 3, wherein the computing device e) generates a new data request comprising the pagination value and repeats steps b) through e) using the new data request until the pagination value indicates an end of data value. (Par. [0592] a fetch field allows for options including pagination of return results, including a pagination cursor that may instruct that more data be loaded)
Regarding claim(s) 8, Kumar teach claim 7 as shown above, but does not explicitly teach
The system of claim 7, wherein extracting one or more data elements comprises removing duplicates from the data or reformatting one or more data elements.
However, from the same field Williams teaches
The system of claim 7, wherein extracting one or more data elements comprises removing duplicates from the data or reformatting one or more data elements. (Par. [0145] data from a variety of sources can be deduplicated)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the deduplication of Williams into the FARLG system of Kumar. The motivation for this combination would have been to improve the functioning of computer systems by providing more personalized, context dependent search results as explained in Williams (Par. [0014]).
Regarding claim(s) 10, Kumar teach claim 1 as shown above, but does not explicitly teach
The system of claim 1, wherein the repository comprises source code associated with a software application.
However, from the same field Williams teaches
The system of claim 1, wherein the repository comprises source code associated with a software application. (Par. [0137] a version repository retains different versions of a model that can be stored, identified and retrieved)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the repository of Williams into the FARLG system of Kumar. The motivation for this combination would have been to improve the functioning of computer systems by providing more personalized, context dependent search results as explained in Williams (Par. [0014]).
Regarding claim(s) 11, Kumar teach claim 1 as shown above, but does not explicitly teach
The system of claim 10, wherein the data received from the repository comprises commits associated with the source code, issues associated with the source code, and pull requests associated with the source code.
However, from the same field Williams teaches
The system of claim 10, wherein the data received from the repository comprises commits associated with the source code, issues associated with the source code, and pull requests associated with the source code. (Par. [0137] a version repository retains different versions of a model that can be stored (i.e. committed), identified (i.e. issues) and retrieved (i.e. pull requests))
Regarding claim 14, while worded slightly differently, is rejected under the same rationale as claim 3.
Regarding claim 15, while worded slightly differently, is rejected under the same rationale as claim 4.
Regarding claim 16, while worded slightly differently, is rejected under the same rationale as claim 5.
Regarding claim 19, while worded slightly differently, is rejected under the same rationale as claim 8.
Regarding claim 21, while worded slightly differently, is rejected under the same rationale as claim 10.
Regarding claim 22, while worded slightly differently, is rejected under the same rationale as claim 11.
Claim(s) 9 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar in view of Huus et al. (US Pub. 2020/0192706).
Regarding claim(s) 9, Kumar teaches claim 1 as shown above, but does not explicitly teach
The system of claim 1, wherein the structured query objects comprise GraphQL objects. However, from the same field Huus teaches
The system of claim 1, wherein the structured query objects comprise GraphQL objects. (Par. [0034] GraphQL is among the options for querying data)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the GraphQL option of Huus into the FARLG system of Kumar. The motivation for this combination would have been to improve merchant workflows as explained in Huus (Par. [0035]).
Regarding claim 20, while worded slightly differently, is rejected under the same rationale as claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jha et al. (US Pub. 2024/0281554) teaches using a rate-limiting mechanism.
Gahm et al. (US Pub. 2015/0074285) teaches adaptive rate limiting.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to J MITCHELL CURRAN whose telephone number is (469)295-9081. The examiner can normally be reached M-F 8:00am - 5:00pm.
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, Sherief Badawi can be reached at (571) 272-9782. 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 MITCHELL CURRAN/Examiner, Art Unit 2169
/SHERIEF BADAWI/Supervisory Patent Examiner, Art Unit 2169