`
`JENAM TECH, LLC’S FIRST AMENDED SET OF INFRINGEMENT CONTENTIONS
`
`U.S. Patent No. 10,951,742 – Google LLC
`Claims 1-3, 6, 10, 12, 15, 20-21, 27-28, 35, 39, 48, 51-52, 55-56, 63-65, 67-69, 71-78, 80, 83-84, 86, 88, 103-104, 159, 167-176
`
`Jenam Tech LLC (“Jenam”) provides evidence of infringement of claims 1-3, 6, 10, 12, 15, 20-21, 27-28, 35, 39, 48, 51-52, 55-
`56, 63-65, 67-69, 71-78, 80, 83-84, 86, 88, 103-104, 159, 167-176 of U.S. Patent No. 10,951,742 (hereinafter “the ’742 patent”) by
`Google LLC (“Google”). In support thereof, Jenam provides the following claim charts.
`“Accused Instrumentalities” as used herein refers to at least one or more websites or web addresses including, but not limited to
`www.google.com, stored and/or hosted on one or more servers owned or under the control of Google. For the sake of clarity, Jenam
`alleges that all of Google’s various websites, products, and platforms utilizing QUIC infringe the ’742 patent, including, but not limited
`to Google Edge Network, Google Cloud, Chrome Enterprise, G suite, Google Play, Chrome, Android (Android Enterprise, Android
`Messages (RCS)), Duo, Google Ads, Adwords, Google Analytics, Youtube, Google Mobile apps, Google shopping, and Google Maps.
`A list of Google’s “products” can be found at https://about.google/intl/en_us/products/. On information and belief, the Accused
`Instrumentalities referred to in the charts below are representative of Google’s use of QUIC in Google’s other websites, products and
`platforms. These claim charts demonstrate Google’s infringement, and provide notice of such infringement, by comparing each element
`of the asserted claims to corresponding components, aspects, and/or features of the Accused Instrumentalities. These claim charts are
`not intended to constitute an expert report on infringement. These claim charts include information provided by way of example, and
`not by way of limitation.
`The analysis set forth below is based only upon information from publicly available resources regarding the Infringing
`Instrumentalities. An analysis of Google’s (or other third parties’) technical documentation and/or software source code may assist in
`fully identify all infringing features and functionality. Accordingly, Jenam reserves the right to supplement this infringement analysis
`once such information is made available to Jenam. Furthermore, Jenam reserves the right to revise this infringement analysis, as
`appropriate, upon issuance of a court order construing any terms recited in the asserted claims.
` Unless otherwise noted, Jenam contends that Google directly infringes the ’742 patent in violation of 35 U.S.C. § 271(a) by
`selling, offering to sell, making, using, and/or importing the Infringing Instrumentalities. The following exemplary analysis demonstrates
`that infringement. Unless otherwise noted, Jenam further contends that the evidence below supports a finding of indirect infringement
`under 35 U.S.C. §§ 271(b) and/or (c), in conjunction with other evidence of liability under one or more of those subsections. Google
`makes, uses, sells, imports, or offers for sale in the United States, or has made, used, sold, imported, or offered for sale in the past,
`without authority, or induces others to make, use, sell, import, or offer for sale in the United States, or has induced others to make, use,
`sell, import, or offer for sale in the past, without authority products, equipment, or services that infringe claims 1-3, 6, 10, 12, 15, 20-
`21, 27-28, 35, 39, 48, 51-52, 55-56, 63-65, 67-69, 71-78, 80, 83-84, 86, 88, 103-104, 159, 167-176 of the ’742 patent, including without
`limitation, the Accused Instrumentalities.
`
`Page 1 of 422
`
`GOOGLE EXHIBIT 1017
`
`

`

`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`
` Unless otherwise noted, Jenam believes and contends that each element of each claim asserted herein is literally met through
`Google’s provision of the Infringing Instrumentalities. However, to the extent that Google attempts to allege that any asserted claim
`element is not literally met, Jenam believes and contends that such elements are met under the doctrine of equivalents. More specifically,
`in its investigation and analysis of the Infringing Instrumentalities, Jenam did not identify any substantial differences between the
`elements of the patent claims and the corresponding features of the Infringing Instrumentalities, as set forth herein. In each instance, the
`identified feature of the Infringing Instrumentalities performs at least substantially the same function in substantially the same way to
`achieve substantially the same result as the corresponding claim element.
`To the extent the chart of an asserted claim relies on evidence about certain specifically-identified Accused Instrumentalities,
`Jenam asserts that, on information and belief, any similarly-functioning instrumentalities also infringes the charted claim. Jenam reserves
`the right to amend this infringement analysis based on other products made, used, sold, imported, or offered for sale by Google. Jenam
`also reserves the right to amend this infringement analysis by citing other claims of the ’742 patent, not listed in the claim chart, that are
`infringed by the Accused Instrumentalities. Jenam further reserves the right to amend this infringement analysis by adding, subtracting,
`or otherwise modifying content in the “Accused Instrumentalities” column of each chart.
`
`
`Claim Claim Elements
`1
`An apparatus, comprising:
`a non-transitory memory
`storing instructions; and
`one or more processors in
`communication with the
`non-transitory memory,
`wherein the one or more
`processors execute the
`instructions to:
`
`Applicability
`Google uses an apparatus (e.g., a platform or device, including a QUIC-compliant server or
`client, etc.), comprising: a non-transitory memory storing instructions (e.g., server software,
`etc.), and one or more processors in communication with the non-transitory memory, wherein
`the one or more processors execute the instructions to:
`
`See excerpt(s) below, for example (emphasis added, if any):
`
`Note: Google admits that their “Google Cloud Platform” uses QUIC:
`
`"Google Cloud Platform Blog...
`
`we’re happy to be the first major public cloud to offer QUIC support for our HTTPS load
`balancers."
`https://cloudplatform.googleblog.com/2018/06/Introducing-QUIC-support-for-HTTPS-load-
`balancing.html
`
`
`July 1, 2021
`
`2 of 422
`
`Page 2 of 422
`
`

`

`
`Claim Claim Elements
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`Note: The “Google Cloud Platform” that, as established above, uses QUIC, is also used for
`ALL of Google’s services:
`
`“Google Cloud Platform (GCP), offered by Google (company), is a suite of cloud computing
`services that runs on the same infrastructure that Google uses internally for its end-user
`products, such as Google Search, Gmail, file storage, and YouTube”
`https://en.wikipedia.org/wiki/Google_Cloud_Platform
`
`Note: At least a portion of the citations herein are made to the QUIC standard found at:
`https://tools.ietf.org/html/draft-ietf-quic-transport-22, and/or https://tools.ietf.org/html/draft-
`ietf-quic-transport-27. Based upon information and belief, the pertinent portions of such
`version of the QUIC standard may also be found in one or more other versions. For
`completeness, all of the versions below (and future iterations thereof) are hereby incorporated
`by reference:
`
`https://tools.ietf.org/html/draft-ietf-quic-transport-00
`https://tools.ietf.org/html/draft-ietf-quic-transport-01
`https://tools.ietf.org/html/draft-ietf-quic-transport-02
`https://tools.ietf.org/html/draft-ietf-quic-transport-03
`https://tools.ietf.org/html/draft-ietf-quic-transport-04
`https://tools.ietf.org/html/draft-ietf-quic-transport-05
`https://tools.ietf.org/html/draft-ietf-quic-transport-06
`https://tools.ietf.org/html/draft-ietf-quic-transport-07
`https://tools.ietf.org/html/draft-ietf-quic-transport-08
`https://tools.ietf.org/html/draft-ietf-quic-transport-09
`https://tools.ietf.org/html/draft-ietf-quic-transport-10
`https://tools.ietf.org/html/draft-ietf-quic-transport-11
`https://tools.ietf.org/html/draft-ietf-quic-transport-12
`https://tools.ietf.org/html/draft-ietf-quic-transport-13
`https://tools.ietf.org/html/draft-ietf-quic-transport-14
`https://tools.ietf.org/html/draft-ietf-quic-transport-15
`
`July 1, 2021
`
`3 of 422
`
`Page 3 of 422
`
`

`

