PATENT NUMBER
`6839761
`
`z0
`
`7C) <
`n
`
`C)
`
`LL
`
`Cf)<
`C)
`
`,
`
`LLJ
`
`(j)
`
`co
`
`U.S. UTILITY Patent Application
`PATENT DATE
`
`O.I.P.E.
`
`SCANNED
`
`G.A.
`
`APPLlcAT16N NO.
`0911608126
`
`CONT/PRIOR CLASS
`709
`D
`
`SUBCLASS
`
`ART UNIT
`
`EXAMINER
`
`50
`
`;"k-jdt-ew
`
`0.
`
`IA *.'.S 1. I't,
`
`J. F I f",
`
`fl-clul
`
`cka-l.(cid:173)'-L-
`
`1,
`
`S,:*-,tl:::: t.:i C,
`
`Certifjrafe
`
`o
`
`of Cori- c,,,or,
`
`PTO-2040
`12/99
`
`ORIGINAL
`
`CLASS
`
`-'7 0 41
`
`I
`
`SUBCLASS
`
`Z -2
`
`INTERNATIONAL CLASSIFICATION
`
`ISSUING CLASSIFICATION
`
`CROSS REFERENCE(S)
`
`CLASS
`
`SUBCLASS (ONE SUBCLASS PER BLOCK)
`
`3
`
`o
`
`lvmjj q ftsg4f
`*40_7 ARAM IUWJ)
`
`DRAWINGS
`
`ontinued on issue Slip inside File Jacket
`
`tLi
`
`3E) - 0 0
`
`CLAIMS ALLOWED
`
`-3 o - 0 Lt
`TERMINAL
`DISCLAIMER
`
`Sheets Drwg.
`
`Figs. Drwg.
`
`Print Fig.
`
`Total Claims
`
`Print Claim for O.G,
`
`The term ot this patent
`
`subsequent to
`
`(date)
`
`has been disclaimed.
`
`(Assistant Examiner)
`
`(Date,
`
`NOTICE OF ALLOWANCE MAILED
`
`6,
`
`cj
`
`1] The term of this patent shall
`
`not extend beyond the expiration date
`
`of U.S Patent. No.
`
`(Primary Examinerr
`
`zCl)-4 13'; o ,
`
`ISSUE FEE
`
`Amount Due
`
`Date Paid
`
`(Date)
`
`6 Z3 04 JPM
`ISSUE BATCH NUMBER
`
`The terminal
`
`mb nths of
`
`patent have been disclaimed.
`
`(Legal Instruments Examiner)
`
`(Date)
`
`WARNING:
`The information disclosed herein may be restricted. Unauthorized disclosure may be prohibited by the United States Code Title 35, Sections 122, 161 and 368.
`Possession outside the U.S. Pateni & Trademark Office is restricted to authorized employees and contractors only.
`
`L
`rorm PTO-436A
`(Rev. 6/99)
`
`FILED WITH: 0 DISK (CRF) [] FICHE L] CD-ROM
`
`(Attached in pocket on right inside flap)
`
`ISSUE FEE IN FILE
`
`(FACE)
`
`Petitioners' EX1015 Page 1
`
`

`
`INITIALS
`
`Date Received
`(incl. C. of M.)
`or
`Date Mailed
`
`t"A I t:N I ArrL-Koft I lw"J
`
`IC-061 L Y. PTO
`09/604,26
`
`09608126
`
`CONTENTS
`
`Application
`
`papers.
`
`Ve-ri.
`
`Date Received
`(incl. C. of M.)
`or
`Date Mailed
`
`k 6 .2
`
`,e
`
`-2,
`
`12 X
`
`D
`
`4.
`
`9.
`
`10
`
`13.
`
`0.
`
`1.-
`r29.
`
`42.-
`
`46.
`
`:-47.
`
`48.
`
`49
`
`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.
`
`81.
`
`82.
`
`(LEFT OUTSIDE)
`
`Petitioners' EX1015 Page 2
`
`

