Exhibit 2a

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 Page 1 of 109
Infringement Contentions – Adidas’s Android 

U.S. Patent No. 5,991,399 

Claim Analysis 1. A method of securely distributing data comprising: 

Adidas’s mobile software application products and services including by way o“mobile apps” or “Accused Products”) that are specifically developed, used, so

downloaded onto Android mobile or tablet devices. 

 Runtastic Steps - Step Tracker & Pedometer (https://play.google.com/

Mar 19, 2020 

 adidas Running App by Runtastic (https://play.google.com/store/apps/ adidas Training by Runtastic - Fitness Workouts (https://play.google.co

accessed on Mar 19, 2020 

Adidas directly infringes and/or continues to knowingly induce Google to infrinadvertising, providing, sending, distributing and licensing its mobile application

abetting, encouraging, promoting or inviting use thereof. To the extent any steps identified herein are performed by Google, such acts aGoogle in a joint enterprise in the building and distribution of its mobile apps, under the direction and control of Adidas, or acts as agent, or on behalf of Adid

apps.Alternatively, any steps or acts performed by Adidas, are attributable to Googl

the distribution of Adidas’s mobile apps through its app store, upon compliancGoogle in the building and upload of Adidas’s mobile apps, and Adidas induces 

Adidas’s mobile apps.To the extent the preamble is limiting, Adidas distributes data according to the 

In order to build and send the mobile app securely to the Google servers, Adid

securely distribute its mobile app to Adidas’s customers through the Google ap

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Developer Console (https://play.google.com/apps/publish/, Last accessed on M

Google app store, Google Play, as evidenced by the “https” in the URL. Source: https://support.google.com/googleplay/android-developer/answer/61

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
generating an asymmetric key pair 

having a public key and a private key; 

The Court previously construed1 “an asymmetric key pair having a public key apairs, one of the asymmetric key pairs having the claimed public key and claimcomplementary by performing complementary functions, such as encrypting aAlso relevant to this claim element is the Court’s previous construction of “execode module” / “tamper resistant key module” to mean “software that is desigmodification, and that includes a key for secure communication.” Also relevant to this claim element is the Court’s rejection of limiting “includinUpon information and belief, the method step of “generating an asymmetric kand/or its agents – whose acts are attributable to Adidas (i) because Adidas wo

distribution of its mobile apps, or (ii) because Google distributes and markets Aas agent, or on behalf of Adidas, in the building, marketing and distribution of 

Alternatively, to the extent any portion of this method step is performed by Adparticipation in and the receipt of a benefit, namely, the distribution of Adidasmandatory procedures and guidelines dictated by Google in the building and uGoogle in the building, marketing and distribution of Adidas’s mobile apps. Adidas uploads their mobile apps to Google using a TLS connection – which be

that allows Adidas and Google to exchange cryptographic parameters, includincommunication including upload of Adidas’s mobile apps to Google servers. A TLS handshake begins with Adidas sending a list of cipher suites supported bthe following key exchange algorithms: 

1 See Memorandum Opinion and Order, Document 104 signed by Judge Rodney Gilstrap on 7/21/2016 in re Plano Encryption Techno

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Each of these algorithms necessitates generating one or more asymmetric key For RSA and RSA _PSK, a Google server generates an RSA public-private key pa

performing complementary function encrypting and decrypting data. 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Google server generates 

public-private key pair2. Adidas also generates a second Diffie-Hellman public-pcomplementary by performing complementary functions, such as creating and Hellman private key are also complementary by performing complementary futhe Diffie-Hellman key exchange algorithm, Adidas uses Google’s Diffie-Hellmacompute a premaster secret and thereon a master secret3 for encrypting data. Google’s own Diffie-Hellman private key to compute the same premaster secre

Conversely, Google uses Adidas’s Diffie-Hellman public key combined with Gooand thereon, a master secret4 for encrypting data. Adidas uses Google’s Diffie-

key to compute a premaster secret and thereon a master secret for decrypting For DHE_DSS and DH_DSS, Google server generates a DSA public-private key pgenerates a second Diffie-Hellman public-private key pair. The DSA public key acomplementary functions, such as creating and verifying signatures. The Diffiecomplementary by performing complementary functions, such as encrypting aexchange algorithm, Adidas uses Google’s Diffie-Hellman public key combined secret and thereon a master secret5 for encrypting data. Google in turn uses AHellman private key to compute the same premaster secret and the master seuses Adidas’s Diffie-Hellman public key combined with Google’s own Diffie-He

2 ECDH and ECDHE algorithms require generating at the server and the client, elliptical curve parameters that constitute a Diffie-Hellmhttps://tools.ietf.org/html/rfc5246 page 49-52, https://tools.ietf.org/html/rfc7525 page 12, http://www.cse.hut.fi/fi/opinnot/T-110.5http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2897.pdf, http://www.networkworld.com/article/2268575/lahttp://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf, Implementing SSL / TLS Using Cryptography and PKI by Joshua DavieNetworks and Cybersecurity By Chwan-Hwa (John) Wu, J. David Irwin, ISBN 1466572140, 9781466572140, Page 1021, which state that ECDH requires generating a Diffie-Hellman public-private key pair, Last acc3 The master secret obtained from the premaster secret may be hashed according to a hashing algorithm also specified in the cipher s

https://tools.ietf.org/html/rfc5246, Sections 6.3, 7.4.9 and 8.1. 4 The master secret obtained from the premaster secret may be hashed according to a hashing algorithm also specified in the cipher s

https://tools.ietf.org/html/rfc5246, Sections 6.3, 7.4.9 and 8.1. 5 The master secret obtained from the premaster secret may be hashed according to a hashing algorithm also specified in the cipher s

https://tools.ietf.org/html/rfc5246, Sections 6.3, 7.4.9 and 8.1. 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
master secret6 for encrypting data. Adidas uses Google’s Diffie-Hellman public 

compute a premaster secret and thereon a master secret for decrypting encryFor ECDH_ECDSA and ECDHE_ECDSA, a Google server generates an ECDSA pubAdidas also generates a second Diffie-Hellman public-private key pair. The ECDperforming complementary functions, such as creating and verifying signature

also complementary by performing complementary functions, such as encrypt

exchange algorithm, Adidas uses Google’s Diffie-Hellman public key combined secret and thereon a master secret7 for encrypting data. Google in turn uses AHellman private key to compute the same premaster secret and the master seuses Adidas’s Diffie-Hellman public key combined with Google’s own Diffie-Hemaster secret8 for encrypting data. Adidas uses Google’s Diffie-Hellman public compute a premaster secret and thereon a master secret for decrypting encry

6 The master secret obtained from the premaster secret may be hashed according to a hashing algorithm also specified in the cipher s

https://tools.ietf.org/html/rfc5246, Sections 6.3, 7.4.9 and 8.1. 7 The master secret obtained from the premaster secret may be hashed according to a hashing algorithm also specified in the cipher s

https://tools.ietf.org/html/rfc5246, Sections 6.3, 7.4.9 and 8.1. 8 The master secret obtained from the premaster secret may be hashed according to a hashing algorithm also specified in the cipher s

https://tools.ietf.org/html/rfc5246, Sections 6.3, 7.4.9 and 8.1. 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 50-51, Last accessed on Mar 19, 202

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

In addition, Adidas and/or Google also generate additional asymmetric key paicommunications during the operation of the mobile app. Thus, at least one asymmetric key pair is generated having the claimed public k

that the mobile app code and metadata can be sent securely to the Google ser

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
pair used to digitally sign the app) is complementary as described below by pe

data and/or creating and verifying signatures. As described in greater detail besecurely upload the mobile app onto the Google servers by SSL/TLS when buildclaimed asymmetric key pair and the encrypted predetermined data that has b

encrypting predetermined data with the generated public key; 

Upon information and belief, the method step of “encrypting predetermined dagents. To the extent any portion of the method step is performed by Google and/or ittogether with Google in a joint enterprise in the building and distribution of its mobile apps under the direction and control of Adidas, or acts as agent, or on bmobile apps. When Adidas uploads its mobile apps to Google, it connects to Google Play DeTLS handshake procedure which uses asymmetric key encryption and necessitanegotiates with Google a cipher suite and the key exchange algorithm that will 

The cryptographic parameters of the session state are produced by the 

 TLS Handshake Protocol, which operates on top of the TLS record  layer. When a TLS client and server first start communicating, they  agree on a protocol version, select cryptographic algorithms,  optionally authenticate each other, and use public-key encryption  techniques to generate shared secrets.  The TLS Handshake Protocol involves the following steps: 

 - Exchange hello messages to agree on algorithms, exchange random  values, and check for session resumption.  - Exchange the necessary cryptographic parameters to allow the  client and server to agree on a premaster secret.  - Exchange certificates and cryptographic information to allow the  client and server to authenticate themselves.

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
 - Generate a master secret from the premaster secret and exchanged 

 random values.  - Provide security parameters to the record layer.  - Allow the client and server to verify that their peer has  calculated the same security parameters and that the handshake  occurred without tampering by an attacker. 

Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

The actual key exchange uses up to four messages: the server 

 Certificate, the ServerKeyExchange, the client Certificate, and the  ClientKeyExchange. New key exchange methods can be created by 

 specifying a format for these messages and by defining the use of the  messages to allow the client and server to agree upon a shared  secret. This secret MUST be quite long; currently defined key  exchange methods exchange secrets that range from 46 bytes upwards.  Following the hello messages, the server will send its certificate in  a Certificate message if it is to be authenticated. Additionally, a  ServerKeyExchange message may be sent, if it is required (e.g., if  the server has no certificate, or if its certificate is for signing  only). If the server is authenticated, it may request a certificate  from the client, if that is appropriate to the cipher suite selected.  Next, the server will send the ServerHelloDone message, indicating  that the hello-message phase of the handshake is complete. The  server will then wait for a client response. If the server has sent  a CertificateRequest message, the client MUST send the Certificate  message. The ClientKeyExchange message is now sent, and the content  of that message will depend on the public key algorithm selected  between the ClientHello and the ServerHello. If the client has sent  a certificate with signing ability, a digitally-signed 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
 CertificateVerify message is sent to explicitly verify possession of 

 the private key in the certificate. 

Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

The TLS Handshaking Protocols 

 TLS has three subprotocols that are used to allow peers to agree upon 

 security parameters for the record layer, to authenticate themselves,  to instantiate negotiated security parameters, and to report error  conditions to each other.  The Handshake Protocol is responsible for negotiating a session,  which consists of the following items:  session identifier  An arbitrary byte sequence chosen by the server to identify an  active or resumable session state.  peer certificate  X509v3 [PKIX] certificate of the peer. This element of the state 

 may be null.  compression method  The algorithm used to compress data prior to encryption.  cipher spec  Specifies the pseudorandom function (PRF) used to generate keying  material, the bulk data encryption algorithm (such as null, AES,  etc.) and the MAC algorithm (such as HMAC-SHA1). It also defines  cryptographic attributes such as the mac_length. (See Appendix

A.6 for formal definition.) 

 master secret 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
 48-byte secret shared between the client and server. 

 is resumable  A flag indicating whether the session can be used to initiate new  connections.  These items are then used to create security parameters for use by  the record layer when protecting application data. Many connections  can be instantiated using the same session through the resumption  feature of the TLS Handshake Protocol. 

Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

As explained above, Adidas and Google negotiate a key exchange algorithm fro

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

For each of the above key exchange algorithms, Google and/or Adidas encryptFor RSA and RSA _PSK, Adidas encrypts a random premaster secret with Goog

Google. Google decrypts the premaster secret with its matched RSA private ke

master secret which is then used by both Adidas and Google to encrypt all sub

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
when any of RSA and RSA _PSK algorithms are chosen during a TLS handshake

the generated public key (i.e. Google’s RSA public key). For the other key exchange algorithms, namely Diffie-Hellman based algorithmECDH_RSA, ECDH_ECDSA and ECDHE_ECDSA, Adidas sends its Diffie-Hellman 

to Adidas. Adidas then uses Google’s Diffie-Hellman public key combined with 

secret. Google in turn uses Adidas’s Diffie-Hellman public key combined with Gpremaster secret. Adidas and Google both use the premaster secret to computencrypt all subsequent communications between Adidas and Google. Therefore, when any of the Diffie-Hellman based key exchange algorithms are i.e. all communication with Google subsequent to the TLS handshake, including information such as name, category, screenshots and description related to AdHellman public key, since the master secret used to encrypt the predetermined 

Adidas’s Diffie-Hellman private key11. Similarly, when any of the Diffie-Hellman based key exchange algorithms are c

i.e. all communication with Google subsequent to the TLS handshake, including Developer Console website and forms that Adidas uses for uploading its mobilDiffie-Hellman public key, since the master secret used to encrypt the predete

Google’s Diffie-Hellman private key12. 

and building an executable tamper resistant key module identified for a selected program, the executable 

Relevant to this claim element is the Court’s previous construction13 of “executcode module” / “tamper resistant key module” to mean “software that is desig

9 For Diffie-Hellman (DH) based algorithms such as DH_RSA, DHE_RSA, ECDH_RSA, ECDHE_RSA, DH_DSS, DHE_DSS, ECDH_ECDSA and Diffie-Hellman public key and encrypts the hash with their RSA/DSA/ECDSA private key (i.e. signing the message). Google then sends tRuntastic can authenticate the Google server by decrypting the hash using Google’s public key and matching the decryption result to values match, Runtastic knows that the message originated from Google and not from a malicious third party. 10 The master secret obtained from the premaster secret may be hashed according to a hashing algorithm also specified in the cipher https://tools.ietf.org/html/rfc5246, Sections 6.3, 7.4.9 and 8.1. 11 See, for example, https://tools.ietf.org/html/rfc2631, Page 2, Last accessed on Mar 19, 2020 12 Id. 13 See Memorandum Opinion and Order, Document 104 signed by Judge Rodney Gilstrap on 7/21/2016 in re Plano Encryption Techno

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
tamper resistant key module including 

the generated private key and the encrypted predetermined data. 

modification, and that includes a key for secure communication.” Also relevan“including” to compiling14. The method step of “building an executable tamper resistant key module iden

module including the generated private key and the encrypted predetermined To the extent any portion of the method step is performed by Google and/or ittogether with Google in a joint enterprise in the building and distribution of its mobile apps under the direction and control of Adidas, or acts as agent, or on b

mobile apps. Building of an “executable tamper resistant code module” (that is, the mobile asymmetric key pairs: (1) An asymmetric key pair must be included in order to send the mobile a(2) An asymmetric key pair must be included by Adidas in order to digitally mobile app has not been changed with the public key for Android compatible mThe asymmetric key pair that is included to digitally sign the mobile app is diffesecurely upload the mobile app to the Google servers for distribution on the GThus, at least one asymmetric key pair is included having the claimed public kethe mobile app code can be sent uploaded to the Google servers using SSL/TLS pair used to digitally sign the app) is complementary as described below by pedata and/or creating and verifying signatures. As described in greater detail besecurely upload the mobile app onto the Google servers by SSL/TLS when build

claimed asymmetric key pair(s) and the encrypted predetermined data. Adidas uploads their mobile apps to Google using a TLS connection – which be

that allows Adidas and Google to exchange cryptographic parameters, includincommunication including upload of Adidas’s mobile apps to Google servers. 

14 Also relevant is the Court’s construction of “an asymmetric key pair having a public key and a private key” in claims 1, 9 and 10 to m

having the claimed public key and claimed private key, the asymmetric keys of an asymmetric key pair being complementary by perfocreating and verifying signatures.” 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
A TLS handshake begins with Adidas sending a list of cipher suites supported b

the following key exchange algorithms: 

Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For each of the key exchange algorithms, Adidas and/or Google build an execu

key and the encrypted predetermined data. For RSA and RSA _PSK, the executable tamper resistant key module includes eit would be impossible for Adidas to send its mobile app to Google using SSL/Texecutable tamper resistant key module also includes: 

1. Google’s RSA private key corresponding to Google’s RSA public key use

2. Adidas’s private key used to code-sign the mobile app. 

For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, the executable tamper recommunication with Google subsequent to the TLS handshake, including at leainformation such as name, category, screenshots and description related to Adincludes: 

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s RSA private key used to sign the message containing Google’s 4. Adidas’s private key used to code-sign the mobile app. 

For DHE_DSS and DH_DSS, the executable tamper resistant key module includ

subsequent to the TLS handshake, including at least the executable compiled ccategory, screenshots and description related to Adidas’s mobile apps). The ex

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s DSA private key used to sign the message containing Google’4. Adidas’s private key used to code-sign the mobile app. 

For ECDH_ECDSA and ECDHE_ECDSA, the executable tamper resistant key mo

with Google subsequent to the TLS handshake, including at least the executablname, category, screenshots and description related to Adidas’s mobile apps). 

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
3. Google’s ECDSA private key used to sign the message containing Goog

