Searching over 5,500,000 cases.


searching
Buy This Entire Record For $7.95

Download the entire decision to receive the complete text, official citation,
docket number, dissents and concurrences, and footnotes for this case.

Learn more about what you receive with purchase of this case.

Twilio, Inc. v. Telesign Corp.

United States District Court, N.D. California, San Jose Division

March 31, 2017

TWILIO, INC., Plaintiff,
v.
TELESIGN CORPORATION, Defendant.

          ORDER GRANTING IN PART AND DENYING IN PART DEFENDANT'S MOTION TO DISMISS RE: DKT. NO. 31

          LUCY H. KOH United States District Judge

         Plaintiff Twiilio, Inc. (“Twilio” or “Plaintiff”) filed a patent infringement suit against Defendant Telesign Corporation (“Telesign” or “Defendant”) and alleged that Defendant infringed the claims of U.S. Patent Nos. 8, 306, 021 (“the '021 Patent”), 8, 837, 465 (“the '465 Patent”), 8, 755, 376 (“the '376 Patent”), 8, 738, 051 (“the '051 Patent”), 8, 737, 962 (“the '962 Patent”), 9, 270, 833 (“the '833 Patent”), and 9, 226, 217 (“the '217 Patent”) (collectively, the “Asserted Patents”). Before the Court is Defendant's Motion to Dismiss, which seeks to dismiss all seven Asserted Patents. ECF No. 31 (“Mot.”). Due to the breadth of Defendant's Motion to Dismiss, the Court will issue its decision in two orders. This order covers the '962, '833, '021, '465, and '376 patents. Having considered the submissions of the parties, the relevant law, and the record in this case, the Court GRANTS IN PART and DENIES IN PART Defendant's Motion to Dismiss with respect to these patents.

         I. BACKGROUND

         A. Factual Background

         1. The Parties

         Plaintiff Twilio is a Delaware corporation with its primary place of business in San Francisco, California. ECF No. 1 (“Compl.”) ¶ 1. Plaintiff's co-founder, Jeffrey Lawson, is a co-inventor on three of the Asserted Patents. ECF No. 45 at 1. Defendant Telesign is a California corporation with its principal place of business in Marina Del Rey, California. Compl. ¶ 15.

         2. The Twilio Patents

         Plaintiff's complaint and the parties' briefing divides the asserted patents into four families: (1) the '962 and '833 patents (the “Score Patents”), (2) the '051 patent (the “Delivery Receipts Patent”), (3) the '021, '465, and '376 patents (the “Platform Patents”), and (4) the '217 patent (the “Path Selection Patent”). As mentioned above, this order covers the '962, '833, '021, '465, and '376 patents, which are the patents from the Score Patents and Platform Patents families. An overview of the two patent families follows.

         a. The Score Patents

         i. Specification

         The '962 patent is titled “Method and System for Preventing Illicit Use of a Telephony Platform.” Compl, Ex. E ('962 patent). It was filed on July 24, 2013 and issued on May 27, 2014. It claims priority to a provisional application, which was filed on July 24, 2012.

         The '833 patent is also titled “Method and System for Preventing Illicit Use of a Telephony Platform.” Compl., Ex. F ('833 patent). It was filed on April 15, 2014 as a divisional application of the '962 patent. It issued on February 23, 2016. Its specification is identical to the '962 patent, and it also claims priority to the same July 24, 2012 provisional application.

         The Score Patents generally relate to “preventing illicit use of a telephony platform.” '962 patent at col. 1:15. As the Background section of the specification explains, “[t]elephone fraud has long been a problem for telephony systems.” Id. at col. 1:20-21. However, in recent years, "the opportunities for telephony fraud is [sic] even greater." Id. at col. 1:22-23. This is because "[t]he recent development of new telephony platforms . . . enable[] nefarious parties to create programs that commit telephony fraud." Id. at col. 1:23-26. Examples of such fraud include toll fraud, chargebacks, and "us[ing] valuable resources for improper uses that would otherwise be used for legitimate applications." Mat col. 1:26-33.

         The Score Patents purport to address telephony fraud through a method of "fraud scoring, " which "monitor[s], measure[s], and detect[s] instances of illicit use that occur within or through the communication platform." Id. at col. 4:4-6. Figure 1 shows how this fraud scoring mechanism is deployed within a communication platform:

         (IMAGE OMITTED)

         As Figure 1 illustrates, the fraud scoring method functions as a component of a communication platform. Id. at Fig. 1. The communication platform includes a multitenant account system, which "manage[s] and facilitate[s] the accounts within the communication platform." Id. at col. 3:28-29. It also includes "operational components" which include "any servers, databases, processors or other resources that either define account configuration, account usage, or other aspects of the account within the platform." Id. at col. 5:33-36. The fraud scoring method utilizes the multitenant account system and the operational components of the communication platform. Id. at col. 2:16-35, 5:30-32, Fig. 1.

         Figure 2 illustrates the operation of the fraud scoring method within the communication platform:

         (IMAGE OMITTED)

         The first step, "enrolling a plurality of accounts in the platform, " refers to general account set up and configuration activities. Id. at col. 6:50-51. This includes associating an account with phone number(s), billing information, and relevant internet resources. Id. at col. 7:13-50. In the system, it is possible to create sub-accounts that correspond to a single, base account. Id. at col. 3:54-58. "For example, an application developer may create a customer service application, and then allow end users to signup as customers within his account." Id. at col. 3:60-63. The customers' accounts would then be sub-accounts of the customer service application's account. See Id. This allows both the customer and the customer service application to modify the customer accounts. Id. at col. 3:63-66.

         The remaining steps describe the core fraud detection functionality. First, at step S120, the fraud score method “receive[s] usage data of a telephony platform component.” Id. at col. 7:51-52, Fig. 2. This step “functions to collect data used to calculate a fraud score.” Id. at col. 7:53. Usage data can be pulled from “a variety of data sources, ” including “call history databases, messaging history databases, account databases, credit card hash databases, account databases, client device information databases, IP address databases, phone number databases, credit card or spending databases, API logs, and/or any suitable machine containing data useful for calculating a fraud score.” Id. at col. 4:38, 8:3-9. For example, usage data stored in a call history database can include “call duration, account(s) associated with a call, call destination endpoints, caller endpoints, carrier origin of a call, destination carrier, frequency of calls, number of concurrent calls for an account, or any suitable parameter of call data.” Id. at col. 10:6-8.

         Next, at step S130, the fraud score method “calculat[es] a fraud score from the usage data.” Id. at col. 8:55-56, Fig 2. This “functions to process usage data to generate metric that reflects the likelihood that illicit use of the telephony platform is occurring.” Id. at col. 8:56-58. To calculate a fraud score, the method uses a set of fraud rules. Id. at col. 8:58-59. Fraud rules can either be conditions within a single account, or patterns across multiple accounts. Id. at col. 8:64-66. When a fraud rule is triggered, the corresponding account(s) are assigned a fraud score, which is generally a “numeric value” but may be a “label or any suitable construct to communicate fraud likelihood.” Id. at col. 9:16-18, 23-25. A single account may have multiple fraud rules (and, as a result, multiple fraud scores) associated with it, which reflect different fraud detection heuristics. Id. at col. 9:30-36.

         Next, at step S140, the method “detect[s] when fraud scores of an account satisfy a fraud threshold.” Id. at col. 11:64-65, Fig. 2. This “function[s] to monitor and assess when a scenario of illicit behavior is occurring based on the fraud scores.” Id. at col. 11:65-67. In one example, this is achieved by summing all the fraud scores across an account, and detecting when the sum is higher than a numeric threshold. Id. at col. 12:12-16.

         Finally, at step S150, the method “tak[es] action when a fraud score satisfies a fraud threshold.” Id. at col. 12:27-28. This “functions to react to fraud scores that indicate illicit behavior.” Id. at col. 12:28-29. Examples of actions include “flagging the account, throttling communication of an account, requesting additional billing information, notifying account holder, notifying an analyst of the communication platform, performing additional fraud detection analysis on the account, blocking particular actions on the account, or performing any suitable action.” Id. at col. 12:29-35.

         Neither the claims nor the specification provide much restriction on how these steps must be implemented. Instead, the specification makes a number of non-limiting statements, including: “The communication platform 100 can provide any suitable service.” Id. at col. 2:62-63. “The [fraud scoring] method is preferably used to prevent illicit use cases in . . . any suitable form of telephony communication.” Id. at col. 5:55-59. “The telephony platform components coupled to the fraud scoring system may include . . . any suitable machine containing data useful for calculating a fraud score.” Id. at col. 8:2-9. “[A]ny suitable usage data may . . . be used in calculating fraud score.” Id. at col. 9:55-56. And in particular, usage data associated with call history data may be “any suitable parameter of call data.” Id. at col. 10:7-8. Usage data associated with messaging history data may be “any suitable parameter of a message or messages sent through the telephony platform.” Id. at col. 10:40-41. “Usage data associated with platform account configuration data may include . . . any suitable platform account data.” Id. at col. 10:59-62. “[A]ny suitable parameters may be specified to determine a [fraud] rule set.” Id. at col. 13:6-7. “The fraud score is . . . any suitable construct to communicate fraud likelihood.” Id. at col. 9:22-24. Further, “any suitable relationship may be defined” between the fraud score and the likelihood of illicit use (e.g., the greater the score, the greater the likelihood, or vice versa). Id. at col. 9:24-26. “The reaction to a fraud score may include . . . performing any suitable action.” Id. at col. 12:29-35.

         ii. Asserted Claims

         In its Complaint, Twilio alleges that Telesign infringes at least claim 1 of the '962 patent and claim 5 of the '833 patent. Compl. ¶¶ 75, 91. Claim 1 recites:

         1. A method comprising:

enrolling a plurality of accounts on a telecommunications platform, wherein an account includes account configuration;
at a fraud detection system of the telecommunications platform, receiving account usage data, wherein the account usage data includes at least communication configuration data and billing configuration data of account configuration and further includes communication history of the plurality of accounts;
calculating fraud scores of a set of fraud rules from the usage data, wherein at least a sub-set of the fraud rules include conditions of usage data patterns between at least two accounts;
detecting when the fraud scores of an account satisfy a fraud threshold;
initiating an action response when a fraud score satisfies the fraud threshold.

'962 patent at col. 14:4-20.

         Claim 5 of the '833 patent recites:

         5. A method comprising: at a telecommunication platform:

enrolling a plurality of parent accounts in the telecommunication platform;
within a first enrolled account, enrolling at least one sub-account that is managed by the first account;
at a fraud detection system of the telecommunication platform, receiving sub-account usage data of a plurality of sub-accounts of the telecommunication platform, wherein the sub-account usage data of each of the plurality of sub-accounts includes at least configuration data of the sub-account and communication history data;
calculating fraud scores of a set of fraud scores from the sub-account usage data;
in a case where the set of fraud scores of a sub-account satisfy a fraud threshold, programmatically notifying the corresponding parent account of illicit behavior of the sub-account, the notification being provided via the telecommunication platform,
wherein illicit behavior includes at least one of toll fraud, spamming, terms of service violations, denial of service attacks, credit card fraud, suspicious behavior, and phishing attacks,
wherein the parent account is an account of an external service provider system, and
wherein each sub-account is an account of a system that uses a service of the external service provider system.

