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 .
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 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yi et al (US Patent Application Publication 2020/0236591), and further in view of Yi-Hsien Ko (US Patent Application Publication 2021/0067917). Hereinafter Yi and Ko.
Regarding claim 1, Yi discloses a utility device within a utility system (IoT device in communication system, Figs. 1 and 3), comprising:
a power source (the wireless device (UE), such as an IoT device, includes a power unit/battery, paragraphs [0020], [0096]);
a communication interface (the wireless device (UE), such as an IoT device, includes communication unit, paragraph [0095]); and
one or more electronic processors, wherein the one or more electronic processors are configured to (the wireless device (UE), such as an IoT device, includes control unit that controls electric/mechanical operation of the wireless device based on programs/code/commands/information stored in the memory unit, paragraph [0095]):
receive a message via the communication module while in the receive mode (the UE receives radio signals containing PDCP PDU, paragraph [0142]);
analyze a header of the received message to determine whether the received broadcast message is relevant (the UE checks the header compression indicator of the received PDCP PDU to figure out which header compression algorithm is applied, and performs header decompression, paragraphs [0142] – [0144]).
However, Yi does not explicitly “periodically transition from a standby mode to a receive mode; monitor for a broadcast message while in the receive mode;” “receive a broadcast message;” “analyze the broadcast message;” “wherein determining whether the received broadcast is relevant includes determining whether the received broadcast message includes one or more data packets associated with a unique network ID of the utility device based on the analysis of the header;” and “resume operation in the standby mode in response to determining that the received broadcast message is not relevant.”
Ko discloses “periodically transition from a standby mode to a receive mode; monitor for a broadcast message while in the receive mode” as every node is on long-term standby in IoT system, where the node is in power saving mode until a waking signal is received (paragraphs [0042], [0043]); “receive a broadcast message;” “analyze the broadcast message;” “wherein determining whether the received broadcast is relevant includes determining whether the received broadcast message includes one or more data packets associated with a unique network ID of the utility device based on the analysis of the header” as the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); and “resume operation in the standby mode in response to determining that the received broadcast message is not relevant” as the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and the node stops broadcasting the network packet if the ID field has been recorded (paragraph [0060]; the node ID is checked and stopped broadcasting if it is not relevant to be broadcasted to the network, and the node goes back to long-term standby mode (power saving mode) until receiving another waking signal).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 2, Yi and Ko disclose the utility device of claim 1, but Yi does not explicitly disclose wherein the one or more electronic processors are further configured to process the received broadcast message in response to determining that the received broadcast message is relevant.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 3, Yi and Ko disclose the utility device of claim 1, but Yi does not explicitly disclose wherein the header includes one or more unique network ID values and at least one rule.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 4, Yi and Ko disclose the utility device of claim 3, but Yi does not explicitly disclose wherein determining whether the received broadcast message is relevant is based on applying the at least one rule to the one or more unique network ID values in the header.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 5, Yi and Ko disclose the utility device of claim 3, but Yi does not explicitly disclose wherein the at least one rule defines one or more of a range of included unique network ID values, a range of excluded unique network ID values, and a function defining a plurality of excluded unique network ID values.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]; the threshold provides a range for the unique network ID values).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 6, Yi and Ko disclose the utility device of claim 5, but Yi does not explicitly disclose wherein the function is a modulo function.
Ko discloses function module that includes sensor element and the related electronic components for performing a corresponding function, where the sensor element is utilized to conduct sensing in order to generate the sensed data and convert the sensed data into signals (paragraph [0040]).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the function module of the IoT node for performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 7, Yi and Ko disclose the utility device of claim 1, Yi discloses wherein the utility device is a sensor device (the IoT device includes a sensor and smartmeter, paragraph [0019]).
Regarding claim 8, Yi and Ko disclose the utility device of claim 1, Yi discloses wherein the power source is a battery (the wireless device (UE), such as an IoT device, includes a power unit/battery, paragraphs [0020], [0096]).
Regarding claim 9, Yi and Ko disclose the utility device of claim 1, but Yi does not explicitly disclose wherein the unique network ID is a value from 1-N, where N is the number of utility devices in the utility network.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]; the threshold provides a range for the unique network ID values, i.e. N is the threshold for the range).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 10, Yi discloses a method for generating broadcast messages within a utility network, the method comprising:
generating a message (the transmitting PDCP entity applies header compression algorithm, constructs a PDCP PDU including the header compression indicator, and transmits the PDCP PDU, paragraphs [0128] – [0131]);
generating a header for the generated message (the transmitting PDCP entity applies header compression algorithm, constructs a PDCP PDU including the header compression indicator, and transmits the PDCP PDU, paragraphs [0128] – [0131]); and
transmitting the generated message (the transmitting PDCP entity applies header compression algorithm, constructs a PDCP PDU including the header compression indicator, and transmits the PDCP PDU, paragraphs [0128] – [0131]).
However, Yi does not explicitly disclose “generating a broadcast message, wherein the broadcast message includes one or more data packets associated with one or more utility device, wherein each of the one or more utility devices has a unique network ID;” “generate a header for the generated broadcast message, wherein the generated header includes a first unique network ID value, a second unique network ID value, and at least one rule;” and “transmitting the generated broadcast message, wherein the header is configured to define one or more exclusion zones, the exclusion zones including one or more unique network ID values that have no associated data packets within the generated broadcast message.”
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]; the threshold provides a range for the unique network ID values).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 11, Yi and Ko disclose the method of claim 10, but Yi does not explicitly disclose wherein each of the unique network IDs have values from 1-N, where N is the number of utility devices within the utility network.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]; the threshold provides a range for the unique network ID values, i.e. N is the threshold for the range).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 12, Yi and Ko disclose the method of claim 10, but Yi does not explicitly disclose wherein the first unique network ID value is the lowest unique network ID value having a data packet within the generated broadcast message and the second unique network ID value is the greatest unique network ID value having a data packet within the generated broadcast message.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 13, Yi and Ko disclose the method of claim 10, but Yi does not explicitly disclose wherein the at least one rule defines one or more of a range of included unique network ID values, a range of excluded unique network ID values, and a function defining a plurality of excluded unique network ID values.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]; the threshold provides a range for the unique network ID values).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 14, Yi and Ko disclose the method of claim 13, but Yi does not explicitly disclose wherein the function is a modulo function.
Ko discloses function module that includes sensor element and the related electronic components for performing a corresponding function, where the sensor element is utilized to conduct sensing in order to generate the sensed data and convert the sensed data into signals (paragraph [0040]).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the function module of the IoT node for performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 15, Yi discloses a method of processing broadcast messages at a utility device, comprising:
receiving, via a communication interface of the utility device, a message (the UE receives radio signals containing PDCP PDU, paragraph [0142]);
analyzing a header of the received message (the UE checks the header compression indicator of the received PDCP PDU to figure out which header compression algorithm is applied, and performs header decompression, paragraphs [0142] – [0144]);
determining whether the received broadcast message is a relevant message (the UE checks the header compression indicator of the received PDCP PDU to figure out which header compression algorithm is applied, and performs header decompression, paragraphs [0142] – [0144]).
However, Yi does not explicitly “periodically transitioning the utility device from a first mode to a second mode;” “analyzing a header of the received broadcast message to determine whether the received broadcast message includes one or more data packets associated with a unique network ID of the utility device;” “determining whether the received broadcast message is a relevant message in response to determining that the received broadcast message includes one or more data packets associated with the unique network ID of the utility device;” and “processing the received broadcast message in response to determining that the received broadcast message is a relevant broadcast message.”
Ko discloses “periodically transitioning the utility device from a first mode to a second mode” as every node is on long-term standby in IoT system, where the node is in power saving mode until a waking signal is received (paragraphs [0042], [0043]); “analyzing a header of the received broadcast message to determine whether the received broadcast message includes one or more data packets associated with a unique network ID of the utility device;” “determining whether the received broadcast message is a relevant message in response to determining that the received broadcast message includes one or more data packets associated with the unique network ID of the utility device;” and “processing the received broadcast message in response to determining that the received broadcast message is a relevant broadcast message” as the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 16, Yi and Ko disclose the method of claim 15, but Yi does not explicitly disclose further comprising resuming operation in the first mode in response to determining that the received broadcast message is not a relevant broadcast message.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and the node stops broadcasting the network packet if the ID field has been recorded (paragraph [0060]; the node ID is checked and stopped broadcasting if it is not relevant to be broadcasted to the network, and the node goes back to long-term standby mode (power saving mode) until receiving another waking signal).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 17, Yi and Ko disclose the method of claim 15, but Yi does not explicitly disclose wherein the first mode is a standby mode and the second mode is a receive mode.
Ko discloses every node is on long-term standby in IoT system, where the node is in power saving mode until a waking signal is received (paragraphs [0042], [0043]).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 18, Yi and Ko disclose the method of claim 15, but Yi does not explicitly disclose wherein the header includes one or more unique network ID values and at least one rule.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 19, Yi and Ko disclose the method of claim 18, but Yi does not explicitly disclose wherein determining whether the received broadcast message is relevant is based on applying the at least one rule to the one or more unique network ID values in the header.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Regarding claim 20, Yi and Ko disclose the method of claim 18, but Yi does not explicitly disclose wherein the at least one rule defines one or more of a range of included unique network ID values, a range of excluded unique network ID values, and a function defining a plurality of excluded unique network ID values.
Ko discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]; the node ID is checked and added to the header if it is relevant to be broadcasted to the network); the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]; the threshold provides a range for the unique network ID values).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Yi and Ko before him or her, to incorporate the IoT node performing specified function with the network packet as taught by Ko, to improve the IoT device of Yi for the motivation of receiving signals at any time on long-term standby, and maintaining long-term connection for receiving signals at any time from other devices (paragraph [0004] of Ko).
Response to Arguments
Applicant's arguments, filed January 2, 2026, with respect to Claims 1 – 20 have been fully considered but they are not persuasive. Applicants argue that YI and KO do not teach A) “periodically transition from a standby mode to a receive mode,” “ receive a broadcast message via the communication module while in the receive mode,” and “analyze a header of the receives broadcast message to determine whether the received broadcast message is relevant, wherein determining whether the received broadcast is relevant includes determining whether the received broadcast message includes one or more data packets associated with a unique network ID of the utility device based on the analysis of the header” in Claim 1, B) “generating a header for the generated broadcast message, wherein the generated header includes a first unique network ID value, a second unique network ID value, and at least one rule,” and “wherein the header is configured to define one or more exclusions zones, the exclusion zones including one or more unique network ID values that have no associated data packets within the generated broadcast message” in Claim 10, and “analyzing a header of the received broadcast message to determine whether the received broadcast message includes one or more data packets associated with a unique network ID of the utility device” in Claim 15.
In response to A), the examiner respectfully disagrees.
First, YI is cited to teach the wireless device (UE) such as IoT device includes sensor and smart meter (paragraphs [0019], [0095]), where the UE receives radio signals containing PDCP PDU, checks the header compression indicator of the received PDCP PDU to figure out which header compression algorithm is applied and performs header decompression (paragraphs [0142] – [0144]). The IoT device analyzes a header of the received message to determine whether the compression algorithm is relevant, and applies decompression if it is relevant.
KO teaches every node is on long-term standby in IoT, where the node is in power saving mode until a waking signal is received (paragraphs [0042], [0043]). In addition, the node device keeps listening to the waking signal in the power saving mode (paragraph [0043]). As such, the IoT device (node) is periodically transitioning from standby mode to waking mode (i.e. receive mode) when a waking signal is received (i.e. keeps listening during the duration of the standby mode until the standby mode is transitioned to the waking mode).
KO is then cited to teach the node receiving a network packet broadcasted over the IoT network, where the node analyzes the network packet and checks whether the network packet records a node ID of the received node is in the ID field to perform the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcast to the network or the node stops broadcasting the network packet if the ID field has been recorded (paragraph [0060]). The IoT node receives the broadcast message, analyzes the header of the broadcast message to determine if the node ID is relevant to the IoT node that received the broadcast message (i.e. the node ID is added to the header as it is relevant to the function of the network packet to add the node ID), where the IoT node stops broadcasting if it is not relevant (i.e. the node ID is not added to the header as it is not relevant to the function of the network packet to add the node ID).
However, it appears that applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “does this message contain data for me”) are not recited in the rejected claim(s). It is noted that the claim recites “relevant” in the limitation, and thus, the question of “have I already seen this message?” in KO, under Broadest Reasonable Interpretation (BRI), is “relevant” to the device to determine whether a function is to be performed. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
In response to B), the examiner respectfully disagrees.
First, YI is cited to teach the wireless device (UE) such as IoT device includes sensor and smart meter (paragraphs [0019], [0095]), where the transmitting PDCP entity applies header compression algorithm, constructs a PDCP PDU including the header compression indicator, and transmits the PDCP PDU (paragraphs [0128] – [0131]). The IoT device generates a message (PDU), generates a header (including header compression), and transmits the PDU.
KO discloses the node receives a network packet broadcasted over IoT network, where the node analyzes the network packet to check if the network packet records a node ID of the received node is in an ID field, and performs the function that indicates by a function field of the header of the network packet to add node ID of the node to the ID field and broadcasted to the network (paragraph [0060]). The IoT node receives the broadcast message that is generated, and the IoT node analyzes the header of the broadcast message to determine if the node ID is associated with the IoT node that received the broadcast message.
KO is also cited to teach the node performs a function when it determines that the counting value does not exceed a threshold, and adds one to the counting field, and broadcasts the network packet to the network, where the information recorded in the ID field and the counting field of the header of the received network packet is to instruct the node to perform or not perform the specified function (paragraphs [0066] – [0068]). The IoT receives the broadcast message that is generated, checks whether the header of the broadcast message includes node ID that is associated to the IoT node, where the IoT node then performs the function to broadcast the network packet to the network. The IoT node determines whether the counting value exceeds a threshold, and adds one to the counting field when it does not exceed a threshold for broadcasting the network packet to the network. The broadcast message provides whether node ID (i.e. unique network ID value) is included in the ID field, and the counting field is to provide instruction to the node to perform or not perform the specified function (i.e. rule). The threshold provides the range of the counting field to perform or not the specified function of broadcasting the network packet associated with the IoT node with the node ID (i.e. the threshold range (i.e. zone) exceed the counting field threshold prevents (i.e. exclusion zone) the IoT node to perform the specified function (i.e. the exclusion zone has no data packet)).
It appears that applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “pre-defined first and second unique network ID values that define a range”) are not recited in the rejected claim(s). It appears the “range” applicants is referring to distance/area physically. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
In response to C), the examiner maintains that YI and KO disclose the limitations as recited in the claim, which is addressed in Argument (A) above.
Conclusion
THIS ACTION IS MADE FINAL. 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
SHUEY et al (US Patent Application Publication 2008/0219210) – the endpoint meters are operating in the mobile mode that periodically transition between a wake state and a sleep state, where the endpoint meters’ transceivers are active to listen for a wake signal from the mobile device when operating in the wake state, and the endpoint meters' transceivers are not active to listen for the wake signal when operating in the sleep state, where the wake signal notifying the endpoint meters that the mobile device is within a physical proximity of the endpoint meters
PADGETT et al (US Patent Application Publication 2018/0139569) – a plurality of portable guest devices provided to users of the guest engagement system to be carried by the users, each guest device having a unique identifier and including first and second wireless communication antennas respectively configured for Bluetooth low energy (BLE) and near field communication (NFC) communications; a sensor network comprising a plurality of sensors each mounted at a different location, wherein at least one sensor of the plurality of sensors is operative to detect portable guest devices that are proximate thereto and receive unique identifiers therefrom based on BLE communication with the portable guest devices and at least another sensor of the plurality of sensors is operative to detect portable guest devices that are proximate thereto and receive unique identifiers therefrom based on NFC communication with the portable guest devices; a communication network connecting each of the plurality of sensors of the sensor network; and a central server communicatively connected to each of the plurality of sensors of the sensor network via the communication network, and storing a log associating each unique identifier of a portable guest device received using BLE or NFC communications by a sensor of the sensor network, wherein each guest device is configured to selectively operate according to first and second operating modes, each guest device engaging in bi-directional communication using the first wireless communication antenna configured for BLE communications in the first operating mode and engaging in a beacon mode periodically broadcasting a beacon signal using the first wireless communication antenna configured for BLE communications in the second operating mode, and each sensor of the sensor network is operative to transmit a command to a guest device in its communication range to cause the guest device to change operating mode between the first and second operating modes
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAI J CHANG whose telephone number is (571)270-5448. The examiner can normally be reached Monday - Friday, 10AM-6PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Marcus Smith can be reached at (571)270-1096. 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.
/Kai Chang/Examiner, Art Unit 2468
/Thomas R Cairns/Primary Examiner, Art Unit 2468
Prosecution Insights