MXPA06013664A - Sistema para prioridad de aplicacion basado en el modo de operacion del dispositivo. - Google Patents

Abstract

Sistema para prioridad de aplicacion basado en el modo de operacion del dispositivo. Se proporciona un metodo para asignar un recurso visible en la parre superior en el dispositivo. El metodo incluye recibir peticion de solicitud de asignacion del recurso visible en la parte superior a una aplicacion solicitante, y determinar que el recurso visible de la parte superior esta asignado a una aplicacion poseedora. El metodo tambien incluye asociar informacion de la propietaria con informacion del solicitante para formar una peticion de arbitraje. El metodo tambien incluye arbitrar la peticion de arbitraje para producir una decision de arbitraje que indique que el recurso visible en la parte superior va a ser asignado a la aplicacion solicitante si la informacion de la propietaria indica que la aplicacion poseedora es privilegiada y un identificador que identifica que la aplicacion solicitante esta contenida en una lista de renuncia asociada con la informacion de la propietaria.

Description

SISTEMA PARA PRIORIDAD DE APLICACIÓN BASADO EN EL MODO DE OPERACIÓN DEL DISPOSITIVO CAMPO DE LA INVENCIÓN La presente invención se relaciona, de manera general, con la operación de un dispositivo y de manera más particular, con un sistema para la prioridad de aplicación basado en el modo de operación del dispositivo.

DESCRIPCIÓN DE LA TÉCNICA RELACIONADA Los avances en la tecnología han dado como resultado el desarrollo y despliegue de redes de datos extensas. Esas redes incluyen redes de datos públicas, como la Internet, y redes especializadas, como las redes de telecomunicación inalámbricas. Los usuarios de esas redes tienen la capacidad de tener acceso a una amplia variedad de información y servicios que están disponibles.

Por ejemplo, las propietarias de dispositivos inalámbricos pueden ahora descargar una amplia variedad de aplicaciones para la ejecución en sus dispositivos. La asignación de recursos se ha vuelto cada vez más importante como resultado del incremento en las aplicaciones descargables. Los recursos de los dispositivos incluyen dispositivos de visualización, teclados numéricos, procesadores de sonido, módems, dispositivos de almacenamiento, canales de comunicación y otros tipos de recursos. Debido a que cada dispositivo tiene un número limitado de recursos, la forma en que aquellos recursos son asignados a aplicaciones que compiten determina como opera el dispositivo. Por ejemplo, un teléfono inalámbrico puede estar en una llamada de voz, una llamada de datos, ejecutando una aplicación, o manejando un mensaje SMS, y el dispositivo necesita saber como asignar sus recursos a varias aplicaciones dada una condición de operación particular. Un recurso muy importante para la mayoría de los dispositivos es referido como el recurso "visible en la parte superior" (TVR)- (también algunas veces referido como "alcance poseído"). El recurso visible en la parte superior generalmente comprende la pantalla del dispositivo y el dispositivo de entrada del dispositivo (por ejemplo, el teclado numérico) , lo cual permite aplicaciones para representar al usuario que están en un foco actual del dispositivo. Por ejemplo, una aplicación que sea asignada al recurso visible en la parte superior puede interactuar con el usuario del dispositivo via la pantalla y el teclado numérico. Existe la necesidad de un arbitraje efectivo entre aplicaciones que compitan que se ejecuten en un dispositivo para determinar cual solicitud deberá tener acceso al recurso visible en la parte superior. Por ejemplo, la operación del dispositivo, la cual determina la "experiencia del usuario", es determinada por que aplicaciones son asignadas al recurso visible en la parte superior. En los sistemas actuales, el recurso visible en la parte superior es 'asignado a una aplicación de acuerdo a reglas estáticas. Por ejemplo, en un dispositivo de aparato telefónico, no se le permite a las aplicaciones comenzar cuando esté en progreso una llamada telefónica. Típicamente, el acceso de una aplicación al recurso visible en la parte superior es controlado por reglas de asignación fuertemente codificadas que no toman en cuenta el ambiente dinámico en el cual opera el dispositivo actual. Por lo tanto, lo que se necesita es un sistema de prioridad de aplicación dinámico que opere para determinar que aplicación en el dispositivo es asignada al recurso visible en la parte superior sobre la base del ambiente de operación del dispositivo. El sistema también deberá proporcionar un mecanismo para permitir a terceras partes, como portadores de red, tener una entrada para saber como es asignado el recurso visible en la parte superior del dispositivo, de modo que la experiencia del usuario proporcionada por el dispositivo pueda ser controlada dinámicamente.

SUMARIO En una o más modalidades, el sistema de prioridad de aplicación es proporcionado de modo que opera para asignar dinámicamente el recurso visible en la parte superior de un dispositivo. En una modalidad, se proporciona un método para operar un sistema de prioridad de aplicación para asignar un recurso visible en la parte superior en un dispositivo. El método comprende recibir una petición que solicita la asignación del recurso visible en la parte superior a una aplicación solicitante, y determinar que el recurso visible en la parte superior se asignó a una aplicación poseedora. El método también comprende asociar la información de la propietaria con la información de la solicitante para formar una petición de arbitraje, donde la información de la propietaria comprende información acerca de la aplicación poseedora y la información de la solicitante comprende información acerca de lá aplicación del solicitante. El método también comprende arbitrar la petición de arbitraje para producir la decisión de arbitraje que indique que el recurso visible en la parte superior debe ser asignado a la aplicación solicitante si la información de la propietaria indica que la aplicación poseedora es privilegiada y un identificador que identifique la aplicación solicitante está contenido en una lista de renuncia asociada con la información de la propietaria. El método también comprende asignar el recurso visto en la parte superior sobre la base de la decisión del arbitraje. En una modalidad, el aparato se proporciona para operar un sistema de prioridad de aplicación para asignar dinámicamente un recurso visible en la parte superior en un dispositivo. El aparato comprende el administrador de recursos que opera para asignar el recurso visible en la parte superior a una aplicación poseedora, y recibir una petición para asignar el recurso visible en la parte superior de una aplicación solicitante. El aparato también comprende la lógica de arbitraje que opera para asignar el recurso visible en la parte superior de la aplicación poseedora si la aplicación poseedora es privilegiada y no ha identificado la aplicación solicitante a una lista de renuncia. La lógica de arbitraje también opera para arbitrar la asignación del recurso visible en la parte superior entre la aplicación poseedora y la aplicación solicitante si la aplicación poseedora es privilegiada y ha identificado la aplicación solicitante en la lista de renuncia. La lógica de arbitraje también opera para arbitrar la asignación del recurso visible en la parte superior entre la aplicación poseedora y la aplicación solicitante si la aplicación poseedora no es privilegiada. En una modalidad, el aparato es proporcionado para operar un sistema de prioridad de aplicación para asignar dinámicamente un recurso visible en la parte superior en un dispositivo. El aparato comprende medios para asignar el recurso visible en la parte superior a una aplicación poseedora, y medios para recibir la petición de asignación del recurso visible en la parte superior de una aplicación solicitante. El aparato también comprende medios para asignar el recurso visible en la parte superior de la aplicación poseedora si la aplicación poseedora es privilegiada y no ha identificado la aplicación solicitante en. la lista de renuncia. El aparato también comprende medios para arbitrar la asignación del recurso visible en la parte superior entre la aplicación poseedora y la aplicación solicitante si la aplicación poseedora es privilegiada y ha identificado la aplicación solicitante en la lista de renuncia. El aparato también comprende medios para arbitrar la asignación del recurso visible en la parte superior entre la aplicación poseedora y la aplicación solicitante si la aplicación poseedora no es privilegiada. En una modalidad, se proporcionan medios legibles por computadora que comprenden instrucciones, las cuales cuando son ejecutadas por un procesador en un dispositivo, operan para proporcionar un sistema de prioridad de aplicación para asignar dinámicamente un recurso visible en la parte superior en un dispositivo. Los medios legibles por computadora comprenden instrucciones para asignar el recurso visible en la parte superior a una aplicación poseedora, e instrucciones para recibir una petición de asignación del recurso visible en la parte superior de una aplicación solicitante. Los medios legibles por computadora también comprenden instrucciones para asignar el recurso visible en la parte superior de la aplicación poseedora si la aplicación poseedora es privilegiada y no ha identificado la aplicación solicitante en una lista de renuncia. Los medios legibles por computadora también comprenden instrucciones para arbitrar la asignación del recurso visible en la parte superior entre la aplicación poseedora y la aplicación solicitante si la aplicación poseedora es privilegiada y ha identificado la aplicación solicitante en la lista de renuncia. Los medios legibles por computadora también comprenden instrucciones para arbitrar la asignación del recurso visible en la parte superior entre la aplicación poseedora y la aplicación solicitante si la aplicación poseedora no es privilegiada . Otros aspectos, ventajas y características de la presente invención se volverán ' evidentes después de revisar la Breve Descripción de las Figuras, la Descripción Detallada y las Reivindicaciones expuestas aqui posteriormente.

