`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________
`
`
`JUNIPER NETWORKS, INC.,
`
`“Petitioner”
`
`v.
`
`IMPLICIT, LLC,
`
`“Patent Owner”
`___________
`
`U.S. Patent No. 9,591,104
`
`Issued: March 7, 2017
`
`Named Inventor:
`Edward Balassanian
`
`Title: Method and System for Data Demultiplexing
`___________
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 9,591,104
`
`
`
`
`Mail Stop: PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`10788584
`
`
`
`
`

`

`TABLE OF CONTENTS
`
`Page
`INTRODUCTION ........................................................................................ 1
`
`STATE OF THE ART .................................................................................. 4
`
`I.
`
`II.
`
`III. THE PURPORTED INVENTION ............................................................... 6
`
`A.
`
`B.
`
`C.
`
`The ’104 Patent .................................................................................. 6
`
`History of the ’104 Patent .................................................................. 8
`
`Decasper’s Anticipation of the Broadly Similar Claims of the
`’163 Patent ........................................................................................ 10
`
`IV.
`
`325(D) DOES NOT APPLY TO THIS PETITION ................................... 12
`
`A.
`
`B.
`
`314(a) ................................................................................................ 12
`
`325(d) ............................................................................................... 13
`
`V.
`
`IDENTIFICATION OF CHALLENGE AND GROUNDS ....................... 16
`
`VI. LEVEL OF ORDINARY SKILL IN THE ART ........................................ 18
`
`VII. CLAIM CONSTRUCTION ....................................................................... 18
`
`A.
`
`B.
`
`C.
`
`D.
`
`“message” ......................................................................................... 18
`
`“sequence of two or more routines” ................................................. 18
`
`“state information” ........................................................................... 19
`
`“execute a Transmission Control Protocol (TCP) to process
`packets having a TCP format”/“execute TCP to process at
`least one of the subsequent packets having a TCP format” ............. 19
`
`E.
`
`“key value” ....................................................................................... 20
`
`VIII. GROUND 1: THE CHALLENGED CLAIMS ARE OBVIOUS
`OVER SMITH IN VIEW OF DECASPER ................................................ 20
`
`10788584
`
`
`- i -
`
`

`

`Page
`A. Overview .......................................................................................... 20
`
`B.
`
`C.
`
`Smith................................................................................................. 20
`
`Decasper ........................................................................................... 23
`
`i.
`
`ii.
`
`Extensibility via Modular Plugins ......................................... 23
`
`Classifying Packets (and TCP Connections) into Flows ....... 24
`
`iii. Binding Plugins to Flows Using Decasper’s
`Framework ............................................................................. 25
`
`D. Motivation To Combine ................................................................... 27
`
`E.
`
`F.
`
`G.
`
`H.
`
`I.
`
`J.
`
`K.
`
`L.
`
`The Combined Smith-Decasper System .......................................... 29
`
`Claim 1 ............................................................................................. 33
`
`Claim 2 ............................................................................................. 42
`
`Claim 3 ............................................................................................. 43
`
`Claim 4 ............................................................................................. 43
`
`Claim 5 ............................................................................................. 43
`
`Claim 6 ............................................................................................. 44
`
`Claim 7 ............................................................................................. 45
`
`M. Claim 10 ........................................................................................... 45
`
`N.
`
`O.
`
`P.
`
`Q.
`
`Claim 11 ........................................................................................... 47
`
`Claim 12 ........................................................................................... 48
`
`Claim 13 ........................................................................................... 48
`
`Claim 16 ........................................................................................... 48
`
`10788584
`
`
`- ii -
`
`

`

