Page 1 of 66 

IN THE UNITED STATES DISTRICT COURT 

FOR THE WESTERN DISTRICT OF TEXAS 

WACO DIVISION 

CONVERSANT WIRELESS LICENSING 

S.A.R.L., 

 Plaintiff, 

 v. 

TESLA, INC., 

 Defendant. 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

Civil No. 6:20-cv-00323 

JURY TRIAL DEMANDED 

ORIGINAL COMPLAINT FOR PATENT INFRINGEMENT 

Plaintiff Conversant Wireless Licensing S.A.R.L. (“Conversant”) files this Complaint for 

patent infringement against Defendant Tesla, Inc. (“Tesla” or “Defendant”), alleging as follows: 

NATURE OF SUIT 

1. This is a claim for patent infringement arising under the patent laws of the United 

States, Title 35 of the United States Code. 

PARTIES 

2. Plaintiff Conversant Wireless Licensing S.A.R.L. (“Conversant”) is a corporation 

duly organized and existing under the laws of the Grand Duchy of Luxembourg, having a principal 

place of business at 12, rue Jean Engling, L-1466, Luxembourg. Conversant has a regular and 

established place of business and does business relating to the Patents-in-Suit, as defined in 

section I below, in connection with its wholly-owned subsidiary, Conversant Wireless Licensing 

Ltd. (“Conversant USA”), a corporation duly organized and existing under the laws of the State of 

Texas, having a principal place of business at 5630 Granite Parkway #100-247, Suite 247, Plano, 

TX 75024. All pertinent documents and discovery relevant to this matter either reside at 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 1 of 66
Page 2 of 66 

Conversant USA’s local address or will be produced at that address. Conversant is the owner of 

record of the Patents-in-Suit in this action. 

3. Defendant Tesla, Inc. (“Tesla” or “Defendant”) is a corporation organized under 

the laws of the State of Delaware, having a principal place of business at 3500 Deer Creek Road, 

Palo Alto, CA 94304. Tesla may do business with the fictitious name Tesla Motors, Inc. Tesla 

can be served with process through its registered agent in the State of Texas, CT Corporation, 1999 

Bryan St., Suite 900, Dallas, Texas 75201-3136. 

JURISDICTION AND VENUE 

4. This action arises under the patent laws of the United States, 35 U.S.C. § 101, et 

seq. This Court has jurisdiction over this action pursuant to 28 U.S.C. §§ 1331 and 1338(a). 

5. Tesla is subject to personal jurisdiction in this Court. This Court has personal 

jurisdiction over Tesla because Tesla has engaged in continuous, systematic, and substantial 

activities within this State, including substantial marketing and sales of products within this State 

and this District. Furthermore, upon information and belief, this Court has personal jurisdiction 

over Tesla because Tesla has committed acts giving rise to Conversant’s claims for patent 

infringement within and directed to this District. 

6. Upon information and belief, Tesla has conducted and does conduct substantial 

business in this forum, directly and/or through subsidiaries, agents, representatives, or 

intermediaries, such substantial business including but not limited to: (i) at least a portion of the 

direct and indirect acts of infringement alleged herein; (ii) purposefully and voluntarily placing 

one or more infringing products into the stream of commerce with the expectation that they will 

be purchased by consumers in this forum; or (iii) regularly doing or soliciting business, engaging 

in other persistent courses of conduct, or deriving substantial revenue from goods and services 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 2 of 66
Page 3 of 66 

provided to individuals in Texas and in this judicial district. Thus, Tesla is subject to this Court’s 

specific and general personal jurisdiction pursuant to due process and the Texas Long Arm Statute. 

7. Upon information and belief, Tesla has committed acts of infringement in this 

District and has one or more regular and established places of business within this District under 

28 U.S.C. § 1400(b). Thus, venue is proper in this District under 28 U.S.C. § 1400(b). 

8. Tesla maintains a permanent physical presence within this District. For example, 

it maintains galleries at (1) 12845 Research Boulevard, Austin, Texas 78759; (2) 11600 Century 

Oaks Terrace, Austin, Texas 78758; and (3) 23011 IH-10 West, San Antonio, Texas 78257. Tesla 

also maintains service centers in this District, including at 12845 Research Boulevard, Austin, 

Texas 78759; 23011 IH-10 West, San Antonio, Texas 78257; and 28 Walter Jones, Suite C, El 

Paso, Texas. Tesla conducts business from at least these locations. Tesla employs employees who 

work at Tesla’s locations in this District. 

9. In addition, Tesla maintains charging stations throughout this District. Tesla 

features commercial signage at each Supercharger station identifying the location as a regular and 

established place of Tesla’s business. Moreover, Superchargers are monitored closely and 

regularly serviced by Tesla Service Technicians. Tesla’s Supercharging stations in this District 

include at least at the following locations: (1) Austin, TX – Research Boulevard Supercharger, 

9607 Research Boulevard, Austin, TX 78759; (2) Austin, TX Supercharger, 6406 N. Interstate 35 

Frontage Road, Austin, TX 78752; (3) El Paso Supercharger, 6401 South Desert Boulevard, El 

Paso, Texas 79932; (4) Fort Stockton, TX Supercharger, 2571 North Front Street, Fort Stockton, 

Texas 79735; (5) Giddings, TX Supercharger, 3025 East Austin Street, Giddings, Texas 78942; 

(6) Junction Supercharger, 2415 N Main Street, Junction, Texas 76849; (7) Leon Springs, TX 

Supercharger, 24165 I-10 #300, San Antonio, Texas 78357; (8) Midland Supercharger, 3001 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 3 of 66
Page 4 of 66 

Antelope Trail, Midland, Texas 79706; (9) Pecos, TX Supercharger, 100 East Pinehurst Street, 

Pecos, Texas 79772; (10) San Antonio, TX Supercharger, 11745 I-10, San Antonio, Texas 78230; 

(11) San Marcos, TX Supercharger, 3939 Interstate 35, San Marcos, Texas 78666; (12) Van Horn 

Supercharger, 1921 Frontage Rd, Van Horn, Texas 79855; and (13) Waco Supercharger, 701 

Interstate 35, Bellmead, Texas 76705. Upon information and belief, Tesla also has eight (8) 

Supercharging stations “coming soon” to this District. 

10. Tesla’s locations in this District, including at least those identified in paragraphs 8 

and 9 above, are regular and established places of business under 28 U.S.C. § 1391, 28 U.S.C. 

§ 1400(b), and In re Cray, Inc., 871 F.3d 1355, 1360 (Fed. Cir. 2017). 

a. Tesla’s locations in this District, including at least those identified in 

paragraphs 8 and 9 above, are physical places in this District. Each gallery and service 

center comprises one or more buildings set apart for the purpose of offering for sale, selling, 

showcasing, and/or servicing infringing products. Each Supercharging station comprises 

a physical area set apart for the purpose of charging infringing products. Indeed, Tesla 

itself advertises its physical locations in this District as places of its business and it features 

commercial signage at each location. 

b. Tesla’s locations in this District, including at least those identified in 

paragraphs 8 and 9 above, are regular and established. Tesla features commercial signage 

at each location identifying the location as a regular and established place of Tesla’s 

business. 

c. Tesla’s locations in this District, including at least those identified in 

paragraphs 8 and 9 above, are places of business of Tesla. Tesla offers its own products 

and services for sale at its locations. 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 4 of 66
Page 5 of 66 

d. Tesla’s locations in this District, including at least those identified in 

paragraphs 8 and 9 above, are physical, geographical locations in this District from which 

Tesla carries out its business. 

e. Tesla employees work at Tesla’s locations, including at least those 

identified in paragraphs 8 and 9 above. Upon information and belief, these Tesla 

employees are regularly and physically present at Tesla’s locations, including at least those 

identified in paragraphs 8 and 9 above, during business hours and they are conducting 

Tesla’s business while working there. 

11. Further, upon information and belief, Tesla trains future employees (specifically, 

electric vehicle technicians) in this District at Tesla’s START Training Program housed at Texas 

State Technical College in Waco, Texas. Tesla provides the instructor, training equipment, 

vehicles, tools, and curriculum for the program. Students are employed by Tesla as hourly interns, 

and following completion of the program they are placed in a Tesla Service Center in North 

America. 

FACTUAL ALLEGATIONS 

I. PATENTS-IN-SUIT 

12. United States Patent No. 7,643,456 (“the ’456 Patent”) is entitled “Transfer of 

Packet Data to Wireless Terminal.” The ’456 Patent duly and legally issued on January 5, 2010, 

from U.S. Patent Application No. 10/957,777, filed on October 4, 2004. The ’456 Patent is a 

continuation of application No. PCT/FI03/00263, filed on April 8, 2003. The ’456 Patent is 

entitled to the benefit of the April 8, 2003 filing date of application No. PCT/FI03/00263. The 

’456 Patent names Jarkko Jouppi and Janne Rinne as inventors. Conversant is the current owner 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 5 of 66
Page 6 of 66 

of all rights, title, and interest in and to the ’456 Patent. A true and correct copy of the ’456 Patent 

is attached hereto as Exhibit A and is incorporated by reference herein. 

13. United States Patent No. 9,930,697 (“the ’697 Patent”) is entitled “Random Access 

Channel Response Handling with Aggegrated [sic] Component Carriers.” The ’697 Patent duly 

and legally issued on March 27, 2018 from U.S. Patent Application No. 14/976,154, filed on 

December 21, 2015. The ’697 Patent is a continuation of application No. 13/248,579, filed on 

September 29, 2011, now United States Patent No. 9,253,797. United States Patent No. 9,253,797 

is a division of application No. 12/384,950, filed on April 10, 2009, now United States Patent 

No. 8,077,670. The ’697 Patent is entitled to the benefit of the April 10, 2009 filing date of United 

States Patent No. 8,077,670. The ’697 Patent names Jianke Fan, Juha S. Korhonen, Mikko J. 

Rinne, and Esa M. Malkamaki as inventors. Conversant is the current owner of all rights, title, 

and interest in and to the ’697 Patent. A true and correct copy of the ’697 Patent is attached hereto 

as Exhibit B and is incorporated by reference herein. 

14. Collectively, the ’456 Patent and the ’697 Patent are referred to herein as the 

“Patents-in-Suit.” 

II. BACKGROUND 

15. In 2011, Conversant acquired a portfolio of close to 2,000 patents and patent 

applications previously owned by Nokia Corporation (“Nokia”), obtaining all right, title, and 

interest in, to and under the patents and patent applications in the portfolio, including without 

limitation the right to sue for past, present, or future infringements of the patents and patent 

applications acquired. By reason of the aforesaid, Conversant has, since 2011, been the owner of 

the Patents-in-Suit and the right to enforce them. Before Conversant became the owner of the 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 6 of 66
Page 7 of 66 

Patents-in-Suit, the Patents-in-Suit were originally invented by agents or employees of, procured 

by, or assigned to Nokia. 

16. Nokia is and has been a member of the European Telecommunications Standards 

Institute (“ETSI”), a non-profit Standard Setting Organization headquartered in France. 

Conversant and/or Nokia have made declarations in respect of the Patents-in-Suit to ETSI, one of 

the organizational partners of the Third Generation Partnership Project (“3GPP”) that organizes 

and maintains the development of telecommunications standards applicable to mobile 

communications products, devices, and services. Telecommunications standards applicable to 

wireless mobile communications devices include second generation technologies such as Global 

System for Mobile (“GSM”) and GSM Packet Radio Service (“GPRS”), third generation 

technologies such as Universal Mobile Telecommunications System (“UMTS”) and High Speed 

Packet Access (“HSPA”), and fourth generation technologies such as Long-Term Evolution 

(“LTE”). With respect to the Patents-in-Suit, the declarations and affirmations made by 

Conversant and/or Nokia include a provision to the effect that the declarant is prepared to grant 

irrevocable licenses to the Patents-in-Suit on fair, reasonable, and non-discriminatory (“FRAND”) 

terms. Conversant has specifically agreed to grant a license to the Patents-in-Suit under FRAND 

terms to willing licensees who negotiate in good faith. For example, on July 22, 2014, Conversant 

made a declaration to ETSI to the effect that it is willing and prepared to grant irrevocable licenses 

on terms and conditions that are FRAND with respect to the patents that it owns that cover 

functionality that has been implemented in mobile communications devices that are in compliance 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 7 of 66
Page 8 of 66 

with the requirements and technical specifications of the mobile communications standards that 

are promulgated by and maintained by 3GPP. 

III. CONVERSANT’S ATTEMPTS TO LICENSE TESLA 

17. On or about December 18, 2018, Conversant sent a letter and FRAND licensing 

offer to Tesla. The letter stated, “Conversant Wireless owns an extensive patent portfolio related 

to mobile communications networks, which includes hundreds of patents and patent applications 

that have been declared essential to 2G, 3G and 4G mobile standards.” Conversant then offered a 

FRAND license to its applicable standard-essential patent (“SEP”) portfolio: “Conversant 

Wireless is offering a FRAND license to its SEP portfolio to manufacturers of vehicles with 

cellular functionality, including Tesla.” As part of its FRAND offer, Conversant provided Tesla 

with access to a Share File site which included representative claim charts for Conversant’s patent 

portfolio. 

18. In addition, Conversant is a member of the Avanci patent pool. As such, upon 

information and belief, Avanci also offered Tesla a FRAND license to Conversant’s SEP patent 

portfolio, among other patents. 

19. As of December 18, 2018, the Shared Site provided by Conversant to Tesla 

included over 20 claim charts for Conversant’s Standard Essential Patents issued in the United 

States and foreign countries. At least by having access to this Shared Site, Tesla had knowledge 

of each of the Patents-in-Suit and its infringement of such patents, prior to the filing of this lawsuit. 

20. After Tesla ignored Conversant’s December 18, 2018 FRAND license offer, on 

February 26, 2019, Conversant again contacted Tesla to follow up on its previous offer, stating in 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 8 of 66
Page 9 of 66 

part, “As you are well aware, FRAND licensing of Standard Essential Patents (SEPs) requires 

active participation of both sides in the negotiations.” 

21. Tesla finally responded on April 4, 2019 but failed to provide any material response 

to Conversant’s FRAND offer and related correspondence. 

22. After no further communication from Tesla, on or about February 26, 2020, 

Conversant filed patent infringement complaints against Tesla, Inc. and its German subsidiary 

Tesla Germany GmbH before the Manheim Regional Court in Germany. 

23. On March 16, 2020, Conversant again contacted Tesla, informing it of the German 

patent infringement complaints, stating “Tesla’s failure to provide a material response or any 

further communication raises doubts as to its actual willingness to take a license. We also 

understand that Tesla has not taken the parallel pool offer from Avanci, which presents an 

alternative opportunity to license our portfolio. . . . We remain open and willing to discuss our 

bilateral license offer and hope that a meeting can be arranged promptly.” 

24. On March 26, 2020, Tesla responded by requesting a copy of the German patent 

infringement complaints and indicating that “Tesla is and remains a willing licensee of the 

Conversant portfolio for applicable standard-essential-patents (“SEP”),” and suggested that Tesla 

would formulate a counteroffer for Conversant’s portfolio for applicable SEPs. 

25. On April 6, 2020, Conversant responded by again offering a FRAND license to its 

SEP portfolio: “I can confirm that our applicable SEPs can be licensed either through the Avanci 

pool or by way of our bilateral FRAND license offer presented to you in December 2019. As we 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 9 of 66
Page 10 of 66 

understand that you have declined our bilateral FRAND offer, we now look forward to your 

mentioned counter offer.” 

26. To date, Tesla has not taken a license to Conversant’s patent portfolio, or any of 

the Patents-in-Suit. 

IV. THE TESLA STANDARD-COMPLIANT PRODUCTS 

27. As further discussed below, Tesla has directly and indirectly infringed and 

continues to directly and indirectly infringe each of the Patents-in-Suit by engaging in acts 

constituting infringement under 35 U.S.C. § 271(a), (b), and/or (c), including without limitation 

by one or more of making, using, selling and offering to sell, in this District and elsewhere in the 

United States, and importing into this District and elsewhere in the United States Tesla’s connected 

vehicle products (the “Tesla Standard-Compliant Products”). 

28. Tesla is doing business in the United States, and, more particularly, in the this 

District by making, using, selling, importing, and/or offering for sale the Tesla 

Standard-Compliant Products, including without limitation Tesla’s Model S, Model 3, Model X, 

Model Y, Cybertruck, and Roadster that infringe one or more of the patent claims involved in this 

action. 

29. Upon information and belief, and as widely reported, the Tesla Standard-Compliant 

Products, including the above-referenced connected vehicles, are compliant with at least 3G and/or 

4G/LTE cellular network standards . See, e.g., Tesla unveils world’s first mass-produced, highway 

capable EV, Tesla Investors, Mar. 26, 2009, https://ir.tesla.com/news-releases/news-releasedetails/tesla-unveils-worlds-first-mass-produced-highway-capable-ev (describing “in-car 3G 

connectivity”); Roger Cheng, Tesla taps AT&T to bring cellular connection to its cars, CNET, 

Oct. 17, 2013, https://www.cnet.com/news/tesla-taps-at-t-to-bring-cellular-connection-to-its-cars

(describing 3G and HSPA+ capability); First LTE-enabled Tesla Model S delivered, Electrek, June 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 10 of 66
Page 11 of 66 

5, 2015, https://electrek.co/2015/06/05/first-lte-enabled-model-s-delivered (reporting new Model 

S delivered with working 4G/LTE capability); Tesla to Acquire SolarCity: Presentation to Proxy 

Advisory Firms, Form S-4 File No.:333-213390, Oct. 25, 2016, at 16 (stating vehicle features 

include 4G/LTE connectivity); Russ Mitchell, Tesla Model 3 has some unusual features, including 

an instrument-free dash, Seattle Times, Aug. 5, 2017, 

https://www.seattletimes.com/business/tesla-model-3-has-some-unusual-features-including-aninstrument-free-dash (reporting Model 3 is 4G/LTE capable); Ryan Whittwam, Tesla will begin 

charging $10 per month for “Premium” LTE features, Dec. 9, 2019, 

https://www.extremetech.com/extreme/303159-tesla-will-begin-charging-10-per-month-forpremium-lte-features (reporting that all Tesla vehicles are 4G/LTE capable) (collectively attached 

hereto as Exhibit D1). 

30. Tesla’s Support webpage confirms that the Tesla Standard-Compliant Products, 

including Tesla’s Model 3, Model S, Model X, and Model Y connected vehicles, come with 

cellular connection capabilities. See, e.g., Support: Connectivity, Tesla, 

https://www.tesla.com/support/connectivity (attached hereto as Exhibit E). At a minimum, Tesla 

offers its connectively package with 3G and 4G/LTE cellular free for the first year (for orders of 

Model S, Model X, Model Y, and Model 3 with Premium Interior) and 30 days (for orders of 

Model 3 Standard Range and Standard Range Plus), and charges $9.99 per month thereafter. See 

id.

31. Further, the Owner’s Manuals for the Tesla Standard-Compliant Products, 

including Tesla’s Model 3, Model S, Model X, and Model Y connected vehicles, confirm that the 

Tesla Standard-Compliant Products are compliant with at least 3G and/or 4G/LTE cellular network 

 

1

 Exhibit C not used. 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 11 of 66
Page 12 of 66 

standards. For example, the Owner’s Manual for the Model S describes how the internet 

connection of the Model S can be switched from a cellular connection (“usually LTE or 3G”) to a 

Wi-Fi connection. See, e.g., Model S Owner’s Manual, v. 2020.4 North America, at 156 (attached 

hereto as Exhibit F). 

COUNT 1—INFRINGEMENT OF THE ’456 PATENT 

32. Conversant incorporates by reference the allegations set forth in Paragraphs 1–31 

of this Complaint as though fully set forth herein. 

33. In violation of 35 U.S.C. § 271(a), Tesla is and has been directly infringing one or 

more of the ’456 Patent’s claims, including at least Claim 7, by making, using, offering to sell, 

and/or selling in the United States, and/or importing into the United States, without authority, 

products that support 3G and/or 4G/LTE connectivity, including without limitation the Tesla 

Standard-Compliant Products as defined above. Each of the Tesla Standard-Compliant Products 

comprises hardware and software components that together practice every element of one or more 

claims of the ’456 Patent, including at least Claim 7. These components include those hardware 

and software components that enable the set of wireless cellular communications functionalities 

known as 3G and/or 4G/LTE and implement 3G and/or 4G/LTE in compliance with the 

requirements of the technical standards applicable to mobile communications, including the 

technical standards promulgated by 3GPP and various subsequent releases and versions thereof. 

These components enable the Tesla Standard-Compliant Products to perform 3G and/or 4G/LTE 

communications functionality. 

34. It is necessary to practice one or more of the claims of the ’456 Patent to comply 

with the requirements of certain standards applicable to mobile communications. For example, it 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 12 of 66
Page 13 of 66 

is necessary to practice at least Claim 7 from the ’456 Patent to comply with certain 3G and/or 

4G/LTE standards. 

35. The Tesla Standard-Compliant Products comply with the applicable standards 

covered by the claims of the ’456 Patent. 

36. The Tesla Standard Compliant Products comprise at least the wireless terminal of 

Claim 7 of the ’456 Patent. 

37. The applicable standards covered by the claims of the ’456 Patent describe, at least, 

the wireless terminal of Claim 7 of the ’456 Patent. 

38. By way of example, Claim 7 of the ’456 Patent requires “the wireless terminal 

being configured to transmit a configuration signal to a network node in a mobile system for 

activating or modifying a packet data protocol context.” 

39. The applicable standards covered by the claims of the ’456 Patent, including but 

not limited to 3GPP TS 24.301 V11.5.0 (2012-12), describe the wireless terminal being configured 

to transmit a configuration signal to a network node in a mobile system for activating or modifying 

a packet data protocol context: 

3.2 Abbreviations 

. . . . 

EPS Evolved Packet System 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 13 of 66
Page 14 of 66 

6.5.3 UE requested bearer resource allocation procedure 

6.5.3.1 General 

The purpose of the UE requested bearer resource allocation procedure is for a UE 

to request an allocation of bearer resources for a traffic flow aggregate. The UE 

requests a specific QoS demand (QCI) and optionally sends a GBR requirement for 

a new traffic flow aggregate. If accepted by the network, this procedure invokes a 

dedicated EPS bearer context activation procedure (see subclause 6.4.2) or an EPS 

bearer context modification procedure (see subclause 6.4.3). 

. . . . 

6.5.3.2 UE requested bearer resource allocation procedure initiation 

In order to request the allocation of bearer resources for one traffic flow aggregate, 

the UE shall send a BEARER RESOURCE ALLOCATION REQUEST message 

to the MME, start timer T3480 and enter the state PROCEDURE TRANSACTION 

PENDING (see example in figure 6.5.3.2.1). 

The UE shall include the EPS bearer identity of the default EPS bearer associated 

with the requested bearer resource in the Linked EPS bearer identity IE. The UE 

shall set the TFT operation code in the Traffic flow aggregate IE to "Create new 

TFT". In the Required traffic flow QoS IE, the UE shall indicate a QCI and, if the 

UE also includes a GBR, the additional GBR required for the traffic flow aggregate. 

Figure 6.5.3.2.1: UE requested bearer resource allocation procedure 

(3GPP TS 24.301 V11.5.0 (2012-12), at 24, 189–90). 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 14 of 66
Page 15 of 66 

40. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 24.008 V11.8.0 (2013-09), describe the wireless terminal 

being configured to transmit a configuration signal to a network node in a mobile system for 

activating or modifying a packet data protocol context: 

2.1.2 Vocabulary 

. . . . 

- A default PDP context is a PDP context activated by the PDP context 

activation procedure that establishes a PDN connection. The default PDP 

context remains active during the lifetime of the PDN connection. 

. . . . 

6.1.3.2 Secondary PDP Context Activation Procedure 

The purpose of this procedure is to establish an additional PDP context between the 

MS and the network for a specific Traffic Flow Template (TFT) and QoS profile 

on a specific NSAPI, when one or more PDP contexts has/have already been 

established for the particular PDP address and APN. The MS shall include a request 

for a TFT if a PDP context without a TFT is presently active for the particular PDP 

address, or the BCM is 'MS/NW'. Depending on the selected Bearer Control Mode 

being 'MS only' or 'MS/NW', the secondary PDP context activation procedure may 

either be initiated by the MS or by either the MS or the network, respectively. If 

there is a PDN connection for emergency bearer services established, the MS shall 

not initiate a secondary PDP context activation procedure for this connection unless 

triggered by the network. 

(3GPP TS 24.008 V11.8.0 (2013-09), at 38, 40, 287). 

41. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 23.060 V11.8.0 (2013-12), describe the wireless terminal 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 15 of 66
Page 16 of 66 

being configured to transmit a configuration signal to a network node in a mobile system for 

activating or modifying a packet data protocol context: 

9.2.1A Principles for mapping between PDP Contexts and EPS Bearers 

The following text describes the general principles used by an SGSN using S4 when 

mapping between PDP Contexts and EPS Bearers. 

The MS is using PDP Context Activation, Modification and Deactivation functions, 

and PDP Contexts are therefore used between MS and SGSN. An SGSN using 

Gn/Gp only will use these procedures towards GGSNs as well. An SGSN using S4 

will for a specific PDP Context towards an MS map these procedures into 

equivalent procedures using EPS Bearer towards S GW and P GW. EPS Bearer 

procedures will not be used between MS and SGSN. 

The following principles are to be used: 

- 1:1 mapping between one PDP context and one EPS Bearer; 

(3GPP TS 23.060 V11.8.0 (2013-12), at 206.) 

42. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 36.300 V11.4.0 (2012-12), describe the wireless terminal 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 16 of 66
Page 17 of 66 

being configured to transmit a configuration signal to a network node in a mobile system for 

activating or modifying a packet data protocol context: 

13.1 Bearer service architecture 

The EPS bearer service layered architecture is depicted in Figure 13.1-1 below, 

where: 

. . . . 

Figure 13.1-1: EPS Bearer Service Architecture

(3GPP TS 36.300 V11.4.0 (2012-12), at 98–99.) 

43. By way of example, Claim 7 of the ’456 Patent requires “a packet data protocol 

context for linking a packet radio network to an external system.” 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 17 of 66
Page 18 of 66 

44. The applicable standards covered by the claims of the ’456 Patent, including but 

not limited to 3GPP TS 24.301 V11.5.0 (2012-12), describe a packet data protocol context for 

linking a packet radio network to an external system: 

6 Elementary procedures for EPS session management 

6.1 Overview 

6.1.1 General 

This clause describes the procedures used for EPS session management (ESM) at 

the radio interface (reference point "LTE-Uu"). 

. . . .

The ESM comprises procedures for: 

- the activation, deactivation and modification of EPS bearer contexts; and 

- the request for resources (IP connectivity to a PDN or dedicated bearer 

resources) by the UE. 

Each EPS bearer context represents an EPS bearer between the UE and a PDN. EPS 

bearer contexts can remain activated even if the radio and S1 bearers constituting 

the corresponding EPS bearers between UE and MME are temporarily released. 

An EPS bearer context can be either a default bearer context or a dedicated bearer 

context. 

A default EPS bearer context is activated when the UE requests a connection to a 

PDN. 

. . . . 

A dedicated EPS bearer context is always linked to a default EPS bearer context 

and represents additional EPS bearer resources between the UE and the PDN. The 

network can initiate the activation of dedicated EPS bearer contexts together with 

the activation of the default EPS bearer context or at any time later, as long as the 

default EPS bearer context remains activated. 

(3GPP TS 24.301 V11.5.0 (2012-12), at 157). 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 18 of 66
Page 19 of 66 

45. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 36.300 V11.4.0 (2012-12), describe a packet data protocol 

context for linking a packet radio network to an external system: 

13.1 Bearer service architecture 

The EPS bearer service layered architecture is depicted in Figure 13.1-1 below, 

where: 

. . . . 

Figure 13.1-1: EPS Bearer Service Architecture

(3GPP TS 36.300 V11.4.0 (2012-12), at 98–99.) 

46. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 23.401 V11.4.0 (2012-12), describe a packet data protocol 

context for linking a packet radio network to an external system: 

3.2 Abbreviations 

. . . . 

EPS Evolved Packet System 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 19 of 66
Page 20 of 66 

4.2 Architecture reference model 

4.2.1 Non-roaming architecture 

SGi

S12

S3

S1-MME

PCRF

Gx

S6a

HSS

Operator's IP 

Services

(e.g. IMS, PSS etc.)

Rx 

S10

UE

SGSN

LTE-Uu

E-UTRAN

MME

S11

Serving S5

Gateway

PDN

Gateway

S1-U

S4 

UTRAN

GERAN

Figure 4.2.1-1: Non-roaming architecture for 3GPP accesses 

. . . . 

4.7 Overall QoS concept 

4.7.1 PDN connectivity service 

The Evolved Packet System provides IP connectivity between a UE and a PLMN 

external packet data network. This is referred to as PDN Connectivity Service. 

The PDN Connectivity Service supports the transport of traffic flow aggregate(s), 

consisting of one or more Service Data Flows (SDFs). 

(3GPP TS 23.401 V11.4.0 (2012-12), at 14, 16, 61.) 

47. By way of example, Claim 7 of the ’456 Patent requires the limitation “wherein the 

wireless terminal is configured to check if a filter used for mapping data flows at the network node 

is determined by a separate network element.” 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 20 of 66
Page 21 of 66 

48. The applicable standards covered by the claims of the ’456 Patent, including but 

not limited to 3GPP TS 24.008 V11.8.0 (2013-09), describe that the wireless terminal is configured 

to check if a filter used for mapping data flows at the network node is determined by a separate 

network element: 

10.5.6.12 Traffic Flow Template 

The purpose of the traffic flow template information element is to specify the TFT 

parameters and operations for a PDP context. In addition, this information element 

may be used to transfer extra parameters to the network (e.g. the Authorization 

Token; see 3GPP TS 24.229 [95]). The TFT may contain packet filters for the 

downlink direction, the uplink direction or packet filters that apply for both 

directions. The packet filters determine the traffic mapping to PDP contexts. The 

downlink packet filters shall be applied by the network and the uplink packet filters 

shall be applied by the MS. A packet filter that applies for both directions shall be 

applied by the network as a downlink packet filter and by the MS as an uplink filter. 

(3GPP TS 24.008 V11.8.0 (2013-09), at 576.) 

49. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 36.300 V11.4.0 (2012-12), describe that the wireless terminal 

is configured to check if a filter used for mapping data flows at the network node is determined by 

a separate network element: 

4.1 Functional Split 

. . . . 

The PDN Gateway (P-GW) hosts the following functions (see 3GPP TS 23.401 

[17]): 

- Per-user based packet filtering (by e.g. deep packet inspection); 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 21 of 66
Page 22 of 66 

Figure 4.1-1: Functional Split between E-UTRAN and EPC 

. . . . 

13.1 Bearer service architecture 

The EPS bearer service layered architecture is depicted in Figure 13.1-1 below, 

where: 

- An UL TFT in the UE binds an SDF to an EPS bearer in the uplink direction. 

Multiple SDFs can be multiplexed onto the same EPS bearer by including 

multiple uplink packet filters in the UL TFT. 

- A DL TFT in the PDN GW binds an SDF to an EPS bearer in the downlink 

direction. Multiple SDFs can be multiplexed onto the same EPS bearer by 

including multiple downlink packet filters in the DL TFT. 

. . . . 

- A PDN GW stores a mapping between a downlink packet filter and an 

S5/S8a bearer to create the binding between an SDF and an S5/S8a bearer 

in the downlink. 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 22 of 66
Page 23 of 66 

Figure 13.1-1: EPS Bearer Service Architecture 

(3GPP TS 36.300 V11.4.0 (2012-12), at 20–22, 98–99.) 

50. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 23.401 V11.4.0 (2012-12), describe that the wireless terminal 

is configured to check if a filter used for mapping data flows at the network node is determined by 

a separate network element: 

4.2 Architecture reference model 

4.2.1 Non-roaming architecture 

SGi

S12

S3

S1-MME

PCRF

Gx

S6a

HSS

Operator's IP 

Services

(e.g. IMS, PSS etc.)

Rx 

S10

UE

SGSN

LTE-Uu

E-UTRAN

MME

S11

Serving S5

Gateway

PDN

Gateway

S1-U

S4 

UTRAN

GERAN

Figure 4.2.1-1: Non-roaming architecture for 3GPP accesses 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 23 of 66
Page 24 of 66 

4.4 Network elements 

. . . . 

4.4.3.3 PDN GW 

The PDN GW is the gateway which terminates the SGi interface towards the PDN. 

. . . . 

Additionally the PDN GW includes the following functions for the GTP-based 

S5/S8: 

- UL and DL bearer binding as defined in TS 23.203 [6]; 

- UL bearer binding verification as defined in TS 23.203 [6]; 

. . . . 

4.4.7 PCRF 

4.4.7.1 General 

PCRF is the policy and charging control element. PCRF functions are described in 

more detail in TS 23.203 [6]. 

. . . . 

4.7.6 Bearer Control Mode in EPC 

The Bearer Control Mode (BCM) for E-UTRAN access is always UE/NW. Hence, 

explicit signalling between the UE and the network to determine BCM for EUTRAN access does not occur. 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 24 of 66
Page 25 of 66 

5.4.5 UE requested bearer resource modification 

. . . . 

1. . . . . 

The TAD indicates one requested operation (add, modify, or delete packet 

filters). If traffic flows are added, the TAD includes the packet filter(s) 

(consisting of the packet filter information including packet filter precedence, 

but without a packet filter identifier) to be added. The UE also sends the QCI 

requested and GBR, if applicable, for the added traffic flows. If the UE wants 

to link the new packet filter(s) to an existing packet filter to enable the usage of 

existing bearer resources for the new packet filter(s), the UE shall provide an 

existing packet filter identifier together with the new packet filter(s). 

. . . . 

5. . . . . 

The PDN GW inserts, modifies or removes packet filter(s) corresponding to the 

TAD into the TFT for the EPS bearer. When a new packet filter is inserted into 

a TFT, the PDN GW assigns a new packet filter identifier which is unique 

within the TFT. The PDN GW maintains the relation between the SDF filter 

identifier in the PCC rule received from the PCRF and the packet filter identifier 

of the TFT of this EPS bearer. If all of the packet filter(s) for a dedicated EPS 

bearer have been removed from the TFT, the PDN GW performs the PDN GW 

Initiated Bearer Deactivation Procedure. 

(3GPP TS 23.401 V11.4.0 (2012-12), at 16, 52, 54–55, 67, 154–56.) 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 25 of 66
Page 26 of 66 

51. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 23.203 V11.11.0 (2013-09), describe that the wireless 

terminal is configured to check if a filter used for mapping data flows at the network node is 

determined by a separate network element: 

6.2 Functional entities 

6.2.1 Policy Control and Charging Rules Function (PCRF) 

6.2.1.0 General 

The PCRF encompasses policy control decision and flow based charging control 

functionalities. 

The PCRF provides network control regarding the service data flow detection, 

gating, QoS and flow based charging (except credit management) towards the 

PCEF. 

. . . . 

The PCRF shall decide how certain service data flow/detected application traffic 

shall be treated in the PCEF and in the TDF, if applicable, and ensure that the PCEF 

user plane traffic mapping and treatment is in accordance with the user's 

subscription profile. 

. . . . 

6.2.2 Policy and Charging Enforcement Function (PCEF) 

6.2.2.1 General 

The PCEF encompasses service data flow detection, policy enforcement and flow 

based charging functionalities. 

This functional entity is located at the Gateway (e.g. GGSN in the GPRS case, and 

PDG in the WLAN case). It provides service data flow detection, user plane traffic 

handling, triggering control plane session management (where the IP CAN 

permits), QoS handling, and service data flow measurement as well as online and 

offline charging interactions. 

. . . . 

The PCEF is enforcing the Policy Control as indicated by the PCRF in two different 

ways: 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 26 of 66
Page 27 of 66 

- Gate enforcement. The PCEF shall allow a service data flow, which is 

subject to policy control, to pass through the PCEF if and only if the 

corresponding gate is open; 

- QoS enforcement: 

. . . . 

6.2.2.2 Service data flow detection 

. . . . 

Service data flow filters identifying the service data flow may: 

- be a pattern for matching the IP 5 tuple (source IP address or IPv6 network 

prefix, destination IP address or IPv6 network prefix, source port number, 

destination port number, protocol ID of the protocol above IP). In the 

pattern: 

. . . . 

6.2.3 Application Function (AF) 

The Application Function (AF) is an element offering applications that require 

dynamic policy and/or charging control over the IP CAN user plane behaviour. The 

AF shall communicate with the PCRF to transfer dynamic session information, 

required for PCRF decisions as well as to receive IP CAN specific information and 

notifications about IP CAN bearer level events. One example of an AF is the P 

CSCF of the IM CN subsystem. 

. . . . 

6.7 IP flow mobility Routing rule 

6.7.1 General 

. . . . 

The Packet filter may comprise any number of packet filters, containing 

information for matching service data flows. The format of the packet filters is the 

same as the service data flow filter described in clause 6.2.2.2. A default packet 

filter can be specified by using wild card filter. 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 27 of 66
Page 28 of 66 

A.1 GPRS 

A.1.0 General 

The GPRS IP CAN employs, for an IP CAN session, the concept of PDP contexts 

in order to provide an information transmission path of defined capacity (QoS). For 

GPRS, the IP CAN bearer is the PDP context. 

GPRS

IP-CAN

GGSN 

PCEF

PCRF

Gx

UE

Figure A.1: The GPRS IP CAN 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 28 of 66
Page 29 of 66 

A.4 3GPP Accesses (GERAN/UTRAN/E-UTRAN) - GTP-based EPC 

A.4.0 General 

For 3GPP Access (GTP-based), architecture details are described in TS 23.401 [17] 

and in TS 23.060 [12]. 

3GPP IP CAN

GTP-based PDN GW 

PCEF

PCRF

Gx

UE

Figure A.1: The 3GPP EPS IP CAN (GTP-based) 

(3GPP TS 23.203 V11.11.0 (2013-09), at 44, 54–55, 57–58, 62, 77, 112, 122.) 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 29 of 66
Page 30 of 66 

52. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 23.207 V11.0.0 (2012-09), describe that the wireless terminal 

is configured to check if a filter used for mapping data flows at the network node is determined by 

a separate network element: 

Annex C (informative): 

Sample Mapping of SDP Descriptions Into QoS Authorization 

. . . . 

The session initiator includes an SDP in the SIP INVITE message that lists every 

codec that the originator is willing to support for this session. When the message 

arrives at the destination endpoint, it responds with the subset that it is also willing 

to support for the session by selectively accept or decline those media types in the 

original list. When multiple media codecs are listed, the caller and called party's 

media fields must be aligned—that is, there must be the same number, and they 

must be listed in the same order. QoS authorization is performed for this common 

subset. The P-CSCF(PDF) shall use the SDP contained in the SIP signalling to 

calculate the proper authorization. The authorization shall include limits on IP 

resources, and restrictions on IP packet flows, and may include restrictions on IP 

destinations. These restrictions are expressed as a data rate and QoS class for the 

combined set of IP flows, and a set of filter specs. 

The QoS authorization for a session shall include an Authorization-Token, which 

shall be assigned by the P-CSCF(PDF). The Authorization-Token shall contain 

information that identifies the P-CSCF(PDF) that generated the token. Each 

authorized session may include several flow authorizations. Each flow 

authorization may include an authorization for one or more flows. The 

authorization shall contain the following information: 

- Filter Specs (IP flow 5-tuples that identify the set of flows) 

- Data rate and QoS class that describes the authorized resource for the set of 

flows 

- The IP flow 5-tuples includes Source Address, Source Port, Destination 

Address, Destination Port and Protocol ID. Note that some fields may be 

wildcarded. 

(3GPP TS 23.207 V11.0.0 (2012-09), at 29.) 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 30 of 66
Page 31 of 66 

53. By way of example, Claim 7 of the ’456 Patent requires the limitation “wherein the 

wireless terminal is configured to generate said configuration signal without filter information.” 

54. The applicable standards covered by the claims of the ’456 Patent, including but 

not limited to 3GPP TS 24.301 V11.5.0 (2012-12), describe that the wireless terminal is configured 

to generate said configuration signal without filter information: 

8.3.8 Bearer resource allocation request 

8.3.8.1 Message definition 

This message is sent by the UE to the network to request the allocation of a 

dedicated bearer resource. See table 8.3.8.1. 

Message type: BEARER RESOURCE ALLOCATION REQUEST 

Significance: dual 

Direction: UE to network 

Table 8.3.8.1: BEARER RESOURCE ALLOCATION REQUEST message 

content 

. . . . 

9.9.4 EPS Session Management (ESM) information elements 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 31 of 66
Page 32 of 66 

9.9.4.15 Traffic flow aggregate description 

The purpose of the Traffic flow aggregate description information element is to 

specify the aggregate of one of more packet filters and their related parameters and 

operations. The traffic flow aggregate description may contain the aggregate of 

packet filters for the downlink direction, the uplink direction or packet filters that 

apply for both directions. The packet filters determine the traffic mapping to EPS 

bearer contexts. The downlink packet filters shall be applied by the network, and 

the uplink packet filters shall be applied by the UE. A packet filter that applies for 

both directions shall be applied by the network as a downlink packet filter and by 

the UE as an uplink packet filter. 

When the traffic flow aggregate description is used in the UE requested bearer 

resource allocation procedure or the UE requested bearer resource modification 

procedure, it is associated to a particular procedure identified by a procedure 

transaction identity (PTI). Therefore, the UE shall release the traffic flow aggregate 

description when the UE requested bearer resource allocation procedure or the UE 

requested bearer resource modification procedure is completed. The UE shall not 

include the packet filters of a particular traffic flow aggregate description in any 

other traffic flow aggregate description when multiple UE requested bearer 

resource allocation procedures and/or UE requested bearer resource modification 

procedures are ongoing in parallel. 

The Traffic flow aggregate description information element is encoded using the 

same format as the Traffic flow template (TFT) information element (see subclause 

10.5.6.12 in 3GPP TS 24.008 [13]). When sending this IE in the BEARER 

RESOURCE ALLOCATION REQUEST message or the BEARER RESOURCE 

MODIFICATION REQUEST message, the UE shall set the packet filter identifier 

values to 0 if the packet filters are newly created; otherwise, the UE shall set the 

packet filter identifier values from those of already assigned packet filter identifiers 

of the existing EPS bearer, so that they are unique across all packet filters for the 

EPS bearer context indicated by the EPS bearer identity IE. 

(3GPP TS 24.301 V11.5.0 (2012-12), at 246, 298, 310–11). 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 32 of 66
Page 33 of 66 

55. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 23.401 V11.4.0 (2012-12), describe that the wireless terminal 

is configured to generate said configuration signal without filter information: 

3.2 Abbreviations 

. . . . 

TAD Traffic Aggregate Description 

. . . . 

5.4.5 UE requested bearer resource modification 

. . . . 

MME Serving GW PDN GW PCRF

1. Request Bearer Resource Modification

2. Bearer Resource Command

UE eNodeB

3. Bearer Resource Command

(A) 4. PCEF Initiated IP-CAN 

Session Modification, begin 

6. PCEF Initiated IP-CAN 

Session Modification, end 

5. Dedicated bearer activation as per Figure 5.4.1-1, from step 2 to 11; or 

Bearer modification procedure as per Figure 5.4.2.1-1, from step 2 to 11, or as per 

Figure 5.4.3-1, from step 2 to 9; or 

Dedicated bearer deactivation procedure as per Figure 5.4.4.1-1, from step 2 to 9.

Figure 5.4.5-1: UE requested bearer resource modification 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 33 of 66
Page 34 of 66 

1. . . . . 

The TAD indicates one requested operation (add, modify, or delete packet 

filters). If traffic flows are added, the TAD includes the packet filter(s) 

(consisting of the packet filter information including packet filter precedence, 

but without a packet filter identifier) to be added. The UE also sends the QCI 

requested and GBR, if applicable, for the added traffic flows. If the UE wants 

to link the new packet filter(s) to an existing packet filter to enable the usage of 

existing bearer resources for the new packet filter(s), the UE shall provide an 

existing packet filter identifier together with the new packet filter(s). 

. . . . 

5. . . . . 

The PDN GW inserts, modifies or removes packet filter(s) corresponding to the 

TAD into the TFT for the EPS bearer. When a new packet filter is inserted into 

a TFT, the PDN GW assigns a new packet filter identifier which is unique 

within the TFT. The PDN GW maintains the relation between the SDF filter 

identifier in the PCC rule received from the PCRF and the packet filter identifier 

of the TFT of this EPS bearer. If all of the packet filter(s) for a dedicated EPS 

bearer have been removed from the TFT, the PDN GW performs the PDN GW 

Initiated Bearer Deactivation Procedure. 

(3GPP TS 23.401 V11.4.0 (2012-12), at 14–15, 154–56.) 

56. By way of example, Claim 7 of the ’456 Patent requires that the wireless terminal 

