Case3:10-cv-04234-SI Document175 Filed11/16/12 Page1 of 21
`
`SPENCER HOSIE (CA Bar No. 101777)
`shosie@hosielaw.com
`DIANE S. RICE (CA Bar No. 118303)
`drice@hosielaw.com
`DARRELL R. ATKINSON (CA Bar No. 280564)
`datkinson@hosielaw.com
`HOSIE RICE LLP
`Transamerica Pyramid, 34th Floor
`600 Montgomery Street
`San Francisco, CA 94111
`(415) 247-6000 Tel.
`(415) 247-6001 Fax
`
`Attorneys for Plaintiff
`IMPLICIT NETWORKS, INC.
`
`UNITED STATES DISTRICT COURT
`FOR THE NORTHERN DISTRICT OF CALIFORNIA
`SAN FRANCISCO DIVISION
`
`IMPLICIT NETWORKS, INC.,
`
`Plaintiff,
`
`v.
`
`F5 NETWORKS, INC.,
`
`Defendant.
`
`Case No. 10-CV-3365 SI
`
`IMPLICIT NETWORKS’ OPPOSITION
`TO JUNIPER NETWORKS/F5
`NETWORKS’ MOTION FOR
`SUMMARY JUDGMENT OR, IN THE
`ALTERNATIVE, FOR PARTIAL
`SUMMARY JUDGMENT, ON THE
`ISSUE OF INVALIDITY
`
`_______________________________________
`
`IMPLICIT NETWORKS, INC.,
`
`Case No. C 10-4234 SI
`
`Plaintiff,
`
`v.
`
`JUNIPER NETWORKS, INC.,
`
`Defendant.
`
`Date: December 14, 2012
`Time: 9:00 a.m.
`Courtroom: 10
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`Juniper Ex. 1023-p. 1
`Juniper v Implicit
`
`

