`
`
`
`
`
`
`
`
`
`
`IW 7696177
`
`
`
`T®AGE,TOWHOMTHESE: PRESENTS) SHAT:COMES
`
`UNITED STATES DEPARTMENT OF COMMERCE
`United States Patent and Trademark Office
`
`October 10, 2018
`
`THIS IS TO CERTIFY THAT ANNEXED IS A TRUE COPY FROM THE
`
`RECORDSOF THIS OFFICE OF THE FILE WRAPPER AND CONTENTS
`
`OF:
`
`APPLICATION-NUMBER:-10/684;776- ~~
`FILING DATE: October 14, 2003
`|
`PATENT NUMBER: 6,954,789.
`ISSUE DATE: October 11, 2005
`
`
`Certifying Officer
`
`
`Wd NTGOMER
`
`By Authority of the
`UnderSecretary of Commerce for Intellectual Property
`and Directorof the United States Patent and Trademark Office
`
`NOAC Ex. 1019 Page 1
`
`

`

`Russell S. Dietz
`
`Title
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`
`
`
`
`
`Attorney Docket No.|APPT-001-1-1
`UTILITY PATENT APPLICATION
`TRANSMITTAL
`
`
`
`(New Nonprovisional Applicati_ ns Under 37 CFR §
`
`
`1.53(b))
`
`
`
`
`~N
`. Mail Stop Patent Application
`ADDRESSTO:
`Commissionerfor Patents Om
`APPLICATION ELEMENTS
`
`
`P.O. Box 1450
`>
`Alexandria, VA 22313-1450 |
`1.
`
`
`Om
`a
`1. [Fee transmittal form (in duplicate)
`7. cp-RoMin duplicate, large table, or computer prggramn
`
`(Appendix)
`
`
`20 Applicant(s) claim(s) a small entity status.
`
`8. C1] Nucleotide &/or amino acid sequence submission
`
`
`
`
`
`
`
`Assignment papers (cover sheet & documents)
`10.C 37 CFR3.73(b) statement. [] Powerof
`Attorney 5. Dé] Declaration and [EX] Power of Attorney
`
`
`
` a O Newly executed (original or copy)
` English translation document.
`
` b.
`application with box 18 completed Information Disclosure Statement (Form PTO-1449)
`Copyfrom prior application for continuing
`
` i. CJ DELETION OF INVENTOR(S)
`signed statement attached deleting
`
`inventor(s) named in the prior application.
` Return Receipt postcard.
`
`
` 6.0] Application Data Sheet
` Certified copies of priority documents.
` Requestandcertification under 35 USC 122
`
`(b)(2)(B){i).
`
`
`Other: _List of inventors, with residence city,
`
`state/country and citizenship for each
`
`
`
`
`
`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:
`
`
`oO Continuation in
`
`
`part (CIP).
`Prior application information.
`Examiner: Khanh Q. DINH
`Group Art Unit:
`2155
`
`
`
`
` For CONTINUATION OR DIVISIONAL APPLICATIONS ONLY:the entire disclosureof the prior application, from which an oath or declaration is
`supplied underitem Sb, is considered a part of the disclosure of the accompanying continuation ordivisional application and is herebyincorporated by
`reference. The incorporation can only be relied upon whena portion has beeninadvertently omitted from the submitted application parts.
`
`
`
`
`
`
`
`Name: Dov Résénfeld, Reg. No. 38687
`
`Express Mail Label No.
`
`EV325162991US
`
`oO
`
`sheet(s) of specification, claims, and abstract
`3.
`67
`sheet(s) of formal Drawing(s) with a
`4. 1 18
`submissionletter to the Official Draftsperson
`
`and copies of IDS citations.
`
`Preliminary Amendment.
`
`[x] Continuation .
`
`oO Divisional.
`
`of prior application no:
`
`Customer Number: 21921.|(Name: Dov Rosenfeld, INVENTEK)
`
`
`
`19. CORRESPONDENCE ADDRESS
`
`ZL
`i”
`\
`
`)
`
`Certificate of Mailing under 37 CFR 1.10
`I herebycertify that this application andall attachments are being deposited with the United States Postal Serviceas
`Express Mail (Express Mail Label: EV325162991USin an envelope addressed to Mail Stop Patent Application,
`Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on.
`Date:
`Oct YS, 20033
`Signed:
`
`NOAC Ex. 1019 Page2
`
`NOAC Ex. 1019 Page 2
`
`

`

`
`
`Attorney Docket No.|APPT-001-1-1
`FEE TRANSMITTAL
`
`
`
`First Inventor|Russell S. Dietz
`(New Nonprovisional Applications Under
`
`37 CFR § 1.53(b))
`
`
`
`
`
`
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`$1292.00 $7500 Express Mail Label No.
`
`EV325162991US
`
`Title
`
`1. EX] The commissioneris hereby authorized to charge any missing fees and credit any overpayment to
`
`METHOD OF PAYMENT
`
`Deposit
`Account
`Number
`
`‘Deposit
`Account
`Name
`
`50-0292
`
`INVENTEK/ROSENFELD
`
`
`
`O Applicant(s) claim(s) a small entity status.
`
`2. KX] Paymentis enclosed:
`
`CI check
`
`EX] credit card.
`(Credit Card Charge
`form enclosed
`
`O Money order
`
`C1 other
`
`Independent
`Claims
`
`3
`
`$86.00
`
`§ 52500
`$ 0.00
`
`$0.00
`
`
`
`
`
`
`
`Multiple Dependent Claims(if applicable)
`
` Assignment Recording Fee
`$0.00
`Basic Filing Fee
` Total Filing Fee
`
`$770.00
`
`$1,292.00
`
`
`
`Customer Number:|21921.|(Dov Rosenfeld, INVENTEK)
`
`
`
`SUBMITTED BY
`
`Name:|Dov Rosenteld, so egistration. No. :|38687
`
`rn en
`to
`
`fle
`
`NOACEx. 1019 Page 3
`
`NOAC Ex. 1019 Page 3
`
`

`

`Our Ref./Docket No: APPT-001-1-1
`
`Patent
`
`IN THE UNITED STATES PATENT AND TRADEMARKOFFICE
`
`Russell S. Dietz
`
`
`
`
`
`Attorney Docket No.|APPT-001-1-1
`
`
`INVENTOR(S)/APPLICANT(S)
` (New Nonprovisional Applications Under 37
`CFR § 1.53(b))
`
`
`EV325162991US
`Express Mail Label No.
`
`
`Last Name
`First Name, MI
`Residence (City and Either Citizenship
`State or Foreign Country)
`
`Dietz
`Russell S.
`San Jose,California, USA
`US
`
`Title
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`Maixner
`
`Joseph R.
`
`Aptos, California, USA
`
`Koppenhaver
`
`Andrew A.
`
`Littleton, CO, USA
`
`Bares
`
`Sarkissian
`
`Torgerson
`
`William H.
`
`Haig A.
`
`JamesF.
`
`Germantown, TN, USA
`
`San Antonio, Texas, USA
`
`Andover, MN, USA
`
`US
`
`US
`
`US
`
`US
`
`US
`
`NOACEx. 1019 Page 4
`
`NOAC Ex. 1019 Page 4
`
`