be configured to generate said configuration signal without filter information “in response to the 

filter associated to a packet data protocol context of the packet radio network and used for mapping 

the data flows being determined in the separate network element and being sent to the network 

node by the separate network element.” 

57. The applicable standards covered by the claims of the ’456 Patent, including but 

not limited to 3GPP TS 23.401 V11.4.0 (2012-12), describe that the wireless terminal is configured 

to generate said configuration signal without filter information in response to the filter associated 

to a packet data protocol context of the packet radio network and used for mapping the data flows 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 34 of 66
Page 35 of 66 

being determined in the separate network element and being sent to the network node by the 

separate network element: 

5.4.1 Dedicated bearer activation 

The dedicated bearer activation procedure for a GTP based S5/S8 is depicted in 

figure 5.4.1-1. 

3. Create Bearer Request

MME Serving GW PDN GW PCRF

4. Bearer Setup Request/ 

Session Management Request 

5. RRC Connection Reconfiguration

 2. Create Bearer Request

 6. RRC Connection Reconfiguration Complete

7. Bearer Setup Response

10. Create Bearer Response

UE eNodeB

(A)

(B)

1. IP-CAN Session 

Modification 

12. IP-CAN Session 

Modification 

11. Create Bearer Response

8. Direct Transfer

9. Session Management Response

Figure 5.4.1-1: Dedicated Bearer Activation Procedure 

. . . . 

1. If dynamic PCC is deployed, the PCRF sends a PCC decision provision (QoS 

policy) message to the PDN GW. This corresponds to the initial steps of the 

PCRF-Initiated IP CAN Session Modification procedure or to the PCRF 

response in the PCEF initiated IP-CAN Session Modification procedure as 

defined in TS 23.203 [6], up to the point that the PDN GW requests IP CAN 

Bearer Signalling. The PCC decision provision message may indicate that User 

Location Information and/or UE Time Zone Information is to be provided to 

the PCRF as defined in TS 23.203 [6]. If dynamic PCC is not deployed, the 

PDN GW may apply local QoS policy. 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 35 of 66
Page 36 of 66 

2. The PDN GW uses this QoS policy to assign the EPS Bearer QoS, i.e., it assigns 

the values to the bearer level QoS parameters QCI, ARP, GBR and MBR; see 

clause 4.7.3. The PGW generates a Charging Id for the dedicated bearer. The 

PDN GW sends a Create Bearer Request message (IMSI, PTI, EPS Bearer QoS, 

TFT, S5/S8 TEID, Charging Id, LBI, Protocol Configuration Options) to the 

Serving GW, the Linked EPS Bearer Identity (LBI) is the EPS Bearer Identity 

of the default bearer. 

. . . . 

5.4.5 UE requested bearer resource modification 

. . . . 

MME Serving GW PDN GW PCRF

1. Request Bearer Resource Modification

2. Bearer Resource Command

UE eNodeB

3. Bearer Resource Command

(A) 4. PCEF Initiated IP-CAN 

Session Modification, begin 

6. PCEF Initiated IP-CAN 

Session Modification, end 

5. Dedicated bearer activation as per Figure 5.4.1-1, from step 2 to 11; or 

Bearer modification procedure as per Figure 5.4.2.1-1, from step 2 to 11, or as per 

Figure 5.4.3-1, from step 2 to 9; or 

Dedicated bearer deactivation procedure as per Figure 5.4.4.1-1, from step 2 to 9.

Figure 5.4.5-1: UE requested bearer resource modification 

. . . . 

4. The PDN GW may either apply a locally configured QoS policy, or it may 

interact with the PCRF to trigger the appropriate PCC decision, which may take 

into account subscription information. This corresponds to the beginning of a 

PCEF-initiated IP CAN Session Modification procedure as defined in TS 

23.203 [6], up to the point that the PDN GW requests IP CAN Bearer 

Signalling. When interacting with PCRF, the PDN GW provides to the PCRF 

the content of the TAD and, if applicable, the GBR change (increase or 

decrease) associated with the packet filter information contained in the TAD. 

The GBR change is either calculated from the current Bearer QoS and the 

requested Bearer QoS from the UE, or set to the requested GBR if the TAD 

indicates an add operation and no EPS Bearer Identity was received. If the TAD 

indicates an add operation, the requested QCI is also provided to the PCRF 

unless an existing packet filter identifier is provided together with the new 

packet filter. 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 36 of 66
Page 37 of 66 

6. If the PDN GW interacted with the PCRF in step 4, the PDN GW indicates to 

the PCRF whether the PCC decision could be enforced or not. This corresponds 

to the completion of the PCEF-initiated IP CAN session modification procedure 

as defined in TS 23.203 [6] . . . . 

(3GPP TS 23.401 V11.4.0 (2012-12), at 142–43, 154–56.) 

58. In addition, the applicable standards covered by the claims of the ’456 Patent, 

including but not limited to 3GPP TS 23.203 V11.11.0 (2013-09), describe that the wireless 

terminal is configured to generate said configuration signal without filter information in response 

to the filter associated to a packet data protocol context of the packet radio network and used for 

mapping the data flows being determined in the separate network element and being sent to the 

network node by the separate network element: 

6.2 Functional entities 

6.2.1 Policy Control and Charging Rules Function (PCRF) 

6.2.1.0 General 

The PCRF encompasses policy control decision and flow based charging control 

functionalities. 

The PCRF provides network control regarding the service data flow detection, 

gating, QoS and flow based charging (except credit management) towards the 

PCEF. 

. . . . 

The PCRF shall decide how certain service data flow/detected application traffic 

shall be treated in the PCEF and in the TDF, if applicable, and ensure that the PCEF 

user plane traffic mapping and treatment is in accordance with the user's 

subscription profile. 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 37 of 66
Page 38 of 66 

A.4 3GPP Accesses (GERAN/UTRAN/E-UTRAN) - GTP-based EPC 

A.4.0 General 

For 3GPP Access (GTP-based), architecture details are described in TS 23.401 [17] 

and in TS 23.060 [12]. 

3GPP IP CAN

GTP-based PDN GW 

PCEF

PCRF

Gx

UE

Figure A.1: The 3GPP EPS IP CAN (GTP-based) 

. . . . 

A.4.3.1.3 Binding mechanism 

. . . . 

For the 3GPP Access (GTP-based) the Bearer Binding is performed by the PCEF. 

For GERAN/UTRAN in UE-only mode the Bearer Binding mechanism is restricted 

by the UE provided binding between a SDF and a bearer for UE initiated resource 

requests. 

The bearer binding mechanism associates the PCC Rule with the EPS bearer to 

carry the service data flow. The association shall: 

- cause the downlink part of the service data flow to be directed to the EPS 

bearer in the association; and 

- assume that the UE directs the uplink part of the service data flow to the 

EPS bearer in the association. 

(3GPP TS 23.203 V11.11.0 (2013-09), at 44, 122, 124–25.) 

59. By way of example, Claim 7 of the ’456 Patent requires the limitation “wherein the 

wireless terminal is configured to transmit, in a packet data protocol context activation request, a 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 38 of 66
Page 39 of 66 

traffic flow template information element in response to the need to create a packet data protocol 

context.” 

60. The applicable standards covered by the claims of the ’456 Patent, including but 

not limited to 3GPP TS 24.301 V11.5.0 (2012-12), describe that the wireless terminal is configured 

to transmit, in a packet data protocol context activation request, a traffic flow template information 

element in response to the need to create a packet data protocol context: 

3.2 Abbreviations 

. . . . 

EPS Evolved Packet System 

. . . . 

6.5.3 UE requested bearer resource allocation procedure 

6.5.3.1 General 

The purpose of the UE requested bearer resource allocation procedure is for a UE 

to request an allocation of bearer resources for a traffic flow aggregate. The UE 

requests a specific QoS demand (QCI) and optionally sends a GBR requirement for 

a new traffic flow aggregate. If accepted by the network, this procedure invokes a 

dedicated EPS bearer context activation procedure (see subclause 6.4.2) or an EPS 

bearer context modification procedure (see subclause 6.4.3). 

. . . . 

6.5.3.2 UE requested bearer resource allocation procedure initiation 

In order to request the allocation of bearer resources for one traffic flow aggregate, 

the UE shall send a BEARER RESOURCE ALLOCATION REQUEST message 

to the MME, start timer T3480 and enter the state PROCEDURE TRANSACTION 

PENDING (see example in figure 6.5.3.2.1). 

The UE shall include the EPS bearer identity of the default EPS bearer associated 

with the requested bearer resource in the Linked EPS bearer identity IE. The UE 

shall set the TFT operation code in the Traffic flow aggregate IE to "Create new 

TFT". In the Required traffic flow QoS IE, the UE shall indicate a QCI and, if the 

UE also includes a GBR, the additional GBR required for the traffic flow aggregate. 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 39 of 66
Page 40 of 66 

UE Network

ACTIVATE DEDICATED EPS BEARER CONTEXT 

Stop T3480 REQUEST

OR

BEARER RESOURCE ALLOCATION REQUEST Start T3480

MODIFY EPS BEARER CONTEXT REQUEST Stop T3480

OR

BEARER RESOURCE ALLOCATION REJECT Stop T3480

Figure 6.5.3.2.1: UE requested bearer resource allocation procedure 

. . . . 

8.3.8 Bearer resource allocation request 

8.3.8.1 Message definition 

This message is sent by the UE to the network to request the allocation of a 

dedicated bearer resource. See table 8.3.8.1. 

Message type: BEARER RESOURCE ALLOCATION REQUEST 

Significance: dual 

Direction: UE to network 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 40 of 66
Page 41 of 66 

Table 8.3.8.1: BEARER RESOURCE ALLOCATION REQUEST message 

content 

. . . . 

9.9.4 EPS Session Management (ESM) information elements 

. . . . 

9.9.4.15 Traffic flow aggregate description 

The purpose of the Traffic flow aggregate description information element is to 

specify the aggregate of one of more packet filters and their related parameters and 

operations. The traffic flow aggregate description may contain the aggregate of 

packet filters for the downlink direction, the uplink direction or packet filters that 

apply for both directions. The packet filters determine the traffic mapping to EPS 

bearer contexts. The downlink packet filters shall be applied by the network, and 

the uplink packet filters shall be applied by the UE. A packet filter that applies for 

both directions shall be applied by the network as a downlink packet filter and by 

the UE as an uplink packet filter. 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 41 of 66
Page 42 of 66 

The Traffic flow aggregate description information element is encoded using the 

same format as the Traffic flow template (TFT) information element (see subclause 

10.5.6.12 in 3GPP TS 24.008 [13]). When sending this IE in the BEARER 

RESOURCE ALLOCATION REQUEST message or the BEARER RESOURCE 

MODIFICATION REQUEST message, the UE shall set the packet filter identifier 

values to 0 if the packet filters are newly created; otherwise, the UE shall set the 

packet filter identifier values from those of already assigned packet filter identifiers 

of the existing EPS bearer, so that they are unique across all packet filters for the 

EPS bearer context indicated by the EPS bearer identity IE. 

(3GPP TS 24.301 V11.5.0 (2012-12), at 24, 189–90, 246, 298, 310–11). 

61. Upon information and belief, the Tesla Standard-Compliant Products comply or 

have complied with the applicable standards covered by the claims of the ’456 Patent, including 

without limitation 3G and/or 4G/LTE, and therefore infringe the ’456 Patent, including at least 

Claim 7. 