`Page
`Claim 19 ........................................................................................... 49
`
`Claim 20 ........................................................................................... 50
`
`R.
`
`S.
`
`IX. GROUND 2: THE CHALLENGED CLAIMS ARE OBVIOUS
`OVER CHECK POINT IN VIEW OF DECASPER .................................. 50
`
`A. Overview .......................................................................................... 50
`
`B.
`
`CheckPoint ....................................................................................... 51
`
`i.
`
`ii.
`
`Inspection Module.................................................................. 52
`
`Security Servers ..................................................................... 53
`
`iii. Anti-virus Inspection ............................................................. 54
`
`iv. Additional CVP Processing ................................................... 56
`
`C.
`
`Decasper ........................................................................................... 57
`
`D. Motivation To Combine ................................................................... 57
`
`E.
`
`F.
`
`G.
`
`H.
`
`I.
`
`J.
`
`K.
`
`L.
`
`The Combined CheckPoint-Decasper System ................................. 59
`
`Claim 1 ............................................................................................. 62
`
`Claim 2 ............................................................................................. 64
`
`Claim 3 ............................................................................................. 64
`
`Claim 4 ............................................................................................. 65
`
`Claim 5 ............................................................................................. 65
`
`Claim 6 ............................................................................................. 65
`
`Claim 7 ............................................................................................. 66
`
`M. Claim 10 ........................................................................................... 66
`
`10788584
`
`
`- iii -
`
`

`

`Page
`Claim 11 ........................................................................................... 68
`
`Claim 12 ........................................................................................... 68
`
`Claim 13 ........................................................................................... 69
`
`Claim 16 ........................................................................................... 69
`
`Claim 19 ........................................................................................... 70
`
`Claim 20 ........................................................................................... 70
`
`N.
`
`O.
`
`P.
`
`Q.
`
`R.
`
`S.
`
`X.
`
`STATUTORY REQUIREMENTS ............................................................ 70
`
`A. Notice of Real Party-In-Interest (37 C.F.R. § 42.8(b)(1)) ............... 70
`
`B.
`
`C.
`
`D.
`
`E.
`
`F.
`
`Notice of Related Matters (37 C.F.R. § 42.8(b)(2)) ......................... 70
`
`Designation of Lead And Back-Up Counsel (37 C.F.R.
`§ 42.8(b)(3)) ..................................................................................... 72
`
`Service Information (37 C.F.R. § 42.8(b)(4)) .................................. 72
`
`Fees ................................................................................................... 72
`
`Grounds for Standing ....................................................................... 72
`
`XI. CONCLUSION ........................................................................................... 73
`
`
`
`10788584
`
`
`- iv -
`
`

`

`
`
`EXHIBIT LIST
`
`Exhibit Description
`1001
`U.S. Patent No. 6,629,163 (“the ’163 patent”)
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`1015
`
`1016
`
`10788584
`
`
`File History of the ’163 patent
`
`U.S. Patent No. 8,694,683 (“the ’683 patent”)
`
`File History of the ’683 patent
`
`U.S. Patent No. 9,270,790 (“the ’790 patent”)
`
`U.S. Patent No. 9,591,104 (“the ’104 patent”)
`
`U.S. Patent No. 10,027,780 (“the ’780 patent”)
`
`U.S. Patent No. 10,033,839 (“the ’839 patent”)
`
`U.S. Patent No. 10,225,378 (“the ’378 patent”)
`
`File History of the ’104 patent
`
`Expert Declaration of Dr. Seth Nielson (“Nielson Dec.”) – Ex. A
`Curriculum Vitae of Dr. Nielson
`
`J. Mark Smith et al., “Protecting a Private Network: The AltaVista
`Firewall,” Digital Technical Journal, Vol. 9, No. 2 (1997) (“Smith”)
`
`Declarations of S.D. Hall-Ellis and D. Ramsey; supporting exhibits &
`attachments
`
`D. Decasper et al., “Router Plugins, A Software Architecture for Next
`Generation Routers, ACM SIGCOMM Computer Communication
`Review, Vol. 28, No. 4, October 1998 (“Decasper”)
`
`Declaration of Martin L. Knott & Exhibit (Decasper)
`
`Selected webpages from www.checkpoint.com, as archived by the
`Internet Archive’s WayBack Machine on February 12, 1998
`(“CheckPoint”), and Affidavit of Christopher Butler
`
`- v -
`
`

