具有动态内核选择的销售点（POS）系统和方法与流程

具有动态内核选择的销售点（pos）系统和方法
相关申请的交叉引用
1.本技术要求于2018年12月21日提交的题为“具有动态内核选择的销售点(pos)系统和方法”的美国申请号16/230,823的优先权，通过引用将其合并于此。本技术还要求于2018年12月21日提交的题为“具有动态内核选择的销售点(pos)系统和方法”的美国申请号16/230,940的优先权，通过引用将其合并于此。本技术还要求于2018年12月21日提交的题为“具有动态内核选择的销售点(pos)系统和方法”的美国申请号 16/231,030的优先权，通过引用将其合并于此。


背景技术：

2.消费者可以通过多种方式与商家的支付读取器交互，以办理电子支付，例如，通过具有磁条的支付卡，其在支付读取器的磁性读取器中刷过，通过具有europay/mastercard/visa(emv)芯片的支付设备，其插入支付读取器的相应emv插槽，以及通过使能近场通信(nfc)的设备(诸如智能手机或emv卡)，其在支付读取器上轻触(tap)并通过安全无线连接传输支付信息。支付读取器可以从支付设备接收支付信息以及关于支付交易的信息，并且可以将这样的支付信息通信给支付系统以对交易进行处理和/或授权。能够帮助这样的交易的支付读取器可以采用多种形式，包括独立的移动设备。
3.移动支付读取器已经在市场上存在了几年。但是，随着与支付处理相关的功能在多样性和复杂性上的增加，也就是说，随着消费者的支付选项的增长，对支付读取器的处理要求可能会过大而不适于已经在市场上的现有硬件的能力。在某些情况下，商家使用的早期(或更早)一代的支付读取器的硬件可能无法满足更现代的支付交易的处理要求。在其他情况下，商家使用的支付读取器可能无法处理现代支付交易，因为该读取器缺少足够的电力资源或所需的软件未进行更新。在其他情况下，商家使用的支付读取器可能物理上有能力处理支付交易，但由于环境或安全条件，可能无法或不愿意在在由消费者要求的特定时间或特定条件下进行处理。
4.因此，通常需要这样的解决方案，其更优化地利用支付读取器上的处理资源和/或电力资源，防止通过过时、效率较低或不期望的软件版本进行处理，另外在支付处理期间增强数据安全性。
附图说明
5.在结合附图考虑以下详细描述时，本公开的以上和其他特征、其本质和各种优点将变得更加显而易见。
6.图1描绘了根据本公开的一些实施例的支付系统的框图。
7.图2a和图2b描绘了根据本公开的一些实施例的支付读取器的框图。
8.图3a、图3b、图3c和图3d描绘了根据本公开的一些实施例的各种支付服务系统的框图。
9.图4描绘了示出根据本公开的一些实施例的用于支付处理的示例性步骤的流程
图。
10.图5a和图5b描绘了根据本公开的一些实施例的支付服务系统的框图。
具体实施方式
11.通过从支付接口获取支付信息、将获取的支付信息加密和/或根据支付处理协议执行支付处理以与支付服务器交换信息，可以使用支付读取器来处理支付信息。支付读取器可以具有一个或多个处理器，该处理器包括专用内核，其用于支付处理、提供与支付读取器的各个抽象层有关的各种功能。例如，与第一(物理)层的功能有关的模块可以控制与能够从支付卡接收信息的设备(诸如nfc接口)的交互。与第二(应用)层的功能有关的内核可以解决其他任务，诸如，例如，处理支付交易、在终端的安全支付飞地(enclave)内加密和/或向支付服务器传输支付信息以获得批准等。通常，物理层在本文中被称为“第一层”或“l1”。虽然在osi模型的上下文中，通常将应用层称为“层7”或“l7”，但在本文中，应用层组件也可以称为“第二层”或“l2”组件，以易于与术语“l1”进行比较。在这方面，将理解的是，在不同的实施例中，l1和l2可以指与物理层和应用层不同的osi层，并且本文描述的系统和方法的概念可以类似地应用于其。
12.支付读取器可能包含一个或多个处理单元，其可以提供不同的处理能力。例如，支付读取器的较旧模型可能已设计为与第一代内核一起工作，第一代内核取决于第一有限组的硬件资源，而支付读取器的较新模型可能已设计为具有第二代内核，第二代内核提供了超越第一代内核的一系列功能的一系列功能，但与第一代相比，它需要更大量的内存和硬件资源。为了便于参考，提供第一有限组的处理功能的内核在本文中称为“1代”或“gen 1”内核，而提供第二更健壮组的处理功能的内核在本文中称为“2 代”或“gen 2”内核。
13.在一个实施例中，商家可能拥有具有gen 1内核的支付读取器，该 gen 1内核无法执行gen 2处理器特有的功能或处置gen 2处理器特有的信息(即“gen 2功能”)。在优选实施例中，支付读取器包含内核控制器(也称为“内核引导器”)，该内核控制器识别到支付读取器可能不具有执行gen 2功能所需的硬件或软件资源。响应于该识别，内核引导器改为控制支付读取器以将该功能的执行分配给具有必需的gen 2内核和资源的外部设备(诸如移动设备(例如，移动电话或平板电脑)或远程服务器)。在一个优选实施例中，内核控制器可以位于处理器中，但是，它可以可替代地在支付读取器中实现为单独的电路(或实现为硬件和软件的任何组合)。在又一个实施例中，可以在单独的设备上实现内核控制器，以控制支付读取器上的功能。
14.在另一个实施例中，支付读取器可以具有gen 2内核，但是仍然可以决定将gen 2功能的处理引导到外部设备的内核，因为支付读取器在其他方面是资源限制的，例如，由于在读取器上节省电力的需要。在另一替代实施例中，支付读取器可以具有gen 2内核，但是可以将gen 2功能的处理引导到版本与读取器上的gen 2内核版本不同的外部设备的gen 2内核，例如，在下述情况下，其中特定gen 2功能被更有效地或更好地在该版本不同的软件上执行。在又一个实施例中，支付读取器可以具有gen 2 内核，但是可以将gen 2功能的处理引导到外部设备的内核，因为支付读取器已经识别到对读取器的安全威胁(例如，篡改尝试)。为便于参考，由非支付读取器本地的内核进行的处理(无论进行该处理的设备的位置和/或该设备是否在物理上连接到支付读取器)可以在本文中称为“在云中”的处理。
15.在另一实施例中，不是将gen 2功能的处理卸载到外部设备，而是在由支付读取器或充当嵌入式读卡器(ecr)的设备的单独的处理器管理的隔离的安全区域(诸如“信任区域”)中执行该处理。
16.在另一个实施例中，内核本质上可以是模块化的，其中可以将在应用层上的不同的gen 1和/或gen 2功能分离为内核的不同的逻辑上“子模块”。在该实施例中，可以基于支付读取器的硬件资源和其他约束，在不同的各个设备处执行不同的内核功能。
17.图1描绘了根据本公开的实施例的支付系统1的说明性框图。如所图示的，支付系统1包括支付设备10、支付读取器20、网络30、移动设备 (诸如移动电话或ipad)或替代的计算设备(诸如移动设备或pc)40以及支付服务器50。在示例性实施例中，支付服务器50可以包括由不同实体操作的多个服务器，诸如支付服务系统或银行服务器。支付系统1的组件帮助商家和顾客之间的电子支付交易。
18.商家和顾客之间的电子交互发生在顾客的支付设备10和商家的支付读取器20之间。在优选实施例中，支付读取器20可以是独立的移动硬件设备，尽管不限于此。例如，在其他实施例中，支付读取器20可以是移动设备，诸如智能电话(ios或android)或被配置为充当嵌入式读卡器(ecr) 的另一计算设备。在一个实施例中，支付设备10可以是能够与支付读取器 20通信的设备，诸如具有磁条的信用卡、具有emv芯片的信用卡或使能 nfc的电子设备(诸如运行支付应用程序的智能电话)。芯片卡可以包括安全集成电路，该安全集成电路能够与支付读取器20通信、产生加密的支付信息，并根据一个或多个电子支付标准(诸如那些由emvco发布的电子支付标准)提供该加密的支付信息以及其他支付或交易信息。支付读取器20能够执行支付应用程序(在一些实施例中其可以是销售点应用程序或提供其功能的一部分的应用程序)，并且包括至少一个用于从支付设备10接收支付信息的接口。支付读取器20能够通过与卡或非接触式接口的接触来接收和处理支付信息，并且能够收集支付信息，该支付信息包括交易信息 (例如，购买金额和购买点信息)和卡信息(例如，加密的支付卡数据和用户认证数据)。
19.在一些实施例中，商家还可以具有一个或多个移动设备(或固定的计算设备)40。在一些实施例中，这些设备可以提供附加功能，以便与支付读取器的应用程序相对应地创建、完成、补充或增强由商家实现的综合性销售点系统。在一些实施例中，一个或多个移动设备40可以提供与在支付读取器20上执行的支付应用程序完全分开的pos应用程序。设备40可以是，例如，诸如iphone或android设备的移动电话、ipad或平板电脑设备、笔记本电脑或触摸屏设备，或pc或固定的计算设备，尽管能与支付读取器通信的任何实用设备可能是适当的。
20.支付读取器20，和/或，任何商家设备40(在一些实施例中)，可以通过通信网络30与支付服务器50通信。尽管通信网络30可以是任何合适的通信网络，但是在一个实施例中，通信网络30可以是因特网，并且可以在支付读取器20和支付服务器50之间以诸如通过传输层安全性(tls) 或安全套接层(ssl)协议的加密格式通信支付和交易信息。此外，当网络 30是因特网时，支付读取器20可以使用传输控制协议/因特网协议(tcp/ip) 用于通信。
21.尽管支付服务器50可以由单个实体操作，但是在一个实施例中，支付服务器50可以包括由任何适当的实体操作的任何适当数量的服务器，诸如商家和顾客的支付服务系统以及一个或多个银行(例如，银行服务器) 或卡发行方。支付读取器20和支付服务器50通信
支付和交易信息，以确定交易是否被授权。例如，支付读取器20可以通过网络30向支付服务器 50提供加密的支付数据、用户认证数据、购买金额信息和购买点信息。支付服务器50可以基于该接收到的信息以及与顾客或商家账户有关的信息来确定交易是否被授权，并且通过网络30响应支付读取器20以指示该支付交易是否被授权。支付服务器50还可以将诸如交易标识符之类的附加信息传输到支付读取器20。
22.基于在支付读取器20处从支付服务器50接收到的信息，商家可以向顾客指示交易是否已经被批准。在诸如芯片卡支付设备的一些实施例中，可以在支付读取器20处(例如在支付读取器20的屏幕上)指示批准。在诸如作为nfc支付设备操作的移动电话或智能设备的其他实施例中，可以向nfc支付设备提供有关被批准的交易的信息和附加信息(例如，收据、特价、优惠券或忠诚计划信息)，以显示在智能手机或手表的屏幕上或存储在存储器中。
23.如前所述，支付读取器20可以单独地或与设备40一起地具有支付应用程序，该支付应用程序可以提供购买和支付信息的录入、与顾客的交互以及与支付服务器50的通信。例如，支付应用程序可以提供商家能够选择的服务的菜单以及用于使交易自动化的一系列菜单或屏幕。支付应用程序还可以帮助录入顾客身认证信息，诸如签名、pin码或生物信息。
24.图2a示出了根据一个实施例的示例性支付读取器20的组件的示例性示意图。该设备可以包括多核处理器205或等同物。在一些实施例中，支付读取器20可以具有另一种类型的合适的处理器，并且可以包括执行和控制支付读取器20的功能所必需的硬件、软件、存储器和电路(或其任何组合)。在一些实施例中，支付读取器20可以具有多个独立的处理单元，例如多核处理器或其他类似的组件。在一优选实施例中，处理器可以具有一个或多个专用内核，用于执行与支付处理有关的不同功能。
25.处理器可以执行存储在存储器209中的指令以控制支付读取器20的操作。如本文中所使用的，存储器可以指任何合适的易失性和非易失性的存储介质，诸如磁盘、拇指驱动器等。此类介质的示例包括ram、rom、 eprom、eeprom、sram、闪存、磁盘或光存储器、磁存储器或任何其他有形或非暂时性的存储可由处理器访问的信息的介质。
26.读取器可以包括通信接口213，其可以包括一个或多个无线通信接口和/或有线通信接口。读取器20还可包括电池207。作为电池的替代物，可以使用一个或多个电源，诸如到交流电源或直流电源的物理连接(包括电源转换电路)。电池207可以通过物理电源连接、通过感应充电或通过任何其他合适的方法来充电。尽管未描绘为在物理上连接到支付读取器的除了处理器(以下描述)之外的组件，但是电池可以根据那些组件的要求向支付读取器20的组件供应各种电压。
27.多个支付接口可以连接到处理器205上的相应端口或终端。处理器 205从磁条读取器(msr)232接收输入，该输入由磁头读取器230读取。在一些实施例中，msr设备230、232可以包括插槽，其引导顾客滑动或浸入卡的磁条以收集支付信息。然后可以将接收到的支付信息提供给处理器 205用于处理。还从emv触点240(芯片卡)接收输入，并由emv触点块242处理该输入。芯片卡可具有触点，该触点与对应的触点接合并在物理上与之接合，以接触emv接口240的引脚。emv接口240根据emv规范为芯片卡的emv芯片提供电力和通信。该数据可以由emv触点应用块 242处理并提供给处理器205。
28.来自非接触式接口的输入是从nfc非接触式天线250接收的并且由 nfc非接触式应用块252处理。非接触式天线250配置为接收来自emv 卡20和nfc(近场通信)卡以及其他
nfc设备(诸如智能电话或其他设备)的输入。在一个实施例中，天线250可以包括用于nfc通信的电路，诸如电磁兼容(emc)电路、匹配电路、调制电路和测量电路。基于由处理器205提供的信号，天线250可能输出载波信号或调制信号。载波信号可以是具有固定频率(诸如13.56mhz)的信号。根据诸如iso 14443和 iso 18092的调制过程，调制信号可以是载波信号的调制版本。当支付读取器20被感应地耦合到非接触式支付设备10时，非接触式支付设备10可以经由主动或被动负载调制来调制载波信号。通过改变支付设备10的天线的调谐特性，在支付设备10和支付读取器20两者处修改无线载波信号，从而导致经调制的无线载波信号。以这种方式，支付设备10能够将经调制的数据发送到支付读取器20，该数据可以由天线250感测到并被提供给处理器205用于处理。在优选实施例中，上述接触式和非接触式接口可以被组合到能够提供所有上述功能的单个支付设备中。
29.图2b示出了类似于图2a的实施例的实施例，其中，存在额外的组件，安全处理器260及存储器265，其与处理器205及存储器209分开，位于读取器的安全区域或安全飞地270中。安全区域可以包括与非安全区域在物理上和在逻辑上隔离的硬件(例如，处理单元、存储器)、固件和/或软件(例如，应用程序)。安全区域可以用于接收、处置和/或存储进入支付读取器的安全数据，并且用于执行取决于这种安全数据和组件的功能，诸如加密。
30.将理解的是，以上描述的以及在图2a和图2b中示出的架构不限于本文讨论的组件，并且可以包括其他硬件和软件组件。相反，为了便于说明，本文仅讨论与本发明最相关的组件和功能。
31.图3a示出了一种架构，其中专用于支付处理功能的各种内核位于支付系统中的相应的设备中。包括支付读取器20的商家系统300被图示为被分成包含模块的物理层(l1)和具有一个或多个第一代(gen 1)内核的应用层(l2)，每个内核专用于不同的支付功能。在优选实施例中，l1模块 302可以包括硬件组件，该硬件组件控制与接口(诸如nfc接口)的交互，该接口能够从支付卡接收信息并将该信息转移到支付读取器的其他组件。在一些实施例中，l1模块可能能够执行与从支付卡接收的信息有关的其他物理层功能(例如，纠错)。在图3a的实施例中，示出了多个l2 gen 1内核304、306。在该实施例中，多个gen 1内核中的每一个可以例如对应于用于非接触式支付处理的交易的基本类型。就这一点而言，多个gen 1l2 内核中的每一个可以专用于例如万事达卡(mc)、visa、jcb、cup和其他交易类型中的相应的一个。
32.在图3a的实施例中，支付读取器20具有受限的硬件资源。例如，支付读取器20可能具有较旧的或过时的芯片技术，该技术不能提供处理能力以执行某些支付处理功能。gen 1内核力所不及的这些额外的功能在本文中可以称为“gen 2功能”，即，具有超出gen 1内核的能力的但在gen2内核的能力内的处理器要求的功能(诸如，从礼品卡、忠诚卡或其他非标准emv支付设备收集支付信息，等等)。在应用层上，l2 gen 2内核可以提供gen 1内核无法访问的各种功能，诸如加密。为了说明，椭圆曲线加密(ecc)(适用于例如加密、密钥协商、数字签名和其他任务)的安全性取决于设备以相对快的速度执行密集计算的能力。在过时的硬件的限制内，此类计算繁重的任务可能无法实现，即使此类硬件在其他方面仍可正常工作。替代地或附加地，l2内核上可用的特征集可能比l1模块的特征集更大(或与之不同)，与gen 1相比，gen 2内核上可用的特征集还更大。因此，过时的设备上可能存在内存限制，这进一步限制或禁止了处理密集型任务。
33.图3a示出了支付读取器20外部的能处理gen 2交易的几个设备。在所图示的示例中，每个移动设备40a(其可以包括例如移动电话(诸如 iphone或android)、ipad或其他平板电脑、笔记本电脑或触摸屏计算机或任何其他合适的设备)、计算设备40b(其例如可以是个人计算机)和远程服务器310具有gen 2l2内核。将理解的是，给定商家系统和支付系统的特定架构，可以使用任何数量的外部设备。移动设备40a和计算设备40b 都被图示为商家系统(商家设备300)的一部分，也就是说，控制支付读取器20的商家也控制着移动设备40a和/或计算设备40b，尽管它们不限于此。因此，在该实施例中，虽然设备40a和40b在支付读取器20的外部，但是它们不一定位于遥远的地理位置。
34.支付读取器20还可以包括支付应用程序或支付软件301。在一些实施例中，支付应用程序301可以包括组成全部或部分的销售点(pos)应用程序(或与之相关的支付功能)的特征。当由处理器205执行时，在一些实施例中，支付应用程序301可以提供带有交互界面的显示，该交互界面允许商家处理与顾客的支付交易。这些指令可以包括定制的界面，该界面允许商家或顾客选择用于购买的产品、计算营业税、处理小费、提供收据、产生折扣或特价、处理顾客忠诚计划、搜索库存中的物品或用于交货的物品，和/或执行任何其他合适的零售操作。此外，在交易处理中的恰当时间处，支付应用程序301可以向一个或多个支付接口发送消息以允许支付读取器20从支付设备10接收支付信息。在替代实施例中，可以从支付读取器20外部的设备(诸如移动设备40a(智能电话)或任何其他实际实施方式来执行支付应用程序301。例如，在读取器20上的硬件资源受到限制的情况下，这样的实施方式可能是优选的。在又一个实施例中，支付应用程序301的一些元素可以在读取器20上运行(例如，用户输入的能力)，而其他元素可以从不同的设备执行。
35.图3a还示出了支付处理服务器50，该支付处理服务器50是能够授权支付的远程服务器。支付服务器50可以包括由不同实体操作的多个服务器，诸如支付服务系统或银行服务器。移动设备40a、计算设备40b、远程服务器310和支付读取器20中的每一个都能多方面地与支付处理服务器 50通信。
36.在第一实施例中，支付读取器包含内核控制器305，该内核控制器305 动态地选择或确定专用内核，特定的交易数据应被引导到该专用内核用于处理。可以以硬件和/或软件或其任何组合来实现内核控制器305。在所图示的实施例中，内核控制器305被示为单独的组件，但是，在另一个示例中，内核控制器可以是支付应用程序301的一部分。在又一个示例中，内核控制器的功能可以另外地由处理器205的一个或多个组件来执行。
37.在图3a所示的实施例中，l1模块302控制与支付接口232、242、 252的交互以从支付卡20接收支付信息。支付读取器20的内核控制器305 确定对支付交易的处理需要可以由gen 2内核实现但可以不由l2 gen 1 内核304和306中的任何一个实现的功能。因为已经确定读取器不具有硬件资源以执行所需的gen 2功能，所以内核控制器305反而是控制将该功能的执行分配给读取器外部的gen 2内核，诸如移动设备40a、pc 40b或远程服务器310的gen 2内核(无论进行处理的设备是否在商家系统300 的外部)，它们中的任何一个都可以具有必需的gen 2内核和足够的硬件资源。
38.在替代实施例中，在顾客的移动支付设备10中的非接触式程序软件 (例如，nfc软件)可能自身发起对支付读取器20中的内核或模块的呼叫。例如，使用nfc天线，在支付设备10中的nfc软件可以呼叫l1模块302、呼叫应用层内核304或306或呼叫内核控制器305，内核
控制器 305可以确定使用哪个内核，并且可以引导nfc软件呼叫该选定的内核。
39.不同内核功能在本地的分布以及到云中资源的分布可以视为内核的“混合”分布或分配。例如，在图3a所图示的混合实施方式中，处理支付所需的gen 1功能在支付读取器20处(即，在本地)执行，而处理支付所需的gen 2功能由远离读取器20的gen 2内核(即，在云中)执行。例如，在一个实施例中，可以由移动电话或ipad设备上的gen 2内核来执行 gen 2功能。在非混合架构中，gen 1和gen 2内核两者都将位于支付读取器20上，或者两者都位于读取器20外部的单个位置(例如，移动设备、计算设备或远程服务器)处。
40.图3b图示出了替代实施例，其中支付读取器20可以在应用层上包含gen 1内核304和gen 2内核354，并且在物理层上包含l1模块。在支付读取器具有gen 2内核的情况下，无论使用哪种交易类型(例如，mc、 visa等)，只需要一个l2 gen 2内核用于非接触式支付。在另一个实施例 (未具体图示出)中，第二l2 gen 2内核专用于处理基于接触的支付(例如，刷卡或芯片支付)。在这样的实施例中，其中支付读取器具有能力以执行gen 2功能，读取器20仍然可以选择将gen 2处理卸载到具有相同的 (或相似的)gen 2处理器的设备。换句话说，系统选择性地在位于不同安装点的gen 2内核的复制的副本中做选择。该选择可能由多种因素的激发，而不仅限于硬件资源上的限制。
41.在一个实施例中，决定卸载gen 2功能的处理可以基于以下确定：支付读取器尽管具有足够的处理器带宽，但是在其他方面是资源限制的。例如，由于例如电池电量低或由诸如卡读取、计算和通信之类的其他任务造成的过度的电力消耗，支付读取器可能需要节省电力。在一个实施例中，可以由内核控制器305基于对支付读取器的电力水平的确定来做出确定以将处理移动至云，否则可以将处理引导至读取器20本地的gen 1或gen2内核。在优选实施例中，内核控制器可以包括可以连接至处理器205的电力测量电路或传感器(未具体示出)，该传感器能够对电池207的电力水平进行动态测量。替代地，对电池电量进行测量的电路可以与内核控制器分隔开并且可以与内核控制器通信。作为一个示例，内核控制器可以通过这些手段之一来测量由电池107供应的读取器的当前电力水平。如果该当前电力水平落在预定的最小阈值以下，则内核控制器可以忽略本地内核，而是将功能的处理引导到安装在移动设备40a(或任何其他适当的外部设备) 上的gen 2内核。通过这些手段，低电力设备可以节省能量，并且不必基于有限的电力资源而担心无法处理。在一些实施例中，针对其而测量电池电量的预定阈值可以是存储在存储器209中的值，而在其他实施例中，预定阈值可以是读取器的总电池容量的百分比值。仍在其他实施例中，一个或多个阈值可以与条件事件(诸如，读取器的机械或环境条件)或计划事件(其可能影响电力消耗)相关联地存储在存储器209中的参考表或其他数据结构中。在一个这样的示例中，内核控制器305可以确定读取器被计划为执行需要高电力消耗的任务，并且可以参考该参考表以确定与计划事件相关联的阈值电力值。然后将电池207的当前电力水平与该阈值进行比较，以确定是否可以执行支付处理，同时仍然保持用于计划任务的电力。在又一个实施例中，存储器209中的表可以将阈值与特定的历史或预测电力使用条件(诸如观察到的或预测的电力消耗模式)相关联。在示例性实施例中，内核控制器可以对电力水平进行几次迭代测量，并且可以观察电力消耗的模式(例如，随着时间的流失率)。然后，内核控制器可以参考存储器209中的表，以确定特定的阈值是否与这样的模式相关联(例如，这样的阈值高于最小阈值，以解释以后的电力中的下降)。如果当前电力水平低于该阈值，则内核控制器将gen 2信息的处理引导到
外部设备上的内核。通常，应当理解，将当前电力水平与其进行比较的阈值可以是可以将电池电量与其进行比较的任何可测量的值。
42.替代地，对从读取器卸载处理的确定可以基于对支付读取器与目标 gen 2内核位于其上的设备之间的电力水平的比较(例如，相对的电池电力)，或者基于对电力消耗和/或约束的任何其他测量。在一个这样的示例中，内核控制器305可以测量读取器20的当前电力水平和移动设备40a的当前电力水平。然后可以将这两个值都与预定的阈值进行比较(与相同的阈值进行比较或与两个相应的阈值进行比较)。在测量到的读取器的电力水平值下降到阈值以下并且测量到的移动设备40a的电力水平在其阈值之上的情况下，内核控制器然后可以(如上所述)绕过在读取器本地内核上的处理，并且反而是将处理引导到安装在移动设备40a上的gen 2内核。在另一示例中，计算支付读取器和移动设备40a之间的电力水平的差，并且在移动设备的电力水平比支付读取器的电力水平高预定的差的情况下(即，移动设备设备具有电力出让)，即使在读取器的特定电力水平本身未必下降到低于低电力阈值的情况下，处理也可以被引导到安装在移动设备40a上的gen 2内核。
43.在替代实施例中，内核控制器305可以动态地确定将功能的处理路由到外部设备上的gen 2内核，其中安装在支付读取器上的gen 2内核可能不是执行特定的gen 2功能的理想的版本。即，位于读取器20上的gen2内核和外部设备40a、40b、310上的gen 2内核不是复制的副本，而是，可以使内核的各个副本相对于彼此被不同版本化(以版本的任何排列)。因此，基于对支付读取器的内核软件的版本与在目标云设备上内核软件的版本的比较，内核控制器可以确定将处理引导到最合适的(例如，最有效或在其他方面优选的)内核的版本。
44.在又一个实施例中，由于对读取器的公认的安全威胁，内核控制器 305可以选择卸载处理。作为一个示例，读取器20(或外部安全监视电路 (或软件)或人类参与者)可以识别到该读取器已被篡改，诸如通过添加能够读取卡数据的未授权的第三方硬件组件或通过更改、操控或损坏读取器20的任何组件。在优选实施例中，内核控制器可以动态地参考篡改检测电路(未具体示出)或其他传感器，以确定是否进行了篡改尝试。在其他实施例中，内核控制器本身可以包含这样的电路，或者这样的电路可以被容纳在外部设备上。在一个实施例中，篡改检测电路可以能够测量读取器20 的电阻或电容值。将理解，可以基于读取器的任何组件部分的电荷、读取器的特定(例如，安全)部分的电荷、总计的读取器的电荷或任何其他适当的测量值来测量电容值。然后，可以将电容测量值与已知电容值进行比较，并且如果两个值之间的差超过特定量，则内核控制器可以确定进行了篡改尝试。在另一个示例中，可以通过下述来检测篡改尝试：对读取器20的组件扫描以确定存储在存储器209中的数据中是否存在任何差异，其中存在意外或未知的应用程序，或者在安全和非安全区域内组件的在物理和逻辑上的分隔中是否存在差异，等等。通过将处理从读取器上的本地内核重新路由到云，系统在某些情况下可以规避读取器的被危害的组件。
45.图3c图示出了替代实施例，其中支付读取器20可以包含gen 1或 gen 2l2内核，该内核本质上是模块化的；也就是说，可以将在物理层和 /或应用层上的不同的gen 1和/或gen 2功能分隔成l2内核的不同的逻辑上的“子模块”。换句话说，不是将l2内核的整体作为无法分割的统一或整体组件来处置，而是可以将其功能分解为某些组件部分。在该实施例中，可以基于支付读取器的硬件(或其他)资源在不同的相应的设备处执行不同的l2内核功
能。在示例性实施例中，读取器20的l2内核的子模块 1和2可以在读取器上或在云中的设备上以各种方式实现。图3c描绘了具有l2内核子模块1(l2内核的第一子模块)340的移动支付读取器20。l2 内核子模块2(同一l2内核的第二子模块)342、344或346可以被容纳在外部设备上，诸如移动设备40a、pc 40b或远程服务器310中的任何一个。子模块340和子模块342、344、346可以被引导到l2内核的不同功能。例如，在各种实施例中，子模块340、342、344和/或346中的任何一个或多个可以以各种方式作用以执行支付读取器的功能，诸如以下项：选择管理器(例如内核控制器，其将数据引导用于支付读取器的不同元素的处理)、个人识别号码(pin)处置、主要内核功能(例如核心交易)、密码处理程序、支付授权/批准/拒绝/推荐、处理额外的支付服务、处理使用持卡人信息的非支付服务、配置管理器(例如，特定于国家、品牌、支付交易类型等的处置配置)、风险处置、交互点(例如，持卡人/商家显示或通过ui、小键盘或外围设备的数据录入)、收据处置、邻近协议、处置未授权的交易、超时或取消、安全通道管理以及不同模块或设备之间的通信以及其他功能。将理解的是，这些仅仅是功能的一般类别，其在某些情况下可以在一个或多个子模块中实现，并且不旨在作为穷举列表，或者不作为功能与离散子模块之间的严格的一对一的对应。作为一个图示出的示例，其中在读取器20上的l2内核包括与非接触式支付处理有关的子模块和被引导到处置pin/签名/生物数据的子模块，这些子模块之一可以在读取器20上执行，并且一个子模块可以在移动设备40a上执行。尽管上述功能要么可以在读取器本身上执行，要么可以从外部设备上执行，但是与通信抽象层相关的功能(即，处理支付读取器的l1层与osi层的其余层之间的通信)或与基于接触的支付卡的某些低级对话通常必须位于支付读取器本身中，因为将这样的功能移动至其他位置将不切实际或效率低下的。
46.通过分布这些子模块的位置，可以在执行中优化各种功能的处理。在示例性场景中，可以将设计为处理高度敏感信息的特定的子模块卸载到具有额外的安全特征的基于云的设备。在另一示例性情形中，可以在计算资源要不然将不允许在读取器上并行地进行处理的场合，从基于云的设备处理一个或多个子模块，从而以更及时的方式完成处理。在另一示例性场景中，子模块所需的信息可以存储在云中(即，在远离读取器20和/或被限制远离其的位置)，并且可以将处理委托给位于下述设备上的内核子模块，从该设备可以更有效地访问所需的数据。
47.图3d图示出了替代实施例，其中l1模块已被划分为子模块，l1模块的子模块代表以下项中一个或多个：支付卡或使能nfc的设备与其接口接合的元素的机械特征、施加到支付卡或使能nfc的设备的以及从其接收的信号的电气特征，以及操作完整的l1模块所需的其他特征。在一些实施例中，l1模块的所有子模块可以在支付读取器本身上，如图3d中所示的 l1子模块1c(元素370)和2c(元素372)一样，其被容纳在支付读取器 20上。替代地，如图3d所示，可以在支付读取器20的物理层和应用层之间划分l1子模块，其中子模块1a(元素350)在读取器的l1层中，而子模块2a(元素352)在读取器的应用层中。在又一替代实施例中，子模块 1b(元素360)可以位于支付读取器上，而子模块2b(元素356、357或358) 可以位于外部设备(诸如，移动设备40a，pc 40b或远程服务器310)上。注意，子模块2b是支付读取器20的l1层的子模块，而不是子模块位于其上的外部设备的l1层的子模块，因此，在所图示的实施例中，将在外部设备的应用层上处理l1子模块2b。在其他实施例中，l1子模块可以被不同地分布。
48.将理解的是，被引导到读取器的机械特(例如，卡触点、电线、用于处理信号的有源和/或无源电路等)的l1子模块实际上可以仅实现在读取器自身上，因为那些功能通常以物理方式嵌入读取器中。然而，可以替代地布置被引导到其他特征的l1子模块，以使其位于读取器上或位于读取器外部的设备上。例如，下面的表1列出了可以在这样的实施例中实现的子模块的一些分布。表1
49.作为示例，在一些实施方式中，仅软件模块/特征被布置为读取器内软件或布置在诸如移动电话的外部设备上(分别为l1子模块2a或2b)。在这些实施方式中，在读取器上或在外部设备上执行的离散的软件组件驱动电气和机械组件/特征，其例如调节电压或测试卡触点(l1子模块1a和 1b)。作为另一个示例，表1的第4行引用了一种实施方式，其中电气和软件子模块都被布置在移动电话上(例如l1子模块2b 356、357或358)或布置在读取器的应用层中(l1子模块2a)。在该替代实施方式中，在外部设备的内核上执行的软件组件可以驱动读取器20的电气性能(例如，通过音频/闪电插孔等)，例如以调节电压或将铜线驱动至支付读取器20上的 emv接触盘或nfc线圈(天线)(例如，在l1子模块1a或1b中)。作为一个示例，移动设备40a、pc 40b或远程服务器310之一上的软件无线电 (software defined radio)应用程序或等同物(l1子模块2b)用于控制保持在支付读取器20上的nfc线圈(l1子模块1b)。类似地，可以使用支付读取器的应用层中的软件(l1子模块2a)来控制物理层中的机械组件 (l1子模块1a)。
50.将理解的是，上面描述的并且在图3a
‑
图3d中图示出的架构不限于本文讨论的组件，并且可以包括其他硬件和软件组件。相反，为了便于说明，本文仅讨论与本发明最相关的组件和功能。
51.图4图示出了根据一个实施例的在读取器20与移动设备40a的组件之间的数据流的示例图。在图4的示例中，沿着图3b所示的示例的线的架构可以用作示例性模型。该流程
开始于步骤402，其中读取器20的l1模块例如在nfc交易中通过非接触式天线250读取卡数据。在步骤404中，将卡数据传输到处理器205(或适当时传输到安全处理器260)。在步骤406，内核控制器305确定哪个内核应处理支付交易。
52.在第一场景下，交易的处理需求和支付信息被限制到gen 1应用层内核的特征。在该第一场景下，内核控制器在步骤408中将处理引导到支付读取器20本地的l2 gen1内核304。该处理可以涉及各种步骤，包括例如认证数据(诸如签名、pin或生物特征数据)的录入。在处理之后，内核 304经由通信接口213将经处理的支付信息发送到支付处理服务器50(例如发行方服务器)，以用于认证。在替代实施例中，其中读取器可能不具有用于与支付处理服务器通信的存储器或处理能力，可以经由通信接口213 将经处理的支付数据发送到移动设备40a或计算设备40b，该设备转而将数据转发给支付处理服务器50。
53.在第二场景下，交易的处理需求只能由gen 2应用层内核来满足，并且支付读取器20具有gen 2内核并且具有可用资源来处理交易。在这种场景下，内核控制器305在步骤408中将处理引导到支付读取器20本地的l2 gen 2内核354。该处理可以涉及各种步骤，包括例如基于非标准支付(像通过智能手机上的应用程序进行的支付)形式的礼品卡的交易和/或卡和支付数据的加密。该处理还可以涉及例如认证数据的录入。在处理之后，内核354在步骤410中经由通信接口213将经处理的支付信息发送到支付处理服务器50，或者替代地，发送到移动设备40a或计算设备40b，移动设备40a或计算设备40b转而将数据转发给支付处理服务器50。
54.在第三场景下，交易的处理需求只能通过gen 2应用层内核来满足，但是，支付读取器20没有gen 2内核和/或没有可用的资源来处理交易。在这种场景下，内核控制器305在步骤406中通过经由通信接口213发送支付数据，将处理分别引导到远程服务器310、移动设备40a或计算设备 40b(其每一个都在读取器外部)上的l2 gen 2内核312、322或332中的任何一个。然后，所选择的外部设备上的内核处理该交易。该处理可以涉及各种步骤，包括例如基于非标准支付(例如，通过智能手机上的应用程序的支付)形式的礼品卡的交易和/或卡和交易数据的加密。该处理还可能需要例如认证数据的录入，并且在这种情况下，内核312、322、332在步骤452中处理交易之前，在步骤450中接收这样的数据。在处理之后，在步骤454中，外部设备将数据传输(这还可以包括pin、签名或生物特征数据等其他数据的传输)到支付处理服务器50。
55.通过上述方法和系统，即使支付读取器在硬件资源上、在内存上、在电力上受限，或者其处理支付交易的能力以其他方式限制，其也可以起到帮助各种支付交易的处理的作用。通过此，商家可以为其现有的、已经部署的支付系统提供新生，而无需对新的计算资源和/或支付读取器进行大量投资。此外，通过使用基于云的资源创建混合处理系统，可以提高现有支付处理解决方案的安全性和效率(例如，通过提供更健壮的加密解决方案)。结果，即使在过时的硬件或其他因素可能不允许在支付读取器本身的层次上进行改进的情况下，也实现对计算系统的改进。
56.在另一个实施例中，参考图5a，可以在读取器20中在与非安全(或相对非安全)区域和安全飞地270中的其他处理组件在物理上且在逻辑上隔离的区域中，提供额外的处理器，其管理与安全飞地270分隔的安全区域。该额外的安全区域在本文中称为“信任区域”或“可信区域”520。信任区域处理器510的资源管理信任区域520，即，在芯片本身上管理信任
区域的安全性。在一些实施例中，信任区域处理器510可以保持指定支付读取器应该处于“信任”还是“正常”状态的位值，尽管其他实施例也是可能的。读取器20的组件和任何数据总线将被通知该位值，从而允许处理器510隔离信任区域并控制对其的访问。作为一个示例，可以用来自arm公司的技术来实现信任区域520，但是，也可以使用其他技术。信任区域可以包括相应的硬件(例如，单独的处理单元、存储器)、固件和软件(例如，应用程序)。
57.在一个示例性实施例中，内核控制器305可以动态地确定将gen2功能的处理重新引导到位于支付读取器20的隔离的信任区域520中的单独的gen2内核354。内核控制器305可以基于诸如篡改事件之类的检测到的事件做出这样的确定。也就是说，在检测到篡改尝试之后，内核控制器305可以重新路由gen2功能的处理(否则其可以由安全飞地270中的gen2内核354执行)，以改为由信任区域520内的gen2内核524执行。在另一实施方式中，信任区域可以与在支付读取器上运行的专用android处理器(例如，芯片)相关联，即，信任区域由androidos实现，其可以具有被引导到例如与篡改相关的功能的额外的安全特征。
58.在另一示例性架构中，支付系统1额外地包括诸如android智能电话之类的移动设备511，其被配置为充当ecr。在图5b所图示的示例性实施例中，设备511是移动设备，其具有android处理器517，用于处理androidos的各种功能并且用于管理具有专用于处理支付交易的l1模块522和l2内核524的信任区域520。在读取器20上的gen2内核可能无法满足gen2处理的安全需求的场景下(例如，检测到在读取器上的篡改尝试)，或者在读取器20没有可用的资源来处理安全密集型交易的场景下，内核控制器305可以发送要由在ecr511的隔离的信任区域520中的gen2内核524处理的gen2数据(如图5b中虚线所示)。在不同的实施例中，内核控制器305可以将gen2数据发送到移动设备40a，该移动设备40a转而确定该数据应该在信任区域中被处理，并且将该数据发送到信任区域520中的gen2内核524(如图5b中点线所示)。在又一替代架构(未具体示出)中，ecr511(例如，在android手机上)代替了支付读取器20，而不是独立的支付读取器20，并且ecr通过适当的内核在其信任区域中本地处理了gen2支付信息。
59.使用信任区域与要不然具有安全飞地的混合系统相比，可能具有几个好处。最初，在优选实施例中，通过本地运行的代码来实现信任区域，从而允许该代码直接访问硬件外围设备。因此，与下述解决方案相比，信任区域实现可能更有效，并且处理得更快，该解决方案具有的代码在例如必须访问操作系统/兼容性层的或可能需要额外的java编译的java层或主处理器上实现以执行同样动作。此外，因为信任区域的概念通常在基于arm的架构中(例如，在一些android手机上)实现，所以不需要单独的安全芯片，从而降低了制造成本。而且，由于信任区域通常在一些公共cpu架构中实现，因此其安全性已经过充分测试，导致具有更多组内置防御的潜在安全性更高的系统。
60.示例性条款
61.1.一种移动通信设备，包括：通信接口，用于与第一类型的支付读取器和第二类型的支付读取器进行通信，每个第二类型的支付读取器具有第二代层2(l2)内核，用于处理来自第二类型的支付设备的支付信息，并且每个第一类型的支付读取器具有第一代l2内核，用于处理来自第一代支付设备的支付信息；以及至少一个处理器，其编程有指令，该指令在由至少一个处理器执行时使至少一个处理器：接收经处理的第二类型的支付信息，经处理
的第二类型的支付信息已由第二类型的支付读取器的第二代l2内核处理；将经处理的第二类型的支付信息传输到一个或多个支付服务器，以基于经处理的第二类型的支付信息批准支付交易；接收由第一类型的支付读取器的第一代l2内核处理的第一类型的支付信息；将所述第一类型的支付信息传输给一个或多个支付服务器，以基于所述第一类型的支付信息批准支付交易；从第一类型的支付读取器接收原始的第二类型的支付信息；将原始的第二类型的支付信息提供给移动通信设备的第二代l2内核，用于处理原始的第二类型的支付信息；以及将已由移动通信设备的第二代l2内核处理的原始的第二类型的支付信息传输到一个或多个支付服务器，以基于所传输的原始的第二类型的支付信息批准支付交易。
62.2.根据条款1所述的移动通信设备，还包括：配置为直接从支付设备接收非接触式支付的接口，其中该接口使用移动通信设备的第二代l2内核接收非接触式支付。
63.3.根据条款1所述的移动通信设备，其中移动通信设备的第二代l2 内核具有比第一代l2内核更强的处理能力。
64.4.根据条款1所述的移动通信设备，其中，原始的第二类型的支付信息包括与支付交易有关的认证信息。
65.5.根据条款1所述的移动通信设备，其中，移动通信设备还配置为：从第二类型的支付读取器的第二代l2内核接收未经处理的第二类型的支付信息；将未经处理的第二类型的支付信息提供给移动通信设备的第二代 l2内核，以处理未经处理的第二类型的支付信息。
66.6.根据条款5所述的移动通信设备，其中，第二类型的支付读取器的第二代l2内核在功能上与移动通信设备的第二代l2内核相同。
67.7.根据条款1所述的移动通信设备，其中，移动通信设备是移动电话。
68.8.一种方法，包括：由移动通信设备从第一类型的支付读取器或第二类型的支付读取器接收支付信息，其中，第一类型的支付读取器具有第一代l2内核，用于处理来自第一类型的支付设备的支付信息，并且其中第二类型的支付读取器具有第二代层2(l2)内核，用于处理来自第二类型的支付设备的支付信息；在所接收的支付信息是由第二类型的支付读取器的第二代l2内核处理的经处理的第二类型的支付信息的情况下，由移动通信设备将经处理的第二类型的支付信息传输给一个或多个支付服务器，以基于经处理的第二类型的支付信息批准支付交易；在所接收的支付信息是由第一类型的支付读取器的第一代l2内核处理的第一类型的支付信息的情况下，由移动通信设备将第一类型的支付信息传输给一个或多个支付服务器，以基于第一类型的支付信息批准支付交易；在所接收的支付信息是来自第一类型的支付读取器的原始的第二类型的支付信息的情况下，(a)由移动通信设备将原始的第二类型的支付信息提供给移动通信设备的第二代l2 内核，用于处理原始的第二类型的支付信息，以及(b)由移动通信设备将已经由移动通信设备的第二代l2内核处理的原始的第二类型的支付信息传输到一个或多个支付服务器，以基于被传输的原始的第二类型的支付信息批准支付交易。
69.9.根据条款8所述的方法，还包括：使用移动通信设备的第二代l2 内核从支付设备接收非接触式支付。
70.10.根据条款8所述的方法，其中，移动通信设备的第二代l2内核具有比第一类型的支付读取器的第一代l2内核更强的处理能力。
71.11.根据条款8所述的方法，其中，原始的第二类型的支付信息包括与支付交易有关的认证信息。
72.12.根据条款8所述的方法，还包括：从第二类型的支付读取器的第二代l2内核接收未经处理的第二类型的支付信息；以及将未经处理的第二类型的支付信息提供给移动通信设备的第二代l2内核，用于处理未经处理的第二类型的支付信息。
73.13.根据条款8所述的方法，其中，第二类型的支付读取器的第二代 l2内核在功能上与移动通信设备的第二代l2内核相同。
74.14.根据条款8所述的方法，其中，移动通信设备是移动电话。
75.15.一种非暂态计算机可读存储介质，包括存储在其中的指令，该指令在由移动通信设备的一个或多个处理器执行时，使一个或多个处理单元执行操作，该操作包括：从移动通信设备外部的第一支付读取器或第二支付读取器接收支付信息，其中第一支付读取器具有配置为处理第一类型的支付信息的第一代l2内核，并且其中第二支付读取器具有配置为处理不同于第一类型的支付信息的第二类型的支付信息的第二代层2(l2)内核；在所接收的支付信息包括第二类型的支付信息并且所接收的支付信息已经由第二支付读取器的第二代l2内核处理情况下，将所接收的支付信息传输给一个或多个支付服务器，以基于所接收的支付信息批准支付交易；在所接收的支付信息包括第一类型的支付信息并且所接收的支付信息已经由第一支付读取器的第一代l2内核处理的情况下，将所接收的支付信息传输给一个或多个支付服务器，以基于所接收的支付信息批准支付交易；在所接收的支付信息包括第二类型的支付信息并且所接收的支付信息已经从第一支付读取器接收而未处理的情况下，执行以下项：(a)使用移动通信设备的第二代l2内核处理所接收的支付信息，以及(b)将经处理的支付信息传输到一个或多个支付服务器，以基于经处理的支付信息批准支付交易。
76.16.根据条款15所述的非暂态计算机可读存储介质，其中，指令的执行还使一个或多个处理单元执行操作，操作包括：使用移动通信设备的第二代l2内核从支付设备接收非接触式支付。
77.17.根据条款15所述的非暂态计算机可读存储介质，其中，移动通信设备的第二代l2内核具有比第一支付读取器的第一代l2内核更强的处理能力。
78.18.根据条款15所述的非暂态计算机可读存储介质，其中，所接收的支付信息包括与支付交易有关的认证信息。
79.19.根据条款15所述的非暂态计算机可读存储介质，其中，指令的执行还使一个或多个处理单元执行操作，操作包括：从第二支付读取器的第二代l2内核接收未经处理的支付信息，未经处理的支付信息包括第二类型的支付信息；以及将未经处理的支付信息提供给移动通信设备的第二代l2 内核，用于处理未经处理的支付信息。
80.20.根据条款15所述的非暂态计算机可读存储介质，其中第二支付读取器的第二代l2内核在功能上与移动通信设备的第二代l2内核相同。
81.21.一种销售点(pos)系统，包括：具有支付应用程序的支付读取器、层2(l2)内核的第一模块以及用于从支付设备接收支付信息的层1(l1) 模块，支付应用程序配置为将支付信息提供给l2内核的第一模块，用于由 l2内核的第一模块处理支付信息；以及支付读取器外部的装置，该装置具有l2内核的第二模块，其中，支付应用程序配置为将由l2内核的第
一模块处理的支付信息传输给该装置，用于由l2内核的第二模块处理。
82.22.根据条款21所述的pos系统，其中，装置配置为在支付信息已经由l2内核的第二模块处理之后，将支付信息传输到一个或多个支付服务器。
83.23.根据条款21所述的pos系统，其中，由l2内核的第二模块进行的处理与支付交易的认证有关。
84.24.根据条款21所述的pos系统，其中，支付信息包括第一支付信息和第二支付信息，其中l2内核的第一模块配置为处理第一支付信息，并且l2内核的第二模块配置为处理第二支付信息。
85.25.一种销售点(pos)系统，包括：支付设备，其具有支付应用程序、层2(l2)内核以及层1(l1)模块的第一子模块，l1模块的第一子模块配置为接收来自支付对象的支付信息，支付应用程序配置为将支付信息从 l1模块的第一子模块提供给l2内核，用于由l2内核处理支付信息；以及支付读取器，其耦合到支付设备并且具有l1模块的第二子模块，l1模块的第二子模块包括配置为从支付对象读取支付信息的物理接口，其中，支付读取器配置为将从支付对象读取的支付信息传输给l1模块的第一子模块。
86.26.根据条款25所述的pos系统，其中，支付设备是在支付读取器外部的移动电话，并且其中，支付读取器通信地耦合到移动电话。
87.27.根据条款25所述的pos系统，其中，l1模块的第二子模块与支付读取器的机械功能有关。
88.28.根据条款27所述的pos系统，其中，支付读取器的机械功能涉及以下项中的一个或多个：调节支付读取器的电压电平以及实现与支付对象的接触。
89.29.根据条款25所述的pos系统，其中，l1模块的第一子模块涉及对支付读取器的软件功能的控制。
90.30.根据条款25所述的pos系统，其中，l1模块的第一子模块涉及对支付读取器的电功能的控制。
91.31.根据条款30所述的pos系统，其中，支付读取器的电气功能涉及驱动电线和支付读取器的支付接口之间的电连接，并且其中，支付接口是emv接触盘或nfc线圈中的一个或多个。
92.32.一种支付设备，包括：接口，其配置为从支付对象接收支付信息；支付应用程序；内核的第一模块；以及能够与装置而非支付设备通信的无线通信接口，装置包括内核的第二模块，其中支付应用程序配置为经由无线通信接口将所接收的支付信息提供到装置，用于由第二模块处理。33.根据条款32所述的支付设备，其中，支付应用程序还配置为：经由无线通信接口从装置接收经处理的支付信息，经处理的支付信息已经由第二模块处理，并且将经处理的支付信息传输到一个或多个支付服务器。
93.34.根据条款32所述的支付设备，其中，支付应用程序还配置为：在将经处理的支付信息传输到一个或多个支付服务器之前，将经处理的支付信息传输到内核的第一模块以被处理。
94.35.根据条款32所述的支付设备，其中，第一模块处理所接收的支付信息的第一支付信息，并且第二模块处理所接收的支付信息的第二支付信息，并且其中，第一模块对第一
支付信息的处理和第二模块对第二支付信息的处理是并行进行的。
95.36.一种方法，包括：由支付设备从支付对象接收支付信息；由支付设备将支付信息传输给内核的第一模块，第一模块安装在支付设备上，用于由第一模块处理支付信息；以及由支付设备将由第一模块处理的支付信息传输给内核的第二模块，用于由第二模块进行处理，第二模块安装在支付设备外部的装置上。
96.前述内容仅是本公开的原理的说明，并且本领域技术人员可以在不脱离本公开的范围的情况下进行各种修改。呈现上述实施例是出于说明而非限制的目的。除了本文明确描述的形式以外，本公开还可以采取许多形式。因此，要强调的是，本公开不限于明确公开的方法、系统和装置，而是旨在包括在所附权利要求的精神之内的对其的变型和修改。
97.作为另一个示例，可以进行装置或工艺参数的变化(例如，尺寸、配置、组件、流程步骤顺序，等等)以进一步优化所提供的结构、设备和方法 (如本文所示和所描述的)。无论如何，本文所述的结构和设备以及相关联的方法具有许多应用。因此，所公开的主题不应限于本文所述的任何单个实施例，而应根据所附权利要求在广度和范围上来解释。