62. The Tesla Standard Compliant Products have complied with 3GPP TS 24.301 

V11.5.0 (2012-12). 

63. The Tesla Standard Compliant Products have complied with 3GPP TS 24.008 

V11.8.0 (2013-09). 

64. The Tesla Standard Compliant Products have complied with 3GPP TS 23.060 

V11.8.0 (2013-12). 

65. The Tesla Standard Compliant Products have complied with 3GPP TS 36.300 

V11.4.0 (2012-12). 

66. The Tesla Standard Compliant Products have complied with 3GPP TS 23.401 

V11.4.0 (2012-12). 

67. The Tesla Standard Compliant Products have complied with 3GPP TS 23.203 

V11.11.0 (2013-09). 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 42 of 66
Page 43 of 66 

68. The Tesla Standard Compliant Products have complied with 3GPP TS 23.207 

V11.0.0 (2012-09). 

69. Tesla is infringing claims of the ’456 Patent, including at least Claim 7, literally 

and/or pursuant to the doctrine of equivalents. 

70. In violation of 35 U.S.C. § 271(b), Tesla is and has been infringing one or more of 

the ’456 Patent’s claims, including at least Claim 7, indirectly by inducing the infringement of the 

’456 Patent’s claims by third parties, including without limitation manufacturers, resellers, and/or 

users of Tesla’s Standard-Compliant Products, in this District, and elsewhere in the United States. 

Direct infringement is the result of activities performed by users of the Tesla Standard-Compliant 

Products in accordance with the claims of the ’456 Patent. 

71. Tesla’s affirmative acts of selling the Tesla’s Standard-Compliant Products, 

causing the Tesla Standard-Compliant Products to be manufactured and distributed, providing 

instructive materials and information concerning operation and use of the Tesla 

Standard-Compliant Products, and maintenance/service for such products, induced users of the 

Tesla Standard-Compliant Products to infringe the ’456 Patent’s claims by using the vehicles in 

their normal and customary way. By and through these acts, Tesla knowingly and specifically 

intends the users of the Tesla Standard-Compliant Products to infringe the ’456 Patent’s claims. 

Tesla (1) knows and knew of the ’456 Patent since at least prior to the filing of this lawsuit, 

(2) performs affirmative acts that constitute induced infringement, and (3) knows or should know 

that those acts would induce actual infringement of one or more of the ’456 Patent’s claims by 

users of the Tesla Standard-Compliant Products. 

72. In violation of 35 U.S.C. § 271(c), Tesla is and has been infringing one or more of 

the ’456 Patent’s claims, including at least Claim 7, indirectly by contributing to the infringement 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 43 of 66
Page 44 of 66 

of the ’456 Patent’s claims by third parties, including without limitation manufacturers, resellers, 

and/or users of the Tesla Standard-Compliant Products, in this District, and elsewhere in the United 

States. Direct infringement is the result of activities performed by manufacturers, resellers, and/or 

users in relation to the Tesla Standard-Compliant Products, including without limitation use of the 

Tesla Standard-Compliant Products. 

73. Upon information and belief, Tesla at least installs, configures, and sells Tesla 

Standard-Compliant Products with distinct and separate hardware and/or software components 

especially made or especially adapted to practice the invention claimed in the ’456 Patent. That 

hardware and/or software is a material part of the invention. That hardware and/or software is not 

a staple article or commodity of commerce because it is specifically designed to perform the 

claimed functionality. Any other use of that hardware and/or software would be unusual, farfetched, illusory, impractical, occasional, aberrant, or experimental. 

74. Therefore, upon information and belief, Tesla is making, using, offering to sell, 

and/or selling in the United States, and/or importing into the United States, without authority, a 

component of a patented machine, manufacture, combination or composition, or a material or an 

apparatus for use in practicing a patented process, constituting a material part of the invention, 

knowing the same to be especially made or especially adapted for use in infringement of a patent, 

and not a staple article or commodity of commerce suitable for substantial noninfringing use. 

75. As explained above, Tesla had actual notice of the ’456 Patent prior to this lawsuit 

being filed and had knowledge of the infringing nature of its activities. Nevertheless, Tesla 

continued its infringing activities. 

76. Instead of taking a FRAND license to Conversant’s patent portfolio, Tesla 

continues, in bad faith, to directly and indirectly infringe Conversant’s patents, including the 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 44 of 66
Page 45 of 66 

’456 Patent by making, using, offering for sale and selling infringing Tesla Standard-Compliant 

Products, and inducing and contributing to the infringement of others. 

77. Therefore, upon information and belief, Tesla’s infringement of the ’456 Patent’s 

claims, including at least Claim 7, has been and continues to be willful entitling Conversant to 

increased damages pursuant to 35 U.S.C. § 284 and to attorneys’ fees and costs incurred in 

prosecuting this action pursuant to 35 U.S.C. § 285. 

78. Tesla’s acts of infringement have caused damages to Conversant, and Conversant 

is entitled to recover from Tesla the damages sustained by Conversant as a result of Tesla’s 

wrongful acts in an amount to be determined at trial. 

COUNT 2—INFRINGEMENT OF THE ’697 PATENT 

79. Conversant incorporates by reference the allegations set forth in Paragraphs 1–78 

of this Complaint as though fully set forth herein. 

80. In violation of 35 U.S.C. § 271(a), Tesla is and has been directly infringing one or 

more of the ’697 Patent’s claims, including at least Claim 1, by making, using, offering to sell, 

and/or selling in the United States, and/or importing into the United States, without authority, 

products that support 3G and/or 4G/LTE connectivity, including without limitation the Tesla 

Standard-Compliant Products as defined above. Each of the Tesla Standard-Compliant Products 

comprises hardware and software components that together practice every element of one or more 

claims of the ’697 Patent, including at least Claim 1. These components include those hardware 

and software components that enable the set of wireless cellular communications functionalities 

known as 3G and/or 4G/LTE and implement 3G and/or 4G/LTE in compliance with the 

requirements of the technical standards applicable to mobile communications, including the 

technical standards promulgated by 3GPP and various subsequent releases and versions thereof. 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 45 of 66
Page 46 of 66 

These components enable the Tesla Standard-Compliant Products to perform 3G and/or 4G/LTE 

communications functionality. 

81. It is necessary to practice one or more of the claims of the ’697 Patent to comply 

with the requirements of certain standards applicable to mobile communications. For example, it 

is necessary to practice at least Claim 1 from the ’697 Patent to comply with certain 3G and/or 

4G/LTE standards. 

82. The Tesla Standard-Compliant Products comply with the applicable standards 

covered by the claims of the ’697 Patent. 

83. The Tesla Standard-Compliant Products are capable of performing, and when used 

do in fact perform, the method of Claim 1 of the ’697 Patent. 

84. The applicable standards covered by the claims of the ’697 Patent describe, at least, 

performing the method of Claim 1 of the ’697 Patent. 

85. By way of example, Claim 1 of the ’697 Patent requires a method including the 

step of “transmitting , by a user equipment to a network access node , in a time and frequency 

resource allocated for preamble transmission, and in one of a plurality of uplink component carriers 

selected by the user equipment , a random access request.” 

86. The applicable standards covered by the claims of the ’697 Patent, including but 

not limited to 3GPP TS 36.300 V11.4.0 (2012-12), describe a method including the step of 

transmitting , by a user equipment to a network access node , in a time and frequency resource 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 46 of 66
Page 47 of 66 

allocated for preamble transmission, and in one of a plurality of uplink component carriers selected 

by the user equipment , a random access request: 

7 RRC

. . . . 

7.5 Carrier Aggregation 

When CA is configured, the UE only has one RRC connection with the network. 

At RRC connection establishment/re-establishment/handover, one serving cell 

provides the NAS mobility information (e.g. TAI), and at RRC connection reestablishment/handover, one serving cell provides the security input. This cell is 

referred to as the Primary Cell (PCell). In the downlink, the carrier corresponding 

to the PCell is the Downlink Primary Component Carrier (DL PCC) while in the 

uplink it is the Uplink Primary Component Carrier (UL PCC). 

Depending on UE capabilities, Secondary Cells (SCells) can be configured to form 

together with the PCell a set of serving cells. In the downlink, the carrier 

corresponding to an SCell is a Downlink Secondary Component Carrier (DL SCC) 

while in the uplink it is an Uplink Secondary Component Carrier (UL SCC). 

The configured set of serving cells for a UE therefore always consists of one PCell 

and one or more SCells: 

- For each SCell the usage of uplink resources by the UE in addition to the 

downlink ones is configurable (the number of DL SCCs configured is 

therefore always larger than or equal to the number of UL SCCs and no 

SCell can be configured for usage of uplink resources only); 

- From a UE viewpoint, each uplink resource only belongs to one serving 

cell; 

- The number of serving cells that can be configured depends on the 

aggregation capability of the UE (see subclause 5.5); 

- PCell can only be changed with handover procedure (i.e. with security key 

change and RACH procedure); 

- PCell is used for transmission of PUCCH; 

- Unlike SCells, PCell cannot be de-activated (see subclause 11.2); 

- Re-establishment is triggered when PCell experiences RLF, not when 

SCells experience RLF; 

- NAS information is taken from PCell. 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 47 of 66
Page 48 of 66 

. . . . 

10 Mobility 

. . . . 

10.1.5 Random Access Procedure 

The random access procedure is characterized by: 

- Common procedure for FDD and TDD; 

- One procedure irrespective of cell size and the number of serving cells when 

CA is configured; 

The random access procedure is performed for the following events related to the 

PCell: 

- Initial access from RRC_IDLE; 

- RRC Connection Re-establishment procedure; 

- Handover; 

- DL data arrival during RRC_CONNECTED requiring random access 

procedure; 

- E.g. when UL synchronisation status is “non-synchronised”; 

- UL data arrival during RRC_CONNECTED requiring random access 

procedure; 

- E.g. when UL synchronisation status is "non-synchronised" or there are no 

PUCCH resources for SR available. 

- For positioning purpose during RRC_CONNECTED requiring random 

access procedure; 

- E.g. when timing advance is needed for UE positioning; 

The random access procedure is also performed on a SCell to establish time 

alignment for the corresponding sTAG. 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 48 of 66
Page 49 of 66 

10.1.5.2 Non-contention based random access procedure 

The non-contention based random access procedure is outlined on Figure 10.1.5.2-

1 below: 

Figure 10.1.5.2-1: Non-contention based Random Access Procedure 

The three steps of the non-contention based random access procedures are: 

0) Random Access Preamble assignment via dedicated signalling in DL: 

- eNB assigns to UE a non-contention Random Access Preamble (a Random 

Access Preamble not within the set sent in broadcast signalling). 

- Signalled via: 

- HO command generated by target eNB and sent via source eNB for 

handover; 

- PDCCH in case of DL data arrival or positioning; 

- PDCCH for initial UL time alignment for a sTAG. 

1) Random Access Preamble on RACH in uplink: 

- UE transmits the assigned non-contention Random Access Preamble. 

2) Random Access Response on DL-SCH: 

- Semi-synchronous (within a flexible window of which the size is two or 

more TTIs) with message 1; 

- No HARQ; 

- Addressed to RA-RNTI on PDCCH; 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 49 of 66
Page 50 of 66 

- Conveys at least: 

- Timing Alignment information and initial UL grant for handover; 

- Timing Alignment information for DL data arrival; 

- RA-preamble identifier. 

- Intended for one or multiple UEs in one DL-SCH message. 

When performing non-contention based random access on the PCell while CA is 

