Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This office action is in response to the claim listing filed on May 18th, 2026. Claims 1-22 are currently pending.
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.
Response to Arguments
Applicant’s arguments filed on 07/24/2026 have been considered but deemed moot in view of the following explanation:
Applicant summarizes and surmises opinions in response to a plurality of citations from the current ground of rejection(s) commenting legal basis (Remarks pages 8 entirety through 9 line 24, Remarks page 10 line 10 through Remarks page 11, line 8, Remarks page 12, lines 8-14, Remarks page 12 line 28 through page 13 line 12, Remarks page 13, line 22 through page 14 line 8).
The Examiner acknowledges such descriptions however do not have further comment on the validity of such observations until further duress or otherwise contradicts common sense.
Applicant also asserts Fadul does not disclose obtaining a model name or a firmware version of a field device according to any network protocols (Remarks page 9, lines 25 and 26).
The Examiner further expand on the claim interpretation and then draw parallels to the references, in particular Fadul. Each of the respective independent claims reciting “comprising” preamble, which treats the claim open-ended and including features/steps/functionality undisclosed in the claim as long as further facilitate the steps/structure/functionality disclosed in the claim. Claim 1 recites both “determining a device configuration of a network device” as a broad scope, and none of the claims in any dependent claim further define types of network device whether local (e.g. USB), wide area, remote type, intranet or Internet network devices to name a few. Similar issues also present with the term “device configuration”, other than such configuration depends on a model name and firmware version, provided the probing a control item to a device profile leading to an update to the device profile per claim 1. Claim 3 further goes to recognizing an unidentified device, however does not mean the device includes a plurality of unsupported protocols.
Turning to the instant specification, the term “device configuration” recited ad nauseum without specific quantities, dimensions, physical attributes other than “to generate a device configuration needed by the network device for management” ([0016]). On the note of such management, the claimed protocols illustrated in instant specification Figure 2 lists “management device 200 of the embodiment of the present invention may be suitable for any number of network protocols and for managing any number of network devices, the network devices 120 to 122 may comprise any number of control items, and are not limited thereto” as well as including examples of “SNMP”, “NETCONF” and “RESTFUL API” however none of these examples are disclosed or inferred in any way in any of the currently listed claims.
Understandably, similar problems occur with the obtaining such information “according to any protocols” where if such transaction occur between two devices, particularly over a network, Fadul [0163] “other communication protocols and standards… SNMP” safe to assume a protocol have been involved in some form/capacity with a networked device.
Situations where unable to obtain a model name comes down to errors with the transmission, corrupted data and so on. Solutions to such issue involve retrying the enumerating/discovering mechanisms or simple authentication failure and denying access/further discovery connection methods to the rogue device. Taking a probe to a device that sent a message gives further weight to the type of probe, the location of the “control item” and what scope the control item pertains to the device.
Finally, obtaining a device profile is different from generating it, as the claims do not expand/further define how such device profile is obtained, whether remotely, locally, or through a database, stored on a disk, flash drive, and so on as long as the firmware version and model name is obtained first.
Applicant also asserts the claimed feature surrounding “device configuration” is conceptually and functionally different from Fadul’s message format translating, Fadul operating at a message translation layer rather than configuring operational parameters of the device (Remarks page 11, lines 17-24, [sic]).
Similar to the claim language interpretation above, Fadul’s “message format translating” affects an access interface of the network device. Example of operational parameters “device 75”) that can: (i) analyze decoder files for EIOC-enabled field devices to automatically identify field device variables (sometimes “field device parameters” (see Figs. 1a and 1b, [0036])
Applicant contends Fadul error-checking data in a communication frame is part of a predefined protocol format and is unrelated to any probing control item of a network device (Remarks page 12, lines 15-18).
Per the claim interpretation rebuttal above, the claim lacks further features to such “control item” for the network device and that the failure of such error checking either informs the network device to retry or discard the message entirely. In other words, the network device have to find a resolution to the corrupt data as appropriate. Fadul [0063]: “automatically map field device variables for an EIOC field device to message positions so that the field device variables can be easily and quickly integrated into the process control system” to avoid errors like “and error-checking data so that damaged frames can be detected and discarded; most often, higher-layer protocols trigger retransmission of lost frames” ([0041])
Applicant also contends fundamentally different layers and serve different purposes between Fadul’s communication formatting and data integrity mechanism versus claimed invention device-specific configuration and probing control items based on a device profile device from a model name and firmware version (Remarks page 12, lines 19-26).
As explained above, failure to fix the corrupted data when Fadul’s format and data integrity mechanism means a device-specific configuration must be changed or resolved to behave properly in Fadul’s data integrity mechanism such as “Regarding potential errors, the user may misunderstand the documentation and assign a new system tag to a wrong I/O channel or a wrong message position, resulting in the system tag being assigned to the wrong field device variable (and thus resulting in the system tag carrying incorrect values” ([0062] which can in turn lead to erratic/unexpected behavior “ the corresponding system tags may “break” (e.g., by way of the process control system reading from or writing to message positions no longer associated with the desired field device variable” ([Fadul [0062]).
Applicant contends further that claimed feature surrounding “device configuration” is conceptually and functionally different from Fadul’s message format translating, Fadul operating at a message translation layer rather than configuring operational parameters of the device (Remarks page 12, lines 15-18, [sic]).
The above rebuttals and claim interpretation above demonstrates that any protocol and device configuration is applicable as long as management is involved, including a message translation layer that permits other devices to communicate over SNMP (one example) which is also disclosed in the instant specification.
Applicant also asserts that no disclosure attempting multiple network protocols to determine how a control item of device may be accessed, in particular Solari does not address any uncertainty regarding supported protocols nor a probing device interface to resolve such uncertainty or probing step (Remarks page 14, lines 15-22) 1st full paragraph) and that assigning system tags to message positions does not constitute generating a device profile as needed in claim 1 (Remarks page 12, lines 3-7).
Same as the issues presented in the first rebuttal, how and to what extent this probing step matters as a device profile can either describe entirety of the device or a unique profile per protocol and so on. Fadul [0088]: “workstation or diagnostic [probing] test equipment that is utilized by an operator within the process plant” since the claim language does not necessarily have to be an automatic probing, software/or hardware implementation for probing the device.
The Examiner respectfully recommends incorporating the features of claim 11, expanding on the functionality of who/what element performing “probing control item” in light of Figure 4 into each independent claims 1 and 12.
Furthermore, Applicant makes alleged distinctions that the instant application is directed to determining how to access a network device when the supported interfaces or protocols are not known in advance (Remarks page 14, line 29 through page 15, line 1)
As mentioned above, the claim language does not distinguish how far “advance” is to the networked device, merely that the device is not identified, and could possess any plurality of protocols as long as the device is capable of switching from a first protocol to a second one and model name/firmware/profile can be transmitted.
For these reasons the current ground of rejection(s) is respectfully maintained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights