本申请是2009年12月18递交的申请号为200980157050.8的中国专利申请的分案申请。相关申请本申请要求享有2008年12月19日提交的美国专利申请No.12/340,568的权益，该美国专利申请No.12/340,568是2006年9月1日提交的美国专利申请No.11/514,698的部分延续申请；通过引用的方式将两者的全部公开内容并入本文。技术领域本文所述的主题涉及在具有无线通信能力的设备上供应软卡。具体地说，本文所述的主题涉及在具有无线通信能力的设备上通过空中供应软卡的方法、系统和计算机可读介质。
背景技术：
常规的物理支付卡(联名卡或专用卡)、会员卡和忠诚卡通常是在由卡发行方控制的物理安全环境中供应的。例如，卡发行方可以具有安全设施，其中在将卡发送给用户之前在该安全设施中供应该卡。当用户收到卡时，该用户通常用电话联系卡发行方以激活该卡。为了使用户无需携带物理卡，卡发行方已开始发行软卡。如本文所使用的，术语“软卡”是指用于有助于交易(诸如支付交易)的软件实现的实体。软卡的例子包括诸如信用卡、借记卡、预付卡、电子钱包卡、交通卡、忠诚卡、会员卡、标识卡(包括门钥匙)之类的支付卡、其它支付和非支付卡、优惠券、促销券、票证(诸如用于交通、停车、电影、活动等的票证)。可以在具有无线通信能力的设备上供应软卡。具有无线通信能力的设备可以与本地读卡器交互，以能够实现涉及软卡的交易。具有无线通信能力的设备的例子包括具有到本地读卡器的接口的移动电话、智能电话、密钥卡(keyfob)、物理卡和个人数字助理。设备和读卡器之间的交互可以经由该设备和该读卡器之间的电场和/或磁场来进行。可以在能够支持软卡的设备和用于支付或偿还交易的读卡器之间使用的一种类型的通信信道是启用射频(RF)的近场通信(NFC)或者是非接触式的。近场通信通常发生在设备和非接触式读卡器之间所使用的通信射频的大约一个波长之内的距离处。可以在能够支持软卡的设备和非接触式读卡器之间的通信中使用的非接触式通信协议的例子是ISO14443或ISO18092接口。具有无线通信能力的设备还能够与远程实体进行数据通信。例如，具有无线通信能力的设备可以通过空中接口在传输控制协议/因特网协议(TCP/IP)、短消息服务点对点(SMSPP)、和/或卡应用工具包传输协议(CAT_TP)上实现安全超文本传输HTTP，以便与远程实体进行通信。具有无线通信能力的设备所使用的空中接口协议可以随该设备的不同而变化。可以使用的空中接口协议的例子包括GSM、GPRS、CDMA、蓝牙等。为了在具有无线通信能力的设备上使用软卡，必须将该软卡供应或加载到该设备上。一种用于在移动设备上供应软卡的可能的解决方案是在由卡发行方控制的安全设施处对该设备进行供应。然而，要求用户将其移动电话或PDA带到卡发行方位置以进行安全供应是不现实的。因此，一种常规的供应方法涉及用户呼叫卡发行方并请求软卡。卡发行方处的人工操作员或呼叫中心获取用户信息。卡发行方对该用户进行验证，并且对多个用户的软卡供应请求进行排队。当卡发行方获得一批软卡供应请求时，卡发行方成批地供应这些卡。从软卡请求到成批供应的时间范围可以是从3天到20天。对于期望立即使用其软卡的用户来说，这样的延迟是不合乎要求的。常规卡供应系统的另一个问题是系统是不可扩展的。例如，卡发行方特定的供应系统使用专用协议与后端网络设备进行通信。可以相信的是，没有能够使用移动设备的单个联络点来供应由不同卡发行方发行的卡的系统。因此，鉴于常规软卡供应方法的这些问题，人们需要在具有无线通信能力的设备上通过空中供应软卡的改进的方法、系统和计算机可读介质。
技术实现要素：
本文公开了在具有无线通信能力的设备上通过空中供应软卡的方法、系统和计算机可读介质。根据一种方法，在具有无线通信能力的设备上对软卡供应应用进行实例化。从设备的用户获得期望在该设备上供应的软卡的卡号。通过空中接口将表示发行方标识号(IIN)的卡号的前8位发送到供应配置服务器。从与发行方标识号(IIN)相对应的供应配置服务器获得供应发行方服务器网络地址。建立到与该网络地址相对应的供应发行方服务器的连接。将完整的卡号发送至供应发行方服务器。从供应发行方服务器获得与该卡号相对应的卡发行方特定的质询。向用户提出质询，并且接收用户对该质询的响应。将质询响应发送至供应发行方服务器。从供应发行方服务器接收用于供应软卡的连同商标图像、营销数据、卡压制和刻印数据、账户概要数据一起的软卡个性化数据。基于个性化数据供应软卡以在设备上使用。例如，可以使用安全超文本传输协议(HTTP)与传输控制协议(TCP)协议、短消息服务点对点(SMSPP)、以及卡应用工具包传输协议(CAT_TP)经由无线连接来进行通过空中接口的软卡供应。在超文本传输协议HTTP与TCP协议的情况下，可以创建TCP套接字以用于该供应连接。如果CAT_TP正用于供应，那么SMSPP和CAT_TP可以一起使用。如果SMSPP正用于供应，那么将不使用CAT_TP。该连接的物理层可以使用CDMA、蓝牙、GPRS、或GSM空中接口协议。可以在因特网上或在企业或其它内联网上、或通过SMS或CAT_TP来进行供应。由于供应不需要语音呼叫，所以供应可以是直接的。即，可以不要求设备用户呼叫卡发行方或第三方来发起卡供应。可以通过在移动设备上提供供应应用来进行自动供应，其中，该移动设备响应于被启动的情况而与供应配置服务器建立连接。用户无需发起语音呼叫就可供应软卡，从而减少了供应过程所需的时间。可以使用在其上存储有计算机可执行指令的计算机可读介质来实现本文所述的在具有无线通信能力的设备上通过空中供应软卡的方法和系统，其中，所述计算机可执行指令在由计算机的处理器执行时，控制该计算机将未进行供应的移动设备转变成供应有软卡的设备，以便进行视觉显示和由移动设备用户使用。适于实现本文所述主题的示例性计算机可读介质包括芯片存储设备、磁盘存储设备、可编程序逻辑设备和专用集成电路。此外，实现本文所述主题的计算机程序产品可以位于单个设备或计算平台上，或者可以分布于多个设备或计算平台中。附图说明现在将参照附图解释本文所述主题的优选实施例，其中在附图中：图1是根据本文所述主题的实施例的、用于在具有无线通信能力的设备上通过空中供应软卡的系统的方框图；图2是示出了根据本文所述主题的实施例的、从软卡供应应用角度来看的用于人工供应软卡的示例性总体步骤的流程图；图3A和3B是示出了根据本文所述主题的实施例的、从软卡供应应用角度来看的用于通过空中接口供应软卡的示例性详细步骤的流程图；图4A和4B是根据本文所述主题的实施例的、用于使用web接口来为软卡预加载供应信息的示例性详细步骤的流程图；图5A和5B是示出了根据本文所述主题的实施例的、由软卡供应应用执行以自动供应软卡的示例性详细步骤的流程图；图6是示出了根据本文所述主题的实施例的、从供应配置服务器角度来看的用于供应软卡的示例性总体步骤的流程图；图7A和7B是示出了根据本文所述主题的实施例的总体供应过程的示例性详细步骤的流程图；并且图8A和8B是示出了根据本文所述主题的实施例的、用于使用WAP推送方法来供应软卡的示例性步骤的流程图。具体实施方式图1是根据本文所述主题的实施例的、用于在具有无线通信能力的设备上供应软卡的供应系统的方框图。参照图1，系统100包括供应和支付应用102、web供应应用104、管理站点106、供应配置服务器108以及一个或多个设在卡发行方位置处的供应发行方服务器110。供应和支付应用102可以位于诸如移动电话、智能电话或个人数字助理之类的具有无线通信能力的设备上。无线网络运营商112可以提供与供应和支付应用102进行供应通信的路径。该路径可以是独立于语音呼叫的IP连接，从而不需要用户利用语音呼叫来发起供应。供应和支付应用102可以为终端用户提供用户接口，以发起对位于无线通信设备上的一个或多个软卡的供应。供应和支付应用102可以与用户进行通信以获得认证信息，并可以联系供应发行方服务器110以获得软卡个性化数据。下文将更详细地描述由供应和支付应用102执行的示例性步骤。由于对解释本文所述主题而言支付功能不是必要的，所以在本文中供应和支付应用102还称为“供应应用”。web供应应用104可以允许用户执行经由web接口供应软卡所需的一个或多个步骤。web供应应用104可以位于与独立于卡发行方的实体相关联的web服务器上。web供应应用104可以允许用户在一次供应交易中供应多个卡。下文将描述由web供应应用104执行的示例性详细步骤。管理站点106可以为在手持设备上供应软卡提供客户支持。管理站点106的功能对于本文所述主题而言不是必要的。因此，将不再提供额外的细节。供应配置服务器108可以为多个不同的卡发行方存储配置和业务过程信息。例如，供应配置服务器108可以从供应和支付应用102接收软卡供应请求。供应配置服务器108可以基于该请求中提供的卡号的发行方标识号(IIN)或标识符来识别与该请求相关联的卡发行方。供应配置服务器108可以为移动设备用户提供单个联络点以供应软卡。此外，供应配置服务器108可以被配置为与多个卡发行方进行通信。因此，供应配置服务器108为软卡供应提供了易用且可扩展的解决方案。根据本文所述主题的另一个方面，供应配置服务器108可以执行电话生命周期管理、安全域生命周期管理、卡发行方配置管理、以及安全域密钥管理。安全域生命周期管理和安全域密钥管理将在下面进行详细描述。可由供应配置服务器108执行的电话生命周期管理动作包括当用户电话丢失或被盗时执行的操作，该操作包括：对与新电话相关联的安全要素进行认证；以及防止与旧电话相关联的安全要素的使用。可由供应配置管理服务器108执行的卡发行方配置管理操作包括：对每个卡发行方的供应发行方服务器配置和地址信息进行管理。供应发行方服务器110可以位于每个不同的卡发行方处，并且可以与每个卡发行方的后台办公系统集成，以提供卡供应数据、卡图像数据、质询问题、和诸如账户余额、奖金、卡上预先印制的信息、以及个性化压制(emboss)信息(失效日期、CVV、卡上的名称、PAN)之类的金融信息。对于软卡而言，可以经由与该设备相关联的图形用户界面向用户显示卡图像以及预先印制的和个性化压制的信息。可以通过空中接口从供应发行方服务器110获得的其它软卡个性化数据包括发行方营销数据，该发行方营销数据包括卡类型、账户类型、会员加入日期、发行方特定数据，其中，该发行方特定数据包括客户支持号码、发行方URL、发行方名称以及支持的网络。供应发行方服务器110可以与供应和支付应用102通信，以便认证用户以及向应用102传送卡个性化数据和卡图像信息。供应发行方服务器110还可以与后台办公系统114和卡发行方客户支持站点116通信。后台办公系统114可以为软卡存储用户的个人信息和个性化数据。客户支持站点116可以为卡发行方客户提供客户支持。根据本文所述主题的另一个方面，每个供应发行方服务器110可以执行账户生命周期管理、准备个性化数据以及执行安全域管理。可由供应发行方服务器110执行的账户生命周期管理操作包括当用户的信用卡丢失或被盗时执行的操作，该操作包括封锁旧信用卡和验证新信用卡。与嵌入式NFC和UICC/uSIM相关联的安全存储器被称为发行方安全域(ISD)，并且其具有发行方卡管理者密钥以对该ISD进行管理。发行方安全域可以被分为多个次安全域或子安全域，每个次安全域或子安全域具有其自己的卡管理者密钥，以便对这些安全域进行管理。ISD可以创建或删除子安全域，但是不能访问子安全域中的数据。安全域管理将允许ISD创建、删除、增加存储器分配、减少存储器分配、指派临时安全域密钥(卡管理者密钥)、向应用提供商指派安全域。可以由供应发行方服务器110执行与对安全域和子域进行管理相关联的这些操作。在图1所示的例子中，虚线箭头代表自动供应，这种供应涉及web应用104，并且随后利用web应用用户名和密码，使用供应和支付应用102来供应具有单个请求的多个卡。实线箭头代表人工供应，这种供应使用供应和支付应用102来每次供应单独的卡。其余箭头代表WAP推送供应，将在下面对其进行详细描述。图2是示出了根据本文所述主题的实施例的、用于在具有无线通信能力的设备上供应软卡的示例性总体步骤的流程图。图2中的步骤可以由供应和支付应用102和/或web供应应用104执行。图2所示的步骤对于自动或人工供应而言意在表达一般情况。参照图2，在步骤200A中，如果是第一次使用设备，则供应和支付应用102将对嵌入在该设备中的安全和/或非安全存储器连同近场通信部件一起进行配置。该存储器可以是以下述形式之一存在于设备中的任何存储器：嵌入式存储器、通用集成电路卡(UICC)的通用用户身份模块(uSIM)部分、用户识别模块(SIM)、可移动的元件、以及设备存储器。该存储器可以用于存储软卡个性化数据。对于供应和支付应用102的旧用户，可以不重复该过程。在步骤200中，从用户接收对软卡供应的请求。对于人工供应，可以由供应和支付应用102执行该步骤。对于自动供应，可以由web供应应用104执行该步骤。在步骤202中，从用户获得卡发行方标识符。该发行方标识符可以是与软卡请求相关联的个人账号(PAN)的发行方标识号(IIN)。对于人工供应，可以由供应和支付应用102执行步骤202。对于自动供应，可以由web供应应用104执行步骤202。在步骤204中，将发行方标识符发送到供应配置服务器108。在一个示例性实施方式中，供应配置服务器108可以与供应发行方服务器110具有1到n种关系。因此，供应和支付应用102和/或web供应应用104可以配置有针对单个供应配置服务器108的联系信息。不需要为供应和支付应用102和/或web供应应用104预先配置多个卡发行方标识，这允许以更高效的方式供应由不同发行方发行的不同卡。此外，利用供应配置服务器108来控制与供应和支付应用102、web供应应用104和发行方服务器110进行的通信，这使系统比卡发行方特定的供应系统更加可扩展。在人工供应过程中，可以由供应和支付应用102实施步骤204。在自动供应过程中，可以由web供应应用104执行步骤204。在步骤206中，供应和支付应用102接收供应发行方服务器信息、以及由供应配置服务器108识别的供应发行方服务器的卡类型信息(诸如Paypass、Visa、Discover)。在步骤207中，供应和支付应用102可以连接到供应发行方服务器110，发送卡标识信息并且接收质询问题。在步骤208A中，供应和支付应用102可以向用户发送由针对特定卡发行方的供应发行方服务器108接收到的所有质询问题。在步骤208中，供应和支付应用102从用户获得质询响应信息。在步骤210中，供应和支付应用102将该质询响应发送到供应发行方服务器。在步骤211中，如果针对卡类型没有出现新的实例，则供应和支付应用102可以在安全存储器中创建卡类型实例以进行个性化。在步骤212中，供应和支付应用102从供应发行方服务器110获得卡个性化数据、卡图像和预先印制的卡信息以及卡压制信息。如果供应和支付应用102通过空中接口成功地接收到卡个性化数据，则供应和支付应用102通过将个性化数据存储在存储器中来供应软卡，以便在设备上使用。如果供应和支付应用102未能成功接收到软卡个性化数据，则供应和支付应用102可以从与该设备相关联的安全芯片读取卡磁道(cardtrack)信息，以获得并显示卡号的后四位，并在供应时或在支付时显示默认的卡图像。图3A和3B是示出了根据本文所述主题的实施例的、在人工供应过程中由供应和支付应用102执行的示例性详细步骤的流程图。参照图3A，在步骤300中，为具有无线通信能力的设备加电。在步骤302中，用户等待设备启动。在步骤304中，用户选择供应和支付应用102。在步骤306中，用户等待供应和支付应用102打开。在步骤308中，假设已经配置了嵌入安全存储器中的近场通信部件，用户选择人工供应选项。如上所述，人工供应包括例如利用因特网(基于TCP/IP的HTTP)对具有无线通信能力的设备进行供应，而无需在web应用中预先加载信息。在步骤310中，应用102确定要下载的卡数量是否小于预定的最大数量。该最大数量可以由软卡供应和支付应用102的开发者配置。在步骤312中，如果要下载的卡数量不小于最大数量，则控制前进到步骤314，在该步骤314中人工供应过程结束。在步骤310中，如果要下载的卡数量小于最大数量，则控制前进到步骤316，在该步骤316中，应用102要求用户输入要下载的卡的PAN号码。一旦用户输入了PAN号码，控制就前进到图3B中的步骤318，在该步骤318中，应用开启认证过程。将在下文中描述用于对该设备进行认证的详细步骤。在步骤320中，确定该设备是否被认证。如果该设备未被认证，则控制前进到步骤322，在该步骤322中，应用102指出该电话不是具有安全存储器和近场通信部件的有效电话。应用102可以向用户显示消息，以联系客户支持。然后，控制前进到步骤314，在该步骤中，供应过程结束。在步骤320中，如果该设备被成功地认证，则控制前进到步骤324A，在该步骤324A中，应用102从供应配置服务器108获得卡发行方信息、卡类型信息。在步骤324B中，供应和支付应用102连接到供应发行方服务器110，并基于卡号和卡发行方得到质询问题。在步骤325中，供应和支付应用102可以向用户提出这些质询问题。在步骤326A中，用户提供对质询问题的响应。在步骤326B中，如果不存在卡类型的实例，则供应和支付应用102可以创建卡类型的新实例。在步骤328中，应用102向所识别的供应发行方服务器发出软卡下载请求。所识别的供应发行方服务器110可以与卡发行方后端网络通信，以使用软卡下载请求中提供的质询响应信息来验证该用户。一旦用户被验证，供应发行方服务器110就可以向供应和支付应用102提供软卡个性化数据。应用102从供应发行方服务器接收软卡个性化数据。在步骤330中，应用102向用户显示具有卡昵称和卡PAN号码后4位的卡图像，并且应用102可以分别在安全存储器和/或记录管理存储器(RMS)中存储压制信息和预先印制的信息。在步骤332中，应用102确定用户是否想要下载另一个卡。如果用户给出肯定的答复，则控制返回到步骤308，在该步骤308中，针对下一个卡重新开始供应过程。如果用户不希望下载另一个卡，则控制前进到步骤334，在步骤334中供应过程结束。如上所述，在一种实施方式中，用户可以使用用于单个卡或多个卡的web应用104来预先加载供应过程所需的一些信息。在web应用104中预先验证并预先加载信息以有助于软卡供应的过程被称为软卡请求。图4A和4B示出了在发起软卡请求时可以利用web应用104执行的示例性步骤。参照图4A，在步骤400中，用户针对希望供应的软卡提供PAN号码、失效日期、以及其它的卡验证值。在步骤402A中，web应用104将卡信息发送到供应配置服务器108，并从供应配置服务器108获得卡发行方标识信息。在步骤402B中，web应用104连接到供应发行方服务器110以获得质询问题，并且还获得在登记期间提供的针对质询问题的值。在步骤404中，web供应应用104确定在登记期间用户是否已提供了对质询问题的响应。如果尚未提供对质询问题的所有响应，则控制前进到步骤406，在该步骤406中，web应用104向用户询问对质询问题的缺失的响应。在步骤408中，web供应应用104将PAN和对质询问题的响应发送到卡发行方。卡发行方使用在物理卡发行期间提供的存储在卡发行方后台办公数据库中的用户信息，来验证卡信息和对质询问题的响应。在步骤410中，web供应应用104确定该验证是否成功。如果验证未成功，则控制前进到步骤412，在该步骤412中，应用104询问用户是否希望重试。如果用户选择是，则控制前进到步骤414，在该步骤414中，用户重新输入验证信息。然后，由卡发行方再次尝试验证。如果验证成功，则控制前进到步骤418，在该步骤418中，应用104接收验证确认、卡图像、以及账户用户标识符和/或PAN。参照图4B，在步骤420中，应用104存储卡图像和诸如昵称、失效日期以及账户余额信息之类的一般账户信息。在步骤422中，应用104显示确认页，该确认页表示成功完成了软卡请求。在步骤424中，应用104确定用户是否希望针对另一个卡重复该过程。如果用户希望针对另一个卡重复该过程，则控制返回到步骤400，并重复用于软卡请求的这些步骤。如果用户不希望处理另一个卡，则控制前进到步骤426，在该步骤426中，终止软卡请求过程，并将用户重新引导到供应实体的主页。如上所述，一旦用户使用应用104和图4A与4B所示的过程预先存储了一个或多个软卡，该用户就可以使用自动供应过程在其具有无线通信能力的设备上自动供应软卡。图5A和5B是示出了根据本文所述主题的实施例的、可以由供应和支付应用102在实现自动供应时执行的示例性步骤的流程图。参照图5A，在步骤500中，用户为具有无线通信能力的设备加电。在步骤502中，用户等待设备启动。在步骤504中，用户选择供应和支付应用102。在步骤506中，用户等待供应和支付应用102打开。一旦打开供应和支付应用102，在步骤508中，用户就选择自动供应选项。然后，控制前进到步骤510，在该步骤510中确定在设备上是否预先存储了与web应用104相关联的用户名和密码。如果用户名和密码没有预先存储在该设备上，则控制前进到步骤512，在该步骤512中供应和支付应用102向用户询问用户名和密码。在步骤514中，用户输入在web登记过程中创建的用户名和密码。然后，控制前进到步骤516，在该步骤516中开启设备认证过程。如上所述，设备认证可以包括：与供应配置服务器108进行通信，以确定该设备是否被授权以接收供应信息。参照图5B，在步骤518中确定认证是否成功。如果认证不成功，则控制前进到步骤520，在该步骤520中，供应和支付应用102指出该设备不是有效的近场通信(或其它无线通信)手持移动受信任设备，并指示用户联系客户支持。在步骤522中，自动供应过程结束。返回步骤518，如果设备被成功认证，则控制前进到步骤524，在该步骤524中，通过供应配置服务器108使用web应用104来验证用户名和密码。在步骤526中，确定用户名和密码是否已得到验证。如果用户名和密码未得到验证，则控制前进到步骤528，在该步骤528中确定重试是否超过重试的最大次数。如果重试未超过最大次数，则控制前进到步骤530，在该步骤530中，提示用户再次输入用户名和密码。在步骤526中，如果验证了用户名和密码，则控制前进到步骤532，在该步骤532中，将先前使用web应用104为用户存储的软卡请求数据下载到供应和支付应用102。在步骤534中，确定供应和支付应用102中存在的卡数量是否小于卡的最大数量。如果该数量不小于最大数量，则控制前进到步骤536，在该步骤536中向用户显示消息，该消息表示应用不能支持超过最大数量的卡。在步骤538中，供应过程结束。返回到步骤534，如果应用中存在的卡数量小于最大数量，则控制前进到步骤540，在该步骤540中，将卡的个性化信息下载到具有无线通信能力的设备中。如果在web应用104中配置的卡的配置数量大于1，则个性化过程一次处理一个卡的个性化。在步骤542中，该设备将卡显示给用户。在步骤544中，自动供应过程结束。如上所述，供应配置服务器108充当供应和支付应用102和多个不同卡发行方的联络点。图6是示出了根据本文所述主题的实施例的、可以在具有无线通信能力的设备上供应软卡期间由供应配置服务器108执行的示例性总体步骤的流程图。参照图6，在步骤600中，供应配置服务器108从具有无线通信能力的设备接收卡标识符信息。在步骤602中，服务器108通过在数据库中执行查找来识别卡发行方，其中该数据库将(从PAN取得的)发行方标识号(IIN)号码与卡发行方相匹配。下面的表1示出了可能包括在这种数据库中的示例性条目。IIN号供应发行方服务器IP地址XXXXXX–XXXXYY128.128.0.1AAAAAA-AAAABB128.256.0.1EEEEEE–EEEEFF192.128.0.1JJJJJJ-JJJJKK192.256.0.1表1：IIN号到卡发行方的映射在表1中，第一列包括IIN号的范围。表1中所示的包含字母符号的条目意在表示对应于IIN号的数字符号。如上所述，IIN号是由ISO发行的卡发行方的发行方标识号。发行方标识号可以与信用卡、借记卡或签帐卡相关联。通常，IIN号是在物理卡表面上或软卡图形图像上印制的PAN的前3-6位。表1中的第二列表示不同供应发行方服务器的供应发行方服务器IP地址或完全合格域名(FQDN)。供应配置服务器108可以将该信息提供给供应和支付应用102，以允许供应和支付应用102建立安全的通信并获得软卡个性化数据。在步骤604中，供应配置服务器108从针对特定卡发行方配置的数据库取得卡发行方特定的配置。在步骤606中，供应配置服务器108向位于请求供应软卡的手持移动受信任设备上的供应和支付应用102发送卡发行方特定的标识信息。图7A和7B是示出了根据本文所述主题的实施例的、用于人工和自动软卡供应的示例性详细步骤的流程图。参照图7A，在步骤700中，供应和支付应用102执行预个性化过程。在预个性化过程期间，供应和支付应用102可以更改或管理要用于建立安全通信的加密密钥。预个性化过程可以通过供应和支付应用102对近场通信部件的安全芯片中的基础支付和非支付程序(applet)进行配置。由于支付部分的功能不是解释本文所述主题所必需的，因此将不对其操作做进一步的描述。在步骤702中，确定正在执行自动供应还是人工供应。如果正在执行人工供应，则控制前进到步骤704，在该步骤704中，用户在具有无线通信能力的设备上输入PAN和对质询问题的响应。在步骤706中，供应和支付应用102通过供应配置服务器108创建到供应发行方服务器110的安全信道，以便向供应发行方服务器108和从供应发行方服务器108直接传输数据。在步骤708中，供应和支付应用102对PAN标识信息和对质询问题的响应进行加密，并将它们发送到供应发行方服务器708。在步骤710中，供应发行方服务器110将PAN和对质询问题的响应发送到卡发行方后端网络。在步骤712中，供应发行方服务器110确定数据是否已经得到验证。如果数据尚未得到验证，则控制前进到步骤714，在该步骤714中，供应和支付应用102指示不能验证用户输入的质询信息。可以提示用户再次尝试。在步骤716中，该过程终止。返回步骤712，如果数据得到验证，则控制前进到图7B中的步骤718，在该步骤718中，卡发行方后端网络将卡个性化数据、加密密钥和卡图像提供给供应发行方服务器110。在步骤720中，供应发行方服务器110用会话密钥对分组进行加密，并将其发送到供应和支付应用102。在步骤722中，供应和支付应用102将卡个性化数据发送到移动受信任手持设备上的安全芯片以用于软卡的个性化，并且还将软卡的图像存储在操作系统文件系统中。在步骤724中，人工供应过程结束。返回到图7A中的步骤702，如果选择自动供应，则控制前进到图7B中的步骤725，在该步骤725中，供应和支付应用102通过供应配置服务器108创建到供应发行方服务器110的安全信道，以便向供应发行方服务器108和从供应发行方服务器108直接传输数据。在步骤726中，供应和支付应用102对由web应用104接收的PAN和质询问题及其响应进行加密，并一次一个地发送到供应发行方服务器110。在步骤728中，供应发行方服务器110将对请求下载的PAN的质询问题的响应发送到卡发行方后端网络。在步骤730中，确定数据是否得到验证。如果数据未得到验证，则如上所述地执行步骤714和716。如果数据得到了验证，则执行步骤718到724，以在设备上加载卡图像和个性化数据。返回到图1，另一种在具有无线通信能力的设备上供应软卡的方法是WAP推送供应。WAP或无线应用协议是用于向移动设备递送信息的协议。图8A和8B是示出了根据本文所述主题的实施例的、用于使用WAP推送供应或控制SMS来供应软卡的示例性步骤的流程图。参照图8A，在步骤800中，用户通过电话联系卡发行方的客户支持。用户可以针对其期望在移动设备上供应的软卡来提供移动电话号码、PAN号码、压制在塑料卡上的CVV和失效日期。在步骤802中，客户支持向用户询问质询问题。质询问题可以是如上所述的任何卡发行方特定的质询。在步骤804中，卡发行方后台办公应用基于用户向客户支持提供的信息来对用户凭证进行验证。在步骤806中，卡发行方后台办公应用通过供应发行方服务器110向供应配置服务器108发出包含该卡的供应信息的WAP推送或控制SMS请求。在步骤808中，客户支持可以向用户询问手机号码。在步骤810中，供应配置服务器108将WAP消息连同PAN和表示用户凭证得到验证的标记以及卡发行方信息一起发送到软卡供应和支付应用102。在步骤812中，具有无线通信能力的设备接收该WAP消息或控制SMS，并自动启动供应和支付应用102。在步骤814中，软卡供应和支付应用102读取WAP消息中传递的参数并开始供应过程。在步骤816中，软卡供应和支付应用102通过供应配置服务器108与供应发行方服务器110建立安全的通信。在步骤818中，软卡供应和支付应用102将供应请求发送到供应发行方服务器110。在步骤820中，基于静态或动态卡验证值，卡发行方后端网络向供应发行方服务器110提供卡个性化数据、加密密钥和卡图像。在步骤824中，供应发行方服务器110用会话密钥对分组进行加密，并将其发送到供应和支付应用102。在步骤826中，软卡供应和支付应用102将该信息传递到设备上的安全芯片以用于个性化，并将卡图像存储在操作系统文件系统中。应当理解的是，可以在不脱离发明范围的情况下对本发明的各种细节做出更改。此外，以上描述仅仅出于例示的目的，而不是为了限制的目的。