UNITED STATES PATENT AND TRADEMARK OFFICE
`________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________________________
`
`
`TELESIGN CORPORATION
`Petitioner
`
`v.
`
`TWILIO, INC.
`Patent Owner
`
`________________________________
`Patent 8,755,376
`IPR Case Number: IPR2017-01977
`________________________________
`
`PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 8,755,376
`
`
`
`
`
`

`

`TABLE OF CONTENTS
`
`I.
`
`INTRODUCTION ........................................................................................... 1
`
`II.
`
`SUMMARY OF THE ’376 PATENT ............................................................. 2
`
`A. Description of the alleged invention of the ’376 patent ........................ 2
`
`B.
`
`Prosecution history for the ’376 patent ................................................. 3
`
`III. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37
`C.F.R. § 42.104 ................................................................................................ 5
`
`A. Grounds for standing under 37 C.F.R. § 42.104(a) ............................... 5
`
`B.
`
`Identification of challenges under 37 C.F.R. § 42.104(b) and
`relief requested ...................................................................................... 5
`
`C.
`
`Level of ordinary skill in the art ............................................................ 7
`
`D.
`
`Claim construction under 37 C.F.R. § 42.104(b)(3) ............................. 8
`
`IS A REASONABLE LIKELIHOOD THAT THE
`IV. THERE
`CHALLENGED CLAIMS OF THE
`’376 PATENT ARE
`UNPATENTABLE .......................................................................................... 9
`
`A. Ground 1: Maes in view of Ransom Renders Claims 1-3, 14, 16,
`and 19 Obvious ...................................................................................... 9
`
`B.
`
`C.
`
`Ground 2: Maes in view of Ransom and further in view of Jiang
`Renders Claims 5 and 17 Obvious ...................................................... 35
`
`Ground 3: ETSI ES 202 391-4 in view of Ransom Renders
`Claims 1-3, 5, 14, and 16 Obvious ...................................................... 40
`
`D. Ground 4: ETSI ES 202 391-4 in view of Ransom and further in
`view of ETSI ES 202 391-7 Renders Claim 17 Obvious .................... 59
`
`E.
`
`Ground 5: ETSI ES 202 391-4 in view of Ransom and further in
`view of ETSI ES 202 391-2 Renders Claim 19 Obvious .................... 61
`
`V.
`
`CONCLUSION .............................................................................................. 65
`
`VI. MANDATORY NOTICES UNDER 37 C.F.R. § 42.8(A)(1) ...................... 66
`
`
`
`i
`
`

`

`A.
`
`Real Party-In-Interest .......................................................................... 66
`
`B.
`
`C.
`
`Related Matters .................................................................................... 66
`
`Lead and Back-Up Counsel ................................................................. 66
`
`
`
`
`
`ii
`
`

`

`I.
`
`INTRODUCTION
`
`Petitioner TeleSign Corporation requests Inter Partes Review (“IPR”) of
`
`claims 1-3, 5, 14, 16-17, and 19 (“the Challenged Claims”) of U.S. Patent No.
`
`8,755,376 (“the ’376 Patent”). The ’376 Patent is allegedly directed to a method
`
`and system that allows for the creation of telephony-based applications without
`
`requiring expertise in complicated telephony-network interfacing. The claims,
`
`however, are broadly directed to the exchange of messages between an application
`
`seeking to invoke functionality on a telephony network, such as setting up a phone
`
`call or collecting DTMF digits, and a gateway connected to that telephony network
`
`for converting the request into telephony action. Indeed, the claims are not
`
`directed to how the gateway converts an application’s request into telephony
`
`action. Instead, the claims are merely directed to a request-response message
`
`exchange pattern using web-service-messaging formats that the ’376 Patent
`
`concedes were well known in the art to invoke telephony-network functionality.
`
`By April 2008, however, gateways for converting a request for telephony
`
`functionality into telephony-network action were well known. As demonstrated
`
`below, this prior art allowed an application through a request-response message
`
`exchange pattern with a system connected to a telephony-network, to invoke
`
`telephony-network functionality, such as a setting up a call or collecting DTMF
`
`digits from a caller.
`
`
`
`1
`
`

