CN107646122A - 从支付账户交易生成捐赠的***和方法 - Google Patents

Abstract

公开了基于涉及支付账户的交易生成向慈善机构的捐赠的示例性***和方法。一种示例性方法包括：识别与支付账户相关联的至少一个交易；由计算设备基于所述至少一个交易生成向所述支付账户的捐赠值；由所述计算设备汇总所述至少一个交易的捐赠值；以及向与所述慈善机构相关联的收单方提交捐赠交易，以至少基于汇总的捐赠值向所述慈善机构支付金额。

Description

从支付账户交易生成捐赠的***和方法

相关申请的交叉引用

本申请是PCT国际申请并要求2015年3月30日提交的美国专利申请No.14/672,552的优先权。通过引用的方式将上述申请的全部公开内容并入到本文中。

技术领域

本公开总体上涉及基于消费者对与消费者相关联的支付账户进行的交易生成向例如一个或多个慈善机构等的捐赠的***和方法。

背景技术

本部分提供与本公开相关的背景信息，其不一定是现有技术。

向慈善机构捐赠是已知的。捐赠者通常以现金、支票、支付账户交易等形式向慈善机构提供捐赠。另外，捐赠可由捐赠者作为一次性捐赠或重复捐赠甚至计划性捐赠向慈善机构提供，这取决于捐赠者。

附图说明

本文描述的附图仅用于对选择的实施例而不是所有可能的实施方式进行说明的目的，并且不意图限制本公开的范围。

图1是适于用于基于消费者进行的支付账户交易从消费者生成向慈善机构的捐赠的本公开的示例性***的框图；

图2是可以在图1的示例性***中使用的计算设备的框图；

图3是供消费者使用的示例性界面，消费者使用该示例性界面来注册支付账户，以具有基于消费者对支付账户进行的交易而生成的代表消费者的捐赠；以及

图4是用于基于消费者对与消费者相关联的支付账户进行的交易而生成向慈善机构的捐赠的示例性方法。

在附图的几个图中，相应的附图标记表示相应的部分。

具体实施方式

现在将参考附图更全面的描述示例性实施例。本文包括的描述和具体示例仅出于说明的目的，并不旨在限制本公开的范围。

慈善机构经常鼓励消费者(广义上来说，是本文所指的捐赠者)定期捐赠。关于捐赠，可以允许消费者创建自动借记或其他交易以定期(例如，每周间隔等)向慈善机构进行定额捐赠。本文的***和方法特别地允许消费者将对慈善机构的捐赠捆绑(或连接)到涉及与消费者相关联的支付账户的交易，其受到各种条件的约束，从而捐赠被自动提供给慈善机构，并且也基于消费者的特定活动。

图1示出了示例性***100，其中可以实现本公开的一个或多个方面。尽管在描述的实施例中，***100的组件以一种布置呈现，但是其他实施例可以包括取决于例如支付设备交易的授权过程等以其他方式布置的相同或不同的组件。

如图1所示，***100通常包括商家102、收单方104、支付网络106、发行方108和慈善机构110，它们中的每个都耦接到网络112。网络112可以包括但不限于局域网(LAN)、广域网(WAN)(例如，因特网等)、移动网络、虚拟网络和/或能够支持图1所示的两个或更多个组件之间的通信的另一个合适的公共和/或专用网络，或其任意组合。例如，网络112可以包括多个不同的网络，例如，可由支付网络106和/或因特网访问的交易网络。

***100的商家102、收单方104、支付网络106、发行方108和慈善机构110中的每一个都可以实现在一个或多个计算设备中或与一个或多个计算设备相关联。为了说明，参考图2所示的示例性计算设备200来描述***100。例如，***100的商家102、收单方104、支付网络106、发行方108和慈善机构110的每一个都与计算设备200相关联。然而，不应该认为***100及其组件限于计算设备200，这是因为可以使用不同的计算设备和/或计算设备的不同布置。另外，在其他计算设备中可以使用不同组件和/或组件的不同布置。另外，在各种示例性实施例中，计算设备200可以包括位置紧邻的或分布在地理区域上的多个计算设备。另外，每个计算设备200都可以耦接到网络(例如，因特网、内联网、专用或公共LAN、WAN、移动网络、电信网络、及其组合、或其他合适的网络等)，所述网络是网络112的一部分或者是与网络112分离的网络。

通过示例，示例性计算设备200可以包括一个或多个服务器、个人计算机、膝上型计算机、平板电脑、PDA、电话(例如，蜂窝电话、智能电话、其他电话等)，销售点(POS)终端、及其组合等，视情况而定。

参考图2，所示的计算设备200包括处理器202和耦接到处理器202的存储器204。处理器202可以包括但不限于一个或多个处理单元(例如，多核配置等)，包括通用中央处理单元(CPU)、微控制器、精简指令集计算机(RISC)处理器、专用集成电路(ASIC)、可编程逻辑电路(PLC)、门阵列和/或能够具有本文所述功能的任何其他电路或处理器。上述示例仅是示例性的，因此不旨在以任何方式限制处理器的定义和/或含义。

