IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`Kevin J. Ma et al.
`In re Patent of:
`9,313,178 Attorney Docket No.: 50095-0082IP1
`U.S. Patent No.:
`April 12, 2016
`
`Issue Date:
`Appl. Serial No.: 14/266,368
`
`Filing Date:
`April 30, 2014
`
`Title:
`METHOD AND SYSTEM FOR SECURE OVER-THE-TOP LIVE
`VIDEO DELIVERY
`
`
`Mail Stop Patent Board
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`PETITION FOR INTER PARTES REVIEW OF UNITED STATES PATENT
`NO. 9,313,178 PURSUANT TO 35 U.S.C. §§ 311–319, 37 C.F.R. § 42
`
`
`
`Google Exhibit 1026
`Google v. Ericsson
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`TABLE OF CONTENTS
`
`I.(cid:3)
`
`II.(cid:3)
`
`REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104 ............................ 1(cid:3)
`A.(cid:3) Standing .................................................................................................... 1(cid:3)
`B.(cid:3) Challenge and Relief Requested ............................................................... 1(cid:3)
`SUMMARY OF THE ’178 PATENT ............................................................. 3(cid:3)
`A.(cid:3) Brief Description ....................................................................................... 3(cid:3)
`B.(cid:3) Summary of the Prosecution History ........................................................ 4(cid:3)
`C.(cid:3) Level of Ordinary Skill in the Art ............................................................. 5(cid:3)
`III.(cid:3) CLAIM CONSTRUCTION UNDER 37 C.F.R. §§ 42.104(b)(3) .................. 5(cid:3)
`IV.(cid:3) THE CHALLENGED CLAIMS ARE UNPATENTABLE ............................ 6(cid:3)
`A.(cid:3) [Ground 1A]: Peterka in view of Bocharov .............................................. 6(cid:3)
`1.(cid:3)
`Peterka ............................................................................................. 6(cid:3)
`2.(cid:3)
`Bocharov ....................................................................................... 10(cid:3)
`3.(cid:3) Obviousness Based on Peterka-Bocharov Combination ............... 12(cid:3)
`B.(cid:3) [Ground 1B]: Peterka in view of Bocharov, Peterka308, and Chen ...... 45(cid:3)
`1.(cid:3)
`Peterka308 ..................................................................................... 45(cid:3)
`2.(cid:3)
`Chen ............................................................................................... 46(cid:3)
`3.(cid:3) Obviousness Based on Peterka-Bocharov-Peterka308-Chen
`Combination .................................................................................. 46(cid:3)
`C.(cid:3) [Ground 1C]: Peterka in view of Bocharov and Balraj .......................... 58(cid:3)
`1.(cid:3)
`Balraj ............................................................................................. 58(cid:3)
`2.(cid:3) Obviousness Based on Peterka-Bocharov-Balraj Combination ... 59(cid:3)
`D.(cid:3) [Ground 1D]: Peterka in view of Bocharov and Kelly ........................... 61(cid:3)
`1.(cid:3) Kelly .............................................................................................. 61(cid:3)
`2.(cid:3) Obviousness Based on Peterka-Bocharov-Kelly Combination .... 61(cid:3)
`E.(cid:3) [Ground 1E]: Peterka in view of Bocharov, Kelly, and Eisen ............... 64(cid:3)
`1.(cid:3)
`Eisen .............................................................................................. 64(cid:3)
`2.(cid:3) Obviousness Based on Peterka-Bocharov-Kelly-Eisen
`Combination .................................................................................. 64(cid:3)
`V.(cid:3) MANDATORY NOTICES UNDER 37 C.F.R. §42.8 .................................. 66(cid:3)
`A.(cid:3) Real Parties-In-Interest Under 37 C.F.R. §42.8(b)(1) ............................ 66(cid:3)
`B.(cid:3) Related Matters Under 37 C.F.R. §42.8(b)(2) ........................................ 66(cid:3)
`C.(cid:3) Lead And Back-Up Counsel Under 37 C.F.R. §42.8(b)(3) .................... 66(cid:3)
`D.(cid:3) Service Information ................................................................................ 67(cid:3)
`VI.(cid:3) PAYMENT OF FEES – 37 C.F.R. §42.103 .................................................. 67(cid:3)
`VII.(cid:3) CONCLUSION .............................................................................................. 67(cid:3)
`
`i
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`
`
`
`EXHIBITS
`
`APPLE-1001
`
`U.S. Patent 9,313,178 to Ma et al. (“the ’178 patent”)
`
`APPLE-1002
`
`Prosecution History of the ’178 Patent (Serial No. 14/266,368)
`
`APPLE-1003
`
`Expert Declaration of Dr. Aviel Rubin, Ph.D.
`
`APPLE-1004
`
`U.S. Pub. 2002/0172368 (“Peterka”)
`
`APPLE-1005
`
`U.S. Pub. 2010/0235528 (“Bocharov”)
`
`APPLE-1006
`
`European Patent Pub. 1 418 756 A2 (“Chen”)
`
`APPLE-1007
`
`U.S. Pub. 2009/0254708 (“Balraj”)
`
`APPLE-1008
`
`U.S. Pub. 2012/0254456 (“Visharam”)
`
`APPLE-1009
`
`U.S. Pub. 2008/0270308 (“Peterka308”)
`
`APPLE-1010
`
`U.S. Pub. 2005/0138362 (“Kelly”)
`
`APPLE-1011
`
`U.S. Pub. 2011/0067012 (“Eisen”)
`
`APPLE-1012
`
`U.S. Pub. 2011/0099594 (“Chen594”)
`
`APPLE-1013
`
`APPLE-1014
`APPLE-1015
`
`Chow et al., A White-Box DES Implementation for DRM
`Applications, Pre-Proceedings for ACM DRM-2002 Workshop
`(October 15, 2002)
`RFC793: Transmission Control Protocol (September 1981)
`RFC2616: Hypertext Transfer Protocol – HTTP/1.1 (June
`1999)
`
`
`
`
`ii
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`CLAIM LISTING
`
`Claim Language
`Element
`[1.P] A method for handling secure distribution of content comprising:
`
`[1.1]
`
`[1.2]
`
`[1.3]
`
`[1.4]
`
`[1.5]
`
`[1.6]
`
`[2]
`
`[3]
`
`[4]
`
`initiating a media playback request and receiving a playback request
`response;
`
`parsing content information from the playback request response, the
`content information including content encryption keys, content
`encryption key identifiers, and content encryption key expiration
`times;
`
`retrieving content and manifest files from a content delivery server;
`
`detecting content encryption key rotation boundaries between periods
`of use of different content encryption keys in decrypting retrieved
`content;
`
`issuing requests to a license server ahead of a key rotation boundary
`to retrieve a second content encryption key to be used after a content
`encryption key rotation boundary is reached; and
`
`applying the second key for content decryption after the key rotation
`boundary is reached.
`
`The method of claim 1, wherein the content encryption keys and
`content encryption key identifiers returned in the playback request
`response include the content encryption key and associated identifier
`currently being applied as well as a future content encryption key and
`associated identifier yet to be applied.
`
`The method of claim 1, wherein the content encryption key expiration
`returned in the playback request response is expressed as an expected
`minimum interval between periodic key rotation.
`
`The method of claim 3, further comprising: timing the prefetching of
`a next un-retrieved content encryption key based on an expected
`expiration of the content encryption key currently being used.
`
`iii
`
`

`