`

`II.
`
`SUMMARY OF THE ’376 PATENT
`
`A. DESCRIPTION OF THE ALLEGED INVENTION OF THE ’376
`PATENT
`
`The ’376 Patent describes a method for processing a telephony session
`
`involving a call router (22) connected both to a telephony network, such as the
`
`public switched telephone network (“PSTN”) (21), and to an application server
`
`(26) via the Internet (24):
`
`
`
`EX1001 at Abstract; FIG. 2A.
`
`
`
`The method, illustrated in the annotated Figure 2A above, includes the
`
`following steps. The call router accepts an incoming message, such as a phone call
`
`from a telephony network, and communicates with an application server to receive
`
`an application response. Id. at 3:14-4:31. The call router then converts the
`
`response into telephony action on the telephony network (S120), such that, for
`
`
`
`2
`
`

`

`example, a call is initiated, DTMF digits are collected, or an SMS message is sent.
`
`Id. at 6:35-58.
`
`The call router includes resources (29), i.e. information and/or functionality
`
`that an application can access via an application programming interface (“API”)
`
`(28). Id. at 8:4-8. The ’376 Patent describes a call router resource, such as, for
`
`example, a media resource, which allows an application to retrieve text messages
`
`stored on the call router. Id. at 12:1-10. The ’376 Patent also describes a
`
`functional call router resource, which can, for example, modify the state of a
`
`telephony session in the call router, such as, initiating, terminating, or transferring
`
`a call. Id. at 10:35-59; 11:13-30.
`
`The ’376 Patent describes two message formats that an application can use
`
`to request a resource on the call router: (1) a message with the URI of the resource
`
`in the request line, i.e. the first line of the message or (2) a message that identifies
`
`the resource in the body of the message. Id. at 4:50-58. In response to the
`
`application server request for a specified resource, the call router responds by
`
`performing the function, such as, for example, initiating, terminating, or
`
`transferring a call, or by returning the information requested, such as, for example,
`
`the requested text messages.
`
`B.
`
`PROSECUTION HISTORY FOR THE ’376 PATENT
`
`
`
`3
`
`

`

`The application resulting in the ’376 Patent, U.S. Patent Application No.
`
`13/743,078, was filed January 16, 2013. It is a continuation application of U.S.
`
`Patent Application No. 13/632,798, filed October 1, 2012, which is a continuation
`
`application of U.S. Patent No. 8,306,021, filed April 2, 2009, which claims priority
`
`to U.S. Provisional Patent Application Nos.: 61/041,829, filed April 2, 2008;
`
`61/055,417, filed May 22, 2008; 61/100,578, filed September 26, 2008; and
`
`61/156,746 and 61/156,751, both filed March 2, 2009. For purposes of this
`
`proceeding only, Petitioner assumes that the priority date for the Challenged claims
`
`is April 2, 2008.
`
`In a first Office Action, the Examiner rejected all claims in light of certain
`
`prior art references. EX1002 at 922-932. In an applicant-initiated interview with
`
`the Examiner, “[i]t was agreed that applicants would amend the claims to specify
`
`the phrase ‘RESTful’ in a more defined matter.” Id. at 985-991. Applicant
`
`subsequently amended the claim term “RESTful” to “REST.” Id. at 996. For
`
`example, Applicant amended the following portion of claim 1 as follows:
`
`“exposing the plurality of API resources through a RESTful representational state
`
`transfer (REST) API that comprises: receiving a RESTful API request that
`
`specifies an API resource URI.” Id. at 985. The Examiner issued a final rejection,
`
`rejecting all claim in light of the prior art references identified in the first Office
`
`Action. Id. at 1021-1024.
`
`
`
`4
`
`

`

