移动支付方法及其装置与流程

本发明涉及移动支付，更具体地，涉及在服务器中执行移动支付的支付方法和用于执行移动支付的装置。

背景技术：

近来，随着使用诸如智能电话的移动终端的支付方法的增加，已经引入了各种支付方法。

当通过基于移动操作系统(os)的支付应用进行支付时，各种支付网关公司提供支付平台以提供支付服务。

因此，当通过执行安装在移动终端中的用于在线或离线支付的应用进行支付时，不知道要执行提供支付应用的多个应用中的哪一个，这可能会导致每次用户进行支付时不便于指定用于支付的应用。

另外，当用户使用各种支付应用进行支付时，每个应用都管理交易相关的支付信息，因此这些信息不是整体管理和使用的。

技术实现要素：

技术问题

鉴于上述技术背景设计了本发明，并且本发明的一个目的在于提供一种移动支付方法和包括以下服务器的移动支付系统：当用户的移动终端中存在多个移动支付应用时，该服务器通过定义支付应用的执行顺序来自动地确定并提供最高优先级支付应用，而不需要用户干预，并且当使用推送方案执行支付应用时，不管支付应用的类型如何，都可以通过执行最高优先级支付应用来整体管理所有信息。

本发明的另一个目的在于提供一种开放式营销平台，在该开放式营销平台中，支付服务运营商整体管理交易相关的支付信息，因此，当用户使用附属机构的应用在另一个商家处进行支付时，向附属机构提供另一个商家的交易信息，从而允许交易信息用于营销。

本发明不限于此，并且从已经在下面阐述的内容将更清楚地理解上面未描述的其它目的。

技术方案

本发明的一方面提供了一种移动支付方法，包括：从商家终端接收支付请求；确定已经发送支付请求的商家是否具有附属应用；通过预设优先级来确定多个支付应用当中的具有最高优先级的应用；以及向用户的移动终端发送用于执行确定为具有最高优先级的应用的推送命令。

在商家具有附属应用的情况下，确定优先级的步骤包括：当商家具有附属应用并且商家的附属应用包括安装在移动终端中的支付模块时，确定商家的附属应用具有最高优先级；当商家没有附属应用但存在由用户确定为主要支付应用的支付应用时，确定主要支付应用具有最高优先级；当主要支付应用不存在并且存在包括独立于附属应用的支付手段的基本支付应用时，确定基本支付应用具有最高优先级；并且当基本支付应用不存在并且商家的附属应用不同于商家时，确定不同商家的附属应用当中的包括最后安装的支付手段的附属应用具有最高优先级。

在商家没有附属应用的情况下，确定优先级的步骤包括：当移动终端中存在由用户确定为主要支付应用的支付应用时，确定主要支付应用具有最高优先级；当主要支付应用不存在并且存在包括独立于附属应用的支付手段的基本支付应用时，确定基本支付应用具有最高优先级；并且当基本支付应用不存在并且商家的附属应用不同于商家时，确定不同商家的附属应用当中的包括最后安装的支付手段的附属应用具有最高优先级。

本发明的另一方面提供了一种移动支付系统，其包括：移动终端，在该移动终端中安装了包括由服务运营商提供的支付模块的至少两个或更多个支付应用，并且当从服务服务器接收到用于执行应用的推送命令时，该移动终端通过向服务服务器发送交易信息和认证信息来执行应用并请求支付批准；服务服务器，其被配置为在从商家终端接收到支付请求时，通过预设优先级来确定安装在移动终端中的多个应用当中的具有最高优先级的应用，向移动终端发送用于执行具有最高优先级的应用的推送命令，当从移动终端接收到支付批准请求时，执行用户验证并使用认证信息执行支付应用的认证，存储交易信息，并且将交易信息和认证信息发送给金融服务器；以及金融服务器，其被配置为通过接收交易信息和认证信息来执行支付，并且将支付结果发送给服务服务器或移动终端。

有益效果

根据本发明，当存在各种支付应用时，根据每个支付应用的预设执行优先级来提供支付应用执行服务，使得在没有用户干预的情况下确定和提供最高优先级支付应用，从而向用户提供便利。另外，交易信息被共同存储在服务服务器中，使得可以有效地使用用户相关信息，并且共享诸如订户认证或金融机构注册的信息，使得可以提高用户便利性。

附图说明

