DETAILED ACTION
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 .
Status of Claims
This action is in reply to the amendments filed on 15 December 2025.
Claims 1, 3, 4, 6, 9, 11, 13, 14, 16, 19, and 21 have been amended.
Claims 1-21 are currently pending and have been examined.
Response to Amendment
Applicant’s amendments are insufficient to overcome the 101 rejection. This rejection is respectfully maintained and updated below as necessitated by the amendments to the claims.
Applicant’s amendments are sufficient to overcome the 102 rejections. These rejections are respectfully withdrawn. New grounds of rejection have been set forth below under 103 as necessitated by the amendments to the claims.
Response to Arguments
Applicant’s arguments filed on 15 December 2025 have been fully considered but are not persuasive.
Regarding the 101, applicant’s arguments regarding the mathematical concept and mental processes grouping have been fully considered but are moot in view of the new grounds of rejection necessitated by the amendments to the claims. See below.
Regarding the 102/103 applicant argues that the previously cited references fail to teach identifying any patterns as well as the entirety of the amended claim language. These arguments have been fully considered but are moot in view of the new grounds of rejection necessitated by the amendments to the claims. See below.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 17 February 2026 was filed after the mailing date of the initial disclosure but prior to the close of prosecution. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Independent claims 1, 11 and 21 recite identifying a pattern, identifying conditions, predicting service parameters. These limitations, as drafted, is a process step that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A user can mentally identify patterns and conditions and predict service parameters. But for the “by a processor” for executing instructions the claims encompass a user simply observing and evaluating patterns and conditions and making predictions mentally or manually. The mere nominal recitation of a generic processor does not take the claim out of the mental processing grouping. Thus, the claims recite a mental process, which is an abstract idea.
This judicial exception is not integrated into a practical application. The claims recite storing data in memory, executing instructions stored in memory, training a model based on patterns, applying a model to conditions and generating a custom user interface that presents selectable options, no details of any interaction with interactive selectable features or elements of the interface are claimed. Storing data and generating a UI that presents data are recited at a high level of generality and amounts to mere data gathering and transmission/outputting, which are forms of insignificant extra solution activity. Describing the training, applying the trained model, identifying, predicting are done by a processor is also recited at a high level of generality and merely automate the steps. Each of the additional limitations is no more than mere instructions to apply the exception using a generic computer component. The combination of these additional elements is no more than mere instructions to apply the exception using a generic computer component. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to step 2A Prong 2, the additional elements in the claims amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B and does not provide an inventive concept.
For the storing and generating a UI to present steps that were considered extra solution activity in step 2A, these have been re-evaluated in step 2B and determined to be well-understood, routine and conventional activity in the field. The specification does not provide any indication that the processor is anything other than a generic, off the shelf computer component, and the Symantec, TLI and OIP Techs court decisions in MPEP 2106.05d indicate that mere collection, receipt and transmission of data by generic devices over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here.
Dependent claims 2-10 and 12-20 include all of the limitations of the independent claims and therefore recite the same abstract idea. The claims merely narrow the abstract idea by describing that the wait times are updated based on threshold evaluations and dynamically scheduling including identifying functions. The claims include additional elements that describe the networked environment where data is exchanged through receiving functions, adding data to storing, updating predictions which is just re-executing the instructions, polling a database is considered extras solution activity since it is mere data gathering, sending which is extra solution activity since it is data transmission. Receiving feedback and updating the model based on the feedback is considered a high level recitation of data gathering and storage, and does not transform the claim into a patent eligible invention. The functions are merely performed in the environment with no details as to what or how the feedback is determined or how the model is updated specifically using or as a result of that feedback. Thus, this limitation does not illustrate a technological improvement to the function of the model itself by demonstrating a specifically recited and supported automated learning process. The additional receiving, adding, generating a notification, storing and deleting functions are also considered extra solution activity since they demonstrate data gathering, receipt and transmission functions. When reconsidered under step 2B they do not transform he claim into a patent eligible invention because they are determined to be well-understood, routine and conventional activity in the field. The specification does not provide any indication that the processor is anything other than a generic, off the shelf computer component, and the Symantec, TLI and OIP Techs court decisions in MPEP 2106.05d indicate that mere collection/deletion, receipt and transmission of data by generic devices over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here.
Claims 1-21 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 11 and 21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 11 and 21 recite the limitation "the combination of service parameters that corresponds to the respective selected option" in the last limitation. There is insufficient antecedent basis for this limitation in the claim. The claim recites generating a UI that presents one or more combinations of different options for the predicted service parameters and describes that each option is selectable. However, there is no limitation that actively recites selecting selectable options or a particular combination. Therefore, it is unclear what combination of service parameters is being referenced and what constitutes a respective selected option. Clarification and correction is required.
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-7, 11-17 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Wozniak (US 11,481,705) in view of Bueche, JR. (US 2022/0172176) further in view of LI et al. (US 2019/0057326).
As per Claim 1 Wozniak teaches:
A method of providing artificial intelligence models for dynamic scheduling, the method comprising:
storing historic schedule data in memory regarding a plurality of different service sessions, wherein each service session is associated with a type of service and one or more service parameters; and executing instructions stored in memory (Wozniak in at least Col. 3:43-Col. 4:21 describes memory for storing data relating to events such as service events and queuing for past events and historical behavior, Col. 4: 47-67 describe the type of events and parameters of the request for service as is described in at least Col. 28:45-Col. 29:13), wherein execution of the instructions by a processor (Col. 3: 53-61):
trains a learning model based on the historic schedule data, (Wozniak in at least Col. 12:64-Col. 13:28 describe training a model based on historic data and using the trained model to predict execution and/or prioritize queues based on historic behavior profiles, Col. 6:29-37, Col. 28:45-Col. 29:13, Col. 40:40-52 and Col. 42:4-19 describe identifying input fields for parameters of the request for service, Col. 13: 29-Col. 14:67 describe predicted wait times),
identifies one or more conditions associated with an incoming service request to provide a requested type of service to a requesting user (Wozniak in at least Col. 6:29-37, Col. 28:45-Col. 29:13, Col. 40:40-52 and Col. 42:4-19 describe identifying input fields for parameters of the request for service from a requesting user),
predicts one or more service parameters for the incoming service request based on applying the trained learning model to the conditions associated with the incoming service request and requesting user, wherein each predicted service parameters is associated with one or more different options (Wozniak in at least Col. 12: 6-51 describe the historic behavior profile as including the ability to determine an approximate or anticipated wait time based on the service requested and associated attributes or parameters, Col. 13: 29-Col. 14:67 describe an anticipated flow state where an expected or predicted wait time can be determined and provided for different states, profiles, services and options or attributes, Col. 12:64-Col. 13:28 describe training a model based on historic data and using the trained model to predict execution and/or prioritize queues based on historic behavior profiles, Col. 6:29-37, Col. 28:45-Col. 29:13, Col. 40:40-52 and Col. 42:4-19 describe identifying input fields for parameters of the request for service, Col. 13: 29-Col. 14:67 describe predicted wait times), and
generates a custom user interface that presents one or more of the different options for the predicted service parameters, wherein each of the different options is selectable to dynamically schedule a service session in accordance with a wait time associated with the requested type of service and service parameters that correspond to the respective selected option (Wozniak in at least Col. 14: 57-67 describes a visual indicium of the anticipated flow state corresponding to the service provider where the wait times for different services options can be displayed as is illustrated in at least Fig. 6 where options can be selected for scheduling).
Wozniak does not explicitly recite that the training using historic data is based on patterns in the historic data or that the model identifies patterns associated types of services with certain parameters. However, Bueche teaches systems and methods for interactive schedule with models and AI are used to identify patterns in historic data. Bueche further teaches:
trains a learning model based on one or more patterns in the historic schedule data, wherein the learning model is trained to identify a pattern that associates a certain type of service with one or more of the service parameters (Bueche in at least [0046-0054] describes how the analytic service can narrow down the scope of potential results by applying predictive modeling to learn patterns hidden in historical data, building a predictive model using the learned patterns and applying the learned knowledge to a new situation)
Therefore, it would be obvious to one of ordinary skill in the art to modify the ability to train a model to include techniques that learn patterns from historic data and use that to train a model to identify patterns or associations between services and parameters because each of the elements were known, but not necessarily combined as claimed. The technical ability existed to combine the elements as claimed and the result of the combination is predictable because each of the elements performs the same function as it did individually. By utilizing AI to learn patterns in historical data and applying that trained model to other data, the combination enables improved predictions and recommendations, even for new customers, based on historic data.
Neither Wozniak nor Bueche explicitly recite that the selectable options include combinations of options of service parameters. However, LI teaches systems and methods for booking transportation services. LI further describes:
generates a custom user interface that presents one or more combinations of the different options for the predicted service parameters, wherein each of the different options is selectable to dynamically schedule a service session in accordance with a wait time associated with the requested type of service and the combination of service parameters that correspond to the respective selected option (Li in at least [0037, 0040, 0042, 0053, 0055] describe generating a custom interface that presents selectable options, the options include different fees, times and other parameter combinations, [0029-0033] describe including a wait time for each of the selectable options, see Fig. 4A-C)
Therefore, it would be obvious to one of ordinary skill in the art to modify the ability to generate interface of selectable options to include techniques combinations of parameters for different options including wait times because each of the elements were known, but not necessarily combined as claimed. The technical ability existed to combine the elements as claimed and the result of the combination is predictable because each of the elements performs the same function as it did individually. By providing selectable options with different combinations of parameters, the combination informs the requestor of a variety of options at once thus enabling the requestor to exercise their ability to choose different options/combinations and customize their selection to best suit their needs.
As per Claim 2 Wozniak further teaches:
receiving the incoming service request over a communication network from a user device, wherein the incoming service request is initiated by an application executed by the user device (Wozniak in at least Fig. 1 and Col. 3:62- Col. 4:46 describe a network through which service requests are received and initiated through device applications as is further described in at least Col. 12:64-13:12).
As per Claim 3 Wozniak further teaches:
initially adding incoming service request to a waitlist database when the wait times associated with the selection option exceeds a predetermined threshold, and continuing to update the associated wait times based on real-time changes to the conditions, wherein the custom user interface is generated when the associated wait times fall below the predetermined threshold (Wozniak in at least Coil. 20:50-Col. 22:49 where requests can be added to a stored waitlist based on a lack of availability, or other threshold evaluations as is described in at least Col. 18:6-26 and 19:13-42).
Li further teaches in at least [0037, 0040-0042, 0053, 0055] describe generating a custom interface that presents selectable options, the options include different fees, times and other parameter combinations, [0029-0033] describe including a wait time for each of the selectable options, see Fig. 4A-C that are updated in real time a status indicator. LI is combined based on the reasons and rationale set forth in the rejection of Claim 1.
As per Claim 4 Wozniak further teaches:
polling the waitlist database for one or more next incoming requests when the associated wait times falls below the predetermined threshold (Wozniak in at least Coil. 20:50-Col. 22:49 where requests can be added to a stored waitlist based on a lack of availability, or other threshold evaluations as is described in at least Col. 18:6-26,19:13-42, and Col. 24:59-Col. 25:14 where upcoming events can be pulled up to a now/confirmation or immediate event) .
As per Claim 5 Wozniak further teaches:
sending the custom user interface over a communication network to a user device, and receiving a selection of one of the different options from the user device over the communication network (Wozniak in at least Col. 14: 57-67 describes a visual indicium of the anticipated flow state corresponding to the service provider where the wait times for different services options can be displayed as is illustrated in at least Fig. 6 where options can be selected for scheduling).
As per Claim 6 Wozniak further teaches:
dynamically scheduling the service session based on the received selection (Wozniak Col. 15:6-28 describes receiving an input that results in scheduling, Col. 36:4-24 describes receiving selections that result in rescheduling).
Wozniak does not explicitly recite but LI further teaches:
the combination of service parameters corresponding to the received selection (Li in at least [0037, 0040, 0042, 0053, 0055] describe generating a custom interface that presents selectable options, the options include different fees, times and other parameter combinations, [0029-0033] describe including a wait time for each of the selectable options, see Fig. 4A-C)
LI is combined based on the reasons and rationale set forth in the rejection of Claim 1 above.
As per Claim 7 Wozniak further teaches:
wherein dynamically scheduling the service session includes identifying a service provider device associated with the service session, and sending a notification to the identified service provider device regarding the service session (Wozniak Col. 15:6-28 describes receiving an input that results in scheduling, Col. 36:4-24 describes receiving selections that result in rescheduling, Col. 37:13-45 describe the orchestration engine updating schedules based on inputs and selections, see also Col. 39:60-Col. 40:10 and Col. 46:20-32 describe the ability to generate electronic messages to notify users of an assigned status or other information).
As per Claims 11-17 and 21 the limitations are substantially similar to those set forth in claims 1-7 and are therefore rejected based on the same reasons and rationale set forth above.
Claims 8-10 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wozniak (US 11,481,705) in view of Bueche, JR. (US 2022/0172176) further in view of LI et al. (US 2019/0057326) further in view of Bohannon et al. (US 2023/0216959)
As per Claim 8 Wozniak in at least claim 1 illustrates using an update signal and training signal so that in response to signals training operations to retrain a model can occur. None of Wozniak, Bueche or LI explicitly recite receiving feedback which is a basis for updating a model. However, Bohannon teaches a system and method for enhanced virtual queuing. Bohannon further teaches:
receiving feedback regarding the service session, and updating the learning model based on the received feedback (Bohannon in at least [0220] and Fig. 61 the illustrate and describe how model parameters and hyperparameters are adjusted and applied as feedback to the one or more learning algorithms at step 3106).
Therefore it would be obvious to one of ordinary skill in the art to modify a learning model that is trained to predict wait times to include techniques for retraining or updating a model using an iterative process of feeding training data to algorithms, testing the outputs and adjusting the model parameters because by continuous modifications enable the model to make improved predictions with particular desired outcomes while minimizing error.
As per Claim 9 Wozniak further teaches:
receiving another incoming service request for another type of service (Wozniak Col. 4: 47-67 describe the type of events and parameters of the request for service as is described in at least Col. 28:45-Col. 29:13, Fig. 1 and Col. 3:62- Col. 4:46 describe a network through which service requests are received and initiated through device applications as is further described in at least Col. 12:64-13:12);
adding the other incoming service request to a waitlist database based on a determination that the predicted wait times exceed a predetermined threshold (Wozniak in at least Coil. 20:50-Col. 22:49 where requests can be added to a stored waitlist based on a lack of availability, or other threshold evaluations as is described in at least Col. 18:6-26 and 19:13-42);
generating a notification that includes an option selectable to change one or more service parameters of the other type of service (Wozniak Col. 15:6-28 describes receiving an input that results in scheduling, Col. 36:4-24 describes receiving selections that result in rescheduling, i.e. changing parameters of the type of service, Col. 37:13-45 describe the orchestration engine updating schedules based on inputs and selections, see also Col. 39:60-Col. 40:10 and Col. 46:20-32 describe the ability to generate electronic messages to notify users of an assigned status or other information),
None of Wozniak, Bueche or LI explicitly recite that the selectable option is an associated reward which is stored and applicable to dynamically schedule a different session in accordance with a changed parameter. However, Bohannon further teaches:
wherein the option is associated with a reward; and storing information in memory regarding assignment of the reward to an account associated with the other incoming service request, wherein the reward is applicable to dynamically schedule a different service session in accordance with the changed service parameters of the other type of service (Bohannon in at least [0017, 0089, 0173] describe incentivizing punctuality and minimizing wait times based on predictive analysis, a virtual event allows for options where queued persons with incentives to choose to wait longer than others, using the queue load balancer the system can use detours, incentivized delays and coupons to adjust the flow of traffic through an event both spatially and/or temporally, see also [0163] describing updating queues and removing individuals from queues based on specific updates).
Therefore, it would be obvious to one of ordinary skill in the art to modify the ability to store information and offer selectable options to include techniques for incentivizing schedule changes because each of the elements were known, but not necessarily combined as claimed. The technical ability existed to combine the elements as claimed and the result of the combination is predictable because each of the elements performs the same function as it did individually. By incentivizing particular schedule changes and updating queues accordingly, the combination enables improved load balancing which will result in better overall customer satisfaction.
As per Claim 10 Wozniak teaches storing data in a waitlist database that can be updated but none of Wozniak, Bueche or LI explicitly recite that requests are removed based on changes. Bohannon further teaches:
removing the other incoming service request from the waitlist database based on selection of the option (Bohannon [0163-0165, 0171, 0180, 0191] describing updating queues and removing individuals from queues based on specific updates).
Bohannon is combined based on the same reasons and rationale set forth in the rejection of Claim 9 above.
As per Claims 18-20 the limitations are substantially similar to those set forth in claims 8-10 and are therefore rejected based on the same reasons and rationale set forth above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 STEPHANIE Z DELICH whose telephone number is (571)270-1288. The examiner can normally be reached on Monday - Friday 7-3:30.
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, Rutao Wu can be reached on 571-272-6045. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEPHANIE Z DELICH/Primary Examiner, Art Unit 3623