`Element
`[5]
`
`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`Claim Language
`The method of claim 4, further comprising: prefetching a next un-
`retrieved key a fixed duration before the expected expiration of the
`content encryption key currently being used.
`
`[6]
`
`[7]
`
`[8]
`
`[9]
`
`[10]
`
`[11]
`
`[12]
`
`The method of claim 4, further comprising: prefetching a next un-
`retrieved key within a period of time after the expected expiration of
`the content encryption key currently being applied, the period of time
`beginning at the expected expiration of the content encryption key
`currently being used, and ending at a duration calculated as a fixed
`percentage of a fixed periodic content encryption key expiration
`interval.
`
`The method of claim 1, wherein subsequent content encryption key
`identifiers are predictable based on a predetermined known
`progression.
`
`The method of claim 7, further comprising: the identifier being
`calculated as monotonically increasing sequential integer values
`based on the number of segments or video frames generated during a
`fixed periodic content encryption key expiration interval.
`
`The method of claim 7, further comprising: the identifier being
`calculated as an expected wall clock time for applying the next
`content encryption key based on a fixed periodic content encryption
`key expiration interval.
`
`The method of claim 1, wherein license server communications are
`secured and authenticated using a selected one of Secure Sockets
`Layer and a token-based technique using a token encrypted with a
`symmetric key.
`
`The method of claim 10, wherein the token-based technique employs
`white box encryption to encrypt the token.
`
`The method of claim 1, wherein actual content encryption key
`rotation boundaries are detected based on real-time in-band
`notifications.
`
`iv
`
`