图1是例示根据本发明的一个实施方式的移动支付方法的流程图。

图2是例示根据本发明的另一实施方式的移动支付方法中的服务服务器确定在移动终端没有商家附属应用时将通过其发送推送命令的支付应用的优先级的方法的流程图。

图3是例示根据本发明的又一实施方式的移动支付方法中的在移动终端没有支付应用时安装和执行支付应用的方法的流程图。

图4是根据本发明的进行移动支付的整个系统的结构图。

图5是根据本发明的另一实施方式的移动支付服务器的结构图。

图6是根据本发明的又一实施方式的移动终端的结构图。

图7是例示根据本发明的再一实施方式的移动支付方法的流程图。

具体实施方式

通过参照示例性实施方式的以下详细描述和附图，可以更容易地理解本发明的优点和特征以及实现它们的方法。然而，本发明可以以许多不同的形式实施，并且不应被解释为限于本文阐述的实施方式。相反，提供这些实施方式是为了使本公开将是透彻和完整的，并且将向本领域技术人员充分地传达本发明的构思，并且本发明将仅由所附权利要求限定。提供详细描述中使用的术语仅是为了描述本发明的实施方式，而不是为了限制的目的。除非上下文另有明确指示，否则单数形式包括复数形式。应当理解，术语“包括”或“包括有”在本文中使用时指定一些特征、数量、步骤、操作、元件和/或其组合，但除了描述之外，不排除一个或更多个其它特征、数量、步骤、操作、元件和/或其组合的存在或可能性。

以下，将参照附图详细地描述本发明的示例性实施方式。

使用移动终端进行在线和离线支付的情况的数量已经增加，并且多个各种支付应用经常地安装在单个移动终端中。在这种情况下，当没有确定应用的执行优先级时，每次用户进行支付时都可能会导致指定用于支付的应用的不便。

为了减少用户的不便，本发明提供了一种为多个应用分配优先级的方法，从而允许根据优先级自动执行支付应用。

将总结本发明的基本操作环境和支付方法，然后将参照实施方式详细地描述本发明的配置。

本发明提供了一种面向用户的支付系统。当如在传统情况下的用户将卡信息等发送给商店并且商店请求来自金融公司的支付批准时，存在暴露金融信息的高风险，这可能会导致安全问题，并且需要时间来使用积留的积分。

因此，本发明提供了一种方法，在该方法中，商店将交易细节发送给用户，并且用户在确认交易细节之后发出支付请求或者商店发出包括交易细节的支付请求。

另外，提供了一种结构，在该结构中，位于用户、商店和金融机构之间的支付服务运营商(以下简称为“运营商”)发出包括交易细节而不包括用户的金融信息的支付请求，并且服务服务器向金融公司(金融卡公司、银行等)请求支付批准。在这种情况下，前提条件是用户已签署作为服务服务器的会员，因此服务服务器管理用户的基本信息，使得通过将诸如交易id(tid)、移动终端标识符(电话号码等)、用户标识符(会员资格编号)等的非金融信息包括在交易细节(交易金额、交易物品、商店信息等)以及移动终端与服务服务器之间的没有传递诸如信用卡号等的金融信息的支付请求消息中来处理支付请求。

使用交易id、移动终端标识符或用户标识符处理批准请求，而不在服务服务器与金融公司之间传递金融信息。

在这种情况下，由于金融信息没有存储在商店终端、用户移动终端和服务服务器中的任何一个中，所以即使在商店终端、用户移动终端或服务服务器被黑客攻击时，用户的金融信息也不可能被盗，因此显著地提高了安全性。

另外，由于服务服务器与金融公司之间的数据传递是经由具有增强安全性的电缆网络来执行的，所以服务服务器可以被配置为存储用户(会员)的金融信息并通过向金融公司传递金融信息来发出针对每个交易的批准请求。

在本发明的操作环境中，由于服务服务器介于用户、商店与金融公司之间，并且当进行支付请求时，交易信息被发送给服务服务器，当用户同意获取交易信息时，服务服务器可以收集每个用户的每笔交易的细节信息(物品、单价、数量等)，并且可以构建关于用户的生活方式的大数据。

因此，可以向经由附属于运营商的服务服务器(即，各种服务供应商(例如，用于执行支付的金融公司、制造商、销售公司、慈善组织、游戏公司、娱乐公司、广播公司、社交网络运营商、教育相关组织等))来附属于运营商的附属机构(affiliate)提供来自于服务服务器的与用户的购买活动有关的信息和与捐赠活动有关的信息。

