Prosecution Insights
Last updated: October 02, 2026
Application No. 18/700,651

APPARATUSES, METHODS, AND SYSTEMS FOR DYNAMIC CONTROL LOOP CONSTRUCTION

Non-Final OA §103
Filed
Apr 11, 2024
Priority
Oct 11, 2021 — provisional 63/254,286 +1 more
Examiner
BARKER, TODD L
Art Unit
2449
Tech Center
2400 — Computer Networks
Assignee
Lenovo (United States) Inc.
OA Round
3 (Non-Final)
76%
Grant Probability
Favorable
3-4
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 76% — above average
76%
Career Allowance Rate
293 granted / 387 resolved
+17.7% vs TC avg
Strong +23% interview lift
Without
With
+23.1%
Interview Lift
resolved cases with interview
Typical timeline
2y 4m
Avg Prosecution
41 currently pending
Career history
441
Total Applications
across all art units

Statute-Specific Performance

§101
2.7%
-37.3% vs TC avg
§103
54.4%
+14.4% vs TC avg
§102
10.7%
-29.3% vs TC avg
§112
23.1%
-16.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 387 resolved cases

Office Action

§103
Detailed Action The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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 6/18/2026 has been entered. The Office Action is in response to claims filed on 11/25/2025 where claims 1, 3-5, 7-8, 15, 18-20, 23-25 are pending and ready for examination. 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. Applicant's arguments filed 5/18/2026 have been fully considered but they are not persuasive. The Examiner respectfully reminds the Applicant Guedalia provides a distributed bus for messaging with event triggering ([0086]). Goel teaches the generation of goals ([0076]). 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, 15, 18, 20, 23, and 25 are rejected under 35 USC 103 as being unpatentable over Guedalia (US2014/0244834) in view of Goel (US 2014/0244568) and in further view of Smith (US 2019/0349426) Regarding claim 1, Guedalia discloses an apparatus for performing a network function, the apparatus comprising: at least one memory (Guedalia; see e.g. [0055]” ... a memory ... The memory 212 can include one or more of read-only memory (ROM), random-access memory (RAM), electrically erasable programmable ROM (EEPROM), flash cards, or any memory common to computer platforms ...”); and at least one processor coupled with the at least one memory (Guedalia; see e.g. [0055]” ... the processor 208 can execute application programming instructions within a memory 212 of the IoT device. The memory 212 can include one or more of read-only memory (ROM), random-access memory (RAM), electrically erasable programmable ROM (EEPROM), flash cards, or any memory common to computer platforms ...”) and configured to cause the apparatus to: receive, from a consumer device, a request to create a closed loop (CL) functionality between a plurality of interconnected network entities (Guedalia; Guedalia teaches that each IoT device may treat the supervisor device as a peer and transmit attribute/schema updates to the supervisor device (see e.g. [0047]. See e.g. [0077]) The transmitted schema update from the IoT device to the supervisor device may be considered to be by one of ordinary skill in the art a request describing an interaction between IoT devices corresponding to the claimed request to create a closed loop functionality. [0047] “Each IoT device 110-118 can treat the supervisor device 130 as a peer and transmit attribute/schema updates to the supervisor device 130 ...”), wherein the request comprises a description of a desired behavior of the CL or components of the CL (Guedalia; Guedalia teaches that schemas associated with IoT devices describe service capabilities, communication methods, input/outputs, and state information (see e.g. [0086] [0086] “More particularly, according to various aspects of the disclosure, the method 800 shown in FIG. 8 may initially include detecting and registering various devices and/or other physical objects into the IoT network at block 810, wherein a supervisor device associated with the IoT network may detect and register one or more IoT devices, one or more non-IoT devices, and/or other suitable physical objects that are coupled to otherwise used in the controlled IoT network at block 810. In one embodiment, the IoT devices detected and registered into the IoT network at block 810 may include any suitable electronic device having certain attributes and state information that can be embedded in, observed with, monitored with, controlled with, or otherwise managed with the supervisor device and connected to the IoT network (e.g., an appliance, sensor, refrigerator, toaster, oven, microwave, freezer, dishwasher, washer, dryer, furnace, air conditioner, thermostat, television, light fixture, vacuum cleaner, electricity meter, gas meter, cell phone, desktop computer, laptop computer, tablet computer, etc.). In one embodiment, the attributes associated with the IoT devices may be expressed using a universal vocabulary that provides a generic, adaptive, and extensible schema that can define any suitable facet that relates to interaction and usage associated with the IoT devices (e.g., schema values can evolve or otherwise adapt based on learning from environmental surroundings and discovery and interaction among IoT devices and new schema elements may be added to extend an existing IoT device vocabulary). For example, in one embodiment, the universal vocabulary may express attributes associated with a particular IoT device according to schema elements that may include, among other things, a globally unique identifier, make, model, type, and version attributes, supported inputs (e.g., voltage, amperage, gallons, BTUs, etc.), supported outputs (e.g., watts, temperature, area-units, volume-units, speed, etc.), supported capabilities (e.g., start, stop, shutdown, hibernate, standby, reset, introduce, etc.), and supported communication methods (e.g., Bluetooth, Wi-Fi, Infrared, Near-Field Communication, Shortwave Radio, etc.). Furthermore, the state information associated with the IoT device may indicate whether the IoT device is on or off, open or closed, idle or active, available for task execution or busy, or any other suitable information that may relate to the status associated with the IoT device”). Because the request in [0047] is the transmitted schema, and the schema contains the descriptive information of the device behavior and capabilities, the request comprises a description of the desired behavior and components of the closed loop interaction.); generate at least one management service associated with the request for the CL functionality (Guedalia discloses that the IoT supervisor monitors and manages attributes, activities, and states associated with loT devices and manages interactions among these devices (see e.g. [0040],[0088] These supervisor y operations constitute a management service that manages the coordinated functionality between IoT devices in response to the request); generate a CL identifier for the CL based on successfully generating the at least one management service for the CL (Guedalia; Guedalia teaches that applications connected to bus nodes determine routing groups for endpoints and may use a unique routing group name (see e.g. [0084]) The routing group name functions as an identifier associated with the coordinated interaction between the participating IoT entities, corresponding to the CL identifier. [0084]” At message sequence step 766, the bus node 712 and the bus node 732 may communicate (e.g., broadcast) signals to inform other bus nodes of changes to endpoint bus topologies. Thereafter, traffic from local endpoint 714 may move through virtual endpoints to reach intended local endpoint 734 on Device B 730. Further, in operation, communications between local endpoint 714 and local endpoint 734 may use routing groups. In one aspect, routing groups may enable endpoints to receive signals, method calls, or other suitable information from a subset of endpoints. As such, a routing name may be determined by an application connected to a bus node 712 or 732) ...” transmit the CL identifier to the consumer device or a failure message indicating unsuccessfully generating the at least one management service for the CL (Guedalia; Guedalia teaches that bus nodes may send signals to notify other nodes of routing group changes including when members are added or removed from the routing group (see e.g. [0084] These signals communicate the routing group identifier associated with the coordinated interaction to participating devices, corresponding to transmitting the CL identifier); and identify, from a previously generated list of management services, a shortlist of management services from & previously generated list (Guedalia teaches that the IoT supervisor manages device attributes, activities, and interactions among IoT devices (see e.g. [0040], [0088] Selecting and applying appropriate management operations based on the device schemas and requested interactions corresponds to identifying appropriate management services associated with the requested functionality [0040] “In one embodiment, the supervisor device 130 may generally observe, monitor, control, or otherwise manage the various other components in the wireless communications system 100B ... monitor or manage attributes, activities, or other states associated with the various IoT devices 110-120. The supervisor device 130 may be a standalone device or one of IoT devices 110-120, such as computer 120. The supervisor device 130 may be a physical device or a software application running on a physical device. The supervisor device 130 may include a user interface that can output information relating to the monitored attributes, activities, or other states associated with the IoT devices 110-120 and receive input information to control or otherwise manage the attributes, activities, or other states associated therewith. Accordingly, the supervisor device 130 may generally include various components and support various wired and wireless communication interfaces to observe, monitor, control, or otherwise manage the various components in the wireless communications system 100B.” [0088] “In one embodiment, at block 820, the supervisor device may then monitor interactions and usage associated with the devices and/or other objects that were detected and registered at block 810, wherein the monitored interactions and usage may then be used to create one or more groups, sub-networks, subsets, or other suitable sub-divisions within the IoT network at block 830. For example, in one embodiment, each device or object registered at block 810 may include a globally unique identifier and each IoT device may further include a local database that stores information relating to each encounter or other interaction with another device or object in the IoT network (e.g., the globally unique identifier that corresponds to the other device or object associated with the interaction, a time stamp or other temporal context relating to the interaction ...” ) generate a notification, an event, or both for triggering each stage of the CL (Guedalia; Guedalia teaches a distributed bus where devices can exchange notifications with respect to collaborating and teaches whether a device is available for task execution or busy. Although Guedalia does not expressly disclose each stage of the CL (e.g. service chaining), one of ordinary skill in the art would be readily available to take into account service chaining based upon the context of tasks with a plurality of types of IoT devices; see e.g. [0077] “ ... the distributed bus 625, which may comprise a software bus used to enable application-to-application communications in a networked computing environment where applications register with the distributed bus 625 to offer services to other applications and other applications query the distributed bus 625 for information about registered applications. Such a protocol may provide asynchronous notifications and remote procedure calls (RPCs) in which signal messages (e.g., notifications) may be point-to-point or broadcast, method call messages (e.g., RPCs) may be synchronous or asynchronous, and the distributed bus 625 (e.g., a "daemon" bus process) may handle message routing between the various devices 610, 630, 640.” see e.g. [0086] “... supported communication methods (e.g., Bluetooth, Wi-Fi, Infrared, Near-Field Communication, Shortwave Radio, etc.). Furthermore, the state information associated with the IoT device may indicate whether the IoT device is on or off, open or closed, idle or active, available for task execution or busy, or any other suitable information that may relate to the status associated with the IoT device” ); Guedalia does not expressly disclose: generate a goal for the CL functionality based on the request and the shortlisted management services. Goel discloses: generate a goal for the CL functionality based on the request (Goel; Goel teaches devices may work in tandem together (i.e. collaborate) for the purpose of completing a goal; see e.g. [0076] “... In another example, a local neighborhood may include a closed sprinkler controller IoT device group that can share weather information and coordinate operational times (e.g., the group owner or another suitable ranking member in the sprinkler controller IoT device group may subscribe to weather forecasts and inform all other members in the group about upcoming weather forecasts to coordinate when and/or how long the sprinklers should enter an operational state). In still another example, a bathtub IoT device may notify an ad-hoc hot water group that water will be required for a certain time period (e.g., the next 15 minutes or until the bathtub has filled), or the bathtub may appropriately join the ad-hoc hot water group for the time period during which hot water will be required” The examiner notes Goel supports the rationale with respect to Guedalia on the following features: request (see e.g. [0052] In one embodiment, in response to having suitably formed the various IoT device groups 160 (e.g., based on various resources 180 shared therein, monitored interactions among the IoT devices 110-120, etc.), the IoT devices 110-120 within the various IoT device groups 160 may communicate with one another in a collaborative manner to make decisions about planned state transitions. In particular, as noted above, the various IoT devices 110-120 in each IoT device group 160 may be interdependent, whereby a decision that one IoT device 110-120 plans may impact other IoT devices 110-120 in the IoT device group 160. Accordingly, in response to an IoT device 110-120 planning a certain decision (e.g., to transition state or initiate another action), the IoT devices 110-120 in the IoT device group 160 may collaborate using distributed intelligence prior to taking action on the planned decision. For example, a recommendation request message may be sent to other IoT devices 110-120 in the IoT device group 160”) a failure message indicating unsuccessfully generating the at least one management service for the CL (Goel; Goel teaches a message be transmitted indicated that there will be no transition to a collaborative task between IoT devices; see e.g. [0011] “ ... the advertised final decision may indicate that the planned state transition will not be initiated”) see e.g. [0049] “... collaborative intelligence and decision-making within and/or among the IoT device groups 160 (e.g., to control usage associated with various resources 180 that may be shared among the IoT devices 110-120 and/or passive IoT devices 105 in the IoT device groups 169) ...” see e.g. [0052] ) Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Goel’s schemes. The motivation being the combined solution provide for implanting a known technique resulting in increased efficiencies in provisioning IoT devices for collaborative tasks. Guedalia in view of Goel discloses: generate a goal for the CL functionality based on the request and the shortlisted management services (The combined solution provides for generating goals per Goel based on the requests and shortlisted management services) As evidence of the rationale above Smith discloses: Goals (Smith; Smith teaches within the context of IoT devices and service chaining goals; [0325] FIG. 5 is a schematic drawing 500 showing the formation of a composite object 502 from a number of atomic objects 504, 506, and 508 in accordance with some embodiments. An object includes a data model representation of functionality, state and interface semantics that make up a node of a distributed system. As used herein, an object, or IoT object, may be a physical device made up of IoT devices, a virtual device formed from a group of physical or virtual devices, or any number of other configurations; see e.g. Fig. 5 [0326] Objects may interact to accomplish a larger function, goal or workflow. Objects may be identified in terms of their type, e.g., the function performed, and instance, e.g., presence. Multiple object instances may have the same type identity, but may have unique instance identities. Further, multiple object instances may be organized into groups where an instance of the grouping may have an identity. A group of objects that interact in a particular way, given their type, for example, function, state and interface semantics, may represent a composite object. The composition itself may have a type and instance abstraction. Hence, composite objects follow the same identity rules as atomic objects. Composition with type and instance properties allows object extensibility through composition. See e.g. [0711] “... The technique allows the creation of service chains across heterogeneous networks, which may allow for the automatic provisioning and reconfiguration of IoT devices in a fog or mesh network. For example, IoT devices may be functionally clustered to form a service ...”) Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Smith’s goal scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of collaboration among devices. Regarding claim 15, Guedalia discloses a user equipment (UE), comprising: at least one memory (Guedalia ;see e.g. [0055]” ... a memory ... The memory 212 can include one or more of read-only memory (ROM), random-access memory (RAM), electrically erasable programmable ROM (EEPROM), flash cards, or any memory common to computer platforms ...”); and at least one processor coupled with the at least one memory and configured to cause the UE to (Guedalia; see e.g. [0055]” ... the processor 208 can execute application programming instructions within a memory 212 of the IoT device. The memory 212 can include one or more of read-only memory (ROM), random-access memory (RAM), electrically erasable programmable ROM (EEPROM), flash cards, or any memory common to computer platforms ...” see e.g. [0030] “... cell phone ...”): generate a request to create a closed loop (CL) functionality between a plurality of interconnected network entities (Guedalia; Guedalia teaches that each IoT device may treat the supervisor device as a peer and gemerate attribute/schema updates to the supervisor device (see e.g. [0047]. See e.g. [0077]) The schema update from the IoT device may be considered to be by one of ordinary skill in the art a request describing an interaction between IoT devices corresponding to the claimed request to create a closed loop functionality.), wherein the request comprises a description of a desired behavior of the CL or components of the CL CL (Guedalia; Guedalia teaches that schemas associated with IoT devices describe service capabilities, communication methods, input/outputs, and state information (see e.g. [0086]). Because the request in [0047] is the transmitted schema, and the schema contains the descriptive information of the device behavior and capabilities, the request comprises a description of the desired behavior and components of the closed loop interaction.), and wherein the description of components in the CL comprises properties of messages, requirement for the messages, or messages to be sent between stages of the CL (Guedalia; Guedalia teaches the schemas provides one of ordinary skill in the art a description of what essages can be sent to the stages of the CL (e.g. status and/or task availability see e.g. [0086]); transmit the request to a network function (NF) entity (Guedalia, Gudalia teaches the rewqust is sent to the IoT s(Guedalia; Guedalia teaches a distributed bus where devices can exchange notifications with respect to collaborating and teaches whether a device is available for task execution or busy. Although Guedalia does not expressly disclose each stage of the CL (e.g. service chaining), one of ordinary skill in the art would be readily available to take into account service chaining based upon the context of tasks with a plurality of types of IoT devices; see e.g. [0077] “ ... the distributed bus 625, which may comprise a software bus used to enable application-to-application communications in a networked computing environment where applications register with the distributed bus 625 to offer services to other applications and other applications query the distributed bus 625 for information about registered applications. Such a protocol may provide asynchronous notifications and remote procedure calls (RPCs) in which signal messages (e.g., notifications) may be point-to-point or broadcast, method call messages (e.g., RPCs) may be synchronous or asynchronous, and the distributed bus 625 (e.g., a "daemon" bus process) may handle message routing between the various devices 610, 630, 640.” see e.g. [0086] “... supported communication methods (e.g., Bluetooth, Wi-Fi, Infrared, Near-Field Communication, Shortwave Radio, etc.). Furthermore, the state information associated with the IoT device may indicate whether the IoT device is on or off, open or closed, idle or active, available for task execution or busy, or any other suitable information that may relate to the status associated with the IoT device” ); upervisor (i.e. Network Function Entity; see e.g.[0047] ) ; notification, an event, or both for triggering each stage of the CL Guedalia suggests but does not expressly disclose: receive an identifier associated with a completed CL from the NF entity or an indication that generation of the CL failed. the request further specifies a goal for the CL functionality However in analogous art Goel discloses: receive an identifier associated with a completed CL from the NF entity or an indication that generation of the CL failed (Goel; Goel teaches a message is received indicating that the generation of the CL is not approved and/or will not occur (i.e. failed) see e.g. [0011] “ ... the advertised final decision may indicate that the planned state transition will not be initiated”) see e.g. [0049] “... collaborative intelligence and decision-making within and/or among the IoT device groups 160 (e.g., to control usage associated with various resources 180 that may be shared among the IoT devices 110-120 and/or passive IoT devices 105 in the IoT device groups 169) ...” the request further specifies a goal for the CL functionality(Goel; Goel teaches devices may work in tandem together (i.e. collaborate) for the purpose of completing a goal; see e.g. [0076] “... In another example, a local neighborhood may include a closed sprinkler controller IoT device group that can share weather information and coordinate operational times (e.g., the group owner or another suitable ranking member in the sprinkler controller IoT device group may subscribe to weather forecasts and inform all other members in the group about upcoming weather forecasts to coordinate when and/or how long the sprinklers should enter an operational state). In still another example, a bathtub IoT device may notify an ad-hoc hot water group that water will be required for a certain time period (e.g., the next 15 minutes or until the bathtub has filled), or the bathtub may appropriately join the ad-hoc hot water group for the time period during which hot water will be required” Goel also discloses: request (see e.g. [0052] In one embodiment, in response to having suitably formed the various IoT device groups 160 (e.g., based on various resources 180 shared therein, monitored interactions among the IoT devices 110-120, etc.), the IoT devices 110-120 within the various IoT device groups 160 may communicate with one another in a collaborative manner to make decisions about planned state transitions. In particular, as noted above, the various IoT devices 110-120 in each IoT device group 160 may be interdependent, whereby a decision that one IoT device 110-120 plans may impact other IoT devices 110-120 in the IoT device group 160. Accordingly, in response to an IoT device 110-120 planning a certain decision (e.g., to transition state or initiate another action), the IoT devices 110-120 in the IoT device group 160 may collaborate using distributed intelligence prior to taking action on the planned decision. For example, a recommendation request message may be sent to other IoT devices 110-120 in the IoT device group 160”) Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Goel’s schemes. The motivation being the combined solution provide for increased efficiencies in provisioning IoT devices for collaborative tasks. As evidence of the rationale above Smith discloses: Goals (Smith; Smith teaches within the context of IoT devices and service chaining goals; [0325] FIG. 5 is a schematic drawing 500 showing the formation of a composite object 502 from a number of atomic objects 504, 506, and 508 in accordance with some embodiments. An object includes a data model representation of functionality, state and interface semantics that make up a node of a distributed system. As used herein, an object, or IoT object, may be a physical device made up of IoT devices, a virtual device formed from a group of physical or virtual devices, or any number of other configurations; see e.g. Fig. 5 [0326] Objects may interact to accomplish a larger function, goal or workflow. Objects may be identified in terms of their type, e.g., the function performed, and instance, e.g., presence. Multiple object instances may have the same type identity, but may have unique instance identities. Further, multiple object instances may be organized into groups where an instance of the grouping may have an identity. A group of objects that interact in a particular way, given their type, for example, function, state and interface semantics, may represent a composite object. The composition itself may have a type and instance abstraction. Hence, composite objects follow the same identity rules as atomic objects. Composition with type and instance properties allows object extensibility through composition. See e.g. [0711] “... The technique allows the creation of service chains across heterogeneous networks, which may allow for the automatic provisioning and reconfiguration of IoT devices in a fog or mesh network. For example, IoT devices may be functionally clustered to form a service ...”) Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Smith’s goal scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of collaboration among devices. Regarding claim 18, Guedalia in view of Goel and in further view of Smith disclose The UE of claim 15, wherein the description of components in the CL comprises conditions for the messages to be sent between the components or the stages (Guedalia; Guedalia provides communication mode requirements for sending messages; See e.g. [0086] ”... supported communication methods (e.g., Bluetooth, Wi-Fi, Infrared, Near-Field Communication, Shortwave Radio, etc.) ...” Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Goel’s schemes. The motivation being the combined solution provide for increased efficiencies in provisioning IoT devices for collaborative tasks. Regarding claim 20, claim 20 comprises the same and/or similar subject matter as claim 15 and is considered an obvious variation; therefore it is rejected under the same rationale. Regarding claim 23, claim 23 comprises the same and/or similar subject matter as claim 18 and is considered an obvious variation; therefore it is rejected under the same rationale. Regarding claim 25, claim 25 comprises the same and/or similar subject matter as claim 15 and is considered an obvious variation; therefore it is rejected under the same rationale. Claims 3 – 4 and 7 are rejected under 35 USC 103 as being unpatentable over Guedalia in view of Goel and in further view of Smith and in further view of Wang (US 2018/0007172) Regarding claim 3, Guedalia in view of Goel and in further view of Smith discloses the apparatus of claim 1, Guedalia does not expressly disclose wherein the description of components in the CL comprises properties of messages, requirement for the messages, or messages to be sent between stages of the CL. However in analogous art Wang discloses: wherein the description of components in the CL comprises properties of messages, requirement for the messages, or messages to be sent between stages of the CL (Wang; see e.g. [0036] Similarly, an IoT entity may prefer to use different messaging protocols as they are fitting for different resource requirements. For example, an IoT gateway may have three resources: general sensor readings, video streaming, and Pub/Sub data. Such resources have different requirements for messaging protocols to access them efficiently. For example, CoAP may be better for accessing the general sensor readings, HTTP may be better for video streaming, and MQTT may be better for Pub/Sub data) Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wang’s message types/protocols. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of provisioning IoT collaborative services. Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Goel’s schemes. The motivation being the combined solution provide for increased efficiencies in provisioning IoT devices for collaborative tasks. Regarding claim 4, Guedalia in view of Goel and in further view of Smith and in further view of Wang disclose the apparatus of claim 3, wherein the description of components in the CL comprises conditions for the messages to be sent between the components or the stages (Guedalia; Guedalia provides communication mode requirements for sending messages; See e..g. [0086] ”... supported communication methods (e.g., Bluetooth, Wi-Fi, Infrared, Near-Field Communication, Shortwave Radio, etc.) ...” Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wang’s message types/protocols. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of provisioning IoT collaborative services. Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Goel’s schemes. The motivation being the combined solution provide for increased efficiencies in provisioning IoT devices for collaborative tasks Regarding claim 7, Guedalia in view of Goel and in further view of Smith and in further view of Wang disclose the apparatus of claim 3, wherein the at least one processor is configured to cause the apparatus to generate notifications, events, or both for triggering each stage of the CL (Guedalia’s managing activities and interactions requires signaling or triggering device actions which corresponds to generates events or notifications that initiate the stages of the interaction; see e.g. [0040], [0088])). Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wang’s message types/protocols. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of provisioning IoT collaborative services. Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Goel’s schemes. The motivation being the combined solution provide for increased efficiencies in provisioning IoT devices for collaborative tasks Claims 5, 19, and 24 are rejected under 35 USC as being unpatentable over Guedalia in view of Goel and in further view of Smith and in further view of Volkerink (US 2022/0108143) Regarding claim 5, Guedalia in view of Goel and in further view of Smith disclose the apparatus of claim 1, Guedalia does not expressly disclose wherein the request includes timeouts, time periods, or both for the messages to be sent between the stages of the CL. However in analogous art Volkerink discloses: wherein the request includes timeouts, time periods, or both for the messages (Volkerink; see e.g. [0148] “A wireless node B in the vicinity of the wireless node A periodically transmits 1412 a request to receive a configuration file from a nearby wireless node of IoT system 400 for completing the configuration of wireless node B. The frequency with which the wireless node B transmits 1412 the request may correspond to a timeout period of the wireless node A's search 1410 ...”) Therefore it would have been prima facie obvious before the effective filing date of the claimed invention to incorporate Volkerink’s transmission scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies in provisioning IoT services. Guedalia in view of Goel and in further view of Smith and in further view of Volkerink discloses: wherein the request includes timeouts, time periods, or both for the messages to be sent between the stages of the CL (The combined solution provides for Guedalia’s IoT devices to utrlize Volkerink’s scheme) Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Goel’s schemes. The motivation being the combined solution provide for increased efficiencies in provisioning IoT devices for collaborative tasks Regarding claim 19, Guedalia in view of Goel and in further view of Smith discloses the UE of claim 15, Guedalia does not expressly disclose wherein the request includes timeouts, time periods, or both for the messages to be sent between the stages of the CL. However Volkerink discloses: wherein the request includes timeouts, time periods, or both for the messages messages (Volkerink; see e.g. [0148] “A wireless node B in the vicinity of the wireless node A periodically transmits 1412 a request to receive a configuration file from a nearby wireless node of IoT system 400 for completing the configuration of wireless node B. The frequency with which the wireless node B transmits 1412 the request may correspond to a timeout period of the wireless node A's search 1410 ...”) Therefore it would have been prima facie obvious before the effective filing date of the claimed invention to incorporate Volkerink’s transmission scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies in provisioning IoT services. Guedalia in view of Goel and in further view of Smith and in further view of Volkerink discloses: wherein the request includes timeouts, time periods, or both for the messages to be sent between the stages of the CL (The combined solution provides for Guedalia’s IoT devices to utrlize Volkerink’s scheme) Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Goel’s schemes. The motivation being the combined solution provide for increased efficiencies in provisioning IoT devices for collaborative tasks Regarding claim 24, claim 24 comprises the same and/or similar subject matter as claim 19 and is considered an obvious variation; therefore it is rejected under the same rationale. Any inquiry concerning this communication or earlier communications from the Examiner should be directed to TODD L. BARKER whose telephone number is (571) 270 0257. The Examiner can normally be reached on Monday through Friday, 7:30am to 5:00pm. If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's supervisor Vivek Srivastava can be reached on (571) 272 7304 /TODD L BARKER/Primary Examiner, Art Unit 2449
Read full office action

Prosecution Timeline

Show 1 earlier event
Aug 28, 2025
Non-Final Rejection mailed — §103
Oct 06, 2025
Interview Requested
Nov 25, 2025
Response Filed
Mar 18, 2026
Final Rejection mailed — §103
May 18, 2026
Response after Non-Final Action
Jun 18, 2026
Request for Continued Examination
Jun 23, 2026
Response after Non-Final Action
Jul 15, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12750270
METHOD AND APPARATUS FOR DETERMINING A FIRST CAUSAL MAP
2y 8m to grant Granted Sep 29, 2026
Patent 12732492
Placement of Hosts Based on Authentication Server Status
3y 4m to grant Granted Sep 08, 2026
Patent 12726375
Virtual Background Adjustment For Quality Retention During Reduced-Bandwidth Video Conferencing
4y 4m to grant Granted Sep 01, 2026
Patent 12724784
Distance Based Search Ranking Demotion
2y 8m to grant Granted Sep 01, 2026
Patent 12706811
SYSTEM AND METHOD FOR IMPLEMENTING RAN TELEMETRY FRAMEWORK IN A MOBILE NETWORK
2y 8m to grant Granted Aug 11, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
76%
Grant Probability
99%
With Interview (+23.1%)
2y 4m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 387 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month