`

`1017
`
`1018
`
`1019
`
`1020
`
`1021
`
`1022
`
`1023
`
`1024
`
`1025
`
`1026
`
`1027
`
`1028
`
`1029
`
`
`
`Request for Inter Partes Reexamination of the ’163 patent, February 13,
`2012
`
`Office Action in Inter Partes Reexamination of the ’163 patent, August
`16, 2013
`
`Action Closing Prosecution in Inter Partes Reexamination of the ’163
`patent, October 1, 2012
`
`Patent Owner Comments to Action Closing Prosecution in Inter Partes
`Reexamination of the ’163 patent, December 12, 2012
`
`Decision Vacating Inter Partes Reexamination of the ’163 patent,
`December 12, 2013
`
`Order Granting Defendants’ Motion for Summary Judgment, March 13,
`2013
`
`Opposition to Defendants’ Motion for Summary Judgment, November
`16, 2012
`
`Joint Claim Construction and Prehearing Statement Pursuant to P.R. 4-
`3, November 26, 2019
`
`Exhibit A to Joint Claim Construction and Prehearing Statement
`Pursuant to P.R. 4-3, November 26, 2019
`
`Exhibit B to Joint Claim Construction and Prehearing Statement
`Pursuant to P.R. 4-3, November 26, 2019
`
`Implicit, LLC v. Trend Micro, Inc., Case No. 6:16-cv-80-JRG, Claim
`Construction Memorandum and Order, March 29, 2017
`
`Implicit, LLC v. Netscout Systems, Inc. et al., Case No. 2:18-CV-53-
`JRG, Claim Construction Memorandum and Order, April 15, 2019
`
`Implicit, LLC v. Huawei Technologies USA, Inc. et al., Case No. 6:17-
`CV-182-JRG, Claim Construction Memorandum and Order, March 6,
`2018
`
`1030 W. Richards Stevens, TCP/IP Illustrated Volume 1, The Protocols,
`Addison-Wesley Professional Computing Series, 1994
`
`10788584
`
`
`- vi -
`
`

`

`
`
`RFC 2068, Hypertext Transfer Protocol -- HTTP/1.1, January 1997
`
`R. Hunt, Internet/Intranet firewall security – policy, architecture and
`transaction services, Computer Communications 21 (1998) 1107-1123
`
`Check Point Company Overview
`
`Awards and Recognition – Check Point
`
`Check Point Newsletter, 1997
`
`CheckPoint FireWall-1 White Paper, Version 2.0, 1995
`
`RFC 1825, Security Architecture for the Internet Protocol, August 1995
`
`RFC 1826, IP Authentication Header, August 1995
`
`RFC 1827, IP Encapsulating Security Payload (ESP), August 1995
`
`The SSL Protocol, Version 3.0, November 18, 1996.
`
`First Amended Complaint for Patent Infringement, Civil Action No.
`2:19-cv-37-JRG-RSP, March 19, 2019
`
`Original Complaint and Demand for Jury Trial, Case No. C 10-4234
`EDL, September 20, 2010
`
`K. Jonas et al., “Audio streaming on the Internet. Experiences with real-
`time streaming of audio streams,” ISIE '97 Proceeding of the IEEE
`International Symposium on Industrial Electronics, 1997.
`
`L. Peterson at al., “Computer Networks, A System Approach,” Morgan
`Kaufman Publishers, Inc., 1996.
`
`B. Godwin-Jones, “Emerging Technologies, Real-time Audio and Video
`Playback on the Web,” Language Learning & Technology, vol. 1, no. 1,
`July 1997.
`
`S. Bellovin et al., “Network Firewalls,” IEEE Communications
`Magazine, 1994.
`
`RFC 791, Internet Protocol, September 1981
`
`RFC 793, Transmission Control Protocol, September 1981
`
`- vii -
`
`1031
`
`1032
`
`1033
`
`1034
`
`1035
`
`1036
`
`1037
`
`1038
`
`1039
`
`1040
`
`1041
`
`1042
`
`1043
`
`1044
`
`1045
`
`1046
`
`1047
`
`1048
`
`10788584
`
`
`