如本文所述的存储器204是允许对诸如可执行指令和/或其他数据的信息被进行存储和检索的一个或多个设备。存储器204可以包括一个或多个计算机可读介质，例如但不限于动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)、固态设备、闪存驱动器、CD-ROM、指状驱动器、磁带、闪存驱动器、硬盘和/或任何其他类型的易失性或非易失性物理或有形计算机可读介质。存储器204可以被配置为存储不限于用户偏好、条件、消费者注册、慈善商家标识符、交易数据和/或适用于如本文所描述的其他类型的数据等。

另外，在各种实施例中，计算机可执行指令可以存储在存储器204中以供处理器202执行，以使处理器202执行本文所述的一个或多个功能，这样存储器204是物理的、有形的和非暂时的计算机可读介质。应当理解，存储器204可以包括各种不同的存储器，每个存储器都以本文所描述的一个或多个功能或过程来实现。

在示例性实施例中，计算设备200包括耦接到处理器202的呈现单元206。呈现单元206例如通过显示、可听、和/或以其他方式输出例如但不限于消费者数据、交易数据、商家数据，商品和/或服务数据，慈善数据、和/或任何其他类型的数据的信息，向用户(例如，***100中的消费者114、***100中的与慈善机构110相关联的个人等)输出或呈现信息。应当进一步理解，在一些实施例中，呈现单元206包括显示设备，以使得可以在计算设备200，特别是在显示设备显示各种界面(例如，应用、网页等)，以显示该信息和数据等。在一些示例中，计算设备200可以使得在另一计算设备(包括例如经营具有多个网页的网站的服务器等)的显示设备上显示界面。呈现单元206可以包括但不限于液晶显示器(LCD)、发光二极管(LED)显示器、有机LED(OLED)显示器、“电子墨水”显示器、扬声器、及其组合等。在一些实施例中，呈现单元206包括多个单元。

计算设备200还包括从用户接收输入的输入设备208。输入设备208耦接到处理器202，并且可以包括例如键盘、指示设备、鼠标、触笔、触敏面板(例如，触摸板或触摸屏等)、另一个计算设备和/或音频输入设备。另外，在一些示例性实施例中，诸如包括在平板电脑、智能电话或类似设备中的触摸屏表现为呈现单元206和输入设备208两者。在至少一个示例性实施例中，省略了呈现单元和输入设备。

另外，所示的计算设备200包括耦接到处理器202(以及在一些实施例中，也耦接到存储器204)的网络接口210。网络接口210可以包括但不限于有线网络适配器、无线网络适配器、移动电信适配器或能够与一个或多个不同网络(包括网络112)通信的其他设备。在一些示例性实施例中，计算设备200包括处理器202和并入处理器202中或与处理器202合并的一个或多个网络接口。

再次参考图1，通常在所示的***100中，商家102、收单方104、支付网络106和发行方108响应于来自消费者114的请求而协同工作以完成使用支付账户进行的产品和/或服务的支付交易。作为支付交易的一部分，消费者114首先向商家102提供有关支付账户的信息(例如，通过支付卡、其他支付设备(例如，船上交货、智能手机等)的支付账号等，或者通过以前建立的购买账户(例如，诸如MasterPassTM、谷歌钱包、闪付(PayPass)、等的电子钱包)的登录凭证等)。商家102读取支付账户信息，并通过网络112经由收单方104(与商家102相关联)向支付网络106传送授权请求，以处理该交易(例如，使用交换，等)。授权请求包括交易的各种细节(例如，交易数据等)以有助于处理授权请求。支付网络106又将授权请求传送给发行方108(与消费者的支付账户相关联)。然后，发行方108向支付网络106提供授权响应(例如，授权或拒绝该请求)，通过收单方104将该授权响应返给商家102。随后由商家102完成与消费者114的交易。根据授权响应，交易被批准或拒绝。

作为商家102、收单方104、支付网络106、发行方108和消费者114之间的上述交互的一部分，生成交易数据。根据交易，通过支付网络106将交易数据从商家102发送到发行方108(例如，作为授权请求的一部分，作为单独请求的一部分等)。交易数据可以包括但不限于消费者支付账户的支付账号、交易的支付金额、在交易中购买的(多个)产品和/或(多个)服务的(多个)标识符、在交易中购买的(多个)产品和/或(多个)服务的(多个)说明、在交易中购买的(多个)产品和/或(多个)服务的列表、商家102的商家名称、商家102的商家标识码(MID)、商家102的商家类别码(MCC)、交易的日期和/或时间、交易金额等。

涉及消费者114、商家102、其他的消费者114、***100包括但未示出的其他消费者、以及***100包括但未示出的其他商家的***100中的其他支付交易也以与消费者114和商家102之间的上述支付交易相似的方式进行处理。也可以结合这些支付交易生成交易数据。

