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 .
Status of Claims
This action is in reply to the amendment filed 4 April 2026.
Claims 1-9 and 18-20 have been amended and are hereby entered.
Claims 15-17 and 21-25 have been canceled.
Claims 1-14 and 18-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 13 February 2026 has been considered by the examiner and an initialed copy of the IDS is hereby attached.
Response to Amendments and Remarks
Claim Objections
Claims 4 was objected to because of informalities. Applicant has amended the claims to overcome or render moot each of the objections. Accordingly, the objection of claims 4 has been withdrawn.
Claim Rejections - 35 USC § 112
Claims 2-9 and 18-20 were rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The Applicant has amended the claims to overcome or render moot most of the rejections under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. Accordingly, the rejection of claims 2-9 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, has been withdrawn. However, the rejection of claims 18-20 is maintained as explained below.
Claim Rejections - 35 USC §§ 102 and 103
Claim(s) 1-3, 6-7, 10-14 and 18 were rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ota et al. US Pub. No. 2012/0029697, hereinafter “Ota”).
Claim(s) 4-5 were rejected under 35 U.S.C. 103 as being unpatentable over Ota in view of Kasperski III US Pub. No. 2020/0025574, hereinafter Kasperski”).
Claim(s) 8-9 and 19-20 were rejected under 35 U.S.C. 103 as being unpatentable over Ota in view of Wurman et al. (US Pub. No. 2015/0066283, hereinafter “Wurman”).
Applicant’s arguments, see pages 10, filed 4 April 2026, with respect to the rejection(s) of claim(s) 1-3, 6-7, and 10-14 under 35 U.S.C. 102 have been fully considered, but they are not persuasive.
Applicant’s arguments, see pages 10, filed 4 April 2026, with respect to the rejection(s) of claim(s) 18 under 35 U.S.C. 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Wurman, already of record.
Returning to Applicant’s arguments regarding the rejection of claim(s) 1-3, 6-7, and 10-14 under 35 U.S.C. 102, that were not found persuasive, the Applicant argues:
In response to the claim rejections under 35 U.S.C. § 102(a)(1) based on Ota, as currently amended, the independent claims require a server-mediated, identity- centric dispatch workflow that Ota does not disclose. Ota does not disclose server- received coupling request carrying device identity information, server-side fleet selection/dispatch of a designated transportation device, and server-side matching of a read identification code to device identity information from that request prior to engagement. The claims also recite a pre-engagement target rendezvous location tied to the request, whereas Ota focuses on post-engagement delivery.
The examiner respectfully disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e. Server-received coupling request and server-side matching) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Accordingly, this argument is not persuasive.
Applicants arguments regarding claim 4-5 rely upon the purported deficiencies of Ota addressed above.
Applicants arguments regarding the rejection of claims 8-9 and 19-20 also rely upon the purported deficiencies of Ota addressed above, however the further argue:
. Wurman's management module selects devices and plans routes for transporting people in a workspace and manages protected areas and docking alignment. It does not teach receiving a coupling request naming a third-party movable device by identity, server-side selection/dispatch of a designated transportation device to couple and tow that device, or server-side identity matching prior to engagement. Wurman and Ota, therefore, either alone or in combination with the other prior art of record, do not teach or fairly suggest the identity-based authentication and dispatch workflow of claims 8-9 and 19-20.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e. a coupling request naming a third-party movable device by identity, server-side selection/dispatch of a designated transportation device to couple and tow that device, or server-side identity matching prior to engagement) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Accordingly, this argument is not persuasive.
Wurman is relied upon to show the server-side selection and dispatch of a transport device as addressed in the updated rejection below.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 18-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 18 recites “receiving, at a server, a coupling request comprising location information and device identity information of the movable device” and further recites “wherein the transportation device comprises…a receiver configured to receive a coupling request comprising location information and device identity information” It is not clear whether the server receives the coupling request or the receiver of the transportation device receives the coupling request.
Claim 18 recites “a coupling request” in line 15. Claim 18 previously recited “a coupling request” in line 3. It is not clear if the coupling request of line 15 is the same or different than that recited in line 3. Further it is not clear if the coupling request of line 15 includes the same or different location information and device identity information. Further, line 18 of the claim recites “a location indicated by the location information”. It is not clear if the location is based on the location information received by the server or by the receiver.
Claim 18 recites “authenticating the movable device based on the device identity information in the coupling request;” in line 10-11 and “an authentication module configured to authenticate a movable device at the target rendezvous location based on the device identity information in the received coupling request;” in lines 24-26. First, it is not clear if the movable device of line 24-26 is the same or different than that of lines 10-11. Further, as written, it is not clear if the server performs the authentication or the transportation device performs the authentication. It appears that the authentication of the mobile device is performed by the transportation device however by reciting a new mobile device in lines 24-26 a lack of clarity is introduced in the process.
Claims 19-20 depend from claim 18 and are similarly rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, based on their dependency on claim 18.
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 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.
Claim(s) 1-3, 6-7, and 10-14 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ota et al. US Pub. No. 2012/0029697, hereinafter “Ota”).
Regarding claim 1, Ota discloses a transportation device comprising:
a receiver configured to receive a coupling request comprising location information and device identity information (see at least Ota, Figure 2 and 6, wireless communications device 160. See at least Ota [0006] “In yet another embodiment, a wheeled device transportation system includes a wireless communications network, a central server communicatively coupled to the wireless network, a radio frequency identification tag, and a robotic transportation device. The central server may provide navigation data over the wireless communications network. The target device has two wheels and a radio frequency identification tag configured to emit an identification signal. The robotic transportation device may include a device body having at least one motorized wheel coupled to a drive motor, two docking arms, a wireless communications device, and a controller module. Each docking arm may include a support wheel and an adjustable wheel locking device, and may extend horizontally from the device body and may be adjustable along at least two directions. The wireless communications device is communicatively coupled to the wireless communications network. The wireless communications device further detects a location of the robotic transportation device, provides proximity data corresponding to the location of the robotic transportation device, and wirelessly receives navigational data over the wireless communications network emitted by the central server. The controller module may include a processor and a computer readable memory having executable instructions. The controller module is electrically coupled to the wireless communications device and the device detection module. The controller module may receive the proximity data and the navigational data from the wireless communications device, detect a device type of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously approach a target device. The drive signal may be based at least in part on the proximity data and the navigational data. The controller module may further control the docking arms in accordance with the device type to engage the adjustable wheel locking devices with the wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously tow the target device to a desired location.”)
a mobility mechanism configured to drive the transportation device to target rendezvous location identified in the location information of the received coupling request (see at least Ota Figures 1-2, motorized wheels 112, drive motor 113, See at least [0022] “The device body 110 comprises a body housing 111, which may be made of a metal or plastic material, and a pair of motorized wheels 112 that are coupled to a drive motor 113 that is positioned within the body housing 111. In another embodiment, more than two motorized wheels may be utilized. Alternatively, a single motorized wheel may be utilized. For example, a single motorized wheel may be used in conjunction with non-motorized wheels (not shown) to move the robotic transportation device 100. The drive motor may be an electric motor that is powered by one or more rechargeable batteries (not shown). The motorized wheels 112 and drive motor 113 may be responsive to drive signals provided by a controller module 140 (FIG. 2), as described in more detail below.”)
an authentication module configured to authenticate a movable device at the target rendezvous location based on the device identity information in the received coupling request (see at least Ota, Figure 6, device detection module 170 and [0038-0040] “Once the robotic transportation device 100 is located near the target device, it may detect the position and type of target device. Referring to FIG. 8, a hospital bed 200 is illustrated. The hospital has a frame 212 on which two device tags 220 may be positioned. Alternatively, there may be only one device tag 220 or no device tag positioned on the target device. The device tags 220 may be RFID tags that transmit a wireless identification signal indicative of the type of target device. The RFID signal may be detected by the wireless communications device 160 in one embodiment. In another embodiment, the RFID signal or other target device signal may be detected by a device detection module 170. The device detection module 170, or the wireless communications device 160 may be equipped with a radio frequency receiver capable of receiving the radio frequency signal from the device tags 220. The device tags 200 (or single device tag) may be configured as other wireless devices capable of transmitting an identification signal, such as infrared signals, or WiFi signals, for example…[0039] The identification signal may provide or otherwise indicate device data associated with the particular target device. The device data may be provided to the controller module 140 by the device detection module 170. In an alternative embodiment, the controller module 140 may receive or determine the device data. The device data may include the make and model of the target device, the overall dimensions of the target device, position of the target device wheels, etc. From the device data, the controller module 140 may determine the type of target device (e.g., a hospital bed)…”); and
a coupler selectively engageable with the movable device based on the authentication (see at least Ota, Figure 1 and 9, docking arms 120. See also [0006] “The controller module is electrically coupled to the wireless communications device and the device detection module. The controller module may receive the proximity data and the navigational data from the wireless communications device, detect a device type of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously approach a target device. The drive signal may be based at least in part on the proximity data and the navigational data. The controller module may further control the docking arms in accordance with the device type to engage the adjustable wheel locking devices with the wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously tow the target device to a desired location.” See also [0041] “Still referring to FIG. 8, the device data may indicate to the robotic transportation device 100 that the hospital bed 200 has two target device wheels 210 having a particular diameter that are separated by a distance d. The controller module 140 may adjust the docking arms 120 and associated wheel adjustable wheel locking devices 125 in accordance with the type of target device. Also referring to FIGS. 1-7, the controller module 140 may provide drive signals to the length adjustment actuator 150, the wheel stop actuator 152, the docking arm actuator 154, and the vertical actuator 156 to prepare the robotic transportation device 100 for docking with the target device (e.g., hospital bed 200). For example, the docking arms 120 may be lowered and positioned such that the adjustable wheel locking devices 125 are substantially aligned with the target device wheels 210. The docking arms 120 may be moved along direction A so that the adjustable wheel locking devices 125 are separated by a distance d in accordance with the distance d between the target wheels 210.”),
wherein on the selective engagement of the coupler with the movable device, movement of the transportation device correspondingly moves the movable device (see at least Ota [005] “The executable instructions may further cause the controller module to receive the device data from the device detection module to determine a device type of the target device, control docking arms to engage the adjustable wheel locking devices with wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously travel to a second destination associated with the second destination input signal. The drive signal may be based at least in part on a navigation route calculated from the proximity data and the navigational data.” See also [0045] “The robotic transportation device 100 then autonomously navigates throughout the facility to deliver the target device to the desired location. The robotic transportation device 100 tows the target device to the desired location. The target devices remaining unlocked wheels enable it to be towed by the robotic transportation device. For example, the unlocked wheels 330 of the wheels chair 300 (FIG. 9), the unlocked wheels 430 of the patient lift 400 (FIG. 10), and the unlocked wheels 220 of the hospital bed 220 (FIGS. 8 and 11) are free to rotate as the respective target device is towed.” See also [0006] “The controller module may further control the docking arms in accordance with the device type to engage the adjustable wheel locking devices with the wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously tow the target device to a desired location.” ).
Regarding claim 2, Ota discloses the transportation device of claim 1, further comprising:
a navigation module configured to determine a travel route for the transportation device to reach the target rendezvous location identified in the coupling request (see at least Ota See at least [0036] “Once the robotic transportation device 100 receives the first and second destination input signals, the position of the robotic transportation device 100 may be determined and a navigation route determined by the controller module 140 and/or the central server 172.” See also [0033] ”The robotic transportation device 100 may determine its location within the area. In one embodiment, a plurality of local position tags 174 (FIG. 6) may be located throughout a facility (e.g., a floor or ward of a hospital). The local position tags 174 may be located on walls, obstacles (e.g., desks, nurses stations, chairs, etc.) or other locations. The local position tags 174 may emit a wireless location signal that is uniquely addressed. The wireless communications device 160 (and controller module 140) may receive the wireless signals as proximity data from the local position tags 174. The proximity data corresponding to the signals from the local position tags 174 may be provided to the controller module 140. The controller module 140 may use the proximity data to determine a position of the robotic transportation device 100 within the facility. The position may then be used to navigate the robotic transportation device 100 throughout the facility in accordance with a calculated navigation route. The navigation route may be calculated by the controller module 140 or the central server 172. The local position tags 174 may define portions of the area that are restricted to prevent the robotic transportation device from entering such areas. Infrared and/or ultrasonic sensors may also be used for collision avoidance. See also Ota [0044] The robotic transportation device 100 may determine its location with proximity data as described above and calculate a navigation route to the desired destination corresponding to the second destination input signal. The navigation route may be based on the navigation data, the proximity data, the dimensions of the robotic transportation device 100 and the target device. See also Ota [0005] ).
Regarding claim 3, Ota discloses the transportation device of claim 2, wherein the mobility mechanism is configured to drive the transportation device to the target rendezvous location identified in the coupling request in accordance with the determined travel route (see at least Ota [0036] “Once the robotic transportation device 100 receives the first and second destination input signals, the position of the robotic transportation device 100 may be determined and a navigation route determined by the controller module 140 and/or the central server 172.” See also Ota [0044-0045] The robotic transportation device 100 may determine its location with proximity data as described above and calculate a navigation route to the desired destination corresponding to the second destination input signal. The navigation route may be based on the navigation data, the proximity data, the dimensions of the robotic transportation device 100 and the target device…. [0045] The robotic transportation device 100 then autonomously navigates throughout the facility to deliver the target device to the desired location. The robotic transportation device 100 tows the target device to the desired location.).
Regarding claim 6, Ota discloses the transportation device of claim 2, wherein the navigation module is configured to receive sensor data, and to determine the travel route based on the sensor data
wherein the navigation module is configured to receive updated sensor data and further configured to adapt the travel route based on the updated sensor data (see at least Ota [0033] “The robotic transportation device 100 may determine its location within the area. In one embodiment, a plurality of local position tags 174 (FIG. 6) may be located throughout a facility (e.g., a floor or ward of a hospital). The local position tags 174 may be located on walls, obstacles (e.g., desks, nurses stations, chairs, etc.) or other locations. The local position tags 174 may emit a wireless location signal that is uniquely addressed. The wireless communications device 160 (and controller module 140) may receive the wireless signals as proximity data from the local position tags 174. The proximity data corresponding to the signals from the local position tags 174 may be provided to the controller module 140. The controller module 140 may use the proximity data to determine a position of the robotic transportation device 100 within the facility. The position may then be used to navigate the robotic transportation device 100 throughout the facility in accordance with a calculated navigation route. The navigation route may be calculated by the controller module 140 or the central server 172. The local position tags 174 may define portions of the area that are restricted to prevent the robotic transportation device from entering such areas. Infrared and/or ultrasonic sensors may also be used for collision avoidance. The robotic transportation device 100 may also use other methods of determining a location within the facility, such as a global position system, for example.” ), and
wherein the sensor data is provided in real-time (see at least Ota [0033] as cited above as the data is updated as the vehicle travels).
Regarding claim 7, Ota discloses the transportation device of claim 1, wherein the authentication module is configured to authenticate the movable device by reading an identification code provided on the movable device and matching the read identification code to the device identity information in the received coupling request (see at least Ota [0038-0039] “Once the robotic transportation device 100 is located near the target device, it may detect the position and type of target device. Referring to FIG. 8, a hospital bed 200 is illustrated. The hospital has a frame 212 on which two device tags 220 may be positioned. Alternatively, there may be only one device tag 220 or no device tag positioned on the target device. The device tags 220 may be RFID tags that transmit a wireless identification signal indicative of the type of target device. The RFID signal may be detected by the wireless communications device 160 in one embodiment. In another embodiment, the RFID signal or other target device signal may be detected by a device detection module 170. The device detection module 170, or the wireless communications device 160 may be equipped with a radio frequency receiver capable of receiving the radio frequency signal from the device tags 220. The device tags 200 (or single device tag) may be configured as other wireless devices capable of transmitting an identification signal, such as infrared signals, or WiFi signals, for example….[0039] The identification signal may provide or otherwise indicate device data associated with the particular target device. The device data may be provided to the controller module 140 by the device detection module 170. In an alternative embodiment, the controller module 140 may receive or determine the device data. The device data may include the make and model of the target device, the overall dimensions of the target device, position of the target device wheels, etc. From the device data, the controller module 140 may determine the type of target device (e.g., a hospital bed).”).
Regarding claim 10, Ota discloses the transportation device of claim 1, wherein the coupling request further comprises destination information, and
wherein the mobility mechanism is further configured to drive the transportation device to a destination location indicated by the destination information, in response to the coupler being engaged with the movable device (see at least Ota [0036] “Once the robotic transportation device 100 receives the first and second destination input signals, the position of the robotic transportation device 100 may be determined and a navigation route determined by the controller module 140 and/or the central server 172.” See also Ota [0044-0045] The robotic transportation device 100 may determine its location with proximity data as described above and calculate a navigation route to the desired destination corresponding to the second destination input signal. The navigation route may be based on the navigation data, the proximity data, the dimensions of the robotic transportation device 100 and the target device…. [0045] The robotic transportation device 100 then autonomously navigates throughout the facility to deliver the target device to the desired location. The robotic transportation device 100 tows the target device to the desired location.).
Regarding claim 11, Ota discloses the transportation device of claim 10, wherein the coupler is configured to disengage from the movable device in response to the transportation device having reached the destination location (see at least Ota [0046] “When at the desired location (i.e., the destination), the robotic transportation device 100 may provide an audible or visual alert to nearby personnel that it has made the delivery. The device 100 may wait to have personnel uncouple the target device, or the instructions may be that the device 100 is to operate the docking arms 120 and the adjustable wheel locking devices 125 to autonomously decouple the target device. For example, the docking arms 120 may be lowered, the wheel stops 126a, 126b opened, and then the docking arms 120 slid from beneath the target wheels.”).
Regarding claim 12, Ota discloses the transportation device of claim 1, wherein the receiver is configured to receive the coupling request from a server ((see at least Ota, Figure 2 and 6, wireless communications device 160. See at least Ota [0006] “In yet another embodiment, a wheeled device transportation system includes a wireless communications network, a central server communicatively coupled to the wireless network, a radio frequency identification tag, and a robotic transportation device. The central server may provide navigation data over the wireless communications network. The target device has two wheels and a radio frequency identification tag configured to emit an identification signal. The robotic transportation device may include a device body having at least one motorized wheel coupled to a drive motor, two docking arms, a wireless communications device, and a controller module. Each docking arm may include a support wheel and an adjustable wheel locking device, and may extend horizontally from the device body and may be adjustable along at least two directions. The wireless communications device is communicatively coupled to the wireless communications network. The wireless communications device further detects a location of the robotic transportation device, provides proximity data corresponding to the location of the robotic transportation device, and wirelessly receives navigational data over the wireless communications network emitted by the central server. The controller module may include a processor and a computer readable memory having executable instructions. The controller module is electrically coupled to the wireless communications device and the device detection module. The controller module may receive the proximity data and the navigational data from the wireless communications device, detect a device type of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously approach a target device. The drive signal may be based at least in part on the proximity data and the navigational data. The controller module may further control the docking arms in accordance with the device type to engage the adjustable wheel locking devices with the wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously tow the target device to a desired location.”)
Regarding claim 13, Ota discloses the transportation device of claim 1,
wherein the coupler is selectively engageable with any one movable device of a plurality of movable devices (see at least Ota Figures 9-11 and [0043] “ FIGS. 9-11 illustrate a target device of varying configurations wherein the target wheels are engaged with and locked by the adjustable wheel locking devices. FIG. 9 illustrates a wheel chair 300 having target wheels 310 that are held in place by the wheel stops 126a, 126b. The unlocked wheels 330 are free to rotate while the wheel chair 300 is being towed by the robotic transportation device 100. As illustrated in FIG. 9, a person 320 may be sitting in the wheel chair 300 as it is towed. FIG. 10 illustrates target wheels 410 of a lift device 400 in a locked position. The remaining wheels 430 are free to rotate. FIG. 11 depicts a person 225 lying on a hospital bed 200 that is coupled to a robotic transportation device 100. The target wheels 210 are maintained by the adjustable wheel locking devices 125 and the remaining wheels are free to rotate during transportation.”, and
wherein each movable device of the plurality of movable devices has a unique identification code readable by the authentication module (see at least Ota [0038-0039] “Once the robotic transportation device 100 is located near the target device, it may detect the position and type of target device. Referring to FIG. 8, a hospital bed 200 is illustrated. The hospital has a frame 212 on which two device tags 220 may be positioned. Alternatively, there may be only one device tag 220 or no device tag positioned on the target device. The device tags 220 may be RFID tags that transmit a wireless identification signal indicative of the type of target device. The RFID signal may be detected by the wireless communications device 160 in one embodiment. In another embodiment, the RFID signal or other target device signal may be detected by a device detection module 170. The device detection module 170, or the wireless communications device 160 may be equipped with a radio frequency receiver capable of receiving the radio frequency signal from the device tags 220. The device tags 200 (or single device tag) may be configured as other wireless devices capable of transmitting an identification signal, such as infrared signals, or WiFi signals, for example….[0039] The identification signal may provide or otherwise indicate device data associated with the particular target device. The device data may be provided to the controller module 140 by the device detection module 170. In an alternative embodiment, the controller module 140 may receive or determine the device data. The device data may include the make and model of the target device, the overall dimensions of the target device, position of the target device wheels, etc. From the device data, the controller module 140 may determine the type of target device (e.g., a hospital bed).”)
Regarding claim 14, Ota discloses the transportation device of claim 1, wherein the coupler is further selectively engageable with a further transportation device (see at least Ota Figures 9-12 wherein the coupler 120 is capable of being selectively engageable with any device including a transportation device. For example, see at least description in [0028] wherein the coupler includes a wheel lock for a target device which could be a further transportation device. See also at least Fig. 1, 4 and 5 and [0018-0019] and [0030-0031] which discloses a further transportation device coupled to the movable device and the communication device communication with a further transportation device. See also [0048]).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 4-5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ota in view of Kasperski III US Pub. No. 2020/0025574, hereinafter Kasperski”).
Regarding claim 4, Ota discloses the transportation device of claim 2, including wherein the navigation module is configured to navigation data, and is further configured to determine the travel route based on the navigation data (see at least Ota [0006] “The central server may provide navigation data over the wireless communications network.” and [0037] “A navigation route may be determined based on the destination input signals, the proximity data (i.e., the current location of the robotic transportation device 100), and the navigation data.” See also [0032] “:The wireless signals may also correspond with navigation data received from a central server 172 that is also communicatively coupled to the wireless communications network. The wireless communications device 160 may also transmit wireless signals to the central server 172 and other device to navigate within the area.”), however Ota does not explicitly teach wherein the navigation data is map data. Kasperski teaches wherein the navigation data is map data from a server (see at least Kasperski [0023-0026] [0023] In response to requests for autonomous or semi-autonomous functions, processor 201 may utilize navigational data indicating routes within the environment that are navigable by the associated PMD. Navigational data may comprise map data defining roadways or walkways navigable by the PMD. The map data may define fixed-obstacles that may impede the PMD during navigation. Fixed-obstacles may be artificial, such as buildings, walls, fountains, sculptures, curbs, barricades, areas of insufficient overhead clearance, or other structures that impede or prevent movement of the PMD. Fixed-obstacles may be natural, such as rocks, trees, or bushes. The examples of fixed-obstacles listed herein are provided by way of example and not limitation..”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Ota with the teaching Kasperski, with a reasonable expectation of success, because as Kasperski teaches the map data provides data to determine areas navigable by the personal mobility device (PMD) (see at least Kasperski [0023]).
Regarding claim 5, the combination of Ota and Kasperski teach Ota discloses the transportation device of claim 4, wherein the navigation module is further configured to download further map data from a cloud-based server and further configured to update the map data based on the downloaded further map data, wherein the further map data comprises crowd-sourced information (see at least Ota [0032] wherein further map data is downloaded from a server. [0032] “The wireless signals may also correspond with navigation data received from a central server 172 that is also communicatively coupled to the wireless communications network. The wireless communications device 160 may also transmit wireless signals to the central server 172 and other device to navigate within the area.”), also Kasperski [0024] “In some embodiments, navigational data, including any associated map data, may be stored by internal data store 203.” And Figure 2 and [0026] “In the depicted embodiment, wireless connectivity interface 217 provides data communication between processor 201 and an external data source 219. External data source 219 may provide a source of navigational data instead or in addition to navigational data being provided by internal data store 203. In some embodiments, external data source 219 may comprise a database of navigational data that may acquire data from one or more PMDs during navigation in order to compile a history of navigational data for utilization in a machine-learning algorithm.).
Claim(s) 8-9 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ota in view of Wurman et al. (US Pub. No. 2015/0066283, hereinafter “Wurman”).
Regarding claim 8, Ota discloses the transportation device of claim 1, further comprising at least one of:
an object detector configured to detect the movable device, wherein the mobility mechanism is further configured to position the transportation device adjacent to the detected movable device, for the coupler to engage with the detected movable device (see at least Ota [0040-0042] [0040] “The device detection module 170 may also be a visual module such as a camera device. The camera device may take a digital image of the target device, which is provided to the controller module 140…[0041] Still referring to FIG. 8, the device data may indicate to the robotic transportation device 100 that the hospital bed 200 has two target device wheels 210 having a particular diameter that are separated by a distance d. The controller module 140 may adjust the docking arms 120 and associated wheel adjustable wheel locking devices 125 in accordance with the type of target device. Also referring to FIGS. 1-7, the controller module 140 may provide drive signals to the length adjustment actuator 150, the wheel stop actuator 152, the docking arm actuator 154, and the vertical actuator 156 to prepare the robotic transportation device 100 for docking with the target device (e.g., hospital bed 200). For example, the docking arms 120 may be lowered and positioned such that the adjustable wheel locking devices 125 are substantially aligned with the target device wheels 210. The docking arms 120 may be moved along direction A so that the adjustable wheel locking devices 125 are separated by a distance d in accordance with the distance d between the target wheels 210. Further, the wheel stop actuator 152 may be actuated such that the wheel stops 126a, 126b, are moved such that the wheel locking devices 125 may accept the target wheels 210. The controller module 140 may align the robotic transportation device 100 with the target device using the camera of the device detection module 170 described above, or using the wireless signals provided by the device tags 220. In another embodiment, the target device may also have infrared light guides (not shown) that emit an infrared signal. The infrared detector 162 (FIG. 6) of the robotic transportation device 100 may detect the infrared signal and the controller module 140 may determine the position of the robotic transportation device 100 with respect to the target device. [0042] In one embodiment, the docking arm actuator 154 moves the second portion 124 of the docking arms 120 toward the target wheels 210 such that the wheel stops 126a, 126b slide underneath the target wheels 210. In another embodiment, the motorized wheels 112 may be actuated such that the robotic transportation device 100 drives forward toward the target device 200 and the wheel stops 126a, 126b slide underneath the target device wheels 210….”);
a communication module configured to communicate with at least one further transportation device , wherein the communication module) comprises the receiver (see at least Ota Fig. 1, 4 and 5 and [0018-0019] and [0030-0031] which discloses the communication device communication is capable of communicating with a further transportation device. )
While Ota teaches the mobility mechanism is positioning the transportation device adjacent to the authenticated movable device (see [0040-0042] as cited above) and implies that is done based on the displacement or relative positioning of the devices (i.e. a kinematic parameter), Ota does not explicitly teach a kinematics controller configured to determine kinematic parameters of the transportation a device and to position the transportation device based on the determined kinematic parameters.
Wurman teaches
a kinematics controller configured to determine kinematic parameters of the transportation a device and to position the transportation device based on the determined kinematic parameters. (see at least Wurman, determine relative position as at least one of the kinematic parameters [0077] “The docking sensor 506 may be utilized in human transport devices such as the human transport device 400, 420 of FIGS. 4A and 4B where a mobile drive unit 104 docks with the portable cabin 402 in order to propel the human transport device 400, 420. Accordingly, the docking sensor 506 may determine an absolute location of the portable cabin 402, or a location of the portable cabin 402 relative to the mobile drive unit 104 such that the mobile drive unit 104 may use this information for docking with the portable cabin 402.” ),
a communication module configured to communicate with at least one further transportation device , wherein preferably the communication module) comprises the receiver (see at least Wurman Figure1 , human transport devices 106, [0027] “the human transport devices” and [0039] “a human transport manager 208 to manage the operation of the human transport devices 106 within the workspace 102 of FIG. 1.” See also “[0063] As another example, in a tracked system, the tracks or other guidance elements upon which the human transport devices 400 move may be wired to facilitate communication between the human transport devices 400 and other components of the inventory system 100, 300. ).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Ota with the teaching of Wurman, with a reasonable expectation of success, because this would allow for the devices to share information that would be helpful in route planning, such as areas to avoid (see at least [0053-0054]).
Regarding claim 9, the combination of Ota and Wurman teach the transportation device of claim 8, wherein the mobility mechanism is configured to drive the transportation device to the target rendezvous location identified in the coupling request on the determined kinematic parameters of the transportation device (see at least Ota [0005] “The drive signal may be based at least in part on a navigation route calculated from the proximity data and the navigational data. The executable instructions may further cause the controller module to receive the device data from the device detection module to determine a device type of the target device, control docking arms to engage the adjustable wheel locking devices with wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously travel to a second destination associated with the second destination input signal.” See also Wurman [0077] and (see at least Wurman, [0077] “The docking sensor 506 may be utilized in human transport devices such as the human transport device 400, 420 of FIGS. 4A and 4B where a mobile drive unit 104 docks with the portable cabin 402 in order to propel the human transport device 400, 420. Accordingly, the docking sensor 506 may determine an absolute location of the portable cabin 402, or a location of the portable cabin 402 relative to the mobile drive unit 104 such that the mobile drive unit 104 may use this information for docking with the portable cabin 402.” See also Wurman [0058] “Although FIG. 4A shows the mobile drive unit 104 lifting the portable cabin 402 from underneath the portable cabin 402, it is to be appreciated that the mobile drive unit 104 may connect to, or otherwise interact with, the portable cabin 402 in any suitable manner so that, when docked, the mobile drive unit 104 is coupled to the portable cabin 402 and can move the portable cabin 402 within the workspace 102, 302. For instance, in some embodiments a hitch facilitating attachment of the mobile drive unit 104 to the portable cabin 402 may enable the mobile drive unit 104 to push/pull the portable cabin 402, wherein the portable cabin 402 may include casters or a similar wheel-like mechanism at the bottom of the portable cabin 402 for such movement. The mobile drive unit 104 may comprise suitable components to lift, rotate and/or otherwise maneuver the portable cabin 402 into any position, location and/or orientation. The mobile drive unit 104 (or the drive subsystem in the fully integrated embodiment of the human transport device 106) may include motorized wheels or legs configured to propel and/or rotate the human transport device 400 in any direction and at various speeds and accelerations. In some embodiments, a self-powered human transport device 106 (i.e., without a detachable mobile drive unit 104) may include wheels or legs configured to allow for translational movement of the human transport device 106.”).
Regarding claim 18, Ota discloses a method of driving a movable device, the method comprising:
receiving [at a server] a coupling request comprising location information and device identity information of the movable device (see at least Ota [0035] The first and second destination input signals may be received from the HMI device 180. For example, a hospital employee may have entered the first and second destinations into the HMI device 180. The first destination may be a particular patient's room and the second destination may be a test location, such as an magnetic resonance imaging test room. The hospital employee, in one embodiment, may also enter information corresponding to the type of target device. For example, the hospital employee may enter the type of wheel chair that the robotic transportation device 100 is supposed to pick up and deliver. Alternatively, the first and second destination input signal, as well as target device data, may be received from the central server 172 via the wireless communications device 160. In this embodiment, a hospital employee may enter in destination information into a software program that dispatches a robotic transportation device 100 by transmitting the destination information thereto” The examiner notes that in the alternative embodiment the transportation device receives the information form the central server, however, the central server receives the information based on input by a hospital employee, thus the server receives the request. Further, the examiner notes the 112b indefiniteness rejection above, wherein the claim appears to require that the coupling request is received from both the server and the receiver. See also [0006] and [0032] regarding the wireless communications including those of the server.);
[selecting, by the server a designated transportation device from a plurality of transportation devices] dispatching a designated transportation device to the movable device based at least on the location information in the coupling request (see at least Ota [0036] “Once the robotic transportation device 100 receives the first and second destination input signals, the position of the robotic transportation device 100 may be determined and a navigation route determined by the controller module 140 and/or the central server 172.” See also [0033] ”The robotic transportation device 100 may determine its location within the area. In one embodiment, a plurality of local position tags 174 (FIG. 6) may be located throughout a facility (e.g., a floor or ward of a hospital). The local position tags 174 may be located on walls, obstacles (e.g., desks, nurses stations, chairs, etc.) or other locations. The local position tags 174 may emit a wireless location signal that is uniquely addressed. The wireless communications device 160 (and controller module 140) may receive the wireless signals as proximity data from the local position tags 174. The proximity data corresponding to the signals from the local position tags 174 may be provided to the controller module 140. The controller module 140 may use the proximity data to determine a position of the robotic transportation device 100 within the facility. The position may then be used to navigate the robotic transportation device 100 throughout the facility in accordance with a calculated navigation route. The navigation route may be calculated by the controller module 140 or the central server 172. The local position tags 174 may define portions of the area that are restricted to prevent the robotic transportation device from entering such areas. Infrared and/or ultrasonic sensors may also be used for collision avoidance. See also Ota [0037] A navigation route may be determined based on the destination input signals, the proximity data (i.e., the current location of the robotic transportation device 100), and the navigation data. The controller module 140 may provide drive signals to the motorized wheels 112 such that the robotic transportation device 100 autonomously moves toward the target device corresponding with the first destination input signal. Infrared and/or sonar devices may be used for obstacle avoidance….[0038] Once the robotic transportation device 100 is located near the target device, it may detect the position and type of target device. See also Ota [0005] ).
[dispatching from the server the coupling request to the designated transportation device; ]
authenticating the movable device based on the identity information in the coupling request (see at least Ota [0038-0040] “Once the robotic transportation device 100 is located near the target device, it may detect the position and type of target device. Referring to FIG. 8, a hospital bed 200 is illustrated. The hospital has a frame 212 on which two device tags 220 may be positioned. Alternatively, there may be only one device tag 220 or no device tag positioned on the target device. The device tags 220 may be RFID tags that transmit a wireless identification signal indicative of the type of target device. The RFID signal may be detected by the wireless communications device 160 in one embodiment. In another embodiment, the RFID signal or other target device signal may be detected by a device detection module 170. The device detection module 170, or the wireless communications device 160 may be equipped with a radio frequency receiver capable of receiving the radio frequency signal from the device tags 220. The device tags 200 (or single device tag) may be configured as other wireless devices capable of transmitting an identification signal, such as infrared signals, or WiFi signals, for example….[0039] The identification signal may provide or otherwise indicate device data associated with the particular target device. The device data may be provided to the controller module 140 by the device detection module 170. In an alternative embodiment, the controller module 140 may receive or determine the device data. The device data may include the make and model of the target device, the overall dimensions of the target device, position of the target device wheels, etc. From the device data, the controller module 140 may determine the type of target device (e.g., a hospital bed).”)…See also [0040] “The device detection module 170 may also be a visual module such as a camera device. The camera device may take a digital image of the target device, which is provided to the controller module 140. The controller module 140 may compare the digital image with a plurality of registered device types stored within the memory 144 to determine the type of target device. For example, a digital image of the hospital bed illustrated in FIG. 8 may be compared with registered devices. Based on the comparison, the controller module 140 may determine that the target device is a hospital bed. It may also determine the relative position of the target devices wheels and other details.”.);
operating the transportation device such that the designated transportation device couples itself to the movable device (see at least Ota [0042] “ In one embodiment, the docking arm actuator 154 moves the second portion 124 of the docking arms 120 toward the target wheels 210 such that the wheel stops 126a, 126b slide underneath the target wheels 210. In another embodiment, the motorized wheels 112 may be actuated such that the robotic transportation device 100 drives forward toward the target device 200 and the wheel stops 126a, 126b slide underneath the target device wheels 210. Once the wheel stops 126a, 126b are underneath the target device wheels 210, the wheel stop actuator 152 may be further adjusted such that the wheel locking devices 125 lock the target wheels 210 in place. The vertical actuator 156, if present in the robotic transportation device 100, may then lift the docking arms 120 and the target wheels. The wheel locking devices 125 may also engage the target wheels by positioning the docking arms 120 and wheel locking devices 125 in between the target wheels. The docking arm actuator 154 may be controlled to move the docking arms 120 outwardly such that the wheel stops 126a, 126b engage the target wheels from an inner side of each target wheel. The wheel stop actuators 152 may then be controlled such that the wheel stops 126a, 126b move closer to one another and lock the target wheels.”); and
instructing the transportation device to drive off and thereby correspondingly moving the movable device (see at least Ota [0036] “Once the robotic transportation device 100 receives the first and second destination input signals, the position of the robotic transportation device 100 may be determined and a navigation route determined by the controller module 140 and/or the central server 172.” See also Ota [0044-0045] The robotic transportation device 100 may determine its location with proximity data as described above and calculate a navigation route to the desired destination corresponding to the second destination input signal. The navigation route may be based on the navigation data, the proximity data, the dimensions of the robotic transportation device 100 and the target device…. [0045] The robotic transportation device 100 then autonomously navigates throughout the facility to deliver the target device to the desired location. The robotic transportation device 100 tows the target device to the desired location.);
wherein the transportation device comprises:
a receiver configured to receive a coupling request comprising location information and device identity information see at least Ota, Figure 2 and 6, wireless communications device 160. See at least Ota [0006] “In yet another embodiment, a wheeled device transportation system includes a wireless communications network, a central server communicatively coupled to the wireless network, a radio frequency identification tag, and a robotic transportation device. The central server may provide navigation data over the wireless communications network. The target device has two wheels and a radio frequency identification tag configured to emit an identification signal. The robotic transportation device may include a device body having at least one motorized wheel coupled to a drive motor, two docking arms, a wireless communications device, and a controller module. Each docking arm may include a support wheel and an adjustable wheel locking device, and may extend horizontally from the device body and may be adjustable along at least two directions. The wireless communications device is communicatively coupled to the wireless communications network. The wireless communications device further detects a location of the robotic transportation device, provides proximity data corresponding to the location of the robotic transportation device, and wirelessly receives navigational data over the wireless communications network emitted by the central server. The controller module may include a processor and a computer readable memory having executable instructions. The controller module is electrically coupled to the wireless communications device and the device detection module. The controller module may receive the proximity data and the navigational data from the wireless communications device, detect a device type of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously approach a target device. The drive signal may be based at least in part on the proximity data and the navigational data. The controller module may further control the docking arms in accordance with the device type to engage the adjustable wheel locking devices with the wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously tow the target device to a desired location.”)
a mobility mechanism configured to drive the transportation device to a location indicated by the location information in the received coupling request (see at least Ota Figures 1-2, motorized wheels 112, drive motor 113, See at least [0022] “The device body 110 comprises a body housing 111, which may be made of a metal or plastic material, and a pair of motorized wheels 112 that are coupled to a drive motor 113 that is positioned within the body housing 111. In another embodiment, more than two motorized wheels may be utilized. Alternatively, a single motorized wheel may be utilized. For example, a single motorized wheel may be used in conjunction with non-motorized wheels (not shown) to move the robotic transportation device 100. The drive motor may be an electric motor that is powered by one or more rechargeable batteries (not shown). The motorized wheels 112 and drive motor 113 may be responsive to drive signals provided by a controller module 140 (FIG. 2), as described in more detail below.”)
an authentication module configured to authenticate a movable device at the indicated location based on the device identity information in the received coupling request (see at least Ota, Figure 6, device detection module [0038-0040] “Once the robotic transportation device 100 is located near the target device, it may detect the position and type of target device. Referring to FIG. 8, a hospital bed 200 is illustrated. The hospital has a frame 212 on which two device tags 220 may be positioned. Alternatively, there may be only one device tag 220 or no device tag positioned on the target device. The device tags 220 may be RFID tags that transmit a wireless identification signal indicative of the type of target device. The RFID signal may be detected by the wireless communications device 160 in one embodiment. In another embodiment, the RFID signal or other target device signal may be detected by a device detection module 170. The device detection module 170, or the wireless communications device 160 may be equipped with a radio frequency receiver capable of receiving the radio frequency signal from the device tags 220. The device tags 200 (or single device tag) may be configured as other wireless devices capable of transmitting an identification signal, such as infrared signals, or WiFi signals, for example…[0039] The identification signal may provide or otherwise indicate device data associated with the particular target device. The device data may be provided to the controller module 140 by the device detection module 170. In an alternative embodiment, the controller module 140 may receive or determine the device data. The device data may include the make and model of the target device, the overall dimensions of the target device, position of the target device wheels, etc. From the device data, the controller module 140 may determine the type of target device (e.g., a hospital bed)…”); and
a coupler selectively engageable with the movable device based on the authentication (see at least Ota, Figure 1 and 9, docking arms 120. See also [0006] “The controller module is electrically coupled to the wireless communications device and the device detection module. The controller module may receive the proximity data and the navigational data from the wireless communications device, detect a device type of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously approach a target device. The drive signal may be based at least in part on the proximity data and the navigational data. The controller module may further control the docking arms in accordance with the device type to engage the adjustable wheel locking devices with the wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously tow the target device to a desired location.” See also [0041] “Still referring to FIG. 8, the device data may indicate to the robotic transportation device 100 that the hospital bed 200 has two target device wheels 210 having a particular diameter that are separated by a distance d. The controller module 140 may adjust the docking arms 120 and associated wheel adjustable wheel locking devices 125 in accordance with the type of target device. Also referring to FIGS. 1-7, the controller module 140 may provide drive signals to the length adjustment actuator 150, the wheel stop actuator 152, the docking arm actuator 154, and the vertical actuator 156 to prepare the robotic transportation device 100 for docking with the target device (e.g., hospital bed 200). For example, the docking arms 120 may be lowered and positioned such that the adjustable wheel locking devices 125 are substantially aligned with the target device wheels 210. The docking arms 120 may be moved along direction A so that the adjustable wheel locking devices 125 are separated by a distance d in accordance with the distance d between the target wheels 210.”),
wherein on the selective engagement of the coupler with the movable device , movement of the transportation device correspondingly moves the movable device (see at least Ota [005] “The executable instructions may further cause the controller module to receive the device data from the device detection module to determine a device type of the target device, control docking arms to engage the adjustable wheel locking devices with wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously travel to a second destination associated with the second destination input signal. The drive signal may be based at least in part on a navigation route calculated from the proximity data and the navigational data.” See also [0045] “The robotic transportation device 100 then autonomously navigates throughout the facility to deliver the target device to the desired location. The robotic transportation device 100 tows the target device to the desired location. The target devices remaining unlocked wheels enable it to be towed by the robotic transportation device. For example, the unlocked wheels 330 of the wheels chair 300 (FIG. 9), the unlocked wheels 430 of the patient lift 400 (FIG. 10), and the unlocked wheels 220 of the hospital bed 220 (FIGS. 8 and 11) are free to rotate as the respective target device is towed.” See also [0006] “The controller module may further control the docking arms in accordance with the device type to engage the adjustable wheel locking devices with the wheels of the target device, and provide a drive signal to the at least one motorized wheel to cause the robotic transportation device to autonomously tow the target device to a desired location.” ).
Ota does not explicitly teach receiving, at a server, a coupling request, selecting, by the server a designated transportation device from a plurality of transportation devices, receiving at a server a coupling request comprising location information and device identity information of the movable device, and dispatching from the server the coupling request to the designated transportation device.
However, Wurman teaches receiving, at a server, a coupling request (see at least Wurman Figure 2, management module 110 and [0027] As noted above, there may be circumstances where it is necessary for users 114 to traverse the workspace 102. For instance, a failed mobile drive unit 116 or a drive unit charging station 117 may alert the management module 110 that it is in need of maintenance, or a mobile drive unit 104 or other component of the inventory system 100 may detect fallen inventory items within the workspace 102.” See also [0029] and [0030] regarding location information, e.g. “whereby a current location of the user 114 may be transmitted to the management module 110”), selecting, by the server a designated transportation device from a plurality of transportation devices (see at least Wurman [0030] “the users 114 may be associated with computing devices that are configured to communicate with the management module 110 whereby a current location of the user 114 may be transmitted to the management module 110, and the management module 110 may then direct an available human transport device 106 to the transmitted location to pick up the user 114. “ See also [0031]),and dispatching from the server the coupling request to the designated transportation device (see at least Wurman [0030] “the users 114 may be associated with computing devices that are configured to communicate with the management module 110 whereby a current location of the user 114 may be transmitted to the management module 110, and the management module 110 may then direct an available human transport device 106 to the transmitted location to pick up the user 114.” See also [0026] “The inventory holders 108 may be capable of being carried, rolled, and/or otherwise moved by the mobile drive units 104. In general, the mobile drive units 104 are configured to transport the inventory holders 108 between points within the workspace 102 in response to commands communicated by a management module 110.”),
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Ota with the teaching of Wurman, with a reasonable expectation of success, to include server-side control of the requests because as Wurman teaches, this allows for a management system that provides a coordinated effort interacting with the devices to ensure that the devices arrive at the specified destination with minimal disruption to other mobile units.
Regarding claim 19, the combination of Ota and Wurman teaches the method of claim 18, further comprising at least one of:
selecting the designated transportation device from a plurality of transportation devices, based on at least one of the location information in the coupling request and respective positions of each transportation device of the plurality of transportation devices and wherein the coupling request is from the server to the designated transportation device (see at least Wurman [0029] “In some embodiments, the inventory system 100 may further include one or more user stations 120. The user stations 120 represent physical locations where a user 114 may enter or exit a human transport device 106 depending upon whether the human transport device 106 is departing from, or arriving at, the user station 120. The user stations 120 may be located at any suitable location, such as a perimeter of the workspace 102 that is designated as an "inactive" portion of the inventory system 100. The mobile drive units 104 may be prohibited from entering inactive portions of the inventory system 100 to provide a safe area for users 114 to reside and move about. Additionally, or alternatively, the user stations 120 may be located at other locations, such as in the middle of the workspace 102 and within an inactive portion of the inventory system 100. Regardless of the locations of the user stations 120, the human transport devices 106 may be configured to remain parked, or idling, at or near the user stations 120 until a user 114 enters or boards the human transport device 106 for transport to a destination location.” See also [0041] “The resource scheduling module 210 may also be configured to generate task assignments related to the general maintenance of the human transport devices 106 themselves, such as prompting the human transport devices 106 to charge or replace batteries, instruct the human transport devices 106 to park or idle near a user station 120 and out of the way of heavy traffic flow of components of the inventory system, and the like.” [0042] “ The human transport manager 208 may further include a route planning module 218 to identify destination locations associated with a received request or alert 212 and to generate or plan a route to the identified destination location. For example, a user 114 may request, via their associated computing device, transport to a location such as the restroom 118. After a task assignment 214 is generated and a human transport device 106 is selected by the resource scheduling module 210, the route planning module 218 may identify a destination location within the workspace 102 in proximity to the restroom 118 and may then plan a route to transport the user 114 in the human transport device 106 from a starting location to the destination location near the restroom 118. In planning the route, the route planning module 218 may utilize knowledge of current congestion, historical traffic trends, task prioritization, and/or other appropriate considerations and feedback to make decisions on an optimal route for the human transport device 106.” See also [0057] “In general, the human transport devices disclosed herein may represent any devices or components suitable for transporting personnel/users 114 within the workspace 102, 302 of the inventory system 100, 300.” Which teaches selecting a device within the workspace. See also [0027]).
transmitting the coupling request from the server to the designated transportation device (see at least Wurman [0030] “the users 114 may be associated with computing devices that are configured to communicate with the management module 110 whereby a current location of the user 114 may be transmitted to the management module 110, and the management module 110 may then direct an available human transport device 106 to the transmitted location to pick up the user 114.” See also [0026] “The inventory holders 108 may be capable of being carried, rolled, and/or otherwise moved by the mobile drive units 104. In general, the mobile drive units 104 are configured to transport the inventory holders 108 between points within the workspace 102 in response to commands communicated by a management module 110.”. See also Ota, Figure 2 and 6, wireless communications device 160. Ota [0006]).
Regarding claim 20, the combination of Ota and Wurman teaches the method of claim 18, wherein the authenticating the movable device comprises reading an identification code provided on the movable device using the designated transportation device, uploading the
identification code to the server, and matching the read identification code to the device identity information in the coupling request (see at least Ota [0038-0039] “Once the robotic transportation device 100 is located near the target device, it may detect the position and type of target device. Referring to FIG. 8, a hospital bed 200 is illustrated. The hospital has a frame 212 on which two device tags 220 may be positioned. Alternatively, there may be only one device tag 220 or no device tag positioned on the target device. The device tags 220 may be RFID tags that transmit a wireless identification signal indicative of the type of target device. The RFID signal may be detected by the wireless communications device 160 in one embodiment. In another embodiment, the RFID signal or other target device signal may be detected by a device detection module 170. The device detection module 170, or the wireless communications device 160 may be equipped with a radio frequency receiver capable of receiving the radio frequency signal from the device tags 220. The device tags 200 (or single device tag) may be configured as other wireless devices capable of transmitting an identification signal, such as infrared signals, or WiFi signals, for example….[0039] The identification signal may provide or otherwise indicate device data associated with the particular target device. The device data may be provided to the controller module 140 by the device detection module 170. In an alternative embodiment, the controller module 140 may receive or determine the device data. The device data may include the make and model of the target device, the overall dimensions of the target device, position of the target device wheels, etc. From the device data, the controller module 140 may determine the type of target device (e.g., a hospital bed).” See also [0040] “The device detection module 170 may also be a visual module such as a camera device. The camera device may take a digital image of the target device, which is provided to the controller module 140. The controller module 140 may compare the digital image with a plurality of registered device types stored within the memory 144 to determine the type of target device. For example, a digital image of the hospital bed illustrated in FIG. 8 may be compared with registered devices. Based on the comparison, the controller module 140 may determine that the target device is a hospital bed.” and [0006]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US-20160209843-A1 to Meuleau et al. and US-20220234631-A1 to Mandler are cited for showing a transportation device that receives a coupling request, further at least Meuleau teaches a server that receives the coupling request and dispatches the coupling request to the transport device.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action0 is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER M. ANDA whose telephone number is (571)272-5042. The examiner can normally be reached Monday-Friday 8:30 am-5pm MST.
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, Aniss Chad can be reached on (571)270-3832. 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.
/JENNIFER M ANDA/Examiner, Art Unit 3662
Prosecution Insights