PROGRAMACION ESTANDAR PERSONALIZADA DE PUBLICIDAD
Campo de la Invención La invención se refiere generalmente a un método y un sistema para facilitar la distribución y acceso de información electrónica. Específicamente, la invención se refiere a un sistema y método para proporcionar información de publicidad a aplicaciones . Antecedentes de la Invención Las aplicaciones soportadas en publicidad están incrementando en popularidad ya que los publicistas y compañías se esfuerzan por nuevas formas de llegar al público o un segmento específico de éste. La aplicación soportada en publicidad o adware es cualquier paquete de software el cual automáticamente reproduce, exhibe, o descarga material de publicidad a una computadora después de que el software se instala en esta o mientras la aplicación está siendo usada. Las aplicaciones soportadas en publicidad son frecuentemente pequeñas y no intrusas para atraer más usuarios y parecer menos invasiva. Las compañías frecuentemente ofrecen grandes descuentos u ofertas especiales a través de estas aplicaciones como un incentivo para usar las aplicaciones de publicidad. Las aplicaciones soportadas en publicidad se han desarrollado para dispositivos de computación tales como computadoras de
Ref. 199278
escritorio, computadoras portátiles y aún dispositivos móviles, tales como Asistentes Personales de Datos (PDAs) y teléfonos celulares . Sin embargo, con el número siempre incrementado de tipos y marcas de dispositivos de computación, los desarrolladores de aplicaciones soportadas en publicidad frecuentemente necesitan programar las aplicaciones específicamente para cada dispositivo o arquitectura. Las aplicaciones de programación para cada diferente tipo de dispositivo o arquitectura pueden ser consumidoras de tiempo, complejas y costosas no solamente para los desarrolladores sino para las compañías que respaldan tales negocios. Como tal, algunas aplicaciones de publicidad pueden existir solamente para ciertos dispositivos o tipos de dispositivos, limitando el alcance de algunos anuncios. Además, la descarga de aplicaciones que no están específicamente diseñadas para un dispositivo del usuario puede causar problemas técnicos significativos con el dispositivo. Por las razones anteriores, es necesario un sistema y método para facilitar el acceso o funcionalidad de publicidad. Breve Descripción de la Invención Muchos de los problemas mencionados antes son resueltos proporcionando un método y sistema que proporciona una interfaz de programación de aplicación para facilitar la funcionalidad del anuncio. Los desarrolladores de aplicación
pueden crear aplicaciones usando funciones y ganchos proporcionados por una programación estándar personalizada de anuncios estandarizado. La programación estándar personalizada de anuncios proporciona la funcionalidad de interconectarse con componentes de hardware y software asociados con un dispositivo particular. Como tal, los desarrolladores de aplicaciones no necesitan proveer su programación a un dispositivo particular o tipo de dispositivo. La programación estándar personalizada de anuncios puede contener varios módulos incluyendo un reproductor de anuncios, un caché de anuncios, reporte, perfil, rastreador de lealtad y un componente de pago. Cada módulo facilita ciertas funciones asociadas con la exhibición o de otra forma proporciona un anuncio a una aplicación. Por ejemplo, el módulo de reproductor puede incluir programación que instruye a un visualizador del dispositivo fundamental a exhibir o reproducir uno o más anuncios. El caché puede almacenar anuncios para recuperación más rápida. De conformidad con otro aspecto, la programación estándar personalizada de aplicación puede rastrear la lealtad de un usuario a una cierta compañía o tipo de anuncio. Un usuario puede ganar crédito de lealtad si, por ejemplo, ve y/o da clic en múltiples anuncios de una cierta compañía durante un período de tiempo especificado. Alternativamente, el crédito de lealtad puede ser ganado si un usuario compra un producto que es anunciado.
De conformidad con aún otro aspecto, la programación estándar personalizada puede incluir adicionalmente una capa de transporte que implementa múltiples protocolos de transporte. Con la capa de transporte, las comunicaciones entre una aplicación y un servidor de contenidos, por ejemplo, pueden ser significativamente agilizadas. En particular, puede no ser requerido que las aplicaciones conozcan cuales servidores usan cuál protocolo de comunicación. Como tal, las aplicaciones pueden recuperar anuncios de una variedad de servidores usando diferentes protocolos de comunicación. En todavía otro aspecto, el programación estándar personalizada puede proporcionar un modelo de pago para desarrolladores . Específicamente, el programación estándar personalizada puede mantener el rastreo de visitantes por unidad de tiempo u otras formas de acceso de anuncios para cada aplicación de publicidad. Con base en el número de visitantes por unidad de tiempo asociados con una aplicación de publicidad particular, el desarrollador de la aplicación de publicidad puede ser recompensado con un pago especificado. Por consiguiente, varios modelos de pago de publicidad se pueden desarrollar con base en la efectividad de las aplicaciones de publicidad. Los incentivos pueden motivar adicionalmente al desarrollo de aplicaciones de publicidad adicionales. Estas así como otras ventajas y aspectos de la invención son evidentes y entendidos a partir de la siguiente
descripción detallada de la invención, las reivindicaciones anexas, y las figuras acompañantes. Breve Descripción de las Figuras La presente invención se ilustra por vía de ejemplo y no limitada a las figuras acompañantes en las cuales los números de referencia similares indican elementos similares y en las cuales : La figura 1 ilustra un diagrama de bloques de un sistema de comunicación inalámbrico en el cual varias modalidades se pueden implementar. La figura 2 ilustra una terminal móvil en la cual una o más modalidades ilustrativas se pueden implementar. La figura 3 es un diagrama de bloques que ilustra componentes de una programación estándar personalizada de aplicación e interacciones con otros componentes de acuerdo con uno o más aspectos descritos en éstos. La figura 4 ilustra un diagrama de funcionalidad de bloque de un componente de programación estándar personalizada de acuerdo con uno o más aspectos descritos en la presente . La figura 5 ilustra un diagrama de flujo de un método para proporcionar anuncios relevantes a una aplicación de solicitud vía un componente de programación estándar personalizada de acuerdo con uno o más aspectos descritos en la presente . La figura 6 es un diagrama de flujo que ilustra un
método para proporciona incentivos a desarrolladores de aplicación de acuerdo con uno o más aspectos descritos en la presente . Descripción Detallada de la Invención En la siguiente descripción de las diversas modalidades, se hace referencia a las figuras acompañantes, las cuales forman una parte de las mismas, y en las cuales se muestra por vía de ilustración varias modalidades en las cuales la invención se puede practicar. Se entenderá que otras modalidades se pueden utilizar y se pueden hacer modificaciones estructurales y funcionales sin apartarse del alcance de la presente invención. Los aspectos de la presente invención se pueden utilizar a través de un amplio arreglo de redes y protocolos de comunicación. La figura 1 ilustra un ejemplo de un sistema de comunicación inalámbrico 100 en el cual se pueden emplear sistemas y métodos de acuerdo con al menos algunas modalidades . Uno o más dispositivos móviles habilitados en red 112, tales como un asistente personal digital (PDA) , teléfono celular, terminal móvil, grabadora de video personal, televisión portátil, computadora portátil, cámara digital, videocámara digital, dispositivo de audio portátil, radio portátil, o combinaciones de los mismos, están en comunicación con una fuente de servicio 122 a través de una red de difusión 114 (la cual puede incluir la Internet o red similar) y/o red celular
116. La terminal/dispositivo móvil 112 puede incluir un dispositivo receptor de difusión de banda ancha digital. La fuente de servicio 112 puede ser conectada a varios proveedores de servicio tal como la fuente de anuncios 125 que puede proporcionar su contenido de programa actual o información o descripción de sus servicios y programas a la fuente de servicio 122 que adicionalmente proporciona el contenido o información al dispositivo móvil 112. Los diversos proveedores de servicio incluyendo fuente de anuncios 125 pueden incluir, pero no se limitan a, uno o más proveedores de servicio de televisión y/o televisión digital, proveedores de servicio de radio AM/FM, servidores y/o proveedores de anuncios, proveedores de servicio push SMS/MMS, proveedores de acceso o contenido de Internet. En uno o más arreglos, la red de difusión 114 puede difundir anuncios de una o más fuente de servicio tal como fuente de servicio 122. La fuente de servicio 122 puede obtener o recibir anuncios de un servidor o proveedor de anuncios. Los anuncios luego se pueden recibir por la terminal móvil 112 a través de la red de difusión 114 y almacenar en una base de datos para exhibir a un usuario de la terminal 112. En un ejemplo, una fuente de servicio de difusión 122 puede obtener ingresos de la exhibición de anuncios en sus difusiones. Como tal, la fuente de servicio de difusión 122 puede recuperar periódicamente los anuncios de una fuente de anuncios 125 o base de datos y difundir el anuncio a una población de usuario
suscrita al servicio de difusión. Un método para difundir datos es usando difusión de datos IP (IPDC) . La IPDC combina la difusión digital y Protocolo de Internet. Como tal, una variedad de información y servicios se pueden transmitir usando una red y protocolo. El dispositivo móvil 112 también puede enviar y recibir mensajes a y desde la fuente de servicio 122 a través de la red celular 116. La red celular 116 puede incluir una red inalámbrica y un transmisor de estación de transceptor base 120. La red celular puede incluir una red de comunicaciones de datos celular de segunda/tercera generación (2G/3G) , un Sistema Global para red de comunicaciones móvil (GSM) , un Sistema de Telecomunicaciones Móvil Universal (UMTS) y/u otra red de comunicación inalámbrica tal como una red WLA . En uno o más aspectos, las comunicaciones a través de la red celular 116 pueden permitir a una fuente de servicio 122 distribuir anuncios en una base individual. Es decir, antes que la difusión de anuncios a una población de suscriptores completa, la fuente de servicio 122 puede obtener y distribuir anuncios de una fuente de publicidad 125 con base en los intereses del usuario, estadísticas de uso, un tiempo de uso más frecuente del usuario y similares. Alternativamente o adicionalmente, el dispositivo móvil 112 puede acceder ya sea a la red de difusión 114 o red celular 116 para recuperar los anuncios u otras formas de contenido de un servidor o proveedor de contenido 122. En un
ejemplo, el dispositivo 112 puede solicitar anuncios adicionales de un servidor de anuncios 125 en respuesta la determinación que no se almacenan anuncios en el dispositivo 112. De conformidad con un aspecto de la invención, el dispositivo móvil 112 puede incluir una interfaz inalámbrica configurada para enviar y/o recibir comunicaciones inalámbricas digitales dentro de la red celular 116 usando el transmisor de estación de transceptor base 120. La información recibida por el dispositivo móvil 112 a través de la red celular 116 o red de difusión 114 vía una torre de red celular 118 puede incluir la entrada o selección de usuario (por ejemplo, en una transmisión interactiva) , aplicaciones, servicios, imágenes electrónicas, solicitudes de contenido, clips de audio, clips de video, y/o mensajes WTAI (Interfaz de Aplicación de Telefonía Inalámbrica) . Como parte de la red celular 116, una o más estaciones base (no mostradas) pueden soportar comunicaciones digitales con el dispositivo receptor 112 mientras que el dispositivo receptor se ubica dentro del dominio administrativo de la red celular 116. Como se muestra en la figura 2, el dispositivo móvil 112 puede incluir el procesador 128 conectado a la interfaz de usuario 130, memoria 134 y/u otro almacenamiento, y visualizador 136. El dispositivo móvil 112 también puede incluir la batería 150, altavoz 152 y antenas 154. La interfaz de usuario 130 puede incluir adicionalmente un teclado, pantalla táctil, interfaz de voz, teclas de cuatro flechas, palanca de mando, lápiz óptico,
guante de datos, ratón, bola de rodillos, pantalla táctil, o similares. Además, la interfaz de usuario 130 puede incluir la totalidad o porción del visualizador 136. Las instrucciones ejecutables por computadora y los datos usados por el procesador 128 y otros componentes dentro del dispositivo móvil 112 se pueden almacenar en una memoria leíble por computadora 134. La memoria se puede implementar con cualquier combinación de módulos de memoria de solo lectura o módulos de memoria de acceso aleatorio, incluyendo opcionalmente memoria tanto volátil como no volátil. El software 140 se puede almacenar dentro de la memoria 134 y/o almacenar para proporcionar instrucciones al procesador 128 para hacer posible que el dispositivo móvil 112 realice varias funciones. Alternativamente, algunas o todas las instrucciones ejecutables por computadora se pueden incluir en el hardware o firmware (no mostrado) . El dispositivo móvil 112 se puede configurar para recibir, decodificar y procesar transmisiones de difusión de banda ancha digitales que se basan, por ejemplo, en el estándar de Difusión de Video Digital (DVB) , tal como DVB-H, DVB-T o DVB-MHP, a través de un receptor DVB específico 141. El dispositivo móvil también se puede proporcionar con otros tipos de receptores para transmisiones de difusión de banda ancha digitales. Adicionalmente , el dispositivo receptor 112 también se puede configurar para recibir, decodificar y procesar
transmisiones a través del receptor de radio FM/AM 142, transceptor WLA 143, y transceptor de telecomunicación 144. En un aspecto de la invención, el dispositivo móvil 112 puede recibir mensajes de corriente de datos de radio (RDS) . En un ejemplo del estándar DVB, una transmisión DVB de
Mbit/s puede tener 200 canales de programa de audio de 50 kbit/s ó 50 canales de programa de video (TV) de 200 kbits/s. El dispositivo móvil 112 puede ser configurado para recibir, decodificar, y procesar transmisión basado en el estándar de Difusión de Video Digital para Dispositivos Móviles (DVB-H) u otros estándares DVB, tales como DVB de Plataforma Casera de Multimedia, DVB Satelital (DVB-S) , DVB Terrestre (DVB-T) o DVB por Cable (DVB-C) . De manera similar, otros formatos de transmisión digital se pueden usar alternativamente para suministrar contenido e información de disponibilidad de servicios complementarios, tal como ATSC (Comité de Sistemas Avanzados de Televisión) , NTSC (Comité de Sistema Nacional de Televisión) , ISDB-T (Difusión Digital de Servicios Integrado Terrestre) , DAB (Difusión de Audio Digital) , DMB (Difusión de Multimedia Digital) , FLO (Enlace Unico Directo) o DIRECTV. Adicionalmente, la transmisión digital puede ser recortada de tiempo, tal como en la tecnología DVB-H. El recorte de tiempo puede reducir el consumo de energía promedio de una terminal móvil y puede habilitar el traspaso suave y continuo. El recorte de tiempo consiste en enviar datos en ráfagas usando una
velocidad de bits instantánea mayor cuando se compara con la velocidad de bits requerida si los datos fueran transmitidos usando un mecanismo de transmisión en directo tradicional. En este caso, el dispositivo móvil 112 puede tener una o más memorias intermedias para almacenar la transmisión recortada de tiempo decodificada antes de la presentación. La energía del receptor entre ráfagas se puede apagar para reducir el consumo de energía. En una o más configuraciones, un usuario de un dispositivo móvil puede estar de acuerdo para recibir anuncios en su dispositivo móvil. Por ejemplo, un usuario puede descargar una aplicación widget que proporciona transacciones o descuentos para permitir que los anuncios de organizaciones o compañías sean exhibidos en el dispositivo del usuario. Para facilitar la visualización de anuncios en aplicaciones widget y otras aplicaciones, la terminal móvil del usuario puede incluir una programación estándar personalizada de anuncios que proporciona un widget o aplicación API que permite que una aplicación ordene a las funciones estandarizadas a recuperar los anuncios o realizar otras tareas de publicidad. Un widget, como se usa en la presente, se refiere a una aplicación y/o elemento de interfaz de usuario que proporciona información tal como publicidad o información de clima a un usuario con base en una variedad de factores tales como preferencias del usuario. Los ejemplos de widgets de publicidad y otras aplicaciones de
publicidad se describen en una solicitud de patente de Estados Unidos identificada como Documento de Apoderado No. 004770.00924, titulada "AUCTIONS FOR WIDGET SPACE", presentada el 15 de Junio de 2006, el contenido de la cual se incorpora para referencia en su totalidad. Programación estándar personalizada, en general, se refiere a una entidad que facilita la interacción entre componentes de software y/o hardware. Por ejemplo, una programación estándar personalizada puede realizar procesos tales como mediación entre una aplicación y una red para manejar la interacción entre aplicaciones desiguales a través de plataformas heterogéneas. La programación estándar personalizada de anuncios descrita en la presente proporciona una variedad de funcionalidades asociadas con la visualización y recuperación de anuncios. En particular, la programación estándar personalizada libera al widget u otra aplicación de tener que implementar las funcionalidades de programación estándar personalizada. En su lugar, la aplicación puede ordenar a varias funciones de la programación estándar personalizada a realizar varias tareas o procesos de anuncios. La programación estándar personalizada de anuncios se puede almacenar en un medio legible por computadora 134 en una terminal móvil del usuario 112 a lo largo de una o más aplicaciones de anuncios que pueden interconectarse con la programación estándar personalizada. La aplicación o widget de anuncios puede exhibir anuncios u otra información en el
visualizador 136. La programación estándar personalizada de anuncios también puede incluir componentes para interconectarse con uno o más componentes de hardware tales como transceptor LAN 143, transceptor de telecomunicaciones 144 y visualizador 136 para realizar una o más tareas. La figura 3 es un diagrama de bloques que ilustra un componente de programación estándar personalizada 301. Entre otras capacidades, el componente de programación estándar personalizada 301 puede coordinar la comunicación, datos, mensajes e interacción de usuario entre uno o más servidores de contenido 315a y 315b y una o más aplicaciones 305a, 305b y 305c ejecutadas en el dispositivo de terminal móvil. El componente de programación estándar personalizada 301 puede exponer una o más APIs funcionales, tal como API 307, para proporciona una aplicación 305 con una interfaz estandarizada para realizar funciones relacionadas con anuncios. Por ejemplo, la API funcional 307 puede publicar una función llamada GET_ADVERTISEMENT que dirige el componente de programación estándar personalizada 301 para obtener uno o más anuncios con basa en uno o más parámetros especificados. Otras funciones también se pueden publicar a través de la API funcional 307 que incluye DISPLAY_ADVERTISEMENT que dirige la programación estándar personalizada 301 para exhibir una publicidad en un visualizador de un dispositivo de terminal móvil y ADD_CREDIT que instruye al programación estándar personalizada 301 a
agregar crédito o puntos de lealtad a una cuenta del usuario. El crédito y/o puntos de lealtad se puede agregar con base en los factores tales como un número de anuncios vistos en el dispositivo. El componente de programación estándar personalizada
301 también puede interactuar con un servidor 315a ó 315b a través de una capa de transporte 317 la cual puede incluir una pluralidad de mecanismos de transporte y/o protocolos incluyendo HTTP, FTP, SMS, Bluetooh, WLA , Identificación de Radiofrecuencia (RFID) , RSS, ó Código de barras 2D. Por ejemplo, el componente de programación estándar personalizada 301 puede determinar que no existen anuncios disponibles en el almacenamiento del dispositivo. Como tal, la programación estándar personalizada 301 puede conectarse a un servidor de anuncios 315a para solicitar anuncios adicionales. La solicitud se puede emitir a través de la capa de transporte 317 la cual puede proporcionar múltiples protocolos para hacer tal solicitud. En otro ejemplo, la programación estándar personalizada 301 puede actualizar periódicamente un servidor de anuncios 315a con información de lealtad asociada con un usuario o dispositivo particular a través de la capa de transporte 317. En general, la capa de transporte 317 puede facilitar cualquier comunicación con dispositivos o entidades externas. Alternativamente o adicionalmente, el componente de programación estándar personalizada 301 puede incluir o
interactuar con una API de hardware para instruir a varios componentes de hardware a realizar ciertas funciones o tareas. En uno o más casos, una aplicación puede ordenar una función DISPLAY_ADVERTISEME T. En respuesta, la programación estándar personalizada 301 puede interconectarse con un componente de visualizador a través de la API de hardware para exhibir un anuncio específico. Los procesos e interfaces mostradas en la figura 3 son para propósitos ilustrativos, y aquellos de experiencia en la técnica apreciarán que el componente de programación estándar personalizada 301 puede soportar procesos, componentes e interfaces adicionales además de aquellos mostrados . Adicionalmente, el componente de programación estándar personalizada 301 expone una o más APIs a programas de aplicación 305a, 305b y 305c ejecutados en el dispositivo de terminal móvil. Los programas de aplicación 305a, 305b y 305c se pueden implementar en una variedad de plataformas incluyendo Symbian y J2ME. Cada programa de aplicación 305a, 305b y 305c puede contener programación predefinida para facilitar la interconexión con el componente de programación estándar personalizada 301 usando las APIs expuestas. Las APIs funcionales asociadas con la programación estándar personalizada 301 se pueden publicar al público o un grupo de desarrolladores para permitirles implementar la programación apropiada en las aplicaciones 305a, 305b y 305c para utilizar
las funcionalidades día programación estándar personalizada 301. Por consiguiente, las aplicaciones 305a, 305b y 305c no pueden necesitar implementar las funcionalidades ya proporcionadas por el componente de programación estándar personalizada 301. Por ejemplo, las apliaciones no pueden necesitar incluir programación para realizar funciones tales como almacenamiento de perfiles de usuario e interconexión con subsistemas de software y hardware. Las ventajas de usar las funcionalidades del componente 301 pueden incluir una reducción en la carga en el sistema operativo completo del dispositivo fundamental. La figura 4 es un diagrama de bloques que ilustra la arquitectura de un componente de programación estándar personalizada, tal como componente 301 de la figura 3. El componente de programación estándar personalizada puede incluir un módulo de reproductor 411, un módulo de caché 412, un módulo de reporte 413, un módulo de perfil 414, un módulo de lealtad 415, y/o un módulo de pago 416. Además, el componente de programación estándar personalizada 301 puede interconectarse con un servidor de contenido 315 (no mostrado) , por ejemplo, servidor de publicidad, vía mecanismo de transporte 317, así como con el usuario del dispositivo de terminal móvil vía una o más interfaces de usuario final tales como teclas, botones, disco selectores, pantallas de visualización, altavoces, etc., del dispositivo de terminal móvil. Como se describió anteriormente, la API 307 funcional
puede interconectarse con uno o más programas de nivel de aplicación (no mostrados) . Esta interacción se puede controlar y/o dirigir por un usuario del dispositivo de terminal móvil en el cual una o más aplicaciones son ejecutadas vía una o más interfaces de usuario final. Las llamadas y solicitudes de función por las aplicaciones a través de la API funcional 308 se pueden enrutar directamente al módulo del componente de programación estándar personalizada al cual corresponde, como se describe posteriormente adicionalmente . Alternativamente o adicionalmente, el componente de programación estándar personalizada 301 puede incluir un módulo manejador (no mostrado) que inicialmente recibe la solicitud o entrada de la aplicación vía la API funcional 307 y dirige la solicitud al módulo aplicable del componente de programación estándar personalizada 301. Mientras que las APIs específicas son llamadas y descritas en la presente, aquellos de experiencia en la técnica apreciarán que se pueden usar APIs diferentes. El módulo de reproductor 411, en una modalidad ilustrativa, es responsable de exhibir o proporcionar de otra forma uno o más anuncios a la aplicación. El módulo de reproductor 411 puede recibir una solicitud de una aplicación vía la API funcional 307 para exhibir o proporcionar anuncios. En respuesta, el módulo de reproductor 411 puede extraer de la solicitud uno o más parámetros, tales como el tipo de anuncio a ser proporcionado, por ejemplo, pantalla completa, banner, cinta
de información, o widget; duración para exhibir o reproducir el anuncio; posición y/o tamaño del anuncio a ser exhibido; e intervalo para refrescar el anuncio o para proporcionar nuevos anuncios . Algunos parámetros pueden ser opcionales y se pueden usar con valores por defecto pre-definidos si se dejan sin especificar. El módulo de reproductor 411 puede seleccionar posteriormente uno o más anuncios de conformidad con los parámetros de un módulo de caché 412 que almacena anuncios. El módulo de caché 412 se puede implementar como una base de datos con funciones de recuperación para facilitar la selección de anuncios con base en los parámetros. Si el módulo de caché 412 está vacío o no contiene algunos anuncios ajustando los parámetros solicitados por la aplicación, el módulo de reproductor 411 o módulo de caché 412 puede recuperar uno o más anuncios de un servidor (por ejemplo, servidor 315a de la figura 3) vía un mecanismo de transporte 317 de conformidad con los parámetros especificados en la solicitud inicial. Los parámetros adicionales se pueden extraer del dispositivo, tal como uso e información de perfil de usuario, y se pueden proporcionar al servidor para facilitar el suministro de contenido optimizado. Por ejemplo, los parámetros relacionados con el género se pueden extraer de la información de perfil de usuario para determinar las preferencias de anuncios con base en el género del usuario. Estos parámetros se pueden usar para recuperar, o
colocar una mayor prioridad de recuperación, anuncios dirigidos a una audiencia masculina, y/o no recuperar, o colocar una prioridad menor de recuperación, anuncios dirigidos exclusivamente a una audiencia femenil. Adicionalmente o alternativamente, el módulo de caché 412 puede recuperar periódicamente nuevos anuncios del servidor con base en los parámetros previamente usados . Por ejemplo, la información de uso transmitida al servidor puede revelar que una porción significativa de anuncios que es exhibida en una aplicación ha sido con respecto a equipo deportivo en un anuncio tipo banner. El módulo de caché 412 puede recuperar periódicamente, por ejemplo, cada cinco horas, nuevos anuncios del servidor con respecto al equipo deportivo en un formato tipo banner. Alternativamente, el módulo de caché 412 puede optar por recuperar anuncios relacionados con equipo no deportivo para proporcionar más variedad al grupo de caché. Pre-extrayendo el contenido, la recuperación futura de anuncios del caché por el módulo de reproductor 411 se puede facilitar grandemente . Adicionalmente, o alternativamente, el módulo de caché
412 puede recuperar periódicamente contenido de servidores cercanos con base en los cambios en la ubicación del dispositivo móvil, tal como recuperar automáticamente nuevos anuncios de un servidor de contenido más cercano con respecto al dispositivo móvil. Por ejemplo, un usuario en un supermercado puede recibir
anuncios sobre las ediciones especiales semanales en el supermercados en su dispositivo móvil que fueron recuperados por el módulo de caché 412 vía un mecanismo de transporte, por ejemplo, WLAN, de un servidor de publicidad ubicado en el almacén. Los anuncios recuperados se pueden almacenar en el módulo de caché 412 para uso más tarde por el módulo de reproductor 411. Una vez que el módulo de reproductor 411 ha recibido uno o más anuncios de conformidad con los parámetros del módulo de caché 412 o un servidor de anuncios externo, el módulo de reproductor 411 puede exhibir o reproducir el anuncio en la aplicación o de otra forma proporcionar uno o más anuncios a la aplicación solicitante. En uno o más arreglos, el anuncio puede incluir una animación o video clip. En tales arreglos, el anuncio se puede exhibir usando varios dispositivos de hardware incluyendo un visualizador y altavoces del dispositivo. El módulo de reporte 413 monitorea y rastrea el uso del componente de programación estándar personalizada 301 y los módulos de programación estándar personalizada. El módulo de reporte 413 puede recibir o colectar información de uso de otros módulos de programación estándar personalizada 411, 412, 414, 415 y/o 416. La información de uso puede incluir, por ejemplo, cuales anuncios se han proporcionado por el módulo de reproductor 411 a la aplicación solicitante o usuario. La información se puede otorgar en cualquier tiempo deseado, por
ejemplo, periódicamente, cada vez que el contenido sea solicitado, etc., y almacenar en el módulo de caché 412 u otra base de datos. El componente de programación estándar personalizada 301, por ejemplo, vía el módulo de reporte 413, puede exponer una o más APIs para permitir que una aplicación acceda y/o recupera la información de uso de la base de datos o permitir que la aplicación solicite autorización, iniciación y/o detención del monitoreo de uso. Adicionalmente, la información colectada por el módulo de reporte 413 puede ser transmitida adicionalmente a uno o más servidores de anuncios. Con la información colectada, los servidores, por ejemplo, pueden analizar las estadísticas de uso de servicio. El módulo de perfil 414 almacena y maneja la información de perfil de usuario incluyendo comportamiento del usuario e interacciones y preferencias del usuario. Algo o toda la información se puede otorgar desde otro módulo de programación estándar personalizada, por ejemplo, módulo de reporte 413. En un ejemplo, el componente de programación estándar personalizada 301, vía el módulo de perfil 414, puede exponer una o más APIs para permitir que una aplicación y usuario actualicen la información de perfil del usuario o dispositivo, incluyendo preferencias. La información de perfil también se puede transmitir a un servidor, por ejemplo, vía el módulo de reproductor 411, para facilitar la recuperación de los anuncios dirigidos del servidor. Por ejemplo, el módulo de
perfil 414 puede colectar datos relacionados con la frecuencia con la cual el usuario o dispositivo solicita o ve anuncios. El módulo de perfil 414 puede colectar adicionalmente información relacionada con que tipos de anuncios son típicamente vistos y/o solicitados. Usando tales datos, los anuncios relevantes se pueden recuperar de un servidor de anuncios . El módulo de lealtad 415 almacena y maneja información de lealtad del usuario para facilitar proporcionar al usuario con recompensas o incentivos para ciertas interacciones de usuario con anuncios. Algo o toda la información usadas y/o almacenada por el módulo de lealtad 415 se puede otorgar desde otro módulo de programación estándar personalizada (por ejemplo, módulo de reporte 413) o de los anuncios (por ejemplo, recompensas especificadas en los metadatos asociados con el anuncio) . El componente de programación estándar personalizada 301, por ejemplo, vía el módulo de lealtad 415, puede exponer una o más APIs para permitir que las aplicaciones y/o el usuario acceda a la información de lealtad. Adicionalmente, la información de lealtad se puede transmitir al servidor 315 el cual puede posteriormente retransmitir la información a los publicistas apropiados. Por ejemplo, las interacciones de usuario tal como seguir un enlace en un anuncio o hacer una compra con un publicista, puede autorizar al usuario recompensas incluyendo recibir minutos móviles extras, descuentos del publicista, o recompensas de aplicación específica (por ejemplo,
vidas extras en una aplicación de juego de video) . El módulo de pago 416 almacena y maneja la información de pago. Por ejemplo, el módulo de pago 416 puede almacenar y manejar datos de pago para facilitar el pago de honorarios a desarrolladores de aplicación para anuncios proporcionados al usuario vía una o más aplicaciones de un desarrollador creado. Por ejemplo, los desarrolladores pueden ser pagados con base en el número de vistas o visitantes por unidad de tiempo de los anuncios generados, y/o comisión con base en las transacciones de ventas. Algo o toda la información se puede otorgar desde otro módulo de programación estándar personalizada, por ejemplo, módulo de reporte 413. La información adicionalmente se puede transmitir a un servidor de publicidad 315 para facilitar el procesamiento de pago. Cada bloque dentro del componente 301 se puede implementar en software vía instrucciones ejecutables por computadora almacenadas en una memoria, o vía hardware, por ejemplo, como una o más ASICs, o similares. Los módulos funcionales ilustrados en la figura 4 son una posible modalidad, ya que la funcionalidad se puede combinar a través de módulos, o dividir para crear aún más módulos funcionales . Algunos módulos pueden ser opcionales, y se pueden agregar módulos adicionales. El alcance de la invención no se limita a la modalidad ilustrativa de la figura 4. La figura 5 es un diagrama de flujo que ilustra un
método para proporcionar anuncios relevantes a una aplicación de solicitud vía un componente de programación estándar personalizada tal como componente 301 en las figuras 3 y 4. En la etapa 500, una solicitud de registro se puede recibir de una aplicación. Por ejemplo, una aplicación, en la carga o encendido, puede ordenar una función NAD_REGISTER ( ) a registrarse con un componente de programación estándar personalizada conocido. Una aplicación se puede dar cuenta del componente de programación estándar personalizada con base, por ejemplo, en las difusiones amplias de sistema o anuncios del componente de programación estándar personalizada. En la etapa 505, se hace una determinación en cuánto a si el componente de programación estándar personalizada se ha cargado. Si el componente de programación estándar personalizada no se ha cargado, entonces en la etapa 510, el componente de programación estándar personalizada es inicializado y cargado. En uno o más arreglos, el componente de programación estándar personalizada se puede configurar para cargarse automáticamente en el arranque del dispositivo de terminal móvil o alternativamente o adicionalmente , se puede construir en el sistema operativo. Por consiguiente, si el componente de programación estándar personalizada ya está cargado cuando se hace la solicitud de registro por la aplicación, el componente de programación estándar personalizada puede registrar la aplicación en respuesta en la etapa 515.
Por ejemplo, la segunda aplicación de solicitud se puede asignar a un identificador único para diferenciar la segunda aplicación de solicitud de otras aplicaciones, por ejemplo, la primera aplicación mencionada anteriormente. En la etapa 520, el componente de programación estándar personalizada puede recibir una solicitud para uno o más anuncios, incluyendo valores asociados con una lista de parámetros tales como tipo, duración, posición, e intervalo de la aplicación vía una API funcional. Esta solicitud se puede enviar directamente a un módulo de reproductor o alternativamente, a un módulo de manejador el cual dirige la solicitud al módulo de reproductor. En la etapa 525, el componente de programación estándar personalizada o un módulo del mismo busca un caché para uno o más anuncios de conformidad con los parámetros. En la etapa 530, se hace una determinación en cuanto si el caché contiene un anuncio relevante que iguala los parámetros especificados. Si el caché está vacío o no se identifican anuncios ajustados a los parámetros del caché en la etapa 530, el componente de programación estándar personalizada luego puede, en la etapa 540, transmitir una solicitud de uno o más anuncios a un servidor de publicidad vía un mecanismo de transporte tal como HTTP. En la etapa 545, uno o más anuncios son recibidos del servidor de publicidad a través de la capa de transporte y almacenados en el caché. En la etapa 550, los anuncios seleccionados son exhibidos al usuario de acuerdo con, por
ejemplo, los parámetros recibidos en la etapa 520. Alternativamente, si un anuncio relevante está disponible en el caché de la etapa 530, el anuncio relevante es recuperado del caché en la etapa 535 y exhibido en la etapa 550. En la etapa 555, el componente de programación estándar personalizada puede recibir un mensaje de cancelación de registro de la segunda aplicación vía una función NAD_DEREGISTER ( ) si, por ejemplo, la aplicación está siendo cerrada por un usuario. En uno o más arreglos, si el componente de programación estándar personalizada no está siendo usado por otra aplicación, el componente de programación estándar personalizada se puede descargar de la memoria. Donde otras aplicaciones aún están registradas o en comunicación con el componente de programación estándar personalizada, la programación estándar personalizada no se puede descargar. Alternativamente, el componente de programación estándar personalizada puede permanecer residente en la memoria hasta que el dispositivo móvil es apagado. La figura 6 es un diagrama de flujo que ilustra un modelo de negocios para generar ingresos para desarrolladores de aplicaciones móviles que exhiben anuncios vía el componente de programación estándar personalizada. En la etapa 600, un desarrollador implementa la funcionalidad de llamada en su aplicación habilitando la aplicación para interconectarse con un componente de programación estándar personalizada a través de una API funcional estandarizada. Los desarrolladores pueden ser
capaces de acceder al componente de programación estándar personalizada si, por ejemplo, el componente de programación estándar personalizada y API funcional están públicamente disponibles y descargables libres de cargo. En la etapa 601, un desarrollador registra la aplicación con un servidor de publicidad para establecer la información de pago. Por ejemplo, el desarrollador puede aceptar una cuenta en el servidor bajo un programa de pago que paga la comisión basada en las vistas o visitantes por unidad de tiempo totales de anuncios exhibidos en su aplicación. En la etapa 602, la aplicación se comunica con el servidor vía el componente de programación estándar personalizada y envía la información de reporte de usuario tal como vistas y visitantes por unidad de tiempo de usuario de anuncios al servidor. En la etapa 603, se puede aplicar un crédito a la cuenta del desarrollador con cualquier comisión generada de los anuncios exhibidos. En la etapa 604, el desarrollador paga la cantidad adeudada en su cuenta. Una cantidad mínima adeudada se puede requerir antes que se haga el pago. En uno o más arreglos, un nivel de pago también se puede asociar con las funcionalidades o complejidades de las aplicaciones del desarrollador. Por ejemplo, una aplicación con más funciones tales como música y juegos se puede proporcionar a un desembolso mayor que una aplicación que es especializada para exhibir anuncios . Los métodos y características citadas en la presente
se pueden implementar adicionalmente a través de cualquier número de medios legibles por computadora que con capaces de almacenar instrucciones legibles por computadora. Los ejemplos de medios legibles por computadora que se pueden usar incluyen RAM, ROM, EEPROM, memoria flash u otra tecnología de memoria, CD-ROM, DVD u otro almacenamiento de disco óptico, casetes magnéticos, cinta magnética, almacenamiento magnético y similares . El siguiente ejemplo proporciona una implementación ilustrativa de ciertos aspectos de la presente invención. Un desarrollador ha invertido una gran cantidad de tiempo, recursos, y dinero para producir un juego de jugadores múltiples masivo que corre en dispositivos móviles y desea generar ingresos del juego. El desarrollador podrá cargar un precio para comprar el juego o una tasa de suscripción periódica para jugar el juego, pero tales modelos de negocios probablemente podrían no alcanzar una base de usuario tan amplia como un juego distribuido sin cargos. Por consiguiente, el desarrollador puede en su lugar, o adicionalmente como una opción, ofrecer una versión del juego libre de cargos, pero una que es soportada a través de anuncios exhibidos en el juego. El desarrollador podrá implementar tal funcionalidad directamente en el juego, pero hacerlo así podría ser costoso y complejo, ya que el desarrollador tendrá que considerar varias plataformas de software y hardware, formatos de anuncios, especificaciones del
servidor, etc. En su lugar, el desarrollador simplemente puede implementar una función en el juego, por ejemplo, GET_ADVERTISEMENT ( ) , para ordenar al programación estándar personalizada de anuncios exhibir anuncios de acuerdo con cualquiera de los parámetros deseados. Por ejemplo, el juego puede solicitar que los anuncios de tipo cinta de información (TIPO) sean exhibidos en el fondo de la pantalla de juego (POSICION) , para minimizar la obstrucción del juego, mientras que el juego está siendo jugado (DURACION) , con una velocidad de refrescamiento de un minuto para nuevos anuncios (INTERVALO) . Tal ejemplo muestra cuatro parámetros para exhibir el anuncio. El módulo de reproductor de la programación estándar personalizada, en la recepción de la solicitud del juego, selecciona del módulo de caché los anuncios que se ajustan a los parámetros, es decir, tipo de cinta de información. Si el caché está vacio, o no se selecciona contenido ajustado a los parámetros proporcionados, el módulo de caché descarga nuevos anuncios, por ejemplo, vía HTTP, de un servidor de publicidad. La información adicional de otros módulos de programación estándar personalizada se transmite al servidor para segurar que los anuncios descargados son dirigidos al usuario, tal como información de perfil de usuario otorgada del registro de usuario en el juego. Una vez que los anuncios son seleccionados por el módulo de reproductor, ya sea del caché o del servidor, son exhibidos al usuario en el juego de acuerdo
con los otros parámetros solicitados, por ejemplo, fondo de la pantalla. Como tal, el desarrollador registra esta aplicación con el servidor de publicidad y establece una cuenta donde futuras ganancias se pueden acreditar. Asumiendo, por ejemplo, que un anuncio para un reproductor MP3 se exhibe en el juego. El usuario del dispositivo móvil decide seguir el enlace en el anuncio, y enlazando lo que ve , compra el reproductor MP3. El módulo de usuario de perfil rastrea la interacción, por ejemplo vía el módulo de reporte, y actualiza la información de perfil de usuario para reflejar la compra/click-through. Esta información se puede transmitir a un servidor de publicidad por la programación estándar personalizada para recuperar anuncios futuros relacionados con esta compra/click-through, tales como accesorios para reproductores MP3, otros reproductores portátiles, etc. El módulo de lealtad rastre la compra y recompensa al jugador en el juego, tal como dando al jugador algunas monedas del juego, con la cantidad dependiendo del precio de compara, por ejemplo, mayores compras son recompensadas por mayores premios, o el número de visitantes por unidad de tiempo o vistas de anuncios. Adicionalmente, se le puede dar al usuario descuentos futuros en productos comprados del mismo publicista. Finalmente, el módulo de pago rastrea la vista, click-through, y compra generada por este anuncio y transmite la información al servidor de publicidad, el cual
acredita la cuenta del desarrollador para cualquier ingreso generado de la vista y click-through, y honorario por comisión asociado con la compra. Tal implementacion beneficia todas las partes involucradas. Los usuarios pueden jugar el juego gratis y recibir bonos, recompensas, o descuentos para interactuar con los publicistas. Un desarrollador puede capitalizar oportunidades de renovación que de otra forma podrían no ser posibles a través de vías de negocios tradicionales o son prácticamente no factibles dada la complejidad de la implementacion de funcionalidad de publicidad directamente en su juego. Finalmente, los publicistas pueden llegar a una vasta base de consumidores a costo relativamente pequeño y exposición de ganancias amplia de usuarios que interactúan con los anuncios. La presente invención se ha descrito en términos de las modalidades preferidas y ejemplares de la misma. Numerosas otras modalidades, modificaciones y variaciones dentro del alcance y espíritu de las reivindicaciones anexas ocurrirán a personas de experiencia ordinaria en la técnica a partir de una revisión de esta descripción. Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.