Our Ref./Docket No: APPT-001-4
`
`Patent
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Applicant(s): Sarkissian, et al.
`Application No.: 09/608266
`Filed: June 30, 2000
`Title: ASSOCIA TNE CACHE STRUCTURE FOR
`LOOKUPS AND UPDATES OF FLOW
`RECORDS IN A NE1WORK MONITOR
`
`Group Art Unit: 2662
`Examiner: Alan Nguyen
`
`RESPONSE TO OFFICE ACTION UNDER 37 CFR 1.111
`
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`Dear Commissioner:
`This is a response to the Office Action of September 10, 2003.
`Any amendments to the specification begin on a new page immediately after these
`introductory remarks.
`Any amendments to the claims begin on a new page immediately after such amendments
`to the specification, if any.
`Any amendments to the drawings begin on a new page immediately after such
`amendments to the claims, if any.
`The Remarks/arguments begin on a new page immediately after such amendments to the
`drawings, if any.
`If there are drawing amendments, an Appendix including amended drawings is attached
`following the Remarks/arguments.
`
`Certificate or Facsimile Transmimon under 37 CFR 1.8
`
`I hereby certify that this correspondence is being deposited with the United States Postal Service as first class
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`mail in an envelope addressed to Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on.
`
`Date f,-8-, trQ7 ::?,.t90 '/
`
`· s;gne,1, � >
`
`Name: Dov�.
`
`No. 38687
`
`EX 1020 Page 1
`
`Pl 0027961
`
`PCKTI NT-00023634
`
`Packet Intelligence Ex. 2003 Page 1 of 12
`
`

`

`SIN: 09/608266
`
`Page2
`
`
`
`AMENDMENT(S) TO THE CLAIMS:
`
`The following listing of claims will replace all prior versions, and listings, of claims on the
`application. All claims are set forth below with one of the following annotations.
`•
`(Original): Claim filed with the application.
`•
`(Currently amended): Claim being amended in the current amendment paper.
`•
`(Canceled): Claim cancelled or deleted from the application. No claim text is
`shown.
`•
`(Withdrawn): Claim still in the application, but in a non-elected status.
`•
`(New): Claim being added in the current amendment paper.
`•
`(Previously presented): Claim added or amended in an earlier amendment paper.
`•
`(Not entered): Claim presented in a previous amendment, but not entered or whose
`entry status unknown. No claim text is shown.
`(Currently amended) A packet monitor for examining packets passing through a
`connection point on a computer network, each packets conforming to one or more
`protocols, the monitor comprising:
`(a)
`a packet acquisition device coupled to the connection point and configured
`to receive packets passing through the connection point;
`(b)
`a memory for storing a database comprising aane er mere flow-entries for
`previously encountered conversational flows to which a received packet may
`belong, a conversational flow being an exchange of one or more packets in any
`direction as a result of an activity corresponding to the flow;
`a cache subsystem coupled to the flow-entry database memory providing for
`fast access of flow-entries from the flow-entry database; anEl
`a lookup engine coupled to the packet acquisition device and to the cache
`subsystem and configured to lookup whether a received packet belongs to a
`flow-entry in the flow-entry database, the looking up being in-the cache
`subsystem; and
`a state processor coupled to the lookup engine and to the flow-entry-
`database memory, the state processor being to perform any state operations
`specified for the state of the flow starting from the last encountered state of the
`flow in the case that the packet is from an existing flow, and to perform any
`state operations reguired for the initial state of the new flow in the case that the
`packet is from an existing flow.
`
`1.
`
`(c)
`( d)
`
`{e}
`
`EX 1020 Page 2
`
`PI_0027962
`PCKTI NT-00023635
`
`Packet Intelligence Ex. 2003 Page 2 of 12
`
`