`
`Page 1 of 1
`
`I0
`
`%1 F,1 "I
`
`LTNITED STATES PATENT AM ThADEMAPM OMGE
`
`COMMISSIONER FOR PATENTS
`UNITED STATES PATENT AND TRADEMARK OFFICE
`WASHINGTON, D.C, 20231
`www.uspto.gov
`
`Bib Data Sheet
`
`SERIAL NUMBER
`09/608,126
`
`FILING DATE
`
`06/30/2000
`RULE
`
`APPLICANTS
`Russell S. Dietz, San Jose, CA;
`Joseph R. Maixner, Aptos, CA;
`Andrew A. Koppenhaver, Fairfax, VA;
`
`CLASS
`709
`
`GROUP ART UNIT
`2755
`
`1
`
`ATTORNEY
`DOCKET NO.
`APPT-001-3
`
`CONTINUING DATA
`THIS APPLN CLAIMS BENEFIT OF 60M41,903 06/30/1999
`
`* FOREIGN APPLICATIONS
`
`REQUIRED, FOREIGN FILING LICENSE
`iRANTED ** 08/21/2000
`0 yes
`119 (a-d) conditions Li yes Ri no El Met after
`
`Priority claimed
`
`no
`
`iet
`
`USC
`"'in
`.ri%d and
`
`Allowm
`
`m Rosenfeld
`
`ui 2
`
`3C7 College Avenue
`
`alland CA 94618
`
`SHEETS
`STATE OR
`COUNTRY DRAWING
`CA -
`18
`
`TOTAL
`CLAIMS
`21
`
`EPENDEN
`CLAIMS
`2
`
`information from data transactions for maintaining statistics in network monitoring
`
`El All Fees
`
`El 1.16 Fees Filing
`
`FILING FEE
`RECEIVED
`858
`
`No.
`No.
`
`Authority has been given in Paper
`to charge/credit DEPOSIT ACCOUNT
`for following:
`
`El 1. 17 Fees
`time
`
`Processing Ext. of
`
`El 1.18 Fees Issue
`
`El Other
`
`El Credit
`
`file: //C:\APP S\PreExam\correspondence\ 1 A. xml
`
`12/14/00
`
`Petitioners' EX1015 Page 3
`
`

