DETAILED ACTION
This action is responsive to the response filed on 11/12/2025.
Claims 1-7 and 10-18 remain pending in this application. Claims 1, 5, 10, and 13 have been amended. Claims 1, 10, and 13 are independent claims.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 1, 10, and 13 are objected to because of the following informalities:
Replace, for each of the claims, the limitation … transmitting, at the relocation time, … to a computing device … with … transmitting, at the relocation time, … to the computing device … Appropriate correction is required for proper antecedent basis, since a computing device has been recited/introduced in an earlier amended limitation.
Move, for each of the claims, the limitation … detecting the first service provider being positioned at the intermediate location in advance of the pickup time … between the two “transmitting” limitations for the claim limitations to flow in a comprehensible sequence.
Examiner Comments
Applicant is advised that should claim 1 be found allowable, claim 10 will be objected to under 37 CFR 1.75 as being a substantial duplicate thereof. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
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 and 10-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Independent claims 1 and 13 recite “scheduling a transport service for an upcoming scheduled event at a mass egress location, the scheduled transport service identifying one or more transport service parameters including a pickup time when a transport service is to initiate for a user”, “monitoring one or more activities associated with the upcoming scheduled event to determine whether to update the one or more transport service parameters, including the pickup time”, “predicting a provisioning level of service providers for the mass egress location …”, “based on the predicted provisioning level of service providers for the mass egress location, implementing a queue mode to manage a queue that identifies multiple service providers within one or more regions associated with the mass egress location, wherein when the queue mode is implemented, each of the multiple service providers is matched to a corresponding transport request based oat least in part on a time when….”, “determining, by monitoring one or more third-party data sources, that an exception event has taken place, the exception event being determined to affect the scheduled transport service”, “in response to determining that the exception event has taken place, (i)implementing a pre-match mode … (ii) selecting, a first service provider from the multiple service providers …and (iii) determining a current location of the first service provider within one of the one or more regions associated with the mass egress location”, “determining, based at least in part on the one or more transport service parameters and the current location of the first service provider, a set of relocation parameters, the set of relocation parameters including (i) an intermediate location where the service provider is to be located to provide the user with the transport service, and (ii) an intermediate arrival time when the first service provider is to arrive at the intermediate location before the pickup time”, “determining, based at least in part on the set of relocation parameters, a relocation time when the service provider is to initiate travel to the intermediate location”, and “detecting the first service provider being positioned at the intermediate location in advance of the pickup time” which can all be recognized as a mental process that can be performed in the human mind, but for the recitation of generic computer components (“one or more processors” and “a memory” for claim 1 and “non-transitory computer-readable medium” for claim 13). This can be exemplified by a series of observations (for a scheduling event, monitoring activities associated with it, observing/determining a current location of a certain provider), evaluations (predicting a provisioning level of service providers), and judgments (based on the predicted provisioning level of service providers, implementing a queue mode and in response to determining that the exception event has taken place, implementing a pre-match process and selecting a first service provider…, determining transport service parameters). It thus falls within the “Mental Processes” groupings of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the above-indicated limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions. Furthermore, the additional elements of “based … on location data received from a computing device …”, “transmitting, at the relocation time, a first notification …”, and “transmitting, based at least in part on the pickup time, a second notification …” amount to no more than adding insignificant extra-solution activity of mere data input /transmittal. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a processor, memory, and/or non-transitory computer-readable medium to perform the steps described above amounts to no more than mere instructions to apply the exception using generic computer components. The “… received …” and “transmitting” steps are further considered well-understood, routine, and conventional in view of the Symantec, TLI, and OIP Techs. court decisions cited in MPEP 2106.05(d)(II) indicating that mere collection, receipt, or transmittal of data over a network is a well-understood, routine, conventional function when it is claimed in a merely generic manner. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Neither can insignificant extra-solution.
Therefore, these limitations, taken alone or in combination, do not integrate the abstract idea into a practical application or recite significantly more that the abstract idea. Thus, these independent claims are not patent eligible.
Regarding independent claim 10, the rejection is identical to that of independent claim 1. See the Examiner Comments above.
The dependent claims respectively recite additional limitations of: … monitoring a status or location of the user within the mass egress location to update one or more of the transport parameters (claims 2 and 14), … automatically updating the pickup time in response to detecting a change to the scheduled event (claims 3 and 15), … monitoring a location of the user (claims 4 and 16), inferring the one or more transport service parameters for the scheduled event, based on a preceding or subsequent transport event (claim 5), … and implementing a queue matching process in the queue mode by (i) selecting a set of service providers that have a low queue priority position (claim 11). These additional limitations also constitute concepts performed in the human mind which fall within the “Mental Processes” groupings of abstract ideas.
This judicial exception is not integrated into a practical application. Additional elements of using specific criteria for the determinations (claims 6, 7, 17, and 18), … utilizing one or more program interfaces to detect changes to the scheduled event (claims 3 and 15), and … (ii) transmitting an invitation that identifies the upcoming scheduled event to the set of service providers (claim 11), and specifics of the data transmitted (claim 12), all amount to no more than adding insignificant extra-solution activity/specifications related to data gathering, data input, or data transmittal. Implementing the data input via a program interface amounts to no more than mere instructions to apply an exception using generic computer components cannot provide an inventive concept. These additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The dependent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of receiving and transmitting information, which are mere data gathering, data input, or data transmittal are again insignificant extra-solution activity steps that cannot provide an inventive concept. All of these additional elements as generically claimed are considered well-understood, routine, and conventional in view of the Symantec, TLI, and OIP Techs. court decisions cited in MPEP 2106.05(d)(II) indicating that mere collection or receipt of data over a network is a well-understood, routine, conventional function when it is claimed in a merely generic manner. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Neither can insignificant extra-solution activity.
Therefore, these limitations, taken alone or in combination, do not integrate the abstract idea into a practical application or recite significantly more that the abstract idea.
Thus, all of the dependent claims are also not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5, 6, 10, 13-15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Marco et al., US PGPUB 2017/0098224 Al (hereinafter as Marco) in view of Schwendimann et al., US PGPUB 2022/0309925 A1 (hereinafter as Schwendimann), Kantarjiev et al., US PGPUB 2005/0021225 Al (hereinafter as Kantarjiev) and Peng, US PGPUB 2016/0335576 Al (hereinafter as Peng).
Regarding independent claim 1, Marco teaches a network computer system [note the network computer system in fig. 1; see also fig. 2] comprising:
one or more processors [see the processors in fig. 2];
a memory to store instructions [see the memory units in fig. 2];
wherein the one or more processors execute the instructions stored in the memory to perform operations that comprise:
scheduling a transport service for an upcoming scheduled event at a mass egress location, the scheduled transport service identifying one or more transport service parameters including a pickup time when a transport service is to initiate for a user [see e.g. [0095] and note scheduling a ride including identifying a pickup time related to an event; see examples of events in [0073]; note also from the last 8 lines of [0072] the determination of a location as well as an estimated end time for the event; see also the scheduling in fig. 5];
monitoring one or more activities associated with the upcoming scheduled event to determine whether to update the one or more transport service parameters, including the pickup time [see e.g. [0102] indicating receiving updated information regarding the end time of the event and the possibility of updating the schedule for directing drivers to the event; especially note steps 510 and 512 in fig. 5; see also e.g. [0075] describing the periodic update of the end time of an event];
predicting a provisioning level of service providers for the mass egress location during a period associated with the scheduled event [see e.g. [0086] and note a projected supply of drivers; see also in the last 3 lines of [0085] an average number of drivers arriving at the event location being determined for a certain duration; see also the first 3 lines of [0083]; see also [0079]-[0081] describing the predicted provisioning level of service in terms of both demand and supply; Examiner notes that the determination of provisional level, according to Applicant’s specification as e.g. in [0046]-[0047], can be based on available supply and/or expected demand];
based on the predicted provisioning level of service providers for the mass egress location, implementing a queue mode to manage a queue that identifies multiple service providers within one or more regions associated with the mass egress location [see e.g. [0085] and note the placement of requests in a queue if the demand for drivers is greater than the supply of drivers (i.e. based on a provisioning level of providers) and consecutive pairing of drivers with passengers in the queue as they are expected to arrive at the event location; note the regions such as 404 indicated in fig. 4 which are geographical delineations for passenger pickup regions associated with the mass egress location, as per [0097]-[0098]], wherein when the queue mode is implemented, each of the multiple service providers is matched to a corresponding transport request based on a variety of factors [again see the queue mode matching in [0085] and note the exemplary factors for the queue mode matching and the option for incorporating other or additional factors];
determining, by monitoring one or more third-party data sources, that an exception event has taken place, the exception event being determined to affect the scheduled transport service [note in [0075]-[0076] third-party data sources such as sports or airports websites monitoring the scheduled event; Examiner notes that an exceptional event, according to Applicant’s specification as e.g. in [0051]-[0052], can be based on a delay of a certain arbitrarily chosen time period); note in [0102] the change of an end time and in [0103] the option of repetition, combination, and modifications to the steps of fig. 5];
in response to determining that a change in operations has taken place: (i)implementing a pre-match mode for the scheduled transport service, (ii) selecting, a first service provider from the multiple service providers within one of the one or more regions associated with the mass egress location for the scheduled transport request, and (iii) determining a current location of the first service provider within one of the one or more regions associated with the mass egress location based at least in part on location data received from a computing device of the first service provider [note in fig. 6, steps 604 and 606 and the description in [0104]-[0107] the determination of a certain predicted provisioning level in 606 and the pairing of drivers with passengers in cases when driver demand does not exceed the driver supply; note that if the demand does not exceed the supply (i.e. the difference between the demand and the supply is less than or equal to zero), the pairing (or pre-matching) occurs; note also the option of assigning requests to drivers as in the last 3 lines of [0058] which is a form of pre-matching; see e.g. [0067] indicating the selection of a particular driver by the system to match a request and note also the proximity of the driver to the pickup location of the event; note again in [0097] and fig. 4 the pickup regions associated with the mass egress location; further note in [0021] that a computing device of each of service providers may periodically transmit their current location to the backend system]; and
transmitting, based at least in part on the pickup time, a notification to the computing device of the first service provider to direct the first service provider to a pickup location within the mass egress location, to initiate the transport service for the user from the mass egress location [see e.g. [0069] indicating transmitting navigation information to the driver’s mobile device to direct the driver to the pickup location ; note from fig. 5, step 512 that the updated schedule (including the updated pickup time) is used to direct drivers to the event location].
Although Marco does not explicitly teach that the matching of the multiple service providers to the corresponding transport request (in the queue mode) is based at least in part on a time when the service provider entered one of the one or more regions associated with the mass egress location, Marco does teach an assignment factor of a particular driver to a passenger based on the driver’s proximity to the pick-up location [see e.g. the last 4 lines of [0067]], which is a priority based on distance. Marco further teaches geofences of the mass egress location [note the regions such as 404 indicated in fig. 4 which are geographical delineations for passenger pickup regions associated with the mass egress location, as per [0097]-[0098]].
It would have been obvious to one of ordinary skill in the art having the teachings of Marco before the effective filing date of the claimed invention, to modify the factors taught by Marco to further specify basing the matching of providers to requests at least in part on a time when the service provider entered one of the one or more regions associated with the mass egress location since it would have been obvious that the earlier the provider entered the geofence, the closer they are to the pick-up location.
Marco does not explicitly teach any of the following:
determining, based at least in part on the one or more transport service parameters and the current location of the first service provider, a set of relocation parameters, the set of relocation parameters including (i) an intermediate location where the first service provider is to be located to provide the user with the transport service, and (ii) an intermediate arrival time when the first service provider is to arrive at the intermediate location before the pickup time;
determining, based at least in part on the set of relocation parameters, a relocation time when the first service provider is to initiate travel to the intermediate location;
transmitting, at the relocation time, a first notification to the computing device of the first service provider to direct the first service provider to the intermediate location; and
detecting the first service provider being positioned at the intermediate location in advance of the pickup time.
Neither does it teach that the notification to the computing device of the first service provider to direct the first service provider to a pickup location within the mass egress location, to initiate the transport service from the mass egress location is from the intermediate location.
It also does not teach that the implementation of a pre-match mode is in response to determining that the exception event has taken place.
Schwendimann teaches:
determining, based at least in part on one or more transport service parameters and the current location of a service provider, a set of relocation parameters, the set of relocation parameters including (i) an intermediate location where the service provider is to be located to provide a user with a transport service, and (ii) an intermediate arrival time when the service provider is to arrive at the intermediate location before a pickup time [note e.g. from [0007] the selection of an intermediate preposition location for the vehicle (which can be related to the pickup location); note e.g. from [0003] the determination of a temporal limit for which the vehicle is able to pick up the rider by the estimated pickup time; note from [0010] the determination of the current position of the vehicle and the coupling between the positioning system and the control system];
transmitting a first notification to a computing device of the service provider to direct the service provider to the intermediate location [note e.g. in fig. 10, step 1006, causing a driving system of a vehicle to preposition the vehicle to a certain location];
detecting the service provider being positioned at the intermediate location in advance of the pickup time; and transmitting, based at least in part on the pickup time, a notification to the computing device of the service provider to direct the service provider from the intermediate location to a pickup location [note e.g. in fig. 10, step 1008, causing the driving system of a vehicle to maneuver the vehicle from the prepositioned (intermediate) location to the pickup location before or at the estimated pickup time].
Schwendimann’s known loitering mode for rider pickups is applicable to the operations taught by Marco for facilitating the pickup of a user from a mass egress location.
One of ordinary skill in the art would have recognized that applying Schwendimann’s technique of prepositioning a vehicle at a current location to an intermediate location by an intermediate time then directing it the pickup location by the estimated pickup time to Marco’s environment would have yielded the predictable results of ensuring a pickup by a specified time by avoiding unnecessary delays and providing the best use for vehicle resources while ensuring a positive rider experience, as also suggested by Schwendimann [see e.g. [00001] and the first 3 lines in [0070]].
The rationale for the combination would be that a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art. One of ordinary skill in the art would have been capable of applying this known technique to a known invention that was ready for improvement and the results would have been predictable to one of ordinary skill in the art.
See MPEP 2143 I.D.
Marco/Schwendimann does not explicitly teach determining, based at least in part on the set of relocation parameters, a relocation time when the service provider is to initiate travel to the intermediate location. Neither does it teach that transmitting the notification to direct the first service provider to the intermediate location is at the relocation time.
It also does not teach that the implementation of a pre-match mode is in response to determining that the exception event has taken place.
Kantarjiev teaches determining, based at least in part on a set of relocation parameters (including a current location of a service provider, a desired destination, and a desired arrival time), a relocation time when the service provider is to initiate travel to the desired destination/location [note e.g. in [0014] the determination of a departure time based at least in part on a starting location, a destination, and a desired arrival time; see also [0015]].
It would have been obvious to one of ordinary skill in the art having the teachings of Marco, Schwendimann, and Kantarjiev, before the effective filing date of the claimed invention, to modify the operations taught by Marco and modified by Schwendimann to explicitly specify determining a relocation time when the first service provider is to initiate travel to a desired location based in part on a set of relocation parameters, as per the teachings of Kantarjiev, and to further specify transmitting the notification to direct the first service provider to the intermediate location at the relocation time. The motivation for this obvious combination would be to allow for on-time arrivals at specific locations, as taught by Kantarjiev [see e.g. [0003]].
The previously combined art, still, does not explicitly teach that the implementation of a pre-match mode is in response to determining that the exception event has taken place.
Peng teaches an implementation of a pre-match mode (assignment) that is in response to determining that an exception event has taken place [note e.g. in [0046] the driver/passenger assignment being implemented responsive to a pick-up request spike (which can be interpreted to be an occurrence of an exception for pick-up requests)].
It would have been obvious to one of ordinary skill in the art having the teachings of the previously combined art and Peng, before the effective filing date of the claimed invention, to modify the operations taught by Marco to explicitly specify apply the teachings of Peng of implementing a pre-match mode in response to determining a request spike to the exception of Marco of a change of an event ending time resulting in a spike of requests affecting scheduled transport services. The motivation for this obvious combination would be to simplify mitigating the anticipated supply shortage at the event location by keeping track of the amount of committed (assigned) drivers, as taught by Peng [see e.g. [0046]].
Regarding independent claim 10, the rejection is identical to that of independent claim 1. See the Examiner Comments above.
Regarding independent claim 13, Marco also teaches a non-transitory computer-readable medium that stores instructions, which when executed by one or more processors of a network computer system [see [0052]; see also claim 15; note the network computer system in fig. 1], cause the network computer system to perform operations that include:
scheduling a transport service for an upcoming scheduled event at a mass egress location, the scheduled transport service identifying one or more transport service parameters including a pickup time when a transport service is to initiate for a user [see e.g. [0095] and note scheduling a ride including identifying a pickup time related to an event; see examples of events in [0073]; note also from the last 8 lines of [0072] the determination of a location as well as an estimated end time for the event; see also the scheduling in fig. 5];
monitoring one or more activities associated with the upcoming scheduled event to determine whether to update the one or more transport service parameters, including the pickup time [see e.g. [0102] indicating receiving updated information regarding the end time of the event and the possibility of updating the schedule for directing drivers to the event; especially note steps 510 and 512 in fig. 5; see also e.g. [0075] describing the periodic update of the end time of an event];
predicting a provisioning level of service providers for the mass egress location during a period associated with the scheduled event [see e.g. [0086] and note a projected supply of drivers; see also in the last 3 lines of [0085] an average number of drivers arriving at the event location being determined for a certain duration; see also the first 3 lines of [0083]; see also [0079]-[0081] describing the predicted provisioning level of service in terms of both demand and supply; Examiner notes that the determination of provisional level, according to Applicant’s specification as e.g. in [0046]-[0047], can be based on available supply and/or expected demand];
based on the predicted provisioning level of service providers for the mass egress location, implementing a queue mode to manage a queue that identifies multiple service providers within one or more regions associated with the mass egress location [see e.g. [0085] and note the placement of requests in a queue if the demand for drivers is greater than the supply of drivers (i.e. based on a provisioning level of providers) and consecutive pairing of drivers with passengers in the queue as they are expected to arrive at the event location; note the regions such as 404 indicated in fig. 4 which are geographical delineations for passenger pickup regions associated with the mass egress location, as per [0097]-[0098]], wherein when the queue mode is implemented, each of the multiple service providers is matched to a corresponding transport request based on a variety of factors [again see the queue mode matching in [0085] and note the exemplary factors for the queue mode matching and the option for incorporating other or additional factors];
determining, by monitoring one or more third-party data sources, that an exception event has taken place, the exception event being determined to affect the scheduled transport service [note in [0075]-[0076] third-party data sources such as sports or airports websites monitoring the scheduled event; Examiner notes that an exceptional event, according to Applicant’s specification as e.g. in [0051]-[0052], can be based on a delay of a certain arbitrarily chosen time period); note in [0102] the change of an end time and in [0103] the option of repetition, combination, and modifications to the steps of fig. 5];
in response to determining that a change in operations has taken place: (i)implementing a pre-match mode for the scheduled transport service, (ii) selecting, a first service provider from the multiple service providers within one of the one or more regions associated with the mass egress location for the scheduled transport request, and (iii) determining a current location of the first service provider within one of the one or more regions associated with the mass egress location based at least in part on location data received from a computing device of the first service provider [note in fig. 6, steps 604 and 606 and the description in [0104]-[0107] the determination of a certain predicted provisioning level in 606 and the pairing of drivers with passengers in cases when driver demand does not exceed the driver supply; note that if the demand does not exceed the supply (i.e. the difference between the demand and the supply is less than or equal to zero), the pairing (or pre-matching) occurs; note also the option of assigning requests to drivers as in the last 3 lines of [0058] which is a form of pre-matching; see e.g. [0067] indicating the selection of a particular driver by the system to match a request and note also the proximity of the driver to the pickup location of the event; note again in [0097] and fig. 4 the pickup regions associated with the mass egress location; further note in [0021] that a computing device of each of service providers may periodically transmit their current location to the backend system]; and
transmitting, based at least in part on the pickup time, a notification to the computing device of the first service provider to direct the first service provider to a pickup location within the mass egress location, to initiate the transport service for the user from the mass egress location [see e.g. [0069] indicating transmitting navigation information to the driver’s mobile device to direct the driver to the pickup location ; note from fig. 5, step 512 that the updated schedule (including the updated pickup time) is used to direct drivers to the event location].
Although Marco does not explicitly teach that the matching of the multiple service providers to the corresponding transport request (in the queue mode) is based at least in part on a time when the service provider entered one of the one or more regions associated with the mass egress location, Marco does teach an assignment factor of a particular driver to a passenger based on the driver’s proximity to the pick-up location [see e.g. the last 4 lines of [0067]], which is a priority based on distance. Marco further teaches geofences of the mass egress location [note the regions such as 404 indicated in fig. 4 which are geographical delineations for passenger pickup regions associated with the mass egress location, as per [0097]-[0098]].
It would have been obvious to one of ordinary skill in the art having the teachings of Marco before the effective filing date of the claimed invention, to modify the factors taught by Marco to further specify basing the matching of providers to requests at least in part on a time when the service provider entered one of the one or more regions associated with the mass egress location since it would have been obvious that the earlier the provider entered the geofence, the closer they are to the pick-up location.
Marco does not explicitly teach any of the following:
determining, based at least in part on the one or more transport service parameters and the current location of the first service provider, a set of relocation parameters, the set of relocation parameters including (i) an intermediate location where the first service provider is to be located to provide the user with the transport service, and (ii) an intermediate arrival time when the first service provider is to arrive at the intermediate location before the pickup time;
determining, based at least in part on the set of relocation parameters, a relocation time when the first service provider is to initiate travel to the intermediate location;
transmitting, at the relocation time, a first notification to the computing device of the first service provider to direct the first service provider to the intermediate location; and
detecting the first service provider being positioned at the intermediate location in advance of the pickup time.
Neither does it teach that the notification to the computing device of the first service provider to direct the first service provider to a pickup location within the mass egress location, to initiate the transport service from the mass egress location is from the intermediate location.
It also does not teach that the implementation of a pre-match mode is in response to determining that the exception event has taken place.
Schwendimann teaches:
determining, based at least in part on one or more transport service parameters and the current location of a service provider, a set of relocation parameters, the set of relocation parameters including (i) an intermediate location where the service provider is to be located to provide a user with a transport service, and (ii) an intermediate arrival time when the service provider is to arrive at the intermediate location before a pickup time [note e.g. from [0007] the selection of an intermediate preposition location for the vehicle (which can be related to the pickup location); note e.g. from [0003] the determination of a temporal limit for which the vehicle is able to pick up the rider by the estimated pickup time; note from [0010] the determination of the current position of the vehicle and the coupling between the positioning system and the control system];
transmitting a first notification to a computing device of the service provider to direct the service provider to the intermediate location [note e.g. in fig. 10, step 1006, causing a driving system of a vehicle to preposition the vehicle to a certain location];
detecting the service provider being positioned at the intermediate location in advance of the pickup time; and transmitting, based at least in part on the pickup time, a notification to the computing device of the service provider to direct the service provider from the intermediate location to a pickup location [note e.g. in fig. 10, step 1008, causing the driving system of a vehicle to maneuver the vehicle from the prepositioned (intermediate) location to the pickup location before or at the estimated pickup time].
Schwendimann’s known loitering mode for rider pickups is applicable to the operations taught by Marco for facilitating the pickup of a user from a mass egress location.
One of ordinary skill in the art would have recognized that applying Schwendimann’s technique of prepositioning a vehicle at a current location to an intermediate location by an intermediate time then directing it the pickup location by the estimated pickup time to Marco’s environment would have yielded the predictable results of ensuring a pickup by a specified time by avoiding unnecessary delays and providing the best use for vehicle resources while ensuring a positive rider experience, as also suggested by Schwendimann [see e.g. [00001] and the first 3 lines in [0070]].
The rationale for the combination would be that a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art. One of ordinary skill in the art would have been capable of applying this known technique to a known invention that was ready for improvement and the results would have been predictable to one of ordinary skill in the art.
See MPEP 2143 I.D.
Marco/Schwendimann does not explicitly teach determining, based at least in part on the set of relocation parameters, a relocation time when the service provider is to initiate travel to the intermediate location. Neither does it teach that transmitting the notification to direct the first service provider to the intermediate location is at the relocation time.
It also does not teach that the implementation of a pre-match mode is in response to determining that the exception event has taken place.
Kantarjiev teaches determining, based at least in part on a set of relocation parameters (including a current location of a service provider, a desired destination, and a desired arrival time), a relocation time when the service provider is to initiate travel to the desired destination/location [note e.g. in [0014] the determination of a departure time based at least in part on a starting location, a destination, and a desired arrival time; see also [0015]].
It would have been obvious to one of ordinary skill in the art having the teachings of Marco, Schwendimann, and Kantarjiev, before the effective filing date of the claimed invention, to modify the operations taught by Marco and modified by Schwendimann to explicitly specify determining a relocation time when the first service provider is to initiate travel to a desired location based in part on a set of relocation parameters, as per the teachings of Kantarjiev, and to further specify transmitting the notification to direct the first service provider to the intermediate location at the relocation time. The motivation for this obvious combination would be to allow for on-time arrivals at specific locations, as taught by Kantarjiev [see e.g. [0003]].
The previously combined art, still, does not explicitly teach that the implementation of a pre-match mode is in response to determining that the exception event has taken place.
Peng teaches an implementation of a pre-match mode (assignment) that is in response to determining that an exception event has taken place [note e.g. in [0046] the driver/passenger assignment being implemented responsive to a pick-up request spike (which can be interpreted to be an occurrence of an exception for pick-up requests)].
It would have been obvious to one of ordinary skill in the art having the teachings of the previously combined art and Peng, before the effective filing date of the claimed invention, to modify the operations taught by Marco to explicitly specify apply the teachings of Peng of implementing a pre-match mode in response to determining a request spike to the exception of Marco of a change of an event ending time resulting in a spike of requests affecting scheduled transport services. The motivation for this obvious combination would be to simplify mitigating the anticipated supply shortage at the event location by keeping track of the amount of committed (assigned) drivers, as taught by Peng [see e.g. [0046]].
Regarding claims 2 and 14, the rejections of independent claims 1 and 13 are respectively incorporated. Schwendimann further teaches monitoring a status or location of the user within an egress location to update one or more of transport parameters [see e.g. [0060] and note the change in pickup location based on monitoring the location of the user within a shopping building; see also figs. 6B and 6C].
It would have been obvious to one of ordinary skill in the art having the teachings of the combined art, before the effective filing date of the claimed invention, to modify the operations taught by Marco and modified by Schwendimann to explicitly apply Schwendimann’s teaching regarding monitoring a status or location of the user within an egress location to update one or more of transport parameters to the mass egress location taught by Marco. The motivation for this obvious combination would be to allow for choosing pickup locations that are closer to the user, as taught by Schwendimann [again, see e.g. [0060]].
Regarding claims 3 and 15, the rejections of claims 1 and 14 are respectively incorporated. Marco further teaches that monitoring one or more activities associated with the scheduled event includes: utilizing one or more program interfaces to detect changes to the scheduled event, and automatically updating the pickup time in response to detecting a change to the scheduled event [note in the last 10 lines of [0075] the utilization of a website as an event information source to detect changes to a scheduled event; note from fig. 5, steps 510 and 512 the automatic update to the schedule for directing drivers following the receipt of updated information regarding end time of an event].
Regarding claim 5, the rejection of claim 1 is incorporated. Marco further teaches that determining the one or more service parameters for the scheduled event includes inferring the one or more transport service parameters for the scheduled event, based on a preceding or subsequent transport event [note e.g. in the last 3 lines of [0080] the selection of pickup times based on requests from previous events; see also in [0064] the use of historical event data related to transport events].
Regarding claims 6 and 17, the rejections of claims 1 and 14 are respectively incorporated. Schwendimann further teaches that determining the set of relocation parameters is based on minimizing a wait time of the user [note in the first 3 lines of [0070] that loitering in a certain vicinity is to ensure pickup by a prescribed time, which would minimize a wait time for the user; see also [0003]]. See the rejection of the independent claims for combining the cited art.
Claims 4 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Marco in view of Schwendimann, Kantarjiev, and Peng, as applied to claims 1 and 13 above, and further in view of Sumcad et al., US PGPUB 2005/0021225 Al (hereinafter as Sumcad).
Regarding claims 4 and 16, the rejections of independent claims 1 and 13 are respectively incorporated. The previously combined art does not explicitly teach that monitoring the one or more activities associated with the scheduled event includes monitoring a location of the user.
Sumcad teaches monitoring activities associated with a scheduled event that includes monitoring a location of a user [see e.g. col. 5, lines 1-7 indicating the use of the passenger location data as part of the data feed together with plane arrival, airport delays, baggage delivery locations, etc. for monitoring activities associated with the scheduled event of a plane’s arrival (related to a user’s pickup)].
It would have been obvious to one of ordinary skill in the art having the teachings of the previously combined art and Sumcad, before the effective filing date of the claimed invention, to modify the operations taught by Marco and modified by the combined art to explicitly specify that monitoring the one or more activities associated with the scheduled event includes monitoring a location of the user, as per the teachings of Sumcad. The motivation for this obvious combination would be to allow for better synchronization of passenger pickup via telematic routing services where coordination between passenger arrival and vehicle routing is needed, as taught by Sumcad [see e.g. col. 1, lines 41-49].
Claim 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Marco in view of Schwendimann, Kantarjiev, and Peng, as applied to claims 1 and 13 above, and further in view of Fox et al., US PGPUB 2021/0108932 Al (hereinafter as Fox).
Regarding claims 7 and 18, the rejections of independent claims 1 and 13 are respectively incorporated. The previously combined art does not explicitly teach that determining the set of relocation parameters is based on minimizing a downtime of the first service provider.
Fox teaches determining a set of relocation parameters that is based on minimizing a downtime a service provider [see e.g. [0032] indicating the relocation of a conveyance (service provider) when not is use to be more convenient; note in [0012]-[0013] the allocation of the conveyances such that downtime is minimized; see also [0015]].
It would have been obvious to one of ordinary skill in the art having the teachings of the previously combined art and Fox, before the effective filing date of the claimed invention, to modify the operations taught by Marco and modified by the combined art to explicitly specify that determining the set of relocation parameters is based on minimizing a downtime of the first service provider, as per the teachings of Fox. The motivation for this obvious combination would be to allow for a maximized utilization of service providers such that a fewer number may be used to provide timely service to users, as taught by Fox [again, see e.g. [0012]-[0013]].
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Marco in view of Schwendimann, Kantarjiev, and Peng, as applied to independent claim 10 above, and further in view of Wu, US PGPUB 2010/0293030 Al (hereinafter as Wu).
Regarding claim 11, the rejection of claim 10 above is incorporated.
As per the rejection of claim 10, Marco teaches implementing a queue matching process in the queue mode [again, see e.g. [0085] and note the placement of requests in a queue and consecutive pairing of drivers with passengers in the queue as they are expected to arrive at the event location].
Marco further teaches (i) selecting a set of service providers, and (ii) transmitting an invitation that identifies the upcoming scheduled event to the set of service providers [see e.g. [0067], lines 23-end indicating the selection of a plurality of drivers and notifying them of the request].
Marco, however, does not explicitly teach that implementing the queue matching process in the queue mode is by selecting a set of service providers that have a low queue priority position.
Wu teaches an implementation of a queue matching process by selecting a service provider that has a low queue priority position [note in [0030] the establishment of a database 101 storing a set of service providers with priority ranking; note the dispatching method of fig. 6 described in [0034] and note the selection of a provider according to a vehicle-requiring condition corresponding to a vehicle service request; note the case when the dispatching condition does not match the vehicle-requiring condition (NO for step 63), and another vehicle is selected to judge whether the condition is satisfied, i.e. the selected provider is not the one with the highest queue priority position].
It would have been obvious to one of ordinary skill in the art having the teachings of the previously combined art and Wu, before the effective filing date of the claimed invention, to modify the operations taught by Marco to explicitly specify implementing the queue matching process in the queue mode by selecting a set of service providers that have a low queue priority position and transmitting an invitation that identifies the upcoming scheduled event to the set of service providers, as per the combined teachings of Marco and Wu. The motivation for this obvious combination would be to enable proper matchings of a service provider/vehicle and the user/passenger, according to certain additional conditions, as suggested by Wu [again, see e.g. [0034]].
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Marco in view of Schwendimann, Kantarjiev, Peng, and Wu, as applied to claim 11 above, and further in view of AU 2015101687 A4 (hereinafter as Lai).
Regarding claim 12, the rejection of claims 11 above is incorporated.
The previously combined art does not explicitly teach that transmitting the invitation includes indicating, with the invitation to each service provider of the set of service providers, a number of service providers who are viewing the invitation.
Lai teaches indicating with an invitation a number of service providers who have viewed the invitation [see e.g. fig. 10 and the description on p. 31, lines 9-11].
It would have been obvious to one of ordinary skill in the art having the teachings of the previously combined art and Lai, before the effective filing date of the claimed invention, to modify the transmittal of the invitation to each service provider of the set taught by Marco by specifying that transmitting the invitation includes indicating, with the invitation to each service provider of the set of service providers, a number of service providers who are viewing the invitation, as per the teachings of Lai. The motivation for this obvious combination would be to allow for providing feedback, as suggested by Lai [again, see the description on p. 31, lines 9-11] that could be used to increase the awareness of the service provider of the provisioning level of service providers.
Response to Arguments
Applicant’s amendments in view of previously presented claim objections have been fully considered and are persuasive. Applicant, however, is referred to the newly presented claim objections.
Applicant’s arguments regarding the rejections of the claims under 35 U.S.C. § 101 have been fully considered but are not persuasive.
Applicant argues on pp. 10-11 of the Applicant’s response that the following additional elements improve the functioning of a computer:
predicting a provisioning level of service providers for the mass egress location during a period associated with the scheduled event;
based on the predicted provisioning level of service providers for the mass egress location, implementing a queue mode to manage a queue that identifies multiple service providers within one or more regions associated with the mass egress location, wherein when the queue mode is implemented, each of the multiple service providers is matched to a corresponding transport request based at least in part on a time when the service provider entered ….;
determining, by monitoring one or more third-party data sources, that an exception event has taken place, the exception event being determined to affect the scheduled transport service;
in response to determining that the exception event has taken place: (i) implementing a pre-match mode for the scheduled transport service, (ii)selecting a first service provider from the multiple service providers within one of the one or more regions associated with the mass egress location for the scheduled transport request, and (iii) determining a current location of the first service provider within the geofence based at least in part on location data received from a computing device of the first service provider;
detecting the first service provider being positioned at the intermediate
location in advance of the pickup time;
Examiner respectfully notes that the entirety of the above-indicated limitations merely recites additional mental steps including observations (determining, by monitoring one or more third-party data sources, that an exception event has taken place, the exception event being determined to affect the scheduled transport service, determining a current location of the first service provider, and detecting the first service provider being positioned at the intermediate location in advance of the pickup time), evaluations (predicting a provisioning level of service providers), and judgments (based on the predicted provisioning level of service providers for the mass egress location, implementing a queue mode to manage a queue that identifies multiple service providers within one or more regions associated with the mass egress location, wherein when the queue mode is implemented, each of the multiple service providers is matched to a corresponding transport request based at least in part on a time when the service provider entered and in response to determining that the exception event has taken place: (i) implementing a pre-match mode for the scheduled transport service, (ii)selecting a first service provider from the multiple service providers within one of the one or more regions associated with the mass egress location for the scheduled transport request), as also indicated in the updated full rejection, presented above. Examiner reminds Applicant that an improvement in the abstract idea itself cannot be an improvement in technology or a technical field.
Thus, Examiner respectfully reasserts the 35 U.S.C. § 101 rejections of the pending claims. Applicant is respectfully referred to the complete rejections reasserted and updated above for further details.
Applicant's prior art arguments have been fully considered but they are not persuasive.
Applicant argues on pp. 13-14 of Applicant’s response that Peng does not disclose implementing a pre-match mode for the scheduled transport request.
Examiner respectfully notes that the primary reference, Marco, teaches implementing a pre-match mode for a scheduled transport service in response to determining that a change in operations has taken place [note in fig. 6, steps 604 and 606 and the description in [0104]-[0107] the determination of a certain predicted provisioning level in 606 and the pairing of drivers with passengers in cases when driver demand does not exceed the driver supply; note that if the demand does not exceed the supply (i.e. the difference between the demand and the supply is less than or equal to zero), the pairing (or pre-matching) occurs; note also the option of assigning requests to drivers as in the last 3 lines of [0058] which is a form of pre-matching; see e.g. [0067] indicating the selection of a particular driver by the system to match a request]. The only aspect missing from Marco’s teaching for this limitation is that the change in operations is an exception event. Peng teaches an implementation of a pre-match mode (an assignment) that is in response to determining that an exception event has taken place [note e.g. in [0046] the driver/passenger assignment being implemented responsive to a pick-up request spike (which can be reasonably interpreted to be an occurrence of an exception for pick-up requests)]. It would have been obvious to one of ordinary skill in the art having the teachings of the Marco and Peng to explicitly specify applying the teachings of Peng of implementing a pre-match mode in response to determining a request spike to the exception of Marco of a change of an event ending time resulting in a spike of requests affecting scheduled transport services. The motivation for this obvious combination would be to simplify mitigating the anticipated supply shortage at the event location by keeping track of the amount of committed (assigned) drivers, as taught by Peng [see e.g. [0046]]. Examiner reminds Applicant that, during patent examination, the pending claims must be "given their broadest reasonable interpretation consistent with the specification." Phillips v. AWH Corp., 415 F.3d 1303, at 1316 (Fed. Cir. 2005). See also In re Hyatt, 211 F.3d 1367, 1372, 54 USPQ2d 1664, 1667 (Fed. Cir. 2000); although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).Examiner further reminds Applicant that one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Therefore, Examiner respectfully asserts that the combination of the cited art sufficiently teaches all the limitations recited in the independent claims and all the dependent claims, likewise, including but not limited to the limitation addressed explicitly in the Response to the Office Action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Examiner notes from the cited art:
US Patent No. 12,314,989, which teaches matching processes for transport service providers and requestors based on real-time information [see e.g. abstract].
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 MARIA S AYAD whose telephone number is (571)272-2743. The examiner can normally be reached Monday-Friday, 7:30 am - 4:30 pm. Alt, Friday, EST.
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, Adam Queler can be reached at (571) 272-4140. 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.
/MARIA S AYAD/Primary Examiner, Art Unit 2172