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 .
DETAILED ACTION
Priority
Acknowledgment is made of applicant's claim for domestic benefit based on provisional application 62/857,118 filed on June 4, 2019.
DETAILED ACTION
Claims 1 – 22 are pending in the application.
Claims 1, 21, and 22 are independent.
Claims 21 and 22 are new.
This action is Final based on a new 35 U.S.C. §103 prior art reference that was necessitated by the applicant’s amendment; see MPEP §706.07(a).
The claim objections for claim 8 and 18 and 35 USC 112(b) rejection for claim 4 are rescinded based on the amendments to the claims.
The objection to the drawings is rescinded based on applicant’s arguments.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 8, 9, 12, 13, and 15 - 19 are rejected under 35 U.S.C. 103 as being unpatentable over Basterash et al. (US PG Pub. No. 20180150121), herein “Basterash,” in view of Hough et al. (PG Pub. No. 20170116137), herein “Hough” in further view of Donahue et al. (US PG Pub. No. 20160323736), herein “Donahue.”
Regarding claim 1,
Basterash teaches a building system of a building, (Par. 0002: “The present disclosure relates generally to building automation systems, and in particular, to a building automation system controller…”)
the building system comprising: an embedded computer, (primary controller; Par. 0030: “Primary controller 14 is a microcontroller or a microprocessor-based embedded computing device which includes the necessary logic and software instructions…”)
receive building data from at least one of the one or more of peripheral USB building devices; (Par. 0004: “Such USB ports can be used to support many types of peripherals.” Par. 0030: “…receiving sensor data from a range of environmental and system sensors (e.g., temperature, humidity, pressure), communicating with and controlling system devices (compressors, variable air volume devices, chillers, lighting etc.” Par. 0003: “Building automation system (BAS) controllers are used to coordinate, manage, and automate control of diverse environmental, physical, and electrical building subsystems, particularly HVAC and climate control systems but also including security, lighting, power, and the like. Typical existing BAS controllers are hardwired or use proprietary communication standards or protocols to link various subsystems and provide system-wide user access, monitoring, and control. More recently, BAS controllers have begun to employ open architecture to enable peripherals to be easily added or removed using industry standard interfaces, such as universal serial bus (USB) ports.”)
generate one or more control decisions for the one or more of peripheral USB building devices; (Par. 0051: “A BAS controller configured to power one or more peripheral devices, comprising a USB hub having a plurality of independently-powerable USB ports…” Par. 0011: “In some embodiments of the BAS controller, then means for removing power from individual ones of the plurality of USB ports includes opening a switch in accordance with a control signal transmitted from the primary controller. In some embodiments, the means for removing power from individual ones of the plurality of USB ports includes a current latch.” See also full paragraph 0029 and claim 13. See also Hough Par. 0043 that teaches an embedded computer that generates configuration files to control the peripheral device(s). Hough paragraph 0029 also teaches generating control signals for the peripheral. )
and communicate the one or more control decisions to the one or more of peripheral USB building devices via the USB connection; (Par. 0029: “Each USB port 20 is operatively associated with a controllable switch 22 that enables or disables power delivery to its respective USB port 20. Controllable switch 22. may include a relay and/or a solid state switching device such as a transistor or MOSFET arranged to selectively allow current to flow between power supply 12 and USB port 20. Controllable switch 22 is opened or closed in accordance with a control signal transmitted from primary controller 14 via control bus 26 to controllable switch 22. Each controllable switch 22 operates independently from the others thereby allowing the plurality of USB ports 20 to be selectively and independently powered-on or powered-off as desired, in any combination. Each USB port 20 is communicatively coupled with primary controller 14 via data bus 28 to enable data transfer between primary controller 14 and any USB device 21 that may be inserted into a corresponding USB port 20. In some embodiments, the one or more controllable switches 22 are included within a USB hub comprising USB ports 20.” Par. 0011: “In some embodiments of the BAS controller, then means for removing power from individual ones of the plurality of USB ports includes opening a switch in accordance with a control signal transmitted from the primary controller. In some embodiments, the means for removing power from individual ones of the plurality of USB ports includes a current latch.” Par. 0030: “…receiving sensor data from a range of environmental and system sensors (e.g., temperature, humidity, pressure), communicating with and controlling system devices (compressors, variable air volume devices, chillers, lighting etc.”) Examiner’s Note - See also Hough Par. 0026 that teaches a command set and/or configurations files are communicated to peripheral devices 46 and 50 via USB and other protocols.)
and the one or more of peripheral USB building devices, wherein the one or more of peripheral USB building devices are connected to the USB host via the USB connection to the embedded computer, (Par. 0029: “Each USB port 20 is operatively associated with a controllable switch 22 that enables or disables power delivery to its respective USB port 20. Controllable switch 22. may include a relay and/or a solid state switching device such as a transistor or MOSFET arranged to selectively allow current to flow between power supply 12 and USB port 20. Controllable switch 22 is opened or closed in accordance with a control signal transmitted from primary controller 14 via control bus 26 to controllable switch 22. Each controllable switch 22 operates independently from the others thereby allowing the plurality of USB ports 20 to be selectively and independently powered-on or powered-off as desired, in any combination. Each USB port 20 is communicatively coupled with primary controller 14 via data bus 28 to enable data transfer between primary controller 14 and any USB device 21 that may be inserted into a corresponding USB port 20. In some embodiments, the one or more controllable switches 22 are included within a USB hub comprising USB ports 20.” Par. 0011: “In some embodiments of the BAS controller, then means for removing power from individual ones of the plurality of USB ports includes opening a switch in accordance with a control signal transmitted from the primary controller. In some embodiments, the means for removing power from individual ones of the plurality of USB ports includes a current latch.” Par. 0030: “…receiving sensor data from a range of environmental and system sensors (e.g., temperature, humidity, pressure), communicating with and controlling system devices (compressors, variable air volume devices, chillers, lighting etc.”)
Basterash may implicitly teach a USB host such as USB ports (item 20); however, Hough teaches that the embedded computer (embedded computer 40) comprising one or more circuits configured to: implement a universal serial bus (USB) host (communications link, item 48. Par. 0025: “In the illustrated example, a first set of peripheral devices 46 ( 46a-46c) are coupled to a communications link 48 of the apparatus 40…”) and communicate with one or more of peripheral USB building devices via at least one of a USB connection or the USB host; (Par. 0025: “Turning now to FIG. 4, an embedded computer apparatus 40 (e.g., personal computer/PC) is shown, wherein the embedded computer apparatus 40 may be part of a system such as, for example, a vending machine ( e.g., coffee dispenser, snack dispenser), cooler, freezer, industrial appliance, home appliance, smart signage, smart shelf, and so
forth.” Par. 0025: “…The first set of peripheral devices 46 may communicate via a PC
standard protocol such as, for example, I2C, USB, RS-232, Zigbee, TCP/IP, SPI, GIP, etc.,”)
Hough also teaches that the USB connection is provided using RS-485, RS 232, Ethernet twisted pair, or telephone wiring. (Par. 0025, last sentence: “The first set of peripheral devices 46 may communicate via a PC standard protocol such as, for example, I2C, USB, RS-232, Zigbee, TCP/IP, SPI, GIP, etc., whereas the second set of peripheral devices 50 may communicate via a non-PC standard such as, for example, MDB, CAN (Controller Area Network), GPIO, and so forth.” See also Par. 0013.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the building automation system that details a building automation controller and exchanges both sensor data and controlling signals with the peripheral devices via USB as in Basterash with a system and method that incorporates an embedded computing device and communicates with peripherals by USB, wherein the peripherals are part of a building system such as home appliances or industrial appliances and the USB is an RS-232 protocol as in Hough in order to accommodate peripherals with universal controllers that communicate with common interfaces standards/specifications such as USB. (Par. 0013)
Hough may implicitly teach, but Basterash does not teach the amended portion that wherein the one or more control decisions include at least one of a temperature setpoint, a valve position, or a damper position associated with the one or more peripheral USB building devices. However, Donahue does teach wherein the one or more control decisions include at least one of a temperature setpoint, a valve position, or a damper position associated with the one or more peripheral USB building devices. (Par. 0118: “…receiver-controller 500 connects to the control device using standard interfaces and connectors such as USB, RS-232, RS-485, parallel ports, or CEA-2045.” Par. 0117: “The receiver/controller 500 incorporates intelligence and comprises a microprocessor and firmware or software. The receiver/controller 500 comprises a unique identity 502 can be addressed for signaling and/or controlling devices individually or as a group such, as devices of a predefined type within a given local utility service area. Upon decoding its unique address, the receiver-controller 500 responds to FM broadcast subcarrier signals directed to its address and generates analog outputs 504 or digital outputs 506 that may be used to turn devices or systems on or off, cycle devices or subsystems of devices on or off, send energy information to devices, send non energy information to devices, and/or control adjustments or set points of energy loads and their systems or subsystems.” See figures 4 and 5. Par. 0146: “Another embodiment comprises wide area geographically dispersed wireless control devices that receive and respond to control signals that are transmitted by a broadcast station sub carrier for the purposes of controlling valves, compressors, air handlers, chillers, and boilers of any type in an HVAC system.” Par.0144, 0148, and 0153. )
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the building automation system that details a building automation controller and exchanges both sensor data and controlling signals with the peripheral devices via USB as in Basterash with a system and method that incorporates an embedded computing device and communicates with peripherals by USB, wherein the peripherals are part of a building system such as home appliances or industrial appliances and the USB is an RS-232 protocol as in Hough with controlling a building HVAC device that is connected to a controller by a USB connection wherein control signals control at least the temperature and/or the valve of the building HVAC device as in Donahue in order to monitor and control power consumption and other occupant discomfort factors and be able to control those elements by a USB connection. (Par. 0088).
Regarding claim 8,
The previously cited references teach the limitations of claim 1 which claim 8 depends. Basterash also teaches that the one or more of peripheral USB building devices receive USB power from at least one of the embedded computer and an USB power injector and operates based on the USB power. (Par. 0002: “The present disclosure relates generally to building automation systems, and in particular, to a building automation system controller which selectively distributes power to a set of USB peripherals to ensure overall power consumption is kept within a predefined power budget.” See also Par. 0004 – 0011, 0025, 0031 – 0039, 0051 – 0052, and 0059 – 0065.)
Regarding claim 9,
The previously cited references teach the limitations of claim 1 which claim 9 depends. Basterash also teaches comprising a USB actuator, wherein the USB actuator comprises: an actuator device configured to operate to control an environmental condition of the building; an energy storage device configured to store energy and discharge the energy; and a charging circuit configured to: receive the USB power from the embedded computer and charge the energy storage device based on the USB power; receive a command, via the USB connection, to operate the actuator device from the embedded computer; and operate the actuator device by causing the energy storage device to discharge the energy. (Par. 0030: “Primary controller 14 is a microcontroller or a microprocessor-based embedded computing device which includes the necessary logic and software instructions to perform the primary functions of BAS controller 10, including, but not limited to, receiving sensor data from a range of environmental and system sensors (e.g., temperature, humidity, pressure), communicating with and controlling system devices (compressors, variable air volume devices, chillers, lighting etc.), performing diagnostics, and performing peripheral power management as described herein. Example BAS systems and controllers of the type referred to herein are discussed in detail in U.S. Pat. No. 8,050,801, filed Aug. 22, 2005, issued Nov. 1, 2011, and entitled “Dynamically Extensible and Automatically Configurable Building Automation System and Architecture.” See also Par. 0029 and 0047.)
Regarding claim 12,
The previously cited references teach the limitations of claim 1 which claim 12 depends. Basterash also teaches that a first peripheral USB building device of the one or more of peripheral USB building devices is configured to: collect building data and encrypt the building data; communicate the encrypted building data to the embedded computer via the USB connection; receive encrypted operational data encrypted by the embedded computer, the encrypted operational data generated by the embedded computer based on the building data; and decrypt the encrypted operational data and operate based on the operational data. (Par. 0027: “Aspects of the present disclosure are described herein in terms of functional block components and various processing steps. It should be appreciated that such functional blocks configured to perform the specified functions may be embodied in mechanical devices, electromechanical devices, analog circuitry, digital circuitry, and/or modules embodied in a computer. For example, the present disclosure may employ various discrete components, integrated circuit components memory elements, processing elements, logic elements, look-up tables, and the like) which may carry out a variety of functions, whether independently, in cooperation with one or more other components, and/or under the control of one or more processors or other control devices, One skilled in the art will also appreciate that, for security reasons, any element of the present disclosure may include any of various suitable security features, such as firewalls, access codes, authentication, encryption, de-encryption, compression, decompression, and/or the like. It should be understood that the steps recited herein may be executed in any order and are not limited to the order presented. Moreover, two or more steps or actions recited herein may be performed concurrently.”)
Regarding claim 13,
The previously cited references teach the limitations of claim 12 which claim 13 depends. Hough also teaches wherein the one or more circuits of the embedded computer are configured to: receive the encrypted building data from the first peripheral USB building device; decrypt the encrypted building data and generate operational data based on the building data; and encrypt the operational data and communicate the encrypted operational data to the first peripheral USB building device via the USB connection. (Par. 0027: “Aspects of the present disclosure are described herein in terms of functional block components and various processing steps. It should be appreciated that such functional blocks configured to perform the specified functions may be embodied in mechanical devices, electromechanical devices, analog circuitry, digital circuitry, and/or modules embodied in a computer. For example, the present disclosure may employ various discrete components, integrated circuit components memory elements, processing elements, logic elements, look-up tables, and the like) which may carry out a variety of functions, whether independently, in cooperation with one or more other components, and/or under the control of one or more processors or other control devices, One skilled in the art will also appreciate that, for security reasons, any element of the present disclosure may include any of various suitable security features, such as firewalls, access codes, authentication, encryption, de-encryption, compression, decompression, and/or the like. It should be understood that the steps recited herein may be executed in any order and are not limited to the order presented. Moreover, two or more steps or actions recited herein may be performed concurrently.”)
Regarding claims 15 - 17, they are directed to a method of steps to implement the system or apparatuses set forth in claim 1. Basterash and Hough teach the claimed system or apparatuses in claim 1. Therefore, Basterash and Hough teach the method of steps in claims 15 – 17.
Regarding claim 18, they are directed to a system to implement the system or apparatuses set forth in claim 1 although stated similar limitations differently. Basterash and Hough teach the claimed system or apparatuses in claim 1. Therefore, Basterash and Hough teach the system in claim 18.
Regarding claim 19,
The previously cited references teach the limitations of claim 18 which claim 19 depends. Hough also teaches wherein the one or more control decisions are provided from an external cloud-based processor. (Par. 0027: “FIG. 5 shows a fleet management architecture 62 in which a plurality of vending machines 64 support remote monitoring of the health of the vending machines 64 by a cloud computing infrastructure 69. Each vending machine 64 may include peripheral devices 68 (e.g., sensors, actuators) that report data 70 back to the cloud computing infrastructure 69 via an embedded PC 71 when actionable conditions are detected (e.g., resulting in condition based fleet management). The data 70 may include information, alerts, etc., regarding the quality of products (e.g., beverages, snacks, etc.) dispensed by the vending machines 64, as well as predictions of future failures of the vending machines 64. Conducting quality analysis and/or failure predictions locally at the vending machines 64 may reduce WWAN (wireless wide area network) bandwidth usage and further enhance efficiency.” Note – see figure 5 of Hough that discloses that the cloud computing system 69 communicates between the embedded PC which communicates with peripherals 46 and 50 of figure 4.)
Claims 2, 10, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Basterash in view of Hough in further view of Donahue in further view of Erickson et al. (PG Pub. No. 20160370835), herein “Erickson.”
Regarding claim 2,
The previously cited references teach the limitations of claim 1 which claim 2 depends. They do not teach a power over Ethernet (POE) to provide USB power. However, Erickson does teach that the embedded computer is connected to an Ethernet network and receives power over Ethernet (PoE), wherein the embedded computer is configured to power the one or more circuits based on the PoE and provide USB power to the one or more of peripheral USB building devices via the PoE. (Par. 0072: “Some embodiments of the PoE-to-USB power conversion device described herein can also be configured to transfer data as well as power. According to such embodiments, in addition to converting PoE power to USB power, the conversion device can also transfer data between the USB port of the conversion device and the PoE-enabled Ethernet network. FIG. 12 illustrates an example configuration that uses a conversion device 1206 to both convert PoE power to USB power and transfer data between a USB device and a PoE-enabled Ethernet network. Conversion device 1206 includes an RJ45 plug 1208 configured to interface with an Ethernet port 1210 in wall plate 1212. Ethernet port 1210 is connected to a network device 1218 (e.g., a server, a router, a hub, a switch, etc.) via Ethernet cable 1216 (e.g., a CAT-5 cable) on the other side of wall 1214. Similar to previous examples, conversion device 1206 converts PoE power on cable 1216 to USB power, which is delivered to a USB port 1224 on the outward face of conversion device 1206. Thus, plugging a portable device 1202 into the USB port 1224 of conversion device 1206 facilitates charging of the portable device 1202 using the converted PoE power. As described in previous examples, conversion device 1206 can determine the rated charging current of portable device 1202 when the device is plugged into the USB port 1224, and set its internal conversion component to provide a level of charging current commensurate with the charging capability of the device 1202 (e.g., by configuring an output circuit that outputs the converted PoE power to the USB port 1224.” Par. 0076. See also Par. 0007 – 0013, 0076, 0114 and figure 12, 13, and 21.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the building automation system that details a building automation controller and exchanges both sensor data and controlling signals with the peripheral devices via USB as in Basterash with a system and method that incorporates an embedded computing device and communicates with peripherals by USB, wherein the peripherals are part of a building system such as home appliances or industrial appliances and the USB is an RS-232 protocol as in Hough with controlling a building HVAC device that is connected to a controller by a USB connection wherein control signals control at least the temperature and/or the valve of the building HVAC device as in Donahue with a computing device that power USB peripheral devices using power over Ethernet as in Erickson in order to convert existing legacy data ports such as PoE that are current installed to USB charging ports in the building peripheral devices. (Par. 0008 and 0103)
Regarding claim 10,
The previously cited references teach the limitations of claim 1 which claim 10 depends. They do not teach a power over Ethernet (POE) network that has a site director and a gateway as defined in claim 10. However, Erickson does teach that the system further comprises a USB host gateway, wherein the USB host gateway is configured to connect to an Ethernet network and implement a second USB host, wherein the USB host gateway is configured to facilitate communication between a site director system connected to the Ethernet network and a second one or more of peripheral USB building devices connected via the USB connection to the USB host gateway. (Par. 0076: “USB-to-TCP/IP conversion device 1300 can be used to complete a USB connection over an Ethernet network. In a non-limiting example application, a USB peripheral device 1326 (e.g., a speaker, a webcam, a printer, etc.) can be plugged into USB port 1310 using a USB cable 1302 by means of USB connector 1328. A computer 1322 located in another room is connected to an existing Ethernet network via router 1320. An Ethernet plug 1318 terminated to Ethernet cable 1324 of router 1320 can be plugged into RJ45 port 1316 of USB-to-TCP/IP conversion device 1300, thereby networking computer 1322 to the conversion device 1300. Once connected in this manner, USB-to-TCP/IP converter 1314 can facilitate data exchange between USB peripheral device 1326 and computer 1322. That is, USB-to-TCP/IP converter 1314 converts TCP/IP data from computer 1322 to USB-formatted data and sends the data to USB peripheral device 1326 via USB port 1310, and converts USB data from USB peripheral device 1326 to TCP/IP data and sends the converted data to the computer via the Ethernet network. In this way, USB-to-TCP/IP conversion device 1300 allows computer 1322 to communicate with USB peripheral devices (e.g., USB peripheral device 1326) over longer distances than can be achieved using USB alone by leveraging TCP/IP protocol.” Par. 0078: “For applications in which computer 1322 is required to exchange data with the USB peripheral device 1326 using a native USB port on the computer, another USB-to-TCP/IP conversion device 1300 can be installed near computer 1322 (e.g., between router 1320 and computer 1322) to facilitate converting Ethernet data received from the USB peripheral device 1326 back to USB at the computer end. FIG. 14 is a diagram illustrating the use of USB-to-TCP/IP conversion devices 1300 to establish a remote USB port. In this example, two USB-to-TCP/IP conversion devices 1300a and 1300b are mounted on walls in different areas (e.g., in different rooms, or on different walls within the same room). The example shown in FIG. 14 depicts each conversion device 1300a and 1300b as being a single-port device (as opposed to the dual-port device of FIG. 13). Similar to the example depicted in FIG. 13, each conversion device 1300a and 1300b includes a USB-to-TCP/IP converter 1314 that converts between TCP/IP data received or sent via an RJ45 connector (or terminals) on the in-wall (rear) side of the conversion devices 1300a and 1300b, and USB data received or sent via the USB ports 1310a and 1310b on the outward-facing side of the conversion devices.” Par. 0082: “In addition to the data conversion features described above, some embodiments of the conversion devices 1300a and 1300b can also include PoE-to-USB power conversion features described in previous examples. In this way, if network 1402 is PoE-enabled—e.g. if network 1402 includes a PoE injector, PoE switch, or other type of PoE power supply—the USB ports 1310a and 1310b are also capable of providing USB power by virtue of the PoE-to-USB power conversion functionality. As an alternative to a PoE injector or switch, PoE power may be supplied to the network 1402 by USB peripheral device 1404 (e.g., a phone, a tablet computer, a desktop computer, a laptop computer, etc.) or computer 1406.”)
Regarding claim 11,
The previously cited references teach the limitations of claim 10 which claim 11 depends. Erickson also teach that the wherein the USB host gateway is further configured to implement a USB hub. (Par. 0065: “That is, each of the Ethernet ports 604 is connected to an Ethernet cable that runs within or through the wall and connects to a network infrastructure device (e.g., a switch, a router, a hub, a server or other networked device, etc.). Power is provisioned on the one or more Ethernet networks by virtue of a PoE switch, PoE injector, or other such power source, rendering the Ethernet ports 604 PoE-enabled.” Par. 0071: “RJ45 plug 1104 can then be plugged into a port of an existing network infrastructure device (e.g., PoE switch, hub, router, networked device, etc.) to provide PoE power to the power conversion device 102.” Par. 0072: “Conversion device 1206 includes an RJ45 plug 1208 configured to interface with an Ethernet port 1210 in wall plate 1212. Ethernet port 1210 is connected to a network device 1218 (e.g., a server, a router, a hub, a switch, etc.) via Ethernet cable 1216 (e.g., a CAT-5 cable) on the other side of wall 1214.” Basterash also teaches a USB hub comprising USB ports 20. See Par. 0029 and figure 1.)
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Basterash in view of Hough in further view of Donahue in further view of Ng et al. (PG Pub. No. 20200089637), herein “Ng” with a provisional filing date of September 16, 2018.
Regarding claim 3,
The previously cited references teach the limitations of claim 1 which claim 3 depends. They do not teach the elements of a first and second USB building device that communicates via a USB Hub and an embedded computer. However, Ng does teach that a first peripheral USB building device of the one or more of peripheral USB building devices comprises a USB hub circuit; wherein a second peripheral USB building device of the one or more of peripheral USB building devices communicates to the embedded computer via a first USB connection to the USB hub circuit of the first peripheral USB building device and a second USB connection between the USB hub circuit and the embedded computer. (Par. 0006: “] Referring to FIG. 1, USB devices 101 and USB hub 103 were originally used only with personal computers 102 and corresponding device drivers in order to interface with different kinds of USB peripheral devices. In conventional systems, a device driver 204 (see FIG. 3) is required to allow the personal computer (PC) operating system 201 to drive the specific USB hardware. Each USB device uses either a unique device driver 204 or adopts the corresponding defined class driver so that the upper application layer 206 is able to use the USB I/O (see FIG. 3). As is well known in the art, the Windows OS 201 includes a Kernel Mode 202 and User Mode 203. The Kernel Mode includes the Kernel Mode Client Driver as well as USB Host Controller and Driver 205. The User Mode 203 includes the User-Mode Client Driver, the Windows API and the upper application layer 206. USB device driver 104 can be locally loaded onto the operating system or remotely loaded onto the operating system from a central repository 105 (see FIG. 2) which may be a vendor's web site. These specific drivers are required in order for the USB I/O device to operate under the hardware and operating system. USB devices are mostly built for PC applications and current defined device-classes are confined for PC applications. Adopting the USB connection technology for IoT applications will expand the variety of applications for USB I/O devices. The existing defined device-classes are not capable of covering IoT applications. Therefore, new device drivers are necessary for new USB applications. The original design of a device driver is highly dependent on the operating system (OS) such as Windows, Linux or other embedded OS. A further disadvantage is that the device driver is also dependent upon the particular version of the OS. Such a situation complicates the development and maintenance of the device drivers by the USB I/O device manufacturers. FIG. 1 shows standard connections between USB peripheral devices 101 and a main personal computer (PC) system 102 either directly or via a USB hub 103. The configuration shown in FIG. 1 is a conventional system-centric I/O configuration wherein all I/O devices are connected to and controlled by the combination of the personal computer CPU system and its operating system (OS). All I/O operation is built upon upper application layer 206 (see FIG. 3).” Par. 0053: “The present invention is directed to a system and method to enable a USB I/O device to operate as an IoT device without building specific device drivers for the USB I/O device and without making any modifications to the USB I/O device. Many smart devices use a USB I/O as an interface for data communication, data transfer and receiving DC power supply voltage and current. External devices may control the USB I/O device through the network. Referring to FIGS. 4 and 5, the USB I/O 101 is interfaced to the network via a Network Interface Module 301 so as to enable the USB I/O device to communicate through the network. The combination of the Net Interface Module and the USB I/O device functions as “Thing” 302 which is capable of operating in the Internet of Things (IoT) environment. The details of the Network Interface Module are described in the ensuing description. The Internet of Things (IoT) is defined as a network of connected I/O devices that are able to communicate with each other within the existing network (e.g. Internet) infrastructure. In such a network, the focus is on the connected Thing 302, i.e. the I/O device. Therefore, such a network is based on an I/O-centric platform (see FIG. 5). In this network 401, Things 302 are connected to and distributed over the network. However, Things 302 are not constrained to any main system. Each Thing 302 can be a single I/O device, e.g. an air conditioner, or a combination of a USB I/O device and Network Interface Module 301 (see FIG. 4). Control terminal 402 is a control device such as a remote control console, smart phone or smart speaker. Control gateway 403 enables the network of connected I/Os to connect to the Internet or act as central management unit for locally connected Things 302.” See also Par. 0022.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the building automation system that details a building automation controller and exchanges both sensor data and controlling signals with the peripheral devices via USB as in Basterash with a system and method that incorporates an embedded computing device and communicates with peripherals by USB, wherein the peripherals are part of a building system such as home appliances or industrial appliances and the USB is an RS-232 protocol as in Hough with controlling a building HVAC device that is connected to a controller by a USB connection wherein control signals control at least the temperature and/or the valve of the building HVAC device as in Donahue with devices that communicate with a computing device that entails a hub where the USB devices that may be an air conditioner communicates by connections via a USB Hub as in Ng in order to interface a USB device and allow the USB device to function as a IoT device which does not require a specific driver. (Par. 0008)
Regarding claim 14,
The previously cited references teach the limitations of claim 1 which claim 14 depends. Ng teaches that the one or more of peripheral USB building devices comprise a USB input and output module (IOM);wherein the USB IOM comprises one or more second circuits, one or more physical inputs, and one or more physical outputs; wherein the one or more second circuits are configured to: receive the building data via the one or more physical inputs; communicate the building data to the embedded computer via a USB connection; receive the one or more control decisions via the USB connection from the embedded computer; and operate the one or more physical outputs based on the one or more control decisions. (Par. 0053: “The present invention is directed to a system and method to enable a USB I/O device to operate as an IoT device without building specific device drivers for the USB I/O device and without making any modifications to the USB I/O device. Many smart devices use a USB I/O as an interface for data communication, data transfer and receiving DC power supply voltage and current. External devices may control the USB I/O device through the network. Referring to FIGS. 4 and 5, the USB I/O 101 is interfaced to the network via a Network Interface Module 301 so as to enable the USB I/O device to communicate through the network. The combination of the Net Interface Module and the USB I/O device functions as “Thing” 302 which is capable of operating in the Internet of Things (IoT) environment. The details of the Network Interface Module are described in the ensuing description. The Internet of Things (IoT) is defined as a network of connected I/O devices that are able to communicate with each other within the existing network (e.g. Internet) infrastructure. In such a network, the focus is on the connected Thing 302, i.e. the I/O device. Therefore, such a network is based on an I/O-centric platform (see FIG. 5). In this network 401, Things 302 are connected to and distributed over the network. However, Things 302 are not constrained to any main system. Each Thing 302 can be a single I/O device, e.g. an air conditioner, or a combination of a USB I/O device and Network Interface Module 301 (see FIG. 4). Control terminal 402 is a control device such as a remote control console, smart phone or smart speaker. Control gateway 403 enables the network of connected I/Os to connect to the Internet or act as central management unit for locally connected Things 302.” See also Par. 0005, 0006, 0007, 0022, 0029, 0056, 0064 – 0067, See also Basterash Par. 0028 and 0031.)
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Basterash in view Hough in further view of Donahue in further view of Korean patent document Goo et al. (KR 20070107983 A) herein “Goo.”
Regarding claim 5,
The previously cited references teach the limitations of claim 1 which claim 3 depends. They do not teach licensing data that is sent to the embedded computer. However, Goo does teach that a first peripheral USB building device (USB home controller) of the one or more of peripheral USB building devices is configured to: store licensing data associated with one or more features for the first peripheral USB building device; and communicate the licensing data to the embedded computer via the USB connection in response to being connected to the embedded computer via the USB connection; wherein the one or more circuits of the embedded computer are configured to: receive the licensing data via the USB connection; enforce the licensing data on the one or more circuits enabling the one or more features; and perform the one or more features by generating result data based on collected building data of the first peripheral USB building device or performing one or more control operations for the first peripheral USB building device. (Page 4, Par. 4 and 5: “Preferably, when the MCU of the many-to-many wireless USB hub starts wireless data communication with the wireless USB home controller of the remote control target, the MCU performs an authentication procedure based on the unique ID included in the authentication request from the wireless USB home controller. It will contain the controls to execute. Correspondingly, the MCU of the wireless USB home controller licensed by the authentication procedure includes a control for storing the authentication number transmitted under the control of the MCU of the wireless USB hub to complete the authentication.” See also page 9, paragraph 6 and other paragraphs describing use of the home controller by way of authentication.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the building automation system that details a building automation controller and exchanges both sensor data and controlling signals with the peripheral devices via USB as in Basterash with a system and method that incorporates an embedded computing device and communicates with peripherals by USB, wherein the peripherals are part of a building system such as home appliances or industrial appliances and the USB is an RS-232 protocol as in Hough with controlling a building HVAC device that is connected to a controller by a USB connection wherein control signals control at least the temperature and/or the valve of the building HVAC device as in Donahue with communicating licensing data to a MCU from a USB peripheral device (USB home controller) as in Goo in order to ensure the security and stability while a plurality of wireless USB home controller is actively connected to a single wireless USB hub. (Page 11, Par. 5)
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Basterash in view of Hough in further view of Donahue in further view of Lamont et al. (US PG Pub. No. 20200225653) herein “Lamont.”
Regarding claim 7,
The previously cited references teach the limitations of claim 1 which claim 3 depends. They do not teach that a USB peripheral device form an air handling unit package. However, Lamont does teach that the embedded computer (MCU 246 and/or SOC 248; see also monitoring center module 240) and the one or more of peripheral USB building devices form an air handler unit (AHU) package, wherein the embedded computer is configured to perform one or more control operations for an AHU and the one or more of peripheral USB building devices are AHU sensors and AHU actuators of the AHU. (Par. 0055: “The air handler module 210 can comprise of an air handler PCB 211 which can comprise one or more GPIOs (not shown) or electrical inputs that can connect one or more sensors directly to the monitoring center module 240 or the monitoring center module can comprise of GPIOs that can be incorporated to the air handler module as one system, or the air handler module can be its own system having a MCU, memory medium, and a communications device that can transmit information to the monitoring center module. The monitoring center module 240 can include one or more expansion ports such as GPIOs, LAN port, USB ports, or the like to allow for additional connection of sensors and/or allow connections for other devices such as computer device, handheld computer device, tablets, and or a home security system. The air handler module 210 can monitor, but are not limited to, current, voltage, pressures, and temperatures. The air handler module 210 can further comprise at least one sensor wherein the sensor can be, but not limited to, an air handler motor current transducer 212, one or more temperature sensors such as a return air temperature 214 and a supply air temperature 216, a fluid detection sensor 218, and a flow meter 220 wherein the air handler motor current transducer 212 can measure the current delivered to the air handler unit 226 from the electrical panel (not shown). The air handler motor current transducer 212 can be the same as the condenser unit's main current transducer 278. The air handle motor current transducer 212 can be connected to, clamped around, or attached to the circular blower 228 by its wires, or within the circulator blower itself. In other embodiments, the circular blower 228 can be monitored by a speed switch to monitor critical speed, and guard against slowdown or stoppage during nominal operation. The motor current transducer 212 can be attached to and monitored by either the monitoring center module 240, or the air handler module 210.” See figure 3.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the building automation system that details a building automation controller and exchanges both sensor data and controlling signals with the peripheral devices via USB as in Basterash with a system and method that incorporates an embedded computing device and communicates with peripherals by USB, wherein the peripherals are part of a building system such as home appliances or industrial appliances and the USB is an RS-232 protocol as in Hough with controlling a building HVAC device that is connected to a controller by a USB connection wherein control signals control at least the temperature and/or the valve of the building HVAC device as in Donahue with a USB device that forms an air handling unit package (air handling module combined with monitoring center module) that has USB ports and that has sensors and air handling motors (actuators) as in Lamont in order to allow connections of other devices between the air handler such as a computer device, tablet, or home security system. (Par. 0055)
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Basterash in view of Hough in further view of Donahue in further view of Brantner et al. (US PG Pub. No. 20160209899) herein “Brantner.”
Regarding claim 20,
The previously cited references teach the limitations of claim 19 which claim 20 depends. They do not teach that a USB cloud based device. However, Brantner does teach that the external cloud-based processor is USB device. (Par. 0099: “As discussed above, the power switching device 10 may include a USB port accessible through an opening 29 of the housing 12 of the power switching device 10. The USB connection may be utilized to control, monitor, or transfer data to the USB device. Furthermore, power switching device 10 may include a plurality of USB ports so that a plurality of USB devices may be connected thereto and remotely monitored and/or wirelessly controlled, e.g., by computing device 80, or a device within cloud 81, via the communications components of the power switching device 10. Similarly, data obtained from or associated with the USB devices may be stored within on board memory of the microcontroller 65 of the power switching device 10, “local” USB devices such as desktop computers, devices on the local network or the cloud, or any other device connectible to the USB device via the communications bridge of the device 10.” See also Brantner claims 1, 26, and 32.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the building automation system that details a building automation controller and exchanges both sensor data and controlling signals with the peripheral devices via USB as in Basterash with a system and method that incorporates an embedded computing device and communicates with peripherals by USB, wherein the peripherals are part of a building system such as home appliances or industrial appliances and the USB is an RS-232 protocol as in Hough with controlling a building HVAC device that is connected to a controller by a USB connection wherein control signals control at least the temperature and/or the valve of the building HVAC device as in Donahue with a USB cloud device as in Brantner in order to communicate by a public communication platform by a cloud to control those USB devices. (Par. 0078).
Allowable Subject Matter
Claim 4 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims pending resolving all intervening issues such as any 35 U.S.C. §112(b) rejections above and the deletion of the word “optionally” in claim 4. Reasons for allowance will be held in abeyance pending final recitation of the claims. The prior art does not disclose the elements of claim 1 and wherein at least a first peripheral USB building device of the one or more of peripheral USB building devices is configured to communicate identifying 61information to the embedded computer in response to being connected to the embedded computer via the USB connection; wherein the one or more circuits of the embedded computer are configured to: receive the identifying information and identify driver software for the first peripheral USB building device and a control algorithm for the first peripheral USB building device; optionally generate the one or more control decisions for the first peripheral USB building device based on the control algorithm; and communicate the one or more control decisions to the first peripheral USB building device via the USB connection with the driver software.
Claim 6 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Reasons for allowance will be held in abeyance pending final recitation of the claims. The prior art does not disclose the elements of claim 1 and that the system further comprises a USB host actuator, wherein the USB host actuator is configured to connect to an Ethernet network and implement a second USB host, wherein the USB host actuator is configured to facilitate communication between a site director system connected to the Ethernet network and a second one or more of peripheral USB building devices connected via the USB connection to the USB host actuator.
Claims 21 and 22 are allowable as they include the features of independent claim 1, and dependent claims 4 and 6, respectively, that were objected to in the previous and this action.
Response to Arguments
Applicant’s arguments state that Basterash is different than the claimed invention; and applicant has also amended claim 1. The main argument states that “Basterash does not disclose, teach, or reasonably suggest a building system comprising an embedded computer, the embedded computer configured to "receive building data from at least one of the one or more of peripheral USB building devices," much less "generate one or more control decisions for the one or more of peripheral USB building devices.” Examiner is not persuaded by this argument. Paragraph 0029 and 0030 specifically teach that the primary controller receives and transfers data from the USB devices. Paragraph 0003 also states that the controllers are used to coordinate, manage, and automate building subsystems. Secondary reference of Hough also teaches appliance peripheral devices (Par. 0011, 0019, 0025) that are controlled by the HAL (Par. 0073). Paragraph 0019 teaches that the peripheral device may be a building device such as a home appliance or cooler, etc. and paragraph 0048 teaches that the peripheral device includes an actuator, on point with the amendment that discloses controlling a valve or damper position. Paragraph 0025 also teaches that the peripheral devices communicate and are controlled via a USB connection.
However, these arguments may be mute as a new reference was found that teaches the amended portions. Donahue teaches control devices such as an A/C unit and water heater that are controlled by an FM Receiver/controller. (See figures 4 and 5) As rejected above, paragraph 0118 teaches a USB connection. Paragraph 0117 and 0146 teaches controlling the control devices which may comprise boilers, chillers and valves. Even though Hough may implicitly teach the amended portion, The new reference of Donahue was necessitated by amendment and therefore this is a final office action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Belinsky et al. (WO 2016/179042 A1) (also as Alvey) may also teach the elements of claim 16. See paragraphs 0031, 0034 and Par. 0045: “The body of the adapter can have a connective element 205 that provides connection between the adapter and a device on an opposite side of the support. In some cases, the connective element can permit a user to plug in a device 208 to the adapter. The device can be a device that comprises one or more sensors. The device can be a device configured to monitor one or more conditions of an environment. In an example, the device can be a smoke detector, carbon monoxide (CO) detector, gas sensor, home alarm system, thermostat, humidity sensor, light detector, or any other device configured to monitor one or more environment conditions. The connective element can be configured to plug in to the device through a USB, micro USB, mini USB, VGA, or any other connection.”
Caron et al. (US PG Pub. No. 20150045960) teaches a BAS system and a controller that reads data from a peripheral device and sends data and programs to a peripheral. (Par. 0023 and 0024: “Referring now to FIG. 3 there is shown an example application of embodiments described herein, where a peripheral unit 50 communicates wirelessly with a controller 52 within a control (or BAS) network. In this example, the peripheral unit 50 is an actuator with an internal antenna. The controller 52 has an external antenna to read data 54 from the peripheral unit 50 and write data 56 to the peripheral unit 50 via the control network. The peripheral unit 50 may have an internal transceiver, such as a Zigbee transceiver, and an antenna, enabling it to communicate with a controller 52, gateway (not shown), other peripheral units (not shown), a central server (not shown), and other components of the BAS. The peripheral unit 50 may be configured for wireless communication, such as Zigbee wireless communication, for example, with a communication stack including, for example, Zigbee pro and a Zigbee cluster library.” [0024] The peripheral unit 50 may receive scripts and programs over the wireless network from the controller 52, for example, and store and interpret them locally using the embedded interpreter. The controller 52 can read data from the peripheral unit 50 to check customer variables, such as specified set points, and to determine whether the most up to date script or program resides on the peripheral unit 50. That is, the peripheral unit 50 may communicate wirelessly with other devices of a BAS network, receive programs, commands, and data from the BAS network as well as push data and commands to other devices of the BAS network.” See also Par. 0019.)
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAD G ERDMAN whose telephone number is (571)270-0177. The examiner can normally be reached Mon - Fri 7am - 3pm or 4pm EST..
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, Kenneth Lo can be reached at (571) 272-9774. 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.
/CHAD G ERDMAN/Primary Examiner, Art Unit 2116