一旦生成交易数据，交易数据就可以存储在***100的一个或多个不同组件中。在示出的实施例中，例如，支付网络106收集交易数据并将其存储在数据结构118中。这样，数据结构118就包括由支付网络106处理的支付交易所涉及的消费者和商家的汇编以及支付交易的相应交易数据。对于消费者114和商家102之间的上述交易(以及***100中的各种其他交易)来说，根据与消费者114、商家102(例如，商家102的MID、商户102的MCC，等等)相关联的一个或多个支付账户、或任何其他标准，将交易数据存储在数据结构118中，以使得可以如本文所描述的容易地使用交易数据。应当理解，可以收集相同或不同的交易数据并将其存储在***100的其他组件内。另外，虽然将数据结构118示出为与***100中的支付网络106分开，但是应当理解，在各种实现方式中，数据结构118可以包括在支付网络计算设备200的存储器204中。

在各种示例性实施例中，本文中的不同交易所涉及的消费者例如在注册他们的账户期间等同意与他们的支付账户相关联的法律条款。这样做，消费者可以同意例如允许商家、支付账户的发行方、支付网络等使用在注册期间收集的数据和/或收集的与处理交易相关的数据，随后用于本文描述的一个或多个不同目的。

进一步参考图1，慈善机构110包括消费者114可以向其捐款的任何组织或团体(或任何多个组织或团体)。不限于此，慈善机构110可以与特定宗教、各种政治活动、一个或多个受益人、或消费者114可以向其捐款的任何其他类别的个人或实体相关联。

如本文所述，在***100中，慈善机构110经营网站(直接地或通过第三方，诸如通过支付网络106或其他方等)，以便传播关于慈善机构和/或注册消费者114的信息以向慈善机构110捐赠。另外或替代地，应用程序可以由慈善机构110(直接地或通过诸如支付网络106或其他方等的第三方)提供给消费者114(例如，通过网站、通过其他手段等)，其功能与本文所述的慈善机构的网站基本一致。

在注册消费者114时，慈善机构110，特别是与慈善机构110相关联的网站，向消费者114显示不同的界面(例如，在与消费者114相关联的计算设备的呈现单元处，等等。)。作为示例，在注册消费者114时，可以通过慈善机构的网站显示的界面从消费者114征求(不限于)关于消费者114的各种信息(例如，人口统计等)、消费者114的联系信息、消费者114的支付账户信息(例如，账号、到期日、安全代码等)、消费者114的捐赠条件和/或用户偏好(如下所述)、来自消费者114的合适的授权、选择和/或批准，以允许/禁止捐赠等。然后，消费者114可以通过界面设置捐赠数额、每个交易的捐赠数额、每个时间间隔的捐赠限额和每个交易的捐赠百分比中的一个或多个。其他标准(例如，其他资格标准、由于各种原因排除某些活动的基本级别标准等)也可以(或替代地)包括在界面中，例如(但不限于)具有或不具有捐赠资格的交易类型(例如，通过交易金额、通过MCC、通过交易时间/日期、通过交易阈值、通过交易是否涉及商业活动、通过交易是否涉及慈善交易、通过生命周期数据(例如，拒付数据等)等)、和/或与消费者的捐赠的金额、频率、时间等有关的其他条件。这些标准通常将由支付网络106确定。然而，应当理解，在一些实施例中，标准(或其他)也可以(或者可选的)由消费者114设置和/或修改(例如，通过界面等)。

另外，在慈善机构110(或在不同的时间)注册时，消费者114还可以将关于向消费者114或向一个或多个第三方报告关于消费者的捐赠、以及注册的条款和条件的报告设置为偏好。在各种实施例中，慈善机构的网站(或应用程序)进一步允许消费者114选择捐赠应提交给的慈善机构110的特定部分/目标，甚至允许消费者114选择消费者的捐赠将被指定的不同慈善机构。网站(或应用程序)还可以要求消费者114在注册之前或在对注册期间提供的任何信息或条件进行更改之前登录。例如，在***100中，在允许消费者114无限期地禁用任何捐赠(即，结束捐赠)或在指定的时间段禁用任何捐赠(即，暂停捐赠)之前要求登录。

虽然在前面的描述中，将慈善机构110描述为对消费者114进行注册，但是应当理解，支付网络106或其他实体也可以(或替代地)对消费者114进行注册。这可以通过与慈善机构110相配合来完成，或者可以独立于慈善机构110(但仍代表慈善机构)完成。

图3示出了可以由慈善机构110或另一实体(例如，与对消费者114进行注册相结合等)通过网站(或应用程序)向***100中的消费者114提供的示例性界面300。如图所示，刚一呈现给消费者114，界面300就征求消费者114的名称302、与消费者114相关联的并且与向慈善机构110捐赠结合使用的支付账户的账号304、来自与消费者的支付账户相关联的支付设备的CVC代码306(或其他安全代码)、以及各种捐赠条件308。在界面300中，支付条件308包括两个一般选项：消费者114将要针对特定期望数量的交易作出的期望的捐赠数额的指示310、以及消费者114将要为每个交易(不管交易数量)作出的期望的捐赠数额的指示312。如果需要，界面300中的支付条件308然后还允许消费者114输入消费者114每月(或其他时间周期)进行捐赠的限额(或最多捐赠)的指示314。另外，界面300包括要由消费者114选择的指示符316，其提供对注册的任何条款和条件的同意/批准。

