MX2012008156A - Mecanismo para una interface de usuario grafica de maquina expendedora que utiliza xlm para una experiencia. de cliente versatil. - Google Patents

Abstract

Se suministra la lógica 106 para una interfase de cliente de máquina expendedora a partir de una pluralidad de descripciones de lenguaje de marcación 113a-113n de la interfase de cliente contenida dentro de medios de almacenamiento 112 en la máquina expendedora 100. Cada descripción de lenguaje de marcación está configurada para hacer que la interfase de cliente fluya entre diferentes grupos de estados de aplicación, y contenga el contenido que es presentado/solicitado cuando se activan estados de aplicación respectivos. En respuesta a la selección del cliente de un producto particular o clase de productos, basándose en la selección del cliente, el controlador procesa el flujo y contenido de interfase de cliente basándose en una descripción de lenguaje de marcación correspondiente para producir la presentación de interfase de cliente.

Description

MECANISMO PARA UNA INTERFASE DE USUARIO GRAFICA DE MAQUINA EXPENDEDORA QUE UTILIZA XML PARA UNA EXPERIENCIA DE CLIENTE VERSATIL CAMPO TECNICO La presente solicitud se refiere generalmente a máquinas expendedoras y, más específicamente, a selección de lenguaje dinámico dentro de la interfase de cliente a una máquina expendedora.

ANTECEDENTES Las máquinas expendedoras convencionales típicamente siguen un grupo de reglas simples basadas en logística para asegurar que el consumidor ha hecho una selección válida de producto para compra, y que el consumidor, en regreso, ha presentado suficiente crédito (dinero). La operación de estos dispositivos por lo general está gobernada por acciones activadas por eventos del sistema, tales como depósito de moneda en un sistema de pago, accionamiento de cliente de un control de selección, o verificación de suministro de producto por un sistema de percepción.

En algunas situaciones, es deseable proporcionar una experiencia diferente de interfase de cliente dependiendo del producto o tipo de producto que se está comprando. Por ejemplo, las máquinas para vender café (americano o estilo europeo), expreso, y otras bebidas elaboradas calientes necesitan diferente flujo de la interacción de cliente para hacer todas las selecciones requisito, especialmente si se ofrecen diferentes preparaciones o sabores.

Por lo tanto, existe una necesidad en la técnica de una máquina expendedora que permita un diferente flujo de interfase de cliente basándose en la selección(es) de producto.

BREVE DESCRIPCION DE LA INVENCION Se suministra lógica para una interfase de cliente de máquina expendedora a partir de una pluralidad de descripciones de lenguaje de marcación del texto de interfase de cliente contenido dentro de los medios de almacenamiento en la máquina expendedora. Cada descripción de lenguaje de marcación está configurada para ocasionar el flujo de interfase de cliente entre diferentes grupos de estados de aplicación, y contenido que se despliega/presenta cuando se activan estados de aplicación respectivos. En respuesta a la selección, por parte del cliente, de un producto particular o clases de productos, basándose en la selección del cliente, el controlador procesa el flujo de interfase de cliente y contenido basándose en una descripción de lenguaje de marcación correspondiente para producir la presentación de interfase de cliente.

Antes de ocuparse de la DESCRIPCIÓN DETALLADA a continuación, puede ser ventajoso explicar definiciones de ciertas palabras y frases utilizadas a través de este documento de patente: los términos "incluyen" y "comprenden", así como derivados de los mismos, significan inclusión sin limitación; el término "o", es inclusivo, significando y/o; las frases "asociado con" y "asociado con éste", así como derivados de las mismos, pueden significar que incluyen, que están incluidos dentro, interconectan con, contienen, están contenidos dentro, se conectan a o con, se acoplan a o con, se pueden comunicar con, cooperan con, se intercalan, yuxtaponen, están cerca de, se unen a o con, tienen, tienen una propiedad de, o similares; y el término "controlador" significa cualquier dispositivo, sistema o parte del mismo que controla al menos una operación, tal dispositivo puede ¡mplementarse en hardware, firmware o software, o alguna combinación de al menos dos de los mismos. Se debe observar que la funcionalidad asociada con cualquier controlador particular puede centralizarse o distribuirse, ya sea local o remotamente. Se proporcionan definiciones para ciertas palabras y frases a través de este documento de patente, aquellos expertos en la técnica deben entender que en muchos, si no es que en la mayoría de los casos, tales definiciones aplican antes, así como usos futuros de tales palabras y frases definidas.

BREVE DESCRIPCION DE LOS DIBUJOS Para un entendimiento más completo de la presente descripción y sus ventajas, ahora se hace referencia a la siguiente d escripción tomada en conjunto con los dibujos anexos, en donde números de referencia similares representan partes similares: La Figura 1 ilustra una máquina expendedora de bebida preparada que emplea descripciones de lenguaje de marcación para flujo de interfase de cliente dinámica para una interfase de usuario gráfica de acuerdo con una modalidad de la presente descripción; La F igura 1A ¡lustra con mayor detalle la porción de interfase de usuario de la máquina expendedora de bebida preparada de la Figura 1 ; La Figura 1B es un diagrama de bloques de subsistemas eléctricos, electrónicos y/o el electro-mecánicos seleccionados dentro de la máquina expendedora de bebida preparada de la Figura 1; Las Figuras 2A y 2B son diagramas de bloques que ilustran la arquitectura de y flujo de datos con los sistemas de control de hardware y software dentro de una máquina expendedora de bebida preparada que emplea descripciones de lenguaje de marcación para flujo de interfase de cliente dinámica para una interfase de usuario gráfica de acuerdo con una modalidad de la presente descripción; La Figura 3 es un diagrama de bloques más detallado de un administrador de contenido dentro de la arquitectura de las Figuras 2A y 2B; La Figura 4A ilustra un diagrama de estado para una implementación simplificada de la máquina de estado en la Figura 2; La Figura 4B ilustra un diagrama de estado para una implementación realista de la máquina de estado en la Figura 2; y La Figura 5 es un diagrama de flujo de alto nivel para un procedimiento para emplear descripciones de lenguaje de marcación para flujo de ¡nterfase de cliente dinámica para una interfase de usuario gráfica dentro de una máquina expendedora de bebida preparada de acuerdo con una modalidad de la presente descripción.

DESCRIPCION DETALLADA Las Figuras 1 a 5, discutidas a continuación, y las varias modalidades utilizadas para describir los principios de la presente descripción en este documento de patente son a manera de ilustración únicamente y no deben interpretarse de ninguna forma para limitar el alcance de la descripción. Aquellos expertos en la técnica entenderán que los principios de la presente descripción pueden implementarse en cualquier máquina expendedora adecuadamente dispuesta.

La Figura 1 ilustra una máquina expendedora de bebida preparada que emplea descripciones de lenguaje de marcación para flujo de interfase de cliente dinámica para una interfase de usuario gráfica de acuerdo con una modalidad de la presente descripción. El sistema 100 incluye un gabinete 101 que aloja los componentes internos de la máquina expendedora y que incluyen una estación de suministro 102 en la cual, en la modalidad ilustrativa, se suministran bebidas preparadas calientes o frías al cliente. El sistema 100 también incluye una interfase de usuario gráfica (cliente) que proporciona información dinámica al cliente durante una transacción de venta tal como el estado de pago o selecciones de producto disponibles, y permite al cliente seleccionar productos, obtener rembolsos de moneda depositada, y/u obtener información adicional con respecto a productos disponibles o términos de compra de venta. La interfase de usuario 103, ilustrada con mayor detalle en la Figura 1A, incluye una presentación gráfica 104 que, para el cliente que utiliza la máquina expendedora, parece físicamente dividida en un área de presentación principal 104a y una pluralidad de aéreas de presentación de etiqueta 104b-104m al sobreponer material (por ejemplo, plástico) ilustrado en fantasma en la Figura 1A. Como se ilustra, una pluralidad de controles de interfase de usuario 105b-105m (por ejemplo, interruptores activados por presión) corresponde a la pluralidad de áreas de presentación de etiqueta 104b-104m. En modalidades alternas, sin embargo, una presentación de pantalla táctil directa puede permitir la selección de usuario basada en las áreas de presentación de etiqueta.

