JP4139228B2 - Billing method and system based on application communication - Google Patents

Abstract

Computer- and network-based methods and systems for transmission-based billing are provided. Example embodiments provide a Packet-Based Billing System ("PBBS"), which enables application providers, such as carriers and content providers, to bill subscribers for the use of content on mobile subscriber devices, such as wireless devices, on a per-application, per-user basis based upon the extent of the usage. Embodiments of the present invention can also be used to bill subscribers for the use of content on a per-application, per-user basis for wired subscriber devices as well, using the same techniques. In operation, the PBBS provides modified content by inserting billing and tracking code into content returned to a requesting device. The modified content, when executed, tracks the amount of data sent and received between the content and a network and posts the accumulated data to a proxy/billing server according to business rules for an interval/frequency to post such data. The proxy/billing server stores the raw billing data and an accounting program retrieves the billing data to generate customer (call) data records. Business rules that specific different charges for different content or users can be incorporated into the system.

Description

(Background of the Invention)
(Field of Invention)
The present invention relates to a method and system for billing based on transmission, and more particularly to a method and system for billing the use of wireless and wired applications based on data transmitted over a network.

(Background information)
Today, wireless devices are becoming fruitful in many communities around the world. Devices such as wireless phones, handsets, personal information managers, electronic organizers, personal digital assistants, portable email machines, gaming machines, and other devices used by telephone carrier subscribers to provide convenience to our lives Is done. However, the software used on such devices, and the mechanisms for deploying and billing these devices for use of such software are esoteric. Typically, if an application or other service is loaded onto a wireless device (at a flat fee at a time), the application or other service is subscriber-based (a fee for the entire use of the set of applications and services, Alternatively, it is charged for the total line usage time (airtime). In a more recent third generation wireless network such as GPR, the carrier can identify the total number of physical packets used by the device or the amount of data used by the device. Thus, the billing model for a typical network carrier reflects a flat fee or subscriber-based billing and does not necessarily accurately reflect the use of applications and services. For example, a wireless application (eg, a calendar, browser, or email client) that accesses a network while operating on a device typically has a different carrier resource (eg, a calculator or an application) than an application that does not access the network. Use a text editor. Carriers or content providers are not available to charge accurately for the amount of carrier resources consumed by a particular application. This is because the current billing system provided at the wireless carrier level cannot provide different billing for the application level except during download.

(Simple Summary of Invention)
Embodiments of the present invention provide computer and network based methods and systems for transmission based billing. The method and system provide tracking of billing information based on the amount of data transmitted between applications or other types of content, as well as network. The illustrative embodiments provide a packet-based billing system ("PBBS") that allows application providers such as carriers and third-party content providers to be mobile subscribers such as wireless devices. Billing clients or subscribers (typically “users”) for use of applications / services (typically “content”) on a per-user, application-based, user-by-user basis Enable. Embodiments of the present invention can also be used to bill subscribers on a per application, per user basis for wired subscriber devices using the same technology.

  The PBBS determines and provides the billing tracking code and associated communication support (generally referred to herein as the “billing tracking code”), the application, and the service provider or other content provider (typically Allowing the carrier) to automatically track billing information regarding configurable logical packet levels based on the amount of data transferred and / or received by the application or service over the network. In the case of wireless devices and wireless networks, this billing data tracks network usage on a per application basis instead of the traditional “total line usage” usage model. The tracked data is associated with a particular user, allowing an application or service provider to bill on a per user basis, per application based on actual usage. In one embodiment, the tracked and transferred billing data includes the amount of data transferred / received over the network, a time stamp, an application identifier, a security key, a transaction identifier, and a retry deadline indicator. In other embodiments, the billing data may include a subset of these data, or may include different or additional data. The application / service provider may continuously implement various billing policies at the application or user level that may change over time.

  In one embodiment, the PBBS includes a packet-based billing tracking code for the content to track and store billing data on the client device and transfer the data to a server such as a proxy server or billing server. Java (R) application,. For some content such as NET applications and other binary applications, instrumentation is achieved at the bytecode level. In one such embodiment, the instrumentation parses the data structure, call sequence, content for determining the location and identification of any network call, and these calls by proxy network calls that include billing and tracking code. Executed by a content (code) modifier that replaces.

  In another embodiment, the billing tracking code is incorporated into the content by modifying the content according to the written specification. In yet another embodiment, billing tracking code is incorporated into the content via a call to an application programming interface library. In yet another embodiment, the billing tracking code is placed in network driver software on the client device and interfaces directly with the proxy / billing server.

  In yet another embodiment, the security key is inserted to allow the billing tracking code to identify the code itself to the proxy server when billing data is transferred from the client device. In one such embodiment, each security key is a number uniquely associated with the content / user combination and is stored in a secure data repository to avoid fraudulent spending and false billing data. In another embodiment, the security key is a unique random number.

  In one embodiment, the PBBS includes a network call relationship to different proxy network calls including a content (code) modifier, a billing tracking code. That is, one or more data repositories, business rules for billing data, raw billing data, and security keys, proxy servers, billing servers, and accounting programs. In accordance with this embodiment, PBBS functionality can be integrated into different programs and distributed via different components in the application acquisition system. These components then determine the billing tracking code, interact to insert this code into the content, receive data from the billing tracking code, and with the billing policy shown to generate a billing record Process the tracked data. In one embodiment, the billing tracking code is inserted in response to a request from the client device for the application, and the modified application is automatically returned. This billing data is then transferred when the modified application is implemented on the client device. In another embodiment, billing data is generated directly in response to a request from a client device for streaming content such as streaming audio and video. This is because the request is for a specific number of bytes or amount of data. In one of these embodiments, the application acquisition system provides an application to the wired device. In another embodiment, the application providing system provides an application for a wired device.

  In another embodiment, data based on transmission is used to route network packets from the application to other servers (network traffic). In accordance with this embodiment, transmission-based (billing) data generates greater efficiency by the proxy server by determining how much resources the application is consuming, for example, significantly used or popular Used to determine that network traffic can be directed to provide / guarante better response times for applications, or applications based on some other criteria.

(Detailed description of the invention)
Embodiments of the present invention provide computer and network based methods and systems for transmission based billing. The method and system provide tracking of billing information based on the amount of data transmitted between applications or other types of content, as well as network. Exemplary embodiments provide a packet-based billing system (“PBBS”) that is based on application-by-application, user-by-user, based on the degree of usage, by application providers such as carriers and third-party content providers. As a client or subscriber (generally “user”) for use of an application / service (typically “content”) on a mobile subscriber device such as a wireless device. Embodiments of the present invention can also be used to bill subscribers on a per application, per user basis for wired subscriber devices using similar techniques. Although this description primarily refers to applications, those skilled in the art will recognize that the method and system described herein can be transmitted at any packet level (such as services and resources) over a network. It is understood that billing data can be communicated to a server when applicable to types of content and these are “executed” on the client device. For example, an engine for playing audio or video or the like can be modified for transmission based billing according to these methods. Furthermore, the methods and systems described herein can be extended to text, video, audio, graphics, and other content that can be streamed.

  The PBBS dynamically provides billing tracking code and associated communication support (collectively referred to herein as “billing tracking code”), and applications, as well as service providers or other content providers (typically The carrier) can automatically track billing information regarding configurable logical packet levels based on the amount of data transmitted and / or received by the application or service over the network. The tracked data is associated with a specific user, allowing the content provider to bill on a per user, per application basis based on actual usage. Content providers (generally used herein to refer to any type of content provider) may subsequently implement various billing policies at the application or user level. This billing policy can change over time. For example, application providers may charge lower fees for popular applications because they are measured by the amount of packets received / forwarded by these applications for a particular subscriber, for example if used frequently by subscribers You can hope for. As another example, a service provider may wish to implement a promotion for a new application because there is little charge per transmission for that particular application compared to a normal fee.

  FIG. 1 is a schematic block diagram of a billing system based on an exemplary transmission. In FIG. 1, a packet-based billing system 100 includes several components. That is, a content (code) modifier 103 for modifying the requested content to include the billing tracking code, a configuration data repository 105 for storing the transmission and billing tracking code, and downloaded to the target (client) device. A proxy server and / or billing server 104 for receiving and collecting billing data from the content, collected billing data for collecting billing information, and other billing data repositories 106 for storing billing data and business rules, and An accounting program 107 that reads the collected billing data and generates a customer billing record 108. As described in further detail below, the PBBS component is typically integrated into a system that provides content to a target device. In operation, a client device such as personal computer 101 or wireless handset 102 requests content, such as an application, from a system that provides the content. Content can be requested from a system connected to a wireless device (such as handset 102) via a wireless network or connected to a wired device (such as personal computer 101) via a wired network from the connected system. Can be requested from the system. For part of the process of requesting content, after the system determines and retrieves the requested content, the content modifier 103 analyzes the content and inserts what type of billing tracking code into the requested content. The configuration data repository 105 is consulted to determine what needs to be done and to modify the content accordingly without the user's knowledge. This modified content is then returned to the client device 101/102 for downloading. At a later time, if the downloaded modified content is executed on the client device 101/102, the billing tracking code automatically collects billing data and forwards it to the proxy / billing server 104 To be executed. The billing server 104 collects the received billing data according to business rules and stores it in the billing data repository 106. Accounting program 107 may then retrieve the collected billing data to generate customer billing record 108. Typically, accounting programs are specifically designed to accommodate the need for services that are responsible for billing, such as carriers in a wireless network environment.

  Exemplary billing data includes the number of bytes transferred and / or received, a timestamp, an application identifier, a user identifier (automatically transferred by the carrier infrastructure when the billing data is transferred over the wireless network) , Security key, transaction identifier, and retry end indicator. Transaction identifiers are typically used to identify individual / different billing tracking “events”. If the client device recognizes that the transfer operation will fail, this retry end indicator indicates how long the client device should continue to retransmit the same billing data. Similarly, the proxy / billing server uses the retry end indicator to determine how long the transaction identifier is valid for detecting duplicate incoming transfers.

  In one embodiment, the FBBS content modifier (eg, the content (code) modifier 103 of FIG. 1) includes a packet-based billing tracking code in the requested content to accomplish the techniques of the present invention. As used herein, instrumentation is a non-intrusive means for modifying content (eg, an application) to include additional code, in this case with billing tracking and transmission code. is there. In one embodiment, the network tracking resident in the content is detected by a PBBS code modifier and replaced by a billing tracking code that is dedicated to transmission based billing so that the billing tracking code Calculate and collect and call the original special network call. In this sense, instrumentation is used as a “hook” before and after a network call as a way to block the network call. Because different content uses different network calls in different environments and different providers have different billing policies, the PBBS code modifier uses configuration data to determine which replacement network call comprises the content. A repository (such as the configuration data repository 105 in FIG. 1) is used. This replacement call may store the billing data collected in temporary storage on the target device locally, and then the collected data if the content finishes executing (eg, the application exits). Forward. Alternatively, the collected data can be transferred in response to each network call. Furthermore, the collected data can be stored in permanent storage on the client device so that it can be transferred after cycling power on the device. Those skilled in the art will understand that different scenarios are possible when data is transferred and are contemplated to work with these techniques.

  FIG. 2 is an exemplary block diagram of content provided using a billing tracking code as performed by a content (code) modifier of a packet-based billing system. For example, code such as application 210 is transferred to code identifier 201 for analysis and preparation. The calling order of routines within the application 210 is schematically shown (after undergoing a calling order analysis). According to the order shown, the “startup ()” routine 211 is called, followed by the network call 212, followed by the “end ()” routine 213 for application cleanup, and then terminates application execution The end call 214 is followed. The content modifier 201 references the network call in the configuration data repository 202 and determines and retrieves a corresponding network call 222 that includes code for implementing transmission-based billing and tracking. A corresponding network call 222 is implemented to call the original network call 212, thereby providing a “hook” to the original network call 212. This content modifier 201 also transfers configuration parameters for billing, such as how frequency billing information is transferred (eg, after a specific time or amount of data has been transmitted), and billing data is transferred. Examine the configuration data repository 202 to determine the network address of the proxy server to be. The content modifier 201 then comprises the application with the retrieved network call 222 and the code for transferring the billing data, as indicated by the determined configuration parameters. A schematic diagram of the exemplary modified application 220 is shown by call order after instrumentation has been performed. In the modified application 220, the “startup ()” routine 211 is called, followed by the next provided network call 222 (following the original network call 212), followed by the “end ()” routine 213. The content modifier also includes a code 223 for transferring billing data to the proxy / billing server according to predetermined configuration parameters. This transfer code 223 is shown in the order between the “end ()” routine 213 and the end call 214. By having a code that transfers billing data at the end of the application, it will attempt to retry any previously failed transfer, even if billing data was transferred earlier. In one embodiment, if the last transfer call 223 fails, the billing data simply fails and is ignored. Other embodiments may choose to store billing data and retry transfers more permanently if the application is run again. This retry end indicator may be used to prevent redundant billing events. In particular, the client device determines, based on the timestamp, whether the retry period is terminated or whether the transfer code should attempt to retransmit the same billing data. Those skilled in the art will appreciate that many such modifications are possible. In addition to the billing tracking code provided, in some embodiments, once the content modifier 201 is downloaded, billing data for the application cannot be dressed by transferring counterfeit billing data. To ensure that the security key 230 is added to the modified application.

  In other embodiments, as detailed in Appendix E, the billing tracking code is incorporated into the content by other means including interrupt and non-interrupt means. For example, specifications for packet-based billing tracking codes can be provided to other providers that can modify their content to explicitly include such tracking and the like. In a second example, an application programming interface (“API”) may be invoked by a content provider at an appropriate point in the content to provide packet-based billing tracking and communication. In yet a third example, the network driver software of a target device, such as a wireless device, may be modified (via a specification or library mechanism) to include a packet-based billing tracking code. In all of these other embodiments, either the content provider or device driver manufacturer needs to be aware of the billing tracking code and communication technology, thereby providing more interrupt means to incorporate billing support. .

  PBBS components and functionality can be integrated and distributed over different components in a network environment such as an application provisioning system. Then in this scenario, providing the component determines the billing tracking code, inserts it into the content, receives data from the billing tracking code, and generates a billing record along with the billing policy indicated Interact to process tracked data. More specifically, when an application is requested by a subscriber, the application is provided by the application provisioning system for the requesting device and downloaded with the appropriate billing code provided for the application on the requesting device. Is done. As used herein, providing is to customize and distribute content for a particular use (eg, for a particular type of subscriber device by a particular customer). An exemplary application provisioning system called Mobile Application System (MAS) may be used with the PBBS described herein. Appendix D describes in detail such a system, including technology for providing code to the application, customizing such application, and distributing this application specifically to wireless devices. MAS is a collection of interacting server components that work individually and together in a secure manner to provide applications, resources, and other content to mobile and wired subscriber devices.

  FIG. 3 is a block diagram of an exemplary transmission-based billing system implemented within an exemplary mobile application system environment. The illustrated mobile application system (MAS) is a provisioning system connected to a wireless handset 310 via a wireless connection. The components of the MAS include, among other things, a provision and deployment manager 302 that includes a content scanner, analyzer, and instrumentation capability 303 as part of its functionality, a billing manager 305, a configuration data repository 304, and accounting. Program 306. This instrumentation capability 303 of the provision and deployment manager 302 provides a PBBS code modifier function. The billing manager 305 may incorporate a proxy server role to collect forwarded billing data. The wireless handset 310 typically includes flash memory 311 or other types of local, semi-permanent storage for holding billing data when billing data is collected. The wireless handset 310 is also connected to a public network such as the Internet 320 via a wireless connection. For simplicity of explanation, it is assumed that the handset 310 allows addressing to a server on the public network 320 that forwards billing data directly and separately to the MAS billing manager 305, but this assumption is The techniques described herein are not necessarily achieved. In particular, if the client device cannot address directly to multiple servers, a proxy server may be provided that implements storage and transmission capabilities for all received network packets. In this scenario, the proxy server receives the packet, determines its intended destination (and receipt of the billing data), retrieves the billing data from the packet, and sends its original packet data to its intended destination To do.

  Although PBBS technology is generally available for any type of client wireless device, those skilled in the art will recognize that the terms subscriber device, client device, telephone, handheld, etc., work with PBBS. It is understood that they are used interchangeably to indicate any type of subscriber device that is possible. Alternatively, the terms may have alternative spells that may or may not be explicitly described. For example, a byte-code may also be indicated as “byte code” or “byte code”, and those skilled in the art should include all such variations of terminology. Understand what is intended. Additionally, the exemplary embodiments described herein provide applications, tools, data structures, and other support for implementing a billing system based on transmission over one or more networks. Other embodiments of the method and system of the present invention provide billing support based on software transmission for the software and have non-wireless subscriber devices (personal computers, docked wireless handsets, Internet connectivity) Including providing billing support based on transmission for software and other content over a non-wireless network, such as the Internet, for a telephone or customer kiosk (eg, in an airport or shopping mall), Understand that it can be used for many other purposes. Furthermore, although this description primarily refers to content in the form of applications, services, and resources, those skilled in the art will understand that content may include text, graphics, audio, and video. Alternatively, in the following description, numerous specific details are set forth, such as data formats and code flows, in order to provide a thorough understanding of the techniques and system of the present invention. However, those skilled in the art will recognize that the present invention may also be practiced without some specific details described herein or with other specific details (such as changes to the order of code flows). recognize.

  Furthermore, the PBBS technology can be extended to work with streaming content. In particular, if streaming content (text, audio, video, graphics, etc.) is requested by a client device, the request indicates the amount of content to download. Instead of inserting billing and tracking code into the content, the content modifier generates billing events directly and forwards them to the proxy / billing server.

  Alternatively, those skilled in the art will recognize that the techniques of the present invention can be used for other uses where determining and tracking the amount of data transferred and received is valuable other than generating billing data. To do. For example, a further use for the techniques of the present invention relates to the routing of network packets and requests. In particular, the same technique for tracking billing data based on the amount of data transferred and received between content and the network determines how and where to route network packets based on routing policies Can be used by proxy servers. The transferred “billing data” includes information identifying the user, the application to be transmitted and the amount of data, which can be used by the routing system to route traffic. For example, an application server may provide some kind of load balance by desiring to distribute network traffic in a particular manner or store a particular server for significant traffic application / user combinations. .

  FIG. 4 is an exemplary block diagram of a general purpose computer system and client device for performing an embodiment of a transmission-based billing system. The computer environment of FIG. 4 includes a client (subscriber) device 401 and a general-purpose computer system 420 that communicate via a network 410. Each block may represent one or more such blocks as appropriate in a particular embodiment, or may be combined with other blocks. Each block may reside in a separate physical location.

  Client device 401 includes computer memory (“memory”) 402, display 404, input / output device 403, and central processing unit (“CPU”) 405. Modified content 406 (eg, an executable application) is shown to reside in memory 402 using a data repository for temporary storage of other downloaded applications 407 and billing data 408. This modified content 406 preferably executes and inserts on the CPU 405 as shown in the previous figure to track transmission data and communicate billing data to the proxy / billing server via the network 410. The billing tracking code

  The general purpose computer system 420 may include one or more server and / or client computing systems and may span distributed locations. In one embodiment where the PBBS is integrated into an application providing system such as MAS, the MAS is implemented using Java® Enterprise Edition (J2EE) on a general purpose computer system that provides a J2EE compliant application server. Execute. In accordance with this embodiment, the MAS is designed and encoded using the J2EE multi-tier application architecture, which supports web tier, business tier, and database tier on the server side. Accordingly, general purpose computer system 420 represents one or more servers capable of running one or more components and / or data repositories of MAS and PBBS.

  As shown, the general purpose computer system 420 includes a CPU 423, memory 421, and optionally a display 422 and input / output devices 424. The components of PBBS 430 are shown to reside in memory 421 and preferably execute one or more CPUs 423. Other data repositories and other programs (not shown) also reside in memory 421 and preferably execute on one or more CPUs 423. In an exemplary embodiment, the PBBS 430 includes a content modifier 425, data repositories 427 and 428 for storing transmission and billing tracking codes, billing data and business rules, billing server 426 (to act as a proxy and billing server). As well as an accounting program 429). As described above, the PBBS may include other data repositories and components depending on the needs of the carrier or other host system and its integration. Other components that are part of the application provisioning system also reside in memory 421 (not shown, such as provisioning and deployment components and local application storage). As described, the application is provided and provided using a billing tracking code by the content modifier 425 prior to downloading to the client device 401.

  Those skilled in the art will recognize that PBBS 430 may be implemented in a distributed environment consisting of multiple, uniform, heterogeneous computer systems and networks. For example, in one embodiment, content modifier 425 and billing server 426 are located on physically different computer systems. In another embodiment, the various components of PBBS 430 can be hosted on separate server machines and remotely located from data repositories 427 and 428. Further, in some scenarios, the accounting program 429 can be hosted within the carrier infrastructure and completely separated from the PBBS. Different configurations and locations of programs and data are contemplated for use with the techniques of the present invention.

  In the exemplary embodiment, the components of PBBS 421 are implemented using the J2EE multi-tier application platform, as described in detail in Java® 2 Platform, Enterprise Edition Specification, Version 1.2, Sun Microsystems, 1999. (As part of MAS). Typically, the content modifier 425 is part of the MAS delivery and deployment manager (as shown in FIG. 3). Billing manager 426 is a component of MAS that has been enhanced to perform various capabilities associated with billing based on transmissions. Data repositories 427 and 428 for storing the code to be measured, business rules, and billing data may be part of the MAS configuration manager (see configuration data repository 304 in FIG. 3) or security. May be implemented as a separate data repository, depending on the needs of, the location of the accounting program 429, etc. 5-13 illustrate various exemplary embodiments of specific routines implemented by each of these components to achieve the functionality described with reference to FIGS. 1-3. In the exemplary embodiment, these components may execute simultaneously and asynchronously so that the components may communicate using well-known message passing techniques. Those skilled in the art will appreciate that equivalent synchronization embodiments can also be supported by the PBBS implementation. Alternatively, those skilled in the art will recognize that even if other steps are implemented for each routine in a different order and with different routines, the functionality of the PBBS can still be achieved.

  As described with reference to FIG. 1, a client (subscriber) device may request an application from an application providing system, such as a mobile application system. With MAS, applications may be pre-provisioned to devices and subscribers, stored locally within MAS (called "walled garden provisioning"), For example, by browsing the site over the Internet ("open provisioning"), an application can be provided on the fly when requested. FIG. 5 is a block diagram of several example procedures for transferring an application for a mobile application system for use with transmission-based billing. In FIG. 5, a content provider 501 such as a third-party application provider or carrier transfers an application for the providing system (shown herein as MAS 502). The MAS 502 stores the application in the local storage 503 (either as raw data or previously provided). Content provider 501 also provides billing related to business rules appropriately stored by MAS 502 in billing data repository 504. These rules include billing related information such as frequency or interval for transferring billing data, proxy server address for forwarding billing data, logical packet size, and billing billing information associated with logical packet size. Indicates. Those skilled in the art will appreciate that other billing related business rules that are application specific or user specific may also be stored if required.

  FIG. 6 is an exemplary block diagram illustrating an overall process for unknowingly delivering an application that supports billing based on transmission to a client device using a mobile application system. The client device 601 requests an application from the MAS 602 using the command handler 602. The command handler 602 processes a request for the MAS. The command handler 602 is responsible for distributing application requests to appropriate components of the MAS (such as MAS provisioning and deployment manager (not shown)). These components, including content modifier functionality, determine whether an application corresponding to the requested application already exists in the cache 603, or whether the application needs to be provided for deployment. As part of the provisioning process, the billing tracking code is included in the application 605 and a security key 606 is added to generate a modified application 604. Even if the provided application with the billing tracking code provided is available in the cache 603, it may be necessary to generate a security key (depending on the technology used). Preferably, a security key 600 is generated and stored in a secure data repository 607 along with an associated application identifier and application identifier. Any mechanism for generating a security key uniquely associated with a subscriber and application can be incorporated and used with the techniques of the present invention. One mechanism is to generate an n-bit random number and combine this random number in some manner using a unique application identifier and a unique subscriber identifier. This mechanism allows a single security key to be reused for more than one of the application / subscriber combinations. This is because this key is uniquely tied to each application / subscriber combination. Thus, the modified content (including the billing tracking code and security key) is cached, which can allow for fast download of the content. Alternatively, a unique security key can be associated with each application / subscriber version of the content. The purpose of the security key is to generate a number that can subsequently be recognized as uniquely belonging to a particular subscriber and application when the billing data is forwarded to a proxy / billing server for collection and processing. The modified application 604 is optionally stored in the cache 603 and returned to the requesting client device 601 via the command handler 602. It may be desirable to store the modified application 604 in the cache 603 in a short period of time if the request fails to download properly and the client device 601 retries the request for the same application. However, note that in one embodiment, the security key added to this application is associated with a particular subscriber. In this scenario, storing the modified application 604 with the security key in the cache 603 does not make sense for deploying to different application / subscriber combinations.

  FIG. 7 is an exemplary flowchart of a routine for modifying an application to support transmission-based billing. This routine is typically performed as part of the provisioning and deployment process (see content modifier 201 in FIG. 2). In essence, the routine determines or generates a version of the designated application with the billing tracking code provided, determines or generates an appropriate security key to be inserted into the application, and returns the modified application to the requester. In particular, at step 701, the routine receives an application request having a specified application as a parameter. In step 702, the routine determines whether the provided application is already available (eg, stored in cache 603 in FIG. 6) and if so, proceeds to step 705 and if not available. The process proceeds to step 703. In step 703, the routine analyzes the code flow of the application and causes the application to include billing tracking code. This process is further described below with reference to FIG. In step 704, the routine stores the provided application in, for example, an application cache, and proceeds to step 707. In step 705, after determining that the provided application is already available, the routine retrieves the provided application from local storage (eg, cache) and proceeds to step 706. In step 706, the routine determines whether the retrieved application already has a security key attached to or associated with it. If you already have a security key, go to step 710 to retrieve the security key (or the application that was modified using the security key), or go to step 707 if you do not already have a security key. It may be desirable to retain a security key attached with a built-in application to limit potential dressing for a limited period of time. In step 707, the routine generates a new security key for the application. Any suitable security mechanism may be utilized including the mechanism described in FIG. In step 708, the routine stores the newly generated security key in a secure data repository. In step 709, the routine causes the application to have a new security key. In step 711, the routine sends the modified application including the provided billing tracking code and the security key for the requester, and the process ends.

  FIG. 8 is an exemplary flowchart of a routine for analyzing and providing an application with support for transmission-based billing. This routine converts the application into a modified application that includes support for transmission-based billing as shown in FIG. In step 801, the routine scans and parses the application structure and call sequence flow, preferably at the bytecode level (sometimes referred to as a “binary application”) at the data structure (package, class, method, and Understand field definitions) and calling order. As part of this decomposition / decode process, the routine detects all of the APIs present in the application and identifies any network calls. As a result of this analysis, in step 802, the routine identifies which code invokes the network, thereby placing the call within the application. If the application is encoded in Java (R), this analysis can be performed at the bytecode (or binary) level of the program without the need to insert analysis generated code at the source level (the bytecode level is binary (Interpreted by "engine", "byte code", interpreter, "virtual machine" etc.) for execution by referring to "intermediate level" of code). Those skilled in the art will appreciate that other embodiments can be implemented for other languages and content by providing and analyzing data structures and calling orders. Those skilled in the art will recognize that other embodiments may be implemented and implemented for other languages and content to provide data structures and calling order and be detected and analyzed. In particular Java (R) and. NET applications are uniquely adapted to such processes. This is because these applications are driven instructions (ie, different bytecodes are used to indicate different language elements). Other intermediate code languages can be parsed as well. In step 803, the routine determines a proxy network call corresponding to the network call located within the application. These proxy calls are typically determined from a deployment data repository that associates various network calls with a particular device and protocol. Attachment A contains exemplary pseudo code for mapping a located network call to a proxy network call. In step 804, the routine determines specific business rules that apply to this application, for example, as specified by the carrier. As explained at the beginning, these rules are associated with the interval / frequency for the billing data to be transferred to the proxy / billing server, the logical size of the packet to be used for charging, and the packet Billing can be defined. An extended set of rules can be specified on a per application or user basis. Those skilled in the art will appreciate that other business rules may be identified as appropriate and may change over time. For example, in some systems, it may be possible to provide default charging information by an application programmer, and this information may be modified by a standard multiplier by carrier (ie, PBBS). In step 805, the routine replaces the network call identified in the application with a proxy network call, as shown in FIG. As shown in FIG. 2, in step 806, the routine adds a final proxy network call to transfer billing data at the end of application processing. Typically, this call is typically added even if the forwarded billing data is called to the proxy / billing server if the previous proxy network call system fails. In situations where a previous proxy network call collects data locally on the client device, the final call to transfer the data communicates with the billed data of the accumulated set of billing data.

  As described with reference to FIG. 1, when the modified content is executed (processed) on the client device, the billing tracking code is activated to collect the data and pass the data to the PBBS. Automatically forward to associated proxy / billing server. FIG. 9 is an exemplary block diagram illustrating the overall process for communicating billing data based on network transmission data on a per application basis. For illustrative purposes, the component is assumed to be part of the Internet of the application providing system. Those skilled in the art will appreciate that it can be integrated into any content distribution system capable of performing the functions of the PBBS as described at the outset. In FIG. 9, the client device 901 transfers billing data (via a network packet) to the proxy server 902 as a result of the transfer code previously provided in the application (see FIGS. 2 and 8). Two different types of proxy servers can be implemented depending on the capabilities of the device. In particular, some devices may forward packets directly to more than one server. In that case, the billing data may be transferred directly to the proxy server 902 while packets 909 destined for some servers are transferred directly to the server (such a setup is sometimes referred to as a computational and log approach). Other devices can forward network packets to only one server. In this scenario, proxy server 902 acts as a store and send proxy server, distributing network packets to their intended destination and processing only packets with forwarded billing data. If it is a separate server, proxy server 902 collects the forwarded data and sends it to billing server 903 as appropriate. In some embodiments, a proxy server and billing server are combined. However, in some situations it may be desirable to separate proxies and billing servers, eg for security purposes. As another example, the billing server may already exist and have a specific data collection protocol that the proxy server interfaces with. Once the collected billing data is received, the billing server 903 determines that the security key transferred with the billing data is the security key and the predicted security for that particular application and its user in the security data repository 905. Determine whether it is legal by comparing it with the key. If the security key is legal, the billing server 903 stores the raw billing data in the data repository 906. The billing server 903 may optionally post-process billing data, for example, according to business rules stored in the repository 906. Those skilled in the art will recognize that the data repositories are separated as shown for illustrative purposes only, and other combinations such as a single data repository are used. Further, proxy server 902 may directly store raw billing data to be processed asynchronously by billing server 903. Accounting program 904 retrieves billing data (raw or post-processed) from data repository 906 and optionally uses invalid business rules (such as stored in data repository 907) to further process the billing data. Process and generate a call (customer) data record 908. Invalid business rules may include, for example, specific application or subscriber invalidation, promotion, and the like.

  FIG. 10 is an exemplary flowchart of a client routine for transferring data that has been modified to collect and transfer billing data to the network. This routine shows exemplary proxy network code that replaces several types of “send_data” network calls. An exemplary pseudo code implementation of proxy network code for transferring data over a network is included in Appendix B. This routine tracks and accumulates the amount of data to be transferred, and billing data is transferred if the accumulated amount corresponds to the business rules built into the routine for the frequency / interval for transferring billing data. The In particular, at step 1001, the routine determines the amount of data transferred in the current packet and accumulates that data (eg, in variable “data_out”). In step 1002, the routine stores the amount of data in the current packet along with a time stamp in local storage, an application identifier, and a security key. In step 1003, the routine determines whether it is time to transfer data (eg, whether a time / frequency encoded interval is handed over to transfer data). If it is time to transfer the data, the process proceeds to step 1004 to transfer the billing data to the proxy server. If it is not time to transfer data, the process proceeds to step 1006. In step 1006, the routine determines whether the business rules for database transfer are count based (based on the amount of data). If the business rule is count-based, whether the count is greater than the rule indicated for transferring data. If the count is greater than the rule indicated for transferring data, the routine proceeds to step 1005, and if the count is not greater than the rule indicated for transferring data, the routine proceeds to step 1007. In step 1005, the routine proceeds to step 1004 to reset the data amount counter and transfer the billing data to the proxy server. In step 1007, the routine transfers the data using the original network call encoded in the application.

  FIG. 11 is an exemplary flowchart of a client routine for transferring data that has been modified to collect and transfer billing data to the network. This routine shows exemplary proxy network code that replaces several types of “receive_data” network calls. An exemplary pseudo code implementation of proxy network code that receives data over a network is included in Appendix C. This routine tracks and accumulates the amount of data to be received, and billing data is transferred if the accumulated amount corresponds to the business rules built into the routine for frequency / interval to transfer billing data. The In particular, at step 1101, the routine receives data using the original network call and blocks this reply. Then, in step 1102, the reply determines whether the original network call was successful and proceeds to step 1103 if the original network call was successful and returns an error if the original network call was not successful. In step 1103, the routine determines the amount of data received in the packet and accumulates it (eg, in the variable “data_in”). In step 1104, the routine stores the amount of data in the current packet received with a timestamp in local storage, an application identifier, and a security key. In step 1105, it is determined whether it is time to transfer data (eg, whether a time / frequency encoded interval applies to transfer data). If it is time to transfer the data, go to step 1106 to transfer the billing data to the proxy server. If it is not time to transfer data, the process proceeds to step 1107. In step 1107, the routine determines whether the business rules for database transfer are count based (based on the amount of data). If the business rule is count-based, whether the count is greater than the rule indicated for transferring data. If the count is greater than the rule indicated for transferring data, the routine proceeds to step 1108 and returns if the count is not greater than the rule indicated for transferring data. In step 1108, the routine resets the data amount counter, proceeds to step 1106 to transfer the billing data to the proxy server, and then returns.

  FIG. 12 is an exemplary flowchart of a server routine for processing billing data based on forwarded transmissions. This routine may be executed, for example, by a billing server (such as billing server 903 in FIG. 9) or a proxy server (such as proxy server 902 in FIG. 9). Those skilled in the art will appreciate that the steps included herein are merely exemplary, and that different steps may be substituted for these steps, depending on the placement and integration of PBBS functionality in the surrounding environment. Recognize that can be combined with. In step 1201, the routine receives billing data transferred from the client device. In step 1202, the routine extracts the security key, application identifier, and user identifier from the billing data. Then, in step 1203, the routine compares the information with the application identifier and user identifier associated with that security key in the security key data repository table. In step 1204, if the security key information matches, the routine proceeds to step 1206, and if the security key information does not match, the billing data is discarded in step 1205 and the routine returns. In step 1206, the routine stores the billing data (or sends the billing data to the billing server). In embodiments where the device is limited to communication with one server system, then in step 1207, the routine detects and sends the specified data packet to the other server and then returns.

  FIG. 13 is an exemplary flowchart of steps for generating a billing charge based on billing data based on transmission. This routine can be executed by, for example, an accounting program (such as the accounting program 904 in FIG. 9). The steps set forth herein are generally applicable to processing billing records. However, depending on the carrier details or other content providers that determine the billing rate, customer (call) data record applicability and data record format, various additional or different steps may be included. In step 1301, the routine retrieves billing data based on the transmission. In step 1302, the routine determines applicable business rules for the indicated application identifier and user identifier. In step 1303, the routine determines whether any invalid policy / business rule (eg, advertisement, discount, etc.) exists, and if any invalid policy / business rule exists, proceeds to step 1304; Determine invalid rules. If there are no invalid policy / business rules, go to step 1305. In step 1305, the routine applies any determined business rules to generate a call data record. The format of these records is highly dependent on any billing system in which billing data based on transmission is integrated into a billing system that already exists, for example, within the wireless carrier infrastructure.

  From the foregoing, it will be understood that although particular embodiments of the invention have been shown herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. . For example, those skilled in the art will be able to apply the methods and systems described herein to a content providing system and a billing system based on transmission any network, wired, wireless, or via a plurality of such networks. Recognize Those skilled in the art will understand that the methods and systems described herein differ in protocols, communication media (optical, wireless, cable, etc.), subscriber devices (wireless handsets, electronic organizers, personal digital assistants, portable email machines, games) It is also recognized that the present invention can be applied to a navigation device such as a machine, a pager, or a GPS receiver. Aspects of the invention can be modified to take advantage of the methods, systems, and concepts of these various patents, applications and publications to provide further embodiments of the invention, if necessary. Moreover, those skilled in the art will understand how to make changes and modifications to the methods and systems described to meet specific requirements or conditions.

