On April 12, 2010, Yahoo! filed counterclaims alleging patent infringement of two of its patents, U.S. Patent No. 7,512,622 (the '622 Patent) and U.S. Patent No. 7,640,320 (the '320 Patent). Before the Court is the task of construing certain terms used in the '622 and '320 Patents.

The asserted claims are claims 1-2, 4-5, 7-14, 16-18, and 20-23 of the '622 Patent and Claims 1-2, 4, 7-8, and 10 of the '320 Patent.

The parties have consented to the jurisdiction of a United States Magistrate Judge pursuant to 28 U.S.C. § 636(c).

II. OVERVIEW OF THE PATENTS AND CLAIMS

A. The '622 Patent

The invention disclosed in the '622 Patent is entitled "Method and Apparatus for Organizing and Playing Data." Yahoo!'s Opening Claim Construction Brief ("Yahoo! Br."), Declaration of Ryan Gilfoil ("Gilfoil Decl."), Ex. A ('622 Patent). It is designed to provide a general solution to problems that arise when users access media entertainment on their computers, "such as audio or video entertainment, occur[ing] via a network, such as the internet." '622 Patent at 1:24-26. The patent discloses a system and method, which includes an interface to present media files over a computer network, such as the internet, and maintains the user at a single site regardless of the source of the media content. Id. at 2:25-29. The interface allows the user to select and play a media file over a computer network by selecting a channel, a show and then an episode associated with the media file. In the claimed interface, certain information about media files, e.g., title, description, duration, are displayed in predetermined locations. The patent refers to this information about the media files as "metadata attributes." By displaying the metadata in a predetermined location, the interface has a consistent look and feel for the user, even if the media content has been provided to the user from different sources. Id. at 1:28-29. Further, because the user remains at the same site, regardless of the source of the media content, "differences in tiered membership may be tracked so that the user is only presented with content that the user is permitted to play." '622 Patent at 2:29-32.

The parties agree that "metadata attributes" and "metadata attribute types" mean "types of information that characterize a media file, e.g., the title, description, duration, and format of a media file. See Augme's Responsive Brief at 2, n.2 citing Docket No. 178, App. A at 1.

Asserted Claim 1 of the '622 Patent provides:

A method comprising: generating an interface at a site on a network for display on a user computer, a plurality of media files from a plurality of media file providers being made available to said user computer via said network using said interface;
defining a set of metadata attributes relating to said plurality of media files, each of said metadata attributes in the set having a respective predetermined location in said interface, said respective predetermined location for a given metadata attribute being a same location in said interface regardless of media file or media file provider;
compiling said plurality of media files for use with said interface, wherein said plurality of media files is compiled from a plurality of media file providers;
associating metadata attributes from the set of metadata attributes with each of said plurality of media files; and
mapping each of said associated metadata attributes to its respective predetermined location in said interface, so that in said interface for said user each of said associated metadata attributes appears at its respective predetermined same location in said interface for all of said media files and media file providers, wherein said interface comprises:

a channel description portion to display a plurality of channel selections corresponding to the plurality of media files by said user;

a show description portion to display one or more show selections, and in response to user selection of one of the channel selections said show description portion displays only those show selections corresponding to the channel selection;
an episode description portion to display one or more episode selections, and in response to user selection of one of the show selections said episode description portion displays only those episode selections corresponding to the show selection;
and
a viewer to view media file content at the user computer, the media file content corresponding to the channel, show and episode selections made by the user using the interface.

B. The '320 Patent

The '320 Patent provisional application was filed on January 18, 2001 and the patent issued on December 29, 2009. The '320 Patent is a "method and system for uploading, managing and delivering digital content, including streaming media." The '320 Patent asserts: "[w]ith the advent of the Internet and the World Wide Web, an industry has developed around the delivery of digital content, such as streaming media content." '320 Patent at 1:23-25.6. The specification discusses the need for the invention: (1) ". . .some content providers have hundreds, even thousands of content files," (2) storing and streaming a large number of content files can be costly, and (3) "streaming content requires a level of technical expertise often not found in companies focusing on creating content." Id. at 1:30-37. The "Background of the Invention" states that in order to solve these problems "content providers have turned to content management service providers to store and stream content on behalf of the content providers." Id. at 1:31-39.

The '320 Patent is attached as Exhibit B to the Declaration of Ryan P. Gilfoil (Dkt. No. 187).

The '320 Patent has two independent claims - Claims 1 and 7. In the claimed methods, digital content is uploaded from a content provider and stored in a "repository server." Claim 1 provides:

A method comprising: receiving, by an ingest server, digital content from a client;
storing, by a repository server, the digital content, the digital content having an associated server hostname and a filename;
assigning a unique identifier to the digital content, and associating the unique identifier, server hostname and filename;
providing the client with a link containing the unique identifier but not the server hostname and filename associated with the digital content's unique identifier;
receiving, by a playlist server, a request for the content, the request based on activation of the link, the request including the unique identifier but not the server hostname and filename associated with the digital content's unique identifier;
determining, by the playlist server, the server hostname and filename based on the unique identifier received with the request;
creating, by the playlist server, a redirector file, the redirector file including the server hostname and filename associated with the digital content's unique identifier, the redirector file is returned in response to the request.

Claim 7 provides:

A method of providing an end user access to digital content, the method comprising:
causing digital content to be stored, by a repository server, and a unique identifier to be assigned to the digital content, the digital content having a server hostname and a filename when stored, the unique identifier of the digital content being associated with the digital content's server hostname and filename;
receiving, by an ingest server, the unique identifier to the digital content but not the server hostname and filename associated with the digital content's unique identifier;
publishing a link for activation by the end user, the link including the unique identifier and filename associated with the digital content's unique identifier,
wherein activation of the link causes resolution of the unique identifier into the server hostname and the filename of the digital content, and causes the digital content to be provided to the end user, by a playlist server, based on the server hostname and filename of the digital content determined using the unique identifier.

The number of terms presented by the parties for construction is in dispute. Yahoo! addresses seven terms, four from the '622 Patent and three from the '320 Patent. Augme, however, responds that the parties identified four additional terms for construction by the Court: "compiling said plurality of media files" from the '622 Patent, and "repository server" and "receiving by an injest server, the unique identifier to the digital content," from the '320 Patent. Yahoo! argues that the additional terms included by Augme in its Responsive Brief do not require construction by the Court at all. Yahoo! proffers its proposed construction of these additional terms in its Reply Brief "in the event that the Court elects to construe them." Yahoo!'s Reply at 1, n. 1.

III. LEGAL STANDARDS

A. Claim Construction Standards

A determination of infringement is a two-step process. Wright Med. Tech., Inc. v. Osteonics Corp., 122 F.3d 1440, 1443 (Fed. Cir. 1997). The first step is claim construction, which is a question of law to be determined by the court. Id. The second step is an analysis of infringement, in which it must be determined whether a particular device infringes a properly construed claim. Id. This analysis is a question of fact. Id.

"It is a 'bedrock principle' of patent law that 'the claims of a patent define the invention to which the patentee is entitled the right to exclude.'" Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (quoting Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). Generally, claim terms are given the ordinary and customary meaning that would be ascribed to them by a person of ordinary skill in the field of the invention. Id. at 1313; see also Rexnord Corp. v. Laitram Corp., 274 F.3d 1336, 1342 (Fed. Cir. 2001) ("[U]nless compelled to do otherwise, a court will give a claim term the full range of its ordinary meaning as understood by an artisan of ordinary skill").

The most "significant source of the legally operative meaning of disputed claim language" is the intrinsic evidence of record, that is, the claims, the specification and the prosecution history. Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996). This is because "the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification." Phillips, 415 F.3d at 1313. In some cases, the specification may reveal a "special meaning" given by the inventor that differs from the meaning the term might otherwise possess. Id. at 1316; see also Irdeto Access, Inc. v. Echostar Satellite Corp., 383 F.3d 1295, 1300 (Fed. Cir. 2004) (holding that where a disputed claim term has "no previous meaning to those of ordinary skill in the art, its meaning, then, must be found elsewhere in the patent."). In such instances, "the inventor's lexicography governs." Phillips, 415 F.3d at 1316. Similarly, a specification may reveal "an intentional disclaimer, or disavowal, of claim scope by the inventor." Id.

"[T]he Federal Circuit has held that if commonly understood words are used, then the 'ordinary meaning of claim language as understood by a person of skill in the art may be readily apparent even to lay judges, and claim construction in such cases involves little more than the application of the widely accepted meaning of commonly understood words.'" Board of Trustees of Leland Stanford Jr. Univ. v. Roche Molecular Systems, Inc., 528 F. Supp. 2d 967, 976 (N.D. Cal. 2007) (quoting Phillips, 415 F.3d at 1314); see also United States Surgical Corp. v. Ethicon, Inc., 103 F.3d 1554, 1568 (Fed. Cir. 1997) (holding that "[c]laim construction is a matter of resolution of disputed meanings and technical scope, to clarify and when necessary to explain what the patentee covered by the claims, for use in the determination of infringement. It is not an obligatory exercise in redundancy."). Thus, in Board of Trustees of Leland Stanford Junior University v. Roche Molecular Systems, Inc., the court held that a claim term did not need construction where it was "neither unfamiliar to the jury, confusing to the jury, nor affected by the specification or prosecution history." 528 F. Supp. 2d at 976.

A person of ordinary skill in the art also looks to the prosecution history of a patent to understand how the patent applicant and the Patent Office understood the claim terms. Phillips, 415 F.3d at 1314. "The prosecution history limits the interpretation of claim terms so as to exclude any interpretation that was disclaimed during prosecution." Southwall Technologies, Inc. v. Cardinal IG Co., 54 F.3d 1570, 1576 (Fed. Cir. 1995).

While claims are to be construed in light of the specification, courts must be careful not to read limitations from the specification into the claim. Phillips, 415 F.3d at 1323. If a patent specification describes only a single embodiment, that does not mean the claims of the patent necessarily must be construed as limited to that embodiment. Id. Rather, it is to be understood that the purpose of the specification "[is] to teach and enable those of skill in the art to make and use the invention" and that sometimes, the best way to do that is to provide an example. Id. Similarly, the Federal Circuit has cautioned that "patent coverage is not necessarily limited to inventions that look like the ones in the figures," noting that taking such an approach to claim construction would amount to "import[ing] limitations onto the claim from the specification, which is fraught with danger." MBO Laboratories, Inc. v. Becton, Dickinson & Co., 474 F.3d 1323, 1333 (Fed. Cir. 2007).