configured, the Random Access Preamble assignment via PDCCH of step 0, step 1 

and 2 of the non-contention based random access procedure occur on the PCell. In 

order to establish timing advance for a sTAG, the eNB may initiate a noncontention based random access procedure with a PDCCH order (step 0) that is sent 

on a scheduling cell of activated SCell of the sTAG. Preamble transmission (step 

1) is on the indicated SCell and Random Access Response (step 2) takes place on 

PCell. 

(3GPP TS 36.300 V11.4.0 (2012-12), at 56, 58–59, 61, 72, 74–75.) 

87. In addition, the applicable standards covered by the claims of the ’697 Patent, 

including but not limited to 3GPP TS 36.211 V11.2.0 (2013-02), describe a method including the 

step of transmitting , by a user equipment to a network access node , in a time and frequency 

resource allocated for preamble transmission, and in one of a plurality of uplink component carriers 

selected by the user equipment , a random access request: 

5 Uplink 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 50 of 66
Page 51 of 66 

5.7 Physical random access channel 

5.7.1 Time and frequency structure 

The physical layer random access preamble, illustrated in Figure 5.7.1-1, consists 

of a cyclic prefix of length and a sequence part of length . The parameter values 

are listed in Table 5.7.1-1 and depend on the frame structure and the random access 

configuration. Higher layers control the preamble format. 

TCP TSEQ

Figure 5.7.1-1: Random access preamble format. 

Table 5.7.1-1: Random access preamble parameters. 

* Frame structure type 2 and special subframe configurations with UpPTS lengths 

4384 Ts and 5120 Ts only. 

The transmission of a random access preamble, if triggered by the MAC layer, is 

restricted to certain time and frequency resources. These resources are enumerated 

in increasing order of the subframe number within the radio frame and the physical 

resource blocks in the frequency domain such that index 0 correspond to the lowest 

numbered physical resource block and subframe within the radio frame. PRACH 

resources within the radio frame are indicated by a PRACH Resource Index, where 

the indexing is in the order of appearance in Table 5.7.1-2 and Table 5.7.1-4. 

(3GPP TS 36.211 V11.2.0 (2013-02), at 12, 41.) 

88. In addition, the applicable standards covered by the claims of the ’697 Patent, 

including but not limited to 3GPP TS 36.213 V11.1.0 (2012-12), describe a method including the 

step of transmitting , by a user equipment to a network access node , in a time and frequency 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 51 of 66
Page 52 of 66 

resource allocated for preamble transmission, and in one of a plurality of uplink component carriers 

selected by the user equipment , a random access request: 

6 Random access procedure 

. . . . 

6.1 Physical non-synchronized random access procedure 

From the physical layer perspective, the L1 random access procedure encompasses 

the transmission of random access preamble and random access response. The 

remaining messages are scheduled for transmission by the higher layer on the 

shared data channel and are not considered part of the L1 random access procedure. 

A random access channel occupies 6 resource blocks in a subframe or set of 

consecutive subframes reserved for random access preamble transmissions. The 

eNodeB is not prohibited from scheduling data in the resource blocks reserved for 

random access channel preamble transmission. 

(3GPP TS 36.213 V11.1.0 (2012-12), at 23–24.) 

89. In addition, the applicable standards covered by the claims of the ’697 Patent, 

including but not limited to 3GPP TS 36.321 V11.1.0 (2012-12), describe a method including the 

step of transmitting , by a user equipment to a network access node , in a time and frequency 

resource allocated for preamble transmission, and in one of a plurality of uplink component carriers 

selected by the user equipment , a random access request: 

3 Definitions and abbreviations 

3.1 Definitions 

. . . . 

RA-RNTI: The Random Access RNTI is used on the PDCCH when Random 

Access Response messages are transmitted. It unambiguously identifies which 

time-frequency resource was utilized by the UE to transmit the Random Access 

preamble. 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 52 of 66
Page 53 of 66 

5 MAC procedures 

5.1 Random Access procedure 

5.1.1 Random Access Procedure initialization 

The Random Access procedure described in this subclause is initiated by a PDCCH 

order or by the MAC sublayer itself. Random Access procedure on an SCell shall 

only be initiated by a PDCCH order. If a UE receives a PDCCH transmission 

consistent with a PDCCH order [5] masked with its C-RNTI, and for a specific 

Serving Cell, the UE shall initiate a Random Access procedure on this Serving Cell. 

For Random Access on the PCell a PDCCH order or RRC optionally indicate the 

ra-PreambleIndex and the ra-PRACH-MaskIndex; and for Random Access on an 

SCell, the PDCCH order indicates the ra-PreambleIndex with a value different from 

000000 and the ra-PRACH-MaskIndex. For the pTAG preamble transmission on 

PRACH and reception of a PDCCH order are only supported for PCell. 

. . . . 

5.1.3 Random Access Preamble transmission 

The random-access procedure shall be performed as follows: 

- set PREAMBLE_RECEIVED_TARGET_POWER to 

preambleInitialReceivedTargetPower + DELTA_PREAMBLE + 

(PREAMBLE_TRANSMISSION_COUNTER – 1) * powerRampingStep; 

- instruct the physical layer to transmit a preamble using the selected 

PRACH, corresponding RA-RNTI, preamble index and 

PREAMBLE_RECEIVED_TARGET_POWER. 

(3GPP TS 36.321 V11.1.0 (2012-12), at 6–7, 13, 15.) 

90. The method of Claim 1 of the ’697 Patent requires the step of “receiving a random 

access response that is aggregated with other random access responses for other user equipments 

in a time and frequency resource of a single downlink component carrier.” 

91. The applicable standards covered by the claims of the ’697 Patent, including but 

not limited to 3GPP TS 36.321 V11.1.0 (2012-12), describe the step of receiving a random access 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 53 of 66
Page 54 of 66 

response that is aggregated with other random access responses for other user equipments in a time 

and frequency resource of a single downlink component carrier: 

3 Definitions and abbreviations 

3.1 Definitions 

. . . . 

RA-RNTI: The Random Access RNTI is used on the PDCCH when Random 

Access Response messages are transmitted. It unambiguously identifies which 

time-frequency resource was utilized by the UE to transmit the Random Access 

preamble. 

. . . . 

5 MAC procedures 

5.1 Random Access procedure 

. . . . 

5.1.4 Random Access Response reception 

Once the Random Access Preamble is transmitted and regardless of the possible 

occurrence of a measurement gap, the UE shall monitor the PDCCH of the PCell 

for Random Access Response(s) identified by the RA-RNTI defined below, in the 

RA Response window which starts at the subframe that contains the end of the 

preamble transmission [7] plus three subframes and has length raResponseWindowSize subframes. The RA-RNTI associated with the PRACH in 

which the Random Access Preamble is transmitted, is computed as: 

RA-RNTI= 1 + t_id+10*f_id 

Where t_id is the index of the first subframe of the specified PRACH (0≤ t_id <10), 

and f_id is the index of the specified PRACH within that subframe, in ascending 

order of frequency domain (0≤ f_id< 6). The UE may stop monitoring for Random 

Access Response(s) after successful reception of a Random Access Response 

containing Random Access Preamble identifiers that matches the transmitted 

Random Access Preamble. 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 54 of 66
Page 55 of 66 

6 Protocol Data Units, formats and parameters 

6.1 Protocol Data Units 

. . . . 

6.1.5 MAC PDU (Random Access Response) 

A MAC PDU consists of a MAC header and zero or more MAC Random Access 

Responses (MAC RAR) and optionally padding as described in figure 6.1.5-4. 

The MAC header is of variable size. 

A MAC PDU header consists of one or more MAC PDU subheaders; each 

subheader corresponding to a MAC RAR except for the Backoff Indicator 

subheader. If included, the Backoff Indicator subheader is only included once and 

is the first subheader included within the MAC PDU header. 

. . . . 

Figure 6.1.5-4: Example of MAC PDU consisting of a MAC header and MAC 

RARs

(3GPP TS 36.321 V11.1.0 (2012-12), at 6–7, 13, 15, 35, 43-44.) 

92. In addition, the applicable standards covered by the claims of the ’697 Patent, 

including but not limited to 3GPP TS 36.300 V11.4.0 (2012-12), describe the step of receiving a 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 55 of 66
Page 56 of 66 

random access response that is aggregated with other random access responses for other user 

equipments in a time and frequency resource of a single downlink component carrier: 

10 Mobility 

. . . . 

10.1 Intra E-UTRAN 

. . . . 

10.1.5 Random Access Procedure 

. . . . 

10.1.5.2 Non-contention based random access procedure 

The non-contention based random access procedure is outlined on Figure 10.1.5.2-

1 below: 

Figure 10.1.5.2-1: Non-contention based Random Access Procedure 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 56 of 66
Page 57 of 66 

The three steps of the non-contention based random access procedures are: 

0) Random Access Preamble assignment via dedicated signalling in DL: 

- eNB assigns to UE a non-contention Random Access Preamble (a Random 

Access Preamble not within the set sent in broadcast signalling). 

- Signalled via: 

- HO command generated by target eNB and sent via source eNB for 

handover; 

- PDCCH in case of DL data arrival or positioning; 

- PDCCH for initial UL time alignment for a sTAG. 

1) Random Access Preamble on RACH in uplink: 

- UE transmits the assigned non-contention Random Access Preamble. 

2) Random Access Response on DL-SCH: 

- Semi-synchronous (within a flexible window of which the size is two or 

more TTIs) with message 1; 

- No HARQ; 

- Addressed to RA-RNTI on PDCCH; 

- Conveys at least: 

- Timing Alignment information and initial UL grant for handover; 

- Timing Alignment information for DL data arrival; 

- RA-preamble identifier. 

- Intended for one or multiple UEs in one DL-SCH message. 

When performing non-contention based random access on the PCell while CA is 

configured, the Random Access Preamble assignment via PDCCH of step 0, step 1 

and 2 of the non-contention based random access procedure occur on the PCell. In 

order to establish timing advance for a sTAG, the eNB may initiate a noncontention based random access procedure with a PDCCH order (step 0) that is sent 

on a scheduling cell of activated SCell of the sTAG. Preamble transmission (step 

1) is on the indicated SCell and Random Access Response (step 2) takes place on 

PCell. 

(3GPP TS 36.300 V11.4.0 (2012-12), at 61–62, 72, 74–75.) 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 57 of 66
Page 58 of 66 

93. In addition, the applicable standards covered by the claims of the ’697 Patent, 

including but not limited to 3GPP TS 36.213 V11.1.0 (2012-12), describe the step of receiving a 

random access response that is aggregated with other random access responses for other user 

equipments in a time and frequency resource of a single downlink component carrier: 

6 Random access procedure 

. . . . 

6.1 Physical non-synchronized random access procedure 

From the physical layer perspective, the L1 random access procedure encompasses 

the transmission of random access preamble and random access response. The 

remaining messages are scheduled for transmission by the higher layer on the 

shared data channel and are not considered part of the L1 random access procedure. 

A random access channel occupies 6 resource blocks in a subframe or set of 

consecutive subframes reserved for random access preamble transmissions. The 

eNodeB is not prohibited from scheduling data in the resource blocks reserved for 

random access channel preamble transmission. 

(3GPP TS 36.213 V11.1.0 (2012-12), at 23–24.) 

94. The method of Claim 1 of the ’697 Patent requires the step of “wherein the 

aggregated random access response comprises responses to a plurality of random access requests 

