Trials@uspto.gov
`571-272-7822
`
`
`Paper 6
`Entered: August 31, 2017
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SANDVINE CORPORATION and SANDVINE INCORPORATED ULC,
`Petitioner,
`
`v.
`
`PACKET INTELLIGENCE, LLC,
`Patent Owner.
`____________
`
`Case IPR2017-00863
`Patent 6,665,725 B1
`____________
`
`
`Before ELENI MANTIS MERCADER, JUSTIN T. ARBES, and
`WILLIAM M. FINK, Administrative Patent Judges.
`
`MANTIS MERCADER, Administrative Patent Judge.
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`NOAC Ex. 1058 Page 1
`
`
`571-272-7822
`
`
`Paper 6
`Entered: August 31, 2017
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SANDVINE CORPORATION and SANDVINE INCORPORATED ULC,
`Petitioner,
`
`v.
`
`PACKET INTELLIGENCE, LLC,
`Patent Owner.
`____________
`
`Case IPR2017-00863
`Patent 6,665,725 B1
`____________
`
`
`Before ELENI MANTIS MERCADER, JUSTIN T. ARBES, and
`WILLIAM M. FINK, Administrative Patent Judges.
`
`MANTIS MERCADER, Administrative Patent Judge.
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`NOAC Ex. 1058 Page 1
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`
`I. INTRODUCTION
`Sandvine Corporation and Sandvine Incorporated ULC (collectively,
`“Petitioner”) filed a Petition for inter partes review of claims 1 and 2 of
`U.S. Patent No. 6,665,725 B1 (Ex. 1033, “the ’725 patent”). Paper 1
`(“Pet.”). Patent Owner, Packet Intelligence, LLC, did not file a Preliminary
`Response. By statute, institution of an inter partes review may not be
`authorized “unless . . . the information presented in the petition . . . and any
`response . . . shows that there is a reasonable likelihood that the petitioner
`would prevail with respect to at least 1 of the claims challenged in the
`petition.” 35 U.S.C. § 314(a); see also 37 C.F.R. § 42.108.
`Upon consideration of the Petition, we are persuaded Petitioner has
`demonstrated a reasonable likelihood of prevailing in establishing
`unpatentability of at least one claim of the ’725 patent. Accordingly, we
`institute an inter partes review.
`A. Related Matters
`“Patent Owner submits that the ’725 patent is the subject of a patent
`
`infringement lawsuit in the United States District Court for the Eastern
`District of Texas: Packet Intelligence, LLC v. Sandvine Corp., Case No.
`2:16-cv-00147, which was consolidated for pretrial matters (except venue)
`with co-pending Packet Intelligence, LLC v. NetScout Systems, Inc., Case
`No. 2:16-cv-00230.” Paper 4. Petitioner filed a petition for inter partes
`review challenging claims 10, 12, 13, and 15–17 of the ’725 patent in
`IPR2017-00862. Petitioner also filed petitions for inter partes review of
`related United States Patent Nos. 6,839,751 B1 (IPR2017-00451); 6,771,646
`B1 (IPR2017-00450); 6,954,789 B2 (IPR2017-00629 and IPR2017-00630);
`and 6,651,099 B1 (IPR2017-00769). Id.
`
`2
`
`NOAC Ex. 1058 Page 2
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`
`
`
`B. The ’725 Patent
`The ’725 patent relates to examining packets passing through a
`connection point on a computer network to determine whether a packet is of
`a conversational flow associated with an application program. Ex. 1033,
`7:12–26. Figure 3 of the ’725 patent is reproduced below.
`
`
`Figure 3 above shows network packet monitor 300. Id. at 8:48–13:50.
`
`
`Packet 302 is examined and evaluated by network packet monitor 300
`to determine its characteristics, such as all the protocol information in a
`multilevel model, including what server application produced the packet. Id.
`at 8:51–57. Initialization of the monitor to generate what operations need to
`occur on packets of different types is accomplished by compiler and
`
`3
`
`NOAC Ex. 1058 Page 3
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`optimizer 310, parsing and extraction of selected portions of packets to
`generate an identifying signature is accomplished by parser subsystem 301,
`and analysis of the packets is accomplished by analyzer 303. Id. at 8:64–
`9:3.
`Parser subsystem 301 examines the packets using pattern recognition
`
`process 304, which parses the packet and determines the protocol types and
`associated headers for each protocol layer that exists in packet 302. Id. at
`9:17–20. Protocol description language (PDL) files 336
`describe[] both patterns and states of all protocols that . . . occur
`at any layer, including how to interpret header information, how
`to determine from the packet header information the protocols
`at the next layer, and what information to extract for the
`purpose of identifying a flow, and ultimately, applications and
`services.
`Id. at 9:29–35.
`
`The ’725 patent states that it incorporates by reference U.S. Patent
`Application No. 09/608,237, issued as U.S. Patent 6,651,099 B1 (Ex. 1003,
`“the ’099 patent”), which discloses “protocol specific operations on
`individual packets including extracting information from header fields in the
`packet used for building a signature for identifying the conversational flow
`of the packet and for recognizing future packets as belonging to a previously
`encountered flow.” Ex. 1033, 2:21–30. A parser recognizes different
`patterns in the packet identifying the protocols used. Id. at 2:30–32. For
`each protocol recognized, packet elements are extracted to form the flow
`signature (also called a “key”). Id. at 2:32–34.
`
`Compiler/optimizer 310 generates two sets of internal data structures.
`Id. at 9:42–43, Fig. 3. The first is the set of parsing/extraction operations
`308 wherein “database 308 of parsing/extraction operations includes
`
`4
`
`NOAC Ex. 1058 Page 4
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`information describing how to determine a set of one or more protocol
`dependent extraction operations from data in the packet that indicate a
`protocol used in the packet.” Id. at 9:43–52. “The other internal data
`structure that is built by compiler 310 is the set of state patterns and
`processes 326.” Id. at 9:53–54.
`These are the different states and state transitions that occur in
`different conversational flows, and the state operations that need
`to be performed (e.g., patterns that need to be examined and new
`signatures that need to be built) during any state of a
`conversational flow
`to further
`the
`task of analyzing a
`conversational flow.
`Id. at 9:54–60.
`Input to compiler/optimizer 310 “includes a set of files that describe
`each of the protocols that can occur.” Id. at 41:24–25. “These files are in a
`convenient protocol description language (PDL) which is a high level
`language.” Id. at 41:25–27. “The PDL file for a protocol provides the
`information needed by compilation process 310 to generate the database
`308.” Id. at 41:57–59.
`That database in turn tells [parser subsystem 301] how to parse
`and/or extract information, including one or more of what
`protocol-specific components of the packet to extract for the flow
`signature, how to use the components to build the flow signature,
`where in the packet to look for these components, where to look
`for any child protocols, and what child recognition patterns to
`look for.
`
`
`Id. at 41:59–65
`
`C. Illustrative Claim
`Claim 1 of the challenged claims of the ’725 patent is independent.
`Claim 1 is illustrative of the claimed subject matter:
`
`5
`
`NOAC Ex. 1058 Page 5
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`
`(a) receiving the packet;
`
`1. A method of performing protocol specific operations on a
`packet passing through a connection point on a computer
`network, the method comprising:
`
`
`
`(b) receiving a set of protocol descriptions for a plurality
`
`of protocols that conform to a layered model, a protocol
`description for a particular protocol at a particular layer level
`including:
`
`
`(i) if there is at least one child protocol of the
`
`protocol at the particular layer level, the-one or more child
`protocols of the particular protocol at the particular layer
`level, the packet including for any particular child protocol
`of the particular protocol at the particular layer level
`information at one or more locations in the packet related
`to the particular child protocol,
`
`
`
`(ii) the one or more locations in the packet where
`information is stored related to any child protocol of the
`particular protocol, and
`
`
`
`(iii) if there is at least one protocol specific
`operation to be performed on the packet for the particular
`protocol at the particular layer level, the one or more
`protocol specific operations to be performed on the packet
`for the particular protocol at the particular layer level: and
`
`
`
`
`
`
`(c) performing the protocol specific operations on the
`
`packet specified by the set of protocol descriptions based on the
`base protocol of the packet and the children of the protocols used
`in the packet,
`
`the method further comprising:
`
`storing a database in a memory, the database generated
`
`from the set of protocol descriptions and including a data
`structure containing information on the possible protocols and
`
`6
`
`NOAC Ex. 1058 Page 6
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`
`organized for locating the child protocol related information for
`any protocol, the data structure contents indexed by a set of one
`or more indices, the database entry indexed by a particular set of
`index values including an indication of validity,
`
`
`wherein the child protocol related information includes a child
`recognition pattern,
`
`
`wherein step (c) of performing the protocol specific operations
`includes, at any particular protocol layer level starting from the
`base level, searching the packet at the particular protocol for the
`child field, the searching including indexing the data structure
`until a valid entry is found, and
`
`
`whereby the data structure is configured for rapid searches using
`the index set.
`
`
`Ex. 1033, 95:2–49.
`
`D. Reference
`Petitioner relies on the following reference. Pet. 1.
`Reference Title
`Date
`Baker
`WO 97/23076 A1
`June 26, 1997
`
`
`Ex. No.
`Ex. 1038
`
`
`
`E. Asserted Ground of Unpatentability
`Petitioner contends that claims 1 and 2 of the ’725 patent are
`
`unpatentable based on the following ground:
`
`Reference
`Baker
`
`Basis
`§ 102(b)
`
`Challenged Claims
`1 and 2
`
`
`Pet. 1. Petitioner also relies on the declaration of Bill Lin, Ph.D. (Ex. 1006)
`for support. Id. at 2.
`
`7
`
`NOAC Ex. 1058 Page 7
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`
`II. ANALYSIS
`A. Claim Construction
`In an inter partes review, claim terms in an unexpired patent are given
`their “broadest reasonable construction in light of the specification of the
`patent in which they appear.” 37 C.F.R. § 42.100(b). Under the broadest
`reasonable construction standard, claim terms are given their ordinary and
`customary meaning, as would be understood by one of ordinary skill in the
`art in the context of the entire disclosure. In re Translogic Tech., Inc., 504
`F.3d 1249, 1257 (Fed. Cir. 2007). Only terms in controversy need to be
`construed, and only to the extent necessary to resolve the controversy. Vivid
`Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`Petitioner contends that the term “rapid” in claim 1 is not entitled to
`patentable weight because it is “purely functional” and a statement of a
`desired result, rather than an apparatus or specific structure to accomplish
`the desired result.” Pet. 3 (citing Hewlett-Packard Co. v. Bausch & Lomb
`Inc., 909 F.2d 1464, 1468 (Fed. Cir. 1990) (“[A]pparatus claims cover what
`a device is, not what a device does.”); In re Schreiber, 128 F.3d 1473, 1478–
`79 (Fed. Cir. 1997) (“choosing to define an element functionally, i.e., by
`what it does, carries with it a risk”); Euramax Int’l, Inc. v. Invisaflow, LLC,
`Case IPR2016–00423, slip op. at 8–9 (PTAB June 1, 2016) (Paper 9).
`Petitioner asserts that affording no patentable weight to language describing
`an intended use or desired result of an apparatus is the long-standing rule.
`Id. at 3 (citing In re Gardiner, 171 F.2d 313, 315–16 (C.C.P.A. 1948) (“It is
`trite to state that the patentability of apparatus claims must be shown in the
`structure claimed and not merely upon a use, function, or result thereof.”)).
`
`8
`
`NOAC Ex. 1058 Page 8
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`We note Petitioner relies on legal precedents that address apparatus
`
`claims rather than method claims. Nonetheless, in Hoffer v. Microsoft
`Corp., 405 F.3d 1326, 1329 (Fed. Cir. 2005), the court noted that a
`“whereby clause in a method claim is not given weight when it simply
`expresses the intended result of a process step positively recited” (quoting
`Minton v. Nat’l Ass’n of Sec. Dealers, Inc., 336 F.3d 1373, 1381 (Fed. Cir.
`2003)).
`Here, the term “rapid” appears in the limitation “whereby the data
`structure is configured for rapid searches using the index set,” which
`configuration appears to be the result of the organization of the data
`structure as recited by step (c). In particular, claim 1 recites, inter alia, “the
`data structure contents indexed by a set of one or more indices, the database
`entry indexed by a particular set of index values including an indication of
`validity, . . . wherein step (c) . . . includes . . . searching including indexing
`the data structure until a valid result is found.” See Ex. 1033, 95:43–49.
`Similarly, the specification states that “the data structure is organized for
`rapidly locating the child protocol related information by using a set of one
`or more indices to index the contents of the data structure.” Id. at 34:34–37.
`In other words, the intended result of organizing the data structure according
`to step (c) of the claim is a rapid search.
`
`Accordingly, for purposes of this Decision, we agree with Petitioner
`that the term “rapid” is not entitled patentable weight.1
`
`
`
`
`1 The parties are encouraged to address the interpretation of the claim term
`“rapid” in their papers during trial.
`
`9
`
`NOAC Ex. 1058 Page 9
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`
`B. Asserted Anticipation by Baker
`1. Baker (Ex. 1038)
`Figure 1 of Baker is reproduced below.
`
`
`Figure 1 shows database of protocol description files 22 used by
`
`network device control logic 16 to retrieve network frames based on
`extracted field values and filtering criteria contained in protocol description
`files 22. Ex. 1038, 10:10–35.
`
`Baker’s protocol description file includes a protocol control record
`that defines the overall structure of a network protocol and references other
`information relating to the network protocol. Id. at 12:25–32. Each protocol
`description file includes a total bit length of the protocol header; a number of
`fields required to describe the header; and field records, each describing a
`protocol header field, including a byte offset from the start of the protocol
`header and, if appropriate, an associated lookup structure for determining the
`next protocol control record to use. Id. at 12:25–15:17, Tables 1, 2, and 4.
`
`10
`
`NOAC Ex. 1058 Page 10
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`Upon initialization of the system, the protocol and associated control
`
`record information is extracted from all protocol description files and a
`“ProtocolList” is constructed. Id. at 20:35–21:11. The ProtocolList is a
`sorted vector of all protocol records. Id.
`2. Analysis of Claim 1
`Petitioner relies on Baker as allegedly teaching the limitations of
`
`independent claim 1. Pet. 8–43. Petitioner also relies upon the Declaration
`of Dr. Lin to support its contentions. Petitioner provided mappings of
`Baker’s disclosure to claim 1 as further supported by Dr. Lin. Id. We
`emphasize Petitioner’s contentions regarding each of the limitations of claim
`1 below for which we are persuaded.
`1(a) receiving the packet
`Petitioner relies on Baker’s disclosure that “frames of network data
`may be received” by a network device such as an analyzer for meeting the
`recited 1(a) limitation of “receiving the packet.” Pet. 8 (citing Ex. 1038,
`4:26–35).
`
`1(b) receiving a set of protocol descriptions for a plurality of protocols that
`conform to a layered model
`
`Petitioner points us to Baker’s disclosure of protocol description files
`(PDFs), which is consistent with the ’725 patent specification describing
`protocol description language files (PDLs) corresponding to one of a
`plurality of protocols (e.g., Ethernet, IP, TCP) conforming to a layered
`model according to Petitioner. Pet. 8–9 (citing Ex. 1033, 14:63–65, 42:14–
`22, 42:46–43:9; Ex. 1038, 21:32–22:5, 34:16–21). The existence of a
`layered model is further supported by Dr. Lin’s testimony addressing
`Baker’s disclosure of “ParseLvl” variable matched to a “[z]ero based
`
`11
`
`NOAC Ex. 1058 Page 11
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`protocol level in ISO reference model of protocol being parsed (current
`protocol)” identifying the ISO reference model as the OSI layered model as
`it would have been recognized by a skilled artisan. Id. at 8–10 (citing Ex.
`1006 ¶ 179 (discussing Table 14)); see also Ex. 1006 ¶¶ 30–37.
`
`1(b)(i)(1) 2 a protocol description for a particular protocol at a particular
`layer level including: (i) if there is at least one child protocol of the protocol
`at the particular layer level, the-one or more child protocols of the
`particular protocol at the particular layer level
`
`Petitioner relies on Baker’s Ethernet PDF (i.e., “protocol description”)
`for the Ethernet protocol (i.e., a particular protocol at a particular layer level)
`including one child protocol, Generic Protocol (“GP”) (i.e., “including . . .
`the-one or more child protocols of the particular protocol at the particular
`layer level”) for disclosing the claim limitation of “a protocol description for
`a particular protocol at a particular layer level including: (i) if there is at
`least one child protocol of the protocol at the particular layer level, the-one
`or more child protocols of the particular protocol at the particular layer
`level.” Pet. 11–13 (citing Ex. 1038, Fig. 4D, 8:21–30, 21:32–22:5). Figure
`4D of Baker is reproduced below.
`
`Figure 4D shows the Ethernet type lookup structure including the one or
`more child protocols GP.
`
`
`2 For consistency purposes, we identify the claim limitations as Petitioner
`identified them, including adding parts (1) and (2) to element 1(b)(i).
`
`
`
`12
`
`NOAC Ex. 1058 Page 12
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`Petitioner further directs us to the GP PDF (i.e., “protocol
`
`description”) for the GP protocol (i.e., “a particular protocol at a particular
`layer level”) including four child protocols, “GP1,” “GP2,” “GP3,” and
`“GP4” (i.e., “the-one or more child protocols of the particular protocol at the
`particular layer level”). Id. at 13–14 (citing Ex. 1038, Figs. 5C–5E, 8:31–
`9:6, Table 13 (the Frame Type field indicates the “upper level protocol
`identifier,” and Src Socket and Dst Socket fields indicate the “Socket of
`Upper-layer protocol”), Figs. 5, 5A (the Frame field references the Fig. 5C
`lookup structure, the Source Socket field references the Fig. 5D lookup
`structure, and the Destination Socket field references the Fig. 5E lookup
`structure). Figures 5C, 5D, and 5E of Baker are reproduced below.
`
`
`
`
`
`Figure 5C
`
`Figure 5D
`
`13
`
`NOAC Ex. 1058 Page 13
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`
`
`
`Figure 5E
`
`
`Figures 5C, 5D, and 5E show the GP PDF for GP, including four child
`protocols GP1, GP2, GP3, and GP4.
`1(b)(i)(2) the packet including for any particular child protocol of the
`particular protocol at the particular layer level information at one or more
`locations in the packet related to the particular child protocol
`
`Petitioner then directs us to Table 12 in Baker as disclosing the claim
`limitation of “the packet including for any particular child protocol of the
`particular protocol at the particular layer level information at one or more
`locations in the packet related to the particular child protocol.” Pet. 14–18.
`Table 12 of Baker is reproduced below.
`
`
`
`14
`
`NOAC Ex. 1058 Page 14
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`Table 12 shows the Ethernet Protocol Specification.
`
`Specifically, according to Petitioner, Baker states that the “Ethernet
`Protocol Type” field of the Ethernet frame header includes an ‘“upper layer
`protocol designator 0x8888=GP’ (i.e., information at one or more locations
`in the packet related to the particular child protocol).” Id. at 14–15 (citing
`Ex. 1038, Table 12, 21:14–16).
`
`Petitioner contends that “each Ethernet frame includes an Ethernet
`header that is 14-bytes (112-bits) long followed by the header of the next
`layer protocol (GP Header) (i.e., information at a location in the packet
`related to the particular child protocol).” Id. at 15 (citing id. at 25:29–32
`(“Frame 1 shown below has a hardware length of eighty-two 8-bit bytes and
`consists of a fourteen byte Ethernet header, a twenty byte GP header with no
`option bytes, and forty-eight bytes of application data.”)). Frame 1 of Baker
`(Ex. 1038, 26) is reproduced below.
`
`
`
`
`Frame 1 depicts an Ethernet frame.
`1(b)(ii) the one or more locations in the packet where information is stored
`related to any child protocol of the particular protocol, and
`
`As an example of the “one or more locations in the packet where
`information is stored,” Petitioner discusses the “NumBits” attribute in Baker.
`Pet. 18–21. Each PDF protocol control record may include a “NumBits”
`
`15
`
`NOAC Ex. 1058 Page 15
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`attribute that is “the total bit length of the protocol header.” Id. at 18 (citing
`Ex. 1038, Table 1 (“numBits” attribute), 19:17; 56:30–57:11 (initialization
`routine for reading protocol control record elements from PDF, including
`“num_bits” attribute), Ex. 1006 ¶¶146–148). According to Petitioner, “[t]he
`’725 patent similarly discloses a ‘HEADER’ attribute of a PDL file ‘used to
`describe the length of the protocol header.’” Id. at 18 (citing Ex. 1033,
`48:41–50). According to Petitioner, “[d]uring the parsing process, the value
`of the numBits attribute may be used to determine where the next layer
`protocol header/data begins.” Id. (referring to the analysis of element 1(c)
`discussed below). In pertinent part, in the analysis of element 1(c),
`Petitioner relies on Baker for disclosing that “[w]hen parsing of the current
`protocol terminates, the ParsePtr variable is set to the start of the next layer
`protocol header/data (i.e., by adding the value of ProtoParseLen (which for
`Ethernet is equal to the value of NumBits) to the ParsePtr variable).” Id. at
`27 (citing Ex. 1038, 36:13–27, 64:11–13, 38:13–18, Figs. 4 (“NumBits”
`attribute), 13 (step 228); Ex. 1006 ¶¶174, 161, 165).
`
`“Each PDF also includes field sub-records for each field of the
`protocol header” according to Petitioner. Id. at 19 (citing Ex. 1038, 12:25–
`28, Tables 1, 2). “Each field sub-record includes an ‘fdwoff’ attribute (also
`called Byte/Bit Offset) that is the byte offset of the field from the start of the
`protocol header.” Id. (citing Ex. 1038, Table 2 (“fdwoff” attribute), 20:5,
`Figs. 4A, 5A, 147:28–148:13 (initialization routine for reading field sub-
`record elements from PDF, including “fdwoff” attribute); Ex. 1006 ¶¶ 149–
`150). The “fdwoff” attribute “is used during the parsing process to extract
`the value of the associated field.” Id. (citing Ex. 1038, 27:17–35, Fig. 13
`(step 210), Fig. 16 (step 502)).
`
`16
`
`NOAC Ex. 1058 Page 16
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`
`Petitioner further relies on Baker’s example of the “Ethernet PDF
`NumBits attribute of the protocol control record [being] set to 112,
`indicating the total bit length of the Ethernet header.” Id. (citing Ex. 1038,
`Fig. 4). Figure 4 of Baker is reproduced below.
`
`
`
`Figure 4 indicates the Ethernet PDF NumBits attribute of 112.
`
`Petitioner indicates that “[t]he Ethernet PDF ‘Type’ field sub-record
`includes a ‘Bit Offset’ (i.e., fdwoff attribute),” and shows “the Type field is
`96-bits offset from the start of the Ethernet header.” Id. (citing Ex. 1038,
`Fig. 4A; 29:32–30:4). Figure 4A of Baker is reproduced below.
`
`
`
`
`
`Figure 4A shows a “Bit Offset” of 96-bits offset.
`
`Petitioner concludes that “the NumBits attribute of the Ethernet
`control record and the fdwoff attribute of the Ethernet Type field sub-
`record” constitute “the one or more locations in the packet where
`information is stored related to any child protocol of the particular protocol.”
`Id. at 20.
`1(b)(iii) if there is at least one protocol specific operation to be performed
`on the packet for the particular protocol at the particular layer level, the one
`
`17
`
`NOAC Ex. 1058 Page 17
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`or more protocol specific operations to be performed on the packet for the
`particular protocol at the particular layer level; and
`
`Petitioner contends “one or more protocol specific operations to be
`performed on the packet for the particular protocol at the particular layer
`level” as recited in claim 1 includes “one or more parsing and extraction
`operations on the packet,” as recited in claim 10. Pet. 21 (quoting Ex. 1033,
`42:3–6 (“[T]he PDL file for an Ethernet packet includes information on how
`the parsing subsystem is to extract the source and destination addresses,
`including where the locations and sizes of those addresses are.”), citing id. at
`41:57–65).
`
`In particular, Petitioner states:
`The Baker PDFs include the locations and sizes of fields that are
`to be extracted by the parsing control logic (e.g., the disclosed
`ParseFrame, ParseProtocol, ParseFields, ValidateValue, and
`GetValue control logic), among other information. See generally
`EX1038 at 19:11-20:34, Tables, 1-13, Figs. 4, 4A-D, 5, 5A-D
`(describing data written to PDF file); 26:26-40:36, Figs. 11-16
`(describing control logic), 64:1-68:24; EX1006, ¶¶157-177
`(describing parsing control logic as implemented by disclosed
`source code). Namely, each PDF field sub-record includes an
`“fdwoff” attribute (also called Byte/Bit Offset) that is the byte
`offset of the respective field from start of protocol header (i.e.,
`the location of the field that is to be extracted). EX1038 at Table
`2 (“fdwoff” attribute), 20:4, 27:17-35, Figs. 4A, 5A, 13 (step
`210), 16 (step 502), 147:28-148:13, 148:25-26; EX1006, ¶¶169,
`185, 149-150; see Element 1(b)(ii). Each PDF field sub-record
`also includes an “fblen” attribute (also called Bit Length) that is
`the length of the respective field in bits (i.e., the size of the field
`that is to be extracted). EX1038 at Table 2 (“fblen” attribute),
`20:4, 35:27-30, Figs. 4A, 5A, 13 (step 222), 147:28-148:13,
`148:25-26; EX1006, ¶¶185, 149-150.
`Pet. 22.
`
`18
`
`NOAC Ex. 1058 Page 18
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`1(c) performing the protocol specific operations on the packet specified by
`the set of protocol descriptions based on the base protocol of the packet and
`the children of the protocols used in the packet
`
`According to Petitioner, in the ’725 patent, “the base protocol” of a
`packet is described as the protocol associated with the packet type, such as
`Ethernet. Pet. 23.
`
`Petitioner contends Baker discloses “control logic perform[ing]
`protocol specific operations on the packet as specified by the set of protocol
`description files based on the base layer protocol (i.e., Ethernet) of the
`packet and the children of the protocols used in the packet (i.e., GP and
`others).” Id. at 23.
`
`More particularly, Petitioner relies on Baker’s disclosure that “after
`the Ethernet protocol fields are parsed (at step 106 of Fig. 11), ‘the
`NextProtocol variable ‘will refer to the GP shown in FIGS. 5-5(e), and
`ParsePtr will point at the start of line 2’ of the frame.’” Id. at 27 (citing Ex.
`1038, 38:13–18, 146:19–25, 67:27–32, 29:17–31, Figs. 11–14; Ex. 1006 ¶¶
`174, 161, 165). “[T]he CurrentProtocol variable will [then] be updated with
`the NextProtocol value (of GP) and the GP fields in the frame are parsed
`using the ParseProtocol, ParseFields, GetValue, and ValidateValue fields.”
`Id. at 27–28 (citing Ex. 1038, 38:18–24, 67:27–32, Fig. 11 (steps 108, 128);
`Ex. 1006 ¶¶ 161–177).
`1(d)(i) the method further comprising: storing a database in a memory, the
`database generated from the set of protocol descriptions and including a
`data structure containing information on the possible protocols and
`organized for locating the child protocol related information for any
`protocol
`
`Petitioner contends that the recited “database” “may include a
`Protocol Table (PT) and a series of one or more Look Up Tables (LUTs)
`
`19
`
`NOAC Ex. 1058 Page 19
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`associated with a protocol in PT and used to identify known protocols and
`their children.” Pet. 29 (citing Ex. 1033, 14:39–43, 39:22–40:60, Fig. 18B).
`According to Petitioner, “Baker discloses a database in memory generated
`from the set of protocol descriptions consistent with the ’725 Patent Fig. 18B
`embodiment.” Id. (citing Ex. 1006 ¶¶ 182–187). In particular, “Baker
`discloses that, upon initialization and when PDF files are read into memory,
`the resulting protocol description data structures include a data structure of
`protocol records (each corresponding to a PDF) and further provides a
`ProtocolList sorted vector that is used as an index for searching the protocol
`descriptions supported by the system.” Id. (citing Ex. 1038, 20:35–21:11,
`127:20–128:13, 128:33–129:1; Ex. 1006 ¶¶ 143–147, 183).
`
`Furthermore, Petitioner states that “[d]uring parsing, the protocol data
`structure is used to extract a field that specifies the next protocol, which is
`then used as an address into the lookup structure for determining the child
`protocol.” Id. at 32 (citing Ex. 1038, 145:20–146:2, 64:18, 148:26, 27:17–
`35, Fig. 13 (step 210), Fig. 16, Table 2; Ex. 1006 ¶¶ 170–174, 186.
`Petitioner further states that “[w]hen the next protocol is identified using the
`lookup structure, it is used as an index into the protocol table.” Id. at 33
`(citing Ex. 1038, 146:19–25, 29:17–31, 67:27–32, Fig. 11 (steps 108, 128),
`Fig. 14 (steps 306, 308, 310, 312); Ex. 1006 ¶¶ 174, 161, 186). Petitioner
`contends that this is further supported by Dr. Lin’s testimony. Id. (citing Ex.
`1006 ¶¶ 182–188). Of note is Dr. Lin’s testimony that the “Baker protocol
`data structure like the Protocol Table of the ’725 patent, contains
`information on the possible protocols known by the system.” Ex. 1006 ¶
`183 (comparing the ’725 patent’s protocol table (PT) with Baker’s protocol
`data structure and ProtocolList).
`
`20
`
`NOAC Ex. 1058 Page 20
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`1(d)(ii) the data structure contents indexed by a set of one or more indices
`
`With respect to the claim 1 limitation of “the data structure contents
`indexed by a set of one or more indices,” Petitioner contends Baker discloses
`that multi-protocol lookup structures are each indexed by a value extracted
`from the next/child protocol field in the packet. Pet. 33 (citing Ex. 1038,
`177:4–26; 64:25–38, 175:35–176:24, 29:1–31, Fig. 13 (step 214), Fig. 14;
`Ex. 1006 ¶¶ 151–156, 170–172). Petitioner states “[t]he ’725 patent
`similarly discloses that each LUT is ‘indexed by one byte of the child
`recognition pattern that is extracted from the next protocol field in the
`packet.’” Id. (citing Ex. 1033, 39:33–35). Petitioner relies on Baker’s
`disclosure of “[w]hen the next/child protocol is identified using the Baker
`lookup structure, it is used as an index into the protocol table.” Id. (citing
`Ex. 1038, 146:19–25, 29:17–31, 67:27–32, Fig. 11 (steps 108, 128), Fig. 14
`(steps 306, 308, 310, 312), Table 4; Ex. 1006 ¶¶ 174, 161, 190). According
`to Petitioner, this disclosure is consistent with the ’725 patent wherein
`“when a lookup results in a valid next protocol, the next protocol ‘is used as
`an index into the protocol table.’” Id. at 34 (citing Ex. 1033, 40:27–31).
`
`1(d)(iii) the database entry indexed by a particular set of index values
`including an indication of validity
`
`Petitioner argues that, as described in the ’725 patent, “each LUT
`entry includes a ‘node code’ that indicates the validity of the contents.” Pet.
`34 (citing Ex. 1033, 39:39–50, 35:4–11, 14:57–61). The ’725 patent
`discloses that “a ‘protocol’ node code indicates a recognized protocol
`whereas a ‘null’ node code indicates ‘that there is no valid entry.’” Id.
`
`Petitioner points us to Baker’s “multi-protocol lookup structure
`entries,” which “are indexed by a valid protocol identification value.” Id. at
`
`
`
`21
`
`NOAC Ex. 1058 Page 21
`
`
`
`
`IPR2017-00863
`Patent 6,665,725 B1
`
`35 (citing Ex. 1006 ¶¶ 151–156, 170–172, 194). Petitioner adds that the
`“[e]ntries also include a ‘prot’ variable (‘Protocol’ of Table 4 and Figs. 4D,
`5C–5E) that, similar to the ’725 Patent ‘node code,’ has one of tw
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
