IN THE U.S. PATENT AND TRADEMARK OFFICE
`Provisional Application Cover Sheet
`
`0R-
`OUR DOCKET NO. APPTIT-0(11
`
`c=o
`
`nASSISTANT COMMISSIONER FOR PATENTS
`0 Washington, D.C. 20231
`
`Ca) ••••=m.
`
`la
`
`-
`
`-
`
`IU This is a request for filing a PROVISIONAL APPLICATION under 37 CFR 1.53 (b)(2).
`O
`
`Last Name
`
`INVENTOR(s)/APPLICANT(s)
`First Name, MI (cid:9)
`Residence (City and Either State or Foreign Country)
`
`Russel S. (cid:9)
`Dietz (cid:9)
`San Jose, CA
`Maixner (cid:9)
`Santa Cruz, CA
`Joseph R. (cid:9)
`Vienna, VA
`Koppenhaver (cid:9)
`Andrew A. (cid:9)
`Additional inventors are being named on separately numbered sheets attached hereto.
`
`TITLE OF THE INVENTION
`
`METHOD AND APPARATUS FOR MONITORING TRAFFIC IN A NETWORK
`
`CORRESPONDENCE ADDRESS
`
`Dov Rosenfeld
`5507 College Avenue
`Suite 2
`Oakland, CA 94618
`
`ENCLOSED APPLICATION PARTS (check all that apply)
`
`( X ) Specification (cid:9)
`( X ) Drawing(s) (cid:9)
`( (cid:9)
`) Power of Attorney
`( X ) Additional inventors are being named on separately numbered sheets attached hereto.
`
`Number of Pages .. (cid:9)
`Number of Pages (cid:9)
`
`242
`25
`
`METHOD OF PAYMENT
`
`A check in the amount of $ 150.00 to cover the filing fee is enclosed.
`
`If the check is insufficient, please charge any missing fees to Deposit Account 50-0292 .
`
`'Express Mail" label no. EE516848835US
`
`Date of Deposit: 6/30/1999
`
`1 hereby certify that this is being deposited with the United States
`Postal Service 'Express Mail Post Office to Addressee' service under
`37 CFR 1.10 on the date indicated above and is addressed to the
`Assistant Commissioner for Patents, Washington, D.C. 20231.
`
`By
`Typed (cid:9)
`
`e: Dov Rosenfeld
`
`Respectfully submitted,
`
`Rosenfeld
`Agent for Applicant(s)
`Reg. No. 38687
`
`Date: 6/30/1999
`
`Telephone No.: +1-510-547-3378
`
`EX 1016 Page 1
`
`(cid:9)
`

`

`4
`
`ATTORNEY DOCKET NO. APPTIT-001
`
`Provisional Application Cover Sheet (cont.)
`
`INVENTOR(s)/APPLICANT(s)
`
`Last Name
`
`Bares (cid:9)
`
`Sarkissian (cid:9)
`
`First Name, MI (cid:9)
`
`Residence (City and Either State or Foreign Country)
`
`William H. (cid:9)
`
`Haig A. (cid:9)
`
`Germantown, Tennessee
`
`Bexar County, Texas
`
`EX 1016 Page 2
`
`(cid:9)
`

`

`Please type a plus sign (+) inside this box —> (cid:9) El
`
`PTO/SB/16 (2-98)
`Approved for use through 01/31/2001. OMB 0651-0037
`Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a
`valid OMB control number.
`
`PROVISIONAL APPLICATION FOR PATENT COVER SHEET
`
`PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.53(c).
`-
`• - (cid:9)
`INVENTOR(S)
`
`Residence
`(City and either State or Foreign Country)
`Family Name or Surname
`Given Name ( first and middle [if any))
`San Jose, CA
`Dietz
`Russel S.
`Santa Cruz , CA
`Maixner
`Joseph It
`Vienna, VA
`Koppenhaver
`Andrew A.
`separately numbered sheets attached hereto
`li (cid:9) Additional inventors are being named on the 1 (cid:9)
`TITLE OF THE INVENTION (280 characters max)
`METRODANDAPPARATISFORMONITORINGTRAWICINANZIWORK
`
`Direct all correspondence to: (cid:9)
`X Customer Number
`
`21921
`
`CORRESPONCENCEADDRESS
`
`Place Customer Number
`Bar Code Label here
`
`NV
`
`OR
`X Firm or
`Individual Name
`Address
`Address
`City
`Country
`
`Type Customer Number here
`Dov Rosenfeld
`
`5507 College Avenue, Suite 2
`
`Oakland
`USA
`
`CA
`State
`Telephone +1-510-547-
`3378
`ENCLOSED APPLICATION PARTS (chock all that apply)
`
`ZIP
`Fax
`
`94618
`+1-510-653-
`7992
`
`X Specification Number of Pages d-171 a.
`X Drawing(s) Number of Sheets ac
`
`Small Entity Statement
`check, postcard
`X Other (specify)
`METHOD OF PAYMENT OF FILING FEES FOR THIS PROVISIONAL APPLICATION FOR PATENT (check one)
`FILING FEE
`x A check or money order is enclosed to cover the filing fees (cid:9)
`AMOUNT ($)
`
`X The Commissioner Is hereby authorized to charge any mising
`fees or credit any overpayment to Deposit Account Number:
`
`50-0292
`
`$150.
`
`The invention was made by an agency of the United States Government or under a contract with an agency of
`the United States Government.
`X No.
`Yee, the name of the U.S. Government agency and the Government contract number are:
`
`Respectfully submitted,
`
`SIGNATURE
`
`TYPED or PRINTED NAME Dov Rosenfeld
`
`Date June 30,
`1999
`
`REGISTRATION NO.
`(if appropriate)
`
`38,687
`
`TELEPHONE +1-510-547-3378
`USE ONLY FOR FILING A PROVISIONAL APPLICATION FOR PATENT
`This collection of information is required by 37 CFR 1.51. The Information is used by the public to file (and by the PTO to process) a
`provisional application. Confidentiality is governed by 35 U.S.C. 122 and 37 CFR 1.14. This collection is estimated to take 8 hours to
`complete, including gathering, prepanng, and submitting the complete provisional application to the PTO. Time will vary depending upon the
`individual case. Any comments on the amount of time you require to complete this form and/or suggestions for reducing this burden, should
`be sent to the Chief Information Officer, U.S. Patent and Trademark Office. U.S. Department of Commerce, Washington, D.C., 20231. DO
`NOT SEND FEES OR COMPLETED FORMS TO THIS ADDRESS. SEND TO: Box provisional Application, Assistant Commissioner for
`Patents, Washington, D.C., 20231.
`
`Docket Number: APPTIT-001
`
`Certificate of Mailing under 37 CFR 1.10
`I hereby certify that this application and all attachments are being deposited with the United States Postal Service as
`Express Mail (Express Mail Label: EE516848835US in an envelope addressed to Box Provision a pplication,
`Assistant Commissioner for Patents, Washington, D.C. 20231 on.
`Pis et 6:11 (cid:9)
`
`Date: (cid:9)
`
`Signed:
`Name: (cid:9)
`
`enfeld, Reg. No. 38,687
`
`EX 1016 Page 3
`
`

`

`PROVISIONAL APPLICATION COVER SHEET
`Additional Page
`PTO/SB/16 (2-98)
`Approved for use through 01/31/2001. OMB 0651-0037
`Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a
`
`APPTITUDE-001
`I Docket Number
`INVENTOR(S) /APPLICANT(S)
`
`Type a plus sign(+)
`inside this box 3
`
`+
`
`Given Name (first and middle[if any])
`William H.
`Haig A.
`
`Family or Surname
`Bares
`Sarkissian
`
`Residence
`(City and either State or Foreign Country)
`Germantown, Tennessee
`Bexar County, Texas
`
`Number 1 of 1 additional pages
`
`EX 1016 Page 4
`
`

`

`Our Ref./Docket No: APPTIT-001
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`Inventor(s):
`
`DIETZ, Russel S.
`San Jose, CA
`
`MAIXNER, Joseph R.
`Santa Cruz, CA
`
`KOPPENHAVER, Andrew A.
`Vienna, VA
`
`BARES, William H.
`Germantown, Tennessee
`
`SARKISSIAN, Haig A.
`Bexar County, Texas
`
`Certificate of Mailing under 37 CFR 1.10
`I hereby certify that this application and all attachments are being deposited with the United States Postal Service as
`Express Mail (Express Mail Label: EE516848835US in an envelope addressed to Box Provisional Application,
`Assistant Commissioner for Patents, Washington, D.C. 20231 on.
`Date:
`
`
`Signed: (cid:9)
`Name: Dov Rosenfeld, Reg. No. 38,687
`
`EX 1016 Page 5
`
`(cid:9)
`

`

`1
`
`METHOD AND APPARATUS FOR MONITORING
`TRAFFIC IN A NETWORK
`
`FIELD OF INVENTION
`
`5 (cid:9)
`
`The present invention relates to computer networks, and more specifically to the
`real-time elucidation of packets communicated within a data network, for example,
`between a client and a server, the elucidation including classification by protocol and
`
`application program.
`
`COPYRIGHT NOTICE
`
`10 (cid:9)
`
`15 (cid:9)
`
`20 (cid:9)
`
`25 (cid:9)
`
`A portion of the disclosure of this patent document contains material which 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
`copyright rights whatsoever.
`
`BACKGROUND TO THE PRESENT INVENTION
`
`There has long been a need for network activity monitors. The popularity of
`networks used as a collection of clients obtaining services from one or more servers on
`the network, and especially the recent popularity of the Internet and other internets (an
`"internet" is a plurality of interconnected networks to form a larger single network) has
`made it increasingly important to be able to monitor the use of services offered on the
`network and rate those services accordingly. For example, objective information such as
`which services (i.e., application programs) are being used, who is using them, how often
`they have been accessed, when they are being accessed, how long accesses have been,
`and so forth. Additionally, remote access by selected users to generate reports in real
`time on network use is needed. Finally, an network monitor which can provide alarms in
`real-time to notify selected users of network or site problems is needed.
`
`Selected network activities may be retrospectively analyzed by reviewing log
`files. Log files 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. However, there exist several problems with this method. First, log file
`
`EX 1016 Page 6
`
`

`

`2
`
`information does not provide any real-time usage map. Secondly, log file mining does
`
`not supply complete information. The method relies on logs maintained by numerous
`
`network devices and servers and the information in them must be subjected to refining
`
`and correlation. Sometimes, for example in the case of information about NetMeeting®
`
`5 (cid:9)
`
`(Microsoft Corporation, Redmond, Washington) sessions where two computers connect
`
`directly on the network and the data is never seen by a server or gateway, information is
`
`simply not available to any server or gateway, in order to make a log file entry. Creating
`
`log files requires data logging features of network elements to be enabled, placing a
`
`substantial load on the device performance, thus reducing network performance. Log-
`
`in (cid:9)
`
`files also require a substantial amount of maintenance (there is no standard way of
`
`storing for log files), and grow rapidly.
`
`NetFlow® (Cisco Systems, Inc., San Jose, California), RMON2, and other
`
`network monitor devices are available for the real-time monitoring of networks, but
`
`these lack visibility into application content and context and are therefore typically
`
`15 (cid:9)
`
`limited to providing network layer level information.
`
`Pattern-matching parser techniques wherein a packet is parsed and pattern filters
`
`are applied also are known. These too are limited in how deep into the protocol stack
`
`they can examine packets.
`
`What is needed, therefore, is a network monitor that makes it possible to
`
`20 (cid:9)
`
`continuously analyze all user sessions on a heavily trafficked network, remotely and in a
`
`noninvasive manner. 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 all packet streams passing through any location in the
`
`network. Not only should all the packets be detected and analyzed, but for each of these
`
`25 (cid:9)
`
`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 pattern of use within each application or the application context
`
`(e.g., options selected, service level delivered, duration, time of day, data requested, and
`
`so forth). The network monitor also should not be reliant upon server resident
`
`30 (cid:9)
`
`information such as log files. It should thus allows a user such as a network
`
`administrator or an Internet service provider (ISP) the means to objectively measure and
`
`EX 1016 Page 7
`
`(cid:9)
`(cid:9)
`(cid:9)
`(cid:9)
`(cid:9)
`(cid:9)
`

`

`analyze network activity, customize the type of data that collected and analyzed,
`
`undertake real time analysis and receive timely notification of network problems.
`
`3
`
`Some prior art packet monitors classify packets into connection flows. The term
`
`connection flow is sometimes used to describe all the packets involved with a single
`
`5 (cid:9)
`
`connection. A conversational flow, on the other hand, is the sequence of packets that are
`
`exchanged in any direction as a result of an activity, for example, 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.
`
`Some conversational flows involve more than one connection, and some even
`
`io (cid:9)
`
`involve more than one exchange of packets between a client and a server. This is a
`
`particularly true when using client/server protocols, such as RPC, DCOMP, and SAP,
`
`that enable a service to be set up or defined prior to any use of that service. For example,
`
`SAP (Service Advertising Protocol) is a NetWare (Novell Systems, Provo, Utah)
`
`protocol used to identify the services and addresses of servers attached to a network. In a
`
`15 (cid:9)
`
`first exchange, a client sends a SAP request to a server, for example, for print service.
`
`The server sends a SAP reply that identifies a particular address, for example, SAP #5, as
`
`the print service on that server. Such may be responses used to update a table, for
`
`example in a router, known as the Server Information Table. A client who has
`
`inadvertently seen this reply or who has access to the table (via the router that has the
`
`20 (cid:9)
`
`Server Information Table, for example) would know that SAP #5 for such this server is a
`
`print service. Therefore, in order to print data on the server, such a client does not need
`
`to make the request for a print service, but simply to send data to be printed specifying
`
`SAP #5. This sending of data to be printed again involves an exchange of data between a
`
`client and a server, disjoint from the previous exchange which was with a different client
`
`25 (cid:9)
`
`setting up that SAP #5 is a print service on this server is a second connection. It is
`
`desirable for a network packet monitor to be able to "virtually concatenate" the first
`
`exchange that defines SAP #5 as the print service on the server with the second exchange
`
`that uses the print service. The two packet exchanges would then be correctly identified
`
`as being part of the same flow if the clients were the same. They would even be
`recognized if the clients were not the same. One feature of the invention is to so correctly
`
`30 (cid:9)
`
`identify the second exchange as being associated with a print service on the server.
`
`EX 1016 Page 8
`
`

`

`4
`
`Other protocols that are similar in that they may lead to disjointed conversational
`
`flows include DCOM (Distributed Component Object Model), formerly called Network
`OLE (Microsoft Corporation, Redmond, Washington), which is Microsoft's technology
`
`for distributed objects, RPC (Remote Procedure Call), and CORBA (Common Object
`Request Broker Architecture). RPC is a programming interface from Sun Microsystems
`
`5 (cid:9)
`
`(Palo Alto, California) that allows one program to use the services of another program in
`a remote machine. DCOM defines the remote procedure call which allows those objects
`
`to be run remotely over the network. DCOM Microsoft's counterpart to CORBA, a
`standard from the Object Management Group (OMG) for communicating between
`
`to (cid:9)
`
`distributed objects (objects are self-contained software modules). CORBA provides a
`way to execute programs (objects) written in different programming languages running
`
`on different platforms no matter where they reside in the network.
`
`Prior art network monitors do not presently have the ability to recognize such
`
`disjointed flows as belonging to the same conversational flow.
`
`15 (cid:9)
`
`20 (cid:9)
`
`25 (cid:9)
`
`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." Phael describes a network activity monitor that
`processes only randomly selected packets in United States Patent 5,315,580, titled
`"NETWORK MONITORING DEVICE AND SYSTEM." Nakamura teaches a network
`
`monitoring system in United States Patent 4,891,639, titled "MONITORING SYSTEM
`OF NETWORK." Ross, et al., teach a method and apparatus for analyzing and
`monitoring network activity in United States Patent 5,247,517, titled "METHOD AND
`APPARATUS FOR ANALYSIS NETWORKS," McCreery, et al., describe an Internet
`activity monitor that decodes packet data at the Internet protocol level layer in United
`States Patent 5,787,253, titled "APPARATUS AND METHOD OF ANALYZING
`
`INTERNET ACTIVITY,"
`
`EX 1016 Page 9
`
`

`

`SUMMARY
`
`5
`
`One aspect of the present invention is providing a network monitor that can
`
`recognize and classify at all protocol layer levels conversational flows that pass in either
`
`direction at a point in a network.
`
`5 (cid:9)
`
`Another aspect of the present invention is providing a network monitor that can
`
`recognize and classify at all packets that are exchanges between a client and a server into
`
`respective client/server applications.
`
`Another aspect of the present invention is providing a network monitor that can
`
`determine the connection and flow progress between clients and servers by the individual
`
`to (cid:9)
`
`packets exchanged over a network.
`
`Another aspect of the present invention is providing a network monitor that can
`
`determine the connection and flow progress between clients and servers by the individual
`
`packets exchanged over a network.
`
`Another aspect of the present invention is providing a network monitor that can
`
`15 (cid:9)
`
`be used to help tune the performance of a network according to the current mix of
`
`client/server applications needing network resources.
`
`A still further aspect of the present invention is providing a network monitor that
`can maintain statistics relevant to the mix of client/server applications using network
`
`resources.
`
`20 (cid:9)
`
`Another aspect of the present invention is providing a network monitor that
`reports on the occurrences of specific sequences of packets used by particular
`
`applications for client/server network conversations.
`
`Another aspect of an embodiment of the invention is properly analyzing each of
`the packets exchanged between a client and a server and maintain information relevant to
`
`25 (cid:9)
`
`the current state of each of these conversations.
`
`Another aspect of an embodiment of the invention is a flexible processing system
`
`that can be tailored or adapted as new application entered the client/server market.
`
`Another feature of an embodiment of the invention is maintaining statistics
`
`EX 1016 Page 10
`
`

`

`relevant to the conversations in a client/server network as their classified by an
`
`individual application.
`
`6
`
`Another feature of an embodiment of the invention is reporting a specific
`
`identifier, which may be used by other network, oriented devices to identify the series of
`
`5 (cid:9)
`
`packets with a specific application for a specific client/server network conversation.
`
`Additional features and advantages of the invention will be clear from the
`
`description which follows.
`
`In general, the embodiments of the present invention overcome the problems and
`
`disadvantages of the prior art.
`
`More aspects and advantages of the present invention are set forth in part in a
`
`description that follows, and in part are obvious from a description, or may be learned by
`
`practice of the present invention. The objects and advantages of the present invention
`
`may be realized by the elements and combinations particularly pointed out in the
`
`appended claims.
`
`Embodiments of the present invention overcome the problems and disadvantages
`
`of prior art and achieves the objects of the present invention by analyzing each of the
`
`packets passing through any point in the network in either direction, extracting a
`
`signature for th conversation which may then be used for identifying the conversational
`
`flows. Another feature of the invention is forming and remembering the state of any
`conversational flow, which is deteti (cid:9) lined by the relationship between individual packets
`of the conversational flow and the entire conversational flow over the network. By so
`
`remembering the state of a flow, a feature of the invention is to the determine the context
`
`of the conversational flow, including the application program it relates to and such
`
`parameters as the time, length of conversation, data rate, etc.
`
`to (cid:9)
`
`15 (cid:9)
`
`20 (cid:9)
`
`25 (cid:9)
`
`A monitor embodiments of the present invention determine the identities of any
`
`and all application programs executing on the network by evaluating each and every
`
`packet conversing between clients and servers. In one embodiment, the monitor
`
`comprises parser that includes a packet parsing module, and an identifying information
`extracting module to faun a signature from a packet received by the parser. The monitor
`
`30 (cid:9)
`
`further comprises an analyzer which receives the signature from the parser and comprises
`
`EX 1016 Page 11
`
`

`

`7
`
`a flow lookup/update engine, a flow insertion and deletion engine, a state processor, a
`
`cache and a unified memory controller. Each of these analyzer elements work in parallel
`
`to create and update flow recognition signatures. The monitor is scalable to handle more
`
`protocols and applications. As a flow signature is examined by the monitor, the lookup
`
`5 (cid:9)
`
`engine attempts to find the signature in a flow-entry database. If the first part of the flow
`
`matches an already identified signature that resides in the cache, the lookup engine
`
`retrieves the flow from the cache, else if the first part of the flow matches an already
`
`identified signature that is not in the cache, it retrieves the flow from a flow database.
`
`The flow entry for previously encountered flows preferably includes state information,
`
`10 (cid:9)
`
`and this state information is used in the state processor to execute any operations defined
`
`for the state, and to determine the next state. The flow entry is updated by adding values
`
`to counters in the flow-entry database entry. If a flow does not exist, the protocol is
`
`identified and the state processor starts executing whatever operations are defined for the
`
`initial state. The state processor sends a flow signature to the flow insertion and deletion
`
`15 (cid:9)
`
`engine that adds the flow to the database as a new item. The state processor updates the
`
`flow based on the current state and the flow-signature information. The state processor
`
`processes single and multi packet protocol recognition. It may have to search through a
`
`series of possible states to determine the flow's actual state. The result of this processing
`
`is a consolidated flow entry. This enables the monitor to correctly determine disjointed
`
`20 (cid:9)
`
`flows. For example, a PointCast session (PointCast, Inc., Cupertino, CA) will open
`
`multiple conversations packet-by-packet that might look like separate flows to prior art
`
`monitors. However, each of these connections is merely a sub-flow under the PointCast
`
`master flow, so a single flow that consolidates all of the information for the flow is
`
`desired. The analyzer is able to so consolidate individual connections since the state of
`
`25 (cid:9)
`
`the overall flow is maintained by the monitor. The unified memory controller can be
`
`setup to work with various memory device types and controls an SRAM tag memory for
`
`shadowing of flow entries. The cache is used to optimize memory bandwidth. On a
`
`typical network, the packets will have a certain amount of congruity so a cache
`
`architecture can have a relatively high hit rate.
`
`30
`
`Invention Overview
`
`A real-time traffic classification system, which has the ability to derive the
`
`EX 1016 Page 12
`
`

`

`8
`
`application or service being used over the data communications network, comprises the
`
`following modules found in Fig. 10 and Fig. 11. A pattern analysis and recognition
`
`engine 1006, a pattern extraction engine 1007, a unique signature generation engine
`
`(elements of 1007), a signature matching engine 1107, a protocol and layer identification
`
`5 (cid:9)
`
`engine (elements of 1107), the state oriented processing engine 1108, the derived set of
`
`rules 1109 and a set of active and in process signatures and records (Fig. 3, 319). The
`
`pattern analysis and recognition engine 1006 is used to derive and determine the type of
`
`network packets that exist on the network. Once a pattern match has occurred, the pattern
`
`is passed on to the pattern extraction engine 1007 for the generation of a signature. The
`
`10 (cid:9)
`
`pattern extraction engine extracts components from each of the packets required in the
`
`formation of unique signature. Once these elements have been extracted from the
`
`packets, the information is passed on to the unique signature generation engine 1007.
`
`The signature generation engine then sequences and formats the extracted information
`
`into a unique signature that will be used to identify other packets within the same
`
`15 (cid:9)
`
`conversation on the network. The contents of the unique signature are passed on to a
`
`matching engine 1107, which looks up the signature from the database of currently
`
`known conversations or flows. If the signature-matching engine determines an existing
`
`conversation, information is passed on to update the contents of the record in the
`
`database and processing is teiminated for this packets 1112. If either no match is found
`
`20 (cid:9)
`
`or a match is found with remaining state or rules to be processed, the protocol layer
`
`identification engine 1107 is initiated to derive the layering involved in the packets. With
`
`the layering information interpreted and understood, the system begins the process of
`
`protocol application identification. This process is initiated by the state oriented
`
`processing engine 1108. This processing engine uses a set of derive states or rules to
`
`25 (cid:9)
`
`apply to each of the individual packets 1109 and signature these to determine the extent
`
`of the application used in the conversation. When the processing engine determines the
`
`application component of a conversation, that information is updated in the conversation
`
`record for this particular flow. In this way, multiple packets from a conversation can be
`
`used to derive the application component of a particular set of packets exchanged
`
`30 (cid:9)
`
`between nodes in a network. In addition to maintaining the actual application
`
`information relative to conversation in a network, the system maintains real-time
`
`statistics relevant to these applications.
`
`EX 1016 Page 13
`
`

`

`Packet Parsing Sub-System
`
`9
`
`The packet parsing system consists of two main sub engines. These engines are
`the pattern analysis and recognition engine (PAR) and the field extraction engine (FEE).
`
`The pattern analysis and recognition engine interprets each packet that is seen
`
`5 (cid:9)
`
`entering the system. As individual fields from each packet enter the system the field
`
`contents are analyzed for specific patterns. As more fields under the system fewer pattern
`
`to remain to be analyzed and through the process of elimination particular pattern for
`
`packet is found.
`
`The patterns for this engine are stored in a special pattern database. The pattern
`
`to (cid:9)
`
`database contains a sparsely populated three-dimensional array of patterns and links to
`
`additional those beyond the patterns that are being currently analyzed. Because this is a
`
`sparsely populated three-dimensional array, as patterns enter the system the depth of
`
`nodes is eliminated rapidly. Once a node does not contain a link to a deeper level, the
`
`pattern matching is complete. At that point, the field extraction engine instruction found
`
`15 (cid:9)
`
`at that node in the array is sent to the field extraction engine with this packet.
`
`The field extraction engine takes the packet contents and the extraction
`
`instructions from the pattern analysis and recognition engine to continue processing the
`
`packet. Each of the elements found within the instructions of the field extraction engine
`
`component are removed from the packet and inserted into a buffer for signature
`
`20 (cid:9)
`
`generation. Once all the operations requested of the field extraction engine are completed
`
`for this packet, the signature is set as complete, and a hash key is generated to identify
`
`this signature.
`
`Packet Analysis Sub-System.
`
`When the parsing system has successfully completed the task of deriving,
`
`25 (cid:9)
`
`determining and extracting the required information, the remaining pieces of the packet
`
`and the generated signature for the packet are passed to the packet analysis system.
`
`All of these elements from the packets are formulated into a flow signature and
`
`stored in the unified flow key buffer of the packet analysis system. This buffer is
`
`designed to maintain and hold multiple flow signature is from the packets being analyzed
`
`30 (cid:9)
`
`in a client/server network. While the flow signature of a packet exists in the unified flow
`
`EX 1016 Page 14
`
`

`

`5 (cid:9)
`
`10 (cid:9)
`
`15 (cid:9)
`
`(cid:9) (cid:9)
`
`20 (cid:9)
`
`25
`
`10
`
`key buffer, several operations are performed to further derive the application content of
`
`the packet involved in the client/server conversation.
`
`The first step in the process of packet analysis is to look up the instance in the
`
`current database of known flow signature ease for packets. The look up/update engine
`
`accomplishes this task. This engine uses the hash key and remaining fields of the flow
`
`signature from the packet to determine if this packet is flow record exists in the flow
`
`database of the packet analysis system. Once the look up processing has been completed
`
`the flag stating whether it was found or is new, will be set within the unified flow key
`
`buffer structure for this packet flow signature.
`
`After the packet flow signature has been looked up and contents of the current
`
`flow signature database tree, the state processor will begin analyzing the packet payload
`
`to further derive the application component of this packet. The exact operation of the
`
`state processor and functions performed by at will very depending on the current packet
`
`seek once in the stream of a conversation. The state processor will performed the next
`
`logical operation that was stored from the previous packet seen with this same flow
`
`signature. If any processing is required on this packet, the state processor will execute
`
`state processor instructions from the state processor instruction database until they're
`
`either are no more left for this packet or the instruction signifies and processing for this
`
`packet.
`
`Since the seek once love packet exchanges between client and server is crucial in
`
`deriving the application component of a conversation, the state processor functions are
`
`required to be variable and program. Each new application that exists on the network
`
`may have different characteristics for identifying the components within packets. The
`
`state processor functions take into consideration this variable method of communicating
`
`in a client/server network. The actual operations performed by the state processor are
`
`described in the section under state processor instruction database operations.
`
`If during the look up process for this particular packet flow signature, the flow is
`
`required to be inserted into the active database, the flow insertion and deletion engine is
`
`initiated. This engine operates independently from the other two engines within the
`
`30 (cid:9)
`
`analysis system. The look up update engine will determine whether the flow insertion
`
`and deletion engine is required to operate for particular packet flow signature.
`
`EX 1016 Page 15
`
`

`

`BRIEF DESCRIPTION OF THE DRAWINGS
`
`11
`
`The present invention is more fully understood from the detailed preferred
`
`embodiments of the present invention, and should not be taken to limit the present
`
`invention to any specific embodiment because such are provided only for explanation
`
`5 (cid:9)
`
`and better understanding. The embodiments, in turn, are explained with the aid of the
`
`following figures.
`
`Fig. 1 is a functio