`After conducting a second applicant-initiated interview (id. at 1040-1043),
`
`the Examiner allowed all claims finding that “the prior art does not teach or
`
`adequately suggest a representational state transfer (REST) API through which a
`
`plurality of API resources operating a telephony network and Internet connected
`
`system are exposed.” Id. at 1049. In addition, the Examiner found that “[t]he prior
`
`art does not teach o[r] suggest a REST API request that specifies an API resource
`
`URI and responding to the REST API request.” Id. at 1049.
`
`III. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R.
`§ 42.104
`
`A. GROUNDS FOR STANDING UNDER 37 C.F.R. § 42.104(A)
`
`Petitioner certifies that the ’376 Patent is available for IPR and that the
`
`Petitioner is not barred or estopped from requesting IPR challenging the claims of
`
`the ’376 Patent.
`
`B.
`
`IDENTIFICATION OF CHALLENGES UNDER 37 C.F.R. §
`42.104(B) AND RELIEF REQUESTED
`
`In view of the prior art and evidence, claims 1-3, 5, 14, 16-17, and 19 of the
`
`’376 Patent are unpatentable and should be cancelled. 37 C.F.R. § 42.104(b)(1).
`
`Based on the prior art references identified below, IPR of the Challenged Claims
`
`should be granted. 37 C.F.R. § 42.104(b)(2).
`
`Proposed Grounds of Unpatentability
`
`Exhibit
`Numbers
`Ground 1: Claims 1-3, 14, 16, and 19 are obvious under § EX1003 and
`EX1004
`
`
`
`5
`
`

`

`103(a) over U.S. Patent No. 6,801,604 to Maes et al. (“Maes”) in
`
`view of U.S. Patent Application Publication No. 2003/0204756 to
`
`Ransom et al. (“Ransom”)
`
`Ground 2: Claims 5 and 17 are obvious under § 103(a) over
`
`Maes in view of Ransom and further in view of U.S. Patent No.
`
`7,092,370 to Jiang et al. (“Jiang”)
`
`Ground 3: Claims 1-3, 5, 14, and 16 are obvious under § 103(a)
`
`over Open Service Access (OSA) Parlay X Web Services, ETSI
`
`Standard 202 391-4 v.1.2.1 (“ETSI ES 202 391-4”) in view of
`
`Ransom
`
`Ground 4: Claim 17 is obvious under § 103(a) over ETSI ES
`
`202 391-4 in view of Ransom and further in view of Open
`
`Service Access (OSA) Parlay X Web Services, ETSI Standard
`
`202 391-7 v.1.2.1 (“ETSI ES 202 391-7”)
`
`Ground 5: Claim 19 is obvious under § 103(a) over ETSI ES
`
`202 391-4 in view of Ransom and further in view of Open
`
`Service Access (OSA) Parlay X Web Services, ETSI Standard
`
`202 391-2 v.1.2.1 (“ETSI ES 202 391-2”)
`
`EX1003,
`EX1004, and
`EX1005
`
`EX1006 and
`EX1004
`
`EX1006,
`EX1004, and
`EX1007
`
`EX1006,
`EX1004, and
`EX1008
`
`Section IV.A-E identifies where each element of the Challenged Claims is
`
`found in the identified prior art. 37 C.F.R. § 42.104(b)(4). The exhibit numbers of
`
`
`
`6
`
`

`

`the supporting evidence relied upon to support the challenges are identified in the
`
`above chart and the relevance of the evidence to the challenges raised are provided
`
`in Section IV.A-E.
`
`C. LEVEL OF ORDINARY SKILL IN THE ART
`
`As explained by Dr. Nielson, the use of web services for communication
`
`between two applications or devices over the Internet was known well before April
`
`2, 2008, the earliest priority date of the ’376 Patent. EX1009 at [0046]-[0047]. In
`
`fact, by this date, there were two well-known approaches to providing web
`
`services, including Simple Object Access Protocol (“SOAP”) and Representational
`
`State Transfer (“REST”). Id. at [0061]. Version 1.2 of the SOAP specification
`
`was submitted to the W3C (World Wide Web Consortium) in 2001. Id. at [0064].
`
`Unlike SOAP, REST is not a protocol and there is no specification, but
`
`instead is a style of protocol and, in fact, one could even have a SOAP API that
`
`follows RESTful principles. Id. at [0068]. Importantly though, as confirmed by Dr.
`
`Nielson, one of skill in the art prior to April 2008 would have readily understood
`
`that there is no difference in the power or capability of a system that uses a SOAP-
`
`based or REST-based API and in fact, they are functionally equivalent. Id. at
`
`[0070]-[0071]. Even with the differences between SOAP and REST and the fact
`
`that some have preferences for one over the other, as far as programming language
`
`
`
`7
`
`

`

