IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`PATENT
`
`Inventor:
`
`Edward Balassanian
`
`Serial Number: Unknown
`
`Filing Date:
`
`June 6, 2013
`
`Title: METHOD AND SYSTEM FOR
`DATA DEMULTIPLEXING
`
`Atty.Dkt.No.:
`
`6743-00105
`
`Examiner:
`
`Unknown
`
`Group/ Art Unit: Unknown
`
`Conf. No.:
`
`Unknown
`
`****CERTIFICATE OF E-FILING TRANSMISSION****
`
`I hereby certify that this correspondence is being transmitted
`via electronic filing to the United States Patent and
`Trademark Office on the date shown below:
`
`On: June 6, 2013
`Date
`
`/Dean M. Munyon/
`Dean M. Munyon,# 42,914
`
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`§
`
`PRELIMINARY AMENDMENT
`
`Please enter the following preliminary amendment in the above-captioned case.
`
`Please amend the case as listed below.
`
`Page 1 of 21
`
`Juniper Ex. 1004-p. 1
`Juniper v Implicit
`
`

`

`IN THE SPECIFICATION:
`
`Please amend the specification by replacing the first paragraph after the title with the
`
`following amended paragraph:
`
`[0001] +his- The present application is a continuation of U.S. patent application Ser. Aiml. No.
`13/236,090, filed September 19, 2011, which is a continuation of US. Appl. No. 10/636,314,
`
`filed August 6, 2003 (now U.S. Patent No. 8,055,786), titled Method and System: for Data
`
`Dem:ultiplmcing, for all purposes including but not limited to the right of priority and benefit of
`
`earlier filing date, and mcpressly incorporates by reference the entire content of Patent
`
`l\pplication Serial No.10/636,314 for all purposes. U.S. patent application Ser. No.10/636,314
`
`which is a continuation of U.S. Appl. patent application Ser. No. 09/474,664, filed December 29,
`
`1999 (now U.S. Patent No. 6,629,163);, filed December 29, 1999, titled Method and System: for
`
`Dem:ultiplmcing a First Sequence of Packet Components to Identify Specific Components
`
`:\!/herein Subsequent Components l\re Processed 'Nithout Re Identifying Components. This
`
`application claims the benefit of the follmving applications for all purposes including but not
`
`limited to the right of priority and benefit of earlier filing date, and mcpressly incorporates by
`
`reference the entire content of the follo1tving applications for all purposes: U.S. patent application
`
`Ser. No. 10/636,314; and U.S. patent application Ser. No. 09/474,664 the disclosures of each of
`
`the above-referenced applications are incorporated by reference herein in their entireties.
`
`Page 2 of 21
`
`Juniper Ex. 1004-p. 2
`Juniper v Implicit
`
`

`

`IN THE CLAIMS:
`
`The following is a current listing of claims and will replace all prior versions and listings
`
`of claims in the application. Please amend the claims as follows:
`
`1-25. (Canceled)
`
`26.
`
`(New) An apparatus, comprising:
`
`a processing unit; and
`
`a memory storing instructions executable by the processing unit to:
`
`create, based on an identification of information in a packet of a message, a path
`
`that includes a sequence of routines for processing packets in the message; and
`
`process packets in the message using the sequence of routines in the created path,
`
`wherein the sequence includes a routine that is used to execute a Transmission Control Protocol
`
`(TCP) to convert packets having a TCP format into a different format.
`
`27.
`
`(New) The apparatus of claim 26, wherein the sequence includes:
`
`a second routine that is used to execute a second, different protocol to convert packets of the
`
`different format into another format; and
`
`a third routine that is used to execute a third, different protocol to further convert the
`
`packets.
`
`28.
`
`(New) The apparatus of claim 27, wherein the second protocol is an Internet Protocol (IP)
`
`and the third protocol is an Ethernet Protocol.
`
`29.
`
`(New) The apparatus of claim 26, wherein the memory stores instructions executable by
`
`the processing unit to maintain state information associated with one or more routines in the
`
`sequence of routines, and wherein the state information is specific to the message.
`
`30.
`
`(New) The apparatus of claim 26, wherein the sequence of routines includes a routine
`
`that is executable to process the packets without converting a format of the packets.
`
`Page 3 of 21
`
`Juniper Ex. 1004-p. 3
`Juniper v Implicit
`
`

