DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 8 September 2026 has been entered.
Claims 1, 7, 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.
Response to Amendments and Remarks
Claim Rejections - 35 USC § 112
Claims 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 the rejections under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. Accordingly, the rejection of claims 18-20 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, has been withdrawn.
Claim Rejections - 35 USC §§ 102 and 103
Claim(s) 1-3, 6-7, and 10-14 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 18-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 with respect to claim(s) 1-14 and 18-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim 7 is 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.
Amended claim 7 recites “wherein the authentication module is configured to read the unique identification code from a coupling assembly affixed to the movable device by initiating a wireless handshake with the coupling assembly”. The examiner understands that the term “handshake” as a term of the art as a process in which two devices establish a communication link by authenticating and validating each other's signals. The examiner notes that the coupling assembly is not taught to have a processor and thus it is unclear how the coupling assembly can be capable of validating the signal received in the wireless handshake (see at least Fig. 3A showing the coupling assembly and [0050] of the instant application). The examiner notes that there is support for the transportation device 120 verifying the unique ID of the coupling assembly to authenticate the movable device {see [0068]). Similarly, there is support for the authentication module 206 of the transport device to initiate a handshake with the movable device 180 (see [0068]), There is no discussion of the authentication module to initiate a handshake with the coupling assembly, nor is it clear how the coupling assembly would be capable of doing so.
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) 1-3, 6-7, and 10-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ota et al. US Pub. No. 2012/0029697, hereinafter “Ota in view of Williams et al. (US Pub. No. 2017/0185717, hereinafter “Williams”).
Regarding claim 1, Ota teaches a transportation device comprising:
a receiver configured to receive a coupling request comprising location information and device identity information [[that uniquely identifies a particular movable device]] that the transportation device is requested to couple to (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 by reading a [[unique]] identification code provided on the movable device and matching the read [[unique]] identification code to the device identity information in the received coupling request, to verify that the movable device at the target rendezvous location is the [[particular]] movable device that the transportation device is requested to couple to (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.” ).
Ota does not explicitly teach wherein the device identity information is identify information that uniquely identifies a particular movable device, and further the reading and verification of the identification code of the movable device is a unique identification code of a particular movable device.
Williams teaches the device identity information is identify information that uniquely identifies a particular movable device, and further the reading and verification of the identification code of the movable device is a unique identification code of a particular movable device (see at least Williams Figure 7 and Figure 8A and [0074] “ (Step 703); receiving an image of a unique device identifier located on a medical device present in a sterile setting, the image of a unique device identifier captured with a computer with an imaging device within the sterile field (Step 705); decoding a captured image of the unique device identifier to provide a decoded unique device identifier for the device in the sterile setting (Step 707); transmitting the decoded captured image of the unique device identifier to the remote HIPPA-compliant server (Step 712); the remote HIPPA-compliant server receives GUDID data (Step 710); identifying the medical device by matching the decoded captured image of the Unique Device Identifier affixed to the medical device with the Global Unique Device Identifier Database data at the remote HIPPA-compliant server and transmitting this identity to the user”).
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 Williams, with a reasonable expectation of success, because as Williams teaches the method and system allow verification of a medical device and ensure the device is correct for the patient (see [0004] and [0068]).
Regarding claim 2, the combination of Ota and Williams teaches 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, the combination of Ota and Williams teaches 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, the combination of Ota and Williams teaches 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, the combination of Ota and Williams teaches the transportation device of claim 1, wherein the authentication module is configured to read the unique identification code from a coupling assembly affixed to the movable device by initiation ga wireless handshake with the coupling assembly (The examiner interprets the wireless handshake to be the transportation device reading the identification code of the coupling assembly. 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 Williams [0074] for unique identification code as cited and discussed with respect to claim 1).
Regarding claim 10, the combination of Ota and Williams teaches 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, the combination of Ota and Williams teaches 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, the combination of Ota and Williams teaches 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, the combination of Ota and Williams teaches 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, the combination of Ota and Williams teaches 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(s) 4-5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ota and Williams in view of Kasperski III (US Pub. No. 2020/0025574, hereinafter Kasperski”).
Regarding claim 4, the combination of Ota and Williams teaches 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 the combination of Ota and Williams 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, Williams, and Kasperski teach 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 and Williams in view of Wurman et al. (US Pub. No. 2015/0066283, hereinafter “Wurman”).
Regarding claim 8, the combination of Ota and Williams teaches 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 the combination of Ota and Williams 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), the combination 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 and Williams 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, Williams 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 teaches a method of driving a movable device, the method comprising:
receiving [at a server] a coupling request comprising location information and device identity information [[that uniquely identifies]] 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]] based on at least 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; ]
driving the designated transportation device to a target rendezvous location identified in the location information of the coupling request (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] ).
authenticating the movable device at the target rendezvous location, the authenticating comprising reading, by the designated transportation device a [[unique]] identification code provided on the movable device, and matching the read [[unique]] identification code to the device identify information in the coupling request to verify that the movable device at the target rendezvous location is the movable deice [[uniquely’]] identified by the device identify information (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 a coupler of the designated transportation device to selectively engage the movable device based on the authenticating (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 designated transportation device to drive off and thereby correspondingly move 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.).
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, 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.
The combination of Ota and Wurman does not explicitly teach wherein the device identity information is identify information that uniquely identifies the movable device, and further the reading, matching, and verification of the identification code of the movable device is a unique identification code of the movable device.
Williams teaches the device identity information is identify information that uniquely identifies the movable device, and further the reading, matching, and verification of the identification code of the movable device is a unique identification code of the movable device (see at least Williams Figure 7 and Figure 8A and [0074] “ (Step 703); receiving an image of a unique device identifier located on a medical device present in a sterile setting, the image of a unique device identifier captured with a computer with an imaging device within the sterile field (Step 705); decoding a captured image of the unique device identifier to provide a decoded unique device identifier for the device in the sterile setting (Step 707); transmitting the decoded captured image of the unique device identifier to the remote HIPPA-compliant server (Step 712); the remote HIPPA-compliant server receives GUDID data (Step 710); identifying the medical device by matching the decoded captured image of the Unique Device Identifier affixed to the medical device with the Global Unique Device Identifier Database data at the remote HIPPA-compliant server and transmitting this identity to the user”).
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 the combination of Ota and Wurman with the teaching of Williams, with a reasonable expectation of success, because as Williams teaches the method and system allow verification of a medical device and ensure the device is correct for the patient (see [0004] and [0068]).
Regarding claim 19, the combination of Ota, Wurman, and Willams teaches the method of claim 18, further comprising at least one of:
selecting the designated transportation device is further based on respective positions of each transportation device of the plurality of transportation devices (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]).
Regarding claim 20, the combination of Ota, Wurman, and Williams teaches the method of claim 18, wherein the authenticating the movable device comprises reading the unique identification code provided on the movable device using the designated transportation device, uploading the read unique identification code to the server, and matching, by the server the read unique 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]. See at least Wurman (as cited above with respect to claim 18) and Williams [0074] for matching by the server. See Williams [0074] and the citations and discussion with respect to claim 18 for the unique identification code.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US-20200064446-A1 is cited for showing a unique identifier of a device (see at least [0036].
US-20190287047-A1 Is cited for showing logistics operations for delivery and pickup of items using an autonomous bot apparatus assembly.
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/Primary Examiner, Art Unit 3662
Prosecution Insights