`

`
`
`RFC 879, The TCP Maximum Segment Size and Related Topics,
`November 1983
`
`RFC 1919, Classical versus Transparent IP Proxies, March 1996
`
`RFC 1945, Hypertext Transfer Protocol – HTTP/1.0, May 1996
`
`SSL 0.2 Protocol Specification, Netscape Communications Corp.,
`February 9, 1995
`
`A. Luotonen et al., “World-Wide Web Proxies,” Computer Networks
`and ISDN Systsems 27 (1994) 147-154
`
`RFC 854, Telnet Protocol Specification, May 1983
`
`RFC 959, File Transfer Protocol, October 1985
`
`RFC 788, Simple Mail Transfer Protocol, November 1981
`
`RFC 2616, Hypertext Transfer Protocol – HTTP/1/1, June 1999
`
`1049
`
`1050
`
`1051
`
`1052
`
`1053
`
`1054
`
`1055
`
`1056
`
`1057
`
`
`
`
`
`10788584
`
`
`- viii -
`
`

`

`U.S. Patent No. 9,591,104
`
`I.
`
`INTRODUCTION
`The ’104 patent descends from and shares the same specification as U.S.
`
`Patent No. 6,629,163 (“the ’163 patent”)(Ex. 1001), whose main claims were found
`
`by a district court to be anticipated in light of the same Decasper reference relied on
`
`here.1 The ’104 patent claims the same basic approach as the ’163 patent of
`
`identifying an appropriate sequence of routines to process incoming packets from a
`
`network (see Section III.C). In fact, Patent Owner now asserts the ’104 patent
`
`against the very same products that it had earlier accused of infringing the ‘163
`
`patent—thus further demonstrating the significant overlap between the claims of
`
`these two patents.2
`
`
`1 See generally Ex. 1022 (finding Decasper anticipates independent claims 1,
`
`15 and 35 of the ’163 patent). These claims were also rejected over Decasper as
`
`being anticipated/obvious during an inter partes reexamination of the ’163 patent
`
`(“the ’163 reexam), which was later vacated in light of the district court decision.
`
`See Ex. 1018; Ex. 1021 at 3.
`
`2 E.g., Juniper’s SRX Series Gateways are accused of infringing the ’104
`
`patent (Ex. 1041 at 5), just as they were accused of infringing the ’163 patent (Ex.
`
`1042 at 3).
`
`10788584
`
`
`- 1 -
`
`

`

`U.S. Patent No. 9,591,104
`
`
`To distinguish Decasper during prosecution of a parent patent (the ’683
`
`patent), the Patent Owner merely added a trivial new limitation that one of the
`
`routines must execute a transport layer protocol specifically, such as TCP, arguing
`
`that Decasper is limited to an IP router that processes packets using only the IP
`
`protocol, not TCP.3 Ex. 1004 at 13-20. This limitation is also found in the claims
`
`of the ’104 patent. However, as detailed below, there is nothing novel or invention-
`
`worthy about executing well-known protocols.
`
`Nevertheless, Decasper is not limited to IP routers, but rather describes an
`
`example of how its framework can be used in the context of an IP router. This
`
`example is the linchpin for Patent Owner’s argument during prosecution that
`
`Decasper can only process IP packets and not TCP packets, as required by the ’683
`
`patent (which is also required by the ’104 patent). But Patent Owner failed to
`
`mention to the examiner that Decasper’s framework is not limited to the given
`
`example of an IP router, as explained by Decasper:
`
`Our framework is also very well suited to Application
`Layer Gateways (ALGs), and to security devices like
`Firewalls. In both situations, it is very important to be able
`to quickly and efficiently classify packets into flows, and
`
`
`3 Exhibit citations refer to page numbers added by the Petitioner, except in
`
`the case of Ex. 1011 (Nielson), which references paragraph numbers.
`
`10788584
`
`
`- 2 -
`
`

`

