Exhibit 2b

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 Page 1 of 109
Infringement Contentions – Evernote Corporation’s A

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

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

Evernote Corporation’s mobile software application products and services incl

(“mobile applications”, “mobile apps” or “Accused Products”) that are specific

distributed by Evernote Corporation to be downloaded onto Android mobile o

 Evernote - Notes Organizer & Daily Planner (https://play.google.com/s

19, 2020 

Evernote Corporation directly infringes and/or continues to knowingly induce Gmarketing, advertising, providing, sending, distributing and licensing its mobile and aiding, abetting, encouraging, promoting or inviting use thereof. To the extent any steps identified herein are performed by Google, such acts a

Corporation works together with Google in a joint enterprise in the building anmarkets Evernote Corporation’s mobile apps under the direction and control oCorporation, in the building, marketing and distribution of Evernote CorporatioAlternatively, any steps or acts performed by Evernote Corporation, are attribu

benefit, namely, the distribution of Evernote Corporation’s mobile apps througand guidelines dictated by Google in the building and upload of Evernote Corpby Google in the building, marketing and distribution of Evernote Corporation’To the extent the preamble is limiting, Evernote Corporation distributes data aIn order to build and send the mobile app securely to the Google servers, Ever

order to securely distribute its mobile app to Evernote Corporation’s customerCorporation registers with the Android Developer Console (https://play.google

securely upload Evernote Corporation’s apps onto the Google app store, Goog

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Source: https://support.google.com/googleplay/android-developer/answer/61

Case 1:20-cv-00403-RP Document 1-3 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 Evernote Corporation (i) becenterprise in the building and distribution of its mobile apps, or (ii) because Gounder the direction and control of Evernote Corporation, or acts as agent, or odistribution of Evernote Corporation’s mobile apps.Alternatively, to the extent any portion of this method step is performed by Ev

conditions participation in and the receipt of a benefit, namely, the distributio

compliance with certain mandatory procedures and guidelines dictated by Goo

and Evernote Corporation induces infringement by Google in the building, marEvernote Corporation uploads their mobile apps to Google using a TLS connectmandatory procedure that allows Evernote Corporation and Google to exchangshared master secret for encrypting communication including upload of EvernoA TLS handshake begins with Evernote Corporation sending a list of cipher suit

specify at least one or more of the 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-00403-RP Document 1-3 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-00403-RP Document 1-3 Filed 04/16/20 
For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Google server generates 

public-private key pair2. Evernote Corporation also generates a second Diffie-H

key are complementary by performing complementary functions, such as creat

Diffie-Hellman private key are also complementary by performing complemenper the Diffie-Hellman key exchange algorithm, Evernote Corporation uses Goo

own Diffie-Hellman private key to compute a premaster secret and thereon a mCorporation’s Diffie-Hellman public key combined with Google’s own Diffie-Hemaster secret for decrypting encrypted data from Evernote Corporation. Convcombined with Google’s own Diffie-Hellman private key to compute a premast

Corporation uses Google’s Diffie-Hellman public key combined with Evernote C

secret and thereon a master secret for decrypting encrypted data from Google

For DHE_DSS and DH_DSS, Google server generates a DSA public-private key pCorporation also generates a second Diffie-Hellman public-private key pair. Thperforming complementary functions, such as creating and verifying signature

also complementary by performing complementary functions, such as encrypt

exchange algorithm, Evernote Corporation uses Google’s Diffie-Hellman public key to compute a premaster secret and thereon a master secret5 for encryptinpublic key combined with Google’s own Diffie-Hellman private key to compute encrypted data from Evernote Corporation. Conversely, Google uses Evernote 

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-00403-RP Document 1-3 Filed 04/16/20 
Diffie-Hellman private key to compute a premaster secret and thereon, a mast

Diffie-Hellman public key combined with Evernote Corporation’s own Diffie-He

master secret for decrypting encrypted data from Google. For ECDH_ECDSA and ECDHE_ECDSA, a Google server generates an ECDSA pubEvernote Corporation also generates a second Diffie-Hellman public-private kecomplementary by performing complementary functions, such as creating and Hellman private key are also complementary by performing complementary futhe Diffie-Hellman key exchange algorithm, Evernote Corporation uses Googleown Diffie-Hellman private key to compute a premaster secret and thereon a mCorporation’s Diffie-Hellman public key combined with Google’s own Diffie-Hemaster secret for decrypting encrypted data from Evernote Corporation. Convcombined with Google’s own Diffie-Hellman private key to compute a premast

Corporation uses Google’s Diffie-Hellman public key combined with Evernote C

secret and thereon a master secret for decrypting encrypted data from Google

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-00403-RP Document 1-3 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

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

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

In addition, Evernote Corporation and/or Google also generate additional asym

during TLS communications 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-00403-RP Document 1-3 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 build

claimed 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 dCorporation and/or its agents. To the extent any portion of the method step is performed by Google and/or itbecause Evernote Corporation works together with Google in a joint enterprise 

Google distributes and markets Evernote Corporation’s mobile apps under the behalf of Evernote Corporation, in the building, marketing and distribution of E

When Evernote Corporation uploads its mobile apps to Google, it connects to G

Evernote Corporation perform a TLS handshake procedure which uses asymme

asymmetric key pair. Specifically, Evernote Corporation negotiates with Google the handshake. 

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-00403-RP Document 1-3 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 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
 a certificate with signing ability, a digitally-signed 

 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.) 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
 master secret 

 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, Evernote Corporation and Google negotiate a key exchang

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Case 1:20-cv-00403-RP Document 1-3 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 Evernote CorpoFor RSA and RSA _PSK, Evernote Corporation encrypts a random premaster se

secret to Google. Google decrypts the premaster secret with its matched RSA psecret to compute a master secret which is then used by both Evernote Corpor

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Evernote Corporation and Google. Therefore, when any of RSA and RSA _PSK 

encrypts predetermined data (i.e. the premaster secret) with the generated pu

For the other key exchange algorithms, namely Diffie-Hellman based algorithmECDH_RSA, ECDH_ECDSA and ECDHE_ECDSA, Evernote Corporation sends its D

Hellman public key to Evernote Corporation. Evernote Corporation then uses G

Corporation’s own Diffie-Hellman private key to compute a premaster secret. G

combined with Google’s own Diffie-Hellman private key to compute the same 

premaster secret to compute a master secret10 which is then used by both Eve

communications between Evernote Corporation and Google. Therefore, when any of the Diffie-Hellman based key exchange algorithms are 

predetermined data, i.e. all communication with Google subsequent to the TLS its mobile apps and information such as name, category, screenshots and descgenerated public key, i.e. Google’s Diffie-Hellman public key, since the master 

Google’s Diffie-Hellman public key and Evernote Corporation’s Diffie-Hellman 

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 Evernote Corporation uses for uplokey, i.e. Evernote Corporation’s Diffie-Hellman public key, since the master secEvernote Corporation’s Diffie-Hellman public key and Google’s Diffie-Hellman 

and building an executable tamper resistant key module identified for a 

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 tso that Evernote Corporation can authenticate the Google server by decrypting the hash using Google’s public key and matching the d

Corporation itself. If the two values match, Evernote Corporation knows that the message originated from Google and not from a ma

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-00403-RP Document 1-3 Filed 04/16/20 
selected program, the executable 

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 it

because Evernote Corporation works together with Google in a joint enterprise 

Google distributes and markets Evernote Corporation’s mobile apps under the behalf of Evernote Corporation, in the building, marketing and distribution of E

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 Evernote Corporation in oto verify the mobile app has not been changed with the public key for Android 

The asymmetric key pair that is included to digitally sign the mobile app is diffe

securely 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 ke

the 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. Evernote Corporation uploads their mobile apps to Google using a TLS connect

mandatory procedure that allows Evernote Corporation and Google to exchang

shared master secret for encrypting communication including upload of Everno

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-00403-RP Document 1-3 Filed 04/16/20 
A TLS handshake begins with Evernote Corporation sending a list of cipher suit

specify at least one or more of the following key exchange algorithms: 

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
For each of the key exchange algorithms, Evernote Corporation and/or Google 

generated private key and the encrypted predetermined data. 

For RSA and RSA _PSK, the executable tamper resistant key module includes e

it would be impossible for Evernote Corporation to send its mobile app to Goo

to Google. The executable tamper resistant key module also includes: 

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

2. Evernote Corporation’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 lea

information such as name, category, screenshots and description related to Evkey module also includes: 

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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s RSA private key used to sign the message containing Google’s 4. Evernote Corporation’s private key used to code-sign the mobile app. 

For DHE_DSS and DH_DSS, the executable tamper resistant key module includsubsequent to the TLS handshake, including at least the executable compiled ccategory, screenshots and description related to Evernote Corporation’s mobil

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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s DSA private key used to sign the message containing Google’

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

For ECDH_ECDSA and ECDHE_ECDSA, the executable tamper resistant key mowith Google subsequent to the TLS handshake, including at least the executabl

name, category, screenshots and description related to Evernote Corporation’

includes: 

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

shared master secret. 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
2. Evernote Corporation’s Diffie-Hellman private key used to compute th

3. Google’s ECDSA private key used to sign the message containing Goog

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

Evernote Corporation builds an executable tamper resistant key module identi

Evernote Corporation builds a mobile app, which is an executable tamper resisidentified for a selected program resident on a remote system, namely the And

The mobile app comprises an executable tamper resistant key module that is idescribed above and the encrypted predetermined data encrypted with the clathat it can be made available for download from Google servers onto devices cEvernote Corporation. An asymmetric key pair is used not only to upload the bincluding all of the metadata for the app, such as title, screenshots, and other which are included during the upload process so that the mobile app can be idEvernote Corporation’s mobile app is each an executable tamper resistant key the Android operating system as well as other applications or programs installeobservation and modification, as explained below; and because in building EveCorporation’s apps include at least the claimed generated private key and the 

master secret encrypted with the claimed generated public key when the mobabove. 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. Evernote Corporation’s private key used to code-sign the mobile app. 3. Symmetric key used for uploading the mobile app to Google subseque

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

For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA: 

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
1. Google’s Diffie-Hellman private key corresponding to Google’s Diffie-H

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s RSA private key used to sign the message containing Google’s 4. Evernote Corporation’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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s DSA private key used to sign the message containing Google’

4. Evernote Corporation’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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s ECDSA private key used to sign the message containing Goog

4. Evernote Corporation’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

Evernote Corporation’s mobile apps are tamper resistant, resistant to observat

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Evernote Corporation mobile apps are resistant to observation, at least in part

before submitting the app to Google – and uploads the binary output of the co

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 

Evernote Corporation’s mobile apps are made further resistant to observation, 

Google as part of the building process. Android Developer Console (https://pla

establishes SSL/TLS communications when uploading Evernote Corporation’s acode by SSL/TLS is necessary to keep the code from being observed in transit fThe secure upload process starts with a TLS handshake procedure which uses a

asymmetric key pair. Specifically, Evernote Corporation negotiates with Google 

the handshake. 

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

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Case 1:20-cv-00403-RP Document 1-3 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 Evernote Corpo

app, using a master secret, rendering the communication resistant to observatFor RSA and RSA _PSK, Evernote Corporation encrypts a random premaster se

secret to Google. Google decrypts the premaster secret with its matched RSA p

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
secret to compute a master secret which is then used by both Evernote Corpor

Evernote Corporation and Google. For the other key exchange algorithms, namely Diffie-Hellman based algorithmECDH_RSA, ECDH_ECDSA and ECDHE_ECDSA, Evernote Corporation sends its DHellman public key to Evernote Corporation. Evernote Corporation then uses GCorporation’s own Diffie-Hellman private key to compute a premaster secret. G

combined with Google’s own Diffie-Hellman private key to compute the same 

premaster secret to compute a master secret which is then used by both Everncommunications between Evernote Corporation 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, becaus

must sign the mobile app submission with his/her asymmetric developer key t

impersonator18. 

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 tso that Evernote Corporation can authenticate the Google server by decrypting the hash using Google’s public key and matching the dCorporation itself. If the two values match, Evernote Corporation knows that the message originated from Google and not from a ma

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

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

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

accessed on Mar 19, 2020 

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

accessed on Mar 19, 2020

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

accessed on Mar 19, 2020

Evernote Corporation complies with Google’s instructions on code signing as s

Corporation’s mobile apps contain files such as the files CERT.SF and CERT.RSA the code signing process as per instructions from Google. 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Source: Contents of Evernote - Notes Organizer & Daily Planner (https://play.g

accessed on Mar 19, 2020) as an example of Evernote Corporation app 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Source: Contents of Evernote - Notes Organizer & Daily Planner (https://play.g

accessed on Mar 19, 2020) as an example of Evernote Corporation app 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 includekey of the claimed generated asymmetric key pair because it does not match tthe 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, Evernote Corporation’s mobdevices to verify that the application is being distributed by trusted source (i.e. 

by a third party, which can be verified by the corresponding public key generatmodification by digital signing. Accordingly Evernote Corporation’s Android mobile apps establish SSL/TLS com

SSL/TLS handshake procedure involving asymmetric key encryption. SSL/TLS enresistant to observation. 

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. 

Evernote Corporation’s mobile software application products and services incl

(“mobile applications”, “mobile apps” or “Accused Products”) that are specific

distributed by Evernote Corporation to be downloaded onto Android mobile o

 Evernote - Notes Organizer & Daily Planner (https://play.google.com/s

19, 2020) 

Evernote Corporation directly infringes and/or continues to knowingly induce Gmarketing, advertising, providing, sending, distributing and licensing its mobile and aiding, abetting, encouraging, promoting or inviting use thereof. 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Upon information and belief, the method step of sending the executable tamp

and/or its agents – whose acts are attributable to Evernote Corporation (i) becenterprise in the building and distribution of its mobile apps, or (ii) because Go

under the direction and control of Evernote Corporation, or acts as agent, or o

distribution of Evernote Corporation’s mobile apps.Alternatively, to the extent any portion of this method step is performed by Ev

conditions participation in and the receipt of a benefit, namely, the distributiocompliance with certain mandatory procedures and guidelines dictated by Gooand Evernote Corporation induces infringement by Google in the building, marEvernote Corporation’s mobile apps are sent or downloaded from Google servphones and tablets. When a user accesses Google Play Store – and requests to 

tamper resistant key module from the Google servers to the remote device(s). 

Further, the step of “sending” Evernote Corporation mobile apps to the remot

Evernote Corporation mobile apps, to the extent required by the claims, also inkey, as explained in detail above. In particular, Evernote Corporation mobile apps sent to users’ remote devices follows: 

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

Evernote Corporation mobile apps are resistant to observation, at least in partbefore submitting the app to Google – and uploads the binary output of the co

user can only download the compiled source code from Google rather than the 

See, Android Studio Users Guide, “Prepare for Release” stating “To release youusers 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

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

Case 1:20-cv-00403-RP Document 1-3 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 Download from Google Is Over SSL

Evernote Corporation’s mobile apps are made further resistant to observation, 

downloaded by SSL/TLS from Google servers. Evernote Corporation app users 

the URL https://play.google.com/store/apps/details?id=com.evernote&hl=en_

team projects) when downloading Evernote Corporation’s apps, as evidenced necessary to keep the code from being observed in transit from Google to the 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-00403-RP Document 1-3 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-00403-RP Document 1-3 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 publi

The 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-00403-RP Document 1-3 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Case 1:20-cv-00403-RP Document 1-3 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-00403-RP Document 1-3 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 secr

decrypt 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 puand 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 devicprotocol. 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-00403-RP Document 1-3 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

Evernote Corporation complies with Google’s instructions on code signing as s

Corporation’s mobile apps contain files such as the files CERT.SF and CERT.RSA during the code signing process as per instructions from Google. 

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Source: Contents of Evernote - Notes Organizer & Daily Planner (https://play.g

accessed on Mar 19, 2020) as an example of Evernote Corporation app 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Source: Contents of Evernote - Notes Organizer & Daily Planner (https://play.g

accessed on Mar 19, 2020) as an example of Evernote Corporation app By signing the app binary with a digital signature, Evernote Corporation’s mobdevices to verify that the application is being distributed by trusted source (i.e. 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
by a third party, which can be verified by the corresponding public key generat

modification by digital signing. Accordingly Evernote Corporation’s Android mobile apps establish SSL/TLS com

SSL/TLS handshake procedure involving asymmetric key encryption. SSL/TLS en

resistant to observation. 

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 operat

which further renders Evernote Corporation app resistant to observation23. 

5. Resistant to Observation Because Mobile App Securely Communicate

Evernote Corporation’s mobile apps are made further resistant to observation, 

Corporation using SSL/TLS during operation. Evernote Corporation app users ewhen the app is executed. Such secure communication is necessary to keep sotransit from the remote system to Evernote Corporation servers and vice versa

The secure communications process starts with a TLS handshake procedure whleast one asymmetric key pair. Specifically, user’s remote device negotiates wialgorithm that 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-00403-RP Document 1-3 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 Evernote Corporation and user’s remote dFor RSA and RSA _PSK, Evernote Corporation server generates an RSA public-p

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Evernote Corporation ser

Hellman public-private key pair24. The user’s remote device also generates a se

For DHE_DSS and DH_DSS, Evernote Corporation server generates a DSA publi

The user’s remote device also generates a second Diffie-Hellman public-private For ECDH_ECDSA and ECDHE_ECDSA, Evernote Corporation server generates aprivate key pair. The user’s remote device also generates a second Diffie-Hellm

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.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-00403-RP Document 1-3 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 2020

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Case 1:20-cv-00403-RP Document 1-3 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 Evernote Corporation and the user’s remote device so that they are r

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

server and the user’s remote device to compute a master secret. Evernote Cor

encrypting and decrypting communication messages. For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Evernote Corporation ser

Hellman public-private key pair25. The user’s remote device also generates a seserver uses its Diffie-Hellman private key and the user’s Diffie-Hellman public k

master secret. The user’s remote device uses the user’s Diffie-Hellman private 

premaster secret and subsequently the master secret for encrypting and decryFor DHE_DSS and DH_DSS, Evernote Corporation server generates a DSA publi

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

uses the user’s Diffie-Hellman private key and Google’s Diffie-Hellman public k

master secret for encrypting and decrypting communication messages. For ECDH_ECDSA and ECDHE_ECDSA, Evernote Corporation server generates aprivate key pair. The user’s remote device also generates a second Diffie-Hellm

Hellman private key and the user’s Diffie-Hellman public key to compute a preremote device uses the user’s Diffie-Hellman private key and Google’s Diffie-H

subsequently the master secret for encrypting and decrypting communication 

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

Evernote Corporation’s mobile software application products and services incl

(“mobile applications”, “mobile apps” or “Accused Products”) that are specific

distributed by Evernote Corporation to be downloaded onto Android mobile o

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-00403-RP Document 1-3 Filed 04/16/20 
 Evernote - Notes Organizer & Daily Planner (https://play.google.com/s

19, 2020) 

Evernote Corporation directly infringes and/or continues to knowingly induce Gmarketing, advertising, providing, sending, distributing and licensing its mobile and aiding, abetting, encouraging, promoting or inviting use thereof. Upon information and belief, the method step of generating an integrity verific

are attributable to Evernote Corporation (i) because Evernote Corporation wordistribution of its mobile apps, or (ii) because Google distributes and markets EEvernote Corporation, or acts as agent, or on behalf of Evernote Corporation, i

mobile apps. Alternatively, to the extent any portion of this method step is performed by Ev

conditions participation in and the receipt of a benefit, namely, the distributio

compliance with certain mandatory procedures and guidelines dictated by Goo

and Evernote Corporation induces infringement by Google in the building, marThe Court construed “integrity verification kernel” to mean “software that veriand 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

Further, Android implements disk encryption for encrypting the operating systwhich renders the code for validating the digitally signed mobile app binary fur

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

Case 1:20-cv-00403-RP Document 1-3 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 opera

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

modification. 

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-00403-RP Document 1-3 Filed 04/16/20 
Source: http://web.archive.org/web/20171208043438/https://source.android

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

Case 1:20-cv-00403-RP Document 1-3 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 opera

not launch. 

Case 1:20-cv-00403-RP Document 1-3 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 

Evernote Corporation’s mobile software application products and services incl

(“mobile applications”, “mobile apps” or “Accused Products”) that are specific

distributed by Evernote Corporation to be downloaded onto Android mobile o

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, 2020 https://www.linuxsecrets.com/elinux-wiki/images/b/b2/Android_Verified_Boot.pdf, Last accessed on Mar 19, 2020 

Case 1:20-cv-00403-RP Document 1-3 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. 

 Evernote - Notes Organizer & Daily Planner (https://play.google.com/s

19, 2020) 

Evernote Corporation directly infringes and/or continues to knowingly induce Gmarketing, advertising, providing, sending, distributing and licensing its mobile and aiding, 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 performeEvernote Corporation (i) because Evernote Corporation works together with Gapps, or (ii) because Google distributes and markets Evernote Corporation’s m

acts as agent, or on behalf of Evernote Corporation, in the building, marketing 

Alternatively, to the extent any portion of this method step is performed by Ev

conditions participation in and the receipt of a benefit, namely, the distributiocompliance with certain mandatory procedures and guidelines dictated by Goo

and Evernote Corporation induces infringement by Google in the building, marThe Court previously construed30 “integrity verification kernel” to mean “softw

digital 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

parses a manifest associated with the operating system and code that verifies 

and has not been maliciously modified. 

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-00403-RP Document 1-3 Filed 04/16/20 
Further, the software that performs the above verification is stored in a compi

Additionally, the software is digitally signed by Google with their asymmetric p

Case 1:20-cv-00403-RP Document 1-3 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, 2020 https://www.linuxsecrets.com/elinux-wiki/images/b/b2/Android_Verified_Boot.pdf, Last accessed on Mar 19, 2020 

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

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

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

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

Case 1:20-cv-00403-RP Document 1-3 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. 

Evernote Corporation’s mobile software application products and services incl(“mobile applications”, “mobile apps” or “Accused Products”) that are specific

distributed by Evernote Corporation to be downloaded onto Android mobile o

 Evernote - Notes Organizer & Daily Planner (https://play.google.com/s

19, 2020) 

Evernote Corporation directly infringes and/or continues to knowingly induce Gmarketing, advertising, providing, sending, distributing and licensing its mobile and aiding, 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 Evernote Corporation (i) bec

enterprise in the building and distribution of its mobile apps, or (ii) because Gounder the direction and control of Evernote Corporation, or acts as agent, or odistribution of Evernote Corporation’s mobile apps.Alternatively, to the extent any portion of this method step is performed by Ev

conditions participation in and the receipt of a benefit, namely, the distributio

compliance with certain mandatory procedures and guidelines dictated by Goo

and Evernote Corporation induces infringement by Google in the building, marAs 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-00403-RP Document 1-3 Filed 04/16/20 
Case 1:20-cv-00403-RP Document 1-3 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: 

Evernote Corporation’s mobile software application products and services incl

(“mobile applications”, “mobile apps” or “Accused Products”) that are specific

distributed by Evernote Corporation to be downloaded onto Android mobile o

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, 2020 https://www.linuxsecrets.com/elinux-wiki/images/b/b2/Android_Verified_Boot.pdf, Last accessed on Mar 19, 2020 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
 Evernote - Notes Organizer & Daily Planner (https://play.google.com/s

19, 2020) 

Evernote Corporation directly infringes and/or continues to knowingly induce Gmarketing, advertising, providing, sending, distributing and licensing its mobile and aiding, abetting, encouraging, promoting or inviting use thereof. To the extent any steps identified herein are performed by Google, such acts a

Corporation works together with Google in a joint enterprise in the building anmarkets Evernote Corporation’s mobile apps under the direction and control oCorporation, in the building, marketing and distribution of Evernote CorporatioAlternatively, any steps or acts performed by Evernote Corporation, are attribu

benefit, namely, the distribution of Evernote Corporation’s mobile apps througand guidelines dictated by Google in the building and upload of Evernote Corpby Google in the building, marketing and distribution of Evernote Corporation’To the extent the preamble is limiting, Evernote Corporation distributes data aIn order to build and send the mobile app securely to the Google servers, Ever

in order to securely distribute its mobile app to Evernote Corporation’s custom(https://play.google.com/apps/publish/, Last accessed on Mar 19, 2020) estab

Corporation’s apps, as evidenced by the “https” in the URL. That process necesencrypt data that is used to 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 desigmodification, and that includes a key for secure communication.” Also relevan

“including” to compiling34. 

33 See Memorandum Opinion and Order, Document 104 signed by Judge Rodney Gilstrap on 7/21/2016 in re Plano Encryption Techno34 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 priva

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

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

The method step of “building an executable tamper resistant key module iden

executable tamper resistant key module including a private key of the asymmeCorporation and/or its agents. To the extent any portion of the method step is performed by Google and/or itbecause Evernote Corporation works together with Google in a joint enterprise 

Google distributes and markets Evernote Corporation’s mobile apps under the behalf of Evernote Corporation, in the building, marketing and distribution of E

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 Evernote Corporation in oto verify the mobile app has not been changed with the public key for Android 

The asymmetric key pair that is included to digitally sign the mobile app is diffe

securely 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 ke

the 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. Evernote Corporation uploads their mobile apps to Google using a TLS connect

mandatory procedure that allows Evernote Corporation and Google to exchang

shared master secret for encrypting communication including upload of Everno

performing complementary functions, such as encrypting and decrypting data or creating and verifying signatures.” While not necess

key and private key in claim 34 must perform complementary functions. 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
A TLS handshake begins with Evernote Corporation sending a list of cipher suit

specify at least one or more of the following key exchange algorithms: 

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

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

For each of the key exchange algorithms, Evernote Corporation and/or Google 

generated private key and the encrypted data. 

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

impossible for Evernote Corporation to send its mobile app to Google using SS

The executable tamper resistant key module also includes: 

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

2. Evernote Corporation’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 executablname, category, screenshots and description related to Evernote Corporation’

includes: 

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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s RSA private key used to sign the message containing Google’s 4. Evernote Corporation’s private key used to code-sign the mobile app. 

For DHE_DSS and DH_DSS, the executable tamper resistant key module includthe TLS handshake, including at least the executable compiled code related to 

and description related to Evernote Corporation’s mobile apps). The executabl

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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s DSA private key used to sign the message containing Google’

4. Evernote Corporation’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 Evernote Corporation’s mobil

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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s ECDSA private key used to sign the message containing Goog

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Evernote Corporation builds an executable tamper resistant key module identi

Evernote Corporation builds a mobile app, which is an executable tamper resis

identified for a selected program resident on a remote system, namely the And

The mobile app comprises an executable tamper resistant key module that is idescribed above and the encrypted data encrypted with the claimed public key made available for download from Google servers onto devices compatible wit

Corporation. An asymmetric key pair is used not only to upload the binary cod

all of the metadata for the app, such as title, screenshots, and other resources included during the upload process so that the mobile app can be identified by 

Evernote Corporation’s mobile app is each an executable tamper resistant key 

the Android operating system as well as other applications or programs installeobservation and modification, as explained below; and because in building EveCorporation’s apps include at least the claimed generated private key and the 

encrypted with the claimed generated public key when the mobile app is secur

The tamper resistant key module includes several keys “used for secure comm

following: For RSA and RSA _PSK: 

1. Google’s RSA private key corresponding to Google’s RSA public key use2. Evernote Corporation’s private key used to code-sign the mobile app. 3. Symmetric key used for uploading the mobile app to Google subseque

4. 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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s RSA private key used to sign the message containing Google’s 4. Evernote Corporation’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-00403-RP Document 1-3 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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s DSA private key used to sign the message containing Google’

4. Evernote Corporation’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

shared master secret. 

2. Evernote Corporation’s Diffie-Hellman private key used to compute th3. Google’s ECDSA private key used to sign the message containing Goog

4. Evernote Corporation’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

Evernote Corporation’s mobile apps are tamper resistant, resistant to observat

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

Evernote Corporation mobile apps are resistant to observation, at least in partbefore submitting the app to Google – and uploads the binary output of the co

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-00403-RP Document 1-3 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 

Evernote Corporation’s mobile apps are made further resistant to observation, 

Google as part of the building process. Android Developer Console (https://pla

establishes SSL/TLS communications when uploading Evernote Corporation’s acode by SSL/TLS is necessary to keep the code from being observed in transit fThe secure upload process starts with a TLS handshake procedure which uses a

asymmetric key pair. Specifically, Evernote Corporation negotiates with Google 

the handshake. 

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Case 1:20-cv-00403-RP Document 1-3 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 Evernote Corpo

app, using a master secret, rendering the communication resistant to observatFor RSA and RSA _PSK, Evernote Corporation encrypts a random premaster se

secret to Google. Google decrypts the premaster secret with its matched RSA p

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
secret to compute a master secret which is then used by both Evernote Corpor

Evernote Corporation and Google. For the other key exchange algorithms, namely Diffie-Hellman based algorithmECDH_RSA, ECDH_ECDSA and ECDHE_ECDSA, Evernote Corporation sends its DHellman public key to Evernote Corporation. Evernote Corporation then uses GCorporation’s own Diffie-Hellman private key to compute a premaster secret. G

combined with Google’s own Diffie-Hellman private key to compute the same 

premaster secret to compute a master secret which is then used by both Everncommunications between Evernote Corporation 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, becaus

must sign the mobile app submission with his/her asymmetric developer key t

impersonator38. 

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 tso that Evernote Corporation can authenticate the Google server by decrypting the hash using Google’s public key and matching the dCorporation itself. If the two values match, Evernote Corporation knows that the message originated from Google and not from a ma

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

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

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

accessed on Mar 19, 2020 

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

accessed on Mar 19, 2020

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

accessed on Mar 19, 2020

Evernote Corporation complies with Google’s instructions on code signing as s

Corporation’s mobile apps contain files such as the files CERT.SF and CERT.RSA the code signing process as per instructions from Google. 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Source: Contents of Evernote - Notes Organizer & Daily Planner (https://play.g

accessed on Mar 19, 2020) as an example of Evernote Corporation app 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Source: Contents of Evernote - Notes Organizer & Daily Planner (https://play.g

accessed on Mar 19, 2020) as an example of Evernote Corporation app 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 includekey 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, Evernote Corporation’s mobdevices to verify that the application is being distributed by trusted source (i.e. 

by a third party, which can be verified by the corresponding public key generatmodification by digital signing. Accordingly Evernote Corporation’s Android mobile apps establish SSL/TLS com

SSL/TLS handshake procedure involving asymmetric key encryption. SSL/TLS enresistant to observation. 

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 Evernote Corporation (i) becenterprise in the building and distribution of its mobile apps, or (ii) because Gounder the direction and control of Evernote Corporation, or acts as agent, or o

distribution of Evernote Corporation’s mobile apps.

Alternatively, to the extent any portion of this method step is performed by Ev

conditions participation in and the receipt of a benefit, namely, the distributiocompliance with certain mandatory procedures and guidelines dictated by Gooand Evernote Corporation induces infringement by Google in the building, mar

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Evernote Corporation’s mobile apps are sent or downloaded from Google serv

phones and tablets. When a user accesses Google Play Store – and requests to 

tamper resistant key module from the Google servers to the remote device(s). 

Further, the step of “sending” Evernote Corporation mobile apps to the remot

Evernote Corporation mobile apps, to the extent required by the claims, also inin detail above. In particular, Evernote Corporation mobile apps sent to users’ remote devices 

follows: 

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

Evernote Corporation mobile apps are resistant to observation, at least in partbefore submitting the app to Google – and uploads the binary output of the co

user can only download the compiled source code from Google rather than the 

See, Android Studio Users Guide, “Prepare for Release” stating “To release youusers 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

Evernote Corporation’s mobile apps are made further resistant to observation, 

downloaded by SSL/TLS from Google servers. Evernote Corporation app users the URL https://play.google.com/store/apps/details?id=com.evernote&hl=en_

Evernote Corporation’s apps, as evidenced by the “https” in the URL. Sending tbeing observed in transit from Google to the user’s remote system. 

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
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-00403-RP Document 1-3 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 pairFor 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-00403-RP Document 1-3 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Case 1:20-cv-00403-RP Document 1-3 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-00403-RP Document 1-3 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 secr

decrypt 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 puand 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 devicprotocol. 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-00403-RP Document 1-3 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

Evernote Corporation complies with Google’s instructions on code signing as s

Corporation’s mobile apps contain files such as the files CERT.SF and CERT.RSA during the code signing process as per instructions from Google. 

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Source: Contents of Evernote - Notes Organizer & Daily Planner (https://play.g

accessed on Mar 19, 2020) as an example of Evernote Corporation app 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Source: Contents of Evernote - Notes Organizer & Daily Planner (https://play.g

accessed on Mar 19, 2020) as an example of Evernote Corporation app By signing the app binary with a digital signature, Evernote Corporation’s mobdevices to verify that the application is being distributed by trusted source (i.e. 

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
by a third party, which can be verified by the corresponding public key generat

modification by digital signing. Accordingly Evernote Corporation’s Android mobile apps establish SSL/TLS com

SSL/TLS handshake procedure involving asymmetric key encryption. SSL/TLS en

resistant to observation. 

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 operat

which further renders Evernote Corporation app resistant to observation43. 

5. Resistant to Observation Because Mobile App Securely Communicate

Evernote Corporation’s mobile apps are made further resistant to observation, 

Corporation using SSL/TLS during operation. Evernote Corporation app users ewhen the app is executed. Such secure communication is necessary to keep sotransit from the remote system to Evernote Corporation servers and vice versa

The secure communications process starts with a TLS handshake procedure whleast one asymmetric key pair. Specifically, user’s remote device negotiates wialgorithm that 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-00403-RP Document 1-3 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 Evernote Corporation and user’s remote d

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
For RSA and RSA _PSK, Evernote Corporation server generates an RSA public-p

For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Evernote Corporation serHellman public-private key pair44. The user’s remote device also generates a se

For DHE_DSS and DH_DSS, Evernote Corporation server generates a DSA publi

The user’s remote device also generates a second Diffie-Hellman public-private For ECDH_ECDSA and ECDHE_ECDSA, Evernote Corporation server generates aprivate key pair. The user’s remote device also generates a second Diffie-Hellm

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-00403-RP Document 1-3 Filed 04/16/20 
Source: https://tools.ietf.org/html/rfc5246 at 48-49, Last accessed on Mar 19, 

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

Case 1:20-cv-00403-RP Document 1-3 Filed 04/16/20 
Case 1:20-cv-00403-RP Document 1-3 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 Evernote Corporation and the user’s remote device so that they are r

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

server and the user’s remote device to compute a master secret. Evernote Cor

encrypting and decrypting communication messages. For DHE_RSA, ECDHE_RSA, DH_RSA and ECDH_RSA, Evernote Corporation ser

Hellman public-private key pair45. The user’s remote device also generates a seserver uses its Diffie-Hellman private key and the user’s Diffie-Hellman public k

master secret. The user’s remote device uses the user’s Diffie-Hellman private 

premaster secret and subsequently the master secret for encrypting and decryFor DHE_DSS and DH_DSS, Evernote Corporation server generates a DSA publi

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

uses the user’s Diffie-Hellman private key and Google’s Diffie-Hellman public k

master secret for encrypting and decrypting communication messages. For ECDH_ECDSA and ECDHE_ECDSA, Evernote Corporation server generates aprivate key pair. The user’s remote device also generates a second Diffie-Hellm

Hellman private key and the user’s Diffie-Hellman public key to compute a preremote device uses the user’s Diffie-Hellman private key and Google’s Diffie-H

subsequently the master secret for encrypting and decrypting communication 

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-00403-RP Document 1-3 Filed 04/16/20