CTNF 18/596,365 CTNF 93625 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Status of the Claims A Requirement for Restriction/Election was issued on 12/04/2025. Claims 1-6 and 15-20 are canceled. Claims 21-32 are new. Claims 7-14 and 21-32 are pending in the instant patent application. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Regarding Claims 7-14 and 21-32, they are directed to a method, however the claims are directed to a judicial exception without significantly more. Claims 7-14 and 21-32 are directed to the abstract idea of managing ontology. Performing the Step 2A Prong 1 analysis while referring specifically to independent Claim 1, claim 1 recites receiving data points from a node of the data handling facility, the data points indicating the node as a reporting node; performing name-based data validation of the data points; responsive to the data points passing the name-based data validation, recording the data points; and determining data integrity of the data handling facility by determining a ratio of recorded data points over a specified period of time to a number of expected data points over the specified period of time. These claim limitations fall within the Mental Processes grouping of abstract ideas for they are concepts that can be practically performed in the human mind and/or with pen/paper. Furthermore, the courts have found claims requiring a generic computer or nominally reciting a generic computer may still recite a mental process even though the claim limitations are not performed entirely in the human mind (see MPEP 2106.04(a)(2)(III)(C)). Accordingly, the claim recites an abstract idea and dependent claims 8-14 and 21-32 further recite the abstract idea. Regarding Step 2A Prong 2 analysis, the judicial exception is not integrated into a practical application. In particular the claim recites the elements of a data store. The data store is merely a generic computing device and does not integrate the judicial exception into a practical application. With respect to 2B, the claims do not include additional elements amounting to significantly more than the abstract idea. Claims 7 and 22 include various elements that are not directed to the abstract idea under 2A. These elements include a data store, an inventory management system and the generic computing elements described in the Applicant's specification in at least Para 0094. These elements do not amount to more than the abstract idea because it is a generic computer performing generic functions. Therefore, Claims 7 and 22, alone or in combination, are not drawn to eligible subject matter as they are directed to abstract ideas without significantly more. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries 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. 07-21-aia AIA Claim (s) 7-14, 27 and 30-32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smith et al. (US 2019/0171510 A1) in view of Howarth et al. (US 2006/0033606 A1) . Regarding Claim 7, Smith teaches the limitations of Claim 7 which state receiving data points from a node of the data handling facility, the data points indicating the node as a reporting node (Smith: Para 0033 via Embodiments can also include a health monitoring engine (HME) that receives heartbeat messages from nodes (e.g., monitored devices 30-1 through 30-M, network devices 40 and 40-1 through 40-N) within an IoT network. Heartbeat messages are a type of watchdog message that contain additional information. For example, heartbeat messages may contain a device identifier (‘device ID’), a local time stamp, a next heartbeat time, a node health and diagnostic information, and a watchdog report from a subordinate node or network of nodes (e.g., subnet). The HME can use machine learning (ML) techniques to form a reference template by monitoring actual heartbeat messages during a training period and by being informed of expected watchdog messages or a schedule of watchdog messages using a data model); and determining data integrity of the data handling facility by determining a ratio of recorded data points over a specified period of time to a number of expected data points over the specified period of time (Smith: Para 0122, 0130 via HME 85 can determine a threshold of missing heartbeats that constitutes a resiliency risk. The statistical probability can be compared to the threshold to determine whether a resiliency risk exists in the network. For example, in at least one embodiment, a threshold could be a 50% resilience risk. Thus, if the threshold is reached or exceeded (e.g., observed watchdog behavior is determined to have a 60% statistical probability that it is not consistent with normal operation of the node), then, in at least one embodiment, the HME may continue monitoring for a short period to avoid hysteresis. For example, this could be an additional monitoring period of a few seconds or minutes. If subsequent heartbeat messages do not arrive within the expected time (e.g., according to reference template 81), the resilience threshold may be acted upon… At 1302, a network is monitored for heartbeat messages over a period of time or monitoring period. At 1304, a statistical probability that a number of heartbeat messages received from a node are the result of abnormal behavior is determined. This determination can be made based on a comparison of a reference template and a machine learning template that contains data from the observed heartbeat messages. In some instances the reference template can indicate only an amount and frequency of heartbeat messages that should be received for a particular node. In other instances, the reference template can indicate certain information related to a node that should be reported in the heartbeat messages (e.g., temperature, resource utilization, power utilization/battery life/use, flash burn rate, bus contention, network interface card (NIC) utilization, buffer utilization, dropped packets, health reports, etc.)). However, Smith does not explicitly disclose the limitations of Claim 7 which states performing name-based data validation of the data points; responsive to the data points passing the name-based data validation, recording the data points in a data store. Howarth though, with the teachings of Smith, teaches of performing name-based data validation of the data points (Howarth: Para 0065 via an authentication process will be applied to at least some packets. In some implementations, the authentication process involves comparing a hashed portion of the heartbeat that includes a secret from a device with what the heartbeat server expected. The secret authorized for the device that sent the heartbeat, e.g., by referencing a database, a lookup table, etc is used by the server to generate a hash value. If the correct secret was included in the heartbeat from the device, it will be assumed that the device indicated by the identification information (e.g., an EPC code) in the heartbeat was the device that transmitted the heartbeat. The authorization process is preferably not applied to all packets. For example, an authorization process may be applied to every M packets, where M is a predetermined number (50, 100, 1,000, 10,000, or any appropriate number). Heartbeats purportedly from devices involving critical operations, valuable items, etc., may be authenticated more often than heartbeats that appear to be from other devices); responsive to the data points passing the name-based data validation, recording the data points in a data store (Howarth: Para 0064 via it is determined whether heartbeat packets have been received from devices 1 through N (e.g., by a syslog server). In some preferred embodiments, it will be determined whether each heartbeat packet has been received within a predetermined time. Preferably, the packets' receipt will be determined during an ongoing process, rather than at one particular phase of method 300. In some implementations, received packets are archived and in other implementations received packets are discarded. In yet other implementations, certain types of heartbeat packets (e.g., those containing information about device or network status) are stored and other types of heartbeat packets are discarded). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith with the teachings of Howarth in order to have performing name-based data validation of the data points; responsive to the data points passing the name-based data validation, recording the data points in a data store. The motivations behind this being to incorporate the teachings of monitoring the status of networked devices as taught by Howarth. Furthermore, combining prior art elements according to known methods will yield predictable results. Smith/Howarth teaches the limitations of Claim 8 which state further comprising, responsive to the data points failing the name-based data validation, deleting the data points (Howarth: Para 0065 via In preferred implementations, an authentication process will be applied to at least some packets. In some implementations, the authentication process involves comparing a hashed portion of the heartbeat that includes a secret from a device with what the heartbeat server expected. The secret authorized for the device that sent the heartbeat, e.g., by referencing a database, a lookup table, etc is used by the server to generate a hash value. If the correct secret was included in the heartbeat from the device, it will be assumed that the device indicated by the identification information (e.g., an EPC code) in the heartbeat was the device that transmitted the heartbeat. The authorization process is preferably not applied to all packets. For example, an authorization process may be applied to every M packets, where M is a predetermined number (50, 100, 1,000, 10,000, or any appropriate number)). Smith/Howarth teaches the limitations of Claim 9 which state further comprising, responsive to the data integrity having a value less than a threshold value, performing remedial actions regarding the data handling facility (Smith: Para 0033, 0117 via Embodiments can also include a health monitoring engine (HME) that receives heartbeat messages from nodes (e.g., monitored devices 30-1 through 30-M, network devices 40 and 40-1 through 40-N) within an IoT network. Heartbeat messages are a type of watchdog message that contain additional information. For example, heartbeat messages may contain a device identifier (‘device ID’), a local time stamp, a next heartbeat time, a node health and diagnostic information, and a watchdog report from a subordinate node or network of nodes (e.g., subnet). The HME can use machine learning (ML) techniques to form a reference template by monitoring actual heartbeat messages during a training period and by being informed of expected watchdog messages or a schedule of watchdog messages using a data model… FIG. 11 provides additional possible details of health monitoring engine 85 in at least one embodiment. Health monitoring engine (HME) 85 may be provisioned in network device 80, which includes at least one processor 87 and at least one memory element 89. HME 85 can include a reference template 81, a machine learning (ML) analysis engine 82, a machine learning (ML) template 83, and a response module 84. Reference template 81 can be constructed during a training period using a data model description of expected behavior 94 of a watchdog message traffic system, in addition to monitoring actual observed watchdog behavior 92 (i.e., heartbeat message traffic) during training. Reference template 81 can be used during normal operation where HME 85 evaluates variances and thresholds that may trigger a pro-active response and prescriptive response to improve network resilience properties prior to node or network failures. For example, ML analysis engine 82 can compute a threshold matching function that corrects for hysteresis and then dispatch a resiliency response action 98 via response module 84. Resiliency response actions may include, but are not limited to, notifications, repairs, and deployment of network redundancy in the form of redundant nodes, routers, routes and other network infrastructure). Smith/Howarth teaches the limitations of Claim 10 which state wherein the remedial action includes interrogating a device of the data handling facility to determine a status of the device (Smith: Para 0124 via Other resiliency response actions may include, but are not limited to, notifications, repairs (e.g., a software or firmware patch or update), deployment of network redundancy in the form of, for example, redundant nodes, routers, routes, and other network infrastructure, physical replacement of the device (e.g., dispatch a human, drone, or autonomous vehicle to physically replace the device), or device reset. In one example, a notification includes generating an alert naming the node or subnet exhibiting abnormal watchdog behavior). Smith/Howarth teaches the limitations of Claim 11 which state wherein the remedial action includes power cycling a device of the data handling facility (Smith: Para 0124 via Other resiliency response actions may include, but are not limited to, notifications, repairs (e.g., a software or firmware patch or update), deployment of network redundancy in the form of, for example, redundant nodes, routers, routes, and other network infrastructure, physical replacement of the device (e.g., dispatch a human, drone, or autonomous vehicle to physically replace the device), or device reset. In one example, a notification includes generating an alert naming the node or subnet exhibiting abnormal watchdog behavior). Smith/Howarth teaches the limitations of Claim 12 which state further comprising determining that a second node has an inactive status responsive to not receiving any data points from the node in a 24- hour period of time (Howarth: Para 0066 via If an expected packet is not received within a predetermined time, in some implementations a notification procedure will then ensue (step 320). For example, a communication (e.g., an email, voice mail, text message, etc.) may be sent to a network administrator regarding the non-responsive device (e.g., "No heartbeat from RFID reader 3313 at warehouse 111"). In other implementations, a notification will be sent only after a predetermined number of expected packets have not been received from a non-responsive device. In some implementations, a non-responsive device will be instructed to reboot). Smith/Howarth teaches the limitations of Claim 13 which state wherein the node has a standardized naming format, the node name including an identifier of the data handling facility, a device category of the node, an identifier of a room in which the node is located within the data handling facility, an identifier of a row of network equipment racks in which the node is located within the room, a position of the node within the row, and an identifier of a device within the network equipment rack (Howarth: Para 0048, 0071, 0073, 0077-0080 via a customized packet generally within the syslog protocol is used to transmit a "heartbeat" from each of a plurality of networked devices to a syslog server. In order to overcome the problems noted above, the heartbeat includes identification information regarding the device, e.g., the unique electronic product code ("EPC") of the device. The packet preferably includes other identification and/or authentication information, such as a shared secret and time data, which may be hashed with the identification information. The heartbeat may include information indicating the health, accuracy and/or reliability of the device and/or of the network that includes the device…A change may also be indicated by information contained in the heartbeat itself. As noted elsewhere, heartbeats may include various types of information regarding the device that transmitted the heartbeat, the network in which the device is located, or other information. If information in the heartbeat suggests, for example, that the device may be malfunctioning, the device may be instructed to provide heartbeats with other diagnostic information…FIG. 4 illustrates one exemplary heartbeat format for implementing some aspects of the invention. It will be appreciated by those of skill in the art that other formats may be used for implementing the present invention. According to RFC 3164, "[t]he payload of any IP packet that has a UDP destination port of 514 MUST be treated as a syslog message." Accordingly, even those implementations of the invention that are based in part on syslog need not be in a particular format. Nonetheless, implementations of the present invention that use syslog are preferably formatted in the manner suggested by RFC 3164…Some heartbeat packets 400 may serve only to identify the device that transmitted the heartbeat and the time that the heartbeat was transmitted. However, heartbeat packet 400 (or packets having other formats) may contain other types of information. Preferably, this information is set forth according to standardized option fields having predetermined formats. One such exemplary format is CPU_Memory_Disk Utilization. The CPU field may contain, for example, the average percent utilization of the CPU since the time that the last heartbeat was sent and The Memory and Disk Utilization fields could contain information regarding their respective utilizations…heartbeat packet 400 contains LAN interface and/or IP packet statistics, preferably in a predetermined format. For example, such packets could include information regarding "receiver not ready" conditions, dropped packets or frames, megaframes, wrong format of packets or frames, etc…heartbeat packet 400 contains device Uptime information, preferably in a predetermined format…the heartbeat may contain information specific to a particular vendor or device. Such information could be used for error reporting, product differentiation, or other purposes. If the device is an RFID reader, the heartbeat could include information regarding the performance of the reader, e.g., the current antenna set-up, interference information, incomplete reads, percent of "good" reads, multipath information, etc.). Smith/Howarth teaches the limitations of Claim 14 which state further comprising performing a regular expression check of the node name to perform the name-based data validation (Howarth: Para 0023 via The first packet may be a syslog packet and may include encrypted authentication information. The computer program may include instructions for validating the first packet according to the authentication information. The first packet may contain information regarding the utilization of the first RFID device, information regarding a local area network that includes the first RFID device, information regarding Internet Protocol packet statistics, information specific to the first RFID device (e.g., information regarding a radio frequency interface of the first RFID device) and/or information specified by a vendor of the first RFID device). Smith/Howarth teaches the limitations of Claim 27 which state further comprising: receiving second data points from a second node of a second data handling facility, the second data points indicating the second node as a second reporting node (Smith: Para 0033 via Embodiments can also include a health monitoring engine (HME) that receives heartbeat messages from nodes (e.g., monitored devices 30-1 through 30-M, network devices 40 and 40-1 through 40-N) within an IoT network. Heartbeat messages are a type of watchdog message that contain additional information. For example, heartbeat messages may contain a device identifier (‘device ID’), a local time stamp, a next heartbeat time, a node health and diagnostic information, and a watchdog report from a subordinate node or network of nodes (e.g., subnet). The HME can use machine learning (ML) techniques to form a reference template by monitoring actual heartbeat messages during a training period and by being informed of expected watchdog messages or a schedule of watchdog messages using a data model); performing name-based data validation of the second data points (Howarth: Para 0065 via an authentication process will be applied to at least some packets. In some implementations, the authentication process involves comparing a hashed portion of the heartbeat that includes a secret from a device with what the heartbeat server expected. The secret authorized for the device that sent the heartbeat, e.g., by referencing a database, a lookup table, etc is used by the server to generate a hash value. If the correct secret was included in the heartbeat from the device, it will be assumed that the device indicated by the identification information (e.g., an EPC code) in the heartbeat was the device that transmitted the heartbeat. The authorization process is preferably not applied to all packets. For example, an authorization process may be applied to every M packets, where M is a predetermined number (50, 100, 1,000, 10,000, or any appropriate number). Heartbeats purportedly from devices involving critical operations, valuable items, etc., may be authenticated more often than heartbeats that appear to be from other devices); responsive to the second data points passing the name-based data validation, recording the second data points in the data store (Howarth: Para 0064 via it is determined whether heartbeat packets have been received from devices 1 through N (e.g., by a syslog server). In some preferred embodiments, it will be determined whether each heartbeat packet has been received within a predetermined time. Preferably, the packets' receipt will be determined during an ongoing process, rather than at one particular phase of method 300. In some implementations, received packets are archived and in other implementations received packets are discarded. In yet other implementations, certain types of heartbeat packets (e.g., those containing information about device or network status) are stored and other types of heartbeat packets are discarded); and determining data integrity of the second data handling facility (Smith: Para 0122, 0130 via HME 85 can determine a threshold of missing heartbeats that constitutes a resiliency risk. The statistical probability can be compared to the threshold to determine whether a resiliency risk exists in the network. For example, in at least one embodiment, a threshold could be a 50% resilience risk. Thus, if the threshold is reached or exceeded (e.g., observed watchdog behavior is determined to have a 60% statistical probability that it is not consistent with normal operation of the node), then, in at least one embodiment, the HME may continue monitoring for a short period to avoid hysteresis. For example, this could be an additional monitoring period of a few seconds or minutes. If subsequent heartbeat messages do not arrive within the expected time (e.g., according to reference template 81), the resilience threshold may be acted upon… At 1302, a network is monitored for heartbeat messages over a period of time or monitoring period. At 1304, a statistical probability that a number of heartbeat messages received from a node are the result of abnormal behavior is determined. This determination can be made based on a comparison of a reference template and a machine learning template that contains data from the observed heartbeat messages. In some instances the reference template can indicate only an amount and frequency of heartbeat messages that should be received for a particular node. In other instances, the reference template can indicate certain information related to a node that should be reported in the heartbeat messages (e.g., temperature, resource utilization, power utilization/battery life/use, flash burn rate, bus contention, network interface card (NIC) utilization, buffer utilization, dropped packets, health reports, etc.)). Smith/Howarth teaches the limitations of Claim 30 which state wherein the data points comprise at least one of a status update, a heartbeat signal, or a measurement (Howarth: Para 0013 via Methods and devices are provided for determining the status of a networked device, e.g., a networked RFID device. In some embodiments of the invention, a customized packet is used to transmit a "heartbeat" from each of a plurality of networked devices to a server. Some such embodiments use a customized syslog packet for the heartbeats. The heartbeat includes identification information regarding the device, e.g., the unique electronic product code ("EPC") of the device. The identification information may include other identification and/or authentication information, such as a shared secret and time data, which may be hashed with the identification information. The heartbeat may include information indicating the health, accuracy and/or reliability of the device and/or of the network that includes the device). Smith/Howarth teaches the limitations of Claim 31 which state wherein the node comprises a sensor (Smith: Para 0025 via Examples of nodes in a IoT network include embedded devices and sensors in, for example, medical devices, automobiles, transportation infrastructure, energy production and delivery infrastructure, factories, schools, homes, farms, enterprises, government entities, etc. Other nodes in the IoT network can include more traditional computing systems such as mobile devices (e.g., laptops, smart phones, tablets, gaming systems, automobile infotainment systems, etc.), computing devices (e.g., desktop, etc.), network elements (e.g., routers, gateways, switches, appliances, servers, etc.), and many more). Smith/Howarth teaches the limitations of Claim 32 which state wherein the remedial actions comprise one or more of power cycling at least one node, resetting a network connection of at least one node, requesting at least one node, network element, or other device to report its status, or power cycling a network device for which the node is monitoring power (Smith: Para 0124 via Other resiliency response actions may include, but are not limited to, notifications, repairs (e.g., a software or firmware patch or update), deployment of network redundancy in the form of, for example, redundant nodes, routers, routes, and other network infrastructure, physical replacement of the device (e.g., dispatch a human, drone, or autonomous vehicle to physically replace the device), or device reset. In one example, a notification includes generating an alert naming the node or subnet exhibiting abnormal watchdog behavior) . 07-21-aia AIA Claim (s) 21-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smith et al. (US 2019/0171510 A1) in view of Howarth et al. (US 2006/0033606 A1) further in view of Gardner et al. (US 2007/0234427 A1) . Regarding Claim 21, while Smith/Howarth teaches the limitations of Claim 7, it does not explicitly disclose the limitations of Claim 21 which state further comprising cross-referencing an inventory management system to perform an inventory-based data validation of the data points. Gardner though, with the teachings of Smith/Howarth, teaches of further comprising cross-referencing an inventory management system to perform an inventory-based data validation of the data points (Gardner: Para 0054, 0063 via If an ESN has not been assigned to the computer (i.e., the last 4 digits are 0's), (or if an earlier assigned ESN is misidentified, e.g., as a result of tampering), it means that either it is a new installation, or the hard drive has been wiped and the persistence algorithm from BIOS has restored the agent. If ESN assignment is needed, the right hand side of the flow diagram in FIG. 2 is undertaken, and an ESN activation process is executed. For example, in case of a stolen device, the ESN written on the hard drive my have been erased or tampered with, so a reverse lookup is done using the key data points and an ESN is found and re-written to the hard drive. This reverse lookup is also used to match the device to its rightful owner. In connection with the ESN activation process, using the data points collected by the device attribute collection application, the inventory record is validated against the existing inventory records stored in the inventory record database 24…Specifically, prior to matching the data points, an exception table is looked up to see if the data point is in the exception table. This is to ensure known non-unique data points are not used in ESN determination. Some generic no-name devices are known to have either blank serial numbers or a non-unique serial number that exists on multiple devices. A list of these known non-unique identifiers is maintained in the exception table. If there is an exception, the data point is ignored, and the next item of data point is matched. If a particular data point item is not on the exception list, a determination is made as to how many existing inventory records are found having such data point item. If instead no existing inventory record or multiple existing inventory records are found, that particular data point item is ignored and the next item matched. Any multiple records found in the process may be "cleaned" to remove or reduce issues for future inventory record validation. If only one existing inventory record is found, then the inventory record corresponding to the collected data point item is deemed to be found and a match of the device in relation to such existing inventory record is deemed to have been achieved. The ESN of the existing inventory record is checked to determine if it is in a holding account. If not in the holding account, such ESN is assigned to the device (e.g., written to the device hard-drive) and the inventory record for the device is updated). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith/Howarth with the teachings of Gardner in order to have further comprising cross-referencing an inventory management system to perform an inventory-based data validation of the data points. The motivations behind this being to incorporate the teachings of identifying and collecting key data of electronic devices as taught by Gardner. Furthermore, combining prior art elements according to known methods will yield predictable results and in addition to being in the same CPC class, the teachings, suggestions, and motivations in this prior art would have led one of ordinary skill to modify the prior art reference or combine prior art reference teachings to arrive at the claimed invention. Regarding Claim 22, Smith/Howarth/Gardner teaches the limitations of Claim 22 which states wherein performing the inventory-based data validation of the data points includes: determining, based on the inventory management system, an expected inventory of the data handling facility; determining, based on the data store, a reported inventory of the data handling facility based on nodes of the data handling facility for which data points have been received; comparing the expected inventory to the reported inventory; and responsive to a mismatch between the expected inventory and the reported inventory, performing one or more remedial actions regarding the data handling facility (Gardner: Para 0063 via Specifically, prior to matching the data points, an exception table is looked up to see if the data point is in the exception table. This is to ensure known non-unique data points are not used in ESN determination. Some generic no-name devices are known to have either blank serial numbers or a non-unique serial number that exists on multiple devices. A list of these known non-unique identifiers is maintained in the exception table. If there is an exception, the data point is ignored, and the next item of data point is matched. If a particular data point item is not on the exception list, a determination is made as to how many existing inventory records are found having such data point item. If instead no existing inventory record or multiple existing inventory records are found, that particular data point item is ignored and the next item matched. Any multiple records found in the process may be "cleaned" to remove or reduce issues for future inventory record validation. If only one existing inventory record is found, then the inventory record corresponding to the collected data point item is deemed to be found and a match of the device in relation to such existing inventory record is deemed to have been achieved. The ESN of the existing inventory record is checked to determine if it is in a holding account. If not in the holding account, such ESN is assigned to the device (e.g., written to the device hard-drive) and the inventory record for the device is updated). Regarding Claim 23, Smith/Howarth/Gardner teaches the limitations of Claim 23 which states wherein the one or more remedial actions include interrogating a device of the data handling facility to determine a status of the device (Smith: Para 0124 via Other resiliency response actions may include, but are not limited to, notifications, repairs (e.g., a software or firmware patch or update), deployment of network redundancy in the form of, for example, redundant nodes, routers, routes, and other network infrastructure, physical replacement of the device (e.g., dispatch a human, drone, or autonomous vehicle to physically replace the device), or device reset. In one example, a notification includes generating an alert naming the node or subnet exhibiting abnormal watchdog behavior. Another type of notification includes marking a node such as a monitored device or subnet network device (e.g., router) as LOST). Regarding Claim 24, Smith/Howarth/Gardner teaches the limitations of Claim 24 which states wherein the one or more remedial actions include power cycling a device of the data handling facility (Smith: Para 0124 via Other resiliency response actions may include, but are not limited to, notifications, repairs (e.g., a software or firmware patch or update), deployment of network redundancy in the form of, for example, redundant nodes, routers, routes, and other network infrastructure, physical replacement of the device (e.g., dispatch a human, drone, or autonomous vehicle to physically replace the device), or device reset. In one example, a notification includes generating an alert naming the node or subnet exhibiting abnormal watchdog behavior. Another type of notification includes marking a node such as a monitored device or subnet network device (e.g., router) as LOST). Regarding Claim 25, Smith/Howarth/Gardner teaches the limitations of Claim 25 which states wherein the node has a standardized naming format, the node name including an identifier of the data handling facility, a device category of the node, an identifier of a room in which the node is located within the data handling facility, an identifier of a row of network equipment racks in which the node is located within the room, a position of the node within the row, and an identifier of a device within the network equipment rack (Howarth: Para 0048, 0071, 0073, 0077-0080 via a customized packet generally within the syslog protocol is used to transmit a "heartbeat" from each of a plurality of networked devices to a syslog server. In order to overcome the problems noted above, the heartbeat includes identification information regarding the device, e.g., the unique electronic product code ("EPC") of the device. The packet preferably includes other identification and/or authentication information, such as a shared secret and time data, which may be hashed with the identification information. The heartbeat may include information indicating the health, accuracy and/or reliability of the device and/or of the network that includes the device…A change may also be indicated by information contained in the heartbeat itself. As noted elsewhere, heartbeats may include various types of information regarding the device that transmitted the heartbeat, the network in which the device is located, or other information. If information in the heartbeat suggests, for example, that the device may be malfunctioning, the device may be instructed to provide heartbeats with other diagnostic information…FIG. 4 illustrates one exemplary heartbeat format for implementing some aspects of the invention. It will be appreciated by those of skill in the art that other formats may be used for implementing the present invention. According to RFC 3164, "[t]he payload of any IP packet that has a UDP destination port of 514 MUST be treated as a syslog message." Accordingly, even those implementations of the invention that are based in part on syslog need not be in a particular format. Nonetheless, implementations of the present invention that use syslog are preferably formatted in the manner suggested by RFC 3164…Some heartbeat packets 400 may serve only to identify the device that transmitted the heartbeat and the time that the heartbeat was transmitted. However, heartbeat packet 400 (or packets having other formats) may contain other types of information. Preferably, this information is set forth according to standardized option fields having predetermined formats. One such exemplary format is CPU_Memory_Disk Utilization. The CPU field may contain, for example, the average percent utilization of the CPU since the time that the last heartbeat was sent and The Memory and Disk Utilization fields could contain information regarding their respective utilizations…heartbeat packet 400 contains LAN interface and/or IP packet statistics, preferably in a predetermined format. For example, such packets could include information regarding "receiver not ready" conditions, dropped packets or frames, megaframes, wrong format of packets or frames, etc…heartbeat packet 400 contains device Uptime information, preferably in a predetermined format…the heartbeat may contain information specific to a particular vendor or device. Such information could be used for error reporting, product differentiation, or other purposes. If the device is an RFID reader, the heartbeat could include information regarding the performance of the reader, e.g., the current antenna set-up, interference information, incomplete reads, percent of "good" reads, multipath information, etc.). Regarding Claim 26, Smith/Howarth/Gardner teaches the limitations of Claim 26 which states further comprising performing a regular expression check of the node name to perform the name-based data validation (Howarth: Para 0023 via The first packet may be a syslog packet and may include encrypted authentication information. The computer program may include instructions for validating the first packet according to the authentication information. The first packet may contain information regarding the utilization of the first RFID device, information regarding a local area network that includes the first RFID device, information regarding Internet Protocol packet statistics, information specific to the first RFID device (e.g., information regarding a radio frequency interface of the first RFID device) and/or information specified by a vendor of the first RFID device) . 07-21-aia AIA Claim (s) 28-29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smith et al. (US 2019/0171510 A1) in view of Howarth et al. (US 2006/0033606 A1) further in view of Ramachandran et al. (US 2023/0230010 A1) . Regarding Claim 28, while Smith/Howarth teaches the limitations of Claim 27, it does not explicitly disclose the limitations of Claim 28 which state further comprising comparing the data integrity of the first data handling facility to the data integrity of the second data handling facility. Ramachandran though, with the teaching of Smith/Howarth, teaches the limitations of Claim 28 which state further comprising comparing the data integrity of the first data handling facility to the data integrity of the second data handling facility (Ramachandran: Para 0011 via an infrastructure health score for an infrastructure service utilized by an organization may be determined for the organization and an overall health score, based on the various infrastructure health scores of the organization, may be determined for the organization. In order to maximize performance of the infrastructure services, changes in how the services are utilized (e.g., change in message complexity, change in message volume, etc.) may be evaluated and resulting infrastructure health scores and overall health scores may be compared between a target organization and a number of control groups of organizations having similar scores as the target organization. For example, Bayesian market matching causal inferences may be used to assess and prioritize significant impact to the target organization's service health due to changes compared to similar causal inferences to other organizations in the number of control groups without the changes. In this way, an offering utilized by an organization may be enhanced by maximizing performance of the various infrastructure services of the offering for the organization based on comparisons with peer organizations). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith/Howarth with the teachings of Ramachandran in order to have further comprising comparing the data integrity of the first data handling facility to the data integrity of the second data handling facility. The motivations behind this being to incorporate the teachings of quantifying an infrastructure service health as a score and optimizing performance of the infrastructure service based on benchmarks of dynamically identified control groups as taught by Ramachandran. Furthermore, in addition to being in the same CPC class, the teachings, suggestions, and motivations in this prior art would have led one of ordinary skill to modify the prior art reference or combine prior art reference teachings to arrive at the claimed invention. Smith/Howarth/Ramachandran teaches the limitations of Claim 29 which state responsive to the data integrity having a value less than a threshold value, performing one or more remedial actions regarding the second data handling facility (Smith: Para 0033, 0117 via Embodiments can also include a health monitoring engine (HME) that receives heartbeat messages from nodes (e.g., monitored devices 30-1 through 30-M, network devices 40 and 40-1 through 40-N) within an IoT network. Heartbeat messages are a type of watchdog message that contain additional information. For example, heartbeat messages may contain a device identifier (‘device ID’), a local time stamp, a next heartbeat time, a node health and diagnostic information, and a watchdog report from a subordinate node or network of nodes (e.g., subnet). The HME can use machine learning (ML) techniques to form a reference template by monitoring actual heartbeat messages during a training period and by being informed of expected watchdog messages or a schedule of watchdog messages using a data model… FIG. 11 provides additional possible details of health monitoring engine 85 in at least one embodiment. Health monitoring engine (HME) 85 may be provisioned in network device 80, which includes at least one processor 87 and at least one memory element 89. HME 85 can include a reference template 81, a machine learning (ML) analysis engine 82, a machine learning (ML) template 83, and a response module 84. Reference template 81 can be constructed during a training period using a data model description of expected behavior 94 of a watchdog message traffic system, in addition to monitoring actual observed watchdog behavior 92 (i.e., heartbeat message traffic) during training. Reference template 81 can be used during normal operation where HME 85 evaluates variances and thresholds that may trigger a pro-active response and prescriptive response to improve network resilience properties prior to node or network failures. For example, ML analysis engine 82 can compute a threshold matching function that corrects for hysteresis and then dispatch a resiliency response action 98 via response module 84. Resiliency response actions may include, but are not limited to, notifications, repairs, and deployment of network redundancy in the form of redundant nodes, routers, routes and other network infrastructure) . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Brooks et al. (US 2017/0302557 A1) Any inquiry concerning this communication or earlier communications from the examiner should be directed to TYRONE E SINGLETARY whose telephone number is (571)272-1684. The examiner can normally be reached 9 - 5:30. 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, Beth Boswell can be reached at 571-272-6737. 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. /T.E.S./ Examiner, Art Unit 3625 /BETH V BOSWELL/ Supervisory Patent Examiner, Art Unit 3625 Application/Control Number: 18/596,365 Page 2 Art Unit: 3625 Application/Control Number: 18/596,365 Page 3 Art Unit: 3625 Application/Control Number: 18/596,365 Page 4 Art Unit: 3625 Application/Control Number: 18/596,365 Page 5 Art Unit: 3625 Application/Control Number: 18/596,365 Page 6 Art Unit: 3625 Application/Control Number: 18/596,365 Page 7 Art Unit: 3625 Application/Control Number: 18/596,365 Page 8 Art Unit: 3625 Application/Control Number: 18/596,365 Page 9 Art Unit: 3625 Application/Control Number: 18/596,365 Page 10 Art Unit: 3625 Application/Control Number: 18/596,365 Page 11 Art Unit: 3625 Application/Control Number: 18/596,365 Page 12 Art Unit: 3625 Application/Control Number: 18/596,365 Page 13 Art Unit: 3625 Application/Control Number: 18/596,365 Page 14 Art Unit: 3625 Application/Control Number: 18/596,365 Page 15 Art Unit: 3625 Application/Control Number: 18/596,365 Page 16 Art Unit: 3625 Application/Control Number: 18/596,365 Page 17 Art Unit: 3625 Application/Control Number: 18/596,365 Page 18 Art Unit: 3625 Application/Control Number: 18/596,365 Page 19 Art Unit: 3625 Application/Control Number: 18/596,365 Page 20 Art Unit: 3625 Application/Control Number: 18/596,365 Page 21 Art Unit: 3625 Application/Control Number: 18/596,365 Page 22 Art Unit: 3625 Application/Control Number: 18/596,365 Page 23 Art Unit: 3625 Application/Control Number: 18/596,365 Page 24 Art Unit: 3625 Application/Control Number: 18/596,365 Page 25 Art Unit: 3625 Application/Control Number: 18/596,365 Page 26 Art Unit: 3625 Application/Control Number: 18/596,365 Page 27 Art Unit: 3625 Application/Control Number: 18/596,365 Page 28 Art Unit: 3625 Application/Control Number: 18/596,365 Page 29 Art Unit: 3625
Prosecution Insights