再次参考图1，慈善机构110可以在无需与支付网络106进行交互的情况下管理消费者114的注册及其支付账户。或者，慈善机构的网站可以通过应用程序界面(API)与支付网络106或支付网络106的一部分进行通信，由此在注册期间由消费者114提供的信息被提供给支付网络106。或者，支付网络106(或另一个实体)可以管理消费者114的注册，然后将该注册传送给慈善机构110。

无论消费者114如何注册，都例如由慈善机构110(例如，由与慈善机构110相关联的计算设备200等)、由支付网络106(例如，由与支付网络106相关联的计算设备200等)将关于消费者114及其支付账户的信息提供给捐赠引擎120。在所示的***100中，捐赠引擎120与计算设备200相关联，并且被并入到支付网络106(如图1中的虚线所示)中。然而，应当理解，在其他实施例中，捐赠引擎120可以是***100中的单独实体(并且可以经由网络112与慈善机构110和/或支付网络106通信)，或者捐赠引擎120可以并入***100中所示的其他实体(例如，发行方108等)中或***100中未示出的其他实体中。

通常利用计算机可读指令将捐赠引擎120配置为除了本文描述的其他功能之外，还可以部分地基于消费者114向其注册的支付账户进行的交易生成向慈善机构110(或其他慈善机构)的捐赠。特别的，对于每个消费者114来说，捐赠引擎120识别向消费者的支付账户的交易，并基于一个或多个预定条件(例如，基于相应的消费者114在注册期间设置的一个或多个用户偏好、基于支付网络106设置的标准、它们的组合，等)生成针对该交易的捐赠指示符114。接下来，捐赠引擎120以预定的时间间隔(例如，第三间隔、一个月间隔、两周间隔等)汇总捐赠指示符。然后，捐赠引擎120基于汇总的捐赠指示符，以向慈善机构110捐赠(广义上来说，支付)的形式生成对消费者的支付账户进行的交易，并将交易提交给收单方104(其也与***100中的慈善机构110相关联)。通常，捐赠引擎120创建包括以预定的时间间隔(例如，来自多个消费者114等)向慈善机构110进行的多个基于捐赠的交易的批处理文件，并将该批处理文件提交给收单方104。一旦接收到该批处理文件，就以与上文描述的消费者114和商家102之间的支付交易基本上一致的方式对该交易(或者批处理文件中的多个交易)进行处理。将任何被拒绝的交易或交易的其他问题返回给支付网络106(代表商家102运作)，以允许根据需要进行额外的尝试，并且保持一致的报告，和/或返回给慈善机构110和/或返回给捐赠引擎120，或者经由警告或通过常规的和/或定期的报告来向消费者114报告该任何被拒绝的交易或交易的其他问题。

应当理解，捐赠引擎120生成的基于捐赠的交易的金额、时间和/或其他方面可以基于消费者114、收单方104、慈善机构110、支付网络106和/或捐赠引擎120设置的条件。

图4示出了基于消费者向与消费者相关联的支付账户的交易生成捐赠的示例性方法400。本文结合***100描述了示例性方法400，并且该示例性方法400可以在支付网络106(例如，与支付网络106相关联的捐赠引擎120等)和***100的发行方108中的任何一个或多个中实现，其中的每一个均包括如上所述的一个或多个计算设备。另外，为了说明的目的，还参考计算设备200描述了示例性方法400。应当理解，方法400或本文描述的其他方法不限于***100或计算设备200。并且反过来，本文描述的***和计算设备不限于示例性方法400。

如图4所示，在方法400中，在402，捐赠引擎120例如从慈善机构110或在其他实施例中从与慈善机构110分离的支付网络106的各个部分接收消费者114和与消费者相关联的支付账户的注册。该注册包括消费者114的支付账户信息以及由消费者114选择或定义的与代表消费者114进行捐赠有关的用户偏好和/或捐赠条件。在一些实施例中，捐赠引擎120还在此时通过向收单方104提交名义金额(例如，$0，另一名义金额等)的测试交易(或验证交易)来验证消费者的注册。测试交易允许捐赠引擎120在注册期间确认消费者114提供的信息的准确性(例如，支付账户信息等)，并且确认要提交给收单方104的交易的格式等(例如，以有助于确保正确处理后续交易等)。另外，在一些实施例中，注册可以包括单个消费者的注册。而在其他实施例中，注册可以包括多个消费者的大批注册。

一旦消费者114向慈善机构110注册并且捐赠引擎120已经接收到消费者的注册，捐赠引擎120就在404开始监视用于交易消费者的支付账户。这样做时，捐赠引擎120通常基于预定的时间间隔(例如，连续的、周期性的(例如，每天一次、每两天一次、每周一次等)等)检查用于交易的支付账户。

结合对消费者的支付账户监视，捐赠引擎120在406识别消费者在预定的时间间隔期间向支付账户进行的所有交易。然后，当识别出交易时，例如基于预定的时间间隔在支付账户内分离识别出的交易。或者，当识别出交易时，可以从支付账户提取识别出的交易，并将其存储在与支付网络106相关联的数据结构中(例如，支付网络计算设备200的存储器204内等)，并且基于预定的时间间隔在该数据结构中分离该识别出的交易。