`

`SIN: 09/608266
`
`Page 3
`
`
`
`comprising: to claim 1, further according 2. (Previously presented) A packet monitor
`
`
`
`
`
`
`
`
`
`
`
`a parser subsystem coupled to the packet acquisition device and to the
`
`
`
`
`
`
`lookup
`
`
`
`
`
`engine such that the acquisition device is coupled to the lookup engine
`
`
`
`
`
`
`via the parser subsystem, the parser subsystem configured to extract identifying
`
`
`information from a received packet,
`
`wherein each flow-entry is identified by identifying information stored in the flow­
`
`
`
`
`
`
`
`
`
`
`entry, and wherein the cache lookup uses a function of the extracted identifying
`information.
`
`wherein the cache to claim 2, monitor according 3. (Previously presented) A packet
`
`
`
`
`
`
`
`
`
`
`subsystem is an associative cache subsystem including one or more content
`
`
`addressable memory cells (CAMs).
`
`
`
`the cache wherein to claim 2, according 4. (Previously presented) A packet monitor
`
`
`
`
`
`
`
`
`
`
`subsystem includes:
`
`(i) a set of cache memory elements coupled to the flow-entry database memory,
`
`
`
`
`
`each cache memory element including an input port to input an flow-entry and
`
`
`
`
`configured to store a flow-entry of the flow-entry database;
`
`according to (CAMs) connected (ii) a set of content �ddressable memory cells
`
`
`
`
`
`
`
`
`an order of connections from a top CAM to a bottom CAM, each CAM
`
`
`
`
`containing an address and a pointer to one of the cache memory elements, and
`including:
`
`a matching circuit having an input such that the CAM asserts a
`
`
`
`
`
`
`match output when the input is the same as the address in the CAM
`
`
`
`
`cell, an asserted match output indicating a hit,
`
`
`
`
`
`
`
`
`
`a CAM input configured to accept an address and a pointer, and
`
`
`
`
`
`a CAM address output and a CAM pointer output;
`
`
`
`
`
`(iii) a CAM controller coupled to the CAM set; and
`
`(iv) a memory controller coupled to the CAM controller, to the cache memory
`
`
`
`
`set, and to the flow-entry memory,
`
`wherein the matching circuit inputs of the CAM cells are coupled to the lookup engine
`
`
`
`
`
`
`
`
`
`
`
`
`such that that an input to the matching circuit inputs produces a match output in any
`
`
`
`CAM cell that contains an address equal to the input, and
`
`wherein the CAM controller is configured such that which cache memory element a
`
`
`
`
`
`
`
`particular CAM points to changes over time.
`
`the CAM to claim 4, wherein monitor according 5. (Previously presented) A packet
`
`
`
`
`
`
`
`
`
`
`
`
`controller is configured such that the bottom CAM points to the least recently used
`cache memory element.
`
`EX 1020 Page 3
`
`Pl_0027963
`PCKTI NT-00023636
`
`Packet Intelligence Ex. 2003 Page 3 of 12
`
`

`

`SIN: 09/608266
`
`Page4
`6. (Previously presented) A packet monitor according to claim 5, wherein the address
`and pointer output of each CAM starting from the top CAM is coupled to the address
`and pointer input of the next CAM, the final next CAM being the bottom CAM, and
`wherein the CAM controller is configured such than when there is a cache hit, the
`address and pointer contents of the CAM that produced the hit are put in the top CAM
`of the stack, the address and pointer contents of the CAMs above the CAM that
`produced the asserted match output are shifted down, such that the CAMs are ordered
`according to recentness of use, with the least recently used cache memory element
`pointed to by the bottom CAM and the most recently used cache memory element
`pointed to by the top CAM.
`7.-20. (Cancelled).
`21. (New) A packet monitor for examining packets passing through a connection point
`on a computer network, each packets conforming to one or more protocols, the
`monitor comprising:
`a packet acquisition device coupled to the connection point and configured
`to receive packets passing through the connection point;
`an input buffer memory coupled to and configured to accept a packet from
`the packet acquisition device;
`a parser subsystem coupled to the input buffer memory, the parsing
`subsystem configured to extract selected portions of the accepted packet and to
`output a parser record containing the selected portions;
`a memory to storing a database of one or more flow-entries for any
`previously encountered conversational flows, each flow-entry identified by
`identifying information stored in the flow-entry;
`a lookup engine coupled to the output of the parser subsystem and to the
`flow-entry memory and configured to lookup whether the particular packet
`whose parser record is output by the parser subsystem has a matching flow­
`entry, the looking up using at least some of the selected packet portions and
`determining if the packet is of an existing flow
`a cache subsystem coupled to and between the lookup engine and the flow­
`entry database memory providing for fast access of a set of likely-to-be­
`accessed flow-entries from the flow-entry database; and
`a flow insertion engine coupled to the flow-entry memory and to the lookup
`engine and configured to create a flow-entry in the flow-entry database, the
`flow-entry including identifying information for future packets to be identified
`with the new flow-entry,
`the lookup engine configured such that if the packet is of an existing flow, the monitor
`classifies the packet as belonging to the found existing flow; and if the packet is of a
`new flow, the flow insertion engine stores a new flow-entry for the new flow in the
`
`EX 1020 Page 4
`
`PI_0027964
`PCKTI NT-00023637
`
`Packet Intelligence Ex. 2003 Page 4 of 12
`
`

`

