DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Amendment filed 17 February 2026 has been received and considered.
Claims 1-3 and 5-8 are pending.
This Action is Final.
Claim Interpretation
The claim interpretation as invoking 35 U.S.C. 112(f) is withdrawn.
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.
Claims 1-3 and 5-8 are rejected under 35 U.S.C. 103 as being unpatentable over Rizwan et al. (US 20200137027) in view of Kagoura et al. (JP 2021078066).
As per claims 1 and 8, Rizwan et al. discloses a device and method for monitoring a current loop, the method comprising intercepting a command in accordance with the HART protocol circulating over a current loop (see paragraph [0049] where the WirelessHART adapter 418 receives, i.e. intercepts, a command destined for field device; and paragraphs [0044] and bottom on [0049] showing the HART protocol current loop);
extracting data from the command, wherein the data comprises a first datum of the HART protocol, and a second datum indicating a type of the command (see paragraph [0049] where the device data, and command data is extracted for be used in the inspection);
generating, or not generating, an alert according to the extracted data, the alert indicating that the command is potentially abnormal or hazardous (see paragraph [0051] where an alert is transmitted for blocked, i.e. potentially abnormal or hazardous commands).
While the Rizwan et al. system uses device information as part of the determination whether the command is abnormal or hazardous (see paragraph [0049]) and the HART protocol explicitly requires a designation in the address field whether the device is a primary master or secondary master, there lacks an explicit recitation of including a determination of the source of the command as part of the overall determination.
However, there lacks an explicit recitation of extracting data describing the source of the command as part of the determination whether the command is abnormal or hazardous.
However, Kagoura et al. teaches using source information extracted from a HART protocol message as part of determining allowability of a command (see Fig. 2 step 101 and the corresponding description: The communication management unit 13 confirms the source MAC address included in the packet received by the communication interface unit 12, and determines whether the source of this packet is a host device that is permitted to connect to the HART device).
At a time before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to include the source check of Kagoura et al. in the Rizwan et al. system.
Motivation, as recognized by one of ordinary skill in the art, to do so would have been to increase the granularity of the command control by allowing certain sources to send certain commands.
The modified Rizwan et al. and Kagoura et al. system further discloses the alert is not generated whenever all the following conditions are met: the first datum indicates that the command was not transmitted by a primary master and the second datum indicates that the type of the command is part of a whitelist of authorized command types or is not part of a blacklist of unauthorized command types, and the alert is generated whenever at least one of said conditions is not met (see Rizwan et al. paragraphs [0049]-[0051] showing the accepting of a command from the secondary master and Kagoura et al. Fig. 2 step 107: At this time, the communication management unit 13 may send a packet notifying that the communication request is rejected to the host device 3-2).
As per claim 2, the modified Rizwan et al. and Kagoura et al. system discloses the alert is generated if the first datum indicates that the transmitter is a primary master (see Rizwan et al. paragraph [0051] showing the accepting of a command from the secondary master and Kagoura et al. Fig. 2 step 107: At this time, the communication management unit 13 may send a packet notifying that the communication request is rejected to the host device 3-2).
As per claim 3, the modified Rizwan et al. and Kagoura et al. system discloses comprising comparing the type of the command indicated by the second datum with reference data, wherein the alert is generated or not generated according to the comparing (see Rizwan et al. paragraph [0049] the firewall rules and DPI).
As per claims 5-7, the modified Rizwan et al. and Kagoura et al. system discloses an alert stored in memory (see Rizwan et al. paragraphs [0049]-[0050] and Kagoura et al. Fig. 2 step 107: At this time, the communication management unit 13 may send a packet notifying that the communication request is rejected to the host device 3-2; where the alert must be stored in memory to be displayed or transmitted), but fails to explicitly disclose at least one of the following data is stored in the memory in association with the generated alert: all or part of the data extracted from the command, a date on which the command was intercepted, a slave recipient of the command and displaying the alert on a display screen; in replacement of another previously generated alert. However, Official Notice is taken that at a time before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to store information about the command and the replace previously displayed alerts in the modified Rizwan et al. and Kagoura et al. system. Motivation, as recognized by one of ordinary skill in the art, to do so would have been to allow the system to collect information about the commands and the display the most recent alert.
Response to Arguments
Applicant's arguments filed 17 February 2026 have been fully considered but they are not persuasive. Applicant argues that the cited prior art fails to teach the specific requirement of not generating an alert when the message is not sent from a primary master and passes a command type list comparison (i.e. whitelist/blacklist).
The Examiner respectfully disagrees as the prior art renders this limitation obvious. More specifically, the combination, as recognized by one of ordinary skill in the art recognizes that this limitation is obvious. Rizwan teaches that only the whitelisted commands are allowed to be sent from the handheld device 501 to the HART field instrument 520 and an alert is generated when a non-whitelisted command is sent (see, for example, paragraph [0051]). This clearly meets the claimed, “ datum indicates that the type of the command is part of a whitelist of authorized command types or is not part of a blacklist of unauthorized command types” and “the alert is generated whenever at least one of said conditions is not met”. Furthermore, Kagoura specifically checks the source of the command by checking a MAC address which shows the claimed requirement to be from a specific device obvious. Kagoura also discloses in reference Fig. 6 the confirmation that the command is permitted. While there is no explicit requirement that each of the criteria to be met for the alert not to be sent, it is obvious over the prior art. As put forth above, Rizwan checks commands from devices against whitelists and Kagoura teaches checking sources of command and the command numbers. One of ordinary skill in the art recognizes that requiring both the source of the command and the command itself to meet requirements increases the security of the system and is therefore obvious. Furthermore, the combination as put forth above has a limited number of options for not generating an alert: when the command is on the white list, when the source device is authorized, or when both the command is on the white list and the source device is authorized. Since there is a limited number of options to try and would result in the predictable result of alerting when specific criteria are met, it would be obvious to one of ordinary skill in the art to try requiring both criteria for not sending an alert.
Furthermore, previously cited but not relied upon Koniki teaches the very well-known idea of checking multiple criteria to allow a command.
Applicant’s remaining arguments are moot in view of the above response.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: the remaining references put forth on the PTO-892 form are directed towards HART protocol monitoring.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J PYZOCHA whose telephone number is (571)272-3875. The examiner can normally be reached Monday-Thursday 7:30am-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, Hadi Armouche can be reached at (571) 270-3618. 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.
/Michael Pyzocha/ Primary Examiner, Art Unit 2409