在具有无线通信功能的装置上经由空中传送(OTA)供应软卡的方法、系统和计算机程序产品

摘要

本文披露了在具有无线通信功能的装置上经由空中传送(OTA)供应软卡的方法、系统和计算机程序产品。根据一种方法，在具有无线通信功能的装置上对软卡供应应用进行实例化。从所述装置的用户获得希望在所述装置上供应的软卡的卡号。通过空中接口向供应配置服务器发送所述卡号。从所述供应配置服务器获得与所述卡号相对应的发卡方特定的质询和供应发放方服务器网络地址。向所述用户呈现所述质询，并接收对所述质询的用户响应。连接到与所述网络地址相对应的供应发放方服务器。将所述质询响应发送到所述供应发放方服务器。从所述供应发放方服务器接收用于激活软卡的软卡个性化数据。基于所述个性化数据供应所述软卡，以供在所述装置上使用。

说明书

相关申请

本申请要求享有2006年9月1日提交的美国专利申请No.11/514698的权益，通过引用将其公开全文并入于此。

技术领域

本文所述的主题涉及在具有无线通信功能的装置上供应软卡。更具体而言，本文所述的主题涉及在具有无线通信功能的装置上经由空中传送供应软卡的方法、系统和计算机程序产品。

背景技术

常规的物理支付卡、会员卡和忠诚卡通常是在发卡方控制的物理安全环境中供应的。例如，发卡方可以具有安全设施，在将卡发送给用户之前将卡储存在那里。在用户收到卡时，用户通常用电话联系发卡方以激活卡。

为了使用户无需携带物理卡，发卡方已开始发放软卡。如本文所使用的，术语“软卡”是指用于诸如支付交易之类的交易的软件实现的实体。软卡的范例包括诸如信用卡、忠诚卡、会员卡、标识卡的支付卡之类的支付卡以及其他支付和非支付卡。

可以在具有无线通信功能的装置上供应(provision)软卡。具有无线通信功能的装置可以与本地读卡器交互，以实现涉及软卡的交易。具有无线通信功能的装置的范例包括具有与本地读卡器之间的接口的移动电话、智能电话、密钥卡(key fob)、物理卡和个人数字助理。装置和读卡器之间的交互可以经过装置和读卡器之间的电和/或磁场进行。可以在能支持软卡的装置和用于支付交易的读卡器之间使用的一种通信信道为近场通信(NFC)。近场通信通常发生在装置和非接触读卡器之间使用的通信频率的大约一个波长之内的距离处。可以用于能支持软卡的装置和非接触读卡器之间通信的非接触通信协议的范例为ISO 14443接口。

具有无线通信功能的装置还可以与远程实体进行数据通信。例如，具有无线通信功能的装置可以实现空中接口上的HTTP over TCP/IP，以与远程实体通信。具有无线通信功能的装置所用的空中接口协议可以随装置而变。可以使用的空中接口协议的范例包括GSM、GPRS、CDMA、蓝牙等。

为了在具有无线通信功能的装置上使用软卡，必需向装置上供应或加载软卡。用于在移动装置上供应软卡的一种可能方案是在发卡方控制的安全设施处供应该装置。然而，要求用户将其移动电话或PDA带到发卡方那里进行安全供应是不现实的。因此，一种常规的供应方法涉及到用户给发卡方打电话并请求软卡。发卡方那里的人工操作员或呼叫中心获取用户信息。发卡方验证该用户并为多个用户的软卡供应请求排队。当发卡方获得一批软卡供应请求时，发卡方将卡按批供应。从软卡请求直到按批供应的时间可能从3到20天不等。这样的延迟对于希望立即使用其软卡的用户来说是不合乎需要的。

常规卡供应系统的另一个问题是系统不可缩放(not scalable)。例如，发卡方特定的供应系统利用专门协议与后端网络装置通信。可以认为，不存在能够利用移动装置的单个联系点供应由不同发卡方发放的卡的系统。

因此，鉴于常规软卡供应方法的这些问题，需要提出一种用于在具有无线通信功能的装置上经由空中传送供应软卡的改进的方法、系统和计算机程序产品。

发明内容

本文公开了用于在具有无线通信功能的装置上经由空中传送供应软卡的方法、系统和计算机程序产品。根据一种方法，在具有无线通信功能的装置上对软卡供应应用进行实例化。从该装置的用户获取希望在该装置上供应的软卡的卡号。通过空中接口向供应配置服务器发送该卡号。

从供应配置服务器获取对应于该卡号的发卡方特定的质询以及供应发放方服务器的网络地址。向用户提出质询，并接收用户对质询的响应。生成通往对应于该网络地址的供应发放方服务器的连接。将质询响应发送到供应发放方服务器。从供应发放方服务器接收用于供应软卡的软卡个性化数据。基于个性化数据供应软卡以在该装置上使用。

例如，可以利用HTTP和TCP协议通过无线连接进行经空中接口的软卡供应。可以为该供应连接创建TCP套接字。连接的物理层可以利用CDMA、蓝牙、GPRS或GSM空中接口协议。可以通过因特网或企业或其他内联网进行供应。供应可以是直接的，即供应不需要语音呼叫。亦即，可以不要求该装置的用户给发卡方或第三方打电话来发起卡供应。可以通过在移动装置上提供供应应用，该移动装置响应于被启动的情况而与供应配置服务器建立连接，从而自动进行供应。用户无需发起语音呼叫就可供应软卡，从而减少了供应过程所需的时间。

可以利用包括体现于计算机可读介质中的计算机可执行指令的计算机程序产品来实现本文所述的用于在具有无线通信功能的装置上经由空中传送供应软卡的方法和系统。适于实现本文所述主题的示范性计算机可读介质包括芯片存储装置、磁盘存储装置、可编程序逻辑装置、专用集成电路和可下载电信号。此外，实现本文所述主题的计算机程序产品可以位于单个装置或计算平台上，或者可以分布于多个装置或计算平台中。

附图说明

现在将参考附图解释本文所述的主题的优选实施例，附图中：

图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可以基于请求中提供的卡号或标识符识别与该请求相关联的发卡方。供应配置服务器108可以从发卡方获取质询数据，并可以向供应和支付应用102发送该质询数据。供应配置服务器108可以为移动装置用户提供单个联系点，以供应软卡。此外，供应配置服务器108可以用于和多个发卡方通信。结果，供应配置服务器108为软卡供应提供了易用且可缩放的方案。

供应发送方服务器110可以驻留在每个不同的发卡方，且可以与每个发卡方的后台办公系统集成，以提供卡供应数据、和诸如账户余额、奖金、卡上预先印刷的信息、以及个性化压制(emboss)信息(截止日期、CVV、卡上的名称、PAN)之类的卡图像和卡金融信息。对于软卡而言，可以经由与该装置相关联的图形用户界面向用户显示预先印刷的和个性化压制信息。供应发放方服务器110可以与供应和支付应用102通信，以认证用户并向应用102提供卡的个性化数据和卡图像信息。供应发放方服务器110还可以与后台办公系统114和发卡方客户支持点116通信。后台办公系统114可以为软卡存储用户的个人信息和个性化数据。客户支持点116可以为发卡方客户提供客户支持。

在图1所示的范例中，虚线箭头代表自动供应，这种供应涉及到web应用104，然后利用web应用用户名和口令，利用供应和支付应用102来供应具有单个请求的多个卡。实线箭头代表人工供应，这种供应利用供应和支付应用102一次供应一张卡。其余箭头代表WAP推送(push)供应，下文将详细描述这种供应。