付録（ＡＰＰＥＮＤＩＸ） Ｄ
無線アプリケーションの保守および分配
本発明の実施形態は、無線アプリケーションを保守および提供するためのコンピュータおよびネットワークベースの方法、ならびにシステムを提供する。本明細書中で議論されるように、プロビジョニング（Ｐｒｏｖｉｓｉｏｎｉｎｇ）とは、特定の使用、例えば、特定の顧客による特定の種類の加入者デバイス上で使用するためのコンテンツをカスタマイズおよび分配することである。例示の実施形態においては、モバイルアプリケーションシステム（ＭＡＳ）が提供される。ＭＡＳは、アプリケーション、リソース、およびモバイル加入者デバイスへの他のコンテンツを提供するために、個別かつ共にセキュアな態様で動作する相互運用サーバコンポーネントの集合である。ＭＡＳは、例えば、セルラー電話およびハンドセットデバイス等の無線デバイスが、それらのデバイス上で用いるために、新しい、かつ更新されたアプリケーションをＭＡＳから動的にダウンロードすることを可能にする。動的ダウンロード能力は、無線アプリケーションのディベロッパー（コンテンツプロバイダ）の製品化までの時間の要求（ｔｉｍｅ−ｔｏ−ｍａｒｋｅｔ ｒｅｑｕｉｒｅｍｅｎｔｓ）を著しく低減し、その結果、製品サポートおよびマーケティングの効率を高める。顧客は、その無線デバイス上でオペレーティングソフトウェアを迅速かつ便利に更新し、かつ人気のあるアプリケーション（ゲームを含む）をダウンロードすることができる。ＭＡＳを用いて、顧客は、その無線ハンドセットデバイスをネットワークから直接的に更新し、これにより、ソフトウェアを更新するために地域の顧客サービス担当者と話す、または、サービスセンターを訪れるという時間のかかる経験を回避することができる。ＭＡＳは、さらに、加入ビリング（ｓｕｂｓｃｒｉｐｔｉｏｎ ｂｉｌｌｉｎｇ）を含む柔軟なビリングシナリオを支援し、これは、顧客が特定のサービスに加入して、所望するリソースおよびアプリケーションのみを受取ることを可能にする。