`

`Element
`[13]
`
`[14]
`
`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`Claim Language
`The method of claim 12, wherein content encryption key rotation
`boundaries are detected based on notifications in an unencrypted
`header portion of the encrypted content files.
`
`The method of claim 12, wherein content encryption key rotation
`boundaries are detected based on notifications present in the content
`manifest file, the content manifest file being selected from an m3u8
`file, an IIS Smooth Streaming manifest file, a DASH MPD file and a
`proprietary manifest file.
`
`[15]
`
`The method of claim 12, wherein content encryption key rotation
`boundaries are detected based on a notification embedded in the file
`name of the encrypted content file.
`
`[16.P] A computerized device operable as a client for handling secure
`distribution of content, comprising:
`
`[16.1] memory operative to store computer program instructions; one or
`more processors; input/output interface circuitry; and interconnect
`circuitry coupling the memory, processors and input/output interface
`circuitry together, wherein the processors are operative to execute the
`computer program instructions from the memory to cause the
`computerized device to:
`
`[16.2]
`
`[16.3]
`
`initiate a media playback request and receive a playback request
`response;
`
`parse content information from the playback request response, the
`content information including content encryption keys, content
`encryption key identifiers, and content encryption key expiration
`times;
`
`[16.4]
`
`retrieve content and manifest files from a content delivery server;
`
`[16.5]
`
`detect content encryption key rotation boundaries between periods of
`use of different content encryption keys in decrypting retrieved
`content;
`
`v
`
`

`