Courts may also use extrinsic evidence in construing claim terms if it is necessary, so long as such evidence is not used to "enlarge, diminish, or vary the limitations in the claims." Markman, 52 F.3d at 980; see also Verve, LLC v. Crane Cams, Inc., 311 F.3d 1116, 1119 (Fed. Cir. 2002) ("Patent documents are written for persons familiar with the relevant field; the patentee is not required to include in the specification information readily understood by practitioners, lest every patent be required to be written as a comprehensive tutorial and treatise for the generalist, instead of a concise statement for persons in the field. Thus resolution of any ambiguity arising from the claims and specification may be aided by extrinsic evidence of usage and meaning of a term in the context of the invention."). As the court explained in Markman, "[extrinsic] evidence may be helpful to explain scientific principles, the meaning of technical terms, and terms of art that appear in the patent and prosecution history." 52 F.3d at 980. The Federal Circuit has warned, however, that such evidence is generally "less reliable than the patent and its prosecution history. . ." Phillips, 415 F.3d at 1318. Thus, courts are free to consult dictionaries and technical treatises so long as they are careful not to elevate them "to such prominence . . . that it focuses the inquiry on the abstract meaning of [the] words rather than on the meaning of the claim terms within the context of the patent." Phillips, 415 F.3d at 1321.

"A word or phrase used consistently throughout a claim should be interpreted consistently." Phonometrics, Inc. v. Northern Telecom Inc., 133 F.3d 1459, 1465 (Fed. Cir. 1998). On the other hand, where a claim term is used "in two contexts with a subtle but significant difference" the term "should not necessarily be interpreted to have the same meaning in both phrases." Epcon Gas Systems, Inc. v. Bauer Compressors, Inc., 279 F.3d 1022, 1031 (Fed. Cir. 2002).

B. Indefiniteness Standards

The requirement that claims be sufficiently "definite" is set forth in 35 U.S.C. § 112, ¶ 2, which provides that, "[t]he specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention." "The definiteness inquiry focuses on whether those skilled in the art would understand the scope of the claim when the claim is read in light of the rest of the specification." Union Pacific Resources Co. v. Chesapeake Energy Corp., 236 F.3d 684, 692 (Fed. Cir. 2001). In order to "accord respect to the statutory presumption of patent validity," a claim should be found indefinite "only if reasonable efforts at claim construction prove futile." Exxon Research and Engineering Co. v. United States, 265 F.3d 1371, 1375 (Fed. Cir. 2001). Thus, a claim is not indefinite simply because its meaning is not ascertainable from the face of the claims. Amgen, Inc. v. Hoechst Marion Roussel, Inc., 314 F.3d 1313, 1342 (Fed. Cir. 2003). Further, a claim is not indefinite simply because it covers "some embodiments that may be inoperable." Exxon Research and Engineering Co., 265 F.3d at 1382. A claim is indefinite, however, if it is "insolubly ambiguous, and no narrowing construction can properly be adopted." Amgen, 314 F.3d at 1342 (citations omitted).

IV. DISPUTED CLAIM TERMS

Consistent with Patent Local Rule 4-3 and the Court's Amended Case Management and Pretrial Order, the Court addresses the following claim terms below: 1) "viewer" 2) "media file providers" 3) "defining a set of metadata attributes" 4) "compiling said plurality of media files" and 5) "associating metadata attributes. . .plurality of media files" from the '622 Patent; and 6) "server hostname" 7) "redirector file" 8) "playlist server" 9) "repository server" and 10) "ingest server" from the '320 Patent.

A. Terms from the '622 Patent

1. "Viewer"

a. Arguments

The asserted claims of the '622 Patent recite a "viewer" that allows a user to "view media file content" on his or her computer. '622 Patent at 14:39-44. The parties agree that this term requires construction and that it refers to software that plays media files. The parties disagree as to whether a player that plays only audio meets the claims.

Yahoo! argues that the specification expressly embraces audio-only players and that the use of the word "viewer" in the patent does not limit the claims to video players. Yahoo! points out that the specification states that "[i]t is understood that the invention has equal application to audio media content as well." '622 Patent at 3:22-23 (emphasis added). The specification states that the invention allows the web surfer's computer to play "audio/video clip content." Yahoo! argues that the use of a slash in "audio/video" mean audio or video content not audio and visual content. Id. at 11:27-28. Yahoo! also notes that the specification describes the "Background Art" as including "web sites" of "radio networks" and websites that provide "audio program files." Id. at 1:26-31.

Yahoo! offers extrinsic evidence in support of its argument that skilled artisans "routinely used the word 'view' to mean experiencing audio content." Yahoo!'s expert Dr. Nutt opines that one of ordinary skill in the art would understand "viewing" to include experiencing audio content in addition to video content. Declaration of Gary Nutt ("Nutt Decl."), ¶¶ 2-3 (". . .a skilled artisan in the 2002-2003 timeframe would have concluded that the recited 'viewer' included an audio-only media file player in addition to a player that played video" and "[a] skilled artisan would have interpreted the word "viewer" as a term for a media file player generally, not as a term for only a media file player that could play video.").

Yahoo! includes by way of example a citation to U.S. Patent No. 7,908,630, filed January 23, 2002, which discloses a method for experiencing Internet content on a television. Gilfoil Decl., Ex. D at Abstract. According to the patentees, the invention allowed a user to "view the awdio-visual" content. Id. at Abstract, 2:33-35 (emphasis added).) "View," according to Yahoo!, could encompass listening to audio. Yahoo!'s other cited example, U.S. Patent No. 7,103,668, filed August 29, 2000, discloses a method for distributing multimedia. Gilfoil Decl., Ex. E at Abstract. The patentees similarly referred to "video and audio signals . . . streamed to remote viewers" and to "transferring video and/or audio data to viewers." Id. at Abstract, 4:3-6.

Finally, Yahoo! argues that the "viewer" must "appear on a webpage." Yahoo! Br. at 8. Yahoo! argues that its construction follows from the parties' agreement that the recited "interface" is generated at a 'website" (which consists of webpages). '622 Patent at, e.g., 14:3-6 ("interface" is "generat[ed]" "at a site on a network."); JCS App'x A (Ex. H) at 1 ("site on a network" means "website.").) Because the interface comprises the viewer per the claim language, Yahoo! argues, the viewer appears on a webpage of the website." Yahoo! Br. at 8.

Yahoo! also notes that its construction is consistent with Augme's initial proposal, which agreed that the viewer is contained within a webpage. Id. (citing Gilfoil Decl., Ex. C at Ex. A, '622 Patent constructions p. 10)

Augme responds ach claim requires :

a viewer to view media file content at the user computer, the media file content corresponding to the channel, show and episode selections made by the user using the interface.

'622 Patent at 14:40-43 (claims 1-13); 15:59-62 (claims 14-22); 16:57-60 (claim 23) (emphasis added). Thus, Augme argues, the "viewer" is "to view" media file content and is part of an interface that is "for display" on a user's computer. Augme Br. at 3. Augme argues that Yahoo!'s construction is "untenable on its face" because "[a]udio data is not viewed, it is heard. Similarly, audio-only data is not 'displayed' on a user computer, it is played over speakers." Id.

Augme argues that the '630 Patent and the '668 Patent do not concern purely audio content, but rather describe audio/visual content that clearly has a visual component. Augme Br. at 6. Thus, Augme argues, these patents do not support Yahoo!'s conclusion that "view"means experiencing audio-only data. Id.

In contrast, Augme asserts that the specification of the '620 Patent teaches that media file content is viewed in a region of the interface (region 102 in Fig. 4) that is displayed on the computer screen. Id. (citing '622 Patent at 4:38-39) ("The user can select one of the chapter selections for viewing in region 102 of the embodiment of the invention."). Further, in the specification "the media playing window 501" (which the patent alternatively calls the viewing window 501), is only a portion of the "player." Id. (citing '622 Patent at 7:49-54). Augme argues that only visual data is viewed in the "viewing window 501." Id.

Finally with respect to Yahoo!'s argument that the viewer is "required to appear on a webpage," Augme asserts that Yahoo!'s argument is an "unsupported leap of logic" from the agreement that the claims require "generating an interface at a site on a network for display on a user computer" to the conclusion that a web site consists only of web pages. Augme Br. at 6. Augme argues that the claim language is silent as to whether the interface, including the viewer, is displayed within a webpage, and further, that Yahoo! has provided no "basis to limit the claim to require the viewer to appear in a web page." Id.

Yahoo! responds that Augme conflates the "interface" the "viewer"and the "content." Yahoo! Reply at 3. Yahoo! argues that the claims say nothing about whether the content played via the viewer is also "displayed." Yahoo! argues that "an 'interface' or a 'viewer' may be 'displayed' on a computer screen and used to play audio that is not itself "displayed but rather heard through speakers. The WinAmp application, for example, displays a player application on the user's screen, but the content is played via speakers (and optionally displayed visually)." Id. (citing Br. Ex. F at 48 & Fig. 4.1, 128).

Finally, Yahoo! argues that Augme's argument ignores the parties' agreement that it is a "web site" that generat[es]" the interface "compris[ing]" the "viewer." Yahoo! argues that "by definition" a web site consists of one or more web pages. Reply at 4 (citing Augme Br. Ex. C at 564 ("Web page" means "an HTML file"). Yahoo! also points out that this definition is consistent with

Augme's original construction for the viewer as a "media file player embedded in a web page." Id. (citing Ex. C. At Ex. A, '622 patent constructions p. 10).

b. Analysis

The Court concludes the patents' use of the term "viewer" refers to a "media file player displayed on a web page, including media file players that play audio-only content."

The patent's use of the word "viewer" does not mean that the patentees intended to limit the claims to software that plays content that is seen. The specification clearly states that "[i]t is understood that the invention has equal application to audio media content as well." '622 Patent at 3:22-23 (emphasis added). There are repeated references in the patent specification of an audio-only player. '622 patent 4:33-34-5:41-43. The specification also teaches that the invention allows the end user's computer to play "audio/video clip content" using a slash to mean audio or video content. Id. at 11:27-28. Further, the "Background Art" is described as including "web sites" of "radio networks" and websites that provide "audio program files." Id. at 1:26-31; see also 5:42-43 ("'Audio' refers to an audio-only file"). The patent also discloses a "feed," or data file in which a media file provider supplies metadata for a media file (or "clip"). Id. at 4:52-67 (disclosing XML data file for supplying metadata), 5:21-23 (the data file is a "feed"). In this particular embodiment, the "feed" "is associated with a clip for viewing." Id. at 4:62-67 (emphasis added). The feed may include a parameter indicating whether a media file is "audio-only." Id. at 5:41-43. A skilled artisan would thus have understood that variants of "view" as used in the patent refer to experiencing media content, including via an audio-only player.