Appendix (APPENDIX) D
Wireless Application Maintenance and Distribution Embodiments of the present invention provide computer and network-based methods and systems for maintaining and providing wireless applications. As discussed herein, provisioning is the customization and distribution of content for use on a particular type of subscriber device, eg, by a particular customer. . In the illustrated embodiment, a mobile application system (MAS) is provided. A MAS is a collection of interoperable server components that operate individually and together in a secure manner to provide applications, resources, and other content to mobile subscriber devices. MAS allows, for example, wireless devices such as cellular phones and handset devices to dynamically download new and updated applications from MAS for use on those devices. The dynamic download capability significantly reduces the time-to-market requirements for developers (content providers) of wireless applications and consequently increases the efficiency of product support and marketing. Customers can quickly and conveniently update operating software on their wireless devices and download popular applications (including games). Using MAS, customers can update their wireless handset devices directly from the network, thereby talking with local customer service representatives or visiting service centers to update their software. Can be avoided. The MAS further supports flexible billing scenarios including subscription billing, which allows customers to subscribe to specific services and receive only the desired resources and applications.

  Although the capabilities of MAS are typically applicable to any type of customer wireless device, those skilled in the art will recognize that any term such as subscriber device, customer device, phone, handheld, etc. can work with MAS. It is used interchangeably to indicate a subscriber device. In addition, the exemplary embodiments described herein provide applications, tools, data structures, and other support for implementing maintenance and distribution of wireless applications over one or more networks. Those skilled in the art will recognize that other embodiments of the method and system of the present invention can be used to connect a personal computer, a network-connected wireless handset, a telephone with connectivity to the Internet, or an airport or shopping center via a non-wireless network such as the Internet. It will be appreciated that it can be used for a number of other purposes, including maintaining and distributing software and other content to non-wireless subscriber devices such as customer kiosks within. Furthermore, although this description primarily relates to content in the form of applications and resources, those skilled in the art will recognize that this content may include text, graphics, audio and video. Furthermore, in the following description, numerous specific details such as data format, user interface screen display, code flow, menu options, etc. are provided to provide a thorough understanding of the method and system techniques of the present invention. Indicated. However, those skilled in the art will recognize that the present invention does not use some of the specific details described herein, or that the code flow ordering or changes related to specific features shown on the user interface screen display, etc. It will be appreciated that other specific details can also be used.

  FIG. 1 is an exemplary block diagram illustrating aspects of a wireless service subscriber requesting and downloading a software application from a mobile application system. The wireless environment in which the MAS operates includes subscriber devices 101 and 101b, a wireless network 102 with a transceiver 103, a wireless carrier service 104, a MAS 105, and various content providers 106. The content provider 106 provides the application to the MAS 105 through or by authorization of the carrier service 104. The application is then verified, published, and served to the subscriber device 101 by the MAS 105 when requested. This type of provisioning is referred to herein as “walled garden” provisioning. This is because the applications delivered and published in this manner are known to the carrier and / or MAS infrastructure. The content provider 106 may further treat as an application an application that can be browsed by a subscriber device that can be dynamically served by the MAS 105. This type of provisioning is referred to herein as “open” provisioning. This is because it is not limited to “known” applications within the scope of MAS or carrier infrastructure. These are only distinguished for discussion purposes because different types of provisioning share multiple similar functions. The MAS 105 further provides carriers, content providers, customer care personnel and subscribers with multiple tools to customize the applications, services, and billing scenarios available to a particular subscriber or group of subscribers. .

  In FIG. 1, a subscriber device 101 is a wireless network such as a wireless handset, a telephone, an electronic organizer, a personal digital assistant, a portable electronic mail device, a game device, a page, and a navigation device, whether or not currently present. An electronic device capable of communicating via 102 is included. One or more subscriber devices 101 (also referred to as customer devices) communicate across the wireless network 102 to a wireless carrier service 104 that the subscriber has processed to use that service. The wireless network 102 has a transceiver 103 that is used to relay services (and process subscriber requests) to the subscriber device 101. Those skilled in the art will recognize a relatively large form factor, such as personal computer 101b, that allows wireless service subscribers to provide an easier-to-use interface by using alternative networks (such as the Internet) and for downloading applications. It will be appreciated that by using a device having, it can complement any or all of the steps involved in requesting and downloading wireless applications across a wireless network. Transceiver 103 typically converts wireless communications to cable-based communications and cable-based communications to wireless communications, but those skilled in the art will recognize that various media and protocols can be used. The transceiver 103 typically communicates with the carrier service 104 across a cable-based medium using a carrier-only communication protocol. Carrier-only communication may use any protocol suitable for point-to-point communication, such as hypertext transport protocol (HTTP) and wireless application protocol (WAP). The carrier service 104 includes accounting, POTS ("plain old telephone service") and other telephone services (automatic forwarding, caller ID service, voicemail, etc.) and telephones that can be downloaded Provide a service that is typical to a station, a mobile application system 105 is provided in communication with a carrier service 104 via, for example, a broadband communication channel 108 or a publicly accessible network such as the Internet 107. The application to the subscriber device 101. Those skilled in the art will recognize that the mobile application system 105 may be fully or partially integrated with the carrier service 104. Using yield garden provisioning, the downloadable application generated by the content provider 106 is typically provided directly to the mobile application system 105 or carrier service 104 or across a network such as the Internet 107. These downloadable applications are then properly validated and customized by the mobile application system 105 and provided to the subscriber device 101. In an embodiment that supports open provisioning, the carrier's subscribers can be located (network). By specifying an address or URL (Uniform Resource Locator), the application can be downloaded from the website. .MAS that may be over the soil, and intercepting a download request from the subscriber, then the specified position, validated, and the customer supplies the application to.

  Subscriber device 101 relies on a customer side application management utility (eg, a handset administration console or browser) to request and download applications. FIG. 2 is an exemplary block diagram of a handset administration console operating with a mobile application system. The handset administration console handles notification, installation and uninstallation of applications on the subscriber's wireless device. Subscriber device 201 provides the subscriber with a menu of functions available to the device. The subscriber may be selected, for example, from a menu routine that manages applications already installed on the device and provides new applications that can be downloaded. For example, the routine obtains version information for installed applications, downloads these application updates as they become available, and browses for new applications to be downloaded. Can make it possible. Menu 202 is an exemplary menu showing a list of new applications 203 that may possibly be downloaded to subscriber device 201. The exemplary screen display 204 shows an exemplary user interface provided after the subscriber selects an application to download. The screen display 204 provides an icon 205 indicating a download operation, a title 206 of the application to be downloaded, and a status bar 207 that displays the ongoing process of the download. The screen 204 further provides a stop button 208 that allows the download process to be canceled.