BREVE DESCRIPCIÓN DE LAS FIGURAS Los aspectos anteriores y las ventajas que confieren las modalidades descritas aqui se volverán más fácilmente evidentes con referencia a la siguiente descripción detallada cuando se tome en conjunto con las Figuras acompañantes donde: La Figura 1 muestra una modalidad de un sistema de prioridad de aplicación dinámico que opera para asignar un recurso visible en la parte superior en un dispositivo; La Figura 2 muestra un diagrama funcional de una modalidad de un sistema de prioridad de aplicación para asignar el recurso visible en la parte superior en un dispositivo, por ejemplo, el dispositivo mostrado en la Figura 1; La Figura 3 muestra una modalidad de un dispositivo que incluye una modalidad de un sistema de prioridad de aplicación; La Figura 4 muestra una modalidad de un método para proporcionar una modalidad de un sistema de prioridad de aplicación para usarse en un dispositivo; La Figura 5 muestra una modalidad de un método para operar un arbitro de recursos para proporcionar una modalidad del sistema de prioridad de aplicación; La Figura 6 muestra una modalidad de una arquitectura de control de recursos adecuada para usarse con una o más modalidades de un sistema de prioridad de aplicación; y La Figura 7 muestra un ejemplo de cómo un recurso visible en la parte- superior en un dispositivo es asignado entre dos aplicaciones de acuerdo con una o más modalidades de un sistema de prioridad de aplicación.

DESCRIPCIÓN DETALLADA La siguiente descripción detallada describe una o más modalidades de un sistema de prioridad de aplicación que opera para asignar dinámicamente al recurso visible de la parte superior en un dispositivo.

