Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 1 of 15 PageID #: 86
`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 1 of 15 PageID #: 86
`
`EXHIBIT 4
`
`
`
`
`
`
`
`EXHIBIT 4
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 2 of 15 PageID #: 87
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (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. 6,574,239, entitled “Virtual Connection of a Remote Unit to a Server” (“the ’239 patent”) by JPMorgan Chase & Co.
`(“Chase”). The following chart illustrates an exemplary analysis regarding infringement by Chase’s commercial mobile device application(s)
`including Chase Mobile, Chase Mobile Checkout, J.P. Morgan Access Mobile, J.P. Morgan Mobile, and Chase Mobile Checkout-PLUS, 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
`
`Chase has not yet provided any non-public information.
`
`Unless otherwise noted, CIT contends that Chase directly infringes the ’239 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 Chase’s provision
`
`of the Accused Instrumentalities. However, to the extent that Chase 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 Chase
`nor has Chase 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
`
`

`

`
`
`
`Claim 7
`7 For use in controlling a virtual session
`on a server, a method comprising:
`
`
`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 3 of 15 PageID #: 88
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`
`
`
`Chase Service
`A method is specified for controlling a virtual session on a server. The definition of a virtual
`session is described section 7a below.
`
`See https://play.google.com/store/apps/developer?id=JPMorgan+Chase
`
`
`7a
`
`establishing a virtual session with a
`remote unit, the virtual session being
`instantiated to support at least one
`application layer program;
`
`
`
`
`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 Chase Server backend to the Chase App
`(application program, application layer program) running on a user’s smartphone or tablet (remote
`unit).
`
`See https://play.google.com/store/apps/details?id=com.chase.sig.android
`
`
`2
`
`

`

`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 4 of 15 PageID #: 89
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`
`
`
`
`
`In the Chase application, for example, a push notification contains information related to charges,
`
`
`
`3
`
`

`

`
`
`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 5 of 15 PageID #: 90
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`refunds, balance transfers, payments, balances, credit limit amounts, due dates, and other
`transactions and account information.
`
`See https://www.chase.com/personal/mobile-online-banking/login-alerts
`
`
`
`
`Also, the Server Application and the client-side App establish a separate TLS connection for
`traditional client-server communications. For example, the Chase Application Server program
`establishes a TLS session with the Chase App.
`
`
`
`
`4
`
`

`

`
`
`7b placing the virtual session in an inactive
`state;
`
`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 6 of 15 PageID #: 91
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`The TLS session used for client-server communications between the Chase Application Server and
`the Chase App correspond to the recited virtual session.
`
`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.
`
`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.
`
`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 virtual session into the inactive state.
`
`Chase Application server causes a push notification message (incoming communication) to be sent
`to the Chase App running on the user’s smartphone or tablet device (remote unit). See Endnote #1.
`
`In the Chase App, for example, a push notification contains information related to charges, refunds,
`balance transfers, payments, balances, credit limit amounts, due dates, and other transactions and
`5
`
`7c
`
`sending a signal indicative of an
`incoming communication request and an
`application-program identifying packet
`to said remote unit, said application-
`program identifying packet identifying
`
`

`

`
`
`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 7 of 15 PageID #: 92
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`
`an application program that needs to
`resume a virtual session and
`communicate with said remote unit; and
`
`account information.
`
`See https://www.chase.com/personal/mobile-online-banking/login-alerts
`
`
`
`
`The signal indicative of an incoming communication request will request the application program
`running on the remote unit to resume the TLS session used for client-server communications
`between the Chase Application server and the Chase App running on the user’s smartphone or
`tablet device (remote unit). The application-program identifying packet will include information
`used to identify the App) on the remote unit.
`
`
`6
`
`

`

`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 8 of 15 PageID #: 93
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`The Chase server and the Chase App will resume a TLS session so that the server and the remote
`unit can resume communications. To do so the Chase App will invoke a protocol stack within the
`remote unit to communicate back to the server via the remote unit.
`
`See Endnote #1 for a discussion of how each new set of data payloads coming into the Chase
`application includes an app-specific device token. The app-specific device token is indicative of
`the Chase application running on the remote unit. Each incoming wireless push notification
`message contains the app-specific device token which is part of the application-program identifying
`packet.
`
`Based upon user selection of information associated with the above-mentioned push notification,
`the Transport Layer Security (TLS) session between the Chase Application Server and the Chase
`App is resumed as discussed in Endnote #2. TLS session resumption means that the TLS session is
`placed back into the active state using an abbreviated handshake sequence so that new application
`data can be passed between the Chase Application Server and the App running on the user’s
`smartphone or tablet.
`
`See Endnote#2 for a discussion of TLS session resumption. See also,
`https://docs.microsoft.com/en-us/windows/desktop/secauthn/tls-handshake-protocol.
`
`
`placing the virtual session back into the
`active state and transferring data
`between the application and the remote
`unit via the virtual session in response to
`said step of sending.
`
`
`
`7d
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`7
`
`

`

`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 9 of 15 PageID #: 94
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`
`
`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.
`
`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
`
`
`
`
`
`
`8
`
`

`

`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 10 of 15 PageID #: 95
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (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.
`
`9
`
`

`

`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 11 of 15 PageID #: 96
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`
`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:
`
`{
` "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
`
`
`
`
`
`
`10
`
`

`

`
`
`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 12 of 15 PageID #: 97
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`
`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();
`
` // 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();
` }
` });
`
`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) {
`
`11
`
`MainActivity.java
`
`

`

`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 13 of 15 PageID #: 98
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`
`
` 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.
`
`
`
`
`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.”
`
`12
`
`

`

`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 14 of 15 PageID #: 99
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`
`
`
`“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
`
`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
`
`13
`
`

`

`Case 4:20-cv-00527-SDJ Document 1-4 Filed 07/10/20 Page 15 of 15 PageID #: 100
`Analysis of Infringement of U.S. Patent No. 6,574,239 by JPMorgan Chase & Co.
` (Based on Public Information Only)
`
`
`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.
`
`
`
`
`
`
`
`14
`
`