SYSTEMS AND METHODS FOR DATA PROCESSING. STORAGE, AND RETRIEVAL
FROM A SERVER Cross Reference to Related Applications
[1] This application is a continuation-in-part, and claims the benefit of priority, of United States Patent Application No. 16/660,761, filed on October 22, 2019, currently pending, which is incorporated herein by reference in its entirety.
BACKGROUND Technical Field
[2] The present disclosure relates to systems and methods for establishing data communication with a data storage provider and for exchanging data with the data storage provider. More particularly, various embodiments of the present disclosure relate to transmitting video data to and from the data storage provider. Background Information
[3] Direct to home (DTH) broadcasting occurs when content providers transmit data using satellites (such as satellite television or satellite radio), and digital terrestrial television (DTT) broadcasting occurs when content providers transmit data (e.g., digital television data) over the air with broadcast towers. Combined with cable broadcasts (e.g., using auxiliary cables to cable boxes), these technologies remain a primary source for content distribution to consumers. [4] In addition to DTH, DTT, and cable, over the top (OTT) services include multimedia content providers that stream content directly to viewers over the Internet, bypassing telecommunications, multichannel television, and broadcast television platforms that traditionally act as a content controller or distributor. Users have widely embraced OTT services, such as web-based and video-on-demand services, as alternatives to traditional multimedia platforms.
[5] Developers and broadcasters have turned to digital rights management (DRM) techniques to securely distribute content using OTT services. For example, an application on a user device, such as a smartphone, laptop, or the like, may use a key, certificate, or other encryption protocol to receive copyrighted content and decode the same for playback. Some OTT services may allow for non-transitory storage of copyrighted content on a user device for offline playback. [6] Existing encryption techniques face important challenges that limit the flexibility of storing content transmitted using DTH, DTT, and cable technology. User devices are often not

allowed to transmit or store copyrighted content without encryption. For example, users may retain the key, certificate, or other encryption protocol on the user device to prevent a third party from obtaining unauthorized access to the contents of the encrypted content. However, this leads to redundancies if the user stores the copyrighted content remotely, e.g., using a cloud service or the like. In particular, the remote storage must store each and every user's copy of the copyrighted content in full because the remote storage is unable to determine overlapping (also referred to as common or equivalent) content. Further, reducing the transmission of copyrighted content may reduce security risks, and may lead to better network utilization and storage efficiency. For example, transmitted copyrighted content may be intercepted on a network, and, in some cases, may be decrypted by a bad actor. Therefore, traditional approaches for storing data may result in vulnerabilities and redundancies for copyrighted content. [7] These challenges are also present for content from OTT systems or when DTH, DTT, or cable technologies cooperate with OTT systems for upload and remote storage of content. For example, the same redundancies and vulnerabilities occur if copyrighted content from an OTT system is uploaded to remote storage.
[8] The disclosed systems and methods for recognition, storage, and transmission of encrypted data structures address one or more of the problems set forth above and/or other problems in the prior art.
SUMMARY [9] Embodiments consistent with the present disclosure provide systems and methods for establishing data communication with a data storage provider and for exchanging data with the data storage provider.
[10] Disclosed embodiments may include any one of the following embodiments alone or in combination with one or more other embodiments, whether implemented as a method, by at least one processor, and/or stored as executable instructions on non transitory computer readable media.
[11] Consistent with a disclosed embodiment, a method for identifying a data segment is provided. The method is performed by at least one processor and comprises receiving a first data segment associated with a first recording time, the first data segment comprising one or more first data packets, wherein a starting first data packet includes a first time reference value. The method further includes receiving a second data segment associated with a second recording

time, the second data segment comprising one or more second data packets, wherein a starting second data packet includes a second time reference value. The method also comprises comparing the first recording time with the second recording time, the first time reference value with the second time reference value, wherein comparing the first time reference value and the second time reference value comprises determining whether the first time reference value matches identically the second time reference value. Further, the method includes comparing a first length enumeration for the first data packets with a second length enumeration for the second data packets, wherein comparing the first length enumeration and the second length enumeration comprises determining whether the first length enumeration matches identically the second length enumeration. Also, the method includes determining, based on the comparing a match between the first data segment and the second data segment; and identifying the first data segment as the same as the second data segment based on the determining. [12] Further, consistent with a disclosed embodiment, the method may include evaluating a time metric by computing an absolute value of a difference between the first recording time and the second recording time, wherein the determining further is based on the evaluated time metric, and wherein the identifying further is based on the time metric is within a threshold range. [13] In an example embodiment, the first time reference value comprises a system clock reference of the first data segment, and the second time reference value comprises a system clock reference of the second data segment.
[14] In an example embodiment, the first time reference value comprises a program clock reference of the first data segment, and the second time reference value comprises a program clock reference of the second data segment.
[15] In an example embodiment, the first time reference value comprises a presentation timestamp of the first data segment, and the second time reference value comprises a presentation timestamp of the second data segment.
[16] In an example embodiment, the first length enumeration comprises a number of packets in the first data segment, and the second length enumeration comprises a number of packets in the second data segment.
[17] In an example embodiment, the first length enumeration comprises a number of packets for the first data segment, and the second length enumeration comprises a number of packets for the second data segment.

[18] In an example embodiment, the first length enumeration comprises a first many-to-one
mapping rule between the number of packets for the first data segment and a first unique integer
number, and wherein the second length enumeration comprises a second many-to-one mapping
rule between the number of packets for the second data segment and a second unique integer
number, and wherein the first many-to»one mapping rule is the same as the second many-to-one
mapping rule.
[19] Consistent with a disclosed embodiment, a method for identifying a data segment, the
method being performed by at least one processor comprises receiving a first and a second group
of data segments each data segment in the first and the second group being defined by segment
parameters, the segment parameters comprising a time at which each data segment in the first or
the second group was received, a length enumeration for each data segment in the first or the
second group, and a starting time reference value identified within each data segment in the first
or the second group. The method includes for each first data segment from the first group
determining a matching second data segment from the second group by comparing first segment
parameters of the first data segment with second segment parameters of the second data segment,
resulting in a matching set of pairs of data segments.
[20] Consistent with a disclosed embodiment, the method may further comprise identifying
the matching set of pairs of data segments based on canonical segment parameters.
[21] In an example embodiment, the canonicalized segment parameters for a matching pair of
the first data segment and the second data segment are determined by selecting a time at which
the first data segment was received as a canonical time, selecting a length enumeration for the
first data segment as a canonical data segment length, and selecting a starting time reference
value identified within the first data segment as a canonical starting time reference.
[22] In an example embodiment, the length enumeration comprises a number of packets for
the first data segment.
[23] Consistent with a disclosed embodiment, the method may further comprise determining a
group of pairs from the matching set of pairs.
[24] In an example embodiment, comparing the first segment parameters with the second
segment parameters comprises comparing a first starting time reference value of the first
parameters with a second starting time reference value of the second parameters and determining

whether the first starting time reference value matches identically the second starting time reference value.
[25] In an example embodiment, comparing the first segment parameters with the second segment parameters comprises comparing a first length enumeration of the first parameters and a second length enumeration of the second parameters and detenrnning whether the first length enumeration matches identically the second length enumeration.
[26] In an example embodiment, comparing the first segment parameters with the second segment parameters comprises determining an absolute value of a difference between a first time of the first parameters and a second time of the second parameters, and deterrnining whether the absolute value is below a time threshold.
[27] Consistent with a disclosed embodiment, a method of splitting a data stream into a set of data segments is provided. The method is performed by at least one processor, and includes receiving the data stream, wherein the data stream comprises data packets, with at least some of the data packets having time identifiers, selecting a segment time period and a time domain, subdividing the time domain into a set of time blocks, each one of the set of time blocks having a duration of the segment time period, identifying a set of starting data packets corresponding to the set of time blocks, wherein each one of the set of starting data packets comprises a first data packet having a time identifier in a corresponding each one of the set of time blocks, identifying a set of finishing data packets corresponding to the set of starting data packets, wherein each identified one of the set of finishing data packets immediately precedes each one, except a first one, of the set of starting data packets, identifying a last one of the set of finishing data packets being a last data packet of a last one of the set of time blocks; and identifying the set of data segments based on the corresponding set of starting data packets and the corresponding set of finishing data packets.
[28] In an example embodiment, a data segment from the set of data segments includes a corresponding starting data packet from the set of starting data packets, a corresponding finishing data packet from a set of finishing data packets, and all data packets of the data stream located between the corresponding starting data packet and the corresponding finishing data packet. [29] In an example embodiment, the segment time period is in a range of one to tens of seconds.

[30] In an example embodiment, the segment time period is determined by a number, such
that the segment time period is substantially an exponentiation of two in a power of the number
divided by a frequency of a clock.
[31] In an example embodiment, the data stream comprises compressed video data, and
wherein the clock is a system time clock associated with a decoder for the compressed video
data.
[32] In an example embodiment, the data stream comprises compressed video data, and
wherein the clock is a program clock reference associated with a decoder for the compressed
video data.
[33] In an example embodiment, the data stream comprises compressed video data, and
wherein the clock is a presentation timestamp associated with a decoder for the compressed
video data.
[34] In an example embodiment, the time identifiers identify time positions of the video data,
and wherein the time positions substantially match time values obtained from the system time
clock being one of a program clock reference or a presentation timestamp.
[35] In an example embodiment, the data stream comprises an MPEG-2 transport stream of
the data packets communicated via a network.
[36] Consistent with a disclosed embodiment, the method may further comprise determining a
probability of a data packet being missed from a data segment during the communication of the
data stream and selecting the segment time period such that a probability of the data packet being
missed from the data segment is less than a target probability value.
[37] Consistent with a disclosed embodiment, the method may further comprise determining
an overhead cost associated with the processing of the data segment and selecting the segment
time period such that the overhead cost is less than a target overhead value.
[38] Consistent with a disclosed embodiment, the method may further comprise for a time
segment period determining a probability of a data packet being missed from a data segment
having the segment time period, determining an overhead cost associated with the processing of
the data segment, and based on a cost function associated with the probability and the overhead
cost, determining a target time segment period that minimizes the cost function.
[39] Consistent with a disclosed embodiment, a method of splitting a data stream into a set of
data segments is provided. The method may be performed by at least one processor and includes

receiving the data stream, wherein the data stream comprises data packets of a fixed length, with
at least some of the data packets having bit number identifiers, selecting a segment length unit
and a total length, subdividing the total length into a set of length blocks, each one of the set of
length blocks having a length of the segment length unit, identifying a set of starting data packets
corresponding to the set of length blocks, wherein each one of the set of starting data packets
comprises a first data packet having a bit number identifier in a corresponding each one of the set
of length blocks, identifying a set of finishing data packets correspondmg to the set of starting
data packets, wherein each identified one of the set of finishing data packets immediately
precedes each one, except a first one, of the set of startmg data packets, identifying a last one of
the set of finishing data packets as being a last data packet of a last one of the set of length
blocks, and identifying the set of data segments based on the correspondmg set of starting data
packets and the corresponding set of finishing data packets.
[40] In an example embodiment, a data segment from the set of data segments includes a
corresponding starting data packet from the set of starting data packets, a corresponding finishing
data packet from a set of finishing data packets, and all the data packets of the data stream
located between the corresponding starting data packet and the correspondmg finishing data
packet.
[41] In an example embodiment, the segment length unit is determined by a number, such that
the segment length unit is substantially an exponentiation of two in a power of the number.
[42] In an example embodiment, the data stream comprises a transport stream of the data
packets communicated via a network to a user device.
[43] Consistent with a disclosed embodiment, the method may further comprise determining a
probability of a data packet being missed from a data segment during the communication of the
data stream and selecting the segment length unit such that a probability of the data packet being
missed from the data segment is less than a target probability value.
[44] Consistent with a disclosed embodiment, the method may further comprise determining
an overhead cost associated with the processing of a data segment and selecting the segment
length unit such that the overhead cost is less than a target overhead value.
[45] Consistent with a disclosed embodiment, the method may further comprise for a segment
length unit determining a probability of a data packet being missed from a data segment having
the segment length unit, determining an overhead cost associated with the processing of the data

