Trials@uspto.gov
`571-272-7822
`
`
`
`
`Paper 51
`Entered: March 6, 2019
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_______________
`
`TELESIGN CORPORATION,
`Petitioner,
`
`v.
`
`TWILIO INC.,
`Patent Owner.
`_______________
`
`Case IPR2017-01977
`Patent 8,755,376 B2
`_______________
`
`
`Before ROBERT J. WEINSCHENK, KIMBERLY MCGRAW, and
`SCOTT C. MOORE, Administrative Patent Judges.
`
`WEINSCHENK, Administrative Patent Judge.
`
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`571-272-7822
`
`
`
`
`Paper 51
`Entered: March 6, 2019
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_______________
`
`TELESIGN CORPORATION,
`Petitioner,
`
`v.
`
`TWILIO INC.,
`Patent Owner.
`_______________
`
`Case IPR2017-01977
`Patent 8,755,376 B2
`_______________
`
`
`Before ROBERT J. WEINSCHENK, KIMBERLY MCGRAW, and
`SCOTT C. MOORE, Administrative Patent Judges.
`
`WEINSCHENK, Administrative Patent Judge.
`
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`
`5 and 17
`
`I.
`INTRODUCTION
`TeleSign Corporation (“Petitioner”) filed a Petition (Paper 1, “Pet.”)
`requesting an inter partes review of claims 1–3, 5, 14, 16, 17, and 19 of U.S.
`Patent No. 8,755,376 B2 (Ex. 1001, “the ’376 patent”). Twilio Inc. (“Patent
`Owner”) filed a Preliminary Response (Paper 10, “Prelim. Resp.”) to the
`Petition. On March 9, 2018, an inter partes review of the challenged claims
`was instituted on the following grounds:
`Applied References
`Claim(s)
`Statutory Basis
`1–3, 14, 16, and
`35 U.S.C. § 103(a)1 Maes et al., U.S. Patent No.
`19
`6,801,604 B2 (filed June 25,
`2002, issued Oct. 5, 2004) (Ex.
`1003, “Maes”) and Ransom et
`al., U.S. Patent Application
`Publication No. 2003/0204756
`A1 (filed Jan. 9, 2003, published
`Oct. 30, 2003) (Ex. 1004,
`“Ransom”)
`35 U.S.C. § 103(a) Maes, Ransom, and Jiang et al.,
`U.S. Patent No. 7,092,370 B2
`(filed Aug. 16, 2001, issued
`Aug. 15, 2006) (Ex. 1005,
`“Jiang”)
`35 U.S.C. § 103(a) European Telecommunications
`Standards Institute, ETSI ES 202
`391-4 V1.2.1 (2006) (Ex. 1006,
`“ETSI 391-4”) and Ransom
`35 U.S.C. § 103(a) ETSI 391-4, Ransom, and
`European Telecommunications
`
`1–3, 5, 14, and
`16
`
`17
`
`
`1 The Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112-29,
`which was enacted on September 16, 2011, made amendments to 35 U.S.C.
`§§ 102, 103. AIA § 3(b), (c). Those amendments became effective on
`March 16, 2013. Id. at § 3(n). Because the challenged claims of the ’376
`patent have an effective filing date before March 16, 2013, any citations
`herein to 35 U.S.C. §§ 102, 103 are to their pre-AIA versions.
`
`2
`
`
`
`Claim(s)
`
`19
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`
`Statutory Basis
`
`Applied References
`Standards Institute, ETSI ES 202
`391-7 V1.2.1 (2006) (Ex. 1007,
`“ETSI 391-7”)
`35 U.S.C. § 103(a) ETSI 391-4, Ransom, and
`European Telecommunications
`Standards Institute, ETSI ES 202
`391-2 V1.2.1 (2006) (Ex. 1008,
`“ETSI 391-2”)
`
`Paper 12 (“Dec. on Inst.”), 15.
`After institution, Patent Owner filed a Response (Paper 26,2 “PO
`Resp.”) to the Petition, and Petitioner filed a Reply (Paper 30, “Pet. Reply”)
`to the Response. Petitioner submitted a Declaration of Dr. Seth Nielson
`(Ex. 1009) with the Petition, and a Supplemental Declaration of Dr. Nielson
`(Ex. 1019) with the Reply. Patent Owner submitted a Declaration of Dr.
`Kevin Negus (Ex. 2010) with the Response. An oral hearing was held on
`November 15, 2018, and a transcript of the hearing is included in the record.
`Paper 503 (“Tr.”).
`For the reasons set forth below, Petitioner has shown by a
`preponderance of the evidence that claims 1–3, 5, 14, 16, 17, and 19 of the
`’376 patent are unpatentable.
`A.
`Related Proceedings
`The parties indicate that the ’376 patent is the subject of the following
`case in the United States District Court for the Northern District of
`California (“District Court”): Twilio Inc. v. TeleSign Corporation, No. 5:16-
`
`2 Paper 26 is a public version of the Response. Paper 28 is a confidential
`version of the Response, which remains under seal.
`3 Paper 50 is a public version of the transcript. Paper 48 is a confidential
`version of the transcript, which remains under seal.
`
`3
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`cv-06925 (N.D. Cal.). Pet. 66; Paper 4, 1. Patent Owner also indicates that
`the following petitions for inter partes review are related to this case:
`Case No.
`Involved U.S. Patent No.
`IPR2017-01976
`U.S. Patent No. 8,837,465
`IPR2017-01978
`U.S. Patent No. 8,306,021
`Paper 4, 1.
`B.
`The ’376 Patent
`The ’376 patent relates to “making telephony application development
`as easy as web programming.” Ex. 1001, 1:66–2:3. The ’376 patent
`explains that deploying telephony services “requires developers to train in
`new languages, tools, and development environments,” and, thus, involves
`“significant upfront and ongoing investment.” Id. at 1:35–54. To address
`this problem, the ’376 patent describes a method and system for processing
`telephony sessions that “enables web developers to use their existing skills
`and tools with the esoteric world of telephony.” Id. at 1:61–2:3. For
`example, the method and system of the ’376 patent “use the familiar web
`site visitor model to interact with a web developer’s application, with each
`step of the phone call analogous to a traditional page view.” Id. at 2:3–6.
`C.
`Illustrative Claim
`Of the challenged claims, claim 1 is independent and is reproduced
`
`below.
`
`1. A method comprising:
`operating a telephony network and internet connected
`system cooperatively with a plurality of application
`programming Interface (API) resources, wherein operating the
`system comprises:
`initiating a telephony session,
`
`4
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`
`communicating with an application server to receive an
`application response,
`converting the application response into executable
`operations to process the telephony session,
`creating at least one informational API resource; and
`exposing the plurality of API resources through a
`representational state transfer (REST) API that comprises:
`receiving a REST API request that specifies an API
`resource URI,4 and
`responding to the API request according to the request
`and the specified resource URI.
`Ex. 1001, 18:29–45.
`
`II. ANALYSIS
`A.
`Level of Ordinary Skill in the Art
`Petitioner argues that a person of ordinary skill in the art would have
`had “a bachelor’s degree in computer science with at least two years of
`experience in application development.” Pet. 8 (citing Ex. 1009 ¶¶ 49–50).
`Patent Owner argues that a person of ordinary skill in the art would have had
`“the equivalent of a four-year degree from an accredited institution in
`computer science, computer engineering, electrical engineering, software
`engineering, or the equivalent, and approximately 1–2 years of professional
`experience with or exposure to computer networking, telephony networking
`protocols, and various APIs,” but “[a]dditional graduate education could
`substitute for professional experience, while significant experience in the
`field might substitute for formal education.” PO Resp. 10 (citing Ex. 2010
`¶ 32).
`
`
`4 URI stands for Universal Resource Identifier. Ex. 1001, 2:61–62.
`
`5
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`
`Neither party identifies any specific instance in which the difference
`between the parties’ respective definitions of the level of ordinary skill in the
`art impacts the analysis or conclusions of either party, or either party’s
`declarant, in this case. Our findings and conclusions in this case would be
`the same under either party’s definition of the level of ordinary skill in the
`art. To the extent necessary, though, we adopt Petitioner’s definition, which
`is supported by the testimony of Petitioner’s declarant, Dr. Nielson, and is
`consistent with the prior art. Pet. 6–8; Ex. 1009 ¶¶ 49–50.
`B.
`Claim Construction
`The claims of an unexpired patent are interpreted using the broadest
`reasonable interpretation in light of the specification of the patent in which
`they appear.5 37 C.F.R. § 42.100(b) (2017); Cuozzo Speed Techs., LLC v.
`Lee, 136 S. Ct. 2131, 2144–45 (2016). “Under a broadest reasonable
`interpretation, words of the claim must be given their plain meaning, unless
`such meaning is inconsistent with the specification and prosecution history.”
`TriVascular, Inc. v. Samuels, 812 F.3d 1056, 1062 (Fed. Cir. 2016). An
`applicant may provide a definition of a term in the specification with
`reasonable clarity, deliberateness, and precision. In re Paulsen, 30 F.3d
`1475, 1480 (Fed. Cir. 1994). In the absence of such a definition, limitations
`
`
`5 The rule replacing the broadest reasonable interpretation standard with the
`standard used in federal district court does not apply in this case. Changes to
`the Claim Construction Standard for Interpreting Claims in Trial
`Proceedings Before the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340
`(Oct. 11, 2018) (final rule) (“This rule is effective on November 13, 2018
`and applies to all IPR, PGR and CBM petitions filed on or after the effective
`date.”). Nonetheless, on this record, the outcome would be the same under
`the standard used in federal district court.
`
`6
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`are not to be read into the claims from the specification. In re Van Geuns,
`988 F.2d 1181, 1184 (Fed. Cir. 1993).
`1.
`Representational State Transfer (REST) API
`Patent Owner proposes construing the term “representational state
`transfer (REST) API” to mean “an application programming interface that
`complies with Representational State Transfer (REST) interface constraints,
`which are: identification of resources; manipulation of resources through
`representations; self-descriptive messages; and, hypermedia as the engine of
`application state.” PO Resp. 10. Petitioner does not propose an express
`construction for the term “representational state transfer (REST) API,” but
`acknowledged at the oral hearing that Patent Owner’s proposed construction
`“simply makes express what [Petitioner] implies.” Tr. 32:24–33:13.
`Patent Owner’s proposed construction is supported by the
`specification of the ’376 patent and the extrinsic evidence. Specifically, the
`’376 patent indicates that the term “REST” has its ordinary meaning in the
`art (Ex. 1001, 2:15–16, 8:12–14), and Patent Owner’s declarant, Dr. Negus,
`explains that a person of ordinary skill in the art would understand the term
`“REST API” to refer to the interface constraints set forth in Patent Owner’s
`proposed construction (Ex. 2010 ¶¶ 163–166). Patent Owner’s proposed
`construction also is consistent with the construction that was adopted by the
`District Court in a related case. Ex. 2005, 16–22.
`Therefore, the term “representational state transfer (REST) API” is
`construed to mean “an application programming interface that complies with
`Representational State Transfer (REST) interface constraints, which are:
`identification of resources; manipulation of resources through
`
`7
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`representations; self-descriptive messages; and hypermedia as the engine of
`application state.”
`2.
`Application Programming Interface (API) Resource
`Patent Owner proposes construing the term “application programming
`interface (API) resource” to mean “a resource identifiable by its URI and
`available through an API.” PO Resp. 12. Petitioner agrees with a portion of
`Patent Owner’s proposed construction, namely, Petitioner agrees that the
`term “application programming interface (API) resource” refers to “a
`resource available through an API.” Tr. 33:24–34:8.
`The agreed portion of Patent Owner’s proposed construction is
`supported by the claim language. Specifically, the term “API resource” by
`itself indicates that the resource is available through an API. The other
`portion of Patent Owner’s proposed construction, however, is not supported
`by the claim language. For example, claim 1 separately recites “an API
`resource URI” (Ex. 1001, 18:42–43), which Patent Owner asserts is “a URI
`that identifies an API resource” (PO Resp. 13). Because claim 1 separately
`recites a URI that identifies an API resource, it is unnecessary to include that
`limitation in a construction of the term “API resource” alone.
` Therefore, the term “application programming interface (API)
`resource” is construed to mean “a resource available through an API.”
`3.
`API Resource URI
`Patent Owner proposes construing the term “API resource URI” to
`mean “a URI that identifies an API resource.” PO Resp. 13. Petitioner
`agrees with Patent Owner’s proposed construction. Tr. 34:9–16. And Patent
`Owner’s proposed construction is supported by the specification of the ’376
`patent, which indicates that an API resource preferably is addressed by a
`
`8
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`URI. Ex. 1001, 9:33–34.
`Therefore, the term “API resource URI” is construed to mean “a URI
`that identifies an API resource.”
`4.
`URI
`Patent Owner proposes construing the term “URI” to mean “a
`compact sequence of characters that identifies an abstract or physical
`resource.” PO Resp. 13. Petitioner agrees with Patent Owner’s proposed
`construction. Tr. 12:5–9, 34:17–20.
`Patent Owner’s proposed construction is supported by the
`specification of the ’376 patent. Namely, the ’376 patent provides several
`examples of URIs, and each example is a compact sequence of characters.
`Ex. 1001, 4:4–5 (“http://demo.twilio.com/myapp{dialed phone number}/
`{originating phone number}”), 4:5–8 (“http://demo.twilio.com/mpapp/
`foo.php?dialed_number={dialed phone number}& originating_number=
`{originating phone number}”), 7:45–51 (“http://demo.twilio.com/foo.php?
`digits=1234”), 7:51–54 (“http://demo.twilio.com/myapp/1234.mp3”).
`Patent Owner’s proposed construction also is consistent with the parties’
`agreed construction that was adopted by the District Court in a related case.
`Ex. 2005, 13–16.
`Therefore, the term “URI” is construed to mean “a compact sequence
`of characters that identifies an abstract or physical resource.”
`C. Obviousness of Claims 1–3, 14, 16, and 19 over Maes and
`Ransom
`Petitioner argues that claims 1–3, 14, 16, and 19 would have been
`obvious over Maes and Ransom. Pet. 5–6. A claim is unpatentable as
`obvious under 35 U.S.C. § 103(a) if the differences between the claimed
`subject matter and the prior art are such that the subject matter as a whole
`
`9
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`would have been obvious at the time the invention was made to a person
`having ordinary skill in the art to which the subject matter pertains. KSR
`Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). The question of
`obviousness is resolved on the basis of underlying factual determinations,
`including: (1) the scope and content of the prior art; (2) any differences
`between the claimed subject matter and the prior art; (3) the level of ordinary
`skill in the art; and (4) any objective indicia of non-obviousness. Graham v.
`John Deere Co., 383 U.S. 1, 17–18 (1966).
`Based on the parties’ arguments and supporting evidence, Petitioner
`has shown by a preponderance of the evidence that claims 1–3, 14, 16, and
`19 would have been obvious over Maes and Ransom.
`1.
`Overview of Maes and Ransom
`Maes relates to “building distributed conversational applications using
`a Web services-based model.” Ex. 1003, 3:52–65. Maes describes a router
`that receives incoming call information, such as a telephone number, and
`assigns an application to the incoming call. Id. at 15:51–57. The router
`sends a message that includes a telephony gateway address to the assigned
`application over the Internet. Id. at 15:57–62, Fig. 1 (“IP Network”). The
`assigned application then sends a message to the telephony gateway to
`accept the incoming call. Id. at 15:63–65.
`Ransom relates to transporting data between a mix of secure and
`unsecure networks. Ex. 1004 ¶ 5. Ransom explains that “there are two
`common web service models”—the REST and SOAP models—for use with
`Hypertext Transfer Protocol (“HTTP”). Id. ¶ 163. In the REST model, “the
`service being invoked is the URI being accessed through the web.” Id. In
`the SOAP model, “the content of the message is generally thought to
`
`10
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`describe the service being invoked, with the resource at the URI that the
`SOAP message is being sent to, as a routing mechanism.” Id.
`2.
`Claim 1
`Claim 1 recites “operating a telephony network and internet connected
`system cooperatively with a plurality of application programming Interface
`(API) resources.” Ex. 1001, 18:30–33. Maes teaches a telephony network
`and Internet-connected system. Pet. 14–16; Ex. 1003, Fig. 11 (showing
`“PSTN” and “IP Network”). Maes also teaches that the network and system
`operate cooperatively with a plurality of API resources, such as API
`resources for setting up, transferring, and recording a call. Pet. 16; Ex. 1003,
`34:20–35:8.
`Patent Owner responds that “Petitioner makes no attempt to show how
`Maes’s telephony-based servers, which Petitioner alleges are ‘a plurality of
`API resources’ . . . are identifiable through their URIs nor how any server is
`available through an API.”6 PO Resp. 15–16. Patent Owner’s argument is
`not persuasive. Petitioner does not rely solely on Maes’s telephony servers
`as teaching a plurality of resources. Rather, Petitioner explains that Maes’s
`telephony gateway, TEL 20, includes various resources that allow an
`application to modify the state of a telephony session, such as setting up,
`transferring, and recording a call. Pet. 16 (citing Ex. 1003, 34:20–35:8).
`Petitioner also explains that because an application accesses the
`aforementioned resources by sending a SOAP message over the Internet,
`those resources are available through an API. Pet. 20–21 (citing Ex. 1003,
`
`
`6 Patent Owner argues that Maes “disparages proprietary APIs.” PO Resp.
`15 (citing Ex. 1003, 2:30–40). Even if Maes disparages proprietary APIs,
`Maes nonetheless teaches using APIs generally. Ex. 1003, 8:10–15.
`
`11
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`16:4–8, 34:20–35:28; Ex. 1009 ¶¶ 59–60). And although the term “API
`resource” does not by itself require the resource to be identifiable by a URI
`(see supra Section II.B.2), Petitioner explains how the combination of Maes
`and Ransom teaches an API resource identifiable by a URI in its discussion
`of the term “an API resource URI” (Pet. 24–27).
`Claim 1 recites “initiating a telephony session.” Ex. 1001, 18:34.
`Maes teaches a voice response system that receives and accepts an incoming
`call. Pet. 16–17; Ex. 1003, 15:44–48, 15:63–65. Patent Owner does not
`dispute that the combination of Maes and Ransom teaches this limitation of
`claim 1.
`Claim 1 recites “communicating with an application server to receive
`an application response.” Ex. 1001, 18:35–36. Maes teaches that a router
`sends a message to an application on an application server, and the
`application sends a response to a telephony gateway. Pet. 17–18; Ex. 1003,
`15:59–65, 16:14–26. Patent Owner does not dispute that the combination of
`Maes and Ransom teaches this limitation of claim 1.
`Claim 1 recites “converting the application response into executable
`operations to process the telephony session.” Ex. 1001, 18:37–38. Maes
`teaches that after receiving an application’s response, a telephony gateway,
`TEL 20, executes telephony actions, such as playing a text-to-speech stream,
`recording to an automatic speech recognition (“ASR”) port, and collecting
`dual tone multi-frequency (“DTMF”) digits. Pet. 18–19; Ex. 1003, 16:14–
`26. Patent Owner does not dispute that the combination of Maes and
`Ransom teaches this limitation of claim 1.
`Claim 1 recites “creating at least one informational API resource.”
`Ex. 1001, 18:39. Maes teaches that after receiving an application’s
`
`12
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`response, a telephony gateway, TEL 20, collects DTMF digits. Pet. 19–20;
`Ex. 1003, 34:20–35:8, 35:29–31. Patent Owner does not dispute that the
`combination of Maes and Ransom teaches this limitation of claim 1.
`Claim 1 recites “exposing the plurality of API resources through a
`representational state transfer (REST) API.” Ex. 1001, 18:40–41. Maes
`teaches that an application accesses a plurality of resources through a SOAP
`API, specifically by sending a SOAP message over the Internet. Pet. 20–21;
`Ex. 1003, 16:4–8, 34:20–35:28; Ex. 1009 ¶ 59. Ransom teaches that
`resources also can be accessed using a REST API. Pet. 21–22; Ex. 1004 ¶¶
`161–163, 184–185; Ex. 1009 ¶ 62. Thus, the combination of Maes and
`Ransom teaches accessing a plurality of API resources through a REST API.
`Pet. 23; Ex. 1009 ¶ 62.
`Patent Owner responds that Petitioner improperly “points to different
`alleged ‘API resources’ in Maes” for the “operating” and “exposing”
`limitations of claim 1. PO Resp. 16. Patent Owner’s argument is not
`persuasive. For both the “operating” and “exposing” limitations of claim 1,
`Petitioner explains that Maes’s telephony gateway, TEL 20, includes a
`plurality of API resources, such as API resources for setting up, transferring,
`and recording a call. Compare Pet. 16 (“Maes teaches that TEL 20, includes
`various functionalities that allow an application to modify the state of a
`telephony session, such as setting up a call, transferring a call, and recording
`audio during a call.”), with id. at 20–21 (“Maes discloses several resources
`accessible via an API. . . . For example, by sending a control message over
`the Internet to TEL20, application 14 can access resources that initiate,
`terminate, or transfer a call, such as ‘MakeCall,’ ‘DropCall,’ ‘TransferCall,’
`etc.”).
`
`13
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`
`Patent Owner responds that “Petitioner has not shown how the
`enumeration values are identifiable through their URIs, nor how they are
`accessible via an API.” PO Resp. 16–17. Patent Owner’s argument is not
`persuasive. Petitioner explains that because an application accesses the
`resources of telephony gateway, TEL 20, by sending a SOAP message over
`the Internet, those resources are available through an API. Pet. 20–21 (citing
`Ex. 1003, 16:4–8, 34:20–35:28; Ex. 1009 ¶ 59). And, although the term
`“API resource” does not by itself require the resource to be identifiable by a
`URI (see supra Section II.B.2), Petitioner explains how the combination of
`Maes and Ransom teaches an API resource identifiable by a URI in its
`discussion of the term “an API resource URI” (Pet. 24–27).
`Patent Owner responds that Petitioner does not show that Ransom
`teaches a REST API that complies with “the four REST conventions,” which
`are “(1) identification of resources; (2) manipulation of resources through
`representations; (3) self-descriptive messages and (4) hypermedia as the
`engine of application state.” PO Resp. 17–18. Patent Owner’s argument is
`not persuasive. Patent Owner acknowledges that the four REST conventions
`are based on “the common understanding that a POSA would have had of a
`‘REST API’ at the time of the invention.” Id. at 10–11 (emphasis added).
`And Ransom teaches the “common” REST web service model. Ex. 1004 ¶
`163 (emphasis added). Thus, a person of ordinary skill in the art reading
`Ransom would have understood Ransom as teaching the common REST
`API that complies with the four REST conventions. Id. Further, Petitioner’s
`declarant, Dr. Nielson, explains how Ransom’s REST API complies with the
`four REST conventions. Pet. Reply 9; Ex. 1019 ¶¶ 4–14.
`
`14
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`
`Patent Owner responds that Ransom does not teach “how to use a
`‘REST API’ to expose a single API resource nor a plurality of API
`resources.” PO Resp. 18. Patent Owner’s argument is not persuasive. As
`discussed, Maes teaches exposing a plurality of resources using a SOAP
`API. Pet. 20–21; Ex. 1003, 16:4–8, 34:20–35:28; Ex. 1009 ¶ 59. As also
`discussed, Ransom teaches that a resource can be exposed using another
`common API, namely a REST API. Pet. 21–22; Ex. 1004 ¶¶ 161–163, 184–
`185; Ex. 1009 ¶ 62. And Petitioner’s declarant, Dr. Nielson, explains
`specifically that it would have been within the capabilities of a person of
`ordinary skill in the art to implement Maes’s system using a REST API
`instead of a SOAP API. Pet. 23–24; Ex. 1009 ¶¶ 62–75.
`Patent Owner responds that Ransom teaches away from using a REST
`API because Ransom teaches that an XML firewall will eliminate all non-
`SOAP traffic. PO Resp. 19. Patent Owner’s argument is not persuasive.
`Even if Ransom describes one specific type of firewall that would block
`REST messages (Ex. 1004 ¶ 157), Ransom still teaches using a REST API
`with other firewalls (id. ¶ 185).
`Claim 1 recites “receiving a REST API request that specifies an API
`resource URI.” Ex. 1001, 18:42–43. Maes teaches that a telephony
`gateway, TEL 20, receives a SOAP message that specifies an API resource,
`such as “MakeCall,” “TransferCall,” or “Record.” Pet. 24–26; Ex. 1003,
`34:20–35:28, Fig. 1; Ex. 1009 ¶¶ 77–78. Ransom teaches using a REST
`message that specifies the URI of an API resource. Pet. 26–27; Ex. 1004 ¶¶
`163, 185; Ex. 1009 ¶¶ 62, 79. Thus, the combination of Maes and Ransom
`teaches receiving a REST API request that specifies an API resource URI.
`Pet. 28; Ex. 1009 ¶ 82.
`
`15
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`Patent Owner responds that “Petitioner relies on Maes for ‘API
`
`resource URI’ but separates the ‘URI’ from ‘API resource.’” PO Resp. 29.
`Specifically, Patent Owner argues that “Petitioner points to an enumeration
`value as the ‘API resource’ while pointing to a URI for a server.” Id. Patent
`Owner also argues that “Maes does not list TEL 20 as having a URI.” Id. at
`30. Patent Owner’s arguments are not persuasive because Patent Owner
`addresses Maes individually, not the combination of Maes and Ransom
`proposed by Petitioner. See In re Keller, 642 F.2d 413, 426 (CCPA 1981)
`(“[O]ne cannot show non-obviousness by attacking references individually
`where, as here, the rejections are based on combinations of references.”). As
`discussed, Maes teaches that a telephony gateway, TEL 20, receives a SOAP
`message that specifies an API resource, such as “MakeCall,” “TransferCall,”
`or “Record” (Pet. 24–26; Ex. 1003, 34:20–35:28, Fig. 1; Ex. 1009 ¶¶ 77–
`78), and Ransom teaches using a REST message that specifies the URI of an
`API resource (Pet. 26–27; Ex. 1004 ¶¶ 163, 185; Ex. 1009 ¶ 79). Thus, even
`if Maes alone does not teach an API resource URI, the combination of Maes
`and Ransom teaches receiving a REST API request that specifies an API
`resource URI. Pet. 28; Ex. 1009 ¶ 82.
`
`Patent Owner responds that “to the extent Petitioner is relying on
`Ransom for ‘URI’ and Maes for ‘API resource,’ its position is flawed”
`because “Petitioner does not explain how any URI in Ransom could identify
`any alleged API resource in Maes.” PO Resp. 30. Patent Owner also argues
`that Petitioner does not show that Maes teaches an API request or that
`Ransom teaches a REST API. Id. at 31. Patent Owner’s arguments are not
`persuasive. As discussed, Maes teaches receiving a SOAP message that
`specifies an API resource. Pet. 24–26; Ex. 1003, 34:20–35:28, Fig. 1; Ex.
`
`16
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`1009 ¶¶ 77–78. As also discussed, Ransom teaches using a REST message
`that specifies the URI of an API resource. Pet. 26–27; Ex. 1004 ¶¶ 163, 185;
`Ex. 1009 ¶ 79. And Petitioner’s declarant, Dr. Nielson, explains specifically
`that it would have been within the capabilities of a person of ordinary skill in
`the art to implement Maes’s system using a REST API instead of a SOAP
`API. Pet. 28; Ex. 1009 ¶¶ 62–75, 81.
`Claim 1 recites “responding to the API request according to the
`request and the specified resource URI.” Ex. 1001, 18:44–45. Maes teaches
`that a telephony gateway, TEL 20, responds to an API request that specifies
`an API resource, such as “MakeCall,” “TransferCall,” or “Record,” by
`modifying the state of a telephony session according to the request and the
`specified resource, such as by initiating, transferring, or recording a call.
`Pet. 29; Ex. 1003, 16:24–44, 35:25–28.
`Patent Owner responds that the portions of Maes cited by Petitioner
`do not teach responding to the API request according to the specified
`resource URI. PO Resp. 33. Specifically, Patent Owner argues that column
`16, lines 24–26 of Maes relates to a task manager, not TEL 20, and that
`column 35, lines 25–28 of Maes relates to both play and record resources,
`not just a single specified resource. Id. at 33–34. Patent Owner’s argument
`is not persuasive. Column 16, lines 24–26 of Maes teaches that the task
`manager “wait[s]” for a “response[]” from the telephony gateway, TEL 20,
`and, thus, teaches that TEL 20 responds to the API request. Ex. 1003,
`16:21–26. Also, column 35, lines 25–28 of Maes teaches that the request
`may include “play and/or record” resources, and, thus, Maes teaches that the
`response may relate to a single specified resource. Id. at 35:25–28
`(emphasis added).
`
`17
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`
`Patent Owner responds that Petitioner relies on TEL 20’s URI for the
`“receiving” limitation, but does not rely on TEL 20’s URI for the
`“responding” limitation. PO Resp. 34. Patent Owner’s argument is not
`persuasive. Petitioner does not rely solely on Maes to teach an API resource
`URI. Rather, as discussed, Maes teaches receiving and responding to an API
`request for an API resource, such as “MakeCall,” “TransferCall,” or
`“Record” (Pet. 24–26, 29; Ex. 1003, 16:24–44, 34:20–35:28; Ex. 1009 ¶¶
`77–78), and Ransom teaches that an API request can be a REST API request
`that specifies an API resource URI (Pet. 26–27; Ex. 1004 ¶¶ 163, 185; Ex.
`1009 ¶¶ 62, 79).
`Patent Owner responds that Petitioner relies solely on Maes for the
`“responding” limitation. PO Resp. 34. Patent Owner’s argument is not
`persuasive. For the “receiving” limitation, Petitioner relies on the
`combination of Maes and Ransom to teach receiving a REST API request
`that specifies an API resource URI. Pet. 24–28; Ex. 1003, 34:20–35:28, Fig.
`1; Ex. 1004 ¶¶ 163, 185; Ex. 1009 ¶¶ 62, 77–82. For the “responding”
`limitation, Petitioner then relies on Maes to further teach responding to an
`API request that specifies an API resource by modifying the state of a
`telephony session according to the request and the specified resource. Pet.
`29; Ex. 1003, 16:24–44, 35:25–28. Thus, when Petitioner’s arguments and
`evidence regarding the “receiving” and “responding” limitation are
`considered together, Petitioner shows that the combination of Maes and
`Ransom teaches responding to the REST API request according to the
`specified API resource URI.
`
`18
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`
`3.
`Claim 2
`Claim 2 depends from claim 1, and recites “wherein the specified API
`resource URI is a URI of a functional API resource.” Ex. 1001, 18:46–47.
`As discussed, the combination of Maes and Ransom teaches receiving a
`REST API request that specifies an API resource URI. Pet. 24–28; Ex.
`1003, 34:20–35:28, Fig. 1; Ex. 1004 ¶¶ 163, 185; Ex. 1009 ¶¶ 62, 77–82.
`Maes further teaches that the API resource is a functional API resource, such
`as “MakeCall,” “TransferCall,” or “Record,” and, thus, the aforementioned
`URI is a URI of a functional API resource. Pet. 30–31; Ex. 1003, 16:24–26,
`34:20–35:28.
`Patent Owner responds that the URI of Maes’s TEL 20 does not
`specify what Petitioner identifies as a functional API resource. PO Resp. 35.
`Patent Owner’s argument is not persuasive. As discussed, Maes teaches that
`a telephony gateway, TEL 20, receives a SOAP message that specifies a
`functional API resource, such as “MakeCall,” “TransferCall,” or “Record”
`(Pet. 24–26; Ex. 1003, 34:20–35:28, Fig. 1; Ex. 1009 ¶¶ 77–78), and
`Ransom teaches using a REST API message that specifies the URI of an API
`resource (Pet. 26–27; Ex. 1004 ¶¶ 163, 185; Ex. 1009 ¶¶ 62, 79). Thus, even
`if Maes alone does not teach a functional API resource URI, the combination
`of Maes and Ransom teaches a functional API resource URI. Pet. 28; Ex.
`1009 ¶ 82.
`Patent Owner responds that Petitioner does not rely on Ransom for
`claim 2. PO Resp. 35. Patent Owner’s argument is not persuasive. As
`discussed for claim 1, Petitioner relies on Ransom to teach an API resource
`URI. Pet. 26–27 (citing Ex. 1004 ¶¶ 163, 185). For claim 2, Petitioner then
`relies on Maes to further show that the API resource from claim 1 is a
`
`19
`
`
`
`IPR2017-01977
`Patent 8,755,376 B2
`
`functional resource, and, thus, tha
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
