UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`Juniper Networks, Inc. & Palo Alto Networks, Inc.
`Petitioners,
`
`
`v.
`
`Packet Intelligence LLC,
`Patent Owner.
`
`
`Case IPR2020-00337
`U.S. Patent No. 6,771,646
`
`PATENT OWNER’S REQUEST FOR DIRECTOR REVIEW
`
`
`
`
`
`
`
`
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`Juniper Networks, Inc. & Palo Alto Networks, Inc.
`Petitioners,
`
`
`v.
`
`Packet Intelligence LLC,
`Patent Owner.
`
`
`Case IPR2020-00337
`U.S. Patent No. 6,771,646
`
`PATENT OWNER’S REQUEST FOR DIRECTOR REVIEW
`
`
`
`
`
`
`
`
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`Introduction .......................................................................................................... 1
`I.
`II. The Panel Deviated from Every Prior Tribunal ................................................... 2
`III. The Panel Ignored Critical Context From The Specification .............................. 3
`A. Flows Have Particular Endpoints .................................................................. 4
`B. The Panel Gives No Meaning to “Conversational” ...................................... 5
`C. The Invention Monitors Network Activity Based on Endpoints
`and Activity Type .......................................................................................... 6
`IV. The Panel Misinterpreted the SAP Example to Support Its Unreasonable
`Understanding of “conversational flow” ............................................................. 9
`V. The Acting Director Lacks Authority to Rule on this Request .........................15
`VI. Conclusion .........................................................................................................15
`
`
`
`i
`
`
`
`TABLE OF AUTHORITIES
`
`Cases
`
`Akzo Nobel Coatings, Inc. v. Dow Chem. Co.,
`No. 12-1264-LPS, 2015 U.S. Dist. LEXIS 12940 (D. Del. Jan. 26, 2015) ......... 8
`Core Wireless Licensing S.A.R.L. v. LG Elecs., Inc.,
`No. 2:14-cv-0912, 2015 U.S. Dist. LEXIS 151310 (E.D. Tex. Nov. 7,
`2015) .................................................................................................................... 8
`Eon Corp. IP Holdings LLC v. Silver Spring Networks, Inc.,
`815 F.3d 1314 (Fed. Cir. 2016) ........................................................................... 5
`Oasis Research, LLC v. AT&T Corp.,
` No. 4:10-CV-00435, 2012 U.S. Dist. LEXIS 22836 (E.D. Tex. Feb. 23,
`2012) .................................................................................................................... 8
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) ........................................................................... 3
`Realtime Data, LLC v. Stanley,
`554 F. App’x 923 (Fed. Cir. 2014) ...................................................................... 7
`Realtime Data, LLC v. Stanley,
`875 F. Supp. 2d 276 (S.D.N.Y. 2012) ................................................................. 7
`Sandvine Corporation, et al v. Packet Intelligence LLC,
` IPR2017-00862 ...............................................................................................2, 3
`Sandvine Corporation, et al v. Packet Intelligence,
`IPR2017-00630 .................................................................................................... 3
`Shire Dev. LLC v. Teva Pharm. USA, Inc.,
`No. 1:17-cv-01696, 2019 U.S. Dist. LEXIS 31753 (D. Del. Feb. 28,
`2019) .................................................................................................................... 8
`Sinorgchem Co. v. ITC,
`511 F.3d 1132 (Fed. Cir. 2007) ........................................................................... 8
`United States v. Arthrex, Inc.,
`141 S. Ct. 1970 (2021); 5 U.S.C. §§ 3345, 3346 ...............................................15
`
`
`
`
`ii
`
`
`
`I. INTRODUCTION
`The Panel’s decision defies fairness, logic, legal sufficiency, and is a prime
`
`example of why the Supreme Court mandated Director oversight of PTAB decisions.
`
`If this case is not selected for review and overturned, then patentees can assume that
`
`the PTO has decided to ignore the Supreme Court’s directive regarding the
`
`unsupervised, unlawful taking of property by APJs without proper oversight.
`
`First, the challenged patent family has been tested in multiple district court
`
`litigations, including an appeal to the Federal Circuit, as well as seven inter partes
`
`reviews. Indeed, the same prior art references raised here were also raised in the prior
`
`litigations. The Panel’s findings directly contradict the findings by a previous panel
`
`addressing the same patents. Despite that extensive history, the Panel reversed
`
`course to invalidate the patents. In each prior proceeding, the adopted construction
`
`of “conversational flow” matched that proposed by the Patent Owner (“PO”). Yet
`
`this Panel ignored the specification’s definition of “conversational flow,” and
`
`instead relied on a hand-picked excerpt from that definition to support its
`
`unreasonable unpatentability findings.
`
`Second, the Panel compounded this error by determining that a network
`
`“activity” includes all packet exchanges related to a specific type of network activity,
`
`regardless of whether those exchanges form part of the same “conversation”
`
`involving the same client and server. This second error stems from the failure to
`
`1
`
`
`
`account for the specification’s express teachings about flows and effectively rewrites
`
`the claims to remove the “conversational” aspect of “conversational flows.”
`
`Third, the Panel justified its faulty analyses of conversational flows and
`
`network activities based on a misinterpretation of an SAP example included in the
`
`specification. In shoehorning the SAP example to fit within its unreasonably broad
`
`interpretation of conversational flows and network activities, the Panel ignored
`
`conditional language in the SAP example that illustrated the difference between
`
`(1) recognizing the type of a network activity to which a packet exchange relates
`
`and (2) identifying disjointed packet exchanges, involving the same client and same
`
`instance of a network activity, as belonging to the same conversational flow.
`
`II. THE PANEL DEVIATED FROM EVERY PRIOR TRIBUNAL
`The analysis and reasoning of the panel in the prior IPRs is instructive; it
`
`adopted the specification’s full definition even under the less restrictive “broadest
`
`reasonable interpretation” claim construction standard, stating as follows:
`
`we observe that the specification of the ’099 patent explicitly supports
`this construction. See Ex. 1003, 2:34–45. Accordingly, for purposes of
`this Decision, we agree that Patent Owner’s proposed construction,
`which mirrors the definition in the specification, is the broadest
`reasonable construction consistent with the specification.
`IPR2017-00862, Paper 8 at 9-10 (all emphases added unless otherwise noted).
`
`Indeed, every tribunal to have considered the proper construction for
`
`“conversational flow” has adopted the same construction, including two district
`
`2
`
`
`
`court proceedings, previous IPRs, and a Federal Circuit appeal. See Paper 7 at 21-
`
`23; Paper 23 at 1-3; Paper 26 at 24-26. This construction flows directly from the
`
`specification’s explicit definition. See EX1001 at 2:37-45.1 For example, in
`
`IPR2017-00630, the panel embraced PO’s proposed construction. IPR2017-00630,
`
`Paper 9 at 9 (“We agree with Patent Owner that the term ‘conversational flow’ is
`
`expressly defined in the excerpt of the patent quoted above.”). The other IPR
`
`decisions mirror this reasoning. See Paper 24 at 2-3. No matter the standard used,
`
`every tribunal to consider the construction of “conversational flow” adopted the
`
`complete specification definition.
`
`The Panel’s failure to adhere to the lexicography of “conversational flow” is
`
`reversible error. See Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005)
`
`(en banc) (“[T]he specification may reveal a special definition given to a claim term
`
`by the patentee . . . . In such cases, the inventor’s lexicography governs.”). The
`
`Panel adopted a construction and understanding of “conversational flow” that is
`
`unreasonably broad. When the proper construction of “conversational flow” is
`
`applied, the challenged claims are unmistakably patentable over the asserted art.
`
`III. THE PANEL IGNORED CRITICAL CONTEXT FROM THE SPECIFICATION
`The Panel’s error hinges on its failure to understand the teachings of the
`
`
`1 The ’646 Patent at 1:16-18 incorporates the ’099 Patent (EX1001) by reference.
`
`3
`
`
`
`specification as understood by a POSITA. First, the specification consistently
`
`teaches that flows are understood within the context of the endpoints (users or
`
`client/server pair) for the flow. Second, the Panel’s interpretation of “conversational
`
`flow” eviscerates the “conversational” aspect of the term by ignoring the endpoints
`
`that (along with the underlying activity type) define a specific conversation. Finally,
`
`the Panel’s interpretation of activity as it relates to “conversational flow” ignores the
`
`specification’s focus on granular (i.e., user-level) network monitoring—identifying
`
`flows relating to a specific network activity involving the same combination of
`
`conversation participants (endpoints).
`
`A. Flows Have Particular Endpoints
`
`The specification consistently teaches that flows represent communication
`
`between particular devices—not all communication of a particular type. See
`
`EX1001 at 12:4-5 (“A flow is a stream of packets being exchanged between any two
`
`addresses in the network.”); id. at 6:37-38 (discussing “client/server conversational
`
`flow”). Flows are typically identified by a signature including information about the
`
`endpoint devices (client/server) involved in the packet communication. See, e.g., id.
`
`at 4:34-36 (“[A] signature is built for every flow such that future packets of the flow
`
`are easily recognized.”); id. at 32:43-47 (“A source and destination network
`
`address occupy the first two fields of each packet, and…the flow signature…will
`
`also contain these two fields…”).
`
`4
`
`
`
`“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”). Here, the specification teaches that flows, flow signatures, and network
`
`activities (which result in flows) involve specific endpoints. To remove this aspect
`
`of a conversational flow, as the Panel has done, eliminates the notion of a flow,
`
`which is communication between two devices. See EX1001 at 12:4-5. This
`
`understanding of conversational flow tracks how a POSITA would have understood
`
`this term within the context of the specification. See EX2061 ¶¶41, 43-44, 47.
`
`Flows are defined, in part, based on their endpoints. The Panel construed
`
`“conversational flow” in a manner that disregards the participants in the flow. This
`
`erroneous construction resulted in the Panel’s next error.
`
`B. The Panel Gives No Meaning to “Conversational”
`
`The Panel’s analysis also rewrites the conventional understanding of a
`
`“conversation.” The very notion of a “conversation” implicates particular
`
`participants, and the Panel erroneously determined that a “conversational flow” is
`
`identified without regard for (or even awareness of) the participants in the
`
`conversational flow. Indeed, the Panel concluded that a “conversational flow” is
`
`simply all network flows relating to the same type of activity. See Paper 48 at 23
`
`5
`
`
`
`(“[W]e determine that ‘conversational flow[s]’ means a ‘sequence of packets that
`
`are exchanged in any direction as a result of an activity,’ without the additional
`
`restriction that the conversational flow must be client- or user-specific.”).
`
`This is no different than saying that every Skype call is part of a single
`
`“conversational flow”—this defies logic: every network client using a particular
`
`application is not a party to the same conversation. Multiple Skype calls within a
`
`network may involve many different conversations—they do not collectively
`
`represent a single conversational flow, as the Panel erroneously determined.
`
`Not only has the Panel ignored the specification’s teachings about the nature
`
`of a conversational flow, but it has also defied common-sense in its interpretation of
`
`what constitutes a “conversation” within the context of monitoring network activity.
`
`The Panel’s error spans both legal and common-sense domains.
`
`C. The Invention Monitors Network Activity Based on Endpoints and
`Activity Type
`The specification’s definition of “conversational flow” states that an activity
`
`is, “for instance, the running of an application on a server as requested by a
`
`client….” EX1001 at 2:39-40; see id. at 9:14-19 (“Any network activity—for
`
`example an application program run by the client 104 (CLIENT 1) communicating
`
`with another running on the server 110 (SERVER 2)—will produce an exchange
`
`of a sequence of packets over network 102 that is characteristic of the respective
`
`programs and of the network protocols.”). The background describes the information
`
`6
`
`
`
`obtained by network activity monitors, including “who is using [network services.]”
`
`Id. at 1:57; see id. at 3:23-25 (“What is needed, therefore, is a network monitor that
`
`makes it possible to continuously analyze all user sessions on a heavily trafficked
`
`network.”); id. at 3:34-35 (describing need to determine “an end user’s pattern of
`
`use within each application”).
`
`Even if the language clarifying the scope of an activity were “exemplary,” that
`
`language must still be considered in determining the meaning of the term
`
`“conversational flow.” See Realtime Data, LLC v. Stanley, 554 F. App’x 923, 932-
`
`33 (Fed. Cir. 2014). The district court in Realtime Data construed the term “data
`
`field type” as “[c]ategorization of the data in the field (or block) as one of ASCII,
`
`image data, multimedia data, signed and unsigned integers, pointers, or other data
`
`type,” consistent with examples provided in the specification. See Realtime Data,
`
`LLC v. Stanley, 875 F. Supp. 2d 276, 290-91, 296 (S.D.N.Y. 2012) (construing “data
`
`field type” to include exemplary types: “data types (e.g., ASCII, image data,
`
`multimedia data, signed and unsigned integers, pointers, etc.)”). The Federal Circuit
`
`affirmed the construction, finding “[t]he district court was correct in concluding that,
`
`based on the specifications of the patents, the ‘data field/block type’ term…must be
`
`tied to some analysis of the content of the data field or block and cannot simply
`
`encompass any characteristic or attribute of data.” Realtime, 554 F. App’x at 933
`
`(emphasis in original).
`
`7
`
`
`
`District courts applying Phillips have held that exemplary or non-limiting
`
`language within a patentee’s lexicography must remain part of the term-at-issue’s
`
`construction. See Shire Dev. LLC v. Teva Pharm. USA, Inc., No. 1:17-cv-01696,
`
`2019 U.S. Dist. LEXIS 31753, at *28 (D. Del. Feb. 28, 2019) (adopting a full
`
`definitional paragraph as the construction despite inclusion of permissive, non-
`
`limiting language); Oasis Research, LLC v. AT&T Corp., No. 4:10-CV-00435, 2012
`
`U.S. Dist. LEXIS 22836, at *25-26 (E.D. Tex. Feb. 23, 2012) (including an example
`
`sentence in its construction because “[t]he second sentence of the construction
`
`provides guidance and understanding to the first sentence, and in combination will
`
`be understandable to the jury while remaining faithful to the explicit definition
`
`provided within the specification”); Core Wireless Licensing S.A.R.L. v. LG Elecs.,
`
`Inc., No. 2:14-cv-0912, 2015 U.S. Dist. LEXIS 151310, at *70-71 (E.D. Tex. Nov.
`
`7, 2015) (adopting a paragraph definitional construction and explaining that “[t]he
`
`first and second sentences together provide context and understanding to the term”
`
`and that “[t]he examples listed at the end of the second sentence reinforce this
`
`context”); Sinorgchem Co. v. ITC, 511 F.3d 1132, 1136-40 (Fed. Cir. 2007)
`
`(construing “controlled amount” to include the exemplary phrase “e.g., up to about
`
`4% H[2]O”); Akzo Nobel Coatings, Inc. v. Dow Chem. Co., No. 12-1264-LPS, 2015
`
`U.S. Dist. LEXIS 12940, at *16-17 (D. Del. Jan. 26, 2015) (construing “aqueous
`
`medium” to include that “[t]here can be up to 40% by weight of water miscible
`
`8
`
`
`
`organic solvents present in the aqueous medium”).
`
`The language clarifying the meaning of “an activity” is important here for the
`
`same reason—in the context of the specification, no reasonable person, let alone a
`
`POSITA, would interpret the use of “an activity” to include all packets merely
`
`related to the same “type of activity.” Instead, the activity contemplated by the
`
`specification’s definition implicates instances of an activity relating to specific
`
`endpoints. Different clients performing the same type of activity yield different
`
`conversational flows. The Panel’s understanding of network activity is divorced
`
`from the teachings of the specification and is, thus, unreasonably broad.
`
`IV. THE PANEL MISINTERPRETED THE SAP EXAMPLE TO SUPPORT ITS
`UNREASONABLE UNDERSTANDING OF “CONVERSATIONAL FLOW”
`
`The specification details an example about the use of SAP (Service
`
`Advertising Protocol). See EX1001 at 2:49-52. SAP “identif[ies] the services and
`
`addresses of servers attached to a network.” Id. at 2:51-52. For example, a network
`
`client might send an SAP request to determine the server to use for printing services.
`
`See id. at 2:52-53. In response, the server would send an SAP reply identifying the
`
`server for handling print services. See id. at 2:53-56. Now, the original client has the
`
`information necessary (i.e., address of the print service) to send a print request. Each
`
`of these exchanges represents a connection flow—the first is between the client and
`
`SAP server; the second is between the client and print server. See id. at 2:64-67. To
`
`“eliminate the possibility of disjointed conversational exchanges,” the specification
`
`9
`
`
`
`teaches that “it is desirable for a network packet monitor to be able to ‘virtually
`
`concatenate’—that is, to link—the first exchange with the second.” Id. at 3:1-4.
`
`The specification also describes a scenario in which a different client sends a
`
`print request to the print server. See id. at 2:58-64. In this scenario, the exchange
`
`between the different client and print server represents a different conversational
`
`flow than the two exchanges from a single client detailed above. The second client
`
`is initiating a different activity than the first client, even though both clients are
`
`requesting print services—the same type of activity. See id. at 3:4-6 (“If the clients
`
`were the same, the two packet exchanges would then be correctly identified as being
`
`part of the same conversational flow.”). On the other hand, if the clients were not
`
`the same, the packet monitor would correctly identify the exchange from the second
`
`client as a different conversational flow corresponding to a different print request
`
`activity than that of the first client.
`
`The Panel misunderstood the SAP example, which reflects two critical points
`
`consistent with PO’s position. First, the SAP example teaches identifying disjointed
`
`connection flows as a conversational flow because they relate to the same network
`
`activity for a particular client or endpoint. This first point is illustrated by the
`
`specification’s explanation of the first client activity in the SAP example. In short:
`
`an SAP Request is sent, and the server responds with an SAP Reply, which identifies
`
`the address (or port) for the print service. EX1001 at 2:52-56; EX1016 at 135:6-10.
`
`10
`
`
`
`Later, a print request is sent to the address (or port) previously identified. EX1001
`
`at 2:61-64. If the sender of the print request is the same client that sent the SAP
`
`request, that print request connection flow is identified as related to the earlier SAP
`
`Request connection flow, thus belonging to the same conversational flow. If not, the
`
`print request connection flow—from a different client—is identified as a different
`
`conversational flow.
`
`Second, the SAP example explains how to recognize the type of network
`
`activity (in this example, a print request activity) based on previously observed
`
`communications, even if a protocol relies on dynamic port allocation (such as server
`
`announcement protocols like SAP). Under a dynamic addressing scheme (like that
`
`used by SAP) in which service addresses are determined and announced by a server,
`
`clients (and network monitors) learn of the appropriate service address by receiving
`
`a server announcement. EX1016 at 28:8-16, 30:4-15. This information is important
`
`because it allows the network monitor to recognize future “print request” activities
`
`because it now knows the address of the service for handling print requests.
`
`The Panel misinterprets the SAP example to support its finding that “the ’099
`
`patent and the provisional application expressly contemplate classifying connection
`
`flows from different clients into the same conversational flow when those
`
`connections involve the same activity.” Paper 48 at 17. The Panel relies on the
`
`following passage from the Provisional application:
`
`11
`
`
`
`It is desirable for a network packet monitor to be able to “virtually
`concatenate” the first exchange that defines SAP #5 as the print service
`on the server with the second exchange that uses the print service. The
`two packet exchanges would then be correctly identified as being part
`of the same flow if the clients were the same. They would even be
`recognized if the clients were not the same.
`EX1016 at 3:25-30. But this passage does not support the Panel’s position. The last
`
`two sentences are critical—they first explain that two packet exchanges related to
`
`the same activity type (e.g., print request activities) belong to the “same flow if the
`
`clients [are] the same.” Id. at 3:28-29. The Panel’s analysis eliminates and ignores
`
`the conditional that states “if the clients were the same,” which requires that the
`
`clients be the same for the two disjoint exchanges relating to the same type of activity
`
`to be considered part of the same conversational flow.
`
`The Panel incorrectly interprets the last sentence to support its position
`
`conversational flows are determined irrespective of the clients involved. This
`
`sentence says that “[the packet exchanges] would even be recognized if the clients
`
`were not the same.” Id. at 3:29-30. This sentence illustrates how a later print request
`
`by a different client can be recognized as a print request type activity because it uses
`
`the now-known address of the print service. Put another way, the packet monitor
`
`now knows—based on its earlier receipt of the server announcement including the
`
`address of the print service—that any packet exchanges sent to the announced
`
`address are properly recognized as SAP print requests (rather than another activity
`
`type, such as an FTP request). For example, three clients each sending a print request
`
`12
`
`
`
`to the print service address would yield three different packet exchanges. Per the
`
`specification’s teachings, each of these exchanges would be recognized as a print
`
`request activity based on the target service address (which was previously provided
`
`by a server announcement). Yet because the clients are different, each exchange is
`
`identified as a separate conversation.
`
`In its analysis, the Panel cites a similar passage in the ’099 Patent. See Paper
`
`48 at 18-19. The ’099 Patent passage is slightly different, but the concepts conveyed
`
`are the same. As in the provisional, the ’099 passage includes a conditional: “If the
`
`clients were the same, the two packet exchanges would then be correctly identified
`
`as being part of the same conversational flow.” EX1001 at 3:4-6. The Panel simply
`
`ignores this conditional “if.” A later passage in the ’099 Patent explains the concept
`
`of recognizing the type of activity at issue: “Considering the previous SAP example
`
`again, because one features of the invention is to correctly identify the second
`
`exchange as being associated with a print service on that server, such exchange
`
`would even be recognized if the clients were not the same.” Id. at 3:44-48; see supra.
`
`The distinctions made in the SAP example between recognizing activity type
`
`(regardless of the clients involved) and identifying related connection flows that
`
`form a conversational flow (which depends on the clients involved) illustrate how
`
`the claimed packet monitor solves challenges particular to dynamic address
`
`assignment for application services. Thus, the passages relied on by the Panel do not
`
`13
`
`
`
`suggest every exchange of SAP packets is part of a single conversational flow
`
`regardless of the clients involved. Instead, they describe how the invention can still
`
`correctly recognize the second packet exchange as associated with a print service
`
`even though the second client never issued its own SAP Request to the server.
`
`Patent Owner’s expert, Ms. Quigley, addressed the SAP example and reached
`
`the same conclusion. EX2061 ¶¶58-60. Thus, a POSITA would understand the SAP
`
`example to reinforce that a conversational flow relates to a specific activity as
`
`requested by a client. Petitioner’s expert provides no testimony supporting its
`
`assertion that the SAP example describes different clients as being part of the same
`
`conversational flow. See Paper 32 at 9. Nor did Petitioner include any other evidence
`
`to support its new SAP theory with its Reply. Thus, Ms. Quigley’s testimony about
`
`how a POSITA would understand the SAP example stands unrebutted.
`
`The Panel’s analysis of the SAP example is wrong. The Panel glossed over
`
`highly technical material, ignoring conditional language from the specification that
`
`explains what the patentee is teaching about the recognition of network activities
`
`involving complicated server announcement protocols. If the address for a print
`
`service becomes known to multiple clients, those clients do not then have to make
`
`the same request to use the service that was previously announced. Instead, they can
`
`initiate a conversation with those services based on the previously obtained
`
`announcement information. Likewise, the network monitor can rely on the same
`
`14
`
`
`
`announcement information to properly recognize subsequent packet exchanges from
`
`different clients as relating to the service or application that was announced.
`
`V. THE ACTING DIRECTOR LACKS AUTHORITY TO RULE ON THIS REQUEST
`Ruling on this Request must be delayed until a Director is properly appointed
`
`and confirmed. The Acting Director lacks authority to rule on this Request under
`
`Arthrex and, alternatively, the Federal Vacancies Reform Act, which limits the
`
`duration of an acting officer’s authority to 210 days. See United States v. Arthrex,
`
`Inc., 141 S. Ct. 1970, 1980, 1987 (2021); 5 U.S.C. §§ 3345, 3346.
`
`VI. CONCLUSION
`For the reasons enumerated above, Patent Owner requests that the Director
`
`reverse the Panel’s finding that the challenged claims are unpatentable.
`
`
`
`
`
`
`
`Dated: October 8, 2021
`
`
`
`Respectfully submitted,
`
`
`
`
`
`
`
`
`
`By: /R. Allan Bullwinkel/
`
`R. Allan Bullwinkel (Reg. No. 77,630)
`
`Attorney for Patent Owner
`
`Packet Intelligence LLC
`
`15
`
`
`
`CERTIFICATE OF SERVICE
`
`The undersigned certifies that pursuant to 37 C.F.R. § 42.6(e), a copy of the
`
`foregoing PATENT OWNER’S REQUEST FOR DIRECTOR REVIEW was served
`
`via email to the Director (Director_PTABDecision_Review@uspto.gov) and lead
`
`and backup counsel of record for Petitioners as follows:
`
`202-362-3536
`Phone:
`adam.allgood@fischllp.com
`
`Lead Counsel for Petitioner
`Joseph F. Edell (Reg. No. 67,625)
`Phone:
`202-362-3524
`FISCH SIGLER LLP
`joe.edell.IPR@fischllp.com
`5301 Wisconsin Avenue NW
`
`Fourth Floor
`
`Washington, DC 20015
`Back-Up Counsel for Petitioner
`Scott A. McKeown (Reg. No. 42,866)
`Phone:
`202-508-4740
`ROPES & GRAY LLP
`scott.mckeown@ropesgray.com
`
`2099 Pennsylvania Avenue, NW
`Washington, D.C. 20006-6807
`Adam A. Allgood (Reg. No. 67,306)
`FISCH SIGLER LLP
`5301 Wisconsin Avenue NW
`Fourth Floor
`Washington, D.C. 20015
`James R. Batchelder
`forthcoming)
`ROPES & GRAY LLP
`1900 University Avenue, 6th Floor
`East Palo Alto, CA 94303-2284
`Mark D. Rowland (Reg. No. 32,077)
`ROPES & GRAY LLP
`1900 University Avenue, 6th Floor
`East Palo Alto, CA 94303-2284
`Andrew Radsch (pro hac forthcoming)
`ROPES & GRAY LLP
`1900 University Avenue, 6th Floor
`East Palo Alto, CA 94303-2284
`
`(pro hac
`
`650-617-4000
`Phone:
`james.batchelder@ropesgray.com
`
`
`
`650-617-4000
`Phone:
`mark.rowland@ropesgray.com
`
`
`650-617-4000
`Phone:
`Andrew.radsch@ropesgray.com
`
`
`
`16
`
`
`
`
`Dated: October 8, 2021
`
`
`
`
`
`
`
`By: /R. Allan Bullwinkel/
`
`R. Allan Bullwinkel (Reg. No. 77,630)
`
`Attorney for Patent Owner
`
`Packet Intelligence LLC
`
`17
`
`
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