Moreover, although Augme is correct that the commonly-understood meaning of the term "viewer" or "to view" would suggest visual, rather than audio content, the meaning of a patent claim is judged not from the standpoint of an ordinary consumer. The court must determine what the words would mean to a person of ordinary skill in the art. Moreover, it is well established that a patentee can act as his or her own lexicographer and define a term contrary to its ordinary meaning. See USHIP Intellectual Properties, LLC. v. United States, 98 Fed. Cl. 396, 406-407 (Fed. Cir. 2011) ("a patentee can act as his own lexicographer to specifically define terms of a claim contrary to their ordinary meaning. . . the written description in such a case must clearly redefine a claim term 'so as to put a reasonable competitor or one reasonably skilled in the art on notice that the patentee intended to so redefine that claim term.'") (quoting Elekta Instrument S.A. v. O.U.R. Scientific Int'l., Inc., 214 F.3d 1302, 1307 (Fed. Cir. 2000), cert. denied, 529 U.S. 1066 (2000). At the outset of the specification, the patentee clearly states that the invention "has equal application to audio media content. . ." '622 Patent at 3:22-23. The unambiguous statement of the invention's applicability to audio-only content places one reasonably skilled in the art on notice that the term "viewer" should be read to mean that either, or both, audio and visual content may be communicated by the invention to the end user.

Augme's argument that the patentee's 2003 amendment of the term "player" to the term "viewer" means that audio-only data has necessarily been excluded from the definition is without merit. The original claims recited a "player" but Yahoo! amended its claims to require the interface displayed on the user computer to include "a viewer to view media file content at the user computer." Declaration of Gregory S. Bishop ("Bishop Decl."), Ex. A at YAH-0019647-662. Augme argues that Yahoo! seeks to "recapture the disclaimed subject matter by ignoring the plain meaning of 'to view' and 'display.'" Augme Br. at 4. The Court finds that Augme has not made a sufficient showing that such a disavowal occurred during prosecution. See Home Diagnostics, Inc. v. LifeScan, Inc., 381 F.3d 1352, 1357 (Fed. Cir. 2004). Augme's argument incorrectly assumes that a "viewer" necessarily excludes an audio-only player. The Court is not convinced that one can deduce from the patentee's 2003 amendment of the term "player" to the term "viewer" that audio-only data has necessarily been excluded. There is nothing in the applicants' remarks during prosecution of the patent to suggest that by using the term "viewer" the applicants intended to limit the claims to players that play video content. To conclude that the claims have been narrowed in this way would require an unmistakable disclaimer during patent prosecution, which did not occur here. Home Diagnostics, Inc., 381 F.3d at 1357 ("clear[] and unambiguous[] disavow[al]" required)).

Finally, with respect to the parties' dispute about the inclusion of the phrase "on a web page," the Court is persuaded by Yahoo!'s position. See '622 Patent at, e.g., 14:3-6 ("interface" is "generat[ed]" "at a site on a network."); Gilfoil Decl., Ex H, JCS App'x A at 1 (parties' agreement that "site on a network" means "website on a network.").

Accordingly, the Court construes "viewer" as "a media file player that is displayed on a web page, including media file players that play audio-only content."

2. "Media File Providers"

+----------------------------------------------------------------------------+ ¦ ¦Augme's Proposed ¦Yahoo!'s Proposed ¦ ¦Claim Term ¦ ¦ ¦ ¦ ¦Construction ¦Construction ¦ +--------------------------+------------------------+------------------------¦ ¦ ¦"Entities that provide ¦ ¦ ¦ ¦digital ¦ ¦ ¦ ¦ ¦ ¦ ¦Media file providers ¦audio or video files, ¦ ¦ ¦ ¦wherein ¦ ¦ ¦(Claims 1, 2, 4, 5, 7-14, ¦ ¦No construction; plain ¦ ¦16-18, ¦file is a named sequence¦meaning ¦ ¦ ¦of ¦ ¦ ¦20-23) ¦ ¦ ¦ ¦ ¦bits that is stored on a¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦persistent medium" ¦ ¦ +----------------------------------------------------------------------------+

a. Arguments

Yahoo! argues that the term "media file providers" is straightforward and can easily be understood by a lay jury, thus no construction of this term is necessary. If a construction is adopted, the main disagreement with Augme's proposed construction is whether the named sequence of bits must be stored on a persistent medium. Yahoo! Br. at 9-11.

Yahoo! argues that limiting files to bits "stored on a persistent medium" would improperly exclude the situation in which digital content is generated and provided to the patented system "live." - e.g., by an entity filming audio/video with a "webcam" or speaking into a microphone connected to an accused system over the Internet. Yahoo! Br. at 9. Yahoo! Argues that such an entity is providing a "file," and to exclude such a "file" from the definition would contradict the specification, which states that the invention may provide "live broadcast media." Yahoo! Br. at 10 (citing '622 Patent at 3:43-44). Yahoo also notes that: 1) the '320 patent refers to a redirector "file" which need not be stored on a persistent medium, and 2) dynamically-generated web pages are commonly referred to as "files" but are not stored on a persistent medium.

Augme argues the media files in one of the disclosed embodiments are stored in a database. Id. (citing '622 patent at 4:47-51, "One of the embodiments of the invention that makes this possible is that the data resides in a database on the web site of the invention. Unlike prior art schemes that link to external data sources, the present invention maintains data locally."). The media file providers provide media files using FTP (file transfer protocol). Id. at 7:28-30. Augme concludes that "the disclosed embodiment is covered by Augme's construction for media file providers." Id. at 8.

Augme disputes Yahoo!'s position, in reliance on Dr. Nutt's declaration, that the redirector file of the '320 patent is not stored on a persistent medium. Yahoo! Br. at 11. Dr. Nutt contends that the "web surfer's computer could receive the redirector file, read it, and subsequently discard it without ever saving it to a persistent medium." Nutt Decl., Dkt. No. 186-1, ¶10. He then states that a "skilled artisan would still have referred to the redirector file as a 'file' as did the '320 Patent patentees." Id. at ¶11. Augme argues that Dr. Nutt's argument flawed because the statements are speculative and are based upon the assumption that Yahoo!'s definition of "file" is correct.

Augme also argues that Yahoo!'s reliance on dynamic generation of webpages in support of its construction of "file" is misleading. Yahoo! relies on U.S. Patent No. 6,311,194 to support its contention that a dynamic webpage is also referred to as a "file," stating that the '194 patent "refer[s] to webpage as an 'HTML file.'" Yahoo! Br. at 10-11. Augme argues that the cited reference does not use the term "webpage," or even refer to a web page as an HTML file. See Gilfoil Decl., Ex. J at 13:4-5 ("In this diagram [Fig.10], an extractor applies its extraction rules to an incoming HTML file."). Augme contends that "[t]hose skilled in the art recognize that a web page is not an HTML file, but a web page is generated when a browser executes an HTML file." Augme Br. at 9; Bhattacharjee Decl. ¶19. When used in the generation of a web page, HTML files are typically stored on persistent media on a web server and sent to a browser on request to generate the web page. Id. According to Augme, the '194 patent simply does not support Yahoo!'s construction.

b. Analysis

Neither party disputes that a "medial file provider" is an entity that provides media files. The parties also do not dispute that a "file" is a named sequence of bits. The parties' disagreement centers on whether the named sequence of bits must be stored on a persistent medium.

The Court concludes that the term should be construed as "entities that provide named digital or audio sequences of bits." This construction makes sense in the context of the claims and conforms to the specification.

Although Yahoo! offers no construction of this term, the Court notes that in its brief Yahoo!'s objection to Augme's proposed construction of "media file providers" is limited to Augme's definition of the term "file." Yahoo! apparently has no disagreement with the term "a named sequence of bits."

First, the definition of "file" is not limited to data that has been previously stored on a persistent medium, such as a hard drive. Augme's contrary construction would exclude live broadcast media and contradict the specification, which clearly states that the invention may provide "live broadcast media." '622 Patent at 3:43-44. If the Court were to construe the term as proposed by Augme, the claim would be improperly limited to the "pre-recorded media" embodiment from the specification. See Verizon Services Corp. v. Vonage Holdings Corp., 503 F.3d 1295, 1305 (Fed. Cir. 2007) (court should "not interpret claim terms in a way that excludes disclosed examples in the specification.").

One of ordinary skill in the art would have understood that live media could be delivered to the invention as a stream of bits in realtime and would not need to be stored on a hard drive before it was received by the invention. See, Nutt Decl., ¶12. Moreover, a person of ordinary skill would understand that files may be stored in Random Access Memory ("RAM"). Augme's construction excludes such storage: Augme's claim construction expert, Dr. Bhattacharjee, testified that a "persistent medium" is a "medium that will withstand a power cycle," such as a "hard drive." See Ex. G at 69:3-12. RAM, on the other hand, is a storage medium that is "volatile," i.e., it only retains data as long as it has power. See "Microsoft Computer Dictionary" (Ex. I at 437, 558). Dr. Bhattacharjee agreed that "random access memory" is not a persistent medium. Yahoo! Br. at 9-10 (citing Ex. G at 69:3-70:4).

The extrinsic evidence cited by Yahoo! supports its construction. Yahoo! has proffered evidence dynamic generation of webpages was commonplace in the 2003 time frame. A visitor to a finance website might, for instance, select a webpage with information about Yahoo! stock, such as its current price. See Nutt Decl. ¶5. The page would not typically be pre-stored on the website computers, because that could require pre-storing thousands or millions of webpages (e.g., one for each stock), and stock prices frequently change. Id. ¶6. Instead, the website would dynamically generate the webpage for each stock as it was requested. Id. ¶7; see also U.S. Patent No. 6,311,194 (Ex. J) at 1:67-2:3 (cited in '622 Patent file history) ("Web pages may be generated dynamically by a server"). Although the web page might not be stored on the hard drive of either the website or the web surfer, a skilled artisan would have understood that the webpage is still a "file." Id. (citing Nutt Decl. ¶8; Ex. J at 1:67-2:3, 13:4-5 (teaching dynamic webpage generation and referring to webpage as an "HTML file")); see also Home Diagnostics, 381 F.3d at 1358 (construing term consistently with usage in prior art of record).

The '320 patent also demonstrates that Augme's construction of the term "file" is too narrow. That patent discloses "dynamically generat[ing] a redirector file" and providing it to the end user. '320 patent at 18:5-7. The patentees used the word "file" even though there is nothing in the '320 Patent that requires storage of the redirector file in a persistent medium. See Nutt Decl. ¶¶9-11. The Court notes that Augme's proposed construction of "redirector file" does not include the narrow definition of "file" that Augme seeks in connection with the '622 Patent (Ex. H at Item 11); yet there is nothing in the specification or claims to suggest that "file" has a special meaning in the '622 patent.

The Court concludes that the term "media file providers" should be construed as "entities that provide named digital or audio sequences of bits."

3. "Defining a set of metadata attributes" and "defining a set of metadata attribute types"

a. Arguments

The asserted claims of the '622 Patent required "defining a set of metadata attributes relating to said plurality of media files. . ." '622 Patent at 14:7-8. The parties agree that the terms "defining a set of metadata attributes" and "defining a set of metadata attribute types" should be construed in the same way. Yahoo! Br. at 11. The parties further agree that "metadata attributes" (or "metadata attribute types") are types of information that characterize media files, such as "airtime" "description" or "duration." The "values" for those metadata attributes are the specific information that populates those attributes, such as "48 minutes" (the value for the metadata attribute "airtime") or "Seinfeld, the Puffy Shirt Episode" (the value for the metadata attribute "description") or "32 minutes (the value for the metadata attribute of the show's duration). While the parties agree that "defining" is related to storage of the metadata, they disagree whether defining: 1) is limited to constructing an XML data store template (Augme), or 2) more broadly encompasses configuring a database to store the metadata (Yahoo!).

Yahoo!'s construction has two parts. First, Yahoo!'s construction specifies that the invention uses a database that is part of the website that generates the interface. The specification states that a "database on the web site of the invention," which "makes [the invention] possible." Yahoo! Br. at 12 (citing '622 Patent at 4:47-49 (emphasis added). The specification also refers to the "present invention" as including a "local database." Id. at 9:3-5.

Second, Yahoo! argues that its construction clarifies that "defining" the metadata attributes means configuring the database to store values for the metadata attributes. Yahoo! Br. at 12. The specification discloses that a media file provider supplies metadata information for a particular media file via a "feed." '622 Patent at 7:28-33 (media file provider can supply a "feed document[]" containing "metadata"). For example, a feed for a particular media file may contain "airtime" and "description" elements that represent metadata attributes. Id. at 6:3-7, 6:64-67 (disclosing "airtime" and "description" elements of "feed"). The feed also contains values for these (and other) metadata attributes specific to the media file, such as the media file's airtime and description. E.g., id. at 5:35-36 (feed document contains "values"), 7:1-4 (feed contains "values" for metadata attributes). These data values are "stored" in "the database." Id. at 7:38-42 (disclosing setting value for "expiration time" metadata field in the database and media files "inherit[ing]" values for "metadata attributes" within the database), 4:52-59 ("metadata" "is stored" in "the database"), 9:3-5 ("metadata" is "include[d]" in "database"). Yahoo! argues that "[a] skilled artisan would thus have understood that "defining" the metadata attributes would mean configuring the database to store the values for the metadata attributes that the system would accept. The values for the metadata attributes could then be supplied via a feed and saved in the database." Yahoo! Br. at 12.

Yahoo! further argues that "Augme effectively admits that 'defining a set of metadata attributes' refers to configuring a database to store values for metadata attributes." Id. Specifically, Augme's construction recites "constructing" a "template" for a "data store." Id. Yahoo! points out that a "template" is a way of defining the contents of a data structure, while a "data store" is simply a more general term, which includes a database. Id. (citing Nutt Decl. ¶¶15-16). Yahoo! argues further that Augme's expert, Dr. Bhattacharjee, conceded that a database "schema" - that is, a file that sets forth the configuration of a database - is one type of data store template. Id. (citing Ex. G at 98:13-19). Thus, Yahoo! argues, by "constructing" a "template" for a "data store," one is in fact configuring that data store (e.g., database) with respect to the data that it will store. Id. at 13.

Yahoo! argues further that Augme's construction is "overly narrow and confusing." Id. In particular, Yahoo! takes issue with Augme's narrow requirement that the metadata be defined in an XML format. Id. Yahoo! contends that Augme improperly reads a limitation from a preferred embodiment in the specification. "[T]he specification is explicit that the invention uses 'an XML template' '[i]n one embodiment.' Id. (citing '622 Patent at 4:54-55; id. at 9:5-7 (database may store data in "XML" format or "any suitable form" (emphasis added)). Yahoo! argues that the Federal Circuit has cautioned repeatedly against reading particular embodiments into the claims. Id. (citing Comark Commc'ns, Inc. v. Harris Corp., 156 F.3d 1182, 1186-87 (Fed. Cir. 1998) ("'[P]articular embodiments and examples appearing in the specification will not generally be read into the claims.'" (quoting Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1572 (Fed. Cir. 1988)).

Augme responds that its proposed construction is supported by the specification. Augme Br. at 10. In particular, "the specification specifically identifies the XML data store template as the essence of its invention." Id. The specification states that the "present invention is able to customize content presentation because of the data structure of the database used for the local data storage." '622 patent at 4:52-53 (emphasis added). It describes only one way to define metadata attributes, through the XML template, which it contends is "unique to the present invention." Id. at 4:52-55. It explains that this XML template is what makes "a consistent interface and experience possible." Id. at 4:55-58. The patent shows an embodiment of the XML template. Id. at 5:1-7:23.

In response to Yahoo!'s argument that the XML template is only one embodiment of the invention, Augme responds that the specification is clear that the other embodiments are XML templates, with different metadata attributes defined. Id. at 4:62-67 ("The template below is an example of one embodiment of an XML datastore template used in the present invention. . . . It should be noted that items are not required to have all elements listed."). Nowhere does it teach or suggest any alternative to the "XML template unique to the present invention." Id. at 4:52-55. Augme argues that Yahoo!'s reliance on column 9, lines 5-7 is incorrect because Yahoo! quotes this passage out of context. In context, the passage reads as follows:

The present invention includes additional information in a local database in addition to the metadata provided by a content provider. This information can also be XML metadata or it can be associated attributes of the database in any suitable form. This data includes subscription information such as active/inactive, and level of subscription (e.g., regular, premium, package, etc.).

'622 patent at 9:3-9 (emphasis added). According to Augme, the additional information here is not "relating to said plurality of media files" as required in the asserted claims. Augme Br. at 10. Thus, Augme argues, it is "irrelevant" that this additional information may be stored in "any suitable form." Id. Augme maintains that "the only suitable form for the metadata attributes related to the media files is the XML datastore format the inventors touted as unique to their invention." Id.

b. Analysis

The Court agrees with the definition proposed by Yahoo! with a slight modification.

First, it appears that the parties agree that a database is used to store the metadata. The Court is not persuaded by Augme's argument that the use of "data store template" is required (or helpful). This construction introduces additional terms ("XML" and "data store template") that are beyond the ken of a lay jury and would require further construction. The term "database" is commonly understood.

Second, the claims do not require that metadata attributes be stored using an XML template as advanced by Augme. Augme's reliance on column 4, lines 52-58 of the '622 patent is misplaced because that reference, by its terms, is only to "one embodiment. . ." The Court declines to graft a limitation from one embodiment onto the patent claims. The Court is similarly unpersuaded by Augme's citation to the portions of the specification that discuss the XML template as "unique to the present invention" or is "used in the present invention." These references do not establish what the claims actually require.

Finally, the reference in the specification to association of information with the database "in any suitable form" is dispositive. Augme argues that the "additional information" that can be associated "in any suitable form" has nothing to do with "said plurality of media files." Id. However, the Court agrees with Yahoo! that the information is metadata that is associated with media files. Yahoo! Reply at 6 (citing '622 Patent at 4:40-44).

Accordingly, the Court construes the term "defining a set of metadata attributes" or "defining a set of metadata attribute types" as "configuring a database to store values for the metadata attributes."

4. "Associating Metadata attributes from the set of metadata attributes with each of said plurality of media files"

+-----------------------------------------------------------------------------+ ¦ ¦Augme's Proposed ¦Yahoo!'s Proposed ¦ ¦Claim Term ¦ ¦ ¦ ¦ ¦Construction ¦Construction ¦ +-------------------------+----------------------------+----------------------¦ ¦ ¦Plain meaning of ¦ ¦ ¦ ¦"associating" ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦If the Court believes ¦ ¦ ¦"Associating Metadata ¦ ¦ ¦ ¦ ¦construction is necessary, ¦ ¦ ¦attributes from the set ¦ ¦ ¦ ¦of ¦Augme proposes: ¦ ¦ ¦ ¦ ¦Plain meaning ¦ ¦metadata attributes with ¦"to join or connect together¦ ¦ ¦each ¦ ¦ ¦ ¦ ¦metadata attributes from the¦ ¦ ¦of said plurality of ¦ ¦ ¦ ¦media files" ¦set of metadata attributes ¦ ¦ ¦ ¦with ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦each of said plurality of ¦ ¦ ¦ ¦media files" ¦ ¦ +-----------------------------------------------------------------------------¦ ¦The parties agree that no construction of this term is required. The court ¦ ¦therefore finds that no construction is necessary beyond plain meaning in ¦ ¦light of the agreed construction for "metadata attributes." ¦ ¦ ¦ ¦5. "Compiling said plurality of media files" ¦ +-----------------------------------------------------------------------------¦ ¦ ¦Augme's Proposed ¦Yahoo!'s Proposed ¦ ¦Claim Term ¦ ¦ ¦ ¦ ¦Construction ¦Construction ¦ +-------------------------+----------------------------+----------------------¦ ¦ ¦"gathering or putting ¦ ¦ ¦ ¦together ¦ ¦ ¦"compiling said plurality¦ ¦Not construed by ¦ ¦of ¦into a corpus or other ¦Yahoo! in its ¦ ¦ ¦ ¦ ¦ ¦media files" ¦collection the plurality of ¦Opening Brief. ¦ ¦ ¦ ¦ ¦ ¦ ¦media files" ¦ ¦ +-----------------------------------------------------------------------------+

Augme advances a construction of this term, which is not addressed in Yahoo!'s opening brief. In its Reply Brief, however, Yahoo! states that it has no objection to Augme's proposed definition. Yahoo! Reply at 15.

CONSTRUCTION OF '320 PATENT DISPUTED TERMS

6. "Server Hostname"

a. Arguments

Yahoo! argues that the concept of a "server hostname" is well within the understanding of a lay jury and thus, the term should not be construed. Yahoo! challenges Augme's proposed construction on several grounds. First, Yahoo! argues that Augme improperly seeks to limit the claims by its proposal that would require the server hostname to identify a server "in a content management system." The phrase "content management system" does not appear in the claims, nor would it assist the jury. Rather, the addition of the phrase "content management system" would complicate the jury's infringement analysis because the jury would not only have to decide whether the accused systems perform the recited steps, but also whether the accused systems are of a particular type. Augme's proposed construction does not provide guidance as to the meaning of "content management system."

Yahoo! next argues that the "content management system" limitation is improper because the claims recite methods, not systems. "The inventors chose to define their invention by what it does, not by what it is." Yahoo! Br. at 15. Therefore, Yahoo! argues that Augme's proposal improperly imports structural limitations into a method claim. Id. (citing Epcon Gas Sys., Inc. v. Bauer Compressors, Inc., 279 F.3d 1022, 1032 (Fed. Cir. 2002) ("The method of claim 2 does not mention structure by which the "venting" is to be performed. Thus, Epcon is correct that the district court improperly imported language from the specification into the claim.").

Yahoo! argues that Augme's inclusion of the "particular media server" limitation is similarly incorrect because the claims do not require the server hostname to identify the "particular media server . . . from which digital content is served." Yahoo Br. at 15. Yahoo! also argues that the specification discloses an embodiment in which the server hostname is the hostname of a storage server, not the server that delivers the content.

Augme responds that Claims 1 and 7 of the '320 patent require that the digital content itself have an "associated server hostname and filename." Augme argues that "server hostname" must be construed, because otherwise it will be unclear to the jury "which of the many servers described in the patent is the one to which this claim term refers." Augme Br. at 15. Augme argues that its proposed construction clarifies that "server hostname" refers to the particular media server in the content management system from which the digital content is served to an end user. Id.

Augme argues that Yahoo!'s contention that it is improper to identify the network as a content management system fails for two reasons: First, the specification states that the "need" met by the claimed invention is for "a content management system that allows clients to easily up-load, manage, and deliver streaming media content via the Internet." '320 patent at 1:47-54. Thus, although the claims themselves do not use the term "content management system," Augme argues that "the entirety of the '320 patent is directed to the architecture of what the patentees call a 'content management system.'" Augme Br. at 16. Augme argues that its construction is necessary so that the jury will be able to differentiate between three separate entities in the patent - the client (who is the content provider), the end-user (who accesses the content), and the service provider's content management system (the system to which content is uploaded and from which content is served). Id. (citing '320 Patent at 4:12-16). Augme argues that its construction is needed to clarify that the "server hostname" refers to the server on the content management system, not the client's system or the end-user's system. Id.

Second, Augme argues that the patentees amended the claims to require a specific structure for performing the method steps - e.g., "ingest server," "repository server," "playlist server." Bishop Decl., Ex. E at YAH-0019201-02. The labels "ingest server," "repository server," and "playlist server," are labels that the patentees give to different servers. See, e.g., '320 patent at Figs. 1, 4a-4b, 2:24-26, 3:34-38, 3:53, 4:12-15. According to Augme's expert, "outside the context of the disclosed content management system, these terms have no meaning." Augme Br. at 16 (citing Bhattacharjee Decl. ¶28). Furthermore, claim 1 explicitly differentiates between the content management system and the client. For example, the client provides the digital content to the content management system ("receiving, by an ingest server, digital content from a client").

Augme disputes Yahoo!'s assertion that the patent discloses an alternative embodiment in which the digital content's "server hostname" is the hostname of the storage server (and not the server that delivers the content). Augme argues that this interpretation is incorrect for two reasons. First, the patent includes two alternative "architectures" for a content management system - one that uses repository servers, and one that uses "storage servers." Compare '320 patent Figs. 1 & 6. When storage servers are used, no back-up of digital content is maintained, and content is not stored on the media server. See '320 patent at 18:35-55. The alternative "storage server" architecture is not covered by the asserted claims as the claims explicitly require "repository servers." Augme therefore concludes that "[t]he 'server hostname' of Claim 7, therefore, cannot be the hostname of a storage server.'" Augme Br. at 18.

Augme also argues that claims covering "storage server" embodiments were restricted from the '320 Patent. Augme Br. at 18-19. During prosecution of the patent, the original claims included embodiments that used "storage servers." See Ex. E at YAH-0019570-71 (claims 12-18, 30) ("A system for managing digital content and provide digital content to end users, the system comprising. . . one or more storage servers configured to store digital content received by the first servers.") (emphasis added). Augme interprets the restriction requirements issued by the examiner to mean that the patent office had concluded that the storage server embodiments were different inventions from those claimed in claims 1-11, which eventually issued in the '320 patent. Id. at YAH-0019239, 19307. In responding to the restriction requirement, the patentees elected to prosecute claims 1-11. Id. at YAH-0019233, 19299-300. Thus, according to Augme, the patentees "discontinued prosecution of claims covering the 'storage server' embodiment." Augme Br. at 19.

Finally, Augme argues that even if Claim 7 recited the use of "storage servers" the claimed "server hostname" would still be the network name of a media server. Id. When a storage server is used (and the content is stored on the storage servers, not on the media servers), the digital content's filename is its "filename as stored on the storage server." '320 patent at 25:44-48. The hostname, however, is the hostname of the media server that will deliver the content. Id. at 25:49-26:5, 26:20-23 ("Once the media server hostname is determined, the component on the playlist server 620 obtains the filepath prefix from the record in the Stream-Servers Table 830 corresponding to the relevant stream id and hostname.")

Yahoo! responds that Augme's reliance on the Examiner's restriction to argue that Claim 7 does not encompass the "storage server"embodiment is misplaced. Yahoo! argues that in raising the restriction requirement, the patent examiner was distinguishing between two types of functionality -the method for resolving a unique identifier to the server hostname and filename (claims 1-11 and 28-34) and a more general system for managing digital content (original claims 12-18). Yahoo! Reply at 9. The Examiner was not, as Augme argues, distinguishing between the presence or absence of a "storage server." Id. Yahoo! points out that original claim 30 confirms this because it recited a "storage server' and the Examiner included this claim in the restriction requirement with Claim 7. Id. at YAH19307, YAH19374-75. Thus, Yahoo! argues, the disclosed "storage server" embodiment and Claim 7 are "not mutually exclusive." Yahoo! Reply at 9.

b. Analysis

The Court is not persuaded by Augme's inclusion of the limiting phrase "in a content management system." Although Augme is correct that the specification refers to the invention as a method and system for managing content, the Court finds no such limitation in this claim term.

First, the claims make no mention of a "content management system." Although such a system is referred to in the background of the invention section of the specification, this phrase is not used in the claims and would only complicate matters as the additional phrase would itself need to be defined for the jury. Moreover, the specification describes the whole invention as a "content management system," thus to insert these words into the claims would be redundant. Further, the Court is unpersuaded by Augme's argument that such a construction is necessary in order to "differentiate the content management system from the client" or "end user." Augme Br. at 16. Because the claims make this distinction by reciting steps performed by the system and the role of the client and end user, further differentiation is not required.

Second, "server hostname" is not limited to the server that delivers or serves the content to the end-user because the specification describes an embodiment in which the "server hostname" may refer to a "storage server" (not the server that delivers the content). Augme's argument that that Claim 7 cannot cover this embodiment because the claim uses the phrase "repository server" not "storage server" is without merit. The "storage server" and "repository server" embodiments are not mutually exclusive. The specification explains only that the "storage server" embodiment does not require a "repository server for maintaining a backup." '320 Patent at 18:43-48 (emphasis added). Elsewhere, however, the specification explains that the repository server performs other functions that may relate to the "storage server" embodiment, such as receiving and storing uploaded digital content. Yahoo! Reply at 9 (citing '320 patent, 9:32-35 ("[C]lient 102 is able to . . . upload the file to a repository server.").

The term "media server" is not recited in the claims at all. Rather, the claims recite digital content with "a[n associated] server hostname." '320 Patent at 27:42-44, 28:24-29). In Claim 1, the hostname is included in a "redirector file" that is returned to the web surfer's computer. In one embodiment, after reading the redirector file, the web surfer's computer sends a request to the server identified by the server hostname to obtain the digital content. Id. at 18:23-26. In Claim 7, the digital content is provided to the web surfer "based on" the server hostname. Neither of the asserted claims requires that the server hostname identify a "media server" or that digital content be served "from" that particular server.

The use of "media server" is also contrary to the specification and Claim 7. In that claim the digital content is provided "based on" the server hostname. Yahoo! Br. at 15. The specification discloses an embodiment of this limitation, in which digital content is not stored on a media server, but rather, on a "storage server." Id. (citing '320 Patent, 18:43-52, 25:44-47). When a request is made using the "unique identifier," the playlist server "resolves the unique identifier to the storage server hostname." Id. at 25:44-51.

Augme contends that "the prosecution history makes clear that it is the "digital content" itself that has an associated 'server hostname.'" Augme Br. at 17. As originally drafted, claims 1 and 7 required storing the digital content "on a server having a hostname." Bishop Decl., Ex. E at YAH-0019244-45. Augme argues that the examiner rejected the claims as indefinite because "As per claim 1, it is not clearly understood who performs 'creating a redirector file' and what the purpose is for creating such redirect file." Id. at YAH-0019226. In response, the patentees amended the claims to recite that it is the digital content itself, not the server on which the digital content is stored, that has an associated hostname. Id. at YAH-0019213. Augme also points to an embodiment in the specification where the "server hostname" associated with digital content itself is the hostname of the media server that serves the content:

The CM Database also includes a Stream-Servers Table 230. The records in the Stream-Servers-Table 230 correlate each file, as identified by its stream ID, with the hostname (or domain name server (DNS) address) of the streaming server 120 on which it resides.

Augme Br. at 18 (citing '320 Patent at 7:16-20; see also id. at 17:62-65 (same)). In addition, Augme argues that in the Remarks that accompanied the patentees' amendments, they refer to the digital content's "server hostname" as a server that serves the content:

Upon activation of the link, a server, e.g., a playlist server, uses the unique identifier to identify the digital content's server hostname and filename, and creates a redirector file, which contains a reference to the server hostname, e.g. a server to serve the content, and the filename of the content that is to be served.

Bishop Decl., Ex. E at YAH-0019216 (emphasis added).

Neither the cited portions of the specification nor the prosecution history are sufficient to import these limitations into the claims. The patentee did not purport to restrict the term "server hostname" to servers that serve the content. The cited portions of the specifications are not exclusive descriptions of the invention. They are examples.

Although the Court disagrees with Augme's proposed construction of this term, it is not persuaded by Yahoo!'s argument that "server hostname" requires no construction at all. A jury would have difficulty understanding what a "server hostname" is without any definition.

Accordingly, the Court construes the term "server hostname" as "network name of a server."

7. "Playlist Server"

a. Arguments

In its opening Brief, Yahoo! notes first that the "playlist server" plays a similar role in the '320 patent's two independent claims. Yahoo! Br. at 16. In Claim 1, the playlist server "receiv[es] . . . a request" for digital content from the web surfer's computer. Id. (citing '320 Patent at 27:51-28:3. The playlist server "creat[es] . . . a redirector file" and "return[s]" that file to the end user's computer. Id. at 28:7-10. The end user's computer uses the redirector file to obtain the digital content. Id. at 18:23-26. Similarly, in Claim 7, the playlist server "causes the digital content to be provided to the end user." Id. at 17 (citing '320 Patent 28:37-42). The role of the "playlist server" in both Claim 1 and Claim 7 is to cause digital content to be provided to the end user. Id. at 17. Yahoo! argues that its proposed construction, "server(s) that causes digital content to be provided to the end user," clarifies this for a lay jury that may be unfamiliar with the term "playlist server." Id.

Yahoo! argues that Augme's proposed construction replaces two words with narrowing limitations that are not supported by the claims or the specification. Yahoo! Br. at 17.

Yahoo! also argues that Augme again attempts to rewrite these method claims, turning them into system claims by requiring the accused system to be a "content management system." Id. For the same reasons discussed with respect to the term "server hostname" Yahoo! asserts that this is improper. With respect to Augme's attempt to limit the claim language to "a specific media server" (and as argued previously with respect to the term "server hostname"), Claim 7 and the specification disclose an embodiment in which the requested digital content is stored on a storage server, not a media server. Id. (citing '320 Patent at 18:43-52, 25:44-47). Yahoo! contends that in that embodiment, the playlist server causes the digital content to be provided to the end user "based on" the "server hostname" of the storage server. The playlist server is not required to select a "specific media server" or any media server for that matter. Id.

Finally, Yahoo! argues that Augme's "distinct server" limitation is not consistent with the specification and is a "tacked on word" which appears nowhere in the '320 Patent. Id. In any event, Yahoo! argues that Augme's construction is incorrect "because the specification is clear that the playlist server need not be a standalone computer:"

In general, the division of functionality among the web server 110, file management server 112, playlist server 122 and script processor 116 described herein is exemplary, as the functions may be segregated and grouped differently. For example, it is to be understood that although the present embodiment utilizes client web servers 110 that are separate from the playlist server 122, in alternate embodiments the functionality of the playlist server 122 described herein may be implemented in software residing on the web server 110, thereby obviating the need for a separate playlist server ."

'320 Patent at 4:24-33 (emphasis added). Yahoo! Br. at 18-19. Yahoo! interprets the quoted language to mean that "far from contemplating a 'distinct'or separate playlist server, the patentees plainly stated that a playlist server could simply be a software program running on a computer that performed other tasks, such as serving web pages." Yahoo! Br. at 19.

In response, Augme makes several arguments in support of its proposed construction that a "playlist server" is a "distinct server in a content management system that determines the specific media server from which the requested digital content will be served."

First, Augme insists that the servers claimed in the '320 Patent - the ingest server, the repository server, and the playlist server are "distinct" from one another. Augme Br. at 21 (citing Bishop Decl., Ex. B, excerpt of deposition of Dr. Nutt at 103:19-104:8; 107:4-12). Augme argues that in order to gain allowance of the claims, the patentees agreed to an examiner's amendment that specified the server responsible for performing certain steps. Id. (citing Bishop Decl., Ex. E at YAH-0019201-02 (inserting "by an ingest server" and "by a repository server" in claims 1 and 7)). Because the claims include three different labeled servers, this confirms that the claimed servers are distinct from one another. Id. (citing Free Motion Fitness, Inc. v. Cybex Int'l, Inc., 423 F.3d 1343, 1348 (Fed. Cir. 2005)). Augme points out that although Yahoo! claims that Augme's assertion that the claimed servers must be distinct is unclear, Yahoo!'s own expert, Dr. Nutt, confirmed that the servers are distinct. He testified: "So the way I interpreted the patent when I read it is, is that the -the ingest server was defined to be distinct, being a distinct unit of computation from the repository server." Ex. B at 103:19-104:8. Dr. Nutt also testified that each server uses distinct memory. Id. (citing Bishop Decl., Ex. B at 104:9-18). Augme thus maintains that the playlist server is a "distinct server" and must be defined as such.

Second, Augme argues that the playlist server is the server in the content management system that "dynamically generates a playlist metafile [i.e., redirector file] . . . to be provided to the end user's windows media player." Augme Br. at 22 (citing '320 Patent at 4:3-7). When the end user clicks on the playlist link, the playlist server "retrieve[s] the data necessary to generate the playlist redirector file." Id. (citing '320 Patent at 17:48-51). The playlist server passes the redirector file "to the media player stored on the end user's computer." Id. at 18:5-8. Augme argues that "[t]he end-user's machine, not the playlist server, uses the redirector file to find and play the media file." Id. (citing Ex. B at 110:15-20). Augme points out that "[o]ther than creating the redirector file and passing it to the end user, there is no other functionality for the playlist server described in the '320 patent." Id. Thus, Augme concludes that the playlist server determines the media server from which content will be served.

During prosecution, to overcome the prior art, the patentee asserted that a "metafile," is just another word for "redirector file." Bishop Decl., Ex. E at YAH-0019249.

As will be discussed more fully below, Augme asserts that the term "redirector file" is "a file that contains links to the particular media server in the content management system from which the requested digital content will be served, the links including the server hostname and filename." See id. at 4:3-7; 17:15-18:26; 25:4-26:41.

Augme argues, on the other hand, that Yahoo!'s construction of the term "playlist server" is too broad and vague. Augme Br. at 22. In support of its position, Augme points out that claim 1 requires "creating, by the playlist server," a redirector file. Id. Augme asserts that Yahoo!'s construction ignores claim 1, and attempts "to tie its faulty construction to the claim language of claim 7." Augme Br. at 22-23. Augme cites to the file history in support of its contention that when claim 7 was originally filed, it read, "wherein activation of the link causes resolution of the unique identifier into the hostname and filename and causes the digital content to be provided to the end user based on the hostname and filename." Id. at 23 (citing Bishop Decl., Ex. E at YAH-0019371-72). In response to the indefiniteness rejection, Yahoo! amended the claim, explaining to the examiner that "a playlist server, uses the unique identifier to identify the digital content's server hostname and filename, and creates a redirector file, which contains a reference to the server hostname, e.g., a server to serve the content, and the filename of the content that is to be served." Id. (citing Ex. E at YAH-0019216). The examiner then amended the claim to clarify that it was the playlist server that resolved the "unique identifier into the server hostname and the filename of the digital content . . . based on the server hostname and filename of the digital content determined using the unique identifier." Id. (citing Bishop Decl., Ex. E at YAH-0019203). According to Augme, "that amendment didn't alter the plain language of the claim that activation of the link 'causes resolution of the unique identifier . . . and causes the digital content to be provided to the end user . . .'" Id. (citing '320 Patent at 28:37-42).

Yahoo! responds first that Augme's "distinct" server requirement fails because the claims do not require separate physical machines. Second, Yahoo! argues that Augme misreads the file history in arguing that Claim 7 requires a redirector file that identifies a "specific media server."

First, with respect to the "distinct server" argument, Yahoo! responds that there is no support for Augme's argument that the servers must be separate physical machines. Rather, Augme's position is contradicted by the specification, which states that the playlist server (and, by implication, any server) "may be implemented in software" - i.e., on a shared computer with other "servers." Yahoo! Reply at 11 (citing '320 Patent at 4:24-33).

Yahoo! contends that the parties' extrinsic evidence is in accord. Id. (citing Br. Ex. H at 8-9 (citing dictionaries); Reply Declaration of Richard S.J. Hung, Dkt. 198, Ex. P at 474 ("server" may be a "computer or program"); Reply Ex. Q at 215 ("client-server computing" may include a "server process or program"); Reply Ex. R at 1905 ("server" may be "a computer or software package").

Yahoo! disputes Augme's characterization of Dr. Nutt's testimony as supporting Augme's construction. Yahoo! Reply at 11. In the deposition excerpt cited by Augme, Yahoo!'s expert, Dr. Nutt, provided his interpretation of an "ingest server" as a "distinct unit of computation from the repository server" using "some" separate memory. Bishop Decl., Ex. B at 103:19-104:18. Yahoo! argues that this testimony is entirely consistent with an implementation of the recited servers as separate "threads" of program instructions on a single physical machine. Later in his deposition, Dr. Nutt made this point. Yahoo! Reply at 11 (citing Reply Ex. S at 108:8-22 (in response to the question: "Does the playlist server have to be distinct from the ingest server" Dr. Nutt answered: "The playlist server has to be - it's defined to be in the patent a distinct unit of computation, but it can still be on the same machine. . . . It has its own memory. . . .And it has its own portion of the processor.")

A "thread" is a sequence of program instructions executing within a larger software application, such as separate instructions to download two web pages in two separate web browser tabs at the same time. Reply Ex. P at 518 (defining "thread" as "a process that is part of a larger process or program").

In response to Augme's argument that Yahoo!'s construction is too broad because it encompasses functionality provided by the ingest and repository servers (Augme Br. at 22:18-22), Yahoo! notes that the parties have agreed that the ingest and repository servers, respectively, receive or store content. See Gilfoil Decl., Ex. H at 8-9. Thus, receiving or storing content does not "cause[] digital content to be provided to the end user," as Yahoo!'s construction of "playlist server" requires.

Yahoo! further argues that Augme's proposed construction that Claim 7's playlist server must provide a redirector file that identifies "the specific media server" to serve the content (as set forth in Augme's "redirector file" construction) is improperly narrow and limiting. See Augme Br. at 15:20-16:7, 17:11-19, 22:23-23:19. Because claim 7 does not even recite a "redirector file" (unlike claim 1), the construction of this term as including a redirector file clearly imports a limitation from the specification. Yahoo Reply at 12.

Yahoo rejects Augme's citation to the Examiner's and the applicant's discussion of the "redirector file" during prosecution of the patent. Id. (citing Augme Br., citing Bishop Decl., Ex. E at YAH-19216). Augme emphasizes that the Examiner issued a rejection on the alleged basis that the "redirector file" was indefinite. Yahoo! points out that the Examiner rejected only claim 1 on the basis of the "redirector file" limitation. See Bishop Decl., Ex. E at YAH-19226. Yahoo! explains that the Examiner did not explain its reasons for rejecting claim 7, which does not contain the term "redirector file." Id. Thus, the patentees directed their remarks regarding indefiniteness of the redirector file to Claim 1, not Claim 7. Id. at YAH-19216. In particular, the patentees stated that the "hereinabove" comments cited by Augme related to the amendments to Claim 1. Yahoo! Reply at 12. Yahoo! also points out that the patentees also stated that their remarks were "[b]y way of a non-limiting example" and were merely "[i]n accordance with one or more embodiments and without limitation." Id. at 12-13.

Thus, Yahoo! argues that there is no basis for requiring a redirector file in Claim 7 or for insisting that Claim 7's playlist server determines the "specific media server" to serve the content. Id.

b. Analysis

The Court is not persuaded by either parties' proposed construction of the term "playlist server." On the one hand, although Yahoo!'s definition ("server(s) that causes digital content to be provided to the end user") has some appeal, the definition is too broad because that definition could, arguably, apply to any of the servers in this patent given that serving content is ultimately what the invention does.

On the other hand, the Court finds that Augme's proposed construction is too narrow. Augme proposes to limit the function of the "playlist server" in ways that are not contemplated by the patent claims themselves. As discussed above with respect to the term "server hostname," there is no mention in the claims of any "specific media server" from which the content is served, nor is it clear that this is the function of the playlist server. Rather, the claim language is clear that the "playlist server" performs certain functions, including requesting the digital content, it determining the server hostname and filename based upon the unique identifier received with the request, and then creating the redirector file, (which includes the server hostname and filename associated with the digital content's unique identifier). '320 Patent, 27:51-28:1-11.

Augme also prefaces its proposed construction of the term with the word "distinct" without offering any explanation of how that term has applicability to the patent. Augme's argument is belied by the teachings of the specification, which states:

In general, the division of functionality among the web server 110, file management server 112, playlist server 122 and script processor 116 described herein is exemplary, as the functions may be segregated and grouped differently. For example, it is to be understood that although the present embodiment utilizes client web servers 110 that are separate from the playlist server 122, in alternate embodiments the functionality of the playlist server 122 described herein may be implemented in software residing on the web server 110, thereby obviating the need for a separate playlist server.

Id. at 4:24-33 (emphasis added). The servers need not be on separate physical machines, and, indeed, their functionality may be grouped.

Augme's proposed definition also includes the concept of a content management system that the Court has previously rejected.

Accordingly, the Court rejects the constructions proposed by both parties. The Court finds that because the playlist server is defined by what it does, which is set forth in the claims, at this point the term requires no further construction, other than to reject the additional limitations described above. The Court will determine in later proceedings whether any further construction is necessary.

8. "Redirector File"

a. Arguments

The parties agree that the term "redirector file" should be construed. Yahoo! disputes Augme's proposed construction for many of the same reasons as it disputes Augme's proposed definitions of "playlist server" and "server hostname," i.e., the addtion of limiting phrases such as "content management system" and "particular media server" which Yahoo! argues is improper and not supported by the claims nor the specification.

In support of its construction, Yahoo! explains that an end user (or web surfer) requests digital content from a "playlist server" using a unique identifier. Yahoo! Br. at 18 (citing '320 Patent at 27:51-28:3). The "playlist server" uses the unique identifier to determine a server hostname and filename associated with the digital content. Id. at 28:4-28:6. The playlist server then creates a "redirector file," which contains that server hostname and filename, and returns the file to the web surfer's computer. Id. at 28:7-10.

In one embodiment, the end user's computer reads the server hostname and filename from the redirector file and requests the digital content based on the server hostname and filename. Id. at 18:23-26. Therefore, Yahoo! explains "the 'redirector file' essentially 'redirects' the web surfer's computer from the playlist server to another server to obtain the digital content." Yahoo! Br. at 19.

Yahoo! argues that the patent claims define "redirector file" broadly, and that the only requirement of the redirector file is that it "includ[es] the server hostname and filename" associated with the unique identifier. '320 Patent at 28:7-10. Yahoo! advances a construction of this term in order to clarify that the server hostname and filename are that of the requested digital content. Id. at 27:40-47 (unique identifier, server hostname, and filename are all associated with the digital content).

With respect to Augme's position, Yahoo! argues that Augme's construction improperly reads limitations into the claims from one embodiment in the specification. For example, Augme's construction includes the term "link" - stating that redirector file must contain "links including the server hostname and filename." Yahoo! argues that the inclusion of the word "link" could cause the jury to interpret "link" to mean "a URL such as conventionally underpins a "link" on a webpage." Yahoo! Br. at 19. The jury might assume that the server hostname and filename must be packaged in the redirector file in the form "http://server.com/file," where "server.com" represents the server hostname and "file" represents the filename. Because the claims only require the redirector file to include the server hostname and filename, ('320 Patent 28:7-10), such a construction would be too narrow as it suggests that a particular format is required. Yahoo! Br. at 19.

Yahoo! also argues that the patentees used the word "link" elsewhere in the same claim, but chose not to use it here. Id. at 19-20; see also Acumed LLC v. Stryker Corp., 483 F.3d 800, 807 (Fed. Cir. 2007) (refusing to limit claim where specification showed "patentees knew how to restrict their claim coverage" as defendant urged, but patentees "chose a different term that implies a broader scope").

Finally, Yahoo! argues that Augme's "links" construction "is nothing more than an attempt to restrict the claims to one embodiment." Yahoo! Br. at 20. Augme cites as support, column 17, line 20 through column 18, line 26, which discloses a redirector file in "ASX" format containing URLs for digital content. Id. (citing '320 Patent at 18:5-26). Augme suggests that these URLs are "links." However, according to Yahoo!, Augme ignores the explicit statement in the specification that the "ASX"-type redirector file is but one example of a format for a redirector file:

One skilled in the art will recognize, of course, that different media technologies utilize different formats of redirector files and, therefore, the term "redirector file" is not limited to the ASX-type file shown above.

Id. at 18:20-23 (emphasis added).

Augme responds that Yahoo!'s proposed definition of "redirector file" would render the term "redirector" meaningless. Augme Br. at 19. Under Yahoo!'s proposed definition, any file that contains a "server hostname" and filename associated with digital content is a "redirector file," including a text file that simply lists a server hostname and filename, but does nothing, which according to Augme is "contrary to the teachings of the '320 Patent, and the understanding of a person of ordinary skill in the art." Id. at 19 (citing Bishop Decl., Ex. B at 115:23-117:18, excerpt of deposition of Dr. Nutt).

Augme contends that the specification teaches that a "redirector file" is provided to a media player on an end-user's computer to provide the media player with the hostname of the media server from which the digital content will be served, the filename of the content and the protocol to use to obtain it. Augme argues that the "sole example" of a "redirector file" in the '320 Patent is an "ASX-type" file which the patent explains is "a redirector file for use with Windows Media Technologies (WMT)." '320 Patent at 18:5-26. Augme asserts that Yahoo!'s proposed definition fails to capture any "redirection" functionality and that only the use of the word "link" will do so, otherwise, the term "redirector file" is "useless." Augme Br. at 20.

Augme also clarifies that it does not contend that the "redirector file" format must be ASX-type. However, the '320 Patent instructs that, regardless of format, "the end-user's media player pulls each identified stream file from the media server 120 identified in the redirector file in the order in which it appears in the file." '320 Patent at 18:23-26. Augme argues that:

a redirector file must allow a media player to contact the media server - it does this by providing the media player with a link to the particular media files to be played. And, as discussed above, the "server hostname" in a redirector file is the name of the particular media server from which the requested digital content is served.

See id. at 17:62-65, 17:67-18:4, 18:23-26, 26:20-41.

Yahoo! argues in its Reply Brief that Augme's own expert testified at his deposition in a manner consistent with Yahoo!'s definition, not Augme's. Specifically, at his deposition, the following exchange occurred between Yahoo!'s counsel and Augme's expert Dr. Bhattacharjee:

Q. I am sorry. Please take me through that again. You are saying [the server hostname and filename] doesn't have to be a URL?
A. It does not have to be a URL. It just has to have the hostname and filename in a way that can be parsed by the end user player. Okay? So any file that happens to include the text corresponding to the server hostname and filename is sort of not sufficient. It needs to be - it needs to be interpretable to a certain extent, if I may use that term, by the player. And the way that's being expressed in this definition is that it's saying it's a link. Okay? It's not saying what the format of the link is. It need not be a URL.

Reply at 10 (citing Ex. O at 184:15-185:14 (emphasis added).

b. Analysis

The Court is not persuaded by Augme's proposed construction of the term "redirector file." It suffers some of the same deficiencies as its proposed definition of "playlist server" and "server hostname", i.e., it inserts limiting phrases that would require further construction and which would result in improper limitations being imported from the specification. The Court therefore declines to adopt a construction that includes the phrase "in a content management system" or the term "media server" for the reasons explained more fully above.

Moreover, there is no support for Augme's insertion of the term "link" into the definition of "redirector file." Augme's own expert testified that any file that includes the server hostname and filename and which can be interpreted by the player is sufficient - "it need not be a URL." Use of the term "link" would confuse the jury in that it is a commonly-used term for a URL. Augme has not provided support for its contention that a playlist server's computer would be unable to read a filename or server hostname unless it is in the form of a "link." The claims themselves do not require any particular format.

On the other hand, Yahoo!'s proposed construction leaves out the functionality of the redirector file: redirection. The Court thus adopts a slightly modified version of Yahoo!'s construction of this term and construes "redirector file" as "a file that includes the server hostname and filename associated with the requested digital content, which can be used by the end user to obtain the requested digital content."

9. "Repository Server"

a. Arguments

Augme's construction of "repository server" again includes the limitations "distinct" and "in a content management system." Augme also limits the function of the repository server to storage of back-up content. Augme notes that the '320 Patent explains that the function of the repository server is to store back-up of the digital content that is also stored on a media server. Augme Br. at 23-24 (citing '320 Patent at 5:66-6:25 (noting that status of a content file on the repository server is 'back up" once the file is copied to a media server.); id. at 18:32-35 ("Furthermore, certain embodiments do not, as in the embodiment of FIG. 1, include repository servers that maintain backed up copies of files"); see also U.S. Provisional Patent Application Ser. No. 60/263,058, Ex. F at 27 ("For example, certain embodiment [sic] do not include repository servers and therefore, do not maintain backed-up copies of files as in the embodiment of Figure 1"); '320 Patent at 19:1 ("repository or backup server")).

Augme argues that Yahoo!'s construction of a "server that stores content" is too broad because: 1) it ignores the "backup" functionality of the repository server; and 2) it could include any server in the content management system that stores digital content such an ingest server or a media server. Augme argues that Yahoo!'s definition fails because it does not provide an appropriate distinction between the repository server and the other servers in the system.

Yahoo! responds that its construction is consistent with the claim language, i.e., that the repository server "stor[es] . . .the digital content" or 'caus[es] digital content to be stored." Yahoo! Reply at 13 (citing '320 Patent at 27:42-44, 28:24-29). Yahoo! argues that Augme's proposed definition is too narrow because the claims themselves are clear that the content stored (or "caused to be stored") by the repository server may be the same copies that are provided to the end user (and thus not limited to "back-ups"). Yahoo! Reply at 13 (citing '320 Patent at 28:7-10, 28:37-42). Because the repository server may store the primary, and not just back up, copies of the digital content, Augme's definition is too narrow. Id. Yahoo! disputes Augme's position that Yahoo!'s definition "ignores" the back-up function of the repository server. Although the specification may describe other functions for the repository server, such as receiving uploads, or transferring content to a media server ('320 Patent at 9:32-35, 3:66-4:3), these "other functions" are not recited by the claims and are "thus not required by the plain claim language." Id. at 14.

Yahoo! also dismisses Augme's concern that the construction of "repository server" could be interpreted by a jury to cover all of the other servers because the patentees "clearly defined a repository server in the claims by what it does ("stor[ing]" "digital content") - not what it is, consistent with the method style of claiming." Yahoo! Reply at 14.

b. Analysis

As a threshold matter, the Court declines to include the limitations "in a content management system" and "distinct" in the definition of the term "repository server" for the reasons explained more fully above. The Court also declines to limit the repository server to a "back up" function. Nowhere in the claims is the word "back up" used; thus, inclusion of this term would graft a limitation from the specification onto the claims.

The examples cited by Augme from the specification only describe an embodiment of the invention: None of the portions of the specification suggests that the function of the repository server must be limited to the storing of backup content. Augme's citations to the specification support the conclusion that storing backup content is one of the functions of the repository server, but do not convince the Court that this is the only function.

Similarly, the Court is not persuaded by Augme's argument that Yahoo!'s proposed construction could be read to encompass all of the servers. The servers in the invention are defined by what they do. The repository server "stores digital content." Yahoo!'s definition is the only one that does not import limitations from one embodiment.

Accordingly, the Court defines "repository server" as "a server that stores digital media files."

10. "Receiving by an Ingest Server, the Unique Identifier to the Digital Content"; "Ingest Server"

a. Arguments

Augme argues that Claim 7 is indefinite because "receiving by an ingest server, the unique identifier to the digital content" is nonsensical in the context of the '320 Patent." Augme Br. at 24. However, Augme also presents a construction of the term "ingest server." Augme argues that "ingest server" should be construed as "a distinct server in a content management system to which digital content is uploaded, transferred or copied." Id.

Relying on the declaration of its expert, Dr. Bhattacharjee, Augme argues that one of ordinary skill in the art would not understand Claim 7 of the '320 to disclose any functionality for the ingest server to receive the unique identifier to the digital content. Id. (citing Bhattacharjee Decl., ¶30). Rather, according to Augme, the ingest server receives uploaded content from a digital content provider (the client). Id. (citing '320 Patent at 3:8-12). The ingest server transfers the content to the repository server. Id. (citing 3:21-22). The unique identifier is provided to the client for inclusion on a web page or otherwise published so that it is accessible to the end user. Id. (citing 12:60-65; 17:4-5; 17:27-35; 28:33-36). Augme contends that "[t]here is no description of a scenario in which the ingest server receives a unique identifier to the digital content in the '320 Patent, nor does it specify how an ingest server would store, process, or use such an identifier." Id. at 24-25 (citing Bhattacharjee Decl., ¶30).

Yahoo! responds that Augme's indefiniteness argument - made without citation to any legal authority, or reference to the appropriate legal standard - is without merit. The correct legal inquiry is not whether "the functionality is disclosed" in the specification, as Augme argues. Rather, the question is whether "one of ordinary skill in the art would understand what is claimed when the claim is read in light of the specification." Yahoo! Reply at 14 (citing Bancorp Servs., LLC v. Hartford Life Ins. Co., 359 F.3d 1367, 1372 (Fed. Cir. 2004)). Yahoo! argues that one of ordinary skill in the art would understand what is claimed by the language "receiving, by an ingest server, the unique identifier to the digital content" and that is this: the ingest server receives the digital content's unique identifier. Id. (citing Nutt Reply Decl., ¶¶ 2-6).

Relying on All Dental Prodx, LLC v. Advantage Dental Prods., Inc., 309 F.3d 774, 780 (Fed. Cir. 2002), Yahoo! argues that Augme's failure to argue that any of the words in this term are unclear reveals the weakness of its argument. In fact, Augme offers its own definition of "ingest server," which Yahoo! argues is further proof that the claim is capable of construction, and therefore not "indefinite." Id. Yahoo! also points out that Augme does not dispute that similar claim language is understandable - "receiving by a playlist server, a request for the content, . . . the request including the unique identifier." Id. at 14-15 (citing '320 Patent at 27:51-28:3). This too undermines Augme's argument that a skilled artisan would not understand what it means for a different server - the ingest server - to perform a similar step. Id.

In All Dental Prods., the Federal Circuit explained: "Only after a thorough attempt to understand the meaning of a claim has failed to resolve material ambiguities can one conclude that the claim is invalid for indefiniteness." 309 F.3d at 780.
--------

Yahoo! contends that the heart of Augme's indefiniteness argument is its "belief that there is no reason for an ingest server to receive a unique identifier. Id. at 15 (citing Augme Br. at 24-25, specification does not disclose "how an ingest server would store, process or use [a unique] identifier.") Yahoo! points out that the purpose of a limitation is not the appropriate inquiry on indefiniteness, but rather "indefiniteness concerns whether the bounds of the claim are clear to the skilled artisans." Id. (citing Bancorp, 359 F.3d at 1372 (rejecting indefiniteness challenge where term was "not defined in the patent," but the components of the term have well-recognized meanings, which allow the reader to infer the meaning of the entire phrase with reasonable confidence"). Because "those boundaries are clear here," Yahoo! urges the Court to reject Augme's indefiniteness challenge. Id.

b. Analysis

The Court notes at the outset that wherever possible, the Court will construe the claims to preserve validity. See Cardiac Pacemakers, Inc. v. St. Jude Medical, Inc., 296 F.3d 1106 (Fed. Cir. 2002) (citing Tate Access Floors, Inc. v. Interface Architectural Resources, Inc., 279 F.3d 1357, 1367, 61 USPQ2d 1647, 1654 (Fed. Cir. 2002)).

Here, the Court concludes that claim 7 is not indefinite. An artisan of ordinary skill would be able to discern what is claimed in Claim 7. The fact that Augme advances its own construction of the term "ingest server" is telling. However, the Court declines to address, at this stage of the case, whether there are other problems with this claim, e.g., whether the claim is enabled or whether a sufficient written description accompanies this claim.

Again, as with its proposed constructions of the terms "playlist server" and "server hostname," Augme seeks to limit the definition of ingest server by importing limitations from the specification. The Court is neither persuaded by Augme's indefiniteness arguments (which Yahoo! correctly notes are made without citation to any relevant authority) nor is it persuaded by the proposed construction of the term "ingest server." Rather, the Court finds no construction is necessary as the jury could understand the words used in the patent.

VI. CONCLUSION

For the reasons stated above, the Court adopts the following claim constructions:

+-----------------------------------------------------------------------------+ ¦Claim Term ¦Court's Construction ¦ +------------------------------------+----------------------------------------¦ ¦ ¦"a media file player that is displayed ¦ ¦ ¦on a web ¦ ¦ ¦ ¦ ¦1. "Viewer" ¦page, including media file players that ¦ ¦ ¦play ¦ ¦ ¦ ¦ ¦ ¦audio-only content" ¦ +------------------------------------+----------------------------------------¦ ¦ ¦"entities that provide named digital or ¦ ¦2. "Media file providers" ¦audio ¦ ¦ ¦ ¦ ¦ ¦sequences of bits." ¦ +------------------------------------+----------------------------------------¦ ¦3. "Defining a set of metadata ¦"configuring a database to store values ¦ ¦attributes"; ¦for the ¦ ¦ ¦ ¦ ¦and "defining a set of metadata ¦metadata attributes" ¦ ¦attribute types" ¦ ¦ +------------------------------------+----------------------------------------¦ ¦4. "Associating Metadata attributes ¦ ¦ ¦from ¦ ¦ ¦ ¦Per parties' agreement, no construction ¦ ¦the set of metadata attributes with ¦is required. ¦ ¦each ¦ ¦ ¦ ¦ ¦ ¦of said plurality of media files" ¦ ¦ +------------------------------------+----------------------------------------¦ ¦ ¦Per the parties' agreement: "gathering ¦ ¦ ¦or ¦ ¦5. "Compiling said plurality of ¦ ¦ ¦media files" ¦putting together into a corpus or other ¦ ¦ ¦ ¦ ¦ ¦collection the plurality of media files"¦ +-----------------------------------------------------------------------------+

+-----------------------------------------------------------------------------+ ¦6. ¦"Server hostname" ¦network name of a server ¦ +---+-------------------------------+-----------------------------------------¦ ¦7. ¦"Playlist Server" ¦No construction necessary ¦ +---+-------------------------------+-----------------------------------------¦ ¦ ¦ ¦"a file that includes the server hostname¦ ¦ ¦ ¦and ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦filename associated with the requested ¦ ¦8. ¦"Redirector File" ¦digital ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦content, which can be used by the end ¦ ¦ ¦ ¦user to ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦obtain the requested digital content" ¦ +---+-------------------------------+-----------------------------------------¦ ¦9. ¦"Repository Server" ¦"A server that stores digital media ¦ ¦ ¦ ¦files" ¦ +---+-------------------------------+-----------------------------------------¦ ¦ ¦"Receiving by an Ingest Server,¦ ¦ ¦ ¦the ¦ ¦ ¦ ¦ ¦ ¦ ¦10.¦Unique Identifier to the ¦No construction necessary. ¦ ¦ ¦Digital ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦Content"; "Ingest Server" ¦ ¦ +-----------------------------------------------------------------------------+

IT IS SO ORDERED.

_______________

JOSEPH C. SPERO

United States Magistrate Judge

Augme Techs. Inc. v. Yahoo! Inc.

Summary

Opinion

CLAIM CONSTRUCTION ORDER

I. INTRODUCTION

II. OVERVIEW OF THE PATENTS AND CLAIMS

III. LEGAL STANDARDS

IV. DISPUTED CLAIM TERMS

CONSTRUCTION OF '320 PATENT DISPUTED TERMS

VI. CONCLUSION

Augme Techs. Inc. v. Yahoo! Inc.

Augme Techs. Inc. v. Yahoo! Inc.

Case Details

Citations

Citing Cases

Augme Techs. Inc. v. Yahoo! Inc.

Summary

Opinion

CLAIM CONSTRUCTION ORDER

I. INTRODUCTION

II. OVERVIEW OF THE PATENTS AND CLAIMS

III. LEGAL STANDARDS

IV. DISPUTED CLAIM TERMS

CONSTRUCTION OF '320 PATENT DISPUTED TERMS

VI. CONCLUSION

Augme Techs. Inc. v. Yahoo! Inc.

Augme Techs. Inc. v. Yahoo! Inc.

Case Details

CitationsCopy Citation

Citing Cases

Citations