segment, and based on a cost function associated with the probability and the overhead cost, determining a target segment length unit that minimizes the cost function. [46] Consistent with a disclosed embodiment, a method of selectively decrypting encrypted data is provided. The method is performed by at least one processor and includes identifying a first encrypted data bit and a last encrypted data bit associated with a portion of encrypted data, identifying a first encrypted block including the first encrypted data bit, and a first counter associated with the first encrypted block, identifying a last encrypted block including the last encrypted data bit, and a last counter associated with the last encrypted block, identifying a set of encrypted blocks, the set of encrypted blocks including the first encrypted block, the last encrypted block, and a set of all encrypted blocks located between the first and the last encrypted block, identifying a set of counters corresponding to the set of encrypted blocks, the set of counters including the first counter, the last counter, and a plurality of counters located between the first and the last counter, wherein a bitwise length of each one of the plurality of counters is the same as a bitwise length of each one of the set of encrypted blocks, selecting a plurality of encrypted data bits between and including the first encrypted data bit and the last encrypted data bit. The method further includes for each encrypted data bit from the plurality of encrypted data bits determining a corresponding encrypted block and a block number that contains the encrypted data bit, determining a corresponding counter for the determined block number, determining a bit position of the encrypted data bit within the determined encrypted block, selecting a counter bit at the bit position within the counter, encrypting the counter, and executing an XOR operation between the encrypted data bit and the corresponding encrypted counter bit.
[47] In an example embodiment, identifying the first encrypted block comprises determining a first bit number associated with the first encrypted data bit, and determining a first block number, the determining based on the first bit number and a block length, wherein the first block number corresponds to the first encrypted block.
[48] In an example embodiment, identifying the last encrypted block comprises determining a last bit number associated with the last encrypted data bit, and determining a last block number, the determining based on the last bit number and a block length, wherein the last block number corresponds to the last encrypted block. [49] In an example embodiment, the counter is encrypted using a cipher key.

[50] In an example embodiment, the cipher key is locally available to the at least one hardware processor.
[51] In an example embodiment, the encrypted data is encrypted using a block cipher counter mode.
[52] In an example embodiment, the encrypted data is encrypted using a random initialization vector.
[53] In an example embodiment, any one of the plurality of counters comprises a first part and a second part, the first part being the initialization vector, and the second part being a counter increment.
[54] Consistent with a disclosed embodiment a method of selectively encrypting a portion of data is provided. The method is performed by at least one hardware processor and comprises identifying a first data bit and a last data bit associated with a portion of data, identifying a first block including the first data bit, and a first counter associated with the first block, identifying a last block including the last data bit, and a last counter associated with the last block, identifying a set of blocks, the set of blocks including the first block, the last block, and a set of all blocks located between the first and the last block, identifying a set of counters corresponding to the set of blocks, the set of counters including the first counter, the last counter, and a plurality of counters located between the first and the last counter, wherein a bitwise length of each one of the plurality of counters is the same as a bitwise length of each one of the set of blocks, selecting a plurality of data bits between and including the first data bit and the last data bit. The method further comprises for each data bit from the plurality of data bits determining a corresponding block and a block number that contains the data bit, determining a corresponding counter for the determined block number, determining a bit position of the data bit within the determined block, selecting a counter bit at the bit position within the counter, encrypting the counter, and executing an XOR operation between the data bit and the corresponding encrypted counter bit. [55] In an example embodiment, identifying the first block comprises determining a first bit number associated with the first data bit, and determining a first block number, the determining based on the first bit number and a block length, wherein the first block number corresponds to the first block, and wherein lengths for all blocks of the data are the same.

[56] In an example embodiment, the first block number is a ceiling of a result of dividing the
first bit number by the block length, wherein a starting block number of the data is assigned to
one.
[57] In an example embodiment, identifying the last block comprises determining a last bit
number associated with the last data bit, and detenriining a last block number, the determining
based on the last bit number and a block length, wherein the last block number corresponds to
the last block, and wherein lengths for all blocks of the data are the same.
[58] In an example embodiment, the last block number is a ceiling of a result of dividing the
last bit number by the block length, wherein a starting block number of the data is assigned to
one.
[59] In an example embodiment, the set of counters are encrypted using a cipher key, resulting
in a set of encrypted counters.
[60] In an example embodiment, a cipher key is locally available to the at least one hardware
processor.
[61] Consistent with a disclosed embodiment, a method of selectively encrypting a portion of
data is provided. The data is subdivided into a set of blocks, each block having a corresponding
block number. In an example embodiment, the method is performed by at least one hardware
processor and includes identifying a one-to-one mapping for mapping a block number to a
unique block identifier, wherein a bitwise length of the unique block identifier is the same as a
bitwise length of each one of the set of blocks, identifying a first data bit and a last data bit
associated with the portion of the data, identifying a first block including the first data bit,
identifying a last block including the last data bit, identifying a set of blocks including the first
and the last blocks, and a set of all blocks located between the first and the last blocks. The
method may further include for each data bit from a plurality of data bits located between and
including the first data bit and the last data bit determining a corresponding block and a block
number that contains the data bit, determining a unique block identifier for the determined block
number, determining a bit position of the data bit within the determined block, selecting a unique
block identifier bit at the bit position within the unique block identifier, encrypting the unique
block identifier; and executing an XOR operation between the data bit and the corresponding
encrypted unique block identifier bit.

[62] In an example embodiment, the one-to-one mapping is created using a random number generator with a random seed being the cipher key.
[63] In an example embodiment, the one-to-one mapping is created using a function that takes as an input the block number and at least one unique parameter associated with one of a user or a device of the user and returns a unique block identifier.
[64] In an example embodiment, the unique parameter includes a unique device identification. [65] In an example embodiment, the unique block identifier is encrypted using a cipher key. [66] In an example embodiment, the unique block identifier comprises a first part and a second part, wherein the first part being an initialization vector and the second part being a result of the one-to-one mapping.
[67] Consistent with a disclosed embodiment, a method of authenticating data received from a user device by a service provider is provided. The method is performed by at least one processor of the service provider and includes receiving user credentials from the user device via a secure communication channel, upon verifying the user credentials, providing to the user device via the secure channel a permission token, wherein the permission token includes at least a shared secret, wherein a data within the permission token is not observable to the user device and a shared secret data outside the data of the permission token, the shared secret data observable to the user device. The method further includes receiving a request from the user device via a non¬secure communication channel, wherein the request comprises at least the permission token and a hash digest formed using at least a portion of the shared secret data.
[68] In an example embodiment, the permission token is encrypted based on a cryptographic key maintained by the service provider and not made available to the user device. [69] In an example embodiment, the shared secret data includes a sequence number. [70] In an example embodiment, the shared secret data includes one of an increment algorithm or a download challenge, or both the increment algorithm and the download challenge. [71] In an example embodiment, the permission token includes secret data, the secret data representing at least a period of validity of the permission token.
[72] In an example embodiment, the request includes information about video data, and wherein the permission token includes information regarding a channel identification comprising one of a broadcast channel identification or a broadcast program related to the video data.

[73] Consistent with a disclosed embodiment, the method may further comprise upon
successfully verifying the sequence number and the permission token, completing the request,
communicating to the user device that the sequence number requires to be incremented, wherein
the incrementation is carried out using the increment algorithm, and updating a local copy of the
sequence number by incrementing the sequence number via the increment algorithm.
[74] In an example embodiment, the increment algorithm comprises adding an integer to the
sequence number.
[75] In an example embodiment, the request comprises a request to offload a data segment.
[76] In an example embodiment, the request comprises a proof that the user device is in
possession of the data segment, and wherein the shared secret data and the proof are used to form
the hash digest.
[77] In an example embodiment, the request comprises a segment identification for the data
segment.
[78] In an example embodiment, the request comprises a broadcast channel identification.
[79] In an example embodiment, the request comprises a hash digest computed based on at
least one of a proof that the user device is or was in possession of the data segment, a segment
identification for the data segment, the sequence number, or a broadcast channel identification.
[80] In an example embodiment, the request comprises a hash digest computed based on all of
a proof that the user device is in possession of the data segment, a segment identification for the
data segment, the sequence number, and a channel identification.
[81] In an example embodiment, completing the request to upload the data segment comprises
providing to the user device a challenge for offloading the data segment, wherein the challenge
comprises a request for one or more bits of data of the data segment, receiving a communication
from the user device, wherein a proof for the received challenge is included in a hash digest, and
upon verifying the hash digest based on a local copy of a proof, authorizing the user device to
offload the data segment.
[82] In an example embodiment, at least some data communicated over the non-secure
communication channel between the user device and the service provider is encrypted using a
user device-based encryption key.
[83] In an example embodiment, the service provider has access to a user-device based
encryption key.

[84] In an example embodiment, the request comprises a request to download a data segment. [85] In an example embodiment, completing the request to download the data segment comprises providing to the user device a challenge for downloading the data segment, wherein the challenge comprises a request for one or more bits of data of the data segment, receiving a communication from the user device, wherein a proof for the received challenge is included in a hash digest, and upon verifying the hash digest based on a local copy of a proof, authorizing the user device to download the data segment.
[86] Consistent with disclosed embodiment, a system for exchanging data securely between a user device and a server is provided. The system includes server instructions, wherein at least one processor of the server performs the server instructions resulting in server operations comprising receiving a user credential from the user device via a secure communications channel, upon verifying the user credentials, providing to the user device via the secure channel, a permission token, wherein the permission token includes at least a sequence number, wherein a data within the permission token is not observable to the user device, and the sequence number outside the data of the permission token, the sequence number observable to the user device. The server operations may further comprise receiving a request from the user device via a non-secure communication channel, wherein the request comprises at least the permission token and a hash digest formed using in part the sequence number, verifying the request by verifying the sequence number and the permission token. Further, the system includes at least one processor of the user device configured to perform operations comprising providing the user credential to the server via the secure communications channel, receiving the permission token via the secure communications channel, forming the request to the server, and providing the permission token and the hash digest to the server via the non-secure communications channel. [87] In an example embodiment, at least one processor of the user device is configured to perform operations further comprising forming a hash digest computed based on at least a proof that the user device is in possession of the data segment, a segment identification for the data segment, the sequence number, or a broadcast channel identification.
[88] In an example embodiment, the request comprises a request to upload a data segment. [89] In an example embodiment, the server operations further comprise upon verifying the hash digest using the local copy of the proof, authorizing the user device to upload the data segment.

[90] In an example embodiment, comprising providing to the user device via the secure channel a challenge and an increment algorithm.
[91] In an example embodiment, the user device is further configured to perform operations comprising forming the proof based on the provided challenge and providing the permission token and the proof to the server via the non-secure communications channel. [92] Consistent with a disclosed embodiment, a method of authenticating data received from a user device by a service provider is provided. The method is performed by at least one processor of the service provider and includes receiving user credentials from the user device via a secure communication channel, upon verifying the user credentials, providing to the user device via the secure channel a handle to a permission token, wherein the permission token includes at least a shared secret, wherein a data within the permission token is not observable to the user device, and a shared secret data outside the data of the permission token, the shared secret data observable to the user device. The method may further include receiving a request from the user device via a non-secure communication channel, wherein the request comprises at least the handle to the permission token and a hash digest of the shared secret data. The method may further include verifying the request by comparing the hash digest received from the user device with a computed hash digest, wherein the computed hash digest is obtained using data obtained by retrieving the permission token using the handle to the permission token. [93] Consistent with a disclosed embodiment, a method for offloading a data segment comprises receiving a request from a user device to offload the data segment, the request including a probe request wherein the probe request includes a segment identification. The method includes sending a probe response to the user device, the probe response comprising an approval or decline of an action to be executed by the user device, the action being one of an upload, or a request to retry offloading the data segment at a later time. Further the method includes sending a challenge to the user device.
[94] In an example embodiment, the challenge comprises a request for one or more bits of data of the data segment.
[95] In an example embodiment, the probe request includes a segment identification formed using a recording time for the data segment, a reference time value for the data segment, and a length enumeration for the data segment.

[96] Consistent with a disclosed embodiment, the method may further comprise requestmg the
user device to store the challenge, and a user device proof, wherein the challenge and the user
device proof is specific to the data segment.
[97] In an example embodiment, the upload is declined if data corresponding to the data
segment is known to be recoverable from a server.
[98] Consistent with a disclosed embodiment, the method may further comprise determining
whether the segment identification matches one of the segment identifications associated with
one of the local copies of data segments recoverable from a server.
[99] Consistent with a disclosed embodiment, the method may further comprise determining
that the action is an approval of the upload when the segment identification does not match any
of the segment identifications associated with one of the local copies of data segments
recoverable from a server.
[100] Consistent with a disclosed embodiment, the method may fiirther comprise determining
that the action is a decline of the upload when the segment identification matches at least one of
segment identifications associated with one of the local copies of data segments recoverable
from a server.
[101] In an example embodiment, the challenge is unique for the user device.
[102] In an example embodiment, the challenge is generated for the user device based on an
identification of the user device.
[103] Consistent with a disclosed embodiment, the method may further comprise authenticating
the user device before receiving the request from the user device.
[104] Consistent with a disclosed embodiment, the method may further comprise receiving the
data segment and the segment identification information when the probe response to the user
device indicates that the upload is approved.
[105] Consistent with a disclosed embodiment, the method may further comprise receiving
uploaded data, the uploaded data comprising information used to obtain a user device content
key, wherein the content key is configured to partially decrypt the data segment.
[106] Consistent with a disclosed embodiment, the method may further comprise notifying the
user device that the uploaded data is received after receiving the uploaded data.
[107] In an example embodiment, the data segment is encrypted commutatively with at least
the content key and a common key.

[108] Consistent with a disclosed embodiment, the method may further comprise the uploaded
data comprises a local server copy of the data segment, the local server copy of the data segment
is stored at a storage device associated with the local server, the local server copy of the data
segment being encrypted only by the common key.
[109] Consistent with disclosed embodiment, a method for providing a data segment for
downloading to a user device may include receiving a request from the user device to download
the data segment, the request comprising a data segment identification and a user device proof,
obtaining a content key, encrypting a local server copy of the data segment with the content key,
generating a server proof based on the encrypted local server copy of the data segment and a
challenge, comparing the user device proof with the server proof. The method may further
comprise, when the user device proof matches the server proof, providing the user device with
the local server copy of the data segment, and when the user device proof does not match the
server proof, either requesting the user device to retry downloading the data segment at a later
time, or notifying the user device that the data segment cannot be downloaded.
[110] Consistent with a disclosed embodiment, the method may further comprise authenticating
the user device before receiving the request from the user device.
[Ill] In an example embodiment, the server proof is generated using the received challenge.
[112] In an example embodiment, the challenge comprises a request for one or more bits of the
data segment extracted starting at a particular bit position in the data segment.
[113] In an example embodiment, the challenge is configured to be unique for each user device.
[114] In an example embodiment, the challenge is received as a part of the request.
[115] In an example embodiment, determining whether the user device proof matches the
server proof comprises comparing the one or more bits of data of the data segment with the one
or more bits of the local server copy of the data segment.
[116] In an example embodiment, determining whether the user device proof matches the
server proof comprises comparing a result of a hash digest of the one or more bits of data of the
data segment obtained by the user device with a result of the hash digest of the one or more bits
of the local server copy of the data segment obtained by a server.
[117] Consistent with disclosed embodiment, a method for providing a data segment for
downloading to a user device may include receiving a request from the user device to download
the data segment, the request comprising a data segment identification and a user device proof,

obtaining a content key, generating a server proof based on a local server copy of the data segment and a challenge, encrypting the server proof using the content key, comparing the user device proof with the encrypted server proof. The method may further comprise when the user device proof matches the encrypted server proof, providing the user device with the local server copy of the data segment and when the user device proof does not match the encrypted server proof, either requesting the user device to retry downloading the data segment at a later time, or notifying the user device that the data segment cannot be downloaded.
[118] Additional objects and advantages of the disclosed embodiments will be set forth in part in the following description and will be apparent from the description or may be learned by practice of the embodiments. The objects and advantages of the disclosed embodiments may be realized and attained by the elements and combinations set forth in the claims. [119] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS [120] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate various disclosed embodiments. In the drawings:
[121] Fig. 1 is a block diagram of an exemplary system for establishing data communication with a data storage provider and for exchanging data with the data storage provider, consistent with disclosed embodiments.
[122] Fig. 2A is a block diagram of an exemplary remote storage server, consistent with disclosed embodiments.
[123] Fig. 2B is a block diagram of an exemplary client device, consistent with disclosed embodiments.
[124] Fig. 3 is an exemplary diagram of a system for authentication and data communication, consistent with disclosed embodiments.
[125] Fig. 4A is an exemplary diagram of a data communication system, consistent with disclosed embodiments.
[126] Fig. 4B is an exemplary diagram of a process of a client device downloading data from a server, consistent with disclosed embodiments.

[127] Fig. 4C is an exemplary diagram of a challenge-proof process for data communication,
consistent with disclosed embodiments.
[128] Fig. 4D is another exemplary diagram of a challenge-proof process for data
communication, consistent with disclosed embodiments.
[129] Fig. 5A is an exemplary diagram of a process for offloading data to a server, consistent
with disclosed embodiments.
[130] Fig. 5B is another exemplary diagram of a process for offloading data to a server,
consistent with disclosed embodiments.
[131] Fig. 6 depicts data segments corresponding to a portion of a broadcast program,
consistent with disclosed embodiments.
[132] Fig. 7 depicts an example process for offloading data to a server, consistent with
disclosed embodiments.
[133] Fig. 8A depicts an example process for downloading data from a server, consistent with
disclosed embodiments.
[134] Fig. 8B depicts another example process for downloading data from a server, consistent
with disclosed embodiments.
[135] Figs. 9A-9G depict various steps for recording broadcast data, submitting probe requests,
receiving probe requests, and uploading data to a server, consistent with disclosed embodiments.
[136] Fig. 10 depicts a process for downloading data from a server, consistent with disclosed
embodiments.
[137] Fig. 11A is an exemplary diagram of a client device communicating with a server,
consistent with disclosed embodiments.
[138] Fig. 11B is an exemplary diagram of a structure of a token, consistent with disclosed
embodiments.
[139] Fig. 12 is an exemplary process of offloading data to a server using permission token
authentication, consistent with disclosed embodiments.
[140] Fig. 13 depicts components of a permission token and related data for digital signature,
consistent with disclosed embodiments.
[141] Fig. 14 is an exemplary diagram of a process of authentication, consistent with disclosed
embodiments.

[142] Fig. 15 is another exemplary diagram of a process of authentication, consistent with
disclosed embodiments.
[143] Fig. 16 is an exemplary diagram of a data communication system, consistent with
disclosed embodiments.
[144] Fig. 17 is an exemplary diagram of a process of detemiining a match between data
segments, consistent with disclosed embodiments.
[145] Fig. 18 depicts exemplary data segments having data packets, consistent with disclosed
embodiments.
[146] Fig. 19 is an exemplary diagram of a process of identifying matching data segments,
consistent with disclosed embodiments.
[147] Fig. 20 depicts exemplary data segments having data packets, consistent with disclosed
embodiments.
[148] Fig. 21 is an exemplary diagram of a process of partitioning the data stream into data
segments, consistent with disclosed embodiments.
[149] Fig. 22 is an exemplary diagram of aprocess of identifying data segments, consistent
with disclosed embodiments.
[150] Fig. 23 depicts an exemplary diagram of a process of partitioning a data stream into data
segments, consistent with disclosed embodiments.
[151] Fig. 24 is an exemplary diagram of aprocess of identifying data segments, consistent
with disclosed embodiments.
[152] Fig. 25 depicts another exemplary diagram of a process of partitioning a data stream into
data segments, consistent with disclosed embodiments.
[153] Fig. 26 depicts a schematic diagram of an exemplary encryption process of a counter
mode, consistent with disclosed embodiments.
[154] Fig. 27 depicts a schematic diagram of an exemplary decryption process of a counter
mode, consistent with disclosed embodiments.
[155] Fig. 28 depicts a flow chart of an exemplary process for selective decrypting of a portion
of encrypted data, consistent with disclosed embodiments.
[156] Fig. 29 depicts a flow chart of an exemplary process for selective encrypting of a portion
of data, consistent with disclosed embodiments.

DETAILED DESCRIPTION
[157] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. While several illustrative embodiments are described herein, modifications, adaptations and other implementations are possible. For example, substitutions, additions or modifications may be made to the components illustrated in the drawings, and the illustrative methods described herein may be modified by substituting, reordering, removing, or adding steps to the disclosed methods. Accordingly, the following detailed description is not limited to the disclosed embodiments and examples. Instead, the proper scope is defined by the appended claims.
[158] The present disclosure is generally directed to systems and methods that enhance efficiency associated with transmitting and storing data that contains common content. In some embodiments, the disclosed systems and methods improve flexibility and security for copyrighted content by enhancing communication security when transmitting copyrighted content. For example, the disclosed systems and methods may use double encryption when copyrighted content is transmitted to allow for the transmission of one of the encryption keys with the content without risk of exposing the original unencrypted content. Moreover, the disclosed systems and methods may withhold transmission of at least one of the necessary keys to retain benefits provided by double encryption and allow for single encryption storage once the encrypted content is received. Further, the disclosed systems and methods may also increase flexibility by enabling a remote service to detect overlaps in copyrighted content without decryption, and can also be easily integrated with existing content delivery infrastructure, whether DTH, DTT, or cable transmission; OTT infrastructure; or other multimedia delivery techniques.
[159] Although described above and below using double encryption, embodiments of the present disclosure may use any number of keys for encryption. For example, a client device may use additional keys to provide additional layers of encryption before sending a data structure (as well as the additional keys) to remote storage. Additionally, or alternatively, the remote storage may apply one or more keys locally to the remote storage when storing encrypted content. [160] Multimedia content can be transmitted to client devices as data structures. In this description, data structures may refer to, for example, content segments (such as HLS segments),

information chunks (such as PNG, IFF, MP3, and/or AVI files), URI fragments, URI queries, HTML5 fragments, and/or CSS3 fragments, etc.
[161] To prevent unauthorized access to these data structures, existing systems, such as OTT infrastructure or cable networks, apply encryption such that only client devices (e.g., smartphones, tablets, laptops, auxiliary cable devices, or the like) having a particular key may decrypt the data structures and view the content therein. For example, the encryption may comprise asymmetric encryption such that the private key used by the client device to decrypt is distinct from the public key used by a content distributor to encrypt the data structures. In other embodiments, the encryption may comprise symmetric encryption such that the key used by the client device to decrypt is the same key used by the content distributor to encrypt the data structures.
[162] Remote storages, such as cloud services, may not store cleartext versions of content (i.e., an unencrypted content that is also referred to as a cleartext content or cleartext) without violating the copyright of the content. However, this may result in numerous redundancies if multiple users store overlapping (also referred to as equivalent) copyrighted content that is encrypted on the remote storage because the remote storage may then include multiple copies of the equivalent (or common) content encrypted with different keys or schemes. To solve these technical problems, the disclosed methods and systems enable storing content when content is determined to correspond to broadcast data. Thus, the remote storage may determine overlap in encrypted content without having access to the cleartext content, which may be copyrighted. For example, some embodiments of the disclosed techniques include generating a common key for use by client devices in further encrypting already encrypted content, whose cleartext version may be copyrighted. The remote storage may lack access to the common key (or to the private key of a common key pair in embodiments using asymmetric encryption). Accordingly, the key is common because multiple client devices may have access to the key, while the remote storage lacks access. In embodiments where the common key comprises the private key of a key pair, the remote storage may have access to the public key but does not have access to the private key, which is shared amongst client devices.
[163] Because in some embodiments client devices may encrypt the already encrypted data structures with the common key, the common key may be configured for commutative application with the keys typically used by the client devices for viewing the copyrighted