`

`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page2 of 21
`
`TABLE OF CONTENTS
`
`INTRODUCTION AND SUMMARY
`
`
`
`PROCEDURAL STATE: REEXAM REDOUBT
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`THE PATENTS-IN-SUIT: A FLEXIBLE AND EXTENSIBLE NETWORK
`OPERATING SYSTEM
`
`
`
`
`
`
`
`
`A.
`
`B.
`
`THE PRESUMPTION OF VALIDITY MEANS SOMETHING HERE
`
`Implicit’s Patents: A Modular Network Operating System
`
`Implicit’s Products and Sales
`
`
`
`
`
`
`
`
`
`
`
`Packets Stand Alone in a Router, the Very Converse of ʼ163
`
`
`
`
`
`Page
`
`1
`
`3
`
`4
`
`4
`
`7
`
`8
`
`9
`
`9
`
`
`
`
`
`
`
`
`
`
`
`DECASPER’S ROUTER DOES NOT ANTICIPATE
`
`A.
`
`B.
`
`
`
`I.
`
`II.
`
`III.
`
`IV.
`
`V.
`
`VI.
`
`VII.
`
`IX.
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`No Data Conversion; No Formats
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` 12
`
` 12
`
`Decasper Does Not Anticipate
`
`1.
`
`2.
`
`Decasper Does Not Maintain State, as Required by the Claims 13
`
`
`JUNIPER’S COMBINATIONS DO NOT RENDER ʼ163 OBVIOUS
`
`JUNIPER IGNORES THE SECONDARY INDICIA
`
`VIII. JUNIPER IS ASSERTING PATENTS REMARKABLY SIMILAR TO ʼ163,
`JUST LATER IN TIME
`
`
`
`
`
`
` 16
`
`CONCLUSION
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` 14
`
` 16
`
` 18
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`i
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 2
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page3 of 21
`
` TABLE OF AUTHORITIES
`
`Cases
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Page
`
`
`
`1
`
` 2, 17
`
` 15
`
`In Re Icon Health,
`496 F.3d 1374 (Fed. Cir. 2007)
`
`
`
`Juniper Networks, Inc. v. Palo Alto Networks,
`
`2012 WL3133092 (D. Del. 2012)
`
`
`McGinley v. Franklin Sports, Inc.,
`
`262 F.3d 1339 (Fed. Cir. 2001)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`ii
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 3
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page4 of 21
`
`I.
`
`INTRODUCTION AND SUMMARY.
`
`Decasper is a one format system. It is a router, a node in a network that takes in IP
`
`packets and spits out IP packets. It carefully preserves the IP format throughout. Decasper
`
`turns on the efficient processing of uniform IP packets. It centers on preserving the one
`
`format it handles, exactly the converse of the demultiplexing (conversion) claimed by the
`
`patents-in-suit.
`
`As a router, Decasper does not disclose building paths to demultiplex the packets of a
`
`message. See below § V. It does not teach input and output formats, as it does not deal with
`
`formats at all. Nor does Decasper teach storing state to process the subsequent packets of a
`
`message, as claimed here. See below § V.
`
`Neither Juniper nor F5 could build their infringing products based on Decasper.
`
`Juniper’s and F5’s products process packets by unwrapping the packets, inspecting the
`
`contents layer by layer, and then determining the correct processing post-TCP. Decasper
`
`does not do this. Nor does Decasper necessarily maintain state for the duration of a message.
`
`In fact, Decasper routers may not even see all the packets of a message. That is not what
`
`routers do.
`
`Appreciating these points, Juniper combines Decasper with two generic texts, Nelson
`
`and IBM. Juniper cites to pages dealing with LZ compression, and then incongruously
`
`argues that mixing compression with Decasper gives rise to ʼ163. But LZ compression
`
`would not work with Decasper, as this compression requires exactly the kind of all packet
`
`state that Decasper disclaims. See below § V. Putting together disparate things to break a
`
`larger whole is the antithesis of the kinds of combinations giving rise to real obviousness.
`
`See In Re Icon Health, 496 F.3d 1374, 1382 (Fed. Cir. 2007)
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`1
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 4
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page5 of 21
`
`For that matter, there would be no motivation to combine Decasper’s one format fast
`
`router with a demultiplexing system. The two systems are exactly at cross purposes; adding
`
`format driven conversion to Decasper’s fast router thwarts the very goals that Decasper
`
`serves. Mixing the two would be like sewing a bowling ball onto the belly of a fish – it
`
`would make no sense and neither would function well.
`
`Two other points merit note in a brief introduction. Juniper trumpets the pending
`
`reexams, and suggests (without quite saying) that the process is all but over. It is not. These
`
`are early rejections, as is common, and the process has years to run. The foundation on this
`
`Bleak House is yet being dug.
`
`Juniper also suggests that the presumption of validity means nothing here and that it
`
`need not prove invalidity by clear and convincing evidence. Juniper Br. at 2. It argues that
`
`the PTO did not have Decasper before it in the original prosecution, and hence the
`
`presumption of validity has no force. What Juniper does not acknowledge, however, is that
`
`art very similar to Decasper was fully disclosed in the original prosecution. Decasper is
`
`cumulative over the art disclosed, a point that Juniper carefully sidesteps. Indeed, Juniper’s
`
`expert, Dr. Calvert, despite writing a 235 page expert report with 36 separate references and
`
`40 combinations, carefully did not even look at whether any art disclosed in the first
`
`prosecution was similar to Decasper. See § IV below. This was no mere inadvertence.
`
`Perhaps the best evidence that Juniper does not truly think ʼ163 is invalid comes in its
`
`conduct in a related case, Juniper Networks, Inc. v. Palo Alto Networks, 2012 WL3133092
`
`(D. Del. 2012). There, Juniper is asserting seven networking patents against its competitor,
`
`Palo Alto Networks. Juniper characterizes these patents as “core” networking patents and
`
`vigorously defends their validity. These patents are remarkably similar to ʼ163, just later in
`
`time. See § VIII, below. Surely the jury is entitled to hear Juniper explain how its own
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`2
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 5
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page6 of 21
`
`copycat networking patents are valid and non-obvious, even while insisting that Implicit’s
`
`earlier and similar patents are neither.
`
`II.
`
`
`PROCEDURAL STATUS: REEXAM REDOUBT.
`
`In December 2008, a consortium of companies, led by Intel, put Implicit’s ʼ163 patent
`
`in ex parte re-exam. Although Intel et al. cited numerous pieces of prior art against ʼ163,
`
`including one very similar to Juniper’s new references, Decasper, the re-exam focused on
`
`one particular piece of art: Mosberger, “Scout: A Path Based Architecture.”
`
`Mosberger involved processing paths configured in code, and then these possible
`
`paths are compiled and hard-coded into a kernel. As a result, paths in Mosberger were fully
`
`pre-defined before the system was turned on. When the system would boot up, Mosberger’s
`
`system would create all anticipated paths. These paths were created in a top-down fashion
`
`since the definition of the paths was inherent in the code itself. Neither the arrival nor
`
`content of the first packets of a message played a role in path construction. In contrast,
`
`Implicit claimed paths constructed bottom-up, post-first packet, and where path creation
`
`varied based on information in the first packet. Because Implicit’s system was configurable
`
`and changeable prior to the first packet, the system could be modified to accommodate
`
`different devices, formats, applications as networking changed day over day.
`
`The PTO agreed that ʼ163 was novel as amended over Mosberger and ʼ163 reissued
`
`in June 2010.
`
`In February 2012, after a year and a half of robust litigation, and post-claims hearing,
`
`Juniper filed a second re-exam on the ʼ163 patent, an inter partes re-exam. A second reexam
`
`followed in March for the other patent-in-suit, the ʼ857 patent.
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`3
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 6
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page7 of 21
`
`These second re-exams are early in the PTO process. The parties have exchanged
`
`Office Actions, and all claims stand rejected.1 Although Juniper will say this is significant,
`
`the PTO routinely rejects all claims, as it did initially in the first ʼ163 reexam and as it did for
`
`some of the patents that Juniper even now asserts against Palo Alto Networks, and then the
`
`process continues. These re-exams are not remotely over.
`
`III. THE PATENTS-IN-SUIT: A FLEXIBLE AND EXTENSIBLE NETWORK
`OPERATING SYSTEM.
`
`
`
`A.
`
`Implicit’s Patents: A Modular Network Operating System.
`
`Implicit invented, claimed, and subsequently built a modular networking operating
`
`system, U.S. Patent No. 6,629,163 (“Method and System for Demutiplexing a First Sequence
`
`of Packet Components to Identify Specific Components Wherein Subsequent Components
`
`Are Processed Without Re-Identifying Components”) (“ʼ163”). In Implicit’s systems
`
`individual code processing functions were captured in individual code modules, known as
`
`“beads.” The beads were not glued together at compile time, but rather remained individual
`
`and then were recruited as part of a message/flow-specific processing path after a first packet
`
`of a new flow arrived. At that point, the system would “demultiplex,” i.e. “unwrap” the
`
`packets, and then build a data processing path by selecting individual beads based on and
`
`guided by configuration information present before the first packet. As part of this process,
`
`and as set forth in the preferred embodiment, Implicit used configuration information
`
`expressed as a sequence of processing steps – do “a,” then do “b,” then do “c” – a cache it
`
`called “LabelMapGet.”
`
`
`1
`Most recently, there was an action closing prosecution, which is the reexam
`equivalent to a final office action. This will spark a further round of comments and then an
`appeal to the Board.
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`4
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 7
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page8 of 21
`
`Unlike prior art, the actual processing path in the Implicit system was built
`
`dynamically after the first packet of a new flow arrived and variant on information in that
`
`first packet. This meant that Implicit’s system was flexible and could be changed to
`
`accommodate different processing steps, different applications, different protocols, and the
`
`like. In the prior art systems, the “policies,” i.e., what do with the traffic, were hard-baked
`
`into the code, and the paths were created before and in anticipation of the type of traffic the
`
`system was designed to process; in Implicit’s systems, the configuration policies could be
`
`changed at any time pre-first packet and changing the policies would change the processing
`
`by changing the paths that the system built.
`
`This dynamic path construction did not mean that Implicit disclaimed using
`
`administrator set configuration information in path construction. Indeed, the ability to
`
`configure the system differently as the world changed was one explicit object of the
`
`invention. See below, § III.
`
`As described in the specification, the steps in the Implicit system were as follows:
`
`A packet arrives:
`
`When a packet arrives, the system knows one thing: that the packet arrived at an
`
`Ethernet port. That Ethernet packet could have any number of embedded protocols,
`
`including IP. The Ethernet component makes no assumptions about content. Rather,
`
`Ethernet component inspects the header to determine the next layer, and then hands the
`
`packet off to the module responsible for processing that format.
`
`Ethernet determines it is carrying IP data:
`
`If the packet is carrying IP data, the system sends the packet to the IP module: IP is
`
`the “compatible format” here.
`
`IP determines it is carrying TCP data:
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`5
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 8
`Juniper v Implicit
`
`

`

