DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 12/1/2025, by way of RCE on 12/23/25, has been entered.
Notice to Applicant
The following is a Non-Final Office action. In response to Examiner’s Final Rejection of 10/2/25, Applicant, on 12/1/25, amended claims. Claims 1-6 and 10 are pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
The 112 rejection is withdrawn in light of claim 11 being cancelled.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/24/25 is in compliance with the provisions of 37 CFR 1.97.
Reasons for Subject Matter Eligibility under 35 USC 101
The claim 1 overcomes the 101 rejections because the claim is now : performing by the management server, a first matching suitability between the operating vehicle and the passenger based on the driving information including current location information of an operating vehicle and the passenger information including departure and destination information and using a passenger matching condition and a reference value set in the management server, then performing a final matching determination by the driver terminal based on the driving information and the passenger information using a passenger matching condition selected by a driver and a reference value set by the driver in the driver terminal independently from the management server. When viewing the claim as a whole, this when combined with the earlier limitations is viewed as a practical application under step 2a, prong 2, as the claim is improving another technology when viewing all the limitations listed above (See MPEP 2106.05a – e.g. Enfish; “improvements to computer functionality” – see vii. vii. Particular structure of a server that stores organized digital images, TLI Communications, 823 F.3d at 612; DDR Holdings; Applicant’s Remarks 8/13/25 pages 19-20 (showing Applicant’s FIG. 3, and explanation), pages 25-27) and/or is viewed as a using a judicial exception in a meaningful way under MPEP 2106.05(e), as it requires a particular arrangement for when processing is conducted on a local driver terminal in combination with when processing is conducted on a server. The same reasons also apply to independent claim 4, which has similar limitations.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-6 and 10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The structure of the claim is not supported by the disclosure as originally filed. The beginning of claim 1 is “receiving, by a management server, driving information including current location information of an operating vehicle and arrival point information of the operating vehicle, from a driver terminal” which refers to the embodiment of the “arrival point” being [0041] as published “the arrival point of the operating vehicle 10-1 may be a returning place of the driver who finished the day's operation or a garage where the driver has to return the operating vehicle 10-1, and in this case, the present disclosure may be the allocation management method for a returning vehicle.” and [0043] as published “the management server 200 receives, from the driver terminal 300, driving information including current location information of the operating vehicle 10-1 and arrival point information of the operating vehicle 10-1”. The claim now is amended to recite aspects from a second embodiment - “determining, by the management server, that the operating vehicle is more suitable than a standing-by vehicle for matching with the passenger in response to predicting that the operating vehicle, after passing through the arrival point, will arrive at a departure point of the passenger earlier than the standing-by vehicle.” This existing portions of the claim refer to a first embodiment, where “arrival point” refers to a destination of a [first] passenger that is currently in the car– [0042] as published “ Also, in implementing the present disclosure, the arrival point of the operating vehicle 10-1 may be a destination of a passenger riding in the operating vehicle 10-1”; [0077] as published “management server 200 receives the driving information including the current location information of the operating vehicle 10-1 and the arrival point information of the operating vehicle 10-1, from the operating driver terminal 300-1 that is a terminal possessed by the driver driving the operating vehicle 10-1 that is a vehicle being driven to the arrival point with a passenger (operation S510)”; [0080] as published “determining unit 250 of the management server 200 determines and compares matching suitability between the operating vehicle 10-1 and the passenger and matching suitability between the standing-by vehicle 10-2 and the passenger” and [0081] as published “the determining unit 250 of the management server 200 calculates each of an estimated travel time T1 from the current location 1 of the operating vehicle 10-1 to the arrival point 2 of the operating vehicle 10-1 and an estimated travel time T2 from the arrival point 2 of the operating vehicle 10-1 to the departure point 3 of the passenger, and then calculates a final arrival estimated required time T1+T2 of the operating vehicle 10-1 to the departure point of the passenger.” See FIG. 5-6.
PNG
media_image1.png
596
774
media_image1.png
Greyscale
PNG
media_image2.png
460
574
media_image2.png
Greyscale
The driver/operating vehicle in the above embodiment is NOT taking a passenger to the provider’s garage or end location, as in the earlier part of the claim, or as used in claim 2 [represented by FIG. 4 and [0054] as published]. See below
PNG
media_image3.png
428
584
media_image3.png
Greyscale
As best understood, for purposes of applying prior art only, Examiner interprets claim 1 as reciting: “determining, by the management server, that the operating vehicle is more suitable than a standing-by vehicle for matching with [[the]] a second passenger in response to predicting that the operating vehicle, after passing through the destination information of the passenger, will arrive at a departure point of the second passenger earlier than the standing-by vehicle.”
Claim 4 recites similar limitations and is rejected for the same reasons.
Claims 2-3, 5-6, and 10 depend from claim 1, 4 and are rejected for the same reasons.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-6 and 10 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are: it is unclear if in new step (d) if “determining, by the management server, that the operating vehicle is more suitable than a standing-by-vehicle for matching with the passenger” is referring to the “first matching suitability determination”; whether this has any impact on the later “final matching suitability determination” in step (f). As best understood, based on Applicant pointing to [0081-0083] as published in the Remarks, it appears this limitation is referring to a different passenger and [0077] also explaining that operating vehicle 10-1 is a “vehicle being driven to the arrival point with a passenger (operation S510). For purposes of applying prior art only, Examiner interprets claim 1 as reciting “determining, by the management server, that the operating vehicle is more suitable than a standing-by vehicle and [[for]] matching with [[the]] a second passenger to the operating vehicle in response to predicting that the operating vehicle, after passing through the destination information of the passenger, will arrive at a departure point of the second passenger earlier than the standing-by vehicle” ; and Examiner suggests adding a limitation that “operating vehicle is matched”, see e.g. [0086] as published. There may be other ways to phrase this, Examiner has attempted to clarify this above.
Claim 4 recites similar limitations and is rejected for the same reasons.
Claims 2-3, 5-6, and 10 depend from claim 1, 4 and are rejected for the same reasons.
Dependent Claims 2-3, 5-6 have additional issues stemming from the new amendments, depending on how claims 1, 4 are amended. For example, Claim 2 introduces “a departure point of the passenger” and “a destination of the passenger.” It is now unclear which passenger is being referred to.
Claim 2, 5 recites the limitation "an arrival point of the operating vehicle". There is insufficient antecedent basis for this limitation in the claim, as claim 1 also recites “an arrival point of the operating vehicle.” Examiner suggests, as in claim 1, clarifying whether this is referring “garage or final destination of driver of the operating vehicle.”
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claim(s) 1, 4, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Kuncl (US 2018/0330621) in view of Tang (US 2016/0182312).
Concerning claim 1, Kuncl discloses:
An allocation management method for a vehicle being driven to an arrival point (Kuncl – See par 31-32 - the network computer system 100 may also optimize the selection of service providers individually, so as to maximize the objective of individual service providers (e.g., increased amount of service provided, minimize downtime, etc.); “service providers” of service vehicles for service requests of transport-related services; See par 56 - system 200 includes a profile component 270 to continuously develop profile information about service providers. The profile information 275 may be specific to geolocation, to identify, for example, preferred locations where the service provider pauses or ends a shift.), the allocation management method comprising:
(a) receiving, by a management server (Kuncl – see par 21 - FIG. 1 illustrates a network computer system to manage the positioning of service vehicles in a geographic region. A network computer system 100 such as shown by FIG. 1 can be implemented in a variety of computing environments, including as part of a network service provided through one or more servers; see par 32 - a service arrangement system 200 (FIG. 2) may be implemented as a network service, using, for example, a network computer system 100 such as described with an example of FIG. 1.), driving information including current location information of an operating vehicle (Kuncl – see par 23 - The estimated quantity of service providers may be determined from the historical trip data 124 for the geographic region, and a current or recent location of individual service providers. see par 36 - provider device 202 may repeatedly or continuously communicate service information 203 to the system 200. The service information 203 may include the provider's identifier 205, and the provider's current location 207, which may be determined by the service application interfacing with a GPS component of the provider device 202.) and arrival point information of the operating vehicle, from a driver terminal (Applicant’s [0041] as published gives example – “the arrival point of the operating vehicle 10-1 may be a returning place of the driver who finished the day's operation or a garage where the driver has to return the operating vehicle 10-1, and in this case, the present disclosure may be the allocation management method for a returning vehicle.”
Kuncl discloses the limitations based on broadest reasonable interpretation in light of the specification – See par 56 - system 200 includes a profile component 270 to continuously develop profile information about service providers. The profile information 275 may be specific to geolocation, to identify, for example, preferred locations (describing an “arrival point”) where the service provider pauses or ends a shift. see par 71 - the system 200 may determine a preference or propensity for the service provider to stop service (e.g., go off duty) at a particular time. For example, the service provider may have a preference to stop service at a particular location (describing an “arrival point”) and time for a personal appointment. The system 200 can learn the propensity of the service provider, and then plan the location bias for the service provider so that the service provider is near the stopping location at the particular time);
(b) receiving, by the management server, passenger information including departure point information and first destination information of a passenger, from a passenger terminal (Kuncl – see par 34, FIG. 2 - system 200 to establish communication channels with individual devices of requesters; The requesters may also operate mobile devices (represented in FIG. 2 by the requester device 204) on which a corresponding service application 218 runs. The requesters may operate respective service applications 218 to request transport-related services, such as human transport between a start location (or pickup location) (describing a “departure point”) and a destination (or drop-off) (describing “destination information”).); and
(c) performing, by the management server, a first matching suitability determination of the operating vehicle and the passenger, based on the driving information and the passenger information, using at least one passenger matching condition set in a management server and at least one reference value set in the management server (Applicant’s [0068 as published] state : “even when the matching suitability determination performed by the determining unit 250 of the management server 200 has passed according to information about a passenger matching condition and reference values set by a manager, the driver may finally perform the matching suitability determination additionally according to the information about the passenger matching condition and reference values personally set according to his/her tendency and situation as described above.
Kuncl discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 40 - In one implementation, the matching component 240 references the service location(s) 209 of an incoming service request 201 with the current location of available service providers, as provided by the service data store 230. In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel).
See also Tang – see par 26 - the network node 315 selects which of the contractors 325 will provide the service to the user 310, defines the terms of the service agreement, and then confirms the service agreement with the selected contractor 325 and user 310. For example, the network node 315 may filter the contractors 325 based on their real-time locations (e.g., proximity to the user 310, etc.) or some other criteria, and then present the remaining subset of contractors with the opportunity to fulfill the service request under pre-defined terms).
(d) determining, by the management server, that the operating vehicle is more suitable than a standing-by vehicle for matching with the passenger in response to predicting that the operating vehicle, after passing through the arrival point, will arrive at a departure point of the passenger earlier than the standing-by vehicle (As stated in 112a and 112b rejections above, based on [0077, 0081-0083], FIGS. 5-6, Examiner interprets claim 1 as reciting “determining, by the management server, that the operating vehicle is more suitable than a standing-by vehicle and [[for]] matching with [[the]] a second passenger to the operating vehicle in response to predicting that the operating vehicle, after passing through the destination information of the passenger, will arrive at a departure point of the second passenger earlier than the standing-by vehicle”
Kuncl discloses the limitations as best understood – see par 33 - the service application 216 can automate operations which include indicating the availability of the service provider to provide service, communicate location information to enable the system 200 to monitor the location of the service provider's vehicle, receive information from the system 200 for facilitating the service provider in receiving service requests and fulfilling a service request, and communicate information to the system 200 for various purposes, including provisioning determination. see par 37 - For each service provider, the provider device interface 210 extracts the current location 207 and stores the current location with the provider's identifier 205 in the service data store 230; see par 41 - a service state of the service provider can be changed from available to unavailable, or from available to on-route to service start location. In the latter example, the service state may change again once service is initiated for the requester; see par 54 - The communication 263 may recommend a specific subregion where the service provider can position his or her service vehicle (when waiting for a next assignment) to reduce the service provider wait time. see par 61 - The location bias 285 for each target area may be associated with the service provider in the service data store 230 at selective time intervals that precede the target time interval by a duration predicted for matching the service provider to a suitable request and to have the service provider fulfill the service request (e.g., time for service provider to pickup and drop-off requester); see par 65 - Without consideration of location bias, the matching component 240 can match the service provider to individual service requests based primarily on a proximity of the current location 207 of the service provider's vehicle, and the service start location specified by a newly received service request.
Tang discloses the limitations as best understood –see par 23 - In some embodiments, the referrals may be sent to the candidate devices 210-213 without filtering the candidate devices 210-213 based on their real time locations. see par 26 - FIG. 3 illustrates a conventional architecture 300 for brokering peer-to-peer service agreements; the conventional architecture 300 comprises a user 310, a network node 315, a central server 320, and contractors 325; the network node 315 may filter the contractors 325 based on their real-time locations (e.g., proximity to the user 310, etc.) or some other criteria; The network node 315 may then arrange for one of the responding contractors (e.g., the first to respond, etc.) to fulfill the service request in accordance with the brokered service agreement);
(e) transmitting, by the management server, the passenger information to the driver terminal (Kuncl – see par 39 - The requester device interface 220 can parse individual service requests 201 to determine one or more service locations 209 of the service request, including the service start location and/or the service destination location. see par 40 - the matching component 240 references the service location(s) 209 of an incoming service request 201 with the current location of available service providers, as provided by the service data store 230. In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel). From the queried result set, the matching component 240 makes a selection of a service provider for the service request 201. The service provider may receive the matched service request as an invitation);
(f) performing, by the driver terminal, a final matching suitability determination of the operating vehicle and the passenger based on the driving information and the passenger information (Applicant’s [0063-0064] further state : “Information about the passenger matching condition and a reference value personally set by the driver.” Applicant’s [0054] as published states “shown in FIG. 4… an estimated travel time t3 from the destination 4 of the passenger to an arrival point 2 of the operating vehicle 10-1, determine whether a difference value between a total estimated travel time (t1+t2+t3) obtained by adding the same and an estimated travel time T1 from the current location 1 of the operating vehicle 10-1 to the arrival point 2 of the operating vehicle 10-1 is less than a predetermined first reference value α (for example, 10 minutes),”… then “the passenger is suitable” – see Equation 1; [0062] as published states “In addition, in implementing the present disclosure, the driver may personally set a passenger matching condition as described above, via the operating driver terminal 300-1. In detail, the driver may select one or at least two equations to be necessarily satisfied from among three equations above, such that matching with the passenger is determined to be suitable, according to his/er tendency and situation.”; see [0057-0058] as published – Equation 2 -a case where Equation 2 is satisfied is a case where the time t1 taken for the driver to deviate from an original moving path ((1).fwdarw.(2)) and arrive at the departure point 3 of the passenger so as to take the passenger is less than the predetermined second reference value β, for example, 3 minutes, and the determining unit 250 of the management server 200 determines that the matching between the operating vehicle 10-1 and the passenger is suitable; [0059] as published – Equation 3 - the determining unit 250 of the management server 200 may determine that the matching between the operating vehicle 10-1 and the passenger is suitable when a distance D from the destination 4 of the passenger to the arrival point 2 of the operating vehicle 10-1 is less than a predetermined third reference value γ, for example, 2 km (i.e., when Equation 3 is satisfied). In light of 112 rejections and the various paragraphs, for purposes of applying prior art only, Examiner interprets the limitations as including the scope of two of the three equations, where one condition could be “time” from Equation 1 or 2; or “distance” deviating from Equation 3.
Kuncl discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 13 - positioning operations can be selected to maximize an objective of the service provider (e.g., maximize service time), while facilitating the service provider in arriving at a stopping location identified by the provider's profile at an appropriate time. see par 40 - the matching component 240 references the service location(s) 209 of an incoming service request 201 with the current location of available service providers. In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel); see par 44 - the system 200 may perform positioning operations for individual service provider considerations, in order to meet a preference of the service provider as to locality where the service provider performs services (e.g., service provider has affinity or need to be positioned in subregion near particular location, etc.), or to further an objective of the individual service provider with respect to the quantity or duration of service time the service provider will provide in a given shift.), using at least one passenger matching condition selected by a driver corresponding to the driver terminal and at least one reference value set by the driver, the at least one passenger matching condition being selected and the at least one reference value being set … (Kuncl see par 56 – system has preferred locations where service provider ends a shift; see par 57 - The calendar data set may identify appointments or other events which are likely to signify stop or pause locations of the provider. The profile component 270 may update the profile information 275 of each active service provider, based on … retrieving calendar or other relative data set to determine the location preferences or likely service stops of the service provider. see par 59 - In some examples, as the time of the likely service stop nears, location bias 285 may be implemented as a band that is separated from the stopping location by a distance that is approximately the same as an expected trip distance for an expected service request that can be matched to the service provider prior to the stopping time; See par 61 - satisfy one or more preferences of the service provider (e.g., service provider prefers to be located at a particular subregion during a portion of their respective shift). see par 71 – service provider may have a preference to stop service at a particular location and time for a personal appointment (disclosing a condition, that considers driving information of a driver, and passenger information – distance/location and time).
Kuncl discloses that the driver terminal is used for gathering updated preferences/objectives of a provider, such as appointments or other events, to aid in matching (see par 44, 56-57, 59, 61, 71).
Tang discloses that the driver device itself can perform the matching.
(f) performing, “by the driver terminal,” a final matching suitability determination of the operating vehicle and the passenger based on the driving information and the passenger information, using at least one passenger matching condition selected by a driver corresponding to the driver terminal and at least one reference value set by the driver, the at least one passenger matching condition being selected and the at least one reference value being “set in the driver terminal, independently from the management server” (Tang – see par 2 – ride-sharing agreements between passengers and drivers; Upon receiving the ride-request, the network server distributes a fare offer to candidate drivers based on their real-time locations, and brokers a ride-sharing agreement between the passenger and a selected one of the candidate drivers; see par 24, FIG. 2 - filtering may be autonomously performed by the candidate devices 210-213 upon receiving the referrals. In this example, the candidate device 213 may autonomously ignore the referral because the requesting mobile device 205 is located more than a threshold distance from the candidate device 213. There may be other reasons for autonomously ignoring the referral, e.g., the candidate device 213 is turned off, the candidate device 213 is configured to ignore referrals outside a pre-defined time-window, etc. see par 25 – responses may propose… time/day to provide the service, e.g. fair, rate)).
Kuncl and Tang disclose:
(g) transmitting, by the driver terminal, a request for allocation of the passenger to the operating vehicle (Kuncl – see par 33 - In some examples, the service providers operate mobile devices (represented in FIG. 2 by the mobile device 202) on which a corresponding service application 216 runs. Among other functionality, the service application 216 can automate operations which include indicating the availability of the service provider to provide service, … receive information from the system 200 for facilitating the service provider in receiving service requests and fulfilling a service request, and communicate information to the system 200 for various purposes, including provisioning determination; see par 38 - The service data store 230 may also associate a service state with each provider. Initially, when the service provider goes on duty, the service provider may be associated with an available state. See par 40 - From the queried result set, the matching component 240 makes a selection of a service provider for the service request 201. The service provider may receive the matched service request as an invitation, or the matched service request may be communicated as an automatic assignment. See par 41 - For example, the current trip for the service provider may complete, or the system 200 may detect when the service vehicle is nearing the destination, such that the service provider can be marked available for assignment to a new service request); see par 59 - The planning logic 280 may repeatedly determine and store the location bias 285 with the current location 207 of the provider in the service data store 230. The location bias 285 may influence the service requests which the particular service provider is matched with.
See also Tang – see par 29, FIG. 6 - As shown, the method 600 begins at step 610, where the candidate device receives a referral from a network node. The referral indicates that a service has been requested by a requesting device. Subsequently, the method 600 proceeds to step 620, where the candidate device determines whether to autonomously ignore the referral. In some embodiments, the candidate device may autonomously ignore the referral when a criteria is satisfied (e.g., proximity of candidate device to requesting device exceeds threshold, etc.). see par 30 - if the candidate device decides not to autonomously ignore the referral, then the method 600 proceeds to step 640, where the candidate device prompts the user to respond to the referral).
Both Kuncl and Tang are analogous art as they are directed to forming agreements between two people - assigning drivers/providers for transport/vehicle requests (see Kuncl Abstract; Tang par 2, 18). Kuncl discloses that the driver terminal is used for gathering updated preferences/objectives of a provider, such as appointments or other events, to aid in matching (see par 44, 56-57, 59, 61, 71) and that it checks for matches based on a threshold distance or time of travel (See par 40). Tang improves upon Kuncl by disclosing filtering contractors based on real-time locations or other criteria (See Tang par 26), and having the driver terminal itself perform matching with regards to “threshold” distance or “pre-defined” time windows for facilitating peer-to-peer service agreements (See Tang par 24-25) and also noting the conventional feature of having a network node filter contractors (e.g. drivers) based on real-time locations and proximity to user, where those “first to respond” chosen to fulfill a service request. One of ordinary skill in the art would be motivated to further include doing a first filter based on locations or criteria and having a driver device itself conduct some portion of matching, as well as just matching with whichever driver can pickup the passenger first, to efficiently improve upon computing devices performing various examples for ride matching in Kuncl (See par 16) and the preferred locations and times of a driver/provider being considered in Kuncl (See par 56-57, 59, 61, 71).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to supplement the consideration of stopping location and stopping time for which requests to be matched with in Kuncl to further include service a provider device itself performing matching determination based on location thresholds or pre-defined time windows as disclosed in Tang, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning independent claim 4, Kuncl discloses:
A management server (Kuncl – see par 21 - FIG. 1 illustrates a network computer system to manage the positioning of service vehicles in a geographic region. A network computer system 100 such as shown by FIG. 1 can be implemented in a variety of computing environments, including as part of a network service provided through one or more servers; see par 32 - a service arrangement system 200 (FIG. 2) may be implemented as a network service, using, for example, a network computer system 100 such as described with an example of FIG. 1) comprising:
a management server (Kuncl – see par 75-76 – computer system 400 (which can implement computing system 100), includes one or more processors);
a driver terminal (Kuncl – see par 33 - service providers operate mobile devices (represented in FIG. 2 by the mobile device 202) on which a corresponding service application 216 runs),
wherein the management server comprises:
a processor (Kuncl – see par 75-76 – computer system 400 (which can implement computing system 100), includes one or more processors));
a receiving unit, executed by the processor, configured to receive, from a driver terminal, driving information including current location information of an operating vehicle (Kuncl – see par 23 - The estimated quantity of service providers may be determined from the historical trip data 124 for the geographic region, and a current or recent location of individual service providers. see par 36 - provider device 202 may repeatedly or continuously communicate service information 203 to the system 200. The service information 203 may include the provider's identifier 205, and the provider's current location 207, which may be determined by the service application interfacing with a GPS component of the provider device 202.) and arrival point information of the operating vehicle Applicant’s [0041] as published gives example – “the arrival point of the operating vehicle 10-1 may be a returning place of the driver who finished the day's operation or a garage where the driver has to return the operating vehicle 10-1, and in this case, the present disclosure may be the allocation management method for a returning vehicle.”
Kuncl describes the limitations based on broadest reasonable interpretation in light of the specification – See par 56 - system 200 includes a profile component 270 to continuously develop profile information about service providers. The profile information 275 may be specific to geolocation, to identify, for example, preferred locations (describing an “arrival point”) where the service provider pauses or ends a shift. see par 71 - the system 200 may determine a preference or propensity for the service provider to stop service (e.g., go off duty) at a particular time. For example, the service provider may have a preference to stop service at a particular location (describing an “arrival point”) and time for a personal appointment. The system 200 can learn the propensity of the service provider, and then plan the location bias for the service provider so that the service provider is near the stopping location at the particular time), and receive, from a passenger terminal, passenger information including departure point information and destination information of a passenger (Kuncl – see par 34, FIG. 2 - system 200 to establish communication channels with individual devices of requesters; The requesters may also operate mobile devices (represented in FIG. 2 by the requester device 204) on which a corresponding service application 218 runs. The requesters may operate respective service applications 218 to request transport-related services, such as human transport between a start location (or pickup location) (describing a “departure point”) and a destination (or drop-off) (describing “destination information”).); and
a determining unit, executed by the processor, configured to perform a first matching suitability determination of the operating vehicle and the passenger based on the driving information and the passenger information, using at least one passenger matching condition selected by a manager and at least one reference value set by the manager (Kuncl – [same as claim 1] - see par 40 - In one implementation, the matching component 240 references the service location(s) 209 of an incoming service request 201 with the current location of available service providers, as provided by the service data store 230. In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel;
See also Tang – see par 26 - he network node 315 selects which of the contractors 325 will provide the service to the user 310, defines the terms of the service agreement, and then confirms the service agreement with the selected contractor 325 and user 310. For example, the network node 315 may filter the contractors 325 based on their real-time locations (e.g., proximity to the user 310, etc.) or some other criteria, and then present the remaining subset of contractors with the opportunity to fulfill the service request under pre-defined terms).
The remaining limitations are the same as claim 1 and are rejected for the same reasons.
It would be obvious to combine Kuncl and Tang for the same reasons as claim 1.
Concerning claim 10, Kuncl disclose:
A non-transitory recording medium having recorded thereon a program for executing the method according to claim 1. (Kuncl – see par 19 - one or more examples described may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium.)
Claim(s) 2-3 and 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Kuncl (US 2018/0330621) in view of Tang (US 2016/0182312), as applied to claims 1, 4, and 10-11 above, and further in view of Wang (US 2017/0220966).
Concerning claims 2 and 5, Kuncl discloses:
The allocation management method of claim 1, wherein the (c) performing comprises (c1)
determining, by the management server, a total estimated travel time (Appears to be referring to addition of t1+t2+t3 in specification page 10 and equation) obtained by (Kuncl – see par 59 - The location bias 285 may reflect an area or band about the assumed (or likely) stopping location of the provider, where the separation distance of the location bias 285 from the stopping location is based on travel time for the provider's vehicle to travel to the stopping point in a given time period set by the likely stopping time. In some examples, as the time of the likely service stop nears, the location bias 285 may be implemented as a band that is separated from the stopping location by a distance that is approximately the same as an expected trip distance for an expected service request that can be matched to the service provider prior to the stopping time. see par 62 - The service plan 282 may then define location bias 285 for the provider, based on inputs such as the current location of the provider, the preferences of the service provider, and the service provider's objective (e.g., eliminate downtime or maximize earnings)).
adding an estimated travel time from a current location to the operating vehicle to a departure point of the passenger (in one example, this is departure point 3 in Applicant’s FIG. 4, page 10 of spec, and time “t1”) (Kuncl – see par 45 - provisioning level may reflect a comparative measure of service providers and requesters; the determination of the provisioning level can be represented by the wait time for a requester to be provided a service vehicle after making a request (“requester wait time”)),
adding an estimated travel time from the departure point of the passenger to a destination of the passenger (“destination” is point 4 in Applicant’s FIG. 4, page 10 of spec, and this is time “t2”) (Kuncl – see par 61 - The location bias 285 for each target area may be associated with the service provider in the service data store 230 at selective time intervals that precede the target time interval by a duration predicted for matching the service provider to a suitable request and to have the service provider fulfill the service request (e.g., time for service provider to pickup and drop-off requester)), and
adding an estimated travel time from the destination of the passenger to an arrival point of the operating vehicle (“arrival point” is point 2 in Applicant’s FIG. 4, page 10 of spec, and this is time “t3”) (Kuncl – see par 60 - planning logic 280 may predict (e.g., using historical trip data store) that a given service provider can, when positioned in a more distance subregion (target subregion) relative to the stopping location as compared to a current subregion, be matched to a single service request that can place the service provider adjacent to a likely stopping location prior to the expected stopping time. The planner 280 may then implement a service plan 282 to position the service provider after fulfillment of service requests along a path (pickup then dropoff; disclosing locations 3 and 4 in Applicant’s FIG. 4) that will position the service provider in the target subregion, with adequate time to match the service provider to a service request that that will position the service provider near the likely stopping location, before the expected stopping time)).
Kuncl discloses that the provider should be separated from the “stopping location” (corresponding to Applicant’s Arrival Location 2) that is “approximately the same” as an expected trip distance for expected service request (See par 59), where a provider can have a “likely” stopping time, and a provider can also have an objective of “maximize earnings” (See par 62). Tang discloses having a response related to an offer including a time to provide the service (See par 25).
Wang discloses:
determining a difference between the total estimated travel time and an estimated travel time from the current location of the operating vehicle to the arrival point of the operating vehicle is less than a predetermined reference value (current location is point 1; “arrival point” is point 4 in Applicant’s FIG. 4, page 10 of spec, and this is time “T1”; this is the same as “total estimated travel time” at beginning of this claim; the difference appears to be equation 1 on page 10 – comparing (t1+t2+t3) to T1 being less than “reference value alpha”) Wang discloses the limitations as best understood – see par 186 - In comparing the service provider's preset time limitations with the estimated travel time of the customer's service request, which includes the entire time the service provider will be underway from traveling to the pickup location to the drop off location to the preset return location; if applicable; if the estimated travel time will be beyond the service provider's time limitations (disclosing that the difference between time to go home and time to make this trip is too large, disclosing comparing different to a reference value) —making the service provider unable to get to where he or she needs to be by a certain time—the service provider will be deemed incompatible).
It would be obvious to combine Kuncl and Tang for the same reasons as claim 1. In addition, Kuncl, Tang, and Wang are analogous art as they are directed to ride request data processing (See Kuncl Abstract; Tang par 2, 18; Wang Abstract) and in addition both Kuncl and Wang are directed to assigning drivers/providers for transport/vehicle requests (see Kuncl Abstract; Wang par 59). Kuncl discloses that the provider should be separated from the “stopping location” (corresponding to Applicant’s Arrival Location 2) that is “approximately the same” as an expected trip distance for expected service request (See par 59), where a provider can have a “likely” stopping time, and a provider can also have an objective of “maximize earnings” (See par 62). Klein discloses estimating arrival times generally (See par 28). Wang improves upon Kuncl and Tang by disclosing that it checks whether the provider is incompatible by seeing whether provider can get to where he or she needs to by a certain time by seeing the estimated travel time for the request, relative to the provider’s time limitations (See par 186). One of ordinary skill in the art would be motivated to further include estimated travel time for a request being compared to where provider needs to be by a certain time for determining whether the driver/provider is compatible for a request to improve upon the preferred locations of where a service provider ends a shift that also considers a stopping time (see Kuncl par 56, 59).
Concerning claims 3 and 6, Kuncl and Wang disclose:
The allocation management method of claim 2, wherein the (c) performing further comprises (c2) determining, by the management server, whether the estimated travel time from the current location of the operating vehicle to the departure point of the passenger is less than a predetermined reference value (Kuncl – see par 40 - n one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel). see par 45 - the determination of the provisioning level can be represented by … (ii) the wait time for a requester to be provided a service vehicle after making a request (“requester wait time”)).
Response to Arguments
Applicant's arguments filed 12/1/25 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
With regards to 103, Applicant argues that the new limitations, supported in [0081-0083] and FIG. 5, overcomes the prior art because Kuncl does not disclose “operating vehicles and standing-by vehicles” nor “when an operating vehicle would be more suitable for matching than a standing-by vehicle.” Remarks, pages 9-11. In response, Examiner respectfully disagrees. New citations to the prior art address the arguments as best understood in light of 112 issues. Applicant’s argument that the claim “distinguishes” operating vehicles from standing-by vehicles from Kuncl is not persuasive. First, the claim gives no explanation as to what is required by a “standing-by vehicle.” Second, Kuncl discloses multiple vehicles (see par 37 – “service data store 230 maintains the current location 207 of each active service provider at a particular moment. By way of example, each service provider may start a shift by operating the service application 216 (e.g., opening the application on the provider's device 202), and then toggling a state feature provided by the service application 216 to ‘on duty’. … For each service provider, the provider device interface 210 extracts the current location 207 and stores the current location with the provider's identifier 205 in the service data store 230.” par 38 – “when the service provider goes on duty, the service provider may be associated with an available state”; par 40 – “matching component 240 references the service location(s) 209 of an incoming service request 201 with the current location of available service providers, as provided by the service data store 230. In one example, that matching component 240 queries the service data store 230 for service providers that are within a first threshold distance (alternatively, within a threshold time of travel).”). The remaining arguments are moot over the new rejections necessitated by the amendments.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
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, Anita Coupe can be reached at 571-270-3614. 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.
/IVAN R GOLDBERG/Primary Examiner, Art Unit 3619