La Figura 1B es un diagrama de bloques de subsistemas eléctricos, electrónicos y/o electromecánicos seleccionados dentro de la máquina expendedora de bebida preparada de la Figura 1. Sistema 100 incluye un controlador central 106, que puede implementarse como un controlador de máquina expendedora (VMC) del tipo conocido en la técnica, que está comunicativamente acoplado a la interfase de usuario gráfica (cliente) 103. El VMC 106 también está comunicativamente acoplado a, y recibe señales de control desde y puede suministrar señales de control a, un sistema de pago 107 tal como un aceptador/reciclador de billete, un mecanismo de moneda, y/o un sistema de pago de tarjeta de crédito o débito, todos los cuales son conocidos en la técnica. El VMC 160 está comunicativamente acoplado a y controla un sistema de suministro electromecánico 108, que está mecánicamente acoplado a u operable con almacenamiento de producto 109. El VMC 101 además está comunicativamente acoplado a y controla un sistema de calentamiento y/o calentamiento de refrigeración 110, y además puede estar comunicativamente acoplado a y recibir señales de control de un sistema de detección de suministro opcional 111.

Como se observó anteriormente, la modalidad ilustrativa es preferiblemente una máquina expendedora de café para suministrar bebidas calientes preparadas a la orden. Como tal, el almacenamiento de producto 109 típicamente incluirá granos o molido de café, u otras sustancias a partir de las cuales puede prepararse una bebida caliente (por ejemplo, hojas de té, polvo de cacao, etc.) y tazas. El sistema de suministro 108 normalmente incluirá una cámara de mezcla para mezclar la sustancia que se va a preparar con agua caliente y un sistema de canalización para suministrar la bebida preparada caliente. Un ejemplo de la estructura interna de tal máquina expendedora de café se encuentra en la Solicitud de Patente de E.U.A. Serie No. 12/958,172 titulada MÁQUINA DE CAFÉ MODULAR CON BANDA DE FILTRO CONTINUA y presentada el 1 de diciembre, 2010, cuyo contenido se incorpora aquí por referencia.

Aquellos expertos en la técnica reconocerán que la construcción y la operación completa de una máquina expendedora no se ilustra en los dibujos o se describe aquí. Más bien, para simplicidad y claridad, únicamente siempre y cuando una máquina expendedora de bebida preparada sea única para la presente descripción o necesaria para un entendimiento de la presente descripción se ilustra y describe. En modalidades de máquina expendedora alternativas, el almacenamiento de producto 109 puede tomar la forma de espirales helicoidales que soportan productos de botana, con el sistema de suministro 108 incluyendo motores para hacer girar los espirales helicoidales. Incluso en otras modalidades de máquina expendedora, el almacenamiento de producto 109 puede ser bandejas que soportan bebidas empacadas en posición vertical, mientras el sistema de suministro 108 incluye un mecanismo de recuperación de producto X-Y. Tales diseños son conocidos por aquellos expertos en la técnica. Además, las técnicas de la presente descripción pueden implementarse en otros tipos de sistemas en lugar de máquinas expendedoras, tales como máquinas contadoras automatizadas (ATM), quioscos de boleto de autobús/tren/avión, dispensadores de combustible, y registradoras de supermercado de auto-revisión.

Las máquinas expendedoras, así como máquinas contadoras automatizadas, quioscos de boleto, dispensadores de combustible, y registradoras de supermercado de auto-revisión, son todos dispositivos similares a una "terminal" que tradicionalmente han tenido que manejar interfases multilingües para la población general, pero no siempre lo han hecho en una forma flexible. Las interfases de Lenguaje de Marcación de Hipertexto (HTML) para sitios web, por otro lado, están diseñadas para una audiencia global, y han desarrollado técnicas y herramientas que proporcionan infraestructura sofisticada para selección de lenguaje dinámico, unidades de medición (incluyendo moneda), etc. El concepto algunas veces se denomina como localización.

En la presente descripción, el sistema 100 incluye medios de almacenamiento 112 comunicativamente acoplados a VMC 106, y opcionalmente incluyen un controlador de presentación 114 separado del VMC 106 acoplado entre la interfase de cliente 103 y los medios de almacenamiento 112 realizando o facilitando los procedimientos descritos a continuación. Los medios de almacenamiento 112 pueden tomar la forma de memoria "flash", Memoria de sólo lectura eléctricamente programable borrable (EEPROM), o cualquier otro tipo adecuado de medios de almacenamiento de datos, preferiblemente no volátiles y adaptados para sobrescribirse así como leerse durante la vida útil operativa del sistema 100.

Dentro de los medios de almacenamiento 112 están descripciones de interfase de cliente de lenguaje de marcación 113a-113n. Como se utiliza aquí, "lenguaje de marcación" incluye definiciones basadas en texto de contenido de interfase de usuario (en lugar de puramente contenido gráfico presentado por código ejecutable específico de máquina) e incluye, a manera de ejemplo, HTML y en una modalidad preferida Lenguaje de Marcación eXtensible (XML). La modalidad ilustrativa del diseño descrito utiliza XML para definir todo el texto asociado con la interfase de cliente de sistema, utilizando una gramática flexible pero predeterminada para describir elementos textuales utilizando etiquetas XML. La descripción XML define todos los elementos textuales específicos en un diccionario basándose en estas etiquetas XML, agrupadas por lenguaje. Este mecanismo a su vez se utiliza por un mecanismo de conmutación de lenguaje flexible en la capa de presentación de la interfase de cliente. El cambio de lenguaje se conduce subsecuentemente por un evento de selección en la interfase de cliente. El evento de selección puede estar asociado con presionar un botón físico (tal como pero no limitado a una tecla suave reprogramable) en el exterior de la máquina expendedora, o presionar un botón "virtual" en una interfase de usuario de pantalla táctil.

Las Figuras 2A y 2B son diagramas de bloques que ilustran la arquitectura de y el flujo de fecha dentro de los sistemas de control de hardware y software dentro de una máquina expendedora de bebida preparada que emplea descripciones de lenguaje de marcación flujo de interfase de cliente dinámica para una interfase de usuario gráfica de acuerdo con una modalidad de la presente descripción. La arquitectura de sistema de control 200 incorpora el patrón arquitectónico de "separación de problemas" (SoC), con componentes lógicamente agrupados basándose en si el componente respectivo está activamente involucrado en un procedimiento de interés o simplemente es reactivo al procedimiento y/o son relativamente independientes de los procedimientos de interfase de usuario. En la presente descripción, el hardware para el sistema 100 esta lógicamente dividido en los componentes de interfase de usuario 201 y los componentes 202 para el resto del sistema. Los componentes de interfase de usuario 201 incluyen un administrador de contenido 203 y capas de presentación PL1 204 y PL2 205. Preferiblemente existe una capa de presentación para cada dispositivo de interacción de usuario. De esa forma la capa de presentación PL1 204 está asociada con la presentación de interfase de usuario 104 e interruptores 105b-105h (o la presentación de pantalla táctil mencionada anteriormente) en la modalidad ilustrativa, aunque la capa de presentación PL2 205 está asociada con algún otro dispositivo de interacción de usuario no mostrado en la modalidad ilustrativa (por ejemplo, una presentación de 7 segmentos y/o botones adicionales). En modalidades con más de dos dispositivos de interacción de usuario, se proporcionarán capas de presentación adicionales para cada dispositivo de interacción de usuario.

Los componentes restantes 202 para el sistema 100 están lógicamente agrupados por procedimientos, y pueden incluir el mismo dispositivo de hardware en diferentes componentes. Estos son los componentes del "resto del sistema", o los componentes de sistema diferentes al subsistema de interfase de usuario. De esa forma, por ejemplo, el componente de sistema de suministro de producto (PDS) 206 incluye el VMC 106 y el sistema de suministro 108, mientras el componente monetario ( ON) 207 también incluye el VMC 106, e incluye el sistema de pago 107 también. Otro componente 208 también puede incluir el VMC 106, junto con uno o más de otros dispositivos de hardware. Por ejemplo, puede incluirse un componente de "Gabinete" que abarca el sistema de detección de suministro de producto en la estación de suministro 102. Los componentes en el grupo de "resto del sistema" 202 pueden variar, debido a una modalidad particular pueden tener los componentes mostrados u otro grupo de componentes, para cumplir los propósitos particulares del sistema.

