MXPA06013782A - Sistema para acceder a una terminal de punto de venta (pos), metodo para descargar y actualizar solicitudes y metodo para ejecutar una operacion electronica usando este sistema - Google Patents

Abstract

La presente invención se refiere a un sistema para acceder a terminales de POS (10), con o sin pads de pin, utilizando un sistema cliente (15) para conectar tal terminal POS (10) a una red comprendida de por lo menos un servidor (30), el sistema que permite a cualquier terminal POS (10) ejecutar solicitudes (25) localizadas en estos servidores, a través de una pluralidad de servidores específicos (20) en un proceso similar al de Internet, asícomo también descargar y actualizar solicitudes de servidores de aplicación (30) y ejecutar operaciones electrónicas en servidores de transacción (35).

Description

SISTEMA PARA ACCEDER A UNA TERMINAL DE PUNTO DE VENTA (POS) , MÉTODO PARA DESCARGAR Y ACTUALIZAR SOLICITUDES Y MÉTODO PARA EJECUTAR UNA OPERACIÓN ELECTRÓNICA USANDO ESTE SISTEMA CAMPO DE LA INVENCIÓN La presente invención se relaciona con un sistema para acceder a un POS y dispositivos pad de pin con el uso de un sistema de cliente conectado por una red de conexión con por lo menos un servidor, así como a un método para actualizar y descargar solicitudes y ejecutar una pluralidad de operaciones con el uso del sistema. ANTECEDENTES DE LA INVENCIÓN Muchas compañías en la industria de las operaciones electrónicas (aseguradoras médicas, tarjetas de valor, de pre-pago, de recarga, de regalo, etc.) constantemente se encuentran en busca de soluciones para mejorar sus servicios y ofrecer algunos nuevos, volviéndolos más competitivos. Antes de la llegada de la presente invención, los usuarios, también conocidos como titulares-de-cuenta, han sido provistos de terminales tecnológicamente limitadas . Con respecto a la portabilidad, cada terminal de Punto-de-Venta, denominada aquí como terminal POS (POS, por sus siglas en inglés) , se compone por su equipo físico y sistema operativo de uso propio. Por consiguiente, las solicitudes requieren ser rescritas y adaptadas para cada modelo de Ref. No. :178053 terminal, en un proceso laborioso y costoso. La aplicación compartida también es insuficiente ya que las terminales POS utilizadas en la red de conexión son capaces solamente de mandar y recibir datos de transacción, sin obtener ventaja de otras instalaciones de la red de conexión tal como los servidores de aplicación. También, debido a que las solicitudes se codificaron-físicamente en las terminales POS (cliente-pesado) , el uso de diferentes solicitudes en la misma máquina es extremadamente difícil, quizás imposible debido a las restricciones de memoria y de desarrollo. De esta manera, cada terminal POS comúnmente se actualiza independientemente en un proceso no automatizado. Recientemente, los fabricantes de terminales POS han acondicionado ambientes heterogéneos y sistemas de actualización remotos para ser aplicados en los procesos de actualización. Sin embargo, tales terminales y sus respectivos sistemas de actualización no eran compatibles uno con otro, requiriendo personal con conocimientos específicos y de mantenimiento para cada sistema y para cada vendedor, de esa forma se duplican esfuerzos y costos. Otro problema existente en el estado previo de la técnica es la necesidad de contar con habilidades de programación avanzadas así como también un conocimiento profundo del ambiente operativo de uso propio de cada fabricante de terminales en el mercado, con respecto a sus especificaciones.