`

`Our Ref./Docket No: APPT-001-1-1
`
`Patent
`
`IN THE UNITED STATES PATENT AND TRADEMARKOFFICE
`
`
`
`Group Art Unit: unassigned
`
`
`Applicant(s): Dietz, et al.
`
`
`
`Title: METHOD AND APPARATUS FOR
`Examiner: unassigned
`MONITORING TRAFFIC IN A NETWORK
`
`
`LETTER TO OFFICIAL DRAFTSPERSON
`SUBMISSION OF FORMAL DRAWINGS
`
`The Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`ATTN: Official Draftsperson
`
`Dear Sir or Madam:
`
`Attached please find 18 sheets of formal drawings to be madeof record for the above-
`identified patent application submitted herewith.
`
`Oct 13,2003
`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 herebycertify that this application and all attachments are being deposited with the United States Postal
`Service as Express Mail (Express Mail Label: EV325162991USin an envelope addressed to
`Mail Stop
`Patent Application, Commissioner for Patents, P.O. Box 1450, Alexandria, V
`=4450 on.
`Date: Cet
`bMS _ 2003
`Signed:
`
`
`}
`Name: Dov Rosenfeld, Reg. No. 38687
`
`NOACEx. 1019 Page 5
`
`NOAC Ex. 1019 Page 5
`
`

`

