q
`
`UTILITY PATENT APPLICATION
`TRANSMITTAL
`
`(Now Nonprovisional Applicati ns Under 37 CFR
`1.53(b))
`
`Aftomey Docket No. I APPT-001 -1 -1
`
`First Inventor I Russell S. Dietz
`I METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`Title
`
`Express Mail Label No.
`
`I EV325162991 US
`
`APPLICATION ELEMENTS
`
`ADDRESSTO:
`
`Mail Stop Patent Application
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`LL
`
`(6
`
`:
`
`OC)
`
`1.
`
`2.
`
`3.
`
`Fee transmittal form (in duplicate)
`
`Applicant(s) claim(s) a small entity status.
`
`67
`
`sheet(s) of specification, claims, and abstract
`
`4. El 18
`
`sheet(s) of formal Drawing(s) with a
`
`submission lefter to the Official Draftsperson
`
`5. XM Declaration and [9 Power of Attorney
`
`El CD-ROM in duplicate, large table, or computer OrAid
`C%j T--
`N
`(Appendix)
`
`El Nucleotide Wor amino acid sequence submission
`
`ACCOMPANYING APPLICATION PARTS
`
`1] Assignment papers (cover sheet & documents)
`0 37 CFR 3.73(b) statement. [] Power of
`Attorney
`
`El Newly executed (original or copy)
`
`0 English translation document.
`
`El Copy from pfior application for continuing
`
`application with box 18 completed
`
`0 Information Disclosure Statement (Form PTO-1449)
`and copies of IDS citations.
`
`i. 0 DELETION OF INVENTOR(S)
`signed statement attached deleting
`inventor(s) named in the prior application.
`
`El Preliminary Amendment.
`
`[91 Return Receipt postcard.
`
`6. 0 Application Data Sheet
`
`11 Certified copies of priority documents.
`
`Request and certification under 35 USC 122
`
`(b)(2)(13)(i).
`
`Other: List of inve*ntors, with residence citV,
`
`18. If a CONTINUING APPLICATION, check appropriate box, and supply the requisite information below and ina preliminary
`amendment, or in an Application Data Sheet under 37 CFR 1.76:
`
`0 Continuation
`
`El Divisional.
`
`Continuation in
`
`of prior application no:
`
`Prior application information.
`
`Examiner:
`
`Khanh 0. DINH
`
`Group Art Unit:
`
`2155
`
`part (CIP).
`
`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.
`
`El Customer Number:
`
`21921. 1 (Name: Dov Rosenfeld, INVENTEK)
`
`19. CORRESPONDENCE ADDRESS
`
`Name:
`
`Signature:
`
`Dov Rosenfeld,
`
`Registration. No.
`
`38687
`
`Date:
`
`Ocf 134, ) Z00,2
`
`Certiricate 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,
`
`Cominissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on.
`
`Date:
`
`Oct A- 7 nn;&
`If
`
`Signed:
`
`Name: Dov R enfe d, Reg. No. 38687
`
`Petitioners' EX1017 Page 1
`
`

`
`FEE TRANSMITTAL
`
`Attomey Docket No.
`
`I APPT-001 -1 -1
`
`(New Nonprovisional Applications Under
`37 CFR § 1.53(b))
`
`Firstinventor
`
`RussellS.Dietz
`
`TOTAL PAYMENT j$J'Zq2.0O $-7;4p Express Mail Label O-T
`
`EV325162991 US
`
`I
`
`Title
`
`I METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`1. [E] The commissioner is hereby authorized to charge any missing fees and credit any overpayment to
`
`METHOD OF PAYMENT
`
`Deposit
`Account
`Number
`
`Deposit
`Account
`Name
`
`50-0292
`
`INVENT EK/ROSEN FELD
`
`0 Applicant(s) claim(s) a small entity status.
`
`2. El Payment is enclosed:
`
`0 check
`
`El credit card.
`
`Money order
`
`D Other
`
`(Credit Card Charge
`
`form enclosed)
`
`FEE CALCULATION
`
`CLAIMS AS FILED
`
`NO. FILED
`
`NO.EXTRA
`
`OTHER THAN SMALL ENTITY
`RATE
`
`FEE
`
`49
`
`3
`
`29
`
`0
`
`$18.00
`
`$86.00
`
`FOR
`
`Total Claims
`Independent
`Claims
`
`$522.00
`
`$ 0.00
`
`$0.00
`
`$0.00
`
`$770.00
`
`Multiple Dependent Claims (if applicable)
`
`Assignment Recording Fee
`
`Basic Filing Fee
`
`Total Filing Fee
`
`$1,292.00
`
`Customer Number:
`
`21921. 1 (Dov Rosenfeld, INVENTEK)
`
`SUBMITTED BY
`
`Name:
`
`Signature:
`
`Dov Rosentel
`
`gistration.
`
`No.:
`
`38687
`
`I Date:
`
`or-t- 11, -ZOO-3
`
`Petitioners' EX1017 Page 2
`
`

