MXPA06008318A - Application-based value billing in a wireless subscriber network - Google Patents

Abstract

Systems and methods for application-based billing in a wireless subscriber billing system are disclosed. A wireless client device can generate and transmit a billing request to the billing system. The billing system generates a validation response to the billing request and transmits the validation response to the client device. The validation response can be processed by the client device to enable a service linked to the billing request.

Description

BILLING VALUE BASED ON APPLICATION IN A WIRELESS SUBSCRIBER NETWORK FIELD OF THE INVENTION The present invention generally relates to communications between remote computing devices and servers. More particularly, the invention relates to the creation and sending of billing events between a server and a remote client device.

BACKGROUND OF THE INVENTION Technological advances have resulted in more powerful and smaller personal computing devices. For example, there is currently a variety of portable personal computing devices, including wireless computing devices, such as portable cordless phones, personal digital assistants (PDAs) and tracking devices that are small, lightweight, and can be easily carried. by the users. More specifically, portable wireless telephones, for example, also include cell phones that communicate data and voice packets over wireless networks. In addition, many of those cell phones are being manufactured with relatively large increases in computing capabilities, and as such, they are becoming the equivalent of small personal computers and PDA manuals. However, these more powerful and smaller personal computing devices usually have severe resource constraints. For example, the size of the screen, the amount of available memory, and the file system space, the number of input and output capacities and the processing capacity can be limited by the small size of the device, and in particular , the small size of the user input unit, for example, the keyboard. Due to such severe resource constraints, it is often desirable, for example, to maintain a limited size and quantity of software applications and other information hosted on such remote personal computing devices (client devices). Some personal computing devices use application programming interfaces (APIs), sometimes referred to as runtime environments and software platforms, which are installed on your local computing platform and used, for example, to simplify operations of such devices, such as, providing generalized calls for device-specific resources. In addition, some of these APIs are also known because they provide software developers the ability to create software applications that are fully executable on those devices. In addition, some of those APIs are known to be operatively located between the computer system system software and the software applications so that the computing device computing functionality is available to the software applications without requiring the software developer have the source code of the specific computing device system. In addition, it is known that some APIs provide mechanisms to secure communications between said personal devices (ie, clients) and remote devices (ie, servers) using secure cryptographic information. Examples of such APIs, some of which are discussed in more detail below, include versions of the Binary Runtime Environment for Wireless® (BREW®) developed by QUALCOMM, Inc., of San Diego, California. BREW® can cooperate with the operating system of a computing device (e.g., a wireless cellular telephone) and can, among other functions, provide interfaces to hardware functions particularly found in personal computing devices. BREW® can also provide these interfaces in such personal computing devices at a relatively low cost with respect to demands on device resources and with respect to the price paid by consumers per device containing the BREW® API. Additional features of BREW® include its end-to-end software distribution platform that provides a variety of benefits for wireless service operators, software developers and consumers of computing devices. At least one currently available end-to-end software distribution platform of that type includes distributed logic in a server-client architecture, where the server performs, for example, billing, security and application distribution functionality. , and the client performs, for example, application execution, security and user interface functionality. Improved computing capabilities and security features on client devices have enabled applications that can be purchased directly from a carrier network and downloaded and installed on a client device. Once an application is purchased, a remote billing system can automatically generate billing to a subscriber / account associated with the customer's device and can distribute the appropriate payment to developers / advertisers. However, current wireless client-server systems provide limited purchase options. In general, a one-time purchase or a fixed number of uses can be made for a desired application or content. This results in limited flexibility for developers and content providers to pack or increase the sales of their applications. The above description of the related art merely aims to provide an overview of some of the known uses of API and as an introduction to the BREW® platform, which can be used in embodiments of the invention. However, the invention will not be construed as limited to a specific execution, platform or operating environment.

SUMMARY OF THE INVENTION Exemplary embodiments of the present invention are directed to systems and methods for generating and processing billing requests generated by the client's device in a wireless network. Accordingly, one embodiment of the invention may include a method for application-based billing in a wireless subscriber billing system, the method comprising: generating a billing request within a client device; transmit the information request including a subscriber identification (SID) to the billing system; generate a validation response to the billing request in the billing system; and transmit the validation response to the client's device. Another embodiment of the invention may include an apparatus comprising: a wireless client device, including an application configured to generate and transmit a billing request and configured to receive a validation response; a billing server configured to receive the billing request and transmit the validation response; and validation logic configured to generate the validation response in response to the billing request. Another embodiment of the invention may include a client device comprising: a transceiver with the ability to transmit and receive data wirelessly; a user interface; and an application configured to generate a billing request; transmit the billing request to a billing system using the transceiver; and receive a validation response associated with the billing request from the billing system. Another embodiment of the invention may include a billing system comprising: a transceiver with the ability to transmit and receive data wirelessly; a billing server operatively coupled to the transceiver, wherein the billing server is configured to receive a billing request including a subscriber ID (SID) from a client device and to transmit a validation response to the client's device; and validation logic configured to generate the validation response in response to the billing request. Another embodiment of the invention may include a computer-readable medium in which a computer program is stored to wirelessly communicate application-based billing requests, the computer program comprises instructions which, when executed at least by a computing device in a device of the wireless client, cause the computing device to execute the process of: generating a billing request in the wireless client's device; transmit the billing request to a billing system; and receive a validation response associated with the billing request from the billing system.

Another embodiment of the invention may include a billing system, comprising: means for generating a billing request within a client device; means for transmitting the billing request including a subscriber identification (SID) to a billing server; means for generating a validation response to the billing request in the billing server; and means for transmitting the validation response to the client's device.

