MXPA03007661A

MXPA03007661A - Metodo y sistema para facturacion de aplicaciones basada en la transmision.

Info

Publication number: MXPA03007661A
Application number: MXPA03007661A
Authority: MX
Inventors: L Jansen Markus
Original assignee: 4Thpass Inc
Priority date: 2001-02-26
Filing date: 2002-02-26
Publication date: 2004-11-12
Also published as: WO2002084947A3; WO2002084947A2; US7436816B2; JP2007329937A; JP4139228B2; AU2002306608B2; EP1397769A2; JP2005509322A; US20020128984A1

Abstract

Se proporcionan metodos y sistemas basados en computadora y en red para facturacion basada en la transmision. Las modalidades de ejemplo proporcionan un Sistema de Facturacion Basado en Paquetes ("PBBS"), el cual hace posible que los proveedores de aplicaciones, tales como distribuidores y proveedores de contenido, facturen a los suscriptores por el uso del contenido en aparatos moviles de los suscriptores, tales como aparatos inalambricos, sobre una base por aplicacion y por usuario, basandose en el grado de uso. Las modalidades de la presente invencion tambien se pueden utilizar para facturar a los suscriptores por el uso del contenido sobre una base por aplicacion y por usuario, tambien para aparatos alambricos de los suscriptores, utilizando las mismas tecnicas. En la operacion, el Sistema de Facturacion Basado en Paquetes proporciona contenido modificado mediante la insercion del codigo de facturacion y rastreo en el contenido devuelto a un aparato solicitante. El contenido modificado, cuando se ejecuta, rastrea la cantidad de datos enviados y recibidos entre el contenido y una red, y coloca los datos acumulados en un servidor de facturacion/proxy de acuerdo con las reglas del negocio, por un intervalo/frecuencia para colocar estos datos. El servidor de facturacion/proxy almacena los datos de facturacion brutos, y un programa de contabilidad recupera los datos de facturacion para generar registros de datos del cliente (llamada). Se pueden incorporar en el sistema reglas comerciales que especifiquen diferentes cargos para diferentes contenidos o usuarios.

Description

METODO Y SISTEMA. PARA FACTURACION DE APLICACIONES BASADA EN LA TRANSMISION ANTECEDENTES DE LA INVENCION Campo de la Invención La presente invención se relaciona con un método y sistema para facturación basada en transmisión y, en particular, a métodos y sistemas para facturar el uso de aplicaciones inalámbricas y cableadas que se basan en datos que se transmiten sobre una red.

Información Antecedente Hoy en día, los dispositivos inalámbricos se han hecho prolificos en muchas comunidades del mundo. Los suscriptores de portadores telefónicos usan dispositivos tales como teléfonos inalámbricos, microteléfonos , administradores personales de información, organizadores electrónicos, asistentes digitales personales, máquinas de correo electrónico portátiles, máquinas de juegos, y otros dispositivos, para agregar conveniencia a sus vidas. Sin embargo, el software que se usa para estos dispositivos es arcano. Típicamente, las aplicaciones u otros servicios se facturan cuando se cargan sobre un dispositivo inalámbrico (una sola vez, cargo de cuota fija) ; sobre una base de suscripción, tal como un cargo por el uso general de un conjunto de aplicaciones y servicios; o por el tiempo aire total. En la tercera generación más nueva, las redes inalámbricas, tales como las GPRs, los portadores pueden identificar un número total de paquetes fisicos o la cantidad de datos gue usó un dispositivo. De esta manera, los modelos de facturación para un portador de red típico reflejan la cuota fija o la facturación que se basa en suscripción y no reflejan necesariamente de manera exacta el uso de las aplicaciones y los servicios. Por ejemplo, las aplicaciones inalámbricas que obtienen acceso a la red mientras que se están ejecutando en el dispositivo, por ejemplo un calendario, un navegador, o un cliente de correo electrónico, típicamente utilizan diferentes recursos portadores que las aplicaciones que no obtienen acceso a una red, por ejemplo, una calculadora o un editor de texto. Un portador o proveedor de contenido no puede cargar de manera exacta por la cantidad de recursos del portador que consume una aplicación particular, debido a que los sistemas de facturación actuales que se proporcionan en el nivel del portador inalámbrico no pueden proporcionar facturación diferenciada a un nivel de la aplicación, excepto en el momento de la descarga.

BREVE COMPENDIO DE LA INVENCION Las modalidades de la presente invención proporcionan métodos y sistemas que se basan en computadora y en la red para la facturación basada en transmisión, la cual proporciona el rastreo de la información de facturación que se basa en el volumen de los datos que se transmiten entre las aplicaciones u otros tipos de contenido, y una red. Las modalidades de ejemplo proporcionan un Sistema de Facturación Que Se Basa en Paquete ("PBBS", por sus siglas en inglés) , el cual facilita que los proveedores de la aplicación, tales como los portadores y los proveedores de contenido de una tercera parte, le facturen a los clientes o suscriptores (genéricamente "usuarios") por el uso de las aplicaciones/ servicios (genéricamente, "contenido") sobre dispositivos móviles del suscriptor, tales como dispositivos inalámbricos, sobre una base por aplicación, por usuario sobre el grado de uso. Las modalidades de la presente invención también se pueden usar para facturar a los suscriptores sobre una base por aplicación, por usuario para los dispositivos cableados del suscriptor también, usando las mismas técnicas. El PBBS determina y proporciona el código de rastreo de facturación y el soporte de comunicación asociado, al que se hace referencia generalmente de manera colectiva en la presente como "código de rastreo de facturación," para habilitar la aplicación y a los proveedores de servicios u otros proveedores de contenido (típicamente portadores) para rastrear de manera automática la información de facturación sobre un nivel de paquete lógico, que se pueda configurar, basándose en la cantidad de datos que envió y/o recibió la aplicación o el servicio sobre la red. En el caso de los dispositivos inalámbricos y una red inalámbrica, estos datos de facturación rastrean el uso de la red sobre una base por aplicación en lugar de los modelos de uso "tiempo aire total" tradicionales. Los datos que se rastrean se asocian con un usuario particular, permitiendo asi que la aplicación o el proveedor de servicio facture sobre una base por aplicación basándose en el volumen real de uso. En una modalidad, los datos de facturación que se rastrean y se colocan incluyen una cantidad de datos enviados /recibidos a través de la red, una estampilla de tiempo, un identificador de la aplicación, una clave de seguridad, un identificador de transacción, y un indicador de vencimiento para volver a procesar. En otras modalidades, los datos de facturación pueden incluir un subconjunto de esos datos o pueden incluir datos diferentes o adicionales. La aplicación/proveedor de servicios puede implementar de manera subsecuente una variedad de políticas de facturación en la aplicación o el nivel del usuario, el cual puede cambiar a través del tiempo. En una modalidad, el PBBS instrumenta el código de rastreo de facturación que se basa en paquete dentro del contenido para rastrear y acumular los datos de facturación en el dispositivo del cliente y para colocar los datos en un servidor, tal como un servidor proxy o un servidor de facturación. Para algún contenido, tal como las aplicaciones Java, las aplicaciones.NET, y otras aplicaciones binarias, la instrumentación se logra en el nivel de código de byte. En una modalidad asi, la instrumentación se realiza mediante un modificador de contenido (código) que analiza el contenido para determinar las estructuras de datos, la secuencia de llamada, y la ubicación e identidad de cualesquiera llamadas de la red y reemplaza estas llamadas por llamadas de la red proxy que contengan el código de facturación y rastreo. En otra modalidad, se incorpora el código de rastreo de facturación dentro del contenido por medio de modificar el contenido de conformidad con una especificación por escrito. En todavía otra modalidad, se incorpora el código de rastreo de facturación dentro del contenido a través de llamadas a la biblioteca de Inferíase de Programación de la Aplicación. En todavía otra modalidad, se coloca el código de rastreo de facturación en el software del controlador de la red en el dispositivo del cliente y se interconecta de manera directa con un servidor proxy/de facturación. En todavía otra modalidad, se inserta una clave de seguridad dentro del contenido para habilitar al código de rastreo de facturación para que se identifique a sí mismo con un servidor proxy cuando se coloquen los datos de facturación desde un dispositivo del cliente. En una modalidad como esta, la clave de seguridad es un número que se asocia de manera única con cada combinación de contenido/usuario y se almacena en un depósito de datos seguro para evitar el mal uso y datos de facturación falsos. En otra modalidad, la clave de seguridad es un número aleatorio único. En una modalidad, el PBBS comprende un modificador de contenido (código) ; uno o más depósitos de datos que contienen las asociaciones de las llamadas de la red a diferentes llamadas de la red proxy que contienen el código de rastreo de facturación, reglas de negocios para los datos de facturación, datos puros de facturación, y claves de seguridad; un servidor proxy, un servidor de facturación, y un programa de contabilidad. De conformidad con esta modalidad, las funciones del PBBS se pueden integrar dentro y dispersarse sobre diferentes componentes en un sistema de abastecimiento de la aplicación. Después estos componentes interactúan para determinar e insertar el código de rastreo de facturación dentro del contenido; reciben datos del código de rastreo de facturación; y procesa los datos que se rastrearon en conjunción con las políticas indicadas de facturación para generar los registros de facturación. En una modalidad el código de rastreo de facturación se inserta en respuesta a una solicitud de un dispositivo del cliente para una aplicación y automáticamente se devuelve una aplicación modificada. Después se colocan los datos de facturación cuando se ejecuta la aplicación modificada en el dispositivo del cliente. En otra modalidad, los datos de facturación se generan directamente en respuesta a una solicitud desde un dispositivo del cliente para el contenido de flujo continuo, tal como audio y video de flujo continuo, debido a que las solicitudes son para un número particular de bytes o cantidad de datos. En una de estas modalidades, el sistema de abastecimiento de la aplicación suministra las aplicaciones para los dispositivos inalámbricos. En otra modalidad, el sistema de abastecimiento de la aplicación suministra las aplicaciones para los dispositivos cableados. En otra modalidad, los datos que se basan en transmisión se usan para enrutar paquetes de la red desde las aplicaciones hacia otros servidores (tráfico de la red) . De conformidad con esta modalidad, se consume una aplicación de manera que un servidor proxy pueda dirigir el tráfico directo de la red para promover más eficiencia o, por ejemplo, para proporcionar/garantizar mejor tiempo de respuesta para aplicaciones que se usan excesivamente o populares, o aplicaciones que se basan en algunos otros criterios.

BREVE DESCRIPCION DE LOS DIBUJOS La Figura 1 es un diagrama de bloques general de un sistema de facturación que se basa en transmisión. La Figura 2 es un diagrama de bloques de ejemplo del contenido que se instrumenta con el código de rastreo de facturación como lo realiza un modificador de contenido (código) de un Sistema de Facturación Que Se Basa En Paquete.

La Figura 3 es un diagrama de bloques de un sistema de facturación que se basa en transmisión de ejemplo que se implementa dentro de un Sistema de Aplicación Móvil. La Figura 4 es un diagrama de bloques de ejemplo de un sistema de computadora de propósito general y un dispositivo del cliente para practicar las modalidades del sistema de facturación que se basa en transmisión. La Figura 5 es un diagrama de bloques de un procedimiento de ejemplo para presentar una aplicación a un Sistema de Aplicación Móvil para usarse con la facturación que se basa en transmisión. La Figura 6 es un diagrama de bloques de ejemplo que ilustra un proceso general para entregar de manera transparente una aplicación que soporte la facturación que se basa en transmisión a un dispositivo del cliente que esté usando un Sistema de Aplicación Móvil. La Figura 7 es un diagrama de flujo de ejemplo de una rutina para modificar una aplicación para soportar la facturación que se basa en transmisión. La Figura 8 es un diagrama de flujo de ejemplo de una rutina para analizar e instrumentar una aplicación con soporte para la facturación que se basa en transmisión.

La Figura 9 es un diagrama de bloques de ejemplo que ilustra un proceso general para comunicar los datos de facturación que se basan en los datos de transmisión de la red sobre una base por aplicación. La Figura 10 es un diagrama de flujo de ejemplo de una rutina del cliente para enviar los datos a una red que se ha modificado para recolectar y transmitir los datos de facturación . La Figura 11 es un diagrama de flujo de ejemplo de una rutina del cliente para recibir datos desde una red que se ha modificado para recolectar y transmitir los datos de facturació . La Figura 12 es un diagrama de flujo de ejemplo de una rutina del servidor para procesar los datos de facturación que se basan en transmisión que se colocaron. La Figura 13 es un diagrama de flujo de ejemplo de los pasos para generar los cargos de facturación que se basan en los datos de facturación que se basan en transmisión.

DESCRIPCION DETALLADA DE LA INVENCION Las modalidades de la presente invención proporcionan métodos y sistemas que se basan en computadora y en la red para la facturación que se basa en transmisión, la cual proporciona el rastreo de la información de facturación sobre el volumen de datos que se transmiten entre las aplicaciones, u otros tipos de contenidos, y una red. Las modalidades de ejemplo proporcionan un Sistema de Facturación Que Se Basa en Paquete ("PBBS") , el cual habilita a los proveedores de la aplicación, tales como portadores y proveedores de contenida de una tercera parte, para que facturen a los clientes o suscriptores (qenéricamente "usuarios") por el uso de aplicaciones/servicios (genéricamente "contenido") sobre los dispositivos móviles del suscriptor, tales como dispositivo inalámbricos, sobre una base por aplicación, por usuario que se basa en el grado de uso. Las modalidades de la presente invención también se pueden usar para facturar a los suscriptores sobre una base por aplicación, por usuario para dispositivos cableados del suscriptor también, usando las mismas técnicas. Aunque esta descripción se refiere principalmente a las aplicaciones, Alguien experto en la técnica reconocerá que los métodos y sistemas que se describen en la presente se pueden aplicar a cualquier otro tipo de contenido que se pueda transmitir a un nivel de paquete a través de una red, tal como servicios y recursos, y que pueda comunicar datos de facturación a un servidor cuando éste se "ejecute" en un dispositivo del cliente. Por ejemplo, una máquina para reproducir audio, o video, etcétera, se puede modificar para la facturación que se basan en transmisión de conformidad con estos métodos. Además, los métodos y sistemas que se describen en la presente se pueden extender al contenido que se pueda poner en flujo, tal como texto, video, audio, gráficas, etcétera. El PBBS proporciona de manera dinámica el código de rastreo de facturación y el soporte de comunicación asociado, al que se hace referencia de manera colectiva en la presente como "código de rastreo de facturación," para habilitar a la aplicación, y a los proveedores de servicios u otros proveedores de contenido (típicamente portadores) para rastrear de manera automática la información de facturación en un nivel de paquete lógico, que se puede configurar, basándose en la cantidad de datos que envía y/o recibe la aplicación o el servicio. Los datos que se rastrean se asocian con un usuario particular, permitiendo así que el proveedor de contenido facture sobre una base por usuario, por aplicación que se basa en el volumen real de uso. El proveedor de contenido (que se usa en la presente para hacer referencia qeneralmente a cualquier tipo de proveedor de servicios) puede implementar de manera subsecuente una variedad de políticas de facturación al nivel de la aplicación o el usuario, el cual puede cambiar a través del tiempo. Por ejemplo, un proveedor de aplicación pudiera desear cargar cuotas inferiores para aplicaciones populares cuando un suscriptor las usa en gran escala, por ejemplo, como se mide mediante la cantidad de datos en paquete que reciben/envían esas aplicaciones para el suscriptor particular. Como otro ejemplo, un proveedor de servicios pudiera desear implementar una promoción para una aplicación nueva, cargando menos por volumen de transmisión para esa aplicación particular, en comparación con una cuota normal. La Figura 1 es un diagrama de bloques general de un sistema de facturación que se basa en transmisión de ejemplo. En la Figura 1, el Sistema de Facturación Que Se Basa en Paquete 100 comprende diferentes componentes: un modificador de contenido (código) 103 para modificar el contenido que se solicitó para que contenga el código de rastreo de facturación; un depósito de datos de configuración 105 para almacenar el código de rastreo de transmisión y facturación; un servidor proxy y/o servidor de facturación 104 para recibir y recolectar los datos de facturación desde el contenido que se descarga hacia los dispositivos objetivo (cliente) ; un depósito de datos de facturación 106 para almacenar los datos de facturación que se recolectaron y las reglas de negocio para recolectar la información de facturación; y un programa de contabilidad 107 para leer los datos de facturación que se recolectaron y generar los registros de facturación 108 del cliente. Como se describirá con detalle adicional más adelante, los componentes del PBBS se integran típicamente dentro de un sistema que proporciona el contenido a los dispositivos objetivo. En operación, un dispositivo del cliente, tal como la computadora personal 101 o el microteléfono inalámbrico 102, solicita el contenido, tal como una aplicación, desde un sistema que proporciona el contenido. El contenido se puede solicitar desde un sistema que se conecta por medio de una red inalámbrica a un dispositivo inalámbrico, tal como el microteléfono 102, o desee un sistema que se conecta por medio de una red cableada a un dispositivo cableado, tal como la computadora personal 101. Como parte del proceso para solicitar el contenido, después de que el sistema determina y recupera el contenido que se solicitó, el modificador de contenido 103 analiza el contenido y consulta el depósito de datos de configuración 105 para determinar qué tipo de código de rastreo de facturación se necesita insertar dentro del contenido que se solicitó y modifica de manera transparente el contenido en conformidad. El contenido modificado se regresa después al dispositivo del cliente 101/102 para descargarlo. En momentos subsecuentes, cuando se ejecuta el contenido modificado que se descargó en el dispositivo del cliente 101/102, se ejecuta de manera automática el código de rastreo de facturación para recolectar y colocar los datos de facturación en el servidor proxy/de facturación 104. El servidor de facturación 104 recolecta y almacena los datos de facturación que se recibieron de acuerdo a las reglas de negocio en el depósito de datos de facturación 106. El programa de contabilidad 107 puede recuperar entonces los datos de facturación que se recolectaron, para generar los registros de facturación 108 del cliente. Típicamente, el programa de contabilidad se diseña de manera específica para acomodar las necesidades de un servicio responsable por la facturación, tal como un portador en un ambiente para poner en red inalámbrica. Los datos de facturación de ejemplo incluyen el número de bytes que se envían y/o se reciben, una estampa de tiempo, un identificador de la aplicación, identificador del usuario (que envía de manera automática la infraestructura del portador cuando se envían los datos de facturación sobre una red inalámbrica) , una clave de seguridad, un identificador de transacción, y un indicador de vencimiento para volver a procesar. El identificador de transacción se usa típicamente para identificar "eventos" de rastreo de facturación individuales/diferentes. El indicador de vencimiento para volver a procesar indica por cuánto tiempo deberá volver a colocar el dispositivo del cliente los mismos datos de facturación, cuando el dispositivo del cliente se da cuenta de que una operación de colocación ha fallado. De manera similar, un servidor proxy/de facturación usa el indicador de vencimiento para volver a procesar para determinar por cuánto tiempo es válido un identificador de transacción, a fin de detectar colocaciones recibidas duplicadas . En una modalidad, el modificador de contenido del PBBS (por ejemplo, el modificador de contenido (código) 103 de la Figura 1) instrumenta el código de rastreo de facturación que se basa en paquete dentro del contenido que se solicitó, para realizar las técnicas de la presente invención. Instrumentación, como se usa en la presente, es un elemento no intrusivo para modificar el contenido (por ejemplo, una aplicación) para incluir el código adicional, el cual en este caso, es el código de rastreo de facturación y de transmisión. En una modalidad, las llamadas de la red residentes en el contenido se detectan mediante el modificador de código del PBBS y se reemplazan mediante el código de rastreo de facturación especifico de la facturación que se basa en transmisión, el cual calcula y recolecta los datos de facturación que se basan en paquete e invoca las llamadas de la red que se especificaron originalmente. La instrumentación en este sentido se usa como un "gancho" antes o después de una llamada de la red como un método para intersecar la llamada de la red. Debido a que el diferente contenido en los diferentes ambientes usará una variedad de llamadas de la red y debido a que los diferentes proveedores tienen diferentes políticas de facturación, el modificador de código del PBBS usa un depósito de datos de configuración (tal como un depósito de datos de configuración 105 en la Figura 1) , para determinar cuál llamada de la red de reemplazo instrumentar dentro del contenido. Las llamadas de reemplazo pueden almacenar los datos de facturación que se recolectaron en el almacenamiento temporal en el dispositivo objetivo y después colocar los datos que se recolectaron cuando el contenido termina la ejecución (por ejemplo, cuando sale una aplicación) . De manera alternativa, los datos que se recolectaron se pueden colocar sobre cada llamada de la red. Además, los datos que se recolectaron se pueden almacenar en el almacenamiento permanente en el dispositivo del cliente de manera que se puedan colocar después de la energía de reciclaje en el dispositivo. Alguien experto en la técnica reconocerá que son posibles diferentes escenarios para cuando se colocan los datos y se contempla trabajar con estas técnicas . La Figura 2 es un diagrama de bloques de ejemplo del contenido que se instrumenta con el código de rastreo de facturación como lo realiza un modificador de contenido (código) de un Sistema de Facturación Que Se Basa en Paquete. El código, por ejemplo, una aplicación 210, se envía al modificador de código 201 para análisis e instrumentación. La secuencia de llamada de las rutinas dentro de la aplicación 210 se muestra de manera esquemática (después de experimentar un análisis de secuencia de llamada) . De conformidad con la secuencia que se ilustra, se llama una rutina "startupO" ("inicioO") 211 seguida por una llamada de la red 212, seguida por una rutina "endO" ("finO") 213 para la limpieza de la aplicación, seguida por una llamada de salida 214 para terminar la ejecución de la aplicación. El modificador de contenido 201, busca la llamada de la red en el depósito de datos de configuración 202, y determina y recupera una llamada de la red 222 correspondiente la cual contiene el código para implementar la facturación que se basa en transmisión y el rastreo. La llamada de la red 222 correspondiente se implementa para invocar la llamada de la red 212 original, de manera que proporciona un "gancho" para la llamada de la red 212 original. El modificador de contenido 201 también consulta el depósito de datos de configuración 202 para determinar los parámetros de configuración para facturar, tal como con cuánta frecuencia se deberá colocar la información de facturación (por ejemplo, después de un tiempo o de que se haya transmitido una cantidad particular de datos) y la dirección de la red del servidor proxy en el cual se colocarán los datos de facturación. El modificador de contenido 201 instrumenta entonces la aplicación con la llamada de la red 222 que se recuperó y el código para colocar los datos de facturación, como se indica mediante los parámetros de configuración determinados. Se muestra un esquemático de una aplicación modificada de ejemplo 220 con una secuencia de llamada después de que se ha realizado la instrumentación. En la aplicación modificada 220, se llama la rutina "startupO", seguida ahora por la llamada de la red 222 que se instrumentó, la cual está seguida por la llamada de la red 212 original, seguida por la rutina "endO" 213. El modificador de contenido también instrumenta el código 223 para colocar los datos de facturación en el servidor proxy/de facturación de conformidad con los parámetros de configuración que se determinaron. Este código de colocación 223 se muestra en la secuencia entre la rutina "endO" 213 y la llamada de salida 214. El tener el código que coloca los datos de facturación al final de la aplicación, aún si los datos de facturación se colocaron con anterioridad, intenta colocar para volver a procesar cualesquiera colocaciones fallidas previas. En una modalidad, si la llamada de colocación final 223 falla, simplemente se pierden y se ignoran los datos de facturación. Otras modalidades pudieran seleccionar el almacenamiento más permanente de los datos de facturación y la colocación para volver a procesar cuando se ejecuta la aplicación nuevamente. El indicador de vencimiento para volver a procesar se puede usar para evitar eventos de facturación redundantes. De manera especifica, el dispositivo del cliente determina, basándose en la estampa de tiempo, si se ha vencido un periodo para volver a procesar, o si el código de colocación deberá tratar de colocar nuevamente los mismos datos de facturación. Alguien experto en la técnica reconocerá que muchas de estas variaciones son posibles.