对于每个识别出的交易，捐赠引擎120在408确定交易是否满足消费者114在注册期间指定的各种预定的捐赠条件(即，交易必须满足的条件，为了将其用作捐赠给慈善机构110的基准)。当交易满足消费者的捐赠条件时，捐赠引擎120在410将该交易追加到与预定时间间隔相关联的捐赠单，在该预定时间间隔识别出交易。然而，当交易不满足消费者的捐赠条件时，捐赠引擎120在412排除该交易。应当理解，消费者114可以根据需要在任何时间设置和/或随后改变/修改消费者的捐赠条件(例如，通过与慈善机构110相关联的网站；通过与支付网络106相关联的网站，消费者114可以通过该网站访问他/她的支付账户；等)。

接下来，基于消费者114指定的捐赠条件，捐赠引擎120在413确定在预定时间间隔期间追加到捐赠单的每个交易的捐赠值。然后将捐赠值和从中确定该捐赠值的交易包含在捐赠单中。作为示例，当消费者114在注册期间设置每个交易捐赠$0.05的条件时，对于在预定的时间间隔期间识别出的每个交易，捐赠引擎120都在捐赠单中包括$0.05捐赠值(其也满足消费者114在注册期间设置的任何其他条件)。

应当理解，捐赠引擎120基于消费者114在注册期间设置的条件来生成交易的捐赠值。在某些方面，条件决定要包括哪些交易以及要排除哪些交易。在其他方面，条件确定交易的捐赠值。例如，捐赠引擎120可以基于参与交易的特定商家或者参与交易的商家的类型，考虑到MCC等，将消费者114向消费者支付账户进行的交易包括在内或将其排除，以用作确定交易的捐赠值的基准。在另一个例子中，可以基于交易的金额对交易的捐赠值进行限制(例如，只有交易超过$5.00时才确定捐赠值，等)，可以基于在预定的时间间隔内已经汇总的总捐赠值对交易的捐赠值进行限制(例如，可以在每个时间间隔将总捐赠值限制为$15.00，等)，可以基于交易的时间/日期、和/或在预定的时间间隔内识别出的交易的总数对交易的捐赠值进行限制(例如，可以仅针对每个预定时间间隔内进行的十个交易确定捐赠值等)等。在另外的示例中，消费者114设置的其他条件可以涉及消费者向支付账户进行的交易、消费者114或交易的其他方面。

在一些实施例中，捐赠引擎120可以根据消费者114指定的一个或多个条件(例如，用户偏好等)将捐赠引擎120确定的捐赠值分配给不同的慈善机构。例如，消费者114可以在注册时或者在注册之后设置如下条件：将涉及针对具有特定MCC(例如，航空公司等)的商家的交易的捐赠值分配给第一慈善机构，而将针对所有其他交易的捐赠值分配给第二个不同的慈善机构。作为另一个例子，消费者114可以在注册时或者在注册之后设置如下条件：将针对涉及第一支付账户的交易的捐赠值分配给第一慈善机构，而将针对所有其他支付账户的捐赠值分配给第二个不同的慈善机构。应当理解，慈善机构110和/或捐赠引擎120可以不仅为不同的支付账户允许各种不同的捐赠条件，而且还可以为单个支付账户允许各种不同的捐赠条件。

还应当理解，当在方法400中最初生成捐赠单时(例如，当以预定的时间间隔将第一交易追加到捐赠单时等)，捐赠引擎120对捐赠单进行存储(例如，将其存储到与捐赠引擎120相关联的计算设备200的存储器204中、将其存储到与支付网络106相关联的计算设备200的存储器204中等)。然后可以在预定的时间间隔期间更新捐赠单，以在该时间间隔期间识别出额外的交易时(并且当确定它们满足消费者的各种预定条件时)将其包括在捐赠单中。在一些实施例中，消费者114可以通过与慈善机构110相关联的网站查看捐赠单。慈善机构的网站可以提供指示板，其包括对交易的记账、捐赠标记、捐赠总额等。另外，对于已注册的消费者114，在预定的时间间隔结束时，通过支付网络106中的消费者支付账户发布符合资格(例如，满足各种预定条件的捐赠等)的活动。如本文所述，还可以向慈善机构提供反馈。在其他实施例中，消费者可以通过与支付网络106相关联的网站或者发行方108查看捐赠单(例如，消费者114可以通过其查看他/她的支付账户的细节的账户网站，其中，该账户网站可以直接包括捐赠单，或者该账户网站通过应用程序界面(API)呼叫慈善机构的网站以允许消费者查看捐赠单等)。

继续参考图4，在414，捐赠引擎120确定预定的时间间隔是否期满。如果时间间隔未期满，则捐赠引擎120在预定的时间间隔的剩余持续时间内继续执行操作406-413。然而，一旦预定的时间间隔期满(或完成)，捐赠引擎120就在416汇总在该给定的时间间隔内捐赠单中包括的捐赠值。更一般的，捐赠引擎120计算在预定的时间间隔由支付账户出资捐赠给慈善机构110的捐赠值的总和。另外，在捐赠周期(例如，如由消费者114、慈善机构110等确定的周期(例如，一个月等)等，在该周期内，在将捐赠值发送给慈善机构110之前对捐赠值进行收集)内将汇总的捐赠值存储在捐赠引擎计算设备200的存储器204中。如果在存储器204中还存在未处理的其他捐赠值，则在给定的捐赠周期内，在416也对所有未处理的捐赠值进行汇总，直到捐赠周期期满(或完成)为止。

