2
`
`PA'
`
`z0
`
`cc
`
`N U) U)
`
`U)
`
`_jo
`cc w
`
`U)
`
`U.S. UTILITY Patent Appli
`
`O.I.P.E.
`
`cation
`PATENT DATE
`
`SCANNED 414)
`
`Q.A
`
`IN3
`
`APPLICATION
`
`NO'
`0 9 6 0 81 12 .3 f-
`
`CONTIPRIOF
`D
`
`CLASS
`709
`
`SUBCLASS
`
`ART UNIT
`
`EXAMINER
`
`---wl
`
`2 i 5_7
`
`Id+
`
`:3
`CL
`CL
`
`Ul
`
`ORIGINAL
`
`CLASS
`
`I
`
`SUBCLASS
`
`-7 Z-1
`
`-2"-7
`'70 q
`INTERNATIONAL CLASSIFICATION
`is/oo
`
`) OICF
`
`PTO-2040
`12/99
`
`ISSUING CLASSIFICATION
`
`CROSS REFERENCE(S)
`
`CLASS
`
`S70 1 1307" 7 1
`
`SUBCLASS (ONE SUBCLASS PER BLOCK)
`
`-
`
`I
`
`I
`
`I
`
`,
`
`Continued on Issue Slip Inside File Jacket
`
`TERMINAL
`DISCLAIMER
`
`DRAWINGS
`
`CLAIMS ALLOWED
`
`Sheets Drwg.
`
`Figs. Drwg.
`
`Print Fig
`
`Total Claims
`
`Print Claim for O.G.
`
`/9
`
`20
`
`10
`
`El The term of this patent
`
`subsequent to
`
`(date)
`
`has been disclaimed.
`
`(A.sistant Examiner)
`
`(Date)
`
`/ (D
`
`I
`
`NOTICE OF ALLOWANCE MAILED
`
`7-1-1-03
`
`1
`
`ISSUE FEE
`
`I
`
`/
`
`g4
`
`El The term of this patent shall
`
`not extend beyond the expiration date
`
`of U.S Patent. No.
`
`MOUSTAFA M. MIEKY
`PR,,,ARY EMMMER
`
`(Primary Examiner)
`
`Amount Due
`7)/M_'*3 -* h3bo- '--
`
`(Date)
`
`Date Paid
`
`1
`ISSUE BATCH NUMBER
`
`El The terminal
`
`months of
`
`this patent have been disclaimed.
`
`(Legal Instrknents Examlner
`
`WARNING:
`The information disclosed herein may be restdcted. Unauthorized disclosure may 6e prohibited by the United States Code Title 35, Sections 122, 181 and 368.
`Possession outside the U.S. Patent & Trademark Office is restricted to authorized employees and contractors only.
`
`Form PTO-436A
`(Rev. 6199)
`
`V:ILE
`
`FILED WITH' [:] DISK (CRF) [:] FICHE [] CD-ROM
`
`(Attached in pocket on right inside flap)
`
`(FACE)
`
`Petitioners' EX1016 Page 1
`
`

