DETAILED ACTION
Status of the Application
Claims 1-20 have been examined in this application. This communication is the first action on the merits. The information disclosure statement (IDS) submitted on 06/10/2025; was filed with this application. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 Non-Final Action on the merits in response to the application filed on 06/10/2025.
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-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;
generating a job order based on the transport request;
during a first time interval, (i) performing a matching process to match the job order to multiple service providers, including a first service provider and a second service provider, and (ii) the first communication enabling the first service provider to accept or not accept the job order;
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:
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, receiving, over one or more networks, a transport request;
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 but not to a computing device of 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 mere data gathering and output 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 data gathering and output, and, as such, these limitations do not impose any meaningful limits on the claim. These limitations amount to necessary data gathering and outputting. 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: This part of the eligibility analysis evaluates whether the claim as a whole amounts to significantly more than the recited exception i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim. See MPEP 2106.05. As explained with respect to Step 2A, Prong Two, the additional elements are the processor, memory, computing device. The additional elements were found to be insignificant extra-solution activity in Step 2A, Prong Two, because they were determined to be insignificant limitations as necessary data gathering and outputting.
However, a conclusion that an additional element is insignificant extra solution activity in Step 2A, Prong Two should be re-evaluated in Step 2B. See MPEP 2106.05, subsection I.A. At Step 2B, the evaluation of the insignificant extra-solution activity consideration takes into account whether or not the extra-solution activity is well understood, routine, and conventional in the field. See MPEP 2106.05(g). As discussed in Step 2A, Prong Two above, the recitations of
one or more processors;
a memory to store instructions;
wherein the one or more processors execute the instructions to perform operations that include:
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, receiving, over one or more networks, a transport request;
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 but not to a computing device of 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 recited at a high level of generality. These elements amount to transmitting data and are well understood, routine, conventional activity. See MPEP 2106.05(d), subsection II. 10 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, (i) performing a matching process to match the job order to 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 but not to a computing device of 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. 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).).
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, 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);
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 each of the matched primary service provider and a matched backup service provider (
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.);
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, transmitting a second communication to a computing device associated with the backup service provider, the second communication enabling the matched backup service provider to accept or not accept the first job order (
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).
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.
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.).
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
Prosecution Insights