`neLe
`
`
`
`1. Bd the commissioneris hereby authorized to charge any missing fees and credit any overpaymentto
`
`METHOD OF PAYMENT
`
`Deposit
`Account
`Number
`
`Deposit
`Account
`Name
`
`50-0292
`
`INVENTEK/ROSENFELD
`
`OC Applicant(s) claim(s) a small entity status.
`
`2. Xx] Paymentis enclosed:
`
`0 check
`
`EX] credit card.
`(Credit Card Charge
`form enclosed
`
`CO Moneyorder
`
`
`
`Claims
`
`$16.00
`
`$ 522.00
`
`$ 0.00
`
`
`
`$0.00
`
`$0.00
`
`$770.00
`
`Multiple DependentClaims(if applicable)
`Assignment Recording Fee
`
`Basic Filing Fee
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Total Filing Fee
`
`$1,292.00
`
`Customer Number:|21921.|(Dov Rosenfeld, INVENTEK)
`
`
`
`
`SUBMITTED BY
`
`ZZ
`LE
`
`
`
`NOACEx. 1019 Page 6
`
`tt
`[ot
`¢0/tT
`
`AW
`
`First Inventor|Russell S. Dietz
`
`‘s
`old
`
`n
`
`FEE TRANSMITTAL (New Nonprovisional Applications Under
`37 CFR § 1.53(b))
`
`
`
`METHOD AND APPARATUS FOR MONITORING
`
`
`TRAFFIC IN A NETWORK
`
`}TOTALPAYMENT[1292.00 $p8e0Q|Express Mail Label No._|EV325162991US
`
`NOAC Ex. 1019 Page 6
`
`

`