Esto ha resultado en una gran cantidad de costos en personal de capacitación, desarrollo y mantenimiento de solicitudes, y consecuentemente, se limita el alcance de las solicitudes y servicios POS disponibles. OBJETIVO DE LA INVENCIÓN En vista de los inconvenientes indicados anteriormente, la invención proporciona un sistema para acceder a dispositivos POS que transforman redes de conexión POS en redes de conexión de servicio y reducir costos en la implementación y gestión de tales redes de conexión POS . Otro objetivo de la presente invención es proporcionar un sistema con características de mayor portabilidad para las solicitudes en diferentes modelos de terminales POS y de igual forma que permita compartir múltiples solicitudes en el mismo dispositivo POS. Un objetivo adicional de la presente invención es proporcionar un sistema para acceder a dispositivos que permitan a los usuarios ejecutar una aplicación en una terminal POS realizada por diferentes vendedores sin necesidad de personalizarla. Un aspecto importante de la invención es que el sistema está diseñado para complementar el uso de terminales POS estándares, no para competir con las mismas ya que muchas compañías, como VeriFone, Ingenico, Lipman, Sagem, Axalto e Intellect entre otras, ya han desarrollado tales terminales POS desde hace mucho tiempo. SUMARIO DE LA INVENCIÓN La invención se refiere a un sistema cliente para acceder a dispositivos POS y pad de pin, conectando la terminal POS con una red de conexión comprendida por al menos un servidor. El sistema permite a cualquier terminal POS ejecutar solicitudes ubicadas en servidores de aplicación conectados con la red de conexión POS con el uso de páginas y scripts de TCP/IP (Internet, intranets, VPN's, etc.) y, WML (Lenguaje de Marcado Inalámbrico, por sus siglas en inglés) en un proceso similar al Internet . La tecnología de sistema cliente implementa un modelo de cliente-ligero para la arquitectura cliente/servidor. Éste asume que el cliente tiene acceso directo al servidor, en donde reside toda la lógica de programación de gestión. Esta suposición intrínsicamente ofrece dos grandes ventajas para el desarrollo y mantenimiento de programas computacionales . El desarrollo de la aplicación ocurre por completo en el lado del servidor en donde muchas herramientas de alta productividad se encuentran disponibles y la aplicación del lado del cliente puede ser automáticamente actualizada inmediatamente después de una actualización del lado del servidor. El estándar WAP, dirigido a los teléfonos celulares de primera generación, se ocupa de las fallas de comunicación entre el cliente y el servidor. Por lo tanto, el foro WAP ha especificado ciertos mecanismos de información y validación de datos persistentes que reducen notablemente la cantidad de información intercambiada a través de la red de conexión durante la transición de páginas WML (Lenguaje de Marcas Inalámbrico) sucesivas. Las solicitudes de página de pantalla no modificadas también pueden ser evitadas con los mecanismos de caché de protocolos de red HTTP o WSP, aun cuando todavía dependan de un proceso de actualización conducido-por-cliente. De ahí que, la programación de navegación WML junto con las rutinas de validación de datos WMLScript, es muy parecida a un flujo de aplicación POS de pantallas. El WML es un lenguaje de marcado declarativo dirigido para crear pantallas de entrada de datos . Éste ofrece facilidades básicas de tecleo de entrada y selección de opción básica. Tiene un ambiente de variable volátil para almacenar información entre pantallas del mismo flujo de transacción. El WMLScript es un pequeño lenguaje de scripting diseñado para escribir scripts simples de validación de datos. Ni el WML ni el WMLScript proporcionan algún almacenamiento de datos persistentes, tampoco suponen la presencia de algún dispositivo periférico en particular. Por analogía, el concepto de sistema cliente fue llevado a las terminales POS. Particularmente, los programas de navegación WML han mostrado ser el estándar más cercano que ofrecería, la red de y los programas de navegación, beneficios a una terminal POS, y aun todavía careciendo de algunas características claves requeridas por las operaciones electrónicas, tales como impresión de recibos y almacenamiento del historial de transacciones, entre otras. Las terminales POS utilizadas para contar con periféricos, como lectores de tarjetas magnéticas, impresoras térmicas, dispositivos de entrada pad de pin, lectores de tarjetas inteligentes y otros dispositivos seriales que comúnmente son integrados a través de una interface RS-232 estándar tal como un lector de código de barras, un lector de tarjeta sin contacto Mifare y/o lectores de cheques. Además del acceso a dispositivos periféricos, las solicitudes POS demandan algunas características que no están disponibles en las definiciones WML estándar y WMLScript tal como almacenamiento de registros de datos persistentes, formateo de mensajes IS08583, criptografía de información clasificada y un soporte de entrada de datos mejorado, autorización de transacciones EMV y terminales de acceso telefónico, soporte de redes de conexión tipo hereditario SDLC y X.28. Más aun, se ha requerido una política de actualización de caché conducida por servidores con el propósito de establecer los mecanismos de actualización de los servidores de transacciones actuales.

De acuerdo a lo que se describirá en la presente invención, la tecnología de sistema cliente permite el uso de la terminal POS como una plataforma de "bajo costo" para compartir múltiples solicitudes y servicios de valor agregado, lo que convierte "de facto" una red de conexión POS en una red de conexión de servicio. BREVE DESCRIPCIÓN DE LAS FIGURAS La Figura 1 representa una terminal POS conectada a múltiples redes de conexión por medio de diferentes protocolos de comunicación. La Figura 2 representa la personalización individual de cada terminal POS enseñada por el estado previo de la técnica. La Figura 3 representa cómo la invención hace posible la comunicación de cualquier terminal POS personalizada con un servidor de aplicación. La Figura 4 representa un diagrama para subir a la red-descargar y un diagrama de operación electrónica ejecutado por la presente invención. La Figura 5 representa un diagrama con una secuencia de subir a la red-descargar una aplicación de sistema cliente POS. La Figura 6 representa un diagrama con una secuencia de operaciones electrónicas de sistema cliente POS. La Figura 7 representa la arquitectura de un sistema cliente POS y las capas de protocolo.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La presente invención consiste de un sistema para acceder y conectar terminales POS personalizadas 10 con cualquier red de conexión, con el uso de un sistema cliente específico 15. Cuando está en operación, el sistema cliente 15 asume el control de todos los recursos de las terminales POS 10 actuando como un sistema operacional. Permite que cualquier terminal POS 10 ejecute las solicitudes 25 localizadas en los servidores de aplicación 30 conectados a la red de conexión POS con el uso de páginas y scripts TCP/IP (Internet, intranets, VPN's, etc.) y WML (Lenguaje de Marcado Inalámbrico) en un proceso similar al Internet. El sistema cliente 15 también permite a la misma aplicación 25 utilizar múltiples protocolos de comunicación 20 cuando se conecta con diferentes redes de conexión de acceso, lo que hace posible el uso de redes de conexión tipo-herencia TCP/IP (SDLC y X.28, por ejemplo) y otras (GSM, GPRS, CDMA, Eternet, Wi-Fi, Bluetooth, IR, etc.) de acuerdo a lo mostrado en la Figura 1. Además, el sistema cliente 15 también tiene una característica avanzada de guardado-en-caché con el propósito de incrementar la velocidad de intercambio-de-datos, permite incluso operaciones reales fuera de línea. El sistema cliente 15 aun reconoce y controla todos los dispositivos de entrada y salida conectados con el POS, tales como lectores de tarjeta magnética, lectores de tarjetas inteligentes, impresoras, pads de pin, lectores de código de barras, lectores de cheques, teclados, lectores de tarjeta sin contacto Mifare y similares. El acceso a los servidores de aplicación 30 proporcionados por la presente invención hace posible llevar a la red de conexión POS toda la flexibilidad y funcionalidades disponibles en el Internet en cuanto a lo que se refiere a servicios y solicitudes. Como resultado, se reducen los costos de mantenimiento y se agrega flexibilidad al proceso de actualización de solicitudes. Más aun, debido a la posibilidad de utilizar distintas redes de conexión físicas, el proceso de actualización de solicitudes no afecta el tiempo de intercambio de datos promedio, el cual usa las redes de conexión tipo-herencia basadas en protocolos SDLC u otros no-sincrónicos . La Figura 2 muestra cómo se actualizaban usualmente las terminales POS 10. Antes de la presente invención, la aplicación necesitaba ser personalizada, de modo que se debe llevar a cabo cada conexión de puerto para cada modelo de terminal POS. Esta operación se ejecutaba individualmente, requiriendo personal con conocimientos específicos y de mantenimiento para cada sistema de terminal POS. Como se puede ver de la Figura 3 , el ambiente operacional del sistema cliente permite compartir una cantidad arbitraria de solicitudes 25 en solamente una terminal POS 10, utilizando servidores de aplicación 30 conectados a través de la red de conexión, también permite actualizar tales solicitudes de forma remota y automática y en tiempo real . MODALIDAD PREFERIDA DE LA INVENCIÓN Para resolver los problemas descritos anteriormente, la presente invención define extensiones de sistema cliente en red que adaptan un programa de navegación WAP estándar para utilizar los periféricos POS y los amplía para ejecutar operaciones electrónicas . La solución resuelve un problema existente con una nueva tecnología, uniendo la confiabilidad y la velocidad de ejecución de las operaciones IS08583 sobre protocolos tipo-herencia, tales como SDLC y X.28, con la capacidad de conservación y velocidad de desarrollo de las solicitudes en red. Cuando se encuentra en operación, este sistema cliente 15 asume el control de todos los recursos de la terminal POS actuando como el mismo sistema operativo. Éste permite que cualquier terminal POS 10 ejecute solicitudes en red 25 descargadas de los servidores de aplicación 30 conectados con la red de conexión POS con el uso del HTTP sobre la parte superior de TCP/IP, opcionalmente asegurado por el protocolo SSL, en un proceso similar al de Internet. El acceso TCP/IP al servidor de aplicación 30 puede ser realizado con el uso de una simple conexión por acceso telefónico, o una red de conexión de banda ancha como, GPRS, CDMA IX, Ethernet II y WiFi (IEEE 802.11).

Las solicitudes en red POS, que consisten de páginas WML, scripts y otros archivos, ejecutan operaciones electrónicas IS08583 con el servidor de transacciones 35, pretendiendo ser una aplicación C convencional. Las operaciones fluyen tanto sobre conexiones de acceso telefónico SDLC/X.28 como sobre redes de conexión de banda ancha TCP/IP. Este esquema se muestra en la Figura 4. Al observar tal figura, es posible detectar las dos distintas situaciones en el ciclo de vida del sistema cliente POS 15. La primera es cuando se conecta con un servidor de solicitudes 30 para descargar o actualizar la aplicación en red y la segunda cuando esta aplicación 25 se conecta con el servidor de transacciones 35 para ejecutar. una transacción electrónica. La descarga de aplicación puede ser detallada dentro de los siguientes pasos, de conformidad con la Figura 5: 1. El técnico introduce los ajustes de conexión del servidor de solicitudes . 2. El sistema cliente POS 15 se conecta con un Servidor de Acceso Remoto (RAS, por sus siglas en inglés) 45 o se acopla a una red de conexión de banda ancha. 3. El sistema cliente POS 15 recibe una dirección de Protocolo de Internet (IP, por su siglas en inglés) . 4. El sistema cliente POS 15 establece una sesión de Protocolo de Control de Transferencia (TCP, por sus siglas en inglés) con el servidor de solicitudes 30 y envía una solicitud de descarga/actualización de una aplicación, usualmente con un comando HTTP (o HTTPs) POST. 5. El servidor de solicitudes 30 procesa la solicitud. 6. El servidor de solicitudes 30 entra en contacto con el servidor de transacciones 35, pretendiendo ser la terminal POS , con un mensaje IS08583 sobre una conexión TCP/IP. 7. El servidor de transacciones 35 responde al servidor de solicitudes 30 con los ajustes de configuración del sistema cliente POS. 8. El servidor de solicitudes 30 procesa los ajustes de aplicación y construye una versión personalizada de la Aplicación en Red. 9. El servidor de solicitudes 30 envía las páginas, los scripts y archivos de datos de aplicación en red hacia el sistema cliente POS 15. 10. El sistema cliente POS 15 procesa los archivos recibidos . 11. El sistema cliente POS 15 emite un recibo de que se ha completado la descarga/actualización de aplicación al técnico. 12. El sistema cliente POS 15 inicia automáticamente la Aplicación en red. Los pasos 6 y 7 anteriores son opcionales en la solución. En otro escenario de uso, el servidor de solicitudes simplemente puede descargar la aplicación completa sin necesidad del proceso de personalizar la aplicación o de acceder al servidor de transacciones. Además, las operaciones electrónicas ejecutan un proceso más sencillo que puede ser detallado con los siguientes pasos, de acuerdo a lo mostrado en la Figura 6 : 1. El usuario de POS ingresa los datos de transacción. 2. El sistema cliente POS 15 se conecta con un Servidor de Acceso Remoto (RAS) 45 o se enlaza a una red de conexión de banda ancha. 3. El sistema cliente POS 15 recibe acceso a la red de conexión. 4. El sistema cliente POS 15 construye un mensaje IS08583. 5. El sistema cliente POS 15 envía el mensaje IS08583 hacia el servidor de transacciones 35. 6. El servidor de transacciones 35 responde al sistema cliente POS con un mensaje IS08583. 7. El sistema cliente POS 15 procesa el mensaje recibido. 8. El sistema cliente POS 15 emite un recibo de transacción. 1. ARQUITECTURA Y CAPAS DE PROTOCOLO Con el propósito de brindar una mejor definición de la invención, se detalla a continuación la arquitectura del sistema cliente y se divide en capas específicas de acuerdo a lo ilustrado en la Figura 7. 1.1 - Protocolo de Comunicación Con respecto a los protocolos de comunicación, el sistema cliente es capaz de ejecutar operaciones a través de uno de los siguientes protocolos: TCP/IP/PPP, SDLC, X.28, GSM, GPRS, CDMA, Ethernet, Wi-Fi, Bluetooth, IR, etc. La aplicación se encarga de seleccionar cuál protocolo deberá ser usado durante una operación. 1.2 - Protocolo de Seguridad La aplicación de cliente-ligero intercambia datos con el servidor en red a través del protocolo HTTPS, el cual está basado en el estándar SSL 3.0. La capa SSL corre sobre la parte superior del protocolo TCP y proporciona un soporte para un cliente HTTP para establecer una conexión segura con cualquier servidor que cumpla con las especificaciones . El sistema cliente soporta las siguientes sucesiones de cifrado: RSA+RC4+MD5 y RSA+3DES+MD5. Ambas soportan la autenticación certificada de servidor y la autenticación certificada de cliente en el formato PEM. La sucesión de cifrado con 3DES también soporta la autenticación certificada de cliente en el formato PKCS12. 1.3 - Protocolos de Transacción El sistema cliente soporta operaciones HTTP, IS08583 y XML. Las operaciones HTTP están disponibles a través de la etiqueta WML <go> y son soportados tanto el comando GET y POST. Las operaciones IS08583 y XML son ofrecidas por extensiones WMLScript . Todos los protocolos pueden coexistir en la misma aplicación y pueden conectarse a distintos servidores de acuerdo con los ajustes de la aplicación. 1.4 - Motor de Tiempo de Ejecución Después señalizar la interface de usuario, el sistema cliente se mantiene en espera de una interacción de usuario para activar eventos con respecto al motor de tiempo de ejecución. Estos eventos son manejados de acuerdo con las definiciones de página actuales y pueden activar algún procesamiento WMLScript local o invocar otra página que debe ser cargada. Cuando se carga una nueva página WML, es analizada sintácticamente por el analizador sintáctico XML personalizado en WML y se genera un árbol de sintaxis DOM. Entonces el árbol es recorrido y se establecen las estructuras internas de tiempo de ejecución para responder adecuadamente a los siguientes eventos generados por usuario. Tanto las páginas y los scripts se pueden encontrar en el caché del sistema cliente o pueden ser solicitados a un servidor HTTP(S) . 1.5 - Gestionador de Múltiples-Solicitudes (MAM) El gestionador de múltiples-solicitudes del sistema cliente permite residir más de una aplicación y que se ejecuten en el mismo POS. El sistema cliente aisla las solicitudes de otras solicitudes que utilizan diferentes ambientes virtuales de ejecución. Los recursos (WMLs, scripts, archivos de datos y variables) pueden ser creados, leídos o actualizados solamente por la aplicación de propietario. Las solicitudes pueden ser configuradas en la terminal desde una PC, utilizando una comunicación serial, o pueden ser jaladas desde un servidor, sobre TCP/IP. La configuración básica es almacenada en una tabla de solicitudes (TA) en el POS que almacena información acerca del conjunto actual de solicitudes. Funcionalidades Principales MAM: Carga, Actualización o Eliminación Automática de Aplicación- La aplicación maestra, la cual cuenta con derechos privilegiados y usualmente pertenece al propietario de POS, puede solicitar una actualización de la tabla de solicitudes del servidor, con el fin de agregar, borrar o actualizar solicitudes en esa terminal. La misma operación puede ser realizada por un técnico a través del menú de configuración. Ver la funcionalidad de Configuración de Múltiples-Solicitudes descrita a continuación. - Comunicación Entre Solicitudes - El sistema cliente permite la comunicación entre solicitudes . Una Aplicación A puede iniciar una Aplicación B, así como enviar parámetros de una aplicación a otra. Conmutación Entre Solicitudes - El usuario puede conmutar de una aplicación a otra al presionar una tecla de función de programación que llama al menú principal del sistema cliente. De éste, los usuarios pueden seleccionar otras solicitudes . - Validación de Tabla de Aplicación - Una clave es utilizada para verificar si la tabla de aplicación válida actual (TA) pertenece al POS actual. Si la clave no corresponde, es necesaria una nueva TA. - Configuración de Múltiples-Solicitudes - Una interface para el operador POS. A través de esta es posible ejecutar funciones de operación y configuración básica, incluyendo solicitudes de eliminar, crear o actualizar. 1.6 - Librería Estándar de Protocolo EMV Con el propósito de resumir distintas capacidades de terminal del fabricante relacionadas con el protocolo EMV, el sistema cliente supone la existencia de una librería EMV. La librería es, en realidad, una librería de interface PINPad que encapsula todas las interacciones entre el sistema cliente y el kernel del EMV de POS. El sistema cliente ofrece la Librería EMV para la aplicación de cliente-ligero como una librería de extensión WMLScript, denominada PINPadLib. 2. EXTENSIONES DE SISTEMA CLIENTE Ambos lenguajes el WML y el WML Script fueron diseñados originalmente para crear sitios de RED que pueden ser visualizados en programas de navegación WAP, los cuales usualmente se encuentran disponibles en los teléfonos celulares. Con el propósito de satisfacer los requerimientos de una aplicación POS estándar, la invención define algunas extensiones para los lenguajes WML y WML Script. Este conjunto de etiquetas WML, atributos, y funciones script permiten, entre otras características, a las solicitudes POS que se ejecutan sobre el sistema cliente: 1) acceder a dispositivos generalmente disponibles en terminales de POS tales como lectores de tarjetas, impresoras, lectores de códigos de barras, pad de pin, lectores de tarjeta sin contacto Mifare, lectores de cheques, etc.; 2) utilizar múltiples protocolos de comunicación de cuando son conectados a distintas redes de conexión de acceso (SDLC, X.28, TCP/IP, PPP. GPRS, CDMA, WNB, etc..) ; 3) almacenamiento de registro de datos persistentes; 4) acceder al kernel de EMV presente en el sistema operativo de POS; 5) formatear mensajes ISO 8583; 6) criptografía de información clasificada; etc.. La lista completa de extensiones así como su funcionalidad detallada se describe a continuación. 2.1 - Extensiones de Etiqueta para el Lenguaje WML Esta sección presenta las etiquetas nuevas, y sus atributos, proporcionados para un programa de navegación WAP con el propósito de convertirlo en un sistema cliente POS.