`
`Claim Claim Elements
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`https://tools.ietf.org/html/draft-ietf-quic-transport-16
`https://tools.ietf.org/html/draft-ietf-quic-transport-17
`https://tools.ietf.org/html/draft-ietf-quic-transport-18
`https://tools.ietf.org/html/draft-ietf-quic-transport-19
`https://tools.ietf.org/html/draft-ietf-quic-transport-20
`https://tools.ietf.org/html/draft-ietf-quic-transport-21
`https://tools.ietf.org/html/draft-ietf-quic-transport-22
`https://tools.ietf.org/html/draft-ietf-quic-transport-23
`https://tools.ietf.org/html/draft-ietf-quic-transport-24
`https://tools.ietf.org/html/draft-ietf-quic-transport-25
`https://tools.ietf.org/html/draft-ietf-quic-transport-26
`https://tools.ietf.org/html/draft-ietf-quic-transport-27
`
`Note: Though these contentions may refer to a specific version of the QUIC standard, the
`presented evidence is not exclusive to this specific version and is compliant with and/or
`supported by current versions of the QUIC standard, including
`QUIC_VERSION_IETF_RFC_V1 (https://datatracker.ietf.org/doc/html/draft-ietf-quic-
`transport-34), QUIC_VERSION_IETF_DRAFT_25
`(https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-25),
`QUIC_VERSION_IETF_DRAFT_27 (https://datatracker.ietf.org/doc/html/draft-ietf-quic-
`transport-27), QUIC_VERSION_IETF_DRAFT_28
`(https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-
`28), QUIC_VERSION_IETF_DRAFT_29 (https://datatracker.ietf.org/doc/html/draft-ietf-
`quic-transport-29), and/or QUIC_VERSION_50 which relies in part on
`IETF_QUIC_INVARIANTS_06 (https://tools.ietf.org/html/draft-ietf-quic-invariants-06)
`and/or IETF_QUIC_TRANSPORT_17 (https://tools.ietf.org/html/draft-ietf-quic-transport-
`17), each of which, upon information and belief, has been utilized by Google LLC through its
`accused instrumentalities.
`
`Note: Below is a web page of Google (https://www.google.com/).
`
`
`July 1, 2021
`
`4 of 422
`
`Page 4 of 422
`
`

`

`
`Claim Claim Elements
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`
`
`
`identify, at a first node,
`first information on which
`at least a first duration for
`detecting a first type of
`time period is based;
`
`
`
`
`Google uses an apparatus (e.g., a platform or device, including a QUIC-compliant server or
`client, etc.), configured to identify, at a first node (e.g., one of a QUIC-compliant server or
`client, etc.), first information (e.g., first value, etc.) on which at least a first duration (e.g.,
`duration associated with idle timeout in connection with 0-RTT packets, etc.) for detecting a
`first type of time period (e.g., idle-type timeout, etc.) is based;
`
`See excerpt(s) above and below, for example (emphasis added, if any):
`
`Note: As set forth below, since the idle_timeout value sets the duration of idleness, after
`which the connection is shutdown, a timeout attribute of the connection is necessarily
`detected based on the value received in the idle_timeout field of the connection negotiation
`packet.
`
`“idle_timeout (0x0001): The idle timeout is a value in milliseconds that is encoded as an
`integer; see (Section 10.2). If this parameter is absent or zero then the idle timeout is
`disabled.”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`
`July 1, 2021
`
`5 of 422
`
`Page 5 of 422
`
`

`

`
`Claim Claim Elements
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`“10. Connection Termination
`
`An established QUIC connection can be terminated in one of three ways:
`idle timeout (Section 10.2)
`•
`•
`immediate close (Section 10.3)
`• stateless reset (Section 10.4)
`An endpoint MAY discard connection state if it does not have a validated path on which it
`can send packets (see Section 8.2).”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`“10.2. Idle Timeout
`
`If the idle timeout is enabled, a connection is silently closed and the state is discarded when it
`remains idle for longer than both the advertised idle timeout (see Section 18.1) and three
`times the current Probe Timeout (PTO).
`
`Each endpoint advertises its own idle timeout to its peer. An endpoint restarts any timer it
`maintains when a packet from its peer is received and processed successfully. The timer is
`also restarted when sending a packet containing frames other than ACK or PADDING (an
`ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK-eliciting packets
`have been sent since last receiving a packet. Restarting when sending packets ensures that
`connections do not prematurely time out when initiating new activity.
`
`The value for an idle timeout can be asymmetric. The value advertised by an endpoint is only
`used to determine whether the connection is live at that endpoint. An endpoint that sends
`packets near the end of the idle timeout period of a peer risks having those packets discarded
`if its peer enters the draining state before the packets arrive. If a peer could timeout within a
`Probe Timeout (PTO; see Section 6.3 of [QUIC-RECOVERY]), it is advisable to test for
`liveness before sending any data that cannot be retried safely. Note that it is likely that only
`applications or application protocols will know what information can be retried.”
`
`July 1, 2021
`
`6 of 422
`
`Page 6 of 422
`
`

`

`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`“7.3.1. Values of Transport Parameters for 0-RTT
`
`Both endpoints store the value of the server transport parameters from a connection and apply
`them to any 0-RTT packets that are sent in subsequent connections to that peer, except for
`transport parameters that are explicitly excluded. Remembered transport parameters apply to
`the new connection until the handshake completes and the client starts sending 1-RTT
`packets. Once the handshake completes, the client uses the transport parameters established
`in the handshake.
`
`The definition of new transport parameters (Section 7.3.2) MUST specify whether they
`MUST, MAY, or MUST NOT be stored for 0-RTT. A client need not store a transport
`parameter it cannot process.
`
` A
`
` client MUST NOT use remembered values for the following parameters:
`original connection id, preferred address, stateless reset token, ack delay exponent and
`active_connection_id_limit. The client MUST use the server's new values in the handshake
`instead, and absent new values from the server, the default value.
`
` A
`
` client that attempts to send 0-RTT data MUST remember all other transport parameters
`used by the server. The server can remember these transport parameters, or store an integrity-
`protected copy of the values in the ticket and recover the information when accepting 0-RTT
`data. A server uses the transport parameters in determining whether to accept 0-RTT data.
`
`If 0-RTT data is accepted by the server, the server MUST NOT reduce any limits or alter any
`values that might be violated by the client with its 0-RTT data. In particular, a server that
`accepts 0-RTT data MUST NOT set values for the following parameters (Section 18.1) that
`are smaller than the remembered value of the parameters.
`
`
`
`Claim Claim Elements
`
`July 1, 2021
`
`7 of 422
`
`Page 7 of 422
`
`

`

`
`Claim Claim Elements
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`initial_max_data
`•
`•
`initial_max_stream_data_bidi_local
`•
`initial_max_stream_data_bidi_remote
`•
`initial_max_stream_data_uni
`•
`initial_max_streams_bidi
`•
`initial_max_streams_uni
`
`
`Omitting or setting a zero value for certain transport parameters can result in 0-RTT data
`being enabled, but not usable. The applicable subset of transport parameters that permit
`sending of application data SHOULD be set to non-zero values for 0-RTT. This includes
`initial max data and either initial max streams bidi and
`initial max stream data bidi remote, or initial max streams uni and
`initial max stream data uni.
`
` A
`
` server MUST either reject 0-RTT data or abort a handshake if the implied values for
`transport parameters cannot be supported.
`
`When sending frames in 0-RTT packets, a client MUST only use remembered transport
`parameters; importantly, it MUST NOT use updated values that it learns from the server's
`updated transport parameters or from frames received in 1-RTT packets. Updated values of
`transport parameters from the handshake apply only to 1-RTT packets. For instance, flow
`control limits from remembered transport parameters apply to all 0-RTT packets even if
`those values are increased by the handshake or by frames sent in 1-RTT packets. A server
`MAY treat use of updated transport parameters in 0-RTT as a connection error of type
`PROTOCOL_VIOLATION.”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`“3.3. Session resumption versus Keep-alive
`
`
`July 1, 2021
`
`8 of 422
`
`Page 8 of 422
`
`

`

`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`Because QUIC is encapsulated in UDP, applications using QUIC must deal with short idle
`timeouts. Deployed stateful middleboxes will generally establish state for UDP flows on the
`first packet state, and keep state for much shorter idle periods than for TCP. According to a
`2010 study ([Hatonen10]), UDP applications can assume that any NAT binding or other state
`entry will be expired after just thirty seconds of inactivity.
`
` A
`
` QUIC application has three strategies to deal with this issue:
`
`
`
`•
`
`Ignore it, if the application-layer protocol consists only of interactions with no or very
`short idle periods.
`• Ensure there are no long idle periods.
`• Resume the session after a long idle period, using 0-RTT resumption when appropriate.
`...
`Alternatively, the client (but not the server) can use session resumption instead of sending
`keepalive traffic. In this case, a client that wants to send data to a server over a connection
`idle longer than the server's idle timeout (available from the idle timeout transport
`parameter) can simply reconnect. When possible, this reconnection can use 0-RTT session
`resumption, reducing the latency involved with restarting the connection. This of course only
`applies in cases in which 0-RTT data is safe, when the client is the restarting peer, and when
`the data to be sent is idempotent.”
`https://www.ietf.org/id/draft-ietf-quic-applicability-07.txt
`
`Google uses an apparatus (e.g., a platform or device, including a QUIC-compliant server or
`client, etc.), configured to allocate a first resource (e.g. a storage and/or data structure for
`storing connection IDs, a connection state, send/recv buffers, etc.) for a first non-
`Transmission Control Protocol (non-TCP) connection (e.g., QUIC connection, etc.);
`
`See excerpt(s) above and below, for example (emphasis added, if any):
`
`
`
`Claim Claim Elements
`
`
`
`allocate a first resource for
`a first non-Transmission
`Control Protocol (non-
`TCP) connection;
`
`July 1, 2021
`
`9 of 422
`
`Page 9 of 422
`
`

`

`
`Claim Claim Elements
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`“Google Cloud Platform (GCP), offered by Google (company), is a suite of cloud computing
`services that runs on the same infrastructure that Google uses internally for its end-user
`products, such as Google Search, Gmail, file storage, and YouTube”
`https://en.wikipedia.org/wiki/Google Cloud Platform
`
`
`
`
`generate a first non-TCP
`packet including a first
`parameter field identifying
`first metadata for use in
`determining a second
`duration for detecting the
`first type of time period;
`
`
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-07
`
`Google uses an apparatus (e.g., a platform or device, including a QUIC-compliant server or
`client, etc.), configured to generate a first non-TCP packet (e.g., first QUIC negotiation
`packet, etc.) including a first parameter field (e.g., first idle_timeout parameter field, etc.)
`identifying first metadata (e.g., first idle timeout value, etc.) for use in determining a second
`duration (e.g., duration associated with idle timeout in connection with 1-RTT packets, etc.)
`for detecting the first type of time period (e.g., idle-type timeout, etc.);
`
`See excerpt(s) above and below, for example (emphasis added, if any):
`
`Note: As set forth below, a QUIC negotiation packet includes transport parameters that
`include an idle_timeout parameter that is detected by a recipient of such packet.
`
`“7.3. Transport Parameters
`
`During connection establishment, both endpoints make authenticated declarations of their
`transport parameters. These declarations are made unilaterally by each endpoint. Endpoints
`
`July 1, 2021
`
`10 of 422
`
`Page 10 of 422
`
`

`

`
`Claim Claim Elements
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`are required to comply with the restrictions implied by these parameters; the description of
`each parameter includes rules for its handling.”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`
`July 1, 2021
`
`
`
`11 of 422
`
`Page 11 of 422
`
`

`

`
`Claim Claim Elements
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`“18. Transport Parameter Encoding
`
`The format of the transport parameters is the TransportParameters struct from Figure 15. This
`is described using the presentation language from Section 3 of [TLS13].
`
`enum {
` original_connection_id(0),
` idle_timeout(1),
` stateless_reset_token(2),
` max_packet_size(3),
` initial_max_data(4),
` initial_max_stream_data_bidi_local(5),
` initial_max_stream_data_bidi_remote(6),
` initial_max_stream_data_uni(7),
` initial_max_streams_bidi(8),
` initial_max_streams_uni(9),
` ack_delay_exponent(10),
` max_ack_delay(11),
` disable_migration(12),
` preferred_address(13),
` active_connection_id_limit(14),
` (65535)
`} TransportParameterId;”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`Note: As set forth below, since the idle_timeout value sets the duration of idleness, after
`which the connection is shutdown, a timeout attribute of the connection is necessarily
`
`July 1, 2021
`
`12 of 422
`
`Page 12 of 422
`
`