`21.
`22.
`
`23.
`
`24.
`
`25.
`
`PageS
`SIN: 09/608266
`flow-entry database, including identifying information for future packets to be
`identified with the new flow-entry,
`wherein the operation of the parser subsystem depends on one or more of the protocols
`to which the packet conforms.
`(New) A monitor according to claim 20, wherein the lookup engine updates the
`flow-entry of an existing flow in the case that the lookup is successful.
`(New) A monitor according to claim 20, further including a mechanism for building
`a hash from the selected portions, wherein the hash is included in the input for a
`particular packet to the lookup engine, and wherein the hash is used by the lookup
`engine to search the flow-entry database.
`(New) A monitor according to claim 20, further including a memory containing a
`database of parsing/extraction operations, the parsing/extraction database memory
`coupled to the parser subsystem, wherein the parsing/extraction operations are
`according to one or more parsing/extraction operations looked up from the
`parsing/extraction database.
`(New) A monitor according to claim 33, wherein the database of parsing/extraction
`operations includes information describing how to determine a set of one or more
`protocol dependent extraction operations from data in the packet that indicate a
`protocol used in the packet.
`(New) A method according to claim 20, further including a state processor coupled
`to the lookup engine and to the flow-entry-database memory, and configured to
`perform any state operations specified for the state of the flow starting from the last
`encountered state of the flow in the case that the packet is from an existing flow, and
`to perform any state operations required for the initial state of the new flow in the case
`that the packet is from an existing flow.
`(New) A method according to claim 25, wherein the set of possible state operations
`that the state processor is configured to perform incJudes searching for one or more
`patterns in the packet portions.
`(New) A monitor according to claim 25, wherein the state processor is
`programmable, the monitor further including a state patterns/operations memory
`coupled to the state processor, the state operations memory configured to store a
`database of protocol dependent state patterns/operations.
`(New) A monitor according to claim 25, wherein the state operations include
`updating the flow-entry, including identifying information for future packets to be
`identified with the flow-entry.
`(New) A method of examining packets passing through a connection point on a
`computer network, each packets conforming to one or more protocols, the method
`comprising:
`
`26.
`27.
`
`28.
`29.
`
`EX 1020 Page 5
`
`P1_0027965
`PCKTI NT-00023638
`
`Packet Intelligence Ex. 2003 Page 5 of 12
`
`