`
`PA-TENIT APPLICATION
`
`i
`
`09608237
`
`U I PTO
`
`A-
`
`06/10/00
`
`CONTENTS
`
`Date Received
`(incl. C. of M.)
`or
`Date Mailed
`
`INITIALS
`
`Date Received
`(incl. C. of M.)
`or
`Date Mailed
`
`4pplication
`
`6
`
`papers.
`
`/7-1i
`
`ILIA
`
`VL
`
`(Y\ (D 5
`
`(-x
`
`N4kI, 1,3\j
`
`7
`
`-17 -03
`
`9.
`
`0
`
`0.
`
`1 .
`
`0.
`
`1 .
`
`3
`
`42.
`
`43.
`
`44.-
`45.-
`
`46.
`
`47.
`
`48.
`
`49.
`
`50.
`
`51.-
`52.-
`53.-
`54.-
`55.-
`
`56.
`
`57.-
`58.-
`
`59.
`
`60.
`
`61.
`
`62.-
`
`63.
`
`64.
`
`65.
`
`66.
`
`67.
`
`68.
`
`69-
`
`70.
`
`71.
`
`72.
`
`73.
`
`74.
`
`75.
`
`76.-
`
`77.
`
`78.
`
`79.
`
`80.
`
`0.
`
`1.
`
`I
`
`81.-
`82.-
`(LEFT OUTSIDE)
`
`m
`
`13
`
`I
`
`Petitioners' EX1016 Page 2
`
`

`
`UNITED STATES PATENT AND MRADEMARK OMCE
`
`Page I of I
`
`COMMISSIONER
`PATENTS
`FOR
`UNITED STATFS PATFNT ANo TRADFMARK OFFICF
`W&SHINGMN, D.C. 20231
`W%VW.Uspto.gov
`
`CONFIRMATION NO.9093
`
`Bib Data Shoot
`
`SERIAL NUMBER
`09/608,237
`
`FILING DATE
`
`06/30/2000
`
`RULE
`
`PPLICANTS
`Russell S. Dietz, San Jose, CA;
`Joseph R. Maixner, Aptos, CA;
`Andrew A. Koppenhaver, Littleton, CO;
`William H. Bares, Germantown, TN;
`Haig A. Sarkissian, San Antonio, TX;
`James F. Torgerson, Andover, MN;
`
`CLASS
`709
`
`GROUP ART UNIT
`2755
`
`ATTORNEY
`DOCKET NO.
`APPT-001-1
`
`CONTINUING DATA
`THIS APPLN CiAI S BENEFIT OF 60/141,903 06/30/1999
`
`y o , 1-, 14 T
`T ONS
`"FOREIGN APP I
`O%UV'V I R ip
`IF REQUIRED, FOREIGN FILING LICENSE
`GRANTED ** 08/21/2000
`
`SHEETS
`STATE OR
`COUNTRY DRAWING
`CA
`18
`
`TOTAL
`CLAIMS
`59
`
`INDEPENDENT
`CLAIMS
`4
`
`Foreign Priority claimed
`
`Li yes)4 no
`
`35 USC 119 (a-d) conditions
`met
`
`LJ yes4 no LJ met after
`Allowance
`
`Examiner's Signature
`
`IK,ow,
`
`Verified and
`Acknowledged
`ADDRESS
`Dov Rosenfeld
`
`Suite 2
`
`5507 College Avenue
`Oakland CA 94618
`
`TITLE
`
`Method and apparatus for monitoring traffic in a network
`
`FILING FEE FEES: Authority has been given in Paper
`RECEIVED
`to charge/credit DEPOSIT ACCOUNT
`No.
`No.
`1622
`for following:
`
`tO 1,)17 F
`time )
`
`ees Processing Ext. of
`
`[E) 1. 18 Fees
`
`Issue
`
`ILI Ail Fees
`
`I LD 1.16 FeesiFiring
`
`ILD Other
`
`JE) Credit
`
`Petitioners' EX1016 Page 3
`
`

`
`'E)' -
`
`-3, - 0 0
`
`0,
`
`IN THE U.S. PATENT AND TRADEMARK OFFICE
`Application Transmittal Sheet
`
`OurRef./DocketNo.:
`
`APPT-001-1
`
`C= F-
`C= EaE -
`C= =
`
`Box Patent Application
`ASSISTANT COMMISSIONER FOR PATENTS
`Washington, D.C. 20231
`
`0
`
`Dear Assistant Commissioner:
`
`Transmitted herewith is the patent application of
`
`0E
`
`-- k%j, Q
`(D
`
`CL.
`
`.00
`
`(D
`cn
`
`Last Name
`
`Dietz
`Maixner
`Koppenhaver
`
`INVENTORo/APPLICANT s)
`First Name, MI
`Residence (City and State or Country)
`
`Russell S.
`Joseph R.
`Andrew A.
`
`San Jose, CA
`Aptos, CA
`
`Fairfax, VA
`
`Additional inventors are being named on separately numbered sheets attached hereto.
`
`TITLE OF THE HWENTION
`
`METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A NETWORK
`
`CORRESPONDENCE ADDRESS AND AGENT FOR APPLICANT(S)
`
`Dov Rosenfeld, Reg. No. 38,387
`
`5507 College Avenue, Suite 2
`
`Oakland, California, 94618
`
`Telephone: (510) 547-3378; Fax: (510) 653-7992
`
`ENCLOSED APPLICATION PARTS (check all that apply)
`
`Included are:
`*
`66
`*
`
`18
`
`sheet(s) of specification, claims, and abstract
`
`sheet(s) of formal Drawing(s) with a submission letter to the Official Draftsperson
`
`Information Disclosure Statement.
`Form PTO-1449: INFORMATION DISCLOSURE CITATION IN ANAPPLICATION, together with a
`
`copy of each references included in PTO- 1449.
`
`Declaration and Power of Attorney
`
`An assignment of the invention to Apptitude, Inc.
`
`A letter requesting recordation of the assignment.
`
`An assignment Cover Sheet.
`
`Additional inventors are being named on separately numbered sheets attached hereto.
`
`*
`*
`This application has:
`
`Return postcard.
`
`a small entity status. A verified statement:
`
`is enclosed
`
`was already filed.
`
`The fee has been calculated as shown in the following page.
`
`I
`
`Certificate of Mailing under 37 CFR 1.10
`
`1
`
`I hereby certify that this application and all attachments are being deposited with the United States Postal
`
`Service as Express Mail (Express Mail Label: E1417961944US in an envelope addressed to Box Patent
`
`Application, Assistant Cornmissioner for Patents, Washington, D.0 20231
`
`Date:
`
`-'Zkkp -.ZZC9
`
`Sirme: ov;Roenfeld
`N
`0
`, Reg. No. 3868
`
`7
`
`Petitioners' EX1016 Page 4
`
`

