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
`
`Group An Unit: 2662
`
`Examiner: Alan Nguyen
`
`
`
`
`
`
`Filed: June 30, 2000
`
`Title: ASSOCIATIVE CACHE STRUCTURE FOR
`
`
`
`LOOKUPS AND UPDATES OF FLOW
`RECORDS IN A NETWORK MONITOR
`
`
`
`RESPONSE TO OFFICE ACTION UNDER 37 CFR 1.111
`
`Commissioner for Patents
`PO. 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 of Fannie Tramnission under 37 CFR 1.8
`
` I hereby certify that this correspondence18 being deposited with the United States Postal Service as first class
`
`
`mailin an envelope addressed to Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on.
`
`
`Signed:%—Name: Dov
`fig: “9, 2199 9,
`Date:
`
`senfeld Reg No 38687
`
`EX 1020 Pa e 1
`EX 1020 Page 1
`
`
`PI_0027961
`PCKTINT-00023634
`
`

`

`C
`
`O
`
`SIN: 09/608266
`
`Page 2
`
`'
`
`_.
`
`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.
`
`0
`
`0
`
`0
`
`0
`
`0
`
`0
`
`0
`
`(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.
`
`1.
`
`(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)
`
`(b)
`
`(c)
`
`(d)
`
`(e)
`
`a packet acquisition device coupled to the connection point and configured
`to receive packets passing through the connection point;
`
`a memory for storing a database comprising mae—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; and
`
`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
`subsystemyafl
`
`a state processor coupled to the lookup engine and to the flow—ent_ry-
`database memog, the state processor being to perform any state omrations
`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 omrations required for the initial state of the new flow in the case that the
`packet is from an existing flow.
`
`EX 1020 Page 2
`\EXMW
`
`P|_0027962
`PCKTINT-00023635
`
`

`

`g
`
`
`
`O
`
`O
`
`SIN: 09/608266
`
`Page 3
`
`2.
`
`(Previously presented) A packet monitor according to claim 1, further comprising:
`
`'
`
`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 flew-entry is identified by identifying information stored in the flow-
`entry, and wherein the cache lookup uses a function of the extracted identifying
`information.
`
`3.
`
`4.
`
`(Previously presented) A packet monitor according to claim 2, wherein the cache
`subsystem is an associative cache subsystem including one or more content
`addressable memory cells (CAMS).
`
`(Previously presented) A packet monitor according to claim 2, wherein the cache
`subsystem includes:
`
`(i)
`
`(ii)
`
`a set of cache memory elements coupled to the flOerntry 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;
`
`a set of content addressable memory cells (CAMs) connected according to
`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.
`
`V
`
`5.
`
`(Previously presented) A packet monitor according to claim 4, wherein the CAM
`controller is configured such that the bottom CAM points to the least recently used
`cache memory element.
`
`EX 1020 Pa e 3
`EX 1020 Page 3
`
`P|_0027963
`PCKTINT-00023636
`
`

`

`SIN: 09/608266
`
`Page 4
`
`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
`
`\W
`EX 1020 Page 4
`
`P|_0027964
`PCKTINT-00023637
`
`

`

`S/N: 09/608266
`
`Page 5
`
`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 lockup 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 includes 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 pattems/operations memory
`coupled to the state processor, the state operations memory configured to store a
`database of protocol dependent state pattems/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:
`
`21.
`
`22.
`
`23.
`
`24.
`
`25.
`
`26.
`
`27.
`
`28.
`
`29.
`
`EX 1020 Page 5
`EX 1020 Page 5
`
`PI_0027965
`PCKTINT-00023638
`
`

`

`SIN: 09/608266
`
`Page 6
`
`(a)
`
`(b)
`
`(c)
`
`(d)
`
`(e)
`
`receiving a packet from a packet acquisition device;
`
`perfomiing one or more parsing/extraction operations on the packet to
`create a parser record comprising a function of selected portions of the packet;
`
`looking up a flow-entry database comprising none or more flow-entries for
`previously encountered conversational flows, the looking up using at least
`some of the selected packet portions and determining if the packet is of an
`existing flow, the lookup being via a cache;
`
`if the packet is of an existing flow, classifying the packet as belonging to the
`found existing flow; and
`
`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,
`
`30.
`
`31.
`
`32.
`
`33.
`
`wherein the parsing/extraction operations depend on one or more of the protocols to
`which the packet conforms.
`(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.
`(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.
`
`(New) A method according to claim 29, wherein the looking up of the flow—entry
`database uses a hash of the selected packet portions.
`,
`
`(New) A method according to claim 29, wherein step ((1) includes if the packet is of
`an existing flow, obtaining the last encountered state of the flow and performing 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 Pa e 6
`EX 1020 Page 6
`
`PI_0027966
`PCKTINT-00023639
`
`

`

`SIN : 09/608266
`
`Page 7
`
`REMARKS
`
`Status of the Application:
`
`Claims 1-20 are the claims of record of the application. Claims. 1—20 have been rejected.
`
`Amendment to the Claims:
`
`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.
`
`Description of aspects of the present invention
`
`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 US. Patent
`application 09/608237 for METHOD AND APPARATUS FOR MONITORING TRAFFIC
`IN A NETWORK, to inventors Dietz, et a1, Attomey/Agent Docket APPT-OOl-l.
`
`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 conversationalflow 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
`
`EX 1020 Page 7
`\W
`
`P|_0027967
`PCKTINT-00023640
`
`

`

`
`
`I
`
`, O
`
`S/N: 09/608266
`
`Page 8
`
`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
`conversationalflows to determine whether a signature is from an existing flow. The
`present invention described the lookup mechanism in more detail. In one aspect, the
`analyzer further identifies the state ofthe existingflow, and performs any state processing
`operations specified for the state. In the case of a newly encounteredflow, 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.
`
`Claim Rejections -35 USC § 102 and 35 USC § 103
`
`In paraggaph 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 paraggaph 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.
`
`Description of 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).
`
`Gobuyan fails to include the cache subsystem
`
`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.
`
`Gobuyan fails to include the state processor
`
`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
`
`EX 1020 Page 8
`EX 1020 Page 8
`
`PI_0027968
`PCKTINT-00023641
`
`

`

`S/N: 09/608266
`
`Page 9
`
`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 conversationalflow. 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 conersationalflow 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 conversationalflows may occur between the same two
`addresses. Each ofthese would have a separate entry in the flow database. Gobuyan,
`however, being concerned with routing and bridging, cannot distinguish between different
`conversational flows. Forexample, two packets having the same source and destination
`addresses would be treated the same by Gobuyan. Unlike Gobuyan, the present invention
`is able to identify and classify conversationalflows rather than only connection 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 usedto 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#5-—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
`EX 1020 Page 9
`
`PI_0027969
`PCKTINT-00023642
`
`

`

`SIN: 09/608266
`
`Page 10
`
`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.
`
`Regarding claim 1,
`
`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, c.g., FIG 3 and the description of FIG. 3in 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 lookup 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/F RAM 9
`receiving input from the AXE (Transfer Engine) and reassembler. The output from
`the look-up engine is through word—wide FIFOs 11, 12.
`
`Applicants' claim 1 includes in the memory a database that may containflow-entries for
`previously encountered conversationalflows to which a receivedpacket may belong.
`
`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 server as requested by
`a client. Different conversationalflows may occur between the same two addresses. Each
`ofthese would have a separate entry in theflow 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.
`
`EX 1020 Page 10
`\WW
`
`P|_0027970
`PCKTINT-00023643
`
`

`

`C
`
`D
`
`SIN: 09/608266
`
`Page 1 1
`
`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 previously
`encountered conversationalflows to which a received packet may belong. In fact, col. 9,
`lines 36-37 clearly state: The main purpose ofthe ALE RAMs 6, 8 is to hold MAC layer
`addresses. Because Gobuyan is for a bridge, Gobuyan processes each packet individually,
`and cannot distinguish flows, e.g., different conversationalflows between the same two
`addresses. 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 I/F RAM (element 9)”
`
`There is no mention in the cited sections that the lookup engine is configured to lookup
`whether a received packet belongs to a flow-entry in theflow-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 1, as amended r as
`previously stated. Thus, examiner’s rejection of claim 1 is believed overcome.
`
`Reconsideration and reexamination are requested.
`
`Claim 1 is believed allowable. Action to that end is respectfully requested.
`
`Other allowable claims
`
`Rejected claims
`
`Claim 2 depends on claim I, 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 1, believed to be allowable. Claims 2-6 are therefore
`believed allowable and action to that end is respectfully requested.
`
`New claims
`
`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.
`
`EX 1020 Page 11
`' EX 1020 Page 11\
`
`
`
`P|_0027971
`PCKTINT-00023644
`
`

`

`
`
`S/N:809/608266
`
`Conclusion
`
`*
`
`Page 12
`
`The Applicants believe all of Examiner’s rejections have been overcome with respect to all
`remaining claims (as amended), and that the remaining claims are allowable. Action to that
`end is respectfully requested.
`
`If the Examiner has any questions or comments that would advance the prosecution and
`allowance of this application, an email message to the undersigned at dov@inventek.com,
`or a telephone call to the undersigned at +1 -5 10-547-3378 is requested.
`
`Respectfully Submitted,
`
`
`
`
`
`senfeld, Reg. No. 38687
`
`MDate
`
`Address for correspondence:
`Dov Rosenfeld
`
`5507 College Avenue, Suite 2
`Oakland, CA 94618
`Tel. +1-510-547~3378
`
`Fax: +1-510—291-2985
`Email: dov@inventck.com
`
`A
`
`EX 1020 Pa e 12
`EX 1020 Page 12
`
`PI_0027972
`PCKTINT-00023645
`
`