content. In such embodiments, the common key and/or the keys (whether one, two, or any number of keys) typically used by the client devices may comprise self-inverses. Additionally or alternatively, the common key and the keys typically used by the client devices may provide homomorphic encryption such that the remote storage may perform one or more operations (such as hash verification or calculation of a segment identifier using a hash) on the data structures without decrypting the same. Regardless of whether one or more of the keys are self-inverses, client devices may provide the individual keys typically used to the remote storages, but not the common key, ensuring that the client devices do not compromise the security of the copyrighted content. The remote storage may then recognize common content because it may remove encryption with the keys typically used by the client devices but does not have access to the common key (or to a private key of a common key pair in embodiments using asymmetric encryption).
[164] Therefore, while allowing for storing of copyrighted content on remote storage, some embodiments of the disclosed systems and methods still allow for the security of the copyrighted content, taking advantage of commutative encryption technology. Thus, the disclosed systems and methods can provide a scalable and affordable technique that can easily be integrated into existing content delivery infrastructure while reducing redundancy on remote storage units. Further, in some embodiments, the double encryption that allows the secure, remote storage of copyrighted content may increase security during transmission of the same. In addition, some embodiments may include additional layers of encryption using keys local to client devices and/or to remote storages.
[165] The disclosed systems and methods may be applicable to multiple content delivery schemes and may be adaptable to different delivery infrastructures. For example, the disclosed systems and methods can be used with multiple encoding, encryption, and packaging technologies. In some embodiments, the disclosed techniques may be applied to constant bitrate (CBR), adaptive bitrate (ABR), and variable bitrate (VBR) encodings. Moreover, the disclosed techniques may be employed with multiple packaging technologies such as Common Media Application Format (CMAF), MPEG-DASH, MPEG-2 transport stream (TS), HTTP Live Streaming (HLS), among others. Further, the disclosed systems and methods may be independent of the streaming mode used by the client. For example, the disclosed systems and

methods may apply to any received or stored data structures subject to encryption, e.g., on account of a license required because the data structures include copyrighted content. [166] Further, to reduce exposure of copyrighted information in transmission or storage, the disclosed systems and methods may use hardware and/or software isolation on a client device (e.g., a trusted execution environment (TEE)) such that a portion of the client device encrypting a data structure including the copyrighted information with a common key is isolated from a portion of the client device decrypting the data structure including the copyrighted information using a first key, e.g., associated with a DRM license. Further, in such embodiments, the disclosed systems and methods may prevent all portions of the client device not using the first key (e.g., all portions not used for consumption of the copyrighted information by the user) from accessing a cleartext version of the data structure.
[167] The disclosed systems and methods improve the technical field of storing content (e.g., multimedia content, images, text, or the like) remotely and solve technical problems associated with redundancies in storing encrypted data structures. In some embodiments, the disclosed systems and methods modify the conventional operation of client devices and remote storages with an encryption scheme that avoids revealing cleartext data structures but also permits recognition of common content from different client devices. Thus, the disclosed methods and systems may improve the efficiency of the remote storages by reducing redundant storages. The arrangement in the disclosed techniques may improve the resource utilization and minimize computer expenditures (e.g., processing, bandwidth, storage, etc.). These features not only result in more efficient systems that improve the storage of content but also enhance the user experience.
[168] Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings.
[169] Fig. 1 is a block diagram of an exemplary system 100, consistent with disclosed embodiments. In system 100, a content distributor 140 may comprise a DTH transmitter, DTT transmitter, cable service, or any other content delivery service using a one-way network, such as network 190, to provide content (e.g., copyrighted content) included in one or more data structures to clients (e.g., via client devices 150). Additionally or alternatively, content distributor 140 may comprise an OTT service using a two-way network, such as network 170, to

provide copyrighted content included in one or more data structures to clients (e.g., via client devices 150).
[170] Client devices 150 may include set-top boxes (STB) or set-top units (STU), customer premises equipment (CPE), and the like, such as receivers 141 and 142 configured to perform one or more operations consistent with disclosed embodiments. For example, client devices 150 may receive content from content distributors 140 over one-way network 190 or two-way network 170 using a receiver (e.g., receiver 142), and generate and display content in interfaces via display devices included in client devices 150. For example, client devices 150 may include a display (such as a television 151, a smartphone 152, or a monitor 153) to output content received from content distributors 140. Receivers 141-142 may be configured to record content and facilitate storage of content at server 110, as further discussed below. It should be appreciated that receivers 141 and 142 may be updated. For example, receiver 142 serving devices 154,151, and 152 may be replaced by a new model. Additionally or alternatively, a hardware or firmware of receiver 142 may be updated. When receiver 142 is updated it may be authenticated with server 110 using any suitable approach (e.g., by a service provider via a phone call from a user, via an authentication software, and the like). In some cases, a household having receiver 142 may get a second receiver that may be configured to server devices 154,151, and 152 (or other household devices). In some cases, two receivers may serve one client device. In some cases, client devices 152 may be configured to connect and disconnect from a particular receiver. [171] Additionally or alternatively, client devices 150 may include one or more computing devices configured to perform one or more operations consistent with disclosed embodiments. For example, in some cases, a client device (e.g., client device 154) may include a receiver software that allows client device 154 to perform functions of a receiver. Client devices 150 may include a desktop computer, a laptop, a server, a mobile device (e.g., tablet, smartphone, etc.), a gaming device, a wearable computing device, or another type of computing device. Client devices 150 may include one or more processors configured to execute software instructions stored in memory, such as memory included in client devices 150, to perform operations to implement the functions described below. Client devices 150 may be configured for wired and/or wireless communications and may include software that, when executed by a processor, performs internet-related communication (e.g., TCP/IP) and content display processes. For instance, client devices 150 may execute browser software that generates and displays interfaces

including content on a display device included in, or connected to, client devices 150. Client devices 150 may execute applications that allow client devices 150 to communicate with content distributors 140 over a two-way network 170 or one-way network 190 and generate and display content in interfaces via display devices included in client devices 150. For example, client devices 150 may display a media player to output content received from content distributors 140. [172] Whether comprising STBs and STUs or computing devices, client devices 150 may further execute applications that allow client devices 150 to communicate with components over network 170, and upload content to and download content from remote storage server 110. For example, client devices 150 may display a cloud interface to provide for uploads to and downloads from remote storage server 110. Client devices 150 are further described in connection with Fig. 2B.
[173] System 100 may include a remote storage server 110. Remote storage server 110 is further described in connection with Fig. 2A. In one exemplary configuration, remote storage server 110 may include one or more computing systems configured to perform operations consistent with handling content uploads from client devices 150 as well as content downloads to client devices 150. In some embodiments, remote storage server 110 may receive encrypted content from client devices 150, where the cleartext version of the encrypted content is copyrighted. For example, client devices 150 may request to upload encrypted data structures whose cleartext versions include a movie, a TV show, a song, a book, or the like, using an appropriate secure request (e.g., a secure HTTP request, an FTP request, or the like). Remote storage server 110 may provide infrastructure and components to receive the uploaded resource and securely store the same on behalf of client devices 150. In such embodiments, remote storage server 110 may verify that the user of client devices 150 has adequate authorization to remotely store encrypted versions of the content (e.g., by verifying a license associated with DRM technology, verifying proof to access the content, or the like).
[174] In some embodiments, remote storage server 110 may prepare elements of system 100 for remote storage of encrypted content whose cleartext version is copyrighted. For example, remote storage server 110 may instruct client devices 150 to use a common key—which may allow for commutative encryption with the encryption from one or more other keys used by client devices 150 to encrypt the copyrighted content—that is used to keep uploaded content secret from remote storage server 110. For example, the common key may be accessible by client devices

150 but not remote storage server 110 through a key distribution center (KDC) or any other system distributing the common key to client devices 150 or may be derived by client devices 150 using a key determining or generating technique. Additionally or alternatively, the common key may be used in asymmetric encryption technology such that the common key comprising the private key of a key pair and is only accessible or provided to client devices 150. In such embodiments, the public key of the key pair may also be accessible to client devices 150 for encryption and optionally to remote storage server 110 because remote storage server 110 may not decrypt information using the public portion of the common key. In such embodiments, as further described below in connection with Figs. 3, client devices 150 may provide the key used by client devices 150 to encrypt the copyrighted content to remote storage server 110. Accordingly, remote storage server 110 may partially decrypt content from client devices 150, identify corresponding content, and reduce redundant storage. For example, a "partial decryption" may comprise removing one or more layers of encryption from one or more keys while leaving one or more additional layers of encryption from one or more additional keys. Remote storage server 110 still cannot access fully decrypted content on account of its lack of access to the common key used by client devices 150 for double encryption. Some embodiments may include additional layers of encryption from client devices 150 and/or from remote storage server 110.
[175] Fig. 1 shows client devices 150 connected to remote server 110 using two-way network 170. In such embodiments, client devices 150 may transmit keys to server 110 used by client devices 150 to encrypt copyrighted content (e.g., using separate ports on network 170, using separate upload protocols such as HTTP rather than FTP or the like, using different packet groups sent at different times, or the like). In some cases, keys may be delivered within the HTTP request to upload or download content. These keys may be, for example, sent as HTTP headers. In various cases, these keys may be securely delivered to server 110 (i.e., delivered such that a person-in-a-middle may not obtain these keys or disrupt transmission of the keys). Additionally, or alternatively, client devices 150 may connect to remote storage server 110 using one or more additional networks that are at least partially distinct from two-way network 170. For example, client devices 150 may use a cellular connection (e.g., using long term evolution (LTE), 4G, or the like) in addition to a wired connection (e.g., using ethernet or the like) and/or a different wireless connection (e.g., using a WiFi protocol, a Bluetooth® protocol, or the like).

Although these networks may share components (e.g., using the same Internet backbone), they may still be at least partially distinct, as explained above. In another example, client devices 150 may upload the keys using a different route of servers on the Internet or other computer network that may be used for uploading the encrypted content whose cleartext version includes copyrighted content.
[176] hi some embodiments, as shown in Fig. 1, components of system 100 may be connected to a two-way network 170. Moreover, as shown in Fig. 1, other components of system 100 may additionally or alternatively be connected to a one-way network 190.
[177] In an example embodiment, server 110 may have access to a database. The database may include one or more computing devices configured with appropriate software to perform operations consistent with providing remote storage server 110 data for performing transactions with client devices 150. The database may include, for example, Oracle™ databases, Sybase™ databases, or other relational databases or non-relational databases, such as Dynamo™ DB, Hadoop™ sequence files, HBase™, or Cassandra™. The database may include computing components (e.g., database management system, database server, etc.) configured to receive and process requests for data stored in memory devices of the database(s) and to provide data from the database(s). The database may be included in, or otherwise related to, remote storage server 110. For example, elements of the database may be embodied in one or more non-transitory media forming part of remote storage server 110.
[178] The database may be configured to collect and/or maintain the data uploaded by users from client devices 150. For example, the database may store data structures uploaded by users via remote storage server 110 and (in some cases) data uploaded by content distributors 140. Thus, the database may collect the data from a variety of sources, including, for instance, content distributors 140 and/or remote storage server 110. In some cases, remote storage server 110 may be physically separate from one or more database(s).
[179] Using a database may be one possible approach. Alternatively, data uploaded by users may be stored using any other suitable means (e.g., a file system). In an example embodiment, the data may be stored as a part of an Amazon Simple Storage Service (Amazon S3), or any other suitable storage.
[180] Fig. 1 shows client devices 150 as singular devices. However, client devices 150 may be implemented as combinations of different devices. For example, elements in one of client