这里，关键特征在于，例如，从服务供应商a做出的购买细节可以由运营商提供给服务供应商b。

在这种情况下，当服务供应商b附属于运营商时，服务供应商a可以或可以不附属于运营商。

因此，允许附属于运营商的各种服务供应商访问比服务供应商做出的交易细节更多的累积的大数据，并且使用大数据执行营销。结果，可以实现开放式营销平台和开放式支付平台。

此外，随着更多服务供应商(以下简称为“附属机构”)附属于运营商，可以更积极地执行与用户的购买和捐赠活动有关的数据的收集，并且更多的附属机构可以访问大数据。因此，本发明为没有自己的支付应用的附属公司提供了app内app(app-in-app)支付解决方案。

也就是说，在具有其自己的应用但不具有支付特征的附属机构的情况下，运营商提供支付模块以允许支付特征可用于附属机构的应用。

运营商的支付模块可以以更新附属机构自己的应用的形式安装在用户的移动终端中，并且与附属机构的应用链接。当安装了运营商的支付模块时，优选的是，在附属机构自己的应用中显示用于指示安装了运营商的支付模块的措词，例如，“由基于使用情况的保险(ubi)技术支持”。

当用户尝试使用附属机构的应用进行支付时，允许用户使用所有附属于运营商的一个或更多个金融公司。

为了使服务供应商构建支付解决方案，例如，其自己的支付应用，并且执行支付处理，服务供应商必须附属于一个或更多个金融卡公司和银行，并且为了方便用户起见，需要附属于尽可能多的金融卡公司和银行。然而，除非服务供应商规模很大，否则服务供应商无法构建支付解决方案。根据本发明，当附属于多个金融公司的服务运营商以app内app方式向附属机构提供运营商支付模块并且该支付模块安装在附属机构自己的应用中或与附属机构自己的应用相关联时，附属机构，甚至是小规模的服务供应商，可以容易地提供支付特征，使得能够通过附属于服务运营商的各种金融公司而在其自己的应用中进行支付。

另外，当用户通过附属机构的应用向另一服务供应商进行支付或者针对在另一服务供应商的商店进行的购买进行支付时，可以向附属机构提供对应的交易信息。

因此，允许附属机构访问其它服务供应商的交易信息以及其自己的交易信息，因此可以利用更多的用户购买信息或活动信息(以下简称为“购买信息”)，例如，捐赠活动。另外，由于购买信息不仅包括购买金额，还包括诸如购买物品的细节信息，因此附属机构能够使用这样的信息进行准确的营销。

也就是说，通过本发明，不同于传统的封闭式系统，可以通过共享金融公司和用户购买信息来执行开放式支付和开放式营销。

下面描述通过附属机构的应用支付和获取购买信息的一个特定实施方式。

假设作为韩国折扣店零售连锁店的homeplus附属于运营商并且具有安装在其自己的应用中的或与其自己的应用相关联的运营商支付模块。

作为homeplus会员的在他/她的移动终端中已经安装了homeplus应用的用户成为运营商的会员并且同意在用户的移动终端中以homeplus应用更新等的形式在运营商支付模块的安装过程中使用购买信息。

然后，当用户例如购买音乐网络(mnet)的移动查看优惠券并使用homeplus应用进行支付时(当homeplus应用中有多个支付手段并且通过选择本发明的运营商支付手段来使用运营商支付模块进行支付时)，通过服务服务器进行支付，使得服务服务器可以得知用户的移动查看优惠券的购买细节。另外，运营商将用户的移动查看优惠券的购买细节提供给作为附属机构的homeplus，使得homeplus还可以得知用户的移动查看优惠券的购买细节。

也就是说，homeplus不仅可以得知用户在homeplus商店进行的购买细节，还可以得知从其它服务供应商进行的购买细节。

当用户购买mnet的移动查看优惠券时，用户可以使用mnet提供的支付手段，但是当homeplus提供更多奖励(要积留积分)时，用户可以通过homeplus应用为mnet产品进行支付。

因此，每个附属机构试图鼓励用户通过其自己的应用进行支付，以便提供更多的用户购买信息。为此，每个附属机构可以提供更多奖励，例如，要积留积分，并且用户可以在得到更多优惠的同时具有更广泛的选择范围，并且进行购买活动。