接下来，捐赠引擎120在418确定在捐赠周期内汇总的捐赠值是否超过了如消费者114在注册期间或者在注册之后提供的捐赠限额(例如，每月$20.00等等)。当汇总的捐赠值超过限额时，捐赠引擎120就在420将捐赠值减少到指定的捐赠限额(并且从而将向慈善机构110的捐赠限制为消费者114指定的最大金额)。在一些实施例中，消费者114可以不设置捐赠限制条件，从而可以省略在420的限制捐赠的操作。

在一些实施例中，慈善机构110、消费者114、捐赠引擎120或另一个实体可以指定在捐赠值将要被发送给慈善机构110之前必须满足的最少交易阈值(例如，最少汇总捐赠值等)。当汇总的捐赠值小于阈值时，则捐赠引擎120保持捐赠值直到下一个捐赠周期期满。如果此时合并的两个捐赠周期的汇总捐赠值超过阈值，则捐赠引擎120进行如下操作(否则，可以保持合并的汇总捐赠值，直到下一个捐赠周期期满，依此类推)。

在任何情况下，在420减少汇总的捐赠值之后，或者相反地，如果汇总的捐赠值没有超过捐赠限额(或者，如果不存在捐赠限额)，则捐赠引擎120在422向收单方104提交捐赠交易，以向慈善机构110支付汇总的捐赠值。然后，以与上文描述的***100中的消费者114和商家102之间的支付交易基本上一致的方式，对捐赠交易进行处理。

方法400中的每个捐赠交易都包括与慈善机构110相关联的商家标识符(“ID”)，就好像慈善机构是发起交易的商家。以这种方式，当结算和清算了捐赠交易时，将从合适的消费者支付账户的发行方108转移的资金提供给与慈善机构110相关联的支付账户。或者，如果捐赠交易被拒绝，则收单方104将交易返回到捐赠引擎120，并且捐赠引擎120保持交易，直到下一个捐赠周期期满。此时，捐赠引擎120提交包括被拒绝的汇总捐赠值加上下一个周期的任何额外捐赠值(例如，如果没有超过捐赠限额)的另一个交易。

由于在方法400以及在此之前中完成了捐赠交易，所以捐赠引擎120可以将捐赠值、捐赠交易和与上述相关的其他信息存储在计算设备200的存储器204中。该信息可供慈善机构110访问，或者通过慈善机构的网站(或应用程序)允许慈善机构110查看和/或传播有关收到的捐赠的某些信息，或允许消费者114检查对慈善机构110和/或消费者的相关联的支付账户的交易和捐赠细节。在各种实施例中，指示板可由慈善机构110查看(例如，由慈善机构110或由捐赠引擎120等经营)，其提供例如每个时间段的捐赠、注册的消费者/捐赠者的总数、捐赠总额、总捐赠交易、每个消费者的平均捐赠等的概要。类似地，在各种实施例中，可以通过慈善机构的网站向消费者114提供指示板，由此消费者114能够查看例如历史捐赠、交易、目标和/或预期捐赠的描述、和/或与被拒绝的交易、捐赠、交易、目标等有关的报告。

应当理解，捐赠交易可以由捐赠引擎120单独提交、或者作为批处理文件的一部分与要由收单方104处理的其他捐赠交易一起提交。例如，如果多个消费者114都选择将其支付账户与慈善机构110相关联，则可以在每个捐赠周期向慈善机构110提交用于支付的多个捐赠交易。因此，在此，捐赠引擎120可以将捐赠交易一起进行批处理并将它们(同时)一起提交给收单方104。在所示的实施例中，对于每个支付账户并且在每个捐赠周期，向慈善机构110进行单个捐赠交易(只要满足捐赠交易的各个预定条件)。然而，应当理解，在其他实施例中，对于每个支付账户和/或在每个捐赠周期，可以向慈善机构110和/或其他慈善机构进行多个捐赠交易。还应当理解，在其他实施例中，对于每个支付账户和/或在每个捐赠周期，可以向慈善机构110进行多个捐赠交易。

还应当理解，尽管在方法400中参考一个支付账户描述了捐赠引擎120，但是捐赠引擎120可以针对多个支付账户、多个消费者和/或多个慈善机构执行方法400。

如前所述，在一些实施例中，消费者114的注册可以单独完成，以使得每个注册都包括单个个体消费者的注册。而在其他实施例中，消费者114的注册可以大批或批量的进行，以使得每个注册都包括多个消费者的注册(消费者只需消耗很少或最小的精力)。