En una modalidad, las aplicaciones solicitan asignación del recurso visible en la parte superior transmitiendo una petición de asignación a un administrador de recursos. La petición de asignación es combinada con uno o más parámetros que describen el estado del recurso visible en la parte superior y su propietaria actual para * formar una petición de arbitraje. Un arbitro procesa la petición de arbitraje de acuerdo a las reglas de arbitraje para producir una decisión de arbitraje que indica como van a ser asignados los recursos. La decisión de arbitraje es entonces usada para asignar el recurso visible en la parte superior. El sistema es adecuado para usarse con cualquier tipo de dispositivo alámbrico o inalámbrico, incluyendo, pero sin limitarse a, computadoras de escritorio, computadoras de cuaderno, teléfonos inalámbricos, paginadores, PDAs, dispositivos de correo electrónico, computadoras de mesa, o cualquier otro tipo de dispositivos alámbricos o inalámbricos. En una o más modalidades, los sistemas de prioridad de aplicación interactúan con un ambiente de tiempo de ejecución que se ejecuta en el dispositivo que es usado para simplificar la operación del dispositivo, como proporcionando llamadas generalizadas por recursos específicos del dispositivo. Uno de esos ambientes de tiempo de ejecución es el Ambiente de Tiempo de Ejecución Binario para la plataforma de programas y sistemas de programación o software WirelessMR (BREW®) desarrollada por QUALCOMM, Inc., de San Diego, California. En la siguiente descripción, se asumirá que una modalidad del sistema de prioridad de aplicación es implementada usando un dispositivo inalámbrico que está ejecutando un ambiente de tiempo de ejecución, como la plataforma de programas y sistemas de programación o software BREW. Sin embargo, una o más modalidades del sistema de prioridad de aplicación son adecuadas para usarse con otros tipos de ambientes de tiempo de ejecución para asignar dinámicamente el recurso visible en la parte superior en dispositivos alámbricos e inalámbricos. Además, el término "recurso visible en la parte superior" es usado aqui para describir cualquier tipo de recursos de componentes físicos de computación o hardware y/o programas y sistemas de programación o software en un dispositivo que sea usado para representar el foco actual del dispositivo, usando pero sin limitarse a, la combinación de la pantalla y un teclado numérico del dispositivo . La Figura 1 muestra una modalidad de un sistema de prioridad de aplicación dinámico 100 que opera para asignar un recurso visible en la parte superior en un dispositivo. El sistema 100 comprende una terminal inalámbrica 102 que se comunica con una red de datos 104 via un canal de comunicación inalámbrico 106. La red de datos 104 comprende cualquier tipo de red de datos que puede incluir, pero no se limita a, una red de datos alámbrica, inalámbrica, privada o .pública, o cualquier combinación de las mismas. El sistema 100 también comprende un servidor 108 que está acoplado a la red 104 via un canal de comunicación 110 para proporcionar servicios a dispositivos en comunicación con la red 104. Por ejemplo, la terminal inalámbrica 102 puede ser un teléfono inalámbrico, y el servidor 108 puede ser parte de una red de telecomunicaciones nacional que proporcione servicios de telecomunicación al teléfonp. El canal de comunicación 110 puede ser cualquier tipo de canal de comunicación alámbrico o inalámbrico. El dispositivo 102 incluye las aplicaciones 116 que se ejecutan en un dispositivo para proporcionar características y funciones deseables por el usuario del dispositivo. Por ejemplo, las aplicaciones 116 pueden ser descargadas al dispositivo 102 del servidor 108 como es mostrado por la trayectoria 120. Durante la ejecución, las aplicaciones' 116 intentan obtener acceso al recurso visible en la parte superior 118 del dispositivo 102, el cual en una modalidad comprende una pantalla y un teclado numérico del dispositivo. En una modalidad, las aplicaciones 116 tienen cada una, uno o más grupos de ID que indican los derechos y privilegios de una aplicación. Por ejemplo, un ID de grupo identifica si una aplicación es Privilegiada (P) o no Privilegiada (nP) con respecto al recurso visible en la parte superior. En una modalidad, ambas aplicaciones privilegiadas y no privilegiadas pueden tener acceso al recurso visible en la parte superior, sin embargo, a las aplicaciones privilegiadas se les permite especificar las aplicaciones o grupos seleccionados para los cuales el control del recurso visible en la parte superior será liberado. En una modalidad, el dispositivo 102 comprende un arbitro 112 y reglas de arbitraje 114. Por ejemplo, el arbitro 112 y las reglas de arbitraje 114 pueden ser descargadas al dispositivo 102 del servidor 108, como lo muestra la trayectoria 120. El arbitro 112 opera o arbitra las peticiones del recurso visible en la parte superior 118 de aplicaciones competentes que se ejecuten en el dispositivo 102. El arbitro 112 decide las peticiones de arbitraje sobre la base de la información acerca de la aplicación solicitante y la aplicación poseedora del recurso. En una modalidad, el estado de privilegio de la aplicación poseedora y las reglas de arbitraje 114 son usados para producir una decisión de arbitraje que indique como asignar el recurso visible en la parte superior 118 a las aplicaciones que compiten. De este modo, asociando un estado de privilegio particular con una aplicación seleccionada y descargando un conjunto particular de reglas de arbitraje 114 del servidor 108 al dispositivo 102, es posible que el servidor 108 controle como es asignado al recurso visible en la parte superior 118 en el dispositivo a las aplicaciones 116. Esto permite al servidor 108 controlar la experiencia del usuario proporcionada -por el dispositivo 102. En una o más modalidades, el servidor 108 y la terminal 102 pueden ser cualquier tipo de dispositivos y sus conexiones asociadas a la red de datos 104 pueden ser inalámbricas, alámbricas, o cualquier combinación de las mismas. De este modo, las modalidades del sistema de prioridad de aplicación dinámico operan para permitir a un servidor controlar como es asignado el recurso de la parte superior en un dispositivo usando virtualmente cualquier configuración de red que tenga una variedad de servidores y terminales. La Figura 2 muestra un diagrama funcional de una modalidad de un sistema de prioridad de aplicación 200 para asignar el recurso visible en la parte superior en un dispositivo, por ejemplo, el dispositivo 102 mostrado en la Figura 1. El sistema 200 comprende un administrador del recurso visible en la parte superior 202, el estado del recurso visible en la parte superior 204, un arbitro de recursos 206, y reglas de arbitraje 208. También se muestran el recurso visible en la parte superior 210 del dispositivo y las aplicaciones (1-4) que se ejecutan en el dispositivo, las cuales se muestran de manera general en 212. El administrador del recurso visible en la parte superior 202 comprende la lógica de componentes físicos de computación o hardware, la lógica de programas y sistemas de programación o software, o cualquier combinación de las mismas, y opera para administrar el recurso visible en la parte superior 210. El recurso visible en la parte superior 210 puede comprender cualquier tipo de recurso del dispositivo, como una pantalla y un teclado numérico, los cuales son usados para representar a un usuario cual aplicación tiene el foco del dispositivo. Por ejemplo, la aplicación que tiene el foco del dispositivo es la aplicación que está interactuando actualmente con el usuario. El estado del recurso visible en la parte superior 204 comprende componentes físicos de computación o hardware, o programas y sistemas de programación o software o cualquier combinación de los mismos. En una modalidad, el estado del recurso visible en la parte superior 204 comprende información acerca del recurso visible en la parte superior 210 y/o información acerca de la propietaria del recurso actual (información de la propietaria). Por ejemplo, una aplicación que esté asignada actualmente al recurso visible en la parte superior 210 se considera la propietaria del recurso, la propietaria actual, o la aplicación poseedora. Por ejemplo, en una modalidad, el estado de recurso visible en la parte superior 204 comprende información acerca de la propietaria actual que comprende un identificador de propietaria actual (ID), uno o más ID de grupo, estado de privilegio, razón para adquirir el recurso, una lista de renuncia, y/o cualquier otra información acerca de la propietaria actual o del recurso visible en la parte superior 210. En una modalidad, la lista de renuncia identifica que aplicaciones o grupos (por ejemplo, clases de privilegios) la propietaria actual desea liberar al recurso visible en la parte superior 210. En una modalidad, esta lista es controlada durante el proceso de arbitraje conducido por el arbitro de recursos 206. En otra modalidad, esta lista de renuncia es considerada únicamente una recomendación al arbitro de recursos 206 de cómo deberán decidirse los arbitrajes. El administrador del recurso visible en la parte superior 210 opera para mantener, actualizar, cambiar, agregar, suprimir, o procesar de otro modo la información que esté comprendida en el estado del recurso 204. El arbitro del recurso 206 comprende componentes físicos de computación o hardware, programas y sistemas de programación o software o cualquier combinación de los mismos, y operar para arbitrar el acceso al recurso visible en la parte superior 210 usando las reglas de arbitraje 208. Por ejemplo, en una modalidad, el arbitro del recurso 206 puede ser un módulo de programa y las reglas de arbitraje 208 pueden ser parámetros almacenados en una memoria que sean recuperados por el arbitro de recurso 206 y procesados para asignar dinámicamente el recurso visible a la parte superior 210. En una o más modalidades, el administrador del recurso visible en la parte superior 202 y el arbitro de recursos 206 pueden ser implementados como extensiones descargables al ambiente de tiempo de ejecución que se ejecute en el dispositivo; por ejemplo, ellos pueden ser extensiones BREW descargables. Durante la operación de una modalidad del sistema de prioridad de aplicación dinámico 200, una aplicación presenta una petición de asignación al administrador del recurso visible en la parte superior 202 para tener acceso al recurso visible en la parte superior 210. Si el recurso visible en la parte superior 210 está disponible, el administrador del recurso visible en la parte superior 202 asigna el recurso visible en la parte superior 210 a la aplicación solicitante. Si el recurso visible en la parte superior 210 es poseído actualmente por otra aplicación, el administrador del recurso visible en la parte superior 202 responde montando una petición de arbitraje que comprende información acerca de la aplicación solicitante (información de la solicitante) e información acerca de la propietaria actual del recurso (información de la propietaria) . La información acerca de la aplicación solicitante es derivada de la petición de asignación, y la información acerca de la propietaria actual del recurso es derivada del estado del recurso visible en la parte superior 204. La petición de arbitraje es enviada al arbitro del recurso 206, como se muestra en 214. El arbitro del recurso 206 procesa la petición de arbitraje usando las reglas de arbitraje 208 para producir una decisión de arbitraje que es enviada de regreso al administrador del recurso visible de la parte superior 202, como se muestra en 216. El administrador del recurso visible en la parte superior 202 opera entonces para asignar el recurso visible en la parte superior 210 a la aplicación apropiada de acuerdo a la decisión del arbitraje. En una modalidad, las aplicaciones 212 tienen un ID de grupo que determina si una aplicación particular es privilegiada con respecto al recurso visible en la parte superior 210. Por ejemplo, un ID de grupo está asociado con el conjunto de derechos que se aplican a todas las aplicaciones que tienen ese ID de grupo. Uno de los derechos define el estado de privilegio de la aplicación con respecto a los recursos visibles en la parte superior 210. Cuando una primera aplicación obtiene acceso al recurso visible en la parte superior 210, proporciona información al administrador del recurso visible en la parte superior 202 (via la petición de asignación) que incluye su ID de aplicación, uno o más ID de grupo, y una razón para desear tener acceso al recurso visible en la parte superior 210. En una modalidad el ID de grupo no pasó debido a que puede estar inferido del ID de la aplicación. En una modalidad, la razón para desear tener acceso al recurso visible en la parte superior 210 es seleccionada de varios tipos enumerados. Sin embargo, el conjunto de razones no se limita a una lista numerada, sino que también puede ser asociada con un ID de grupo u otras razones del cliente. Si la aplicación es privilegiada, de acuerdo a lo determinado de su ID de grupo, esto puede restringir que aplicaciones pueden tomar el recurso visible en la parte superior 210. Por ejemplo, la aplicación puede especificar una lista de renuncia que identifique aplicaciones para las cuales será liberado el recurso visible en la parte superior 210. Por ejemplo, las aplicaciones en la lista de renuncia pueden ser identificadas por uno o más de sus ID de grupo. Cuando otra aplicación solicite acceso al recurso visible en la parte superior 210, el administrador del recurso visible en la parte superior 202 genera una petición de arbitraje que incluye información acerca de la propietaria del recurso actual (información de la propietaria) e información acerca de la aplicación solicitante (información de la solicitante) . Como parte de la petición de arbitraje, el estado de privilegio de la propietaria y el solicitante del recurso visible de la parte superior 210 son pasados al arbitro de recursos 206 junto con sus razones asociadas para esperar el recurso visible en la parte superior 210 y cualquier lista de renuncia. La información pasada al arbitro del recurso 206 puede comprender también cualesquier otros parámetros o criterios. Por ejemplo, la información pasada al arbitro del recurso 206 puede incluir preferencias del usuario, modo de operación del dispositivo actual, preferencias del portador, o cualquier otro tipo de información que pueda ser usado para arbitrar la petición. El arbitro del recurso 206 usa entonces esta información para determinar como se asignará el recurso visible en la parte superior 210. En una modalidad, la propietaria del recurso visible en la parte superior actual 210 puede cambiar dinámicamente su prioridad de aplicación con respecto al recurso visible en la parte superior 210. Por ejemplo, después del acceso inicial al recurso visible en la parte superior 210, donde otras aplicaciones pueden tener acceso restringido, la aplicación puede cambiar su lista de renuncia y por lo tanto permitir que otras aplicaciones obtengan acceso al recurso visible en la parte superior 210. De este modo, el sistema opera para proporcionar flexibilidad permitiendo a la aplicación que posee el recurso visible en la parte superior 210 liberar el recurso visible en la parte superior 210, o facilitar el acceso al recurso visible en la parte superior 210 para otras aplicaciones. En otra modalidad, el sistema proporciona un mecanismo de consulta que permite a una aplicación registrar una función de consulta. La función de consulta permite que el sistema notifique a la aplicación cuando existe cambio de estado del recurso visible en la parte superior 210. Por ejemplo, la función de consulta puede ser usada para notificar a una aplicación cuando el recurso visible en la parte superior 210 está libre, o cuando el recurso visible en la parte superior 210 está ocupado debido a que se asignó a otra aplicación. De este modo, el sistema 200 opera para proporcionar un sistema de prioridad de aplicación dinámica para asignar acceso al recurso visible en la parte superior 210 de un dispositivo a una aplicación particular. Para un mejor ajuste a los ambientes de operación cambiantes, el arbitro del recurso 206 y las reglas de arbitraje 208 pueden ser descargadas al dispositivo de una entidad de una red, permitiendo por lo tanto una tercera parte tener acceso a como es asignado el recurso visible en la parte superior 210 en el dispositivo. Por ejemplo, en una modalidad, el dispositivo es un teléfono inalámbrico y el arbitro del recurso 206 y las reglas de arbitraje 208 son descargadas al dispositivo desde un servidor de red que sea parte de una red portadora de telecomunicaciones nacional. De esta manera, al portador de telecomunicación se le proporciona acceso a como es asignado el recurso visible en la parte superior 210 entre aplicaciones en el dispositivo, y por lo tanto es capaz de controlar la experiencia del usuario proporcionada por el dispositivo. La Figura 3 muestra una modalidad de un dispositivo 300 que incluye una modalidad de un sistema de prioridad de aplicación. El dispositivo 300 comprende la lógica de procesamiento 302, la memoria 304, la lógica de visualización 306, la lógica de teclado numérico 308, y la interfaz o interconexión de I/O 310 todas acopladas a un canal de datos interno 312. Para propósitos de claridad, se asumirá que un recurso visible en la parte superior 332 en el dispositivo 300 comprende la lógica de visualización 306 y la lógica del teclado numérico 308.

