DETAILED ACTION
This is in response to the amendment filed on December 26th 2025.
Response to Arguments
Applicant’s arguments, see pg. 1, filed 12/26/25, with respect to the claim objection have been fully considered and are persuasive. The objection of claim 13 has been withdrawn.
Applicant's arguments filed 12/26/25 have been fully considered but they are not persuasive. Applicant’s remarks regarding the preamble are noted. The rejection has been updated in response to the amendment. However, the statement that all of the claim language must be given patentable weight and cannot simply be ignored as the Office Action improperly does is not persuasive. The preamble and remaining claim limitations will still be interpreted as set forth in the MPEP. Applicant cites MPEP 2111.02 which clearly does not state “all of the claim language must be given patentable weight” as suggested by applicant. Rather, the preamble will be construed as part of the claim when it recites limitations of the claim or when necessary to give life, meaning and vitality to the claim. In this case, examiner finds the phrase “communicating with and supplying energy for operation to IoT wireless tags” is neither recited in the claim (body) or necessary to give life, meaning and vitality to the claim. Also, the Office Action did not “ignore” any limitations but rather explained why or why not they were being given patentable weight.
Applicant argues (pg. 4-5) the contingent limitations are required because the claimed invention requires both the first and second conditions to occur. This is not persuasive. As acknowledged by applicant, MPEP 2111.04 is explicitly clear that for a method claim, the BRI only requires “steps that must be performed” and does not include steps that may not occur because of conditions not met (i.e. contingent limitations). Applicant seems to assert that because there are 2 conditions (the claim recites “when” twice), this somehow means both conditions are required. This is not accurate. Each “when” recitation is it’s own condition. Neither is required. The MPEP section applicant is relying on clearly states that if the claim requires both A and B conditions to occur, then the BRI requires both A and B. It does not say that simply because two conditions exist, that both are required. Thus, the office did not “read out” any limitations but simply interpreted the claims in accordance with the MPEP.
Applicant also asserts that when is different than if. Examiner agrees the two words have different meanings, however it does not change that the claimed limitations are still condition precedent and thus contingent limitations. Note, the MPEP does not say that only “if” creates a contingent limitation. Therefore, this argument is erroneous. Instead, the inquiry is whether the step “must be” performed. As applicant points out, when the criteria is not met, the claim element is not invoked. Thus, the BRI does not require the claim element because it is possible the criteria is never met. Applicant also suggests the cited paragraphs were not mapped to the claim elements. These citations were provided as a courtesy to applicant since the claim elements are not actually required by the claim, applicant is also directed to the rejection of claim 13. Therefore, applicant’s remarks regarding the 102 rejection are not persuasive.
The rejection of claim 13 is withdrawn based on the amendments; however a new ground of rejection is made under 103.
Applicant’s remarks, pg. 6, regarding the 103 rejection rely on the above; thus they are not persuasive for the same reasons.
Claim Rejections - 35 USC § 102
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-2, 4-6 and 9-12 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Zimny et al. US 2019/0205541 A1.
Examiner note: nearly all the limitations recited by claim 1 are behind a contingent limitation (i.e. “when …”). Thus, the BRI of claim 1, since it is a method claim, requires only those steps that must be performed (see mpep 2111.04). In this case, the only required step is “receiving by the server an indication of a current state of the bridge”. This results in the scope of the claim being so broad, that nearly any prior art teaching remote network device configuration could read on the claim. Examiner has attempted to provide pertinent prior art for applicant’s use during prosecution.
Regarding claim 1, Zimny discloses a method for updating a configuration of a bridge in a network comprising at least the bridge, a gateway, and a server, the server being communicatively coupled to the gateway which is in turn wirelessly communicatively coupled to the bridge (abstract, paragraph 5, Fig. 1; wireless communication – see paragraphs 54, 64) comprising:
receiving by the server an indication of a current state of the bridge (bridge publishes status update about the bridge device to server – see paragraph 141, 144, 148, Fig. 8).
The remaining limitations are not required because “when the current state of the bridge is not a desired state” is a condition precedent that may never occur. However, applicant is advised that Zimny teaches sending and receiving updates/configuration between a bridge and server and thus appears to disclose the features (paragraphs 141-148, Figs. 7-8)
when the current state of the bridge is not a desired state: setting, in the server, the current state of the bridge to pending for the desired state;
transmitting, by the server toward the bridge, a configure request to update the bridge to the desired state; and
when, within a predetermined period of time of transmitting the configure request, a completion message is received by the server from the bridge in response to updating the bridge configuration in response to the configure request, such updating having been performed using at least a portion of a protocol for wireless communication between the gateway and the bridge that does not support acknowledgement (ACK) messages or no acknowledgement (NACK) message (note: Zimny does not appear to explicitly disclose a protocol that does not support ACK messages however there are many well-known protocols in the art such as UDP – see the rejection of claim 13)., setting the current state of the bridge to the desired state in the server.
Regarding claim 2, Zimny discloses the protocol for wireless communication comprises only BLE advertising packets (use BLE standard – paragraphs 82, Fig. 3)
Regarding claim 4, Zimny discloses querying the network for an existing reliable path to the bridge wherein, transmitting the configure request is performed only when there is a reliable existing path to the bridge (the server transmits the request in response to receiving a communication from the bridge, thus it transmits when there is an existing path to the bridge, not before – paragraph 131, Fig. 7; Zimny also teaches device-specific paths which are channels known only to the bridge/server pair in order to communicate – paragraph 136).
Regarding claim 5, it depends from claim 4 and is based on the condition of waiting when a path does not exist. Similar to claim 1, this condition may never occur and therefore the features are not required under the BRI of the claim. Applicant is advised that Zimny teaches periodic communication and waiting for predetermined time periods between transmissions (paragraph 108).
Regarding claim 6, Zimny discloses the indication of the current state of the bridge includes at least one of a firmware version, an API version and a list of at least one capability of the bridge (firmware – see paragraphs 140-141 and 148-151).
Regarding claim 9, Zimny discloses the configure request is transmitted from the server to the gateway and thereafter is relayed by the gateway to the bridge (intermediate device such as message broker relays communication between server and bridge – see Figs. 7-8; Zimny also teaches using a gateway – paragraphs 54-55).
Regarding claim 10, Zimny discloses the current state of the bridge is received at the server by being relayed thereto from the gateway (intermediate device such as message broker relays communication between server and bridge – see Figs. 7-8; Zimny also teaches using a gateway – paragraphs 54-55).
Regarding claim 11, Zimny discloses the current state of the bridge, the configure request, and the completion message are each in a BLE advertising packet (use BLE for wireless communication – paragraphs 57, 59, 102-103, 116 and Figs. 3-5).
Regarding claim 12, Zimny discloses the current state of the bridge, the configure request, and the completion message are each a state-type BLE advertising packet (use BLE for wireless communication – paragraphs 57, 59, 102-103, 116 and Figs. 3-5).
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 3 is rejected under 35 U.S.C. 103 as being unpatentable over Zimny.
Regarding claim 3, Zimny discloses waiting … for the predetermined period of time after transmitting the configure request to receive a … message; and when the predetermined period expires without receipt of the … message, transmitting again (transmit and wait a predetermined period of time – see paragraph 108). Zimny does not explicitly disclose the server waiting for a period of time and then retransmitting when the period expires without receiving a completion/confirmation but this is very well-known in the art. Servers running TCP implement retransmission timeout where they retransmit after a time period expires when no ACK (completion message) is received. This is merely the combination of a well-known technique according to its established function in order to yield a predictable result.
Claim(s) 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Zimny in view of Devine et al. US 10,970,136 B1.
Regarding claim 7, Zimny discloses the configure request is structured based on a … API version that describes the configuration and [an] advertisement packets’ structure (request is based on API version and includes packets elements such as headers for example according to APiVersion – see paragraphs 153-154 and 157, Table 1). Zimny does not explicitly disclose a “new” API version but this is taught by Devine as API versions and a “new” API version (col. 4 ln. 42-50). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zimny with the API translation taught by Devine for the purpose of communicating between devices. Devine teaches this allows for APIs to be update (e.g. new API version) without breaking code dependencies and allows customers to continue using software/systems (col. 1 ln. 60 – col. 2 ln. 53).
Regarding claim 8, Zimny does not explicitly disclose the new API version was requested by the user, but this is taught by Devine (user requests API version – col. 8 ln. 48-53). The motivation to combine is the same as that given above.
Claim(s) 13-15 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Zimny in view of Cholas et al. US 2010/0313226 A1.
Regarding claim 13, it is a method claim that corresponds to the method of claim 1 but is directed to the actions of the bridge, any corresponding limitations are rejected for the same reasons given above.
Zimny discloses:
transmitting by the bridge an indication of a current state of the bridge toward the server (paragraph 141, 148, Fig. 7-8);
receiving, by the bridge, a configure request to update the bridge to a desired state (paragraph 142, 148-149); and
transmitting, by the bridge, a completion message toward the server in response to the bridge successfully completing the updating of the bridge’s configuration per the configure request (reporting channel publishes status updates or changes about the bridge to the server – paragraph 141; also see paragraph 141 which teaches the bridge sends an update firmware information message to the server – this is equivalent to a confirmation that the bridge has completed the update of the configuration).
Zimny also discloses such updating having been performed using at least a portion of a protocol for wireless communication between the gateway and the bridge (wireless – paragraphs 54, 64).
Zimny does not explicitly disclose the protocol does not support ACK messages or NACK messages. Cholas discloses a network bridge and server communicating for remote configuration and provisioning, including obtaining and transmitting status information, as well as updating (paragraph 143). Cholas explicitly discloses using UDP which does not support ACK messages (paragraph 68). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Zimny to use UDP to communicate as taught by Cholas. UDP is extremely well-known in the art and yields predictable results. Thus, this is merely the combination of a known technique according to its established function in order to yield a predictable result.
Regarding claim 14, Zimny discloses the protocol for wireless communication comprises only BLE advertising packets (use BLE standard – paragraphs 82, Fig. 3).
Regarding claim 15, Zimny discloses the indication of the current state of the bridge includes at least one of a firmware version, an API version and a list of at least one capability of the bridge (firmware – see paragraphs 140-141 and 148-151).
Regarding claim 18, Zimny discloses the configure request is relayed by the gateway to the bridge (intermediate device such as message broker relays communication between server and bridge – see Figs. 7-8; Zimny also teaches using a gateway – paragraphs 54-55).
Regarding claim 19, Zimny discloses the current state of the bridge is transmitted toward the gateway to be relayed thereby to the server (intermediate device such as message broker relays communication between server and bridge – see Figs. 7-8; Zimny also teaches using a gateway – paragraphs 54-55).
Regarding claim 20, Zimny discloses the current state of the bridge, the configure request, and the completion message are each in a BLE advertising packet (use BLE for wireless communication – paragraphs 57, 59, 102-103, 116 and Figs. 3-5).
Claim(s) 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Zimny and Cholas in view of Devine et al. US 10,970,136 B1.
Regarding claims 16-17, they correspond to claims 7-8 respectively. Therefore, they are rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Herbert et al. US 2017/0142659 A1 discloses wireless bridges communicating with wireless tags (abstract, Fig. 1).
Swart US 10,028,105 B1 discloses a system comprising a server, a bridge and IoT tags that communicate using BLE (abstract, Fig. 1), and exchanging status information and configuration changes between the bridge and server (Fig. 11).
Wang et al. US 2023/0378807 A1 discloses IoT tags that can harvest energy from radio signals (paragraphs 49, 103, Fig. 2).
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 JASON D RECEK whose telephone number is (571)270-1975. The examiner can normally be reached Flex M-F 9-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, Umar Cheema can be reached at 571-270-3037. 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.
/JASON D RECEK/Primary Examiner, Art Unit 2458