`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
` ____________
`
`SANDVINE CORPORATION AND SANDVINE INCORPORATED ULC,
`Petitioners
`
`v.
`
`PACKET INTELLIGENCE, LLC,
`Patent Owner.
`
`____________
`
`Case No. IPR2017-00450
`U.S. Patent No. 6,771,646
` ____________
`
`
`
`
`
`PETITIONERS’ REQUEST FOR REHEARING
`UNDER 37 C.F.R. § 42.71(D)
`
`
`
`TABLE OF CONTENTS
`
`Overlooked the Disclosure of the Engel Appendix VI and the Lin
`
`INTRODUCTION ............................................................................................... 1
`I.
`II. APPLICABLE STANDARDS .......................................................................... 3
`III. ARGUMENT .................................................................................................... 4
`A. Regarding Application Level Dialogs, The Decision Misapprehended or
`Declaration .................................................................................................. 4
`B. Regarding Application-Specific Server Statistics, The Decision
`and the Lin Declaration ............................................................................. 12
`IV. CONCLUSION ............................................................................................... 15
`
`Misapprehended or Overlooked the Disclosure of the Engel Appendix VI
`
`
`
`
`
`I.
`
`INTRODUCTION
`
`In response to the Decision Denying Institution of Inter Partes Review
`
`entered July 26, 2017, (Paper 8, hereinafter “Decision”) and pursuant to 37 C.F.R.
`
`§ 42.71(d), Sandvine Corporation and Sandvine Incorporated ULC (“Petitioners”)
`
`hereby respectfully request the Patent Trial and Appeal Board (“Board”)
`
`reconsider its decision denying institution for inter partes review of claims 1–3 and
`
`7–20 of U.S. Patent No. 6,771,646 (EX1001, “the ‘646 Patent”).
`
`The grounds of invalidity raised by Petitioners in the Petition (Paper 2,
`
`hereinafter “Petition”) are based principally on the Engel1 reference. Decision at
`
`6-7. The Board denied institution, finding generally that Engel did not disclose
`
`application-specific dialogs
`
`that would satisfy
`
`the “conversational flow”
`
`requirement of the Challenged Claims, but rather disclosed dialogs grouped by a
`
`particular layer without regard to application. Decision at 18-24.
`
`Petitioners respectfully request rehearing of the decision denying institution
`
`because it appears the Board overlooked or misapprehended parts of the Engel
`
`Appendix VI source code relied upon to demonstrate application-specific dialogs.
`
`Specifically, the Engel Appendix VI source code disclosed that (i) Application
`
`1 Engel refers collectively to the Engel patent (EX1007) and Appendices I-VI
`
`referenced therein. See, e.g., EX1007 at 1:10-15, 5:52-6:3; EX1008 (Appendices
`
`I-V); EX1009 (Appendix VI). See also Decision, Paper 8, at note 3.
`
`1
`
`
`
`Level Dialogs are looked-up in an application-specific dialog hash table through
`
`application-specific processing routines and (ii) the hash look-up table includes
`
`only dialog records for the specific application. Similarly, the Board overlooked or
`
`misapprehended parts of the Engel Appendix VI source code demonstrating that (i)
`
`Application-Specific Server Statistics are looked-up in an application-specific
`
`server hash table through application-specific processing routines and (ii) the hash
`
`look-up table includes only server records for the specific application. The Petition
`
`used NFS as an exemplary application activity to make this point, but also noted
`
`that source code supported other expressly disclosed application activities (e.g.,
`
`FTP, SMTP, Telnet) each of which included similar, if not identical, application-
`
`specific processing routines to those specifically discussed for NFS. Put simply,
`
`each supported application in Engel has its own code and own data structures for
`
`creating and tracking its own application-specific dialogs and server statistics.
`
`The Board either did not apprehend or overlooked this evidence in the
`
`Decision, and this evidence demonstrates that the Board’s conclusion is
`
`inconsistent with the only record evidence on the point. Accordingly, Petitioners
`
`request rehearing and, because the overlooked or misapprehended evidence
`
`negates the only basis on which the Board denied institution, Petitioners further
`
`request institution of trial in this matter.
`
`This request is timely under 37 CFR §42.71(d)(2) because it was filed within
`
`2
`
`
`
`thirty days of the Board’s decision denying institution of a trial on the ‘646 Patent.
`
`II. APPLICABLE STANDARDS
`“A party dissatisfied with a decision may file a request for rehearing,
`
`without prior authorization from the Board.” 37 C.F.R. §42.71(d). “The request
`
`must specifically identify all matters the party believes the Board misapprehended
`
`or overlooked, and the place where each matter was previously addressed in a
`
`motion, an opposition, or a reply.” Id. The Board reviews a decision for an abuse
`
`of discretion. 37 C.F.R. §42.71(c).
`
`The Board has granted requests for rehearing and instituted a previously
`
`denied
`
`inter partes
`
`review proceeding after determining
`
`that
`
`it had
`
`misapprehended and/or overlooked evidence that was relied upon by the
`
`Petitioners. Exemplary opinions reflecting such action may be found in Merial
`
`Limited v. Virbac IPR2014-01279, Paper 18 at 7 (Apr. 15, 2015) (granting
`
`rehearing and ordering institution, finding: “Petitioner emphasizes the ‘optional’
`
`nature of the cosolvent, a matter we overlooked in entering our order declining to
`
`institute an inter partes review trial.”) and Daicel Corp. v. Celanese International
`
`Corp. IPR2015-00171, Paper 13 at 3-4 (Jun. 26, 2015) (granting rehearing and
`
`ordering institution, determining that it had “misapprehended the significance of
`
`this argument in the Petition, and overlooked the fact that Mr. Cooper’s opinion is
`
`also based on his own calculations and data in two published articles”).
`
`3
`
`
`
`III. ARGUMENT
`Petitioners request reconsideration of the decision not to institute inter
`
`partes review on all grounds raised in the Petition because the Decision
`
`misapprehends or overlooks Engel’s Source Code Appendix VI (and the Lin
`
`Declaration describing the same), which showed that Engel links communications
`
`by application, not by layer. Namely, each Application Level Dialog and
`
`Application-Specific Server Statistics record in Engel is part of an application-
`
`specific hash table that only includes dialog or server records for a particular
`
`identified application. These application-specific hash tables are used by
`
`application-specific lookup routines based on an identification of the packet’s
`
`application activity. The Board appears to have either misapprehended the
`
`significance of Appendix VI and Dr. Lin’s analysis thereof or overlooked the vast
`
`majority of it altogether.
`
`A. Regarding Application Level Dialogs, The Decision
`Misapprehended or Overlooked the Disclosure of the Engel
`Appendix VI and the Lin Declaration
`
`The Board’s Decision repeatedly concludes that Petitioners did not point to
`
`anything in Engel indicating that Engel links communications by application (as
`
`opposed to by layer and client-server pair). Decision at 21 (“Petitioner’s position
`
`appears
`
`to be
`
`that conversational flows exist
`
`in Engel simply because
`
`communications exist at the application layer and because those communications
`
`4
`
`
`
`result from some application activity. See Pet. 16–21. As explained in connection
`
`with Patent Owner’s illustration above, however, we do not see—and Petitioner
`
`does not point to—anything in Engel indicating that it links communications by
`
`application (as opposed to by layer and client-server pair) as our interpretation of
`
`‘conversational flow” above requires.”) (emphasis added); see also id. at 19
`
`(“Petitioner [] does not point to any disclosure in Engel indicating that its disclosed
`
`system relates information from one packet to another as pertaining to a specific
`
`application activity. … [E]ven if application activity causes the dialog to be created,
`
`Petitioner does not direct us to teachings or disclosure of identifying a sequence of
`
`packets as being part of a specific application activity.”). The Decision further
`
`dismisses Dr. Lin’s testimony, stating that Dr. Lin “only explains in [paragraph 86]
`
`how Engel searches for existing dialogs based on the client-server IP address pair,
`
`not based on application.” Decision at 21-22 (citing only to EX1006 at ¶86).
`
`As discussed in detail below, the Petition demonstrates in Element 1(b) (“a
`
`memory for storing a database comprising flow-entries for previously encountered
`
`conversational flows to which a received packet may belong”) that the database for
`
`storing dialog records for a particular application activity in Engel are specific only
`
`to that activity. Then, with respect to the related Element 1(d) (“a lookup engine []
`
`configured to lookup whether a received packet belongs to a flow-entry in the
`
`flow-entry database”), the Petition demonstrates that the hash tables and lookup
`
`5
`
`
`
`routines used to lookup the application level dialogs in the database are, again,
`
`specific only to that activity. The disclosures explained in detail in Element 1(d)
`
`were all cited with respect to Element 1(b), were explained in detail in connection
`
`with the actual “lookup” limitation. The disclosures relied upon demonstrate a
`
`conversational flow in contradiction to the Board’s finding.
`
`To demonstrate application specific “conversational flows,” the Petition
`
`utilized an exemplary set of source code operations from Appendix VI for an NFS
`
`application dialog. The NFS example showed that the dialog records for an NFS
`
`activity were NFS specific (Petition at 18-19), the hash tables were NFS specific
`
`(id. at 29-31), and the lookup routines were NFS specific (id.). In other words, the
`
`entire processing around an Engel Application Level Dialog is specific to the
`
`particular application – NFS in the example. The Petition further noted that the
`
`Engel code supports other application activities (e.g., FTP, SMTP, Telnet) in a
`
`similarly application specific manner. The uncontroverted testimony of Dr. Lin’s
`
`analysis of the Engel source code demonstrates that each such application activity
`
`includes nearly identical processing to that described with respect to NFS — i.e.,
`
`its own application specific look-up processing routines that use an application-
`
`specific dialog hash table including only dialog records for the specific application.
`
`Petition at fn. 2 on 16-17 (citing EX1006 at ¶¶74, 108); see also EX1006 at ¶¶74,
`
`86-88, 108, 53-54 (all cited in the Petition at 16-21).
`
`6
`
`
`
`Utilizing the NFS application as an example, the Petition first demonstrated
`
`that the data structures used to store Application Level Dialogs are application
`
`specific: “Application level dialogs, such as for NFS, are stored as StatsAddrEntry
`
`records, with a stats_ptr pointer to a linked StatsNfsDialogEntry record[.]” Petition
`
`at 18-19 (citing EX1009 at pp.179, 249-250; EX1006, ¶¶54-61) (emphasis added).
`
`See also Petition at 19 (code defining StatsNfsDialogEntry reproduced from
`
`EX1009 at pp.249-250 and citing EX1006 at ¶¶54-61). This StatsNfsDialogEntry
`
`data structure is defined in the stats_nfs.h source code file, which source code is
`
`applicable only to NFS application activity. EX1006 at ¶58. There would be no
`
`need for application-specific dialog data structures if Engel maintained dialogs for
`
`a particular layer without regard to application as the Board has concluded.
`
`Next, the Petition noted that the look-up process for Application Dialogs
`
`was application specific. Appendix VI discloses that the dialog look-up is
`
`performed with an application-specific routine (e.g., stats_nfs_lookup_dialog),
`
`which consults an application-specific hash table (e.g., nfs_dialog_hash_table),
`
`which in turn includes a linked list of application-specific dialog records. Petition
`
`at 20 (“Engel’s application level lookup_dialog routines search for existing dialogs
`
`based on application and the client-server IP address pair of the communication”);
`
`id. at 29-31 (describing the application-specific nature of the lookup routine in
`
`detail); EX1009 at pp.478-480, 484, 179 and EX1006 at ¶¶53-54, 86, 88 (each
`
`7
`
`
`
`cited in Petition at 17-18). Each application-specific dialog hash table includes
`
`only dialog records for the specified application. Dr. Lin explains:
`
`“The stats_nfs_lookup_dialog routine then uses the hash function as
`an index to the nfs_dialog_hash_table, thereby setting up a pointer to
`an
`indexed
`entry
`of
`the
`dialog
`hash
`table.
`The
`stats_nfs_lookup_dialog routine then walks the linked list of NFS
`dialog records to determine whether the IP address pair matches an
`IP address pair of an entry in the database, based on a comparison of
`the extracted IP addresses with the IP addresses stored in each dialog
`record of the NFS dialog hash table. Engel Appendix VI at pp. 478-
`480 of stats_nfs_p.c.”
`
`EX1006 at ¶86 (emphasis added); see also id. at ¶54 (“Each NFS dialog record is
`
`part of a doubly linked list, including forward and backward pointers to
`
`neighboring NFS dialog records in the nfs_dialog_hash_table (i.e., the ‘link’ and
`
`‘*hash_link’ fields of the StatsAddrEntry dialog record). Engel Appendix VI at pp.
`
`479, 484 of stats_nfs_p.c.”); ¶53 (“Each dialog record is part of a doubly linked
`
`list, including forward and backward pointers to neighboring dialog records in an
`
`application-specific dialog hash table.”); ¶88 (describing newly allocated NFS
`
`dialogs added to the nfs_dialog_hash_table) (cited in Petition at 17-20, 30-31).
`
`The application-specific look-up routine stats_nfs_lookup_dialog is in the
`
`stats_nfs_p.c source code file, which source code is applicable only to NFS
`
`application activity. EX1006 at ¶86. The cited source code itself confirms that the
`
`8
`
`
`
`purpose of stats_nfs_lookup_dialog is to “find a nfs dialog given 2 ip addresses.”
`
`
`
`EX1009 at p.478 (cited in Petition at 17, 20 and reproduced at 30); EX1009 at
`
`p.480 (describing stats_nfs_get_dialog as to “find or allocate an nfs dialog given 2
`
`ip addresses”) (cited in Petition at 17, 31); see generally id. pp.478-480. If the
`
`searched hash table included records for application layer activities other than
`
`NFS, such a search would not necessarily result in finding an NFS dialog. While
`
`the Board mentioned ¶86 of the Lin Declaration in its Decision, the Board appears
`
`to have misapprehended the import (especially considering fn. 2 of the Petition and
`
`the cited ¶¶74 and 108 of the Lin Declaration), i.e., that the look-up processing is
`
`performed in application specific routines using application specific hash tables to
`
`find application specific dialog records. The fact that Engel expressly discloses
`
`application specific dialogs is directly inconsistent with the Board’s conclusion
`
`that Engel groups communications only by layer without regard to application.
`
`In addition to NFS, the Appendix VI Source Code supported FTP, Telnet,
`
`and SMTP, where each supported application will have its own lookup_dialog
`
`routine
`
`(e.g.,
`
`stats_ftp_lookup_dialog
`
`or
`
`stats_telnet_lookup_dialog
`
`or
`
`stats_smtp_lookup_dialog) and consults its own application-specific dialog hash
`
`9
`
`
`
`table
`
`(e.g.,
`
`ftp_dialog_hash_table
`
`or
`
`telnet_dialog_hash_table
`
`or
`
`smtp_dialog_hash_table) to determine whether a packet is part of a previously
`
`encountered application-specific dialog. EX1006 at ¶108 (cited in Petition at fn. 2),
`
`¶53 (cited in Petition at 17-18). While not as detailed as Appendix VI, the Engel
`
`patent itself is consistent with the source code. EX1007, Engel at 15:35-39
`
`(identifying statistics “records” that are kept per each nfs pair, ftp control and data
`
`connection, telnet connection, and smtp connection) (cited in Petition at fn. 2).
`
`The determination of which application-specific routines will be executed on
`
`a particular packet is determined “based on the program identified from the port to
`
`program map.” EX1006 at ¶74 (cited in Petition at fn. 2 on 16-17). For example:
`
`“If the program identified is FTP, the next layer’s parse routine is
`rtp_ftp_parse. Engel Appendix VI at p. 132 of rtp_tcp_p.c. If the
`program identified is Telnet, the next layer’s parse routine is
`rtp_telnet_parse. Engel Appendix VI at p. 132 of rtp_tcp_p.c. If the
`program identified is SMTP, the next layer’s parse routine is
`rtp_smtp_parse. Engel Appendix VI at p. 132 of rtp_tcp_p.c. Finally,
`if the program identified is PortMapper, NFS, or NFS Mount, the next
`layer’s parse routine is rtp_rpc_parse. Engel Appendix VI at p. 132 of
`rtp_tcp_p.c.”
`
`Id.; see EX1009 at p.132. All of this detailed disclosure presents, at a minimum,
`
`compelling evidence demonstrating that it is at least reasonably likely that the
`
`Application Layer Dialogs in Engel are application specific. The Board’s contrary
`
`10
`
`
`
`determination is directly at odds with these disclosures. The illustration of the
`
`operation of Engel relied upon by the Board (Decision at 20-21) cannot be aligned
`
`with the application-specific disclosure of Source Code Appendix VI. As
`
`demonstrated in the Petition and reiterated in this request for rehearing, NFS
`
`packets on a first and second connection between Nodes A and B are collectively
`
`tracked as an NFS Dialog (i.e., “conversational flow”); packets of an SMTP
`
`communication between Nodes A and B are collectively tracked as an SMTP
`
`Dialog; packets of a Telnet communication between Nodes A and B
`
`are collectively tracked as a Telnet Dialog; and so on.
`
`Neither Patent Owner nor its expert offered any discussion of Source Code
`
`Appendix VI in the Patent Owner Preliminary Response, and instead emphasized
`
`only the limited disclosures in the Engel patent itself. By turning a blind eye to the
`
`Appendix VI and considering only the Engel patent, Patent Owner’s declarant, Dr.
`
`Almeroth opined that Engel could be understood to be disclosing layer-specific
`
`dialogs as opposed to application-specific dialogs. The Board’s reliance on layer-
`
`specific expert opinions formed without the benefit of Appendix VI is misplaced
`
`and cannot be squared with the Appendix VI Source Code, and its application-
`
`specific routines for creating application-specific dialogs and server statistics.
`
`The testimony of Dr. Lin regarding the application specific operation of the
`
`Engel Appendix VI source code is unrefuted. Petitioners’ discussion of the Engel
`
`11
`
`
`
`Appendix VI source code in the Petition is unrebutted. The only record evidence
`
`at this stage addressing Appendix VI is the Appendix itself and Dr. Lin’s
`
`explanation of the same. The Board’s Decision does not meaningfully discuss this
`
`key evidence. In view of the foregoing, Petitioners urge that the Board’s Decision
`
`be reconsidered and trial instituted.
`
`B. Regarding Application-Specific Server Statistics, The Decision
`Misapprehended or Overlooked the Disclosure of the Engel
`Appendix VI and the Lin Declaration
`
`For Application-Specific Server Statistics, the Decision similarly concludes
`
`that Petitioners did not point to anything in Engel indicating that Engel links
`
`communications by application. Decision at 23 (“As explained above, however,
`
`Petitioner has only shown that Engel links packets (and tracks corresponding
`
`statistics) by layer and client-server pair, not by application.”). For the reasons
`
`discussed in Section III.A, Petitioners respectfully submit that the Decision
`
`misapprehended or overlooked the discussion of Source Code Appendix VI in the
`
`Petition that directly contradicts this central premise of the Board’s Decision.
`
`For Application-Specific Server Statistics, the Decision also found: “We see
`
`no disclosure in Engel of linking these disjointed dialogs into a ‘conversational
`
`flow.’ Petitioner’s cited portions of Engel shed no light on such connections. See
`
`Pet. 24–25 (citing Ex. 1007, col. 18, ll. 41–62, col. 17, l. 32–col. 18, l. 40).
`
`12
`
`
`
`Keeping statistics relating to separate dialogs does not extend to linking unique
`
`dialogs, let alone linking them based on a specific application.” Decision at 23.
`
`Petitioners respectfully submit that the Board misapprehended or overlooked
`
`the significant evidence cited to in the Petition and in the Lin Declaration showing
`
`that Engel, in fact, links dialogs based on a specific application. To demonstrate
`
`application-specific server statistics satisfying “conversational flows,” the Petition
`
`again relied on the Appendix VI source code and Dr. Lin’s explanation of the same.
`
`Petition at 21-27, 31-33. Like the application-specific dialogs, each application-
`
`specific server statistic record is part of an application-specific server hash table
`
`that includes only server records for the particular application. Petition at 31-33
`
`(citing EX1009 at pp.179, 475-477; EX1006 at ¶¶62, 64, 84-85 (each cited in
`
`Petition at 23-24)). In the case of NFS, the stats_nfs_lookup_server routine
`
`determines whether the server has a record in the nfs_server_hash_table. Id. Here
`
`again, the source code itself confirms that the purpose of stats_nfs_lookup_server
`
`is to “find the nfs server” using a hash of a single IP address.
`
`
`
`13
`
`
`
`EX1009 at p.475 (cited in Petition at 23-24 and reproduced at 32); EX1009 at
`
`p.476 (describing stats_nfs_get_server as to “find the structure for keeping nfs
`
`statistics for the given ip address”) (cited in Petition at 23-24, 33); see generally id.
`
`at pp.475-476. If the searched hash table included records for application activities
`
`other than NFS, such a search would not necessarily result in finding an NFS
`
`server. Again, this processing is application specific and leads to application-
`
`specific server statistics records. See generally Petition at fn. 3 on 21-22 and
`
`EX1006 at ¶¶74, 82-88, 108, EX1009 at p.132.
`
`Even further, each server statistics record includes a dialog link queue
`
`(“dialogQ”), linking all application-specific dialog records for the same application
`
`activity in which the server has participated. Petition at 24-25; also id. at 27 (citing
`
`EX1006 at ¶¶65, 88). As Dr. Lin explains:
`
`“As shown above, each NFS client/server record includes a pointer to
`a linked list of all NFS dialogs to which the client/server has
`participated (“dialogQ” field). Namely, when a new application-
`specific dialog (i.e., NFS dialog) is allocated for a given client/server
`pair, the new dialog record is added to the dialog link queue for each
`application-specific client and server record (i.e., each NFS client and
`server record). Engel Appendix VI at pp. 483-484 of stats_nfs_p.c;
`see also Section VII.C.7 (Paragraphs 86-88) below.”
`
`EX1006 at ¶65; see also id. at ¶88, EX1009 at pp. 483-484. This dialog link queue
`
`provides a linked list of application-specific dialog records (e.g., NFS dialogs) for
`
`14
`
`
`
`a particular server and is based on the specifically identified application (e.g., NFS).
`
`Thus, not only are the dialog and server statistic records application specific, but
`
`each application-specific server statistics record expressly links the individual
`
`disjointed dialogs in which the server has participated for the application in
`
`question. This is exactly the type of “virtual concatenation” or “linking” of
`
`disjointed exchanges contemplated by the ‘646 Patent and discussed in the Petition.
`
`Petition at 22-23; EX1014 at p.9; EX1003, ‘099 Patent at 3:44-51.
`
`In light of the above, the Board either overlooked or misapprehended this
`
`substantial evidence in determining that Engel did not disclose application specific
`
`Application Layer Dialogs and Application-Specific Server Statistics. Accordingly,
`
`reconsideration is proper and trial should be instituted.
`
`IV. CONCLUSION
`For these reasons, Petitioners respectfully request that the Board reconsider
`
`its Decision and institute inter partes review of the ‘646 Patent.
`
`Date: August 25, 2017
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Respectfully submitted,
`
`ERISE IP, P.A.
`
`
`
`
`
`
`
`BY: /s/ Eric A. Buresh
`
`
`
`
`Eric A. Buresh, Reg. No. 50,394
`Counsel for Petitioners
`
`
`
`15
`
`
`
`
`Pursuant to 37 C.F.R. §§ 42.6(e), the undersigned certifies that on August 25,
`2017, a true and correct copy of this PETITIONERS’ REQUEST FOR
`REHEARING UNDER 37 C.F.R. § 42.71(d) was served on the counsel for Patent
`Owner by electronic means at the following addresses of record:
`
`Steven W. Hartsell Reg. No: 58,788
`Skiermont Derby LLP
`2200 Ross Ave., Suite 4800W
`Dallas, Texas 75201
`Tel: (214) 978-6600
`Fax: (214) 978-6601
`packetintelligence@skiermontderby.com
`Lead Counsel for Patent Owner
`
`Paul J. Skiermont
`Skiermont Derby LLP
`2200 Ross Ave., Suite 4800W
`Dallas, Texas 75201
`Tel: (214) 978-6600
`Fax: (214) 978-6601
`packetintelligence@skiermontderby.com
`Back-Up Counsel for Patent Owner
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BY:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CERTIFICATE OF SERVICE ON PATENT OWNER
`
`Alexander E. Gasser (Reg. No: 48,760)
`Skiermont Derby LLP
`2200 Ross Ave., Suite 4800W
`Dallas, Texas 75201
`Tel: (214) 978-6600
`Fax: (214) 978-6601
`packetintelligence@skiermontderby.com
`Back-Up Counsel for Patent Owner
`
`Sadaf R. Abdullah
`Skiermont Derby LLP
`2200 Ross Ave., Suite 4800W
`Dallas, Texas 75201
`Tel: (214) 978-6600
`Fax: (214) 978-6601
`packetintelligence@skiermontderby.com
`Back-Up Counsel for Patent Owner
`
`
`
`ERISE IP, P.A.
`
`
`
`
`
`
` /s/ Mark C. Lang
`
`
`Eric A. Buresh, Reg. No. 50,394
`Mark C. Lang, Reg. No. 55,356
`Kathleen D. Fitterling, Reg. No. 62,950
`6201 College Blvd., Suite 300
`Overland Park, KS 66211
`P: (913) 777-5600
`F: (913) 777-5601
`eric.buresh@eriseip.com
`mark.lang@eriseip.com
`kathleen.fitterling@eriseip.com
`
`
`
`
`
`Abran J. Kean, Reg. No. 58,540
`5600 Greenwood Plaza Blvd., Suite 200
`Greenwood Village, CO 80111
`Phone: (913) 777-5600
`
`
`
`
`
`
`
`
`
`
`
`ATTORNEYS FOR PETITIONERS
`
`
`
`
`
`
`
`
`
`
`
`
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
