DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09/11/2025 has been entered.
Status of Claims
The following is a Non-Final Office Action in response to applicant’s request for continued examination (RCE) received on 09/11/2025.
Claim 1 is amended. Claims 5-7 are cancelled. Claims 1-4 are considered in this Office Action. Claims 1-4 are currently pending.
Response to Argument
Applicant’s amendment necessitated the new ground(s) of rejection set forth in this Office Action.
Applicant’s arguments with respect to the 35 U.S.C. §101 rejection to claims have been considered, but are not persuasive.
Applicant argues that the amended claims cannot be performed in the human mind the examiner previously asserted that the claims could be performed mentally or via generic business practices. Amended Claim 1 forecloses this: Verifying and transmitting driver identity and vehicle information to dependent passengers requires computer-based integration of identity verification databases and secure communication channels. This is not a mental process.
The examiner respectfully disagrees. The examiner notes that the claims are directed to scheduling rides between series of drivers and riders based on incentive and gradually increase the incentive to motivate a driver to claim a transport request/demand, which falls under an abstract idea of certain methods of organizing human activity and mental process. The examiner notes the claims recite an abstract idea by reciting concepts of commercial or legal interactions (including advertising, marketing or sales activities or behaviors, and business relations) and managing interactions between people, which falls into the “certain methods of organizing human activity” group within the enumerated groupings of abstract ideas.
The applicant argues that The Amended Claims Improve the Functioning of the Ride Assignment Platform The specification describes a hybrid push/pull rideshare platform with dedicated modules including a ride organizer module, passenger module, ride scheduling module, historical data module, and bonus escalation module. - The safety transmission step improves the technological field of ridesharing by ensuring dependent passengers are informed of and protected by verified driver details a solution to a problem arising only in computer-mediated ride platforms, not in human scheduling. - The bonus escalation module ensures that unclaimed rides are not left stranded, materially improving system reliability and efficiency over prior ridesharing systems. These are improvements in the technology of ridesharing platforms, not abstract business practices, consistent with DDR Holdings v. Hotels.com, 773 F.3d 1245 (Fed. Cir. 2014).
The examiner respectfully disagrees. The examiner notes that it is important to note that in order for a method claim to improve computer functionality, the broadest reasonable interpretation of the claim must be limited to computer implementation. That is, a claim whose entire scope can be performed mentally, cannot be said to improve computer technology. Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 120 USPQ2d 1473 (Fed. Cir. 2016) (a method of translating a logic circuit into a hardware component description of a logic circuit was found to be ineligible because the method did not employ a computer and a skilled artisan could perform all the steps mentally). Similarly, a claimed process covering embodiments that can be performed on a computer, as well as embodiments that can be practiced verbally or with a telephone, cannot improve computer technology. See RecogniCorp, LLC v. Nintendo Co., 855 F.3d 1322, 1328, 122 USPQ2d 1377, 1381 (Fed. Cir. 2017) (process for encoding/decoding facial data using image codes assigned to particular facial features held ineligible because the process did not require a computer).
The claims recite the following additional elements: processing system, ride organizer module, passenger module, wherein the ride series is presented in bulk to the drivers for simultaneous claiming and scheduling (amounts to displaying data which is extra-solution activity), transmitting verified driver identity and vehicle information to the dependent passenger and ride organizer prior to the ride to ensure passenger safety(amounts to extra-solution activity), using a bonus escalation module operatively coupled to the historical data module and by the ride scheduling module the personalized bonus is based on historical data stored in historical data module, and ride scheduling module. However, the additional elements fail to integrate the abstract idea into a practical application because they fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Furthermore, these claims as a whole have been fully considered, however they are directed to the use of generic computing elements (Applicant’s Specification figure 11 and [0063-0068]describe high level general purpose computer) to perform the abstract idea, which is not sufficient to amount to a practical application and is tantamount to simply saying “apply it” using a general purpose computer, which merely serves to tie the abstract idea to a particular technological environment (computer based operating environment) by using the computer as a tool to perform the abstract idea, which is not sufficient to amount to particular application.
Further examples that the courts have indicated may not be sufficient to show an improvement in computer-functionality: ii. Accelerating a process of analyzing audit log data when the increased speed comes solely from the capabilities of a general-purpose computer, FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016);iii. Mere automation of manual processes, such as using a generic computer to process an application for financing a purchase, Credit Acceptance Corp. v. Westlake Services, 859 F.3d 1044, 1055, 123 USPQ2d 1100, 1108-09 (Fed. Cir. 2017) or speeding up a loan-application process by enabling borrowers to avoid physically going to or calling each lender and filling out a loan application, LendingTree, LLC v. Zillow, Inc., 656 Fed. App'x 991, 996-97 (Fed. Cir. 2016) (non-precedential); vi. Instructions to display two sets of information on a computer display in a non-interfering manner, without any limitations specifying how to achieve the desired result, Interval Licensing LLC v. AOL, Inc., 896 F.3d 1335, 1344-45, 127 USPQ2d 1553, 1559-60 (Fed. Cir. 2018).
The Examiner emphasizes that merely using a general purpose computer to execute the communications processing activities, without more, does not improve the performance of a computer or any technology at all, but merely employs generic technology as a tool to perform the steps of the abstract idea, such that any improvement achieved by automating the processing of communications would come from the capabilities of a general-purpose computer, rather than the sequence of steps/activities recited in the method itself, which does not materially alter the patent eligibility of the claim. See Bancorp Servs., L.L.C. v. Sun Life Assurance Co. of Can. (U.S.), 687 F.3d 1266, 1278 (Fed. Cir. 2012) (“[T]he fact that the required calculations could be performed more efficiently via a computer does not materially alter the patent eligibility of the claimed subject matter.”) (cited in the Federal Circuit's FairWarning decision). Therefore, Applicant’s claims do not configure, reconfigure, manipulate, transform, or improve a computer, a database, or any technological components whatsoever, but instead utilize a general-purpose computer as a tool for gathering data, analyzing the data, and presenting the results of the analysis. Accordingly, Applicant’s claims have not been shown to be directed to any improvement in computer related technology, but instead merely utilize a general-purpose computer and known techniques in the art for performing the abstract idea, which individually and collectively lack any discernible nexus to a technological result or improvement related thereto.
Applicant argues that the ordered combination solves the specific technological problems of (1) protecting dependent passengers in a computer-mediated ride platform and (2) preventing unclaimed trips via automated escalation. Such an integrated architecture is not a conventional computer function and represents "significantly more" under Alice Step 2.
The examiner respectfully disagrees. The claims recite the following additional elements: processing system, ride organizer module, passenger module, wherein the ride series is presented in bulk to the drivers for simultaneous claiming and scheduling (amounts to displaying data which is extra-solution activity), transmitting verified driver identity and vehicle information to the dependent passenger and ride organizer prior to the ride to ensure passenger safety(amounts to extra-solution activity), using a bonus escalation module operatively coupled to the historical data module and by the ride scheduling module the personalized bonus is based on historical data stored in historical data module, and ride scheduling module. The claims as a whole have been considered, but merely serve to tie the invention to a particular operating environment (i.e., computer-based implementation), though at a very high level of generality and without imposing meaningful limitation on the scope of the claim. In addition, Applicant’s Specification (figure 11) describes generic off-the-shelf computer-based elements for implementing the claimed invention, and which does not amount to significantly more than the abstract idea, which is not enough to transform an abstract idea into eligible subject matter. Such generic, high-level, and nominal involvement of a computer or computer-based elements for carrying out the invention merely serves to tie the abstract idea to a particular technological environment, which is not enough to render the claims patent-eligible, as noted at pg. 74624 of Federal Register/Vol. 79, No. 241, citing Alice, which in turn cites Mayo. In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrates the abstract idea into a practical application. Their collective functions merely provide conventional computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that the ordered combination amounts to significantly more than the abstract idea itself.
Accordingly, the 35 U.S.C. rejection is maintained, and an updated the 35 U.S.C. §101 rejection will address applicant’s amendment.
Applicant’s arguments and amendments with respect to the 35 U.S.C. §103 rejection to claims have been considered, however they are primarily raised in light of applicant’s amendments. An updated the 35 U.S.C. §103 rejection will address applicant’s amendment.
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-4 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-patentable subject matter. The claims are directed to an abstract idea without significantly more.
Claims 1-4 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The eligibility analysis in support of these findings is provided below, in accordance with the “Patent Subject Matter Eligibility Guidance”.
With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106), it is first noted that the method (claims 1-4) is directed to an eligible category of subject matter (i.e., process, machine, and article of manufacture respectively). Thus, Step 1 is satisfied.
With respect to Step 2, and in particular Step 2A Prong One, it is next noted that the claims recite an abstract idea by reciting concepts of ride share agreement between a rider and a driver which is considered commercial or legal interactions (including advertising, marketing or sales activities or behaviors, and business relations) and managing interactions between people, which falls into the “certain methods of organizing human activity” group within the enumerated groupings of abstract ideas. The claims further fall under “mental process” grouping. The limitations reciting the abstract idea are highlighted in italics and the limitation directed to additional elements highlighted in bold, as set forth in exemplary claim 1, are: A method of providing a plurality of ride series to a driver comprising: in a processing system; identifying metrics of the plurality of ride series using a ride organizer module; and wherein the request for the plurality of ride series is from a passenger module, and wherein each of the plurality of ride series comprises a plurality of trips by a dependent passenger having common start points and destinations and includes an offered fare and wherein the dependent passenger is not a ride organizer; identifying a plurality of possible drivers that can provide service for the plurality ride series using a ride scheduling module; offering at least one ride of each of the plurality of ride series to the plurality of possible drivers using the ride scheduling module , wherein the ride series is presented in bulk to the drivers for simultaneous claiming and scheduling; assigning the at least one ride of one or more of the plurality of ride series to one driver of the plurality of possible drivers if the one driver claims the offered ride and accepts the offered fare using the ride scheduling module; transmitting verified driver identity and vehicle information to the dependent passenger and ride organizer prior to the ride to ensure passenger safety; automatically offering a personalized bonus to each of the plurality of drivers by the ride scheduling module to take at least one unclaimed ride of the plurality of ride series; wherein the personalized bonus is based on historical data stored in historical data module for each of the plurality of drivers, and the personalized bonus is different for each of the plurality of drivers for the at least one unclaimed ride, automatically escalating the personalized bonus in value using a bonus escalation module operatively coupled to the historical data module and by the ride scheduling module until the at least one unclaimed ride is claimed by any of the plurality of drivers.
With respect to Step 2A Prong Two, the judicial exception is not integrated into a practical application. The claims recite the following additional elements: processing system, ride organizer module, passenger module, wherein the ride series is presented in bulk to the drivers for simultaneous claiming and scheduling (amounts to displaying data which is extra-solution activity), transmitting verified driver identity and vehicle information to the dependent passenger and ride organizer prior to the ride to ensure passenger safety(amounts to extra-solution activity), using a bonus escalation module operatively coupled to the historical data module and by the ride scheduling module the personalized bonus is based on historical data stored in historical data module, and ride scheduling module. However, the additional elements fail to integrate the abstract idea into a practical application because they fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Furthermore, these claims as a whole have been fully considered, however they are directed to the use of generic computing elements (Applicant’s Specification figure 11 and [0063-0068]describe high level general purpose computer) to perform the abstract idea, which is not sufficient to amount to a practical application and is tantamount to simply saying “apply it” using a general purpose computer, which merely serves to tie the abstract idea to a particular technological environment (computer based operating environment) by using the computer as a tool to perform the abstract idea, which is not sufficient to amount to particular application.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
With respect to Step 2B of the eligibility inquiry, it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claims recite the following additional elements: processing system, ride organizer module, passenger module, wherein the ride series is presented in bulk to the drivers for simultaneous claiming and scheduling (amounts to displaying data which is extra-solution activity), transmitting verified driver identity and vehicle information to the dependent passenger and ride organizer prior to the ride to ensure passenger safety(amounts to extra-solution activity), using a bonus escalation module operatively coupled to the historical data module and by the ride scheduling module the personalized bonus is based on historical data stored in historical data module, and ride scheduling module. The claims as a whole have been considered, but merely serve to tie the invention to a particular operating environment (i.e., computer-based implementation), though at a very high level of generality and without imposing meaningful limitation on the scope of the claim. In addition, Applicant’s Specification (figure 11) describes generic off-the-shelf computer-based elements for implementing the claimed invention, and which does not amount to significantly more than the abstract idea, which is not enough to transform an abstract idea into eligible subject matter. Such generic, high-level, and nominal involvement of a computer or computer-based elements for carrying out the invention merely serves to tie the abstract idea to a particular technological environment, which is not enough to render the claims patent-eligible, as noted at pg. 74624 of Federal Register/Vol. 79, No. 241, citing Alice, which in turn cites Mayo.
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrates the abstract idea into a practical application. Their collective functions merely provide conventional computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that the ordered combination amounts to significantly more than the abstract idea itself.
The dependent claims have been fully considered as well, however, similar to the finding for claims above, these claims are similarly directed to the abstract idea of certain method of organizing human activity and a mental process, without integrating it into a practical application and with, at most, a general-purpose computer that serves to tie the idea to a particular technological environment, which does not add significantly more to the claims. The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to significantly more than the abstract idea.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over Narayan (US 2018/0211228 A1, hereinafter “Narayan”) in view Willner (US 2020/0160235 A1, hereinafter “Willner”) in view of Absher (US 2018/0025309 A1, hereinafter “Absher”) in view of Dicker (US 2017/0352125 A1, hereinafter “Dicker”) in view of RideShare Guy (NPL: “Understanding Lyft’s Driver Bonuses”, published 07/19/2018, hereinafter “Lyft”).
Narayan teaches:
A method of providing a plurality of ride series to a driver comprising: in a processing system; identifying metrics of the plurality of ride series using a ride organizer module; and wherein the request for the plurality of ride series is from a passenger module, and wherein each of the plurality of ride series comprises a plurality of trips by a dependent passenger having common start points and destinations and includes [...] and wherein the dependent passenger is not a ride organizer(figures 2-8 and [0023] describe processing system used by a user to request a ride for a third party, which is through a passenger module. The ride requestor may be considered to be the parent (ride organizer) while the third-party rider is a child (dependent). [0025] At step 115, the user inputs a pickup address and a pickup time for the third party's ride into the user device. At step 120, the user inputs a drop-off address and a drop-off time for the third party's ride into the user device. [0034] the user may be able to repeat particular ride requests (series of request) automatically on particular days, such that every Monday, Wednesday, and Friday, for example, the same ride will be requested and provided to the third party);
transmitting verified driver identity and vehicle information to the dependent passenger and ride organizer prior to the ride to ensure passenger safety ([0045] and figure 7 describe graphical user interface 700 may also include information about the driver's vehicle 720. The vehicle 720 may show an exact picture of the driver's vehicle or may show a car of a similar make, model, model year, and color. Graphical user interface 700 may further include textual information about vehicle 720 such as the make and model “Volkswagen Jetta” and include the driver's license information and state “CA 234LFTE” to ensure positive identification of the vehicle by the third party. Graphical user interface 700 may further identify the driver, Kimberlee, with textual information 730 indicating that she is certified and textual information 735 conveying the length of time she has been a rideshare service provider).
While Narayan describes in figures 2-8 and [0023] processing system used by a user to request a ride for a third party, which is through a passenger module. The ride requestor may be considered to be the parent (ride organizer) while the third-party rider is a child (dependent). [0025] At step 115, the user inputs a pickup address and a pickup time for the third party's ride into the user device. At step 120, the user inputs a drop-off address and a drop-off time for the third party's ride into the user device. [0034] the user may be able to repeat particular ride requests (series of request) automatically on particular days, such that every Monday, Wednesday, and Friday, for example, the same ride will be requested and provided to the third party, it does not explicitly teach the following, however, analogous art in the field of ride share, Willner teaches:
identifying metrics of the plurality of ride… and includes an offered fare (fig. 3a and par. [0017] describe trip information for both the driver and rider, wherein the ride metrics include originating location information, destination information, passenger/driver information and pricing information such as the price the rider is willing to pay. [0014] The driver trip information may include a driver destination location, a driver starting location and/or the number of passengers the driver may be able to accommodate. The driver price information may include an offer price that the driver is willing to drive passengers to the driver destination location or a price range that a driver may be willing to accept with respect to rider trip information);
identifying a plurality of possible drivers that can provide the rides service for the plurality of ride … using a ride scheduling module ([0018] processing of the information may also be performed so that it is in a format to be displayed. Also, travelers, or riders, may be provided via the rider devices with a list of drivers who are willing to accept less than retail price for private transfers in order to not travel back to their originating destination empty or travel to a schedule pick-up empty. [0015] the ride-matching module 24 may also enable negotiation between a rider device 16 and a driver device 14, such as when the rider destination location is between the driver starting location and the driver destination location. Fig. 2 describes plurality of modules);
offering at least one ride of each of the plurality of ride series to the plurality of possible drivers using the ride scheduling module ([0018] processing of the information may also be performed so that it is in a format to be displayed. Also, travelers, or riders, may be provided via the rider devices with a list of drivers who are willing to accept less than retail price for private transfers in order to not travel back to their originating destination empty or travel to a schedule pick-up empty. [0015] the ride-matching module 24 may also enable negotiation between a rider device 16 and a driver device 14, such as when the rider destination location is between the driver starting location and the driver destination location. [fig. 3b and par. [0019] describes offering the ride to a driver);
assigning the at least one ride of one or more of the plurality of ride series to one driver of the plurality if possible, drivers if the one driver claims the offered ride and accepts the offered fare using the ride scheduling module ([0019] and fig. 3b step 112 and 114 describe confirming by the driver the ride and removing the ride from the list and reserve the ride (assign))
[the negotiation of the incentive for the ride is repeated] until the at least one unclaimed plurality of ride is claimed by any of the plurality of drivers for the at least one unclaimed ride (fig. 3b step 118 adjusting price bid/bonus offered to the driver in order to negotiate, wherein if the negotiation is successful the ride gets reserved by driver as illustrated in steps 119, 112, 114, and 116. Par. [0024] the steps depicted in flowchart(s) shown in FIGS. 3a-3c may occur in a linear manner, the driver via driver device or the rider via rider device may participate in multiple ongoing negotiation).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the teaching of Narayan with Willner to include identifying metrics of the plurality of ride and includes an offered fare, identifying a plurality of possible drivers that can provide the rides service for the plurality of ride using a ride scheduling module, assigning the at least one ride of one or more of the plurality of ride series to one driver of the plurality if possible drivers if the one driver claims the offered ride and accepts the offered fare using the ride scheduling module, and the negotiation of the incentive for the ride is repeated until the at least one unclaimed plurality of ride is claimed by any of the plurality of drivers for the at least one unclaimed ride as part of the scheduling ride service system of Narayan, because it will provide an accurate and efficient matching model to find the best match between riders and drivers [0033].
While Narayan teaches figures 2-8 and [0023] describe processing system used by a user to request a ride for a third party, which is through a passenger module. The ride requestor may be considered to be the parent (ride organizer) while the third-party rider is a child (dependent). [0025] At step 115, the user inputs a pickup address and a pickup time for the third party's ride into the user device. At step 120, the user inputs a drop-off address and a drop-off time for the third party's ride into the user device. [0034] the user may be able to repeat particular ride requests (series of request) automatically on particular days, such that every Monday, Wednesday, and Friday, for example, the same ride will be requested and provided to the third party and Willner describes [0018] processing of the information may also be performed so that it is in a format to be displayed. Also, travelers, or riders, may be provided via the rider devices with a list of drivers who are willing to accept less than retail price for private transfers in order to not travel back to their originating destination empty or travel to a schedule pick-up empty. [0015] the ride-matching module 24 may also enable negotiation between a rider device 16 and a driver device 14, such as when the rider destination location is between the driver starting location and the driver destination location. [fig. 3b and par. [0019] describes offering the ride to a driver. Narayan and Willner do not explicitly teach the following, however, analogous art in the field of customer and service provider management systems, Absher teaches:
wherein the ride series is presented in bulk to the drivers for simultaneous claiming and scheduling ([0049] FIG. 3 shows an example user interface including an interactive shifter calendar 300. When a shifter 130 accesses the shift worker platform 400, the shifter calendar 300 may be one of a plurality of user interface views available to the shifter 130, e.g. on a display of a computing device associated with the shifter 130. The shifter calendar 300 allows the shifter 130 to easily see suitable shifts to work as well as schedule gaps where no suitable shifts are available. [0055] When the shifter 130 would like to work one of the available shifts 130, the shifter 130 may select the available shift 130 using, for example, a “select available shift” button of the plurality of buttons 330).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the teaching of Narayan and Willner with Absher to include wherein the ride series is presented in bulk to the drivers for simultaneous claiming and scheduling as part of the scheduling ride service system of Narayan, because it will provide flexibility in scheduling between job providers and service providers by providing accessibility to schedule within their needs [0005].
While Narayan describes in figures 2-8 and [0023] processing system used by a user to request a ride for a third party, which is through a passenger module. The ride requestor may be considered to be the parent (ride organizer) while the third-party rider is a child (dependent). [0025] At step 115, the user inputs a pickup address and a pickup time for the third party's ride into the user device. At step 120, the user inputs a drop-off address and a drop-off time for the third party's ride into the user device. [0034] the user may be able to repeat particular ride requests (series of request) automatically on particular days, such that every Monday, Wednesday, and Friday, for example, the same ride will be requested and provided to the third party, and Willner describes in fig. 3b step 118 adjusting price bid/bonus offered to the driver in order to negotiate, wherein if the negotiation is successful the ride gets reserved by driver as illustrated in steps 119, 112, 114, and 116. Par. [0024] the steps depicted in flowchart(s) shown in FIGS. 3a-3c may occur in a linear manner, the driver via driver device or the rider via rider device may participate in multiple ongoing negotiations, Narayan and Willner do not explicitly teach the following, however, analogous art in the field of ride share, Dicker, teaches:
automatically offering a personalized bonus to each of the plurality of drivers by the ride scheduling module to take at least one unclaimed ride of the ride series; wherein the personalized bonus is based on historical data stored in historical data module for each of the plurality of drivers, […]automatically escalating the personalized bonus in value using a bonus escalation module operatively coupled to the historical data module and by the ride scheduling module until the at least one unclaimed ride is claimed by any of the plurality of drivers (0039] The database 160 can store driver profiles 166 that can indicate the home locations of the drivers (e.g., the driver's address), preferred operating areas (e.g., either inputted by the driver or inferred by the network system 100 over time), the driver's service rating and/or safety rating, the driver's history of claiming and delivering on claimed rides (e.g., a failed claim rate), the driver's cancelation rate, and the like. Based on such profile information, the selection engine 135 can determine one or more drivers that would be optimally suited to claim the scheduled transport 142. the selection engine 135 can further include an incentive or bonus payment with the claim offer 186 to further incentivize the driver to claim the scheduled transport 142. In one example, the selection engine 135 can provide an initial claim offer 186, and gradually provide increased incentives until the scheduled transport 142 is claimed. [0049] the selection engine 135 can provide information 149 corresponding to the scheduled transport 142 to the pricing engine 165 prior to the scheduled transport time. Examiner notes: the incentive is gradually(automatically) increased and offered until the condition is met, which is when the unclaimed ride claimed).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the teaching of Narayan, Willner, and Absher with Dicker to include the personalized bonus is different for each of the plurality of drivers as part of the scheduling ride service system of Narayan, because it will provide an accurate and efficient matching model to find the best match between riders and drivers and provide personalized incentive catered towards each drivers’ attribute [0052].
While Narayan describes in figures 2-8 and [0023] processing system used by a user to request a ride for a third party, which is through a passenger module. The ride requestor may be considered to be the parent (ride organizer) while the third-party rider is a child (dependent). [0025] At step 115, the user inputs a pickup address and a pickup time for the third party's ride into the user device. At step 120, the user inputs a drop-off address and a drop-off time for the third party's ride into the user device. [0034] the user may be able to repeat particular ride requests (series of request) automatically on particular days, such that every Monday, Wednesday, and Friday, for example, the same ride will be requested and provided to the third party, and Willner describes in fig. 3b step 118 adjusting price bid/bonus offered to the driver in order to negotiate, wherein if the negotiation is successful the ride gets reserved by driver as illustrated in steps 119, 112, 114, and 116. Par. [0024] the steps depicted in flowchart(s) shown in FIGS. 3a-3c may occur in a linear manner, the driver via driver device or the rider via rider device may participate in multiple ongoing negotiations, Narayan and Willner do not explicitly teach the following, however, analogous art in the field of ride share, Lyft teaches:
and the personalized bonus is different for each of the plurality of drivers (figure 2 describes each driver has a different personalized bonus).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the teaching of Narayan, Willner, Absher, and Dicker with Lyft to include the personalized bonus is different for each of the plurality of drivers as part of the scheduling ride service system of Narayan, because it will provide an accurate and efficient matching model to find the best match between riders and drivers and provide personalized incentive catered towards each drivers’ attribute.
Claim 2
Narayan teaches:
The method of claim 1 wherein the metrics of the plurality of ride series include passenger, pickup location, destination, pickup time, and drop-off time ([0024] Once the user has requested a ride for a third party in step 105 of method 100, the user may then identify the third party to be picked up for the ride service at step 110. [0025] At step 115, the user inputs a pickup address and a pickup time for the third party's ride into the user device. At step 120, the user inputs a drop-off address and a drop-off time for the third party's ride into the user device. [0034] the user may be able to repeat particular ride requests (series of request) automatically on particular days, such that every Monday, Wednesday, and Friday, for example, the same ride will be requested and provided to the third party).
Claim 3
While Narayan teaches in [0024] once the user has requested a ride for a third party in step 105 of method 100, the user may then identify the third party to be picked up for the ride service at step 110. [0025] At step 115, the user inputs a pickup address and a pickup time for the third party's ride into the user device. At step 120, the user inputs a drop-off address and a drop-off time for the third party's ride into the user device. [0034] the user may be able to repeat particular ride requests (series of request) automatically on particular days, such that every Monday, Wednesday, and Friday, for example, the same ride will be requested and provided to the third party. Narayan does not explicitly teach the following, however Willner teaches:
The method of claim 1 wherein the metrics each of the plurality of ride series include an offered fare (fig. 3a and par. [0017] describe trip information for both the driver and rider, wherein the ride metrics include originating location information, destination information, passenger/driver information and pricing information such as the price the rider is willing to pay).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the teaching of Narayan, Absher, Dicker, and Lyft with Willner to include the metrics each of the plurality of ride series include an offered fare as part of the scheduling ride service system of Narayan, because it will provide an accurate and efficient matching model to find the best match between riders and drivers [0033].
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Narayan in view Willner in view of Absher in view of Dicker in view of Lyft, as applied in claim 1, and further in view of Rajaa Chraibi (US 2019/0019146 A1, hereinafter “Chraibi”).
Claim 4:
While Narayan teaches in [0024] once the user has requested a ride for a third party in step 105 of method 100, the user may then identify the third party to be picked up for the ride service at step 110. [0025] At step 115, the user inputs a pickup address and a pickup time for the third party's ride into the user device. At step 120, the user inputs a drop-off address and a drop-off time for the third party's ride into the user device. [0034] the user may be able to repeat particular ride requests (series of request) automatically on particular days, such that every Monday, Wednesday, and Friday, for example, the same ride will be requested and provided to the third party. Narayan does not explicitly teach the following, however analogous art Chraibi teaches:
The method of claim 1 further including offering a previously claimed ride to the driver (Fig. 3 steps 306-309 describes offering previously claimed ride to the driver).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the teaching of Narayan, Willner, Absher, Dicker, and Lyft with Chraibi to include offering a previously claimed ride to the driver as part of the scheduling ride service system of Narayan, because aid in helping riders with rejected or cancelled trips request find a new driver to fulfill their request [0088].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20170330111 A1
Systems and Methods for Managing Travel Options
Vogel; Henry et al.
US 20180108103 A1
Systems and Methods for Matching and Displaying Service Request and Available Vehicles
Li; Junqin et al.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to REHAM K ABOUZAHRA whose telephone number is (571)272-0419. The examiner can normally be reached M-F 7:00 AM to 5:00 PM.
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, Brian Epstein can be reached at (571)-270-5389. 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.
/REHAM K ABOUZAHRA/ Examiner, Art Unit 3625