FIG. 3 is a flowchart of an example overview of the general steps performed by an example mobile application system to provide an application to a wireless subscriber device. These steps are applicable to either a provisioning scenario (using a walled garden) or open provisioning. These same steps can also be used to provide applications to wireless devices such as those connected through the Internet 107 in FIG. Steps 301-310 illustrate the manner in which the MAS processes an incoming request to download an application from the subscriber device, provides the requested application, and transmits the requested application to the subscriber device. Provisioning includes one or more of code extraction, inspection, optimization, instrumentation, and packaging, and is necessary to prepare the application for downloading to the target device Depending on the, further steps may be included. For example, additional security and billing methods can be added to the system, and provisioning can include encrypting the division and reporting. In another case, steps 301-310 assume that the application is requested directly from the MAS as opposed to being indirectly requested by browsing a location on the network. (In the case of open provisioning, the MAS intercepts the request and attempts to serve and download the application as if it were received for the first time.)
Specifically, in step 301, the application is typically made available for download from a carrier or directly from a content provider. Applications can be written using a computer language such as Jave that can run on a variety of subscriber devices. Applications are stored locally in the carrier's application data repository (which can be located at the MAS or at the carrier's premises) or, where appropriate, stored on a trusted third party server (open). In the case of provisioning, the third party server is not necessarily trusted). In step 302, the subscriber downloads an application, retrieves a list of available applications, and sends a request to execute a specific management query or other command. Protocol conversion is performed on incoming requests (and outgoing messages) to enable communication with subscriber devices across various wireless carriers. Downloaded applications can be, for example, new and popular applications that run on subscriber devices, or upgrades or more recent software versions. The request is made using, for example, Uniform Resource Locators (URL) using HTTP that informs that the request is directed. MAS supports an extensible command processing engine and direct calls of various handlers, modules, and other structures that are components of MAS, either through HTTP requests or application programming interfaces (“APIs”). In the case of an application provisioning request, a request to download a specific file is made by assigning a URL that identifies the file (application or service) to be downloaded. Made to a servlet or other code in the MAS that processes the request, in step 303, the MAS is for download or for certain other commands. If the request is a download request, the process continues at step 305. Otherwise, the command is processed at step 304. In step 305, the URL to which the MAS is assigned specifies a published application. If not (which indicates that a walled garden supply can be performed) is determined and specified, continue at step 306, otherwise continue at step 308. At step 306, the subscriber's The request is verified for authentication, device capabilities, and, where appropriate, prepaid billing authorization, which typically depends on the level of service the customer has subscribed to. Assist prepaid billing, which allows subscribers to use the application Allows the payment to be made in advance, in which case the MAS verifies that the prepaid billing account can handle the request before the application is downloaded. Other factors such as how many times the subscriber has accessed the service, whether there is a special offer price, the date or week the service was accessed, the number of bytes to be downloaded and other such factors The device capabilities can be further checked to determine if the requested application can operate satisfactorily on the subscriber device, which may include, for example, a device profile that is known to the requesting device and Application profile for the requested application Can be performed by comparing with In step 307, the MAS determines whether the subscriber's request has been successfully verified and, if verified, continues at step 308, otherwise it rejects the request, and another Return to step 302 to await the request.

  In step 308, the MAS determines whether there is already a pre-provisioned application that corresponds to the subscriber request and is appropriate for the subscriber device. The pre-supplied application is an application that has been pre-customized according to the authorization level and capabilities of the subscriber device. When pre-supplied applications are available, they minimize system latency for corresponding application requests and enhance system response time. Applications can be pre-supplied by a typical level of subscriber subscription and a typical subscriber device (eg, determined by the intended use), and stored and pre-supplied applications for later access In response to a subscriber device request for an application corresponding to. If the application was not provisioned in advance, the MAS will dynamically serve the application, which will increase the time required to process the request, but will allow customized and authorized applications to be distributed. Generate.

  If at step 308 a suitable pre-provisioned application is found for the subscriber device, the provisioning scenario continues at step 310, otherwise it continues at step 309. At 309, the application is provisioned for a particular subscriber device and according to access authorization. In step 310, the MAS sends the provided application to the subscriber device for download.

  As mentioned above, one of the requests supported by the MAS is to retrieve a list of available applications that can be downloaded to the subscriber's device. This process is called application discovery. FIG. 4 is an exemplary flowchart outlining the steps performed by an exemplary mobile application system that performs application discovery for a wireless subscriber device. In the exemplary embodiment, two types of application discovery are supported. The first type generates a list driven by and derived from the system. The second type specifies a search term that is driven by a requester and matched by the MAS to generate a list of “appropriate” applications. In step 401, the MAS determines whether the user has entered any search terms, and if so, continues at step 402, otherwise continues at step 403. At step 402, the MAS searches the published application's data repository for those that meet the criteria specified in the request and continues at step 404. Alternatively, in step 403, the MAS determines an initial list. In one embodiment, this list is formed from the subscriber's personalized list (if available), otherwise MAS provides a default list. In step 404, the MAS filters this initial list based on subscriber and device capabilities. For example, the MAS can determine, for example, whether a subscriber is authorized to use the application and whether the application needs as reflected in the application profile are met by the device. Various profiles such as profiles, device profiles and application profiles may be analyzed. In step 405, the MAS adds any system-defined application to the list (referred to as “startdeck”). Such applications can be assigned according to the carrier's customizable rules, for example, placing these applications at the top of the list can give applications that generate more revenue “premium” visibility time. . In step 405, the MAS formats the list according to the visibility capabilities of the requesting device (eg, a supported markup language) and ends processing.

  FIG. 5 is a schematic block diagram of components of an exemplary embodiment of a mobile application system. In this embodiment, mobile application system 500 includes protocol manager 503, provisioning manager 504, cache 505, deployment manager 506, billing manager 507, logging manager 508, administrator 509 and heart rate monitor 310. These components interoperate to receive applications from content providers and carrier services, provision them for delivery to subscriber devices and process MAS commands, as shown in FIG. Those skilled in the art recognize that many different arrangements and divisions regarding the functionality of a MAS component or different components are possible. For example, functions located in protocol manager 504 and billing manager 507 are combined into one component. Other arrangements are also possible and are contemplated.

  The various components of the MAS are content that is developed and distributed to the carrier by a carrier (or system) administrator or customer care representative who manages the services provided by the carrier. It interacts to provide a number of capabilities to providers and subscribers consuming services, applications and other content. Administrator 509 provides various user interfaces to each of these types to configure MAS, applications, billing and other services and customize the subscriber experience through MAS. In the provisioning aspect, as described with reference to FIG. 3, the functionality of the MAS in terms of processing steps that occur in the MAS component when a subscriber calls the MAS and causes the application to be downloaded to the subscriber's device. Explained. Those skilled in the art will recognize that other data flows and usage of the component are appropriate and depend on the command processed and / or the way the component or code within the component is invoked. .

  More specifically, in the exemplary embodiment shown in FIG. 5, communications from subscriber devices such as J2ME or WAP handsets are presented to mobile application system 500 as incoming request 501 and outgoing data 502, respectively, Received from application system 500. Typically, a MAS is invoked by a subscriber via a command interface (as opposed to a website-based interface) to handle two different types of input requests (application search and requested application download). To do. The MAS can also be invoked to process other commands. Also, a component of the MAS can be called directly, for example, to execute a management request to obtain usage information. If the input request 501 is an application search request, it compiles and returns a list of available and appropriate applications based on the subscriber, application profile and device profile. The steps normally performed by the MAS to achieve application search are described with reference to FIG. Alternatively, if the input request 501 is a request to download the specified application, the MAS searches for the application, verifies that the application is appropriate, and that the download is allowed to the device and user, and requested Provision and package the application and send the packaged application to the requesting subscriber device. The steps normally performed by the MAS to achieve the provisioning application are described with reference to FIG.

  Protocol manager 503 performs protocol conversion of messages between the subscriber device and provisioning manager 504. Protocol conversion ensures that MAS 500 can communicate with any subscriber device (wireless or wired) and is independent of the communication protocol used in the network (such as wireless network 102 in FIG. 1) and should be processed. Allows incoming requests that can be embedded within various protocols. The example protocol manager 503 has built-in support for WAP and HTTP protocols and can be extended with well-known techniques that provide support for additional formats and protocols. One or more separate gateways, such as a WAP gateway (not shown), may reside between the protocol manager 503, incoming request 501 / outgoing data 502. These gateways can be used to process messages targeted as a specific protocol. The protocol manager 503 may also optionally include a plug-in security layer and handle data encryption, decryption, and certificate management for end-to-end security support. Those skilled in the art will recognize that the protocol manager 503 can be extended to include other types of support for secure communications as desired.

  Once the incoming request is properly translated, the provisioning manager 504 processes the request and, if necessary, takes care of other component assistance. For example, if the request is a management query, the provisioning manager 504 may forward the request to the management servlet in the MAS. Instead, if it is a request for a list of applications that can be downloaded to the subscriber device, the provisioning manager 504 addresses the performance and request of each application available from the carrier to the subscriber's device and subscriber. To generate such a list by comparing with appropriate device and subscriber profile data, the repository 311 and profile management code may be queried. On the other hand, if a request from a subscriber downloads a specified application, the provisioning manager 504 and deployment manager 506 interact to obtain and provision the requested application for distribution to the subscriber. In one embodiment, provisioning manager 504 validates application information referenced by user, device, billing and subscriber requests, and deployment manager 506 retrieves and provisions the application. The application provisioning process performed by the deployment manager 506 includes one or more of the following processing steps. Searching step, checking step, optimizing step, code editing step, packaging step, which will be described below with reference to FIG.

  The provisioning manager 504 receives the subscriber request from the protocol manager 503 and handles the download request or other commands included in the subscriber request. Download requests are handled based on the information submitted by each download request and other information accessible by the MAS (eg, a profile stored in the data repository 511). When processing a request to download an application, provisioning manager 504 may have previously generated or utilized for subscribers, subscriber devices, and requested application (s) and billing related information. Test the possible profiles and determine the suitability of the requested application for the subscriber using the particular subscriber and following the subscriber billing method. After reviewing the profile, the provisioning manager 504 either either approves or denies the request, for example, by trying to assess whether the requested application can successfully run on the subscriber device. . For example, this evaluation is performed by determining whether application requirements can be met by the performance of a particular subscriber device. The provisioning manager 504 also determines whether the billing method is set up for the requested application, whether the subscriber is adaptable and sufficient to perform the download. For example, if this request indicates that the subscriber is part of a prepaid billing program, the provisioning manager 504 should be sufficient to allow the application for which the subscriber's prepaid bill funds have been downloaded. To verify.

  Once authenticated, provisioning manager 504 may obtain the requested application from either cache 505 or deployment manager 506. Typically, the cache 505 is used to store frequently downloaded applications in a pre-provisioned format, while the deployment manager 506 dynamically provisions applications while they are requested. Used. Applications controlled by the carrier are typically pre-provisioned and stored in the cache 505, for example, applications available via the Internet site are typically provisioned only when download is required.

  Cache 505 is used to provide faster delivery of the requested application to the subscriber device. The cache 505 is used to cache provisioned applications being processed ahead of time for a particular profile, eg, for a particular subscriber device or in response to authorized access. It is done. Applications stored in cache 505 that have already been inspected, optimized, and edited are tagged as provisioned for deployment. Those skilled in the art also recognize that system performance may be enhanced by implementing similar caching functionality among other components of the MAS. For example, a cache that holds Internet applications may reside between the deployment manager and the Internet and reduce the access time required to communicate with the Internet application. Also, for example, a cache that holds unstored JAR files can be implemented to speed up the instrumentation process. Other configurations are possible. If a requested authentication application for a particular subscriber and a particular device is not found in the cache 505, that application can be retrieved via the deployment manager 506. The deployment manager 506 prepares an application for delivery to the subscriber device. Deployment manager 506 provides support for applications (eg, illegal application detection, restricted API usage, trial distribution (use allowed for only one set of times or one set of time) and other billing methods; Managing many aspects of provisioning, maintaining and provisioning) (and other aspects) such as application size optimization for requesting subscriber devices. The deployment manager 506 acquires the application and provisions each application instance for the intended (requested) use of the application when an instance of the application is requested. The deployment manager 506 also stores specific results for specific devices and / or subscriber profiles by pre-provisioning applications for those profiles, storing results for quick access in the cache 505, or other data repository. Applications may be pre-deployed ("pre-provisioned"). As will be described below with reference to FIG. 7, the deployment manager 506 can be from a carrier's application data repository, from a remote application host (trusted or untrusted), or any Applications can be deployed from other application sources. After the deployment manager 506 properly provisions the requested application, the deployment manager 506 returns the requested application to the provisioning manager for any post-processing on outgoing responses.

  Details regarding transactions are typically recorded in the logging manager 508 when the provisioned application is being communicated to the user. Logging manager 508 enables various billing methods that are accessible to billing manager 507. The recorded data includes information regarding the incoming request 501 and deployed applications such as subscriber ID, download size, download time and date, and the particular application downloaded. Due to the wide variety of information recorded about downloads, operators have great flexibility in billing methods for application provisioning, depending on the different categories of services and subscribers. The carrier may charge, for example, by air traffic used, download time, amount of data downloaded, client demographics, or based on the particular application downloaded.

  The billing manager 507 is obliged to assist in implementing the billing method. In the exemplary embodiment, several initial billing options are provided. (1) Download fees based on downloading applications, (2) Packet-based billing fees based on network packet transmissions, (3) Subscription fees based on periodic fees such as daily, weekly or monthly (4) Trial usage fee based on any calculation method of trial usage, for example, the number of times an application can be executed, (5) Prepaid billing. These billing options can be customized at both the carrier level and the application level, and the desired billing option can be selected by the subscriber when one or more are provided for a particular application. In the exemplary mobile application system 500, an application programming interface (API) is provided for easy integration by the carrier's existing billing subsystem. In one embodiment, the subscriber pays in advance for an application to be downloaded later. When the subscriber downloads the prepaid application, the billing manager 507 forwards the billing record to the carrier's prepaid billing system, which changes the amount of the subscriber. Can be updated. In an alternative embodiment, prepaid subscriber accounts are stored and maintained by billing manager 507. Other configurations are possible and support for other types of billing methods. After the billing manager 507 generates billing related information, the application is sent to the protocol manager 503 and reformatted for a different protocol if needed and transmitted to the customer as outgoing data 502. .

  Administrator 509 interacts with other components of exemplary MAS 500 and customizes various aspects of MAS 500. For example, the administrator 509 allows operators to implement contracts related to customizable provisioning and integrate MAS with their own infrastructure via the reprogramming component of the mobile application system itself. This allows subscribers, carriers, system administrators and content providers to be more flexible when performing profile management, report generation, billing method management and server management.

  The heart rate monitor 510 monitors and provides reports of other MAS 500 components and provides appropriate notifications when relevant system events occur. For example, it detects a system problem such as a component not working. For example, heart rate monitor 510 can monitor protocol manager 503 and determines whether protocol manager 503 responds to incoming requests within a predetermined time period. If the heart rate monitor determines that the protocol manager 503 is not responding properly, a number of heart rate monitors 510 can monitor whether the first monitor is functioning properly and can take over if necessary. Is done. The heart rate monitor 510 is capable of both active monitoring (by polling the device with a status request) and passive listening (by verifying that a particular type of communication occurs at the appropriate time). The heart rate monitor 510 also provides an interface to industry standard protocols such as Simple Network Management Protocol (SNMP), allowing other external codes to monitor the MAS.

  As described with reference to FIG. 5, the MAS provisioning manager processes incoming download requests and other commands and drives dynamic provisioning of applications for downloading. FIG. 6 is an exemplary block diagram of exemplary provisioning manager components of a mobile application system. In one embodiment, provisioning manager 600 includes a MAS command, control processor 620 (“MCCP”), verifier 601, XSLT processor 630, request processor and post processor 640, and MAS data query engine 650. The MCCP is responsible for decrypting the request and directs the request to the correct MAS subcomponent. For example, downloading a lighted application or executing an application search. A verifier 601 including a subscriber verifier 602, a device verifier 603, a prepaid bill verifier 604, and an application verifier 605 performs the verification and appropriately determines the application for the subscriber and the device. The XSLT processor can be implemented, for example, as an industry standard extended style sheet processor and is used to format data according to the rendering capabilities of the requesting device. In one embodiment, the XSLT processor supports style sheets for SML, but additional style sheets for HTML, Java, WML, XHTML Basic and text, or any other makeup or rendering language. Can be easily extended to provide The request processor and post processor 640 can be extended to manipulate the parameters of the request “packet” to communicate within other components and perform any type of processing that can be “hooked” at this level. The MAS data query engine 650 manages communications with various data repositories. The MAS data query engine 650 includes a provisioning reader 651, a profile reader 652 and a configuration data reader 653. Although there are no arrows to connect these components so that they can be easily seen, those skilled in the art recognize that the components are interconnected and interacted in many ways.

  Initially, provisioning manager 600 receives an incoming request from a protocol manager (eg, protocol manager 504 of FIG. 5) or the like. Manager 600 parses incoming requests and optionally reprocesses requests by modifying requests that dynamically consider changing, or restricting, subsequent provisioning, billing or logging steps. To do. Such dynamic modification allows the carrier to dynamically hook its own infrastructure to the system. For example, the provisioning manager 600 may observe a request header passed along with an incoming download request and modify, add or delete headers to modify system behavior. Since other components of the MAS use information that is included with the header, updating or modifying the header information is a means of extending or limiting the functionality of a particular request or modifying the behavior of the MAS. provide.

  When received from the MAS command interface (as opposed to being called directly via a website or API), the request is processed by the MCCP. If the request is for application searching or downloading content, various verifiers 601 are used to determine the suitability of the application. If the request is for some other command, the request is processed as a result.

  Application verifier 604 determines whether the requested application is prohibited by the deployment carrier. Specifically, application verifier 604 examines a list of applications. Here, the carrier does not want the list of applications to be downloaded so that the carrier can decide whether to prohibit the requested application. For example, this situation occurs when an application is suddenly discovered to provide unjust behavior and the carrier wants to immediately suspend the carrier's distribution.

  The subscriber verifier 601 determines the identity of the subscriber from the person who generated the request and determines the level of service. For this level of service, the subscriber is entitled to determine whether the subscriber is authorized to use a particular application. Subscribers for a particular service are entitled and can be determined by searching and using profile reader 652, corresponding subscriber profile, as well as by testing various factors alone or in combination. Factors may include, for example, the number of downloads allowed in any month, the time required for the download, the time that requests are made during the day and week, the availability of special offers, and the grace period. The subscriber verifier 601 can also determine the subscriber group to which the subscriber belongs and determine the access level allowed to the subscriber by determining services that are considered and not considered for the subscriber group as a whole. decide. An exemplary embodiment of the determination performed by the subscriber verifier is described with reference to FIG.

  Device verifier 602 determines the type and capabilities of the subscriber device (requests from this subscriber device) and determines whether the capabilities of the device are sufficient to support a particular application. The capability of the subscriber device, if present, is determined by searching using the profile reader 652 corresponding to the requesting subscriber device. The device profile is tested to determine if the device has the characteristics required by the requested application that runs properly on the subscriber device. An exemplary embodiment of the determination performed by device verifier 502 is described with reference to FIG.

  When prepaid billing is supported by the MAS, the prepaid bill verifier 603 queries the carrier prepaid billing infrastructure wherever billing records for individual subscribers are stored. Downloaded requests are typically allowed to proceed to provisioning only when there is sufficient funds in the subscriber's account, as indicated by the carrier.

  After the provisioning manager 600 determines that the subscriber device is appropriate to run the requested application, the subscriber has sufficient funds to use the application (as part of the prepaid billing scheme). ) Be authenticated. The provisioning manager 600 then calls the provisioning manager's provisioning interface to obtain the corresponding provisioned application. The deployment manager is described with reference to FIG. 7 and retrieves and provisions the requested application and returns it to the provisioning manager 600.

  After a provisioned application suitable for downloading to a subscriber device is obtained from the deployment manager, the provisioning manager 600 optionally post-processes the request. By preprocessing, the post process can perform further modifications to the validated request so that this modification can be used to extend the functionality of the MAS. For example, the instructions later introduce a protocol manager (eg, the protocol manager of FIG. 5) and package a request for a custom protocol.

  As described above, a deployment manager (such as deployment manager 506 in FIG. 5) receives a subscriber request from a provisioning manager, or receives a direct request (eg, from a system administrator) and requests it. Acquire the corresponding provisioned application. The request includes the URL of the requested application, and the requested application indicates the location of the source for the application. In one embodiment, the URL refers to a list of mirror sites and retrieves the application from the optimal location determined from the MAS. In another embodiment, the URL is a proxy and the deployment manager redirects the URL to its actual location. Such a method may provide an additional secure layer to the system. Those skilled in the art recognize that any method of indicating a location for an application can be used by these techniques and that these techniques operate on indicators rather than URLs. The application is also inspected, optimized and edited for transmission before the application is deployed and sent to the subscriber.

  FIG. 7 is an exemplary block diagram of components of a deployment manager of a mobile application system. The deployment manager 700 includes a retriever 701, a remote fetch 702, a local fetch 703, an inspector 704, an optimizer 705, an instrumentation installer 706, and an application packager 707. The retriever 701 obtains application code from the appropriate host server using either the remote fetcher 702 or the local fetcher 703, then the application code through various components and the application code appropriately. To vision. In particular, the inspector component 704 inspects applications for illegal code and forbidden APIs; the optimizer component 705 reduces code size if possible; And management functions, for example, incorporate billing and notification messages into the code.

  In particular, the retriever 701 allows multiple users and multiple carriers to communicate over various networks using different protocols. This is achieved in part by allowing the carrier to be flexible at the location of the software application (content) that the carrier will host for distribution. For example, a carrier may host all available applications from the carrier's own network by storing such applications in a specified directory for a data repository such as an FTP or HTTP server, standard DBMS, etc. Can be selected. The carrier application store 708 is such a data repository and may reside on the server of the MAS itself. The retriever 701 activates the local fetcher 703 to retrieve a copy of the data stored locally. The carrier may also choose to allow trusted third party application providers to host applications from the remote application host 709. This remote application host 709 is under the control of a trusted third party application provider. Further, when used to perform open provisioning, the retriever 701 may retrieve applications from third party hosts that are not necessarily from trusted sources. In both cases, the carrier uses the URL supplied by the third party to attribute the incoming request to a specific downloadable application hosted on one of the remote application hosts 709. The retriever 701 typically activates the remote fetcher 702 to search for such applications hosted on the remote application host 709 when such hosts are accessible via public protocols. In one embodiment, the local fetch 703 may be optimized to quickly retrieve locally stored data, while the remote fetcher 702 implements the required public protocol and via a public network. Search for applications that reside on accessible hosts.

  Depending on the trusted third party host or carrier preference, the application code retrieved by the retriever 701 may already be provisioned. If the retriever 701 acquires code that is not provisioned, the code is sent to the inspector 704, optimizer 705, and instrumentation installer 706 for further processing. The inspector 704 examines the retrieved unprovisioned application code and detects illegal code. In Java® code, the inspector 704 can also perform class analysis of application code, where the class in the application matches the desired standard such as number, type, frequency of API calls, etc. In addition, the inspector 704 applies application filters to package and method names, classes, fields, or subscribers, target devices or some that are suspected or requesting inconvenient, improper behavior. Detect other forms of API that cannot be authenticated for use by other targets. Inspector 704 may also apply application filters and detect API usage patterns. The inspector 704 is available to use the subscriber and device profiles retrieved by the provisioning manager (described with reference to FIG. 6) so that the inspector 704 can be per device or subscription Restrictions can be enforced on a per-user basis. In an exemplary embodiment, the inspector 704 allows such parameter thresholds and thresholds for flagging parameters for further inspection by other entities, such as, for example, a logging manager, to be adjusted. To do. If the inspector 704 searches for potentially unlawful behavior, violations due to provisioning (and subsequent downloading) and criminal identity reported to the logging manager may be prevented (or the subscriber warned To do).

  After the inspector 704 tests the unprovisioned application code that was successfully retrieved, the code is forwarded to the optimizer 705 for further processing, reducing the size of the application. The optimizer 705 uses methods well known in the art to shorten variable names and remove unused code from the application. Such optimization procedures usually make downloads faster. The optimizer 705 can also use techniques well known in the art, and when this technique is performed, the speed of the application is increased, such as changing the use of specific instructions to more efficient instructions. Those skilled in the art will recognize that any optimization can be incorporated into the system as the components of the MAS can be extended or modified.

  After optimization, the inspected and optimized application code is transferred to the instrumentation installer 706 for further processing. Because downloadable application suppliers typically do not have the ability to modify the requested application for an individual subscriber, it is desirable to modify the application code to add specific code to the subscriber. . For example, a billing option such as a “trial use” scheme may be implemented, for example, by inserting code into an application that causes the application to run only a certain number of times or only for a specific period of time. Similarly, code for reporting information for logging purposes, or information for other billing options (such as packet-based billing that fills based on the number of network packets transmitted) may be implemented. Also, in the case of open provisioning, code may be provided that alerts the subscriber that the subscriber is trying to download and execute content from an untrusted source. The instrumentation installer 706 may also modify the code of the application according to other terms specified by the carrier (eg, terms for implementing promotion and advertising campaigns). By using well-known methods such as manipulating libraries, or by subclassing classes and methods, code can be provided for many other purposes, or can be provided in place. This is recognized by those skilled in the art.

  After instrumentation installer 706 has the requested application, application packager 707 is inspected, optimized, and packaged with the provided application. As determined from the device profile acquired by the provisioning manager and described with reference to FIG. 6, the application packager 707 formats the contents of the application file in a manner that the subscriber device can read by: Package the required application. For example, many subscriber devices have the ability to read files presented in a compressed “JAR” format (Java archive format). The “JAR” format is a format used to compress and package a requested JAVA application. Because some devices cannot receive compressed JAR files, the application packager 707 can provide custom packaging of provisioned applications for those subscriber devices that cannot receive files in the compressed JAR format. provide. It is worth noting that such packaging converters and other converters for formats other than JAR can be installed in application packager 707 using well-known techniques such as by subclassing packaging routines. Recognized by contractors. In addition, some subscriber devices may limit the size of packets that the subscriber device can receive. When detected, the application packager 707 may package a provisioned application for such a subscriber device into a number of data files. The subscriber device may incorporate this multiple data files into a single JAR file upon receipt. Multiple data files can be used by subscriber devices to install applications.

  As described with reference to FIG. 5, an administrator component (eg, administrator 509) may be used for different types of users to configure the various components of the mobile application system and specify preferences. FIG. 8 is an exemplary block diagram of an administrator component of a mobile application system. In one embodiment, administrator 800 preferably provides multiple web-based user interfaces to allow content providers, system (telecom operators or MAS) administrators, subscribers, and customer service support staff to be components of MAS. To make them accessible and customizable for their experience. In particular, the exemplary administrator provides a content provider website 801, an administrator website 802 and a personalization website 803. Those skilled in the art will appreciate that each described website can include multiple screen displays, and that these and / or other screen displays, and websites can be combined in various configurations to achieve the same result. It has recognized. For example, the administrator website 802 may optionally include a separate customer care website 804. This customer care website 804 may be used by a customer care representative (usually of a carrier) to manage individual subscriber accounts on behalf of the carrier.

  The administrator 800 provides a content provider website 801 for use by content providers, submits downloadable applications to the MAS, and the submitted downloadable applications are reviewed (eg, reviewed) and authorized for publication. Monitor whether it is done. The content provider may also use the content provider website 801 to recommend changes to the application provider, monitor the popularity of those applications, or communicate with the MAS administrator.

  Administrator 800 also provides an administration website 802 for MAS system administration and manages published and pending applications, eg, submitted by content providers. In one embodiment, the administration website 802 interface provides separate nodes to build, configure and / or manage accounts, applications, subscribers, devices, servers and reports.

  The system administrator may use the application node of the administration website 802 to identify global billing methods supported by the carrier. In one embodiment, the administrator may select a number of billing options that generate a fee for each download, each network usage (eg, transmission-based), each subscription, and each non-cost trial use.

  Other functions are also accessible to the system administrator via the administration website 802. For example, a system administrator may use subscriber nodes, manage the use of MAS by subscribers, and build a subscriber profile for each subscriber. The subscriber profile maintains a list of published applications downloaded by each subscriber, maintains a list of forbidden applications that a particular subscriber cannot operate, and a group of subscribers to which a particular user belongs Generate and maintain In one embodiment, these profiles are stored in the MAS data repository (eg, the data repository in FIG. 5) and read by the provisioning manager's profile reader (eg, profile reader 652 in FIG. 6).

  The system administrator may also send a message to the subscriber (eg, a notification that an updated version is available for one of the applications already downloaded by the subscriber). This behavior is sometimes referred to as a “push” ability. Information for contacting the subscriber is usually available from the subscriber profile.

  In addition, the system administrator may choose to remotely operate or stop the downloaded application over the wireless network when the instrumentation installer 706 instrumentes properly downloaded content. For example, an instrumented application may be forced to check by a host server (communication carrier or third party) to recognize whether a new version of the application is available and the application server The subscriber may be prompted to determine whether to download a new version. Instrumented applications are also forced to check by the host server to determine if the time limit expires or if the application exceeds the number of times it can run (eg, using a trial period billing option). Can be done. An instrumented application may also place a daily time limit that may limit the application to be used only a certain number of times within a set period of the day, for example. These restrictions effectively allow system administrators to revoke or restrict subscriber privileges, allowing applications to run even after the application is downloaded to the subscriber's wireless device. . Those skilled in the art will recognize that other limitations and capabilities may be imposed as well.

  The system administrator may use the device node of the administrator website 802 to submit and maintain information used for verification during application provisioning. For example, the system administrator may generate and maintain a list of device profiles corresponding to a particular device. Typically, the system administrator generates a device profile for each device supported by the MAS. New device profiles and corresponding device designations can be added if necessary. Each device profile includes, for example, the amount of run-time memory and flash memory, chip identification, maximum download size, and whether the device is “OTA” compliant (OTA is a Sun Microsystem broadcast compliance standard (Sun Microsystem 's Over The Air specification. Devices that follow OTA include hardware specific information and source characteristics such as tracking device successful downloads in common with other capabilities.

  Each device profile may also specify a single Java profile supported by the device. The Java® profile specifies the Java® API supported by the device. For example, the MIDP 1.0 standard (a well-known standard that defines a set of Java APIs implemented by devices) typically has a device profile that indicates this consistency. Device (and associated Java®) profiles are for comparison with applications to ensure that a particular device has resources and supports the set of APIs required by the application. Used by the provisioning manager during the verification process. Although the same Java® profile can be associated with multiple devices, a device can usually only support one Java® profile. The system administrator loads Java by specifying a set of APIs and specifying the name of the archive file (eg, a JAR file or a .zip file) to describe. The MAS tests a particular archive for a particular archive structure (package, class, method and field definitions) and generates a profile containing this structure. These profiles can also be used to generate application filters, which prevent applications using certain APIs from provisioning and / or downloading. Although primarily described in terms of Java-enabled devices and Java APIs, certain APIs, objects, classes, variables and / or other data structures exist in the application and are supported by the device MAS can be adapted to other language standards and devices capable of other languages, as long as the language supports determining whether or not, and the structure can be verified at the byte-code level Are recognized by those skilled in the art. Furthermore, those skilled in the art will recognize that these techniques can be employed for use at the source code level as long as the receiving application can compile or interpret the source and produce an executable file. ing.

  The administration website 802 allows system administrators to implement various security techniques and conventions that supplement and supplement the verification and inspection process provided by the provisioning and deployment manager. One such technique is the ability to define application filters, and as described, they are used to identify APIs that should not be invoked by applications using specific devices or other targets. It is done. These limited capabilities and structures can be identified during the application provisioning process in response to subscriber requests, and when an application is submitted by a content provider, the subscriber loads the wrong code on a particular device Helps to ensure not. Another security technology provided is the ability to change URLs. The system administrator may change the URL for MAS user convenience and safety by specifying a change URL mapping using the server node of the administration website 802. For example, a URL that points to an unauthenticated advertising site can be changed to a URL that provides an advertisement from a paying advertiser. Similarly, after removing the content, the system administrator wants to change the URL that previously referenced the content instead of an error message. Also, the modified URL can be used so that the application can be moved more easily to hide the actual location of the application. Upon receipt of incoming data, the MAS compares any URLs that identify the application with the list of modified URLs managed using the administration website 802 and modifies them if specified. To do. Additional and other security technologies may be added and utilized by the MAS, if necessary, configured via the administration website 802 to provide various secure mechanisms for subscribers, content providers, administrators, and various Communicate securely between different MAS components and securely deliver data stored in the MAS, accessible via the MAS, or stored on the client device. For example, as devices that support secure protocols such as KSSL are manufactured, various MAS components can be configured to use the protocol. Further, where applicable, the secure interface may be installed as a component between the web-based interface and the MAS component operated by the web-based interface.

  Administrator 800 also provides a personalization website 803, which is used by subscribers to order, maintain and display services and information associated with the subscriber and manage applications. Subscribers use the personalization website 803 to subscribe to additional categories of content by changing service plans (which may cause the user to change the amount charged). Once a new service plan is selected, the subscriber is then authenticated to use the associated content category.

  The subscriber may also manage the subscriber's application by observing the current application, adding an application, removing an application, and controlling the application. Although described with reference to applications, it is understood by those skilled in the art that these techniques can be applied to any downloadable content, and in addition to application-based management, applications can be managed by categories or other abstractions. Is aware. The subscriber may use the personalization website 803 to create and manage the subscriber's “personal access list” (“PAL”). The subscriber's PAL is, for example, a list of applications that the subscriber desires to have the MAS displayed on the subscriber's device during application discovery. This list may include an initial set of applications, or an initial set that does not include applications, or a list of applications that the subscriber has downloaded or desires to download in the future, or a combination thereof. . In one embodiment, the PAL initially includes what the subscriber downloaded. Because it maintains a record of application downloads for each wireless device and every wireless device, the MAS can track the subscriber's downloaded applications.

  The subscriber may also use the personalization website 803 to obtain and change account information and history of downloads or account activity.

  Via the personalization website 803, the system administrator may notify subscribers of the availability of updated or new applications, or “co-hosted events” (“tie-ins”). These allow the system administrator to display product offerings or advertisements (via “push” messages). The subscriber may access the personalization website 803 using the subscriber's wireless device or using a display wired device that preferably has excellent display characteristics via a wireless device (such as a personal computer). When wired devices with superior display characteristics are used to access the personalization website 803, the superior display characteristics can be used to support enhanced co-hosted events.

  In addition to providing various website-based user interfaces to existing MAS components, the MAS administrator component (eg, administrator 509 in FIG. 5) allows the system administrator to reprogram the components of the MAS itself. And by defining provisioning rules, customizable provisioning-related contracts can be implemented. In one embodiment, reprogramming is accomplished through the administrator website 802. However, it will be appreciated by those skilled in the art that this functionality can be achieved using other mechanisms, for example, by registering different components and profiles with the administrator through the registration mechanism, or by subclassing elements of the MAS interface. Is aware. This capability enhances the flexibility of subscribers, operators and system administrators when performing profile management, report generation and server administration when observing submitted applications.

  For example, a system administrator may use profile management and implement provisioning rules. Profiles provide an inherently dynamic data driven technique. By identifying various categories of services for subscribers, and groups of subscribers, provisioning rules can be customized individually by modifying various profiles, for example, using the administrator component's website interface. Or can be applied to a group of subscribers. Further, provisioning rules may be stored in a profile that is used to determine how a category of service is applied to individual subscribers and groups of subscribers. Provisioning rules can be modified by themselves.

  Profile management allows a high degree of flexibility when defining provisioning-related and billing-related service contracts. For example, a carrier may provide a subscription service that includes a basic service level and a premium service level. Basic service subscribers can be individually modified for each application that the subscriber downloads, while high-end service subscribers pay a higher monthly fee, but pay an additional fee. An unlimited number of applications can be downloaded. In another example, a company such as a bank negotiates with a carrier to set up a specific type of service. In this type of service, an enterprise customer may, for example, provide an enterprise with a specific application for one type of subscriber device that allows bank customers to view account balances and send funds. Downloadable. In this example, the carrier will host a subscriber profile for the company, and the company will be able to access this information using industry standard databases such as LDAP and related databases well known to those skilled in the art.

  The administrator 800 also provides the user interface necessary to govern other components of the MAS. Through these interfaces, system administrators can observe different modules of the MAS, manage server-side security, and monitor system status and server performance at any time. The system administrator may also manage subscriber accounts and assign various levels of administrative privileges. Server administrators also include features such as analysis tools for log management and troubleshooting purposes.

  In an exemplary embodiment, the method and system of a mobile application system is implemented in a wireless network with one or more general purpose computer systems and a typical client / server architecture and is designed and / or configured to operate in a distributed environment. obtain. Exemplary embodiments are designed to operate in a global network environment, such as a network environment having multiple subscriber devices that communicate with a MAS via one or more wireless networks.

  FIG. 12 is an exemplary block diagram of a multipurpose computer system and subscriber device for implementing an embodiment of a mobile application system. The computer environment of FIG. 12 includes a subscriber device 1201 and a multipurpose computer system 1200 that communicate via a wireless carrier 1208. Each block may represent one or more blocks suitable for a particular embodiment, and each may reside in a separate physical location.

  Subscriber device 1201 includes computer memory (“memory”) 1202, display 1203, input / output device 1204, and central processing unit (“CPU”) 1205. Shown is a Handset Administration Console 1206 that resides in memory 1202 with the downloaded application 1207. Handset administration console 1206 preferably runs on CPU 1205 and executes application 1207 currently in memory 1202 or from MAS 1209 via wireless carrier 1208 as described with reference to the above figure. Download the application.

  The general purpose computer system 1200 may include one or more server and / or client computing systems to bridge distributed locations. In one embodiment, the MAS is implemented using Java® Enterprise Edition (J2EE) and runs on a multipurpose computer system that provides a J2EE compliant application server. According to this embodiment, the MAS is designed and encoded using a J2EE multi-tier application architecture that supports server-side web, business, and database layers. Accordingly, the general purpose computer system 1200 represents a data repository of one or more servers and / or MASs that can execute one or more components.

  As shown, the multipurpose computer system 1200 includes a CPU 1213, a memory 1210, and optionally a display 1211 and input / output devices 1212. The components of MAS 1209 are shown to reside in memory 1210 along with other data repositories 1220 and other programs 1230, and preferably execute on one or more CPUs 1213. In the exemplary embodiment, MAS 1209 includes provisioning component 1214, data repository 1215 for storing profile and structure data, and application store 1216. As previously described, the MAS may include other data repositories and components that depend on the needs of the carrier or other host system and integration with the carrier or other host system. The provisioning component 1214 includes the components of the MAS illustrated in FIG. 5 and described with reference to FIG. With provisioning component 1214, MAS 1209 receives a request for discovery of downloadable application (s) and verifies the suitability of the request for use by a particular subscriber and a particular subscriber device. As a result, the requested application can be customized and the acquired application can be transmitted to the subscriber device 1201. The application store 1216 is a data repository that stores applications suitable for downloading to the subscriber device 1201. An application for quick download to the subscriber device 1201 may be provided in advance (“static provisioning”). That is, an application can be provided upon request (“dynamic provisioning”). Data repository 1215 provides data repositories and retrieval services to establish subscriber proficiency and device capabilities (hosting profiles used for profile management) and determine the appropriate application for each customer device To do.

  Those skilled in the art will recognize that MAS 1209 may be implemented in a distributed environment consisting of multiple highly heterogeneous computer systems and networks. For example, in one embodiment, provisioning component 1214 and application store 1215 are located on physically different computer systems. In another embodiment, the various components of provisioning component 1214 can be hosted on individual server machines and remotely located from data repositories 1215 and 1216. Different configurations and locations of programs and data for using the techniques of the present invention are contemplated.

  In the illustrated embodiment, the provisioning component 1214 is implemented using J2EE, as described in detail in Sun Microsystems' Java (R) 2 Platform (Enterprise Edition Specification, Version 1.2) in 1999. Incorporated herein by reference. Provisioning component 1214 includes a protocol manager, a provisioning manager, a deployment manager, a billing manager, and other components. FIGS. 13-28 describe various exemplary embodiments of specific routines implemented by each of these components, and implement the functionality described with reference to FIGS. 3-8. In the illustrated embodiment, these components may execute simultaneously and asynchronously. Thus, components can communicate using well-known message passing techniques. It will be appreciated by those skilled in the art that equal synchronization embodiments are also supported by the MAS implementation. Furthermore, those skilled in the art will recognize that other steps may be implemented for each routine, and still achieve further MAS functionality in different orders and different routines.

  FIG. 13 is an exemplary flow diagram of the processing performed by the protocol manager of the mobile application system to communicate with various subscriber devices over a changing wireless network using different protocols. (See, for example, protocol manager 503 in FIG. 5.) In step 1301, the protocol manager is initialized. In step 1302, the protocol manager determines whether there is an incoming data request from the subscriber device and if so, proceeds to step 1303, otherwise continues to step 1306. In step 1303, the protocol manager determines the protocol used for the incoming request by determining through which wireless network (or wire network) the request was sent, and the incoming request In the record associated with, the protocol for the determined pending request is stored. The association between the protocol record and the incoming request as processed by the system is maintained, for example, by storing a reference to the protocol record in the request message header. In step 1304, the protocol manager translates the incoming request for the originally used protocol (eg, HTTP). In step 1305, the protocol manager sends the converted request to a provisioning manager (eg, provisioning manager 504 in FIG. 5), after which the request processing step ends. In step 1306, the protocol manager determines whether there is an outgoing data request for the subscriber device, and if so, proceeds to step 1307; otherwise, the request processing step ends. In step 1307, the protocol manager retrieves the determined protocol associated with the incoming request corresponding to the output data. The determined protocol is the protocol used by the subscriber device that issued the request. In step 1308, the protocol manager encodes / converts the outgoing data message according to the determined protocol. In step 1309, the protocol manager sends the encoded outgoing data to the subscriber device that presented the request, after which the processing step ends.

  FIG. 14 illustrates a mobile application system for determining suitability of a requested application for a subscriber device and presenting the requested application to a device in a form that the subscriber device can decrypt. FIG. 10 is a flowchart illustrating an example of processing executed by a provisioning manager. (See, eg, provisioning manager 504 in FIG. 5.) In step 1401, the provisioning manager performs any needed initialization. In steps 1402-1413, the provisioning manager processes the MAS “instruction”. In step 1402, the provisioning manager determines the command (or download request) specified in the incoming request. In step 1403, the provisioning manager parses the incoming request to provide an extension, change or restriction of certain provisioning steps to be taken later, and dynamically as described with reference to FIG. The request is pre-processed by modifying the request or by inserting other parameter values for communication or configuration reasons. In step 1404, the provisioning manager determines whether the “command” is a download request, if so, continues to step 1404, otherwise continues to step 1408. Although currently implemented as another “type” command, they are essentially commands and perform command processing, even though the download request is indicated by specifying “URL” as a parameter. Those skilled in the art will appreciate that there are many equivalent program techniques to do this. In step 1405, the provisioning manager determines whether the requested application (content) MAS is known, and if so, proceeds to step 1406 to perform walled-garden provisioning, and so on. If not, the process proceeds to step 1407, and open provisioning is executed. In an exemplary embodiment, there are several ways in which content can be made known to MAS. That is, how a system administrator uses a website that provides and publishes applications, A method for presenting approved and published content, and a method for a subscriber to request a known application download from a trusted third party content provider known to the carrier that indirectly initiates the presentation process. Walled garden provisioning is further discussed in connection with Figure 15, and open provisioning is further discussed with reference to Figure 16. Once provisioning occurs at step 1406 or 1407, the request is made at step 1403. Post-processing On the other hand, if the designed command is a request for an application list in step 1408, the provisioning manager proceeds to step 1409 to perform application discovery or proceeds to step 1410. After application discovery, provisioning is performed. The manager proceeds to step 1413 to perform post-processing of the request, and in step 1409, if the command is a request for download history, the provisioning manager proceeds to step 1411 to retrieve the list of downloaded applications and proceeds to step 1413. In step 1412, if the command is some other MAS command, the provision The processing manager appropriately processes the command and proceeds to step 1413. In step 1413, the provisioning manager looks up instructions for directing other components of the MAS, as described in connection with FIG. Post-process the request by modifying the request it contains, thereby extending the functionality of other components or performing functions that modify other parameters, for example, a provisioning manager requests a download If an individual determines that a high-value advertiser's employee is a client, the provisioning manager may instruct the billing manager not to charge for this particular transaction. The other The process ends until a request is received.

  FIG. 15 is a flowchart illustrating an example of processing executed by the execution walled garden provisioning routine of the provisioning manager. (See step 1406 in FIG. 14.) In walled garden provisioning, the requested application checks for subscriber authority and subscriber device performance. Specifically, in step 1501, the provisioning manager retrieves the subscriber profile, device profile, and application profile corresponding to the requested application. In one embodiment, these profiles are retrieved by calling the profile reader 652 in FIG. In step 1502, the provisioning manager performs an application check to check if the requested application has been retrieved by the wireless carrier, for example because it includes a prohibited API. Application inspection is further described with reference to FIG. In step 1503, the provisioning manager performs a subscriber check to determine if the subscriber is authorized for the requested application, either by carrier billing agreement or otherwise. Subscriber authority is further discussed with reference to FIG. In step 1504, the provisioning manager performs device inspection to determine if the device has the resources specified by the application profile corresponding to the requested application and the required and other capabilities. Device authority is further discussed with reference to FIG. In step 1505, the provisioning manager performs a prepaid billing check, and if a prepaid billing is included in the system, the subscriber's savings are sufficient to charge for the application download, as described in connection with FIG. Check whether or not. In step 1506, the provisioning manager calls the deployment manager's provisioning interface and returns to the provisioning application.

  FIG. 16 is an exemplary flow diagram of processing performed by the provisioning manager's inspection application routine. (See step 1502 in FIG. 15.) In summary, the test application routine can download the application requested by the carrier (globally or based on other criteria such as subscriber identity, device, etc.). Judge whether the subject is forbidden). In step 1601, the routine requests and obtains a list of applications that the carrier has not given permission to download. This list is retrieved locally and updated periodically using, for example, the MAS query engine 650 of FIG. In step 1602, the routine searches the requested list for the requested application to determine if the application is forbidden. This provides, for example, a quick and robust way to prohibit downloading of applications that contain or are suspected of containing malicious code. This method provides a center-based approach (compared to a split approach where each device gets a “virus checker” and malicious application data files) to stop the growth of malicious applications. In step 1603, the routine determines whether the request is for a prohibited application, and if so, proceeds to step 1605, otherwise proceeds to step 1604. In step 1604, the request is logged and the routine returns to a successful state. In step 1605, the failed request is logged, a notification is sent to the subscriber, and the routine returns to the failed state.

  FIG. 17 is a flow diagram illustrating an example of processing performed by a provisioning manager's inspection subscriber routine. (See step 1503 in FIG. 15.) In summary, when a test subscriber routine is stored and saved by an administrator component in the profile (eg, administrator 509 in FIG. 5), the subscriber profile is grouped into content categories and Compare with the service plan definition and determine whether the subscriber is authorized to download the required application. Specifically, in step 1701, the routine determines from which communication carrier the request message has been received. In step 1702, the routine identifies the subscriber who sent the request. This can be accomplished, for example, by examining the request message for routing information. In step 1703, the routine establishes a connection with the determined carrier if the subscriber profile information is stored in the carrier, and in step 1704, the subscriber profile identified from the carrier. Take out. Those skilled in the art, for example, utilizing the profile reader 652 component of FIG. 6 to access the local data repository 511 of FIG. 5, subscriber profiles can be stored locally on the MAS and retrieved from the MAS. Understand what can be done. In step 1705, the routine examines the request to determine which application was requested. In step 1706, the routine determines whether the subscriber profile is authorized to download the required application. This determination can be accomplished, for example, by examining the service plan of the subscriber group to which the subscriber belongs to determine whether the application belongs to a content category associated with the service plan. In addition, the routine checks for the existence of forbidden applications that match the subscriber profile and, in turn, rejects the request if a match is found. If, in step 1707, it is determined that the request is authorized, the routine continues to step 1708; otherwise, it proceeds to step 1709. In step 1708, the request is logged and the routine returns to a successful state. In step 1709, the failed request is logged, a notification is sent to the subscriber, and the routine returns to the failed state.

  FIG. 18 is a flowchart illustrating an example of processing executed by the inspection device routine of the provisioning manager. (See step 1504 in FIG. 15.) In summary, the test device routine compares the device profile associated with the subscriber device to the application profile for the requested application and the resources required by the application. Check whether it is available according to the device profile. In step 1801, the routine identifies the type of subscriber device that received the request. One skilled in the art understands that this information can be determined in protocol negotiation and typically extracted from routing information stored in the request message. In step 1802, the routine determines the performance of the subscriber device by accessing an already stored device profile associated with the identified device. In one embodiment, the device profile is retrieved utilizing the profile reader 652 of FIG. If a device profile is not found for the identified device, the event is logged and the system administrator is notified accordingly. (In one embodiment, when a subscriber registers with a carrier to obtain a phone number, the carrier knows the particular type of device used by each subscriber. Should preferably ensure that all registered device types are supported by the device profile.) Device profiles include memory capacity, processor type, processing speed, minimum size for downloadable applications, etc. Includes information related to the performance of the subscriber device. In step 1803, the routine determines the requirements for the requested application by retrieving and examining the application profile corresponding to the requested application, as already generated by the administrator component. The application profile includes requirements for running the application, including the amount of memory required, API calls generated, minimum processor speed, and so forth. Requirements can also be specified in the application profile, depending on the type of subscriber device supported. In step 1804, the device performance is compared to the required application requirements by comparing the device and application profile. In step 1805, the routine determines whether the device is capable of executing the requested application, and if so, proceeds to step 1806, otherwise proceeds to step 1807. In step 1806, the request is logged and the routine returns to a successful state. In step 1807, the failed request is logged, a notification is sent to the subscriber, and the routine returns to the failed state.

  FIG. 19 is a flowchart illustrating an example of processing executed by an execution open provisioning routine of the provisioning manager. (See step 1407 in FIG. 14.) In steps 1901 and 1902, the provisioning manager needs to determine if a cached provision application is already available or there is a cached provision application. If not, the process proceeds to step 1903; otherwise, the process proceeds to step 1904. This scenario can occur, for example, if the application is previously requested and provided, even if it is not trusted or even from an unknown source. In step 1903, the provision application is returned. Alternatively, if a provision application is not found, at step 1904, the routine retrieves the application using the indicated URL provided in the request message. This application may have been previously processed by the MAS and thus may already have a corresponding application profile. Accordingly, in step 1905, the routine determines whether a corresponding application profile exists, and if so, proceeds to step 1907, otherwise generates a new application profile in step 1906 and proceeds to step 1907. In step 1907, the routine performs a device check by comparing the application profile with the device profile corresponding to the device type of the subscriber's request. In step 1908, the routine calls the deployment manager's provisioning interface to provide an untrusted application and returns to the provision application in step 1909.

  FIG. 20 is a flowchart illustrating an example of processing executed by the execution application discovery routine of the provisioning manager. (See step 1409 in FIG. 14.) There are two basic types of application discovery. A system that provides a search for applications that match criteria specified by a subscriber and an application list based on stored subscriber preferences. Specifically, in step 2001, the routine determines whether or not the user has specified a search determination criterion. If so, the routine proceeds to step 2002, and if not, the routine proceeds to step 2004. In step 2002, the routine searches the application store (application data repository) and queries the application (content) that meets the specified criteria. Exemplary criteria include category, amount, gender, age, etc. In step 2003, the list is initially set to these query results and continues to step 2007. In step 2004, the routine determines whether there is an available personal access list ("PAL"), and if so, proceeds to step 2005 and first sets the list to the determined PAL, otherwise. In step 2006, the list is first set to a default value. In step 2007, the MAS adds the defined set of applications to the initial list (known as the start deck). The start deck essentially allows the MAS to reserve a slot for an application discover session, for example, for a high-income advertiser. In step 2008, the routine calls the test subscriber routine for each initial application on the list, as described in connection with FIG. Any application that has not gone through any one of the filtering steps 2008-2009 is filtered from the list before the next step in the process. In step 2009, the routine calls a test device for each initial application on the list, as described with reference to FIG. In step 2010, the routine generates XML for the internally standardized format, and in step 2011 converts the contents of this list to the appropriate language corresponding to the subscriber device.

  FIG. 21 is an exemplary flow diagram of a process performed by a mobile application system deployment manager to provide a provision application in response to a request by a subscriber and system administrator. (See, for example, deployment manager 506 in FIG. 5.) The system administrator can pre-populate popular applications for popular devices to minimize the time required to respond to subscriber requests. May be provided (provided statically) and requested to be cached. Alternatively, all applications can be served dynamically and selectively cached. In step 2101, the deployment manager is initialized. In step 2102, the deployment manager evaluates the request to determine the identity of the requested application. In step 2103, the deployment manager calls an acquisition provision application routine to control content retrieval and generate provisioning, as further described with reference to FIG. In step 2104, the deployment manager determines whether a request is generated by the system administrator to begin storing the provision application, and if so, proceeds to step 2105; Proceed to In step 2105, the deployment manager stores the provision application in the cache, the carrier's application store, or the server of the remote application host, and ends the process. In step 2106, the deployment manager sends the provision application to the provisioning manager and then ends the process.

  FIG. 22 is an exemplary flow diagram of processing performed by a deployment manager acquisition provision application routine. (See step 2105 in FIG. 21.) In summary, the deployment manager retrieves, inspects, optimizes, and prepares application code according to the current conventions implemented in the MAS. In step 2201, the routine examines some type of index to determine if a pre-provisioned version of the application exists at a known location in the MAS. The manner in which this information is stored relates to how the cache and / or data repository is implemented. Well-known techniques for implementing caches using local fast data stores and indexes can be utilized. An application can be predefined and stored if it is expected that a large number of requests will be generated for applications that require the same provisioning requirements. This can occur, for example, when a large number of users with the same type of subscriber device request the same application. In such a case, the application is provided in a cache and stored (and retrieved when a request is generated by a user having a subscriber device to which the application is provided) or other MAS data. It can be stored in a repository. In step 2202, if there is a pre-provisioned version of the application, the routine proceeds to step 2203, otherwise proceeds to step 2207. In step 2203, the location of the pre-provision application is determined. In step 2204, the routine determines whether the pre-provision application is stored locally, and if so, proceeds to step 2205, otherwise proceeds to step 2206. In step 2205, the routine retrieves the application locally (typically from the carrier's application store, which can be located in the MAS or at the carrier's premises) and returns. In step 2206, the routine retrieves the application from the remote application host (eg, a third party server) and returns. On the other hand, if, in step 2202, the routine determines that there is no application for which a pre-provision version is required, in step 2207, the routine determines the location of the unprovided application that has not been processed. In step 2208, the routine determines whether the application code is stored locally, and if so, proceeds to step 2209, otherwise proceeds to step 2210. In step 2209, the routine retrieves the application code from the carrier's application store or other local storage. In step 2210, the routine retrieves the application code from the remote application host. In step 2211, the routine provides the retrieved application and returns, as further described in connection with FIG.

  FIG. 23 is a flow diagram illustrating an example of processing performed by the provision manager's provision application routine. In step 2301, the provision application routine examines the application as further described in connection with FIG. In step 2302, the routine optimizes the application as further described with reference to FIG. In step 2303, the routine installs instrumentation in the application as further described in connection with FIG. In step 2304, the routine packages the application in a form suitable for delivery and returns, as further described in connection with FIG.

  FIG. 24 is a flowchart illustrating an example of processing executed by the inspection application routine of the deployment manager. (See, for example, step 2301 in FIG. 23.) In step 2401, the routine is required to identify an API that includes packages, classes, methods, and fields, or other suitable structures. If so, disassemble / decrypt the structure of the application. If the application is coded in Java, the check can be performed on the binary program and there is no need to insert a source code level check into the application itself for the generated debugging / logging information. The set of inspection steps is described as an example of steps 2401-2405. However, those skilled in the art will appreciate that other inspection steps may be suitably applied in addition to or as an alternative to those described herein. In step 2402, the routine retrieves any application filters (requested application, requesting subscriber, application content provider, and global filter) associated with the potential target under examination. In one embodiment, these filters are stored in the MAS data repository, but they can be stored in any known location. In step 2403, the routine checks the malicious and prohibited code from the retrieved application by comparing the disassembled code with stored instructions in the prohibited data structure. In step 2404, the routine determines the number, type, and frequency of API calls present in the code and checks whether they are compatible with system administration requirements that can be stored in the application filter. In step 2405, the routine performs a flow analysis of the dismantled application and determines whether the number of threads to be executed is within the requirements of the system administrator. This flow analysis can be accomplished using techniques such as generating a directional graph of code and applying well-known graph analysis algorithms. Those skilled in the art will appreciate that other checks can be performed on the retrieved application. In step 2406, the routine determines whether the retrieved application has undergone a check, and if so, returns to a successful state; otherwise, the routine flags a failed state and returns to a failed state.

  FIG. 25 is a flowchart illustrating an example of processing executed by the optimization application routine of the deployment manager. (See, for example, step 2302 in FIG. 23.) Those skilled in the art will understand that any well-known code optimization technique can be incorporated into this routine, and what is shown is an example. In step 2501, the routine shortens the variable names included in the retrieved application in order to reduce the required application file size. In step 2502, the routine maps the executable path of the retrieved application. In step 2503, the routine removes any unused code and continues similar optimization steps to reduce the length of the file. When optimization is complete, the routine returns.

  FIG. 26 is a flowchart illustrating an example of processing executed by the installation instrumentation routine of the deployment manager. (See, eg, step 2303 in FIG. 23.) In step 2601, the routine retrieves the identified subscriber profile, typically from a local data repository, utilizing, for example, profile reader 652 in FIG. Take out. In step 2602, the routine determines the operator's contract for the identified subscriber in utilizing the requested application. For example, some subscribers may be allowed to use the application on a reservation or trial basis, but others are not. As described above with reference to FIG. 7, instrumentation implements certain conventions. For example, an instrumentation can provide a code wrapper that allows a provision code to be executed a limited number of times or a given time period. In step 2603, the routine installs instrumentation in the required application according to the determined carrier convention, and then the routine returns. In an exemplary embodiment, the installation instrumentation routine utilizes code instrumentation techniques to insert new code or modify existing code in the application at the binary code level. The code provided may be provided directly by the installation instrumentation routine or may be retrievable from other data storage (eg, data storage associated with different carrier agreements).

  FIG. 27 is a flow diagram illustrating an example of processing performed by the deployment manager's packaging application routine. (See, for example, step 2304 of FIG. 23.) In step 2701, the routine accesses the retrieved subscriber device profile to determine if the file format is compatible with the identified subscriber device. Judging. In step 2702, the routine determines whether the subscriber device can read the compressed file, and if so, proceeds to step 2703, otherwise proceeds to step 2704. In step 2703, the routine compresses the provision application to minimize the transmission time and the number of bytes transmitted. In step 2704, the routine utilizes the determined file format by encapsulating a provision application with sufficient information to allow a handset administration console to run on the wireless device that extracts the application. Package the application. (See, for example, the handset administration console of FIG. 2.) As noted above, one format that is implemented by many Java-enabled wireless devices is a compressed JAR file. However, in some cases, the application needs to be distributed to the device in smaller packets, which reassembles for installation work on the wireless device. The billing manager also relies on the encapsulation of information for billing and routing purposes, as described below with reference to FIG. After the application is packaged, the routine returns.

  FIG. 28 is an exemplary flow diagram of processing performed by the billing manager of the mobile application system. (See, eg, billing manager 507 in FIG. 5.) In step 2801, the billing manager is initialized. In step 2802, the billing manager determines whether there is time to generate a billing report, and if so, proceeds to step 2803, otherwise proceeds to step 2804. In an alternative embodiment, the billing manager may respond to an administrative query, eg, from an administrator component, to generate a billing report. In step 2803, the billing manager generates a billing report based on the set of parameters by the system administrator. In step 2804, the billing manager determines whether there is a request for log provisioning information (for billing purposes) and if so, proceeds to step 2805, otherwise returns. In step 2805, the billing manager sends a request that relates the status of the billing (eg, the identity of the user making the request, the category of the request, the size of the requested download, etc.) and the system variables (eg, date, date, etc.). Log parameters and use them for future billing. For example, the length of the application, the time the application was requested, the time required to process the application, and the number of applications can be utilized in generating the billing report. Further, if prepaid billing is supported, the billing manager generates an accounting request to the carrier and appropriately reduces the subscriber's prepaid billing amount. After the billing report is generated and the appropriate parameters are logged, the billing manager returns.

付録（ＡＰＰＥＮＤＩＸ）Ｅ
ワイヤレスアプリケーション環境におけるパケットレベル請求の方法およびシステム

本発明は、ワイヤレス環境のための方法およびシステムに関する。詳細には、本発明は、ワイヤレスアプリケーションのパケットレベルにおいて情報を請求するおよびロギングする方法およびシステムに関する。

Appendix (APPENDIX) E
Method and system for packet level billing in a wireless application environment

The present invention relates to a method and system for a wireless environment. In particular, the present invention relates to a method and system for soliciting and logging information at the packet level of wireless applications.

Embodiments of the present invention provide computer-based and network-based methods and systems for packet-type billing and other types of statistics collection and logging at the packet level (“packet-level billing system”) in a wireless application environment. provide. Some exemplary embodiments are described in detail in Appendix A. Appendix A is hereby incorporated by reference in its entirety. Although methods and systems are described for use in collecting and logging billing information so that airtime is not only the statistics used to determine billing for wireless applications, these are described. Those skilled in the art will recognize that any of these mechanisms can be used to log other types of statistical information, such as other time and usage information. Instead of providing a server-side implementation that implements the billing server convention by using other statistics, any type of data collection convention is described in the standard, API, and / or Appendix X. Can be implemented by other code.

  The packet level billing system may be implemented in an inconvenient or non-conventional manner, thereby causing a portion of code to be modified to include packet level billing and packet level billing generation. The code that notices that the code is called, allowing various degrees of flexibility. Some methods may also collect and generate bills (or any other type of logging information) without the network application developer being aware. Methods and systems include “write to standard” solutions, library solutions, device software (driver) modification solutions, and instrumentation solutions.

From the foregoing, it will be appreciated by persons skilled in the art that specific embodiments of the present invention have been described herein for purposes of illustration and that various modifications may be made without departing from the spirit and scope of the present invention. Has been. For example, those skilled in the art will recognize that the methods and systems described herein are applicable to the collection and generation of any type of application data. The methods and systems described herein differ in protocols, communication media (optical, wireless, cable, etc.) and client devices (eg, wireless handsets, electronic organizers, portable email machines, game consoles, pagers, GPS reception) It is recognized by those skilled in the art that the present invention can be applied to navigation devices such as containers.

Appendix X

Packet-level billing
For network applications in a wireless environment

極秘
（パケットレベルの請求 ページ１／１６）

目次
定義・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・３
非ネットワークアプリケーション・・・・・・・・・・・・・・・・・・・・・・３
ネットワークアプリケーション・・・・・・・・・・・・・・・・・・・・・・・３
サーバ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・３
クライアント・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・４
背景・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・５
要約・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・６
ネットワークアプリケーションのための４ｔｈｐａｓｓ請求ソリューション・・・・７
「仕様書にあわせて書く」ソリューション（侵入型）・・・・・・・・・・・・・・９
プロキシの保存および転送アプローチ・・・・・・・・・・・・・・・・・・・・９
ライブラリソリューション（侵入型）・・・・・・・・・・・・・・・・・・・・１０
プロキシの保存および転送アプローチ・・・・・・・・・・・・・・・・・・・１０
計算およびログアプローチ・・・・・・・・・・・・・・・・・・・・・・・・１１
デバイスソフトウェア修正ソリューション（非侵入型）・・・・・・・・・・・・１２
プロキシの保存および転送アプローチ・・・・・・・・・・・・・・・・・・・１２
計算およびログアプローチ・・・・・・・・・・・・・・・・・・・・・・・・１３
計装ソリューション（非侵入型）・・・・・・・・・・・・・・・・・・・・・・１３
ＤＮＳに基づくサーバ側インプリメンテーション・・・・・・・・・・・・・・・１４
異なるソリューションの比較・・・・・・・・・・・・・・・・・・・・・・・・１５
（パケットレベルの請求 ページ２／１６）

定義
アプリケーションタイプ
本文書の目的に沿って、ワイヤレスデバイス上で実行し得るアプリケーションは、２つのカテゴリーに分割される。

Top Secret (Packet Level Billing Page 1/16)

Table of Contents Definitions ... 3
Non-network application ... 3
Network application ... 3
Server ... 3
Client ... 4
Background ... 5
Summary ... 6
4thpass billing solution for network applications ... 7
"Writing in accordance with the specification" solution (intrusive) ... 9
Proxy storage and forwarding approach ... 9
Library solution (intrusive) ... 10
Proxy storage and forwarding approach ... 10
Calculation and log approach ... 11
Device software correction solution (non-intrusive) ... 12
Proxy storage and forwarding approach ... 12
Calculation and log approach ... 13
Instrumentation solution (non-intrusive) ... 13
Server-side implementation based on DNS ... 14
Comparison of different solutions ... 15
(Packet level billing page 2/16)

Definitions Application types For purposes of this document, applications that can run on wireless devices are divided into two categories.

Non-network applications These types of applications do not communicate over the network when operating. These applications do not send any data to the network or receive any data from the network.

Examples: address book, calculator, text editor, etc. Network applications These types of applications use some kind of network communication to access other applications / devices / services on the network when running. These applications send / receive messages over the network.

Example: browser, email client, chat program, calendar, etc. Server For the purposes of this document, a server typically provides specific data or services to a client (not necessarily mapped to server hardware). Software). The function of a given server is used to identify the server. For example, a billing server (generating billing data and / or logging), a proxy server (acting as a proxy in communication with other servers), etc.
(Packet level billing page 3/16)

Client For purposes of this document, “client” is used to mean a network application running on a wireless device and communicates with a server in the traditional “client-server” sense.
(Packet level billing page 4/16)

Background Typically, when a wireless device user uses airtime or when a user downloads any application or any other data to the device, the wireless device user is subject to the terms of the carrier. Will be charged. All current solution families provide a means of billing the user for airtime and the total amount of data downloaded on the device. Software level or hardware that enables a carrier to charge a customer for the use of a specific network application or part of an application on a wire device based on data transmitted or received by the specific application There is currently no solution available at the wear level.
(Packet level billing page 5/16)

Summary 4thpass proposes a set of solutions for determining the use of data for a particular network application at the data packet level (ie, data packets transmitted and received by wireless devices). These solutions allow operators to reveal billing conventions that consider not only the data transmitted and received but also the application in question.

  Network applications make use of lower level communication protocols such as TCP / IP and UDP / IP and higher level protocols such as HTTP and WAP (Wireless Application Protocol). The proposed solution is a general solution and works for any communication protocol. The implementation of a particular solution is protocol specific and application language specific.

  The different solutions proposed in this document require different types of support on the device (where the application resides) and the billing server (where billing specific data is generated and / or logged). This document describes a different solution to achieve the goal of generating packet level information for each application so that users can be charged based on data sent / received as an alternative or addition to the airtime billing convention. Describe the different ways to implement.

Complete solutions for providing packet-level billing include client-side solutions and server-side solutions. Depending on the solution, billing information is generated by either the client or the server. The billing server eventually collects data size / data packet information based on which billing records are generated.
(Packet level billing page 6/16)

4thpass billing solutions for network applications 4thpass proposes the following categories of solutions for generating billing data in response to data transmitted and received by applications running on the device. Each solution category provides a different way to implement the solution.

    1. “Write to Specification” Solution: Network application developers use the specification provided by 4thpass to write their code. The specification dictates how to write the network communication portion of the code in order to generate appropriate billing information at the packet level.

    2. Library solutions: Network application developers utilize a specific set of application programming interfaces (APIs) that generate billing information provided by 4thpass in the form of software libraries to write applications. This solution is an extension of the previous solution.

    3. Device software modification solution: The device manufacturer modifies the network function software layer on the device to generate billing information.

    4). Instrumentation solution: The software automatically uses the billing API to generate billing information invisible to the user (without changing the application functionality) before the application is installed on the device. Scan and correct.

  Roughly speaking, the solution can be further divided into two categories, depending on whether application developers must write code in a specific way or use specific tools. .