`U.S. Patent No. 9,591,104
`
`
`to apply different policies to different flows: these are both
`things that our architecture excels at doing.
`
`Ex. 1014 (Decasper) at 2.4 As a POSA would recognize, ALGs and firewalls often
`
`have to execute TCP in order to perform their basic functions—and the Decasper
`
`framework is indeed “very well suited” to such TCP functions as well. Ex. 1011
`
`(hereinafter “Nielson”) at ¶¶123-128, 379-391. Patent Owner’s attempt to
`
`distinguish around Decasper with the trivial limitation of TCP is untenable, given
`
`Decasper’s direct advice to apply itself to applications that require performing
`
`TCP—such as Smith and CheckPoint.
`
`It is in these further examples of implementing Decasper’s framework,
`
`neither considered by the examiner, that Decasper is relied upon here. Specifically,
`
`Ground 1 applies Decasper to an ALG firewall (Smith), and Ground 2 applies
`
`Decasper to a firewall (CheckPoint). Smith and CheckPoint each clearly perform
`
`the trivial TCP requirement added by Patent Owner, while Decasper’s framework
`
`continues to carry out the packet processing approach that was already found to
`
`anticipate the broadly similar claims of the parent ’163 patent. As such, the ’104
`
`patent is just as unpatentable as the parent ’163 patent before it.
`
`
`4 All emphasis added unless otherwise indicated.
`
`10788584
`
`
`- 3 -
`
`

`

`U.S. Patent No. 9,591,104
`
`II.
`
`STATE OF THE ART
`At the time of the ’104 patent, many computer networks (including the global
`
`Internet) were packet-based networks in which messages are communicated from
`
`one computer to another by breaking them up into discrete blocks called “packets”
`
`that are then reassembled into the original messages after they have traveled through
`
`the network. Nielson at ¶15.
`
`Transmitting messages over a packet-based network
`
`required
`
`the
`
`development of a standardized suites of protocols—a pre-established set of rules for
`
`communication—that the host computers and shared nodes of the network could
`
`follow. Id. These protocols include certain network protocols, such as TCP
`
`(Transmission Control Protocol) and IP (Internet Protocol). Id. These protocols tell
`
`each machine on the network how to form, transmit, process, and respond to
`
`messages.
`
`Network architects divided network communications responsibilities into
`
`different protocols in part because a single protocol would have been exceedingly
`
`complex and less versatile. Id. However, the use of multiple protocols (such as
`
`HTTP, TCP, and IP) has the natural consequence that even a single transfer of data
`
`across the Internet (in response, for example, to a single user’s visit to one web page)
`
`involves a multitude of conversions of data from one format into another. Id. The
`
`various protocol components that work together form a “network stack.” A
`
`10788584
`
`
`- 4 -
`
`

`

`U.S. Patent No. 9,591,104
`
`conceptual reference model for network stacks—a group of protocols that work
`
`together to process data—was created in the 1970’s and 1980’s called the Open
`
`Systems Interconnection model (OSI model). This model did not identify specific
`
`protocols such as TCP or IP, but rather defined what a protocol at a specific
`
`numbered layer should do. The OSI model defined 7 layers as shown below,
`
`illustrating also how one layer is encapsulated inside another by showing the data
`
`and the various headers present at each layer:
`
`In practice, most networking applications and devices deal with only layer 2
`
`(Data Link), such as Ethernet and Wifi, layer 3 (Network), such as IP, layer 4
`
`(Transport), such as TCP and UDP, and layer 7 (Application).
`
`
`
`10788584
`
`
`- 5 -
`
`

