`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 1 of 27 PageID #: 88
`
`EXHIBIT 4
`
`EXHIBIT 4
`
`
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 2 of 27 PageID #: 89
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (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 Capital One Financial
`Corporation (“Capital One”). The following chart illustrates an exemplary analysis regarding infringement by Capital One’s commercial mobile
`device application(s) including the Capital One Mobile App, the Capital One CreditWise App, Capital One T&Easy app, the Capital One Intellix
`Mobile app, and the Capital One Mobile app for Apple Watch, 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
`
`Capital One has not yet provided any non-public information.
`
`Unless otherwise noted, CIT contends that Capital One 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 Capital One’s
`
`provision of the Accused Instrumentalities. However, to the extent that Capital One 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 Capital
`One nor has Capital One 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
`
`
`
`
`
`
`7a
`
`Claim 7
`7 For use in controlling a virtual session
`on a server, a method comprising:
`
`establishing a virtual session with a
`remote unit, the virtual session being
`instantiated to support at least one
`application layer program;
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 3 of 27 PageID #: 90
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`
`Capital One Mobile App Service
`A method is specified for controlling a virtual session on a server. The definition of a virtual
`session is described section 7a below.
`
`Wireless push notification messages are sent over Transport Layer Security (TLS) sessions. Also,
`the remote server and the client side application establish a separate TLS connection for traditional
`client-server communications. For example, a Capital One server establishes a TLS session with a
`Capital One application program (application layer program) running on a user’s smartphone or
`tablet (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.
`
`See Endnote #2 for a discussion of the virtual session aspects of TLS.
`
`See Endnote #5 for a discussion of Wireless push email services such as Gmail which receives
`wireless push notification packets from a Gmail server.
`
`See Endnote #2 for a discussion of how wireless push notification services use Transport Layer
`Security (TLS) connections that constitute virtual sessions implemented at one or more layers
`below the application layer.
`
`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.
`
`https://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.dev.doc/dev/t
`_enforce_TLS.html
`
`“From iOS 9, Transport Layer Security (TLS) protocol version 1.2 must be enforced in all apps.”
`
`
`2
`
`
`
`
`
`7b placing the virtual session in an inactive
`state;
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 4 of 27 PageID #: 91
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`“Apple App Transport Security (ATS) is a new feature of iOS 9 that enforces best practices for
`connections between the app and the server. By default, this feature enforces some connection
`requirements that improve security. These include client-side HTTPS requests and server-side
`certificates and connection ciphers that conform to Transport Layer Security (TLS) version 1.2
`using forward secrecy.”
`
`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.”
`
`The Capital One application and the Capital One server communicate over a TLS session in order
`to provide secure communications between the client app and the server.
`
`See https://datatracker.ietf.org/doc/rfc5077/ - Note that session resumption was added in 2007 and
`does not appear to have been available in SSL and earlier versions, especially going back to
`November of 1998.
`See Endnote #2. Note when the application data phase is finished, the 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.
`
`Capital One server causes a push notification message (incoming communication) to be sent to the
`Capital One application running on the user’s smartphone or tablet device.
`
`In the Capital One application, for example, a push notification contains information related to
`purchase notifications, etc.
`See https://www.capitalone.com/applications/mobile/
`
`
`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
`an application program that needs to
`resume a virtual session and
`communicate with said remote unit; and
`
`3
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 5 of 27 PageID #: 92
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`
`
`
`The Capital One server and the Capital One application will resume a 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.
`
`See Endnote #1 and #2 for a discussion of how each new set of data payloads coming into the
`Capital One application includes an app-specific device token. The app-specific device token is
`indicative of the Capital One application running on the user’s smartphone or tablet. Each
`incoming wireless Internet Protocol packet that contains the app-specific device token corresponds
`to an application-program identifying packet.
`
`7d placing the virtual session back into the The Capital One server sends a push notification message to the Capital One application running in
`4
`
`
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 6 of 27 PageID #: 93
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`active state and transferring data
`between the application and the remote
`unit via the virtual session in response to
`said step of sending.
`
`REFERENCES
`
`
`
`the smartphone or tablet operated by a specified user.
`When the push notification is received, the Transport Layer Security (TLS) session 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 (payload of
`the push notification message) can be passed to the Capital One application program 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.
`
`[1] operating system push notification service, e.g.,
`https://www.urbanairship.com/push-notifications-explained
`https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/Remot
`eNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
`https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/Remot
`eNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW4
`
`[2] app-specific device token
`https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/Remot
`eNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW9
`
`
`
`
`
`
`
`
`
`
`5
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 7 of 27 PageID #: 94
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (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
`
`
`Hence as can be seen above, both Apple iOS and Android use similar but not identical device tokens. The basic protocol described below is
`discussed in the context of iOS but similarly applies to Android.
`For example, Firebase allows Android client app tokens to be used. The link below is from the Android specific page discussing app tokens from the
`developer’s viewpoint.
`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.
`6
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 8 of 27 PageID #: 95
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`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:
`
`{
` "message":{
` "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...", -- App-specific token
` "notification":{
` "title":"Portugal vs. Denmark",
` "body":"great match!"
` }
` }
`}
`
`The actions taken at the client and server levels to initialize the device token is described below. The same basic handshake sequence applies to both
`iOS and Android.
`
`
`7
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 9 of 27 PageID #: 96
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref
`/doc/uid/TP40008194-CH8-SW9
`
`
`
`Figure 6-6 - Managing the device token
`
`
`Obtaining and handling an app-specific device token works as follows:
`
`
`
`1.
`
`2.
`
`3.
`
`Your app registers with APNs for remote notifications, as shown in the top arrow. If the app is already registered and the app-specific
`device token has not changed, the system quickly returns the existing token to the app and this process skips to step 4.
`When a new device token is needed, APNs generates one using information contained in the device’s certificate. It encrypts the token
`using a token key and returns it to the device, as shown in the middle, right-pointing arrow.
`The system delivers the device token back to your app by calling your
`application:didRegisterForRemoteNotificationsWithDeviceToken: delegate method.
`
`8
`
`
`
`
`
`4.
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 10 of 27 PageID #: 97
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`Upon receiving the token, your app (within the delegate method) must forward it to your provider in either binary or hexadecimal
`format. Your provider cannot send notifications to the device without this token. For details, see Registering to Receive Remote
`Notifications in Configuring Remote Notification Support.
`
`IMPORTANT
`APNs device tokens are of variable length. Do not hard-code their size.
`When your provider sends a push notification request to APNs, it includes a device token that identifies a unique app-device combination. This step
`is shown in the “Token, Payload” arrow between the provider and APNs in Figure 6-7. APNs decrypts the token to ensure the validity of the request
`and to determine the target device. If APNs determines that the sender and recipient are legitimate, it then sends the notification to the identified
`device.
`
`Figure 6-7 - Remote notification path from provider to device
`After the device receives the notification (and after the final step shown in Figure 6-7), the system forwards the remote notification to your app.
`
`
`
`
`
`9
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 11 of 27 PageID #: 98
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (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.
`
`https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref
`/doc/uid/TP40008194-CH8-SW9
`
`
`
`10
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 12 of 27 PageID #: 99
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`Figure 6-3 illustrates using the HTTP/2-based APNs provider API to establish trust and using JWT provider authentication tokens for sending
`notifications. Figure 6-3 Establishing and using token-based provider connection trust.
`
`
`As shown in Figure 6-3, token-based provider trust works as follows:
`
`
`1.
`
`2.
`
`3.
`
`4.
`
`
`
`Your provider asks for a secure connection with APNs using transport layer security (TLS), represented as the arrow labeled “TLS
`initiation” in the figure.
`APNs then gives your provider an APNs certificate, represented by the next arrow in the figure (labeled “APNs certificate”), which
`your provider then validates.
`At this point, connection trust is established and your provider server is enabled to send token-based remote push notification requests
`to APNs.
`Each notification request that your provider sends must be accompanied by a JWT authentication token, represented in the figure as
`the arrow labeled “Notification push.”
`APNs replies to each push, represented in the figure as the arrow labeled “HTTP/2 response.”
`For specifics on the responses your provider can receive for this step, see HTTP/2 Response from APNs.
`
`Certificate-Based Provider-to-APNs Trust
`
`A certificate-based provider connection is valid for delivery to one specific app, identified by the topic (the app bundle ID) specified in the provider
`certificate (which you must have previously created, as explained in “Generate a universal APNs client SSL certificate” in Xcode Help). Depending
`on how you configure and provision the certificate, the trusted connection can also be valid for delivery of remote notifications to other items
`associated with your app, including Apple Watch complications for your apps, and for voice-over-Internet Protocol (VoIP) status notifications for
`your apps. APNs delivers these notifications even when those items are running in the background. See Communicating with APNs for details, and
`see Voice Over IP (VoIP) Best Practices in Energy Efficiency Guide for iOS Apps.
`
`With certificate-based trust, APNs maintains a certificate revocation list; if a provider’s certificate is on the revocation list, APNs can revoke provider
`trust (that is, APNs can refuse the TLS initiation connection).
`
`11
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 13 of 27 PageID #: 100
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`
`
`
`
`Figure 6-4 illustrates the use of an Apple-issued SSL certificate to establish trust between a provider and APNs.
`
`Unlike Figure 6-3, this figure does not show a notification push itself, but stops at the establishment of a Transport Layer Security (TLS) connection.
`In the certificate-based trust scheme, push notification requests are not authenticated but they are validated using the accompanying device token.
`Figure 6-4 – Establishing certificate-based provider connection trust.
`
`As shown in Figure 6-4, certificate-based provider-to-APNs trust works as follows:
`
`
`1.
`
`2.
`
`Your provider asks for a secure connection with APNs using transport layer security (TLS), represented as the arrow labeled “TLS
`initiation” in the figure.
`APNs then gives your provider an APNs certificate, represented by the next arrow in the figure (labeled “APNs certificate”), which
`your provider then validates.
`
`12
`
`
`
`
`
`3.
`
`4.
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 14 of 27 PageID #: 101
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`Your provider must then send its Apple-provisioned provider certificate (which you have previously obtained from your online
`developer account, as explained in “Generate a universal APNs client SSL certificate” in Xcode Help) back to APNs, represented as
`the arrow labeled “Provider certificate.”
`APNs then validates your provider certificate, thereby confirming that the connection request originated from a legitimate provider,
`and establishes your TLS connection.
`
`At this point, connection trust is established and your provider server is enabled to send certificate-based remote push notification
`requests to APNs.
`
`APNs-to-Device Connection Trust and Device Tokens
`
`Trust between APNs and each device is established automatically, without participation by your app, as described in this section.
`
`Each device has a cryptographic certificate and a private cryptographic key, provided by the operating system at initial device activation and stored in
`the device’s keychain. During activation, APNs authenticates and validates the connection to the device, based on the certificate and key, as shown in
`Figure 6-5.
`
`
`
`
`13
`
`
`
`
`
`
`Figure 6-5 - Establishing connection trust between a device and APNs
`
`As shown in Figure 6-5, APNs-to-device trust works as follows:
`
`
`1.
`2.
`3.
`
`Trust negotiation begins when the device initiates a TLS connection with APNs, as shown in the top arrow in the figure.
`APNs returns an APNs certificate to the device.
`The operating system validates this certificate and then, as shown in the “Device certificate” arrow, sends the device certificate to
`APNs.
`Finally, as indicated by the bottom arrow in the figure, APNs validates the device certificate, establishing trust.
`
`With a TLS connection established between APNs and the device, apps on the device can register with APNs to receive their app-specific device
`tokens for remote notifications. For details and code examples, see Registering to Receive Remote Notifications in Configuring Remote Notification
`Support.
`
`After receiving the device token, an app must connect to the app’s associated provider and forward the token to it. This step is necessary because a
`provider must include the device token later when it sends a notification request, to APNs, targeting the device. The code you write for forwarding
`the token is also shown in Registering to Receive Remote Notifications.
`
`Whether a user is activating a device for the first time, or whether APNs has issued a new device token, the process is similar and is shown in Figure
`6-6.
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 15 of 27 PageID #: 102
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`4.
`
`14
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 16 of 27 PageID #: 103
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`
`
`Figure 6-6 - Managing the device token
`
`https://www.oreilly.com/library/view/high-performance-browser/9781449344757/ch04.html
`
`
`
`Negotiating a secure TLS tunnel is a complicated process, and there are many ways to get it wrong. The good news is all the work just shown will be
`done for us by the server and the browser, and all we need to do is provide and configure the certificates.
`
`Having said that, while our web applications do not have to drive the preceding exchange, it is nonetheless important to realize that every TLS
`connection will require up to two extra roundtrips on top of the TCP handshake—that’s a long time to wait before any application data can be
`exchanged! If not managed carefully, delivering application data over TLS can add hundreds, if not thousands of milliseconds of network latency.
`
` OPTIMIZING TLS HANDSHAKE WITH SESSION RESUMPTION AND FALSE START
`
`15
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 17 of 27 PageID #: 104
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`New TLS connections require two roundtrips for a “full handshake” and CPU resources to verify and compute the parameters for the ensuing session.
`However, the good news is that we don’t have to repeat the “full handshake” in every case:
`
`• If the client has previously communicated with the server, an “abbreviated handshake” can be used, which requires one roundtrip and allows
`the client and server to reduce the CPU overhead by reusing the previously negotiated parameters for the secure session; see TLS Session
`Resumption.
`• False Start is an optional TLS protocol extension that allows the client and server to start transmitting encrypted application data when the
`handshake is only partially complete—i.e., once ChangeCipherSpec and Finished messages are sent, but without waiting for the other side to
`do the same. This optimization reduces new handshake overhead to one roundtrip; see TLS False Start.
`For best results, both optimizations should be used together to provide a single roundtrip handshake for new and returning visitors, plus
`computational savings for sessions that can be resumed based on previously negotiated session parameters.
`
`Session Identifiers
`
`The first Session Identifiers (RFC 5246) resumption mechanism was introduced in SSL 2.0, which allowed the server to create and send a 32-byte
`session identifier as part of its “ServerHello” message during the full TLS negotiation we saw earlier.
`
`Internally, the server could then maintain a cache of session IDs and the negotiated session parameters for each peer. In turn, the client could then
`also store the session ID information and include the ID in the “ClientHello” message for a subsequent session, which serves as an indication to the
`server that the client still remembers the negotiated cipher suite and keys from previous handshake and is able to reuse them. Assuming both the
`client and the server are able to find the shared session ID parameters in their respective caches, then an abbreviated handshake (Figure 4-3) can take
`place. Otherwise, a full new session negotiation is required, which will generate a new session ID.
`
`
`16
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 18 of 27 PageID #: 105
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`
`
`
`
`
`
`
`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.
`
`
`17
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 19 of 27 PageID #: 106
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`
`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.
`
`
`https://www.americanbanker.com/news/the-mobile-app-security-hole-that-should-keep-bankers-up-at-night
`
`https://www.firstcitybank.com/about-us/news/transport-layer-security-(tls)/
`
`https://www.altigen.com/tls-vs-ssl-what-protocol-should-you-be-using/
`
`https://threatpost.com/banking-apps-found-vulnerable-to-mitm-attacks/129105/
`
`According to the links above, banking apps use TLS, although they might use specialized hardened certificates to further strengthen the security.
`
`https://tools.ietf.org/html/rfc5246
`
`Client
`
`The application entity that initiates a TLS connection to a server. This may or may not imply that the client initiated the underlying transport
`connection. The primary operational difference between the server and client is that the server is generally authenticated, while the client is only
`optionally authenticated.
`
`Connection
`
` A
`
` connection is a transport (in the OSI layering model definition) that provides a suitable type of service. For TLS, such connections are peer-to-peer
`relationships. The connections are transient. Every connection is associated with one session.
`
` /* google: TCP connection termination*/
`
`https://vincent.bernat.ch/en/blog/2011-ssl-session-reuse-rfc5077
`
`To avoid a full TLS handshake each time a client request a resource, it is possible for the client to request an abbreviated handshake, saving a
`complete round-trip (100 ms) and avoiding the costliest part of the full TLS handshake.
`
`18
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 20 of 27 PageID #: 107
`Analysis of Infringement of U.S. Patent No. 6,574,239 by Capital One Financial Corporation
` (Based on Public Information Only)
`
`
`
`Endnote#3 - Payload Format of Push Notification Messages
`
`
`Abbreviated TLS handshake
`
`
`
`
`https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_updates_to_your_app_silently
`“If your app’s server-based content changes infrequently, or at irregular intervals, you can use silent notifications to notify your app when new content is
`available. A silent notification is a remote notification that doesn't display an alert, play a sound, or badge your app’s icon. It wakes your app in the
`background and gives it time to initiate downloads from your server and update its content.”
`
`https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CreatingtheNotificationPayload.html
`“To support a background update notification, make sure that the payload’s aps dictionary includes the content-available key with a value of 1. If
`there are user-visible updates that go along with the background update, you can set the alert, sound, or badge keys in the aps dictionary, as
`appropriate.
`
`
`19
`
`
`
`Case 4:20-cv-00307-SDJ Document 1-5 Filed 04/13/20 Page 21 of 27