from individual ones of a plurality of user equipments.” 

95. The applicable standards covered by the claims of the ’697 Patent, including but 

not limited to 3GPP TS 36.300 V11.4.0 (2012 12), describe the step of wherein the aggregated 

random access response comprises responses to a plurality of random access requests from 

individual ones of a plurality of user equipments: 

10 Mobility 

. . . . 

10.1 Intra E-UTRAN 

. . . . 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 58 of 66
Page 59 of 66 

10.1.5 Random Access Procedure 

. . . . 

10.1.5.2 Non-contention based random access procedure 

The non-contention based random access procedure is outlined on Figure 10.1.5.2-

1 below: 

Figure 10.1.5.2-1: Non-contention based Random Access Procedure 

The three steps of the non-contention based random access procedures are: 

0) Random Access Preamble assignment via dedicated signalling in DL: 

- eNB assigns to UE a non-contention Random Access Preamble (a Random 

Access Preamble not within the set sent in broadcast signalling). 

- Signalled via: 

- HO command generated by target eNB and sent via source eNB for 

handover; 

- PDCCH in case of DL data arrival or positioning; 

- PDCCH for initial UL time alignment for a sTAG. 

1) Random Access Preamble on RACH in uplink: 

- UE transmits the assigned non-contention Random Access Preamble. 

2) Random Access Response on DL-SCH: 

- Semi-synchronous (within a flexible window of which the size is two or 

more TTIs) with message 1; 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 59 of 66
Page 60 of 66 

- No HARQ; 

- Addressed to RA-RNTI on PDCCH; 

- Conveys at least: 

- Timing Alignment information and initial UL grant for handover; 

- Timing Alignment information for DL data arrival; 

- RA-preamble identifier. 

- Intended for one or multiple UEs in one DL-SCH message. 

When performing non-contention based random access on the PCell while CA is 

configured, the Random Access Preamble assignment via PDCCH of step 0, step 1 

and 2 of the non-contention based random access procedure occur on the PCell. In 

order to establish timing advance for a sTAG, the eNB may initiate a noncontention based random access procedure with a PDCCH order (step 0) that is sent 

on a scheduling cell of activated SCell of the sTAG. Preamble transmission (step 

1) is on the indicated SCell and Random Access Response (step 2) takes place on 

PCell. 

(3GPP TS 36.300 V11.4.0 (2012-12), at 61–62, 72, 74–75.) 

96. In addition, the applicable standards covered by the claims of the ’697 Patent, 

including but not limited to 3GPP TS 36.321 V11.1.0 (2012-12), describe the step of wherein the 

aggregated random access response comprises responses to a plurality of random access requests 

from individual ones of a plurality of user equipments: 

6 Protocol Data Units, formats and parameters 

6.1 Protocol Data Units 

. . . . 

6.1.5 MAC PDU (Random Access Response) 

A MAC PDU consists of a MAC header and zero or more MAC Random Access 

Responses (MAC RAR) and optionally padding as described in figure 6.1.5-4. 

The MAC header is of variable size. 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 60 of 66
Page 61 of 66 

A MAC PDU header consists of one or more MAC PDU subheaders; each 

subheader corresponding to a MAC RAR except for the Backoff Indicator 

subheader. If included, the Backoff Indicator subheader is only included once and 

is the first subheader included within the MAC PDU header. 

. . . . 

Figure 6.1.5-4: Example of MAC PDU consisting of a MAC header and MAC 

RARs

(3GPP TS 36.321 V11.1.0 (2012-12), at 35, 43-44.) 

97. Upon information and belief, the Tesla Standard-Compliant Products comply or 

have complied with the applicable standards covered by the claims of the ’697 Patent, including 

without limitation 3G and/or 4G/LTE, and therefore infringe the ’697 Patent, including at least 

Claim 1. 

98. The Tesla Standard-Compliant Products have complied, and continue to comply, 

with 3GPP TS 36.300 V11.4.0 (2012-12). 

99. The Tesla Standard-Compliant Products have complied, and continue to comply, 

with 3GPP TS 36.211 V11.2.0 (2013-02). 

100. The Tesla Standard-Compliant Products have complied, and continue to comply, 

with 3GPP TS 36.321 V11.1.0 (2012-12). 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 61 of 66
Page 62 of 66 

101. The Tesla Standard-Compliant Products have complied, and continue to comply, 

with 3GPP TS 36.213 V11.1.0 (2012-12). 

102. Tesla is infringing claims of the ’697 Patent, including at least Claim 1, literally 

and/or pursuant to the doctrine of equivalents. 

103. In violation of 35 U.S.C. § 271(b), Tesla is and has been infringing one or more of 

the ’697 Patent’s claims, including at least Claim 1, indirectly by inducing the infringement of the 

’697 Patent’s claims by third parties, including without limitation manufacturers, resellers, and/or 

users of Tesla’s Standard-Compliant Products, in this District, and elsewhere in the United States. 

Direct infringement is the result of activities performed by users of the Tesla Standard-Compliant 

Products in accordance with the claims of the ’697 Patent. 

104. Tesla’s affirmative acts of selling the Tesla’s Standard-Compliant Products, 

causing the Tesla Standard-Compliant Products to be manufactured and distributed, providing 

instructive materials and information concerning operation and use of the Tesla 

Standard-Compliant Products, and maintenance/service for such products, induced users of the 

Tesla Standard-Compliant Products to infringe the ’697 Patent’s claims by using the vehicles in 

their normal and customary way. By and through these acts, Tesla knowingly and specifically 

intends the users of the Tesla Standard-Compliant Products to infringe the ’697 Patent’s claims. 

Tesla (1) knows and knew of the ’697 Patent since at least prior to the filing of this lawsuit, 

(2) performs affirmative acts that constitute induced infringement, and (3) knows or should know 

that those acts would induce actual infringement of one or more of the ’697 Patent’s claims by 

users of the Tesla Standard-Compliant Products. 

105. In violation of 35 U.S.C. § 271(c), Tesla is and has been infringing one or more of 

the ’697 Patent’s claims, including at least Claim 1, indirectly by contributing to the infringement 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 62 of 66
Page 63 of 66 

of the ’697 Patent’s claims by third parties, including without limitation manufacturers, resellers, 

and/or users of the Tesla Standard-Compliant Products, in this District, and elsewhere in the United 

States. Direct infringement is the result of activities performed by manufacturers, resellers, and/or 

users in relation to the Tesla Standard-Compliant Products, including without limitation use of the 

Tesla Standard-Compliant Products. 

106. Upon information and belief, Tesla at least installs, configures, and sells Tesla 

Standard-Compliant Products with distinct and separate hardware and/or software components 

especially made or especially adapted to practice the invention claimed in the ’697 Patent. That 

hardware and/or software is a material part of the invention. That hardware and/or software is not 

a staple article or commodity of commerce because it is specifically designed to perform the 

claimed functionality. Any other use of that hardware and/or software would be unusual, farfetched, illusory, impractical, occasional, aberrant, or experimental. 

107. Therefore, upon information and belief, Tesla is making, using, offering to sell, 

and/or selling in the United States, and/or importing into the United States, without authority, a 

component of a patented machine, manufacture, combination or composition, or a material or an 

apparatus for use in practicing a patented process, constituting a material part of the invention, 

knowing the same to be especially made or especially adapted for use in infringement of a patent, 

and not a staple article or commodity of commerce suitable for substantial noninfringing use. 

108. As explained above, Tesla had actual notice of the ’697 Patent prior to this lawsuit 

being filed and had knowledge of the infringing nature of its activities. Nevertheless, Tesla 

continued its infringing activities. 

109. Instead of taking a FRAND license to Conversant’s patent portfolio, Tesla 

continues, in bad faith, to directly and indirectly infringe Conversant’s patents, including the 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 63 of 66
Page 64 of 66 

’697 Patent by making, using, offering for sale and selling infringing Tesla Standard-Compliant 

Products, and inducing and contributing to the infringement of others. 

110. Therefore, upon information and belief, Tesla’s infringement of the ’697 Patent’s 

claims, including at least Claim 1, has been and continues to be willful entitling Conversant to 

increased damages pursuant to 35 U.S.C. § 284 and to attorneys’ fees and costs incurred in 

prosecuting this action pursuant to 35 U.S.C. § 285. 

111. Tesla’s acts of infringement have caused damages to Conversant, and Conversant 

is entitled to recover from Tesla the damages sustained by Conversant as a result of Tesla’s 

wrongful acts in an amount to be determined at trial. 

DAMAGES 

112. Tesla’s acts of infringement are and were committed intentionally, knowingly, and 

with callous disregard of Conversant’s legitimate rights. Conversant is therefore entitled to and 

now seeks to recover exemplary damages in an amount not less than the maximum amount 

permitted by law. 

113. As a result of Tesla’s acts of infringement, Conversant has suffered actual and 

consequential damages. To the fullest extent permitted by law, Conversant seeks recovery of 

damages in an amount to compensate for Tesla’s infringement. Conversant further seeks any other 

damages to which Conversant would be entitled to in law or in equity. 

ATTORNEYS’ FEES 

114. Conversant is entitled to recover reasonable and necessary attorneys’ fees under 

applicable law. 

DEMAND FOR JURY TRIAL 

Pursuant to Rule 38 of the Federal Rules of Civil Procedure, Conversant demands a trial 

by jury on all issues so triable. 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 64 of 66
Page 65 of 66 

PRAYER FOR RELIEF 

Conversant respectfully requests that the Court enter preliminary and final orders, 

declarations, and judgments against Tesla as are necessary to provide Conversant with the 

following relief: 

a. A judgment that Tesla has infringed and/or is infringing one or more claims of the 

’456 Patent, literally or under the doctrine of equivalents, and directly or indirectly; 

b. A judgment that Tesla’s infringement of the ’456 Patent has been willful; 

c. A judgment that Tesla has infringed and/or is infringing one or more claims of the 

’697 Patent, literally or under the doctrine of equivalents, and directly or indirectly; 

d. A judgment that Tesla’s infringement of the ’697 Patent has been willful; 

e. An award for all damages arising out of Tesla’s infringement, together with 

prejudgment and post-judgment interest, jointly and severally, in an amount 

according to proof, including without limitation attorneys’ fees and litigation costs 

and expenses; 

f. Any future compensation due to Conversant for Tesla’s infringement (past, present 

or future) not specifically accounted for in a damages award (or other relief), and/or 

permanent injunctive relief; 

g. An award of reasonable attorneys’ fees as provided by 35 U.S.C. § 285 and 

enhanced damages as provided by 35 U.S.C. § 284; and 

h. All further relief in law or in equity as the Court may deem just and proper. 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 65 of 66
Page 66 of 66 

Dated: April 24, 2020 Respectfully submitted, 

/s/ Jamie H. McDole 

 Jamie H. McDole 

State Bar No. 24082049 

Michael D. Karson 

State Bar No. 24090198 

Nadia E. Haghighatian 

State Bar No. 24087652 

THOMPSON & KNIGHT LLP 

One Arts Plaza 

1722 Routh St., Suite 1500 

Dallas, Texas 75201 

Tel.: 214.969.1700 

Fax: 214.969.1751 

Email: jamie.mcdole@tklaw.com

michael.karson@tklaw.com

nadia.haghighatian@tklaw.com

Attorneys for Plaintiff 

Conversant Wireless Licensing S.A.R.L.

 

Case 6:20-cv-00323-ADA Document 1 Filed 04/24/20 Page 66 of 66