`

`31.
`
`(New) The apparatus of claim 26, wherein the routine is not executable to convert
`
`packets having the different format, and wherein the different format is an Internet Protocol (IP)
`
`format.
`
`32.
`
`(New) The apparatus of claim 26, wherein the memory stores instructions executable by
`
`the processing unit to identify an address associated with the information, wherein the address
`
`indicates the routines in the sequence of routines of the created path.
`
`33.
`
`(New) A non-transitory, computer-readable medium comprising software instructions for
`
`processmg a message, wherein the software instructions, when executed, cause a computer
`
`system to:
`
`obtain information from an initial packet of the message;
`
`use the obtained information to identify an address comprising a list of conversion
`
`routines;
`
`create a path that includes a sequence of sessions, wherein sessions in the sequence
`
`include respective ones of the conversion routines in the list;
`
`store the created path; and
`
`process packets of the message by routing packets through sessions in the created path,
`
`including:
`
`a session in which a transport layer protocol is executed to convert packets in a
`
`transport layer format into a different format; and
`
`another session in which a different protocol corresponding to the different format
`
`is executed.
`
`34.
`
`(New) The medium of claim 33, wherein one or more of the sessions comprises state
`
`information for one or more of the conversion routines, and wherein the state information is
`
`specific to the message.
`
`35.
`
`(New) The medium of claim 33, wherein the different protocol is associated with a layer
`
`selected from the group consisting of an application layer and a network layer.
`
`Page 4 of 21
`
`Juniper Ex. 1004-p. 4
`Juniper v Implicit
`
`

`

`36.
`
`(New) The medium of claim 33, wherein at least one of the routines associated with at
`
`least one of the sessions is not used to convert the packets.
`
`37.
`
`(New) The medium of claim 33, wherein the transport layer protocol is a Transmission
`
`Control Protocol (TCP).
`
`38.
`
`(New) The medium of claim 37, wherein the message comprises a stream of data.
`
`39.
`
`(New) The medium of claim 33, wherein using the obtained information to identify the
`
`address includes determining a plurality of protocols by analyzing headers of the initial packet,
`
`and wherein the plurality of protocols includes protocols executable at the transport layer and an
`
`application layer.
`
`40.
`
`(New) The medium of claim 33, wherein the different format is not compatible with the
`
`transport layer protocol, and wherein the different format is a network layer format.
`
`41.
`
`(New) An apparatus, comprising:
`
`a processing unit; and
`
`memory storing instructions that are executable by the processing unit to:
`
`obtain and analyze information from a packet of a message;
`
`identify an address based on the obtained information, wherein the address comprises a
`
`list of routines;
`
`create a sequence of sessions, wherein sessions in the sequence are associated with
`
`respective ones of the routines in the list; and
`
`process packets of the message using the sequence, wherein one of the sessions in the
`
`sequence is associated with a particular routine that is used to execute a protocol to convert the
`
`packets from an input format to an output format, wherein the particular routine is not executable
`
`to convert packets having the output format.
`
`42.
`
`(New) The apparatus of claim 41, wherein a different session is associated with a
`
`different routine that is used to execute a second, different protocol to convert the packets from
`
`the output format to a different output format, and wherein another session is associated with
`
`Page 5 of 21
`
`Juniper Ex. 1004-p. 5
`Juniper v Implicit
`
`