BRIEF DESCRIPTION OF THE FIGURES A more complete appreciation of the embodiments of the invention and many of the advantages associated therewith will readily be realized as it is better understood by reference to the following detailed description, when considered in connection with the accompanying figures which are shown only for illustration and not as a limitation of the invention, and wherein: Figure 1 is a diagram of a wireless network architecture that supports client devices and servers according to, at least, one embodiment of the invention; Figure 2 is a more detailed diagram of a wireless network architecture that supports client devices and servers according to at least one embodiment of the invention; Figure 3 is an illustration of the system level of an application-based value billing system according to at least one embodiment of the invention; Figure 4 is an illustration of an application-based value billing process from the perspective of a developer according to at least one embodiment of the invention; Figure 5 is an illustration of the level of the system for adding application-based value billing applications to an operator catalog according to, at least, one embodiment of the invention; Figure 6A is an illustration of an application-based value billing process according to at least one embodiment of the invention; Figure 6B is a validation logic illustration according to at least one embodiment of the invention; and Figures 7A and 7B are illustrations of the processing of a validation response on a client device according to at least one embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED MODALITIES Aspeof the invention are shown in the following description and related figures focused on specific embodiments of the invention. Alternative embodiments may be contemplated without departing from the scope of the invention. Additionally, well-known elements of the invention will not be described in detail or will be omitted so as not to obscure the relevant details of the invention. The word "exemplary" is used in the present invention to mean "that it serves as an example, case or illustration". Any modality described here as "exemplary" will not necessarily be interpreted as preferred or advantageous over other modalities. Similarly, the term "embodiments of the invention" does not require that all embodiments of the invention include the characteristic, advantage or mode of operation analyzed. In addition, many modalities are analyzed in terms of sequences of actions that are to be executed, for example, by elements of a computing device. It will be recognized that various actions described herein can be executed by specific circuits (for example, application-specific integrated circuits (ASICs)), through program instructions executed by one or more processors, or by a combination of both.

Additionally, these sequences of actions described herein may be fully considered or incorporated into any form of computer-readable storage medium having a corresponding set of computation instructions stored therein which, at the time of execution, will cause a processor to associate perform the functionality described here. Therefore, the various aspeof the invention can be incorporated in a number of different ways, all contemplated within the scope of subject matter claimed. Furthermore, for each of the modalities described herein, the corresponding form of any of these modalities can be described here as, for example, "logic configured to" perform the described action. One or more embodiments of the invention can be used in conjunction with a runtime environment (for example API) that is executed in the computing device. A runtime environment like that (API) is the Binary Runtime Environment for Wireless® software (BREW®) previously analyzed. However, one or more embodiments of the invention can be used with other types of runtime environments (APIs) that, for example, operate to control the execution of applications in wireless client computing devices. Additionally, "API" is intended to be widely interpreted as an autonomous program or portion of a program that is used to achieve a particular function and that can be used interchangeably with the terms "application", "program", "routine", " instructions "and" applet program ". Figure 1 illustrates a block diagram of an exemplary embodiment of a wireless system 100 according to at least one embodiment of the invention. The system 100 may contain client devices, such as the cellular phone 102, in communication over a wireless network 104 with at least one billing server 106 that receives billing events from the wireless devices through a wireless portal. wireless communication or other data access for the wireless network 104. As shown here, the wireless device (client) can be a cell phone 102, a personal digital assistant 108, a locator 110, which is shown here as a pager two-way text, or even a separate computing platform 112 that has a wireless communication portal. Therefore, embodiments of the invention can be executed in any form of client device including a wireless communication portal or having wireless communication capabilities, including without limitation, wireless modems, PCMCIA cards, personal computers, access terminals, telephones or any combination or sub-combination thereof. The billing server (BDS) 106 is shown here on a network 116 with other computing elements in communication with the wireless network 104. There may be additional stand-alone servers (e.g., stand-alone server 122), and each server may provide services and separate processes to client devices 102, 108, 110, 112 through wireless network 104. Preferably, there is also at least one stored transaction database 118 that maintains records of transactions related to billing of wireless devices 102, 108, 110, 112. However, those skilled in the art will appreciate that, the configuration illustrated in Figure 1 is merely exemplary. Accordingly, embodiments of the invention may include one or more servers that can each perform all of the functions described and contain all the necessary hardware and software, or may contain only the desired functionality. Figure 2 shows a block diagram that more fully illustrates the system 100, including the components of the wireless network 104 and the interrelation of the elements of the exemplary embodiments of the invention. System 100 is merely exemplary and may include any system that allows remote client devices, such as wireless client computing devices 300, 102, 108, 110, 112 to engage in on-air communication between them and / or between components connected through a wireless network 104, including, without limitation, wireless network carriers and / or servers. The billing server 106 and the stored transaction database 118, together with any other servers such as the application download server 130, which are used to provide cellular telecommunication services, establish communication with a carrier network 200, through a data link, such as the Internet, a secure LAN, WAN or other network. In the embodiment shown, a single server 120 may include the application download server 130, the billing server 106 and the stored transaction database 118. Additionally, the server 120 may be coupled directly to the carrier network or it can be included in it. However, these servers can also be independent devices. The carrier network 200 controls the messages (typically sent as data packets) sent to a message sending service controller ("MSC") 202.