`

`U.S. Patent No. 9,591,104
`
`III. THE PURPORTED INVENTION
`A. The ’104 Patent
`
`The ’104 patent describes itself as relating “generally to a computer system
`
`for data demultiplexing.” Ex. 1006 (’104 patent) at 1:22-23. The ’104 patent
`
`purports to address issues associated with the need to convert packet-based data into
`
`“many different intermediate formats” when transmitting data from one computer to
`
`another. Id. at 1:28-30.
`
`The ’104 patent suggests that its advantage lies in being able to “dynamically”
`
`identify a series of conversion routines for processing data. Id. at 2:8-10. This
`
`“dynamic” approach involves using a key value in one or more received packets to
`
`identify a sequence of two or more routines to process packets having a TCP format.
`
`Id. at 14:40-57 (claim 1).
`
`Figure 4 of the ’104 patent shows the “paths” for received packets from
`
`bottom to top in the figure.
`
`10788584
`
`
`- 6 -
`
`

`

`U.S. Patent No. 9,591,104
`
`
`
`
`
`
`Each rectangle in Figure 4 (highlighted in green) represents a session 410,
`
`420, 430, 440, 450 for a protocol, where the session includes an instance of the
`
`protocol and state information for that instance of the protocol. Id. at 5:51-55. Each
`
`protocol session has an edge 411, 421, 431 (which is a conversion routine) to which
`
`10788584
`
`
`- 7 -
`
`

`

`U.S. Patent No. 9,591,104
`
`a corresponding binding 412, 422, 432, 442, 452 (highlighted in red) is used to bind
`
`or “nail” one or more paths to that protocol session. Id. at 6:5-11; see also Nielson
`
`at ¶49-53.
`
`Following the blue line in Figure 4 above starting at the entry, the queue (472)
`
`receives a packet and passes it to an Ethernet session (labeled 410) at the entry
`
`labeled 414. That routine processes the packet at the Ethernet level, converts the
`
`packet to an IP packet, and passes the packet to the IP session (labeled 420) at the
`
`path entry labeled 424. The IP session processes the packet at the IP level, converts
`
`the packet to a TCP packet, and then passes the packet to a particular TCP session
`
`(labeled 440) at path entry 443. Id. at 54-57. The TCP session converts the packet
`
`to another format and the packet continues along the path. Id.
`
`B. History of the ’104 Patent
`
`The ’104 patent is one of a series of continuations of U.S. Patent Application
`
`No. 09/474,464, which was filed on December 29, 1999 and issued as the above-
`
`mentioned ’163 patent. Id. The ’163 patent and the ’104 patent share a common
`
`specification.
`
`The ’163 patent was the subject of an inter partes reexamination during which
`
`the examiner found independent claims 1, 15 and 35 to be anticipated or rendered
`
`obvious by Decasper. Ex. 1018; see also supra fn 1. The Patent Owner attempted
`
`to distinguish Decasper by arguing, inter alia, that “[t]he packets of Decasper always
`
`10788584
`
`
`- 8 -
`
`

`

`U.S. Patent No. 9,591,104
`
`have the same format (IP), and therefore, by definition, do not have ‘different
`
`formatting needs.’” Ex. 1020 at 21-22. The examiner rejected this argument because
`
`the word “format” is broad and “does not state any particular format such as IP, TCP,
`
`Ethernet or HTTP etc.” Ex. 1018 at 16; see also generally id. at 13-19.
`
`Around this same timeframe, and three months after claims of the parent ’163
`
`patent were found by a district court to be anticipated by Decasper (Ex. 1022), the
`
`application that led to the parent ’683 patent was filed with broadly similar claims
`
`(see Section III.C), albeit with the additional requirement of executing a transport
`
`layer protocol specifically, such as TCP, to convert packets to a “different format”
`
`or “different protocol.”5 Alongside these claims, the applicant included remarks
`
`characterizing Decasper as being limited to the IP protocol—arguing that Decasper
`
`taught “operat[ing] on IP packets only and thus execut[ing] the IP protocol but not
`
`other protocols,” and that “nothing in Decasper contemplates processing a non-IP
`
`packet format such as a TCP packet.” Ex. 1004 at 13-20. The examiner did not
`
`comment on this characterization of Decasper, which is incorrect for the reasons
`
`discussed below in at least Sections VIII.C & VIII.E.
`
`
`5 For purposes of this proceeding, Petitioner interprets the term “executing”
`
`TCP, in the context of the ’104 patent, to mean operating on a packet whose
`
`outermost header is TCP, respectively. See Section VII.E.
`
`10788584
`
`
`- 9 -
`
`

`