Toda la comunicación entre los componentes lógicamente agrupados se hace a través de un distribuidor 201, el motor de mensajería extendido en el sistema. Si un componente desea enviar datos y/o una notificación de evento a uno o más otros componente(s), la notificación de datos/eventos se envía en la forma de un mensaje al distribuidor 209, que dirige ese mensaje a todos los componentes previamente suscritos a tal mensaje.

El componente de administrador de contenido 203 es la raíz de la interfase de usuario de la arquitectura ilustrada 200, que proporciona una conexión de trayectoria de datos entre la capa(s) de presentación 204 y 205 y el resto del sistema 100. El administrador de contenido 203 conoce el lenguaje de mensajes de sistema, interpreta datos entrantes, y construye el contenido para uno o más componente(s) de capa de presentación para presentación de acuerdo con los datos recibidos desde el resto del sistema en la trayectoria de datos "hacia adelante" ilustrada en la Figura 2A (la trayectoria de propagación de evento o mensaje desde el resto del sistema en la presentación 104). Diferentes actividades en el sistema resultarán en cambios al contenido de interfase de usuario, con un evento activando el cambio del contenido que se propaga desde algún subsistema como un mensaje a través del distribuidor 209 al administrador de contenido 203, y el administrador de contenido 203 determinando qué necesita hacerse con el contenido de presentación de interfase de usuario en una respuesta a ese evento. Por ejemplo, cuando se prepara un producto y está listo, el sistema de suministro de producto 206 (o, alternativamente, el componente de "Gabinete" descrito anteriormente) envía un mensaje de "Suministrado" al administrador de contenido 203. El administrador de contenido entonces determina (como se describe a continuación) que medios presentar con el fin de mostrar al usuario que el producto está listo, incitando al usuario a remover el producto del puerto de suministro 102.

Cuando un usuario hace alguna entrada a un dispositivo de interacción de usuario, el administrador de contenido 203 recibe y procesa un mensaje desde un componente de capa de presentación y, si se necesita, envía el mensaje apropiado al resto del sistema a través de la trayectoria de datos "hacia atrás" ¡lustrada en la Figura 2B (la trayectoria de preparación de datos desde la entrada de usuario hacia el "resto del sistema"). El cliente juega un papel activo en la operación de la máquina expendedora, de manera que cuando un cliente selecciona un producto disponible (al presionar una tecla/botón, interruptor o una porción de una pantalla táctil), la capa de presentación enviará un mensaje "hacia atrás" al administrador de contenido con la información que identifica la acción necesaria en respuesta al botón presionado. Después el administrador de contenido procesará el mensaje recibido y enviará un mensaje al resto del sistema con la información sobre la selección del usuario y/o cambia su estado interno para reflejar la entrada del usuario. El administrador de contenido sirve como un muro contra incendios efectivo, previniendo que las capas de presentación envíen mensajes inesperados directamente al resto del sistema. El grupo limitado de mensajes permitidos y las reglas de su composición se definen por el desarrollador de sistema y se colocan en el Archivo de Configuración de Comunicador de Sistema, un archivo de configuración que controla el componente de Comunicador de Sistema del Administrador de Contenido, descrito en detalle adicional a continuación.

Cada capa de presentación es un procesador de presentación de medios y un aceptador de entrada de usuario para el dispositivo(s) de interacción de usuario específico. En la modalidad ilustrativa, la capa de presentación 204 para la interfase de usuario 103 es Adobe Flash Player, que es un procesador de interfase de usuario efectivo para muchos dispositivos que manejan gráficos de vector, corrientes de animación y video y soporta guión (ActionScript) y soporta objetos de pantalla de entrada de usuario. Otro ejemplo de una capa de presentación posible para la Arquitectura ATLAS es un navegador web (por ejemplo, Mozilla Firefox, Microsoft Internet Explorer o Apple Safari), que proporciona un grupo similar de presentación de contenido y funcionalidad de interacción de usuario.

De esa forma, cada capa de presentación tiene dos f unciones mayores: presentar contenido y aceptar entrada de usuario. La presentación de contenido inicia al recibir un "paquete de contenido" del administrador de contenido. La aceptación de entrada de usuario ocurre cuando un usuario presiona una tecla o hace alguna otra interacción de dispositivo de entrada de usuario, y resulta en un mensaje "hacia atrás" enviado de regreso desde una capa de presentación hacia el administrador de contenido. Una capa de presentación se implementa usualmente como un par de procesador y adaptador, en donde el procesador es una aplicación lista para usar (por ejemplo, Flash Player), y el adaptador es una aplicación especial que permite que un procesador de capa de presentación se comunique a través de la mensajería de Distribuidor. Sin embargo, la capa de presentación puede implementarse como una aplicación individual al unir tanto la funcionalidad de adaptador como de procesador dentro de un solo ejecutable: La Figura 3 es un diagrama de bloques más detallado de un administrador de contenido dentro de la arquitectura de las Figuras 2A y 2B, que muestra los componentes internos, trayectorias de comunicación internas, y la forma en la cual el administrador de contenido 203 se comunica con el resto del sistema. Cuando el sistema 100 (por algunos de los componentes) desea cambiar o actualizar el contenido en cualquier porción de la presentación de interfase de usuario 104, se envía un mensaje al administrador de contenido 203 (en una trayectoria de datos hacia adelante que fluye de izquierda a derecha en la Figura 3). El administrador de contenido 203 recibe mensajes entrantes desde el distribuidor 209 desde el resto del sistema por un componente de configuración configurable, el comunicador de sistema 301. El comunicador de sistema 301 analiza mensajes recibidos y después envía datos y/o notificaciones de evento a una memoria caché de modelo 302, el componente responsable de rastrear el estado del sistema 100 y notificar a otros componentes de administrador de contenido de cambios de estado. Un componente de máquina de estado 303 controla e I estado de la interfase de usuario (por ejemplo, estado inactivo, selección de producto, preparación de producto, pantalla de gracias, etc.). Un trazador 304 realiza trazado de eventos y datos desde el estado de sistema al contenido presentado en la presentación de interfase de usuario. Un servicio de lista de producto 305, que es un componente específico de máquina expendedora del administrador de contenido 203, mantiene el catálogo de producto, un grupo de productos que la máquina expendedora tiene disponible para ventas, con el texto y medios apropiados y dispuesto en pantallas de selección para un usuario. El comunicador de sistema 301 también proporciona acceso a las capas dé presentación (en una trayectoria de datos de inversa que fluye de derecha a izquierda en la Figura 3), que presenta el contenido en los dispositivos de presentación y recibe la entrada de usuario como se describió anteriormente. Cuando la entrada de usuario aparece, el comunicador de sistema 301 recibe un mensaje "hacia atrás" desde la capa de presentación respectiva y coloca los datos recibidos dentro de la memoria caché de modelo 302, que entonces notifica al resto de los componentes de administrador de contenido de la recepción de datos. Cualquiera de los componentes afectados procesa esos datos y actualiza el contenido de presentación de interfase de usuario y/o envía un m ensaje al resto del sistema 100.

Brevemente mencionada, la memoria caché de modelo 302 es un reflejo del estado de sistema actual, y representa el Modelo en el patrón estándar de Controlador de Vista de Modelo (MVC) para desarrollo de interfase de usuario, que constituye todos los datos que representan el sistema con el cual interactúa un usuario. Ya que el Modelo no está directamente disponible en la arquitectura 200, el estado de modelo se "guarda en memoria caché". El sistema 100 se comunica con el administrador de contenido 203 por mensajes, cada mensaje transportando una actualización de evento o de datos, o ambos. Para permitir suministrar cada dato necesario para llenar una pantalla de ¡nterfase de usuario, el administrador de contenido almacena el último valor para cada campo de información obtenido del sistema, es decir, "guarda en memoria caché" esos valores dentro de la memoria caché de modelo. La memoria caché de modelo 302 se implementa como almacenamiento de entradas de datos nombradas ("variables") cada una teniendo un nombre y valor, ambas son secuencias de texto (preferiblemente secuencias de texto de Unicódigo para que el sistema esté listo para internacionalización y localización). Cuando es necesario un valor de algunos datos de la memoria caché de modelo (tal como valor de crédito de estado de venta actual) ese valor se solicita por nombre variable, que sirve como un "tecla". Un ejemplo de contenido de memoria caché de modelo se proporciona en el Cuadro I a continuación: Cuadro I Se utilizan valores de variable de memoria caché de modelo para almacenar datos textuales y datos numéricos (en forma textual), y además pueden utilizarse para almacenar cualquier formato de datos, incluyendo XML (que se utiliza para transportar datos complejos). Incluso pueden almacenarse datos binarios en una variable de memoria caché de modelo (si es necesario) utilizando HEX de cualquier codificación binario a texto. Como un almacenamiento de variable de propósito general, la memoria caché de modelo 302 también se utiliza para almacenar datos de tránsito dentro del administrador de contenidos 203, tales como mensajes de entrada de usuario y los datos actuales de máquina de estado. La memoria caché de modelo 302 es adecuada para almacenar grandes cantidades de datos, limitadas únicamente por memoria de sistema disponible, aunque el uso no económico del espacio de almacenamiento puede comprometer al desempeño de sistema.