Además del código de rastreo de facturación que se instrumentó, en algunas modalidades, el modificador de contenido 201 agrega una clave de seguridad 230 a la aplicación modificada, con el propósito de asegurar esos datos de facturación para la aplicación, una vez que no se le pueda mal uso a la descarga por medio de enviar datos de facturación falsos. En otras modalidades, como se describe con detalle en el Apéndice E, se incorpora el código de rastreo de facturación dentro del contenido mediante otros medios, incluyendo medios intrusivos y no intrusivos. Por ejemplo, se puede proporcionar una especificación para el código de rastreo de facturación que se basa en paquete a los proveedores de contenido, los cuales pueden modificar su contenido para incluir de manera explícita este rastreo. En un segundo ejemplo, una Interfase de Programación de Aplicación (una VAPI") puede proporcionar una biblioteca de funciones que pueden invocar los proveedores de contenido en puntos apropiados en el contenido, para proporcionar el rastreo de facturación que se basa en paquete y la comunicación. En todavía un tercer ejemplo, el software del controlador de la red del dispositivo objetivo, tal como un dispositivo inalámbrico, se puede modificar para que incluya el código de rastreo de facturación que se basa en paquete (a través de la especificación o mecanismos de la biblioteca) .

En todas estas otras modalidades, se le debe informar ya sea al proveedor de contenido a al fabricante del controlador del dispositivo sobre el código de rastreo de facturación y de las técnicas de comunicación; proporcionando asi un elemento más intrusivo para incorporar el soporte de la facturación. Los componentes y la funcionalidad del PBBS se pueden integrar dentro de, y dispersarse sobre diferentes componentes en un ambiente de la red, tal como un sistema de abastecimiento de la aplicación. En ese escenario, los componentes de abastecimiento interactúan entonces para determinar e insertar el código de rastreo de facturación dentro del contenido, recibir los datos del código de rastreo de facturación, y procesar los datos que se rastrearon en conjunción con las políticas de facturación que se indicaron para generar los registros de facturación. De manera más especifica, cuando un suscriptor solicita una aplicación, se proporciona la aplicación mediante el sistema de abastecimiento de aplicaciones para el dispositivo que lo solicita y se descarga al dispositivo que lo solicita, con el código de facturación apropiado que s.e instrumentó dentro de la aplicación. Abastecimiento, como se usa en la presente, es la fabricación según especificaciones y la distribución del contenido para un uso particular, por ejemplo, para usarlo sobre un tipo particular de dispositivo del suscriptor mediante un cliente particular. Un sistema de abastecimiento de aplicaciones de ejemplo, al que se hace referencia como el Sistema de Aplicación Móvil (MAS, por sus siglas en inglés) , se puede usar con el PBBS que se describe en la presente. El Apéndice D describe este sistema en detalle, incluyendo las técnicas para instrumentar el código dentro de las aplicaciones, fabricar según especificaciones estas aplicaciones, y distribuirlas a, de manera especifica, dispositivos inalámbricos. El MAS es una colección para interoperar los componentes del servidor que trabajan de manera individual y juntos de una manera segura para proporcionar las aplicaciones, recursos, y otro contenido a los dispositivos de suscriptores móviles y cableados. la Figura 3 es un diagrama de bloques de un sistema de facturación que se basa en transmisión de ejemplo, que se implementa dentro de un ambiente del Sistema de Aplicación Móvil de ejemplo. El sistema de Aplicación Móvil (MAS) que se muestra es un sistema de Abastecimiento que se conecta sobre una conexión inalámbrica a un microteléfono inalámbrico 310. Los componentes del MAS incluyen, entre otros componentes, los Administradores de Abastecimiento y Despliegue 302, los cuales contienen como parte de su función, el escáner de contenido, el analizador, y las capacidades de instrumentador 303; un Administrador de Facturación 305; un depósito de datos de Configuración 304; y un Programa de Contabilidad 306. Las capacidades de instrumentador 303 de los Administradores de Abastecimiento y Despliegue 302 proporcionan las funciones de modificador de código del PBBS . El Administrador de Facturación 305 puede incorporar el papel de un servidor proxy para recolectar los datos de facturación que se colocaron. EL microteléfono inalámbrico 310 incluye típicamente la memoria de destello 311, u otro tipo de almacenamiento local, semipermanente para sostener los datos de facturación a medida que se recolectan. El microteléfono inalámbrico 310 se conecta también sobre una conexión inalámbrica a una red pública, tal como la Internet 320. Para propósitos de sencillez de descripción, se supone que el microteléfono 310 puede dirigir los servidores sobre la red pública 320 de manera directa y separada de los datos de facturación de colocación para el Administrador de Facturación MAS 305; sin embargo, no es necesaria esta suposición para realizar las técnicas que se describen en la presente. En particular, si un dispositivo del cliente no puede dirigir de manera directa múltiples servidores, entonces se puede proporcionar un servidor proxy que implemente las capacidades de almacenamiento y transmisión para todos los paquetes de la red que se recibieron. En este escenario, el servidor proxy recibe un paquete y determina su destino pretendido (así como la recepción de los datos de facturación) ; recupera los datos de facturación del paquete, y transmite los datos en paquete originales a su destino pretendido . Aunque las técnicas del PBBS se pueden aplicar generalmente a cualquier tipo de dispositivo inalámbrico del cliente, Alguien experto en la técnica reconocerá que términos tales como dispositivo del suscriptor, dispositivo del cliente, teléfono, manual, etcétera, se usan de manera intercambiable para indicar cualquier tipo de dispositivo del cliente que se pueda operar con el PBBS. También, los términos pueden tener ortografías alternas las cuales se pueden o no se pueden mencionar de manera explícita. Por ejemplo, código-byte se puede indicar también como "código de byte" o "código de Byte," y Alguien experto en la técnica reconocerá que se pretende que se incluyan todas estas variaciones de los términos. Además, las modalidades de ejemplo que se describen en la presente proporcionan aplicaciones, herramientas, estructuras de datos y otro soporte para implementar un sistema de facturación que se basa en transmisión, sobre una o más redes. Alguien experto en la técnica reconocerá se pueden usar otras modalidades de los métodos y sistemas de la presente invención para muchos otros propósitos, que incluyen la instrumentación del soporte de facturación que se basa en transmisión dentro del software y otro contenido sobre redes no inalámbricas, tal como la Internet, hacia dispositivos del suscriptor no inalámbricos, tal como una computadora personal, un microteléfono inalámbrico acoplado, teléfonos con conectividad a la Internet, o quioscos del cliente, por ejemplo, dentro de los aeropuertos o centros comerciales. Además, aunque esta descripción se refiere principalmente al contenido en la forma de aplicaciones, servicios, y recursos, Alguien experto en la técnica reconocerá que el contenido puede contener texto, gráficas, audio, y video. También, en la siguiente descripción, se establecen numerosos detalles específicos, tales como formatos de datos y flujos de código, etcétera, a fin de proporcionar un entendimiento profundo de las técnicas de los métodos y sistemas de la presente invención. Alguien experto en la técnica reconocerá, sin embargo, que la presente invención también se puede practicar sin algunos de los detalles específicos que se describen en la presente, o con otros detalles específicos, tales como los cambios con respecto al ordenamiento del flujo de código. Además, se pueden extender las técnicas del PBBS para operar con el contenido de flujo continuo. De manera específica, cuando un dispositivo del cliente solicita el contenido de flujo continuo (tal como texto, audio, video, gráficas, etcétera), la solicitud indica una cantidad de contenido para descargar. El modificador de contenido, en lugar de insertar el código de facturación y rastreo dentro del contenido. Genera eventos de facturación directamente y los envía a un servidor proxy/de facturación.

También, Alguien experto en la técnica reconocerá que las técnicas de la presente invención se pueden usar para otros usos en los cuales la determinación y el rastreo de la cantidad de los datos que se envían y se reciben son valiosos, para algo más que generar datos de facturación. Por ejemplo, un uso adicional para las técnicas de la presente invención se relaciona con el enrutamiento de los paquetes y solicitudes de la red. De manera específica, un servidor proxy (u otro componente o sistema) puede usar las mismas técnicas para rastrear los datos de facturación que se basan en la cantidad de datos que se envían y se reciben entre el contenido y la red, para decidir cómo y en dónde enrutar los paquetes de la red basándose en una política de enrutamiento. Los datos de "facturación" que se colocaron incluyen información que identifica al usuario, la aplicación y la cantidad de datos que se están transmitiendo, cuáles se pueden usar para distribuir el tráfico de la red de una manera particular o reservar servidores particulares para combinaciones de aplicación/usuario que se comercian en gran escala; proporcionando así un tipo de equilibrio de la carga.

La Figura 4 es un diagrama de bloques de ejemplo de un sistema de computadora de propósito general y un dispositivo del cliente para practicar las modalidades del sistema de facturación que se basa en transmisión. El ambiente de computadora de la Figura 4 comprende un dispositivo del cliente (suscriptor) 401 y un sistema de computadora de propósito general 420, el cual se comunica por medio de una red 410. Cada bloque puede representar uno o más de estos bloques según sea apropiado para una modalidad especifica, o se puede combinar con otros bloques, y cada uno puede residir en ubicaciones físicas separadas. El dispositivo del cliente 401comprende una memoria de computadora ("memoria") 402, un despliegue visual 404, Dispositivos de Entrada/Salida 403, y una Unidad de Procesamiento Central ("CPU") 405. El contenido Modificado 406, por ejemplo una aplicación que se puede ejecutar, se muestra residiendo en la memoria 402 con otras aplicaciones 407 descargadas y un depósito de datos para el almacenamiento temporal de los datos de facturación 408. El Contenido Modificado 406 se ejecuta de preferencia sobre la CPU 405 y ejecuta el código de rastreo de facturación que se insertó, como se describió en las figuras previas, para rastrear los datos de transmisión y para comunicar los datos de facturación a un servidor proxy/de facturación a través de la red 410. El sistema de computadora de propósito general 420 puede comprender uno o más servidores y/o sistemas de computación del cliente y puede abarcar las ubicaciones distribuidas . En una modalidad, en donde el PBBS se integra dentro de un sistema de abastecimiento de aplicaciones tal como un MAS, el MAS se implementa usando la Edición de empresa Java 2 (J2EE) y se ejecuta sobre un sistema de computadora de propósito general que proporciona un servidor de aplicación que cumple con J2EE. De conformidad con esta modalidad, el MAS se diseña y se codifica usando una arquitectura de aplicación de múltiples hileras, la cual soporta una hilera web, una hilera de negocios, y una hilera de base de datos en el lado del servidor. Por tanto, el sistema de computadora de propósito general 420 representa uno o más servidores que pueden ejecutar uno o más componentes y/o depósitos de datos del MAS y el PBBS. Como se muestra, el sistema de computadora de propósito general 420 comprende una CPU 423, una memoria 421, y opcionalmente un despliegue visual 422 y Dispositivos de Entrada/Salida 424. Los componentes del PBBS 430 se muestran residiendo en la memoria 421, y de preferencia se ejecutan sobre una o más CPüs 423. Otros depósitos de datos y otros programas (no se muestran) residen también en la memoria 421, y de preferencia se ejecutan sobre una o más CPüs 423. En una modalidad típica, el PBBS 430 incluye un Modificador de Contenido 425, Depósitos de Datos 427 y 428 para almacenar el código de rastreo de transmisión y facturación, datos de facturación y reglas de negocios, el Servidor de Facturación 426 (el cual se muestra actuando como el servidor proxy y de facturación), y el Programa de Contabilidad 429. Como se describió antes, el PBBS puede incluir otros depósitos de datos y componentes que dependen de las necesidades de, y de la integración con el portador u otros sistemas anfitriones. Otros componentes, los cuales son parte del sistema de abastecimiento de aplicaciones, también están presentes en la memoria 421, pero no se muestran, tales como los componentes de abastecimiento y despliegue y un almacén local de aplicaciones. Como se mencionó, las aplicaciones se abastecen y se instrumentan con el código de rastreo de facturación mediante el Modificador de Contenido 425, antes de descargarlas hacia el dispositivo del cliente 401. Alguien experto en la técnica reconocerá que el PBBS 430 se puede implementar en un ambiente distribuido que comprende múltiples, aún heterogéneos, sistemas de computadora y redes. Por ejemplo, en una modalidad, el Modificador de Contenido 425 y el Servidor de Facturación 426 se localizan en sistemas de computadora físicamente diferentes. En otra modalidad, los diferentes componentes del PBBS 430 se alojan cada uno en máquinas servidoras separadas y se pueden localizar de manera remota desde los depósitos de datos 427 y 428. Además, bajo algunos escenarios, el Programa de contabilidad 429 se pueden alojar dentro de la infraestructura de un portador y estar separados por completo del PBBS. Las diferentes configuraciones y ubicaciones de los programas y los datos se contemplan para usarse con las técnicas de la presente invención. En una modalidad de ejemplo, los componentes del PBBS 421 se implementan usando (como parte del MAS) una plataforma de aplicación de múltiples hileras de J2EE, como se describe en detalle en Plataforma 2 de JavaMR, Especificación de Edición de Empresa, Versión 1.2, Sun Microsystems, 1999. El Modificador de Contenido 425 es típicamente parte de los Administradores de Abastecimiento y Despliegue de MAS (como se muestra en la Figura 3) . El Administrador de Facturación 426 es un componente del MAS, que se aumenta para realizar las diferentes capacidades que se asocian con la facturación que se basa en transmisión. Los depósitos de datos 427 y 428 para almacenar el código que se va a instrumentar, las reglas de negocios, y los datos de facturación pueden ser parte del Administrador de Configuración del MAS (ver el Depósito de Datos de Configuración 304 de la Figura 3) o se puede implementar como depósitos de datos separados, dependiendo de las necesidades de seguridad, la ubicación del Programa de Contabilidad 429, etcétera. Las Figuras 5-13 describen diferentes modalidades de ejemplo de las rutinas específicas que implemento cada uno de estos componentes para conseguir la funcionalidad que se describe con referencia a las Figuras 1-3. En las modalidades de ejemplo, estos componentes pueden ejecutarse de manera concurrente y asincrónica; por tanto, los componentes se pueden comunicar usando técnicas de pasaje de mensajes bien conocidas. Alguien experto en la técnica reconocerá que las modalidades sincrónicas equivalentes también las puede soportar una implementación de PBBS . También, alguien experto en la técnica reconocerá que se podrían implementar otros pasos para cada rutina, y en diferentes órdenes, y en diferentes rutinas, todavía realizar las funciones del PBBS. Como se describe con respecto a la Figura 1, el dispositivo del cliente (suscriptor) puede solicitar una aplicación desde un sistema de abastecimiento de aplicaciones, tal como un Sistema de Aplicación Móvil. Usando el MAS, la aplicación se puede abastecer previamente para el dispositivo y el suscriptor y almacenarse de manera local dentro del MAS (llamado "abastecimiento de jardín cercado) o se puede abastecer al vuelo cuando se solicita una aplicación, por ejemplo, por medio de navegar u sitio sobre la Internet (llamado "abastecimiento abierto") . La Figura 5 es un diagrama de bloques de un procedimiento de ejemplo para someter una aplicación a un Sistema de Aplicación Móvil para usarse con la facturación que se basa en transmisión. En la Figura 5, un proveedor de contenido 501, tal como un proveedor de aplicación de tercera parte o un portador, somete una aplicación al sistema de abastecimiento, que se muestra aquí como MAS 502. El MAS 502 almacena la aplicación (ya sea como datos puros o que se abasteció previamente) en el almacén local 503. El proveedor de contenido 501 también proporciona reglas de negocios relacionadas con la facturación, las cuales se almacenan de manera apropiada mediante el MAS 502 en el Depósito de Datos de Facturación 504. Estas reglas indican la información que se relaciona con la facturación tal como la frecuencia o intervalo para colocar los datos de facturación, la dirección del servidor proxy para enviar los datos de facturación, el tamaño de un paquete lógico, y la información del cargo de facturación que se asocia con el tamaño del paquete lógico. Alguien experto en la técnica reconocerá que también se pueden almacenar otras reglas de negocios relacionadas con la facturación que sean especificas de la aplicación o especificas del usuario, según sea necesario. La Figura 6 es un diagrama de bloques de ejemplo que ilustra un proceso general para entregar de manera transparente una aplicación que soporte la facturación que se basa en transmisión para un dispositivo del cliente usando el Sistema de Aplicación Móvil. El dispositivo del cliente 601 solicita una aplicación del MAS 602 usando el manejador de comandos 602, el cual procesa las solicitudes para el MAS. El manejador de comandos 602, es responsable para distribuir la solicitud de la aplicación al componente apropiado del MAS, tal como los Administradores de Abastecimiento y Despliegue de MAS (no se muestran) . Estos componentes, los cuales también contienen la funcionalidad del Modificador de contenido, determinan si ya existe una aplicación que corresponda a la aplicación solicitada en la memoria caché 603, o si -se necesita abastecer una aplicación para su despliegue. Como parte del proceso de abastecimiento, el código de rastreo de facturación se instrumenta dentro de la aplicación 605 y se agrega una clave de seguridad 606, para generar la aplicación modificada 604. Aún si hay disponible una aplicación abastecida con el código de rastreo de facturación instrumentado en la memoria caché 603, podría ser necesario (dependiendo de la técnica que se use) para generar una clave de seguridad. De preferencia, la clave de seguridad 606 se genera y se almacena en un depósito de datos seguro 607 junto con un identificador de suscriptor asociado y un identificador de aplicación. Se puede incorporar cualquier mecanismo para generar una clave de seguridad que se asocie de manera única con un suscriptor y una aplicación y se puede usar con las técnicas de la presente invención. Un mecanismo es generar un número aleatorio de n-bits y combinarlo de alguna manera con un identificador de aplicación único y un identificador de suscriptor único. Este mecanismo permite que se vuelva a usar una sola clave de seguridad para más de una combinación de aplicación/suscriptor, debido a que la clave está unida de manera única a cada combinación de aplicación/suscriptor. Por tanto, el contenido modificado (el cual incluye el código de rastreo de facturación y la clave de seguridad) se puede poner en memoria caché, permitiendo en consecuencia descargas más rápidas del contenido. De manera alternativa, se puede asociar una clave de seguridad única con cada versión de contenido de aplicación/suscriptor . El propósito de la clave de seguridad es generar un número que se pueda reconocer más tarde como perteneciente de manera única a un suscriptor y aplicación particulares cuando se coloquen los datos de facturación en el servidor proxy/de facturación para su recolección y procesamiento. La aplicación modificada 604 se almacena de manera opcional en la memoria caché 603 y devolverse a través del manejador de comandos 602 hacia el dispositivo del cliente solicitante 601. Pudiera ser deseable almacenar la aplicación modificada 604 en la memoria caché 603 durante un corto periodo de tiempo en caso de que la solicitud no se haya descargado de manera apropiada y el dispositivo del cliente 601 vuelva a procesar la solicitud para la misma aplicación. Note, sin embargo, que en una modalidad, la clave de seguridad que se agrega a la aplicación se asocia con un suscriptor particular. En ese escenario, el almacenamiento de la aplicación modificada 604 con una clave de seguridad en la memoria caché 603 no tiene sentido para desplegar para una combinación de aplicación/suscriptor diferente. La Figura 7 es un diagrama de flujo de ejemplo de una rutina para modificar una aplicación para soportar la facturación que se basa en transmisión. Esta rutina se ejecuta típicamente como parte del proceso de abastecimiento y despliegue (ver el Modificador de Contenido 201 en la Figura 2) . En resumen, la rutina determina o generar una versión de la aplicación designada con el código de rastreo de facturación instrumentado, determina o genera una clave de seguridad apropiada que se inserta dentro de la aplicación, y devuelve la aplicación modificada al solicitante. De manera específica, en el paso 701, la rutina recibe una solicitud de aplicación con una aplicación designada como un parámetro. En el paso 702, la rutina determina si ya hay disponible una aplicación instrumentada (por ejemplo, se almacena en la memoria caché 603 en la Figura 6) , y, si es así, continúa en el paso 705, de otro modo continúa en el paso 703. En el paso 703, la rutina analiza el flujo del código de la aplicación e instrumenta el código de rastreo de facturación dentro de la aplicación. Este proceso se describe adicionalmente más adelante con respecto a la Figura 8. En el paso 704, la rutina almacena la aplicación instrumentada, por ejemplo, en una memoria caché de la aplicación, y continúa en el paso 707. En el paso 705, después de determinar que ya hay una aplicación instrumentada disponible, la rutina recupera la aplicación instrumentada desde el almacén local, por ejemplo, la memoria caché, y continúa en el paso 706. En el paso 706, la rutina determina si la aplicación que se recuperó ya tiene una clave de seguridad unida o que se asocie con ella, y, si es asi, continúa en el paso 710 para recuperar la clave de seguridad (o la aplicación modificada con la clave de seguridad), de otro modo continúa en el paso 707. Podría ser deseable mantener una clave de seguridad unida con la aplicación instrumentada durante un período limitado de tiempo para limitar el mal uso potencial. En el paso 707, la rutina genera una clave de seguridad nueva para la aplicación. Se puede utilizar cualquier mecanismo de seguridad, incluyendo el que se describió con respecto a la Figura 6. En el paso 708, la rutina almacena la clave de seguridad que se acaba de generar en un depósito de datos seguro. En el paso 709, la rutina instrumenta la clave de seguridad nueva dentro de la aplicación. En el paso 711, la rutina transmite la aplicación modificada que ahora incluye el código de rastreo de facturación instrumentado y la clave de seguridad al solicitante, y termina el procesamiento. La Figura 8 es un diagrama de flujo de ejemplo de una rutina para analizar e instrumentar una aplicación con soporte para la facturación que se basa en transmisión. Esta rutina transforma una aplicación en una aplicación modificada que contiene soporte para la facturación que se basa en transmisión, como se ilustra en la Figura 2. En el paso 801, la rutina escanea y analiza la estructura y la secuencia de llamada de la aplicación, de preferencia en el nivel del código de byte (al que se llama algunas veces "aplicación binaria") , para entender las estructuras de los datos (paquete, clase, método, y definiciones de campo) y las secuencias de llamada. Como parte de este proceso de desconstrucción/descodificación, la rutina detecta todas las APIs presentes en la aplicación e identifica cualesquier llamadas de la red. Como un resultado de este análisis, en el paso 802, la rutina identifica cuál código llama a las llamadas de la red, y en consecuencia en dónde se localizan las llamadas dentro de la aplicación. Cuando las aplicaciones se codifican en Java, entonces este análisis se puede realizar al nivel de un código de byte (o binario) del programa, si necesidad de insertar el código de generación de análisis al nivel de la fuente. (El nivel del código de byte se refiere a un nivel "intermedio" del código binario, el cual se interpreta mediante una "máquina," intérprete de "código de byte," o "máquina virtual," etcétera, a fin de ejecutar) . Alguien experto en la técnica reconocerá que se pueden implementar otras modalidades para otros lenguajes y contenido, siempre que se puedan detectar y analizar las estructuras de datos y la secuencia de llamada. Las aplicaciones Java y .NET, en particular, son inherentemente adecuadas para ese proceso debido a que son impulsadas por instrucciones - se usan diferentes códigos de byte para indicar diferentes elementos del lenguaje. Se pueden analizar de manera similar otros lenguajes de código intermedio. En el paso 803, la rutina determina las llamadas de la red proxy que corresponden a las llamadas de la red que se localizaron dentro de la aplicación. Estas llamadas proxy se determinan típicamente desde un depósito de datos de configuración que asocia diferentes llamadas de la red con dispositivos y protocolos particulares. El Apéndice A incluye el seudo-código de ejemplo para asignar las llamadas de la red que se localizaron a las llamadas de la red proxy. En el paso 804, la rutina determina reglas de negocios específicas que aplican a esta aplicación como las especificó, por ejemplo, un portador. Como se describió anteriormente, estas reglas pueden definir el intervalo/f ecuencia para que se coloquen los datos de facturación en el servidor proxy/de facturación, el tamaño lógico de un paquete que se va usar para hacer el cargo, y el cargo que se asocia con un paquete. Se puede especificar un conjunto extensivo de reglas en una aplicación o sobre una base por usuario. Alguien experto en la técnica reconocerá que se pueden especificar otras reglas de negocios según sea apropiado y que se pueden cambiar a través del tiempo. Por ejemplo, en algunos sistemas, se puede permitir que el programador de la aplicación proporcione información de cargo predeterminada la cual se puede modificar entonces mediante un multiplicador estándar por el portador, y por tanto el PBBS . En el paso 805, la rutina reemplaza las llamadas de la red que se identificaron en la aplicación con las llamadas de la red proxy, como se ilustra en la Figura 2. En el paso 806, la rutina agrega una llamada de red proxy final para colocar los datos de facturación al final del procesamiento de la aplicación, como se ilustra en la Figura 2. Esta llamada se agrega típicamente aún si la llamada de la red proxy anterior colocó los datos de facturación en el servidor proxy/de facturación en caso de que una llamada anterior haya fallado. En una situación en donde las llamadas de la red proxy anteriores recolecten los datos de manera local en el dispositivo del cliente, esta llamada final para colocar los datos comunica el conjunto acumulado de datos de facturación . Como se describió con respecto a la Figura 1, cuando se ejecuta (se procesa) el contenido modificado en un dispositivo del cliente, el código de rastreo de facturación se activa, recolecta los datos, y los coloca de manera automática en un servidor proxy/de facturación que se asocia con el PBBS. La figura 9 es un diagrama de bloques de ejemplo que ilustra un proceso general para comunicar los datos de facturación que se basan en los de transmisión de la red sobre una base por aplicación. Aunque para los propósitos del ejemplo, se supone que los componentes son parte de un sistema de abastecimiento de aplicación, alguien experto en la técnica reconocerá que, como se describió anteriormente, éstos se pueden integrar dentro de cualquier sistema de entrega de contenido que pueda realizar las funciones del PBBS . En la Figura 9, un dispositivo del cliente 901 coloca los datos de facturación (a través de paquetes de la red) en un servidor proxy 902, como un resultado del código de colocación que se instrumentó previamente dentro de la aplicación (ver Figuras 2 y 8). Se pueden implementar dos tipos diferentes de servidores proxy, dependiendo de las capacidades de los dispositivos. En particular, algunos dispositivos pueden enviar paquetes de la red directamente a más de un servidor. En este caso, los paquetes 909 que se destinan para otros servidores se pueden enviar directamente a ellos, mientras que los datos de facturación se pueden enviar de manera directa al servidor proxy 902. (Algunas veces se hace referencia a esta instalación como un planteamiento de cálculo y registro.) Otros dispositivos pueden enviar paquetes de la red a solamente un servidor. En este escenario, el servidor proxy 902 actúa como un servidor proxy de almacenamiento y transmisión y distribuye los paquetes de la red a sus destinos pretendidos, procesando solamente los paquetes con los datos de facturación que se colocaron. El servidor proxy 902, si es un servidor separado, recolecta los datos que se colocaron y los transmite según sea apropiado a un servidor de facturación 903. En algunas modalidades, se combinan el servidor proxy y el servidor de facturación. En algunas situaciones, sin embargo, por ejemplo debido a preocupaciones de seguridad, pudiera ser deseable separar los servidores proxy y de facturación. Como otro ejemplo, el servidor de facturación puede existir ya y tener un protocolo de recolección de datos particular con el cual se interconecta el servidor proxy. Una vez que se reciben los datos de facturación que se recolectaron, el servidor de facturación 903 determina si la clave de seguridad que se envió con los datos de facturación es legitima por medio de compararla con la clave de seguridad que se esperaba en el depósito de datos de seguridad 905 para esa aplicación particular y para ese usuario. Si la clave de seguridad es legitima, el servidor de facturación 903 almacena los datos de facturación puros en un depósito de datos 906. El servidor de facturación 903 puede, de manera opcional, procesar posteriormente los datos de facturación de conformidad con las reglas de negocios almacenadas, por ejemplo, en el depósito 906. Alguien experto en la técnica reconocerá que los depósitos de datos están separados como se muestra como mera ilustración, y que se pueden usar otras combinaciones, tal como un solo depósito de datos. Además, el servidor proxy 902 puede almacenar los datos de facturación puros de manera directa, para que se les procese de manera asincrónica mediante el servidor de facturación 903. El programa de contabilidad 904 recupera los datos de facturación (puros o procesados posteriormente) desde el depósito de datos 906 y opcionalmente usa reglas de negocios de anulación, por ejemplo, como se almacenan en el depósito de datos 907, para procesar adicionalmente los datos de facturación y para generar los registros de datos de llamada (cliente) 908. Las reglas de negocios de anulación pueden incluir, por ejemplo, la aplicación especifica o anulaciones del suscriptor, promociones, etcétera. La Figura 10 es un diagrama de flujo de ejemplo de una rutina del cliente para enviar datos a una red que se ha modificado para recolectar un transmitir datos de facturación. Esta rutina ilustra el código de la red proxy de ejemplo que reemplaza algún tipo de llamada de la red "send_data" ( enviar_datos") . Se incluye una implementación de seudo-código de ejemplo del código de la red proxy que envía datos a través de una red como el Apéndice B. La rutina rastrea y acumula la cantidad de datos que se está enviando y, cuando la cantidad acumulada corresponde con la regla de negocios que se incorpora dentro de la rutina para la frecuencia/intervalo para colocar los datos de facturación, entonces se colocan los datos de facturación. De manera específica, en el paso 1001, la rutina determina la cantidad de datos que se va a enviar en el paquete actual y los acumula (por ejemplo, en una variable "data_out" ["datos_fuera"] ) . En el paso 1002, la rutina almacena la cantidad de datos en el paquete actual junto con una estampa de tiempo, el identificador de la aplicación, y la clave de seguridad en el almacén local. En el paso 1003, la rutina determina si es tiempo de colocar los datos (por ejemplo, si ha pasado el intervalo de tiempo/frecuencia que se codificó para colocar los datos) y, si es asi, continúa en el paso 1004 para colocar los datos de facturación en el servidor proxy, de otra manera continúa en el paso 1006. En el paso 1006, la rutina determina si la regla de negocios para colocar los datos basados se basa en cómputo (que se basa en la cantidad de datos) y, si es asi, si el cómputo es mayor que la regla que se indicó para colocar los datos. Si es asi, entonces la rutina continúa en el paso 1005, de otro modo continúa en el paso 1007. En el paso 1005, la rutina reajusta el contador de la cantidad de datos y continúa en el paso 1004 para colocar los datos de facturación en el servidor proxy. En el paso 1007, la rutina envía los datos usando la llamada de la red original que se codificó dentro de la aplicación, y después regresa. La Figura 11 es un diagrama de flujo de ejemplo de una rutina del cliente para recibir los datos desde una red que se ha modificado para recolectar y transmitir datos de facturación. Esta rutina ilustra el código de la red proxy de ejemplo que reemplaza algún tipo de llamada de la red "receive_data" ("recibir_datos") . Se incluye una implementación de seudo-código de ejemplo del código de la red proxy que recibe los datos a través de una red como el Apéndice C. La rutina intercepta la llamada de la red V1receive_data" original, rastrea y acumula la cantidad que corresponda con la regla de negocios que se incorporó dentro de la rutina para la frecuencia/intervalo para colocar los datos de facturación, después se colocan los datos de facturación. De manera especifica, en el paso 1101, la rutina recibe los datos usando la llamada de la red original e intercepta el regreso. Después, en el paso 1102, el regreso determina si la llamada de la red original fue exitosa y, si fue asi, continúa en el paso 1103, de otro modo regresa un error. En el paso 1103, la rutina determina la cantidad de datos que se recibió en el paquete y los acumula (por ejemplo, en una variable "data_in" ["datos_dentro"] ) . En el paso 1104, la rutina amacena la cantidad de datos en el paquete que se recibió junto con una estampa de tiempo, el identificador de la aplicación, y la clave de seguridad en el almacén local. En el paso 1105, la rutina determina si es tiempo de colocar los datos (por ejemplo, si ha pasado el intervalo que se codificó de tiempo/frecuencia para colocar los datos) y, si es así, continúa en el paso 1106 para colocar los datos de facturación en el servidor proxy, de otra manera continúe en el paso 1107. En el paso 1107, la rutina determina si la regla de negocios para colocar los datos basados se basa en cómputo (que se basa en la cantidad de datos) y, si es asi, si el cómputo es mayor que la , regla que se indicó para colocar los datos. Si es asi, entonces la rutina continúa en el paso 1108, de otra manera regresa. En el paso 1108, la rutina reajusta el contador de la cantidad de datos y continúa en el paso 1106 para colocar los datos de facturación en el servidor proxy, y después regresa. La Figura 12 es un diagrama de flujo de ejemplo de una rutina del servidor para procesar los datos de facturación que se basan en transmisión. Esta rutina se puede realizar, por ejemplo, mediante un servidor de facturación, tal como el servidor de facturación 903 en la Figura 9 o mediante un servidor proxy, tal como el servidor proxy 902 en la Figura 9. Alguien experto en la técnica reconocerá que los pasos que se incluyen aquí son simplemente ilustrativos, y que se pueden sustituir los diferentes pasos por, o combinarse con estos pasos, dependiendo de la configuración y la integración de las funciones del PBBS en un ambiente circundante. En el paso 1201, la rutina recibe los datos de facturación que se colocaron desde un dispositivo del cliente. En el paso 1202, la rutina extrae la clave de seguridad, el identificador de la aplicación, y la interfase del usuario desde los datos de facturación. La rutina, en el paso 1203, compara entonces esta información con el identificador de la aplicación y el identificador del usuario que se asocia con esa clave de seguridad en una tabla del depósito de datos de clave de seguridad. En el paso 1204, si la información de la clave de seguridad coincide, la rutina continúa en el paso 1206, de otro modo los datos de facturación se desechan en el paso 1205, y la rutina regresa. En el paso 1206, la rutina almacena los datos de facturación (o transmite los datos de facturación a un servidor de facturación) . En las modalidades en las cuales los dispositivos están restringidos a la comunicación con un sistema del servidor, entonces en el paso 1207, la rutina detecta y transmite los paquetes de datos que se designaron para otros servidores, y después regresa. La Figura 13 es un diagrama de flujo de ejemplo de los pasos para generar cargos de facturación que se basan en los datos de facturación que se basan en transmisión. Esta rutina se puede realizar, por ejemplo, mediante un programa de contabilidad, tal como el Programa de Contabilidad 904 en la Figura 9. Los pasos que se muestran aquí se pueden aplicar generalmente para procesar registros de facturación; sin embargo, dependiendo de los específicos del portador u otro proveedor de contenido que esté determinando las cuotas de facturación, la aplicabilidad y el formato de los registros de datos del cliente (llamada) , se pueden incluir varios pasos adicionales o diferentes. En el paso 1301, la rutina recupera los datos de facturación que se basan en transmisión. En el paso 1302, la rutina determina las reglas de negocios que se pueden aplicar para el identificador de aplicación que se indicó y el identificador del usuario. En el paso 1303, la rutina determina si existen reglas de política/negocios de anulación, por ejemplo, promociones, descuentos, etcétera, y si es asi, continúa en el paso 1304 para determinar las reglas de anulación, de otro modo continúa en el paso 1305. En el paso 1305, la rutina aplica cualesquier reglas de negocios determinadas y genera registros de datos de la llamada. El formato de estos registros depende altamente de que se haya integrado cualquier sistema de facturación que se basa en transmisión dentro de, por ejemplo, un sistema de facturación ya existente dentro de una infraestructura portadora inalámbrica . ? partir de lo anterior se apreciará que, aunque en la presente se han descrito modalidades especificas de la invención para propósitos de ilustración, se pueden hacer diferentes modificaciones sin desviarse del espíritu y el alcance de la invención. Por ejemplo, alguien experto en la técnica reconocerá que los métodos y sistemas en la presente se pueden aplicar a sistemas de abastecimiento de contenido y el sistema de facturación que se basa en transmisión a través de cualquier red, cableada o inalámbrica, o aún una pluralidad de estas redes. Alguien experto en la técnica también reconocerá que los métodos y sistemas que se describen en la presente se pueden aplicar a diferentes protocolos, medios de comunicación (ópticos, inalámbricos, cable, etcétera) y dispositivos del suscriptor (tal como microteléfonos inalámbricos, organizadores electrónicos, asistentes digitales personales, máquinas de correo electrónico portátiles, máquinas de juego, localizadores, dispositivos de navegación tales como receptores GPS, etcétera) . Los aspectos de la invención se pueden modificar, si es necesario, para emplear los métodos, sistemas y conceptos de estas diferentes patentes, aplicaciones y publicaciones para proporcionar todavía modalidades adicionales de la invención. Además, aquellos expertos en la técnica entenderán cómo hacer cambios y modificaciones a los métodos y sistemas que se describen para cumplir sus requerimientos o condiciones específicos .

Apéndice A (connection_setup_proxycode) (conexión instalación_códigoproxy) * METODOS DE INSTRUMENTACION * Aqui hay métodos de ejemplo que se instrumentarán a la aplicación * (en seudo-código) * este el método de reemplazo para Conector . abierto (Cadena) * regresar el error de conexión original agregar conexión * a la lista de conexiones de la red si es una conexión de la red */ Conexión estática pública abierta (nombre de Cadena) lanza IOExcepción { Conexión con = Conector . abierto (nombre) ; Si (nombre .empiezacon ("hhtp : //") || nombre . empiezacon ("sóquet : //") ) { Conexionred . agregarElemento ( con) ; } regresar con; } * este es el método de reemplazo para Conecto . abierto (Cadena, int) * Regresar error de conexión original agregar conexión * a la lista de conexiones de la red si es una conexión de la red */ Conexión estática pública abierta (nombre de Cadena, modo int) lanza IOExcepción { Conexión con = Conector . abierto (nombre, modo); Si (nombre. empiezacon ("hhtp: //") || nombre . empiezacon ( "sóquet : //") ) { Conexiónred . agregarElemento (con) ; } regresar con; } /** * este es el método de reemplazo para Conector . abierto (Cadena, int) * Regresar error de conexión original agregar conexión * a la lista de conexiones de la red si es una conexión de la red */ Conexión estática pública abierta (nombre de Cadena, modo int, intervalos booleanos) lanza IOExcepción Conexión con = Conector . abierto (nombre, modo, intervalos); Si (nombre . empiezacon ("hhtp : //") I I nombre . empiezacon ( "sóquet : //" ) ) { Conexiónred . agregarElemento ( con) ; } regresar con; } /** * este es el método de reemplazo para el método Conexión . cerrar () . * Este método removerá cualquier conexión a la red a partir de la lista * cuando esté cerrado */ vació estático público cerrado ( conexión con) lanza IOExcepción { _Conexiónred. removerElemento (con) ; con . cerrar ( ) ; } Apéndice B (send_proxycode) (enviar_códigoproxy) Nota: el seudo-código en este archivo son extractos del archivo de código original que administra la recepción y el envió de los datos . /* enviar datos al anfitrión remoto original (como lo especificó el código original) * con — conexión original que se creó para comunicarse con el anfitrión * dgram - El datagrama que se va a enviar. */ enviar vacio estático público (ConexiónDatagrama con, Datagrama dgram) lanza IOExcepción { con . enviar (dgram) ; // incrementar el total de bytes enviar incrementarBytesEnviados (dgram. obtenerLongitud ( ) ) ; } /* * Incrementar el contador interno por número de bytes enviados al * anfitrión remoto. */ vacio estático público incrementarBytesEnviados (bytes largos) { sincronizado (_0bj sincronizado) { _totalBytesEnviados += bytes; // siempre guardamos info de facturación la primera vez si ( (Sistema. HoraactualMilis () - _hora) > 60* 1000) { faseuno ( ) ; _hora = Sistema . Horaactualmilis () ; } } } /** * Esta fase guardará la info de la lista de datos para rms */ vacio estático privado faseunoO { tratar { // verificar las memorias caché si ( (_últimosBytesEnviados = -1) && (_útimosBytesrecibidos = -i) ) { cargarlnfoFacturació ( ) ; } // guardar info de facturación nueva y actualizar memorias caché guardarlnfoFacturación ( ) ; // realizar autoenvio este código se puede sacar dependiendo del dispositivo si (Sistema . Horaactualmilis ( ) - _registrarHoraAlmacena-miento > 24*60*60*1000) { faseDos ( ) ; } } atrapar (Excepción e) { } } /** * enviar info de facturación desde rms a servidor MAS */ vacio estático público faseDos() { tratar{ // verificar las memorias caché si (_últimosBytesEnviados = -1) && (_últimosBytes Recibidos = -1) ) { cargarlnfoFacturación () } // obtener total _últimosBytesEnviados += _totalBytesEnviados; _últimosBytesRecibidos += _totalBytesRecibidos // enviar info de facturación autoEnviarlnfoFacturación ( ) ; // envío de datos exitoso así es que despejar el rms despej arAlmacénRegistros () ; } atrapar (Excepción e){} } / -k-k * Este método cargará el registro de facturación de paquete base en la memoria caché y * mantendrá la info de facturación en el almacén de registros * Este método lo usarán la faseüno y la faseDos * */ vacío estático privado cargarlnfoFacturación ( ) { tratar { sincronizado (_Obj sincronizado) { AlmacénRegistros Almacénregistros = AlmacénRegistros . abrirAlmacénRegistros (REGISTRO_ALMACE _ NOMBRE, verdadero) ; id int = Almacénregistros . obtenerSiguientelDRegistro ( ) -1; registro byte [] = Almacénregistros . obtenerRegistro (id) ; Fluj oEntradaConfiguracionByte bis = Fluj oEntradaConfi-guraciónByte nuevo (registro) ; Fluj oEntradaDatos dis = Fluj oEntradaDatos nuevo (bis); // cargar info de facturación _últimosBytesRecibidos = dis . leerLargo ( ) ; _últimosBytesEnviados = dis . leerLargo () ; _registrarHoraAlmacenamiento = dis . leerLargo () ; // cerrar flujo entrada y almacén de registros // no se necesita cerrar Fluj oEntradaConfiguracionByte registrarAlmacén. cerrarAlmacénRegistros () ; } } atrapar (Excepción e) { // no hay nada en el almacén de registros. Dar datos de nicialización _últimosBytesRecibidos = 0; _últimosBytesEnviados = 0; registrarHoraAlmacenamiento = Sistema . HoraactualMilis () ; } } /** * Guardar rms de info de facturación nueva + lista de datos después borrar el registro anterior y actualizar * memorias caché */ vacio estático privado guardarlnfoFacturacion ( ) lanza ExcepcióAlmacénRegistrosNoEncontrado, Excepción AlmacénRegistros , ExcepciónlO, ExcepciónAlmacénRegistros Completo { AlmacénRegistros Almacénregistros = nulo registro byte [] = nulo sincronizado (_0bj sincronizado) { // guardar la info nueva Almacénregistros = AlmacénRegistros . abrirAlmacén Registros (REGISTRO_ALMACEN_NOMBRE, verdadero) : FlujoSalidaConfiguraciónByte bos = Fluj oSalidaConfiguración Byte nuevo (24) ; Flu oSalidaDatos dos = Fluj oSalidaDatos nuevo (bos ); // guardar bytes recibidos nuevos = últimos recibidos + lista de datos dos . escribirLargo (_últimosBytesRecibidos + _totalBytes Recibidos) ; // guardar bytes enviados nuevos = últimos enviados + lista de datos dos . escribirLargo (_últimosBytesRecibidos + _totalBytes Enviados) ; // guardar hora dos . escribirLargo (_registrarHoraAlmacenamiento) ; // guardar registrar = bos . aConfiguraciónByte ( ) ; registrarAlmacén . agregarRegistro (registro, 0, registro, longitud) ; // ya se guardó registro nuevo así es que actualizar última info _últimosBytesRecibidos += _totalBytesRecibidos ; _últimosBytesEnviados += _totalBytesEnviados; // ahora despejar la lista de datos despe arListadeDatos () ; // ya se guardó registro nuevo así es que eliminar el antiguo si (Almacénregistros . obtenerNúmRegistro ( ) > 2) { Almacénregistros . borrarRegistro (Almacénregistros . obtener SiguientelDRegistro ( ) -2) ; } // cerrar flujo de salida y almacén de registros // no se necesita cerrar Fluj oSalidaConfiguraciónByte Almacénregistros . cerrarAlmacénRegistros ( ) ; } } /** * Enviar info de facturación base en paquete a MAS. Después de enviar con éxito * registro de facturación, despejar todos los registros (lista de datos y almacén de registros) * Este método lo usa enviarlnfoFacturacion y guardarlnfo Facturación */ booleano estático privado autoenviarlnfoFacturacion () lanza ExcepciónlO { si (_últimosBytesRecibidos <=0 && -últimosBytesEnviados <=0) { } Cadena es = Cadena eq = "="; si(ESCAPE_URL í=0) { es = ??%26"; eq = %3D"; } BúferCadena buf = BúferCadena nuevo () ; // anexar url anexar . búf (MAS_PAQUETE_BASE_FACTURACION_URL) anexar. búf (es) ; // anexar total bytes enviados anexar. búf ("recibido" + eq) ; anexar. búf (_últimosBytesRecibidos ) ; solicitar Cadena = búf . aCadena ( ) ; Sistema . fuera . imprimirln (solicitud) ; // tratar de enviar info facturación 3 veces int númDeRecuperación = 0; mientras que (númDeRecuperación < 3) { tratar { conexiónHttp con = (conexiónHttp) Conector . abrir (solicitud) ; FlujoEntrada es = con . abrirFluj oEntrada ( ) ; está . cerrado ( ) ; con . cerrado () ; regresar verdadero; } obtener (Excepción e) { númDeRecuperación++; } } // no necesitamos verificar la respuesta si falla la conexión http, // se hará mediante excepción regresar falso; } vacio estático privado despej arAlmacénRegistros ( ) { sincronizado (_Obj sincronizado) { tratar { _últimosBytesRecibidos = 0; _últimosBytesEnviados = 0; AlmacénRegistros Almacénregistros = AlmacénRegistros . abrirAlmacénRegistros (REGISTRO_ ALMACEN_NOMBRE, falso) ; Almacénregistros . borrarRegistro (Almacénregistros . ObtenerSiguientelDRegistro ( ) - 1); Almacénregistros . cerrarAlmacénRegistros () ; // reajustar la hora de almacenamiento de registro _registrarHoraAlmacenamiento = Sistema . Horaactual Milis ( ) ; } atrapar (Excepción e) {} } } // Las variables locales que se usan en la sección de código anterior estático público largo totalBytesEnviados = 0; estático público largo _últimosBytesEnviados = -1; estático público largo totalBytesRecibidos = 0; estático público largo últimosBytesRecibidos= -1 Objeto estático público _Obj sincronizado = Obj eto nuevo ( ) ; estático público largo _hora = 0; estático público largo _registrarHoraAlmacenamiento = 0 vector estático público _Conexiónred - vector nuevo 111111111111111111111111111111111111111111111 / 111111 ! I / 111111 /////// Constructor Público FlujoSalidaFacturación público (FlujoSalida fuera) { _Flujosalida = fuera; } ///////////////////////////////////////////////////////////// /////// Miembros Públicos (Métodos de Acceso) escribir vacio público (int b) lanza ExcepciónlO { _Fluj osalida . escribir (b) ; _totalBytesenviados++; incremento ( ) ; } escribir vacio público (byte [] b) lanza Excepción 10 { _Flujosalida . escribir (b) ; _totalBytesEnviados += b. longitud; incremento ( ) ; 1 escribir vacio público (byte [] b, int apagado, int len) lanza Excepción 10 { _Fluj osalida . escribir (b, apagado, len); _totalBytesEnvíados += len; incremento ( ) ; } vaciar vacío público (byte [] b) lanza ExcepciónlO { _Fluj osalida . vaciar ( ) ; } cerrar vacío público () lanza ExcepciónlO { // guardar bytes enviados totales si (_totalBytesEnviados > 0) { FacturaciónBasePaquete . incrementarBytesEnviados (_totalBytesEn viados) ; } // reajustar el total de bytes enviados en caso cerrar ( ) se llama nuevamente _totalBytesEnviados = 0 _Fluj osalida . cerrar ( ) ; } incrementar vacío privado ( ) { si ( totalBytesSnviados > PAQUETE) { FacturaciónBasePaquete . incrementarBytesEnviados (_totalBytesEn viados) ; _totalBytesEnviados = 0; } } ¡ 1111 ¡ 11111111111111 ¡ 11111111111111111 ! 1111111 ¡ 111111111 i 11 II /////// Campos Privados FlujoSalida privado _Fluj osalida; Privado largo _totalBytesEnviados = 0; Int estático final privado PAQUETE = 10; Apéndice C (receivejproxycode) . txt (recibir_códigoproxy) .t t Nota: El seudo-código en este archivo son extractos del archivo de códigos original que administra la recepción y el envío de los datos .

/* * Este código proxy permite la conexión original para obtener los datos y después * incrementa el contador interno para registrarla. * con — conexión original que se creó para comunicarse con * dgram anfitrión - El datagrama que se va a enviar. */ recibir vacío estático público (conexiónDatagrama con, Datagrama dgram) lanza ExcepciónlO { con. recibir (dgram) ; incrementarBytesRecibidos (dgram. obtenerLongitud ( ) ) ; } vacío estático público incrementarBytesRecibidos (bytes largos ) { sincronizado (_0bj sincronizado) { _totalBytesRecibidos += bytes; // siempre guardamos info de facturación la primera vez si ( (Sistema. HoraactualMilis () - _hora) > 60*1000) { // guardar info de facturación f seüno ( ) ; _hora = Sistema . HoraactualMilis () ; } } } /** * Esta fase guardará la lista de datos en rms */ vacio etático privado faseUnoO { tratar { // verificar las memorias caché si ( (_últimosBytesEnviados = -1) && (_últimosBytes Recibidos = -1) ) { cargarlnfoFacturación ( ) ; } // guardar info de facturación nueva y actualizar memorias caché guardarlnfoFacturación ( ) ; // sí autoenviar este código se puede sacar dependiendo del dispositivo si (Sistema. HoraactualMilis () - _registrarHoraAlmacena-miento > 24*60*60*1000) { faseDos ( ) ; } } atrapar (Excepción e) {} } j -k * * enviar info de facturación desde rms a servidor MAS */ vacío estático público faseDosO { tratar { // verificar las memorias caché si ( (_últimosBytesEnviados = -1) && (_últimosBytesRecibidos = -i) ) { cargarlnfoFacturació ( ) ; } // obtener total _últimosBytesEnviados += _totalBytesEnviados; últimosBytesRecibidos += _totalBytesRecibidos ; // enviar info de facturación autoenviarlnfoFacturacion ( ) ; // envió exitoso de datos asi es que despejar el rms despej arAlmacénRegistros () ; } atrapar (Excepción e) {} * * * Este método cargará el registro de facturación base en aquete en la memoria caché y * mantiene la info de facturación en el almacén de registros * Este método lo usarán la faseüno y la faseDos * */ vacio estático privado cargarlnfoFacturacio ( ) { tratar { sincronizado (_0bj sincronizado) { AlmacénRegistros Almacénregistros = AlmacénRegistros . abrirAlmacénRegistros (REGISTR0_ ALMACEN NOMBRE, verdadero) ; id int = Almacénregistros . obtenerSiguientelDRegistro ( ) -1; registro byte [] = Almacénregistros . obtener Registro (id) ; FlujoEntradaConfiguraciónByte bis= Fluj oEntradaConfi-guraciónByte nuevo (registro) ; Fluj oEntradaDatos dis = Fluj oEntradaDatos nuevo (bis); // cargar info de facturación _últimosBytesRecibidos = dis . leerLargo ( ) ; _últimosBytesEnviados = dis . leerLargo () ; _registrarHoraAlmacenamiento = dis . leerLargo () ; // cerrar flujo entrada y almacén de registros // no se necesita cerrar FlujoEntradaConfiguraciónByte registrarAlmacén. cerrarAlmacénRegistros () ; } } atrapar (Excepción e) { // no hay nada en el almacén de registros. Dar datos de inicialización _últimosBytesRecibidos = 0; _últimosBytesEnviados = 0; _registrarHoraAlmacenamiento = Sistema .HoraactualMilis () ; } } /* * * Guardar rms de info de facturación nueva + lista de datos después borrar el registro anterior y actualizar * memorias caché */ vacio estático privado guardarlnfoFacturación ( ) lanza AlmacénRegistros lanza ExcepcióAlmacénRegistrosNoEncontrado, Excepción AlmacénRegistros, ExcepciónlO, ExcepciónAlmacénRegistros Completo { AlmacénRegistros Almacénregistros = nulo registro byte [] = nulo sincronizado (_0bj sincronizado) { // guardar la info nueva Almacénregistros = AlmacénRegistros . abrir lmacén Registros (REGISTRO_ALMACEN_NOMBRE, verdadero) : Fluj oSalidaConfiguraciónByte bos = Flu oSalidaConfiguración Byte nuevo (24) ; Flu oSalidaDatos dos = Fluj oSalidaDatos nuevo (bos); // guardar bytes recibidos nuevos = últimos recibidos lista de datos dos . escribirLargo (_últimosBytesRecibidos + _totalByte Recibidos ) ; // guardar bytes enviados nuevos = últimos enviados + lista de datos dos . escribirLargo (_últimosBytesRecibidos + _totalByte Enviados) ; // guardar hora dos . escribirLargo ( registrarHoraAlmacenamiento) ; // guardar registrar = bos . aConfiguraciónByte ( ) ; registrarAlmacé . agregarRegistro (registro, 0, regist longitud) ; // ya se guardó registro nuevo así es que actualizar última info últimosBytesRecibidos += _totalBytesRecibidos ; últimosBytesEnviados += totalBytesEnviados ; // ahora despejar la lista de datos despej arListadeDatos () ; // ya se guardó registro nuevo asi es que eliminar el antiguo si (Almacénregistros . obtenerNúmRegistro ( ) > 2) { Almacénregistros .borrarRegistro (Almacénregistros . obtener SiguientelDRegistro ( ) -2); } // cerrar flujo de salida y almacén de registros // no se necesita cerrar Fluj oSalidaConfiguraciónByte Almacénregistros . cerrarAlmacénRegistros ( ) ; } } /** * Enviar info de facturación base en paquete a MAS. Después de enviar con éxito * registro de facturación, despejar todos los registros (lista de datos y almacén de registros) * Este método lo usa enviarlnfoFacturacion y guardarlnfo Facturación */ booleano estático privado autoenviarlnfoFacturacion () lanza ExcepciónlO { si (_últimosBytesRecibidos <=0 && -últimosBytesEnviados <=0) { regresar verdadero; } Cadena es = Cadena eq = "="; si (ESCAPE_URL !=0) { es = "%26"; eq = "%3D"; } BúferCadena buf = BúferCadena nuevo ( ) ; // anexar url anexar. búf (MAS_PAQUETE_BASE_FACTURACION_URL) ; anexar . búf ( es ) ; // anexar total bytes enviados anexar. búf ("recibido" + eq) ; anexar .búf (_últimosBytesRecibidos) ; solicitar Cadena = búf . aCadena ( ) ; Sistema . fuera . imprimirln (solicitud) ; // tratar de enviar info facturación 3 veces. int númDeRecuperación = 0; mientras que (númDeRecuperación < 3) { tratar { conexiónHttp con = (conexiónHttp) Conector . abrir (solicitud) ; FlujoEntrada es = con . abrirFluj oEntrada ( ) ; // cerrar entrada y conexión está . cerrada ( ) ; con . cerrada ( ) ; regresar verdadero; } obtener (Excepción e) { númDeRecuperación++; } } // no necesitamos verificar la respuesta si falla la conexión http, // se hará mediante excepción regresar falso; } vacio estático privado despe arAlmacénRegistros ( ) { sincronizado (_Obj sincronizado) { tratar { _últimosBytesRecibidos = 0; _últimosBytesEnviados = 0; AlmacénRegistros Almacénregistros = AlmacénRegistros . abrirAlmacénRegistros (REGISTRO AL ACEN_NOMBRE, falso) ; Almacénregistros .borrarRegistro (Almacénregistros . ObtenerSiguientelDRegistro ( ) - 1); Almacénregistros . cerrarAlmacénRegistros () ; // reajustar la hora de almacenamiento de registro _registrarHoraAlmacenamiento = Sistema . Horaactual Milis ( ) ; } atrapar (Excepción e) {} } } // Las variables locales que se usan en la sección de código anterior estático público largo totalBytesEnviados = 0; estático público largo últimosBytesEnviados = -1; estático público largo totalBytesRecibidos = 0; estático público largo últimosBytesRecibidos= -1 Objeto estático público Obj sincronizado = Objeto nuevo ( ) ; estático público largo _hora = 0; estático público largo _registrarHoraAlmacenamiento = 0 vector estático público _Conexiónred = vector nuevo (3); clase pública Fluj oEntradaFacturacion extiende FlujoEntrada { Fluj oEntradaFacturacion (FlujoEntrada es) { _es = es; } ///////////////////////////////////////////////////////////// ¡II//// Miembros Públicos (Métodos de Acceso) leer int público ( ) lanza ExcepciónlO { r int = _es.leer(); si(r != -1) { _totalBytesRecibidos++; } incrementar ( ) ; regresar r; } int público disponible () lanza ExcepciónlO { regresar _está . disponible () ; } vacio público marcar (limitelectura int) { _es .marca (limitelectura) ; } booleano público marcarSoportado ( ) { regresar _es .marcaSoportado ( ) ; } int público leer (byte [] ) lanza ExcepciónlO { i int = _es . leer (b) ; _totalBytesRecibidos += i; incrementar ( ) ; regresar i; } int público lee (byte [] b, int apagado, int len) lanza ExcepciónlO { i int = _es.leer(b, apagado, len) ; _totalBytesRecibidos += i; incrementar ( ) ; regresar i; } salto largo público (n largo) lanza ExcepciónlO { regresar _es . salto (n) ; } vacio público reajustar () lanza ExcepciónlO { _es . reajuste () ; } vacio público cerrar ( ) lanza ExcepciónlO { // guardar el total de bytes recibidos si (_totalBytesRecibidos > 0) { FacturaciónBasePaquete . incrementarBytesRecibidos ( BytesRecibidos ) ; } // reajustar el total de bytes recibidos en caso suelto () se llame nuevamente _totalBytesRecibidos = 0 _está . cerrado ( ) ; } vacio privado incrementar ( ) { si (_totalBytesRecibidos > PAQUETE) { FacturaciónBasePaquete .incrementarBytesRecibidos (_total BytesRecibidos) ; _totalBytesRecibidos = 0; } } ///////////////////////////////////////////////////////////// /////// Campos Privados FlujoEntrada privado _es; Privado largo _totalBytesRecibidos = 0; int estático final privado PAQUETE = 10; } APENDICE D MANTENIENDO Y DISTRIBUYENDO APLICACIONES INALAMBRICAS Las modalidades de la presente invención proporcionan métodos y sistemas basados en computadoras y basados en la red, para mantener y abastecer aplicaciones inalámbricas. El abastecimiento, como se describe en la presente, es la personalización y distribución de contenido para un uso particular, por ejemplo, para usarse en una clase particular de dispositivo de suscriptor por parte de un cliente particular. En una modalidad de ejemplo, se proporciona un Sistema Móvil de Aplicaciones (MAS, por sus siglas en inglés) . El MAS es una reunión de componentes del servidor interoperantes que trabajan individualmente y juntos de una manera segura para proporcionar aplicaciones, recursos, y otro contenido a dispositivos suscriptores móviles. El MAS permite, por ejemplo, que dispositivos inalámbricos, tales como teléfonos celulares y dispositivos microtelefónicos , descarguen dinámicamente aplicaciones nuevas y actualizadas desde el MAS para usarlas en sus dispositivos. La capacidad de descarga dinámica reduce significativamente los requerimientos de tiempo - a - mercado para los desarrolladores de aplicaciones inalámbricas (proveedores de contenido) y da como resultado mayores eficiencias en el soporte y mercadeo del producto. Los clientes son capaces de actualizar rápida y convenientemente el software operativo en sus dispositivos inalámbricos y descargar aplicaciones populares (incluso juegos) . Con el MAS, los clientes son capaces de actualizar sus dispositivos microtelefónicos inalámbricos directamente desde la red, y mediante lo mismo evitar la experiencia consumidora de tiempo de hablar a un representante de servicios al cliente, o visitar un centro de servicio local para actualizar el software. El MAS también soporta escenarios de facturación flexibles, incluyendo facturación de suscripción, lo que le permite a los clientes suscribirse a un servicio particular para recibir únicamente aquellos recursos o aplicaciones que ellos deseen. Aunque las capacidades del MAS generalmente se pueden aplicar a cualquier tipo de dispositivo inalámbrico del cliente, uno de experiencia en la técnica reconocerá que términos tales como dispositivo de suscriptor, dispositivo del cliente, teléfono, de mano, etcétera, se usan intercambiablemente para indicar cualquier tipo de dispositivo de suscriptor que sea capaz de operar con el MAS. En adición, las modalidades de ejemplo que se describen en la presente proporcionan aplicaciones, herramientas, estructuras de datos y otro soporte para implementar el mantenimiento y la distribución de aplicaciones inalámbricas sobre una o más redes. Un experto en la técnica reconocerá que se pueden usar otras modalidades de los métodos y sistemas de la presente invención para otros muchos propósitos, que incluyen el mantenimiento y la distribución de software y otro contenido a través de redes no inalámbricas, tales como la Internet, a dispositivos suscriptores no inalámbricos, tales como una computadora personal, un microteléfono inalámbrico acoplado, teléfonos con conectividad a la Internet, o quioscos de cliente, por ejemplo, adentro de aeropuertos o centros comerciales. En adición, aunque esta descripción se refiere principalmente al contenido en la forma de aplicaciones y recursos, un experto en la técnica reconocerá que el contenido puede contener texto, gráficos, audio y video. Además, en la siguiente descripción, se declaran numerosos detalles específicos, tales como formatos de datos, despliegues visuales en pantalla de interfase de usuario, flujos de códigos, opciones de menú, etcétera, con el propósito de proporcionar un entendimiento profundo de las técnicas de los métodos y sistemas de la presente invención. Un experto en la técnica reconoce, no obstante, que la presente invención también se puede practicar sin algunos de los detalles específicos descritos en la presente, o con otros detalles específicos, tales como cambios con respecto al ordenamiento del flujo de códigos, o las características específicas que se muestran en los despliegues visuales en pantalla de la interfase de usuario. La Figura 1 es un diagrama de bloques de ejemplo que ilustra cómo los suscriptores de servicios inalámbricos solicitan y descargan aplicaciones de software desde un Sistema Móvil de Aplicaciones. El medio ambiente inalámbrico en el cual opera el MAS incluye los dispositivos de suscriptor 101 y 101b, la red inalámbrica 102 con el transmisor - receptor 103, los servicios portadores inalámbricos 104, el MAS 105, y diferentes proveedores de contenido 106. Los proveedores de contenido 106 proporcionan aplicaciones al MAS 105, a través de, o por el permiso de los servicios portadores 104. Entonces se verifican, publican y abastecen las aplicaciones a los dispositivos suscriptores 101 por medio del MAS 105 cuando se soliciten. En la presente se hace referencia a este tipo de abastecimiento como el abastecimiento de "jardín amurallado", porque las aplicaciones que se abastecen y se publican de esta manera son conocidas para la infraestructura del portador y/o el MAS. Los proveedores de contenido 106 también pueden hospedar aplicaciones que pueden navegar los dispositivos suscriptores, a los cuales se puede abastecer dinámicamente mediante el MAS 105. En la presente se hace referencia a este tipo de abastecimiento como abastecimiento "abierto", porque éste no está restringido a aplicaciones "conocidas" dentro de los confines de la infraestructura del MAS o portador. Estas distinciones se hacen sólo para conveniencia de la descripción, puesto que los diferentes tipos de abastecimiento comparten muchas funciones similares . El MAS 105 también proporciona una multitud de herramientas para los portadores, proveedores de contenido, representantes de atención a clientes, y suscriptores para la personalización de las aplicaciones, servicios, y escenarios de facturación disponibles para suscriptores o grupos de suscriptores específicos . En la Figura 1, los dispositivos suscriptores comprenden dispositivos electrónicos capaces de comunicación a través de la red inalámbricas 102, tales como microteléfonos inalámbricos, teléfonos, organizadores electrónicos, asistentes digitales personales, máquinas de correo electrónico portátiles, máquinas de juegos, localizadores, dispositivos de navegación, etcétera, sea que existan actualmente o no. Uno o más de los dispositivos suscriptores 101 (a los que también se hace referencia como dispositivos de cliente) se comunican a través de la red inalámbricas 102 con los servicios portadores inalámbricos 104, cuyos servicios el suscriptor ha hecho arreglos para usarlos. La red inalámbrica 102 tiene un transmisor receptor 103, el cual se usa para retransmitir los servicios a los dispositivos suscriptores 101 (y manejar las solicitudes del suscriptor) . Un experto en la técnica reconocerá que un suscriptor de servicios inalámbricos puede completar algunos o todos los pasos envueltos en la solicitud y descarga de aplicaciones inalámbricas a través de una red inalámbrica, mediante el uso de una red alterna (tal como la Internet) y mediante el uso de dispositivos que tengan un factor de forma más grande, tales como una computadora personal 101b, que pudiera ofrecer interfases más fáciles de usar para descargar las aplicaciones. El transmisor receptor 103 típicamente convierte las comunicaciones inalámbricas a comunicaciones basadas en cables, y convierte las comunicaciones basada en cables a comunicaciones inalámbricas, aunque un experto en la técnica notará que se pueden usar medios y protocolos variables. El transmisor -receptor 103 típicamente se comunica con los servicios portadores 104 a través de un medio basado en. cables, usando un protocolo de comunicación específico al portador. La comunicación específica al portador puede usar cualquier protocolo adecuado para comunicaciones de punto - a - punto tales como el Protocolo de Transporte de Hipertexto (HTTP, por sus siglas en inglés) y el Protocolo de Aplicaciones Inalámbricas (WAP, por sus siglas en inglés) . Los servicios portadores 104 proporcionan servicios que son típicos de una oficina telefónica central, incluyendo contabilidad, POTS (siglas en inglés para "servicio telefónico convencional") y otros servicios telefónicos (tales como adelantamiento de llamadas, ID de la persona que llama, correo de voz, etcétera), y aplicaciones que se pueden descargar. El Sistema Móvil de Aplicaciones 105 se comunica con los servicios portadores 104, por ejemplo, a través de un canal de comunicaciones de amplitud de banda alta 108 o una red públicamente accesible, tal como la Internet 107, para proporcionar aplicaciones abastecidas a los dispositivos suscriptores 101. Un experto en la técnica reconocerá que el Sistema Móvil de Aplicaciones 105 puede estar completa o parcialmente integrado con los servicios portadores 104. Osando el abastecimiento de jardín amurallado, se suministran las aplicaciones que se pueden descargar, las cuales se generan típicamente mediante los proveedores de contenido 106, al Sistema Móvil de Aplicaciones 105 o a los servicios portadores 104 directamente o a través de una red, tal como la Internet 107. Después el Sistema Móvil de Aplicaciones 105 verifica y personaliza estas aplicaciones que se pueden descargar según sea apropiado, y se abastecen para un dispositivo de suscriptor 101. En una modalidad que soporta el abastecimiento abierto, un suscriptor del portador puede descargar una aplicación desde un sitio Web, mediante la especificación de una ubicación (tal como una dirección de la red, o el URL - siglas en inglés para Localizador Uniforme de Recursos) . El MAS intercepta la solicitud descargada desde el suscriptor y entonces localiza, verifica, y abastece la aplicación para el cliente. El dispositivo de suscriptor 101 depende de una utilidad de administración de aplicaciones del lado del cliente (por ejemplo, una Consola de Administración de Microteléfono o un navegador) para solicitar y descargar aplicaciones. La Figura 2 es un diagrama de bloques de ejemplo de una Consola de Administración de Microteléfono que opera con un Sistema Móvil de Aplicaciones. La Consola de Administración de Microteléfono maneja la notificación, instalación, y desinstalación de aplicaciones en el dispositivo inalámbrico del suscriptor. El dispositivo de suscriptor 201 le proporciona al suscriptor un menú de funcionalidad disponible para el dispositivo. El suscriptor puede seleccionar desde el menú las rutinas que, por ejemplo, administren las aplicaciones que ya están instaladas en el dispositivo y presenten nuevas aplicaciones que se puedan descargar. Por ejemplo, las rutinas le pueden permitir al suscriptor obtener información de la versión para las aplicaciones instaladas, descargar actualizaciones para esas aplicaciones cuando lleguen a estar disponibles éstas, y navegar para buscar nuevas aplicaciones para descargarlas. El menú 202 es un menú de ejemplo que muestra una lista de nuevas aplicaciones 203 que se pueden descargar potencialmente al dispositivo de suscriptor 201. El despliegue visual en pantalla 204 de ejemplo muestra una inferíase de usuario de ejemplo que se presenta después de que el suscriptor ha seleccionado una aplicación para descargarla. El despliegue visual de pantalla 204 presenta un icono 205 que ilustra la operación de descarga, el titulo de la aplicación que se está descargando 206, y una barra de estado 207 que despliega visualmente el proceso en progreso de la descarga. La pantalla 204 también presenta un botón de detención 208, el cual permite que se cancele el proceso de descarga . La Figura 3 es un diagrama de flujo general de ejemplo de los pasos generales que realiza un Sistema Móvil de Aplicaciones de ejemplo para abastecer aplicaciones para dispositivos suscriptores inalámbricos. Estos pasos se pueden aplicar a cualquier escenario de abastecimiento - usando abastecimiento de jardín amurallado o abierto. Estos mismos pasos también se pueden usar para abastecer aplicaciones para dispositivos cableados, tales como aquellos conectados a través de la Internet 107 en la Figura 1. Los pasos 301-310 demuestran cómo el MAS maneja una solicitud entrante para descargar una aplicación desde un dispositivo de suscriptor, abastece la aplicación solicitada, y envía la aplicación solicitada al dispositivo de suscriptor. El abastecimiento incluye uno o más de los pasos de recuperación, inspección, optimización, código de instrumentación, y empaquetamiento, y puede incluir los pasos adicionales según sea necesario para preparar una aplicación para descarga a un dispositivo objetivo. Por ejemplo, puesto que se añaden al sistema métodos de seguridad y facturación adicionales, el abastecimiento pudiera incluir pasos para encriptar y reportar información. En donde es distinto, los pasos 301-310 presumen que se está solicitando una aplicación directamente desde el MAS, en oposición a indirectamente mediante la navegación de una ubicación en una red. (En el caso del abastecimiento abierto, el MAS intercepta la solicitud e intenta abastecer y descargar la aplicación como si la estuviera recibiendo por primera vez) . Específicamente, en el paso 301, las aplicaciones se hacen disponibles para descarga, típicamente desde un portador, o directamente desde un proveedor de contenido. Las aplicaciones se pueden escribir usando un lenguaje de computadora, tal como Java, que sea capaz de ejecución en una amplia variedad de dispositivos suscriptores . Las aplicaciones se almacenan localmente en un recipiente de datos de aplicación del portador (el cual puede estar localizado en el MAS o en las instalaciones del portador) , u opcionalmente se almacenan en servidores de terceras partes confiables. (En el caso del abastecimiento abierto, los servidores de terceras partes no son necesariamente confiables) . En el paso 302, el suscriptor envía una solicitud para descargar una aplicación, recuperar una lista de aplicaciones disponibles, realizar alguna consulta administrativa, u otro comando. Se realizan conversiones de protocolos sobre solicitudes entrantes (y mensajes salientes) para habilitar las comunicaciones con los dispositivos suscriptores a través de una amplia variedad de portadores inalámbricos. La aplicación descargada puede ser, por ejemplo, una aplicación nueva y popular o una actualización o una versión más reciente de software que se ejecutará sobre el dispositivo de suscriptor. Las solicitudes se hacen, por ejemplo, usando Localizadores Uniformes de Recursos (URLs) que usan la mensajería HTTP para dirigir las solicitudes. El MAS soporta una máquina de procesamiento de comandos extensible y soporta la invocación directa de los diferentes manej adores, módulos, y otras estructuras que son componentes del MAS, ya sea a través de las solicitudes HTTP, o a través de una interfase de programación de aplicación (una "API", por sus siglas en inglés) . En el caso de una solicitud de abastecimiento de aplicación, la solicitud para descargar un archivo particular se hace mediante la designación de un URL que identifique un archivo (una aplicación o servicio) para descargar. En el caso de una consulta administrativa, se hace una solicitud a, por ejemplo, un servidor secundario administrativo u otro código en el MAS, el cual maneja la solicitud. En el paso 303, el MAS determina si la solicitud es para descargar o para algún otro comando, y, si asi es, continúa en el paso 305, o de otra manera procesa el comando en el paso 304. En el paso 305, el MAS determina si el URL designado especifica una aplicación publicada (indicando mediante lo mismo que se va a realizar el abastecimiento de jardín amurallado) y, si asi es, continúa en el paso 306, o de otra manera continúa en el paso 308. En el paso 306, se verifica la solicitud del suscriptor para ver la autorización, la capacidad del dispositivo, y si es apropiado, la autorización de facturación pagada previamente. El nivel de autorización típicamente depende del nivel de servicio al cual se ha suscrito el cliente. Por ejemplo, en una modalidad el MAS soporta la facturación pagada previamente, lo que le permite al suscriptor pagar por adelantado para el uso de las aplicaciones. En este caso, el MAS verificará que la cuenta de facturación pagada previamente pueda cubrir la solicitud, antes de que se descargue la aplicación. Se pueden aplicar otros factores tales como si se está ofreciendo una oferta promocional, el número de veces que el suscriptor ha accesado el servicio, si existe una oferta por introducción, la hora del día o la semana en que se está accesando ese servicio, el número de bytes que se van a descargar, y otros factores. También se examina la capacidad del dispositivo para determinar si la aplicación solicitada se puede ejecutar satisfactoriamente en el dispositivo de suscriptor. Esto se puede realizar, por ejemplo, por medio de comparar el dispositivo solicitante para saber los perfiles del dispositivo y un perfil de la aplicación para la aplicación solicitada. En el paso 307, el MAS determina si se ha verificado exitosamente la solicitud del suscriptor y, si asi es, continúa en el paso 308, de otra manera éste declina la solicitud y regresa al paso 302 para esperar otra solicitud. En el paso 308, el MAS determina si ya existe una aplicación abastecida previamente que corresponda con la solicitud del suscriptor, y es adecuada para el dispositivo de suscriptor. Una aplicación abastecida previamente es una aplicación que se ha personalizado previamente de conformidad con el nivel de autorización y la capacidad del dispositivo de suscriptor. Las aplicaciones abastecidas previamente, cuando están disponibles, reducen al mínimo la latencia del sistema y mejoran el tiempo de respuesta del sistema para una solicitud de aplicación correspondiente. Las aplicaciones se pueden abastecer previamente de conformidad con los niveles típicos de suscripción de los suscriptores y los dispositivos de suscriptor típicos (según se determina, por ejemplo, por el uso proyectado) y almacenarse para acceso posterior para responder a la solicitud de un dispositivo de suscriptor por una aplicación que corresponda con una aplicación abastecida previamente. Si no se ha abastecido previamente la aplicación, el más abastece la aplicación de manera dinámica, lo cual incrementará el tiempo que se requiere para procesar la solicitud, pero producirá una aplicación personalizada y autorizada para despliegue. En el paso 308, si se ha encontrado una aplicación adecuada abastecida previamente para el dispositivo de suscriptor, el escenario de abastecimiento continúa en el paso 310, de otra manera éste continúa en el paso 309. En el paso 309, se abastece la aplicación para el dispositivo de suscriptor especifico y de conformidad con la autorización de acceso. En el paso 310, el MAS envia fuera la aplicación abastecida al dispositivo de suscriptor para descarga. Como se mencionó, una de las solicitudes que soporta el MAS es recuperar una lista de aplicaciones disponibles que se puedan descargar al dispositivo del suscriptor. Se hace referencia a este proceso como descubrimiento de aplicación. La Figura 4 es un diagrama de flujo general de ejemplo de los pasos que realiza un Sistema Móvil de Aplicaciones de ejemplo para realizar el descubrimiento de aplicación para dispositivos de suscriptor inalámbricos. En una modalidad de ejemplo, se soportan dos tipos de descubrimiento de aplicación. El primero se acciona por el sistema y genera una lista derivada por el sistema. El segundo se acciona por el solicitante y especifica los términos de búsqueda que compara el MAS para generar una lista de aplicaciones "adecuadas". En el paso 401, el MAS determina si el usuario ha suministrado cualesquier términos de búsqueda y, si asi es, continúa en el paso 402, de otra manera continúa en el paso 403. En el paso 402, el MAS busca un recipiente de datos de aplicaciones publicadas para ver aquellas que satisfacen los criterios especificados en la solicitud, y continúa en el paso 404. Alternativamente, en el paso 403, el MAS determina una lista inicial. En una modalidad esta lista se forma a partir de la lista personalizada de un suscriptor si está disponible una, de otra manera el MAS suministra una lista establecida previamente. En el paso 404, el MAS filtra esta lista inicial con base en las capacidades del suscriptor y del dispositivo. Por ejemplo, el MAS puede analizar diferentes perfiles, por ejemplo, un perfil del suscriptor, un perfil del dispositivo, y un perfil de la aplicación, para determinar si el suscriptor está autorizado para usar la aplicación, y si el dispositivo, según se refleja en el perfil del dispositivo, satisface las necesidades de la aplicación, según se reflejan en el perfil de la aplicación. En el paso 405, el MAS añade cualesquier aplicaciones definidas por el sistema a la lista (a la que se hace referencia como la "plataforma de inicio") . Esas aplicaciones se pueden designar de conformidad con las reglas- personalizables del portador, por ejemplo, a las aplicaciones que generan más ingresos se les puede dar tiempo de visión de "mayor importancia" por medio de colocarlas hasta arriba de la lista. En el paso 405, el MAS formatea la lista de conformidad con las capacidades de visión del dispositivo solicitante (por ejemplo, el lenguaje de marcación soportado), y termina el procesamiento. La Figura 5 es un diagrama de bloque general de los componentes de una modalidad de ejemplo de un Sistema Móvil de Aplicaciones . En esta modalidad, el Sistema Móvil de Aplicaciones 500 incluye un Administrador de Protocolos 503, un Administrador de Abastecimiento 504, una Caché 505, un Administrador de Despliegue 506, un Administrador de Facturación 507, un Administrador de Registros 508, un Administrador 509, y un Monitor de Latido 310. Estos componentes interoperan para recibir aplicaciones desde los proveedores de contenido y los servicios portadores, para abastecerlos para envió a los dispositivos de suscriptor, tales como aquellos que se muestran en la Figura 1, y para procesar los comandos del MAS. Un experto en la técnica reconocerá que son posibles muchas diferentes configuraciones y divisiones de funcionalidad de los componentes o diferentes componentes del MAS. Por ejemplo, las funciones asignadas al Administrador de Protocolos 504 y al Administrador de Facturación 507 se pueden combinar en un componente. También son posibles y están contempladas otras configuraciones. Los diferentes componentes del MAS interoperan para proporcionar una multitud de capacidades a los administradores de portadores (o sistemas) o representantes de atención a clientes, quienes administran los servicios que proporciona el portador, los proveedores de contenido que desarrollan y distribuyen las aplicaciones y los servicios a los portadores, y los suscriptores que consumen los servicios, las aplicaciones y otro contenido. El Administrador 509 proporciona diferentes interfases de usuario para cada uno de estos tipos de usuarios para configurar el MAS, las aplicaciones, la facturación y otros servicios, y para personalizar la experiencia de un suscriptor con el MAS. Para ilustrar los aspectos del abastecimiento, se describe la funcionalidad del MAS desde el punto de vista de los pasos del procesamiento que ocurren en los componentes del MAS cuando un suscriptor invoca el MAS para descargar aplicaciones al dispositivo del suscriptor, a} como se describe con referencia a la Figura 3. Un experto en la técnica reconocerá que son apropiados otros flujos de datos y usos de los componentes, y depende de los comandos procesados y/o de cómo se invoquen los componentes, o el código adentro de ellos. Más específicamente, en la modalidad de ejemplo que se muestra en la Figura 5, las comunicaciones desde los dispositivos de suscriptor, tales como los microteléfonos J2ME o WAP, se presentan a, y se reciben desde el Sistema Móvil de Aplicaciones 500 como la Solicitud Entrante 501 y como los Datos Salientes 502, respectivamente. Típicamente, un suscriptor invoca el MAS por medio de la inferíase de comandos (en oposición a la interconexión basada en el sitio Web) para procesar dos tipos diferentes de solicitudes de entrada: el descubrimiento de aplicaciones y la descarga de una aplicación solicitada. El MAS también se puede invocar para procesar otros comandos. Además, los componentes del MAS se pueden invocar directamente, tal como para realizar solicitudes administrativas para obtener información sobre uso. Cuando la solicitud de entrada 501 es una solicitud para el descubrimiento de aplicaciones, el MAS compila y regresa una lista de aplicaciones que están disponibles y que se basan apropiadamente en el suscriptor, los perfiles de la aplicación, y los perfiles del dispositivo. Los pasos que típicamente ejecuta el MAS para realizar el descubrimiento de aplicaciones se describen con referencia a la Figura 4. Alternativamente, cuando la solicitud de entrada 501 es una solicitud para descargar una aplicación designada, el MAS recupera la aplicación, verifica que ésta sea la apropiada y que esté permitida para descarga a ese dispositivo y usuario, abastece y empaqueta la aplicación solicitada, y envía la aplicación empaquetada al dispositivo de suscriptor solicitante. Los pasos que típicamente ejecuta el MAS para realizar el abastecimiento de aplicaciones se describieron con referencia a la Figura 3. El Administrador de Protocolos 503 realiza la conversión de protocolos de los mensajes entre los dispositivos de suscriptor y el Administrador de Abastecimiento 504. La conversión de protocolos asegura que el MAS 500 pueda comunicarse con cualquier dispositivo de suscriptor (alámbrico o inalámbrico) , independientemente del protocolo de comunicación que se use en la red (tal como la red inalámbrica 102 en la Figura 1) , y permite que se procesen solicitudes entrantes que pudieran estar incrustadas adentro de diferentes protocolos . Un Administrador de Protocolos 503 de ejemplo tiene soporte integrado para los protocolos WAP y HTTP y se puede extender usando técnicas bien conocidas para proporcionar soporte para formatos y protocolos adicionales. Entre el Administrador de Protocolos 503, y la solicitud entrante 501/datos salientes 502 pueden residir una o más puertas de enlace separadas tales como una puerta de enlace WAP (no se muestra) . Estas puertas de enlace se pueden usar para procesar los mensajes dirigidos para un protocolo particular. El Administrador de Protocolos 503 también puede incluir opcionalmente una capa de seguridad de enchufe para manejar la encriptación y desencriptación, asi como la administración certificada para soporte de seguridad de extremo a extremo. Un experto en la técnica reconocerá que el Administrador de Protocolos 503 se puede extender para incluir otros tipos de soporte para comunicaciones seguras según se desee. Después de que se convierte apropiadamente la solicitud entrante, el Administrador de Abastecimiento 504 procesa la solicitud, empleando la ayuda de otros componentes según sea necesario. Por ejemplo, si la solicitud es una consulta administrativa, entonces el Administrador de Abastecimiento 504 puede enviar la solicitud a un servidor secundario administrativo en el MAS. Si, más bien, la solicitud es para una lista de aplicaciones que se pueden descargar al dispositivo de un suscriptor, entonces el Adminis rador de Abastecimiento 504 puede interrogar a los Recipientes de Datos 311 y al código de administración de perfil para generar esa lista, mediante la comparación de las capacidades y los requerimientos de cada aplicación disponible desde el portador con el dispositivo apropiado y los perfiles de suscriptor que correspondan con el dispositivo del suscriptor y el suscriptor. Si, por otra parte, la solicitud es de un suscriptor para descargar una aplicación designada, entonces el Administrador de Abastecimiento 504 y el Administrador de Despliegue 506 interactúan para obtener y preparar la aplicación solicitada para distribución al suscriptor. En una modalidad, el Administrador de Abastecimiento 504 verifica la información del usuario, dispositivo, facturación y aplicación a la que hace referencia la solicitud de un suscriptor, y el Administrador de Despliegue 506 recupera y abastece las aplicaciones . El proceso de abastecimiento de la aplicación que realiza el Administrador de Despliegue 506 comprende uno o más de los siguientes pasos de procesamiento: recuperación, inspección, optimización, instrumentación de código, y empaquetamiento, los cuales se describen posteriormente con referencia a la Figura 7. El Administrador de Abastecimiento 504 recibe solicitudes de suscriptor desde el Administrador de Protocolos 503 y maneja las solicitudes de descarga u otros comandos que estén contenidos en las solicitudes de suscriptor. Las solicitudes de descarga se manejan con base en la información presentada con cada solicitud de descarga y otra información que esté accesible para el MAS (por ejemplo, el almacén de perfiles en el recipiente de datos 511) . Cuando se procesa una solicitud para descargar una aplicación, el Administrador de Abastecimiento 504 examina los perfiles previamente creados o disponibles para el suscriptor, los dispositivos de suscriptor, y la(s) aplicación (es) solicitada (s) y la información relacionada con la facturación, para determinar lo adecuado de la aplicación solicitada para el suscriptor que usa el dispositivo de suscriptor particular, y de conformidad con el método de facturación del suscriptor. Después de inspeccionar los perfiles, el Administrador de Abastecimiento 504 ya sea aprueba o niega la solicitud por medio de intentar evaluar, por ejemplo, si la aplicación solicitada se puede ejecutar exitosamente en el dispositivo del suscriptor. Esta evaluación se realiza, por ejemplo, mediante la determinación de si las capacidades del dispositivo de i suscriptor particular pueden satisfacer los requerimientos de la aplicación. El Administrador de Abastecimiento 504 también determina si se ha establecido el método de facturación para la aplicación solicitada y si el suscriptor es compatible y suficiente para realizar la descarga. Por ejemplo, si la solicitud indica que el suscriptor es parte de un programa de facturación de pago previo, entonces el Administrador de Abastecimiento 504 verifica que los fondos de la cuenta de facturación pagados previamente del suscriptor son suficientes para permitir la descarga de la aplicación. Una vez aprobada, el Administrador de Abastecimiento 504 puede obtener la aplicación solicitada desde ya sea la caché 505 o desde el Administrador de Despliegue 506. Típicamente, la caché 505 se usa para almacenar aplicaciones f ecuentemente descargadas en un formato previamente abastecido, mientras que el Administrador de Despliegue 506 se usa para abastecer las aplicaciones dinámicamente, a medida que se solicitan éstas. Las aplicaciones que se controlan mediante el portador típicamente se abastecen previamente y se almacenan en la caché 505, mientras que las aplicaciones disponibles a través de, por ejemplo, un sitio de Internet, típicamente se abastecen únicamente cuando se solicitan para descarga.

La caché 505 se usa para proporcionar el envío más rápido de la aplicación solicitada al dispositivo de suscriptor. La caché 505 se usa para colocar en memoria caché las aplicaciones abastecidas que se han procesado con anticipación para perfiles específicos, tales como para dispositivos de suscriptor específicos o de conformidad con acceso autorizado. Las aplicaciones almacenadas en la caché 505 que ya se han inspeccionado, optimizado, e instrumentado, se etiquetan como estando listas para despliegue. Un experto en la técnica reconocerá que el funcionamiento del sistema se puede mejorar mediante la implementación de funcionalidad de colocación en memoria caché similar entre otros componentes del MAS también. Por ejemplo, una caché para contener las aplicaciones de Internet, la cual resida entre el Administrador de Despliegue y la Internet, pudiera reducir el tiempo de acceso que se requiere para comunicación con las aplicaciones de Internet. Además, por ejemplo, se podría implementar una caché para contener los archivos JAR no archivados para acelerar el proceso de instrumentación. También son posibles otras configuraciones . Si en la caché 505 no se encuentra una aplicación solicitada aprobada para un suscriptor particular y un dispositivo particular, ésta se puede recuperar por medio del Administrador de Despliegue 506. El Administrador de Despliegue 506 prepara las aplicaciones para envío a un dispositivo de suscriptor. El Administrador de Despliegue 506 administra muchas facetas de la preparación, mantenimiento, y abastecimiento de aplicaciones, tales como la detección de aplicación maliciosa, uso restringido de la API, soporte para la distribución de ensayos (uso permitido para únicamente un número establecido de veces o un periodo de tiempo establecido) y otros métodos de facturación, optimización del tamaño de la aplicación para los dispositivos de suscriptor solicitantes, y otras facetas. El Administrador de Despliegue 506 obtiene aplicaciones y abastece cada instancia de aplicación para su uso pretendido (solicitado) cuando se solicita una instancia de una aplicación. Este también pudiera desplegar previamente ("provisión previa") aplicaciones para dispositivos y/o perfiles de suscriptor específicos mediante la preparación de aplicaciones para esos perfiles con antelación, y almacenando los resultados para rápido acceso en la caché 505, u otro recipiente de datos. Como se describirá posteriormente con referencia a la Figura 7, el Administrador de Despliegue 506 puede desplegar aplicaciones desde un recipiente de datos de aplicación del portador, o desde huéspedes de aplicación remotos (confiables o de otra manera) , o desde cualquier otra fuente de aplicaciones. Después de que el Administrador de Despliegue 506 ha abastecido adecuadamente la aplicación solicitada, éste envía la aplicación solicitada de regreso al Administrador de Abastecimiento 504 para cualquier procesamiento posterior a la respuesta de salida. A medida que la aplicación abastecida se está enviando a un usuario, los detalles acerca de la transacción típicamente se graban en el Administrador de Registros 508, el cual es accesible para el Administrador de Facturación 507, para habilitar una diversidad de métodos de facturación. Los datos grabados incluyen información concerniente a la solicitud entrante 501 y la aplicación desplegada tal como la ID del suscriptor, el tamaño de la descarga, la hora y la fecha de la descarga, la aplicación particular descargada, etcétera. Debido al amplio intervalo de información grabada acerca de la descarga, el portador tiene gran flexibilidad en los métodos de facturación para el abastecimiento de las aplicaciones de conformidad con diferentes categorías de servicios y suscriptores . Los portadores pueden facturar, por ejemplo, por la cantidad de tiempo aire que se usó, el tiempo de descarga, la cantidad de datos descargados, la demografía del cliente, o sobre la base de la aplicación particular que se descargó. El Administrador de Facturación 507 es responsable de ayudar en la imposición de los métodos de facturación. En una modalidad de ejemplo, se proporcionan muchas opciones de facturación iniciales: (1) cargos de descarga con base en la descarga de una aplicación; (2) cargos de facturación basados en el paquete, con base en las transmisiones de paquetes de red; (3) cargos de suscripción con base en cuotas periódicas tal como diariamente, semanalmente , o mensualmente; (4) cargos por uso de ensayo con base en cualquier uso de métrica o ensayo, por ejemplo, el número de veces que se puede ejecutar una aplicación; y (5) facturación pagada previamente. Estas opciones de facturación se pueden personalizar tanto a nivel del portador como a nivel de la aplicación, y, cuando se ofrecen más de una para una aplicación particular, un suscriptor puede seleccionar una opción de facturación deseada. En un Sistema Móvil de Aplicaciones 500 de ejemplo, se proporciona una interfase de programación de aplicación (API) para fácil integración con un subsistema de facturación existente del portador. Si un portador soporta facturación pagada previamente, un suscriptor puede establecer una cuenta que mantenga el portador. En una modalidad, el suscriptor paga previamente las aplicaciones que se vayan a descargar en un momento posterior. Cuando el suscriptor descarga una aplicación pagada previamente, el Administrador de Facturación 507 envia un registro de facturación al sistema de facturación pagado previamente del portador, de tal manera que se pueda cargar y actualizar la cuenta del suscriptor. En una modalidad alternativa, el Administrador de Facturación 507 almacena y mantiene las cuentas de suscriptor pagadas previamente.

También son posibles otras configuraciones, asi como el soporte para otros tipos de métodos de facturación. Después de que el Administrador de Facturación 507 ha generado la información relacionada con la facturación, la aplicación se envía al Administrador de Protocolos 503, en donde ésta se vuelve a formatear entonces para un protocolo diferente si se requiere y se transmite al cliente como datos salientes 502.

El Administrador 509 interactúa con los otros componentes del MAS 500 de ejemplo para personalizar diferentes aspectos del MAS 500. Por ejemplo, el Administrador 509 permite que los portadores implementen políticas que se pueden personalizar relacionadas con el abastecimiento, e integren el MAS con sus propias infraestructuras a través de los componentes de reprogramación del Sistema Móvil de Aplicaciones mismo, permitiendo mediante lo mismo a los suscriptores , portadores, administradores del sistema, y proveedores de contenido flexibilidad mejorada para realizar la administración de perfiles, la generación de reportes, la administración del método de facturación y la administración del servidor. El Monitor de Latido 510 monitorea y proporciona reportes en otros componentes del MAS 500, y proporciona notificaciones apropiadas cuando ocurren eventos relevantes del sistema, por ejemplo, para detectar problemas en el sistema tales como que un componente se vuelva inoperante.

Por ejemplo, el Monitor de Latido 510 puede monitorear el Administrador de Protocolos 503 para determinar si el Administrador de Protocolos 503 responde a una solicitud entrante dentro de un limite de tiempo determinado previamente. Si el Monitor de Latido determina que el Administrador de Protocolos 503 no está respondiendo apropiadamente, éste puede señalizar el evento y notificar a un administrador del sistema. En una modalidad, se proporcionan múltiples Monitores de Latido 510 de tal manera que un segundo monitor pueda monitorear si el primer monitor está funcionando apropiadamente y tomar el mando si es necesario. El Monitor de Latido 510 es capaz tanto de monitorear activamente (por medio de agrupar los dispositivos con solicitudes de estado) , como de escuchar pasivamente (mediante la verificación de que ocurren tipos específicos de comunicaciones en los momentos apropiados) . El Monitor de Latido 510 también proporciona interfases para protocolos de estándares industriales, por ejemplo, el Protocolo de Administración de Red Simple (SNMP, por sus siglas en inglés), para habilitar otro código externo para monitorear el MAS. Como se describe con referencia a la Figura 5, el Administrador de Abastecimiento del MAS que procesa las solicitudes de descarga entrantes y otros comandos, y acciona el abastecimiento dinámico de aplicaciones para descarga. La Figura 6 es un diagrama de bloques de ejemplo de los componentes de un Administrador de Abastecimiento de ejemplo de un Sistema Móvil de Aplicaciones. En una modalidad, el Administrador de Abastecimiento 600 comprende un Procesador de Comando y Control MAS 620 (el "MCCP", por sus siglas en inglés) , los verificadores 601, el procesador XSLT 630, el Procesador Previo y Procesador Posterior de Solicitudes 640, y la Máquina de Consultas de Datos MAS 650. El MCCP es responsable de la descodificación de la solicitud y de dirigirla al subcomponente MAS correcto, por ejemplo, para descargar una aplicación publicada o para realizar el descubrimiento de la aplicación. Los Verificadores 601, los cuales comprenden el Verificador del Suscriptor 602, el Verificador de Dispositivo 603, el Verificador de Facturación Pagada Previamente 604, y el Verificador de Aplicación 605, realizan verificaciones para determinar adecuadamente acerca de una aplicación para un suscriptor y un dispositivo. El procesador XSLT (el cual se puede implementar, por ejemplo, como un Procesador de Hojas de Estilo Extendido estándar industrial) se usa para formatear los datos de conformidad con las capacidades de representación del dispositivo solicitante. En una modalidad, éste soporta hojas de estilo para XML, pero se puede extender fácilmente para proporcionar hojas de estilo adicionales para HTML, Java, WML, XHTML Básico, y texto, o cualquier otro lenguaje de marcación o representación. El Procesador Previo y Procesador Posterior de Solicitudes 640 manipula los parámetros en los "paquetes" de solicitud para comunicarse entre los otros componentes, y se puede extender para realizar cualquier tipo de procesamiento que se pueda "enganchar" en este nivel. La Máquina de Consultas de Datos MAS 650 administra la comunicación con los diferentes recipientes de datos . Esta incluye lectores para Abastecimiento 551, Perfiles 652, y Datos de Configuración 653. Aunque no se muestran flechas conectando estos componentes para facilidad de visión, un experto en la técnica reconocerá que los componentes están interconectados e interoperan de muchas maneras . Inicialmente, el Administrador de Abastecimiento 600 recibe una solicitud entrante tal como desde el Administrador de Protocolos (por ejemplo, el Administrador de Protocolos 504 de la Figura 5) . El Administrador de Abastecimiento 600 opcionalmente procesa previamente la solicitud mediante el análisis de la solicitud entrante, y modificando la solicitud dinámicamente para permitir el me oramiento, la alteración, o la limitación del abastecimiento, la facturación, o los pasos de registro que se tomarán posteriormente. Esa modificación dinámica habilita a los portadores para enganchar su propia infraestructura dinámicamente dentro del sistema. Por ejemplo, el Administrador de Abastecimiento 600 puede ver los encabezadores de la solicitud que pasan junto con la solicitud de descarga entrante y modificar, añadir, o remover los encabezadores para modificar el comportamiento del sistema. Debido a que otros componentes en el MAS usan la información contenida con los encabezadores para realizar sus funciones, la actualización o modificación de la información de los encabezadores proporciona un medio para extender o limitar la funcionalidad de una solicitud especifica, o modificar el comportamiento del MAS. La solicitud, cuando se recibe desde la interfase de comando MAS (en oposición a invocada directamente por medio del sitio Web o la API) se procesa mediante el MCCP. Si la solicitud es por el descubrimiento de la aplicación o para descargar contenido, se usan diversos Verificadores 601 para determinar la compatibilidad de una aplicación. Si la solicitud es por algún otro comando, entonces éste se procesa de conformidad con lo anterior. El Verificador de Aplicación 604 determina si una aplicación solicitada ha sido prohibida por el portador para despliegue. Específicamente, el Verificador de Aplicación 604 examina una lista de aplicaciones que el portador no desea permitir que se descarguen, para determinar si el portador ha proscrito la aplicación solicitada. Esta situación podría ocurrir, por ejemplo, si súbitamente se ha encontrado que una aplicación proporciona comportamiento malicioso y el portador desea interrumpir inmediatamente su distribución.

El Verificador de Suscriptor 601 determina la identidad del suscriptor desde quien se originó la solicitud, y determina el nivel de servicios a los cuales tiene derecho el suscriptor, para determinar si el suscriptor está autorizado para usar una aplicación específica. Los servicios particulares a los cuales tiene derecho el suscriptor se pueden determinar mediante la recuperación, usando el Lector de Perfil 652, de un perfil de suscriptor correspondiente y examinando una diversidad de factores, ya sea individualmente o en combinación. Los factores pueden incluir, por ejemplo, el número de descargas permitidas dentro de cualquier mes, el tiempo requerido para las descargas, la hora del día y el momento en la semana en el cual se hizo la solicitud, la disponibilidad de ofertas especiales y períodos de gracia, etcétera. El Verificador de Suscriptor 601 también puede determinar un grupo suscriptor al cual pertenece un suscriptor, y determinar el nivel de acceso permitido al suscriptor mediante la determinación de los servicios que están permitidos y no permitidos para el grupo suscriptor como un todo. Con referencia a la Figura 17 se describe una modalidad de ejemplo de la determinación que realiza el Verificador de Suscriptor. El Verificador de Dispositivo 602 determina el tipo y las capacidades del dispositivo de suscriptor a partir del cual se hizo la solicitud, y determina si las capacidades del dispositivo son suficientes para soportar una aplicación especifica. Las capacidades del dispositivo de suscriptor se determinan mediante la recuperación, usando el Lector de Perfil 652, de un perfil de dispositivo, si existe uno, que corresponda con el dispositivo de suscriptor solicitante. El perfil de dispositivo se examina para determinar si el dispositivo tiene las características requeridas por la aplicación solicitada para ejecutarse apropiadamente en el dispositivo de suscriptor. Con referencia a la Figura 18 se describe una modalidad de ejemplo de la determinación que realiza el Verificador de Dispositivo 602. Cuando el MAS soporta un método de facturación pagada previamente, el Verificador de Facturación Pagada Previamente 603 consulta la infraestructura de facturación pagada previamente del portador, en cualquier lugar que estén almacenados los registros de facturación para suscriptores individuales. Se permite que una solicitud de descarga proceda para abastecimiento, típicamente sólo si hay suficientes fondos en la cuenta del suscriptor, como lo indica el portador. Después de que el Administrador de Abastecimiento 600 ha determinado que el dispositivo de suscriptor es adecuado para ejecutar la aplicación solicitada, se autoriza al suscriptor para que use la aplicación y tiene suficientes fondos (si es parte de un esquema de facturación pagada previamente) , entonces el Administrador de Abastecimiento 600 invoca una interfase de abastecimiento del Administrador de Despliegue para obtener una aplicación abastecida correspondiente. El Administrador de Despliegue, el cual se describe con referencia a la Figura 7, recupera y abastece la aplicación solicitada, y la regresa al Administrador de Abastecimiento 600. Después de que se obtiene una aplicación abastecida adecuada para descarga al dispositivo de suscriptor desde el Administrador de Despliegue, el Administrador de Abastecimiento 600 opcionalmente procesa posteriormente la solicitud. Como con el procesamiento previo, el procesamiento posterior puede realizar modificaciones adicionales a la solicitud verificada, de tal manera que se puedan usar las modificaciones para extender la funcionalidad del MAS. Por ejemplo, se pueden asociar las instrucciones con la solicitud que después dirigirá el Administrador de Protocolos (por ejemplo, el Administrador de Protocolos 503 de la Figura 5) para empaquetar la solicitud por un protocolo personalizado. Como se mencionó. El Administrador de Despliegue (tal como el Administrador de Despliegue 506 de la Figura 5) recibe una solicitud del suscriptor desde el Administrador de Abastecimiento, o recibe una solicitud directa (tal como desde un administrador del sistema) para obtener una aplicación abastecida que corresponda con la solicitud. La solicitud incluye un URL de la aplicación solicitada, que indica una ubicación de la fuente para la aplicación. En una modalidad, el URL hace referencia a una lista de sitios de duplicación y recupera la aplicación desde una ubicación óptima que se determina desde el MAS. En otra modalidad, el URL es un proxy y el Administrador de Despliegue redirige el URL a su ubicación real. Esos métodos pueden proporcionar capas de seguridad adicionales al sistema. Un experto en la técnica reconocerá que con estas técnicas se puede usar cualquier método para indicar una ubicación para la aplicación, y que estas técnicas operan sobre indicadores diferentes a los URLs . La aplicación también se inspecciona, optimiza, e instrumenta para envió antes de que ésta se despliegue y se envié al suscriptor. La Figura 7 es un diagrama de bloques de ejemplo de los componentes de un Administrador de Despliegue de un Sistema Móvil de Aplicaciones. El Administrador de Despliegue 700 comprende un Recuperador 701, un Buscador Remoto 702, un Buscador Local 703, un Inspector 704, un Optimizador 705, un Instalador de Instrumentación 706, y el Empaquetador de Aplicaciones 707. El recuperador 701 obtiene el código de la aplicación desde el servidor huésped apropiado, usando ya sea el Buscador Remoto 702 o el Buscador Local 703, y después pasa el código de la aplicación a través de una diversidad de componentes para abastecer apropiadamente el código de la aplicación. En particular, el Componente Inspector 704 inspecciona la aplicación para ver si hay un código malicioso y una API prohibida; el Componente Optimizador 705 reduce el tamaño del código si es posible; y el Instalador de Instrumentación 706 incorpora las políticas especificadas y características administrativas del portador, por ejemplo, mensajes de facturación y notificación, dentro del código. Específicamente, el Recuperador 701 está diseñado para permitir que múltiples usuario y múltiples portadores se comuniquen a través de una diversidad de redes, usando diferentes protocolos. Esto se realiza, en parte, por medio de permitirla flexibilidad de los portadores en las ubicaciones de las aplicaciones (contenido) del software que éstos hospedan para distribución. Por ejemplo, los portadores pudieran elegir "hospedar todas las aplicaciones disponibles de su propia red, por medio de almacenar esas aplicaciones en directorios designados en un servidor FTP o HTTP o recipiente de datos, tal como un DBMS estándar. El Almacén de Aplicaciones del Portador 708 es ese recipiente de datos, y puede residir en un servidor del MAS mismo. El Recuperador 701 activa el Buscador Local 703 para recuperar una copia de los datos localmente almacenados. Los portadores también pudieran elegir permitir que los proveedores de aplicaciones de terceras partes confiables hospeden las aplicaciones de los Huéspedes de Aplicaciones Remotos 709, los cuales están bajo el control de los proveedores de aplicaciones de terceras partes confiables. En adición, cuando se usa para realizar el abastecimiento abierto, el Recuperador 701 puede recuperar las aplicaciones desde huéspedes de terceras partes que no necesariamente son de fuentes confiables. En ambos casos, el portador usa un URL suministrado por la tercera parte para referir la solicitud entrante a una aplicación particular que se pueda descargar, que esté hospedada en uno de los Huéspedes de Aplicaciones Remotos 709. El Recuperador 701 típicamente activa el Buscador Remoto 702 para recuperar esas aplicaciones hospedadas en los Huéspedes de Aplicaciones Remotos 709, cuando tales huéspedes están accesibles por medio de protocolos públicos. En una modalidad, se puede optimizar el Buscador Local 703 para recuperar rápidamente los datos almacenados localmente, mientras que el Buscador Remoto 702 implementa los protocolos públicos necesarios para recuperar las aplicaciones que residen en los huéspedes que son accesibles a través de una red pública. Dependiendo de las preferencias de un huésped de tercera parte confiable o el portador, el código de aplicación que recupera el Recuperador 701 pudiera estar ya abastecido. Si el Recuperador 701 obtiene el código no abastecido, se envía el código al Inspector 704, el Optimizador 705, y el Instalador de Instrumentación 706 para procesamiento adicional. El Inspector 704 examina el código de aplicación no abastecido recuperado para detectar código malicioso. En el código Java, el Inspector 704 también pudiera realizar un análisis de clase del código de aplicación para verificar qué clases en la aplicación se conforman con los estándares deseados tales como el número, tipo, y frecuencia de las llamadas API. En adición, el Inspector 704 aplica filtros de aplicación para detectar nombres de paquete y método, clases, campos, u otras formas de una API de la que se sospecha que tiene comportamiento intrusivo, malicioso, o que pudiera no estar autorizada para que la use el suscriptor solicitante, el dispositivo objetivo, o algún otro objetivo. El Inspector 704 también pudiera aplicar filtro de aplicación para detectar patrones de uso de la API. El Inspector 704 tiene disponible para su uso los perfiles del suscriptor y del dispositivo, que recuperó el Administrador de Abastecimiento (como se describió con referencia a la Figura 6) , de tal manera que el Inspector 704 pueda imponer restricciones sobre una base por dispositivo o por suscriptor. En una modalidad de ejemplo, el Inspector 704 permite que se ajusten los umbrales de esos parámetros, asi como los umbrales para señalizar los parámetros para inspección adicional por parte de otras entidades tales como el Administrador de Registros, por ejemplo. Si el Inspector 704 descubre comportamiento potencialmente malicioso, se puede evitar (o advertir al suscriptor) el abastecimiento (y la descarga subsecuente) , y se puede reportar la violación junto con la identidad del ofensor al Administrador de Registros. Después de que el Inspector 704 ha examinado exitosamente el código de aplicación no abastecido recuperado, se envía el código al Optimizador 705 para procesamiento adicional para reducir el tamaño de la aplicación. El Optimizador 705 usa métodos bien conocidos en la técnica para acortar los nombres de variables y para remover el código sin usar de la aplicación. Esos procedimientos de optimización típicamente dan como resultado descargas más rápidas. El Optimizador 705 también pudiera usar técnicas que son bien conocidas en la técnica, para incrementar la velocidad de la aplicación cuando se ejecuta ésta, tal como cambiar el uso de instrucciones particulares por instrucciones más eficientes. Un experto en la técnica reconocerá que, debido a que los componentes del MAS se pueden extender o modificar, se puede incorporar cualquier técnica de optimización dentro del sistema. Después de la optimización, el código de aplicación inspeccionado, optimizado se envía al Instalador de Instrumentación 706 para más procesamiento. Debido a que los proveedores de aplicaciones que se pueden descargar típicamente no tienen la habilidad para modificar las aplicaciones solicitadas para suscriptores individuales, pudiera ser deseable modificar el código de una aplicación para añadir código especifico al suscriptor. Por ejemplo, las opciones de facturación tales como un esquema de "uso de ensayo" se pueden implementar mediante la inserción del código dentro de la aplicación que provoca, por ejemplo, que la aplicación únicamente se ejecute un cierto número de veces, o durante únicamente un periodo de tiempo especificado. De manera similar, se puede instrumentar el código que reporta información para propósitos de registro o el código que reúne información para ver otras opciones de facturación (tales como facturación basada en paquetes que hace los cargo con base en el número de paquetes de red transmitidos) . Además, en el caso del abastecimiento abierto, se puede instrumentar el código que le advierte al suscriptor que el suscriptor está a punto de descargar y ejecutar contenido desde una fuente no confiable. El Instalador de Instrumentación 706 también puede modificar el código en la aplicación de conformidad con otras políticas que especifican los portadores, por ejemplo, políticas que implementan promociones y campañas de publicidad. Un experto en la técnica reconocerá que el código se puede instrumentar para muchos otros propósitos, así como también se puede instrumentar en ubicaciones determinadas previamente usando métodos bien conocidos tales como la manipulación de bibliotecas o por medio de dividir en subclases las clases y métodos . Después de que el Instalador de Instrumentación 706 ha instrumentado la aplicación solicitada, el Empaquetador de Aplicaciones 707 empaqueta la aplicación inspeccionada, optimizada, e instrumentada. El Empaquetador de Aplicaciones 707 empaqueta la aplicación solicitada mediante el formateo de los contenidos del archivo de aplicación de una manera que pueda leer el dispositivo de suscriptor, según se determina por el perfil del dispositivo que obtuvo el Administrador de Abastecimiento, como se describió con referencia a la Figura 6. Por ejemplo, muchos dispositivos de suscriptor son capaces de leer archivos que se presentan en un formato "JAR" comprimido (un formato de archivo Java) , el cual es un formato que se usa para comprimir y empaquetar aplicaciones Java solicitadas. Debido a que algunos dispositivos pudieran no aceptar un archivo JAR comprimido, el Empaquetador de Aplicaciones 707 proporciona empaquetamiento personalizado de las aplicaciones abastecidas para aquellos dispositivos de suscriptor que no pueden aceptar los archivos en el formato JAR comprimido. Un experto en la técnica reconocerá que tales convertidores de empaquetamiento y otros convertidores para formatos aparte del JAR se pueden instalar dentro del Empaquetador de Aplicaciones 707 usando técnicas bien conocidas, tales como por medio de dividir en subclases las rutinas de empaquetamiento. En adición, algunos dispositivos de suscriptor pudieran limitar el tamaño de los paquetes que éstos pueden recibir. Cuando se detecta, el Empaquetador de Aplicaciones 707 puede empaquetar una aplicación abastecida para ese dispositivo de suscriptor en múltiples archivos de datos que el dispositivo de suscriptor puede armar en un solo archivo JAR después de la recepción, el cual puede usar entonces el dispositivo de suscriptor para instalar la aplicación . Como se mencionó con respecto a la Figura 5, al componente Administrador (por ejemplo, el Administrador 509) lo pueden usar muchos tipos diferentes de usuarios para configurar los diferentes componentes del Sistema Móvil de Aplicaciones y para especificar preferencias. La Figura 8 es un diagrama de bloques de ejemplo de un componente Administrador de un Sistema Móvil de Aplicaciones, en una modalidad, el Administrador 800 de preferencia proporciona múltiples interfases de usuario basadas en la Web, para permitir que los proveedores de contenido, los administradores del sistema (portador o MAS) , los suscriptores , y el personal de soporte de servicios al cliente accesen los componentes del MAS, o para personalizar sus experiencias. En particular, el Administrador de ejemplo proporciona un Sitio Web de Proveedor de Contenido 801, un Sitio Web de Administración 802, y un Sitio Web de Personalización 803. Un experto en la técnica reconocerá que cada sitio Web descrito puede comprender múltiples despliegues visuales en pantalla, y que esos y/u otros despliegues visuales en pantalla y sitios Web se pueden combinar en diferentes configuraciones para conseguir el mismo resultado. Por ejemplo, el Sitio Web del Administrador 802 pudiera incluir opcionalmente un Sitio Web de Atención a Clientes 804 separado, el cual puede usar un representante de atención a clientes (o típicamente el portador) para administrar las cuentas de suscriptores individuales en beneficio del portador. El Administrador 800 proporciona un Sitio Web de Proveedor de Contenido 801 para que los proveedores de contenido lo usen para presentar al MAS las aplicaciones que se pueden descargar, y para monitorear si las aplicaciones que se pueden descargar presentadas se han revisado (por ejemplo, inspeccionado) y aprobado para publicación. Los proveedores de contenido también pueden usar el Sitio Web de Proveedor de Contenido 801 para recomendar cambios a un perfil de aplicación, para monitorear la popularidad de sus aplicaciones, o para enviar comunicaciones a un administrador MAS. El Administrador 800 proporciona además un Sitio Web de Administración 802 para la administración del sistema MAS, por ejemplo, para administrar las aplicaciones publicadas y pendientes presentadas por los proveedores de contenido. En una modalidad de ejemplo, la interfase del Sitio Web de Administración 802 proporciona nodos separados para establecer, configurar y/o administrar cuentas, aplicaciones, suscriptores , dispositivos, servidores, y reportes. El administrador del sistema puede usar un nodo de aplicación del Sitio Web de Administración 802 para especificar métodos de facturación globales que soporta el portador. En una modalidad, el administrador puede seleccionar múltiples opciones de facturación diferentes para hacer cargos por descarga, por uso de la red (por ejemplo, con base en la transmisión) , y por suscripción, y el uso de ensayos libres de cargos. También son accesibles otras funciones para los administradores del sistema, por medio del Sitio Web de Administración 802. Por ejemplo, los administradores del sistema pueden usar el nodo de suscriptores para administrar el uso del MAS por parte de los suscriptores, y para establecer un perfil de suscriptor para cada suscriptor. Los perfiles de suscriptor mantienen listas de aplicaciones publicadas que ha descargado cada suscriptor, mantienen una lista de aplicaciones proscritas que no puede ejecutar un suscriptor particular, y crea y mantiene los grupos de suscriptores a los cuales pertenece el usuario particular. En una modalidad, estos perfiles se almacenan en un recipiente de datos en el MAS (tal como el recipiente de datos 511 en la Figura 5, y los lee el Lector de Perfiles del Administrador de Abastecimiento (tal como el Lector de Perfiles 652 de la Figura 6) . El administrador del sistema también pudiera enviar a un suscriptor un mensaje, tal como una notificación de que está disponible una versión actualizada para una de las aplicaciones ya descargadas por el suscriptor. Algunas veces se hace referencia a este comportamiento como capacidad de "empujar". (La información para contactar al suscriptor está disponible típicamente desde el perfil de suscriptor del suscriptor) . En adición, los administradores del sistema pueden elegir activar o desactivar remotamente las aplicaciones descargadas a través de la red inalámbrica, con la condición de que el Instalador de Instrumentación 706 haya instrumentado apropiadamente el contenido descargado. Por ejemplo, se pueden obligar a las aplicaciones instrumentadas a que se verifiquen con el servidor huésped (portador o tercera parte) para ver si está disponible una nueva versión de la aplicación, y puede sugerir al suscriptor que determine si se descarga la nueva versión de la aplicación. Las aplicaciones instrumentadas también se pueden forzar para que se verifiquen con el servidor huésped para determinar si ha expirado un período de tiempo límite, o si se ha excedido el número de veces que se puede ejecutar la aplicación (por ejemplo, para usarse con una opción de facturación de periodo de ensayo) . Las aplicaciones instrumentadas también pueden colocar restricciones de horas del dia que pudieran, por ejemplo, restringir una aplicación para que se use únicamente un cierto número de veces dentro de un periodo de tiempo establecido de un dia. Estas restricciones permiten de manera efectiva que los administradores del sistema revoquen o restrinjan el privilegio de un suscriptor para ejecutar una aplicación aún después de que la aplicación se ha descargado al dispositivo inalámbrico del suscriptor. Un experto en la técnica reconocerá que de manera similar se pueden imponer otras restricciones y capacidades. Los administradores del sistema pueden usar el nodo de los dispositivos del Sitio Web de Administración 802 para presentar y mantener la información que se usa para verificación durante el abastecimiento de una aplicación. Por ejemplo, los administradores del sistema pueden crear y mantener una lista de perfiles de dispositivos que correspondan con dispositivos particulares. Típicamente, el administrador del sistema crea un perfil de dispositivo para cada dispositivo que soporta el MAS. Se pueden añadir nuevos perfiles de dispositivo y designaciones de dispositivo correspondientes según sea necesario. Cada perfil de dispositivo contiene información especifica del hardware y características de recursos, tales como la cantidad de memoria de tiempo de ejecución y memoria flash, identificación del chip, tamaño máximo de descarga, y si el dispositivo cumple con "OTA" (OTA se refiere a la especificación de conformación Sobre el Aire de Sun Microsystems . Los dispositivos que se conforman a OTA soportan, entre otras capacidades, el rastreo de descargas exitosas en dispositivos) . Cada perfil de dispositivo también puede designar un solo perfil Java que soporta el dispositivo. Un perfil Java especifica la API de Java que soporta un dispositivo. Por ejemplo, un dispositivo que se conforma al estándar MIDP 1.0 (un estándar bien conocido que define un conjunto de API de Java implementado por el dispositivo) típicamente tendría un perfil de dispositivo que indique esta conformidad. El Administrador de Abastecimiento usa los perfiles de dispositivo (y Java asociado) durante el proceso de verificación para comparación con un perfil de aplicación, para asegurar que un dispositivo particular tenga los recursos y soporte el conjunto de API que requiere la aplicación. Aunque el mismo perfil Java puede estar asociado con múltiples dispositivos, un dispositivo típicamente puede soportar únicamente un perfil Java. Un administrador del sistema carga un perfil Java mediante la especificación del nombre de una carpeta del archivo (por ejemplo, un archivo JAR o un archivo . zip) que especifica y describe un conjunto de APIs . El MAS examina el archivo especificado para ver su estructura (definiciones de paquete, clase, método, y archivo) y genera un perfil que contiene esta estructura. Estos perfiles también se pueden usar para crear filtros de aplicación, los cuales evitan el abastecimiento y/o descarga de aplicaciones que usan una API especifica. Aunque se describió principalmente con respecto a dispositivos habilitador por Java y API de Java, un experto en la técnica reconocerá que el MAS se puede adaptar a otras especificaciones de lenguaje y otros dispositivos habilitados por lenguaje, siempre y cuando el lenguaje soporte una determinación de si la API particular, objetos, clases, variables, y/u otras estructuras de datos están presentes en una aplicación, y soportados por dispositivos siempre y cuando la estructura se pueda averiguar en el nivel de código por bytes . En adición, un experto en la técnica reconocerá que estas técnicas se pueden adaptar para usarse en el nivel de código de fuente, siempre y cuando la aplicación receptora pueda compilar o interpretar la fuente para generar un archivo que se pueda ejecutar. El Sitio Web de Administración 802 habilita a los administradores del sistema para implementar diferentes técnicas de seguridad y políticas que suplementen y complementen los procesos de verificación e inspección que proporcionan los Administradores de Abastecimiento y Despliegue. Una de esas técnicas es la habilidad para definir filtros de aplicación, como se describió, los cuales se usan para especificar la API que no debe llamar una aplicación usando un dispositivo particular u otro objetivo. Esas llamadas y estructuras restringidas se pueden identificar durante el proceso de abastecimiento de la aplicación, en respuesta a la solicitud de un suscriptor para descargar, y después de la presentación de una aplicación por parte de los proveedores de contenido, para ayudar a asegurar que un suscriptor no cargará el código que sea inapropiado para un dispositivo particular. Otra técnica de seguridad que se proporciona es la habilidad para redirigir los URLs . Los administradores del sistema pueden redirigir los URLs para la conveniencia y seguridad de los usuarios del MAS, mediante la especificación de los mapeos de redirección URL usando el nodo del Servidor del Sitio Web de Administración 802. Por ejemplo, un URL que apunte a un sitio de publicidad no autorizado se puede redirigir a un URL que proporcione la publicidad desde un publicista que paga. De manera similar, después de remover el contenido, el administrador del sistema pudiera desear redirigir el URL que se refirió previamente al contenido, en lugar de a un mensaje de error. Además, los URLs redirigidos se pueden usar para esconder la ubicación real de una aplicación, o para habilitar una aplicación para que se mueva más fácilmente. Después de recibir los datos entrantes, el MAS compara cualesquier URLs que especifiquen una aplicación con una lista de URLs redirigidos administrados usando el Sitio Web de Administración 802, y los redirige si se especifica asi. Un experto en la técnica también reconocerá que se pueden añadir técnicas de seguridad y otras técnicas adicionales a, y para que las utilice el MAS y, en donde sea necesario, se pueden configurar a través del Sitio Web de Administración 802 para proporcionar una diversidad de mecanismos de seguridad para comunicarse de manera segura entre suscriptores, proveedores de contenido, administradores, y diferentes componentes del MAS, y para transportar de manera segura los datos almacenados en el MAS, accesibles a través del MAS, o almacenados en el dispositivo de cliente. Por ejemplo, a medida que se fabrican dispositivos que soportan protocolos seguros tales como SSL, se pueden configurar diferentes componentes MAS para que usen los protocolos. En adición, en donde sea aplicable, se pueden instalar interfases seguras como componentes entre las interfases basadas en la Web y los componentes MAS manipulados por ellas. El Administrador 800 también proporciona un Sitio Web de Personalización 803, el cual usan los suscriptores para ordenar, mantener, y desplegar visualmente servicios e información relacionados con el suscriptor, y para administrar aplicaciones. Un suscriptor usa el Sitio Web de Personalización 803 para suscribirse a categorías adicionales de contenido y cambiar planes de servicio (lo cual posiblemente podría provocar un cambio en la cantidad facturada al usuario. Cuando se selecciona un nuevo plan de servicio, entonces se autoriza al suscriptor para usar las categorías de contenido asociadas. El suscriptor también puede administrar las aplicaciones del suscriptor por medio de ver las aplicaciones actuales, añadir aplicaciones, remover aplicaciones, y organizar aplicaciones. Aunque se describe con referencia a aplicaciones, un experto en la técnica reconocerá que estas técnicas se pueden aplicar a cualquier contenido que se pueda descargar, y que las aplicaciones se pueden administrar por categoría u otros conceptos en adición a la administración basada en la aplicación. Un suscriptor puede usar el Sitio Web de Personalización 803 para crear y administrar la "Lista de Acceso Personal" ("PAL", por sus siglas en inglés) del suscriptor. Una PAL del suscriptores la lista de aplicaciones que el suscriptor desea que tenga el despliegue visual del MAS en el dispositivo del suscriptor durante, por ejemplo, el descubrimiento de aplicaciones. Esta lista puede incluir un conjunto establecido previamente de aplicaciones, no aplicaciones, o una lista de aplicaciones que el suscriptor ha descargado o que desea descargar en algún momento futuro, u otras combinaciones. En una modalidad, la PAL inicialmente contiene lo que el suscriptor ha descargado. Debido a que el MAS mantiene registros de descargas de aplicaciones para cada y todo dispositivo inalámbrico, el MAS es capaz de rastrear las aplicaciones descargadas de un suscriptor particular. Un suscriptor también puede usar el Sitio Web de Personalización 803 para obtener y cambiar información sobre la cuenta y una historia de actividades de descargas y cuentas . A través del Sitio Web de Personalización 803, los administradores del sistema pueden notificar a los suscriptores de la disponibilidad de aplicaciones actualizadas o nuevas, o "enlaces", mediante las cuales los administradores del sistema puedan desplegar visualmente ofertas o anuncios de productos (a través de mensajería de actualización automática) . Un suscriptor puede accesar el Sitio Web de Personalización 803 usando el dispositivo inalámbrico del suscriptor, o usando un dispositivo cableado que tenga de preferencia características de despliegue visual superiores sobre el dispositivo inalámbrico (tal como una computadora personal) . Cuando se usa un dispositivo cableado que tiene características de despliegue visual superiores para accesar el Sitio Web de Personalización 803, se pueden usar características de despliegue visual superiores para soportar los enlaces mejorados. Además de proporcionar diferentes interfases de usuario basadas en el sitio Web a los componentes MAS existentes, el componente Administrador del MAS (por ejemplo, el Administrador 509 en la Figura 5) habilita a los administradores del sistema para que implementen políticas relacionadas con el abastecimiento que se puedan personalizar, a través de los componentes de reprogramación del MAS mismo, y a través de la definición de reglas de abastecimiento. En una modalidad, la reprogramación se realiza a través del Sitio Web de Administración 802; sin embargo, un experto en la técnica reconocerá que esta funcionalidad se puede realizar usando otros mecanismos, por ejemplo, mediante el registro de diferentes componentes y perfiles con el Administrador, a través de un mecanismo de registro, o por medio de dividir en subclases los elementos de las interfases MAS. Esta funcionalidad le permite a los suscriptores , portadores, y administradores del sistema flexibilidad mejorada para revisar las aplicaciones presentadas, realizar la administración de perfiles, la generación de reportes, y la administración de servidores. Por ejemplo, un administrador del sistema puede emplear la administración de perfiles para implementar reglas de abastecimiento. Los perfiles proporcionan una técnica accionada por datos que es inherentemente dinámica. Mediante la especificación de diferentes categorías de servicio para los suscriptores y grupos de suscriptores, se pueden aplicar las reglas de abastecimiento a individuos o a grupos de suscriptores simplemente mediante la modificación de diferentes perfiles, por ejemplo, usando las interfases del sitio Web del componente Administrador. En adición, las reglas de abastecimiento se pueden almacenar en perfiles que se usan para determinar cómo se aplican las categorías de servicio a suscriptores individuales y a grupos de suscriptores . Las reglas de abastecimiento mismas se pueden modificar . La administración de perfiles permite un alto grado de flexibilidad para definir políticas de servicio relacionadas con el abastecimiento y relacionadas con la facturación. Por ejemplo, el portador puede ofrecer servicios de suscripción que comprendan un nivel de servicio básico y un nivel de servicio premium. A los suscriptores del servicio básico se les pudiera cobrar individualmente por cada aplicación que descarguen, mientras que los suscriptores del servicio premium pagarían una cuota de servicio más alta mensualmente, pero se les permitiría descargar un número ilimitado de aplicaciones sin cargo extra. En otro ejemplo, una empresa tal como un banco podría negociar con el portador el establecimiento de un tipo de servicio específico en el cual los clientes de la empresa serían capaces de descargar una aplicación específica a la empresa en un tipo de dispositivo de suscriptor para permitir, por ejemplo, que los clientes del banco busquen estados de cuenta y fondos de transferencia. En este ejemplo, el portador hospeda el perfil del suscriptor para la empresa y le permite a la empresa accesar esta información usando bases de datos estándares industriales tales como LDAP y bases de datos relaciónales que son bien conocidas para un experto en la técnica. El Administrador 800 también proporciona las interfases de usuario necesarias para administrar otros componentes del MAS. A través de estas interfases, los administradores del sistema pueden observar diferentes módulos del MAS, administrar la seguridad del lado del servidor, y monitorear el estado del sistema y el funcionamiento del servidor en cualquier momento. Los administradores del sistema también pueden administrar las cuentas de los suscriptores y asignar diferentes niveles de privilegios administrativos. La administración del servidor también incluye funciones tales como la administración de registros y herramientas de análisis para propósitos de resolución de problemas. En modalidades de ejemplo, los métodos y sistemas del Sistema Móvil de Aplicaciones se implementan en uno o más sistemas de computadora de propósito general y redes inalámbricas de conformidad con una arquitectura de cliente/servidor típica, y se pueden diseñar y/o configurar para operar en un medio ambiente distribuido. Las modalidades de ejemplo están diseñadas para operar en un medio ambiente de red global, tal como uno que tenga una pluralidad de dispositivos de suscriptor que se comunican a través de una o más redes inalámbricas con el MAS. La Figura 12 es un diagrama de bloques de ejemplo de un sistema de computadora de propósito general y un dispositivo suscriptor para practicar las modalidades del Sistema Móvil de Aplicaciones. El medio ambiente de computadora de la Figura 12 comprende un dispositivo de suscriptor 1201 y un sistema de computadora de propósito general 1200, que se comunican por medio de un portador inalámbrico 1208. Cada bloque puede representar uno o más de tales bloques, según sea apropiado para una modalidad especifica, y cada uno puede residir en ubicaciones físicas separadas. El dispositivo de suscriptor 1201 comprende una memoria de computadora ("memoria") 1202, un despliegue visual 1203, los Dispositivos de Entrada/Salida 1204, y una Unidad de Procesamiento Central ("CPU", por sus siglas en inglés) 1205. Se muestra una Consola de Administración de Microteléfono 1206 que reside en la memoria 1202 con las aplicaciones descargadas 1207. La Consola de Administración de Microteléfono 1206 de preferencia se ejecuta en la CPU 1205 para ejecutar las aplicaciones 1207 actualmente existentes en la memoria 1202, o para descargar las aplicaciones desde el MAS 1209 por medio del portador inalámbrico 1208 como se describió con referencia a las figuras previas. El sistema de computadora de propósito general 1200 puede comprender uno o más sistemas de computación de servidor y/o cliente y puede abarcar ubicaciones distribuidas. En una modalidad, el MAS se implementa usando la Edición de Empresa Java 2 (J2EE, por sus siglas en inglés) , y se ejecuta en un sistema de computadora de propósito general que proporciona un servidor de aplicación que concuerda con J2EE . De conformidad con esta modalidad, el MAS está diseñado y codificado usando una arquitectura de aplicación de múltiples enlazadores, la cual soporta un enlazador Web, enlazador de negocios, y un enlazador de bases de datos en el lado del servidor. De esta manera, el sistema de computadora de propósito general 1200 representa uno o más servidores capaces de ejecutar uno o más componentes y/o recipientes de datos del MAS. Como se muestra, el sistema de computadora de propósito general 1200 comprende una CPU 1213, una memoria 1210, y opcionalmente un despliegue visual 1211 y los Dispositivos de Entrada/Salida 1212. Los componentes del MAS 1209 se muestran como residiendo en la memoria 1210, junto con otros recipientes de datos 1220 y otros programas 1230, y de preferencia se ejecutan en una o más CPUs 1213. En una modalidad tipica, el MAS 1209 incluye los Componentes de Abastecimiento 1214, los Recipientes de Datos 1215 para almacenar perfiles y datos de configuración, y el Almacén de Aplicaciones 1216. Como se describió anteriormente, el MAS puede incluir otros recipientes de datos y componentes dependiendo de las necesidades de, y de la integración con el portador u otros sistemas huéspedes. Los Componentes de Abastecimiento 1214 incluyen los componentes del MAS que se ilustran en, y se describen con referencia a la Figura 5. Los Componentes de Abastecimiento 1214 habilitan al MAS 1209 para recibir solicitudes por aplicaciones que se pueden descargar y el descubrimiento de aplicaciones, para verificar lo apropiado de la solicitud para que la use un suscriptor particular y un dispositivo de suscriptor particular, para personalizar la aplicación solicitada de conformidad con lo anterior, y para enviar la aplicación abastecida al dispositivo de suscriptor 1201. El Almacén de Aplicaciones 1216 es un recipiente de datos que almacena aplicaciones adecuadas para descarga al dispositivo de suscriptor 1201. Las aplicaciones se puede abastecer previamente ( "abastecimiento estático") para la descarga rápida al dispositivo suscriptor 1201, o las aplicaciones se pueden abastecer sobre solicitud ("abastecimiento dinámico") . Los Recipientes de Datos 1215 proporcionan servicios de depósito y recuperación de datos para establecer niveles de suscripción y capacidades del dispositivo (para hospedar los perfiles que se usen en la administración de perfiles) y para determinar las aplicaciones adecuadas para cada dispositivo de cliente. Un experto en la técnica reconocerá que el MAS 1209 se puede implementar en un medio ambiente distribuido que comprenda múltiples, hasta heterogéneos, sistemas y redes de computadora. Por ejemplo, en una modalidad, los Componentes de Abastecimiento 1214 y el Almacén de Aplicaciones 1215 están localizados en sistemas de computadora físicamente diferentes. En otra modalidad, los diferentes componentes de los Componentes de Abastecimiento 1214 se hospedan en máquinas de servidores separadas y pueden estar localizados remotamente de los recipientes de datos 1215 y 1216. Se contemplan diferentes configuraciones y ubicaciones de programas y datos para usarse con las técnicas de la presente invención . En una modalidad de ejemplo, los Componentes de Abastecimiento 1214 se implementan usando una plataforma de aplicación de múltiples enlazadores J2EE, como se describe en detalle en Java™ 2 Platform, Enterprise Edition Specification, Versión 1.2, Sun Microsystems, 1999, incorporada a la presente como referencia en su totalidad. Los Componentes de Abastecimiento 1214 incluyen el Administrador de Protocolos, el Administrador de Abastecimiento, el Administrador de Despliegue, el Administrador de Facturación, entre otros componentes. Las Figuras 13-28 describen diferentes modalidades de ejemplo de las rutinas específicas que implementa cada uno de estos componentes para conseguir la funcionalidad que se describe con referencia a las Figuras 3-8. En las modalidades de ejemplo, estos componentes se pueden ejecutar concurrente y asincrónicamente; de esta manera, los componentes se pueden comunicar usando técnicas de paso de mensaje bien conocidas. Un experto en la técnica reconocerá que una implementación MAS también puede soportar modalidades sincrónicas equivalentes. Además, un experto en la técnica reconocerá que se podrían implementar otros pasos por cada rutina, y en diferentes órdenes, y en diferentes rutinas, y aún así conseguir las funciones del MAS. La Figura 13 es un diagrama de flujo de ejemplo del procesamiento que realiza un Administrador de Protocolos de un Sistema Móvil de Aplicaciones para comunicarse con diferentes dispositivos de suscriptor a través de redes inalámbricas variables usando diferentes protocolos. (Ver, por ejemplo, el Administrador de Protocolos 503 en la Figura 5) . En el paso 1301, se inicializa el Administrador de Protocolos. En el paso 1302, el Administrador de Protocolos determina si hay una solicitud de datos entrante desde un dispositivo suscriptor y, si así es, procede al paso 1303, si no, continúa en el paso 1306. En el paso 1303, el Administrador de Protocolos determina el protocolo que se usa para la solicitud entrante mediante la determinación de a través de cuál red inalámbrica (o red cableada) se envió la solicitud, y almacena el protocolo determinado para la solicitud pendiente en un registro asociado con la solicitud entrante. Se mantiene una asociación entre el registro del protocolo y la solicitud entrante a medida que el sistema procesa ésta, por ejemplo, mediante el almacenamiento de una referencia al registro del protocolo adentro del encabezador del mensaje de solicitud. En el paso 1304, el Administrador de Protocolos traduce la solicitud entrante al protocolo que se usa internamente (por ejemplo, HTTP) . En el paso 1305, el Administrador de Protocolos envía la solicitud traducida al Administrador de Abastecimiento (por ejemplo, el Administrador de Abastecimiento 504 en la Figura 5) , y después termina el procesamiento de la solicitud. En el paso 1306, el Administrador de Protocolos determina si hay o no una solicitud de datos saliente a un dispositivo de suscriptor y, si así es, procede al paso 1307, de otra manera termina el procesamiento de la solicitud. En el paso 1307, el Administrador de Protocolos recupera el protocolo determinado que está asociado con la solicitud entrante que corresponde con los datos de salida. El protocolo determinado es el protocolo que usa el dispositivo de suscriptor que emitió la solicitud. En el paso 1308, el Administrador de Protocolos codifica/traduce el mensaje de datos de salida de conformidad con el protocolo determinado. En el paso 1309, el Administrador de Protocolos transmite los datos de salida codificados al dispositivo de suscriptor que presentó la solicitud, y termina el procesamiento. La Figura 14 es un diagrama de flujo de ejemplo del procesamiento que realiza un Administrador de Abastecimiento de un Sistema Móvil de Aplicaciones para determinar lo adecuado de una aplicación solicitada para un dispositivo de suscriptor, y para presentar la aplicación solicitada al dispositivo en un formato que pueda descodificar el dispositivo de suscriptor. (Ver, por ejemplo, el Administrador de Abastecimiento 504 en la Figura 5) . En el paso 1401, el Administrador de Abastecimiento realiza cualquier inicialización necesaria. En los pasos 1402-1413, el Administrador de Abastecimiento procesa un "comando" MAS. En el paso 1402, el Administrador de Abastecimiento determina el comando (o solicitud a descargar) que está especificado en la solicitud entrante. En el paso 1403, el Administrador de Abastecimiento procesa previamente, como se describió con referencia a la Figura 6, la solicitud por medio de analizar la solicitud entrante y modificando la solicitud dinámicamente para permitir el mejoramiento, alteración, o limitación de ciertos pasos de abastecimiento que se tomarán posteriormente, o mediante la inserción de otros valores de parámetros por razones de comunicación o configuración. En el paso 1404, el Administrador de Abastecimiento determina si el "comando" es una solicitud para descargar y, si asi es, continúa en el paso 1404, de otra manera continúa en el paso 1408. Aunque actualmente se iirtplementan como "tipos" de comandos separados, un experto en la técnica reconocerá que aun cuando las solicitudes de descarga se indican mediante la especificación de un "URL" como un parámetro, éstas son esencialmente comandos y que existen muchas técnicas de programación equivalentes para realizar el procesamiento de comandos. En el paso 1405, el Administrador de Abastecimiento determina si la aplicación (contenido) solicitada es conocida para el MAS y, si es asi, continúa en el paso 1406 para realizar abastecimiento de jardin amurallado, de otra manera continúa en el paso 1407 para realizar el abastecimiento abierto. En una modalidad de ejemplo, existen muchas maneras en las que el contenido puede llegar a ser conocido para el MAS: a través de un administrador del sistema que use el sitio Web para abastecer y publicar aplicaciones, a través de un proveedor de contenido que presente contenido que eventualmente se llegue a aprobar y publicar, y a través de un suscriptor que solicite la descarga de una aplicación todavía por conocerse desde un proveedor de contenido de tercera parte confiable conocido para el portador, que provoque que ocurra indirectamente un proceso de presentación. El abastecimiento de jardín amurallado se describe adicionalmente con referencia a la Figura 15, y el abastecimiento abierto se describe adicionalmente con referencia a la Figura 16. Una vez que ha ocurrido el abastecimiento en los pasos 1406 ó 1407, la solicitud de procesa posteriormente en el paso 1413. Si, por otra parte, en el paso 1408 el comando designado es una solicitud por una lista de aplicaciones, entonces el Administrador de Abastecimiento continúa en el paso 1409 para realizar el descubrimiento de aplicación, o continúa en el paso 1410. Después del descubrimiento de aplicación, el Administrador de Abastecimiento procede al paso 1413 para procesar posteriormente la solicitud. En el paso 1409, si el comando es una solicitud para descargar historia, entonces el Administrador de Abastecimiento continúa en el paso 1411 para recuperar la lista de aplicaciones descargadas, y procede al paso 1413 para procesamiento posterior. En el paso 1412, si el comando es algún otro comando MAS, entonces el Administrador de Abastecimiento procesa apropiadamente el comando, y procede al paso 1413. En el paso 1413, como se describió con referencia a la Figura 6, el Administrador de Abastecimiento procesa posteriormente la solicitud mediante la modificación de la solicitud para que contenga referencias a instrucciones para dar instrucciones a otros componentes del MAS para que realicen funciones que son extensiones de la funcionalidad de otros componentes, o modifica otros parámetros. Por ejemplo, si el Administrador de Abastecimiento determina que el individuo que solicita la descarga es un empleado de un cliente de publicidad altamente valuado, el Administrador de Abastecimiento puede dar instrucciones al Administrador de Facturación para que no facture esta transacción particular. Después de procesar posteriormente la solicitud, el Administrador de Abastecimiento termina el procesamiento hasta que se recibe otra solicitud. La Figura 15 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Realizar Abastecimiento de Jardín Amurallado de un Administrador de Abastecimiento. (Ver el paso 1406 de la Figura 14) . En el abastecimiento de jardín amurallado, se verifica la aplicación solicitada para autorización por parte del suscriptor y capacidad por parte del dispositivo de suscriptor. Específicamente, en el paso 1501, el Administrador de Abastecimiento recupera el perfil del suscriptor, el perfil del dispositivo, y el perfil de aplicación que corresponden con la aplicación solicitada. En una modalidad, estos perfiles se recuperan por medio de invocar al Lector de Perfiles 652 en la Figura 6. En el paso 1502, el Administrador de Abastecimiento realiza la verificación de la aplicación para verificar que el portador inalámbrico no haya restringido la aplicación solicitada, por ejemplo, debido a la inclusión de APIs prohibidas. La verificación de la aplicación se describe adicionalmente con referencia a la Figura 16. En el paso 1503, el Administrador de Abastecimiento realiza la verificación del suscriptor para determinar si el suscriptor autoriza por medio de la política de facturación del portador o de otra manera la aplicación solicitada. La autorización del suscriptor se describe adicionalmente con referencia a la Figura 17. En el paso 1504, el Administrador de Abastecimiento realiza la verificación del dispositivo para determinar si el dispositivo tiene los recursos y otras capacidades especificadas por el perfil de la aplicación, que correspondan con la aplicación solicitada. La autorización del dispositivo se describe adicionalmente con referencia a la Figura 18. En el paso 1505, el Administrador de Abastecimiento realiza la verificación de facturación pagada previamente, si en el sistema está incluida la facturación pagada previamente, para verificar que la cuenta del suscriptor sea suficiente para cobrar por la descarga de la aplicación, como se describe con referencia a la Figura 6. En el paso 1506, el Administrador de Abastecimiento invoca la interfase de abastecimiento del Administrador de Despliegue, y regresa la aplicación abastecida.

La Figura 16 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Verificar Aplicación de un Administrador de Abastecimiento. [Ver el paso 1502 en la Figura 15) . En resumen, la rutina de Verificar Aplicación determina si el portador ha proscrito la aplicación solicitada para descarga (globalmente o dirigida con base en otros criterios tales como identidad del suscriptor, tipo de dispositivo, etcétera) . En el paso 1601m la rutina solicita y obtiene una lista de aplicaciones que el portador ha declinado para permitir que se descarguen. Esta lista se puede recuperar localmente, y se puede actualizar sobre una base periódica, por ejemplo, usando la Máquina de Consultas MAS 650 en la Figura 6. En el paso 1602, la rutina busca la lista recuperada para la aplicación solicitada, para determinar si la aplicación está proscrita. Esto proporciona una manera rápida y robusta para prohibir la descarga de aplicaciones que, por ejemplo, contienen o se sospecha que contienen código malicioso. Este método proporciona un planteamiento basado centralmente (en comparación con un planteamiento distribuido en donde cada dispositivo obtiene un "verificador de virus" y un archivo de datos de aplicación maliciosa) para detener la diseminación de aplicaciones maliciosas. En el paso 1603, la rutina determina si la solicitud es por una aplicación proscrita y, si asi es, procede al paso 1605, o de otra manera procede al paso 1604.

En el paso 1604, se registra la solicitud, y la rutina regresa con estado exitoso. En el paso 1605, se registra la solicitud fallida, se envía una notificación al suscriptor, y la rutina regresa un estado de falla. La Figura 17 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Verificar Suscriptor de un Administrador de Abastecimiento. (Ver el paso 1503 de la Figura 15) . En resumen, la rutina de Verificar Suscriptor compara los perfiles de suscriptores con las categorías de contenido y las definiciones de planes de servicio, según las almacena e implementa el componente Administrador en loe perfiles (por ejemplo, el Administrador 509 en la Figura 5) , y determina si el suscriptor está autorizado para descargar la aplicación solicitada. Específicamente, en el paso 1701, la rutina determina desde cuál portador se recibió el mensaje de solicitud. En el paso 1702, la rutina identifica al suscriptor que envió la solicitud. Esto se pudiera realizar, por ejemplo, por medio de examinar el mensaje de solicitud para ver la información de ruteamiento. En el paso 1703, la rutina establece una conexión con el portador determinado si la información del perfil del suscriptor está almacenada en el portador, y en el paso 1704, recupera el perfil del suscriptor identificado desde el portador. Un experto en la técnica notará que el perfil del suscriptor también puede estar almacenado localmente en, y se puede recuperar desde el MAS usando, por ejemplo, el componente Lector de Perfiles 652 en la Figura 6, para accesar un recipiente de datos local 511 en la Figura 5. En el paso 1705, la rutina examina la solicitud para determinar cuál aplicación se ha solicitado. En el paso 1706, la rutina determina si el perfil del suscriptor autoriza la descarga de la aplicación solicitada. Esta determinación se puede realizar, por ejemplo, por medio de examinar el plan de servicio del grupo de suscriptores al cuál pertenece el suscriptor, para determinar si la aplicación pertenece a una categoría de contenido asociada con ese plan de servicio. En adición, la rutina puede verificar la presencia de una aplicación proscrita que coincida en el perfil del suscriptor, y si se encuentra una coincidencia, rechazar subsecuentemente la solicitud. En el paso 1707, si se determina que la solicitud está autorizada, entonces la rutina procede al paso 1708, de otra manera ésta procede al paso 1709. En el paso 1708, se registra la solicitud y la rutina regresa con un estado exitoso. En el paso 1709, se registra la solicitud fallida, se envía una notificación al suscriptor, y la rutina regresa con un estado de falla. La Figura 18 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Verificar Dispositivo de un Administrador de Abastecimiento. (Ver el paso 1504 de la Figura 15) . En resumen, la rutina de Verificar Dispositivo compara el perfil del dispositivo asociado con el dispositivo del suscriptor con el perfil de aplicación para la aplicación solicitada, y verifica que estén disponibles los recursos que requiere la aplicación, de conformidad con el perfil de dispositivo. En el paso 1801, la rutina identifica el tipo de dispositivo de suscriptor desde el cual se recibió la solicitud. Un experto en la técnica reconocerá que esta información se determina en negociaciones de protocolo y típicamente se puede extraer a partir de la información de ruteamiento almacenada en el mensaje de solicitud. En el paso 1802, la rutina determina las capacidades del dispositivo de suscriptor por medio de accesar un perfil de dispositivo previamente almacenado que esté asociado con el dispositivo identificado. En una modalidad, el perfil de dispositivo se recupera usando el Lector de Perfiles 652 en la Figura 6. Si no se encuentra un perfil de dispositivo para el dispositivo identificado, el evento se registra y de conformidad con esto se le notifica al administrador del sistema. (En una modalidad, se les advierte a los portadores de la clase particular de dispositivo que usa cada suscriptor cuando el suscriptor se registra con el portador para obtener un número telefónico; los portadores deben asegurar de preferencia que todos los tipos de dispositivos registrados estén soportados con un perfil de dispositivo) . El perfil de dispositivo contiene información relevante para las capacidades del dispositivo suscriptor tal como la capacidad de memoria, el tipo de procesador, la velocidad del procesamiento, el tamaño máximo de una aplicación que se puede descargar, etcétera. En el paso 1803, la rutina determina los requerimientos para la aplicación solicitada mediante la recuperación y examen del perfil de aplicación que corresponda con la aplicación solicitada, según lo creó previamente el componente Administrador. El perfil de aplicación contiene los requerimientos para ejecutar la aplicación incluyendo, por ejemplo, la cantidad de memoria que se requiere, llamadas API hechas, y velocidad mínima del procesador. Los requerimientos también se pueden especificar en el perfil de aplicación, de conformidad con los tipos de dispositivos de suscriptor que están soportados. En el paso 1804, se comparan las capacidades del dispositivo con los requerimientos de la aplicación solicitada, mediante la comparación de los perfiles del dispositivo y la aplicación. En el paso 1805, la rutina determina si el dispositivo es capaz de ejecutar la aplicación solicitada y, si asi es, procede al paso 1806, de otra manera procede al paso 1807. En el paso 1806, se registra la solicitud y la rutina regresa con un estado exitoso. En el paso 1807, se registra la solicitud fallida, se envía una notificación al suscriptor, y la rutina regresa con un estado de falla.

La Figura 19 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Realizar Abastecimiento Abierto de un Administrador de Abastecimiento. [Ver el paso 1407 de la Figura 14) . En los pasos 1901 y 1902, el Administrador de Abastecimiento necesita determinar si existe una aplicación abastecida ya disponible o colocada en caché y, si asi es, continúa en el paso 1903, de otra manera continúa en el paso 1904. Este escenario puede ocurrir, por ejemplo, si se ha solicitada y abastecido anteriormente la aplicación, aunque ésta sea desde una fuente no confiable o desconocida. En el paso 1903, se regresa la aplicación abastecida. Alternativamente, si no se encuentra ninguna aplicación abastecida previamente, entonces en el paso 1904, la rutina recupera la aplicación usando el URL designado que se proporciona en el mensaje de solicitud. Esta aplicación pudiera haberse procesado antes por medio del MAS, y de esta manera pudiera ya tener un perfil de aplicación correspondiente. De esta manera, en el paso 1905, la rutina determina si existe un perfil de aplicación correspondiente y, si asi es, continúa en el paso 1907, de otra manera crea un nuevo perfil de aplicación en el paso 1906, y después continúa en el paso 1907. En el paso 1907, la rutina realiza la verificación del dispositivo mediante la comparación del perfil de la aplicación (recuperado o creado) con un perfil del dispositivo que corresponda con el tipo de dispositivo de la solicitud del suscriptor. En el paso 1908, la rutina invoca la interfase de abastecimiento del Administrador de Despliegue para abastecer una aplicación no confiable, y en el paso 1909 regresa la aplicación abastecida. La Figura 20 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Realizar Descubrimiento de Aplicación de un Administrador de Abastecimiento. (Ver el paso 1409 de la Figura 14) . Existen dos tipos básicos de descubrimiento de aplicación: una búsqueda de las aplicaciones que coincidan con criterios especificados por el suscriptor y una lista de aplicaciones proporcionadas por el sistema basada en preferencias almacenadas del suscriptor. Específicamente, en el paso 2001, la rutina determina si el usuario ha designado criterios de búsqueda y, si así es, continúa en el paso 2002, de otra manera continúa en el 2004. En el paso 2002, la rutina busca el almacén de aplicaciones (un recipiente de datos de aplicaciones) y consulta para ver las aplicaciones (contenido) que coincidan con los criterios designados. Los criterios de ejemplo incluyen categoría, precio, género, edad, etcétera. En el paso 2003, la lista se establece inicialmente a estos resultados de la consulta, y la rutina continúa en el paso 2007. En el paso 2004, la rutina determina si existe una Lista de Acceso Personal (una "PAL") disponible y, si así es, continúa en el paso 2005 para establecer la lista micialmente a la PAL determinada, de otra manera continúa en el paso 2006 para establecer la lista inicialmente a un valor establecido previamente. En el paso 2007 , el MAS añade un conjunto de aplicaciones definidas a la lista inicial, conocida como plataforma de inicio. La plataforma de inicio esencialmente le permite al MAS reservar ranuras en las sesiones de descubrimiento de aplicaciones, por ejemplo, para publicistas de ingresos más altos. En el paso 2008, la rutina invoca la rutina de Verificar Suscriptor, como se describió con respecto a la Figura 17, para cada aplicación inicialmente en la lista. Cualesquier aplicaciones que no pasen alguno de los pasos de filtración 2008-2009 se filtrarán de la lista antes del siguiente paso en el proceso. En el paso 2009, la rutina invoca Verificar Dispositivo, como se describió con respecto a la Figura 18, para cada aplicación inicialmente en la lista. En el paso 2010, la rutina genera un XML para formato estandarizado interno, y en el paso 2011, transforma el contenido de esta lista a un lenguaje apropiado que corresponda con el dispositivo de suscriptor. La Figura 21 es un diagrama de flujo de ejemplo del procesamiento que realiza un Administrador de Despliegue de un Sistema Móvil de Aplicaciones, para proporcionar aplicaciones abastecidas en respuesta a solicitudes por parte de suscriptores y administradores del sistema. (Ver, por » ejemplo, el Administrador de Despliegue 506 en la Figura 5) . Los administradores del sistema pudieran solicitar que se abastezcan (abastecidas estáticamente) previamente aplicaciones populares para dispositivos populares, y que se pongan en caché con el propósito de reducir al mínimo el tiempo que se requiere para responder a la solicitud de un suscriptor. Alternativamente, todas las aplicaciones se pueden abastecer dinámicamente, y opcionalmente ponerse en caché. En el paso 2101, el se inicializa Administrador de Despliegue. En el paso 2102, el Administrador de Despliegue evalúa una solicitud para determinar la identidad de la aplicación solicitada. En el paso 2103 r el Administrador de Despliegue invoca la rutina de Adquirir Aplicación Abastecida para controlar la recuperación del contenido, y para provocar que ocurra el abastecimiento, como se describe adicionalmente con referencia a la Figura 22. En el paso 2104, el Administrador de Despliegue determina si la solicitud lo hace un administrador del sistema para iniciar el almacenamiento de la aplicación abastecida y, si es así, procede al paso 2105, de otra manera procede al paso 2106. En el paso 2105, el Administrador de Despliegue almacena la aplicación abastecida en la caché, el almacén de aplicaciones del portador, o un servidor del huésped de aplicación remoto, dependiendo de la política del administrador del sistema, y termina el procesamiento. En el paso 2106, el Administrador de Despliegue envía la aplicación abastecida al Administrador de Abastecimiento, y entonces termina el procesamiento. La Figura 22 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Adquirir Aplicación Abastecida de un Administrador de Despliegue; (Ver el paso 2105 en la Figura 21) . En resumen, el Administrador de Despliegue recupera el código de la aplicación y lo inspecciona, optimiza, e instrumenta de conformidad con las políticas actuales implementadas en el MAS. En el paso 2201, la rutina consulta algún tipo de índice para determinar si existe una versión abastecida previamente de la aplicación en una ubicación conocida para el MAS . La manera en la cual se almacena esta información está relacionada con cómo están implementados la caché y/o los recipientes de datos. Se pueden usar técnicas bien conocidas para implementar una caché usando un almacén e índice de datos rápido local. Las aplicaciones se pueden abastecer previamente y almacenarse cuando se espera que se hagan grandes números de solicitudes para una aplicación que ocasionaría los mismos requerimientos de abastecimiento. Esto pudiera ocurrir, por ejemplo, cuando grandes números de usuarios que tienen la misma clase de dispositivo de suscriptor solicitan la misma aplicación. En tales casos, la aplicación se podría abastecer y almacenarse en la caché (y recuperarse cuando se hacen solicitudes por parte de usuarios que tienen dispositivos de suscriptor para los cuales se abasteció la aplicación) o almacenarse en los otros recipientes de datos MAS. En el paso 2202, si existe una versión abastecida previamente de la aplicación, entonces la rutina procede al paso 2203, de otra manera ésta procede al paso 2207. En el paso 2203, se determina la ubicación de la aplicación abastecida previamente. En el paso 2204, la rutina determina si la aplicación abastecida previamente está almacenada localmente y, si asi es, procede al paso 2205, de otra manera ésta procede al paso 206. En el paso 2205, la rutina busca la aplicación localmente (típicamente del almacén de aplicaciones del portador, que pudiera estar ubicado en el MAS o en las instalaciones del portador), y regresa. En el paso 2206, la rutina busca la aplicación desde un huésped de aplicación remoto (por ejemplo, un servidor de tercera parte) y regresa. Si, por otra parte, en el paso 2202, la rutina determina que no existe una versión abastecida previamente de la aplicación solicitada, entonces en el paso 2207 la rutina determina la ubicación de la aplicación no procesada, no abastecida. En el paso 2208, la rutina determina si el código de la aplicación está almacenado localmente y, si así es, procede al paso 2209, de otra manera procede al paso 2210. En el paso 2209, la rutina busca el código de la aplicación desde el almacén de aplicaciones del portador u otro almacenamiento local. En el paso 2210, la rutina busca el código de la aplicación desde un huésped de aplicación remoto. En el paso 2211, la rutina abastece la aplicación buscada, como se describe adicionalmente con referencia a la Figura 23, y regresa. La Figura 23 es un diagrama de flujo de ejemplo del 'procesamiento que se realiza mediante una rutina de Abastecer Aplicación de un Administrador de Despliegue. En el paso 2301, la rutina de Abastecer Aplicación inspecciona la aplicación, como se describe adicionalmente con referencia a la Figura 24. En el paso 2302, la rutina optimiza la aplicación, como se describe adicionalmente con referencia a la Figura 25. En el paso 2303, la rutina instala la instrumentación en la aplicación, como se describe adicionalmente con referencia a la Figura 26. En el paso 2304, la rutina empaqueta la aplicación en un formato adecuado para envió, como se describe adicionalmente con referencia a la Figura 23, y regresa. La Figura 24 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Inspeccionar Aplicación de un Administrador de Despliegue. {Ver, por ejemplo, el paso 2301 en la Figura 23) . En el paso 2401, la rutina descompone/descodifica la estructura del código de la aplicación si se requiere identificar las APIs, incluyendo paquetes, clases, métodos, y campos, u otras estructuras según sea apropiado. Cuando las aplicaciones están codificadas en Java, entonces se puede realizar la inspección contra el programa binario, sin ninguna necesidad de insertar las verificaciones de nivel del código de fuente en la aplicación misma a la información de depuración/registro generada. En los pasos 2401-2405 se describen como ejemplos un conjunto de pasos de inspección; no obstante, un experto en la técnica reconocerá que se pueden aplicar otros pasos de inspección, en adición a, o en lugar de los que se describen en la presente, según sea apropiado. En el paso 2402, la rutina recupera cualesquier filtros de aplicación que sean relevantes para los objetivos potenciales bajo examen (la aplicación solicitada, el suscriptor solicitante, el proveedor de contenido de la aplicación, y los filtros globales) . En una modalidad, estos filtros están almacenados en un recipiente de datos MAS, sin embargo, éstos pueden estar almacenados en cualquier ubicación conocida. En el paso 2403, la rutina inspecciona la aplicación recuperada para ver si hay código malicioso y proscrito, mediante la comparación del código descompuesto con las indicaciones almacenadas de estructuras de datos proscritas y API como se describe por los filtros de aplicación recuperados. En el paso 2404, la rutina determina el número, tipo, y frecuencia de llamadas API presentes en el código, y verifica si éstos satisfacen los requerimientos del administrador del sistema, los cuales podrían estar almacenados en los filtros de aplicación. En el paso 2405, la rutina realiza un análisis de flujo de la aplicación descompuesta y determina si el número de subprocesos activados está dentro de los requerimientos de los administradores del sistema. Este análisis de flujo se puede realizar usando técnicas tales como la creación de un grafo de dirección del código y la aplicación de algoritmos bien conocidos de análisis de grafos. Un experto en la técnica reconocerá que también se pueden realizar otras verificaciones sobre la aplicación recuperada. En el paso 2406, la rutina determina si la aplicación recuperada ha pasado la inspección y, si es asi, regresa un estado de éxito, de otra manera la rutina señaliza la condición fallida y regresa un estado de falla. La Figura 25 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Optimizar Aplicación de un Administrador de Despliegue. [Ver, por ejemplo, el paso 2302 en la Figura 23) . Un experto en la técnica reconocerá que en esta rutina se pueden incorporar cualesquier técnicas de optimización de código bien conocidas, y lo que se muestra es un ejemplo. En el paso 2501, la rutina acorta los nombres de variables contenidos en la aplicación recuperada, con el propósito de acortar el tamaño del archivo de la aplicación solicitada. En el paso 2502, la rutina mapea las trayectorias ejecutables de la aplicación recuperada. En el paso 2503, la rutina remueve cualquier código sin usar, con el propósito de acortarla longitud del archivo, y continúa con pasos de optimización similares. Cuando se termina la optimización, la rutina regresa. La Figura 26 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Instalar Instrumentación de un Administrador de Despliegue. (Ver, por ejemplo, el paso 2303 en la Figura 23) .' En el paso 2601, la rutina recupera el perfil del suscriptor identificado desde típicamente un recipiente de datos local usando, por ejemplo, el Lector de Perfiles 652 en la Figura 6. En el paso 2602, la rutina determina la política del portador para el suscriptor identificado cuando se usa la aplicación solicitada. Por ejemplo, a ciertos suscriptores se les podría permitir usar la aplicación sobre una base de suscripción o hasta una base de ensayo, pero a otros pudiera no permitírseles. Como se describió anteriormente con referencia a la Figura 7, la implementación implementa ciertas políticas. Por ejemplo, ésta puede proporcionar un envolvedor de código que permita que se ejecute el código abastecido un número limitado de veces, o durante un período de tiempo dado. En el paso 2603, la rutina instala la instrumentación en la aplicación solicitada, de conformidad con la política determinada del portador, después de lo cual la rutina regresa. En una modalidad de ejemplo, la rutina de Instalar Instrumentación usa técnicas de instrumentación de código de bytes para insertar código nuevo o para modificar el código existente adentro de la aplicación en el nivel binario. El código que se va a instrumentar se puede proporcionar directamente mediante la rutina de Instalar Instrumentación, o puede ser recuperable desde otro almacén de datos, por ejemplo, el almacén de datos asociado con diferentes políticas del portado . La Figura 27 es un diagrama de flujo de ejemplo del procesamiento que se realiza mediante una rutina de Empaquetar Aplicación de un Administrador de Despliegue. (Ver, por ejemplo, el paso 2304 en la Figura 23) . En el paso 2701, la rutina accesa el perfil de dispositivo de suscriptor recuperado para determinar formatos de archivos compatibles para el dispositivo de suscriptor identificado. En el paso 2702, la rutina determina si el dispositivo de suscriptor es capaz de leer archivos comprimidos y, si así es, procede al paso 2703, de otra manera procede al paso 2704. En el paso 2703, la rutina comprime la aplicación abastecida, con el propósito de reducir al mínimo el tiempo de transmisión y el número de bytes transmitidos. En el paso 2704, la rutina empaqueta la aplicación usando un formato de archivo determinado mediante la encapsulación de la aplicación abastecida con información suficiente para habilitar la Consola de Administración de Microteléfono de la Figura 2) que se ejecuta en un dispositivo inalámbrico para extraer la aplicación. Como se describió anteriormente, un formato que prefieren muchos dispositivos inalámbricos habilitados por Java es el de los archivos JAR comprimidos. En algunos casos, no obstante, la aplicación se necesita distribuir al dispositivo en paquetes más pequeños, los cuales se vuelven a ensamblar en el dispositivo inalámbrico para instalación. El Administrador de Facturación, descrito posteriormente con referencia a la Figura 28, también depende de la información de encapsulación para propósitos de facturación y ruteamiento. Después de que se ha empaquetado la aplicación, la rutina regresa. La Figura 28 es un diagrama de flujo de ejemplo del procesamiento que realiza un Administrador de Facturación de un Sistema Móvil de Aplicaciones. (Ver, por ejemplo, el Administrador de Facturación 507 en la Figura 5) . En el paso 2801, se inicializa el Administrador de Facturación. En el paso 2802, el Administrador de Facturación determina si es tiempo .de generar un reporte de facturación y, si asi es, procede al paso 2803, de otra manera procede al paso 2804. En una modalidad alternativa, el Administrador de Facturación puede responder a una consulta administrativa, por ejemplo, desde el componente Administrador, para generar un reporte de facturación. En el paso 2803, el Administrador de Facturación genera un reporte de facturación con base en los parámetros establecidos por un administrador del sistema. En el paso 2804, el Administrador de Facturación determina si existe una solicitud para registrar información de abastecimiento (para propósitos de facturación) y, si asi es, procede al paso 2805, de otra manera éste regresa. En el paso 2805, el Administrador de Facturación registra los parámetros de la solicitud que se relacionan con la facturación (por ejemplo, la identidad del usuario que hace la solicitud, la categoría de la solicitud, el tamaño de la descarga que se requiere, etcétera) y el estado de las variables del sistema (por ejemplo, la fecha, la hora del día, etcétera) para usarse para facturación futura. Por ejemplo, la longitud de la aplicación, la hora en la que se solicitó la aplicación, el tiempo que se requiere para procesar la aplicación, y el número de aplicaciones se puede usar en la generación de un reporte de facturación. En adición, si se soporta la facturación pagada previamente, entonces el Administrador de Facturación puede generar una solicitud de cuenta al portador, para disminuir apropiadamente la cuenta de facturación pagada previamente del suscriptor. Después de que se ha generado el reporte de facturación y de que se han registrado los parámetros apropiados, el Administrador de Facturación regresa.

FIG. 1 i65 ' Abastecimiento General y Escenario de Procesamiento de Comando Las aplicaciones se publican y se almacenan en MAS o en servidores de terceras -301 partes FIG.3 FIG.4 FIG.5 FIG.6 Solicitud Entrante FIG.7 FIG.8 FIG.12 FIG. 13 FIG. 14 FIG. 15 FIG. 16 FIG. 17 FIG. 18 FIG. 19 FIG. 20 FIG. 21 FIG. 22 FIG. 23 Inspeccionar la Aplicación Descomponer estructura de la aplicación h- 2401 Determinar filtros de h-2402 aplicación aplicables Verificar claves h-2403 maliciosas/proscritas Verificar número, tipo y -2404 frecuencia de las llamadas API Verificar número de -2405 hilos activados FIG. 24 FIG. 26 FIG. 27 FIG. 28 APENDICE E METODO Y SISTEMA PARA FACTURACION A NIVEL PAQUETE EN MEDIO AMBIENTES DE APLICACIÓN INALAMBRICA CAMPO TECNICO La presente invención se relaciona con un método y sistema para medio ambientes de aplicación inalámbrica y, en particular, con métodos y sistemas para facturación y registro de información a nivel paquete en aplicaciones inalámbricas .

DESCRIPCION DETALLADA DE LA INVENCION Las modalidades de la presente invención proporcionan métodos y sistemas basadas en la computadora y la red para facturación a nivel paquete y otros tipos de estadísticas que coleccionan y registran en el nivel paquete en un medio ambiente de aplicación inalámbrica (un "sistema de facturación a nivel paquete") . Se describen en detalle diversas modalidades de muestra en el Apéndice A, el cual se incorpora en la presente como referencia en su totalidad. A pesar de que los métodos y sistemas se describen para usar en la generación y registro de información de facturación de tal manera que el tiempo al aire no es solamente la estadística usada para determinar la facturación para aplicaciones inalámbricas, una persona con experiencia en la técnica reconocerá que se pueden usar cualesquiera de estos mecanismos para registrar otros tipos de información de estadísticas, tal como información de otro tiempo y uso. Para usar con otras estadísticas, en vez de proporcionar una implementación lateral de servidor que implemente las políticas de un servidor de facturación, en su lugar se puede implementar cualquier tipo de política de colección de datos por medio de especificaciones, API, y/u otro código descrito en el Apéndice. El sistema de facturación a nivel paquete se puede implementar de una manera intrusiva o no intrusiva, permitiendo de esta manera un grado variado de flexibilidad tanto en la parte de la clave que sea cambiada para incluir la generación de facturación a nivel paquete y en la parte en la que el código percibe que el código de generación de facturación a nivel paquete está siendo invocada. También, muchos de los métodos pueden coleccionar y generar la facturación (o cualquier otro tipo de información de registro) transparentemente al desarrollador de la aplicación de red. Estos métodos y sistemas incluyen una solución "Writing to Specification" (Escrita según Especificaciones) , una solución de Biblioteca, una solución de Modificación (transmisor) de Software de Dispositivo, y una solución de Instrumentación.

De lo anterior se podrá notar que, a aun cuando las modalidades especificas de la invención han sido descritas en la presente para propósitos de ilustración, se pueden hacer diversas modificaciones sin desviarse del espíritu y alcance de la invención. Por ejemplo, una persona con experiencia en la técnica reconocerá que los métodos y sistemas descritos en la presente son aplicables a la recolección y generación de cualquier tipo de datos de aplicación. Una persona con experiencia en la técnica también reconocerá que los métodos y sistemas descritos en la presente son aplicables a protocolos, medios de comunicación (ópticos, inalámbricos, por cable, y similares) que discrepan y dispositivos de los clientes (tales como aparatos microtelefónicos inalámbricos, organizadores electrónicos, máquinas de correo electrónico portátiles, máquinas de juegos, localizadores, dispositivos de navegación tales como los receptores GPS, y similares) .

APENDICE A - E Facturación a Nivel Paquete Para Aplicaciones de Red en un Medio Ambiente Inalámbrico Indice Definiciones Aplicaciones de No Red Aplicaciones de Red Servidor Cliente Antecedentes Abstracto Soluciones de Facturación del paso 4o para Aplicaciones de Red Solución "Escritura según Especificaciones" (Intrusiva) .. Almacén proxy y Planteamiento De adelantamiento ..

Solución de Biblioteca (Intrusiva) Almacén proxy y Enfoque de Adelantamiento Planteamiento de Computación y Registro Solución de Modificación de Software de Dispositivo (No Intrusivo) Almacén proxy y Enfoque De adelantamiento Planteamiento de Computación y Registro Solución de Instrumentación (No Intrusiva) Implementación Lateral de Servidor basado en DNS Comparación de Soluciones Diferentes Definiciones Tipos de Aplicación Para el propósito de este documento, las aplicaciones que pudieran operarse en un dispositivo inalámbrico están divididas en dos categorías : Aplicaciones No de Red: Estos tipos de aplicaciones no se comunican a través de la red cuanto están activas. Estas aplicaciones tampoco envían ningún dato a la red, ni tampoco reciben ninguno de la red . Ejemplos: libro de direcciones, calculadora, editor de texto, etcétera .

Aplicaciones de Red Estos tipos de aplicaciones usan alguna clase de comunicación de red para accesar otras aplicaciones/ dispositivos/servicios en la red cuando están activas. Estas aplicaciones enviarán/recibirán mensajes en la red Ejemplos: navegador, cliente de correo electrónico, programa de conversación, calendario, etcétera.

Servidor Para el propósito del documento, un servidor es generalmente el software (que puede o no mapear necesariamente al hardware del servidor) que ofrece datos o servicios específicos a los clientes. Se usa la funcionalidad de un servidor dado para identificarlo - por ejemplo, un Servidor de Facturación (que genera y/o registra datos específicos de facturación) , un Servidor Proxy (que actúa como un proxy en la comunicación con otros servidores) , etcétera .

Cliente Para el propósito de este documento, se usa un "cliente" para hacer referencia a una aplicación de red que operar en un dispositivo inalámbrico, que se comunica con un servidor en un escenario tradicional de "cliente servidor" Antecedentes Típicamente, se le hace un cargo a un usuario de un dispositivo inalámbrico cuando ella/el usa tiempo aire o cuando el usuario descarga cualquier aplicación o cualesquiera otros datos al dispositivo, dependiendo de las políticas del portador. Todas las clases de soluciones en curso proporcionan elementos para facturar a un usuario por el tiempo aire y una cantidad total de datos descargados en el dispositivo. Ninguna de las soluciones está disponible actualmente a nivel software o a nivel hardware para permitir que un portador haga un cargo al cliente por usar una aplicación de red en particular, o una porción de una aplicación en dispositivos inalámbricos basados en los datos que la aplicación especifica transmita o reciba.

Compendio El paso cuarto propone un conjunto de soluciones para determinar el uso de datos para una aplicación de red específica a nivel de paquete de datos (es decir, los paquetes de datos enviados y recibidos por el dispositivo inalámbrico) . Estas soluciones permitirán que un portador especifique las políticas de facturación tomando en cuenta no solamente los datos enviados y recibidos sino también la aplicación en cuestión. Las aplicaciones de red usan protocolos de comunicación de bajo nivel como TCP/IP y UDP/IP y protocolos de nivel más alto como HTTP y WAP (Protocolo de Aplicación Inalámbrica) . Las soluciones propuestas son soluciones genéricas y funcionan con cualquier protocolo de comunicación. La implementación de una solución en particular es de protocolo específico y lenguaje específico de aplicación . Las diferentes soluciones propuestas en este documento requieren diferentes tipos de soporte en el dispositivo (en donde reside la aplicación) y en el servidor de facturación (en donde se generan o se registran los datos específicos de facturación) . Este documento describe diferentes maneras para implementar soluciones diferentes para lograr la meta de generar información a nivel paquete para cada aplicación de tal manera que un usuario puede ser facturado con base en los datos que ellos transmitieron/ recibieron en lugar de o en adición a las políticas de facturación de tiempo aire. Una solución completa para proporcionar la facturación a nivel paquete involucra una solución del lado del cliente y una solución del lado del servidor. Dependiendo de la solución, la información de facturación es generada ya sea por el cliente o por el servidor. El servidor de facturación finalmente recolecta información de paquete de datos/tamaño de datos con base en cuáles de estos registros de f cturación son generados .

Soluciones de Facturación de Paso 4 o para Aplicaciones de Red El paso 4o propone las siguientes categorías de soluciones para generar los datos de facturación dependiendo de los datos transmitidos y recibidos por medio de una aplicación mientras ésta esté activa en un dispositivo. Cada categoría de solución proporciona diferentes maneras de implementar la solución. 1. Solución de "Escritura según Especificaciones": Un desarrollador de aplicación de red usa las especificaciones proporcionadas por el paso 4°, para escribir su clave. Las especificaciones indican cómo escribir la parte del código de comunicación de red para que éste genere la información de facturación apropiada a nivel paquete . 2. Solución de Biblioteca: Un desarrollador de aplicación de red usa un conjunto especifico de Interfases de Programación de Aplicación (APIs, por sus siglas en inglés) que generan información de facturación, proporcionada por el paso 4o en forma de biblioteca de software, para escribir su aplicación. Esta solución es una extensión de la solución anterior . 3. Solución de Modif cación de Software de Dispositivo : Un fabricante de dispositivo modifica la capa de software de funcionalidad de la red en el dispositivo para generar la información de facturación. 4. Solución de Instrumentación: El software escanea y modifica una aplicación automáticamente para usar las APIs que generan información de facturación transparentemente (sin alterar la funcionalidad de la aplicación) antes de instalar la aplicación en el dispositivo . Hablando ampliamente, las soluciones se pueden dividir adicionalmente en dos categorías, dependiendo de sí el desarrollador de aplicación tiene que escribir en clave de una manera específica o usar herramientas específicas . 1. Intrusiva: Las primeras dos categorías de soluciones descritas anteriormente "Solución de Escritura según Especificaciones" y "Solución de Biblioteca" son soluciones intrusivas. Un desarrollador de aplicación tiene que codificar de una manera específica o tiene que codificar usando Interfases de Programación de Aplicación (APIs) con el objetivo de generar información de facturación a nivel paquete . 2. No Intrusiva: La tercera y cuarta categorías descritas anteriormente "Solución de Modificación de Software de Dispositivo" y "Solución de Instrumentación" son soluciones no intrusivas. Un desarrollador no tiene que hacer nada especial mientras que escribe su aplicación. En lugar de eso, el paso 4° proporcionó las herramientas para atender la funcionalidad necesaria para generar automáticamente la facturación a nivel paquete. Todas las categorías, intrusivas y no intrusivas, sus pros y sus contras, y el lado del servidor de soluciones específicas a ellos, se describen detalladamente en la presente. A su vez, cada una de las categorías de soluciones, proponen un mecanismo diferente para lograr la funcionalidad requerida .

Solución "Escritura según Especificaciones" (Intrusiva) La solución requiere un 4° paso para proporcionar las especificaciones detalladas a los desarrolladores de la aplicación, describiendo maneras en las que el código de la aplicación se debe escribir. Las especificaciones proporcionan información sobre cómo escribir el código de la aplicación para generar la información de facturación requerida. Un desarrollador tiene que escribir el código en un formato especifico y un secuencia especifica, cumpliendo con lineamientos específicos para que la información de facturación sea generada apropiadamente . Cuando se escribe según esta especificación, se puede usar el siguiente mecanismo basado en proxy para generar la información de facturación.

Almacén proxy y Planteamiento de Adelantamiento Se escribe el código para comunicar una aplicación con un servidor proxy definido previamente. Los datos se envían al servidor proxy en un formato definido previamente (incluyendo información de destino y datos que se adelantan) . El servidor proxy lee los datos definidos previamente (almacenados en un formato conocido) , extrae la información de éste que requiere para comunicarse correctamente con el destino, y adelanta los datos al destino.

Los datos que han sido adelantados al destino denotan al servidor proxy como la fuente, por lo que permite la comunicación en reversa desde el destino. ?1 recibir datos desde el destino, el servidor proxy determina el remitente original y le adelanta los datos recibidos. Mientras que se envían datos de ida y vuelta, se registra la información de paquete de datos/tamaño de datos transmitidos y recibidos, por ejemplo, por medio del servidor proxy (que actúa también como un servidor de facturación o adelantándolo a un servidor de facturación) para que se pueda usar más adelante en la generación de información de facturación .

Solución de Biblioteca (Intrusivo) La "Solución de Biblioteca" es una extensión de la "Solución de Escritura según Especificaciones". En lugar de proporcionarle a un desarrollador de aplicación con especificaciones, a un desarrollador se le proporciona con una biblioteca de software, con un conjunto definido previamente de Interfases de Programación de Aplicación (APIs) , que interactúan transparentemente con el servidor proxy / servidor de facturación. No obstante, un desarrollador tiene que seguir un conjunto especifico de lineamiento al usar la API, pero se captura la especificación implícita por medio de las APIs y el desarrollador no tiene que trabajar extensamente para soportar la aplicación. La solución de Biblioteca se puede usar para permitir el soporte para dos clases diferentes de implementaciones, por medio de proporcionar bibliotecas diferentes y/o múltiples.

Almacén proxy y Planteamiento De adelantamiento Se escribe el código para una aplicación usando un conjunto de APIs definido previamente. Este Planteamiento es el mismo como el que se describió bajo la "solución de Escritura según Especificaciones", excepto que la biblioteca proporcionada a un desarrollador de aplicación i plemente y encapsula la comunicación con el servidor proxy (entre la fuente y el destino) usando diferentes APIs. Las APIs que existen previamente le permiten al desarrollador a que desarrolle su clave sin saber los detalles intrincados de la especificación y las implementaciones del código de la biblioteca. En este Planteamiento, el servidor genera (y registra) la información de facturación.

Cómputo y Registro del Planteamiento Otra implementación del mecanismo de la biblioteca proporciona registro transparente / generación de la información de facturación. Este planteamiento es útil si la red fundamental permite la comunicación directa entre los dispositivos . En esta implementación, en lugar de usar un servidor proxy para manejar el tránsito bidireccional para la aplicación del cliente, solamente se le envían los datos de facturación al servidor de facturación, es decir, tamaño de paquete/número de paquetes, etcétera, y continúa la comunicación normal de los datos de aplicación entre el cliente y el servidor. Específicamente, la biblioteca de APIs esconde la implementación del código (registro) de facturación, la cual ahora se comporta de manera diferente que el "almacén proxy y planteamiento hacia adelante". En lugar de mandar los datos que se van a transmitir al servidor proxy (y recibir a su vez los datos de regreso desde el servidor proxy) , la biblioteca de APIs que está ejecutando en la aplicación determina el tamaño de datos/número de paquetes y envía esta información al servidor de facturación, de manera transparente desde e programa de aplicación. La comunicación con el dispositivo d destino o cualquier servidor externo se realiza directamente Solución de Modificación de Software de Dispositivo (No Intrusivo) Este planteamiento requiere que el paso 4o trabaje con el desarrollador del controlador de software puesto en red (el software del dispositivo responsable de proporcionar la conectividad puesta en red) de un dispositivo en particular para proporcionar la facturación a nivel paquete. Usando este planteamiento, el paso 4o proporciona una pieza especial de software que está integrada con el controlador de software puesto en red. La pieza especial de software proporciona la funcionalidad diferente dependiendo de si se toma un planteamiento proxy o un planteamiento de "computar y registrar". Estos planteamientos son los mismos que aquellos descritos en las dos secciones anteriores, excepto que el desarrollador de aplicación de red no tiene que escribir en clave de ninguna manera especifica o de seguir ninguna especificación. En lugar de esto, el código del controlador de comunicación puesto en red es responsable de proporcionar la funcionalidad especifica de facturación.

Almacén proxy y Planteamiento De adelantamiento Planteamiento Computar y Registrar Dispositivo Servidor de Destino Facturación Solución de Instrumentación (No Intrusiva) La solución de instrumentación es un híbrido de las soluciones de "biblioteca" y de "escritura según especificaciones". Usando este planteamiento, las APIs que fueron escritas según la especificación de facturación son agregadas a la aplicación de red, pero no por el desarrollador de aplicación. Específicamente, el paso 4° proporciona herramientas de software automatizadas, las cuales pueden leer la aplicación de red y modificar su imagen binaria (por ejemplo, clave de byte en J2ME) para que incluya las APIs apropiadas. Las herramientas de software del paso 4o soportan la instrumentación que puede modificar una imagen binaria (por ejemplo, el código de byte en J2ME) al vuelo por medio de agregar, modificar o eliminar el código binario existente (por ejemplo, en formato de clave de byte en J2ME) . Por consiguiente, por medio de introducir automáticamente el código instrumentado, el programa de red puede satisfacer cualquier especificación y proporcionar soluciones de facturación como sean requeridas. Todas las implementaciones del lado del servidor descritas en las secciones anteriores aplican (por ejemplo, almacén proxy y de adelantamiento, y computar y registrar) . Justo antes de instalar la aplicación de red en el dispositivo, la aplicación de red es operada a través del Escáner binario de paso 4o y el Instrumentador . El Escáner determina las APIs puestas en red usadas y las reemplazan automáticamente con las APIs más nuevas puestas en red. Las APIs más nuevas puestas en red proporcionan la misma funcionalidad que las originales, excepto que éstas son también generan información especifica de facturación.

Una vez que las operaciones de la aplicación revisada (Aplicación) , ésta usa las APIs fundamentales puestas en red pero estas APIs proporcionan la funcionalidad extendida para generar/registrar la información de facturación apropiada. En el dibujo anterior la Aplicación representa la versión del paso 4° procesado previamente de la aplicación de red, mientras que la Aplicación' representa la versión del paso 4o procesado posteriormente. El soporte del lado del servidor es el mismo que el del planteamiento de "almacén proxy y de adelantamiento" o "computar y registrar" (vea, por ejemplo, las imágenes descritas bajo las secciones de "Solución de Biblioteca") .

Implementacion del Lado del Servidor basada en DNS Con objeto de soportar la facturación a nivel paquete en clientes en un escenario especifico, se implementa una solución basada en DNS en el servidor. Esta solución es útil para permitir que los dispositivos o programas de una red exterior (tales como aquellos que usan IPs públicos) para accesar dispositivos en una red interna usando IPs privados que no se pueden rutear. De esta manera, los paquetes de datos entrantes (a la aplicación de red) se pueden contar y todavía se puede generar la aplicación de información de facturación . El reto está en proporcionar un elemento para los dispositivos o programas desde la red exterior para comunicarse con los dispositivos interiores, puesto que estos están en redes muy diferentes y generalmente los datos desde un IP privado que no se puede rutear no se pueden enviar a programas que usan el IP público. Una solución de paso 4 o permite esa comunicación por medio de proporcionar su propia implementación del servidor DNS en el lado del portador, el cual funciona con un agrupamiento o agrupamientos de IPs públicos, que son mapeados dinámicamente a los IPs privados de la red interna. El servidor DNS administra el enlace de comunicación virtual entre dos extremos por medio de proporcionar la Traducción de Dirección de Red (???, por sus siglas en inglés) . En un documento por separado está disponible más información, que describe la tecnología para implementar esta solución .

Comparación de Soluciones Diferentes Cada una de las diferentes soluciones tiene sus pros y sus contras. Es más fácil de administrar una solución basada en especificaciones, puesto que no se requiere la distribución del software de biblioteca. Por otro lado, las especificaciones son más difíciles de entender y siguen en comparación a la biblioteca de software. Usando una biblioteca, un desarrollador de aplicación de red llama a las APIs sin saber que pasa bajo la cubierta. En comparación a estas dos, modificar el controlador de software puesto en red es proporcionar la misma funcionalidad y es más fácil de implementar y administrar desde el punto de vista de un desarrollador de aplicación. No obstante, se hace más difícil administrar diferentes dispositivos y se necesita proporcionar una modificación del controlador por separado para cada uno. El soporte para los diferentes APIs de una manera escalable y a prueba de errores puede ser difícil de mantener. Así mismo, puede ser difícil convencer a los numerosos autores del controlador del dispositivo puesto en red que incluyan el código del paso 4°.

En comparación a los planteamientos anteriores, el planteamiento de Instrumentación es el más flexible y escalable. Este proporciona la flexibilidad y las ventajas de las soluciones descritas previamente. Las bibliotecas de software de las APIs, (las cuales son agregadas dinámicamente a una aplicación de red después de escanearlas) son escritas según especificaciones y no requieren de un desarrollador de aplicación de red para entender cómo éstas son escritas. Ni tampoco necesita el desarrollador saber que las APIs de biblioteca se van a agregar. En su lugar, al escanear una aplicación ya escrita por medio de un desarrollador de aplicación, la herramienta del paso 4° inspecciona la aplicación para el uso de las APIs de red (prescindiendo del protocolo) . Al detectar las APIs de red, la herramienta del paso 4o reemplaza las APIs de red detectadas con un conjunto de APIs definidas previamente que implementan las diversas especificaciones. Esta solución no requiere de ninguna intervención por parte de un desarrollador de aplicación. Asi mismo, es más fácil administrar su implementación porque ésta está escondida del desarrollador (hasta pudiera no hacerse pública) . Por consiguiente, permite que se implemente una solución óptima, puesto que la implementación se puede cambiar y extender aun mientras una solución más antigua se encuentre en su lugar. Y por último, pero no menos importante, está menos propensa a cometer errores porque generalmente los pasos automáticos tienden menos a cometer errores que los pasos manuales .

Claims

REIVINDICACIONES 1. Un método en un medio ambiente basado en una computadora para proporcionar facturación basada en la transmisión del contenido que transmite datos a través de una red, que comprende: determinar el código de rastreo de facturación; e instrumentar el código de rastreo de facturación determinada en el contenido modificando el contenido de esta manera, de tal manera que, cuando el contenido modificado sea ejecutado en un dispositivo objetivo, el código del rastreo de facturación automáticamente comunica los datos de facturación basado sobre una cantidad de datos transmitidos entre el contenido modificado y la red.
2. El método de la reivindicación 1 en donde el código de rastreo de facturación rastrea la cantidad de datos enviados desde el contenido instrumentado a través de la red.
3. El método de la reivindicación 2 en donde la red es la Internet.
4. El método de la reivindicación 2 en donde se rastrea la cantidad de datos a nivel paquete que está definido lógicamente.
5. El método de la reivindicación 1 en donde el código de rastreo de facturación rastrea la cantidad de datos recibidos mediante el contenido instrumentado desde la red.
6. El método de la reivindicación 5 en donde la red es la Internet.
7. El método de la reivindicación 5 en donde se rastrea la cantidad de datos a nivel paquete que está definido lógicamente.
8. El método de la reivindicación 1 en donde el contenido está basado en Java.
9. El método de la reivindicación 1 en donde el contenido contiene instrucciones de código de byte .
10. El método de la reivindicación 1 en donde la instrumentación se realiza a un nivel de código de byte del examen de contenido .
11. El método de la reivindicación 1 en donde el contenido instrumentado incluye una clave de seguridad y en donde la clave de seguridad es transmitida con los datos de facturación comunicados automáticamente de tal manera que la integridad de la fuente de los datos de facturación se puede verificar .
12. El método de la reivindicación 11 en donde la clave de seguridad está basada sobre un número al azar.
13. El método de la reivindicación 11 en donde la clave de seguridad es especifica a la aplicación y al suscriptor .
14. El método de la reivindicación 11 en donde la clave de seguridad es instrumentada dentro del contenido al recibir una solicitud para descargar el contenido.
15. El método de la reivindicación 1 en donde el medio ambiente está integrado con una infraestructura de portador inalámbrico.
16. El método de la reivindicación 1, que adicionalmente comprende ocasionar que el contenido instrumentado sea descargado a un dispositivo objetivo a través de un medio de transmisión inalámbrico.
17. El método de la reivindicación 16 en donde el contenido es solicitado por un suscriptor de un portador desde el medio ambiente basado en computadora a través de un medio de transmisión inalámbrico.
18. El método de la reivindicación 1, que adicionalmente comprende ocasionar que el contenido instrumentado sea descargado a un dispositivo objetivo a través de un medio de transmisión cableado.
19. El método de la reivindicación 18 en donde el medio de transmisión cableado es la Internet.
20. El método de la reivindicación 1 en donde los datos de facturación comprenden cuando menos una cantidad de datos enviados, cantidad de datos recibidos, una estampa de tiempo, un identificador de aplicación, una clave de seguridad, un identificador de transacción, y un indicador de expiración para volver a tratar.
21. El método de la reivindicación 1 en donde los datos de facturación se comunican automáticamente sobre la base de transmisión a un sistema de servidor de facturación.
22. El método de la reivindicación 21 que adicionalmente comprende transmitir los datos que no son datos de facturación directamente entre el dispositivo del suscriptor y un sistema de servidor que no es el sistema de servidor de facturación.
23. El método de la reivindicación 1, que adicionalmente comprende integrar los datos de facturación con información de facturación basada en el cliente para generar un registro de datos del cliente.
24. El método de la reivindicación 1 en donde los datos de facturación se usan para soportar una pluralidad de políticas de facturación.
25. El método de la reivindicación 24 en donde las políticas de facturación incluye una oferta promocional que proporciona cambios reducidos para una aplicación designada .
26. El método de la reivindicación 24 en donde un proveedor de contenido proporciona las políticas de facturación.
27. El método de la reivindicación 1 en donde los datos de facturación son usados para proporcionar pagos de regalía a los proveedores del contenido.
28. El método de la reivindicación 1, que adicionalmente comprende ocasionar que los datos transmitidos entre el contenido instrumentado y la red sean ruteados de conformidad con los datos de facturación basados en la transmisión comunicada automáticamente.
29. El método de la reivindicación 28 en donde el ruteado habilita el uso eficiente de los recursos de la red.
30. El método de la reivindicación 28 en donde se asigna una prioridad al contenido basado en el uso de la transmisión .
31. El método de la reivindicación 1 en donde el código de rastreo de facturación utiliza un almacén proxy y una técnica de adelantamiento para transmitir los datos de facturación y los paquetes de transmisión de datos entre el contenido instrumentado y una pluralidad de sistemas de servidores .
32. Un medio de transmisión basado en la red que contiene un contenido que ha sido instrumentado con clave de rastreo de facturación, según el cual el código de rastreo de facturación automáticamente genera los datos de facturación sobre una base de transmisión cuando se ejecuta el contenido en un dispositivo objetivo.
33. El medio de transmisión de la reivindicación 32 en donde el código del rastreo de facturación rastrea la cantidad de datos enviados desde el contenido instrumentado a través de la red.
34. El medio de transmisión de la reivindicación 33 en donde la red es la Internet.
35. El medio de transmisión de la reivindicación 33 en donde la cantidad de datos es rastreada a nivel paquete que está definido lógicamente.
36. El medio de transmisión de la reivindicación 32 en donde el código de rastreo de facturación rastrea la cantidad de datos recibidos por el contenido instrumentado desde la red.
37. El medio de transmisión de la reivindicación 36 en donde la red es la Internet.
38. El medio de transmisión de la reivindicación 36 en donde la cantidad de datos es rastreada a un nivel de paquete que está definido lógicamente.
39. El medio de transmisión de la reivindicación 32 en donde el contenido está basado en Java.
40. El medio de transmisión de la reivindicación 32 en donde la instrumentación se realiza a un nivel de código de byte del examen de contenido.
41. El medio de transmisión de la reivindicación 32 en donde el contenido contiene instrucciones de código de byte .
42. El medio de transmisión de la reivindicación 32 en donde el contenido instrumentado incluye una clave de seguridad.
43. El medio de transmisión de la reivindicación 32 en donde la clave de seguridad es especifica a la aplicación y al suscriptor.
44. El medio de transmisión de la reivindicación 32 en donde el medio de transmisión es un medio de transmisión inalámbrico .
45. El medio de transmisión de la reivindicación 32 en donde el medio de transmisión es un medio de transmisión cableado.
46. El medio de transmisión de la reivindicación 45 en donde el medio de transmisión cableado es la Internet.
47. El medio de transmisión de la reivindicación 32 en donde el código de rastreo de facturación automáticamente genera cuando menos una de las cantidades de datos enviados, cantidad de datos recibidos, una estampa de tiempo, un identificador de aplicación, una clave de seguridad, un identificador de transacción, y un indicador de expiración para volver a tratar.
48. El medio de transmisión de la reivindicación 32 en donde el código de rastreo de facturación se usa para rutear los datos desde el contenido de conformidad con la transmisión basada en los datos de facturación.
49. El medio de transmisión de la reivindicación 32 en donde el contenido es transmitido a un dispositivo inalámbrico objetivo.
50. Un sistema de facturación basado en la transmisión en un medio ambiente de computadora para generar automáticamente datos de facturación para el contenido que se ejecuta en un dispositivo de cliente y que transmite datos a través de una red, que comprende: un modificador de código que instrumenta el contenido con un código de rastreo de facturación, que, cuando se ejecuta en el dispositivo del cliente, automáticamente comunica datos de facturación que reflejan la cantidad de datos transmitidos a través de la red.
51. El sistema de facturación de la reivindicación 50 en donde el código de rastreo de facturación rastrea la cantidad de datos enviados desde el contenido instrumentado a través de la red.
52. El sistema de facturación de la reivindicación 51 en donde la red es la Internet.
53. El sistema de facturación de la reivindicación 51 en donde la cantidad de datos es rastreada a un nivel de paquete lógico.
54. El sistema de facturación de la reivindicación 50 en donde el código de rastreo de facturación rastrea la cantidad de datos recibidos por medio del contenido instrumentado desde la red.
55. El sistema de facturación de la reivindicación 54 en donde la red es la Internet.
56. El sistema de facturación de la reivindicación 54 en donde la cantidad de datos es rastreada a un nivel de paquete lógico.
57. El sistema de facturación de la reivindicación 50 en donde el contenido está basado en Java.
58. El sistema de facturación de la reivindicación 50 en donde el contenido contiene instrucciones de código de byte .
59. El sistema de facturación de la reivindicación 50 en donde la instrumentación se realiza a un nivel de código de byte del examen de contenido.
60. El sistema de facturación de la reivindicación 50 en donde el contenido instrumentado incluye una clave de seguridad y en donde la clave de seguridad es transmitida con los datos de facturación comunicados automáticamente de tal manera que la integridad de la fuente de los datos de facturación se puede verificar al recibirlos.
61. El sistema de facturación de la reivindicación 60 en donde la clave de seguridad est basado en un número al azar.
62. El sistema de facturación de la reivindicación 60 en donde la clave de seguridad es especifica a la aplicación y al suscriptor.
63. El sistema de facturación de la reivindicación 60 en donde la clave de seguridad es instrumentada dentro del contenido al recibir una solicitud para descargar el contenido.
64. El sistema de facturación de la reivindicación 50 en donde el medio ambiente de computadora está integrado con una infraestructura de portador inalámbrico.
65. El sistema de facturación de la reivindicación 50, que adicionalmente comprende ocasionar que se descargue el contenido instrumentado a un dispositivo objetivo a través de un medio de transmisión inalámbrico.
66. El sistema de facturación de la reivindicación 65 en donde el contenido es solicitado por un suscriptor de un portador desde el medio ambiente de computadora a través de una medio de transmisión inalámbrico.
67. El sistema de facturación de la reivindicación 50, que adicionalmente comprende ocasionar que el contenido instrumentado sea descargado a un dispositivo objetivo a través de un medio de transmisión cableado.
68. El sistema de facturación de la reivindicación 67 en donde el medio de transmisión cableado es la Internet.
69. El sistema de facturación de la reivindicación 50 en donde los datos de facturación comprenden cuando menos una de las cantidades de datos enviados, cantidad de datos recibidos, una estampa de tiempo, un identificador de aplicación, una clave de seguridad, un identificador de transacción, y un identificador de expiración para volver a tratar.
70. El sistema de facturación de la reivindicación 50 en donde los datos de facturación son comunicados automáticamente sobre la base de transmisión a un sistema de servidor de facturación.
71. El sistema de facturación de la reivindicación 70, que adicionalmente comprende un módulo de detección de paquete y de adelanto para transmitir los datos que no son datos de facturación directamente entre el dispositivo del suscriptor y un sistema de servidor que no es el sistema de servidor de facturación.
72. El sistema de facturación de la reivindicación 50, que adicionalmente comprende integrar los datos de facturación con la información de facturación basada en el cliente para generar un registro de datos del cliente.
73. El sistema de facturación de la reivindicación 50 en donde los datos de facturación se usan para soportar una pluralidad de políticas de facturación.
74. El sistema de facturación de la reivindicación 73 en donde las políticas de facturación incluyen una oferta promocional que proporciona cargos reducidos para una aplicación designada.
75. El sistema de facturación de la reivindicación 73 en donde las políticas de facturación son proporcionadas por medio de un proveedor de contenido.
76. El sistema de facturación de la reivindicación 50 en donde los datos de facturación son usados para proporcionar los pagos de regalía a los proveedores de contenido.
77. El sistema de facturación de la reivindicación 50, que adicionalmente comprende ocasionar que los datos transmitidos entre el contenido instrumentado y la red sean ruteados de conformidad con los datos de facturación basados en la transmisión.
78. El sistema de facturación de la reivindicación 77 en donde el ruteado habilita el uso eficiente de recursos en la red.
79. El sistema de facturación de la reivindicación 77 en donde se asigna una prioridad al contenido basado en el uso de transmisión.
80. El sistema de facturación de la reivindicación 50 en donde el código de rastreo de facturación incorpora un almacén proxy y una técnica de adelantamiento para transmitir los datos de facturación y los paquetes de transmisión de datos entre el contenido instrumentado y una pluralidad de sistemas de servidores.
81. Un medio de memoria legible por computadora que contiene instrucciones para controlar un procesador de computadora en un dispositivo inalámbrico para transmitir automáticamente los datos de facturación basados en paquetes en una base por contenido, por medio de: registrar la cantidad de datos recibidos con un identificador del contenido cuando un paquete de datos es recibido por contenido desde una red; registrar la cantidad de datos que se van a enviar con un identificador del contenido cuando un paquete de datos que se va a enviar por el contenido desde una red; y transmitir la cantidad de datos registrada con el identificador del contenido a un sistema de servidor para que sea acumulada, habilitando de esta manera al sistema de servidor para que facture a un suscriptor basándose en los datos acumulados.
82. El medio de memoria legible por computadora de la reivindicación 81 en donde el registrar la cantidad de datos se realiza por medio del código que está cargado transparentemente en el dispositivo inalámbrico.
83. El medio de memoria legible por computadora de la reivindicación 81 en donde registrar la cantidad de datos y transmitir los datos registrados se realiza por medio del código que reside en una biblioteca de códigos.
84. El medio de memoria legible por computadora de la reivindicación 81 en donde el registrar la cantidad de datos y transmitir los datos registrados se realiza por medio del código que reside en el software del controlador de la red del dispositivo inalámbrico.
85. El medio de memoria legible por computadora de la reivindicación 81 en donde el registrar la cantidad de datos y transmitir los datos registrados se realiza por medio del código que está escrito a una especificación para la facturación basada en la transmisión.
86. El medio de memoria legible por computadora de la reivindicación 81 en donde el registrar la cantidad de datos y transmitir los datos registrados se realiza por medio del código que está instrumentado dentro de las instrucciones previo a la ejecución de las instrucciones en el dispositivo del cliente.
87. ün método en un dispositivo inalámbrico para transmitir automáticamente los datos de facturación basados en paquetes, que comprende: registrar la cantidad de datos recibidos cuando se recibe un paquete de datos desde una red; registrar la cantidad de datos a enviar cuando un paquete de datos se va a enviar a través de la red; y transmitir la cantidad de datos registrada a un sistema de servidor para ser acumulados, habilitando de esta manera al sistema de servidor para que facture a un suscriptor basándose en los datos acumulados.
88. El método de la reivindicación 87 en donde el registro de la cantidad de datos se realiza por medio de código que está transparentemente cargado dentro del dispositivo inalámbrico.
89. El método de la reivindicación 87 en donde el registro de la cantidad de datos y la transmisión de los datos registrados se realiza por medio del código que reside en una biblioteca de códigos .
90. El método de la reivindicación 87 en donde el registro de la cantidad de datos y la transmisión de los datos registrados se realiza por medio del código que reside en el software del controlador de la red del dispositivo inalámbrico.
91. El método de la reivindicación 87 en donde el registro de la cantidad de datos y la transmisión de los datos registrados se realiza por medio del código que está escrito según una especificación para la facturación basada en la transmisión.
92. El método de la reivindicación 87 en donde el registro de la cantidad de datos y la transmisión de los datos registrados se realiza por medio del código que está instrumentado dentro de las instrucciones previo a la ejecución de las instrucciones en el dispositivo del cliente.
93. Un dispositivo inalámbrico que automáticamente transmite datos de facturación basados en paquetes, que comprende: registrar la cantidad de datos recibidos cuando se recibe un paquete de datos desde una red; registrar la cantidad de datos que se van a enviar cuando un paquete de datos se va a enviar a través de la red; y transmitir la cantidad de datos registrados a un sistema de servidor para ser acumulados, habilitando de esta manera al sistema de servidor para facturar a un suscriptor basándose en los datos acumulados.
94. El dispositivo inalámbrico de la reivindicación 93 en donde el código de facturación y rastreo se · carga transparentemente dentro del dispositivo inalámbrico.
95. El dispositivo inalámbrico de la reivindicación 93 en donde el código de facturación y rastreo reside en la biblioteca de códigos.
96. El dispositivo inalámbrico de la reivindicación 93 en donde el código de facturación y rastreo reside en el software del controlador de la red del dispositivo inalámbrico y es invocado desde la aplicación.
97. El dispositivo inalámbrico de la reivindicación 93 en donde el código de facturación y rastreo es escrita según una especificación para facturar basándose en la transmisión.
98. El dispositivo inalámbrico de la reivindicación 93 en donde el código de facturación y rastreo está instrumentado dentro de la aplicación previo a la ejecución de la aplicación. RESUMEN Se proporcionan métodos y sistemas basados en computadora y en red para facturación basada en la transmisión. Las modalidades de ejemplo proporcionan un Sistema de Facturación Basado en Paquetes ("PBBS") , el cual hace posible que los proveedores de aplicaciones, tales como distribuidores y proveedores de contenido, facturen a los suscriptores por el uso del contenido en aparatos móviles de los suscriptores, tales como aparatos inalámbricos, sobre una base por aplicación y por usuario, basándose en el grado de uso. Las modalidades de la presente invención también se pueden utilizar para facturar a los suscriptores por el uso del contenido sobre una base por aplicación y por usuario, también para aparatos alámbricos de los suscriptores, utilizando las mismas técnicas. En la operación, el Sistema de Facturación Basado en Paquetes proporciona contenido modificado mediante la inserción del código de facturación y rastreo en el contenido devuelto a un aparato solicitante. El contenido modificado, cuando se ejecuta, rastrea la cantidad de datos enviados y recibidos entre el contenido y una red, y coloca los datos acumulados en un servidor de facturación/proxy de acuerdo con las reglas del negocio, por un intervalo/frecuencia para colocar estos datos. El servidor de facturación/proxy almacena los datos de facturación brutos, y un programa de contabilidad recupera los datos de facturación para generar registros de datos del cliente (llamada) . Se pueden incorporar en el sistema reglas comerciales que especifiquen diferentes cargos para diferentes contenidos o usuarios.