Etiqueta Descripción Atributos Interpretados Comienza a emitir frequency times- número de pitidos en la veces en las que el pitido se frecuencia apaga . especificada hasta que se pulsa una tecla Sync (true | false) -beep reproduce el sonido-beep en tiempo de exposición (verdadero) o en tiempo-de- ej ecución (falso) cuando ocurre una redirección. Permite la entrada de datos en páginas que contienen etiquetas <input> posicionando automáticamente el cursor en el siguiente campo cuando se presiona la tecla <enter> . Si el número de líneas entre los dos campos es mayor que el número de form Ninguno líneas sobre la pantalla, el cursor será posicionado en la ultima línea sobre la pantalla. Su función es similar a de la etiqueta, que está definida en el mismo alcance y acepta los mismos atributos y contenido. Hace posible utilizar ñame - Nombre de la variable los dispositivos pad que recibe la entrada de pin en páginas WML. title - texto presentado sobre Puede ser definido en la pantalla del pad de pin el mismo alcance al igual que <input> de maxlength -longitud máxima de la etiqueta. la cadena de entrada Exactamente como el <input> de la type (text | hidden | etiqueta, no puede password) -el texto y la pinpad tener algún contenido . contraseña son 2.2 - Extensiones de Atributos para el Lenguaje WML Esta sección presenta los nuevos atributos, valores y el nuevo comportamiento de atributos estándar, proporcionados para un programa de navegación WAP con el propósito de convertirlo en un sistema cliente POS.

Etiqueta Atributos Descripción ne context= (true false vars) Nuevo valor: El valor "vars" inicializa sólo las variables . autoprint = (true | f lse) Nuevo atributo: Imprime automáticamente los contenidos de tarjeta actuales. dialup = (true | false) Nuevo atributo: Se conecta automáticamente cuando se muestra la tarjeta. hangup= (true | false) Nuevo atributo : Se desconecta automáticamente cuando se muestra la tarjeta persist= (true | false | last |none) Nuevo atributo: Permite que Card un panel sea persistido: True - Creará una copia del archivo actual utilizando el nombre "persist .wml" . El archivo persistido más antiguo será renombrado a "last_persist .wml" False - No se tomará ninguna acción. Last - Renombrará "last_persist .wml" por "persist .wml" . None - Borrará el archivo "persist .wml" por lo que no es usado indeseablemente. onrefresh= hRef Nuevo atributo: un URL para conducirse cuando el evento intrínsico de actualizar es activado onuserevent= hRef Nuevo atributo : un url para conducirse cuando es activado cualquier evento de usuario (barrido de tarjeta, pulsado de tecla, lectura de código de barras) . Usualmente útil para pantallas inactivas . onvalidate = hRef Nuevo atributo : url para conducirse después de cada confirmación de entrada en el flujo de la tarjeta. Localsrc = hRef Nuevo atributo: trayectoria para el archivo local para la operación obtener y colocar. src= hRef Nuevo atributo: trayectoria para el archivo remoto para la operación obtener y colocar. delimiter Nuevo atributo: Delimitador para la lista de campos postfields. User Nuevo atributo: conexión de sesión de usuario para servidores que requieren autorización de acceso.

Password Nuevo atributo: Contraseña de usuario para servidores que requieren autorización de acceso. Nuevo comportamiento: Envía hRef = ref eventos OS MAM hacia otras solicitudes si se establece con una URLs del tipo "osmam: //LogAppName :EventNo" .

Los argumentos pueden ser transmitidos a través de una estructura de registro TLV con una etiqueta <setfield> o a través de formato HTTP con sintaxis de obtención "?" o con la etiqueta <postfield>.

Nuevo atributo: El texto se alinea dentro del espacio de align = (leftjright) entrada .

Nuevo atributo: Dispositivo de entrada de datos seleccionado. Los valores posibles son: Device= (keypad | keyboard| magnetic - lector de tarjetas barcode I magnetic) magnéticas; barcode - Lector de código de barras ; keyboard - Teclado externo; keypad - Teclado estándar.

Valor Nuevo: el valor de moneda en curso fuerza al type = (text | password valor de entrada par contar currency) con centavos (por ejemplo "0.00") .

Nuevo atributo: Si es verdadero, suena un sonido- alarm = (true I false) de-pitido cuando se ha Input alcanzado el tamaño de entrada .