`
`SUBMISSION DOCUMENT
`ATrORNEY DOCKET NO. APPT-001-1
`
`Page 2
`
`TOTAL CLAIMS
`
`NO. OF EXTRA
`CLANS
`
`TOTAL
`CLAIMS
`
`INDEP.
`CLAIMS
`
`59
`
`4
`
`39
`
`1
`
`RATE
`
`$18
`
`$78
`
`BASIC APPLICATION FEE:
`
`TOTALFEESPAYABLE:
`
`EXTRA CLAIM
`FEE
`
`$702.00
`
`$ 78.00
`
`$690.00
`
`$1,470.00
`
`METHOD OF PAYMENT
`
`is attached for application fee and presentation of claims.
`check in the amount of
`check in the amount of $ 40.0 is attached for recordation of the Assignment.
`The Comniissioner is hereby authorized to charge payment of the any missing filing or other fees
`required for this filing or credit any overpayment to Deposit Account No. 50-0292
`(A DUPLICATE OF THIS TRANSMITTAL IS ATTACHED):
`
`Respectfully Subn-dtted,
`
`Date
`
`YovfZosenfeld, Reg. No. 38687
`
`Correspondence Address:
`Dov Rosenfeld
`5507 College Avenue, Suite 2
`Oakland, Califomia, 94618
`Telephone: (510) 547-3378; Fax: (510) 653-7992
`
`Petitioners' EX1016 Page 5
`
`

`
`SUBMISSION DOCUMENT
`ATTORNEY DOCKET NO. APPT-001-1
`
`Page-31
`
`ATTORNEY DOCKET NO. APPT-001-1
`
`Application Cover Sheet (cont.)
`
`INVENTOR(s)/APPLICANT(s)
`
`Last Name
`
`First Name, MI
`
`Residence (City and Either State or Foreign
`Country)
`
`Bares
`
`Sarkissian
`
`Torgerson
`
`William H.
`
`Haig A.
`
`James F.
`
`Germantown, TN
`
`San Antonio, Texas
`
`Andover, MN
`
`Petitioners' EX1016 Page 6
`
`