Deberá notarse que una o más modalidades del sistema de prioridad de aplicación son adecuadas para usarse con otros dispositivos que tengan configuraciones diferentes, y que es posible definir el recurso visible en la parte superior 332 usando diferentes elementos funcionales. La lógica de procesamiento 302 comprende una CPU, un procesador, un arreglo de compuertas, una lógica discreta u otros componentes físicos de computación o hardware o programas y sistemas de programación o software, o cualquier combinación de los mismos. De este modo, la lógica de procesamiento 302 generalmente comprende la lógica para ejecutar instrucciones legibles por una máquina para efectuar las funciones descritas aqui. Por ejemplo, las instrucciones pueden ser cargadas en el dispositivo 300 desde medios legibles por computadora, como un disco flexible, CDROM, memoria instantánea, u otro medio legible por computadora que se interconecte con el dispositivo 300 via la interfaz o interconexión 310. En otra modalidad las instrucciones 310 pueden ser descargadas al dispositivo 300 desde un recurso de red, como un servidor de red o cualquier otro tipo de recurso de red via una interfaz o interconexión 310. Las instrucciones, cuando son ejecutadas por la lógica de procesamiento 302 proporcionan una o más modalidades de un sistema de prioridad de aplicación como se describe aqui. La memoria 304 comprende cualquier tipo de RAM, ROM, disco duro, disco flexible, memoria instantánea, o cualquier otro tipo de dispositivo de memoria. La lógica de visualización 306 comprende la lógica para controlar el dispositivo de visualización, como CRT, LCD en cualquier otro tipo de dispositivo de visualización. La lógica del teclado numérico 308 comprende la lógica para controlar un dispositivo de entrada de usuario, como un teclado numérico, pluma, palanca de tubo o cualquier otro tipo de dispositivo de entrada, para recibir la entrada del usuario. La interfaz o interconexión de I/O 310 comprende componentes físicos de computación o hardware y/o programas y sistemas de programación o software o cualquier combinación de los mismos para permitir al dispositivo 300 interconectarse con dispositivos o sistemas externos. Por ejemplo, la interfaz de I/O 310 comprende la lógica para interconectarse al sistema de almacenamiento externos, como unidades de disco u otros dispositivos de memoria. La interfaz o interconexión 310 también comprende la lógica para interconectarse con un sistema externo, como un sistema de computadora local. Además, la interfaz también comprende la lógica para interconectarse con la red de datos que permite la comunicación con computadoras y servidores remotos.