Nuevo atributo: Carácter para llenar el área de entrada con el propósito permitirle al usuario estar conciente del tamaño de la entrada. Su presencia fuerza que las máscaras de entrada sean mostradas antes del tecleado filler y se suprime el signo de intercalación ? . 2.3 - Extensiones de Funciones de WML Script para las Librerías Estándares de WML Script Esta sección presenta las extensiones para las librerías estándares de WML Script, proporcionadas para un programa de navegación WAP con el propósito de convertirlo en un sistema cliente POS. Las definiciones de tales extensiones de Funciones Script son explicadas después de la tabla: Funciones específicas creadas para el sistema cliente POS: toFloat (valué) - Esta función regresa la representación de punto-flotante de un valor determinado. Esta función ejecuta, exactamente, los mismos tipos de conversiones definidas para el Lenguaje WML Script. Un valor inválido regresa a la cadena "inválido" . Requerido para forzar el tipo de conversión cuando son utilizadas las variables ingresadas. setElementsPos (String, separator, nElements) - Esta función almacena n-Elementos de Cadenas separadas por un separador. En caso de éxito, regresa a un entero, el cual contiene la posición del último carácter del último elemento almacenado. Usualmente, es utilizado antes de un llamado al String. elementAtPos (elementPos) mostrado a continuación. elementAtPos (elementPos) - Esta función regresa el elemento de una cadena, la cual se encuentra en la posición elementPos . La cadena ya debe haber sido organizada con la aplicación de la función setElementsPos (String, separator, nElements) . Si la cadena no está aún organizada por la función setElementPos, se usará la que estaba organizada previamente. En caso de error, regresa a inválido . formatCurrency (currencyString) - Esta función da formato a una Cadena en notación de valor monetario, separando los centavos con una coma o punto, así como también los miles y así sucesivamente. La función regresa a la Cadena formateada o a inválido en caso de que falle . isNumeric (string) - Esta función regresa a verdadero si el argumento puede ser convertido exitosamente a un valor numérico, de lo contrario, regresa a falso. toUpper (string) - Esta función regresa el argumento de la cadena convertido a mayúsculas . toLower (string) - Esta función regresa el argumento de la cadena convertido a minúsculas . padRight (string, pad, len) - Esta función regresa el argumento de la cadena desplazada por introducción de espacios hacia la derecha con el carácter de desplazamiento hasta la longitud len. padLeft (string, pad, len) - Esta función regresa el argumento de la cadena desplazada por introducción de espacios hacia la izquierda con el carácter de desplazamiento hasta la longitud len. loadFile (url, fileName) - Esta función recupera el contenido indicado por el url absoluto y lo guarda en un archivo nombrado fileName. Éste extrae los encabezados HTTP y regresa al código de resultado HTTP (200 significa OK) . loadToCache (url) Esta función recupera el contenido indicado por el url absoluto y lo almacena en el caché del sistema cliente para un uso futuro. Regresa al código de resultado HTTP (200 significa OK) . setEnv (Ñame, Valué) - Esta es una extensión que recibe como parámetros el nombre de la variable de ambiente del POS y el valor que será atribuido a esta variable. Regresa a verdadero si es exitoso cambiando el valor de la variable o a falso, si no lo es. En caso de fallo (parámetros inválidos, por ejemplo) , regresa a inválido . goExt(url, method, blsBack) - Esta extensión de la función WMLBrowser. go ( ) permite retransmitir o regresar a una URL definida. El regreso a una página WML requerirá la ejecución del evento "onenterbackward" , en caso que sea previsto. Recibe como parámetros la url, el método (POST o GET) y un valor lógico blsBack, que indica el regreso a la URL. Regresa a la cadena vacía en caso de éxito, de lo contrario, regresa a inválido. beep (Freq, nTi es) - Esta función emite un sonido en el dispositivo de salida en la frecuencia especificada por Freq, y el número de veces especificado por nTimes . Regresa a la cadena vacía en caso de éxito, de lo contrario, regresa a inválido . hangUp ( ) - Esta función desconecta el POS de la línea telefónica. Regresa a la cadena vacía. dialup ( ) - Esta función inicializa la conexión asincrona del POS con la línea telefónica. Regresa a la cadena vacía. persist () - Esta función genera una copia del Script en curso con el nombre "i : persist .wmlsc" . En caso de que este archivo ya exista, será renombrado a "i : last_persist. wmlsc" . Regresa al número de bytes registrados en el archivo "i:persist .wmlsc" . Si el mismo script en curso ya se ha borrado al limpiar la caché, entonces el resultado del llamado persistente será indefinido y puede resultar en un error de tiempo de ejecución. setPostfield (ñame, valué) - Esta función establece los campos de post que son los que se supone serán enviados con el siguiente llamado a WMLBrowser . goExt (href , "POST" , true) . Regresa a la cadena vacía si es exitoso, de lo contrario regresa a inválido . clearCacheWithTag (tag) - Esta función borra del caché cada archivo que presente un encabezado HTTP "VWTag:" que comience con fca<gr. getFirstVarName ( ) - Esta función regresa al nombre de la primera variable de ambiente . Junto con getNextVarName ( ) y getPrevVarName () , ofrece un iterador para el ambiente persistente. getNextVarName ( ) - Esta función regresa al nombre de la primera variable de ambiente. Junto con getFirstVarName () y getPrevVarName() , ofrece un iterador para el ambiente persistente. getPrevVarName ( ) - Esta función regresa al nombre de la primera variable de ambiente . Junto con getFirstVarName ( ) y getNextVarName ( ) , ofrece un iterador para el ambiente persistente . pin2pin() - Esta función inicializa un clon del sistema cliente "recíproco continuo" manejado por Sistema Operativo. dial (String toWhere) - Esta función establece los parámetros de marcado desde de una configuración en un almacén de registros. Regresa al estatus de conexión. getConStatus ( ) - Esta función regresa a un entero cuyo valor es el estatus de conexión. upLoad ( ) - Esta función inicializa la aplicación "recíproca continua" clonando lo que se sube o carga. addEnv (varName, increment) - Esta función recibe como parámetros el nombre de la variable de ambiente del POS y un valor entero que se agregará a este valor en curso de la variable . Si la variable no existe es creada con el valor recibido como parámetro. Regresa a verdadero si es exitoso el cambio del valor de la variable o a falso, si no. En caso de fallo (parámetros inválidos, por ejemplo) , regresa a inválido. appendVar (varName, valué) - Esta función recibe como parámetros el nombre de la variable de ambiente del POS y un valor de cadena que será anexado a este valor en curso de la variable . Si la variable no existe es creada con el valor recibido como parámetro. Regresa a verdadero si es exitoso el cambio del valor de la variable o a falso, si no. En caso de fallo (parámetros inválidos, por ejemplo), regresa a inválido . setEnvFromVars (varName, varList) - Esta función establece la variable de ambiente varName con las variables definidas en la lista de nombre de variables varlist separadas por punto-y-coma. Regresa la longitud de la cadena establecida varName, la cual deberá ser guardada para un uso futuro con las funciones setVarsFromEnv ( ) ó getVarFromEnv ( ) . setVarsFromEnv (varName) - Esta función establece el contexto de WML con las variables obtenidas del valor de la variable de ambiente varName. Regresa al número de variables establecidas, las cuales deberían haber sido grabadas con la función setEnvFromVars () . getVarFromEnv (envVarName , varName) - Esta función regresa al valor de la variable nombrada varName del valor de la variable de ambiente varName. Sí la variable no está definida por el valor regresa a la cadena vacía. deleteContext (appName) - Esta función borra completamente los archivos de la aplicación nombrada appName . Solamente puede ser llamada por la Aplicación Maestra del POS . isConnected() - Esta función reemplaza a getConStatus () regresa a un valor booleano que indica si la conexión está activada. installApp (appDataFile) - Esta función instala una aplicación desde un archivo de datos nombrado appDataFile y regresa a un entero que indica el código de error. Si esta función se ejecuta bien, la terminal será reiniciada y el código de regreso no será probado. setVarFromVars (varName, varList) - Esta función establece la variable WML varName con las variables definidas en la lista de nombre de variables varlist separadas por punto o coma. Regresa a la longitud de la cadena establecida para varName, la cual debería ser guardada para un uso futuro con las Funciones setVarsFromVar () o getVarFromVar ( ) . setVarsFromVar (varName) - Esta función establece el contexto de WML con las variables obtenidas del valor de la variable WML varName . Regresa al número de variables establecidas, las cuales deberían haber sido grabadas con la función setVarFromVars ( ) . getVarFromVar (wmlVarName, varName) - Esta función regresa al valor de la variable nombrada varName del valor de la variable WML wmlVarName . Si la variable no está definida por el valor regresa a la cadena vacía. getVarFromStr (wmlsStringOrVar, varName) - Esta función regresa el valor de la variable nombrada varName del valor de una variable de WMLScript o de una cadena wmlsStringOrVar . Si la variable no está definida por el valor regresa a la cadena vacía. show(message, defaultinput) - Esta función despliega un mensaje en la pantalla del POS y continúa la ejecución sin importar la solicitud del usuario. En caso de éxito, regresa a la cadena vacía, de lo contrario, regresa a inválido. showStatus (message, defaultinput) - Esta función despliega un mensaje en la línea de estatus de la pantalla del POS. En caso de éxito, regresa a la cadena vacía, de lo contrario, regresa a inválido. 2.4 - Librerías y Funciones de WML Script - Extensiones para las Librerías Estándar de WML Script . Esta sección presenta las librerías de extensión de WML Script proporcionadas a un programa de navegación WAP con el propósito de convertirlo en un sistema cliente POS.