例如，关于个人注册，消费者114可以被发行方108通过URL引导到慈善机构110的捐赠平台(例如，先前讨论过的网站等)。例如，可以通过发行方的家庭银行网站等将该URL显示给消费者114，并且可以根据需要由发行方108向消费者114介绍向慈善机构110进行捐赠的提议(例如，经由银行网站上的或通过邮件的营销、经由银行网站上的或通过邮件的广告等方式)。在捐赠平台上，消费者114可以在个人的基础上进行注册，例如，通过选择捐赠平台上的注册按钮，并随后输入与其个人注册有关的各种细节(例如，诸如姓名、地址等的个人识别数据；用户名和密码；安全问题的答案；捐赠参数等)。一旦注册，消费者114然后就可以访问(例如，登录等)捐赠平台上的个人指示板以管理他们的捐赠(例如，监视捐赠、改变他们在注册时或注册后设置的捐赠参数等)。

作为另一个例子，并且再次针对个人注册，当发行方108向消费者114发行支付设备时，消费者114可以接触到向慈善机构110捐赠的提议。在此，例如，发行给消费者114的特定支付设备(或者可由消费者114选择)可以各自包括独特的卖点或特征，这是因为对支付设备的某些使用会触发向慈善机构110的捐赠。在该实施方式中，消费者114在收到支付设备后，再次主动注册，并随后设置他们的捐赠偏好。

作为进一步的示例，对于消费者114的批量注册来说，当向消费者114发行支付设备(例如，作为发行过程的一部分等)时，发行方108可以从对向慈善机构110捐赠表示出兴趣的每个消费者114获得初始注册数据然后，发行方108将收集的消费者114的注册数据发送(例如，通过网络112等)给支付网络106以进行正式注册。因此，在该实施方式中，在将支付设备发行给消费者114时，消费者114将其意图和意愿发送给发行方108以向慈善机构110捐赠，然后发行方108负责收集相关的默认数据来引导消费者114注册(消费者不需要必须访问网站才能实际注册)。一旦注册，消费者114然后就可以访问(例如，登录等)与慈善机构110相关联的捐赠平台上的个人指示板以管理他们的捐赠(例如，监视捐赠、改变他们在注册时或注册后设置的捐赠参数等)。

应当理解，在一些实施例中，本文描述的功能可以在存储在计算机可读介质上并且可由一个或多个处理器执行的计算机可执行指令中描述。计算机可读介质是非暂时的计算机可读介质。作为示例而非限制，该计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储器、磁盘存储器或者其他磁存储设备，或者可以用于携带或存储指令或数据结构的形式的所需的程序代码并且可以由计算机访问的任何其他介质。以上的组合也应包括在计算机可读介质的范围内。

还应当理解，当通用计算设备被配置为执行本文所述的功能、方法和/或过程时，本公开的一个或多个方面将通用计算设备变换为专用计算设备。

如将基于前述说明书所理解的，本公开的上述实施例可以使用包括计算机软件、固件、硬件或其任何组合或子集的计算机编程或工程技术来实现，其中技术效果可以通过执行以下步骤中的至少一个来实现：(a)识别与支付账户相关联的至少一个交易；(b)由计算设备基于所述至少一个交易生成向所述支付账户的捐赠值；(c)由所述计算设备汇总所述至少一个交易的捐赠值；以及(d)向与慈善机构相关联的收单方提交捐赠交易，以至少基于汇总的捐赠值向慈善机构支付金额。

提供了示例性实施例以使得本公开将是全面的，并且将会将本公开的范围完全传达给本领域技术人员。阐述了许多具体细节，例如特定部件、设备和方法的示例，以提供对本公开的实施例的完全理解。对于本领域技术人员来说显而易见的是，不需要采用具体细节，该示例性实施例可以以许多不同的形式实施，并且不应被解释为限制本公开的范围。在一些示例性实施例中，没有详细描述公知的过程、公知的设备结构和公知技术。此外，通过本文公开的一个或多个示例性实施例可以实现的优点和改进可以提供所有上述优点和改进或者不提供上述优点和改进，并且仍然落入本公开的范围内。

本文使用的术语仅用于描述特定示例性实施例的目的，而不是限制性的。如本文所使用的，除非上下文另有明确指示，单数形式“一”、“一个”和“该”也可以包括复数形式。术语“包括”、“包含”、“含有”和“具有”是包容性的，因此指定所述特征、整体、步骤、操作、元件和/或组件的存在，但不排除存在或添加一个或多个其他特征、整体、步骤、操作、元件、组件和/或其组合。除非特别指定为性能的顺序，否则本文所述的方法步骤、过程和操作不应被解释为必须要求它们的性能以所讨论或示出的特定顺序进行。还应当理解，可以采用额外的或替代的步骤。

对实施例的前述描述是为了说明和描述的目的而提供的。不旨在其是穷举的或限制本公开。特定实施例的单个元件或特征通常不限于该特定实施例，即使没有具体示出或描述，但是其在适用的时候是可互换的，并且可以在所选择的实施例中使用。在许多方面也可能有所不同。这些变化不被视为背离本公开，而是旨在将所有这些修包括在本公开的范围内。

Claims (20)

1.一种用于通过向支付账户的交易生成向慈善机构的捐赠的计算机实现的方法，所述方法包括：

识别与支付账户相关联的至少一个交易；

