CN104866946B - 一种不同系统用户账号共享的方法 - Google Patents

Abstract

本发明提供一种不同系统用户账号共享的方法，其中一个系统可以识别另一个系统的用户账号、用户账号的等价标识或用于标识的实物载体并直接通过其查验接口或通过第三方查验入口使用此其查验接口进行远程查验，然后对于查验通过的赋予本系统的权限，或者然后在查验通过的基础上再根据查验所获取的账户情况对比本系统权限设定条件的情况赋予本系统的权限或不赋予本系统的权限，本系统提供对应的用户账户或相应的实物载体或利用原实物载体行使权限。也可在本系统验证或上述方法间接通过本系统查验后推送该用户查验情况来实现用户账号共享。本发明提供的方法，可以实现不同系统统一的用户账号，省去重复注册申领，还可方便的使用不同系统的功能。

Description

一种不同系统用户账号共享的方法

技术领域

本发明属于机电电子产品及软件领域，尤其涉及一种不同系统用户账号共享的方法。

背景技术

现实生活中，公共交通是多数城市居民首选的交通方式，公共交通的种类很多，如公共汽车、地铁、公共自行车，但各自有各自的系统，卡经常不能通用，即使同城能够通用，换一个城市就不能通用。为解决上述情况，住房和城乡建设部牵头开始建设“全国城市一卡通互联互通大平台”。“全国城市一卡通互联互通大平台”自2008年开始筹备，2012年7月，上海等首批8个城市加入，2013年4月南昌等9个城市加入。据了解，统一的标准体系和安全密钥系统是异地公交IC卡互通的前提。目前，按住建部标准进行建设并申请使用统一密钥安全体系的城市已有160多个。即使能够覆盖全国各个城市，也只是限于公交（公共汽车），而且北京、上海等大城市因为已有卡存量大功能多难以加入，因为这种解决方法有很大局限性。

无论是互联网上还是一些大型单位的局域网内，都运行着数量众多的应用系统，每个系统都有自己用户账号管理系统，不能通用，人们不得不努力记下所有要使用的用户账号（口令）等信息，但事实上除非另有载体记录，否则很难记下众多的用户账号（口令）；另外，注册使用也是比较麻烦的问题，很多人都在不同的邮箱系统注册了邮箱，以方便不同情况的交流场合，每个系统都要注册一次，在使用时也必须登录到相应的系统去查看使用。

在虚拟空间，系统多、用户账号多，用户账号和口令都难记；以及在现实生活，各种实物卡太多，注册申领手续重复雷同（一般都要提交身份信息、身份证复印件等），占用时间（至少需要专门跑一趟）和资金（大多是先预付后消费，象公共自行车租赁还需要另外的押金）。

不同系统之间的用户账号信息不能关联共享是造成上述问题的主要原因，其解决方案前面已经提到一种一卡通模式是比较有代表性的解决方案（银行业的银联卡方案等也属于这一类型），但由于要遵循同样的标准进行建设，对于已有的系统及跨界的系统来说这很难做到（比如住建部的标准不能约束银行业、电信业，反之亦然）。另外，还有一些其它的解决方案。一是同一家公司不同系统实现统一的或近于统一或部分统一的用户管理，比如阿里系的淘宝、天猫、阿里商城，腾讯的微信、QQ及邮箱，宁波公共交通系统则是一种部分统一用户管理的情况，其中的甬城通卡可以在公交地铁公共自行车三种公共交通系统上用、而市民卡则只能用于公交，这种方案显然不能彻底解决问题，而仅能限于内部；第二种是开放用户账号查验接口实现用户账号共享，比如新浪微博可用腾讯QQ账号登录，这种方式采用专门开发针对专门系统的接口，使用起来很方便但开放性不够（没看到其它系统使用），同时也不支持实物卡形式的验证；第三种是半共享已有的用户账号，比如支付宝用的已有的邮箱账号，但有本系统的进一步验证机制，这种方式仅仅共享了一个用户名而已，其它都是独立的。

发明内容

本发明的目的在于解决用户账号太多以及实物形式的用户卡证太多、注册申领及使用麻烦的问题，提供一种不同系统用户账号共享的方法，可以实现不同系统统一的用户账号，省去重复注册申领，还可方便的使用不同系统的功能。具体有两个基本内容相似但使用场合各有不同的技术方案。其技术方案一如下：

至少两个非统一用户管理的不同系统，其中一个系统可以识别非本系统的另一个系统的用户账号、此用户账号的等价标识或用于标识此用户账号的实物载体并直接通过此另一个系统的查验接口或通过第三方查验入口使用此另一个系统的查验接口进行远程查验，然后对于查验通过的赋予本系统的权限，或者然后在查验通过的基础上再根据查验所获取的账户情况对比本系统权限设定条件的情况赋予本系统的权限或不赋予本系统的权限；

或者在前面基础上对于上述可赋予权限的情形，本系统为此另一个系统用户账号提供对应的本系统用户账户，或本系统先为之提供对应的本系统用户账户然后再为之发放用于标识此本系统用户账号的实物载体，或本系统先为之提供对应的本系统用户账户然后再使原用于标识此另一系统用户账号的实物载体能够标识此本系统用户账户；

所述查验过程要求口令验证或不要求口令验证，和/或所述本系统为之发放用于标识该账号的实物载体永久有效或临时有效，和/或所述本系统为之提供对应的本系统用户账户永久有效或临时有效，和/或所涉及的资金清算采用基于另一个系统的原资金账户先冻结后记账最后结算支付的方法，或采用基于另一个系统的原资金账户实时结算支付的方法，或采用基于本系统的新资金账户实时结算支付的方法，或者上述三种资金清算方法其中任意一种的基础上另要求一定数量资金作为担保；

所述用户账号采用符合正则表达式userName|userID@host[:(port|protocol)]的格式进行全局标识以实现查验接口的标识，和/或建立各系统接口汇总表并以各系统接口汇总表为基础实现查验接口的自动选择或提供查验接口的人工选择；

已赋予本系统权限的此另一个系统用户账号在使用本系统中获取到的信息或其它用户通过本系统发送给此已赋予该本系统权限的此另一个系统用户账号的信息可由本系统通知或转发，或者在前面基础上是通知或转发给此用户账号的原系统、主登录系统、所有登录系统、主赋权但未登录系统或所有赋权但未登录系统。

本方案适用于其它系统的用户账号登录本系统而非自身本来的系统情况。这种情况包括异地使用公交卡、用已有用户账号登录其它系统等典型应用场合。至少两个非统一用户管理的不同系统，既然是用户账号共享，当然至少两个不同系统，而且应是两个非统一用户管理的不同系统，象阿里系的淘宝、天猫、阿里商城这种同一系列的统一的、近于统一的及部分统一的用户管理的多个系统不算在内，这种类型的多个系统在一定程度上可以算作一个系统，尽管相互之间还是有区别的。这种说明也适用于后面的技术方案二，除非特别注明，关于技术方案一的说明均适用于技术方案二，后面就此不再赘述。其中一个系统可以识别非本系统的另一个系统的用户账号、用户账号的等价标识或用于标识其用户账号的实物载体并直接通过此另一个系统的查验接口或通过第三方查验入口使用此另一个系统的查验接口进行远程查验，实物载体包括各种实物卡（用户卡）、身份证、银行卡等有形的实物载体（这时识别一般需要相应的读卡器或类似设备），等价标识指的是和用户账号名称一一对应的其它标识，比如身份证号、ID号等，增加识别用户账号的等价标识可以增加系统的灵活性；查验接口指的是可以验证用户账号合法性及查询用户相关信息如基本注册信息、具有的权限、资信情况等的接口，该接口是另一系统提供的，当另一系统调用本系统的同样接口进行查验时则是本系统提供的，也就是说这里共享用户每个系统都有这样的接口，这个接口是一种通用接口，至少在这里共享用户的所有系统中是这样的，而非开放性较低的专门针对一种系统或少数几个系统的专用接口。也可以通过第三方查验入口进行查验，这样可以减少或控制查验系统的压力，而且用起来也方便，一个统一的入口比多个入口更简单好记，但和银联卡查验不同的是，这里查验最终还是使用此另一个系统的查验接口进行远程查验，而非在第三方查验入口本身解决，但可以可以利用缓存的先前已有的查验结果直接进行查验。然后对于查验通过的此另一系统用户账号赋予本系统的权限，这样就实现了用户账号的共享，不需要重新注册、申领，也不需要增加记忆和/或保存的负担，使原有的用户账号增加具有了另一个系统的功能；也可然后在查验通过的基础上再根据查验所获取的账户情况对比本系统权限设定条件的情况赋予本系统的权限或不赋予本系统的权限，各个系统对于用户的要求很可能存在不同，要求严的一般不会简单接受其它系统的用户，而是要进一步检查，符合要求的才会赋予权限，不符合要求的则不会赋予权限。一般情况下，同类系统可以查验结果互认，比如工商银行系统认可建设银行系统的查验结果，低要求系统可以认可高要求系统的查验结果，但反过来高要求系统对于低要求系统则可以则查验通过的基础上再附加条件。对于上述可赋予权限的情形，本系统可以直接使用此另一个系统用户账号（或其等价标识、实物载体），当作本系统的用户账号用，但一般情况下不会这样做，而采用其它的方式。具体处理的方式有这么几种：一是为此另一个系统用户账号提供对应的本系统用户账户，在登录本系统时使用此本系统用户账户或原系统用户账号，但使用本系统的过程中最终是通过此本系统用户账户来实现；第二种是本系统先为之提供对应的本系统用户账户然后再为之发放用于标识此本系统用户账号的实物载体，在第一种基础上换发或新发实物形态的用户卡，方便使用，比如在异地坐公交而异地的公交卡系统不能识别本地公交卡，这时就可以采取换发卡的方式，换发该异地公交卡系统所用的啊，换发卡时可同时强制收回原本地卡（即要用原本地卡做抵押，确保两张不会同时在两地被使用），直至离开不需要收回换发卡再拿回原本地卡，也可不收回换发卡，但这样仍有卡太多的问题；第三种是本系统先为之提供对应的本系统用户账户然后再使原用于标识此另一系统用户账号的实物载体能够标识此本系统用户账户，这是在第一种情况下仍旧使用原有的实物形态的用户卡，这必须在此卡能被本系统广泛识别的情况下。第二种情况的换发卡点可以设在交通枢纽、商业中心、游客服务中心等处，无需广泛设点，因此设备系统可以复杂一些，甚至可以所有类型的卡各设一个识别装置，但这种做法如果推广到所有可使用的网点则成本太高，所以一般不采用这种方式；而第三种情况由于卡物理上本来就可通用，通过查验这一关后就直接可以跨系统用了，省去了换发卡的麻烦，同时也更经济。

上述查验过程可以要求口令验证，这样安全性更高；也可不要求口令验证，但采用实物载体的一般可以不再要求验证口令，不过为了安全起见也可要求验证口令，以免被盗卡、遗失卡在异地非法使用。本系统为之发放用于标识该账号的实物载体可以永久有效，也可临时有效，永久有效则一般对应不回收此换发卡或新发卡，这样仍会造成卡太多的情况，所以永久有效一般在不用换发卡即原卡可以通用的情况下采用。一般情况下，推荐采用临时有效的方式，临时有效可以采用限定有效时间，超期则失效，也可结合采用其它条件判断的形式，如直到换回原卡前一直有效，一定期限内不使用则失效，关联的资金账号上金额低于一定数额则失效，等等。对于本系统为之提供对应的本系统用户账户也可以分别采用永久有效、临时有效的策略，和前面实物载体类似，但有所区别的是如果仅有用户账号无需考虑换发卡或新发卡的问题。对于公交卡、地铁卡、公共自行车卡等实物载体的卡及类似于支付宝账号一样和支付有关的用户账号，则在异地、跨系统使用时可能会涉及到资金支付的问题（坐公交要付费，当然也可能不会，如在规定时间内使用公共自行车为免费），这就涉及资金清算的问题，象支付宝账号是捆绑银行卡的，但也有自己的资金账号，而象公交卡这种带支付功能的实物载体的用户卡都是预付卡（即先存钱后消费）均有自己的资金账号，针对上述情况，可以采用基于另一个系统的原资金账户先冻结后记账最后结算支付的方法，也就是先冻结此另一个系统用户账号（或其等价标识、实物载体）对应的原系统的资金账户上的资金，全部冻结（这样就不能在原地使用）、定额冻结（还保留在原地使用的可能性）、比例冻结等，然后此另一个系统用户账号（或其等价标识、实物载体）或对应的基于本系统的用户账号（或其等价标识、实物载体）在使用本系统的过程中，比如乘坐公交车、使用公共自行车的过程中实时进行记账，最后再基于原资金账户进行结算，需要进行支付则进行支付，不需要支付的仅结算就可以了，结算可以日结算、定期结算、有效期满（包括注销、换回卡等情况），具体根据成本及方便程度等而定。也可基于另一个系统的原资金账户实时结算支付，这时可冻结也可不冻结原资金账户的资金，使用本系统时，每次进行原资金账户的查验，需要扣费则实时扣费，这种方式除非远程查验原资金账户及扣费比较方便或成本低，否则不宜采用。也可采用结算新资金账户实时结算支付的方法，即为此另一个系统用户账号（或其等价标识、实物载体）或对应的基于本系统的用户账号（或其等价标识、实物载体）在本系统开设一个新资金账户，然后结算支付就可本系统的本地卡一样使用，这种方式便于充值等，但存在一个余额的问题，非常去的异地情况下，余额一般需要用户收回（否则也是一种损失，象香港、悉尼等地为旅行者提供的定额交通卡、通信卡大多数旅行者是用不完的，因为没有回收措施结果最终把自己的利益放弃了，实在有些不划算），应有提现、转账（转到原资金账户上）等措施保护用户的利益。还可以在上述三种资金清算方法其中任意一种的基础上另要求一定数量资金作为担保，比如公共自行车如果没有担保用户拿了不还怎么办、没有抵押原卡而换发卡收不回怎么办等情况，都可以用一定的押金来解决，这个担保的资金可以有两种形式的解决方法，第一种是此另一个系统用户账号本来就有使用公共自行车的功能并为此提供了担保资金，这时可以这个资金拿过来（指用途上，只要两个系统承认即可，而非真的转账过来）用于此处的担保；第二种是冻结原资金账户上的相应余额作为担保，直至解除担保（可以在对应的本系统用户注销时、换回卡等时机解除担保）后解冻这部分资金。

用户账号可以采用符合正则表达式userName|userID@host[:(port|protocol)]的格式进行全局标识以实现查验接口的标识，userName表示用户账号名称，userID 表示用户ID，userName和userID的不同在于userName一般是一个有意义的容易记忆的名称，而userID一般是一个无意义的不易记忆的数字串或其它符号串。@是个分隔符。host表示合法的主机域名或IP地址或ID（如hosts文件所定义的名称或数字序号）。port表示端口号，一般用数字表示，如邮件服务的端口号21，WEB的通用端口号为80；protocol为服务协议名，一般用符号表示，如类似于TCP、IP等，这些服务协议与端口号一一对应。userName|userID和port|protocol均是选一的关系，[:(port|protocol)]则是整部分可选的，整部分表示通过主机的该端口（或服务协议）去执行查验，在假设默认端口为21的情况下，这就是一个完整的邮箱名称。在本系统中@host[:(port|protocol)]都可以不要，但这时就不是全局标识了，而是本地的局域标识，有了@host[:(port|protocol)]则是一个全局标识，这时系统就可以根据host[:(port|protocol)]找到查验接口的入口地址了，这就实现了查验接口的标识和寻址。

也可以建立各系统接口汇总表，这个表名是从功能上来描述的，用来将各系统的查验接口入口地址汇总在一起，类似于UNIX系统中的hosts文件。有了这个汇总表就可以各系统接口汇总表为基础实现查验接口的自动选择（在使用ID形式来标识host等时），也可提供查验接口的人工选择，即用户在登录系统时可以只输入用户名，然后在到导航中选择其本来所属的系统（此导航的每一个条目对应到各系统接口汇总表每一个条目），这样可以减少用户在记忆及录入方面很多麻烦，而且可以做到一目了然，可以同明确的说明文字来做到一目了然，比如宁波市民卡、宁波公交甬城通卡，而不要采用宁波市民卡系统、宁波公交甬城通卡系统的查验接口的IP地址或域名（估计没人记得住）。

为了实现不同系统的互通，还可以在前面用户账号共享的基础在进一步拓展。可将已赋予本系统权限的此另一个系统用户账号在使用本系统中获取到的信息或其它用户（可以是本系统本身的用户账号也可以是通过查验而获得本系统期限的其它系统用户账号，方案二也与此相同）通过本系统发送给此已赋予该本系统权限的此另一个系统用户账号的信息可由本系统通知或转发，通知一般是指告知哪个系统有消息、反馈或交互的提示，一般最多还可显示一个摘要；转发则相当于功能上做一个中继，比如收到一个文件、邮件、消息直接转发过来，这种情况比较难实现，特别是功能完全不同的系统，比如一个即时通信系统和一个股票行情系统，两者功能完全不同实现转发成本太高。通知或转发的目的是哪个，可以发给此用户账号本所属的原系统，也可以是设置的主登录系统（可以是本所属的原系统也可是其它系统，根据具体设置而定，这时需要有一个检测机制来确认是哪个系统，且这时通知或转发可直接到达相应的用户账号-因为已经登录所以可以马上收到通知或转发的内容），也可以是所有登录系统即目前已登录的系统（也需要有一个检测机制，且这时通知或转发可直接到达相应的用户账号-因为已经登录所以可以马上收到通知或转发的内容），也可以是主赋权但未登录系统（也需要有一个检测机制，但因为没登录而无法立即收到），也可以是所有赋权但未登录系统（也需要有一个检测机制，同样因为没登录而无法立即收到）。

其技术方案二如下：

至少两个非统一用户管理的不同系统，其中一个系统在识别本系统的用户账号、此用户账号的等价标识或用于标识此用户账号的实物载体并验证后，或者基于权利要求1、2、3或4所述的方法识别非本系统的另一个系统的用户账号、该用户账号的等价标识或用于标识该用户账号的实物载体并查验通过后，本系统向其它至少一个系统通过该其它系统的查验推送接口或通过第三方查验推送入口使用该其它系统的查验推送接口推送用户账号查验情况，然后该其它系统赋予该其它系统的权限，或者再根据查验情况对比该其它系统权限设定条件的情况赋予该其它系统的权限或不赋予该其它系统的权限；

或者在前面基础上对于上述可赋予权限的情形，该其它系统为此用户账号提供对应的该其它系统用户账户，或该其它系统先为之提供对应的该其它系统用户账户然后再为之发放用于标识此该其它系统用户账号的实物载体，或该其它系统先为之提供对应的该其它系统用户账户然后再使原用于标识此用户账号的实物载体能够标识该其它系统用户账户；

所述本系统验证过程要求口令验证或不要求口令验证，和/或所述该其它系统为之发放用于标识该账号的实物载体永久有效或临时有效，和/或所述该其它系统为之提供对应的该系统用户账户永久有效或临时有效，和/或所涉及的资金清算采用基于本系统的原资金账户先冻结后记账最后结算支付的方法，或采用基于不系统的原资金账户实时结算支付的方法，或采用基于该系统的新资金账户实时结算支付的方法，或者上述三种资金清算方法其中任意一种的基础上另要求一定数量资金作为担保；

所述用户账号采用符合正则表达式userName|userID@host[:(port|protocol)]的格式进行全局标识以实现查验接口的标识，和/或建立各系统接口汇总表并以各系统接口汇总表为基础实现查验接口的自动选择或提供查验接口的人工选择；

已赋予该其它系统权限的此用户账号在使用该其它系统中获取到的信息或其它用户通过该其它系统发送给此已赋予该其它系统权限的用户账号的信息可由该其它系统通知或转发，或者在前面基础上是通知或转发给此用户账号的原系统、主登录系统、所有登录系统、主赋权但未登录系统或所有赋权但未登录系统。

技术方案一是用非本系统的用户账号来本系统申请共享，这样一次操作只能实现增加一个系统的用户账号共享；而技术方案二则可以一次实现增加不止一个不同系统的用户账号共享，本系统的账号登录验证时或根据技术方案一非本系统的用户账号来本系统申请共享时，直接把用户验证（对于本系统）或用户查验（对于非本系统）情况直接推送到试图进行用户账号共享的多个不同系统，这样就大大简化了共享操作。当然，要实现换发不同系统用于标识此该其它系统用户账号的实物载体，如用户卡，在现实中还是有困难的，除非本处备有。所以无论是技术方案一还是技术方案二都推荐支持每一个用户都有的一种实物载体，比如身份证（一般应为二代证），这样就既省去的换发卡的麻烦，又方便各个系统进行改造（开发一次各个系统都可用）。查验推送接口和技术方案一的查验接口除功能上有所不同，一个主动一个被动，除此之外，其它都差不多，而且可以整合在一起。其它方面，技术方案二和技术方案一均差不多，这里不再赘述。

本发明提供两种不同系统用户账号共享的方法，可以以较低的成本实现不同系统用户账号共享，对现有系统的软硬件改造不大，软件方面一是增加1-2个接口即查验推送接口、查验接口，接口都是通用的，无需针对不同系统开发专有接口；二是增加一个识别接口，对于不涉及实物载体识别的也可只要一个通用的识别模块（可以为纯软件形态的）即可，而对于涉及实物载体识别的则每一种类型的实物载体可能都需要专门的识别器（一般硬件形态的，其中也包含软件），所以最好采用一种通用实物载体识别器，如身份证识别器，这样就无需为每一种类型的实物载体都使用一个专门的识别器，当然这时由于身份证信息无法与具体的系统关联（因没有指出原系统主机等信息所以一个局域标识），就需要进行导航选择相应的系统（如果非本系统登录验证的话，若是本系统登录验证则需要导航选择需要进行用户账号共享的系统）进行验证。本发明提供的不同系统用户账号共享的方法，可以在现实世界、虚拟世界（不涉及实物载体或现实财物的）通用，可以方便用户同时节约建设成本。

具体实施方式

实施例1

一种公交卡异地互用的方法

假设宁波和南京的公交卡在物理实现上采用完全不同的技术，一个采用IC卡技术，一个采用RFID技术，两种卡在物理上不能通用。一个持有宁波公交卡的定居宁波的人到南京去旅游，可以南京的游客服务中心的公交卡互通换发点申请认证换发南京的公交卡（隐含开了一个用户账号），此时宁波的公交卡系统提供一个查验接口，南京公交卡互通换发点远程调用此查验接口进行查验，查验通过的则冻结其宁波公交卡资金账户上10元钱并发放一张南京的公交卡，此卡在使用过程中实时记账，产生费用的实时从其宁波公交卡资金账户上冻结相应的资金，每日晚上12点进行结算并划转相应的资金（由宁波公交卡资金账户上汇划到南京公交卡系统的资金账户）。此旅游者离开南京时就近到一个公交卡互通换发点（不一定要到原换发点）交回南京公交卡（隐含注销了对应的南京系统用户账号），这时南京公交卡系统远程解冻其宁波公交卡资金账户上的10元钱。异地互用完毕。如果此卡一直没有交回，南京公交系统可以认为一直有效，但冻结的10元钱押金可以在一定时间后汇划至南京，若南京、宁波都存在这样的情况，可以只汇划两地总数的差额。在结算费用时，也可只汇划两地异地消费的差额。

Claims (10)

1.一种不同系统用户账号共享的方法，其特征在于：

至少两个非统一用户管理的不同系统，其中一个系统可以识别非本系统的另一个系统的用户账号、此用户账号的等价标识或用于标识此用户账号的实物载体并直接通过此另一个系统的查验接口或通过第三方查验入口使用此另一个系统的查验接口进行查验，然后对于查验通过的赋予本系统的权限，或者然后在查验通过的基础上再根据查验所获取的账户情况对比本系统权限设定条件的情况赋予本系统的权限或不赋予本系统的权限；

对于查验通过的赋予本系统的权限或在查验通过的基础上再根据查验所获取的账户情况对比本系统权限设定条件的情况赋予本系统的权限的情形，本系统为此另一个系统用户账号提供对应的本系统用户账户，或本系统先为之提供对应的本系统用户账户然后再为之发放用于标识此本系统用户账号的实物载体，或本系统先为之提供对应的本系统用户账户然后再使原用于标识此另一系统用户账号的实物载体能够标识此本系统用户账户。

2.根据权利要求1所述的不同系统用户账号共享的方法，其特征在于：

查验过程要求口令验证或不要求口令验证；

和/或所述本系统为之发放用于标识该账号的实物载体永久有效或临时有效；

和/或所述本系统为之提供对应的本系统用户账户永久有效或临时有效；

和/或所涉及的资金清算采用基于另一个系统的原资金账户先冻结后记账最后结算支付的方法，或采用基于另一个系统的原资金账户实时结算支付的方法，或采用基于本系统的新资金账户实时结算支付的方法，或者上述三种资金清算方法其中任意一种的基础上另要求一定数量资金作为担保。

3.根据权利要求1或2所述的不同系统用户账号共享的方法，其特征在于：

所述用户账号采用符合正则表达式userName|userID@host[:(port|protocol)]的格式；

和/或建立各系统接口汇总表。

4.根据权利要求1或2所述的不同系统用户账号共享的方法，其特征在于：

已赋予本系统权限的此另一个系统用户账号在使用本系统中获取到的信息或其它用户通过本系统发送给此已赋予该本系统权限的此另一个系统用户账号的信息可由本系统通知或转发。

5.根据权利要求4所述的不同系统用户账号共享的方法，其特征在于：

通知或转发的目的为此另一系统用户账号的原系统、主登录系统、所有登录系统、主赋权但未登录系统或所有赋权但未登录系统。

6.一种不同系统用户账号共享的方法，其特征在于：

至少两个非统一用户管理的不同系统，其中一个系统在识别本系统的用户账号、此用户账号的等价标识或用于标识此用户账号的实物载体并验证后，或者基于权利要求1、2、3、4或5所述的方法识别非本系统的另一个系统的用户账号、该用户账号的等价标识或用于标识该用户账号的实物载体并查验通过后，本系统向其它至少一个系统通过该其它系统的查验推送接口或通过第三方查验推送入口使用该其它系统的查验推送接口推送用户账号查验情况，然后该其它系统赋予该其它系统的权限，或者再根据查验情况对比该其它系统权限设定条件的情况赋予该其它系统的权限或不赋予该其它系统的权限；

对于该其它系统赋予该其它系统的权限或在对比该其它系统权限设定条件的情况赋予该其它系统的权限的情形，该其它系统为此用户账号提供对应的该其它系统用户账户，或该其它系统先为之提供对应的该其它系统用户账户然后再为之发放用于标识此该其它系统用户账号的实物载体，或该其它系统先为之提供对应的该其它系统用户账户然后再使原用于标识此用户账号的实物载体能够标识该其它系统用户账户。

7.根据权利要求6所述的不同系统用户账号共享的方法，其特征在于：

本系统验证过程要求口令验证或不要求口令验证；

和/或所述该其它系统为之发放用于标识该账号的实物载体永久有效或临时有效；

和/或所述该其它系统为之提供对应的该系统用户账户永久有效或临时有效；

和/或所涉及的资金清算采用基于本系统的原资金账户先冻结后记账最后结算支付的方法，或采用基于不系统的原资金账户实时结算支付的方法，或采用基于该系统的新资金账户实时结算支付的方法，或者上述三种资金清算方法其中任意一种的基础上另要求一定数量资金作为担保。

8.根据权利要求6或7所述的不同系统用户账号共享的方法，其特征在于：

所述用户账号采用符合正则表达式userName|userID@host[:(port|protocol)]的格式；

和/或建立各系统接口汇总表。

9.根据权利要求6或7所述的不同系统用户账号共享的方法，其特征在于：

已赋予该其它系统权限的此用户账号在使用该其它系统中获取到的信息或其它用户通过该其它系统发送给此已赋予该其它系统权限的用户账号的信息可由该其它系统通知或转发。

10.根据权利要求9所述的不同系统用户账号共享的方法，其特征在于：

通知或转发的目的为此用户账号的原系统、主登录系统、所有登录系统、主赋权但未登录系统或所有赋权但未登录系统。