`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page9 of 21
`
`The IP module then determines the type of payload in the next layer. IP can carry
`
`many types of data, including TCP. The IP module inspects the header, and if it sees TCP, it
`
`hands the packet to the TCP component for subsequent processing. TCP is the “compatible
`
`format” here.
`
`TCP determines it is carrying application data:
`
`TCP can carry any number of application layer data types. This could be HTTP on
`
`port 80 or thousands of other types of data. As such, the format of data encapsulated by TCP
`
`is defined by the TCP port number. There is no way for TCP to know how to map its
`
`payload to a subsequent component. There must be a mechanism in the system that dictates
`
`the mapping of TCP data types (e.g. the port number) to a subsequent component.
`
`The mechanism described in ʼ163 is a “policy” look-up. At this point, the
`
`specification describes methods to determine the next series of processing steps, e.g., a
`
`LabelMapGet (“LMG”) cached list of steps. Once this is done, a message specific path is
`
`built, and all subsequent packets in the same message shuttle through that path. The state
`
`associated with each path is message and component specific and each component uses this
`
`information for processing the data received from the previous component.
`
`The steps in this method are captured in the language of the claims as follows:
`
`A method “providing a plurality of components,”
`
`for the first packet of the message, “dynamically identifying a non-predefined
`sequence of components for processing the packets of a message such that the
`output format of the components of the non-predefined sequence match the
`input format of the next component in the non-predefined sequence,”
`
`and “wherein dynamically identifying includes selecting individual
`components to create the non-predefined sequence of components after the
`first packet is received; and
`
`
`
`
`
` 
`
`
`
`
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`6
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Juniper Ex. 1023-p. 9
`Juniper v Implicit
`
`

