Advanced Voice Recognition Systems, Inc.Download PDFPatent Trials and Appeals BoardJan 13, 2021IPR2019-01352 (P.T.A.B. Jan. 13, 2021) Copy Citation Trials@uspto.gov Paper 33 Tel: 571-272-7822 Date: January 13, 2021 UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ APPLE INC., Petitioner, v. ADVANCED VOICE RECOGNITION SYSTEMS, INC., Patent Owner. ____________ IPR2019-01352 Patent 7,558,730 B2 ____________ Before JOHN A. HUDALLA, MELISSA A. HAAPALA, and STEVEN M. AMUNDSON, Administrative Patent Judges. AMUNDSON, Administrative Patent Judge. JUDGMENT Final Written Decision Determining All Challenged Claims Unpatentable 35 U.S.C. § 318(a) IPR2019-01352 Patent 7,558,730 B2 2 I. INTRODUCTION Apple Inc. (“Petitioner”) filed a Petition (Paper 2, “Pet.”) requesting an inter partes review of claims 15 and 17 in U.S. Patent No. 7,558,730 B2 (Ex. 1001, “the ’730 patent”) under 35 U.S.C. §§ 311–319. Advanced Voice Recognition Systems, Inc. (“Patent Owner”) filed a Preliminary Response (Paper 5, “Prelim. Resp.”). In our Institution Decision (Paper 10, “Inst. Dec.”), we instituted review based on all challenged claims and all grounds advanced in the Petition. We have jurisdiction under 35 U.S.C. § 6. We issue this Final Written Decision under 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For the reasons explained below, Petitioner has shown by a preponderance of the evidence that claims 15 and 17 in the ’730 patent are unpatentable. See 35 U.S.C. § 316(e) (2018). II. BACKGROUND A. Procedural History After we instituted review, Patent Owner filed a Response (Paper 20, “Resp.”), Petitioner filed a Reply (Paper 22, “Reply”), and Patent Owner filed a Sur-reply (Paper 28, “Sur-reply”). On October 26, 2020, we held an oral hearing, and the record includes the hearing transcript. See Paper 32 (“Tr.”). B. Real Parties in Interest Petitioner identifies itself as the real party in interest. Pet. 74. Patent Owner identifies itself as the real party in interest. Paper 4, 1. The parties do not raise any issue about real parties in interest. IPR2019-01352 Patent 7,558,730 B2 3 C. Related Matters Petitioner and Patent Owner identify the following civil action where Patent Owner has asserted the ’730 patent against Petitioner: Advanced Voice Recognition Systems, Inc. v. Apple Inc., No. 2:18-cv-02083 (D. Ariz. filed July 3, 2018). Pet. 74; Paper 4, 1. D. The ’730 Patent (Ex. 1001) The ’730 patent, titled “Speech Recognition and Transcription Among Users Having Heterogeneous Protocols,” issued on July 7, 2009, based on an application filed on July 3, 2007, as a continuation of an application filed on November 27, 2001. Ex. 1001, codes (21), (22), (45), (54), (63). The patent states that the “invention relates to electronic speech recognition and transcription, and more particularly, to processes and systems for facilitating electronic speech recognition and transcription among a network of users having heterogeneous system protocols.” Id. at 1:17–21; see id. at codes (54), (57). In the Background of the Invention, the ’730 patent describes “sophisticated” or “high accuracy” networked and centrally located speech- recognition-and-transcription engines as an “efficient way to utilize” automatic speech recognition (ASR) for “large-scale users, especially in the professions.” Ex. 1001, 2:36–42. But the patent identifies a barrier “to implementation of such centralized systems.” Id. at 2:42–43. In particular, the patent explains “most businesses operate using their own internal” system protocols, e.g., “legacy” protocols, that “are very difficult to alter because they are the heart of the internal workings of a business, a computer system, or a hardware interface.” Id. at 2:43–51. The patent also explains that “[f]or most network users, it is too costly, both in terms of equipment IPR2019-01352 Patent 7,558,730 B2 4 costs and disruptions in electronic communications, to replace a legacy system with a uniform ‘business’ or system protocol merely to support network applications for speech recognition and transcription.” Id. at 2:51–56. In addition, the ’730 patent explains the “establish[ing] direct communications between the legacy or business system protocol[s] of two different users” could require much “skill and testing” because “the operational commands and language used to communicate with another user can be unique for each user on the network.” Ex. 1001, 2:61–3:4. Moreover, the patent notes that “the use of a public network raises privacy concerns and does not address the heterogeneity of different internal entity protocols used by different entities in transacting information flow.” Id. at 3:10–13. The ’730 patent discusses the desirability of systems and methods that (1) “facilitate the exchange of speech . . . and information among users having heterogeneous and/or disparate internal system protocols” and (2) “provide[] for automated speech recognition and transcription in a seamless manner . . . irrespective of the internal system protocol employed by an individual user.” Ex. 1001, 3:44–52. Among other things, the patent describes its invention as “provid[ing] a system for facilitating speech recognition and transcription among users employing heterogeneous or disparate entity system protocols.” Id. at 3:56–58. The patent also describes its invention as “provid[ing] a method of exchanging generated speech information and/or transcribed spoken text among users who may employ different user protocols.” Id. at 4:53–55; see id. at 5:6–8. IPR2019-01352 Patent 7,558,730 B2 5 Figure 3 of the ’730 patent is reproduced below: Figure 3 is a schematic diagram of a system “for facilitating speech recognition and transcription.” Ex. 1001, 5:39–40; see id. at 16:51–56. Figure 3 illustrates system 20' including system transaction manager 30', speech recognition and transcription engine 32', user application service adapter 80, user service adapter 82, ASR application service adapter 84, and speech service adapter 86. See Ex. 1001, 16:64–17:4. System 20' provides “speech recognition and transcription services using Speech Information Requests and Responses.” Id. at 17:34–37. The ’730 patent defines “Speech Information Request” as “Formatted Speech, which can be acted upon by System components, including the System Transaction Manager.” Ex. 1001, 7:33–35. The patent defines IPR2019-01352 Patent 7,558,730 B2 6 “Response to a Speech Information Request” as “[a] formatted transcription of formatted Speech.” Id. at 7:11–12. Referring to Figure 3, if a user creates a Speech Information Request using a legacy protocol, application service adapter (ASA) interface 94 in user application service adapter 80 “transforms the Request so that it adheres to” a uniform system protocol. Ex. 1001, 17:60–66; see also id. at 5:60–66, 17:40–45. After transformation, user application service adapter 80 transmits the Request to system transaction manager 30' via user service adapter 82. Id. at 18:6–11. Then, system transaction manager 30' processes the Request in various ways and transmits it to speech recognition and transcription engine 32' via speech service adapter 86 and ASR application service adapter 84. Id. at 18:19–63, 19:12–39. After receiving the Request, speech recognition and transcription engine 32' generates “a Response, which includes a transcription of spoken text, and transmits the Response” to system transaction manager 30' via ASR application service adapter 84 and speech service adapter 86. Id. at 19:40–45. Then, system transaction manager 30' processes the Response in various ways and transmits it to the user via user service adapter 82 and user application service adapter 80. Id. at 19:58–20:25. Before the user receives the Response, however, application service adapter (ASA) interface 94 in user application service adapter 80 “reformats the Response . . . so that it is compatible with” the legacy protocol. Id. at 20:25–29. E. The Challenged Claims Petitioner challenges independent claims 15 and 17. Pet. 7–8, 12–73. The challenged claims read as follows: IPR2019-01352 Patent 7,558,730 B2 7 15. A system for facilitating speech recognition and transcription among users, the system comprising: a system transaction manager, the system transaction manager utilizing a uniform system protocol for handling speech information requests and responses to speech information requests, the speech information requests and responses comprising, respectively, formatted spoken text and formatted transcriptions of the formatted spoken text; a first user application service adapter communicating with at least one user and the system transaction manager, the first user application service adapter configured to generate speech information requests from spoken text produced by the at least one of the users through a first protocol; a speech recognition and transcription engine communicating with the system transaction manager, the speech recognition and transcription engine configured to receive speech information requests from the system transaction manager, to generate responses to the speech information requests, and to transmit the responses to the system transaction manager; and a second user application service adapter communicating with one or more of the users and with the system transaction manager, the second user application service adapter which is different than the first user application service adapter and configured to provide the one or more users with a transcription of the spoken text that is compatible with a second protocol, the second protocol being the same as or different than the first protocol. 17. A method of exchanging transcribed spoken text among users, the method comprising: generating a speech information request from spoken text obtained through a first protocol, the speech information request comprised of formatted spoken text generated using a first user application service adapter; IPR2019-01352 Patent 7,558,730 B2 8 transmitting the speech information request to a speech recognition and transcription engine via a system transaction manager; generating a response to the speech information request using the speech recognition and transcription engine, the response comprised of a formatted transcription of the formatted spoken text; transmitting the response to a user via the system transaction manager; and providing the user with a processed transcription of the spoken text using a second user application service adapter, the processed transcription being compatible with a second protocol that is different than the first protocol. Ex. 1001, 27:14–44, 28:10–29. F. The Asserted Prior Art For its challenges, Petitioner relies on the following prior art: 1. U.S. Patent No. 6,487,278 B1 to Skladman et al., titled “Method and System for Interfacing Systems Unified Messaging with Legacy Systems Located Behind Corporate Firewalls,” filed on February 29, 2000, and issued on November 26, 2002 (Ex. 1004, “Skladman”). 2. U.S. Patent No. 7,558,735 B1 to Obilisetty, titled “Transcription Application Infrastructure and Methodology,” filed on December 28, 2000, and issued on July 7, 2009 (Ex. 1005, “Obilisetty”). 3. U.S. Patent No. 6,064,723 to Cohn et al., titled “Network-Based Multimedia Communications and Directory System and Method of Operation,” filed on April 7, 1998, and issued on May 16, 2000 (Ex. 1006, “Cohn”). 4. U.S. Patent No. 6,850,609 B1 to Schrage, titled “Methods and Apparatus for Providing Speech Recording and Speech Transcription IPR2019-01352 Patent 7,558,730 B2 9 Services,” filed on October 23, 1998, and issued on February 1, 2005 (Ex. 1022, “Schrage”). G. Instituted Grounds of Unpatentability We instituted trial on the following grounds of unpatentability, i.e., all grounds asserted by Petitioner: Claims Challenged 35 U.S.C. § References 15, 17 103(a)1 Skladman, Obilisetty 15, 17 103(a) Skladman, Obilisetty, Schrage 15, 17 103(a) Cohn, Obilisetty See Pet. 7–8, 12–73. H. Testimonial Evidence To support its challenges, Petitioner relies on two declarations of Charles D. Creusere, Ph.D. (Ex. 1003, “Creusere Decl.”; Ex. 1025, “Creusere Suppl. Decl.”). Patent Owner relies on the declaration of David V. Anderson, Ph.D. (Ex. 2014, “Anderson Decl.”). During the trial, each declarant was cross-examined, and the record includes the deposition transcripts. See Exs. 1024, 2015. I. Burden In an inter partes review, a petitioner bears the burden of persuasion to prove “unpatentability by a preponderance of the evidence.” Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015) (quoting 35 U.S.C. § 316(e)); see 37 C.F.R. § 42.1(d) (2019). 1 The Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112-29, 125 Stat. 284 (2011), amended 35 U.S.C. § 103 effective March 16, 2013. Because the ’730 patent’s effective filing date predates the AIA’s amendments to § 103, this decision refers to the pre-AIA version of § 103. IPR2019-01352 Patent 7,558,730 B2 10 III. PATENTABILITY ANALYSIS A. Legal Principles: Obviousness A patent may not be obtained “if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains.” 35 U.S.C. § 103(a). An obviousness analysis involves underlying factual inquiries including (1) the scope and content of the prior art; (2) differences between the claimed invention and the prior art; (3) the level of ordinary skill in the art; and (4) where in evidence, objective indicia of nonobviousness, such as commercial success, long-felt but unmet need, and failure of others. Graham v. John Deere Co., 383 U.S. 1, 1718, 35–36 (1966); Apple Inc. v. Samsung Elecs. Co., 839 F.3d 1034, 1047–48 (Fed. Cir. 2016) (en banc). “An obviousness determination requires finding that a person of ordinary skill in the art would have been motivated to combine or modify the teachings in the prior art and would have had a reasonable expectation of success in doing so.” Regents of Univ. of Cal. v. Broad Inst., Inc., 903 F.3d 1286, 1291 (Fed. Cir. 2018); In re Stepan Co., 868 F.3d 1342, 1345–46, 1346 n.1 (Fed. Cir. 2017). Hence, an obviousness analysis should address “whether there was an apparent reason” to combine or modify “known elements in the fashion claimed by the patent at issue.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007). Moreover, “mere conclusory statements” do not suffice for an apparent reason to combine or modify known elements. In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006). Crediting conclusory statements “risks IPR2019-01352 Patent 7,558,730 B2 11 allowing the challenger to use the challenged patent as a roadmap to reconstruct the claimed invention using disparate elements from the prior art—i.e., the impermissible ex post reasoning and hindsight bias that KSR warned against.” TQ Delta, LLC v. Cisco Sys., Inc., 942 F.3d 1352, 1361 (Fed. Cir. 2019). We analyze the obviousness issues according to these principles. B. Level of Ordinary Skill in the Art Factors pertinent to determining the level of ordinary skill in the art include (1) the educational level of the inventor; (2) the type of problems encountered in the art; (3) prior-art solutions to those problems; (4) the rapidity with which innovations are made; (5) the sophistication of the technology; and (6) the educational level of workers active in the field. Envtl. Designs, Ltd. v. Union Oil Co., 713 F.2d 693, 696–97 (Fed. Cir. 1983). Evidence for these factors may not exist in every case, and one or more of these or other factors may predominate in a particular case. Id. Moreover, these factors are not exhaustive, but are merely a guide to determining the level of ordinary skill in the art. Daiichi Sankyo Co. v. Apotex, Inc., 501 F.3d 1254, 1256 (Fed. Cir. 2007). Further, the prior art itself may reflect an appropriate skill level. Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001). In our Institution Decision, we noted that the parties’ respective descriptions of a person of ordinary skill in the art differed in two ways: First, the experience level differed, i.e., “at least . . . one year” according to Petitioner and “about 2 years” according to Patent Owner. Inst. Dec. 11; see Pet. 6; Prelim. Resp. 22. Second, the experience area differed, i.e., “telecommunications or a related field” according to Petitioner and “speech IPR2019-01352 Patent 7,558,730 B2 12 recognition and transcription systems (or its equivalent)” according to Patent Owner. Inst. Dec. 11; see Pet. 6; Prelim. Resp. 22. Based on an analysis of the ’730 patent and the asserted prior art, we determined that a person of ordinary skill in the art would have had “at least a bachelor’s degree in electrical engineering, computer engineering, computer science, electrical and computer engineering, or in some other field related to information sciences and two years of experience in the area of telecommunications applicable to speech recognition and transcription systems.” Inst. Dec. 11–12, 14; see Ex. 1001, 1:17–21, 2:36–3:13, 3:44–5:29, 5:66–6:3, 6:50–53, 9:12–45, 11:63–66, 19:27–39, 20:48–52, 25:55–28:56, codes (54), (57); Ex. 1004, 1:21–30, 2:47–3:4, codes (54), (57); Ex. 1006, 2:45–47, 2:54–58, 7:15–24, 7:46–52, 8:45–62, 9:15–21, codes (54), (57). Although Petitioner does not dispute our determination of the level of ordinary skill in the art, Patent Owner does. See Resp. 8–14; Reply 4–7. Specifically, Patent Owner asserts that a person of ordinary skill in the art would have had “a bachelor of science degree in electrical engineering, computer engineering, computer science, electrical and computer engineering, or some other field related to information sciences (or its equivalent)” and “at least 1 year of experience in the design of speech recognition and transcription systems or the equivalent graduate experience in speech recognition and transcription systems.” Resp. 8 (citing Ex. 2014 ¶ 28). Patent Owner also asserts that “a modification of a system that implements speech recognition and transcription requires an understanding and a level of expertise in speech recognition and transcription.” Id. at 13; see id. at 10. IPR2019-01352 Patent 7,558,730 B2 13 Petitioner disagrees with Patent Owner’s description of an ordinarily skilled artisan. See Reply 4–7. Petitioner asserts that Patent Owner’s description wrongly “requires experience with, not only ‘speech recognition and transcription systems,’ but specifically the design of such systems, and does not expand the pertinent experience through equivalency.” Id. at 5. In addition, Petitioner contends that “[b]y the time of the ’730 patent, there already were in existence conventional speech recognition and transcription engines that received speech data and produced a transcript based on the speech data.” Id. at 5–6 (citing Ex. 1001, 2:18–35; Ex. 1003 ¶¶ 33–39; Ex. 1024, 21:4–7, 23:7–18; Prelim. Resp. 4). Petitioner also contends that “Patent Owner makes no attempt to suggest these systems were deficient in any way for use as the claimed ‘speech recognition and transcription engine.’” Id. at 6. For the reasons explained below, we agree with Petitioner that an ordinarily skilled artisan need not have had “experience in the design of speech recognition and transcription systems or the equivalent graduate experience in speech recognition and transcription systems” according to Patent Owner’s description. See Resp. 8; see also Inst. Dec 11–14. Claims 15 and 17 each recite “a speech recognition and transcription engine” that receives speech data and produces a transcript based on the speech data. Ex. 1001, 27:29–36, 28:16–22. The ’730 patent discusses conventional engines that received speech data and produced a transcript based on the speech data, i.e., Dragon Dictate and IBM ViaVoice. Id. at 2:18–35; see Ex. 1011, 2:15–23; Ex. 1024, 22:11–23:14; Ex. 2014 ¶ 40; Tr. 36:7–18. Moreover, other conventional engines received speech data and produced a transcript based on the speech data, e.g., Dragon IPR2019-01352 Patent 7,558,730 B2 14 NaturallySpeaking and Lernout & Hauspie Voice Xpress. Ex. 1003 ¶¶ 33–39; Ex. 2007, 191–932; Ex. 2008, 31–32, 35; Ex. 2011, 49; Ex. 2012; see Resp. 4 (citing Ex. 2008, 31; Ex. 2012, 46). The ’730 patent does not explain “the inner workings of” any conventional engine. Ex. 1024, 20:23–21:7; see Ex. 2005, 79:18–21. Instead, the patent describes “a black box speech recognition technology of any sort [that] can be plugged in and can be used to support” transcription needs. Ex. 2005, 71:1–13; see id. at 68:21–24, 69:18–24, 76:4–10, 79:18–21; Ex. 2015, 50:17–22. Patent Owner does not allege a deficiency in a conventional engine preventing its use as the claimed “speech recognition and transcription engine.” See Resp. 3–5, 8–14; Tr. 36:7–18. In addition, Dr. Anderson admits that the ’730 patent contemplates “work[ing] with systems that may be available from other sources,” e.g., commercially available or off-the- shelf software for speech recognition and transcription. Ex. 1024, 50:13–19. Hence, an ordinarily skilled artisan could use a conventional engine as the claimed “speech recognition and transcription engine.” Because an ordinarily skilled artisan could use a conventional engine as the claimed “speech recognition and transcription engine,” the skilled artisan need not have had “experience in the design of speech recognition and transcription systems or the equivalent graduate experience in speech recognition and transcription systems” according to Patent Owner’s 2 For this and other publications, a page number in the citation references a page number in the publication itself rather than a page number added by a party, e.g., Page 1, Page 2, Page 3, etc. IPR2019-01352 Patent 7,558,730 B2 15 description of an ordinarily skilled artisan. See Resp. 8; see also Inst. Dec 11–14. Hence, we decline to adopt Patent Owner’s description. Based on the complete record, we determine that a person of ordinary skill in the art would have had at least a bachelor’s degree in electrical engineering, computer engineering, computer science, electrical and computer engineering, or in some other field related to information sciences and two years of experience in the area of telecommunications applicable to speech recognition and transcription systems. For the reasons explained above, this level of skill comports with the description in the ’730 patent and the prior art of record. But even if we did adopt Patent Owner’s description of an ordinarily skilled artisan, that would not change our patentability determinations. See infra §§ III.D–III.E. Because Dr. Creusere allegedly lacks “experience in the design of speech recognition and transcription systems or the equivalent graduate experience in speech recognition and transcription systems,” Patent Owner asserts that “the Board should be skeptical of Dr. Creusere’s obviousness opinions and should afford them little weight.” Resp. 13. Given our determination that an ordinarily skilled artisan need not have had such experience, we disagree with Patent Owner’s assertion. In any event, we would consider Dr. Creusere’s experience sufficiently relevant even under Patent Owner’s description of an ordinarily skilled artisan. See Ex. 1003 ¶¶ 5–18, App. A; Ex. 1025 ¶¶ 5–7; Ex. 2017; Ex. 2018. There is no requirement for a perfect match between an expert’s experience and the IPR2019-01352 Patent 7,558,730 B2 16 relevant field. See SEB S.A. v. Montgomery Ward & Co., 594 F.3d 1360, 1373 (Fed. Cir. 2010); Consolidated Trial Practice Guide at 34.3 C. Claim Construction 1. GENERALLY In an inter partes review, claims “shall be construed using the same claim construction standard that would be used to construe the claim in a civil action” under 35 U.S.C. § 282(b). 37 C.F.R. § 42.100(b) (2019). Under that standard, “[c]laim terms are given their ordinary and customary meaning, which is the meaning the term would have to a person of ordinary skill in the art at the time of the invention.” Power Integrations, Inc. v. Fairchild Semiconductor Int’l, Inc., 904 F.3d 965, 971 (Fed. Cir. 2018) (citing Phillips v. AWH Corp., 415 F.3d 1303, 1312–13 (Fed. Cir. 2005) (en banc)). The meaning of claim terms may be determined by “look[ing] principally to the intrinsic evidence of record, examining the claim language itself, the written description, and the prosecution history, if in evidence.” DePuy Spine, Inc. v. Medtronic Sofamor Danek, Inc., 469 F.3d 1005, 1014 (Fed. Cir. 2006) (citing Phillips, 415 F.3d at 1312–17). The ’730 patent provides “general definitions” for numerous terms. Ex. 1001, 5:50–8:28; see Pet. 9 (citing Ex. 1001, 5:50–8:29). Petitioner asserts that the district court in the related civil action “adopt[ed] a series of constructions that had been stipulated by the parties,” including many constructions “taken directly from a set of explicitly defined terms” in the ’730 patent. Pet. 8–9; see Ex. 1021 (Order Granting Stipulation Regarding 3 Available at https://www.uspto.gov/TrialPracticeGuideConsolidated. IPR2019-01352 Patent 7,558,730 B2 17 Claim Construction). Petitioner “submits that these agreed-upon constructions should be applied in this proceeding.” Pet. 8–9. When analyzing the patentability issues in our Institution Decision, we applied the stipulated constructions. See, e.g., Inst. Dec. 19–20, 32–45, 64–72. In their respective papers, the parties also applied the stipulated constructions. See, e.g., Pet. 9–12, 18–19, 33, 38; Resp. 6–8, 27–28, 50; Reply 4; Sur-reply 8; Ex. 2014 ¶ 27. Hence, we see no reason to depart from the stipulated constructions. As for other terms, the parties dispute the meaning of “speech.” See Resp. 6–8; Reply 3–4; Sur-reply 11–12; Tr. 12:2–10, 42:13–43:13, 52:5–7. 2. “SPEECH” The ’730 patent defines “Speech” as “Spoken text and spoken and embedded commands, which the System may transcribe or process.” Ex. 1001, 7:22–23. Patent Owner contends that an inventor’s lexicography governs and that “Speech” requires “spoken text” combined with “spoken and embedded commands.” See Resp. 6–8; Sur-reply 11–12; Tr. 12:2–10, 42:13–43:13, 52:5–7. Petitioner contends that the ’730 patent “includes several descriptions of the term ‘speech’ that show it was intended to include ‘spoken text’ and may optionally include ‘spoken and embedded commands.’” Reply 3–4 (emphasis by Petitioner) (citing Ex. 1001, 8:66–9:2, 10:33–35; Ex. 1024, 40:15–25). We disagree with Patent Owner that “Speech” requires “spoken text” combined with “spoken and embedded commands.” See Resp. 7. Patent Owner’s proposed construction rests on the ’730 patent’s definition of IPR2019-01352 Patent 7,558,730 B2 18 “Speech” in isolation. But “claim construction requires that we ‘consider the specification as a whole, and [ ] read all portions of the written description, if possible, in a manner that renders the patent internally consistent.’” Baxalta Inc. v. Genentech, Inc., 972 F.3d 1341, 1347 (Fed. Cir. 2020) (alteration in original) (quoting Budde v. Harley-Davidson, Inc., 250 F.3d 1369, 1379–80 (Fed. Cir. 2001)). An analysis of the ’730 patent’s specification as a whole indicates that “Speech” includes “spoken text” and may include “spoken and embedded commands.” For example, the specification explains that “[s]peech to be transcribed is generated primarily as spoken text” and that “spoken text, which can include spoken and/or imbedded [sic] commands is captured and obtained using any well-known methods and devices for capturing audio signals.” Ex. 1001, 8:66–9:2. Further, the specification states that “a Formatted Speech Information Request . . . comprises formatted spoken text and typically includes formatted spoken and embedded commands.” Id. at 9:13–16. The specification similarly states that “a Speech Information Request . . . includes formatted spoken text, and may include formatted spoken and embedded commands.” Id. at 10:33–35; see id. at 10:39–52. In addition, the specification notes that a user with a legacy protocol “may create a Speech Information Request, which includes formatted spoken text and perhaps formatted spoken and embedded commands.” Id. at 17:40–45. Patent Owner’s construction of “Speech” excludes these specific embodiments. See Resp. 7–8; Sur-reply 11–12. A construction that excludes a preferred embodiment is “rarely, if ever correct.” PPC Broadband, Inc. v. Corning Optical Commc’ns RF, LLC, 815 F.3d 747, 755 (Fed. Cir. 2016). “[W]here claims can reasonably [be] interpreted to include IPR2019-01352 Patent 7,558,730 B2 19 a specific embodiment, it is incorrect to construe the claims to exclude that embodiment, absent probative evidence on the contrary.” Oatey Co. v. IPS Corp., 514 F.3d 1271, 1277 (Fed. Cir. 2008). Here, Patent Owner identifies no such probative evidence. See Resp. 6–8. Because the ’730 patent explains that “Speech” encompasses either “spoken text” alone or “spoken text” combined with “spoken and embedded commands,” we decline to construe “Speech” as requiring “spoken text” combined with “spoken and embedded commands.” 3. OTHER TERMS We determine that no other claim terms require explicit constructions to decide the patentability issues. “[O]nly those terms need be construed that are in controversy, and only to the extent necessary to resolve the controversy.” Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999); see Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017). D. Obviousness over Skladman and Obilisetty Petitioner contends that claims 15 and 17 are unpatentable under § 103(a) as obvious over Skladman and Obilisetty. See Pet. 7–8, 12–44. Below, we provide overviews of Skladman and Obilisetty, and then we consider the obviousness issues raised by the parties. For the reasons explained below, we agree with Petitioner that claims 15 and 17 are unpatentable under § 103(a) as obvious over Skladman and Obilisetty. 1. OVERVIEW OF SKLADMAN (EX. 1004) Skladman discloses a communications system “for providing unified messaging services for transferring different types of electronic messages,” including voicemail, e-mail, and facsimile messages. Ex. 1004, 1:21–30. IPR2019-01352 Patent 7,558,730 B2 20 Skladman explains that “[e]ach type of electronic message requires its own transmission protocol and access mechanism.” Id. at 1:30–32. Skladman also explains that “unified messaging systems have been developed” to permit message retrieval by a user through “a single access interface.” Id at 1:43–47. But Skladman identifies a drawback with those systems, specifically, “they do not interface to existing (‘legacy’) messaging systems.” Id. at 1:63–65. Hence, Skladman provides “an improved unified messaging system that permits” integrating “one or more legacy messaging systems” into the unified messaging system. Id. at 2:49–52; see id. at 2:7–9, code (57). “To integrate the legacy systems,” Skladman’s unified messaging system includes “a unified message server, a proxy interface, and a message protocol converter.” Ex. 1004, 2:58–60, code (57). The proxy interface accesses “the legacy systems in response to a request from the unified message server.” Id. at 2:60–62, code (57). The protocol converter converts messages “stored on the legacy system” to “a predetermined format usable by the unified message server.” Id. at 2:63–65, code (57). The “converted messages are then transferred to the unified message server.” Id. at 2:65–66, code (57). The unified message server “provid[es] messages from [the] different messaging systems,” including voicemail, e-mail, and facsimile messages, “to users in a predetermined format.” Id. at 2:66–3:1, code (57). According to Skladman, this arrangement advantageously “permits enterprise-wide communication systems to provide unified messaging without abandoning pre-existing legacy messaging systems.” Id. at 3:1–4, code (57). IPR2019-01352 Patent 7,558,730 B2 21 Skladman’s Figures 1a and 1b (reproduced below) depict a block diagram of a unified messaging system. Ex. 1004, 2:16–18, 3:5–8, code (57). Figures 1a and 1b illustrate unified messaging system 20 including enterprise communications system 22, telephone company central office 24, and unified messaging center 26 that “provides unified messaging services to the enterprise 22.” Id. at 3:5–17. IPR2019-01352 Patent 7,558,730 B2 22 Enterprise communications system 22 includes legacy e-mail server 28 and middleware server 34 comprising proxy interface 52 and protocol converter 54. Ex. 1004, 3:20–23, 4:9–14, Figs. 1b, 2b. Telephone company central office 24 includes legacy voicemail server 50. Id. at 3:32– 33, 4:11–12, 4:26–27, Figs. 1a, 2a. Among other things, unified messaging center 26 includes unified message server 64 and router 70. Ex. 1004, 6:8–10, Figs. 1a, 2a. Unified message server 64 communicates through router 70 with middleware server 34. Id. at 4:9–23, 4:34–37, Figs. 1a–1b, 2a–2b. Middleware server 34 communicates with voicemail server 50 and e-mail server 28. Id. at 3:23–25, 4:9–23, 4:34–37, code (57), Figs. 1a–1b, 2a–2b. Unified message server 64 may send middleware server 34 a request, e.g., an internet protocol (IP) packet, “containing predetermined data representing a command to access a specific legacy messaging system.” Ex. 1004, 4:21–27, code (57). “[U]pon receiving a request from the unified message server 64,” proxy interface 52 connects to either voicemail server 50 or e-mail server 28. Id. at 4:21–23, code (57); see id. at 9:10–15, Fig. 6. Proxy interface 52 “establishes communication sessions with the legacy messaging systems so that messages stored by the systems can be accessed and retrieved.” Id. at 4:14–17. After message retrieval, protocol converter 54 converts “the retrieved messages into one or more predetermined formats usable by” unified message server 64, e.g., a “standard digital format” for unified message server 64. Id. at 2:63–65, 4:17–20, 9:23–27, code (57), Fig. 6. After protocol conversion, protocol converter 54 routes the converted messages to unified message server 64. Ex. 1004, 4:17–20, 9:25–27, code IPR2019-01352 Patent 7,558,730 B2 23 (57), Fig. 6. Then, unified message server 64 provides “messages from [the] different messaging systems to users in a predetermined format.” Id. at 2:65–3:1, code (57); see id. at 7:57–8:32, Fig. 4. For example, unified message server 64 may use the transmission control protocol/internet protocol (TCP/IP) to communicate with a user via the Internet and to communicate with middleware server 34. Id. at 6:6–7, 6:14–17, 7:57–59, 7:64–8:3, 8:27–32, 8:47–55, Figs. 1a–1b, 4; see id. at 2:23–25, 3:62–64, 6:26–29. In an example regarding voicemail messages, Skladman states that middleware server 34 accesses voicemail messages at voicemail server 50 and digitizes the voicemail messages using “a standard audio/digital code (A/D) converter.” Ex. 1004, 4:65–5:11. The digitized voicemail messages “are then converted and compressed” by protocol converter 54 using “standard digital audio compression formats.” Id. at 5:11–14. Those standard formats may produce a .wav file suitable for use as an e-mail attachment “that can be audibly played back at a user’s PC.” Id. at 5:11–14, 6:48–51. After digitization and compression, protocol converter 54 “transfers these compressed, digitized” voicemail messages to “unified message server 64 by way of communications network 47.” Id. at 5:14–17. Skladman’s Figure 4 (reproduced below) depicts a block diagram of an interface between unified message server 64 and various communication networks. Ex. 1004, 2:23–25, 7:57–59. IPR2019-01352 Patent 7,558,730 B2 24 Figure 4 illustrates interface 120 including text-to-speech (TTS) generator 122, facsimile interface 124, dual-tone multi-frequency (DTMF) dialer 126, TCP/IP interface 128, and modem interface 130. Id. at 7:64–8:1, Fig. 4; see id. at 6:55–59. Interface 120 connects unified message server 64 to “each of the various communication networks 56–62,” i.e., Internet 56, cellular network 58, paging network 60, and public switched telephone network (PSTN) 62. Ex. 1004, 8:1–3; see id. at 2:23–25, 6:22–34, 7:57–59, Figs. 1a, 2a, 3a, 4. For instance, facsimile interface 124 permits unified message server 64 “to transfer messages to subscribers by” facsimile. Id. at 8:18–20. In addition, DTMF dialer 126 connects unified message server 64 “to each of the communications networks that rely on a conventional dial-up telecommunications network, such as the PSTN 62.” Id. at 8:23–26. Further, TCP/IP interface 128 permits unified message server 64 “to IPR2019-01352 Patent 7,558,730 B2 25 communicate messages to subscribers over data networks using the TCP/IP protocol, such as the Internet.” Id. at 8:29–32. TTS generator 122 in interface 120 “generates spoken messages in response to computer readable text messages received from” unified message server 64. Ex. 1004, 8:7–9. For example, TTS generator 122 may convert e-mail messages to audible messages that a user can listen to over the phone. Id. at 6:55–58. Moreover, a user may configure unified message server 64 “to deliver different types of messages to an e-mail account that is accessible over the Internet.” Ex. 1004, 6:25–28. More specifically, unified message server 64 may place a user’s messages in an e-mail account where the user “can then retrieve them using standard e-mail software on a PC.” Id. at 6:40–48. Further, unified message server 64 may provide voicemail messages as e-mail attachments “that can be audibly played back at a user’s PC.” Id. at 6:48–51. Thus, “a user may choose to receive all incoming faxes, voice mails and e-mails by way of an e-mail account.” Id. at 1:49–52; see id. at 9:57–60. 2. OVERVIEW OF OBILISETTY (EX. 1005) Obilisetty discloses “a centrally manageable and accessible system” for “capturing, transcribing, and delivering information.” Ex. 1005, 9:13–16; see id. at 2:44–47, 6:4–14, 7:61–8:2, 8:25–40, code (57), Figs. 3A–3B, 4. Obilisetty describes high costs for obtaining and maintaining dictation devices. Id. at 1:66–2:8, code (57). Obilisetty identifies a need to “reduce the costs associated with the purchase, operation and maintenance of prior art dictation devices.” Id. at 2:26–29. Obilisetty then explains that the “present invention provides a method and system that can reduce the costs IPR2019-01352 Patent 7,558,730 B2 26 associated with the purchase, operation and maintenance of prior art dictation devices,” e.g., by centrally locating certain system components. See id. at 2:37–3:11, 8:25–9:17, code (57), Fig. 4. Obilisetty’s Figure 3A is reproduced below: Figure 3A shows a system for capturing, transcribing, and delivering information. Ex. 1005, 4:19–21, 6:4–7, 9:13–16. Specifically, Figure 3A illustrates (1) “speech portal 310 (e.g., a telephone)” communicatively coupled to “intelligent communication server (ICS) 315”; (2) ICS 315 “communicatively coupled to computer system 390 (e.g., a Web server)”; and (3) computer system 390 “communicatively coupled to transcription service provider 330.” Id. at 6:6–14; see id. at 6:40–41, 6:55–56. ICS 315 “provide[s] access to a public switched telephone network (PSTN).” Ex. 1005, 6:44–46. ICS 315 also “receive[s] and digitize[s] IPR2019-01352 Patent 7,558,730 B2 27 information into voice files” and “forward[s] the voice files to computer system 390.” Id. at 6:46–49, 7:39–42. “Computer system 390 then sends the voice file to transcription service provider 330.” Id. at 7:46–48. “[T]ranscription service provider 330 returns to computer system 390 a transcript file providing a transcribed version of the voice file,” e.g., a transcript file “formatted according to conventional word processing applications (such as Microsoft Word), XML (Extensible Markup Language), or HL7.” Id. at 8:41–48. Computer system 390 provides a transcript file “to the end user in a variety of different ways,” e.g., for viewing “on a portable device” or “by accessing a Web site.” Id. at 8:49–9:12, code (57). Obilisetty states that “the present invention is well- suited for use with any number of” speech portals, servers, and transcription service providers to permit scale up in size. Id. at 6:15–22, 8:2–5. Obilisetty discloses an embodiment where “transcription service provider 330 is a computer system or other such device (e.g., a word processor) that can be coupled to the Internet, receive and play voice files, and send voice files and transcript files (that is, a file containing the transcribed version of a voice file).” Ex. 1005, 6:58–63. In that embodiment, transcription service provider 330 is “exemplified by computer system 190 of FIG. 2.” Id. at 6:63–64; see id. at 4:16–18, 5:29–6:3, Fig. 2. In addition, Obilisetty discloses “automatically” downloading files to and uploading files from transcription service provider 330. Id. at 3:24–26, 7:58–60, 8:41–45, 10:57–61. IPR2019-01352 Patent 7,558,730 B2 28 3. CLAIM 15 (a) Preamble Claim 15’s preamble recites “[a] system for facilitating speech recognition and transcription among users.” Ex. 1001, 27:14–15. Petitioner contends that the combined disclosures in Skladman and Obilisetty teach claim 15’s preamble. Pet. 17. Specifically, Petitioner asserts that Skladman discloses a system for interfacing unified messaging systems with legacy systems, e.g., legacy voicemail systems. Id. at 17–18 (citing Ex. 1004, 2:47–3:4, 7:50–56, code (57), Figs. 2a–2b). To support Petitioner’s arguments, Dr. Creusere testifies that Skladman discloses “a system for facilitating communication between systems employing heterogenous [sic] protocols.” Ex. 1003 ¶ 48 (citing Ex. 1004, code (57)). Petitioner also asserts that Obilisetty discloses “a centralized system for transcription of speech.” Pet. 18. Patent Owner makes no arguments specific to claim 15’s preamble. See, e.g., Resp. 15–62; Sur-reply 18–22.4 Generally, a preamble does not limit a claim. Allen Eng’g Corp. v. Bartell Indus., Inc., 299 F.3d 1336, 1346 (Fed. Cir. 2002). Here, we need not decide whether claim 15’s preamble limits the claim because we agree with Petitioner that the combined disclosures in Skladman and Obilisetty teach the preamble. See Pet. 17–18. 4 Any arguments Patent Owner has not raised in its Response are waived. See Novartis AG v. Torrent Pharm. Ltd., 853 F.3d 1316, 1330 (Fed. Cir. 2017); In re NuVasive, 842 F.3d 1376, 1381 (Fed. Cir. 2016); see also Paper 11, 7 (cautioning Patent Owner that “any arguments for patentability not raised in the response may be deemed waived”). IPR2019-01352 Patent 7,558,730 B2 29 Specifically, Skladman discloses a communications system “for providing unified messaging services for transferring different types of electronic messages,” including voicemail, e-mail, and facsimile messages. Ex. 1004, 1:21–30. The different types of electronic messages may include legacy voicemail messages and legacy e-mail messages that employ “proprietary message protocols and formats.” Id. at 2:52–54; see id. at 4:9–20. To accommodate the heterogeneous system protocols of legacy messaging systems, Skladman provides “an improved unified messaging system that permits” integrating “one or more legacy messaging systems” into the unified messaging system. Id. at 2:49–52; see id. at 2:7–9, code (57). Skladman’s system facilitates the exchange of speech and other information among a network of users having heterogeneous system protocols. See Ex. 1003 ¶¶ 47–48. In addition, Obilisetty discloses “a centrally manageable and accessible system” for “capturing, transcribing, and delivering information” where a transcription service provider supplies “a transcribed version of [a] voice file.” Ex. 1005, 8:41–48, 9:13–16; see id. at 2:44–47, 6:4–14, 7:61– 8:2, 8:25–40, code (57), Figs. 3A–3B, 4. Obilisetty’s system facilitates speech recognition and transcription. See Ex. 1003 ¶ 50. For the reasons discussed above, the combined disclosures in Skladman and Obilisetty teach “[a] system for facilitating speech recognition and transcription among users” according to claim 15’s preamble. (b) System Transaction Manager Claim 15 recites “a system transaction manager, the system transaction manager utilizing a uniform system protocol for handling speech information requests and responses to speech information requests, the IPR2019-01352 Patent 7,558,730 B2 30 speech information requests and responses comprising, respectively, formatted spoken text and formatted transcriptions of the formatted spoken text.” Ex. 1001, 27:16–22. The parties agree that a “system transaction manager” is “a server application that provides a central interconnect point (hub) and a communications interface among system components and Users having disparate or heterogeneous protocols; and, an information router (or bridge or switch) within the Speech Recognition and Transcription System.” Pet. 11, 18–19; Resp. 27–28, 50; see Ex. 1001, 7:51–56; Ex. 1021, 2; Ex. 2014 ¶ 27. We adopt the agreed-upon construction. Petitioner contends that the combined disclosures in Skladman and Obilisetty teach the “system transaction manager” limitation. See Pet. 18–33; Reply 7–12. In particular, Petitioner argues that Skladman’s unified messaging center 26 “serve[s] as a system transaction manager.” Pet. 19; see id. at 25; Ex. 1003 ¶ 59. Petitioner addresses the various aspects of the “system transaction manager” limitation as explained below. (i) Uniform System Protocol, Central Interconnect Point, Communications Interface, and Information Router Petitioner asserts that Skladman’s unified messaging center 26 uses unified message server 64 and router 70 to serve as a central interconnect point and a communications interface among legacy messaging systems and users. Pet. 20–21. In addition, Petitioner contends that unified message server 64 and router 70 handle messages using a “uniform system protocol,” i.e., “a protocol that processes information expressed in a normalized data format.” Id. at 20–22; see Ex. 1003 ¶ 54. Petitioner identifies the transmission control protocol/internet protocol (TCP/IP) disclosed in Skladman as “a protocol that processes information IPR2019-01352 Patent 7,558,730 B2 31 expressed in a normalized data format.” Pet. 22 (citing Ex. 1004, 7:64–8:6, 8:27–32). Petitioner contends that the ’730 patent describes TCP/IP as “an example of a ‘unified system protocol.’” Id. at 22–23 (citing Ex. 1001, 2:63–3:4, 5:60–6:3, code (57)). Patent Owner makes no arguments specific to these aspects of the “system transaction manager” limitation. See, e.g., Resp. 15–62; Sur-reply 18–22. (ii) Handling Speech Information Requests For the claimed “speech information requests,” Petitioner asserts that a voicemail message at voicemail server 50 includes spoken text. Pet. 24; see Ex. 1003 ¶¶ 54, 58. Petitioner also asserts that middleware server 34 (including proxy interface 52 and protocol converter 54) works with voicemail server 50 to transform a voicemail message “into a digitized audio file” suitable for playback. Pet. 24; see Ex. 1003 ¶ 54. In addition, Petitioner contends that protocol converter 54 converts a digitized voicemail message “into the appropriate predetermined (e.g., normalized/unified) format” used by unified message server 64 in unified messaging center 26, “which is mapped as the ‘system transaction manager.’” Pet. 25; see Ex. 1003 ¶ 54. Petitioner identifies digitized and format-converted voicemail messages as the claimed “speech information requests.” Pet. 24; see Ex. 1003 ¶ 54. Patent Owner makes no arguments specific to this aspect of the “system transaction manager” limitation. See, e.g., Resp. 15–62; Sur-reply 18–22. IPR2019-01352 Patent 7,558,730 B2 32 (iii) Handling Responses to Speech Information Requests For the claimed “responses to speech information requests,” Petitioner asserts that transcription functionality for producing formatted transcriptions of formatted speech was well known before the ’730 patent’s effective filing date. Pet. 28; see Ex. 1001, 2:18–35; Ex. 1003 ¶¶ 35–39, 49–50, 65. To support Petitioner’s assertion, Dr. Creusere testifies that systems “capable of computerized transcription of spoken words” had been developed before the ’730 patent’s effective filing date. Ex. 1003 ¶ 35; see id. ¶¶ 36–37, 65; Ex. 1011, 2:15–23; Ex. 1012, 1:49–2:33, 8:40–9:39, code (57); Ex. 1017, 2:22–37, code (57); Ex. 1022, 6:65–7:5, 8:4–5, code (57). Further, Petitioner asserts that Obilisetty discloses a transcription service provider that (1) receives a “voice file containing . . . dictated information” from a remote device via the Internet and (2) returns a “transcript file providing a transcribed version of the voice file” to a computer system via the Internet. Pet. 28–29 (citing Ex. 1005, 3:19–50, 6:34–36, 6:58–64, 7:39–42, 7:46–48, 8:25–43, 8:49–62, code (57), Fig. 3A); see Ex. 1003 ¶¶ 50, 55. Petitioner also asserts that an ordinarily skilled artisan would have combined Obilisetty’s transcription service provider 330 with Skladman’s network interface for unified message server 64, i.e., interface 120. Pet. 31–32; see Ex. 1003 ¶ 56. To show the proposed combination, Petitioner provides a modified version of Skladman’s Figure 4 as reproduced below: IPR2019-01352 Patent 7,558,730 B2 33 According to Petitioner, this modified version of Figure 4 depicts Obilisetty’s transcription service provider 330 added to Skladman’s interface 120. Pet. 31–32; see Ex. 1003 ¶ 56; Ex. 1025 ¶ 11. In Petitioner’s proposed combination, interface 120 still includes the following components: text-to-speech (TTS) generator 122, facsimile interface 124, dual-tone multi-frequency (DTMF) dialer 126, TCP/IP interface 128, and modem interface 130. Ex. 1004, 7:64–8:1, Fig. 4; see id. at 6:55–59. Petitioner contends that in the proposed combination (1) TTS generator 122 would provide text-to-speech services to unified message server 64 and (2) transcription service provider 330 would provide speech- to-text services to unified message server 64. Pet. 41; see Ex. 1003 ¶¶ 56–57, 59; Ex. 1025 ¶¶ 8–11. Specifically, Petitioner asserts that transcription service provider 330 would provide unified message server 64 with a “formatted transcription” of a formatted voicemail message. Pet. 31; see Ex. 1003 ¶¶ 57, 60; Ex. 1025 ¶ 11. Petitioner further asserts that the IPR2019-01352 Patent 7,558,730 B2 34 “other interfaces in block 120—fax interface 124, DTMF Dialer 126, TCP/IP Stack 128, and Modem Interface 130—are utilized by the unified message server for communicating with a user through one of the networks identified in blocks 132–142.” Pet. 41–42 (citing Ex. 1004, 7:57–8:32); see Ex. 1003 ¶ 60; Ex. 1025 ¶ 10. To show message flow in the proposed combination, Petitioner provides annotated versions of Skladman’s Figures 2a and 2b combined with Skladman’s modified Figure 4 as reproduced below: Paper 30, 14. The above annotated figures show (1) voicemail server 50 sending a message to middleware server 34, (2) middleware server 34 sending the message to router 70, (3) router 70 sending the message to unified message server 64, (4) unified message server 64 sending the message to interface 120, and (5) interface 120 sending the message to a user. Id. The above annotated figures also show two-way communication between unified message server 64 and interface 120. Id. IPR2019-01352 Patent 7,558,730 B2 35 Petitioner explains that “there is a distinction between the components” in interface 120. Reply 10; see Ex. 1025 ¶ 10. Petitioner contends that only components 124–130 in interface 120 would provide “communication paths between” unified message server 64 and a user. Reply 10; see Ex. 1025 ¶¶ 10–11. Petitioner also contends that TTS generator 122 and transcription service provider 330 would “provide their respective services” to unified message server 64 rather than a user, unlike components 124–130 in interface 120. Reply 10; see Ex. 1025 ¶¶ 10–11. To support Petitioner’s arguments, Dr. Creusere testifies that an ordinarily skilled artisan “would have understood that the TTS 122 module does not itself include the communication infrastructure necessary to communicate with” a user. Ex. 1025 ¶ 10. He also testifies that an ordinarily skilled artisan “would have understood that Skladman contemplates relying on the TTS module solely to provide the text to audio conversion, rather than also including duplicative communication infrastructure within the TTS module.” Id. (emphasis omitted). In addition, Dr. Creusere testifies that transcription service provider 330 “would have been most efficient as a component” within interface 120 that serves unified message server 64 and “does itself not contain communications infrastructure” to reach users directly. Id. ¶ 11. In addition, Petitioner contends that with the proposed combination a user would “receive formatted transcriptions of their voicemail messages through” unified message server 64 and interface 120. Pet. 32, 41–42; see id. at 38–39; Ex. 1003 ¶¶ 56–57, 59. Petitioner identifies formatted transcriptions of voicemail messages as the claimed “responses to speech information requests.” Pet. 32–33; see Ex. 1003 ¶ 56; Ex. 1025 ¶ 11. IPR2019-01352 Patent 7,558,730 B2 36 Patent Owner contends that the proposed combination does not produce a “system transaction manager . . . for handling . . . responses to speech information requests” as required by the “system transaction manager” limitation. See Sur-reply 18–20, 22. Specifically, Patent Owner asserts that Skladman does not disclose two-way communication between unified message server 64 and interface 120. Id. at 18. Regarding TTS generator 122 in interface 120, Patent Owner asserts that “interface 120 has all the functionality that it needs to perform” text-to- speech conversion and then communicate an audible message directly to a user rather than return the audible message to unified message server 64. Sur-reply 20. According to Patent Owner, interface 120 may communicate an audible message to a user either directly through DTMF dialer 126 or indirectly through DTMF dialer 126 coordinating with fax interface 124 or modem interface 130. Id. Further, interface 120 would use transcription service provider 330 like TTS generator 122 and communicate a textual message directly to a user rather than return the textual message to unified message server 64. See id. (iv) Analysis For the reasons explained below, we agree with Petitioner that the combined disclosures in Skladman and Obilisetty teach the “system transaction manager” limitation. See Pet. 18–33; Reply 7–12; Ex. 1003 ¶¶ 47, 54–57; Ex. 1025 ¶¶ 8–11. In Skladman’s system, unified messaging center 26 includes unified message server 64 and router 70. Ex. 1004, 6:8–10, Figs. 1a, 2a. Unified message server 64 communicates through router 70 with middleware server 34. Id. at 4:9–23, 4:34–37, Figs. 1a–1b, 2a–2b. Middleware IPR2019-01352 Patent 7,558,730 B2 37 server 34 includes proxy interface 52 and protocol converter 54. Id. at 4:9–14, Fig. 2b. Middleware server 34 communicates with voicemail server 50 and e-mail server 28. Id. at 3:23–25, 4:9–23, 4:34–37, code (57), Figs. 1a–1b, 2a–2b. In Skladman’s system, unified message server 64 and router 70 serve as a central interconnect point and a communications interface among legacy messaging systems and users according to the “system transaction manager” limitation. For example, unified message server 64 may send middleware server 34 a request, e.g., an internet protocol (IP) packet, “containing predetermined data representing a command to access a specific legacy messaging system.” Ex. 1004, 4:21–27, code (57). “[U]pon receiving a request from the unified message server 64,” proxy interface 52 connects to either voicemail server 50 or e-mail server 28. Id. at 4:21–23, code (57); see id. at 9:10–15, Fig. 6. Proxy interface 52 “establishes communication sessions with the legacy messaging systems so that messages stored by the systems can be accessed and retrieved.” Id. at 4:14–17. After message retrieval, protocol converter 54 converts “the retrieved messages into one or more predetermined formats usable by” unified message server 64, e.g., a “standard digital format” for unified message server 64. Id. at 2:63–65, 4:17–20, 9:23–27, code (57), Fig. 6. A “standard digital format” for unified message server 64 corresponds to a “uniform system protocol,” i.e., “a protocol that processes information expressed in a normalized data format.” See Ex. 1001, 6:50–53, 17:22–24; Ex. 1003 ¶ 54; Ex. 1004, 2:63–65, 4:17–20, 9:23–27, code (57); Ex. 1021, 1; Ex. 2014 ¶ 27. For example, unified message server 64 may use the transmission control protocol/internet protocol (TCP/IP) to communicate IPR2019-01352 Patent 7,558,730 B2 38 with middleware server 34. Ex. 1004, 6:6–7, 6:14–17, 8:47–55, Figs. 1a–1b; see id. at 3:62–64, 6:26–29. The ’730 patent identifies TCP/IP as a “uniform system protocol.” Ex. 1001, 6:2–3. After protocol conversion, protocol converter 54 routes the converted messages to unified message server 64. Ex. 1004, 4:17–20, 9:25–27, code (57), Fig. 6. Then, unified message server 64 provides “messages from [the] different messaging systems to users in a predetermined format.” Id. at 2:65–3:1, code (57); see id. at 7:57–8:32, Fig. 4. Hence, unified message server 64 and router 70 serve as a central interconnect point and a communications interface among legacy messaging systems and users according to the “system transaction manager” limitation. Further, router 70 corresponds to “an information router (or bridge or switch)” according to the “system transaction manager” limitation. Ex. 1004, 6:8–10, 6:17–20; see Ex. 1003 ¶¶ 47, 59. Also, a voicemail message at voicemail server 50 includes spoken text. See Ex. 1003 ¶¶ 54, 58; Ex. 1004, 4:54–5:17. When protocol converter 54 converts a retrieved voicemail message into a “standard digital format” for unified message server 64, protocol converter 54 generates a “speech information request,” i.e., “Formatted Speech, which can be acted upon by System components, including the System Transaction Manager.” Ex. 1003 ¶ 54; see Ex. 1001, 7:22–25, 7:33–35, 27:19–22; Ex. 1021, 2; Ex. 2014 ¶ 24. As discussed above, a “standard digital format” for unified message server 64 corresponds to a “uniform system protocol.” Hence, when unified message server 64 receives and processes a voicemail message that protocol converter 54 has converted into a “standard digital format,” unified message IPR2019-01352 Patent 7,558,730 B2 39 server 64 utilizes a “uniform system protocol” for handling a “speech information request” according to the “system transaction manager” limitation. See Ex. 1003 ¶ 54; Ex. 1004, 2:63–65, 4:17–20, 9:23–27, code (57), Fig. 6. In addition, we agree with Petitioner that in the proposed combination (1) TTS generator 122 would provide text-to-speech services to unified message server 64 and (2) transcription service provider 330 would provide speech-to-text services to unified message server 64. See Pet. 41; Ex. 1003 ¶¶ 56–57, 59; Ex. 1025 ¶¶ 8–11. In Skladman’s system, a user may choose to receive textual messages audibly, e.g., as .wav files “that can be audibly played back at a user’s PC” when attached to e-mails. Ex. 1004, 1:49–52, 6:20–29, 6:35–58; see id. at 5:18–32; Ex. 1003 ¶¶ 40, 55, 57, 59. When a user chooses to receive textual messages audibly, unified message server 64 sends a textual message to TTS generator 122, and TTS generator 122 converts the textual message to an audible message. See Ex. 1004, 6:55–58, 8:7–9; Ex. 1025 ¶ 10. Skladman contains no disclosure indicating that interface 120 includes the functionality for creating an e-mail attachment, e.g., from an audible message produced by TTS generator 122. See, e.g., Ex. 1004, 6:20–59, 7:57–8:32, Fig. 4; Ex. 1025 ¶ 10. For instance, creating a .wav file requires audio-compression functionality, and Skladman contains no disclosure indicating that interface 120 includes audio-compression functionality. See Ex. 1004, 5:11–14, 6:45–51, 7:57–8:32, Fig. 4; see also Ex. 1003 ¶¶ 40, 54; Ex. 1016, 4, 10, 13, 16. Instead, Skladman indicates that unified message server 64 includes the functionality for creating an e-mail attachment. See Ex. 1004, 6:20–51. IPR2019-01352 Patent 7,558,730 B2 40 Hence, when TTS generator 122 converts a textual message to an audible message, TTS generator returns the audible message to unified message server 64, and unified message server 64 creates an e-mail attachment from the audible message produced by TTS generator 122. See Ex. 1004, 6:35–58; Ex. 1025 ¶ 10. As Dr. Creusere testifies, an ordinarily skilled artisan would have understood that (1) “the TTS 122 module does not itself include the communication infrastructure necessary to communicate with” a user and (2) “Skladman contemplates relying on the TTS module solely to provide the text to audio conversion, rather than also including duplicative communication infrastructure within the TTS module.” Ex. 1025 ¶ 10 (emphasis omitted). In the proposed combination, unified message server 64 would use transcription service provider 330 like TTS generator 122. See Ex. 1003 ¶¶ 59–60; Ex. 1025 ¶¶ 8–11. In particular, unified message server 64 would send a “voice file” to transcription service provider 330, and transcription service provider 330 would return a “transcript file providing a transcribed version of the voice file” to unified message server 64. See Ex. 1003 ¶¶ 56–57; Ex. 1005, 2:53–60, 3:19–22, 6:58–63, 7:46–48, 8:41–43, 10:57–60, code (57), Fig. 6 (step 605); Ex. 1025 ¶¶ 8, 11. As Dr. Creusere testifies, transcription service provider 330 “would have been most efficient as a component” within interface 120 that serves unified message server 64 and “does itself not contain communications infrastructure” to reach users directly. Ex. 1025 ¶ 11. In the proposed combination, a “transcript file providing a transcribed version of the voice file” that transcription service provider 330 returns to unified message server 64 corresponds to a “response to the speech IPR2019-01352 Patent 7,558,730 B2 41 information request,” i.e., “a formatted transcription of formatted speech.” Ex. 1003 ¶¶ 55–56; see Ex. 1001, 7:11–12, 27:19–22; Ex. 1021, 2; Ex. 2014 ¶ 25. Hence, unified message server 64 handles “responses to speech information requests” according to the “system transaction manager” limitation. See Ex. 1003 ¶¶ 55–56; Ex. 1025 ¶¶ 8, 11. For the reasons discussed above, we agree with Petitioner that the combined disclosures in Skladman and Obilisetty teach the “system transaction manager” limitation. Patent Owner asserts that the Reply includes improper new arguments about TTS generator 122 and transcription service provider 330 and that we should not consider those improper new arguments. See Sur-reply 20–21. We disagree that the Reply includes improper new arguments about TTS generator 122 and transcription service provider 330. In the Petition and the Reply, Petitioner relies on the same disclosures from the same references to support the same legal argument. Compare Pet. 41–43 (citing Ex. 1004, 7:57–8:32, Fig. 4), and Ex. 1003 ¶¶ 55–56, 59–60 (citing Ex. 1004, 5:18–52, 6:21–59, 7:57–8:32, Figs. 2a–2b, 4; Ex. 1005, 6:7–21, 6:34–36, 6:58–64, code (57), Figs. 3A, 6), with Reply 7–12 (citing Ex. 1004, 7:57–8:32, Fig. 4), and Ex. 1025 ¶¶ 8–11 (citing Ex. 1004, 4:14–20, 6:24–34, 7:64–8:31, Figs. 2a–2b, 4). In the Reply, Petitioner provides a further explanation why that evidence demonstrates unpatentability. As an example in the Petition, Petitioner distinguishes TTS generator 122 and transcription service provider 330 from components 124–130 in interface 120. See Pet. 41–42. Specifically, Petitioner asserts that TTS generator 122 and transcription service provider 330 “are utilized for IPR2019-01352 Patent 7,558,730 B2 42 providing either text-to-speech capabilities or speech transcription capabilities to” unified message server 64. Id. at 41. Petitioner next asserts that the “other interfaces in block 120—fax interface 124, DTMF Dialer 126, TCP/IP Stack 128, and Modem Interface 130—are utilized by the unified message server for communicating with a user through one of the networks identified in blocks 132–142.” Id. at 41–42 (citing Ex. 1004, 7:57–8:32). In the Reply, Petitioner further explains that distinction. See Reply 10–12. Petitioner’s further explanation does not amount to a new theory of unpatentability. See Apple Inc. v. Andrea Elecs. Corp., 949 F.3d 697, 706 (Fed. Cir. 2020). In addition, in our Institution Decision we determined preliminarily that “after transcription service provider 330 produces a transcription in the proposed combination, ‘the transcription would then be provided directly to the user,’ just like other ‘messages that would be delivered to users via’ components 122–130 in interface 120.” Inst. Dec. 42 (citing Ex. 1004, 7:57–8:32). The arguments in the Reply address that determination. See Reply 7–12. According to the Board’s Trial Practice Guide, “the Board will permit the petitioner, in its reply brief, to address issues discussed in the institution decision.” Consolidated Trial Practice Guide at 73. (c) First User Application Service Adapter Claim 15 recites “a first user application service adapter communicating with at least one user and the system transaction manager, the first user application service adapter configured to generate speech information requests from spoken text produced by the at least one of the users through a first protocol.” Ex. 1001, 27:23–28. The parties agree that a “user application service adapter” is “a Specific Application Service IPR2019-01352 Patent 7,558,730 B2 43 Adapter that handles formatting and Routing of Speech Information Requests and Responses to elements of a User’s Protocol within the Speech Recognition and Transcription System.” Pet. 10, 33; Resp. 6–8; see Ex. 1001, 8:15–19; Ex. 1021, 2; Ex. 2014 ¶ 27. We adopt the agreed-upon construction. Petitioner contends that Skladman teaches the “first user application service adapter” limitation. See Pet. 34–37; Ex. 1003 ¶ 58. Specifically, Petitioner asserts that voicemail server 50 and middleware server 34 (including proxy interface 52 and protocol converter 54) generate a “speech information request” through the following process. Initially, a user contacts voicemail server 50 and “leave[s] a recorded message that consists of that user’s spoken text” recorded in a legacy audio format corresponding to the claimed “first protocol.” Pet. 34, 37 (citing Ex. 1004, 4:33–47, 4:60–63, 5:5–17); see Ex. 1003 ¶ 58. Next, at the request of unified message server 64, proxy interface 52 collects a voicemail message from voicemail server 50. Pet. 34; see Ex. 1003 ¶ 58. Then, proxy interface 52 digitizes the voicemail message. Pet. 34–35; see Ex. 1003 ¶ 58. After digitization, protocol converter 54 converts the digitized voicemail message into a “uniform system protocol compatible with unified message server 64.” Pet. 35–36; see Ex. 1003 ¶ 58. After format conversion, protocol converter 54 routes the digitized and format-converted voicemail message to unified message server 64 for delivery to an intended recipient. Pet. 35; see Ex. 1003 ¶ 58. As discussed above, Petitioner identifies digitized and format-converted voicemail messages as the claimed “speech information requests.” Pet. 24; see Ex. 1003 ¶ 54; supra § III.D.3(b)(ii). IPR2019-01352 Patent 7,558,730 B2 44 In addition, Petitioner contends that “voicemail server 50 and middleware server 34 constitute an application layer within the voicemail system that provides an interface between a user who is leaving a message and the user who will receive the message.” Pet. 35 (citing Ex. 1004, 4:33–44); see Ex. 1003 ¶ 58. Petitioner also contends that voicemail server 50 and middleware server 34 use “routing information” for a voicemail message, i.e., “envelope information” identifying sender and recipient, to ultimately route the message to unified messaging center 26. Pet. 36 (citing Ex. 1004, 4:33–44); see Ex. 1003 ¶ 58. Patent Owner makes no arguments specific to the “first user application service adapter” limitation. See, e.g., Resp. 15–62; Sur-reply 18–22. We agree with Petitioner that Skladman teaches the “first user application service adapter” limitation because Skladman’s voicemail server 50 and middleware server 34 (including proxy interface 52 and protocol converter 54) function according to the limitation. See Pet. 34–37; Ex. 1003 ¶ 58. Specifically, users communicate with voicemail server 50 by leaving voicemail messages at voicemail server 50. See Ex. 1003 ¶ 58; Ex. 1004, 4:33–47, 4:60–63, 5:5–17. Voicemail messages at voicemail server 50 have a legacy audio format corresponding to the claimed “first protocol.” See Ex. 1003 ¶ 58; Ex. 1004, 2:49–54, 4:9–12, 4:23–27, 5:55–60, 7:11–14, code (57). When unified message server 64 requests voicemail messages from middleware server 34, proxy interface 52 connects to voicemail server 50. Ex. 1004, 4:21–27, code (57); see id. at 9:10–15, Fig. 6; Ex. 1003 ¶ 58. After connecting, proxy interface 52 accesses and retrieves voicemail IPR2019-01352 Patent 7,558,730 B2 45 messages from voicemail server 50. Ex. 1004, 4:14–17; see Ex. 1003 ¶ 58. After message retrieval, protocol converter 54 converts “the retrieved messages into one or more predetermined formats usable by” unified message server 64, e.g., a “standard digital format” for unified message server 64. Ex. 1004, 2:63–65, 4:17–20, 9:23–27, code (57), Fig. 6; see Ex. 1003 ¶ 58. After protocol conversion, protocol converter 54 routes the converted messages to unified message server 64. Ex. 1004, 4:17–20, 9:25–27, code (57), Fig. 6. As discussed above for the “system transaction manager” limitation, a voicemail message at voicemail server 50 includes spoken text. See Ex. 1003 ¶¶ 54, 58; Ex. 1004, 4:54–5:17; supra § III.D.3(b)(iv). Protocol converter 54 generates a “speech information request” when it converts a voicemail message having a legacy audio format into a “standard digital format” for unified message server 64. Ex. 1003 ¶ 54; see Ex. 1001, 7:22–25, 7:33–35, 27:19–22; Ex. 1021, 2; Ex. 2014 ¶ 24; supra § III.D.3(b)(iv). Further, voicemail server 50 and middleware server 34 handle the formatting and routing of a “speech information request” by (1) protocol converting a voicemail message to generate a “speech information request” and (2) routing the “speech information request” to unified message server 64. See Ex. 1003 ¶ 58. For the reasons discussed above, Skladman teaches the “first user application service adapter” limitation. (d) Speech Recognition and Transcription Engine Claim 15 recites “a speech recognition and transcription engine communicating with the system transaction manager, the speech recognition and transcription engine configured to receive speech information requests IPR2019-01352 Patent 7,558,730 B2 46 from the system transaction manager, to generate responses to the speech information requests, and to transmit the responses to the system transaction manager.” Ex. 1001, 27:29–36. The parties agree that a “speech recognition and transcription engine” is “[a] process running on a computer that recognizes an audio file and transcribes that file to written text to generate a transcription of Speech.” Pet. 11–12, 38; Resp. 8; Reply 4; Sur-reply 8; see Ex. 1001, 7:57–60; Ex. 1021, 2; Ex. 2014 ¶ 27. We adopt the agreed- upon construction. Petitioner contends that the combined disclosures in Skladman and Obilisetty teach the “speech recognition and transcription engine” limitation. See Pet. 37–39; Reply 7–12, 17–18. Specifically, Petitioner asserts that Obilisetty teaches “[a] process running on a computer that recognizes an audio file and transcribes that file to written text to generate a transcription of Speech.” Pet. 29; Reply 17–18; see Ex. 1003 ¶ 55. As support, Petitioner identifies Obilisetty’s disclosure that transcription service provider 330 “is a computer system or other such device.” Pet. 29 (quoting Ex. 1005, 6:58–60); see Reply 17. In addition, Petitioner contends that in the proposed combination, Obilisetty’s transcription service provider 330 interfaces with Skladman’s unified message server 64 to transcribe voicemail messages received by unified message server 64 from protocol converter 54. Pet. 31, 38; see Reply 7–8; Ex. 1003 ¶ 56. Petitioner also contends that transcription service provider 330 “working in communication with” unified message server 64 “would constitute the speech recognition and transcription engine.” Pet. 39; see Ex. 1003 ¶¶ 56–57. IPR2019-01352 Patent 7,558,730 B2 47 According to Petitioner, the proposed combination would “generate a response to the speech information request by creating a formatted transcription of the formatted speech contained in the voicemail message.” Pet. 38; see Ex. 1003 ¶¶ 55–56. Petitioner contends that Skladman “teaches that this process would occur through communications with the unified message server 64, where it could then be provided to the user.” Pet. 38–39 (citing Ex. 1004, 6:52–59, 7:64–8:32, Fig. 6); see Reply 10–12; Ex. 1003 ¶¶ 55–56, 59–60; Ex. 1025 ¶¶ 8–11. Patent Owner disputes that the combined disclosures in Skladman and Obilisetty teach the “speech recognition and transcription engine” limitation. Sur-reply 8–11, 18–20, 22; see Resp. 27–33, 57–61; Tr. 43:14–45:4. Specifically, Patent Owner asserts that “Obilisetty discloses human transcription not automatic computerized transcription.” Resp. 31; see Ex. 2014 ¶¶ 63, 70, 109, 114. Patent Owner also asserts that “every instance where Obilisetty describes the actual transcription function (as opposed to the forwarding of the transcription), it clearly refers to human transcription.” Sur-reply 10 (citing Ex. 1005, 1:34–35, 2:19–26, 3:5–7, 7:29–32). According to Patent Owner, “Obilisetty only identifies the word transcriber as applying to a user who transcribes documents, never in the sense of an automatic transcription engine.” Resp. 30, 60; see Ex. 2014 ¶¶ 69, 113. Patent Owner admits that “Obilisetty discloses that in one embodiment the transcription service provider 330 may be ‘a computer system or other such device (e.g., a word processor) that can be coupled to the Internet, receive and play voice files, and send voice files and transcript files (that is, a file containing the transcribed version of a voice file).’” Resp. 29, 32, 59 (quoting Ex. 1005, 6:58–64); see Sur-reply 9. But Patent IPR2019-01352 Patent 7,558,730 B2 48 Owner asserts that this disclosure “describes a workflow with a person listening to speech and typing transcriptions.” Resp. 29–30, 59; see Ex. 2014 ¶¶ 66, 112. Patent Owner also asserts that this disclosure does not “refer to automatic transcription” because “automatic transcription operates on digital sound files and does not require playback” for a human transcriber. Resp. 32; see Ex. 2014 ¶¶ 71, 115. Patent Owner further assets that “a word processor was not an automatic transcription engine but rather a tool for a human user to enter text.” Resp. 32; see id. at 32–33; Sur-reply 8–9; Ex. 2014 ¶¶ 71, 115. In addition, Patent Owner contends that the proposed combination does not produce a “speech recognition and transcription engine communicating with the system transaction manager” that “transmit[s] the responses to the system transaction manager” as required by the “speech recognition and transcription engine” limitation. See Sur-reply 18–20, 22. Patent Owner disputes that the proposed combination “transmit[s] the responses to the system transaction manager” for the same reasons that Patent Owner disputes that the proposed combination produces the “system transaction manager” limitation. Id.; see supra § III.D.3(b)(iii). For the reasons explained below, we agree with Petitioner that the combined disclosures in Skladman and Obilisetty teach the “speech recognition and transcription engine” limitation. See Pet. 37–39; Reply 7–12, 17–18; Ex. 1003 ¶¶ 55–57, 59–60; Ex. 1025 ¶¶ 8–11. As Patent Owner asserts, Obilisetty discloses human transcription. Ex. 1005, 1:30–35, 2:19–25, 3:5–7, 7:27–32, 7:54–56; see Resp. 31; Sur-reply 9–11. But Obilisetty also discloses computerized transcription, i.e., a software process “running on a computer.” Ex. 1005, 6:58–64; see id. IPR2019-01352 Patent 7,558,730 B2 49 at 4:16–18, 5:29–6:3, Fig. 2; Ex. 1003 ¶ 55. Specifically, Obilisetty discloses an embodiment where “transcription service provider 330 is a computer system or other such device (e.g., a word processor) that can be coupled to the Internet, receive and play voice files, and send voice files and transcript files (that is, a file containing the transcribed version of a voice file).” Ex. 1005, 6:58–63. In that embodiment, transcription service provider 330 is “exemplified by computer system 190 of FIG. 2.” Id. at 6:63–64; see id. at 4:16–18, 5:29–6:3, Fig. 2. Obilisetty states that computer system 190 includes the following components: (1) processor 101 “for processing information and instructions”; (2) “random access (volatile) memory 102 coupled with bus 100 for storing information and instructions for processor 101”; (3) “read-only (non-volatile) memory 103 coupled with bus 100 for storing static information and instructions for processor 101”; and (4) network interface card (NIC) 108 “to couple computer system 190 to a network 170 (e.g., the Internet).” Id. at 5:33–53, Fig. 2. Obilisetty discloses computerized transcription by describing transcription service provider 330 as “a computer system” that is “exemplified by computer system 190 of FIG. 2.” Ex. 1005, 6:58–64. Obilisetty explains that transcription service provider 330 “can be coupled to the Internet.” Id. at 6:60–61; see id. at 5:51–53, Fig. 2. A computer system that “can be coupled to the Internet” does not correspond to a human transcriber. IPR2019-01352 Patent 7,558,730 B2 50 Moreover, Obilisetty discloses “automatically” downloading files to and uploading files from transcription service provider 330. Ex. 1005, 3:24–26, 7:58–60, 8:41–45, 10:57–61. A computer system that can “automatically” download and upload files does not correspond to a human transcriber. As noted above, Patent Owner asserts that Obilisetty’s description of transcription service provider 330 as “a computer system” does not “refer to automatic transcription” because “automatic transcription operates on digital sound files and does not require playback” for a human transcriber. Resp. 32. That assertion disregards Obilisetty’s disclosure of digital sound files. See Ex. 1005, 2:53–55, 3:3–5, 3:12–14, 6:46–49, 7:39–42, 8:9–15, 9:55–58, code (57). Specifically, Obilisetty discloses that a “voice file” contains a “digital recording” of dictated information. Id. at 2:53–55, 3:3–5, code (57); see id. at 3:12–14, 6:46–49, 7:39–42, 8:9–15, 9:55–58. Further, contrary to Patent Owner’s assertion, Obilisetty does not describe “playback” by transcription service provider 330. Ex. 1005, 6:58–64. Rather, Obilisetty explains that transcription service provider 330 can “receive and play voice files.” Id. at 6:58–61. The automatic transcription process begins by playing a “voice file.” See id. at 6:58–63. As noted above, Patent Owner asserts that “a word processor was not an automatic transcription engine but rather a tool for a human user to enter text.” Resp. 32; see id. at 32–33; Sur-reply 8–9. That assertion mischaracterizes Obilisetty’s reference to “a word processor.” See Ex. 1005, 6:58–63. Obilisetty describes transcription service provider 330 as “a computer system” that may include “a word processor.” Id. Consistent with that description, vendors were “developing tight links between their speech IPR2019-01352 Patent 7,558,730 B2 51 recognition programs” and word processors before Obilisetty’s filing date. Ex. 2007, 192; see Ex. 2014 ¶ 126 n.7. For instance, Dragon NaturallySpeaking included a “built-in word processor.” Ex. 2012, 3, 173. Further, with Dragon NaturallySpeaking a user could “dictate into” the commercially available word processors Microsoft Word and Corel WordPerfect, and Dragon NaturallySpeaking could “process Microsoft Word and Corel WordPerfect files.” Id. at 1, 46; see id. at 98, 171. In addition, Dr. Creusere testifies that some systems “capable of computerized transcription of spoken words” had been developed before Obilisetty’s filing date. See Ex. 1003 ¶¶ 35–36 (citing Ex. 1008, U.S. Patent No. 4,430,726; Ex. 1009, U.S. Patent No. 4,692,042; and Ex. 1011, U.S. Patent No. 6,122,614). Other systems “capable of computerized transcription of spoken words” had been developed before Obilisetty’s filing date, such as Dragon NaturallySpeaking, IBM ViaVoice, and Lernout & Hauspie Voice Xpress. Ex. 2007, 191–93; Ex. 2008, 31–32, 35; Ex. 2011, 49; Ex. 2012. Patent Owner identifies no evidence indicating that an ordinarily skilled artisan would have believed that Obilisetty intended to exclude those computerized systems when describing transcription service provider 330 as “a computer system.” See Resp. 28–33, 57–61; Sur-reply 8–11; Ex. 1005, 6:58–64. Patent Owner argues that “Obilisetty was careful to list dozens of alternatives for various aspects of his invention, but automatic speech recognition was conspicuously absent from that description.” Resp. 33; see Ex. 2014 ¶¶ 72, 116. Yet a patent “need not disclose what is well known in the art.” In re Buchner, 929 F.2d 660, 661 (Fed. Cir. 1991). Rather, a patent IPR2019-01352 Patent 7,558,730 B2 52 “preferably omits” what is well known in the art. Hybritech Inc. v. Monoclonal Antibodies, Inc., 802 F.2d 1367, 1384 (Fed. Cir. 1986). For these reasons, an ordinarily skilled artisan would have understood that transcription service provider 330 includes “[a] process running on a computer that recognizes an audio file and transcribes that file to written text to generate a transcription of Speech” according to the “speech recognition and transcription engine” limitation. See Ex. 1003 ¶¶ 55–57, 59–60; Ex. 1005, 6:58–64; Ex. 1025 ¶¶ 8–11. As also noted above, Patent Owner contends that the proposed combination does not produce a “speech recognition and transcription engine communicating with the system transaction manager” that “transmit[s] the responses to the system transaction manager” as required by the “speech recognition and transcription engine” limitation. See Sur-reply 18–20, 22. We disagree with that contention. For the reasons discussed above for the “system transaction manager” limitation, unified message server 64 would send a “voice file” to transcription service provider 330, and transcription service provider 330 would return a “transcript file providing a transcribed version of the voice file” to unified message server 64. See Ex. 1003 ¶¶ 56–57; Ex. 1005, 2:53–60, 3:19–22, 6:58–63, 7:46–48, 8:41–43, 10:57–60, code (57), Fig. 6 (step 605); Ex. 1025 ¶¶ 8, 11; supra § III.D.3(b)(iv). A “transcript file providing a transcribed version of the voice file” that transcription service provider 330 returns to unified message server 64 corresponds to a “response to the speech information request.” Ex. 1003 ¶¶ 55–56. Hence, transcription service provider 330 “transmit[s] the responses to the system IPR2019-01352 Patent 7,558,730 B2 53 transaction manager” as required by the “speech recognition and transcription engine” limitation. Ex. 1003 ¶¶ 55–56; Ex. 1025 ¶¶ 8, 11. For the reasons discussed above, the combined disclosures in Skladman and Obilisetty teach the “speech recognition and transcription engine” limitation. (e) Second User Application Service Adapter Claim 15 also recites “a second user application service adapter communicating with one or more of the users and with the system transaction manager, the second user application service adapter which is different than the first user application service adapter and configured to provide the one or more users with a transcription of the spoken text that is compatible with a second protocol, the second protocol being the same as or different than the first protocol.” Ex. 1001, 27:37–44. As discussed above, a “user application service adapter” is “a Specific Application Service Adapter that handles formatting and Routing of Speech Information Requests and Responses to elements of a User’s Protocol within the Speech Recognition and Transcription System.” Pet. 10, 33; Resp. 6–8; see Ex. 1001, 8:15–19; Ex. 1021, 2; Ex. 2014 ¶ 27; supra § III.D.3(c). Petitioner contends that Skladman teaches the “second user application service adapter” limitation. See Pet. 39–43; Ex. 1003 ¶¶ 59–60. In particular, Petitioner identifies the following components in Skladman’s interface 120 that function individually as the claimed “second user application service adapter”: facsimile interface 124, DTMF dialer 126, TCP/IP interface 128, and modem interface 130. Pet. 41–43; see Ex. 1003 ¶¶ 59–60. IPR2019-01352 Patent 7,558,730 B2 54 Petitioner asserts that components 124, 126, 128, and 130 “are utilized by the unified message server for communicating with a user through one of the networks identified in blocks 132–142.” Pet. 41–42 (citing Ex. 1004, 7:57–8:32); see Ex. 1003 ¶¶ 59–60. According to Petitioner, an ordinarily skilled artisan would have understood that components 124, 126, 128, and 130 “would be used to connect the user to the unified message server 64 to provide the user with the transcribed, formatted speech.” Pet. 42; see Ex. 1003 ¶ 60. Petitioner also asserts that a voicemail message at voicemail server 50 differs in “protocol and format” from the “final transcribed message provided to the user” by unified message server 64 through components 124, 126, 128, and 130. Pet. 42–43; see Ex. 1003 ¶ 60. According to Petitioner, components 124, 126, 128, and 130 “handle routing of the formatted and translated message from” unified messaging center 26 “to the user and would constitute a second user application service adapter.” Pet. 43. Patent Owner makes no arguments specific to the “second user application service adapter” limitation. See, e.g., Resp. 15–62; Sur-reply 18–22. We agree with Petitioner that Skladman teaches the “second user application service adapter” limitation. See Pet. 39–43; Ex. 1003 ¶¶ 59–60; Ex. 1004, 2:23–25, 6:22–34, 7:57–8:32, Figs. 1a, 2a, 3a, 4. In particular, Skladman explains that interface 120 connects unified message server 64 to “each of the various communication networks 56–62,” i.e., Internet 56, cellular network 58, paging network 60, and public switched telephone network (PSTN) 62. Ex. 1004, 8:1–3; see id. at 2:23–25, 6:22–34, 7:57–59, Figs. 1a, 2a, 3a, 4. Among other things, interface 120 includes facsimile IPR2019-01352 Patent 7,558,730 B2 55 interface 124 and TCP/IP interface 128. Id. at 7:64–8:1, Fig. 4. Each of those components handles message formatting and routing according to the agreed-upon construction of “user application service adapter.” See Pet. 10, 33; Resp. 6–8; Ex. 1001, 8:15–19; Ex. 1003 ¶¶ 54, 58–60; Ex. 1004, 7:57–8:32, Fig. 4; Ex. 1021, 2; Ex. 1025 ¶¶ 10–11; Ex. 2014 ¶ 27. Specifically, facsimile interface 124 permits unified message server 64 “to transfer messages,” e.g., transcribed versions of voicemail messages, “to subscribers by” facsimile. Ex. 1004, 8:18–20; see Ex. 1025 ¶ 10. By transferring a particular message to a particular subscriber, facsimile interface 124 routes the message to the subscriber in a format (or protocol) that differs from the legacy audio format (or protocol) for voicemail server 50. See Ex. 1003 ¶¶ 54, 58–60; Ex. 1004, 1:28–32, 4:9–12, 4:54–5:17. Further, TCP/IP interface 128 permits unified message server 64 “to communicate messages,” e.g., transcribed versions of voicemail messages, “to subscribers over data networks using the TCP/IP protocol, such as the Internet.” Ex. 1004, 8:29–32; see Ex. 1025 ¶ 10. By communicating a particular message to a particular subscriber, TCP/IP interface 128 routes the message to the subscriber in a format (or protocol) that differs from the legacy audio format (or protocol) for voicemail server 50. See Ex. 1003 ¶¶ 54, 58–60; Ex. 1004, 1:28–32, 4:9–12, 4:54–5:17. For the reasons discussed above, Skladman teaches the “second user application service adapter” limitation. (f) Combining the Teachings of the References Petitioner asserts that an ordinarily skilled artisan would have been motivated to modify Skladman’s system to “transcribe voicemail messages” IPR2019-01352 Patent 7,558,730 B2 56 into text according to Obilisetty’s teachings to “accommodate different methods of providing the message to the user.” Pet. 29–30; see Ex. 1003 ¶¶ 55–56. To support Petitioner’s assertion, Dr. Creusere testifies that incorporating Obilisetty’s teachings into Skladman’s system would have furthered Skladman’s “stated goal of ‘providing unified messaging services for transferring different types of electronic messages.’” Ex. 1003 ¶ 57 (quoting Ex. 1004, 1:21–24). Petitioner identifies several reasons that would have prompted an ordinarily skilled artisan to “transcribe voicemail messages” into text. Pet. 30–31; see Ex. 1003 ¶¶ 56–57. In particular, Petitioner asserts that reading a voicemail transcript in an e-mail (1) “can be done discretely,” (2) “can be done in a noisy environment,” (3) “avoids the problem of privacy concerns with someone listening to the voicemail,” and (4) “will be far quicker than dialing in to the voicemail server and listening to a lengthy message.” Pet. 31; see Ex. 1003 ¶ 57. Dr. Creusere identifies the same reasons that would have prompted an ordinarily skilled artisan to “transcribe voicemail messages” into text. Ex. 1003 ¶ 57; see Pet. 30–31. Petitioner asserts that Skladman’s system already provides text-to- speech functionality, e.g., receiving e-mail as voicemail. Pet. 30; see Ex. 1003 ¶¶ 55, 57; Ex. 1004, 6:55–58, 8:7–11, Fig. 4. Petitioner also asserts that an ordinarily skilled artisan would have “recognize[d] that users would have both desired and expected speech-to-text functionality,” e.g., receiving voicemail as e-mail. Pet. 31; see Ex. 1003 ¶ 57. To support Petitioner’s assertions, Dr. Creusere testifies that an ordinarily skilled artisan “would have recognized that receiving any type of message (including a spoken message) in any other form (including a formatted transcription) IPR2019-01352 Patent 7,558,730 B2 57 would have been expected and desired by users of a system intended to allow access to legacy message information in the most convenient form at all times.” Ex. 1003 ¶ 57. Further, Petitioner asserts that an ordinarily skilled artisan would have had a reasonable expectation of success in combining the teachings of Skladman and Obilisetty because speech-to-text functionality “would have been a natural extension” of the text-to-speech functionality that Skladman’s system already provides. Pet. 32–33; see Ex. 1003 ¶ 57. To support Petitioner’s assertion, Dr. Creusere testifies that an ordinarily skilled artisan would have had a reasonable expectation of success for this combination at least because Skladman’s system “already provides users with text-based message access (e.g., email) and audio message (e.g., voicemail) access, and performs the inverse scenario of providing audio-based access to text-based messages via TTS [text-to-speech generator] 122.” Ex. 1003 ¶ 57; see id. ¶ 55. Patent Owner makes no arguments against combining the teachings of Skladman and Obilisetty. See, e.g., Resp. 15–62; Sur-reply 18–22. We agree with Petitioner that an ordinarily skilled artisan would have been motivated to combine the teachings of Skladman and Obilisetty as Petitioner proposes. See Pet. 30–33; Ex. 1003 ¶¶ 55–57. As Petitioner asserts, reading a voicemail transcript in an e-mail (1) “can be done discretely,” (2) “can be done in a noisy environment,” (3) “avoids the problem of privacy concerns with someone listening to the voicemail,” and (4) “will be far quicker than dialing in to the voicemail server and listening to a lengthy message.” See Pet. 31; Ex. 1003 ¶ 57. As Petitioner also asserts, “users would have both desired and expected speech-to-text IPR2019-01352 Patent 7,558,730 B2 58 functionality,” e.g., receiving voicemail as e-mail. See Pet. 31; Ex. 1003 ¶ 57. We also agree with Petitioner that an ordinarily skilled artisan would have had a reasonable expectation of success in combining the teachings of Skladman and Obilisetty because speech-to-text functionality “would have been a natural extension” of the text-to-speech functionality that Skladman’s system already provides. See Pet. 32–33; Ex. 1003 ¶ 57. (g) Objective Indicia of Nonobviousness Patent Owner asserts that the claimed invention addressed the longstanding but unsolved “problem of enabling a user using a legacy protocol to communicate with a separate server capable of communicating with other users using heterogeneous protocols.” Resp. 63; see Ex. 2014 ¶ 123. Patent Owner also asserts that the claimed invention advantageously enabled users of speech-recognition-and-transcription systems “to interface with speech recognition and transcription engines with uniformly accessible databases that contain information for a number of users, including the wide spread availability of specific vocabularies which include phraseology, grammar, and dictionaries, as well as formatting structures for users of such systems.” Resp. 63–64; see Ex. 2014 ¶¶ 124–125. In addition, Patent Owner contends that “the time of the unmet need can be described from the time that these legacy systems came about as early as 1994, but at least in 1999, and continued until approximately 9 years after the issuance of the ’730 Patent when Apple Siri adopted the inventor’s solution.” Resp. 64 (footnote omitted) (citing U.S. Patent No. 8,645,137 not in the record); see Ex. 2014 ¶ 129 (citing U.S. Patent No. 9,318,108 not in the record). As evidence of an unmet need from 1994, Patent Owner cites IPR2019-01352 Patent 7,558,730 B2 59 a May 1994 edition of Computerworld, specifically, its discussion of the “Kurzweil Product.” Resp. 64 n.12 (citing Ex. 2011); see Sur-reply 17; Ex. 2014 ¶ 129 n.8 (citing Ex. 2011). Petitioner contends that Patent Owner “submit[s] no objective, independent evidence of a longstanding problem.” Reply 28. Petitioner also contends that Patent Owner relies on (1) “conclusory statements” from Dr. Anderson, (2) “vague and unexplained citations to prior art translation/dictation offerings in the market,” and (3) “an unsupported argument that the problem existed until Apple released the products Patent Owner now accuses of infringement.” Id. at 28–29. A long-felt but unmet need “is analyzed as of the date of an articulated identified problem and evidence of efforts to solve that problem.” Tex. Instruments Inc. v. Int’l Trade Comm’n, 988 F.2d 1165, 1178 (Fed. Cir. 1993). The analysis should consider “the filing date of the challenged invention to assess the presence of a long-felt and unmet need.” Procter & Gamble Co. v. Teva Pharm. USA, Inc., 566 F.3d 989, 998 (Fed. Cir. 2009). Unsupported assertions that a challenged claim improves upon the prior art do not suffice to establish a long-felt but unmet need. See Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1332–33 (Fed. Cir. 2009). Here, for the problem or problems facing the inventors, the ’730 patent describes “sophisticated” or “high accuracy” networked and centrally located speech-recognition-and-transcription engines as an “efficient way to utilize” automatic speech recognition (ASR) for “large- scale users, especially in the professions.” Ex. 1001, 2:36–42. But the patent identifies a barrier “to implementation of such centralized systems.” Id. at 2:42–43. In particular, the patent explains “most businesses operate IPR2019-01352 Patent 7,558,730 B2 60 using their own internal” system protocols, e.g., “legacy” protocols, that “are very difficult to alter because they are the heart of the internal workings of a business, a computer system, or a hardware interface.” Id. at 2:43–51; see Ex. 2014 ¶ 129. Hence, the inventors addressed “the heterogeneity of different internal entity protocols used by different entities in transacting information flow.” Ex. 1001, 3:1–13; see id. at 3:44–52, 3:56–58, 4:53–55, 5:6–8; Ex. 1003 ¶¶ 43, 48, 50, 53; Ex. 2014 ¶¶ 127–128. To address that issue, the inventors converted between protocols and used a “uniform system protocol” for communications between certain system components. Ex. 1001, 4:20–23, 5:66–6:3, 6:50–53, 9:37–45, 10:37–39, 11:44–50, 11:63–66, 25:58–64, 26:55–59, 27:16–22, 27:50–53, 28:33–39, code (57). Addressing that issue allowed the inventors “to seamlessly interface network application software and enable powerful speech recognition/transcription engines to interface with legacy systems.” Id. at 2:57–60; see id. at 9:12–45; Ex. 2014 ¶¶ 88, 127 (quoting Ex. 1001, 2:42–60, 3:58–62); Resp. 45–46 (quoting Ex. 1001, 2:42–60). Patent Owner offers no evidence of an “articulated identified problem” relating to “the heterogeneity of different internal entity protocols used by different entities in transacting information flow.” See Resp. 62–64; Sur-reply 17; Ex. 2011; Ex. 2014 ¶¶ 122–129. The May 1994 edition of Computerworld states that Kurzweil Applied Intelligence, Inc. “is the first with a Windows-based dictation product,” i.e., Kurzweil Voice, “a general- purpose speech-recognition dictation product.” Ex. 2011, 49. That publication also states that Dragon Systems, Inc. “plans to introduce a Windows version of its Dragon Dictate line of speech-recognition systems IPR2019-01352 Patent 7,558,730 B2 61 this summer.” Id. But that publication does not discuss any problems due to different internal entity protocols used by different entities and does not even mention communication protocols. Id. Even if the record contained evidence of an “articulated identified problem,” Patent Owner offers no evidence of “efforts to solve that problem” by others in the industry before the invention. See Resp. 62–64; Sur-reply 17; Ex. 2014 ¶¶ 122–129; see also WBIP, LLC v. Kohler Co., 829 F.3d 1317, 1334 (Fed. Cir. 2016) (discussing efforts to solve an “articulated identified problem” by an alleged infringer before the invention); Apple Inc. v. Samsung Elecs. Co., 816 F.3d 788, 804–05 (Fed. Cir. 2016) (requiring evidence of unsuccessful efforts to solve an “articulated identified problem” before the invention), vacated in part on other grounds, 839 F.3d 1034 (Fed. Cir. 2016); Geo. M. Martin Co. v. Alliance Mach. Sys. Int’l LLC, 618 F.3d 1294, 1304–05 (Fed. Cir. 2010) (determining that the “need” had been met by others in the industry before the invention); Tex. Instruments, 988 F.2d at 1178 (discussing efforts to solve an “articulated identified problem” by others in the industry before the invention). For instance, Dr. Anderson paraphrases the ’730 patent’s discussion about efforts by the inventors, not others. See Ex. 2014 ¶¶ 124–127. In addition, Patent Owner’s contention that Petitioner “adopted the inventor’s solution” concerns Petitioner’s actions after the ’730 patent issued, not before the invention. Resp. 64; see Ex. 2014 ¶ 129. And even if Petitioner’s actions after the ’730 patent issued were relevant, Patent Owner provides no explanation how Petitioner’s actions relate to the claimed invention. See Resp. 64; Ex. 2014 ¶ 129. Patent Owner “bears the IPR2019-01352 Patent 7,558,730 B2 62 burden of showing that a nexus exists” to the claimed invention. See WMS Gaming, Inc. v. Int’l Game Tech., 184 F.3d 1339, 1359 (Fed. Cir. 1999); see also Fox Factory, Inc. v. SRAM, LLC, 944 F.3d 1366, 1373 (Fed. Cir. 2019) (placing the burden of showing that a nexus exists on a patent owner). Patent Owner fails to shoulder that burden. For the reasons discussed above, Patent Owner fails in its attempt to establish a long-felt but unmet need for the claimed invention. Thus, we accord little probative weight to Patent Owner’s evidence of objective indicia of nonobviousness. (h) Conclusion for Claim 15 For the reasons discussed above, the combined disclosures in Skladman and Obilisetty teach claim 15’s subject matter. See supra §§ III.D.3(b)–III.D.3(e). Further, an ordinarily skilled artisan would have been motivated to combine the teachings of Skladman and Obilisetty as Petitioner proposes and would have had a reasonable expectation of success in doing so. See supra § III.D.3(f). Also, we accord little probative weight to Patent Owner’s evidence of objective indicia of nonobviousness. See supra § III.D.3(g). Hence, we determine that Petitioner has shown by a preponderance of the evidence that claim 15 is unpatentable under § 103(a) as obvious over Skladman and Obilisetty. 4. CLAIM 17 (a) Preamble Claim 17’s preamble recites “[a] method of exchanging transcribed spoken text among users.” Ex. 1001, 28:10–11. Petitioner contends that the combined disclosures in Skladman and Obilisetty teach claim 17’s preamble. Pet. 43. Specifically, Petitioner IPR2019-01352 Patent 7,558,730 B2 63 asserts that the proposed combination “would result in [a] user’s voicemail containing speech being transcribed into text and exchanged with another user.” Id. Patent Owner makes no arguments specific to claim 17’s preamble. See, e.g., Resp. 15–62; Sur-reply 18–22. Generally, a preamble does not limit a claim. Allen Eng’g, 299 F.3d at 1346. Here, we need not decide whether claim 17’s preamble limits the claim because we agree with Petitioner that the combined disclosures in Skladman and Obilisetty teach the preamble. See Pet. 25–33, 39–43; Ex. 1003 ¶¶ 55–57, 59–60. Specifically, Skladman discloses a communications system “for providing unified messaging services for transferring different types of electronic messages,” including voicemail, e-mail, and facsimile messages. Ex. 1004, 1:21–30. In the proposed combination, unified message server 64 would send a “voice file” to transcription service provider 330, and transcription service provider 330 would return a “transcript file providing a transcribed version of the voice file” to unified message server 64. See Ex. 1003 ¶¶ 56–57; Ex. 1005, 2:53–60, 3:19–22, 6:58–63, 7:46–48, 8:41–43, 10:57–60, code (57), Fig. 6 (step 605); Ex. 1025 ¶¶ 8, 11. Then, a user would receive transcribed spoken text from unified message server 64 via interface 120, e.g., through facsimile interface 124 or TCP/IP interface 128. See Ex. 1003 ¶¶ 59–60; Ex. 1004, 2:23–25, 6:22–34, 7:57–8:32, Figs. 1a, 2a, 3a, 4; Ex. 1025 ¶¶ 8, 11. For the reasons discussed above, the combined disclosures in Skladman and Obilisetty teach “[a] method of exchanging transcribed spoken text among users” according to claim 17’s preamble. IPR2019-01352 Patent 7,558,730 B2 64 (b) Method Steps Petitioner contends that claim 17 is unpatentable under § 103(a) as obvious over Skladman and Obilisetty for the same reasons as claim 15. See Pet. 43–44. Patent Owner makes the same patentability arguments for claim 17 as for claim 15. See Resp. 27–33, 57–62; Sur-reply 8–11, 18–20, 22. We agree with Petitioner that claim 17 is unpatentable under § 103(a) as obvious over Skladman and Obilisetty for the same reasons as claim 15. See Pet. 43–44; Ex. 1003 ¶¶ 54–60; Ex. 1025 ¶¶ 8–11; supra §§ III.D.3(b)– III.D.3(g). The method recited in claim 17 parallels the system recited in claim 15. Compare Ex. 1001, 27:14–44, with id. at 28:10–29. Patent Owner describes claim 17 as “[h]ighly similar” to claim 15. Resp. 62. Each claim requires the following elements: (1) “a system transaction manager”; (2) “a first user application service adapter”; (3) “a speech recognition and transcription engine”; and (4) “a second user application service adapter.” Ex. 1001, 27:14–44, 28:10–29. For the reasons discussed above, the combined disclosures in Skladman and Obilisetty teach those elements. See supra §§ III.D.3(b)–III.D.3(e). We note that claim 17 requires a “second protocol that is different than the first protocol,” whereas claim 15 requires a “second protocol” that is “the same as or different than the first protocol.” Ex. 1001, 27:43–44, 28:28–29. But that inconsistency in claim scope does not affect the patentability determination because, as discussed above, facsimile interface 124 and TCP/IP interface 128 route messages in a second format (or protocol) that differs from the first format (or protocol) for voicemail IPR2019-01352 Patent 7,558,730 B2 65 server 50. See Ex. 1003 ¶¶ 54, 58–60; Ex. 1004, 1:28–32, 4:9–12, 4:54–5:17; supra § III.D.3(e). (c) Conclusion for Claim 17 For the reasons discussed above, the combined disclosures in Skladman and Obilisetty teach claim 17’s subject matter. See supra §§ III.D.3(b)–III.D.3(e). Further, an ordinarily skilled artisan would have been motivated to combine the teachings of Skladman and Obilisetty as Petitioner proposes and would have had a reasonable expectation of success in doing so. See supra § III.D.3(f). Also, we accord little probative weight to Patent Owner’s evidence of objective indicia of nonobviousness. See supra § III.D.3(g). Hence, we determine that Petitioner has shown by a preponderance of the evidence that claim 17 is unpatentable under § 103(a) as obvious over Skladman and Obilisetty. E. Obviousness over Skladman, Obilisetty, and Schrage Petitioner contends that claims 15 and 17 are unpatentable under § 103(a) as obvious over Skladman, Obilisetty, and Schrage. See Pet. 7–8, 44–50. Specifically, to the extent that Obilisetty does not teach computerized transcription, i.e., a software process “running on a computer,” Petitioner asserts that Schrage supplies that teaching. Id. at 44–45. Above, we provided overviews of Skladman and Obilisetty. Below, we provide an overview of Schrage, and then we consider the obviousness issues raised by the parties. For the reasons explained below, we agree with Petitioner that claims 15 and 17 are unpatentable under § 103(a) as obvious over Skladman, Obilisetty, and Schrage. IPR2019-01352 Patent 7,558,730 B2 66 1. OVERVIEW OF SCHRAGE (EX. 1022) Schrage discloses a transcription system for “making transcripts from audio signals received from multiple sources, e.g., users.” Ex. 1022, 3:31–35; see id. at 1:14–17, 2:44–52, 3:41–4:17. Schrage explains that a transcription system implemented with a “speech recognizer” employed as a “shared resource” allows for “the use of a far more expensive, and potentially far more accurate, speech recognizer than individual users of the system could afford to purchase independently” and “eliminat[es] the need for customers to invest in transcription equipment.” Id. at 3:20–30; see id. at 2:24–41. Schrage’s Figure 3 (reproduced below) depicts a schematic diagram for a transcription system. Ex. 1022, 4:26–31, 5:5–6:3. IPR2019-01352 Patent 7,558,730 B2 67 Figure 3 illustrates communications system 10 including switching network 11, transcript server 12, and transcription system 13. Id. at 4:42–5:6. Switching network 11 couples remotely located communication units U1 through Un to transcript server 12 via communication channels C1 through Cn. Ex. 1022, 4:43–53. The “communication units and transcript server may be located in separate buildings, towns, or even different countries.” Id. at 4:53–56. IPR2019-01352 Patent 7,558,730 B2 68 Transcript server 12 “normally records audio signals from each communication channel separately.” Ex. 1022, 4:57–62, 6:53–56, Fig. 4B (step 416). Transcript server 12 communicates with transcription system 13 and provides recordings to transcription system 13. Id. at 4:56–57, 4:65–67, 6:65–66, Fig. 4B (step 418). Transcription system 13 performs “a speech recognition operation on recordings received from” transcript server 12. Ex. 1022, 4:67–5:2. In particular, transcription system 13 performs “an automated speech recognition operation on the recorded speech.” Id. at 6:66–7:2, Fig. 4B (step 420); see id. at 3:52–59, 3:65–67, code (57). After performing that automated operation, transcription system 13 generates “a transcript, e.g., a set of text corresponding to recognized speech in the recording, for each recording received from” transcript server 12. Id. at 7:2–5, Fig. 4B (step 422); see id. at 2:55–60, 3:60–62, 3:65–4:3, code (57). After generating a transcript, transcription system 13 returns the transcript to transcript server 12. Ex. 1022, 7:23–26. Then, transcript server 12 delivers the transcript to one or more users. Id. at 7:22–27, 7:35–37. “Transcript delivery may be in electronic form, e.g., by transmitting an electronic version of the generated transcript as part of an E-mail, e.g., as a file attachment, to a computer 18 via, the Internet 17, a LAN connection, or another connection.” Id. at 7:27–31. 2. CLAIMS 15 AND 17 (a) Speech Recognition and Transcription Engine Claims 15 and 17 each recite “a speech recognition and transcription engine.” Ex. 1001, 27:29–36, 28:16–22. As discussed above, a “speech recognition and transcription engine” is “[a] process running on a computer IPR2019-01352 Patent 7,558,730 B2 69 that recognizes an audio file and transcribes that file to written text to generate a transcription of Speech.” Pet. 11–12, 38; Resp. 8; Sur-reply 8; see Ex. 1001, 7:57–60; Ex. 1021, 2; Ex. 2014 ¶ 27; supra § III.D.3(d). To the extent that Obilisetty does not teach computerized transcription, Petitioner asserts that the Skladman-Obilisetty system as modified by Schrage’s teachings “would have created the claimed speech recognition and transcription engine.” Pet. 48–49; see Ex. 1003 ¶¶ 64–65. In particular, Petitioner contends that Schrage discloses “a centralized transcription server that includes an automated speech-to-text system running on a computer that recognizes the speech and provides a transcription of the audio in the form of written text.” Pet. 45–46 (citing Ex. 1022, 5:5–54, 6:9–7:5, code (57)); see Ex. 1003 ¶ 64. Petitioner also contends that Schrage’s centralized transcription server would fit with Skladman’s centrally located components and that the resulting system “would utilize a process running on a computer to generate the response to the speech information request.” Pet. 47–48; see Ex. 1003 ¶ 64. For the Skladman-Obilisetty-Schrage ground, Patent Owner makes no arguments specific to the “speech recognition and transcription engine” limitation. See, e.g., Resp. 15–62; Sur-reply 18–22. We agree with Petitioner that the Skladman-Obilisetty system as modified by Schrage’s teachings “would have created the claimed speech recognition and transcription engine.” See Pet. 48–49; Ex. 1003 ¶¶ 64–65. Specifically, Schrage discloses transcription system 13 that performs “a speech recognition operation on recordings received from” transcript server 12. Ex. 1022, 4:67–5:2. In particular, transcription system 13 performs “an automated speech recognition operation on the recorded IPR2019-01352 Patent 7,558,730 B2 70 speech.” Id. at 6:66–7:2, Fig. 4B (step 420); see id. at 3:52–59, 3:65–67, code (57). Hence, transcription system 13 comprises “[a] process running on a computer that recognizes an audio file and transcribes that file to written text to generate a transcription of Speech” according to the “speech recognition and transcription engine” limitation. Id. at 3:65–67, 4:67–5:2, 6:65–7:5, code (57). Further, after performing “an automated speech recognition operation,” transcription system 13 generates “a transcript, e.g., a set of text corresponding to recognized speech in the recording, for each recording received from” transcript server 12. Id. at 7:2–5, Fig. 4B (step 422); see id. at 2:55–60, 3:60–62, 3:65–4:3, code (57). And after generating a transcript, transcription system 13 returns the transcript to transcript server 12 for delivery to one or more users, e.g., in electronic form as an e-mail attachment. Ex. 1022, 7:22–31, 7:35–37. Hence, a transcript generated by transcription system 13 corresponds to a “response to the speech information request,” i.e., “a formatted transcription of formatted speech.” See Ex. 1001, 7:11–12, 27:19–22; Ex. 1021, 2; Ex. 2014 ¶ 25. For the reasons discussed above, the combined disclosures in Skladman, Obilisetty, and Schrage teach “a speech recognition and transcription engine” according to claims 15 and 17. (b) Other Limitations For the reasons discussed above for the Skladman-Obilisetty ground, the combined disclosures in Skladman and Obilisetty teach the other limitations in claims 15 and 17. See supra §§ III.D.3(b)–III.D.3(e), III.D.4(b). IPR2019-01352 Patent 7,558,730 B2 71 (c) Combining the Teachings of the References To the extent that Obilisetty does not teach computerized transcription, Petitioner asserts that an ordinarily skilled artisan would have been motivated to modify the Skladman-Obilisetty system according to Schrage’s teachings to computerize transcription. Pet. 48. In particular, Petitioner contends that an ordinarily skilled artisan would have been motivated to computerize transcription “rather than rely on human translators because a computerized transcription system is faster than human transcription and more efficient to manage and maintain.” Id. To support Petitioner’s arguments, Dr. Creusere testifies that an ordinarily skilled artisan would have been motivated to computerize transcription in the Skladman-Obilisetty system “because a computerized transcription system is faster and less error-prone than human transcription and more efficient to manage and maintain.” Ex. 1003 ¶ 65 (citing Ex. 1022, 3:1–19). Further, Petitioner asserts that an ordinarily skilled artisan would have had a reasonable expectation of success in modifying the Skladman- Obilisetty system according to Schrage’s teachings. Pet. 48. To support Petitioner’s assertion, Dr. Creusere testifies that an ordinarily skilled artisan would have had a reasonable expectation of success in modifying the Skladman-Obilisetty system according to Schrage’s teachings because Obilisetty and Schrage each describe “transcription by a central, dial-in transcription server.” Ex. 1003 ¶ 65. For the Skladman-Obilisetty-Schrage ground, Patent Owner makes no arguments against combining Schrage’s teachings with the teachings of Skladman and Obilisetty. See, e.g., Resp. 15–62; Sur-reply 18–22. IPR2019-01352 Patent 7,558,730 B2 72 For the reasons stated by Dr. Creusere, we agree with Petitioner that an ordinarily skilled artisan would have been motivated to modify the Skladman-Obilisetty system according to Schrage’s teachings to computerize transcription and would have had a reasonable expectation of success in doing so. See Ex. 1003 ¶ 65; Ex. 1005, 2:37–3:11, 8:25–9:17, code (57), Fig. 4; Ex. 1022, 2:22–41, 3:1–30, 4:56–5:2, 6:66–7:5, code (57). For example, “a computerized transcription system is faster and less error- prone than human transcription and more efficient to manage and maintain.” Ex. 1003 ¶ 65. (d) Conclusion for Claims 15 and 17 For the reasons discussed above, the combined disclosures in Skladman, Obilisetty, and Schrage teach the subject matter of claims 15 and 17. See supra §§ III.D.3(b)–III.D.3(e), III.D.4(b), III.E.2(a). Further, an ordinarily skilled artisan would have been motivated to modify the Skladman-Obilisetty system according to Schrage’s teachings to computerize transcription and would have had a reasonable expectation of success in doing so. See supra § III.E.2(c). Also, we accord little probative weight to Patent Owner’s evidence of objective indicia of nonobviousness. See supra § III.D.3(g). Hence, we determine that Petitioner has shown by a preponderance of the evidence that claims 15 and 17 are unpatentable under § 103(a) as obvious over Skladman, Obilisetty, and Schrage. F. Obviousness over Cohn and Obilisetty Petitioner contends that claims 15 and 17 are unpatentable under § 103(a) as obvious over Cohn and Obilisetty. See Pet. 7–8, 50–73. Above, we provided an overview of Obilisetty. Below, we provide an overview of Cohn, and then we consider the obviousness issues raised by the parties. For IPR2019-01352 Patent 7,558,730 B2 73 the reasons explained below, we disagree with Petitioner that claims 15 and 17 are unpatentable under § 103(a) as obvious over Cohn and Obilisetty. 1. OVERVIEW OF COHN (EX. 1006) Cohn discloses a “network-based voice and multimedia communications system” for “communications including voice mail, electronic mail, facsimile transmissions, voice transmissions and video transmissions.” Ex. 1006, 2:45–47, 2:54–58, Fig. 1; see id. at 7:15–24, 7:46–52, 8:45–62, 9:15–21, code (54). Cohn explains that “there has been little effort to supply large scale integrated network functionality to” messaging systems “within a single organization” or “within a single local exchange carrier facility” due to “the largely local nature of messaging facilities and the incompatibility of proprietary messaging protocols.” Id. at 1:41–48. Cohn also explains that “even messaging systems that are working in the same media, for example, two voice messaging systems, may be incapable of transferring information and messages between the systems due to the differences in the protocols used by the systems to process and transfer messages.” Id. at 2:22–27. Hence, Cohn’s system provides, among other things, “improved network-based voice messaging and multimedia communications.” Id. at 1:19–23; see id. at 2:41–58. Cohn’s Figure 1 (reproduced below) depicts a block diagram of a network-based voice and multimedia communications system. Ex. 1006, 6:43–44, 7:15–24. IPR2019-01352 Patent 7,558,730 B2 74 Figure 1 illustrates communications system 10 “comprising a number of network hubs 12, 14 and 16” and network center 37 coupled to one another through communications network 18. Id. at 7:15–21, 7:56–58, 23:25–28, 30:21–29, code (57). Cohn’s Figure 2 (reproduced below) depicts a block diagram of a network hub in Cohn’s communications system. Ex. 1006, 6:45–47, 11:2–7. IPR2019-01352 Patent 7,558,730 B2 75 Figure 2 illustrates internal interface 56 coupling analog connection processor 52, digital connection processor 54, file server 59, network processor 60, management processor 64, media translator 69, and event processor 70 within the network hub. Id. at 11:20–30, 11:44–54, 12:4–6, Fig. 2. Figure 2 also illustrates external interface 62 coupling network processor 60, management processor 64, and control processors 66 within the network hub to other network hubs and network center 37. Id. at 11:45–47, 11:53–57, 11:63–64, Fig. 2; see id. at 23:23–31, Fig. 13. In each network hub, analog connection processor 52 and digital connection processor 54 “interact with messaging systems connected to the particular network hub.” Ex. 1006, 11:4–9, code (57); see id. at 6:45–47, 16:8–46, Fig. 2. Analog connection processor 52 “communicates with external messaging systems that use analog communication protocols,” e.g., certain voicemail systems. Id. at 11:9–13; see id. at 6:51–53, 10:3–10, 13:52–59, 14:15–22, 16:8–11, Fig. 4. Digital connection processor 54 “communicates with external messaging systems that use digital IPR2019-01352 Patent 7,558,730 B2 76 communication protocols.” Id. at 11:13–15; see id. at 6:59–61, 10:5–15, 15:30–43, 15:49–52, 16:8–11, Fig. 6. Cohn’s Figure 13 (reproduced below) depicts a block diagram of the network center in Cohn’s communications system. Ex. 1006, 7:8–9, 23:23–25. Figure 13 shows network center 37 including “an operations center management system 153 and an [sic] central access and control system 155 coupled to external interface 62.” Id. at 23:28–31, Fig. 13. Figure 13 also shows central access and control system 155 coupled to master database 151 and various systems, such as billing system 159 and message-tracking system 163. Id. at 23:31–35, Fig. 13. Cohn’s communications system “operates to process and route communications traffic from a wide variety of message sources and to a wide variety of message destinations.” Ex. 1006, 7:21–24; see id. at IPR2019-01352 Patent 7,558,730 B2 77 9:15–21. To do so, the network hubs “operate as protocol translation facilities” that allow the system to interconnect “any of a large number of disparate messaging systems employing differing protocols.” Id. at 9:8–12; see id. at 8:1–4. Hence, the system permits “messaging between dissimilar, proprietary messaging systems by supporting disparate communication protocols.” Id. at 10:17–21; see id. at 22:49–57. In particular, a source network hub interfacing with a source messaging system receives a message from that system “using the protocol native to that system.” Ex. 1006, 9:15–18; see id. at 2:54–63, 10:1–5, 13:55–59, 15:49–52. The source network hub converts the message to a “network transmission format” according to a “shared internal protocol.” Id. at 10:8–24; see id. at 11:49–52, 16:20–21, 16:30–31, 22:36–40. After protocol conversion, the source network hub transmits the message to a destination network hub interfacing with a destination messaging system. Id. at 10:10–13. The destination network hub converts the message to a protocol “understood by” the destination messaging system. Id. at 10:13–15; see id. at 13:55–59, 15:49–52, 23:9–21. After protocol conversion, the destination network hub transmits the message to the destination messaging system. Id. at 10:13–15; see id. at 2:54–63. In Cohn’s communications system, each network hub includes a media translator that “perform[s] media and format conversions,” e.g., “convert[s] the format of data” and “translate[s] the media of messages.” Ex. 1006, 12:52–55, 16:20–21, 22:29–31, 22:66–67; see id. at 3:22–26, 4:57–62, 5:21–27, 8:22–26, 11:32–35, 13:46–49, 22:21–23:21, Fig. 12. Among other things, the media translator “performs the translations of messages from one media to another such as, for example, the translation of IPR2019-01352 Patent 7,558,730 B2 78 an electronic mail message into a voice message using a text to speech system.” Id. at 13:46–49. The “media translation features include the ability to translate text to speech, facsimile images to text and text images, text and text images to facsimile images, and speech to text.” Id. at 22:67–23:3. Cohn’s Figure 12 (reproduced below) depicts a block diagram of a media translator at each network hub in Cohn’s communications system. Ex. 1006, 7:6–7, 22:21–24. Figure 12 shows “media translator 69 compris[ing] a control module 133 and a translator bank 144.” Id. at 22:24–26. Translator bank 144 “convert[s] the format of data” and “translate[s] the media of messages.” Ex. 1006, 22:29–31. Translator bank 144 comprises a plurality of translators 144a–144n. Id. at 22:33–34, Fig. 12. Each of translators 144a–144n in translator bank 144 accomplishes “a stage of the conversion to be performed by translator bank 144.” Id. at 22:34–36. Control module 133 causes translator bank 144 to use an appropriate sequence of filters “to accomplish any permutation of media-to-media translation, message-to-message transformation or data-to-data conversion.” Id. at 22:44–48. IPR2019-01352 Patent 7,558,730 B2 79 2. ANALOGOUS OR NONANALOGOUS ART The parties dispute whether Cohn is analogous art. See Pet. 50–51; Resp. 42 & n.6; Reply 13–15. We need not resolve that dispute because, as explained below, Petitioner has not shown by a preponderance of the evidence that claims 15 and 17 are unpatentable under § 103(a) as obvious over Cohn and Obilisetty. See infra § III.F.3(c). So we assume without deciding that Cohn is analogous art. 3. COMBINING THE TEACHINGS OF THE REFERENCES (a) Petitioner’s Contentions Petitioner contends that each of Cohn’s network hubs includes a translator bank with transcription functions, i.e., software for speech recognition and transcription. See Pet. 67–69; Ex. 1003 ¶¶ 61–62; Tr. 20:23–21:2. Petitioner asserts that an ordinarily skilled artisan would have been motivated to modify Cohn’s system to replace the transcription functions at Cohn’s network hubs with Obilisetty’s “single centralized transcription function” located at Cohn’s network center. Pet. 57, 63; see id. at 53–54, 62; Ex. 1003 ¶ 61. Petitioner explains that the proposed combination relocates the transcription functions in the translator banks at the network hubs to the network center according to Obilisetty’s teachings. Pet. 69; see Ex. 1003 ¶ 62; Tr. 28:17–29:10. In the proposed combination with the transcription functions relocated to the network center, Petitioner maps the claimed “speech recognition and transcription engine” to the transcription functions at the network center. Pet. 63; see id. at 69; Ex. 1003 ¶ 62. Petitioner maps the claimed “system transaction manager” to the “modified network center” because “it is a centralized point that handles” speech information requests and responses. IPR2019-01352 Patent 7,558,730 B2 80 Pet. 61–62; see Ex. 1003 ¶ 62. Petitioner maps the claimed “first user application service adapter” to the “unmodified portions of” a “network hub serving a sending user.” Pet. 69–70; see id. at 67; Ex. 1003 ¶ 63. And Petitioner maps the claimed “second user application service adapter” to the “unmodified portions of” a “network hub serving a receiving user.” Pet. 70–71; see Ex. 1003 ¶ 63. Further, Petitioner identifies three reasons that would have prompted an ordinarily skilled artisan to relocate the transcription functions in the translator banks at the network hubs to the network center. Pet. 57–59; see Ex. 1003 ¶¶ 61–62. First, Petitioner asserts that centralizing the transcription functions at the network center would have provided “a single, centralized transcription system that is simpler and more efficient to manage and maintain.” Pet. 57; see Ex. 1003 ¶ 61. According to Petitioner, centralizing the transcription functions would have saved time and processing overhead because (1) many messages may not require transcription and (2) for messages not requiring transcription, each network hub “need only accommodate disparate protocols between sender and receiver.” Pet. 58; see Ex. 1003 ¶ 61. In addition, Petitioner contends that centralizing the transcription functions would have “reduc[ed] the number of components that would need to be updated” when new software became available. Pet. 57–58; see Ex. 1003 ¶ 61. Second, Petitioner asserts that centralizing the transcription functions at the network center would have “reduced the cost of the overall system” by “reducing internal hardware components duplicated within each network hub.” Pet. 57–58; see Ex. 1003 ¶ 61. To support Petitioner’s assertion, Dr. Creusere testifies that centralizing the transcription functions would have IPR2019-01352 Patent 7,558,730 B2 81 (1) minimized “costly equipment and building infrastructures containing that equipment” and (2) reduced costs by “removing unnecessary duplication of hardware across many hubs.” Ex. 1003 ¶ 61. Third, Petitioner asserts that Cohn teaches centralizing certain functionality at the network center, such as message tracking, operations monitoring, and hub updating. Pet. 55–56, 59 (citing Ex. 1006, 8:56–62, 10:33–50, 23:23–40, 33:55–34:6, Figs. 1, 13); see Ex. 1003 ¶ 62. Petitioner contends that Cohn “expressly contemplates embodiments” that centralize “a portion of its network hubs (steps performed by network processor 60, an element within each hub)” as “a task on a central server.” Pet. 59 (quoting Ex. 1006, 16:64–66); see Ex. 1003 ¶ 61. (b) Patent Owner’s Contentions Patent Owner disputes that an ordinarily skilled artisan would have been motivated to modify Cohn’s system to replace the transcription functions at Cohn’s network hubs with Obilisetty’s “single centralized transcription function” located at Cohn’s network center. See Resp. 20–47; Sur-reply 5–8, 15–17; Ex. 2014 ¶¶ 49–90. Patent Owner argues that “Petitioner’s proposed reconfiguration of Cohn in combination with Obilisetty contradicts the intended purpose of Cohn.” Resp. 25; see Sur-reply 16; Ex. 2014 ¶¶ 58–59. Specifically, Patent Owner asserts that to “effectively address the problems of multi-modal messaging across” multiple networks, Cohn proposed a communications system having multiple network hubs at the system’s boundaries so the hubs “could translate messages entering and leaving” the system. Resp. 34; see Ex. 2014 ¶ 75. Patent Owner also asserts that “[h]aving multiple hubs as Cohn described is an efficient way to handle IPR2019-01352 Patent 7,558,730 B2 82 the processing load.” Resp. 37; see Ex. 2014 ¶¶ 54, 79. According to Patent Owner, an ordinarily skilled artisan would have understood that “such an architecture is scalable in that, as the network or system size increases, additional hubs may be deployed to handle the heavy lifting of processing the additional messages.” Resp. 34–35; see Ex. 2014 ¶ 75. In addition, Patent Owner contends that “Cohn teaches a decentralized approach to translation so that ‘the communications system of the present invention can easily be adapted as new communications protocols . . . become popular.’” Resp. 42 (alteration by Patent Owner) (quoting Ex. 1006, 10:24–27); see Ex. 2014 ¶ 84. Patent Owner also contends that by “performing translation at the individual hubs” instead of “at some centralized location ‘[t]he network hubs that are required to interface with systems utilizing these new protocols need only translate the new protocol to the internal protocol. As such, the operation of the communications system as a whole can support the addition of unlimited new protocols.’” Resp. 42–43 (alteration by Patent Owner) (quoting Ex. 1006, 10:27–32); see Ex. 2014 ¶ 84. Patent Owner asserts that the “distributed nature of the processing” at Cohn’s network hubs is “critical.” Resp. 40; see Ex. 2014 ¶ 82. To support Patent Owner’s assertion, Dr. Anderson testifies that Petitioner’s proposed relocation of the transcription functions to the network center “would have been analogous to suggesting that McDonald’s foods should make hamburgers in their corporate headquarters.” Ex. 2014 ¶ 51. Patent Owner argues that relocating the transcription functions from the network hubs to the network center would have negatively impacted system performance by causing the following problems: IPR2019-01352 Patent 7,558,730 B2 83 (1) “introduc[ed] a processing bottleneck at the media translation processor—significant resources may be required to handle peak load and messages will have to queue up for processing”; (2) “substantially increas[ed] the network traffic as data is passed from the hubs to the network center and back before normal routing is resumed—this can be even more extreme if the network is widely distributed (e.g. spanning multiple facilities”; (3) “increas[ed] the management and communication requirements of the hub message processing—instead of having a linear message handling path at the hub, the hub must now account for variable delays on each message as it is sent away for part of the message processing”; and (4) “increas[ed] the latency, even under ideal circumstances, for message handling—the result of the above impacts will be felt by all users of the system as latency will only increase.” Resp. 22–23, 37 (citing Ex. 1006, 2:10–15); see Ex. 1024, 81:14–83:11; Ex. 2014 ¶¶ 53, 78, 82. According to Patent Owner, Petitioner’s proposed relocation of the transcription functions to the network center would have required “a complete change of the communications architecture for the hub and introduce[d] the bottlenecks, increased latency, and other problems discussed above.” Resp. 40; see Ex. 2014 ¶ 82. Further, Patent Owner asserts that Petitioner’s contention that Cohn “expressly contemplates embodiments” that centralize “a portion of its network hubs (steps performed by network processor 60, an element within each hub)” as “a task on a central server” rests on a misunderstanding of Cohn. Resp. 41; Sur-reply 6–7; see Pet. 59 (quoting Ex. 1006, 16:64–66); Ex. 2014 ¶ 83. Patent Owner contends that Cohn describes network processor 60 as “a stand-alone hardware platform within the hub.” Resp. 41; IPR2019-01352 Patent 7,558,730 B2 84 see Ex. 2014 ¶ 83. Patent Owner also contends that Cohn explains that network processor 60 “could also be implemented as a task on a central server” but that “central server” simply “incorporates several hub components” and still resides within the hub because it communicates “on the internal hub interface.” Resp. 41; see Ex. 2014 ¶ 83. According to Patent Owner, Cohn does not associate that “central server” with the network center. Resp. 41 (citing Ex. 1006, 16:58–17:9); see Ex. 2014 ¶ 83. To support Patent Owner’s arguments, Dr. Anderson testifies that an ordinarily skilled artisan would have understood from Cohn’s disclosure that “a single system just isn’t adequate to handle the complexities of messaging, message routing, [and] message processing” and that Cohn criticizes “placing any of the message processing into a single centralized location.” Ex. 1024, 70:2–12, 73:1–15. (c) Analysis For the reasons explained below, we agree with Patent Owner that an ordinarily skilled artisan would not have been motivated to modify Cohn’s system to replace the transcription functions at Cohn’s network hubs with Obilisetty’s “single centralized transcription function” located at Cohn’s network center. See Resp. 20–47; Sur-reply 5–8, 15–17; Ex. 2014 ¶¶ 49–90. As Patent Owner asserts, Petitioner’s contention that Cohn “expressly contemplates embodiments” that centralize “a portion of its network hubs (steps performed by network processor 60, an element within each hub)” as “a task on a central server” rests on a misunderstanding of Cohn. See Pet. 59 (quoting Ex. 1006, 16:64–66); Resp. 41. Specifically, Cohn explains that each network hub includes network processor 60 that “can be a stand-alone hardware platform similar to” analog connection processor 52 or digital IPR2019-01352 Patent 7,558,730 B2 85 connection processor 54, e.g., a personal-computer system. Ex. 1006, 16:61–64; see id. at 13:67–14:4, 15:56–60; Ex. 2014 ¶¶ 48, 83. Cohn also explains that network processor 60 can be “implemented as a task on a central server that connects to the internal interface 56 and that contains the remaining storage facilities such as message store 58, file server 59, and hub database 68.” Ex. 1006, 16:64–17:1; see Ex. 2014 ¶ 83. A “central server that connects to the internal interface 56” for a network hub resides within the network hub, not at the network center. See Ex. 1006, 11:24–26, Fig. 2; Ex. 2014 ¶ 83. Hence, contrary to Petitioner’s contention, Cohn does not contemplate centralizing portions of the network hubs at the network center. See Ex. 2014 ¶ 83. Petitioner’s assertion that centralizing the transcription functions at the network center would have “reduced the cost of the overall system” by “reducing internal hardware components duplicated within each network hub” fails to withstand scrutiny. See Pet. 57–58. As explained in more detail below, Petitioner’s proposed combination relocates software for speech recognition and transcription from the network hubs to the network center. But the network hubs still use the same hardware—loaded with less software—for message formatting and routing. Specifically, as discussed above, Petitioner maps the claimed “speech recognition and transcription engine” to the transcription functions at the network center. Pet. 63; see id. at 69; Ex. 1003 ¶ 62. Those transcription functions correspond to a software process, i.e., software for speech recognition and transcription. See Pet. 67–69; Tr. 31:4–8. Thus, Petitioner’s proposed combination relocates software for speech recognition and IPR2019-01352 Patent 7,558,730 B2 86 transcription from the network hubs to the network center. See Tr. 25:20–25, 26:10–12, 29:8–10. In Petitioner’s proposed combination, “the network hubs retain their native formatting and routing functionalities.” Pet. 53–54; see Ex. 1003 ¶ 63; Tr. 28:17–29:10. For message formatting and routing, the network hubs may employ “a variety of hardware platforms depending on the quantity of traffic to be serviced by a particular network hub.” Ex. 1006, 12:20–22. For example, each network hub includes connection processors 52 and 54 that “interact with messaging systems connected to the particular network hub.” Ex. 1006, 11:4–9, code (57); see id. at 6:45–47, 16:8–46, Fig. 2. Specifically, the connection processors receive incoming messages from connected messaging systems and deliver outgoing messages to connected messaging systems. Ex. 1006, 13:55–59, 15:49–52. For message delivery, the connection processors use a protocol “native” to the destination messaging system. Id. at 9:8–21, 10:1–15, 22:49–44. Hence, the connection processors assist with the “native formatting and routing functionalities” of the network hubs. But the “connection processors reside in personal computer platforms,” e.g., “personal computer system[s] running the Unix, Windows NT, or SOLARIS operating systems.” Id. at 12:22–24, 13:67–14:7, 15:56–16:4. So the network hubs use the same hardware for message formatting and routing regardless whether the software for speech recognition and transcription resides at the network hubs or the network center. Also, because the network hubs use the same hardware for message formatting and routing regardless whether the software for speech IPR2019-01352 Patent 7,558,730 B2 87 recognition and transcription resides at the network hubs or the network center, we accord little probative weight to Dr. Creusere’s testimony that centralizing the transcription functions would have minimized “costly equipment and building infrastructures containing that equipment.” See Ex. 1003 ¶ 61. We also disagree with Petitioner’s assertion that centralizing the transcription functions at the network center would have saved time and processing overhead. See Pet. 58. In Cohn’s communications system, “media translator 69 comprises a control module 133 and a translator bank 144.” Ex. 1006, 22:24–26. Control module 133 causes translator bank 144 to use an appropriate sequence of filters “to accomplish any permutation of media-to-media translation, message-to-message transformation or data-to-data conversion.” Id. at 22:44–48. For messages not requiring transcription, control module 133 would not include transcription functions in the sequence of filters for message processing. See id. at 22:34–44. Further, we agree with Patent Owner that “Cohn teaches a decentralized approach to translation.” See Resp. 42; Ex. 2014 ¶ 84. In Cohn’s communications system, each network hub includes a media translator that “perform[s] media and format conversions,” e.g., “convert[s] the format of data” and “translate[s] the media of messages.” Ex. 1006, 12:52–55, 16:20–21, 22:29–31, 22:66–67; see id. at 3:22–26, 4:57–62, 5:21–27, 8:22–26, 11:32–35, 13:46–49, 22:21–23:21, Fig. 12. Among other things, the media translator “performs the translations of messages from one media to another such as, for example, the translation of an electronic mail message into a voice message using a text to speech system.” Id. at IPR2019-01352 Patent 7,558,730 B2 88 13:46–49. The “media translation features include the ability to translate text to speech, facsimile images to text and text images, text and text images to facsimile images, and speech to text.” Id. at 22:67–23:3. Because Cohn’s communications system employs a decentralized approach to translation and a shared internal protocol for message formatting and routing, the communications system “can easily be adapted as new communications protocols . . . become popular.” Ex. 1006, 10:21–27; see Ex. 2014 ¶¶ 56, 84. Due to Cohn’s decentralized approach, “[t]he network hubs that are required to interface with systems utilizing these new protocols need only translate the new protocol to the internal protocol. As such, the operation of the communications system as a whole can support the addition of unlimited new protocols.” Ex. 1006, 10:27–32; see Ex. 2014 ¶¶ 56, 84. In addition, Dr. Creusere identifies another advantage of Cohn’s decentralized system: it “could possibly be more robust to failure.” Ex. 2005, 92:14–93:19. We also agree with Patent Owner that relocating the transcription functions from the network hubs to the network center would have negatively impacted system performance, e.g., by introducing a processing bottleneck, increasing network traffic, and increasing the latency for message handling. See Resp. 22–23, 37; Ex. 1024, 81:14–83:11; Ex. 2014 ¶¶ 53, 78, 82. Those problems would have dissuaded an ordinarily skilled artisan from relocating the transcription functions from the network hubs to the network center. See Ex. 2014 ¶¶ 53, 78–80, 82. Petitioner contends that the problems Patent Owner identifies rest on “the faulty assumption that Cohn was only designed for a ‘very large-scale system.’” Reply 21 (emphasis omitted) (quoting Resp. 23). Contrary to IPR2019-01352 Patent 7,558,730 B2 89 Petitioner’s contention, however, Dr. Anderson testifies that relocating the transcription functions from the network hubs to the network center would cause problems regardless of system size. See Ex. 1024, 82:10–83:11. Further, for the Skladman-Obilisetty ground, Petitioner links speech- to-text functionality with text-to-speech functionality. See Pet. 30–31; Ex. 1003 ¶ 57. In particular, Petitioner argues that (1) Skladman’s system already provides text-to-speech functionality and (2) an ordinarily skilled artisan would have “recognize[d] that users would have both desired and expected speech-to-text functionality.” Pet. 30–31; see Ex. 1003 ¶¶ 55, 57. For the Cohn-Obilisetty ground, however, Petitioner argues that an ordinarily skilled artisan would have (1) relocated speech-to-text functionality from the network hubs to the network center and (2) retained text-to-speech functionality at the network hubs. See Pet. 57, 63; Ex. 1003 ¶¶ 61–62. According to Petitioner, an ordinarily skilled artisan would have centralized speech-to-text functionality to achieve certain advantages, e.g., lower system costs. See Pet. 57–59; Ex. 1003 ¶ 61; Tr. 25:20–26:12, 27:9–28:7. Petitioner fails to explain why centralizing speech-to-text functionality would have achieved those advantages but centralizing text-to- speech functionality would not. See Pet. 56–71; Ex. 1003 ¶¶ 61–63. This disparate treatment of speech-to-text functionality and text-to-speech functionality for the Cohn-Obilisetty ground compared to the Skladman- Obilisetty ground suggests that Petitioner used the challenged patent as a roadmap to reconstruct the claimed invention for the Cohn-Obilisetty ground. In short, Petitioner provides some evidence that an ordinarily skilled artisan would have been motivated to modify Cohn’s system according to IPR2019-01352 Patent 7,558,730 B2 90 Obilisetty’s teachings. On balance, however, and based on the totality of the evidence, we find that an ordinarily skilled artisan would not have been motivated to do so. On this issue, we credit Dr. Anderson’s testimony more than Dr. Creusere’s testimony. 4. SUMMARY For the reasons discussed above, an ordinarily skilled artisan would not have been motivated to modify Cohn’s system to replace the transcription functions at Cohn’s network hubs with Obilisetty’s “single centralized transcription function” located at Cohn’s network center as Petitioner proposes. Hence, we determine that Petitioner has not shown by a preponderance of the evidence that claims 15 and 17 are unpatentable under § 103(a) as obvious over Cohn and Obilisetty. IV. CONCLUSION Based on the evidence presented with the Petition, the evidence introduced during the trial, and the parties’ respective arguments, Petitioner has shown by a preponderance of the evidence that (1) claims 15 and 17 are unpatentable under § 103(a) as obvious over Skladman and Obilisetty; and (2) claims 15 and 17 are unpatentable under § 103(a) as obvious over Skladman, Obilisetty, and Schrage.5 But Petitioner has not shown by a 5 Should Patent Owner wish to pursue amendment of the challenged claims in a reissue or reexamination proceeding after the issuance of this Final Written Decision, we draw Patent Owner’s attention to the April 2019 Notice Regarding Options for Amendments by Patent Owner Through Reissue or Reexamination During a Pending AIA Trial Proceeding. See 84 Fed. Reg. 16,654 (Apr. 22, 2019). If Patent Owner chooses to file a reissue application or a request for reexamination of the challenged patent, we remind Patent Owner of its continuing obligation to notify the Board of IPR2019-01352 Patent 7,558,730 B2 91 preponderance of the evidence that claims 15 and 17 are unpatentable under § 103(a) as obvious over Cohn and Obilisetty. In summary: Claims 35 U.S.C. § Reference(s)/ Basis Claims Shown Unpatentable Claims Not Shown Unpatentable 15, 17 103(a) Skladman, Obilisetty 15, 17 15, 17 103(a) Skladman, Obilisetty, Schrage 15, 17 15, 17 103(a) Cohn, Obilisetty 15, 17 Overall Outcome 15, 17 V. ORDER Accordingly, it is ORDERED that claims 15 and 17 in the ’730 patent are determined to be unpatentable; and FURTHER ORDERED that, because this is a Final Written Decision, the parties to the proceeding seeking judicial review of the decision must comply with the notice and service requirements of 37 C.F.R. § 90.2. any such related matters in updated mandatory notices. See 37 C.F.R. § 42.8(a)(3), (b)(2). IPR2019-01352 Patent 7,558,730 B2 92 PETITIONER: Adam P. Seitz Paul R. Hart ERISE IP, P.A. Adam.Seitz@eriseip.com Paul.Hart@eriseip.com PATENT OWNER: Nicholas C. Kliewer Michael C. Pomeroy BUETHER JOE & CARPENTER, LLC BJC-AVRS@bjciplaw.com Nick.Kliewer@bjciplaw.com Michael.Pomeroy@bjciplaw.com Copy with citationCopy as parenthetical citation