Otra función de memoria caché de modelo significativa es la notificación. Muchos componentes de administrador de contenido desean saber si se cambian los datos de memoria caché de modelo. Por ejemplo, el contenido de presentación de interfase de usuario puede actualizarse cuando un crédito establecido cambia. La memoria caché de modelo 302 de esa forma emite notificaciones para todos los componentes interesados para cada actualización variable, para que la memoria caché de modelo no únicamente rastree el estado del sistema sino también propague eventos de actualizaciones, que son controladores primarios de la actualización de pantalla de interfase de usuario. Observar que la notificación de actualización se emite para cada caso de actualización, que incluye casos de actualización en donde la actualización transporta el mismo valor como ya se almacenó en el valor de variable para que el valor de variable real no cambie. Esto propaga eventos claros sin ningún cambio de datos, y viceversa, para no perder el evento de actualización incluso si no se cambiaron los datos.

Un desarrollador de contenido utiliza variables de memoria caché de modelo al hacer referencia a las variables en el archivo de manifiesto de contenido 306, como fuentes de datos para llenado de interfase de usuario y, de forma más importante, como activadores de un diseño/actualización de pantalla. Los mecanismos de uso variable en el archivo de manifiesto (no mostrados en la Figura 3) se describen a continuación. Las variables de memoria caché de modelo se dividen en varias categorías, por "propietarios", un componente de administrador de contenido 203 que establece valores de estas variables. Las categorías de variable son: variables pertenecientes al administrador de contenido, variables de sistema, variables de usuario, y variables internas. Las variables del administrador de contenido son independientes de sistema y no se ven afectadas por cualquier archivo de configuración y se enlistan en el Cuadro II a continuación: Cuadro II Las variables de sistema son variables que representan el estado de sistema; su manejo es la función primaria de la memoria caché de modelo 302. Cada variable de sistema recibe una propiedad particular del sistema con un mensaje de actualización-notificación entrante desde el sistema. Ejemplos de variables de sistema pueden ser un valor de crédito, un porcentaje de progreso de una preparación de producto, una temperatura de un producto, y así sucesivamente. Las variables de sistema son dependientes de sistema, representando los datos que se reciben desde el sistema de acuerdo con un diccionario de mensaje-un grupo específico de sistema de mensajes. Se definen nombres de variable de sistema por el archivo de configuración de comunicador de sistema 306, un archivo de configuración que ordena al administrador de contenido 203 sobre cómo interpretar mensajes del resto del sistema. Diferentes modalidades de las máquinas de arquitectura 200 pueden tener diferentes grupos de variables de sistema, así un desarrollador de contenido debe pedir al desarrollador de sistema una lista de variables de sistema actuales y su significado. Las variables de sistema utilizadas en la modalidad de máquina expendedora ilustrativas se enlistan en el Cuadro III a continuación: Cuadro III Para cualquier aplicación particular, puede necesitar analizarse dos archivos que definen comunicación de sistema a administrador de contenido para obtener nombres y significados de las variables de sistema: el archivo de diccionario de mensaje (no mostrado en la Figura 3), que es la lista de todos los mensajes que van a través de un sistema particular, y el archivo de configuración de comunicador de sistema 306, que define qué mensajes se aceptan por el administrador de contenido y qué campo de estos mensajes aceptados se utilizan en que forma (usualmente los campos se colocan en variables de memoria caché de modelo). Estos dos archivos se utilizan por el componente de comunicador de sistema 301 del administrador de contenido 203 y se describen en detalle adicional a continuación.

Las variables de usuario son variables utilizadas por el desarrollador de contenido en el archivo de manifiesto. El archivo de manifiesto se especifica al inicio del administrador de contenido 203 por el argumento de línea de comando "-m". Un desarrollador de contenido es libre de introducir variables de gsuario dentro del archivo de manifiesto, y establecer y utilizar sus valores. Las variables de usuario pueden tener cualquiera de los nombres posibles para no tener conflicto con otros nombres de variable de memoria caché de modelo. Un ejemplo típico es la variable de "lenguaje", que representa el lenguaje de interfase de usuario actualmente seleccionado y puede tener valores de "EN" (Inglés), "FR" (Francés) "RU" (Ruso), etc. Ya que un desarrollador de contenido tiene acceso a escritura directo a la memoria caché de modelo 302 a través del archivo de manifiesto, la evasión de la colisión de nombre de variable de memoria caché de modelo es importante. Escribir erróneamente en una variable de memoria caché de modelo ya utilizada tendrá resultados impredecibles debido a que los componentes del administrador de contenido utilizan variables de memoria caché de modelo y asumen que tienen valores correctos y momentos correctos de actualización. Los archivos de sistema (tales como el diccionario de mensaje, el archivo de configuración de comunicador de sistema 306, el archivo de configuración de máquina de estado, etc.) pueden no ser accesibles al desarrollador de contenido.

La máquina de estado 303 controla el estado de interfase de usuario y, conceptualmente, es un grupo de estados, un estado actual, y un grupo de reglas que definen transiciones de estado a estado en una respuesta a señales de entrada. La implementación de máquina de estado dentro del administrador d e contenido 203 sirve como asincrónica, impulsada por evento, completamente configurable a través de un archivo de configuración (que define todos los estados y transiciones permitidas, posiblemente condicionales, entre estados). La salida de máquina de estado es su estado puro, tomando la entrada del componente de memoria caché de modelo 302 del administrador de contenido 203 para eventos entrantes y datos utilizados para calcular condiciones de transición de estado.

La Figura 4A ilustra un diagrama de estado para una implementación simplificada de la máquina de estado en la Figura 2. Después que se inicia una máquina expendedora, va a un estado "Inactivo" hasta que un cliente inicia una interacción con la máquina, en cuyo momento la máquina pasa a un estado de "Selección de Producto". Una vez que el cliente ha seleccionado y pagado un producto, la máquina va a un estado de Preparación de Producto" hasta que se alcanza un estado de "Producto está Listo", en cuyo momento la máquina incita al usuario a tomar el producto. Después que se remueve el producto, la máquina presenta "Gracias" por un momento, y entonces regresa al Estado "Inactivo". De esa forma, la máquina de estado ilustrada por la Figura 4A tiene estados de "Inactivo", "Selección de Producto", "Preparación de Producto", "Producto está Listo" y "Gracias", y un grupo de reglas bien definidas de transición de estado a estado por ciertos eventos, proporcionando ciertas condiciones se satisface como se muestra en la flecha de transición.