`
`OurRef./DocketNo.:
`
`APPT-001-1
`
`METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A NETWORK
`
`Inventor(s):
`
`DEETZ, Russell S.
`
`San Jose, CA
`
`MAIXNER, Joseph R.
`Aptos, CA
`
`KOPPENHAVER, Andrew A.
`Fairfax, VA
`
`BARES, William H.
`Germantown, TN
`
`SARKISSLAN, Haig A.
`San Antonio, Texas
`
`TORGERSON, James F.
`Andover, MN
`
`I hereby certify that this apptication and all attachments are being deposited with the United States Postal Service as Express Mail
`
`(Express Mail Label: E1417961944US in an envelope addressed to Box Patent Application, Assistant Conunissioner for Patents,
`
`Certificate of Mailing under 37 CFR 1.10
`
`Washington, D.C. 20231 on.
`
`Date:
`
`2,Q6,c)
`
`Signed-.
`
`N a e. Dov Rosenfeld, Reg. No. 38687
`
`Petitioners' EX1016 Page 7
`
`

`
`
`
`\1 -
`
`Petitioners' EX1016 Page 8
`
`

`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`CROSS-REFERENCE TO RELATED APPLICATION
`
`This application 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.
`
`This application is related to the following U.S. patent applications, each filed
`
`concurrently with the present application, and each assigned to Apptitude, Inc., the
`
`10
`
`assignee of the present invention:
`
`I
`U.S. Patent Application Serial No.
`
`.
`
`C)c
`\
`
`C\
`flor PROCESSING PROTOCOL
`
`SPECIFIC INFORMATION IN PACKETS SPECIFIED BY A PROTOCOL
`
`DESCRIPTION LANGUAGE, to inventors Koppenhaver, et al., filed June 30, 2000,
`t
`
`nr1j,Z,4__.
`4;
`IN uIllUr"
`
`and incorporated herein by reference.
`
`15
`
`U.S. Patent Application Serial No. t'k 16,-IjVor RE-USING INFORMATION FROM
`
`DATA TRANSACTIONS FOR MAINTAINING STATISTICS IN NETWORK
`St, /I ,0,eett1j*
`MONITORING, to inventors Dietz, et al., filed June 30, 2000, AA9F*@y;Ag
`
`-Referertee Ntm+er APPT- 991
`
`, and incorporated herein by reference.
`
`U.S. Patent Application Serial No. 0! 4 for ASSOCIATIVE CACHE
`
`20
`
`STRUCTURE FOR LOOKUPS AND UPDATES OF FLOW RECORDS IN A
`
`NETWORK MONITOR, to inyentors Sarkissian, et al., filed June 30, 2000,
`
`-Attet:ao54
`
`P-PT-06 t -4, and incorporated herein by reference.
`
`U.S. Patent Application Serial No. 0 /Wj It 7for STATE PROCESSOR FOR
`
`PATTERN MATCHING IN A NETWORK MONITQR DEVICE, to inventors
`56; IJ o9enchl!)'
`
`25
`
`Sarkissian, et al., filed June 30, 2000,
`
`and incorporated herein by reference.
`
`FIELD OF INVENTION
`
`The present invention relates to computer networks, specifically to the real-time
`
`elucidation of packets communicated within a data network, including classification
`
`30
`
`according to protocol and application program.
`
`Petitioners' EX1016 Page 9
`
`

`
`BACKGROUND TO THE PRESENT INVENTION
`
`2
`
`There has long been a need for network activity monitors. This need has become
`
`especially acute, however, given the recent popularity of the Intemet and other internets
`
`an "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
`
`10
`
`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.
`
`15
`
`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
`
`20
`
`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.
`
`25
`
`One such case, for example, would be information conceming 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.
`
`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 ,
`
`30
`
`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
`
`Petitioners' EX1016 Page 10
`
`

`
`significant amount of maintenance.
`
`3
`
`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.
`
`Pattem-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 exan(cid:173)ine packets.
`
`Some prior art packet monitors classify packets into connection flows. The term
`
`10
`
`46connection 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 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
`
`15
`
`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.
`
`An example of such a case is the SAP (Service Advertising Protocol), a NetWare
`
`20
`
`(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 addressfor example, SAP#5as the print service on that server. Such
`
`responses n-dght be used to update a table in a router, for instance, known as a Server
`
`25
`
`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
`
`30
`
`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
`
`Petitioners' EX1016 Page 11
`
`

`
`4
`
`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.
`
`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, Califomia) that allows one program to use the services of another program in a
`
`ioi
`
`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
`
`15
`
`platforms regardless of where they reside in a network.
`
`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
`
`20
`
`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, 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
`
`25
`
`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
`
`co
`
`of network problems.
`
`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
`
`Petitioners' EX1016 Page 12
`
`

`
`5
`
`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.
`
`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
`
`10
`
`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,
`
`15
`
`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
`
`20
`
`802.3 packet from the older Ethemet Type 2 (or Version 2) DIX (Digital-Intel-Xerox)
`
`packet.
`
`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
`
`25
`
`uniquely identify to a required level, even all the way to the application level (in the OSI
`
`model).
`
`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
`
`30
`
`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
`
`Petitioners' EX1016 Page 13
`
`

