Opinion
Civil Action No. 17-1751-CFC-CJB
01-16-2019
PERSONAL AUDIO, LLC, Plaintiff, v. GOOGLE LLC, Defendant.
REPORT AND RECOMMENDATION
In this action filed by Plaintiff Personal Audio, LLC ("PA" or "Plaintiff") against Google LLC ("Google" or "Defendant"), PA alleges infringement of United States Patent Nos. 6,199,076 (the "'076 patent") and 7,509,178 (the "'178 patent" and collectively with the '076 patent, "the asserted patents"). Presently before the Court is the matter of claim construction. The Court recommends that the District Court adopt the constructions as set forth below.
I. BACKGROUND
A. The Asserted Patents
The asserted patents are related and share a common specification. (See D.I. 147, ex. A (hereinafter, the "'076 patent"); id., ex. B (hereinafter, the "'178 patent"); D.I. 38 at ¶ 30; D.I. 159 at 1 n.1) The '076 patent is entitled "Audio Program Player Including a Dynamic Program Selection Controller" and was issued on March 6, 2001 from U.S. Appl. No. 08/724,813, which was filed on October 2, 1996. ('076 patent) The '178 patent, entitled "Audio Program Distribution and Playback System," is a divisional of the application that led to the '076 patent, and was issued on March 24, 2009. ('178 patent)
In light of this, the Court will typically only cite to one of the two patents when citing to portions of the patents' common specification.
The asserted patents are directed to an audio program player that automatically plays a predetermined schedule of audio program segments (e.g., songs) from a program library. (D.I. 38 at ¶¶ 31, 33; '076 patent, col. 2:6-8; D.I. 159 at 1) The claimed player further allows a listener to dynamically alter the sequence and content of the audio program segments presented. (D.I. 38 at ¶¶ 31, 33; '076 patent, cols. 1:7-9, 1:64-2:3, 2:44-47, 2:55-58) The Abstract of the patents explains that "a host system organizes and transmits program segments to client subscriber locations" (i.e., to players). ('076 patent, Abstract) The audio program player may be implemented by a conventional laptop or desktop computer equipped with, inter alia: (1) a sound card connected to a speaker; and (2) a modem connected to the Internet that downloads the program information from the remote server and uploads program selections and preferences as well as usage data. (Id., cols. 4:32-5:45)
B. Procedural History
On September 15, 2015, PA filed this action against Google in the United States District Court for the Eastern District of Texas ("Eastern District of Texas"), alleging infringement of the asserted patents. (D.I. 1 at ¶¶ 1-4) Prior to filing the instant lawsuit, PA had asserted the '076 patent and '178 patent in six other litigations in the Eastern District of Texas. (D.I. 128 at ¶ 7) In one of these litigations, Personal Audio, LLC v. Apple, Inc., Civil Action No. 9:09CV111 (the "Apple litigation"), the Eastern District of Texas Court issued multiple orders in which it construed certain terms of the asserted patents, (D.I. 160 (hereinafter, "Sano Decl."), exs. 1-3), and further discussed the meaning of claim terms in connection with opinions relating to the defendant's motion for summary judgment of indefiniteness and motions for judgment as a matter of law, (id., ex. 16; D.I. 147 (hereinafter, "Almeroth Decl."), ex. C).
In conjunction with the Apple litigation, an ex parte reexamination proceeding was instituted by the United States Patent and Trademark Office ("PTO") with respect to certain claims of the '076 patent, and an inter partes reexamination proceeding was instituted by the PTO with respect to the '178 patent. (See D.I. 147, ex. Z at 3-4) The reexamination examiners ultimately confirmed the relevant claims of the '076 patent, and the reexamination proceeding for the '178 patent was eventually terminated as a result of the conclusion of the Apple litigation. (Id.)
Shortly after PA initiated this action in the Eastern District of Texas, the case was stayed, at Google's request, pending inter partes review ("IPR") proceedings (the "IPR proceedings") involving certain claims of both asserted patents, which had been instituted by the Patent Trial and Appeal Board ("PTAB") of the PTO. (See D.I. 234 at 4) Those proceedings concluded by September 2016. (Almeroth Decl., exs. G, H) With respect to the '076 patent, the PTAB found that: (1) claims 1 and 4 were unpatentable; and (2) Google had not proven that claims 2, 3, 14 and 15 were unpatentable. (Id., ex. G at 57; D.I. 23 at 1) As for the '178 patent, the PTAB found that: (1) claims 1-4, 9 and 13 were unpatentable; and (2) Google had not proven that claims 5-8, 14-17, 28 and 29 were unpatentable. (Almeroth Decl., ex. H at 44; D.I. 23 at 1) The parties filed cross-appeals with respect to those decisions to the United States Court of Appeals for the Federal Circuit, and the Federal Circuit ultimately affirmed the PTAB's conclusions in all respects. Google LLC v. Personal Audio, LLC, 743 F. App'x 978 (Fed. Cir. 2018).
In January 2017, the Eastern District of Texas Court lifted the stay, (D.I. 31), but the case was thereafter transferred to this District in December 2017, (D.I. 103). Upon transfer here, the case was assigned to the Vacant Judgeship docket on December 13, 2017, and was referred to the Court "for handling through case-dispositive motions[,]" including "deciding non-dispositive matters and making recommendations as to the resolution of dispositive matters." (Docket Item, December 13, 2017) The case has since been re-assigned to District Judge Colm F. Connolly, with the substance of the referral to the Court remaining the same. (Docket Item, September 10, 2018)
The parties completed initial briefing on claim construction on July 18, 2018. (D.I. 146; D.I. 159; D.I. 176; D.I. 186) The Court held a Markman hearing on August 1, 2018. (D.I. 250 (hereinafter, "Tr.")) Following the hearing, on August 7, 2018, Google submitted a supplemental letter brief to address caselaw newly disclosed by PA during the Markman hearing. (D.I. 202)
II. STANDARD OF REVIEW
A. General Claim Construction Principles
It is well-understood that "[a] claim in a patent provides the metes and bounds of the right which the patent confers on the patentee to exclude others from making, using, or selling the protected invention." Corning Glass Works v. Sumitomo Elec. U.S.A., Inc., 868 F.2d 1251, 1257 (Fed. Cir. 1989). Claim construction is a generally a question of law, although subsidiary fact finding is sometimes necessary. Teva Pharms. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 837-38 (2015).
The Court should typically assign claim terms their "ordinary and customary meaning[,]" which is "the meaning that the term[s] would have to a person of ordinary skill in the art ['POSITA'] in question at the time of the invention, i.e., as of the effective filing date of the patent application." Phillips v. AWH Corp., 415 F.3d 1303, 1312-13 (Fed. Cir. 2005) (citations omitted). However, when determining the ordinary meaning of claim terms, the Court should not extract and isolate those terms from the context of the patent; rather it should endeavor to reflect their "meaning to the ordinary artisan after reading the entire patent." Id. at 1321; see also Eon Corp. IP Holdings LLC v. Silver Spring Networks, Inc., 815 F.3d 1314, 1320 (Fed. Cir. 2016).
In proceeding with claim construction, the Court should look first and foremost to the language of the claims themselves, because "[i]t 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, 415 F.3d at 1312 (internal quotation marks and citations omitted). For example, the context in which a term is used in a claim may be "highly instructive." Id. at 1314. In addition, "[o]ther claims of the patent in question, both asserted and unasserted, can . . . be valuable" in discerning the meaning of a particular claim term. Id. This is "[b]ecause claim terms are normally used consistently throughout the patent, [and so] the usage of a term in one claim can often illuminate the meaning of the same term in other claims." Id. Moreover, "[d]ifferences among claims can also be a useful guide[,]" as when "the presence of a dependent claim that adds a particular limitation gives rise to a presumption that the limitation in question is not present in the independent claim." Id. at 1314-15.
In addition to the words of the claims, the Court should look to other intrinsic evidence. For example, the Court should analyze the patent specification, which "may reveal a special definition given to a claim term . . . that differs from the meaning [that term] would otherwise possess" or may reveal an intentional disclaimer of claim scope. Id. at 1316. Even if the specification does not contain such revelations, it "is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term." Id. at 1315 (internal quotation marks and citation omitted). That said, however, the specification "is not a substitute for, nor can it be used to rewrite, the chosen claim language." SuperGuide Corp. v. DirecTV Enters., Inc., 358 F.3d 870, 875 (Fed. Cir. 2004). And a court should also consider the patent's prosecution history, if it is in evidence, because it "can often inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution[.]" Phillips, 415 F.3d at 1317.
Extrinsic evidence, "including expert and inventor testimony, dictionaries, and learned treatises[,]" can also "shed useful light on the relevant art[.]" Id. (internal quotation marks and citations omitted). Overall, while extrinsic evidence may be useful, it is "less significant than the intrinsic record in determining the legally operative meaning of claim language." Id. (internal quotation marks and citations omitted); accord Markman v. Westview Instruments, Inc., 52 F.3d 967, 981 (Fed. Cir. 1995).
In utilizing these resources during claim construction, courts should keep in mind that "[t]he construction that stays true to the claim language and most naturally aligns with the patent's description of the invention will be, in the end, the correct construction." Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998).
B. Principles for Construction of Means-Plus-Function Limitations
35 U.S.C. § 112, ¶ 6 ("Section 112, paragraph 6") provided as follows:
The Court here refers to the version of Section 112 as it existed prior to the passage of the Leahy-Smith America Invents Act ("AIA"). Although the structure of Section 112 changed after the AIA's passage, those changes are applicable only to any patent application filed on or after September 16, 2012. See Alcon Research Ltd. v. Barr Labs., Inc., 745 F.3d 1180, 1183 n.1 (Fed. Cir. 2014). Because the applications at issue here were filed before that date, the Court refers to the pre-AIA version of Section 112.
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.The "means-plus-function" technique of claim drafting is a "convenience" that allows a patentee to express a claim limitation in functional terms "without requiring the patentee to recite in the claims all possible structures" that could perform that function. Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205, 1211 (Fed. Cir. 2003). In exchange for getting the benefit of this drafting convenience, however, patentees must disclose, in the written description of the patent, a corresponding structure for performing the claimed function. Noah Sys, Inc. v. Intuit Inc., 675 F.3d 1302, 1318 (Fed. Cir. 2012); see also Elekta, 344 F.3d at 1211 ("[T]he price that must be paid for use of that convenience is limitation of the claim to the means specified in the written description and equivalents thereof.") (citation omitted). A patentee satisfies this requirement "only if the specification or prosecution history clearly links or associates that structure to the function recited in the claim." In re Aoyama, 656 F.3d 1293, 1297 (Fed. Cir. 2011) (emphasis added) (quoting Elekta, 344 F.3d at 1210); see also Elekta, 344 F.3d at 1220 ("The public should not be required to guess as to the structure for which the patentee enjoys the right to exclude. The public instead is entitled to know precisely what kind of structure the patentee has selected for the claimed functions, when claims are written according to section 112, paragraph 6."). "If the specification does not contain an adequate disclosure of the structure that corresponds to the claimed function, the patentee will have failed to particularly point out and distinctly claim the invention as required by . . . section 112, [paragraph 2], which renders the claim invalid for indefiniteness." Blackboard, Inc. v. Desire2Learn Inc., 574 F.3d 1371, 1382 (Fed. Cir. 2009) (internal quotation marks and citation omitted).
Section 112, paragraph 2 provided 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." 35 U.S.C. § 112, ¶ 2.
Construing a means-plus-function limitation is a two-step process. The first step is determining the claimed function of the limitation. Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1351 (Fed. Cir. 2015); Medtronic, Inc. v. Advanced Cardiovascular Sys., Inc., 248 F.3d 1303, 1311 (Fed. Cir. 2001). The second step is identifying the corresponding structure disclosed in the specification and equivalents thereof. Williamson, 792 F.3d at 1351; Medtronic, Inc., 248 F.3d at 1311.
When a patentee claims a computer-implemented invention and invokes means-plus-function limitations, the United States Court of Appeals for the Federal Circuit has "consistently required that the structure disclosed in the specification be more than simply a general purpose computer or microprocessor." Aristocrat Techs. Austl. Pty Ltd. v. Int'l Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008). This requirement seeks to avoid "pure functional claiming[,]" id., and mandates that the patent must disclose sufficient algorithmic structure or some other description explaining how the computer performs the claimed function, see id. at 1332-37; Blackboard, Inc, 574 F.3d at 1383-85; Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340 (Fed. Cir. 2008) (explaining that a patentee is permitted "to express that algorithm in any understandable terms including as a mathematical formula, in prose, [] or as a flow chart, or in any other manner that provides sufficient structure") (internal citation omitted). The Federal Circuit has identified a "narrow exception" to this requirement; no algorithm need be disclosed "when the function 'can be achieved by any general purpose computer without special programming.'" Ergo Licensing, LLC v. CareFusion 303, Inc., 673 F.3d 1361, 1364-65 (Fed. Cir. 2012) (quoting In re Katz Interactive Call Processing Patent Litig., 639 F.3d 1303, 1316 (Fed. Cir. 2011)). For example, "a general-purpose computer is sufficient structure if the function of a term such as 'means for processing' requires no more than merely 'processing,' which any general-purpose computer may do without special programming." Id. at 1365. The Federal Circuit has emphasized that "[i]t is only in the rare circumstances where any general-purpose computer without any special programming can perform the function that an algorithm need not be disclosed." Id; see also Alfred E. Mann Found. for Sci. Research v. Cochlear Corp., 841 F.3d 1334, 1342 (Fed. Cir. 2016).
An algorithm is "'a step-by-step procedure for accomplishing a given result[.]'" Alfred E. Mann Found. for Sci. Research v. Cochlear Corp., 841 F.3d 1334, 1342 (Fed. Cir. 2016) (citation omitted).
III. DISCUSSION
The parties currently have disputes regarding ten terms or sets of terms (hereinafter, "terms"). This Report and Recommendation addresses the first three terms, in the order in which the parties addressed them at the Markman hearing. The other seven terms will be addressed in a forthcoming Report and Recommendation(s).
The parties originally submitted an additional set of terms for claim construction: "player"/"audio program player"/"programmed digital computer[,]" which are found in all asserted claims of the patents-in-suit. (See, e.g., D.I. 159 at 2; D.I. 176 at 14) During the Markman hearing, however, the parties agreed that these terms may be given their plain and ordinary meaning, and the Court therefore will not further construe them. (Tr. at 174-75)
A. "file"
The claim term "file" appears in all asserted claims of the patents-in-suit. The use of the disputed term in claim 1 of the '178 patent is representative. Accordingly, this claim is reproduced below, with the disputed term highlighted:
1. An audio program player comprising:
a communications port for establishing a data communications link for downloading a plurality of separate digital compressed audio program files and a separate sequencing file from one or more server computers,
a digital memory unit coupled to said communications port for persistently storing said separate digital compressed audio program files and said separate sequencing file, said sequencing file containing data specifying an ordered sequence of a collection of said separate digital compressed audio program files,
an audio output unit including at least one speaker or headset for reproducing said audio program files in audible form perceptible to a listener,
one or more manual controls for accepting commands from said listener, and
a processor for continuously delivering a succession of said audio program files in said collection to said audio output unit in said ordered sequence specified by said sequencing file in the absence of a program selection command from said listener, and for discontinuing the reproduction of the currently playing audio
program file and instead continuing the reproduction at the beginning of a listener-selected one of said audio program files in said collection in response to a program selection command from said listener.('178 patent, cols. 45:60-46:18 (emphasis added))
The parties' competing proposed constructions for "file" are set out in the chart below:
| Term | Plaintiff's ProposedConstruction | Defendant's ProposedConstruction |
|---|---|---|
| file | any collection of data that isstored and manipulated as aunitor, alternatively:a collection of data that isstored and manipulated as aunit by a file management ordatabase system | a collection of data that isstored and manipulated as anamed unit by a file-management system |
The Court will first assess Google's proposed "file-management system" limitation. As to that limitation, the Court is not persuaded that, in the context of these patents, a "file" must be limited to something (i.e., data) stored and manipulated only by a file-management system. This is so for four reasons.
First, despite Google's argument to the contrary, the Court does not understand PA's alternative proposed construction for "file" (i.e, "a collection of data that is stored and manipulated as a unit by a file management or database system") to mean the same thing as "data" and to thus improperly conflate "file" and "data." PA does not simply propose to construe "file" to mean "data." Instead, its proposal adds additional parameters: (1) there must be a collection of data; (2) such collection must be stored and manipulated as a unit; and (3) such storing and manipulation is by a file-management system or a database system. (See id. at 23-24 (PA's counsel explaining that its proposal amounts to more than just "unstructured" data, instead encompassing a block of data that is stored and manipulated by a database system (or file-management system)))
Second, it is undisputed that the patents nowhere use the term "file-management system" in describing the invention. (See D.I. 146 at 3; Tr. at 14) And thus, as PA puts it, Google "ignores that the patents teach storing and accessing files and the data within files without ever teaching that a file-management system is necessary." (D.I. 146 at 4) Moreover, while the patents do not include the phraseology "file-management system," they do refer to "database[s]" that "store[]" "file[s]." (See, e.g., '076 patent, cols. 5:66-6:2, 6:34-44; D.I. 146 at 4)
During oral argument, Google's counsel argued that while the patents did not expressly use the term "file-management system," there are "examples of file-management systems" therein. (Tr. at 14) To that end, counsel asserted that the patents refer to the notion of a file transfer protocol ("FTP") as the means for downloading files to the player, and that such a protocol deals only with files, not just any collection of data. (Id. at 13-14; see, e.g., '076 patent, col. 5:47-51 ("The host server 101 provides a FTP server interface . . . which provides file transfer protocol services to the player 103[.]")) Google did not make this point in its briefing, (see D.I. 159; D.I. 186), though Google's expert did briefly mention it in his declaration, (see D.I. 162 at ¶ 18 (explaining that the POSITA would not understand "file" in the context of "receiving and storing" to mean any unit of data, especially given the patents' numerous references to the FTP server as being the tool that downloads files to the player)). However, it is not entirely clear from Google's limited arguments on this point whether a FTP actually is a "file-management system," or instead simply constitutes instructions for transferring files. (See, e.g., id. at 7 n.1 (Google's expert stating that FTP is "a fast, application-level protocol widely used for copying files to and from remote computer systems on a network using TCP/IP, such as the Internet"); Tr. at 14 (Google's counsel responding that "[y]es[,]" FTP is the file-management system but then adding "[w]ell, it's a system that deals only with files")) And so the Court is not convinced that it should limit the construction of "file" to requiring a file-management system on the basis of these references to "FTP" in the patents' specifications.
Third, the patents refer to database tables as files, which (as PA asserts) indicates that the construction for "file" should encompass data structures that are stored and manipulated by database systems. (D.I. 146 at 3-4; D.I. 176 at 14; Tr. at 7-8, 25) For instance, in discussing the preferred embodiment, the patents refer to a particular table (Table 301) that is stored in a database as a "file":
The [program] selections made by and uploaded from the [individual] subscriber take the form of a file (sequence) of 32 bit integers, each integer (ProgramID) designating a particular program segment. This file of integers is placed in a relational database Requested Table seen at 301 in Fig. 4 . . . . The Program Segment records in the Programs Table 303 are relationally linked using the ProgramID key to other tables including[] the Requested Table 301 discussed above.('178 patent, col. 17:15-61 (emphasis added)) And earlier, the patents explain that at step 219, "the selections made by the user at 217 as well as the contents of the usage log recorded at 215 are uploaded to the server as a requested file (seen at 301 in Fig. 4)." (Id., col. 9:50-52 (emphasis added)) Additionally, the patents describe another database table ("Table 307") as a "file" which is formed from segments added to Table 301:
The Program_Segment records in the Programs Table 303 are relationally linked using the ProgramID key to other tables including . . . Schedule Table 307 which contains the recommended sequence of program segments for the next playback session[.](Id., col. 17:58-64 (emphasis added))
The programs, advertising and announcement segments which are added to the Request Table 301 to form the Schedule Table 307 are determined by a matching procedure 342 which may be better understood by first considering the content of the data structures which provide data utilized to make those selections.(Id., col. 18:37-42 (emphasis added))
As described in more detail later in connection with FIGS. 4 and 5, the sequence of program segments to be presented to the user is formed into a schedule file (seen at 307 in Fig. 4 ) consisting of a sequence of program segment identification numbers which are used to compile a sequencing file, called the selections file, illustrated at 351 in FIG. 5, which contains more detailed information about the sequence of events which occur during playback.(Id., col. 12:9-16 (emphasis added)) In the Court's view, the patents' references to these structures as both database tables and files supports PA's argument that a file should be construed to mean data stored and manipulated as a unit by a file-management system or a database system. (See Tr. at 25)
Google responds that these references are irrelevant to the construction of the claimed "files" because "the server-side 'database' of 32-bit integers relied on by PA has nothing to do with the 'files' that are received and stored by the player." (D.I. 186 at 13; see also D.I. 159 at 11) At a minimum, however, the above-referenced portions of the specification provide support for the idea that—at least as a general matter—a "file" is something that can be stored in a database system.
Google's position that server-side database structures have nothing to do with the "files" received and stored by the player seems to overlook the fact that the specification not only refers to Table 301 and Table 307 as both files and database tables, but also discloses that Table 307 is downloaded by the player. (See, e.g., '076 patent, col. 18:29-31) Indeed, when pressed about PA's reliance on Table 307 in support of its proposed construction during the Markman hearing, Google seemed to have a different answer as to why Table 307 is not helpful to PA—there explaining that even if a file can "go into" a database system, it also must be "capable of being stored and managed by a file-management system." (Tr. at 19-20)
Google asserts that certain arguments that PA made during reexamination proceedings support Google's position that a "file" must be received and stored by a file-management system (and not simply by a database system). (D.I. 159 at 10 (citing D.I. 160, ex. 11 at 8 & id., ex. 9 at 3); Tr. at 16; Google's Markman Presentation, Slide 16) This stretches the prosecution history too far. As PA retorts, in these portions of the prosecution history, PA was distinguishing the prior art on other bases; Google has not pointed to anywhere in the prosecution history where the patentee stated that a file could not be stored and manipulated by a database system. (Tr. at 9-10; PA's Markman Presentation, Slides 8-11)
Fourth and finally, the extrinsic evidence further supports that a "file" is not always something that is stored and manipulated by a file-management system. (D.I. 146 at 4) For example, in support of its argument, Google cites to a dictionary that defines "file" in a way mirroring Google's construction ("any collection of data that is stored and manipulated as a named unit by a file-management system"). (D.I. 147 at ¶ 39 & ex. M (citing Academic Press Dictionary of Science & Technology 826 (1st ed. 1992))) However, that same dictionary provides another definition for "file" that makes no mention of a "file-management system." (Id.) This alternative definition simply describes a "file" as "a collection of items with certain common aspects, organized for a specific purpose and stored or processed as a unit[.]" (Id.) Similarly, other dictionaries from the relevant time period do not require that a file be something that is only stored in and manipulated by a "file-management system." For example, one such dictionary defines "file" as "'a block of information stored on disk, tape, or similar media. A file may contain a program, a document, or a collection of data (such as a mailing list).'" (Id. at ¶ 38 & ex. J (quoting Barron's Dictionary of Computer and Internet Terms (5th ed. 1996))) Another dictionary defines "file" to mean:
A complete, named collection of information, such as a program, a set of data used by a program, or a user-created document. A file is the basic unit of storage that enables a computer to distinguish one set of information from another. A file is the "glue" that binds a conglomeration of instructions, numbers, words, or images into a coherent unit that a user can retrieve, change, delete, save or send to an output device.(Id. at ¶ 38 & ex. K (quoting Microsoft Press Computer Dictionary (3d ed. 1997))) These dictionary definitions also help to underscore that a "file" is not something that must always be associated with a file-management system. (D.I. 146 at 4; Tr. at 7)
PA's expert points to a few more dictionary definitions for "file" that purportedly do not include reference to a "file-management system," (D.I. 147 at ¶ 38), but the attached portions of the dictionaries do not appear to include the pages that define "file[,]" (id., exs. I, L).
With regard to the parties' second dispute (that is, whether a file must constitute data that is a "named" unit), the Court will adopt that portion of Google's construction. In its opening brief, Google argued that the patent specification "confirms that 'files' must be identified by name, distinct from unnamed collections of data[,]" and it cited to numerous examples of the patents: (1) describing files as being requested, downloaded, or stored using a filename; and (2) making reference to named files. (D.I. 159 at 10; see also Tr. at 13-14) In its briefing, PA did not address this dispute at all. During the Markman hearing, PA only raised the issue in response to questioning from the Court. (See, e.g., Tr. at 10) This all suggests that PA's opposition on this point is not especially strong.
PA ultimately explained that its hesitation with respect to the "named" limitation is that it is not sure what the scope of "named" is—for instance, does a file with an identifier amount to a "named" file? (Id. at 10-11, 23-24) Because this issue was not well-argued in the briefs, Google's response to PA's question (about what it means for a file to be "named") is unclear. In light of all of this, the Court will recommend adoption of the "named" portion of Google's construction, and to the extent that there are disputes down the line with respect to what "named" means, the parties may address those during the summary judgment stage of the case. (See id. at 10 (PA's counsel acknowledging that the "named" issue is one "probably [best] taken up on summary judgment"))
For all of the above reasons, the Court recommends that the term "file" be construed as "a collection of data that is stored and manipulated as a named unit by a file-management or database system."
B. "sequencing file" terms
The terms "sequencing file" and "playback session sequencing file" appear in independent claims 1 and 14 of the '178 patent, respectively, while the term "file of data establishing a sequence" is part of the means-plus-function element "a means for receiving and storing a file establishing a sequence" of the independent claims of the '076 patent (collectively, the "sequencing file limitations" or the "sequencing file terms"). (See, e.g., D.I. 146 at 4-5) The use of the disputed term in claim 1 of the '178 patent is representative. Accordingly, this claim is reproduced again below for ease of reference, with the disputed term highlighted:
1. An audio program player comprising:
a communications port for establishing a data communications link for downloading a plurality of separate digital compressed audio program files and a separate sequencing file from one or more server computers,('178 patent, cols. 45:60-46:18 (emphasis added))
a digital memory unit coupled to said communications port for persistently storing said separate digital compressed audio program files and said separate sequencing file, said sequencing file containing data specifying an ordered sequence of a collection of said separate digital compressed audio program files,
an audio output unit including at least one speaker or headset for reproducing said audio program files in audible form perceptible to a listener,
one or more manual controls for accepting commands from said listener, and
a processor for continuously delivering a succession of said audio program files in said collection to said audio output unit in said ordered sequence specified by said sequencing file in the absence of a program selection command from said listener, and for discontinuing the reproduction of the currently playing audio program file and instead continuing the reproduction at the beginning of a listener-selected one of said audio program files in said collection in response to a program selection command from said listener.
The parties' competing proposed constructions for the "sequencing file" limitations are set out in the chart below:
| Term | Plaintiff's ProposedConstruction | Defendant's ProposedConstruction |
|---|---|---|
| "sequencing file""file of data establishing asequence""playback session sequencingfile" | a file of data that identifiesthe order in which audioprogram segments chosen byor for a user are to be played | A file that is received by theplayer, stored, and used bythe processor to both controlplayback of each song in theordered sequence and respondto control commands |
In assessing the respective arguments, it is helpful to first have an understanding of the bigger picture. In other words, why are the parties fighting about this? With its proposed construction, Google's position is that each reference to "sequencing file" in the claims "refers to the same 'sequencing file'"—meaning one single sequencing file is received by the player and stored by the player, and it is that file and that file only that is used to control playback of each song in the ordered sequence, and used to respond to control commands. (D.I. 186 at 1 (emphasis in original); see also D.I. 159 at 4-5; Tr. at 74-75) For its part, PA acknowledges that every claim requires "one sequencing file to be received, to be stored, and its sequence be referenced for use to control playback and to respond to commands[.]" (Tr. at 47; see also id. at 49) Beyond that, however, PA asserts that the claims do not require that the received sequencing file and only that sequencing file be scanned and used in certain algorithmic steps (which steps will be discussed in detail in connection with the next set of terms addressed herein, the "means responsive" limitations). (Id. at 47; D.I. 146 at 2-3, 8-9) Instead, according to PA, the patents allow for the sequence from that received sequencing file to be used to respond to control playback—for example, after it has been copied onto another file. (Tr. at 46-48)
During the Markman hearing, PA explained that the "real battle" with respect to these terms relates to the "means responsive" terms that will be taken up next, (Tr. at 46), and the parties' dispute will be clearer in the discussion of that term set.
The Court ultimately concludes that PA's proposed construction for the sequencing file limitations is the correct one. To explain why this is so, the Court will address, in turn, the claim language, the patent specification and the prosecution history.
1. Claim Language
PA argues that the sequencing file limitations should be construed based on what such a file actually is (a file of data that identifies the order in which audio program segments chosen by or for a user are to be played), instead of construing the term based on how a sequencing file may be used. (Tr. at 32) To that end, PA points out that the use limitations in Google's construction are found explicitly in the surrounding claim language, where applicable. (D.I. 146 at 5; Tr. at 32) Claim 1 of the '178 patent, for example, recites a sequencing file that is: (1) received by the player (i.e., the player has a communications port for "downloading" the sequencing file); (2) stored at the player; and (3) used to control playback (i.e., the player has a processor for delivering audio program files "in said ordered sequence" specified by "said sequencing file" and for "continuing the reproduction at the beginning of a listener-selected one of said audio program files"). (See PA's Markman Presentation, Slide 36) In PA's view, the use limitations included in Google's proposal should not be included in the construction for the sequencing file limitations, because the claims recite them expressly where they are required, and because the patents make certain other references to sequencing files that are not limited in the manner suggested by Google's construction. (D.I. 146 at 5-6; Tr. at 32-33, 44-46)
The Court notes that in the Apple litigation, the Eastern District of Texas Court used a similar rationale in construing the "sequencing file" terms in a manner similar to that proposed here by PA. (D.I. 147, ex. D at 20-21)
Google, for its part, asserts that the claim language demonstrates that the same sequencing file received by the player must be stored by the player, used to control playback of each song in the ordered sequence and used to respond to control commands. (D.I. 186 at 1) In support, Google points out that the claims "recit[e] 'sequencing file' the first time the term appears in the claims, and then recit[e] 'said [] sequencing file' in every other instance. Accordingly, each 'sequencing file' in the claims refers to the same 'sequencing file.'" (Id. (certain emphasis in original); see also D.I. 159 at 5 ("The references to 'said sequencing file' [in the claims] indicate that it is the same file that is subject to each aspect of the claim."))
When one looks carefully at the claim language, however, it becomes clear that the claims do more than simply make repeated references to "said sequencing file." For instance, as to the player recited in claim 1 of the '178 patent, certain steps require a processor for delivering audio program files "in said ordered sequence specified by said sequencing file in the absence of a program selection command from said listener[.]" ('178 patent, col. 46:11-13 (emphasis added)) Similarly, the player claimed in claim 14 of the '178 patent includes an "audio playback unit for automatically and continuously reproducing said audio program files in said collection in the ordered sequence specified by said playback session sequencing file[.]" (Id., col. 48:28-32 (emphasis added)) And claim 1 of the '076 patent claims a player with a "means for receiving and storing a file of data establishing a sequence" and "means for continuously reproducing said program segments in the order established by said sequence in the absence of a control command[.]" ('076 patent, col. 46:18-19, 24-26 (emphasis added)) These references to the use of a "sequence" from the sequencing file do not explicitly require that the sequence may be found only on that sequencing file at the time the sequence is used. They simply require that the sequence itself is originally found on the sequencing file referenced in the claims.
With the claim language both: (1) otherwise including use limitations like the ones that Google seeks to include in the construction for the "sequencing file" limitations; and (2) seeming to require that, for some of the steps, "[a]ll you have to use is the sequence specified by that [received] sequencing file[,]" (Tr. at 49 (emphasis added); see also id. at 103-04), that language thus appears to more closely support PA's proposal.
2. Patent Specification
PA also heavily relies on the specification in support of its proposed construction. It cites to portions of the specification that purportedly demonstrate that in one embodiment, the player downloads a sequencing file (Table 307) and then uses the sequence from Table 307 to create a separate sequencing file ("Selections File 351") that was itself not received by the player from the host server. Instead, PA explains, Selections File 351 was compiled directly on the player from another sequencing file (i.e., Table 307). (D.I. 146 at 2-3, 5-6; D.I. 176 at 1-3; Tr. at 33-34) PA argues that Selections File 351 is thus an example of a sequencing file that is not received by the player, but is nevertheless used by the player to influence playback; this shows, according to PA, that Google's construction (which requires that a "sequencing file" must always have been downloaded by the player) is incorrect. (D.I. 176 at 1 (PA contending that because this embodiment makes reference to a sequencing file that is not downloaded onto the player, it helps explain why "the naked term 'sequencing file' by itself does not have the[] limitations [suggested by Google]"); see also Tr. at 34)
PA further explains that its position here (that Selections File 351 is not downloaded to the player, and instead is created on the player) must be correct, because were both sequencing files (Table 307 and Selections File 351) downloaded by the player, this would lead to an unnecessary redundancy. In other words, "[i]f final Selections File 351 was downloaded . . . there would be no reason to also redundantly download a separate Recommended Schedule Table 307." (D.I. 176 at 3; see also Tr. at 88 (PA emphasizing that it "doesn't make any sense at all" for the specification to be describing both sequencing files 307 and 351 as being downloaded to the player))
For its part, Google agrees with PA that Table 307 and Selections File 351 are not both downloaded. (D.I. 186 at 3) But what Google argued in its briefing was that: (1) Table 307 is not a "file" at all, but instead a "relational database[;]" and (2) Table 307 "resides on the server (Fig. 4) and is not downloaded, stored, or used on the player." (Id. at 2 (emphasis added)) Instead, Google's position was that "Selections File 351 is plainly downloaded; Table 307 is not." (Id. at 3 (emphasis added)) Google's position is wrong, for the reasons set out below.
Both parties' experts also agree at least on this point. PA's expert, Kevin C. Almeroth, Ph.D., explains that if Selections File 351 was compiled on the server and downloaded to the player, "there would be no reason to also download recommended Schedule File 307, for which the only disclosed purpose is to provide an initial recommended sequence for compiled Selections File 351." (D.I. 177 at ¶ 21) Google's expert, Ketan Mayer-Patel, Ph.D., similarly points out that "[a] person of ordinary skill in the art would understand that there is no need to download both Table 307 and Selections File 351." (D.I. 188 at ¶ 8)
By the time of the Markman hearing, Google seemed to back away from the absolute position that Table 307 is not downloaded, contending instead that "[w]hether 307 is also downloaded is more of an open question" and that "the specification suffers from some lack of specificity" in that regard. (Tr. at 84)
First, the specification clearly refers to the structure that is Table 307 as, inter alia, a file. At differing points, the specification names that structure as both a "schedule file" and a "Schedule Table[.]" (See, e.g., '076 patent, cols. 12:5; 17:59)
This point was also touched on above with respect to the "file" term.
Second, contrary to Google's position, the specification makes it very clear that Table 307 is indeed downloaded to (i.e., received by) the player. To that end, the specification explicitly states that "the recommended Schedule Table 307 [] is transferred to the subscriber, along with program segments, during the download transfer." (Id., col. 18:29-31 (emphasis added); see also id., col. 21:61-62 (referring to the "output Schedule Table 307") (emphasis added); id., col. 27:15 (referring to the "Schedule 307 downloaded to the player"); PA's Markman Presentation, Slide 17) The specification also makes more implicit references to the fact that Table 307 is received by the player. To that end, the patents refer to what must be Table 307—i.e., a file with a recommended sequence of program segments—as being downloaded to the player. For example, the specification explains that: (1) "the recommended order and the identification of the program files making up an individual playback session are stored in a session schedule file (to be described in detail in connection with FIG. 5)[;]" and (2) the "player 103 downloads the session schedule file[.]" (See id., col. 7:1-11 (emphasis added)) In the next column, the specification indicates that "[t]he data downloaded includes a recommended program sequence file which provisionally identifies the order in which downloaded program segments are to be played[.]" (Id., col. 8:39-41 (emphasis added)) Meanwhile, the specification never states that Selections File 351 is downloaded to the player from the server. (See D.I. 176 at 2; Tr. at 35)
It is clear from the specification that Schedule File/Table 307 "contains the recommended sequence of program segments for the next playback session[.]" ('076 patent, col. 17:59-61 (emphasis added); see also id., col. 18:29 (explaining that the host server adds various program segments tailored to the subscriber's known preferences to "produc[e] the recommended Schedule Table 307") (emphasis added); D.I. 186 at 2 (Google acknowledging that Schedule File/Table 307 "contains 'the recommended sequence of program segments for the next playback session'"); Tr. at 35 (PA's counsel pointing out that Table 307 contains the recommended sequence))
PA notes that the specification describes in detail what is being downloaded, and in each case it refers to only a single sequencing file being downloaded that is either explicitly identified as Table 307, or described as containing a recommended sequence. (Tr. at 35; PA's Markman Presentation, Slides 22-23) That seems correct.
Third, the specification describes Selections File 351 as being compiled from Table 307 and it strongly suggests that this compilation happens on the player. The specification states:
As described in more detail later in connection with FIGS. 4 and 5, the sequence of program segments to be presented to the user is formed into a schedule file (seen at 307 in FIG. 4) consisting of a sequence of program segment identification numbers which are used to compile a sequencing file, called the selections file, illustrated at 351 in FIG. 5, which contains more detailed information about the sequence of events which occur during playback.('076 patent, col. 12:3-10) While it is true that this excerpt does not expressly say that the compiling of Selections File 351 file takes place on the player, (see D.I. 159 at 5), the Court agrees with PA that all signs point to that being the case.
For one thing, as explained above, everyone agrees that it would not make sense for two sequencing files (both Table 307 and Selections File 351) to be downloaded to the player. Additionally, as PA points out, Figure 4 seems to "describe[] all the different data structures that are stored on the host server and created on the host server" and, while it discloses Table 307, it does not disclose Selections File 351. (Tr. at 34-35; see also D.I. 176 at 2)
Moreover, the specification notes that Selections File 351 is compiled from Table 307, as described above, and then further explains that Selections File 351 "follows" a sequence that is created by the host server and downloaded to the player (i.e., Table 307):
The playback operation itself continues from the designated playback point in the selections file (seen at 351 in FIG. 5) which
follows a program sequence initially created by the host server and downloaded with the program segments themselves, and then (optionally) modified by the addition, deletion and re-sequencing of segment identifiers as discussed earlier in connection with step 211 in FIG. 2 .('076 patent, col. 12:21-27 (emphasis added); see also PA's Markman Presentation, Slide 30; Tr. at 37-38) The earlier discussion referenced in this passage (i.e., the discussion of step 211 of Figure 2) explains that:
The data downloaded [to the player] includes a recommended program sequence file which provisionally identifies the order in which downloaded program segments are to be played, with the initial selection and sequence being established based on user preference data by the download compilation processing mechanism seen at 151 at the server.('076 patent, col. 8:39-57 (emphasis added)) Figure 2 of the patent, which depicts a flow chart of the "information distribution functions" of the invention, (see id., col. 4:1-3), in turn depicts certain of these steps:
Before a playback session begins, as indicated at 211 , the subscriber has the opportunity to review and alter the provisional program selections and sequence established as a default by the downloaded information from the server. Utilizing the programming data and a utility program previously supplied by the server, the subscriber may alter the selection and sequence of program materials to be played . . . .
At the request of the user, the sequence of programming defined by the program sequence file (the selections file illustrated at 351 in FIG. 5) is then reproduced for the listener.
Image materials not available for display.
Fig. 2
Taken together, these portions of the specification show that it is Table 307, with its recommended sequence of programs, that is downloaded at step 207 of Figure 2. Following that download, the subscriber may then edit (on the player) that downloaded program sequence (step 211 of Figure 2). What results from such editing is the final sequence of programming defined in Selections File 351, which is ultimately "reproduced for the listener." (Id., col. 8:54-57; see also id., col. 12:21-27; D.I. 176 at 3 (PA noting that "Selections File 351 contains a final sequence that is disclosed as being edited after Schedule Table 307 is downloaded. See Step 211 of Fig. 2[.]"))
In sum, the Court agrees with PA that the specification discloses: (1) a "sequencing file" with a recommended sequence that is created on the host server and downloaded by the player; and (2) another "sequencing file" containing the final sequence that is compiled from the first sequencing file, after optional modification by the subscriber, on the player. This, in turn, supports PA's proposal, which: (1) does not require a sequencing file to be something that in all cases has been received by the player; and (2) does not limit the claims to requiring that the same received sequencing file—and that file only—must be used to "control both playback of each song in the ordered sequence and respond to control commands."
3. Prosecution History
Google contends that the prosecution history supports its construction. (D.I. 159 at 6; Tr. at 68-69) To that end, the Federal Circuit has explained that "[t]he prosecution history limits the interpretation of claim terms so as to exclude any interpretation that was disclaimed during prosecution." Southwall Techs., Inc. v. Cardinal IG Co., 54 F.3d 1570, 1576 (Fed. Cir. 1995). Google's argument is premised on the following portions of the prosecution history, (D.I. 159 at 6-7):
• During the reexamination proceeding for the '178 patent, the patent owner explained with respect to "sequencing file":
G. Proper Interpretation of "Sequencing File" in Light of Specification and Prosecution History
In light of the specification and file history excerpts quoted above, the claim term "sequencing file" (which appears in all '178 patent claims and was not a term of art in 1996) is readily understandable to one of skill in the art as a file that is received by the player, stored, and used by the processor to both control playback of each song in the ordered sequence and respond to control commands. [12:16-19; 12:27-28; 34:17-19] It is used to determine, for instance, what song is to be played next if the user wishes to skip forward or back or select a specific song. It is not simply a playlist, but rather a file of data that the player references when the player is deciding what audio segment to play in response to the presence or absence of a control command. (D.I. 160, ex. 11 at 8 (emphasis added))
• [T]he term "sequencing file" of independent claim 1 and the term "playback session sequencing file" of independent claim 14, when interpreted in light of the '178 patent specification and file history, should be interpreted to mean "a file that is received by the player and used by the processor to both control playback of each song in the ordered sequence and respond to control commands." The claimed sequencing file is received by the player and used by the processor to both control playback of each song in the ordered sequence and respond to control commands. [12:16-19, 34:17-23] (Id. at 5 (emphasis in original))
• During the reexamination for the '178 patent, the patentee explained that prior art "does not disclose that the same 'play list' the Examiner equates with the claimed 'sequencing file' is downloaded, persistently stored and used to playback similarly downloaded and persistently stored audio files in the way claim 1 requires." (Id., ex. 12 at 11 (emphasis in original))
• During the reexamination for the '178 patent, Dr. Almeroth submitted a declaration explaining that the opposing expert's declaration "does not state that the 'import function' in the [prior art] discloses downloading a sequencing file and then using that file for playback by the [prior art system]." (Id., ex. 13 at 7)
• During prosecution, the applicants of the '076 patent stated that "[i]n claims 1-17, as amended, applicants set forth an audio program player which stores a collection of individual program segments and which further receives and stores a file of data which specifies the order in which those program segments are scheduled to be reproduced by the player." (D.I. 187, ex. A at 2 (emphasis added); see also id. at 3)
• During prosecution, the applicants of the '076 patent stated that "[c]laim 1 makes it clear that the stored 'program segments' are different from the 'file of data' which is received and stored and which establishes a sequence in which the separately claimed program segments are scheduled to be reproduced." (Id., ex. B at 3 (emphasis in original); see also id. at 4, 5; id., ex. C at 2, 5, 6, 7; id., ex. D at 14, 16-17, 18-19, 24)
At first blush, Google's prosecution history argument does appear to be compelling. But PA has two good responses to Google's argument.
First, PA asserts that in its prosecution history statements, PA was not intending to generally define any and all "sequencing file[s]." (D.I. 176 at 5) Rather, PA's statements above were "characterizing the use of a particular claimed sequencing file as dictated by explicit limitations of a specific claim[.]" (Id. (emphasis added)) To that end, PA points out portions of the prosecution history that at times seem to explain what a sequencing file is generally—i.e., a file containing data specifying an ordered sequence of a collection of the downloaded audio program files. (D.I. 177, ex. 3 at 5; see also, e.g., id., Appendix A at 10 n.1 (during prosecution, patentee explaining that a sequencing file is "a file of data which establishes the sequence in which program segments are scheduled to be reproduced") (emphasis omitted)) And PA is also correct that other portions of the '178 patent's prosecution history do refer to the "claimed" sequencing file or the sequencing file "of independent claim 1" and "independent claim 14" of that patent—with the patentee there explaining that these specific claimed sequencing files should be interpreted to mean a file that has the use attributes identified in Google's proposed construction (and that are expressly found in surrounding limitations). For example, during reexamination proceedings for the '178 patent, the patentee referred to the "sequencing file" of the independent claims and explained that "[t]he claimed sequencing file is received by the player and used by the processor to both control playback of each song in the ordered sequencing and respond to control commands." (D.I. 177, Appendix A at 7)
As explained above, in the claims that contain the sequencing file terms, the surrounding claim language explicitly sets out the use requirements. And thus the prosecution history statements highlighted by Google could reasonably be seen as being "directed to the combination of explicit limitations directed to the sequencing file found in the claims[.]" (D.I. 176 at 6; see also Tr. at 51-53, 57, 63) These statements may well not have been intended to define a "sequencing file" generally. The Court agrees with PA that while the prosecution history could be interpreted as Google argues here, one could also reasonably interpret it in line with PA's explanation. See, e.g., Golight, Inc. v. Wal-Mart Stores, Inc., 355 F.3d 1327, 1332 (Fed. Cir. 2004) (finding no clear or express statement by the patentees defining "rotating" as requiring 360 degrees of rotation because while the relevant statements in the prosecution history could be "arguably subject to the interpretation [the defendant] gives them, [they can] also be reasonably understood as applying only to those claims [] that explicitly recite that rotation must be 'through greater than 360°.' . . . Because the statements in the prosecution history are subject to multiple reasonable interpretations, they do not constitute a clear and unmistakable departure from the ordinary meaning of the term 'rotating.'")
Second, PA points to the IPR proceeding. During that process, Google submitted that the sequencing file limitations should be construed to mean "'file of data that identifies the order in which audio program segments are to be played and that may contain information about the sequence of events that occur during playback.'" (D.I. 147, ex. E at 8 (citations omitted)) Google never argued before the PTAB that the proper construction of these terms required the use limitations that it now seeks to import into its construction. (D.I. 146 at 6; Tr. at 32, 63) Yet here, Google argues that "[b]ased on [the patentee's] definitional statements and arguments during prosecution and reexamination, Plaintiff has affirmatively and unequivocally limited the claimed 'sequencing file' to the same file that is received from outside the player, stored in a non-volatile memory ('persistently stored'), and used to control playback and respond to commands." (D.I. 159 at 8 (emphasis added)) If the patentee's statements in the IPR proceeding were so affirmative and unequivocal on the point at issue (i.e., the incorporation of the use limitations into the "sequencing file" terms), how could Google have advanced a construction for the terms in the IPR that did not include those limitations?
Google defends its differing proposals by noting that during the IPR proceeding, the claim terms were to be interpreted according to their broadest reasonable interpretation ("BRI"), in light of the patent specification in which they appear. In re Cuozzo Speed Techs., LLC, 793 F.3d 1268, 1275-79 (Fed. Cir. 2015), aff'd, Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131 (2016). But that fact would not justify Google's shifting positions in the two proceedings.
Pursuant to a recent rule change, beginning on November 13, 2018, the PTAB began to construe claims (including in IPR proceedings) using the same Phillips claim construction standard that is used to construe claims in a civil action in federal district court. See Changes to the Claim Construction Standard for Interpreting Claims in Trial Proceedings Before the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340 (Oct. 11, 2018) (to be codified at 37 C.F.R. pt. 42). The PTAB thus utilized the BRI standard during the IPR proceeding relevant to this case, but no longer uses that standard.
After all, for a statement to constitute prosecution history disclaimer, it must amount to a clear and unmistakable disclaimer. (Tr. at 64; D.I. 176 at 8) This is true in both federal district court proceedings and in IPR proceedings. See, e.g., Arendi S.A.R.L. v. Google LLC, 882 F.3d 1132, 1135 (Fed. Cir. 2018) (explaining, in an appeal of the PTAB's decision in an IPR proceeding where the PTAB held that no prosecution disclaimer had occurred, that "a disclaimer must be clear and unmistakable"); Thorner v. Sony Comput. Entm't Am. LLC, 669 F.3d 1362, 1366-67 (Fed. Cir. 2012) (noting, in an appeal from a district court litigation, that "to constitute disclaimer, there must be a clear and unmistakable disclaimer"). The Federal Circuit has explained that "when a prosecution argument is subject to more than one reasonable interpretation, it cannot rise to the level of a clear and unmistakable disclaimer." Aylus Networks, Inc. v. Apple Inc., 856 F.3d 1353, 1363 (Fed. Cir. 2017) (internal quotation marks and citation omitted). Therefore, if the patentee made statements regarding the sequencing file limitations during prosecution that amount to clear and unmistakable disclaimer—meaning that the only reasonable interpretation of such statements is that they served to import the use limitations into the claim terms at issue—then Google could not have advanced the constructions it did for these terms in the IPR proceeding (i.e., constructions that did not include those use limitations). (D.I. 176 at 9; Tr. at 64-65)
Moreover, when the PTAB construes claims under the BRI standard during an IPR proceeding, it is not as if the prosecution history is irrelevant. Indeed, the Federal Circuit has explained that during an IPR proceeding, when a claim is given its BRI in light of the patent specification, such "specification, together with [the patent's] prosecution history, constitutes intrinsic evidence to which the Board gives priority when it construes claims." WesternGeco LLC v. ION Geophysical Corp., 889 F.3d 1308, 1323 (Fed. Cir. 2018); see also Arendi, 882 F.3d at 1135 (explaining that, in appeal from IPR decision applying the BRI standard, "[i]n construing patent claims, a court should consult the patent's prosecution history so that the court can exclude any interpretation that was disclaimed during prosecution") (internal quotation marks and citation omitted); cf. Tempo Lighting, Inc. v. Tivoli, LLC, 742 F.3d 973, 977 (Fed. Cir. 2014) (explaining, in an appeal of the PTAB's decision in an inter partes reexamination proceeding, "[a]dditionally, the prosecution history, while not literally within the patent document, serves as intrinsic evidence for purposes of claim construction. This remains true in construing claims before the PTO").
This all signals to the Court that the patentee's statements regarding these terms in the prosecution history are subject to more than one reasonable interpretation. And thus, it indicates that those statements were not clear enough to serve as the type of disclaimer Google now suggests.
4. Conclusion
In light of the above, the Court recommends that the sequencing file limitations be construed to mean "a file of data that identifies the order in which audio program segments chosen by or for a user are to be played."
Google suggests that PA's reading of what a "sequencing file" refers to would render the term indefinite. (D.I. 186 at 2 n.2; Tr. at 83) Google may raise this argument during summary judgment, but at this time, the issue has not been fully briefed and is not yet ripe for resolution.
C. "means responsive" terms
The "means responsive" terms constitute three means-plus-function limitations in claims 1-3 of the '076 patent, governed by 35 U.S.C. § 112(6). (See, e.g., D.I. 146 at 6; id., Appendix A at Refs. 3, 4, 5) For ease of reference, the Court reproduces these claims below, with the disputed terms highlighted:
1. A player for reproducing selected audio program segments comprising, in combination:('076 patent, col. 46:13-33 (emphasis added))
means for storing a plurality of program segments, each of said program segments having a beginning and an end,
means for receiving and storing a file of data establishing a sequence in which said program segments are scheduled to be reproduced by said player,
means for accepting control commands from a user of said player, means for continuously reproducing said program segments in the order established by said sequence in the absence of a control command,
means for detecting a first command indicative of a request to skip forward, and
means responsive to said first command for discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of a program segment which follows said currently playing program in said sequence.
2. A player as set forth in claim 1 further comprising means for detecting a second command indicative of a request to skip backward, and(Id., col. 46:34-41 (emphasis added))
means responsive to a single one of said second commands for discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of said currently playing program.
3. A player as set forth in claim 2 further comprising means responsive to the detection of two consecutive ones of said second commands for discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of a program segment which precedes the currently playing program segment.(Id., col. 46:42-48 (emphasis added))
The parties' competing proposed constructions for the "means responsive" limitations are set out in the chart below, with the main disputed points noted by bold, underlined language:
| Term | Plaintiff's ProposedConstruction | Defendant's ProposedConstruction |
|---|---|---|
| "means responsive to saidfirst command fordiscontinuing thereproduction of the currentlyplaying program segment andinstead continuing thereproduction at the beginningof a program segment whichfollows said currently playingprogram in said sequence"(hereinafter, "skipcommand")('076 patent, claim 1) | Function: "in response to a'Skip' command,discontinuing thereproduction of the currentlyplaying program segment andinstead continuing thereproduction at the beginningof a program segment whichfollows said currently playingprogram in said sequence."The structure correspondingto the claimed function is thefollowing structure andequivalents thereof:A general purpose computerprogrammed to perform thealgorithm that is illustrated inthe flow chart of Figure 3 atitems 269 and 235 and more | Function: In response to a['Skip'/single 'Back'/twoconsecutive 'Back'/ 'Back']command[s], discontinuingthe [reproduction/translation]of the currently playingprogram segment and insteadcontinuing the[reproduction/translation] atthe beginning of [a programsegment which follows saidcurrently playing program insaid sequence/said currentlyplaying program/a programsegment which precedes thecurrently playing programsegment/the next programsegment in said sequence]. |
| fully described at column 15,lines 21 to 25 and column 34,line 28 to column 35, line 48.Specifically, this algorithmincludes the following steps:1. scanning forward in thesequence established by thesequencing file to locate thenext Selection_Record of theappropriate LocType;or, alternatively,1. scanning forward in asequencing file to locate thenext Selection_Record of theappropriate LocType;2. resetting the CurrentPlayvariable to the record numberof that Selection_Record; and3. fetching and playing theprogram segment identifiedby the ProgramID containedin the new Selection_Record.A LocType is an identifierthat indicates acharacteristic of a selectionrecord, for example, aplayable content selectionrecord. | Structure: A general purposecomputer programmed toperform the algorithm that isillustrated in the flow chart ofFigure 3 at items 269 and 235and described at column 15,lines 21 to 25 and column 34,line 28 to column 35, line 48.Specifically, this algorithmincludes the following steps:(1) scanning forward in thereceived sequencing file tolocate the nextSelection_Record of theappropriate LocType;(2) resetting the CurrentPlayvariable to the record numberof that Selection_Record; and(3) fetching and playing theprogram segment identifiedby the ProgramID containedin the new Selection_Record.No construction necessaryfor LocType, oralternatively:A LocType is a single bytecharacter and an identifierthat indicates acharacteristic of a selectionrecord. | |
|---|---|---|
| "means responsive to a singleone of said second commandsfor discontinuing thereproduction of the currentlyplaying program segment andinstead continuing thereproduction at the beginningof said currently playingprogram" | The function is "in responseto a single 'Back' command,discontinuing thereproduction of the currentlyplaying program segment andinstead continuing thereproduction at the beginningof said currently playingprogram." | Function: In response to a['Skip'/single 'Back'/twoconsecutive 'Back'/ 'Back']command[s], discontinuingthe [reproduction/translation]of the currently playingprogram segment and insteadcontinuing the[reproduction/translation] atthe beginning of [a program |
| (hereinafter, "single skip backcommand")('076 patent, claim 2) | The structure correspondingto the claimed function is thefollowing structures andequivalents thereof:A general purpose computerprogrammed to perform thealgorithm that is illustrated inthe flow chart of Figure 3 atitems 269 and 235 and morefully described at column 15,lines 49 to 59. Specifically,this algorithm includes thefollowing steps:1. if the currently playingprogram segment has playedfor a predetermined amountof time, resetting theplayback position to thebeginning of the programsegment; and2. playing the programsegment from its beginning.A LocType is an identifierthat indicates acharacteristic of a selectionrecord, for example, aplayable content selectionrecord. | segment which follows saidcurrently playing program insaid sequence/said currentlyplaying program/a programsegment which precedes thecurrently playing programsegment/the next programsegment in said sequence].Structure: A general purposecomputer programmed toperform the algorithm that isillustrated in the flow chart ofFigure 3 at items 267, 269,and 235 and described atcolumn 15, lines 49 to 59.Specifically, this algorithmincludes the following steps:(1) if the currently playingprogram segment has playedfor a predetermined amountof time after the start timerecorded in a usage log file,resetting the playbackposition to the beginning ofthe program segment; and(2) playing the programsegment from its beginning.No construction necessaryfor LocType, oralternatively:A LocType is a single bytecharacter and an identifierthat indicates acharacteristic of a selectionrecord. |
|---|---|---|
| "means responsive to thedetection of two consecutiveones of said secondcommands for discontinuingthe reproduction of thecurrently playing program | The function is "in responseto two consecutive 'Back'commands, discontinuing thereproduction of the currentlyplaying program segment andinstead continuing the | Function: In response to a['Skip'/single 'Back'/twoconsecutive 'Back'/ 'Back']command[s], discontinuingthe [reproduction/translation]of the currently playing |
| segment and insteadcontinuing the reproduction atthe beginning of a programsegment which precedes thecurrently playing programsegment"(hereinafter, "double skipback command"('076 patent, claim 3) | reproduction at the beginningof a program segment whichprecedes the currently playingprogram segment."The structure correspondingto the claimed function is thefollowing structures andequivalents thereof:A general purpose computerprogrammed to perform thealgorithm that is illustrated inthe flow chart of Figure 3 atitems 269, 235, 261, 262, and278 and more fully describedat column 15, lines 49 to 59and column 34, line 28 tocolumn 35, line 53.Specifically, this algorithmincludes the following steps:1. in response to a first 'Back'command, if the currentlyplaying program segment hasplayed for a predeterminedamount of time, resetting theplayback position to thebeginning of the programsegment and playing theprogram segment from itsbeginning;2. in response to a second'Back' command, if thecurrently playing programsegment has not yet playedfor said predeterminedamount of time, scanningbackward in the sequenceestablished by the sequencingfile to locate the previousSelection_Record of theappropriate LocType;or, alternatively: | program segment and insteadcontinuing the[reproduction/translation] atthe beginning of [a programsegment which follows saidcurrently playing program insaid sequence/said currentlyplaying program/a programsegment which precedes thecurrently playing programsegment/the next programsegment in said sequence].Structure: A general purposecomputer programmed toperform the algorithm that isillustrated in the flow chart ofFigure 3 at items 267, 269,235, 261, 262, and 278 anddescribed at column 15, lines49 to 59 and column 34, line28 to column 35, line 53.Specifically, this algorithmincludes the following steps:(1) in response to a first"Back" command, if thecurrently playing programsegment has played for apredetermined amount oftime after the start timerecorded in a usage log file,resetting the playbackposition to the beginning ofthe program segment, andplaying the program segmentfrom its beginning;(2) in response to a second"Back" command, if thecurrently playing programsegment is near itsbeginning, scanningbackward in the receivedsequencing file to locate the |
|---|
| 2. in response to a second'Back' command, if thecurrently playing programsegment has not yet playedfor said predeterminedamount of time, scanningbackward in a sequencing fileto locate the previousSelection_Record of theappropriate LocType;3. resetting the CurrentPlayvariable to the record numberof that Selection_Record; and4. fetching and playing theprogram segment identifiedby the ProgramID containedin the new Selection_Record.A LocType is an identifierthat indicates acharacteristic of a selectionrecord, for example, aplayable content selectionrecord. | previous Selection_Record ofthe appropriate LocType;(3) resetting the CurrentPlayvariable to the record numberof that Selection_Record; and(4) fetching and playing theprogram segment identifiedby the ProgramID containedin the new Selection_Record.No construction necessaryfor LocType, oralternatively:A LocType is a single bytecharacter and an identifierthat indicates acharacteristic of a selectionrecord. |
|---|
1. Skip Command
With respect to the skip command, found in claim 1 of the '076 patent, the function for this means-plus-function term is not in dispute, and is reflected in the chart above. As for the corresponding structure for this term, the parties have two disputes. First, the parties dispute whether the same "received sequencing file" must itself be continuously used for playback control (as Google argues), or whether that received sequencing file can be used to obtain a sequence that is then used to create another sequencing file that is further acted on by the controls (as PA argues). (See D.I. 146 at 7; D.I. 159 at 17; Tr. at 90 (Google's counsel explaining that the "main [] dispute" regarding this term is "whether the scanning forward to locate the next record in response to a user commanding a skip . . . has to be in the received sequencing file") (emphasis added)) Second, the parties dispute whether the structure should include a definition of the term "LocType[,]" and if so, what that definition should be. (D.I. 146 at 11-13; D.I. 159 at 21-22) The Court will take up these disputes in turn.
The parties also have this dispute with respect to the the double skip back command, and the Court's resolution here will also apply to that term.
The parties have this dispute with respect to each of the means responsive limitations, and the Court's resolution here will also apply to the other two such terms.
a. Must the scanning forward take place in the "received" sequencing file?
At the outset, the Court notes that both parties agree that the corresponding structure for the skip command includes scanning Selections File 351 in order to skip forward. (See D.I. 176 at 1; D.I. 146, Appendix A at Ref. 3; '076 patent, cols. 34:28-35:48) However, the parties disagree as to whether this file was compiled on the player from another downloaded sequencing file (PA's view) or was received from outside the player (Google's view). If Selections File 351 was received from outside the player, that supports Google's position that the same sequencing file is received by the player, stored, and scanned during playback. But if Selections File 351 was compiled on the player, that supports PA's position that the player does not have to keep referencing only one particular received sequencing file over and over, but can instead use the received file by accessing it and obtaining/copying its sequence, and then compiling another sequencing file with the copied sequence. In conjunction with their respective positions, PA asserts that the scanning forward step should be construed to require "scanning forward in a sequencing file" or, alternatively, "scanning forward in the sequence established by the sequencing file[,]" (D.I. 146 at 7 (emphasis added)), whereas Google asserts that it should be construed such that the scanning forward step must occur in the same sequencing file that was "received" by the player, (D.I. 159 at 17).
As described above in connection with the "sequencing file" limitations, the embodiment described in the specification teaches that a sequencing file with a recommended sequence (Table 307) is created on the host server and downloaded to the player—and that another sequencing file containing the final sequence (Sequencing File 351) is created on the player, using the data of the received sequencing file to control playback. (See D.I. 176 at 2-3) The Court will not here repeat the analysis that led it to that conclusion, as that analysis has already been set out in some detail in the "sequencing file" section. It is simply worth noting that this conclusion strengthens PA's position as to the correct outcome regarding this dispute.
The Court also will assess three other arguments made in the parties' briefs with regard to this "received sequencing file" issue. The outcome as to each also supports PA's position.
First, PA rightly points out that the claim language "never requires only scanning or using the 'received sequencing file'" and instead simply refers to using the "sequence" from that file. (D.I. 146 at 8; see also Tr. at 48-49, 103) Indeed, claim 1 of the '076 patent recites, inter alia, "means for receiving and storing a file of data establishing a sequence in which said program segments are scheduled to be reproduced by said player," "means for continuously reproducing said program segments in the order established by said sequence[,]" and then—in response to a command to skip forward (the limitation at issue here): "means responsive to said first command for discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of a program segment which follows said currently playing program in said sequence." ('076 patent, col. 46:13-33 (emphasis added))
Second, Google's argument regarding the import of the prosecution history seems off base. Google asserts that several of the patentee's statements in the prosecution history mandate its proposal. (Tr. at 90 (citing Google's Markman Presentation, Slide 22)) But PA retorts that Google's proposed construction is actually much more narrow than the import of the patentee's prosecution history statements. PA argues that during the prosecution history, when the patentee made statements to the effect that the claimed sequencing file is "used by the processor to both control playback of each song in the ordered sequence and respond to control commands[,]" (D.I. 177, ex. 3 at 5 (emphasis added)), the patentee did not mean that the processor must only continue to reference the actual received sequencing file, (D.I. 176 at 4; Tr. at 99-101). Rather, according to PA, "[a] processor can use the received sequencing file to control playback and respond to control commands by referencing the file . . . to obtain the sequence used for control and playback but not continue to reference only that file." (Id. at 100-01 (emphasis added)) So under PA's reading, one can "use" the file by accessing it and obtaining its sequence (i.e., a sequence that will later be scanned), but one does not have to keep referencing only one particular sequencing file over and over. (Id. at 103)
The Court finds PA's position to be reasonable and supported by portions of the file history. For example, during reexamination of the '178 patent, the patentee explained that:
The '178 specification describes in detail how the exemplary preferred embodiment personal audio player implementation uses the sequencing file's ordered sequence of program segment identifiers to sequence events which occur during playback and to control the playback session and navigation within the playback session. Figure 5 shows an example non-limited preferred embodiment sequencing file and how the personal audio player processor dynamically uses the sequencing file to both control playback of each song in the ordered sequence and to change selections in response to listener-inputted control commands. For example, the '178 specification beginning at 34:14 et seq. describes
how the audio player uses the downloaded sequencing file format and associated player processor to permit the listener to skip forward, backward, etc.(D.I. 177, ex. 3 at 6 (emphasis added); PA's Markman Presentation, Slide 65) As PA notes, this explanation allows for the player to use the sequencing file's "ordered sequence" to control the playback session, but it does not necessarily require the received file to always be scanned as part of that process. And the citation to column 34 of the '178 patent in the above excerpt also supports the idea that the player uses the format of the downloaded sequencing file—i.e., its sequence—to skip forward. (Tr. at 102; D.I. 177 at ¶ 42)
This reading of the import of the prosecution history statement is in harmony not only with the claim language, but also with the embodiment described in the specification. With respect to playback, the specification explains that "[t]he playback operation itself continues from the designated playback point in the selections file (seen at 351 in FIG. 5) which follows a program sequence initially created by the host server and downloaded with the program segments themselves, and then (optionally) modified by the addition, deletion and re-sequencing of segment identifiers as discussed earlier in connection with step 211 in FIG. 2." ('178 patent, col. 12:27-33 (emphasis added)) This description aligns with PA's position that the downloaded sequencing file is used to control playback by providing the sequence for playback, and not necessarily by being continually scanned itself. (PA's Markman Presentation, Slide 67)
Third, PA made persuasive points about Google's positions during the IPR proceeding. For example, it is undisputed that Google submitted to the PTAB a construction for the term at issue that did not require scanning forward to happen in the "received" sequencing file. (D.I. 146 at 9; PA's Markman Presentation, Slide 69; D.I. 177, ex. 1 at 13-14; Tr. at 104) And it appears to also be undisputed that in the IPR, Google relied on prior art that did not directly scan the received sequencing file (a playlist in the prior art) to skip forward, and instead scanned data structures that were derived from the received sequencing file. (PA's Markman Presentation, Slides 70-74; D.I. 146 at 9; Tr. at 104-05) The PTAB invalidated claims based on this algorithm. (PA's Markman Presentation, Slide 74; D.I. 147, ex. G at 31-32) Yet Google's position in this case is that the prosecution history makes it "clear that the [received] sequencing file does need to be referred to in connection with determining where to skip forward." (Tr. at 90; see also Google's Markman Presentation, Slides 22-24) Again, if the patentee's statements during prosecution were really clear and unmistakable and subject to no other reasonable interpretation than that proffered by Google in this case, then Google should have submitted the same construction to the PTAB in the IPR. The fact that it did not causes the Court to question the correctness of its proposal here.
For all of these reasons, the Court is persuaded that PA's construction is appropriate as to this issue. It thus recommends that the structure for the skip command not include Google's "received" sequencing file language.
b. "LocType"
The term "LocType" is used in the algorithmic structures for the means responsive terms. PA submits that these structures should include a statement defining "LocType," since that term's meaning is not otherwise readily ascertainable. (D.I. 146 at 12; D.I. 176 at 14) To that end, PA explains that "'LocType' is not a term of art in the industry but rather a coined term where the patentee acted as its own lexicographer." (D.I. 146 at 12) According to PA, the patents demonstrate that structurally, LocType is a character identifier (letter or numbers) that identifies the characteristics of a given selection record pertaining to a program segment. (Id.; Tr. at 112-13) Further, PA asserts that such identifier should not be limited to a single byte character. (PA's Markman Presentation, Slide 95; Tr. at 114) In response, Google does not think that LocType needs to be construed. If the Court does intend to ascribe a definition to the term, Google does not dispute that a LocType "indicates a characteristic of a selection record"; however, Google argues that the term must be described as "a single byte character" because that is how the term is defined in the patent specification. (D.I. 186 at 12; Tr. at 123-24; see also D.I. 159 at 21-22)
The portion of the patent specification that Google refers to is a good place to start the Court's analysis. It is reproduced below:
To control subject and topic skipping, as well as hyperlink jumps, the selections file seen generally at 301 in FIG. 4 preferably takes the form of a sequence of records, each having the structure defined by the following Pascal record definition:
type Selection_Record = record
LocType: Char;
Location: Integer;
where LocType is a single byte character having the values and meanings shown in the following table:end;
| LocType | Meaning |
| "S", "s""T", "t""P", "p""Q", "q""G", "g""H""E""A""M""B""L""R""I""J""K""C""V""X""Y" | Subject AnnouncementTopic AnnouncementProgramming content segmentAdvertising segmentGlue (announcement) segmentHighlight start offsetHighlight end offsetAnchor start offsetBookmarked anchor startAnchor end offsetLinked segmentRewind to identified locationImage identificationImage display start offsetImage display end offsetAccept commentAccept value designationAccept list terminationAccept "Yes"/ "No" |
Google's argument seems correct: the patentee did appear to define "LocType" in the specification. And it seems to have done so by noting that a "LocType" is "a single byte character" that is part of the Selection_Record in the selections file, and that it has a particular value. (See D.I. 159 at 21-22; D.I. 186 at 12) PA never really persuasively explains why "LocType" should not be construed in a manner that mirrors the very definition chosen by the patentee. It complains that Google did not suggest adding in "single byte character" to the construction until it filed its sur-reply brief, thus leaving PA without a "full opportunity to address" the dispute here. (See Tr. at 115) But in its responsive brief, Google did note that "[e]ven if LocType were required to be construed," PA's construction would confuse the term's meaning because "[t]he specification explains that LocType is 'a single byte character' that is part of the Selection_Record in the selections file, which contains a value indicating one of almost 20 possible types of records." (D.I. 159 at 21-22) PA could have directly responded to this argument in its reply brief, but it did not, instead inaccurately stating that "Defendant's response does not contest the merits of Plaintiff's construction." (D.I. 176 at 14)
In its briefing, PA primarily focused on what occurred in the IPR proceeding. (D.I. 146 at 12-13) In the IPR, Google represented that a LocType indicated a characteristic of a "'playable object[.]'" (Id. at 12 (quoting D.I. 147, ex. Z at 48)) In its decision to institute review on, inter alia, claim 1 of the '076 patent, the PTAB concluded that a prior art reference ("Chase") taught the steps of the algorithm corresponding to the "means responsive to said first command" described in the patent. (D.I. 147, ex. E at 29-30) In its briefing here, PA seemed to be asserting that something about "Google's representation" to the PTAB, which led the PTAB to find that Chase invalidated claim 1, suggests that the Court should adopt PA's construction for LocType (and not Google's proposal). (D.I. 146 at 12)
The problem for the Court is that after reading PA's brief, the Court does not understand the argument that PA was making. That is, the Court cannot discern what it is about Google's position in the IPR that was inconsistent with the patentee's definition of LocType in the specification (i.e., that a LocType is a "single byte character").
During the Markman hearing, PA's counsel tried to further explain its position. There, counsel focused on a different portion of the IPR record—one it had not referenced in its pre-hearing briefing. During the hearing, PA's counsel argued that in the IPR proceeding, Google advocated that a LocType could be a five byte character (i.e., not simply a single byte character). (PA's Markman Presentation, Slide 98; see also Tr. at 114) But PA did not provide a sufficient record to make it clear that Google had in fact taken this position in the IPR. Indeed, PA pointed only to one slide of its Markman presentation in support, and that slide was unclear at best. Moreover, as Google's counsel noted, (Tr. at 125), during the IPR proceeding, the claim terms were to be interpreted according to their BRI.
During the Markman hearing, PA also for the first time argued that because the term "LocType" is found in the structure for a means-plus-function term, the structural nature of a LocType—i.e, whether it is a single byte character, or a multi-byte character—is not necessary to the recited function and thus should not be included in any construction. (Tr. at 114-15; PA's Markman Presentation, Slide 99) The Court declines to consider this argument since it was not fairly raised by PA prior to the Markman hearing. See, e.g., Horatio Washington Depot Techs. LLC v. TOLMAR, Inc., Civil Action No. 17-1086-LPS, 2018 WL 5669168, at *7 n.4 (D. Del. Nov. 1, 2018) (citing cases).
In the end, the Court recommends that the corresponding structures for the means responsive terms reflect that a LocType is a single byte character, as Google has proposed in the alternative. PA has not explained in a clear and understandable way why the specification's definitional statement in this regard is wrong.
2. Single Skip Back Command and Double Skip Back Command
With respect to both the single skip back command and the double skip back command, found in claims 2 and 3 of the '076 patent, respectively, the functions of these means-plus-function terms are not in dispute, and are reflected in the chart above. The first steps of the corresponding structures for these terms recite that "if the currently playing program segment has played for a predetermined amount of time [then the structure will be] resetting the playback position to the beginning of the program segment." However, the parties dispute whether the "predetermined . . . time" is measured using a "start time recorded in a usage log file" (Google's position). (D.I. 159 at 19; Tr. at 93) The parties have an additional dispute regarding the corresponding structure for the double skip back command—i.e., whether the algorithm must determine whether "the currently playing program is near its beginning" (as Google argues), or whether the player just needs to assess whether the currently playing program has played for some predetermined amount of time (as PA argues). (See D.I. 159 at 19 (emphasis added); Google's Markman Presentation, Slide 35)
Taking up the latter dispute first, Google asserted in its initial claim construction brief that the specification discloses a single algorithm for determining whether a skip back command should restart the currently playing segment or transition to the beginning of the prior segment (i.e., the double back skip command):
Note that, after any given segment has played for a predetermined amount of time, the BACK command should reset the playback to [the] beginning of the current segment or topic respectively, allowing the user to start the current segment or topic from the
beginning unless the playback point is already near the beginning, in which case the transition is made to the prior segment.('076 patent, col. 15:49-55 (cited in D.I. 159 at 19) (emphasis added by Google)) According to Google, this disclosure means that: (1) in response to a BACK command, if the currently playing program has played for a predetermined amount of time, playback should be reset to the beginning of the current program; (2) unless such command comes "near the beginning" of the current program, in which case playback should be reset to the previous program. (See D.I. 159 at 19-20)
In response, PA explained that this passage simply refers to the time interval from the beginning of the audio segment to the predetermined amount of time. (D.I. 176 at 11-12; Tr. at 118-19) In other words, according to PA, this passage is saying that if the BACK command occurs during the interval between the beginning of the segment and that predetermined amount of time, then the player will reset the playback to the prior segment. (D.I. 176 at 11-12; PA's Markman Presentation, Slide 106; Tr. at 118-19) But if the BACK command occurs after the predetermined amount of time has elapsed, the player will reset at the beginning of the current segment. (D.I. 176 at 11-12; PA's Markman Presentation, Slide 106; Tr. at 118-19)
Both positions seem possibly correct. That said, PA notes that both the Eastern District of Texas and the PTAB construed the structure corresponding to the double skip back command without reference to whether the currently playing program segment is near its beginning (instead, the relevant step in those constructions is identical to PA's proposal here). (Tr. at 116; PA's Markman Presentation, Slide 107) PA's expert also persuasively notes that PA's interpretation seems to be supported by the language of claims 5 and 6 of the '178 patent, respectively. (D.I. 177 at ¶ 63)
Because Google is the party seeking an additional limitation with respect to the structure, and because PA had the more persuasive arguments, the Court will side with PA. That is, the Court will not require the corresponding algorithm for the double skip back command to have to measure whether the currently playing program "is near its beginning."
The Court next turns to the issue of whether the "predetermined . . . time" is measured using a "start time recorded in a usage log file." Both parties seem to agree that responding to a listener's "skip back" command requires measuring the amount of time that a segment has been playing, in order to determine whether the currently playing segment should be restarted, or whether the prior segment should be restarted. (D.I. 176 at 12; D.I. 186 at 9) According to Google, the specification reveals only one way to measure the "predetermined amount of time" that a song has been playing:
The system responds to BACK commands by resetting the playback point to the desired point in the sequence and recording the start time, volume setting and new program segment ID in the log file as indicated at 267 .('076 patent, col. 15:55-59 (cited in D.I. 159 at 20) (certain emphasis added by Google); see also D.I. 186 at 9-10) Step 267 describes responding to a back command including recording the start time. ('076 patent, col. 15:23-24,55-59) Therefore, Google asserts that either the structure for these functions uses "the start time recorded in a usage log file" to determine whether a skip back command should restart the current segment or start the prior segment, or there is no structure for this function. (D.I. 186 at 10) PA's proposed structure does not include an algorithm for measuring time.
For its part, PA responds that the invention utilizes usage logging primarily to maintain a record of listener behavior for future recommendations and accounting purposes—and not for performing the claimed functions of the single skip back and double skip back commands. (D.I. 146 at 9; D.I. 176 at 12) And it is true that the patent does refer to usage log data as being utilized for accounting of royalty payment records for amounts due to content providers, ('178 patent, cols. 12:2-8, 28:41-54), and for generating program recommendations, (id., col. 24:46-59). Thus, the big question is whether the specification clearly links usage logging to the single skip back and double skip back commands. See Medtronic, Inc., 248 F.3d at 1311 ("Structure disclosed in the specification is 'corresponding' structure only if the specification [] clearly links or associates that structure to the function recited in the claim.") (citation omitted).
The Court is not persuaded that recording the start time in a usage log file is necessary for measuring whether the segment has played for a predetermined amount of time. The passage that Google relies on describes responding to "BACK commands" by resetting the playback point to the desired point in the sequence and recording the start time—these seem to be two separate actions. (PA's Markman Presentation, Slide 85) PA also points out that the specification teaches that with respect to usage logging, "it is unnecessary to record the end time for the prior segment since it is the same value as the start time for the next segment." ('178 patent, col. 13:16-18) Therefore, according to PA, the usage log cannot be used to measure whether you are within the predetermined time, since the end time is not recorded until the next program segment begins. (PA's Markman Presentation, Slide 87; Tr. at 109)
In its decision affirming the PTAB Final Written Decisions, the Federal Circuit seemed to agree that there is no link between the usage logging and calculating the time played. (PA's Markman Presentation, Slide 87a; Tr. at 109-10 (quoting Google LLC, 743 F. App'x at 982)).
If the specification does not disclose usage logging as the corresponding structure for measuring whether the predetermined amount of time has passed, where does this leave things? PA asserts that determining the elapsed time of a program "was common among those skilled in the art" and needs no further elaboration. (D.I. 176 at 12) It notes that the specification discloses a visual indicator showing the elapsed time of the program. ('178 patent, col. 12:43-58; see also D.I. 176 at 12) And during the Markman hearing, PA's counsel asserted that: (1) such indicators were common at the relevant time and were "embedded in the time sequencing information of the CD itself; and (2) the algorithm does not need to recite further detail on this point, other than simply determining the amount of elapsed time. (Tr. at 110-11, 127)
The law requires a specification to "recite the particular structure that performs the function and to which the means-plus function claim is necessarily limited." Aristocrat Tech., 521 F.3d at 1336. It seems problematic that the specification does not appear to recite structure for measuring whether the segment is within the predetermined amount of time when a back command is received. According to Google, in such a circumstance, the "relevant claims are indefinite." (D.I. 186 at 10; see also D.I. 202 at 2; Tr. at 95, 123)
Google does not cite to any expert testimony in support of this statement. --------
The Court is not yet prepared to recommend that the terms be found to be indefinite. Prior to opining on that question, the Court would benefit from additional focused briefing on the extent to which the current structure for these functions is sufficient (including citations to analogous cases and expert testimony, if applicable). Google thus may wish to re-raise this definiteness argument during the summary judgment stage.
IV. CONCLUSION
For the foregoing reasons, the Court recommends that the District Court adopt the following constructions:
1. "file" should be construed to mean "a collection of data that is stored and manipulated as a named unit by a file-management or database system"
2. the "sequencing file" terms should be construed to mean "a file of data that identifies the order in which audio program segments chosen by or for a user are to be played"
3. For the term "means responsive to said first command for discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of a program segment which follows said currently playing program in said sequence" the function is "in response to a 'Skip' command, discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of a program segment which follows said currently playing program in said sequence." The corresponding structure for this term is: "A general purpose computer programmed to perform the algorithm that is illustrated in the flow chart of Figure 3 at items 269 and 235 and more fully described at column 15, lines 21 to 25 and column 34, line 28 to column 35, line 48. Specifically, this algorithm includes the following steps:
1. scanning forward in the sequence established by the sequencing file to locate the next Selection_Record of the appropriate LocType;
2. resetting the CurrentPlay variable to the record number of that Selection_Record; and
3. fetching and playing the program segment identified by the ProgramID contained in the new Selection_Record.
A LocType is a single byte character and an identifier that indicates a characteristic of a selection record."
4. For the term "means responsive to a single one of said second commands for discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of said currently playing program" the function is "in response to a single 'Back' command, discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of said currently playing program." The corresponding structure for this term is: "A general purpose computer programmed to perform the algorithm that is illustrated in the flow chart of Figure 3 at items 269 and 235 and more fully described at column 15, lines 49 to 59. Specifically, this algorithm includes the following steps:
1. if the currently playing program segment has played for a predetermined amount of time, resetting the playback position to the beginning of the program segment; and
2. playing the program segment from its beginning.
A LocType is a single byte character and an identifier that indicates a characteristic of a selection record."
5. For the term "means responsive to the detection of two consecutive ones of said second commands for discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of a program segment which precedes the currently playing program segment" the function is "in response to two consecutive 'Back' commands, discontinuing the reproduction of the currently playing program segment and instead continuing the reproduction at the beginning of a program segment which precedes the currently playing program segment." The corresponding structure for this term is: "A general purpose computer programmed to perform the algorithm that is illustrated in the flow chart of Figure 3 at items 269, 235, 261, 262, and 278 and more fully described at column 15, lines 49 to 59 and column 34, line 28 to column 35, line 53. Specifically, this algorithm includes the following steps:
1. in response to a first 'Back' command, if the currently playing program segment has played for a predetermined amount of time, resetting the playback position to the beginning of the program segment and playing the program segment from its beginning;
2. in response to a second 'Back' command, if the currently playing program segment has not yet played for said predetermined amount of time, scanning backward in the sequence established by the sequencing file to locate the previous Selection_Record of the appropriate LocType;
3. resetting the CurrentPlay variable to the record number of that Selection_Record; and
4. fetching and playing the program segment identified by the ProgramID contained in the new Selection_Record.
A LocType is a single byte character and an identifier that indicates a characteristic of a selection record."
This Report and Recommendation is filed pursuant to 28 U.S.C. § 636(b)(1)(B), Fed. R. Civ. P. 72(b)(1), and D. Del. LR 72.1. The parties may serve and file specific written objections within fourteen (14) days after being served with a copy of this Report and Recommendation. Fed. R. Civ. P. 72(b)(2). The failure of a party to object to legal conclusions may result in the loss of the right to de novo review in the district court. See Henderson v. Carlson, 812 F.2d 874, 878-79 (3d Cir. 1987); Sincavage v. Barnhart, 171 F. App'x 924, 925 n.1 (3d Cir. 2006).
The parties are directed to the Court's Standing Order for Objections Filed Under Fed. R. Civ. P. 72, dated October 9, 2013, a copy of which is available on the District Court's website, located at http://www.ded.uscourts.gov. Dated: January 16, 2019
/s/_________
Christopher J. Burke
UNITED STATES MAGISTRATE JUDGE