DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/16/2026 has been entered.
Response to Arguments
Applicant’s arguments, see pages 7-8, filed 3/15/26, with respect to the 103 rejection(s) of amended claims 1, 9 and 16 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Rajakarunanayake et al. US 20140123209.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-5, 7, 9-12, 14, and 16-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Independent claims 1, 9 and 16 are amended to recite the limitation “receiving, by the first computing device via the communications channel, a plurality of broadcasts, the plurality of broadcasts identifying, for at least some other computing devices of the plurality of computing devices, other sets of access policies for the other computing devices.” Applicant states that support for this limitation is found in para 0031 and 0032 of the specification. However, the most relevant portion of this disclosure only describes a computing device may receive broadcasts of other computing devices or subscribe to events published by other computing devices and build an access policy data structure. These passages do not describe “receiving, by the first computing device … a plurality of broadcasts … identifying … other sets of access policies for the other computing devices.” [emphasis added] There is no description in these paragraphs that the broadcasts from the computing devices transmits information that identifies access policies for computing devices. The dependent claims inherit the defects of their parent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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, 3-5, 9-12, and 16-19 are rejected under 35 USC 102(a)(1) as being unanticipated by Smith et al. US 20160366188 (hereinafter Smith ‘188) in view of Kommalapati et al. US 20220245006 (hereinafter Kommalapati ‘006), Quinn et al. US 20170155710 (hereinafter Quinn ‘710), and Rajakarunanayake et al. US 20140123209 (hereinafter Rajakarunanayake ‘209).
As per claim 1, Smith ‘188 discloses a method comprising:
receiving, by a first computing device of a plurality of computing devices in communication with one another via a communications channel, from a requesting computing device (fig. 3, ref no. 310), an access request that identifies a subject, a resource identifier that identifies a resource controlled by the first computing device, and an action (fig. 3, request R3, para 0029 “the client device D3 (310) requests access to a resource R3 hosted by device D5 (320)”; para 0028, “As seen, client device 210 issues a request for access to a particular resource R1 of resources R1-R5 included in server device 220. In turn, server device 220 accesses ACL 225. As seen, ACL 225 includes various fields, including a subject field 226, a resource field 227, and a permission field 228. As seen, subject field 226 identifies a source of a request and here identifies client device 210. Resource field 227 identifies one or more resources that may be accessed by the subject, here including requested resource R1, which may be a data value stored in a particular location, such as a sensor register or other storage. In turn, permission field 228 indicates the type of permission to be granted. In this instance a read (R) permission is granted. As such, the requested resource, R1, is provided in a reply from server device 220 to client device 210. Note that permission field 228 may indicate one or more particular types of permissions to be granted. In embodiments of IoT devices, such permissions may include, in addition to CRUDN (create read update delete and notify)”), the first computing device having a first set of access policies, each access policy corresponding to a particular resource of a plurality of resources (fig. 2, “Server Device 5,” ref no. 225; fig. 3, ref. no. 320, R1, R2, R3, R4, ref. no. 325);
determining, by the first computing device, that the resource controlled by the first computing device is not governed by an access policy in the first set of access policies (para 0029, “In this implementation, the client device D3 (310) requests access to a resource R3 hosted by device D5 (320), but according to an ACL entry 325 (with subject, resource and distribution fields 326, 327, 328) the access decision is distributed to an Access Manager Service (AMS1) 330.”);
sending, by the first computing device to the communications channel, the access request (fig. 3, “Request: Subject: D3, Rsrc: R3”);
receiving, by the first computing device, an access request decision from a second computing device of the plurality of computing devices (fig. 3, “Reply: ‘R’”, ref. no. 330; para 0029, “The AMS has an ACL policy 335 (with subject, resource, and permission fields, 336, 337, and 338) that specifies D3's access rights. The original request is relayed to AMS1 by D5 and a response R(ead) is returned.”), the second computing device having a second set of access policies, wherein at least one access policy in the second set of access policies governs access to the resource controlled by the first computing device (fig. 3, ref. no. 335, “ACL Policy”; see also para. 0037, “At diamond 550 it may be determined whether there is a primary or secondary controller coupled to device D that has sufficient memory resources to handle maintenance of an access control policy for device Dn, and also displays low network latency to device D. With reference back to FIG. 1, such primary or secondary controllers may be located in first network portion 110 or second network portion 120, as examples. If such primary or secondary controller exists, control passes to block 560 where an access policy may be created in such controller that defines access rights for the resources of device D. Such one or more ACLs thus may be stored in or associated with such controllers.”); and
granting or denying access to the resource by the subject based on the access request decision (fig. 3, “Reply: R3”).
Smith ‘188 does not expressly disclose but Kommalapati ‘006 discloses the access request identifies an action (para. 0015, “The IoT device 102 communicates with one or more cloud-based devices 120, such as a cloud-based server or an IoT hub that provides services for managing data flows between web-based IoT application(s) and the IoT devices managed by those IoT applications. For example, the cloud-based devices 120 may include an IoT hub that communicates with the IoT device 102 to provision the device, store and manage data collected by the device, and ensure that the IoT device 102 operates as expected/designed. Various channels continuously flow I/O data between the cloud-based device(s) 120 and the IoT device 102. Specifically, the cloud-based device(s) 120 may send the IoT device 102 commands for execution, such as commands for performing actions by one or more actuators 122 of the IoT device 102, retrieving data collected by one or more environmental sensors 104 or metrics computed by control logic 118 of the IoT device 102, write commands such as firmware updates, read commands such as device health and safety parameter checks, etc. In response to the incoming commands, the IoT device 102 performs various actions such as to retrieve requested information (e.g., by reading stored data), updating firmware, controlling actuators to perform requested tasks, computing requested metrics, etc. In addition to executing commands received from the cloud-based devices 120”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith ‘188 such that the access request identifies an action. One would have been motivated to do so to enable the requestor to request specific actions to be performed by the resource.
Smith ‘188 does not disclose, but Quinn ‘710 discloses broadcasting, by the first computing device via the communications channel, information that identifies the resources governed by the first set of access policies (para. 0059, “The IoT devices 101 illustrated in FIG. 3 may broadcast or otherwise send resource declaration messages 181 to inform the device group 110 and master arbiter 160 of resources that the particular IoT device 101 may have.”). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Smith ‘188 to broadcast resources controlled by an IoT device as taught by Quinn ‘710. One of ordinary skill in the art would have done so to implement a conventional and efficient means of communicating available device resources, and to ensure devices on the network are aware of the services and resources provided by each networked IoT device.
Smith ‘188 does not disclose, but Rajakarunanayake ‘209 discloses receiving, by the first computing device via the communications channel, a plurality of broadcasts, the plurality of broadcasts identifying, for at least some other computing devices of the plurality of computing devices, other sets of access policies for the other computing devices (para 0031, “Accordingly, the remote computing device 204 may be configured to generate policies 154 and send the policies 154 to a PWCD 101.”; para 0047, “At reference number 311, the remote computing device 204 transmits the policy 154….In various embodiments of the present disclosure, the remote computing device 204 wirelessly transmits the policy 154 by broadcasting the policy to a plurality of PWCDs 101.”; examiner’s note: any subsequent changes to the access policy, or when a new PWCD is added to the network, would necessitate a broadcast of the current policy).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Smith ‘188 to broadcast access policies for multiple computing devices attached to the network. One of ordinary skill in the art would have done so to implement an efficient means of distributing access policies to network devices.
As per claim 3, Smith ‘188 in view of Kommalapati ‘006, Quinn ‘710, and Rajakarunanayake ‘209 disclose the method of claim 1 (supra). In addition, Smith ‘188 discloses wherein the access request decision is to grant access to the resource (fig. 3, “Reply: ‘R3’”).
As per claim 4, Smith ‘188 in view of Kommalapati ‘006, Quinn ‘710, and Rajakarunanayake ‘209 disclose the method of claim 1 (supra). In addition, Smith ‘188 discloses wherein access is granted to the resource (fig. 3, “Reply: ‘R3’”), and further comprising:
receiving, by the first computing device from the requesting computing device, authentication information that validates to the first computing device that the requesting computing device has been granted access by the second computing device (para. 0015, “ACL structures may be hosted by a remote device such that the requesting device is redirected to the remote device to obtain a single use token granting access to a specific resource or property of the device.”; para 0025, “For non-safety critical operation, a more traditional client-server approach may suffice where, for each access request, an authorization token may be constructed and presented to the resource host for evaluation. The resource host may validate the service issuing the token in order to determine whether the request is authorized.”).
As per claim 5, Smith ‘188 in view of Kommalapati ‘006, Quinn ‘710, and Rajakarunanayake ‘209 disclose the method of claim 1 (supra). In addition, Smith ‘188 discloses wherein access is granted to the resource (fig. 3, “Reply: ‘R3’”) and further comprising:
receiving, by the first computing device from the second computing device, information identifying the requesting computing device and an indication that the requesting computing device has been granted access to the resource (fig. 3, “Reply: ‘R’”); the reply grants authorization for a particular requesting device).
Claims 9-12 and 16-19 are computing device and computer readable medium claims that correspond to claims 1 and 3-5. Therefore, claims 9-12 and 16-19 are rejected over Smith ‘188 in view of Kommalapati ‘006, Quinn ‘710, and Rajakarunanayake ‘209 for the same reasons as claims 1 and 3-5.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Smith ‘188 in view of Kommalapati ‘006, Quinn ‘710, and Rajakarunanayake ‘209, and further in view of Schmidt US 20200021586 (hereinafter Schmidt ‘586).
As claim 2, Smith ‘188 in view of Kommalapati ‘006, Quinn ‘710, and Rajakarunanayake ‘209 disclose the method of claim 1 (supra). Smith ‘188 does not disclose, but Schmidt ‘586 discloses wherein the communications channel comprises a publish/subscribe message bus, and further comprising subscribing, by the first computing device, to the publish/subscribe message bus (para. 0003, “Typical application layer communication protocols for such resource-constrained IoT devices follow simple message-centric paradigms, such as the publish (pub)/subscribe (sub) method for example. An example of a publish/subscribe protocol is the Message Queue Telemetry Transport (MQTT) protocol specified by OASIS. An example of MQTT Publish/Subscribe is depicted in FIG. 2. MQTT is a slim pub/sub messaging protocol that runs over TCP/IP. It can thus be used directly for IoT devices attached to an IP network, such as for wireless connections over 6LoWPAN.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the communications channel of Smith ‘188 to comprise a publish/subscribe protocol as taught by Schmidt ‘586. One would have been motivated to do so to enable an established, lightweight communication protocol suitable for low-bandwidth applications as is known to one of ordinary skill in the art. Such a modification would have been a simple substitution of the communication protocol to obtain predictable results.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Smith ‘188 in view of Kommalapati ‘006, Quinn ‘710, and Rajakarunanayake ‘209, and further in view of Novo Diaz US 20210219117 (hereinafter Novo Diaz ‘117) and Smith et al. US 20190349426 (Smith ‘426).
As claim 7, Smith ‘188 in view of Kommalapati ‘006, Quinn ‘710, and Rajakarunanayake ‘209 disclose the method of claim 1 (supra). Smith ‘188 does not disclose, but Novo Diaz ‘117 discloses the method further comprising: receiving, by the first computing device, a plurality of messages, the plurality of messages identifying, for at least some of the other computing devices of the plurality of computing devices, resources controlled by the other computing devices (para. 0051, “Operations illustrated in FIG. 5 may be performed by a suitably configured IoT device 20 that provides IoT resources to the network and/or by a separate server device 300 that is distinct from the IoT device that provides the IoT resources. Referring to FIG. 5, the operations include providing a Thing Description file for an IoT device (block 502). As described in more detail below, the Thing Description file is a formatted record that describes a resource provided by the IoT device. Next, systems/methods parse the TD file to obtain its constituent parts (block 504), and then map the TD file to a Resource Directory registration command (block 506). Some examples of parsing the TD file and mapping the TD file to a Resource Directory registration command are provided below. Finally, the systems/methods transmit the Resource Directory registration command to a Resource Directory 20 to register the resource or resources in the Resource Directory 20 (block 508).”); and
generating, by the first computing device, a data structure that identifies the resources controlled by the other computing devices, and for each resource, the corresponding computing device that controls access to the resource (para. 0039, “The IETF has defined an entity called “Resource Directory” that may be present in an IoT environment. A Resource Directory can be used to assist in the process of resource discovery in an IoT environment.”; para. 0056, “A registration operation accepts a POST command from an endpoint, or node, containing a list of resources to be added to the Resource Directory as the message payload. As used herein, a “registration operation” may include a new registration operation in which a new registration is created in the Resource Directory or an update registration operation in which an existing registration in the Resource Directory is updated. A “registration command” includes a command to create a new registration in a Resource Directory or to update an existing registration in a Resource Directory”; para. 0058, “The command string includes a Resource Directory registration URI, which is a URI of the Resource Directory that is being updated (“coap://rd.example.com/rd”) followed by a command parameter string (“?ep=node1”). The command parameter string includes one or more variables or parameters, including a mandatory endpoint (“ep=”) parameter that identifies the node whose Resource Directory entry is being modified. Various optional command parameters may be provided in the command parameter string, including a context (“con=”) parameter that refers to a scheme, address, port and base path of the owner of the resources (“con=” is used if the resources are registering by a third-party node), an endpoint type (“et=”) parameter that defines the semantic type of the node, a domain (“d=”) parameter that identifies the domain to which the node belongs”; para. 0059, “The payload of the registration command provides information needed to create or update the Resource Directory entry for the device identified in the endpoint (ep) parameter. In this example, a resource of type “temperature-c” is associated with a URI target of “/sensors/temp” which is enclosed in braces “< >” at the start of the entry. The payload includes a content type attribute (“ct=41”) that is a numerical content type indicator, a resource type attribute (“rt=′temperature-c”) that indicates the type of resource that is provided by the target, an anchor attribute (“anchor=‘coap://spurious.example.com:5683’”) that provides a URI associated with the target, and an interface type attribute (“if=‘sensor’”) that provides a name or URI indicating a specific interface definition used to interact with the target resource.”). 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 method of Smith ‘188 by establishing a resource directory for the IoT environment. One would have been motivated to do so to enable an IoT device on the network to efficiently discover resources available to the IoT device within the IoT environment.
Smith ‘188 in view of Novo Diaz ‘117 does not explicitly disclose, but Smith ‘426 discloses by the first computing device (para. 841, “A shared domain creator 11310 may work to assist the onboarding tool in working with onboarding tools from the other domains to create a shared domain. The shared domain may include a shared resource directory 11312 that is accessible to all of the onboarding tools across the different domains, or is mirrored in each of the IoT devices hosting onboarding tools.” [emphasis added]; see also, figs. 110 and 113). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to establish a shared resource directory on the first computing device as taught by Smith ‘426. One would have been motivated to do so to enable an IoT device within a domain to store a local copy of a shared resource directory and thereby establish an efficient means of managing IoT devices within each domain.
Claim 14 is a computing device claim that correspond to claim 7. Therefore, claim 14 is rejected over Smith ‘188 in view of Kommalapati ‘006, Quinn ‘710, and Rajakarunanayake ‘209, and further in view of Novo Diaz ‘117 and Smith ‘426 for the same reasons as claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Meyer et al. US 11470685 discloses a method of improving communication efficiency among IoT devices by assigning a managing IoT device among a set of similar IoT devices, wherein the managing IoT device includes a table of the controlled IoT devices.
Kim et al. US 20210329074 discloses a method of providing IoT resource information using a system of IoT resource name system including a root RNS and local RNS.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNG W KIM whose telephone number is (571)272-3804. The examiner can normally be reached Monday-Friday, 10 a.m. - 6 p.m..
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, Amy Cohen Johnson can be reached at 571-272-2238 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.
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494
Prosecution Insights