1. Intrusive: The first two categories of solutions described above, namely “solutions to write to specifications” and “library solutions”, are intrusive solutions. Application developers must either code in a specific way to generate packet-level billing information, or use a special application programming interface (API).
(Packet level billing page 7/16)

2. Non-intrusive: The third and fourth categories described above, namely “device software modification solutions” and “instrumentation solutions”, are non-intrusive solutions. Developers do not have to do anything special while writing developer applications. Instead, the tools provided by 4thpass have the ability to automatically generate the required packet level billing.

All categories, intrusive and non-intrusive, good and bad, and their specific server-side solutions are described in detail in this document. Each category of solutions then proposes various mechanisms to achieve the required functionality.
(Packet level billing page 8/16)

“Writing to the specification” solution (intrusive)
This solution requires 4thpass to provide detailed specifications to application developers by describing how to write application code.

  The specification provides information on how to write application code to generate the required billing information. Developers must write code in a specific format and in a specific order to meet specific guidelines so that billing information is properly generated.

  When writing to this specification, the following proxy-based mechanisms can be used to generate billing information.

Proxy storage and forwarding approach The code for an application is written to communicate with a given proxy server. The data is transmitted to the proxy server in a predetermined format (including destination information and data to be transferred). The proxy server reads predetermined data (stored in a known format), extracts information necessary for accurately communicating with the transmission destination from the data, and transfers the data to the transmission destination.

    Data transferred to the destination displays the proxy server as the source of reception, thus allowing reverse communication from the destination. When receiving data from the transmission destination, the proxy server determines the original sender and transfers the received data to the original sender.