The carrier network 200 establishes communication with the MSC 202 through a network, the Internet and / or a public switched telephone network (PSTN). Usually, network or Internet connection between the carrier network 200 and the MSC 202 transfers data, and the PSTN transfers voice information. The MSC 202 can be connected to multiple base stations ("BTS") 204. In a manner similar to the network carrier, the MSC 202 is typically connected to the BTS 204 via a network, the Internet and / or PSTN for transfer of data and / or voice information. The BTS 204 can transmit data messages wirelessly to the client devices, such as the client device 102, by short message delivery service ("SMS") and other known on-the-air (OTA) methods in The technique. The client device 300, e.g., a cellular telephone, has a computing platform 206 that can receive and execute software applications and transmit billing requests from an application to the billing server 106. Additionally, the client 300 device can engage communication with the application download server 130. The computing platform 206 may include a specific application integrated circuit ("ASIC" 208), or another processor, microprocessor, logic circuit, or other data processing device. The ASIC 208 or another processor executes the application programming interface ("API") layer 210 which interfaces with any programs resident in the memory 212 of the wireless device. The memory 212 may be composed of read-only memory or random access memory (RAM or ROM), EEPROM, instant memory cards, or any common memory for computing platforms. The API 210 (e.g., BREW®) also has operating therein an application-based value (AVB) billing application 310 that contains logic configured to process special billing requests from the client device to the billing server 106 , through the carrier network 200. The computing platform 206 may also include a local database 214 that can maintain applications not actively used in the memory 212. The local database 214 is typically a memory cell. instantaneous, but can be any secondary storage device as is known in the art, such as magnetic media, EEPROM, optical media, tape, flexible or hard disk, or the like. The device of the wireless client 300, such as a cellular phone, has installed on it, or otherwise downloads, one or more software applications, such as games, news, securities monitors, and the like. For example, the client device 300 may receive one or more software applications downloaded from the application download server 130. The software applications may be stored in the local database 214 when they are not in use. The client device 300 or other wireless computing device may load resident applications stored in local database 214 to memory 212 for execution in API 210 when the user so desires or when so required by another API. Thus, in one embodiment, an AVB 310 application can be loaded into the client device 300 for execution of the application and generation of billing requests for the billing server 106. As used in the present invention, the terms "client device", "wireless device", "wireless computing device", "client computing device" and variations thereof can be exchanged and each includes, for example, one or more processing circuits that execute logic resident configured, wherein said computing devices include, for example, microprocessors, digital signal processors (DSP), microcontrollers, portable wireless telephones, personal digital assistants (PDA), and location devices, or any convenient combination of hardware, software and / or wired microprogramming that contains processors and logic configured at least to perform the operations described herein focused on the billing information communicated between a client device 300 and a billing server 106. The client device 300 can be serviced by at least one remote billing server 106 with respect to the processing of billing requests generated in the device of client 300. Some examples of client devices that may be used, in accordance with embodiments of the present invention, include cellular phones or other wireless communication units, PDAs, location devices, manual navigation devices, handheld game devices , units for downloading music or video content, and other similar wireless communication devices. The wireless communication between the client device 300 and the BTS 204 can be based on different technologies, such as code division multiplex access (CDMA), time division multiplexed access (TDMA), access multiplexed by frequency division (FDMA), the global system for mobile communications (GSM), or other protocols that can be used in a wireless communications network or a data communications network. The data communication is usually between the client device 300, the BTS 204, and the MSC 202. The MSC 202 can be connected to multiple data networks such as the carrier network 200, the PSTN, the Internet, a virtual private network, and the like, thus allowing the client's device access to a wider communication network. As discussed in the aforementioned, in addition to voice transmission, data can be transmitted to the customer's device through SMS or other OTA methods known in the art. The developers have made great efforts to create consumer affinity for their applications and brands. Many developers believe that customers would be willing to increase their purchases beyond an initial purchase of an application, providing more value to consumers and creating new revenue opportunities for developers, advertisers and wireless operators. For example, developers can generate applications that include additional features (for example, improved weapons or additional levels in a game) that can be enabled through a separate purchase purchase of the initial application. Therefore, a developer can derive an increased revenue from these purchases based on the application. In addition, some applications, such as ring managers, actually use content (for example, the timbres themselves, which may be music by recording artists and the like). This content can also be purchased and delivered to the customer's device and can be installed on the customer's device in separate transactions. Billing and enabling the requested service (for example, adding a weapon or delivering content) can be separate events. To facilitate an understanding of the description, definitions of some terms are provided. Generally, an application is a software program that executes actions based on the direction and interaction of the consumer. Therefore, an application potentially behaves differently each time it is used. A manipulator is an application that supports the delivery of content. It is usually previously installed on a device and can support one or more types of content. Typically, a manipulator does not interact with the consumer but works behind the scenes to launch the content. However, some manipulators support simple interaction with a consumer, such as, "Do you want to install this ringer as the default ringer?".

The content (or statistical content) is usually a software file that is displayed to the consumer through an application, interpreter or manipulator. The content file usually does not contain executable / conditional software logic. Typical content types include images, videos, pages to navigate, ringtones and text files. An application-based value billing request (AVB) is a billing request that is generated in an application on a client device. The AVB request can also be referred to as a value billing request or simply a billing request. Similarly, the billing event generated from the AVB request can be referred to as an AVB event, a value billing event, or simply a billing event. The above definitions are basic and should not be considered as all-inclusive. For example, an application can perform actions based on specific parameters and device configurations in addition to the consumer / subscriber interaction. Accordingly, other aspects of the terms fall within the intended scope of the definitions and the invention, as will be appreciated by those skilled in the art.