`

`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page10 of 21
`
`storing an indication of each of the identified components so that the non-
`predefined sequence does not need to be re-identified for subsequent packets
`of the message;”
`
`and “for each of a plurality of packets of the message,” storing, retrieving, and
`using state to process “the next packet of the message.”
`
`
`
` 
`
`
`
`
`See Dixon Decl., Ex. 5.
`
`Read together, these limitations describe constructing, post-first packet, a stateful,
`
`message specific data processing path – that is exactly what the claims say.
`
`B.
`
`Implicit’s Products and Sales.
`
`Implicit first offered for sale a commercial product based on its patents at the
`
`Consumer Electronics Show in January 2000. Thereafter, Implicit entered into significant
`
`development and sales contracts with Intel, AMD, Raytheon, and other sophisticated
`
`technology companies.
`
`These companies bought the Implicit technology precisely because it was new and
`
`novel at the time. For example, prior to entering into its first contract with Implicit, Intel had
`
`a senior engineer, David Anderson, conduct an engineering due diligence. See Hosie Decl.,
`
`Ex. A, Anderson Tr. at 64:12-24.
`
`
`
`
`
`
`
`
`
`
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`7
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Redacted
`
`Juniper Ex. 1023-p. 10
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page11 of 21
`
` All of this
`
`serves as commercial recognition of the value and novelty of Implicit’s technology.
`
`Although Juniper argues that Implicit has not shown any secondary indicia, and even
`
`though it relies on Dr. Calvert’s expert report on this point, Juniper did not even provide the
`
`Anderson transcript to Dr. Calvert. Hosie Decl., Ex. B, Calvert Depo. at 59:7-13.
`
`IV.
`
`THE PRESUMPTION OF VALIDITY MEANS SOMETHING HERE.
`
`How many reexams does it take? This patent has already gone through one reexam –
`
`surely, that means something.
`
`Not, evidently, to Juniper. Juniper now argues that the “Patent Office did not have all
`
`relevant information at its disposal during prosecution of the patents,” and so the
`
`presumption of validity really means little. Hosie Decl., Ex. C, Calvert Report at 4:26-28.
`
`When pressed at deposition about the “information” the PTO lacked, Dr. Calvert could only
`
`cite one missing reference: Mosberger. See Hosie Decl., Ex. B, Calvert Depo. at 103-105 (“I
`
`believe that in the initial prosecution, the initial prosecution history, the 1997 dissertation by
`
`Mosberger was not considered.… [A] piece that they didn’t have at their disposal was
`
`Mosberger.”).2 While Mosberger may be many things, missing is not among them:
`
`Mosberger was explicitly disclosed in the original prosecution,3 and rivers of ink spilled over
`
`Mosberger in the first reexam.
`
`After lunch, and after being prompted by Juniper’s lawyers (as Dr. Calvert was good
`
`enough to admit; Calvert at 124:8-9), Dr. Calvert then mentioned Kerr and Decasper as also
`
`missing. But it is clear from the transcript that this was more lawyer channeling than the
`
`independent thinking of an expert. Id.
`
`
`2
`He was asked this question repeatedly; “just Mosberger,” he repeatedly replied.
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`8
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Redacted
`
`Juniper Ex. 1023-p. 11
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page12 of 21
`
`Nor are Juniper’s “new” references in fact new, but instead cumulative over prior art
`
`disclosed. For example, Dietz, Method and Apparatus for Monitoring Traffic in a Network,
`
`6,651,099, cited in the first reexam and attached as Hosie Decl., Ex. D, involves an extended
`
`router that creates flows, keeps flow tables, classifies flows given packet identification, and
`
`maintains state. Decasper and Kerr are cumulative over Dietz, and Dietz was squarely before
`
`the PTO – it, like Mosberger, is cited on the face of the patent. Juniper’s Dr. Calvert had no
`
`idea whether Decasper and Kerr were cumulative over Dietz, as he did not look, even though
`
`he ventured the opinion that the presumption of validity means little here as the PTO was
`
`bereft of necessary information. Hosie Decl., Ex. B, Calvert Depo. at 118:14-20. (“I didn’t
`
`look at all of the patents that were cited as prior art.”).4
`
`V.
`
`DECASPER’S ROUTER DOES NOT ANTICIPATE.
`
`With that, to the meat of it: Decasper’s router is a much different beast than ʼ163’s
`
`demultiplexing system.
`
`A.
`
`Packets Stand Alone in a Router, the Very Converse of ʼ163.
`
`An IP router is a piece of networking gear that sits in the middle of an IP network,
`
`e.g., the Internet. IP packets come in, are inspected, and then forwarded along the network.
`
`By design, the packets of one message are not necessarily sent through the same series of
`
`routers. To the contrary, packets are broken up and may be sent through a multitude of
`
`different routers before arriving and being reassembled at the ultimate endpoint. For
`
`example, some packets in a VoIP (Voice Over IP) call from San Francisco to Chicago might
`
`go through routers in Seattle, and Omaha, while others might go through routers in Tulsa and
`
`
`3
`It is cited on the face of the patent.
`4
`Indeed, this witness professed not to even know what the question meant by “prior art
`similar to Decasper.” Id. at 118:22-119:3.
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`9
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 12
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page13 of 21
`
`Abilene, Texas, before being received and reassembled at the endpoint in Chicago. This is a
`
`deliberate design choice rooted in the defense-system origin of the Internet.
`
`By design, every IP packet stands alone. Each is independent; each can be seen and
`
`sent along without regard to any other IP packets. As Juniper puts it in a pretty lucid white
`
`paper, “Packet-based forwarding is performed on a packet-by-packet basis without regard to
`
`flow or state information. Each packet is assessed individually for treatment.” See Juniper
`
`White Paper: Understanding Packet-Based and Flow-Based Forwarding. Hosie Decl., Ex. E.
`
`As Juniper recognizes, “Packet-based forwarding does not require any information about
`
`either previous or subsequent packets that belong to a given connection….” Id.
`
`Flow-based processing as debated in this case5 is fundamentally unlike such packet-
`
`based routing. In flow-based processing, a “session” is created to ensure that all packets of a
`
`flow are treated similarly. No longer do packets stand alone, which is the object and goal of
`
`routing. To the contrary, flow-based processing absolutely requires that all packets of a flow
`
`be identified and collated with that flow. In contrast, a router is not even guaranteed to see
`
`all packets of a given message (Abilene; Omaha), much less being capable of processing
`
`packets of a message as a whole.
`
`Decasper is on the packet-based router side of this great divide. Decasper is an
`
`extended integrated services router. This type of router enhances traditional router
`
`functionality by adding some limited flexibility in how IP packets (and just IP packets; see
`
`below) are processed. Decasper accomplishes this by adding “gates” to the system. A gate is
`
`a place where the system can add a plug-in; a plug-in is a piece of code that does some form
`
`
`5
`ʼ163 and the infringing systems necessarily maintain state for the duration of a
`message. Absent this, the systems could not ensure that flows would be processed as flows
`or even support session-based protocols such as TCP.
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`10
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 13
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page14 of 21
`
`of IP packet processing. Although the ordering and number of the gates are compiled in, so
`
`that the actual processing done and the sequence of the processing is immutable absent
`
`recompiling the kernel, plug-ins can be upgraded at the gates and different plug-ins can be
`
`associated with different flows. The function at a gate is driven by the nature of the gate
`
`itself, e.g., a security gate will always be a security gate.
`
`Decasper is not guaranteed to see all the packets of a given message. It is a routing
`
`node in a network – some packets pass through, others may not. It is hard to process what
`
`you do not even see. As a consequence, as an IP router, Decasper has no ability to guarantee
`
`that “state” is maintained for all the packets of a given message.
`
`Along the same lines, because Decasper does not support plugins that operate at a
`
`higher level than IP, there is no inherent notion of a session in Decasper. Rather, Decasper
`
`uses the notion of “flows” as an optimization to group packets together but not to process all
`
`packets of a message with the same processing state. How could it? A Decasper router is
`
`not even guaranteed to see all the packets of a message since many of these packets will end
`
`up at different routers.
`
`A direct architectural implication of the fact that Decasper is an IP router is that
`
`Decasper maintains only “soft state.” See Dixon Decl., Ex. 1, Decasper at 9 (“to store per-
`
`flow ‘soft state’”). Soft state is defined as “state which is useful for efficiency, but not
`
`essential, as it can be regenerated or replaced if needed.” See Hosie Decl., Ex. F. As a
`
`consequence of this soft state only, Decasper might reset in the middle of processing any
`
`particular message, be it an e-mail, a Skype conversation, or a Juniper or F5 box serving as a
`
`proxy. See Decasper at 9 (“recycle” mid-flow); id. at 5 (dumping flow if idle). With such a
`
`random flush facility, Decasper could not do what Juniper and F5 products do. There is no
`
`room for debate on this.
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`11
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 14
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page15 of 21
`
`In distinction, ʼ163 (and the infringing systems) need “hard state” to operate as
`
`designed. Hard state means state that is required for correct function and state that cannot be
`
`flushed randomly without regard to the processing of flows.
`
`As another consequence of being an IP router, Decasper has no ability to process
`
`packets higher in the stack than IP. To go deeper into the packet, Decasper would have to be
`
`able to convert formats, match formats, and determine what to do post-TCP. To illustrate,
`
`the TCP module is required to collect all the packets of a given message, make sure that all
`
`packets are present, eliminate duplication, and ensure that the packets are in the right
`
`sequence. A TCP module can do this only if it is guaranteed to have all of the packets
`
`constituting a message. As a router is has all of the packets constituting a message, a router
`
`simply has no ability to do TCP protocol layer processing.6 As a router, Decasper has simply
`
`no ability to do any of this.
`
`In short, Decasper and ʼ163 are profoundly different systems. Equating them is like
`
`arguing that the Queen Mary is akin to a bicycle because both are made of steel and involve
`
`transport. But no one could build the Queen Mary from a bicycle or a bicycle from the
`
`schematics for the Queen Mary.
`
`B.
`
`Decasper Does Not Anticipate.
`
`
`
`Given this meta level difference, it is not surprising that Decasper does not anticipate
`
`the specific elements of the ʼ163 claims. Juniper likes Decasper because the vernacular
`
`makes it sound close to ʼ163: flows, components, gates. Here is how Decasper is different
`
`and why it does not anticipate:
`
`1.
`
`No Data Conversion; No Formats.
`
`IMPLICIT’S OPPOSITION TO JUNIPER/F5 NETWORKS’
`
`SUMMARY JUDGMENT MOTION ON INVALIDITY
`
`12
`
`
`
`
`
`Case No. C 10-3365 SI
`Case No. C 10-4234 SI
`
`
`
`Juniper Ex. 1023-p. 15
`Juniper v Implicit
`
`