While transferring data back and forth, the data size / data packet information transmitted and received can be used later in generating billing information, for example (further acting as a billing server). Logged by a proxy server) that forwards or forwards the information to the billing server.
(Packet level billing page 9/16)

ライブラリソリューション（侵入型）
「ライブラリソリューション」は、「仕様書にあわせて書くソリューション」の拡張である。アプリケーション開発者に仕様書を提供するのではなく、開発者は、プロキシサーバ／請求サーバとユーザに見えないように相互通信するソフトウェアライブラリ、すなわち、所定のアプリケーションプログラミングインターフェイス（ＡＰＩ）のセットを提供される。開発者は、ＡＰＩを利用する際にまだ特定のガイドラインのセットに従わなくてはならないが、元にある仕様書は、ＡＰＩの手段に取得され、開発者は、仕様書をサポートするために広範囲に努力する必要がない。

Library solution (intrusive)
“Library solution” is an extension of “Solution written according to specifications”. Rather than providing specifications to the application developer, the developer is provided with a set of software libraries, ie a predetermined application programming interface (API), that communicates with the proxy / billing server invisible to the user. The Developers still have to follow a specific set of guidelines when using the API, but the original specification is captured by the API means, and the developer has extensive coverage to support the specification. There is no need to make efforts.

  Library solutions can be utilized to support two different types of implementations by providing different and / or multiple libraries.