`

`
`Claim Claim Elements
`
`
`
`set up the first non-TCP
`connection, by sending,
`from the first node to a
`
`July 1, 2021
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`modified based on the value received in the idle_timeout field of the connection negotiation
`packet.
`
`“idle_timeout (0x0001): The idle timeout is a value in milliseconds that is encoded as an
`integer; see (Section 10.2). If this parameter is absent or zero then the idle timeout is
`disabled.”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`“QUIC provides reliable, ordered delivery of the cryptographic handshake data. QUIC packet
`protection is used to encrypt as much of the handshake protocol as possible. The
`cryptographic handshake MUST provide the following properties:
`
`• authenticated key exchange, where
`o a server is always authenticated,
`o a client is optionally authenticated,
`o every connection produces distinct and unrelated keys,
`o keying material is usable for packet protection for both 0-RTT and 1-RTT
`packets, and
`o 1-RTT keys have forward secrecy
`• authenticated values for the transport parameters of the peer (see Section 7.3)
`• authenticated negotiation of an application protocol (TLS uses ALPN [RFC7301] for this
`purpose)”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`Google uses an apparatus (e.g., a platform or device, including a QUIC-compliant server or
`client, etc.), configured to set up the first non-TCP connection (e.g., QUIC connection, etc.),
`by sending, from the first node (e.g., one of a QUIC-compliant server or client, etc.) to a
`
`13 of 422
`
`Page 13 of 422
`
`

`

`
`Claim Claim Elements
`second node, the first non-
`TCP packet to provide the
`first metadata to the
`second node, for use by
`the second node in
`determining the second
`duration for detecting the
`first type of time period;
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`second node (e.g., the other one of the QUIC-compliant server or client, etc.), the first non-
`TCP packet (e.g., first QUIC negotiation packet, etc.) to provide the first metadata (e.g., first
`idle timeout value, etc.) to the second node, for use by the second node in determining the
`second duration (e.g., duration associated with idle timeout in connection with 1-RTT
`packets, etc.) for detecting the first type of time period (e.g., idle-type timeout, etc.);
`
`See excerpt(s) above and below, for example (emphasis added, if any):
`
`Note: As set forth below, a QUIC negotiation packet includes transport parameters that
`include an idle_timeout parameter that is detected by a recipient of such packet.
`
`“7.3. Transport Parameters
`
`During connection establishment, both endpoints make authenticated declarations of their
`transport parameters. These declarations are made unilaterally by each endpoint. Endpoints
`are required to comply with the restrictions implied by these parameters; the description of
`each parameter includes rules for its handling.”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`
`July 1, 2021
`
`14 of 422
`
`Page 14 of 422
`
`