Referring to Figure 3, application-based value billing (AVB) can be considered the ability of an application 320 (e.g., a BREW® application) on a device of client 300 to deliver an event that can be billed (eg example, through an AVB extension 315) to a billing server (BDS) 106 for billing processing. The application 320 and the related AVB extension 315 can be considered an AVB 310 application that includes the ability to generate and process billing events on the client device 300. These value billing events can be propagated through the BDS 106 to the module billing 350 (for example, a system for generating invoices from the operator's subscriber) and a 360 payment module (for example, BREW® billing services), which supports consumer billing, developer payment, distribution of the operator's income, and the distribution of income for payments. The AVB services do not usually require the distribution of content to the customer's device 300 or the enabling of services related to the billing of value on the customer's device 300. Therefore, the BDS 106 does not necessarily implement the services of the client. license administration related to the AVB. It is the responsibility of the AVB 310 application to submit a value billing request, process a validation response, and enable the service upon receipt of a successful validation response. This local control of license management allows developers to customize their pricing and / or licensing, as desired without having to comply with predefined rules (eg, one-time charge, subscription billing, and the like) executed by BDS 106. As noted above, billing services can be extended directly to the AVB 310 application. Accordingly, the AVB 310 application can initiate billing events after the initial application download transaction, where the application AVB 310 is downloaded. The AVB 310 application can offer additional services (post-application download) for an additional cost to the subscriber / consumer. Because of the financial implications, these billing enabled applications (for example, the AVB 310 application) can use special protected application interfaces that are related to billing in the BDS 106. For example, AVB applications can access and use data interfaces. billing, download interfaces and mutual authentication interfaces to use billing through the BDS 106. These interfaces can be accessed through calls to the AVB 315 extension, which can be distributed to developers for integration with applications, as discussed in more detail below. AVB applications generate value billing for services in numerous ways. For example, game developers can provide services beyond basic applications. These services can be incremental and oscillate from improved levels of games, for example, new golf courses in golf games, up to more features, and the like. Typically, these services are offered to the subscriber through the AVB 310 application. After the subscriber confirms the purchase, the AVB 310 application can initiate a billing request and transmit the billing request to BDS 106 for processing and billing. the purchase. This capability offers the flexibility for application developers to attract a larger audience with a lower cost of entry application and / or differentiated pricing for services while running the AVB 310 application. Another example can be a purchase application of ring tones. Currently, typical ringtone applications use the pricing model for purchase / number of uses. One use is equated to a ringtone discharge. Nevertheless, by using an AVB 310 application and value billing in the BDS 106, the ring tone provider can differentiate pricing in ring tones. For example, popular ring tones may have a different price than other ring tones. Additionally, an AVB application can be quoted as a monthly subscription with incorporated billing services invoiced as incremental charges based on the billing requests generated by the AVB application. The value billing charges generated by the AVB application can be handled separately from the AVB application fee (for example, a charge for downloading a time to install the AVB application on a client device). Typically, each value billing request is considered a one-time purchase event, and there does not have to be a billing relationship between the value billing event and a BDS download event. The AVB 310 application can set billing attributes to include, among other items, a billing description and a billing amount, for example, customer list price (CLP), and other billing information that is associated with the subscriber ID (SID) associated with the client device 300 and the AVB 310 application that generated the billing request (AVB request). Billing information is sent to BDS 106, in the AVB application. The AVB request can be processed and validated using validation logic 330. The validation logic 330 can be configured by the carrier / operator and used to approve or deny the AVB request. For example, an operator may issue a denial of AVB applications with billing amounts in excess of fifty dollars, or may issue a denial of specific SID AVB requests. Additionally, validation logic 330 may have access to prepaid interfaces, if the SID is associated with a prepaid account, to check that the balance in the prepaid account has sufficient funds, for example. Once the AVB request has been approved, an AVB billing event can be propagated through BDS 106. Additionally, AVB billing events can be included in reports for the operator and / or developer for bill processing, support customer service, business intelligence, payment reconciliation support, and the like. The AVB 310 application can be pre-installed on the client 300 device or can be downloaded in a conventional manner. For example, the client / subscriber can browse a catalog, select and buy an AVB 310 application for download.

The consumer can then be asked to confirm the purchase, and can be notified that there may be additional costs for service / content associated with the AVB 310 application. The AVB 310 application can then be downloaded and the purchase transaction recorded, in a conventional way. Then, at a certain point during the use of the AVB 310 application, the opportunity to buy a "value-added service" may be presented. The AVB 310 application can use the carrier, platform, language, prepaid information and / or environment (for example BREW® 3.0) to determine relevant value added services available and pricing. The AVB 310 application can display additional quoted services to the client, for example, a new weapon for $ 0.25 or a song in MP3 for $ 1.00. Value-added items and prices can be stored locally as part of the core application and / or the AVB 310 application can connect to a content server 390 from the developer or another remote server. As discussed here, the service (value-added service) could already be in the AVB 310 application (for example, extra level of a game) or require a connection to a content server 390. The application AVB 310 can then ask the customer for billing authorization (that is, generate an AVB request). The client 300 device contacts the BDS 106 for purchase approval (e.g., makes a network connection). The BDS 106 responds with an approval or denial, or there is no response. Based on the response, the AVB 310 application can unblock the local service, contact the content server 390, or deny the requested service. The AVB 310 application may mark the transaction as pending or may leave the transaction if there is no response, after a predetermined time and / or number of attempts. The client device 300 / AVB 310 application can contact the content server 390, if they need content that is not present in the AVB 310 application. If the AVB 310 application can not recover the content, the application can put queued a retry because the purchase service was assigned. Usually, once the billing request is approved, a billing event is generated and propagated through BDS 106 and the subscriber's invoice is generated. At least one embodiment of the invention is illustrated in Figure 3. A client device 300 including an AVB 310 application is illustrated. The AVB 310 application may include an application 320 (eg, a BREW® application) that includes an extension . AVB 310 (for example, an API that enables billing requests and processing within the application). Accordingly, the billing request is generated within the device of the client 300 (for example, in the AVB 310 application). This allows the shopping experience to be controlled at the customer's device level and greater flexibility in the licensing, distribution and pricing of applications, features in applications and / or content. For example, a developer may want the provisioning of a commercial gallery-type application, with several features where each one has different price levels. These features can be included with the original application (eg, different difficulty levels) or can be downloaded from a remote content server 390 (eg, enhanced background music). The option to buy each service (for example, additional feature, content) can be presented to the user, the user can determine whether or not to purchase each service at the application level. Therefore, an AVB 310 application can generate additional incremental billing for the developer and the carrier, without the need for multiple applications and / or multiple downloads of different applications. In contrast, to achieve similar functionality using conventional systems, the application developer would need to generate different applications for each feature level and / or pricing and make them available for download. Conventional systems record billing information and process payments for each downloaded application. This process is controlled by the carrier and to buy each application, the client's device would have to connect to the carrier network to go through the application catalog and buy the desired application with the desired characteristics. At least in one embodiment of the invention, as mentioned above, the shopping experience is performed on the client device 300. Accordingly, after a purchase option is presented and accepted on the client 300 device, it is generated a billing request within the client device 300. The billing request includes information used to process the billing transaction (e.g., SID) and can be transmitted to a remote billing server (e.g., BDS 106). The billing request is received in BDS 106 and processed. A validation response is generated by the validation logic 330 in response to the billing request in the BDS 106. Then, the validation response is transmitted to the client device 300.

The validation response can be an approval of the billing request or a denial of the billing request. Once the client's device receives the response, it can process the validation response. For example, you can activate the service (for example, enabling an additional feature of a game) linked to the billing request, if the validation response is positive. Similarly, if the billing request is denied, an indication of the denial of the billing request can be displayed on the customer's device. Optionally, additional information may be included in the denial, such as the reason why the request was denied (for example, insufficient funds). In at least one embodiment, the BDS 106 may fund existing billing components to facilitate the execution of an application-based billing system. For example, in Figure 3, the BDS 106 may receive the billing request from the client device 300. The BDS 106 may then have access to the validation logic 330 which may be determined by the billing entity. (for example, an operator / carrier). The validation logic 330 may be as detailed or as limited as desired. For example, a carrier can allow all billing events to be processed as long as the SID is valid, using predetermined amounts and beneficiary information. However, validation reviews may usually include that the requested billing amount be valid and that sufficient information be provided to generate a billing event (eg, price for service, AVB application ID, short description of the service requested, and similar). This information may be included in the billing request directly or may be generated in combination with information stored in the BDS 106 or another server operatively coupled to the BDS 106. For example, an application ID may be linked to one or more vendor IDs. and pricing of the related supplier, description of the application, list price (CLP), pricing plan and the like. However, typically at least SID, price (CLP) and a short description of the requested service will be transmitted from the client device 300 / AVB 310 application, because the price displayed for the service during the purchase transaction based on the The client that generates the billing request is usually the price used for subscriber billing. Typically, as mentioned above, the billing request may include or may be associated with the SID, a short description of the service requested (short description), and a price for the service (CLP). Additional information can also be transmitted with the billing request including at least one application ID, transaction ID, delivery time, creation time, currency, long description, beneficiary ID, vendor data, SID number, platform, language, environment (for example, BREW® 3.0) and similar. The additional data may be used by the operator and / or the developer as will be appreciated by those skilled in the art. For example, the transaction ID can be a unique code used to avoid multiple billing events for the same billing / transaction request. In the wireless environment, interruptions in communication routes can cause a disruption of data communication between the billing server and the customer's device. Accordingly, a billing request may be received and approved by the billing server, but the approval may not be received by the customer's device. The transaction ID can then be used to avoid double billing, if the customer's device re-submits the billing request, because the transaction ID will be the same for both requests. In addition, the SID number can be a unique identifier associated with the SID, but not identifiable back to the SID. The SID number can then be passed on to developers / or other third parties for associated business / marketing intelligence without jeopardizing the privacy of the subscriber associated with the SID. For example, by using a SID number, it is possible to determine that a particular subscriber purchased multiple value services from an AVB application. However, the SID number prevents the identification of that particular subscriber. Additionally, in embodiments of the invention, the validation logic 330 can perform additional revisions to approve the billing request. For example, if the subscriber's pricing plan is a prepaid plan, the prepaid balance can be reviewed to see if there are sufficient funds to purchase the requested service. If there are sufficient funds, then the approval is transmitted to the client's device. However, if there are not enough funds, then the billing request is denied, even if the billing request itself is valid. Once the billing request is finally approved by the validation logic 330 / billing server 106, the approval is transmitted to the client device 300 for processing by the AVB 310 application generating the billing request. At the time of transmitting the approval to the client device 300, the transaction data is communicated to the transaction manager (TXN) 340, which is configured to receive the transaction data. The TXN 340 can optionally associate additional billing information not included with the transaction data of the billing request. For example, the transaction data may contain the SID, description of the requested service (short description), and a price (for example, CLP). The TXN 340 can associate additional data to complete the billing process (for example, item description, application ID, pricing plan, and the like). Alternatively, the TXN 340 can process and pass the received transaction data without any addition or modification. The TXN 340 then communicates this information as a billing event to a customer billing module 350 and a payment module 360. The billing module of customer 350 can be configured to receive the billing event of the TXN 340 and generate an invoice for a subscriber associated with the SID and device of the client 300. The payment module 360 can also be configured to receive the billing event of the TXN 340, to bill the carrier / operator, receive the payment from the carrier / operator and pay to a service provider (for example, developer, content provider, advertiser, and the like). The billing event can be created and processed in a manner similar to conventional application download transactions, once the transaction data has been generated. For example, the transaction data associated with the purchased billing / service request may be stored in the TXN 340 and / or related database (transaction database 118). The transaction data may include a sub-set of metadata stored in the TXN 340 or a related database and additional information included by other devices and / or systems. Billing events can be created on the TXN 340 by metadata correlation and transaction data or can be based only on the transaction data received from the AVB 310 application. Once a billing event is generated, it it can be communicated together with the related report generation data (e.g., vendor data) and can be processed by the billing module 350 and the payment module 360, as discussed above. At least some of the information included in the billing request may not be processed. For example, the vendor's data may be pass-through data that is not processed other than to propagate the vendor's data through the BDS 106 and / or related components. Although illustrated as part of a common BDS / BDS server 106, the various components that are illustrated (e.g., validation logic 330, TXN 340, billing module 350 and payment module 360) and / or functionalities described they can be separated or combined, as desired. Additionally, the various components and / or functionalities described may optionally reside in separate servers / computing devices that are operatively coupled together through a wireless or wired network, Internet, PSTN, other known communication systems and combinations thereof. Figure 4 illustrates the process of the AVB from the perspective of the developer. The developer can use AVB applications to increase revenue, expand the distribution of applications, and improve licensing configurations. To develop an AVB application, the developer can retrieve the billing documentation of value and information needed to develop a value billing application. This may include having access to programming guidelines, tools, and public extensions (eg AVB 310 extension) available from an owner / operator of BDS 106, block 410. The developer then builds an AVB application that incorporates a valuable service. aggregate that can be sensitive to the active carrier, platform, language, prepaid, and SID. Price management can be integrated into the AVB application as well as value billing transaction management services (AVB extension). The AVB application can be tested by the developer using test tools in the operating environment (for example, BREW® value-added testing tools), block 420. The application can then be delivered to a third-party test center or center of operator tests with supplementary information describing the value-added billing services and the behavior of the transaction management of the AVB application. The test center can test and / or increase the AVB application for value invoicing. For example, the testing center can verify that the AVB application transaction management adequately handles the approved, denied and unanswered BDS condition. In addition, the test center can exercise a subset of the value billing services to verify the interaction with a graphical user interface (GUI) on the client's device. Platform-based testing (for example, device type / operating system) and subscription can also be included to examine the effect on value-added service offerings by the platform and prepaid / subscription type to certify the AVB application , block 430. While the application is under development and / or during the test cycle, the developer and operator can analyze the AVB application, the value-added services, and the pricing of the AVB application and the value-added services . The operator may require a service level agreement (SLA) with the developer for the time of operation in accessing the network server and price range contracts. After the AVB application is distributed, the developer can, in some cases, change the pricing of the service using a networked server (for example, content server 390). However, operators may require pricing within an agreed price range, block 440. The pricing of the AVB application may be agreed upon by the operator, who may then add the application to a catalog of available applications at the operator's network. As discussed above, once the AVB application is available in the operator's catalog for distribution, subscribers can see the AVB application and download the application, block 450. After the application is distributed, the developer can manage the services of value added and associated pricing, if a content server / network controlled by the developer is used in the value-added services. As the AVB application generates value billing requests that are processed and approved, the developer can receive payments and reports related to AVB from the BDS. The reports can be generated by the BDS that provides usage information for each value billing event and any associated adjustments, payments that are related to the value billing services, and the like. For example, the BDS can generate payments based on the value billing services independently. Alternatively, payments can be included in a lump sum with other developer payments, such as payments for application downloads. If the payments are received in a lump sum, the payment report or other reports from the BDS can be used to identify payments based on AVB, block 460. In addition to the billing information, the seller's data can be transmitted with the billing request and can be spread through the billing system. The data in the seller's data can be included with the developer's report to stipulate that the information programmed by the developer corresponds with the invoicing requests based on AVB / private purchases. For example, the data could indicate the number of uses of an application or function, before making a particular service request based on value. This data can be used with the other reporting data to allow developers to derive important business intelligence from AVB events, which can be used for pricing decisions, application design, features to be improved / eliminated , and similar. From an operator's perspective, AVB applications allow new revenue opportunities. However, you can modify the operator distribution control points that exist with application downloads. For example, the AVB application controls the offer of value added services to the consumer and the establishment of the list price. Usually, in the conventional access of applications from an operator catalog, the operator controls the catalog and the pricing for the consumer of all applications. For AVB applications, the operator does not have the same systematic consumer / subscriber purchase control. However, operators can validate control through direct talks with developers (for example, 440). Additionally, the validation logic (for example 330) can be controlled by the operator, so that control over the approval of a billing request can still be exercised, even when pricing and other aspects are not directly controlled. Because of that, for value billing requests, the BDS 106 provides the operator's possibilities to validate all value billing requests through the operator interfaces (eg, validation logic 330). Figure 5 provides a more detailed illustration of a system for the acceptance and integration of an AVB application in a catalog manager 530 and operator catalog 540 for distribution. In general, a test center 510 may contain logic 512 configured to receive an AVB application from a developer, logic 514 configured to certify the AVB application and logic 516 configured to send the certified AVB application to the Unified Application Administrator (UAM) 520. The UAM 520 can store metadata related to the application for billing and reporting purposes, to which the BDS (for example, TXN) can access to process billing transactions. The UAM 520 may communicate the AVB application to a catalog manager 530. The catalog manager 530 may include logic 532 configured to identify the AVB application based on privileges (e.g., access to billing services and the like) associated with the application. AVB, logic 534 configured to accept the AVB application in a list of parts, logic 536 configured to add the AVB application to a pending catalog, and logic 538 configured to activate a catalog that includes the AVB application. The activated catalog can be considered an operator ADS catalog 540. The catalog 540 can be considered a catalog of purchases (for example, hierarchical clustered folders), containing applications from the parts list) that can be accessed through the ADS and presented to the subscriber for review and download. Upon acceptance of a value billing application in the parts list (for example, list of items available for download), the operator can identify the AVB application because it has a dependency on privileged billing extensions. value. For AVB applications, each operator can optionally perform additional pre-commercial tests on the application that is going to be satisfied with the GUI, the pricing, the performance and the added value services that will be exposed to its subscribers. Due to the variable business decisions of each operator / carrier, it is possible for an AVB application to pass the testing of the testing center, but not to comply with the operator's specific guidelines for value invoicing. Therefore, as part of the 440 operator's negotiation, developers should review the guidelines of each operator to determine how to work with each specific operator on AVB applications. As discussed above, the validation logic can be used to determine whether a billing request is approved or denied. The validation logic can be based on several operator interfaces relevant to the billing of value in the BDS (for example, user authorization, validation transaction, and prepaid service). The user authorization can be used by the operator to approve or deny value billing requests at the SID level.

For example, an operator may cap a value bill based on a threshold defined by the operator (for example, fifty dollars). After the threshold is reached, the operator can then deny subsequent value billing requests for an indefinite or defined period of time, for example, the rest of the month. The validation transaction can be used by the operator to include any additional validation tests on the value billing request prior to the prepayment processing or return of an approved response. This additional validation logic can include, for example, verifying that the billing account does not exceed a threshold value for a single value billing event (for example, ten dollars). Another example includes verifying that the AVB application request is not on an operator's value billing exclusion list due to disputes in the post-distribution service and pricing (or disapproved for other reasons). You can also perform revisions to the functional format, such as verifying that the billing amount is at the appropriate decimal precision. A prepaid interface can be used by the operator to use prepaid services (for example, pre-paid debit and balance authorization), which are similar to conventional prepaid services. In addition to the operator interface (for example, validation logic), additional billing integration can be added for consumer billing / subscriber processing and developer payment for value billing events. Although an operator can finance much of an existing billing system, the AVB system has many aspects of billing integration. For example, AVB billing events can be treated as a billing event type different from the application download billing events. In addition, adjustments made against AVB billing events may result in transaction adjustment events referenced as adjusted ADD transaction ID (unique code representing the AVB transaction, as discussed above). For example, a short description of the purchased service can be passed from the AVB application, because the service is usually not in the operator's catalog. Also, the billing amount spent from the value billing application can be included as the price billed to the subscriber. Adjustment services can support adjustment processing online or offline, which may include AVB billing events. However, usually, a requested service is not associated with a part number in an operator catalog. Accordingly, a customer service representative can see the AVB application that recorded the value billing event by part name and part number, but the value service itself is defined by the application and specified in the description of the billing. Accordingly, a long description can optionally be included in the AVB billing request, which can provide more detail than the short description regarding the AVB transaction. Typically, the long description is only available for customer service access and is typically not included in the subscriber's reports and billing. Adjustments to AVB billing events can be validated against similar adjustment rules such as other types of billing events (for example, download and subscription billing events), including the use of similar adjustment periods. By virtue of the above description, those skilled in the art will recognize that the embodiments of the invention include methods for performing the sequence of actions, operations and / or functions discussed herein. For example, Figure 6A illustrates a process according to at least one embodiment of the invention. A billing request can be generated on a client device, block 610. The billing request can be transmitted to the billing / system server, block 620. A validation response in response to the billing request can be generated in the system of billing, block 630. The validation response may be transmitted to the client device, block 640. The validation response may or may not be received on the client's device, block 650. If the validation response is not received (for example , after a predetermined time), the billing request may be retransmitted, until a validation response is received or a predetermined number of retransmissions is attempted, block 670. If the validation response is received, the validation response may be processed on the client's device, block 700, which is discussed in more detail below. Referring to Figure 6B, the validation process of block 630 is further illustrated. For example, as part of the validation process, the SID can be reviewed to determine if the SID is authorized for value billing services, block 632. If the SID is not authorized, then the billing request can be denied, block 631 The billing request can be reviewed for valid billing information (for example, appropriate currency, formatting and the like), block 633. If invalid billing information is detected, then the billing request, block 631, can be denied. check the tracking status of the client device 634. If the client's device is being tracked, then the billing request can be denied, block 631. The prepaid status of the SID, block 635 can be checked. If the SID is associated with a prepaid plan, then you can review the balance to see that there are enough funds to cover the billing request, block 636. If the funds are insuf If the funds are sufficient and the billing request has not been denied for other reasons, as discussed above, the billing request, block 639, can be approved. The analysis can be denied. The above and the related illustration are simple examples of aspects of the invention and the invention is not limited to these examples. The validation process can be configured with many alternative validation reviews added or removed from the previous illustration, as desired by the operator. Similarly, a non-limiting example of the validation response processing 700 is illustrated in Figures 7A and 7B. For example, an application may optionally allow all or some services before the validation response is received. These services can be determined based on several criteria established by the developer, such as service cost, to avoid service delay (for example, an added function in a video game) and the like. Accordingly, as illustrated in Figure 7A, a review can be performed to see if the service related to the validation response is enabled, block 702. If the service is enabled, the validation response can be reviewed for a denial, block 704. If a denial is received, the service can be disabled, block 706. Optionally, a notification that the billing request was denied and / or the service disabled, block 708 can be displayed on the client device. Application may not allow some services, or any service, before receiving the validation response. Accordingly, as illustrated in Figure 7B, the validation response can be reviewed for an approval, block 710. If the validation response indicates an approval and the service is available locally (e.g., in the same application), block 712, the service can be enabled directly by the application, block 714. However, if the service is not available on the client's device, a remote server / content server can be contacted, block • 716 and you can access and / or retrieve the service / content (for example, purchased tickets, downloaded music, streaming video, and the like), block 718. If the validation response is not approved, you can display a notification that the requested billing and / or service request was denied, block 720. Those skilled in the art will appreciate that only one of the processes illustrated in Figures 7A and 7B can be used by an application, or both can be used by an application (for example, when some services are enabled before approval through the validation response, and other services offered by the application are not). Again, the above analysis and the related illustration are simple examples of aspects of the invention, and the invention is not limited to these examples. In addition, other methods and alternatives may be recognized by those skilled in the art, and the illustrated examples are not intended to be a limitation of the methods discussed herein. In further embodiments, those skilled in the art will appreciate that the above illustrated methods and those described herein can be executed through a program incorporated into a computer readable medium, such as the memory of a computer platform. The instructions may reside in various types of primary, secondary or tertiary means of signal carrying or data storage. The means may comprise, for example, RAM accessible by, or residing within, the client's and / or server's device. Whether they are contained in RAM, a diskette, or other secondary storage medium, the instructions can be stored in a variety of machine readable data storage media, such as DASD storage. (for example, a conventional "hard drive" or an array RAID), magnetic tape, electronic read-only memory (for example, ROM or EEPROM), instant memory cards, an optical storage device (for example, CD-ROM, WORM, DVD, digital optical tape), "punched" paper cards, or other data storage media convenient including digital and analogous transmission media. The value-based billing system (AVB) based on the application described in the previous description can be used to open new revenue opportunities for both operators and developers. Additionally, it can allow consumers / subscribers to have increased control and choice in what they buy and do. Content support allows consumers to personalize their experience while using applications on client devices. Consequently, consumers can use these value-added offers to make them more productive with their time, while navigating through traffic or administrative contacts, and to improve the enjoyment of games, songs and other entertainment. Although the foregoing description shows illustrative embodiments of the invention, it should be appreciated that various changes or modifications can be made to the present invention without departing from the scope of the invention. For example, the functions, steps and / or actions of the method claims, according to the embodiments of the invention described herein, need not be performed in a particular order. Furthermore, although elements of the invention may be described or claimed in the singular, the plural is contemplated unless a limitation to the singular is explicitly stipulated. Similarly, functional elements that are indicated as part of a server and / or system can be organized in any operable form and can be incorporated or separated as desired. For example, the billing server may reside on a server separate from the validation logic, or both may reside on a common server and / or may be incorporated into a common element. Therefore, the modalities described above should be seen as illustrative and not as restrictive. Accordingly, it should be appreciated that those skilled in the art can make changes to those embodiments without departing from the scope of the invention, as defined by the following claims.

Claims (51)

NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following is claimed as a priority: CLAIMS

1. - A method for application-based billing in a wireless subscriber billing system, the method comprising: generating a billing request within a client device; transmit the billing request including a subscriber identification (SID) to the billing system; generate a validation response to the billing request in the billing system; and transmit the validation response to the client's device.

2. - The method according to claim 1, wherein the client device is at least one of a wireless computing device, a cell phone, a personal digital assistant (PDA), and a location device.

3. - The method according to claim 1, characterized in that the validation response is at least one of an approval of the billing request and a denial of the billing request.

4. - The method according to claim 1, further comprising: receiving the validation response on the client's device; and process the validation response.

5. - The method according to claim 4, characterized in that the processing of the validation response further comprises: enabling a service linked to the billing request, if the validation response is an approval.

6. The method according to claim 4, characterized in that the processing of the validation response further comprises: connecting to a remote content server; and retrieve content linked to the billing request, if the validation response is an approval.

7. - The method according to claim 4, characterized in that the processing of the validation response further comprises: indicating a denial of the billing request, if the validation response is a negation.

8. - The method according to claim 1, further comprising: presenting an option to purchase a service that includes a list price on the customer's device; and receive an acceptance of the purchase option, before generating the billing request.

9. The method according to claim 1, further comprising: associating the seller's data with the billing request.

10. The method according to claim 9, further comprising: propagating the seller's data through the billing system; and generate a report that includes the seller's data.

11. The method according to claim 1, characterized in that the billing request includes additional billing information and wherein the additional billing information is at least one of a list price, application ID, transaction ID, delivery time, creation time, currency, short description, long description, beneficiary ID, vendor data and SID number.

12. The method according to claim 1, characterized in that the generation of a validation response comprises: determining if the SID is associated with a prepaid account; verify that there are sufficient funds in the prepaid account; and deny the billing request, if there are not enough funds.

13. The method according to claim 1, characterized in that the generation of a validation response comprises: determining the tracking status of the client's device; and deny the billing request, if the client's device is in follow-up.

14. The method according to claim 1, characterized in that the generation of a validation response comprises: determining whether the SID is authorized for value billing services; and deny the billing request, if the SID is not authorized for value billing services.

15. - The method according to claim 1, characterized in that the generation of a validation response comprises: determining whether the billing request contains valid billing information; and deny the billing request, if the billing information is not valid.

16. The method according to claim 1, further comprising: enabling a service related to the billing request before the receipt of the validation response; and disable the service, if the validation response is a denial.

17. An apparatus comprising: a wireless client device, including an application configured to generate and transmit a billing request and configured to receive a validation response; a billing server configured to receive the billing request and transmit the validation response; and validation logic configured to generate the validation response in response to the billing request.

18. - The apparatus according to claim 17, characterized in that the client device is at least one of a wireless computing device, a cell phone, a personal digital assistant (PDA), and a location device.

19. The apparatus according to claim 17, further comprising: a transaction manager configured to receive transaction data related to the billing request and to generate a billing event; a customer billing module configured to receive the billing event from the transaction manager and generate an account; and a payment module configured at least for one to receive the billing event from the transaction manager, bill an operator and pay a service provider.

20. The apparatus according to claim 17, characterized in that the billing server is configured to associate additional billing information with the billing request.

21. The apparatus according to claim 17, characterized in that the validation response is at least one of an approval of the billing request and a denial of the billing request.

22. The apparatus according to claim 17, characterized in that the application is also configured to enable a service linked to the billing request, if the validation response is an approval.

23. The apparatus according to claim 17, characterized in that the application is also configured to be connected to a remote content server; and to retrieve content linked to the billing request, if the validation response is an approval.

24.- A client device, comprising: a transceiver that has the ability to transmit and receive data wirelessly; a user interface; and an application configured to generate a billing request, to transmit the billing request to a billing system using the transceiver, and to receive a validation response associated with the billing request from the billing system.

25. The client device according to claim 24, characterized in that the application is also configured to retransmit the billing request, if the validation response is not received.

26.- The client device according to claim 24, characterized in that the application is also configured to present a denial of the request indication in the user interface, if the validation response indicates a negation and processing the validation response , if the validation response indicates an approval.

27. The client device according to claim 24, characterized in that the application is also configured to activate a service linked to the billing request, if the validation response indicates an approval.

28. The client device according to claim 24, characterized in that the application is also configured to be connected to a remote content server.; and to retrieve content linked to the billing request, if the validation response indicates an approval.

29. The client device according to claim 24, characterized in that the application is also configured to present an option to purchase a service that includes a list price in the user interface, and to receive an acceptance of the option of purchase from the user interface, before generating the billing request.

30. The client device according to claim 24, characterized in that the client device is at least one of a wireless computing device, a cell phone, a personal digital assistant (PDA) and a location device.

31.- A billing system comprising: a transceiver that has the ability to transmit and receive data wirelessly; a billing server operatively coupled to the transceiver, wherein the billing server is configured to receive a billing request including a subscriber ID (SID) of a client device and to transmit a validation response to the client's device; and validation logic configured to generate the validation response in response to the billing request.

32. The billing system according to claim 31, further comprising: a transaction manager configured to receive transaction data related to the billing request and to generate a billing event; a billing module configured to receive the billing event from the transaction manager and generate a subscriber account; and a payment module configured at least for one to receive the billing event from the transaction manager, bill an operator and pay a service provider.

33. The billing system according to claim 31, characterized in that the billing server is configured to associate additional billing information with the billing request.

34. The billing system according to claim 31, characterized in that the validation logic comprises: logic configured to determine if the SID is associated with a prepaid account; logic configured to verify that sufficient funds are available in the prepaid account; and logic configured to deny the billing request, if there are not sufficient funds available.

35.- The billing system according to claim 31, characterized in that the validation logic comprises: logic configured to determine the tracking status of the client's device; and logic configured to deny the billing request, if the client's device is being tracked.

36.- The billing system according to claim 31, characterized in that the validation logic comprises: logic configured to determine if the SID is authorized for value billing services; and logic configured to deny the billing request, if the SID is not authorized for value billing services.

37.- The billing system according to claim 31, characterized in that the validation logic comprises: logic configured to determine if the billing information in the billing request is valid; and logic configured to deny the billing request, if the billing information is valid.

38.- A computer-readable medium in which a computer program is stored to wirelessly communicate applications based billing, the computer program comprises instructions that, when executed by at least one computing device in a device of the wireless client, causes the computing device to perform the process of: generating a billing request on the wireless client's device; transmit the billing request to a billing system; and receive a validation response associated with the billing request from the billing system.

39.- The computer-readable medium according to claim 38, characterized in that the instructions of the computer program, when executed by at least one computing device, also causes the computing device to execute the process of: retransmitting the billing request, if the validation response is not received.

40.- The computer readable medium according to claim 38, characterized in that the instructions of the computer program, when executed by at least one computing device, also causes the computing device to execute the process of: activating a service linked to the billing request, if the validation response indicates an approval.

41.- The computer readable medium according to claim 38, characterized in that the instructions of the computer program, when executed by at least one computing device, also causes the computing device to execute the process of: connecting to a remote content server; and retrieve content linked to the billing request, if the validation response indicates an approval.

42.- A billing system, comprising: means for generating a billing request within a customer's device; means for transmitting the billing request including a subscriber identification (SID) to a billing server; means for generating a validation response for the billing request in the billing server; and means for transmitting the validation response to the client's device.

43. - The billing system according to claim 42, characterized in that the client device is at least one of a wireless computing device, a cell phone, a personal digital assistant (PDA) and a location device.

44. The billing system according to claim 42, further comprising: means for receiving the validation response on the client's device; and means to process the validation response.

45.- The billing system according to claim 44, characterized in that the means for processing the validation response comprise: means for enabling a service linked to the billing request, if the validation response is an approval.

46.- The billing system according to claim 44, characterized in that the means for processing the validation response comprise: means for connecting to a remote content server; and means to retrieve content linked to the billing request, if the validation response is an approval.

47.- The billing system according to claim 44, characterized in that the means for processing the validation response comprise: means for indicating a denial of the billing request, if the validation response is a negation.

48. The billing system according to claim 42, further comprising: means for presenting an option to purchase a service that includes a list price on the customer's device; and means to receive an acceptance of the purchase option, before generating the billing request.

49. The billing system according to claim 42, further comprising: means for determining whether the billing request contains valid billing information; and means to deny the billing request, if the billing information is not valid. 50.- The billing system according to claim 42, further comprising: means for generating a subscriber invoice based on the billing request. 51.- The billing system according to claim 42, further comprising: means for generating a report based on the billing request; and means to communicate the report to at least one of an operator and a developer.