`

`another routine that is used to execute a third, different protocol corresponding to the different
`
`output format.
`
`43.
`
`(New) The apparatus of claim 42, wherein the protocols include a Transmission Control
`
`Protocol (TCP), an Internet Protocol (IP), and an Ethernet Protocol.
`
`44.
`
`(New) The apparatus of claim 41, wherein at least one of the sessions is associated with a
`
`routine that is executable to process packets of the message without converting the packets.
`
`45.
`
`(New) The apparatus of claim 41, wherein the particular routine is executable to convert
`
`packets by removing an outermost header of the packets.
`
`46.
`
`(New) The apparatus of claim 41, wherein the protocol is a transport layer protocol.
`
`47.
`
`(New) The apparatus of claim 46, wherein the transport layer protocol is a Transmission
`
`Control Protocol (TCP), and wherein the message comprises a stream of data.
`
`48.
`
`(New) The apparatus of claim 41, wherein the obtained information includes information
`
`from headers of the packet that are associated with a network layer and a transport layer.
`
`49.
`
`(New) The apparatus of claim 48, wherein the memory stores instructions executable by
`
`the processing unit to maintain state information associated with one or more routines in the
`
`sequence of sessions, and wherein the state information is specific to the message.
`
`50.
`
`(New) A non-transitory, computer-readable medium comprising program instructions
`
`executable by a computer system to:
`
`identify information from different headers associated with various layers of a packet of a
`
`message;
`
`create, using the identified information, a sequence of sessions of routines; and
`
`process packets of the message, including by removing an outermost header of a given
`
`packet using a first session corresponding to a protocol in a first layer and by removing the
`
`resulting outermost header using a second session corresponding to a different protocol in a
`
`different layer.
`
`Page 6 of 21
`
`Juniper Ex. 1004-p. 6
`Juniper v Implicit
`
`

`

`51.
`
`(New) The medium of claim 50, wherein the protocol in the first layer is a Transmission
`
`Control Protocol (TCP), and the message comprises a stream of data.
`
`52.
`
`(New) The medium of claim 50, wherein the protocol in the first layer is a transport layer
`
`protocol and the different protocol in the different layer is an application layer protocol.
`
`53.
`
`(New) The medium of claim 50, wherein processing packets of the message further
`
`includes removing the resulting outermost header using a third session corresponding to another
`
`protocol in another layer, and wherein the layers include a network layer, a transport layer, and
`
`an application layer.
`
`54.
`
`(New) The medium of claim 50, wherein at least one of the routines associated with at
`
`least one of sessions is not used to remove a header of the packets.
`
`55.
`
`(New) The medium of claim 50, wherein the outermost header has a format that is
`
`incompatible with a format of the resulting outermost header, and wherein the outermost header
`
`is associated with a network layer protocol.
`
`Page 7 of 21
`
`Juniper Ex. 1004-p. 7
`Juniper v Implicit
`
`

`

`REMARKS:
`
`Claims 1-25 were pending in this application. Claims 1-25 have been canceled. Claims
`
`26-55 have been added. Therefore, claims 26-55 are now pending in this application.
`
`Reexaminations of Related Cases
`
`Three reexaminations have been filed against cases related to the present case.
`
`In
`
`reexamination Control No. 90/010,356, ex parte reexamination was ordered on January 17, 2009,
`
`against U.S. Patent No. 6,629,163, which issued from the great-grandparent application of the
`
`present case. That reexamination largely concerned the reference "Scout: A Path-Based
`
`Operating System" by David Mosberger. In that proceeding, Patent Owner amended the claims
`
`to distinguish over Mosberger, resulting in a reexamination certificate being issued for the '163
`
`patent on June 22, 2010.
`
`In reexamination Control No. 95/000,659, inter partes reexamination was ordered against
`
`the '163 patent on April 3, 2012. Rejections in that proceeding, which is still pending, are
`
`largely based on the reference "Router Plugins: A Software Architecture for Next Generation
`
`Routers," by Dan Decasper et al. Similarly, in reexamination Control No. 95/000,660, an inter
`
`partes reexamination was ordered on May 10, 2012, for U.S. Patent No. 7,711,857, which issued
`
`from a continuation of the grandparent of the present application. Rejections in that proceeding,
`
`which remains pending, are also based on Decasper.
`
`Applicant plans to submit an Information Disclosure Statement in this application that
`
`includes Mosberger, Decasper, and other references from the above-noted reexaminations and
`
`the related litigations. The claims in this application are believed to distinguish over Mosberger
`
`and Decasper for at least the reasons set forth below.
`
`Page 8 of 21
`
`Juniper Ex. 1004-p. 8
`Juniper v Implicit
`
`

`