`capability, they are identical. Id. at [0070]. That is, every program that can be
`
`created in one language can be created in another. Id. at [0070]-[0071].
`
`Indeed, even as far back as 2002, it was well known that SOAP and REST
`
`were alternatives and were interchangeable. EX1002 at [0071];[0072];[0075].
`
`While SOAP seemed to be the preference in 2002, by 2005, there was a trend to
`
`implement APIs using REST. EX1009 at [0070]-[0072]. As the article notes, new
`
`companies at the time, such as Yahoo, began implementing their APIs using REST
`
`while more established companies, such as Google who had started with SOAP to
`
`begin with, stayed with SOAP-based APIs. Id. at [0073]. By December 2006, still
`
`a year and half before the filing of the provisional patent application for the ’376
`
`Patent, Yahoo even filed a patent application directed to a solution for converting
`
`between SOAP and REST. Id. at [0073]-[0074].
`
`A person having ordinary skill in the art at the time of the ’376 Patent would
`
`have had a bachelor’s degree in computer science with at least two years of
`
`experience in application development. Id. at [0049]-[0050].
`
`D. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3)
`
`In an inter partes review, claim terms in an unexpired patent are given
`
`their “broadest reasonable construction in light of the specification of the patent in
`
`which [they] appear [].” 37 C.F.R. § 42.100(b); Cuozzo Speed Techs., LLC v. Lee,
`
`
`
`8
`
`

`

`136 S.Ct. 2131, 2144-46 (2016). All claim terms should be given their broadest
`
`reasonable construction in light of the specification.
`
`IV. THERE
`IS A REASONABLE LIKELIHOOD THAT THE
`CHALLENGED CLAIMS OF THE
`’376 PATENT ARE
`UNPATENTABLE
`
`A. Ground 1: Maes in view of Ransom Renders Claims 1-3, 14, 16,
`and 19 Obvious
`
`1.
`
`Summary of Maes
`
`U.S. Patent No. 6,801,604 to Maes et al. (“Maes”) was published on May 8,
`
`2003 as U.S. Publication No. 2003/0088421 and issued on October 5, 2004 and
`
`qualifies as prior art with regard to the ’376 Patent under 35 U.S.C. § 102(b) (pre-
`
`AIA). Maes generally relates to the use of web services to provide IP-based
`
`applications over various telephony networks, such as PSTN. EX1003 at Abstract,
`
`FIG. 1, FIG. 11, 3:52-65. Because of the “strong desire for development of
`
`distributed conversational systems having scalable and flexible architectures,
`
`which enable implementation of such systems over a wide range of application
`
`environments and voice processing platforms,” the system of Maes, illustrated in
`
`FIG. 1 was developed:
`
`
`
`9
`
`

`

`
`
` Id. at FIG. 1; 6:62-63. FIG. 1 illustrates various components used to provide
`
`connectivity to a telephone line and perform various functionalities associated with
`
`the telephony session by way of web services and a call router. Id. at FIG. 1; 6:50-
`
`9:38. The system of Maes is compatible with a wide variety of telephony
`
`networks, including PSTN. Id. at 6:62-63; FIG. 11.
`
`Control messages are exchanged in the Maes system to allow, for example,
`
`the application server to request services or functions from one or more of the
`
`speech engines. Id. at 4:21-34; 7:61-8:14. These functions may include collecting
`
`digits, playing prompts, recording audio, making a call, transferring a call, etc. Id.
`
`at 15:66-16:26 (“The application then sends an XML control message to the task
`
`manager (using, e.g., SOAP) requesting certain functionalities…”). The control
`
`
`
`10
`
`