Librerías y funciones específicas creadas para el sistema cliente POS: 2.4.1 - Librería Extendida RECORDSTORE El propósito de esta librería es permitir la persistencia de la información, almacenamiento de datos en archivos indexados . Lista de Funciones : openStore (Ñame, CreatelfNecessary) - Esta función recibe como parámetros el nombre del archivo que debe ser creado y una variable booleana CreatelfNecessary, indicando si el archivo debería ser creado en caso de que no exista. Al mismo tiempo en que se crea el archivo, también se crea un archivo índice respectivo. Regresa a un entero con el (id) del índice del archivo abierto o inválido, en caso de fallo en abrir o crear el archivo. closeStore (Storeld) - Esta función recibe como parámetro el índice (Storeld) del archivo abierto, cerrando los archivos de datos e índices . Regresa a un entero con el índice (Storeld) del archivo cerrado. En caso de no tener éxito al cerrar el archivo o si Storeld no existe, regresa a inválido. deleteStore (Ñame) - Esta función recibe como parámetro una cadena y Nombre, que contiene el nombre del archivo abierto y borra ese archivo de datos, así como su archivo índice. Regresa a un entero mayor o igual a cero si es exitoso al borrar los archivos. Si no es exitoso, regresa a inválido. getNumRecords (Storeld) - Esta función recibe como parámetro un Storeld entero, que contiene el índice del archivo abierto y obtiene el número de registros registrados. Regresa a un entero mayor o igual a cero si es exitoso al obtener el número de registros. De lo contrario, regresa a inválido. getSize (Storeld) - Esta función recibe como parámetro un Storeld entero, que contiene el índice del archivo abierto y obtiene su tamaño en bytes. Si la operación es exitosa regresa a un entero con el tamaño de archivo (numero total de bytes) , de lo contrario regresa a inválido. addRecord (Storeld, Record) - Esta función recibe como parámetro un Storeld entero, que contiene el índice del archivo abierto y un Record de cadena, que contiene los datos que se incluirán en el archivo. Si la agregación es exitosa, regresa a un entero con el índice del registro añadido en el archivo de datos, de lo contrario regresa a inválido. deleteRecord(Store!d, RecordId) - Esta función recibe dos enteros como parámetros: Storeld, que contiene el índice del archivo abierto y RecordId, que contiene el índice del registro que será excluido del archivo. Si se elimina con éxito, regresa a un entero con el índice de ese registro eliminado, de lo contrario, regresa a inválido. getRecord(Store!d, RecordId)- Esta función recibe dos enteros como parámetros: Storeld, que contiene el índice del archivo abierto y RecordId, que contiene el índice del registro que será recuperado. Si es exitosa la operación de lectura, regresa a un entero con el índice de ese registro recuperado, de lo contrario, regresa a inválido. getNextRecordld (Storeld, RecordId) - Esta función recibe dos enteros como parámetros: Storeld, que contiene el índice del archivo abierto y RecordId, que contiene el índice del registro anterior que será recuperado. Si es exitoso encontrar el índice del siguiente registro, regresa el índice como un entero, de lo contrario, regresa a inválido. getRecordSize (Storeld, RecordId) - Esta función recibe dos enteros como parámetros: Storeld, que contiene el índice del archivo abierto y RecordId, que contiene el índice del registro que será dimensionado. Si es exitoso encontrar el índice de registro, regresa a un entero con su dimensión en bytes, de lo contrario, regresa inválido. setRecord(StoreId, RecordId, RecordValue) Esta función recibe como parámetro el Storeld enteros, que contienen el índice del archivo abierto y RecordId, que contiene el índice del registro que será cambiado y el RecordValue de cadena, que contiene los nuevos valores que serán registrados . Esta función es útil para actualizar información en un registro determinado, mientras no altere su dimensión. En caso de buen-éxito del cambio, el RecordId de ese registro será regresado, de lo contrario, regresa a inválido. Si la dimensión del registro no es la misma, regresa a inválido. En este caso, se debe excluir y deberá registrarse una nueva información en un nuevo registro. createDatabase (BaseName, SourceName) - Esta función crea un almacenamiento de registros bajo el nombre BaseName desde un archivo fuente SourceName, ambos suministrados como parámetros . La función regresa a un cero o a un entero positivo si es exitosa. Regresa a inválido si no puede crear el almacenamiento de registros . findRecord(DB, Key, Pos, Separator, Ordered) - Esta función busca una clave de cadena ubicada en la posición Pos relacionada con el separador. Si el archivo DB está organizado en relación con el campo deseado, el parámetro Ordered puede ser igual a verdadero, permitiendo la ejecución de una búsqueda binaria en DB. setOrderKey (DB, Pos , Separador) - Esta función define el orden de búsqueda en el archivo DB de acuerdo con la posición Pos en relación al separador, para las funciones findFirstRecordO y findNextRecord ( ) . findFirstRecord (Storeld) - Esta función recibe como parámetro al manejador (Storeld) del archivo abierto y regresa a su primer índice de registro. La función setOrderKey ( ) debe haber sido llamado previamente. Regresa a un índice entero relacionado con la posición del primer registro de acuerdo con el orden definido por la función setOrderKey (DB, Pos, Separator) , o a inválido en caso de fallo (no pueda abrir el archivo, por ejemplo) . findNextRecord (Storeld) - Esta función recibe como parámetro el manejador (Storeld) del archivo abierto y regresa al siguiente índice de registro. La función findFirstRecordO debe haber sido llamada previamente. Regresa un índice entero relacionado con la posición del siguiente registro de acuerdo con el orden definido por la función setOrderKey(DB, Pos, Separador) , o a inválido en caso de fallo (no puede abrir el archivo, por ejemplo) . findRepeatedRecord(DB, Key, Pos, Separator, Ordered) -Esta función funciona como findRecordO , pero considera la ocurrencia de registros con claves repetidas. Regresa ael Id del registro encontrado. defragStore (StoreName) - Esta función elimina físicamente registros eliminados del RecordStore nombrado StoreName . El recordStore no debe ser abierto cuando es llamado. Regresa a inválido si falla. appendLastRecord (Storeld, string) - Esta función añade el argumento de cadena al contenido del último registro físico, si no es eliminado, deberá ser llamada enseguida de addRecordO . Regresa al RecordId. addRecordFromVars (Storeld, varList) - Esta función agrega un registro al RecordStore abierto identificado por Storeld con las variables definidas en la lista de nombres de variables varlist separadas por punto o coma. Regresa al id del registro agregado, que deberá ser guardado para uso futuro con las funciones setVarsFromRecordO ó getVarFromRecord ( ) . setVarsFromRecord (Storeld, RecordId) - Esta función establece el contexto de WML con las variables obtenidas del registro identificado con RecordId del RecordStore abierto identificado por Storeld. Regresa al id de la lectura de registro agregado, que deberá haber sido grabada con la función setRecordFromVars ( ) . getVarFromRecord (Storeld, RecordId, VarName) - Esta función regresa al valor de la variable nombrada VarName del registro identificado con RecordId del RecordStore abierto identificado por Storeld. Si la variable no está definida por el registro regresa a la cadena vacía. setView(DB, Key, Pos, Separator) - Esta función define un filtro de navegación para una almacenamiento de registros DB, que tiene una clave de valor en el campo en la posición Pos en relación con el separador. El almacenamiento de registros se supone que deberá ser ordenado por el mismo campo. Las vistas creadas con esta función ofrecen una selección totalmente transparente en el almacenamiento de registros para las funciones de navegación básicas. deleteVie (DB) - Esta función elimina los registros seleccionados por la vista establecida recientemente para un almacenamiento de registros DB. setFilterView(DB, Key, Pos, Separator) - Esta función define un filtro de navegación para un almacenamiento de registros DB, que tiene una clave de valor en el campo en la posición Pos en relación con el separador. El almacenamiento de registros no se supone que será ordenado por algún campo. Las vistas creadas con esta función ofrecen una selección totalmente transparente en el almacenamiento de registros para las funciones de navegación básicas, aunque los registros fuera de la vista serán omitidos secuencialmente cuando sea llamado RecordStore . getNextRecordld ( ) . 2.4.2 Librería Extendida CONSOLÉ . Esta librería contiene un conjunto de funciones utilizadas para depuración de la aplicación. Lista de Funciones : print (string) - Esta función muestra el texto del string' de depuración en la ventana de información del sistema cliente . Ningún carácter de línea nueva es insertado después del texto. Regresa a 1 si es exitoso al mostrase o, de lo contrario, a inválido. printLn (string) - Esta función muestra el string de texto de depuración en la ventana de información del sistema cliente . Inserta un nuevo carácter de línea nueva después del texto. Regresa 1 si es exitoso al mostrarse , de lo contrario, regresa a inválido. 2.4.3 Librería Extendida CRYPTO Esta librería contiene un conjunto de funciones utilizadas para el cifrado y descifrado de la información que se transmitirá con mayor seguridad a través de la red. Lista de Funciones : encrypt (Message, SessionKey) - Esta función regresa al parámetro message encriptado con el algoritmo DES . Si la dimensión de Message es mayor de 512 bytes o si el cifrado no tiene éxito, el message regresa a inválido. SessionKey es la cadena de 16 bytes que corresponde a una clave de 8 bytes codificada por hexadecimal. El valor de regreso es una cadena ascii codificada por hexadecimal con el doble de longitud del argumento Message . decrypt (Message, SessionKey) - Esta función regresa al parámetro message desencriptado con el algoritmo DES . Si la dimensión de Message es mayor de 1024 bytes o si el cifrado no tiene éxito, el message regresa a inválido. SessionKey es la cadena de 16 bytes que corresponde a una clave de 8 bytes codificada por hexadecimal. El parámetro Message se supone que debe ser una cadena ascii codificada por hexadecimal con el doble de longitud del valor regresado. enerypt2DES (Message, SessionKey) - Esta función regresa al parámetro message encriptado con el algoritmo DES . Antes de la encriptación, prefija el Message con la representación BCD de su longitud. Sí el tamaño de Message es mayor a 512 bytes o si el cifrado no tiene éxito, el message regresa inválido. SessionKey es la cadena de 16 bytes que corresponde a una clave de 8 bytes codificada por hexadecimal. El valor de regreso es una cadena ascii codificada por hexadecimal con el doble de longitud del argumento Message . decrypt2DES (Message, SessionKey) - Esta función regresa el parámetro message desencriptado con el algoritmo DES . Sí la dimensión de Message es mayor de 1024 bytes o si el cifrado no tiene éxito, el mensaje regresa a inválido . El parámetro Message se supone debe ser una cadena ascii codificada por hexadecimal con el doble de longitud del valor regresado más la dimensión de la longitud de la cadena. xor(stringl, string2) - Esta función recibe dos cadenas ascii codificadas por hexadecimal y regresa a la cadena ascii codificada por hexadecimal que corresponde a xor entre sus valores binarios . encrypt2DESHexa (Message, SessionKey) - Esta función regresa al parámetro message encriptado con el algoritmo DES . Antes de la encriptación, prefija el Message con la representación BCD de su longitud. El argumento Message se supone debe ser una cadena ascii codificada por hexadecimal. Sí la dimensión de Message es mayor de 1024 bytes o si el cifrado no tiene éxito, el mensaje regresa a inválido . SessionKey es la cadena de 16 bytes que corresponde a una clave de 8 bytes codificada por hexadecimal. El valor de regreso es una cadena ascii codificada por hexadecimal con la misma dimensión del argumento Message . decrypt2DESHexa (Message, SessionKey) - Esta función regresa al parámetro message desencriptado con el algoritmo DES. Si la dimensión de Message es mayor de 1024 bytes o si el cifrado no tiene éxito, el mensaje regresa a inválido. SessionKey es la cadena de 16 bytes que corresponde a una clave de 8 bytes codificada por hexadecimal. El parámetro Message se supone es una cadena ascii codificada por hexadecimal con la misma longitud del valor regresado más el tamaño de la dimensión de la cadena . encryptHexa (Message, SessionKey) - Es igual que encrypt, pero el parámetro message se encuentra en una representación hexadecimal . El valor de regreso es una cadena ascii codificada por hexadecimal con el doble de longitud del argumento Message . decryptHexa (Message, SessionKey) - Es igual que encrypt, pero el parámetro message se encuentra en una representación hexadecimal. El valor de regreso es el parámetro message desencriptado con el algoritmo DES . 2.4.4 - Librería PRINTER Esta librería contiene un conjunto de funciones utilizadas para la impresión. Lista de Funciones : open ( ) - Esta función abre la salida a la impresora. Si tiene éxito, regresa el manejador obtenido, de lo contrario regresa a inválido. setWidthMode (mode) - Esta función configura el ancho de la fuente que se enviará a la impresora, tomando como base el parámetro mode. Mode debe cumplir con los requisitos de conversión a entero o punto flotante. Si tiene éxito regresa a verdadero, si no o el parámetro mode es ilegal, regresa a inválido. setHeightMode (mode) - Esta función configura la altura de la fuente que se enviará a la impresora, tomando como base el parámetro mode. Mode debe cumplir con los requisitos de conversión a entero o punto flotante. Si tiene éxito regresa a verdadero, si no o el parámetro mode es ilegal, regresa a inválido. print ( string) - Esta función imprime el contenido de la cadena . Regresa verdadero si se logra imprimir, de lo contrario, regresa a inválido . printLn ( string) - Esta función imprime el contenido de la cadena y agrega un nuevo carácter de línea después de imprimir . Regresa a verdadero si logra imprimir, de lo contrario, regresa a inválido . cióse ( ) - Esta función cierra la salida a la impresora, regresando una cadena vacía ( "" ) . printLogo (LOGOFileName) - Esta función recibe como parámetro la ruta hacia el archivo en donde está localizado el mapa de bits, en formato LGO, que será impreso. La función regresa ya sea a un valor negativo en caso de que falle o "1" en caso de ser exitosa la impresión. 2 . 4 . 4 Liberia CARD Esta librería contiene un conjunto de funciones utilizadas para el intervalo de verificación de tarjetas financieras BIN.