图2是示出了根据本文所述主题的实施例的用于在具有无线通信功能的装置上供应软卡的示范性总体步骤的流程图。图2中的步骤可以由供应和支付应用102和/或web供应应用104执行。图2所示的步骤对于自动或人工供应而言意在表达一般情况。参考图2，在步骤200A中，如果是第一次使用装置，供应和支付应用102将连同近场通信部件一起配置内嵌于装置中的安全存储器。对于供应和支付应用102的回头用户，可以不重复该过程。在步骤200中，从用户接收到对软卡供应的请求。对于人工供应而言，可以由供应和支付应用102执行该步骤。对于自动供应而言，可以由web供应应用104执行该步骤。

在步骤202中，从用户获取卡标识符。卡标识符可以是与软卡请求相关联的个人账号(PAN)。对于人工供应而言，可以由供应和支付应用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接收供应发放方服务器信息、诸如Paypass、Visa、Discover之类的卡类型信息、以及由供应配置服务器108识别的供应发放方服务器的质询信息。在步骤207中，如果卡类型没有新的实例，供应和支付应用102可以在安全存储器中生成卡类型实例以进行个性化。在步骤208A中，供应和支付应用102可以向用户发送由用于特定发卡方的供应配置服务器108接收到的所有质询问题。在步骤208中，供应和支付应用102从用户获取质询响应信息。在步骤210中，供应和支付应用102向供应发放方服务器发送质询响应。在步骤212中，供应和支付应用102从供应发放方服务器110获取卡的个性化数据、卡图像和预先印刷的卡信息以及卡压制信息。

如果供应和支付应用102成功地通过空中接口接收到卡的个性化数据，则供应和支付应用102通过在存储器中存储个性化数据来提供软卡，以在装置上使用。如果供应和支付应用102未能成功接收到软卡个性化数据，则供应和支付应用102可以从与该装置相关联的安全芯片读取卡磁道信息(card track information)，以获取和显示卡号的最后四位并在供应时或在支付时显示默认的卡图像。

图3A和3B为示出了根据本文所述主题的实施例的在人工供应过程中由供应和支付应用102执行的示范性详细步骤的流程图。参考图3A，在步骤300中，为具有无线通信功能的装置加电。在步骤302中，用户等待装置启动。在步骤304中，用户选择供应和支付应用102。在步骤306中，用户等待供应和支付应用102打开。

在步骤308中，假设已经配置了安全存储器中嵌入的近场通信部件，用户选择人工供应选项。如上所述，人工供应包括例如利用因特网(HTTPover TCP/IP)供应具有无线通信功能的装置，无需在web应用中预先加载信息。在步骤310中，应用102判断要下载的卡数量是否小于预定最大数量。可以由软卡供应和支付应用102的开发者配置最大数量。在步骤312中，如果要下载的卡数量不小于最大数量，控制前进到步骤314，在该步骤中人工供应过程结束。

在步骤310中，如果要下载的卡数量小于最大数量，控制前进到步骤316，在该步骤中，应用102要求用户输入要下载的卡的PAN号。一旦用户输入了PAN号码，控制就前进到图3B中的步骤318，在该步骤中应用开始认证过程。将在下文中描述认证该装置的详细步骤。在步骤320中，判断该装置是否被认证。如果该装置未被认证，控制则前进到步骤322，在该步骤中，应用102指出该电话不是具有安全存储器和近场通信部件的有效电话。应用102可以向用户显示消息，以联系客户支持。然后控制前进到步骤314，在该步骤，供应过程结束。

在步骤320中，如果该装置得到成功认证，控制则前进到步骤324，在该步骤中，应用102从供应配置服务器108获取发卡方信息、卡类型信息和质询问题。在步骤325A中，如果没有卡类型的实例，供应和支付应用102可以创建卡类型的新的实例。在步骤325B中，供应和支付应用102可以向用户提出质询问题。在步骤326中，用户提供质询问题的响应。在步骤328中，应用102向所识别的供应发放方服务器发出软卡下载请求。所识别的供应发放方服务器110可以与发卡方后端网络通信，以利用软卡下载请求中提供的质询响应信息使证实用户。一旦用户被证实，供应发放方服务器110可以向供应和支付应用102提供软卡个性化数据。应用102从供应发放方服务器接收软卡个性化数据。在步骤330中，应用102向用户显示具有卡昵称和卡PAN号最后四位的卡图像，并可以分别在安全存储器和记录管理存储器(RMS)中存储压制信息和预先印刷的信息。在步骤332中，应用102判断用户是否希望下载另一张卡。如果用户给出肯定的答复，控制返回到步骤308，在该步骤中，为下一张卡重新开始供应过程。如果用户不希望下载另一张卡，控制前进到步骤334，在该步骤，供应过程结束。