La im plementación de máquina de estado dentro del administrador de contenido 203 funciona de acuerdo con las reglas de máquina de estado representadas en forma legible por máquina y colocadas en un archivo de configuración XML: el archivo de configuración de máquina de estado (no mostrado en las Figura 2 y 3). La sintaxis del archivo de configuración de máquina de estado representa los mismos estados, transiciones y reglas como un diagrama de estado, pero en forma textual, con cada estado definido como un elemento XML, conteniendo e lementos anidados para cada transición de estado a estado, opcionalmente equipado con condiciones requeridas para que o curra la transición. De esa forma el contenido puede enviar una máquina en estado original o en actualización a un desarrollador de sistema en forma de XML directa. La sintaxis XML de la máquina de estado ilustrada en la Figura 4A es como a continuación: <?xml versión = "l .0" codificación = "utf-8"?> <ReglasdeMáquinadeEstado Estadoinicial = "lnactivo"> <nombre de estado = "lnactivo"> <evento de transición = "acción de usuario estadoobjetivo = "Selección de Producto"/> </estado> <nombre de estado = "Selección de Producto"> <evento de transición = "se selecciona producto estadoobjetivo="Preparación de Producto" > <condición dinero = "suficiente" /> </transición> </estado> <nombre de estado = "Preparación de Producto"> <evento de transición = "preparación completa" estadoobjetivo = "Producto está Listo"/> </estado> <nombre de estado = " Producto está Listo"> <evento de transición = "producto removido" estadoobjetivo = "Gracias"/> </estado> <nombre de estado = "Gracias"> <transición caducado = "10" estadoobjetivo = "lnactivo"/> </estado> </ReglasdeMáquinadeEstado> <?xml...> es un encabezado de archivo XML estándar en codificación de archivo de Unicódigo de formato de transformación UCS de 8 bits (UTF-8), necesario por razones de internacionalización y localización y particularmente para escribir un texto en diferentes lenguajes. <Reglas de máquina de estado... > es el elemento de raíz del archivo de configuración XML de máquina de estado, con el atributo "estado inicial" del elemento de raíz que establece el estado inicial de máquina de estado a "inactivo"; el elemento <estado...> define las reglas para un estado particular de la máquina de estado, un estado llamado "Inactivo" en este caso; elementos hijo del elemento <estado> definen posibles transacciones desde este estado; el elemento <transición... > denota una posible transición del estado actual a un estado objetivo definido por "estado objetivo" de atributo, en donde la transición se lleva a cabo cuando ocurre un evento definido por el atributo "evento"; el elemento de <condición ... > establece una condición que debe satisfacerse para que ocurra la transición, con el atributo de dinero = "suficiente" que significa que el dinero variable de modelo debe tener el valor de "suficiente" para que ocurra esa transición. Junto con los eventos entrantes externos, otra fuente de las transiciones de máquina de estado se caduca, generada por el procesador de máquina de estado cuando la Máquina de Estado ha estado en un estado especificado por una cantidad de tiempo especificada. Cuando la máquina de estado persiste en un estado con el grupo agotado por el periodo de tiempo especificado, la regla de agotado se activa, y la máquina de estado ejecuta la transición especificada por esta regla (si cualquiera de las condiciones especificadas para esta transición están presentes y se satisfacen).

La Figura 4B ilustra un diagrama de estado para una implementación realista de la máquina de estado en la Figura 2. La sintaxis XML de la máquina de estado ilustrada por la Figura 4B es como sigue: <?xml versión = "1.0" codificación = "UTF-8"?> <ReglasdeMáquinadeEstado Estadoinicial = "Arranque de s¡stema"> <nombre de estado = "Arranque de sistema"> <evento de transición = "SYS. Progreso de Arranque" estadoobjetivo = "Arranque de sistema"/> <evento de trans¡ción = "Configuración. CatálogodeProducto" estadoobjet¡vo = "lnactivo"/> <evento de transición = "Venta . Error Fatal" estadoobjetivo = "FueradeSer icio"/> </estado> <nombre de estado = "lnact¡vo"> <evento de transición = "Dinero. Crédito" estado objet i vo = "Selecc¡óndeProducto"> <condición mcnombre = "crédito" valor="A[1 -9] [0-9]*" do = "regexp"/> </trans¡c¡ón> <evento de trans¡c¡ón = "UI.GolpedePantalla" estadoobjet¡vo = "Selecc¡óndeProducto" /> <evento de transic¡ón = "Configurac¡ón. CatálogodeProducto" estadoobjet¡vo = " Inactivo "/> <evento de transición = "Venta. Error Fatal" estado objetivo = "FueradeServicio"/> </estado> < nombre de estado = "SeleccióndeProducto"> <evento de transición = "Configuración. CatálogodeProducto" estadoobjetivo = "PrecioCambiado"/> <evento de transición = "UI.SuministrarCanasta" estadoobjetivo = "SuministrodeProducto"> <condición mcnombre = "total" valor = "A[1 -9] [0-9]*" do = "regexp"/> </trans¡ción> <evento de transición = "Venta. Cancel" estadoobjetivo = " Gracias "> <condición mcnombre = "crédito" valor=""[1 -9] [0-9]*" do = "regexp'7> </transición> <evento de transición ="Venta. Cancelar" estadoobjetivo = " Gracias "> <condición mcnombre = "total" valor="A[1-9] [0-9]*" do = "regexp"/> </transición> <evento de transición = "Venta. AgregaralaCanastaFallido" estadoobjet¡vo = "ProductoNoValidado"/> <transición caducado = "120" estadoobjetivo = "lnactivo"> <condición mcnombre = "Crédito" valor="0'7> </transición> <evento de transición = "Venta. ErrorFatal" estadoobjetivo = "FueradeSer icio"/> <evento de transición = "Venta.SinErrorFatal" estadoobjetivo = "SinErrorFatal"/> </estado> <nombre de estado = "ProductoNoValidado"> <transición caducado = "10" estadoobjetivo = "SeleccióndeProducto"/> </estado> <nombre de estado = "Sum¡nistrodeProducto"> <evento de transición = "Venta. IniciodeSuministro" estadoobjetivo = " SuministrodeProducto"/> <evento de transición = "Venta. VentaCompleta" estado objetivo = "Gracias"/> <evento de transición = "Venta. ErrorFatal" estadoobjet¡vo = "FueradeSer icio"/> <evento de transición = "Venta.SinErrorFatal" estadoobjetivo = "S i n ErrorFatal" /> </estado> <nombre de estado = "SuministrodeProducto"> <evento de transición = "Venta. ProgresodeSuministro estadoobjetivo = " SuministrodeProducto" /> <evento de transición = "Venta. Suministrado" estadoobjetivo = " ProductoListo" /> <evento de transición = "Venta. ErrorFatal" estadoobjetivo = "FueradeServ¡cio" /> <evento de transición = "Venta.SinErrorFatal" estado objetivo = "SinErrorFatal'7> </estado> <nombre de estado = "ProductoListo"> <evento de transición = "Venta. ProductoRemovido" estadoobjetivo = " Sum¡nistrodeProducto'7> <evento de trans¡ción = "Venta. ErrorFatal" estadoobjet¡vo = "FueradeServic¡o"/> </estado> <nombre de estado = "Gracias"> <transición caducado = "10" estado objet¡vo = "SeleccióndeProducto" /> <evento de trans¡ción = "UI.GolpedePantalla" estadoobjetivo = "SeleccióndeProducto"/> <evento de trans¡ción = "D¡nero. Crédito" estadoobjet¡vo = "SeleccióndeProducto"> <condición mcnombre = "crédito" valor="0" do = "noteq"/> </transición> <evento de transición = "Venta. ErrorFatal" estadoobjetivo = "FueradeSer icio'7> </estado> <nombre de estado = "FueradeServicio"> <evento de transic¡ón = "SYS . ProgresodeArranque" estadoobjetivo = "ArranquedeS¡stema"/> </estado> <nombre de estado = "SinErrorFatal"> <transición caducado = "10" estadoobjet¡vo="SeleccióndeProducto"/> </estado> <nombre de estado = "PrecioCambiado"> <transic¡ón caducado = "1 O" estadoobjetivo = "SeleccióndeProducto"/> <evento de transición = "Dinero Crédito" estadoobjetivo = "SeleccióndeProducto"/> </estado> <evento de transición = "Venta. ErrorFatal" estadoobjetivo = "FueradeServicio"/> </ReglasdeMáquinadeEstado> El trazador 304 es el componente de administrador de contenido que realiza dos operaciones de trazado, trazado de evento y trazado de datos, del sistema de usuario, ambos controlados por un desarrollador de contenido por reglas definidas en el archivo de manifiesto de contenido. Las operaciones de trazado realizadas por el trazador 304 dirigen la información del sistema a la presentación de interfase de usuario 104. "Trazado de evento" transporta la transferencia de eventos o del momento de cambio de datos, y el "trazado de datos" realiza la transferencia de datos. En otras palabras, el trazador 304 es el procesador de flujo de evento y de datos controlado por el archivo de manifiesto.