Lista de funciones checkRanges (currentPAN, privateLabelSuffix) - Esta función verifica el intervalo de una determinada tarjeta PAN contra los leídos desde el ambiente de POS para las variables MAXlblZ y MINIJlX, en donde lbl representa el privateLabelSuffix determinado y X representa el contador de intervalos para esa etiqueta. X empieza en 0. Si el currentPAN se ajusta al intervalo X entonces INFlblX. Si no se ajusta a algún rango, regresa a inválido . Si no se determina algún prívate label suffix, asume el valor por omisión "PAN" . checkRangesInStore (currentPAN, 'StoreName) - Esta función verifica el intervalo de la tarjeta PAN determinada contra los leídos desde los registros de StoreName RecordStore. Cada registro se supone debe tener una cadena-de-tres-elementos separados por punto o coma, por ejemplo, "4400;4999;returnedinfo" . El PAN se verifica contra los dos primeros elementos de cada registro hasta que se ajuste entre ellos. La función regresa al tercer elemento del primer registro que se ajusta. Si no se ajusta al intervalo de cualquier registro, regresa a inválido . 2.4.5 Librería SYSTEM Esta librería contiene un conjunto de funciones utilizadas para el acceso a utilerías de tiempo del sistema. Lista de funciones : currentTimeSecs ( ) - Esta función regresa al tiempo de POS en curso en segundos a partir de 01/01/1970, 00:00:00. datetime2Seconds (datetime) - Esta función regresa al número de segundos transcurridos a partir de 01/01/1970, 00:00:00 a la fecha y hora expresados por datetime con el formato "YYYYMMDDHHMMSS" . seconds2datetime (seconds) - Esta función regresa la fecha y hora correspondientes al número de segundos transcurridos a partir de 01/01/1970, 00:00:00 expresado en segundos. El valor de regreso tiene el formato "YYYYMMDDHHMMSS" . isValidDate (datetime) - Esta función regresa a verdadero si el argumento datetime expresa una fecha/hora válida con formato "YYYYMMDDHHMMSS" . datetime ( ) - Esta función regresa a la fecha y hora de POS en curso. El formato de valor de regreso es "YYYYMMDDHHMMSS". currentTicks ( ) - Esta función regresa al número de milisegundos desde que el POS fue iniciado. 2.4.6 Librería ISO Esta librería contiene un conjunto de funciones para tratar con mensajes ISO-8583. charToHe (String) - Esta función recibe un String como Entrada y regresa otro String con la representación HEXADECIMAL del String de entrada en ASCII. hexToChar (String) - Esta función recibe un String como entrada que es una representación HEXADECIMAL de un String (en ASCII) y regresa al String representado. El String que ha sido regresado siempre tendrá la mitad de dimensión del String de origen. Si la longitud del String de origen es impar, la función regresara a inválido. readPackager (String) - Esta función actualiza el empaquetador utilizado para empaquetar el mensaje ISO-8583. El String de Entrada es la TRAYECTORIA del archivo con la definición del empaquetador. El valor de regreso es el código de error. Si el regreso es cero, no ocurrió ningún error. El formato del archivo que define al empaquetador es: FIELDID=PACKAGER; LEN< ; INNERPACKAGER FILEPATH> Ej emplo : #este es un comentario 0=IFB_NUMERIC;4 1=IFB_BITMAP;16 2=IFB_LLNUM;19 3=IFB_NUMERIC;6 #4=IFB_NUMERIC;12 34=IFB_LLLIBINARY; 999 ; f : subdef .pdf Para reducir la dimensión del archivo y disminuir el tiempo de análisis sintáctico, no son permitidos los caracteres de espacio en un archivo de definición de empaquetador. Este archivo es un archivo de texto regular (formato de texto) . Los campos ISO tienen un empaquetador, que identifica el formato de los datos que serán enviados en el mensaje ISO. Un campo puede, opcionalmente, tener campos interiores. Se puede definir un empaquetador interior para permitir que el sistema cliente analice de forma sintáctica el campo. Para que esto ocurra, se puede especificar una trayectoria de archivo que contiene la definición del empaquetador interior. Los empaquetadores posibles son: IFB_BITMAP, IF_HEX, IFA_LLHEX, IFA_LLLHEX, IFB_LLHEX, IFB_LLLHEX, IF_BINARY, IFA_LLBINARY, IFA_LLLBINARY , IFB_LLBINARY , IFB_LLLBINARY, IF_CHAR, IFA_LCHAR, IFA_LLCHAR, IFA_LLLCHAR, IFB_LLCHAR, IFB_LLLCHAR, IFA_NUMERIC, IFA_LLNUM, IFA_LLLNUM, IFB_NUMERIC, IFB_LLNUM, IFB__LLLNUM, IFA_AMOUNT, IFB_AMOUNT, IFB_LLLIHEX, IFB_LLLIBINARY, IFB_LLLICHAR y IFB_LLLINUM. Existen 6 tipos de empaquetadores: Numérico, Cantidad, Carácter, Hexa, Binario y Mapa de Bits. Los caracteres L, LL o LLL indican la dimensión máxima de un campo. Si un campo es IFA_LLLNUM, significa que su tamaño no puede ser mayor a 999. El prefijo IFA o IFB indica que la porción numérica de un campo es almacenada en ASCII o BCD . La ? I' en algunos nombres de empaquetador (por ejemplo: IFB_LLLINUM) indica que el campo será identificado. Esto es útil para definir empaquetadores interiores, en donde los campos interiores deberán ser identificados . Numérico: Este empaquetador recibe un String con una representación numérica (por ejemplo: "12345").

Resultados : IFA_NUMERIC: 12345 (número enviado como un String) IFA-LLNUM: 0512345 (la dimensión del campo en ASCII) IFA_LLLNUM: 00512345 (la dimensión del campo en ASCII) IFB_NUMERIC: xl2 x34 x50 (número almacenado en BCD) IFB LLNUM: x05 xl2 x34 x50 (dimensión de campo también en BCD) IFB_LLLNUM: xOO x05 xl2 x34 x50 (dimensión de campo también en BCD) IFB_LLLINUM: xOO x05 x23 xl2 x34 x50 (id es 23. También en BCD) Cantidad: Este empaquetador es similar al numérico, excepto por el hecho de que es precedido por un carácter que indica la señal . La entrada para este empaquetador puede ser un String como "D12050". Resultados : IFA AMOUNT: C12345 (número enviado como una String) IFB AMOUNT: x43 xl2 x34 x50 (número enviado en BCD) Carácter: Este empaquetador recibe una String como "¡este texto esta bien! 12345". Resultados : IFA_CHAR: 12345 (campo enviado como un String) IFA_LCHAR: 512345 (la dimensión de campo en ASCII) IFA_LLCHAR: 0512345 (la dimensión de campo en ASCII) IFA_LLLCHAR: 00512345 (la dimensión de campo en ASCII) IFB CHAR: x31 x32 x33 x34 x35 (campo enviado como un String) IFB_LLCHAR : x05 x31 x32 x33 x34 x35 (dimensión de campo en BCD) IFB_1ULCHAR: xOO x05 x31 x32 x33 x34 x35 (dimensión de campo también en BCD) IFB_LLLICHAR: xOO x05 x23 x31 x32 x33 x34 x35 ( id es 23 . También en BCD) Hexa : Este empaquetador recibe un String que representa (en hexadecimal) un campo binario. El String hexa es convertido a un campo binario y añadido en el mensaje. Resultados: IF_HEX: x31 x32 x33 x34 x35 Campo enviado en binario IFA_LLHEX: x30 x35 x31 x32 x33 x34 x35 (dimensión (05) en ASCII) IFA_LLLHEX: x30 x30 x35 x31 x32 x33 x34 x35 (dimensión (005) en ASCII) IFB_LLHEX: x05 x31 x32 x33 x34 x35 (dimensión (05) en BCD) IFB_LLLHEX: xOO x05 x31 x32 x33 x34 x35 (dimensión (005) en BCD)) Binario: Este empaquetador recibe un buffer binario y crea un campo binario en el mensaje. Como no existe un tipo binario para el WMLScript, este empaquetador fue intencionalmente creado para envolver los campos interiores . Los campos interiores pueden ser numérico + carácter y el campo exterior deberá ser definido como binario. Al empacar los campos interiores, el resultado del buffer binario (campo exterior) será empaquetado automáticamente como binario por el motor.