`

`
`Claim Claim Elements
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`
`
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`“QUIC provides reliable, ordered delivery of the cryptographic handshake data. QUIC packet
`protection is used to encrypt as much of the handshake protocol as possible. The
`cryptographic handshake MUST provide the following properties:
`
`July 1, 2021
`
`15 of 422
`
`Page 15 of 422
`
`

`

`
`Claim Claim Elements
`
`
`
`in response to detecting,
`based on the first duration
`and by the first node
`during at least a portion of
`the first non-TCP
`connection including at
`least a portion of the first
`non-TCP connection set
`up, a first time period of
`the first type of time
`period, at least partially
`close the first non-TCP
`connection, by releasing,
`by the first node, the first
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`
`• authenticated key exchange, where
`o a server is always authenticated,
`o a client is optionally authenticated,
`o every connection produces distinct and unrelated keys,
`o keying material is usable for packet protection for both 0-RTT and 1-RTT
`packets, and
`o 1-RTT keys have forward secrecy
`• authenticated values for the transport parameters of the peer (see Section 7.3)
`• authenticated negotiation of an application protocol (TLS uses ALPN [RFC7301] for this
`purpose)”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`Google uses an apparatus (e.g., a platform or device, including a QUIC-compliant server or
`client, etc.), configured to, in response to detecting, based on the first duration (e.g., duration
`associated with idle timeout in connection with 0-RTT packets, etc.) and by the first node
`(e.g., one of a QUIC-compliant server or client, etc.) during at least a portion of the first non-
`TCP connection (e.g., QUIC connection, etc.) including at least a portion of the first non-
`TCP connection set up, a first time period (e.g., idle timeout in connection with 0-RTT
`packets, etc.) of the first type of time period (e.g., idle-type timeout, etc.), at least partially
`close (e.g., terminate, etc.) the first non-TCP connection, by releasing, by the first node, the
`first resource (e.g. a storage and/or data structure for storing connection IDs, a connection
`state, send/recv buffers, etc.) allocated for the first non-TCP connection;
`
`See excerpt(s) above and below, for example (emphasis added, if any):
`
`Note: As set forth below, since the idle_timeout value sets the duration of idleness, after
`which the connection is shutdown, a timeout attribute of the connection is necessarily
`
`July 1, 2021
`
`16 of 422
`
`Page 16 of 422
`
`

`

`
`Claim Claim Elements
`resource allocated for the
`first non-TCP connection;
`
`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`detected based on the value received in the idle_timeout field of the connection negotiation
`packet.
`
`“idle_timeout (0x0001): The idle timeout is a value in milliseconds that is encoded as an
`integer; see (Section 10.2). If this parameter is absent or zero then the idle timeout is
`disabled.”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`“10. Connection Termination
`
`An established QUIC connection can be terminated in one of three ways:
`idle timeout (Section 10.2)
`•
`•
`immediate close (Section 10.3)
`• stateless reset (Section 10.4)
`An endpoint MAY discard connection state if it does not have a validated path on which it
`can send packets (see Section 8.2).”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`“10.2. Idle Timeout
`
`If the idle timeout is enabled, a connection is silently closed and the state is discarded when it
`remains idle for longer than both the advertised idle timeout (see Section 18.1) and three
`times the current Probe Timeout (PTO).”
`QUIC: A UDP-Based Multiplexed and Secure Transport https://tools.ietf.org/html/draft-ietf-
`quic-transport-22
`
`“7.3.1. Values of Transport Parameters for 0-RTT
`
`
`July 1, 2021
`
`17 of 422
`
`Page 17 of 422
`
`

`

`CLAIM CHARTS
`BASED ON INFRINGEMENT ANALYSIS OF GOOGLE
`U.S. Patent No. 10,951,742
`
`Applicability
`Both endpoints store the value of the server transport parameters from a connection and apply
`them to any 0-RTT packets that are sent in subsequent connections to that peer, except for
`transport parameters that are explicitly excluded. Remembered transport parameters apply to
`the new connection until the handshake completes and the client starts sending 1-RTT
`packets. Once the handshake completes, the client uses the transport parameters established
`in the handshake.
`
`The definition of new transport parameters (Section 7.3.2) MUST specify whether they
`MUST, MAY, or MUST NOT be stored for 0-RTT. A client need not store a transport
`parameter it cannot process.
`
` A
`
` client MUST NOT use remembered values for the following parameters:
`original connection id, preferred address, stateless reset token, ack delay exponent and
`active_connection_id_limit. The client MUST use the server's new values in the handshake
`instead, and absent new values from the server, the default value.
`
` A
`
` client that attempts to send 0-RTT data MUST remember all other transport parameters
`used by the server. The server can remember these transport parameters, or store an integrity-
`protected copy of the values in the ticket and recover the information when accepting 0-RTT
`data. A server uses the transport parameters in determining whether to accept 0-RTT data.
`
`If 0-RTT data is accepted by the server, the server MUST NOT reduce any limits or alter any
`values that might be violated by the client with its 0-R