IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Examiner: (cid:9)
`
`Salman Ahmed
`
`Technology Center/Art Unit: 3992
`
`COMMENTS TO ACP
`
`In re application of: Edward Balassanian
`
`U.S. Patent No. 6,629,163
`
`Reexamination Control No.: 95/000,659
`
`Reexamination Request Filed: February 13, 2012
`
`For: Method and System for Demultiplexing a
`First Sequence of Packet Components to Identify
`Specific Components Wherein Subsequent
`Components are Processed Without Reidentifying
`Com • onents
`
`Attn: Mail Stop "Inter Partes Reexam"
`Central Reexamination Unit
`Commissioner for Patents
`United States Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`Dear Sir:
`
`Patent Owner has received the PTO's Action Closing Prosecution ("ACP") dated October
`
`1, 2012. In the ACP, the Examiner maintained his rejection of claim 1 of U.S. Patent No.
`
`6,629,163 ("the '163 Patent," or simply "'163") as obvious in light of "Router Plugins: A
`
`Software Architecture for Next Generation Routers" ("Decasper") and U.S. Patent No. 6,243,667
`
`("Kerr"). The Examiner also maintained his rejection of claims 15 and 35 as anticipated by
`
`Decasper and Kerr. Only claims 1, 15 and 35 are under reexamination. Patent Owner continues
`
`to traverse these rejections. The pending claims are reflected in the Listing of Claims attached as
`
`an Appendix. Exhibit 1 (Dr. Ng's Declaration) is also attached. While Patent Owner does not
`
`believe any fees are required, if fees are necessary, then such fees are hereby petitioned and
`
`authorized to be charged to our Deposit Account No. 504592.
`
`Juniper Ex. 1020-p. 1
`Juniper v Implicit
`
`

`

`I. (cid:9)
`
`Background of the '163 Invention (cid:9)
`
`TABLE OF CONTENTS
`
`A. Message-Based Systems Contrasted with Packet-Based Systems (cid:9)
`
`B. Dynamic Identification of a Sequence of Components Based on First Packet (cid:9)
`
`C. Components Convert Data with Input Format to Data with Output Format (cid:9)
`
`D. Format Matching/Compatibility (cid:9)
`
`E. State Information (cid:9)
`
`II. (cid:9)
`
`IP Routers in General (cid:9)
`
`A. Routers Versus End Points (cid:9)
`
`B.
`
`IP Routers Only Process IP Formats at One Layer (cid:9)
`
`C.
`
`IP Routers Do Not Maintain Message-Specific State (cid:9)
`
`III. (cid:9)
`
`Decasper Fails to Anticipate or Render Obvious the '163 Patent Claims (cid:9)
`
`A. Background on Decasper as an IP Router (cid:9)
`
`B. Decasper Fails to Teach the Message Limitations (cid:9)
`
`C. Decasper Fails to Teach the Converting Limitations (cid:9)
`
`D. Decasper Fails to Teach the First Packet Limitations (cid:9)
`
`E. Decasper Fails to Teach the Format Matching Limitations (cid:9)
`
`F. Decasper Fails to Teach the State Limitations (cid:9)
`
`IV. (cid:9)
`
`Kerr Fails to Anticipate or Render Obvious the '163 Patent Claims (cid:9)
`
`A. Background on Kerr (cid:9)
`
`B. Kerr Fails to Teach the Message Limitations (cid:9)
`
`C. Kerr Fails to Teach the Converting Limitations (cid:9)
`
`D. Kerr Fails to Teach the First Packet Limitations (cid:9)
`
`E. Kerr Fails to Teach the Dynamic Identification Limitations (cid:9)
`
`F. Kerr Fails to Teach the Format Matching Limitations (cid:9)
`
`14069-v4/1048-0030
`
` 1
`
`1
`
`5
`
`7
`
`8
`
`10
`
`11
`
`11
`
`12
`
`13
`
`14
`
`14
`
`16
`
`18
`
`20
`
`21
`
`26
`
`29
`
`29
`
`31
`
`32
`
`33
`
`33
`
`36
`
`Juniper Ex. 1020-p. 2
`Juniper v Implicit
`
`

`

`G. (cid:9)
`
`Kerr Fails to Teach the State Limitations (cid:9)
`
`V. Dr. Ng.'s Declaration (cid:9)
`
`VI.
`
`Secondary Indicia (cid:9)
`
`38
`
`39
`
`41
`
`14069-v4/1048-0030
`
`Juniper Ex. 1020-p. 3
`Juniper v Implicit
`
`

`

`REMARKS
`
`Patent Owner respectfully submits that there is a fundamental and patentable difference
`
`between the '163 Patent and the Decasper and Kerr prior art references—namely, the message-
`
`oriented nature of the '163 invention and its stateful, dynamic processing of the message at
`
`different layers in the protocol stack versus the packet-oriented nature of IP routers that are
`
`designed to only process the IP protocol. 1 An initial explanation of these fundamental
`
`differences provides the proper perspective for the claim analysis that follows.
`
`I. (cid:9)
`
`Background of the '163 Invention
`
`Claims 1, 15, and 35 use the word "message(s)" no fewer than 26 times. These message-
`
`centric claims require that a message's packets are processed by using the first packet to
`
`dynamically identify a non-predefined sequence of components so that the output format of one
`
`component is compatible with the input format of the next component. The sequence of
`
`components, i.e., the "path," is then stored and used—along with message-specific state
`
`information—to process the subsequent packets of the message. These concepts are critical to
`
`the patentability of the '163 invention.
`
`A. (cid:9)
`
`Message-Based Systems Contrasted with Packet-Based Systems
`
`In addition to the actual claim language that centers on messages, the '163 specification
`
`repeatedly emphasizes the message-oriented nature of the invention. 2 See, e.g., '163 Abstract
`
`IP routers have an IP core, such as the IP core disclosed in Decasper, that is responsible for the
`processing of IP packets. The references in this Response to "IP router," "Decasper router," and "Kerr
`router" (and the like) are meant to cover the architecture and functionality of an IP core, as opposed to the
`device the IP core might be integrated with, i.e., "IP router" in this Response is shorthand for the IP core
`of the router. This definition is appropriate because the rejections based on Decasper and Kerr are
`focused on the IP core disclosed in those references.
`
`2 (cid:9)
`
`In its Markman Order in the related litigation, the district court construed "message[s]" as "a
`collection of data that is related in some way, such as a stream of video or audio data or an email
`1
`
`14069-v4/1048-0030
`
`Juniper Ex. 1020-p. 4
`Juniper v Implicit
`
`

`

`(referencing messages); Figures 1, 7A-C, 8, 9, and 12 (referencing messages); 2:38-49 ("A
`
`message is a collection of data that is related in some way, such as stream of video or audio data
`
`or an email message."); 2:57-64 (referencing "the processing of each message"); 3:2-7
`
`(referencing the processing of "all packets of a message").
`
`A message-based technology fundamentally differs from a packet-based technology in
`
`that it is concerned with not just the processing of individual packets, but with the processing of
`
`a message as a whole, i.e., processing all the packets of the message. For example, the '163
`
`specification states that a "session" is created to ensure that all packets of a message are
`
`processed properly: the "conversion system routes all packets of a message through the same
`
`session of each conversion routine so that the same state or instance information can be used by
`
`all packets of the message." '163 3:2-7 (emphasis added). The specification provides an
`
`example of a message that includes packets with three nested layers having different formats:
`
`Ethernet, IP, and TCP. '163 Fig. 4; 1:27-37; 5:32-57; 6:48-57. In this example, the message has
`
`a start point (defined by the initiation of a TCP connection) and an end point (defined by the
`
`termination of a TCP connection), which clearly delineates the message. RFC 793. The
`
`Requestor Juniper agrees that the '163 "patent[ ] claim[s] an approach to processing packets of
`
`data that starts by analyzing the first packet of a message in order to figure out how best to
`
`process the remaining packets in the message...." Juniper Summary Judgment motion at 2; id.
`
`at 3 ("This dynamically identified sequence is then stored so it can be used in processing each
`
`subsequent packet of the same message") (emphases added).
`
`message." Markman Order at 12-13, Implicit Networks, Inc. v. Juniper Networks, Inc., No. 10-CV-4234-
`SI (N.D. Cal. Feb. 29, 2012).
`
`14069-v4/1048-0030
`
`2
`
`Juniper Ex. 1020-p. 5
`Juniper v Implicit
`
`

`

`In contrast to the message-based approach, a packet-based processing technology—such
`
`as that employed by IP routers—is concerned primarily with processing individual packets as
`
`opposed to processing the entirety of the message. Unlike the '163 technology that processes
`
`"all packets of a message" ('163 3:2-7), an IP router is not guaranteed to receive all packets of a
`
`message; it may receive none or only some of the message's packets. Accordingly, because IP
`
`routers cannot depend on receiving all packets of a message, they are designed to process the
`
`individual packets rather than the entire message. In fact, an IP router does not depend on when
`
`a message starts or stops; instead, it processes each packet independently as prescribed by the
`
`specification for the IP protocol (RFC 791) which dictates that IP packets are independent
`
`datagrams. While IP routers can exploit information about where IP packets are headed (e.g., by
`
`using addresses and ports), they are not designed to process the entire messages the packets
`
`belong to. Instead, they primarily attempt to make forwarding decisions about the individual
`
`packets as efficiently as possible.
`
`This fundamental difference between the '163 Patent and general IP routers (such as
`
`those of Decasper and Kerr) is critical because the distinguishing claim limitations flow from it.
`
`Figure 1 provides a high-level depiction of this fundamental difference:
`
`FIG. 1
`
`14069•v4/1048-0030
`
`3
`
`Juniper Ex. 1020-p. 6
`Juniper v Implicit
`
`

`

`Figure 1 shows a client and server communicating with each other over the Internet,
`
`which contains numerous IP routers, represented by routers 1-6. The client and the server, which
`
`can be considered as end points, communicate by sending and receiving messages between each
`
`other. Clients can include applications such as web browsers, enterprise applications, video
`
`conferencing systems, and email applications. Servers can include front-end web servers, back-
`
`end web servers, enterprise applications, etc.
`
`Generally speaking, a message is a group of packets related in a meaningful way by, for
`
`example, the connection between a client and server. See, e.g., '163 2:38-49. A message could
`
`include HTTP requests, HTTP responses, HTTP connections, email messages, VoIP
`
`conversations, etc.—all of which require higher-level protocol support to effectively
`
`communicate a message or establish a connection between a client application and a
`
`server. When a client sends a message to a server, the message is broken up into individual
`
`packets by processing the message through protocols such as HTTP, TCP, IP, and Ethernet.
`
`Id.
`
`at '163 Fig. 4; 1:27-37; 5:32-57; 6:48-57. HTTP sends its data to TCP. TCP, in turn, breaks up
`
`the byte-stream into individual segments that are transmitted as individual IP packets. Finally,
`
`the Ethernet protocol frames IP packets for transmission. On the server side, a similar sequence
`
`of message processing steps occurs as the incoming packets are processed by Ethernet, IP, TCP,
`
`HTTP, and so on.
`
`Each individual IP packet of a particular message may take a different route over the
`
`Internet when traveling from the client to the server or vice versa. For instance, a first packet of
`
`a TCP connection between a client and a server may travel through routers 1, 2, 3, and 6, while a
`
`second packet of that connection may travel from the client to the server through routers 2, 3,
`
`and 6, and a third packet may go through routers 4, 5 and 3. However, since IP packets are
`
`14069-v4/1048-0030
`
`4
`
`Juniper Ex. 1020-p. 7
`Juniper v Implicit
`
`

`

`essentially independent datagrams, routers are designed to process each IP packet independently.
`
`While routers can exploit characteristics in the IP packets to allow for optimized routing, they
`
`process incoming packets at the IP layer and do not support high-level protocols required to
`
`process the entire message.
`
`The only devices shown in the above Figure 1 that process the actual message or are even
`
`guaranteed to see all of the packets of a given message are the client and the server. This is one
`
`reason why the '163 invention is so different from the IP routers taught in Decasper and Kerr—it
`
`operates on entire messages because it works at the end points, processing each message up and
`
`down the various layers of the protocol stack. This is in contrast to the IP routers of Decasper
`
`and Kerr, which operate at the network layer and only process the IP protocol.
`
`Routers operate in this message-agnostic way because, by design, every IP packet stands
`
`alone. Per the IETF specifications for the IP protocol, each IP packet is an independent datagram
`
`which can be processed independently by any router. RFC 791. As Requester Juniper puts it in
`
`a white paper, "Packet-based forwarding does not require any information about either previous
`
`or subsequent packets that belong to a given connection ..."
`
`See Juniper White Paper:
`
`"Understanding Packet-Based and Flow-Based Forwarding."
`
`B. (cid:9)
`
`Dynamic Identification of a Sequence of Components Based on First Packet
`
`Claim 1 requires that "for the first packet of the message," "dynamically identifying a
`
`non-predefined sequence of components for processing the packets of the message" and "storing
`
`an indication of each of the identified components so that the non-predefined sequence does not
`
`need to be re-identified for subsequent packets of the message." Some background information
`
`on these claim limitations—including how they are derived from the concept of message-based
`
`processing—is helpful.
`
`14069-v4/1048-0030
`
`5
`
`Juniper Ex. 1020-p. 8
`Juniper v Implicit
`
`

`

`In Patent Owner's preferred embodiment, processing functions are captured in individual
`
`code modules, which are called "components." The components are not glued together at
`
`compile time, but rather remain individual and then are recruited as part of a message-specific
`
`processing path after a first packet of a new message arrives. At that point, the system unwraps
`
`the different layers of the first packet (e.g., Ethernet, IP, TCP, etc.), examines those layers, and
`
`builds a data processing path by selecting components based on and guided by configuration
`
`information present before the first packet. As set forth in the preferred embodiment, the '163
`
`Patent technology uses configuration information expressed as a sequence of processing steps
`
`that are stored in a cache called "LabelMapGet" (do "a," then do "b," then do "c").
`
`As described in the '163 specification, the steps in Patent Owner's preferred embodiment
`
`are as follows for the example of a message with packets having three nested layers based on
`
`Ethernet/IP/TCP protocols:
`
`A packet arrives:
`
`The first packet of the message arrives at an Ethernet port. The Ethernet component
`
`inspects the header to determine the next layer, and then hands the packet off to the module
`
`responsible for processing that format.
`
`Ethernet determines it is carrying IP data:
`
`If the packet is carrying IP data, the system sends the packet to the IP component. IP is
`
`the "compatible format" here, which is explained in more detail below.
`
`IP determines it is carrying TCP data:
`
`The IP component then determines the type of payload in the next layer. IP can carry
`
`many types of data, including TCP. The IP component inspects the header, and if it sees TCP, it
`
`14069-v4/1048-0030
`
`6
`
`Juniper Ex. 1020-p. 9
`Juniper v Implicit
`
`

`

`hands the packet to the TCP component for subsequent processing. TCP is the "compatible
`
`format" here.
`
`TCP determines it is carrying application data:
`
`TCP can carry any number of application layer data types. This could be HTTP on port
`
`80 or many other types of data. As such, the format of data encapsulated by TCP can be inferred
`
`by the TCP port number. There is a mechanism in the system that dictates the mapping of TCP
`
`data types (e.g., the port number) to a subsequent component. That mechanism described in the
`
``163 Patent is a "policy" look-up. At this point, the specification describes methods to determine
`
`the next series of processing steps, e.g., a LabelMapGet ("LMG") cached list of steps. Once this
`
`is done, a message -specific path is built, and all subsequent packets in the same message
`
`shuttle through that path. The "dynamic identification" step of claim 1 is thus message-
`
`centric—something that IP routers by definition are not.
`
`C. (cid:9)
`
`Components Convert Data with Input Format to Data with Output Format
`
`Claim 1 also requires "providing a plurality of components, each component being a
`
`software routine for converting data with an input format into data with an output format." A
`
`component is a software routine that receives data and outputs data using certain formats.
`
`See,
`
`e.g., '163 1:23-36 (describing "TCP format," "IP format," and "ethernet format"); 4:43-50
`
`("Each edge has an input format and an output format."). The data that a component receives
`
`has a certain format, which is the "input format." Likewise, the data that it outputs has a certain
`
`format, which is the "output format." 3 Id. at 4:55-67 (describing converting various input
`
`formats to various output formats).
`
`3 (cid:9)
`
`In its Markman Order in the related litigation, the district court construed "input/output format"
`as the "structure or appearance of data to be processed" and the "structure or appearance of the data that
`7
`
`14069-v4/1048-0030
`
`Juniper Ex. 1020-p. 10
`Juniper v Implicit
`
`

`

`As with the other claim limitations specifically highlighted here, this limitation stems in
`
`part from the fact that the '163 Patent technology allows protocols above the IP layer at which IP
`
`routers operate, e.g., at the TCP level. As a result, the '163 invention can handle different
`
`formats at multiple layers in the protocol stack (e.g., Ethernet/IP/TCP), and the components that
`
`handle the packets can implement different input and output formats. In contrast and as
`
`described below, IP routers process packets only at one layer and use only the IP format. Every
`
`packet goes into a router as an IP packet, exits the router as an IP packet, and remains an IP
`
`packet throughout its time inside the router. Preserving the IP format is critical for such IP
`
`routers as it is for each of the processing steps within the routers.
`
`D. (cid:9)
`
`Format Matching/Compatibility
`
`Claim 1 requires that the dynamic identification step be performed "such that the output
`
`format of the components of the non-predefined sequence match the input format of the next
`
`component in the non-predefined sequence." In order to determine which software routines (or
`
`"components") to select and in what order they should be applied, the '163 preferred
`
`embodiment inspects and understands the format of a packet and maps that format to the one or
`
`more components that are compatible to that format. '163 Patent at 4:43-5:4.
`
`In fact, the '163 Patent states that "[w]hen a packet of a message is received, the
`
`conversion system ... identifies a sequence of conversion routines [i.e creates a path] for
`
`processing the packets of the message by comparing the input and output formats of the
`
`conversion routines." '163 Patent at 2:40-45; see also 1:66-2:2 ("it would be desirable to have a
`
`technique in which the output format of one conversion routine can be identified as being
`
`results from processing." Markman Order at 9, Implicit Networks, Inc. v. Juniper Networks, Inc., No. 10-
`CV-4234-S1 (N.D. Cal. Feb. 29, 2012).
`
`14069-v4/1048-0030
`
`8
`
`Juniper Ex. 1020-p. 11
`Juniper v Implicit
`
`

`

`compatible with the input format of another conversion routine"); 4:51-53 ("The label map get
`
`routine identifies a sequence of edges such that the output format of each edge is compatible with
`
`the input format of another edge in the sequence...."). This mapping process identifies the
`
`sequence of components (e.g., Ethernet, IP, TCP, HTTP, and so on) that should be associated
`
`with the message, and then it creates the message-specific sequence of processing components
`
`(i.e., the path). '163 Patent at 3:65-5:4.
`
`In the context of Figure 1 above, this type of format matching can only be performed by
`
`systems that operate at the message level (e.g., clients and servers). In particular, the only
`
`devices shown in the Figure 1 network that are capable of processing packets at a layer higher
`
`than IP are the client and the server, both of which see all packets of a message and thus handle
`
`multiple formats, such as Ethernet, IP and TCP. In contrast, routers 1-6 are IP routers and thus
`
`process packets only at a single layer and handle only a single format: Internet Protocol. Each
`
`router receives an IP packet and outputs an IP packet. Indeed, as a consequence of being IP
`
`routers, they have no ability to process packets higher in the stack than IP. To go deeper into the
`
`packet, routers would have to maintain state for the duration of a message, and determine what to
`
`do after processing at the TCP level (even if IP routers did process at the TCP level, which they
`
`do not).
`
`The router's lack of format matching ultimately stems from the fact that routers only
`
`process independent IP packets that take varying routes across the Internet. As such, routers are
`
`not guaranteed to receive all the packets of a message and thus are designed to process individual
`
`packets. Because a router is message-agnostic and often does not receive all packets of a
`
`message, it does not process packets at the TCP layer or any higher layer protocol. To illustrate,
`
`the TCP module is required to collect all the packets of a given message, make sure that all
`
`14069-v4/1048-0030
`
`9
`
`Juniper Ex. 1020-p. 12
`Juniper v Implicit
`
`

`

`packets are present, eliminate duplication, and ensure that the packets are in the right sequence.
`
`A TCP module can do this only if it is guaranteed to have all of the packets that make up a
`
`message. RFC 793. As a router is not guaranteed to receive all packets of a message, however,
`
`it simply has no ability to do TCP protocol layer processing.
`
`E. (cid:9)
`
`State Information
`
`Claim 1 further requires, "for each of a plurality of packets of the message in sequence"
`
`and "for each of a plurality of components in the identified non-predefined sequence":
`
`retrieving state information relating to performing the processing of the
`component with the previous packet of the message;
`
`performing the processing of the identified component with the packet and the
`retrieved state information; and
`
`storing state information relating to the processing of the component with the
`packet for use when processing the next packet of the message.
`
`Thus, the claim limitations require collecting and maintaining message-specific state information
`
`relating to the processing of one packet of a message, storing that state information, and
`
`retrieving it for use when processing the next packet of that message.
`
`Referring again to Figure 1 above, the fact that the client and server are the only devices
`
`that are guaranteed to see all the packets of a given message means that they are the only devices
`
`that are designed to perform the state limitations recited above, which require using state
`
`information across the packets of a message to "process[] [the] message." See '163 3:2-7 ("The
`
`conversion system routes all packets of a message through the same session of each conversion
`
`routine so that the same state or instance information can be used by all packets of the
`
`message."); 3:58-60 ("The sessions are identified so that each packet is associated with the
`
`appropriate state information.") (emphases added). Routers 1-6, in contrast, do not necessarily
`
`see all the packets of a message and thus are not designed to collect, retain and apply state
`10
`
`14069-v4/1048-0030
`
`Juniper Ex. 1020-p. 13
`Juniper v Implicit
`
`

`

`information from packet-to-packet for the entire message. In fact, as explained above, IP routers
`
`such as Decasper and Kerr are not designed to determine the actual start and end to a message
`
`because, for example, they are not designed to inspect the SYN and FIN bits in the TCP headers
`
`that are normally associated with setting up and tearing down a TCP connection.
`
`The message-specific claim limitations also highlight the type of state that the '163 Patent
`
`technology uses: hard state. Hard state is required for correct function and cannot be flushed
`
`randomly without regard to the processing of the entire message. In other words, it is
`
`inextricably intertwined with the message and must be maintained for the duration of the entire
`
`message. If it is discarded before the entire message is processed, all mid-message processing
`
`would fall apart, and the system would be useless. In contrast, IP routers do not use this kind of
`
`hard state, since hard state is tied to the processing of entire messages and routers are not
`
`guaranteed to see all packets of entire messages. In short, because routers do not process entire
`
`messages, they also cannot use the hard state that is used to process entire messages. Instead,
`
`routers use soft state—state that can be discarded, regenerated or replaced as needed, as further
`
`explained below.
`
`II. (cid:9)
`
`IP Routers in General
`
`A. (cid:9)
`
`Routers Versus End Points
`
`As explained above in connection with Figure 1, a message between a client and a server
`
`might be comprised of packets across a TCP connection, or higher layer applications such as e-
`
`mail, video streams, or HTTP requests. When the client sends the message, the message has a
`
`definitive start and end as determined by higher layer protocols such as TCP. Similarly, when
`
`the server receives the message, the message is also complete in the sense that the server has all
`
`of the packets that make up the message.
`
`14069-v4/1048-0030
`
`11
`
`Juniper Ex. 1020-p. 14
`Juniper v Implicit
`
`

`

`But in between—that is, when the message is being routed through routers 1-6—the
`
`message is fragmented into packets, each of which may take one of a variety of routes to the
`
`server. Thus, while the client and the server—i.e., the end-points—necessarily see the entire
`
`message, routers 1-6 are not guaranteed to see the entire message. This fundamental difference
`
`between routers and end-points is significant because Decasper and Kerr function at the router
`
`level and the '163 Patent technology functions at the end-point level.
`
`B. (cid:9)
`
`IP Routers Only Process IP Formats at One Layer
`
`One significant implication of this fundamental difference is the fact that because end-
`
`points see all the packets of a message, they can operate at layers in the protocol stack that are
`
`above IP. For instance, the end-points can operate with TCP, while the IP routers cannot
`
`because operating at higher layer protocols than IP would require seeing all the packets that
`
`make up the message. This means that routers only process packets having the IP format.
`
`Whether a packet is an IP format is determined by the structure of its header. To
`
`illustrate, Figure 2 shows the structure of an exemplary IP format header:
`
`0
`
`4
`
`8
`
`16 (cid:9)
`
`19
`
`24
`
`31
`
`I HI, (cid:9)
`
`Type of Service
`
`Total Leagth
`
`Identification
`
`Flags (cid:9)
`
`Fiagment Offset
`
`Time to Live (cid:9)
`
`Protocol
`
`Header Checksum
`
`Solace P Address
`
`Destination TP Address
`
`Options (cid:9)
`
`Padding
`
`Fig. 2
`
`RFC 791 at 10. As shown, in this IP header format, the first 4 bits always mean "version," and if
`
`the IP version equals "4," the next 4 bits always mean "Internet header length," the next 8 bits
`
`always mean "type of service," and so on. A packet that has a header with the structure shown in
`
`Figure 2 is, by definition, an IP packet. The bit values within the various fields of the header can
`
`14069-v4/1048-0030
`
`12
`
`Juniper Ex. 1020-p. 15
`Juniper v Implicit
`
`(cid:9)
`(cid:9)
`(cid:9)
`(cid:9)
`(cid:9)
`

`

`vary, but regardless of the bit values in those fields, and regardless of any changes to those bit
`
`values that may be made by a router, the packet always remains an IP formatted packet when the
`
`header's structure is like that shown in Figure 2. That is, the structure or format of the header,
`
`not the bit values, determines whether the packet is an IP packet.
`
`The point here is that IP routers do not change the format of packets, nor would they need
`
`to do so, since routers are designed to handle only IP packets. Routers receive packets in the IP
`
`format, process them in the IP format, and output them in the IP format. In short, IP routers deal
`
`only with the IP format—nothing else.
`
`C. (cid:9)
`
`IP Routers Do Not Maintain Message-Specific State
`
`As explained above in the context of Figure 1, Routers 1-6 do not necessarily see all the
`
`packets of a message. Accordingly, they are not designed to collect, retain and apply state
`
`information from packet-to-packet for the entire message,
`
`i.e., they are not designed to use
`
`message-specific state information. This notwithstanding, routers sometimes use a type of state
`
`called soft state. In general, "soft state is state which is useful for efficiency, but not essential, as
`
`it can be regenerated or replaced if needed." Wikipedia—Soft State,
`
`http://en.v, 'Solt state; see also Such itra Raman & Steven McCanne, A Model,
`
`Analysis, and Protocol Framework for Soft State-based Communication, 29 ACM SIGCOMM
`
`Computer Communication Review 15, 15 (1999). In the context of IP routers, soft state
`
`information (if used) is periodically flushed and "replaced" for one or more reasons such as
`
`memory constraints. An IP router can still function using this flushing process because soft state
`
`information is "not essential" for processing individual IP packets.
`
`On the other hand, state information is essential for a message-centric system that
`
`depends on state information being available for the processing of each packet in the message.
`
`14069-v4/1048-0030
`
`13
`
`Juniper Ex. 1020-p. 16
`Juniper v Implicit
`
`

`

`See, e.g., '163 3:2-7 ("The conversion system routes all packets of a message through the same
`
`session of each conversion routine so that the same state or instance information can be used by
`
`all packets of the message.") (emphasis added). Importantly, because an IP router does not
`
`determine the start and stop of a message, the flushing process described above means that there
`
`is no guarantee that the soft state information will be present for the entire duration of the
`
`message (even assuming the IP router sees all of the message packets). As such, soft state is not
`
`a viable option for message-centric processing that requires the presence of state information.
`
`This would, for instance, render a router incapable of processing TCP packets since the state
`
`required for maintaining a TCP connection would be required for the entire duration of any such
`
`message.
`
`III. (cid:9)
`
`Decasper Fails to Anticipate or Render Obvious the '163 Patent Claims
`
`Decasper does not disclose multiple claim limitations, any one of which requires the
`
`withdrawal of the rejections based on Decasper. 4
`
`A. (cid:9)
`
`Background on Decasper as an IP Router
`
`Decasper teaches an IP router that implements gates and plugins. As such, the Decasper
`
`router shares the characteristics of general IP routers discussed in Sections I and II above.
`
`Accordingly, Decasper processes packets only at the IP layer, such as at routers 1-6 shown in
`
`Figure 1 above. Because it processes packets strictly at the IP layer, Decasper handles only the IP
`
`format, which it carefully preserves when processing packets.
`
`As an IP router, Decasper is not designed to process messages, in part, because it does
`
`not necessarily see all packets in a message and also because the IP protocol does not provide for
`
`4
`
`In support of several of these patentable distinctions with respect to both Descasper and Kerr, Patent Owner
`presents the declaration of Dr. Eugene Ng. (Ex. 1). The declaration should be considered for the reasons set forth in
`section V, infra.
`
`14069-v4/1048-0030
`
`14
`
`Juniper Ex. 1020-p. 17
`Juniper v Implicit
`
`

`

`any ability to define message boundaries. In fact, Decasper's router is not designed to recognize
`
`when a packet marks the start of a new message or when a packet marks the end of that message.
`
`Instead, Decasper is designed to route or forward IP packets on an individual basis, and the
`
`processing of each packet is done without regard to any other packets in the system. Put simply,
`
`the fact that two packets might belong to the same flow does not change the processing of either
`
`packet in Decasper. On the contrary, the processing of one packet in a message has a direct
`
`impact