如上所述，在一种实施方式中，用户可以利用用于单张卡或多张卡的web应用104预先加载一些供应过程所需的信息。将预先证实以及在web应用104中预先加载信息以辅助软卡供应的过程称为软卡请求。图4A和4B示出了在发起软卡请求时可以利用web应用104执行的示范性步骤。参考图4A，在步骤400中，用户针对希望供应的软卡提供PAN号、截止日期和其他卡验证值。在步骤402中，web应用104向供应配置服务器108发送卡信息并从供应配置服务器108获取质询问题和发卡方标识信息。在步骤404中，web供应应用104判断在登记期间用户是否已提供了对质询问题的响应。如果还未提供对质询问题的所有响应，控制前进到步骤406，在该步骤中，web应用104向用户询问缺少的对质询问题的响应。

在步骤408中，web供应应用104向发卡方发送PAN和对质询问题的响应。发卡方利用发放物理卡期间提供的发卡方后台办公数据库中存储的用户信息证实卡信息以及对质询问题的响应。在步骤410中，web供应应用104判断证实是否成功。如果证实未成功，控制则前进到步骤412，在该步骤中，应用104询问用户，用户是否希望重新尝试。如果用户选择是，控制则前进到步骤414，在该步骤中用户重新输入证实信息。然后由发卡方再次尝试证实。

如果证实成功，则控制前进到步骤418，在该步骤中，应用104接收证实确认、卡图像、以及账户用户标识符和/或PAN。参考图4B，在步骤420中，应用104存储卡图像和一般账户信息，例如昵称、截止日期和账户余额信息。在步骤422中，应用104显示确认页，表明成功完成了软卡请求。在步骤424中，应用104判断用户是否希望针对另一张卡重复该过程。如果用户希望针对另一张卡重复该过程，控制返回到步骤400，并重复软卡请求的步骤。如果用户不希望处理另一张卡，控制前进到步骤426，在该步骤中，终止软卡请求过程，将用户重新引导到供应实体的主页。

如上所述，一旦用户利用应用104和图4A和4B所示的过程预先存储了一个或多个软卡，用户就可以利用自动供应过程在其具有无线通信功能的装置上自动供应软卡。图5A和5B为示出了根据本文所述主题的实施例在实现自动供应过程期间可以由供应和支付应用102执行的示范性步骤的流程图。参考图5A，在步骤500中，用户为具有无线通信功能的装置加电。在步骤502中，用户等待装置启动。在步骤504中，用户选择供应和支付应用102。在步骤506中，用户等待供应和支付应用102打开。

一旦打开供应和支付应用102，在步骤508中，用户选择自动供应选项。然后控制前进到步骤510，在该步骤中，判断与web应用104相关联的用户名和口令是否预先存储在该装置上。如果用户名和口令未预先存储在该装置上，控制则前进到步骤512，在该步骤供应和支付应用102询问用户的用户名和口令。在步骤514中，用户输入在web登记过程中生成的用户名和口令。控制然后前进到步骤516，在该步骤开始装置认证过程。如上所述，装置认证可以包括与供应配置服务器108通信以判断是否授权该装置接收供应信息。

参考图5B，在步骤518中，判断认证是否成功。如果认证不成功，控制前进到步骤520，在该步骤中，供应和支付应用102指出该装置不是有效的近场通信(或其他无线通信)手持移动置信装置，并指示用户联系客户支持。在步骤522中，自动供应过程结束。