Durante la operación del dispositivo, las instrucciones de programa ejecutadas por la lógica de procesamiento 302 activan un ambiente de tiempo de ejecución 314. Por ejemplo, el ambiente de tiempo de ejecución puede ser el ambiente de tiempo de ejecución BREW. Las instrucciones del programa ejecutadas por la lógica de procesamiento 302 también activan un administrador del recurso visible en la parte superior 318. El administrador del recurso visible en la parte superior 318 opera para controlar el acceso al recurso visible en la parte superior 332 para permitir que las aplicaciones controlen los recursos de visualización 306 y los recursos del teclado numérico 308. De este modo, el administrador del recurso visible en la parte superior 318 opera para controlar el acceso al recurso visible en la parte superior 332 (la pantalla 306 y el teclado numérico 308) para permitir que las aplicaciones interactúen con el usuario del dispositivo. El administrador del recurso visible en la parte superior 318 recibe la petición para tener acceso al recurso visible en la parte superior 332 de las aplicaciones (320, 322, 324, 326) que se ejecutan en el dispositivo 300. Las aplicaciones (320, 322, 324, 326) pueden ser cualquier tipo de aplicaciones adecuadas para ejecutarse en el dispositivo 300. Por ejemplo, las aplicaciones pueden ser aplicaciones de multimedios, aplicaciones de calendario, aplicaciones de correo electrónico, aplicaciones de procesamiento de voz, o cualquier otro tipo de aplicaciones que cuando se ejecuten en el dispositivo 300 proporcionen características y/o funciones útiles. Para facilitar la asignación del recurso visible en la parte superior 332, el administrador del recurso visible en la parte superior 318 mantiene el estado del recurso visible en la parte superior 328 en la memoria 304. El estado del dispositivo 334 identifica un modo de operación actual del dispositivo, por ejemplo, el modo de operación del dispositivo puede estar libre, ejecutando una aplicación, recibiendo un mensaje, procesando una llamada de voz, jugando un juego, o estar en cualquier otro tipo de modo de operación del dispositivo. Cuando las aplicaciones (320, 322, 324, 326) se ejecutan en el dispositivo 300, ellas presentan peticiones del administrador del recurso visible en la parte superior 318 para tener acceso al recurso visible en la parte superior 332. En el caso donde el recurso visible en la parte superior 332 no está actualmente asignado, el recurso visible en la parte superior 332 puede ser asignado fácilmente a una aplicación solicitante. Sin embargo, si el recurso visible en la parte superior 332 está actualmente asignado a una aplicación, cualquier petición de acceso al recurso visible en la parte superior 332 de otra aplicación necesita ser arbitrado para determinar a cual aplicación se asignará el recurso visible en la parte superior 332. En una o más modalidades, el sistema de prioridad de aplicación opera para arbitrar la asignación del recurso visible en la parte superior 332 a una de las aplicaciones que se ejecuten en el dispositivo. Por ejemplo, si el recurso visible en la parte superior 332 está actualmente asignado a una aplicación, el administrador del recurso visible en la parte superior 318 presenta una petición de arbitraje al arbitro del recurso 316. La petición incluye información acerca de la aplicación solicitante (información de las solicitantes) e información acerca de la propietaria actual (información de la propietaria) del recurso visible en la parte superior 332. Por ejemplo, si la información acerca de la propietaria actual del recurso visible en la parte superior 332 es mantenida en el estado del recurso visible en la parte superior 328. En una modalidad, el arbitro del recurso 316 procesa la petición de arbitraje de acuerdo a reglas de arbitraje 330 almacenadas en la memoria 304. Por ejemplo, en una modalidad, las reglas de arbitraje 330 son descargadas al dispositivo 300 de un servidor de red, de modo que el servidor de red puede proporcionar acceso a como son arbitradas las peticiones de recurso en el dispositivo 300. La petición de arbitraje es procesada por el arbitro del recurso 316 para producir una decisión de arbitraje que es regresada al administrador del recurso visible en la parte superior 318. El administrador del recurso visible en la parte superior 318 asigna entonces el recurso sobre la base de la decisión de arbitraje. Deberá notarse que la descripción del sistema de prioridad de aplicación mostrado en el dispositivo 300 ilustra solo una modalidad, y que son posibles otras configuraciones para proporcionar las funciones descritas aqui. Por ejemplo, es posible que los elementos funcionales del dispositivo 300 sean combinados, rearreglados, cambiados, agregados a o suprimidos dentro del alcance de las modalidades descritas.

Arbitro del Recurso En una o más modalidades, el arbitro del recurso 316 opera como el que toma las decisiones centrales para determinar si el recurso visible en la parte superior 332 puede ser traspasado a una aplicación (u objeto) solicitante. En una modalidad, el arbitro del recurso 316 es instalado sobre el dispositivo durante la fabricación. En otra modalidad, el arbitro del recurso 316 es adaptable por un servidor de red y es implementado como un módulo descargable que. puede ser actualizado o reemplazado cuando se desee. Por ejemplo, en una implementación donde el dispositivo es un teléfono inalámbrico, el arbitro del recurso 316 puede ser adaptado y descargado al teléfono desde un servidor de red operado por un OEM/portador de comunicaciones. Preferiblemente, se usa un solo arbitro del recurso 316 para arbitrar las peticiones del recurso visible en la parte superior 332 en un dispositivo. En una modalidad, al arbitro del recurso 316 se pasa una variedad de información del administrador del recurso visible en la parte superior 318, y esa información es usada para producir una decisión de arbitraje. En una modalidad, la información que es pasada al arbitro del recurso 316 comprende información acerca de la aplicación solicitante (información de la solicitante) e información acerca de la propietaria actual del recurso visible en la parte superior 332 (información de la propietaria) . Sin embargo, en otras modalidades, se pasan tipos adicionales de información al arbitro del recurso 316 y esta información adicional comprende información del estado del dispositivo 334, información de preferencia del usuario, información de preferencias de terceras partes, y cualquier otro tipo de información adecuado para ser usado por el arbitro del recurso para producir una decisión de arbitraje. Adicionalmente, en una modalidad, el arbitro del recurso 316 es extensible, de modo que el proceso de arbitraje pueda ser modificado para usar diferentes elementos de información durante diferentes periodos de tiempo o condiciones de operación para tomar una decisión de arbitraje. Lo siguiente representa una breve descripción de la información de la solicitante y la propietaria que puede ser pasada al arbitro del recurso 316 para producir una decisión de arbitraje, sin embargo, la información que puede ser pasada al arbitro del recurso no se limita a la lista mostrada. A. Información de la Propietaria del Recurso 1. Identificador de la clase de propietaria (CLSID) e indicador del paso 2. Razón para la adquisición de TVR 3. Información de control de renuncia a. Lista de los Identificadores de Renuncia b. Conteo de la Lista (-1= todo, 0= ninguno, otro conteo) B. Información de la Solicitante 1. Identificador de la clase de la solicitante (CLSID) e indicador del paso 2. Razón para la adquisición de TVR 3. Información de control de renuncia a. Lista de los Identificadores de Renuncia b. Conteo de la Lista (-1= todo, 0= ninguno, otro conteo) La FIGURA 4 muestra una .modalidad de un método 400 para proporcionar una modalidad de un sistema de prioridad de aplicación para usarse en un dispositivo. Para propósitos de claridad, la operación del método 400 será descrita con referencia al dispositivo 300 mostrado en la FIGURA 3. Por ejemplo, el método 400 muestra como en una modalidad, el recurso visible en la parte superior 332 (la pantalla 306 y el teclado 308) es asignado dinámicamente a una de las aplicaciones 320 322, 324 y 326. En el bloque 402, una primera aplicación envia una petición de asignación de recurso al administrador del recurso visible en la parte superior 318, asociado con el recurso visible en la parte superior 332. Por ejemplo, la aplicación 320 envia una petición de asignación de recurso al administrador del recurso visible en la parte superior 318 para solicitar la asignación del recurso visible en la parte superior 332. La petición de asignación incluye información acerca de la aplicación 320; por ejemplo, la petición de asignación incluye información de la solicitante como se describió anteriormente. En el bloque 404, el administrador del recurso visible en la parte superior 318 .asigna el recurso visible en la parte superior 332 a la primera aplicación. Por ejemplo, el administrador de recurso visible en la parte superior 318 asigna el recurso visible en la parte superior a la aplicación 320. Adicionalmente, el administrador de recurso visible en la parte superior 318 usa la información de la solicitante proporcionada en la petición de asignación para actualizar la información de la propietaria descrita anteriormente. La información de la propietaria del recurso es entonces almacenada en el estado del recurso visible en la parte superior 328. En el bloque 406, una segunda aplicación envia una petición de asignación de recurso al administrador del recurso visible en la parte superior 318 asociada con el recurso visible en la parte superior 332. Por ejemplo, la aplicación 322 envia una petición de asignación de recurso al administrador del recurso visible en la parte superior 318 para solicitar la asignación del recurso visible en la parte superior 332. La petición de asignación incluye información acerca de la aplicación 322; por ejemplo, la petición de asignación incluye información de la solicitante como se describió anteriormente.