devices 150 may be embodied in an STB or STU, such as a cable box, communicating with a user computing device, such as a laptop or desktop.
[181] Two-way network 170 may be any type of network configured to provide communications between components of system 100. For example, network 170 may be any type of network (including infrastructure) that provides communications, exchanges information, and/or facilitates the exchange of information, such as the Internet, a Local Area Network, or other suitable connection(s) that enables the sending and receiving of information between the components of system 100. One-way network 190 may be any type of network configured to allow one component of system 100 to broadcast information to another component of system 100. For example, network 190 may be any type of network (including infrastructure) that provides frequency bands or other means of transmission for content to move from a broadcaster (such as content distributors 140) to receivers (such as client devices 150). In other embodiments, one or more components of system 100 may communicate directly through a dedicated communication link(s).
[182] It is to be understood that the configuration and boundaries of the functional building blocks of system 100 have been defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[183] Fig. 2A shows a block diagram of a remote storage server 110 (Fig. 1), consistent with disclosed embodiments. Remote storage server 110 may include a communication device 210, a server memory 220, a server processor 230, and a persistent storage 240. Server memory 220 may include encryption programs 222, cache memory 224, a client request processing program 226, a content key 232, a content segment identifier 234, and an indexer 236. Server processor 230 may use information stored in server memory 220 for various operations (e.g., processing client requests, encrypting/decrypting content, and the like).
[184] In some embodiments, remote storage server 110 may take the form of a server, a general purpose computer, a mainframe computer, or any combination of these components. In other embodiments, remote storage server 110 may be a virtual machine, container instance, or

serverless code (e.g., based on AWS™, Azure™, IBM Cloud™, etc.). Other implementations consistent with disclosed embodiments are possible as well.
[185] Communication device 210 may be configured to communicate with one or more databases, such as databases 180 (Fig. 1) described above, and other elements of system 100 either directly or via network 170. In particular, communication device 210 may be configured to receive data structures from client devices 150 (Fig. 1). Further, communication device 210 may be configured to receive user account information from client devices 150 to verify an identity of client device 150 before storing the data structures. Additionally, or alternatively, communication device 210 or a separate communication device (not shown) may be configured to communicate with other components as well, including, for example, content distributors 140. [186] Communication device 210 may include, for example, one or more digital and/or analog devices that allow communication device 210 to communicate with and/or detect other components, such as a network controller and/or wireless adaptor for communicating over the Internet. Other implementations consistent with disclosed embodiments are possible as well. [187] Server memory 220 may include one or more storage devices configured to store instructions used by server processor 230 to perform functions related to disclosed embodiments. For example, server memory 220 may store software instructions, such as encryption programs 222, that may perform operations when executed by server processor 230. The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, server memory 220 may include a single encryption program 222 that performs the functions of remote storage server 110, or encryption programs 222 may comprise multiple programs. Server memory 220 may also use cache memory 224 to store encrypted content and/or for encryption programs 222. For example, cache memory 224 may include copies of encrypted content that have been received from client devices 150 but not yet indexed and stored. Additionally, or alternatively, cache memory 224 may include copies of encrypted content retrieved from database(s) 180 before transmission to client devices 150. For example, with the encrypted content stored in cache memory 224, remote storage server 110 may quickly respond to user content requests. In such embodiments, locally storing encrypted content enables handling transactions without additional traffic and reduces latency.
[188] In certain embodiments, server memory 220 may store client request processing program 226 which may include sets of instructions for carrying out processes to partially decrypt content

stored in cache memory 224, perform user authentication or verification tasks, and/or interact with databases 180 to store and index uploaded content as well as retrieve content to respond to user requests. In certain embodiments, server memory 220 may store sets of instructions for requesting content from content distributors 140 in response to user requests to store such content. Other instructions are possible as well. In general, instructions may be executed by server processor 230 to perform processes consistent with disclosed embodiments. [189] In some embodiments, server processor 230 may include one or more processing devices such as, but not limited to, microprocessors such as ARM, Xeon™, Turion™, Intel Core family, AMD Ryzen family, or any other suitable processors, including graphical processing units (GPU) from other manufacturers. However, in other embodiments, server processor 230 may be a plurality of devices coupled and configured to perform functions consistent with the disclosure. For example, server processor 230 may include a plurality of co-processors, each configured to run specific remote storage server 110 operations such as floating-point arithmetic, graphics, signal processing, string processing, cryptography, or I/O interfacing.
[190] In some embodiments, server processor 230 may execute software to perform functions associated with remote storage server 110. In some embodiments, server processor 230 may include multiple components configured to execute various functions of remote storage server 110. In such embodiments, each component may be a hardware device configured to specifically process data or perform operations of processing transactions. While an example embodiment, as shown in Fig. 2A, describes content key 232, indexer 236, and content segment identifiers 234 stored at server memory 220, in an alternative embodiment, some of the data (e.g., content key) may be stored on processor cache or registers. In some cases, indexer 236 may be included in a central processing unit (CPU) or a field-programmable gate array (FPGA). Other hardware combinations are also possible. In yet other embodiments, combinations of hardware and software may be used to implement server processor 230.
[191] Content key 232 may comprise a key received from an example client device along with encrypted content. Herein, content key 232 may also be referred to as a local user key. [192] Content key 232 may allow encryption programs 222 to partially decrypt the received content. For example, encryption with content key 232 may commute with encryption with a common key such that the received content is double encrypted (or even further encrypted with additional content keys not shown in Fig. 2A). Accordingly, encryption programs 222 may

partially decrypt the received content using content key 232 such that the partially decrypted content is still encrypted with the common key, to which remote storage server 110 lacks access. [193] Content segment identifiers 234 (e.g., URIs) may comprise one or more data structures received from client devices 150 identifying content whose encrypted versions are received by remote storage server 110. Accordingly, content segment identifiers 234 may be extracted using any tool for the identification of data structures from client devices 150. For example, content segment identifiers 234 may identify content using a secure token, a hash, a cookie, or an equivalent technique for identification. Additionally or alternatively, content segment identifiers 234 may comprise a universally unique identifier (UUID), a certificate, or any other data structure uniquely identifying the content whose encrypted versions are received by remote storage server 110. Additionally or alternatively, content segment identifiers 234 may be extracted using any tool for the verification of authorization by client devices 150 and/or users of those devices to upload particular content. For example, content segments identifiers 234 may be included in proof to access or a license to use particular data structures. [194] Indexer 236 may include one or more software implemented processes that identify portions of databases assigned to (or otherwise associated with) content segment identifier 234. For example, communication device 210 may receive encrypted content from client devices 150. Using content segment identifier 234 associated with the received content, indexer 236 may determine if the content is stored in the databases. If not available, remote storage server 110 may store a partially decrypted version of the received encrypted content in association with content segment identifier 234. If available, remote storage server 110 may decline to store a new copy of the partially decrypted content. In such embodiments, storing a single copy of the content reduces storage redundancy.
[195] In some embodiments, encryption programs 222 may further partially decrypt the received content in order to verify the partially decrypted content. For example, indexer 236 may verify the partially decrypted content against an available copy already associated with content segment identifier 234. Alternatively, indexer 236 may verify the partially decrypted content against an expected hash signature or other identifiers of integrity within a data file if there is no available copy already associated with content segment identifier 234. [196] The components of remote storage server 110 may be implemented in hardware, software, or a combination of both. For example, although one or more components of remote

storage server 110 may be implemented as computer processing instructions embodied in computer software, all or a portion of the functionality of remote storage server 110 may be implemented in dedicated hardware. For instance, groups of GPUs and/or FPGAs may be used to quickly process encrypted content in server processor 230.
[197] Referring now to Fig. 2B, there is shown a block diagram of an exemplary client device 150 (Fig. 1), consistent with disclosed embodiments. In one embodiment, client devices 150 may include one or more processors 252, one or more input/output (I/O) devices 254, one or more memories 260, and persistent storage 280 (e.g., a non-transitory storage medium such as flash memory, a hard disk drive, or the like). In some embodiments, client devices 150 may take the form of STBs, STUs, or any combination of these components. Accordingly, client devices 150 (or systems including client devices 150) may be configured as a particular apparatus, embedded system, dedicated circuit, and the like based on the storage, execution, and/or implementation of the software instructions that perform one or more operations consistent with disclosed embodiments. Additionally or alternatively, client devices 150 may take the form of smartphones, tablets, general purpose computers, or any combination of these components. According to some embodiments, client devices 150 may comprise web browsers or similar computing devices that access websites consistent with disclosed embodiments. [198] Processor 252 may include one or more known processing devices, such as mobile device microprocessors manufactured by ARM, Intel™, NVIDIA™, or various processors from other manufacturers. The disclosed embodiments are not limited to any specific type of processor configured in client devices 150.
[199] Memory 260 may include one or more storage devices configured to store instructions used by processor 252 to perform functions related to disclosed embodiments. For example, memory 260 may be configured with one or more software instructions, such as programs 262 that may perform operations when executed by processor 252. The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, memory 260 may include a single program 262 that performs the functions of the client devices 150, or program 262 may comprise multiple programs. Memory 260 may also store data 263 that is used for processing and/or displaying multimedia content. That is, memory 260 may include instructions to play multimedia in the client devices 150, upload encrypted content to remote storage server 110 (Fig. 1), and/or generate requests for content from remote storage

server 110 and/or content distributors 140 (Fig. 1). Additionally, or alternatively, the content may be extracted from persistent storage 280 to memory 260 for processing and/or displaying. [200] In certain embodiments, memory 260 may store instructions for displaying multimedia content in client devices 150. For example, memory 260 may include a content player 264. Moreover, in some embodiments, if content player 264 is not part of memory 260, client devices 150 may include programs 262 to download the applications required to view content and/or execute alternative media players to display the content. In addition, programs 262 may include client identification tools, such as secure cookies, to identify client devices 150 and/or users of client devices 150 and generate requests to remote storage server 110 and/or content distributors 140 including data structures for identifying the client and/or verifying permission to access the requested content. Further content player 264 may be configured to perform automated operations, such as transmitting a decline message when a user is not authorized or verified to view requested content or upload content from player 314.
[201] Although depicted as separate components, memory 260 and processor 252 may comprise integrated circuits for an STB, STU, or other content receivers. For example, memory 260 and processor 252 may comprise a DVR, a PVR, or any other electronic device configured to receive content (e.g., from content distributors 140, as shown in Fig. 1). [202] I/O devices 254 may include one or more devices configured to allow data to be received and/or transmitted by client devices 150 and to allow client devices 150 to communicate (e.g., via two-way network 170 of Fig. 1) with other machines and devices, such as other components of system 100. For example, I/O devices 254 may include a screen for displaying multimedia content or otherwise providing information to the user. I/O devices 254 may also include components for Internet communication or any other form of communication with components of system 100. I/O devices 254 may also include one or more digital and/or analog devices that allow a user to interact with client devices 150, such as a touch-sensitive area, buttons, or microphones. I/O devices 254 may also include other components known in the art for interacting with remote server 110 and content distributors 140.
[203] In addition to or as an alternative to I/O devices 254, client devices 150 may also include a wired connection 270 (and/or corresponding wireless connection) to a one-way network (e.g., one-way network 190 of Fig. 1). For example, connection 270 may comprise an aux connection to a cable service, a wired connection to a satellite in a DTH system, a wired connection to an

