ES2961266T3 - Sistemas y métodos para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota - Google Patents
Sistemas y métodos para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota Download PDFInfo
- Publication number
- ES2961266T3 ES2961266T3 ES20203134T ES20203134T ES2961266T3 ES 2961266 T3 ES2961266 T3 ES 2961266T3 ES 20203134 T ES20203134 T ES 20203134T ES 20203134 T ES20203134 T ES 20203134T ES 2961266 T3 ES2961266 T3 ES 2961266T3
- Authority
- ES
- Spain
- Prior art keywords
- payment
- mobile device
- machine
- user
- implementations
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 146
- 238000013475 authorization Methods 0.000 claims abstract description 238
- 230000004044 response Effects 0.000 claims abstract description 24
- 238000003860 storage Methods 0.000 claims description 10
- 230000000694 effects Effects 0.000 claims description 3
- 230000010399 physical interaction Effects 0.000 claims description 3
- 238000004891 communication Methods 0.000 description 186
- 238000012545 processing Methods 0.000 description 74
- 230000008569 process Effects 0.000 description 63
- 238000005516 engineering process Methods 0.000 description 54
- 230000007246 mechanism Effects 0.000 description 34
- 238000010586 diagram Methods 0.000 description 32
- 230000001413 cellular effect Effects 0.000 description 23
- 108010076504 Protein Sorting Signals Proteins 0.000 description 22
- 230000005540 biological transmission Effects 0.000 description 21
- 230000002085 persistent effect Effects 0.000 description 17
- 230000006870 function Effects 0.000 description 14
- 238000007726 management method Methods 0.000 description 10
- 235000014214 soft drink Nutrition 0.000 description 10
- 230000008859 change Effects 0.000 description 8
- 238000013459 approach Methods 0.000 description 7
- 230000007257 malfunction Effects 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 238000004590 computer program Methods 0.000 description 5
- 230000014509 gene expression Effects 0.000 description 5
- 238000009434 installation Methods 0.000 description 5
- 239000004020 conductor Substances 0.000 description 4
- 238000009420 retrofitting Methods 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 238000005406 washing Methods 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 230000000007 visual effect Effects 0.000 description 3
- 230000003213 activating effect Effects 0.000 description 2
- 230000000994 depressogenic effect Effects 0.000 description 2
- 230000001976 improved effect Effects 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 239000006249 magnetic particle Substances 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 239000002245 particle Substances 0.000 description 2
- 238000005070 sampling Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 241000167854 Bourreria succulenta Species 0.000 description 1
- XQCFHQBGMWUEMY-ZPUQHVIOSA-N Nitrovin Chemical compound C=1C=C([N+]([O-])=O)OC=1\C=C\C(=NNC(=N)N)\C=C\C1=CC=C([N+]([O-])=O)O1 XQCFHQBGMWUEMY-ZPUQHVIOSA-N 0.000 description 1
- CDBYLPFSWZWCQE-UHFFFAOYSA-L Sodium Carbonate Chemical compound [Na+].[Na+].[O-]C([O-])=O CDBYLPFSWZWCQE-UHFFFAOYSA-L 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 235000021152 breakfast Nutrition 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000003599 detergent Substances 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 230000006698 induction Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000013178 mathematical model Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000003825 pressing Methods 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F9/00—Details other than those peculiar to special kinds or types of apparatus
- G07F9/002—Vending machines being part of a centrally controlled network of vending machines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F9/00—Details other than those peculiar to special kinds or types of apparatus
- G07F9/001—Interfacing with vending machines using mobile or wearable devices
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F9/00—Details other than those peculiar to special kinds or types of apparatus
- G07F9/02—Devices for alarm or indication, e.g. when empty; Advertising arrangements in coin-freed apparatus
Landscapes
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Economics (AREA)
- Marketing (AREA)
- Telephonic Communication Services (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Selective Calling Equipment (AREA)
- Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Telephone Function (AREA)
- User Interface Of Digital Computer (AREA)
Abstract
En el presente documento se describen sistemas y métodos para determinar impulsos eléctricos para proporcionarlos a una máquina desatendida basándose en opciones configuradas de forma remota. Un método de ejemplo incluye: detectar la presencia de la máquina desatendida cerca del dispositivo móvil. Tras detectar la presencia, el método incluye: recibir, desde un servidor, información sobre un primer conjunto de opciones configuradas remotamente. En respuesta a recibir la información sobre el primer conjunto de opciones configuradas de forma remota, el método incluye: mostrar objetos de interfaz de usuario que permiten la selección de las opciones respectivas en el primer conjunto de opciones configuradas de forma remota. Después de detectar una selección de un primer objeto de interfaz de usuario, recibir, desde el servidor, especificaciones con respecto a los impulsos eléctricos que se proporcionarán a la máquina desatendida mediante un dispositivo que proporciona impulsos. Después de enviar una concesión de autorización y las especificaciones al dispositivo proveedor de impulsos, el método incluye: recibir una indicación de que los impulsos eléctricos se proporcionaron a la máquina desatendida de acuerdo con las especificaciones. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Sistemas y métodos para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota
Campo de la invención
La presente solicitud se refiere al campo de la provisión de pulsos eléctricos en máquinas no atendidas y, en particular, a la determinación de pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota.
Antecedentes de la invención
Las máquinas de crédito basadas en pulsos eléctricos son un tipo de "unidad de aceptación de pago" o "máquina no atendida" (las máquinas no atendidas o las unidades de aceptación de pago también se denominan en el presente documento genéricamente "máquinas"). Una máquina no atendida es un equipo que requiere el pago por la dispensación de productos (por ejemplo, artículos almacenados por una máquina expendedora) y/o servicios (por ejemplo, partidas de videojuego).
Un consumidor que usa una máquina de crédito basada en pulsos eléctricos, tal como un videojuego, una atracción de paseo para niños o una lavandería que funciona con monedas, está restringido a una cantidad por defecto predefinida por incremento de pago según es establecido por la máquina (es decir, una correlación directa de las monedas que se insertan con los créditos validados por la máquina). Por ejemplo, si un crédito permitiera al usuario jugar una partida, el usuario necesitaría enviar 3 créditos (es decir, insertar 3 monedas en la máquina) si este deseara jugar tres partidas.
Debido a que las opciones de precios están predefinidas y programadas físicamente en la máquina, los operadores de máquina son incapaces de ofrecer descuentos por adelantado, descuentos basados en el tiempo u otras opciones que permitan a los operadores de máquina controlar de manera flexible las opciones de precios disponibles. Además, los usuarios son incapaces de aprovechar las promociones y tienen que seguir insertando monedas en las máquinas no atendidas de acuerdo con las opciones existentes.
El documento US2015/0170131 A1 propone un módulo de pago para adaptar una máquina operada con pagos fuera de línea para aceptar pagos electrónicos, en donde la máquina operada con pagos fuera de línea incluye un interruptor de recepción de monedas.
El documento US 2015/0235202A1 propone un método para gestionar transacciones sin efectivo en una máquina expendedora.
El documento US 8.600.899 B1 propone circuitos de máquina expendedora adaptados para interactuar con la electrónica de la máquina expendedora para proporcionar comunicaciones de datos entre un dispositivo portable y la electrónica de la máquina expendedora.
El documento US2015/0100152A1 desvela un sistema que comprende una máquina expendedora (VM).
Sumario
En el presente documento se divulgan sistemas y métodos que abordan las deficiencias anteriores. En particular, en el presente documento se divulgan sistemas y métodos para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota. Por ejemplo, un operador de máquina es capaz de acceder a una interfaz basada en web con el fin de añadir o modificar opciones de precios para una máquina no atendida particular. Cuando un usuario recibe posteriormente una concesión de autorización para la máquina no atendida particular, ese usuario es capaz de aprovechar las opciones de precios nuevas o modificadas. De esta manera, los operadores de máquina pueden establecer programaciones de precios y los usuarios pueden aprovechar las promociones únicas ofrecidas por los operadores de máquina. Además, los usuarios no necesitan añadir constantemente monedas individuales con el fin de acceder a servicios proporcionados por una máquina no atendida, en su lugar los usuarios pueden aprovechar, de manera simple y fácil, las promociones únicas a través de una aplicación que se está ejecutando en su propio teléfono móvil (evitando de este modo ineficiencias tales como monedas perdidas, monedas atascadas, interfaces de aceptación de monedas rotas y otras dificultades similares que se encuentran a menudo en las máquinas no atendidas).
Además de las máquinas expendedoras, otras máquinas no atendidas incluyen: parquímetros, cabinas de peaje, lavadoras y secadoras de lavandería automática, una consola de videojuegos (es decir, una máquina recreativa de videojuegos que funciona con monedas), una mesa de billar que funciona con monedas, una máquina de dardos que funciona con monedas, una bomba de vacío o de aire que funciona con monedas (tal como las que se hallan comúnmente en estaciones de servicio), u otras máquinas que funcionan con pagos fuera de línea que dispensan bienes (por ejemplo, productos almacenados por una máquina expendedora) y/o proporcionan servicios (por ejemplo, permiten a un usuario usar los servicios, tales como jugar a un videojuego, usar la lavadora o secadora, etc.).
Como se define en la reivindicación 1, la presente invención proporciona un método para determinar pulsos eléctricos para proporcionarlos a una pluralidad de máquinas desatendidas basándose en opciones configuradas remotamente para la pluralidad de máquinas desatendidas. Aspectos adicionales de la presente invención se establecen en las reivindicaciones restantes.
En un aspecto ilustrativo, un método para presentar representaciones de eventos de unidad de aceptación de pago se realiza en un dispositivo (por ejemplo, el dispositivo móvil 150, las figuras 5 y 21) con uno o más procesadores, memoria, uno o más dispositivos de salida y dos o más capacidades de comunicación. Después de enviar una solicitud a un módulo de pago (por ejemplo, el módulo de adaptador 100, las figuras 5 y 20), a través de una primera capacidad de comunicación (por ejemplo, una tecnología/protocolo de comunicación de corto alcance tal como BLE), para iniciar una transacción con una unidad de aceptación de pago (por ejemplo, la unidad de aceptación de pago 120, las figuras 5 y 19) (a veces también denominada en el presente documento "máquina 120") asociada con el módulo de pago, el método incluye obtener una notificación desde el módulo de pago a través de la primera capacidad de comunicación, en donde la notificación indica un evento en la unidad de aceptación de pago asociada con el módulo de pago. En respuesta a la obtención de la notificación, el método incluye proporcionar una representación de la notificación a un usuario del dispositivo móvil a través de los uno o más dispositivos de salida del dispositivo móvil (por ejemplo, un mensaje visualizado en un visualizador del dispositivo móvil, una vibración producida por un mecanismo de vibración del dispositivo móvil, una alerta auditiva producida por un altavoz del dispositivo móvil, y/o similares).
En un aspecto más, un método para retroadaptar una máquina que funciona con pagos fuera de línea para aceptar pagos electrónicos se realiza en un módulo de pago (por ejemplo, el módulo de adaptador 100, las figuras 5 y 20) con uno o más procesadores, memoria, una capacidad de comunicación de corto alcance (por ejemplo, una tecnología/protocolo de comunicación de corto alcance tal como BLE), y un primer módulo de interfaz configurado para acoplar el módulo de pago con una unidad de control de una máquina que funciona con pagos fuera de línea (por ejemplo, la unidad de aceptación de pago 120, las figuras 5 y 19) (a veces también denominada en el presente documento "máquina 120"). El método incluye recibir una solicitud de transacción a través de la capacidad de comunicación de corto alcance desde un dispositivo móvil respectivo para realizar una transacción con la máquina que funciona con pagos fuera de línea. El método incluye validar la solicitud de transacción, en donde la validación de la solicitud de transacción indica que el dispositivo móvil respectivo está autorizado para iniciar el pago de la transacción por un servidor remoto (por ejemplo, el servidor 130, las figuras 5 y 22) a través de la capacidad de comunicación de largo alcance (por ejemplo, la tecnología/protocolo de comunicación de largo alcance tal como GSM, CDMA o Wi-Fi). De acuerdo con una determinación de que la solicitud de transacción es válida, el método incluye hacer que la máquina que funciona con pagos fuera de línea realice la transacción solicitada emitiendo una señal para realizar la transacción a la unidad de control de la máquina que funciona con pagos fuera de línea a través del primer módulo de interfaz.
En un aspecto adicional, un dispositivo (por ejemplo, la máquina 120 (las figuras 5 y 19), el módulo de adaptador 100 (las figuras 5 y 20), el dispositivo móvil 150 (las figuras 5 y 21), el servidor 130 (las figuras 5 y 22), o una combinación de los mismos) incluye uno o más procesadores y memoria que almacena uno o más programas para su ejecución por los uno o más procesadores, los uno o más programas incluyen instrucciones para realizar, o controlar el desempeño de, las operaciones de cualquiera de los métodos descritos en el presente documento. En algunas implementaciones, un medio de almacenamiento legible por ordenador no transitorio que almacena uno o más programas, comprendiendo los uno o más programas unas instrucciones que, cuando son ejecutadas por un dispositivo (por ejemplo, la máquina 120 (las figuras 5 y 19), el módulo de adaptador 100 (las figuras 5 y 20), el dispositivo móvil 150 (las figuras 5 y 21), el servidor 130 (las figuras 5 y 22), o una combinación de los mismos) con uno o más procesadores, hacen que el sistema informático realice, o controle el desempeño de, las operaciones de cualquiera de los métodos descritos en el presente documento. En algunas implementaciones, un dispositivo (por ejemplo, la máquina 120 (las figuras 5 y 19), el módulo de adaptador 100 (las figuras 5 y 20), el dispositivo móvil 150 (las figuras 5 y 21), el servidor 130 (las figuras 5 y 22), o una combinación de los mismos) incluye medios para realizar, o controlar el desempeño de, las operaciones de cualquiera de los métodos descritos en el presente documento.
El objeto descrito en el presente documento se señala particularmente y se reivindica claramente en la parte final de la presente memoria descriptiva. Los objetivos, características, combinaciones y ventajas descritos e implicados en el presente documento se entenderán más fácilmente tras la consideración de la siguiente descripción detallada de la invención, tomada junto con los dibujos adjuntos.
Breve descripción de los dibujos
La figura 1 es un diagrama esquemático que muestra tres zonas: una "zona de comunicación" (por ejemplo, alcance de Bluetooth), una "zona de autorización" y una "zona de pago" de acuerdo con algunas implementaciones.
La figura 2 es un diagrama esquemático que muestra las tres zonas de la figura 1 con múltiples usuarios en las mismas de acuerdo con algunas implementaciones.
La figura 3 es una tabla que ilustra el principio de crédito de manos libres o de alertar al usuario de acuerdo con algunas implementaciones.
La figura 4 es un diagrama de flujo que muestra el registro de la información de indicador de intensidad de señal recibida (RSSI) de acuerdo con algunas implementaciones.
La figura 5 es un diagrama esquemático de bloques que muestra elementos del sistema de procesamiento de pago incluyendo, pero sin limitarse a, el módulo de adaptador, la máquina, el dispositivo móvil y los servidores, así como las comunicaciones entre los mismos de acuerdo con algunas implementaciones.
La figura 6 es un diagrama esquemático de bloques que muestra tres áreas de cifrado usadas (cada una es bidireccional) entre el módulo de adaptador, la máquina, el dispositivo móvil y/o los servidores de acuerdo con algunas implementaciones.
La figura 7 es un diagrama de bloques que muestra comunicaciones, mensajería, secuencia de expendición y flujo de compra entre el módulo de adaptador, el dispositivo móvil y un servidor de gestión de sistema de acuerdo con algunas implementaciones.
La figura 8A es un diagrama de flujo de proceso esquemático que muestra elementos y características adicionales del sistema de procesamiento de pago (por ejemplo, comunicaciones, mensajería, secuencia de expendición y flujo de compra) cuando el usuario entra en la "zona de comunicación" (por ejemplo, alcance de Bluetooth) de acuerdo con algunas implementaciones.
La figura 8B es un diagrama de flujo de proceso esquemático que muestra elementos y características adicionales del sistema de procesamiento de pago (por ejemplo, comunicaciones, mensajería, secuencia de expendición y flujo de compra) cuando el usuario entra en la "zona de autorización" de acuerdo con algunas implementaciones.
La figura 8C es un diagrama de flujo de proceso esquemático que muestra elementos y características adicionales del sistema de procesamiento de pago (por ejemplo, comunicaciones, mensajería, secuencia de expendición y flujo de compra) cuando el usuario entra en la "zona de pago" y, en particular, que detalla una realización de modo de manos libres y una realización de modo de deslizamiento de acuerdo con algunas implementaciones.
La figura 8D es un diagrama de flujo de proceso esquemático que muestra elementos y características adicionales del sistema de procesamiento de pago (por ejemplo, comunicaciones, mensajería, secuencia de expendición y flujo de compra) en una transacción de expendición que incluye un bucle para múltiples transacciones de acuerdo con algunas implementaciones.
La figura 8E es un diagrama de flujo de proceso esquemático que muestra elementos y características adicionales del sistema de procesamiento de pago (por ejemplo, comunicaciones, mensajería, secuencia de expendición y flujo de compra) en el modo de inicio de sesión de acuerdo con algunas implementaciones.
La figura 8F es un diagrama de flujo de proceso esquemático que muestra elementos y características adicionales del sistema de procesamiento de pago (por ejemplo, comunicaciones, mensajería, secuencia de expendición y flujo de compra) durante el arranque del módulo de adaptador de acuerdo con algunas implementaciones.
La figura 8G es un diagrama de flujo de proceso esquemático que muestra elementos y características adicionales del sistema de procesamiento de pago (por ejemplo, comunicaciones, mensajería, secuencia de expendición y flujo de compra) durante un proceso de verificación/actualización de cuenta de acuerdo con algunas implementaciones.
Las figuras 9A-9E son diagramas de flujo que muestran etapas y características de ejemplo del sistema de procesamiento de pago (por ejemplo, comunicaciones, mensajería, secuencia de expendición y flujo de compra) de acuerdo con algunas implementaciones.
Las figuras 10A-10D muestran un dispositivo móvil con una representación gráfica de una aplicación móvil mostrada en el mismo, usándose la aplicación móvil como parte del sistema de procesamiento de pago de dispositivo móvil a máquina de acuerdo con algunas implementaciones.
La figura 11 es una vista en perspectiva del módulo de adaptador de llave en línea de acuerdo con algunas implementaciones.
La figura 12 es una vista en planta frontal del módulo de adaptador de llave en línea de la figura 11 de acuerdo con algunas implementaciones.
La figura 13 es una vista en planta posterior del módulo de adaptador de llave en línea de la figura 11 de acuerdo con algunas implementaciones.
La figura 14 es una vista lateral del módulo de adaptador de llave en línea de la figura 11 de acuerdo con algunas implementaciones.
La figura 15 es una primera vista de extremo de un receptáculo de conector del módulo de adaptador de llave en línea de la figura 11 de acuerdo con algunas implementaciones.
La figura 16 es una segunda vista de extremo de un receptáculo de conector del módulo de adaptador de llave en línea de la figura 11 de acuerdo con algunas implementaciones.
La figura 17 es una vista en perspectiva tomada desde el primer extremo del módulo de adaptador de llave en línea de la figura 11, mostrándose los conectores y los cables entre los cuales se inserta el módulo de adaptador de llave en línea en líneas discontinuas para fines ilustrativos de acuerdo con algunas implementaciones.
La figura 18 es una vista en perspectiva tomada desde el segundo extremo del módulo de adaptador de llave en línea de la figura 11, mostrándose los conectores y los cables entre los cuales se inserta el módulo de adaptador de llave en línea en líneas discontinuas para fines ilustrativos de acuerdo con algunas implementaciones.
La figura 19 es una vista en perspectiva del módulo de adaptador de llave en línea de la figura 11 dentro de una máquina expendedora de acuerdo con algunas implementaciones.
La figura 20 es un diagrama de bloques de un módulo de adaptador de acuerdo con algunas implementaciones. La figura 21 es un diagrama de bloques de un dispositivo móvil de acuerdo con algunas implementaciones. La figura 22 es un diagrama de bloques de un servidor de acuerdo con algunas implementaciones.
La figura 23 es un diagrama de flujo esquemático de un proceso para autenticar a un usuario para realizar una transacción en el sistema de procesamiento de pago de acuerdo con algunas implementaciones.
La figura 24A es un diagrama de bloques de un paquete de información radiodifundido por el módulo de pago (a veces también denominado en el presente documento "módulo de adaptador") de acuerdo con algunas implementaciones.
La figura 24B es un diagrama de bloques de una solicitud de autorización de acuerdo con algunas implementaciones.
La figura 24C es un diagrama de bloques de un testigo de concesión de autorización de acuerdo con algunas implementaciones.
La figura 24D es un diagrama de bloques de información de transacción generada por el módulo de pago de acuerdo con algunas implementaciones.
La figura 25A ilustra un diagrama de flujo esquemático de un proceso para proporcionar una representación de un evento de máquina en un dispositivo móvil de acuerdo con algunas implementaciones
La figura 25B es un diagrama de flujo esquemático de un proceso para procesar información de acuse de recibo en el sistema de procesamiento de pago de acuerdo con algunas implementaciones.
Las figuras 26A-26D ilustran interfaces de usuario de ejemplo para proporcionar una representación de un evento de máquina en un dispositivo móvil de acuerdo con algunas implementaciones.
Las figuras 27A-27B ilustran un diagrama de tipo diagrama de flujo de un método para presentar representaciones de eventos de unidad de aceptación de pago de acuerdo con algunas implementaciones.
La figura 28A ilustra un diagrama de bloques de una máquina que funciona con pagos fuera de línea de acuerdo con algunas implementaciones.
La figura 28B ilustra señales muestreadas por el módulo de pago de acuerdo con algunas implementaciones.
Las figuras 29A-29B ilustran un diagrama de tipo diagrama de flujo de un método 1600 para retroadaptar una máquina que funciona con pagos fuera de línea para aceptar pagos electrónicos de acuerdo con algunas implementaciones.
La figura 30 ilustra un diagrama de tipo diagrama de flujo de un método para habilitar que una máquina que funciona con pagos acepte pagos electrónicos de acuerdo con algunas implementaciones.
La figura 31 es un diagrama de flujo esquemático de un proceso para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota para la máquina no atendida, de acuerdo con algunas implementaciones.
La figura 32 ilustra un ejemplo de una interfaz de usuario en un dispositivo móvil que se usa para seleccionar una de las opciones configuradas de forma remota para la máquina no atendida, de acuerdo con algunas implementaciones.
La figura 33 es un diagrama de flujo de un método para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota para la máquina no atendida, de acuerdo con algunas implementaciones.
De principio a fin de las diversas vistas de los dibujos, números de referencia semejantes se refieren a partes correspondientes.
Descripción detallada de la invención
En el presente documento se divulga un sistema de procesamiento de pago o, más específicamente, un sistema de procesamiento de pago de dispositivo móvil a máquina para procesar transacciones a través de una conexión de red no persistente. El sistema de procesamiento de pago de dispositivo móvil a máquina divulgado en el presente documento se centra en el espacio de venta al por menor no atendido (por ejemplo, una unidad de aceptación de pago 120, a veces también denominada en el presente documento "máquina 120"). Más específicamente, el sistema de procesamiento de pago de dispositivo móvil a máquina divulgado en el presente documento permite a un usuario (que tiene un dispositivo móvil 150 con una aplicación móvil 140 en el mismo) realizar una compra sin efectivo desde una unidad de aceptación de pago 120 (que tiene un módulo de adaptador 100 asociado con la misma).
El sistema de procesamiento de pago de dispositivo móvil a máquina descrito en el presente documento se puede implementar con una o más de las siguientes características: característica de instalación fácil, característica de conexión de red no persistente; una característica de modo manual (deslizar para pagar); una característica de modo de manos libres; y una característica de transacciones de expendición múltiple (de multiexpendición).
Instalación fácil: La instalación es muy fácil, no requiere herramienta alguna, no requiere configuración alguna y lleva tan solo 30 segundos. Esto se logra usando un módulo de adaptador 100 (a veces también denominado en el presente documento "módulo de pago 100") tal como un diseño de llave en línea (un dispositivo de hardware con software en el mismo) para su inserción en línea dentro de un bus multipunto (MDB) de una unidad de aceptación de pago 120 (por ejemplo, una máquina expendedora) (a veces también denominada en el presente documento "la máquina 120"). La instalación es tan simple como "desconectar" (apagar) la máquina 120, identificar el "hilo" que conecta con un mecanismo de recepción de pago (por ejemplo, el mecanismo de monedas), desconectar el hilo (de tal manera que haya dos extremos sueltos, tales como un adaptador o extremo de conexión macho de un MDB y un adaptador o extremo de conexión hembra de un MDB), enchufar (insertar) el módulo de adaptador 100 en serie ("en línea") con el hilo (por ejemplo, conectar el adaptador hembra de MDB a un adaptador macho del módulo de adaptador 100 y conectar el adaptador macho de<m>D<b>a un adaptador hembra del módulo de adaptador 100), meter el hilo y el módulo de adaptador 100 instalado de nuevo en su posición y "conectar" (encender) la máquina 120. La mayoría de las máquinas expendedoras fabricadas desde 1995 tienen esta tecnología de MDB convencional de la industria que permitiría esta instalación fácil de 30 segundos. En máquinas sin tecnología de MDB, el módulo de adaptador 100 se puede configurar o diseñar para funcionar con otros protocolos en serie o activar un conmutador. En esencia, el módulo de adaptador 100 simula el establecimiento de un pago en la unidad de aceptación de pago 120 de una manera muy similar a otras formas alternativas de pago (por ejemplo, efectivo).
Conexión de red no persistente: Aunque las unidades de aceptación de pago (o "máquinas") que solo aceptan efectivo (por ejemplo, Papel moneda y monedas) pueden no requerir una conexión (persistente o no persistente) a una red, las unidades de aceptación de pago tradicionales que aceptan pagos sin efectivo (por ejemplo, tarjetas de crédito, tarjetas de débito y métodos alternativos de pago de dispositivo móvil usando, por ejemplo, teléfonos inteligentes) requieren una conexión persistente a una red (cableada o inalámbrica) para facilitar los pagos sin efectivo. En otras palabras, sin una conexión de red persistente (continua o accesible a petición), las unidades de aceptación de pago tradicionales no pueden aceptar pagos sin efectivo. La mayoría de las unidades de aceptación de pago tradicionales que aceptan pagos sin efectivo incluyen la tecnología para lograr esta conexión de red persistente que les permite conectarse a un servidor remoto. Si la conexión de red a una máquina tradicional se interrumpe temporalmente, los pagos sin efectivo no estarán disponibles temporalmente. Si la máquina está ubicada en una ubicación en donde no hay disponible conexión de red alguna, no es posible realizar pagos sin efectivo. Además de usar un dispositivo móvil 150 como un intermediario entre las unidades de aceptación de pago 120 y el servidor 130, el sistema de procesamiento de pago de dispositivo móvil a máquina descrito en el presente documento minimiza (es decir, el modo manual) o elimina (es decir, el modo de manos libres) la interacción de usuario con el dispositivo móvil 150. Además, en algunas implementaciones, el sistema de procesamiento de pago de dispositivo móvil a máquina descrito en el presente documento facilita la aceptación de pago sin efectivo sin requerir conexión de red alguna cerca de la unidad de aceptación de pago 120. En algunas implementaciones, cuando el sistema de procesamiento de pago de dispositivo móvil a máquina descrito en el presente documento está ubicado en una ubicación remota en donde la conexión de red no está disponible, el sistema de procesamiento de pago de dispositivo móvil a máquina, por lo tanto, aún puede aceptar pagos sin efectivo.
Modo manual (deslizar para pagar): El uso de una característica de "deslizar para pagar" (o simplemente "deslizar") se refiere a la acción de un usuario implementada en su dispositivo móvil 150 en donde este rápidamente pasa rozando con su dedo (u otra interacción predeterminada) la pantalla táctil 152 del dispositivo móvil (las figuras 10A-10D) u otros dispositivos de entrada asociados con el dispositivo móvil 150. Desde la perspectiva del usuario, cuando el usuario está dentro del alcance, una aplicación móvil 140 preinstalada se conecta automáticamente a la unidad de aceptación de pago 120 (por ejemplo, una máquina expendedora). La aplicación móvil 140 podría visualizar (en la pantalla táctil 152) un saldo de prepago que el usuario "desliza" para transferir el pago a la unidad de aceptación de pago 120. El usuario podría observar los fondos transferidos en la pantalla táctil 152 del dispositivo móvil 150 y/o en el visualizador 122, 124 (la figura 19) de la unidad de aceptación de pago 120. La transacción se completa igual que si se hubiera insertado efectivo en la máquina 120 con el usuario introduciendo su selección en la unidad de aceptación de pago 120 y la unidad de aceptación de pago 120 dispensando el producto o servicio. Una vez se ha realizado la selección, el cambio se devuelve al dispositivo móvil 150 y esto se puede mostrar en la pantalla táctil 152 del dispositivo móvil 150.
Modo de manos libres: Una característica de "pago de manos libres" (o simplemente "manos libres") se usaría muy probablemente con las unidades de aceptación de pago 120 "favoritas" (por ejemplo, una máquina expendedora de uso frecuente en el trabajo o la escuela de un usuario). Desde la perspectiva del usuario, este se aproximaría a la unidad de aceptación de pago 120 favorita y observaría que el visualizador 122, 124 (la figura 19) de la unidad de aceptación de pago 120 muestra fondos disponibles, seleccionaría el producto o servicio usando los mecanismos de entrada de la unidad de aceptación de pago (por ejemplo, unos botones 126 o un visualizador de pantalla táctil 124 mostrado en la figura 19) y recuperaría los servicios o productos dispensados. Esto sería así de simple. Más específicamente, cuando el usuario está dentro del alcance, una aplicación móvil 140 preinstalada se conecta automáticamente a la unidad de aceptación de pago 120 (por ejemplo, una máquina expendedora). El usuario puede dejar el dispositivo móvil 150 en un bolsillo, bolso, maletín, mochila u otro soporte. A medida que el usuario se aproxima a la unidad de aceptación de pago 120 y está aproximadamente a una distancia "al alcance de la mano" (por ejemplo, de 3 a 5 pies (de 0,91 a 1,53 metros)) de la unidad de aceptación de pago 120, el usuario podría observar los fondos transferidos en el visualizador 122, 124 (la figura 19) de la unidad de aceptación de pago 120. La transacción se completa igual que si se hubiera insertado efectivo en la unidad de aceptación de pago 120 con el usuario introduciendo su selección en la unidad de aceptación de pago 120 y la unidad de aceptación de pago 120 dispensando el producto o servicio. Una vez se haya realizado la selección, el cambio se devuelve al dispositivo móvil 150. La figura 3 detalla cuándo estaría disponible el modo de manos libres.
Transacciones de expendición múltiple (multiexpendición): Tanto el modo manual como el de manos libres se podrían usar múltiples veces en secuencia (implementados, por ejemplo, como un bucle) de tal manera que un usuario pueda realizar múltiples compras. Después de hacer su primera selección y recibir su producto (o servicio), el usuario observaría que había fondos adicionales disponibles en el visualizador 122, 124 (la figura 19) en la unidad de aceptación de pago 120. Este podría hacer otra selección (o múltiples selecciones) y recibir un producto o productos (o un servicio o servicios) adicionales. Más específicamente, el visualizador 122, 124 (la figura 19) se puede restablecer como si la transacción se hubiera completado, pero entonces, debido a que el usuario sigue estando dentro del alcance, la aplicación móvil 140 enviaría otro crédito a la unidad de aceptación de pago 120, permitiendo una segunda compra. Cuando el usuario se aleja, el sistema se despeja (por ejemplo, devuelve los fondos no usados a la aplicación 140 en el dispositivo móvil 150).
Las características descritas anteriormente, solas o en combinación con otras características descritas en el presente documento, revolucionarán la industria de venta al por menor automatizada, con un volumen de cien mil millones de dólares. El hardware es de muy bajo coste y no hay tasas recurrentes debido a que no se requiere conexión celular alguna en la máquina 120. Usando el sistema de procesamiento de pago de dispositivo móvil a máquina descrito en el presente documento, los operadores de las máquinas 120 pueden aumentar la frecuencia de las visitas por los compradores, y los artículos vendidos con cada visita.
El sistema de procesamiento de pago de dispositivo móvil a máquina descrito en el presente documento se puede implementar como un aparato, sistema y/o método para habilitar pagos a una máquina 120 a través de un dispositivo móvil 150. El sistema de procesamiento de pago de dispositivo móvil a máquina se puede entender mejor con referencia a los dibujos, pero el sistema de procesamiento de pago de dispositivo móvil a máquina mostrado no pretende ser de naturaleza limitante.
Definiciones
Antes de describir el sistema de procesamiento de pago de dispositivo móvil a máquina y las figuras, se debería aclarar parte de la terminología. Obsérvese que los términos y expresiones pueden tener definiciones y/o ejemplos adicionales de principio a fin de la memoria descriptiva. Cuando no se defina específicamente de otro modo, se da a las palabras, expresiones y acrónimos su significado convencional en la técnica. Los siguientes párrafos proporcionan algunas de las definiciones para los términos y expresiones usados en el presente documento.
Módulo de adaptador 100: Como se muestra en las figuras 1 y 2, el módulo de adaptador 100 (a veces también denominado en el presente documento el "módulo de pago 100") es un dispositivo físico que se instala en una máquina 120 (una unidad de aceptación de pago 120). El módulo de adaptador 100 mostrado es un dispositivo de llave en línea (un dispositivo de hardware con software en el mismo) que se puede insertar en línea dentro de un bus multipunto (MDB) de una máquina 120. El módulo de adaptador 100 sirve de puente para la comunicación entre la máquina 120 y un dispositivo móvil 150. Aunque se describe como un componente único, se debería hacer notar que el módulo de adaptador 100 se podría implementar como una pluralidad de dispositivos o integrarse en otros dispositivos (por ejemplo, componentes de una máquina 120). En su forma de componente única, el módulo de adaptador 100 se puede insertar fácilmente en una máquina 120 de tal manera que la máquina 120 sea capaz de realizar características nuevas con la ayuda del módulo de adaptador 100. La figura 20 muestra componentes asociados con el módulo de adaptador 100. Como se muestra en la figura 20, la unidad de comunicaciones 770 del módulo de adaptador 100 incluye una capacidad de comunicación de corto alcance 776 (por ejemplo, mecanismos de Bluetooth). El ejemplo mostrado se puede dividir en múltiples componentes distintos que están asociados entre sí o el ejemplo se puede incorporar a o extraer de otra tecnología (por ejemplo, un ordenador o una unidad de aceptación de pago) siempre que los componentes estén asociados entre sí.
Dispositivo móvil 150 y Aplicación 140 (también denominada "aplicación móvil", "app móvil" o "aplicación"): En general, un dispositivo móvil 150 puede ser un dispositivo móvil personal 150 de un usuario. El dispositivo móvil 150 (con una aplicación móvil 140 en el mismo) actúa como un puente de comunicación entre el módulo de adaptador 100 (asociado con una unidad de aceptación de pago 120) y el servidor 130. Sin embargo, el dispositivo móvil 150 y la aplicación 140 no son de "confianza" ya que las comunicaciones (transmisiones) que este pasa están cifradas. Las comunicaciones cifradas (seguras) son indescifrables (no cifrables, ilegibles y/o inutilizables) por el dispositivo móvil 150. Esto mantiene las comunicaciones pasadas entre el módulo de adaptador 100 y el servidor 130 seguras y a salvo de piratería. Los dispositivos móviles incluyen, pero sin limitarse a, teléfonos inteligentes, tabletas u ordenadores portátiles, o asistentes digitales personales (PDA), tarjetas inteligentes u otra tecnología (por ejemplo, una combinación de hardware y software) conocida o que no se haya descubierto aún que tiene una estructura y/o capacidades similares a los dispositivos móviles descritos en el presente documento. El dispositivo móvil 150 tiene preferiblemente una aplicación (por ejemplo, la aplicación 140) ejecutándose en el mismo. El término "aplicación" se usa ampliamente para incluir cualquier programa o programas de software capaces de implementar las características descritas en el presente documento. Las figuras 10A-10D muestran interfaces de usuario para la aplicación 140 visualizada por el dispositivo móvil 150. Se debería hacer notar que se puede suponer que la expresión "dispositivo móvil" incluye la aplicación relevante a menos que se exponga específicamente lo contrario. De manera similar, se debería hacer notar que se puede suponer que una "aplicación" se está ejecutando en un dispositivo móvil asociado a menos que se exponga específicamente lo contrario. La figura 21 muestra componentes asociados con el dispositivo móvil 150. El ejemplo mostrado se puede dividir en múltiples componentes distintos que están asociados entre sí o el ejemplo se puede incorporar a o extraer de otra tecnología (por ejemplo, el propio teléfono celular) siempre que los componentes estén asociados entre sí.
Unidad de aceptación de pago 120 (o máquina 120): Una unidad de aceptación de pago 120 (o la máquina 120) es un equipo que requiere el pago por la dispensación de un producto y/o servicio. Las unidades de aceptación de pago 120 pueden ser máquinas expendedoras, parquímetros, cabinas de peaje, lavadoras y secadoras de lavandería automática, máquinas recreativas de videojuegos, quioscos, cabinas de fotografías, cabinas de peaje, máquinas expendedoras de billetes de transporte y otras unidades de aceptación de pago 120 conocidas o que no se hayan descubierto aún. Algunas unidades de aceptación de pago 120 pueden aceptar pagos sin efectivo (pagos aparte de efectivo (papel moneda y monedas)) aceptando pagos a partir de, por ejemplo, tarjetas de crédito, tarjetas de débito y dispositivos móviles.
Conexiones de red: Para los fines de este análisis, una conexión de red persistente es una conexión de comunicaciones cableada o inalámbrica que está en curso (por ejemplo, una conexión dedicada, una conexión en línea dedicada y/o una conexión permanentemente cableada) o es accesible a petición (por ejemplo, la capacidad de la máquina para realizar una conexión temporal a un servidor o la capacidad del usuario de contactar con un servidor desde su dispositivo móvil). Habitualmente, la conexión de red persistente se ha llevado a cabo a través de una "tecnología de comunicación de largo alcance" o un "protocolo de comunicación de largo alcance" (por ejemplo, permanentemente cableado, tecnología de red telefónica, tecnología celular (por ejemplo, GSM, CDMA o similares), tecnología de Wi-Fi, red de área extensa (WAN), red de área local (LAN) o cualquier tecnología de comunicación cableada o inalámbrica a través de Internet que sea conocida o que no se haya descubierto aún). Tradicionalmente, las máquinas que aceptan pagos aparte de efectivo requieren una conexión persistente (en curso o accesible a petición) a una red para facilitar el pago. Esto es cierto para las máquinas que aceptan, por ejemplo, tarjetas de crédito y tarjetas de débito. Las unidades de aceptación de pago 120 descritas en el presente documento no requieren una conexión de red persistente tradicional. El dispositivo móvil 150 del usuario actúa como un puente de comunicación entre el módulo de adaptador 100 y el servidor 130. Las comunicaciones entre los dispositivos móviles de usuario 150 y los servidores (por ejemplo, un servidor de gestión de sistema 130 y/o un servidor de fuente de financiación 160) tienen lugar usando tecnología de comunicación de largo alcance. Las comunicaciones entre los dispositivos móviles de usuario 150 y el módulo de adaptador 100 de la unidad de aceptación de pago 120 se realizan usando una "tecnología de comunicación de corto alcance" o un "protocolo de comunicación de corto alcance" (por ejemplo, Bluetooth (tal como Bluetooth 4.0, Bluetooth Inteligente, Bluetooth de Baja Energía (BLE)), comunicación de campo cercano (NFC), Banda Ultra Ancha (UWB), identificación por radiofrecuencia (RFID), inalámbrica por infrarrojos, inalámbrica por inducción o cualquier tecnología cableada o inalámbrica que se pueda usar para comunicarse a una distancia pequeña (aproximadamente a cien pies (30,5 metros) o más cerca) que sea conocida o no se haya descubierto aún). Por lo tanto, ni el módulo de adaptador 100 ni la unidad de aceptación de pago 120 requieren una conexión de red inalámbrica de largo alcance persistente tradicional. La tecnología de comunicaciones mostrada en las figuras se puede sustituir con una tecnología de comunicaciones alternativa y, por lo tanto, las tecnologías de comunicaciones mostradas específicas no tienen por objeto ser limitantes. Por ejemplo, la tecnología de Wi-Fi se podría sustituir con otra tecnología de comunicación de largo alcance.
Servidor: Un servidor es el servidor de procesamiento de anfitrión que puede ser operado por la empresa que ejecuta el sistema de procesamiento de pago. Para cada usuario, el servidor 130 preferiblemente mantiene al menos un "monedero virtual" que tiene al menos un "saldo" (que puede ser de 0 dólares) de fondos designados para los cuales el servidor 130 lleva una contabilidad. El saldo puede representar, por ejemplo, "efectivo" o puede ser un "valor promocional" que representa fondos que se pueden gastar en determinadas circunstancias. Si estos fondos comienzan a agotarse, se puede notificar al usuario (por ejemplo, a través de la aplicación 140 en el dispositivo móvil 150) que es necesario designar y/o transferir fondos adicionales. Como alternativa, los fondos procedentes de otras fuentes (por ejemplo, el servidor de fuentes de financiación 160) se pueden transferir automáticamente para restablecer un saldo predeterminado. El saldo también se puede aumentar basándose en una promoción (por ejemplo, puntos ganados o vales). Como se muestra en la figura 22, el servidor incluye unos procesadores 950, una memoria 960 (que llevaría una contabilidad del saldo del usuario de una manera similar a una tarjeta de regalo) y unos sistemas de comunicación 970 apropiados. Como se muestra en la figura 22, la unidad de comunicaciones 970 del servidor 130 incluye una capacidad de comunicación de largo alcance 972 (por ejemplo, tecnología celular y/o mecanismos de Wi-Fi). El servidor 130 también incluye una unidad de seguridad 955 para cifrar y descifrar mensajes. El servidor 130 recibe una solicitud de autorización (a veces también denominada en el presente documento "SolicitudAut") procedente del módulo de adaptador 100 (a través de un dispositivo móvil 150) y, si hay fondos disponibles, devuelve una concesión de autorización (a veces también denominada en el presente documento "ConcesiónAut" o un "testigo de concesión de autorización") de fondos. La figura 22 muestra componentes asociados con el servidor 130. El ejemplo mostrado se puede dividir en múltiples componentes distintos que están asociados entre sí o el ejemplo se puede incorporar a o extraer de otra tecnología (por ejemplo, un ordenador o un ordenador central) siempre que los componentes estén asociados entre sí.
Anunciar presencia: Cada módulo de adaptador 100 anuncia su presencia radiodifundiendo señales (señales de radiodifusión de anuncios) a los dispositivos móviles en las zonas 102, 104, 106. Cada módulo de adaptador 100 puede escuchar los anuncios de otros módulos de adaptador.
Indicador de intensidad de señal recibida (RSSI): El módulo de adaptador 100 puede tener una intensidad de señal de autocalibración para determinar umbrales de zona (por ejemplo, un umbral de zona de pago y un umbral de zona de autenticación). En el momento en el que el usuario selecciona un artículo (producto o servicio) de la unidad de aceptación de pago 120, se registra el indicador de intensidad de señal recibida (RSSI). En este momento, se conjetura que el usuario está "al alcance de la mano" (que puede ser una longitud predeterminada que se aproxima a la distancia de un usuario parado frente a una máquina para el fin de realizar una compra) de la unidad de aceptación de pago 120. Se lleva a cabo un cálculo matemático (es decir, heurística dentro del alcance) para inferir el umbral de RSSI óptimo al que el pago debería ser desencadenado por una aplicación 140 en un dispositivo móvil 150. El umbral puede ser específico de la unidad de aceptación de pago y puede variar a lo largo de un período de tiempo. Este umbral de zona óptimo se notifica preferiblemente al dispositivo móvil 150 durante una toma de contacto inicial.
Heurística dentro del alcance: Un cálculo matemático que determina el umbral de RSSI para determinar cuándo un usuario está en la zona de autorización 104 y/o en la zona de pago 102. Este cálculo puede tener en cuenta numerosos puntos de datos históricos, así como información específica de la transacción, tal como qué dispositivo móvil 150 se está usando, el tipo de unidad de aceptación de pago, entre otros factores. Preferiblemente, el RSSI se registra mientras el usuario está haciendo su selección (esta es la única vez en todo el proceso que el usuario definitivamente estará "al alcance" (por ejemplo, este estará al alcance de la mano de la máquina 120 debido a que está interaccionando físicamente con la máquina 120). El tipo de dispositivo móvil de usuario 150, datos de acelerómetro (por ejemplo, si el usuario está en movimiento o estacionario) y/u otra información también se pueden registrar mientras el usuario está haciendo su selección. El módulo de adaptador 100 puede dar un RSSI de referencia para la zona de pago 102 para la máquina 120, y la aplicación 140 puede realizar un ajuste de /- basándose en el dispositivo móvil 150 específico en el que está instalado el mismo. A lo largo de un período de tiempo, el sistema de procesamiento de pago continúa mejorándose a sí mismo basándose en puntos de datos adicionales.
Solicitud de autorización ("SolicitudAut:): Cuando un usuario entra en la zona de autorización 104, el dispositivo móvil 150 notifica al módulo de adaptador 100 y el módulo de adaptador 100 envía una solicitud de autorización segura (por ejemplo, la solicitud de autorización cifrada) como un "mensaje" (también denominado comunicación o transmisiones) al servidor 130 a través del dispositivo móvil 150. El cifrado se puede realizar mediante una unidad de seguridad 755 (la figura 20) con tecnología de seguridad (por ejemplo, medios de cifrado y de descifrado) que puede estar asociada con la unidad de procesamiento 750 y/o la memoria 760. Resulta significativo que la SolicitudAut es una solicitud de autorización de fondos, no una solicitud de autorización de una transacción. El fin de los fondos no tiene relevancia para el servidor 130.
Testigo de concesión de autorización ("ConcesiónAut"): Este es un "mensaje" (también denominado comunicación o transmisiones) cifrado por la unidad de seguridad 955 (la figura 22) con tecnología de seguridad (por ejemplo, medios de cifrado y de descifrado) del servidor 130 con la clave privada única correspondiente al módulo de adaptador 100. La concesión de autorización segura (por ejemplo, la concesión de autorización cifrada) se pasa desde el servidor 130 al módulo de adaptador 100 a través del dispositivo móvil 150 en forma de mensaje. Sin embargo, el dispositivo móvil 150 no es capaz de descifrar y/o leer el mensaje. La concesión de autorización es en respuesta a la solicitud de autorización. La cantidad de los fondos concedidos por la ConcesiónAut puede ser determinada por factores que incluyen, pero sin limitarse a, la cantidad de fondos disponibles (o, si no hay fondos disponibles, se podría conceder un mini-préstamo), una cantidad preautorizada (por ejemplo, establecida por el servidor, establecida por el usuario durante la configuración, establecida por la fuente de financiación o una cantidad convencional), limitada por tiempo (por ejemplo, solo una cierta cantidad por hora, o una cantidad predeterminada en momentos específicos del día), limitada a la cantidad máxima de un artículo en la máquina (o suficiente para dos o tres artículos en la máquina), o uno o más de estos y otros factores. Resulta significativo que la ConcesiónAut hace que los fondos estén disponibles, pero no autoriza una transacción. La ConcesiónAut puede tener un período de vencimiento asociado, ya que esta puede vencer si la misma no se usa en un período de tiempo predeterminado. El período de tiempo antes de que venza la ConcesiónAut puede ser determinado por factores que incluyen, pero sin limitarse a, la confianza del usuario (por ejemplo, el usuario tiene un historial prolongado con el sistema de procesamiento de pago o algún proveedor conocido (por ejemplo, un proveedor de tarjetas de crédito, banco o cooperativa de crédito), el usuario tiene una buena calificación crediticia o el usuario tiene un saldo de monedero grande), un período de tiempo preautorizado (por ejemplo, establecido por el servidor, establecido por el usuario durante la configuración, establecido por la fuente de financiación, o un período de tiempo convencional), limitado por el tiempo (por ejemplo, períodos de tiempo predeterminados en momentos específicos del día, tales como tiempos más largos durante el desayuno, el almuerzo y la cena), limitado por la máquina o los productos o servicios vendidos en la máquina, limitado por el número de otros usuarios cerca de la máquina (por ejemplo, si es una máquina abarrotada, la ConcesiónAut puede vencer más rápido), o uno o más de estos y otros factores. La ConcesiónAut sigue siendo válida hasta que esta vence o se produce algún otro evento para finalizar su validez (por ejemplo, el usuario la cancela). Esto significa que, en circunstancias normales, el dispositivo móvil 150 mantendrá la ConcesiónAut que autoriza el uso de fondos durante un período de tiempo predeterminado que permitirá al usuario un tiempo suficiente para realizar una compra. Se puede considerar que la cantidad autorizada es el "saldo de monedero" que se mantiene en un "monedero" virtual.
Sincronización: El tiempo se puede sincronizar con el módulo de adaptador 100 desde el servidor 130. El servidor 130 envía información de tiempo con mensajes cifrados y el módulo de adaptador 100 usa el tiempo codificado en los mensajes para la sincronización.
El sistema de procesamiento de pago de dispositivo móvil a máquina y los componentes del mismo pueden tener hardware, software y/o firmware asociados (una variación, subconjunto o híbrido de hardware y/o software). El término "hardware" incluye al menos una "unidad de procesamiento", "procesador", "ordenador", "aparato programable" y/u otra tecnología conocida o que no se haya descubierto aún capaz de ejecutar instrucciones o etapas (mostradas como la unidad de procesamiento 750 en la figura 20, la unidad de procesamiento 850 en la figura 21 y la unidad de procesamiento 950 en la figura 22). El término "software" incluye al menos un "programa", "subprograma", "serie de instrucciones" u otras instrucciones de hardware, o código de programa legible por hardware, conocidos o que no se hayan descubierto aún. El software se puede cargar en hardware (o firmware) para producir una "máquina", de tal manera que el software se ejecute en el hardware para crear estructuras para implementar las funciones descritas en el presente documento. Además, el software se puede cargar en el hardware (o firmware) con el fin de indicar al sistema de procesamiento de pago de dispositivo móvil a máquina (y a componentes del mismo) que funcione de una manera particular descrita en el presente documento o que realice una serie de etapas operativas, como se describe en el presente documento. El "hardware", tal como el módulo de adaptador 100, el dispositivo móvil 150 y la unidad de aceptación de pago 120, puede tener software (por ejemplo, programas y aplicaciones) cargado en el mismo. La expresión "cargado en el hardware" también incluye cargarse en una memoria (mostrada como la memoria 760 en la figura 20, la memoria 860 en la figura 21 y la memoria 960 en la figura 22) asociada con o accesible por el hardware. El término "memoria" se define como que incluye cualquier tipo de medio legible por hardware (u otra tecnología) (también denominado medio de almacenamiento legible por ordenador) incluyendo, pero sin limitarse a, medios de almacenamiento unidos (por ejemplo, unidades de disco duro, unidades de disco en red, servidores), medios de almacenamiento interno (por ejemplo, RAM, ROM, EPROM, FLASH-EPROM o cualquier otro chip o cartucho de memoria), medios de almacenamiento extraíbles (por ejemplo, CD, DVD, unidades flash, tarjetas de memoria, disquetes, discos flexibles), firmware y/u otros medios de almacenamiento conocidos o que no se hayan descubierto aún. Dependiendo de su fin, la memoria puede ser transitoria y/o no transitoria. "Mensajes", "comunicaciones", "señales" y/o "transmisiones" apropiados (lo que incluye diversos tipos de información y/o instrucciones, incluyendo, pero sin limitarse a, datos, órdenes, bits, símbolos, voltajes, corrientes, ondas electromagnéticas, partículas o campos magnéticos, partículas o campos ópticos y/o cualquier combinación de los mismos) a través de "rutas de comunicación", "rutas de transmisión" y otros medios para la transmisión de señales apropiados, incluyendo cualquier tipo de conexión entre dos elementos en el sistema de procesamiento de pago (por ejemplo, el módulo de adaptador 100, el dispositivo móvil 150, la unidad de aceptación de pago 120, los sistemas y subsistemas de hardware y la memoria) se usarían según sea apropiado para facilitar los controles y las comunicaciones.
Se debería hacer notar que los términos "programas" y "subprogramas" se definen como una serie de instrucciones que se pueden implementar como software (es decir, instrucciones de programa informático o código de programa legible por ordenador) que se pueden cargar en un ordenador para producir una "máquina", de tal manera que las instrucciones que se ejecutan en el ordenador crean estructuras para implementar las funciones descritas en el presente documento o mostradas en las figuras. Además, estos programas y subprogramas se pueden cargar en un ordenador de tal manera que estos puedan indicar al ordenador que funcione de una manera particular, de tal manera que las instrucciones produzcan un artículo de fabricación que incluya estructuras de instrucciones que implementen la función especificada en el bloque o bloques de diagrama de flujo. Los programas y subprogramas también se pueden cargar en un ordenador para hacer que se realicen una serie de etapas operativas en o mediante el ordenador para producir un proceso implementado por ordenador de tal manera que las instrucciones que se ejecutan en el ordenador proporcionan etapas para implementar las funciones especificadas en el bloque o bloques de diagrama de flujo. La expresión "cargado en un ordenador" también incluye cargarse en la memoria del ordenador o en una memoria asociada con o accesible por el ordenador. Programas y subprogramas separados, aunque interaccionantes, se pueden asociar con los módulos de adaptador 100, el servidor 130 y el dispositivo móvil 150 (incluyendo la aplicación móvil 140) y estos programas y subprogramas se pueden dividir en subprogramas más pequeños para realizar funciones específicas.
Los términos "mensajes", "comunicaciones", "señales" y/o "transmisiones" incluyen diversos tipos de información y/o instrucciones incluyendo, pero sin limitarse a, datos, órdenes, bits, símbolos, voltajes, corrientes, ondas electromagnéticas, partículas o campos magnéticos, partículas o campos ópticos y/o cualquier combinación de los mismos. Se puede usar una tecnología apropiada para implementar las "comunicaciones", "señales" y/o "transmisiones" que incluyen, por ejemplo, transmisores, receptores y transceptores. Las "comunicaciones", las "señales" y/o las "transmisiones" descritas en el presente documento usarían la tecnología apropiada para su fin previsto. Por ejemplo, las comunicaciones permanentemente cableadas (por ejemplo, comunicaciones en serie cableadas) usarían una tecnología apropiada para unas comunicaciones permanentemente cableadas, las comunicaciones de corto alcance (por ejemplo, Bluetooth) usarían una tecnología apropiada para unas comunicaciones cercanas y las comunicaciones de largo alcance (por ejemplo, GSM, CDMA, Wi-Fi o similares) usarían una tecnología apropiada para unas comunicaciones remotas a través de una distancia. En el presente documento se incluye una seguridad apropiada (por ejemplo, SSL o TLS) para cada tipo de comunicación. Las unidades de seguridad 755 y 955 incluyen tecnología para asegurar mensajes. La tecnología de seguridad puede ser, por ejemplo, tecnología (por ejemplo, software o hardware) de cifrado/descifrado. Aunque el cifrado/descifrado se analiza principalmente como si se realizara con una clave privada única, estrategias alternativas incluyen, pero sin limitarse a, un cifrado/descifrado realizado con claves públicas/privadas (es decir, criptografía asimétrica) u otras estrategias de cifrado/descifrado conocidas o que no se hayan descubierto aún. Se considera que los mecanismos de entrada y/o de salida apropiados, incluso si no se describen específicamente, son parte de la tecnología descrita en el presente documento. La unidad de comunicaciones 770 (mostrada en la figura 20) del módulo de adaptador 100 se muestra como si incluyera unos mecanismos de entrada y de salida 772, 774 apropiados que se pueden implementar en asociación (por ejemplo, directa o indirectamente en comunicación funcional) con unos adaptadores macho y hembra 720, 730 del módulo de adaptador 100. La unidad de comunicaciones 870 (mostrada en la figura 21) del dispositivo móvil 150 incluye mecanismos para comunicaciones de largo alcance (mostradas como la capacidad de comunicación de largo alcance 872, tal como mecanismos celulares y/o de Wi-Fi) para comunicarse con el servidor 130 y comunicaciones de corto alcance (mostradas como la capacidad de comunicación de corto alcance 876, tal como mecanismos de Bluetooth) para comunicarse con el módulo de adaptador 100.
Cuando se usan en relación con "comunicaciones", "señales" y/o "transmisiones", los términos "proporcionar" y "proporcionando" (y variaciones de los mismos) tienen por objeto incluir medios convencionales de provisión, incluyendo "transmitir" y "transmitiendo", pero también se pueden usar para disposiciones no tradicionales siempre que las "comunicaciones", "señales" y/o "transmisiones" sean "recibidas" (lo que también puede significar obtenidas). Los términos "transmitir" y "transmitiendo" (y variaciones de los mismos) tienen por objeto incluir medios convencionales de transmisión, pero también se pueden usar para transmisiones no tradicionales siempre que las "comunicaciones", "señales" y/o "transmisiones" sean "enviadas". Los términos "recibir" y "recibiendo" (y variaciones de los mismos) tienen por objeto incluir medios convencionales de recepción, pero también se pueden usar para métodos no tradicionales de obtención siempre que las "comunicaciones", "señales" y/o "transmisiones" sean "obtenidas".
El término "asociado" se define como que significa integrante u original, retroadaptado, unido, conectado (incluyendo conectado funcionalmente), situado cerca de y/o accesible por. Por ejemplo, si la interfaz de usuario (por ejemplo, un visualizador tradicional 122 (la figura 19), un visualizador de pantalla táctil 124 (la figura 19), un teclado 126 (la figura 19), los botones 126 (la figura 19, que se muestran como parte del teclado numérico 126), un teclado (no mostrado) y/u otro mecanismo de entrada o de salida) está asociado con una unidad de aceptación de pago 120, la interfaz de usuario puede ser original de la unidad de aceptación de pago 120, retroadaptarse en la unidad de aceptación de pago 120, unirse a la unidad de aceptación de pago 120 y/o estar cerca de la unidad de aceptación de pago 120. De manera similar, los módulos de adaptador 100 pueden estar asociados con las unidades de aceptación de pago 120 ya que los módulos de adaptador 100 pueden ser originales de la unidad de aceptación de pago 120, retroadaptarse en la unidad de aceptación de pago 120, unirse a la unidad de aceptación de pago 120 y/o estar cerca de la unidad de aceptación de pago 120.
VISIÓN GENERAL DEL SISTEMA
Las figuras 5, 6 y 7 muestran conjuntamente componentes principales del sistema de pago de dispositivo móvil a máquina y las interacciones entre los mismos.
Como se muestra, el módulo de adaptador 100 se conecta funcionalmente de forma bidireccional a la unidad de aceptación de pago 120 a través de una conexión en serie cableada de tal manera que no es necesaria seguridad alguna. El módulo de adaptador 100 también está conectado funcionalmente de forma bidireccional al dispositivo móvil 150 (y a su aplicación móvil 140 instalada) a través de una tecnología de comunicación de corto alcance (por ejemplo, una conexión de Bluetooth). Debido a que el dispositivo móvil 150 no es un enlace "de confianza" (por ejemplo, podría ser pirateado por un usuario), solo se pasan comunicaciones (transmisiones) seguras entre el módulo de adaptador 100 y el dispositivo móvil 150. Esto mantiene las comunicaciones seguras y a salvo de piratería. El dispositivo móvil 150 (y su aplicación móvil 140 instalada) también está conectado funcionalmente de forma bidireccional a un servidor de gestión de sistema 130 y/o un servidor de fuente de financiación 160 a través de una tecnología de comunicación de largo alcance (por ejemplo, conexión de Wi-Fi o celular) que preferiblemente tiene una seguridad apropiada (por ejemplo, seguridad de SSL). La seguridad entre el dispositivo móvil 150 y el servidor de gestión de sistema 130 tiene la ventaja de proteger las comunicaciones desde el dispositivo móvil 150 al servidor de gestión de sistema 130, que pueden incluir datos sensibles y pueden no estar cifrados. El servidor de gestión de sistema 130 y el servidor de fuente de financiación 160 pueden estar conectados a través de una conexión de Internet cableada con seguridad de SSL. El servidor de gestión de sistema 130 puede estar conectado a través de una conexión de Internet cableada con seguridad de SSL al servidor 170 de un operador. Aunque no es necesario para implementar una transacción de compra, para otros fines (por ejemplo, inventario), el servidor 170 de los operadores puede estar conectado a la unidad de aceptación de pago 120 usando una sincronización de ordenador de mano o una conexión celular.
Asimismo, se puede usar una clave privada única para transmitir de forma segura mensajes cifrados entre el módulo de adaptador 100 y el servidor de gestión de sistema 130 (aunque las transmisiones cifradas se encaminarían muy probablemente a través del dispositivo móvil 150). El servidor 130 almacena una clave privada para cada módulo de adaptador 100, y esta clave solo es conocida por el módulo de adaptador 100 y el servidor 130. Ningún intermediario está al tanto de esta clave (no lo está, especialmente, el dispositivo móvil 150). Cuando el módulo de adaptador 100 y el servidor 130 comunican mensajes (por ejemplo, SolicitudAut y ConcesiónAut), la unidad de seguridad 755 del módulo de adaptador 100 cifra el mensaje con su clave privada y pasa el mensaje al dispositivo móvil 150. El dispositivo móvil 150 (que preferiblemente no puede descifrar el mensaje) pasa el mensaje cifrado al servidor 130. El servidor 130 es capaz de descifrar el mensaje usando la unidad de seguridad 955 del módulo de adaptador 100 y la clave privada única. La unidad de seguridad 955 del servidor 130 usa esta misma clave privada única para cifrar mensajes al módulo de adaptador 100 y envía el mensaje al dispositivo móvil 150 para su retransmisión al módulo de adaptador 100 que es capaz de descifrar el mensaje usando la unidad de seguridad 755 del módulo de adaptador 100 y la clave privada única.
La figura 7 muestra comunicaciones y mensajería específicas con una secuencia de expendición (los números a la izquierda de las comunicaciones y la mensajería) entre el módulo de adaptador 100, el dispositivo móvil 150 y el servidor de gestión de sistema 130. Estas comunicaciones se analizan con más detalle en el análisis relacionado con los diagramas de flujo esquemáticos (las figuras 8A-8G) y los diagramas de flujo (las figuras 9A-9E).
Se debería hacer notar que las figuras 5, 6 y 7 son ejemplos y tienen por objeto ayudar en la comprensión del sistema de pago de dispositivo móvil a máquina. Por ejemplo, la tecnología de comunicaciones de largo alcance mostrada se puede sustituir con una tecnología de comunicaciones de largo alcance alternativa conocida o que no se haya descubierto aún, la tecnología de comunicaciones de corto alcance mostrada se puede sustituir con una tecnología de comunicaciones de corto alcance alternativa conocida o que no se haya descubierto aún, y la seguridad mostrada se puede sustituir con una seguridad alternativa conocida o que no se haya descubierto aún. Las conexiones mostradas tienen por objeto ser ejemplos, y puede haber intermediarios que no se muestran. Los componentes mostrados se han simplificado ya que, por ejemplo, se muestra solo un dispositivo móvil 150 (o máquina 120, módulo de adaptador 100 o servidor 130) en donde se pueden incluir muchos. Por último, se puede cambiar el orden de las etapas y se pueden eliminar algunas etapas.
MÓDULO DE ADAPTADOR
Las figuras 11-18 muestran vistas del módulo de adaptador 100a (denominado generalmente módulo de adaptador 100). El módulo de adaptador 100 es un componente de hardware de coste relativamente bajo que está preconfigurado para funcionar con el bus multipunto (MDB) convencional de la industria. En máquinas sin tecnología de MDB, el módulo de adaptador 100 se puede configurar o diseñar para funcionar con otros protocolos en serie o activar un conmutador. En esencia, el módulo de adaptador 100 simula el establecimiento de un pago en la unidad de aceptación de pago 120 de una manera muy similar a otras formas alternativas de pago (por ejemplo, efectivo).
Los módulos de adaptador 100 mostrados están diseñados preferiblemente para usarse como una llave en línea para su inserción en línea dentro de, por ejemplo, un MDB de una máquina 120. El hilo usado en la tecnología de MDB usa adaptadores o extremos de conexión macho y hembra para permitir la unión de periféricos. En el caso de una máquina expendedora, el hilo con los adaptadores o extremos de conexión estaría presente para permitir la unión de un mecanismo de recepción de pago (por ejemplo, un mecanismo de monedas). Los adaptadores macho y hembra de MDB 700, 710 se pueden separar (como se muestra en las figuras 17-18). El módulo de adaptador 100a en las figuras 11 y 17-18 tiene un adaptador macho 720 y un adaptador hembra 730. El módulo de adaptador 100a se puede enchufar (insertar) en serie ("en línea") con el hilo. Por ejemplo, el adaptador hembra de<m>D<b>710 se puede conectar al adaptador macho 720 del módulo de adaptador 100 y el adaptador macho de MDB 700 se puede conectar al adaptador hembra 730 del módulo de adaptador 100. La configuración en línea resultante se muestra en la figura 19. Se debería hacer notar que los módulos de adaptador 100 están diseñados para permitir unas comunicaciones pasantes de tal manera que si el sistema de procesamiento de pago de dispositivo móvil a máquina no está habilitado (por ejemplo, para una compra particular o simplemente está apagado), el MDB funciona como si el módulo de adaptador 100 no estuviera allí y la máquina 120 puede funcionar normalmente.
MODO DE MANOS LIBRES
En resumen, si este está disponible, un modo de manos libres, desde la perspectiva del usuario, permitiría al usuario aproximarse a una unidad de aceptación de pago 120 favorita y observar que el visualizador (por ejemplo, los visualizadores 122 o 124 mostrados en la figura 19) asociado con la unidad de aceptación de pago 120 muestra fondos disponibles (por ejemplo, el saldo de monedero), este seleccionaría el producto o servicio usando mecanismos de entrada (por ejemplo, unos botones 126 o un visualizador de pantalla táctil 124 mostrado en la figura 19) asociados con la unidad de aceptación de pago 120 y recuperaría sus servicios o productos dispensados.
Durante una toma de contacto inicial con el dispositivo móvil 150 (cuando el usuario está dentro del alcance), el módulo de adaptador 100 informa al dispositivo móvil 150 si el modo de manos libres está disponible o no. Si está disponible, la aplicación móvil 140 instalada se conecta automáticamente a la unidad de aceptación de pago 120 sin que el usuario tenga que interaccionar con el dispositivo móvil 150. El usuario observa que hay fondos disponibles en el visualizador 122, 124 de la unidad de aceptación de pago 120 y completa la transacción de compra como si se hubiera insertado efectivo en la máquina 120 introduciendo su selección en la unidad de aceptación de pago 120. La unidad de aceptación de pago 120 dispensa el producto o servicio. Una vez se haya realizado la selección, el cambio se devuelve al dispositivo móvil 150.
Si el pago de manos libres está disponible es determinado por factores que incluyen, pero sin limitarse a, si otros dispositivos móviles 150 están dentro del alcance, si otros módulos de adaptador 100 están dentro del alcance, si hay alguna alerta, si el umbral de desencadenamiento de pago está teniendo variaciones amplias y, por lo tanto, se considera inestable, o si el operador de unidad de aceptación de pago (por ejemplo, un operador de máquina expendedora) ha optado por deshabilitar el modo de manos libres para la unidad de aceptación de pago 120. En este último caso, los operadores pueden realizar una deshabilitación a través de un dispositivo móvil de mantenimiento 150, así como a través del servidor 170 de los operadores y/o el servidor de gestión de sistema 130.
La figura 3 es una tabla que muestra consideraciones, condiciones o factores que se pueden usar para determinar si la característica de pago de manos libres está disponible. Empezando por la columna de "¿Favorita?", esto indica si la unidad de aceptación de pago 120 es una máquina favorita. Preferiblemente, la característica de pago de manos libres solo está disponible para su uso con unidades de aceptación de pago 120 "favoritas" (por ejemplo, una máquina expendedora en el trabajo o en la escuela). La columna de "Alerta" tiene que ver con si hay alguna razón (por ejemplo, hay demasiados usuarios dentro del alcance) por la que la característica de pago de manos libres no debería funcionar y, si existe una razón de este tipo, se notificará (se alertará) al usuario y puede ser capaz de usar el modo manual para resolver la alerta y/o completar la transacción. La figura 3 muestra situaciones en las que un usuario es o no es capaz de realizar compras de manos libres desde una máquina 120 usando una aplicación móvil 140 en su dispositivo móvil 150. Se debería hacer notar que la interfaz mostrada es un ejemplo. Por ejemplo, algunas de las características podrían estar automatizadas o preseleccionadas (se debería hacer notar que la columna de la izquierda, la columna de "Pestaña", se refiere a si la pestaña seleccionada en la aplicación móvil 140 es "todas" o "favorita". Las figuras 10A-10D muestran, todas ellas, estas pestañas. A diferencia de las otras columnas en la figura 3, esta columna tiene más que ver con la funcionalidad y la vista de la aplicación 140 que específicamente con la característica de manos libres. Las pestañas permitirían al usuario seleccionar si este deseaba recibir una alerta cuando estuviera dentro del alcance de todas las unidades de aceptación de pago 120 o simplemente de las unidades de aceptación de pago 120 "favoritas", y la aplicación 140 mostraría la vista apropiada).
Visualización de saldo: Una característica opcional del sistema de pago de dispositivo móvil a máquina que es particularmente útil en el modo de manos libres (aunque puede estar disponible en el modo manual y/o en escenarios de expendición múltiple) es cuando el dispositivo móvil 150 del usuario envía "crédito" a la unidad de aceptación de pago 120 (o bien a través de pago de manos libres o bien a través de un deslizamiento manual), el saldo de monedero se envía a la unidad de aceptación de pago 120 que entonces se visualiza al usuario en un visualizador 122, 124 de la máquina 120. Esto es particularmente beneficioso durante el modo de manos libres cuando el usuario no recupera el dispositivo móvil 150 y, por lo tanto, puede no conocer el saldo. Asimismo, en un escenario de expendición múltiple, el usuario no tendría que calcular un saldo restante.
A continuación, se da un ejemplo de un escenario de manos libres de expendición múltiple en donde un saldo es visualizado por la unidad de aceptación de pago 120: El usuario tiene 5,00 dólares en su monedero virtual debido a que esa es la cantidad que ha sido autorizada (almacenándose la ConcesiónAut en el dispositivo móvil 150). El usuario se acerca a la unidad de aceptación de pago 120 y se visualizan 5,00 dólares en el visualizador 122, 124 de la unidad de aceptación de pago 120, debido a que se habilitó el modo de manos libres y se envió el crédito (por ejemplo, a través de la capacidad de comunicación de corto alcance) a la unidad de aceptación de pago 120. El usuario hace una selección de 1,50 dólares interaccionando (por ejemplo, presionando botones) con la máquina 120. El artículo (producto o servicio) se dispensa y el "cambio" se "devuelve" (por ejemplo, a través de la capacidad de comunicación de corto alcance) al monedero virtual. Pero, debido a que el usuario sigue estando en la zona de pago 102, el saldo de monedero restante de 3,50 dólares se envía a la unidad de aceptación de pago 120 y se visualiza de tal manera que el usuario puede ver entonces que tiene un saldo de 3,50 dólares (se debería hacer notar que los fondos autorizados pueden permanecer en la máquina 120 y no volver a transferirse al dispositivo móvil 150 entre transacciones). El usuario decide comprar un artículo de 1,50 dólares y la transacción se completa como de costumbre (por ejemplo, interaccionando con la máquina 120). Entonces el usuario sigue estando en la zona de pago 102 y ve el saldo de monedero de 2,00 dólares en el visualizador 122, 124 de la unidad de aceptación de pago 120. El usuario decide que no desea comprar nada más y simplemente se aleja. Cuando el usuario sale de la zona de pago 102, el crédito se borra de la máquina 120, pero este se queda con el conocimiento de que su saldo de monedero es de 2,00 dólares incluso a pesar de que el mismo nunca tocó el dispositivo móvil 150. Las comunicaciones entre la unidad de aceptación de pago 120 y el módulo de adaptador 100 (a través del dispositivo móvil 150) manejan la contabilidad inherente a la transacción. El saldo restante (2,00 dólares) se almacena técnicamente en el servidor 130 y se puede reflejar en la aplicación 140 en el dispositivo móvil 150.
MÚLTIPLES ZONAS DISTINTAS
Como se muestra en las figuras 1-2, las funciones realizadas por el módulo de adaptador 100 se pueden dividir en zonas distintas: una primera "zona de comunicación" (por ejemplo, un "alcance de Bluetooth" 106), una segunda "zona de autorización" 104 y una tercera "zona de pago" 102. La zona de pago 102 es más pequeña o igual que (se superpone completamente a) la zona de autorización 104. Dicho de otra forma, la zona de pago 102 está dentro de o se extiende conjuntamente con la zona de autorización 104. La zona de pago 102 es un subconjunto de la zona de autorización 104 con una relación de la zona de pago 102 a la zona de autorización 104 que varía de 0,01:1 a 1:1. Esta no es necesariamente una proporción fija y puede variar entre diferentes unidades de aceptación de pago 120, diferentes dispositivos móviles 150, diferentes usuarios y a lo largo del tiempo. Aunque las zonas 102, 104, 106 se representan como si tuvieran una forma uniforme, las zonas pueden no ser necesariamente uniformes (o constantes a lo largo del tiempo) ya que la forma puede variar. Por ejemplo, la forma del alcance de Bluetooth 106 puede variar dependiendo de condiciones ambientales tales como obstáculos en la habitación y los materiales de puerta/pared de la unidad de aceptación de pago 120.
Alcance de Bluetooth 106 (a veces también denominado en el presente documento "zona de comunicación"): El alcance más externo es el alcance de Bluetooth 106 (mostrado en las figuras 1-2). Esta es el área en la que el módulo de adaptador 100 es capaz de radiodifundir su presencia. En la mayoría de las situaciones, el alcance de Bluetooth 106 es un alcance pasivo ya que no se intercambian datos reales entre el dispositivo móvil 150 y el módulo de adaptador 100. Mientras está en el alcance de Bluetooth 106, el dispositivo móvil 150 supervisa el RSSI (indicador de intensidad de señal recibida).
Zona de autorización 104: La región media es la zona de autorización 104 (mostrada en las figuras 1-2). Ésta es un área calculada basándose en el RSSI. Como se ha mencionado, el dispositivo móvil 150 supervisa el RSSI mientras está en el alcance de Bluetooth 106. Cuando el RSSI alcanza un cierto umbral predeterminado basándose en la heurística dentro del alcance, se puede considerar que el dispositivo móvil 150 está en la zona de autorización 104. En la zona de autorización 104, el dispositivo móvil 150 establece una conexión con el módulo de adaptador 100 (por ejemplo, una conexión de Bluetooth (la figura 5) con una protección de SSL (la figura 6)) e informa al módulo de adaptador 100 de su presencia. Después de una toma de contacto con éxito con el módulo de adaptador 100, el dispositivo móvil 150 registra el módulo de adaptador 100 y el módulo de adaptador 100 solicita una autorización al servidor 130 a través de la conexión de red de los dispositivos móviles (por ejemplo, una conexión de WiFi o celular (la figura 5) con una protección de SSL (la figura 6)). Es importante observar que el dispositivo móvil 150 y el módulo de adaptador 100 tienen una relación no exclusiva en este punto. El módulo de adaptador 100 puede recopilar registros para todos los dispositivos móviles 150 que están dentro de la zona de autorización 104.
Se produce una autorización en preparación para cuando el usuario entra en la zona de pago 102 (mostrada en las figuras 1-2). Una autorización vence en un período de tiempo establecido (por ejemplo, cinco minutos), por lo que, si el dispositivo móvil 150 todavía está en la zona de autorización 104 en el momento del vencimiento, el módulo de adaptador 100 se somete a y recibe otra autorización. Esto continuará durante un número establecido de veces (por ejemplo, el límite puede ser tres veces para limitar casos de autorizaciones numerosas para un dispositivo móvil que puede permanecer en la zona de autorización 104 durante un período de tiempo prolongado sin completar una transacción). Si la autorización falla (por ejemplo, si se había alcanzado el límite) antes de que el usuario entre en la zona de pago 102, el módulo de adaptador 100 solicitará autorización cuando el dispositivo móvil 150 entre en la zona de pago 102 (lo que añade unos pocos segundos a la experiencia).
Zona de pago 102: Cuando un usuario entra en la zona de pago 102, el dispositivo móvil 150 establece un control exclusivo del módulo de adaptador 100. Una vez establecido, se pone a cualquier otro usuario en la zona de pago 102 en un estado de "espera".
En la zona de pago 102, el pago se puede desencadenar automáticamente si el sistema de procesamiento de pago tiene y está en modo de manos libres. En tales casos, el dispositivo móvil 150 está ejecutando la aplicación 140 en modo de segundo plano y enviará crédito a la unidad de aceptación de pago 120 sin interacción de usuario explícita alguna. El usuario completa la transacción en la unidad de aceptación de pago 120 de una manera muy similar a si se hubiera insertado efectivo en la unidad de aceptación de pago 120 para establecer crédito. Una vez que el usuario ha completado la transacción (que puede incluir una o más compras), los detalles de la transacción se devuelven preferiblemente al dispositivo móvil 150 y al servidor 130 en mensajes separados. El mensaje al servidor 130 se cifra preferiblemente con la clave privada del módulo de adaptador 100 (la figura 6) para asegurar la integridad de los datos. Como se muestra en la figura 7, el mensaje codificado de "clave privada" (DetallesExpendición cifrados) se envía preferiblemente a través del dispositivo móvil 150. El mensaje al dispositivo móvil 150 se puede enviar únicamente para el fin de cerrar la transacción. El historial de transacciones y el saldo se actualizan en el lado de servidor a través del mensaje cifrado enviado al servidor 130.
El otro modo de funcionamiento es el modo manual. En el modo manual, el usuario inicia el dispositivo móvil 150 y es capaz de realizar un deslizamiento para enviar el pago a la unidad de aceptación de pago 120. El usuario también puede realizar un deslizamiento hacia atrás para cancelar el pago. Como en el modo de manos libres, la transacción de compra se completa en la unidad de aceptación de pago 120 de la misma manera que si se hubiera insertado efectivo en la unidad de aceptación de pago 120. El dispositivo móvil 150 solo se usa para enviar pagos. La selección se realiza directamente en la unidad de aceptación de pago 120.
Umbral de zona de autocalibración: Una característica clave, pero opcional, del sistema de procesamiento de pago es un umbral de RSSI de zona de pago de autocalibración. Debido a que el RSSI puede variar de máquina a máquina, de entorno a entorno y de dispositivo a dispositivo, puede ser problemático tener un umbral fijo al que se desencadena el pago. El enfoque sugerido en el presente documento es la creación de un umbral de autocalibración. Cuando el usuario está interaccionando con la unidad de aceptación de pago 120 (tal como cuando hace su selección en la unidad de aceptación de pago 120), la unidad de aceptación de pago 120 notifica al módulo de adaptador 100 y el módulo de adaptador 100 registra las condiciones, tales como RSSI, tipo del dispositivo móvil de usuario 150, datos de acelerómetro y otra información. Es en este punto que se puede determinar con seguridad que el usuario está al alcance de la mano de la unidad de aceptación de pago 120 (por necesidad, el usuario está al alcance de la mano debido a que este está realizando alguna interacción física con la unidad de aceptación de pago 120). Este es el único punto de toda la transacción en el que se puede tener la certeza de que el usuario está al alcance de la mano de la unidad de aceptación de pago 120.
La figura 4 muestra un conjunto simplificado de etapas involucradas cuando los usuarios entran en la zona de pago 102. Específicamente, la figura 4 muestra que el crédito se establece 200 (esto se puede haber hecho en la zona de autorización 104, pero si no, se manejaría en la zona de pago 102), que el usuario hace una selección usando la máquina 202, que la máquina notifica al módulo de adaptador la selección 204, que el módulo de adaptador (opcionalmente) registra el RSSI 206, y que el proceso o procesos de compra continúan 208. Usando los datos de RSSI registrados históricamente, el módulo de adaptador 100 calcula uno de varios RSSI "promedio" usando diversos modelos matemáticos. Este "promedio" podría ser un promedio tradicional, un promedio móvil, un promedio ponderado, una mediana u otra función de resumen similar. El módulo de adaptador 100 podría preprocesar los datos históricos antes de ejecutar la función, tal como para eliminar puntos de datos superiores e inferiores, puntos de datos sospechosos, etc.
Opcionalmente, durante la toma de contacto entre el dispositivo móvil 150 y el módulo de adaptador 100, la información transmitida al módulo de adaptador 100 puede incluir, por ejemplo, el modelo del dispositivo móvil 150. Usando la información recibida relacionada con los modelos de dispositivo móvil, el módulo de adaptador 100 puede crear múltiples umbrales de pago, uno para cada modelo de dispositivo móvil. Esto permite variaciones que pueden ser inherentes en diferentes tipos de radios de Bluetooth. Una alternativa a este método es que el módulo de adaptador 100 radiodifunda un umbral de zona de pago de referencia, y el dispositivo móvil 150 puede usar una compensación con respecto a este valor de referencia basándose en su tipo de modelo específico. Los umbrales de zona de pago (o compensaciones de referencia) pueden ser únicos para tipos específicos de dispositivos móviles (por ejemplo, por fabricante, sistema operativo o partes componentes), modelos de dispositivos móviles o dispositivos móviles individuales (únicos para cada usuario).
En un escenario típico en el que se ha calibrado el umbral de zona de pago, el módulo de adaptador 100 anuncia su presencia junto con el umbral al que este considera que cualquier dispositivo móvil 150 está en la zona de autorización 104. Esta es una comunicación unidireccional desde el módulo de adaptador 100 al dispositivo móvil 150. Una vez que el dispositivo móvil 150 ha entrado en la zona de autorización 104, hay una toma de contacto que se establece entre el módulo de adaptador 100 y el dispositivo móvil 150. Durante esta toma de contacto, el dispositivo móvil 150 puede compartir su información de modelo con el módulo de adaptador 100, y el módulo de adaptador 100 puede devolver el umbral de la zona de pago 102 para ese modelo específico.
Opcionalmente, además de calibrar el umbral de zona de pago, el módulo de adaptador 100 puede aplicar el modelo de autocalibración a la zona de autorización 104 para calibrar el umbral de zona de autorización. Al igual que con los umbrales de zona de pago, los umbrales de zona de autorización pueden ser únicos para tipos específicos de dispositivos móviles, modelos de dispositivos móviles o dispositivos móviles individuales. En este escenario, el módulo de adaptador 100 radiodifundiría múltiples umbrales por tipo de dispositivo y el dispositivo móvil 150 determinaría qué umbral aplicar (o, como alternativa, radiodifundiría un valor de referencia y el dispositivo móvil 150 usaría una compensación basándose en su modelo de dispositivo). Incluso en este escenario, la zona de autorización 104 es una comunicación unidireccional.
Opcionalmente, junto con el umbral que se calcula (en la zona o zonas de pago y/o de autorización), se puede añadir un margen de seguridad para minimizar los escenarios en los que un usuario está dentro del alcance, pero el sistema de procesamiento de pago de dispositivo móvil a máquina no lo reconoce debido a que puede no haberse alcanzado el umbral. Por ejemplo, si el RSSI calculado para un iPhone™ 5 en la máquina 4567 es -68 dB, el sistema de procesamiento de pago de dispositivo móvil a máquina puede añadir un margen de seguridad de -5 dB y establecer el umbral en -73 dB. Por lo tanto, cuando el teléfono de un usuario se comunica con el módulo de adaptador 100 a un RSSI de -73 dB o mejor, el sistema de procesamiento de pago de dispositivo móvil a máquina permitirá que el dispositivo móvil 150 haga un abono a la unidad de aceptación de pago 120. El margen de seguridad se puede establecer en el servidor 130 y descargarse al módulo de adaptador 100, o establecerse en el dispositivo móvil 150, o establecerse en el propio módulo de adaptador 100.
Opcionalmente, en el umbral de zona de pago, el dispositivo móvil 150 puede usar otros datos para determinar cuándo cancelar el control exclusivo de la unidad de aceptación de pago 120, para identificar cuándo el usuario se está moviendo fuera de la zona de pago 102. Los datos externos podrían incluir datos de acelerómetro procedentes del dispositivo móvil 150. Usando esos datos, el dispositivo móvil 150 puede determinar si el usuario está relativamente quieto frente a la unidad de aceptación de pago 120, o si el usuario está en movimiento - alejándose en la práctica de la unidad de aceptación de pago 120.
ADAPTACIÓN DE NO DISPONIBILIDAD DE SEÑAL
El sistema de procesamiento de pago de dispositivo móvil a máquina descrito en el presente documento usa una tecnología de comunicación de corto alcance de un dispositivo móvil 150 (por ejemplo, mecanismos de Bluetooth) (mostrada como la capacidad de comunicación de corto alcance 876 en la figura 21) y una tecnología de comunicaciones de largo alcance de un dispositivo móvil 150 (por ejemplo, mecanismos celulares y/o de Wi-Fi) (mostrada como la capacidad de comunicación de largo alcance 872 en la figura 21). La capacidad de comunicación de corto alcance 876 se comunica con la tecnología de comunicación de corto alcance del módulo de adaptador 100 (por ejemplo, mecanismos de Bluetooth) (mostrada como la capacidad de comunicación de corto alcance 776 en la figura 20). La capacidad de comunicación de largo alcance 872 se comunica con la tecnología de comunicaciones de largo alcance del servidor 130 (por ejemplo, mecanismos celulares y/o de Wi-Fi) (mostrada como la capacidad de comunicación de largo alcance 972 en la figura 22). El dispositivo móvil 150 (con una aplicación móvil 140 en el mismo) actúa como un puente de comunicación entre el módulo de adaptador 100 (asociado con una unidad de aceptación de pago 120) y el servidor 130. Este proceso se describe en el presente documento y funciona apropiadamente si hay cobertura celular o de Wi-Fi dentro de la zona de pago 102.
Una opción si no hay cobertura celular o de Wi-Fi alguna dentro de la zona de pago 102 es determinar si hay cobertura celular o de Wi-Fi dentro de la zona de autorización 104 o el alcance de Bluetooth 106. Si este es el caso, entonces se podrían adaptar los tamaños de las zonas 102, 104, 106 y se podría adaptar la temporización. Por ejemplo, si los dispositivos móviles 150 detectan problemas con la cobertura celular o de Wi-Fi dentro de la zona de pago 102, el usuario podría llevar su dispositivo móvil 150 a las otras zonas (o el dispositivo móvil 150 podría usar una tecnología de comunicación de corto alcance para comunicarse con otros dispositivos móviles 150 dentro de la zona de autorización 104 o el alcance de Bluetooth 106) para determinar si las zonas tienen cobertura celular o de Wi-Fi. Si tienen, de hecho, cobertura, la comunicación entre el dispositivo móvil 150 y el servidor 130 se puede anticipar (llevarse a cabo antes, cuando el dispositivo móvil 150 está más lejos de la máquina 120) o retardar (llevarse a cabo más tarde, cuando el dispositivo móvil 150 está más lejos de la máquina 120). Esto se puede interpretar como un cambio en el tamaño o las formas de las zonas 102, 104, 106. La temporización también se tendría que ajustar de tal manera que la autorización de fondos (ConcesiónAut) no venza antes de que el usuario tenga la oportunidad de realizar una compra. Esto también significa que las actualizaciones de saldo en el servidor 130 pueden tener lugar después de que el usuario se haya alejado de la máquina 120 y vuelva a tener cobertura celular o de Wi-Fi.
Otra opción si no hay cobertura celular o de Wi-Fi alguna dentro de ninguna de las zonas 102, 104, 106 es que el usuario obtenga autorización mientras está fuera de las zonas en un lugar con cobertura celular o de Wi-Fi. Esto puede tener lugar, por ejemplo, si un usuario sabe que irá a un lugar con una unidad de aceptación de pago 120 equipada con un módulo de adaptador 100 (tal vez a una unidad de aceptación de pago 120 favorita) que no tiene (o rara vez tiene) cobertura celular o de Wi-Fi. Un usuario también puede usar la aplicación móvil 140 para consultar las unidades de aceptación de pago 120 en un alcance dado (por ejemplo, dentro de 50 millas (80,47 kilómetros)) o en una ubicación dada (por ejemplo, en una zona de acampada o en una ciudad remota particular) para determinar si hay cobertura celular o Wi-Fi dentro de las zonas 102, 104, 106. El usuario puede entonces obtener una pre-autorización desde el servidor 130 usando la aplicación móvil 140. Una vez más, la temporización también se tendría que ajustar de tal manera que la autorización de fondos (ConcesiónAut) no venza antes de que el usuario tenga la oportunidad de realizar una compra. Esto también significa que las actualizaciones de saldo en el servidor 130 pueden tener lugar después de que el usuario se haya alejado de la máquina 120 y vuelva a tener cobertura celular o de Wi-Fi. Un sistema de pago de dispositivo móvil a máquina que tiene la capacidad de implementar esta opción sería capaz de aceptar pagos sin efectivo sin requerir conexión de red alguna cerca de la unidad de aceptación de pago 120. En algunas implementaciones, los sistemas de procesamiento de pago de dispositivo móvil a máquina descritos en el presente documento están ubicados en una ubicación remota en donde no hay señal alguna disponible, por lo tanto, pueden aceptar pagos sin efectivo.
Como un ejemplo de una situación en la que podría no haber cobertura celular o de Wi-Fi alguna dentro de cualquiera de las zonas 102, 104, 106 de una unidad de aceptación de pago 120 particular, el usuario (un adolescente) puede estar viajando a una ubicación remota para asistir a un campamento de verano en donde no haya cobertura celular o de Wi-Fi alguna. El campamento puede tener varias unidades de aceptación de pago 120 (por ejemplo, una máquina que crea una "zona con cobertura inalámbrica" dedicada cuyo uso requiere un pago, máquinas expendedoras o máquinas para alquilar equipos tales como bicicletas, kayaks o pelotas de baloncesto). Las instalaciones de campamento podrían notificar a los padres que el sistema de pago de dispositivo móvil a máquina está disponible. Los padres, mientras están en casa, podrían obtener autorización para que una cantidad particular (que se podría repartir una cierta cantidad por día o limitarse al tipo de máquina o ubicación) se autorizara y se "cargara" en el dispositivo móvil 150 del usuario y especificar que la autorización no vencerá durante un período determinado o hasta una fecha determinada. Posteriormente, mientras está en el campamento, el usuario podría usar la aplicación móvil 140 en su dispositivo móvil 150 de una manera similar a las analizadas en cualquier otra parte en el presente documento. Se pueden usar comunicaciones de corto alcance para comunicaciones entre los módulos de adaptador 100 (asociados con las máquinas 120) y los dispositivos móviles 150 de los usuarios.
Un componente sutil pero potente del sistema de procesamiento de pago descrito en el presente documento es que este requiere una capacidad de comunicación de largo alcance (por ejemplo, una conexión de Internet o de red celular) solo en la zona de autorización 104 y solo durante el período de tiempo requerido para enviar la SolicitudAut y recibir la ConcesiónAut. Una vez que una ConcesiónAut válida ha sido recibida por el dispositivo móvil 150, la capacidad de comunicación de largo alcance (por ejemplo, una conexión de Internet o de red celular) no es requerida ni por el dispositivo móvil 150 ni por el módulo de adaptador 100 en la zona de pago 102 siempre que la ConcesiónAut sea válida (no esté vencida). Este mecanismo permite que el sistema maneje sin problemas transacciones autenticadas en modo fuera de línea (temporal), con los mensajes de acuse de recibo y de transacción diferidos realizando la contabilidad y la limpieza cuando se recupera la conexión de red. Las alternativas descritas anteriormente proporcionan una forma única de ampliar artificialmente la zona de autorización para incluir cualquier ubicación en donde el dispositivo móvil 150 se pueda comunicar con el servidor 130.
RESOLUCIÓN DE MÚLTIPLES USUARIOS
Como se muestra en la figura 2, en un escenario práctico, hay múltiples usuarios en las zonas 102, 104, 106. Como se muestra en la figura 2, los usuarios 1, 2 y 3 están en la zona de pago 102 cerca de la máquina 120; los usuarios 5 y 6 se muestran como situados entre la zona de autorización 104 y el alcance de Bluetooth 106; los usuarios 4 y 7 están en el alcance de Bluetooth 106, el usuario 10 está situado en el borde del alcance de Bluetooth 106; y los usuarios 8 y 9 están situados fuera del alcance de Bluetooth 106. En algunas implementaciones, el sistema de procesamiento de pago de dispositivo móvil a máquina gestiona y resuelve problemas relacionados con múltiples usuarios.
Los usuarios 4 y 7 están dentro del alcance de Bluetooth 106 y el usuario 10 está o bien entrando en o bien saliendo del alcance de Bluetooth 106. Dentro del alcance de Bluetooth 106, los dispositivos móviles 150 de los usuarios son capaces de ver el anuncio del módulo de adaptador 100. En esta zona, el dispositivo móvil 150 preferiblemente no inicia una conexión. El módulo de adaptador 100 preferiblemente no tiene conocimiento de los usuarios en el alcance de Bluetooth 106. Todo lo que hace el módulo de adaptador 100 es anunciar su presencia a cualquier multitud de usuarios que puedan estar en el alcance de Bluetooth 106.
El módulo de adaptador 100 comienza a registrar usuarios cuando los usuarios (y sus dispositivos móviles 150 respectivos) entran en la zona de autorización 104 (mostrada en la figura 2 como los usuarios 5 y 6). En este punto, hay una conexión no exclusiva iniciada por el dispositivo móvil 150 al módulo de adaptador 100. Este hace una toma de contacto (por ejemplo, para intercambiar información necesaria para obtener autorización y, opcionalmente, para registrar la información necesaria para un umbral de zona de autorización de autocalibración) y el dispositivo móvil 150 contacta con el servidor 130 para obtener una autorización (por ejemplo, enviando una SolicitudAut y recibiendo una ConcesiónAut). El módulo de adaptador 100 registra todos los dispositivos móviles 150 que han solicitado y recibido unas ConcesiónAut. El módulo de adaptador 100 continúa comunicándose con cualquier otro dispositivo móvil 150 que entre en la zona de autorización 104. Después del contacto inicial, el módulo de adaptador 100 puede proporcionar al dispositivo móvil 150 un retardo de aplazamiento de cuándo volver a registrar la entrada con el módulo de adaptador 100, lo que permite a otros dispositivos móviles 150 la oportunidad de comunicarse con el módulo de adaptador 100.
Si hay solo un usuario en la zona de pago 102, se puede realizar una transacción de compra. Si hay múltiples usuarios en la zona de pago 102, el sistema de pago de dispositivo móvil a máquina ha de manejar la situación.
Una solución opcional para manejar la situación de los múltiples usuarios en la zona de pago 102 es poner en cola a los usuarios en la zona de pago 102. Una vez que cualquier dispositivo móvil 150 entra en la zona de pago 102, establece la exclusividad para un dispositivo móvil particular 150 (por ejemplo, de una forma primero en llegar, primero en ser atendido). Técnicamente, sin embargo, el módulo de adaptador 100 no está estableciendo una conexión exclusiva con el dispositivo móvil 150. El módulo de adaptador 100 todavía puede realizar un sondeo por orden cíclico y comunicarse con y anunciarse a otros dispositivos móviles 150. En su lugar, el módulo de adaptador 100 establece una cola priorizada por RSSI y tiempo (por ejemplo, quién fue el primero y si la autorización ha vencido) y notifica (por ejemplo, alerta) a otros dispositivos móviles 150 que esperen. La autorización válida (no vencida) más antigua tiene prioridad cuando hay cualquier empate en el RSSI. De lo contrario, por ejemplo, el RSSI promedio más fuerte tiene prioridad. Preferiblemente, la cola no es una medida estática del RSSI sino una medida promediada a lo largo del período de tiempo en la cola. Esto compensa un escenario en el que un usuario puede estar caminando en la cola y entonces aparece en la unidad de aceptación de pago 120 justo cuando el usuario previo está terminando. Si otro usuario también estaba en la zona de pago 102 y permaneció allí todo el tiempo, pero puede tener una autorización más reciente, este podría imponerse.
Siempre que el módulo de adaptador 100 no pueda determinar exactamente qué usuario está en la zona de pago 102 frente a la unidad de aceptación de pago 120, el módulo de adaptador 100 deshabilitará el pago de manos libres. El dispositivo móvil 150 enviará una alerta al usuario y éste podrá usar deslizar para pagar (modo manual). Todos los usuarios en la zona de pago 102 mostrarán "Conectado" y el primero en pasar por deslizamiento el pago a la unidad de aceptación de pago 120 bloquea entonces el uso por otros usuarios.
RESOLUCIÓN DE MÚLTIPLES MÓDULOS
En el escenario en el que hay múltiples módulos presentes, determinar frente a qué unidad de aceptación de pago 120 está un usuario puede ser un desafío. En algunas implementaciones, el sistema de procesamiento de pago de dispositivo móvil a máquina descrito en el presente documento permite que los módulos de adaptador 100 se comuniquen con otros módulos de adaptador 100 dentro del alcance a través de Bluetooth. Cada usuario recibe concesiones de autorización para unidades de aceptación de pago 120 específicas. Esto significa que, si hay múltiples módulos de adaptador 100 dentro de la misma zona de autorización 104, habrá múltiples concesiones de autorización para el usuario. Cuando el usuario entra en la zona de pago 102, puede ser difícil diferenciar frente a qué unidad de aceptación de pago 120 está el usuario si las zonas de pago 102 se superponen.
Para resolver este problema, cuando el usuario entra en la zona de pago 102, los módulos de adaptador 100 se comunican entre sí para determinar el RSSI para el usuario particular (basándose en la señal procedente de su dispositivo móvil 150) para triangular qué módulo de adaptador 100 (y la unidad de aceptación de pago 120 asociada) está más cerca del usuario. Opcionalmente, las comunicaciones entre módulos pueden restringir al usuario a establecer una conexión exclusiva con solo una unidad de aceptación de pago 120.
Opcionalmente, cuando el usuario se conecta a una unidad de aceptación de pago 120, el dispositivo móvil 150 puede enviar una comunicación a la unidad de aceptación de pago 120 para una visualización momentánea al usuario en el visualizador 122, 124 de la unidad de aceptación de pago 120. Por ejemplo, el dispositivo móvil 150 puede enviar una comunicación (por ejemplo, "conectado" o "Dispositivo móvil de Fred conectado") al visualizador 122, 124 de la unidad de aceptación de pago durante un período de tiempo predeterminado (por ejemplo, 1-3 segundos), de tal manera que, cuando el usuario está en la zona de pago 102, está claro a qué unidad de aceptación de pago 120 está conectado el usuario antes de realizar una compra (en modo o bien de manos libres o bien manual).
Además, cuando el usuario está en modo manual, el dispositivo móvil 150 puede visualizar (por ejemplo, en la pantalla táctil 152 como se muestra en las figuras 10A-10D) una indicación visual de la unidad de aceptación de pago 120 (por ejemplo, una imagen y/o un ID de unidad de aceptación de pago de la unidad de aceptación de pago 120) para una confirmación visual. Si el usuario está en modo manual, el usuario puede cambiar manualmente la unidad de aceptación de pago 120.
ESCENARIO DESCRIPTIVO
La figura 7, las figuras 8A-8G y 9A-9E (así como otras figuras) se pueden usar para comprender un escenario detallado del sistema de procesamiento de pago de dispositivo móvil a máquina descrito en el presente documento. Un flujo de comunicaciones y etapas se describen a grandes rasgos a continuación con referencia a estas (y a otras) figuras. Se debería hacer notar que escenarios alternativos podrían incluir, por ejemplo, un orden modificado de las etapas realizadas.
Antes de las transacciones de expendición, un usuario descarga una aplicación móvil 140 en su dispositivo móvil 150, crea una cuenta y configura una fuente de financiación a través de, por ejemplo, un servidor de fuente de financiación 160. Una fuente de financiación puede ser, por ejemplo, una tarjeta de débito, una tarjeta de crédito, tarjetas universitarias, puntos de recompensa, cuentas bancarias, servicios de pago (por ejemplo, PayPal™) u otra opción de pago o combinación de opciones de pago conocidas o que no se hayan descubierto aún. Las fuentes de financiación pueden ser fuentes de pago tradicionales y/o no tradicionales que se integran en el ecosistema descrito en el presente documento y entonces se usan indirectamente como una fuente de financiación. Los fondos procedentes de la fuente de financiación se mantienen preferiblemente en el servidor 130 de tal manera que, cuando una SolicitudAut es recibida por el servidor 130, el servidor 130 puede enviar una ConcesiónAut autorizando fondos para una compra.
El usuario puede especificar uno o más módulos de adaptador 100 "favoritos" (que tienen una relación de uno a uno con la unidad de aceptación de pago 120) que este puede visitar regularmente, tales como una máquina expendedora en la escuela o el trabajo. Los módulos de adaptador 100 favoritos aparecen en una lista prefiltrada y permiten características adicionales de gran valor, tales como el pago de manos libres.
La unidad de aceptación de pago 120 se puede equipar con un módulo de adaptador 100 que está anunciando constantemente su disponibilidad a través de Bluetooth (u otras "señales", "comunicaciones" y/o "transmisiones"). Este anuncio y exploración en curso en busca de módulos de adaptador se muestra en la figura 8A. Como se muestra, el dispositivo móvil 150 está explorando continuamente en busca de cualquier módulo de adaptador 100 dentro del alcance de Bluetooth (o de otra "señal", "comunicación" y/o "transmisión"). Cuando el usuario está dentro del alcance de ese módulo de adaptador 100, el dispositivo móvil 150 rastrea y supervisa la intensidad de señal hasta que se logra un umbral de "zona de autorización" predeterminado.
Las figuras 8B y 9A muestran generalmente que, cuando se alcanza el umbral de zona de autorización, el dispositivo móvil 150 entra en la zona de autorización (el bloque 302) y registra el módulo de adaptador 100. El dispositivo móvil 150 se conecta al servidor 130 (el bloque 304). La aplicación 140 en el dispositivo móvil 150 crea una solicitud de autorización (SolicitudAut) y pasa la SolicitudAut al servidor 130 usando una tecnología de comunicación apropiada (por ejemplo, GSM, CDMA, Wi-Fi o similares) (el bloque 306). El servidor 130 responde con una concesión de autorización (ConcesiónAut) cifrada con la clave privada del módulo de adaptador específico (el bloque 306). Este testigo de autorización puede incluir como mínimo el identificador (ID) de usuario, el ID del aparato (para el módulo de adaptador 100), la cantidad de autorización y el tiempo de vencimiento. El dispositivo móvil 150 recibe la ConcesiónAut desde el servidor 130 y la retiene hasta que el dispositivo móvil 150 está listo para emitir el pago a un módulo de adaptador 100. El dispositivo móvil 150 recopila todas las ConcesiónAut pendientes, que pueden ser una o más, dependiendo de cuántos módulos de adaptador 100 estén dentro del alcance. Las ConcesiónAut no usadas que vencen se purgan del dispositivo móvil 150 y el servidor 130. Es importante hacer notar que el dispositivo móvil 150 es incapaz de leer la ConcesiónAut debido a que la misma está cifrada con la clave privada única del módulo de adaptador que solo es conocida por el servidor 130 y el módulo de adaptador 100. Esto proporciona un elemento clave preferido de seguridad en el sistema, debido a que el módulo de adaptador 100 solo confía en las ConcesiónAut emitidas por el servidor 130, y las ConcesiónAut no pueden ser leídas ni modificadas por el dispositivo móvil 150 o cualquier otra parte entremedias del servidor y el módulo de adaptador 100. Pueden entrar dispositivos móviles 150 adicionales en la zona de autorización 104 (el bloque 308).
Cuando el usuario se aproxima a un módulo de adaptador específico 100, el usuario entra en la zona de pago 102 y se desencadena un umbral de evento basándose en una heurística realizada por el dispositivo móvil 150. Los bloques 310 y 312 muestran las etapas de bucle de esperar a que un dispositivo móvil 150 procedente de la zona de autorización 104 entre en la zona de pago 102. Si el usuario abandona la zona de autorización 104 sin entrar en la zona de pago 102, el módulo de adaptador 100 vuelve a anunciar su presencia (el bloque 300).
Las figuras 8C y 9B muestran generalmente al usuario entrando en la zona de pago. El dispositivo móvil 150 verifica que tiene una ConcesiónAut válida y no vencida. Si la ConcesiónAut no es buena, esta se puede solicitar de nuevo, repitiendo el proceso de Solicitud de Autorización (el bloque 315). Si la ConcesiónAut es buena, el dispositivo móvil 150 envía la ConcesiónAut válida (incluyendo el saldo de monedero (el bloque 322)) al módulo de adaptador 100 para iniciar una transacción. El dispositivo móvil 150 puede emitir la ConcesiónAut automáticamente sin interacción de usuario específica si se soporta el modo de manos libres (y el dispositivo es un favorito (el bloque 318), hay solo un dispositivo en la zona de pago 102 (el bloque 318) y (opcionalmente) hay solo un usuario en la zona de autorización 104 (el bloque 320). Si no está presente cualquiera de estos factores, el dispositivo móvil 150 solicitará al usuario y/o esperará de este a que comience la transacción manualmente (el bloque 324).
Las figuras 8D, 9C y 9D muestran generalmente el proceso de transacción. Como se muestra en la figura 9C, el módulo de adaptador 100 pasa por una serie de preguntas para determinar si hay algún problema que impediría la expendición, incluyendo: ¿el usuario ha cancelado en la aplicación? (el bloque 326), ¿el usuario se ha alejado? (el bloque 328), ¿está presionada la devolución de monedas? (el bloque 330), ¿ha transcurrido más de un período de tiempo predeterminado? (el bloque 332). Si la respuesta a cualquiera de estas preguntas es "sí", la transacción no prosigue. Si la respuesta a todas estas preguntas es "no", el usuario hace una selección (el bloque 334) en la unidad de aceptación de pago 120 de la misma manera o una similar en comparación con si se hubiera presentado efectivo o crédito a la unidad de aceptación de pago 120. Si la máquina 120 es capaz de expender (el bloque 336), esta intenta liberar el producto. Si la expendición falla (el bloque 338), esto es notificado por la máquina (el bloque 340) y se devuelve un crédito al monedero virtual (el bloque 342). Si la expendición tiene éxito (el bloque 338), esto es notificado por la máquina (el bloque 344). Dicho de otra manera, una vez completada la transacción, el módulo de adaptador 100 devuelve al dispositivo móvil 150 los detalles de la transacción, así como un paquete cifrado que contiene los detalles de expendición a enviar al servidor 130 a través del dispositivo móvil 150. Opcionalmente, el módulo de adaptador 100 puede pasar información adicional no relacionada directamente con la transacción, tal como estado de unidad de aceptación de pago, datos de ventas, códigos de error, etc.
Las figuras 8D y 9E muestran generalmente la función de multiexpendición. Si la máquina tiene capacidades de multiexpendición habilitadas (el bloque 350) y no se ha alcanzado el límite de multiexpendición, el proceso vuelve a la pregunta de si el usuario está en la zona de pago (el bloque 310 de la figura 9A). Si la máquina no tiene capacidades de multiexpendición habilitadas (el bloque 350) o se ha alcanzado el límite de multiexpendición, el monedero se decrementa en la cantidad o cantidades de expendición y se devuelve un "cambio" al monedero virtual (el bloque 354) y el proceso termina (el bloque 356).
La figura 8E es un diagrama de flujo esquemático de un proceso de inicio de sesión de ejemplo. La figura 8F es un diagrama de flujo esquemático de un proceso de arranque de ejemplo. La figura 8G es un diagrama de flujo esquemático de un proceso de verificación/actualización de cuenta de ejemplo.
Varias de las figuras son diagramas de flujo (por ejemplo, las figuras 9A-9E) que ilustran métodos y sistemas. Se entenderá que cada bloque de estos diagramas de flujo, componentes de todos o algunos de los bloques de estos diagramas de flujo, y/o combinaciones de bloques en estos diagramas de flujo, se pueden implementar mediante software (por ejemplo, codificación, software, instrucciones de programa informático, programas de software, subprogramas u otra serie de instrucciones ejecutables por ordenador o ejecutables por procesador), por hardware (por ejemplo, procesadores, memoria), por firmware y/o una combinación de estas formas. Como ejemplo, en el caso de software, se pueden cargar instrucciones de programa informático (código de programa legible por ordenador) en un ordenador para producir una máquina, de tal manera que las instrucciones que se ejecutan en el ordenador crean estructuras para implementar las funciones especificadas en el bloque o bloques de diagrama de flujo. Estas instrucciones de programa informático también se pueden almacenar en una memoria que puede indicar a un ordenador que funcione de una manera particular, de tal manera que las instrucciones almacenadas en la memoria produzcan un artículo de fabricación que incluya estructuras de instrucciones que implementen la función especificada en el bloque o bloques de diagrama de flujo. Las instrucciones de programa informático también se pueden cargar en un ordenador para hacer que se realicen una serie de etapas operativas en o mediante el ordenador para producir un proceso implementado por ordenador de tal manera que las instrucciones que se ejecutan en el ordenador proporcionan etapas para implementar las funciones especificadas en el bloque o bloques de diagrama de flujo. En consecuencia, los bloques de los diagramas de flujo soportan combinaciones de etapas, estructuras y/o módulos para realizar las funciones especificadas. También se entenderá que cada bloque de los diagramas de flujo y las combinaciones de bloques en los diagramas de flujo se pueden dividir y/o unir con otros bloques de los diagramas de flujo sin afectar el alcance de la invención. Esto puede dar como resultado, por ejemplo, que un código de programa legible por ordenador se almacene en su totalidad en una única memoria, o que diversos componentes del código de programa legible por ordenador se almacenen en más de una memoria.
IMPLEMENTACIONES ADICIONALES
La figura 23 ilustra un diagrama de flujo esquemático de un proceso 1000 para autenticar a un usuario para realizar una transacción en el sistema de procesamiento de pago de acuerdo con algunas implementaciones. En algunas implementaciones, el sistema de procesamiento de pago incluye uno o más módulos de pago 100 (por ejemplo, cada uno asociado con una unidad de aceptación de pago 120 respectiva, tal como una máquina de venta al por menor automática para dispensar bienes y/o servicios), uno o más dispositivos móviles 150 (por ejemplo, ejecutando cada uno la aplicación 140 para el sistema de procesamiento de pago como un proceso o bien de primer plano o bien de segundo plano) y el servidor 130. El servidor 130 gestiona el sistema de procesamiento de pago y, en algunos casos, está asociado con una entidad que suministra, opera y/o fabrica los uno o más módulos de pago 100. Por brevedad, el proceso 1000 se describirá con respecto a un módulo de pago 100 respectivo y un dispositivo móvil 150 respectivo en el sistema de procesamiento de pago.
El módulo de pago 100 radiodifunde (1002), a través de una capacidad de comunicación de corto alcance (por ejemplo, BLE), un paquete de información (a veces también denominado en el presente documento "información anunciada"). El paquete de información incluye al menos un código de autorización y un identificador asociado con el módulo de pago 100 (ID de módulo). En algunas implementaciones, el paquete de información incluye además una versión de firmware del módulo de pago 100 y uno o más indicadores de estado correspondientes a uno o más estados del módulo de pago 100 y/o la unidad de aceptación de pago 120. La información incluida en el paquete radiodifundido por el módulo de pago 100 se analiza adicionalmente a continuación con referencia a la figura 24A.
En algunas implementaciones, el módulo de pago 100 envía un código de autorización único cada X segundos (por ejemplo, 100 ms, 200 ms, 500 ms, etc.). En algunas implementaciones, los códigos de autorización únicos son números generados aleatoria o pseudoaleatoriamente. En algunas implementaciones, el módulo de pago 100 almacena códigos de autorización radiodifundidos hasta que un testigo de concesión de autorización recibido coincide con uno de los códigos de autorización almacenados. En algunas implementaciones, el módulo de pago 100 almacena códigos de autorización radiodifundidos durante un período de tiempo predeterminado (por ejemplo, Y minutos), después de lo cual vence y se elimina un código de autorización. En algunas implementaciones, el código de autorización se cifra con una clave secreta compartida conocida por el servidor 130 pero única del módulo de pago 100. En algunas implementaciones, el módulo de pago 100 inicializa un número aleatorio y entonces los códigos de autorización son recuentos secuenciales a partir de este número aleatorio. En tales implementaciones, el módulo de pago 100 almacena el contador válido (no vencido) más antiguo sin necesidad de almacenar cada código de autorización válido. En algunas implementaciones, el código de autenticación incluido en el paquete de información radiodifundido es un valor de troceo del número generado aleatoria o pseudoaleatoriamente o el número secuencial.
El dispositivo móvil 150 recibe el paquete de información radiodifundido y el dispositivo móvil 150 envía (1004), a través de una capacidad de comunicación de largo alcance (por ejemplo, GSM, CDMA, Wi-Fi o similares), una solicitud de autorización al servidor 130. Por ejemplo, una aplicación 140 que está asociada con el sistema de procesamiento de pago se está ejecutando como un proceso de primer plano o de segundo plano en el dispositivo móvil 150. En este ejemplo, la aplicación 140 recibe el paquete de información radiodifundido cuando el dispositivo móvil 150 está dentro de la zona de comunicación del módulo de pago 100 (es decir, alcance de BLE) y envía automáticamente la solicitud de autorización al servidor 130 o envía la solicitud de autorización al servidor 130 cuando el dispositivo móvil 150 está dentro de la zona de autorización del módulo de pago 100. En algunas implementaciones, el paquete de información radiodifundido incluye un umbral de zona de autorización de referencia (es decir, un criterio de zona de autorización) que indica un RSSI de referencia que se requiere que el dispositivo móvil 150 (o la aplicación 140) observe antes de estar dentro de la zona de autorización del módulo de pago 100. En algunas implementaciones, el dispositivo móvil 150 (o la aplicación 140) compensa el umbral de zona de autorización de referencia basándose en la intensidad y/o recepción de la capacidad de comunicación de corto alcance (por ejemplo, transceptor/radio de BLE) del dispositivo móvil 150. En algunas implementaciones, la solicitud de autorización incluye al menos el código de autorización que se incluyó en el paquete de información radiodifundido, un identificador asociado con el usuario del dispositivo móvil 150 o la cuenta de usuario bajo la cual el usuario del dispositivo móvil 150 se registra en la aplicación 140 (ID de usuario) y el identificador asociado con el módulo de pago 100 (ID de módulo). En algunas implementaciones, el código de autenticación incluido en la solicitud de autorización es el valor de troceo en texto sin cifrar. La solicitud de autorización se analiza adicionalmente a continuación con referencia a la figura 24B.
Después de recibir la solicitud de autorización, el servidor 130 procesa (1006) la solicitud de autorización. En algunas implementaciones, el servidor 130 descifra el código de autorización incluido en la solicitud de autorización con la clave secreta compartida correspondiente al módulo de pago 100. En algunas implementaciones, el servidor 130 determina si el usuario asociado con el ID de usuario en la solicitud de autorización tiene fondos suficientes en su cuenta para que el sistema de procesamiento de pago realice una transacción en la máquina 120 que está asociada con el módulo de pago 100 correspondiente al ID de módulo en la solicitud de autorización.
El servidor 130 envía (1008), a través de una capacidad de comunicación de largo alcance (por ejemplo, GSM, CDMA, Wi-Fi o similares), un testigo de concesión de autorización al dispositivo móvil 150. En algunas implementaciones, el servidor 130 no envía el testigo de concesión de autorización si el código de autorización en la solicitud de autorización no se puede descifrar con la clave secreta compartida correspondiente al módulo de pago 100 (por ejemplo, el código de autorización está corrompido o pirateado). En algunas implementaciones, el servidor 130 no envía el testigo de concesión de autorización si el usuario asociado con el ID de usuario en la solicitud de autorización no tiene fondos suficientes en su cuenta. En algunas implementaciones, además del testigo de concesión de autorización, el servidor 130 envía un mensaje directamente al dispositivo móvil 150 que no está cifrado con la clave secreta compartida correspondiente al módulo de pago 100. Después de recibir el mensaje, el dispositivo móvil 150 visualiza un mensaje apropiado al usuario, tal como saldo insuficiente o autorización rechazada. En algunas implementaciones, el servidor 130 envía un testigo de concesión de autorización para una cantidad igual a cero; caso en el cual, el módulo de pago 100 interpreta esto como una autorización rechazada o fallida, lo que se puede producir por cualquier número de razones incluyendo, pero sin limitarse a, saldo o crédito insuficiente.
El dispositivo móvil 150 recibe el testigo de concesión de autorización y, posteriormente, el dispositivo móvil 150 detecta (1010) una condición de desencadenamiento. En algunas implementaciones, el dispositivo móvil 150 (o la aplicación 140) detecta la condición de desencadenamiento a través del modo de manos libres (por ejemplo, tras la entrada en la zona de pago del módulo de pago 100) o el modo manual (por ejemplo, interaccionando con la interfaz de usuario de la aplicación 140 para iniciar una transacción con la unidad de aceptación de pago asociada con el módulo de pago 100).
En algunas implementaciones, las concesiones de autorización no usadas (por ejemplo, si no hubo condición de desencadenamiento alguna, o esta venció) son canceladas por el dispositivo móvil 150 enviando un mensaje de cancelación al servidor 130 correspondiente a la concesión de autorización no usada. En algunas implementaciones, el servidor 130 niega o limita el número de concesiones de autorización enviadas al dispositivo móvil 150 hasta que el mismo haya recibido información de transacción o la cancelación de concesiones de autorización pendientes de autorización enviadas al dispositivo móvil 150.
En respuesta a la detección de la condición de desencadenamiento, el dispositivo móvil 150 envía (1012), a través de una capacidad de comunicación de corto alcance (por ejemplo, BLE), el testigo de concesión de autorización al módulo de pago 100. Posteriormente, la máquina 120 visualiza crédito al usuario (por ejemplo, a través de uno de los visualizadores 122 o 124 mostrados en la figura 19) y el usuario interacciona con los mecanismos de entrada de la máquina 120 (por ejemplo, a través de los botones 126 o un visualizador de pantalla táctil 124 que se muestra en la figura 19) para comprar productos y/o servicios.
La figura 24A ilustra un diagrama de bloques de un paquete 1100 de información radiodifundida por el módulo de pago 100 (por ejemplo, en la etapa 1002 del proceso 1000 en la figura 23) de acuerdo con algunas implementaciones. En algunas implementaciones, el paquete 1100 incluye al menos: un ID de módulo 1102 y un código de autorización 1104. En algunas implementaciones, el paquete 110 adicional incluye: una versión de firmware 1106 y uno o más indicadores de estado 1108.
En algunas implementaciones, el ID de módulo 1102 es un identificador único correspondiente al módulo de pago 100 (a veces también denominado en el presente documento "módulo de adaptador 100") que radiodifunde el paquete 1100.
En algunas implementaciones, el código de autorización 1104 es un valor de troceo en texto sin cifrar. En algunas implementaciones, el módulo de pago 100 genera aleatoria o pseudoaleatoriamente un número o determina un número secuencial (véase la etapa 1002 del proceso 1000 en la figura 23) y realiza una función de troceo predeterminada (por ejemplo, SHA-256) sobre el número para producir el valor de troceo como el código de autorización 1104. En algunas implementaciones, el código de autorización 1104 es un código único que está cifrado con una clave de cifrado secreta correspondiente al módulo de pago 100. La clave de cifrado secreta se comparte con el servidor 130, lo que habilita al servidor 130 para descifrar el código de autorización 1104 y cifrar el testigo de concesión de autorización, pero no al dispositivo móvil 150. En algunas implementaciones, el cifrado entre el servidor 130 y el módulo de pago 100 se logra mediante dos pares de claves pública/privada.
En algunas implementaciones, la información de versión de firmware 1106 identifica una versión de firmware 1112 actual del módulo de pago 100. En algunas implementaciones, la información de versión de firmware 1106 también incluye información de estado de actualización 1114 que indica uno o más paquetes recibidos por el módulo de pago 100 para actualizar el firmware o uno o más paquetes que el módulo de pago 100 necesita para actualizar el firmware. En algunas implementaciones, los uno o más indicadores de estado 1108 indican un estado del módulo de pago 100 y/o la unidad de aceptación de pago 120 asociada con el módulo de pago 100. En algunas implementaciones, los uno o más indicadores de estado 1108 indican un estado del módulo de pago 100, tal como que el indicador de información de carga 1116 indique que el módulo de pago 100 tiene información a cargar en el servidor 130 (por ejemplo, información de transacción para una o más transacciones interrumpidas). En algunas implementaciones, el indicador de información de carga 1116 desencadena que el dispositivo móvil 150 se conecte al módulo de pago 100 inmediatamente (por ejemplo, si este tiene información de transacción interrumpida a cargar en el servidor 130). En algunas implementaciones, los uno o más indicadores de estado 1108 indican un estado de la unidad de aceptación de pago 120 que incluye uno o más de un indicador de error 1118 (por ejemplo, que indica que un aceptador de billetes y/o monedas de la unidad de aceptación de pago 120 está experimentando un atasco, código de error o mal funcionamiento), un indicador de nivel de moneda 1120 (por ejemplo, que indica que el nivel del depósito de aceptador de billetes y/o de monedas de la unidad de aceptación de pago 120 está lleno o vacío) y/o un indicador de nivel o niveles de inventario 1122 (por ejemplo, que indica que uno o más productos de la unidad de aceptación de pago 120. En algunas implementaciones, los uno o más indicadores de estado 1108 son códigos de error emitidos por la unidad de aceptación de pago 120 a través del MDB.
En algunas implementaciones, la información de criterios de zona 1110 especifica un criterio de zona de autorización 1124 (por ejemplo, un umbral de zona de autorización de referencia que indica un RSSI de referencia que se requiere que el dispositivo móvil 150 (o la aplicación 140) observe antes de estar dentro de la zona de autorización del módulo de pago 100) y/o un criterio de zona de pago 1126 (por ejemplo, un umbral de zona de pago de referencia que indica un RSSI de referencia que se requiere que el dispositivo móvil 150 (o la aplicación 140) observe antes de estar dentro de la zona de pago del módulo de pago 100). En algunas implementaciones, el umbral de zona de autorización de referencia y el umbral de zona de pago de referencia son valores por defecto determinados por el servidor 130 o almacenados como variables por la aplicación 140, caso en el cual el criterio de zona de autorización 1124 y el criterio de zona de pago 1126 son compensaciones para compensar la intensidad y/o recepción de la capacidad de comunicación de corto alcance (por ejemplo, transceptor/radio de BLE) del módulo de pago 100. Como alternativa, la información de criterios de zona 1110 incluye una extensión entre el umbral de zona de autorización de referencia y el umbral de zona de pago de referencia. Por tanto, el dispositivo móvil 150 (o la aplicación 140) determina el umbral de zona de autorización de referencia y el umbral de zona de pago de referencia basándose en el valor de extensión y un valor por defecto para o bien el umbral de zona de autorización de referencia o bien el umbral de zona de pago de referencia. Por ejemplo, la extensión indica -10 dB y el umbral de zona de pago de referencia por defecto es -90 dB; por lo tanto, el umbral de zona de autorización de referencia es -80 dB. Continuando con este ejemplo, después de determinar el umbral de zona de autorización de referencia y el umbral de zona de pago de referencia, el dispositivo móvil 150 (o la aplicación 140) puede ajustar adicionalmente el umbral de zona de autorización y/o el umbral de zona de pago basándose en la intensidad y/o recepción de su capacidad de comunicación de corto alcance (es decir, transceptor/radio de BLE).
La figura 24B es un diagrama de bloques de una solicitud de autorización 1130 enviada por el dispositivo móvil 150 al servidor 130 (por ejemplo, en la etapa 1004 del proceso 1000 en la figura 23) de acuerdo con algunas implementaciones. En algunas implementaciones, la solicitud de autorización 1130 incluye al menos: un ID de módulo 1102, un ID de usuario 1134 y un código de autorización 1104.
En algunas implementaciones, el ID de módulo 1102 es un identificador único correspondiente al módulo de pago 100 que radiodifundió el 1100 que incluía el código de autorización 1104.
En algunas implementaciones, el ID de usuario 1134 es un identificador asociado con el usuario del dispositivo móvil 150 que envía la solicitud de autorización 1130 al servidor 130. En algunas implementaciones, el ID de usuario 1134 está asociado con la cuenta de usuario bajo la cual el usuario del dispositivo móvil 150 se registra en la aplicación 140.
En algunas implementaciones, el código de autorización 1130 incluye el código de autorización 1104 incluido en el paquete 1100 de información que fue radiodifundido por el módulo de pago 100.
La figura 24C es un diagrama de bloques de un testigo de concesión de autorización 1140 enviado por el servidor 130 al dispositivo móvil 150 (por ejemplo, en la etapa 1008 del proceso 1000 en la figura 23) de acuerdo con algunas implementaciones. En algunas implementaciones, de acuerdo con una determinación de que el código de autorización 1136 incluido en la solicitud de autorización 1130 del dispositivo móvil 150 es válido y que el usuario asociado con el dispositivo móvil 150 tiene fondos suficientes en su cuenta para el sistema de procesamiento de pago, el servidor 130 genera el testigo de concesión de autorización 1140. En algunas implementaciones, el testigo de concesión de autorización 1140 incluye al menos: un ID de módulo 1102, un ID de usuario 1134, una cantidad autorizada 1146, (opcionalmente) una compensación de período de vencimiento 1148 y (opcionalmente) el código de autorización 1104.
En algunas implementaciones, el ID de módulo 1102 es un identificador único correspondiente al módulo de pago 100 que radiodifundió el paquete 1100 que incluía el código de autorización 1104.
En algunas implementaciones, el ID de usuario 1134 es un identificador asociado con el usuario del dispositivo móvil 150 que envió la solicitud de autorización 1130 al servidor 130.
En algunas implementaciones, la cantidad autorizada 1146 indica una cantidad máxima por la cual el usuario del dispositivo móvil 150 está autorizado para una transacción usando el testigo de concesión de autorización 1140. Por ejemplo, la cantidad autorizada 1146 está predefinida por el usuario del dispositivo móvil 150 o por el servidor 130 basándose en un límite diario o basándose en el saldo de cuenta total del usuario o basándose en un perfil de riesgo del usuario que corresponde al ID de usuario 1134.
En algunas implementaciones, la compensación del período de vencimiento 1148 indica una compensación a la cantidad de tiempo que el módulo de pago 100 mantiene el testigo de concesión de autorización 1140 válido para el inicio de una transacción con la máquina 120 asociada con el módulo de pago 100. Por ejemplo, la compensación de período de vencimiento 1148 depende del historial y el crédito del usuario del dispositivo móvil 150 o de un período predefinido por el usuario del dispositivo móvil 150.
En algunas implementaciones, el testigo de concesión de autorización 1140 incluye además el código de autorización 1104 que se incluyó en la solicitud de autorización 1130. En algunas implementaciones, cuando el código de autorización 1104 es el valor de troceo, el servidor 130 cifra el testigo de concesión de autorización 1140 que incluye el valor de troceo con la clave de cifrado secreta compartida asociada con el módulo de pago 100. Posteriormente, cuando el dispositivo móvil 150 envía el testigo de concesión de autorización 1140 al módulo de pago 100 después de detectar una condición de desencadenamiento, el módulo de pago 100 descifra el testigo de concesión de autorización 1140 usando la clave secreta conocida solo por el servidor 130 y el módulo de pago 100 (que autentica el mensaje y la concesión de autorización), y entonces hace coincidir el valor de troceo incluido en el testigo de concesión de autorización 1140 descifrado con valores de troceo válidos (no vencidos) previamente radiodifundidos (es decir, códigos de autenticación) para determinar la validez de la (que solo era conocida por el módulo de pago 100).
La figura 24D ilustra un diagrama de bloques de la información de transacción 1150 generada por el módulo de pago 100 (por ejemplo, en la etapa 1254 del proceso 1250 en la figura 25B) de acuerdo con algunas implementaciones. En algunas implementaciones, la información de transacción 1150 incluye: un ID de transacción 1152 para la transacción respectiva, un ID de módulo 1154, un ID de usuario 1156, (opcionalmente) el código de autorización 1158, la información de estado de la transacción 1160, la cantidad de transacción 1162 y otra información 1164.
En algunas implementaciones, el ID de transacción 1152 es un identificador único correspondiente a la transacción respectiva. En algunas implementaciones, el ID de transacción 1152 se codifica basándose en, o asociado con, la hora y/o la fecha y la ubicación en las que tuvo lugar la transacción respectiva.
En algunas implementaciones, el ID de módulo 1154 es un identificador único correspondiente al módulo de pago 100 que realizó la transacción respectiva.
En algunas implementaciones, el ID de usuario 1156 es un identificador asociado con el usuario del dispositivo móvil 150 que inició la transacción respectiva.
En algunas implementaciones, el código de autorización 1158 corresponde al código de autorización original (por ejemplo, el código de autorización 1104, las figuras 24A-24C) y/o al testigo de concesión de autorización (por ejemplo, el testigo de concesión de autorización 1140, la figura 24C) que se usó para iniciar la transacción respectiva. En algunas implementaciones, el código de autorización 1156 está cifrado con una clave de cifrado única correspondiente al módulo de pago 100.
En algunas implementaciones, la información 1160 del estado de la transacción incluye una indicación de si la transacción respectiva se completó, no se completó o se canceló. Por ejemplo, la transacción respectiva está incompleta si se produjo un atasco en la unidad de aceptación de pago 120 y el usuario no recibió el producto asociado con la transacción respectiva. Por ejemplo, si el usuario se aleja de la unidad de aceptación de pago 120 después de que se haya abonado dinero para la transacción respectiva, se cancela la transacción respectiva. En otro ejemplo, si la transacción respectiva expira después de un período de tiempo predeterminado debido a que el usuario no pudo seleccionar un producto en la unidad de aceptación de pago 120, la transacción respectiva se cancela. En otro ejemplo, si el usuario acciona un mecanismo de devolución de billetes o de monedas de la unidad de aceptación de pago 120, se cancela la transacción respectiva.
En algunas implementaciones, la cantidad de transacción 1162 indica la cantidad de la transacción respectiva o la cantidad de cada una de múltiples transacciones (por ejemplo, en un escenario de multiexpendición). En algunas implementaciones, la cantidad de transacción 1162 está cifrada con una clave de cifrado única correspondiente al módulo de pago 100.
En algunas implementaciones, la otra información 1164 incluye otra información relacionada con la transacción respectiva, tal como los artículos dispensados por la unidad de aceptación de pago 120 y el tipo de transacción (por ejemplo, monedas, billetes, tarjeta de crédito, modo manual, modo de manos libres, etc.). En algunas implementaciones, la otra información 1164 incluye otra información relacionada con el módulo de pago 100 y/o la unidad de aceptación de pago 120 asociada con el módulo de pago 100. Por ejemplo, la otra información 1164 incluye una solicitud de verificación al servidor 130 con el fin de implementar firmware nuevo. En otro ejemplo, la otra información 1164 incluye información de transacción procedente de una o más transacciones interrumpidas previas. En otro ejemplo, la otra información 1164 incluye información de transacción para una o más transacciones pagadas a través de billetes y/o monedas. En otro ejemplo, la otra información 1164 incluye información de inventario con respecto a uno o más productos de la unidad de aceptación de pago 120.
La figura 25A ilustra un diagrama de flujo esquemático de un proceso 1200 para proporcionar una representación de un evento de máquina en un dispositivo móvil de acuerdo con algunas implementaciones. En algunas implementaciones, el sistema de procesamiento de pago incluye uno o más módulos de pago 100 (por ejemplo, cada uno asociado con una unidad de aceptación de pago 120 respectiva, tal como una máquina de venta al por menor automática para dispensar bienes y/o servicios), uno o más dispositivos móviles 150 (por ejemplo, ejecutando cada uno la aplicación 140 para el sistema de procesamiento de pago como un proceso o bien de primer plano o bien de segundo plano) y el servidor 130. El servidor 130 gestiona el sistema de procesamiento de pago y, en algunos casos, suministra, opera y/o fabrica los uno o más módulos de pago 100. Por brevedad, el proceso 1200 se describirá con respecto a un módulo de pago 100 respectivo asociado con una unidad de aceptación de pago 120 respectiva (a veces también denominada en el presente documento la "máquina 120") y un dispositivo móvil 150 respectivo en el sistema de procesamiento de pago.
En algunas implementaciones, el proceso 1200 tiene lugar después de que el dispositivo móvil 150 haya enviado la ConcesiónAut en la figura 8C. En algunas implementaciones, el proceso 1200 tiene lugar después de que el dispositivo móvil 150 haya enviado la concesión de autorización al módulo de pago 100 en la operación 1012 del proceso 1000 en la figura 23.
El módulo de pago 100 obtiene (1202) una indicación correspondiente a un evento en la máquina 120. Por ejemplo, después del proceso 1000 en la figura 23, el usuario del dispositivo móvil 150 selecciona un producto para comprar de la máquina 120 interaccionando con uno o más mecanismos de entrada de la máquina 120 (por ejemplo, botones 126 o un visualizador de pantalla táctil 124 mostrado en la figura 19), y la máquina 120 dispensa el producto seleccionado. Continuando con este ejemplo, después de que se haya dispensado el producto, la transacción se completa y el módulo de pago 100 obtiene una indicación procedente de la máquina de la transacción completada. En algunas implementaciones, la indicación incluye la cantidad de la transacción y (opcionalmente) información de estado de máquina asociada con la máquina 120, tal como información de inventario con respecto a uno o más productos de la unidad de aceptación de pago 120 y/o similares. En algunas implementaciones, la indicación incluye información de estado que indica que la transacción se canceló (por ejemplo, a través del accionamiento de un mecanismo de devolución de monedas en la máquina 120) o que hubo un error con la transacción (por ejemplo, un atasco de expendición u otro mal funcionamiento con la máquina 120).
Después de obtener la indicación correspondiente a la compleción de la primera transacción, el módulo de pago 100 genera (1204) una notificación correspondiente al evento en la máquina 120.
El módulo de pago 100 envía (1206), a través de una capacidad de comunicación de corto alcance (por ejemplo, BLE), la notificación al dispositivo móvil 150. En algunas realizaciones, además de la notificación correspondiente al evento en la máquina 120, el módulo de pago 100 envía una promoción o anuncio al dispositivo móvil 150 que está dirigida al usuario del dispositivo móvil 150 basándose en la transacción o el ID de usuario incluido en la ConcesiónAut o el testigo de concesión de autorización que inició la transacción. En algunas realizaciones, además de la notificación correspondiente al evento en la máquina 120, el módulo de pago 100 envía una promoción o anuncio seleccionado pseudoaleatoriamente al dispositivo móvil 150 que se selecciona de un conjunto de promociones o anuncios almacenados por el módulo de pago 100. Por ejemplo, la promoción es un vale para un refresco gratis después de la compra de diez refrescos de la máquina 120 por el usuario del dispositivo móvil 150. Por ejemplo, la promoción es un vale de un 50 % de descuento aleatorio o un vale de refresco gratis. Por ejemplo, la transacción corresponde a un refresco expendido y el anuncio corresponde a un refresco nuevo de la misma empresa que produce el refresco expendido.
El dispositivo móvil 150 proporciona (1208) una representación de la notificación. Por ejemplo, en la figura 26A, el dispositivo móvil 150 visualiza la interfaz de usuario 1302 en la pantalla táctil 152 con un mensaje 1306 que indica que la primera transacción está completa. Por ejemplo, en la figura 26C, el dispositivo móvil 150 visualiza la interfaz de usuario 1320 en la pantalla táctil 152 con un mensaje 1322 que indica que la transacción se canceló. Por ejemplo, en la figura 26D, el dispositivo móvil 150 visualiza la interfaz de usuario 1330 en la pantalla táctil 152 con un mensaje 1332 que indica que hubo un error con la transacción. Por ejemplo, el dispositivo móvil 150 también visualiza una representación de la promoción de anuncios en la interfaz de usuario de la aplicación 140.
La figura 25B ilustra un diagrama de flujo esquemático de un proceso 1250 para procesar información de acuse de recibo de acuerdo con algunas implementaciones. En algunas implementaciones, el sistema de procesamiento de pago incluye uno o más módulos de pago 100 (por ejemplo, cada uno asociado con una unidad de aceptación de pago 120 respectiva, tal como una máquina de venta al por menor automática para dispensar bienes y/o servicios), uno o más dispositivos móviles 150 (por ejemplo, ejecutando cada uno la aplicación 140 para el sistema de procesamiento de pago como un proceso o bien de primer plano o bien de segundo plano) y el servidor 130. El servidor 130 gestiona el sistema de procesamiento de pago y, en algunos casos, suministra, opera y/o fabrica los uno o más módulos de pago 100. Por brevedad, el proceso 1250 se describirá con respecto a un módulo de pago 100 respectivo asociado con una unidad de aceptación de pago 120 respectiva (la máquina 120) y un dispositivo móvil 150 respectivo en el sistema de procesamiento de pago.
En algunas implementaciones, el proceso 1250 tiene lugar después de que el dispositivo móvil 150 haya enviado la ConcesiónAut en la figura 8C. En algunas implementaciones, el proceso 1250 tiene lugar después de que el dispositivo móvil 150 haya enviado la concesión de autorización al módulo de pago 100 en la operación 1012 del proceso 1000 en la figura 23.
El módulo de pago 100 obtiene (1252) una indicación correspondiente a la compleción de una primera transacción desde la máquina 120. Por ejemplo, después del proceso 1000 en la figura 23, el usuario del dispositivo móvil 150 selecciona un producto para comprar de la máquina 120 interaccionando con uno o más mecanismos de entrada de la máquina 120 (por ejemplo, botones 126 o un visualizador de pantalla táctil 124 mostrado en la figura 19), y la máquina 120 dispensa el producto seleccionado. Continuando con este ejemplo, después de que se haya dispensado el producto, la transacción se completa y el módulo de pago 100 obtiene una indicación procedente de la máquina de la transacción completada. En algunas implementaciones, la indicación incluye la cantidad de la transacción y (opcionalmente) información de estado de máquina asociada con la máquina 120, tal como información de inventario con respecto a uno o más productos de la unidad de aceptación de pago 120 y/o similares.
Después de obtener la indicación correspondiente a la compleción de la primera transacción, el módulo de pago 100 genera (1254) una primera notificación con una primera información de transacción basándose en la indicación, y el módulo de pago 100 almacena la primera información de transacción. En algunas implementaciones, la primera información de transacción incluye un ID de transacción para la primera transacción, un ID de módulo correspondiente al módulo de pago 100, un ID de usuario correspondiente al dispositivo móvil 150, información de estado de transacción que indica que la primera transacción está completa, y la cantidad de transacción indicada por la indicación. En algunas implementaciones, el módulo de pago 100 retiene el código de autorización incluido en el paquete radiodifundido original y/o el testigo de concesión de autorización e incluye el código de autorización en la primera información de transacción. En algunas implementaciones, el código de autorización se cifra con una clave secreta correspondiente al módulo de pago 100, que se comparte con el servidor 130 pero no con el dispositivo móvil 150. En algunas implementaciones, la primera información de transacción incluye además otra información tal como la información de estado de máquina incluida en la primera notificación o información de transacción correspondiente a una transacción o transacciones interrumpidas previas. Véase la figura 24D y el texto adjunto para un análisis adicional con respecto a la información de transacción 1150.
El módulo de pago 100 envía (1256), a través de una capacidad de comunicación de corto alcance (por ejemplo, BLE), la primera notificación con una primera información de transacción al dispositivo móvil 150. En algunas realizaciones, además de la primera información de transacción correspondiente a la compleción de la primera transacción en la máquina 120, la primera notificación incluye una promoción o anuncio al dispositivo móvil 150 que está dirigida al usuario del dispositivo móvil 150 basándose en la transacción o el ID de usuario incluido en la ConcesiónAut o el testigo de concesión de autorización que inició la transacción. En algunas realizaciones, además de la primera información de transacción correspondiente a la compleción de la primera transacción en la máquina 120, la primera notificación incluye una promoción o anuncio seleccionado pseudoaleatoriamente al dispositivo móvil 150 que se selecciona de un conjunto de promociones o anuncios almacenados por el módulo de pago 100. Por ejemplo, la promoción es un vale para un refresco gratis después de la compra de diez refrescos de la máquina 120 por el usuario del dispositivo móvil 150. Por ejemplo, la promoción es un vale de un 50 % de descuento aleatorio o un vale de refresco gratis. Por ejemplo, la transacción corresponde a un refresco expendido y el anuncio corresponde a un refresco nuevo de la misma empresa que produce el refresco expendido.
El dispositivo móvil 150 proporciona (1258) una representación de la primera notificación. Por ejemplo, en la figura 26A, el dispositivo móvil 150 visualiza la interfaz de usuario 1302 en la pantalla táctil 152 con un mensaje 1306 que indica que la primera transacción está completa. Por ejemplo, el dispositivo móvil 150 también visualiza una representación de la promoción de anuncios en la interfaz de usuario de la aplicación 140.
El dispositivo móvil 150 envía (1260), a través de una capacidad de comunicación de largo alcance (por ejemplo, GSM, CDMA, WiFi o similares), la primera información de transacción al servidor 130.
El servidor 130 procesa (1262) la primera información de transacción. Por ejemplo, el servidor 130 pasa el cargo a la cuenta del usuario asociado con el ID de usuario en la primera información de transacción con la cantidad indicada por la primera información de transacción.
El servidor 130 envía (1264), a través de una capacidad de comunicación de largo alcance (por ejemplo, GSM, CDMA, Wi-Fi o similares), una primera información de acuse de recibo al dispositivo móvil 150. En algunas implementaciones, la primera información de acuse de recibo da acuse de recibo de que el servidor 130 recibió la primera información de transacción. En algunas implementaciones, la primera información de acuse de recibo incluye el ID de usuario, el ID de módulo, el ID de transacción y (opcionalmente) la concesión de autorización incluida en la información de transacción (por ejemplo, la concesión de autorización 1158, la figura 24D).
Después de recibir la primera información de acuse de recibo, el dispositivo móvil 150 envía (1266), a través de una capacidad de comunicación de corto alcance (por ejemplo, BLE), la primera información de acuse de recibo al módulo de pago 100.
Después de recibir la primera información de acuse de recibo, el módulo de pago 100 elimina (1268) la primera información de transacción almacenada.
La atención se dirige a continuación a implementaciones de interfaces de usuario y procesos asociados que se pueden implementar en el dispositivo móvil 150 con cero o más altavoces, cero o más micrófonos y un visualizador. Por ejemplo, el visualizador es una pantalla táctil (a veces también denominada en el presente documento "visualizador de pantalla táctil") habilitada para recibir uno o más contactos y visualizar información (por ejemplo, contenido de medios, sitios web y páginas web de los mismos, interfaz de usuario para la aplicación 140, y/o interfaces de usuario para aplicaciones). Las figuras 26A-26D ilustran interfaces de usuario de ejemplo para proporcionar una representación de un evento de máquina en un dispositivo móvil de acuerdo con algunas implementaciones.
Las figuras 26A-26D muestran interfaces de usuario visualizadas en el dispositivo móvil 150 (por ejemplo, un teléfono móvil); sin embargo, un experto en la materia apreciará que las interfaces de usuario mostradas en las figuras 26A-26D se pueden implementar en otros dispositivos informáticos similares. Las interfaces de usuario en las figuras 26A-26D se usan para ilustrar los procesos descritos en el presente documento, incluyendo el proceso descrito con respecto a las figuras 25A-25B y 27A-27B.
Por ejemplo, un usuario del dispositivo móvil 150 se aproxima a una máquina 120 (por ejemplo, la máquina expendedora 78x928 como se muestra en las figuras 10A-10D) y ejecuta la aplicación 140 en el dispositivo móvil 150 con el fin de realizar una transacción electrónica con la máquina 120. Por ejemplo, con referencia a las figuras 10C-10D, el usuario del dispositivo móvil 150 inicia una transacción con la máquina 120 (por ejemplo, la máquina expendedora 78x928) realizando un gesto de deslizamiento en una ubicación correspondiente a la representación del billete de un dólar (por ejemplo, un gesto de deslizamiento sustancialmente vertical desde una ubicación correspondiente a la representación del billete de un dólar hasta el borde superior del dispositivo móvil 150).
La figura 26A ilustra el dispositivo móvil 150 que visualiza una interfaz de usuario 1302 de la aplicación 140 en la pantalla táctil 152 después de que el usuario del dispositivo móvil 150 haya iniciado y realizado una transacción con la máquina 120. En la figura 26A, la interfaz de usuario 1302 incluye un saldo de prepago 1304 que indica que se ha deducido 1,00 dólar del saldo de prepago después de realizar una transacción con la máquina 120 en comparación con el saldo de prepago en la figura 10C-10D (es decir, 9,00 dólares en las figuras 10C-10D y 8,00 dólares en la figura 26A). En la figura 26A, la interfaz de usuario 1302 también incluye un mensaje 1306 que indica que la transacción con la máquina 120 está completa.
La figura 26B ilustra el dispositivo móvil 150 que visualiza una interfaz de usuario 1310 de la aplicación 140 en la pantalla táctil 152 después de que el usuario del dispositivo móvil 150 haya iniciado una transacción con la máquina 120 y se produce un error con la transacción o la transacción se cancela. En la figura 26B, la interfaz de usuario 1310 muestra la representación del billete de un dólar deslizándose sobre la pantalla táctil 152 (por ejemplo, de una manera sustancialmente de arriba a abajo). En la figura 26B, la interfaz de usuario 1310 incluye un saldo de prepago 1312 que indica que no se ha deducido dinero alguno del saldo de prepago después de realizar una transacción con la máquina 120 en comparación con el saldo de prepago en la figura 10C-10D (es decir, 9,00 dólares en las figuras 10C-10D y 9,00 dólares en la figura 26B).
La figura 26C ilustra el dispositivo móvil 150 que visualiza una interfaz de usuario 1320 de la aplicación 140 en la pantalla táctil 152 después de que la representación del billete de un dólar se haya deslizado sobre la pantalla táctil 152 en la figura 26B debido a que se cancele la transacción. Por ejemplo, el usuario cancela la transacción accionando un mecanismo de devolución de monedas de la máquina 120. En otro ejemplo, el usuario cancela la transacción seleccionando una prestación de cancelación en la interfaz de la aplicación 140 (no mostrada). En la figura 26C, la interfaz de usuario 1320 incluye un mensaje 1322 que indica que la transacción con la máquina 120 fue cancelada y que el cargo por la transacción cancelada no se pasó a la cuenta del usuario.
La figura 26D ilustra el dispositivo móvil 150 que visualiza una interfaz de usuario 1330 de la aplicación 140 en la pantalla táctil 152 después de que la representación del billete de un dólar se haya deslizado sobre la pantalla táctil 152 en la figura 26B debido a la aparición de un error con la transacción. Por ejemplo, un mal funcionamiento con la máquina 120 (por ejemplo, un atasco de expendición o un artículo atorado) hace que se produzca el error. En la figura 26D, la interfaz de usuario 1330 está asociada con la aplicación 140 ejecutada en el dispositivo móvil 150. En la figura 26D, la interfaz de usuario 1330 incluye un mensaje 1332 que indica que se produjo un error durante la transacción con la máquina 120 y que el cargo por la transacción no se pasó a la cuenta del usuario.
Las figuras 27A-27B ilustran un diagrama de tipo diagrama de flujo de un método 1400 para presentar representaciones de eventos de unidad de aceptación de pago de acuerdo con algunas implementaciones. En algunas implementaciones, el método 1400 es realizado por un dispositivo con uno o más procesadores, memoria, uno o más dispositivos de salida y dos o más capacidades de comunicación. Por ejemplo, en algunas implementaciones, el método 1400 es realizado por el dispositivo móvil 150 (las figuras 5 y 21) o un componente del mismo (por ejemplo, la aplicación 140). En algunas implementaciones, el método 1400 se rige por instrucciones que se almacenan en un medio de almacenamiento legible por ordenador no transitorio (por ejemplo, la memoria 860, la figura 21) y las instrucciones son ejecutadas por uno o más procesadores (por ejemplo, la unidad de procesamiento 850, la figura 21) del dispositivo. Se indican operaciones opcionales por líneas discontinuas (por ejemplo, recuadros con bordes de línea discontinua).
Después de enviar una solicitud a un módulo de pago a través de una primera transacción de capacidad de comunicación para iniciar una transacción con una unidad de aceptación de pago (por ejemplo, una máquina que funciona con pagos fuera de línea, tal como una máquina expendedora o quiosco) asociada con el módulo de pago, el dispositivo móvil obtiene (1402) una notificación desde el módulo de pago a través de la primera capacidad de comunicación, en donde la notificación indica un evento en la unidad de aceptación de pago asociada con el módulo de pago. En algunas implementaciones, el método 1400 tiene lugar después de que el dispositivo móvil 150 haya enviado la ConcesiónAut en la figura 8C. En algunas implementaciones, el método 1400 tiene lugar después de que el dispositivo móvil 150 haya enviado la concesión de autorización al módulo de pago 100 en la operación 1012 del proceso 1000 en la figura 23. La operación 1206 de la figura 25A, por ejemplo, muestra el dispositivo móvil 150 recibiendo una notificación enviada por el módulo de pago 100 (por ejemplo, el módulo de adaptador 100, las figuras 5 y 20) enviada a través de la primera capacidad de comunicación (por ejemplo, una tecnología/protocolo de comunicación de corto alcance tal como BLE). La notificación indica un evento en la unidad de aceptación de pago (por ejemplo, la unidad de aceptación de pago 120, las figuras 5 y 19) (a veces también denominada en el presente documento "máquina 120") asociada con el módulo de pago 100.
En algunas implementaciones, la primera capacidad de comunicación corresponde (1404) a un protocolo de comunicación de corto alcance. Como se ha descrito anteriormente, los protocolos de comunicación de corto alcance incluyen BLE, NFC y/u otros protocolos que utilizan canales de comunicación no persistentes.
En respuesta a la obtención de la notificación, el dispositivo móvil proporciona (1406) una representación de la notificación a un usuario del dispositivo móvil a través de los uno o más dispositivos de salida del dispositivo móvil. Por ejemplo, en la figura 26A, el dispositivo móvil 150 visualiza la interfaz de usuario 1302 en la pantalla táctil 152 con un mensaje 1306 que indica que la primera transacción está completa. Por ejemplo, en la figura 26C, el dispositivo móvil 150 visualiza la interfaz de usuario 1320 en la pantalla táctil 152 con un mensaje 1322 que indica que la transacción se canceló. Por ejemplo, en la figura 26D, el dispositivo móvil 150 visualiza la interfaz de usuario 1330 en la pantalla táctil 152 con un mensaje 1332 que indica que hubo un error con la transacción.
En algunas implementaciones, los uno o más dispositivos de salida del dispositivo móvil incluyen (1408) al menos uno de: un visualizador, uno o más altavoces, uno o más LED y un mecanismo de vibración. Por ejemplo, el dispositivo móvil 150 incluye uno o más de un visualizador (por ejemplo, la pantalla táctil 152, las figuras 10A-10D), uno o más altavoces, uno o más LED y un mecanismo de vibración.
En algunas implementaciones, la representación de la notificación es al menos uno de (1410): un mensaje visualizado en el visualizador del dispositivo móvil; una notificación de cartel publicitario visualizada en un visualizador del dispositivo móvil; una alerta de vibración procedente del mecanismo de vibración del dispositivo móvil; una alerta auditiva procedente de los uno o más altavoces del dispositivo móvil; y una alerta visual procedente de los uno o más LED del dispositivo móvil. Por ejemplo, en las figuras 26B-26D, la representación de la notificación incluye los mensajes 1306, 1322 y 1332 visualizados en la pantalla táctil 152 del dispositivo móvil 150. En otro ejemplo, la representación de la notificación es una secuencia predefinida de vibraciones proporcionada por el mecanismo de vibración del dispositivo móvil 150. En otro ejemplo, la representación de la notificación es una secuencia predefinida de tonos proporcionada por los uno o más altavoces del dispositivo móvil 150. En otro ejemplo, la representación de la notificación es una secuencia predefinida de LED parpadeantes del dispositivo móvil 150.
En algunas implementaciones, la notificación indica (1412) la cancelación de una transacción iniciada por el usuario del dispositivo móvil. En la figura 26C, por ejemplo, la interfaz de usuario 1320 incluye el mensaje 1322 que indica que la transacción se ha cancelado. Por ejemplo, el usuario cancela la transacción accionando un mecanismo de devolución de monedas de la máquina 120. En otro ejemplo, el usuario cancela la transacción seleccionando una prestación de cancelación en la interfaz de la aplicación 140 (no mostrada).
En algunas implementaciones, la notificación indica (1414) la compleción de una transacción entre el usuario del dispositivo móvil y la unidad de aceptación de pago. En la figura 26A, por ejemplo, la interfaz de usuario 1302 incluye el mensaje 1306 que indica que la compleción de la transacción con la máquina 120 iniciada por el usuario del dispositivo móvil 150.
En algunas implementaciones, la notificación que indica la compleción de la transacción incluye al menos (1416) una cantidad de la transacción completada. En la figura 26A, por ejemplo, la interfaz de usuario 1302 incluye un saldo de prepago 1304 que indica que se ha deducido 1,00 dólar del saldo de prepago después de realizar una transacción con la máquina 120 en comparación con el saldo de prepago en la figura 10C-10D (es decir, 9,00 dólares en las figuras 10C-10D y 8,00 dólares en la figura 26A).
En algunas implementaciones, el dispositivo móvil envía (1418) al menos una porción de la notificación a un servidor a través de una segunda capacidad de comunicación distinta de la primera capacidad de comunicación. La operación 1260 de la figura 25B, por ejemplo, muestra el dispositivo móvil 150 enviando una primera información de transacción al servidor 130 para una transacción completa a través de la segunda capacidad de comunicación (por ejemplo, protocolos de comunicación de largo alcance tales como Wi-Fi, CDMA, GSM, y/o similares). Por ejemplo, la primera información de transacción incluye al menos la cantidad de la primera transacción completada.
En algunas implementaciones, la primera capacidad de comunicación corresponde (1420) a un protocolo de comunicación de corto alcance y la segunda capacidad de comunicación corresponde a un protocolo de comunicación de largo alcance. Por ejemplo, la primera capacidad de comunicación del dispositivo móvil 150 son unos medios de transceptor/radio para comunicarse a través de uno o más protocolos de comunicación de corto alcance tales como BLE, NFC y/o similares (es decir, un canal de comunicación no persistente). Por ejemplo, la segunda capacidad de comunicación del dispositivo móvil 150 son unos medios de transceptor/radio para comunicarse a través de uno o más protocolos de comunicación de largo alcance tales como Wi-Fi, CDMA, GSM y/o similares.
En algunas implementaciones, la notificación indica (1422) el fallo de una transacción iniciada por el usuario del dispositivo móvil o un mal funcionamiento asociado con la unidad de aceptación de pago. En la figura 26D, por ejemplo, la interfaz de usuario 1330 incluye el mensaje 1332 que indica que hubo un error con la transacción. Por ejemplo, la transacción falla debido a un atasco de expendición u otro mal funcionamiento. En otro ejemplo, la unidad de aceptación de pago experimenta un mal funcionamiento debido a una puerta abierta o similar. En algunas implementaciones, al menos una porción de la notificación de fallo/mal funcionamiento se envía al servidor 130 y, posteriormente, una alerta al operador de la unidad de aceptación de pago (por ejemplo, la máquina 120) es enviada por el servidor 130.
Se debería entender que el orden particular en el que se han descrito las operaciones en las figuras 27A-27B es simplemente para fines de ejemplo y no pretende indicar que el orden descrito es el único orden en el que se podrían realizar las operaciones. Un experto en la materia reconocería diversas maneras para reordenar las operaciones descritas en el presente documento. Además, se debería hacer notar que los detalles de otros procesos descritos en el presente documento con respecto a otros métodos descritos en el presente documento también son aplicables de manera análoga al método 1400 descrito anteriormente con respecto a las figuras 27A-27B.
La figura 28A ilustra un diagrama de bloques de una máquina que funciona con pagos fuera de línea 1500 de acuerdo con algunas implementaciones. Por ejemplo, la máquina que funciona con pagos fuera de línea 1500 (por ejemplo, una forma de la máquina 120) es una máquina electromecánica capaz de aceptar moneda (por ejemplo, monedas), que no está conectada a red alguna (por ejemplo, de teléfono, celular o de Wi-Fi). Por ejemplo, la máquina que funciona con pagos fuera de línea 1500 es una lavadora o secadora en una lavandería automática, un quiosco de pago para lavado de coches, una consola de videojuegos (es decir, una máquina recreativa de videojuegos que funciona con monedas), una mesa de billar que funciona con monedas, una máquina de dardos que funciona con monedas, una bomba de vacío o de aire que funciona con monedas (tal como las que se hallan comúnmente en estaciones de servicio), u otra máquina que funciona con pagos fuera de línea que dispensa bienes (por ejemplo, productos almacenados por la máquina 1500) y/o proporciona servicios (por ejemplo, permite a un usuario usar los servicios, tales como jugar a un videojuego, usar la lavadora o secadora, etc.). Las máquinas que funcionan con pagos fuera de línea están, en algunas circunstancias, no atendidas en el sentido de que ningún operador está físicamente cerca de la máquina mientras la máquina está funcionando normalmente. Por lo tanto, estas máquinas también se denominan en el presente documento "máquinas no atendidas", "máquinas no atendidas que funcionan con monedas" y "máquinas no atendidas que funcionan con pagos fuera de línea".
En la figura 28A, la máquina que funciona con pagos fuera de línea 1500 incluye un microconmutador 1502, una unidad de control 1506, una fuente de alimentación 1508, un transistor 1510 y una unidad de operación 1512. Los componentes de la máquina que funciona con pagos fuera de línea 1500 en la figura 28A son ejemplos y un experto en la materia apreciará que diversos otros componentes se pueden incluir en, o excluir de, la máquina que funciona con pagos fuera de línea 1500.
En la figura 28A, el microconmutador 1502 es un microconmutador con apalancamiento con una palanca 1504. Por ejemplo, el microconmutador 1502 es un microconmutador CHERRY BRAND™ con un terminal normalmente abierto ("NA"), un terminal normalmente cerrado ("NC") y un terminal común. Por ejemplo, la palanca 1504 está incorporada en una ranura para monedas de la máquina que funciona con pagos fuera de línea 1500 y se oprime siempre que una moneda se desliza por la ranura para monedas hacia un depósito de monedas de la máquina que funciona con pagos fuera de línea 1500 (no mostrada). Por ejemplo, cuando se oprime la palanca 1504 y el microconmutador 1502 está cableado en la configuración NA como se muestra en la figura 28A, el conmutador está cerrado. Continuando con este ejemplo, cuando el conmutador está cerrado, la unidad de control 1506 recibe un pulso (es decir, una señal de aceptación de pago) desde el terminal común del microconmutador 1502 que indica la opresión de la palanca 1504 a partir de la recepción de un cuarto de dólar estadounidense (es decir, 0,25 dólares) o una moneda de otro valor.
En algunas implementaciones, cuando la unidad 1506 de control recibe una secuencia preestablecida de señales de aceptación de pago indicativa de que el microconmutador 1502 recibe un número preestablecido de monedas, la unidad de control 1506 inicia la operación de la máquina que funciona con pagos fuera de línea 1500. Por ejemplo, después de recibir la secuencia preestablecida de señales de aceptación de pago (por ejemplo, tres pulsos que indican la recepción de tres cuartos de dólar estadounidense), la unidad de control 1506 inicia la operación de la máquina que funciona con pagos fuera de línea 1500 aplicando corriente a la puerta del transistor 1510, lo que permite que fluya corriente desde la fuente de alimentación 1508 a la unidad de operación 1512. Por ejemplo, la unidad operativa 1512 es un motor de una secadora que comienza a girar una vez que fluye corriente desde la fuente de alimentación 1508.
En la figura 28A, el módulo de pago 1520 (por ejemplo, una forma del módulo de adaptador 100, las figuras 5 y 20) está configurado para instalarse en la máquina que funciona con pagos fuera de línea 1500 con el fin de retroadaptar la máquina que funciona con pagos fuera de línea 1500 para ser capaz de aceptar pagos electrónicos. En algunas implementaciones, el módulo de pago 1520 se denomina en el presente documento un dispositivo de provisión de pulsos 1520 (como se analiza a continuación con referencia a las figuras 31-33). En algunas implementaciones, el módulo de pago 1520 incluye todos o algunos de los componentes incluidos en el módulo de adaptador 100 en la figura 20, tales como la unidad de procesamiento 750, la memoria 760, una unidad de seguridad 755 y una unidad de comunicaciones 770. En algunas implementaciones, el módulo de pago 1520 también incluye un primer módulo de interfaz 1522, un segundo módulo de interfaz 1524 y un conductor 1536 para extraer energía de la fuente de alimentación 1508 de la máquina que funciona con pagos fuera de línea 1500.
En la figura 28A, el primer módulo de interfaz 1522 está configurado para muestrear señales de aceptación de pago procedentes del microconmutador 1502 (por ejemplo, un conmutador de recepción de monedas) a través del conductor 1532 de la máquina que funciona con pagos fuera de línea 1500. Por ejemplo, las señales de aceptación de pago son indicativas de que una moneda es recibida por el microconmutador 1502, que oprime la palanca 1504. En la figura 28A, el segundo módulo de interfaz 1524 está configurado para muestrear señales de control procedentes de la unidad de control 1506 de la máquina que funciona con pagos fuera de línea 1500 a través del conductor 1534 que inicia una operación de la máquina que funciona con pagos fuera de línea (por ejemplo, la aplicación de corriente a la puerta del transistor 1510) en respuesta a recibir una secuencia preestablecida de señales de aceptación de pago procedentes del microconmutador 1502 (por ejemplo, el conmutador de recepción de monedas) indicativa del número preestablecido de monedas.
En algunas implementaciones, aunque una máquina no atendida particular (por ejemplo, 1500, la figura 28A) no está conectada a red alguna y un operador no está ubicado en las proximidades de la máquina no atendida particular, la máquina no atendida sigue siendo capaz de aceptar opciones configuradas de forma remota (por ejemplo, opciones de precios de múltiples créditos) que se configuran en un servidor y se envían al dispositivo de provisión de pulsos 1520 que está acoplado con la máquina no atendida particular a través de un intercambio cifrado de información con un teléfono móvil. En algunas implementaciones, el intercambio cifrado de información incluye instrucciones o datos que permiten que el dispositivo de provisión de pulsos 1520 proporcione pulsos eléctricos que se determinan de acuerdo con una opción configurada de forma remota que es seleccionada por un usuario del dispositivo móvil (por ejemplo, a través de un visualizador de interfaz de usuario en una aplicación 140, como se muestra en la figura 32). También se proporcionan detalles adicionales a continuación con referencia a las figuras 31-33.
La figura 28B ilustra señales muestreadas por el módulo de pago 1520 de acuerdo con algunas implementaciones. En la figura 28B, la muestra 1550 representa una secuencia preestablecida de señales de aceptación de pago muestreadas por el primer módulo de interfaz 1522 a través del conductor 1532 que se envían desde el microconmutador 1502 a la unidad de control 1506. Por ejemplo, la secuencia preestablecida de señales de aceptación de pago indicativa del número preestablecido de monedas incluye unos pulsos (es decir, señales de aceptación de pago) 1552, 1554, 1556 y 1558. Por ejemplo, los flancos de subida de los pulsos 1552, 1554, 1556 y 1558 en los tiempos 1582, 1584, 1586 y 1588 indican la recepción de una moneda por el microconmutador 1502 que hace que el conmutador se cierre cuando se cablea en la configuración NA como se muestra en la figura 28A. En la figura 28b , la muestra 1570 representa una señal de control muestreada por el segundo módulo de interfaz 1524 a través del conductor 1534 que se envía desde la unidad de control 1506 al transistor 1510. En la figura 28B, la muestra 1570 incluye un pulso 1572 que se envía desde la unidad de control 1506 al transistor 1510 en el tiempo 1590 después de recibir la secuencia preestablecida de señales de aceptación de pago procedentes del microconmutador 1502 (es decir, los pulsos 1552, 1554, 1556 y 1558).
Las figuras 29A-29B ilustran un diagrama de tipo diagrama de flujo de un método para retroadaptar una máquina que funciona con pagos fuera de línea para aceptar pagos electrónicos de acuerdo con algunas implementaciones. En algunas implementaciones, el método 1600 es realizado por un módulo de pago con uno o más procesadores y memoria. En algunas implementaciones, el módulo de pago también incluye una capacidad de comunicación de corto alcance correspondiente a un protocolo de comunicación de corto alcance (por ejemplo, un canal de comunicación no persistente tal como BLE, NFC y/o similares), en donde la capacidad de comunicación de corto alcance está configurada para comunicarse con uno o más dispositivos móviles, en donde cada uno de los uno o más dispositivos móviles está configurado con una capacidad de comunicación de corto alcance de cortesía y una capacidad de comunicación de largo alcance correspondiente a un protocolo de comunicación de largo alcance (por ejemplo, Wi-Fi, CDMA, GSM y/o similares).
En algunas implementaciones, el módulo de pago está acoplado con una máquina que funciona con pagos fuera de línea (por ejemplo, la unidad de aceptación de pago 120, las figuras 5 y 19 (a veces también denominada en el presente documento "máquina 120"), o la máquina que funciona con pagos fuera de línea 1500, la figura 28A) tal como una secadora o lavadora en una lavandería automática, un parquímetro, un quiosco de pago para lavado de coches, o similares. En algunas implementaciones, la máquina que funciona con pagos fuera de línea incluye un conmutador de recepción de monedas (por ejemplo, el microconmutador 1502, la figura 28A) y una unidad de control (por ejemplo, la unidad de control 1506, la figura 28A). En algunas implementaciones, el módulo de pago incluye además: (A) un primer módulo de interfaz (por ejemplo, el primer módulo de interfaz 1522, la figura 28A) configurado para muestrear señales de aceptación de pago procedentes del conmutador de recepción de monedas de la máquina que funciona con pagos fuera de línea, en donde las señales son indicativas de que una moneda es recibida por el conmutador de recepción de monedas; y (B) un segundo módulo de interfaz (por ejemplo, el segundo módulo de interfaz 1524, la figura 28A) configurado para muestrear señales de control procedentes de la unidad de control de la máquina que funciona con pagos fuera de línea que inicia una operación de la máquina que funciona con pagos fuera de línea en respuesta a recibir una secuencia preestablecida de señales de aceptación de pago procedentes del conmutador de recepción de monedas indicativa del número preestablecido de monedas. Al muestrear y almacenar estas señales, el módulo de pago 1520 es capaz de simular la operación de un conmutador de recepción de monedas respectivo en respuesta a la recepción del número correcto/preestablecido de monedas con el fin de desencadenar la operación de la máquina que funciona con pagos fuera de línea en respuesta a la compleción de un pago electrónico.
Por ejemplo, en algunas implementaciones, el método 1600 es realizado por el módulo de adaptador 100 (las figuras 5 y 20) o el módulo de pago 1520 (la figura 28A). En algunas implementaciones, el método 1600 se rige por instrucciones que se almacenan en un medio de almacenamiento legible por ordenador no transitorio (por ejemplo, la memoria 760, la figura 20) y las instrucciones son ejecutadas por uno o más procesadores (por ejemplo, la unidad de procesamiento 750, la figura 20) del módulo de pago. Se indican operaciones opcionales por líneas discontinuas (por ejemplo, recuadros con bordes de línea discontinua).
En algunas implementaciones, el módulo de pago detecta (1602), a través del primer módulo de interfaz, una secuencia preestablecida de señales de aceptación de pago procedentes del conmutador de recepción de monedas que hace que la unidad de control inicie la operación de la máquina que funciona con pagos fuera de línea, en donde la secuencia preestablecida de señales de aceptación de pago es indicativa de un número preestablecido de monedas recibidas por el conmutador de recepción de monedas. Por ejemplo, con referencia a las figuras 28A-28B, el primer módulo de interfaz 1522 del módulo de pago 1520 muestrea señales de aceptación de pago a través del conductor 1532 desde el microconmutador 1502 a la unidad de control 1506. Por ejemplo, cada una de las señales de aceptación de pago es indicativa de la recepción de una moneda por el microconmutador 1502. Continuando con este ejemplo, el segundo módulo de interfaz 1524 del módulo de pago 1520 muestrea señales de control a través del conductor 1534 desde la unidad de control 1506 al transistor 1510. El módulo de pago 1520 detecta una secuencia preestablecida de señales de aceptación de pago procedentes del microconmutador 1502 que hace que la unidad de control 1506 aplique una corriente a la puerta del transistor 1510 (por ejemplo, las señales de control). Por ejemplo, la secuencia preestablecida de señales de aceptación de pago es indicativa de un número preestablecido de monedas recibidas por el microconmutador 1502 para provocar la operación de la máquina que funciona con pagos fuera de línea 1500. Por ejemplo, la aplicación de corriente a la puerta del transistor 1510 permite que fluya corriente desde la fuente de alimentación 1508 a la unidad de operación 1512 de tal manera que la operación. Por ejemplo, la unidad operativa 1512 es un motor de una secadora que comienza a girar una vez que fluye corriente desde la fuente de alimentación 1508.
En algunas implementaciones, el módulo de pago determina (1604) la secuencia de señales predefinida para emular la secuencia preestablecida de señales de aceptación de pago procedentes del conmutador de recepción de monedas. En algunas implementaciones, después de detectar la secuencia preestablecida de señales de aceptación de pago que hace que la unidad de control 1506 inicie la operación de la máquina que funciona con pagos fuera de línea 1500, el módulo de pago 1520 determina una secuencia de señales predefinida para emular la secuencia preestablecida de señales de aceptación de pago. En algunas implementaciones, el valor monetario asociado con cada pulso en la secuencia preestablecida de señales de aceptación de pago procedentes del microconmutador 1502, indicativo del número preestablecido de monedas para iniciar la operación de la máquina que funciona con pagos fuera de línea 1500, es una moneda (por ejemplo, dólar estadounidense) y una cantidad (por ejemplo, 0,25 dólares) por defecto establecidas en el firmware del módulo de pago 1520. En algunas implementaciones, el valor monetario asociado con cada pulso en la secuencia preestablecida de señales de aceptación de pago del microconmutador 1502, indicativo del número preestablecido de monedas para iniciar la operación de la máquina que funciona con pagos fuera de línea 1500, es establecido por el servidor 130 y se puede cambiar de forma remota usando el dispositivo móvil 150 como un puente de comunicaciones para enviar información que indica el valor de un pulso desde el servidor 130 al dispositivo móvil 150 a través de la segunda capacidad de comunicación (por ejemplo, GSM, CDMA o Wi-Fi) y reenviando la información desde el dispositivo móvil al módulo de pago 1520 a través de la primera capacidad de comunicación (por ejemplo, BLE). Por ejemplo, en la mayoría de los casos, cada pulso es de 0,25 dólares estadounidenses. Los detalles adicionales con respecto a opciones de configuración remota para máquinas que funcionan con pagos fuera de línea también se proporcionan a continuación con referencia a las figuras 31-33.
En algunas implementaciones, determinar la secuencia de señales predefinida incluye (1606) al menos uno de: identificar un recuento de los pulsos en la presente secuencia de señales de aceptación de pago; identificar una amplitud de los pulsos en la presente secuencia de señales de aceptación de pago; identificar una forma de los pulsos en la presente secuencia de señales de aceptación de pago; e identificar un intervalo entre pulsos. En algunas implementaciones, después de detectar la secuencia preestablecida de señales de aceptación de pago (por ejemplo, la muestra 1550, la figura 28B), el módulo de pago 1520 determina una secuencia de señales predefinida para emular la secuencia preestablecida de señales de aceptación de pago identificando un recuento de los pulsos en la secuencia preestablecida de señales de aceptación de pago, un intervalo entre pulsos en la secuencia preestablecida de señales de aceptación de pago, la forma de los pulsos en la secuencia preestablecida de señales de aceptación de pago y una amplitud de los pulsos en la secuencia preestablecida de señales de aceptación de pago.
El módulo de pago recibe (1608) una solicitud a través de la capacidad de comunicación de corto alcance desde un dispositivo móvil respectivo para realizar una operación de la máquina que funciona con pagos fuera de línea. Por ejemplo, con referencia a la figura 8C, el módulo de pago 1520 (la figura 28A) recibe la ConcesiónAut desde el dispositivo móvil 150 a través de la capacidad de comunicación de corto alcance (por ejemplo, BLE) que indica que el usuario del dispositivo móvil 150 desea realizar la operación de la máquina que funciona con pagos fuera de línea 1500 (la figura 28A). Por ejemplo, con referencia a la operación 1012 en la figura 23, el módulo de pago 1520 (la figura 28A) recibe un testigo de concesión de autorización desde el dispositivo móvil 150 a través de la capacidad de comunicación de corto alcance (por ejemplo, BLE) que indica que el usuario del dispositivo móvil 150 desea realizar la operación de la máquina que funciona con pagos fuera de línea 1500 (la figura 28A).
El módulo de pago valida (1610) la solicitud. La validación de la solicitud indica (1612) que el dispositivo móvil respectivo está autorizado para iniciar el pago de la operación por un servidor remoto a través de la capacidad de comunicación de largo alcance. En algunas implementaciones, el módulo de pago 1520 valida la solicitud del dispositivo móvil 150 determinando si la ConcesiónAut o el testigo de concesión de autorización incluye un código de autorización válido.
De acuerdo con una determinación de que la solicitud es válida, el módulo de pago hace que (1614) la máquina que funciona con pagos realice la operación emitiendo una secuencia de señales predefinida a la unidad de control, en donde la secuencia de señales predefinida emula una secuencia de señales que sería emitida por el conmutador de recepción de monedas en respuesta a la recepción de un número preestablecido de monedas. Por ejemplo, con referencia a la figura 28B, el módulo de pago 1520 emite una secuencia de señales predefinida con el primer módulo de interfaz 1522 a la unidad de control 1506 que emula la muestra 1550 en la figura 28B. Continuando con este ejemplo, en respuesta a recibir la secuencia de señales predefinida desde el módulo de pago 1520, la unidad de control 1506 provoca el inicio de la operación de la máquina que funciona con pagos fuera de línea 1500 aplicando corriente a la puerta del transistor 1510, lo que permite que fluya corriente desde la fuente de alimentación 1508 a la unidad de operación 1512. En algunas implementaciones, la unidad de control 1506 provoca el inicio de la operación estableciendo un temporizador a una cantidad de tiempo correspondiente al número preestablecido de monedas, con lo que fluye corriente a la puerta del transistor 1510 durante la cantidad de tiempo establecida. Por ejemplo, el número preestablecido de monedas es un número de monedas requerido para hacer funcionar la máquina que funciona con pagos fuera de línea 1500 durante una cantidad de tiempo por defecto y se pueden añadir monedas posteriores para ampliar la cantidad de tiempo que estará en funcionamiento la máquina que funciona con pagos fuera de línea 1500. En algunas implementaciones, el número preestablecido de monedas es un número de monedas requerido para hacer que la máquina que funciona con pagos fuera de línea 1500 dispense un artículo comprado, tal como detergente para lavandería.
Como alternativa, en algunas implementaciones, de acuerdo con una determinación de que la solicitud es válida, la máquina que funciona con pagos fuera de línea 1500 visualiza crédito al usuario (por ejemplo, a través de uno de los visualizadores 122 o 124 mostrados en la figura 19) y el usuario interacciona con los mecanismos de entrada de la máquina que funciona con pagos fuera de línea 1500 120 (por ejemplo, a través de los botones 126 o un visualizador de pantalla táctil 124 que se muestra en la figura 19) para realizar la operación de la máquina. Por ejemplo, si la máquina que funciona con pagos fuera de línea 1500 es una secadora, el usuario del dispositivo móvil 150 selecciona el ciclo de giro apropiado a través de los mecanismos de entrada de la secadora y, cuando el usuario del dispositivo móvil 150 selecciona un mecanismo de entrada de inicio/funcionamiento de la secadora, la unidad de control 1506 de la secadora provoca el inicio de la operación de la secadora (por ejemplo, arrancando un motor que corresponde a la unidad de operación 1512 en la figura 28A).
En algunas implementaciones, en lugar de emitir la secuencia de señales predefinida a la unidad de control, el dispositivo de provisión de pulsos 1520 emite una secuencia de señales configurada de forma remota (es decir, configurada de forma remota por un operador y enviada al dispositivo de provisión de pulsos 1520 a través del dispositivo móvil con la concesión de autorización) que corresponde al pago proporcionado por el usuario a través del dispositivo móvil. En algunas implementaciones, la secuencia de señales configurada de forma remota no corresponde a la secuencia de señales predefinida para un número equivalente de monedas. Por ejemplo, si el usuario elige enviar un pago de un dólar a la máquina no atendida (a través del dispositivo de provisión de pulsos 1520), la secuencia de señales predefinida observada por el dispositivo de provisión de pulsos 1520 puede indicar que se han de proporcionar cuatro pulsos predefinidos (con el fin de simular los pulsos proporcionados en respuesta a la recepción de cuatro cuartos de dólar por la máquina no atendida, pero en lugar de proporcionar esos cuatro pulsos predefinidos, el dispositivo de provisión de pulsos 1520 podría enviar cinco pulsos configurados de forma remota. De esta manera, los operadores son capaces de configurar fácilmente opciones de precios nuevas, sin tener que interaccionar físicamente con sus máquinas no atendidas ubicadas de forma remota. Se proporcionan detalles adicionales a continuación con referencia a las figuras 31-33.
En algunas implementaciones, antes de enviar la información de operación y después de hacer que la máquina que funciona con pagos fuera de línea realice la operación emitiendo la secuencia de señales predefinida a la unidad de control, el módulo de pago obtiene (1616) una notificación desde la máquina que funciona con pagos fuera de línea que indica el inicio de la operación de la máquina que funciona con pagos fuera de línea y el número preestablecido de monedas. Por ejemplo, después de emitir la secuencia de señales preestablecida a la unidad de control 1506, el módulo de pago 1520 (la figura 28A) obtiene una notificación que indica que la unidad de control 1506 envió señales de control para iniciar la operación de la máquina que funciona con pagos fuera de línea 1500 en respuesta a la recepción de la secuencia de señales predefinida. Por ejemplo, la notificación se obtiene al muestrear el segundo módulo de interfaz 1524 (por ejemplo, la muestra 1570, la figura 28B) unas señales de control enviadas por la unidad de control 1506 (por ejemplo, la aplicación de corriente a la puerta del transistor 1510, lo que permite que fluya corriente desde la fuente de alimentación 1508 a la unidad de operación 1512).
En respuesta a la recepción de la notificación, el módulo de pago (1618): genera la información de operación basándose al menos en parte en la notificación; y almacena la información de operación generada en la memoria. Por ejemplo, después de obtener la notificación, el módulo de pago 1520 (la figura 28A) genera información de operación correspondiente al desempeño de la operación y el número preestablecido de monedas asociado con la secuencia de señales predefinida (por ejemplo, la cantidad requerida para iniciar la operación de la máquina que funciona con pagos fuera de línea 1500) y almacena la información de operación en una memoria local al módulo de pago 1520 (por ejemplo, la memoria 760, la figura 20).
En algunas implementaciones, el módulo de pago envía (1620) información de operación correspondiente a la operación al dispositivo móvil respectivo a través de la capacidad de comunicación de corto alcance. Por ejemplo, después de la operación 1618, el módulo de pago 1520 (la figura 28A) envía la información de operación al dispositivo móvil 150 a través de la primera capacidad de comunicación del dispositivo móvil 150, tal como unos medios de transceptor/radio para comunicarse a través de uno o más protocolos de comunicación de corto alcance tales como BLE, NFC y/o similares (es decir, un canal de comunicación no persistente).
Se debería entender que el orden particular en el que se han descrito las operaciones en las figuras 29A-29B es simplemente para fines de ejemplo y no pretende indicar que el orden descrito es el único orden en el que se podrían realizar las operaciones. Un experto en la materia reconocería diversas formas de reordenar las operaciones descritas en el presente documento (por ejemplo, incluyendo detalles del método 1700 en la figura 30 y/o el método 3200 de la figura 32). Además, se debería hacer notar que los detalles de otros procesos descritos en el presente documento con respecto a otros métodos descritos en el presente documento (por ejemplo, el método 1700 en la figura 30 o el método 3200 de la figura 32) también son aplicables de manera análoga al método 1600 descrito anteriormente con respecto a las figuras 29A-29B.
La figura 30 ilustra un diagrama de tipo diagrama de flujo de un método 1700 para habilitar que una máquina que funciona con pagos acepte pagos electrónicos de acuerdo con algunas implementaciones. En algunas implementaciones, el método 1700 es realizado por una máquina que funciona con pagos fuera de línea (por ejemplo, la unidad de aceptación de pago 120, las figuras 5 y 19 (a veces también denominada en el presente documento "máquina 120"), o la máquina que funciona con pagos fuera de línea 1500, la figura 28A) tal como una secadora o lavadora en una lavandería automática, un parquímetro, un quiosco de pago para lavado de coches, o similares.
En algunas implementaciones, la máquina que funciona con pagos fuera de línea incluye una unidad de control (por ejemplo, la unidad de control 1506, la figura 28A), memoria y un conmutador de recepción de monedas (por ejemplo, el microconmutador 1502, la figura 28A). En algunas implementaciones, la máquina que funciona con pagos fuera de línea también incluye una capacidad de comunicación de corto alcance correspondiente a un protocolo de comunicación de corto alcance (por ejemplo, un canal de comunicación no persistente tal como BLE, NFC y/o similares), en donde la capacidad de comunicación de corto alcance está configurada para comunicarse con uno o más dispositivos móviles, en donde cada uno de los uno o más dispositivos móviles está configurado con una capacidad de comunicación de corto alcance de cortesía y una capacidad de comunicación de largo alcance correspondiente a un protocolo de comunicación de largo alcance (por ejemplo, Wi-Fi, CDMA, GSM y/o similares). Por ejemplo, en algunas implementaciones, el método 1700 es realizado por la máquina 120 (las figuras 5 y 19). En algunas implementaciones, el método 1700 se rige por instrucciones que se almacenan en un medio de almacenamiento legible por ordenador no transitorio y las instrucciones son ejecutadas por la unidad de control de la máquina que funciona con pagos fuera de línea.
La máquina que funciona con pagos fuera de línea recibe (1702) una solicitud a través de una capacidad de comunicación de corto alcance desde un dispositivo móvil respectivo para realizar una operación de la máquina que funciona con pagos fuera de línea. Por ejemplo, con referencia a la figura 8C, el módulo de pago 1520 (la figura 28a ) recibe la ConcesiónAut desde el dispositivo móvil 150 a través de la capacidad de comunicación de corto alcance (por ejemplo, BLE) que indica que el usuario del dispositivo móvil 150 desea realizar la operación de la máquina que funciona con pagos fuera de línea 1500 (la figura 28A). Por ejemplo, con referencia a la operación 1012 en la figura 23, el módulo de pago 1520 (la figura 28A) recibe un testigo de concesión de autorización desde el dispositivo móvil 150 a través de la capacidad de comunicación de corto alcance (por ejemplo, BLE) que indica que el usuario del dispositivo móvil 150 desea realizar la operación de la máquina que funciona con pagos fuera de línea 1500 (la figura 28A).
La máquina que funciona con pagos fuera de línea valida (1704) la solicitud. La validación de la solicitud indica (1706) que el dispositivo móvil respectivo está autorizado para iniciar el pago de la operación por un servidor remoto a través de la capacidad de comunicación de largo alcance. En algunas implementaciones, el módulo de pago 1520 valida la solicitud del dispositivo móvil 150 determinando si la ConcesiónAut o el testigo de concesión de autorización incluye un código de autorización válido.
De acuerdo con una determinación de que la solicitud es válida, la máquina que funciona con pagos fuera de línea realiza (1708) la operación emitiendo una secuencia de señales predefinida a la unidad de control, en donde la secuencia de señales predefinida emula un número preestablecido de monedas recibidas por el conmutador de recepción de monedas. Por ejemplo, de acuerdo con una determinación de que la solicitud es válida, la máquina que funciona con pagos fuera de línea o un componente de la misma emite una secuencia de señales predefinida a la unidad de control 1506 que emula la muestra 1550 en la figura 28B. Continuando con este ejemplo, en respuesta a recibir la secuencia de señales predefinida desde el módulo de pago 1520, la unidad de control 1506 provoca el inicio de la operación de la máquina que funciona con pagos fuera de línea 1500 aplicando corriente a la puerta del transistor 1510, lo que permite que fluya corriente desde la fuente de alimentación 1508 a la unidad de operación 1512. En otro ejemplo, de acuerdo con una determinación de que la solicitud es válida, la unidad de control 1506 provoca el inicio de la operación de la máquina que funciona con pagos fuera de línea 1500 aplicando corriente a la puerta del transistor 1510, lo que permite que fluya corriente desde la fuente de alimentación 1508 a la unidad de operación 1512.
Se debería entender que el orden particular en el que se han descrito las operaciones en la figura 30 es simplemente para fines de ejemplo y no pretende indicar que el orden descrito es el único orden en el que se podrían realizar las operaciones. Un experto en la materia reconocería diversas formas de reordenar las operaciones descritas en el presente documento (por ejemplo, incluyendo detalles del método 1600 o el método 3200). Además, se debería hacer notar que los detalles de otros procesos descritos en el presente documento con respecto a otros métodos descritos en el presente documento (por ejemplo, el método 1600 en las figuras 29A-29B o el método 3200 de la figura 32) también son aplicables de manera análoga al método 1700 descrito anteriormente con respecto a la figura 30.
La figura 31 es un diagrama de flujo esquemático de un proceso 3100 para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota para la máquina no atendida, de acuerdo con algunas implementaciones.
En algunas implementaciones, el proceso 3100 para determinar los pulsos eléctricos para proporcionar a una máquina no atendida se realiza a través de uno o más componentes de los sistemas de procesamiento de pago descritos en el presente documento. Como se muestra en la figura 31, los uno o más componentes incluyen una máquina no atendida 1500 (la figura 28A), un módulo (por ejemplo, un dispositivo de provisión de pulsos 1520 que está acoplado con la máquina no atendida a través de una interfaz interna de la máquina no atendida), una aplicación 140 (por ejemplo, una aplicación de pago móvil) que se está ejecutando en un dispositivo móvil 150, y un servidor 130.
En algunas implementaciones, la aplicación 140 está en comunicación con el dispositivo de provisión de pulsos 1520 (por ejemplo, a través de la transmisión de señales de Bluetooth, tales como señales de Bluetooth de baja energía (BLE)) que está acoplado con la máquina no atendida 1520. El dispositivo de provisión de pulsos 1520 anuncia un código de autorización (3102) y la aplicación 140 recibe la radiodifusión anunciada desde el dispositivo de provisión de pulsos 1520. La aplicación 140 solicita entonces una autorización desde el servidor 130 (3104). En algunas implementaciones, el servidor 130 crea una concesión de autorización usando una opción de precios por defecto para la máquina, cifra la concesión de autorización y la transmite al dispositivo móvil (3106). Las solicitudes de autorización y la creación de concesiones de autorización se han explicado con detalle anteriormente y, en particular, con referencia a las figuras 8A-8G.
En este momento, el usuario puede optar por enviar una cantidad de pago que corresponde a la opción de precios por defecto al dispositivo de provisión de pulsos 1520 o, como alternativa, seleccionar otra opción de precios (3108) que se recibió desde el servidor. En algunas implementaciones, la aplicación 140 que se ejecuta en el dispositivo móvil 150 también visualiza una interfaz de usuario que permite seleccionar entre las opciones de precios recibidas desde el servidor (se muestra una interfaz de usuario de ejemplo en la figura 32).
El usuario, por ejemplo, puede seleccionar una tercera opción que se visualiza dentro de la interfaz de usuario (por ejemplo, la opción para "4 créditos: 1,00 dólar", mostrada en la figura 33). La aplicación 140 hace que el dispositivo móvil 150 envíe una nueva solicitud de autorización al servidor, esta vez acompañada del valor de índice 3 (3110). Al recibir la solicitud de autorización, el servidor determina el valor de la opción de precios con el índice 3 para esa máquina particular, crea una nueva concesión de autorización y la envía al dispositivo móvil (3112).
En algunas implementaciones, el pago se envía entonces a la máquina no atendida 1520 después de la satisfacción de una condición de desencadenamiento (3114) (por ejemplo, una condición de desencadenamiento basada en proximidad, basándose en la proximidad del dispositivo móvil 150 al dispositivo de provisión de pulsos 1520, o una condición de desencadenamiento basada en entrada de usuario que se basa en una entrada de usuario (tal como un gesto de deslizamiento) que se recibe dentro de la aplicación 140). En algunas implementaciones, la concesión de autorización que se envía al módulo de pago (3116) incluye precios para la cantidad de los precios a los que hace referencia el valor de índice 3.
Además, la concesión de autorización también incluye información sobre el número de pulsos (y, en algunos casos, características de los pulsos, tales como la anchura de pulso que se ha explicado anteriormente) que el dispositivo de provisión de pulsos 1520 debería enviar a la máquina no atendida 1520. El dispositivo de provisión de pulsos 1520 descifra la concesión de autorización y recupera la información para el número de pulsos a proporcionar y entonces proporciona pulsos a la máquina no atendida de acuerdo con la información recuperada (3118). Entonces, el usuario es capaz de interaccionar con la máquina no atendida (por ejemplo, tener tantas partidas en una consola de videojuegos como pagó el usuario, ser capaz de usar una lavadora que funciona con monedas un número de veces basándose en el pago proporcionado por el usuario, y similares, basándose en el tipo de máquina no atendida 1520).
Con el fin de garantizar que se pasa el cargo apropiadamente a la cuenta del usuario, el proceso 3100 también incluye enviar información de compleción de transacción y cargar esa información en el servidor 130 (3122-3124). Los detalles con respecto al procesamiento y envío de la información de compleción de transacción (también denominada información de operación) se han proporcionado anteriormente con referencia a las operaciones 1616-1620 de la figura 29B.
En algunas implementaciones, se utiliza una estructura de datos que desacopla los precios y los pulsos para crear diversas opciones de precios. Más específicamente, puede ser posible una tabla de precios como sigue: 25 centavos = 1 pulso = 1 crédito; 50 centavos = 2 pulsos = 2 créditos; 1,00 = 5 pulsos = 5 créditos; y 2,00 = 12 pulsos = 12 créditos.
En algunas implementaciones, no se confía en que el dispositivo móvil 150 y la aplicación 140 le digan a la máquina no atendida cuántos créditos ha de recibir la misma. Estos componentes tampoco son de confianza para determinar la cantidad de créditos. En algunas implementaciones, toda esa información se configura en su lugar en el servidor 130. El usuario tiene acceso a la información sobre la matriz de precios, incluyendo el número de créditos (como se presenta en una interfaz de usuario mostrada en la aplicación 140, tal como la mostrada en la figura 32), y mientras al usuario le parece que la selección se está haciendo en la aplicación móvil, en algunas implementaciones, el usuario simplemente está seleccionando un valor de índice. En algunas implementaciones, el valor de índice se envía al servidor 130, en donde este consulta los precios y los créditos, cifra los detalles y lo envía de vuelta a la aplicación 140 (por ejemplo, como una concesión de autorización) con una clave de cifrado que solo puede ser leída por el dispositivo de provisión de pulsos 1520 particular que está acoplado con esa máquina no atendida particular (para la cual se generó la concesión de autorización).
En algunas implementaciones, las autorizaciones para todas las opciones de precios se pueden enviar a la aplicación (desde el servidor 130) en el momento de la solicitud de autorización original (por ejemplo, en el momento en el que la autorización solicitada para una concesión de autorización por defecto 130 es recibida por el servidor, tal como 3104 en la figura 31). En algunas implementaciones, cuando se selecciona posteriormente un valor de índice a través de una interfaz de usuario que se proporciona al usuario dentro de la aplicación 140 (por ejemplo, la que se muestra en la figura 32), se envía entonces una concesión de autorización indexada apropiada al dispositivo de provisión de pulsos 1520. En algunas implementaciones, todas las concesiones de autorización tienen el mismo código de autorización, por lo que una vez que se ha enviado una concesión de autorización con el mismo código de autorización al dispositivo de provisión de pulsos 1520, las concesiones de autorización restantes se invalidan debido a que el dispositivo de provisión de pulsos 1520 aceptará solo una concesión de autorización con el mismo código de autorización (como se ha explicado con detalle anteriormente con referencia a las figuras 8A-8G).
En algunas implementaciones, la cantidad y el número de pulsos se disocian y están en cualquier número independiente del valor del pulso.
En algunas implementaciones, las longitudes (anchuras) de pulso pueden ser diferentes para cada cantidad de crédito, y los pulsos pueden estar en una matriz (por ejemplo, cuando se envían tres pulsos en un deslizamiento: el primer pulso es de 10 ms, el segundo es de 50 ms, el tercero es de 10 ms).
En algunas implementaciones, cuando hay una oferta de máquina completa, se puede proporcionar una autorización instantánea a un usuario (por ejemplo, después de recibir una solicitud de autorización procedente de un dispositivo móvil) y se puede enviar una concesión de autorización apropiada a la máquina no atendida 1500 (a través del dispositivo móvil y el dispositivo de provisión de pulsos) sin requerir que el usuario pague (tenga un saldo) en primer lugar.
De esta manera, y usando el proceso 3100, diversas opciones de precios pueden ser seleccionadas por un usuario sin crear una relación de confianza entre la aplicación 140, el usuario y el dispositivo de provisión de pulsos 1520. El usuario no puede realizar una entrada de forma libre en número de créditos (estos están predefinidos en el servidor 130) y el usuario simplemente está seleccionando valores de índice que entonces son interpretados por el servidor 130 con el fin de enviar entonces datos de pulsos/crédito que están asociados con el valor de índice seleccionado al dispositivo de provisión de pulsos (es decir, el dispositivo móvil 150 se usa simplemente como un medio de comunicación para encaminar los datos de pulsos/crédito desde el servidor 130 al dispositivo de provisión de pulsos 1520).
La figura 32 ilustra un ejemplo de una interfaz de usuario en un dispositivo móvil que se usa para seleccionar una de las opciones configuradas de forma remota para la máquina no atendida, de acuerdo con algunas implementaciones.
Como se muestra en la figura 32, en algunas implementaciones, la interfaz de usuario incluye un número de opciones de precios para la máquina no atendida. Como se ha explicado anteriormente con referencia a la figura 31, las opciones de precios se reciben desde un servidor 130 en respuesta a una solicitud de autorización procedente de un usuario del dispositivo móvil 150. En algunas implementaciones, las opciones de precios son configuradas por un operador de la máquina no atendida a través de una interfaz basada en web (de tal manera que el operador no necesita estar en la proximidad física de la máquina no atendida con el fin de crear y hacer que haya opciones de precios nuevas disponibles para la máquina no atendida). Como también se ha explicado anteriormente, la interfaz de usuario no proporciona detalles con respecto a pulsos eléctricos que se proporcionarán a la máquina no atendida después de que el usuario haya seleccionado una de las opciones de precios.
En algunas implementaciones, la interfaz de usuario es una tarjeta específica de máquina (por ejemplo, la tarjeta específica de máquina 3202) que también incluye detalles con respecto a ofertas o promociones especiales para la máquina no atendida (por ejemplo, como se muestra en la figura 32, hay una oferta disponible de "Compre 7 y llévese 1 GRATIS"). Una vez que el usuario ha seleccionado la oferta disponible, el usuario es capaz de proporcionar un pago equivalente a 7 créditos que funcionan con monedas, pero recibirá 8 partidas en lugar de solo 7. Esto es debido a que el servidor 130 almacena información que indica que se han de proporcionar 8 pulsos a la máquina no atendida (a través del dispositivo de provisión de pulsos 1520) en respuesta a la recepción de un pago equivalente a 7 créditos que funcionan con monedas.
En algunas implementaciones, el operador selecciona la oferta disponible que está resaltada para su inclusión en el anverso de la tarjeta específica de máquina por el operador y también hay disponibles ofertas adicionales dando la vuelta a la tarjeta específica de máquina. Dar la vuelta a la tarjeta específica de máquina se realiza en respuesta a una selección de usuario de la pestaña de "ofertas especiales" y entonces se revela el reverso de la tarjeta específica de máquina, que muestra una o más ofertas adicionales para la máquina no atendida.
En algunas implementaciones, la interfaz de usuario también incluye una etiqueta para la máquina no atendida con la que se está interaccionando (por ejemplo, se muestra una etiqueta de "Street Fighter" en una porción superior de la interfaz de usuario, la figura 32). En algunas implementaciones, la interfaz de usuario también incluye una representación de la máquina no atendida (por ejemplo, una fotografía de la máquina no atendida que es tomada por un operador y entonces se carga en el servidor 130 para su presentación posterior a los usuarios a través de la aplicación 140).
Como también se muestra en la figura 32, también se ilustran porciones de tarjetas específicas de máquina para otras máquinas no atendidas (por ejemplo, tarjetas específicas de máquina 3204 y 3206). Un deslizamiento en una dirección lateral sobre la tarjeta específica de máquina permite al usuario acceder a tarjetas específicas de máquina para las otras máquinas no atendidas. Después de acceder a una nueva tarjeta específica de máquina para una de las otras máquinas no atendidas, entonces las solicitudes de autorización se presentan al servidor 130 con el fin de recibir las opciones de precios disponibles y las concesiones de autorización que corresponden a las opciones de precios disponibles para estas otras máquinas no atendidas (como se ha explicado anteriormente con respecto al proceso 3100, la figura 31). En algunas implementaciones, las concesiones de autorización por defecto para cada una de las otras máquinas no atendidas se reciben antes de que el usuario haya realizado un deslizamiento en la dirección lateral apropiada (de esta manera, se precarga la información de precios por defecto y se pueden obtener más adelante datos de precios específicos para otros índices si el usuario selecciona uno de los otros índices para las otras máquinas no atendidas).
La figura 33 es un diagrama de flujo de un método para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota para la máquina no atendida, de acuerdo con algunas implementaciones. Por conveniencia, el método 3300 se describe a continuación como es realizado por una aplicación (por ejemplo, la aplicación 140 descrita anteriormente) que se está ejecutando en un dispositivo móvil (por ejemplo, el dispositivo móvil 150 descrito anteriormente).
El método 3300 permite determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota para la máquina no atendida. Como se ha explicado anteriormente, las máquinas no atendidas no pueden aceptar opciones de precios configurables o en tiempo real debido a que estas están permanentemente cableadas para aceptar solo monedas específicas a unos valores de crédito específicos. Al retroadaptar una máquina no atendida con un dispositivo de provisión de pulsos 1520 (descrito anteriormente), los operadores de máquinas no atendidas son capaces de establecer opciones de precios nuevas y de hacer que las mismas estén disponibles para los usuarios a través de la aplicación 140. De esta forma, al implementar el método 3300, se mejora el funcionamiento de las máquinas no atendidas, se mejoran las experiencias de usuario en las máquinas no atendidas y los operadores pueden abrir flujos de ingresos nuevos.
Como se muestra en la figura 33, el método 3300 comienza cuando la aplicación detecta (3302), basándose en una radiodifusión recibida de un dispositivo de provisión de pulsos que está acoplado con la máquina no atendida, la presencia de la máquina no atendida en las proximidades de un dispositivo móvil. Por ejemplo, la radiodifusión es una transmisión Bluetooth de baja energía (BLE) enviada por el dispositivo de provisión de pulsos y esa transmisión incluye un código de autenticación (analizado con detalle con referencia a las figuras 8A-8G).
Después de detectar la presencia de la máquina no atendida, la aplicación recibe (3304), desde un servidor (por ejemplo, el servidor 130 descrito anteriormente), información sobre un primer conjunto de opciones configuradas de forma remota para interaccionar con la máquina no atendida. En algunas implementaciones, el servidor 130 no es capaz de comunicarse directamente con la máquina no atendida, debido a que la máquina no atendida no tiene una conexión de red.
En algunas implementaciones, las opciones configuradas de forma remota son opciones de precios. En algunas implementaciones, las opciones configuradas de forma remota son opciones de precios que se determinan de acuerdo con una programación de precios predefinida. En algunas implementaciones, la programación de precios predefinida se determina basándose en una hora del día actual en el servidor (de esta manera, la información de hora del día o de zona horaria recibida o comunicada a través del dispositivo móvil no es de confianza y solo se utiliza tal información de temporización procedente del servidor 130, con el fin de evitar o mitigar un potencial comportamiento malicioso). En algunas implementaciones, las opciones configuradas de forma remota son configuradas por un operador de la máquina no atendida sin requerir interacción física alguna con la máquina no atendida (por ejemplo, el operador solo necesita configurar las opciones a través del servidor, tal como a través de una interfaz basada en la web, y no necesita cambiar físicamente operación o interfaz alguna de la máquina no atendida).
En algunas implementaciones, las opciones configuradas de forma remota son distintas de aquellas opciones de precios que están disponibles a través de una interacción mecánica con la máquina no atendida (a través de la inserción de monedas en la máquina no atendida). Por ejemplo, un operador puede establecer ofertas 2 por 1, ofertas basadas en el tiempo (descuentos por usar la máquina después de, antes de o durante una hora determinada del día), ofertas de fidelidad (descuentos por usar la máquina no atendida en múltiples días de forma consecutiva), ofertas basándose en la última actividad (descuentos por volver a usar una máquina no atendida que no se ha usado durante más de un período de inactividad predeterminado), y similares, y estas opciones no están disponibles a menos que un usuario interaccione con la máquina no atendida a través de la aplicación 140 y el dispositivo de provisión de pulsos 1520 (debido a que estas opciones se han de transmitir dinámicamente a la máquina no atendida a través de comunicaciones con el servidor 130, como se explica en el presente documento).
En respuesta a recibir la información sobre el primer conjunto de opciones configuradas de forma remota, la aplicación visualiza (3306), dentro de la aplicación mientras esta se está ejecutando en el dispositivo móvil, objetos de interfaz de usuario que permiten la selección de opciones respectivas en el primer conjunto de opciones configuradas de forma remota. Un ejemplo de interfaz de usuario se muestra en la figura 32 (y se ha descrito anteriormente con referencia a las figuras 31 y 32).
La aplicación también detecta (3308) una selección de un primer objeto de interfaz de usuario que corresponde a una primera opción en el primer conjunto de opciones configuradas de forma remota. Después de (o en respuesta a) detectar la selección del primer objeto de interfaz de usuario, la aplicación recibe (3310), desde el servidor, información que incluye una concesión de autorización para la primera opción en la máquina no atendida, en donde la información incluye especificaciones con respecto a pulsos eléctricos a proporcionar a la máquina no atendida por el dispositivo de provisión de pulsos de acuerdo con la primera opción. De acuerdo con una determinación de que se ha cumplido una condición de desencadenamiento, el solicitante envía (3312) la información que incluye la concesión de autorización y las especificaciones al dispositivo de provisión de pulsos. Después de enviar la concesión de autorización y la información de pulsos al dispositivo de provisión de pulsos, la aplicación recibe (3314) una indicación (tal como una compleción de transacción o información de operación, como se ha explicado anteriormente con referencia a la figura 31), desde el dispositivo de provisión de pulsos, de que los pulsos eléctricos se proporcionaron a la máquina no atendida de acuerdo con las especificaciones.
En algunas implementaciones, la aplicación recibe una segunda indicación desde el servidor de que las opciones configuradas de forma remota ya no están en vigor. Por ejemplo, el servidor compara un primer valor de troceo que está asociado con las opciones configuradas de forma remota (tal como el primer conjunto) con un segundo valor de troceo que está asociado con las opciones configuradas de forma remota más recientes disponibles en el servidor. Si los valores de troceo no coinciden, entonces el servidor envía la indicación (a la aplicación 140). En respuesta a recibir la segunda indicación desde el servidor, la aplicación recibe un conjunto actualizado de opciones de precios configuradas de forma remota que es diferente del primer conjunto de opciones de precios configuradas de forma remota. En algunas implementaciones, se cancela cualquier pago que fuera enviado por el usuario a la máquina no atendida basándose en el primer conjunto de opciones configuradas de forma remota (ahora desactualizadas) y al usuario se le proporcionan objetos de interfaz de usuario que permiten la selección de una opción nueva que se proporciona entonces a través del conjunto actualizado de opciones configuradas de forma remota.
Un experto en la materia reconocerá que las operaciones del método 3300 se pueden reorganizar, sustituir o modificar basándose en las operaciones de otros métodos descritos en el presente documento (por ejemplo, los métodos 1600 y 1700).
Se debería hacer notar que los términos relativos tienen por objeto ayudar en la comprensión de la tecnología y no tienen por objeto limitar el alcance de la invención. De manera similar, a menos que se exponga específicamente lo contrario, los términos usados para las etiquetas (por ejemplo, "primero", "segundo" y "tercero") tienen por objeto únicamente fines de designación y no de orden o limitación. El término "corto" en la expresión "corto alcance" (además de tener significados específicos de la tecnología) está relacionado con el término "largo" en la expresión "largo alcance".
Los términos "poder", "puede" y "podría" se usan para indicar alternativas y características opcionales y solo se deberían interpretar como una limitación si se incluyen específicamente en las reivindicaciones.
Se debería hacer notar que, a menos que se especifique lo contrario, el término "o" se usa en su forma no exclusiva (por ejemplo, "A o B" incluye A, B, A y B, o cualquier combinación de los mismos, pero este no tendría que incluir todas estas posibilidades). Se debería hacer notar que, a menos que se especifique lo contrario, "y/o" se usa de manera similar (por ejemplo, "A y/o B" incluye A, B, A y B, o cualquier combinación de los mismos, pero este no tendría que incluir todas estas posibilidades). Se debería hacer notar que, a menos que se especifique lo contrario, los términos "incluye" y "tiene" significan "comprende" (por ejemplo, un dispositivo que incluye, tiene o comprende A y B contiene A y B, pero opcionalmente puede contener C o más componentes aparte de A y B). Se debería hacer notar que, a menos que se especifique lo contrario, las formas singulares "un", "una", "el" y "la" se refieren a uno o más de uno, a menos que el contexto indique claramente lo contrario.
Debería entenderse que las invenciones, ejemplos e implementaciones descritas en el presente documento no se limitan a materiales, métodos y/o estructuras particularmente ejemplificados. Debería entenderse que las invenciones, ejemplos e implementaciones descritos en el presente documento deben considerarse invenciones, ejemplos e implementaciones preferidas, ya sea que se identifiquen o no específicamente como tales.
Claims (15)
1. Un método para determinar pulsos eléctricos para proporcionar a una pluralidad de máquinas no atendidas (1500) basado en opciones configuradas remotamente para la pluralidad de máquinas no atendidas, comprendiendo el método:
en una aplicación (140) que se ejecuta en un dispositivo móvil (150):
detectar, basándose en las respectivas radiodifusiones recibidas desde los respectivos dispositivos de provisión de pulsos (1520), cada uno de los cuales está acoplado a una respectiva máquina no atendida, la presencia de la pluralidad de máquinas no atendidas en proximidad al dispositivo móvil;
después de detectar la presencia de la pluralidad de máquinas no atendidas, recibir, desde un servidor (130): (i) información sobre un conjunto respectivo de opciones configuradas remotamente para cada máquina no atendida, y (ii) información cifrada que incluye una concesión de autorización respectiva, para interactuar con una máquina no atendida respectiva, en donde la información cifrada incluye especificaciones con respecto a los pulsos eléctricos a proporcionar a una máquina no atendida respectiva por un dispositivo proveedor de pulsos respectivo de acuerdo con una opción respectiva;
en respuesta a recibir la información sobre un primer conjunto de opciones configuradas remotamente y la información cifrada, mostrar, en la aplicación, los primeros objetos de interfaz de usuario que permiten la selección de las primeras opciones respectivas en un primer conjunto de opciones configuradas remotamente para una primera máquina no atendida;
detectar una selección de un primer objeto de interfaz de usuario que corresponde a una primera opción en el primer conjunto de opciones configuradas remotamente;
después de detectar la selección del primer objeto de interfaz de usuario, de acuerdo con una determinación de que se ha satisfecho una condición de desencadenamiento, enviar la información cifrada que incluye la concesión de autorización y las especificaciones de pulso al respectivo dispositivo proveedor de pulsos acoplado a la primera máquina no atendida; y
después de enviar la información que incluye la concesión de autorización y las especificaciones de pulso al respectivo dispositivo proveedor de pulsos, recibir una primera indicación, desde el respectivo dispositivo proveedor de pulsos, de que los pulsos eléctricos fueron proporcionados a la primera máquina no atendida de acuerdo con las especificaciones de pulso.
2. El método de la reivindicación 1, en donde las opciones configuradas remotamente son opciones de precios.
3. El método de la reivindicación 1, en donde las opciones configuradas remotamente son opciones de precios que se determinan de acuerdo con un programa de precios predefinido.
4. El método de la reivindicación 3, en donde el programa de precios predefinido se determina basándose en una hora actual del día en el servidor (130).
5. El método de la reivindicación 1, en donde las opciones configuradas remotamente son configuradas por un operador de la máquina no atendida (1500) sin requerir ninguna interacción física con la máquina no atendida.
6. El método de una cualquiera de las reivindicaciones 1-5, que comprende además:
recibir una segunda indicación del servidor (130) de que las opciones configuradas remotamente ya no están en vigor; y
en respuesta a recibir la segunda indicación del servidor, recibir un conjunto actualizado de opciones de precios configuradas remotamente que es distinto del primer conjunto de opciones de precios configuradas remotamente.
7. El método de una cualquiera de las reivindicaciones 1-6, en donde un transceptor de corto alcance del dispositivo móvil (150) recibe la radiodifusión desde el dispositivo proveedor de pulsos (1520).
8. El método de una cualquiera de las reivindicaciones 1-7, en donde un transceptor inalámbrico de largo alcance del dispositivo móvil (150) recibe la información sobre el primer conjunto de opciones configuradas remotamente para interactuar con la máquina no atendida desde el servidor remoto (130).
9. El método de una cualquiera de las reivindicaciones 1-8, en donde un transceptor inalámbrico de corto alcance del dispositivo móvil (150) transmite la información cifrada, que incluye la concesión de autorización y las especificaciones de pulso, al dispositivo proveedor de pulsos (1520).
10. El método de una cualquiera de las reivindicaciones 1-6, en donde un transceptor inalámbrico de corto alcance del dispositivo móvil (150) recibe la primera indicación y la radiodifusión desde el dispositivo proveedor de pulsos (1520).
11. El método de una cualquiera de las reivindicaciones 1-10, que comprende además:
mostrar, en la aplicación (140), una porción de una tarjeta específica de máquina para una segunda máquina no atendida, en donde la segunda máquina no atendida es distinta de la primera máquina no atendida.
12. El método de la reivindicación 11, en donde la porción de la tarjeta específica de máquina se muestra adyacente a los primeros objetos de interfaz de usuario.
13. El método de la reivindicación 11, que comprende además:
detectar un deslizamiento en dirección lateral sobre los primeros objetos de interfaz de usuario; y
en respuesta a detectar el deslizamiento, pasar a visualizar, en la aplicación (140), la tarjeta específica de máquina para la segunda máquina no atendida.
14. Un dispositivo móvil (150) que comprende:
uno o más procesadores y memoria que almacena uno o más programas para ser ejecutados por el uno o más procesadores, comprendiendo el uno o más programas instrucciones para realizar el método de una cualquiera de las reivindicaciones 1-13.
15. Un medio de almacenamiento no transitorio legible por ordenador que almacena uno o más programas, comprendiendo el uno o más programas instrucciones, que, cuando se ejecutan por un dispositivo móvil (150) con uno o más procesadores, hacen que el dispositivo móvil realice el método de una cualquiera de las reivindicaciones 1-13.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201662296543P | 2016-02-17 | 2016-02-17 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2961266T3 true ES2961266T3 (es) | 2024-03-11 |
Family
ID=58228566
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES20203134T Active ES2961266T3 (es) | 2016-02-17 | 2017-02-16 | Sistemas y métodos para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota |
| ES17708929T Active ES2858526T3 (es) | 2016-02-17 | 2017-02-16 | Sistemas y métodos para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES17708929T Active ES2858526T3 (es) | 2016-02-17 | 2017-02-16 | Sistemas y métodos para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota |
Country Status (4)
| Country | Link |
|---|---|
| EP (3) | EP3800607B1 (es) |
| JP (3) | JP6898339B2 (es) |
| ES (2) | ES2961266T3 (es) |
| WO (1) | WO2017143079A1 (es) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11074580B2 (en) | 2013-12-18 | 2021-07-27 | PayRange Inc. | Device and method for providing external access to multi-drop bus peripheral devices |
| US11966926B2 (en) | 2013-12-18 | 2024-04-23 | PayRange Inc. | Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel |
| US10019724B2 (en) | 2015-01-30 | 2018-07-10 | PayRange Inc. | Method and system for providing offers for automated retail machines via mobile devices |
| US11966895B2 (en) | 2013-12-18 | 2024-04-23 | PayRange Inc. | Refund centers for processing and dispensing vending machine refunds via an MDB router |
| US11205163B2 (en) | 2013-12-18 | 2021-12-21 | PayRange Inc. | Systems and methods for determining electric pulses to provide to an unattended machine based on remotely-configured options |
| US11983692B2 (en) | 2013-12-18 | 2024-05-14 | PayRange Inc. | Mobile payment module with dual function radio transmitter |
| US11475454B2 (en) | 2013-12-18 | 2022-10-18 | PayRange Inc. | Intermediary communications over non-persistent network connections |
| US11481781B2 (en) | 2013-12-18 | 2022-10-25 | PayRange Inc. | Processing interrupted transaction over non-persistent network connections |
| US8856045B1 (en) | 2013-12-18 | 2014-10-07 | PayRange Inc. | Mobile-device-to-machine payment systems |
| US9659296B2 (en) | 2013-12-18 | 2017-05-23 | PayRange Inc. | Method and system for presenting representations of payment accepting unit events |
| US11481780B2 (en) | 2013-12-18 | 2022-10-25 | PayRange Inc. | Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel |
| EP4185965A1 (en) * | 2020-07-21 | 2023-05-31 | PayRange Inc. | Device and method for providing external access to multi-drop bus peripheral devices |
| IT202200003401A1 (it) * | 2022-02-23 | 2023-08-23 | Alberici S P A | Dispositivo modulare di una macchina per pagamento automatico |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10000948A1 (de) * | 2000-01-12 | 2001-08-02 | Siemens Ag | Anordnung zur Bereitstellung und flexiblen Vergebührung einer Ware oder Dienstleistung sowie Ausgabeautomat zum Einsatz in einer solchen und Verfahren zum Betrieb einer solchen |
| US20030158891A1 (en) * | 2002-02-21 | 2003-08-21 | Warp 9 Inc. | Utilizing mobile devices as a communication proxy for non-connected terminals |
| JP2003323662A (ja) * | 2002-04-30 | 2003-11-14 | Akira Miyaoka | 割引情報サービスシステム、自動販売機、および方法 |
| KR20030089626A (ko) * | 2002-05-16 | 2003-11-22 | 여태순 | 자동판매기 관리 시스템 |
| JP2004185253A (ja) * | 2002-12-03 | 2004-07-02 | Mitsubishi Electric Corp | 電子コインシステム |
| JP2004246720A (ja) * | 2003-02-14 | 2004-09-02 | Fujitsu Ltd | 情報処理デバイス、情報処理方法及びプログラム |
| JP2005242698A (ja) * | 2004-02-26 | 2005-09-08 | Fuji Electric Retail Systems Co Ltd | 電子特典付与方法および電子特典付与システム |
| JP4709970B2 (ja) * | 2004-06-10 | 2011-06-29 | ネッツエスアイ東洋株式会社 | 自動販売機システム |
| JP4268575B2 (ja) * | 2004-08-16 | 2009-05-27 | 株式会社野村総合研究所 | 二次元コードを用いた認証システム |
| US20080154735A1 (en) * | 2006-12-26 | 2008-06-26 | Mark Carlson | Mobile vending purchasing |
| JP5267233B2 (ja) * | 2008-03-17 | 2013-08-21 | 富士電機株式会社 | 自動販売機の表示装置 |
| JP5420205B2 (ja) * | 2008-07-29 | 2014-02-19 | 株式会社インテージホールディングス | 自動販売機を使ったマーケティングシステム及びその方法並びに自動販売機 |
| KR101217323B1 (ko) * | 2008-09-30 | 2012-12-31 | 애플 인크. | 피어 대 피어 금융 트랜잭션 장치들 및 방법들 |
| US8600899B1 (en) * | 2011-10-11 | 2013-12-03 | Videx, Inc. | Vending data communications systems |
| US20140172179A1 (en) * | 2012-12-19 | 2014-06-19 | Shell Oil Company | System and method for dispensing fuel |
| EP3053151B1 (en) * | 2013-10-03 | 2022-01-12 | Vendwatch Telematics, LLC | Vending system |
| US20150170136A1 (en) * | 2013-12-18 | 2015-06-18 | PayRange Inc. | Method and System for Performing Mobile Device-To-Machine Payments |
| US9875473B2 (en) * | 2013-12-18 | 2018-01-23 | PayRange Inc. | Method and system for retrofitting an offline-payment operated machine to accept electronic payments |
| US20150235202A1 (en) * | 2014-02-20 | 2015-08-20 | Eazy Coin Corp. | Method and system for cashless transactions at vending machines |
| CN105139196A (zh) * | 2015-07-27 | 2015-12-09 | 深圳深若科技有限公司 | 红外支付终端、红外适配终端、红外支付系统及支付方法 |
-
2017
- 2017-02-16 ES ES20203134T patent/ES2961266T3/es active Active
- 2017-02-16 EP EP20203134.0A patent/EP3800607B1/en active Active
- 2017-02-16 WO PCT/US2017/018194 patent/WO2017143079A1/en active Application Filing
- 2017-02-16 EP EP23181648.9A patent/EP4250259A3/en active Pending
- 2017-02-16 EP EP17708929.9A patent/EP3417419B8/en active Active
- 2017-02-16 JP JP2018543707A patent/JP6898339B2/ja active Active
- 2017-02-16 ES ES17708929T patent/ES2858526T3/es active Active
-
2021
- 2021-06-10 JP JP2021097012A patent/JP7295164B2/ja active Active
-
2023
- 2023-06-08 JP JP2023094567A patent/JP2023111988A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP3800607A1 (en) | 2021-04-07 |
| JP7295164B2 (ja) | 2023-06-20 |
| EP4250259A3 (en) | 2023-12-27 |
| JP2019508813A (ja) | 2019-03-28 |
| EP3800607B1 (en) | 2023-08-02 |
| EP3417419A1 (en) | 2018-12-26 |
| WO2017143079A1 (en) | 2017-08-24 |
| JP2021152930A (ja) | 2021-09-30 |
| EP3417419B1 (en) | 2020-12-02 |
| ES2858526T3 (es) | 2021-09-30 |
| EP4250259A2 (en) | 2023-09-27 |
| JP2023111988A (ja) | 2023-08-10 |
| JP6898339B2 (ja) | 2021-07-07 |
| EP3417419B8 (en) | 2021-03-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11501296B2 (en) | Method and system for presenting representations of payment accepting unit events | |
| ES2961266T3 (es) | Sistemas y métodos para determinar pulsos eléctricos para proporcionar a una máquina no atendida basándose en opciones configuradas de forma remota | |
| US11983692B2 (en) | Mobile payment module with dual function radio transmitter | |
| US10891608B2 (en) | Method and system for an offline-payment operated machine to accept electronic payments | |
| US11966898B2 (en) | Systems and methods for determining electric pulses to provide to an unattended machine based on remotely-configured options | |
| EP3084699B1 (en) | Mobile device-to-machine payment systems | |
| US9134994B2 (en) | Method and system for updating firmware using a mobile device as a communications bridge | |
| US11074580B2 (en) | Device and method for providing external access to multi-drop bus peripheral devices | |
| US20150178702A1 (en) | Method and device for multi-drop bus payment peripheral expansion |