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 final Office Action for application 18/794,743, in response to arguments and amendment filed on 05/06/2026. Claims 1 and 12 are currently amended. Claims 1-22 are pending and examined below.
Response to Arguments
Applicant’s arguments, see pgs. 8-9, filed 05/06/2026, with respect to the rejection(s) of claim(s) 1 under 35 USC § 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Huus et al. (US Pub. 2020/0192706).
Applicant's other arguments filed 05/06/2026 have been fully considered but they are not persuasive.
Applicant argues that reference art Kumar does not teach amended claim 1 language
wherein each API access token of the plurality of API access tokens is associated with a respective user account for authenticating with the repository via the rate-limited API
because Kumar teaches, “…tokens are mechanisms for internal rate enforcement—not authentication credentials associated with user accounts on an external platform”
However, in cited and previously uncited paragraphs of Kumar (Par. 74-83), Kumar discloses that the gatekeeper uses a plurality of parameters including Application ID, which identifies the client application to the API. The Application ID is, “associated with a respective user account…” as required by new claim 1 language. Therefore this argument is unpersuasive.
Applicant argues that secondary reference Huus does not teach any of the newly added claim 1 language, including
and a number of remaining rate limit points for the API access token relative to a number of rate limit points required to execute a corresponding data request
However, Huus teaches that using a points system of total points divided by the cost of an API request to keep API requests from being throttled (Par. [0071-3]). Therefore, argument is unpersuasive.
Applicant further argues that Williams and Huus do not teach motivations to combine that are sufficient. However, these combinations are both combining prior art elements according to known methods to yield predictable results, a sufficient rationale for supporting motivations to combine. Therefore arguments are unpersuasive.
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) 1-2, 6-9, 12-13, 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (US Pub. 2024/0095127) in view of Huus et al. (US Pub. 2020/0192706).
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 each API access token of the plurality of API access tokens is associated with a respective user account for authenticating with the repository via the rate-limited API, and wherein the computing device: a) generates a plurality of data requests, each comprising one of the structured query objects, (Fig. 4; Par. [0074-83] 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; the parameters associated with the request can include an Application ID (i.e. associated with a user account))
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)
Kumar does not explicitly teach
and a number of remaining rate limit points for the API access token relative to a number of rate limit points required to execute a corresponding data request
However, from the same field, Huus teaches
and a number of remaining rate limit points for the API access token relative to a number of rate limit points required to execute a corresponding data request (Par. [0071-3] a remaining number points is used for determining throttling for a burst (i.e. corresponding data request) based on the point cost of each API request in the burst)
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 point system of Huus into the FARLG system of Kumar. The motivation for this combination would have been to improve system performance through an evolving API complexity modeling as explained in Huus (Par. [0076]).
Regarding claim 2, Kumar and Huus teach claim 1 as shown above, and Kumar 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 and Huus teach claim 1 as shown above, and Kumar 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 and Huus teach claim 1 as shown above, and Kumar 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(s) 9, Kumar and Huus teach claim 1 as shown above, and Huus further 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 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.
Regarding claim 20, while worded slightly differently, is rejected under the same rationale as claim 9.
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 Huus et al. (US Pub. 2020/0192706), and further in view of Williams et al. (US Pub. 2024/0281410).
Regarding claim(s) 3, Kumar and Huus teach claim 1 as shown above, but do 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, Huus 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, Huus 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 and Haas teach claim 7 as shown above, but do 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 and Huus teach claim 1 as shown above, but do 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 and Huus claim 1 as shown above, but do 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.
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 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
Prosecution Insights