En el bloque 408, un administrador del recurso visible en la parte superior 318 envia una petición de arbitraje al arbitro del recurso 316. Por ejemplo, el administrador del recurso visible en la parte superior 318 envia una petición de arbitraje al arbitro del recurso 316. La petición de arbi'traje incluye información de la propietaria del recurso del estado del recurso visible en la parte superior 318 e información de la solicitante de la petición de asignación. De este modo, la petición de arbitraje proporciona al arbitro del recurso 316 con información acerca de la propietaria actual y la solicitante actual del recurso visible en la parte superior 332. En el bloque 410, el arbitro del recurso 316 genera una decisión de arbitraje que indica a cual aplicación se le asignará el recurso visible en la parte superior 332. Por ejemplo, el arbitro del recurso 316 genera la decisión de arbitraje y transmite la decisión del administrador del recurso visible de la parte superior 318. El arbitro del recurso 316 genera la decisión de arbitraje sobre la base de las reglas de arbitraje 330 almacenados en la memoria 304. En una modalidad, el arbitro del recurso 316 y las reglas de arbitraje 330 son descargadas de una tercera parte, como un OEM/portador, que permite actualizar y también proporciona un mecanismo para que la tercera parte decida como asignar el recurso visible en la parte superior 332 en el dispositivo. Una descripción más detallada de cómo el arbitro del recurso 316 genera la decisión de arbitraje que es proporcionada en otra sección de este documento . En el bloque 412, el administrador del recurso visible en la parte superior 318 asigna el recurso visible en la parte superior 332 sobre la base de la decisión de arbitraje. Por ejemplo, el administrador del recurso visible en la parte superior 318 asigna el recurso visible en la parte superior 332 a cualquiera de la primera aplicación 320 de la segunda aplicación 322 sobre la base de la decisión del arbitraje. El administrador del recurso visible en la parte superior 318 también actualiza el estado del recurso visible en la parte superior 318 con cualquier información nueva de la propietaria del recurso. De este modo, el método 400 opera para proporcionar una modalidad de un sistema de prioridad de aplicación dinámico para usarse en un dispositivo. Deberá notarse que el método 400 ilustra solo una modalidad y que es posible rearreglar, cambiar, combinar, agregar, o suprimir pasos del método dentro del alcance de las modalidades descritas. Por ejemplo, es posible para una aplicación registrar una función de consulta con el administrador del recurso- visible -en la parte superior 318, de modo que el estado y/o disponibilidad del recurso visible en la parte superior 322 pueda ser proporcionada a la aplicación cuando lo desee. De este modo, es posible que se proporcionen funciones auxiliares adicionales por el sistema de prioridad de aplicación y que esas funciones auxiliares estén dentro del alcance de las modalidades descritas. La FIGURA 5 muestra una modalidad de un método 500 para operar un arbitro del recurso para proporcionar una modalidad de un sistema de prioridad de aplicación. Para propósitos de claridad, la operación de método 500 será descrita con referencia al dispositivo 300 mostrado en la FIGURA 3. De este modo, en una modalidad, el método 500 es implementado por el arbitro del recurso 316 mostrado en la FIGURA 3. En el bloque 502, se recibe una petición de arbitraje en el arbitro del recurso 316. Por ejemplo, el administrador del recurso visible en la parte superior 318 presenta la petición de arbitraje al arbitro del recurso 316. La petición de arbitraje comprende información acerca de la propietaria actual (información de la propietaria) del recurso visible en la parte superior 332, e información acerca de la aplicación solicitante (información de la solicitante) para tener acceso al recurso visible en la parte superior 332. En el bloque 504, se efectúa una prueba sobre la lista de renuncia proporcionada por la propietaria actual del recurso visible en la parte superior 332 para determinar a cuales aplicaciones a la propietaria actual relegará el control del recurso visible en la parte superior 332. La lista de renuncias es parte de la información de la propietaria actual proporcionada en la petición de arbitraje. Si la lista de renuncia especifica que cualquier aplicación puede obtener el recurso visible en la parte superior 332, el método precede al bloque 510. Si la lista de renuncia especifica que ninguna aplicación o solo algunas aplicaciones especificas pueden obtener el control del recurso visible en la parte superior 332, el método procede al bloque 506. En el bloque 506, se efectúa una prueba para determinar si la aplicación solicitante es una de las aplicaciones identificadas en la lista de renuncia. Por ejemplo, la lista de renuncia especifica los ID de grupo o ID de aplicación que pueden ser usados para identificar aplicaciones seleccionadas. Si el identificador de la aplicación solicitante está especificado en la lista de renuncia, el método procede al bloque 510. Si el identificador de la aplicación solicitante no está especificado en la lista de renuncia, el método procede al bloque 508. En el bloque 508, se toma la decisión de arbitraje para mantener la propietaria actual del recurso visible en la parte superior 332. Debido a que la propietaria actual es privilegiada y la aplicación solicitante no está en la lista : de renuncia, la petición de asignación del recurso visible en la parte superior 332 por la aplicación solicitante es negada. El método procede entonces al bloque ,512 donde la decisión de arbitraje es regresada al administrador del recurso visible en la parte superior 318. En el bloque 510, la petición de arbitraje de la petición solicitante es arbitrada sobre la base de criterios seleccionados. Por ejemplo, en una modalidad, la petición es arbitrada sobre la -base de las reglas de arbitraje 330. Virtualmente puede ser usado cualquier criterio para determinar cual aplicación se le asignará al recurso visible en la parte superior 332. Por ejemplo, el arbitraje puede basarse en la razón por la que cada aplicación desea el recurso visible en la parte superior 332, el modo de operación del dispositivo, las preferencias del usuario, las diferencias del portador, (tercera parte), o cualquier otro .criterio.

Ejemplo de Implementación Lo siguiente describe un ejemplo de implementación de una modalidad de un sistema de prioridad de aplicación que opera para asignar un recurso visible en la parte superior en el dispositivo. En una modalidad, el sistema comprende un administrador del recurso visible en la parte superior que proporciona medios para que las aplicaciones (objetos), incluyendo las aplicaciones BREW, controlen el acceso al recurso. El administrador del recurso visible -en la parte superior también coordina y administra la adquisición y liberación del recurso visible en la parte superior por objetos y también opera para notificar los objetos registrados cuando el estado del recurso visible en la parte superior cambie. En una modalidad, un OEM o portador implementa un conjunto de reglas de arbitraje que son usadas para determinar si la aplicación actual puede ser suspendida o colocada en un modo de fo'ndo o para comenzar una nueva aplicación, dado el estado actual -del dispositivo. Por ejemplo, si el dispositivo es un teléfono inalámbrico que está en una llamada de voz, el OEM puede definir las reglas de arbitraje de modo que se evite que otra aplicación tenga acceso al recurso visible en la parte superior y por lo tanto interrumpa la llamada. La FIGURA 6 muestra una modalidad de una arquitectura de control de recursos 600 adecuada para usarse en una o más modalidades de un sistema de prioridad de aplicación. Por cada Recurso Visible en la parte Superior 602 que sea administrado, existe una Interfaz o Interconexión del Recurso 604 que controla el objeto, una Interfaz o Interconexión de IResourceCtl 606 para controlar el acceso, y un Administrador del Recurso Visible en la Parte Superior 608. Adicionalmente, se proporciona un Arbitro del Recurso 610 para arbitrar el acceso al Recurso Visible en la Parte Superior 602. Cuando es creado un caso de la Interfaz o Interconexión del Recurso 604, este incluye, el caso de IResourceCtl 612. El caso IResourceCtl 612 interactúa con el Administrador de Recurso Visible en la parte Superior 608 para adquirir y liberar el Recurso Visible en la parte Superior Subyacente 602. Deberá notarse que aún si la aplicación tiene el control del Recurso Visible en la Parte Superior 602, otra aplicación podria tomar el control del mismo Recurso Visible en la Parte Superior 602 en cualquier momento sobre la base de las reglas de arbitraje existentes. La FIGURA 7 muestra un diagrama 700 que ilustra un ejemplo de asignación que describe como el recurso visible en la parte superior en el dispositivo es asignado entre dos aplicaciones de acuerdo con una o más modalidades de un sistema de arbitraje dinámico. Por ejemplo, el diagrama 700 muestra la interacción entre varias entidades del dispositivo que comprenden un Arbitro del Recurso 702, el Administrador del Recurso Visible en la Parte Superior 704, la Aplicación A 706, el Caso del Recurso A 708, y la Aplicación B 712 y el Caso del Recurso B 714. Al inicio del ejemplo de asignación, la Aplicación A 706 hace una petición de recurso 714 al Caso de Recurso A 708 para tener acceso a un recurso del dispositivo visible en la parte superior administrado por el Administrador del Recurso Visible en la Parte Superior 704. La petición del recurso es enviada del Caso del Recurso A 708 al Administrador del Recurso Visible en la parte Superior 704, como se muestra en 716. Se asumirá que en este punto en el tiempo el recurso visible en la parte superior no ésta asignado, de modo que el Administrador del Recurso Visible en la parte Superior 704 asigna el recurso visible en la parte superior a la Aplicación A 706 y elige un indicador de "éxito" que fluye nuevamente hacia la Aplicación A 708, lo cual se muestra en 718 y 720. En éste punto, el recurso visible en la parte superior ha sido adquirido por la Aplicación A 708. Adicionalmente, la aplicación A 706 registra una función de consulta con el Caso del Recurso A 708 para recibir información acerca de cualesquier cambio de estado con respecto al recurso visible en la parte superior, como se muestra en 722. Posteriormente, la Aplicación B 710 hace una petición de recurso 724 al Caso del Recurso B 712 para adquirir el recurso visible en la parte superior administrado por el Administrador del Recurso Visible en la parte Superior 704. La petición de recurso en enviada del Caso del Recurso B 712 al Administrador del Recurso Visible en la parte Superior 704, como se muestra en 726. La petición de la Aplicación B 710 hace que el Administrador del Recurso Visible en la parte Superior 704 solicite el arbitraje del Arbitro del Recurso 702, como se muestra en 728. El Arbitro del Recurso 702 procesa la petición de arbitraje 730 de acuerdo con las modalidades descritas aqui. El Arbitro del Recurso 702 proporciona el resultado del arbitraje que indica que el recurso visible en la parte superior fue asignado exitosamente a la Aplicación B 710, como es mostrado por 730, 732, y 734. Por lo tanto, en este punto, la Aplicación B 710 ha adquirido el recurso visible en la parte superior. Debido a que la Aplicación A 706 registró notificaciones al cambio de estado (en 722), la Aplicación A 706 es alertada via una función de consulta 736, debido a que el estado del recurso visible en la parte superior ha cambiado. De este modo, en respuesta a la consulta, la Aplicación A 706 expide una orden de "obtener estado" 738 que regresa una notificación de que el recurso visible en la parte superior ha sido asignado a otra aplicación y ahora está ocupado.