此外，由于已经有许多支付方法并且服务供应商正在提供各种支付手段，所以单个移动终端中经常包括多种支付手段。

在这种情况下，由于对于用户来说，每次从多种支付手段中选择一种很麻烦，所以优选的是，自动设置每种支付手段的优先级。

以下，将描述确定针对每种支付手段的优先级的实施方式。

在本说明书中，支付手段可以分为以下类型。

支付应用包括由支付服务运营商设计和管理的基本支付应用以及具有由服务供应商管理的支付特征的服务供应商应用，例如，homeplus、ebay等。

基本支付应用是由服务供应商设计的不管附属关系如何都提供支付服务的应用，并且当在支付时选择基本支付应用时，执行基本支付应用以执行支付。

在本说明书中，附属应用由服务供应商自主设计和管理，并且包括针对服务供应商附属于运营商的情况的独立应用、通过反映附属公司的品牌、设计和专业功能而在基本支付应用平台的基础上由运营商为附属公司新设计的独立附属应用、以及通过将运营商提供的支付模块嵌入到附属公司的现有应用中而创建的模块型附属应用。

独立附属应用注册于诸如app商店、谷歌play等的应用下载服务器中，可以是从这种服务器下载的，并且可以基于由服务运营商提供的平台来将附属商店的品牌或设计应用至其。

模块型附属应用注册于应用下载服务器中，但不需要单独下载，并且其是在用户更新附属应用或执行支付时通过诸如获得用户同意以进行下载的处理来自动下载和安装的。由于模块型附属应用不是独立执行的形式，所以在诸如智能手机的用户的移动终端中不存在单独的执行图标等。

当管理服务服务器的服务运营商可以开发并提供能够向附属合作伙伴提供支付服务的应用或模块时，期望设计和开发应用，使得该应用可应用于任何操作系统(os)，并且可以通过共享诸如订户认证、金融机构注册等的常用功能来提高用户便利性。

总之，在本说明书中，支付应用总体是指自相同(self-same)应用、基本支付应用、附属应用(包括自相同应用、独立应用和模块型应用)，并且用户指定的支付应用被称为主要支付应用。

图1是例示根据本发明的一个实施方式的在服务服务器中执行的移动支付方法的流程图。

在在线/离线支付中，服务服务器从商家接收支付请求以进行结算(s110)。服务服务器还可以被配置为从已经接收来自商家的交易信息的用户的移动终端接收支付请求。

此外，商家总体是指可以使用支付服务运营商的支付手段的商店、机构等，并且商店是指提供销售服务的地方。然而，在本发明中，商店也仅意指运营商的支付手段可用的地方，因此，本说明书中使用的术语“商店”具有与商家基本相同的含义。在每个实施方式中，仅为了便于描述而对商家和商店进行了不同的描述。

已经接收到支付请求的服务服务器以推送命令的形式向用户移动终端发送用于请求用户批准的支付请求。此时，由于可以在用户移动终端中安装多个支付应用，所以服务服务器确定将使用安装在用户移动终端中的多个应用当中的哪个应用进行支付，然后发送推送命令。

下面描述服务服务器确定用户的支付应用的实施方式。

服务服务器确定发送支付请求的商家是否具有附属应用(s120)。

为此，用于结算的支付请求可以包括商家id，并且可以使用商家id来确定商家是否具有附属应用。

当确定出从具有附属应用的商家接收到支付请求时，进一步确定附属应用是否已经安装在用户的移动终端中(s130)，并且当商家附属应用已经安装在移动终端中时，将附属应用确定为最高优先级的应用(s150)，并且将用于执行确定为具有最高优先级的应用的推送命令发送给用户的移动终端(s170)。

为了确定附属应用是否安装在用户的移动终端中，服务服务器将每个用户的应用安装历史存储在数据库(db)中，并且识别和管理每个用户在用户的移动终端中安装了哪个支付应用。

当附属应用存在时，由于附属应用包含可以在对应商家中使用的优惠券信息、折扣优惠、积分积留信息等，所以对于用户来说，最有利的是使用商家附属应用进行支付。因此，最高优先级被分配给商家附属应用。