`U.S. Patent No. 9,591,104
`
`
`After an obviousness rejection in view of other art and amendments made to
`
`include specific recitation that subsequent packets in the message would be
`
`processed using the same sequence of routines, the examiner allowed the claims. Id.
`
`at 263-284.
`
`The Patent Owner’s comments with respect to Decasper were not expressly
`
`repeated during prosecution of the ’104 patent, but were incorporated by reference.
`
`Ex.1010 (’104 file history) at 10. The claims of the ’104 patent, added by
`
`preliminary amendment during prosecution, were subject to a first action allowance.
`
`Id. at 224-231.
`
`C. Decasper’s Anticipation of the Broadly Similar Claims of the ’163
`Patent
`
`The claims of the ’104 patent are broadly similar to the claims of the ’163
`
`patent that were found to be anticipated by Decasper in a final district court decision.
`
`Ex. 1022 at 12; Nielson at ¶¶75-77. These similarities are evident from the overlap
`
`between the products Patent Owner previously accused of infringing the ’163 patent
`
`to the products Patent Owner now accuses as infringing the ’104 patent in a parallel
`
`litigation. See supra at fn 2.
`
`The broad similarities are also evidenced by the language of the claims, as
`
`explained by Patent Owner itself. For example, in the context of the ’163 patent,
`
`Patent Owner explained to a district court that “[i]n Implicit’s systems individual
`
`code processing functions were captured in individual code modules, known as
`
`10788584
`
`
`- 10 -
`
`

`

`U.S. Patent No. 9,591,104
`
`“beads.”6 “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.” Ex. 1023 at 7. Patent Owner further
`
`explained that “[u]nlike [the] 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.” Ex. 1023 at 8. This feature, which was found
`
`by the district court to be disclosed by Decasper, was reflected in the claims of the
`
`’163 patent as “for the first packet of the message, dynamically identifying a non-
`
`predefined sequence of components for processing the packets of the message….”
`
`Id. at 9; Ex. 1001 at 29. The ’104 patent contains essentially the same feature—
`
`found by the district court to be disclosed in Decasper—by reciting that a sequence
`
`of routines is identified using a key value based on information in a received packet
`
`of a message, where packets are processed using the sequence of routines. See e.g.,
`
`Ex. 1006 (’104 patent), Claim 1.
`
`Patent Owner further explained to the district court that “a message specific
`
`path is built, and all subsequent packets in the same message shuttle through that
`
`path,” and that when read together, the claim “limitations describe constructing,
`
`post-first packet, a stateful, message specific data processing path – that is exactly
`
`
`6 Decasper calls these plugins. See Section VIII.C.i.
`
`10788584
`
`
`- 11 -
`
`

