PTAB

IPR2017-01978

TeleSign Corp v. Twilio Inc

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Telephony-Based Application Creation via Web Services
  • Brief Description: The ’021 patent describes a method and system that allows web developers to create telephony-based applications without expertise in complex telephony network interfacing. The system uses a call router that acts as a gateway between a telephony network (e.g., PSTN) and an application server, enabling the server to invoke telephony functions via a web service API using standard protocols like HTTP.

3. Grounds for Unpatentability

Ground 1: Obviousness over Maes and Ransom - Claims 1-4, 6-7, and 11 are obvious over Maes in view of Ransom.

  • Prior Art Relied Upon: Maes (Patent 6,801,604) and Ransom (Application # 2003/0204756).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Maes disclosed a system for processing telephony sessions using web services to connect IP-based applications to telephony networks. Maes taught a call router (TEL 20) that receives control messages (e.g., "MakeCall," "DropCall") from an application to perform telephony functions. Petitioner contended that Maes, being a SOAP-based system, inherently suggested the core elements of claim 1. Ransom was introduced to explicitly teach well-known web service conventions that Maes did not detail. Specifically, Ransom taught that in both SOAP and REST models, resources are accessed via a URI. Ransom further taught that in a REST model, state information can be encoded within the URI itself, as opposed to the body of a message. Petitioner argued that applying Ransom’s teachings to Maes’s system would render the limitations of storing state information in a resource's URI and making the API substantially a REST API obvious. For dependent claims, Ransom was cited to teach using HTTP (claim 4) and digital signatures for authentication (claims 6-7).
    • Motivation to Combine: A POSITA looking to implement the system in Maes would have been motivated to consult a reference like Ransom to fill in implementation details and understand design trade-offs. Maes referenced web service technologies like SOAP without detailed explanations, and Ransom provided these well-known principles, including the alternative REST architecture and its conventions for accessing resources and structuring requests via URIs.
    • Expectation of Success: Combining Ransom’s well-known, standardized web service principles with Maes’s specific telephony application was a predictable application of known technologies. Implementing a REST or SOAP model as taught by Ransom would be well within the abilities of a POSITA.

Ground 2: Obviousness over ETSI Standards and Ransom - Claims 1-3, 11, and 12 are obvious over ETSI-202-391-4 in view of ETSI-202-391-11 and Ransom.

  • Prior Art Relied Upon: ETSI-202-391-4, ETSI-202-391-11 (collectively, the Parlay X Web Services standards), and Ransom (Application # 2003/0204756).

  • Core Argument for this Ground:

    • Prior Art Mapping: Petitioner asserted that the ETSI standards described a standardized set of web service APIs (Parlay X) for accessing telephony-based functions. ETSI-202-391-4 taught a Short Messaging Service (SMS) Web Service API, and ETSI-202-391-11 taught an Audio Call Web Service API, both using a request-response model. Together, they disclosed creating call router resources (e.g., a "makeACall" operation), sending requests to an application server upon receiving an SMS, and receiving telephony instructions in response. Similar to Ground 1, Ransom was cited to make explicit that resources in such SOAP-based systems are accessed via a URI and that it would be an obvious design choice to use a REST model where state information is stored in the URI. For claim 12, Petitioner argued that ETSI-202-391-4 directly taught a telephony session that includes a sent SMS message.
    • Motivation to Combine: The ETSI standards provided a framework but did not detail specific implementation choices or trade-offs between web service architectures like SOAP and REST. A POSITA implementing the ETSI APIs would be motivated to consult Ransom to understand and apply these conventional, interchangeable design options for structuring the API, such as using URIs to access resources and locate state information as taught in the REST model.
    • Expectation of Success: Applying the general, well-understood web service architectural principles from Ransom to the standardized telephony APIs defined in the ETSI documents was a straightforward and predictable integration of known elements.

  • Additional Grounds: Petitioner asserted two additional grounds. Ground 2 argued claim 12 is obvious over Maes, Ransom, and Jiang (Patent 7,092,370), where Jiang was added to explicitly teach initiating a telephony session by sending an SMS message. Ground 4 argued claims 4, 6, and 7 are obvious over the ETSI combination from Ground 3 further in view of Ransom and ETSI-202-391-1, where the additional ETSI reference was used to explicitly teach that all Parlay X messages use HTTP and can include digital signatures for security.

4. Relief Requested

  • Petitioner requests institution of an inter partes review and cancellation of claims 1-4, 6-7, and 11-12 of Patent 8,306,021 as unpatentable.