由计算设备基于所述至少一个交易生成向所述支付账户的捐赠值；

由所述计算设备汇总所述至少一个交易的捐赠值；以及

向与所述慈善机构相关联的收单方提交捐赠交易，以至少基于汇总的捐赠值向所述慈善机构支付金额。

2.根据权利要求1所述的方法，其中，生成所述捐赠值还基于与所述至少一个交易相关联的至少一个条件。

3.根据权利要求2所述的方法，其中，所述至少一个条件包括所述至少一个交易的金额和在所述至少一个交易中涉及的商家的商家类别代码中的至少一个。

4.根据权利要求1所述的方法，其中，所述至少一个交易包括在预定的时间间隔内的多个交易，并且其中，汇总所述捐赠值包括：在所述预定的时间间隔之后汇总所述多个交易中的每个交易的捐赠值。

5.根据权利要求1所述的方法，还包括接收所述支付账户的注册，所述注册包括至少一个用户偏好；并且

其中，进一步基于所述至少一个用户偏好生成所述捐赠值。

6.根据权利要求1所述的方法，其中，提交用于支付的捐赠交易包括向所述收单方提交批处理文件，所述批处理文件包括所述捐赠交易以及用于支付给所述慈善机构的多个其他捐赠交易，所述多个其他捐赠交易中的每一个用于从不同的支付账户向所述慈善机构支付。

7.根据权利要求1所述的方法，还包括当汇总的捐赠值所指示的金额超过所述捐赠限额时，将用于向所述慈善机构支付的捐赠交易限制为捐赠限额。

8.根据权利要求1所述的方法，其中，所述支付账户与条件相关联；并且

其中，提交所述捐赠交易包括：

当满足所述条件时，提交所述捐赠交易以向所述慈善机构进行支付；以及

当不满足所述条件时，提交所述的捐赠交易以向不同的慈善机构进行支付。

9.一种用于收取向慈善商家的捐赠的***，所述***包括：

包括多个支付账户的数据结构的存储器，其中，每个所述支付账户与消费者相关联，并且其中，每个所述支付账户连接到至少一个慈善机构；和

至少一个处理器，其耦合到所述存储器并且被配置为：

识别与所述支付账户相关联的交易；

对于每个识别出的交易，向所述识别出的交易针对的支付账户生成捐赠值；

针对每个所述支付账户，汇总每个支付账户的捐赠值；

针对所述捐赠值被指定给的每个慈善机构，生成批处理交易文件；

将所述批处理交易文件提交给与合适的慈善机构相关联的收单方。

10.根据权利要求9所述的***，其中，所述至少一个处理器被配置为基于所述收单方的至少一个参数生成所述批处理交易文件，所述批处理交易文件将要被提交给所述收单方。

11.根据权利要求9所述的***，其中，向至少一个支付账户生成的所述捐赠值基于与相应的交易相关联的至少一个条件。

12.根据权利要求11所述的***，其中，所述至少一个条件包括最少捐赠交易阈值；并且

其中，所述至少一个处理器被配置为当不满足所述最少捐赠交易阈值时，保持捐赠交易直到下一个捐赠周期。

13.根据权利要求11所述的***，其中，所述至少一个条件包括交易中涉及的商家的商家类别代码、交易金额以及每个捐赠值的最少交易数量中的一个。

14.根据权利要求11所述的***，其中，所述至少一个条件包括在时间间隔内的捐赠限额；并且

其中，所述至少一个处理器被配置为当所述交易超过所述捐赠限额时，修改与所述捐赠值中的一个相关联的交易以满足所述捐赠限额。

15.根据权利要求9所述的***，其中，所述至少一个处理器被配置为在预定的时间间隔期间周期性地汇总每个支付账户的捐赠值。

16.一种包括可执行指令的非暂时性计算机可读介质，当至少一个处理器执行所述可执行指令时，所述可执行指令使所述至少一个处理器：

从支付网络识别与被注册为基于至少一个条件向慈善机构进行捐赠交易的支付账户相关联的交易；

为每个识别出的交易生成捐赠值；

汇总生成的捐赠值；以及

向与所述慈善机构相关联的收单方提交捐赠交易，以至少基于汇总的捐赠值向所述慈善机构支付金额。

17.根据权利要求16所述的非暂时性计算机可读介质，其中，所述至少一个条件包括所述交易中涉及的商家的商家类别代码和交易金额中的至少一个。

18.根据权利要求16所述的非暂时计算机可读介质，其中，所述识别出的交易包括在预定时间间隔内的交易。

19.根据权利要求16所述的非暂时性计算机可读介质，其中，提交给所述收单方的所述捐赠交易是提交给所述收单方以向所述慈善机构进行支付的多个其他捐赠交易的批处理文件的一部分，所述多个其他捐赠交易中的每一个用于从被注册为向所述慈善机构进行捐赠交易的不同支付账户向所述慈善机构支付。

20.根据权利要求16所述的非暂时性计算机可读介质，其中，所述至少一个处理器进一步被配置为：当所述汇总的捐赠值指示的金额超过捐赠限额时，将用于向所述慈善机构支付的所述捐赠交易限制为所述捐赠限额。