4. Adidas’s private key used to code-sign the mobile app. 

Adidas builds an executable tamper resistant key module identified for a select

mobile app, which is an executable tamper resistant key module, as explained program resident on a remote system, namely the Android operating system oThe mobile app comprises an executable tamper resistant key module that is i

described above and the encrypted predetermined data encrypted with the clathat it can be made available for download from Google servers onto devices cAdidas. An asymmetric key pair is used not only to upload the binary code files the metadata for the app, such as title, screenshots, and other resources or infincluded during the upload process so that the mobile app can be identified by 

Adidas’s mobile app is each an executable tamper resistant key module becausoperating system as well as other applications or programs installed on a user’and modification, as explained below; and because in building Adidas mobile a

generated private key and the encrypted predetermined data including by way generated public key when the mobile app is securely uploaded onto the Goog

The tamper resistant key module includes several keys “used for secure commfollowing: For RSA and RSA _PSK: 

1. Google’s RSA private key corresponding to Google’s RSA public key use2. Adidas’s private key used to code-sign the mobile app. 3. Symmetric key used for uploading the mobile app to Google subseque4. Asymmetric keys and symmetric keys used for TLS communications du

For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA: 

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste

15 See, e.g., https://developer.android.com/studio/publish/index.html, Last accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
3. Google’s RSA private key used to sign the message containing Google’s 

