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
Status
This instant application No. 18/322,438 has Claims 1-20 pending.
Priority / Filing Date
Applicant claimed priority from U.S. provisional application No. 63/365,983. The priority filing date of this application is June 7, 2022.
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 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 of this title, 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.
3. Claims 1-20 are rejected under 35 U.S.C. 103 as being obvious over Crettenand et al. hereafter Crettenand (Pub. No.: US 2023/0119043 A1), in view of Oberstein et al. hereafter Oberstein (Pub. No.: US 2016/0182667 A1).
Regarding Claim 1, Crettenand discloses a computer-implemented method for implementing an architecture for a smart building (Crettenand: abstract), comprising:
receiving, by one or more computer processors of a hub of the smart building, speech input from a smart speaker (Crettenand: [0025], [0026]: smart speaker),
wherein the speech input describes a plurality of asynchronous events associated with a plurality of smart devices in the smart building (Crettenand: [0025]-[0027]: smart speaker, state of audio input processing; [0039]: review of events (e.g., motion, audio, security, etc.) from data captured by the smart devices 120), and
converting the plurality of asynchronous events to at least one of a trigger, a condition, or an action to be performed by at least one smart device of the plurality of smart devices (Crettenand: Figure 1, [0043]: detect a light condition in the smart home environment 100; [0027]: voice-activated electronic devices; [0061]: For example, the first app 401 may receive status data from the smart home device 405, may send commands to the smart home device 405, may generate automation sequences involving the smart home device 405, and so forth);
generating an automated flow for controlling (Crettenand: Figures 1, 6, [0061], [0073]: generate automation sequences involving the smart home device; ……FIG. 6 illustrates a flow diagram 600 of a process for sharing a device between two apps; [0084]: process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may have described the operations as a sequential process, many of the operations can be performed in parallel or concurrently).
and
wherein the at least one smart device corresponds to at least one node in the automated flow (Crettenand: Figure 3, [0054], [0055]: this disclosure uses the term "multi-ecosystem protocol" to generically refer to any application layer protocol that allows different smart home ecosystems and devices to interoperate);
determining that a third-party device is installed in the smart building (Crettenand: Figure 3, [0054], [0056], [0080]: the Google Home® smart phone app may be used to control a Google Nest® doorbell, along with a smart appliance from another manufacturer within the same app);
responsive to determining that the third-party device is installed:
generating (Crettenand: Figure 3, [0054], [0055]: this disclosure uses the term "multi-ecosystem protocol" to generically refer to any application layer protocol that allows different smart home ecosystems and devices to interoperate); and
generating (Crettenand: Figure 3, [0054], [0055], [0057]: Specifically, the multi-ecosystem protocol operating, for example, on Wi-Fi and Thread network layers using BLE for device setup may allow the first device 302 and/for the second device 304 to be commissioned individually and controlled within the separate ecosystem of the application operating on the control device 308); and
operating the at least one smart device and the third-party device using at least one microservice to issue remote procedure calls (RPCs) from the hub via the at least (Crettenand: Figures 1, 3; [0040]: The hub device 180 is further communicatively coupled to one or more of the above intelligent, multi-sensing, network-connected devices (e.g., the cast devices 108, the electronic devices 190, the smart home devices and the client device 104). Each of these network-connected devices optionally communicates with the hub device 180 using one or more radio communication networks available at least in the smart home environment 100 (e.g., ZigBee, Z-Wave, Insteon, Bluetooth, Wi-Fi and other radio communication networks); [0039]: a cloud cast service server 116 creating a virtual user domain based on distributed device terminals; [0054], [0055], [0057]: Specifically, the multi-ecosystem protocol operating, for example, on Wi-Fi and Thread network layers using BLE for device setup may allow the first device 302 and/for the second device 304 to be commissioned individually and controlled within the separate ecosystem of the application operating on the control device 308).
Crettenand do not explicitly disclose
Generating an adapter and a node; and
wherein the hub is connected to a cloud Web Application Messaging Protocol (WAMP) router located in a cloud;
Oberstein discloses:
Generating an adapter (Oberstein: Figure 54, [0367], [0368]: Adapter 5490 is connected to both WAMP routers as a WAMP client); and a node (Oberstein: Figures 59-61, [0375]-[0379]: Crossbar.io node); and
wherein the hub is connected to a cloud Web Application Messaging Protocol (WAMP) router located in a cloud (Oberstein: Figures 21-23; [0114]- [0124]: FIG. 22 is a diagram showing the roles which WAMP routers and WAMP clients can implement to enable them to participate in the Call-and-Register and Publish-and Subscribe messaging patterns which WAMP provides………..FIG. 23 is a diagram illustrating elements of a WAMP connection between a WAMP router 2110 and a WAMP client 2120……..implemented on another underlying transport layer, and that such transport layer need not fulfill all of the requirements).
Crettenand and Oberstein are analogous art because they are from the same field of endeavor. They both relate to management application.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the above smart home device application, as taught by Crettenand, and incorporating the use of management application for application routers., as taught by Oberstein.
One of ordinary skill in the art would have been motivated to do this modification in order to smart devices communicate with each other more effectively in order to exchange information and give access to their functionality, as suggested by Oberstein (Oberstein:[0003]).
Regarding Claim 15, the claim recites the same substantive limitations as Claim 1 and is rejected using the same teachings.
Regarding Claim 2, the combinations of Crettenand and Oberstein further disclose the computer-implemented method of claim 1, comprising:
preventing a first adapter operating a first smart device from communicating with a second adapter operating a second smart device of the smart building (Oberstein: Figure 54, [0367], [0368]: Application MSlO and Container Control Code MS30 are connected to different WAMP routers, Management Router 5400 and Node Management Router MS20 respectively. Adapter 5490 is connected to both WAMP routers as a WAMP client).
Regarding Claims 13 and 18, the claims recite the same substantive limitations as Claim 2 and are rejected using the same teachings.
Regarding Claim 3, the combinations of Crettenand and Oberstein further disclose the computer-implemented method of claim 1, wherein the automated flow is generated using a visual programming language (Crettenand: Figure 6, [0039], [0040], [0073]), and wherein the method comprises:
generating a graphical representation of the automated flow for display to a user on a graphical user interface (GUI) of the smart building, wherein the GUI is displayed on an electronic screen of the hub (Crettenand: Figure 5B, [0067]-[0070]) .
Regarding Claims 14 and 19, the claims recite the same substantive limitations as Claim 3 and are rejected using the same teachings.
Regarding Claim 4, the combinations of Crettenand and Oberstein further disclose the computer-implemented method of claim 1, comprising:
receiving text or graphical input from a user input device communicably coupled to the hub, wherein the text or graphical input references a first smart device (Crettenand: [0040], [0063]-[0064]: the term "share sheet" refers to a user interface that allows the user to share or text or other symbol data from one application to another application); and
modifying a portion of the automated flow corresponding to the first smart device (Crettenand: [0063]-[0064]: the core API from the operating system may be modified to generate an augmented share sheet).
Regarding Claim 20, the claim recites the same substantive limitations as Claim 4 and is rejected using the same teachings.
Regarding Claim 5, the combinations of Crettenand and Oberstein further disclose the
computer-implemented method of claim 1, wherein operating the at least one smart device and the third-party device obviates use of an Internet connection to the Hub (Crettenand: [0023], [0036], [0045], [0047]).
Regarding Claim 6, the combinations of Crettenand and Oberstein further disclose the
computer-implemented method of claim 1, wherein the at least one microservice uses publish/subscribe messaging from the hub via the at least one adapter and the new adapter to the at least one smart device and the third-party device while obviating communication between the hub and the cloud (Crettenand: Figures 1, 3; [0040]: The hub device 180 is further communicatively coupled to one or more of the above intelligent, multi-sensing, network-connected devices (e.g., the cast devices 108, the electronic devices 190, the smart home devices and the client device 104). Each of these network-connected devices optionally communicates with the hub device 180 using one or more radio communication networks available at least in the smart home environment 100 (e.g., ZigBee, Z-Wave, Insteon, Bluetooth, Wi-Fi and other radio communication networks); [0039]: a cloud cast service server 116 creating a virtual user domain based on distributed device terminals; [0054], [0055], [0057]: Specifically, the multi-ecosystem protocol operating, for example, on Wi-Fi and Thread network layers using BLE for device setup may allow the first device 302 and/for the second device 304 to be commissioned individually and controlled within the separate ecosystem of the application operating on the control device 308).
Regarding Claim 12, the claim recites the same substantive limitations as Claim 6 and is rejected using the same teachings.
Regarding Claim 7, the combinations of Crettenand and Oberstein further disclose the
computer-implemented method of claim 1, comprising:
adding the at least one adapter, the at least one smart device, and the at least one microservice to a registry database (Crettenand: [0039]: The server system 140 also includes a device registry for keeping a record of the distributed device terminals in the virtual user environment); and
generating create, read, update and delete (CRUD) operations of the registry
database via the RPCs (Crettenand: [0040]: Each of these network-connected devices optionally communicates with the hub device 180 using one or more radio communication networks available at least in the smart home environment 100 (e.g., ZigBee, Z-Wave, Insteon, Bluetooth, Wi-Fi and other radio communication networks). In some implementations, the hub device 180 and devices coupled with/to the hub device can be controlled and/or interacted with via an application running on a smart phone, household controller, laptop, tablet computer, game console or similar electronic device).
Regarding Claim 8, Crettenand discloses a computer-implemented hub (Crettenand: [0040]) comprising:
one or more computer processors (Crettenand: [0006]); and
a non-transitory, computer-readable storage medium storing instructions, which when executed by at least one of the one or more computer processors cause the computer-implemented hub (Crettenand: [0044]); to:
receive information describing a plurality of asynchronous events associated with a plurality of smart devices in a smart building (Crettenand: [0025]-[0027]: smart speaker, state of audio input processing; [0039]: review of events (e.g., motion, audio, security, etc.) from data captured by the smart devices 120);
convert the plurality of asynchronous events to at least one of a trigger, a condition, or an action to be performed by at least one smart device of the plurality of smart devices (Crettenand: Figure 1, [0043]: detect a light condition in the smart home environment 100; [0027]: voice-activated electronic devices; [0061]: For example, the first app 401 may receive status data from the smart home device 405, may send commands to the smart home device 405, may generate automation sequences involving the smart home device 405, and so forth);
generate an automated flow for controlling at least (Crettenand: Figures 1, 6, [0061], [0073]: generate automation sequences involving the smart home device; ……FIG. 6 illustrates a flow diagram 600 of a process for sharing a device between two apps; [0084]: process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may have described the operations as a sequential process, many of the operations can be performed in parallel or concurrently);
determine that a third-party device is installed in the smart building (Crettenand: Figure 3, [0054], [0056], [0080]: the Google Home® smart phone app may be used to control a Google Nest® doorbell, along with a smart appliance from another manufacturer within the same app);
responsive to determining that the third-party device is installed:
generate (Crettenand: Figure 3, [0054], [0055]: this disclosure uses the term "multi-ecosystem protocol" to generically refer to any application layer protocol that allows different smart home ecosystems and devices to interoperate); and
generate (Crettenand: Figure 3, [0054], [0055], [0057]: Specifically, the multi-ecosystem protocol operating, for example, on Wi-Fi and Thread network layers using BLE for device setup may allow the first device 302 and/for the second device 304 to be commissioned individually and controlled within the separate ecosystem of the application operating on the control device 308); and
operate the at least one smart device and the third-party device in accordance with the automated flow (Crettenand: Figures 1, 3; [0040]: The hub device 180 is further communicatively coupled to one or more of the above intelligent, multi-sensing, network-connected devices (e.g., the cast devices 108, the electronic devices 190, the smart home devices and the client device 104). Each of these network-connected devices optionally communicates with the hub device 180 using one or more radio communication networks available at least in the smart home environment 100 (e.g., ZigBee, Z-Wave, Insteon, Bluetooth, Wi-Fi and other radio communication networks); [0039]: a cloud cast service server 116 creating a virtual user domain based on distributed device terminals; [0054], [0055], [0057]: Specifically, the multi-ecosystem protocol operating, for example, on Wi-Fi and Thread network layers using BLE for device setup may allow the first device 302 and/for the second device 304 to be commissioned individually and controlled within the separate ecosystem of the application operating on the control device 308).
Crettenand do not explicitly disclose
Generate an adapter and a node; and
wherein the hub is connected to a cloud Web Application Messaging Protocol (WAMP) router located in a cloud;
Oberstein discloses:
Generate an adapter (Oberstein: Figure 54, [0367], [0368]: Adapter 5490 is connected to both WAMP routers as a WAMP client); and a node (Oberstein: Figures 59-61, [0375]-[0379]: Crossbar.io node);
Regarding Claim 9, the combinations of Crettenand and Oberstein further disclose the
computer-implemented hub of claim 8, wherein the computer-implemented hub is connected to a cloud Web Application Messaging Protocol (WAMP) router located in a cloud (Oberstein: Figures 21-23; [0114]- [0124]: FIG. 22 is a diagram showing the roles which WAMP routers and WAMP clients can implement to enable them to participate in the Call-and-Register and Publish-and Subscribe messaging patterns which WAMP provides………..FIG. 23 is a diagram illustrating elements of a WAMP connection between a WAMP router 2110 and a WAMP client 2120……..implemented on another underlying transport layer, and that such transport layer need not fulfill all of the requirements).
Regarding Claim 10, the combinations of Crettenand and Oberstein further disclose the
computer-implemented hub of claim 8, wherein the at least one adapter operates the at least one smart device (Crettenand: Figure 3, [0054], [0055], [0057]: Specifically, the multi-ecosystem protocol operating, for example, on Wi-Fi and Thread network layers using BLE for device setup may allow the first device 302 and/for the second device 304 to be commissioned individually and controlled within the separate ecosystem of the application operating on the control device 308; Oberstein: Figure 54, [0367], [0368]: Adapter 5490 is connected to both WAMP routers as a WAMP client), and
wherein the at least one smart device corresponds to an existing node in the automated flow (Crettenand: Figure 3, [0054], [0055]: this disclosure uses the term "multi-ecosystem protocol" to generically refer to any application layer protocol that allows different smart home ecosystems and devices to interoperate; Oberstein: Figures 59-61, [0375]-[0379]: Crossbar.io node).
Regarding Claim 11, the combinations of Crettenand and Oberstein further disclose the
computer-implemented hub of claim 8, wherein the at least one smart device and the third-party device are operated using at least one microservice to issue remote procedure calls (RPCs) from the computer-implemented hub via the at least one adapter and the new adapter to the at least one smart device and the third-party device over a hub WAMP router (Crettenand: Figures 1, 3; [0040]: The hub device 180 is further communicatively coupled to one or more of the above intelligent, multi-sensing, network-connected devices (e.g., the cast devices 108, the electronic devices 190, the smart home devices and the client device 104). Each of these network-connected devices optionally communicates with the hub device 180 using one or more radio communication networks available at least in the smart home environment 100 (e.g., ZigBee, Z-Wave, Insteon, Bluetooth, Wi-Fi and other radio communication networks); [0039]: a cloud cast service server 116 creating a virtual user domain based on distributed device terminals; [0054], [0055], [0057]: Specifically, the multi-ecosystem protocol operating, for example, on Wi-Fi and Thread network layers using BLE for device setup may allow the first device 302 and/for the second device 304 to be commissioned individually and controlled within the separate ecosystem of the application operating on the control device 308; Oberstein: Figure 54, [0367], [0368]: Adapter 5490 is connected to both WAMP routers as a WAMP client).
Regarding Claim 16, the combinations of Crettenand and Oberstein further disclose the
non-transitory, computer-readable storage medium of claim 15, wherein the instructions cause the one or more computer processors to:
receive information describing a plurality of asynchronous events associated with a plurality of smart devices in the smart building (Crettenand: Figure 1, [0043]: detect a light condition in the smart home environment 100; [0027]: voice-activated electronic devices; [0061]: For example, the first app 401 may receive status data from the smart home device 405, may send commands to the smart home device 405, may generate automation sequences involving the smart home device 405, and so forth), wherein the hub is connected to a cloud WAMP router located in the cloud (Oberstein: Figures 21-23; [0114]- [0124]: FIG. 22 is a diagram showing the roles which WAMP routers and WAMP clients can implement to enable them to participate in the Call-and-Register and Publish-and Subscribe messaging patterns which WAMP provides………..FIG. 23 is a diagram illustrating elements of a WAMP connection between a WAMP router 2110 and a WAMP client 2120……..implemented on another underlying transport layer, and that such transport layer need not fulfill all of the requirements).
Regarding Claim 17, the combinations of Crettenand and Oberstein further disclose the
non-transitory, computer-readable storage medium of claim 16, wherein the instructions cause the one or more computer processors to:
convert the plurality of asynchronous events to the at least one of the trigger, the condition, or the action, wherein the action is to be performed by the at least one smart device (Crettenand: Figure 1, [0043]: detect a light condition in the smart home environment 100; [0027]: voice-activated electronic devices; [0061]: For example, the first app 401 may receive status data from the smart home device 405, may send commands to the smart home device 405, may generate automation sequences involving the smart home device 405, and so forth).
Conclusion
4. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sandeep Jain (Pub. No.: US 2017 /0099176 A1) teaches a containerized architecture to secure and manage Internet connected devices, such as "Internet of Things" devices. The containerized applications is a management agent configured to participate, subject to control of the management server, in management of one or more other of said containerized applications.
Shim et al. (Pub. No.: US 2019/0098089 A1) teaches an internet-of-things (IoT) distribution hub enables delivery of formatted Io T data to any of multiple hosting platforms as dynamically configurable by an IoT device owner.
Ni et al. (Pub. No.: US 2021/0132559 A1) conceptually presents efficient control and/or linking of smart network connected devices by efficiently adding one or more particular smart devices of the 3P to the smart device topology.
Horling et al. (Pub. No.: US 2018/0330589 A1) discloses methods for monitoring and operating activity in a home environment by receiving an occupant voice command to operate in a monitoring mode;
Herman et al. (Pub. No.: US 2016/0301373 A1) discloses methods for dynamic volume adjustment. A signal including a detected distance to a person may be received from a proximity sensor of a smart home environment. A volume adjustment for a speaker of the smart home environment may be generated based on the detected distance to the person and a sound level associated with the detected distance to the person;
5. Examiner’s Remarks: Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. In the case of amending the claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
Correspondence Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IFTEKHAR A KHAN whose telephone number is (571)272-5699. The examiner can normally be reached on M-F from 9:00AM-6:00PM (CST). If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emerson Puente can be reached on (571)272-3652. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/IFTEKHAR A KHAN/Primary Examiner, Art Unit 2187
Prosecution Insights