`

`messages taught in Maes use HTTP, and therefore can utilize URIs. Id. at 28:23-
`
`26. (“SOAP presents the advantage that SOAP: … runs over HTTP…”).
`
`Maes teaches having the TEL 20 component of the system receive control
`
`messages to manage access to the telephony facilities of the PSTN. Id. at 34:7:10.
`
`(“TEL: The TEL component is assumed to be a telephony platform or a gateway—
`
`I/O platform capable of receiving the HTTP/SOAP requests and access to control
`
`of the telephony facilities.”). As mentioned, control messages are used by the
`
`system to request functionality or resources and are routed by addresses, such as
`
`URIs. Id. at 10:50-56. (“The application sends request to the router/load manager
`
`(via the task manager) for a particular functionality or resource. As a result, the
`
`router/load manager passes the address of the engines to the task manager and the
`
`audio I/O system. The task manager ships SOAP instructions to the engines. The
`
`audio I/O system ships RTP audio to and from the engine address.”).
`
`Maes was submitted in an IDS by the Applicant during prosecution of the
`
`’376 Patent. But Maes was neither used in a substantive rejection nor discussed
`
`during prosecution. See EX1002 at 1092. The Board has repeatedly declined to
`
`invoke its discretion under § 325(d) to deny institution of an inter partes review
`
`petition under similar circumstances. See, e.g., Scientific Fox Factory v. SRAM,
`
`Case No. IPR2017-00472, slip op., at 7 (PTAB, Apr. 21, 2017) (Paper 10)
`
`(refusing to exercise discretion under § 325(d) to deny petition where the reference
`
`
`
`11
`
`

`

`forming the basis of the petition was cited in an IDS during prosecution of the
`
`subject patent but was not used in a rejection or discussed during prosecution);
`
`Digital Check v. e-ImageData, Case No. IPR2017-00178, slip op., at 12-13
`
`(PTAB, Apr. 25, 2017) (Paper 6) (same).
`
`The ’376 Patent is directed to the field of web services, i.e. web applications,
`
`and in particular, telephony-based web services. In describing examples of the
`
`invention, the ’376 Patent notes that “[c]all router applications are preferably web
`
`applications, implementing the most common phone system features . . . .”
`
`EX1001 at 15:45-47. The ’376 Patent identifies several examples of telephony-
`
`based web services, i.e. web applications, such as an AutoAttendant application, a
`
`AutoConference application, a Queuing application, and a SMS reader/TTY
`
`application. Id. at 15:49-18:22. Maes is in the same field of endeavor as the ‘376
`
`Patent, namely web services, which enable disparate networks, including telephony
`
`networks (e.g., PSTN) to communicate and share data over the Internet. Clearly,
`
`Maes is in the same field of endeavor as the claimed invention of the ‘376 Patent
`
`and is therefore analogous art to the claimed invention of the ‘376 Patent. EX1009
`
`at [0051]-[0056].
`
`2.
`
`Summary of Ransom
`
`U.S. Patent Application Publication No. 2003/0204756 to Ransom et al.
`
`(“Ransom”) was published on October 30, 2003 and therefore qualifies as prior art
`
`
`
`12
`
`

`

`with regard to the ’376 Patent under 35 U.S.C. § 102(b) (pre-AIA). Ransom was
`
`not cited during prosecution of the ’376 Patent. Ransom generally relates to
`
`Internet-based applications for communicating with and controlling disparate
`
`networks. For example, Ransom discloses a power management application for an
`
`electrical distribution network connected over the Internet to intelligent electronic
`
`devices (“IEDs”) located in the field. EX1004 at [0045]. An IED monitors the
`
`flow of power over an electrical distribution network and provides this information
`
`over the Internet to an application. Id. at [0056]; [0058]. Based on the information
`
`provided by the IED, such as an excess of power, the application sends a command
`
`back to the IED to control power flow. Id. at [0056].
`
`Ransom notes that there are two well-known models using the HTTP
`
`protocol that allow for a standardized way of providing interoperability between
`
`disparate operating systems – SOAP and REST. Id. at [0073] (“SOAP allows a
`
`program running one kind of operating system to communicate with the same kind,
`
`or another kind of operating system, by using HTTP and XML as mechanisms for
`
`the information exchange.”); id. at [0109] (“Transmission in XML/SOAP format
`
`allows the recipient to receive XML-tagged data from a sender and not require
`
`knowledge of how the sender’s system operates or data formats are organized.”)
`
`As Ransom notes, in the SOAP model the function being invoked is located in the
`
`
`
`13
`
`