Resultados : IF_BINARY: x31 x32 x33 x34 x35 (campo enviado en binario) IFA_LLBIN: x30 x35 x31 x32 x33 x34 x35 (dimensión (05) en ASCII) IFA_LLLBIN: x30 x30 x35 X31 x32 x33 x34 x35 (dimensión (005) en ASCII) IFB_LLBIN: x05 x31 x32 x33 x34 x35 (dimensión (05) en BCD) IFB LLLBIN: xOO x05 x31 x32 x33 x34 x35 (tamaño (005) en BCD)) Mapa de bits : Este es un empaquetador especial que almacena un mapa de bits binario en el mensaje. Este mapa de bits es creado basado en la existencia de los campos de mensaje. Este empaquetador es utilizado para el campo 1. transactMessage (String .host, int port, String fieldlist, String channel, String header, String trailer, String mandatoryFields) - Esta función envía y recibe un mensaje con base en el empaquetador configurado y en el fieldlist utilizado. La lista de campos es un String que envuelve los nombres de campo que serán enviados en el mensaje. Las muestras son separadas por un carácter " ; " . Los campos son nombrados por la regla f<field ID> . Si el nombre enviado es un nombre de sub campo, la regla es f<field iD>s<sub ID> . Ejemplo de una lista de campos: " f0 ; f2 ; f3 ; f28 ; f11 ; f34s0 ; f34s2s0 ; f34s2s2 ; f34s3 ; f34s5 ; f41 ; f70" f34 está conformado por f34s0, f34s2, f34s3 y f34s5, mientras que f34s2 esta conformado por f34s2s0 y f 34 s 2 s 2 . Aquí encontramos tre s nive le s de campos interiores . El encabezado y cola que serán enviados en el mensaj e son cadenas hexadecimales que representan el encabezado y cola binarios que serán enviadas . E j emplo : "0600030001" genera x06 xOO x03 xOO xOl El canal seleccionado refleja la forma en que la longitud del mensaje se almacena en el mensaje. Los canales disponibles son "ASCII" , "RAW" , "NAC" , y "NCC" . Ejemplo (la dimensión de mensaje es de 256) ASCII: x30 x32 x35 x36("0256") RAW: xOO X00 xOl xOO (0000-0000 0000-0000 0000-0001 0000-0000) NAC: xOl xOO (0000-0001 0000-0000) NCC: x02 X56 (BCD) Los valores para los campos enviados en el parámetro fieldlist , tienen que almacenar valores como variables en la memoria . Se pueden establecer con "WMLBrowser . setvar ( fieldname , valué) ; " . El mensaje será enviado al servidor y el script se bloqueará en espera de la respuesta. Si ocurren errores será recuperado como el valor de regreso de la función, de lo contrario regresará a cero. El mensaj e de respuesta es analizado de forma sintáctica por las reglas del empaquetador . Los campos y sub campos encontrados serán guardados dentro de variables en la memoria también. El nombramiento de convención para esas variables de respuesta es el mismo para el envío, pero en lugar de que una ?f preceda al ID una ?r' será el sufijo. El argumento mandatoryFields es un String formateado como fieldlist. Este fuerza a la respuesta a ser verificada. Si falta un campo obligatorio ocurre un error y no se procesa la transacción. Desde el momento que la función regresa y así sucesivamente, la aplicación tiene que recuperar las variables, verificarlas y hacer lo que se desee hacer. Quiza imprimir un recibo. transactFromRecord (String host, int port, int Storeld, int RecordID, String channel, String header, String trailer, String mandatoryFields) - Esta función envía y recibe un mensaje basado en el empaquetador configurado y en los campos ISO establecidos. Los campos son almacenados en un Registro de un RecordStore. La identificación del RecordStore es transmitida como el parámetro storeld y la identificación del Registro es transmitida como un parámetro registrado. Para generar un registro con los campos ISO, se deberá usar la función addRecordFromVars () de la librería RecordStore. Esta función ofrece una forma alternativa para establecer los argumentos (en este caso, los campos ISO) para una transacción ISO.

El encabezado y la cola que se enviarán en el mensaje son cadenas hexadecimales que representan el encabezado y cola binaria que serán enviados . Ej emplo : "0600030001" genera x06 xOO x03 xOO xOl El canal seleccionado refleja la forma en que se almacena la longitud del mensaje en el mensaje. Los canales disponibles son: "ASCII", "RAW", "NAC" y "NCC". Ejemplo (tamaño del mensaje es de 256) : ASCII: x30 x32 x35 x36 ("0256") RAW: X00 X00 xOl xOO (0000-0000 0000-0000 0000-0001 0000-0000) NAC: xOl xOO (0000-0001 0000-0000) NCC x02 x56 (BCD) El argumento mandatoryFields es una lista de campos que se verificarán si está presente en la respuesta. Ejemplo de una lista mandatoryFields: "f0;f2;f3;f28;f11;f34s0;f34s2s0;f34s2s2;f34s3;f34s5;f41;f70" f34 está conformado por f34s0, f34s2, f34s3 y f34s5, mientras que f34s2 esta conformado por f34s2s0 y f34s2s2. Aquí encontramos tres niveles de campos interiores . MandatoryFields fuerza que la respuesta sea verificada. Si falta un campo obligatorio, ocurre un error y no se procesa la transacción. Los campos de mensaje respuesta son almacenados en un nuevo Registro del RecordStore y su id es el valor de regreso de la función. Para restablecer los campos en variables se deberá llamar la función setVarsFromRecord () de la librería RecordStore. Las variables son establecidas utilizando la misma regla de nomenclatura como la usada por transactMessage () . transactFromRecordToVar (String host, int port, int Storeld, int RecordID, String channel, String header, String trailer, String mandatoryFields) - Esta función envía y recibe un mensaje basado en el empaquetador configurado y en los campos ISO establecidos. Los campos son almacenados en un Registro del RecordStore pero el regreso es establecido para la Variable WML llamada ISORESP. Si la longitud resultante excede la longitud máxima de variables WML (512) , los bytes excedentes son divididos en variables de 500 bytes nombrada ISORESPn, n=l... La variable WML ISONRESP se establece también con el número total de variables necesitadas para almacenar el resultado, incluyendo ISORESP. La identificación del RecordStore es transmitida como el parámetro storeld y la identificación del Registro es pasada como un parámetro registrado. Para generar un registro con los campos ISO, se deberá usar la función addRecordFromVars () de la librería RecordStore . Esta función ofrece una forma alternativa para establecer los argumentos (en este caso, los campos ISO) para una transacción ISO.