Proxy Save and Forward Approach Code for an application is written using a predetermined set of APIs. This approach is different from the library provided to application developers, except that it implements and encapsulates communication with the proxy server (between receiver and destination) using different APIs. This is the same approach as described in “Solutions to be written according to specifications”.

Existing APIs allow developers to develop code without having to know complex specifications and library code implementations.
(Packet level billing page 10/16)

In this approach, the server generates billing information (and logs).

計算およびログアプローチ
ライブラリメカニズムの別のインプリメンテーションは、ユーザに見えない請求情報のロギング／生成を提供する。本アプローチは、元のネットワークがデバイス間の直接の通信を許可する場合に、有用である。本インプリメンテーションでは、クライアントアプリケーションに対して飽和した双方向の通信量を扱うためにプロキシサーバを利用するのではなく、請求サーバは、請求データ（すなわち、パケットサイズ／パケットの数など）が送信されるのみであり、クライアントおよびサーバ間のアプリケーションデータの通常の通信が続く。

Computational and Logging Approach Another implementation of the library mechanism provides logging / generation of billing information that is not visible to the user. This approach is useful when the original network allows direct communication between devices. In this implementation, the billing server sends billing data (ie, packet size / number of packets, etc.) rather than using a proxy server to handle saturated bi-directional traffic for client applications. Only followed by normal communication of application data between the client and server.

