`Case 4:20-cv-00528—SDJ Document 1-6 Filed 07/10/20 Page 1 of 12 PageID #: 111
`
`EXHIBIT 6
`
`
`
`
`
`
`
`EXHIBIT 6
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 2 of 12 PageID #: 112
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`Communication Interface Technologies, LLC (“CIT”) provides this preliminary and exemplary infringement analysis with respect
`
`infringement of U.S. Patent No. 8,291,010, entitled “Virtual Connection of a Remote Unit To A Server” (“the ’010 patent”) by TD Ameritrade, Inc.
`(“TD Ameritrade”). The following chart illustrates an exemplary analysis regarding infringement by TD Ameritrade’s commercial mobile device
`application(s) including the TD Ameritrade Mobile App, thinkorswim Mobile: Trade. Invest. Buy & Sell App, TD Ameritrade Advisor Client, and
`TD Ameritrade Authenticator, along with any hardware and/or software for provisioning that mobile device application (collectively, the “Accused
`Instrumentalities”). Upon information and belief, the exemplary version herein and previous versions of the Accused Instrumentalities distributed
`prior to expiration of the patents-in-suit operated materially in the same manner.
`
`The analysis set forth below is based only upon information from publically available resources regarding the Accused Instrumentalities, as
`
`TD Ameritrade has not yet provided any non-public information.
`
`Unless otherwise noted, CIT contends that TD Ameritrade directly infringes the ’010 patent in violation of 35 U.S.C. § 271(a) by selling,
`
`offering to sell, making, using, and/or importing the Accused Instrumentalities. The following exemplary analysis demonstrates that infringement.
`
`Unless otherwise noted, CIT believes and contends that each element of each claim asserted herein is literally met through TD Ameritrade’s
`
`provision of the Accused Instrumentalities. However, to the extent that TD Ameritrade attempts to allege that any asserted claim element is not
`literally met, CIT believes and contends that such elements are met under the doctrine of equivalents. More specifically, in its investigation and
`analysis of the Accused Instrumentalities, CIT did not identify any substantial differences between the elements of the patent claims and the
`corresponding features of the Accused Instrumentalities, as set forth herein. In each instance, the identified feature of the Accused Instrumentalities
`performs at least substantially the same function in substantially the same way to achieve substantially the same result as the corresponding claim
`element.
`
`CIT notes that the present claim chart and analysis are necessarily preliminary in that CIT has not obtained substantial discovery from TD
`Ameritrade nor has TD Ameritrade disclosed any detailed analysis for its non-infringement position, if any. Further, CIT does not have the benefit of
`claim construction or expert discovery. CIT reserves the right to supplement and/or amend the positions taken in this preliminary and exemplary
`infringement analysis, including with respect to literal infringement and infringement under the doctrine of equivalents, if and when warranted by
`further information obtained by CIT, including but not limited to information adduced through information exchanges between the parties, fact
`discovery, claim construction, expert discovery, and/or further analysis.
`
`1
`
`
`
`
`
`
`1
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 3 of 12 PageID #: 113
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`Claim 1
`A method comprising:
`
`
`
`TD Ameritrade Downloadable App Service
`A method is specified for use on a user device like a handheld or tablet.
`
`See https://play.google.com/store/apps/developer?id=TD+Ameritrade
`
`
`1a
`
`establishing, at a computing device, a
`communication session supporting
`communication between a first
`program executing at an application
`layer of the computing device and a
`remote server;
`
`
`
`
`Wireless push notification messages are sent over Transport Layer Security (TLS) sessions. Each
`Push message includes an encrypted push token as per Endnote #1. The push token is sent in a
`Push Notification message over TLS sessions from the TD Ameritrade Server backend (remote
`server) to the TD Ameritrade App (application program, application layer program) running on a
`user’s smartphone (mobile handset) or tablet.
`
`In the TD Ameritrade application, for example, a push notification contains information related to
`accounts, investments and banking.
`
`
`2
`
`
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 4 of 12 PageID #: 114
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`See https://play.google.com/store/apps/details?id=com.tdameritrade.mobile3
`
`
`
`
`
`Also, the Server Application and the client-side App establish a separate TLS connection for
`traditional client-server communications. For example, the TD Ameritrade Application Server
`program establishes a TLS session with the TD Ameritrade App.
`
`The TLS session used for client-server communications between the TD Ameritrade Application
`Server and the TD Ameritrade App correspond to the recited communication session.
`
`TLS sessions use a full handshake sequence that is used to establish connection parameters, and an
`abbreviated handshake sequence that is used to resume the TLS session from an inactive or
`dormant state to an active state whereby new payload data can be sent via the virtual session once
`again.
`
`See Endnote #2 for a discussion of the virtual session aspects of TLS.
`
`Mobile applications communicate with their application server via TLS connections. These TLS
`connections are established at the time the app is installed or launched and can be resumed at a later
`time using a session token. See Endnote#2 for a discussion of TLS.
`
`See https://threema.ch/press-files/cryptography_whitepaper.pdf - Android uses TLS 1.2 resumable
`sessions.
`
`See https://www.icir.org/johanna/papers/conext17android.pdf - Android also supports TLS and
`secure connections between client app and server are ubiquitously used.
`3
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 5 of 12 PageID #: 115
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`
`
`
`See https://developer.android.com/training/articles/security-ssl. – “The Secure Sockets Layer
`(SSL)—now technically known as Transport Layer Security (TLS)—is a common building block
`for encrypted communications between clients and servers.” Note that certain certificates are used,
`and these are used to help create Android Device Tokens used in Push Notification messages. See
`Endnotes #1, and #2.
`
`
`See Endnote #2. Note when the application data phase is finished, the TLS client-server data
`session is placed back into the inactive state. Hence the end of application data marker is the signal
`used to place the session into the inactive state.
`
`As per Endnote #1, the remote server causes a push notification message to be sent to the
`computing device. Part of this push notification message (incoming communication) will be
`forwarded to the TD Ameritrade App running on the user’s smartphone or tablet device. The push
`notification message is asynchronously initiated by the remote server (TD Ameritrade Application
`Server) as opposed to being sent in response to a request sent by the user computing device.
`
`
`An app-specific device token included in the incoming communication lets the system know which
`App on the device to activate or to send the new incoming information to.
`
`See Endnote #1 for a discussion of how each Push Notification message coming into the TD
`Ameritrade App includes an app-specific device token. The app-specific device token is indicative
`of the TD Ameritrade App running on the user’s smartphone or tablet.
`
`When the push notification has been received by the TD Ameritrade App, the TD Ameritrade App
`provides user interface capabilities that allow the user to click application data information received
`in the push message payload. When the user clicks this information, the TD Ameritrade App
`evaluates this information and causes the TD Ameritrade App to launch.
`
`The remote server sends a push notification message to the TD Ameritrade application running in
`the smartphone or tablet operated by a specified user. As per Endnote #1, this push notification
`message is processed by the operating system and the app-specific device token and related
`information (incoming communication) is forwarded from the OS to the TD Ameritrade App.
`4
`
`1b (i)
`
`subsequent to deactivation of the
`established communication session,
`
`1b (ii)
`
`the computing device receiving an
`incoming communication from the
`remote server, wherein the incoming
`communication is not in response to a
`request sent by the computing device;
`
`
`1c
`
`at the application layer, the
`computing device reading a set of
`information included in the incoming
`communication;
`
`1d
`
`
`
`in response to determining that the set
`of information read at the application
`layer includes information identifying
`the first program executing at the
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 6 of 12 PageID #: 116
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`
`In response to using the app-specific device token to send the notification to the TD Ameritrade
`App’s notification handler routine, plus the application layer events of user then clicking the
`notification message, the App is launched and the TLS session between the TD Ameritrade
`Application Server program and the TD Ameritrade App is resumed.
`
`See Endnote #2 for a discussion of TLS session resumption. See also,
`https://docs.microsoft.com/en-us/windows/desktop/secauthn/tls-handshake-protocol.
`
`The remote server and the TD Ameritrade application will resume their client-server TLS session
`so that the server and the remote unit can resume communications. To do so the application
`program will invoke a protocol stack within the remote unit to communicate back to the server via
`the remote unit.
`
`TLS session use a full handshake sequence that is used to establish connection parameters, and an
`abbreviated handshake sequence that is used to resume the TLS session from an inactive or
`dormant state to an active state whereby new payload data can be sent via the virtual session once
`again.
`
`
`
`
`computing device, the computing
`device reactivating the
`communication session between the
`first program and the remote server.
`
`
`Endnote#1 - App-Specific Device Token
`
`https://help.pushwoosh.com/hc/en-us/articles/360000364923-What-is-a-Device-token-
`Question:
`What is a Device token?
`Answer:
`Push token (device token) - is a unique key for the app-device combination which is issued by the Apple or Google push notification gateways. It
`allows gateways and push notification providers to route messages and ensure the notification is delivered only to the unique app-device combination
`for which it is intended.
`iOS device push tokens are strings with 64 hexadecimal symbols. Push token example:
`03df25c845d460bcdad7802d2vf6fc1dfde97283bf75cc993eb6dca835ea2e2f
`Make sure that iOS push tokens you use when targeting specific devices in your API requests are in lower case.
`5
`
`
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 7 of 12 PageID #: 117
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`
`Android device push tokens can differ in length (usually below 255 characters), and usually start with APA…Push token example:
`
`APA91bFoi3lMMre9G3XzR1LrF4ZT82_15MsMdEICogXSLB8-
`MrdkRuRQFwNI5u8Dh0cI90ABD3BOKnxkEla8cGdisbDHl5cVIkZah5QUhSAxzx4Roa7b4xy9tvx9iNSYw-eXBYYd8k1XKf8Q_Qq1X9-
`x-U-Y79vdPq
`
`
`Note: The Android device push tokens correspond to the app-specific device token terminology used in the claim charts.
`
`https://dev.to/jakubkoci/react-native-push-notifications-313i
`
`
`
`
`
`
`6
`
`
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 8 of 12 PageID #: 118
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`Note: In the above Architecture, the “backend” corresponds to the backend of the Application Server. The Device token corresponds to a specific
`App running on a specific device. That is what is meant by the app-specific device token in the claim charts.
`
`
`
`https://firebase.google.com/docs/cloud-messaging/android/first-message
`
`Access the registration token
`
`To send a message to a specific device, you need to know that device's registration token. Because you'll need to enter the token in a field in the
`Notifications console to complete this tutorial, make sure to copy the token or securely store it after you retrieve it.
`
`On initial startup of your app, the FCM SDK generates a registration token for the client app instance. If you want to target single devices or create
`device groups, you'll need to access this token by extending FirebaseMessagingService and overriding on NewToken.
`
`This section describes how to retrieve the token and how to monitor changes to the token. Because the token could be rotated after initial startup, you
`are strongly recommended to retrieve the latest updated registration token.
`
`The registration token may change when:
`
`• The app deletes Instance ID
`• The app is restored on a new device
`• The user uninstalls/reinstall the app
`• The user clears app data.”
`
`
`https://firebase.google.com/docs/cloud-messaging/concept-options
`
`For example, here is a JSON-formatted notification message in an IM app. The user can expect to see a message with the title "Portugal vs.
`Denmark" and the text "great match!" on the device:
`
`7
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 9 of 12 PageID #: 119
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`
`{
` "message":{
` "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...", -- App-specific token
` "notification":{
` "title":"Portugal vs. Denmark",
` "body":"great match!"
` }
` }
`}
`
`
`https://firebase.google.com/docs/cloud-messaging/android/client
`
`
`
`
`
`
`Retrieve the current registration token
`
`When you need to retrieve the current token, call FirebaseInstanceId.getInstance().getInstanceId():
`FirebaseInstanceId.getInstance().getInstanceId()
` .addOnCompleteListener(new OnCompleteListener<InstanceIdResult>() {
` @Override
` public void onComplete(@NonNull Task<InstanceIdResult> task) {
` if (!task.isSuccessful()) {
` Log.w(TAG, "getInstanceId failed", task.getException());
` return;
` }
`
` // Get new Instance ID token
` String token = task.getResult().getToken();
`
`8
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 10 of 12 PageID #: 120
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`
`
` // Log and toast
` String msg = getString(R.string.msg_token_fmt, token);
` Log.d(TAG, msg);
` Toast.makeText(MainActivity.this, msg, Toast.LENGTH_SHORT).show();
` }
` });
`
`MainActivity.java
`
`Monitor token generation
`
`The onNewToken callback fires whenever a new token is generated.
`/**
` * Called if InstanceID token is updated. This may occur if the security of
` * the previous token had been compromised. Note that this is called when the InstanceID token
` * is initially generated so this is where you would retrieve the token.
` */
`@Override
`public void onNewToken(String token) {
` Log.d(TAG, "Refreshed token: " + token);
`
` // If you want to send messages to this application instance or
` // manage this apps subscriptions on the server side, send the
` // Instance ID token to your app server.
` sendRegistrationToServer(token);
`}
`After you've obtained the token, you can send it to your app server and store it using your preferred method. See the Instance ID API reference
`[https://firebase.google.com/docs/reference/android/com/google/firebase/iid/FirebaseInstanceId] for full detail on the API.
`
`
`
`
`
`9
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 11 of 12 PageID #: 121
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`
`Endnote#2 - Transport Layer Security and Virtual Sessions
`
`Transport Layer Security (TLS) is used by both Apple iOS and Android based devices. The handshake diagrams in this endnote use Apple iOS as an
`example but apply equally to Android type implementations.
`
`https://developer.android.com/training/articles/security-ssl
`
`“The Secure Sockets Layer (SSL)—now technically known as Transport Layer Security (TLS)—is a common building block for encrypted
`communications between clients and servers.”
`
`https://android-developers.googleblog.com/2018/04/protecting-users-with-tls-by-default-in.html
`
`“Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting all data that enters
`or leaves an Android device with Transport Layer Security (TLS) in transit.
`
`A. Razaghpanah et al., Studying TLS Usage in Android Apps, CoNEXT ’17, Dec.12-15, 2017, Incheon, Republic of Korea
`http://abbas.rpanah.ir/publications/conext2017_tls_paper.pdf
`
`“A History of TLS Support in Android: Android has supported TLS 1.0 since its first version released in 2008 and TLS 1.1 and TLS 1.2 since
`2012.”
`
`“However, other protocols such as secure email (42 apps) and Google’s Cloud Messaging service for push notifications (9 apps) [11, 47] also use
`TLS.”
`
`https://developer.ibm.com/customer-engagement/docs/watson-marketing/ibm-engage-2/tls-1-2-migration-for-mobile-push-clients/
`
`What will happen on devices that are unable to support TLS 1.2?
`
`Devices which do not support TLS 1.2 will be unable to connect to our WCA servers. This will prevent users of those devices from:
`
` •
`
` Registering new mobile user IDs
`• Updating push tokens
`• Receiving inbox messages
`• Receiving In-app messages
`
`10
`
`
`
`Case 4:20-cv-00528-SDJ Document 1-6 Filed 07/10/20 Page 12 of 12 PageID #: 122
`Analysis of Infringement of U.S. Patent No. 8,291,010 by TD Ameritrade, Inc.
` (Based on Public Information Only)
`
`
`Note: As the above link shows, the creation of the App IDs of Endnote #1 are linked to the TLS protocol being run on the TLS-enabled Push-
`Notification channel.
`
`https://tools.ietf.org/html/rfc5246
`
`F.1.4. Resuming Sessions
`
`When a connection is established by resuming a session, new ClientHello.random and ServerHello.random values are hashed with the session's
`master_secret. Provided that the master_secret has not been compromised and that the secure hash operations used to produce the encryption keys
`and MAC keys are secure, the connection should be secure and effectively independent from previous connections. Attackers cannot use known
`encryption keys or MAC secrets to compromise the master_secret without breaking the secure hash operations.
`
`Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that
`certificates may have expired or been revoked, it should force a full handshake. An upper limit of 24 hours is suggested for session ID lifetimes,
`since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired.
`Applications that may be run in relatively insecure environments should not write session IDs to stable storage.
`
`https://tools.ietf.org/html/rfc5077
`
`Abstract
`
`This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client
`session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session
`using the obtained ticket.
`
`3. Protocol
`
`
`This specification describes a mechanism to distribute encrypted session-state information in the form of a ticket. The ticket is created by a
`TLS server and sent to a TLS client. The TLS client presents the ticket to the TLS server to resume a session.
`
`
`
`
`
`
`
`
`11
`
`