`

`U.S. Patent No. 9,591,104
`
`what the claims say.” Ex. 1023 at 9-10. This feature, also found to be disclosed by
`
`Decasper, was recited in the claims of the ’163 patent as “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….” Id. at 10; Ex. 1001 at
`
`29. The ’104 patent again contains essentially the same feature by reciting that a
`
`path is created that includes data structures that indicate the identified sequence of
`
`routines, where subsequent packets are processed using this sequence of routines
`
`indicated in the path. See e.g., Ex. 1006 (’104 patent), Claim 1.
`
`IV. 325(D) DOES NOT APPLY TO THIS PETITION
`A.
`314(a)
`
`The Board should not exercise its discretion under Section 314(a) for at least
`
`the following reasons (following the General Plastic Factors)7: First, no other
`
`petition has been filed against the ’104 patent, whether by Petitioner or otherwise.
`
`Second, because there are no earlier petitions, Factors 2-5 do not apply. Third, only
`
`two grounds of attack are presented for consideration (Factor 6). Fourth, parallel
`
`litigation between the parties will not prevent the issuance of a final written decision
`
`
`7 Gen. Plastic Indus. Co. v. Canon Kabushiki Kaisha, Case IPR2016-01357
`
`et al., Paper 19 (Sept. 6 2017).
`
`10788584
`
`
`- 12 -
`
`

`

`U.S. Patent No. 9,591,104
`
`within 1 year (Factor 7). Implicit, LLC v. Juniper Networks, Inc., Case No. 2:19-cv-
`
`00037-JRG-RSP (E.D. Tex.).
`
`Additional factors that weigh in favor of institution include: (1) the trial date
`
`in the parallel litigation, currently scheduled for July 6, 2020, can change; (2) the
`
`claims challenged here include additional claims beyond those asserted in the
`
`parallel litigation; (3) the strong merits of the petition, which is based on prior art
`
`already found to anticipate broadly similar claims of a parent patent. See Sections I
`
`and III.B-C.
`
`B.
`
`325(d)
`
`In exercising its discretion, the Board “may take into account whether, and
`
`reject the petition or request because, the same or substantially the same prior art or
`
`arguments previously were presented to the Office.” 35 U.S.C. § 325(d).
`
`Previously, the Board has identified six non-exhaustive factors in Becton, Dickinson
`
`& Co. v. B. Braun Melsungen AG, IPR2017-01586 (Dec. 15, 2017). As analyzed
`
`below, the Becton factors do not weigh in favor of exercising discretion under §
`
`325(d).
`
`Factors 1 and 2: (1) the similarities and material differences between the
`asserted art and the prior art involved during examination; and (2) the
`cumulative nature of the asserted art and the prior art evaluated during
`examination
`Petitioner acknowledges that, although not commented on by the examiner,
`
`Decasper was specifically discussed by Patent Owner during the prosecution of the
`
`10788584
`
`
`- 13 -
`
`

`

`U.S. Patent No. 9,591,104
`
`parent ’683 patent. However, the Office never considered whether the supposedly
`
`missing limitations were otherwise known elsewhere in the art and whether their
`
`incorporation would have been obvious to a POSA. Nielson at ¶¶610-611. Here,
`
`Petitioner presents Smith and CheckPoint for the supposedly missing limitations and
`
`explains why a POSA, in light of Decasper’s own disclosure that it is “very well
`
`suited” to ALGs (Smith) and firewalls (CheckPoint), would have had a reason to
`
`combine each of these references with Decasper’s framework. See Sections VIII.D,
`
`IX.D (collectively describing motivations to combine).
`
`Of note, neither Smith nor CheckPoint was considered during the ’104
`
`prosecution or are substantially similar to any art substantively considered by the
`
`examiner during the prosecution. Nielson at ¶602. And these references are used to
`
`provide the specific teaching that Patent Owner argued was missing from Decasper
`
`during prosecution. In particular, the Patent Owner argued during prosecution of the
`
`parent ’683 patent that Decasper does not disclose executing TCP to convert packets
`
`to a different format. Ex. 1004, p. 19. And, while the examiner did not comment on
`
`this characterization of Decasper, the examiner presumably relied on it as the claims
`
`were subsequently allowed over Decasper. When a petitioner includes previously
`
`unconsidered references for an allegedly missing limitation, that factor weighs
`
`against exercising discretion under 325(d). Vestas-American Wind Technology, Inc.
`
`v. General Elec. Co., IPR2018-01015, Paper 9 at 23 (PTAB, Nov. 14, 2018).
`
`107885