Prosecution Insights
Last updated: September 17, 2026
Application No. 19/096,948

SYSTEMS AND METHODS FOR ADAPTIVE API RULE MANAGEMENT

Non-Final OA §103
Filed
Apr 01, 2025
Priority
Apr 01, 2024 — provisional 63/572,515
Examiner
TORRICO-LOPEZ, ALAN
Art Unit
Tech Center
Assignee
Quartile Digital Inc.
OA Round
1 (Non-Final)
29%
Grant Probability
At Risk
1-2
OA Rounds
2y 3m
Est. Remaining
66%
With Interview

Examiner Intelligence

Grants only 29% of cases
29%
Career Allowance Rate
104 granted / 360 resolved
-31.1% vs TC avg
Strong +38% interview lift
Without
With
+37.6%
Interview Lift
resolved cases with interview
Typical timeline
3y 8m
Avg Prosecution
32 currently pending
Career history
402
Total Applications
across all art units

Statute-Specific Performance

§101
41.2%
+1.2% vs TC avg
§103
34.7%
-5.3% vs TC avg
§102
8.3%
-31.7% vs TC avg
§112
13.7%
-26.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 360 resolved cases

Office Action

§103
DETAILED ACTION The following is a first office action upon examination of application number 19/096948. Claims 1-20 are pending in the application and have been examined on the merits discussed below. 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 . 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, 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-4, 6, 11-14, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0040182 (Gilder); Symantec Endpoint Detection and Response (Symantec, 2019). As per claim 11, a system for retrieving data associated with an online marketplace, comprising: one or more processors; one or more computer-readable media; and one or more modules maintained on the one or more computer-readable media that, when executed by the one or more processors, cause the one or more processors to perform operations including: ([0011] …a processor communicatively coupled to the network interface and the connection; and memory storing instructions for remote data collection [0137] The processor 2202 is a hardware device for executing software instructions. The processor 2202 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the computer 2200, a semiconductor-based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions. When the computer 2200 is in operation, the processor 2202 is configured to execute software stored within the memory 2210, to communicate data to and from the memory 2210, and to generally control operations of the computer 2200 pursuant to the software instructions). determining, based on a search of a configuration table, a configuration associated with an online marketplace channel API, the configuration table including one or more data fields for one or more online marketplace channel current or updated APIs; ([0128] FIG. 15 is a table describing some of the collection definition object 1104 attributes and metadata 1500 which can be stored in the configuration and definition database 212. The collection definition object facilitates telling the agent 202 what data to collect and send, by defining what LOB database 206 to connect to, which tables and columns to collect from and the actual records to collect (e.g. new, update only, all, etc.) or alternatively which API method(s) to use to access the LOB data 206 and optionally which transformation commands if any to apply to each requested data element. determining, based on a search of a customer query table, one or more customers requiring data retrieval; ([0128] …The collection definition object facilitates telling the agent 202 what data to collect and send, by defining what LOB database 206 to connect to, which tables and columns to collect from and the actual records to collect (e.g. new, update only, all, etc.) or alternatively which API method(s) to use to access the LOB data 206 and optionally which transformation commands if any to apply to each requested data element. These definitions may be stored as records in a definition server database 212 which can contain definitions for multiple sites, groups of sites, multiple LOB applications at a set of sites and for multiple collection customers. [0129] … retrieving the current client definition directly from the definition database 212 …The SP returns the matching definition for the specified client) generating one or more required time periods for data retrieval based in part on one or more settings of the configuration associated with the online marketplace channel API; ([0108] … The collection schedule 800 defines only a subset of key, scheduling-related properties from the full collection definition object defined in the definition and configuration database 212.. the day and time of the first scheduled DCT 620 launch, the interval on which to repeat launching of the DCT 620, the number of total times to launch the DCT 620 [0112] …. The sending modes may include a "re-send all" data retrieval mode, a send "since" a certain date/time mode, or send only "changed or new" since the last collection run mode) retrieving data from the online marketplace channel API … ([0102] The collector process 508 connects to one or more of the configuration defined local LOB database(s) 210, extracts the required information [0119] … using JDBC or native LOB APIs, the collection process may work independently with multiple source databases that are both local on the machine or at remote machines that may use the Operating System (O/S) file system, network sockets layer or other APIs including Internet webservice calls to retrieve data stored within the LOB database). storing the retrieved data. ([0102] The collector process 508 connects to one or more of the configuration defined local LOB database(s) 210, extracts the required information, and may send the data to a destination or write the information to a local shadow database 522). Although not explicitly taught by Gilder, Symantec teaches: generating one or more required time periods for data retrieval based in part on one or more settings of the configuration associated with the online marketplace channel API; (Page 2 The event query APIs use flters based on log_time within the "query" clause and start_time/end_time parameters. Page 117 Event query API limits the time range parameters (start_time and end_time) to a maximum range of 7 days. Page 117 To retrieve event data for a period longer than 7 days, send multiple requests. These requests must be composed in such a way that the time range (start_time to end_time) for each request covers a non-overlapping span. For example, if you want to retrieve events for a time range between 2016-01-01T00:00:00.000Z to 2016-02-01T00:00:00.000Z, you would compose fve separate requests with non-overlapping time.) dividing, based on the one or more settings of the configuration associated with the online marketplace channel API, the one or more required time periods into a plurality of time subperiods compliant with the online marketplace channel API; retrieving data from the online marketplace channel API in batches based on the plurality of time subperiods compliant with the online marketplace channel API; and(Page 117 Event query API limits the time range parameters (start_time and end_time) to a maximum range of 7 days. To retrieve event data for a period longer than 7 days, send multiple requests. These requests must be composed in such a way that the time range (start_time to end_time) for each request covers a non-overlapping span. For example, if you want to retrieve events for a time range between 2016-01-01T00:00:00.000Z to 2016-02-01T00:00:00.000Z, you would compose five separate requests with non-overlapping time. Time range parameters start_time and end_time are inclusive and exclusive, respectively (i.e., start_time < = event time < end_time). This lets you use end_time of an event data request as the start_time for the next event data request to obtain continuous, non-overlapping event data.) It would have been obvious, before the effective filing date of the claimed invention, for one of ordinary skill in the art to have modified the teachings of Gilder with the aforementioned teachings of Symantec with the motivation of complying with source API restrictions. Further, one of ordinary skill in the art would have recognized that applying the teachings of Symantec to the system of Gilder would have yielded predictable results and doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for requests to be broken down to accommodate API restrictions. As per claim 12, Gilder teaches: wherein the one or more data fields for one or more online marketplace channel current or updated APIs are one or more of a channel name, a data ingestion call alias, a listing of all fields of data extracted from an online marketplace channel API endpoint ([0128] … The collection definition object facilitates telling the agent 202 what data to collect and send, by defining what LOB database 206 to connect to, which tables and columns to collect from and the actual records to collect), a local storage location ([0072] … writing the extracted data to the local shadow database), an SQL query listing of customers to be processed for data retrieval ([0128] … These definitions may be stored as records in a definition server database 212 which can contain definitions for multiple sites, groups of sites, multiple LOB applications at a set of sites and for multiple collection customers), a duration for data retrieval, and a data retrieval speed. As per claim 13, Gilder teaches: wherein the one or more data fields for one or more online marketplace channel current or updated APIs include a channel name ([0128] … The collection definition object facilitates telling the agent 202 what data to collect and send, by defining what LOB database 206 to connect to … which API method(s) to use to access the LOB data 20), a data ingestion call alias, and a local storage location ([0065] … copy the data from the data source to a shadow database… create the shadow database based on database schema, tables, and columns defined by the current collection and or ETL object for the data source; wherein the shadow database is adapted to a type associated with the data source). As per claim 14, Gilder teaches: retrieving a full data history ([0112] … The sending modes may include a "re-send all" data retrieval mode [0116] … The decision of what to collect, such as, but not limited to, new, new plus changed data, all data including new, changed or deleted, etc. is accomplished using rules defined by the definition object 1108.) and a partial data history for establishing configuration settings ([0112] … The sending modes may include …a send "since" a certain date/time mode, or send only "changed or new" since the last collection run mode.) As per claim 16, Gilder teaches: storing an execution log of all data retrievals ([0102] … The collector process 508 can also create log entries stored in a local state database 214 in order to identify which stage or process it is (or was last) running and what values or actions it has taken. [0116] … The DCT 620 can also log status information 214 both locally and remotely to the server as it processes, or inserts the data into the shadow database 1102. To log status data 214, the DCT 620 can send a log message which can be retrieved by a listener node servicing the MetaLog Server 228, which inserts them into the central log database 230. A log entry allows the central administer to generate reports 226 and set alerts for any remotely generated errors and provide proactive management to solve any potential problems. Additionally, the DCT 620 sends any client side java exception messages to the MetaLog listener node for logging in the event that any problem occurred (e.g., the local database is missing/moved, corrupted or locked, etc.). [0132] … server process 1900 takes client log messages and inserts them into a server side database 230, 1902 to provide a central repository for all of the client agent 202 status messages). As per claims 1-4 and 6, these claims recite limitations substantially similar to those addressed by the rejection of claims 11-14 and 16, respectively; therefore, the same rejection applies. Claim(s) 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0040182 (Gilder); Symantec Endpoint Detection and Response (Symantec, 2019); in view of Oracle Time & Labor (Oracle, 2005). As per claim 15, Gilder teaches: wherein the configuration settings include … a period start date ([0112] … The sending modes may include …a send "since" a certain date/time mode).Although not explicitly taught by Gilder, Oracle teaches: wherein the configuration settings include a period name, (Page 75, Enter the name of the recurring time period) a period start date, (Page 75 Enter a Start Date to indicate the date the Period Type begins) a period end date, and (Page 90 enter an end date Page 128 You can choose to enter the Start and End Dates) a number of dates between the period start date and the period end date (Page 75, create your own period by using the Duration in Days (such as 3 days, 7 days, 12 days)… Enter duration in days). One of ordinary skill in the art would have recognized that applying the teachings of Oracle to the system of Gilder would have yielded predictable results and doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for include certain specific settings for data retrieval. As per claim 5, this claim recites limitations substantially similar to those addressed by the rejection of claim 15; therefore, the same rejection applies. Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0040182 (Gilder); Symantec Endpoint Detection and Response (Symantec, 2019); in view of US 2019/0149424 (O’Neill). As per claim 17, although not explicitly taught by Gilder, O’Neill teaches: wherein the execution log includes metrics relating to all data retrievals, the metrics including one or more of a percentage of data retrieval successes, ([0111] … key factors associated with API quality have been identified. These are [0112] 1. Availability—the percentage of calls to the API that are successful) a percentage of data retrieval failures, a number of data retrieval executions([0167] …raw metrics include counts (i.e. cardinal numbers), such as a number of invocation attempts), a percentage of errors, and a data retrieval duration ([0113] 2. Average latency—the latency is the overall time that the API takes to respond to a call). It would have been obvious, before the effective filing date of the claimed invention, for one of ordinary skill in the art to have modified the teachings of Gilder with the aforementioned teachings of O’Neill with the motivation of monitoring and evaluating performance of API data retrieval operations. Further, one of ordinary skill in the art would have recognized that applying the teachings of O’Neill to the system of Gilder would have yielded predictable results and doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the tracking API data retrieval statistics. As per claim 7, this claim recites limitations substantially similar to those addressed by the rejection of claim 17; therefore, the same rejection applies. Claim(s) 8 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0040182 (Gilder); Symantec Endpoint Detection and Response (Symantec, 2019); in view of US 2019/0149424 (O’Neill); in view of Official Notice. As per claim 18, although not explicitly taught Gilder, O’Neill teaches: wherein the errors in the percentage of errors include … timeout errors ([0111] … If latency is too long, the requesting process might timeout the request … key factors associated with API quality have been identified. These are [0112] 1. Availability—the percentage of calls to the API that are successful). Although not taught by Gilder, Official Notice is taken that authentication errors, unknown errors, throttling errors, and token service expiration errors were old and well known at the time of invention. Therefore, one of ordinary skill in the art would have recognized that applying the teachings of Official Notice to the system of Gilder would have yielded predictable results and doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the analysis of metrics related to specific types of errors. As per claim 8, this claim recites limitations substantially similar to those addressed by the rejection of claim 18; therefore, the same rejection applies. Claim(s) 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0040182 (Gilder); Symantec Endpoint Detection and Response (Symantec, 2019); in view of US 2016/0124823 (Ruan). As per claim 19, although not explicitly taught by Gilder, Ruan teaches: wherein the execution log is displayed on a single centralized dashboard ([0114] … operators monitor the status of the target application through the operational dashboard. This dashboard provides various information, such as trends of log volumes, lists of requests issued by the users, request types and lists of log entries collected in real time). It would have been obvious, before the effective filing date of the claimed invention, for one of ordinary skill in the art to have modified the teachings of Gilder with the aforementioned teachings of Ruan with the motivation of monitoring status of an application. Further, one of ordinary skill in the art would have recognized that applying the teachings of O’Neill to the system of Gilder would have yielded predictable results and doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the display of log data on a dashboard. As per claim 9, this claim recites limitations substantially similar to those addressed by the rejection of claim 19; therefore, the same rejection applies. Claim(s) 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2014/0040182 (Gilder); Symantec Endpoint Detection and Response (Symantec, 2019); in view of US 2014/0279074 (Chen). As per claim 20, Gilder teaches: wherein the retrieved data is stored in a local infrastructure ([0065] … copy the data from the data source to a shadow database [0066] …The remote data collection method can further include copying the data from the data source to a shadow database). Although not explicitly taught by Gilder, Chen teaches: wherein the retrieved data is stored in a local infrastructure of a digital marketing company ([Abstract] A data management apparatus for digital advertising includes a data integration processor for collecting and storing data from providers [0008] … A DMP may be a central hub to seamlessly and rapidly collect, integrate, manage, and activate large volume of data.) One of ordinary skill in the art would have recognized that applying the teachings of Chen to the system of Gilder would have yielded predictable results and doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the storage of data by a marketing company. As per claim 10, this claim recites limitations substantially similar to those addressed by the rejection of claim 20; therefore, the same rejection applies. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 2007/0011176 – discloses the calculation of metrics including percentage of successful data retrievals. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN TORRICO-LOPEZ whose telephone number is (571)272-3247. The examiner can normally be reached M-F 10AM-5PM. 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, Beth Boswell can be reached at (571)272-6737. 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. /ALAN TORRICO-LOPEZ/ Primary Examiner, Art Unit 3625
Read full office action

Prosecution Timeline

Apr 01, 2025
Application Filed
Aug 18, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12705632
METHOD FOR PREDICTIVE ANALYTICS
3y 4m to grant Granted Aug 11, 2026
Patent 12694419
INFORMATION PROCESSING SYSTEM, INFORMATION PROCESSING DEVICE, INFORMATION PROCESSING METHOD, AND NON-TRANSITORY RECORDING MEDIUM
3y 1m to grant Granted Jul 28, 2026
Patent 12688512
SYSTEM AND METHODS FOR CUSTOMER QUALITY PREDICTION
3y 5m to grant Granted Jul 21, 2026
Patent 12628849
SYSTEMS AND METHODS FOR INDEXING THE QUALITY OF AMINO ACIDS IN FEEDSTUFFS
2y 4m to grant Granted May 19, 2026
Patent 12586090
ENTERPRISE DATA AGGREGATION AND COLLECTIVE INSIGHTS GENERATION
3y 1m to grant Granted Mar 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
29%
Grant Probability
66%
With Interview (+37.6%)
3y 8m (~2y 3m remaining)
Median Time to Grant
Low
PTA Risk
Based on 360 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month