返回步骤518，如果该装置得到成功认证，控制前进到步骤524，在该步骤中，通过供应配置服务器108利用web应用104证实用户名和口令。在步骤526中，判断用户名和口令是否得到证实。如果用户名和口令未得到验证，控制前进到步骤528，在该步骤中，判断重试是否超过重试的最大次数。如果重试未超过最大次数，控制前进到步骤530，在该步骤中，提示用户再次输入用户名和口令。

在步骤526中，如果证实了用户名和口令，控制前进到步骤532，在该步骤中，将为用户预先利用web应用104存储的软卡请求数据下载到供应和支付应用102。

在步骤534中，判断供应和支付应用102中存在的卡数量是否小于卡的最大数量。如果该数量不小于最大数量，控制前进到步骤536，在该步骤中向用户显示消息，表示该应用不能支持超过最大数量的卡。在步骤538中，供应过程结束。

返回到步骤534，如果应用中存在的卡数量小于最大数量，控制前进到步骤540，在该步骤中，将卡的个性化信息下载到具有无线通信功能的装置中。如果web应用104中配置的卡的配置数量大于1，则个性化过程一次处理一张卡的个性化。在步骤542中，该装置向用户显示卡。在步骤544中，自动供应过程结束。

如上所述，供应配置服务器108充当着供应和支付应用102和多个不同发卡方的联系点。图6为示出了根据本文所述主题的实施例在具有无线通信功能的装置上供应软卡期间可以由供应配置服务器108执行的示范性总体步骤的流程图。参考图6，在步骤600中，供应配置服务器108从具有无线通信功能的装置接收卡标识符信息。在步骤602中，服务器108通过在将(从PAN提取到的)发卡方标识号(IIN)与发卡方匹配的数据库中进行查找来识别发卡方。下面的表1示出了这种数据库中可以包括的示范性条目。

  IIN号  供应发放方服务器的IP地址  XXXXXX-XXXXYY  128.128.0.1  AAAAAA-AAAABB  128.256.0.1  EEEEEE-EEEEFF  192.128.0.1  JJJJJJ-JJJJKK  192.256.0.1

表1：IIN号到发卡方的映射

在表1中，第一列包括IIN号的范围。表1中所示的包含字母符号的条目用于表示对应于IIN号的数字符号。如上所述，IIN号是ISO发放的发卡方的发卡方标识号。发卡方标识号可以与信用卡、借记卡或签帐卡相关联。通常，IIN号是物理卡表面上或软卡图形图像上印刷的PAN的前3-6位。表1中的第二列表示不同供应发放方服务器的供应发放方服务器IP地址。供应配置服务器108可以将该信息提供到供应和支付应用102，以允许供应和支付应用102建立安全的通信并获得软卡的个性化数据。

在步骤604中，供应配置服务器108从用于特定发卡方的数据库提取发卡方特定的质询问题。在步骤606中，供应配置服务器108向驻留在请求供应软卡的手持移动置信装置上的供应和支付应用102发送发卡方特定的质询问题和发卡方标识信息。

图7A和7B为示出了根据本文所述主题的实施例用于人工和自动软卡供应的示范性详细步骤的流程图。参考图7A，在步骤700中，供应和支付应用102执行预个性化过程。在预个性化过程期间，供应和支付应用102可以更改或管理要用于建立安全通信的加密密钥。预个性化过程可以通过供应和支付应用102在近场通信部件的安全芯片中配置基础支付和未支付小程序(applet)。由于支付部分的功能不是解释本文所述的主题所必需的，因此将不再进一步赘述其工作。

在步骤702中，判断是否正在执行自动或人工供应。如果正在进行人工供应，控制则前进到步骤704，在该步骤，用户在具有无线通信功能的装置上输入PAN和对质询问题的响应。在步骤706中，供应和支付应用102通过供应配置服务器108建立通往供应发放方服务器110的安全信道，以便向和从供应发放方服务器108直接传输数据。

