PUBLIC VERSION
`
`from the prior art. A claim that includes a negative limitation satisfies the written description
`
`requirement of35 U.S.C. § 112, 11 1 if, for example, the specification describes a reason to
`
`exclude the relevant subject matter from the invention. See San-rcn‘u.s', Inc. 1-‘. Par Pharm. Inc,
`
`694 F.3d 1344, 1351 (Fed. Cir. 2012). The ’8?3 patent specification fails to mention the
`
`negative limitation, much less describe any disadvantages associated with “user input" at the
`
`second device. See RX-0460C (Almeroth DWS) QIA 315. Moreover, the evidence shows that
`
`one of ordinary skill would not understand the benefits of excluding user input on the second
`
`device when reading the specification and the embodiments discussed therein. Sec Almeroth Tr.
`
`665-666. Accordingly, one of ordinary skill would conclude that the applicant was not in
`
`possession of the “without user input“ negative limitation when the original application was
`
`tiled. See RX-0460C (Almeroth DWS) QIA 315. All of the asserted claims are therefore invalid
`
`under 35 U.S.C.. § 112, 111.
`
`Although the Scmrarns opinion was published only recently, the Patent Trial and Appeal
`
`Board has applied the Santa:-'u.s' rule and 35 U.S.C. § 112, 11 1 to reject numerous claims with
`
`negative limitations.
`
`For example, in Ex parre Miyashira, the claim at issue recited an Internet-based chat
`
`system comprising a server and multiple clients. Ex parle Mr'ya.s'i1i!a, Appeal 2010-010626, 2013
`
`WL 1401042, at *1 (Patent Tr. & App. Bd. Mar. 29, 2013). The limitation at issue in M1'ya.s'hira,
`
`requiring that the server receives information and forwards the information to a client “without
`
`solicitation from the [client],"’ is similar to the “without user input" limitation at issue here. Id.
`
`The applicant in llzfi}-'a.s'l1ita cited to a flow chart showing communications between the server and
`
`clients, and argued that there is written description support for the negative limitation because
`
`the flow chart does not show solicitation by any client. See id. at *3.
`
`In affirming the rejection_.
`
`175
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`the Board applied the .S'tm!arus rule and held that “Appellant’s Specification neither explicitly
`
`describes the negative limitation of excluding a solicitation .
`
`.
`
`. nor indicates possession of this
`
`feature by describing any advantage of excluding a solicitation or disadvantage of including a
`
`solicitation.” Id. at *3. With regard to the flow chart, the Board determined that “silence in the
`
`Specification is not enough to show possession of the claimed exclusion of a solicitation-” Id.
`
`In Ex parre Lazarz'df.s'_. the claim at issue recited a method for launching sofiware
`
`applications, wherein the launch occurs “without the user having entered a delimiter denoting an
`
`end of the text string.” Ex parte Lazaridr'.s', Appeal 2010-005137, 2013 WL 1331529, at *2-4
`
`(Patent Tr. & App. Bd. Mar. 12, 2013). Therefore, the limitation in Lazard:'.s' concerned
`
`performing an action without a user input. The specification did not explain the negative
`
`limitation, but provided an example where entering the text “e_j" would cause the application to
`
`send mail. Id. at *3. The Board affirmed the rejection, holding that because the exemplary
`
`embodiment “requiring only two key strokes to invoke the email compose1' application” does not
`
`explain any disadvantages to command-ending delimiters, the claim “e-1°Fectively introduces a
`
`new concept that is not reasonably supported by the original disclosure.” Id.
`
`Additional opinions from the Patent Trial and Appeal Board are consistent with Sanrarus.
`
`See Ex pane Jung, Appeal 20] 1-007279, 2013 WL 6698804, at *3-4 (Patent Tr. & App. Bd.
`
`Dec. 18, 2013); Ex Pane H0, Appeal 201 1—00v-1664, 2013 WL 566';'032_, at *2 (Patent Tr. & App.
`
`Bd. Oct. 15, 2013); Ex Parre Hullnf, Appeal 201 1-002453, 2013 WL 5406700, at *2-3 (Patent
`
`Tr. & App. Bd. Sept. 17, 2013); E.rpm'le Lorerz, Appeal 2010-009480, 2013 WL 1332674. at
`
`*3-4 (Patent Tr. & App. Bd. Feb. 27, 2013); Ex parte Bright, Appeal 2013-003725, 2013 WL
`
`663563. at *2-3 (Patent Tr. & App. Bd. Feb. 21, 2013); Ex parre Chit, Appeal 2011-01 1442,
`
`2013 WL 524284, at *2-3 (Patent Tr. & App. Bd. Feb. 5, 2013); Exparre Pyka, Appeal 2010-
`
`176
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`005667, 2012 WL 67172010, at *2-3 (Patent Tr. & App. Bd. Dec- 31, 2012); Ex parre Kimura.
`
`Appeal 2010-010869, 2012 WL 6114315, at *3-4 (Patent Tr. & App. Bd. Nov. 27, 2012).
`
`Recent opinions from the Federal Circuit and from the Northern District ofCalifomia
`
`have also applied Section 112 to reject claims that include negative limitations when the
`
`specification lacks written description support. See In re Bimeda Research cl’: Devefopmem Ltd,
`
`724 F.3d 1320, 1323-24 (Fed. Cir. 2013) (finding that the negative limitation “is not supported in
`
`the disclosure as originally filed”); Tse v. Google, Inc, Nos. C 13-0194, 13-1204, WL 6502428,
`
`at *3-6 (ND. Cal. Dec. 1 1, 2013) (finding that there is nothing in the original disclosure that
`
`conveys to a skilled artisan that the applicant was in possession of the “no-charge” negative
`
`limitation).
`
`As the law ofwritten description is applied in Scmlams and its progeny, where a claim
`
`expressly contains a negative limitation, the specification must show that the applicant possessed
`
`such an invention when the application was filed.
`
`In the case of the ’8?3 patent, the applicant
`
`added the “without user input” limitations during prosecution to distinguish the claims from the
`
`prior art, but there is no indication in the specification that the inventor was in possession of an
`
`invention that excluded “user input via the second device” at the time the application was filed.
`
`Accordingly, it is determined that each asserted claim of the ‘"873 patent is invalid under 35
`
`U.S.C.§ 112,111.
`
`3.
`
`Indefiniteness
`
`Respondents allege that the device claims, 23, 30, 34, 3?, and 45, ofthe ‘S73 patent are
`
`invalid under §l12, 11 2 as indefinite.
`
`In particular, Respondents allege that the “without user
`
`input” limitation renders the claims indefinite. See, e.g., RX-0460C.066.._ RX-0738C (Almeroth
`
`WS and errata) QIA 317. It is alleged that “one of ordinary skill in the art cannot determine
`
`177
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`whether an accused ‘device for selecting a media itern’ infringes without also looking at the
`
`selected ‘second device’ .
`
`.
`
`. to determine whether any “user input via the second device’ is
`
`required.” See in’. However, a claim is not indefinite unless the claims do not, when “viewed in
`
`light of the specification and prosecution history, inform those skilled in the art about the scope
`
`of the invention with reasonable certainty.” Nmm'Zus_. Inc. v. Bi'o.s':'g In.s'rrr.m-tents, Inca, _ U.S.
`
`_, No. 13-369, at 11 (June 2, 2014).
`
`Here, the evidence shows that a person of ordinary skill in the art would consider the
`
`claim language amenable to construction following a review of the claim language itself in view
`
`of the specification and prosecution history. The ’873 device claims are directed to a first device
`
`(e.g., a mobile device) configured to facilitate directing a second device to receive media without
`
`user input at the second device. Inasmuch as Dr. Loy understood the claims to the extent he was
`
`able to formulate infringement opinions with respect to the accused products demonstrates that a
`
`person of ordinary skill in the an would be informed about the scope of the invention with
`
`reasonable certainty.
`
`Therefore, Respondents have not shown by clear and convincing evidence that the
`
`asserted ’873 claims are invalid for indefiniteness.
`
`4.
`
`Validity Analysis in View of the Prior Art
`
`Although it was determined above that the asserted claims of the ’873 patent are invalid
`
`for lack of a written description under 35 U.S.C. § 112,1] 1, the record evidence regarding
`
`anticipation and obviousness of these claims is summarized below for completeness. As
`
`discussed below. based on the parties’ arguments and the record evidence, there would be no
`
`impediment to finding the asserted claims invalid for anticipation andfor obviousness if the
`
`l78
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`patent disclosure adequately conveyed to a person having ordinary skill in the art that the
`
`inventor had possession ofthe claimed subject matter as of the filing date.
`
`:1.
`
`Priority Date
`
`The ‘S73 patent is a continuation of Application No. l0f840,109, which was filed on May
`
`5, 2004, and ultimately issued as the ’323 patent. See .lX~0003 (‘B73 patent). The priority date
`
`for the ‘S73 patent is therefore May 5, 2004. See id.
`
`b.
`
`Weast - Anticipation of Claims 1, 5, 8, 17, 22, 23, 30, 34, and 37
`
`U.S. Patent No. 7,454,511 (“Weast”_), titled “Visibility of UPnP Media Renderers and
`
`Initiating Rendering via File System User Interface," was filed on May 29, 2003. See RX-0075
`
`(Weast). Weast qualifies as prior art to the ‘S73 patent under § l02(e).
`
`Weast describes an implementation of the UPnP AV Architecture. Weast discloses “a
`
`user friendly technique to employ UPnP media renderers to render media content available from
`
`UPnP media servers.” In’. at col. 1, Ins. 8-10. The UPnP AIV Media Server provides media
`
`contents, the UPnP AN Media Renderers play the provided media contents, and the control
`
`point controls the cooperation between the complying media servers and the complying media
`
`renderers. Id. at col. 1, Ins. 40-46. The control point may be “a desktop computer, a laptop
`
`computer, a tablet computer, a palm-sized computing device, a PDA, a set-top box, an
`
`entertainment center controller, a wireless mobile phone, and so forth." Id. at col. 5, Ins. 10-15.
`
`The 3-box architecture disclosed in the ‘S73 patent (below, left) is identical to the architecture
`
`disclosed in Weast (below, right):
`
`179
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`
`
`RDX-0004.005 (JX-0003 (’873 patent) FIG. 1); RDX-0005.003 (RX-0075 (Weast) at Fig. 1).
`
`The communication protocols employed by the control point to interact with and control
`
`UPnP media servers and UPnP renderers are depicted in vario us figures in the Weast patent. As
`
`shown in Figure 3a, the control point requests an identification of media content and the
`
`corresponding mctadata from a UPnP media server, and the UPnP media server provides the
`
`requested identification of media content and metadata to the control point:
`
`D'Luoovq')-Ping:-302
`j
`
`Mdjlsflwn
`Rsespnsclnflriscnwery -30-I
`age -104:
`
`Rnqu¢nufo¢IduuiliuI1iunInda'otDescripIiou
`nfwnflahhhledhcomnus-306
`Iamtlsurm -lndJ'utDewrlpI§anoflvIi!:ble mm.
`comm -ans
`4—
`
`lnslparxinnsluprmriciaaudcouuvlptolvisionof
`MediICnntwl-I -310
`'— '
`
`'
`
` I
`
`I
`Media Coolants to Medin
`In.-ndems
`
`'WT"'°||| M°‘‘ilRWi=f=f
`S==l‘''-x- 31:
`
`1753"" 3‘
`
`Id. at Fig. 3a elements 306, 308; see also id. at col. 5, lns. 29—39. The control point receives
`
`information relating to the available media content and displays it to the user via a user interface
`
`on the control point. See id. at col. 5, Ins. 40-44; Fig. 421. As shown in Figure 3b, a control point
`
`180
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`discovers the presence of LlPnP media renderers in a network domain by issuing discovery pings,
`
`and the media renderers respond to the control point with description infonnation:
`
`lliserwcry l’in,g.5 - 312
`
`Mum
`Response to Dismvaxy —- 314
`comm] Fain,
`- 102 4 Rgndum
`
`Request for ldciilificution an-I‘.L"or Description
`of Media Rmillcriltg Cnpnbiiity —. 316
`
`‘ “'6
`
`Identification andfot Dcscziplion of Media
`Rendering Capability - 31$
`1--—e—~—————-——-—————
`
`r.:s.uu::'»..ns'io runciva and mum 1\lc.Lin
`Conlcnls -- 320
`
`I
`To-fl-"mm M1:-ii-1 Server
`See Fig. 311
`
`Egan 1”’
`
`'
`
`I
`Media Cunncnls From
`Iwcuiia Senrm
`
`Id. at Fig. 3b elements 312, 314; see also id. at col. 5, in. S9 — col. 6, ln. 6; Fig. Sb. The control
`
`point displays this information to a user via the control point user interface. See id. at col. 6, Ins.
`
`7-1 1 .
`
`According to Weast, a user may use the control point to select the media content and the
`
`media renderer on which the content is to be played, and the control point instructs the applicable
`
`renderer to receive and render the selected media content from the media server. See id. at Fig.
`
`6b; Fig. 5b; col. 6, ln. 19-23; Fig. 3b element 320. Thereafter, the control point operates as a
`
`remote control for the rendering device by, for example, pausing or stopping playback and
`
`adjusting the volume. See id. at col. 8, 1115. 53-64.
`
`Through his direct witness statement, Dr. Almeroth testified that Weast anticipates
`
`asserted claims 1, S, 8, 1?, 22, 23, 30, 34, and 37 under any of the proposed claim constructions.
`
`See RX-0460C (Almeroth DWS) Q/A 150-210. BHM"s expert, Dr. Loy, did not dispute that
`
`Weast discloses the vast majority of the limitations recited in these claims. See CX-1401C (Loy
`
`RWS) QKA 107-19. Dr. Loy disputes that Weast discloses the following limitations:
`
`181
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`0
`
`“receiving, on the first device, a playlist" and “selecting at least one media item
`
`identifier from the received playlist” (claim 1, and similar “playlist"’ limitations in
`
`other asserted claims); and
`
`0
`
`“directing the at least one second device to send information representative of the
`
`at least one media item name to a content server“ (claim 23).
`
`See id. The disputed limitations are discussed below.
`
`BHM does not dispute that Weast discloses a “playlist"' under the adopted construction or
`
`the construction by Staff. BHM contends that Weast does not disclose a “playlist" under BHM’s
`
`proposed construction, which defines the term as “a list referencing media items arranged to be
`
`played in a sequence.”
`
`Weast discloses that a control point requests at identification of media items available
`
`from the media server, along with corresponding metadata describing the available media items.
`
`See RX-00'?5 (Weast) at col. 5, lns. 29-35; Fig- 3a. The control point then receives the
`
`identificati on of media and corresponding metadata from the media server, which may include
`
`Z.’tMvMedia\Mmit
`File Edit View Hc|n—IllI:I
`
`reams: IE! -M
`Addznu-: ?_"tM_flbie6:I'uI-IIIIS:
`
`
`
`
`
`Music
`Music
`
`D9.:"J.SmEI
`08.'2|JI'fll
`
`information such as the title, size, version, date of
`
`creation, media type, and artist of the media, and
`
`displays the information to the user via a user
`
`interface on the device. See id. at col. 5, Ins. 36~47_:
`
`Almeroth Tr. 662. Figure 4a in Weast (at right) is
`
`an example of the music playlist received by the
`
`control point, which consists of multiple songs.
`
`123KB
`2-15KB
`
`
`
`
`
`361KB
`
`
`Music
`
`02105302
`
`
`
`
`Flgnm £3
`
`Applying the methodology that Dr. Loy applies for purposes of infringement, Weast discloses a
`
`“playlist” under BHM°s proposed construction. Specifically, the list of songs disclosed in Wcast
`
`l82
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`is received by the control point from the media server and is arranged to be played in a sequence
`
`determined, for example, by song title. See RX-0075 (Weast) at col. 8, lns. 34-64; Fig. 7;
`
`RX-0460C(_A11neroth DWS) QIA 165-67, 175.
`
`BHM’s expert testified that Weast fails to disclose a “playlist” under BI-IM’s proposed
`
`construction because the content displayed at the control point resembles a “Windows-type
`
`interface that merely lists the files available," the "files could be sorted, for example, by the date
`
`column, or the size column,” and such a list does not “enable, or intend, playback in sequence."
`
`CX—1401C (Loy RWS) QKA 107. Dr. Loy’s opinion conflicts with his opinions on infringement,
`
`in which he pointed to music files stored in a Windows Explorer folder as evidence that
`
`Respondents’ accused mobile devices satisfy the “receiving a playlist” limitation under BHMIS
`
`proposed construction. See RX-0671C (LipoffRWS) QIA 193-203; CPX-0141C (Test Video
`
`502); Loy Tr. 406-423. Moreover, the list of songs received by the control point in Weast is
`
`“capable of“ being played in the sequence in which they are listed, which satisfies one of Dr.
`
`Loy’s interpretations ofBHM"s construction. See Loy Tr. 417; see also RX-0460C (Almeroth
`
`DWS) QKA 175. To the extent Dr. Loy testified that loading the songs into a media player is an
`
`additional requirement of BHM’s construction, Weast also discloses this feature. See Loy Tr.
`
`417, 500; CDX-0132.061. Figure 7 discloses an embodiment wherein the user may drag and
`
`drop songs into a “Music Player“ folder for a rendering device, which causes the songs to be
`
`“queued” in a specific order for the renderer to play. See RX-0075 (Weast) at col. 8, lns. 34-64;
`
`Fig. 3'; Loy Tr. 11732-1734.
`
`Weast states that the media renderer “pulls” the content item from the media server in
`
`response to an instruction received from the control point. See RX—007S (Weast) at col. 5, lns.
`
`50-5 7; col. 6, lns. 19-23; Fig. 3b element 320. Therefore, one of ordinary skill would understand
`
`183
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`that the media renderer sends infonnation representative of the selected media item to the media
`
`server so that the server can retrieve the item from its memory and transfer the content to the
`
`renderer. See RX-0460C (Almeroth DWS) QKA 194. BHM’s expert Mr. Zatkovich testified that
`
`one of ordinary skill would understand that in a “pull” operation, the tenderer makes a request to
`
`the media server for the media item that it should receive, and that the request includes “an
`
`identifier" for the item. Zatkovich Tr. 1564-1566; see also RX-0142 (ContentDirectory:l)
`
`(L1PnP_000215) (a request by a renderer for the content item includes a URI for the media item).
`
`BHM’s other 6Kp€l'l Dr. Loy testified differently. Dr. Loy stated, “Weast makes no
`
`mention as to which device sends the media item identifier to the media server,” and testified
`
`that the control point might do so instead. See CX-1401C. (Loy RWS) QIA 114. However, this
`
`hypothetical scenario describes a “push” protocol, wherein the media server receives a
`
`description of the selected item from a control point, retrieves the item, and transfers the content
`
`to the tenderer. See RX—0460C (Almeroth DWS) Q/A 119; Zatkovich Tr. 1564-1565. As noted,
`
`Weast expressly discloses the use of a “pull” protocol, wherein the renderer receives a
`
`description of the selected item from a control point and makes a request to the media server for
`
`the content by passing the description of the selected content to the server. See RX-0460C
`
`(Almeroth DWS) QIA 194; Zatkovich Tr. 1564-1566.
`
`As for the additional limitations recited in asserted claims 1, 5, 8, 17, 22, 23, 30, 34, and
`
`37 of the ’873 patent, Dr. Almeroth provided an element-by-element invalidity analysis for each
`
`ofthese asserted claims. See RX-0460C (Almeroth DWS) Q/’A 157-175 (claim 1), 176 (claim
`
`5), 177-178 (claim 8), 182-183 (claim 17), 185 (claim 22), 186-195 (claim 23), 205-206 (claim
`
`30), 207 (claim 34), 208 (claim 37).
`
`184
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`c.
`
`UPnP AV 1.0 — Anticipation of Claims 1, 3, 16, 17, 19, 22, 23,
`30., 37, and 45
`
`The UPnP AV Architecture specification (“UPnP AV L0"), dated June 25, 2002,
`
`“defines the general interaction between UPnP Control Points and UPnP AV devices” in
`
`scenarios involving the flow of content from one device to another device over a network.
`
`RX-0140 (UPnP AV 1.0) (UPnP_00005 I -052). “[T]hree distinct entities are involved: the
`
`Control Point, the source of the media content (called the ‘Media Server’), and the sink for the
`
`content (called the ‘Media Rendere1"‘_).'"' Id. (UPnP_000053). The Control Point “coordinates
`
`and manages the operation of the Media Server and Media Renderer as directed by the user (e.g.,
`
`play stop, pause) in order to accomplish the desired task (e.g., play "‘MyFavorite"’ music).” Ia‘.
`
`(UPnP_0000S4). UPnP AV 1.0 explains that the Control Point device may be a “wireless
`
`PDA-like device with a small display,” while the Media Rend.erer may be a “TV, stereo,
`
`network-enabled speakers, MP3 players," etc. Id. (UPnP_0{JO053, UPnP_O00054). UPnP AV
`
`1.0 depicts a 3-box architecture in Figure 3 (illustrated below).
`
`In’. (UPnP_000053).
`
`According to UPnP AV 1.0, “the Media Server contains (entertainment) content that the
`
`user wants to render (rag. _, display or listen to) on the Media Renderer.” Id. Using the Control
`
`Point, a user may “enumerate (i.e., browse
`
`or search for) content items that are
`
`available for the user to render.” Id.
`
`(UPnP_000054-055). For example, using
`
`....-r'
`
`'
`'
`-.3
`55
`the Browse action, a Control Point
`
`1504:‘? - ‘_"_FA—’:;l-
`ri'i:¢~°irM mu
`
`mu,”
`
`obtains identification of and metadata about the various content items that are available on the
`
`Media Server, including properties such as name or artist, and this playlist is then displayed on
`
`185
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`the user interface (“U1”) of the Control Point. See in’. “The user interacts with the Control
`
`Point’s UI to locate and select the desired content on the Media Server and to select the target
`
`Media Rcnderer.” Id. (UPnP_UOD053).
`
`After a content item has been selected, the Control Point “initiates the transfer of the
`
`content" from the Media Server to the Media Renderer, which causes the Media Server to
`
`transfer the content directly to the Media Renderer using any compatible transfer protocol and
`
`data format. See id. (UPnP*000054, UPnP_000052, UI-"nP_000063). As shown above in Figure
`
`3, examples of such transfer protocols include a "‘push"’ by a Media Server or a “pull” by a Media
`
`Renderer.
`
`In’. (Fig. 3). When a “pull” protocol is used, the Control Point provides the Media
`
`Renderer with a string of characters, also known as a URI, that identifies the selected media item
`
`and the address of the device on the network from which the media item can be obtained.
`
`Id.
`
`(UPnP_00005 7') (“invoke the SetAVTransportURI() action to identify the content item that
`
`needs to be transferred"); Loy T1‘. 448-449, 450. The Media Renderer uses the URI that it
`
`received from the Control Point to request the item from the Media Server (e.g., using an
`
`HTTP-GET request), and the content item is streamed or otherwise transferred from the Media
`
`Server to the Media Renderer to be played. See id. (UPnP_000053, UPnP_0D0063).
`
`The Control Point may then operate as a remote control for the Media Renderer. For
`
`example, UPnl’ AV 1.0 states that a user may use the Control Point “to control how content is
`
`rendered (e.g., Brightness, Contrast, Volume, Mute, etc.).'“‘ In’. (UPnP_0O0055).
`
`Through his direct witness statement, Dr. Almeroth has provided evidence that UPnP AV
`
`1.0 anticipates asserted claims 1, 8, 16, 17, 19. 22, 23, 30, 37 and 45.5” See RX—046OC rows
`
`5" It is argued that UP11P AV 1.0 renders these claims obvious if the AL] adopts Respondents and
`Intervenor‘s proposed construction of “device identifier,” but that under all other proposed
`
`186
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`Almeroth) QXA 85-144. BHM"s expert, Dr. Loy, did not dispute that UPnP AV 1.0 discloses the
`
`majority of the limitations recited in these claims. See CX-1401C (Loy RWS) QIA 67-82. Dr.
`
`Loy disputes that UPnP AV 1.0 discloses the following limitations:
`
`0
`
`“displaying, on a first device, at least one device identifier identifying a second
`
`device” and “receiving user first input selecting the at least one device identifier“
`
`(claim 1, and similar “device identifier" limitations in other asserted claims);
`
`0
`
`“rec-eiving, on the first device, a playlist” and “selecting at least one media item
`
`identifier from the received playlist” (claim 1, and similar “playlist"" limitations in
`
`other asserted claims);
`
`0
`
`“requesting, by the second device, the song identified by the song identifier from
`
`a content server” (claim I 9); and
`
`0
`
`“directing the at least one second device to send information representative of the
`
`at least one media item name to a content server" (claim 23).
`
`See id. The disputed limitations are discussed below.
`
`UPnP AV 1.0 states that “[t]he user imeracts‘ 11-':’I'h the C.'onrroi Point '5 UI to locate and
`
`select the desired content on the Media Server and to select the target‘ Media Renderer."'
`
`RX-0140 (UPHP AV 1.0) (UPnP_000053) (emphases added). The ability to select a Media
`
`Renderer using the UI of the Control Point, which may take the form of a “wireless PDA-like
`
`device with a small display,” discloses to one of ordinary skill the display and selection of a
`
`device identifier on the Control Point. Ial; see RX-0460C (Almeroth DWS) QJA 92, 106.
`
`constructions for the agreed-upon and disputed terms, these claims are anticipated by UPnP AV
`1.0. See RX-0460C (Almeroth DWS) Q/A 95.
`
`187
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`Faced with this disclosure, Bl-lM'”s expert testified regarding a scenario in which a user
`
`might select a target Media Renderer using the Control Point’s U] in a manner that would not
`
`involve the display ofa device identifier on the Control Point. See CX-0l40lC ("Loy RWS) QIA
`
`"I0. Specifically, Dr. Loy discussed a hypothetical Control Point with a U1 that includes buttons
`
`that are each dedicated to a tenderer (e.g., a button with “TV” printed on
`
`it, and a button with “Stereo" printed on it), and wherein the selection of
`
`the Media Renderer takes place via the press ofa button. See r'd.;
`
`does not envision or discuss such a Control Point device, and Dr. Loy
`
`CDX-013213023 (Loy Demonstrative) (illustrated at right). UPnP AV 1.0
`
`does not point to real-world examples in which such a U1 has been
`
`implemented on a Control Point. Nevertheless, Dr. Loy"s hypothetical scenario would satisfy the
`
`claim limitation. In the case ofa Control Point that includes buttons that each identify a different
`
`renderer device, the buttons would literally display, on a first device, at least one device
`
`identifier identifying a second device and also may receive user input selecting the device
`
`identifier.
`
`BHM does not dispute that UPnP AV 1.0 discloses a ‘“playlist" under the adopted
`
`construction and that proposed by the Staff. BHM argues only that UPnP AV 1.0 does not
`
`disclose a “playlist"' under BHM’s construction, which defines the term as “a list referencing
`
`media items arranged to be played in a sequence."
`
`UPnP AV 1.0 states that “[t]he user interacts with the Control Point’s UI to locate and
`
`select the desired content on the Media Server.” RX-0140 (UPnP AV 1.0) (UPnP_00[}053)
`
`(emphasis added). The “Content Directory Service” permits the Control Point to identify,
`
`retrieve and display content items that are available on the Media Sewer for the user to play
`
`188
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`using a “Browse" or “Search” action. See id. (UPnP_00O054-055). The Media Server may store
`
`a variety of entertainment content, including music for playback on network-enabled speakers.
`
`See id. (UPnP_000053-054). Elsewhere, UPnP AV 1.0 discloses that the Control Point may
`
`receive playlists of content that are customized to the user’s preferences, such as “MyFavorite”
`
`music. RX-0140 (UPnP AV 1.0) (UPnP_000054).
`
`Using the methodology that Dr. Loy employed in his infringement analysis, UPnP AV
`
`1.0 discloses a "‘playlist"’ under BHM’s proposed construction. Sec RX-0460C (Almeroth DWS)
`
`QEA 98, 106; Almeroth Tr. 660-66].
`
`In particular, Dr. Loy identified the same UPIIP-based
`
`Content Directory “Browse” action, which retrieves an identification of and metadata about the
`
`available content items stored on the server, as evidence of infringement. See CX-1068C (Loy
`
`DWS) Q/A 260 (identifying the “plurality of media item identifiers representing songs available
`
`on the BHM-02 computer”), 272 (“mobile device makes a C‘.ontentDirectory request to the
`
`content sewer"). Accordingly, to the extent Dr. Loy opined that the “Browse” action and receipt
`
`of music content is evidence of infringement, that same operation is disclosed in UPnP AV 1.0.
`
`After a content item is selected at the Control Point, UPnP AV 1.0 discloses that the
`
`Control Point “initiates” the transfer of content from the Media Server to the Media Renderer.
`
`RX-0140 (UPnP_000054). The content may be transferred using a “pull” protocol, such as
`
`HTTP—GET. See id. (UPnP_O00063-065, Fig. 3). In this circumstance, the Control Point
`
`invokes the “SetAVTransportURI() action,” which causes the Control Point to send the Media
`
`Renderer a “URI” (tie. , a string of characters that identifies the selected content as well as the
`
`address of the device on the network from which that content can be obtained). See id.
`
`(UPnP_0U0057, UPnP_000063). UPnP AV 1.0 discloses that the Media Renderer uses the URI
`
`189
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`received from the Control Point to make a request to the Media Server for the selected content
`
`item. See id._: see also RX-0460C‘. (Almeroth DWS) QIA 100, 119, 130.
`
`Dr. Loy identified the same “SetAVTransportURI” action to establish that the accused
`
`DLN A-compliant video display devices request a media item from a content server- See
`
`CX-1068C (Loy DWS) Q/A 162, 205, 292; Loy Tr. 448-449, 450. Yet, with respect to a validity
`
`analysis, Dr. Loy disputes that the same operation in UPnP AV 1.0 performs the same function.
`
`As for the additional limitations recited in asserted claims 1, 8, 16, 17, 19, 22, 23, 30, 37,
`
`and 45 of the ‘S73 patent, Dr. Almeroth provided an element-by-element invalidity analysis for
`
`each of these asserted claims. See RX-0460C‘. (Almeroth DWS) Q/A 92-106 (claim 1), 109-1 10
`
`(claim 8), 111-113 (claim 16), 114-11'? (claim 17), 118-121 (claim 19), 122 (claim 22), 123-130
`
`(claim 23), 139-140 (claim 30), 142 (claim 37), 143 (claim 45).
`
`(1.
`
`UPnP Version 1.0 — Anticipation of Claims 1, 8, 16, 17, 19, 22,
`23, 30, 37, and 45
`
`The UPnP AV 1.0 reference, discussed above, is part of an inter-related collection of
`
`documents that Respondents argue are meant to be read together and comprise Version 1.0 of the
`
`UPnP AV Standard. See Resps. Br. at 85. This set of documents, r'.e., UPnP AV 1.0,
`
`MediaRenderer:l, ContentDirectory:1, and AVTransporl:1 (hereinafter, “UPnP Version 1.0"),
`
`provides additional details regarding the functionalities of the UPnP Control Point, Media
`
`Server, and Media Renderer. For example, the ContentDirectory:l Service Template defines the
`
`Content Directory Service, which allows UPnP devices to locate content stored on a Media
`
`Server, including songs, movies, and pictures. See RX-0142 (ContentDirectory:1)
`
`(UPnP_000I 6?). The AVTransport:1 Service Template defines a service for enabling “control
`
`over the transport of audio and video streams,” which may be used to control media devices such
`
`190
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`as CD players, VCRS and MP3 players. RX-0146 (_A\r’Transport:l) (UPnP_O00075). The UPnP
`
`MediaRenderer:l Device Template defines, among other things, identification information that a
`
`Media Renderer provides to the Control Point during the UPnP Di.s'cover_).= phase. See RX-0143
`
`(MediaRenderer:1') (UPnP__00026D).
`
`It is argued that the UPnP Version 1.0 documents should be treated as a single
`
`anticipatory prior art reference because they all were developed by the same UPnP AV working
`
`committee, relate to the same version of the UPnP AV Standard, were made publicly available
`
`by the UPnP Forum on the same day via the same web site, and share overlapping individual
`
`authors. Resps. Br. at 86 (citing JX-0081 (Murray Dep.) at 23-27, 27-28)- The UPnP AV 1.0
`
`document references the additional “UPnP AV Device and Service templates” in the
`
`Introduction, and discusses the Content Directory Service, the AV Transport Service, and the
`
`Media Renderer Device Template in Section 5. See RX—0140 (UPnP AV 1.0); see also RX-OUTS
`
`(Weast) at col. 1, Ins. 36-46; col. 2, lns. 44-56 (describing the UPnP AV Architecture Version
`
`1.0 specifications). The evidence demonstrates that persons of ordinary skill in the art, including
`
`engineers at Samsung, that make products that can operate as control points and renderers and
`
`that may be used with each other or with other manufacturer’s products, would look to the
`
`entirety of the disclosure to ensure that their products are complaint with the standards. Sec
`
`RX-0676C (Cho RWS) Q/A 23-27. UPnP AV 1.0 describes the overall architecture for the
`
`standard and cross—references the accompanying Device and Service Templates, while the
`
`ContentDirectory:1 Service Template, AVTransport:1 Service Template, and MediaRenderer:1
`
`19]
`
`BHM 2011B
`
`BHM 2011B
`
`

`
`PUBLIC VERSION
`
`Device Template each provide additional details regarding the features and protocols of the
`
`UPnP AV 1.0 specification.“
`
`Through his direct witness statement, Dr. Almeroth has provided evidence that UPnP
`
`Version