'833 patent at col. 15:9-col. 16:4.

         b. The Platform Patents

         i. Specification

         The '021 patent is titled “System and Method for Processing Telephony Sessions.” Compl. Ex. A ('021 patent). It was filed on April 2, 2009 and issued on November 6, 2012. It claims priority to three provisional applications, the earliest of which was filed on April 2, 2008.

         The '465 and '376 patents are also titled “System and Method for Processing Telephony Sessions.” Compl. Ex. B ('465 patent); Compl. Ex. C ('376 patent). The '465 patent was filed on January 16, 2013 and issued on September 16, 2014. The '376 patent was filed on January 16, 2013 and issued on June 17, 2014. Both patents are continuations of another patent application, which is a continuation of the '021 patent. Accordingly, all three Platform Patents share the same specification and priority date.

         The Platform Patents generally relate to “[a] system and method for processing telephony sessions.” '021 patent at col. 1:25-26. Telephony sessions, such as a phone call initiated over a public switched telephone network (“PSTN”) or a text message sent over the Short Message Service (SMS), are communications from one point to another. See id. at col. 3:16-53. However, these communications can be combined with computer logic to create interactive applications, such as an automated customer service hotline, see Id. at col. 15:60-65, or a dial-in conferencing service, see Id. at col. 16:11-20. In order to accomplish this, communication signals need to be “processed” so that input from the user (e.g., a button pressed, text sent, spoken response) is sent to the computer logic, and the appropriate response is sent back. See generally id. at col. 6:48-8:5. For example, processing a call to a customer service hotline would include detecting that the user selected, say, a “2” from the initial menu, and then retrieving and playing a recording for the new set of menu options to which option “2” corresponds. See, e.g., id. at col. 15:49-16:4, Fig. 7.

         The Background section of the specification explains that, at the time of patenting, implementation of these interactive applications was complicated. Id. at col. 1:30-58. At that time, “legislation and the advent of Voice over Internet Protocol (VoIP) ha[d] revolutionized the communication industry.” Id. at col. 1:30-32. There were new technologies for interactive applications, accompanied by new business models, and service providers. Id. at col. 1:32-33. For example, “[o]ne c[ould] implement extensible call switching and voice application logic in Open source software applications, such as Asterisk and FreeSwitch.” Id. at col. 1:34-36. However, getting these modern applications to work with traditional communications networks- such as telephone networks that handled voice communications and SMS messaging-presented “new complexities and challenges.” Id. at col. 1:38. In particular, “[d]eploying telephony services require[d] knowledge of voice networking and codecs, hardware or services to bridge servers to the public phone infrastructure, capital investment in hardware, and ongoing collocation of that hardware.” Id. at col. 1:39-43. In addition, the actual interactive application itself had to be developed, which “require[d] developers to train in new languages, tools, and development environments.” Id. at col. 1:45-46. Finally, “[o]ngoing operation and maintenance of these services require[d] teams to adopt new analysis tools, performance metrics, and debugging methodologies.” Id. at col. 1:50-53. All of these efforts were costly, requiring “significant upfront and ongoing investment.” Id. at col. 1:54-55.

         The Processing Patents purport to address these problems by providing a way for a modern applications to interact with traditional communication networks that mimics web-based programming. See Id. at col. 2:1-18. In particular, this solution “use[s] the familiar web site visitor model, ” where each step of a phone call is made to act like a web page. Id. at col. 2:5-8. For example, in one embodiment, input that a user enters into his telephone (e.g., pressing a “2” in the automated customer hotline example) is sent to the application via HTTP POST, the same mechanism that is used when a user submits a form on a website. See id. at col. 4:49-57, Fig. 7. The methods and systems also leverage “familiar concepts such as HTTP redirects, accessing resources through an API, cookies, and mime-type responses.” Id. at col. 2:9-11. According to the Processing Patents, this reduces complexity and expense because it “enables web developers to use their existing skills and tools with the esoteric world of telephony, making telephony application development as easy as web programming.” Id. at col. 2:2-5.

         In the Processing Patents, the ability to interact with a traditional communication network in a web-like way is accomplished through a "call router, " which sits between the traditional communication network and the modern application and translates between the two. Id. at col. 6:49-8:5, 13:12-14:14. Figures 2A and 3 A show this setup for a modern application communicating with a traditional phone line:

         (IMAGE OMITTED)

         Item 26 represents a server that runs the modern application ("application server"), such as code that implements the tree of menu options in a customer service hotline. Id. at col. 14:15-15:47. It communicates with the call router, item 22, using familiar web-like constructs. Id. at col. 13:29-14:14. The call router then takes these web-based descriptions of interactions and translates them into telephone signals that can be sent to the user's telephone, item 21, over a traditional telephone network, and vice versa. Id. at col. 6:49-8:5, 13:12-14:14. For example, the call router is able to detect the signal indicating that a user pressed a "2" coming from a traditional telephone line, translate that into an HTTP POST response, and send that over the internet to the application server. See Id. at col. 13:12-14:14, Fig. 7.

         Figure 1 illustrates the operation of the call router, the application server, and the communication network:

         (IMAGE OMITTED)

         The call router communicates with the application server using an “application layer protocol, ” such as HTTP or HTTPS. Id. at col. 14:24-26. The location of the application server, or an application hosted on an application server, is identified using a universal resource identifier (“URI”). Id. at col. 14:21-23. When a user initiates a telephony session (such as a phone call), the call router determines the URI that corresponds to the application server responsible for handling that call, and maps the call to that URI. Id. at col. 3:54-4:10. (For example, if a user calls a dial-in voice conferencing number, the call router maps that number to the URI for the server hosting the conferencing application. See Id. at col. 3:54-4:10, 15:51-54.) The call router then communicates that a new call was initiated to the application server by digitally signing any parameters associated with the call, such as the caller's number, the number they are calling, and their account ID, and sending this information to the application server as a web request. Id. at col. 4:11-5:46, 13:29-14:14, Figs. 4A-F. The application server then determines the next action that should be taken, and sends this information back to the call router as a response. Id. at col. 6:15-48, Figs. 5A-B. (For example, if a user calls a dial-in voice conferencing number, the conferencing application may determine that the next step would be to play a greeting asking the user to enter his conference Id. See Id. at Fig. 7. In this case, it sends back a response to the call router with an audio file for this greeting and instructions to play it. See id.) The call router receives this response and converts it into a “telephony action.” Id. at col. 6:49-8:5. It does this by sending the appropriate signals over the telephone network to the user's phone. Id. at col. 6:49-64. Any subsequent input from the user is processed as a new request using this same request and response pattern. See, e.g., id. at Figs. 12-15.

         In addition to translating and relaying signals between the communication network and the application server, the call router also stores state information about the telephony session, such as the number associated with a particular call, id. at col. 10:1-4, the number to which a call was directed, id. at col. 10:29-32, or the current state of a call (e.g., in-progress, completed, failed, not yet initiated), id. at col. 10:40-42. It then makes this information accessible to the application server through a Call Router Application Programming Interface (“API”), which the application server can use at any time. Id. at col. 8:52-54; see generally Id. at col. 8:7-12:64. In addition, the application server can use the Call Router API to direct the call router to take certain actions, such as modify information stored by the call router relating to calls or preform operations on an existing call. Id. at col. 9:42-48. For example, the application server can direct the call router to modify data about the number that a call was initiated from, id. at col. 10:1-4, or change the state of a current call (e.g., hanging up a current call, transferring a current call, or initiating recording of a current call), id. at col. 10:42-53.

         This functionality is implemented through “resources” located on the call router, which are web-accessible data elements that each are associated with their own URIs. Id. at col. 9:33-40. Using the Call Router API, the application server can access or modify a resource by performing HTTP actions (e.g., POST, PUT, GET, or DELETE) on its associated URI. Id. For example, information about the number from which a particular call was initiated is associated with the “caller ID resource.” Id. at col. 10:1-4. To request the number from which a particular call was initiated, the application server can send a GET request to the URI of the caller ID resource. See Id. at col. 9:42-46, 10:1-4. The call router then sends a response to the application server with that information. Id. at col. 10:1-4. These resources allow the application server to access information it needs about the telephony session using familiar web-programming constructs. See Id. at col. 8:7-51.

         ii. Asserted Claims

         In its Complaint, Twilio alleges that Telesign infringes at least claim 13 of the '021 patent. Compl. ¶ 135. Claim 13 recites:

         13. A method comprising:

communicating with an application server using an application layer protocol;
processing telephony instructions with a call router;
creating call router resources accessible through a call router Application Programming Interface (API), wherein the call router resources are accessible by outside devices at an addressable Uniform Resource Identifier (URI);
mapping a telephony session to the URI, the URI being associated with the application server;
sending a request to the application server;
embedding state information of the telephony session in the request;
receiving from the application server a response comprising telephony instructions for sequential processing;
receiving an API request from the application server for interaction with a resource; and
responding to an API request based on the interaction with a resource.

'021 patent at col. 19:19-col. 20:2.

         Twilio also alleges that Telesign infringes at least claim 1 of the'465 patent. Compl. ¶ 156. Claim 1 recites:

1. A method for processing a telephony communication comprising:
associating an initial URI with a telephony endpoint;
initiating a telephony voice session for a telephony communication to the telephony endpoint;
mapping the initial URI to the telephony session;
sending an application layer protocol request to an application resource specified by the URI and embedding state information of the telephony voice session in the request;
receiving a response to the application layer protocol request sent to the application resource, wherein the response includes a document of telephony instructions; and
executing telephony actions during the telephony voice session according to a sequential processing of at least a subset of the telephony instructions of the response.

'465 patent at col. 18:37-54.

         Twilio also alleges that Telesign infringes at least claim 1 of the '376 patent. ...


Buy This Entire Record For $7.95

Download the entire decision to receive the complete text, official citation,
docket number, dissents and concurrences, and footnotes for this case.

Learn more about what you receive with purchase of this case.