DETAILED ACTION
This communication is a Non-Final Office Action rejection on the merits. Claims 1, 3-8, 12, and 14-15 are currently pending and have been addressed below.
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 10/27/2025 has been entered.
Response to Arguments
Applicant's arguments filed on 10/27/2025 (related to the 101 Rejection) have been fully considered but they are not persuasive.
Applicant states, on pages 7-11, that by utilizing the stop position of the delivery vehicle to create and output a route to travel for a delivery destination, the present invention improves delivery efficiency. As noted in the present specification, conventional methods merely set the delivery destinations themselves as transit points and create a route capable of efficiently traveling through these transit points, but do not create a route in which the stop position of the delivery vehicle is taken into account. By creating and outputting a route that travels through a transit point that is determined based on a stop position in which a walking time is shortest, the present invention creates a more efficient delivery route creation system. Thus, the present invention integrates the alleged judicial exception into a practical application of creating and outputting a delivery route in which a stop position is taken into account.
Examiner respectfully disagrees with Applicant. Claim 1 is considered to be an abstract idea because the claim limitations are directed to “mathematical concepts” which include “mathematical calculations.” Those limitations fall within the enumerated sub-grouping of mathematical calculations because they involve using optimization methods to determine a transit point for the delivery destination based on a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in each of the one or more deliveries made to the delivery destination (see Applicant’s specification, Paragraph 0030, determine optimum stop position as the transit point; see MPEP 2106.04(a)(2), determine optimal number of visits). If a claim limitation, under its broadest reasonable interpretation, covers mathematical calculations, then it falls within the “mathematical concepts” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The main functions recited in claim 1 are merely used to: collect data (e.g. acquire a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination in the past by one or more delivery persons); analyze the data (e.g. determine a transit point for the delivery destination, which is the stop position with the shortest walking time in the past); and display certain results of the collection and analysis (e.g. output the route to travel through the transit point for the delivery destination). Those are functions that the courts have described as merely indicating a field of use or technological environment in which to apply a judicial exception (see MPEP 2106.05(h)).
Also, although claim 1 further recites “outputting a route that travels through a transit point that is determined based on a stop position in which a walking time is shortest”, Examiner notes that “outputting information to a user” is merely necessary data gathering and outputting (see MPEP 2106.05).
Lastly, the claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. Thus, the claim is not patent eligible.
Independent claim 6 recites similar features and therefore is rejected for the same reasons as independent claim 1. Claims 3-5, 7-8, 12, and 14-15 are rejected for having the same deficiencies as those set forth with respect to the claims that they depend from, independent claims 1 and 6.
Applicant's arguments filed on 10/27/2025 (related to the 103 Rejection) have been fully considered but they are not persuasive.
Applicant states, on pages 12-16, that the combination of the teachings of Meister and Cajias does not disclose or suggest all the features of amended independent claims 1 and 6, and claims 1 and 6 are patentably distinguished over the references relied upon.
Examiner respectfully disagrees with Applicant. Meister discloses using both a walking travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in another delivery in the past (Paragraph 0053, trajectory data associated with journeys of vehicles; Paragraph 0067, moving trajectory data of the delivery person). Further, Meister discloses deriving, for each of the one or more delivery destinations, a stop position of the delivery vehicle in each of the one or more deliveries based on a walking time and/or distance (Paragraph 0067, determine the shortest/faster/easiest possible route that visits each delivery location and returns to the parking location based a cost function such as walking distance and/or time). In this case, Examiner notes that the walking distance and/or time is the same as the difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle.
Although Meister discloses to determine a stop position in a delivery based on walking distance and/or time of the delivery person (e.g., a stop position in a delivery in which the walking time is shortest among the one or more deliveries made to the delivery destination), Meister does not specifically disclose how the walking time is calculated (e.g., wherein the walking time of a delivery person in each of one or more deliveries based on a difference).
However, Cajias discloses walking time of the delivery person in each of one or more deliveries based on the difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in each of the one or more deliveries made to the delivery destination in the past (Paragraph 0060, In various embodiments, the navigation client 103 may be onboard a vehicle to report a destination location and its corresponding parked location. For instance, the navigation client 103 (comprising the GPS sensors) may report the user entered destination, as the route destination location and a last location of the vehicle before the navigation client 103 was turned-off, as the parked location or the parking spot for the destination location. In some embodiments, the navigation client 103 may determine a walking route between the parked location and the destination location. The navigation client 103 may report, using the walking route, the walking distance between the parked location and the destination location and/or the walking time to reach the destination location from the parked location). In this case, Examiner notes that the calculated walking time is based on the difference between the delivery destination location time and the parked location time. Therefore, Cajias improves upon Meister by further specifying other known techniques to calculate the walking time and/or distance (e.g., by calculating a difference between the destination and the stopping location and/or using a user equipment to report walking time to reach the destination from a stop location), wherein the multiple techniques achieve the same result (e.g., walking time between stop location and delivery location).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-8, 12, and 14-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without reciting significantly more.
Independent Claim 1
Step One - First, pursuant to step 1 in the January 2019 Revised Patent Subject Matter Eligibility Guidance (“2019 PEG”) on 84 Fed. Reg. 53, the claim 1 is directed to an apparatus which is a statutory category.
Step 2A, Prong One - Claim 1 recites: An information processing configured to determine a transit point of a route for delivering a package to one or more delivery destinations, the information processing configured to: acquire, for each of the one or more delivery destinations, a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination in the past by one or more delivery person, the travel trajectory of the delivery person including walking, derive, for each of the one or more delivery destinations, a stop position of the delivery vehicle in each of the one or more deliveries based on a difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in the each of the one or more deliveries made to the delivery destination in the past, derive, for each of the one or more delivery destinations, walking time of the delivery person in each of one or more deliveries based on the difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in each of the one or more deliveries made to the delivery destination in the past, determine, for each of the one or more delivery destinations, a stop position in a delivery in which the walking time is shortest among the one or more deliveries made to the delivery destination in the past, as a transit point for the delivery destination, and create and output the route to travel through the transit point for the delivery destination. Claim 1 is considered to be an abstract idea because the claim limitations are directed to “mathematical concepts” which include “mathematical calculations.” Those limitations fall within the enumerated sub-grouping of mathematical calculations because they involve using optimization methods to determine a transit point for the delivery destination based on a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in each of the one or more deliveries made to the delivery destination (see Applicant’s specification, Paragraph 0030, determine optimum stop position as the transit point; see MPEP 2106.04(a)(2), determine optimal number of visits). If a claim limitation, under its broadest reasonable interpretation, covers mathematical calculations, then it falls within the “mathematical concepts” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2 - The judicial exception is not integrated into a practical application. Claim 1 includes additional elements: an information processing device; and a processor.
The information processing device is merely used to process information (Paragraph 0019). The processor is merely used to: acquire a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination by one or more delivery persons (Paragraph 0021); and determine, for each delivery destination, a transit point for this delivery destination based on the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in each of one or more deliveries made to this delivery destination. For example, as described in detail below, the transit point determination section 130 derives, for each delivery destination, an optimal stop position among the stop positions of the delivery vehicle in the deliveries made to this delivery destination in the past, and determines this optimum stop position as the transit point for this delivery destination (Paragraph 0025). Merely stating that the step is performed by a computer component results in “apply it” on a computer (MPEP 2106.05f). These elements of “information processing device” and “processor” are recited at a high level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer element. Also, the processor is considered “insignificant extra-solution activity” since is just “mere data gathering” to use it for an analysis (MPEP 2106.05g). Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to an abstract idea.
Step 2B - The claim does not include additional elements that are sufficient to amount significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the claim describes how to generally “apply” the concept of determining a transit point for the delivery destination based on a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in each of one or more deliveries made to the delivery destination (e.g., shortest walking time and/or distance). The specification shows that the information processing device is merely used to process information (Paragraph 0019). The processor is merely used to: acquire a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination by one or more delivery persons (Paragraph 0021); and determine, for each delivery destination, a transit point for this delivery destination based on the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in each of one or more deliveries made to this delivery destination. For example, as described in detail below, the transit point determination section 130 derives, for each delivery destination, an optimal stop position among the stop positions of the delivery vehicle in the deliveries made to this delivery destination in the past, and determines this optimum stop position as the transit point for this delivery destination (Paragraph 0025). Also, the processor is considered a conventional computer function of “receiving or transmitting data over a network” (MPEP 2106.05d). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Independent claim 6 is directed to a method at step 1, which is a statutory category. Claim 6 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one; step 2a, prong 2; and step 2b. Claim 13 further recites “computer” – which is treated as just an explicit “processor/computer” for executing the operations and is treated under MPEP 2106.05f in the same manner as claim 1. Accordingly, this additional element of “computer” is viewed as “apply it on a computer” at step 2a, prong 2 and step 2b. Thus, the claim is ineligible.
Dependent claim 3 is directed to additional functions performed by the processor. The processor is further used to: acquire information about weather at the time of delivery to the delivery destination (Paragraph 0035). This is considered “insignificant extra-solution activity” since is just “mere data gathering” to use it for an analysis (MPEP 2106.05g), being applicable at both Step 2A, Prong 2 and Step 2B. Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Dependent claims 4 and 12 are directed to additional functions performed by the processor. The processor is further used to: acquire information about the day of the week on which a package is delivered to the delivery destination (Paragraph 0038). This is considered “insignificant extra-solution activity” since is just “mere data gathering” to use it for an analysis (MPEP 2106.05g), being applicable at both Step 2A, Prong 2 and Step 2B. Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Dependent claims 5 and 14-15 are directed to additional functions performed by the processor. The processor is further used to: acquire information about time of day in which delivery is made to the delivery destination (Paragraph 0040). This is considered “insignificant extra-solution activity” since is just “mere data gathering” to use it for an analysis (MPEP 2106.05g), being applicable at both Step 2A, Prong 2 and Step 2B. Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Dependent claims 7 and 8 are directed to additional elements such as: an information processing program; and a non-transitory computer-readable storage medium. The information processing program is merely used to execute the information processing method (Paragraph 0008). The non-transitory computer-readable storage medium is merely used to store the information processing program (Paragraph 0018). Merely stating that the step is performed by a computer component results in “apply it” on a computer (MPEP 2106.05f) being applicable at both Step 2A, Prong 2 and Step 2B. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1, 3-8, 12, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable by Meister (US 2022/0044198 A1), in view of Cajias et al. (US 2021/0287541 A1).
Regarding claim 1 (Currently Amended), Meister discloses an information processing device configured to determine a transit point of a route for delivering a package to one or more delivery destinations (Paragraph 0003, there is a need for an approach for providing dynamic parking and package delivery load recommendations (e.g., what packages to pick from the delivery truck to deliver from each stop along a last mile delivery route) based on on-site parking availability and attributes (e.g., attributes related to delivery capabilities such as carrying capacity, range, etc.) of the delivery personnel (e.g., drivers) and/or other delivery means (e.g., delivery drones); Paragraph 0005, According to another embodiment, an apparatus comprises at least one processor, and at least one memory including computer program code for one or more computer programs, the at least one memory and the computer program code configured to, with the at least one processor, cause, at least in part, the apparatus to determine a stopping location associated with a delivery vehicle. The delivery vehicle carries a plurality of delivery items. The apparatus also is caused to determine a subset of the plurality of delivery items to be delivered from the stopping location by a delivery means of the delivery vehicle in a load based, at least in part, on one or more delivery capability attributes of the delivery means. The subset of the plurality of delivery items is determined dynamically based on detecting that the delivery vehicle has stopped at the stopping location. The apparatus further is caused to provide data for presenting or transmitting the subset of the plurality of delivery items as an output; Examiner interprets the “stopping location such as a parking” as the “transit point of a route”), the information processing device comprising a processor configured to (Figure 8, item 803, Processor):
acquire, for each of the one or more delivery destinations, a travel trajectory of a delivery person (Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. Given a list of pick-up/drop-off locations/addresses and the distances among the list of delivery locations, the navigation routing engine 207 can determine the shortest/faster/easiest possible route that visits each delivery location and returns to the parking location based a cost function. The navigation routing engine 207 can use a delivery distance, a delivery time, or a combination thereof as a cost function to generate the delivery route, using various positioning assisted navigation technologies (e.g., global navigation satellite systems (GNSS), WiFi, Bluetooth, Bluetooth low energy, 2/3/4/5G cellular signals, ultra-wideband (UWB) signals, etc.) to provide walking directions and map based on high definition outdoors and/or indoors map data retrieved from the geographic database 109. As mentioned, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc.) and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination in the past by one or more delivery persons (Paragraph 0052, In one embodiment, in step 301, the parking module 201 can determine a stopping location associated with a delivery vehicle 101. The delivery vehicle 101 carries a plurality of delivery items 107. Referring back to the delivery scenario shown in FIG. 1 within the area 103 including the plurality of parking locations 105 and designated delivery locations of the plurality delivery items 107 (e.g., packages). In one embodiment, the parking module 201 determines the best stopping location based on parking data (e.g., historical, and/or real-time data). In another embodiment, the parking module 201 determines the best stopping location by feeding various attribute data about the delivery items, the driver, the recipients, the delivery locations, the vehicle, etc. in the above-described algorithm and/or recommendation model; Paragraph 0053, In one embodiment, the parking module 201 can determine a vehicle location of the delivery vehicle, and determine one or more candidate stopping locations based on the vehicle location. The output module 205 can present the best stopping location in a map of the area 103. By way of example, the parking module 201 processes trajectory data (e.g., probe data) associated with journeys of vehicles and/or UE 113 (e.g., using big data analytics, artificial intelligence, etc.) to determine parking events of the vehicles. The parking module 201 can process the trajectory data to determine when a vehicle stopping time passing a threshold (e.g., 5 minutes) at a location. Via map matching, the parking module 201 can classify whether the location is a parking space, and then aggregate the classified parking events into parking data as a part of the parking data. When the location is mapped into a designated parking space (e.g., a marked parking spot) or an undesignated parking space (e.g., an unmarked street parking space), the relevant event data is recorded and aggregated into a database (e.g., the geographic database 109) as parking data), the travel trajectory of the delivery person including walking (Paragraph 0043, The system 100 then determines ideal stopping locations and recommend alternatives as necessary (as discussed). Each spot has its own travelling salesman route for a walking distance and a timeframe. The system 100 can calculate alternative parking such that the driver can spend as less time and walking distance as possible),
derive, for each of the one or more delivery destinations, a stop position of the delivery vehicle in each of the one or more deliveries based on a … between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in the each of the one or more deliveries made to the delivery destination in the past (Paragraph 0043, In other words, the system 100 supports dynamic parking via finding available target stopping locations in range, depending on historical data, from other drivers, temporary stopping locations, parking facilities, Loading zones, street width (number of lanes for 2nd row parking), etc. The system 100 then determines ideal stopping locations and recommend alternatives as necessary (as discussed). Each spot has its own travelling salesman route for a walking distance and a timeframe. The system 100 can calculate alternative parking such that the driver can spend as less time and walking distance as possible; Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. Given a list of pick-up/drop-off locations/addresses and the distances among the list of delivery locations, the navigation routing engine 207 can determine the shortest/faster/easiest possible route that visits each delivery location and returns to the parking location based a cost function. The navigation routing engine 207 can use a delivery distance, a delivery time, or a combination thereof as a cost function to generate the delivery route, using various positioning assisted navigation technologies (e.g., global navigation satellite systems (GNSS), WiFi, Bluetooth, Bluetooth low energy, 2/3/4/5G cellular signals, ultra-wideband (UWB) signals, etc.) to provide walking directions and map based on high definition outdoors and/or indoors map data retrieved from the geographic database 109; In this case, the stop position is the location that minimizes the walking distance and/or time. Also, the calculated walking distance and/or time is the same as the difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle),
derive, for each of the one or more delivery destinations, walking time of the delivery person in each of one or more deliveries based on the … between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in each of the one or more deliveries made to the delivery destination in the past (Paragraph 0043, In other words, the system 100 supports dynamic parking via finding available target stopping locations in range, depending on historical data, from other drivers, temporary stopping locations, parking facilities, Loading zones, street width (number of lanes for 2nd row parking), etc. The system 100 then determines ideal stopping locations and recommend alternatives as necessary (as discussed). Each spot has its own travelling salesman route for a walking distance and a timeframe. The system 100 can calculate alternative parking such that the driver can spend as less time and walking distance as possible; Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. Given a list of pick-up/drop-off locations/addresses and the distances among the list of delivery locations, the navigation routing engine 207 can determine the shortest/faster/easiest possible route that visits each delivery location and returns to the parking location based a cost function. The navigation routing engine 207 can use a delivery distance, a delivery time, or a combination thereof as a cost function to generate the delivery route, using various positioning assisted navigation technologies (e.g., global navigation satellite systems (GNSS), WiFi, Bluetooth, Bluetooth low energy, 2/3/4/5G cellular signals, ultra-wideband (UWB) signals, etc.) to provide walking directions and map based on high definition outdoors and/or indoors map data retrieved from the geographic database 109; Examiner interprets the “delivery time to walk from and ending at the stopping location based on respective delivery locations” as the “walking time.” Examiner notes that the calculated walking distance and/or time is the same as the difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle),
determine, for each of the one or more delivery destinations, a stop position in a delivery in which the walking time is shortest among the one or more deliveries made to the delivery destination in the past, as a transit point for the delivery destination (Paragraph 0043, In other words, the system 100 supports dynamic parking via finding available target stopping locations in range, depending on historical data, from other drivers, temporary stopping locations, parking facilities, Loading zones, street width (number of lanes for 2nd row parking), etc. The system 100 then determines ideal stopping locations and recommend alternatives as necessary (as discussed). Each spot has its own travelling salesman route for a walking distance and a timeframe. The system 100 can calculate alternative parking such that the driver can spend as less time and walking distance as possible; Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. Given a list of pick-up/drop-off locations/addresses and the distances among the list of delivery locations, the navigation routing engine 207 can determine the shortest/faster/easiest possible route that visits each delivery location and returns to the parking location based a cost function. The navigation routing engine 207 can use a delivery distance, a delivery time, or a combination thereof as a cost function to generate the delivery route, using various positioning assisted navigation technologies (e.g., global navigation satellite systems (GNSS), WiFi, Bluetooth, Bluetooth low energy, 2/3/4/5G cellular signals, ultra-wideband (UWB) signals, etc.) to provide walking directions and map based on high definition outdoors and/or indoors map data retrieved from the geographic database 109; Paragraph 0087, The above-mentioned embodiments dynamically process various attribute data about the delivery items, the driver, the recipients, the delivery locations, the vehicle, etc. to improve speed and quality in calculating a best spot to stop/park and what items to delivery from the stopping location. When the driver can stop at the best spot (i.e., an initially recommended stopping location), the above-mentioned embodiments present the list of items for the driver to load and deliver. When the best spot becomes unavailable (e.g., taken by another vehicle), the above-mentioned embodiments calculates the next best stopping location (i.e., a newly recommended stopping location) and a new set of items to load and deliver therefrom. Therefore, the above-mentioned embodiments dynamically determine and present information of stopping locations and package delivery plans tailored for a delivery means (e.g., a delivery person, drone, etc.) and in response to on-site parking condition changes, thereby increasing delivery efficiency; Examiner interprets “shortest/faster/easiest possible route (e.g., walking route) that visits each delivery location and returns to the parking location based on a delivery distance and/or delivery time” as the “shortest walking distance”),
and create and output the route to travel through the transit point for the delivery destination (Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. As mentioned, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc; Paragraph 0073, Optionally, the system 100 can provide a delivery route for the 7 delivery items 503; Paragraph 0093, In one embodiment, as noted above, the vehicles are equipped with an embedded navigation systems or other navigation devices (e.g., a UE 113) that are capable of submitting requests for parking information (e.g., parking scores, etc.), and of guiding a driver of the vehicle 101 along a navigation route using the parking information).
Although Meister discloses to determine a stop position in a delivery based on walking distance and/or time of the delivery person (e.g., a stop position in a delivery in which the walking time is shortest among the one or more deliveries made to the delivery destination), Meister does not specifically disclose how the walking time is calculated (e.g., wherein the walking time of a delivery person in each of one or more deliveries based on a difference).
However, Cajias discloses derive, for each of the one or more delivery destinations, a stop position of the delivery vehicle in each of the one or more deliveries based on a difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in the each of the one or more deliveries made to the delivery destination in the past, derive, for each of the one or more delivery destinations, walking time of the delivery person in each of one or more deliveries based on the difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in each of the one or more deliveries made to the delivery destination in the past (Paragraph 0019, In another aspect, a method for providing a parking recommendation is disclosed. The method may comprise obtaining parking data for a predetermined time period, wherein the parking data comprises a plurality of parked locations and a plurality of destination locations; determining a time-dependent distance threshold based on a last mile model associated with the obtained parking data, wherein the time-dependent distance threshold comprises an average walking distance threshold associated with the plurality of parked locations and the plurality of destination locations; and providing the parking recommendation based on the determined time-dependent distance threshold; Paragraph 0060, At step 303, the method 300 may include obtaining parking data for a pre-determined time period. The parking data may comprises a plurality of destination locations and parked locations associated with each of the plurality of destination locations. In some embodiments, the parking data may comprise data related to a walking distance and/or a walking time from the parked location to the destination location. The destination location may be the observed location such as the POI. In various embodiments, the parking data associated with the destination location may dynamically vary with respect to time. Accordingly, the parking data may be obtained for the pre-determined time period, which may be previous to the time of day. The time period may be a period of day, a week, a month, or a year. In various embodiments, the time period may be based on holidays, working days, event schedules, weather conditions of the day, seasons such as winter, summer and the like. The parking data may be obtained from various navigation clients 103 and user devices such as user equipment 105. In various embodiments, the navigation client 103 may be onboard a vehicle to report a destination location and its corresponding parked location. For instance, the navigation client 103 (comprising the GPS sensors) may report the user entered destination, as the route destination location and a last location of the vehicle before the navigation client 103 was turned-off, as the parked location or the parking spot for the destination location. In some embodiments, the navigation client 103 may determine a walking route between the parked location and the destination location. The navigation client 103 may report, using the walking route, the walking distance between the parked location and the destination location and/or the walking time to reach the destination location from the parked location. According to some example embodiments, the user equipment 105 may be associated with a user of the vehicle to report a destination location and its corresponding parked location. The user equipment 105 (comprising the onboard sensors) may detect current transport mode of the user. For instance, the user equipment 105 may determine whether the user is traveling in the vehicle or the user is walking. Further, the user equipment 105 may determine a location where the transition occurred from driving mode (i.e. the user is traveling through the vehicle) to the walking mode. The user equipment 105 may report the transition occurred location, as the parked location and the POI location reached, as the destination location. In some embodiments, the user equipment 105 may determine the walking route between the parked location and the destination location. The user equipment 105 may report, using the walking route, the walking distance between the parked location and the destination location and/or the walking time to reach the destination location from the parked location. In various embodiments, the navigation client 103 and the user equipment 105 may report the destination location and its corresponding parked location with a time stamp attached. The time stamp may comprise a time of the day (for instance, a time of the day at which the last location of the vehicle was determined or a time of the day at which the transition occurred location was determined), a day of the week and the like).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the information processing device, wherein a stop position is determined based on walking time of a delivery person in each of one or more deliveries of the invention of Meister to further specify how the walking time is calculated based on a difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle (e.g., the user entered destination, as the route destination location and a last location of the vehicle before the navigation client 103 was turned-off) of the invention of Cajias et al. because doing so would allow the method to provide parking recommendation based on the last mile model (see Cajias et al., Paragraph 0013). Further, the claimed invention is merely a combination of old elements, and in combination each element 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.
Regarding claim 3 (Previously Presented), which is dependent of claim 1, the combination of Meister and Cajias et al. discloses all the limitations in claim 1. Meister further discloses wherein the processor is further configured to acquire weather when delivering to the one or more delivery destinations; and acquire, for each of the one or more delivery destinations, a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination in the weather acquired by the weather information acquisition section (Figure 8, item 803, Processor; Paragraph 0002, Last mile delivery of goods to customers (e.g., delivery of goods from a nearest delivery transportation hub to the final destination) presents significant technical challenges to delivery and logistics service providers. This is because conditions on the last mile delivery route (e.g., available parking at the delivery location, traffic, weather, etc.) are dynamic and can affect where, when, and how deliveries can be made; Paragraph 0053, the parking module 201 processes trajectory data (e.g., probe data) associated with journeys of vehicles and/or UE 113 (e.g., using big data analytics, artificial intelligence, etc.) to determine parking events of the vehicles; Paragraph 0067, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc.; Paragraph 0121, In one embodiment, the HD mapping data records 611 also include real-time sensor data collected from probe vehicles in the field. The real-time sensor data, for instance, integrates real-time traffic information, weather, and road conditions (e.g., potholes, road friction, road wear, etc.) with highly detailed 3D representations of street and geographic features to provide precise real-time also at centimeter-level accuracy. Other sensor data can include vehicle telemetry or operational data such as windshield wiper activation state, braking state, steering angle, accelerator position, and/or the like).
Regarding claim 4 (Previously Presented), which is dependent of claim 1, which is dependent of claim 1, Meister discloses all the limitations in claim 1. The combination of Meister and Cajias et al. further discloses wherein the processor is further configure to: acquire a day of week when delivering to the one or more delivery destinations; and acquire, for each of the one or more delivery destinations, a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination on the day of week acquired by the day-of-week information acquisition section (Figure 8, item 803, Processor; Paragraph 0049, In one embodiment, the parking data can be stratified according to different contextual parameters such as but not limited to time of day, day of the week, month, season, etc. In another embodiment, the system 100 can estimate a temporary parking time limit for a temporary parking location based on the parking data; Paragraph 0053, the parking module 201 processes trajectory data (e.g., probe data) associated with journeys of vehicles and/or UE 113 (e.g., using big data analytics, artificial intelligence, etc.) to determine parking events of the vehicles; Paragraph 0067, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc.).
Regarding claim 5 (Previously Presented), which is dependent of claim 1, the combination of Meister and Cajias et al. discloses all the limitations in claim 1. Meister further discloses wherein the processor is further configure to: acquire time of day when delivering to the one or more delivery destinations; and acquire, for each of the one or more delivery destinations, a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination during the time of day acquired by the time-of-day information acquisition section (Figure 8, item 803, Processor; Paragraph 0049, In one embodiment, the parking data can be stratified according to different contextual parameters such as but not limited to time of day, day of the week, month, season, etc. In another embodiment, the system 100 can estimate a temporary parking time limit for a temporary parking location based on the parking data; Paragraph 0053, the parking module 201 processes trajectory data (e.g., probe data) associated with journeys of vehicles and/or UE 113 (e.g., using big data analytics, artificial intelligence, etc.) to determine parking events of the vehicles; Paragraph 0067, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc.).
Regarding claim 6 (Currently Amended), Meister discloses an information processing method executed by a computer for creating a transit point of a route for delivering a package to one or more delivery destinations (Paragraph 0003, there is a need for an approach for providing dynamic parking and package delivery load recommendations (e.g., what packages to pick from the delivery truck to deliver from each stop along a last mile delivery route) based on on-site parking availability and attributes (e.g., attributes related to delivery capabilities such as carrying capacity, range, etc.) of the delivery personnel (e.g., drivers) and/or other delivery means (e.g., delivery drones); Paragraph 0004, According to one embodiment, a method comprises determining a stopping location associated with a delivery vehicle. The delivery vehicle carries a plurality of delivery items. The method also comprises determining a subset of the plurality of delivery items to be delivered from the stopping location by a delivery means of the delivery vehicle in a load based, at least in part, on one or more delivery capability attributes of the delivery means. The subset of the plurality of delivery items is determined dynamically based on detecting that the delivery vehicle has stopped at the stopping location. The method further comprises providing data for presenting or transmitting the subset of the plurality of delivery items as an output; Examiner interprets the “stopping location such as a parking” as the “transit point of a route”), the computer including a processor configured to perform the method comprising (Figure 8, item 803, Processor):
acquiring, by the processor for each of one or more delivery destinations, a travel trajectory of a delivery person (Figure 8, item 803, Processor; Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. Given a list of pick-up/drop-off locations/addresses and the distances among the list of delivery locations, the navigation routing engine 207 can determine the shortest/faster/easiest possible route that visits each delivery location and returns to the parking location based a cost function. The navigation routing engine 207 can use a delivery distance, a delivery time, or a combination thereof as a cost function to generate the delivery route, using various positioning assisted navigation technologies (e.g., global navigation satellite systems (GNSS), WiFi, Bluetooth, Bluetooth low energy, 2/3/4/5G cellular signals, ultra-wideband (UWB) signals, etc.) to provide walking directions and map based on high definition outdoors and/or indoors map data retrieved from the geographic database 109. As mentioned, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc.) and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination in the past (Paragraph 0052, In one embodiment, in step 301, the parking module 201 can determine a stopping location associated with a delivery vehicle 101. The delivery vehicle 101 carries a plurality of delivery items 107. Referring back to the delivery scenario shown in FIG. 1 within the area 103 including the plurality of parking locations 105 and designated delivery locations of the plurality delivery items 107 (e.g., packages). In one embodiment, the parking module 201 determines the best stopping location based on parking data (e.g., historical, and/or real-time data). In another embodiment, the parking module 201 determines the best stopping location by feeding various attribute data about the delivery items, the driver, the recipients, the delivery locations, the vehicle, etc. in the above-described algorithm and/or recommendation model; Paragraph 0053, In one embodiment, the parking module 201 can determine a vehicle location of the delivery vehicle, and determine one or more candidate stopping locations based on the vehicle location. The output module 205 can present the best stopping location in a map of the area 103. By way of example, the parking module 201 processes trajectory data (e.g., probe data) associated with journeys of vehicles and/or UE 113 (e.g., using big data analytics, artificial intelligence, etc.) to determine parking events of the vehicles. The parking module 201 can process the trajectory data to determine when a vehicle stopping time passing a threshold (e.g., 5 minutes) at a location. Via map matching, the parking module 201 can classify whether the location is a parking space, and then aggregate the classified parking events into parking data as a part of the parking data. When the location is mapped into a designated parking space (e.g., a marked parking spot) or an undesignated parking space (e.g., an unmarked street parking space), the relevant event data is recorded and aggregated into a database (e.g., the geographic database 109) as parking data), the travel trajectory of the delivery person including walking (Paragraph 0043, The system 100 then determines ideal stopping locations and recommend alternatives as necessary (as discussed). Each spot has its own travelling salesman route for a walking distance and a timeframe. The system 100 can calculate alternative parking such that the driver can spend as less time and walking distance as possible);
deriving, by the processor for each of the one or more delivery destinations, a stop position of the delivery vehicle in each of the one or more deliveries based on a … between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in the each of the one or more deliveries made to the delivery destination in the past (Paragraph 0043, In other words, the system 100 supports dynamic parking via finding available target stopping locations in range, depending on historical data, from other drivers, temporary stopping locations, parking facilities, Loading zones, street width (number of lanes for 2nd row parking), etc. The system 100 then determines ideal stopping locations and recommend alternatives as necessary (as discussed). Each spot has its own travelling salesman route for a walking distance and a timeframe. The system 100 can calculate alternative parking such that the driver can spend as less time and walking distance as possible; Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. Given a list of pick-up/drop-off locations/addresses and the distances among the list of delivery locations, the navigation routing engine 207 can determine the shortest/faster/easiest possible route that visits each delivery location and returns to the parking location based a cost function. The navigation routing engine 207 can use a delivery distance, a delivery time, or a combination thereof as a cost function to generate the delivery route, using various positioning assisted navigation technologies (e.g., global navigation satellite systems (GNSS), WiFi, Bluetooth, Bluetooth low energy, 2/3/4/5G cellular signals, ultra-wideband (UWB) signals, etc.) to provide walking directions and map based on high definition outdoors and/or indoors map data retrieved from the geographic database 109; In this case, the stop position is the location that minimizes the walking distance and/or time. Also, the calculated walking distance and/or time is the same as the difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle);
deriving, by the processor for each of the one or more delivery destinations, walking time of the delivery person in each of one or more deliveries based on the … between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in each of the one or more deliveries made to the delivery destination in the past (Paragraph 0043, In other words, the system 100 supports dynamic parking via finding available target stopping locations in range, depending on historical data, from other drivers, temporary stopping locations, parking facilities, Loading zones, street width (number of lanes for 2nd row parking), etc. The system 100 then determines ideal stopping locations and recommend alternatives as necessary (as discussed). Each spot has its own travelling salesman route for a walking distance and a timeframe. The system 100 can calculate alternative parking such that the driver can spend as less time and walking distance as possible; Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. Given a list of pick-up/drop-off locations/addresses and the distances among the list of delivery locations, the navigation routing engine 207 can determine the shortest/faster/easiest possible route that visits each delivery location and returns to the parking location based a cost function. The navigation routing engine 207 can use a delivery distance, a delivery time, or a combination thereof as a cost function to generate the delivery route, using various positioning assisted navigation technologies (e.g., global navigation satellite systems (GNSS), WiFi, Bluetooth, Bluetooth low energy, 2/3/4/5G cellular signals, ultra-wideband (UWB) signals, etc.) to provide walking directions and map based on high definition outdoors and/or indoors map data retrieved from the geographic database 109; Examiner interprets the “delivery time to walk from and ending at the stopping location based on respective delivery locations” as the “walking time.” Examiner notes that the calculated walking distance and/or time is the same as the difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle);
determining, by the processor for each of the one or more delivery destinations, a stop position in a delivery in which the walking time is shortest among the one or more deliveries made to the delivery destination in the past, as a transit point for the delivery destination (Paragraph 0043, In other words, the system 100 supports dynamic parking via finding available target stopping locations in range, depending on historical data, from other drivers, temporary stopping locations, parking facilities, Loading zones, street width (number of lanes for 2nd row parking), etc. The system 100 then determines ideal stopping locations and recommend alternatives as necessary (as discussed). Each spot has its own travelling salesman route for a walking distance and a timeframe. The system 100 can calculate alternative parking such that the driver can spend as less time and walking distance as possible; Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. Given a list of pick-up/drop-off locations/addresses and the distances among the list of delivery locations, the navigation routing engine 207 can determine the shortest/faster/easiest possible route that visits each delivery location and returns to the parking location based a cost function. The navigation routing engine 207 can use a delivery distance, a delivery time, or a combination thereof as a cost function to generate the delivery route, using various positioning assisted navigation technologies (e.g., global navigation satellite systems (GNSS), WiFi, Bluetooth, Bluetooth low energy, 2/3/4/5G cellular signals, ultra-wideband (UWB) signals, etc.) to provide walking directions and map based on high definition outdoors and/or indoors map data retrieved from the geographic database 109; Paragraph 0087, The above-mentioned embodiments dynamically process various attribute data about the delivery items, the driver, the recipients, the delivery locations, the vehicle, etc. to improve speed and quality in calculating a best spot to stop/park and what items to delivery from the stopping location. When the driver can stop at the best spot (i.e., an initially recommended stopping location), the above-mentioned embodiments present the list of items for the driver to load and deliver. When the best spot becomes unavailable (e.g., taken by another vehicle), the above-mentioned embodiments calculates the next best stopping location (i.e., a newly recommended stopping location) and a new set of items to load and deliver therefrom. Therefore, the above-mentioned embodiments dynamically determine and present information of stopping locations and package delivery plans tailored for a delivery means (e.g., a delivery person, drone, etc.) and in response to on-site parking condition changes, thereby increasing delivery efficiency; Examiner interprets “shortest/faster/easiest possible route (e.g., walking route) that visits each delivery location and returns to the parking location based on a delivery distance and/or delivery time” as the “shortest walking distance”);
and creating and outputting, by the processor, the route to travel through the transit point for the delivery destination (Paragraph 0067, In one embodiment, the navigation routing engine 207 can generate a delivery route starting from and ending at the stopping location based on respective delivery locations of the subset of the plurality of delivery items of the load, and provide the delivery route to the output module 205. As mentioned, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc; Paragraph 0073, Optionally, the system 100 can provide a delivery route for the 7 delivery items 503; Paragraph 0093, In one embodiment, as noted above, the vehicles are equipped with an embedded navigation systems or other navigation devices (e.g., a UE 113) that are capable of submitting requests for parking information (e.g., parking scores, etc.), and of guiding a driver of the vehicle 101 along a navigation route using the parking information).
Although Meister discloses determining a stop position in a delivery based on walking distance and/or time of the delivery person (e.g., the walking time is shortest among one or more deliveries made to the delivery destination), Meister does not specifically disclose how the walking time is calculated (e.g., wherein the walking time of a delivery person in each of one or more deliveries based on a difference).
However, Cajias discloses deriving, by the processor for each of the one or more delivery destinations, a stop position of the delivery vehicle in each of the one or more deliveries based on a difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in the each of the one or more deliveries made to the delivery destination in the past; deriving, by the processor for each of the one or more delivery destinations, walking time of the delivery person in each of one or more deliveries based on the difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle in each of the one or more deliveries made to the delivery destination in the past (Paragraph 0019, In another aspect, a method for providing a parking recommendation is disclosed. The method may comprise obtaining parking data for a predetermined time period, wherein the parking data comprises a plurality of parked locations and a plurality of destination locations; determining a time-dependent distance threshold based on a last mile model associated with the obtained parking data, wherein the time-dependent distance threshold comprises an average walking distance threshold associated with the plurality of parked locations and the plurality of destination locations; and providing the parking recommendation based on the determined time-dependent distance threshold; Paragraph 0060, At step 303, the method 300 may include obtaining parking data for a pre-determined time period. The parking data may comprises a plurality of destination locations and parked locations associated with each of the plurality of destination locations. In some embodiments, the parking data may comprise data related to a walking distance and/or a walking time from the parked location to the destination location. The destination location may be the observed location such as the POI. In various embodiments, the parking data associated with the destination location may dynamically vary with respect to time. Accordingly, the parking data may be obtained for the pre-determined time period, which may be previous to the time of day. The time period may be a period of day, a week, a month, or a year. In various embodiments, the time period may be based on holidays, working days, event schedules, weather conditions of the day, seasons such as winter, summer and the like. The parking data may be obtained from various navigation clients 103 and user devices such as user equipment 105. In various embodiments, the navigation client 103 may be onboard a vehicle to report a destination location and its corresponding parked location. For instance, the navigation client 103 (comprising the GPS sensors) may report the user entered destination, as the route destination location and a last location of the vehicle before the navigation client 103 was turned-off, as the parked location or the parking spot for the destination location. In some embodiments, the navigation client 103 may determine a walking route between the parked location and the destination location. The navigation client 103 may report, using the walking route, the walking distance between the parked location and the destination location and/or the walking time to reach the destination location from the parked location. According to some example embodiments, the user equipment 105 may be associated with a user of the vehicle to report a destination location and its corresponding parked location. The user equipment 105 (comprising the onboard sensors) may detect current transport mode of the user. For instance, the user equipment 105 may determine whether the user is traveling in the vehicle or the user is walking. Further, the user equipment 105 may determine a location where the transition occurred from driving mode (i.e. the user is traveling through the vehicle) to the walking mode. The user equipment 105 may report the transition occurred location, as the parked location and the POI location reached, as the destination location. In some embodiments, the user equipment 105 may determine the walking route between the parked location and the destination location. The user equipment 105 may report, using the walking route, the walking distance between the parked location and the destination location and/or the walking time to reach the destination location from the parked location. In various embodiments, the navigation client 103 and the user equipment 105 may report the destination location and its corresponding parked location with a time stamp attached. The time stamp may comprise a time of the day (for instance, a time of the day at which the last location of the vehicle was determined or a time of the day at which the transition occurred location was determined), a day of the week and the like).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the information processing device, wherein a stop position is determined based on walking time of a delivery person in each of one or more deliveries of the invention of Meister to further specify how the walking time is calculated based on a difference between the travel trajectory of the delivery person and the travel trajectory of the delivery vehicle (e.g., the user entered destination, as the route destination location and a last location of the vehicle before the navigation client 103 was turned-off) of the invention of Cajias et al. because doing so would allow the method to provide parking recommendation based on the last mile model (see Cajias et al., Paragraph 0013). Further, the claimed invention is merely a combination of old elements, and in combination each element 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.
Regarding claim 7 (Currently Amended), which is dependent of claim 6, the combination of Meister and Cajias et al. discloses all the limitations in claim 6. Meister further discloses an information processing program that causes the computer to execute the information processing method according to claim 6 (Paragraph 0005, According to another embodiment, an apparatus comprises at least one processor, and at least one memory including computer program code for one or more computer programs, the at least one memory and the computer program code configured to, with the at least one processor, cause, at least in part, the apparatus to determine a stopping location associated with a delivery vehicle. The delivery vehicle carries a plurality of delivery items. The apparatus also is caused to determine a subset of the plurality of delivery items to be delivered from the stopping location by a delivery means of the delivery vehicle in a load based, at least in part, on one or more delivery capability attributes of the delivery means. The subset of the plurality of delivery items is determined dynamically based on detecting that the delivery vehicle has stopped at the stopping location. The apparatus further is caused to provide data for presenting or transmitting the subset of the plurality of delivery items as an output; Paragraph 0126, FIG. 7 illustrates a computer system 700 upon which an embodiment of the invention may be implemented. Computer system 700 is programmed (e.g., via computer program code or instructions) to provide a dynamic parking and package delivery load recommendation based on on-site parking availability and delivery means capability attributes as described herein and includes a communication mechanism such as a bus 710 for passing information between other internal and external components of the computer system 700).
Regarding claim 8 (Previously Presented), which is dependent of claim 7, the combination of Meister and Cajias et al. discloses all the limitations in claim 7. Meister further discloses a non-transitory computer-readable storage medium having stored therein the information processing program according to claim 7 (Paragraph 0133, The term computer-readable medium is used herein to refer to any medium that participates in providing information to processor 702, including instructions for execution. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media; Paragraph 0145, The software module could reside in RAM memory, flash memory, registers, or any other form of writable computer-readable storage medium known in the art including non-transitory computer-readable storage medium).
Regarding claim 12 (Previously Presented), which is dependent of claim 3, the combination of Meister and Cajias et al. discloses all the limitations in claim 3. Meister further discloses wherein the processor is further configure to: acquire a day of week when delivering to the one or more delivery destinations; and acquire, for each of the one or more delivery destinations, a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination on the day of week acquired by the day-of-week information acquisition section (Figure 8, item 803, Processor; Paragraph 0049, In one embodiment, the parking data can be stratified according to different contextual parameters such as but not limited to time of day, day of the week, month, season, etc. In another embodiment, the system 100 can estimate a temporary parking time limit for a temporary parking location based on the parking data; Paragraph 0053, the parking module 201 processes trajectory data (e.g., probe data) associated with journeys of vehicles and/or UE 113 (e.g., using big data analytics, artificial intelligence, etc.) to determine parking events of the vehicles; Paragraph 0067, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc.).
Regarding claim 14 (Previously Presented), which is dependent of claim 3, the combination of Meister and Cajias et al. discloses all the limitations in claim 3. Meister further discloses wherein the processor is further configure to: acquire time of day when delivering to the one or more delivery destinations; and acquire, for each of the one or more delivery destinations, a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination during the time of day acquired by the time-of-day information acquisition section (Figure 8, item 803, Processor; Paragraph 0049, In one embodiment, the parking data can be stratified according to different contextual parameters such as but not limited to time of day, day of the week, month, season, etc. In another embodiment, the system 100 can estimate a temporary parking time limit for a temporary parking location based on the parking data; Paragraph 0053, the parking module 201 processes trajectory data (e.g., probe data) associated with journeys of vehicles and/or UE 113 (e.g., using big data analytics, artificial intelligence, etc.) to determine parking events of the vehicles; Paragraph 0067, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc.).
Regarding claim 15 (Previously Presented), which is dependent of claim 4, the combination of Meister and Cajias et al. discloses all the limitations in claim 4. Meister further discloses wherein the processor is further configure to: acquire time of day when delivering to the one or more delivery destinations; and acquire, for each of the one or more delivery destinations, a travel trajectory of a delivery person and a travel trajectory of a delivery vehicle in one or more deliveries made to the delivery destination during the time of day acquired by the time-of-day information acquisition section (Paragraph 0049, In one embodiment, the parking data can be stratified according to different contextual parameters such as but not limited to time of day, day of the week, month, season, etc. In another embodiment, the system 100 can estimate a temporary parking time limit for a temporary parking location based on the parking data; Paragraph 0053, the parking module 201 processes trajectory data (e.g., probe data) associated with journeys of vehicles and/or UE 113 (e.g., using big data analytics, artificial intelligence, etc.) to determine parking events of the vehicles; Paragraph 0067, the system 100 can collect sensor data from the UE 113 (e.g., a delivery handheld device or a mobile user device), including moving trajectory data of the delivery means (e.g., a delivery person, drone, etc.), which can be used for generating a delivery route. A deliver person can be a driver, a driver assistant, a package handler, etc.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Ma (WO 2020/177261 A1) – discloses obtaining user trajectory data of at least two users participating in the trajectory data collection task may include: after acquiring the task start request of the user participating in the trajectory data collection task, detecting whether the current position of the user matches the task starting position. Optionally, the user obtains the notification information of the trajectory data collection task through the mobile terminal, and sends the task start request through the mobile terminal. If the current position of the user matches the starting position of the task, the current time is recorded as the starting check-in time, and the user's real-time motion track and real-time walking distance are collected (see at least Page 6, step 202).
Lacaze et al. (US 2021/0034847 A1) – discloses FIG. 4A—Stopping locations are computed to minimize the time to deliver the items. This considers where the human can and cannot walk due to obstructions, etc. FIG. 4B—The human may be able to carry multiple deliveries without returning to the truck. If the packages are heavy, the walking time with the package may be slower than without it (see at least Paragraph 0018).
Bates (Bates, O., Friday, A., Allen, J., Cherrett, T., McLeod, F., Bektas, T., Nguyen, T., Piecyk, M., Piotrowska, M., Wise, S. and Davies, N., 2018, April. Transforming last-mile logistics: Opportunities for more sustainable deliveries. In Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems (pp. 1-14)) – discloses a driver’s knowledge helps them make decisions that reduce the amount of time spent delivering each parcel. Knowledge of the best parking locations (e.g. within range of multiple addresses, the longest loading times in loading bays), knowing when and where to walk, and where they can drive the van gives them the upper hand in the city. Before a driver gets to a building they must decide where to stop and unload their van. This is not a trivial task. Are they taking one parcel, or multiple? How long can they stop at the curbside for given the twentyminute loading times? Is there space for them to stop and unload their van? Will they get a parking ticket for parking illegally or beyond the loading time? Once the driver has decided on where to stop, how many parcels they will carry, and how far they are willing to walk, they need to navigate from the vehicle stopping point to the address in the manifest and then work out where and with whom they can leave the parcel with. A challenge for the drivers is picking a stopping point that is optimal for a dropping point, or in relation to multiple dropping points. When proof of delivery (PoD) is required, drivers have to find this person (a concierge, or the recipient of the parcel) and obtain their signature (see at least Page 6, Driver knowledge and personal relationships).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARJORIE PUJOLS-CRUZ whose telephone number is (571)272-4668. The examiner can normally be reached Mon-Thru 7:30 AM - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patricia H Munson can be reached at (571)270-5396. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MARJORIE PUJOLS-CRUZ/Examiner, Art Unit 3624