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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/05/2025, and 07/29/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings were received on 08/19/2024. These drawings are accepted.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-22 are rejected 35 U.S.C. 103 as being unpatentable over Fadul et al. (USPGPUB No. 2021/0341907 A1, hereinafter referred to as Fadul) in view of Solari et al. (USPGPUB No. 2022/0279023 A1, hereinafter referred to as Solari).
Referring to claim 1, Fadul discloses a network management method running on a network management device {“dedicated devices responsible for configuring and managing the network”, see Fig. 1a [0184], 1st sentence}, used to determine a device configuration {“configuration system may include a database storing a map 132 linking [device configurations] system tags”, see Fig. 1a [0059]} of a network device {“field device 131”, “133”, “135” networked over “switch 128” and “network 10”, see Fig. 1a [0048], last sentence}, the network management method comprising:
obtaining a model name {“plurality of decoder files based on a model [name] number”, see Fig. 1a [0056]} and a firmware version of the network device {firmware version “existing field device in the process control system may publish a new or updated decoder file… new firmware”, see Fig. 1a [0131]} according to a plurality of network protocols {plurality of network protocols “standard protocols selected from the Internet protocol suite” (see Fig. 6 [0133]), a second protocol “smart field devices HART®, WirelessHART” ([0004], last sentence), “suitable communication protocol such as, an Ethernet protocol” (see Figs. 1a and 1b, [0066], last sentence)};
obtaining or generating a device profile {“formally [generating] assigning … the set of [device profiles] system tags”, see Fig. 1a [0059], 1st sentence} according to the model name and the firmware version {changing/obtaining firmware version “existing field device in the process control system may publish a new or updated decoder file… new firmware” ([Fig. 1a, [0056]) that also relies on model name “other identifier unique to the field device 131 or to the model of the field device 131” (see Fig. 1a, [0056], last sentence)};
and generating or updating the device configuration of the network device {“ process control system 5 is updated to utilize the system tags”, see Fig. 1a [0060], 2nd sentence} according to the device profile {“set of system tags (e.g., new system tags not currently used by the process control system 5) intended to represent the identified field device variables”, see Fig. 1a, [0058], last sentence};
wherein the step of generating the device profile according to the model name and the firmware version further comprises {“formally assigning the system tags for the process variables to the appropriate communication channels” generating device profile as claimed during “step 515”, see Fig. 5 [0129]}:
determining at least one probing control item of the network device {determining “[one control item] error-checking data so that damaged frames can be detected and discarded”, see Fig. 1a [0041], last sentence};
Solari does not appear to explicitly disclose determining at least one probing control item of the network device according to the device profile;
and probing an access interface of the at least one probing control item according to the plurality of network protocols respectively to update the device profile.
However, Solari discloses determining at least one probing control item of the network device {“Digital Trust Broker 300 interacts with operator management platforms to configure [probing] monitoring and data collection for [at least one control item] PKI Certificate flows,”, see Figs. 2 and 3 [0033], last two sentences} according to the device profile {devices “endpoints authenticate each other using PKI/Digital certificates over the user plane tunnel through the transit network”, see Fig. 7 [0066]};
and probing an access interface {“DTB 300 provides UI and REST APIs for policy configuration and actions.”, see Fig. 3 [0034]} of the at least one probing control item {“Enhanced X.509 Certificates (PKI certificate with metadata extensions”, see Fig. 3 [0036]} according to the plurality of network protocols respectively to update the device profile {“puts and notifications from other eco system components and feeds them to the rules engine 302” where such eco system components sent according to plurality of network protocols , see Fig. 3 [0034], last three sentences}.
Fadul and Solari are analogous because they are from the same field of endeavor, networked device(s) management.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Fadul and Solari before him or her, to modify Fadul’s “dedicated devices responsible for configuring and managing the network” (see Fig. 1a [0184], 1st sentence) incorporating Solari’s “Device certificates X.509” (see Fig. 8, [0112]).
The suggestion/motivation for doing so would have been to implement/coordinate Enhanced X.509 certificates with extensions that include provenance and other meta data (Solari [0003], 1st sentence) by facilitating/assisting a high security enterprise may require additional security, trust assurance and methods of verifying this trust before, during or after use such as ensuring that the platform components are from established vendors that the enterprise trusts (Solari [0002], last two sentences).
Therefore, it would have been obvious to combine Solari with
Fadul to obtain the invention as specified in the instant claim(s).
As per claim 2, the rejection of claim 1 is incorporated and Solari discloses wherein the step of obtaining the model name and the firmware version of the network device is obtaining the model name and the firmware version of the network device {“Model [name] Number, SW/Firmware version”, see Fig. 8, [0112], 2nd sentence} according to a first protocol of the plurality of network protocols {“client application attempts to establish secure TCP connection”, see Fig. 4th sentence from bottom of [0106]}.
As per claim 3, the rejection of claim 2 is incorporated and Solari discloses wherein when the network device is an unidentified device {“transit network providers may have embedded vulnerabilities, or may utilize unreliable or not adequately [unidentified] verified [device or sub] components that compromise security” ([0002], last three sentences)}, the first protocol is a default network protocol of the plurality of network protocols {“device establishes default bearer and UP Tunnel when CP connection is established”, see Fig. 5 [0101]}.
As per claim 4, the rejection of claim 2 is incorporated and Solari discloses wherein when the network device is an identified device {“DTB verifies the user and user device meets the authorization and authentication policies required for specific logical network and enables connection to the specific APN/SEPP in the mobile network”, see Fig. 5 [0027], last sentence}, the first protocol is determined according to the device configuration of the network device {“The DTB installs the slice certificates to the CPEs in coordination with operator CMPs”, see Fig. 5 [0097]}.
As per claim 5, the rejection of claim 2 is incorporated and Solari discloses further comprising:
in response to not obtaining the model name and the firmware version of the network device {“policy server enforces the policies and terminates the user session [and likewise obtaining model name and firmware] if allowed limits are reached”, see Fig. 1, [0106], last sentence} according to the first protocol of the plurality of network protocols {“each service provider notifies the DTB 103 of any interface failures”, see Fig. 1, [0077], last three sentences}, obtaining the model name and the firmware version of the network device {“Model [name] Number, SW/Firmware version”, see Fig. 5, [0112], 2nd sentence} according to a second protocol of the plurality of network protocols {“HW/SW updates so that the DTB 103 could revalidate the paths [that involve other network protocols].” (see Fig. 1, [0077], last sentence) examples of such protocols “provides a user interface and common API for validating trust assurance of end-to-end network paths, individual network segments” (see Fig. 3, [0035], 1st sentence)}.
As per claim 6, the rejection of claim 2 is incorporated and Solari discloses further comprising:
in response to not obtaining the model name of the network device {“policy server enforces the policies and terminates the user session [and likewise obtaining model name and firmware] if allowed limits are reached”, see Fig. 5, [0106], last sentence}, generating a generic device profile {“store [static information such as Manufacturing Serial Number/Model/Date/Location, device certificates”, see Fig. 5, [0112], 3rd sentence} as the device profile and determining the at least one probing control item to be all default control items {“store [default] static information such as Manufacturing Serial Number/Model/Date/Location, device certificates”, see Fig. 5, [0112], 3rd sentence} in the step of obtaining or generating the device profile according to the model name and the firmware version {“Model [name] Number, SW/Firmware version”, see Fig. 8, [0112], 2nd sentence}.
As per claim 7, the rejection of claim 2 is incorporated and Solari discloses wherein the step of obtaining or generating the device profile according to the model name and the firmware version comprises querying a database of the network management device {“generates an application request, for example, a database query for specific data segment”, see Fig. 1 [0106]} according to the model name and the firmware version so as to obtain the device profile {“Model [name] Number, SW/Firmware version”, see Fig. 5, [0112], 2nd sentence} with the same model name and firmware version as the network device {“For cross correlating [according to] the enhanced certificates and other attributes stored digitally in the device”, see Fig. 5, [0112]}.
As per claim 8, the rejection of claim 7 is incorporated and Solari discloses further comprising:
in response to not obtaining the device profile with the same model name and firmware version as the network device {“policy server enforces the policies and terminates the user session [and likewise obtaining model name and firmware] if allowed limits are reached”, see Fig. 1, [0106], last sentence}, querying the data base according {“generates an application request, for example, a database query for specific data segment”, see Fig. 1 [0106]} to the model name so as to obtain a device profile of a similar device {“Model [name] Number, SW/Firmware version”, see Fig. 1, [0112], 2nd sentence} and generate the device profile according to the device profile of the similar device {“For cross correlating [according to] the enhanced certificates and other attributes stored digitally in the device”, see Fig. 1 [0112]}, wherein the similar device has the same or similar model name as the network device {“Cross-correlating the permanent device identifiers [of a networked device] from certificates with post manufacturing data on [similar devices] device labels facilitates cataloging information for each device in a database”, see Fig. 1 [0112]}.
As per claim 9, the rejection of claim 8 is incorporated and Solari discloses further comprising:
in response to not obtaining the device profile of the similar device {“policy server enforces the policies and terminates the user session [and likewise obtaining model name and firmware] if allowed limits are reached”, see Fig. [0106], last sentence}, generating a generic device profile as the device profile {“For cross correlating [according to] the enhanced certificates and other attributes stored digitally in the device”, see Fig. 1 [0112]} and determining the at least one probing control item {“Enhanced X.509 Certificates (PKI certificate with metadata extensions”, see Fig. 3 [0036]} to be all default control items according to the generic device profile {“store [default] static information such as Manufacturing Serial Number/Model/Date/Location, device certificates”, see Fig. 5, [0112], 3rd sentence}.
As per claim 10, the rejection of claim 1 is incorporated and Solari discloses wherein the device profile records network protocols supportable to access interfaces of each control item of the network device {“For cross correlating [according to] the enhanced certificates and other attributes stored digitally in the device” (see Fig. 1 [0112]) including recording supportable network protocols {“HW/SW updates so that the DTB 103 could revalidate the paths [that involve other network protocols].” (see Fig. [0077], last sentence) examples of such protocols “provides a user interface and common API for validating trust assurance of end-to-end network paths, individual network segments” (see Fig. 3, [0035], 1st sentence)} with the model name and the firmware version {“Model [name] Number, SW/Firmware version”, see Fig. 1, [0112], 2nd sentence}.
As per claim 11, the rejection of claim 10 is incorporated and Solari discloses wherein in the step of determining the at least one probing control item of the network device {“Enhanced X.509 Certificates (PKI certificate with metadata extensions”, see Fig. 3 [0036]} according to the device profile {“For cross correlating [according to] the enhanced certificates and other attributes stored digitally in the device”, see Fig. 1 [0112]}, the at least one probing control item comprises control items without supportable network protocols recorded in the device profile {“provides a user interface and common API for validating trust assurance of end-to-end network paths, individual network segments” (see Fig. 3, [0035], 1st sentence) including unsupported network protocols “transit network providers may have embedded vulnerabilities, or may utilize unreliable or not adequately verified components that compromise security” ([0002], last three sentences)}.
Referring to claims 12-22 are device claims reciting claim functionality corresponding to the method claim of claims 1-11, respectively, thereby rejected under the same rationale as claims 1-11 recited above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following references are indicative the current state of art regarding claim 1’s “device profile”, “first protocol”, or “firmware”: US 11256641 B2, US 11249647 B2, US 20220164104 A1, US 11252232 B2, US 11232058 B2, US 20210208572 A1, US 20210019138 A1, US 20190226450 A1, US 10216596 B1, US 20180349235 A1, US 20170168883 A1.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER A. BARTELS whose telephone number is (571)270-3182. The examiner can normally be reached on Monday-Friday 9:00a-5:30pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Dr. Henry Tsai can be reached on 571-272-4176. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C. B./
Examiner, Art Unit 2184
/HENRY TSAI/Supervisory Patent Examiner, Art Unit 2184