`Our Ref./Docket No.:
`
`_APPT-001-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
`
`TORGERSON,JamesF.
`Andover, MN, USA
`
`
` Certificate of Mailing under 37 CFR 1.10
`
`
`Therebycertify that this application andall attachments are being deposited with the United States Postal Service as
`Express Mail (Express Mail Label: EV325162991USin an envelope addressed to Mail Stop Patent Application,
`
`
`Commissionerfor Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on.
`
`
`Date:
`Oct 4 , 2003
`Signed:
`[%
`Name: Dov Rosenfeld, Reg. No. 38687
`
`NOACEx. 1019 Page 7
`
`NOAC Ex. 1019 Page 7
`
`

`

`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`CROSS-REFERENCE TO RELATED APPLICATION
`
`This invention is a continuation of U.S. Patent Application Serial No. 09/608237 for
`[0001]
`METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A NETWORKto
`
`inventors Dietz,et al., filed June 30, 2000, Attorney/Agent Reference Number APPT-001-1,
`the contents of which are incorporated herein by reference
`
`This invention claims the benefit of U.S. Provisional Patent Application Serial No.:
`[0002]
`60/141,903 for METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A
`
`NETWORKto inventorsDietz,et al., filed June 30, 1999, the contents of which are
`
`incorporated herein by reference.
`
`This applicationis related to the following U.S. patent applications, eachfiled
`[0003]
`concurrently with the present application, and eachassignedto the assigneeof the present
`invention:
`
`[0004]
`
`U.S. Patent Application Serial No. 09/609179 for PROCESSING PROTOCOL
`
`SPECIFIC INFORMATIONIN PACKETSSPECIFIED BY A PROTOCOL DESCRIPTION
`
`LANGUAGE,to inventors Koppenhaver,et al., filed June 30, 2000, Attorney/Agent
`Reference Number APPT-001-2, and incorporated herein byreference.
`
`[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 RECORDSIN 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 MATCHINGIN A NETWORK MONITOR DEVICE,to inventors Sarkissian,et
`
`APPT-001-1-7
`
`NOACEx. 1019 Page 8
`
`NOAC Ex. 1019 Page 8
`
`

`

`al., filed June 30, 2000, Attorney/Agent Reference Number APPT-001-S, and incorporated
`herein by reference.
`
`2
`
`FIELD OF INVENTION
`
`The present invention relates to computer networks, specifically to the real-time
`[0008]
`elucidation of packets communicated within a data network, including classification
`according to protocol and application program.
`
`BACKGROUND TO THE PRESENT INVENTION
`
`There has long been a need for network activity monitors. This need has become
`[0009]
`especially acute, however, given the recent popularity of the Internet and other internets—an
`“mternet” being any plurality of interconnected networks which formsa 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, whois 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 importantthat selected users be able to access a
`network remotely in order to generate reports on networkusein real time. Similarly, a need
`exists for a real-time network monitor that can provide alarms notifying selected users of
`problems that may occurwith the networkorsite.
`
`Oneprior art monitoring method uses log files. In this method, selected network
`[0010]
`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 determinestatistics about the server or gateway. Several problemsexist with
`this method, however.First, log file information does not provide a map ofreal-time usage;
`and secondly, log file mining does not supply complete information. This methodrelies on
`logs maintained by numerous network devices and servers, which requires that the
`information be subjected to refining and correlation. Also, sometimes informationis simply
`not available to any gatewayorserver in order to makealogfile entry.
`
`APPT-001-1-1
`
`NOACEx. 1019 Page 9
`
`NOAC Ex. 1019 Page 9
`
`

`

`3
`
`Onesuchcase, for example, would be information concerning NetMeeting®
`[0011]
`(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.
`
`Another disadvantage of creating logfiles is that the process requires data logging
`[0012]
`features of network elementsto 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 meansofstorage for them, and they require a significant amount
`of maintenance.
`
`Though Netflow® (Cisco Systems,Inc., San Jose, California), RMON2, and other
`[0013]
`network monitors are available for the real-time monitoring of networks, they lack visibility
`into application contentandaretypically limited to providing network layerlevel
`information.
`
`Pattern-matching parser techniques wherein a packetis parsed andpattern filters are
`[0014]
`applied are also known,butthesetoo are limited in how deepinto the protocol stack they can
`examine packets.
`
`[0015]
`Someprior 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
`exchangedin anydirection as a result of an activity—forinstance,the runningof an
`application on a serveras requestedbya client. It is desirable to be able to identify and
`classify conversational flows rather than only connection flows. The reasonfor this is that
`
`some conversational flows involve more than one connection, and some even involve more
`than one exchangeof packets between a client and server. Thisis 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 ofthat service.
`
`An example of such a case is the SAP (Service Advertising Protocol), a NetWare
`[0016]
`(Novell Systems, Provo, Utah) protocol usedto identify the services and addresses of servers
`attached to a network.In the initial exchange, a client might send a SAP requestto a server
`for print service. The server would then send a SAPreply that identifies a particular
`
`APPT-001-1-1
`
`NOACEx. 1019 Page 10
`
`NOAC Ex. 1019 Page 10
`
`

`

`4
`
`address—for example, SAP#5—astheprint 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
`
`whohasinadvertently seen this reply or who hasaccessto the table (via the router that has
`the Service Information Table) would know that SAP#5 for this particular serveris a print
`service. Therefore, in order to print data on the server, such a client would not need to make a
`
`requestfor a print service, but would simply send data to be printed specifying SAP#5. Like
`the previous exchange, the transmission ofdata to be printed also involves an exchange
`between a client and a server, but requires a second connection andis therefore independent
`of the initial exchange.In order to eliminate the possibility of disjointed conversational
`exchanges,it is desirable for a network packet monitorto be ableto “virtually concatenate”—
`that is, to link—the first exchange with the second.If the clients were the same, the two
`packet exchanges wouldthen be correctly identified as being part of the same conversational
`flow.
`
`Other protocols that may lead to disjointed flows, include RPC (Remote Procedure
`[0017]
`Call); DCOM (Distributed Component Object Model), formerly called Network OLE
`(Microsoft Corporation, Redmond, Washington), and CORBA (CommonObject 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 betweendistributed objects, provides a way to execute programs(objects)
`written in different programming languages running ondifferent platforms regardless of
`wherethey reside in a network.
`
`Whatis needed,therefore, is a network monitor that makesit possible to continuously
`[0018]
`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
`eachof these packets the network monitor should determinethe 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 notbereliant upon server resident information such aslogfiles.
`Rather, it should allow a user such as a network administrator or an Internet service provider
`(ISP) the means to measure and analyze networkactivity 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 exchangeas being associated with a print service on that
`
`server, such exchange would even be recognizedif the clients were not the same. What
`
`distinguishes this invention from prior art network monitorsis that it has the ability to
`recognize disjointed flows as belonging to the same conversational flow.
`
`The data value in monitoring network communications has been recognized by many
`[0020]
`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 NETWORKSESSIONS 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 atsix specific fields (at 6 locations) in the packetin
`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. Withtheproliferation of
`protocols, clearly the specifying of all the possible places to look to determine the session
`becomes more and moredifficult. Likewise, adding a new protocolor applicationis difficult.
`In the present invention, the locations examined and the information extracted from any
`
`packet are adaptively determined from information in the packetfor the particular type of
`
`packet. There is no fixed definition of what to look for and whereto 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
`
`NOAC Ex. 1019 Page 12
`
`NOAC Ex. 1019 Page 12
`
`

`

`6
`
`The 402 patent system is able to recognize up to the session layer. In the present
`[0021]
`invention, the numberof levels examined varies for any particular protocol. Furthermore, the
`present invention is capable of examining up to whateverlevelis sufficient to uniquely
`identify to a required level, even all the wayto the application level (in the OSI model).
`
`Other prior art systems also are known. Phael describes a network activity monitor
`[0022]
`that processes only randomly selected packets in United States Patent 5,315,580, titled
`
`“NETWORK MONITORING DEVICE AND SYSTEM.” Nakamurateaches a network
`
`monitoring system in United States Patent 4,891,639,titled “MONITORING SYSTEM OF
`
`NETWORK.”Ross,ef al., teach a method and apparatus for analyzing and monitoring
`networkactivity in United States Patent 5,247,517, titled “METHOD AND APPARATUS
`
`FOR ANALYSIS NETWORKS,” McCreery,et al., describe an Internet activity monitor that
`decodes packetdata at the Internet protocollevel layer in United States Patent 5,787,253,
`titled “APPARATUS AND METHODOF ANALYZING INTERNETACTIVITY.” 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 signatureis built for every
`flow suchthat future packets of the flow are easily recognized. When a new packetin the
`flow arrives, the recognition process can commencefrom whereit last left off, and a new
`
`signature built to recognize new packetsofthe flow.
`
`SUMMARY
`
`In its various embodimentsthe present invention provides a network monitor that can
`[0023]
`accomplish one or more of the following objects and advantages:
`
`
`
`[0024] Recognize andclassify all packets that are exchanges betweenaclient ande
`
`
`
`server into respective client/server applications.
`
`[0025]
`
`[0026]
`
`°
`
`°
`
`Recognize andclassify at all protocol layer levels conversational flowsthat pass
`
`in either direction at a point in a network.
`
`Determine the connection and flow progress betweenclients and servers
`
`accordingto the individual packets exchanged over a network.
`
`APPT-001-1-1
`
`NOACEx. 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 occurrencesof specific sequences of packets used by particular
`
`applications for client/server network conversational flows.
`
`[0030]
`
`Other aspects of embodimentsof the inventionare:
`
`[0031]
`
`Properly analyzing each of the packets exchanged between a client and a server
`
`and maintaining information relevantto 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]
`
`Maintainingstatistics relevant to the conversational flows in a client/sever
`
`networkas 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 embodimentsof the present invention overcome the problems and
`disadvantagesofthe art.
`
`[0036]
`
`As described herein, one embodiment analyzes each of the packets passing through
`any pointin the networkin eitherdirection, in order to derive the actual application used to
`
`communicate betweena 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 embodimentof the invention successfully classifies each of the individual
`packetsas they are seen on the network. The contents of the packets are parsed and selected
`parts are assembledinto a signature (also called a key) that may then be usedidentify further
`
`APPT-001-1-1
`
`NOACEx. 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. Thusthe key is a function of the selected
`parts, and in the preferred embodiment, the function is a concatenationof the selectedparts.
`The preferred embodiment forms and remembersthestate of any conversational flow, which
`is determinedby the relationship between individual packets and the entire conversational
`flow over the network. By remembering thestate of a flow in this way, the embodiment
`determines the contextof the conversational flow, including the application programit relates
`to and parameters suchasthe time, length of the conversational flow,datarate,etc.
`
`The monitoris flexible to adapt to future applications developed forclient/server
`[0038]
`networks. New protocols and protocol combinations may be incorporated by compilingfiles
`written in a high-level protocol description language.
`
`The monitor embodiment ofthe present invention is preferably implemented in
`[0039]
`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 thatreceives the signature from
`the parser subsystem.
`
`A packet acquisition device such as a media access controller (MAC)or a
`[0040]
`segmentation and reassemble moduleis used to provide packets to the parser subsystem of
`the monitor.
`
`In a hardware implementation, the parsing subsystem comprises two sub-parts, the
`[0041]
`pattern analysis and recognition engine (PRE), and an extraction engine(slicer). The PRE
`interprets each packet, andin particular, interprets individual fields in each packet according
`to a pattern database.
`
`The different protocols that can exist in different layers may be thought ofas nodes of
`[0042]
`one or more trees of linked nodes. The packet typeis the rootof a tree. Each protocolis either
`a parent nodeor a terminal node. A parent nodelinks a protocol to other protocols (child
`protocols) that can beat 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
`
`NOACEx.1019 Page 15
`
`NOAC Ex. 1019 Page 15
`
`

`

`9
`
`one of the children nodes maybethe IP protocol, and oneofthe children of the IP protocol
`may be the TCP protocol.
`
`The pattern database includesa description of the different headers of packets and
`[0043]
`their contents, and howtheserelate to the different nodes in a tree. The PREtraversesthe tree
`
`as far as it can. If a node doesnotincludea link to a deeperlevel, pattern matchingis
`declared complete. Note that protocols can be the children of several parents. If a unique
`node was generated for each ofthe possible parent/child trees, the pattern database might
`becomeexcessively large. Instead, child nodes are shared among multiple parents, thus
`compacting the pattern database.
`
`[0044]
`
`Finally the PRE canbe usedon its own when only protocol recognition is required.
`
`Foreach protocol recognized,the slicer extracts important packet elements from the
`[0045]
`&
`packet. These form a signature(i.e., key) for the packet. The slicer also preferably generates a
`hash forrapidly identifying a flow that may have this signature from a database of known
`
`flows.
`
`The flow signature of the packet, the hash andat least some of the payload are passed
`[0046]
`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 lookupa database of flow
`records for previously encounteredconversational flows to determine whethera signatureis
`from an existing flow,a state processor (SP) for performing state processing, a flow insertion
`and deletion engine (FIDE)for inserting new flowsinto the database offlows, a memory for
`storing the database of flows, and a cache for speeding up access to the memorycontaining
`the flow database. The LUE, SP, and FIDEareall coupled to the UFKB, andto the cache.
`
`The unified flow key buffer thus contains the flow signature of the packet, the hash
`[0047]
`and at least some ofthe payload for analysis in the analyzer subsystem. Manyoperations can
`be performed to further elucidate the identity of the application program content ofthe packet
`involvedin the client/server conversational flow while a packet signature exists in the unified
`flow signature buffer. In the particular hardware embodimentof the analyzer subsystem
`
`APPT-001-1-1
`
`NOACEx. 1019 Page 16
`
`NOAC Ex. 1019 Page 16
`
`

`

`10
`
`several flows may be processedin parallel, and multiple flow signatures from all the packets
`being analyzed in parallel may be held in the one UFKB.
`
`Thefirst step in the packet analysis process of a packet from the parser subsystem is
`[0048]
`to lookupthe instance in the current database of knownpacketflow signatures. A
`lookup/update engine (LUE) accomplishesthis task using first the hash, and then the flow
`signature. The search is carried out in the cache andif 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 includesstate
`information, whichis used in the state processor to execute any operations defined for the
`state, and to determinethe next state. A typical state operation maybeto search for one or
`more knownreferencestrings in the payload of the packet stored in the UFKB.
`
`Once the lookupprocessing by the LUE has been completed a flag stating whetherit
`[0049]
`is found oris 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 componentofthe
`LUEthat adds valuesto 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.
`
`After the packet flow signature has been looked up and contentsof the current flow
`[0050]
`signature are in the database, a state processor can begin analyzing the packet payloadto
`further elucidate the identity of the application program componentofthis packet. The exact
`operation of the state processor and functions performedby it will vary depending on the
`current packet sequencein the stream of a conversational flow. The state processor movesto
`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 databaseof state instructionforthis state until there are either no moreleft or the instruction
`
`signifies processing.
`
`In the preferred embodiment, the state processor functions are programmable to
`[0051]
`provide for analyzing new application programs, and new sequencesofpackets andstates
`that can arise from using such application.
`
`APPT-001-1-1
`
`NOACEx. 1019 Page 17
`
`NOAC Ex. 1019 Page 17
`
`

`

`11
`
`If during the lookup processfor this particular packet flow signature, the flow is
`[0052]
`required to be insertedinto the active database, a flow insertion and deletion engine (FIDE)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.
`
`In the preferred hardware embodiment,each of the LUE, state processor, and FIDE
`[0053]
`operate independently from the other two engines.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Althoughthe presentinventionis better understood byreferring to the detailed
`[0054]
`preferred embodiments, these should notbe takento limit the present invention to any
`specific embodiment because such embodimentsare provided only for the purposes of
`explanation. The embodiments, in turn, are explained with the aid of the followingfigures.
`
`FIG. 1 is a functional block diagram of a network embodimentofthe present
`[0055]
`invention in which a monitor is connectedto analyze packets