Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
1. This action is responsive to applicant’s amendment dated 3/30/2026.
2. Claims 1, 2, 6-9, 11, 21, 23, 25-30 and 32-35 are pending in the case.
3. Claims 3-5, 10, 12-20, 22, 24 and 31 are cancelled.
4. Claims 1, 26 and 32 are independent 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 7, 21, 26, 28, 30, 32 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Wee et al. (hereinafter “Wee”), U.S. Published Application No. 20160357522 A1 which claims priority to provisional application No. 62172466 dated 6/8/2015, in view of Sedayao et al., U.S. Published Application No 20160379464 A1 in view of Siebel et al. (hereinafter “Siebel”), U.S. Published Application No. 20180191867 A1 which claims priority to provisional application No. 62172012 dated 6/5/2015.
Claim 1:
Wee teaches a method comprising:
receiving first information comprising configuration information for a first device of a plurality of devices; (e.g., receiving information (e.g., programming IOT items representing devices, validating configurations involving IOT items representing devices, logically connecting sensor with actuators via integrated developer environment ) from a developer in an integrated development environment as a result of configuring a first plurality of IoT devices (e.g., plurality of sensors or actuators) within integrated developer environment par. 27; Loosely, the term "Internet of Things" (IoT) or "Internet of Everything" (IoE) refers to uniquely identifiable objects (things) and their virtual representations in a network-based architecture. The "Internet of Things" thus generally refers to the interconnection of objects (e.g., smart objects), such as sensors and actuators, over a computer network (e.g., via IP), which may be the public Internet or a private network. Par. 50; the IoT IDE provides visual developer tools 350 in the IDE for developers to easily program. Examples of such visual developer tools include dragging icons, connecting items logically, programming the items, validating the configurations, and running (executing) the system to obtain a result (virtualization, simulation, etc.).)
wherein the first information is from an entity associated the first device; (e.g., configuration information from a developer or vendor associated with the IOT device (e.g., sensors or actuators) par. 30; The developer may have a number of physical sensors and may want to emulate a larger number of virtual sensors to use in their application. par. 42; Then based on the format specification, thing vendors could provide their virtualized products such that the things could be emulated in the developer environment. For instance, if a particular format “X” is used to describe the virtualized thing, then the developer environment herein can import the “X” file to simulate the thing under the corresponding runtime. Then the thing vendor could use format “X” to design their products and provide customers virtualized samples. Notably, with the emulated platforms, developers can simulate the business logics in individual platforms, and also the data-flow protocol compliance between platforms. Par. 45; The framework provides the service that allows developers to register their developed nodes as well as providing the nodes' metadata such as node name, node developer name, node description, the number of node input/output ports and their used protocols.)
receiving second information comprising configuration information for a second device of the plurality of devices; (e.g., receiving second information (e.g., programming IOT items representing devices, validating configurations involving IOT items representing devices, logically connecting sensor with actuators via integrated developer environment ) from a developer in an integrated development environment as a result of configuring a second plurality of IoT devices (e.g., plurality of sensors or actuators) within integrated developer environment par. 27; Loosely, the term "Internet of Things" (IoT) or "Internet of Everything" (IoE) refers to uniquely identifiable objects (things) and their virtual representations in a network-based architecture. The "Internet of Things" thus generally refers to the interconnection of objects (e.g., smart objects), such as sensors and actuators, over a computer network (e.g., via IP), which may be the public Internet or a private network. Par. 50; the IoT IDE provides visual developer tools 350 in the IDE for developers to easily program. Examples of such visual developer tools include dragging icons, connecting items logically, programming the items, validating the configurations, and running (executing) the system to obtain a result (virtualization, simulation, etc.).)
wherein the second information is from an entity associated with the second device; (e.g., configuration information from a developer or vendor associated with the IOT device (e.g., sensors or actuators) par. 30; The developer may have a number of physical sensors and may want to emulate a larger number of virtual sensors to use in their application. par. 42; Then based on the format specification, thing vendors could provide their virtualized products such that the things could be emulated in the developer environment. For instance, if a particular format “X” is used to describe the virtualized thing, then the developer environment herein can import the “X” file to simulate the thing under the corresponding runtime. Then the thing vendor could use format “X” to design their products and provide customers virtualized samples. Notably, with the emulated platforms, developers can simulate the business logics in individual platforms, and also the data-flow protocol compliance between platforms. Par. 45; The framework provides the service that allows developers to register their developed nodes as well as providing the nodes' metadata such as node name, node developer name, node description, the number of node input/output ports and their used protocols.)
verifying, based on the first information and the second information, compatibility of the first device interacting with the second device; (e.g., validating a configuration with a policy comprising two elements representing sensors Figures 7, 9, 10,12 and 15; selectable real thing IOT devices to be used to establish a policy; par. 50; Examples of such visual developer tools include dragging icons, connecting items logically, programming the items, validating the configurations, and running (executing) the system to obtain a result (virtualization, simulation, etc.).)
receiving, a gestural input indicating a request to configure an action to be performed, by the first device, based at least on the second device satisfying a condition; (e.g., based on a touch screen interface, receiving touch and/or dragging inputs (i.e., gestural input to request to configure) to establish a written policy prior to validation of the policy such as if sensor (i.e., second device) reaches a particular temperature, then cause a device(e.g., actuators or lights) to turn on/off (i.e., action to be performed) In the context of testing simulations, Examiner submits that the written policy may include if/then logic such as if a thermostat sensor device satisfying a temperature condition, cause an actuator or device to perform virtualized actions such being turn on or off. Examiner notes that the recited “request to configure” reads on the configurations made prior to be validated (i.e., a request to configure a validated policy) as taught by Wee; Figures 7, 9, 10,12 and 15; selectable real thing IOT devices to be used to establish a policy; Figure 9; Thermostat and air conditioning as a logical grouping 910 Figure 12; policy dialog window 1220 allows a policy message to be established which is associated with a request to configure an action with an actuator device Figure 15;wrting policy for sensors to satisfy conditions and cameras to perform actions par. 26; Smart object networks, such as sensor networks, in particular, are a specific type of network having spatially distributed autonomous devices such as sensors, actuators, etc., that cooperatively monitor physical or environmental conditions at different locations, such as, e.g., energy/power consumption, resource consumption (e.g., water/gas/etc. for advanced metering infrastructure or "AMI" applications) temperature, pressure, vibration, sound, radiation, motion, pollutants, etc. Other types of smart objects include actuators, e.g., responsible for turning on/off an engine or perform any other actions. par. 51; FIG. 6 illustrates an example functional diagram of the IoT IDE 600 described herein. In particular, the IDE allows developers to capture (610) inputs from any number of physical nodes/things (612) and/or virtual nodes/things (614) (e.g., objects, sensors, data producers, etc.), and processes the inputs (620) (e.g., transformations based on one or more rules engines) to result in one or more corresponding actions (630). Example actions include outputs to physical things (632) and/or virtual things (634) (e.g., objects, actuators, indicators, etc.) par. 60; As shown in the view 1200 of the GUI in FIG. 12, the IoT IDE also allows developers to easily provide functionality, write policies, and compile the nodes. Par. 65; virtualized acts (e.g., lights turning on/off, actuators moving/activating, etc.) may also be presented within the IoT IDE. Par. 82; In particular, in FIG. 15, an example logical view 1510 of a number of cameras 1520, temperature sensors 1530, and wireless access points 1540 may be logically connected through a fog controller 1550 to result in various notification (e.g., email 1560) or visualization (e.g., graphs/charts 1570), as desired.)
Wee teaches determining, based on the compatibility of the first device interacting with the second device, that the action indicated by the gestural input is valid; (e.g., based on dragging IOT related icons which may represent IOT devices to configure a created policy, validating the configurations of the created policy which includes if/then logic for implementing actions; Examiner notes that under Broadest Reasonable Interpretation (BRI), compatibility is considered a state in which two things are able to exist or occur together without problems or conflict. Examiner considers validating a policy between two elements and having no error messages as taught by WE to be equivalent to verifying the elements to be compatible par. 50; Examples of such visual developer tools include dragging icons, connecting items logically, programming the items, validating the configurations, and running (executing) the system to obtain a result (virtualization, simulation, etc.).)
Wee fails to expressly teach
causing, based on determining that the action is valid, output of a confirmation for a rule associated with the action.
However, Sedayao teaches
causing, based on determining that the action is valid, output of a confirmation for a rule associated with the action. (e.g., outputting a confirmation message indicating that no violations of the defined rules which includes actions par. 29; Once the distance between the individual IoT tags 110, 112, and 114 and between any of the IoT tags 110, 112, and 114 and the computing device 126 for alerting has been determined, the computing device 126 may confirm that there are no violations of the rules. This may be performed by a rule checker 130 module that uses the identity of the items, the distance between items, and the proximity rule list 120 to determine whether items are too close or too far apart. An alertor 132 module can then inform a user of the problem by triggering an alert.)
In the analogous art of configuring rules for objects, 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 validate the updated written policy for IOT devices and actions as taught by Wee to include a confirmation message from a rule checker as taught by Sedayao, with a reasonable expectation of success, to provide the benefit of quickly determining an error free policy of rules.
Wee/Sedayao fails to expressly teach manufacturer of a first or second device.
However, Siebel teaches a manufacturer being associated with a device.(e.g., share data relating to operations of an enterprise with one or more entities, such as a manufacturer of the device par. 550; A smart, connected device also may include communication components that allow the device to share data relating to operations of an enterprise with one or more entities, such as the enterprise Internet-of-Things application development platform 3002, a manufacturer of the device, other smart, connected devices, other entities, etc., par. 36 of 62172012)
In the analogous art of IOT device related configuration within a development platform, 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 IOT devices associated with vendors and developers as taught by Wee/Sedayao to include an association with manufacturers of the device as taught by Siebel, with a reasonable expectation of success, to provide the benefit of allowing the enterprise Internet-of-Things application development platform 3002 to perform, for example, rigorous predictive analytics, data exploration, machine learning, and complex data visualization requiring responsive design. (see Siebel; par. 540)
Claim 7 depends on claim 1:
Wee teaches wherein the gestural input comprises a swipe motion from a first graphical user interface element, associating with the first device to a second graphical user interface element, associated with the second device. (e.g., flicking an IoT element towards another IoT element on the canvas for automatic node connection par. 59; In one embodiment, particularly for touchscreen implementations, algorithms are defined for auto-placement and auto-connection of the logical "blocks" (nodes). That is, the developer may be able to just select a node, and "flick" it in the general direction of the intended location, and the IoT IDE can determine where to connect the node within the graph based on various rules, e.g., based on input/output ports, how close they are on the canvas)
Claim 21 depends on claim 1:
Wee teaches wherein each device of the plurality of devices comprises an Internet-of-Things (IoT) device. (Figure 7; menu tray 710 of IoT elements which includes sensors)
Independent Claim 26:
Claim 26 is substantially encompassed in claim 1, therefore, Examiner relies on the same rationale set forth in claim 1 to reject claim 26. (see Wee’s Figure 19; device 2200, processor(s) 2220, memory 2240 for storing program )
Claim 28 depends on claim 26:
Claim 28 is substantially encompassed in claim 7, therefore, Examiner relies on the rationale set forth in claim 7 to reject claim 28.
Claim 30 depends on claim 26:
Wee teaches wherein each device of the plurality of devices comprises an Internet-of-Things (IoT) device. (Figure 7; menu tray 710 of IoT elements which includes sensors)
Independent Claim 32:
Claim 32 is substantially encompassed in claim 1, therefore, Examiner relies on the rationale set forth in claim 1 to reject claim 32. (see Wee’s Figure 19; processor(s) 2220, memory 2240 for storing program )
Claim 35 depends on claim 1:
Wee teaches wherein the determining that the action is valid comprises: verifying compatibility of the first device interacting with the second device. (e.g., validating (i.e., verifying compatibility) of policy-related configurations which include one or more IOT devices Figure 12; policy-related configuration with more than one outputs which may be one or more IOT devices par. 15; Examples of such visual developer tools include dragging icons, connecting items logically, programming the items, validating the configurations, and running (executing) the system to obtain a result (virtualization, simulation, etc.). par. 51; FIG. 6 illustrates an example functional diagram of the IoT IDE 600 described herein. In particular, the IDE allows developers to capture (610) inputs from any number of physical nodes/things (612) and/or virtual nodes/things (614) (e.g., objects, sensors, data producers, etc.), and processes the inputs (620) (e.g., transformations based on one or more rules engines) to result in one or more corresponding actions (630). Example actions include outputs to physical things (632) and/or virtual things (634) (e.g., objects, actuators, indicators, etc.) par. 60; As shown in the view 1200 of the GUI in FIG. 12, the IoT IDE also allows developers to easily provide functionality, write policies, and compile the nodes.))
Claims 6, 25 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Wee/Sedayao/Siebel as cited above, and applied to claims 1 and 26, further in view of Sundaresan et al. (hereinafter “Sundaresan”), U.S. Published Application No. 20160112240 A1.
Claim 6 depends on claim 1:
Wee teaches wherein the condition is satisfied by at least one of the second device performing an operation, the second device being placed in a state or (e.g., receiving a policy change message from a developer to configure an action to be performed by a first IOT device based on the second IOT device satisfying a condition (e.g., developer manually establishes a policy condition for a first IOT actuator device to perform an action when a second IOT temperature sensor device reaches a particular degree (i.e., being placed in a state)) Examiner notes that example actions include outputs to physical things (632) and/or virtual things (634) (e.g., objects, actuators, indicators, etc) Figures 7, 10 and 12; selectable real thing IOT devices to be used to establish a policy; Figure 12; policy dialog window 1220 allows a policy message to be established which is associated with a request to configure an action with an actuator device par. 26; Smart object networks, such as sensor networks, in particular, are a specific type of network having spatially distributed autonomous devices such as sensors, actuators, etc., that cooperatively monitor physical or environmental conditions at different locations, such as, e.g., energy/power consumption, resource consumption (e.g., water/gas/etc. for advanced metering infrastructure or "AMI" applications) temperature, pressure, vibration, sound, radiation, motion, pollutants, etc. Other types of smart objects include actuators, e.g., responsible for turning on/off an engine or perform any other actions. par. 51; FIG. 6 illustrates an example functional diagram of the IoT IDE 600 described herein. In particular, the IDE allows developers to capture (610) inputs from any number of physical nodes/things (612) and/or virtual nodes/things (614) (e.g., objects, sensors, data producers, etc.), and processes the inputs (620) (e.g., transformations based on one or more rules engines) to result in one or more corresponding actions (630). Example actions include outputs to physical things (632) and/or virtual things (634) (e.g., objects, actuators, indicators, etc.) par. 60; As shown in the view 1200 of the GUI in FIG. 12, the IoT IDE also allows developers to easily provide functionality, write policies, and compile the nodes.)
Wee/Sedayao/Siebel fails to expressly teach the second device interacting with a social networking service.
However, Sundaresan teaches the second device interacting with a social networking service. (e.g., wherein the condition is satisfied, a device is triggered to interact with a social networking service (e.g., send emails). Par. 68; FIG. 5 is a flow chart for an example method 500 of triggering one or more actions on services and/or network-connected devices responsive to events on other services and/or network-connected devices. par. 72; At block 545, processing logic notifies a user of the user account of the rule satisfaction. The notification to the user may be an electronic mail (email) message sent to an email address of the user. The notification to the user may also be an SMS or MMS message sent to a phone number of the user. The notification may also be an automated phone call to a phone number of the user, a posting to a social network account of the user, or other type of notification)
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 actions within a policy related configuration rule as taught by Wee/Sedayao/Siebel to include an action such as interacting with a social network service as taught by Sundaresan to provide the benefit of expanding the tracking ways to notify a user of a rule satisfaction.
Claim 25 depends on claim 1:
Wee teaches wherein the action comprises the first device performing an operation, the first device being placed in a state, or . (e.g., receiving a policy change message from a developer to configure an action to be performed by a first IOT device based on the second IOT device satisfying a condition (e.g., developer manually establishes a policy condition for a first IOT actuator device to perform an action or operation when a second IOT temperature sensor device reaches a particular degree (i.e., being placed in a state)) Examiner notes that example actions include outputs to physical things (632) and/or virtual things (634) (e.g., objects, actuators, indicators, etc) Examiner also notes that the first device and second device are interchangeable. Figures 7, 10 and 12; selectable real thing IOT devices to be used to establish a policy; Figure 12; policy dialog window 1220 allows a policy message to be established which is associated with a request to configure an action with an actuator device par. 26; Smart object networks, such as sensor networks, in particular, are a specific type of network having spatially distributed autonomous devices such as sensors, actuators, etc., that cooperatively monitor physical or environmental conditions at different locations, such as, e.g., energy/power consumption, resource consumption (e.g., water/gas/etc. for advanced metering infrastructure or "AMI" applications) temperature, pressure, vibration, sound, radiation, motion, pollutants, etc. Other types of smart objects include actuators, e.g., responsible for turning on/off an engine or perform any other actions. par. 51; FIG. 6 illustrates an example functional diagram of the IoT IDE 600 described herein. In particular, the IDE allows developers to capture (610) inputs from any number of physical nodes/things (612) and/or virtual nodes/things (614) (e.g., objects, sensors, data producers, etc.), and processes the inputs (620) (e.g., transformations based on one or more rules engines) to result in one or more corresponding actions (630). Example actions include outputs to physical things (632) and/or virtual things (634) (e.g., objects, actuators, indicators, etc.) par. 60; As shown in the view 1200 of the GUI in FIG. 12, the IoT IDE also allows developers to easily provide functionality, write policies, and compile the nodes.)
Wee/Sedayao/Siebel fails to expressly teach the first device interacting with a social networking service.
However, Sundaresan teaches the first device interacting with a social networking service. (e.g., wherein the condition is satisfied, a device is triggered to interact with a social networking service (e.g., send emails). Par. 68; FIG. 5 is a flow chart for an example method 500 of triggering one or more actions on services and/or network-connected devices responsive to events on other services and/or network-connected devices. par. 72; At block 545, processing logic notifies a user of the user account of the rule satisfaction. The notification to the user may be an electronic mail (email) message sent to an email address of the user. The notification to the user may also be an SMS or MMS message sent to a phone number of the user. The notification may also be an automated phone call to a phone number of the user, a posting to a social network account of the user, or other type of notification)
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 actions within a policy related configuration rule as taught by Wee/Sedayao/Siebel to include an action such as interacting with a social network service as taught by Sundaresan to provide the benefit of expanding the tracking ways to notify a user of a rule satisfaction.
Claim 29 depends on claim 26:
Wee teaches wherein the condition is satisfied by the second device performing an operation, the second device being placed in a state, or and (e.g., receiving a policy change message from a developer to configure an action to be performed by a first IOT device based on the second IOT device satisfying a condition (e.g., developer manually establishes a policy condition for a first IOT actuator device to perform an action when a second IOT temperature sensor device reaches a particular degree (i.e., being placed in a state)) Figures 7, 10 and 12; selectable real thing IOT devices to be used to establish a policy; Figure 12; policy dialog window 1220 allows a policy message to be established which is associated with a request to configure an action with an actuator device par. 26; Smart object networks, such as sensor networks, in particular, are a specific type of network having spatially distributed autonomous devices such as sensors, actuators, etc., that cooperatively monitor physical or environmental conditions at different locations, such as, e.g., energy/power consumption, resource consumption (e.g., water/gas/etc. for advanced metering infrastructure or "AMI" applications) temperature, pressure, vibration, sound, radiation, motion, pollutants, etc. Other types of smart objects include actuators, e.g., responsible for turning on/off an engine or perform any other actions. par. 51; FIG. 6 illustrates an example functional diagram of the IoT IDE 600 described herein. In particular, the IDE allows developers to capture (610) inputs from any number of physical nodes/things (612) and/or virtual nodes/things (614) (e.g., objects, sensors, data producers, etc.), and processes the inputs (620) (e.g., transformations based on one or more rules engines) to result in one or more corresponding actions (630). Example actions include outputs to physical things (632) and/or virtual things (634) (e.g., objects, actuators, indicators, etc.) par. 60; As shown in the view 1200 of the GUI in FIG. 12, the IoT IDE also allows developers to easily provide functionality, write policies, and compile the nodes.)
wherein the action comprises the first device performing a second operation, the first device being placed in a second state, or . (e.g., receiving a policy change message from a developer to configure an action to be performed by a first IOT device based on the second IOT device satisfying a condition (e.g., developer manually establishes a policy condition to turn the air conditioning down when the second IOT device temperature sensor reaches a particular degree) Examiner notes that extending the policy to include additional conditions and output IOT devices is well within the scope of Wee Figures 7 and10; real thing IOT devices such as temp. sensors and air conditioners may be used Figure 12; policy dialog window 1220 allows messages associated with a request to configure an action par. 26; Smart object networks, such as sensor networks, in particular, are a specific type of network having spatially distributed autonomous devices such as sensors, actuators, etc., that cooperatively monitor physical or environmental conditions at different locations, such as, e.g., energy/power consumption, resource consumption (e.g., water/gas/etc. for advanced metering infrastructure or "AMI" applications) temperature, pressure, vibration, sound, radiation, motion, pollutants, etc. Other types of smart objects include actuators, e.g., responsible for turning on/off an engine or perform any other actions. par. 51; FIG. 6 illustrates an example functional diagram of the IoT IDE 600 described herein. In particular, the IDE allows developers to capture (610) inputs from any number of physical nodes/things (612) and/or virtual nodes/things (614) (e.g., objects, sensors, data producers, etc.), and processes the inputs (620) (e.g., transformations based on one or more rules engines) to result in one or more corresponding actions (630). Example actions include outputs to physical things (632) and/or virtual things (634) (e.g., objects, actuators, indicators, etc.) par. 60; As shown in the view 1200 of the GUI in FIG. 12, the IoT IDE also allows developers to easily provide functionality, write policies, and compile the nodes.)
Wee/Sedayao/Siebel fails to expressly teach the second or first device interacting with a social networking service.
However, Sundaresan teaches the second or first device interacting with a social networking service. (e.g., wherein the condition is satisfied, a device is triggered to interact with a social networking service (e.g., send emails). Par. 68; FIG. 5 is a flow chart for an example method 500 of triggering one or more actions on services and/or network-connected devices responsive to events on other services and/or network-connected devices. par. 72; At block 545, processing logic notifies a user of the user account of the rule satisfaction. The notification to the user may be an electronic mail (email) message sent to an email address of the user. The notification to the user may also be an SMS or MMS message sent to a phone number of the user. The notification may also be an automated phone call to a phone number of the user, a posting to a social network account of the user, or other type of notification)
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 actions within a policy related configuration rule as taught by Wee/Sedayao/Siebel to include an action such as interacting with a social network service as taught by Sundaresan to provide the benefit of expanding the tracking ways to notify a user of a rule satisfaction.
Claims 2, 11, 23, 27, 33 and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Wee/Sedayao/Siebel as cited above, and applied to claims 1, 26 and 32, further in view of O’Riordan; Donald, U.S. Published Application No. 2011/0276908 A1.
Claim 2 depends on claim 1:
Wee teaches wherein receiving the gestural input comprises receiving, via a user interface, the gestural input, wherein the user interface comprises (e.g., touch input for touch screen interface to configure written policies par. 39; Furthermore, a number of associated user interface gestures are described to allow a user to interact with the IDE of IoT, in particular for touchscreen implementations. Figure 12; writing a policy via dialog window) a canvas onto which graphical user elements, associating with each device of the plurality of devices are dragged and dropped (e.g. dragging air conditioner or sensors onto the canvas Figures 10- 12).
Wee/Sedayao/Siebel fails to expressly teach wherein the user interface comprising a grid. (emphasis added)
However, O’Riordan teaches wherein the user interface comprising a grid (e.g., well known for IDE to have grid spacing Figure 2, par. 30; A sampling of some EDA contextual examples in which such state-bearing controls are useful, such as in nested, difficult-to-find EDA tool options dialogs, include grid state (on or off, layout and schematic editors, waveform tools, etc.), grid spacing (dense or sparse, layout and schematic editors, waveform tools, etc.), wire snapping (on or off, schematic editors), par. 33; For example, if an EDA tool user were to enable the displayed grid using a grid on/off menu toggle, then a drafting toolbar or canvas-specific context menu which also contains a show/hide grid toggle button, is also maintained in a synchronized state. Par. 70; turning on or off a grid in a layout editor view)
In the same field of endeavor of configuring within a IDE environment, 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 editing canvas as taught by Wee/Sedayao/Siebel to include a grid canvas as taught by O’Riordan with a reasonable expectation of success, to provide the benefit of better organizing the layout of objects.
Claim 11 depends on claim 2:
Wee teaches wherein the user interface further comprises a tray, located at an edge of the user interface, comprising graphical user elements associated with each device of the plurality of devices. (Figure 7; menu tray 710 of IoT elements which includes sensors)
Claim 23 depends on claim 2:
Wee teaches further comprising: updating, based on the indication, the user interface. (e.g., re-simulating after each validation of the updated written policy configurations which include actions Figure 12; select “add button” to update policy-related configuration par. 15; Examples of such visual developer tools include dragging icons, connecting items logically, programming the items, validating the configurations, and running (executing) the system to obtain a result (virtualization, simulation, etc.).)
Claim 27 depends on claim 26:
Claim 27 is substantially encompassed in claim 2, therefore, Examiner relies on the rationale set forth in claim 2 to reject claim 27.
Claim 33 depends on claim 32:
Claim 33 is substantially encompassed in claim 2, therefore, Examiner relies on the rationale set forth in claim 2 to reject claim 33.
Claim 34 depends on claim 33:
Claim 34 is substantially encompassed in claim 23, therefore, Examiner relies on the rationale set forth in claim 23 to reject claim 34.
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Wee/Sedayao /Siebel as cited above, and applied to claim 1, further in view of Briden et al. (hereinafter “Briden”), U.S. Published Application No. 20100162210 A1.
Claim 8 depends on claim 1:
Wee teaches wherein the gestural input comprises a swipe motion from a first user interface element, associated with the first device to a location on the user interface between a second user interface element, and a third user interface element, associated with a third device of the plurality of devices (e.g., dragging multiple IOT devices as input for a policy rule for operating a third IOT device Figure 12; use policy editor to modify rules of automatic node connections Figure 15; condition with multiple IOT devices as input (e.g., multiple motion sensor are triggered by movement before an action is performed with a camera (e.g., turn on camera))par. 51; In particular, the IDE allows developers to capture (610) inputs from any number of physical nodes/things (612) and/or virtual nodes/things (614) (e.g., objects, sensors, data producers, etc.), and processes the inputs (620) (e.g., transformations based on one or more rules engines) to result in one or more corresponding actions (630). par. 59; In one embodiment, particularly for touchscreen implementations, algorithms are defined for auto-placement and auto-connection of the logical "blocks" (nodes). That is, the developer may be able to just select a node, and "flick" it in the general direction of the intended location, and the IoT IDE can determine where to connect the node within the graph based on various rules, e.g., based on input/output ports, how close they are on the canvas. Par. 84; For example, one simple function that may be defined could be turning on a camera when a certain person moves into a certain area, based on motion sensors, wireless access point access, RFID badging, etc.)
Wee/Sedayao /Siebel fails to expressly teach causing the gestural input to establish and AND condition for operating the third device based on the operation of the first device or the second device.
.
However, Briden teaches causing the gestural input to establish and AND condition for operating the third device based on the operation of the first device or the second device. (e.g., well known to apply logical operators to complex rule statements Briden; Figures 4-6; AND or OR logical operators applied to complex rules in a drag and drop interface environment par. 6; In all of these cases it may be challenging to find a comfortable method allowing users to define expressions using the full possibilities of the expression language, without requesting the users to learn a complex syntax or acquire programming skills. par. 35; In addition to typing expressions, the user can be presented with a `palette` (600) of logic blocks that thee user can add to the rule he is creating, as shown in FIG. 6. From that palette (600), the user can select rule blocks (602) and drag them onto the respective rule, as shown in FIGS. 6 and 7.)
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 logical view of IOT device connections as taught by Wee/Sedayao /Siebel to include logical operators as taught by Briden, with a reasonable expectation of success, to provide the benefit of easily creating complex expressions for a rule statement.
Claim 9 depends on claim 1:
Wee teaches wherein the gestural input comprises a swipe motion from a first user interface element associated with the first device to a second user interface element associated with the second device that is connected to a third user interface element associated with a third device of the plurality of devices (e.g., dragging multiple IOT devices as input for a policy rule for operating a third IOT device Wee; Figure 12; use policy editor to modify rules of automatic node connections Figure 15; condition with multiple IOT devices as input (e.g., multiple motion sensor are triggered by movement before an action is performed with a camera (e.g., turn on camera))par. 51; In particular, the IDE allows developers to capture (610) inputs from any number of physical nodes/things (612) and/or virtual nodes/things (614) (e.g., objects, sensors, data producers, etc.), and processes the inputs (620) (e.g., transformations based on one or more rules engines) to result in one or more corresponding actions (630). par. 59; In one embodiment, particularly for touchscreen implementations, algorithms are defined for auto-placement and auto-connection of the logical "blocks" (nodes). That is, the developer may be able to just select a node, and "flick" it in the general direction of the intended location, and the IoT IDE can determine where to connect the node within the graph based on various rules, e.g., based on input/output ports, how close they are on the canvas. Par. 84; For example, one simple function that may be defined could be turning on a camera when a certain person moves into a certain area, based on motion sensors, wireless access point access, RFID badging, etc.)
Wee/Sedayao/Siebel fails to expressly teach causing the gestural input to establish an OR condition for operating the third device based on operation of the first device or the second device.
However, Briden teaches causing the gestural input to establish an OR condition for operating the third device based on operation of the first device or the second device. (Briden; Figures 4-6; AND or OR logical operators applied to complex rules in a drag and drop interface environment par. 6; In all of these cases it may be challenging to find a comfortable method allowing users to define expressions using the full possibilities of the expression language, without requesting the users to learn a complex syntax or acquire programming skills. par. 35; In addition to typing expressions, the user can be presented with a `palette` (600) of logic blocks that thee user can add to the rule he is creating, as shown in FIG. 6. From that palette (600), the user can select rule blocks (602) and drag them onto the respective rule, as shown in FIGS. 6 and 7.)
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 logical view of IOT device connections as taught by Wee/Sedayao /Siebel to include logical operators as taught by Briden, with a reasonable expectation of success, to provide the benefit of easily creating complex expressions for a rule statement.
Response to Arguments
Applicant's arguments filed 3/30/2026 have been fully considered but they are not persuasive.
Prior Art Rejections
Applicant argues The cited portions of Wee describe merely providing an IoT IDE with visual developer tools that " include dragging icons, connecting items logically, programming the items, validating the configurations, and running (executing) the system to obtain a result (virtualization, simulation, etc.)" (see Wee at paragraph [0050]), which is not the same as verifying device compatibility based on manufacturer or vendor provided configuration information.
Examiner respectfully disagrees.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., based on manufacturer or vendor provided configuration information) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Under broadest reasonable interpretation (BRI), Examiner submits that the claim language “information is from an entity associated with a manufacturer or vendor does not necessarily require “manufacturer or vendor provided information” as alleged in the Applicant’s arguments. Therefore, Applicant is arguing features not required in the claims.
For at least the foregoing reasons, Examiner maintains prior art rejections.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HENRY ORR whose telephone number is (571)270-1308. The examiner can normally be reached 9AM-5PM EST M-F.
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, Adam Queler can be reached at (571)272-4140. 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.
/HENRY ORR/Primary Examiner, Art Unit 2172
Prosecution Insights