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 .
Claim Objections
Claims 9-13 are objected to because of the following informalities:
The phrase “batch configuration tool and the metering devices employs” is grammatically incorrect because the subject is plural. Therefore, the verb should be “employ” instead of “employs”.
Claims 10-13 depend from claim 9 and they are objected for the same reason.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9, 10, 11, 12, 13, 19, and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 9 and 19, the limitation “polymorphic keys” renders the scope of the claim unclear because the specification does not reasonably clarify what constitutes a “polymorphic” key in the context of the claimed invention. The disclosure describes generating a session-specific key using credentials and a predetermined hash function, which appears consistent with a conventional static session key. However, the claim language suggests a cryptographic mechanism involving “polymorphic” behavior. As such, it is unclear whether the claimed “polymorphic keys” encompass merely session keys or instead require dynamically changing or mutating cryptographic keys.
Claims 10, 11, 12, 13 and 20 are rejected because of their dependency form claims 9 and 19, respectively.
Applicant may overcome this rejection by clarifying the scope of the term “polymorphic keys”, for example by specifying whether the claimed keys are dynamically changing cryptographic keys or merely session-specific keys generated from static inputs. For purposes of examination, it is assumed that the recited polymorphic keys are analogous to the polymorphic keys disclosed by Carlson, US10965710B1 (see below).
Claim Rejections - 35 USC § 101
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.
Claim 1 recites a system for configuring metering devices within a network environment. Accordingly, claim 1 is directed to a machine under 35 U.S.C. 101.
The claim does not recite a mathematical concept because no mathematical relationships, formulas, or calculations are recited. The claim also does not recite a method of organizing human activity, as the claim is directed to technical configuration and operation of networked metering devices rather than commercial, legal, or interpersonal interactions. Further, the claim does not recite a mental process because the simultaneous configuration and pre-configuration of multiple metering devices through a network using a batch configuration tool cannot be practically performed in the human mind or with pen and paper.
Accordingly, claim 1 does not recite a judicial exception under step 2A, Prong One, and therefore claim 1 and all its dependent claims (2-13) are patent eligible under 35 U.S.C. 101. Claim 14 has the same limitations as claim 1, therefore claim 14 and all its dependent claims (15-20) are also patent eligible under 35 U.S.C. 101.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 3 and 14 are rejected under 35 U.S.C. 102 (a) (1) and 102 (a) (2) as being anticipated by Luna A. Koval et al. (US20200389499A1) hereinafter Koval.
Regarding claim 1, Koval teaches a metering device configuration system (intelligent electronic devices such as electric power meters, and a security system that is used to manage security configuration for all users, Abstract) comprising: a plurality of metering devices (plurality of meters ¶ [11], it also refers to these devices as intelligent electronic devices (IEDs), ¶ [2]), including power meters (electric power meters, ¶ [8]) and communication devices ( communication device, ¶ [11]), configured to measure electrical power consumption (IED function includes measuring power consumption such as voltage or current ¶ [5]) and facilitate data transmission (receiving the security configuration (data) for the meter ¶ [11] and receiving notifications, ¶ [13]), respectively; a network facilitating interconnection among (a network for coupling devices and enabling the transmission of data between the devices ¶ [11] and fig. 3, also communication connections 916 in fig. 9) the metering devices (IED fig.3 and fig. 9) and a computing device (computing device fig. 9 or a dedicated computer on a network ¶ [87]); a batch (this software may perform the action on groups, ranges, or all meters automatically, allowing the administrator to perform a single action on all the devices ¶ [88]) configuration tool (administrative security configuration software (510), fig. 5 and ¶ [87] also referred to as management software (720), fig. 7) installed on the computing device (this software is executing on a server or a dedicated computer on a network, Abstract and ¶ [87]. More specifically fig. 9 shows a computing device containing system memory 906 where program modules 908 and applications 920 (such as administrative configuration software) are stored and executed, fig. 9 and ¶ [158]), designed to perform simultaneous configuration ( A dedicated server computer … might have to service dozens or even hundreds of users at the same time ¶ [73]. Moreover, all the devices can have their security configuration changed simultaneously, rather than tediously reconfiguring each one ¶ [9]) of the metering devices through the network (It teaches that the software is used to manage the security configuration for all users across plurality of meters and specifies that the meters are configured to pull the security configuration from the security server via the network or receive notification through the network ¶ [8 & 11]), wherein the batch configuration tool (administrative security configuration software ¶ [87]) is configured to pre-configure the metering devices for immediate operational use upon deployment (the management software is used to configure users and devices in a way that makes the process simpler for administrators and ensures meters are properly configured,¶ [8]. It teaches that users and devices are all managed in one place instead of tediously reconfiguring each one, ¶ [9]. Furthermore, it teaches that a meter is configured to pull the security configuration from the security server ¶ [13] to update its local database ¶ [90], (allowing it to become operational within the enterprise security framework)) by setting predefined parameters (the configuration stored on the server includes a device profile (such as CT/PT ratios, meter hookup types, login time outs, ¶ [93 & 106]) for the meter ¶ [17]. By storing these values in a server-side profile before the meter connects, the tool ensures the device is provisioned with its required operational settings).
Regarding claim 3, Koval teaches the system of claim 1 as set forth with respect to rejection of claim 1, Koval wherein the network is Ethernet network, RS485 network (Communications (124) includes ETHERNET and 485 SERIAL, fig. 1), or Modbus network (Modbus command ¶ [15]).
Regarding claim 14, Koval teaches a method for configuring metering devices (intelligent electronic devices such as electric power meters, and a security system that is used to manage security configuration for all users, Abstract) within a network (a network for coupling devices and enabling the transmission of data between the devices ¶ [11] and fig. 3, also communication connections 916 in fig. 9), the method comprising: interconnecting (interconnected via a network (302), fig. 3) a plurality of metering devices (plurality of meters ¶ [11], it also refers to these devices as intelligent electronic devices (IEDs), ¶ [2]) including power meters(electric power meters, ¶ [8]) (IED fig.3 and IED in fig. 9), and communication devices ( It discloses a system where a plurality of meters each contain their own communication device, ¶ [11]), with a cloud-based (Koval further teaches the use of hosted data services such as cloud data storage or web hosting that acts as an external server to store meter data, ¶ [83], also it teaches external network (302) ¶ [77]) energy management system (it identifies that metering devices are used to manage and control the distribution and consumption of electrical power ¶ [49]) and a computing device (computing device fig. 9 or a dedicated computer on a network ¶ [87]) through a network (interconnected via a network (302), fig. 3, or communication connection (916) fig. 9 ); utilizing a batch (this software may perform the action on groups, ranges, or all meters automatically, allowing the administrator to perform a single action on all the devices ¶ [88]) configuration tool (administrative security configuration software (510), fig. 5 and ¶ [87] also referred to as management software (720), fig. 7) installed on the computing device (this software is executing on a server or a dedicated computer on a network, Abstract and ¶ [87]. More specifically fig. 9 shows a computing device containing system memory 906 where program modules 908 and applications 920 (such as administrative configuration software) are stored and executed, fig. 9 and ¶ [158]) for simultaneous configuration of the metering devices ( A dedicated server computer … might have to service dozens or even hundreds of users at the same time ¶ [73]. Moreover, all the devices can have their security configuration changed simultaneously, rather than tediously reconfiguring each one ¶ [9]) by setting predefined parameters (the configuration stored on the server includes a device profile (such as CT/PT ratios, meter hookup types, login time outs, ¶ [93 & 106]) for the meter ¶ [17]. By storing these values in a server-side profile before the meter connects, the tool ensures the device is provisioned with its required operational settings) for immediate operational use upon deployment (recites automating detection to minimize configuration on the part of the user and simplify device use, avoiding tedious manual setup, ¶ [9]) and enabling cloud access for the metering devices (Koval further teaches the use of hosted data services such as cloud data storage or web hosting that acts as an external server to store meter data, ¶ [83]) to facilitate the transmission of operational data (the meters utilize HTTP tunneling or HTTP push messages to upload the data, ¶ [77 & 78] directly to the cloud-based energy management system (external network (302)) for data aggregation and analysis (it identifies the data as meter’s data or sensed and generated data ¶ [59]). In Koval’s system authenticated meters use HTTP-based push/post ¶[15] methods to transmit their sensed electrical usage data through a firewall to external cloud hosted servers and databases, ¶ [83] and fig. 3)
Claim Rejections - 35 USC § 103
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.
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 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 non-obviousness.
Claims 2, 6, 8, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over by Luna A. Koval et al. (US20200389499A1) hereinafter Koval as applied to claims 1 and claim 14 above, and further in view of AcuLink 810 Manual (V:1.10 Revised : May 2021) hereinafter AcuLink 810.
Regarding claim 2, Koval teaches the system of claim 1 as set forth with respect to rejection of claim 1.
Koval further teaches the use of hosted data services such as cloud data storage or web hosting that acts as an external server to store meter data, ¶ [83] (wherein the system further comprises a cloud-based) and identifies that metering devices are used to manage and control the distribution and consumption of electrical power ¶ [49] (energy management system). It teaches that different external devices, such as servers, PC clients, etc., may access this meter information via a network interface ¶ [59-60]( accessible via the network). Koval further teaches an embodiment where a server aggregates data from the various IEDs ¶ [79] and it discloses program modules that receive this data to perform an analysis ¶ [159] (configured for the aggregation and analysis of data).
Koval teaches that its administrative security configuration software (the batch configuration tool) allows an administrator to configure group, ranges, or all meters automatically from a single interface, ¶ [88].
However, Koval does not disclose that its batch configuration tool is configured to enable cloud access for the metering devices.
AcuLink 810 discloses cloud-based energy management software AcuCloud that is remotely accessible to users (page 30, section 7.1.3). AcuLink 810 collects data from the all Accuenergy meters and other third party devices (page 6, first ¶). It describes a web interface where a user must select AcuCloud Enable (page 125) and it teaches that the tool is configured to enter a token generated by the cloud software into the configuration field to verify and authorize the connection (page 125) (the batch configuration tool is further configured to enable cloud access for the metering devices). It discloses that the gateway is configured to report to the AcuCloud EMS software and it teaches the transmission of time-stamped data from connected devices directly to the cloud platform (page 124) (facilitating the transmission of operational data directly to the cloud-based energy management system). It further teaches once the token has been successfully added, the user will be able to monitor, compare and
trend the data from devices connected to the gateway (page 124) (for enhanced data management and analytical processing).
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention, to apply token-based cloud-enablement method taught by AcuLink 810 to the batch configuration software of Koval to remotely access energy management system via a secure token-based registration.
Regarding claim 6, Koval teaches the system of claim 1 as set forth with respect to rejection of claim 1.
Koval discloses an administrative security configuration software (the batch configuration tool) that maintain security for all meters on a network from a single interface (e.g., a web page) ¶[87] (the batch configuration tool further comprises a user interface (UI)). It teaches that this software (Application (928)) is executed on a computing device (902), fig. 9 and ¶ [158]. It further discloses that the computing device (902) includes output device (914) such as a display ¶ [161] (displayed on the computing device). Koval teaches performing actions on groups, ranges, or all meters automatically via a single action ¶ [88] (enabling a user to configure the metering devices).
However, Koval doesn’t teach enabling a user to configure the metering devices by selecting said devices through a selection box displayed within the UI and utilizing function buttons within the UI to download, upload, delete configuration files, update firmware, and manage remote and cloud access settings.
AcuLink 810 teaches a web interface where all the configuration is done (page 6, ¶ 2). It further teaches that check boxes can be used to select multiple transceivers (meters) to be added to a list or configured simultaneously (page 64, ¶ 2) (enabling a user to configure the metering devices by selecting said devices through a selection box displayed within the UI).
AcuLink 810 discloses an icon that allows users to download the .def format template file (the device configuration) (page 25) and a download button for data logs (page 123, section 12.3) (to download). AcuLink 810 also features an import tab to upload a new device template (page 35, section 7.2.1) and an import configuration button to restore system and device setting (page 52, the figure)( upload). It also provides a delete button to erase all data from the device selected (page 124) and an action icon to delete the template (page 25)( delete).
AcuLink 810 firmware update features a menu to update the firmware of the 810 either manually or remotely (page 136, ¶ 2) (update firmware).
AcuLink 810 supports a remote access by providing an enable/disable toggle and settings to access the interface through an HTTPS web server (page 46, figure)( manage remote access settings).
AcuLink 810 features AcuCloud that allows users to enable and configure settings to send their data to the [cloud] software using a generated token (page 124, section 12.4 & first figure in page 125) (manage cloud access settings).
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention to implement the batch-action logic of Koval using specific, user-friendly UI controls disclosed in the AcuLink 810, because the graphical controls for managing multiple metering devices enables the batch management functionality of Koval to be performed more efficiently and conveniently through a user-friendly interface.
Regarding claim 17, Koval teaches the method of claim 14 as set forth with respect to rejection of claim 14.
Claim 17 further has the same limitations as claim 6 and therefore is rejected for the same reasons set forth with respect to rejection of claim 6.
Regarding claim 8, Koval in view of AcuLink 810 teaches the system of claim 6 as set forth with respect to rejection of claim 6.
While Koval describes the function of exchanging structured device profiles (that includes both security and non-security parameters) over a web-based HTTP link (¶ [17 & 91]), it does not explicitly name “JSON” as the specific data format used.
AcuLink 810 teaches supporting device twins desired properties to synchronize device configuration or conditions. It provides a specific code block that defines these configurations in JSON format, including (Network Time Protocol (NTP) setting: Configuration for multiple NTP servers and time zones (e.g., "ntpServer1": "0.us.pool.ntp.org") [pages 93 & 94]. AcuLink 810 demonstrates a nested JSON structure that is used to synchronize device configuration between the batch configuration tool (the gateway) and the cloud-based energy management system (Azure) (enabling structured and easily interpretable data exchange for device configuration.) [pages 93 & 94].
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the present claimed invention to incorporate the JSON configuration structure from AcuLink 810 into Koval’s batch configuration server to create a management tool that is easier for developers to maintain and for technicians to troubleshoot, as JSON is human-readable and supported by a wide variety of third-party software platforms.
Regarding claim 18, Koval in view of AcuLink 810 teaches the method of claim 17 as set forth with respect to rejection of claim 17.
Claim 18 further has the same limitations as claim 8 and therefore is rejected for the same reasons set forth with respect to rejection of claim 8.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over by Luna A. Koval et al. (US20200389499A1) hereinafter Koval in view of AcuLink 810 Manual (V:1.10 Revised : May 2021) hereinafter AcuLink 810 as applied to claim 6 above, and further in view of Simon Leblond et al. (US20160234186A1) hereinafter Leblond.
Regarding claim 7, Koval in view of AcuLink 810 teaches the system of claim 6 as set forth with respect to rejection of claim 6.
Koval in view of AcuLink 810 further teaches UI feature AcuCloud to manage the cloud access setting using a generated token (AcuLink 810, page 124, section 12.4 & first figure in page 125) and it teaches that meters communicating with a server via a firewall and router to ensure data transfer (Koval, fig. 3 & ¶ [77]).
Koval doesn’t explicitly teach the UI further enables testing of cloud access for the metering devices by sending a predefined data packet to the cloud-based energy management system to verify the communication link and confirm the registration status of the metering devices.
AcuLink 810 teaches a UI section for AcuCloud (cloud energy management) that includes a dedicated “Test Cloud access” button (page 127, 2nd figure) (UI further enables testing of cloud access for the metering devices). The “Test Cloud access” button is designed specifically to verify the gateway can successfully reach the cloud software (page 127) ( to verify the communication link).It teaches a registration process where adding a device to the cloud returns a token that acts as verification when sending data from gateway (page 124, section 12.4, ¶ 2)( confirm the registration status of the metering devices.). The test button uses this token to confirm the device is authorized/registered in the cloud database.
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention to incorporate the test AcuCloud button and token based registration verification as taught by AcuLink 810 into Koval’s administrative tool (that manages security and configuration across a fleet of meters to reduce manual labor), to provide a technician with immediate diagnostic feedback and prevent the need to manually verify each meter’s connectivity after batch update.
Koval in view of AcuLink 810 teaches the existence of a test cloud access button, it describes the result of the action (verifying the link) rather than the technical form of the data being sent. The combination doesn’t explicitly disclose sending a predefined data packet to the cloud to run the test.
Leblond teaches the technical mechanism of this test by disclosing that a management device generates and transmits a registration request to the cloud server ¶ [45] (by sending a predefined data packet). Cloud server upon receiving the test/registration packet, sends a registration response back to the tool, this response indicates whether the metering device has been successfully saved in the cloud database ¶[46].
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention to use a predefined registration packet, as taught by Leblond, for the test button as taught by Koval in view of AcuLink 810 to prove that the communication link is physically active while simultaneously verifying that the devices’ s unique credentials are correctly recognized by the cloud database.
Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over by Luna A. Koval et al. (US20200389499A1) hereinafter Koval as applied to claims 1 and 14 above, and further in view of Erran Kagan et al. (US20130205022A1) hereinafter Kagan.
Regarding claim 4, Koval teaches the system of claim 1 as set forth with respect to rejection of claim 1, wherein the predefined parameters (management software uses a device profile for the meter consist of both security and non-security parameters, ¶ [17]) include IP addresses (an administrator may use the management software to configure Meter A (702) and Meter B (704) with the security server's parameters, e.g., an IP address ¶ [116]), and communication protocols (it lists protocols used by metering devices as ETHERNET, 485 SERIAL and USB (fig. 1 block (124)). It further discloses that the system utilizes standard industry protocols such as Modbus, TCP/IP and HTTP for device interaction and management ¶ [15 & 61]).
Koval teaches that its system manages non-security configuration parameters used to control meter functions like measuring power consumption, but it does not explicitly disclose data collection intervals as a predefined parameter.
Kagan teaches that an intelligent electronic device (IED) or meter may be programmed to periodically communicate to the server at predefined intervals ¶ [94] (data collection intervals).
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention, to include the specific data collection interval configuration parameters, as taught by Kagan, into the batch configuration disclosed by Koval to provide uniform and centrally manage timing for meter data acquisition, thereby improving the efficiency and consistency of networked energy monitoring operations.
Regarding claim 15, Koval teaches the method of claim 14, as set forth with respect to rejection of claim 14.
Koval further teaches wherein the network comprises one of an Ethernet network, an RS485 network (Communications (124) includes ETHERNET and 485 SERIAL, fig. 1), or a Modbus network (Modbus command ¶ [15]), and wherein setting predefined parameters (management software uses a device profile for the meter consist of both security and non-security parameters, ¶ [17]) includes configuring IP addresses (an administrator may use the management software to configure Meter A (702) and Meter B (704) with the security server's parameters, e.g., an IP address ¶ [116]), and communication protocols for the metering devices (it lists protocols used by metering devices as ETHERNET, 485 SERIAL and USB (fig. 1 block (124)). It further discloses that the system utilizes standard industry protocols such as Modbus, TCP/IP and HTTP for device interaction and management ¶ [15 & 61]).
Koval teaches that its system manages non-security configuration parameters used to control meter functions like measuring power consumption, but it does not explicitly disclose data collection intervals as a predefined parameter.
Kagan teaches that an intelligent electronic device (IED) or meter may be programmed to periodically communicate to the server at predefined intervals ¶ [94] (data collection intervals).
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the present claimed invention, to include the specific data collection interval configuration parameters, as taught by Kagan, into the batch configuration disclosed by Koval to provide uniform and centrally manage timing for meter data acquisition, thereby improving the efficiency and consistency of networked energy monitoring operations.
Claims 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over by Luna A. Koval et al. (US20200389499A1) hereinafter Koval as applied to claims 1 and 14 above, and further in view of David Anderson et al. (US20170279630A1) hereinafter Anderson.
Regarding claim 5, Koval teaches the system of claim 1 as set forth with respect to rejection of claim 1.
Koval further teaches that the administrative security configuration software (the batch configuration tool) is configured to broadcast a UDP (user datagram protocol) message (facilitating the identification of the metering devices by broadcasting a query) to the plurality of meters (metering devices) to initiate configuration ¶ [16 & 91]. Koval further discloses that the security server may maintain a mapping of meters ¶ [90] and it may create report that lists all meters a user can access ¶ [106] (populating a device list).
While UDP is the underlying transport for mDNS, Koval does not explicitly teach employing mDNS protocol. Koval also doesn’t teach populating a list of devices based on their response.
Koval does not teach the batch configuration tool employs a multicast DNS (mDNS) protocol to discover the metering devices on the network, facilitating the identification of the metering devices by broadcasting an mDNS query and populating a device list based on responses from the metering devices.
Anderson teaches that its system controllers (it explicitly identifies that the devices managed within its load control environment include power monitoring devices, energy meter, etc. ¶ [50]) include an mDNS client or mDNS server. It recites that through mDNS the system controllers on the LAN maybe used to discover other system controllers by requesting, for example, same SSID, ¶ [87] (employs a multicast DNS (mDNS) protocol to discover devices on the network). It further teaches that the mDNS client may generate mapping information, which may distinguish each system controller from other system controllers, ¶ [87]. More specifically it provides an example in fig. 3D where the mapping information generated by mDNS identifies controllers by their wired IP addresses (facilitating the identification of the metering devices). Anderson teaches that the network device (the batch tool) may transmit signals (e.g., probe frames) to actively search for system controllers ¶ [100] and it also teaches that the network device may connect to the system controllers by scanning the load control system for system controllers broadcasting their SSIDs ¶ [16] (by broadcasting an mDNS query).
Anderson further discloses that a target system controller may reply with an associate signal ¶ [100] (responses from the metering devices). It teaches that the system uses information received from these discovered devices to generate mapping information 310 ¶ [87] and recites that the tool then provides the user with a webpage that includes a listing of system controllers to be configured in a list, a table, etc. ¶ [103-104] (populating a device list based on responses).
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the present claimed invention to integrate the multicast DNS protocol with the architecture described in Koval to enable automated discovery and to enhance network visibility within an enterprise metering environment. While Koval utilizes UDP broadcasting to notify a plurality of meters that security updates are available, mDNS provides a more robust implementation of this logic. Instead of Koval’s general broadcast, an mDNS query can be directed to specific device types or services (power meters) that are listing on a relevant port. This allows for a more efficient discovery process within a dense IoT environment.
Regarding claim 16, Koval teaches the method of claim 14 as set forth with respect to rejection of claim 14.
Claim 16 further has the same limitations as claim 5 and therefore is rejected for the same reasons set forth with respect to rejection of claim 5.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over by Luna A. Koval et al. (US20200389499A1) hereinafter Koval as applied to claims 1 and 14 above, and further in view of Albert Henry Carlson et al. (US10965710B1) hereinafter Carlson.
Regarding claim 9, Koval teaches the system of claim 1 as set forth with respect to rejection of claim 1.
Koval teaches the system architecture and the necessity of secure key exchange. Koval discloses a protocol for authenticating a meter that involves generating a private key and a public key at the meter and transmitting that public key to the security server (wherein the batch configuration tool and the metering devices employ a secure key exchange protocol) ¶ [32]. It further teaches using a Secure Connection (such as an encrypted SSL or TLS tunnel) to mitigate eavesdropping by an attacker and prevent the injection of faked commands and queries ¶ [124]. It also teaches that the meters themselves need to be verified when connecting to the security server to ensure that an attacker cannot interact with the management system directly without restriction ¶ [117] (ensuring the confidentiality of the metering devices scanning process).
While Koval describes the need for secure communication and the architectural framework for key exchange, it does not teach that its key exchange protocol utilizes polymorphic keys.
Carlson teaches a Diffie-Hellman Key Exchange (employ a secure key exchange protocol) used to establish a shared secret for secure communication between network assets (Col. 5, ll. 40-42). It discloses the CipherLoc Polymorphic Key Progression Algorithm and CipherLoc Polymorphic Key Progression Algorithmic Engine to encrypt data packets (Col. 9, ll. 42-50) (utilizes polymorphic keys). It recites that using this engine ensures intruders will have no idea what the bit stream actually means even if it is captured (Col. 2, ll. 8-13) (ensuring the confidentiality).
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention to use polymorphic key as taught by Carlson with the shared secret generated by Koval’s protocol (private key and public key exchange) because both systems use the same fundamental mechanism generating and exchanging public/private key pairs to establish a shared secret. The polymorphic key would encrypt the bitstream of the device profile and security parameters Koval is sending , making them unreadable to intruders even if the bitstream is captured.
Regarding claim 19, Koval teaches the method of claim 14 as set forth with respect to rejection of claim 14.
Claim 19 further has the same limitations as claim 9 and therefore is rejected for the same reasons set forth with respect to rejection of claim 9.
Claims 10, 11, 12, 13 and, 20 are rejected under 35 U.S.C. 103 as being unpatentable over by Luna A. Koval et al. (US20200389499A1) hereinafter Koval and Albert Henry Carlson et al. (US10965710B1) hereinafter Carlson as applied to claims 9 and 19 above and further in view of Shinji Yamanaka et al. (US20140310524A1) hereinafter Yamanaka and Hongxia Long (WO2022/152423A1) hereinafter Long.
Regarding claim 10, Koval in view of Carlson teaches the system of claim 9 as set forth with respect to rejection of claim 9.
Koval in view of Carlson Further teaches that the security server manages and lists users that are permitted to login to specific meters using credentials (Koval, ¶ [106 & 119]) (Wherein the secure key exchange protocol includes the use of a pre-shared secret). It further teaches the use of a token supplied to users as dynamic credentials to log in (Koval, ¶ [142]) (to establish a unique identifier for each session). It recognizes that the initial connection phase must be secured via an encrypted tunnel to mitigate eavesdropping and prevent faked commands (Koval, ¶ [124]) (enhancing the security of the initial communication phase between the batch configuration tool and the metering devices.)
However, Koval in view of Carlson doesn’t teach the generation of the session identifier from a timestamp and nonce.
Yamanaka teaches creating keys based on a common key shared between devices ¶ [51]. It teaches that a temporary key is created on the basis of time information which includes a date and time or an elapsed time in seconds ¶ [53] (a session identifier generated from the current timestamp).
Moreover, Long teaches the Authentication and Key Agreement (AKA) protocol, which uses an authentication vector containing a network challenge (RAND)(random number used once)(nonce), ¶ [25]. It further teaches that this challenge-response process occurs during primary authentication initialization to prevent unauthorized access ¶ [25] and fig. 7.
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention to incorporate Yamanaka’s teaching of using timestamps alongside a nonce (or RAND) as a requirement of secure handshake protocol as taught by Long with Koval in view of Carlson’s batch configuration tool because the security of that tool depends on ensuring session keys cannot be replayed. Yamanaka’s teaching ensures key freshness and Long’s teaching mathematically guarantees that every configuration session is unique. The unique session identifier (generated from timestamps, nonce and pre-shared secrets) can be used as the initial seed for Koval in view Carlson’s engine, resulting in a session that is both unique and continuously mutating for maximum link confidentiality.
Regarding claim 20, Koval teaches the method of claim 19 as set forth with respect to rejection of claim 19.
Claim 20 further has the same limitations as claim 10 and therefore is rejected for the same reasons set forth with respect to rejection of claim 10.
Regarding claim 11, Koval in view of Carlson, Yamanaka and Long, teaches the system of claim 11 as set forth with respect to rejection of claim 10.
Koval in view of Carlson, Yamanaka and Long teaches that the use of polymorphic keys (the polymorphic keys) to protect network communication, (Carlson, Col. 2, ll. 9-13) (further securing the communication channel established with each metering device). The combination teaches using a dynamic token as a seed token (Koval, ¶ [142]). It teaches that the security server memory includes a mapping of each meter to security credentials of individual users and it also recites a list identifying which specific meter a specific user has access to, (Koval, ¶ [12 & 20])(device-specific login credentials). It teaches using username/password pair to authenticate the meter, (Koval ¶ [119])( including username and password). It further teaches a solution where seed token is combined with static previously shared credentials (the username/password) to generate a new dynamic password or session key, (Koval, ¶ [142])(generated by incorporating into the key generation process). It teaches that encryption within a session is performed via a pre-stablished secure tunnel (SSL/TLS/IPsec) that uses dynamic session to ensure the confidentiality and integrity of meter-fleet management (Koval, ¶ [124 & 129] )
However, Koval in view of Yamanaka and Long doesn’t teach encrypting and decrypting communications using polymorphic keys.
Carlson teaches that the CLDPC encrypts the content of the packets using the CipherLoc Polymorphic Key Progression Algorithm when sending data (Carlson, Col. 9, ll. 46-50) (used for encrypting) and decrypts the encrypted content of the packet upon reception (Carlson, Col. 10, ll. 19-22) (and decrypting communications).It further teaches that the cryptographic state is valid for a specific period or time to live (TTL) (Carlson, Col. 8 , ll. 1-6 ) (within the session).
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention to combine the polymorphic progression algorithm of Carlson, for encrypting and decrypting communication, with the meter management framework of Koval in view of Yamanaka and Long to enhance link confidentiality beyond standard tunnels and achieve a technical synergy between session-specific authentication and data-stream encryption.
Regarding claim 12, Koval in view of Carlson, Yamanaka and Long, teaches the system of claim 11 as set forth with respect to rejection of claim 11.
Koval in view of Carlson, Yamanaka and Long teaches a handshake procedure between the security server and the meter to verify identities (Koval, ¶ [121 & 125]) (the batch configuration tool is configured to perform a verification process). It further teaches that the device encrypts the content of the packets using the polymorphic algorithm during the sending process (Carlson, Col. 9, ll. 41 & 46-49 )( by sending an encrypted verification message). It further discloses a receiving process in which the unit decrypts the encrypted content of the packet using Polymorphic Key Progression Algorithm to interpret the data (Carlson, Col. 10, ll. 9 & 19-22 ) (and upon receiving an encrypted [packet], decrypts and verifies the [packet] using the polymorphic key). The combination further teaches that the server only continues with commands once the secure connection tunnel has been established and the meter is authenticated (Koval, ¶ [125]) (to confirm the successful authentication and secure channel establishment).
The combination does not teach encrypting and decrypting of acknowledgment.
Carlson teaches that when one network asset sends a packet to another the receiving unit acknowledges successful receipt of the packet (Col. 10, ll.14-16)( acknowledgment). Because all communications in Carlson’s system processed through the Polymorphic Key Progression Algorithm, this is acknowledgement is encrypted and decrypted, ensuring that the verification data is not only received but mathematically verified against the unique, mutating key sequence of that session.
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention to incorporate Carlson’s polymorphic encryption and decryption acknowledgment into Koval in view of Carlson, Yamanaka and Long verification handshake to provide a superior technical solution where even an intercepted acknowledgment is useless to an attacker (Carlson, Col. 2, ll. 10-13).
Regarding claim 13, Koval in view of Carlson, Yamanaka and Long, teaches the system of claim 12 as set forth with respect to rejection of claim 12.
Koval in view of Carlson, Yamanaka and Long teaches a handshake using a dynamic token or seed token that both server and meter use to generate session credentials (Koval, ¶ [142 & 143]). It also recites using static previously shared credentials known to both devices (Koval, ¶ [142 & 143]) (include a predefined pattern or token known to both the batch configuration tool and the metering device). It further describes a procedure where the server provides a certificate to the meter and the meter provides credentials to the server to authenticate the message came from a valid meter and a valid server (Koval, ¶ [122]), thereby facilitating mutual authentication (facilitating mutual authentication). The combination teaches that driving the polymorphic algorithm with shared seeds (tokens/credentials) ensures that an intruder has no idea what the bit stream actually means, protecting the confidentiality and integrity of the link (Carlson, Col. 2, ll. 9-13 )(ensuring the integrity of the established secure communication channel).
The combination does not teach using the mutual authentication token as the initialization seed. It does not teach the encrypted verification message and the acknowledgment include a predefined pattern or token.
Carlson teaches that the unit encrypts the content of the packets during the sending process (Col. 9, ll. 37-50) and waits for acknowledgment from the receiving asset (Col. 9, ll. 30-35) (the encrypted verification message and the acknowledgment), which is also encrypted via the same algorithm.
It would have been obvious to a person of ordinary skill in the art, before the effective
filing date of the present claimed invention to combine the teaching of using the mutual authentication token from Koval’s in view of Carlson, Yamanaka and Long handshake as the initialization seed with Carlson’s polymorphic engine. This creates a direct mathematical link between the identity verification phase (Koval) and the subsequent encrypted bit-stream (Carlson) and it secure a tamper-proof, synchronized, and non-repeating communication channel.
Further, the combination teaches that driving the polymorphic algorithm with shared seeds (tokens/credentials) ensures that an intruder has no idea what the bit stream actually means, protecting the confidentiality and integrity of the link (Carlson, Col. 2, ll. 9-13) (ensuring the integrity of the established secure communication channel).
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mark Aune et al. (US20080109537A1) teaches a system for automatic and simultaneous configuration of digital utility meters to ensure they are ready for use upon deployment.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAEEDE NAFOOSHE whose telephone number is (571)272-8629. The examiner can normally be reached Monday-Friday 8:00 am -5:00pm.
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, Andrew Schechter can be reached at 571-272-2302. 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.
/SAEEDE NAFOOSHE/Examiner, Art Unit 2857
/ANDREW SCHECHTER/Supervisory Patent Examiner, Art Unit 2857
Prosecution Insights