El trazado es el procedimiento de conversión de datos impulsados por el sistema en una forma aceptable por usuario. El trazador 304 es responsable de la "decoración" de los datos incompletos que vienen del sistema. Los datos que vienen del sistema contienen campos de datos incompletos tales como un valor de crédito, porcentaje de progreso de procesamiento, o una temperatura, pero la información que va desde el sistema pierde datos de contenido de interfase de usuario, tales como imágenes, sonidos, animaciones, video, y texto localizado. El sistema envía eventos y actualizaciones de datos en una forma específica de máquina, como mensajes que contienen un nombre del evento, tales como "Venta completa" o "Suministro iniciado", o una actualización de datos, en una forma de mensajes, como "Temperatura" con carga útil de datos de "98", que significa que la temperatura de producto está actualmente a 98°C. La tarea del trazador 304 es convertir estos datos en una forma de directivas de capas de presentación, que permite que una capa de presentación presente los datos en el formato legible por usuario, apropiadamente visualizado, internacionalizado y localizado, y adaptándose al concepto de diseño artístico de interfase de usuario. La tarea del subsistema de interfase de usuario 201 de la arquitectura 200 es convertir datos incompletos del sistema en forma aceptable por usuario y conveniente de usuario y (entretenimiento de usuario). Tal "decoración" se hace e n su mayoría por el componente de trazador 304, dirigido por el archivo de manifiesto proporcionado por un creador de contenido.

Existen tres tipos de directivas de manifiesto: directivas de administrador de contenido (directivas CM), directivas de trazo de datos, y directivas de capas de presentación (directivas PL). Las directivas de administrador de contenido únicamente se ejecutan por el administrador de contenido. Las directivas de trazado de datos se pre-procesan por el administrador de contenido 203 y luego se ejecutan por la capa de presentación. Las directivas de capa de presentación se transfieren a la capa de presentación sin cambiar, y se ejecutan por la capa(s) de presentación. " Cuando el estado del sistema 100 cambia, el sistema notifica al administrar de contenido 203 que un evento ocurrió o de su cambio de datos de estado por un mensaje enviado a través del distribuidor 209. Por la recepción de tal actualización, el evento recibido y/o los datos actualizados se reflejan en la memoria caché de modelo 302, y la memoria caché m odelo 300 a su vez notifica al trazador 304 del cambio de estado (actualización) del sistema. El trazador 304 inicia sus operaciones de trazado de evento en respuesta a la señal recibida desde la memoria caché de modelo 302.

El resultado de procedimiento de trazado es el contenido de presentación de inferíase de usuario que se envía a un módulo de raíz de la capa de presentación en una forma aceptable por la capa de presentación. De esa forma el resultado del procedimiento de trazado, y la salida del trazador 304, es una transacción de capa de presentación, que son datos XML que contienen los directivos exactos para la capa de presentación de qué medios/aplicación cargar/descargar en que objetivo/capa y que datos enviar a cada medio/aplicación en su trayectoria objetivo. Una transacción de capa de presentación se genera por el trazador 304 para cada operación de trazado de evento individual, y contiene el mismo contenido que una acción de regla pero con directivas de trazado de datos sustituidas por los datos reales.

Los desabolladores de contenido controlan la operación del trazador 304 por medio del archivo de manifiesto, al definir reglas de trazado de evento y directivas de trazado de datos ahí. El desarrollador de contenido también especifica directivas de capa de presentación dentro de I as acciones de regla, pero estas d irectivas comanda capa(s) de presentación 204, 205, no el administrador de contenido 203.

El archivo de manifiesto es un archivo XML que define operaciones de interfase de usuario en la respuesta a eventos de sistema y actualizaciones de datos. El archivo de manifiesto d efine reglas de trazado de evento y directivas de trazado de datos procesados por el mismo administrador de contenido, y directivas de capa de presentación ejecutadas por el módulo de raíz de la capa de presentación. La sintaxis del archivo de manifiesto se divide por dos partes: una sintaxis impulsada por administrador de contenido de reglas y directivas de trazado de datos, y una sintaxis impulsada por capa de presentación de directivas de capa de presentación dependientes de la implementación de capa de presentación particular. El archivo de manifiesto sirve como una raíz de un paquete de contenido, un paquete de archivos que forman el diseño de interfase de usuario hecho a la medida para un sistema de acuerdo con la presente descripción.

Cada regla de manifiesto tiene una condición asociada que, cuando se satisface, resulta en que la regla se vuelva "activa" y viceversa, (es decir, si, después de alguna actualización de datos, una condición de reglas se vuelve f alsa, la regla pasa a un estado "inactivo"). Cuando una regla se vuelve activa, el trazador 304 ejecuta la acción de entrada para la regla, y cuando la regla se vuelve inactiva, el trazador 304 ejecuta la acción de salida para la regla.

Después de recibir una notificación de actualización, el trazador 304 inmediatamente busca el manifiesto para las reglas que coinciden con la actualización recibida. Si se encuentran reglas coincidentes, el trazador 304 toma acciones definidas por estas reglas, que componen una transacción de capa de presentación que incluye un grupo de datos para una o más capa(s) de presentación para presentar en la pantalla del usuario. El mecanismo de trazado de evento es el controlador primario del llenado de contenido de presentación de interfase de usuario, cambio y actualización. Cada actualización a la presentación de interfase de usuario es un resultado del procedimiento de trazado de evento, y la presentación de interfase de usuario se actualiza cuando y únicamente cuando el manifiesto específica una regla para tal evento. De forma inversa, cuando debe presentarse el hecho de un cambio de datos en la presentación de interfase de usuario, debe introducirse una regla para este evento en el manifiesto que define el contenido para colocarse en la presentación con el fin de reflejar la actualización.

El trazado de datos toma lugar cuando se ejecuta una acción de entrada o salida de una regla de manifiesto. Cuando una actualización de datos de sistema particular cambia un estado de actividad de la regla de manifiesto particular, el trazador 304 ejecuta la acción de entrada o salida definida por esta regla. Una acción de regla contiene un grupo de directivas de capa de presentación mezcladas con directivas de "trazado de datos" que ordenan al trazador 304 insertar los datos de sistema actuales desde la memoria caché de modelo 302 en el contenido que se compone.

El catálogo de producto es el grupo de datos relacionados con la carga actual de productos dentro de una máquina expendedora y su lugar es la inferíase de usuario. El catálogo de producto está separado del archivo de manifiesto para permitir que un operador de máquina expendedora altere la carga de máquina mientras mantiene el diseño de interfase de usuario estable y sin cambios, para excluir costo y retos relacionados con adaptación de diseño de interfase de usuario por cada grupo de máquinas de cambio de productos. El catálogo de producto contiene datos para cada producto, que representan una identificación de producto, un nombre de producto (para cada lenguaje en el cual opera la interfase de usuario), texto descriptivo de producto (para cada lenguaje), imágenes de producto, el precio de producto y opciones de producto, con sus identificadores, imágenes, texto y precio. Además, el catálogo de producto especifica el lugar de cada uno de los productos en el catálogo (página y posición en la página) como parte de la organización y compaginación de catálogo. El catálogo de producto contiene una entrada para cada producto que se carga en la máquina expendedora, que incluye un nombre de producto y texto descriptivo/promocional (en todos los lenguajes soportados), imágenes de producto por cada módulo de presentación (activo/inactivo, pequeño/mediano/grande, estático/animado), y también campos específicos de implementación . El catálogo de producto también contiene la disposición de producto por página de selección, y asocia una pantalla de selección de acción para cada uno de los productos en donde se requiere la selección de opción.

El servicio de lista de producto 305 es un bloque funcional del administrador de contenido 203 que procesa el catálogo de producto al componer contenido requerido para presentar pantallas de selección de producto, permitiendo a un usuario navegar el catálogo para seleccionar productos y elegir opciones de producto individuales, y así sucesivamente. El servicio de lista de producto 305 es una funcionalidad específica de máquina expendedora dentro del administrador de contenido. Las aplicaciones diferentes a una máquina expendedora pueden no utilizar el componente de servicio de lista de producto 305 del todo, o pueden emplear el catálogo de producto y el servicio de lista de producto para otros propósitos tales como mantener una lista de artículos seleccionabas por usuario organizada en un catálogo de múltiples páginas. El estado del catálogo de producto cambia durante una operación de máquina expendedora bajo el control del componente de servicio de suministro de producto (PDS) 206 de la arquitectura 200. El PDS 206 controla la disponibilidad y precio de producto y otros aspectos del catálogo de producto, mientras el trabajo del administrador de contenido es "decoración" de catálogo de producto es decir, asociación de medios y texto localizado para cada producto/opción individual, asociación de una página de producto a las plantillas de página y asi sucesivamente.