`

`SIN: 09/608266
`
`Page6
`
`(a) receiving
`a packet from a packet
`acquisition
`device;
`
`(b) perfonning one or more parsing/extraction
`operations
`on the packet
`to
`create
`a parser record comprising
`a function
`of selected portions
`of the packet;
`
`( c) looking
`up a flow-entry database comprising
`none or more flow-entries
`for
`previously
`encountere
`d conversational
`flows, the looking
`up using at least
`some of the selected
`packet
`portions
`and detennining
`if the packet is of an
`existing
`flow, the lookup
`being via a cache;
`
`( d) if the packet
`is of an existing
`flow, classifying
`the packet
`as belonging
`to the
`found existing
`flow; and
`
`( e) if the packet
`is of a new flow, storing
`a new flow-entry
`for the new flow in
`the flow-entry database,
`including
`identifying
`information
`for future packets
`to
`be identified
`with the new flow-entry,
`
`wherein
`the parsing/extraction
`operations
`depend on one or more of the protocols
`to
`which the
`packet conforms.
`
`30. (New) A method
`according
`to claim 29, wherein classifying
`the packet
`as belonging
`to the found existing
`flow includes
`updating
`the flow-entry of the existing
`flow.
`
`31. (New) A method according
`to claim 29, wherein
`the function
`of the selected
`portions
`of the packet forms a signature
`that includes
`the selected
`packet
`portions
`and
`that can identify
`future packers,
`wherein
`the lookup operation
`uses the signature and
`wherein
`the identifying
`information
`stored in the new or updated flow-entry
`is a
`signature
`for identifying
`future packets.
`
`32. (New) A method
`according
`to claim 29, wherein
`the looking
`up of the flow-entry
`database
`uses a hash
`of the selected
`packet
`portions.
`
`33. (New) A method according
`to claim 29, wherein step (d) includes
`if the packet
`is of
`an existing
`flow, obtaining
`the last encountered
`state
`of the flow and perfonning any
`state operations specified
`for the state
`of the flow starting from the last encountered
`state
`of the flow; and wherein step ( e) includes
`if the packet is of a new flow,
`performing any state
`operations
`required
`for the initial
`state
`of the new flow.
`
`EX 1020 Page 6
`
`PI_0027966
`PCKTI NT-00023639
`
`Packet Intelligence Ex. 2003 Page 6 of 12
`
`

`

`SIN: 09/608266
`
`REMARKS
`
`Page7
`
`Status of the Application:
`
`Amendment to the Claims:
`
`Claims 1-20 are the claims of record of the application. Claims 1-20 have been rejected.
`Claims 7-20 have been cancelled without prejudice.
`Applicants have amended claim 1 to better define the invention by explicitly stating that
`the invention deals with conversational flows, not simply only source and destination
`addresses. Applicants have also amended claim 1 to add the state processor.
`Claims 21-33 have been added and are described in the specification and the drawings as
`follows.
`Claims 21 is shown, e.g., in FIG. 3, with the cache shown in FIG. 11, and described in the
`descriptions of these drawings. The method of claim 29 is carried out by the apparatus of
`FIG. 3, with the cache shown in FIG. 11, and described in the descriptions of these
`drawings.
`The hashing of claims 22 and 32 is shown in FIG. 7 and described in the description of the
`drawing.
`The parsing and extraction of claims 23 and 24 are shown in FIGS. 4 and 6, and described
`in the description of these drawings.
`The state processor of claims 1, 25-27 and 33 is shown in FIGS. 3 and 13.
`Because the added claims include elements argued in the argument below to not be
`included in the cited prior art, they are believed allowable.
`FIG. 3 shows the operation of one embodiment of the analyzer of the present invention.
`This is also described in more detail in related and incorporated by reference U.S. Patent
`application 09/608237 for METHOD AND APPARATUS FOR MONITORING TRAFFIC
`IN A NETWORK, to inventors Dietz, et al, Attorney/Agent Docket APPT-001-1.
`FIG. 3 describes a network monitor that includes carrying out protocol specific operations
`on every individual packet that passes through a connection point on a network. The
`operations include extracting information from header fields in the packet to use for
`building a signature for identifying the conversati.onal flow of the packet and for
`recognizing future packets as belonging to a previously encounteredflow. A parser
`subsystem includes a parser for recognizing different patterns in the packet that identify the
`protocols used. For each protocol recognized, an extractor extracts important packet
`elements from the packet. These form a signature (i.e., key) for the packet. The extractor
`
`
`
`Description of aspects of the present invention
`
`
`
`EX 1020 Page 7
`
`PI_0027967
`PCKTI NT-00023640
`
`Packet Intelligence Ex. 2003 Page 7 of 12
`
`

`