即使当安装了商家附属应用时，在用户的选择下设置不同优先级而不将最高优先级分配给商家附属应用的方法也是可能的。例如，当附属应用和基本支付应用二者都已经安装在用户的移动终端中时，商家附属应用和基本支付应用都被显示，用户选择其中一个应用并接收选择结果(s140)，然后确定是否已经选择了商家附属应用(s145)。当选择了商家附属应用时，将最高优先级分配给商家附属应用(s150)，否则，根据针对没有商家附属应用的商家的应用的执行优先级来确定支付应用，这将在下面进行描述(s160)。

当从没有商店附属应用的商家接收到支付请求时或者当在用户的移动终端中没有安装附属于对应商家的应用时，确定一般商家的应用的执行优先级(s160)并且发送用于执行确定为具有最高优先级的应用的推送命令(s170)。

由于由服务服务器执行用户验证和支付应用认证，所以服务服务器可以存储和管理安装在用户的移动终端中的支付应用的安装历史，并且可以存储和管理安装在用户的移动终端中的应用列表。因此，服务服务器可以确定安装在用户的移动终端中的应用的执行优先级，并根据该确定发送推送命令。

图2是例示在不存在商家附属应用时已经接收到支付请求的服务服务器确定将通过其发送支付请求推送命令的应用的优先级的方法s160的流程图。

当未安装商家附属应用时，确定在所安装的支付应用当中是否存在由用户设置为主要支付应用的应用(s162)，并且当存在由用户设置的主要支付应用时，将主要支付应用确定为要用于支付的应用(s163)。

当用户已经将经常使用的支付应用设置为主要支付应用时，使用对应的应用有利于可以向用户提供便利并且可以集中优惠，并且可以避免由于缺少商家附属应用而不能进行支付的不便。

当不存在由用户设置为主要支付应用的应用时，不管附属应用如何，都确定是否可以独立地进行支付的运营商的基本支付应用(s164)，以及当安装了基本支付应用时，将基本支付应用确定为要用于支付的应用(s165)。

最后，即使当未安装基本支付应用时，也确定是否存在另一商家的附属支付应用(s166)，并且当存在一个或更多个附属支付应用时，将最近安装的支付应用确定为要用于支付的应用(s167)。

在另一实施方式中，在用户将特定附属机构的附属应用指定为主要支付应用的情况下，由于这样的事件被通知给服务服务器，并且因此服务服务器识别出该指定，所以服务服务器可以被配置为甚至在进行交易的商家是另一附属机构的会员时都选择所指定的主要支付应用，而不是选择另一附属机构的应用。

当完成确定附属商家的优先级或一般商家的优先级并且将用于执行支付应用的推送命令发送给用户的移动终端时，已经接收到推送命令的用户的移动终端执行对应的应用并执行支付。

在从附属商家接收到支付请求的情况下，可以通过在运行应用时自动应用会员资格积分或折扣优惠券来执行支付。在这种情况下，用户不需要搜索积分卡或折扣优惠券，并且能够支付应用了对应商家的优惠的价格，从而使用户的不便最小化。另外，当存在各种优惠时，可以向用户提供首先应用更高折扣率或要积留更多积分的价格。

当在用户的移动终端中没有安装支付应用时，服务服务器可以发送用于安装支付应用的推送命令或提供安装链接，从而允许用户安装支付应用。

图3是例示在没有支付应用时安装支付应用的方法的流程图。

当用户的移动终端接收到用于请求用户批准的推送命令(s310)时，移动终端确定在上述处理中确定的并包括在推送命令中的支付应用是否存在于移动终端中(s320)。

当确定出存在由服务服务器确定的支付应用时，立即执行支付应用(s340)，并且当由于删除等而没有安装应用时，安装对应的支付应用(s330)，然后执行(s340)。

如上所述，通过确定要针对在线和离线支付而执行的应用的优先级，自动选择最佳应用并根据情况执行支付，而无需用户每次都选择要用于支付的应用，并且甚至在用户的移动终端中没有安装发送支付请求的商家的附属应用时，都可以通过基本应用或另一商家的应用来处理支付，使得商家可以具有增加销售额的效果，并且用户可以容易地结算支付，而不会由于缺少对应商家的附属应用而不能进行支付。

图4是根据本发明的进行移动支付的整个系统的结构图。

