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 .
Response to Amendment
Applicant's proposed amendment filed 10/2/2025 has been accepted and entered. Accordingly, claims 1-10 have been amended.
Claims 1-10 are pending in this application.
Regarding the objection of Claim 1, the objection has been cured by the amendments. Therefore, the objection has been withdrawn.
Regarding the 112b rejection of Claim 1, 4, and 10, the rejection has been cured by the amendments. Therefore, the rejection of claims 1, 4, and 10 has been withdrawn.
Regarding the 101 rejection of Claim 10, the rejection has been cured by the amendments. Therefore, the rejection of claim 10 has been withdrawn.
Response to Arguments
Applicant's arguments filed 10/02/2025 have been fully considered but they are not persuasive.
Argument: Although Hu describes provisioning and address allocation in a Bluetooth mesh network, Hu does not address, contemplate, or provide any mechanism by which a server can detect such simultaneous attempts and return an existing assigned address to prevent duplication. Rather, Hu assumes a sequential and controlled provisioning process that does not account for conflicting administrative inputs. (Remarks Pg. 11)
Response: Examiner respectfully disagrees. Hu, in at least ¶0108 describes a process of provisioning a single Bluetooth device when it is detected by two or more Bluetooth gateways, “an example in the context in which a single unprovisioned Bluetooth device is detected by two or more Bluetooth gateways, server 120 provides provisioning data for each unprovisioned Bluetooth device. In this context, server 120 determines one or more Bluetooth gateways that detect the unprovisioned Bluetooth device and then determines a particular Bluetooth gateway (e.g., a target gateway) from among the one or more Bluetooth gateways that detect the unprovisioned Bluetooth device. Server 120 provides the provisioning data of the unprovisioned Bluetooth device to the particular Bluetooth gateway, and thus the particular Bluetooth gateway performs a provisioning operation on the unprovisioned Bluetooth device. Thus, if server 120 receives an indication of a detected unprovisioned Bluetooth device from a plurality of Bluetooth gateways, the server provides the provisioning data for the unprovisioned Bluetooth device to a single Bluetooth gateway. The particular Bluetooth gateway to which server 120 provides the provisioning data is a Bluetooth gateway that detected the unprovisioned Bluetooth device. Other Bluetooth gateways will not receive the provisioning data for the unprovisioned Bluetooth device. Accordingly, a provisioning conflict wherein each of multiple Bluetooth gateways performs a provisioning operation with respect to a same unprovisioned Bluetooth device is avoided.” This disclosure shows that Hu does account for conflicting administrative inputs. Although an existing assigned address is not described, the server does determine whether or not multiple gateway devices are attempting a provisioning operation on the same Bluetooth device. In response, the server provides provisioning data to a singular gateway device to avoid provisioning conflicts. The server determining that multiple gateways are attempting to provision the same device has a functionally equivalent outcome to the server determining that a device has already been provisioned, in that the server will avoid such a conflict by taking into account which gateway was the first to send the information of an unprovisioned device and only sending the provisioning data to that gateway device. Seeing as the first gateway to send the information of an unprovisioned device, would become the provisioning device, then the second or further gateways that also attempt to provision the device would inherently determine or have knowledge that the particular device has already been provisioned, and the server would therefore only have provided the provisioning data to the target gateway device (see ¶0111). This effectively prevents allocation of multiple addresses for the same peripheral device.
Argument: The cited art collectively fails to recognize the concurrency problem of simultaneous address allocation attempts by multiple administrators. And that without recognition of this specific problem, there is no teaching, suggestion, or motivation to implement the claimed server-side conflict resolution mechanism. (Remarks Pg. 11-13)
Response: In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the cited prior art Hu discloses in at least ¶0108, a recognition of and solution to a concurrency problem of simultaneous address allocation attempts by multiple administrators.
Argument: If one were to attempt to modify Hu in view of Amrine, which is directed to lighting systems with user interfaces for commissioning and scene management but does not address centralized, server-based address allocation, the result would be a system where address assignment and group management could occur at the user device level. This would undermine Hu’s core purpose which is to ensure address uniqueness and prevent conflicts through centralized control. Allowing address assignment outside the server would introduce the risk of duplicate addresses and inconsistent network state, directly defeating Hu’s intended functionality. (Remarks Pg. 16)
Response: Examiner respectfully disagrees. Hu’s approach takes into consideration that before a gateway device completes the provisioning process, the server receives the unprovisioned device information before determining confliction due to multiple provisioning devices, then returns the provisioning data to only the first gateway device which requested provisioning so that it may complete the provisioning process. Therefore, the process of provisioning (address assignment) in Hu is already outside the server, and does so while avoiding risk of duplicate addresses being assigned. In light of this, the combination of Amrine with Hu would not defeat Hu’s intended purpose.
Argument: Incorporating Zhou’s reporting mechanisms into Hu would require decentralizing the address assignment process, so that addresses could be assigned by provisioners other than the server, which would defeat Hu’s intended purpose of server-centric, authoritative address allocation. (Remarks Pg. 17)
Response: Examiner respectfully disagrees. Much like the response above, Hu’s process of provisioning (address assignment) is already outside the server and therefore decentralized by allowing provisioners other than the server to assign (provision) the address to the Bluetooth device, and the process does so while avoiding risk of duplicate addresses being assigned. In light of this, the combination of Zhou with Hu would not defeat Hu’s intended purpose.
Argument: Adopting Jung’s gateway-based information exchange in Hu would not address the problem of unique address allocation in a mesh network. It would instead introduce additional complexity and potential points of failure, while not contributing to Hu’s goal of centralized, conflict-free address management. A skilled person would not be motivated to modify Hu in view of Jung as it would fail to improve Hu’s intended functionality and could also introduce new problems and inefficiencies. (Remarks Pg. 17-18)
Response: The test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
Argument: If Hu were modified to use Apsangi’s approach, address allocation could occur outside the server, undermining the guarantee of address uniqueness and the integrity of the mesh network, which would make Hu’s system unsatisfactory for its intended purpose of centralized, server-controlled provisioning. A skilled person would not be motivated to modify Hu in view of Apsangi, as this would destroy the core functionality of Hu’s centralized address management. (Remarks Pg. 18)
Response: Examiner respectfully disagrees. Much like the responses above, Hu’s process of provisioning (address assignment) is already outside the server and allows provisioners other than the server to assign (provision) the address to the Bluetooth device using information determined by and provided by the server. It also does so while avoiding risk of duplicate addresses being assigned based on the server only providing provisioning information to a single requesting gateway. In light of this, the combination of Apsangi with Hu would not defeat Hu’s intended purpose.
Argument: Incorporating Pandey’s sequential assignment or recovery mechanisms into Hu would not enhance Hu’s centralized address allocation. Instead, it could introduce distributed elements that would compromise the server’s authoritative role making the system unsatisfactory for Hu’s intended purpose. A skilled person would not be motivated to modify Hu in view of Pandey, as this would undermine the centralized, conflict-free address allocation that is fundamental to Hu. (Remarks Pg. 18-19)
Response: Examiner respectfully disagrees. Following from the above responses, Hu’s process of provisioning (address assignment) is not done solely by the server but rather allows provisioners other than the server to assign (provision) the address to the Bluetooth device using information determined by and provided by the server. It also does so while avoiding risk of duplicate addresses being assigned based on the server only providing provisioning information to a single requesting gateway. In light of this, the combination of Pandey with Hu would not defeat Hu’s intended purpose.
Argument: The prior art either assumes a single, centralized server allocation or does not address the scenario of concurrent, potentially conflicting address assignments by multiple administrators. None of the references recognize the practical risk that, in a real-world smart home environment with multiple users or administrators, simultaneous attempts could result in duplicate addresses, leading to network instability and device control failures. As described in the specification, after the address is assigned, “the terminal device performs step S6 of sending to the server the information of the intelligent light to which an address is to be allocated as well as the information of the Bluetooth address of the intelligent light. The server records the unicast address of the intelligent light after received the above-mentioned information. This is done so as to avoid the problem that a Bluetooth address is repeatedly allocated to the same intelligent light, and solve the problem of Bluetooth address conflict of the intelligent light.” Implementing this feedback and audit step adds complexity and cost to the system, as it requires additional communication, server-side processing, and data management beyond what is found in the prior art. A person having ordinary skill in the art would not have been motivated to incur this additional cost and system complexity, because the problem of address conflicts due to simultaneous administrator actions was not previously recognized or addressed. The prior art systems, such as Hu, operate under the assumption that the server is always the sole allocator and thus inherently avoids this issue while other references do not contemplate multi-administrator environments or the need for post-allocation synchronization. (Remarks Pg. 23-26)
Response: Examiner respectfully disagrees. The cited prior art Hu in at least ¶0108 & ¶0111 proposes a scenario of concurrent, potentially conflicting address assignments by multiple administrators. In order to avoid this issue, the server first receives the information of the unprovisioned device from one or more gateway devices, then determines which of multiple gateway devices attempting to provision the same device was the first to do so. The server then provides provisioning data to a single gateway device that will be responsible for the actual provisioning. This avoids allocation conflicts as well as shows that though the server acts as the main allocator of the provisioning data (addressing), the gateway devices use that information to do the actual provisioning, not the server.
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.
Claims 1 and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Hu (US 2020/0169861 A1), hereinafter referred to as Hu, in view of Amrine et al. (US 2017/0290132 A1), hereinafter referred to as Amrine, and further in view of Zhou et al. (US 2022/0183084 A1), hereinafter referred to as Zhou.
Re. Claim 1, Hu teaches:
A Bluetooth address allocation method for a peripheral Bluetooth device, (Fig. 1 [i.e. depicts 130a as a Bluetooth lamp] & ¶0023 Bluetooth mesh network 100 includes one or more Bluetooth devices 130 (e.g., 130 a , 130 b , 130 c , etc.) & ¶0087 Various embodiments include provisioning within a Bluetooth mesh network [i.e. provisioning is the process of allocating unicast addresses to Bluetooth devices so they can operate on the mesh network].)
comprising: accessing a preset local area network, (¶0023 Bluetooth mesh network 100 [i.e. a preset local area network] includes one or more Bluetooth devices 130 (e.g., 130 a , 130 b , 130 c , etc.) [i.e. Fig. 1 shows some of the devices accessing the LAN, including a Bluetooth lamp 130a].)
and setting administrators of the local area network (¶0036 According to various embodiments, Bluetooth mesh network 200 includes a provisioner [i.e. network includes a previously set up administrator].),
wherein the number of administrators is two or more; (Fig. 1 [i.e. shows multiple gateway devices operating on the LAN] & ¶0023 Bluetooth mesh network 100 includes a plurality of Bluetooth gateways 110 (e.g., 110a, 110b, and 110c) and a server 120. In some embodiments, Bluetooth mesh network 100 includes one or more Bluetooth devices 130 (e.g., 130a, 130b, 130c, etc.). According to various embodiments, Bluetooth mesh network 100 includes a provisioner. The provisioner can be implemented by at least one of the plurality of Bluetooth gateways 110, one of the one or more Bluetooth devices 130, and/or server 120. & ¶0087 Various embodiments include provisioning within a Bluetooth mesh network. In some embodiments, a Bluetooth gateway (e.g., Bluetooth gateway 110 a of FIG. 1) is the provisioner [i.e. an administrator]. In some embodiments, one or more Bluetooth gateways operate as a provisioner. [i.e multiple administrators operable within network; one or two or more])
acquiring (¶0100 if an unprovisioned Bluetooth device is preparing to join the Bluetooth mesh network, the Bluetooth gateways near the unprovisioned Bluetooth device are notified of the unprovisioned Bluetooth device and/or the intent to join the Bluetooth mesh network. As an example, the Bluetooth gateways near the unprovisioned Bluetooth device are notified via broadcasting (e.g., a broadcast signal communicated by the corresponding unprovisioned Bluetooth device. Thus, when the Bluetooth gateways [i.e. administrator/provisioner] receive the beacon signal or broadcast data packets, they may confirm detection of Bluetooth devices that sent the beacon signal or broadcast data packets [i.e. a piece of information of peripheral Bluetooth device], determine that these Bluetooth devices are prepared, and start the provisioning process for them. & ¶0104 In some embodiments, a Bluetooth gateway is configured with a touchscreen. The user can input the detection to the touchscreen (e.g., via selection of a button on a graphical user interface displayed on the touchscreen).)
and acquiring a piece of information of the peripheral Bluetooth device to which the Bluetooth address is to be allocated; (¶0099 information pertaining to unprovisioned Bluetooth devices detected provided by one or more of the plurality of Bluetooth gateways [i.e. information of the detected bluetooth light/device] 110 includes identifying information corresponding to the Bluetooth devices (e.g., universally unique identifiers (UUID), etc.). [i.e. a piece of information of the intelligent device/light] In some embodiments, information pertaining to unprovisioned Bluetooth devices includes signal strength information with respect to the corresponding Bluetooth devices (e.g., received signal strength indicators (RSSI), etc.). The UUID can include product ID, MAC address, and other information [i.e. more pieces of information of the intelligent device/light; some of this information will be displayed on the terminal] The product ID can identify the Bluetooth device type, capabilities, and other such information.)
sending a request message for allocating a Bluetooth address in the local area network to a server, (¶0089 According to various embodiments, “provisioning data” refers to data that an unprovisioned Bluetooth device uses (e.g., requires) to successfully connect to a Bluetooth mesh network 100 . Examples of provisioning data include NetKey, AppKey, and a unicast address. …A “unicast address” is the address used in connection with communicating with other nodes after an unprovisioned Bluetooth device successfully connects to the Bluetooth mesh network 100. & ¶0098 In some embodiments, server 120 allocates provisioning data in response to receiving a request for provisioning data [i.e. provisioning data includes unicast address, therefore the device is requesting the allocation of a unicast address/Bluetooth address] with respect to an unprovisioned Bluetooth device detected by a Bluetooth gateway on the Bluetooth mesh network [i.e. within the LAN]. For example, the Bluetooth gateway requests provisioning data from server 120 in response to detecting the corresponding unprovisioned Bluetooth device.)
and acquiring a piece of information of the Bluetooth address to be allocated, (¶0098 server 120 allocates provisioning data for each of the corresponding detected, unprovisioned Bluetooth devices, and provides provisioning data to the corresponding Bluetooth gateways [i.e. acquiring the provisioning data which includes the Bluetooth address to be allocated to the device] that detected the unprovisioned Bluetooth devices.)
assigning the Bluetooth address to be allocated to the peripheral Bluetooth device to which an address is to be allocated, (¶0089 According to various embodiments, “provisioning data” refers to data that an unprovisioned Bluetooth device uses (e.g., requires) to successfully connect to a Bluetooth mesh network 100. Examples of provisioning data include NetKey, AppKey, and a unicast address. … A “unicast address” is the address used in connection with communicating with other nodes after an unprovisioned Bluetooth device successfully connects to the Bluetooth mesh network 100 [i.e. Bluetooth device is assigned a unicast address as part of completing the provisioning process, which is by design a unique address for each device]. & ¶0097 server 120 can actively allocate provisioning data for one or more of the unprovisioned Bluetooth devices on the list of unprovisioned Bluetooth devices [i.e. allocating the unicast address from the provisioning data to the Bluetooth device].)
and sending the piece of information of the peripheral Bluetooth device to which an address is to be allocated (¶0097 The plurality of Bluetooth gateways 110 can detect unprovisioned Bluetooth devices within their respective signal coverage areas and report information pertaining to the unprovisioned Bluetooth devices (e.g., identifier, type, etc.) to the server 120. & ¶0098 One or more of the plurality of Bluetooth gateways 110 in a Bluetooth mesh network 100 can detect unprovisioned Bluetooth devices within their respective signal coverage areas and provide information pertaining to the detected unprovisioned Bluetooth devices to server 120 & ¶0099 information pertaining to unprovisioned Bluetooth devices detected provided by one or more of the plurality of Bluetooth gateways 110 includes identifying information corresponding to the Bluetooth devices (e.g., universally unique identifiers (UUID), etc.) …The UUID can include product ID, MAC address, and other information [i.e. information of the unallocated device].)
wherein, when a plurality of administrators simultaneously attempts to allocate a Bluetooth address to the same peripheral Bluetooth device, the server determines whether the peripheral Bluetooth device has already been assigned a Bluetooth address, (¶0107 If signal coverage areas of multiple Bluetooth gateways within Bluetooth mesh network 100 overlap, the unprovisioned Bluetooth devices within the overlapped zones can be detected by two or more Bluetooth gateways. Thus, information about a single unprovisioned Bluetooth device will be provided to server 120 by two or more Bluetooth gateways. The server 120 accordingly can receive information at different times about the same unprovisioned Bluetooth device from two or more Bluetooth gateways. [i.e. scenario where a plurality of administrators simultaneously can attempt to provision the same Bluetooth device] & ¶0108 server 120 determines one or more Bluetooth gateways that detect the unprovisioned Bluetooth device and then determines a particular Bluetooth gateway (e.g., a target gateway) from among the one or more Bluetooth gateways that detect the unprovisioned Bluetooth device. if server 120 receives an indication of a detected unprovisioned Bluetooth device from a plurality of Bluetooth gateways, [i.e. server determines a plurality of administrators simultaneously attempting to provision a Bluetooth device] the server provides the provisioning data for the unprovisioned Bluetooth device to a single Bluetooth gateway. & ¶0111 with respect to each detected unprovisioned Bluetooth device, server 120 can use a timer (e.g., that is initiated) upon receiving information pertaining to that unprovisioned Bluetooth device as reported from a first Bluetooth gateway. The timer is used in connection with timing a set length of time. Server 120 can wait to receive information pertaining to that unprovisioned Bluetooth device from another Bluetooth gateway during the timing period of the timer. If information pertaining to the unprovisioned Bluetooth device is provided by other Bluetooth gateways during the timing period of the timer (e.g., within a preset period of time), the first Bluetooth gateway and the other Bluetooth gateways will all be deemed as the one or more Bluetooth gateways that detected the unprovisioned Bluetooth device. [i.e. the server detects whether any other gateway (administrator) is trying to provision the same Bluetooth device, which would effectively cause an address allocation conflict due to the provisioning information for one device being used to allocate the same device multiple times])
and if so, provides the assigned Bluetooth address to the requesting administrator, thereby preventing allocation of multiple addresses to the same peripheral Bluetooth device. (¶0108 Server 120 provides the provisioning data of the unprovisioned Bluetooth device to the particular Bluetooth gateway, and thus the particular Bluetooth gateway performs a provisioning operation on the unprovisioned Bluetooth device. Other Bluetooth gateways will not receive the provisioning data for the unprovisioned Bluetooth device. [i.e. server provides the assigned Bluetooth address to the requesting administrator] Accordingly, a provisioning conflict wherein each of multiple Bluetooth gateways performs a provisioning operation with respect to a same unprovisioned Bluetooth device is avoided. [i.e. the server determines a single gateway to provide the provisioning data to so as to not perform multiple address allocations to the same Bluetooth device])
Yet, Hu fails to teach: displaying, by any one of the administrators, a piece of information of a peripheral Bluetooth device via a terminal device and wherein the Bluetooth address to be allocated is a new Bluetooth address in the local area network;
However, in the analogous art, Amrine teaches such limitations:
displaying, by any one of the administrators, a piece of information of a peripheral Bluetooth device via a terminal device (¶0041 the user device 112 may execute an application 114 (e.g., an app) that enables the operation and/or configuration of the light sources 102 in the system 100. & ¶0042 the application 114 is configured to enable a user to commission the node(s) of the connected lighting system 100, & ¶0056 Signals may be received (302) from the various nodes in an area. In some implementations, the signals may be received through a wireless transceiver of the user device 112. The signals may be the various nodes advertising their presence, and each signal may include a unique identifier (e.g., UUID) of the node that sent the signal. At this stage, the nodes may not yet be on the mesh network. & ¶0057 The UI of the application 114 may present (304) a collection (e.g., list, stack, or other graphical representation) of the various nodes from which signals have been received. In some implementations, the list or other graphical representation may be selectable, such that a user may select various nodes that are presented in the UI.)
wherein the Bluetooth address to be allocated is a new Bluetooth address in the local area network; (¶0052 In some implementations, each light source 102, sensor 110, controller 104, user device 112, and/or other nodes may each have a unique address (e.g., BlueTooth address) on the mesh network. & ¶0060 The selected node may be added (312) to the mesh network, which may include allocating a network address for the node. The network address may uniquely identify the node on the network [i.e. describes allocating a unique/new address for each node/device added to the Bluetooth mesh network].)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Amrine’s teaching of the Bluetooth address to be allocated being a new Bluetooth address in the LAN, because it would allow for each device that is to be connected to the LAN to be defined and identified uniquely within the LAN. (see Amrine ¶0052 & ¶0060)
Yet, the combined references fail to teach: and sending the information of the peripheral Bluetooth device to which an address is to be allocated and the Bluetooth address of the peripheral Bluetooth device to the server.
However, in the analogous art, Zhou teaches such a limitation:
and sending the information of the peripheral Bluetooth device to which an address is to be allocated and the Bluetooth address of the peripheral Bluetooth device to the server. (¶0071 In step 200 , the top provisioner selects an appropriate non-provisioned device, and optionally selects the device as the primary provisioner after the completion of provisioning. In this step, the top provisioner starts to provision its surrounding (i.e., within respective communication distance range) non-provisioned devices & ¶0130 provisioning information (e.g., unicast address and other information of each element of this device). Each temporary provisioner [i.e. a Bluetooth gateway device] may send the provisioning information of all the devices provisioned by itself to the top provisioner [i.e. describes sending the assigned Bluetooth addresses of successfully added nodes to a server device] or the primary provisioner in a unified manner. & ¶0158 the primary provisioner B may summarize the node provisioning information received from each temporary provisioner in step 700 , and send the information to the top provisioner. [i.e. further describes how the top provisioner acts as a Bluetooth network server] Then, the primary provisioner B restores the function as a normal Bluetooth Mesh network node, and deletes all temporary configuration information stored locally.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu and Amrine’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Zhou’s teaching of sending the Bluetooth address assigned to the device to the server, because it would allow the server to contain addressing information of each node in the network, rather than each network node, so as to reduce needed storage space and computing requirements of the Bluetooth provisioning devices. (see Zhou ¶0161-¶0162)
Re. Claim 9, Hu combined with Amrine and Zhou teaches claim 1.
Hu further teaches:
A computer device, comprising a processor and a memory, (¶0145 In a typical configuration, a computer comprises one or more processors (CPUs), input/output ports, network interfaces, and memory.)
wherein the memory stores a computer program which implements, when being executed by the processor, the steps of the Bluetooth address allocation method for the peripheral Bluetooth device according to claim 1. (¶0146 Memory may include the following forms in computer-readable media: volatile memory, random access memory (RAM), and/or non-volatile memory, e.g., read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium. & ¶0148 Accordingly, various embodiments further provide a computer-readable medium storing computer programs. When executed, the computer programs are capable of implementing all the steps)
Re. Claim 10, Hu combined with Amrine and Zhou teaches claim 1.
Hu further teaches:
A non-transitory computer-readable storage medium storing a computer program therein, (¶0013 The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium;)
Wherein the computer program implements, when executed by the processor, the steps of the Bluetooth address allocation method for the peripheral Bluetooth device according to claim 1 (¶0148 Accordingly, various embodiments further provide a computer-readable medium storing computer programs. When executed, the computer programs are capable of implementing all the steps executable by a server in the method embodiments described above.)
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Hu combined with Amrine and Zhou, further in view of Apsangi et al. (US 2008/0177998 A1), hereinafter referred to as Apsangi, and further in view of Pandey et al. (US 2021/0044971 A1), hereinafter referred to as Pandey.
Re. Claim 2, Hu combined with Amrine and Zhou teaches claim 1.
Yet the combined references fail to teach: wherein the acquired Bluetooth address to be allocated is unoccupied.
However, in the analogous art, Apsangi teaches such a limitation:
wherein the acquired Bluetooth address to be allocated is unoccupied (¶0118 As used herein, the term "wireless" means any wireless signal, data, communication, or other interface including without limitation WiFi, Bluetooth, [i.e. can include Bluetooth devices] & ¶0191 using an auto-configuration (e.g., "zero-config") process of the type well known in the art, the device may search the network to determine used and unused addresses. The device then grabs an available MAC or other network address [i.e. address of device to be allocated is unoccupied, MAC address or other network address can be considered a Bluetooth address to be allocated to a device] according to prescribed protocol (e.g., take address if available starting from XXXXYYYY, etc.). This address in one case is temporary and will be used by the device 210 for the remainder of the provisioning process only; a new permanent address is assigned by the head-end 150 during the provisioning process (or once completed). Alternatively, the "grabbed" address may be used permanently by the device 210 if desired.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu, Amrine and Zhou’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Apsangi’s teaching of the Bluetooth address to be allocated being unoccupied, because it would enable the device to permanently allocate the address to the Bluetooth device during the provisioning process by first searching for unused addresses. (see Apsangi ¶0191)
Yet, the combined references fail to teach: and has an address code greater than an address code of a Bluetooth device to which the address is already allocated in the local area network
However, in the analogous art, Pandey teaches such a limitation:
and has an address code greater than an address code of a Bluetooth device to which the address is already allocated in the local area network. (¶0028 To communicate with a node in a Bluetooth mesh network, multiple security credentials are required… The last credential required by the Bluetooth mesh network is the unicast address of the node. & ¶0030 During the provisioning stage 104, the installed provisioning application scans for un-provisioned Bluetooth devices in its vicinity. In conventional systems, the provisioning application generates the network key and the device key randomly at the provisioning stage and application key during configuration 104. Also, the provisioning application assigns the unicast address sequentially [i.e. describes a process of allocating addresses to devices connecting to a Bluetooth mesh network in a sequential manner, meaning that every address allocated is going to be greater than the address allocated to the last or previous device that was connected] and allocates the device key for each un-provisioned device. & ¶0004 A Bluetooth mesh network is protected by multiple security credentials. These security credentials [i.e. which includes address] are generated by and stored on a provisioning device (usually a smart phone). & ¶0076 The provisioning device as described above may be implemented using the example processing system 1000, or variations of the processing system 1000. The processing system 1000 could be a smart phone, a server, a desktop terminal, for example, or any suitable processing system.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu, Amrine, Zhou and Apsangi’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Pandey’s teaching of the Bluetooth address to be allocated being greater than an address code of a Bluetooth device as in a sequential address allocation method, because it enables the device to allocate an address based on what addresses are used by devices currently connected to the mesh network, which further enables the device to communicate with other nodes in the mesh network using the necessary security credentials. (see Pandey ¶0028)
Re. Claim 3, Hu combined with Amrine, Zhou, Apsangi, and Pandey teaches claim 2.
Hu further teaches:
wherein after receiving the request message for allocating a Bluetooth address in the local area network, (¶0098 server 120 allocates provisioning data in response to receiving a request for provisioning data [i.e. a request to allocate an address for an unprovisioned Bluetooth device])
Aspangi further teaches:
the server acquires a maximum code of a Bluetooth address already used in the local area network, (¶0190 For example, a DHCP server or other entity (which may be discovered via, e.g., a DCHP broadcast "discover" message or other such mechanism) can be used to allocate an IP address to the subscriber device [i.e. the server would acquire and allocate addresses using the method described below] & ¶0191 using an auto-configuration (e.g., "zero-config") process of the type well known in the art, the device may search the network to determine used and unused addresses. The device then grabs an available MAC or other network address according to prescribed protocol (e.g., take address if available starting from XXXXYYYY, etc.) [i.e. method of acquiring/seraching and allocating addresses that a server would use; start allocating after determining a maximum address code of already connected Bluetooth devices, this is considering the previous step of searching for used and unused addresses; In this case, the server or the device can allocate an address using the method described].)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu, Amrine, Zhou, and Pandey’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Aspangi’s teaching of the server acquiring a maximum address of a Bluetooth device already connected to the LAN, because it would enable the system to allocate to unprovisioned devices an address that is not currently in use, which reduces potential collision of network transmissions. (see Aspangi ¶0191)
Pandey further teaches:
and acquires a next address code, which is greater than the maximum code of the Bluetooth address already used, as the Bluetooth address to be allocated. (¶0028 To communicate with a node in a Bluetooth mesh network, multiple security credentials are required… The last credential required by the Bluetooth mesh network is the unicast address of the node. & ¶0030 During the provisioning stage 104, the installed provisioning application scans for un-provisioned Bluetooth devices in its vicinity. In conventional systems, the provisioning application generates the network key and the device key randomly at the provisioning stage and application key during configuration 104. Also, the provisioning application assigns the unicast address sequentially [i.e. describes a process of allocating addresses to devices connecting to a Bluetooth mesh network in a sequential manner, meaning that every address allocated is going to be greater than the address allocated to the last or previous device that was connected] and allocates the device key for each un-provisioned device.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu, Amrine, Zhou, and Apsangi’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Pandey’s teaching of acquiring the next address to be allocated to the unprovisioned Bluetooth device being greater than a maximum address that is already used by another Bluetooth device, because it enables the device to allocate an address based on what addresses are used by devices currently connected to the mesh network, which further enables the device to communicate with other nodes in the mesh network using the necessary security credentials. (see Pandey ¶0028)
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Hu combined with Amrine and Zhou, Apsangi, Pandey, and further in view of Mesh Profile (Bluetooth specification, Revision v1.0.1, Revision Date: 2019-01-21), hereinafter referred to as “Mesh Profile”.
Re. Claim 4, Hu combined with Amrine, Zhou, Apsangi, and Pandey teaches claim 3.
Pandey further teaches:
whereinan unused Bluetooth address is searched incrementally from a preset minimum code to serve as the Bluetooth address to be allocated. (¶0062 The unicast addresses of the nodes in the Bluetooth mesh network are assigned by the provisioning device in a sequential manner. [i.e. addressing would inherently need to start from a preset minimum address code such as 0x0001])
Although Pandey discloses provisioning addresses of Bluetooth nodes in a sequential (incremental) manner, the reference does not explicitly disclose doing so if the maximum code of the Bluetooth address already used in the local area network is a preset maximum code. Mesh Profile discloses such a limitation in Unicast Address section 3.4.2.2 “The unicast address shall not have the value 0x0000, and therefore can have any value from 0x0001 to 0x7FFF inclusive. [i.e. a theoretical maximum address code of 0x7FFF can be reached] A unicast address is allocated to each element of a node for the lifetime of the node on the network by a Provisioner during provisioning as described in Section 5.4.2.5. The address may be unallocated by a Provisioner to allow the address to be reused using the procedure defined in Section 3.10.7 [i.e. being able to reuse unallocated addresses, inherently connected to sequentially reaching a maximum address space and needing another address to allocate to an unprovisioned device].”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu, Amrine, Zhou, Apsangi, and Pandey’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Mesh Profile’s teaching of a preset maximum code for Bluetooth device addressing, because it defines a theoretical maximum address code for provisioning devices before the need to reuse previously unallocated addresses that are made available when nodes are removed from the network, this being beneficial for efficient address space utilization. (see Mesh Profile section 3.4.2.2)
Claims 5-8 are rejected under 35 U.S.C. 103 as being unpatentable over Hu combined with Amrine and Zhou, and further in view of Jung et al. (US 2018/0220476 A1), hereinafter referred to as Jung.
Re. Claim 5, Hu combined with Amrine and Zhou teaches claim 1.
Hu further teaches:
further comprises: searching for a gateway device, (¶0100 As an example, the Bluetooth gateways near the unprovisioned Bluetooth device are notified via broadcasting (e.g., a broadcast signal communicated by the corresponding unprovisioned Bluetooth device. [i.e. broadcasting signal to search for gateway devices to connect to])
and when a Bluetooth connection between the terminal device and a peripheral Bluetooth device is disenabled, sending a control instruction to the server, (¶0041 Referring to FIG. 2, in response to server 220 receiving an on/off voice request (e.g., a control request) from the living room Bluetooth gateway 210a [i.e. Bluetooth connection being disenabled by voice command causes control request/instruction to be sent] & ¶0042 the control request sent by one or more of the plurality of Bluetooth gateways 110 to server 120 includes an identifier (ID) of the to-be-controlled Bluetooth device.)
the server sending the control instruction to the gateway device, (¶0041 server 220 communicates the on/off voice request [i.e. the control request/instruction] to the Bluetooth gateway 210a deployed in the living room and to the Bluetooth gateway 210b deployed on the third floor so that one of these Bluetooth gateways 210 [i.e. server sends control instruction to both gateway devices on the network] (e.g., the Bluetooth gateway having a signal range that is capable of covering the third-floor Bluetooth lamp 230c) can control the on/off status of the third-floor Bluetooth lamp (e.g., the Bluetooth gateway that is able to communicate the control request or instructions corresponding thereto the third-floor Bluetooth lamp 230c).)
and the gateway device sending the control instruction to the peripheral Bluetooth device via a Bluetooth signal. (¶0041 server 220 communicates the on/off voice request to the Bluetooth gateway 210a deployed in the living room and to the Bluetooth gateway 210b deployed on the third floor so that one of these Bluetooth gateways 210 (e.g., the Bluetooth gateway having a signal range that is capable of covering the third-floor Bluetooth lamp 230c) can control the on/off status of the third-floor Bluetooth lamp (e.g., the Bluetooth gateway that is able to communicate the control request or instructions corresponding thereto the third-floor Bluetooth lamp 230c) [i.e. gateway device sends control request/instruction to intelligent device/light, which would be done via Bluetooth signal since they are both Bluetooth devices connected over a Bluetooth mesh network].)
Yet, the combined references fail to teach: and sending a piece of wireless account information to the gateway device;
However, in the analogous art, Jung teaches such a limitation:
and sending a piece of wireless account information to the gateway device; (¶0115 the IoT gateway receives access information for any one router (referred to as a target router below) selected by the user from among routers included in the list of accessible routers from the smart device (S390). Here, the target router may be the router 110 shown in FIG. 1 or may differ from the router 110 shown in FIG. 1. For convenience of description, it is assumed below that the target router is the router 110 shown in FIG. 1, and the target router will be indicated by the reference number “110.” & ¶0116 Here, the access information for the target router may include at least one piece of information among an SSID of the target router, an authentication type of the target router, and a password of the target router [i.e. wireless account information sent to gateway device].)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu, Amrine, and Zhou’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Jung’s teaching of sending wireless account information to the gateway device, because it would enable the device to connect to the router through the gateway devices display and input, saving on manufacturing costs for the Bluetooth device by not needing additional inputs or displays. (see Jung ¶0117-¶0119)
Re. Claim 6, Hu combined with Amrine, Zhou, and Jung teaches claim 5.
Hu further teaches:
The Bluetooth address allocation method for the peripheral Bluetooth device according to claim 5, wherein if the terminal device resumes the Bluetooth connection with the peripheral Bluetooth device, the terminal device sends the control instruction to the peripheral Bluetooth device via the Bluetooth signal. (¶0041 server 220 communicates the on/off voice request to the Bluetooth gateway 210a deployed in the living room and to the Bluetooth gateway 210b deployed on the third floor so that one of these Bluetooth gateways 210 [i.e. one of the Bluetooth gateways is turning on or resuming a Bluetooth connection with the intelligent device/light] (e.g., the Bluetooth gateway having a signal range that is capable of covering the third-floor Bluetooth lamp 230c) can control the on/off status of the third-floor Bluetooth lamp (e.g., the Bluetooth gateway that is able to communicate the control request or instructions corresponding thereto the third-floor Bluetooth lamp 230c) [i.e. gateway device sends control request/instruction to intelligent device/light, which would be done via Bluetooth signal since they are both Bluetooth devices connected over a Bluetooth mesh network]. & ¶0097 If server 120 provides authorization to a user or a Bluetooth terminal (e.g., a Bluetooth gateway or Bluetooth device) [i.e. Bluetooth gateway can be considered as a terminal],)
Re. Claim 7, Hu combined with Amrine, Zhou, and Jung teaches claim 5.
Amrine further teaches:
further comprises: the terminal device sending a piece of information of a preset cloud scene to the server, (¶0044 The user may also use the application 114 to specify one or more scenes, where each scene specifies a state of one or more light sources 102 and/or groups of light source(s) 102 when the scene is active [i.e. preset cloud scene]. A scene may specify a state of light source(s) 102 and/or group(s) of light source(s) 102 that includes one or more characteristics that the light source(s) 102 are to assume, such as a brightness level (e.g., power level), color, color temperature, and/or other characteristic(s) of the light source(s). In some instances, a light source 102 may include multiple LEDs or other sub-components which may be independently illuminated or not illuminated by a light source. In such instances, the state may specify a characteristic of a number of LEDs that are to be illuminated by the light source while the scene is active. & ¶0046 The system 100 may also include one or more server devices 120. The server device(s) 120 may include any suitable number and type of computing device, including distributed computing device(s) (e.g., cloud server(s)). The server device(s) 120 may communicated with the user device 112 over one or more network(s), e.g., over the internet. In some implementations, the group information 116 and/or the scene information 118 may be stored in persistent storage on the server device(s) 120 in addition to or instead of being persistently stored on the user device 112. The group information 116 and/or scene information 118 may be periodically synced between the user device 112 and/or server device(s) 120 [i.e. terminal sending scene information of a preset cloud scene to a server].)
and the server acquiring a parameter of the preset cloud scene (¶0045 Scene information 118 may include an identifier of the scene (e.g., “Scene 1”) as well as the state that the light source(s) are to assume when the scene is active [i.e. parameter(s) of the preset cloud scene]. As described above, a state may include characteristic(s) such as a brightness level (e.g., power level), color, color temperature, number of LEDs to be illuminated, and so forth. & ¶0046 The group information 116 and/or scene information 118 may be periodically synced between the user device 112 and/or server device(s) 120 [i.e. terminal sending scene information of a preset cloud scene to a server])
and sending the parameter as a control instruction to the peripheral Bluetooth device via the gateway device. (¶0014 sending a wireless scene activation signal over the wireless network; the wireless scene activation signal specifies the scene to be activated; receipt of the wireless scene activation signal causes the first light source to be in the state associated with the scene; & ¶0050 a wireless scene activation message may be sent over the wireless mesh network, and received by all the light sources in the network. The wireless scene activation message may indicate that a particular scene is to be activated. On receiving the message, each light source may determine based on its stared scene information how it is to respond to the wireless scene activation message, and the light source may assume the appropriate state (e.g., brightness, color, color temperature, etc.) according to its stored scene information. & ¶0051 at least a portion of group information 116 and/or scene information 118 may be stored on the light source(s) 102. A wireless scene activation message may be sent, from the user device 112 and/or controller 104 [i.e. control instruction via a user device or controller, which can be considered as a gateway device], to activate a particular scene in an area. The message may be received by each of the nodes (e.g., light source(s) 102) in the mesh network [i.e. control instruction received by intelligent device/light],)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu, Zhou, and Jung’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Amrine’s teaching of sending a piece of information of a preset cloud scene to the server, because it would enable the device to store said information on the server instead of the user device, which would in turn make the system more robust by diversifying the location of device information. (see Amrine ¶0046)
Re. Claim 8, Hu combined with Amrine, Zhou, and Jung teaches claim 7.
Amrine further teaches:
wherein the information of the preset cloud scene sent by the terminal device to the server comprises: a piece of scene codes information of the preset cloud scene sent by the terminal device to the server. (¶0045 Scene information 118 may include an identifier of the scene (e.g., “Scene 1”) as well as the state that the light source(s) are to assume when the scene is active [i.e. parameter(s) of the preset cloud scene]. As described above, a state may include characteristic(s) such as a brightness level (e.g., power level), color, color temperature, number of LEDs to be illuminated, and so forth. & ¶0046 The group information 116 and/or scene information 118 may be periodically synced between the user device 112 and/or server device(s) 120 [i.e. terminal sending scene information of a preset cloud scene to a server])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hu, Zhou, and Jung’s invention of a method, device, and system for controlling a Bluetooth device over a Bluetooth mesh network to include Amrine’s teaching of sending a piece of scene code information of a preset cloud scene to the server, because it would enable the device to store said information on the server instead of the user device, which would in turn make the system more robust by diversifying the location of device information. (see Amrine ¶0046)
Conclusion
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 GARY A MILLER whose telephone number is (571)272-4423. The examiner can normally be reached Mon-Fri 8 to 5.
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, Rebecca Song can be reached at 571-270-3667. 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.
/G.A.M./Examiner, Art Unit 2417
/REBECCA E SONG/Supervisory Patent Examiner, Art Unit 2417