U.S. patent application number 13/167569 was filed with the patent office on 2012-08-16 for system and method for monitoring account usage on a platform.
This patent application is currently assigned to Twilio, Inc.. Invention is credited to Evan Mansfield Cooke, Jeffrey G. Lawson, John Wolthuis.
Application Number | 20120208495 13/167569 |
Document ID | / |
Family ID | 46637266 |
Filed Date | 2012-08-16 |
United States Patent
Application |
20120208495 |
Kind Code |
A1 |
Lawson; Jeffrey G. ; et
al. |
August 16, 2012 |
SYSTEM AND METHOD FOR MONITORING ACCOUNT USAGE ON A PLATFORM
Abstract
A system and method for monitoring account usage on a platform
that includes creating an account on a platform; assigning a usage
model of the account; running an application of the account on the
platform; monitoring usage of the application of the account;
identifying a usage event of the usage model in the monitored
usage; and generating an event response based on the usage
event.
Inventors: |
Lawson; Jeffrey G.; (San
Francisco, CA) ; Wolthuis; John; (San Francisco,
CA) ; Cooke; Evan Mansfield; (Cambridge, MA) |
Assignee: |
Twilio, Inc.
San Francisco
CA
|
Family ID: |
46637266 |
Appl. No.: |
13/167569 |
Filed: |
June 23, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61357940 |
Jun 23, 2010 |
|
|
|
Current U.S.
Class: |
455/406 ;
455/405; 709/224 |
Current CPC
Class: |
H04L 12/1446 20130101;
H04M 15/77 20130101; H04M 15/8278 20130101; H04L 12/1403 20130101;
H04W 4/24 20130101 |
Class at
Publication: |
455/406 ;
709/224; 455/405 |
International
Class: |
H04W 24/00 20090101
H04W024/00; H04W 4/26 20090101 H04W004/26; G06F 15/173 20060101
G06F015/173 |
Claims
1. A method for monitoring account usage on a platform comprising:
creating an account on a platform; assigning a usage model to an
application of the account; running the application of the account
on the platform; the platform monitoring usage of the application
of the account; identifying a usage event of the usage model in the
monitored usage; and generating an event response based on the
usage event.
2. The method of claim 1, wherein the platform is a
telecommunications platform.
3. The method of claim 2, wherein identifying the usage event
includes detecting when a usage parameter passes a usage threshold
that is set through the usage model.
4. The method of claim 2, wherein identifying the usage event
includes detecting a pattern of application execution.
5. The method of claim 2, wherein generating a usage event includes
deactivating usage by the account.
6. The method of claim 2, wherein generating a usage event includes
sending a notification to an account holder.
7. The method of claim 2, wherein generating a usage event includes
automatically billing a user account for more usage.
8. The method of claim 2, wherein generating a usage event includes
messaging a URI specified for the usage event.
9. The method of claim 8, wherein the URI specified for the usage
event directs application control to a billing application.
10. The method of claim 8, wherein the URI specified for a usage
event activates a notification application.
11. The method of claim 2 wherein the usage event is dependent on a
time-rate based parameter for sessions with the application.
12. The method of claim 2, wherein the usage event is dependent on
a time span of allowed usage of the application.
13. The method of claim 2, wherein the usage event is dependent on
a data-use based parameter.
14. A method for monitoring account usage on a platform creating a
parent account on a platform; creating a sub-account of the parent
account; assigning a usage model to an application of at least the
sub-account; running the application of the sub-account on the
platform; monitoring usage of the application of the sub-account;
identifying a usage event of the usage model in the monitored
usage; and generating an event response based on the usage
event.
15. The method of claim 14, wherein the platform is a
telecommunications platform.
16. The method of claim 15, wherein the parent account has at least
two sub-accounts and a unique usage model is assigned to each
sub-account.
17. The method of claim 15, further comprising assigning a usage
model to the parent account, and wherein generating an event
response based on the usage event includes activating a billing
process and transferring funds to an entity.
18. The method of claim 17, wherein the transferred funds are
dependent on the difference in the sub-account usage model and the
parent account usage model.
19. A system for monitoring account usage on a platform comprising:
an application platform that runs an application and that includes
an account system including a plurality of account resources with a
usage model, wherein the usage model includes at least one usage
event parameter; and a usage monitoring engine configured for
processing usage of an application of an account; and a platform
application programming interface (API) that interfaces with
account resources and usage models of the application platform.
20. The system of claim 19, wherein the application platform is a
telecommunications platform.
21. The system of claim 20, wherein the application platform
includes a billing engine for processing transactions triggered
through the usage monitoring engine.
22. The system of claim 20, wherein the plurality of account
resources includes a parent account resource that includes a
plurality of sub-account resources, wherein the sub-account
resources have access to an instance of an application of the
parent account resource.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application No. 61/357,940 filed 23 Jun. 2010, titled "SYSTEM AND
METHOD FOR MANAGING TELEPHONY APPLICATION ACCOUNTS", which is
incorporated in its entirety by this reference.
TECHNICAL FIELD
[0002] This invention relates generally to the platform as a
service field, and more specifically to a new and useful method for
monitoring account usage on a platform in the platform as a service
field.
BACKGROUND
[0003] In recent years, numerous new platform-as-a-service product
offerings have appeared. Many of these platforms require creating
an account, and sometimes when another product is leveraging the
platform this account may have subaccounts. Thus, in the use of an
application there may be numerous involved entities such as an
account holder, a sub-account holder, a platform as a service
entity, and a client. Additionally, such ecosystems sometimes
require payment to be exchanged between parties, but the
complicated relationships between the different parties make
carrying out such payments cumbersome and difficult. In some cases,
such complications prevent certain products from being viable. In
particular, telephone and telephony messaging services are becoming
more integrated with web-based applications. Many of these services
are built on telephony application platforms. To build an
application on the telephony application often requires creating an
account with the telephony application platform. Because of the
resources required to operate a telephony application platform,
accounts often have to pay for a usage plan. This complicates the
development and distribution options of application developers when
trying to sell their applications/services built on top of a
telephony application platform. Each customer of a developer
impacts the amount of resources used on the telephony application
platform, and thus impacts which usage plan for the developer is
most appropriate. Not only must an application developer charge a
customer for use of their application but the developer must also
interface with the telephony application platform. Thus, there is a
need in the platform as a service field to create a new and useful
system and method for monitoring an account on a platform. This
invention provides such a new and useful system and method.
BRIEF DESCRIPTION OF THE FIGURES
[0004] FIGS. 1 and 2 are a schematic representations of systems of
preferred embodiments;
[0005] FIG. 3 is a schematic representation of a method of a
preferred embodiment;
[0006] FIG. 4 is a detailed schematic representation of defining a
unique mapping between an application of an account a platform
endpoint of a preferred embodiment;
[0007] FIG. 5 is a detailed schematic representation of assigning a
usage model of a preferred embodiment;
[0008] FIG. 6 is a detailed schematic representation of redirecting
an application in series with the running of an application of a
preferred embodiment;
[0009] FIG. 7 is a detailed schematic representation of redirecting
an application in parallel with the running of an application of a
preferred embodiment;
[0010] FIG. 8 is a detailed schematic representation of accessing
account information of a preferred embodiment;
[0011] FIGS. 9 and 10 are schematic representations of a method of
a preferred embodiment;
[0012] FIG. 11 is an exemplary schematic representation of
redirecting a sub-account of a preferred embodiment; and
[0013] FIG. 12 is a detailed schematic representation of charging
for sub-account usage of a preferred embodiment.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0014] The following description of the preferred embodiments of
the invention is not intended to limit the invention to these
preferred embodiments, but rather to enable any person skilled in
the art to make and use this invention.
1. System for Monitoring an Account on a Platform
[0015] As shown in FIG. 1, a system for monitoring an account on a
platform of the preferred embodiment includes an account system no
with at least one account resource 112 with a usage model 114; an
application platform 120, that includes a usage monitoring engine
122; and a platform application programming interface (API) 130.
The system functions to allow usage triggered processing to occur
for applications of an account. The system enables customized
application behavior specific for an account. The system has
particular application to a computing platform utilized by
application developers that create application instances for users.
Additionally the system may be designed for an account system with
parent accounts that have a plurality of sub-accounts. In this
variation, the system enables a reseller system where developers
can seamlessly distribute telephony applications to customers
(i.e., sub-accounts) while using resources of a computing platform.
The system preferably enables a partitioning of usage, where
account usage (or sub-accounts in some variations) is preferably
tracked and treated independently from other accounts. In one
preferred embodiment, the system is applied to a telephony
application platform. The system can preferably be used to offer a
reseller environment where a company can develop an application on
top of a telephony application platform no and sell that to end
users. The system may alternatively be used for any suitable
application.
[0016] The account system no of the preferred embodiment functions
to manage account resources with application instances run on the
application platform 120. The account system preferably includes a
plurality of accounts 112. An account 112 preferably has an
accessible interface for outside control of functionality within
the application platform 120. Each account preferably has an
associated application and a usage model 114. In some variations
the application may be thought of as an account, For example,
obtaining an application from an application store implicitly
creates a usage model account for that application instance. A
usage model 114 for the account preferably determines the pricing
for use of the application platform 120, but may alternatively be
for any usage-based behavior such as logging. A usage model can
preferably be used to specify usage event parameters. For example,
setting a usage model of 1000 minutes of application session use
for an agreed upon price will preferably set a usage event
parameter of 1000 minutes. The usage event parameter is used to
determine when a usage event is triggered. An instance of an
application is preferably devoted to use by the account or a
sub-account. The instance of the application preferably has a
separate endpoint associated with the application instance of the
account resource 112. If the application has any settings or
configuration, the application instance preferably has customized
settings or configuration. Alternatively, the account system 110
may include parent accounts 116 with a plurality of sub-accounts
118 as shown in FIG. 2. The sub-accounts 118 preferably function
substantially similar to the accounts 112 discussed above except a
parent account may control aspects of the application instance
and/or setting of the usage model 114. A parent account and a
sub-account may both have a usage model 114. The account resource
112 and/or parent accounts 116 and sub-accounts 118 are preferably
created, retrieved, updated, deleted, or manipulated in any
suitable way through the platform API, more preferably a
representational state transfer (REST) API.
[0017] A parent account resource 116 is preferably created when an
application developer signs up for or registers for an account on
the application platform 120. A parent account resource is
preferably a high level account that configures applications for a
plurality of other accounts (i.e., sub-accounts). The parent
account may set the usage model between the application developer
and the application platform operator. When the usage events are
used for billing the difference between the usage model of the
parent account and the sub-account preferably determines the cost
or profits of the parent account entity. While the usage model of
the parent account determines the revenue of the application
platform. A parent account resource 116 is preferably created
through a web interface, but a parent account may alternatively be
created programmatically through the platform API 130. The parent
account resource 116 is preferably a data store of settings for the
parent account. The parent account resource 116 is preferably used
to manage configuration of an application such as the URI of an
application, usage model (e.g., pricing for usage), usage amounts,
billing information, and/or any suitable setting of the parent
account. The usage model for the parent account resource 116 is
preferably determined by the application platform provider. The
parent account resource 116 preferably includes at least one
sub-account resource 118. The sub-account resource 118 is
preferably used by an application developer to configure operation
of a sub-account within the account.
[0018] The sub-account resource 118 of the preferred embodiment
functions as an instance of an application of the parent account.
The sub-account resource 118 is preferably a data store of settings
for the sub-account. A usage model 114 for the parent account 116
preferably determines the pricing for use of the main account
application. In other words, the usage model for the sub-account is
preferably for use by a customer of both the telephony application
platform and the application/service of the account holder. For
example, a company selling a telephony based product such as a
phone tree to route callers to different departments may have an
account on a telephony application platform. The company will
preferably have a plurality of sub-accounts for customers using the
phone tree product. Each sub-account will preferably have
customized settings to determine where to route calls. There may
additionally be numerous applications provided by the account
holder so that sub-accounts may have a completely different
application from another sub-account holder.
[0019] The application platform 120 of the preferred embodiment
functions to provide the application processing functionality for
an application. The application platform is preferably a platform
as a service computing platform. The application is preferably
remotely hosted at a URI, but the application may alternatively be
stored or hosted within the application platform. The application
platform is preferably a telecommunications platform and more
preferably a telephony application platform, but may alternatively
be any suitable platform, such as a media processing platform, an
analytics platform, a storage/processing platform or any suitable
platform. A telecommunications platform may involve application use
of voice, video, or messaging communication. The telephony
application platform 110 of the preferred embodiment functions to
provide core functionality of a telephony application. A telephony
application preferably incorporates interaction between a web
application and a telephone network. A telephony application
platform no may additionally or alternatively support application
integration with a telephony messaging network such as short
message short message service (SMS) or multimedia messaging service
(MMS), fax, email, video, and/or any suitable network. The
telephony application platform preferably includes the hardware
such as a call router and/or software stacks required to operate a
telephony application. The telephony application platform 110 is
preferably substantially similar to the platform described in U.S.
patent application Ser. No. 12/417,630, filed on 2 Apr. 2009 and
entitled "System and Method for Processing Telephony Sessions",
which is incorporated in its entirety by this reference, but may
alternatively be any suitable telephony platform.
[0020] The application platform 120 preferably includes a usage
monitoring engine 122, which functions to monitor and detect usage
events of a usage model. The usage monitoring engine preferably
runs in the background on the application platform 120 during
normal operation. The usage events are preferably time based, but
may alternatively be a pattern of execution in an application or
any suitable detectable event of an application. A usage event
dependent on time based parameters may depend on a time rate
parameter (e.g., $0.10/min). In the example where there is a per
minute charge, if funds are reached or a particular total amount is
reached then a usage event occurs. A usage event dependent on time
base parameters may alternatively depend on a time span of allowed
usage. For example, a usage may be allowed for a month. When the
end of that time span is reached or approaches neat, a usage event
may occur. A usage event that is dependent on data-use parameter is
another alternative. Data-use is preferably a count related to the
application. Data-use may include the amount of data transferred,
the number of messages sent, the number of sessions, or any
suitable data related parameter. The usage monitoring engine 122
preferably detects a usage event and then triggers a change in the
application platform (i.e., redirects) to communicate with a
routine to handle the event. The application platform 120 may
additionally include a billing engine that manages billing and
calculation of appropriate transactions to occur between account
holders and the application platform operators. In particular, the
billing engine calculates the appropriate transactions with a
parent account holder which includes the sum total of usage of all
sub-accounts based on the usage model of the parent account offset
by sum total of usage of all sub-accounts based on the usage model
of the individual sub-accounts.
[0021] The platform application programming interface (API) 130 of
the preferred embodiment functions to provide a programmatic way to
interface with a account resource 112 of the account system no. The
platform API can preferably create, read, update, delete or perform
any suitable manipulation to parameters of an account resource 112.
The platform API can preferably allocate new sub-account resources
118, setup an instance of an application for a sub-account, assign
a phone number or allocate a new phone number for an account or
sub-account, retrieve usage of an account, set a usage
model/pricing of an account, parent account and/or sub-account,
perform any suitable interaction with resources of the telephony
application platform. The platform API 120 is preferably a REST API
but any suitable API may alternatively be used such as a simple
object access protocol (SOAP). An account holder can preferably
programmatically interface with the account resource 112 through
the platform API. The resources are preferably accessible with the
API through an outside channel, but may alternatively be an
internal programming interface for applications running within the
platform. Similarly a parent account holder can preferably
interface with the parent account resource 116 and sub-account
resources 118 through the platform API. This preferably allows for
more integration between an application of an account holder and
the application platform 120, rather than requiring an account
holder to manually create accounts through a web interface or have
the application of the account reside within the application
platform 120, though those options may alternatively be available.
For example, an application of a parent account holder may have a
new customer signup for a phone tree product. The customer may
signup through an outside website operated by the parent account
holder. The website of the account holder preferably initiates a
REST API request to access the parent account resource 116 of the
parent account holder and add a sub-account resource 118 for the
new customer. A new phone number may be dynamically assigned for
the sub-account resource, and the website of the parent account
holder can preferably request the new phone number using the REST
API, and then inform the customer of the new phone number. The
customer preferably never has to be bothered with interfacing with
the telephony application platform 110.
2. Method for Monitoring an Account on a Platform
[0022] As shown in FIG. 3, a method S100 for monitoring an account
on a platform of a preferred embodiment includes creating an
account on a telephony application platform S110, assigning a usage
model to the account S120, running an application of the account on
the platform S136, monitoring usage of the application of the
account S140; identifying a usage event of the usage model in the
monitored usage S150; and generating an event response based on an
event of the usage model S160. The method functions to enable
performing account specific tasks based on usage by the account. In
one embodiment, the method is applied to enable accounts to have
billing tasks performed. The method may additionally function to
enable developers of applications to customize behavior of an
application on a platform and may further customize the monitoring
and behavior based on the account holder of an application. In one
example, a developer of an application may set up the redirection
of an application to trigger billing of the account holder. In
another example, a developer of an application may set up the
redirection of an application to send a notification to an account
holder which may be used for billing reminders, usage warnings,
usage logging, or any suitable application. The method is
preferably implemented for a telephony platform. The telephony
platform preferably enables telephony with integration to voice
communication, a telephony messaging service (e.g., SMS or MMS),
fax, email, or any suitable network. The method may alternatively
be applied to any suitable computing platform. As an additional
alternative, the method may be configured to function with parent
accounts and sub-accounts as described below in method S200.
[0023] Step S110, which includes creating an account on a telephony
application platform, functions to create an instance of an
application for use by an account holder. As shown in FIG. 4, an
account preferably defines a unique mapping between an application
of the account and a platform endpoint. The platform endpoint is
preferably any suitable addressable location. The platform endpoint
is preferably a unique endpoint. In one embodiment with a telephony
platform, the platform endpoint is a phone number, but may
alternatively be a SMS short code, fax number, email, or any
suitable telephony address. In one variation, the phone number may
be a shared base phone number with an extension. When creating an
account, a platform endpoint is preferably assigned to the
application of the account. Additionally, step S120 may include
allocating a new platform endpoint for use by the account. A pool
of unused platform endpoints (e.g., phone numbers) is preferably
maintained by the computing platform so that a platform endpoint
can be allocated to an account instantly. In one embodiment
described in the method S200 below, the account may be configured
as a sub-account of a parent account. In this variation, there may
be several instances of an application belonging to various
accounts, and all these application instances and accounts are
created and/or maintained by a parent account. Additionally,
application settings of an account are preferably created when
creating an account. The application settings may be settings with
the computing platform or alternatively settings residing on an
application of a parent account. An account is preferably created
through the platform API, and more preferably a REST API. The
account may alternatively be created in any suitable fashion such
as a web-interface. Creating an account through an API may function
to allow parent accounts (e.g., customers) to dynamically manage
sub-accounts. An account may alternatively be automatically created
upon delivering an application to a client. For example, an account
(or application associated record) may be created when a client
downloads or purchases an application. The application may
facilitate the completion of account parameters such as by
requiring platform account information or providing a form to
acquire the required parameters.
[0024] Step S120, which includes assigning a usage model to the
account, functions to determine the usage model for an account. The
usage model can preferably be based on call session time, number of
telephony messages, data access, usage periods (e.g., unlimited for
a month), rate limits (e.g., maximum number of simultaneous calls
or number of calls per day), or any suitable parameter. A usage
model may be fixed for an application (e.g., set by a developer),
and a user preferably accepts or rejects the fixed usage model.
Actions can preferably be assigned for usage events. Preferably, an
action is set by specifying a URI for a redirecting event response.
The platform will preferably fetch or message the specified URI
when an event occurs. Application logic is preferably included in
the resource at the specified URI to perform the suitable action.
Alternatively, an application process is specified that can be
called when an event occurs. As another variation, various
platform-provided actions may be offered to perform a particular
type of action. Usage events are preferably stages of usage of an
account preferably before a threshold, at a threshold, or after a
threshold. Exemplary usage events preferably include passing a
usage limit, approaching a new billing period, or any suitable
threshold related to usage. For example, an email notification
action may be set to be sent to the account holder five days before
a new billing period. The usage model and/or usage events can
preferably be manipulated or set through the API, as shown in FIG.
5, but may alternatively be created through a web-interface or
through any suitable interface.
[0025] Step S130, which includes running an application of the
account on the platform, functions to operate the application
through the computing platform. Running an application preferably
includes communication between an application resource and a system
of the platform. Instructions and information are preferably passed
back and forth between the application and the computing platform.
The application is preferably a remotely hosted resource such as on
an application server of a developer. The application preferably
resides at a URI to which the platform addresses communications.
The application logic may alternatively be stored within the
application. An application preferably runs on the platform when
the platform is initiated to communicate with the application by an
incoming communication addressed to the endpoint assigned to the
application. Alternatively, the application server may initiate
communication with the computing platform. In a preferred
embodiment the computing platform is preferably a telephony
platform. Phone calls, SMS messages, MMS messages, faxes or any
suitable communication is received by the telephony platform; the
telephony platform retrieves instructions from an application based
on the endpoint (e.g., phone number) of the received communication;
and then the instructions are run on the telephony platform to
interact with the entity that send the original communication.
[0026] Step S140 and Step S150, which include monitoring usage of
the application of the account and identifying a usage event of the
usage model in the monitored usage; functions to track at least one
parameter necessary to assess the usage model and determine when
events relevant to the usage model occur. The monitoring is
preferably performed by the platform on behalf of the application.
this preferably centralizes the usage event management, alleviating
developers of this task. The monitoring of usage keeps track of at
least the parameters relating to the usage model. Additional
parameters may additionally be tracked. The usage is preferably
stored in a log, as attributes of the account, or any suitable
manner. The monitoring of usage is preferably a count of usage. For
example, the amount of time, number of occurrences (e.g., of using
a resource or other actions), amount of data sent, amount of data
received, number of API calls, and/or any suitable parameter may be
tracked. Additionally or alternatively, the occurrences of isolated
events may be monitored. The pattern of operations of an
application may be monitored to detect a pattern or a number of
various patterns. For example when a particular series of
instructions happen and match a specified pattern, a usage event is
preferably identified and the application redirected. The
monitoring of an application is preferably performed by the
computing platform but may alternatively be performed by any
suitable system. The usage model preferably determines particular
thresholds and/or patterns corresponding to a usage event and that
require a redirection of the application. These threshold and/or
patterns that correspond to a usage event may be explicitly set in
the usage model or may be based on information provided in the
usage model. The usage event corresponds to how to redirect an
application. While monitoring the usage of the application, the
current usage is preferably compared to these thresholds and/or
patterns.
[0027] Step S160, which includes generating an event response based
on an event of the usage model, functions to perform an action as a
result of usage of an application. The generation of an event may
be any suitable action. In one preferred variation, the event
response is preferably redirecting the application. In a second
variation, the event response is preferably ceasing or shutting off
usage of the application. This preferably prevents usage of the
platform by the application until further actions are taken. This
may be accomplished through changing a policy engine, authorization
settings, or through any suitable technique. In another variation,
the event response is preferably recharging of an account. This may
include automatically billing an account, deducting from credit of
an account, or through any suitable way. In yet another variation,
the event response is preferably the sending of a notification. The
notification is preferably sent to the account holder/application
owner. The generating of an event response is preferably initiated
by a usage event, such as passing a threshold based on the usage
model, but may alternatively be triggered through pattern detection
or through any suitable form of triggering. A usage event and
associated actions are preferably set when assigning a usage model
but may alternatively be set by default. There may a plurality of
possible usage events, and each one preferably is associated with
specified way to generating an event response. In the variation
where an application each event response preferably has a unique
redirection URI leading to an application. The application is
preferably redirected to a URI. The computing platform preferably
operates by communicating with the application at a specified URI,
and redirecting to a URI gives an application at that URI the
ability to run and/or interact with the computing platform The URI
is preferably defined by a developer of the application, a parent
account holder, the computing platform, or any suitable entity. A
default URI may alternatively be used. The URI preferably includes
a script or program to perform the desired action of the account
holder or parent-account holder as shown in FIG. 6. In one example,
when an account nears a usage limit, a HTTP POST to a URI
preferably initiates sending a billing reminder to the account
holder. In other variations, the event response is performed from
an internal module without any redirection to an external URI. The
redirection may be performed serially or in parallel with operation
of the application. A serial operation preferably interrupts call
flow by the application (i.e., takes control of the application
instance) and performs some action as shown in FIG. 6. The regular
application may regain application control at the end of the
action, or the application may terminate. For example, a serial
operation may interrupt a phone call after the usage limit is
passed; an audio message is played that informs the listener of
surpassed usage; and then call ends. A parallel operation
preferably performs some action concurrently during regular
application control flow as shown in FIG. 7. A parallel operation
preferably performs in the background. For example, a parallel
operation may send a message to a server that sends a notification
email to the sub-account holder.
[0028] As shown in FIG. 8, the method may additionally include
accessing account information S170, which functions to enable
programmatically interacting with account and sub-account
resources. Accessing account information is preferably
programmatically performed through the platform API to monitor,
retrieve, and/or set account and sub-account details. Overall usage
information of an account can preferably be retrieved. Preferably
any settings of the account are preferably controllable through the
platform API. For example, a usage model can preferably be
assigned. The platform API is preferably substantially similar to
the platform API described above, and is preferably a REST API.
3. Method for Monitoring Sub-Accounts on a Platform
[0029] As shown in FIGS. 9 and 10, a method S200 of a preferred
embodiment preferably includes the steps creating a parent account
on an application platform S205, creating a sub-account of the
parent account S210, assigning a usage model to the sub-account
S220, running an application of the sub-account on the platform
S230, monitoring usage of the application of the sub-account S240;
identifying a usage event of the usage model in the monitored usage
S250; and generating an event response based on an event of the
usage model S260. The method functions to enable an application to
be developed by an account holder and instantiated in various
sub-accounts. The method further functions to alleviate parent
account holders from managing usage of sub-accounts on the
telephony application platform. The method can preferably be
adjusted to initiate any suitable action when redirecting. In one
preferred variation, the method functions to simplify the billing
of telephony application users or create billing notifications. The
method is preferably used to implement a reselling environment for
a telephony application platform, but may be used for any suitable
alternative application. An instance of an application of the
parent account is preferably used by the sub-account. Additionally,
the parent account may have several applications from which a
sub-account may select one or more. The method S200 is preferably
substantially similar to method S100 except as noted below. In
particular, Steps S210, S220, S230, S240, S250, and S260 are
sustainably similar to Steps S110, S120, S130, S140, S150, and
S160. The sub-accounts of S200 are preferably substantially similar
to the accounts of S100. For example, as shown in FIG. 11, a
sub-account may be redirected for billing of telephony application
users, creating billing notifications, and/or performing any
suitable usage based action. Sub-accounts preferably have a
parent-account, which may be used to set some of the parameters,
and may have control over the instance of the application used by
the sub-account holder. Any suitable combination of additional
steps or variations of S100 and S200 may be used.
[0030] Step S205, which includes creating a parent account on a
telephony application platform, functions to define a main account
used by a developer for managing an application and customers using
the application. The parent account is preferably created by an
entity that will manage the applications and sub-accounts. The
parent account preferably defines the application(s) settings for
sub-accounts. Creating a parent account preferably includes
assigning a usage model for the parent account. The usage model of
the parent account is preferably the rate at which the computing
platform (e.g., a telephony application platform) earns revenue as
described below. The usage model may be based on any suitable
parameters of use such as call session time, number of telephony
messages, data access, usage periods (e.g., unlimited for a month),
rate limits (e.g., maximum number of simultaneous calls or number
of calls per day), or any suitable parameter. Additionally, the
parent account usage model can have partitions of rates for
different sub-accounts. For example, one type of sub-account may
have lower use (e.g., low volume of calls) so a different usage
model is preferably used, while a second type of sub-account uses
lots of resources (e.g., a high volume of calls) so a different
usage model is preferably used for this type of sub-account. Any
suitable revenue model may alternatively be used. The usage of the
parent account and any sub-accounts is preferably counted as usage
by the parent account. The parent account is preferably created
through a web interface, but may alternatively be created through a
platform API substantially similar to the platform API described
for the system above. The account preferably defines authentication
parameters for which a parent account holder can programmatically
interface with the telephony application platform, such as when
creating sub-accounts or configuring an application.
[0031] In Step S220, which includes assigning a usage model to the
sub-account S220, functions to assign a specific usage model to a
sub-account of a parent account. The parent account may have a
plurality of sub-accounts, and each sub-account may have a unique
usage model. The parent account can set a usage model for a
sub-account. In one variation, a sub-account holder determines
parameters of the usage model through a configuration application
of the parent account holder. The configuration application
preferably communicates the usage model parameters to the computing
platform through an API to assign a usage model to the sub-account.
Alternatively, a sub-account holder may set the usage model
directly through any suitable means such as a user interface. A
usage model of a sub-account preferably accounts for the use of
application/service of the account holder and of the telephony
application platform. The usage model of the account is preferably
different from the account, but may be a substantially similar
usage model as the account. Typically, the usage model of a
sub-account has a higher price rate for the combined use of the
telephony application platform and the application/service of the
account holder. The usage model may alternatively cover just the
usage cost of the telephony application platform or even subsidize
the use of the telephony application platform, such as if the
account generates revenue through different means.
[0032] S200 may additionally include accessing account information
S270, which functions to enable programmatically interacting with
parent account and sub-account resources. This is preferably
substantially similar to Step S170 described above. Accessing
account information is preferably programmatically performed
through the platform API to monitor, retrieve, and/or set account
and sub-account details. Overall usage information of a parent
account can preferably be retrieved. Information for sub-accounts
may alternatively be retrieved. Preferably any settings of the
parent account or sub-account are preferably controllable through
the platform API. The platform API is preferably substantially
similar to the platform API described above, and is preferably a
REST API.
[0033] As shown in FIG. 12, the method may additionally include
charging for sub-account usage S280, which functions to reduce
billing complexity of an application platform. Step S280
additionally functions to create a centralized and automated
billing process so that holders of accounts preferably do not
manage bill collection from sub-account holders and paying
computing platform operators for usage of the parent account. The
computing platform preferably automates the billing process and
usage tracking such that the account holder and sub-account holders
are endpoints of transaction, and the telephony application
platform preferably acts as a middle man. Step S280 preferably
includes setting a telephony application platform usage model for
an account holder, charging sub-accounts for usage plans S282, and
completing a transaction with the parent account by factoring
sub-account usage rates and parent account usage rates S284. The
setting of a computing platform usage model for a parent account
holder is preferably performed in Step S205, but may be performed
at any suitable time. The computing platform preferably collects
funds from sub-account holders. The computing platform may
alternatively interface with an account holder system for charging
the sub-accounts. Interfacing with an account holder system
preferably enables a customer (i.e., sub-account holder) to
interface only with the parent account holder. An oauth system or
any suitable authentication service is preferably used to automate
charging a sub-account through an outside application such as one
managed by the parent account manager. This preferably functions to
create the appearance of a parent account holder managing billing
of a sub-account holder, but the telephony application platform
preferably manages the calculations. When completing a transaction
with a parent account holder, there may be a number of different
situations depending on the usage model of the parent account and
the sub-account. In one situation where a sub-account usage model
has a higher price rate than the usage model of the parent account
holder, an appropriate portion of money collected from the
sub-account holders is preferably transferred to the account
holder. The telephony app platform preferably withholds a portion
of revenue for providing the telephony app platform, which is
preferably determined by the parent account usage model. In another
situation where the parent account holder sets the usage model of
the sub-accounts at a lower price rate (or even free use of the
telephone application/service), the parent account holder is
preferably charged for the resource use of all sub-accounts
according to the usage model of the parent account holder. This
variation may occur if the application/service provided by the
account holder made revenue in some other fashion such as through
ad revenue.
[0034] An alternative embodiment preferably implements the above
methods in a computer-readable medium storing computer-readable
instructions. The instructions are preferably executed by
computer-executable components preferably integrated with a
computing platform. The computer-readable medium may be stored on
any suitable computer readable media such as RAMs, ROMs, flash
memory, EEPROMs, optical devices (CD or DVD), hard drives, floppy
drives, or any suitable device. The computer-executable component
is preferably a processor but the instructions may alternatively or
additionally be executed by any suitable dedicated hardware
device.
[0035] As a person skilled in the art will recognize from the
previous detailed description and from the figures and claims,
modifications and changes can be made to the preferred embodiments
of the invention without departing from the scope of this invention
defined in the following claims.
* * * * *