4. Adidas’s private key used to code-sign the mobile app. 5. Shared master secret key used for uploading the mobile app to Google 

6. Asymmetric keys and symmetric keys used for TLS communications du

For DHE_DSS and DH_DSS: 

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s DSA private key used to sign the message containing Google’4. Adidas’s private key used to code-sign the mobile app. 5. Shared master secret key used for uploading the mobile app to Google 6. Asymmetric keys and symmetric keys used for TLS communications du

For ECDH_ECDSA and ECDHE_ECDSA: 

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s ECDSA private key used to sign the message containing Goog4. Adidas’s private key used to code-sign the mobile app. 5. Shared master secret key used for uploading the mobile app to Google 6. Asymmetric keys and symmetric keys used for TLS communications du

Adidas’s mobile apps are tamper resistant, resistant to observation and modifi

1. Resistant to Observation Because App Source Code Is Compiled Befo

Adidas mobile apps are resistant to observation, at least in part, since Adidas cGoogle – and uploads the binary output of the compilation process rather than 

16 See, e.g., https://developer.android.com/studio/build/index.html, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
See, Android Studio Users Guide, “Prepare for Release” stating “To release you

users can install and run on their Android-powered devices. The release-ready compiled source code, resources, manifest file, and so on — and it is built usinrelease-ready APK file is signed with your own certificate and it is optimized wi

https://developer.android.com/studio/publish/preparing.html, Last accessed o

2. Resistant to Observation Because Upload To Google Is Over SSL/TLS 

