UnitTEeD STATES PATENT AND TRADEMARK OFFICE
`
`APPLICATION NO.
`
`FILING DATE
`
`|
`
`FIRST NAMED INVENTOR
`
`95/000,660
`
`03/02/2012
`
`7711857
`
`55959
`7590
`Newman Du Wors LLP
`1201 Third Avenue, Suite 1600
`SEATTLE, WA 98101
`
`,
`
`05/10/2012
`
`UNITED STATES DEPARTMENT OF COMMERCE
`States Patent and Trademark
`Office
`United
`COMMISSIONER FOR PATENTS
`Address:
`P.O. Box 1450
`Alexandria, Virginia
`uspto.gov
`
`22313-1450
`
`ATTORNEY DOCKET NO.| CONFIRMATION NO.
`
`3313
`
`EXAMINER
`
`WHITTINGTON,
`
`KENNETH
`
`ART UNIT
`
`3992
`
`MAIL DATE
`
`05/10/2012
`
`PAPER NUMBER
`
`|
`
`DELIVERY MODE
`
`PAPER.
`
`|
`
`|
`
`|
`
`|
`
`|
`
`|
`
`Please find below and/or attached an Office communication concerning this application or proceeding.
`
`The time period for reply, if any,
`
`is set in the attached communication.
`
`PTOL-90A
`
`(Rev. 04/07)
`
`JNPR-IMPL_30024_
`
`Page 1 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`iat
`iB)
`
`el
`
`“ener
`
`Commissionerfor Patents
`United States Patent and Trademark Office
`P.O.
`Alexandria, VA 22313-1450
`Wana
`
`USPTO,.gow
`
`DO NOT USE IN PALM PRINTER
`
`(THIRD PARTY REQUESTER’S CORRESPONDENCE
`
`ADDRESS)
`
`IRELL & MANELLA, LLP
`ATTN: DAVID MCPHIE
`840 Newport Center Drive, STE 400
`Newport Beach, CA 92660
`
`Transmittal of Communication to Third Party Requester
`Inter Partes Reexamination
`
`REEXAMINATION CONTROL NUMBER 95/000, 660,
`
`PATENT NUMBER 7711857.
`
`TECHNOLOGY CENTER 3999.
`
`ART UNIT 3992.
`
`Enclosed is a copy of the latest communication from the United States Patent and
`Trademark Office in the above-identified reexamination proceeding. 37 CFR 1.903.
`
`Prior to the filing of a Notice of Appeal, each time the patent owner responds to this
`the third party requester of the infer partes reexamination may once file
`communication,
`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.
`
`PTOL-2070 (Rev.07-04)
`
`JNPR-IMPL_30024_
`
`Page 2 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`ORDER GRANTING/DENYING
`REQUEST FOR INTER PARTES
`REEXAMINATION
`
`Examiner
`
`KENNETH J. WHITTINGTON | 3992
`-- The MAILING DATE of this communication appears on the cover sheet with the correspondence address. --
`
`Control No.
`
`Patent Under
`
`Reexamination
`
`7711887
`Art Unit
`
`Identification of the claims, the
`The request for inter partes reexamination has been considered.
`references relied on, and the rationale supporting the determination are attached.
`
`Attachment(s):
`
`PTO-892
`
`PTO/SB/08
`
`[Other:
`
`1. [x] The request for inter partes reexamination is GRANTED.
`
`An Office action is attached with this order.
`
`[_] An Office action will follow in due course.
`
`2.
`
`The request for inter partes reexamination is DENIED.
`
`This decision is not appealable. 35 U.S.C. 312(c). Requester may seek review of a denial by petition
`to the Director of the USPTO within ONE MONTH from the mailing date hereof. 37 CFR 1.927.
`EXTENSIONS OF TIME ONLY UNDER 37 CFR 1.183. In due course, a refund under 37 CFR 1.26(c)
`will be made to requester.
`
`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
`Order.
`
`U.S. Patent and Trademark Office
`PTOL-2063
`(08/06)
`
`Paper No.
`
`20120418
`
`JNPR-IMPL_30024_
`
`Page 3 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 2
`
`DECISION GRANTING INTER PARTES REEXAMINATION
`
`The request for inter partes reexamination filed March 2, 2012 (hereinafter the
`
`“Request”) establishes a reasonable likelihood that requester will prevail
`
`(hereinafter
`
`“RLP”) with respect to at least one of the claims 1, 4 and 10 of United States Patent No.
`
`7,711,857 (Balassanian), entitled METHOD AND SYSTEM FOR DATA MULTIPLEXING
`the ‘857 Patent). Accordingly, reexamination is GRANTED.
`
`(hereinafter
`
`The References Cited Herein
`
`(1)
`
`(2)
`
`(3)
`
`(4)
`
`(5)
`
`(6)
`
`(7)
`
`(8)
`
`PFEIFER et al., Generic Conversion of Communication Media for Supporting
`Personal Mobility, Multimedia Telecommunication and Applications, COST 237
`Workshop, Nov. 25-27, 1996, Exhibit 3 to the Request (hereinafter
`referred to as
`“Pfeifer96").
`NORTHERN TELECOM, Digital Switching Systems,
`ISDN Primary Rate User-
`Network Interface Specification, NA011, Std 08.01, Aug. 1998, Exhibit 4 to the
`Request (hereinafter referred to as “ISDN98”).
`NELSON et al., The Data Compression Book, 2nd Edition, Nov. 6, 1995, M&T
`Books, New York, NY, Exhibit 5 to the Request (hereinafter referred to as
`Nelson’).
`COX, Superdistribution: objects as property on the electronic frontier; June 4,
`1996, Addison-Wesley Publishing, Reading, MA, Exhibit 6 to the Request
`referred to as "Cox").
`(hereinafter
`FRANZ, Job and Stream Control
`in Heterogeneous Hardware and Software
`Architectures, April 22, 1998, Berlin, DE, Exhibit 7 to the Request
`(hereinafter
`referred to as "Franz98”).
`van der MEER, Dynamic Configuration Management of the Equipment in
`Distributed Communication Environments, Oct. 6, 1996, Technische Universitat
`Berlin, DE, Exhibit 8 to the Request (hereinafter referred to as "Meer96”).
`Information Sciences Institute, RFC:793, Transmission Control Protocol, DARPA
`Internet Program Protocal Specification, Sept. 1981, Marina Del Rey, California,
`Exhibit 9 to the Request (hereinafter referred to as “RFC793’).
`ARBANOWSKI, Generic Description of Telecommunication Services and
`Dynamic Resource Selection in Intelligent Communication Environments, Oct. 6,
`1996 Berlin, DE, Exhibit 11 to the Request (hereinafter referred to as
`“Arbanowski96’).
`
`JNPR-IMPL_30024_
`
`Page 4 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 3
`
`(9)
`
`(10)
`
`(11)
`
`(12)
`
`(13)
`
`(14)
`
`(15)
`
`(16)
`
`(17).
`
`(18)
`
`(19)
`
`(20)
`
`(21)
`
`(22)
`
`PFEIFER et al., Resource Selection in Heterogeneous Communication
`Environments using the Teleservice Descriptor, Dec. 19, 1997, Lisbon, Portugal,
`Exhibit 12 to the Request (hereinafter referred to as “Pfeifer97’).
`Li et al, Active Gateway: A Facility for Video Conferencing Traffic Control, Feb. 1,
`1997, Computer Science Technical Reports, Paper 1349, Exhibit 48 to the
`Request (hereinafter referred to as "Li’).
`LAWSON, Cisco NetFlow Switching speeds traffic routing,
`InfoWorld, July 7,
`1997, ProQuest Center, pg. 19, Exhibit 16 to the Request (hereinafter referred to
`as “NetFlow’)
`BELLARE et al., A Concrete Security Treatment of Symmetric Encryption:
`IEEE, October 20-22, 1997, Exhibit 17
`Analysis of the DES Modes of Operation,
`to the Request (hereinafter referred to as “Bellare97”).
`BELLARE et al., XOR MACS: New Methods for Message Authentication Using
`Finite Pseudorandom Functions, CRYPTO '95, LNCS 963, pp. 15-28, 1995,
`Berlin Heidelberg DE, Exhibit 18 to the Request (hereinafter referred to as
`“Bellare95’).
`IBM Raleigh Center, Local Area Network Concepts and Products: Routers and
`Gateways, 1st Ed., May 1996, Research Triangle Park, NC, Exhibit 19 to the
`Request (hereinafter referred to as “IBM96”).
`NATIONAL INST. OF STDS AND TECH., CheckPoint FireWall-1 White Paper,
`Version 2.0, Sept. 1995, Germany, Exhibit 20 to the Request
`(hereinafter
`referred to as “Checkpoint’).
`BELLISSARD et al., Dynamic Reconfiguration of Agent-Based Applications,
`Proceedings of ACM European SIGOPS Workshop, Sinatra, Sept. 1998, Exhibit
`23 to the Request (hereinafter referred to as “Bellissard”).
`_ FRASER et al., DTE Firewalls Phase Two Measurement and Evaluation Report,
`TIS Report #0682, July 22, 1997, Glenwood, MD, Exhibit 24 to the Request
`referred to as “Fraser’).
`(hereinafter
`DECASPER et al., Router Plugins A Software Architecture of Next Generation
`Routers, Proceedings of ACM SIGCOMM '98, Sept. 10, 1998, Vancouver B.C.,
`Exhibit 25 to the Request (referred to as “Decasper98’).
`ATKINSON, Security Architecture for the Internet Protocol, RFC: 1825, Standard
`Track, Naval Research Lab., Aug. 1995, Exhibit 26 to the Request
`(hereinafter
`referred to as
`KARN et al, RFC: 1829: The ESP DES-CBC Transform, Aug.1995, Exhibit 27 to
`the Request (hereinafter referred to as “RFC1829").
`Internet Protocol, Version 6 (IPv6) Specification, RFC:
`DEERING & HINDEN,
`1883, Standards Track, Dec. 1995, Exhibit 28 to the Request
`(hereinafter
`“RFC1883’).
`DECASPER, Crossbow A Toolkit for Integrated Services over Cell SwitchedIPv6,
`IEEE ATM'97 Workshop Proeedings, May 25-28, 1997, Lisboa, Portugal, Exhibit
`30 to the Request (hereinafter referred to as “Decasper97").
`
`+
`
`JNPR-IMPL_30024_
`
`Page 5 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 4
`
`(23)
`
`(24)
`
`(25)
`
`(26)
`
`(27)
`
`(28)
`
`(29)
`
`(30)
`
`(31)
`
`(32)
`
`MOSBERGER, Scout: A Path-Based Operating System, Dissertation submitted
`to Dept of Computer Science, 19971 University of Arizona, Exhibit 31 to the
`Request (hereinafter referred to as “Mosberger’).
`KRUPCZAK et al.,
`Implementing Communication Protocols in Java,
`IEEE
`Comminication Magazine, October 1998, Exhibit 32 to the Request (hereinafter
`referred to as “HotLava’).
`FIUCZYNSK! et al., An Extensible Protocol Architecture for Application-Specific
`Networking, Jan. 22, 1996, Department of Computer Science and Engineering,
`Seattle, WA, Exhibit 33 to the Request (hereafter referred to as “Plexus’).
`MUHUGUSA et al., COMSCRIPT*: An Environment for the Implementation of
`Protocol Stacks and their Dynamic Reconfiguration, December 1994, Exhibit 34
`to the Request (hereinafter referred to as “ComScript'’).
`WETHERALL et al., The Active IP Option, Telemedia Networks and Systems
`Group, Lab for Computer Science, Sept. 11, 1996, MIT, Exhibit 47 to the
`Request (hereinafter referred to as “Wetheraill’).
`ALAM et al., U.S. Patent No. 6,104,500 (2000), Exhibit 14 to the Request
`referred to as “Alam’).
`(hereinafter
`YUN, U.S. Patent No. 5,298,674 (1994), Exhibit 14 to the Request
`referred to as “Yun’).
`KERR et al., U.S. Patent No. 6,243,667 (2001), Exhibit 15 to the Request
`referred to as “Kerr’).
`(hereinafter
`SHWED et al. U.S. Patent No. 5,835,726 (1998), Exhibit 21 to the Request
`referred to as “Shwed?’).
`(hereinafter
`DIETZ et al., U.S. Patent No. 6,651,099 (2003), Exhibit 22 to the Request
`referred to as “Dietz”).
`(hereinafter
`
`(hereinafter
`
`ll.
`
`identification of Every Claim for Which Reexamination is Requested
`
`The third party Requester (hereinafter the “Requester”) has cited the above
`
`references and combinations thereof that Requester believes establish that there is a
`
`reasonable
`
`likelihood that the requester will prevail with respect to at least one of the
`
`claims challenged in the request,
`
`i.e., one of claims 1, 4 and 10, as outlined in the
`
`Request.
`
`JNPR-IMPL_30024_
`
`Page 6 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 5
`
`Hi.
`
`Reasonable Likelihood to Prevail (RLP) on the Issue of Patentability
`
`The claims for which reexamination is requested will be utilized to show whether
`
`the above-cited references,
`
`taken together with the explanation provided by Requester,
`
`are found to satisfy, or not to satisfy, the burden of establishing that there is a
`
`reasonable likelihood that the requester will prevail with respect to at least one of the
`
`patent claims.
`
`IV.
`
`Issues Raising/Not Raising RLPs
`
`Issues 1-61 outlined below correspond to the proposed issues raised in the
`Request. The subheadings (V.A.1, V.A.2, etc.) correspond to the subheadings outlined
`
`in pages 33-285 of the Request.
`
`issue 1
`
`V.A.1. Proposed Rejections of Decasper98 Anticipating Claims 1, 4 and 10—
`
`RLP
`
`Rejections of claims 1, 4 and 10 as being anticipated by Decasper98 were
`
`proposed by the Requester as set forth in pages 33-48 of the Request.
`
`It is agreed
`
`herein that these proposed rejections satisfy the burden that there is a reasonable
`
`likelihood that the requestor will prevail to at least one of the claims as evidenced by the
`
`accompanying Office Action rejecting these claims.
`
`JNPR-IMPL_30024_
`
`Page 7 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 6
`
`Issue 2
`
`V.A.2. Proposed Rejections of Decasper98 Rendering Obvious Claims 1, 4 and
`
`10--RLP
`
`Rejections of claims 1, 4 and 10 as being obvious over Decasper98 were
`
`proposed by the Requester as set forth in pages 48-58 of the Request.
`
`It is agreed
`
`herein that these proposed rejections satisfy the burden that there is a reasonable
`
`likelihood that the requestor will prevail to at least one of the claims as evidenced by the
`
`accompanying Office Action rejecting these claims.
`
`issue 3
`
`V.A.3. Proposed Rejection of Decasper98 in view of RFC1825 and RFC1829
`
`Rendering Obvious Claims 1, 4 and 10—NO RLP
`
`Rejections of claims 1, 4 and 10 as being obvious over Decasper98 in view of
`
`|
`
`RFC1825 and
`
`are proposed by the Requester as set forth in pages 59-63 of
`
`the Request “if certain aspects recited in claims 1, 4 and 10 ... are not deemed to be
`
`disclosed,
`
`inherent or obvious over Decasper98 alone".
`
`It is initially noted that Requester has not provided the analysis of an obvious
`
`rejection. Requester has not asserted which aspects are missing and thus Requester
`
`has again not identified any deficiencies of Decasper98 nor any differences between the
`
`claims and Decasper98 (See Part A1 wherein Requester asserts that Decasper98
`
`anticipates these claims). Thus, the Request has not outlined why or how Decasper98
`
`in view of
`
`and RFC1829 renders the claims obvious.
`
`JNPR-IMPL_30024_
`
`Page 8 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 7
`
`it is also noted that again Requester has done nothing more than provide more
`
`‘detail of the disclosure of Decaspser98. Decasper98 specifically states that it
`
`implements
`
`IP Security such as that of RFC1825 as
`one of its plug-ins (See
`Decasper98 Part 2, page 2, col. 2 incorporating endnote 2 for RFC1825).
`
`It is further
`
`noted that RFC1825 incorporates the use of ESP DES-CBC Transform aigorithm of
`
`RFC1829 (See RFC1825 at page 10). Thus, the disclosure of Decasper98
`
`incorporates, directly and indirectly, the disclosures of
`
`and
`
`Requester in this proposed combination is merely adding more detail to the
`
`teachings of Decasper98 which are not necessaryto reject the claims because as noted
`
`above,
`
`the proposed anticipation/obvious rejections applying Decasper98 alone already
`
`raises an RLP as noted above in Issues 1 and 2 (See also accompanying Office Action
`
`for respective anticipation rejection). Thus these proposed obvious rejections are
`
`merely cumulative thereto.
`
`Accordingly,
`
`since the proposed obvious rejections applying Decasper98 in view
`
`of RFC1825 and RFC 1829 fail to provide the analysis necessary for an obvious
`
`rejection and is merely cumulative of the anticipation/obvious rejection because it
`
`teaches nothing further than the anticipation rejection, the proposed rejections do not
`
`satisfy the burden of establishing that there is a reasonable likelihood that the
`
`requester will prevail with respect to at least one of the patent claims.
`
`JNPR-IMPL_30024_
`
`Page 9 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 8
`
`issue 4
`
`V.A.4. Proposed Rejection of Decasper98 in view of
`
`Rendering
`
`Obvious Claims 1, 4 and 10—NO RLP
`
`Rejections of claims 1, 4 and 10 as being obvious over Decasper98 in view of
`
`RFC1883 are proposed by the Requester as set forth in pages 63-65 of the Request “if
`
`certain aspects recited in claims 1, 4 and 10 ... are not deemed to be disclosed,
`
`inherent
`
`or obvious over Decasper98 alone”.
`
`It is initially noted that Requester has not provided the analysis of an obvious
`
`rejection. Requester has not asserted which aspects are missing and thus Requester
`
`has again not identified any deficiencies of Decasper98 nor any differences between the
`
`claims and Decasper98 (See Part A1 wherein Requester asserts that Decasper98
`
`anticipates these claims). Thus, the Request has not outlined why or how Decasper98
`
`in view of RFC1883 renders the claims obvious.
`
`Requester
`
`further has not proposed a proper modification of Decasper98 in view
`
`of
`
`to arrive at the claims. Decasper98 teaches a router platform having a
`
`plurality of components/plug-ins for processing of data packets of a flow/message,
`
`wherein the router keeps stores of a flow path through the components/plug-ins
`
`based
`
`on a first packet for quicker processing of later packets through the flow path (See
`
`Decasper98 Part 3.2 and rejection of claims 1, 4 and 10 in Issue 1 of the
`
`accompanying
`
`Office Action). RFC1883 also teaches a router platform using IPv6 protocols to store a
`
`flow-handling
`
`state of a flow path through processing components for a flow based on a
`
`first packet for use when processing subsequent packets of the flow (See
`
`JNPR-IMPL_30024_
`
`Page 10 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 9
`
`pages 28-29). Thus, the applied portions of both references are directed to similar
`
`storing of flow handling states for flows through processing components/plug-ins in a
`
`router platform. There is no teaching from RFC1883 to provide such a router flow-
`
`handling state storage with respect to component/plug-ins of routers as proposed in the
`
`Request.
`
`Thus, the teaching is not applicable to the plug-ins of Decasper98.
`
`Furthermore, Requester in this proposed combination (assuming the teachings
`
`are combinable)
`
`is merely adding more detail to the teachings of Decasper98 to which
`
`is not necessary to reject the claims because as noted above in Issues 1 and 2, the
`
`proposed
`
`anticipation/obvious rejections applying Decasper98 alone already raise an
`
`RLP (See also accompanying Office Action for respective anticipation rejections).
`
`Thus
`
`these proposed obvious rejections are merely cumulative thereto.
`
`Accordingly, since the proposed obvious rejection applying Decasper98 in view
`
`of RFC1883 fails to provide the analysis necessary for an obvious rejection,
`
`is merely
`
`cumulative of the anticipation/obvious
`
`rejections and the teachings are not properly
`
`combinable to arrive at the claimed invention, the proposed rejections do not satisfy
`
`the burden of establishing that there is a reasonable likelihood that the requester will
`
`prevail with respect to at least one of the patent claims.
`
`issue §
`
`V.A.5. Proposed Rejection of Decasper98 in view of Decasper97 Rendering
`
`Obvious Claims 1, 4 and 10—NO RLP
`
`JNPR-IMPL_30024_
`
`Page 11 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 10
`
`Rejections of claims 1, 4 and 10 as being obvious over Decasper98 in view of
`
`Decasper97 are proposed by the Requester as set forth in pages 65-68 of the Request
`
`“if certain aspects recited in claims 1, 4 and 10 ... are not deemed to be disclosed,
`
`inherent or obvious over Decasper98 alone".
`
`It is initially noted that Requester has again not provided the analysis of an
`
`obvious rejection. Requester has not asserted which aspects are missing and thus
`
`Requester has again not identified any deficiencies of Decasper98 nor any differences
`
`between the claims and Decasper98 (See Part A1 wherein Requester asserts that
`
`Decasper98
`
`anticipates these claims). Thus, the Request has not outlined why or how
`
`Decasper98 in view of Decasper97 renders theclaims obvious.
`
`Requester further has not proposed any modifications of Decasper98 in view of
`
`Decasper97 to arrive at the claims. Rather the Request simply identifies the teachings
`
`of both references as being compatible
`
`and
`obvious or “confirm” the claims’ obviousness. Thus,
`
`concludes their teachings render the claims
`
`the Request has not provided any
`
`analysis of how these references are combined and a reason to make such
`
`combination.
`
`Furthermore, Requester in this proposed combination, assuming they are
`
`combinable in some manner,
`
`is merely adding more detail to the teachings of
`
`Decasper98 to “confirm obviousness” (See Request at page 66) which are not
`
`necessary to reject the claims because as noted above in Issues 1 and 2, the proposed
`
`anticipation.obvious
`
`rejections applying Decasper98 alone already raises an RLP (See
`
`JNPR-IMPL_30024_
`
`Page 12 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 11
`
`also accompanying Office Action for respective anticipation rejections). Thus these
`
`proposed obvious rejections are merely cumulative thereto.
`
`Requester further states that one having ordinary skill
`
`in the art would be aware
`
`of both stateful encryption and stateful authentication in view of Bellare97 and Bellare95
`
`references (See pages 66-67 and footnotes thereof). Requester asserts these
`
`references are used solely to explain the prior art, however, Requester in these pages
`
`also states a counter used in these stateful features would record state information as
`
`recited in the claims. Thus, Requester has directly applied the teachings of these
`footnote references and thusit is unclear which references are actually applied in the
`proposed rejection because Requester’s positions are contradictory.
`
`Accordingly, since the proposed obvious rejections applying Decasper98 in view
`of Decasper97 fail to provide the analysis necessary for an obvious rejection, are
`
`merely cumulative of the anticipation/obvious rejections and it is unclear which
`
`references are actually applied in the rejections,
`
`the proposed rejections do not satisfy
`
`the burden of establishing that there is a reasonable likelihood that the requester will
`
`prevail with respect to at least one of the patent claims.
`
`issue 6
`
`V.A.6. Proposed Rejection of Decasper98 in view of Decasper97, Bellare97 and
`Bellare95 Rendering Obvious Claims 1, 4 and 10—NO RLP
`
`Rejections of claims 1, 4 and 10 as being obvious over Decasper98 in view of
`
`Decasper97, Bellare97 and Bellare95 are proposed by the Requester as set forth in
`
`JNPR-IMPL_30024_
`
`Page 13 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 12
`
`pages 68-71 of the Request “if certain aspects recited in claims 1, 4 and 10 ... are not
`
`deemed to be disclosed,
`
`inherent or obvious over Decasper98 in view of Decasper97".
`
`it is initially noted that Requester has not provided the analysis of an obvious
`
`rejection. Requester has not asserted which aspects are missing and thus Requester
`
`has again not identified any deficiencies of Decasper98 nor any differences between the
`
`claims and Decasper98 (See Part A1 wherein Requester asserts that Decasper98
`
`anticipates these claims). Thus, the Request has not properly outlined why or how
`
`Decasper98 in view of Decasper97, Bellare97 and Bellare95 renders the claims
`
`obvious.
`
`Requester further has not proposed any modifications of Decasper98 in view of
`
`Decasper97, Ballare97 and Bellare95 to arrive at the claims. Rather the Request
`
`simply identifies the teachings of the references and concludes their teachings render
`
`the claims obvious. Thus, the Request has not provided any analysis of what this
`
`combination of references would be to allow for a determination ofwhether it would
`
`render the claims obvious.
`
`Furthermore, Requester in this proposed combination, assuming the references
`
`are combinable,
`
`is merely adding more detail to the teachings of Decasper98 which are
`
`not necessary to reject the claims because as noted above in Issues 1 and 2, the
`
`proposed
`
`anticipation/obvious rejections applying Decasper98 alone already raises an
`
`RLP (See also accompanying Office Action for respective anticipation rejection). Thus
`
`these proposed obvious rejections are merely cumulative thereto.
`
`JNPR-IMPL_30024_
`
`Page 14 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 13
`
`Finally,
`
`it is not clear how the counters of Bellare95 and Bellare97 teach any
`
`modification of Decasper98 or Decasper97. The counter in Bellare97 is used in an
`
`encryption scheme for communications between a sender and receiver to change the
`
`encryption after each message is sent (See Bellare97 at page 397). Similarly the
`
`counter
`
`in Bellare95 is used in an authentication scheme for communications between a
`
`sender and receiver to change the authentication after each message is sent (See
`
`Bellare95 pages 21-22). Decasper98 involves a series of packets of a flow passing
`
`through a component/plug-in a router. Accordingly,
`
`it is unclear, nor has Requester
`
`outlined, how the teachings are compatible and how such encryption and authentication
`
`schemes in communications within and between two devices can be incorporated
`
`|
`
`and/or
`
`implemented into the series of router plug-ins of Decasper98 as proposed by
`
`Requester.
`
`Further analysis of how the teachings of these references would be
`
`combined is necessary before a determination of whether they raise an RLP.
`
`Accordingly. since the proposed obvious rejection applying Decasper98 in view
`
`of Decasper97, Bellare97 and Bellare95 fails to provide the proper analysis necessary
`
`for an obvious rejection,
`
`is merely cumulative of the anticipation/obvious
`
`rejections
`
`applying Decasper98 along and the teachings are not properly combination as
`
`proposed by Requester, the proposed rejections do not satisfy the burden of
`
`establishing that there is a reasonable likelihood that the requester will prevail with
`
`respect
`
`to at least one of the patent claims.
`
`JNPR-IMPL_30024_
`
`Page 15 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 14
`
`issue 7
`
`V.A.7. Proposed Rejection of Decasper98 in view of IBM96 Rendering Obvious
`
`Claims 1, 4 and 10—RLP
`
`Rejections of claims 1, 4 and 10 as being obvious over Decasper98 in view of
`
`IBM96 were proposed by the Requester as set forth in pages 71-74 of the Request.
`
`Itis
`
`agreed herein that these proposed rejections satisfy the burden that there is a
`
`reasonable likelihood that the requestor will prevail to at least one of the claims as
`
`evidenced by the accompanying Office Action rejecting these claims.
`
`issue 8
`
`V.A.8. Proposed Rejection of Decasper98 in view of IBM96 and Nelson
`
`Rendering Obvious Claims 1, 4 and 10—RLP
`
`Rejections of claims 1, 4 and 10 as being obvious over Decasper98 in view of
`
`IBM96 and Nelson were proposed by the Requester as set forth in pages 74-78 of the
`
`Request.
`
`It is agreed herein that these proposed rejections satisfy the burden that
`
`there is a reasonable likelihood that the requestor will prevail to at least one of the
`
`claims as evidenced by the accompanying Office Action rejecting these claims.
`
`issue 9
`
`V.A.9. Proposed Rejection of Decasper98 in view of RFC1825, RFC1829,
`
`Decasper97, Bellare97, Bellare95, IBM96 and Nelson Rendering Obvious
`
`Claims 1, 4 and 10—NO RLP
`
`JNPR-IMPL_30024_
`
`Page 16 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 15
`
`Rejections of claims 1, 4 and 10 as being obvious over Decasper98 in view of
`
`RFC1825, RFC1829, Decasper97, Bellare97, Bellare95,
`
`IBM96 and Nelson are
`
`proposed by the Requester as set forth in pages 78-80 of the Request “if certain
`
`aspects recited in claims 1, 4 and 10 ... are not deemed to be disclosed,
`
`inherent or
`
`obvious over Decasper98 alone or in combinations" outlined in other portions of the
`
`Request.
`
`The Request in these pages reiterates the same teachings outlined in the prior
`
`sections of the Request (See Parts V.A.2, V.A.3 and V.A.5-V.A.8 of the Request) and
`
`suggests without any reason or analysis therefor that they are combinable to arrive at
`
`the claimed invention. Secondly, without any analysis of the proposed combination,
`
`the
`
`scope of the proposed combination is unclear for consideration in view of the claims.
`
`Additionally,
`
`for the same reasons as outlined above in Issues 2, 3, 5 and 6
`
`(corresponding to the noted parts of the Request), one or more of the individual parts of
`
`this proposed combination do not raise RLPs.
`
`Accordingly, since the proposed obvious rejections applying Decasper98 in view
`
`of RFC1825, RFC1829, Decasper97, Bellare97, Bellare95,
`
`IBM96 and Nelson fail to
`
`provide the proper analysis necessary for an obvious rejection, the scope of the
`
`combination of teachings is not provided and one or more individual parts of the
`
`proposed combination fail to raise an RLP, the proposed rejections do not satisfy the
`
`burden of establishing that there is a reasonable likelihood that the requester will prevail
`
`with respect to at least one of the patent claims.
`
`JNPR-IMPL_30024_
`
`Page 17 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 16
`
`issue 10
`
`V.A.10.
`
`Proposed Rejection of Decasper98 in view of Fraser Rendering
`
`Obvious Claims 1, 4 and 10—NO RLP
`
`Rejections of claims 1, 4 and 10 as being obvious over Decasper98 in view of
`
`Fraser are proposed by the Requester as set forth in pages 80-85 of the Request “if
`
`certain aspects recited in claims 1, 4 and 10 ... are not deemed to be disclosed,
`
`inherent
`
`or obvious over Decasper98 alone”.
`
`It is initially noted that Requester has not provided the analysis of an obvious
`
`rejection. Requester has not asserted which aspects are missing and thus Requester
`
`has again not identified any deficiencies of Decasper98 nor any differences between the
`
`claims and Decasper98 (See Part A1 wherein Requester asserts that Decasper98
`
`anticipates these claims).
`
`In fact, Requester repeatedly states Decasper98 otherwise
`
`teaches the features of the claims (See last two lines of page 80 and second full
`
`paragraph of page 81). Thus,
`
`it is unclear what further teachings of Fraser can add to
`
`the proposed rejection applying Decasper98 alone.
`
`Furthermore,
`
`the portion of Fraser relied upon by Requester does not provide the
`
`proposed modification of Decasper98. Decasper98 is a router architecture used for
`
`dynamically
`
`identifying a sequence of plug-ins in the router. This is dynamically
`
`controlled by the AIU, which implements a packet classifier,
`
`fast flow detection and
`
`binding between plug-ins creating and maintaining a flow path through a router (See
`
`Decasper98 Part 5). Thus, the AIU dynamically creates the flow path for packets of
`message based on the first packet of the message (See Decasper98 Part 3.2).
`
`In
`
`JNPR-IMPL_30024_
`
`Page 18 of 145
`
`Implicit Exhibit 2006
`Juniper v. Implicit
`
`

`

`Application/Control Number: 95/000,660
`Art Unit: 3992
`
`Page 17
`
`contrast, Fraser teaches a firewall policy module for monitoring the traffic between two
`
`or more hosts in a communication system (See Fraser Part 1.1 and FIG.
`
`1 and
`
`disclosure related thereto). As noted by Requester, this firewall policy module is
`
`dynamic in that it allows for minor changes without having to reboot (See Fraser at page
`
`37 and pages 82-83 of the Request). Thus, the disclosure of Fraser is concerned with
`
`making changes toa firewall policy.
`
`Requester takes the position that because changes to the firewall policies of
`
`Fraser can be dynamic, then it would be obvious to make AIU operation of the router of
`
`Decasper98 also dynamic. However, Fraser does not provide any teaching nor does
`
`Requester provide any reason for using these dynamically changeable firewall policies
`
`to dynamically create and maintain flow paths within a router. These apparatus and
`
`methods are distinct in operation, architecture and structure and are used in distinct
`
`ways. Thus,
`
`there is no teaching in Fraser to modify the already dynamic nature of the
`
`AIU in
`
`Decasperg8.
`It is further noted that the AIU in Decasper98 otherwise operates dynamically by
`
`creating the path on the fly during passing of the first packet through the plug-ins (See
`
`Decasper98 Parts 3, 5.1 and 5.2). Thus, there is no reason to modify Decasper98 to
`
`operate dynamically as suggested by Requester because it already operates as such.
`
`Accordingly, since the proposed obvious rejection applying Decasper98 in view
`
`of Fraser fails to provide the analysis necessary for an obvious rejection (identifies no
`
`differences between claims and Decasper98 and notes there is no differences) and
`
`ther