`
`Our Ref./Docket No: APPT-00 I - I - I
`
`Patent
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`INVENTOR(S)IAPPLICANT(S)
`
`(New Nonprovisional Applications Under 37
`CFR § 1.53(b))
`
`A ftomey Docket No. 7 A P PT-00 1 - 1 - 1
`First Inventor Russell S. Dietz
`
`I
`
`Title
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`Express Mail Label No.
`
`EV325162991 US
`
`Last Name
`
`First Name, MI
`
`Residence (City and Either Citizenship
`State or Foreign Country)
`
`Dietz
`
`Maixner
`
`Koppenhaver
`
`Bares
`
`Sarkissian
`
`Torgerson
`
`Russell S.
`
`Joseph R.
`
`Andrew A
`
`William H.
`
`Haig A.
`
`James F.
`
`San Jose, California, USA
`
`Aptos, California, USA
`
`Littleton, CO, USA
`
`Germantown, TN, USA
`
`San Antonio, Texas, USA
`
`Andover, MN, USA
`
`us
`us
`us
`us
`us
`us
`
`Petitioners' EX1017 Page 3
`
`

`
`Our Ref./Docket No: APPT-001-1-1
`
`Patent
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Applicant(s): Dietz, et al.
`
`Title: METHOD AND APPARATUS FOR
`MONrFORING TRAFFIC IN A NETWORK
`
`Group Art Unit: unassigned
`
`Examiner: unassigned
`
`LETTER TO OFFICIAL DRAFTSPERSON
`SUBMISSION OF FORMAL DRAWINGS
`
`The Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`ATIN: Official Draftsperson
`
`Dear Sir or Madam:
`
`Attached please find 18 sheets of formal drawings to be made of record for the above-
`
`identified patent application submitted herewith.
`
`Respectfully Submitted,
`
`0&-t I -'
`Date
`
`Dy,Vlgenfeld, Reg. No. 38687
`
`Address for correspondence and attomey 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
`
`I hereby certify that this application and all attachments are being deposited with the tJnited States Postal
`
`Service as Express Mail (Express Mail Label: EV325162991 US in an envelope addresseld to-Mail Stop
`
`Certiricate of Mailing under 37 CFR 1.10
`
`Patent Application, Commissioner for Patents, P.O. Box 1450, Alexandria, V
`Oc-t *A, 2.M-3
`
`Date:
`
`Signed:
`
`50 on.
`
`I it
`
`Name: Dov Rosenfeld, Reg. No. 38687
`
`Petitioners' EX1017 Page 4
`
`

`
`C=3
`
`C=31
`
`-4
`D3
`
`C:
`
`0
`
`FEE TRANSMITTAL
`
`Attorney Docket No. TAPPT-001'-1-1
`
`(New Nonprovisional Applications Under
`37 CFR § 1.53(b))
`
`First Inventor
`
`Russell S. Dietz
`
`TOTALPAYMENT 1$12.12.00 !!O Express Mail Label No.
`
`I EV325162991 US
`
`Title
`
`I METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`El The commissioner is hereby authorized to charge any missing fees and credit any overpayment to
`
`METHOD OF PAYMENT
`
`Deposit
`Account
`Number
`
`Deposit
`Account
`Name
`
`50-0292
`
`I NVENTEK/ROSEN FELD
`
`D Applicant(s) claim(s) a small entity status.
`
`Payment is enclosed:
`
`check
`
`[E] credit card.
`
`0 money order
`
`0 Other
`
`(Credit Card Charge
`
`form enclosed)
`
`FEE CALCULATION
`
`CLAIMS AS FILED
`
`NO. FILED
`
`NO.EXTRA
`
`OTHER THAN SMALL ENTITY
`RATE
`
`FEE
`
`49
`
`3
`
`29
`
`0
`
`$18.00
`
`$86.00
`
`FOR
`
`Total Claims
`Independent
`Claims
`
`$522.00
`
`$ 0.00
`
`$0.00
`
`$0.00
`
`$770.00
`
`Multiple Dependent Claims (if applicable)
`
`Assignment Recording Fee
`
`Basic Filing Fee
`
`Total Filing Fee
`
`$1,292.00
`
`El Customer Number:
`
`21921. 1 (Dov Rosenfetd, INVENTEK)
`
`SUBMITTED BY
`
`Name:
`
`Signature:
`
`Dov R
`
`Registration. No.
`
`38687
`
`Date:
`
`Or-t 12, 2003
`
`Petitioners' EX1017 Page 5
`
`

`
`OurRef./DocketNo.: APPT-001-1-1
`
`METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A
`NETWORK
`
`Inventor(s):
`
`DIETZ, Russell S.
`San Jose, Califomia, USA
`
`MAIXNER, Joseph R.
`Aptos, Califomia, 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
`
`Certiricate 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: EV32516299 I US in an envelope addressed to Mail Stop Patent Application,
`Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on.
`Oct.
`'2003
`
`Date:
`
`Signed:
`Name: Dov Rosen(efd, Reg. No. 38687
`
`Petitioners' EX1017 Page 6
`
`

`
`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-00 I - 1,
`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-001-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-00 1-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
`
`Petitioners' EX1017 Page 7
`
`

`
`al., filed June 30, 2000, Attomey/Agent Reference Number APPT-001-5, 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
`
`especiafly acute, however, given the recent popularity of the Internet and other intemetsan
`"intemet" 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 ("rnine")
`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-001-1-1
`
`Petitioners' EX1017 Page 8
`
`

`
`[0011]
`
`One such case, for example, would be information concerning NetMeeting(D
`
`(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(D (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]
`
`Pattem-matching parser techniques wherein a packet is parsed and pattem 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
`44connection flow" is conu-nonly 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 activityfor 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
`
`Petitioners' EX1017 Page 9
`
`

`
`4
`
`addressfor example, SAP#5as 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 would 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 conncction 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 linkthe 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 (Conunon Object Request
`
`Broker Architecture). RPC is a programming interface from Sun Microsystems (Palo Alto,
`Califomia) 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 objectsobjects are self-contained software modulesto 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
`
`Petitioners' EX1017 Page 10
`
`

`
`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 pattem 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 Intemet 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 coffectly 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 exan-fined and the information extracted from any
`
`packet are adaptively determined from information in the packct for the particular type of
`
`packet. Thcre is no fixed definition of what to look for and where to took 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
`
`Petitioners' EX1017 Page 11
`
`

`
`z
`
`[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 OSI 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 EP-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]
`
`Recognize and classify all packets that are exchanges between a client and
`
`server into respective client/server applications.
`
`[0025]
`
`[0026]
`
`9
`
`9
`
`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
`
`Petitioners' EX1017 Page 12
`
`

`
`7
`
`[0027]
`
`[0028]
`
`[00291
`
`o
`
`o
`
`0
`
`Be used to help tune the performance of a network according to the current mix
`
`of client/server applications requiring network resources.
`
`Maintain statistics relevant to the inix of client/server applications using
`
`network resources.
`
`Report on the occurrences of specific sequences of packets used by particular
`
`applications for client/server network conversational flows.
`
`[00301
`
`Other aspects of embodiments of the invention are:
`
`[00311
`
`0
`
`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]
`
`[00331
`
`0
`
`0
`
`Providing a flexible processing system that can be tailored or adapted as new
`
`applications enter the client/server market.
`
`Maintaining statistics relevant to the conversational flows in a client/sever
`
`network as classified by an individual application.
`
`[0034]
`
`0
`
`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 aie parsed and selected
`
`parts are assembled into a signature (also called a key) that may then be used identify further
`
`APPT-001-1-1
`
`Petitioners' EX1017 Page 13
`
`

`
`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
`
`pattem 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 pattem 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 packetalso called an Ethemet TypeNersion 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
`
`Petitioners' EX1017 Page 14
`
`

`
`E
`
`one of the children nodes may be the EP protocol, and one of the children of the IP protocol
`may be the TCP protocol.
`
`[0043]
`
`The pattem 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 recognized, the slicer extracts important packet elements from the
`packet. These form a signature (i.e., 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 (HIDE) 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
`
`Petitioners' EX1017 Page 15
`
`

`
`several flows may be processed in parallel, and multiple flow signatures from all the packets
`being analyzed in parallel may be held in theone UFKB.
`
`10
`
`[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
`
`Petitioners' EX1017 Page 16
`
`

`
`I I
`
`[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 deletion engine (FIODE) is
`initiated. The state processor also may create new flow signatures and thus may instruct the
`flow insertion and deletion engine to add a new flow to the database as a new item.
`
`[0053]
`
`In the preferred hardware embodiment, each of the LUE, state processor, and FIDE
`operate independently from the other two engines.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0054]
`
`Although the present invention is better understood by referring to the detailed
`preferred embodiments, these should not be taken to limit the present invention to any
`specific embodiment because such embodiments are provided only for the purposes of
`explanation. The embodiments, in tum, are explained with the aid of the following figures.
`
`[0055]
`FIG. 1 is a functional block diagram of a network embodiment of the present
`invention in which a monitor is connected to analyze packets passing at a connection point.
`
`[0056]
`FIG. 2 is a diagram representing an example of some of the packets and their formats
`that might be exchanged in starting, as an illustrative example, a