在步骤708中，供应和支付应用102对PAN标识信息和对质询问题的响应进行加密并发送到供应信息服务器708。在步骤710中，供应信息服务器110向发卡方后端网络发送PAN和对质询问题的响应。

在步骤712中，供应发放方服务器110判断数据是否已经得到证实。如果数据尚未得到证实，控制则前进到步骤714，在该步骤，供应和支付应用102指出不能证实用户输入的质询信息。可以提示用户再试一次。在步骤716中，该过程终止。

返回步骤712，如果数据得到证实，控制则前进到图7B中的步骤718，在该步骤，发卡方后端网络向供应发放服务器110提供卡个性化数据、加密密钥和卡图像。在步骤720中，供应发放方服务器110利用会话密钥对数据包加密并将其发送到供应和支付应用102。在步骤722中，供应和支付应用102向移动置信手持装置上的安全芯片发送卡个性化数据以对软卡进行个性化，并且还在操作系统文件系统中存储软卡的图像。在步骤724中，人工供应过程结束。

返回到图7A中的步骤702，如果选择的是自动供应，则控制前进到图7B中的步骤725，在该步骤中，供应和支付应用102通过供应配置服务器108建立通往供应发放方服务器110的安全信道，以向和从供应发放方服务器108直接传输数据。在步骤726中，供应和支付应用102加密由web应用104接收的PAN和质询问题以及其响应并一次一个地发送到供应发放方服务器110。在步骤728中，供应发放方服务器110向发卡方后端网络发送对请求下载的PAN的质询问题的响应。在步骤730中，判断数据是否得到证实。如果数据未得到验证，如上所述，执行步骤714和716。如果数据得到了证实，执行步骤718到724，以在装置上加载卡图像和个性化数据。

返回到图1，另一种在具有无线通信功能的装置上供应软卡的方法是WAP推送供应。WAP或无线应用协议是一种用于向移动装置提供信息的协议。图8A和8B为示出了根据本文所述的主题的实施例利用WAP推送供应来供应软卡的示范性步骤的流程图。参考图8A，在步骤800中，用户通过电话联系发卡方的客户支持。用户可以针对其希望在移动装置上供应的软卡提供移动电话号码、PAN号码、塑料卡上压制的CVV和截止日期。

在步骤802中，客户支持向用户询问质询问题。质询问题可以是如上所述的任何发卡方特定的质询。在步骤804中，发卡方后台办公应用基于用户向客户支持提供的信息证实用户证书。

在步骤806中，发卡方后台办公应用通过供应发放方服务器110向供应配置服务器108发出包含该卡的供应信息的WAP推送请求。在步骤808中，客户支持可以向用户索取蜂窝电话号码。在步骤810中，供应配置服务器108向软卡供应和支付应用102发送WAP消息、连同PAN和表示用户证书得到证实的标记以及发卡方信息。在步骤812中，具有无线通信功能的装置接收该WAP消息并自动启动供应和支付应用102。

在步骤814中，软卡供应和支付应用102读取WAP消息中传递的参数并开始供应过程。在步骤816中，软卡供应和支付应用102通过供应配置服务器108与供应发放方服务器110建立安全的通信。在步骤818中，软卡供应和支付应用102向供应发放方服务器110发送供应请求。

在步骤820中，基于静态或动态卡验证值，发卡方后端网络向供应发放方服务器110提供卡个性化数据、加密密钥和卡图像。在步骤824中，供应发放方服务器110利用会话密钥对数据包加密并将其发送到供应和支付应用102。在步骤826中，软卡供应和支付应用102将该信息传递到该装置上的安全芯片以进行个性化并在操作系统文件系统中存储卡图像。

要理解的是，可以在不脱离发明范围的情况下对本发明的各种细节做出更改。此外，以上描述仅仅出于例示的目的，而不是为了限制的目的。