`
`
`THIS IS TO CERTIFY THAT ANNEXED IS A TRUE COPY FROM THE
`RECORDS OF THIS OFFICE OF THE FILE WRAPPER AND CONTENTS
`OF:
`
`APPLICATION NUMBER: 09/609,179
`
`FILING DATE: June 30, 2000
`
`PATENT NUMBER: 6,665, 725
`ISSUE DATE: December 16, 2003
`
`32‘: '
`; 6;
`g5;
`
`.:
`
`6:,
`‘;
`
`'flQJMfiBMWWQMJ“ME31!; 2%.;145,19ngwW3
`
`UNITED STATES DEPARTMENT OF COMMERCE
`
`x ‘3 :
`,0 ;
`
`355
`.;
`5
`é‘fi
`'3 r .
`.
`g
`34‘;
`1‘ ti
`
`it a?
`£13.;
`z: A}
`6:0
`£9325
`‘
`.
`z. 2.,
`:g A;
`fig”;
`; M’s:
`
`‘
`By Authorlty of the
`Under Secretary of Commerce for Intellectual Property
`.
`and Director of the Unlted States Patent and Trademark Office
`
`‘
`
`P. SWAI
`-
`' Off
`CertIfy g
`Icer
`
`‘ l f;
`19$:
`
`:an
`f1 .
`~§
`‘
`
`
`
`.
`
`5
`.I
`
`'2
`‘:2
`4' ‘:i
`.5
`3?wa
`M *0
`‘3} \‘3
`:.
`'
`:
`
`.. Wag,2,.
`
`‘1
`a
`(“AQKV'
`
`nf
`
`PART (I) OF (‘2) PART(S)
`
`.rH. k.
`,o
`..
`9“
`
`NOAC EX. 1016 Page 1
`”‘2'
`*
`“I
`‘fig; fif/Ié1:3;
`
`.‘
`
`f»x
`
`NOAC Ex. 1016 Page 1
`
`
`
`
`.
`
`
`
`PATENT‘NUMBER, .
`,
`.
`-_TI,.__W_..
`V
`>
`
`
`366.57%" {,1 '5
`‘
`
`
`
`
`I VIIIIIIIIIIIIIIIIIIII‘I“
`.
`
`
`APPLICANTS ’”EL;
`
`
`
`
`
`
`
`
`
`(
`NOAC Ex.10163age2 M5 ,,
`w- . .
`L 4
`‘.......~.‘ __._.,.
`L.
`L
`-
`\A
`
`
`(FACE)
`
`If;
`
`:
`
`3‘
`
`;'
`’5':
`
`.x‘...’~x«
`
`-J,L.
`
`‘
`
`7
`
`WWW"
`
` ISSUE
`CLASSIFICATION
`
`66553} .
`
`‘
`
`J
`
`4
`
`
`
`.'
`
`”M
`i
`APPLICATION NO.
`09/609179
`
`EXAMINER ‘
`ON
`D
`'5
`[‘1 ”w ‘
`. r': I"
`
`r
`
`
`
`
`
`
`
`«Cm-9Almfl'A-yvu'-—p '
`
`4.535;
`
`2:5 5‘
`
`~
`
`‘15 CertifiCd‘l’efigjfiI
`.JUNV2 9 211m
`4‘”
`
`9.. OQ50:: o5’
`
`
`
`A
`{N‘G‘éLVASSiFICATION
`
`9‘7
`, cnoss REFERENCHSL .
`
`H
`
`5
`
`L;
`
`} I,;SUBCLASS (ONE suacmss PEHI‘BLOC
`
`,
`
`Q” "f““ss
`
`
`' VINTERNAiIPNEE-gfiflfiégi‘iéfihfli
`
`
`
`.N;“W,.--.__.-
`
`,.
`
`»
`
`(
`:.,
`'.~‘
`.5
`
`:4.—
`_
`L,
`.
`
`;-
`. w
`:
`~
`
`~
`
`,
`
`»
`
`..
`
`'5magmammmm.“:51.
`>
`‘
`j:
`"l‘fi‘bfiiéWlNGS-é‘
`3 .5 T”?
`‘ _
`‘
`<
`U
`“ .
`I,
`y
`.:<,
`‘
`
`..
`
`v
`
`L
`
`.
`
`»
`
`.N.»
`
`,D Tfiétqtrriof.
`sukyse‘quéntto r‘ a
`’ hah'beén‘dlsqlalffiéflflj
`
`‘
`
`A
`
`ll
`
`'1’,
`
`, ‘33,
`
`h
`
`5
`
`~
`
`'
`
`‘
`
`,
`
`I
`
`‘
`
`<
`
`"
`
`I
`
`~
`
`_
`
`PfintClaimforO.G‘.
`\
`‘
`>
`i
`
`4,
`
`I.
`
`I
`
`i“
`
`7'
`H
`
`5:
`T“
`
`5
`
`5
`:y
`
`J
`'D The igm.offlyl§ gétéfit’éfiuallv‘f"
`‘
`A
`' ’29 ,,
`{not e'xtend béypnfif1h? explratiori date,
`HOSAINIALAM
`3
`atq.§Patent.Nq.
`‘
`.
`-~
`.
`‘
`:5
`I”:
`|
`;
`Amount‘D‘Eie ,
`5
`" PB’MARY EXAMWER
`A
`"
`3'
`”f.
`‘gfl .w-
`I
`5
`5
`'
`may..-
`‘ «6/51"! 0?, #3062?»
`:9"
`I r W I
`« (Primary Eumlnafl‘
`,
`)‘r,
`.
`
`‘
`
`Date Paid
`:55;
`q ,5“;
`‘ ’
`_
`.
`
`. months Cf
`D The termlna!
`L
`thls patent Have been dlsclaimed.
`
`' «\
`
`MW
`(Lana! Ins msnis Examlner)
`
`WARNING:
`The Informafion disclosed hereln may be resumed. Unamhorized dlsclosure may be prohiblted by The United States Code Title 35. Sections 122. 181 and 368.
`Possession outside (he U.S. Patent a Trademark Officer restricted (o authorized employees and comradors only.
`Fm" "“3“
`FILED WITH: D DISK (CRF) |:| FICHE |:| CD~ROM
`(Anachad In pocket on right lnulde flap)
`E FEE IN F\LE
`HHMM. “muss
`
`.
`
`'
`
`‘2;
`I
`
`IIJ ‘
`
`\
`|
`
`NOAC Ex. 1016 Page 2
`
`
`
`Page 1 O
`
`
`COMMISSIONER FOR PATENTS
`UNITED STATES PATENT AND TRADEMARK OFFICE
`WASHINGTON. D.C. ZOZSI
`
`‘1
`
`www.mpto gov
`
`Bib Data Sheet
`
`6
`GROUP ART UNIT
`2755—-
`
`, ATTORNEY
`DOCKET NO.
`APPT-001-2
`
`SERIAL NUMBER
`09/ 09 179
`6
`'
`A PPLICANTS
`
`FILING DATE
`06/30/2000
`RULE
`_
`
`2'
`Russell 8. Dietz, San Jose, CA;
`Andrew A. Koppenhaver, Littleton, CO ;
`James F. Torgerson, Andover, MN ;
`
`* CONTINUING DATA ****i***i*i**ii******i***
`
`THIS APPLN CLAIMS BENEFIT OF 60/141,903 06/30/1999
`WWII/£9
`Id: FOREIGN APPLICATIONS iiiski‘iiiskihkiiiiiiaki
`Mm! 100
`IF REQUIRED, FOREIGN FILING LICENSE
`GRANTED ** 08/23/2000
`
`Me‘afte‘
`
`-
`
`Initials
`
`SHEETS
`STATE OR
`COUNTRY DRAWING
`CA
`20
`
`TOTAL
`CLAIMS
`18
`
`INDEPENDENT
`CLAIMS
`1
`
`
`
`no
`D yes
`ForeIgn Priority claimed
`M D
`35 USC119(a-d) conditions D as
`"0
`II
`met
`y
`A OWQICIQ
`
`Examiner‘s
`
`in nature
`
`p
`
`CI AII Fees
`
`D 116 Fees ( Filing )
`
`.
`
`CI 1.17 Fees ( Processing Ext. of
`time)
`D 118 Fees( Issue
`CI Other
`
`a
`
`to charge/credit DEPOSIT ACCOUNT
`for followmg:
`
`CI Credit
`
`
`file://C :\APPS\PreExam\correspondence\1_A.xml
`
`1 1/7/00
`
`NOAC EX. 1016 Page 3
`
`NOAC Ex. 1016 Page 3
`
`
`
`\
`
`
`
`IWOld'S'n{7119311,
`WWWWWWI
`
`UU/Ut/9U,
`
`Mi
`
`
`
`
`{‘3
`h
`IN THE US. PATENT AND TRADEMARK OFFICE
`Application Transmittal Sheet
`
`Our Ref./Docket No.: APPT-OOl-Z
`
`Box Patent Application
`ASSISTANT COMMISSIONER FOR PATENTS
`Washington, DC. 20231
`
`Dear Assistant Commissioner:
`.
`.
`.
`Transrmtted herewrth IS the patent application of
`
`Last Name
`
`First Name, MI
`
`Residence (City and State or Country)
`
`INVENTOR(s)/APPLICANT(S)
`
`Dietz
`Torgerson
`Koppenhaver
`
`Russell S.
`James F.
`Andrew A.
`
`San Jose, CA
`Andover, MN
`Fairfax, VA
`
`8 §
`“'0‘ E
`01:: :0
`°‘ ES
`3% ES;
`$o¥§\
`8O :3
`n g
`
`TITLE OF THE INVENTION
`
`PROCESSING PROTOCOL SPECIFIC INFORMATION IN PACKETS SPECIFIED BY A PROTOCOL
`DESCRIPTION LANGUAGE
`
`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 a l )i
`
`Included are:
`
`X
`
`129
`sheet(s) of specification, claims, and abstract
`20
`sheet(s) of formal Drawing(s) with a submission letter to the Official Draftsperson
`Information Disclosure Statement.
`
`NIHHW
`
`Form PTO-1449: INFORMATION DISCLOSURE CITATION IN ANAPPLICATION, together with a
`copy of each references included in PTO—1449.
`Declarationand 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.
`Return postcard.
`This application has:
`a small entity status. A verified statement:
`is enclosed
`
`was already filed.
`
`The fee has been calculated as shown in the following page.
`
`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:W in an envelope addressed to Box Patent
`Application, Assistant Commissioner for Patents, Washington, DC. 20231 on.
`
`
`
`
`Date:
`
`C9
`
`‘
`
`:
`
`
`SiNam.
`
`
`Name: Dov Rosenfeld, Reg. No. 38687
`
`NOAC Ex. 1016 Page 4
`
`
`
`SUBMISSION DOCUMENT
`ATTORNEY DOCKET NO. APPT-OOl-Z
`
`Page 2
`
`TOTAL CLAIMS
`
`NO. OF EXTRA
`CIAIMS
`
`TOTAL
`CLAIMS
`
`INDEP.
`CLAIMS
`
`18
`
`1
`
`
`
`
`
`
`
`RATE
`
`$18
`
`$78
`
`
`
`EXTRA CLAIM
`FEE
`
`$ 0.00
`
`$ 0.00
`
`$ 690.00
`
`
`
`
`
`
`
`BASIC APPLICATION FEE:
`
`TOTAL FEES PAYABLE:
`
`$ 690.00
`
`
`METHOD OF PAYMENT
`
`is attached for application fee and presentation of claims.
`A check in the amount of
`A check in the amount of § 40.00 is attached for recordation of the Assignment.
`The Commissioner 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 Submitted,
`
`
`
`
`osenfeld , Reg. No. 38687
`
`
`
`m3029619
`ate
`
`Correspondence Address:
`Dov Rosenfeld
`
`5507 College Avenue, Suite 2
`Oakland, California, 94618
`Telephone: (510) 547-3378; Fax: (510) 653-7992
`
`
`
`
`
`
`
`NOAC EX. 1016 Page 5
`
`NOAC Ex. 1016 Page 5
`
`
`
`0
`
`L
`
`C
`
`Our Ref/Docket No: APPT-001 -2
`
`Patent
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`Applicant(s): Dietz, 3’ al.
`Group Art Unit: unassigned
`
`Title: PROCESSING PROTOCOL SPECIFIC
`
`INFORMATION IN PACKETS SPECIFIED
`
`BY A PROTOCOL DESCRIPTION
`
`Examiner: unassigned
`
`
`
`
`
`
`LANGUAGE
`
`
`
`ii::'m1!...“Cal1122!!M
`
`
`
`11353::£55,.
`
`IIIMII
`
`LETTER TO OFFICIAL DRAFTSPERSON
`
`. SUBMISSION OF FORMAL DRAWINGS
`
`The Assistant Commissioner for Patents
`
`Washington, DC 20231
`ATTN: Official Draftsperson
`
`Dear Sir or Madam:
`
`Attached please find 20 sheets of formal drawings to be made of record for the above
`identified patent application submitted herewith.
`
`. Respectfully Submitted,
`
`W 29 X9979 gfi‘
`
`osenfeld, Reg. No. 38687
`
`Date
`
`Address for correspondence and attorney for applicant(s):
`Dov Rosenfeld, Reg. No. 38,687
`5507 College Avenue, Suite 2
`Oakland, CA 94618
`Telephone: (510) 547-3378; Fax: (510) 653—7992
`
`Certificate of Mailing under 37 CFR 1.10
`
`Name: Dov Rosenfeld, Reg. No. 38687
`
`I hereby certify that this application and all attachments are being deposited with the United States Postal
`Service as Express Mail (Express Mail Label:W in an envelope addressed to Box Patent
`Application, Assistant Commissioner for Patents, Washington, DC. 20231 on.
`I
`1‘33.
`
`NOAC Ex. 1016 Page 6
`
`
`
`D
`
`O
`
`Our Ref./Docket No.: APPT—001-2
`
`PROCESSING PROTOCOL SPECIFIC INFORMATION IN PACKETS SPECIFIED
`
`BY A PROTOCOL DESCRIPTION LANGUAGE
`
`
`
`IIIIII!III]:121!Min:II...II
`
`
`
`
`
`II
`
`
`
`"3:2;.:s!;
`
`
`‘ISEEI!III!
`-IIII"I!III“?2!:
`
`Inventor(s):
`
`DIETZ, Russell S.
`San Jose, CA
`
`KOPPENHAVER, Andrew A.
`Fairfax, VA
`
`TORGERSON, James F.
`
`Andover, MN
`
`
`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: EI417961935US in an envelope addressed to Box Patent Application, Assistant Commissioner for Patents,
`
`Washington,
`.C. 20231 on.
`
`
`
`
`
`
`
`/
`
`
`
`Na
`
`.
`
`ov Rosenfeld,Reg. No. 38687
`
`NOAC Ex. 1016 Page 7
`
`
`
`0
`
`m\
`
`1
`
`METHOD AND APPARATUS FOR MONITORING
`
`TRAFFIC IN A NETWORK
`
`CROSS-REFERENCE TO RELATED APPLICATION
`
`This application claims the benefit of US. 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 US. 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. {151 /603.Z'71Ior METHOD AND APPARATUS FOR
`MONITORING TRAFFIC IN ANETWORK, to inventors Dietz, et al., filed June 30,
`
`Mi"?
`QWU
`
`2000, Attorney/Agent Reference Number APPT-OOl-l, and incorporated herein by
`
`reference.
`
`15
`
`US P
`.
`.
`
`atent
`
`A l.
`I
`S ‘alN
`pp 1cat10n en
`
`0.
`
`DATA TRANSACTIONS FOR MAINTAINING STATISTICS IN NETWORK
`
`q/COK f REUSINGINFORMATIONFROM bu”
`I
`9
`i or
`-
`1
`,, ’2
`I
`1',
`”I V! U 2
`7"
`/
`
`MONITORING, to inventors Dietz, et al., filed June 30, 2000, Attorney/Agent
`
`Reference Number APPT-001—3, and incorporated herein by reference.
`_
`.
`US. Patent Application Serial No. fifl /@[212'(wfor ASSOCIATIVE CACHE
`STRUCTURE FOR LOOKUPS AND UPDATES OF FLOW RECORDS IN A
`
`20
`
`I
`W/
`(53/ (”fl/J3
`
`NETWORK MONITOR, to inventors Sarkissian, et al., filed June 30, 2000,
`
`Attorney/Agent Reference Number APPT-001—4, and incorporated herein by reference.
`
`gI-I'n.l"uu-ws‘gl"I;'33-'4315-35‘31le
`
`
`
`
`
`z:-
`
`:=.=
`3
`
`US. Patent Application Serial No.
`
`PATTERN MATCHING IN A NETWORK MONITOR DEVICE, to inventors
`
`- .
`
`/.. “I l J for STATE PROCESSOR FOR
`
`r
`
`'r‘ 7
`
`7dg‘1/1J
`
`i)
`
`L
`
`25
`
`Sarkissian, et al., filed June 30, 2000, Attorney/Agent Reference Number APPT-001—5,
`
`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.
`
`NOAC EX. 1016 Page 8
`
`NOAC Ex. 1016 Page 8
`
`
`
`(W
`
`(W
`
`
`
`
`
`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
`
`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 Internet and other
`
`interconnected networks. In particular, there is a need for a real-time network monitor 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
`
`information passing through any point on the network (i. e., of all packets and packet
`
`streams passing through any location in the network). Not only should all the packets be
`
`detected and analyzed, but for each of these packets the network monitor should
`
`determine the protocol (e. g., http, ftp, H.323, VPN, etc.), the application/use within the
`
`protocol (e. g., voice, video, data, real-time data, etc.), and an end user’s pattern of use
`
`within each application or the application context (e. g., options selected, service
`
`delivered, duration, time of day, data requested, etc.). Also, the network monitor should
`
`not be reliant upon server resident information such as log files. Rather, it should allow a
`
`user such as a network administrator or an Internet 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.
`
`The recognizing and classifying in such a network monitor should be at all
`
`protocol layer levels in conversational flows that pass in either direction at a point in a
`
`network. Furthermore, the monitor should provide for properly analyzing each of the
`
`packets exchanged between a client and a server, maintaining information relevant to the
`
`current state of each of these conversational flows.
`
`Related and incorporated by reference U.S. Patent application 063 “;C’E' m for
`
`METHOD AND APPARATUS FOR MONITORING TRAFFIC INA NETWORK, to
`
`10
`
`15
`
`20
`
`25
`
`30
`
`NOAC EX. 1016 Page 9
`
`NOAC Ex. 1016 Page 9
`
`
`
`‘u-HH31.lll'
`“"1:x;l-‘
`
`
`
`(V
`
`C)
`
`3
`
`inventors Dietz, et a1, Attorney/Agent Docket APPT-OOl-l, 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 patterns 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.
`
`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
`
`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.
`
`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.
`
`A network analyzer should be able to analyze many different protocols. At a base
`
`level, there are a number of standards used in digital telecommunications, including
`
`Ethernet, HDLC, ISDN, Lap B, ATM, X.25, Frame Relay, Digital Data Service, FDDI
`
`(Fiber Distributed Data Interface), T1, and others. Many of these standards employ
`
`different packet and/or frame formats. For example, data is transmitted in ATM and
`
`frame—relay systems in the form of fixed length packets (called “cells”) that are 5 3 octets
`
`(i.e., bytes) long. Several such cells may be needed to make up the information that might
`
`be included in the packet employed by some other protocol for the same payload
`
`NOAC EX. 1016 Page 10
`
`10
`
`15
`
`20
`
`25
`
`30
`
`NOAC Ex. 1016 Page 10
`
`
`
`
`
`
`
`C‘»
`
`C\,
`
`4
`
`information—for example in a conversational flow that uses the frame-relay standard or
`
`the Ethernet protocol.
`
`In order for a network monitor to be able to analyze different packet or frame
`
`formats, the monitor needs to be able to perform protocol specific operations on each
`
`packet with each packet carrying information conforming to different protocols and
`
`related to different applications. For example, the monitor needs to be able to parse
`
`packets of different formats into fields to understand the data encapsulated in the different
`
`fields. As the number of possible packet formats or types increases, the amount of logic
`
`required to parse these different packet formats also increases.
`
`10
`
`Prior art network monitors exist that parse individual packets and look for
`
`information at different fields to use for building a signature for identifying packets. 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.” In this patent, there are fixed locations specified for particular types of
`
`15
`
`packets. For example, if a DECnet packet appears, the Chiu system 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 locations are examined. The system
`
`looks only at the lowest levels up to the protocol layer. There are fixed locations for each
`
`of the fields that specified the next level. With the proliferation of protocols, clearly the
`
`specifying of all the possible places to look to determine the session becomes more and
`
`more difficult. Likewise, adding a new protocol or application is difficult.
`
`It is desirable to be able to adaptively determine the locations and the information
`
`extracted from any packet for the particular type of packet. In this way, an optimal
`
`signature may be defined using a protocol-dependent and packet-content-dependent
`
`definition of what to look for and where to look for it in order to form a signature.
`
`20
`
`25
`
`There thus is also a need for a network monitor that can be tailored or adapted for
`
`different protocols and for different application programs. There thus is also a need for a
`
`network monitor that can accommodate new protocols and for new application programs.
`
`30
`
`There also is a need for means for specifying new protocols and new levels, including
`
`new applications. There also is a need for a mechanism to describe protocol specific
`
`operations, including, for example, what information is relevant to packets and packets
`
`NOAC EX. 1016 Page 11
`
`NOAC Ex. 1016 Page 11
`
`
`
`m
`
`A'x
`
`5
`
`that need to be decoded, and to include specifying parsing operations and extraction
`
`operations. There also is a need for a mechanism to describe state operations to perform
`
`on packets that are at a particular state of recognition of a flow in order to further
`
`recognize the flow.
`
`SUMMARY
`
`One embodiment of the invention is a method of performing protocol specific operations
`
`on a packet passing through a connection point on a computer network. The packet
`
`contents conform to protocols of a layered model wherein the protocol at a particular
`
`10
`
`15
`
`20
`
`layer level may include one or a set of child protocols defined for that level. The method
`
`includes receiving the packet and receiving a set of protocol descriptions for protocols
`
`may be used in the packet. A protocol description for a particular protocol at a particular
`
`layer level includes any child protocols of the particular protocol, and for any child
`
`protocol, where in the packet information related to the particular child protocol may be
`
`found. A protocol description also includes any protocol specific operations to be
`
`performed on the packet for the particular protocol at the particular layer level. The
`
`method includes performing the protocol specific operations on the packet specified by
`
`the set of protocol descriptions based on the base protocol of the packet and the children
`
`of the protocols used in the packet. A particular embodiment includes providing the
`
`protocol descriptions in a high-level protocol description language, and compiling to the
`
`descriptions into a data structure. The compiling may further include compressing the
`
`data structure into a compressed data structure. The protocol specific operations may
`
`include parsing and extraction operations to extract identifying information. The protocol
`
`specific operations may also include state processing operations defined for a particular
`
`state of a conversational flow of the packet.
`
`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 turn, are explained with the aid of the following
`
`30
`
`figures.
`
`
`
`~ NOAC EX. 1016 Page 12
`
`NOAC Ex. 1016 Page 12
`
`
`
`
`
`
`
`iii"”23:“1!...1'21:1!1m2m!
`
`mm.413.
`
`=25
`:L
`
`
`
`1‘!”i‘
`
`(I
`
`(I
`
`6
`
`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
`
`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
`
`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
`
`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.
`
`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
`
`the pattern recognizer and extractor that can form part of the parser module in an
`
`embodiment of the inventive packet monitor.
`
`10
`
`15
`
`20
`
`25
`
`NOAC EX. 1016 Page 13
`
`NOAC Ex. 1016 Page 13
`
`
`
`m
`
`m
`
`7
`
`FIG. 11 is a functional block diagram of a hardware analyzer including a state
`
`processor that can form part of an embodiment of the inventive packet monitor.
`
`FIG. 12 is a functional block diagram of a flow insertion and deletion engine
`
`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.
`
`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
`
`10
`
`may be implemented in software.
`
`FIG. 15 is a functional block diagram of how the packet monitor of FIG. 3 (and
`
`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 Ethernet packet and some of
`
`the elements that may be extracted to form a signature according to one aspect of the
`
`
`
`1:33;“1:22.12:um12.111311!11351:it‘ll.
`
`
`
`
`
`15
`
`invention.
`
`
`
`risers23}:
`
`
`
`
`
`if]!11.73%1131*3153.:
`
`FIG. 17A is an example of the header of an Ethertype type of Ethernet packet of
`
`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 IP 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.
`
`FIG. 18A is a three dimensional structure that can be used to store elements of the
`
`pattern, parse and extraction database used by the parser subsystem in accordance to one
`
`embodiment of the invention.
`
`FIG. 18B is an alternate form of storing elements of the pattern, parse and
`
`extraction database used by the parser subsystem in accordance to another embodiment of
`
`the invention.
`
`20
`
`25
`
`~ NOAC EX. 1016 Page 14
`
`NOAC Ex. 1016 Page 14
`
`
`
`
`
`II-IIIIIIIII...|I'I
`
`1133:?.131,
`
`III]!
`
`
`
`(3.
`
`fl
`
`8
`
`FIG. 19 shows various PDL file modules to be compiled together by the compiling
`
`process illustrated in FIG. 20 as an example, in accordance with a compiling aspect of the
`
`invention.
`
`FIG. 20 is a flowchart of the process of compiling high—level language files
`
`according to an aspect 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
`
`10
`
`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 102
`
`that communicates packets (e. g., IP datagrams) between various computers, for example
`
`15
`
`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 examining packets
`
`(i. e., datagrams) between the network interface 116 of the server 110 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 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
`
`required communication, e. g., TCP/IP, etc. Any network activity—for 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
`
`20
`
`25
`
`30
`
`NOAC EX. 1016 Page 15
`
`NOAC Ex. 1016 Page 15
`
`
`
`M‘Efill“th5!“‘1
`:55.I!)"r:
`
`’33]!
`
`
`
`:23?!917.3?
`
`
`
`@535!If)!3.1th33:;‘3
`
`(V
`
`C)
`
`9
`
`network protocols. Such characteristics may not be completely revealing at the 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.
`
`Communication protocols are layered, which is also referred to as a protocol stack.
`
`The ISO (International Standardization Organization) has defined a general model that
`
`provides a framework for design of communication protocol layers. This model, shown in
`
`10
`
`table form below, serves as a basic reference for understanding the functionality of
`
`existing communication protocols.
`
`ISO MODEL
`
`Application
`
`Telnet, NFS, Novell NCP, HTTP,
`
`
`
`H.323
`
`
`
`
`
`
`n—_
`
`
`
`
`
`
`
`
`
`
`Data Link
`
`
`
`Network Interface Card (Hardware
`
`Interface). MAC layer
`
`Physical
`
`Ethernet, Token Ring, Frame Relay,
`
`ATM, T1 (Hardware Connection)
`
`Different communication 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
`
`15
`
`model. A protocol in a certain layer may not be visible to protocols employed at other
`
`layers. For example, an application (Level 7) may not be able to identify the source
`
`computer for a communication attempt (Levels 2—3).
`
`NOAC EX. 1016 Page 16
`
`NOAC Ex. 1016 Page 16
`
`
`
`m
`
`a
`
`10
`
`In some communication 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
`
`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
`
`format 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 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 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
`
`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.
`
`10
`
`15
`
`It:
`
`
`
`
`
` llu":23:ii...“"mun1!.
`
` 20
`
`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
`
`25
`
`30
`
`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
`
`signature of extracted characteristic portions of the packet that can be used to rapidly
`
`identify packets belonging to the same flow.
`
`NOAC Ex. 1016 Page 17
`
`NOAC Ex. 1016 Page 17
`
`
`
`in:Ii...“'3::u113:“it...”
`
`
`
`”1:31.53.;ll-
`
`
`
`
`
`
`
`iifji!iii?!13