Opinion
Civil Action No. 17-1751-CFC-CJB
06-07-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 AND STANDARD OF REVIEW
The Court hereby incorporates by reference the summary of the factual and procedural background of this matter set out in its January 16, 2019 Report and Recommendation ("January 16 R&R"). (D.I. 331 at 1-4) It additionally incorporates by reference the legal principles regarding claim construction set out in the January 16 R&R. (Id. at 4-9)
II. DISCUSSION
The parties had disputes regarding 10 terms or sets of terms (hereafter, "terms"). The January 16 R&R addressed the first three terms. The Court addressed terms 4, 5 and 6 in a March 13, 2019 Report and Recommendation. (D.I. 372) The Court addresses the remaining terms herein.
The Court first addresses the remaining three terms that were argued at the Markman hearing (i.e.: (1) the "communications port" terms; (2) "editing means for modifying said data establishing said sequence"; and (3) "means for translating said voice signals"). During the final portion of the hearing in which these terms were argued, the parties agreed that another term that was disputed in the briefing ("player") was no longer in dispute. (Tr. at 172-75) However, the parties addressed one last term in their briefing ("[selected] audio program segments"), for which the dispute seemed to be different than that for "player." (See, e.g., D.I. 146, Appendix A at Refs. 12-13) This term was not argued at the Markman hearing. The Court will address "[selected] audio program segments" last in this opinion.
A. "communications port" terms
The claim terms "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" and "a communications port for downloading at least some of said audio program files and said playback session sequencing file from said one or more server computers" (the "communications port" terms) appear in claims 1 and 14 of the '178 patent, respectively. (D.I. 146 at 28) The use of the disputed term in claim 1 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,('178 patent, cols. 45:60-46:18 (emphasis added))
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 term are set out in the chart below, with the main disputed points noted by bold, underlined language:
| Term | Plaintiff's ProposedConstruction | Defendant's ProposedConstruction |
|---|---|---|
| "a communications port forestablishing a datacommunications link fordownloading a plurality ofseparate digital compressedaudio program files and aseparate sequencing file fromone or more servercomputers" (claim 1)"a communications port fordownloading at least some ofsaid audio program files andsaid playback sessionsequencing file from said oneor more server computers"(claim 14) | "communications port":"a port for establishing aconnection between a playerand a network""downloading":"transferring a file from aremote computer to therequesting computer bymeans of a modem ornetwork" (claim 1)"transferring a plurality ofseparate digital compressedaudio program files and aseparate sequencing file oneor more remote servercomputers via a modem or | "communications port":"[a] port for establishing aconnection between theplayer and a network""downloading":"[t]ransferring digitalcompressed audio programfiles and a separatesequencing file from one ormore separate computers tothe player over a networkupon a request by the playeridentifying said digitalcompressed audio programfiles and said separatesequencing file" (claim 1) |
| network to the player upon arequest by the player" (claim14) | "[t]ransferring at least someof said audio program filesand said playback sessionsequencing file from one ormore separate computers tothe player over a networkupon a request by the playeridentifying said digitalcompressed audio programfiles and said playbacksession sequencing file"(claim 14) |
|---|
For "communications port," the parties agree to the construction of this term adopted by the Eastern District of Texas Court in the Apple litigation ("a port for establishing a connection between the player and a network"). (D.I. 160, ex. 1 at 41; D.I. 146 at 28)
As an initial matter, the parties do not dispute that "downloading" is initiated by a request from the player computer to the host server to initiate the download. (See D.I. 146, Appendix A at Ref. 9; Tr. at 161-62) What the parties do dispute is whether that "request by the player" to download files must identify the files to be downloaded. (D.I. 146 at 28-30; D.I. 159 at 11-13; Tr. at 163 (Google's counsel explaining that "[t]he question is when a request is made to download, does the player have to identify the files that it wants to be downloaded?")) Google's position is that the intrinsic record demonstrates that such an identification of files must be made. (D.I. 159 at 12-13) PA asserts that this additional "unsupported limitation" should be not be imported into the claims (such that the request could simply involve the player informing the server "here I am" to initiate the download). (D.I. 146 at 29-30) For the reasons discussed below, the Court agrees with Google.
During claim construction in the Apple litigation, PA had argued that "downloading" does not require a request from the player to initiate the download. (D.I. 147, ex. D at 38) The Eastern District of Texas Court rejected that position and concluded that, in light of the patent's specification, a person of ordinary skill in the art would understand that the "claimed server/client relationship is one in which the player/client issues 'requests' to initiate a download from the host server." (Id. at 40-41)
While the parties also initially also disputed (1) whether the file transfer must be from a "remote" server; and (2) whether the word "modem" is required in the construction, (D.I. 159 at 11-12; D.I. 146 at 28-30), PA did not respond to Google's arguments on these issues in PA's reply brief, (D.I. 176 at 13; D.I. 186 at 11-12), or during the Markman hearing, (Tr. at 168-70). The Court thus considers them waived and agrees with Google that "remote" and "modem" are not required for the construction of "downloading." See, e.g., Rydex Techs., LLC v. Baxter Int'l, Inc., 105 F. Supp. 3d 420, 426 (D. Del. 2015) (considering argument waived where plaintiff did not respond to argument in its opposition and sur-reply briefs).
The specification consistently explains that a request by the player to download files includes an identification of the files to be downloaded. (D.I. 159 at 12-13; D.I. 186 at 12; Tr. at 162) To that end, as Google points out, the specification states that the "player uses the sequence file to determine files not already on the player, then issues download requests for those files." (Google's Markman Presentation, Slide 73; see also D.I. 159 at 12; Tr. at 162) The specification describes the following with regard to this process, (Google's Markman Presentation, Slide 73; D.I. 159 at 12):
During reexamination proceedings relating to the '178 patent, PA echoed this disclosure regarding the player's download mechanism. (D.I. 159 at 13) There, PA noted that "in some embodiments, the player can download the sequencing file and then issue download requests for those program segment files the sequencing file designates which are not already available in the player's local storage unit, ['178 patent, col. 7:19-22] thus providing a 'synchronization' process that shortens required download and connection time[.]" (D.I. 160, ex. 11 at 6)
(1) "The data downloaded 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." ('178 patent, col. 8:48-53) (emphasis added);In describing the download mechanism of the invention, then, the specification makes clear that when the player requests to download files, it identifies such files. (D.I. 159 at 12)
(2) "Before a playback session begins . . . 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." (Id., col. 8:54-57) (emphasis added);
(3) "In accordance with the invention, the host server receives and supplements the user's initial selection of a sequence of desired programs[.]" (Id., col. 18:24-26) (emphasis added);
(4) "The file 145 is placed in a predetermined FTP download file directory and assigned a filename known to the player 103 ." (Id., col. 6:62-64) (emphasis added);
(5) "The player 103 downloads the session schedule file and then issues download requests for those identified program segment files which are not already available in the player's local storage unit 107 ." (Id., col. 7:19-22) (emphasis added).
(See also, e.g., '178 patent, cols. 14:66-15:13 ("When a communications pathway such as an Internet or cellular phone link is available to connect the player 103 to the server, an immediate request may be sent to the server to download a needed but locally unavailable segment. In that case, the downloading and playing may proceed concurrently by placing the downloaded information into a memory buffer to which the downloaded program segment is written as it is concurrently read for reproduction . . . . To eliminate breaks in the program sequence, the player 103 may advantageously perform a look-ahead operation, sending a file request to the file server via the communication link by pre-scanning the program sequence file 214 to identify program segments to be played which are not in local storage and requesting those segments before they are needed.") (emphasis added))
The Court's conclusion here is also consistent with the Eastern District of Texas Court's decision in the Apple litigation on a motion for judgment as a matter of law relating to the "communications port" terms. (D.I. 159 at 13; Google's Markman Presentation, Slide 76; Tr. at 165) There, PA's expert had argued that a "UBS [sic] system or cable protocol [that said to the server] 'here I am'" met the "downloading" requirement, but the Eastern District of Texas Court found that to be insufficient. (D.I. 160, ex. 18 at 3253 (emphasis omitted)) The Eastern District of Texas Court ruled that "'here I am' is not a request . . . to initiate the transfer." (Id.) While PA's proposed construction here amounts to the player initiating a download by informing the server "here I am," as noted by the Apple Court, a more robust communication to "initiate the transfer" is needed. Google's proposed construction (i.e., a request that includes an identification of the needed files) would certainly amount to more than "here I am."
Though Google discussed this history in the Apple litigation in its responsive brief, (D.I. 159 at 13), PA did not respond, (see D.I. 176 at 13), and wrongly suggested during oral argument that Google had not before made such an argument, (Tr. at 169).
PA's arguments to the contrary with respect to this dispute are not persuasive. PA first asserts that in "ordinary experience" a person can "simply press a button to initiate a download without identifying or even knowing the files one will receive (for example, Microsoft updates)." (D.I. 146 at 29) In support, PA included in its briefing a snapshot of a "Windows Update" message that appears on a computer screen; the message states: "Download and install updates for your computer[.]" The message also indicates that "3 important updates are available" and "6 optional updates are available." (Id.) But the message additionally states that "I important update [was] selected, 24.5MB[.]" (Id. (emphasis omitted)) As Google explained, the snapshot actually refutes the point PA was trying to make, in that the snapshot demonstrates that "[w]hen the 'Install updates' button is pressed, only the selected update is requested to be downloaded." (D.I. 159 at 13 n.8 (certain emphasis omitted))
PA also contends that certain portions of the specification indicate that the host server can identify the files to be downloaded, thus demonstrating that Google's position cannot be correct. (D.I. 146 at 30; D.I. 176 at 13) In support, PA first points to the following disclosure in the specification:
As indicated at 203, an interested subscriber invokes programming services by first supplying personal information . . . . Based on the information supplied by the user, the server then compiles one or more files for downloading to the subscriber at step 207 which include programming and advertising segments[.]('178 patent, col. 8:21-32 (quoted in D.I. 146 at 30) (certain emphasis added by PA)) But this passage only discloses that, based on information from the subscriber, the server will then collect the files that will later be downloaded. (D.I. 159 at 12) Indeed, just a few lines later, the specification explains that "[t]he download file or files containing programming and advertising segments as well as subscriber specific data are designate[d] by filenames provided by the requesting client/player 103 [.]" ('178 patent, col. 8:37-40 (emphasis added); see also D.I. 159 at 12)
PA next asserts that "the specification discloses that identification by the player of files to download is only 'preferably' done (not required)[.]" (D.I. 176 at 13 (citing '178 patent, col. 7:10-22)) But the portion of the specification that PA cites in support does not actually say what PA says it does. What the specification says there is: "[t]he download compilation file 145, though represented as a single file in FIG. 1, preferably takes the form of one or more subscriber and session specific files which contain the identification of separately stored sharable files. ('178 patent, col. 7:10-13 (emphasis added)) In other words, this disclosure is describing the preferable form of the download compilation file; it does not address the identification by the player of files to download. (D.I. 186 at 12; Tr. at 164-65) However, the specification does address that identification issue just a few lines later, when it explains that the player: (1) downloads the session schedule file (which contains the recommended order and the identification of the program files making up an individual playback session); and then (2) "issues download requests for those identified program segment files which are not already available in the player's local storage unit 107." ('178 patent, col. 7:13-22 (emphasis added))
Lastly, PA points to a disclosure in the specification explaining that in one scenario, the host server will prepare a Schedule Table 307 containing program segments selected by the host:
In accordance with the invention, the host server receives and supplements the user's initial selection of a sequence of desired programs, first by adding the program selections specified in failed hypertext requests as indicated by the Usage_Log Table 333 during usage log processing at 350, and then by adding advertisements, announcements and additional program segments tailored to the subscriber's known preferences as indicated at 340 in FIG. 4, thereby producing the recommended Schedule Table 307 which is transferred to the subscriber, along with program segments, during the download transfer. Indeed, if the subscriber provides no selections at all, the host will prepare a Schedule Table 307 containing program segments selected entirely by the host on the subscriber's behalf.(Id., col. 18:23-37 (emphasis added); see also D.I. 176 at 13) According to PA, this means that "[c]learly, the subscriber could not have identified the files in such a case" and that Google's position is therefore wrong. (D.I. 176 at 13)
But as Google responds, Schedule Table 307 is not equivalent to the downloaded program files themselves. (D.I. 186 at 12) Rather, Schedule Table 307 consists of "a sequence of program segment identification numbers which are used to compile a sequencing file . . . which contains more detailed information about the sequence of events which occur during playback." ('178 patent, col. 12:9-16 (emphasis added); see also, e.g., id., col. 17:62-64 (noting that "Schedule Table 307 [] contains the recommended sequence of program segments for the next playback session") (emphasis added)) And so the player is still going to make a request to download any of the actual program files themselves that have not already been downloaded to the player.
Other portions of the specification support this conclusion. The specification explains that Schedule Table 307 is related to Requested Table 301, which is a relational database that includes the selections made by and uploaded from the subscriber. (Id., cols. 17:15-22, 18:37-39 ("[t]he programs, advertising and announcement segments which are added to the Request Table 301 to form the Schedule Table 307")) The patent explains that the subscriber may wish to select for future play a program segment that has already been downloaded to the player. (Id., cols. 18:66-19:1) The ProgramID of such a selection will still be "included in the uploaded selection list (Requested Table 301), recognizing that at the time of actual download, the player 103 will only request the transfer of those program segments not already present in local storage." (Id., col. 19:4-9 (emphasis added)) "The selection of files to download is preferably made by the player which issues FTP download requests from the server by specifying the URLs of the needed files." (Id., col. 19:12-15; see also id., col. 27:13-27 (explaining that Schedule 307 is downloaded to the player and the segments associated with it provide a complete program sequence, and "[a]s a consequence, the player builds a collection of program and advertising segments which can be played in the future and need not be downloaded" as "[d]ownloading of actual program segments therefore preferably occurs at the request of the player which scans the Schedule for program and advertising segments not already available and issues a request for the needed segments") (emphasis added)) In other words, while it seems true that the host server may select program segments on the subscriber's behalf, and the identification of these selections may be downloaded to the player in a file containing a recommended sequence of program segments, the player will still issue download requests for those identified program segments that are not already stored on the player. (Tr. at 165-66)
For the above reasons, the Court recommends that the "communications port" terms be construed in line with Google's proposals. Thus, "communications port" shall be construed to mean "a port for establishing a connection between the player and a network." The term "downloading" in claim 1 shall be construed to mean "transferring digital compressed audio program files and a separate sequencing file from one or more separate computers to the player over a network upon a request by the player identifying said digital compressed audio program files and said separate sequencing file." The term "downloading" in claim 14 shall be construed to mean "transferring at least some of said audio program files and said playback session sequencing file from one or more separate computers to the player over a network upon a request by the player identifying said digital compressed audio program files and said playback session sequencing file."
The Court notes that the "downloading" portion of this construction really seems like it should apply to the entire claim phrases "downloading a plurality of separate digital compressed audio program files and a separate sequencing file from one or more server computers" and "downloading at least some of said audio program files and said playback session sequencing file from said one or more server computers" (as opposed to just the term "downloading"), so that the construction will make more sense in the context of the claims.
B. "editing means for modifying said data establishing said sequence"
The claim term "editing means for modifying said data establishing said sequence" is found in claims 5 and 6 of the '076 patent. These claims depend from claim 1. Accordingly, claims 1, 5 and 6 are reproduced below, with the disputed term highlighted:
1. A player for reproducing selected audio program segments comprising, in combination:('076 patent, col. 46:13-33)
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.
5. A player as set forth in claim 1 including editing means for modifying said data establishing said sequence.(Id., col. 46:52-53 (emphasis added))
6. A player as set forth in claim 5 wherein said editing means includes means for reordering the sequence established by said data.(Id., col. 46:54-56 (emphasis added))
The parties agree that this limitation is a means-plus-function limitation, governed by 35 U.S.C. § 112(6). (D.I. 159 at 28) The parties' competing proposed constructions for the term are set out in the chart below, with the main disputed points noted by bold, underlined language:
| Term | Plaintiff's ProposedConstruction | Defendant's ProposedConstruction |
|---|---|---|
| "editing means for modifyingsaid data establishing saidsequence" | Function:"modifying said dataestablishing said sequence"Structure:"The structure correspondingto the claimed function is thefollowing structures andequivalents thereof:A player client programmedto:1. Add a program segment;and/or2. Delete a program segment;and/or3. Assign a new or differentorder to a given programsegment; and update the order | Governed by 35 U.S.C. §112(6); Indefinite.Function:"[m]odifying said dataestablishing said sequence"Structure:No disclosure ofcorresponding structure inthe patent specification. |
| for the program segments inthe serialized sequence."Alternatively, "[T]hestructure corresponding to theclaimed function is thefollowing structures andequivalents thereof:A player client programmedto:1. Access selections file 351;and2. Alter identifiers ofprogram segments within theselections file, including thefollowing operations:a. Add a program segment;and/orb. Delete a program segment;and/orc. Assign a new or differentorder to a given programsegment; and update the orderfor the program segments inthe serialized sequence." |
|---|
As reflected in these proposals, Google argues that the specification contains no disclosure describing how the function (i.e., "modifying said data establishing said sequence") is performed. Thus, Google asserts that claims 5 and 6 are indefinite. (D.I. 159 at 28-29) PA disagrees. It proposes either the same construction as that adopted by the PTAB during the IPR proceeding (which was agreed to there by the parties), (D.I. 146 at 22; D.I. 147, ex. E at 23-24), or an alternative construction that includes two additional steps, (D.I. 146 at 22).
In support of its position that the specification discloses sufficient structure for this function, PA asserts that the specification discloses a "utility program[,]" provided by the server to the player, which performs steps 213 and 211 ("Edit Downloaded Program Sequence") of Figure 2, depicted below:
Image materials not available for display. (D.I. 146 at 23 (citing '076 patent, FIG. 2))
What exactly is being depicted in this figure? To begin with, as was previously discussed, the player downloads from the server a "recommended program sequence file which provisionally identifies the order in which downloaded program segments are to be played[.]" ('076 patent, col. 8:39-41) The player also issues download requests for the identified program segment files which are not already being stored in the player's local storage unit. (Id., col. 7:10-13) These program segments, stored in randomly addressable locations in the player's local storage unit, are then played at step 212 ("Playback Session(s)") in the sequence established initially by the server and (optionally) modified by the subscriber, with the listener able to skip forward or back in the sequence or jump to a particular segment, thus dynamically altering the preprogrammed sequence. (Id., cols. 8:54-9:4)
With respect to the editing means function, the patent explains that a utility program is utilized to edit the sequence:
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, including altering the extent to which advertising will be played along with the selected programming.(Id., col. 8:45-53) The specification notes that this utility program is responsive to commands received from a listener "to dynamically alter the sequence and content of the programming material actually presented." (Id., col. 2:55-58) To that end, the patent explains that at Step 213, the listener accesses the program sequence to be edited, which can occur at any time. (Id., col. 9:4-6 ("As indicated at 213 in FIG. 2, the listener may at any time return to the sequence editing step 211 to manually reorder the playing sequence if desired."))
At step 211, according to the specification, the downloaded program sequence may be edited by the user in the following ways: (1) by deleting items on the program schedule; (2) by adding items on the program schedule; (3) by reordering items on the program schedule; or (4) by altering his or her selections and general subject matter preferences to affect the way in which the server assembles program schedules for future sessions. (Id., cols. 9:11-15, 12:21-27 ("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 .") (emphasis added))
PA contends that steps 213 and 212 of Figure 2 both describe how to perform the editing means function, as well as the specific data structure (Selections File 351) that is utilized to perform the function. (D.I. 146 at 24; D.I. 176 at 13-14) That is, the playback session can be modified by adding, deleting, or reordering the "segment identifiers" that make up Selections File 351 shown in Figure 5, such that "when the identifiers change, the sequence for playback changes." (D.I. 176 at 13-14; see also D.I. 146 at 24; Tr. at 179) The sequence of programming defined by the program sequence file is then reproduced for the listener. ('076 patent, col. 8:54-57)
For its part, Google responds that "there is no disclosure of how the 'editing' function would be executed." (D.I. 159 at 29 (certain emphasis in original)) With respect to the "four operational steps" that PA points to—i.e., using a utility program for modification (access file, add identifiers, delete identifiers, and resequence identifiers)—Google characterizes these steps as merely restating the function of "modifying said data establishing said sequence." That is, according to Google, these are merely examples of modifying, not additions of necessary structure. (D.I. 186 at 15; see also Tr. at 177 (Google's counsel asserting that a sufficient algorithm would be "some software algorithm for how you actually add or delete or modify what is in the sequencing file [and arguing that the only citation here] is to sort of repeat[] the function that it can be edited, that you can add, that you can subtract, that you can insert something, but there's nothing about how to do it") (emphasis added))
In the Court's view, Google has not met its burden of proving, by clear and convincing evidence, that claims 5 and 6 of the '076 patent are indefinite because of inadequate disclosure of structure. See TecSec, Inc. v. Int'l Bus. Mach. Corp., 731 F.3d 1336, 1349 (Fed. Cir. 2013); Intel Corp. v. VIA Techs., Inc., 319 F.3d 1357, 1365-66 (Fed. Cir. 2003). As described above, the specification discusses a specific way to "modify[] said data establishing said sequence [in which the stored program segments are scheduled to be reproduced by the player.]" That is, utilizing a utility program, the listener accesses the selections file 351 (which can occur at any time) to manually alter the sequence of program segments to be played by adding a program segment identifier to the selections file, deleting a program segment identifier from the selections file, or reordering the program segment identifiers. This is an articulation of the "how" that Google says is missing from the patent—i.e., "how" to do the modifying at issue. While it is true that the specification does not disclose a complex algorithm or specific code that would be utilized, that is not required under the law. Typhoon Touch Techs., Inc. v. Dell, Inc., 659 F.3d 1376, 1386 (Fed. Cir. 2011) ("[A]s precedent establishes, it suffices if the specification recites in prose the algorithm to be implemented by the programmer."); StrikeForce Techs. Inc. v. PhoneFactor Inc., Civil Action No. 13-490-RGA, 2015 WL 5708577, at *1 (D. Del. Sept. 29, 2015) ("They are simple algorithms, but there is no requirement that the algorithms be complicated."). PA's expert, Dr. Kevin C. Almeroth, opined that "a person of ordinary skill reading the specification would be informed with reasonable certainty as to the corresponding algorithmic structure" for the "editing means" function. (D.I. 147 at ¶ 117) If this is not true, and if the person of ordinary skill would be left in the dark regarding the programming needed to implement the step-by-step process for modifying data establishing a sequence, Google should have cited to expert testimony supporting that position. Yet it did not. See Typhoon Touch Techs., 659 F.3d at 1385-86 (finding that the specification contained a sufficient algorithmic structure where it recited in prose the algorithm to be implemented by the programmer, and "[t]he defendants have directed us to no evidence that a programmer of ordinary skill in the field would not understand how to implement this function").
In support of its position that the specification provides no disclosure of how the "editing" function would be executed, Google cites in its responsive brief to Ergo Licensing, LLC v. CareFusion 303, Inc., 673 F.3d 1361, 1365 (Fed. Cir. 2012) and Noah Sys. Inc. v. Intuit Inc., 675 F.3d 1302, 1318-19 (Fed. Cir. 2012). (D.I. 159 at 28-29) Both cases, however, are distinguishable. In Ergo Licensing, the patentee argued that the "corresponding structure for 'control means' is the recitation of 'control device' throughout the specification." 673 F.3d at 1363. The Federal Circuit rejected this argument, explaining that the patentee's proposal simply replaced the word "means" with the generic term "'device.'" Id. at 1363-64. Here, in contrast, PA points to disclosures in the specification that explain how the player would go about "modifying said data establishing a sequence." And in Noah Sys., where the "access means" claim limitation recited two functions but the specification only disclosed an algorithm for one of those functions, the Federal Circuit found that the limitation was indefinite. Noah Sys., 675 F.3d at 1313-19 ("[W]here a disclosed algorithm supports some, but not all, of the functions associated with a means-plus-function limitation, we treat the specification as if no algorithm has been disclosed at all."). Those circumstances are not at play here.
Therefore, the specification sets forth "'an adequate disclosure showing what is meant by [the 'editing means for modifying said data establishing said sequence'] language'" in claims 5 and 6 of the '076 patent. Atmel Corp. v. Info. Storage Devices, Inc., 198 F.3d 1374, 1380 (Fed. Cir. 1999) (quoted in Typhoon Touch Techs., 659 F.3d at 1385). As discussed above, the Court agrees with PA that the steps set out in its alternative proposal are supported by the specification, and therefore recommends that it be adopted for this term.
C. "means for translating said voice signals . . ."
The term "means for translating said voice signals into said control commands" is found in claim 13 of the '076 patent. Claim 13 depends from claim 1, which was set out above. Claim 13 is reproduced below, with the disputed term highlighted:
13. A player as set forth in claim 1 wherein said means for accepting control command from a user includes a microphone for accepting voice signals from said user and means for translating said voice signals into said control commands.('076 patent, col. 47:33-37 (emphasis added))
The parties agree that this limitation is a means-plus-function limitation, governed by 35 U.S.C. § 112(6). (D.I. 159 at 28) The parties' competing proposed constructions for the term 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 for translating saidvoice signals into said controlcommands" | Function:"translating said voice signalsinto said control commands"Structure:"The structure correspondingto the claimed function is thefollowing structures andequivalents thereof:A microphone and voicerecognition software (i.e., avoice command system)." | Governed by 35 U.S.C. §112(6); Indefinite.Function:"[t]ranslating said voicesignals into said controlcommands"Structure:No disclosure ofcorresponding structure inthe patent specification. |
As an initial matter, it is undisputed that the specification identifies a voice command system as performing the function. (Tr. at 180-81, 185; PA's Markman Presentation, Slide 222; Google's Markman Presentation, Slide 98) That disclosure explains that:
Using a hands free voice command system, the player may reproduce a menu program segment in which a sequence of options are enunciated on the system's audio output speaker with short pauses between the recited options. By providing the voice command 'Go' during or shortly after a desired option, the user may cause the system to branch to that selection.('076 patent, col. 16:50-56 (emphasis added)) The specification also indicates that voice responses are recorded and converted to text form by a voice recognition system. (Id., col. 16:21-45) And it explains that "[t]he player 103 further includes a sound card 110 which receives audio input from a microphone input device 111 for accepting voice dictation and commands from a user and which delivers audio output to a speaker 113 in order to supply audio information to the user." (Id., col. 4:41-46)
The crux of the dispute here seems to be whether, at the time of the invention, the "voice command system" referred to in the specification was "well known in the art at [the time] to perform the function." (D.I. 176 at 14; Tr. at 181) The Federal Circuit has explained that "[i]n past cases, we have been generous in finding something to be a corresponding structure when the specification contained a generic reference to structure that would be known to those in the art and that structure was clearly associated with performance of the claimed function." Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205, 1213-14 (Fed. Cir. 2003); see also, e.g., Princeton Dig. Image Corp. v. Konami Dig. Entm't Inc., Civil Action No. 12-1461-LPS-CJB, Civil Action No. 13-335-LPS-CJB, 2017 WL 2615739, at *10 (D. Del. June 16, 2017) (explaining that the Federal Circuit has "rejected the notion that 'special programming' cannot encompass commercially available off-the-shelf software") (citing cases), rejected in part on other grounds, 2017 WL 6375173 (D. Del. Dec. 13, 2017); Thought, Inc. v. Oracle Corp., Case No. 12-cv-05601-WHO, 2014 WL 5408179, at *20 (N.D. Cal. Oct. 22, 2014).
PA's expert Dr. Almeroth opines that the person of ordinary skill in the art at the time of the patent's filing (October 2, 1996) would understand that the term "voice command system" "connotes specific structure and would recognize this term describes specific software that performs the function of translating voice signals into commands." (D.I. 147 at ¶ 129; D.I. 146 at 30) In support of this opinion, Dr. Almeroth cites to several references that assertedly "illustrate the way the term 'voice command system' was used as a term of art and its meaning around the time of the invention." (D.I. 147 at ¶¶ 130-35; D.I. 146 at 30) These references include the following:
(1) One reference, an edition of a handbook regarding multi-media that was published in 1997 (the "Multi-Media Handbook"), explains that "[i]n the voice recognition area, applications may be divided into two categories: voice command and voice dictation. Voice command systems allow a user to run[ the] computer via voice, either in conjunction with or as a replacement of the keyboard and/or mouse." (D.I. 147 at ¶ 131 (emphasis in original) (quoting Mike McGonagle, Voice-Recognition and Voice-Response Systems, in The Ultimate Multi-Media Handbook 35.1, 35.11-35.12 (Jessica Keyes ed., 2d ed. 1997) (hereinafter, "Multi-Media Handbook'')).
(2) The Multi-Media Handbook then provides an in-depth discussion of both types of systems, including characteristics of these systems, types of errors that occur in such systems, steps for building such systems, and a list of commercially available voice command systems. Multi-Media Handbook 35.12-24; see also (D.I. 147 at ¶ 132).
(3) The Multi-Media Handbook also notes that the same software that is used for voice dictation systems (i.e., converting voice signals into text) can be used as voice-
command systems, and some companies (Dragon Systems and IBM, for example) offered systems that could be utilized as both. Multi-Media Handbook 35.23 (cited in D.I. 147 at ¶ 132).
(4) United States Patent No. 5,950,167 (hereinafter, the "'167 patent"), filed on January 26, 1998 and entitled "Screen-less Remote Voice or Tone-Controlled Computer Program Operations Via Telephone Set," references the use of a "voice command system" that "includes an incoming voice-recognition unit" and a "converter [] that provides voice-to-text file and text file-to-voice conversion capability." (D.I. 147, ex. T at col. 4:10-17 (cited in D.I. 147 at ¶ 133)) The patent also notes that "[s]oftware which when suitably programmed performs the function" of the voice command system, voice recognition unit and converter "is commercially available from Lucent Technologies Inc. in the product INTUITY™ CONVERSANT® CURRENT VERSION 6.0." (Id., col. 4:30-33)
(5) United States Patent No. 5,127,043 (hereinafter, the "'043 patent"), filed on May 15, 1990 and entitled "Simultaneous Speaker-Independent Voice Recognition and Verification Over a Telephone Network," discloses "a voice recognition/verification method and system for enabling a caller to obtain access to one or more services via a telephone network." (D.I. 147, ex. U, col. 1:7-11 (cited in D.I. 147 at ¶ 134)) While the '043 patent does not itself explicitly reference a "voice command system," another patent, filed on September 3, 1996 and entitled "Intelligent Call Processing Platform for Home Telephone System," recognizes the '043 patent as reciting such a system: "A voice command system of this type is described in copending application Ser. No. 07/523,486, filed May 15, 1990, to Hunt et al., titled 'Simultaneous Speaker-Independent Voice Recognition and Verification Over a Telephone Network,' assigned to the assignee of the present invention and incorporated herein by reference." (Id., ex. V, col. 4:19-25 (emphasis added) (cited in D.I. 147 at ¶ 134))
With respect to the Multi-Media Handbook and the '167 patent, Google retorts that these references are irrelevant since they come after the October 2, 1996 filing date of the '076 patent. (D.I. 159 at 30; D.I. 162 at ¶ 36; Tr. at 181; Google's Markman Presentation, Slides 99-100) While the Court agrees that the '167 patent may be of minimal relevance to the dispute since it was filed over a year after the '076 patent was filed, the Court does not agree that the discussion in the Multi-Media Handbook is completely irrelevant. That reference was published shortly after the '076 patent was filed, and the discussion therein does not suggest that voice command systems were entirely new or something that had just been invented. Rather, the discussion makes it apparent that these systems were already in use, with commercial options available, as of October 1996. As for the '043 patent, Google contends that it too fails to establish that the term "voice command system" was a commonly used term of art at the relevant time, since the '043 patent does not even use that term. (Tr. at 181; D.I. 162 at ¶ 36; Google's Markman Presentation, Slide 100) But this argument overlooks PA's point that a co-owned patent application filed shortly before the '076 patent application was filed does explain that the '043 patent discloses a "voice command system." (D.I. 147 at ¶ 134) Put together, in the Court's view, these references make it reasonable to conclude that a "voice command system" was indeed a known structure in the art at the time of the invention. (D.I. 146 at 30; D.I. 176 at 14; Tr. at 183-84; PA's Markman Presentation, Slides 223-26)
Indeed, the Court notes that there was a first edition of the Multi-Media Handbook published in 1994, and it appears that the chapter referenced above regarding voice-recognition and voice-response systems was authored in 1994. (See D.I. 147, ex. S at 3, 35.19 ("The next step, currently (1994) in full swing, is to add limited voice recognition to these systems.")) Most of the references in the Bibliography cited at the end of the chapter were published in 1992 and 1993. (Id., ex. S at 35.27)
Google additionally argues that "[e]ven if systems that could accomplish these functions were generally known . . . this would be insufficient to disclose a corresponding algorithmic structure." (D.I. 159 at 30) In support of this assertion, Google cites again to Ergo Licensing and to Triton Tech of Tex., LLC v. Nintendo of Am., Inc., 753 F.3d 1375, 1379 (Fed. Cir. 2014). In the Court's view, however, these cases address different circumstances than those at issue here. In Ergo Licensing, the plaintiff/patentee argued that a "control device" was structure for the term "control means." Ergo Licensing, 673 F.3d at 1363-64. The Federal Circuit rejected this argument, explaining that the plaintiff's expert's "testimony illustrates that those skilled in the art would not recognize a 'control device' as a known structure." Id. at 1364 (emphasis added). Here, however, PA's expert's testimony illustrates the opposite—that those skilled in the art would recognize a voice command system as a known structure. In Triton Tech, the Federal Circuit agreed with the defendant's argument was that the term "numerical integration" did not disclose an algorithm for the function of the "integrator means" because "numerical integration is not an algorithm but is instead an entire class of different possible algorithms used to perform integration." Triton, 753 F.3d at 1379. That is a different situation than that at issue here, where a patentee is pointing to a known structure in the art that could accomplish the function at issue. And as explained above, it is well-settled that a specification's disclosure of a known structure clearly associated with performance of the claimed function can be sufficient to amount to corresponding structure for purposes of Section 112, paragraph 6.
In the end, on this record, Google has not demonstrated by clear and convincing evidence that the "means for translating said voice signals into said voice control commands" limitation is indefinite for failing to disclosure sufficient structure. The patent discloses a structure that is linked to the function at issue, and PA has pointed to evidence sufficiently demonstrating that such structure was known at the time of the invention. Therefore, the Court recommends that PA's proposal be adopted for this term. See, e.g., S3 Inc. v. NVIDIA Corp., 259 F.3d 1364, 1370-71 (Fed. Cir. 2001) (reversing the district court's finding that a means-plus-function limitation was indefinite for lack of disclosure of corresponding structure, where the parties agreed that the function "corresponds to the 'selector' referred to in the specification" and even though "the electronic structure of the selector and the details of its electronic operation are not described in the specification[,]" the patentee "presented evidence that a selector is a standard electronic component whose structure is well known in this art"); cf. Univ. of Pittsburgh v. Varian Med. Sys., Inc., No. 2:08-CV-01307-AJS, 2011 WL 1877663, at *6 (W.D. Pa. Apr. 6, 2011) (finding that "digitizer" was sufficient structure associated with the function "generating digital image signals representative of an image of the patient" where the digitizer was recited in the patent, and the patentee presented evidence that "a digitizer was a well known, off-the-shelf structure at the time of the filing of the patent" and as such the patentee "was not required to disclose the details of that structure").
Google's expert, Dr. Ketan Mayer-Patel, does opine in his declaration that even if voice command systems were commonly known at the time of the invention, "they could not have constituted the entire structure for the claimed function because such software products would be unable to translate voice commands for the claimed audio player without additional components including, e.g., specialized hardware, custom vocabularies of application-specific commands, or programming employing voice application programming interfaces." (D.I. 162 at ¶ 37) In support, Dr. Mayer-Patel cites to the Multi-Media Handbook and to the '076 patent's reference to accepting voice commands "GO," "FIVE," and "NEWS" which he says are "typically not present in standard Windows vocabularies." (Id.) But Google did not rely on this argument in its briefing or at the Markman hearing. And even had Google not waived this argument, in the Court's view, Dr. Mayer-Patel's single, brief statement could not amount to clear and convincing evidence that this term is indefinite.
As PA points out, (PA's Markman Presentation, Slide 229), the Eastern District of Texas Court, in construing the "means for accepting control commands from a user" limitations found in claims 1, 13 and 14 of the '076 patent, rejected the defendant's argument that there was no disclosure for "any voice recognition algorithm for accepting commands from a microphone[,]" (D.I. 160, ex. 2 at 12). The Apple Court noted that the player computer would "need to have some means for translating sounds into commands [,]" citing to the "means for translating said voice signals into said control commands" limitation at issue here. (Id.) The Eastern District of Texas Court then agreed with PA that "methods for recognizing speech commands were extremely well-known in the art, and a skilled artisan would know what software to use and how to implement it[,]" citing in support to a 1996 article in Microsoft Systems Journal relating to "Microsoft programming interface for implementing speech recognition and voice commands into applications [,]" as well as to a declaration of Dr. Almeroth. (Id. at 12-14) That another tribunal considered this issue, and found there to be sufficient structure disclosed for "translating sounds into commands[,]" further persuades the Court that PA's position is the correct one here.
D. "[selected] audio program segments"
The final claim term at issue ("[selected] audio program segments") is found in claim 1 of the '076 patent (reproduced above). ('076 patent, col. 46:13-33)
The parties' competing proposed constructions for the term are set out in the chart below, with the main disputed points noted by bold, underlined language:
| Term | Plaintiff's ProposedConstruction | Defendant's ProposedConstruction |
|---|---|---|
| "[selected] audio programsegments" | "Audio program segmentsthat have been chosen by orfor a user."Preamble is limiting. | Plain and ordinary meaningPreamble is not limiting. |
In its opening brief, PA did not substantively address this term at all. Instead, it lumped reference to the term into the same heading as that for the term "player" (a term that the parties reached agreement on during the Markman hearing), and then proceeded to only make arguments applicable to "player." (D.I. 146 at 30; id., Appendix A at Refs. 12-13) Google noted this lack of argument in its responsive brief. (D.I. 159 at 4) Google then provided argument with respect to the term "audio program segments" (but did not present argument regarding the term "selected audio program segments"). (D.I. 159 at 3-4) In its reply brief, PA briefly addressed this term, noting that both the Eastern District of Texas Court and the PTAB had concluded that "selected audio program segments" requires that the segments be selected. (D.I. 176 at 14 (citing D.I. 147, ex. D at 44, 48; id., ex. E at 8 & '178 patent, cols. 8:48-53, 29:22-30)) PA then stated that "[t]he issue of whether the preamble is limiting is not joined by the term selection 'selected audio program segments' and is not addressed in Defendant's brief." (Id.) In response, Google asserted that "[t]here is . . . no reason to construe 'selected audio program segments'—a term that will be easily understood by the jury—as anything other than its plain and ordinary meaning." (D.I. 186 at 13) The parties did not address this term during the Markman hearing.
In light of the above, the Court is left without a firm grasp of the parties' real arguments with respect to this term. For example, neither party provided any substantive arguments about whether this preamble phrase is or is not limiting. And the Court is unsure whether, in proposing a "plain and ordinary meaning" construction for this term, Google disputes that "selected audio program segments" are anything other than "audio program segments that have been chosen by or for a user" (and if so, why that is, especially in light of the constructions issued by the Eastern District of Texas Court and PTAB for the term). Accordingly, given the unclear state of the record, the Court declines to recommend a construction for this term at this time. The parties may revisit the issue at a later stage of the case, if necessary.
III. CONCLUSION
For the foregoing reasons, the Court recommends that the District Court adopt the following constructions:
1. That the term "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[,]" found in claim 1 of the '178 patent, be construed as follows: "communications port" in the term shall be construed to mean "a port for establishing a connection between the player and a network" and "downloading" in the term shall be construed to mean "transferring digital compressed audio program files and a separate sequencing file from one or more separate computers to the player over a network upon a request by the player identifying said digital compressed audio program files and said separate sequencing file." The term "a communications port for downloading at least some of said audio program files and said playback session sequencing file from said one or more server computers[,]" found in claim 14 of the '178 patent, be construed as follows: "communications port" in the term shall be construed to mean "a port for establishing a connection between the player and a network" and "downloading" in the term shall be construed to mean "transferring at least some of said audio program files and said playback session sequencing file from one or more separate computers to the player over a network upon a request by the player identifying said digital compressed audio program files and said playback session sequencing file"
2. For the term "editing means for modifying said data establishing said sequence" the function is "modifying said data establishing said sequence." The structure corresponding to the claimed function is the following structures and equivalents thereof: "A player client programmed to:
1. Access selections file 351; and
2. Alter identifiers of program segments within the selections file, including the following operations:
a. Add a program segment; and/or
b. Delete a program segment; and/or
c. Assign a new or different order to a given program segment; and update the order for the program segments in the serialized sequence."
3. For the term "means for translating said voice signals into said control commands" the function is "translating said voice signals into said control commands." The structure corresponding to the claimed function is the following structures and equivalents thereof: "A microphone and voice recognition software (i.e., a voice command system)."
4. The Court declines to recommend a construction for "selected audio program segments" at this time.
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: June 7, 2019
/s/_________
Christopher J. Burke
UNITED STATES MAGISTRATE JUDGE