DETAILED ACTION
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 .
Status of Claims
This office action is a response to an application filed on 01/16/2025, wherein claims 1-20 are presented for examination.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 01/16/2025 and 05/07/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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 6, 7, 10, 16 and 19 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 pre-AIA the applicant regards as the invention.
Claim 6 depends from claim 1 which requires that the first data matches a fingerprint of a plurality of fingerprints stored in a database. Claim 6, however, requires that the same first data does not match any of the fingerprints stored in the database. This requirement is contradictory to claim 1, and therefore renders claim 6 indefinite.
Claim 7 is dependent from claim 6, and therefore contains the same indefinite language. As a result, it is rejected under the same rationale as claim 6.
Claims 10 and 19 recite “determining the device associated with the first data and the fingerprint is not included in the network map”. It is unclear whether the device is associated with both the first data and the fingerprint and is absent from the network map, or whether the device is associated only with the first data and the fingerprint itself is absent from the network map. Claims 10 and 19 are therefore rendered indefinite
Claim 16 depends from claim 11 which requires that the first data matches a fingerprint of a plurality of fingerprints stored in a database. Claim 16, however, requires that the same first data does not match any of the fingerprints stored in the database. This requirement is contradictory to claim 11, and therefore renders claim 16 indefinite.
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 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 of this title, 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, 8, 10, 11, 13, 17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gustafson et al. (US 2008/0244741), hereinafter Gustafson, in view of Tarquini et al. (US 2003/0097557), hereinafter Tarquini.
Regarding claim 1, Gustafson discloses a method for enriching a network map of a network, comprising:
receiving, from a device in the network, network traffic comprising one or more data packets (Gustafson, [0024]-[0026]: security devices collect traffic comprising packets from monitored host/device);
identifying first data included in a first field of a packet of the one or more data packets (Gustafson, [0037]: parsing the network and transport protocol fields of a packet [any of these fields can be the first field] to obtain host information [the corresponding host information in the field is the claimed first data]); and
based on determining the first data matches a fingerprint of a plurality of fingerprints (Gustafson, [0025]: comparing the decode data (first data) with operating system and service fingerprints; [0020]: generating an event when a new service or network change is detected (i.e., there is a match)):
generating an event (Gustafson, [0020]);
identifying second data associated with one or more second fields of the packet (Gustafson, [0037]: parsing the network and transport protocol fields of a packet [any of these fields can be the second field] to obtain host information [the corresponding host information in the field is the second data]); and
updating the network map to include the event (Gustafson, Fig. 6, step 630: report the new event to the network map).
Gustafson does not explicitly disclose stored in a database of the network; comprising the first data and the fingerprint; based on determining the second data matches one or more second fingerprints in the database, updating the event to include the second data and the one or more second fingerprints.
However, Tarquini discloses
receiving, from a device in the network, network traffic comprising one or more data packets (Tarquini, [0031]: IPS captures packets in network traffic);
based on determining the first data matches a fingerprint of a plurality of fingerprints stored in a database of the network (Tarquini, [0036]: IPS performs signature analysis using a database of known signatures (fingerprints); [0059]: comparing a signature file (fingerprint) with the packet (first data) to determine whether a match exists):
generating an event comprising the first data and the fingerprint (Tarquini, [0059]: after a signature match, a record of the match (event comprising first data and fingerprint) is denoted by the IPS);
based on determining the second data matches one or more second fingerprints in the database (Tarquini, [0016]: determining a correspondence between the packet and at least two signatures [packet content that corresponds with the additional signature is the second data), updating the event to include the second data and the one or more second fingerprints (Tarquini, [0060]: a record/log of the match is generated by the IPS; the record (event) records multiple signature file matches between a single packet and one or more signature files [recording multiple signature files = updating the event]).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson and Tarquini before him or her before the effective filing date of the claimed invention, to modify a security device that generates packet based events and reports them to a network map as taught by Gustafson, to include a technique of continuing to test the packet after a first signature/fingerprint match and report all matching signatures/fingerprints in one event as taught by Tarquini. The motivation for doing so would have been to avoid missing additional matches and provide the network map with more complete information about the packet.
Regarding claim 3, Gustafson does not explicitly disclose wherein determining the first data matches the fingerprint comprises using one or more pattern matching algorithms.
However, Tarquini discloses wherein determining the first data matches the fingerprint comprises using one or more pattern matching algorithms (Tarquini, [0005]: signature (fingerprint) analysis performed by a network IPS is implemented as a pattern-matching algorithm).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson and Tarquini before him or her before the effective filing date of the claimed invention, to modify a security device compares packet data to operating system and service fingerprints as taught by Gustafson, to include implementing the signature/fingerprint analysis as a pattern matching algorithm as taught by Tarquini. The motivation for doing so would have been to utilize a known and predictable technique for performing the comparison of packet data with stored patterns, in order to predictably identify matching fingerprints.
Regarding claim 8, Gustafson discloses wherein the method is implemented as part of a firewall service of the network, further comprising (Gustafson, [0018]: security devices include firewalls):
determining, based on an operating system of the device, a firewall policy to apply to the device (Gustafson, [0040]); and
applying the firewall policy to the device (Gustafson, [0040]).
Regarding claim 10, Gustafson discloses wherein generating the event comprising the first data (Gustafson, [0020]: if a new service is detected on a host, an event is generated that contains the new service information (first data)) and is further based on determining the device associated with the first data and the fingerprint is not included in the network map (Gustafson, [0024]-[0026]: identifying network devices on a network (first data), and identifying operating systems and services (fingerprints) on those devices; [0051]: newly identified information (i.e., not included in the network map) results in the creation of a new network map entry).
Gustafson does not explicitly disclose the fingerprint.
However, Tarquini discloses generating the event comprising the first data and the fingerprints (Tarquini, [0041]: IPS generates an event comprising matches between a packet (first data) and signature files (fingerprints)).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson and Tarquini before him or her before the effective filing date of the claimed invention, to modify a security device generates an event for newly detected network information and uses that event to create or update a network map entry as taught by Gustafson, to include utilizing an event format that records the packet’s matching signature files/fingerprints as taught by Tarquini. The motivation for doing so would have been so that when a previously unmapped device is detected, the event used to add that device also identifies the signatures that caused the detection, resulting in a more informative event and a better supported new device map entry.
Regarding claim 11, the limitations have been addressed in the rejection of claim 1, and furthermore, Gustafson discloses a system comprising: one or more processors (Gustafson, [0058]); and one or more computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations (Gustafson, [0058]).
Regarding claims 13, 17 and 19, the limitations have been addressed in the rejections of claims, 3, 8 and 10 respectively.
Regarding claim 20, the limitations have been addressed in the rejection of claim 1, and furthermore, Gustafson discloses one or more non-transitory computer-readable media maintaining instructions that, when executed by one or more processors, program the one or more processors to perform operations (Gustafson, [0058]).
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Gustafson in view of Tarquini, further in view of Agarwal et al. (US 2014/0012967), hereinafter Agarwal.
Regarding claim 2, Gustafson discloses the network map comprises a network firewall map (Gustafson, [0019]: security device and network map are in a single computer; [0018]: the security device is a firewall).
Gustafson and Tarquini do not explicitly disclose wherein: the packet comprises a multicast domain name system (mDNS) packet; the method is implemented by a detection system corresponding to a mDNS service detector.
However, Agarwal discloses wherein:
the packet comprises a multicast domain name system (mDNS) packet (Agarwal, [0023], [0006]);
the method is implemented by a detection system corresponding to a mDNS service detector (Agarwal, [0033]-[0035]: controller (mDNS service detector) receives mDNS messages and classifies devices based on whether the mDNS message advertise services and what services are advertised).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson, Tarquini and Agarwal before him or her before the effective filing date of the claimed invention, to modify a security device that monitors packets in order to record events for updating a network map as taught by Gustafson and Tarquini, to include an mDNS service detection functionality as taught by Agarwal. The motivation for doing so would have been to obtain service and device information through mDNS, and thereby improve the completeness of the network map.
Regarding claim 12, the limitations have been addressed in the rejection of claim 2.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Gustafson in view of Tarquini, further in view of Roesch et al. (US 7,949,732), hereinafter Roesch.
Regarding claim 4, Gustafson and Tarquini do not explicitly disclose wherein identifying the first data comprises: classifying the packet as being encoded according to a protocol; decoding the packet based on the protocol to generate decoded data; parsing the decoded data to identify the first data included in the first field; and extracting the first data as raw text.
However, Roesch discloses wherein identifying the first data comprises:
classifying the packet as being encoded according to a protocol (Roesch, col 24, ln 34-43, 50-55: classification as IPv4, TCP, UDP or an IP fragment);
decoding the packet based on the protocol to generate decoded data (Roesch, col 24, ln 61-62: decoding the packet; col 24, ln 50-55: the flow type is used to determine the analysis that is to be performed);
parsing the decoded data to identify the first data included in the first field (Roesch, col 23, ln 1-13: parsing a HTTP header (decoded data) to identify “server=” field (first field) and vendor/version value (first data), or parsing RPC header (decoded data) to identify a sub service field (first field) and sub service type value (first data)); and
extracting the first data as raw text (Roesch, col 23, ln 8-13: the field is extracted and represented as a readable string (raw text)).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson, Tarquini and Roesch before him or her before the effective filing date of the claimed invention, to modify a security device that monitors packets in order to record events for updating a network map as taught by Gustafson and Tarquini, to include identifying packet data by using protocol aware classification, decoding and parsing as taught by Roesch. The motivation for doing so would have been to provide field level packet data required for reliable fingerprint comparison.
Regarding claim 14, the limitations have been addressed in the rejection of claim 4.
Claims 5-7, 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Gustafson in view of Tarquini and Roesch, further in view of Du et al. (US 2021/0377719), hereinafter Du.
Regarding claim 5, Gustafson and Tarquini do not explicitly disclose wherein the first data comprises a device name and a hardware identifier and the fingerprint is associated with a specific pattern, further comprising: determining, based on the hardware identifier matching the fingerprint, an operating system associated with the device; and determining one or more additional matches between the second data and additional fingerprints, the one or more additional matches returning additional device data, wherein the second data comprises device information, wherein the event is associated with the device and comprises the device information, the operating system, and the additional device data.
However, Roesch discloses determining one or more additional matches between the second data and additional fingerprints (Roesch, col 12, ln 4-21: packets having network, transport and application fields are compared with both network and application fingerprint tables), the one or more additional matches returning additional device data (Roesch, Fig. 8: show fingerprint database entries containing “Vendor”, “Product name” and “Version”; col 29, ln 25-34: service type, name, vendor and version are derived from the protocol and mapped to the product information).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson, Tarquini and Roesch before him or her before the effective filing date of the claimed invention, to modify a security device that generates a packet derived event identifying multiple matching signatures/fingerprints and uses it to update a network map as taught by Gustafson and Tarquini, to include identifying a device’s operating system and services from decoded packet fields as taught by Roesch. The motivation for doing so would have been to provide a more complete and accurate network map entry for the detected device, thereby enabling more precise device classification and security policy enforcement.
Furthermore, the combination of Gustafson, Tarquini and Roesch do not explicitly disclose wherein the first data comprises a device name and a hardware identifier and the fingerprint is associated with a specific pattern, further comprising: determining, based on the hardware identifier matching the fingerprint, an operating system associated with the device; and, wherein the second data comprises device information, wherein the event is associated with the device and comprises the device information, the operating system, and the additional device data.
However, Du discloses wherein the first data comprises a device name and a hardware identifier (Du, Fig. 2D: shows discovery event containing “hostname” (device name) and “iotDeviceid” (hardware identifier); [0045]: discovery events are sent by IoT server whenever if observes a packet that can uniquely identify the identity of a device) and the fingerprint is associated with a specific pattern (Du, [0064], [0077]-[0079]: a pattern ID (fingerprint) is a list of attributes/sequence of features that forms a distinct network behavior description identifying the type of an IoT device, and includes OUI in MAC address and hostname string from decoded protocols), further comprising:
determining, based on the hardware identifier matching the fingerprint, an operating system associated with the device (Du, [0061]: device classification uses an OUI (hardware identifier); Fig. 7: shows the resulting device verdict with “OS: Windows 7”); and
the one or more additional matches returning additional device data (Du, Fig. 2C: shows a device verdict containing vendor, model, OS and SN; [0058]: a device record is populated with manufacturer and model information, and updated as additional contextual information is gathered), wherein the second data comprises device information (Du, [0077]-[0087]: identifying device related pattern features including OUI, hostname, operating system, SMB data, DHCP option strings, and strings from IoT protocols; [0048]: raw discovery and session events are enriched with additional contextual information and used for feature extraction),
wherein the event is associated with the device (Du, [0045]: IoT server sends device discovery events when it observes a packet that uniquely identifies a device) and comprises the device information, the operating system, and the additional device data (Du, Fig. 2C: shows “Device Verdict Event” containing Profile & Category information (device information), OS field (operating system), and Vendor, Model, Version and SN (additional device data)).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson, Tarquini, Roesch and Du before him or her before the effective filing date of the claimed invention, to modify a security device that generates a packet derived event identifying multiple matching signatures/fingerprints and the device’s operating system and services, and uses that information to update a network map as taught by Gustafson, Tarquini and Roesch, to include device specific identification using patterns based on attributes as taught by Du in order to have additional device identity and profile information. The motivation for doing so would have been to facilitate having a network map with a more complete device context, thereby allowing more accurate device specific security policies.
Regarding claim 6, Gustafson and Tarquini do not explicitly disclose wherein the first data does not match any of the plurality of fingerprints stored in the database, further comprising: refraining from identifying the second data; generating a discovery event comprising the first data; and storing the discovery event in the database.
However, Roesch discloses wherein the first data does not match any of the plurality of fingerprints stored in the database (Roesch, Fig. 6, steps 650, 660, 680 & END: determining that packet data (first data) does not match any operating system (fingerprint)), further comprising:
refraining from identifying the second data (Roesch, Fig. 6, steps 650, 660, 680 & END: ending the non-match branch after recording the unmatched packet fields, without carrying out additional field based processing).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson, Tarquini and Roesch before him or her before the effective filing date of the claimed invention, to modify a security device that identifies packet data matching signatures/fingerprints and uses the information to update a network map as taught by Gustafson and Tarquini, to include recording unidentified fingerprints to an unknown file as taught by Roesch. The motivation for doing so would have been to facilitate adding items from this file at a later time when the operating system they describe is identified.
Furthermore, the combination of Gustafson, Tarquini and Roesch does not explicitly disclose generating a discovery event comprising the first data; and storing the discovery event in the database.
However, Du discloses
refraining from identifying the second data (Du, Fig. 2D: only attributes (first data) shown in Fig. 2D were identified; [0077]-[0099]: other attributes that were not identified (second data));
generating a discovery event comprising the first data (Du, Fig. 2D: shows a generated discovery event comprising, among other fields, iotDeviceid, hostname, ip (first data); the same event identifies profileType as unknown (i.e., does not match any signatures)); and
storing the discovery event in the database (Du, [0048]: discovery events are stored in storage 158).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson, Tarquini, Roesch and Du before him or her before the effective filing date of the claimed invention, to modify a security device that determines when packet field do not match a known fingerprint and records the unmatched fields in an unknown fingerprint file as taught by Gustafson, Tarquini and Roesch, to include utilizing a discovery event format for unmatched/unknown packet data as taught by Du. The motivation for doing so would have been to enable efficient updating of the event when the unknown packet data is later identified.
Regarding claim 7, Gustafson, Tarquini and Roesch do not explicitly disclose further comprising: determining, based on the discovery event, a hardware name associated with the first data; and updating the database to include the hardware name and an association with the first data.
However, Du discloses further comprising:
determining, based on the discovery event, a hardware name associated with the first data (Du, [0105]: security platform receives device discovery event (first data) for an IoT device and then performs a classification process; [0106]: e.g., the classification identifies the device as an Xbox One game console (hardware name)); and
updating the database to include the hardware name and an association with the first data (Du, [0076]: classification is assigned to a device in device database or updated; [0100]: when a previously unknown device is later identified, the device is relabeled with the newly determined product identity (hardware name) and has an associated pattern ID generated (association with first data)).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson, Tarquini, Roesch and Du before him or her before the effective filing date of the claimed invention, to modify a security device that generates a discovery event containing unidentified device data as taught by Gustafson, Tarquini and Roesch, to include utilizing a device classification and database update technique as taught by Du that enables previously unidentified data to be associated with a hardware name and stored as a reusable device pattern. The motivation for doing so would have been to allow subsequently observed devices having the same data to be identified automatically, thereby permitting security policies to be applied more quickly.
Regarding claim 15, the limitations have been addressed in the rejection of claim 5.
Regarding claim 16, the limitations have been addressed in the rejections of claims 6 and 7.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gustafson in view of Tarquini, further in view of Du.
Regarding claim 9, Gustafson and Tarquini do not explicitly disclose wherein the second data comprises one or more of a device model, a device manufacturer, an operating system version, and a device name associated with the device.
However, Du discloses wherein the second data comprises one or more of a device model, a device manufacturer, an operating system version, and a device name associated with the device (Du, [0058]: as additional contextual information is received, subsequent messages concerning the device is enriched with that information; additional contextual information includes device model, operating system and operating version).
It would have been obvious to one of ordinary skill in the art, having the teachings of Gustafson, Tarquini, and Du before him or her before the effective filing date of the claimed invention, to modify a security device that generates an event identifying multiple signatures/fingerprints for a packet and uses it to update a network map as taught by Gustafson and Tarquini, to include enriching identified device information with device model and operating system version as taught by Du. The motivation for doing so would have been to provide a more complete and accurate network map entry for the detected device, thereby enabling more precise device classification and security policy enforcement.
Regarding claim 18, the limitations have been addressed in the rejection of claim 9.
Related Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Gleichauf et al. (US 6,499,107) discloses monitoring and capturing network packets, analyzing the packets to identify device, operating system and service information, comparing monitored packet traffic with stored attack signatures, and incorporating the discovered information into a maintained network map (Gleichauf, col, 5, ln 48-67; col 6, ln 1-8 and 20-52; col 7, ln 46 – col 8, ln 17) .
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LESA M KENNEDY whose telephone number is (571)431-0704. The examiner can normally be reached Monday-Wednesday 9:30 am - 5:30 pm ET.
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, Umar Cheema can be reached on (571) 270-3037. 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.
The examiner also requests, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
/LESA M KENNEDY/Primary Examiner, Art Unit 2458
Prosecution Insights