antenna in a DTT system, or any other connection for receiving content broadcast to client devices 150 (e.g., by content distributors 140 of Fig. 1).
[204] The components of client devices 150 may be implemented in hardware, software, or a combination of both hardware and software, as will be apparent to those skilled in the art. [205] Aspects of the present disclosure include offloading data to a data storage (e.g., remote server 110, as shown in Fig. 1). Herein, the term "offloading" includes either uploading data to server 110 by one of the client devices 150 (e.g., client device 153) or establishing that server 110 has a copy of data being possessed by client device 153. In various embodiments, offloading implies that client device 153 may discard a local copy of offloaded data, and be able to download the same data from server 110 at a later time provided that it maintains a correct proof that it possessed the data prior to offloading the data. For example, if client device 153 receives a portion (or the entirety) of a broadcast (e.g., a portion of a DTH, DTT broadcast, or the like), client device 153 may be configured to either upload that portion to server 110, or to verify that server 110 has the portion of the broadcast that may be downloaded by client device 153. Once client device 153 establishes that it has access to the portion of the broadcast from server 110, client device 153 may remove a local copy of that portion from local storage (e.g., a hard drive associated with receiving box 141, as shown in Fig. 1). In order to ensure that content rights of broadcasting programs are appropriately protected, client device 153 may only have access to the portion of the broadcast that was previously received and recorded by hardware associated with client device 153 (e.g., receiving box 141, a computer system of client device 153, or the like). [206] An offload process may be completed via a probe and subsequent proof generation. Additionally, an optional upload may also complete the offload process. In various embodiments, a data segment recorded by client device 153 may not be removed from a local storage associated with client device 153 until a proof for that data segment is computed and stored at the local storage. In some cases, a copy of the challenge and/or a copy of the proof for the data segment may be also stored at a database associated with server 110. The copy of the challenge and/or the copy of the proof may then be used by server 110 to verify that client device 153 has (or previously recorded) the data segment. During the probe process, data segments of client device 153 (herein referred to as client's segments) may be validated by comparing at least some information about the client's segments (e.g., last few bits of the client's segments, metadata associated with client's segments, and the like) with relevant information about these

segments stored in a suitable database (e.g., database 180). In such a case, when database 180 does not contain an equivalent copy of the client's segments, the probe process may compare information related to the client's segments with corresponding information for data segments received from other client devices to establish an authenticity of these segments, as further described herein. When the authenticity is established, the client's segments may need to be uploaded to database 180. In some cases, such upload may not be required, as data segments from other client devices may have been uploaded instead (or are currently being uploaded). During the offload the client's segments may be assigned segment identifications (IDs), and such IDs may be keys used for database 180. In some cases, the keys may be provided to client device 153, and such keys may be referenced by client device 153 during a download process. For example, client device 153 may identify data segments from database 180 using segment IDs for downloading the data segments.
[207] In some embodiments, data obtained by client devices 150 may include errors in transmission or recording interruption, and server 110 may be configured to allow the client device that received the data with transmission errors (e.g., client device 153) to download a version of data that is the same as the version recorded by hardware associated with client device 153 (i.e., data that includes errors and interruptions).
[208] In various embodiments, aspects of the present disclosure include systems, methods, and computer readable media for offloading data to a server (e.g., remote server 110, as shown in Fig. 1) from client devices (e.g., client devices 150, as shown in Fig. 1). The client devices 150 can request offloading data to server 110. The data can include data packets (e.g., MPEG-2 packets, or various other types of media or multimedia packets) and can be corresponding to, for example, a broadcast program. When server 110 receives an offloading request from one of the client devices 150 (e.g., client device 153 in Fig. 1), server 110 may verify whether the data for offloading has already been stored in a database of server 110, or is substantially identical to the data being offloaded by another client device 150 (e.g., client device 154 in Fig. 1). The server 110 itself, rather than the client devices 150, may perform the verification. Embodiments of the present disclosure permit recognition of common content from different client devices 150 without revealing the decrypted contents. Additional details regarding the data offloading are described in United States Patent Application No. 16/660,761, filed on October 22, 2019, which is incorporated herein by reference in its entirety.

[209] The data for offloading may be segmented into multiple segments. Each segment may comprise a sequence of packets. There may be, in some situations, reasons to identify a particular segment uniformly across all client devices 150. At least some packets of a segment may carry identifiers. Each identifier may uniquely identify a packet. In one example, the identifier can be a time base known as the system clock reference (STC). STC can be sampled and conveyed in Program Clock Reference (PCR) data or Presentation Timestamp (PTS) data. IS013818-1 ITU-T H.222.0, for example, defines how transport streams are constructed with a Program Clock Reference (PCR). The STC may have discontinuities (e.g., jumps in value) caused by a clock reset. Furthermore, the PCR values may be a fixed number of bits and hence wraps every time this bitfield is overflowed. The value of the STC carried in the first PCR packet of any segment can be used. In an example embodiment, a data segment may be long enough to carry at least one PCR packet. However, this may not be long enough to uniquely identify this segment over an extended period of time, due to the possibility of discontinuities and STC wrapping around. Therefore, the STC value can be used along with other parameters to be described below to uniquely identify a segment over the long term.
[210] Further, as previously described, client device 153 may not be required to upload data for a given broadcast program in order to be able to download a corresponding copy of the data. For example, client device 153 may only need to be able to provide a proof to server 110 that device 153 was at some point in possession of the data for the broadcast program for server 110 to authorize the download of the data. For a given broadcast program, multiple data segments may be required to be uploaded or offloaded. Data received by client device 153 may be transmitted to server 110 and protected with multiple encryption keys using a suitable form of commutative encryption, as described above.
[211] Aspects of the present disclosure describe a system and a process for offloading a data segment. In an example embodiment, a client device (e.g., client device 153) may submit a request to offload data, such as video or audio data, to the server 110. For example, client device 153 may submit a request to offload data segments of a program broadcast to server 110. Client device 153 may first record video and/or audio data of the broadcast and then submit it to server 110. Upon completion of offloading data, client device 15 3 may remove at least some portion of data from a local storage system (e.g., receiving box 141). As described above, a data segment

recorded by client device 153 may not be removed from a local storage associated with client device 153 until a proof for that data segment is computed and stored at the local storage. [212] The request from client device 153 may include authenticating the client device with server 110. For instance, client device 153 may authenticate via a secure network channel by providing to server 110 credentials of device 153, such as an identification and apassword of device 153. In an example embodiment, receiving box 141 may be configured to communicate with server 110 and may include receiving box 141's identification and apassword for authenticating receiving box 141 with server 110. In some cases, an additional authentication server may be used for authenticating client device 153, as further discussed below. [213] As previously discussed, an authentication server may be used for authenticating client device 153. An example authentication process 301, in which the authentication is facilitated by an authentication server 114, is shown in Fig. 3. At step 311, client device 153 may communicate its credentials (e.g., device identification and password) to server 114. In some cases, device 153 may be configured to communicate with server 114 via a receiver box 141. In an example embodiment, at step 311, client device 153 may establish secure network communication with server 114 using, for example, apassword. Upon authenticating device 153, server 114 may be configured to communicate with server 110 to provide server 110 information for communicating with device 153.
[214] Client device 153 may engage in various activities (herein, also referred to as actions) when communicating with server 110. For example, client device 153 may offload data to server 110 by either uploading content to server 110, or verifying that content is already uploaded to server 110. Alternatively, client device 153 may download content from server 110, provided that client device 153 can prove that the content was previously broadcast to client device 153. [215] For offloading data to server 110, client device 153 may submit an offloading (probe) request 413 to server 110, as shown in Fig. 4A. The offloading request 413 may be related, for example, to a broadcast program 411 that client device 153 received from content distributer 140 prior to submitting the offloading request. In an example embodiment, offloading request 413 includes offloading data segments without a priori knowledge of a broadcast program represented by the data segments. However, in some embodiments, offloading request 413 may include information about broadcast data that is being offloaded, such as a title of broadcast program 411, a time at which program 411 was transmitted to client device 153, a channel

identification for broadcasting program 411, an identification number of program 411, or any other suitable information for identifying broadcast program 411.
[216] Upon receiving request 413 for offloading the data from client device 153, server 110 may determine whether a copy of program 411 (or at least a portion of program 411) is already stored at a database (e.g., database 415, as shown in Fig. 4A) associated with server 110. For example, database 415 may have stored program 411 in response to requests of other client devices (e.g., devices 151 and 154) to store program 411. For instance, devices 151 and 154 may have previously received broadcast program 411 from distributer 140 and may have requested to store program 411 on server 110 prior to request 413 (as indicated by requests 414 and 416 and associated program 411). If program 411 is already stored in database 415, server 110 may proceed in verifying that data segments corresponding to program 411 being in possession of client device 153 match data segments of the copy of the program 411 that is stored in database 415.
[217] In an example embodiment, server 110 may verify the data segments of program 411 by providing a download challenge (herein also referred to as a challenge) for client device 153. Herein, the challenge may be any suitable request to client device 153, for which a response from client device 153 indicates, with an acceptable degree of certainty, that client device 153 was in possession of the data segments corresponding to program 411 at the time of offload. For example, a challenge may include a request from server 110 to client device 153 to provide a few last bits or bytes of at least some (or each) data segment(s) corresponding to program 411. In an example embodiment, server 110 may request the last byte from data segments, a few last bytes from the data segments, or the like. In some cases, the challenge may include a request for a first few bytes and the last few bytes of a given data segment. Alternatively, or additionally, server 110 may generate an array of bit positions and request bits from such positions of the data segment. For instance, an array of bit positions may be used to request a first, a nineteenth, and a twenty-third bit from the data segment. In some cases, the numbers for the positions may be generated using a suitable random number generator with an appropriate seed. For instance, a hash function of the data segment may be used to obtain the seed for the random number generator. As used herein, a hash function (also, herein referred to as a hash) may be any function that can be used to map any binary data (e.g., data corresponding to a data segment of

program 411) of arbitrary size to a fixed-size value or set of values. The values returned by a hash function are referred to as hash values, hash codes, or hash digests.
[218] In an example embodiment, the challenge may be any suitable function or algorithm that, upon acting on data segments , provides a set of proofs , where is a proof for a given data segment. For brevity, the set of proofs is also referred to as a proof, when there is no possibility of confusing it with proofs In an example embodiment, data segments may be encrypted with a client encryption key (e.g., content key 232, as shown in Fig. 2A) and a common encryption key, as previously discussed. Here, identifies the th encrypted data segment. Thus, and proof may be computed using challenge and data segments by both server 110 and client device 153. In various embodiments, client device 153 may compute proof and satisfy the challenge from server 110 by providing to server 110. Proof may include, for example, bits of data requested by the challenge . For example, if server 110 requested bits at positions {1, 19, 23} of a given data segment, client device 153 may provide such bits to server 110 as proof. [219] In some cases, challenge may be any suitable mapping of a data segment to a set of hash values via a hash function. After performing the mapping, client device 153 may provide a response to server 110 by reporting the resulting set of hash values to server 110. [220] As discussed above, in an example embodiment, proof may be computed using data segments that are encrypted with content key 232 and a common key. Proof may be communicated to server 110, and server 110 may verify the correctness of proof, provided that server 110 has access to data segment DS and to content key 232 that allows for encryption of data segment DS. In an example embodiment, content key 232 may be transmitted to server 110 via a secure communication channel to ensure that it is not intercepted. Additionally, or alternatively, content key 232 may be securely transmitted from client device 153 to server 110 by device 153 encrypting key 232 using a public key of server 110. As described above, the communication from device 153 to server 110 may be digitally signed to ensure the authentication of device 153.
[221] Alternatively, instead of transmitting content key 232, client device 153 may be configured to authorize a license server to provide content key 232 to server 110 upon authentication of server 110 with the license server.
[222] In some cases, proof may be obtained using data segments encrypted using content key 232 and the common key. In an example embodiment, upon receiving a challenge from server

110 for data segments of program 411 encrypted for client device 153 (e.g., data segments may be encrypted using content key 232 and the common key), client device 153 may determine proof based on locally available data segments and subsequently, store the proof and challenge in a local storage associated with client device 153. Additionally, in some embodiments, client device 153 may transmit the proof to server 110 to be stored at server 110. In an example embodiment, the proof may be stored in a profile of a client maintained by server 110. During download requests, server 110 may use the stored copy of proof to compare with a proof provided by client device 153 to ensure that client device 153 was in a possession of data segments . In some cases, however, server 110 may not rely on a stored copy of proof, but instead may compute proof using stored data segments (which are only encrypted using a common key) and using content key 232. For example, server 110 may encrypt the stored data segments with content key 232 and use such encrypted data segments to calculate proof [223] In various embodiments, data corresponding to program 411 may be split into data segments by a software application of client device 153 (e.g., by a software application of receiving box 141). The software application may be configured to split data corresponding to program 411 into a set of data segments, such that each one of the data segments includes substantially the same data bits as a corresponding data segment of program 411 obtained by any other client device and server 110. Further details of how data corresponding to program 411 is split into data segments are described herein. The term "substantially the same" implies that most of data bits of a given data segment obtained by a software application of client device 153 are the same as the data bits of the same data segment obtained by a software application of any other client device or by a corresponding software application of server 110, with some difference allowed in order to account for errors associated with a transmission of data segments. For example, a few data bits of one data segment may be absent in the data segment or may be corrupted due to transmission errors. In various cases, a measure of how well one data segment matches another data segment may be determined via a suitable metric discussed herein. As described herein, during an offload process for a data segment by client device 153, probe parameters are used to derive a segment ID. During the offload process, client device 153 may not provide server 110 the data segment. The probe response by server 110 may contain a canonicalized segment ID, a challenge for the data segment, and instructions regarding whether upload for the data segment is required. The canonicalized segment ID (or canonical segment

ID) is any suitable identification that is assigned as a segment identification for a pair of data segments, when it is determined that probe parameters for these data segments match. In some cases, when it is determined that probe parameters for several data segments match, the canonicalized segment ID may be assigned as the segment identification for all the matching data segments.
[224] Segment ID may include a length enumeration defined as a many-to-one mapping of the number of packets of the data segment and an integer. The length enumeration may allow to detect a data loss in the data segment.
[225] In various embodiments, at an upload time (e.g., at a time when a data segment is being uploaded to a database associated with server 110), server 110 may use a poison detection technique to require multiple client devices to upload the same data segment corresponding to the same segment ID and perform a bit-for-bit comparison of the segment data protected with the common key (e.g., data segments received from various client devices may be partially decrypted using corresponding content keys 232 of the different client devices prior to bit-for-bit comparison of the data segments).
[226] Fig. 4B shows an example process 401 for performing operations with broadcast program data by client device 153 and hardware related to device 153 (e.g., receiver box 141, as shown in Fig. 1). At a first point in time, at step 421, client device 153 may receive a broadcast program (e.g., program 411, as shown in Fig. 4A) from broadcast content provider 140 and store program 411 at local storage associated with client device 153 (e.g., a hard drive of a receiver box 141, and the like). At a later second point in time, at step 423, client device 153 may authenticate with a data server (e.g., server 110, an authentication server, and the like), and offload program 411 to server 110. During an offloading process, program 411 is partitioned into data segments, and for the data segments, as a part of step 423, client device 153 may determine proof (note, proof and set of proofs is used interchangeably as described above) in response to challenge provided by server 110. Proof may be based on the challenge and data segments of program 411 (e.g., as discussed above). In various embodiments, proof may be stored at a local storage associated with client device 153 before the data segments are removed from the local storage. [227] Additionally, or alternatively, and as further discussed below, client device 153 may receive an authorization from server 110 to download a copy of a data segment related to program 411 from server 110 at a later time. The authorization may be given after client device

153 uploads the data segment related to program 411 to server 110. Alternatively, the authorization may be given to device 153 when a segment ID for the data segment matches a segment ID of a corresponding data segment stored at a database associated with server 110. Client device 153 may store the authorization locally (in addition to storing proof P, or instead of storing proof P), and may present the authorization at a later time during a download request to server 110. The authorization may be digitally signed by server 110 and may be encrypted using content key 232 and a common key.
[228] At a later third point in time, at step 425, client device 153 may remove a local copy of program data 411 to free the local storage from data after computing and storing proofs related to data segments of program data 411. Further, at a later fourth point in time, at step 427, client device 153 may request to download program data 411 from server 110, and upon verification that client device 153 is authorized to download program data 411 (e.g., via proof or the authorization), client device 153 may receive program data 411 from server 110 at step 429. [229] Fig. 4C shows a process 402 for providing a challenge to client device 153, for which a proof may be computed by device 153. At step 430, client device 153 may request to offload data segments 441 corresponding to data of a broadcast program (e.g., program 411), and may provide data segments 441 to server 110. Server 110 may determine whether segments 441 are already stored in database 415, and if segments 441 are not stored in database 415, server 110 may be configured to verify that segments 441 correspond to program 411, and upload segments 441 to database 415. A process of verifying that segments 441 correspond to program 411 may include comparing the segment ID (e.g., probe parameters for the segment) with the segment IDs provided by other client devices 150.
[230] Fig. 4C shows segments 442 stored in database 415. Segments 442 may be a substantially identical copy of segments 441. In an example embodiment, segments 442 may be identified in database 415 by a data segment identification (ID) 443. At step 434, server 110 may be configured to form a challenge 447. In an example embodiment, challenge 447 may be combined together with data segment ID 443 to form a challenge record 448. In an example embodiment, both challenge 447 and a related proof, computed for that challenge, may be stored at a local storage associated with client device 153. Additionally, or alternatively, in some cases, server 110 may maintain a client profile 444 corresponding to device 153, and record 448 may be

stored in profile 444. In an example embodiment, client profile 444 may be stored in database 415.
[231] At step 436, server 110 may transmit challenge record 448 containing challenge 447 and a corresponding ID 443 to client device 153. In an example embodiment, challenge record 448 may be digitally signed by server 110. At step 438, client device 153 may obtain and locally store a proof 449 (e.g., proof P, as discussed before) corresponding to challenge 447. Additionally, client device 153 may store challenge record 448. During subsequent download requests, client device 153 may provide proof 449 and data segment ID 447 as a proof that client device 153 is authorized to download segments 442. In some cases, both challenge 447 and proof 449 are provided by client device 153 during the download request. Additionally, or alternatively, in some cases, challenge 447 may be stored in user profile record 444 at server 110. Having challenge 447 stored in user profile record 444 with a corresponding ID 443 may be sufficient to establish that client device 153 is authorized to access segments 442 from database 415, provided that client device 153 is in possession of proof 449. After obtaining and storing proof 449, client device 153 may remove the local copy of data segments 441 at step 439. [232] In some cases, challenge 447 must be satisfied in any future data downloads for any one of data segments 441 that is to be offloaded. Client device 153 may use challenge 447 to generate a per-segment proof (e.g., proof 449 may include one or more per-segment proofs). Data for proof 449 may be encrypted with content key 232 and a common key. Having proof 449 encrypted with key 232 and the common key allows tying proof 449 to the content of segments 441, content key 232, and the common key.
[233] During a download request, challenge 447 and proof 449 may be sent to server 110 for downloading segments 442. Server 110 may be configured to generate a copy of proof 449 from a copy of segments 442 stored in database 415 and validate that the generated copy of proof 449 identically matches proof 449 received from client device 153. When a match is determined by server 110, server 110 maybe configured to provide client device 153 with data segments 442. In an example embodiment, when content key 232 is protected by a suitable digital rights management DRM approach a bad actor (i.e., a person or a computing system determined to undermine communications of client device 153 and server 110) may not be able to: download a data segment from server 110 that the bad actor did not originally record, download a segment without presenting a proof, download a segment using a content key other than content key 232,

re-use a proof from someone else's recording of the same segment, or re-use a proof from a different recorded segment that may be available to the bad actor.
[234] Fig. 4D shows process 403, which may be a variation of process 401. For example, steps 430 and 432 of process 403 may be the same as the same-numbered steps of process 401. At step 435, server 110 may generate an authorization 446 (instead of challenge 447). Authorization 446 may be part of an authorization record 445 that may combine authorization 446 and data segment ID 443. In some embodiments, authorization 446 may be computed based on information about segments 442, and additionally, in some cases, based on information about client device 153 (e.g., an identification for client device 153). For example, authorization 446 may be a hash value obtained by applying a hash function to data of segments 442 and data corresponding to the identification of device 153.
[235] At step 437, server 110 may transmit authorization record 445 containing authorization 446 and a corresponding ID 443 to client device 153. In an example embodiment, record 445 may be digitally signed by server 110. During subsequent download requests, client device 153 may provide record 445 digitally signed by both server 110 and client device 153 to server 110 as a proof that client device 153 is authorized to download segments 442. [236] Fig. 5A shows an example challenge-proof process 501 performed by server 110 for offloading one or more data segments from a client device (e.g., device 153). At step 511, server 110 may receive a request from client device 153 for offloading one or more data segments. As described above, a request (e.g., request 413, as shown in Fig. 4A) may include probe parameters for the data segments as well as metadata associated with the data segment (e.g., a name of a broadcast channel associated with the data segment, and the like). In an example embodiment, a data segment may include a few seconds of video data of broadcast program 411. In some cases, the data segment may be less than a second or may be as large as tens of seconds of video data (or audio data or any other data), or one or more minutes of the video data (or audio data or any other data). In some cases, the data segment length is selected to have an acceptable number of errors per data segment associated with errors due to transmission from broadcast content provider 140. Thus, the length of the data segment may be determined by the quality of the transmission of data from provider 140. In various embodiments, the quality of transmission may be calculated as an average quality of transmission for various devices configured to receive broadcast content from provider 140. As described above, the data segments may be determined

by a software application of various client devices and are configured to be the same between all the client devices that receive the same segment of program 411.
[237] As described above, a request (e.g., request 413, as shown in Fig. 4A) may include metadata associated with the data segment (e.g., a name of a channel (or in some cases a broadcast program) associated with the data segment, segment IDs, and the like). Further, request 413 may include data segments of a broadcast program which may be used to further identify and verify data ofthe broadcast program for which data needs to be offloaded. Fig. 6 shows data segments A-U for an example broadcast program 611, and data segments C-S corresponding to a portion 613 of broadcast program 611. As shown in Fig. 6, a portion ofthe broadcast program 613 may include a part of segment B, and a part of segment T. In an example embodiment, if client device 153 received portion 613, client device 153 may request to offload segments C-S. The request for offloading segments C-S may include providing of segments C-S to server 111 for data verification.
[23 8] Returning to Fig. 5A, at step 513 server 110 may provide an offload response to client device 153. In an example embodiment, an upload of data segments may be necessary because server 110 may not contain a copy ofthe data segments in database 180. For example, server 110 may provide to client device 153 a canonicalized list of segment IDs as well as one or more challenges (e.g., challenge 447, as shown in Fig. 4C) and instructions for uploading data segments. The instructions may cause client device 153 to compute proofs for all data segments that can be offloaded using corresponding challenges for these data segments. In various embodiments, separate challenges may be provided for each data segment C-S of portion 613 that is needed to be offloaded to database 180.
[239] At step 515, server 110 may determine if the upload of data segments (e.g., segments C-S, as shown in Fig. 6) is needed. For example, the upload may be needed if copies of corresponding segments C-S are not stored in a database (e.g., database 415, as shown in Fig. 4A) associated with server 110. For example, if segments C-Eare stored in database 415, and segments F-S are not stored in database 415, segments F-S may be required to be uploaded. [240] Whether client device 153 is required to upload data segments (e.g., segments C-S) may be determined by server 110 via a probe service. The probe service may be any suitable approach executed by one or more software applications of server 110 for detennining whether the upload of segments C-S is needed. In an example embodiment, server 110 may compare probe

parameters for segments C-S received from client device 153 with probe parameters obtained from a local copy of probe parameters for segments related to program 611 to determine if segments C-S need to be uploaded. It should be noted that program 611 may be interpreted as a period of a service for a particular channel, and may not coincide with a particular broadcast program. In an example embodiment, determining whether the upload of segments C-S is needed may include comparing segment IDs received from client device 153 with stored segment IDs corresponding to a local copy of probe parameters related to segments C-S. If the received segment IDs do not match the stored segment IDs, the upload may be needed (step 515, Yes). Alternatively, if the received segment IDs are the same as the stored segment IDs, the upload may not be needed (step 515, No).
[241] As previously described, the upload of data segments (e.g., segments C and S) may not be required, for example, when a local copy of segments C and S corresponding to server copies of these segments is stored in database 415. Server 110 may determine that the upload is not required when information available in a request (e.g., request 413) indicates that server copies of segments C and S are already stored in database 415. For instance, when request 413 includes probe parameters for data from segments C and S, server 110 may compare the received probe parameters with the probe parameters obtained using a local copy of probe parameters for segments C andS, and verify that segments of client device 153 match the segments of the local copy. If upload is not needed (step 515, No), process 501 may proceed to step 523 and provide an indication to client device 153 that data segments may be deleted after proofs (e.g., proof as described above) are computed for these data segments.
[242] For segments that require upload (step 515, Yes), server 110 may proceed to step 531, and request data segments C-S from client device 153 for the upload. After receiving probe parameters for data segments C-S for the upload (step 511), at step 533, server 110 may store data associated with segments C-S in a temporary data storage location and evaluate at step 535 whether data of segments C-S accurately corresponds to portion 613 of broadcast program 611. Such step 535 is also referred to as a poison detection. For example, data of segments C-S may not accurately correspond to portion 613 if the data contains missing data, incorrect data, or extraneous data, as described herein. If the data of segments C-S corresponds to portion 613 (step 535, Yes), server 110 may upload and store data segments C-S at step 537. For example, server 110 may store data segments C-S by moving data associated with data segments C-S from

the temporary data storage location to database 415, thus, completing a process of uploading segments C-S. Alternatively, if the data of segments C-S does not correspond to portion 613 (step 535, No), server 110 may notify client device 153 that verification test has failed at step 539 and complete process 501.
[243] In an example embodiment, poison detection step may be carried out for each data segment C-S. An example data segment (e.g., data segment C) may be compared with a corresponding data segment (herein, for brevity referred to as a server data segment) stored in a database associated with server 110 by computing a hash digest (e.g., using MD5 hash digest) for data segment C and the server data segment. If the hash digest for data segment C matches the corresponding hash digest for the server data segment, then server 110 may determine that data segment C matches the server data segment. Otherwise, server 110 may determine that these segments are different. In an example embodiment, the process of reconciling content between temporary storage and "real" storage may be performed in the background without client's knowledge.
[244] After uploading data segments C-S at step 537, server 110 may proceed to step 523. At step 523, server 110 may provide an indication to client device 153 that data segments may be deleted (however, the proofs are retained at client device 153) from local storage associated with client device 153 (e.g., such storage may be a hard drive available for receiver box 141, a hard drive of client device 153, a flash memory card of client device 153, or any other suitable data storage element associated with client device 153). In some cases, the indication may be any suitable visual indication (e.g., a message on a screen associated with client device 153, a graphical user element indicating that local data may be removed, and the like). Such an indication may be used by a client device (e.g., via an instruction from a user of the client device) to determine whether to remove portion 613 from local storage. Process 501 may be completed after the completion of step 523. In various embodiments, data segments may be deleted after proof for these segments is computed and stored at the local storage associated with device 153. In various embodiments, the removal of data segments may happen automatically without explicitly providing an indication to a client device.
[245] Fig. 5B shows a process 502 that may be a variation of process 501. For example, with the exception of step 512, steps of process 502 may be the same as the same-numbered steps of

process 501. Instead of step 512 of process 501, process 502 may include step 513 for providing authorization to client device 153, as described in connection with Fig. 4D. [246] Fig. 7 shows a process 701 having steps 711-739 executed by client device 153 in response to correspondingly numbered steps 511-539 of process 503. Steps 711 and 713-739 may be mirror steps for the correspondingly numbered steps 511-539 of process 503. For example, for step 511 of receiving a request to offload data segments by server 110, a correspondingly numbered mirror step 711 may include submitting the request to offload data segments by client device 153. At step 713, client device 153 may receive a response from server 110, which may include challenges for data segments as well as a possible request to upload data segments (e.g., segments C-S, as shown in Fig. 6). If the upload is needed (step 715, Yes), process 701 may proceed to steps 731 and 733 and provide data segments C-S to server 110 for storing in database 415. If client device 153 receives information that data segments C-S are verified to match portion 613 of broadcast program 611 (step 735, Yes), client device 153 may upload data segments C-S at step 737. Alternatively, if data segments C-S are not verified to match portion 613 of broadcast program 611 (step 735, No), client device 151 may be configured to receive a notification that verification test has failed at step 739.
[247] If the upload is not needed (step 715, No), client device 153 may receive an indication that data segments C-S may be deleted, and proof P needs to be locally stored at step 723, after which process 701 may be completed.
[248] In addition to offloading content, client device 153 may request to download content from a database associated with server 110 (e.g., database 415, as shown in Fig 4A). As described above, client device 153 may only be authorized to download content that was previously offloaded by client device 153. For example, if client device 153 has previously offloaded content portion 613, client device 153 maybe authorized to download data content 613.
[249] Fig. 8 A shows an example process 801 for authorizing client device 153 to download data segments (e.g., data segments 442, as shown in Fig. 4B). Process 801 uses a challenge-proof approach for authorization of client device 153 described, for example, in relation to Fig. 4B. Server 110 may authorize access to the service and to the specific data segment, and this access may vary from one data segment to another.

[250] In an example embodiment, steps of process 801 may be performed by server 110. At step 811, server 110 may receive a request to download data segments (e.g., segments C-S) of data 613. Each segment C, D, E ... S, may be transacted individually (e.g., each segment C-S may be downloaded individually). In an example embodiment, a request to download data segments may include a routing request to start the permission chain and determining which download server to use. Such a request may be made over a secure link. In some embodiments, a request for downloading data segments C-S may include data segments ID (e.g., 443, as shown in Fig. 4B) such that, when presented to server 110, they may allow server 110 to retrieve all the data segments that client device 153 is authorized to download for data 613. hi some cases, when a request to download data segments is done over a non-secure connection, the request for downloading data segments C-S may be digitally signed by client device 153 (e.g., data segments ID may be digitally signed by client device 153) to ensure that the request has not been altered by a person-in-a-middle attack. In some cases, a request to download content from database 415 may include a proof, as discussed above.
[251] In various embodiments, as discussed above, prior to submitting a download request, client device 153 may authenticate with server 110 via a secure network connection. Additionally or alternatively, as previously discussed, if client device 153 and server 110 have previously exchanged client and server public encryption keys corresponding to their private encryption keys, they can authenticate via an SSL handshake, as described above. Additionally, the communications between the license server and server 110 may be digitally signed to ensure that data is not altered by a "person-in-a-middle" attack.
[252] To establish the validity of proof 449, server 110 may obtain client encryption key (e.g., content key 232, as shown in Fig. 2A) at step 833. In an example embodiment, content key 232 may be provided to server 110 in a secure way (e. g., via license or DRM token). Server 110 may use content key 232 to encrypt data segments C-S to obtain encrypted data segments , at step 835. At step 839, having challenge (e.g., challenge 447, as shown in Fig. 4B, stored at a local storage associated with client device 153), server 110 may compute a local copy of proof as , as discussed before. Further, server 110 may compare the computed proof with proof received from client device 153 as a part of the request submitted by client device 153, and received at step 811. If matches (step 839, Yes), process 801 may proceed to step 821 and transmit data segments (e.g., segments 442) to client device 153. Alternatively, if does not match (step 839,

WHAT IS CLAIMED IS:
1. A method for offloading a data segment the method comprising:
receiving a request from a user device to offload the data segment, the request including a probe request, and the probe request including a segment identification;
sending a probe response to the user device, the probe response comprising an approval or decline of an action to be executed by the user device, the action being one of an upload, or a request to retry offloading the data segment at a later time; and
sending a challenge to the user device.
2. The method of claim 1, wherein the challenge comprises a request for one or more bits of
data of the data segment
3. The method of claim 1, wherein the probe request includes a segment identification formed using a recording time for the data segment, a reference time value for the data segment, and a length enumeration for the data segment.
4. The method of claim 1, further comprising requesting the user device to store the challenge and a user device proof, wherein the challenge and the user device proof is specific to the data segment.
5. The method of claim 1, wherein the upload is declined if data corresponding to the data segment is known to be recoverable from a server.
6. The method of claim 1, further comprising determining whether the segment identification matches one of segment identifications associated with one of local copies of data segments recoverable from a server.

7. The method of claim 6, farther comprising deteimking that the action is an approval of the upload when the segment identification does not match any of segment identifications associated with one of local copies of data segments recoverable from a server.
8. The method of claim 6, further comprising determining that the action is a decline of the upload when the segment identification matches at least one of segment identifications associated with one of local copies of data segments recoverable from a server.
9. The method of claim 1, wherein the challenge is unique for the user device.

10. The method of claim 1, wherein the challenge is generated for the user device based on an identification of the user device.
11. The method of claim 1, further comprising authenticating the user device before receiving the request from the user device.
12. The method of claim 1, further comprising receiving the data segment and the segment identification information when the probe response to the user device indicates that the upload is approved.
13. The method of claim 12, further comprising receiving uploaded data, the uploaded data comprising information used to obtain a user device content key, wherein the content key is configured to partially decrypt the data segment.
14. The method of claim 13, further comprising notifying the user device that the uploaded data is received, after receiving the uploaded data.

15. The method of claim 13, wherein the data segment is encrypted commutatively with at least the content key and a common key.
16. The method of claim 13, wherein the uploaded data comprises a local server copy of the data segment, the local server copy of the data segment is stored at a storage device associated with the local server, the local server copy of the data segment heing encrypted only by the common key.
17. A method for providing a data segment for downloading to a user device, the method comprising:
receiving a request from the user device to download the data segment, the request comprising a data segment identification and a user device proof;
obtaining a content key;
encrypting a local server copy of the data segment with the content key;
generating a server proof based on the encrypted local server copy of the data segment and a challenge;
comparing the user device proof with the server proof;
when the user device proof matches the server proof, providing the user device with the local server copy of the data segment; and
when die user device proof does not match the server proof, either requesting the user device to retry downloading the data segment at a later time, or notifying the user device that the data segment cannot be downloaded.
18. The method of claim 17, further comprising authenticating the user device before receiving the request from the user device.
19. The method of claim 17, wherein the server proof is generated using the received challenge.

20. The method of claim 17, wherein the challenge comprises a request for one or more bits of the data segment extracted starting at a particular bit position in the data segment.
21. The method of claim 17, wherein the challenge is configured to be unique for each user device.
22. The method of claim 17 wherein the challenge is received as a part of the request.
23. The method of claim 17, wherein detennining whether the user device proof matches the server proof comprises comparing the one or more bits of data of the data segment with the one or more bits of the local server copy of the data segment.
24. The method of claim 17, wherein determining whether the user device proof matches the server proof comprises comparing a result of a hash digest of the one or more bits of data of the data segment obtained by the user device with a result of the hash digest of the one or more bits of the local server copy of the data segment obtained by a server.
25. A method for providing a data segment for downloading to a user device, the method
comprising:
receiving a request fiom the user device to download the data segment, the request comprising a data segment identification and a user device proof;
obtaining a content key;
generating a server proof based on a local server copy of the data segment and a challenge;
encrypting the server proof using the content key;
comparing the user device proof with the encrypted server proof;
when the user device proof matches the encrypted server proof, providing the user device with the local server copy of the data segment; and

when the user device proof does notmatch the encrypted server proof, either requesting the user device to retry downloading the data segment at a later time, or notifying the user device that the data segment cannot be downloaded.