`SIN: 09/608266
`Page8
`also preferably generates a hash for rapidly identifying a flow that may have this signature
`from a database of known flows.
`The lookup is via a cache structure that in one embodiment is built of CAM structures.
`For each packet, the flow signature of each packet, the hash and at least some of the
`payload are passed to an analyzer subsystem.
`The analyzer subsystem receives parts of each packet from the parser subsystem, and, for
`each packet, looks up a database of flow records for previously encountered
`conversati.onal flows to determine whether a signature is from an existing flow. The
`present invention described the lookup mechanism in niore detail. In one aspect, the
`analyzer further identifies the state of the existing flow, and performs any state processing
`operations specified for the state. In the case of a newly encountered flow, the analyzer
`includes a flow insertion and deletion engine for inserting new flows into the database of
`flows. Any state operations that are specified for the new flow are also carried out.
`In paragraph 3 of the office action, claims 7-11, 19, and 20 rejected under 35 U.S.C. 102(b)
`as being anticipated by Chang (US 4,458,310). These claims have been cancelled.
`In paragraph 5 of the office action claims 12-18 rejected under 35 U.S.C. 103(a) as being
`unpatentable over Chang in view of Carter et al. (US 6,003,123). These claims have been
`cancelled.
`In paragraph 4 of the office action, Claims 1 and 2 rejected under 35 U.S.C. 102(e) as
`being anticipated by Gobuyan et al (US 5,917,821), herein Gobuyan.
`Gobuyan describes a look up engine arrangement for parsing packets in a packet-based data
`transmission network. The application is an Ethernet -to-ATM bridge-router (see col. 4,
`lines 21-23). Therefore, the Gobuyan device needs to look up each packet and route is
`appropriately.
`The lookup engine provides all the information needed to find the path to each known
`destination as well as a default information for unknown locations (see col. 4, lines 30-33).
`Claim 1 includes "a cache subsystem coupled to the flow-entry database memory providing
`for fast access of flow-entries from the flow-entry database." The examiner has filed to
`describe where Gobuyan includes this feature.
`Claim 1 as amended includes "a state processor coupled to the lookup engine and to the
`flow-entry-database memory, the state processor being to perform any state operations
`
`
`
`Claim Rejections -35 USC§ 102 and 35 USC§ 103
`
`
`
`Description of Gobuyan
`
`
`
`Gobuyan fails to include the cache subsystem
`
`
`
`Gobuyan fails to include the state processor
`
`EX 1020 Page 8
`
`Pl_0027968
`PCKTI NT-00023641
`
`Packet Intelligence Ex. 2003 Page 8 of 12
`
`

`

`SIN: 09/608266
`Page9
`specified for the state of the flow starting from the last encountered state of the flow in the
`case that the packet is from an existing flow, and to perform any state operations required
`for the initial state of the new flow in the case that the packet is from an existing flow."
`Gobuyan does not includes this feature.
`
`The present invention looks up whether or not a packet belongs to a
`
`
`
`
`previously encountered conversational flow; Gobuyan does not distinguish
`
`
`conversational flows, but rather gathers looks up each packet based only on
`
`
`
`addresses independent of whether or not it belongs to any conversational
`flow. ,.
`
`The present invention includes a process that recognizes a conversati.onal flow. Gobuyan
`does not recognize a conversational flow, but instead looks up only each packet's
`destination address and source address. A conversational flow is not identified simply by
`the stations that are involved in a communication, but rather by the nature of the
`communication, e.g., the application program being invoked. Thus, even for the same two
`stations, the present invention identifies different conversational flows between two
`stations and maintains a different entry for each different conversational flow in a database.
`It is important to be able to distinguish between packets that are exchanged between a
`source and a destination, and a conersational flow as used in the present invention. A
`conversational flow is the sequence of packets that are exchanged in any direction as a
`result of a particulcar activity-for instance, the running of an application on a server as
`requested by a client. Different conversati.onal flows may occur between the same two
`addresses. Each of these would have a separate entry in the flow database. Gobuyan,
`however, being concerned with routing and bridging, cannot distinguish between different
`conversational flows. For example, two packets having the same source and destination
`addresses would be treated the same by Gobuyan. Unlike Gobuyan, the present inventi.on
`is able to identi.fy and classify conversati.onal flows rather than only connecti.on flows.
`The reason for this is that some conversational flows involve more than one connection,
`and some even involve more than one exchange of packets between a client and server.
`Thus, there may be different states to a flow. This is particularly true when using
`client/server protocols such as RPC, DCOMP, and SAP, which enable a service to be set
`up or defined prior to any use of that service.
`An example of such a case is the SAP (Service Advertising Protocol), a NetWare (Novell
`Systems, Provo, Utah) protocol used to identify the services and addresses of servers
`attached to a network. In the initial exchange, a client might send a SAP request to a server
`for print service. The server would then send a SAP reply that identifies a particular
`address-for example, SAP#>-'-as the print service on that server. Such responses might
`be used to update a table in a router, for instance, known as a Server Information Table. A
`client who has inadvertently seen this reply or who has access to the table (via the router
`that has the Service Information Table) would know that SAP#5 for this particular server is
`a print service. Therefore, in order to print data on the server, such a client would not need
`to make a request for a print service, but would simply send data to be printed specifying
`SAP#5. Like the previous exchange, the transmission of data to be printed also involves an
`
`EX 1020 Page 9
`
`P1_0027969
`PCKTI NT-00023642
`
`Packet Intelligence Ex. 2003 Page 9 of 12
`
`

`

`
`
`Regarding claim 1 ,
`
`•
`Page 10
`SIN: 09/608266
`exchange between a client and a server, but requires a second connection and is therefore
`independent of the initial exchange. In order to eliminate the possibility of disjointed
`conversational exchanges, it is desirable for a network packet monitor to be able to
`"virtually concatenate .. -that is, to link-the first exchange with the second. If the clients
`were the same, the two packet exchanges would then be correctly identified as being part of
`the same conversational flow.
`Other protocols that may lead to disjointed flows. include RPC (Remote Procedure Call);
`DCOM (Distributed Component Object Model). formerly called Network OLE (Microsoft
`Corporation, Redmond. Washington); and CORBA (Common Object Request Broker
`Architecture). RPC is a programming interface from Sun Microsystems (Palo Alto,
`California) that allows one program to use the services of another program in a remote
`machine. DCOM. Microsoft's counterpart to CORBA, defines the remote procedure call
`that allows those objects-objects are self-contained software modules-· to be run
`remotely over the network. And CORBA. a standard from the Object Management Group
`(OMG) for communicating between distributed objects, provides a way to execute
`programs (objects) written in different programming languages running on different
`platforms regardless of where they reside in a network.
`The examiner asserts that Gobuyan shows in figure 3 a device with a lookup engine
`(element 3), memory for storage of the entries (elements 6, 8). and a subsystem accessing
`the memory (elements 5 and 7). What Gobuyan shows is a lookup engine to look up source
`and destination addresses (see, e.g .• FIG. 3 and the description of FIG. 3 in col. 3, lines
`35-43) repeated here for convenience.
`Turning now to FIG. 3, the look-up engine consists of three functional blocks.
`namely a destination address look-up engine (DALE) 1, a source address look-up
`engine (SALE) 2, and a look-up engine controller (LEC) 3, which includes a
`microcode ram 4. DALE 1 includes a destination address look-up controller 5 and
`DALE RAM 6. SALE 2 includes a source address look-up controller 7 and SALE
`RAM 8. The input to the look-up engine is through a fast 16-bit wide I/FRAM 9
`receiving input from the AXE (Transfer Engine) and reassembler. The output from
`the look-up engine is through word-wide FlFOs 11, 12.
`Applicants' claim 1 includes in the memory a database that may contain flow-entries for
`A conversational flow is the sequence of packets that are exchanged in any direction as a
`result of an activity-for instance, the running of an application on a se�er as requested by
`a client. Different conversati.onal flows may occur between the same two addresses. Each
`of these would have a separate entry in the flow database. Gobuyan, however, being
`concerned with routing and bridging. cannot distinguish between different conversational
`flows. For example, two packets having the same source and destination addresses would
`be treated the same by Gobuyan.
`
`previously encountered conversati.onal flows to which a received packet may belong.
`
`EX 1020 Page 10
`
`P I_0027970
`PCKTI NT-00023643
`
`Packet Intelligence Ex. 2003 Page 10 of 12
`
`

`

`
`
`encountered conversational
`
`y
`
`addresses.
`
`addresses.
`
`
`
`
`
`different conversational flows between the same two
`
`
`
`Page 11
`SIN: 09/608266
`•
`The memories referred to be examiner are a destination address look-up engine (DALE)
`memory (element 3) and a destination address look-up engine (SALE) memory (element
`8). These are described in detail in FIG. 7, and can be seen to be not for previousl
`flows to which a received packet may belong. In fact, col. 9,
`
`lines 36-37 clearly state: The main purpose of the ALE RAMs 6, 8 is to hold MAC layer
`Because Gobuyan is for a bridge, Gobuyan processes each packet individually,
`and cannot distinguish flows, e.g.,
`Gobuyan uses the lookup engine(s) simply to look up addresses, and sues tree
`searches (engines that traverse a tree) to so perform its lookups.
`The examiner further asserts that column 7 lines 41-43 and 56-59 of Gobuyan teach that
`"Gobuyan discloses that the lookup engine receives portions of packets containing
`identifying information through a 16-bit 1/F RAM (element 9)"
`There is no mention in the cited sections that the lookup engine is configured to lookup
`flow-entry database as required
`(see element (d) of Applicants' claim 1).
`For the reasons above, the cited prior art does not teach or suggest claim l, as amended r as
`previously stated. Thus, examiner's rejection of claim 1 is believed overcome.
`Reconsideration and re-examination are requested.
`Claim l is believed allowable. Action to that end is respectfully requested.
`
`
`
`whether a received packet belongs to a flow-entry in the
`
`
`
`
`
`Other allowable claims
`
`
`
`Rejected claims
`
`Claim 2 depends on claim 1, believed allowable. The examiner's rejection of claim 2 is
`moot in view of the above.
`Claim 3-6 were rejected under 35 U.S.C. 103(a) as being unpatentable over Gobuyan in
`view of Chang (US 4,458,310).
`These claims depend upon claim I, believed to be allowable. Claims 2-6 are therefore
`believed allowable and action to that end is respectfully requested.
`Because the newly added claims include elements that were shown above to not be
`included in Gobuyan and any of the other prior art that was used by the examiner in the
`rejections, the new claims are believed also allowable, and allowance is respectfully
`requested.
`For these reasons, and in view of the above amendment, this application is now considered
`to be in condition for allowance and such action is earnestly solicited.
`
`New claims
`
`EX 1020 Page 11
`
`P I_0027971
`PCKTI NT-00023644
`
`Packet Intelligence Ex. 2003 Page 11 of 12
`
`

`

`SIN: 09/608266
`
`Page 12
`
`Conclusion
`with respect
`to all
`have been overcome
`all of Examiner's rejections
`believe
`The Applicants
`Action to
`that
`claims are allowable.
`(as amended), and that the remaining
`remaining claims
`requested.
`end is respectfully
`the prosecution
`and
`or comments that would advance
`has any questions
`If the Examiner
`ed at dov@inventek.com,
`an email message to the
`undersign
`of this application,
`allowance
`is requested.
`at+ 1-510-547-3378
`call to the undersigned
`or a telephone
`
`r;ib 10 J...Be>t/
`�
`Date
`Address for corresponden
`ce:
`Dov Rosenfeld
`Suite 2
`A venue,
`5507 College
`Oakland, CA 94618
`Tel. +1-510-547-3378
`Fax: +1-510-291-2985
`Email: dov@inventek.com
`
`EX 1020 Page 12
`
`P I_0027972
`PCKTI NT-0002364 5
`
`Packet Intelligence Ex. 2003 Page 12 of 12
`
`