Adaptación del Arbitro del Recurso El arbitro del recurso es el que toma la decisión central que determina si el recurso visible en la parte superior puede ser manejado sobre el objeto solicitante. El modelo del arbitro del recurso es adaptable por el OEM/Portador y puede ser implementado como un módulo descargable usando un identificador de clase (CLSID) . En una modalidad, existe una sola implementación de arbitro de recurso (IResArbiter) para el recurso visible en la parte superior. En una modalidad, el método del arbitro del recurso, IResArbiter_ConfirmAcquire, es pasado a la información de la propietaria del Recurso y la información de- petición como se describió anteriormente para producir la decisión de arbitraje. Si la propietaria actual ha especificado la lista CLSID de renuncia, y la solicitante está identificada en la lista de ID de aplicación o ID de grupo especificado en la lista de inicio, o si la propietaria permite cualquier ID (como en el caso de la propietaria no privilegiada) , entonces el arbitro del recurso puede decidir la propiedad de transferencia sobre la base del resto de la' información proporcionada (la implementación más simple otorga la petición) . Si la solicitante no ha sido identificada en la lista CLSID de renuncia, el arbitro del recurso rechaza la petición. La siguiente es una implementación muestra del método ConfirmAcquire para el arbitro del recurso adecuado para usarse en un dispositivo que ejecuté un ambiente de tiempo de ejecución BREW. int 0EMResArbiter_ConfirmAcquire (IResArbiter * po, AEECLSID clsReq, EEResCtlInfo * pOwner, AEEResCtlInfo * pRequester) ( CResArbiter * pMe = (CResArbiter* ) po; int status = EITEMBUSY; int i; // //verifica primero la lista de clase para ver si la propietaria permitirá esto // switch (pOwner->nClsCount ) { case -1: //permitir a cualquiera adquirir el recurso status = SUCCESS; break; caso 0: //no permitir a nadie adquirir el recurso status = EITEMBUSY; break; default: //verificar lista de acceso (renuncia) for (i=0; i<pOwner->nClsCount; i++) { uint32 privld = pOwner->pClsList [ij; if (privld < QVERSION) { // ¿es aceptable en el caso? If (privld == pRequester->dwReason) { status = SUCCESS; break; else { //¿el id de la clase de la solicitante es igual o tiene privilegios de grupo? if (ISHELL_CheckPrivLevel (pMe->m pIShell.privId.TRUE) ) status = SUCCESS; break; } break; } // En éste punto, un OEM puede elegir, aceptar la lista de acceso verificar el permiso y/o agregar algoritmos de decisión adicionales como examinar la razón actual para el acceso o permitir CLSID solicitantes específicos son importar la lista de acceso, de la propietaria, etc. BREW fija dwReason a RESCTL_REASON_BUSY para si la aplicación actual responde a EVT_BUSY. if (pOwner->dwReason == RESCTL_REASON_BUSY && clsReq == AEECLSID_TOPVISIBLECTL) status = EITEMBUSY; return (status) ; } En consecuencia, aunque ha sido ilustrada y descrita aqui una o más modalidades de un sistema de prioridad de aplicación para usarse en un dispositivo, se apreciará que pueden hacerse varios cambios en las modalidades sin apartarse de su espíritu o características esenciales. Por lo tanto, las revelaciones y descripciones aqui pretenden ser ilustrativas, pero no limitantes, del alcance de la invención, el cual se expone en las siguientes reivindicaciones.

Claims (24)

