DETAILED ACTION
This is in response to the RCE filed on February 20th 2026.
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 2/20/26 has been entered.
Response to Arguments
Applicant’s remarks regarding claims 1, 19, 28 and 32 have been considered but are not persuasive. Initially, applicant notes (pg. 9) the phrase “defining network behavior” was added to clarify the nature of the object being obtained through the LwM2M client/server architecture. This is not persuasive to overcome the rejection as explained in the advisory action. Examiner notes applicant’s remark that this was not the sole basis for attempting to distinguish over the art.
Next (pg. 10), applicant generally repeats the same arguments that have been previous considered and responded to: applicant states GitHub teaches away from the claimed invention because it is directed to self-hosted MUD files – which is the opposite of the claimed invention wherein a MUD object is obtained from a server. This is not persuasive to overcome the rejection. Even assuming arguendo, claims 1 and 28 recite “hosting a MUD file, in local memory of the IoT device” (emphasis added). Thus, by teaching “self-hosted” MUD files, GitHub is directly in line with the claimed invention, it does not teach away as suggested by applicant. By attempting to distinguish the claims in this manner, applicant is basically arguing the inventive concept lies in the extremely well-known concept of a client/server architecture wherein data is obtained by a client from a server. This is clearly known in the art and explicitly taught by Zhang and GitHub (see pg. 3-4 Fig. 1). Therefore, this argument is not persuasive.
Applicant refers (pg. 10) to the invention as solving a different problem – dynamic server-managed MUD content. Examiner does not agree or disagree. However, there is nothing in claims about “dynamic” management. Claim 1 merely requires obtaining a MUD object, storing it, and then using/exposing the content. Therefore, this is not persuasive because applicant is relying on features not in the claims. Applicant is advised that Zhang explicitly discloses a server manages clients (paragraph 5).
Applicant again argues Zhang is directed to queue management and does not cure the deficiencies of GitHub because it is silent regarding MUD files, MUD objects, or any manufacturer usage descriptions (pg. 9). This is also not persuasive. As previously explained, GitHub discloses MUD files, objects and manufacturer usage descriptions. Zhang was not relied upon to teach these features. Applicant is essentially arguing the references individually which is not persuasive when the rejection is based on a combination of references. Applicant does not seem to assert that Zhang does not teach what it was relied upon for (i.e. LwM2M client/server).
Applicant also repeats the argument there is no motivation to combine. This is not persuasive as the office action cited explicit teaching, suggestion, motivation from Zhang for the combination (see the detailed rejection below). Applicant’s reasoning seems to be their own self-characterization of the reference’s purpose (e.g. Zhang is about “queue management”).
Applicant states (pg. 11) that even if network behavior is inherent to MUD, this does not disclose obtaining a MUD object from a server. As explained above, there is nothing inventive about obtaining data from a server. GitHub clearly discloses the features regarding the MUD object, Zhang was not relied upon to teach MUD files and while GitHub does discuss using LwM2M, Zhang was relied upon for teaching LwM2M client/server, which includes receiving data from a server (Fig. 1). Therefore, any arguments the references do not teach these features are not persuasive to overcome the rejection.
Applicant also mentions claims 19 and 32 and states neither reference disclose providing content of a MUD file to a client. This is not persuasive. GitHub clearly teaches retrieving MUD files for local use (pg. 3-6), using CoAP to incorporate device specific information via l2m2m objects and resources available at the server (pg. 4-6). Furthermore, Zhang teaches traditional client/server architecture wherein data is obtained from a server. Thus, the combination clearly discloses the claimed concept of obtaining MUD content from a server for use by a client on an IoT device.
Regarding the new claims, examiner appreciates the citations to the specification for support. Applicant makes brief remarks (pg. 12-13) regarding the new claims. As indicated below, some of these remarks are persuasive (e.g. claim 39 is allowable) while some of the new claims are rejected for the reasons given in the detailed rejection.
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) 1-4, 7-8, 19-22-24, 28-29, 32 and 35-38 and 45 are rejected under 35 U.S.C. 103 as being unpatentable over GitHub jaimejim/draft-coap-mud “Using MUD files in CoAP” 11/15/2019 (cited in IDS filed on 9/2/22, hereinafter “GitHub” in view of Zhang et al. US 2021/0297309 A1.
Regarding claim 1, GitHub discloses a method by an Internet of Things device (IoT / end devices – pg. 3-4) comprising:
hosting a Manufaturer Usage Description, MUD, file in local memory of the IoT device (host MUD file on endpoint – pg. 4; “hosted on the thing” – pg. 5; and Self-hosted MUD Architecture – pg. 6);
a Lightweight Machine-to-Machine, LwM2M … a MUD object (MUD on COAP includes lwm2m objects – see pg. 5);
storing the MUD object within the MUD file in the local memory of the IoT device (MUD file includes lw2m objects – see pg. 5), and
exposing content of the MUD file from the local memory of the IoT device as a Constrained Application Protocol, CoAP, resource (usage of MUD on CoAP environments – pg. 4 abstract and Introduction; and the IoT thing “exposes” a MUD URL to the network – pg. 4; also see pg. 5-6 “MUD on CoAP”).
GitHub does not explicitly disclose obtaining, by a Lightweight Machine-to-Machine, LwM2M, client for and in the IoT device [a object] from a LwM2M server but this is taught by Zhang (abstract, paragraphs 2-7, Figs. 1-3). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify GitHub with the LwM2M client/server taught by Zhang for the purpose of communication. GitHub itself already discusses the use of LwM2M in the MUD on CoAP environment (pg. 5). Zhang suggests that the use of LwM2M enhances resource constrained devices (e.g. IoT devices) which mitigates or eliminates known problems (see paragraphs 10-13).
Regarding claim 2, GitHub discloses providing content of the MUD file from the local memory of the IoT device to a MUD manager using CoAP to create an access policy which controls communications with the IoT device through at least one of a network router and a network switch (file is hosted on IoT device as discussed above, and provided to MUD manager, MUD includes “access policy”, using CoAP, and router or switch – see pg. 4-6 and Figures therein).
Regarding claim 3, GitHub discloses providing a … device policy to the MUD manager which controls communications to the IoT device; and providing a … device policy to the MUD manager which controls commu8nications from the IoT device (one goal of MUD is to define/control network access policy – pg. 4; the MUD manager retrieves the MUD file and applies “access policy” for the IOT device – pg. 4-6).
GitHub does not explicitly disclose separate “to-device” or “from-device” policies. However, it teaches that that MUD permits the device “to send and receive”, thus teaching or suggesting both a “to” policy and a “from” policy (see pg. 5). Therefore, these features would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention based on the teaching of GitHub. GitHub suggests this prohibits unauthorized traffic (pg. 5). Further evidence these are merely well-known features and thus obvious is found in the MUD specification (RFC 8520, Section 3.3).
Regarding claim 4, GitHub discloses receiving, by a CoAP server of the IoT device, a CoAP GET command from the MUD manager; and providing, by the CoAP server on the IoT device responsive to the CoAP GET command, the content of the MUD file to the MUD manager (MUD manager will “get” the MUD file from the IoT device using COAP – see pg. 5-6).
Regarding claim 7, GitHub discloses receiving resources defined in a LwM2M resource structure from the … server (receive MUD file from server – pg. 4-6; use lwm2m objects – pg. 5);
accessing a mapping between the resources and MUD objects (URL maps to description – pg. 5-6);
generating or updating the MUD file in the local memory of the IoT device based on the MUD objects mapped to the resources received (the MUD file is hosted on IoT device and provided to MUD manager, MUD file includes objects using CoAP – see pg. 4-6 and Figures therein; also, MUD file version is part of known RFC 8520).
GitHub does not explicitly disclose the LwM2M client/server but this is taught by Zhang as explained above in the rejection of the claim. The motivation to combine is the same.
Regarding claim 8, GitHub discloses responsive to generating or updating of the MUD file in the local memory of the IoT device, providing content of the MUD file that is generated or updated to a MUD manager using CoAP to create another access policy which controls communications with the IoT device through the at least one of a network router and a network switch (usage of MUD on CoAP environments – pg. 4 abstract and Introduction; and the IoT thing “exposes” a MUD URL to the network – pg. 4; also see pg. 5-6 “MUD on CoAP”; the MUD file is hosted on IoT device and provided to MUD manager, MUD includes “access policy”, using CoAP, and router or switch – see pg. 4-6 and Figures therein).
Regarding claim 19, it is a method claim directed to the LwM2M server, any features corresponding with the method of claim 1 are rejected for similar reasons, for example:
GitHub discloses an IoT device using CoAP, determining a policy to be used to control communications with the IoT device, determining content of a MUD file based on the policy that is determined; and providing the content of the MUD file to … the IoT device using CoAP (see claim 1 or pg. 4-6 of GitHub).
GitHub does not explicitly disclose a LwM2M client/server or receiving a registration command from a LwM2M client. However, this is taught by Zhang. Zhang discloses an LwM2M client and server as explained above in the rejection of claim 1. Zhang also teaches the registration command (paragraphs 5, 8 and Fig. 3). The motivation to combine is the same as that given above.
Regarding claim 20, GitHub discloses a MUD file stored in local memory of the IoT device (pg. 4-6); storing the URL as a MUD based resource type in a LwM2M object structure (use URL for access – pg. 4-6; l2m2m objects – pg. 5); responding to a query from an electronic device identifying the MUD based resource type by providing the URL to the electronic device (respond to request with URL – pg. 4-6 and Figs.).
GitHub does not explicitly disclose the LwM2M client/server or a registration request/command but this is taught by Zhang as discussed above. The motivation to combine is the same.
Regarding claim 21, GitHub discloses the command is received from … the IoT device using CoAP (pg. 4-6). GitHub does not explicitly disclose the LwM2M client but this is taught by Zhang (Figs. 1-3). The motivation to combine is the same.
Regarding claim 22, GitHub discloses the URL is received in a … CoAP command from … the IoT device (pg. 4-6). GitHub does not explicitly disclose using “POST” but it teaches URL, HTTP and CoAP. POST is merely a well-known function that would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. This is merely the combination of a well-known technique (i.e. POST) according to its established function in order to yield a predictable result.
GitHub does not explicitly disclose the LwM2M client but this is taught by Zhang (Figs. 1-3). The motivation to combine is the same.
Regarding claim 23, GitHub discloses providing content of the MUD file … for the IoT device using CoAP (pg. 4-6), providing a MUD object using a … CoAP command (use CoAP – see pg. 4-6 and figures). GitHub does not explicitly disclose using “POST” or “PUT” but it teaches URL, HTTP and CoAP. POST and PUT are merely a well-known function that would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. This is merely the combination of a well-known technique (i.e. POST, PUT) according to its established function in order to yield a predictable result.
GitHub does not explicitly disclose the LwM2M client but this is taught by Zhang (Figs. 1-3). The motivation to combine is the same.
Regarding claim 24, GitHub discloses accessing resources defined in a LwM2M resource structure (use l2m2m object – pg. 5); accessing a mapping between the resources and MUD objects (MUD manager maintains mappings – pg. 4-6); and generating or updating the MUD file in the local memory of the IoT device based on the MUD objects mapped to the resources (MUD file stored locally – pg. 4-6; also, MUD file version is part of known RFC 8520).
GitHub does not explicitly disclose the LwM2M server but this is taught by Zhang as explained above. The motivation to combine is the same.
Regarding claim 28, it is a device claim that corresponds to the method of claim 1; therefore, it is rejected for the same reasons.
Regarding claims 29, 35-36 and 37-38, they correspond to claims 2-4 and 7-8 respectively, so they are rejected for the same reasons.
Regarding claim 32, it is directed to a server that corresponds to the method of claim 19; therefore it is rejected for the same reasons.
Regarding claim 45, GitHub teaches a server discovers whether MUD capability is available at the client (device advertises MUD – pg. 3-6). GitHub does not explicitly disclose but Zhang teaches registering, by the IoT device, with the LwM2M server through a POST command (register/registration with server – paragraph 5, Fig. 1 and Fig. 6 step 102, paragraph 81; use HTTP – paragraph 3, which includes “POST” – see Fig. 3). One of ordinary skill in the art would understand the benefits of registration, i.e. server can then communicate with client.
Claim(s) 41 and 43 are rejected under 35 U.S.C. 103 as being unpatentable over GitHub and Zhang in view of Lear et al. US 2019/0319953 A1.
Regarding claim 41, the combination of GitHub and Zhang teach the MUD file stored in the local memory of the IoT device, communication with a LwM2M server, and advertising the MUD file to a MUD manager as explained in the rejections above. The combination of GitHub and Zhang does not explicitly disclose the server modifying content of the MUD file but this is taught by Lear (abstract, paragraphs 12, 31-32 and Fig. 3). Lear also teaches enabling a MUD file manger to validate the MUD file (provide secure modification including certification of updated MUD – see abstract, paragraphs 14, 35, 49 and Fig. 5).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of GitHub and Zhang with the teachings of Lear for the purpose of modifying and validating MUD files and/or objects. Lear teaches that by dynamically modifying MUD, device behavior is allowed to change which can provide benefits such as new functions (paragraph 15).
Regarding claim 43, GitHub discloses the MUD file hosted in the local memory of the IoT device as explained above. GitHub and Zhang does not explicitly disclose the MUD file is predefined in memory by a manufacturer of the IoT device but this is taught by Lear (MUD file has predetermined usage description and is provided by device’s manufacturer – see paragraphs 20, 25). Lear also discloses receiving MUD content from a server and dynamic management of MUD files on devices (abstract, Fig. 1). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify GitHub and Zhang with the manufacturer predefined MUD file as taught by Lear. This is merely the definition of “MUD” – “manufacturer” usage description. Also, the motivation given above is relevant to this combination.
Claim(s) 5 is rejected under 35 U.S.C. 103 as being unpatentable over GitHub and Zhang in view of Lear et al. “Manufacturer Usage Description Specification” IETF, RFC 8520, March 2019 (cited in IDS 9/2/22).
Regarding claim 5, GitHub discloses the content of the MUD file provided to the MUD manager comprises [data] describing network behavior for the IoT device (pg. 4-7).
GitHub does not explicitly disclose a YANG-based JSON object but this is well-known in the art. Lear explicitly discloses that MUD files contain YANG-based JSON objects (Section 1.3). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of GitHub and Zhang with the JSON object taught by Lear. Lear is the standard specification (IETF, RFC). Thus, this is merely the combination of a well-known technique according to its established function in order to yield a predictable result.
Allowable Subject Matter
Claims 39-40, 42 and 44 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claims 39, 42 and 44 recite additional features that when considered as whole, distinguish over the prior art. Claim 40 is allowable based on its dependency.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Salgueiro et al. US 2020/0259960 A1 discloses network policy for IoT devices using MUD files (abstract, Fig. 1, paragraph 21).
Shurtleff et al. US 2020/0162503 A1 discloses IoT devices (abstract) and using CoAP (paragraph 22) and enforcing policies (paragraphs 67, 75).
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
Prosecution Insights