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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. PCT/CN2022/125530, filed on 10/14/2022.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 4/9/2025 and 10/16/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because of:
Fig. 3 lacks sufficient numbering of the elements.
In Fig. 9, S103 includes the phrase “smart container alposition information”, which needs grammatical correction. In addition, the spelling of mailroom in S107 and S108 is inconsistent.
Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
Applicant is reminded of the proper content of an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
The abstract of the disclosure is objected to because it exceeds the limit of 150 words. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Objections
Claims 6, 8-9 and 12 is objected to because of the following informality:
In Claim 6, there are two instances of the use of the wording “includes one or more of”; in each instance, a colon is needed at the end (i.e., “includes one or more of:”).
In Claim 8, the phrase “wherein the different categories include at least one of” should have a colon after “at least one of”.
In Claim 9, The phrase “category second” should be written as “second category”, to be consistent with the other parts of the limitation which have the numeral before the word category.
In Claim 12, a colon should be placed at the end of the phrase: “wherein the passage coordination strategy includes at least one of”.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-16 and 18-20 are rejected under 35 U.S.C. §102 as being unpatentable over Sibley (US 2018/0330325 A1).
Regarding Claim 1, Sibley discloses the limitations: a robot delivery system {robot instructed to pick up package, Abstract} comprising: a terminal device {smartphone, Figs. 30-31, and/or deliverer computing device 141, Fig. 4} configured to determine delivery demand information {communication of delivery and/or pick-up instructions, ¶71} including at least one of a target collection mode or a target unloading mode {cellphone used to identify delivery/pick-up location, Figs. 30-31 and ¶133}; a server {151, Fig. 4} configured to receive the delivery demand information {receiving delivery/pick-up request, ¶227} from the terminal device {platform server(s) 151 communicates with deliverer computing device 141 (which can be the smartphone in Figs. 30-31) via cloud 172, Fig. 4 and ¶71} and generate a delivery task data packet {cloud 172 inherently provides an internet protocol (i.e., packet-based) communication network between robot computer 156 and platform server(s) 151, Fig. 4 and ¶67} according to the delivery demand information {communication of delivery and/or pick-up instructions, ¶71}; and a delivery robot {robot 114, Figs. 5-6} configured to receive the delivery task data packet from the server {software based communication with robot about pick-up and/or delivery, ¶75}, and perform a delivery task according to the delivery task data packet {computer network provides instructions and directions to robot, ¶213}; wherein: the target collection mode is selected from a plurality of collection modes including: a first collection mode {Figs. 32-33 shows robot 114 gathering a container from the ground} in which the delivery robot performs cargo collection without user participation {¶163 describes a robot using an object, like a step, to aid in picking up a container/package unaided otherwise}; and a second collection mode {above ground level container/parcel/package pickup, such as from a mailbox, Fig. 3} in which the delivery robot performs cargo collection with user participation {user has placed transportation container 361 in above ground container/compartment 115, Fig. 3}; and the target unloading mode is selected from a plurality of unloading modes including: a first unloading mode {dropping off package at ground-level on stair-type step, as represented in Fig. 43} in which the delivery robot performs cargo unloading without user participation {robot delivers package unaided, leaving it on an step, Fig. ¶215}; and a second unloading mode {delivery by robot to a substantially elevated site, be it mailbox container 115 in Fig. 3; a picnic table Figs. 46-47, see ¶218; or pickup container 116 in Fig. 34} in which the delivery robot performs cargo unloading with user participation {delivery by robot with or without human assistance described in ¶175, which is comparable to the user retrieving the package from a picnic table, Fig. 47, or the robot handing the package directly to the recipient}.
Regarding Claim 2, Sibley discloses all the limitations of Claim 1, as discussed supra. In addition, Sibley explicitly recites the limitation: wherein: the delivery robot is one of a plurality of delivery robots in the system {fleet of vehicle/robots, ¶54}; and the server is further configured to determine a target delivery robot from the plurality of delivery robots according to the delivery demand information {coordinating the pick-up and/or delivery involving a fleet of vehicles/robots described in ¶153}.
Regarding Claim 3, Sibley discloses all the limitations of Claim 2, as discussed supra. In addition, Sibley explicitly recites the limitations: wherein the server is further configured to, when determining the target delivery robot: determine delivery priorities according to the at least one of the target collection mode and/or the target unloading mode {determining which robot, from a fleet of robots, is used for a particular pick-up/delivery is based on factors, such as load capacity, battery life, and travel time, ¶153, wherein the determination/evaluation-step involves ranking ¶154}; and determine the target delivery robot from the plurality of delivery robots according to the delivery priorities {the determination/evaluation-step of which of multiple robots to send for a particular pick-up/delivery involves ranking factors, such as travel time for pick-up and delivery, battery life and robot location, ¶154 and ¶248}.
Regarding Claim 4, Sibley discloses all the limitations of Claim 3, as discussed supra. In addition, Sibley explicitly recites the limitation: wherein: the delivery priority of the second collection mode is higher than the delivery priority of the first collection mode {user specifying exact location a package is to be collected from at a home, Figs. 30-31 and ¶153, inherently corresponds to a higher priority (i.e., more efficient) than letting the robot search for the package when it arrives at that home}; and the delivery priority of the second unloading mode is higher than the delivery priority of the first unloading mode {user specifying exact location a package to be delivered at home, Figs. 30-31 and ¶153 (which describes both pick-up and delivery relative to Figs. 30-31), inherently corresponds to a higher priority (i.e., higher user satisfaction) than simply delivering to that home (address) and placing a package anywhere}.
Regarding Claim 5, Sibley discloses all the limitations of Claim 2, as discussed supra. In addition, Sibley explicitly recites the limitation: wherein: each of the plurality of delivery robots includes a plurality of storage compartments {robot 114 in Fig. 4, includes four storage compartments corresponding to four openings, covered by 4 separate doors} each having an adjustable volume {changing the size/proportion and/or adjusting the volume of a container, to deal with the different number of packages/articles, ¶125, is a prima facie case of obviousness under MPEP § 2144.04; in addition, ¶57 includes a container with a closable top, which inherently need not be closed all the way, thus enlarging the volume of the container}; the delivery demand information also includes cargo size information {plurality of packages/articles, ¶55 & ¶125}; and the server is further configured to, when determining the target delivery robot, determine, from the plurality of delivery robots, one delivery robot having one storage compartment that matches the cargo size information as the target delivery robot {matching load size with container size is described in ¶128}.
Regarding Claim 6, Sibley discloses all the limitations of Claim 2, as discussed supra. In addition, Sibley explicitly recites the limitations: wherein: the server is further configured to, when determining the target delivery robot, determine the target delivery robot from the plurality of delivery robots based on the delivery demand information and status information of each of the plurality of delivery robots {the determination/evaluation-step of which of multiple robots to send for a particular pick-up/delivery involves ranking factors, such as travel time for pick-up and delivery, battery life and robot location, ¶154 and ¶248}; the delivery demand information includes one or more of cargo size information {matching load size with container size is described in ¶128} and position information of at least one of a collection point or an unloading point associated with the delivery task {User selecting the pick-up/delivery location on a smartphone, Figs. 30-31, corresponding to deliverer computing device 141 communicating with platform server(s) 151 via cloud 172, Fig. 4 and ¶71}; and the status information of one delivery robot of the plurality of delivery robots includes one or more of[:] a volume of a vacant storage compartment in the one delivery robot {matching load size with container size is described in ¶128}, position information of the one delivery robot, and position information of at least one of a collection point or an unloading point of another delivery task that the one delivery robot needs to perform.
Regarding Claim 7, Sibley discloses all the limitations of Claim 1, as discussed supra. In addition, Sibley explicitly recites the limitations: wherein: the delivery task data packet includes position information of a plurality of path points including a collection point {the dotted-line delivery route in Fig. 1, is under the control of computer network 136, Fig. 4}, an unloading point {119, Fig. 1}, and one or more intermediate path points {all points along the dotted path in Fig. 1 between leaving deliveror 188 and arriving at deliveree 119, including crosswalks 107, Fig. 1} between the collection point {118, Fig. 1} and the unloading point {robot navigation to pick-up and deliver at different locations, continue on to an additional delivery, using any suitable route in the transportation network is described in ¶160-0161}; the delivery robot is further configured to, in response to detecting that one path point among the plurality of path points is unreachable {robot sensors detect and map the terrain it encounters, ¶65, and detect traffic conditions ¶173, which inherently can includes obstacles in the near vicinity, a construction zone, a road block, a traffic jam, etc., such that the elongated route in Fig. 1 corresponds to roadblock at crosswalk 107}, perform processing according to a temporary processing strategy {examiner interprets this to be a need to computationally determine a new route (i.e., rerouting) or perform specific robotic actions; re-routing by computer network 116, Fig. 4 and ¶68, is described in ¶173} corresponding to the one path point {intersection in Fig. 1, near deliveree 119, that dotted line route in Fig. 1 has avoided passing directly through}; and the plurality of path points belong to different categories {left-turn locations, right-turn locations, crosswalks, inherent doors at deliveror 118 and deliveree 119, Fig. 1, and the ability of the robot via a robotic-arm, ¶127, to navigate “an elevator, crosswalk light or traffic signal, to ring doorbells, to open doors, to activate handicapped access plates, to manipulate items, to perform tasks necessary or advisable during operation of the robot 114, or any combination the foregoing.”} and at least some of the different categories have different temporary processing strategies {an “anthropomorphic end effector” provides the ability to operate an elevator or open a door, ¶127 }.
Regarding Claim 8, Sibley discloses all the limitations of Claim 7, as discussed supra. In addition, Sibley explicitly recites the limitation: wherein the different categories include at least one of[:] a first category of intermediate path points at elevator {an “anthropomorphic end effector” provides the ability to operate an elevator or open a door, ¶127}, a category second of intermediate path points at access control, a third category of intermediate path points at gate, a fourth category of intermediate path points at parking lot, a fifth category of collection points with manned picking-up, a sixth category of unloading points of manned unloading, or a seventh category of unloading points of unmanned unloading.
Regarding Claim 9, Sibley discloses all the limitations of Claim 8, as discussed supra. In addition, Sibley explicitly recites the limitation: wherein the temporary processing strategies include at least one of: a first temporary processing strategy corresponding to the first category {navigating an elevator via the additional use of a robotic arm, ¶127} and including waiting for an elevator to open in a preset region {robot sensors in communication with robotic controlling computer network 116 (¶68), which includes computer vision (¶212), combined with the end-effector/robotic arm in ¶127, provide the robot with inherent ability to determine if elevator door is open or closed} including an intermediate path point {all points along the dotted path in Fig. 1 between leaving deliveror 188 and arriving to deliver to a package deliveree 119, which may inherently be inside the building, and involve navigating doors and elevators, ¶127} in the first category {an “anthropomorphic end effector” provides the ability to operate an elevator or open a door (for example, “pushing buttons”, ¶127}; a second temporary processing strategy corresponding to the second category and including waiting for an access control to open in a preset region including an intermediate path point in the second category; a third temporary processing strategy corresponding to the third category and including waiting for a gate to open at a spare path point close to the gate; a fourth temporary processing strategy corresponding to the fourth category and including: passing through a preset passage region including an intermediate path point in the fourth category; and in response to the preset passage region being occupied, waiting in place; a fifth temporary processing strategy corresponding to the fifth category and including stopping in a preset region around a collection point in the fifth category to reduce obstruction to normal traffic; a sixth temporary processing strategy corresponding to the sixth category and including stopping in a preset region around an unloading point in the sixth category to reduce obstruction to normal traffic; or a seventh temporary processing strategy corresponding to the seventh category and including placing a cargo at a spare unloading point near an unloading point in the seventh category.
Regarding Claim 10, Sibley discloses all the limitations of Claim 1, as discussed supra. In addition, Sibley explicitly recites the limitation: wherein: the delivery robot is one of a plurality of delivery robots of the system {fleet of vehicle/robots, ¶54}; and the server {computer network 136, Fig. 4} is further configured to coordinate passage of at least two delivery robots {navigation of robots by computer network 136 is described in ¶173, and includes taking into account factors such as traffic – which inherently includes robot traffic of the fleet of robots, ¶54, controlled by the computer network – and sensor input provided to the network from each robot} of the plurality of deliver robots {fleet of vehicle/robots, ¶54} in response to determining that each of the at least two delivery robots either: occupies a path point {individual points along the delivery route of a robot 114 in Fig. 4, represented by a dotted line} to be reached by another of the at least two delivery robots {the transfer of articles from a first to a second robot, described in ¶206, inherently involves coordinated driving instructions to enable the robots to end up at the same general location – without interfering with each other’s travel route due to network control, ¶173 – and to be positioned next to each other to perform a container/article transfer, comparable to that represented in Fig. 34}, or has a path point to be reached occupied by another of the at least two delivery robots.
Regarding Claim 11, Sibley discloses all the limitations of Claim 10, as discussed supra. In addition, Sibley explicitly recites the limitation: wherein the server is further configured to, when coordinating the passage of the two delivery robots: determine a passage coordination strategy {navigation of robots by computer network 136 is described in ¶173, and includes taking into account factors such as traffic – which inherently includes robot traffic of the fleet of robots, ¶54, controlled by the computer network – and sensor input provided to the network from each robot} according to a number of delivery robots {interpreted as two or more robots or a fleet of vehicle/robots discussed in ¶54} that are able to be accommodated in a region corresponding to an occupied path point {with regard to Fig. 34 (which is comparable to the package transfer between two robot described in ¶206, since pickup container 116 if fully automated for package transfer), pickup container 116 occupies a ”path point” and robot 114 is the only additional robot that can be accommodated at that location to successfully complete a package transfer}.
Regarding Claim 12, Sibley discloses all the limitations of Claim 11, as discussed supra. In addition, Sibley explicitly recites the limitation: wherein the passage coordination strategy {the transfer of articles from a first to a second robot is described in ¶206 and inherently involves coordinated driving instructions (under the control of computer network 136, ¶173) to enable the robots to end up at the same location to be able to perform a container/article transfer, comparable to that represented in Fig. 34} includes at least one of[:] order of the at least two delivery robots reaching the occupied path point or one or more path points where any one of the at least two delivery robots temporarily stops {with regard to Fig. 34 (which is comparable to the package transfer between two robot described in ¶206, since pickup container 116 if fully automated for package transfer), pickup container 116 occupies one ”path point” and robot 114 occupies a second “path point”, with both being stationary to perform the package transfer}.
Regarding Claim 13, Sibley discloses all the limitations of Claim 11, as discussed supra. In addition, Sibley explicitly recites the limitation: wherein a collection point in the first collection mode includes a smart container collection point {automated pickup container 116 in Fig. 34, which includes the automated door mechanism of ¶116} or another collection point other than the smart container collection point, and an unloading point in the first unloading mode includes a smart container unloading point {automated pickup container 116 in Fig. 34, is both a pickup point and a drop-off point that requires no human intervention, ¶62} or another unloading point other than the smart container unloading point.
Regarding Claim 14, Sibley discloses all the limitations of Claim 1, as discussed supra. In addition, Sibley explicitly recites the limitations: wherein a collection point in the second collection mode includes a mailroom collection point {mailbox in Fig. 3; pick-up and drop-off locations mentioned in ¶62, including a mailbox} or another collection point other than the mailroom collection point {pick-up and drop-off locations, ¶62}, and an unloading point in the second unloading mode {door requiring manual operation in Fig. 26 and ¶117} includes a mailroom unloading point or another unloading point other than the mailroom unloading point {various pick-up and drop-off locations mentioned in ¶62, including a mailbox}.
Regarding Claim 15, Sibley discloses all the limitations of Claim 1, as discussed supra. In addition, Sibley explicitly recites the limitations: wherein: the delivery robot includes a plurality of storage compartments each including: a first opening; a second opening {robot 114 in Fig. 4, includes four storage compartments corresponding to four openings, covered by 4 separate doors}; a first type of cover member configured to open or close the first opening at a first speed {segmented, sliding door Fig. 26, manually operated, ¶117}; and a second type of cover member configured to open or close the second opening {¶111 allows for any suitable covering of opening (i.e., door), which can be an automated door mechanism, ¶116}, at a second speed lower than the first speed {manual operation of a door/cover, ¶117, will inherently be at a different speed than an automated door mechanism, ¶116}.
Regarding Claim 16, Sibley discloses all the limitations of Claim 15, as discussed supra. In addition, Sibley explicitly recites the limitations: wherein the delivery robot is further configured to: drive {door opening mechanism, ¶114, being automated ¶116-0117} the first type of cover member {door covering(s) discussed in ¶111} in response to: a collection point in the second collection mode being a mailroom collection point or an unloading point in the second unloading mode being a mailroom unloading point {different pick-up and drop-off locations mentioned, including a mailbox, ¶62}, and the at least one of the target collection mode or the target unloading mode being input by a user {user input, Figs. 30-31} having a specified authority {user authorization needed, ¶166}; and drive the second type of cover member {allowing for any suitable type of door opening, ¶114, and being automated ¶116-0117} in response to: the collection point being not a mailroom collection point, the unloading point being not a mailroom unloading point {different pick-up and drop-off locations mentioned, including the side of a building, ¶62}, or the at least one of the target collection mode or the target unloading mode being input by a user {user input, Figs. 30-31} not having the specified authority {computer network provides access code to user to allow access to container for depositing or removing package/article , ¶166}.
Regarding Claim 18, Sibley discloses all the limitations of Claim 15, as discussed supra. In addition, Sibley explicitly recites the limitations: the delivery robot is provided with a camera {“The computer-executable instructions can be configured to operate on a smartphone and receive the photograph from a camera on the smartphone”, ¶256}; and the delivery robot is further configured to: when picking up a cargo in the first collection mode, turn on the camera to record video {storing images/video, ¶133} after arriving at a collection point {computer vision to aid determination of the correct location, ¶212, wherein the images provided can be picture or video, ¶256} until the cargo is collected {a computer network (136, Fig. 4) records delivery of the article, ¶202, which given the delivery robot computer (156, Fig. 4) includes one or more cameras (¶68), the recordation of the delivery can be video based, since video/imaging is already in use to correctly identify the location, ¶212}; or when unloading the cargo in the first unloading mode, turn on the camera to record video {storing images/video, ¶133} after arriving at an unloading point {computer vision to aid determination of the correct location, ¶212, wherein the images provided can be picture or video, ¶256}until the cargo is unloaded {a computer network (136, Fig. 4) records delivery of the article, ¶202, which given the delivery robot computer (156, Fig. 4) includes one or more cameras (¶68), the recordation of the delivery can be video based, since video/imaging is already in use to correctly identify the location, ¶212}.
Regarding Claim 19, Sibley discloses the limitations: a robot delivery method {robot instructed to pick up package, Abstract} comprising: receiving delivery demand information {receiving delivery/pick-up request, ¶227} including at least one of a target collection mode or a target unloading mode {cellphone used to identify delivery/pick-up location, Figs. 30-31 and ¶133}; and generating a delivery task data packet {cloud 172 inherently provides an internet protocol (i.e., packet-based) communication network between robot computer 156 and platform server(s) 151, Fig. 4 and ¶67} according to the delivery demand information {communication of delivery and/or pick-up instructions, ¶71}; to enable a delivery robot {robot 114, Figs. 5-6} to perform a delivery task according to the delivery task data packet {computer network provides delivery and/or pick-up instructions and directions to robot, ¶213}; wherein: the target collection mode is selected from a plurality of collection modes including: a first collection mode {Figs. 32-33 shows robot 114 gathering a container from the ground} in which the delivery robot performs cargo collection without user participation {¶163 describes a robot using an object, like a step, to aid in picking up a container/package unaided otherwise}; and a second collection mode {above ground level container/parcel/package pickup, such as from a mailbox, Fig. 3} in which the delivery robot performs cargo collection with user participation {user has placed transportation container 361 in above ground container/compartment 115, Fig. 3}; and the target unloading mode is selected from a plurality of unloading modes including: a first unloading mode {dropping off package at ground-level on stair-type step, as represented in Fig. 43} in which the delivery robot performs cargo unloading without user participation {robot delivers package unaided, leaving it on an step, Fig. ¶215}; and a second unloading mode {delivery by robot to a substantially elevated site, be it mailbox container 115 in Fig. 3; a picnic table Figs. 46-47, see ¶218; or pickup container 116 in Fig. 34} in which the delivery robot performs cargo unloading with user participation {delivery by robot with or without human assistance described in ¶175, which is comparable to the user retrieving the package from a picnic table, Fig. 47, or the robot handing the package directly to the recipient}.
Regarding Claim 20, Sibley discloses the limitations: a robot delivery method {robot instructed to pick up package, Abstract} comprising: receiving a delivery task {receiving delivery/pick-up request, ¶227} data packet { cloud 172 inherently provides an internet protocol (i.e., packet-based) communication network between robot computer 156 and platform server(s) 151, Fig. 4 and ¶67} generated according to delivery demand information {communication of delivery and/or pick-up instructions, ¶71} including at least one of a target collection mode or a target unloading mode {cellphone used to identify delivery/pick-up location, Figs. 30-31 and ¶133}; and performing a delivery task according to the delivery task data packet {computer network provides delivery and/or pick-up instructions and directions to robot, ¶213}; wherein: the target collection mode is selected from a plurality of collection modes including: a first collection mode {Figs. 32-33 shows robot 114 gathering a container from the ground} in which the delivery robot performs cargo collection without user participation {¶163 describes a robot using an object, like a step, to aid in picking up a container/package unaided otherwise}; and a second collection mode {above ground level container/parcel/package pickup, such as from a mailbox, Fig. 3}
in which the delivery robot performs cargo collection with user participation {user has placed transportation container 361 in above ground container/compartment 115, Fig. 3}; and the target unloading mode is selected from a plurality of unloading modes including: a first unloading mode {dropping off package at ground-level on stair-type step, as represented in Fig. 43} in which the delivery robot performs cargo unloading without user participation {robot delivers package unaided, leaving it on an step, Fig. ¶215}; and a second unloading mode {delivery by robot to a substantially elevated site, be it mailbox container 115 in Fig. 3; a picnic table Figs. 46-47, see ¶218; or pickup container 116 in Fig. 34} in which the delivery robot performs cargo unloading with user participation {delivery by robot with or without human assistance described in ¶175, which is comparable to the user retrieving the package from a picnic table, Fig. 47, or the robot handing the package directly to the recipient}.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 17 is rejected under 35 U.S.C. §103 as being unpatentable over the combination of Sibley and Javidan et al. (US 2021/0256472 A1, henceforth Javidan).
Regarding Claim 17, Sibley discloses all the limitations of Claim 1, as discussed supra. Sibley does not appear to explicitly recite the limitations: wherein the delivery robot is further configured to: execute the delivery task again according to the second unloading mode in response to failing to unload in the second unloading mode for a first time; and execute the delivery task according to the first unloading mode in response to failing to unload in the second unloading mode for at least twice in a row.
However, Javidan explicitly recites the limitation: wherein the delivery robot {1, Fig. 1} is further configured to: execute the delivery task again according to the second unloading mode in response to failing to unload in the second unloading mode for a first time {delivery-item recipient fails to pick up item within a designated time periods, and the delivery system arranges with them to pick-up the item at a different location and time, ¶101 & ¶140}; and execute the delivery task according to the first unloading mode in response to failing to unload in the second unloading mode for at least twice in a row {the item is dropped-off at a retail location, where the recipient can pick-up it up at their convenience, when the delivery vehicle is elsewhere, ¶141}.
Sibley and Javidan are analogous art because they both deal with parcel pick-up and delivery using unmanned vehicles.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Sibley and Javidan before them, to modify the teachings of Sibley to include the teachings of Javidan to improve delivery efficiency and recipient convenience {¶24}.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 2024/0174464 A1 – Teaches of an delivery system comprising a driver operated delivery truck with an autonomous robot collecting the package from inside the truck and delivering to, for example, the front door-step of a home.
US 12,387,544 B2 – Teaches of autonomous package-retrieval-and-delivery robots, including robot-to-robot package transfer, and robotic delivery of a package to a person, who places the package in a secure storage area; or wherein the robot directly delivers the package to a storage area (such as an individual compartment in a multi-compartment storage locker).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD EDWIN GEIST whose telephone number is (703)756-5854. The examiner can normally be reached Monday-Friday, 9am-6pm.
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, Christian Chace can be reached at (571) 272-4190. 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.
/R.E.G./Examiner, Art Unit 3665
/CHRISTIAN CHACE/Supervisory Patent Examiner, Art Unit 3665
Prosecution Insights