Adidas’s mobile apps are made further resistant to observation, at least in partof the building process. Android Developer Console (https://play.google.com/a

communications when uploading Adidas’s apps, as evidenced by the “https” in the code from being observed in transit from the code developer to Google. The secure upload process starts with a TLS handshake procedure which uses a

asymmetric key pair. Specifically, Adidas negotiates with Google the cipher sui

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

For each of the above key exchange algorithms, Google and/or Adidas encrypt

master secret, rendering the communication resistant to observation during tr

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For RSA and RSA _PSK, Adidas encrypts a random premaster secret with Goog

Google. Google decrypts the premaster secret with its matched RSA private kemaster secret which is then used by both Adidas and Google to encrypt all subFor the other key exchange algorithms, namely Diffie-Hellman based algorithmECDH_RSA, ECDH_ECDSA and ECDHE_ECDSA, Adidas sends its Diffie-Hellman to Adidas. Adidas then uses Google’s Diffie-Hellman public key combined with 

secret. Google in turn uses Adidas’s Diffie-Hellman public key combined with Gpremaster secret. Adidas and Google both use the premaster secret to computencrypt all subsequent communications between Adidas and Google. 

3. Resistant to Modification Because App Binary Is Code Signed 

The mobile app code is made resistant to modification, at least in part, becausmust sign the mobile app submission with his/her asymmetric developer key timpersonator18. 

Android requires that the user generates an asymmetric key all apps be 

uses this certificate to identify the author of an app Source: https://developer.android.com/studio/publish/app-signing.htm

A public-key certificate, also known as a digital certificate or an identity 

as some other metadata identifying the owner of the key (for example, corresponding private key. When you sign an APK, the signing tool attaches the public-key certificathat uniquely associates the APK to you and your corresponding private authentic and come from the original author. 

A keystore is a binary file that contains one or more private keys. When 

generate a new keystore and private key or use a keystore and private k

17 For Diffie-Hellman (DH) based algorithms such as DH_RSA, DHE_RSA, ECDH_RSA, ECDHE_RSA, DH_DSS, DHE_DSS, ECDH_ECDSA and 

Diffie-Hellman public key and encrypts the hash with their RSA/DSA/ECDSA private key (i.e. signing the message). Google then sends tRuntastic can authenticate the Google server by decrypting the hash using Google’s public key and matching the decryption result to values match, Runtastic knows that the message originated from Google and not from a malicious third party. 18 See, e.g., https://developer.android.com/tools/publishing/app-signing.html, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://developer.android.com/studio/publish/app-signing.htm

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171107004101/https://develop

accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171107004101/https://develop

accessed on Mar 19, 2020 Source: http://web.archive.org/web/20171107004101/https://developaccessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Adidas complies with Google’s instructions on code signing as shown by Adida

files CERT.SF and CERT.RSA in Adidas’s Android apps which are generated durinSource: Contents of Runtastic Steps - Step Tracker & Pedometer(https://play.gas an example of Adidas app, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: Contents of Runtastic Steps - Step Tracker & Pedometer(https://play.g

as an example of Adidas app, Last accessed on Mar 19, 2020 Asymmetrical key cryptography and hashing algorithms are used to create the is used to sign the resources in an application package, including the compiled the digital code signing is used to code sign the app. This private key is include

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
key of the claimed generated asymmetric key pair because it does not match t

the court’s construction. Hashes are created for every resource in the application package with the help prevent unauthorized changes. The hashes are encrypted with a private key. A

created. By signing the app binary with a digital signature, Adidas’s mobile apps are tam

verify that the application is being distributed by trusted source (i.e. Adidas) an

can be verified by the corresponding public key generated as part of the pair. T

Accordingly Adidas’s Android mobile apps establish SSL/TLS communications winvolving asymmetric key encryption. SSL/TLS ensures secure communication a

2. The method of claim 1, wherein the program is on a remote system and further comprising sending the executable tamper resistant key module to the remote system. 

Adidas’s mobile software application products and services including by way o“mobile apps” or “Accused Products”) that are specifically developed, used, so

downloaded onto Android mobile or tablet devices. 

 Runtastic Steps - Step Tracker & Pedometer (https://play.google.com/

Mar 19, 2020 

 adidas Running App by Runtastic (https://play.google.com/store/apps/ adidas Training by Runtastic - Fitness Workouts (https://play.google.co

accessed on Mar 19, 2020 

Adidas directly infringes and/or continues to knowingly induce Google to infrinadvertising, providing, sending, distributing and licensing its mobile application

abetting, encouraging, promoting or inviting use thereof. Upon information and belief, the method step of sending the executable tamp

and/or its agents – whose acts are attributable to Adidas (i) because Adidas wo

distribution of its mobile apps, or (ii) because Google distributes and markets Aas agent, or on behalf of Adidas, in the building, marketing and distribution of 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Alternatively, to the extent any portion of this method step is performed by Ad

participation in and the receipt of a benefit, namely, the distribution of Adidasmandatory procedures and guidelines dictated by Google in the building and uGoogle in the building, marketing and distribution of Adidas’s mobile apps. Adidas’s mobile apps are sent or downloaded from Google servers and are exeWhen a user accesses Google Play Store – and requests to download Adidas apGoogle servers to the remote device(s). Further, the step of “sending” Adidas mobile apps to the remote system occur

apps, to the extent required by the claims, also includes a private key and pred

above. In particular, Adidas mobile apps sent to users’ remote devices are tamper res

1. Resistant to Observation Because App is Downloaded in Compiled Fo

Adidas mobile apps are resistant to observation, at least in part, since Adidas c

Google – and uploads the binary output of the compilation process rather than 

compiled source code from Google rather than the source code itself19.

See, Android Studio Users Guide, “Prepare for Release” stating “To release you

users can install and run on their Android-powered devices. The release-ready 

compiled source code, resources, manifest file, and so on — and it is built usin

release-ready APK file is signed with your own certificate and it is optimized wi

https://developer.android.com/studio/publish/preparing.html, Last accessed o

2. Resistant to Observation Because Download from Google Is Over SSL

Adidas’s mobile apps are made further resistant to observation, at least in part

from Google servers. Adidas app users establish SSL/TLS communications with 

https://play.google.com/store/apps/details?id=com.runtastic.android.me.lite 

19 See, e.g., https://developer.android.com/studio/build/index.html, Last accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
19, 2020) when downloading Adidas’s apps, as evidenced by the “https” in the 

code from being observed in transit from Google to the user’s remote system. The secure download process starts with a TLS handshake procedure which us

one asymmetric key pair. Specifically, user’s remote device negotiates with Go

for the handshake: 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Each of these algorithms necessitates generating one or more asymmetric key encrypting the mobile app download. For RSA and RSA _PSK, Google server generates an RSA public-private key pair

For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Google server generates 

key pair20. The user’s remote device also generates a second Diffie-Hellman pu

20 ECDH and ECDHE algorithms require generating at the server and the client, elliptical curve parameters that constitute a Diffie-Hellhttps://tools.ietf.org/html/rfc5246 page 49-52, https://tools.ietf.org/html/rfc7525 page 12, http://www.cse.hut.fi/fi/opinnot/T-110.5

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For DHE_DSS and DH_DSS, Google server generates a DSA public-private key p

remote device also generates a second Diffie-Hellman public-private key pair. For ECDH_ECDSA and ECDHE_ECDSA, Google server generates an ECDSA publiThe user’s remote device also generates a second Diffie-Hellman public-private 

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2897.pdf, http://www.networkworld.com/article/2268575/lahttp://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf, Implementing SSL / TLS Using Cryptography and PKI by Joshua DavieNetworks and Cybersecurity By Chwan-Hwa (John) Wu, J. David Irwin, ISBN 1466572140, 9781466572140, Page 1021, which state that ECDH requires generating a Diffie-Hellman public-private key pair, Last acc

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 50-51, Last accessed on Mar 19, 202

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

The generated asymmetric key pairs are then used to compute a shared maste

that it is resistant to observation during transit.

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For RSA and RSA _PSK, the RSA public-private key pair is used to encrypt a ran

user’s remote device to compute a master secret. Google uses the master secrdecrypt the downloaded mobile app according to the TLS protocol. For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Google server generates key pair21. The user’s remote device also generates a second Diffie-Hellman pu

and the user’s Diffie-Hellman public key to compute a premaster secret, and su

the user’s Diffie-Hellman private key and Google’s Diffie-Hellman public key to secret that Google uses to encrypt the mobile app and the user’s remote devic

protocol. For DHE_DSS and DH_DSS, Google server generates a DSA public-private key p

remote device also generates a second Diffie-Hellman public-private key pair. 

Hellman public key to compute a premaster secret, and subsequently compute 

Hellman private key and Google’s Diffie-Hellman public key to compute the samuses to encrypt the mobile app and the user’s remote device uses to decrypt thFor ECDH_ECDSA and ECDHE_ECDSA, Google server generates an ECDSA publi

The user’s remote device also generates a second Diffie-Hellman public-private user’s Diffie-Hellman public key to compute a premaster secret, and subsequeDiffie-Hellman private key and Google’s Diffie-Hellman public key to compute t

Google uses to encrypt the mobile app and the user’s remote device uses to de

3. Resistant to Modification Because Mobile App is Code Signed 

The downloaded mobile app code is resistant to modification, at least in part, 

allows users’ remote systems to verify that the downloaded app binary is auth

21 ECDH and ECDHE algorithms require generating at the server and the client, elliptical curve parameters that constitute a Diffie-Hellhttps://tools.ietf.org/html/rfc5246 page 49-52, https://tools.ietf.org/html/rfc7525 page 12, http://www.cse.hut.fi/fi/opinnot/T-110.5http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2897.pdf, http://www.networkworld.com/article/2268575/lahttp://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf, Implementing SSL / TLS Using Cryptography and PKI by Joshua DavieNetworks and Cybersecurity By Chwan-Hwa (John) Wu, J. David Irwin, ISBN 1466572140, 9781466572140, Page 1021, which state that ECDH requires generating a Diffie-Hellman public-private key pair, Last acc

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
dictates that each developer must sign the mobile app submission with his/he

modified by a third party impersonator22. 

Android requires that the user generates an asymmetric key all apps be 

uses this certificate to identify the author of an app Source: https://developer.android.com/studio/publish/app-signing.htm

A public-key certificate, also known as a digital certificate or an identity 

as some other metadata identifying the owner of the key (for example, corresponding private key. When you sign an APK, the signing tool attaches the public-key certificathat uniquely associates the APK to you and your corresponding private authentic and come from the original author. 

A keystore is a binary file that contains one or more private keys. When 

generate a new keystore and private key or use a keystore and private kSource: https://developer.android.com/studio/publish/app-signing.htm

Adidas complies with Google’s instructions on code signing as shown by Adidafiles CERT.SF and CERT.RSA in Adidas’s Android mobile apps which are generat

22 See, e.g., https://developer.android.com/tools/publishing/app-signing.html, Last accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: Contents of Runtastic Steps - Step Tracker & Pedometer(https://play.g

as an example of Adidas app, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: Contents of Runtastic Steps - Step Tracker & Pedometer(https://play.g

as an example of Adidas app, Last accessed on Mar 19, 2020 By signing the app binary with a digital signature, Adidas’s mobile apps are tam

verify that the application is being distributed by trusted source (i.e. Adidas) an

can be verified by the corresponding public key generated as part of the pair. T

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Accordingly Adidas’s Android mobile apps establish SSL/TLS communications w

involving asymmetric key encryption. SSL/TLS ensures secure communication a

4. Resistant to Observation Because Mobile App is Stored on Remote Sy

The mobile app is made further resistant to observation because when downloencrypted form. Android implements disk encryption for encrypting the operatwhich further renders Adidas app resistant to observation23. 

5. Resistant to Observation Because Mobile App Securely Communicate

Adidas’s mobile apps are made further resistant to observation, at least in partduring operation. Adidas app users establish SSL/TLS communications with Ad

necessary to keep source code as well as user identity and activity from being versa. The secure communications process starts with a TLS handshake procedure wh

least one asymmetric key pair. Specifically, user’s remote device negotiates wi

will be used for the handshake. 

23 See, e.g., https://source.android.com/security/encryption/, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Each of these algorithms necessitates generating one or more asymmetric key encrypting communication between Adidas and user’s remote device. For RSA and RSA _PSK, Adidas server generates an RSA public-private key pair

For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Adidas server generates a

key pair24. The user’s remote device also generates a second Diffie-Hellman pu

24 ECDH and ECDHE algorithms require generating at the server and the client, elliptical curve parameters that constitute a Diffie-Hellhttps://tools.ietf.org/html/rfc5246 page 49-52, https://tools.ietf.org/html/rfc7525 page 12, http://www.cse.hut.fi/fi/opinnot/T-110.5

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For DHE_DSS and DH_DSS, Adidas server generates a DSA public-private key p

remote device also generates a second Diffie-Hellman public-private key pair. For ECDH_ECDSA and ECDHE_ECDSA, Adidas server generates an ECDSA publiThe user’s remote device also generates a second Diffie-Hellman public-private 

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2897.pdf, http://www.networkworld.com/article/2268575/lahttp://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf, Implementing SSL / TLS Using Cryptography and PKI by Joshua DavieNetworks and Cybersecurity By Chwan-Hwa (John) Wu, J. David Irwin, ISBN 1466572140, 9781466572140, Page 1021, which state that ECDH requires generating a Diffie-Hellman public-private key pair, Last acc

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 50-51, Last accessed on Mar 19, 202

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

The generated asymmetric key pairs are then used to compute a shared maste

between Adidas and the user’s remote device so that they are resistant to obs

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For RSA and RSA _PSK, the RSA public-private key pair is used to encrypt a ran

user’s remote device to compute a master secret. Adidas and the user’s remotcommunication messages. For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Adidas server generates a

key pair25. The user’s remote device also generates a second Diffie-Hellman pu

and the user’s Diffie-Hellman public key to compute a premaster secret, and suthe user’s Diffie-Hellman private key and Google’s Diffie-Hellman public key to secret for encrypting and decrypting communication messages. For DHE_DSS and DH_DSS, Adidas server generates a DSA public-private key premote device also generates a second Diffie-Hellman public-private key pair. AHellman public key to compute a premaster secret, and subsequently compute Hellman private key and Google’s Diffie-Hellman public key to compute the samencrypting and decrypting communication messages. For ECDH_ECDSA and ECDHE_ECDSA, Adidas server generates an ECDSA publiThe user’s remote device also generates a second Diffie-Hellman public-private user’s Diffie-Hellman public key to compute a premaster secret, and subsequeDiffie-Hellman private key and Google’s Diffie-Hellman public key to compute t

encrypting and decrypting communication messages. 

9. The method of claim 1, wherein building the executable tamper resistant code module comprises generating an integrity verification kernel. 

Adidas’s mobile software application products and services including by way o“mobile apps” or “Accused Products”) that are specifically developed, used, so

downloaded onto Android mobile or tablet devices. 

25 ECDH and ECDHE algorithms require generating at the server and the client, elliptical curve parameters that constitute a Diffie-Hellhttps://tools.ietf.org/html/rfc5246 page 49-52, https://tools.ietf.org/html/rfc7525 page 12, http://www.cse.hut.fi/fi/opinnot/T-110.5http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2897.pdf, http://www.networkworld.com/article/2268575/lahttp://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf, Implementing SSL / TLS Using Cryptography and PKI by Joshua DavieNetworks and Cybersecurity By Chwan-Hwa (John) Wu, J. David Irwin, ISBN 1466572140, 9781466572140, Page 1021, which state that ECDH requires generating a Diffie-Hellman public-private key pair, Last acc

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
 Runtastic Steps - Step Tracker & Pedometer (https://play.google.com/

Mar 19, 2020 

 adidas Running App by Runtastic (https://play.google.com/store/apps/ adidas Training by Runtastic - Fitness Workouts (https://play.google.co

accessed on Mar 19, 2020 

Adidas directly infringes and/or continues to knowingly induce Google to infrinadvertising, providing, sending, distributing and licensing its mobile application

abetting, encouraging, promoting or inviting use thereof. Upon information and belief, the method step of generating an integrity verific

are attributable to Adidas (i) because Adidas works together with Google in a j

because Google distributes and markets Adidas’s mobile apps under the directthe building, marketing and distribution of Adidas’s mobile apps. Alternatively, to the extent any portion of this method step is performed by Adparticipation in and the receipt of a benefit, namely, the distribution of Adidasmandatory procedures and guidelines dictated by Google in the building and uGoogle in the building, marketing and distribution of Adidas’s mobile apps. The Court construed “integrity verification kernel” to mean “software that veri

and that is resistant to observation and modification.” When a mobile app is deployed on device, a hash algorithm is used to compute 

hashes in the hash manifest. Then, the hashes from the hash manifest are commatch, the digital signature is invalid and the application does not launch. Thus

image for the app, and this digital signature is supplied so that the mobile app 

The code for Android used to validate the digitally signed mobile app code is it

26 See, e.g., https://developer.android.com/studio/publish/app-signing.html, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Further, Android implements disk encryption for encrypting the operating syst

which renders the code for validating the digitally signed mobile app binary furFurther Android implements a secure boot functionality that verifies the opera

when the mobile device is powered on. If this verification fails, i.e. if the opera

not launch28. Thus, the software that verifies that a program image correspond

modification. 

27 See, e.g., https://source.android.com/security/encryption/, Last accessed on Mar 19, 2020 28 See, e.g., https://source.android.com/security/verifiedboot/ and http://www.zdnet.com/article/google-now-requires-full-device-e

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171208043438/https://source.android

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20170912153704/https://source.android

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Further Android implements a secure boot functionality that verifies the opera

when the mobile device is powered on. If this verification fails, i.e. if the operanot launch. 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171201215912/https://source.android

This verified boot became mandatory for Android 6.0 or later: https://source.android.com/compatibility/6.0/android-6.0-cdd, Last accessed 

10. The method of claim 9, wherein generating an integrity verification kernel comprises accessing an asymmetric public key of a 

Adidas’s mobile software application products and services including by way o“mobile apps” or “Accused Products”) that are specifically developed, used, so

downloaded onto Android mobile or tablet devices. 

29 See also http://www.tomshardware.com/news/marshmallow-encryption-fingerprints-verified-boot,30369.html, Last accessed on Mhttp://www.zdnet.com/article/google-now-requires-full-device-encryption-on-new-android-6-0-devices/, Last accessed on Mar 19, 2http://www.androidauthority.com/new-google-oem-marshmallow-requirements-650266/, Last accessed on Mar 19, 2020https://www.linuxsecrets.com/elinux-wiki/images/b/b2/Android_Verified_Boot.pdf, Last accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
predetermined asymmetric key pair 

associated with a manifest of the program signed by an asymmetric private key of the predetermined asymmetric key pair, producing integrity verification kernel code with the asymmetric public key for verifying the signed manifest of the program and combining manifest parser generator code and the integrity verification kernel code to produce the integrity verification kernel. 

 Runtastic Steps - Step Tracker & Pedometer (https://play.google.com/

Mar 19, 2020 

 adidas Running App by Runtastic (https://play.google.com/store/apps/ adidas Training by Runtastic - Fitness Workouts (https://play.google.co

accessed on Mar 19, 2020 

Adidas directly infringes and/or continues to knowingly induce Google to infrinadvertising, providing, sending, distributing and licensing its mobile application

abetting, encouraging, promoting or inviting use thereof. Upon information and belief, the method step of accessing an asymmetric pub

manifest of the program signed by an asymmetric private key of the predetermwith the asymmetric public key for verifying the signed manifest of the program 

verification kernel code to produce the integrity verification kernel is performe(i) because Adidas works together with Google in a joint enterprise in the build

distributes and markets Adidas’s mobile apps under the direction and control o

marketing and distribution of Adidas’s mobile apps.Alternatively, to the extent any portion of this method step is performed by Adparticipation in and the receipt of a benefit, namely, the distribution of Adidasmandatory procedures and guidelines dictated by Google in the building and u

Google in the building, marketing and distribution of Adidas’s mobile apps. The Court previously construed30 “integrity verification kernel” to mean “softwdigital signature and that is resistant to observation and modification” and “maverification kernel’s entry code, generator code, accumulator code, and other Android implements a secure boot functionality that verifies the operating sys

the mobile device is powered on. If this verification fails, i.e. if the operating sy

the mobile apps installed on the device, does not launch. Thus every time the accessing an asymmetric public key of a predetermined asymmetric key pair ascorresponding asymmetric private key by Google. This integrity verification ker

30 See Memorandum Opinion and Order, Document 104 signed by Judge Rodney Gilstrap on 7/21/2016 in re Plano Encryption Techno

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
parses a manifest associated with the operating system and code that verifies 

and has not been maliciously modified. Further, the software that performs the above verification is stored in a compiAdditionally, the software is digitally signed by Google with their asymmetric p

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171201215912/https://source.android

This verified boot became mandatory for Android 6.0 or later: https://source.android.com/compatibility/6.0/android-6.0-cdd, Last accessed 

31 See also http://www.tomshardware.com/news/marshmallow-encryption-fingerprints-verified-boot,30369.html, Last accessed on Mhttp://www.zdnet.com/article/google-now-requires-full-device-encryption-on-new-android-6-0-devices/, Last accessed on Mar 19, 2http://www.androidauthority.com/new-google-oem-marshmallow-requirements-650266/, Last accessed on Mar 19, 2020https://www.linuxsecrets.com/elinux-wiki/images/b/b2/Android_Verified_Boot.pdf, Last accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171208043438/https://source.android

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20170912153704/https://source.android

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://web.archive.org/web/20171203224317/https://source.androi

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://web.archive.org/web/20170912190232/https://source.androi

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
11. The method of claim 10, wherein 

the program comprises a trusted player and the method further comprises building a manifest for the trusted player, signing the manifest with the asymmetric private key of the predetermined asymmetric key pair, and storing the asymmetric public key of the predetermined asymmetric key pair. 

Adidas’s mobile software application products and services including by way o“mobile apps” or “Accused Products”) that are specifically developed, used, so

downloaded onto Android mobile or tablet devices. 

 Runtastic Steps - Step Tracker & Pedometer (https://play.google.com/

Mar 19, 2020 

 adidas Running App by Runtastic (https://play.google.com/store/apps/ adidas Training by Runtastic - Fitness Workouts (https://play.google.co

accessed on Mar 19, 2020 

Adidas directly infringes and/or continues to knowingly induce Google to infrinadvertising, providing, sending, distributing and licensing its mobile application

abetting, encouraging, promoting or inviting use thereof. Upon information and belief, the method step of building a manifest for the tr

the predetermined asymmetric key pair, and storing the asymmetric public key 

and/or its agents – whose acts are attributable to Adidas (i) because Adidas wodistribution of its mobile apps, or (ii) because Google distributes and markets Aas agent, or on behalf of Adidas, in the building, marketing and distribution of 

Alternatively, to the extent any portion of this method step is performed by Adparticipation in and the receipt of a benefit, namely, the distribution of Adidasmandatory procedures and guidelines dictated by Google in the building and uGoogle in the building, marketing and distribution of Adidas’s mobile apps. As explained in claim 10, Android implements a secure boot functionality that signed mobile apps, when the mobile device is powered on. If this verification 

operating system, along with the mobile apps installed on the device, does not 

system on a device before the device is sold to a user, Google builds a manifesthe manifest with their asymmetric private key and storing the corresponding 

operating system can be verified during device restart. 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171201215912/https://source.android

This verified boot became mandatory for Android 6.0 or later: https://source.android.com/compatibility/6.0/android-6.0-cdd, Last accessed 

34. A method of securely distributing data encrypted by a public key of an asymmetric key pair comprising: 

Adidas’s mobile software application products and services including by way o“mobile apps” or “Accused Products”) that are specifically developed, used, so

downloaded onto Android mobile or tablet devices. 

32 See also http://www.tomshardware.com/news/marshmallow-encryption-fingerprints-verified-boot,30369.html, Last accessed on Mhttp://www.zdnet.com/article/google-now-requires-full-device-encryption-on-new-android-6-0-devices/, Last accessed on Mar 19, 2http://www.androidauthority.com/new-google-oem-marshmallow-requirements-650266/, Last accessed on Mar 19, 2020https://www.linuxsecrets.com/elinux-wiki/images/b/b2/Android_Verified_Boot.pdf, Last accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
 Runtastic Steps - Step Tracker & Pedometer (https://play.google.com/

Mar 19, 2020 

 adidas Running App by Runtastic (https://play.google.com/store/apps/ adidas Training by Runtastic - Fitness Workouts (https://play.google.co

accessed on Mar 19, 2020 

Adidas directly infringes and/or continues to knowingly induce Google to infrinadvertising, providing, sending, distributing and licensing its mobile application

abetting, encouraging, promoting or inviting use thereof. To the extent any steps identified herein are performed by Google, such acts aGoogle in a joint enterprise in the building and distribution of its mobile apps, under the direction and control of Adidas, or acts as agent, or on behalf of Adid

apps.Alternatively, any steps or acts performed by Adidas, are attributable to Googl

the distribution of Adidas’s mobile apps through its app store, upon compliancGoogle in the building and upload of Adidas’s mobile apps, and Adidas induces 

Adidas’s mobile apps.To the extent the preamble is limiting, Adidas distributes data according to the In order to build and send the mobile app securely to the Google servers, Adid

securely distribute its mobile app to Adidas’s customers through the Google Pl(https://play.google.com/apps/publish/, Last accessed on Mar 19, 2020) estab

evidenced by the “https” in the URL. That process necessarily uses the public kto create a symmetric key for secure communications. 

building an executable tamper resistant key module identified for a selected program resident on a remote system, the executable tamper 

Relevant to this claim element is the Court’s previous construction33 of “executcode module” / “tamper resistant key module” to mean “software that is desig

33 See Memorandum Opinion and Order, Document 104 signed by Judge Rodney Gilstrap on 7/21/2016 in re Plano Encryption Techno

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
resistant key module including a 

private key of the asymmetric key pair and the encrypted data; and 

modification, and that includes a key for secure communication.” Also relevan“including” to compiling34. The method step of “building an executable tamper resistant key module iden

executable tamper resistant key module including a private key of the asymmeits agents. To the extent any portion of the method step is performed by Google and/or ittogether with Google in a joint enterprise in the building and distribution of its mobile apps under the direction and control of Adidas, or acts as agent, or on b

mobile apps. Building of an “executable tamper resistant code module” (that is, the mobile asymmetric key pairs: (1) An asymmetric key pair must be included in order to send the mobile a(2) An asymmetric key pair must be included by Adidas in order to digitally mobile app has not been changed with the public key for Android compatible mThe asymmetric key pair that is included to digitally sign the mobile app is diffesecurely upload the mobile app to the Google servers for distribution on the GThus, at least one asymmetric key pair is included having the claimed public kethe mobile app code can be sent uploaded to the Google servers using SSL/TLS pair used to digitally sign the app) is complementary as described below by pedata and/or creating and verifying signatures. As described in greater detail besecurely upload the mobile app onto the Google servers by SSL/TLS when build

claimed asymmetric key pair(s) and the encrypted data. 

34 Although the exact language construed from the previous claims is not at issue in claim 34, also relevant is the Court’s construction 

and 10 to mean “one or more asymmetric key pairs, one of the asymmetric key pairs having the claimed public key and claimed privaperforming complementary functions, such as encrypting and decrypting data or creating and verifying signatures.” While not necesskey and private key in claim 34 must perform complementary functions. 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Adidas uploads their mobile apps to Google using a TLS connection – which be

that allows Adidas and Google to exchange cryptographic parameters, includin

communication including upload of Adidas’s mobile apps to Google servers. A TLS handshake begins with Adidas sending a list of cipher suites supported bthe following key exchange algorithms: 

Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

For each of the key exchange algorithms, Adidas and/or Google build an execukey and the encrypted data. 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For RSA and RSA _PSK, the executable tamper resistant key module includes e

impossible for Adidas to send its mobile app to Google using SSL/TLS without etamper resistant key module also includes: 

1. Google’s RSA private key corresponding to Google’s RSA public key use

2. Adidas’s private key used to code-sign the mobile app. 

For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, the executable tamper rewith Google subsequent to the TLS handshake, including at least the executabl

name, category, screenshots and description related to Adidas’s mobile apps). 

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s RSA private key used to sign the message containing Google’s 4. Adidas’s private key used to code-sign the mobile app. 

For DHE_DSS and DH_DSS, the executable tamper resistant key module includ

the TLS handshake, including at least the executable compiled code related to and description related to Adidas’s mobile apps). The executable tamper resist

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s DSA private key used to sign the message containing Google’4. Adidas’s private key used to code-sign the mobile app. 

For ECDH_ECDSA and ECDHE_ECDSA, the executable tamper resistant key mo

subsequent to the TLS handshake, including at least the executable compiled ccategory, screenshots and description related to Adidas’s mobile apps). The ex

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s ECDSA private key used to sign the message containing Goog4. Adidas’s private key used to code-sign the mobile app. 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Adidas builds an executable tamper resistant key module identified for a select

mobile app, which is an executable tamper resistant key module, as explained program resident on a remote system, namely the Android operating system oThe mobile app comprises an executable tamper resistant key module that is i

described above and the encrypted data encrypted with the claimed public key made available for download from Google servers onto devices compatible wit

asymmetric key pair is used not only to upload the binary code files for the mometadata for the app, such as title, screenshots, and other resources or inform

during the upload process so that the mobile app can be identified by potentia

Adidas’s mobile app is each an executable tamper resistant key module becausoperating system as well as other applications or programs installed on a user’and modification, as explained below; and because in building Adidas mobile a

generated private key and the encrypted data including by way of example, thwhen the mobile app is securely uploaded onto the Google servers as describeThe tamper resistant key module includes several keys “used for secure commfollowing: For RSA and RSA _PSK: 

1. Google’s RSA private key corresponding to Google’s RSA public key use2. Adidas’s private key used to code-sign the mobile app. 3. Symmetric key used for uploading the mobile app to Google subseque4. Asymmetric keys and symmetric keys used for TLS communications du

For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA: 

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s RSA private key used to sign the message containing Google’s 4. Adidas’s private key used to code-sign the mobile app. 5. Shared master secret key used for uploading the mobile app to Google 

35 See, e.g., https://developer.android.com/studio/publish/index.html, Last accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
6. Asymmetric keys and symmetric keys used for TLS communications du

For DHE_DSS and DH_DSS: 

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s DSA private key used to sign the message containing Google’4. Adidas’s private key used to code-sign the mobile app. 5. Shared master secret key used for uploading the mobile app to Google 6. Asymmetric keys and symmetric keys used for TLS communications du

For ECDH_ECDSA and ECDHE_ECDSA: 

1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

secret. 

2. Adidas’s Diffie-Hellman private key used to compute the shared maste3. Google’s ECDSA private key used to sign the message containing Goog4. Adidas’s private key used to code-sign the mobile app. 5. Shared master secret key used for uploading the mobile app to Google 6. Asymmetric keys and symmetric keys used for TLS communications du

Adidas’s mobile apps are tamper resistant, resistant to observation and modifi

1. Resistant to Observation Because App Source Code Is Compiled Befo

Adidas mobile apps are resistant to observation, at least in part, since Adidas cGoogle – and uploads the binary output of the compilation process rather than 

See, Android Studio Users Guide, “Prepare for Release” stating “To release you

users can install and run on their Android-powered devices. The release-ready 

compiled source code, resources, manifest file, and so on — and it is built usin

36 See, e.g., https://developer.android.com/studio/build/index.html, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
release-ready APK file is signed with your own certificate and it is optimized wi

https://developer.android.com/studio/publish/preparing.html, Last accessed o

2. Resistant to Observation Because Upload To Google Is Over SSL/TLS 

Adidas’s mobile apps are made further resistant to observation, at least in partof the building process. Android Developer Console (https://play.google.com/a

communications when uploading Adidas’s apps, as evidenced by the “https” in the code from being observed in transit from the code developer to Google. The secure upload process starts with a TLS handshake procedure which uses a

asymmetric key pair. Specifically, Adidas negotiates with Google the cipher sui

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

For each of the above key exchange algorithms, Google and/or Adidas encrypt

master secret, rendering the communication resistant to observation during tr

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For RSA and RSA _PSK, Adidas encrypts a random premaster secret with Goog

Google. Google decrypts the premaster secret with its matched RSA private kemaster secret which is then used by both Adidas and Google to encrypt all subFor the other key exchange algorithms, namely Diffie-Hellman based algorithmECDH_RSA, ECDH_ECDSA and ECDHE_ECDSA, Adidas sends its Diffie-Hellman to Adidas. Adidas then uses Google’s Diffie-Hellman public key combined with 

secret. Google in turn uses Adidas’s Diffie-Hellman public key combined with Gpremaster secret. Adidas and Google both use the premaster secret to computencrypt all subsequent communications between Adidas and Google. 

3. Resistant to Modification Because App Binary Is Code Signed 

The mobile app code is made resistant to modification, at least in part, becausmust sign the mobile app submission with his/her asymmetric developer key timpersonator38. 

Android requires that the user generates an asymmetric key all apps be 

uses this certificate to identify the author of an app Source: https://developer.android.com/studio/publish/app-signing.htm

A public-key certificate, also known as a digital certificate or an identity 

as some other metadata identifying the owner of the key (for example, corresponding private key. When you sign an APK, the signing tool attaches the public-key certificathat uniquely associates the APK to you and your corresponding private authentic and come from the original author. 

A keystore is a binary file that contains one or more private keys. When 

generate a new keystore and private key or use a keystore and private k

37 For Diffie-Hellman (DH) based algorithms such as DH_RSA, DHE_RSA, ECDH_RSA, ECDHE_RSA, DH_DSS, DHE_DSS, ECDH_ECDSA and 

Diffie-Hellman public key and encrypts the hash with their RSA/DSA/ECDSA private key (i.e. signing the message). Google then sends tRuntastic can authenticate the Google server by decrypting the hash using Google’s public key and matching the decryption result to values match, Runtastic knows that the message originated from Google and not from a malicious third party. 38 See, e.g., https://developer.android.com/tools/publishing/app-signing.html, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://developer.android.com/studio/publish/app-signing.htm

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171107004101/https://develop

accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171107004101/https://develop

accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: http://web.archive.org/web/20171107004101/https://develop

accessed on Mar 19, 2020 

Adidas complies with Google’s instructions on code signing as shown by Adidafiles CERT.SF and CERT.RSA in Adidas’s Android apps which are generated durinSource: Contents of Runtastic Steps - Step Tracker & Pedometer(https://play.g

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
as an example of Adidas app, Last accessed on Mar 19, 2020 

Source: Contents of Runtastic Steps - Step Tracker & Pedometer(https://play.gas an example of Adidas app, Last accessed on Mar 19, 2020 Asymmetrical key cryptography and hashing algorithms are used to create the is used to sign the resources in an application package, including the compiled 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
the digital code signing is used to code sign the app. This private key is include

key of the claimed generated asymmetric key pair because it does not match tconstruction. Hashes are created for every resource in the application package with the help prevent unauthorized changes. The hashes are encrypted with a private key. A

created. By signing the app binary with a digital signature, Adidas’s mobile apps are tam

verify that the application is being distributed by trusted source (i.e. Adidas) an

can be verified by the corresponding public key generated as part of the pair. T

Accordingly Adidas’s Android mobile apps establish SSL/TLS communications winvolving asymmetric key encryption. SSL/TLS ensures secure communication a

sending the executable tamper resistant key module to the remote system. 

Upon information and belief, the method step of sending the executable tamp

and/or its agents – whose acts are attributable to Adidas (i) because Adidas wo

distribution of its mobile apps, or (ii) because Google distributes and markets Aas agent, or on behalf of Adidas, in the building, marketing and distribution of Alternatively, to the extent any portion of this method step is performed by Adparticipation in and the receipt of a benefit, namely, the distribution of Adidasmandatory procedures and guidelines dictated by Google in the building and uGoogle in the building, marketing and distribution of Adidas’s mobile apps. 

Adidas’s mobile apps are sent or downloaded from Google servers and are exe

When a user accesses Google Play Store – and requests to download Adidas ap

Google servers to the remote device(s). Further, the step of “sending” Adidas mobile apps to the remote system occur

apps, to the extent required by the claims, also includes a private key and data In particular, Adidas mobile apps sent to users’ remote devices are tamper res

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
1. Resistant to Observation Because App is Downloaded in Compiled Fo

Adidas mobile apps are resistant to observation, at least in part, since Adidas c

Google – and uploads the binary output of the compilation process rather than compiled source code from Google rather than the source code itself39.

See, Android Studio Users Guide, “Prepare for Release” stating “To release you

users can install and run on their Android-powered devices. The release-ready compiled source code, resources, manifest file, and so on — and it is built usinrelease-ready APK file is signed with your own certificate and it is optimized wi

https://developer.android.com/studio/publish/preparing.html, Last accessed o

2. Resistant to Observation Because Download from Google Is Over SSL

Adidas’s mobile apps are made further resistant to observation, at least in partfrom Google servers. Adidas app users establish SSL/TLS communications with 

https://play.google.com/store/apps/details?id=com.runtastic.android.me.lite 19, 2020) when downloading Adidas’s apps, as evidenced by the “https” in the 

code from being observed in transit from Google to the user’s remote system. The secure download process starts with a TLS handshake procedure which us

one asymmetric key pair. Specifically, user’s remote device negotiates with Go

for the handshake: 

39 See, e.g., https://developer.android.com/studio/build/index.html, Last accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Each of these algorithms necessitates generating one or more asymmetric key encrypting the mobile app download. For RSA and RSA _PSK, Google server generates an RSA public-private key pair

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Google server generates 

key pair40. The user’s remote device also generates a second Diffie-Hellman puFor DHE_DSS and DH_DSS, Google server generates a DSA public-private key premote device also generates a second Diffie-Hellman public-private key pair. For ECDH_ECDSA and ECDHE_ECDSA, Google server generates an ECDSA publiThe user’s remote device also generates a second Diffie-Hellman public-private 

40 ECDH and ECDHE algorithms require generating at the server and the client, elliptical curve parameters that constitute a Diffie-Hellhttps://tools.ietf.org/html/rfc5246 page 49-52, https://tools.ietf.org/html/rfc7525 page 12, http://www.cse.hut.fi/fi/opinnot/T-110.5http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2897.pdf, http://www.networkworld.com/article/2268575/lahttp://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf, Implementing SSL / TLS Using Cryptography and PKI by Joshua DavieNetworks and Cybersecurity By Chwan-Hwa (John) Wu, J. David Irwin, ISBN 1466572140, 9781466572140, Page 1021, which state that ECDH requires generating a Diffie-Hellman public-private key pair, Last acc

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 50-51, Last accessed on Mar 19, 202

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

The generated asymmetric key pairs are then used to compute a shared maste

that it is resistant to observation during transit.

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For RSA and RSA _PSK, the RSA public-private key pair is used to encrypt a ran

user’s remote device to compute a master secret. Google uses the master secrdecrypt the downloaded mobile app according to the TLS protocol. For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Google server generates key pair41. The user’s remote device also generates a second Diffie-Hellman pu

and the user’s Diffie-Hellman public key to compute a premaster secret, and su

the user’s Diffie-Hellman private key and Google’s Diffie-Hellman public key to secret that Google uses to encrypt the mobile app and the user’s remote devic

protocol. For DHE_DSS and DH_DSS, Google server generates a DSA public-private key p

remote device also generates a second Diffie-Hellman public-private key pair. 

Hellman public key to compute a premaster secret, and subsequently compute 

Hellman private key and Google’s Diffie-Hellman public key to compute the samuses to encrypt the mobile app and the user’s remote device uses to decrypt thFor ECDH_ECDSA and ECDHE_ECDSA, Google server generates an ECDSA publi

The user’s remote device also generates a second Diffie-Hellman public-private user’s Diffie-Hellman public key to compute a premaster secret, and subsequeDiffie-Hellman private key and Google’s Diffie-Hellman public key to compute t

Google uses to encrypt the mobile app and the user’s remote device uses to de

3. Resistant to Modification Because Mobile App is Code Signed 

The downloaded mobile app code is resistant to modification, at least in part, 

allows users’ remote systems to verify that the downloaded app binary is auth

41 ECDH and ECDHE algorithms require generating at the server and the client, elliptical curve parameters that constitute a Diffie-Hellhttps://tools.ietf.org/html/rfc5246 page 49-52, https://tools.ietf.org/html/rfc7525 page 12, http://www.cse.hut.fi/fi/opinnot/T-110.5http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2897.pdf, http://www.networkworld.com/article/2268575/lahttp://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf, Implementing SSL / TLS Using Cryptography and PKI by Joshua DavieNetworks and Cybersecurity By Chwan-Hwa (John) Wu, J. David Irwin, ISBN 1466572140, 9781466572140, Page 1021, which state that ECDH requires generating a Diffie-Hellman public-private key pair, Last acc

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
dictates that each developer must sign the mobile app submission with his/he

modified by a third party impersonator42. 

Android requires that the user generates an asymmetric key all apps be 

uses this certificate to identify the author of an app Source: https://developer.android.com/studio/publish/app-signing.htm

A public-key certificate, also known as a digital certificate or an identity 

as some other metadata identifying the owner of the key (for example, corresponding private key. When you sign an APK, the signing tool attaches the public-key certificathat uniquely associates the APK to you and your corresponding private authentic and come from the original author. 

A keystore is a binary file that contains one or more private keys. When 

generate a new keystore and private key or use a keystore and private kSource: https://developer.android.com/studio/publish/app-signing.htm

Adidas complies with Google’s instructions on code signing as shown by Adidafiles CERT.SF and CERT.RSA in Adidas’s Android mobile apps which are generat

42 See, e.g., https://developer.android.com/tools/publishing/app-signing.html, Last accessed on Mar 19, 2020

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: Contents of Runtastic Steps - Step Tracker & Pedometer(https://play.g

as an example of Adidas app, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: Contents of Runtastic Steps - Step Tracker & Pedometer(https://play.g

as an example of Adidas app, Last accessed on Mar 19, 2020 By signing the app binary with a digital signature, Adidas’s mobile apps are tam

verify that the application is being distributed by trusted source (i.e. Adidas) an

can be verified by the corresponding public key generated as part of the pair. T

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Accordingly Adidas’s Android mobile apps establish SSL/TLS communications w

involving asymmetric key encryption. SSL/TLS ensures secure communication a

4. Resistant to Observation Because Mobile App is Stored on Remote Sy

The mobile app is made further resistant to observation because when downloencrypted form. Android implements disk encryption for encrypting the operatwhich further renders Adidas app resistant to observation43. 

5. Resistant to Observation Because Mobile App Securely Communicate

Adidas’s mobile apps are made further resistant to observation, at least in partduring operation. Adidas app users establish SSL/TLS communications with Ad

necessary to keep source code as well as user identity and activity from being versa. The secure communications process starts with a TLS handshake procedure wh

least one asymmetric key pair. Specifically, user’s remote device negotiates wi

will be used for the handshake. 

43 See, e.g., https://source.android.com/security/encryption/, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

Each of these algorithms necessitates generating one or more asymmetric key encrypting communication between Adidas and user’s remote device. For RSA and RSA _PSK, Adidas server generates an RSA public-private key pair

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Adidas server generates a

key pair44. The user’s remote device also generates a second Diffie-Hellman puFor DHE_DSS and DH_DSS, Adidas server generates a DSA public-private key p

remote device also generates a second Diffie-Hellman public-private key pair. For ECDH_ECDSA and ECDHE_ECDSA, Adidas server generates an ECDSA publiThe user’s remote device also generates a second Diffie-Hellman public-private 

44 ECDH and ECDHE algorithms require generating at the server and the client, elliptical curve parameters that constitute a Diffie-Hellhttps://tools.ietf.org/html/rfc5246 page 49-52, https://tools.ietf.org/html/rfc7525 page 12, http://www.cse.hut.fi/fi/opinnot/T-110.5http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2897.pdf, http://www.networkworld.com/article/2268575/lahttp://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf, Implementing SSL / TLS Using Cryptography and PKI by Joshua DavieNetworks and Cybersecurity By Chwan-Hwa (John) Wu, J. David Irwin, ISBN 1466572140, 9781466572140, Page 1021, which state that ECDH requires generating a Diffie-Hellman public-private key pair, Last acc

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 2020 

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 50-51, Last accessed on Mar 19, 202

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
Source: The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246

The generated asymmetric key pairs are then used to compute a shared maste

between Adidas and the user’s remote device so that they are resistant to obs

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20 
For RSA and RSA _PSK, the RSA public-private key pair is used to encrypt a ran

user’s remote device to compute a master secret. Adidas and the user’s remotcommunication messages. For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Adidas server generates a

key pair45. The user’s remote device also generates a second Diffie-Hellman pu

and the user’s Diffie-Hellman public key to compute a premaster secret, and suthe user’s Diffie-Hellman private key and Google’s Diffie-Hellman public key to secret for encrypting and decrypting communication messages. For DHE_DSS and DH_DSS, Adidas server generates a DSA public-private key premote device also generates a second Diffie-Hellman public-private key pair. AHellman public key to compute a premaster secret, and subsequently compute Hellman private key and Google’s Diffie-Hellman public key to compute the samencrypting and decrypting communication messages. For ECDH_ECDSA and ECDHE_ECDSA, Adidas server generates an ECDSA publiThe user’s remote device also generates a second Diffie-Hellman public-private user’s Diffie-Hellman public key to compute a premaster secret, and subsequeDiffie-Hellman private key and Google’s Diffie-Hellman public key to compute t

encrypting and decrypting communication messages. 

45 ECDH and ECDHE algorithms require generating at the server and the client, elliptical curve parameters that constitute a Diffie-Hellhttps://tools.ietf.org/html/rfc5246 page 49-52, https://tools.ietf.org/html/rfc7525 page 12, http://www.cse.hut.fi/fi/opinnot/T-110.5http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2897.pdf, http://www.networkworld.com/article/2268575/lahttp://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf, Implementing SSL / TLS Using Cryptography and PKI by Joshua DavieNetworks and Cybersecurity By Chwan-Hwa (John) Wu, J. David Irwin, ISBN 1466572140, 9781466572140, Page 1021, which state that ECDH requires generating a Diffie-Hellman public-private key pair, Last acc

Case 1:20-cv-00401-RP Document 1-2 Filed 04/16/20