`
`IW 7696177
`
`UNITED STATES DEPARTMENT OF COMMERCE
`
`United States Patent and Trademark Office
`
`October. 10, 2018
`
`
`
`
`It's,
`
`THIS IS TO CERTIFY THAT ANNEXED IS A TRUE COPY FROM THE
`
`
`
`I.‘NRI!:VIMI‘MP-IMEWI-IG'IHH‘IHHH-‘RNDIH-N.‘
`
`
`
`RECORDS OF THIS OFFICE OF THE FILE WRAPPER AND CONTENTS
`
`OF:
`
`
`
`APPLICATION N-U--:MBER--10/684 776
`FILING DATE. October 14, 2003
`
`PATENT NUMBER: 6,954, 789 -
`
`ISSUE DATE: October I1, 2005
`
`
`
`
`
`By Authority of the
`
`Under Secretary of Commerce for Intellectual Property
`and Director of the United States Patent and Trademark Office
`
`
`
`
`
` Certifying Officer
`
`
`
`NOAC EX- 1019...???
`
`
`NOAC Ex. 1019 Page 1
`
`
`
`
`Attorney Docket No.
`APPT-001 -1 -1
`UTILITY PATENT APPLICATION
`
`
`
`
`
`
`
`TRANSMITTAL
`
`Russell 3. Dietz
`
`Title
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`o
`
`N
`
`
`
`
`
`
`(New Nonprovisional Applicati ns Under 37 CFR §
`
`
`1.53(b))
`
`EV325162991US
`Express Mail Label No.
`
`
`
`
`_ Mail Stop Patent Application
`
`
`APPLICATION ELEMENTS
`ADDRESS TO. Commissioner for Patents
`0) {\
`PO. Box 1450
`
`
`
`Alexandria, VA 22313-1450 _
`
`
`
`7. El CD-ROM in duplicate, large table, or computer p'r
`1. B Fee transmittal form (in duplicate)
`(Appendix)
`
`
`2. I] Applicant(s) claim(s) a small entity status.
`
`
`
`
`
`
`
`Assignment papers (cover sheet & documents)
`10. III 37 CFR 3.730;) statement. [I Power of
`Attorney 5. IE Declaration and IX] Power of Attorney
`
`
`
` a. D Newly executed (original or copy)
` English translation document.
`
` b.
`
`Copy from prior application for continuing
`Information Disclosure Statement (Form PTO-1449)
`application with box 18 completed
`and copies of IDS citations.
`
` i. D DELETION OF INVENTOR(S)
`Preliminary Amendment.
`signed statement attached deleting
`
`
`inventor(s) named in the prior application.
`Return Receipt postcard.
`
`
` 6. D Application Data Sheet
`
` Certified copies of priority documents.
` Request and certification under 35 USC 122
`
`(b)(2l(B)(i)-
`
`
`3.
`
`67
`
`sheet(s) of specification, claims, and abstract
`
`sheet(s) of formal Drawing(s) with a
`4. E 18
`submission letter to the Official Draftsperson
`
`8. D Nucleotide &/or amino acid sequence submission
`
`
`
`
`
`18. If a CONTINUING APPLICATION, check appropriate box, and supply the requisite information below and in a preliminary
`amendment, or in an Application Data Sheet under 37 CFR 1.76:
`
`E Continuation .
`
`D Divisional.
`
`D Continuation in
`part (CIP).
`
`Of prior application no:
`
`Other: List of inventors, with residence city,
`stuntate/co _.
`
`
`
`
`
`
`
`
`
`
`Prior application information.
`Examiner: Khanh Q_ DINH
`Group Art Unit:
`2155
`
`
` For CONTINUATION OR DIVISIONAL APPLICATIONS ONLY: the entire disclosure of the prior application, from which an oath or declaration is
`
`supplied under item 5b, is considered a part of the disclosure of the accompanying continuation or divisional application and is hereby incorporated by
`reference. The incorporation can only be relied upon when a portion has been inadvertently omitted from the submitted application parts.
`
`19. CORRESPONDENCE ADDRESS
`
`(Name: Dov Rosenfeld, INVENTEK)
`21921.
`Customer Number:
`
`
`
`.
`t
`:
`Signa ure
`
`
`’
`/
`[11/
`I
`
`
`D t
`:
`I31'ln ,2003
`OC‘I’
`
`
`Certificate of Mailing under 37 CFR 1.10
`
`Name: Dov R enfeld, Reg. No. 38687
`
`I hereby certify that this application and all attachments are being deposited with the United States Postal Service as
`Express Mail (Express Mail Label: EV325162991US in an envelope addressed to Mail Stop Patent Application,
`Commissioner for Patents, PO. Box 1450, Alexandria, VA 22313—1450 on.
`Date:
`Q51: A} 20:23
`Signed:
`[‘1'
`
`NOAC EX. 1019 Page 2
`
`NOAC Ex. 1019 Page 2
`
`
`
`
`
`FEE TRANSMITTAL
`
`Attorney Docket No.
`
`AP PT-001 -1 -1
`
`(New Nonprovisional Applications Under
`37CFR§153m»
`
`First Inventor Russell 8. Dietz
`
`
`
`
`
`
`
`
`
`
`
`Title
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`$242.00 $73364) Express Mail Label No.
`
`EV325162991US
`
`
`
`1. IXI The commissioner is hereby authorized to charge any missing fees and credit any overpayment to
`
`METHOD OF PAYMENT
`
`Deposit
`Account
`Number
`
`50-0292
`
`' Deposit
`Account
`Name
`
`INVENTEK/ROSENFELD
`
`D Applicant(s) claim(s) a small entity status.
`
`2. EI Payment is enclosed:
`
`form enclosed
`
`U check
`
`E credit card.
`(Credit Card Charge
`
`D Money order
`
`NO. FILED
`
`NO. EXTRA
`
`49
`
`29
`
` FEE CALCULATION
`CLAIMS AS FILED
`
`
`OTHER THAN SMALL ENTITY
`
`
`
`
`
`
`Total Claims
` Independent
`
`
`Claims
` Multiple Dependent Claims (if applicable)
`
`$0.00
` Assignment Recording Fee
`$0.00
`
`$770.00
`Basic Filing Fee
`
`
`
` Total Filing Fee
`$1,292.00
`
`RATE
`
`$18.00
`
`$86.00
`
`$ 522.00
`
`$ 0.00
`
`
`
`
`
`
`SUBMITTED BY
`
`K Customer Number:
`
`21921.
`
`(Dov Rosenfeld, INVENTEK)
`
`m DOV Rosenfeld, - - gisuafion' No'
`'- I,/
`
`I
`
`38687
`
`
`
`
`
`//'
`
`
`
`NOAC EX. 1019 Page 3
`
`NOAC Ex. 1019 Page 3
`
`
`
`Our Ref/Docket No: APPT-OOI- 1-1
`
`Patent
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`First Inventor Russell 8. Dietz
`
`APPT-001 -1 -1
`
`
`
`Attorney Docket No.
`
`
`INVENTOR(S)IAPPLICANT(S)
`
`
`
`
`(New Nonprovisional Applications Under 37
`CFR § 1.53(b))
`
`
`
`
`Title
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`Express Mail Label No.
`
`EV325162991US
`
`
`
`Last Name
`
`Residence (City and Either Citizenship
`State or Foreign Country)
`
`
`First Name, MI
`
`Dietz
`
`Maixner
`
`Russell 8.
`
`Joseph R.
`
`San Jose, California, USA
`
`Aptos, California, USA
`
`Koppenhaver
`
`Andrew A.
`
`Littleton, CO, USA
`
`Bares
`
`William H.
`
`Germantown, TN, USA
`
`Sarkissian
`
`Haig A.
`
`San Antonio, Texas, USA
`
`Torgerson
`
`James F.
`
`Andover, MN, USA
`
`US
`
`US
`
`US
`
`US
`
`US
`
`US
`
`NOAC EX. 1019 Page 4
`
`NOAC Ex. 1019 Page 4
`
`
`
`Our Ref./Docket No: APPT-OOl— 1 —1
`
`Patent
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`Applicant(s): Dietz, et al.
`
`Title: METHOD AND APPARATUS FOR
`
`
`
`MONITORING TRAFFIC IN A NETWORK
`
`
`Group Art Unit: unassigned
`
`Examiner: unassigned
`
`LETTER TO OFFICIAL DRAFTSPERSON
`
`SUBMISSION OF FORMAL DRAWINGS
`
`The Commissioner for Patents
`PO. Box 1450
`
`Alexandria, VA 22313-1450
`
`A'ITN: Official Draftsperson
`
`Dear Sir or Madam:
`
`Attached please find E sheets of formal drawings to be made of record for the above-
`identified patent application submitted herewith.
`
`I3.?.DD§
`
`Oct
`Date
`
`Respectfully Submitted,
`
`
`
`enfeld, Reg. No. 38687
`
`Address for correspondence and attorney for applicant(s):
`Dov Rosenfeld, Reg. No. 38,687
`5507 College Avenue, Suite 2
`Oakland, CA 94618
`
`Telephone: (510) 547-3378; Fax: (510) 653-7992
`
`
`
`Certificate of Mailing under 37 CFR 1.10
`I hereby certify that this application and all attachments are being deposited with the United States Postal
`
`Service as Express Mail (Express Mail Label: EV325162991US in an envelope addressed I
`ail Stop
`Patent Application, Commissioner for Patents, PO. Box 1450, Alexandria, V
`-
`50 on.
`Date: Oct g , 2.00 3
`Signed:
`
`I
`Name: Dov Rosenfeld, Reg. No. 38687
`
`
`
`
`NOAC EX. 1019 Page 5
`
`NOAC Ex. 1019 Page 5
`
`
`
`(New Nonprovisional Applications Under
`37 CFR § 1.53(b))
`
`First Inventor Russell S. Dietz
`
`
`
`FEE TRANSMITTAL
`
`
`
`_$lztu .00 W Express Mail Label No.
`
`
`
`EV325162991US
`
`
`
`Title
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`METHOD OF PAYMENT
`
`1. E The commissioner is hereby authorized to charge any missing tees and credit any overpayment to
`
`form enclosed
`
`Deposit
`Account
`Number
`
`Deposit
`Account
`Name
`
`50-0292
`
`INVENTEK/ROSENFELD
`
`D Applicant(s) claim(s) a small entity status.
`
`2. E Payment is enclosed:
`
`D check
`
`IX] credit card.
`(Credit Card Charge
`
`U Money order
`
`
`FEE CALCULATION
`CLAIMS AS FILED
`
`OTHER THAN SMALL ENTITY
`NO. FILED
` NO. EXTRA
`RATE
`49
`2
`
`
`$18.00
`Total Claims
`$ 522.00
`
`
`Independent
`Claims
`
`Multiple Dependent Claims (if applicable)
`$0.00
`$0.00
`Assignment Recording Fee
`
`
`
`$770.00
`
`
`$1 292.00
`Total Filing Fee
`
`$86.00
`
`$ 0.00
`
`Basic Filing Fee
`
`
`
`SUBMITTED BY
`
`
`
`
`21921 _Customer Number: (DOV Rosenfeld, INVENTEK)
`
`
`
`
`
`
`
`
`NOAC EX. 1019 Page 6
`
`NOAC Ex. 1019 Page 6
`
`
`
`Our Ref/Docket No.2 APPT-OOl - 1- 1
`
`METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A
`
`NETWORK
`
`Inventor(s):
`
`DIETZ, Russell S.
`
`San Jose, California, USA
`
`MAIXNER, Joseph R.
`Aptos, California, USA
`
`KOPPENHAVER, Andrew A.
`
`Littleton, CO, USA
`
`BARES, William H.
`
`Germantown, TN, USA
`
`SARKISSIAN, Haig A.
`San Antonio, Texas, USA
`
`TORGERS ON, James F.
`
`Andover, MN, USA
`
`
` Certificate of Mailing under 37 CFR 1.10
`
`
`I hereby certify that this application and all attachments are being deposited with the United States Postal Service as
`Express Mail (Express Mail Label: EV325162991US in an envelope addressed to Mail Stop Patent Application,
`
`
`Commissioner for Patents, PO. Box 1450, Alexandria, VA 22313—1450 on.
`
`
`
`Date:
`
`06" g , ZQQS
`[‘0‘
`
`Signed:
`Name: Dov Rosen e (1, Reg. No. 38687
`
`NOAC EX. 1019 Page 7
`
`NOAC Ex. 1019 Page 7
`
`
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`CROSS-REFERENCE TO RELATED APPLICATION
`
`[0001]
`
`This invention is a continuation of U.S. Patent Application Serial No. 09/608237 for
`
`METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A NETWORK to
`
`inventors Dietz, et al., filed June 30, 2000, Attomey/Agent Reference Number APPT-OOl-l,
`
`the contents of which are incorporated herein by reference
`
`[0002]
`
`This invention claims the benefit of U.S. Provisional Patent Application Serial No.:
`
`60/141,903 for METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A
`
`NETWORK to inventors Dietz, et al., filed June 30, 1999, the contents of which are
`
`incorporated herein by reference.
`
`[0003]
`
`This application is related to the following U.S. patent applications, each filed
`
`concurrently with the present application, and each assigned to the assignee of the present
`
`invention:
`
`[0004]
`
`U.S. Patent Application Serial No. 09/609179 for PROCESSING PROTOCOL
`
`SPECIFIC INFORMATION IN PACKETS SPECIFIED BY A PROTOCOL DESCRIPTION
`
`LANGUAGE, to inventors Koppenhaver, et al., filed June 30, 2000, Attorney/Agent
`
`Reference Number APPT-001—2, and incorporated herein by reference.
`
`[0005]
`
`U.S. Patent Application Serial No. 09/608126 for RE—USING INFORMATION
`
`FROM DATA TRANSACTIONS FOR MAINTAINING STATISTICS IN NETWORK
`
`MONITORING, to inventors Dietz, et al., filed June 30, 2000, Attorney/Agent Reference
`
`Number APPT-OOl—3, and incorporated herein by reference.
`
`[0006]
`
`U.S. Patent Application Serial No. 09/608266 for ASSOCIATIVE CACHE
`
`STRUCTURE FOR LOOKUPS AND UPDATES OF FLOW RECORDS IN A NETWORK
`
`MONITOR, to inventors Sarkissian, et al., filed June 30, 2000, Attorney/Agent Reference
`
`Number APPT-001-4, and incorporated herein by reference.
`
`[0007]
`
`U.S. Patent Application Serial No. 09/608267 for STATE PROCESSOR FOR
`
`PATTERN MATCHING IN A NETWORK MONITOR DEVICE, to inventors Sarkissian, et
`
`APPT-001-1-1
`
`NOAC EX. 1019 Page 8
`
`NOAC Ex. 1019 Page 8
`
`
`
`al., filed June 30, 2000, Attomey/Agent Reference Number APPT-OOl-S, and incorporated
`
`2
`
`herein by reference.
`
`FIELD OF INVENTION
`
`[0008]
`
`The present invention relates to computer networks, specifically to the real—time
`
`elucidation of packets communicated within a data network, including classification
`
`according to protocol and application program.
`
`BACKGROUND TO THE PRESENT INVENTION
`
`[0009]
`
`There has long been a need for network activity monitors. This need has become
`
`especially acute, however, given the recent popularity of the Internet and other internets—an
`
`“internet” being any plurality of interconnected networks which forms a larger, single
`
`network. With the growth of networks used as a collection of clients obtaining services from
`
`one or more servers on the network, it is increasingly important to be able to monitor the use
`
`of those services and to rate them accordingly. Such objective information, for example, as
`
`which services (i.e., application programs) are being used, who is using them, how often they
`
`have been accessed, and for how long, is very useful in the maintenance and continued
`
`operation of these networks. It is especially important that selected users be able to access a
`
`network remotely in order to generate reports on network use in real time. Similarly, a need
`
`exists for a real—time network monitor that can provide alarms notifying selected users of
`
`problems that may occur with the network or site.
`
`[0010]
`
`One prior art monitoring method uses log files. In this method, selected network
`
`activities may be analyzed retrospectively by reviewing log files, which are maintained by
`
`network servers and gateways. Log file monitors must access this data and analyze (“mine”)
`
`its contents to determine statistics about the server or gateway. Several problems exist with
`
`this method, however. First, log file information does not provide a map of real-time usage;
`
`and secondly, log file mining does not supply complete information. This method relies on
`
`logs maintained by numerous network devices and servers, which requires that the
`
`information be subjected to refining and correlation. Also, sometimes information is simply
`
`not available to any gateway or server in order to make a log file entry.
`
`APPT—OO 1- 1-1
`
`NOAC EX. 1019 Page 9
`
`NOAC Ex. 1019 Page 9
`
`
`
`3
`
`[0011]
`
`One such case, for example, would be information concerning NetMeeting®
`
`(Microsoft Corporation, Redmond, Washington) sessions in which two computers connect
`
`directly on the network and the data is never seen by a server or a gateway.
`
`[0012]
`
`Another disadvantage of creating log files is that the process requires data logging
`
`features of network elements to be enabled, placing a substantial load on the device , which
`
`results in a subsequent decline in network performance. Additionally, log files can grow
`
`rapidly, there is no standard means of storage for them, and they require a significant amount
`
`of maintenance.
`
`[0013]
`
`Though Netflow® (Cisco Systems, Inc., San Jose, California), RMON2, and other
`
`network monitors are available for the real-time monitoring of networks, they lack visibility
`
`into application content and are typically limited to providing network layer level
`
`information.
`
`[0014]
`
`Pattern—matching parser techniques wherein a packet is parsed and pattern filters are
`
`applied are also known, but these too are limited in how deep into the protocol stack they can
`
`examine packets.
`
`[0015]
`
`Some prior art packet monitors classify packets into connection flows. The term
`
`“connection flow” is commonly used to describe all the packets involved with a single
`
`connection. A conversational flow, on the other hand, is the sequence of packets that are
`
`exchanged in any direction as a result of an activity—for instance, the running of an
`
`application on a server as requested by a client. It is desirable to be able to identify and
`
`classify conversational flows rather than only connection flows. The reason for this is that
`
`some conversational flows involve more than one connection, and some even involve more
`
`than one exchange of packets between a client and server. This is particularly true when using
`
`client/server protocols such as RPC, DCOMP, and SAP, which enable a service to be set up
`
`or defined prior to any use of that service.
`
`[0016]
`
`An example of such a case is the SAP (Service Advertising Protocol), a NetWare
`
`(Novell Systems, Provo, Utah) protocol used to identify the services and addresses of servers
`
`attached to a network. In the initial exchange, a client might send a SAP request to a server
`
`for print service. The server would then send a SAP reply that identifies a particular
`
`APPT-001-1-1
`
`NOAC EX. 1019 Page 10
`
`NOAC Ex. 1019 Page 10
`
`
`
`4
`
`address—for example, SAP#5——as the print service on that server. Such responses might be
`
`used to update a table in a router, for instance, known as a Server Information Table. A client
`
`who has inadvertently seen this reply or who has access to the table (via the router that has
`
`the Service Information Table) would know that SAP#5 for this particular server is a print
`
`service. Therefore, in order to print data on the server, such a client w0uld not need to make a
`
`request for a print service, but would simply send data to be printed specifying SAP#5. Like
`
`the previous exchange, the transmission of data to be printed also involves an exchange
`
`between a client and a server, but requires a second connection and is therefore independent
`
`of the initial exchange. In order to eliminate the possibility of disjointed conversational
`
`exchanges, it is desirable for a network packet monitor to be able to “virtually concatenate”—
`
`that is, to link—the first exchange with the second. If the clients were the same, the two
`
`packet exchanges would then be correctly identified as being part of the same conversational
`
`flow.
`
`[0017]
`
`Other protocols that may lead to disjointed flows, include RPC (Remote Procedure
`
`Call); DCOM (Distributed Component Object Model), formerly called Network OLE
`
`(Microsoft Corporation, Redmond, Washington); and CORBA (Common Object Request
`
`Broker Architecture). RPC is a programming interface from Sun Microsystems (Palo Alto,
`
`California) that allows one program to use the services of another program in a remote
`
`machine. DCOM, Microsoft’s counterpart to CORBA, defines the remote procedure call that
`
`allows those objects—objects are self-contained software modules—to be run remotely over
`
`the network. And CORBA, a standard from the Object Management Group (OMG) for
`
`communicating between distributed objects, provides a way to execute programs (objects)
`
`written in different programming languages running on different platforms regardless of
`
`where they reside in a network.
`
`[0018] What is needed, therefore, is a network monitor that makes it possible to continuously
`
`analyze all user sessions on a heavily trafficked network. Such a monitor should enable non-
`
`intrusive, remote detection, characterization, analysis, and capture of all information passing
`
`through any point on the network (i.e., of all packets and packet streams passing through any
`
`location in the network). Not only should all the packets be detected and analyzed, but for
`
`each of these packets the network monitor should determine the protocol (e. g., http, ftp,
`
`APPT—001-1-1
`
`NOAC EX. 1019 Page 11
`
`NOAC Ex. 1019 Page 11
`
`
`
`5
`
`H.323, VPN, etc.), the application/use within the protocol (e. g., voice, video, data, real—time
`
`data, etc.), and an end user’s pattern of use within each application or the application context
`
`(e. g., options selected, service delivered, duration, time of day, data requested, etc.). Also, the
`
`network monitor should not be reliant upon server resident information such as log files.
`
`Rather, it should allow a user such as a network administrator or an Internet service provider
`
`(ISP) the means to measure and analyze network activity objectively; to customize the type of
`
`data that is collected and analyzed; to undertake real time analysis; and to receive timely
`
`notification of network problems.
`
`[0019]
`
`Considering the previous SAP example again, because one features of the invention is
`
`to correctly identify the second exchange as being associated with a print service on that
`
`server, such exchange would even be recognized if the clients were not the same. What
`
`distinguishes this invention from prior art network monitors is that it has the ability to
`
`recognize disjointed flows as belonging to the same conversational flow.
`
`[0020]
`
`The data value in monitoring network communications has been recognized by many
`
`inventors. Chiu, et al., describe a method for collecting information at the session level in a
`
`computer network in United States Patent 5,101,402, titled “APPARATUS AND METHOD
`
`FOR REAL-TIME MONITORING OF NETWORK SESSIONS AND A LOCAL AREA
`
`NETWORK” (the “402 patent”). The 402 patent specifies fixed locations for particular types
`
`of packets to extract information to identify session of a packet. For example, if a DECnet
`
`packet appears, the 402 patent looks at six specific fields (at 6 locations) in the packet in
`
`order to identify the session of the packet. If, on the other hand, an IP packet appears, a
`
`different set of six different locations is specified for an IP packet. With the proliferation of
`
`protocols, clearly the specifying of all the possible places to look to determine the session
`
`becomes more and more difficult. Likewise, adding a new protocol or application is difficult.
`
`In the present invention, the locations examined and the information extracted from any
`
`packet are adaptively determined from information in the packet for the particular type of
`
`packet. There is no fixed definition of what to look for and where to look in order to form an
`
`identifying signature. A monitor implementation of the present invention, for example, adapts
`
`to handle differently IEEE 802.3 packet from the older Ethernet Type 2 (or Version 2) DIX
`
`(Digital-Intel-Xerox) packet.
`
`APPT—001-1—1
`
`NO‘AC EX. 1019 Page 12
`
`NOAC Ex. 1019 Page 12
`
`
`
`6
`
`[0021]
`
`The 402 patent system is able to recognize up to the session layer. In the present
`
`invention, the number of levels examined varies for any particular protocol. Furthermore, the
`
`present invention is capable of examining up to whatever level is sufficient to uniquely
`
`identify to a required level, even all the way to the application level (in the 081 model).
`
`[0022]
`
`Other prior art systems also are known. Phael describes a network activity monitor
`
`that processes only randomly selected packets in United States Patent 5,315,580, titled
`
`“NETWORK MONITORING DEVICE AND SYSTEM.” Nakamura teaches a network
`
`monitoring system in United States Patent 4,891,639, titled “MONITORING SYSTEM OF
`
`NETWORK.” Ross, et al., teach a method and apparatus for analyzing and monitoring
`
`network activity in United States Patent 5,247,517, titled “METHOD AND APPARATUS
`
`FOR ANALYSIS NETWORKS,” McCreery, et al., describe an Internet activity monitor that
`
`decodes packet data at the Internet protocol level layer in United States Patent 5,787,253,
`
`titled “APPARATUS AND METHOD OF ANALYZING INTERNET ACTIVITY.” The
`
`McCreery method decodes IP-packets. It goes through the decoding operations for each
`
`packet, and therefore uses the processing overhead for both recognized and unrecognized
`
`flows. In a monitor implementation of the present invention, a signature is built for every
`
`flow such that future packets of the flow are easily recognized. When a new packet in the
`
`flow arrives, the recognition process can commence from where it last left off, and a new
`
`signature built to recognize new packets of the flow.
`
`SUMMARY
`
`[0023]
`
`In its various embodiments the present invention provides a network monitor that can
`
`accomplish one or more of the following objects and advantages:
`
`[0024]
`
`[0025]
`
`[0026]
`
`o
`
`o
`
`0
`
`Recognize and classify all packets that are exchanges between a client and
`
`server into respective client/server applications.
`
`Recognize and classify at all protocol layer levels conversational flows that pass
`
`in either direction at a point in a network.
`
`Determine the connection and flow progress between clients and servers
`
`according to the individual packets exchanged over a network.
`
`APPT-001-1-1
`
`NOAC EX. 1019 Page 13
`
`NOAC Ex. 1019 Page 13
`
`
`
`7
`
`[0027]
`
`Be used to help tune the performance of a network according to the current mix
`
`of client/server applications requiring network resources.
`
`[0028]
`
`Maintain statistics relevant to the mix of client/server applications using
`
`network resources.
`
`[0029]
`
`Report on the occurrences of specific sequences of packets used by particular
`
`applications for client/server network conversational flows.
`
`[0030]
`
`Other aspects of embodiments of the invention are:
`
`[0031]
`
`Properly analyzing each of the packets exchanged between a client and a server
`
`and maintaining information relevant to the current state of each of these
`
`conversational flows.
`
`[0032]
`
`Providing a flexible processing system that can be tailored or adapted as new
`
`applications enter the client/server market.
`
`[0033]
`
`Maintaining statistics relevant to the conversational flows in a client/sever
`
`network as classified by an individual application.
`
`[0034]
`
`Reporting a specific identifier, which may be used by other network-oriented
`
`devices to identify the series of packets with a specific application for a specific
`
`client/server network conversational flow.
`
`[0035]
`
`In general, the embodiments of the present invention overcome the problems and
`
`disadvantages of the art.
`
`[0036]
`
`As described herein, one embodiment analyzes each of the packets passing through
`
`any point in the network in either direction, in order to derive the actual application used to
`
`communicate between a client and a server. Note that there could be several simultaneous
`
`and overlapping applications executing over the network that are independent and
`
`asynchronous.
`
`[0037]
`
`A monitor embodiment of the invention successfully classifies each of the individual
`
`packets as they are seen on the network. The contents of the packets are parsed and selected
`
`parts are assembled into a signature (also called a key) that may then be used identify further
`
`APPT—001-1-1
`
`NOAC EX. 1019 Page 14
`
`NOAC Ex. 1019 Page 14
`
`
`
`8
`
`packets of the same conversational flow, for example to further analyze the flow and
`
`ultimately to recognize the application program. Thus the key is a function of the selected
`
`parts, and in the preferred embodiment, the function is a concatenation of the selected parts.
`
`The preferred embodiment forms and remembers the state of any conversational flow, which
`
`is determined by the relationship between individual packets and the entire conversational
`
`flow over the network. By remembering the state of a flow in this way, the embodiment
`
`determines the context of the conversational flow, including the application program it relates
`
`to and parameters such as the time, length of the conversational flow, data rate, etc.
`
`[0038]
`
`The monitor is flexible to adapt to future applications developed for client/server
`
`networks. New protocols and protocol combinations may be incorporated by compiling files
`
`written in a high—level protocol description language.
`
`[0039]
`
`The monitor embodiment of the present invention is preferably implemented in
`
`application—specific integrated circuits (ASIC) or field programmable gate arrays (FPGA). In
`
`one embodiment, the monitor comprises a parser subsystem that forms a signature from a
`
`packet. The monitor further comprises an analyzer subsystem that receives the signature from
`
`the parser subsystem.
`
`[0040]
`
`A packet acquisition device such as a media access controller (MAC) or a
`
`segmentation and reassemble module is used to provide packets to the parser subsystem of
`
`the monitor.
`
`[0041]
`
`In a hardware implementation, the parsing subsystem comprises two sub-parts, the
`
`pattern analysis and recognition engine (PRE), and an extraction engine (slicer). The PRE
`
`interprets each packet, and in particular, interprets individual fields in each packet according
`
`to a pattern database.
`
`[0042]
`
`The different protocols that can exist in different layers may be thought of as nodes of
`
`one or more trees of linked nodes. The packet type is the root of a tree. Each protocol is either
`
`a parent node or a terminal node. A parent node links a protocol to other protocols (child
`
`protocols) that can be at higher layer levels. For example, An Ethernet packet (the root node)
`
`may be an Ethertype packet—also called an Ethernet Type/Version 2 and a DIX (DIGITAL—
`
`Intel-Xerox packet)—or an IEEE 802.3 packet. Continuing with the IEEE 802.3-type packet,
`
`APPT—001-1-1
`
`NOAC EX. 1019 Page 15
`
`NOAC Ex. 1019 Page 15
`
`
`
`9
`
`one of the children nodes may be the IP protocol, and one of the children of the IP protocol
`
`may be the TCP protocol.
`
`[0043]
`
`The pattern database includes a description of the different headers of packets and
`
`their contents, and how these relate to the different nodes in a tree. The PRE traverses the tree
`
`as far as it can. If a node does not include a link to a deeper level, pattern matching is
`
`declared complete. Note that protocols can be the children of several parents. If a unique
`
`node was generated for each of the possible parent/child trees, the pattern database might
`
`become excessively large. Instead, child nodes are shared among multiple parents, thus
`
`compacting the pattern database.
`
`[0044]
`
`Finally the PRE can be used on its own when only protocol recognition is required.
`
`[0045]
`
`For each protocol reco nized, the slicer extracts important packet elements from the
`g
`
`packet. These form a signature (i. 6., key) for the packet. The slicer also preferably generates a
`
`hash for rapidly identifying a flow that may have this signature from a database of known
`
`flows.
`
`[0046]
`
`The flow signature of the packet, the hash and at least some of the payload are passed
`
`to an analyzer subsystem. In a hardware embodiment, the analyzer subsystem includes a
`
`unified flow key buffer (UFKB) for receiving parts of packets from the parser subsystem and
`
`for storing signatures in process, a lookup/update engine (LUE) to lookup a database of flow
`
`records for previously encountered. conversational flows to determine whether a signature is
`
`from an existing flow, a state processor (SP) for performing state processing, a flow insertion
`
`and deletion engine (FIDE) for inserting new flows into the database of flows, a memory for
`storing the database of flows, and a cache for speeding up access to the memory containing
`
`the flow database. The LUE, SP, and FIDE are all coupled to the UFKB, and to the cache.
`
`[0047]
`
`The unified flow key buffer thus contains the flow signature of the packet, the hash
`
`and at least some of the payload for analysis in the analyzer subsystem. Many operations can
`
`be performed to further elucidate the identity of the application program content of the packet
`
`involved in the client/server conversational flow while a packet signature exists in the unified
`
`flow signature buffer. In the particular hardware embodiment of the analyzer subsystem
`
`APPT—001-1—1
`
`NOAC EX. 1019 Page 16
`
`NOAC Ex. 1019 Page 16
`
`
`
`10
`
`several flows may be processed in parallel, and multiple flow signatures from all the packets
`
`being analyzed in parallel may be held in the one UFKB.
`
`[0048]
`
`The first step in the packet analysis process of a packet from the parser subsystem is
`
`to lookup the instance in the current database of known packet flow signatures. A
`
`lookup/update engine (LUE) accomplishes this task using first the hash, and then the flow
`
`signature. The search is carried out in the cache and if there is no flow with a matching
`
`signature in the cache, the lookup engine attempts to retrieve the flow from the flow database
`
`in the memory. The flow-entry for previously encountered flows preferably includes state
`
`information, which is used in the state processor to execute any operations defined for the
`
`state, and to determine the next state. A typical state operation may be. to search for one or
`
`more known reference strings in the payload of the packet stored in the UFKB.
`
`[0049]
`
`Once the lookup processing by the LUE has been completed a flag stating whether it
`
`is found or is new is set within the unified flow signature buffer structure for this packet flow
`
`signature. For an existing flow, the flow-entry is updated by a calculator component of the
`
`LUE that adds values to counters in the flow-entry database used to store one or more
`
`statistical measures of the flow. The counters are used for determining network usage metrics
`
`on the flow.
`
`[0050]
`
`After the packet flow signature has been looked up and contents of the current flow
`
`signature are in the database, a state processor can begin analyzing the packet payload to
`
`further elucidate the identity of the application program component of this packet. The exact
`
`operation of the state processor and functions performed by it will vary depending on the
`
`current packet sequence in the stream of a conversational flow. The state processor moves to
`
`the next logical operation stored from the previous packet seen with this same flow signature.
`
`If any processing is required on this packet, the state processor will execute instructions from
`
`a database of state instruction for this state until there are either no more left or the instruction
`
`signifies processing.
`
`[0051]
`
`In the preferred embodiment, the state processor functions are programmable to
`
`provide for analyzing new application programs, and new sequences of packets and states
`
`that can arise from using such application.
`
`APPT-001-1—1
`
`NOAC EX. 1019 Page 17
`
`NOAC Ex. 1019 Page 17
`
`
`
`11
`
`[0052]
`
`If during the lookup process for this particular packet flow signature, the flow is
`
`required to be inserted into the active database, a flow insertion and deletio