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
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/01/2026 has been entered. In virtue of this communication, claims 24-43 are currently pending in the instant application.
Response to Arguments
Applicant’s arguments regarding the newly added limitations have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 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 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.
Claims 24-28, 30-31, 33-37, 39-40 and 42--43 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon (US 2017/0295455 A1) in view of Kharvar et al. (US 2020/0305062 A1).
Regarding Claim 34 Kwon teaches the limitations "A system comprising:
a gateway node; a relay node; and a first node implementing a Bluetooth protocol and configured to: (see abstract and fig. 1, 8 and par. 0002, 0058 showing gateway 120 and relay nodes using Bluetooth and “method and apparatus for configuring nodes performing a relay function for data transmission and reception”);
identify whether an existing relay node is in a set of neighboring Bluetooth nodes nearby the first node, perform data communication via the existing relay node if the existing relay node is identified; and (see fig. 1, 3, 6 showing use of relay node if they exist for performing Bt communication and par. 0014 “an object of the present invention is to provide a method and apparatus for checking whether neighboring nodes perform a relay function in a Bluetooth LE mesh network”);
if the existing relay node is not in the neighboring Bluetooth nodes, broadcast a relay configuration request message" (see fig. 9 and par. 0203 and 0215-0216 “the first node enables or disables its relay function depending on whether an indication message (i.e., a first indication message) indicative of the enabling of at least one relay function is received from an neighboring node as a response to the message transmitted by the first node during the specific time (i.e., a first specific time) at step S9030 or S9040”).
Kwon further shows the selection of relay nodes by a gateway node (see e.g. par. 0058, 0274, 0277 and 0294 and response to arguments in the final rejection mailed 01/12/2026) but does not explicitly disclose “wherein the relay configuration request message propagates through one or more intermediate nodes in the neighboring Bluetooth nodes toward the gateway node, and wherein each intermediate node through which the relay configuration request message propagates adds address information of the intermediate node to the relay configuration request message to form a propagation path, to request the gateway node to select and configure the relay node from the neighboring Bluetooth nodes based on the propagation path.”
In the same field of endeavor Kharvar teaches a path handover system in Bluetooth mesh routing, where in order “to establish relay or forwarding paths throughout a mesh network, one or more upstream devices (e.g., source device 110-a) may broadcast path request messages. Downstream mesh network devices (e.g., mesh network device 115-a and mesh network device 115-b) may receive one or more path request messages, and may themselves broadcast path request messages to mesh network devices yet further downstream. Such broadcasting of path request messages may continue downstream through the mesh network (e.g., until mesh network devices furthest downstream, or furthest away from the source device 110-a, have received a path request message). Downstream mesh network devices may then select upstream mesh network devices based on, for example, path metrics (e.g., latency of paths corresponding to path request messages received from one or more upstream mesh network devices, length of a path of paths corresponding to path request messages received from one or more upstream mesh network devices, path stability of paths corresponding to path request messages received from one or more upstream mesh network devices, upstream mesh network device metrics, path request message signal strength metrics, etc.). That is, a mesh network device may select an upstream intermediate mesh network device based on path metrics included in the one or more received path request messages (e.g., path metrics may determine the best mesh network device for forwarding path establishment).” Here, the selecting of the mesh nodes to be relay nodes based on path metrics requires the addresses to be added in order to determine path establishment or during handovers.
Also see par. 0050 “During path establishment procedures, path response messages transmitted from downstream mesh network devices (e.g., mesh network device 115-c) to selected upstream mesh network devices (e.g., mesh network device 115-a) may include a handover address of another intermediate mesh network device (e.g., a handover address of a secondary or backup mesh network device such as, for example, mesh network device 115-b). The handover address of the secondary or backup mesh network device may be used by the selected upstream mesh network device for handover procedures. Should the selected upstream mesh network device (e.g., the upstream mesh network device selected by the downstream mesh network device) disassociate from the forwarding path, the selected upstream mesh network device may perform a handover procedure with the backup mesh network device. The backup mesh network device may then serve as the upstream intermediate relay (e.g., from the perspective of the downstream device).” Here in addition, it is shown that the nodes are adding addresses in responses upstream which are then selected by another node (i.e. gateway) during a handover.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add addresses to relay requests and select a relay based on path propagation as taught by Kharvar in the system of Kwon, in order to “determine the best mesh network device for forwarding path establishment” (par. 0040) so that “mesh network forwarding paths or mesh network relay paths may be modified via handover procedures between mesh network devices, without performing new or additional path establishment procedures. (see par. 0050).
Claims 24, 26 and 43 are rejected for the same reasons set forth above because the claims have similar limitations or have been addressed.
Regarding Claim 35 Kwon teaches the limitations "The system of claim 34, further the first node further configured to record the neighboring Bluetooth node as a relay node if a relay notification message sent by one of the neighboring Bluetooth nodes is received" (see abstract and par. 0017 “activating or deactivating the relay function depending on whether a first indication message to request the activation of the relay function is received or not” (i.e. in order to activate the relay node and communicate via the relay node to another node, it must be recorded. Also see par. 0098 where the message is stored).
Claim 25 is rejected for the same reasons set forth above because the claims have similar limitations or have been addressed.
Regarding Claim 36 Kwon teaches the limitations "The system of claim 34, the gateway node further configured to:
receive the relay configuration request message, wherein the relay configuration request message comprises a propagation path having an end node, intermediate nodes, and the gateway node arranged in sequence; (see fig. 1 and 7 and par. 0132 “The mesh transport 46 defines an encryption and authentication function for the end-to-end transmission of a mesh” (i.e. propagation path);
select the relay node from the intermediate nodes of the propagation path according to a preset selection condition; and (see par. 0098 showing preset conditions);
send a relay enable request to the relay node, wherein the relay enable request comprises address information of the end node" (see par. 0132 “The mesh transport 46 defines an encryption and authentication function for the end-to-end transmission of a mesh” and par. 0098 “The destination of the message is the edge node's unicast address, a broadcast address or group address to which the edge node belongs.”).
Claim 27 is rejected for the same reasons set forth above because the claims have similar limitations or have been addressed.
Regarding Claim 37 Kwon teaches the limitations "The system of claim 36, wherein the preset selection condition comprises a condition selected from the group consisting of:
selecting a Bluetooth node provided with a long-term power supply; (see par. 0102 “A relay node is usually a device that draws main power, which is always awake and transmits received data for other nodes.”);
selecting a Bluetooth node that has high signal strength relative to that of a requesting Bluetooth node compared with other Bluetooth nodes;
selecting a Bluetooth node having a longer online duration compared with other Bluetooth nodes; or (see par. 0102 showing always awake relay node selection (i.e. longer online duration));
selecting a Bluetooth node at which the relay configuration request message arrives earlier compared with other Bluetooth nodes" (alternative met).
Claim 28 is rejected for the same reasons set forth above because the claims have similar limitations or have been addressed.
Regarding Claim 39 Kwon teaches the limitations "The system of claim 34, the relay node further configured to:
] receive the relay configuration request message; (par. 0017);
if a relay function is enabled, add address information of a local node to the relay configuration request message, and broadcast the relay configuration request message; and (see par. 0019 “the specific neighboring node is a neighboring node that first transmitted the second message. the first message includes an address of the neighboring node”);
if the relay function is not enabled, add the address information of the local node to only a relay configuration request message that has not been forwarded, and broadcast the relay configuration request message that has not been forwarded" (see par. 0095j “Each node has a message cache for recently received messages. If a received message is already in the message cache, it is not relayed any longer.”).
Claim 30 is rejected for the same reasons set forth above because the claims have similar limitations or have been addressed.
Regarding Claim 40 Kwon teaches the limitations "The system of claim 39, the relay node further configured to:
enable the relay function according to a relay enable request, (see par. 0343-0344, user can select icon for enabling relay) wherein the relay enable request comprises address information of an end node (see fig. 5 packet format) ; and record the end node in a local node list; and sending a relay notification message to the end node" (see par. 0132 “The mesh transport 46 defines an encryption and authentication function for the end-to-end transmission of a mesh.”).
Claim 31 is rejected for the same reasons set forth above because the claims have similar limitations or have been addressed.
Regarding Claim 42 Kwon teaches the limitations "The system of claim 40, the relay node further configured to: if a network connection fails, disable the relay function, and broadcast, by the relay node, a relay configuration request message to a neighboring Bluetooth node" (see par. 0020-0021 “the first node may deactivate the relay function when the first indication message is not received within the first specific time” and “ the method may further include transmitting a first request message for checking whether or not to activate the relay function to the plurality of neighboring nodes when a message is not received from the plurality of neighboring nodes within a second specific time.”).
Claim 33 is rejected for the same reasons set forth above because the claims have similar limitations or have been addressed.
Claims 29, 32, 38 and 41 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon as applied to their respective parent claims above, and further in view of Jose et al. (Us 2014/0018002 A1).
Regarding Claim 38 Kwon teaches the system of claim 36, but does not explicitly disclose “the gateway node further configured to if it is found that the relay node of the end node has changed, send a child node list update message to the relay node."
In the same field of endeavor Jose discloses an apparatus and method for providing a Bluetooth infrastructure. A master of a network for providing the Bluetooth infrastructure connects with at least one device via bidirectional Bluetooth communication. A hub of the network connects between the at least one device and the master via the bidirectional Bluetooth communication. (see abstract). FIG. 8 illustrates a sequence diagram for updating the network, according to embodiments as disclosed herein. The updating network procedure is usually used to update, remove, or add devices from or into the network. Master 200 can either determine on its own or as per network operator's instruction to remove or add a device. The removal of a device from the network is initiated by master 200 by sending (801) a remove request to the hub 203. Hub 203, on receiving a remove request, sends (802) an un-pair message to the sensor 204 which is out of range from the master 200. Then the hub 203, after un-pairing the sensor 204, updates its node list. Then the hub 203 sends (803) the remove response to the master 200 (see par. 0050) Sensors update their status to respective hubs and the hub reports the status of all reporting sensors to all immediate hubs in the network, indicating these sensors are active in the network (par. 0032).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to delete changed end nodes and update child node lists as taught by Jose in the system of Kwon, in order to allow for faster data transfer (see par. 0004 of Jose).
Claim 29, 32 and 41 is rejected for the same reasons set forth above because the claims have similar limitations or have been addressed.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID BILODEAU whose telephone number is (571)270-3192. The examiner can normally be reached Monday-Thursday 6:00am-4:00pm Eastern Standard Time. 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, Wesley Kim can be reached at (571) 272-7867. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/David Bilodeau/
Primary Examiner, Art Unit 2648
Prosecution Insights