`

`body of a request while in the REST model the function being invoked is located in
`
`the URI of a request. Id. at [0162] – [0163], [0185].
`
`Both Ransom and the claimed invention of the ’376 Patent are in the same
`
`general field of endeavor, namely software applications having a standardized way
`
`of providing interoperability between disparate networks. Ransom focuses on
`
`applications having interoperability with an electrical power distribution system
`
`while the ’376 Patent focuses on applications having interoperability with a
`
`telephony network. As the Federal Circuit has highlighted, “[t]he field of endeavor
`
`of a patent is not limited to the specific point of novelty, the narrowest possible
`
`conception of the field, or the particular focus within a given field.” Unwired
`
`Planet, LLC v. Google Inc., 841 F.3d 995, 1001-02 (Fed. Cir. 2016). Here, a
`
`POSA would not just look to software applications having a standardized way of
`
`providing interoperability with a telephony network but would more broadly look
`
`software applications having a standardized way of providing interoperability with
`
`any disparate network. EX1009 at [0058]. Here, Ransom is in the same field of
`
`endeavor as the claimed invention of the ’376 Patent and is therefore analogous art
`
`to the claimed invention of the ’376 Patent. EX1009 at [0057]-[0058].
`
`3.
`
`Claim 1
`
`[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:
`
`
`
`14
`
`

`

`As illustrated in Figure 1, Maes teaches a system, connected to an IP
`
`network 13, such as the Internet, (e.g., internet connected system) that includes a
`
`router and load manager 21 and various telephony-based servers, such as an
`
`automatic speech recognition (“ASR”) server 15, a natural language parser server
`
`(“NL”) 17, a text-to-speech (“TTS”) server 18, a speaker identification/verification
`
`(“SPID”) server 19, and an audio I/O system (“TEL”) 20 (e.g., plurality of API
`
`Resources):
`
`EX1003 at FIG. 1. As illustrated in annotated Figure 11, this Internet-connected
`
`system is also connected to a telephony network, such as the PSTN, via an
`
`application server response system 11:
`
`
`
`
`
`15
`
`

`

`
`
`Id. at FIG. 11. 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. Id. at cols. 34-35. By
`
`sending a request to TEL 20 over the Internet, an application 14 / task manager 15
`
`(identified in Figure 1), can invoke the telephony-network functionalities of TEL
`
`20 for performance on a telephony network. Id.
`
`[1a]
`
`initiating a telephony session,
`
`The ’376 patent describes “initiating a telephony session” as accepting a
`
`phone call. EX1001 at 3:14-21 (emphasis added) (“Step S1, which recites
`
`initiating a telephony session, functions to accept an incoming message. The
`
`message is preferably a call . . . .”). In Maes, the client voice response system 11
`
`receives an incoming call. EX1003 at 15:44-48 (“Initially, a call (new incoming
`
`voice communication, i.e., establishment of a new voice session which, in
`
`
`
`16
`
`

`

`telephony is a call and which on VoIP, could be a SIP session, etc.) is received by
`
`the client voice response system 11 (step 90).”). After the client voice response
`
`system 11 receives the call, Maes discloses that the application instructs TEL 20 to
`
`accept the call. Id. at 15:63-65 (The application then sends a message (via the task
`
`manager) to the TEL 20 to accept the call (i.e., the TEL ID is initiated) (step 96).”
`
`[1b] communicating with an application server to receive an application
`response,
`
`Maes discloses that once an application is assigned to the incoming call, the
`
`router/load manager 21 sends a request (e.g., communicating) to application 14,
`
`residing on an application server:
`
`
`
`17
`
`
`
`

`

`EX1003 at 7:45-46; 15:59-62; FIG. 1 (annotated).
`
`In response, application 14, via task manager 15, sends a message (e.g.,
`
`application response) instructing TEL 20 to play a text-to-speech stream to the
`
`caller, request the caller’s ID, record the ID that the caller utters to an ASR port,
`
`and collect DTMF digits from the caller. Id. at 16:14-26 (noting that “based on a
`
`request from the application . . . . The task manager may instruct the TEL to
`
`playback a TTS stream or prerecorded file from a particular socket, record to an
`
`ASR port, and collect DTMF digits with a # termination.”).
`
`[1c] converting the application response into executable operations to
`process the telephony session,
`
`The ’376 Patent describes that “[t]he step of processing telephone
`
`instructions with a call router S120 preferably functions to convert the
`
`[application] server[’s] response into telephony actions or executable operations
`
`during a telephony session.” EX1001 at 6:46-49. As the ’376 Patent highlights,
`
`“[t]he telephony actions may include . . . calling another number (such as creating
`
`a new voice connection through the PSTN, SIP/VoIP, or other IP technology
`
`system), collecting digits via DTMF input, recording voice response audio . . . .”)
`
`Id. at 6:49-58.
`
`Maes discloses that after receiving the response from application 14 via task
`
`manager 15 TEL 20 executes telephony actions. In particular, TEL 20 will play a
`
`text-to-speech stream to the caller, request the caller’s ID, record the ID that the
`
`
`
`18
`
`

`

`caller utters to an ASR port, and collect DTMF digits from the caller. EX1003 at
`
`16:14-26 (noting that “based on a request from the application . . . . The task
`
`manager may instruct the TEL to playback a TTS stream or prerecorded file from a
`
`particular socket, record to an ASR port, and collect DTMF digits with a #
`
`termination. The task manager will wait for all three responses (TTS, ASR,
`
`DTMF) to come back with a status before the application gets the results (step
`
`101).”).
`
`[1d] creating at least one informational API resource and
`
`The specification of the ’376 Patent discloses that “creating call router
`
`resources accessible through an Application Programming Interface (API) []
`
`preferably functions to expose information and/or functionality of the call router.”
`
`EX1001 at 8:4-8. The ’376 Patent does not expressly use the term “informational
`
`API resource.” See EX1001. Nevertheless, the ’376 Patent does describe a media
`
`API resource. Id. at 11:66-12:42. The ’376 Patent describes that “[t]he media
`
`resource of the preferred embodiment functions to allow an application to
`
`retrieve and/or access information of media stored, cached, created, and/or
`
`used during a call.” Id. at 11:66-12:1 (emphasis added). “[T]he media resource
`
`may additionally be integrated with the telephony instructions . . . such that a
`
`telephony instruction may instruct the call router to perform an action that creates a
`
`media resource.” Id. at 12:10-14.
`
`
`
`19
`
`

`

`Maes provides examples of messages that an application 14 (which Maes
`
`uses interchangeably with the word “controller,” see, e.g., EX1003 at 15:7-12; at
`
`21:55-63; at 25:3-8; at 25:65-26:4; at 29:65-30:3) exchanges with TEL 20 in order
`
`to obtain media created during a call. Id. at 34:1-7 (“The following exemplary list
`
`of messages comprises a non-exhaustive lis[t] of messages that can be exchanged
`
`between the controller and the remote conversational engines.”). In particular,
`
`Maes discloses an application sending TEL 20 a SOAP message instructing the
`
`collection of DTMF digits from a caller (“CollectDigits”):
`
`
`
`Id. at 34:20-35:9 (annotated). Maes discloses that media created in response to the
`
`application’s instruction, namely the collected digits, i.e. an informational API
`
`resource, are then sent from TEL 20 via the Internet to application 14. Id. at 35:29-
`
`31 (emphasis added) (“If digits collection is requested, the status (Done, Timeout,
`
`Terminating Digit) and collected digits are included in the response.”)
`
`[1e] exposing the plurality of API resources through a representational state
`transfer (REST) API that comprises:
`
`
`
`Maes discloses several resources accessible via an API. Id. at 16:4-8. 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,”
`
`
`
`20
`
`

`

`“DropCall,” “TransferCall,” etc. These exemplary API resources are illustrated in
`
`the control message below:
`
`
`
`Id. at cols. 34-35 (annotated); see also EX1009 at [0059]-[0060].
`
`To the extent one might argue that the API resources of Maes are not
`
`accessible via a REST API, Ransom establishes that a REST API was well known
`
`in the art. See EX1009 at [0061]. As Ransom notes, REST and SOAP “are two
`
`common web service models wherein HTTP is the underlying application
`
`protocol.” EX1004 at [0163]. Ransom teaches a message exchange invoking
`
`
`
`21
`
`

`

`REST conventions or alternatively invoking SOAP conventions. EX1004 at
`
`[0161]-[0163]; [0184]-[0185].
`
`Ransom establishes that it would have been an obvious matter of design
`
`choice to a POSA to use a REST API to expose resources as opposed to a SOAP
`
`API as Maes discloses. The ’376 Patent makes clear that using a REST API as
`
`opposed to a SOAP API does not serve any advantage or present any novel or
`
`unexpected result. EX1009 at [0081]-[0082]. The ’376 Patent concedes that REST
`
`APIs were well known in the art at the time of the ’376 Patent:
`
`The method of processing telephony instructions and
`creating call router resources accessible through an API
`(a call router API) cooperatively function to enable a
`stateless and simple telephony language with more call
`router resources and information provided through the
`call router (preferably a REST API as is familiar to
`many web developers).”)
`
`EX1001 at 2:10-16 (emphasis added); id. at 8:12-17 (emphasis added) (“The Call
`
`Router API is preferably an application programming interface (API) such as a
`
`REST API (Representational State Transfer) as is known in the art . . . .”); id.
`
`at 5:16-18 (emphasis added) (“The HTTP request (or any suitable request
`
`communication) to the server preferably observes the principles of a RESTful
`
`design. RESTful is understood in this document to describe a Representational
`
`State Transfer architecture as is known in the art.”)
`
`
`
`22
`
`

`

`The ’376 Patent also teaches that a REST API and a SOAP API are two
`
`ways to implement the invention. Id. at 8:12-17 (emphasis added) (“The Call
`
`Router API is preferably an application programming interface (API) such as a
`
`REST API (Representational State Transfer) as is known in the art, but the Call
`
`Router API may alternatively be a SOAP (Simple Object Access Protocol)
`
`API or any suitable programmatic communication interface.”); id. at 9:13-18
`
`(emphasis added) (“The Call Router API response is preferably similar to a REST
`
`API response, where the response is a representation of the requested resource.
`
`The Call Router API response may alternatively conform to any suitable
`
`programming principle such as SOAP.”) Indeed, the ’376 Patent does not
`
`describe REST APIs as providing an advantage over SOAP APIs but instead
`
`teaches that either one can be used in conjunction with the invention. Moreover,
`
`using a REST API to access resources as opposed to a SOAP API presents no
`
`novel or unexpected result. The function remains the same, namely both APIs
`
`allow access to resources. EX1009 at [0070]-[0071].
`
`Here, implementing the SOAP-based system of Maes in conformance with
`
`the REST principles of Ransom, such that Maes’ telephony resources were
`
`accessible via a REST API would have been an obvious matter of design choice.
`
`EX1009 at [0062]. A REST API and a SOAP API were two well-known APIs at
`
`the time of the ’376 patent for achieving the same result of accessing API
`
`
`
`23
`
`

`

`resources. EX1009 at [0062]-[0075]. Implementing the system of Maes using the
`
`well-known REST model taught in Ransom would have been well within the