DETAILED ACTION
Status of the Application
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 .
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 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
This action is a Final Action on the merits in response to the application filed on 07/09/2026
Claims 1, 11, and 17 have been amended.
Claims 1-20 remain pending in this application.
Response to Amendment
Applicant’s amendments are acknowledged.
The 35 U.S.C. 101 rejections of claims 1-20 in the previous office action have been maintained.
The 35 U.S.C. 102 rejections of claims 1-20 in the previous office action have been maintained.
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-20 are rejected under 35 U.S.C. 101 because the claims are directed to a judicial exception without significantly more.
Claims 1-7 are directed towards a system, claims 8-14 are directed towards a method, and claims 15-20 are directed towards a method all of which are among the statutory categories of invention.
Step 1: This part of the eligibility analysis evaluates whether the claim falls within any statutory category. See MPEP 2106.03. The claim recites at least one step or act. Thus, the claim is to a process, which is one of the statutory categories of invention. (Step 1: YES).
Step 2A, Prong One: This part of the eligibility analysis evaluates whether the claim recites a judicial exception. As explained in MPEP 2106.04, subsection II, a claim “recites” a judicial exception when the judicial exception is “set forth” or “described” in the claim.
With respect to claims 1-20, the independent claims (claims 1, 11, and 17) are directed to managing orders and service providers, In independent claim 1, the bolded limitations emphasized below correspond to the abstract ideas of the claimed invention:
Claim 1, A network system comprising:
receiving, over one or more networks, a transport request;
generating a job order based on the transport request;
during a first time interval of a plurality of time intervals at which matching job orders to service providers is performed, (i) performing a matching process to match the job order to multiple service providers, the multiple service providers including a first service provider and a second service provider.
these steps fall within and recite an abstract ideas because they are directed to a method of organizing human activity which includes commercial interaction such as business relations; managing personal behavior (including teaching, and following rules or instructions). (See MPEP 2106.04(a)(2), subsection II).
If a claim limitation, under its broadest reasonable interpretation, covers commercial interaction; managing personal behavior, then it falls within the “method of organizing human activity” grouping of abstract ideas. Therefore, If the identified limitation(s) falls within any of the groupings of abstract ideas enumerated in the MPEP 2106, the analysis should proceed to Prong Two. (Step 2A, Prong One: YES).
Step 2A, Prong Two: This part of the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception or whether the claim is “directed to” the judicial exception. This evaluation is performed by (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception, and (2) evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. See MPEP 2106.04(d). The claim recites the additional elements of processor, memory, computing device. The claims recite the steps are performed by the processor, memory, computing device.
The limitations of
one or more processors;
a memory to store instructions;
wherein the one or more processors execute the instructions to perform operations that include:
(ii) transmitting, over the one or more networks, a first communication that specifies the job order to a computing device of the first service provider but not to a computing device of any other service provider of the multiple service providers, the first communication enabling the first service provider to accept or not accept the job order; and
in response to a determination that the first service provider does not accept the job order, transmitting, over the one or more networks, without reperforming the matching process, a second communication that specifies the job order to a computing device of the second service provider matched to the Job order during the first time interval without sending a communication to any other service provider of the multiple service providers, the second communication enabling the second service provider to accept or not accept the job order using the computing device of the second service provider.
are processing and transmitting data recited at a high level of generality, and thus are insignificant extra-solution activity. See MPEP 2106.05(g) (“whether the limitation is significant”). In addition, all uses of the recited judicial exceptions require such processing and transmitting data, and, as such, these limitations do not impose any meaningful limits on the claim. These limitations amount to necessary processing and transmitting data. See MPEP 2106.05.
Further, the limitations are recited as being performed by processor, memory, computing device. The processor, memory, computing device are recited at a high level of generality. In limitation (a), processor, memory, computing device are used as a tool to perform the generic computer function of receiving and outputting data. See MPEP 2106.05(f). The processor, memory, computing device are used to perform an abstract idea, as discussed above in Step 2A, Prong One, such that it amounts to no more than mere instructions to apply the exception using a generic computer. See MPEP 2106.05(f).
Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claim recites the additional elements of processor, memory, computing device. The claims recite the steps are performed by the processor, memory, computing device.
The limitations of
one or more processors;
a memory to store instructions;
wherein the one or more processors execute the instructions to perform operations that include:
(ii) transmitting, over the one or more networks, a first communication that specifies the job order to a computing device of the first service provider but not to a computing device of any other service provider of the multiple service providers, the first communication enabling the first service provider to accept or not accept the job order; and
in response to a determination that the first service provider does not accept the job order, transmitting, over the one or more networks, without reperforming the matching process, a second communication that specifies the job order to a computing device of the second service provider matched to the Job order during the first time interval without sending a communication to any other service provider of the multiple service providers, the second communication enabling the second service provider to accept or not accept the job order using the computing device of the second service provider.
The additional elements in the claims other than the abstract idea per se, including processor, memory, computing device amount to no more than a recitation of generic computer elements utilized to perform generic computer functions, such as receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); performing repetitive calculations, Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); electronic recordkeeping, Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log) and storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; see MPEP 2106.05(d)(II). Viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself.
As discussed in Step 2A, Prong Two above, the recitation of a processor, memory, computing device to perform limitations amounts to no more than mere instructions to apply the exception using a generic computer component. Even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer and insignificant extra-solution activity, which do not provide an inventive concept. (Step 2B: NO).
Dependent claims 2-10, 12-16, and 18-20 are not directed to any additional claim elements. Rather, these claims offer further descriptive limitations of elements found in the independent claims. In this case, the claims are rejected for the same reasons at step 2a, prong one; step 2a, prong 2; and step 2b. Thus, the claim is not patent eligible.
Regarding the dependent claims, dependent claim 2, 3 recites computing device for managing jobs. The dependent claims 2-10, 12-16, and 18-20 recite limitations that are not technological in nature and merely limits the abstract idea to a particular environment. Claims 2-10, 12-16, and 18-20 recites processor, memory, computing device which are considered an insignificant extra-solution activities of collecting and analyzing data; see MPEP 2106.05(g). Claims 2-10, 12-16, and 18-20 recites servers and communication, which merely recites an instruction to apply the abstract idea using a generic computer component; MPEP 2106.05(f). Additionally, claims 2-10, 12-16, and 18-20 recite steps that further narrow the abstract idea. No additional elements are disclosed in the dependent claims that were not considered in independent claims 1, 11, and 17. Therefore claims 2-10, 12-16, and 18-20 do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself.
Claim Rejections - 35 USC § 102
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 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication 20210227049, Demiralp, et al.
Referring to Claim 1, Demiralp teaches a network system comprising (
Demiralp: Sec. 0012, A network system is provided herein that manages an on-demand network-based service linking available service providers with service requesters throughout a given region (e.g., a metroplex such as the San Francisco Bay Area). In doing so, the network system can receive service requests for on-demand services (e.g., transport service or delivery service) from requesting users (e.g., a rider) via a designated service requester application executing on the users' mobile computing devices.);
one or more processors; a memory to store instructions (
Demiralp: Sec. 0032, one or more examples described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. Machines shown or described with figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing examples disclosed herein can be carried and/or executed.
Demiralp: Sec. 0152, The executable instructions stored in the memory 620 can also include content generation instructions 624, which enable the computer system 600 to access user profiles 626 and other user information in order to select and/or generate user content 654 for display on the user devices. As described throughout, user content 654 can be generated based on information pertaining to the state of the request (e.g., ETA/destination info). By way of example, the instructions and data stored in the memory 620 can be executed by the processor 610 to implement an example network system 100 of FIG. 1.);
wherein the one or more processors execute the instructions to perform operations that include:
receiving, over one or more networks, a transport request (
Demiralp: Sec. 0012, the network system can receive service requests for on-demand services (e.g., transport service or delivery service) from requesting users (e.g., a rider) via a designated service requester application executing on the users' mobile computing devices.);
generating a job order based on the transport request (
Demiralp: Sec. 0019, the network system can compute matching parameters for a set of users (e.g., post-request matching users and/or pre-request matching users) and a set of available service providers in the region. Provider matching can be performed based on the computed matching parameters. In some implementations, the network system computes matching parameters for each potential (or hypothetical) user-to-provider pairing of the set of users and the set of available service providers. );
during a first time interval of a plurality of time intervals at which matching job orders to service providers is performed, (i) performing a matching process to match the job order to multiple service providers, the multiple service providers including a first service provider and a second service provider (
Demiralp: Sec. 0021, the network system can optimize the matching parameters on a group basis to identify optimal user-to-provider pairings from the potential user-to-provider pairings. The network system can perform group multivariate optimizations of the parameters or variables described herein, such as distances of the service providers to the users, estimated times of arrival of the service providers, etc.
Demiralp: Sec. 0022, the network system can perform provider matching periodically (e.g., in accordance with a fixed schedule such as every thirty seconds or every two minutes, etc.). For instance, computation of matching parameters can be performed during pre-match computation time periods and the provider matching based on the computed matching parameters can be performed during provider matching time periods. Each provider matching time periods can be preceded by an associated pre-match computation time period. A service request received too late to be included in the set of users for an upcoming provider matching period can be matched with service providers during a subsequent provider matching period. As an alternative implementation, the network system can perform provider matching in a dynamic fashion and not in accordance with any fixed schedule or cycle.
Demiralp: Sec. 0057, Provider matching can be performed during provider matching time periods.),
and (ii) transmitting, over the one or more networks, a first communication that specifies the job order to a computing device of the first service provider but not to a computing device of any other service provider of the multiple service providers, the first communication enabling the first service provider to accept or not accept the job order (
Demiralp: Sec. 0012, transmit a service invitation to one or more service provider devices of the proximate available service providers to fulfil the service request. In many examples, the service providers can either accept or decline the invitation based on, for example, the service location being impractical for the service provider.
Demiralp: Sec. 0071, a service provider that was determined to be optimal by the group optimization process performed by the network system can be pre-request matched with the user and held for the user until the user submits a service request.
Demiralp: Sec. 0120, while the pre-request match is in effect, the network system can classify the first service provider as unavailable for matching with other users in anticipation of receiving a service request from the first user.
Demiralp: Sec. 0014, the network system can be configured to hold the service provider without transmitting an invitation associated with the pre-request matched user to the service provider.);
Demiralp describes invitations enabling accept/decline, and pre-request holding ensures exclusivity.
in response to a determination that the first service provider does not accept the job order, transmitting, over the one or more networks, without reperforming the matching process, a second communication that specifies the job order to a computing device of the second service provider matched to the Job order during the first time interval without sending a communication to any other service provider of the multiple service providers, the second communication enabling the second service provider to accept or not accept the job order using the computing device of the second service provider (
Demiralp: Sec. 0012, In many examples, the service providers can either accept or decline the invitation based on, for example, the service location being impractical for the service provider.
Demiralp: Sec. 0014, In some examples, during this period of time in which the service provider is pre-matched with the user, the network system can be configured to hold the service provider without transmitting an invitation associated with the pre-request matched user to the service provide
Demiralp: Sec. 0081, a pre-request hold can include reserving the service provider for the user and classifying the service provider as not available for provider matching with other providers during subsequent provider matching time periods while the pre-request hold is effective.
Demiralp: Sec. 0090, in response to receiving the service request after pre-request matching the user with the service provider, the network system can automatically transmit an invitation to the service provider pre-request matched with the user (step 220B). In doing so, the network system can avoid re-performing provider matching and can transmit the invitation as soon as the service request is received from the user (as compared with after the subsequent provider matching time period in comparison with step 220A).
Demiralp: Sec. 0091, for a first geographic region managed by the network system (e.g., a high traffic area such as an airport), the network system can be configured to proceed via 220B to automatically transmit an invitation in response to receiving the service request from the user without re-performing provider matching for the user).
Demiralp describes the service provider having the capability to accept or decline a job, without sending out communication such as invitations. As well as, not reperforming the matching process, as this works with the communication of multiple service providers.
Referring to Claim 2, Demiralp teaches the network system of claim 1, wherein the operations further comprise:
making the determination that the first service provider does not accept the job order after passage of a threshold time interval during which no communication that accepts the job order is received from the computing device of the first service provide (
Demiralp: Fig. 2D, Wait time for Req > Threshold?… Cancel Pre-Request Hold for P2… when no request is received within a threshold
Demiralp: Sec. 0106, After the pre-request match is made for U2, the network system can wait for a service request to be transmitted from the device of U2 (step 239). If the wait time for the request exceeds a threshold limit, the network system can terminate the pre-request match between P2 and U2 (steps 240 and 241).).
Demiralp teaches the system uses response/time windows and treats no response within that time as expiration. Moreover, Demiralp discloses the use a predetermined time/threshold to decide that a provider has not accepted when no acceptance communication is received.
Referring to Claim 3, Demiralp teaches the network system of claim 1, wherein the operations further comprise:
making the determination that the first service provider does not accept the job order is based on receiving, over one or more networks, a response communication from the computing device of the first service provider (
Demiralp: Fig. 2E,
Demiralp: Sec. 0012, the service providers can either accept or decline the invitation based on, for example, the service location being impractical for the service provider.
Demiralp: Sec. 0124, If the first service provider declined the invitation (or did not accept the invitation before an expiration time) (not illustrated in FIG. 2E), the provider device can transmit a rejection signal to the network system and the network system can identify another service provider for the first user.
Demiralp: Sec. 0146, The app interface 542 can enable the service provider to, for example, accept or reject invitations 592 in order to service requests throughout a given region.
Demiralp: Sec. 0151, can execute the service provider selection instructions 622 to identify a plurality of candidate service providers and transmit invitation messages 652 to each of the candidate service providers to enable the service providers to accept or decline the invitations).
Demiralp describes the provider device sends an accept or decline; a decline is explicit non-acceptance. FIG. 2E shows provider device presenting prompt to accept/decline and generating confirmation messages
Referring to Claim 4, Demiralp teaches the network system of claim 1, wherein the operations further comprise:
during the first time interval, determining an approval rate of the job order, and associating the approval rate with the job order (
Demiralp: Sec. 0020, In certain implementations, the matching parameters can further include context-based parameters such as a determined likelihood of the user canceling the service request, a determined propensity of the service provider accepting an invitation related to the service request, a determined likelihood of the service provider cancelling an accepted invitation, and/or a determined propensity of the user submitting a service request (for pre-request matching). The context-based parameters can be determined using one or more context models based on context data associated with the user or the service provider.
Demiralp: Sec. 0064, The matching parameters computed for each user-to-provider pairing can further include context-related parameters such as a computed probability that the user will cancel the request, a computed probability that the service provider will decline the resulting invitation, and/or a computed probability that the service provider will cancel his or her acceptance. For pre-request matching, the network system can further compute a probability that the user will submit a service request within a certain time period as a context-related parameter used as a matching parameter for the user-to-provider pairing).
Demiralp teaches these are probabilities/likelihoods computed per potential job pairing, derived from context models, which is equivalent to the Applicant’s spec at 0012 for teaching that an approval rate of a job order is indicating what the probability that the job order will be accepted by a service provider.
Referring to Claim 5, Demiralp teaches the network system of claim 1, wherein the operations further comprise:
determining that the second service provider does not have a pending status corresponding to the second service provider having a prior job order that is currently pending only with the second service provider (
Demiralp: Sec. 0014, A service provider who is pre-request matched with a user can be held for the user (e.g., classified or labeled by the network system as unavailable for matching with other users) for at least a period of time (e.g., until the user submits a service request or until the pre-request match expires).
Demiralp: Sec. 0017, the identification of pre-request matching users within a geographic region managed by the network system can be based dynamic conditions of the network-based service within the geographic region. For instance, if the number of pending service requests associated with the region (e.g., service requests having a start location within the region) exceeds the number of available service providers in the region, the network system can determine to not identify any pre-request matching users for a subsequent provider matching process and consequently not perform pre-request matching. Similarly, if the ratio of available service providers to pending service requests falls below a threshold value, the network system can determine to not identify any pre-request matching users, or alternatively, identify fewer pre-request matching users (e.g., by adjusting threshold values used in the process to identify pre-request matching users).).
Referring to Claim 6, Demiralp teaches the network system of claim 5, wherein the operations further comprise:
associating the second service provider with the job order in response to determining that the second service provider does not have the pending status (
Demiralp: Sec. 0020, the network system can identify a service provider for a given user by optimizing matching parameters (e.g., by performing multivariate optimizations).
Demiralp: Sec. 0034, The network service can provide a platform that facilitates services to be requested and provided between requesting users 171 and available service providers 181 by way of a user application 172 executing on the user devices 170 and a service provider application 182 executing on the service provider devices 180. ).
Demiralp describes confirming that a provider is available, in which the Examiner is interpreting as no pending status.
Referring to Claim 7, Demiralp teaches the network system of claim 5, wherein matching the job order to the second service provider is performed in response to determining that the second service provider does not have the pending status (
Demiralp: Sec. 0014, A service provider who is pre-request matched with a user can be held for the user (e.g., classified or labeled by the network system as unavailable for matching with other users)
Demiralp: Sec. 0071, the network system can simply classify or label a service provider who is pre-request matched with a user as unavailable to be matched with other users in anticipation of the pre-request matching user submitting a service request at a later time.).
Referring to Claim 8, Demiralp teaches the network system of claim 4, wherein the determining the approval rate for the job order approval rate is based at least in part on parametric information of a corresponding transport request (
Demiralp: Sec. 0020, The matching parameters can include location-based parameters such as a distance between the service provider and the given user, an estimated time of arrival of the service provider to rendezvous with the given user, an estimated time of arrival of the given user at a service location (e.g., destination location of a transport service), an estimated cost for the requested service, etc. In certain implementations, the matching parameters can further include context-based parameters such as a determined likelihood of the user canceling the service request, a determined propensity of the service provider accepting an invitation related to the service request, a determined likelihood of the service provider cancelling an accepted invitation, and/or a determined propensity of the user submitting a service request (for pre-request matching). The context-based parameters can be determined using one or more context models based on context data associated with the user or the service provider).
Demiralp describes context-based parameters in which the Examiner is interpreting as deriving from user request submission/cancellation models.
Referring to Claim 9, Demiralp teaches the network system of claim 8, wherein matching the job order to the second service provider is performed in response to determining the approval rate is less than a threshold value (
Demiralp: Sec. 0016, the network system can determine a likelihood of whether the user will submit a service request within a given time window based on the context data relating to the user in determining whether to perform pre-request matching for the user.
Demiralp: Sec. 0039, the user request submission context model 153A can determine, based on context data relating to a given user, a likelihood that the given user will submit a service request. If the likelihood is above a threshold value, the given user is included in the subset of the PRM users 121 for which pre-request matching will be performed by the network system.
Demiralp: Sec. 0063, Similarly, user-to-provider pairings may be ignored or filtered on the basis of user ratings or provider ratings (e.g., the network system may filter a potential user-to-provider pairing comprising a user with a user rating above a certain threshold and a service provider with a provider rating below a certain threshold).
Demiralp: Claim 7, the determined propensity being above a threshold value, determining to perform pre-request matching for the second user.).
Demiralp teaches using context models to compute propensities and can decide actions based on propensities exceeding or not exceeding thresholds.
Referring to Claim 10, Demiralp teaches the network system of claim 4, wherein determining the approval rate is based on contextual information (
Demiralp: Sec. 0016, the network system can determine whether to perform pre-request matching for a user. This determination can be made based on, for example, context data relating to the user. The context data relating to the user can be transmitted periodically or continuously from the user device to the network system as the user interacts with the user application. The context data can include user application status data, user application interaction data, user device sensor data, and/or user profile data.
Demiralp: Sec. 0084, Yet more context-related parameters computed for the first user-to-provider pairing can be the probability of the first provider accepting the resulting invitation and/or the probability the first provider canceling his or her acceptance to the invitation. These probabilities can be computed using the provider acceptance context model 153C and/or the provider cancel context model 153D as described herein.
Demiralp: Sec. 0085, different matching parameters can be computed for users having submitted service requests as compared with users who are being matched with service providers prior to submitting service requests. For example, for pre-request matching for a first user, the matching parameters can include the determined probability of the user submitting a service request (e.g., such as the probability determined at step 214) or a parameter derived therefrom. ).
Demiralp teaches using context models produce probabilities used in matching parameters (propensity to submit, accept, cancel)
Referring to Claim 11, Demiralp teaches a non-transitory computer-readable medium that stores instructions, which when executed by one or more processors of a computer system, cause the computer system to perform operations that include:
during a first time interval of a plurality of time intervals at which matching job orders to service providers is performed, identifying a plurality of job orders, including multiple job orders that each have an open status such that no service provider is currently matched to the job order (
Demiralp: Sec. 0021, the network system can optimize the matching parameters on a group basis to identify optimal user-to-provider pairings from the potential user-to-provider pairings. The network system can perform group multivariate optimizations of the parameters or variables described herein, such as distances of the service providers to the users, estimated times of arrival of the service providers, etc.
Demiralp: Sec. 0022, the network system can perform provider matching periodically (e.g., in accordance with a fixed schedule such as every thirty seconds or every two minutes, etc.). For instance, computation of matching parameters can be performed during pre-match computation time periods and the provider matching based on the computed matching parameters can be performed during provider matching time periods. Each provider matching time periods can be preceded by an associated pre-match computation time period. A service request received too late to be included in the set of users for an upcoming provider matching period can be matched with service providers during a subsequent provider matching period. As an alternative implementation, the network system can perform provider matching in a dynamic fashion and not in accordance with any fixed schedule or cycle.
Demiralp: Sec. 0057, Provider matching can be performed during provider matching time periods);
during at least one time interval of the plurality of time intervals, implementing a matching process to match individual job orders of the plurality of job orders with one or more service providers of a plurality of service providers, wherein for each job order of the multiple job orders that have the open status, implementing the matching process includes determining a matched primary service provider, and wherein for a first job order of the multiple job orders with the open status, implementing the matching process includes determining a matched primary service provider and a matched backup service provider for the first job order during the first time interval of the plurality of time intervals(
Demiralp: Sec. 0020, the network system can identify a service provider for a given user by optimizing matching parameters (e.g., by performing multivariate optimizations).
Demiralp: Sec. 0021, the network system can optimize the matching parameters on a group basis to identify optimal user-to-provider pairings from the potential user-to-provider pairings. The network system can perform group multivariate optimizations of the parameters or variables described herein, such as distances of the service providers to the users, estimated times of arrival of the service providers, etc.
Demiralp: Sec. 0022, the network system can perform provider matching periodically (e.g., in accordance with a fixed schedule such as every thirty seconds or every two minutes, etc.). For instance, computation of matching parameters can be performed during pre-match computation time periods and the provider matching based on the computed matching parameters can be performed during provider matching time periods. Each provider matching time periods can be preceded by an associated pre-match computation time period. A service request received too late to be included in the set of users for an upcoming provider matching period can be matched with service providers during a subsequent provider matching period. As an alternative implementation, the network system can perform provider matching in a dynamic fashion and not in accordance with any fixed schedule or cycle.
Demiralp: Sec. 0057, Provider matching can be performed during provider matching time periods.);
wherein implementing the matching process includes implementing a set of group level objectives for the one or more service providers to optimize the matching process (
Demiralp: Sec. 0021, optimize the matching parameters on a group basis to identify optimal user-to-provider pairings from the potential user-to-provider pairings… when the network system identifies or classifies a user as a pre-request matching user, the network system can include the user as part of the group when performing group multivariate optimizations
Demiralp: Sec. 0052, The provider matching 140 can select an optimal user-to-provider pairings from the potential (or hypothetical) user-to-provider pairings based on a group optimization of the matching parameters 131. In one implementation, the provider matching 140 can resolve a bipartite graph to select the optimal user-to-provider pairings.
Demiralp: Sec. 0065, The network system can match users with available service providers by performing a group optimization of the computed matching parameters. In some examples, the network system can perform optimization with an objective to minimize an aggregate measure of the set of users' wait times in rendezvousing with service providers (e.g., minimize an average wait time, minimize a median wait time). Variations can include ones in which outliers (e.g., users which have a wait time of 2× or greater than the median) are taken into consideration in the group optimization and ones in which outliers can be excluded (e.g., on the rationale that the outlier users have to wait a relatively long time for a service provider regardless of the group optimization). Some implementations can take a hybrid approach in which a subset of the set of users are included in the group optimization while for others (e.g., outlier users), the network system can perform optimizations on an individual basis to match them with service providers.);
for each job order of the multiple job orders having the open status, making the job order available to the matched primary service provider by transmitting a first communication to a computing device associated with the matched primary service provider, the first communication enabling the matched primary service provider to accept or not accept the job order (
Demiralp: Sec. 0012, transmit a service invitation to one or more service provider devices of the proximate available service providers to fulfil the service request. In many examples, the service providers can either accept or decline the invitation based on, for example, the service location being impractical for the service provider.);
for at least the first job order of the multiple job orders, if the matched primary service provider does not accept the first job order, without reperforming the matching process, transmitting a second communication to a computing device associated with the backup service provider matched to the first job order during the first time interval of the plurality of time intervals, the second communication enabling the matched backup service provider to accept or not accept the first job order (
Demiralp: Sec. 0012, In many examples, the service providers can either accept or decline the invitation based on, for example, the service location being impractical for the service provider.
Demiralp: Sec. 0014, In some examples, during this period of time in which the service provider is pre-matched with the user, the network system can be configured to hold the service provider without transmitting an invitation associated with the pre-request matched user to the service provide
Demiralp: Sec. 0081, a pre-request hold can include reserving the service provider for the user and classifying the service provider as not available for provider matching with other providers during subsequent provider matching time periods while the pre-request hold is effective.
Demiralp: Sec. 0090, in response to receiving the service request after pre-request matching the user with the service provider, the network system can automatically transmit an invitation to the service provider pre-request matched with the user (step 220B). In doing so, the network system can avoid re-performing provider matching and can transmit the invitation as soon as the service request is received from the user (as compared with after the subsequent provider matching time period in comparison with step 220A).
Demiralp: Sec. 0091, for a first geographic region managed by the network system (e.g., a high traffic area such as an airport), the network system can be configured to proceed via 220B to automatically transmit an invitation in response to receiving the service request from the user without re-performing provider matching for the user
Demiralp: Sec. 0093, On the other hand, if the service provider declines the invitation, the network system can re-perform provider matching for the user during the subsequent provider match period to identify another service provider for the use.
Demiralp: Sec. 0124, At step 265, the service provider accepts the invitation 263TX. This can cause the provider device to transmit an acceptance 265TX to the network system. If the first service provider declined the invitation (or did not accept the invitation before an expiration time) (not illustrated in FIG. 2E), the provider device can transmit a rejection signal to the network system and the network system can identify another service provider for the first user.).
Demiralp describes the service provider having the capability to accept or decline a job, without sending out communication such as invitations. As well as, not reperforming the matching process, as this works with the communication of multiple service providers, which includes having alternative providers if the first provider doesn’t work.
Referring to Claim 12, Demiralp teaches the non-transitory computer-readable medium of claim 11, wherein identifying a plurality of job orders includes identifying multiple job orders that have a pending status, each job order with the pending status being currently matched to one of the plurality of service providers and awaiting the matched service provider to accept or not accept the job order;
wherein for individual job orders of the multiple job orders having the pending status, implementing the matching process includes matching a backup service provider to the job order (
Demiralp: Sec. 0014, A service provider who is pre-request matched with a user can be held for the user (e.g., classified or labeled by the network system as unavailable for matching with other users) for at least a period of time (e.g., until the user submits a service request or until the pre-request match expires).
Demiralp: Sec. 0071, a service provider that was determined to be optimal by the group optimization process performed by the network system can be pre-request matched with the user and held for the user until the user submits a service request.).
Demiralp describes a pending state awaiting acceptance. Context models and matching parameters let the system consider additional providers during that time.
Referring to Claim 13, Demiralp teaches the non-transitory computer-readable medium of claim 11, wherein matching the backup service provider includes associating the job order with the matched backup service provider in place of a previously matched backup service provider (
Demiralp: Sec. 0022, the network system can perform provider matching periodically (e.g., in accordance with a fixed schedule such as every thirty seconds or every two minutes, etc.). For instance, computation of matching parameters can be performed during pre-match computation time periods and the provider matching based on the computed matching parameters can be performed during provider matching time periods. Each provider matching time periods can be preceded by an associated pre-match computation time period.
Demiralp: Sec. 0057, perform the method 200 to periodically perform provider matching between available service providers and a set of users, including users who submitted service requests (post-request matching users) and certain prospective users who have not yet submitted service requests (pre-request matching users). Provider matching can be performed during provider matching time periods.
Demiralp: Sec. 0060, a user may have previously indicated (e.g., via the user application) that he or she does not wish to be matched with a certain provider, or vice versa, due to, for example, a bad prior experience. In response to such an indication (e.g., stored in the user profile or the service provider's profile), the network system can filter the potential user-to-provider pairing comprising the user and the service provider. In this manner, the network system can reduce the number of potential user-to-provider pairings prior to computing the matching parameters and can thus reduce system computation workload.).
Referring to Claim 14, Demiralp teaches the non-transitory computer-readable medium of claim 11, wherein the operations further comprise:
for each job order of the plurality of job orders, determining an approval rate based at least in part on parametric information of a transport request that corresponds to the job order (
Demiralp: Sec. 0020, The matching parameters can include location-based parameters such as a distance between the service provider and the given user, an estimated time of arrival of the service provider to rendezvous with the given user, an estimated time of arrival of the given user at a service location (e.g., destination location of a transport service), an estimated cost for the requested service, etc. In certain implementations, the matching parameters can further include context-based parameters such as a determined likelihood of the user canceling the service request, a determined propensity of the service provider accepting an invitation related to the service request, a determined likelihood of the service provider cancelling an accepted invitation, and/or a determined propensity of the user submitting a service request (for pre-request matching). The context-based parameters can be determined using one or more context models based on context data associated with the user or the service provider
Demiralp: Sec. 0067, the computation of matching parameters and the setup of the bigraph can be performed during the pre-match computation time period (step 203) whereas the solving of the bigraph to identify user-to-provider pairings from the potential pairings can be performed during the provider matching time period (step 204).).
Demiralp describes context data and request parameters such as location, time, etc. for each potential pairing.
Referring to Claim 15, Demiralp teaches the non-transitory computer-readable medium of claim 14, wherein for the first job order of the multiple job orders with the open status, making a determination as to whether to associate the first job order with a backup service provider is based at least in part on the approval rate (
Demiralp: Sec. 0078, Depending on the determined probability, the network system can determine whether to perform pre-requesting matching for the given user (step 215). In one implementation, if the determined probability is equal to or above a threshold value (e.g., indicating that the user is as likely or more likely than the threshold probability to submit a service request during the lookahead period), the network system can proceed to step 216. ).
Demiralp describes based on context derived probability that the user will submit a request within a time window.
Referring to Claim 16, Demiralp teaches the non-transitory computer-readable medium of claim 15, wherein making the determination to associate the first job order with the backup service provider includes determining whether an approval rate of the first job order exceeds a threshold value (
Demiralp: Sec. 0016, the network system can determine a likelihood of whether the user will submit a service request within a given time window based on the context data relating to the user in determining whether to perform pre-request matching for the user).
Claims 17-20 recite limitations that stand rejected via the art citations and rationale applied to claims 11-14.
Response to Arguments
Applicant’s arguments filed 07/09/2026 have been fully considered but they are not persuasive. Applicant’s arguments will be addressed hereinbelow in the order in which they appear in the response filed 07/09/2026.
Regarding the 35 U.S.C. 101 rejection, at pg. 8-14 Applicant argues with respect to claims at issue are not directed to an abstract idea
In response to the 35 USC § 101 claim rejection argument, the Examiner respectfully disagrees. The Examiner did consider each claim and every limitation both individually and as a whole, since the grounds of rejection clearly indicates that an abstract idea has been identified from elements recited in the claims. Using the two-part analysis, the Office has determined there are no elements, in the claim sufficient enough to ensure that the claims amounts to significantly more than the abstract idea itself. As recited, the claims are directed towards:
A network system comprising:
one or more processors;
a memory to store instructions;
wherein the one or more processors execute the instructions to perform operations that include:
receiving, over one or more networks, a transport request;
generating a job order based on the transport request;
during a first time interval of a plurality of time intervals at which matching job orders to service providers is performed, (i) performing a matching process to match the job order to multiple service providers, the multiple service providers including a first service provider and a second service provider,
and (ii) transmitting, over the one or more networks, a first communication that specifies the job order to a computing device of the first service provider but not to a computing device of any other service provider of the multiple service providers, the first communication enabling the first service provider to accept or not accept the job order; and
in response to a determination that the first service provider does not accept the job order, transmitting, over the one or more networks, without reperforming the matching process, a second communication that specifies the job order to a computing device of the second service provider matched to the Job order during the first time interval without sending a communication to any other service provider of the multiple service providers, the second communication enabling the second service provider to accept or not accept the job order using the computing device of the second service provider.
The claim(s) does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the computer as recited is a generic computer component that performs functions.
Examiner finds the claim recite concepts which are now described in the 2019 PEG as certain methods of organizing human activity. In particular the claims recites limitations for managing orders and service providers, which constitutes methods related to commercial interaction such as business relations; managing personal behavior (including teaching, and following rules or instructions) which are still considered an abstract idea under the 2019 PEG. Examiner finds the claims recite mere instructions to implement the abstract idea on a computer and uses the computer as a tool to perform the abstract idea without reciting any improvements to a technology, technological process or computer-related technology.
Regarding, the steps at pg. 10-11 that Applicant points to as significantly more or technical solution are merely narrowing the abstract idea to a particular technological environment, which has been found to be ineffective to render an abstract idea eligible. Furthermore, the Examiner respectfully disagrees because the following steps and arguments of:
Pg. 10. “The service provider can then accept or reject the job order, either through affirmative action (e.g., interaction through user device) or through no-action (e.g., by default).”
Pg. 10. “Among other technical benefits, the network system makes the job order exclusively available to the second service provider”…”make the job order exclusively available to a second service provider”
Pg. 11. “The network system can also improve efficiencies over conventional approaches by determining a backup service provider for a service request at the same time as the primary service provider.”
Pg. 11. “As a result of the matching process being performed, the backup service providers may be matched as primary service providers to other job orders, and/or alternative service providers can be determined as the corresponding backup service providers for pending service requests. By continuing
to implement the matching process using backup service providers, the network system avoids limiting the pool of candidate service providers for future time intervals when matching is performed. Furthermore, the network system can maintain its optimization objectives by refreshing the backup service providers that are associated with pending job orders.”
Pg. 12. “during a first time interval of a plurality of time intervals at which matching job orders to service providers is performed”; “the first communication enabling the first service provider to accept or not accept the job order”; “the second communication enabling the second service provider to accept or not accept the job order using the computing device of the second service provider.”
seems to describe a “particular way” of managing orders and service providers are part of the abstract idea. The Applicant is admitting that the application is directed to improving the user’s experience, as the above steps and arguments are directed to human interactions and not the system software or any type of computer or structure.
Then, at 14 the Applicant argue:
“The additional technical solution further recited by Claim 11 includes "implementing a set of group level objectives for the one or more service providers to optimize the matching process". For example, the Specification identifies an effect of implementing group level objectives:
"the matching engine 140 can match open job orders 125 to available
service providers based on one or more objectives that include (i) minimizing
a total (or group-level) wait time of requesters until pickup, and/or (ii)
minimizing a total (or group level) distance traveled by service providers to
reach the service start (or pickup) locations".
Under Prong 2 of Step 2A, the above emphasized feature of Claim 11 is also an "additional element" that integrates the alleged abstract idea into a practical application, and as such, confers subject matter eligibility onto the claims.”
Applicant is basically relying on the matching engine as integrating the abstract idea into a practical application but those matching engine aren't really utilized in any particular manner, and the specification indicates that at 0016 " Additionally, one or more examples described herein can be implemented using programmatic modules, engines, or components. A programmatic module, engine, or component can include a program, a sub-routine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs, or machines. ", which indicates the lack of particularity in the application to the technological environment.
Additionally, the Examiner would like to point the Applicant to the 2019 PEG, in which managing orders and service providers will fall under. The 2019 PEG which states:
Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
Adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g)
Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h)
Regarding the 35 U.S.C. 102 rejection, at pg. 15-16 Applicant argues that “The cited references, whether viewed individually or in combination, fail to disclose, "in response to a determination that the first service provider does not accept the job order, transmitting, over the one or more networks, without reperforming the matching process, a second communication that specifies the job order to a computing device of the second service provider matched to the job order during the first time interval without sending a communication to any other service provider of the multiple service providers, the second communication enabling the second service provider to accept or not accept the job order using the computing device of the second service provider," as recited by Claim 1.”.
In response, the Examiner respectfully disagrees. Demiralp describes the service provider having the capability to accept or decline a job, without sending out communication such as invitations. As well as, not reperforming the matching process, as this works with the communication of multiple service providers.
At pg. 16-17, Applicant argues that “The cited references do not disclose, "for at least the first job order of the multiple job orders, if the matched primary service provider does not accept the first job order, without reperforming the matching process, transmitting a second communication to a computing device associated with the backup service provider matched to the first job order during the first time interval of the plurality of time intervals, the second communication enabling the matched backup service provider to accept or not accept the first job order," as recited by Claim 11.”.
In response, the Examiner respectfully disagrees. Demiralp describes the service provider having the capability to accept or decline a job, without sending out communication such as invitations. As well as, not reperforming the matching process, as this works with the communication of multiple service providers, which includes having alternative providers if the first provider doesn’t work.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Felt et al., U.S. Pub. US20110099040A1, (discussing the managing and dispatching of vehicles to be taxis.).
Hicok et al., W.O. Pub. 2019165451, (discussing the managing of on-demand rides).
Mishra et al., Integrated Dynamic Transit Operations (IDTO) concept of operations, https://rosap.ntl.bts.gov/view/dot/3451/dot_3451_DS1.pdf, U.S. Department of Transportation, FHWA-JPO-12-083, 2012 (discussing the managing of paid transportation.).
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 UCHE BYRD whose telephone number is (571)272-3113. The examiner can normally be reached Mon.-Fri..
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, Patricia Munson can be reached at (571) 270-5396. 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.
/UCHE BYRD/Examiner, Art Unit 3624 /PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624
