United States District Court, N.D. California, San Jose Division
ORDER GRANTING IN PART AND DENYING IN PART
DEFENDANT'S MOTION TO DISMISS RE: DKT. NO. 31
H. KOH United States District Judge
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.
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.
The Twilio Patents
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.
The Score Patents
'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.
'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.
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.
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
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.
2 illustrates the operation of the fraud scoring method
within the communication platform:
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
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.
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
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.
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.
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.
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:
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
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
detecting when the fraud scores of an account satisfy a fraud
initiating an action response when a fraud score satisfies
the fraud threshold.
'962 patent at col. 14:4-20.
of the '833 patent recites:
method comprising: at a telecommunication platform:
enrolling a plurality of parent accounts in the
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
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
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.
The Platform Patents
'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,
'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
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.
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.
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.
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:
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.
1 illustrates the operation of the call router, the
application server, and the communication network:
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.
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.
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.
Complaint, Twilio alleges that Telesign infringes at least
claim 13 of the '021 patent. Compl. ¶ 135. Claim 13
communicating with an application server using an application
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
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
'021 patent at col. 19:19-col. 20:2.
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
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.
also alleges that Telesign infringes at least claim 1 of the
'376 patent. ...