便利店、家庭购物公司、银行、安全公司、保险公司等的各种附属应用安装在用户的移动终端中，并且由移动支付平台中心(即，服务运营商的服务服务器)注册和管理每个附属应用的信息和支付手段。

当使用安装在用户的移动终端中的各种应用进行在线/离线支付时，服务服务器根据预设的优先级逻辑确定来自多个应用中的要执行的支付应用，并且将用于执行用于用户批准的应用的推送命令发送给用户的移动终端，并且用户使用移动终端请求或批准支付，从而执行支付。

可以根据传统方法来执行由用户使用安装在用户的移动终端中的支付应用执行的后续支付处理，因此在本说明书中将不提供其详细描述。

在上述描述中，描述了处理流程，该处理流程主要关注由商家终端向服务服务器发出支付请求并且由已经接收到支付请求的服务服务器确定安装在用户终端中的应用当中的要执行的应用并以推送方式发送支付应用执行命令以请求用户批准。

在另一实施方式中，商家终端可以向用户的移动终端发出支付请求，并且用户可以选择安装在用户的移动终端中的支付应用之一并执行支付。支付应用的选择逻辑可以允许一直执行由用户指定的主要支付应用，或者可以基于包括在支付请求中的商家id来检查商家是否属于附属机构并且允许要执行的对应的附属应用。

主要支付应用可以是特定服务供应商的基本支付应用、附属应用和自相同应用中的任何一个。

由于安装在用户的移动终端中的多个应用使用由服务运营商提供的公共支付模块，所以不管附属公司如何，都经由服务服务器交换支付信息，并且支付细节、批准细节以及会员、优惠券的使用细节等所有的都存储在服务服务器中。

例如，在用户通过使用商家b的附属应用而在商家a处进行支付的情况下，传统上，仅商家a保留购买信息，因此不能实现购买信息的整合，从而这种信息的利用受到限制。然而，根据本发明，商家a的购买信息可以由服务服务器发送给商家b的附属应用，因此，不管所使用的支付应用如何，都可以在用户的移动终端中整体管理所有的支付信息，类似地，不管商家和附属应用的类型如何，都可以在服务服务器中累积所有用户的购买信息，使得购买信息可以用于大数据分析方法中。

服务运营商可以使用大数据分析方案来利用存储在其服务服务器中的移动支付信息，并且可以通过与用于信息共享的附属金融公司以及订购该服务的金融公司共享来有利地利用营销中的交易数据。服务服务器向商家提供用户的交易信息的方法可以包括各种方法，例如，仅向管理用于支付的附属应用的商家提供信息以及进一步向已经请求该信息的其它任意商家提供交易信息。图5是根据本发明的另一实施方式的提供移动支付服务的服务服务器500的结构图。

服务服务器500包括控制器510、优先级确定器520、交易信息提供器530、支付请求器540、以及应用执行请求发送器550。

控制器510管理每个模块以发送和接收支付所需的数据。

优先级确定器520根据预定义的支付应用优先级逻辑来确定要用于支付的附属应用或基本支付应用的优先级。

应用执行请求发送器550根据所确定的优先级将用于请求用户的批准并执行确定为具有最高优先级的应用的推送命令发送给移动终端，并且允许移动终端执行对应的应用并执行支付。

当移动终端执行支付应用并向服务服务器500发送支付批准请求时，支付请求器540将支付批准请求发送给金融服务器，从而允许支付获得批准。

交易信息提供器530向安装在用户的移动终端中的附属应用提供从商家终端或用户的移动终端接收的诸如购买信息的支付信息，使得用户可以整体管理支付信息。另外，交易信息提供器530将交易信息提供给附属机构，使得已经接收到交易信息的附属机构可以利用交易信息。

图6是根据本发明的又一实施方式的用于移动支付的移动终端600的结构图。

移动终端600包括用户界面(ui)提供器610和功能提供器620。

ui提供器610提供用于支付的已注册信用卡等的列表612、用于选择诸如条形码、近场通信(nfc)方法和快速响应(qr)码的支付方法的按钮、以及用于显示广告的区域616。

功能提供器620由用于以下功能的模块组成：提供支付处理或广告处理的功能622、用于用户验证和注册已注册信用卡等的功能624、以及用于其它通知、事件和通信的功能626。

由于服务运营商的支付模块可以以app内app的形式安装在功能提供器620中，所以不管用户的移动终端的类型如何，都可以安装服务运营商的支付模块，并且在在线/离线商家处执行支付。