`

`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`
`
`
`Case3:10-cv-04234-SI Document175 Filed11/16/12 Page16 of 21
`
`
`
`Decasper is premised on preserving the format of its one-size IP packets, exactly the
`
`opposite of the data conversion claim elements in ʼ163. See Nettles at 20, ¶64, 71-72.
`
`Decasper is a one format system that does not process packets above the IP layer – nor could
`
`it be extended to do so. IP packets come in; IP packets come out, and they are IP packets
`
`throughout. In Decasper, there is no reason to consider input and output formats; the formats
`
`match because that is the architecture of the underlying system. Decasper accordingly
`
`teaches a system in which format conversion is neither needed nor desirable, exactly the
`
`opposite of the ʼ163 claim limitations. Indeed, Decasper teaches away from conversion or
`
`processing up the stack in any form. See Nettles at 21, ¶ 72, 74-75.
`
`
`
`On this score, Juniper scrambles and argues that a given “component” in ʼ163 need
`
`not convert. Br. at 13. True, but it is a system that converts – that is the point. A system that
`
`is antithetical to conversion hardly discloses conversion.
`
`2.
`
`Decasper Does Not Maintain State, as Required by the Claims.
`
`
`
`Decasper does not maintain state as required by the claims of ʼ163. Given the
`
`specification and claims, ʼ163 absolutely requires that the system maintain state for the
`
`duration of a message. See claims excerpts above at 6 (maintain state for all packets of a
`
`message). First, and as noted above, as a router, Decasper is not even guaranteed to get all
`
`the packets of a message. This means that Decasper could not do any processing requiring
`
`that all packets of a message be identified and kept together as members of a larger whole.
`
`This coherency of the larger whole is essential to ʼ163, and explicit in its specification and
`
`claims.
`
`
`6
`And there are many protocols post-TCP in