1. NOVEDAD DE LA INVENCIÓN Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes: REIVINDICACIONES 1. Un método para operar un sistema de prioridad de aplicación para asignar un recurso visible en la parte superior en un dispositivo, el método caracterizado porque comprende: recibir una petición de solicitud de asignación del recurso visible en la parte superior a una aplicación solicitante; determinar que el recurso visible en la parte superior está asignado a una aplicación poseedora; asociar la información de la propietaria con la información de la solicitante para formar una petición de arbitraje, donde la información de la propietaria comprende información acerca de la aplicación poseedora y la información de la solicitante comprende información acerca de la aplicación solicitante; arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va ser asignado a la aplicación solicitante si la información de la propietaria indica que la aplicación poseedora es privilegiada, y un identificador que identifique que la aplicación solicitante está contenida en una lista de renuncia asociada con la información de la propietaria; y asignar el recurso visible en la parte superior sobre la base de la decisión del arbitraje.
2. 2. El método de conformidad con la reivindicación 1, caracterizado porque el paso de arbitraje comprende arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va a ser asignado a la aplicación poseedora si la información de la propietaria indica que la aplicación poseedora es privilegiada, y el identificador que identifique que la aplicación solicitante no está contenida en la lista de renuncia asociada con la información de la propietaria.
3. 3. El método de conformidad con la reivindicación 1, caracterizado porque el paso de arbitraje comprende arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va a ser asignado a una de la aplicación poseedora y la aplicación solicitante sobre la base de al menos un parámetro contenido en la información de la propietaria.
4. 4. El método de conformidad con la reivindicación 1, caracterizado porque el paso de arbitraje comprende arbitrar la petición de arbitraje para producir una decisión de arbitraje sobre la base de cualquier información seleccionada de un conjunto de elementos de información que comprenden la información de la propietaria, la información de la solicitante, información del estado del dispositivo, información del modo de operación de dispositivo, información de preferencias del usuario e información de preferencias de terceras partes.
5. 5. El método de conformidad con la reivindicación 1, caracterizado porque el paso de arbitraje es efectuado por un arbitro del recurso, y donde el método comprende descargar el arbitro del recurso al dispositivo.
6. 6. El método de conformidad con la reivindicación 1, caracterizado porque el dispositivo es un dispositivo inalámbrico.
7. 7. Un aparato para operar un sistema de prioridad de aplicación para asignar dinámicamente un recurso visible en la parte superior en un dispositivo, el aparato caracterizado porque comprende: un administrador del recurso que comprende: una lógica para recibir una petición que solicita asignación del recurso visible en la parte superior a una aplicación solicitante; la lógica para determinar que el recurso visible en la parte superior sea asignado a una aplicación poseedora; y la lógica para asociar la información de la propietaria con la información de la solicitante para formar una petición de arbitraje, donde la información de la propietaria comprende información acerca de la aplicación poseedora y la información de la solicitante comprende información acerca de la aplicación solicitante; un arbitro del recurso que opera para arbitrar la petición de arbitraje para producir una decisión de arbitraje que indica que el recurso visible en la parte superior va ser asignado a la aplicación solicitante si la información de la propietaria indica que la aplicación poseedora es privilegiada, y un identificador que identifica que la aplicación solicitante está contenida en una lista de renuncia asociada con la información de la propietaria; y la lógica para asignar el recurso de la vista superior sobre la base de la decisión de arbitraje.
8. 8. El aparato de conformidad con la reivindicación 7, caracterizado porque el arbitro del recurso opera para arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va a ser asignado a la aplicación poseedora si la información de la propietaria indica que la aplicación poseedora es privilegiada, y el identificador que identifica la aplicación solicitante no está contenida en la lista de renuncia asociada con la información de la propietaria.
9. 9. El aparato de conformidad con la reivindicación 7, caracterizado porque el arbitro del recurso opera para arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va a ser asignado a una de la aplicación poseedora y la aplicación solicitante sobre la base de al menos un parámetro contenido en la información de la propietaria.
10. 10. El aparato de conformidad con la reivindicación 7, caracterizado porque el arbitro del recurso opera para arbitrar la petición de arbitraje para producir una decisión de arbitraje sobre la base de cualquier información seleccionada de un conjunto de elementos de información que comprende la información de la propietaria, la información de la solicitante, la información del estado el dispositivo, la información del modo de operación del dispositivo, información de preferencias del usuario y la información de preferencias de terceras partes.
11. 11. El aparato de conformidad con la reivindicación 7, caracterizado porque comprende además la lógica para descargar el arbitro del recurso al dispositivo .
12. 12. El aparato de conformidad con la reivindicación 7, caracterizado porque el dispositivo es un dispositivo inalámbrico.
13. 13. Un aparato para operar un sistema de prioridad de aplicación para asignar un recurso visible en la parte superior en un dispositivo, el aparato caracterizado porque comprende: medios para recibir una petición de solicitud de asignación del recurso visible en la parte superior a la aplicación solicitante; medios para determinar que el recurso visible en la parte superior está asignado a una aplicación poseedora; medios para asociar la información de la propietaria con la información de la solicitante para formar una petición de arbitraje, donde la información de la propietaria comprende información acerca de la aplicación poseedora y la información de la solicitante comprende información acerca de la aplicación solicitante; medios para arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va ser asignado a la aplicación solicitante si la información de la propietaria indica que la aplicación poseedora es privilegiada, y un identificador que identifique que la aplicación solicitante está contenida en una lista de renuncia asociada con la información de la propietaria; y medios para asignar el recurso visible en la parte superior sobre la base de la decisión del arbitraje.
14. 14. El aparato de conformidad con la reivindicación 13, caracterizado porque los medios de arbitraje comprenden medios para arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va a ser asignado a la aplicación poseedora si la información de la propietaria indica que la aplicación poseedora es privilegiada, y el identificador que identifica la aplicación solicitante no está contenida en la lista de renuncia asociada con la información de la propietaria.
15. 15. El aparato de conformidad con la reivindicación 13, caracterizado porque los medios de arbitraje comprenden medios para arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va a ser asignado a una de la aplicación poseedora y la aplicación solicitante sobre la base de al menos un parámetro contenido en la información de la propietaria.
16. 16. El aparato de conformidad con la reivindicación 13, caracterizado porque los medios de arbitraje comprenden medios para arbitrar la petición de arbitraje para producir una decisión de arbitraje sobre la base de cualquier información seleccionada de un conjunto de elementos de información que comprende la información de la propietaria, la información de la solicitante, la información del estado del dispositivo, la información del modo de operación del dispositivo, la información de preferencias del usuario y la información de preferencias de terceras partes.
17. 17. El aparato de conformidad con la reivindicación 13, caracterizado porque los medios de arbitraje son efectuados por un arbitro del recurso, y donde el aparato comprende medios para descargar el arbitro del recurso al dispositivo.
18. 18. El aparato de conformidad con la reivindicación 13, caracterizado porque el dispositivo es un dispositivo inalámbrico.
19. 19. Medios legibles por computadora que comprenden instrucciones, las cuales cuando son ejecutadas por un procesador en un dispositivo, operan para proporcionar un sistema de prioridad de aplicación para asignar un recurso visible en la parte superior de un dispositivo, los medios legibles por computadora caracterizados porque comprenden: instrucciones para recibir una petición de solicitud de asignación del recurso visible en la parte superior a la aplicación solicitante; instrucciones para determinar que el recurso visible en la parte superior está asignado a una aplicación poseedora; instrucciones para asociar la información de la propietaria con la información de la solicitante para formar una petición de arbitraje, donde la información de la propietaria comprende información acerca de la aplicación poseedora y la información de la solicitante comprende información acerca de la aplicación solicitante; instrucciones para arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va ser asignado a la aplicación solicitante si la información de la propietaria indica que la aplicación poseedora es privilegiada, y un identificador que identifique que la aplicación solicitante está contenida en una lista de renuncia asociada con la información de la propietaria; e instrucciones para asignar el recurso visible en la parte superior sobre la base de la decisión del arbitraje.
20. 20. Los medios legibles por computadora de conformidad con la reivindicación 19, caracterizados porque las instrucciones para el arbitraje comprenden instrucciones para arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va a ser asignado a la aplicación poseedora si la información de la propietaria indica que la aplicación poseedora es privilegiada, y el identificador que identifica la aplicación solicitante no está contenida en la lista de renuncia asociada con la información de la propietaria.
21. 21. Los medios legibles por computadora de conformidad con la reivindicación 19, caracterizados porque las instrucciones de arbitraje comprenden instrucciones para arbitrar la petición de arbitraje para producir una decisión de arbitraje que indique que el recurso visible en la parte superior va a ser asignado a una de la aplicación poseedora y la aplicación solicitante sobre la base de al menos un parámetro contenido en la información de la propietaria.
22. 22. Los medios legibles por computadora de conformidad con la reivindicación 19, caracterizados porque las instrucciones para el arbitraje comprenden instrucciones para arbitrar la petición de arbitraje para producir una decisión de arbitraje sobre la base de cualquier información seleccionada de un conjunto de elementos de información que comprende la información de la propietaria, la información de la solicitante, la información del estado del dispositivo, la información del modo de operación del dispositivo, la información de preferencias del usuario y la información de preferencias de terceras partes.
23. 23. Los medios legibles por computadora de conformidad con la reivindicación 19, caracterizados porque las instrucciones para el arbitraje son efectuadas por un arbitro del recurso, y donde los medios legibles por computadora comprenden instrucciones para descargar el arbitro del recurso al dispositivo.
24. 24. Los medios legibles por computadora de conformidad con la reivindicación 19, caracterizados porque el dispositivo es un dispositivo inalámbrico.