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 and is in response to communications filed on 7/17/2025 in which claims 21, 23-31, 33-42 are presented for examination.
Priority
Acknowledgement is made of parent applications including provisional Application 62/564,247 filed 9/27/2017.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 21 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 11768826 in view of De Baynast De Septfontaines et al. US 20160179063 A1. There’s a slight difference in the claim language with respect to sensors of a building, but this is an obvious difference even in the claim language. For instance, the language uses objects of a building in one claim, and physical devices in the other. This is obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the claims of the invention in order to include a sensor, specifically of a building; this is advantageous because sensors allow for the tracking of values that are useful in buildings such as temperature, motion, humidity, on/off values, etc. (De Baynast De Septfontaines, paragraph [0056]).
Independent claims 31 and 40 are rejected for similar reasoning.
Claim 21. A building system comprising one or more storage media storing instructions thereon that, when executed by one or more processors, cause the one or more processors to:
generate a smart entity graph comprising object entities representing objects of a building, data entities representing data associated with the objects, and relational objects indicating relationships between the object entities and the data entities, wherein at least one data entity of the data entities corresponds to a sensor for the building and stores data values received from the sensor, wherein at least one relational object of the relational objects indicates a type of relationship;
receive data associated with an object of the objects;
search, based on an identifier of the data, the smart entity graph to identify an object entity of the object entities representing the object responsive to receiving the data;
search the smart entity graph to identify a data entity of the data entities by identifying a relational object of the relational objects relating the object entity with the data entity; and
modify the data entity based on the data received from the object.
1. (Currently Amended) One or more non-transitory computer readable media containing program instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
generating a database of interconnected smart entities, the smart entities comprising object entities representing each of the plurality of physical devices and data entities representing data generated by the plurality of physical devices, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities, wherein at least one relational object of the relational objects indicates a type of relationship;
receiving data from a first device of the plurality of physical devices and identifying a first object entity of the object entities representing the first device;
determining a second device of the plurality of physical devices using a first relational object of the relational objects connecting the first object entity representing the first device and a second object entity of the object entities representing the second device;
identifying a data entity of the data entities storing data for the second device using a second relational object of the relational objects connecting the data entity and the second object entity representing the second device; and
modifying the data entity with the data received from the first device.
Claims 21 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 11314788 in view of De Baynast De Septfontaines. There’s an addition of determining types of relationships, but this is an obvious difference for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the claims of the invention in order to put constraints on connections; this is advantageous because this allows constraints on the types of values which may be input or output from specified components. This also allows for automated design and operationalization that occurs dynamically, on-the-fly, so that performance is continually improved despite changes in the equipment being controlled. De Baynast De Septfontaines also teaches multiple sensors and other devices which correspond to second objects in IoT environment (De Baynast De Septfontaines, paragraphs [0019] and [0041]).
Independent claims 31 and 40 are rejected for similar reasoning.
Claim 21. A building system comprising one or more storage media storing instructions thereon that, when executed by one or more processors, cause the one or more processors to:
generate a smart entity graph comprising object entities representing objects of a building, data entities representing data associated with the objects, and relational objects indicating relationships between the object entities and the data entities, wherein at least one data entity of the data entities corresponds to a sensor for the building and stores data values received from the sensor, wherein at least one relational object of the relational objects indicates a type of relationship;
receive data associated with an object of the objects;
search, based on an identifier of the data, the smart entity graph to identify an object entity of the object entities representing the object responsive to receiving the data;
search the smart entity graph to identify a data entity of the data entities by identifying a relational object of the relational objects relating the object entity with the data entity; and
modify the data entity based on the data received from the object.
Claim 1. One or more non-transitory computer readable media containing program instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
generating a database of interconnected smart entities, the smart entities comprising object entities representing each of a plurality of objects associated with one or more buildings and the plurality of objects each representing a space, person, building subsystem, and/or device, and data entities representing data generated by the plurality of objects, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities;
receiving data from a first object of the plurality of objects;
determining a second object of the plurality of objects from a relational object of the relational objects for the first object based on the received data;
identifying a data entity storing data for the second object by identifying a particular relational object of the relational objects between the data entity and an object entity of the object entities representing the second object; and
modifying the data entity of the data entities connected to the object entity of the object entities representing the second object with the data received from the first object.
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 of this title, 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 21, 23-29, 31, 33-38, and 40-42 are rejected under 35 U.S.C. 103 as being unpatentable over Shaashua et al. US 20160342906 A1 (hereinafter referred to as “Shaashua”) in view of Blank et al. US 10015069 B1 (hereinafter referred to as “Blank”) and further in view of Gomada et al. US 20160314202 A1 (hereinafter referred to as “Gomada”).
As per claim 21, Shaashua teaches:
A building system comprising one or more storage media storing instructions thereon that, when executed by one or more processors, cause the one or more processors to:
generate a smart entity graph (Shaashua, [0158] – entity graph is interpreted as the smart entity graph.
Specification [0093], [0171] and [0188] including examples given in fig. 8 which shows an entity graph of entity data)
comprising object entities (Shaashua, [0158] – target entity is interpreted as an object entity.
Specification [0189] gives an example of a thermostat which is also an example given in Shaashua)
representing objects of a building (Shaashua, [0154] – Contextual situations for a target entity that represents a device can include: “the Device will be on,” “Device will be off,” “Thermostat will be at 27° C.,” “the Device will be at [specific state],” or any combination thereof. Other examples in [0162], and [0163], wherein at least the thermostat is interpreted as an object of a building),
data entities representing data associated with the objects (Shaashua, [0158] – context indicators associated directly or indirectly with target entity and/or the raw data connected in the entity graph are interpreted as data entities), and
relational objects indicating relationships between the object entities and the data entities (Shashua, [0163] – Edges are interpreted as relational objects because they indicate relationships between object entities and data entities. Also [0169] – An example for how a relationship is used is that there’s context between an object and data, wherein an object entity (person A or B) connects to a data entity (“has left” or “has arrived”).
Specification, paragraph [0111] gives an example of sensors and other data as entities which may define links among themselves),
wherein at least one data entity of the data entities corresponds to a data source for the building (Shaashua, [0158] – context indicators interpreted as data entities, and [0154] – Thermostat is interpreted as a data source for a building, wherein this corresponds to [0183] of the specification: “an object entity corresponding to the thermostat could include the last temperature reading and a link to a data entity that stores a series of the last ten temperature readings”)
and stores data values (Shaashua, [0160] – Context indicators in the form of historical profiles of trackable entities are interpreted as data entities storing values. NOTE: a data entity storing data values is confusing because a data entity is understood to be a value that is produced; not a repository of any kind. However, for examination purposes, this is interpreted that the data entity acts as a virtual placeholder for data values that are stored in the system by some storage means)
received from the data source (Shaashua, [0167] – An example of data that is stored is a historical profile which can correspond to a single trackable entity. This can include data such as temperature, heartbeat, time, location coordinate, etc. which are all received from data sources such as thermostat ([0154]), heart rate monitor ([0134]), clock, GPS ([0072]), etc. respectively),
wherein the data entities are instances of data type classes for different data types (Shaashua, [0145] – Label a type of entity of the node added. [0161] – The event detection engine can be implemented as a machine learning model that classifies its input features (e.g., activity data from the activity data streams and/or other context indicators regularly computed/updated by the IoT integration platform) into one or more types of events.
Specification: paragraph [0208] recites, “other types of data as inputs to a risk function that calculates the value of the person object entity's "risk" attribute.” There’s no explicitly support from the specification the data entities are instances especially of “data type classes.” Furthermore, these particular terms (“data type” or “type class”) aren’t explicitly defined, but the terms: “types” and “class” are present throughout the specification (most notable paragraphs are [0189]-[0198]),
wherein at least one relational object of the relational objects indicates a type of relationship (Shaashua, [0163] – Edges model different types of relationships between entities);
receive data from the data source comprising a value of a data type of the different data types (Shaashua, [0161] – The event detection engine can be implemented as a machine learning model that classifies its input features (e.g., activity data from the activity data streams and/or other context indicators regularly computed/updated by the IoT integration platform) into one or more types of events),
the data source comprising at least one of a sensor (Shaashua, [0033] – IOT devices: smart sensors, …, sensor), an actuator, or a piece of equipment of the building (Shaashua, [0087] – The data correlation module 306 and the data analysis module 308 can recognize that every morning a user starts the coffee machine, turns on the music, leaves a house, and turns off all lights and thermostat, wherein the recognition of the status of the objects are interpreted as receiving data associated with the objects);
modify the data entity by identifying a dynamic attribute of the data entity from the data and storing the value of the data in the dynamic attribute (Shaashua, [0160] – Again, context indicators can include current profile or historical profiles of trackable entities, wherein trackable entities are interpreted as dynamic attributes. [0167] – Each historical profile can correspond to a single trackable entity. A historical profile can include one or more profile attributes. The profile attribute can be an enumerated value, such as “male” or “female”, “on” or “off”, or “day” or “night”. A profile attribute can also be a numeric value, such as a numeric value representing temperature, heartbeat, time, location coordinate, IP address, physical address, or any combination thereof. This corresponds to paragraph [0013] of the specification for dynamic attributes and storing values).
Although Shaashua teaches a system which can identify unique identifiers based on devices data elements in paragraph [0050] as well as an entity graph which reads on a smart entity graph, Shaashua doesn’t explicitly teach responsive to receiving the data, a search is conducted, however, Blank teaches:
search, based on an identifier of the data, the smart entity graph to identify an object entity of the object entities representing the data source responsive to receiving the data (Blank, Column 10, lines 16-27 – New identifier of an awakened probe. Column 12, lines 10-25 – Information of sensors is stored in a database, typically a relational database, comprised of tables appropriate to the mapping of the networks and probes being monitored. Using search, sort, and reporting function, analysis and reports are possible.
Specification [0216] cites, “the search service710 provides a unified view of product related information in the form of the entity graph.”);
It would have been obvious for one of ordinary skill in the art at the time of the filing of the application to modify Shaashua’s invention as modified in view of Blank in order to search for an identifier of data in a database; using regular expressions is a known technique which would be advantageous for searching and finding an event from a device that is stored in a database to alert if there’s an error (Blank, column 11, lines 30-35).
Although Shaashua teaches in [0163] – Different types of relationships between entities, Shaahsua doesn’t explicitly teach searching through a smart entity graph to identify an instantiation of a data entity identifying a relational object, however, Gomadam teaches:
search the smart entity graph to identify a data entity of the data entities instantiated for a data type class for the data type by identifying a relational object of the relational objects relating the object entity with the data entity (Gomadam teaches in [0044] – An entity may exist for every instance of a database within the domain knowledge graph 212 relating to the metadata for that particular database, wherein the metadata the entity relates to is interpreted as being instantiated for a data type class. [0048] – Instantiation of things to which the core model relates. The core model may exist as part of the domain knowledge graph 212 of the linked data model (LDM) 700 and may be interlinked within the domain knowledge graph to particular instances of the core model. Also, [0056] – The processor may be part of the data ingestion circuitry 202 or may instantiate the data ingestion circuitry. For example, the dataset context information may identify the dataset as coming from a particular type of data source (e.g., a pressure sensor) or may be of a particular data type (e.g., pressure sensor data). [0061] – The content aware routing circuitry identifies the type of data being processed (e.g., sensor data) and the correct database into which to store the received data. If a data source has already been onboarded, the content aware routing circuitry 216 may query or traverse the domain knowledge graph 212 to identify the proper database for storage of data. This corresponds to definitions of instantiation and searching of entity type [0215]-[0216] of the specification); and
It would have been obvious for one of ordinary skill in the art at the time of the filing of the application to modify Shaashua’s invention as modified in view of Gomadam in order to search the graph for a data type; this would have been advantageous because it allows for the system to match dataset type nodes in the graph which then leads to the proper location of the dataset type node (Gomadam, [0057]).
As per claim 23, Shashua as modified teaches:
The building system of claim 21, wherein the relational object semantically defines a connection between the data entity and the object entity (Shaashua, [0070] – An advantage of the data analysis and data correlation is generation of one or more layers of contextual, correlative, and/or semantic insights, trigger events, and/or actions. The data analysis module 308 may apply machine learning on the analyzed and/or correlated data coming from the three layers described above and create a sense of “cognition”—understanding of contextual, correlative, and/or semantic events in a user's life. These layers enable predictive or reflective comprehension of user and/or IoT device behavior patterns and/or trends, and may further enable synthesis of generalizations of user and/or IoT device activity or need).
As per claim 24, Shaashua as modified teaches:
The building system of claim 21, wherein the object entities are associated with a static attribute to identify the object entity (Shaashua, [0167] – A profile attribute can also be a numeric value, such as a numeric value representing temperature, heartbeat, time, location coordinate, IP address, physical address, or any combination thereof, wherein these addresses are interpreted as static attributes), and
a behavioral attribute that defines an expected response of the object entity to an input (Shaashua, [0070] – These layers enable predictive or reflective comprehension of user and/or IoT device behavior patterns and/or trends, and may further enable synthesis of generalizations of user and/or IoT device activity or need).
As per claim 25, Shaashua as modified teaches:
The building system of claim 24, wherein the data entity is configured to store the dynamic attribute of the object entity (Shaashua, [0160] – Again, context indicators can include current profile or historical profiles of trackable entities, wherein trackable entities are interpreted as dynamic attributes, which can be [0167] – enumerated value, such as “male” or “female”, “on” or “off”, or “day” or “night”. A profile attribute can also be a numeric value, such as a numeric value representing temperature, heartbeat, time, location coordinate, IP address, physical address, or any combination thereof, wherein at least time, location, temperature, etc. are dynamic attributes because they change over time).
As per claim 26, Shaashua as modified teaches:
The building system of claim 21, wherein the instructions cause the one or more processors to;
identify a second object entity of the object entities representing a second object of the building (Shaashua, [0080] – When the friend's (e.g., Erica's) activity tracker is close to the connected door lock of the user, and the user has given permissions, then the connected door lock can open automatically by recognition of a social context of a “friend at my home next to my connected door.”);
identify that the relational object relates the second object entity with the data entity and identify a second relational object of the relational objects relating the object entity and the second object entity (Shaashua, [0163] – Inference and prediction is done over an entity graph, where users, devices and places are entity nodes, and edges model different types of relationships between entities); and
modify the data entity responsive to identifying the relational object and the second relational object (Shaashua, [0080] – When the friend's (e.g., Erica's) activity tracker is close to the connected door lock of the user, and the user has given permissions, then the connected door lock can open automatically by recognition of a social context of a “friend at my home next to my connected door.”).
As per claim 27, Shaashua as modified teaches:
The building system of claim 26, wherein the object is a temperature sensor and the data entity is configured to store an ambient temperature value of a space represented by the second object entity based on ambient temperature data received from the temperature sensor (Shaashua, [0082] – When a user turns off his office lights and leaves the work, then his home temperature may be set automatically for a desired temperature).
As per claim 28, Shaashua as modified teaches:
The building system of claim 26, wherein the object is an access control device (Shaashua, [0062] – For example, a “front door” may be in a context with different default behaviors or interoperable rules than a “bedroom door.” Similarly, data generated through these semantically labeled IoT devices 324 may also be semantically labeled. See also paragraph [0080] for door locking) and
the second object is a person associated with the building in which the access control device is located (Shaashua, [0038] – Context relevant entities may include people, places, groups, physical objects, brands, things, or any combination thereof. See also paragraph [0080] for door locking).
As per claim 29, Shaashua as modified teaches:
The building system of claim 28, wherein the data entity is configured to store a location attribute of the person based on access control data received from the access control device (Shaashua, [0070] – Geo-location, for example, may be reported via a global positioning system (GPS) component or a network module (e.g., via network source triangulation) of the IoT devices).
Claims 31, 33-38 are directed to a method performing steps recited in claims 21, 23-29 with substantially the same limitations. Therefore, the rejections made to claims 21, 23-29 are applied to claims 31, 33-38.
Claim 40 is directed to one or more storage media performing steps recited in claim 21 with substantially the same limitations. Therefore, the rejection made to claim 21 is applied to claim 40.
As per claim 41, Shaashua as modified teaches:
The building system of claim 21, wherein the data type classes comprise at least one of:
a point class comprising a present value for the point class and a unit for the point class; or
a timeseries class comprising values for the timeseries class and a unit for the timeseries class (Gomadam, [0029] – A pressure sensor may have various types of data including configuration data (e.g., denormalized data), sensor readings (e.g., time series data)).
Claim 42 is directed to a method performing steps recited in claim 41 with substantially the same limitations. Therefore, the rejection made to claim 41 is applied to claim 42.
Claims 30 and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Shaashua in view of Blank in view of Gomadam and further in view of Ignatowski et al. US 20030200059 A1 (hereinafter referred to as “Ignatowski”).
As per claim 30, Shaashua as modified doesn’t go into detail about average historical personal arrival time, however, Ignatowski teaches:
The building system of claim 29, wherein the instructions cause the one or more processors to:
create a shadow entity to store historical values of the access control data received from the access control device (Ignatowski, [0018] – To calculate the performance estimate, the script measurements data is read from a table of previously measured values Make sure the mapping is clear), and
calculate an average arrival time of the person from the historical values stored in the shadow entity (Ignatowski, [0018] and [0062] – Objectives include a user arrival rate or average response time or any number of criteria specified such as weighted average).
It would have been obvious for one of ordinary skill in the art at the time of the filing of the application to modify Shaashua’s invention as modified in view of Ignatowski in order to track arrival rates of a person; this is advantageous because it allows the system to fulfill objectives (Ignatowski, paragraph [0062]).
Claim 39 is directed to a method performing steps recited in claim 30 with substantially the same limitations. Therefore, the rejection made to claim 30 is applied to claim 39.
Response to Arguments
Applicant’s arguments filed in Remarks on 7/17/2025 with respect to prior art rejections under 35 U.S.C 103 have been fully considered but they are not persuasive. Applicant’s arguments begin on page 3 where there are a total of 3 specific arguments. Each specific argument is addressed below.
The double patenting rejection is still pending due to lack of arguments.
Argument: Applicant argues in Remarks on page 9 that the prior art of record doesn’t adequately teach wherein the data entities are instances of data type classes for different data types.
In Response: Further search of reference Shaashua was cited using [0145] – Label a type of entity of the node added. [0161] – The event detection engine can be implemented as a machine learning model that classifies its input features (e.g., activity data from the activity data streams and/or other context indicators regularly computed/updated by the IoT integration platform) into one or more types of events.
Specification: paragraph [0208] recites, “other types of data as inputs to a risk function that calculates the value of the person object entity's "risk" attribute.” There’s no explicitly support from the specification the data entities are instances especially of “data type classes.” Furthermore, these particular terms (“data type” or “type class”) aren’t explicitly defined, but the terms: “types” and “class” are present throughout the specification (most notable paragraphs are [0189]-[0198] teaches in [0044] – An entity may exist for every instance of a database within the domain knowledge graph 212 relating to the metadata for that particular database, wherein the metadata the entity relates to is interpreted as being instantiated for a data type class. Also, [0056] – The processor may be part of the data ingestion circuitry 202 or may instantiate the data ingestion circuitry. For example, the dataset context information may identify the dataset as coming from a particular type of data source (e.g., a pressure sensor) or may be of a particular data type (e.g., pressure sensor data). Therefore, the language of the claims in view of the specification, Shaashua teaches the limitation.
Argument: Applicant argues in Remarks on page 9, the prior art of record doesn’t adequately teach search the smart entity graph to identify a data entity of the data entities instantiated for a data type class for the data type by identifying a relational object of the relational objects relating the object entity with the data entity. Shaashua discusses detecting a type or make of an IoT device itself, not detecting any kind of data entity of an IoT device that are “instances of data type classes for different data types,” let alone generating “a smart entity graph comprising . . . data entities. . . wherein the data entities are instances of data type classes for different data types.”.
In Response: Reference Gomadam was used with [0044] – An entity may exist for every instance of a database within the domain knowledge graph 212 relating to the metadata for that particular database, wherein the metadata the entity relates to is interpreted as being instantiated for a data type class. [0048] – Instantiation of things to which the core model relates. The core model may exist as part of the domain knowledge graph 212 of the linked data model (LDM) 700 and may be interlinked within the domain knowledge graph to particular instances of the core model. Also, [0056] – The processor may be part of the data ingestion circuitry 202 or may instantiate the data ingestion circuitry. For example, the dataset context information may identify the dataset as coming from a particular type of data source (e.g., a pressure sensor) or may be of a particular data type (e.g., pressure sensor data). [0061] – The content aware routing circuitry identifies the type of data being processed (e.g., sensor data) and the correct database into which to store the received data. If a data source has already been onboarded, the content aware routing circuitry 216 may query or traverse the domain knowledge graph 212 to identify the proper database for storage of data. This corresponds to definitions of instantiation and searching of entity type [0215]-[0216] of the specification. Again, the specification isn’t clear with respect to “instantiation”, and therefore, based on a reasonable interpretation in view of the specification, the prior art of record teaches the claimed limitation.
Argument: Applicant argues in Remarks on page 4 the prior art of record doesn’t adequately teach search, based on an identifier of the data, the smart entity graph to identify an object entity of the object entities representing the data source responsive to receiving the data.
In Response: Blank was used with column 10, lines 16-27 – New identifier of an awakened probe. Column 12, lines 10-25 – Information of sensors is stored in a database, typically a relational database, comprised of tables appropriate to the mapping of the networks and probes being monitored. Using search, sort, and reporting function, analysis and reports are possible.
The specification [0216] cites, “the search service710 provides a unified view of product related information in the form of the entity graph.”
Based on a reasonable interpretation of the claims in view of the specification, Shaashua as modified with Blank teaches a smart entity graph that is searched. The specification isn’t clear with respect to searching through the graph, but Blank teaches this with “appropriate to the mapping of the networks and probes being monitored”. Therefore, the prior art of record teaches the claimed limitations.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Baez et al. US 20170123389 A1 teaches classifying, by the processor-based capability determining element, the different devices according to capability maturity rankings supported by the different capabilities to provide maturity-based capability classifications for the different devices in an IoT environment (Abstract and [0005]).
Chi et al. US 20170220641 A1 teaches a relational database management system ([0043]).
Dong et al. US 20160119434 A1 teaches an intelligent negotiation service for internet of things (Title).
Reid et al. US 20160277374 A1 teaches unique identities in a database for devices in paragraphs [0075]-[0100].
Chung et al. US 20140205155 A1 teaches a unique identifier of RFID tags for smart devices in a relational database in paragraph [0195].
Angle et al. US 20140207282 A1 teaches a mobile robot that can identify rooms by combining identity information, an RSSI, and a remote control in paragraph [0097].
Penilla et al. US 20170103327 A1 teaches connected objects being used within the home, internet of things objects within or near or associated with the home or networks of the home in [0309].
Schindlauer et al. US 20120005220 A1 teaches dynamic asset monitoring and management using a continuous event processing platform (Title).
Adiba et al. US 20110153603 A1 teaches collecting and storing large volumes of time series data. For example, such data may comprise metrics gathered from one or more large-scale computing clusters over time
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Matthew Ellis whose telephone number is (571)270-3443. The examiner can normally be reached on Monday-Friday 8AM-5PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neveen Abel-Jalil can be reached on (571)270-0474. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
October 7, 2025
/MATTHEW J ELLIS/Primary Examiner, Art Unit 2152