`
`OurRef./DocketNo.:
`
`APPT-001-3
`
`RE-USING INFORMATION FROM DATA TRANSACTIONS FOR MAINTAINING
`STATISTICS IN NETWORK MONITORING
`
`Inventor(s):
`
`DEETZ, Russell S.
`San Jose, CA
`
`MAIXNER, Joseph R.
`Aptos, CA
`
`KOPPENHAVER, Andrew A.
`Fairfax, VA
`
`I hereby certify that this application and all attachments are being deposited with the United States Postal Service as Express Mail
`
`(Express Mail Label: E1417961927US in an envelope addressed to Box Patent Application, Assistant Conunissioner for Patents,
`Washington, D
`. 20231 o
`
`Certificate of Mailing under 37 CFR 1.10
`
`Date:
`
`/7
`
`5_'D
`
`Signed:
`
`Name.-&vRosenfeld, Reg. No. 38687
`
`Petitioners' EX1015 Page 4
`
`

`
`I
`
`RE-USING INFORMATION FROM DATA TRANSACTIONS FOR
`MAINTAINING STATISTICS IN NETWORK MONITORING
`
`CROSS-REFERENCE TO RELATED APPLICATION
`
`This application claims the benefit of U.S. Provisional Patent Application Serial No.:
`
`5
`
`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:
`
`U.S. Patent Application Serial No. 6 9 10 _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, and incorporated herein by
`
`reference.
`
`15
`
`U.S. Patent Application Serial No. o.0 lgoq 17'ffor PROCESSING PROTOCOL
`
`SPECEFIC INFORMATION IN PACKETS SPECUMD BY A PROTOCOL
`
`DESCRIPTION LANGUAGE, to inventors Koppenhaver, et al., filed June 30, 2000,
`
`Attomey/Agent Reference Number APPT-001-2, and incorporated herein by
`
`reference.
`
`20
`
`U.S. Patent Application Serial No. 01/09-4for ASSOCIATIVE CACHE
`
`STRUCTURE FOR LOOKUPS AND UPDATES OF FLOW RECORDS IN A
`
`NETWORK MONITOR, to inventors Sarkissian, et al., filed June 30, 2000,
`
`Attorney/Agent Reference Number APPT-001-4, and incorporated herein by
`
`reference.
`
`25
`
`U.S. Patent Application Serial No. 69 /0 6for STATE PROCESSOR FOR
`
`.:f
`
`PATTERN MATCHING IN A NETWORK MONITOR DEVICE, to inventors
`
`Sarkissian, et al., filed June 30, 2000, Attomey/Agent Reference Number APPT-001-
`
`5, and incorporated herein by reference.
`
`Petitioners' EX1015 Page 5
`
`

`
`FIELD OF INVENTION
`
`0)
`
`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.
`
`COPYRIGHT NOTICE
`
`A portion of the disclosure of this patent document contains material that is
`
`subject to copyright protection. The copyright owner has no objection to the facsimile
`
`reproduction by anyone of the patent document or the patent disclosure, as it appears in
`
`the Patent and Trademark Office patent file or records, but otherwise reserves all
`
`10
`
`copyright rights whatsoever.
`
`BACKGROUND
`
`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
`
`interconnected networks. In particular, there is a need for a real-time network monitor
`
`15
`
`that can provide details as to the application programs being used. Such a monitor should
`
`enable non-intrusive, remote detection, characterization, analysis, and capture of all
`
`infonnation 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
`
`20
`
`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
`
`delivered, duration, time of day, data requested, etc.). Also, the network monitor should
`not be reliant upon server resident inforrnation such as log files. Rather, it should allow a
`
`25
`
`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.
`
`Related and incorporated by reference U.S. Patent application 6 1
`
`for
`
`30 METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A NETWORK to
`
`Petitioners' EX1015 Page 6
`
`

`
`inventors Dietz, et al, Attomey/Agent Docket APPT-001-1, describes a network monitor
`
`that includes carrying out protocol specific operations on individual packets including
`
`extracting information from header fields in the packet to use for building a signature for
`
`identifying the conversational flow of the packet and for recognizing future packets as
`
`belonging to a previously encountered flow. A parser subsystem includes a parser for
`
`recognizing different pattems in the packet that identify the protocols used. For each
`
`protocol recognized, a 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.
`
`10
`
`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
`
`15
`
`whether a signature is from an existing flow, a state processor (SP) for performing state
`
`processing, a flow insertion and deletion engine (FIDE) for inserting new flows into the
`
`database of flows, a memory for storing the database of flows, and a cache for speeding
`
`up access to the memory containing the flow database. The LUE, SP, and FIDE are all
`
`coupled to the UFKB, and to the cache.
`
`20
`
`Each flow-entry includes one or more statistical measures, e.g., the packet count
`
`related to the flow, the time of arrival of a packet, the time differential.
`
`In the preferred hardware embodiment, each of the LUE, state processor, and
`
`FIDE operate independently from the other two engines. The state processor performs
`
`one or more operations specific to the state of the flow.
`
`25
`
`It is advantageous to collect statistics on packets passing through a point in a
`
`network rather than to simply count each and every packet. By maintaining statistical
`
`measures in the flow-entries related to a conversational flow, embodiments of the present
`
`invention enable specific metrics to be collected in real-time that otherwise would not be
`
`possible. For example, it is desirable to maintain metrics related to bi-directional
`
`9TO,
`
`conversations based on the entire flow for each exchange in the conversation. By
`
`maintaining the state of flow, embodiments of the present invention also enable certain
`
`Petitioners' EX1015 Page 7
`
`

`
`metrics related to the states of flows to be determined.
`
`4
`
`Most prior-art network traffic monitors that use statistical metrics collect only
`
`end-point and end-of-session related statistics. Examples of such commonly used metrics
`
`include packet counts, byte counts, session connection time, session timeouts, session
`
`and transport response times and others. All of these deal with events that can be directly
`
`related to an event in a single packet. These prior-art systems cannot collect some
`
`important performance metrics that are related to a complete sequence of packets of a
`
`flow in a network.
`flow or to several disjointed sequences of the same
`
`Time based metrics on application data packets are important. Such metrics could
`
`10
`
`be determined if all the timestamps and related data could be stored and forwarded for
`
`later analysis. However when faced with thousands or ntillions of conversations per
`
`second on ever faster networks, storing all the data, even if compressed, would take too
`
`much processing, memory, and manager down load time to be practical.
`
`Thus there is a need for maintaining and reporting time-base metrics from
`
`15
`
`statistical measures accumulated from packets in a flow.
`
`Network data is properly modeled as a population and not a sample. Thus, all the
`
`data needs to be processed. Because of the nature of application protocols, just sampling
`
`some of the packets may not give good measured related to flows. Missing just one
`
`critical packet, such as one the specified an additional port that data will be transmitted
`
`20
`
`on, or what application will be run, can cause valid data to be lost.
`
`Thus there is also a need for maintaining and reporting time-base metrics from
`
`statistical measures accumulated from every packet in a flow.
`
`There also is a need to determine metrics related to a sequence of events. A good
`
`example is relative jitter. Measuring the time from the end of one packet in one direction
`
`25
`
`to another packet with the same signature in the same direction collects data that relates
`
`normal jitter. This type of jitter metric is good for measuring broad signal quality in a
`
`packet network. However, it is not specific to the payload or data item being transported
`
`in a cluster of packets.
`
`Using the state processing described herein, because the state processor can
`
`Petitioners' EX1015 Page 8
`
`

`
`5
`
`search for specific data payloads, embodiments of monitor 300 can be programmed to
`
`collect the same jitter metric for a group of packets in a flow that are all related to a
`
`specific data payload. This allows the inventive system to provide metrics more focused
`
`on the type of quality related to a set of packets. This in general is more desirable than
`
`metrics related to single packets when evaluating the performance of a system in a
`
`network.
`
`Specifically, the monitor system 300 can be programrned to maintain any type of
`
`metric at any state of a conversational flow. Also the system 300 can have the actual
`
`statistics programrned into the state at any point. This enables embodiments of the
`
`10 monitor system to collect metrics related to network usage and performance, as well as
`
`metrics related to specific states or sequences of packets.
`
`Some of the specific metrics that can be collected only with states are events
`
`related to a group of traffic in one direction, events related to the status of a
`
`communication sequence in one or both directions, events related to the exchange of
`
`15
`
`packets for a specific application in a specific sequence. This is only a small sample of
`
`the metrics that requires an engine that can relate the state of a flow to a set of metrics.
`
`In addition, because the monitor 300 provides greater visibility to the specific
`
`application in a conversation or flow, the monitor 300 can be programmed to collect
`
`metrics that may be specific to that type of application or service. In other word, if a flow
`
`20
`
`is for an Oracle Database server, an embodiment of monitor 300 could collect the
`
`number of packets required to complete a transaction. Only with both state and
`
`application classification can this type of metric be derived from the network.
`
`Because the monitor 300 can be programrned to collect a diverse set of metrics,
`
`the system can be used as a data source for metrics required in a number of
`
`25
`
`environments. In particular, the metrics may be used to monitor and analyze the quality
`
`and performance of traffic flows related to a specific set of applications. Other
`
`implementation could include metrics related to billing and charge-back for specific
`
`traffic flow and events with the traffic flows. Yet other implementations could be
`
`programmed to provide metrics useful for troubleshooting and capacity planning and
`
`30
`
`related directly to a focused application and service.
`
`Petitioners' EX1015 Page 9
`
`

`
`SUMMARY
`
`m
`
`Another aspect of the invention is determining quality of service metrics based on
`
`each and every packet. A method of and monitor apparatus for analyzing a flow of
`
`packets passing through a connection point on a computer network are disclosed that
`
`may include such quality of service metrics. The method includes receiving a packet
`
`from a packet acquisition device, and looking up a flow-entry database containing flow-
`
`entries for previously encountered conversational flows. The looking up to determine if
`
`the received packet is of an existing flow. Each and every packet is processed. If the
`
`packet is of an existing flow, the method updates the flow-entry of the existing flow,
`
`10
`
`including storing one or more statistical measures kept in the flow-entry. If the packet is
`
`of a new flow, the method stores a new flow-entry for the new flow in the flow-entry
`
`database, including storing one or more statistical measures kept in the flow-entry. The
`
`statistical measures are used to determine metrics related to the flow. The metrics may be
`
`base metrics from which quality of service metrics are determined, or may be the quality
`
`15
`
`of service metrics.
`
`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
`
`20
`
`explanation. The embodiments, in tum, are explained with the aid of the following
`
`figures.
`
`FIG. I 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.
`
`25
`
`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
`
`Petitioners' EX1015 Page 10
`
`

`
`7
`
`generated and used in the process of analyzing packets and of recognizing the particular
`
`server 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
`
`5
`
`implemented in software or hardware.
`
`FIG. 4 is a flowchart of a high-level protocol language compiling and
`
`optimization 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 part of the parser in an
`
`10
`
`embodiment of the inventive packet monitor.
`
`FIG. 6 is a flowchart of a packet element extraction process that is used as part of
`
`the parser in an embodiment of the inventive packet monitor.
`
`FIG. 7 is a flowchart of a flow-signature building process that is used as part of
`
`the parser in the inventive packet monitor.
`
`I
`
`15
`
`FIG. 8 is a flowchart of a monitor lookup and update process that is used as part
`
`of the analyzer in an embodiment of the inventive packet monitor.
`
`FIG. 9 is a flowchart of an exemplary Sun Microsystems Remote Procedure Call
`
`application than may be recognized by the inventive packet monitor.
`
`FIG. 10 is a functional block diagram of a hardware parser subsystem including
`
`20
`
`the pattem recognizer and extractor that can form part of the parser module in an
`
`embodiment of the inventive packet monitor.
`
`FIG. 11 is a functional block diagram of a hardware analyzer including a state
`
`processor that can forin part of an embodiment of the inventive packet monitor.
`
`FIG. 12 is a functional block diagram of a flow insertion and deletion engine
`
`25
`
`process that can form part of the analyzer in an embodiment of the inventive packet
`
`monitor.
`
`FIG. 13 is a flowchart of a state processing process that can form part of the
`
`analyzer in an embodiment of the inventive packet monitor.
`
`I
`
`Petitioners' EX1015 Page 11
`
`

`
`8
`
`FIG. 14 is a simple 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.
`
`FIG. 15 is a functional block diagram of how the packet monitor of FIG. 3 (and
`
`5
`
`FIGS. 10 and 11) may operate on a network with a processor such as a microprocessor.
`
`FIG. 16 is an example of the top (MAC) layer of an Ethemet packet and some of
`
`the elements that may be extracted to form a signature according to one aspect of the
`
`invention.
`
`FIG. 17A is an example of the header of an Ethertype type of Ethemet packet of
`
`io
`
`FIG. 16 and some of the elements that may be extracted to form a signature according to
`
`one aspect of the invention.
`
`FIG. 17B is an example of an EP packet, for example, of the Ethertype packet
`
`shown in FIGs. 16 and 17A, and some of the elements that may be extracted to form a
`
`signature according to one aspect of the invention.
`
`15
`
`FIG. 18A is a three dimensional structure that can be used to store elements of
`
`the pattem, parse and extraction database used by the parser subsystem in accordance to
`
`one embodiment of the invention.
`
`FIG. 18B is an altemate form of storing elements of the pattem, parse and
`
`extraction database used by the parser subsystem in accordance to another embodiment
`
`20
`
`of the invention.
`
`DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
`
`Note that this document includes hardware diagrams and descriptions that may
`
`include signal names. In most cases, the names are sufficiently descriptive, in other cases
`
`however the signal names are not needed to understand the operation and practice of the
`
`25
`
`invention.
`
`Operation in a Network
`
`FIG. 1 represents a system embodiment of the present invention that is referred to
`
`herein by the general reference numeral 100. The system 100 has a computer network
`
`Petitioners' EX1015 Page 12
`
`

`
`m
`
`102 that communicates packets (e.g., IP datagrams) between various computers, for
`
`example between the clients 104-107 and servers 110 and 112. The network is shown
`
`schematically as a cloud with several network nodes and links shown in the interior of
`
`the cloud. A monitor 108 examines the packets passing in either direction past its
`
`connection point 121 and, according to one aspect of the invention, can elucidate what
`
`application programs are associated with each packet. The monitor 108 is shown
`
`exan-iining packets (i. e., datagrams) between the network interface 116 of the server I 10
`
`and the network. The monitor can also be placed at other points in the network, such as
`
`connection point 123 between the network 102 and the interface 118 of the client 104, or
`
`10
`
`some other location, as indicated schematically by connection point 125 somewhere in
`
`network 102. Not shown is a network packet acquisition device at the location 123 on
`
`the network for converting the physical information on the network into packets for input
`
`into monitor 108. Such packet acquisition devices are common.
`
`Various protocols may be employed by the network to establish and maintain the
`
`15
`
`required communication, e.g., TCP/IP, etc. Any network activityfor example an
`
`application program run by the client 104 (CLIENT 1) communicating with another
`
`running on the server 110 (SERVER 2)will produce an exchange of a sequence of
`
`packets over network 102 that is characteristic of the respective programs and of the
`
`network protocols. Such characteristics may not be completely revealing at the
`
`20
`
`individual packet level. It may require the analyzing of many packets by the monitor 108
`
`to have enough information needed to recognize particular application programs. The
`
`packets may need to be parsed then analyzed in the context of various protocols, for
`
`example, the transport through the application session layer protocols for packets of a
`
`type conforming to the ISO layered network model.
`
`25
`
`Communication protocols am layered, which is also referred to as a protocol
`
`stack. The ISO (Intemational Standardization Organization) has defined a general model
`
`that provides a framework for design of communication protocol layers. This model,
`
`shown in table form below, serves as a basic reference for understanding the
`
`functionality of existing communication protocols.
`
`Petitioners' EX1015 Page 13
`
`

`
`BOMMM=
`
`10
`
`ISO MODEL
`
`Layer
`
`Functionality
`
`Example
`
`7
`
`6
`
`5
`
`4
`
`3
`
`2
`
`1
`
`Application
`
`Telnet, NFS, Novell NCP, HTTP,
`
`H.323
`
`Presentation
`
`XDR
`
`Session
`
`RPC, NETBIOS, SNMP, etc.
`
`Transport
`
`TCP, Novel SPX, UDP, etc.
`
`Network
`
`IP, Novell IPX, VIP, AppleTalk, etc.
`
`Data Link
`
`Network Interface Card (Hardware
`
`Interface). MAC layer
`
`Physical
`
`Ethemet, Token Ring, Frame Relay,
`
`ATM, Tl (Hardware Connection)
`
`Different conimunication protocols employ different levels of the ISO model or
`
`may use a layered model that is similar to but which does not exactly conform to the ISO
`
`model. A protocol in a certain layer may not be visible to protocols employed at other
`
`5
`
`layers. For example, an application (Level 7) may not be able to identify the source
`
`computer for a conimunication attempt (Levels 2-3).
`
`In some conimunication arts, the term "frame" generally refers to encapsulated
`
`data at OSI layer 2, including a destination address, control bits for flow control, the data
`
`or payload, and CRC (cyclic redundancy check) data for error checking. The term
`"packet" generally refers to encapsulated data at OSI layer 3. In the TCP/IP world, the
`
`10
`
`term "datagram" is also used. In this specification, the term "packet" is intended to
`
`encompass packets, datagrams, frames, and cells. In general, a packet format or frame
`
`fonnat refers to how data is encapsulated with various fields and headers for
`
`transmission across a network. For example, a data packet typically includes an address
`
`15
`
`destination field, a length field, an error correcting code (ECC) field, or cyclic
`
`redundancy check (CRC) field, as well as headers and footers to identify the beginning
`
`m
`
`Petitioners' EX1015 Page 14
`
`

`
`11
`
`and end of the packet. The terms "packet format" and "frame format," also referred to as
`
`"cell format," are generally synonymous.
`
`Monitor 108 looks at every packet passing the connection point 121 for analysis.
`
`However, not every packet carries the same information useful for recognizing all levels
`
`of the protocol. For example, in a conversational flow associated with a particular
`
`application, the application will cause the server to send a type-A packet, but so will
`
`another. If, though, the particular application program always follows a type-A packet
`
`with the sending of a type-B packet, and the other application program does not, then in
`
`order to recognize packets of that application's conversational flow, the monitor can be
`
`10
`
`available to recognize packets that match the type-B packet to associate with the type-A
`
`packet. If such is recognized after a type-A packet, then the particular application
`
`program's conversational flow has started to reveal itself to the monitor 108.
`
`Further packets may need to be examined before the conversational flow can be
`
`identified as being associated with the application program. Typically, monitor 108 is
`
`15
`
`simultaneously also in partial completion of identifying other packet exchanges that are
`
`parts of conversational flows associated with other applications. One aspect of monitor
`
`108 is its ability to maintain the state of a flow. The state of a flow is an indication of all
`
`previous events in the flow that lead to recognition of the content of all the protocol
`
`levels, e.g., the ISO model protocol levels. Another aspect of the invention is forming a
`
`20
`
`signature of extracted characteristic portions of the packet that can be used to rapidly
`
`identify packets belonging to the same flow.
`
`In real-world uses of the monitor 108, the number of packets on the network 102
`
`passing by the monitor 108's connection point can exceed a million per second.
`
`Consequently, the monitor has very little time available to analyze and type each packet
`
`25
`
`and identify and maintain the state of the flows passing through the connection point.
`
`The monitor 108 therefore masks out all the unimportant parts of each packet that will
`
`not contribute to its classification. However, the parts to mask-out will change with each
`
`packet depending on which flow it belongs to and depending on the state of the flow.
`
`The recognition of the packet type, and ultimately of the associated application
`
`30
`
`programs according to the packets that their executions produce, is a multi-step process
`
`within the monitor 108. At a first level, for example, several application programs will
`
`Petitioners' EX1015 Page 15
`
`

`
`12
`
`all produce a first kind of packet. A first "signature" is produced from selected parts of a
`
`packet that will allow monitor 108 to identify efficiently any packets that belong to the
`
`same flow. In some cases, that packet type may be sufficiently unique to enable the
`
`monitor to identify the application that generated such a packet in the conversational
`
`flow. The signature can then be used to efficiently identify all future packets generated in
`
`traffic related to that application.
`
`In other cases, that first packet only starts the process of analyzing the
`
`conversational flow, and more packets are necessary to identify the associated
`
`application program. In such a case, a subsequent packet of a second typebut that
`
`10
`
`potentially belongs to the same conversational flowis recognized by using the
`
`signature. At such a second level, then, only a few of those application programs will
`
`have conversational flows that can produce such a second packet type. At this level in
`
`the process of classification, all application programs that are not in the set of those that
`
`lead to such a sequence of packet types may be excluded in the process of classifying the
`
`15
`
`conversational flow that includes these two packets. Based on the known pattems for the
`
`protocol and for the possible applications, a signature is produced that allows recognition
`
`of any future packets that may follow in the conversational flow.
`
`It may be that the application is now recognized, or recognition may need to
`
`proceed to a third level of analysis using the second level signature. For each packet,
`
`20
`
`therefore, the monitor parses the packet and generates a signature to determine if this
`
`signature identified a previously encountered flow, or shall be used to recognize future
`
`packets belonging to the same conversational flow. In real time, the packet is further
`
`analyzed in the context of the sequence of previously encountered packets (the state), and
`
`of the possible future sequences such a past sequence may generate in conversational
`
`25
`
`flows associated with different applications. A new signature for recognizing future
`
`packets may also be generated. This process of analysis continues until the applications
`
`are identified. The last generated signature may then be used to efficiently recognize
`
`future packets associated with the same conversational flow. Such an arrangement makes
`
`it possible for the monitor 108 to cope with millions of packets per second that must be
`
`IM,
`
`inspected.
`
`Petitioners' EX1015 Page 16
`
`

`
`13
`
`Another aspect of the invention is adding Eavesdropping. In altemative
`
`embodiments of the present invention capable of eavesdropping, once the monitor 108
`
`has recognized the executing application programs passing through some point in the
`
`network 102 (for example, because of execution of the applications by the client 105 or
`
`server 110), the monitor sends a message to some general purpose processor on the
`
`network that can input the same packets from the same location on the network, and the
`
`processor then loads its own executable copy of the application program and uses it to
`
`read the content being exchanged over the network. In other words, once the monitor 108
`
`has accomplished recognition of the application program, eavesdropping can commence.
`
`10
`
`The Network Monitor
`
`FIG. 3 shows a network packet monitor 300, in an embodiment of the present
`
`invention that can be implemented with computer hardware and/or software. The system
`
`300 is similar to monitor 108 in FIG. 1. A packet 302 is examined, e.g., from a packet
`
`acquisition device at the location 121 in network 102 (FIG. 1), and the packet evaluated,
`
`15
`
`for example in an attempt to determine its characteristics, e.g., all the protocol
`
`information in a multilevel model, including what server application produced the
`
`packet.
`
`The packet acquisition device is a common interface that converts the physical
`
`signals and then decodes them into bits, and into packets, in accordance with the
`
`20
`
`particular network (Ethemet, frame relay, ATM, etc.). The acquisition device indicates to
`
`the monitor 108 the type of network of the acquired packet or packets.
`
`Aspects shown here include: (1) the initialization of the monitor to gener