El encabezado y la cola que se enviarán en el mensaje son cadenas hexadecimales que representan el encabezado y cola binarios que serán enviados . Ej emplo : "0600030001" genera x06 xOO x03 xOO xOl El canal seleccionado refleja la forma en que se almacena la longitud del mensaje en el mensaje. Los canales disponibles son: "ASCII", "RAW", "NAC" y "NCC". Ejemplo (dimensión de mensaje es 256) : ASCII: X30 x32 x35 x36 ("0256") RAW: xOO xOO xOl xOO (0000-0000 0000-0000 0000-0001 0000-0000) NAC: xOl xOO (0000-0001 0000-0000) NCC X02 x56 (BCD) El argumento mandatoryFields es una lista de campos que se verificará si está presente en la respuesta. Ejemplo de una lista mandatoryFields: "f0;f2;f3;f28;f11;f34s0;f34s2s0;f34s2s2;f34s3;f34s5;f41;f70" f34 está conformado por f34s0, f34s2, f34s3 y f34s5, mientras que f34s2 está conformado por f34s2s0 y f34s2s2. Aquí encontramos tres niveles de campos internos . MandatoryFields fuerza que la respuesta sea verificada. Si falta ion campo obligatorio, ocurre un error y no se procesa la transacción. Los campos de mensaje respuesta son almacenados en un nuevo Registro del RecordStore y su id es el valor de regreso de la función. Para restablecer los campos en las variables se deberá llamar la función setVarsFromRecordO de la librería RecordStore. Las variables son establecidas utilizando la misma regla de nomenclatura que tiene transactMessage () . hexToInt (String hexa, Boolean BigEndian) - Esta función recibe una representación hexadecimal de un entero. El entero en el motor de script es de 4 bytes de largo, así el parámetro hexa pueda ser una cadena de 2, 4, 6, u 8 caracteres de largo, representando los bytes de Entero. Esta representación puede ser como una "Big Endian" o "Little Endian" , y ésto es informado en el parámetro Boleano BigEndian (si se trabaja con una representación big endian, se establece a verdadero) . El valor regresado es el entero deseado. intToHex(int I, Boolean BigEndian) - Esta función convierte un entero en una representación hexadecimal de un Entero . Adicionalmente, el sistema cliente contiene una librería llamada PinPad que contiene un conjunto de funciones utilizadas para acceder al dispositivo Pad de Pin y el Kernel EMV de POS a través de la interface estándar del EMV. Esta invención será aplicada en una variedad de áreas de negocio, tales como servicios/seguros de salud, sistemas de fidelización, banca remota, pago de facturas, financiamiento de recarga de prepago, tarjetas de regalo, transferencias de dinero y verificación de edad, administración de tiempo y trabajo, entre otras.

La aplicación aquí descrita es una modalidad de las posibilidades que proporciona la invención. Se pueden diseñar muchos modos de aplicación diferentes, utilizando diferentes medios de conexión aun dispositivos y redes. El verdadero alcance de la invención está definido por las reivindicaciones . Se hace constar que con relación a esta fecha, el mejor método conocido por el solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims (16)

1. REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones . 1. Un sistema para acceder a una terminal POS que comprende un sistema cliente el cual conecta la terminal POS a la red de conexión utilizando una pluralidad de protocolos de comunicación y transacción, el sistema cliente que incluye al menos una extensión personalizada WML y Script agregada a los WAP estándares preexistentes, el sistema está caracterizado porque comprende : medios para acceder a una pluralidad de dispositivos periféricos ; medios para descargar y actualizar solicitudes de servidores de aplicación; medios para ejecutar operaciones electrónicas con servidores de transacciones que utilizan diferentes protocolos de transacción; y medios para soportar múltiples-solicitudes llevadas a cabo independientemente en ambientes lógicos diferentes .
2. 2. Un sistema para acceder una terminal POS de conformidad con la reivindicación 1, caracterizado porque los diferentes protocolos de transacción son HTTP, ISO 8583 o XML.
3. 3. Un sistema para acceder a una terminal POS de conformidad con la reivindicación 1, caracterizado porque los protocolos de comunicación pueden ser seleccionados de un grupo que consiste de TCP/IP, PPP, SDLC, X.28, GPRS, CDMA, CDMA IX, Eternet, GSM, WI-Fi, Bluetooth e IR.
4. 4. Un sistema para acceder una terminal POS de conformidad con la reivindicación 1, caracterizado porque los dispositivos periféricos pueden ser seleccionados de un grupo que consiste de lectores de tarjetas magnéticas, lectores de tarjeta inteligentes, impresoras, pads de pin, lectores de código de barras, lectores de cheques, teclados, lectores de tarjeta Mifare sin contacto y pantallas táctiles sensibles.
5. 5. Un sistema para acceder a una terminal POS de conformidad con la reivindicación 1, caracterizado porque la extensión personalizada WML y Script agregada a los WAP estándares preexistentes, además comprende medios para ejecutar una operación electrónica con tarjetas de chip.
6. 6. Un método para descargar y actualizar solicitudes utilizando el sistema de conformidad con cualquiera de las reivindicaciones 1 a 5, caracterizado porque comprende los pasos de: conectar el sistema cliente POS con una red de conexión para recibir una dirección; establecer una sesión de protocolo de control de transferencia entre el sistema cliente con el servidor de aplicación; enviar una solicitud de descarga/actualización de aplicación; procesar la solicitud en el servidor de aplicación; enviar las páginas, scripts y archivos de datos al sistema cliente POS.
7. 7. Un método para descargar y actualizar solicitudes con el uso del sistema de conformidad con la reivindicación 6, caracterizado porque el paso de procesamiento de la solicitud en el servidor de aplicación además comprende los pasos de: hacer contacto con el servidor de transacciones con un mensaje en la conexión TCP/IP; recibir una respuesta del servidor de transacciones con los establecimientos de configuración del sistema cliente POS; procesar las configuraciones de la aplicación y generar una versión personalizada de la aplicación en red; y enviar las páginas, scripts y archivos de datos personalizados de la aplicación al sistema cliente POS.
8. 8. Un método para descargar y actualizar solicitudes, de conformidad con la reivindicación 6, caracterizado porque la conexión de la terminal POS a una red de conexión es ejecutada con un servidor de acceso remoto o por medio de una red de conexión de banda ancha.
9. 9. Un método para descargar y actualizar solicitudes, de conformidad con la reivindicación 6, caracterizado porque la dirección proporcionada por la red de conexión es preferiblemente un Protocolo de Internet (IP) .
10. 10. Un método para descargar y actualizar solicitudes, de conformidad con la reivindicación 6, caracterizado porque el paso de enviar una solicitud de descarga/actualización de aplicación esta acompañado con un HTTP (o HTTPs) POST o comandos GET .
11. 11. Un método para descargar y actualizar solicitudes, de conformidad con la reivindicación 7, caracterizado porque el paso de hacer contacto con el servidor de transacciones es llevado a cabo con un mensaje en formato IS08583.
12. 12. Un método para descargar y actualizar solicitudes, de conformidad con la reivindicación 6, caracterizado porque después del paso del enviar páginas, scripts y archivos de datos de la aplicación, el método además comprende los pasos de procesamiento de los archivos recibidos y la emisión de un recibo de la finalización de descarga/actualización de la aplicación.
13. 13. Un método para ejecutar las operaciones electrónicas utilizando el sistema de conformidad con cualquiera de las reivindicaciones 1 a 5, caracterizado porque comprende los pasos de : conectar al sistema cliente POS con una red de conexión para recibir permiso; construir un mensaje de transacción y enviar el mensaje hacia el servidor de transacciones; recibir una respuesta desde el servidor de transacciones hacia el sistema cliente POS con un mensaje de transacción.
14. 14. Un método para ejecutar operaciones electrónicas de conformidad con la reivindicación 13, caracterizado porque la conexión de la terminal POS a una red de conexión es ejecutada con un servidor de acceso remoto o por medio de una red de conexión de banda ancha.
15. 15. Un método para ejecutar operaciones electrónicas de conformidad con la reivindicación 13, caracterizado porque el mensaje de transacción está en el formato ISO 8583.
16. 16. Un método para ejecutar operaciones electrónicas de conformidad con la reivindicación 13, caracterizado porque después del paso de recibir una respuesta del servidor de transacción, el método además comprende los pasos de procesar los mensajes recibidos y emitir un recibo de la transacción.