Los datos de catálogo de producto actuales se envían por el componente PDS 206 al administrador de contenido 203 en una forma corta, contexto de interfase de usuario faltante tal como archivos de medios, campos de texto internacionalizados, y similares. El servicio de lista de producto realiza la tarea de "decoración" del catálogo de producto al asociar los datos de producto con los medios para presentar en la pantalla de usuario. Otra función del servicio de lista de productos es mantener una "compaginación" del catálogo de producto, la división del catálogo completo en páginas individuales y mantenimiento de navegación de usuario a través de la secuencia de páginas. La decoración del catálogo de producto inicia con cada actualización de catálogo de producto recibida del componente PDS 206. En este procedimiento, el servicio de lista de producto construye una parte dinámica del archivo de manifiesto y envía esos datos al componente de trazador 304 para procesar. La parte dinámica del archivo de manifiesto es responsable de la operación del catálogo de producto y se construye por el componente de servicio de lista de producto utilizando "plantillas" declaradas en el archivo de configuración de servicio de lista de producto.

El comunicador de sistema 301 es el componente de administrador de contenido que facilita toda la comunicación con el resto del sistema. El comunicador de sistema 301 conoce el formato de los mensajes de sistema que fluyen a través del distribuidor 209, interpreta y procesa esos mensajes al utilizar un archivo de definición de mensaje de sistema (archivo XML de Diccionario de Mensaje) y su propio archivo de configuración (archivo de configuración de comunicador de sistema 306). El comunicador de sistema 301 se controla por el archivo de configuración de comunicador de sistema 306, que se es dependiente del sistema y se proporciona por el desarrollador de sistema. Este archivo de configuración enlista todos los mensajes que el administrador de contenido 203 debe procesar, junto con datos que deben extraerse de cada mensaje y en donde el mensaje debe enrutarse dentro del administrador de contenido 203. El archivo de configuración de comunicador de sistema 306 también administra todos los mensajes de salida permitidos y las reglas de su composición.

El documento principal que controla la comunicación del sistema es el diccionario de mensaje, un documento XML que define cada estructura de mensaje y carga de datos. El archivo de configuración de comunicador de sistema 306 depende del diccionario de mensaje ya que se refiere a nombres de mensaje y campos de datos enlistados en el archivo de diccionario de mensaje. Cada mensaje entrante aceptado actualiza el componente de memoria caché de modelo 302 del administrador de contenido 203, llenando variable(s) apropiada con datos actualizados o, si el único sentido del mensaje es un evento, llenando una variable de evento especial con el nombre de evento apropiado. La memoria caché de modelo 302 a su vez notifica al resto de estos componentes de administrador de contenido que ocurrió la actualización, resultando en que el contenido de interfase de usuario se genera y envía a la pantalla de usuario. El llenado tanto del diccionario de mensaje como los archivos de configuración del comunicador de sistema es una responsabilidad del desarrollador de sistema debido a que esos archivos son parte de la lógica de sistema. Un ejemplo de una sintaxis XML de diccionario de mensaje individual es como sigue: <Mensaje Id de Evento = "3" Tema = "Dinero" nombre = "Crédito"> <Descripción> Monetario publicará la cantidad de crédito actual. </Descripción> <Editores> MON </Editores> <Suscriptores> CM, PDS </Suscriptores> <Carga Útil> <Descripción de Artículo = "EI valor de crédito" nombre = "Crédito tipp int'7> </Carga Útil> </Mensaje> Para procesar el mensaje "Crédito", el archivo de configuración de comunicador de sistema 306 contendrá el código: <EntradadeMensaje nombre = "Crédito" mcnomb re = " MáquinadeEstado. acción" mcvalor = " Dinero. Crédito "> <Nombre de Artículo = "Crédito" mcnombre = "crédito"/> </Carga Útil> </EntradadeMensaje> El ejemplo de sintaxis de archivo de configuración de comunicador de sistema mostrado anteriormente ilustra el procesamiento del mensaje "Crédito" por el administrador de contenido. El elemento <Entrada de Mensaje> define un mensaje entrante y toda la acción que tomará el comunicador de sistema con una recepción de mensaje de "Crédito". El atributo nombre = "Crédito" define el nombre del mensaje; nómbreme = "Máquina de Estado. Acción" define la variable de memoria caché de modelo "Máquina de Estado. Acción" para establecerse por la recepción de este mensaje valorado y definido por el atributo mcvalor = "Dinero. Crédito". Esto proporcionará a la máquina de estado un evento de e ntrada del nombre "Dinero. Crédito", debido a la función de la variable de "Máquina de Estado. Acción". El elemento hijo <Articulo> de <Entrada de Mensaje> define el procesamiento de la carga de datos de mensaje, en donde el atributo de nombre = "Crédito" selecciona el campo de datos del mensaje para procesar, y el atributo mcnombre = "crédito" define la variable de memoria caché de modelo objetivo en donde se colocarán los datos de mensaje del campo de datos "Crédito". Observar que en este ejemplo, el valor del crédito puede actualizarse después de que la máquina de estado recibió la notificación de cambio de crédito. Para asegurar el orden correcto de la actualización de datos, el desarrollador de sistema debe elegir el orden de operadores en el archivo de configuración de comunicador de sistema.

La Figura 5 es un diagrama de flujo de alto nivel para un procedimiento para emplear descripciones de lenguaje de marcación para flujo de interfase de cliente dinámica para una interfase de usuario gráfica dentro de una máquina expendedora de bebida preparada de acuerdo con una modalidad de la presente descripción. El archivo de manifiesto de contenido define la composición de contenido de interfase usuario de acuerdo con los cambios en el estado del sistema, y de esa forma puede emplearse junto con elementos de <ReglasMáquinaEstado>, <estado>, <transición> y <condición> para controlar dinámicamente el flujo de las presentaciones de interfase de usuario.