`Element
`[16.6]
`
`[16.7]
`
`[17]
`
`[18]
`
`[19]
`
`[20]
`
`
`
`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`Claim Language
`issue requests to a license server ahead of a key rotation boundary to
`retrieve a second content encryption key to be used after a content
`encryption key rotation boundary is reached; and
`
`apply the second key for content decryption after the key rotation
`boundary is reached.
`
`The computerized device of claim 16, wherein the content encryption
`keys and content encryption key identifiers returned in the playback
`request response include the content encryption key and associated
`identifier currently being applied as well as a future content
`encryption key and associated identifier yet to be applied.
`
`The computerized device of claim 17, wherein the computer program
`instructions further cause the computerized device to time the
`prefetching of a next un-retrieved content encryption key based on an
`expected expiration of the content encryption key currently being
`used.
`
`The computerized device of claim 16, wherein subsequent content
`encryption key identifiers are predictable based on a predetermined
`known progression.
`
`The computerized device of claim 16, wherein actual content
`encryption key rotation boundaries are detected based on real-time in-
`band notifications.
`
`
`
`vi
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`Apple Inc. (“Petitioner” or “Apple”) petitions for Inter Partes Review (“IPR”)
`
`of claims 1-20 (“the Challenged Claims”) of U.S. Patent 9,313,178 (“’178 patent”).
`
`I.
`
`REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104
`A.
`Standing
`Apple certifies that the ’178 patent is available for IPR. Apple has not been
`
`served with a complant for infringement of the ’178 patent. Apple is not barred or
`
`estopped from requesting this review on the grounds identified in Section I.B.
`
`B. Challenge and Relief Requested
`Apple submits that this Petition demonstrates a reasonable likelihood of
`
`prevailing with respect to at least one Challenged Claim, and respectfully requests
`
`institution of IPR and cancellation of all Challenged Claims as unpatentable on the
`
`grounds set forth in the table below. Additional explanation and support for each
`
`ground is set forth in the Declaration of Dr. Aviel Rubin. (APPLE-1003), referenced
`
`throughout this Petition.
`
`Ground
`1A
`
`Claims
`1-4, 6-7, 12-13, 16-20
`
`Basis for Rejection (35 U.S.C. § 103)
`Peterka, Bocharov
`
`1B
`
`1C
`
`1D
`
`1E
`
`7-9, 14-15, 19
`
`Peterka, Bocharov, Peterka308, Chen
`
`5
`
`10
`
`11
`
`Peterka, Bocharov, Balraj
`
`Peterka, Bocharov, Kelly
`
`Peterka, Bocharov, Kelly, Eisen
`
`1
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`The ’178 patent was filed on April 30, 2014, and claims priority through an
`
`intervening application to a provisional patent application filed on June 23, 2011.
`
`For purposes of the analysis herein, and without acquiescence, Petitioner treats June
`
`23, 2011 as the earliest effective filing date (“Critical Date”) of each of the
`
`Challenged Claims in the IPR.
`
`Each of the prior art references applied in Grounds 1A-1E qualifies as prior
`
`art to the ’178 patent on at least the bases shown below:
`
`Reference
`
`Filed
`
`Published
`
`Peterka
`Bocharaov
`Peterka308
`Chen
`Balraj
`Kelly
`Eisen
`
`10/26/2001
`03/16/2009
`08/22/2007
`---
`04/06/2009
`12/22/2004
`05/25/2009
`
`11/21/2002
`09/16/2010
`10/30/2008
`05/12/2004
`10/08/2009
`06/23/2005
`03/17/2011
`
`Pre-AIA 35 U.S.C. §102
`Prior Art Basis
`§102(a)-(b), (e)
`§102(a), (e)
`§102(a)-(b), (e)
`§102(b)
`§102(a)-(b), (e)
`§102(a)-(b), (e)
`§102(a), (e)
`
`
`
`None of the references applied in Grounds 1A-1E were previously cited or
`
`applied in a rejection during prosecution of the ’178 patent. Apple respectfully
`
`submits that discretionary institution denial under 35 U.S.C. § 325(d) would be
`
`unwarranted under these circumstances. Advanced Bionics, LLC v. MED-EL
`
`Elektromedizinische Geräte GmbH, IPR2019-01469, Paper 6 (PTAB Feb. 13, 2020)
`
`(precedential).
`
`2
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`
`II.
`
`SUMMARY OF THE ’178 PATENT
`A. Brief Description
`The ’178 patent generally describes “over-the-top (OTT) media delivery and
`
`more specifically [] encryption key rotation for live streaming media.” APPLE-
`
`1001, 1:15-17; APPLE-1003, ¶41. For example, the specification discloses a server
`
`that streams to a client device segments of media content that are each encrypted
`
`with a different content encryption key. Id., 1:38-42, 1:63-65. The client
`
`communicates with a licensing server during the stream to pre-fetch content
`
`encryption keys ahead of key rotation boundaries, and the client then applies a
`
`retrieved key to decrypt a corresponding segment of the media stream. Id., 11:3-25,
`
`11:38-62. “The transitioning between use of different keys is also referred to … as
`
`key ‘rotation’.” Id., 1:63-65.
`
`3
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`
`
`
`APPLE-1001, FIG. 1; generally id., 9:47-11:62.
`
`B.
`Summary of the Prosecution History
`The file history of the ’178 patent reveals minimal substantive interactions
`
`between the applicant and the Examiner during original prosecution. See APPLE-
`
`1002; APPLE-1003, ¶42. The Examiner identified all original claims 1-20 as
`
`allowable in a first action dated May 26, 2015. Id., 61-65. The Examiner cited one
`
`reference in this action, i.e., U.S. Pub. 2005/0060316 to Kamath et al., but did not
`
`4
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`substantively comment on the reference. Id., 65. The Examiner subsequently
`
`allowed the application in a notice dated October 28, 2015. Id., 19-25. The
`
`Examiner’s reasons for allowance stated “the prior art of record (Kamath
`
`20050060316) does not teach detecting content key rotation boundaries and issuing
`
`requests to a license server ahead of the key rotation boundaries.” Id., 24.
`
`C. Level of Ordinary Skill in the Art
`For purposes of this IPR, Petitioner submits that a person of ordinary skill in
`
`the art at the time of the alleged invention (“POSITA”) would have had a
`
`Bachelor’s degree in computer science, computer engineering, or a related field,
`
`and 2-3 years of practical engineering experience, including experience designing
`
`or researching information security systems that employ cryptographic keys to
`
`encrypt/decrypt digital data. APPLE-1003, ¶¶23-26. Additional education could
`
`substitute for professional experience, or significant experience in the field could
`
`substitute for formal education. Id.
`
`III. CLAIM CONSTRUCTION UNDER 37 C.F.R. §§ 42.104(b)(3)
`All claim terms should be construed according to the Phillips standard.
`
`Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005); 37 C.F.R. §42.100.
`
`Based on the prior art’s description of the claimed elements being similar to
`
`that of the ’178 patent specification, no formal claim constructions are presently
`
`necessary since “claim terms need only be construed to the extent necessary to
`
`5
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`resolve the controversy.” Wellman, Inc. v. Eastman Chem. Co., 642 F.3d 1355, 1361
`
`(Fed. Cir. 2011); APPLE-1003, ¶¶43-44.
`
`Petitioner reserves the right to respond to any constructions offered by Patent
`
`Owner or adopted by the Board in accordance with due process. Furthermore,
`
`Petitioner is not conceding that the Challenged Claims satisfy all statutory
`
`requirements including those under 35 U.S.C. § 112.
`
`IV. THE CHALLENGED CLAIMS ARE UNPATENTABLE
`A.
`[Ground 1A]: Peterka in view of Bocharov
`1.
`Peterka
`Peterka describes systems for securely delivering streaming media content to
`
`authorized devices over a network. APPLE-1004, [0038], [0006]-[0012], Abstract,
`
`FIG. 1; APPLE-1003, ¶¶45-56. To provide customers with different options for
`
`streaming media, Peterka’s system divides streams into “segments,” and encrypts
`
`each segment with a different content key. APPLE-1004, [0099] (“divide a single
`
`program event or an entire service into purchasable segments”), [0101] (the “content
`
`key” is “used to encrypt the content itself” and “should change at least as often as
`
`the [program segment key]”), [0091]-[0093], [0122]-[0125], FIGS. 7A-7B; APPLE-
`
`1003, ¶¶46-47. To playback an encrypted segment of the media stream, the client
`
`must obtain the corresponding “content key” for that was used to encrypt the
`
`segment, and must apply the content key to decrypt the segment before it can be
`
`6
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`played. Id., [0127] (“utilize the content key to decrypt the encrypted program
`
`content”), [0091]-[0093], FIG. 7A.
`
`To protect content keys from unauthorized use, Peterka teaches that the
`
`content keys themselves can be encrypted by other, higher-level (secondary) keys.
`
`Id., [0094]-[0104]. For authorized users, the system issues (1) an encrypted version
`
`of the content key for a given segment of media content and (2) at least one
`
`secondary key (e.g., UK, PK, PSK, or SK). Id. The secondary key is a key that is
`
`used to encrypt the content key (or another key) before the content key is distributed
`
`to users, and the user’s device can subsequently apply the secondary key to decrypt
`
`the encrypted content key (or to decrypt another encrypted key). Id. Peterka provides
`
`additional detail about the content key in paragraph [0101] and the program segment
`
`key (PSK), program key (PK), service key (SK), and unique key (UK) in paragraphs
`
`[0094]-[0104]; APPLE-1003, ¶¶48-50.
`
`Peterka thus discloses that the PSK, PK, and SK are shared keys distributed
`
`to the client devices of potentially all users within a corresponding distribution
`
`scheme (e.g., subscription, pay-per-view, or pay-by-time). A same encrypted
`
`version of the content key can be distributed to all users within a corresponding
`
`distribution scheme, since all such users can apply their respective secondary key
`
`(e.g., PSK, PK, or SK) to decrypt the content key. Id., [0094]-[0104]. On the other
`
`hand, shared secondary keys are unnecessary when the system delivers an encrypted
`
`7
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`version of the content key that is specific to an individual user by encrypting the
`
`content key with that user’s unique key (UK). Id., [0095], [0104] (“only keys
`
`distributed to individual clients (shown as keys encrypted under the UK) using the
`
`UK are delivered in a unicast fashion”), [0108] (“a unique key for a particular client
`
`could be used to distribute the new key to that particular client”), [0125]
`
`(“Alternatively, CK2 may be encrypted with the UK and delivered in the form of an
`
`EMM directly to the client”).
`
`Peterka further describes techniques for implementing “free” and “initial”
`
`viewing periods during which users may access an initial portion of encrypted media
`
`content before a user decides to purchase the content (or otherwise before keys
`
`encrypted by a user’s unique key have been distributed). See id., [0005], [0059],
`
`[0083]-[0093], [0122]-[0134], FIGS. 3-6, 7A-7B. The free preview period is
`
`implemented by distributing a “free preview key” (FPK) to users in advance of a
`
`program’s start time. Id., [0059], [0103]. The FPK can be applied either to decrypt
`
`a content key encrypted by the FPK, or the FPK can be applied to decrypt the media
`
`content directly during the free preview period. Id., [0086], [0123]-[0124], [0129].
`
`The “initial” viewing period then allows users who have requested to continue
`
`consuming the content beyond the free preview period. Id., [0126]-[0133]. During
`
`the initial viewing period, users can apply a “group key” (GK) either to decrypt a
`
`content key encrypted by the GK for the initial viewing period or to directly decrypt
`
`8
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`the media content during the initial viewing period. Id., [0123]-[0124], [0128]-
`
`[0129].
`
`Figure 7B, for example, shows how a group key may be applied during the
`
`initial key distribution period to decrypt content key CK1:
`
`
`
`APPLE-1004, FIG. 7B (annotated), [0122]-[0125].
`
`Peterka’s system streams encrypted media content to client devices in packets,
`
`e.g., RTP packets. Id., [0117]-[0120]. Servers further distribute keys to client
`
`devices in Entitlement Control Messages (ECMs) or Entitlement Management
`
`Messages (EMMs). Id., [0104], [0121]-[0125], FIG. 7B; APPLE-1003, ¶¶52-53.
`
`In some embodiments, Peterka’s system implements a “pull model” that
`
`9
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`leaves client devices with the responsibility for requesting keys from a server at
`
`appropriate times ahead of a segment boundary. See id., [0105] (“Under the pull
`
`model, each client keeps track of the keys and their expiration times and actively
`
`requests new keys before the current keys expire so as to avoid service
`
`interruptions.”), [0106], FIG. 8; APPLE-1003, ¶¶54-56.
`
`2.
`Bocharov
`Bocharov discloses “[a] smooth streaming system [that] provides a stateless
`
`protocol between a client and server” for distribution of streaming media content.
`
`APPLE-1005, Abstract, [0001], [0007], [0053], FIGS.3-5; APPLE-1003, ¶¶57-60.
`
`Figure 5 is a flow diagram that depicts interactions between an origin server 510, an
`
`encoder 505, and a client 515 in Bocharov’s system:
`
`10
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`
`
`
`APPLE-1005, FIG. 5.
`
`As shown in Figure 5, “[t]he encoder 505 continuously provides media data
`
`520 to the origin server 510.” Id., [0053]. “The media data may include fragments
`
`of an MP4 stream based on a live event, for example.” Id. “The origin server 510
`
`archives 525 each media fragment, such as to a local data store.” Id. “The origin
`
`server 510 receives a manifest request 530 from a client 515,” and “generates 535 a
`
`client manifest based on the latest media fragment information.” Id. “The origin
`
`11
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`server 510 provides a client manifest response 540 to the client 515,” “[t]he client
`
`515 then sends one or more media fragment requests 545, and the origin server 510
`
`responds 550 with the requested media fragment and potentially information about
`
`subsequent media fragments.” Id.; see also id., [0006]-[0007], [0014]-[0016],
`
`[0021]-[0031], [0049]-[0057], [0060].
`
`Bocharov teaches that the “client manifest” includes information useful for
`
`the client to request media fragments from a server for either pre-recorded or live
`
`programming. For example, the manifest can provide timestamps for each fragment
`
`archived up to the point of the request, and the client uses the timestamp to compose
`
`a URL for requesting the fragment from the server. Id., [0030]-[0031]. The manifest
`
`can further identify different available codings of the media content. Thus, if a
`
`program has been encoded in multiple bit rates, the client can reference the manifest
`
`to “begin requesting fragments in whichever encoding the client chooses.” Id.,
`
`[0049]. “For example, the client may initially select a low bit rate encoding and
`
`select a higher bit rate encodings for subsequent fragments until network bandwidth
`
`limits the client’s ability to receive the fragments at a bit rate.” Id.; see also id.,
`
`[0023]-[0025], [0031]-[0031], [0049], [0052], [0057], [0060].
`
`3. Obviousness Based on Peterka-Bocharov Combination
`(a) Overview of Combination
`As described above, Peterka describes techniques for distributing streaming
`
`12
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`media content to client devices over a network. Supra, Section IV.A.1; APPLE-
`
`1003, ¶¶68-75. According to Peterka, servers are configured to stream encrypted
`
`media content to client devices, and the client devices in turn apply decryption keys
`
`to recover clear versions of the content for playback. APPLE-1004, [0002], [0004],
`
`[0038]. Peterka explicitly notes that the transmission network “can be implemented
`
`in a variety of ways,” and can employ various protocols suitable for directly
`
`streaming media content or facilitating streaming (e.g., UDP, RTP, RTCP, IGMP,
`
`TSP, SAP/SDP). Id., [0043]; see also id., [0038]-[0043], [0117] (“refers to use of
`
`an RTP packet for distributing program content; however, it could equally apply to
`
`other protocols utilized in distributing content”), FIGS. 1, 14.
`
`Peterka also teaches that streaming content can be offered at different
`
`“qualit[ies]” (i.e., “bit rates”). Id.., [0054]. For example, “[t]he client may report
`
`the highest bit rate it can consume and be offered to purchase the content at that
`
`quality or less.” Id., [0054]. However, beyond the brief description of these features
`
`in paragraph [0054], Peterka offers little additional detail as to how multi-bit-rate
`
`streaming could be implemented or how a client could “adjust the bit rate perceived
`
`by the user,” for example. Id.; APPLE-1003, ¶69.
`
`Bocharov demonstrates that techniques for managing multi bit-rate streaming
`
`services were not new in the ’178 patent. APPLE-1003, ¶70. As discussed above,
`
`Bocharov discloses techniques that allow a client to obtain fragments of media
`
`13
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`content “in whichever encoding the client chooses.” APPLE-1005, [0049]; see also
`
`id., [0007], [0014], [0016], [0049]-[0062], [0060], FIG. 5; supra, Section IV.A.2.
`
`Bocharov’s solution involves issuing manifest files to clients, where the manifest
`
`specifies different encodings available for streaming media fragments. Id.
`
`According to Dr. Rubin, it would have been obvious to a POSITA by the
`
`Critical Date of the ’178 patent to combine the teachings of Peterka and Bocharov
`
`to achieve predictable benefits. APPLE-1003, ¶¶71-75. For example, as shown in
`
`Figure 5 of Bocharov, it would have been predictable for a client device in a Peterka-
`
`Bocharov combination to issue a client manifest request to a server, and to obtain a
`
`manifest in response. APPLE-1005, [0053], FIG. 5. Consistent with Bocharov’s
`
`teachings, the manifest can include information that allows a client to request
`
`delivery of streaming media content, such as information indicative of a URL for the
`
`media content. Id., [0030]-[0031]. As described in Bocharov, the manifest can also
`
`identify different encodings such that the client could request delivery of the
`
`streaming media according to a particular encoding (e.g., corresponding to a desired
`
`“quality” or “bit rate”). Id., [0030]-[0031], [0048]-[0050]. Further, in some
`
`implementations (although not required), the manifest provides a list of fragments
`
`in the media stream with information indicative of a URL for each fragment. Id.
`
`Individual client devices can then reference the manifest to request timely delivery
`
`of fragments to maintain a continuous media stream. Id.
`
`14
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`Multiple reasons would have led a POSITA to combine the teachings of
`
`Peterka in view of Bocharov in a manner like that described in the preceding
`
`paragraph. APPLE-1003, ¶72. To start, the teachings of Peterka and Bocharov are
`
`both directed to highly similar systems for streaming media content. See supra,
`
`Sections, IV.A.1-2; APPLE-1004, Abstract, [0002], [0004], [0038]-[0043], [0117],
`
`FIGS. 1, 4; APPLE-1005, [0001], [0007], [0014]-[0016]; APPLE-1003, ¶72. Both
`
`references describe technologies that are particularly useful for live streaming, and
`
`each provides solutions for managing loads that can result from large numbers of
`
`users requesting access to live streamed content at nearly the same time. E.g.,
`
`APPLE-1004, [0064] (“there will be a large number of clients requesting access to
`
`the same event at the same time” and this “will generate a large load on the system
`
`within a relatively small time window”), [0126] (“If the population is very large, a
`
`server will be unable to distribute keys to all participants instantly”), [0083]-[0093]
`
`(“free preview period”), FIGS. 7A-7B; APPLE-1005, [0014] (“Caching reduces the
`
`load on the server and allows more clients to view the same content at the same
`
`time.”), [0052]. Bocharov’s use of manifests to regulate client content delivery
`
`would thus complement Peterka’s techniques for distributing keys to many users to
`
`access encrypted media content, thereby improving the resulting system’s ability to
`
`handle large loads with respect to both content delivery and key distribution.
`
`APPLE-1003, ¶72. Both references also stream similar types of media (e.g., video,
`
`15
`
`

`

`Attorney Docket No. 50095-0082IP1
`IPR of U.S. Patent No. 9,313,178
`MP4 files) and apply segmentation to divide the media into smaller chunks (e.g.,
`
`fragments) for distribution. APPLE-1004, [0080], [0119]; APPLE-1005, [0016],
`
`[0020], [0034], [0038]-[0039]; APPLE-1003, ¶72.
`
`Moreover, applying Bocharov’s suggested use of manifests in combination
`
`with Peterka would have provided an effective solution for distributing multiple
`
`versions of a media program having different encodings/qualities/bit rates. APPLE-
`
`1003, ¶73. Peterka’s original disclosure already acknowledged the benefit of
`
`providing streams of different qualities that could accommodate changing user
`
`demands and network conditions, and Bocharov’s manifest would have been
`
`predictable to provide clients with the information needed to more readily se