`
`rAl
`
`APPARATUS FOR ANALYSIS NETWORKS," McCreery, et al., describe an Intemet
`
`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
`
`5
`
`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
`
`io
`
`of the flow.
`
`SUMMARY
`
`In its various embodiments the present invention provides a network monitor that
`
`can accomplish one or more of the following objects and advantages:
`
`e
`
`Recognize and classify all packets that are exchanges between a client and
`
`15
`
`server into respective client/server applications.
`
`20
`
`0
`
`0
`
`0
`
`0
`
`0
`
`Recognize and classify at all protocol layer levels conversational flows that
`
`pass in either direction at a point in a network.
`
`D'etermine the connection and flow progress between clients and servers
`
`according to the individual packets exchanged over a network.
`
`Be used to help tune the performance of a network according to the current
`
`rrx of client/server applications requiring network resources.
`
`Maintain statistics relevant to the mix of client/server applications using
`
`network resources.
`
`Report on the occurrences of specific sequences of packets used by particular
`
`25
`
`applications for client/server network conversational flows.
`
`Other aspects of embodiments of the invention are:
`
`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.
`
`Petitioners' EX1016 Page 14
`
`

`
`VA
`
`0
`
`Providing a flexible processing system that can be tailored 6r adapted as new
`
`applications enter the client/server market.
`
`0 Maintaining statistics relevant to the conversational flows in a client/sever
`
`network as classified by an individual application.
`
`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.
`
`In general, the embodiments of the present invention overcome the problems and
`
`disadvantages of the art.
`
`10
`
`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.
`
`15
`
`A monitor embodiment of the invention successfully classifies each of the
`
`individual pdckets 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 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
`
`20
`
`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 deten-nines the context of the conversational flow, including
`
`25
`
`the application program it relates to and parameters such as the time, length of the
`
`conversational flow, data rate, etc.
`
`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.
`
`Petitioners' EX1016 Page 15
`
`

`
`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.
`
`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.
`
`In a hardware implementation, the parsing subsystem comprises two sub-parts, the
`
`10
`
`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.
`
`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
`
`15
`
`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 Ethemet
`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, one of the children nodes may be the IP protocol, and one of
`
`20
`
`the children of the IP protocol may be the TCP protocol.
`
`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, pattem matching is
`
`declared complete. Note that protocols can be the children of several parents. If a unique
`
`25
`
`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 pattem database.
`
`Finafly the PRE can be used on its own when only protocol recognition is
`
`required.
`
`30
`
`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
`
`Petitioners' EX1016 Page 16
`
`

`
`generates a hash for rapidly identifying a flow that may have this signature from a
`
`database of known flows.
`
`m
`
`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
`
`10
`
`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.
`
`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
`
`15
`
`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 several flows may be processed in parallel, and
`
`multiple flow signatures from all the packets being analyzed in parallel may be held in the
`
`20
`
`one UFKB.
`
`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
`
`25
`
`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
`
`30
`
`' UFKB.
`
`Once the lookup processing by the LUE has been completed a flag stating whether
`
`Petitioners' EX1016 Page 17
`
`

`
`10
`
`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.
`
`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
`
`n
`
`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.
`
`15
`
`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.
`
`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
`
`20
`
`(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 operate independently from the other two engines.
`
`25
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`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
`
`30
`
`figures.
`
`Petitioners' EX1016 Page 18
`
`

`
`I I
`
`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.
`
`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 conversational
`
`flow between a client and server on a network being monitored and analyzed. A pair of
`
`flow signatures particular to this example and to embodiments of the present invention is
`
`also illustrated. This represents some of the possible flow signatures that can be generated
`
`and used in the process of analyzing packets and of recognizing the particular server
`
`19
`
`applications that produce the discrete application packet exchanges.
`
`FIG. 3 is a functional block diagram of a process embodiment of the present
`
`invention that can operate as the packet monitor shown in FIG. 1. This process may be
`
`implemented in software or hardware.
`
`FIG, 4 is a flowchart of a high-level protocol language compiling and optimization
`
`15
`
`process, which in one embodiment may be used to generate data for monitoring packets
`
`according to versions of the present invention.
`
`FIG. 5 is a flowchart of a packet parsing process used as pa