Transmittal of Communication to
`Third Party Requester
`Inter Partes Reexamination
`
`Control No.
`
`95/000,659
`Examiner
`
`_ SALMAN AHMED
`
`Patent Under Reexamination
`
`6629163
`Art Unit
`
`3992
`
`-- The MAILING DATE of this communication appears on the cover sheet with the correspondence address. —
`
`r--- (THIRD PARTY REQUESTER'S CORRESPONDENCE ADDRESS)
`
`IRELL & MANELLA, LLP
`DAVID MCPHIE
`840 NEWPORT CENTER DR., STE 400
`NEWPORT BEACH, CA 92660
`
`MO .0
`An 16 2.
`013
`
`REExAm
`
`Enclosed is a copy of the latest communication from the United States Patent and Trademark Office
`in the above-identified reexamination prceeding. 37 CFR 1.903.
`
`Prior to the filing of a Notice of Appeal, each time the patent owner responds to this communication,
`the third party requester of the inter partes reexamination may once file written comments within a
`period of 30 days from the date of service of the patent owner's response. This 30-day time period is
`statutory (35 U.S.C. 314(b)(2)), and, as such, it cannot be extended. See also 37 CFR 1.947.
`
`If an ex parte reexamination has been merged with the inter partes reexamination, no responsive
`submission by any ex parte third party requester is permitted.
`
`All correspondence relating to this inter partes reexamination proceeding should be directed to the
`Central Reexamination Unit at the mail, FAX, or hand-carry addresses given at the end of the
`communication enclosed with this transmittal.
`
`U.S. Patent and Trademark Office
`PTOL-2070 (Rev. 07-04)
`
`Paper No. 20130718
`
`Juniper Ex. 1018-p. 1
`Juniper v Implicit
`
`(cid:9)
`

`

`OFFICE ACTION IN INTER PARTES
`REEXAMINATION
`
`Control No.
`
`95/000,659
`Examiner
`
`_ SALMAN AHMED
`
`Patent Under Reexamination
`
`6629163
`Art Unit
`
`3992
`
`-- The MAILING DATE of this communication appears on the cover sheet with the correspondence address. —
`
`Responsive to the communication(s) filed by:
`Patent Owner on 03 December, 2012
`Third Party(ies) on 02 January, 2013
`
`RESPONSE TIMES ARE SET TO EXPIRE AS FOLLOWS:
`
`For Patent Owner's Response:
`2 MONTH(S) from the mailing date of this action. 37 CFR 1.945. EXTENSIONS OF TIME ARE
`GOVERNED BY 37 CFR 1.956.
`For Third Party Requester's Comments on the Patent Owner Response:
`30 DAYS from the date of service of any patent owner's response. 37 CFR 1.947. NO EXTENSIONS
`OF TIME ARE PERMITTED. 35 U.S.C. 314(b)(2).
`
`All correspondence relating to this inter partes reexamination proceeding should be directed to the Central
`Reexamination Unit at the mail, FAX, or hand-carry addresses given at the end of this Office action.
`
`This action is not an Action Closing Prosecution under 37 CFR 1.949, nor is it a Right of Appeal Notice under
`37 CFR 1.953.
`
`PART I. THE FOLLOWING ATTACHMENT(S) ARE PART OF THIS ACTION:
`
`1. q Notice of References Cited by Examiner, PTO-892
`2.Z Information Disclosure Citation, PTO/SB/08
`
`3. q (cid:9)
`PART II. SUMMARY OF ACTION:
`1a. El Claims 1,15 and 35 are subject to reexamination.
`1 b. q Claims
`are not subject to reexamination.
`q Claims
`have been canceled.
`2.
`q Claims (cid:9)
`3.
`are confirmed. [Unamended patent claims]
`q Claims (cid:9)
`4.
`are patentable. [Amended or new claims]
`5. Z Claims 1,15 and 35 are rejected.
`q Claims (cid:9)
`6.
`are objected to.
`q The drawings filed on
`(cid:9) q are acceptable (cid:9) q are not acceptable.
`7.
`q The drawing correction request filed on (cid:9)
`q approved.
`q disapproved.
`8.
` is:
`q Acknowledgment is made of the claim for priority under 35 U.S.C. 119 (a)-(d). The certified copy has:
`9.
`q been received. (cid:9) q not been received. (cid:9) q been filed in Application/Control No 95000659.
`10. q Other (cid:9)
`
`
`U.S. Patent and Trademark Office
`PTOL-2064 (08/06)
`
`Paper No. 20130718
`
`Juniper Ex. 1018-p. 2
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 2
`
`DETAILED ACTION
`
`In view of the petition decision of July 12, 2013, prosecution is hereby re-opened.
`
`A non-final rejection is hereby issued.
`
`Reexamination History
`
`• U.S. Patent No. 6,629,163 ["the '163 patent"] issued on September 30, 2003.
`
`• An ex parte reexamination certificate "C1" was issued for the ' 163 patent on
`
`June 22, 2010.
`
`• A request for inter partes reexamination was filed February 13, 2012 and
`
`assigned control no. 95/000,659. Reexamination was requested of claims 1, 15
`
`and 35 of the '163 patent.
`
`•
`
`In an order mailed April 3, 2012 ["Order"], the inter partes request was granted-
`
`in-part and denied-in-part. Overall, the examiner granted the request as to claims
`
`1,15 and 35.
`
`• A first action on the merits was mailed concurrently with the Order.
`
`• On May 3, 2012, the third party requester timely filed a petition requesting
`
`reconsideration of the denial of portions of the request.
`
`• An action closing prosecution was mailed on October 1, 2012.
`
`Petition Decision
`
`• On July 12, 2013, the petition was granted-in-part with the following:
`
`Juniper Ex. 1018-p. 3
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 3
`
`1. Based on a de novo review of the record as a whole, the petition is granted-in-cart.
`
`2. The proposed rejections of claims 1, 15 and 35 corresponding to Issues 16 (for claims 15 and
`35), 17-26, 28, 30 (for claims 15 and 35) and 31-40 are determined to raise a RLP and are subject
`to reexamination for resolution of the question of anticipation/obviousness by the subject prior-
`art references. The examiner must determine in the next Office action whether to adopt the
`proposed rejections.
`
`3, The proposed rejections of claims 1, 15 and 35 corresponding to Issue 27 are determined 1191
`to raise a RLP.
`
`4. The proposed rejections of claims 1, 15 and 35 corresponding to Issues 2-14, 41-43, 45 and
`46 are determined not to raise a RLP.
`
`5. The proposed rejections of claim 1 corresponding to Issues 15 and 29 are determined not to
`raise a RLP.
`
`5. This decision is final and non-appealable. Set 35 U.S.C. § 312(c) and 37 (cid:9)
`communication on this matter will be acknowledged or considered.
`
`§ 1.927. No
`
`Therefore, as mandated by the above petition decision, this Office action
`
`addresses issues 16 (for claims 15 and 25), 17-26, 28, 30 (for claims 15 and 35) and
`
`31-40 in addition to the issues that were already addressed in the Office action dated
`
`10/1/2012.
`
`In addition to the petition-decision, this Office action further addresses claims 1,
`
`15 and 35 of United States Patent No. 6,629,163 (Balassanlan, Edward) in response to
`
`Patent Owner (hereinafter PO) response dated 12/3/2012 and Third Party Comment
`
`dated 1/2/2013 for inter partes reexamination.
`
`information Disclosure Statement
`
`1. (cid:9)
`
`The information disclosure statements (IDS) have been considered by the
`
`examiner to the extent that they have been explained in the submissions.
`
`Juniper Ex. 1018-p. 4
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 4
`
`2. (cid:9)
`
`Original claims 1, 15 and 35 are rejected.
`
`Status of the Claims
`
`Response to Arguments
`
`III. B. Decasper in view of Message Limitations:
`
`Patent Owner's Argument (pages 16-18):
`
`Patent Owner argues that Decasper never mentions, much less teaches, the
`
`concept of processing messages. Nothing in the ACP overcomes these deficiencies.
`
`Page 94 of the ACP discusses the "flows" in Decasper and concludes that a "flow would
`
`comprise a 'message' under Implicit's apparent claim constructions. See section IV.C."
`
`Section IV.0 appears to be a reference to the table at page 22 of Junipers request for
`
`reexamination, which includes the following proposed construction for messages: "A
`
`collection or stream of data that is related in some way." This language is similar to the
`
`construction that the court adopted in its Markman order and is also similar to the
`
`language in col. 2, 11.45-47 of the ' 163 Patent. But the "flows" on which the ACP relies
`
`are not messages under Implicit's proposed litigation construction for one simple
`
`reason: such flows, as seen by the Decasper router, are not guaranteed to include all
`
`the packets of a message. The words "collection" and "stream" on their face suggest
`
`that a message includes the entire set of packets (e.g., all the packets associated with a
`
`TCP session that defines the stream). The language does not qualify these terms by
`
`stating that they are "partial collections" or "partial streams," as one would expect to see
`
`Juniper Ex. 1018-p. 5
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 5
`
`in a router that receives fewer than all the packets in a message. In addition, the
`
`language "data that is related in some way" corroborates Patent Owner's position
`
`because it requires a relationship between the packets that make up the collection or
`
`stream. If fewer than all packets are present, such as in an IP router, then part of the
`
`relationship is missing. The express claim language further supports Patent Owner's
`
`position that a message includes all of the packets. For example, claim 15 requires
`
`"each packet of each message," meaning all packets of that message. Moreover, the
`
`Federal Circuit has long held that claim terms must be construed consistent with the
`
`specification. In re Morris', 127 F.3d 1048, 1054 (Fed. Cir. 1997); see also Phillips v.
`
`AWH Corp., 415 F.3d 1303, 1316-17 (Fed. Cir. 2005). And the specification is
`
`abundantly clear that all packets are required to form a message. For instance, the ' 163
`
`specification states that 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).
`
`Requester's Comments (pages 21-28:
`
`In response, Requester submits that Decasper98 plainly processes '"message[s]"
`
`under the broadest reasonable construction of that term. The '163 patent expressly
`
`defines "message" as follows: "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."
`
`'163 patent at 2:45-
`
`47. And this is definition from the specification is also the exact construction for
`
`"message" that the Court adopted in the concurrent litigation: "a collection of data that is
`
`Juniper Ex. 1018-p. 6
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 6
`
`related in some way, such as a stream of video or audio data or an email message."
`
`See App. R9 (Claim Construction Order of 2/29/2012) at 12-13. The Court explained the
`
`term "message" was "clearly defined in the specification" and INI had likewise concurred
`
`that "the inventor" had "act[ed] as his own lexicographer" in this instance as to the term
`
`"message." Ex. 37-C (INI's Claim Construction Reply of 12/19/2011) at 12-13. Thus, the
`
`broadest reasonable construction of "message" should at least be no narrower than this
`
`definition set forth in the specification (and adopted in the litigation proceedings).
`
`And in fact Decasper98 clearly processes "message[s}" under this construction.
`
`Decasper98 explains in a general manner that its "flows" represent "packet streams"
`
`containing data such as "audio-video." See Ex. 25 at 3 (emphasis added); Plattner Decl.
`
`'119. Thus, a Decasper98 flow is a "message" under the broadest reasonable
`
`construction, because it is a "collection of data that is related in some way" (e.g., by
`
`sharing the same six tuple of values), and because the data is data "such as a stream of
`
`video or audio data or an email message" (as evident from widely known port numbers
`
`for applications such as video, audio, email, and multi-media conferencing). Id.
`
`INI makes the circular argument that a "message" should include "the entire set
`
`of packets." Second Response at 17 (emphasis added). But the notion of an "entire set"
`
`is meaningless without defining the set, unless INI is suggesting that related packets in
`
`a "message" must not be related to any other packets in any other messages (and there
`
`is no support for this sort of negative limitation here). The claims, however, do not recite
`
`"the entire set of packets of a session," or "the entire set of packets of a TCP session,"
`
`or "the entire set of packets of a TCP connection," or "the entire set of packets as
`
`Juniper Ex. 1018-p. 7
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 7
`
`determined by some higher layer protocol." The claims recite a "message," which,
`
`according to the specification (and INI's proposed litigation construction), is merely a
`
`"collection of data that is related in some way." Indeed, at least some of the examples of
`
`a "message" expressly provided in the specification--e.g., a "stream of video or audio
`
`data"—are often transmitted using UDP rather than TCP, and so limiting the term
`
`"message" to a TCP session or related session-based protocol would appear to directly
`
`contradict the specification. Plattner Decl.
`
`INI goes on to argues the claims do not recite "partial collections" or "partial
`
`streams," as if the terms "collection" or "stream" could in themselves supply some
`
`narrower definition of completeness. Second Response at 17. However, a collection of
`
`related data does not cease to be a collection of related data when a piece of related
`
`data is added or subtracted, and a stream of audio/video data flowing through a router
`
`does not cease to be a stream of audio/video data, merely because some other device
`
`on the network may allegedly see additional audio/video packets pertaining to a related
`
`TCP session. By the same token, INI further argues that because the proper
`
`construction of "message" requires "data that is related ," then if "fewer than all packets
`
`are present.. then part of the relationship is missing". Second Response at 17-18.
`
`Again, it is not clear what INI is trying to prove with this circular argument. To use an
`
`analogy, family members at a reunion are still "related" even if one uncle happens to be
`
`absent. In the same manner, the packets of (for example) a TCP session would not
`
`cease to be "related" to each other, even if some other device on the network were to
`
`see additional packets pertaining to the same TCP session. In Decasper98
`
`Juniper Ex. 1018-p. 8
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 8
`
`specifically, the packets of a flow are "related in some way" at least because they share
`
`the same "six tuple" of values, which means they are all sent from the same source to
`
`the same destination, and in context of, e.g., the same application. See Ex. 25 at 3, 5;
`
`Plattner Decl. IT 9. This tangible relatedness between the packets (which Decasper98
`
`does see) does not disappear because some other device on the network may allegedly
`
`see additional packets pertaining to an associated TCP session. Id.
`
`INI finally attempts to argue that various phrases in the '163 patent and in
`
`Juniper's summary judgment motion filed in the concurrent litigation somehow support
`
`INI's position "that a message includes all of the packets." See Second Response at 18.
`
`But none of the phrases cited by INI supply a more specific definition of "message" that
`
`would show Decasper98 flows are incomplete. The phrases cited by INI do not recite,
`
`e.g., "each packet of each TCP session," "analyzing the first packet of a TCP session"
`
`or the "remaining packets in the TCP session." Thus, INI fails to show how a
`
`Decasper98 flow does not qualify as a "message" under the broadest reasonable
`
`construction.
`
`Thus, as Decasper98 expressly states it is "well suited" for use as an "edge
`
`router," a more typical deployment for a Decasper98-like system would be in a network
`
`topology like the one in the Plattner Decl. ¶ 9. As this diagram makes clear, a
`
`Decasper98 router in the Router 1 position would necessarily see all of the packets
`
`received by the Client, and a Decasper98 router in the Router 6 position would
`
`necessarily see all of the packets received by the Server. Id. Thus, INI's scenario in
`
`which "[t]he only devices.., that process the actual message or are even guaranteed to
`
`Juniper Ex. 1018-p. 9
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 9
`
`see all the packets of a given message are the client and server" assumes Decasper98
`
`would be positioned only in topologies like the special case contrived by INI. See
`
`Second Response at 5. INI's assumption that Decasper98 will fail to see all the packets
`
`of a "message" that are received by the Client or Server therefore fails accordingly. INI's
`
`tangential argument on this point thus fails to show a deficiency in Decasper98 itself.
`
`Accordingly, even assuming the claims were read to require receiving (for example)
`
`every single packet in a TCP session, Decasper98 would commonly be deployed as the
`
`single "edge" router between the client or server and the larger network, where it would
`
`receive every packet of such a session received by the client or server. Id.
`
`Examiner's Response:
`
`Examiner finds Requester's comments persuasive. Examiner further submits that
`
`in response to applicant's argument that the references fail to show certain features of
`
`applicant's invention, it is noted that the features upon which applicant relies (i.e., "the
`
`entire set of packets of a session," or "the entire set of packets of a TCP session," or
`
`"the entire set of packets of a TCP connection," or "the entire set of packets as
`
`determined by some higher layer protocol") are not recited in the rejected claim(s).
`
`Although the claims are interpreted in light of the specification, limitations from the
`
`specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26
`
`USPQ2d 1057 (Fed. Cir. 1993).
`
`Furthermore, in response to Patent Owner's argument regarding Markman order
`
`"[l]n PTO reexamination, the standard of proof- a preponderance of evidence — is
`
`Juniper Ex. 1018-p. 10
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 10
`
`substantially lower than in a civil case" and there is no presumption of validity in
`
`reexamination proceedings." 678 F.3d 1357, 1364 (Fed. Cir. 2012) (internal citations
`
`omitted); see also Old Reliable Wholesale, Inc. v. Cornell Corp., 635 F.3d 539, 548 n.6
`
`(Fed. Cir. 2011) ("Whereas clear and convincing evidence is required to invalidate a
`
`patent in district court, a patent can be invalidated during PTO reexamination by a
`
`simple preponderance of the evidence."). "Claims are given 'their broadest reasonable
`
`interpretation, consistent with the specification, in reexamination proceedings.'" In re
`
`Trans Texas Holding Corp., 498 F.3d 1290, 1298 (Fed. Cir. 2007) (quoting In re
`
`Yamamoto, 740 F.2d 1569, 1571 (Fed. Cir. 1984). "Giving claims the broadest
`
`reasonable construction 'serves the public interest by reducing the possibility that
`
`claims, finally allowed, will be given broader scope than is justified.'" In re Am. Acad.
`
`ofSci. Tech Ctr., 367 F.3d 1359, 1365 (Fed. Cir. 2004) (quoting Yamamoto, 740 F.2d at
`
`1571). "Construing claims broadly during prosecution is not unfair to the applicant (or, in
`
`this case, the patentee), because the applicant has the opportunity to amend the claims
`
`to obtain more precise claim coverage." In re Trans Texas Holding Corp., 498 F.3d
`
`1290, 1298 (Fed. Cir. 2007) (citing Yamamoto, 740 F.2d at 1571-72 and In re Zletz, 893
`
`F.2d 319, 322 (Fed. Cir. 1989)). "The Board is required to use a different standard for
`
`construing claims than that used by district courts." In re Am. Acad. ofSci. Tech Ctr.,
`
`367 F.3d 1359, 1369 (Fed. Cir. 2004). Indeed, the Federal Circuit has repeatedly held
`
`that "it is error for the Board to 'apply the mode of claim interpretation that is used by
`
`courts in litigation, when interpreting the claims of issued patents in connection with
`
`determinations of infringement and validity."' Id. (citing Zletz, 893 F.2d at 321); see also
`
`Juniper Ex. 1018-p. 11
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 11
`
`In re Morris, 127 F.3d 1048, 1054 (Fed. Cir. 1997) ("It would be inconsistent with the
`
`role assigned to the PTO in issuing a patent to require it to interpret the claims in the
`
`same manner as judges who, post-issuance, operate under the assumption that the
`
`patent is valid)." Instead, the PTO is empowered and "obligated to give claims their
`
`broadest reasonable interpretation during examination." Id. Thus, in the instant case
`
`"the pending claims must be interpreted as broadly as their terms reasonably allow."
`
`In
`
`re Zletz, 893 F.2d 321.
`
`Nevertheless, Decasper98 discloses
`
`1)
`
`"flows" are made-up of "data packets" (page 3):
`
`to flows
`of individual data (cid:9)
`Efficient m (cid:9)
`and the ability to bind flows to p ugin instances. Sets o
`
`Therefore, Decasper98's "flows" are indeed "messages" under the broadest
`
`reasonable interpretation of the claim language.
`
`2)
`
`Contrary to Patent Owner's assertion the "data packets" in a "flow" are
`
`related according to the filter used (Decasper98, page 3):
`
`Overall high performance. High performance is guaran-
`teed only in pan through a fully kernel space implemen-
`tation which prevents costly context switches. We
`identified two other critical properties which, when
`combined, guarantee high performance even in a highly
`modular environment: the flow•like nature of most inter-
`net traffic, and the ability w dassify packets into flows
`quickly and efficiently. As we shoW' below. the filter
`lookup to determine the right plus On instance to which a
`only for the first packet
`picket should beivisied ha (cid:9)
`of a WM- Subsequent (cid:9)
`ets get this inforinatiOrt from
`rn't riOwlFache Whi tenipqrait Stores aielatorrna.
`Lion gathered, by processing the first packet The filter
`implemented using a Directed
`lookuP
`Acyclic Graph (DAG). We elaborate on these techniques
`suer in this section, and also in section 5., -
`
`Juniper Ex. 1018-p. 12
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 12
`
`3) (cid:9)
`
`In response to Patent Owner's argument that "such flows, as seen by the
`
`Decasper router, are not guaranteed to include all the packets of a message", Firstly,
`
`Examiner submits that such limitations are not part of the claim language. Second,
`
`contrary to Patent Owner's assertion, IP routers acting as edge node will indeed
`
`guaranteed to include all packets of a flow or message. Decasper98's implementation is
`
`well suited for edge router (page 2):
`
`We envision several applications for our framework. First,
`our architecture fits very well into the operating system of
`small and mid-sized routers. It is particularly well suited to
`the implementation of modern edge routers that are
`responsible for doing flow classification, and for enforcing
`the configured profiles of differential service flows. This
`
`Therefore, being an edge router, Decasper98's router will encounter all packets
`
`of a flow or message.
`
`III. C and E Decasper in view of Converting Limitations :
`
`Patent Owner (pages 18-20 and 22-26):
`
`Patent Owner argues that the concept of converting from an input format to an
`
`output format for a packet arises, in part, from the fact that the '163 invention allows for
`
`connection-oriented protocols above the IP layer in which IP routers operate, e.g., at the
`
`TCP level. The ACP then states that converting into an "encrypted format" was "well
`
`known." But, as shown below in Section III.E, this is not the claimed converting because
`
`the encrypted packet, by definition, maintains the IP format. Similarly, as explained in
`
`Section II.B, supra, the ACP's references to "different formatting needs ....
`
`Juniper Ex. 1018-p. 13
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 13
`
`within IP" are misplaced. See, e.g., ACP at 22. The packets of Decasper always have
`
`the same format (IP), and therefore, by definition, do not have "different formatting
`
`needs". Patent Owner further argues that It cannot be disputed that even if the security
`
`plugin applies tunnel-mode encryption, the resultant packet is still a fully-formed IP
`
`packet that any subsequent plug-in can operate on.
`
`Patent Owner argues that a look at the IP header format, shown in Figure 2
`
`corroborates Patent Owner's position. As explained in Section II.B, supra, changing bits
`
`in the IP header does not change the format of the packet from IP to something else.
`
`Changing bits in the header merely changes values in the different fields of the IP
`
`packet--for instance, "Type of Service." The format of the IP packet is not changed
`
`unless the actual structure of the header itself is changed from that shown in Figure 2 to
`
`a different type of header (e.g., a TCP header).
`
`Patent Owner argues that for instance, suppose the plugins of Decasper's
`
`Figure 2 are re-arranged to have the following order: IPOPT, IPSEC, PS, and BMP.
`
`After the IPSec plugin has finished performing tunnel mode encryption on a packet, the
`
`PS plugin would receive the resulting, encrypted packet that has the aforementioned
`
`"second" header and an encrypted payload.
`
`Finally, Patent Owner argues that the Examiner cites three other new references-
`
`-U.S. Publication No. 2005/0265309 and U.S. Patent Nos. 6,192,409 and 6,768,738--in
`
`an attempt to establish that the claimed format matching limitation was well-known in
`
`the art. See, e.g., ACP at 23-24, 26, 29. Still, there is no teaching or suggestion that
`
`Juniper Ex. 1018-p. 14
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 14
`
`components should be arranged in a particular order to enable format matching as
`
`claimed. These three references add nothing relevant to Decasper.
`
`Requester's Comments (pages 5-12):
`
`INI's arguments fail in this reexamination proceeding as well, because they rely
`
`on: (1) an improperly narrow construction of "input/output format" which attempts to
`
`prove "there are no differing formats" in Decasper98; and (2) a technically incorrect
`
`assertion that Decasper98 "plugins can be arranged in any arbitrary order." E.g.,
`
`Second Response at 22-25. Decasper98 discloses plugins capable of changing the
`
`"structure or appearance of data in a packet, under the broadest reasonable
`
`interpretation of "format" Tunnel-mode encryption "encrypts the entire original IP packet
`
`from a host" and "prepends a new, second header to the packet." ACP at 27 (emphasis
`
`removed); Plattner Decl. ¶ 9.4 This new second header is at least a change to the
`
`"structure... of data" in the packet, and the encryption of the entire original packet is at
`
`least a change to the "appearance" of that previously unencrypted data. Thus, under the
`
`broadest reasonable construction, there are certainly differing "formats" that must be
`
`matched in the Decasper98 system. Plattner Decl. ¶] 9.
`
`Requester further states that one significant difference in format is created by
`
`tunnel-mode encryptiori, which (as INI puts it) "encrypts the entire [original] packet,
`
`including the header" and "prepends a new header.., onto the encrypted packet."
`
`Second Response at 22-23. When a packet is encrypted, its original header is thus
`
`inaccessible because it is encrypted. Plattner Decl. 119. When a packet is unencrypted,
`
`the second header is inaccessible because it doesn't exist. Id. Thus, when a
`
`Juniper Ex. 1018-p. 15
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 15
`
`Decasper98 plugin receives a packet, it is able to operate on only one header or the
`
`other. INI acknowledges this either/or limitation on the accessibility of the two headers.
`
`See Second Response at 24 ("The plugins.., will operate on the first header if the
`
`plugins appear prior to the IPSec plugin [which performs encryption] or on the second
`
`header if they appear after the IPsec plugin.").
`
`As a final addendum to its arguments, INI argues the Examiner's citation of U.S.
`
`Pub. No. 2005/0265309 and U.S. Pat. Nos. 6,192,409 and 6,768,738 is a failed "attempt
`
`to establish that the claimed format matching limitation was well-known in the art."
`
`Second Response at 25-26. Though these references are not necessary to demonstrate
`
`Decasper98 renders obvious the limitation, the Examiner properly cited them to provide
`
`further support for his findings. Plattner Decl. ¶ 9.
`
`Examiner's Response:
`
`Examiner finds Requester's argument persuasive. Examiner submits that
`
`"connection-oriented protocols above the IP layer in which IP routers operate, e.g., at
`
`the TCP level" is not part of the claim language. The claim language is broad and does
`
`not state that format conversion happens within IP, TCP and Ethernet etc.
`
`Examiner furthe'r submits that although Decasper98 explicitly does not state that
`
`all the plugins deals with IP format, however, If the same format, such as IP, in the
`
`router architecture of Decasper98 is used throughout and thus through each plugins,
`
`the plugins would have matching input and output formats; thus satisfying the claimed
`
`limitations. Security plugins of Decasper98 would perform Tunnel-mode encryption on
`
`Juniper Ex. 1018-p. 16
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 16
`
`packets to provide Decasper98's"virtual private network feature. Tunnel-mode
`
`encryption encrypts the entire original IP packet from a host and prepends a new,
`
`second header to the packet. This new second header is at least a change to the
`
`structure of data in the packet, and the encryption of the entire original packet is at least
`
`a change to the "appearance" of that previously unencrypted data. Thus, under the
`
`broadest reasonable construction, there are certainly differing "formats". Therefore, in
`
`Decasper98 the data format is being converted as it move through the Decapser98
`
`system. Since the claim language does not state what kind of format the data is being
`
`converted to, therefore, under the broadest reasonable interpretation of the claim
`
`language, the claimed limitation is met.
`
`Examiner clarifies in the following figure 1, the concept of format conversion in
`
`view of Decasper98 and explanation in the ACP:
`
`The Decryption Nor decrym
`de payload and HI so Mal me
`subsequent Pavins can
`understand ra-vd process the data
`
`Fig. 1
`
`Juniper Ex. 1018-p. 17
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`Page 17
`
`The Decryption Plugin decrypts the encrypted header and payload prior to
`
`forwarding it to the subsequent IP stack processing plugin. Without this Decryption
`
`Plugin, the subsequent Plugins will not be able to process the received encrypted data.
`
`Since the claim language is broad, and does not claim type of formatting, therefore, the
`
`cited Decasper98 prior art in view of knowledge of ordinary skilled in the art meets the
`
`claimed limitation of format conversion. Therefore, Examiner respectfully disagrees with
`
`the Patent Owner's assertion that the Examiner's core argument that "this format
`
`incompatibility (encrypted v. non-encrypted) necessarily imposes a certain order on
`
`Decasper98's component operations" and "if such an order were not observed, the
`
`plugins could not perform their functions," ACP at 28-29, is simply incorrect.
`
`Examiner submits that the word "format" is a broad term used in the claim
`
`language. It does not state any particular format such as IP, TCP, Ethernet or HTTP etc.
`
`There for any change in the payload or header is construed as a structural change
`
`(therefore changing the format of the payload or header). Such change in structure is
`
`interpreted as conversion of format. As such, Examiner respectfully disagrees with the
`
`Patent Owner's assertion that the format of the IP packet is not changed unless the
`
`actual structure of the header itself is changed to a different type of header (e.g., a TCP
`
`header).
`
`Examiner disagrees with the Patent Owner's argument that in a rearranged
`
`Decasper98 system, if PS comes after IPSec there should not be any issue; PS plugin
`
`will be able to read the second header without problem. However, Examiner disagrees;
`
`Juniper Ex. 1018-p. 18
`Juniper v Implicit
`
`

`

`Application/Control Number: 95/000,659 (cid:9)
`Art Unit: 3992
`
`