El elemento <ReglasMáquinaEstado> es el elemento de raíz del archivo XML de configuración de máquina de estado. El atributo mandatorio "Estadol nicial" define el nombre de estado inicial, el nombre de estado que será cargado en el inicio de administrador de contenido. Los elementos anidados del elemento <ReglasMáquinaEstado> son elementos <estado>, uno por cada estado. Un ejemplo la sintaxis XML para elementos <ReglasMáquinaEstado> es como sigue: <ReglasMáquinaEstado Estado inicial = "RápidoVerificar"> El elemento <estado> define un estado individual en la máquina de estado 30, incluyendo el nombre de estado y la lista de posibles transacciones de este estado (en donde las transacciones pueden ser condicionales). El atributo de "nombre" mandatorio define el nombre del estado. Los elementos anidados <transición> definen las posibles transiciones de este estado. El elemento <estado> siempre es un elemento hijo de <ReglasMáquinaEstado>. Un ejemplo de sintaxis XML para elementos <estado> es como sigue: <nombre estado = "SelecciónProducto"> El elemento <transición> define una transición individual del estado de máquina de estado. El elemento <transición> siempre es un hijo de primer nivel de un elemento <estado>. Una transición de un estado de máquina de estado puede ser ocasionada por la entrada de un evento de máquina de estado o un retraso. Cada transición puede ser ocasionada solo por una razón. Una transición puede ser condicional si contiene un elemento(s) anidado <condición>. La transición no ocurrirá si no se satisfacen todas sus condiciones. El atributo "evento" define el nombre de evento entrante que activa esta transición. El atributo "retraso" establece el valor de retraso para este estado en milisegundos; la transición ocurrirá cuando este tiempo expira. Múltiples transiciones de retraso pueden ser especificadas par un solo estado. Una transición debe tener uno y únicamente uno de los atributos de "evento" y "retraso", éstos son mutuamente exclusivos para una sola transición. El atributo "estadoobjetivo> mandatorio define el nombre del estado objetivo para esta transición. Un ejemplo de sintaxis XML para elementos <transición> es como sigue: <evento transición = " Cancelar. Vend" estadoobjetivo = " Gracias" > El elemento <condición> define una condición individual para una transición de máquina de estado. El elemento padre debe ser el elemento <transición> que define la transición a la que pertenece esta condición. Todas las condiciones deben ser satisfechas para que ocurra una transición; en otras palabras, si una transición tiene múltiples condiciones, estas condiciones son lógicamente ANDed, y si se desea un O lógico entre condiciones, se deben especificar múltiples transiciones para las condiciones Oed. El atributo "nómbreme" mandatorio especifica el nombre de la variable de modelo-memoria caché, dicho valor será comparado con el valor deseado especificado por el atributo "valor". El atributo "valor" mandatorio especifica el valor deseado con el c ual será c omparado el valor de la variable de modelo-memoria caché especificada por el atributo "nómbreme". El atributo opcional "do" define un nombre de una operación especial que se realiza para verificar esta condición, por ejemplo, expresión regular coincide si do = "regexp" o condición no igual si do = "noteq". Ejemplos de sintaxis XML para los elementos <condición> son como sigue: <condición nombremc = "GuardarEnergía" valor = "1"/> <condición nombremc = "total" valor="A[1 -9][0-9]*" do = "regexp"/> El elemento <condición> es particularmente útil para proporcionar un flujo de interfase de usuario dinámica. De esta manera, por ejemplo, un cliente puede ordenar ya sea un café con leche con cafeína o descafeinado, hecho con leche sin grasa, leche descremada o leche entera. Obviamente, podrían estar disponibles pocas opciones (o requerirse) cuando se ordena un expreso. De esta manera, la selección de una bebida por parte del cliente necesita un flujo diferente de la interacción de cliente para hacer todas las selecciones requisito para un café con leche que la que podría ser requerida para un cliente que ordena un expreso. Así, el elemento <condición> puede incluir un atributo nómbreme de "Producto" y un atributo de valor de "DECAFFE_CAFE_LATTE" para especificar una transición particular de un estado de orden al siguiente, mientras un elemento de transición separado podría especificar una transición de estado diferente para ordenar un expreso.

El procedimiento 500 para emplear descripciones de lenguaje de marcación para flujo de interfase de cliente dinámica ilustrado en la Figura 5 comienza con una ocurrencia de evento. Se hace una determinación por el trazador 304 de si el evento activa una transición de estado (paso 501). Si es así, cualquier <condición> especificada por <transición> se verifica para satisfacción (paso 503). Con base en si se satisface la <condición>, se selección el contenido identificado por el elemento <transición> respectivo para ser procesado por ele trazador 304 y es presentado por la capa de presentación para presentar (paso 504).

La presente descripción permite la adaptación dinámica de flujo para el contenido que se va a presentar en la interfase de cliente dentro de una máquina expendedora utilizando la definición de contenido XML basándose en <condición> especificada en el elemento <transición>. De esta manera, se generan dinámicamente flujos de interfase de usuario, y pueden ser actualizados para adaptar nuevos productos u otros cambios en las ofertas.

Aunque la presente descripción ha sido descrita con modalidades ilustrativas, pueden sugerirse varios cambios y modificaciones para un experto en la técnica. Se pretende que la presente descripción abarque tales cambios y modificaciones como caen dentro del alcance de las reivindicaciones anexas.

Claims (20)

REIVINDICACIONES

1. Un sistema para establecer dinámicamente flujo de interfase de usuario para presentarse en una interfase de cliente de máquina expendedora, que comprende: una presentación 103 configurada para presentar contenido a un cliente; una o más memorias 112 configuradas para almacenar un valor para dos o más variables de transición de Lenguaje de Marcación eXtensible (XML) especificando transiciones desde el primer contenido de interfase de usuario a cualquiera del segundo o tercer contenido de interfase de usuario, por lo menos una de las variables de transición especificando una condición con relación a una selección de cliente; y un controlador 106 configurado para generar actualizaciones para presentar contenido, el controlador seleccionando uno del segundo o tercer contenido de interfase de usuario basándose en si la condición se satisface, en donde, en respuesta a que el controlador selecciona uno del segundo o tercer contenido de interfase de usuario, la presentación muestra contenido de presentación dinámicamente seleccionado del segundo y tercer contenido de interfase de usuario basado en un valor para al menos una variable de transición de XML.

2. El sistema de acuerdo con la reivindicación 1 , en donde el valor de las dos o más variables de transición de XML está asociado con una variables de estado de XML al corresponde el primer contenido de interfase de usuario.

3. El sistema de acuerdo con la reivindicación 2, en donde una selección de cliente determina si la condición está satisfecha.

4. El sistema de acuerdo con la reivindicación 1, en donde la memoria se configura para almacenar el valor de las variables de transición de XML en una memoria caché de modelo.

5. El sistema de acuerdo con la reivindicación 4, en donde el controlador se configura para ejecutar un administrador de contenido para generar datos XML para el contenido de presentación, el administrador de contenido buscando valores para variables de XML referenciados por la condición dentro de una memoria caché de modelo.

6. El sistema de acuerdo con la reivindicación 5, en donde el administrador de contenido incluye la memoria caché de modelo y un trazador que traza datos XML para la presentación de datos de capa presentados para generar el contenido de presentación.

7. El sistema de acuerdo con la reivindicación 5, en donde el administrador de contenido incluye un archivo de configuración que identifica una o más variables que corresponden a la condición.

8. El sistema de acuerdo con la reivindicación 5, en donde el administrador de contenido incluye una máquina de estado que controla un estado del administrador de contenido y transiciones entre estados por el administrador de contenido.

9. Una máquina expendedora que incluye el sistema de la reivindicación 1, la máquina expendedora además comprende: un gabinete que aloja la presentación, la memoria y el controlador; y un sistema de suministro de producto configurado para suministrar productos en respuesta a señales generadas por e¡ controlador basándose en la selección de un cliente dentro de la interfase de usuario.

10. La máquina expendedora de acuerdo con la reivindicación 9, en donde la máquina expendedora está configurada para suministrar bebidas elaboradas.

11. Un método para establecer dinámicamente flujo de interfase de usuario para presentarse en una interfase de cliente de máquina expendedora, que comprende: presentar el contenido a un cliente; almacenar un valor para dos o más variables de transición de Lenguaje de Marcación eXtensible (XML) especificando transiciones desde el primer contenido de interfase de usuario a cualquiera del segundo o tercer contenido de interfase de usuario, por lo menos una de las variables de transición especificando una condición con relación a una selección de cliente; generar actualizaciones para presentar contenido al seleccionar uno del segundo o tercer contenido de interfase de usuario basándose en si la condición se satisface; y presentar el contenido de interfase de usuario seleccionado del segundo o tercer contenido de interfase de usuario, dinámicamente seleccionado basado en un valor para por lo menos una variable de transición de XML.

12. El método de acuerdo con la reivindicación 11, en donde el valor de las dos o más variables de transición de XML está asociado con una variable de estado al cual corresponde el primer contenido de interfase de usuario.

13. El método de acuerdo con la reivindicación 12, en donde una selección de cliente determina si la condición se satisface.

14. El método de acuerdo con la reivindicación 11, que además comprende almacenar el valor de las variables de transición de XML en una memoria caché de modelo.

15. El método de acuerdo con la reivindicación 14, que además comprende ejecutar un administrador de contenido que genera datos XML para el contenido de presentación, el administrador de contenido buscando valores para variables de XML referenciados por la condición dentro de una memoria caché de modelo.

16. El método de acuerdo con la reivindicación 15, que además comprende trazar datos XML a datos de capa de presentación mostrados para generar el contenido de presentación.

17. El método de acuerdo con la reivindicación 15, el cual proporciona un archivo de configuración que identifica una o más variables de XML que corresponden a la condición.

18. El método de acuerdo con la reivindicación 15, en donde el administrador de contenido incluye una máquina de estado que controla un estado del administrador de contenido y transiciones entre estados por el administrador de contenido.

19. Un método de acuerdo con la reivindicación 11, que además comprende: suministrar productos en respuesta a señales generadas con base en selecciones de un cliente dentro de la interfase de cliente.

20. El método de acuerdo con la reivindicación 19, que además comprende suministrar bebidas elaboradas.