`v.
`Packet Intelligence LLC
`IPR2020-00336 (U.S. Patent No. Patent 6,665,725)
`IPR2020-00337 (U.S. Patent No. Patent 6,771,646)
`
`Inter Partes Review – Final Hearing
`
`June 9, 2021
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`1
`
`
`
`Instituted Grounds
`
`Patent
`
`Claims
`
`Statutory Basis
`
`Reference
`
`’725 Patent
`
`10, 12, 13, 16, 17
`
`§ 103(a)
`
`Riddle, Baker
`
`’725 Patent
`
`10, 12, 13, 16, 17
`
`§ 103(a)
`
`Riddle, Baker, Yu
`
`’725 Patent
`
`10, 12, 13, 16, 17
`
`§ 103(a)
`
`Riddle, Baker, RFC1945
`
`’646 Patent
`
`1-3, 7, 16, 18
`
`§ 103(a)
`
`Riddle, Ferdinand, Wakeman
`
`’646 Patent
`
`1-3, 7, 16, 18
`
`§ 103(a)
`
`Riddle, Ferdinand, Wakeman, Yu
`
`’646 Patent
`
`1-3, 7, 16, 18
`
`§ 103(a)
`
`Riddle, Ferdinand, Wakeman, RFC1945
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`2
`
`
`
`Burden of Proof for Invalidity
`
`The petitioners bear the burden of
`proving a proposition of unpatentability
`by a preponderance of the evidence.
`
`35 U.S.C. § 316(e)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`3
`
`
`
`Legal Requirements for Obviousness
`
`Petitioners must show that “the differences between the
`subject matter sought to be patented and the prior art are such
`that the subject matter as a whole would have been obvious
`at the time the invention was made to a person having ordinary
`skill in the art to which said subject matter pertains.”
`
`35 U.S.C. § 103
`
`The PTAB must make “a searching comparison of the
`claimed invention—including all its limitations—with the
`teachings of the prior art.’”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`In re Ochiai, 71 F.3d 1565, 1572 (Fed. Cir. 1995).
`
`4
`
`
`
`’725 Patent Independent Claims
`
`Claim 10
`
`Claim 17
`
`10. A method of performing protocol specific operations
`on a packet passing through a connection point on a
`computer network, the method comprising:
`
`17. A method of performing protocol specific operations
`on a packet passing through a connection point on a
`computer network, the method comprising:
`
`(a) receiving the packet;
`
`(a) receiving the packet;
`
`(b) receiving a set of protocol descriptions…
`
`(b) receiving a set of protocol descriptions…
`
`(c) performing the protocol specific operations on the
`packet…,
`
`(c) performing the protocol specific operations on the
`packet…,
`
`wherein the protocol specific operations include one or
`more parsing and extraction operations on the packet to
`extract selected portions of the packet to form a function
`of the selected portions for identifying the packet as
`belonging to a conversational flow.
`
`wherein the packet belongs to a conversational flow of
`packets having a set of one or more states,
`
`and wherein the protocol specific operations include one
`or more state processing operations that are a function of
`the state of the conversational flow of the packet, the
`state of the conversational flow of the packet being
`indicative of the sequence of any previously encountered
`packets of the same conversational flow as the packet.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`5
`
`
`
`‘725 Patent State-based Claims
`
`Claim 16
`
`Claim 17
`
`16. A method according to claim 10,
`
`wherein the protocol specific operations further include
`one or more state processing operations that are a
`function of the state of the flow of the packet.
`
`17. A method of performing protocol specific operations
`on a packet passing through a connection point on a
`computer network, the method comprising:
`
`(a) receiving the packet;
`
`(b) receiving a set of protocol descriptions…
`
`(c) performing the protocol specific operations on the
`packet…,
`
`wherein the packet belongs to a conversational flow of
`packets having a set of one or more states,
`
`and wherein the protocol specific operations include one
`or more state processing operations that are a function of
`the state of the conversational flow of the packet, the
`state of the conversational flow of the packet being
`indicative of the sequence of any previously encountered
`packets of the same conversational flow as the packet.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`6
`
`
`
`’646 Patent Independent Claims
`
`Claim 1
`
`Claim 7
`
`1. A packet monitor…comprising:
`
`7. A packet monitor…comprising:
`
`(a) a packet acquisition device…;
`
`a packet acquisition device…;
`
`(b) a memory for storing a database comprising flow-entries for
`previously encountered conversational flows to which a received
`packet may belong, a conversational flow being an exchange of
`one or more packets in any direction as a result of an activity
`corresponding to the flow;
`
`(c) a cache subsystem…;
`
`(d) a lookup engine…; and
`
`(e) a state processor…to perform any state operations specified
`for the state of the flow starting from the last encountered state
`of the flow in the case that the packet is from an existing flow, and
`to perform any state operations required for the initial state of
`the new flow in the case that the packet is from an existing flow.
`
`an input buffer memory…;
`
`a parser subsystem…;
`
`a memory to storing a database of one or more flow-entries for
`any previously encountered conversational flows, each flow-
`entry identified by identifying information stored in the flow-
`entry;
`
`a lookup engine…;
`
`a cache subsystem…; and
`
`a flow insertion engine…,
`
`the lookup engine configured such that…,
`
`wherein the operation of the parser subsystem depends on one
`or more of the protocols to which the packet conforms.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`7
`
`
`
`’646 Patent Independent Claims
`
`Claim 16
`
`16. A method of examining packets passing through a connection point on a computer network, each
`packets conforming to one or more protocols, the method comprising:
`
`(a) receiving a packet from a packet acquisition device;
`
`(b) performing one or more parsing/extraction operations on the packet to create a parser record
`comprising a function of selected portions of the packet;
`
`(c) looking up a flow-entry database comprising none or more flow-entries for previously encountered
`conversational flows, the looking up using at least some of the selected packet portions and determining if
`the packet is of an existing flow, the lookup being via a cache;
`
`(d) if the packet is of an existing flow, classifying the packet as belonging to the found existing flow; and
`
`(e) if the packet is of a new flow, storing a new flow-entry for the new flow in the flow-entry database,
`including identifying information for future packets to be identified with the new flow-entry,
`
`wherein the parsing/extraction operations depend on one or more of the protocols to which the packet
`conforms.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`8
`
`
`
`’646 Patent State-based Claims
`
`Claim 1
`
`1. A packet monitor…comprising:
`
`(a) a packet acquisition device…;
`
`(b) a memory for storing a database comprising flow-entries for previously encountered conversational flows
`to which a received packet may belong, a conversational flow being an exchange of one or more packets in
`any direction as a result of an activity corresponding to the flow;
`
`(c) a cache subsystem…;
`
`(d) a lookup engine…; and
`
`(e) a state processor…to perform any state operations specified for the state of the flow starting from the
`last encountered state of the flow in the case that the packet is from an existing flow, and to perform any
`state operations required for the initial state of the new flow in the case that the packet is from an existing
`flow.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`9
`
`
`
`’646 Patent Associative Cache Claim
`
`Claim 3
`3. A packet monitor according to claim 2,
`
`wherein the cache subsystem is an associative cache subsystem including one or more
`content addressable memory cells (CAMs).
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`10
`
`
`
`Level of Ordinary Skill in the Art
`
`The Board adopted the level of ordinary skill in the art found
`in a prior, related proceeding. (Paper 21, 26-27)
`
`[W]e conclude that a person of ordinary skill in the art would have had a
`bachelor’s degree in electrical engineering, computer engineering, computer
`science, or a related field (or its equivalent), and one to two years of experience
`working in networking environments, including at least some experience with
`network traffic monitors and/or analyzers.
`
`IPR2017-00450, Paper 8 at 14.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`IPR2020-00336, Paper 21 at 26-27
`
`11
`
`
`
`Construction of “conversational flow”
`
`Board’s Construction
`
`• “[the] sequence of packets that are exchanged in any direction as a
`result of an activity” (IPR2020-00336, Paper 21 at 31)
`
`• Patent Owner’s Construction
`
`• “the sequence of packets that are exchanged in any direction as a
`result of an activity—for instance, the running of an application on a
`server as requested by a client—and where some conversational
`flows involved more than one connection, and some even involve
`more than one exchange of packets between a client and server”
`(IPR2020-00336, Paper 7 at 22-23)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`12
`
`
`
`Patent Owner’s Construction Is Proper
`
`The exemplary language that forms part of the specification’s
`explicit definition of conversational flow gives meaning to both
`“conversational flow” and “activity”
`
`“The specification acts as a dictionary when it expressly defines
`terms used in the claims or when it defines terms by
`implication.”
`
`Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)
`
`The Federal Circuit has previously affirmed constructions based
`on definitional language from the specification that included
`exemplary language. See Realtime Data, LLC v. Stanley, 554 F.
`App’x 923, 932- 33 (Fed. Cir. 2014)
`
`(IPR2020-00336, Paper 26 at 22-24; Paper 32 at 4)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`13
`
`
`
`“activity” implicates a specific client
`
`• “conversational flow” must relate to a conversation, which involves
`an application activity involving the same client.
`
`• A single conversational flow does not relate to every activity of the
`same type.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`(IPR2020-00336, Paper 26 at 25; Paper 32 at 4)
`
`14
`
`
`
`Independent Conversations - Different Activities of Same Type
`
`Different activities of the same application type (e.g., Skype, FTP, etc.) are
`recognized as different conversations
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`(IPR2020-00336, Paper 7 at 40)
`
`15
`
`
`
`Conversational flow ≠ application type
`
`Grouping traffic by application type does not teach recognizing
`conversational flows
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`(IPR2020-00336, Paper 7 at 42)
`
`16
`
`
`
`Activity Instance vs. Activity Type
`
`Conversational flow recognition requires recognizing activity instances on a
`per-client basis
`
`Recognition of Activity Instances
`
`Recognition of Activity Type
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`17
`
`
`
`Flow Overview
`
`’099 Patent at 12:4- 5
`
`’099 Patent at 2:35-37
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`18
`
`
`
`Network activity occurs between specific entities
`
`The specification describes the nature of an activity:
`
`’099 Patent at 2:39-40
`
`’099 Patent at 9:14-19
`
`19
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`
`
`Network activity occurs between specific entities
`
`The specification describes the nature of an activity:
`
`Object and advantage of the invention
`
`’099 Patent at 3:23-25
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`20
`
`’099 Patent at 4:45-47
`
`
`
`flows describe communication between particular devices
`
`’099 Patent at 12:4- 5
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`’099 Patent at 6:35-39
`
`21
`
`
`
`Flow Signatures Include Endpoint Information
`
`’099 Patent at 4:34-36
`
`’099 Patent at 32:43-47
`
`’099 Patent at 13:22-29
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`22
`
`
`
`Claim Interpretation – Specification is an Important Backdrop
`
`Conversational flow must be interpreted in the
`context of the specification.
`
`See Eon Corp. IP Holdings LLC v. Silver Spring Networks, Inc., 815 F.3d 1314,
`1320-23 (Fed. Cir. 2016) (rejecting constructions “untethered to the context of
`the invention” even though they could, “in the abstract, be given such a broad
`meaning”)
`
`Exemplary language in the specification’s definition of
`conversational flow reiterates how a POSITA would
`understand flows.
`
`See Realtime Data, LLC v. Stanley, 554 F. App’x 923, 933 (Fed. Cir. 2014)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`23
`
`
`
`POSITA understands flows similarly
`
`A POSITA would have understood a conversational flow and its
`corresponding activity to relate to a particular client.
`
`See EX2061 ¶¶41, 43-44, 47.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`24
`
`
`
`Specification Embodiments Confirm
`
`Specification embodiments further illustrate that a
`conversational flow relates to specific client activity as
`opposed to an entire class of application activity
`
`• SAP Example
`
`• RPC Example
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`25
`
`
`
`SAP Example – One Conversational Flow
`
`1. Client 1 sends an Initial SAP
`Request (red line) to Server 2
`requesting address information
`about the Print Service.
`
`2. Server 2 sends an SAP Reply (orange
`line) providing the address
`information for its Print Service.
`
`3. Client 1 then sends a Print Request
`(green line) to the Print Service
`available at Server 2.
`
`SAP Reply
`
`SAP
`
`Service
`
`Print Request
`
`One
`Conversational
`Flow
`
`Initial SAP
`Request
`
`(IPR2020-00336, Paper 26 at 30; Paper 32 at 6-8)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`26
`
`
`
`SAP Example – Two Conversational Flows
`
`1. Client 1 sends an Initial SAP
`Request (red line) to Server 2
`requesting address information
`about the Print Service.
`
`2. Server 2 sends an SAP Reply (orange
`line) providing the address
`information for its Print Service.
`
`3. Subsequently, Client 2 ends a Print
`Request (green line) to the Print
`Service available at Server 2.
`
`SAP Reply
`One
`Conversational
`Flow
`
`SAP
`
`Service
`
`Print Request
`
`Different
`Conversational
`Flow
`
`Initial SAP
`Request
`
`(IPR2020-00336, Paper 26 at 31; Paper 32 at 6-8)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`27
`
`
`
`RPC Example
`
`RPC Bind
`Lookup Request
`
`1. Client 3 wants to identify the
`connection point for a specific
`application, so it sends an RPC Bind
`Lookup Request to Server 2
`requesting a version of that
`program.
`
`2. Server 2 responds with an RPC Bind
`Lookup Reply “contain[ing] the
`specific Port number…on which
`future transactions will be accepted
`for the specific RPC program.”
`
`RPC
`Bind
`
`RPC Bind
`Lookup Reply
`
`(IPR2020-00336, Paper 32 at 9-11)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`28
`
`
`
`Skype Example – Related but disjointed flows
`
`Skype illustrates how a single network activity can involve related connection flows
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`29
`
`
`
`Skype Example – Related but disjointed flows
`
`Skype illustrates how a single network
`activity (i.e., involving a single client)
`can involve multiple connection flows.
`
`• Video information connection flows
`
`• Audio information connection flows
`
`• Control information connection flows
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`30
`
`
`
`Riddle Does Not Recognize “conversational flows”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`31
`
`
`
`Riddle Does Not Recognize “conversational flows”
`
`Riddle categorizes traffic into generic “traffic classes” irrespective
`of the clients involved
`
`“Riddle teaches applying ‘policies’ to control traffic classified as to
`type of service required.”
`
`IPR2020-00336, Paper 29 at 8 (internal quotes omitted)
`
`Riddle at 8:48-53
`
`A conversational flow relates to a particular activity, not all
`activities of a generic type.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`32
`
`
`
`Riddle Interpretation of Skype Conversations
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`(IPR2020-00336, Paper 7 at 42)
`
`33
`
`
`
`Riddle Does Not Recognize “conversational flows”
`
`Riddle’s traffic classes are unidirectional
`
`A conversational flow includes traffic flowing in both directions for a particular activity:
`
`Riddle at 8:48-53
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`’099 Patent at 2:38-39
`
`34
`
`
`
`Riddle Does Not Recognize “conversational flows”
`
`• Riddle does not classify traffic per user, but by the
`type of traffic based on properties such as the ports
`being used.
`
`• Petitioners’ allegations that Riddle discloses
`“classifying traffic into client-specific conversational
`flows” is incorrect. IPR2020-00336, Paper 29 at 12 (citing
`Riddle at 8:58-9:11, 10:1-17).
`
`• A traffic class created for a specific IP address would
`not distinguish one client activity from another
`
`• A traffic class created for a specific IP address would
`simply aggregate all traffic for that client IP address
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`35
`
`
`
`Riddle’s Service Aggregates Are Not “conversational flows”
`
`• Traffic classes generically group network
`activity
`
`• Service aggregates simply combine multiple
`traffic classes, providing a larger grouping of
`generic network activity
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`Riddle at 11:21-23
`
`36
`
`
`
`Riddle’s PointCast Traffic Class
`
`• Riddle’s recognition of PointCast traffic is
`based on its traffic classes
`
`• Grouping all PointCast traffic into a single
`class fails to recognize conversational flows
`implicating particular client entities
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`37
`
`
`
`Yu Does Not Recognize “conversational flows”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`38
`
`
`
`Yu Does Not Recognize “conversational flows”
`
`Yu’s “flows” are simply a different name for traffic matched by
`Riddle’s “traffic classes”
`
`A “flow classification specification” is essentially a “traffic class”
`for capture any traffic matching the specification
`
`Yu at 3:47-49
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`Yu at 3:32-38
`
`39
`
`
`
`Yu Does Not Recognize “conversational flows”
`
`• Yu is not distinguishing activities requested
`by individual clients—it is using simple
`pattern matches defined by a rule in the
`same way conventional monitors matched
`tuples on incoming or outgoing packets.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`IPR2020-00336, Petition at 83
`40
`
`
`
`Yu Does Not Recognize “conversational flows”
`
`• Recognizing traffic for a pre-defined user is
`not the same as recognizing conversational
`flows
`
`• A flow classification specification created for
`a specific IP address would not distinguish
`one client activity from another
`
`• A flow classification specification created for
`a specific IP address would simply aggregate
`all traffic for that client IP address
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`41
`
`
`
`RFC 1945 Does Not Teach “conversational flows”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`42
`
`
`
`RFC 1945 Does Not Teach “conversational flows”
`
`RFC 1945 defines the Hypertext Transfer Protocol
`(HTTP) version 1.0
`
`• Describing the components of the HTTP protocol
`does not teach using those components to
`identify conversational flows. IPR2020-00336, Paper 26 at
`44-45; EX2061 ¶¶71-72, 86.
`
`• Petitioner’s argument relies on testimony about
`an accused infringing product in a prior
`proceeding
`
`• That testimony has no bearing on what RFC 1945
`teaches a POSITA
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`43
`
`
`
`Petitioners Have Not Shown that Yu Is Prior Art
`
`A reference patent is only entitled to claim the benefit of the filing
`date of its provisional application if the disclosure of the
`provisional application provides support for the claims in the
`reference patent in compliance with § 112.
`
`Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800 F.3d 1375, 1380-82 (Fed. Cir. 2015)
`
`Petitioner must demonstrate that the subject matter in Chaffee
`relied upon by Petitioner in its unpatentability contentions is
`sufficiently supported in the Chaffee ’836 provisional, this test
`being in addition to the comparison of claimed subject matter
`required by Dynamic Drinkware.
`
`Intex Recreation Corp. v. Team Worldwide Corp., IPR2018-00859, Paper 128 at 26 (PTAB
`Oct. 21, 2019)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`44
`
`
`
`Yu Claim 1 – Includes MPF Terms
`
`Yu Claim 1
`
`1. A policy engine comprising:
`
`a stream classification module;
`
`a packet input/output module that places received packets in an external packet memory and that notifies
`the stream classification module of the packets in the external packet memory;
`
`wherein the stream classification module creates a packet service header for each packet in the external
`packet memory indicating, based on a policy cache, policies to be enforced on that packet;
`
`a policy enforcement module to enforce policies on the packets, including
`
`a packet scheduler that fragments each packet into cells and schedules enforcement of the policies on each
`cell based on the packet service header;
`
`on-chip packet buffer circuitry to temporarily hold the packets during policy enforcement; and
`
`a plurality of action processors, each action processor performing a particular policy enforcement on a cell
`and routing the cell to a next one of the action processors.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`45
`
`
`
`“module” Is an MPF Term
`
`“‘Module’ is a well-known nonce word that can operate as a substitute for
`‘means’ in the context of § 112, para. 6. As the district court found, ‘‘module’ is
`simply a generic description for software or hardware that performs a specified
`function.’”
`
`Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1350-51 (Fed. Cir. 2015)
`
`Where the claim to be construed contains a means-plus-function or step-plus-
`function limitation as permitted under 35 U.S.C. 112(f), the construction of the
`claim must identify the specific portions of the specification that describe the
`structure, material, or acts corresponding to each claimed function.
`
`37 C.F.R. §42.104(b)(3)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`46
`
`
`
`Petitioners Have Not Shown that Yu Is Prior Art
`
`• Petitioner has failed to identify the structure
`corresponding to Yu’s “module” terms, which are
`presumptively means-plus-function terms
`
`• Petitioner has not disputed that the ‘725 Patent and
`‘646 Patents are entitled to their provisional filing date
`
`“The ’725 Patent claims priority to Provisional
`Application No. 60/141,903 (“’903 Provisional”), filed on
`June 30, 1999. Petitioners do not accede to this, but for
`IPR assume that the earliest priority date is June 30,
`1999.”
`
`IPR2020-00336, Paper 3 at 9-10
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`47
`
`
`
`No Reason to Combine Riddle and Yu
`
`“[R]ejections on obviousness grounds cannot be sustained by mere conclusory statements;
`instead, there must be some articulated reasoning with some rational underpinning to
`support the legal conclusion of obviousness.”
`
`KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398, 418 (2007)
`
`[A] statement of similarity, however, does not constitute an articulated reasoning with
`rational underpinning as to why a POSITA would combine elements of one reference with
`another, and why a POSITA would modify the teachings of the references to arrive at the
`claimed invention.
`
`William Wesley Carnes, Sr. Inc. v. Seabaord International Inc., IPR2019-00133, Paper 10 at
`18 (PTAB May 8, 2019)
`
`We have observed that the prejudice of hindsight bias often overlooks that the genius of
`invention is often a combination of known elements which in hindsight seems preordained.
`
`Polaris Indus. v. Arctic Cat, Inc., 882 F.3d 1056, 1068 (Fed. Cir. 2018) (internal quotes
`and citations omitted).
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`48
`
`
`
`No Reason to Combine Riddle and Yu
`
`• Petitioners allege that Riddle and Yu are in the “same field of endeavor” (IPR2020-00336, Paper 3 at
`84)
`
`• Petitioners rely on Yu’s statement that “[f]low classification technique is evolving” (IPR2020-00336
`Paper 3 at 85; Paper 29 at 23)
`
`• Such broad, non-substantive statements cannot meet Petitioner’s burden to prove a motivation to
`combine Riddle and Yu, and confirms that Petitioner’s combination turns on improper hindsight bias.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`49
`
`
`
`Riddle and Yu Implement Different Design Philosophies
`
`• Riddle teaches a simple, automatic classification solution
`
`• Yu teaches a complex hardware/software combination requiring specialized hardware and regularly
`updated policy databases and software modules
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`50
`
`
`
`Riddle Does Not Teach State-based Limitations
`
`• Riddle never mentions state
`
`• Riddle’s analysis is limited to a single packet – state preservation is not required
`
`[A]lthough Riddle teaches classifying multiple packets in a flow, this classification occurs serially on an
`individual packet by packet basis, rather than relying on state transitions across multiple packets.
`IPR2020-00335, Paper 19 at 19-20
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`51
`
`
`
`Yu Does Not Teach State-based Limitations (‘725)
`
`• Yu summarily mentions state: “stateful packet inspection” (Yu at 4:55-64)
`
`• This passing reference fails to teach the particular requirements of the state-based limitations
`wherein the packet belongs to a conversational flow of packets having a set of one or more states,
`and wherein the protocol specific operations include one or more state processing operations that
`are a function of the state of the conversational flow of the packet, the state of the conversational
`flow of the packet being indicative of the sequence of any previously encountered packets of the
`same conversational flow as the packet.
`
`‘725 Patent at 98:30-37
`
`• To hold otherwise engages in improper hindsight bias
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`52
`
`
`
`Yu Does Not Teach State-based Limitations (‘646)
`
`• Yu summarily mentions state: “stateful packet inspection” (Yu at 4:55-64)
`
`• This passing reference fails to teach the particular requirements of the state-based limitations
`a state processor coupled to the lookup engine and to the flow-entry-database memory, the state
`processor being to perform any state operations specified for the state of the flow starting from the
`last encountered state of the flow in the case that the packet is from an existing flow, and to perform
`any state operations required for the initial state of the new flow in the case that the packet is from
`an existing flow.
`
`‘646 Patent at 36:60-67
`
`• To hold otherwise engages in improper hindsight bias
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`53
`
`
`
`The Prior Art Fails to Teach a “flow-entry database”
`
`Every challenged independent claim of the ‘646 Patent recites a flow-entry database:
`
`• Claim 1: “(b) a memory for storing a database comprising flow-entries for previously encountered
`conversational flows to which a received packet may belong, a conversational flow being an exchange
`of one or more packets in any direction as a result of an activity corresponding to the flow;”
`
`• Claim 7: “a memory to storing a database of one or more flow-entries for any previously encountered
`conversational flows, each flow-entry identified by identifying information stored in the flow-entry;”
`
`• Claim 16: “(c) looking up a flow-entry database comprising none or more flow-entries for previously
`encountered conversational flows, the looking up using at least some of the selected packet portions
`and determining if the packet is of an existing flow, the lookup being via a cache;”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`54
`
`
`
`The Prior Art Fails to Teach a “flow-entry database”
`
`• Riddle does not mention or suggest a “flow-entry database”; it mentions “database” twice in passing
`See Riddle at 5:65-67 (“However, server 20 may itself act in the capacity of a client when it
`•
`accesses remote databases located at another node acting as a database server.”)
`See Riddle at 12:34-35 (“The knowledge base may be embodied in a file or a relational
`database.”)
`
`•
`
`• Yu only refers to a “policy database”
`See Yu at Fig. 3, 1:26, 2:58, 3:24, 3:53, 4:53
`•
`
`• Ferdinand discloses “data structures” that “store performance statistics relating to the [] data link
`layer.” Ferdinand at 10 (8:3-5).
`
`• Petitioners’ argument that “databases” were known in the art is insufficient to disclose the “flow-entry
`database” limitations, which specifically implicate flow-entries
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`55
`
`
`
`The Prior Art Fails to Teach an “associative cache”
`
`• Riddle never mentions a cache
`
`• Yu refers to a policy cache.
`
`• Regarding flow information, Yu teaches that using a cache for flow information is very difficult.
`See Yu at 1:60-62 (“The distinctions of various implementation makes it difficult to cache a flow
`•
`with its decision in many ways.”)
`
`• Wakeman teaches caches, but Petitioners fail to show why one of skill in the art would have been
`motivated to combine an associative cache with Riddle or Yu
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`56
`
`