In particular, the library API hides the implementation of the logging code and here operates differently than the “proxy store and forward approach”. Rather than receiving the data to be sent to the proxy server (and receiving the next data coming back from the proxy server), the library API that executes in the application is invisible to the application program so that the data size / Determine the number of packets and send this information to the billing server. Communication with the destination device or any external server is performed directly.
(Packet level billing page 11/16)

デバイスソフトウェア修正ソリューション（非侵入型）
本アプローチは、パケットレベルの請求を提供するために、特定のデバイスのネットワーキングソフトウェアドライバ（ネットワーキング接続性を提供する義務のあるデバイス上のソフトウェア）の開発者４ｔｈｐａｓｓと一緒に仕事をすることを要求する。本アプローチを利用して、４ｔｈｐａｓｓは、ネットワーキングソフトウェアドライバと一体化される専用のソフトウェアの断片を提供する。専用のソフトウェアの断片は、プロキシアプローチまたは「計算およびログ」アプローチのどちらが取られるかに応じて、異なる機能を提供する。これらのアプローチは、ネットワークアプリケーション開発者がどんな特定の方法によってコードを書く必要も、どんな仕様に従う必要もないこと以外は、先の２つのセクションにおいて記載されたアプローチと同じである。代わりに、ネットワーキング通信ドライバコードは、請求特定機能を提供するための責任を負う。

Device software fix solution (non-intrusive)
This approach requires working with the developer 4thpass of a specific device networking software driver (software on the device that is obligated to provide networking connectivity) to provide packet-level billing . Using this approach, 4thpass provides a dedicated piece of software that is integrated with the networking software driver. Dedicated software fragments provide different functions depending on whether a proxy approach or a “computation and logging” approach is taken. These approaches are the same as the approaches described in the previous two sections, except that the network application developer does not need to write code in any particular way or follow any specifications. Instead, the networking communication driver code is responsible for providing the billing specific function.

  Proxy store and forward approach

（パケットレベルの請求 ページ１２／１６）

計算およびログアプローチ

(Packet level billing page 12/16)

Calculation and logging approach

計装ソリューション（非侵入型）
計装ソリューションは、「ライブラリ」および「仕様書にあわせて書く」ソリューションをあわせたものである。本アプローチを利用して、アプリケーション開発者によってではないが、請求仕様書に書かれるＡＰＩが、ネットワークアプリケーションに付加される。

Instrumentation solution (non-intrusive)
An instrumentation solution is a combination of a “library” and a “write to specification” solution. Using this approach, an API written in the billing specification, but not by the application developer, is added to the network application.

  Specifically, 4thpass provides an automated software tool that can read network applications and modify binary images (eg, bytecode in J2ME) to include the appropriate API. An implementation that can modify a binary image (eg, bytecode in J2ME) on the fly by adding, modifying, or erasing existing binary code (eg, bytecode format in J2ME). Support.

  Thus, by automatically implementing the implemented code, the network program can meet any specification and provide the required billing solution.

Apply all server-side implementations discussed in the previous section (eg, proxy storage and forwarding, and computation and logging). Just prior to installing the network application on the device, the network application is run with a 4thpass binary scanner and instrumentation.
(Packet level billing page 13/16)

The scanner determines which network APIs are used and automatically replaces them with new networking APIs. The new networking API provides the same functionality as the original functionality, except that it also generates billing specific information.

一旦、修正されたアプリケーションが実行されると（アプリケーション’）、アプリケーション’は、元のネットワーキングＡＰＩを利用するが、これらのＡＰＩは、適切な請求情報を生成する／ログをとる拡張された機能を提供する。

Once the modified application is executed (application '), the application' utilizes the original networking APIs, but these APIs have extended functionality that generates / logs the appropriate billing information. provide.

In the above diagram, the application represents the version of the network application processed in the previous 4th pass, while the application 'represents the version processed in the later 4th pass. Server-side support is the same as the “proxy storage and forwarding” or “calculation and logging” approach (see, for example, the diagram described in the “Library Solutions” section).
DNS based on server-side implementation
In order to support packet level billing at the client in certain cases, a solution based DNS is implemented on the server. This solution is useful for allowing devices or programs from external networks (such as those using public IP) to access devices inside the network using private IPs that cannot be discovered. In this way, incoming data packets (to the network application) can be counted and application billing information can be further generated.

Since the device or program from the external network is on a completely different network, and data from the private IP that is not discovered cannot be sent to the program using the public IP, this attempt is made from the device from the external network. Or providing a means for the program to communicate with the internal device.
(Packet level billing page 14/16)
The 4thpass solution enables such communication by providing a dedicated DNS server implementation on the carrier side. The carrier side works with the public IP pool (s), and the public IP is dynamically mapped to the internal network private IP. A DNS server manages a virtual communication link between two endpoints by providing network address translation (NAT).

More information is available in a separate document and describes the technology that implements this solution.
Comparison of different solutions Each of the different solutions has advantages and disadvantages. Spec-based solutions are relatively easy to manage because they do not require distribution of library software, while specifications are more difficult to understand and comply with when compared to software libraries. . Using the library, the network application developer calls the API without knowing what is happening under the hood.

  Comparing both, modifying networking software drivers to provide the same functionality is relatively easy to implement and manage from the application developer's perspective. However, managing different devices becomes more difficult and driver modifications need to be applied separately to each. Support for different APIs in a scalable and error tolerant manner can be difficult to maintain. Furthermore, it may be difficult to convince the authors of many networking device drivers to include 4thpass code.

Comparing the above approaches, the instrumentation approach is the most flexible and scalable. The instrumentation approach provides the flexibility and benefits of the aforementioned solution. API software libraries are written to specifications (added dynamically to network applications after they are scanned) and network application developers understand how they are written There is no need. Also, the developer does not need to know that a library API should be added. Instead, when scanning an application already written by an application developer, the 4thpass tool examines the application for use of the network API (regardless of protocol).
(Packet level billing page 15/16)

Simultaneously with the detection of the network API, the 4thpass tool replaces the detected network API with a predetermined set of APIs that implement various specifications. The solution does not require any invention on the part of the application developer. In addition, implementation management is relatively easy because the implementation is hidden from the developer (even if it is made public). In addition, even when older solutions are in place, the implementation can be changed and extended, allowing the optimal solution to be implemented. Lastly, automatic steps generally have a lower error tendency than manual steps, so the error tendency is lower, although not the lowest.
(Packet level billing page 16/16)

FIG. 1 is a schematic block diagram of a billing system based on an exemplary transmission. FIG. 2 is an exemplary block diagram of content provided with a billing tracking code when executed by a content (code) modifier of a packet-based billing system. FIG. 3 is a block diagram of an exemplary transmission based billing system implemented in an exemplary mobile application system. FIG. 4 is an exemplary block diagram of a general-purpose computer system and client device for performing an embodiment of a billing system based on transmission. FIG. 5 is a block diagram of an exemplary procedure for transferring an application to a mobile application system for use with transmission-based billing. FIG. 6 is an exemplary block diagram illustrating an overall process for delivering an application that supports transmission-based billing in an unrecognized manner to client devices using a mobile application system. FIG. 7 is an exemplary flowchart of a routine for modifying an application to support transmission-based billing. FIG. 8 is an exemplary flowchart of a routine for analyzing and providing an application with assistance for billing based on transmission. FIG. 9 is an exemplary block diagram illustrating the overall process for communicating with billing data based on network transmission data on a per application basis. FIG. 10 is an exemplary flowchart of a client routine for transferring data modified to collect and transmit billing data to the network. FIG. 11 is an exemplary flowchart of a client routine for receiving data modified from a network to collect and transmit billing data. FIG. 12 is an exemplary flowchart of a server routine for processing billing data based on forwarded transmissions. FIG. 13 is an exemplary flowchart of steps for generating a billing fee based on billing data based on transmission.

Claims (62)

A method for providing billing based on transmission of content over a network in a computer-based environment, the content including at least one network call, the method comprising:
Determining the billing tracking code,
Modifying the content by incorporating the determined billing tracking code into the content by replacing the at least one network call included in the content with a proxy call that includes the determined billing tracking code And when the modified content is executed on a target device, the billing tracking code is automatically based on the amount of data transmitted between the modified content and the network. , Communicating billing data , and
The method wherein replacing the at least one network call with the proxy call is performed prior to sending the content .   The method of claim 1, wherein the billing tracking code tracks the amount of data transmitted from the embedded content over the network.   The method of claim 2, wherein the network is the Internet.   The method of claim 2, wherein the amount of data is tracked at a logically defined packet level.   The method of claim 1, wherein the billing tracking code tracks the amount of data received by the embedded content from the network.   The method of claim 5, wherein the network is the Internet.   The method of claim 5, wherein the amount of data is tracked at a logically defined packet level.   The method of claim 1, wherein the content is Java® based.   The method of claim 1, wherein the content includes a bytecode instruction.   The method of claim 1, wherein the incorporating is accomplished at a bytecode level of content inspection.   The embedded content includes a security key, which is transmitted with automatically communicated billing data so that the integrity of the source of the billing data can be verified. the method of.   The method of claim 11, wherein the security key is based on a random number.   The method of claim 11, wherein the security key is application and subscriber specific.   The method of claim 11, wherein the security key is incorporated into the content upon receiving a request to download the content.   The method of claim 1, wherein the environment is integrated with a wireless carrier infrastructure.   The method of claim 1, further comprising allowing the embedded content to be downloaded to a target device via a wireless transmission medium.   The method of claim 16, wherein the content is requested by a carrier subscriber from the computer-based environment via a wireless transmission medium.   The method of claim 1, further comprising allowing the embedded content to be downloaded to a target device via a wired transmission medium.   The method of claim 18, wherein the wired transmission medium is the Internet.   The method of claim 1, wherein the billing data includes at least one of an amount of data sent, an amount of data received, a time stamp, an application identifier, a security key, a transaction identifier, and a retry time limit indicator.   The method of claim 1, wherein the billing data is automatically communicated with reference to transmission to a billing server system.   22. The method of claim 21, further comprising transmitting data, wherein the data is not direct billing data between the subscriber's device and a server system that is not a billing server system.   The method of claim 1, further comprising integrating the billing data into customer-based billing information that generates a customer data record.   The method of claim 1, wherein the billing data is used to support a plurality of billing policies.   25. The method of claim 24, wherein the billing policy includes a promotional offer that provides a reduced fee for a specified application.   The method of claim 24, wherein the billing policy is provided by a content provider.   The method of claim 1, wherein the billing data is used to provide a royalties payment to the content provider.   The method of claim 1, further comprising allowing data transmitted between the embedded content and the network to be routed according to billing data based on the automatically communicated transmission. Method.   30. The method of claim 28, wherein the routing allows for efficient use of resources on the network.   30. The method of claim 28, wherein priorities are assigned to content based on transmission usage.   The method of claim 1, wherein the billing tracking code transmits billing data and data transmission packets between the embedded content and a plurality of server systems by utilizing proxy store and forwarding techniques. A transmission-based billing system that automatically generates billing data for content that runs on a client device and transmits data over a network in a computer-based environment, the content comprising at least one Including a network call, the billing system comprising:
A code modifier that embeds billing tracking code into the content by parsing the content and replacing the at least one network call included in the content with a proxy call that includes billing tracking code, on the client device If in runs, it viewed including the automatic code modifier for communicating billing data reflecting the amount of data sent over the network,
The billing system , wherein replacing the at least one network call with the proxy call is performed prior to sending the content .   The billing system of claim 32, wherein the billing tracking code tracks the amount of data transmitted from the embedded content over the network.   34. A billing system according to claim 33, wherein the network is the Internet.   34. The billing system of claim 33, wherein the amount of data is tracked at a logical packet level.   The billing system of claim 32, wherein the billing tracking code tracks the amount of data received by the embedded content from the network.   The billing system according to claim 36, wherein the network is the Internet.   The billing system of claim 36, wherein the amount of data is tracked at a logical packet level.   The billing system of claim 32, wherein the content is Java based.   The billing system of claim 32, wherein the content includes bytecode instructions.   The billing system of claim 32, wherein the incorporating is accomplished at a bytecode level of content inspection.   The embedded content includes a security key that is transmitted with the automatically communicated billing data so that the integrity of the source of the billing data can be verified on receipt. A billing system according to claim 32.   43. The billing system of claim 42, wherein the security key is based on a random number.   43. The billing system of claim 42, wherein the security key is application and subscriber specific.   43. The billing system of claim 42, wherein the security key is incorporated into the content upon receiving a request to download the content.   The billing system of claim 32, wherein the computing environment is integrated with a wireless carrier infrastructure.   33. The billing system of claim 32, further comprising allowing the embedded content to be downloaded to a target device via a wireless transmission medium.   48. The billing system of claim 47, wherein the content is requested by a carrier subscriber from the computing environment via a wireless transmission medium.   35. The billing system of claim 32, further comprising allowing the embedded content to be downloaded to a target device via a wired transmission medium.   50. The billing system of claim 49, wherein the wired transmission medium is the Internet.   33. The billing system of claim 32, wherein the billing data includes at least one of an amount of data sent, an amount of data received, a time stamp, an application identifier, a security key, a transaction identifier, and a retry time limit indicator.   The billing system of claim 32, wherein the billing data is automatically communicated with reference to transmission to a billing server system.   53. The billing system of claim 52, further comprising a packet detection and forwarding module that transmits data that is not direct billing data between the subscriber's device and a server system that is not the billing server system.   36. The billing system of claim 32, further comprising integrating the billing data into customer-based billing information to generate a customer data record.   The billing system of claim 32, wherein the billing data is used to support a plurality of billing policies.   56. The billing system of claim 55, wherein the billing policy includes a promotional offer that provides a reduced fee for a specified application.   56. The billing system of claim 55, wherein the billing policy is provided by a content provider.   The billing system of claim 32, wherein the billing data is used to provide a royalties payment to a provider of the content.   33. The billing system of claim 32, further comprising causing data transmitted between the embedded content and the network to be routed according to billing data based on the transmission.   60. The billing system of claim 59, wherein the routing allows for efficient use of resources on the network.   60. The billing system of claim 59, wherein priorities are assigned to content based on transmission usage.   35. The billing system of claim 32, wherein the billing tracking code transmits billing data and data transmission packets between the embedded content and a plurality of server systems by incorporating proxy store and forwarding techniques.

Images