当使用用户的移动终端600进行支付时，通过使用以app内app的形式安装的支付模块与服务服务器500通信来进行支付，因此不管进行支付的商家如何，都可以从服务服务器500接收支付信息，并且可以存储和管理支付信息。

包括由服务运营商提供的支付模块的多个支付应用可以安装在用户的移动终端600中，并且当移动终端600通过推送命令从服务服务器500接收支付请求时，移动终端600执行对应的应用。

在执行应用之后，移动终端600搜索诸如积分和优惠券之类的优惠手段以及支付手段，确定是否使用这种手段，并向服务服务器500发送支付请求。当移动终端600发送支付请求时，除了诸如要支付的金额、购买物品等的交易信息之外，移动终端600还可以发送用于自我验证的会员信息或用于支付应用认证的多条信息。

移动终端600的出生日期信息或电话号码可以用作用于自验证的会员资格信息，并且还可以使用诸如指纹、虹膜、签名信息等的生物信息。

由服务服务器500预先发出的应用序列号或在安装支付应用时发出的唯一用户标识符(uuid)可以用作用于支付应用认证的信息。

图7是例示根据本发明的又一实施方式的移动支付方法的流程图。

当将包括购买物品和购买金额的购买信息输入到商家并且将支付请求发送给服务服务器500时，接收支付请求(s710)的服务服务器500将用于用户验证的推送命令发送给用户的移动终端600(s720)。

在离线支付中，移动终端600与商家终端之间的数据交换可以通过nfc方法、qr码、条形码、支付信息中继卡等的手段来执行。

当将购买信息输入到会员拍摄终端时，还输入用于用户验证的信息。在这种情况下，可以将用户的电话号码等直接输入到商家终端，或者可用使用nfc方法、qr码等与移动终端600进行的数据交换。

当已经接收到推送命令的移动终端600执行应用并将支付批准请求发送回服务服务器500时，服务服务器500接收支付批准请求(s730)。

服务服务器500使用与支付批准请求一起接收的会员资格信息来执行用户的自我验证，通过基于支付应用信息确定是否复制或伪造支付应用来执行应用认证(s740)，以及当成功执行用户的自我验证和应用认证时，将支付请求发送给金融服务器(440)以执行支付。

商家终端在向服务服务器500发送支付请求时将交易相关信息以及用于认证的信息一起发送。

交易相关信息可以包括购买物品、总购买金额、每个物品的购买金额、支付手段等。当信用卡用作支付手段时，交易相关信息还可以包括是否进行分期付款、分期付款的次数、以及信用卡公司是否提供免息分期付款。

服务服务器500可以存储和管理每个用户的交易信息以及会员资格信息。由于通过经由服务服务器500将使用由服务运营商提供的支付应用或使用支付模块的附属应用的用户的所有购买信息发送给金融服务器来进行交易，所以服务服务器500可以存储购买信息，并将购买信息提供给用户，或者稍后将购买信息用作营销数据。

传统的商家终端仅识别对应商家的用户购买信息，并且由于仅可以获知使用金融服务器的支付手段的用户的购买信息的购买金额，所以金融服务器受限于计算用户的购买信息。

然而，由于根据本发明的服务服务器500能够存储使用支付应用或支付模块的所有用户的购买信息，而不管金融机构或商家如何，所以可以有效地管理和使用所收集的购买信息。也就是说，可以建立共享营销平台。

当从金融服务器接收到支付批准结果时(s760)，将批准结果发送给商家终端或用户的移动终端600以允许完成支付，并且服务服务器500将从商家终端接收的用户的购买信息发送给用户的移动终端600中安装的支付应用，使得服务服务器500和用户的移动终端600二者都可以存储和使用与支付相关联的交易信息。

由支付服务运营商的服务服务器管理的交易信息通常可用于附属应用的应用和利用。具有以下优点：便于通过在对应用进行认证时联合利用订户信息、在没有进一步注册的情况下联合应用已注册的金融机构以及设置主要支付应用来使用应用。

如上所述，尽管已经参照附图和优选实施方式详细地描述了本发明的构造，但这些实施方式仅是示例性的，并且本领域技术人员将理解，在不脱离本发明的技术精神和范围的情况下可以进行各种修改和改变。因此，本发明的保护范围应该由所附权利要求的描述来限定。