Advanced Voice Recognition Systems, Inc.

Patent Trials and Appeals Board

Jan 13, 2021

IPR2019-01352 (P.T.A.B. Jan. 13, 2021)

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, 1718, 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