ES2337600T3 - Gestor de interfaz de usuario y metodo de reaccion ante un cambio en el estado del sistema. - Google Patents
Gestor de interfaz de usuario y metodo de reaccion ante un cambio en el estado del sistema. Download PDFInfo
- Publication number
- ES2337600T3 ES2337600T3 ES06119122T ES06119122T ES2337600T3 ES 2337600 T3 ES2337600 T3 ES 2337600T3 ES 06119122 T ES06119122 T ES 06119122T ES 06119122 T ES06119122 T ES 06119122T ES 2337600 T3 ES2337600 T3 ES 2337600T3
- Authority
- ES
- Spain
- Prior art keywords
- user interface
- user
- interface module
- message
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- User Interface Of Digital Computer (AREA)
- Information Transfer Systems (AREA)
- Circuit For Audible Band Transducer (AREA)
- Computer And Data Communications (AREA)
Abstract
Un método de gestionar múltiples interfaces de usuario, comprendiendo dicho método: detectar un cambio en el estado del sistema desde en comunicación a fuera de comunicación o bloqueado o desde fuera de comunicación o bloqueado al de comunicación; en respuesta a dicha detección, transmitir (202) una petición del estado a un primer módulo de interfaz de usuario (114); recibir (204) una respuesta del estado desde dicho primer módulo de interfaz de usuario (114), comprendiendo dicha respuesta del estado una estructura de datos, en el que dicha estructura de datos incluye una indicación de un estado de dicho primer módulo de interfaz de usuario; transmitir (206) dicha estructura de datos a un segundo módulo de interfaz de usuario (116); y copiar (208), desde una primera lista asociada con dicho primer módulo de interfaz de usuario a una segunda lista asociada con dicho segundo módulo de interfaz de usuario, una identidad de un mensaje, que un proceso del dicho primer módulo de interfaz de usuario espera.
Description
Gestor de interfaz de usuario y método de
reacción ante un cambio en el estado del sistema.
La presente solicitud de patente se refiere en
general a interfaces de usuario y, más en particular, a un gestor
de interfaz de usuario y a un método de reacción ante un cambio en
el estado del sistema.
Es una práctica común al configurar un puesto
trabajo de ordenador para que pueda ser usado por varios usuarios
diferentes. Para mantener personalizadas la privacidad y la
configuración entre todos los usuarios en el contexto del uso del
puesto de trabajo, un sistema operativo para tal puesto, proporciona
típicamente una interfaz para iniciar la comunicación (logon) del
usuario. Un usuario completa un proceso de autenticación a través
de la interacción con la interfaz de inicio de comunicación del
usuario para poder acceder a las aplicaciones disponibles que se
ejecutan en el puesto de trabajo. Por consiguiente, se puede
considerar que el puesto de trabajo tiene un estado del sistema
fuera de comunicación (logged off) y un estado del sistema en
comunicación (logged on). Es más, como respuesta a una instrucción
directa del usuario, o debido a un periodo de inactividad, el
puesto de trabajo puede quedar bloqueado. Es decir, el puesto de
trabajo puede presentar el interfaz de comunicación de usuario y
solicitar al usuario que complete el proceso de autenticación para
que pueda de nuevo volver a acceder a las distintas aplicaciones
que ejecuta el puesto de trabajo. El estado del sistema en modo
bloqueado se puede considerar muy similar al estado del sistema
fuera de comunicación.
Se sabe que existen dispositivos periféricos de
ordenador para los que se puede establecer una conexión entre el
puesto de trabajo y los periféricos independientemente del estado
del sistema del puesto de trabajo. Tales conexiones disponen de sus
correspondientes protocolos de autenticación, y por consiguiente, no
necesitan depender de los protocolos de autenticación gestionados
por el sistema operativo del puesto de trabajo. En particular, el
establecimiento de una conexión entre un puesto de trabajo y un
periférico necesita generalmente una entrada de usuario y el
puesto de trabajo puede necesitar múltiples módulos de interfaz de
usuario con una selección de un módulo particular de interfaz de
usuario que depende del estado del sistema.
Sin embargo, se ha descubierto que aparece un
problema en un escenario en el que el puesto de trabajo realiza
una transición desde el estado del sistema en comunicación al estado
del sistema en modo bloqueado mientras se está efectuando el
establecimiento de la conexión entre puesto de trabajo y periférico.
Si, mientras el puesto de trabajo tenía el estado del sistema en
comunicación, el usuario iniciaba, pero no completaba, el
establecimiento de una conexión entre puesto de trabajo y
periférico, se le podía impedir al usuario establecer una conexión
entre puesto de trabajo y periférico, una vez que el puesto de
trabajo tenía el estado del sistema en modo bloqueado. Esto es
semejante, en tal escenario, a que la aplicación ejecutada por el
puesto de trabajo que permite el establecimiento de una conexión
entre un puesto de trabajo y un periférico espere además la
entrada de usuario, que está siendo impedida por el estado de
bloqueo del sistema.
Bahar, Abdul (Rajib), "Authentication against
Active Directory and Edirectory via LDAP", 28 enero 2004, paginas
1-10, trata de la autenticación de un usuario en
oposición al Microsoft Active Directory y Novell Edirectory usando
LDAP.
De acuerdo con una realización, se proporciona
preferiblemente un método de gestionar múltiples interfaces de
usuario, comprendiendo dicho método: detectar un cambio del estado
del sistema desde en comunicación a fuera de comunicación o
bloqueado o de fuera de comunicación o bloqueado a en comunicación;
en respuesta a dicha detección, transmitir una petición del estado
a un primer módulo de interfaz de usuario; recibir una respuesta
del estado desde dicho primer módulo de interfaz de usuario,
comprendiendo dicha respuesta de estado una estructura de datos,
incluyendo dicha estructura de datos una indicación del estado de
dicho primer módulo de interfaz de usuario; transmitir dicha
estructura de datos a un segundo módulo de interfaz de usuario; y
copiar, desde una primera lista asociada con dicho primer módulo de
interfaz de usuario a una segunda lista asociada con dicho segundo
módulo de interfaz de usuario, una identidad del mensaje, que un
proceso del dicho primer módulo de interfaz de usuario espera.
De acuerdo con otra realización, se proporciona
preferiblemente un equipo de ordenador para la gestión de múltiples
interfaces de usuario, comprendiendo dicho equipo de ordenador un
procesador adaptado para implementar el método anterior.
De acuerdo con otra realización, se proporciona
preferiblemente un medio legible por ordenador que contiene
instrucciones ejecutables por ordenador, de forma que, una vez
realizadas, hacen que dicho procesador realice el método
anterior.
En una realización preferida el método
comprende: la recepción de una petición para iniciar un módulo de
interfaz de usuario relativo a un servicio Windows; la
determinación de un estado actual del sistema de dicho equipo de
ordenador; la selección, basada en dicha determinación, de un
candidato de módulo de interfaz de usuario, de entre una pluralidad
de módulos de interfaz de usuario; la iniciación de dicho candidato
de módulo de interfaz de usuario; la recepción de una indicación de
un cambio a un nuevo estado del sistema; y la cancelación de
procesos actualmente activos de dicho candidato de módulo de
interfaz de usuario.
También se proporciona, en una realización
preferida, un equipo de ordenador para gestionar múltiples
interfaces de usuario, comprendiendo dicho equipo de ordenador un
procesador adaptado para: recibir una petición para iniciar un
módulo de interfaz de usuario relativo a un servicio Windows;
determinar un estado actual del sistema para dicho equipo de
ordenador; seleccionar, basándose en dicha determinación, un
candidato de módulo de interfaz de usuario de entre una pluralidad
de módulos de interfaz de usuario; iniciar dicho candidato de módulo
de interfaz de usuario; recibir una indicación de un cambio a un
nuevo estado del sistema; y cancelar los procesos actualmente
activos de dicho candidato de módulo de interfaz de usuario.
También se proporciona en una realización
preferida, un medio leíble por ordenador que contiene instrucciones
ejecutables por ordenador que, cuando se realizan por medio de un
procesador en un equipo de ordenador, permiten a dicho procesador:
recibir una petición para iniciar un módulo de interfaz de usuario
relativo a un servicio Windows; determinar un estado actual del
sistema de dicho equipo de ordenador; seleccionar, basándose en
dicha determinación, un candidato de módulo de interfaz de usuario
de entre una pluralidad de módulos de interfaz de usuario; iniciar
dicho candidato de módulo de interfaz de usuario;
Se hará referencia ahora a los dibujos, que
muestran, por vía de ejemplo, realizaciones de la invención, y en
los cuales:
La figura 1 ilustra un puesto de trabajo
adaptado para realizar aspectos de la presente solicitud;
La figura 2 ilustra etapas de ejemplo de un
método gestión de interfaces de usuario que responden a un cambio
en el estado del sistema, desde un estado actual del sistema a un
nuevo estado del sistema, de acuerdo con una realización;
La figura 3 ilustra un flujo de mensajes
relativos a la ejecución de las etapas de ejemplo de la figura 2;
y
La figura 4 ilustra etapas de ejemplo de un
método de gestión de múltiples interfaces de usuario para un
servicio de acuerdo con otra realización.
Se hace observar que "Winlogon" en
www.wikipedia.org, en computación, es un componente de los
sistemas operativos Microsoft Windows que es responsable de la
gestión de una clave de atención segura, que carga un perfil de
usuario en comunicación, y que bloquea opcionalmente el ordenador
cuando está funcionando un salva pantallas (requiriendo otra etapa
de autenticación). Se dejan a otros componentes la obtención y la
verificación de credenciales de usuario.
Winlogon gestiona funciones de interfaz que
son independientes de la política de autenticación. Winlogon crea
microordenadores de mesa para el puesto de trabajo, implementa
operaciones en inactividad, proporciona un conjunto de funciones
soporte para una biblioteca de Identificación y Autenticación
Gráfica (GINA) y toma la responsabilidad de configurar la Política
de Grupo para maquina y usuario.
La biblioteca GINA es un componente de algunos
sistemas operativos Microsoft Windows que proporciona autenticación
y servicios de comunicación interactiva seguros, La biblioteca GINA
es una biblioteca de enlace dinámico (DLL) que se carga en el
contexto del proceso Winlogon cuando se pone en marcha la máquina.
La biblioteca GINA es responsable de la gestión de una secuencia de
atención segura, típicamente
Control-Alt-Suprimir, e interactúa
con el usuario cuando se recibe esta secuencia. La biblioteca GINA,
alternativamente referida simplemente como "GINA", es también
responsable de la puesta en marcha de un proceso inicial para un
usuario (tal como Windows Shell) cuando el usuario se pone en
comunicación por vez primera.
Winlogon está configurado, por defecto, para
utilizar una GINA por defecto. Winlogon puede ser configurado para
usar una GINA diferente, proporcionando por ello métodos de
autenticación no standard y/o proporcionando una interfaz visual de
usuario que es diferente de la interfaz visual de usuario que
proporciona GINA por defecto.
Un archivo representativo de la DLL GINA se
localiza típicamente en la carpeta System32 y se puede reemplazar
con un archivo representativo de una DLL GINA personalizada que
proporcione procedimientos alternativos de identificación y
autenticación de usuario, tales como aquellos procedimientos de
autenticación que dependen de la comunicación con un dispositivo
periférico biométrico.
Métodos de ejemplo de autenticación no standard
pueden implicar un lector de tarjetas inteligente y pueden
implicar la identificación de un usuario basada en la biométrica. Se
necesitan programadores que implementen un GINA de reemplazo que
proporcionen implementaciones para un conjunto de llamadas de
interfaz de programación de aplicaciones (API), que cubran
funciones tales como visualizar un dialogo de "puesto de trabajo
bloqueado", procesar la secuencia de atención segura en varios
estados de usuario, responder a preguntas tales como si bloquear o
no el puesto de trabajo es una acción permitida, soportar la
recopilación de credenciales de usuario en conexiones basadas en
Servicios de Terminal e interactuar con un salva pantallas. El
componente Winlogon sólo es responsable de llamar a estas APIs en
la biblioteca GINA.
Un "servicio" Windows es una aplicación que
comienza cuando el sistema operativo Windows arranca y se ejecuta
en segundo plano al mismo tiempo que Windows opera. Windows
proporciona una interfaz llamada Gestor de Control de Servicio
(SCM) que gestiona la creación, supresión, arranque y parada de
servicios. Una aplicación que tiene que ser registrada como un
servicio necesita ser escrita de tal manera que la aplicación pueda
gestionar mensajes (inicio, parada, pausa, etc.) desde el SCM.
Entonces, en una o más llamadas API, se pueden registrar con el
SCM, el nombre del servicio y otros atributos, tales como la
descripción del servicio.
Los servicios Windows, se ejecutan, por defecto,
como un usuario virtual que está asociado con una cuenta llamada
"SistemaLocal". Dado que el SistemaLocal no es un usuario real,
se presentan asimismo algunos problemas cuando los datos
específicos del usuario necesitan ser almacenados por el servicio,
ya que no hay directorio doméstico para el usuario asociado con
la cuenta SistemaLocal.
El SCM mantiene una base de datos de servicios
registrados e incluye información de cómo debería ser iniciado cada
servicio. El SCM permite también a los administradores del sistema
personalizar los requisitos de seguridad para cada servicio y, por
consiguiente, controlar el acceso del usuario al servicio.
Si se está ejecutando un servicio dado en el
contexto de la cuenta SistemaLocal y tiene un atributo conocido
como atributo PROCESO_INTERACTIVO_DEL_SERVICIO, el servicio dado se
conoce como servicio interactivo. Un servicio interactivo puede
visualizar una interfaz gráfica de usuario (GUI) y recibir una
entrada de usuario.
Se sabe que la ejecución de un servicio
interactivo bajo el contexto de la cuenta SistemaLocal es una
práctica peligrosa y debería ser evitada. Se ha sugerido que, si un
servicio que se está ejecutando en un sistema
multi-usuario debe interactuar con un usuario, el
servicio ha de hacerlo por medio de un módulo separado GUI, en el
que el módulo separado GUI se ejecuta bajo el contexto de una
cuenta de usuario. Se ha sugerido además que el módulo separado GUI
ha de estar diseñado para comunicarse con el servicio a través de
algún método de comunicación entre procesos, tal como un método de
sección de memoria compartida para la comunicación llamado
"pipe". Esta combinación de un módulo separado GUI con un
servicio se le conoce como una implementación cliente/servidor y
sirve como una alternativa a la ejecución de un servicio interactivo
bajo el contexto de la cuenta SistemaLocal.
Cuando es necesario que un proceso de un módulo
GUI transmita un mensaje a un servicio Windows, en el que el
mensaje requiere una respuesta, el proceso puede crear una entrada
en un "mapa de procesos", implementado, por ejemplo, como un
mapa o como una lista. Se puede considerar que cada entrada en el
mapa de procesos incluye dos partes: un tipo de respuesta; y una
referencia a un objeto de transferencia del mensaje. Ejemplos de
tipos de respuesta podrían incluir, entre otras cosas, una
respuesta a una petición de comprobación de la versión, una
respuesta a una petición de ajustes de sincronización, y una
respuesta a una petición para fijar la política de Tecnología de la
Información IT.
El objeto de transferencia del mensaje contiene:
un indicador que indica si se ha recibido una respuesta; un evento
ante el cual el proceso debe esperar; y un campo de datos de
respuesta para retener los datos recibidos en la respuesta. Los
eventos ante los cuales el proceso debe esperar pueden incluir por
ejemplo una respuesta pendiente a una petición previa. Un evento
puede ser por ejemplo una manipulación.
Antes de enviar un mensaje del cual se espera
una respuesta, un proceso de envío crea primero un objeto de
transferencia del mensaje. El proceso de envío coloca entonces una
entrada en el mapa de procesos. Se recuerda que la entrada incluye
una indicación de un tipo de respuesta único (es decir, el tipo de
respuesta para el cual esperará el proceso de envío) y una
referencia al objeto de transferencia del mensaje. El proceso de
envío transmite entonces el mensaje. El proceso de envío espera
entonces a un evento, en el que el evento es la recepción de un
mensaje de respuesta que tiene un tipo de respuesta único.
Un proceso único conocido como un proceso
receptor es responsable de la lectura de mensajes entrantes, de
determinar si el mensaje entrante es una respuesta a un mensaje
enviado por uno de los procesos de envío, y, si es así, de activar
el apropiado proceso de envío. El proceso receptor esta inactivo
hasta que se recibe un mensaje. Una vez recibido el mensaje
entrante, el proceso receptor lee el tipo de mensaje del mensaje
entrante. El proceso receptor compara el tipo de mensaje del
mensaje entrante con el tipo de respuesta de cada entrada en el
mapa de procesos. Si el proceso receptor encuentra una entrada en el
mapa de procesos con un tipo de respuesta que concuerda con el tipo
de mensaje del mensaje entrante, el proceso receptor coloca en
"verdadero" el indicador de respuesta de entrada concordante,
copia el mensaje entrante dentro del campo de datos de respuesta,
elimina la entrada del mapa de procesos y señaliza el evento
"recepción de un mensaje de respuesta".
El proceso de envío puede continuar tras el
reconocimiento de que ha ocurrido el evento "recepción de un
mensaje de respuesta". Como continuación, el proceso de envío
examina el indicador de respuesta en el objeto de transferencia del
mensaje. Si el indicador de respuesta tiene un valor de
"verdadero", entonces es que se ha recibido una respuesta y
se puede esperar que el campo de datos de respuesta del objeto de
transferencia del mensaje contenga la respuesta. Si el indicador de
respuesta tiene un valor de "falso", entonces es que no se ha
recibido una respuesta.
Pueden existir módulos de interfaz de usuario
separados como clientes para un servicio Windows. Por ejemplo, se
puede usar un primer módulo de interfaz de usuario como un primer
cliente para un servicio Windows dado cuando el puesto de trabajo
tiene un estado del sistema fuera de comunicación o un estado del
sistema bloqueado y se puede usar un segundo módulo de interfaz de
usuario como un segundo cliente para un servicio Windows dado
cuando el puesto de trabajo tiene un estado del sistema en
comunicación. El primer módulo de interfaz de usuario tiene un
primer motor de mensajes que gestiona los mensajes entre procesos en
el primer módulo de interfaz de usuario y el servicio Windows dado.
Similarmente, el segundo módulo de interfaz de usuario tiene un
segundo motor de mensajes que gestiona los mensajes entre procesos
en el segundo interfaz de usuario y el servicio Windows dado.
Se considera el caso en el que el servicio
Windows dado se comunica con un dispositivo próximo utilizando el
conocido protocolo de comunicación Bluetooth. Tal servicio Windows
puede necesitar la interacción del usuario para seleccionar un
dispositivo al que conectarse y puede además necesitar que el
usuario introduzca una contraseña. También se considera un
escenario en el que un usuario está en pleno proceso de establecer
una conexión Bluetooth utilizando el segundo módulo de interfaz de
usuario, es decir, mientras se está identificando, cuando el puesto
de trabajo se bloquea. Convencionalmente, el usuario sería incapaz
de utilizar el primer módulo de interfaz de usuario, es decir, el
módulo de interfaz de usuario designado para ser utilizado cuando el
puesto de trabajo tiene un estado del sistema en modo bloqueado,
para establecer una conexión Bluetooth mientras se enfrenta a la
interfaz de usuario en comunicación, ya que un proceso en el
segundo módulo de interfaz de usuario está aún esperando la entrada
de usuario para transmitir al servicio Windows responsable de
establecer la conexión Bluetooth.
En una visión de conjunto, para controlar los
módulos de interfaz de usuario y dirigir los mensajes al módulo
correcto de interfaz de usuario, se puede implementar un módulo de
gestión de interfaz de usuario. Como respuesta a un cambio en el
estado del sistema, el módulo de gestión de la interfaz de usuario
determina el estado del primer módulo de interfaz de usuario y
transmite una indicación del estado del primer módulo de interfaz
de usuario al segundo módulo de interfaz de usuario.
Adicionalmente, el módulo gestor de interfaz de
usuario copia las entradas procedentes de un mapa de procesos
asociado con el primer módulo de interfaz de usuario a un mapa de
procesos asociado con el segundo módulo de interfaz de usuario.
La figura 1 ilustra un puesto de trabajo 100 que
incluye, típicamente, un procesador 102 y, en comunicación con el
procesador 102, una pantalla 104, un dispositivo de entrada 106 y
una memoria 108. El procesador 102 puede ejecutar varios módulos y
entidades de software para la ejecución de los métodos de ejemplo de
esta solicitud. Los módulos y las entidades de software están
ilustrados en la figura 1 como GINA 110, servicio Windows 112,
primer módulo de interfaz de usuario 114, segundo módulo de interfaz
de usuario 116 y gestor de la interfaz de usuario 118. Los módulos
y las entidades de software se pueden cargar en la memoria 108
desde un disco, una cinta, un circuito integrado o una memoria de
acceso aleatorio que contienen el archivo descargado desde una
fuente distante.
La figura 2 ilustra las etapas de ejemplo de un
método de gestión de interfaces de usuario que responden a un
cambio en el estado del sistema desde un estado actual del sistema a
un nuevo estado del sistema. La figura 3 ilustra un flujo de
mensajes relativos a la ejecución de las etapas de ejemplo de la
figura 2. Con referencia a la figura 3, en una condición inicial,
el primer módulo de interfaz de usuario 114 está en comunicación
con el servicio Windows 112. En particular, la figura 3 ilustra el
servicio Windows 112 transmitiendo un mensaje de información 302 al
gestor de interfaz de usuario 118. En particular, allí donde el
primer módulo de interfaz de usuario 114 estaría normalmente
registrado en el servicio Windows 112, es el gestor de interfaz de
usuario 118 el que está registrado en su lugar. El gestor de
interfaz de usuario 118 recibe el mensaje de información 302 y,
basado en el estado actual del sistema (es decir, en comunicación),
selecciona como destinatario al primer módulo de interfaz de
usuario 114.
La primera interfaz de usuario 114 recibe el
mensaje de información 302 procedente del gestor de interfaz de
usuario 118 y genera un mensaje de petición 304. En lugar de enviar
el mensaje de petición 304 directamente al servicio Windows 112, el
primer módulo de interfaz de usuario 114 transmite el mensaje de
petición 304 al gestor de interfaz de usuario 118.
Cuando el mensaje de petición 304 requiere una
respuesta procedente del servicio Windows112, el primer módulo de
interfaz de usuario 114 crea un objeto de transferencia del mensaje
y coloca una entrada en un mapa de procesos asociado con el primer
módulo de interfaz de usuario 114, en que la entrada incluye una
referencia al objeto de transferencia del mensaje. El gestor de
interfaz de usuario 118 dirige entonces el mensaje de petición 304
al servicio Windows 112.
Tiene lugar entonces un cambio en el estado del
sistema. Los cambios de ejemplo del estado del sistema incluyen: de
fuera de comunicación a en comunicación; de en comunicación a fuera
de comunicación; de en comunicación a bloqueado; y de bloqueado a
en comunicación. La biblioteca GINA 110 gestiona típicamente el
evento (es decir, una secuencia de atención segura, tal como
Control-Alt-Suprimir) que lleva al
cambio en el estado del sistema. Como tal, la biblioteca GINA 110
gestiona el envío de un mensaje 306, indicando el cambio en el
estado del sistema, al gestor de interfaz de usuario 118.
Como respuesta a la recepción del mensaje 306
que indica el cambio en el estado del sistema, el gestor de
interfaz de usuario 118 transmite (etapa 202, figura 2) un mensaje
de petición del estado 308 al primer módulo de interfaz de usuario
114. El primer módulo de interfaz de usuario 114 formula un mensaje
de respuesta del estado 310 generando una estructura de datos de
control del estado que incluye el estado del primer módulo de
interfaz de usuario 114. La información incluida en la estructura de
datos de control del estado puede incluir: una indicación de qué
diálogo se visualiza; una indicación de qué campo del diálogo está
enfocado; y una indicación de los contenidos de todos los campos
del diálogo. El primer módulo de interfaz de usuario 114 transmite
entonces el mensaje de respuesta del estado 310 al gestor de
interfaz de usuario 118.
Una vez recibido (etapa 204) el mensaje de
respuesta del estado 310, el gestor de interfaz de usuario 118
formula un mensaje de actualización del estado 312 para incluir la
estructura de datos del control del estado recibida en el mensaje
de respuesta del estado 310. El gestor de interfaz de usuario 118
transmite entonces (etapa 206) el mensaje de actualización del
estado 312 al segundo módulo de interfaz de usuario 116.
Adicionalmente, el gestor de interfaz de usuario 118 copia (etapa
208) las entradas procedentes del mapa de procesos asociado con el
primer módulo de interfaz de usuario 114 en el mapa de procesos
asociado con el segundo módulo de interfaz de usuario 116 (de modo
que el mapa de procesos asociado con la segunda interfaz de usuario
312 incluirá un proceso que espera la respuesta al mensaje de
petición 304).
El servicio Windows 112 transmite entonces un
mensaje de respuesta 314 al gestor de interfaz de usuario 118, en
el que el mensaje de respuesta es una respuesta al mensaje de
petición 304. El gestor de interfaz de usuario 118 recibe el
mensaje de respuesta 314 y, basado en que el estado del sistema haya
cambiado, selecciona el segundo módulo de interfaz de usuario 116
como destinatario.
Un proceso receptor del segundo módulo de
interfaz de usuario 116 recibe el mensaje de respuesta 314 del
gestor de interfaz de usuario 118 y compara el tipo de mensaje del
mensaje de respuesta 314 con la entrada asociada con el mensaje de
petición 304 en el mapa de procesos asociado con el segundo módulo
de interfaz de usuario 116. El proceso receptor genera entonces un
evento que activa el proceso que está en espera de una respuesta al
mensaje de petición 304.
Volviendo al caso en el que el servicio Windows
dado es un servicio de conexión Bluetooth y que el escenario es el
de un usuario que está en pleno proceso de establecer una conexión
Bluetooth por medio del uso del segundo módulo de interfaz de
usuario. El usuario puede haber, por ejemplo, utilizado un diálogo
de selección de dispositivo del segundo módulo de interfaz de
usuario para seleccionar un próximo dispositivo habilitado como
Bluetooth. Adicionalmente, el usuario puede haber, por ejemplo,
introducido los dos primeros dígitos de una contraseña de cuatro
dígitos en un campo de entrada alfanumérico de un diálogo de entrada
de contraseña del segundo módulo de interfaz de usuario antes de
que se bloquee el puesto de trabajo. Como respuesta al bloqueo del
puesto de trabajo, el gestor de interfaz de usuario transmite una
petición del estado al segundo módulo de interfaz de usuario y
recibe una respuesta del estado. Esta respuesta del estado incluye
una estructura de datos de control del estado que indica que se ha
abierto un diálogo para introducir contraseña, que se han recibido
dos dígitos y el valor de esos dos dígitos.
En un estado del sistema en modo bloqueado, el
usuario solicita la iniciación de un módulo de interfaz de usuario.
El gestor de interfaz de usuario, basado en el estado del sistema
en modo bloqueado, selecciona e inicia el primer módulo de interfaz
de usuario. Adicionalmente, el gestor de interfaz de usuario envía
un mensaje de actualización del estado al primer módulo de interfaz
de usuario. El mensaje de actualización del estado incluye la
estructura de datos del control del estado que indica que se ha
abierto un diálogo de introducción de contraseña, que se han
recibido dos dígitos en el campo de entrada alfanumérico y el valor
de los dos dígitos. Tras la iniciación, el primer módulo de
interfaz de usuario presenta el usuario con el diálogo de
introducción de contraseña que muestra, en el campo alfanumérico de
entrada, que se han recibido dos dígitos. Convencionalmente, la
indicación de que se ha recibido un dígito de una contraseña se
efectúa visualizando, en el campo alfanumérico de entrada, un
asterisco ("*"). Sin embargo, se pueden usar otros símbolos,
tales como un punto (".") o un punto grueso
("\bullet").
Aunque la copia (etapa 208) del mapa de procesos
asociado con el segundo módulo de interfaz de usuario en el mapa de
procesos asociado con primer módulo de interfaz de usuario,
proporciona suficiente información para permitir que un proceso
del primer módulo de interfaz de usuario espere a la finalización de
la introducción de la contraseña, es la información contenida en
la estructura de datos del control del estado, recibida en el
mensaje de actualización del estado 312, la que permite que el
primer módulo de interfaz de usuario presente el diálogo de
introducción de la contraseña en el estado en que estaba el diálogo
en el momento del bloqueo.
La solución propuesta anteriormente tiene la
ventaja de permitir al usuario utilizar sin fisuras una interfaz de
diálogo para interactuar con, y para proporcionar entrada a, un
servicio Windows en tres situaciones: cuando un usuario está en
comunicación; cuando el puesto de trabajo está bloqueado; y cuando
no hay ningún usuario en comunicación.
Como está claro para una persona experta en esta
técnica, el módulo de interfaz de usuario designado para ser usado
cuando el estado del sistema está fuera de comunicación/bloqueado,
puede estar integrado en una biblioteca GINA personalizada.
Como una alternativa para determinar y
transferir una indicación del estado del módulo de interfaz de
usuario, que responda a la recepción de un mensaje que indica un
cambio en un estado del sistema procedente de GINA, el gestor de
interfaz de usuario puede simplemente disponer la cancelación de los
procesos actualmente activos de cualquier módulo de interfaz de
usuario en uso. A partir de ello, en el nuevo estado del sistema, el
usuario puede iniciar la interacción con el servicio Windows. Como
respuesta, el gestor de interfaz de usuario selecciona el módulo
apropiado de entre los módulos de interfaz de usuario y se le
solicita al usuario que introduzca los datos desde el
principio.
La figura 4 ilustra etapas de ejemplo de un
método de gestión de múltiples interfaces de usuario desarrolladas
para su empleo con un único servicio Windows. Inicialmente, un
gestor de interfaz de usuario recibe (etapa 402) una petición para
iniciar una interfaz de usuario en un servicio Windows. El gestor de
interfaz de usuario determina entonces (etapa 404) el estado del
sistema. Si el gestor de interfaz de usuario determina que el
estado del sistema está "en comunicación", el gestor de
interfaz de usuario selecciona el módulo de interfaz de usuario en
comunicación e inicia el módulo de interfaz de usuario en
comunicación (etapa 406). Mientras está en ejecución el módulo de
interfaz de usuario en comunicación, el gestor de interfaz de
usuario puede determinar (etapa 408) que se ha recibido un mensaje
de cambio del estado del sistema. Si el gestor de interfaz de
usuario determina (etapa 408) que se ha recibido un mensaje de
cambio de estado del sistema, el gestor de interfaz de usuario
procede a cancelar (etapa 410) los procesos actuales del módulo de
interfaz de usuario en modo identificado. Si el gestor de interfaz
de usuario determina (etapa 408) que no se ha recibido un mensaje
de cambio del estado del sistema, el gestor de interfaz de usuario
continúa supervisando su llegada.
La cancelación (etapa 410) de los procesos
actualmente activos del módulo de interfaz de usuario en
comunicación puede implicar, por ejemplo, la eliminación de cada
entrada desde el mapa de procesos asociado con los procesos
actualmente activos y la generación de eventos que ordenen la
finalización de los procesos actualmente activos. Se puede
considerar tal cancelación equivalente a la reacción que tendría un
módulo de interfaz de usuario al seleccionar un usuario el pulsador
de "Cancelar" en un diálogo presentado por el módulo de
interfaz de usuario. El resultado es que el módulo de interfaz de
usuario vuelve a un estado de reposo.
Ventajosamente, una vez que el módulo de
interfaz de usuario en comunicación ha vuelto a un estado de reposo,
la interfaz de usuario en comunicación ya no espera ninguna
entrada de usuario y un nuevo módulo de interfaz de usuario puede
comunicar con el servicio Windows sin restricción.
En el nuevo estado del sistema, el gestor de
interfaz de usuario puede, de nuevo, recibir (etapa 402) un petición
para iniciar una interfaz de usuario al servicio Windows. El gestor
de interfaz de usuario determina entonces (etapa 404) el estado del
sistema. Si el gestor de interfaz de usuario determina que el estado
del sistema está "fuera de comunicación" o "bloqueado",
el gestor de interfaz de usuario selecciona el módulo de interfaz
de usuario fuera de comunicación/bloqueado e inicia (etapa 412) el
módulo de interfaz de usuario fuera de comunicación/bloqueado.
Mientras se está ejecutando el módulo de interfaz de usuario en
fuera de comunicación/bloqueado, el gestor de interfaz de usuario
puede determinar (etapa 408) que se ha recibido un mensaje de cambio
del estado del sistema. Si el gestor de interfaz de usuario
determina (etapa 408) que se ha recibido un mensaje de cambio de
estado del sistema, el gestor de interfaz de usuario procede a
cancelar (etapa 410) los procesos actualmente activos del módulo de
interfaz de usuario en fuera de comunicación/bloqueado. Si el gestor
de interfaz de usuario determina (etapa 408) que no se ha recibido
un mensaje de cambio del estado, el gestor de interfaz de usuario
continúa supervisando su recepción.
Aunque, según se ha presentado en las etapas de
ejemplo del método de la figura 4, sólo hay dos módulos de interfaz
de usuario para elegir entre ellos, una persona experta en esta
técnica sabría que se puede disponer de una amplia variedad de
módulos de interfaz de usuario, uno para cada estado del sistema. De
acuerdo con ello, seleccionar (etapa 404) un candidato de módulo de
interfaz de usuario para iniciar, basado en el estado del sistema,
puede ser más complejo que la simple determinación de si el puesto
de trabajo tiene el estado del sistema en comunicación.
Las realizaciones de la presente solicitud de
patente anteriormente descritas sirven sólo como ejemplos. Se
pueden efectuar alteraciones, modificaciones y variaciones a las
realizaciones particulares por aquellas personas expertas en esta
técnica sin apartarse del alcance de la solicitud, la cual viene
definida por las reivindicaciones siguientes.
Claims (8)
1. Un método de gestionar múltiples interfaces
de usuario, comprendiendo dicho método:
- \quad
- detectar un cambio en el estado del sistema desde en comunicación a fuera de comunicación o bloqueado o desde fuera de comunicación o bloqueado al de comunicación;
- \quad
- en respuesta a dicha detección, transmitir (202) una petición del estado a un primer módulo de interfaz de usuario (114);
- \quad
- recibir (204) una respuesta del estado desde dicho primer módulo de interfaz de usuario (114), comprendiendo dicha respuesta del estado una estructura de datos, en el que dicha estructura de datos incluye una indicación de un estado de dicho primer módulo de interfaz de usuario;
- \quad
- transmitir (206) dicha estructura de datos a un segundo módulo de interfaz de usuario (116); y
- \quad
- copiar (208), desde una primera lista asociada con dicho primer módulo de interfaz de usuario a una segunda lista asociada con dicho segundo módulo de interfaz de usuario, una identidad de un mensaje, que un proceso del dicho primer módulo de interfaz de usuario espera.
\vskip1.000000\baselineskip
2. El método de la reivindicación 1, en el que
la estructura de datos comprende información recuperada desde el
primer módulo de interfaz de usuario (114) y que es utilizada por el
segundo módulo de interfaz de usuario (116) para ajustar una
interfaz de usuario de ese modo generada.
3. El método de la reivindicación 1, en el que
dicha identidad comprende un tipo para dicho mensaje.
4. El método de la reivindicación 1, en el que
dicha identidad comprende una referencia a un objeto de
transferencia del mensaje, comprendiendo dicho objeto de
transferencia del mensaje:
- \quad
- un indicador que indica si se ha recibido dicho mensaje;
- \quad
- un evento, que espera dicho proceso; y
- \quad
- un campo de datos para retener los datos recibidos en el mensaje.
\vskip1.000000\baselineskip
5. El método de cualquiera de las
reivindicaciones 1 a 4, en el que dicha estructura de datos
comprende una indicación de un nombre de un diálogo abierto.
6. El método de la reivindicación 5, en el que
dicha estructura de datos comprende una indicación del contenido de
un campo en dicho diálogo abierto.
7. Un equipo de ordenador (100) para la gestión
de múltiples interfaces de usuario, comprendiendo dicho equipo de
ordenador un procesador (102) adaptado para implementar el método de
cualquiera de las reivindicaciones 1 a 6.
8. Un medio legible por ordenador que contiene
instrucciones ejecutables por ordenador, que, cuando las ejecuta el
procesador (102), hacen que dicho procesador realice el método de
cualquiera de las reivindicaciones 1 a 6.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06119122A EP1890226B1 (en) | 2006-08-17 | 2006-08-17 | User interface manager and method for reacting to a change in system status |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2337600T3 true ES2337600T3 (es) | 2010-04-27 |
Family
ID=37781884
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06119122T Active ES2337600T3 (es) | 2006-08-17 | 2006-08-17 | Gestor de interfaz de usuario y metodo de reaccion ante un cambio en el estado del sistema. |
Country Status (6)
| Country | Link |
|---|---|
| EP (1) | EP1890226B1 (es) |
| CN (1) | CN101131641B (es) |
| AT (1) | ATE455327T1 (es) |
| CA (1) | CA2597453C (es) |
| DE (1) | DE602006011739D1 (es) |
| ES (1) | ES2337600T3 (es) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102456180A (zh) * | 2010-10-28 | 2012-05-16 | 鸿富锦精密工业（深圳）有限公司 | 测量仪器使用信息管控系统及方法 |
| CN103975567B (zh) * | 2012-11-14 | 2017-12-12 | 华为技术有限公司 | 双因素认证方法及虚拟机设备 |
| CN105227426B (zh) * | 2014-05-30 | 2019-12-13 | 小米科技有限责任公司 | 一种应用界面切换方法、装置及终端设备 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10065211A1 (de) * | 2000-12-20 | 2002-05-16 | Sedima Ag | Computersystem mit interaktiver Bildschirmoberfläche |
| US6903743B2 (en) * | 2002-10-16 | 2005-06-07 | Motorola, Inc. | Dynamic interactive animated screen saver |
-
2006
- 2006-08-17 AT AT06119122T patent/ATE455327T1/de not_active IP Right Cessation
- 2006-08-17 ES ES06119122T patent/ES2337600T3/es active Active
- 2006-08-17 EP EP06119122A patent/EP1890226B1/en active Active
- 2006-08-17 DE DE602006011739T patent/DE602006011739D1/de active Active
-
2007
- 2007-08-16 CA CA2597453A patent/CA2597453C/en active Active
- 2007-08-17 CN CN2007101821091A patent/CN101131641B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CA2597453C (en) | 2011-11-01 |
| EP1890226B1 (en) | 2010-01-13 |
| ATE455327T1 (de) | 2010-01-15 |
| CN101131641A (zh) | 2008-02-27 |
| CN101131641B (zh) | 2012-04-25 |
| EP1890226A1 (en) | 2008-02-20 |
| DE602006011739D1 (de) | 2010-03-04 |
| CA2597453A1 (en) | 2008-02-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10362613B2 (en) | Pairing management method, recording medium, and terminal apparatus | |
| EP3403371B1 (en) | Electronic device for authenticating based on biometric data and operating method thereof | |
| EP3225008B1 (en) | User-authentication-based approval of a first device via communication with a second device | |
| US20080289032A1 (en) | Computer Control Method and Computer Control System Using an Externally Connected Device | |
| EP2809046B1 (en) | Associating distinct security modes with distinct wireless authenticators | |
| US9774599B2 (en) | Authenticating method and apparatus using electronic device | |
| JP2008090493A (ja) | 情報処理システム、端末、情報処理装置、管理サーバ | |
| US8151201B2 (en) | User interface manager and method for reacting to a change in system status | |
| KR102469569B1 (ko) | 전자 장치 및 그의 동작 방법 | |
| JP5210966B2 (ja) | 生体認証装置、および、生体認証方法 | |
| US11010460B2 (en) | Method for managing contents and electronic device thereof | |
| CA2660366C (en) | Enhanced user interface manager and method for managing non-contemporaneous user interface modules | |
| ES2337600T3 (es) | Gestor de interfaz de usuario y metodo de reaccion ante un cambio en el estado del sistema. | |
| KR20180046149A (ko) | 인증을 수행하기 위한 전자 장치 및 방법 | |
| US11075920B2 (en) | Providing access to structured stored data | |
| JP2013120594A (ja) | Ｉｃチップと通信可能な携帯情報端末 | |
| KR102508799B1 (ko) | 잠금 장치의 잠금 해제를 위한 방법 및 전자 장치 | |
| JP5037720B1 (ja) | Ｉｃチップと通信可能な携帯情報端末 | |
| US11954237B2 (en) | Systems and methods for providing surrogate credentials and a secure guest mode for mobile devices | |
| JP2016110368A (ja) | 管理システム、情報処理装置、端末装置、管理方法、および管理プログラム | |
| KR102294002B1 (ko) | 심카드를 인식하는 전자장치 및 동작 방법 | |
| CN111859461A (zh) | 数据隔离方法、装置和电子设备 | |
| JP2007034978A (ja) | 生体情報認証装置、生体情報認証方法および生体情報認証用プログラム | |
| JP2005085154A (ja) | ネットワークシステムおよび端末装置 | |
| JP2007094615A (ja) | 機器制御システム |