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 .
This office action is in response to application filed 09/13/2024.
Claims 1-20 are pending and presented for examination.
Priority
Receipt is acknowledged of certified copies of papers, application FR-2309778 filed 09/15/2023, required by 37 CFR 1.55
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/13/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2 and 3 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites “a command to switch to a transponder type of operating mode”. The term ‘transponder type’ is indefinite as to the metes and bounds of the limitation.
Claim 3 recites “data exchanged with the second device in radar mode”. The term ‘radar mode’ is indefinite as to the metes and bounds of the limitation.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 2, 4-11, and 13-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Barthel et al. (D. BARTHEL (Orange) et al. “LoRaWAN® Relay Specification TS011-1.0.0”, Rev. 1.0.0, Released September 2022. Retrieved by USPTO 08-07-2026: https://resources.lora-alliance.org/technical-specifications/ts011-1-0-0-relay, hereinafter “LoRaWAN® Relay Specification TS011-1.0.0”).
RE Claim 1, 9, 10, LoRaWAN® Relay Specification TS011-1.0.0 discloses a method, device, or computer readable medium with instructions:
A wireless communication device (LoRaWAN end device, Relay device, Gateway, §2 pg. 8) comprising:
a radio transceiver (End device and Relay hardware architecture includes radio, a transceiver, §2 pg. 8);
a memory (End device and Relay hardware architecture includes a micro-controller, §2 pg. 8; A micro-controller is a processor and inherently has memory to operate.); and
at least one processor operably coupled to the radio transceiver and to the memory (End device and Relay hardware architecture includes a radio, transceiver, and a micro-controller, §2 pg. 8; A micro-controller is a processor and inherently has memory to operate.), and configured for the implementation of a method of communication between a first device and a second device (Capabilities and controls are required that comply with LoRaWAN Layer 2 Specification, §2 pg. 8), the first device being a low-power wireless end-device of a LP-WAN type data communication network (Relay, a first device, is based on same hardware architecture as a regular end-device, §2 pg. 8), and the second device being a low-power wireless device that is not a node of the LP-WAN type data communication network (Relay, first device, is useful when the end-device, second device, has insufficient coverage from LoRaWAN gateways to establish and maintain a satisfactory direct connection with the network, §2 pg. 8; Without a direct connection, the second device is not a node of the network), the first device being configured to behave as a relay node with respect to the second device (A relay, a first device, can transfer LoRaWAN frames between an end-device and a LoRaWAN network in both directions, uplink and downlink, §2 pg. 8), the method being implemented by the first device and comprising:
receiving a wake-up message from the second device (Protocol includes a Wake On Radio (WOR) frame sent by the end-device, a second device, to the relay, a first device. §3.1, pg. 9, ln 284-286.), via an application layer of the first device (Relay protocol supports forwarding information from the end-device via the relay to the application server. Uplink will be received by the relay and then forwarded to the Network Server using the relay’s own LoRaWAN link. §3.1, pg. 9, ln. 299-307; Fig. 2, pg. 10), on a frequency channel defined for wireless communications between the first device and the second device (Network server configures parameters of a channel for both relay and end-device for a channel. The new channel may be a different frequency than the default channel to improve communication speed and/or frequency diversity. §3.2.3, pg. 13, ln. 379-387; §8.1, pg. 29, ln. 847-863);
transmitting to the second device, via the application layer of the first device, a receipt acknowledge message of the wake-up message (Relay, first device, sends a Wake On Radio Acknowledge (WOR ACK) to the end device, second device, if the WOR frame from the end-device is valid. §3.3, pg. 14, ln.418-427);
receiving a data packet from the second device (End-device, second device, sends its LoRaWAN uplink, data packets, to relay, first device. §3.4, pg. 14, ln. 433-449), via the application layer of the first device (Relay protocol supports forwarding information from the end-device via the relay to the application server. Uplink will be received by the relay and then forwarded to the Network Server using the relay’s own LoRaWAN link. §3.1, pg. 9, ln. 299-307; Fig. 2, pg. 10); and
transferring, to an application server, via a node of the LP-WAN type data communication network, data from the data packet which are inserted in an uplink data transmission message in a communication protocol of the LP-WAN type data communication network (Relay protocol supports forwarding information from the end-device via the relay to the application server. Uplink will be received by the relay and then forwarded to the Network Server using the relay’s own LoRaWAN link. §3.1, pg. 9, ln. 299-307; Fig. 2, pg. 10).
RE Claim 2, 11, LoRaWAN® Relay Specification TS011-1.0.0 discloses a method or device:
further comprising: transmitting, to the second device, a configuration command message comprising a command to switch to a transponder type of operating mode. (Examiner interpretation of ‘transponder’ operating mode is to transmit and receive communication using relay protocols. Relay, first device, sends a Wake On Radio Acknowledge (WOR ACK) to the end device, second device, if the WOR frame from the end-device is valid. The purpose of the WOR ACK frame is from time synchronization, establish a trusted communication link between end-device, second device, and relay, first device. WOR ACK provides relay forwarding information to the end-device, configuration. §3.3, pg. 14, ln.418-427; Configuration parameters; Network server configures parameters of a channel for both relay and end-device for a channel. The new channel may be a different frequency than the default channel to improve communication speed and/or frequency diversity. §3.2.3, pg. 13, ln. 379-387; §8.1, pg. 29, ln. 847-863)
RE Claim 4, 13, LoRaWAN® Relay Specification TS011-1.0.0 discloses a method or device:
further comprising: listening in order to detect radio signals transmitted on one or more wake-up frequency channels during listening periods (Relay, first device, periodically performs a Channel Activity Detection (CAD) to detect radio activity. This scan is done on the channel(s) supported by the relay including at least one default channel. §3.2.1, pg. 11, ln. 334-338), detecting radio activity during a listening period among the listening periods (Relay, first device, channel scan is to detect a WOR frame from an end-point, second device. The time between two consecutive channel scans is defined by CADPeriodicity parameter. §3.2.1, pg. 11, ln. 334-342), and switching to a reception mode in order to receive the wake-up message (If radio activity is detected, the relay, first device, attempts to demodulate the incoming packet. Once a valid WOR frame is received, the relay listens to the subsequent LoRaWAN message. §3.2.4, pg. 13, ln. 388-401).
RE Claim 5, 14, LoRaWAN® Relay Specification TS011-1.0.0 discloses a method or device:
further comprising: determining, via the application layer of the first device, whether the second device corresponds to one or more devices listed in a predefined list of devices (Relay, first device, shall be able to filter Join-Requests based on a filter algorithm and lookup table. Forward/Filter method is based on JoinEUI and DevEUI. Relay can also filter all Join-Requests that do not match the lookup table. §8.6, pgs. 30-31, ln. 914-931; Filter/Forward Examples. Appendix 3, pg. 58, ln. 1824-1849).
RE Claim 7, 15, 18, LoRaWAN® Relay Specification TS011-1.0.0 discloses a method or device:
wherein the data communication network comprises a LoRaWAN type of network (LoRaWAN end device, Relay device, Gateway, §2 pg. 8), the first device is an end-node of the LoRaWAN type of network which is configured to implement relay node functionalities of the LoRaWAN type of network via its application layer (Relay, a first device, is based on same hardware architecture as a regular end-device, §2 pg. 8; Relay protocol supports forwarding information from the end-device via the relay to the application server. Uplink will be received by the relay and then forwarded to the Network Server using the relay’s own LoRaWAN link. §3.1, pg. 9, ln. 299-307; Fig. 2, pg. 10).
RE Claim 8, 16, 19, LoRaWAN® Relay Specification TS011-1.0.0 discloses a method or device:
wherein the wake-up message (Protocol includes a Wake On Radio (WOR) frame sent by the end-device, a second device, to the relay, a first device. §3.1, pg. 9, ln 284-286.), the acknowledgment message (Relay, first device, sends a Wake On Radio Acknowledge (WOR ACK) to the end device, second device, if the WOR frame from the end-device is valid. §3.3, pg. 14, ln.418-427), and the uplink data transmission message are messages in the LoRaWAN Relay protocol (Relay protocol supports forwarding information from the end-device via the relay to the application server. Uplink will be received by the relay and then forwarded to the Network Server using the relay’s own LoRaWAN link. §3.1, pg. 9, ln. 299-307; Fig. 2, pg. 10).
RE Claim 6, 17, 20, LoRaWAN® Relay Specification TS011-1.0.0 discloses a method, device, or computer readable medium with instructions:
A wireless communication device (LoRaWAN end device, Relay device, Gateway, §2 pg. 8) comprising:
a radio transceiver (End device and Relay hardware architecture includes radio, a transceiver, §2 pg. 8);
a memory (End device and Relay hardware architecture includes a micro-controller, §2 pg. 8; A micro-controller is a processor and inherently has memory to operate.); and
at least one processor operably coupled to the radio transceiver and to the memory (End device and Relay hardware architecture includes a radio, transceiver, and a micro-controller, §2 pg. 8; A micro-controller is a processor and inherently has memory to operate.), and configured for the implementation of a method of communication between a first device and a second device (Capabilities and controls are required that comply with LoRaWAN Layer 2 Specification, §2 pg. 8), the first device being a low-power wireless end-device of a LP-WAN type data communication network (Relay, a first device, is based on same hardware architecture as a regular end-device, §2 pg. 8), and the second device being a low-power wireless device that is not a node of the LP-WAN type data communication network (Relay, first device, is useful when the end-device, second device, has insufficient coverage from LoRaWAN gateways to establish and maintain a satisfactory direct connection with the network, §2 pg. 8; Without a direct connection, the second device is not a node of the network), the method being implemented by the second device, and comprising:
transmitting, to an application layer of the first device (Relay protocol supports forwarding information from the end-device via the relay to the application server. Uplink will be received by the relay and then forwarded to the Network Server using the relay’s own LoRaWAN link. §3.1, pg. 9, ln. 299-307; Fig. 2, pg. 10), a wake-up message on a frequency channel defined for wireless communications between the first device and the second device (Protocol includes a Wake On Radio (WOR) frame sent by the end-device, a second device, to the relay, a first device. §3.1, pg. 9, ln 284-286.);
receiving, from the application layer of the first device (Relay protocol supports forwarding information from the end-device via the relay to the application server. Uplink will be received by the relay and then forwarded to the Network Server using the relay’s own LoRaWAN link. §3.1, pg. 9, ln. 299-307; Fig. 2, pg. 10), a receipt acknowledge message of the wake-up message (Relay, first device, sends a Wake On Radio Acknowledge (WOR ACK) to the end device, second device, if the WOR frame from the end-device is valid. §3.3, pg. 14, ln.418-427); and
transmitting a data packet to the application layer of the first device (End-device, second device, sends its LoRaWAN uplink, data packets, to relay, first device. §3.4, pg. 14, ln. 433-449; Relay protocol supports forwarding information from the end-device via the relay to the application server. Uplink will be received by the relay and then forwarded to the Network Server using the relay’s own LoRaWAN link. §3.1, pg. 9, ln. 299-307; Fig. 2, pg. 10).
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.
Claim(s) 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over LoRaWAN® Relay Specification TS011-1.0.0, in view of Peleg et al. (US 20210153033 A1, hereinafter “Peleg”).
RE Claim 3, 12, LoRaWAN® Relay Specification TS011-1.0.0 does not explicitly disclose a method or device, however Peleg discloses:
further comprising: transmitting, to a location server configured to receive data from an LP-WAN type data communication network, data exchanged with the second device in radar mode. (Examiner interpretation of ‘radar mode’ in conjunction with a ‘location server’ is an exchange of data to determine location of the second device. LPWAN technologies include LoRa. ¶0005; Network topology of LPWAN communication network that supports two-way communication between end-points, second devices, and packet network. ¶0037, Fig. 1; Coverage is extended to endpoints by one or more relaying modules to provide reliable communication, standard such as LoRa, between the base stations and remote end points outside coverage of the base stations. ¶¶0048, 0053, Fig. 1; LPWAN supports estimating geolocation (e.g. geographical coordinates) of an end-point based on receiving uplink messages. ¶0158; Based on the RSSI’s estimated in the respective base stations, the network application server, NAS, can estimate the end-point geolocation. ¶0160)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of LoRaWAN® Relay Specification TS011-1.0.0, specification for a LoRaWAN relay to extend coverage of network, with the teachings of Peleg, method of geolocation of end devices that are outside a base station coverage by employing a relay node.
The motivation in doing so would be to support locating an end device that is outside of established base station coverage but withing coverage a relay device. Obtaining location of end device is important for installation, maintenance, and correlating end device with a specific location. (LoRaWAN® Relay Specification TS011-1.0.0; Peleg: Abstract, ¶¶0003-0005, 0006-0007, 0022-0026, 0158-0163)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
US 10326518 B1 Magley et al.
“Repeater And Node Utilization”
Methods and systems of managing communications through a repeater between a gateway and a plurality of nodes in a long-range wireless wide area network include, in various independent aspects, joining the plurality of nodes to the network through the gateway by transmitting to a join server at least a portion of join request messages received from the plurality of nodes, receiving messages from the gateway and identifying associated nodes of the plurality of nodes to which those messages are then transmitted, and transmitting messages to the gateway with physical layer payloads corresponding to payloads of messages received from the plurality of nodes.
WO 2025053809 A1 Arous et al.
“A RELAYING METHOD FOR LoRa NETWORKS”
The proposed invention provides an adaptive, low-complexity relaying mechanism for LoRa devices. The positioning of the relay is chosen to be geometrically effective so that it maintains a reliable connection with the gateway and nearby end devices. Based on RSSI and SF and link budget calculations, the relay can distinguish between devices that can reach the gateway, cannot reach the gateway without tuning existing transmission parameters and cannot communicate with the gateway whatever the transmission parameters are. Thus, the relay takes an action or not according to communication status of the end devices.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL A. LANGER whose telephone number is (703)756-1780. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm, Eastern.
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, Nishant B. Divecha can be reached at 1 (571) 270-3125. 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.
/PAUL A. LANGER/
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights