CN114548962A - 一个独立第n方资金收付平台 - Google Patents

Abstract

本发明公布一个独立第Ｎ方资金收付平台，由一个移动互联网应用及配套客户端构成，用于控制资金收付过程中因信誉缺失而可能发生的风险。相较于这种风险的现有第三方支付解决方案，本平台首先是在使用便利度上的提升，可在大多数应用场景中让用户一言不合就开机使用，通过各自在本平台所注册帐户中的简单操作，自己来实现资金收付过程中的风险控制；另一方面，本平台有更多种类的应用场景，可供用户在一些原来不便甚至无法使用现有第三方支付解决方案的场景中使用，特别地，可由任意数量的用户在同一事项中使用（因此宜称作独立第Ｎ方平台），还可用于促成那些虽然有益、但因在涉及资金收付时参与各方之间缺乏信任而很难或无法实现的事情。

Description

一个独立第N方资金收付平台

技术领域

本发明属于经济和互联网应用技术领域，特别涉及移动互联网在各种涉及资金收付的活动中所能发挥的风险控制作用。

背景技术

第三方支付业务在现今的经济活动中已广泛使用，除了使资金收付更加便捷外（银联，拉卡拉，微信支付等），一个重要的作用是有效控制了买卖双方因货物交付与货款支付的异步和分离而面对的风险，特别是电子商务中因买卖双方不是面对面交易而产生的风险（支付宝，财付通等）。但经济活动中还有其它一些涉及资金收付的风险无法依靠现有第三方支付企业来解决，主要是那些需要一段时间才能完成的交易中的资金收付。在这样的交易中，如果把付款的时间定在卖方的工作完成之后，那么卖方会在付款完成前处于被动地位，其合法利益的获取全由对方掌握；如果付款的时间定在卖方的工作完成之前，那么买方则会在其付款之后、卖方工作完成之前处于不利地位，因有卖方挟款而去的危险，即便不是这种极端情况，卖方也可能在余下的阶段失去了继续按要求标准工作的动力。现在的问题是如何应对这类交易中与支付相关的风险。市场上还有一个办法，就是使用银行的资金监管服务。这是一个手续颇为繁琐、需要双方当事人在同一银行开户、并与银行客户经理一起在很大程度上要以人工方式来设立和操作的过程。如果是家庭之间房产交易这种偶尔为之且涉及一次性大额资金的事情，可以考虑使用；但在很多情况下（见应用举例一节）则因为不方便而显得不太现实。银行的资金监管服务其实是在互联网时代之前就有的第三方支付手段，因为使用场景的广泛，现今依然有其应用价值，并未被后起的基于（移动）互联网的第三方支付平台所取代。但拥有了今天的技术手段再看这项服务，不难发现其中的人工部分几乎全部可以远程自动化实现，实施方仅需提供一个（移动）互联网平台，让用户自己在平台上操作，就能在很多场景中实现资金收付过程中的风险控制，包括但不限于使用银行资金监管所能实现的风险控制。本发明就是这样一个平台的设计方案，可以在大多数情形中方便到能让用户一言不合就开机（手机等）使用的程度，同时在功能上也更为丰富，可以由任意数量的用户在同一涉及资金收付的事项中使用。

发明内容

本发明设计了一个可由任何涉及资金支付事件中的各方利用的、由独立第Ｎ方管控的资金收付和暂存平台，以下简称为本平台，或平台，其具体由一个具有本文下面所述各项功能的移动互联网应用和配套的客户端构成。之所以称之为独立第Ｎ方而非独立第三方，是因为本平台可以由任意数量的用户在同一事项中使用。这个独立第Ｎ方也就是本发明的实施方，下文在强调其对平台的管理作用时，也称其为平台的管理方。实施方要有银行账户或其它具有收付功能的账户与平台绑定，用于与平台用户之间的资金往来。任何具有独立法人地位的个人和组织均可在平台注册成为用户，也就是在平台上开户。如果是为了使用平台的主要功能注册，即，为了能够通过平台与他方进行资金往来，用户需要将其一个银行账户或其它具有收付功能的账户与其在平台注册的账户绑定，并能用于与平台之间的资金往来。这样的绑定对只在平台上起监督作用的注册用户则无必要。另外，组织用户的注册要比个人用户复杂一些，涉及到的更多细节后面再讲，这里只强调，一个独立法人（包括个人）注册申请需要平台管理方核实其有效法人身份信息后方可批准（即，实名制注册）。无论哪一类用户，注册成功后获取在平台具有唯一性的用户ID和对应的用户二维码。这里提到的用户信息，包括用户ID、用户二维码，以及与用户指定银行账户或其它具有支付功能的账户之间的绑定关系等，都以持久化方式存储在平台的关系型数据库中。

用户用以注册、并在注册成功后用以在其平台帐户中操作的客户端，有以下三种：Web客户端，PC客户端，和移动智能通讯设备APP（以下以“手机”代称移动智能通讯设备）。其中的PC客户端适合频繁使用本平台的商家，特别是如果商家有专职人员在固定场所负责处理使用本平台进行的业务。但移动APP无疑对大多数用户更具便利性：任何人在任何时间进行任何交易，可以与对方即时商定使用本平台，并通过互相扫码和几次点击即可完成必要的设置并开始使用。可以讲，本平台的商业和社会价值一定程度上源自于智能手机的普及带来的便利性。三种形式的客户端的工作逻辑是一样的，在以下的说明中一般不予区分，只在移动APP有特别方便之处时做些具体说明。较佳地，无论用户是使用Web客户端，PC客户端、还是移动APP与本平台进行交互，在技术实现上都采用基于域名解析系统（DNS系统）和标准的网络分层协议（如HTTP协议、TCP/IP协议等）与平台进行交互操作，即，DNS系统负责解析用户所访问域名对应的IP地址，通过IP地址路由访问平台的服务器，访问过程中网络协议负责用户与平台之间的数据传输。

先以最简单的应用场景来解释平台基本工作原理。假设现有两方欲直接（而不是在电子商务平台上）进行一项需要一段时间才能完成的交易，但发现无论交易款在哪个时间点支付，总会对一方造成风险。假设双方此前都成为本平台注册用户，现在决定使用平台解决所面临的问题。这样决定后，买方先把交易款付给平台，在交易完成之前暂存于平台，交易款最终无论是转付给卖方，或是退还给买方，或是部分转付给卖方、部分退还给买方，均需要双方的同意才能在平台上得以执行。现在看双方的风险是否已基本消除。此前，买方的风险是付款后卖方可能不继续完成其工作，或不按质量要求完成其工作。现在，因为卖方知道必须有买方的同意才能收到交易款，在交易完成前的整个过程中，卖方始终没有失去按质量要求去完成其工作的动力。所以买方的风险基本消除。同时买方也知道这一点，所以无须在交易过程中担心。再看卖方，其风险是买方可能利用其在工作完成之后、收款之前所处的被动地位，少付或不付交易款。这一风险也基本消除，因为交易款已经不在买方，没有卖方的同意这笔钱也回不到买方。再看双方因买方认为卖方工作不达标等原因而发生争议的情况。如果不使用本平台或任何第三方支付服务，双方之中注定有一方处于强势（如果尚未支付，这就是买方，如果已经支付，这就是卖方）。这一方很难有解决争议的诚意，会导致争议很难得到公正的解决。如果使用了本平台，付入平台的交易款如何在买方和卖方之间分配，必须在获得双方的同意之后才能执行，双方都会有达成协议的意愿，争议会容易解决得多，解决的方案也会公平得多。注意，这里所述的解决方式并不是向当事人提供像银行资金监管那样的服务，而是为社会提供一个能让所有类似事件的当事人用以自己解决问题的移动互联网平台（这里强调的是“自己”二字）。后者较之前者显然更为方便，比如，当事人不必是同一银行的客户，不必通过银行客户经理来设立服务并在其中操作。这还仅仅是就这里所述的最简单的应用场景而言，平台的优势还体现在功能的多样，能应用于更为复杂的场景（详见下文）。

下面讲本发明的各项细节设计。首先，平台所处理的收付款是具体一个“事项”中的收付款。这里用“事项”而非“交易”是考虑到平台的应用可超出“交易”二字通常所指的范围（见应用举例一节）。用户要使用平台服务必须先通过其平台账户建立或加入一个事项，用户在平台上的收付款操作一定是在其参与的某个事项中的操作。以“事项”为基本工作单元是本平台最为根本的一项设计，本平台的其它各项设计绝大多数是建立在其基础之上的，在这一点上有别于包括银行资金监管在内的各现有第三方支付解决方案。这一设计的主要优点是用户可以自己为事项中的资金收付设置规则（这里强调的仍是“自己”二字）。这个看似简单的设计实际上决定了本平台在应用场景上可以达到几乎没有什么限制的程度。

用户可在本平台上建立的事项分为两种，分别称为“普通事项”和“有发起人事项”。前者适合参与者确定且人数不多（至多四、五个）的情形，其主要特征是所有参与者在事项中的地位对等，甚至无需区分谁是买方谁是卖方，具体讲就是在事项中没有特别设置的情况下，每个参与者在事项中可以进行的操作完全一样，而事项中的任何设置必须由全体参与者同意才能生效。后一种顾名思义就是需要有发起人的事项，适合那种参与者众多，或参与者无法在事项建立初期就确定的情形。这类事项需要有一个参与者，即发起人，起组织和协调的作用。无论是哪一种事项，事项的参与者可以是平台的个人用户，也可以是平台的组织用户，但在下文中对组织用户如何在平台上操作做出说明之前，可权且把事项参与者视作来自平台的个人用户。

先讲如何在平台建立普通事项。无论使用哪种与平台交流的方式/软件，平台用户都可在其帐户主页面上看到标识为 [准备建立普通事项] 的操作按钮（中括号 [ ] 中的文字表示操作页面中虚拟操作按钮的标示文字，下同）。点击之后，用户便收到平台系统为准备中的事项所生成一个临时二维图形码或一个临时数字邀请码。在一小段时间内，如十分钟，凡是扫过这个二维码或在其帐户中输入了邀请码的平台用户，包括发出这个二维码/邀请码的用户，会在平台上临时形成一个群。群中每位成员在这小段时间内可在其帐户页面中看到这个群的成员列表，和操作按钮 [确认建立事项]。群中任何人都可点击这个按钮来建立事项。一人点击后，群中其他成员各自帐户页面中的 [确认建立事项] 按钮即变成[确认加入事项]。事项的建立过程随着这小段规定的时间的结束而结束，如果在结束时群中只有一人点击过 [准备建立普通事项] 或 [确认建立事项] 或 [确认加入事项]，事项建立失败（每个事项至少要有两个参与者），如果群中不只一人点击过这三个操作键中的任何一个，事项建立成功，这个刚建立的事项的参与者就是群中那些在规定时间内点击过这三个操作键中任何一个的人。事项建立成功后，平台随之为其生成一个在平台具有唯一性的事项ID。事项参与者可能还需要对事项做一些设置，或是选择做一些设置，下面会详细说明。其中一项可选的设置是由任何一个参与者为事项输入一个名称（不必具有唯一性）。一个事项在建立之后、结束之前将显示在每个参与用户的平台账户主页面里的事项列表中。一个用户可以同时是几个事项的参与者，在其账户中的事项列表中点击任一事项的名称（或ID, 如果没有名称），即可打开这一事项的主页面，并在其中进行相关这一事项的操作。

下面是几点对普通事项的进一步说明：1）一个普通事项的所有参与者在其各自账户中看到的事项页面都一样。这也是这些参与者在事项中的地位对等的表现形式之一。这也意味任何一个参与者在事项中的操作将对所有参与者同步显示，并在同一时间生效。2）在这个共同的事项页面上列有事项的全部参与者，形式可以是，参与者1：张三；参与者2：李四……。这里的名字可以是真名，也可以是昵称，由用户自己选定并可以修改。在事项的参与各方发生纠纷时，平台管理方可以在警方、法院、及仲裁机构的请求下提供任何参与者的真实身份信息。这一点要在注册过程的声明中写明。3）事项的页面上可以开辟文字输入框，用于输入参与者间的协议，类如哪一方在什么日期该做什么。任何一位参与者都可以在事项页面中开辟文字输入框，这个文字输入框会在事项的每个参与者的事项页面中同步显示，并允许每个参与者在其中输入／更改文字，框内的文字变动也对每个参与者同步显示。（或用更简单的方法：一个参与者在其帐户中的事项页面中做出上述有关文字输入的操作后，先要按动 [发送]，才能使其他参与者的事项页面显示出操作的结果。）事项页面同时设有供每位参与者对输入的文字进行确认的按键。假如这是个三方参与的事项，文字输入框的旁边就会有 [待参与者１确认]、 [待参与者2确认]、和 [待参与者3确认] 三个虚拟按键，分别可由这三个参与者在各自的帐户中点击确认。各方确认后，输入框关闭，此前输入其中的文字变成不可更改的显示文字。如果之后某一方想做变动，可以另开这类输入框，并重复上述步骤。这样的文字输入是其所属普通事项中需要在平台的关系型数据库持久化存储的要素之一，以便今后查证。输入文字只关系所属事项的参与各方，旨在使各方的责任更清晰，更容易查证，以减少发生纠纷的几率，与平台管理方无关，这一点需要在注册过程的声明中写明。4）平台应具有一些能增加使用方便性的功能, 如，能使同一普通事项的参与者在平台上互发信息，以在必要时提醒对方按时履行协议。还有，一个参与者在事项中进行操作之后，平台可自动向事项的其他参与者发出通知信息，即，把信息发至这些其他参与者各自的平台账户，待其查看。较佳地，移动APP在手机桌面上的图标可以某种形式的视觉变化在一个用户有未读信息时提醒其查看。这需要移动APP采用“推”或“拉”的方式获取服务端未读消息数据（如未读消息数量等），再调用系统层SDK接口实现。所需的用户ID与其所用手机IMEI之间的绑定可由APP在第一次从手机上被用来登录平台帐户时建立，并发送给平台。

上面第三点所讲的事项中的文字输入是个看似简单，却非常有价值的功能，这里关于其使用做些补充。首先注意，在平台上建立一个事项并不意味着一定要在事项内发生资金收付，这也就意味着平台用户可以仅仅为了使用这个文字输入功能而在平台上建立事项。经济活动中有很多这样的情形，虽然没有（或还没有）签订正规合同，但最好有一些字据为证。平台用户遇到这种情况正好可以利用事项中的文字输入来应对。很多情况下，仅仅留有某人说过什么话的某种证据就能在很大程度上避免或解决纠纷。请公证机关做见证是个办法，但不方便。特别是在公证门槛过高，很多情况下难以使用。本平台采用实名注册，为平台事项输入的文字又经过当事人的确认，还不会遗失，且查证方便，正好可以弥补经济活动中公证难的问题。即使在原本会有正规合同的事项中，参与各方也可考虑使用平台事项中的文字输入来代替纸质合同，这样就不必担心合同丢失，而且在有不可预计情况发生时，还可以按上段所讲的方法在平台帐户中很方便地对原合同进行修正或补充。

下面具体讲有两个参与者的普通事项。这是用得最多的，同时也是最简单的一种。以上面所述的方式建立起这样的事项后，无需再做任何设置便可使用。平台的使用便利性在这种事项中最能体现出来。在使用过程中，当参与者中的一方在事项中向平台转入资金时，除平台给另一方的通知信息外，无需任何一方的任何其他动作。事项中由平台向参与者支付资金只须遵循一简单规则：向参与者中任何一方支付必需经过另一方的同意，这也就等于要由双方同意。具体到操作上就是，参与者1只能在事项的页面中使用由平台向参与者2的支付操作，操作时可选择支付事项中的全部余款，或输入部分款项并支付。两方换位同理。当事项中的资金全部付出后，任何一方可选择关闭事项。该事项则成为历史，即，显示在每个参与用户账户中的历史页面中的一项不可更改、只可查阅的记录。如果双方预期未来还有资金往来，并愿意使用同一事项进行支付，也可以不关闭事项，留下次再用。在事项结束前双方发生争议的情况下，上述操作同样适用。举例讲，假如双方在事项尚有100元未付出余额时发生纠纷，商谈或其他方式处理纠纷的结果是：参与者1和2分获其中的60元和40元。按上述方法执行就是由参与者1操作付40元给参与者2和由参与者2操作付60元给参与者1。但执行纠纷处理结果一个明显更好的方式是，在事项页面中点击[余款分配]或[关闭事项]，只要事项中尚有余款，页面就会先请求输入付给双方各自的金额，再请求双方确认。双方都确认后，向双方的支付在平台上同时执行。

下面具体讲有三个或以上参与者的普通事项。这种普通事项与上面所讲的有一处不同，就是参与者在使用前必须要完成事项中的一项设置。这是个只需平均每人一两次点击就能完成的设置，几乎不会影响平台的使用便利程度，却能使平台在功能上有很大提高。这个必须要做的设置就是付款规则，具体指，平台向参与者中的任何一方付款，需要其他哪几方的同意。举例讲，假设事项有三位参与者，事项建立后，事项页面随即显示图１所示的操作项供参与各方商议后勾选，然后确认。全部确认后，事项即可开始使用。假如三方确认的是，向参与者1付款只需要参与者2一方同意，而向参与者2付款，需要参与者1和3两方同意。在事项的进程中向参与者1的付款由参与者2操作后即可在平台上执行。向参与者2的付款，可由参与者1和3任何一方操作，但只有当另外一方也确认后，付款操作才会在平台上执行。以这样的方式设置付款规则对绝大多数有多个参与者的普通事项应该是够用了，为了能够应对特殊复杂的场景，在设计上可以增加付款规则的高级设置方式供选择，具体讲就是允许事项参与者为不同的时段设置不同的付款规则，包括为事项结束时的余款分配单独设置付款规则。在事项无法按预期完成或参与各方发生争议的情况下，如果没有单独为余款分配设置付款规则，最后解决方案的余款分配也是按既定的付款规则来进行，并在余款分配完毕后由任何一方结束事项。但这个过程会因参与用户的增多而愈发复杂。所以，在设计上可以给余款分配定下这样一个省缺替代方案：在事项中尚有余款时点击[余款分配]或[关闭事项]，事项页面会要求输入分配给每个参与者的金额，并要求全部参与者确认。全部确认后，分配方案执行，然后事项结束。

下面讲另外一种事项，即，有发起人的事项。这种事项适合那种参与人数众多，且参与人数未必确定的活动，这类活动需要有人组织和协调，此人便可作为发起人建立一个这类事项，然后利用本平台更方便地进行组织和协调，并能因此减低所有参与者的风险，使活动更易成功。对发起人以外的参与者来说，参与这类事项的便利程度与参与普通事项大致相当，而且在一般情况下还胜于后者；只有发起人这一个参与者需要在事项的建立过程中对事项做多项设置。正是因为发起人可以为这类事项做多项设置，本平台的功能得以进一步（在普通事项的各项功能之外）提高，可以用于完成更多的虽然对各方有益、但却因相互间缺乏信任而无法办成的事情（见下文中的应用举例5），或是那些先要投入大量时间和资金建立起像水滴筹那样的专项平台之后才能办成的事情。与本平台功能提高后所能完成的事情相比，或是与用其它方法来完成同样事情所需要的付出相比，发起人对事项的设置工作显然还是相当轻松和方便的。

建立有发起人事项的按键置于每个用户的平台账户页面中，并以类如“作为发起人建立多方参与事项”的文字标明其用途。任何一注册用户在其账户主页面内点击此键即建立了一个该类事项，随之获取事项ID和对应的事项二维码，并可以开始对该事项进行设置。澄清一点，此类事项与普通事项的本质区别并不在于参与者人数的多少，即使参与人数不很多的活动也可以为之使用这类事项。本质的区别在于参与者在事项内的地位对等这一原则对有发起人事项不再适用。发起人在事项中起主导作用，是唯一可对事项做各种设置的参与方。其他用户加入事项后，如有任何参与动作如付款，意味着这个用户同意发起人对事项的设置。这一点如有必要可写入下面要提到的发起人声明。

有发起人事项通常需要发起人向其他参与者解释事项的目的、性质、时间表等。所以发起人很可能需要做的一项设置是开辟文字输入框，在其中输入一段可以称之为发起人声明的文字，以向其他参与者提供必要的信息。输入完毕并确认后，这段文字，或打开这段文字的链接，即显示在事项主页面的显著位置。事项最好还要有名称。如果发起人确实这样选择，所取名称应与事项的目的和性质相符，同时由平台确保其在平台具有唯一性，以减小其他用户被误导和加入错误的事项的几率。这类事项通常还需要发起人预先设置一些“特定参与者”，指那些在事项中必不可少的参与者，比如捐款活动的受益方，或是那些受发起人邀请在事项中担任特定角色的参与者，比如某些活动的监督方。发起人可为每位特定参与者输入意思明确的称谓，取代“特定参与者1”这样的省缺、泛用称谓。如果设置的特定参与者尚是一个虚位，这个虚位可生成临时ID或二维码，由发起人传递给目标用户，供其使用以加入这个事项并同时成为这个特定参与者。其他参与者，或称普通参与者，均使用事项ID或事项二维码加入事项。发起人可预先设定这些参与者的加入是否需经发起人或某特定参与者的同意。不需要的话，任何用户通过输入事项ID或扫码就能加入，成为事项的普通参与者；否则还要等发起人或某特定参与者按动同意或审核通过这类操作键后方能加入成功。在事项可以使用之前，发起人必须设置付款规则，即，向参与者中的任何一方付款需要其他哪几方的同意。设置的付款规则只需发起人一方确认，一旦确认便不可更改，除非有不可预计的情况发生且经过其他参与者的投票（见下段）。付款规则必须能为其他参与者所查看，是在事项主页面点击 [查看设置 ]或这一功能的icon后所显示的内容之一。为方便计，和考虑到有些参与者可能不熟悉查看设置这样的功能，也可同时把付款规则写入发起人声明。发起人要为其声明与设置的一致负责。每个有发起人事项在建立、处理过程中所设置的事项名称、发起人声明、付款规则、以及下面要讲的各项投票设置和投票结果等要素，均应持久化存储在平台的关系型数据库中。

为处理无法预计的情况和解决可能发生的纠纷，有发起人事项中设有发起投票功能，供发起人在事项结束之前点击选择。点击后，这个事项就不再能接收新的参与者，还需要发起人先完成对投票的各项设置，然后投票才能在平台上进行。设置的第一项是在文字框中输入关于投票向全体参与者应做的解释，包括原因、目的、截止日期、投票规则等。然后进入投票实施细节设置，如，具体圈定可以参加投票的事项参与者（如果不是所有参与者，至少要有那些在事项中已有所投入的参与者，无论其投入的是钱还是工作），确定投票选项，包括为每个选项输入能明确表达其涵义的文字，和设定投票关闭时间，等。设置完成并确认后，每个可投票的参与者即可在其事项页面中看到投票的选项，并进行投票。为了防止投票功能被蓄意不当使用，平台可采用以下两个措施：一是不允许将投票关闭的时间定得过早，比如，可要求投票时间不得少于３天，或在参与者更多的事项中要求更长时间；二是在投票设置确认时，自动向可以投票的参与者发送通知信息，这样的信息在收信人未读之前，平台用与之前所述同样的方式提醒收信人，但可采用比为其它种类信息所采用的更加醒目的APP图标视觉变化，尤其是在投票截止时间临近时。如果投票是关于事项中的余款如何分配，投票的结果可能可以按预定的付款规则执行，也可能因超出了付款规则所涵盖的各种可能情况而不可以。后一种情况下发起人需要更改付款规则，平台管理方需核实更改后的付款规则是否与投票结果相符，以决定是否批准。只有经过批准的付款规则才能在平台上执行。

平台用户可以是个人，也可以是组织单位，两种用户在平台上的权利地位完全相同。也就是说，以上说明的内容不会因为任何一个事件的参与者可能是个组织单位而有任何不同。但这两种用户从自身角度讲却有很大不同，首先，组织用户要面对一个对个人用户不成问题的问题，那就是，上面提到的要由事项的参与者在其帐户中进行的操作必须要落实到由组织中的某个个人来执行才行，还有，组织用户的这些操作还不能都让一个人来执行，因为由一个人从发起/加入事项到收款/付款全程操办显然不妥。这些组织用户所特有的问题需要在平台的设计上予以解决。这首先体现在用户的注册手续上，每个用户在注册时必须选择是以个人注册还是为其组织注册。这个选择的原因有下面几个。一是为用户提供的帐户模板有所不同：为组织用户提供的帐户模板经过用户设置后可以让多个个人成为同一帐户的成员；二是业务规则有所不同，需要平台服务器部署不同的程序版本，当用户登录其平台帐户时，平台根据登录用户是个人用户还是组织用户的一员，以对应的程序版本来响应。三是配套的移动APP、PC客户端、和web客户端也因此有所不同。所有这些不同的根源在于，组织用户中必需要有角色的区分。组织用户在平台注册时，平台为其提供的帐户模板就是要使组织内的多个个人能够在帐户中担任不同的角色。反映在平台关系型数据库的设计上，同一组织帐户中的不同角色对这一帐户存储在数据库中的各项记录有不同的增删改查权限。平台适用于组织用户的业务处理程序（及配套的客户端软件）需要保证不同角色只能在帐户中进行各自权限内的操作。

平台在设计上必须对组织用户帐户中的角色予以设定（所谓帐户模板主要是指这些预设的角色），否则无法完成涉及组织用户的数据库设计和业务处理程序的编写。从以上的说明中不难总结出平台帐户中可能发生的操作有：1）建立或加入普通事项，2）参与普通事项（不包括付款和核实进款），3）作为发起人发起并管理有发起人事项，4）加入并参与有发起人事项（不包括付款和核实进款），5）在所参与事项中付款，6）接收进款通知和核实进款，7）成员及责任的变动。这其中只有最后一项是组织用户帐户所特有。这个操作列表的拟定有这样几个考虑：一，事项中资金的进和出都要有人专门负责，不与事项中其它参与行动并列；二，因为普通事项中参与者地位对等，无需对建立事项和加入事项予以区分；三，有发起人事项中的普通参与者的参与行动已在事项中设定，且相对单一，不必与普通参与者的加入行动分列。平台在设计上还允许用户为其中的一些操作做进一步分工，就是把一项操作最多再现细分为审批，执行，和执行后接收报告三项任务。所有这样细分出的任务所对应的就是组织用户帐户中的各个角色。当然，并非上面所列的每一项操作都需要这样的分工，比如，为收款设置审批就没有必要。

组织用户在平台开户后，需要为其帐户添加成员来担任帐户中的各个角色。每个帐户成员以自己的ID和密码登录帐户，并在帐户中根据其所任角色有特定的信息和操作权限。其中有一个帐户成员必不可少，就是这个用户组织的负责人（该组织的法定代表人或其授权下的组织总负责人），因为此人的身份及职务信息需要在注册申请中与这个组织的官方识别信息（如统一社会信用代码）一并提交。组织负责人还可选择在注册过程中或注册刚完成之后，为帐户添加一位帐户成员并指定由其代为负责为所注册的帐户进行设置，也就是负责上段中的第7项操作。添加帐户成员的方式至少有两种，一是利用帐户ID和对应的二维码，让组织员工通过扫码下载帐户APP并使用APP进入帐户，再为其选择角色，二是在帐户中为角色生成ID和二维码（包含帐户ID信息），让员工通过扫码下载帐户APP并使用APP直接进入帐户与角色匹配。

下面讲组织用户所用的客户端软件的特别之处，必要时还是以移动APP为例来表述。首先，组织用户帐户的客户端界面并不是一个，而是根据所登录的帐户成员的角色不同而有所不同。主界面中的操作按钮与个人用户帐户主界面中所见到的相同，但每个帐户成员所能操作的只是那些其所任角色有权操作的按钮。主界面之外，组织用户客户端还能在需要时以链接或弹出窗口等方式建立临时个人界面。举例讲，假如[参与普通事项]这一操作需要审批，审批请求连同审批操作就出现在具有审批权的帐户成员的一个临时个人界面中。组织用户已经加入但尚未结束的各个事项以链接方式置于所有相关帐户成员的帐户主界面中，供点击进入事项主界面。每个这样的事项主界面也做与上面关于帐户主界面所述同样的安排，即，每个帐户成员在其所见的事项主界面中，只能操作那些其所任角色有权操作的按钮，客户端也能在需要时以链接或弹出窗口等方式为这个事项建立临时个人界面。以事项中的付款为例，假如账户中是这样设置：付款由成员甲操作，由成员乙审批，然后报告给成员丙。成员甲在事项主界面中启动付款操作后，审批请求连同审批操作就出现在一个只对成员乙的临时界面中；成员乙在这个临时界面中完成审批后，成员甲便可在事项主界面中完成付款的全部步骤；成员甲确认完成后，这次付款的相关信息就会出现在一个只对成员丙的临时界面中供其确认。一个方便的设计是，在事项进程中当组织用户的某（些）帐户成员有等待其去完成的操作时，平台以某种方式向这个（这些）帐户成员发出提醒，具体可利用配套APP在手机桌面上的图标的某种视觉变化来实现。这一功能有赖于组织帐户中的角色ID与担任角色的组织成员所用手机之间的绑定（注意，不是帐户ID与手机间的绑定），可由APP在第一次从某个手机上被用来登录帐户时建立，具体是将这一手机的IMEI与在帐户中所进入的角色的ID进行绑定，并发送给平台。

以上是本平台在业务层面的各项主要设计。从中可以看出，本平台作为很多经济活动的资金收付过程中参与者间缺乏信任这一问题的解决方案，是对现有第三方解决方案在应用的便利性和应用场景的多样性两个方向上的提升，因此在更大程度上具有了优秀软件产品所应具有的特征。具体讲，本平台的绝大多数用户只需要在双方交易这一简单场景中使用本平台，对他们来讲重要的是便利性，是远高于银行资金监管等现有其它第三方支付方案的便利性，而且是几乎不需要先花学习时间便可利用的便利性；而对一些有高级需求的用户，本平台的功能多样性则更为重要，可以使用在很多原来不便甚至无法使用现有第三方解决方案的场景，尤其是作为独立第N方资金收付平台。但需指出，本平台与多数现有第三方平台并非替代关系。这从与支付宝的对比中就可看出，在电子商务平台的交易中，支付宝的第三方支付功能具有绝对优势，方便且有效地控制了因为买卖双方不直接接触而可能发生的风险；相比之下，本平台在这一个场景中的应用价值不大，但却有应用场景更加多样的优势，下文中的五个应用举例便说明了这一点，其中涉及的都是无法或不便使用像支付宝这样现有的第三方支付方案来进行风险控制的场景。可见，本平台与每个现有第三方支付平台之间是类似于通用设备和专用设备那样的关系，各有各的优势用途，并不相互替代，更何况各自还有除第三方支付以外的功能，如本平台的事项协议功能和支付宝的便捷支付功能。

附图说明

图1仅以有三个参与者的普通事项为例，是这三个参与者使用手机APP为他们的普通事项设置付款规则时，APP操作页面的示意图。

具体实施方式

本发明的实施首先要求根据以上发明内容中所述的各项业务设计进行平台的技术设计与开发，具体包含了业务逻辑层、数据逻辑层、和表示逻辑层这三方面的设计与开发工作。这个过程中需要实施方技术人员特别注意三个逻辑层的一体性，确保它们之间在平台业务功能导向下的相互匹配与支持。平台事项的处理过程中所用到的静态资源（HTML页面、图片、icon等）构成平台的表示逻辑层。平台事项的业务处理规则构成平台的业务逻辑层，业务逻辑层处理用户指令并将处理结果通过数据逻辑层持久化到关系型数据库中，数据逻辑层实现对数据库的增删改查操作。上述表示逻辑层部署于实施平台的开源或商业Web服务器上，业务逻辑层和数据逻辑层部署在实施平台的开源或商业应用服务器上，共同实现平台在架构层面上的分层解耦。下面仅就这三个逻辑层的开发和实现再做几点说明。

本平台的独到之处全在于整体的构思，对所需要的组件并无特殊要求，属于通用的交易处理型平台，因此适合采用业界通用的服务化架构进行设计和开发。这一架构下的拆分设计方式可以更好地支持平台业务功能层面的松耦合和易扩展。具体到技术实现上，在Java、C#、.NET等多种技术栈之中，JavaEE显然是本平台实现技术标准的最佳选择，特别是Java庞大的生态体系和开源社区中的很多资源可为本平台所直接复用。在JavaEE技术标准下，业务逻辑层的开发可大量使用底层平台框架所提供的支撑（如，Spring、Springboot框架、分布式服务框架dubbo）；开发人员无需从“零”开始，而是利用框架内现有的组件能力（如会话管理组件、消息组件、日志组件、图表组件、数据库组件等）在框架之上进行本平台业务逻辑程序的开发和部署。本平台要有数据逻辑层介于业务逻辑层和数据库之间，这是由前者的相对易变和后者的相对不变的特点所决定。数据逻辑层封装数据库访问接口（Java为JDBC），实现数据库增删改查操作，提供数据库访问能力，并实现业务逻辑层与数据库松耦合。关于数据库，首先要考虑数据库选型。目前市场上的数据库有传统关系型数据库（如Oracle、MySQL等）和以“Key-Value键值数据库”为代表的非关系型数据库（NoSQL）等。考虑到一个数据库的成熟稳定至少需要10年以上的工业应用历程，本平台宜采用主流的关系型数据库作为数据存储系统。随着平台业务的发展，用户数量和业务并发量大幅提升，对热点数据的更新操作可能造成数据库读写性能瓶颈。针对此种情况，可采用非关系型数据库作为辅助，将热点数据加载到键值数据库的内存中，以提升平台的访问性能和用户体验。关于表示逻辑层的实现，本平台遵循W3C的Web技术标准（如HTML、JS、CSS等）以支持业界主流桌面终端浏览器（如Chrome、Edge、Firefox等）；若因特殊原因不支持某一版本的浏览器，则应以页面文字、页面弹窗等方式进行友好提示。对于移动APP和PC客户端应用，本平台支持客户端程序版本检查和更新。

较佳的，上述平台部署在实施企业的私有云（IaaS、PaaS）环境中，也可以对外开放部署在企业的生态云（SaaS）环境中，还可以托管在电信运营商等第三方的云环境中，由云平台提供计算、存储和网络基础设施资源，实现平台云化部署和资源弹性伸缩。需要说明的是，无论哪种部署方式，均应考虑平台的灾备高可用、监控、运行维护和安全，确保平台业务连续性和安全性符合监管要求和行业标准。

应用举例

应用举例1：张某以20万元的报价承接了王某的一处物业内部装修。该工程预计需要一个月。双方初步商定按进度分两期付款，每期10万元。张某此前有多次工程款被赖账的经历，因此向王某提出使用本平台，由王某在每期工程开始后的第五天把当期的工程款付入平台的要求。而王某更多的是担心张某若在完工后就收款，可能不会太用心去解决完工后才暴露的工程质量问题。虽然合同中有保修，但对张某这样的小流动装修商户并无多大作用。因此，作为交换条件，王某提出最后一期工程款的一半等完工后三个月再从平台支付给张某。假设双方至此达成协议，双方即时登录各自在平台的帐户，用扫二维码的方式为该工程建立一个普通事项，并将上述协议输入事项的说明。再假定张某第1日开工，其后的进度符合预期，第5日王某把第1期的10万元付入该工程的平台事项。第15日王某在检查第一期工程满意后，将事项中的10万元从平台付给张某。第20日，王某将第二期的10万元付入该工程的平台事项。第30日完工，王某检查满意后将事项中的5万元从平台付给张某。三个月后，该工程并无遗留质量问题，王某将事项中的最后5万元从平台付给张某，至此双方可关闭该事项。

应用举例2：与应用举例1在其他各方面相同，只是这次全部20万工程款需要王某从银行贷款获得。假设王某为降低利息申请的是个人抵押贷款，并在开工前获批。这种贷款不能由银行发放给借贷人，只能发放给贷款用途中的收款方。可是这笔款从一开始就发放给张某显然对王某不利。这个问题还是利用本平台连同上面的问题一道解决。具体讲就是在平台建立一个有王某、张某和贷款银行三方参与的普通事项，然后由银行将20万贷款付给平台的这个事项。因为王某并不能在事项中向自己付款，所以贷款并没有发放给王某。但通过使用该平台事项，王某就可以掌握向张某付款的时间，从而达到减小风险的目的。其付款操作与应用举例1中所述相同。

应用举例3：大型工程与上面案例不同，甲方与乙方（也就是总承包商）之间的工程款结算与支付按国家规定必须通过专业第三方工程咨询公司进行，无需使用本平台。但大型工程往往有多级承包。如果甲乙两方的关系称作一级承包，那么从乙方承包工程就是二级承包，而从二级承包商承包工程就是三级承包，以此类推。上述国家规定并不能控制整个承包链上从第二级往后的各个承包关系中的支付风险，因此可以利用本平台作为补充的支付风险控制措施。但要在同一工程的同一承包链上的多级承包关系中同时使用本平台，会有下面这个问题。假设承包商1从乙方承包了部分工程，承包商1又其中的部分工程一发放给承包商2去做，本平台用以应对的风险同时存在于乙方与承包商1，和承包商1与承包商2，这两个关系中。假设乙方与承包商1使用案例1中的方法消除了他们双方的风险。同样方法却无法在承包商1和2之间同时使用，因为乙方为每一期工程提前付入其与承包商1的平台事项的工程款，要等这一期工程结束才能付给承包商1，所以承包商1无法将其中的哪怕一小部分，提前付入其与承包商2的平台事项，以消除承包商2的风险。但注意，这里的问题并非由于缺钱所致，而是一个时间差的问题，这是典型的适合使用贷款解决的问题。同时，假设每一级承包关系都使用本平台，平台管理方因此掌握整个承包链的信息，对每个参与其中的承包商所面临的风险甚至比承包商自己更清楚。所以平台管理方增设贷款业务顺理成章，不仅有信息上的优势，相比其他金融公司还可谓是“近水楼台先得月”。现在假定平台管理方确有贷款业务。在这个两级承包的例子中，案例1中的解决方法就能在这两级承包关系中同时使用，仅需平台管理方在承包商1需要向其与承包商2的平台事项付款和当期工程结算之间的这段时间给承包商1提供短期贷款，前面所讲的时间差问题即可解决。现实中，大工程的承包链往往会更长，但不管有多长，这个方法的道理都一样，显然同样适用，只需平台管理方向这个链上的更多承包商贷款。这对兼有贷款业务的平台管理方反而是个商机。

应用举例4：某公司从事设备制造，其产品包括熔喷布生产设备，并在此领域有多年的研发投入和经验积累，完全有能力为客户生产、安装、调试成功产品合格率达标的熔喷布生产线。该公司对其所在行业非常了解，知道很少有其他企业具备同样的技术能力。近来由于一种为世界卫生组织命名为Covid-20的病毒在世界多国呈蔓延趋势，市场对熔喷布生产设备的需求大幅增加，但令该公司不安的是，市场上来自其他厂家和中间商的供给也同样大幅增加。这是因为这种设备只有在客户购入、安装、反复调试之后才能从其产出的合格率看出设备的质量如何，购买前客户无从知晓，这就给那些劣质设备厂商提供了机会。这同时也给客户和优质厂商制造了问题：前者担心买到劣质设备，成为市场试错过程中的牺牲品，后者则困于如何使客户相信其所卖确是优质设备。对于该公司，允许客户退货或延期付款以示对本公司设备的信心在目前的市场状况下不是好办法，因为客户所面对的口罩市场有很大的不确定性，其风险会过多地转移到本公司。这样情况下，使用本平台是该公司能方便、有效地解决买卖双方问题的方法。具体就是为每一个订单同客户在平台建立事项，让客户先把货款付入这个平台事项，等设备的产品合格率达标后，再让客户在平台上将货款付给该公司。(如果客户在设备质量达标的情况下拒不在事项中付款，对客户自己并无好处，只有坏处。第一，货款并不能回到客户处，第二，损坏了与供应厂商的关系，可能无法得到后续服务，第三，厂商若诉诸法律，客户没有胜算。)这个方法之所以有效，是因为那些劣质设备厂商无法效法。从客户角度，不仅这个方法本身提供了一定程度的保障，而且客户也不难看出这是个只有优质厂商才能使用的方法，其风险和伴随的焦虑因此而降至最低。由此例可见，在那种多变的、尚未形成建立在各方信誉之上的稳定供需关系的市场，本平台为优质厂商提供了一个有效的竞争手段，能使其更快地在市场建立自己的地位，并在这个过程中避免恶性价格竞争。

应用举例 5：某高科技公司在一项关键技术上一直依赖国外，最近被国外断供，因而面临难以克服的经营困难。李同学和他的伙伴们知道有很多像他们这样愿意出手相助不让该公司倒下的人，因此想发起募捐，以支持该公司自己进行研发并最终渡过难关。李同学知道成功的关键在于取得公众的信任。作为没有社会知名度的普通人，李同学的办法是借助本平台，即，作为发起人为此募捐在平台上建立一个有发起人的事项，并为此事项做必要的、合适的设置，然后向公众发布该事项在平台的ID或对应的二维码，以及事项的名称。任何人成为平台用户后，即可使用该事项的ID或二维码进入事项，查看事项设置以消除疑虑，然后在其中操作付款，即捐款成功。李某作为发起人，无需设立或指定另外的银行账户，其所做的设置应包括一个简单明了的事项名称（其只能是在平台上有唯一性的名称，见前文）以便于每个进入事项的用户核实。即便万一有人被他人误导，进错了事项，捐错了对象，也容易在事后发现，并依据平台的记录进行追讨。发起人还应为付款规则设定：只有特定参与者，包括受益公司再加上一两个只起监督作用的机构，可以授权转出资金。这样的设置一旦确认便不可更改，并能确保执行，这是平台的信誉所在。如此便排除了发起人或任何其他参与方从中获利的可能，尤其是消除了公众对这一可能性的疑虑。此外，捐款者还可全程跟踪事项的进展情况，只要登录平台进入该事项就能看到诸如资金的流入、流出、余额等自己关心的信息。如此程度的安全性、便利性和透明度会使此募捐活动更易成功得多和更加成功得多。

以上是对本发明的设计思路和实现方法的说明，文中的表述方式，如各种操作的表述和标识文字，均为示例性的。本领域的普通技术人员无需创造性思维或劳动便可对本文所述的设计构思作出的变动，如缩简、润色、合并、拆分、次序调整等，只要不在精神上偏离这里的总体构思，均不构成对本发明的变更或超越。特别地，在实施中为确保平台网络的安全性而采取一些技术措施是为实现这里所述的各项功能所必需的，并不构成对这些功能的改进或变动。

Claims (4)

1.一个独立第N方资金收付平台（以下简称为平台），由一个移动互联网应用及配套客户端构成，其特征在于，

（1）任何一组已在平台注册的用户（以下简称为“用户”）可以选择通过平台来实现相互间在任一事项中的资金往来，即，选择让事项中的付款方先向平台支付本应向收款方支付的资金，和让事项中的收款方从平台收取本应从付款方收取的资金；

（2）平台的基本工作单元为“事项”，通过平台发生的资金往来一定是平台上某个事项中的资金往来，用户使用平台需要先建立或加入某个事项，也就是先要成为某个事项的参与者，然后在这个具体事项中使用平台；

（3）用户在平台上可建立的事项有两种，分别是“普通事项”和“有发起人事项”，前者是指那些参与者在身份和人数上固定、并在事项的设置中有同等权利的事项，后者需要由某个用户以发起人的身份建立、并独自负责为事项做各项设置，然后可以有不定数目的用户陆续加入成为参与者；

（4）平台上的每个事项一定有“付款规则”，指的是，平台在事项中向每一位参与者付款需要经过其他参与者中哪几位的同意，具体到只有两位参与者的普通事项，这一规则默认为，平台向一位参与者付款必需由另一位同意，但所有其它事项的这一规则均要由事项参与者来设置，在（有两个以上参与者的）普通事项中由所有参与者共同设置，在有发起人事项中由发起人设置；

（5）平台为用户提供的各项功能都能由用户（使用平台客户端）在各自的平台帐户中自己操作来实现，包括建立事项、加入事项、为事项设置付款规则，在事项中付款，在事项中指示平台向他方付款，特别地，这些操作还包括普通事项的参与者为事项输入文字，待事项全部参与者确认后永久保存备查，和有发起人事项的发起人为事项输入文字并确认，以示事项的其他参与者并永久保存备查。

2.如权利要求书1所述的一个独立第N方资金收付平台，其特征在于，平台为有发起人事项设有发起投票的功能，供发起人在事项建立之后、结束之前选择使用，这一功能被启用之后会先要求发起人为所发起的投票做必要的设置，包括输入文字解释、设定投票参与人和投票截止时间、决定并输入投票选项。

3.如权利要求书1所述的一个独立第N方资金收付平台，其特征在于，在平台注册的用户可以是个人，也可以是组织单位，平台支持后者在其帐户中安排不同人员来分别负责用户在平台上的各项不同操作，这些操作具体是，1）建立或加入普通事项，2）参与普通事项（不包括付款和核实进款），3）作为发起人发起并管理有发起人事项，4）加入并参与有发起人事项（不包括付款和核实进款），5）在所参与事项中付款，6）接收进款通知和核实进款，7）帐户内的人员及责任变动，此外，这其中的某些操作还可再细分为审批，执行，和接收执行报告最多三项任务，在帐户中由不同人员负责。

4.如权利要求书1所述的一个独立第N方资金收付平台，其特征在于，每个普通事项的各个参与者之间，和每个有发起人事项的发起人和其他参与者之间，可在平台上互发信息，平台也在用户有进款和有待参加投票等情况下自动通知用户，在每条信息的收件人打开信息之前，平台的配套移动APP以其在收件人手机桌面上的图标的某种视觉变化提醒查看，特别在待参加投票的截止日期临近时，这一视觉变化可以变得更加显著。

Images