`

`

`

`

`See id. As its prototype suggests, a path is created by invoking the "pa thCrea te" software
`function on a module "m" with an attribute set1 "a." See id. Notably, the "pa thCrea te"
`
`software function does not take a message as a parameter, showing that the paths are created
`
`independently of the messages. See id.
`
`The "pa thCrea te" software function eventually invokes the "ere a teStage"
`
`software function, which has the following prototype:
`
`Stage
`
`(*CreateStageFunc)
`
`(Module m,
`
`int s, Attrs a, ModuleLink*
`
`n);
`
`See Mosberger at 80. This prototype shows that the parameters for the "createStage"
`
`software function are a module "m," a service index "s," a set of attributes "a," and a pointer
`
`"ModuleLink*" to the service index of the next stage in the path. See id. Like the
`
`"pa thCrea te" software function, the "ere a teStage" function also does not have an input
`
`parameter for a message, which further shows that the stages are created without regard to the
`
`particular messages. See id.
`
`The end result of invoking the "pa thCrea te" software function is that Scout will
`
`create a set of paths comprising various sequences of modules. See Mos berger at 81 ("At this
`
`point, the pa thCrea te function creates the actual path object, inserts the stages into it, and
`
`establishes the various chains through the path structure"). The knowledge of which modules to
`
`connect together is complied into the Scout kernel at compile time. This knowledge does not
`
`exist outside of the modules themselves. Importantly, this set of paths is finite; Mos berger does
`
`not teach creation of new paths after initialization. See id.
`
`The next section of Mosberger (Section 3.4), entitled "Demultiplexing," describes how to
`
`select the appropriate path from amongst the finite set of previously-created paths based on the
`
`contents of a particular message. See Mosberger at 85-99. This point is underscored by the first
`
`sentence of section 3.4: "So far, we have not discussed the issue of how the appropriate path is
`
`found for a given message." See id. at 85 (emphasis added). This sentence unequivocally
`
`establishes that the prior sections of Mosberger regarding creating paths are limited to "path
`
`creation" and do not relate to selecting ( or "finding") the appropriate (predefined) path for a
`
`particular message. See id.
`
`Instead, Section 3.4 teaches for the first time in Mosberger that,
`
`1 "The attribute set describes the kind of path that is desired. That is, the invariants ... are passed in this set."
`Mosberger at 80.
`
`Page 11 of 21
`
`Juniper Ex. 1004-p. 11
`Juniper v Implicit
`
`

`

`upon the receipt of a message, Scout uses a demultiplexing process to find the correct
`
`previously-created path to process the message. See id. at 85-92 ("a packet classifier that factors
`
`all demultiplexing operations . . . lets Scout pick a path and start processing a packet. .. " and "a
`
`classifier to decide whether a packet should be processed using path pl, p2, or p3"). Thus,
`
`Mosberger does not teach or suggest "instructions executable by [a] processing unit to: create,
`
`based on an identification of information in a packet of a message, a path that includes a
`
`sequence of routines for processing packets in the message" as recited in claim 26 ( emphasis
`
`added). Rather, Mosberger teaches that when a message is received, a path is selected (or
`
`"found" or "picked") from a set of possible paths, which were created before the message was
`
`received. See id. The "path" of claim 26, on the other hand, is "create[ d]" "based on an
`
`identification of information in a packet of a message"-in other words, after a packet of the
`
`message exists and is received.
`
`For at least the reasons given above, Applicant respectfully submits that Mosberger does
`
`not teach or suggest the combination of features recited in claim 26. Accordingly, Applicant
`
`submits that claim 26 and its dependent claims are patentably distinct over Mosberger. Claims
`
`33, 41, and 50 include features that are similar to the features recited in claim 26. Thus,
`
`Applicant submits claims 33, 41, and 50, along with their respective dependent claims, are
`
`patentably distinct over Mosberger for at least the reasons given above.
`
`Page 12 of 21
`
`Juniper Ex. 1004-p. 12
`Juniper v Implicit
`
`

`

`Decasper
`
`As described in detail below, Decasper includes an "IP core" that uses modules called
`
`"plugins" to operate on IP packets. Decasper therefore does not teach or suggest a path having a
`
`sequence of routines, "wherein the sequence includes a routine that is used to execute a
`
`Transmission Control Protocol (TCP) to convert packets having a TCP format into a different
`
`format," as recited in claim 26. Because Decasper operates on IP packets only ( and thus
`
`executes the IP protocol but not other protocols), that reference does not teach or suggest
`
`"process[ing] packets of [a] message, including by removing an outermost header of a given
`
`packet using a first session corresponding to a protocol in a first layer and by removing the
`
`resulting outermost header using a second session corresponding to a different protocol in a
`
`different layer."
`
`Decasper Overview
`
`Decasper is directed to "a high performance, modular, extended integrated services router
`software architecture." Decasper at § 1 (p. 1, first col., ,i 1 ).2 Decasper states that "In the past,
`
`the main task of a router was to simply forward packets based on a destination address lookup."
`
`Id. at§ 2 (p. 1, first col., ,i 3). This type of traditional router implementation is shown in the left
`
`half of Figure 1 of Decasper, which is reproduced below.
`
`In this "Monolit[h]ic Best-Effort
`
`Architecture," packets are shown as being received from the "Net" (i.e., the Internet), processed
`
`according to an Internet Protocol (specifically IPv4), and output back onto the "Net." See id. at
`
`Fig. 1. This prior art router architecture can thus be understood to execute an IP protocol in
`
`order to route packets to other locations in a network such as the Internet. Notably, the diagram
`
`in the left half of Decasper' s Figure 1 does not disclose that these prior art routers execute any
`
`type of networking protocols other than IP ( e.g., TCP).
`
`2 Decasper does not include page numbers. The primary citations to this reference are given by section number(§),
`with parenthetical citations by page number, column, and paragraph number. In determining paragraph numbers,
`each bullet point is considered a separate paragraph. Additionally, a split paragraph that begins a column is
`considered the first paragraph for that column.
`
`Page 13 of 21
`
`Juniper Ex. 1004-p. 13
`Juniper v Implicit
`
`

`

`

`

`

`

`Figure 2 also depicts four plugins. The IPOPT plugin "implement[s] IPv6 options," the
`
`PS plugin performs "packet scheduling," the BMP plugin "calculate[s] the best-matching prefix
`
`... used for packet classification and routing" and the IPSEC plugin is "for IP security." See
`Decasper at § 3.1 (p. 4, first col., ,i 1). Decasper uses a "packet classification algorithm" that
`
`"efficiently maps packets to code modules (plugins)." Id. at§ 2 (p. 2, second col., ,i 6). As will
`
`be discussed in further detail below, Decasper's method of mapping a packet to a plugin requires
`
`the presence of an IP header in order to perform the classification. Accordingly, it follows that
`
`each of the plugins disclosed in Decasper operates on an IP packet (i.e., a packet with an IP
`
`header). This conclusion makes sense given that the process of mapping a packet to one or more
`
`plugins is initiated by different points (referred to as "gates") within the IP core. Stated another
`
`way, it would be expected that plugins called from different points in the control path that
`
`implements an Internet Protocol would operate on IP packets.
`
`Decasper 's Packet Classification Scheme
`
`Decasper discloses that "[i]nstances of plugins can be created, configured, and bound to
`
`specific flows" (i.e., a group of related packets). Decasper at § 2 (p. 2, first col., ,i 2) ( emphasis
`
`in original). Specifically, the Association Identification Unit (AIU) shown in Figures 2 and 3
`
`"implements an innovative algorithm for packet classification which efficiently maps packets to
`
`code modules (plugins)." Id. at§ 2 (p. 2, second col., ,i 6). The mapping between a packet and a
`
`plugin is governed by a "filter," which Decasper discloses is specified by the following "six(cid:173)
`
`tuple":
`
`<source address, destination address, protocol, source port, destination port, incoming interface>.
`
`Id. at§ 5.1 (p. 7, first col., ,i 6). Values in a six-tuple field may include a wildcard character (a
`
`"*"), indicating that any value is acceptable for filter-matching purposes. See id. § 3 (p. 3,
`
`second col., ,i 1). Thus, one filter may be specified by source address 129.132.*, with the
`
`remaining tuple values being wildcards.
`
`In such an example, any flow from source address
`
`129.132. * will be mapped to the plugin specified by that filter. See Decasper at Fig. 3 (first filter
`
`table entry, which is mapped to IPSEC plugin "SEC2").
`
`Page 16 of 21
`
`Juniper Ex. 1004-p. 16
`Juniper v Implicit
`
`

`

`

`

`Figure 3, a packet having the six tuple (129.133.50.50.2, 128.252.50.21, TCP, 1234, 25, 0) maps
`
`to the following plugins: SECI, PSI, RTI, OPTI.
`
`If there is no cached entry in a flow table, a filter table is accessed and "the resulting
`
`plugin instance pointer is returned to the calling gate." See Decasper at§ 3.2 (p. 5, second col., ,i
`
`7) (description of step 3 depicted in Fig. 3). The gate then "calls the plugin instance, passing the
`
`packet as an argument." Id. This process is repeated at each gate in the IP core for a given
`
`packet. See id. at§ 3.2 (p. 5, second col., ,i 11) (description of step 7 depicted in Fig. 3). Figure
`
`3 depicts a separate filter table for each of four types of plugins: IP SEC, PS, BMP, IPOPT. See
`
`id. at Fig. 3. Instance pointers accessed from the filter table are cached in the flow table. See id.
`
`at§ 3.2 (p. 5, second col., ,i 8) (description of step 4 depicted in Fig. 3). Subsequently, "[w]hen
`
`a packet from a cached flow encounters the first gate" in the IP core, a "pointer to the [plugin]
`
`instance requested is already in the flow table." See id. at § 3.2 (p. 6, first col., ,i 3). "No filter
`
`table lookups are required." See id.
`
`Decasper 's Packet Classification Requires IP Packet Headers
`
`As described above, Decasper uses both filter tables and flow tables to classify packets.
`
`With respect to filter table implementations (used for finding the appropriate plugin when a
`
`packet for an uncached flow reaches a gate in the IP core), Decasper "requires packets to be
`
`classified based upon the same five packet header fields and the interface on which the packet
`
`was received." See Decasper at § 5 .1 (p. 7, first col., ,i 6). This six tuple includes the source
`
`address and destination address of the packet-information that is located in both IPv4 and IPv6
`
`headers. Internet Protocol RFC 791, 11 (Jon Postel ed., September 1981) (included in an IDS
`
`submitted with this response). Similarly, Decasper's flow table implementation also uses the
`
`source and destination IP addresses from the packet to calculate the hash index used to perform
`
`the lookup function. See id. at§ 3.2 (p. 5, second col., ,i 8) (description of step 4 depicted in Fig.
`3), § 5.2 (p. 9, first col., ,i 1, 2). Decasper emphasizes that all tuple values used to look up a filter
`
`in the flow table are fully specified-that is, no wildcards. See id. at§ 3.2 (p. 5, second col., ,i 8)
`
`( description of step 4 depicted in Fig. 3). Given the use of IP header information to implement
`
`both filter table and flow table lookups, Decasper does not contemplate classifying packets other
`
`than IP packets. For example, nothing in Decasper contemplates processing a non-IP packet
`
`format such as a TCP packet, since such headers do not have the source and destination IP
`
`Page 18 of 21
`
`Juniper Ex. 1004-p. 18
`Juniper v Implicit
`
`

`

`addresses needed for Decasper's packet classification scheme. 4 Because each gate in Decasper's
`
`IP core must receive an IP packet in order to perform such classification, it follows that
`
`Decasper's plugins do not convert an IP packet into a non-IP format (e.g., a TCP format). An
`
`initial gate in Decasper' s IP core, for example, must produce an output packet that can be
`
`processed by a subsequent gate. If the plugin tied to the initial gate in Decasper's IP core
`
`removed the IP header portion of a packet, for example, the resulting output packet would not be
`
`able to be classified at the subsequent gate. The conclusion that Decasper contemplates
`
`processing only IP packets is consistent with Decasper's implementation of an IP router using an
`
`IP core that executes an IP protocol.
`
`Claim 26
`
`Given the preceding discussion, Applicant submits that Decasper does not teach or
`
`suggest "process[ ing] packets in the message using [a] sequence of routines in the created path,
`
`wherein the sequence includes a routine that is used to execute a Transmission Control
`
`Protocol (TCP) to convert packets having a TCP format into a different format," as recited
`
`in claim 26.
`
`Assuming arguendo that Decasper's plugins or flows correspond to the "sequence of
`
`routines" of claim 26 (which Applicant does not concede), Decasper does not teach or suggest
`
`that any of the plugins operates on "packets having a TCP format" let alone "convert[ing]" such
`
`packets "into a different format," as recited in that claim. Rather, as discussed at length above,
`
`Decasper' s packet classification scheme relies on IP headers remaining with packets throughout
`
`the IP core. For at least these reasons, Applicant respectfully submits that Decasper does not
`
`teach or suggest the combination of features recited in claim 26. Accordingly, Applicant submits
`
`that claim 26 and its dependent claims are patentably distinct over Decasper. Independent claims
`
`33 and 41 include features that are similar to those recited in claim 26. Thus, Applicant submits
`
`4 Additionally, it is well known that the Transmission Control Protocol (TCP) is implemented at the endpoints of a
`connection. Decasper, on the other hand, discloses a router architecture that stands in contrast to "modular end(cid:173)
`system networking subsystems." See Decasper § 2 (p. 2, second col., ,r 5). Accordingly, the fact that Decasper
`refers to a plugin that can monitor "TCP congestion backoffbehavior," see id. § 3 (p. 4, first col., ,r 1 ), does not refer
`to a plugin that executes the TCP protocol (i.e., operates on a packet whose outermost header is a TCP header).
`Given the discussion ofDecasper's classification scheme provided above, plugins in Decasper's routing architecture
`operate on IP packets. The monitoring of TCP congestion backoffbehavior in Decasper can thus be considered akin
`to the statistics gathering functions of other disclosed plugins, and not as the implementation of the TCP protocol.
`
`Page 19 of 21
`
`Juniper Ex. 1004-p. 19
`Juniper v Implicit
`
`

`

`claims 33 and 41, along with their respective dependent claims, are patentably distinct over
`
`Decasper for at least reasons similar to those provided in support of claim 26.
`
`Claim 50
`
`With respect to claim 50, Applicant submits that Decasper does not teach or suggest
`
`"process[ing] packets of the message, including by removing an outermost header of a given
`
`packet using a first session corresponding to a protocol in a first layer and by removing the
`
`resulting outermost header using a second session corresponding to a different protocol in a
`
`different layer." Each of the gates in Decasper operates on a packet having an IP header. In fact,
`
`as explained above, Decasper's gates rely on the presence of IP headers in the packets to
`
`properly classify the packets.
`
`It therefore follows that Decasper's plugins do not operate to
`
`"remov[ e] an outermost header of a given packet" and "remov[ e] the resulting outermost
`
`header." Further, Decasper does not teach or suggest "using a second session corresponding to a
`
`different protocol" to "remov[ e] the resulting outermost header" at least because Decasper does
`
`not teach sessions corresponding to different protocols.
`
`For at least the reasons given above, Applicant respectfully submits that Decasper does
`
`not teach or suggest the combination of features recited in claim 50. Accordingly, Applicant
`
`submits that claim 50 and its dependent claims are patentably distinct over Decasper.
`
`Page 20 of 21
`
`Juniper Ex. 1004-p. 20
`Juniper v Implicit
`
`

`

`CONCLUSION
`
`Applicants submit the application is in condition for allowance, and an early notice to
`
`that effect is requested.
`
`The Commissioner is authorized to charge any fees that may be required, or credit any
`
`overpayment, to Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. Deposit Account No.
`
`501505/6743-00105/DMM.
`
`Date: June 6, 2013
`
`Respectfully submitted,
`
`By: /Dean M. Munyon/
`Dean M. Munyon
`Reg. No. 42,914
`
`Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C.
`P. 0. Box 398
`Austin, Texas 78767
`(512) 853-8847
`
`Page 21 of 21
`
`Juniper Ex. 1004-p. 21
`Juniper v Implicit
`
`

`

`Electronic Patent Application Fee Transmittal
`
`Application Number:
`
`Filing Date:
`
`Title of Invention:
`
`METHOD AND SYSTEM FOR DATA DEMULTIPLEXING
`
`First Named Inventor/Applicant Name:
`
`Edward Balassanian
`
`Filer:
`
`Dean M. Munyon/Deena Beasley
`
`Attorney Docket Number:
`
`6743-00105
`
`Filed as Large Entity
`
`Track I Prioritized Examination - Non provisional Application under 35 USC 111 (a) Filing Fees
`
`Description
`
`Fee Code
`
`Quantity
`
`Amount
`
`Sub-Total in
`USO($)
`
`Basic Filing:
`
`Pages:
`
`Claims:
`
`Utility application filing
`
`Utility Search Fee
`
`Utility Examination Fee
`
`Request for Prioritized Examination
`
`Claims in Excess of 20
`
`Independent claims in excess of 3
`
`1011
`
`1111
`
`1311
`
`1817
`
`1202
`
`1201
`
`1
`
`1
`
`1
`
`1
`
`10
`
`1
`
`280
`
`600
`
`720
`
`280
`
`600
`
`720
`
`4000
`
`4000
`
`80
`
`420
`
`800
`
`420
`
`Juniper Ex. 1004-p. 22
`Juniper v Implicit
`
`

`

`Description
`
`Fee Code
`
`Quantity
`
`Amount
`
`Sub-Total in
`USO($)
`
`Miscellaneous-Filing:
`
`Publ. Fee- Early, Voluntary, or Normal
`
`OTHER PUBLICATION PROCESSING FEE
`
`1504
`
`1808
`
`1
`
`1
`
`300
`
`130
`
`300
`
`130
`
`Petition:
`
`Patent-Appeals-and-Interference:
`
`Post-Allowance-and-Post-Issuance:
`
`Extension-of-Time:
`
`Miscellaneous:
`
`Total in USD ($)
`
`7250
`
`Juniper Ex. 1004-p. 23
`Juniper v Implicit
`
`

`

`Electronic Acknowledgement Receipt
`
`EFSID:
`
`Application Number:
`
`15966847
`
`13911324
`
`International Application Number:
`
`Confirmation Number:
`
`4969
`
`Title of Invention:
`
`METHOD AND SYSTEM FOR DATA DEMULTIPLEXING
`
`First Named Inventor/Applicant Name:
`
`Edward Balassanian
`
`Customer Number:
`
`35690
`
`Filer:
`
`Dean M. Munyon/Deena Beasley
`
`Filer Authorized By:
`
`Dean M. Munyon
`
`Attorney Docket Number:
`
`6743-00105
`
`Receipt Date:
`
`06-JUN-2013
`
`Filing Date:
`
`Time Stamp:
`
`13:33:41
`
`Application Type:
`
`Utility under 35 USC 111 (a)
`
`Payment information:
`
`Submitted with Payment
`
`Payment Type
`
`Payment was successfully received in RAM
`
`RAM confirmation Number
`
`Deposit Account
`
`Authorized User
`
`yes
`
`Credit Card
`
`$7250
`
`11345
`
`501505
`
`MUNYON, DEAN M.
`
`The Director of the USPTO is hereby authorized to charge indicated fees and credit any overpayment as follows:
`
`Charge any Additional Fees required under 37 C.F.R. Section 1.16 (National application filing, search, and examination fees)
`
`Charge any Additional Fees required under 37 C.F.R. Section 1.17 (Patent application and reexamination processing fee