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 .
Examiner notes that the fundamentals of the rejections are based on the broadest reasonable interpretation of the claim language. Any reference to specific figures, columns, lines and paragraphs should not be considered limiting in any way, the entire cited reference, as well as any secondary teaching reference(s), are considered to provide relevant disclosure relating to the claimed invention. Applicant is kindly invited to consider the reference as a whole. References are to be interpreted as by one of ordinary skill in the art rather than as by a novice. See MPEP 2141. Therefore, the relevant inquiry when interpreting a reference is not what the reference expressly discloses on its face but what the reference would teach or suggest to one of ordinary skill in the art.
Status of Claims
This is a Non-Final Office Action on the merits of Application No. 17/728,123, in response to Applicant’s amendments and remarks filed on 11/19/2025. The Applicant has amended claims 1, 13, and 19. No new claims have been added and no new matter has been introduced. Claims 1 – 4, 8 – 11, 13 – 17, and 19 are currently pending in the application and are addressed below.
Reply to Applicant’s Remarks
Claim Rejections Under 35 U.S.C. 103:
Applicant’s arguments (see Arguments/Remarks, filed 11/19/2025) with respect to the rejections of claims 1 – 4, 8 – 17, and 19 under 35 U.S.C. 103 have been fully considered but, respectfully, are not persuasive.
Regarding the Applicant’s arguments that, “Warmoth merely discloses that flight entries into an aerial transport facility may be allocated. In other words, Warmoth at most implies that the system may confirm the entry of an aircraft into the aerial transport facility.”, “Warmoth does not suggest, either explicitly or implicitly, any configuration in which a user's entry notification into a boarding or landing facility is detected or verified.”, “Warmoth also fails to disclose or render obvious any configuration in which service-use information is checked based on a user's entry notification.”, “Miller only discloses determining flight priorities based on business objectives, weather conditions, or providing flight options based on a user's route ranking preferences.”, and, “Miller does not disclose or suggest prioritizing a user themselves, nor does it is close using such user-related priority information to determine a new transfer point when negotiation for an intermediate stop fails.”, the Examiner respectfully disagrees.
Warmoth discloses checking the service use information of the traffic object that approaches a take-off and landing facility in response to receiving a notification of entry into the take-off and landing facility from the user terminal (see at least Warmoth, [¶0116, 0124, 0128 and Fig. 3, 9-11], “Flight trajectories into and out of the aerial transport facility 300 may be defined, configured, assigned, communicated, etc.”, “The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”, i.e., the system can receive notification from the service provider computing devices and/or rider computing device (user terminal) to confirm that the aerial vehicle approaches a take-off and landing facility).
Warmoth further discloses resetting, in response to receiving a failure of waypoint negotiation from the user terminal, the destination information of the at least one passenger based on a priority of the at least one passenger (see at least Warmoth, [¶0024, 0056, 0091 & 0119 and Fig. 2 & 4], “a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, waypoint negotiation and resetting the destination is part of creating and/or maintaining a multi-modal transportation itinerary based on user requests and priorities).
Miller, discloses receiving second route information including second destination information and second waypoint information of the at least one traffic object, set by the driver ; and
detecting a change in the first route information based on the second route information (see at least Miller [Col.8, ln.40-54, and Col.8, ln.59 – Col.9, ln.4], “the traveler 110 may also create a new route by entering a location pair and manually entering the route of the flight 166. New routes may then be stored as part of the user profile 250 []. Additionally, the traveler 110 may edit an existing route by selecting a route from the route list 164 or the saved route list 168 and changing portions of the selected route. Such route changes may also be stored in the user profile 250.”, “The plan operations feature 140 determines and ranks available routes based on preferences stored in the user profile 250, current operational parameters and current and forecast weather data. []. After the traveler 110 has logged on and entered a location pair, the traveler 110 may be requested to enter additional operational parameters of information, such as type of aircraft and departure time. The plan operations feature 140 accesses the user profile 250 from the personalization database 200 (through the access personal information feature 114) so that the traveler's preferences and tolerances may be considered when suggesting a route.”, the traveler’s choices, or user-related priority information, are considered when suggesting a route or route changes).
Therefore, the cited art combination of Warmoth and Miller discloses the claim limitations. See Claim Rejections - 35 USC § 103 below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 8-11, 13, 16-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US 20220067869 Warmoth et al. (Warmoth hereafter) in view of US 7546206 Miller et al. (Miller hereafter).
Regarding Claim 1, Warmoth discloses a method for providing a multimodal transport service in a multimodal transport system comprising at least one of at least one traffic object, a server apparatus, and a user terminal (see at least Warmoth, [¶0027 & Fig. 1], “[0027] The multi-modal transportation service can include a plurality of transportation legs, one of which (e.g., a second transportation leg) can include a transport of a rider through a medium or modality different from a ground vehicle. The transport, for example, can include an aerial transport, a water transport, a rail transport, or any other alternative means of transportation. For example, the computing system can obtain a request for a transportation service. The computing system can obtain the request from a rider device associated with the rider of the transportation platform. The rider device, for example, can include any type of computing device such as a smartphone, tablet, hand-held computing device, wearable computing device, embedded computing device, navigational computing device, etc.”), the method comprising:
checking first route information for the at least one traffic object, wherein the first route information, predetermined by a driver, includes first waypoint information and first destination information of the at least one traffic object (see at least Warmoth, [¶0024, 0056, 0091, 0119 and 0120, and Fig. 2 & 4], “[0024] Aspects of the present disclosure are directed to a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, A rider generating a service request for transportation from an origin location to a destination location corresponds to the predetermined route information, checking route information of the transport vehicle is part of creating and/or maintaining a multi-modal transportation itinerary for customers, and managing and/or coordinating a plurality of different types of vehicles to provide transport services);
checking destination information of at least one passenger (see at least Warmoth, [¶0032], “The computing system can obtain request data indicative of the request for the transportation service for the rider. The request data can include the quantity data, the attribute data, the origin location, the destination location, and/or any other characteristics specified by the rider for the request.”, that means checking passenger’s destination );
setting service use information based on the first route information for the at least one traffic object and the destination information of the at least one passenger (see at least Warmoth, [¶0124 & 0128 and Fig. 9-11], “The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”, i.e., the system sets the transportation service for the passenger using the route information for the vehicle);
checking the service use information of the traffic object that approaches a take-off and landing facility in response to receiving a notification of entry into the take-off and landing facility from the user terminal (see at least Warmoth, [¶0116, 0124, 0128 and Fig. 3, 9-11], “Flight trajectories into and out of the aerial transport facility 300 may be defined, configured, assigned, communicated, etc.”, “The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”, i.e., the system can receive notification from the service provider computing devices and/or rider computing device (user terminal) to confirm that the aerial vehicle approaches a take-off and landing facility); and
processing, based on the service use information, the at least one passenger's getting-in to the at least one traffic object (see at least Warmoth, [¶0084 & 0112], “[0084] Additionally, or alternatively, the object-check action can include preventing a vehicle from commencing a subsequent passenger loading process until all object(s) have been cleared out of the vehicle by riders or personnel associated with the second transportation facility (e.g., ramp staff, etc., that means the system checks passenger getting-in vehicle);
wherein detecting the change in the first route information comprises resetting a route by reflecting the second route information of the at least one traffic object (see at least Warmoth, [¶0019, 0121], “the service entity computing system 102 can match (e.g., via a matching and fulfillment system 132, etc.) the rider with a service provider for the transportation modality from a free-floating, dynamic pool of independent service providers. For example, service providers can dynamically opt in and out of the ride sharing network and the service entity computing system 102 can operate to match the passenger with a vehicle of a service provider who is currently opted into the network. The service provider can choose to provide the service to the passenger or decline to provide the service. For example, for alternative modalities such as by aerial vehicles, water-based vehicle, etc., the service entity computing system 102 can match the rider to one of a dynamically changing pool of vehicles (e.g., aerial vehicles, water vehicles, etc.) and the vehicles can choose (e.g., via one or more functional calls to the matching and fulfillment system 132) to provide or decline the proposed transportation service.”, the service operates in an “on-demand” nature and resetting a route by reflecting the changed destination or waypoint of the transport vehicle is part of the matching process);
wherein the method further comprises providing the service use information to a user (see at least Warmoth [¶0101], “the service entity computing system 102 can book or otherwise reserve a seat in, space on, or usage of one or more of the transportation modalities for the rider. Additionally, or alternatively, the service entity computing system 102 can simply provide information for options to be provided by one or more third parties for one or more of the transportation legs.”); and
wherein the at least one traffic object is controlled based on the service information (see at least Warmoth [¶0091, 0119], “The system 100 can include a service entity computing system 102 that can operate to control, route, monitor, and/or communicate with vehicles such as ground vehicles, aircraft (e.g., VTOL aircraft), etc. and/or one or more other transportation service entities (e.g., third-party vehicle providers) to facilitate a multi-modal transportation service. These operations can be performed as part of a multi-modal transportation service for passengers”, “in some implementations, vehicles (e.g., aerial vehicles, water vehicles, etc.) of a ride-sharing network can be scheduled and/or otherwise controlled by the service entity computing system 102 in accordance with the ride sharing network.”).
the method further comprising:
processing a waypoint negotiation between the destination information of the at least one passenger and the second route information the of the at least one traffic object after detecting the change in the first route information (see at least Warmoth, ¶0103, “A transportation platform, for example, can include cloud services system communicatively connected over a network to a plurality of riders (e.g., via one or more rider devices 140, etc.), a plurality service providers (e.g., via one or more service provider devices 150, 160, 170, etc.), etc. The transportation platform can be configured to leverage transportation capabilities of the plurality of service providers to schedule and facilitate a multi-modal transportation service for the plurality of riders (and/or one or more objects to accompany the riders). The service entity computing system 102 can be configured to coordinate multi-modal transportation for the transportation platform.”, waypoint or destination negotiation is part of coordinating transportation service.);
wherein the processing of the waypoint negotiation comprises:
providing a neighboring waypoint list to the user terminal based on a request from the user terminal (see at least Warmoth, [¶0024, 0056, 0091 & 0119 and Fig. 2 & 4], “a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, checking neighboring waypoints is part of creating and/or maintaining a multi-modal transportation itinerary based on user requests);
resetting the destination information of the at least one passenger based on receiving the neighboring waypoint list selected by the user terminal (see at least Warmoth, [¶0024, 0056, 0091 & 0119 and Fig. 2 & 4], “a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, resetting the destination is part of creating and/or maintaining a multi-modal transportation itinerary based on user requests); and
resetting, in response to receiving a failure of waypoint negotiation from the user terminal, the destination information of the at least one passenger based on a priority of the at least one passenger (see at least Warmoth, [¶0024, 0056, 0091 & 0119 and Fig. 2 & 4], “a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, waypoint negotiation and resetting the destination is part of creating and/or maintaining a multi-modal transportation itinerary based on user requests and priorities).
Warmoth does not explicitly disclose wherein the method further comprises:
receiving second route information including second destination information and second waypoint information of the at least one traffic object, set by the driver; and
detecting a change in the first route information based on the second route information;
However, Miller, directed towards a system and method for suggesting transportation routes, discloses receiving second route information including second destination information and second waypoint information of the at least one traffic object, set by the driver (see at least Miller [Col.8, ln.40-54], “the traveler 110 may also create a new route by entering a location pair and manually entering the route of the flight 166. New routes may then be stored as part of the user profile 250 []. Additionally, the traveler 110 may edit an existing route by selecting a route from the route list 164 or the saved route list 168 and changing portions of the selected route. Such route changes may also be stored in the user profile 250.”); and
detecting a change in the first route information based on the second route information (see at least Miller [Col.8, ln.59 – Col.9, ln.4], “The plan operations feature 140 determines and ranks available routes based on preferences stored in the user profile 250, current operational parameters and current and forecast weather data. []. After the traveler 110 has logged on and entered a location pair, the traveler 110 may be requested to enter additional operational parameters of information, such as type of aircraft and departure time. The plan operations feature 140 accesses the user profile 250 from the personalization database 200 (through the access personal information feature 114) so that the traveler's preferences and tolerances may be considered when suggesting a route.”);
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have considered the teachings of Miller to modify Warmoth, with a reasonable expectation of success, to use the technique of receiving second route information including second destination information and second waypoint information of the at least one traffic object, set by the driver, and detecting a change in the first route information based on the second route information, as taught by Miller, for the purpose of more effectively adjusting the navigation routes as needed and provide a more optimal transportation service to the users.
Regarding Claim 2, Warmoth and Miller, in combination, disclose The method of claim 1, Warmoth further discloses wherein the setting of the service use information comprises identifying the at least one passenger corresponding to the first waypoint information or the first destination information for the at least one traffic object (see at least Warmoth, [¶0124 & 0128 and Fig. 9-11], “[0128] The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”, that means identifying at least one passenger corresponding to waypoint or destination information for at least one transport vehicle or traffic object).
Regarding Claim 3, Warmoth and Miller, in combination, disclose The method of claim 1, Warmoth further discloses wherein the setting of the service use information comprises: providing a target passenger list, which includes the at least one passenger, to the at least one traffic object (see at least Warmoth, [¶0124 & 0128 and Fig. 9-11], “[0128] The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”, that means providing the matching rider or target passenger list to the matching transport vehicle); and
selecting the at least one passenger included in the target passenger list (see at least Warmoth, [¶0124 & 0128 and Fig. 9-11], “[0128] The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”, that means selecting a passenger from the target passenger list in order to match the passenger or rider to a service provider for transport service.).
Regarding Claim 4, Warmoth and Miller, in combination, disclose The method of claim 1, Warmoth further discloses wherein the service use information comprises at least one of traffic object information, information on a passenger's getting-in location, a getting- in time, information on a passenger's getting-off location, and a getting-off time (see at least Warmoth, [¶0120], “For example, the service entity computing system 102 can identify any transportation plans between one of the candidate departure facilities and/or one of the candidate arrival facilities which would satisfy the rider's request, including, for example, any departure or arrival time requests.” The information about candidate departure and/or arrival facilities and rider's departure or arrival time requests corresponds to traffic object information and information on a passenger's getting-in location, a getting-in time, information on a passenger's getting-off location, and a getting-off time).
Regarding Claim 8, Warmoth and Miller, in combination, disclose The method of claim 1, Warmoth further discloses further comprising determining whether or not the second destination information or the second waypoint information, which is included in the reset route, matches the destination information of the at least one passenger (see at least Warmoth, [¶0124 & 0128 and Fig. 9-11], “[0128] The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”, that means determining whether a destination matches the destination of the passenger is part of the transport service matching process).
Regarding Claim 9, Warmoth and Miller, in combination, disclose The method of claim 8, Warmoth further discloses further comprising controlling an operation of the at least one traffic object according to the reset route, as the second destination information or the second waypoint information, which is included in the reset route, matches the destination information of the at least one passenger (see at least Warmoth [¶0091, 0119], “The system 100 can include a service entity computing system 102 that can operate to control, route, monitor, and/or communicate with vehicles such as ground vehicles, aircraft (e.g., VTOL aircraft), etc. and/or one or more other transportation service entities (e.g., third-party vehicle providers) to facilitate a multi-modal transportation service. These operations can be performed as part of a multi-modal transportation service for passengers”, “in some implementations, vehicles (e.g., aerial vehicles, water vehicles, etc.) of a ride-sharing network can be scheduled and/or otherwise controlled by the service entity computing system 102 in accordance with the ride sharing network.”).
Regarding Claim 10, Warmoth and Miller, in combination, disclose The method of claim 9, Warmoth further discloses further comprising processing a waypoint negotiation between the destination information of the at least one passenger and the at least one traffic object, as the second destination information or the second waypoint information, which is included in the reset route, does not match the destination information of the at least one passenger (see at least Warmoth, ¶0103, “A transportation platform, for example, can include cloud services system communicatively connected over a network to a plurality of riders (e.g., via one or more rider devices 140, etc.), a plurality service providers (e.g., via one or more service provider devices 150, 160, 170, etc.), etc. The transportation platform can be configured to leverage transportation capabilities of the plurality of service providers to schedule and facilitate a multi-modal transportation service for the plurality of riders (and/or one or more objects to accompany the riders). The service entity computing system 102 can be configured to coordinate multi-modal transportation for the transportation platform.”, waypoint or destination negotiation is part of coordinating transportation service.).
Regarding Claim 11, Warmoth and Miller, in combination, disclose The method of claim 10, Warmoth further discloses wherein the processing of the waypoint negotiation between the destination information of the at least one passenger and the at least one traffic object comprises: providing a waypoint list, which is included in the reset route, to a user terminal of the passenger (see at least Warmoth, ¶0139, “Each of the devices (e.g., rider device, operator devices, and/or infrastructure devices) can be configured to display one or more user interfaces. Each participant of the multi-modal transportation itinerary can interact with the one or more user interfaces to communicate with the computing system 505. For instance, the participants can input object data 515, 520 to indicative of the number and/or attributes of one or more objects at one or more points along the multi-modal transportation itinerary. In this manner, the input data can include data received from: a rider device and input by the rider; a service provider device and input by a vehicle operator; or an infrastructure device and input by a greeter and/or any other facility personnel. The input data can be obtained at one or more times throughout a transportation service.”); and
resetting the destination information of the at least one passenger by selecting at least one waypoint included in the list (see at least Warmoth, (see at least Warmoth, [¶0024, 0056, 0091 & 0119 and Fig. 2 & 4], “[0024] Aspects of the present disclosure are directed to a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, Examiner interprets that resetting the destination of the passenger by selecting a waypoint is part of creating and/or maintaining a multi-modal transportation itinerary for customers, and managing and/or coordinating a plurality of different types of vehicles to provide transport services).
Regarding Claim 13, Warmoth and Miller, in combination, disclose The method of claim 10, Warmoth does not explicitly disclose, but Miller discloses wherein the processing of the waypoint negotiation between the destination information of the at least one passenger and the at least one traffic object comprises: determining a priority for the at least one traffic object or the priority of the at least one passenger (see at least Miller, col. 12 lines 37 – 50, “the traveler 110 may be presented with a list of ranking parameters or preferences that instruct the plan operations feature 140 how to suggest or list the possible routes applicable to the entered location pair. The traveler 110 may choose multiple ranking preferences, such that the available routes are weighted according to multiple factors, and be presented with a ranked list and/or ranking interface screen 150 (see FIG. 12). For example, in FIG. 12 the traveler 110 may be most interested in routes that have been cleared, while routes that are fastest or having low fuel economy are of lesser importance. Therefore, the operation planning engine 140 will rank routes, such that if a route has been cleared, it receives a relatively high weight factor compared to other available routes that have not been cleared.”, that means determining a priority (or weight) for the at least one traffic object or the priority of the at least one passenger by using a ranking system); and
determining the waypoint of the at least one traffic object by reflecting the priority (see at least Miller, col. 14, lines 41 – 52, “For example, a commercial airline dispatcher or planner may want to determine which flights are the highest priority out of a certain group of flights based on a number of different criteria, including, for example, business objectives and weather data. That is, for example, if a dispatcher is notified that there is a limited window of time to land inbound flights to a particular airport (e.g., because that airport will soon institute a ground stop), the personalized transportation information system 100, using the route ranking process described above, provides the dispatcher with a prioritized list of the flights that the dispatcher should attempt to land first based on the relevant applicable business criteria.” that means determining the waypoint of the transport vehicle by reflecting the priority).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have considered the teachings of Miller to modify Warmoth, with a reasonable expectation of success, to use the techniques of determining a priority for the at least one traffic object or the at least one passenger, and determining the waypoint of the at least one traffic object by reflecting the priority, as taught by Miller, for the purpose of more effectively adjusting the navigation routes as needed and provide a more optimal transportation service to the users.
Regarding Claim 16, Warmoth and Miller, in combination, disclose The method of claim 1, Warmoth further discloses further comprising checking a change of destination information for the at least one passenger (see at least Warmoth, ¶0032, “The computing system can obtain request data indicative of the request for the transportation service for the rider. The request data can include the quantity data, the attribute data, the origin location, the destination location, and/or any other characteristics specified by the rider for the request.”).
Regarding Claim 17, Warmoth and Miller, in combination, disclose The method of claim 16, Warmoth further discloses further comprising:
checking whether or not the changed destination information of the at least one passenger matches the first waypoint information or the first destination information for the at least one traffic object (see at least Warmoth, [¶0124 & 0128 and Fig. 9-11], “[0128] The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”, the matching and fulfillment system checks whether the changed destination of the passenger matches a waypoint or destination for the transport vehicle.);
resetting the first route information, when the changed destination information of the at least one passenger matches the first waypoint information or the first destination information for the at least one traffic object (see at least Warmoth, (see at least Warmoth, [¶0024, 0056, 0091 & 0119 and Fig. 2 & 4], “[0024] Aspects of the present disclosure are directed to a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, Examiner interprets that resetting route information is part of creating and/or maintaining a multi-modal transportation itinerary for customers, and managing and/or coordinating a plurality of different types of vehicles to provide transport services); and
processing a waypoint negotiation between the changed destination information of the at least one passenger and the first route information of the at least one traffic object, when the changed destination information of the at least one passenger does not match the first waypoint information or the first destination information for the at least one traffic object (see at least Warmoth, ¶0103, “A transportation platform, for example, can include cloud services system communicatively connected over a network to a plurality of riders (e.g., via one or more rider devices 140, etc.), a plurality service providers (e.g., via one or more service provider devices 150, 160, 170, etc.), etc. The transportation platform can be configured to leverage transportation capabilities of the plurality of service providers to schedule and facilitate a multi-modal transportation service for the plurality of riders (and/or one or more objects to accompany the riders). The service entity computing system 102 can be configured to coordinate multi-modal transportation for the transportation platform.”).
Regarding Claim 19, Warmoth discloses An at least one traffic object processing a multimodal transport service in a multimodal transport system, the traffic object comprising:
a communication unit (see at least Warmoth, [¶0091], “The system 100 can include a service entity computing system 102 that can operate to control, route, monitor, and/or communicate with vehicles such as ground vehicles, aircraft (e.g., VTOL aircraft), etc. and/or one or more other transportation service entities (e.g., third-party vehicle providers) to facilitate a multi-modal transportation service. These operations can be performed as part of a multi-modal transportation service for passengers, for example, including travel by ground vehicle and travel by alternative modalities such as aircraft (e.g., VTOL aircraft, etc.), watercraft (e.g., ferries, etc.), subway trains, etc.”);
at least one storage medium (see at least Warmoth, [¶0098], “The memory 114 can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, one or more memory devices, flash memory devices, etc., and combinations thereof.”); and
at least one processor (see at least Warmoth, [¶0098 & Fig. 5], “The service entity computing system 102 includes one or more processors 112 ”);
wherein the at least one processor is configured to:
check first route information of the at least one traffic object, wherein the first route information, predetermined by a driver, includes first waypoint information and first destination information of the at least one traffic object (see at least Warmoth, [¶0024, 0056, 0091, 0119 and 0120, and Fig. 2 & 4], “[0024] Aspects of the present disclosure are directed to a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, A rider generating a service request for transportation from an origin location to a destination location corresponds to the predetermined route information, checking route information of the transport vehicle is part of creating and/or maintaining a multi-modal transportation itinerary for customers, and managing and/or coordinating a plurality of different types of vehicles to provide transport services);
provide the route information to the transport management server (see at least Warmoth, [¶0124, 0134], “[0124] the service entity computing system 102 can include a number of subsystems configured to provide a plurality of backend services to facilitate a transportation service. By way of example, the optimization/planning system 130 can provide a backend itinerary service to generate one or more itineraries for a rider in accordance with the procedures described herein. In addition, the system 130 can provide a backend routing service to determine one or more flight plans, routes, skylanes, sea routes, etc. for vehicles associated with transportation service”, that means providing the route information to the transport management server to facilitate a transportation service);
receive a target passenger list including the at least one passenger from the transport management server (see at least Warmoth, [¶0024, 0029, 0103], “[0103] A transportation platform, for example, can include cloud services system communicatively connected over a network to a plurality of riders (e.g., via one or more rider devices 140, etc.), a plurality service providers (e.g., via one or more service provider devices 150, 160, 170, etc.), etc. The transportation platform can be configured to leverage transportation capabilities of the plurality of service providers to schedule and facilitate a multi-modal transportation service for the plurality of riders (and/or one or more objects to accompany the riders). The service entity computing system 102 can be configured to coordinate multi-modal transportation for the transportation platform.”);
select and provide the at least one passenger included in the target passenger list to the transport management server (see at least Warmoth, [¶0124 & 0128 and Fig. 9-11], “[0128] The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”. Selecting and providing passenger information and checking and providing service use information is part of the matching and fulfillment process.);
check service use information in response to receiving a notification of entry into the take-off and landing facility from the user terminal (see at least Warmoth, [¶0116, 0124, 0128 and Fig. 3, 9-11], “Flight trajectories into and out of the aerial transport facility 300 may be defined, configured, assigned, communicated, etc.”, “The matching and fulfillment system 132 can match a rider with a service provider and vehicle for each of the different transportation modalities. For example, each respective matching system 134 can communicate with the corresponding service provider computing devices 150, 160, 170 and/or rider computing device(s) 140 via one or more APIs or connections. Each matching system 134 can communicate trajectories and/or assignments to the corresponding rider, vehicles, service providers etc. Thus, the matching and fulfillment system 132 can perform or handle assignment of ground transportation, flight trajectories, waterway routes, take-off/landing, etc.”, i.e., the system can receive notification from the service provider computing devices and/or rider computing device (user terminal) to confirm that the aerial vehicle approaches a take-off and landing facility); and
provide the service use information to a user (see at least Warmoth [¶0101], “the service entity computing system 102 can book or otherwise reserve a seat in, space on, or usage of one or more of the transportation modalities for the rider. Additionally, or alternatively, the service entity computing system 102 can simply provide information for options to be provided by one or more third parties for one or more of the transportation legs.”); and
control the traffic object based on the service use information (see at least Warmoth [¶0091, 0119], “The system 100 can include a service entity computing system 102 that can operate to control, route, monitor, and/or communicate with vehicles such as ground vehicles, aircraft (e.g., VTOL aircraft), etc. and/or one or more other transportation service entities (e.g., third-party vehicle providers) to facilitate a multi-modal transportation service. These operations can be performed as part of a multi-modal transportation service for passengers”, “in some implementations, vehicles (e.g., aerial vehicles, water vehicles, etc.) of a ride-sharing network can be scheduled and/or otherwise controlled by the service entity computing system 102 in accordance with the ride sharing network.”);
wherein the at least one processor is further configured to:
process a waypoint negotiation between the destination information of the at least one passenger and the second route information the of the at least one traffic object after detecting the change in the first route information (see at least Warmoth, ¶0103, “A transportation platform, for example, can include cloud services system communicatively connected over a network to a plurality of riders (e.g., via one or more rider devices 140, etc.), a plurality service providers (e.g., via one or more service provider devices 150, 160, 170, etc.), etc. The transportation platform can be configured to leverage transportation capabilities of the plurality of service providers to schedule and facilitate a multi-modal transportation service for the plurality of riders (and/or one or more objects to accompany the riders). The service entity computing system 102 can be configured to coordinate multi-modal transportation for the transportation platform.”, waypoint or destination negotiation is part of coordinating transportation service.);
wherein the processing of the waypoint negotiation comprises:
providing a neighboring waypoint list to the user terminal based on a request from the user terminal (see at least Warmoth, [¶0024, 0056, 0091 & 0119 and Fig. 2 & 4], “a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, checking neighboring waypoints is part of creating and/or maintaining a multi-modal transportation itinerary based on user requests);
resetting the destination information of the at least one passenger based on receiving the neighboring waypoint list selected by the user terminal (see at least Warmoth, [¶0024, 0056, 0091 & 0119 and Fig. 2 & 4], “a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, resetting the destination is part of creating and/or maintaining a multi-modal transportation itinerary based on user requests); and
resetting, in response to receiving a failure of waypoint negotiation from the user terminal, the destination information of the at least one passenger based on a priority of the at least one passenger (see at least Warmoth, [¶0024, 0056, 0091 & 0119 and Fig. 2 & 4], “a computing system configured to create and/or maintain a multi-modal transportation itinerary responsive to a rider request for a multi-modal transportation service. For instance, a service entity can manage and/or coordinate a plurality of different types of vehicles to provide services to a plurality of riders via a transportation platform. By way of example, a rider may generate a service request for transportation from an origin location to a destination location.”, waypoint negotiation and resetting the destination is part of creating and/or maintaining a multi-modal transportation itinerary based on user requests and priorities).
Warmoth does not explicitly disclose the at least one processor is further configured to: transmit second route information including second destination information and second waypoint information of the at least one traffic object, set by the driver, to the transport management server; and receive a route, reset by reflecting the second route information of the at least one traffic object, wherein the route is reset, based the transport management server detecting a change in the first route information of the at least one traffic object based on the second route information.
However, Miller discloses the at least one processor is further configured to: transmit second route information including second destination information and second waypoint information of the at least one traffic object, set by the driver, to the transport management server (see at least Miller [Col.8, ln.59 – Col.9, ln.4], “The plan operations feature 140 determines and ranks available routes based on preferences stored in the user profile 250, current operational parameters and current and forecast weather data. []. After the traveler 110 has logged on and entered a location pair, the traveler 110 may be requested to enter additional operational parameters of information, such as type of aircraft and departure time. The plan operations feature 140 accesses the user profile 250 from the personalization database 200 (through the access personal information feature 114) so that the traveler's preferences and tolerances may be considered when suggesting a route.”); and
receive a route, reset by reflecting the second route information of the at least one traffic object (see at least Miller [Col.8, ln.59 – Col.9, ln.4]),
wherein the route is reset, based the transport management server detecting a change in the first route information of the at least one traffic object based on the second route information (see at least Miller [Col.8, ln.59 – Col.9, ln.4]).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have considered the teachings of Miller to modify Warmoth, with a reasonable expectation of success, to use the techniques of transmit second route information including second destination information and second waypoint information of the at least one traffic object, set by the driver, to the transport management server; and receive a route, reset by reflecting the second route information of the at least one traffic object, wherein the route is reset, based the transport management server detecting a change in the first route information of the at least one traffic object based on the second route information, as taught by Miller, for the purpose of more effectively adjusting the navigation routes as needed and provide a more optimal transportation service to the users.
Claims 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Warmoth and Miller, in combination, as applied to Claim 13 above, and further in view of US 20210150424 Ha et al. (Ha hereafter).
Regarding Claim 14, Warmoth and Miller, in combination, disclose The method of claim 13, Warmoth and Miller, in combination, do not explicitly disclose further comprising managing a mileage for the at least one traffic object and a mileage for the at least one passenger.
However, Ha, directed to method and apparatus for managing a moving object for fleet system, discloses further comprising managing a mileage for the at least one traffic object and a mileage for the at least one passenger (see at least Ha [¶0088, 0102], “a fleet system may manage mileage information of a user. Herein, the mileage information may be a value given based on the user's usage of a moving object. Thus, a fleet system may give the user priority or penalty”; “As another example, when it is not possible for a user to use a designated departure or destination spot that is initially intended, a fleet system may provide the user with mileage by considering a distance between a recommend designated spot and a designated departure or destination spot. For example, as a distance increases between a user's intended designated departure or destination spot and a recommend designated spot, a fleet system may provide the user more mileage.”, that means managing the passenger’s and transport vehicle’s mileage information to assign priority.).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have considered the teachings of Ha to modify Warmoth and Miller, in combination, with a reasonable expectation of success, to use the technique of managing a mileage for the at least one traffic object and a mileage for the at least one passenger for the purpose of assigning priority, as taught by Ha, for the purpose of more effectively adjusting the navigation routes as needed and provide a more optimal transportation service to the users.
Regarding Claim 15, Warmoth, Miller and Ha, in combination, disclose The method of claim 14, Ha further discloses wherein the determining of the priority comprises: checking the mileage for the at least one traffic object and the mileage for the at least passenger (see at least Ha [¶0088, 0102], “a fleet system may manage mileage information of a user. Herein, the mileage information may be a value given based on the user's usage of a moving object. Thus, a fleet system may give the user priority or penalty”; “As another example, when it is not possible for a user to use a designated departure or destination spot that is initially intended, a fleet system may provide the user with mileage by considering a distance between a recommend designated spot and a designated departure or destination spot. For example, as a distance increases between a user's intended designated departure or destination spot and a recommend designated spot, a fleet system may provide the user more mileage.”, that means checking the passenger’s and transport vehicle’s mileage information to assign priority); and
determining a higher priority for either of the traffic object and the passenger, of which the mileage is relatively higher (see at least Ha [¶0088, and 0102])
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have considered the teachings of Ha to modify Warmoth and Miller, in combination,, with a reasonable expectation of success, to use the technique of checking the mileage for the at least one traffic object and the mileage for the at least passenger and determining a higher priority for either of the traffic object and the passenger, of which the mileage is relatively higher, as taught by Ha, for the purpose of more effectively adjusting the navigation routes as needed and provide a more optimal transportation service to the users.
Conclusion
Examiner encourages Applicant to fill out and submit form PTO-SB-439 to allow internet communications in accordance with 37 CFR 1.33 (MPEP 502.03). Should the need arise to perfect applicant-proposed or examiner’s amendments, authorization for e-mail correspondence would have already been authorized and would save time.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Neit J. Nieves Flores whose telephone number is (703)756-5864. The examiner can normally be reached M-F 0930-1800 AST.
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, Rachid Bendidi can be reached at (571) 272-4896. 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.
/Neit J. Nieves Flores/
Patent Examiner
Art Unit 3664
/RACHID BENDIDI/Supervisory Patent Examiner, Art Unit 3664