CN104081425A - 基于电子支票的付款*** - Google Patents

Abstract

本发明涉及信息技术的领域，具体而言，涉及电子***和用于资金流通的方法，并且可用于解决在电子付款***的用户之间实时结算的问题。在本发明中，由支付给持票人的电子银行支票提供货币资金，其符合银行规定和适用的法规。客户端应用程序单元根据对应于由客户端和服务器应用程序授权单元确定的用户的状态的分类被分组为模块，其中对于每个分类可预选择用于支票的流通的参数组。当发放了支票，产生法律上有效的文件并且在支票的活动的登记簿中反映交易。

Description

基于电子支票的付款***

技术领域

本发明涉及信息技术的范围，具体而言，涉及一种电子***和货币资金流通方法并且可用于解决处于实时模式的电子付款***的参与者之间相互结算的问题。在这种情况下，讨论的本发明中的货币资金的模拟是符合银行规定和适用的法规的要求的电子银行持票人支票。

背景技术

使用电子支票来解决相互结算问题的电子付款***是公知的。具体而言，使用电子支票作为付款商品和服务的手段的CyberCheck***已称为普通现象。在该***中，支票仅用于执行付款操作并且仅在其被用户签名后生成，其无法确保全部范围的货币资金流通、极大地缩减了结算***能力并且产生了用于发放非划线支票的先决条件。

同样熟悉的是NetChex***，其是有条件电子付款***。在该***中，仅接收以电子形式的客户发放支票的命令，并且支票将以纸质形式发送至服务/商品的供应商，其同样缩减了结算***能力并且使支票流通过程大大地复杂化。

使用用于结算目的的Paymer数字支票也是公知的。在该***的实现中，有关支票在它们的流通中的信息以文件验证的形式存储在硬拷贝中，并且通过***用户之间的支票执行交易既可能以电子形式也可能以硬拷贝。而且，支票不涉及具体所有者，从而产生了支票的“共同拥有”问题。很明显该***不允许排除实现电子相互结算中的风险并且无法确保所有电子支票处理操作的透明度。

发明内容

本发明的目标在于提供一种电子货币***，该电子货币***通过使用电子模拟的银行支票支持以实时模式的在其参与者之间的电子相互结算，为其参与者提供高等级的安全性和获得全面的、在法律上有效的有关由***中的参与者执行的所有交易的文献数据库的可能性。

由本发明实现的技术成果包括产生多功能的电子支票流通***以及通过使用由电子支票记账的工程手段和方法两者所确保的电子支票、对电子支票的真实性的验证和***参与者的认证，并且通过确保电子支票流通的完整循环增强了相互结算的安全性，电子支票流通的完整循环包括电子支票的发放和付款以及电子支票转账的执行的方法。

为了实现上述技术成果，使用一种电子支票结算***，该电子支票结算***包括：用于数据处理和存储的至少一个服务器计算机设备，所述至少一个服务器计算机设备包括服务器应用程序，和用于数据处理的至少一个客户端计算机设备，所述至少一个客户端计算机设备包括固件客户端模块，该固件客户端模块通过使用加密和电子数字签名的服务器和客户端模块的固件手段确保在因特网网络通信信道上客户端计算机设备连接到服务器设备以及保护通信信道的可能性。在这种情况下，正在讨论的用于电子支票的电子结算***与原型的不同在于，客户端和服务器应用程序至少包含：在互连的***中用户授权的互连的单元，用于更新和同步客户端和服务器应用程序数据的单元，以及用于执行转账和存储有关客户端应用程序付款的信息的参数输入单元，该用于执行转账和存储有关客户端应用程序付款的信息的参数输入单元通过固件与用于验证电子支票转账的参数的单元相关，用于验证电子支票转账的参数的单元连接至授权和验证用户参数的单元和用于注册和执行服务器应用程序电子支票转账的单元，所述用于注册和执行服务器应用程序电子支票转账的单元通过反馈信道连接至用于电子支票管理、支票存放、佣金，以及以实时模式向用户发送通知的单元，其连接至用于更新和同步客户端应用程序数据的单元，以及包括由客户端应用程序组成的电子签名单元，该电子签名单元通过固件连接至用于产生和存储服务器应用程序的数字文件的单元，该用于产生和存储服务器应用程序的数字文件的单元连接至用于注册和执行电子支票转账的单元，而且，服务器应用程序的电子支票管理单元通过固件在反馈信道上连接至用于注册电子支票交易的互连的单元，该互连的单元连接至电子支票签名单元。

在这种情况下，客户端应用程序单元通过对应于由客户端和服务器应用程序的授权单元确定的用户状态的类别分组成模块，并且提供了对于每个类别预设置支票流通参数的分组的可能性。

具体而言，***提供三种类别的用户-具有最小组的支票流通参数的初始类别(在操作模式下，当通过交易机构(经纪机构)执行标准用户类别中的电子支票的转账以及银行的转账时-初始类别专门用于注册和发送用于改变状态(用户类别)的申请)；标准类别-需要提供有关参与者的附加数据并且使参与者能够向银行提供用于付款的支票并且为其支票选择付款银行；以及扩展类别-具有最广的功能能力的组，旨在操作***的发放机构、合作银行和交易机构(经纪机构)，并且提供了对于类别产生附加组的支票流通参数的可能性。在这种情况下，为了参与作为法人实体的***，客户应当被指定到标准或扩展类别，其仅可在完成对应的状态改变过程的过程中获得，其保证了所有组织的必要支票的执行。

技术成果还通过以下事实实现：提出利用上述付款***进行付款、发放、转账和验证电子支票的方法。

在这种情况下，用于实现电子支票转账的方法，包括用户数据输入和在***中它的授权以及转账数据的输入的阶段，不同之处在于它根据在电子支票记账方法中所提供的限制允许以实时模式进行支票转账，并且包括以下阶段：在***中授权；接收账户数据；输入电子支票转账参数；验证电子支票参数；注册用于实现电子支票转账的请求；涉及将发送者的支票兑换成若干支票(转账支票、佣金支票、新余额支票)的交易，该交易包括：提供用于付款的支票、新支票的付款和发放；将电子支票佣金存入操作者的账户中或当将标准用户类别的电子支票以及银行的电子支票通过交易机构(经纪机构)转账至交易机构的(经纪机构的)账户时，以***操作模式进行；将电子支票存入收款人的账户；涉及将收款人的支票兑换成单个支票(在收款人在其账户中有余额的情况下)的交易，该交易包括提供用于付款的支票；伴随着电子文件的创建和签名的转账的终止，以及转账执行的参与者通知。用于实现电子支票转账的该方法伴随着必要的在法律上有效的文件的创建，其具有在支票登记簿中反映的所有完成的动作。

本发明所提供的用于发放电子支票的方法仅允许在由若干用户类别完成强制阶段之后发放电子支票。发放的方法包括通过发放机构产生支票发放请求，以及银行对存放在发放机构的结算账户中的钱的验证(所发放的支票的安全性)，与请求参数的一致性和银行对电子支票发放的确认的强制阶段。由单个参与者独立发放是不可能的。发放伴随着法律上有效的文件的创建和在支票登记簿中反映了交易。

电子支票付款的方法还包括若干阶段并且需要必须参与的若干用户类别。该方法包括以下阶段：客户将申请发送至用于支票付款的银行；银行对在申请中指定的细节和支票付款的可能性进行验证；银行将***传送至客户以存入支票；通过所发放的***的付款，由客户将提供用于付款的支票转账给银行；银行将请求发送至发放机构以验证支票；发放机构对提供用于付款的支票进行验证；发放机构通过发送验证通知来确认请求；以及实现支票付款。

附图说明

图1为使用与本发明相关的方法的***的示意图。

图2为包括客户端应用程序的主单元。

图3为包括服务器应用程序的主单元。

图4为主客户端应用程序DB(俄文缩写：БД)部分的图示。

图5为主服务器应用程序DB部分的图示。

图6为在实现电子支票转账中单元交互的图示。

图7为用于参数输入和实现转账的客户端K5单元的操作算法的流程图。

图8为用于执行用于注册和实现电子支票转账的服务器S5单元的操作的程序的流程图。

图9为用于交易(整合)用于电子支票管理的服务器S7单元的电子支票的程序的流程图。

图10为在实现电子支票发放程序中单元交互的图示。

图11为在实现电子支票付款程序中单元交互的图示。

图12为在实现电子支票验证程序中单元交互的图示。

下列标号用于上述原理图中：

K1–用于在***中注册的客户端单元(KB R(俄文缩写：КБ Р))

K2–用于在***中授权的客户端单元(KB A(俄文缩写：КБ А))

K3–用于客户端和服务器应用程序DB的数据更新、同步的客户端单元(KBODS(俄文缩写：КБ ОДС))

K4–用于与服务器交互的客户端单元(KB VS(俄文缩写：КБ ВС))

K5–用于转账的参数输入、执行的客户端单元(KB VDVP(俄文缩写：КБ ВДВП))

K6–用于将支票存入账户的***的数据输入、发送的客户端单元(KB VDOS(俄文缩写：КБ ВДОС))

K7–用于购买、出售电子支票的应用的数据输入、发送的客户端单元(KBOZPPECh(俄文缩写：КБ ОЗППЭЧ))

K8–用于电子支票的付款的应用的数据输入、发送的客户端单元(KBOZOECh(俄文缩写：КБ ОЗОЭЧ))

K9–用于处理所接收的电子支票转账的客户端单元(KB OPPECh(俄文缩写：КБ ОППЭЧ))

K10–用于处理所接收的用于将支票存入账户的***的客户端单元(KBOPSZCh(俄文缩写：КБ ОПСЗЧ))

K11–用于数字文件的电子签名的客户端单元(KB TsP(俄文缩写：КБ ЦП))

K11(发放机构)–用于对发放电子支票的请求的数据输入、发送的客户端单元(KBE OZVECh(俄文缩写：КБЭ ОЗВЭЧ))

K12(发放机构)–用于处理所接收的用于验证电子支票的请求的客户端单元(KBE OPZVFECh(俄文缩写：КБЭ ОПЗВФЭЧ))

K13(银行)–用于处理所接收的对发放电子支票的请求的客户端单元(KBBOPZVECh(俄文缩写：КББ ОПЗВЭЧ))

K14(银行)–用于处理所接收的用于电子支票的付款的应用程序的客户端单元(KBB OPZOECh(俄文缩写：КББ ОПЗОЭЧ))

K15(银行)–用于对验证电子支票的请求的数据输入、发送的客户端单元(KBB VDOZVFECh(俄文缩写：КББ ВДОЗВФЭЧ))

K16(发放机构)－用于处理所接收的用于购买电子支票的应用程序的客户端单元(KBE OPZPECh(俄文缩写：КБЭ ОПЗПЭЧ))

K16(交易机构)－用于处理所接收的用于购买电子支票的应用程序的客户端单元(KBE OPZPECh(俄文缩写：КБД ОПЗПЭЧ))

K17(交易机构)－用于处理所接收的用于出售电子支票的应用程序的客户端单元(KBE OPZPrECh(俄文缩写：КБД ОПЗПрЭЧ))

S1–用于注册、管理用户账户的服务器单元(SB RUUZP(俄文缩写：СБ РУУЗП))

S2–用于授权和验证用户参数的服务器单元(SB APPP(俄文缩写：СБ АППП))

S3–用于客户端和服务器应用程序DB的数据更新、同步的服务器单元(SBODS(俄文缩写：СБ ОДС))

S4–用于验证电子支票转账参数的服务器单元(SB PPPECh(俄文缩写：СБ ПППЭЧ))

S5–用于注册和执行电子支票转账的服务器单元(SB RVPECh(俄文缩写：СБ РВПЭЧ))

S5–用于用户账户管理的服务器单元(SB UUSP(俄文缩写：СБ УУСП))

S6–用于注册用于将支票存入账户的***、请求、申请的服务器单元(SBRZZSZECh(俄文缩写：СБ РЗЗСЗЭЧ))

S7–用于电子支票管理的服务器单元(SB UECh(俄文缩写：СБ УЭЧ))

S8–用于在登记簿中注册电子支票交易的服务器单元(SB ROEChR(俄文缩写：СБ РОЭЧР))

S9–用于产生数字文件的服务器单元(SB GTsD(俄文缩写：СБ ГЦД))

S10–用于发送在线通知的服务器单元(SB OOU(俄文缩写：СБ ООУ))

S11–用于发放电子支票的服务器单元(SB VECh(俄文缩写：СБ ВЭЧ))

S12–用于对电子支票进行签名的服务器单元(SB PECh(俄文缩写：СБ ПЭЧ))

S13–用于处理和执行申请、请求的服务器单元(SB OIZZ(俄文缩写：СБ ОИЗЗ))

S14–用于核销电子支票的服务器单元(SB SECh(俄文缩写：СБ СЭЧ))。

具体实施方式

本发明的目的在于提供一种在组织和/或个人之间以实时模式的电子支票结算***(“***”)。在技术上，该***的实现可包括用于数据处理和存储的至少一个服务器计算机设备、构成该至少一个服务器计算机设备的服务器应用程序，以及用于利用构成客户端计算机设备的客户端应用程序来进行数据处理的客户端计算机设备，所述客户端应用程序提供在客户端计算机设备和服务器计算机设备之间的交互。利用因特网网络在受保护的通信信道上进行客户端计算机设备与服务器的交互。通过借助于加密和电子数字签名算法的服务器和客户端应用程序提供对通信信道的保护。

本文所提供的方法以服务器和客户端计算机设备的对应的操作算法进行表示。通过执行在服务器和客户端应用程序中提供的程序指令的序列来确保设备的操作与给定的算法一致。服务器设备或设备组的体系架构应当基于通过局域网结合的一个或若干计算机的使用，并且应当至少包括以下模块：数据库管理***(DBMS)、网络服务器(经由因特网提供与客户端应用程序的交互的模块)、应用程序服务器(实现主要应用程序逻辑和确保与DBMS的交互的模块)，以及在线消息的模块(向用户提供有关***内的事件的即时信息)。

客户端设备体系架构可基于以下可能的客户端应用程序的解决方案：具有其自身的用户界面的单独的客户端应用程序(将在下文中进行描述)；以内置在标准工具中的模块的形式的客户端应用程序，该标准工具用于利用将被体现在网络浏览器中的其自身的用户界面查看因特网网络资源(网络浏览器)(具有与下文中所描述的相同的单元和交互模式)；在基于网络浏览器的瘦客户端形式中，具有用于数据处理和用户界面生成的单元到服务器的传输。在瘦客户端模式中，仅在客户端设备上处理在网络浏览器用户界面中的数据输入、数字文件的电子签名、数据加密、到服务器的数据传输、从服务器的数据接收、解密和到网络浏览器用户界面的输出。在这种情况下，在以内置模块或瘦客户端的形式实现客户端应用程序的情况下，客户端设备和整个***作为整体在使用基于具有其自身的界面的单独客户端应用程序的客户端设备的情况下具有与***等同的功能能力。

上述***不限制本发明的任何可能的实现。

图2和图3给出以功能单元形式的客户端和服务器应用程序的结构。在所考虑的***实现中，客户端应用程序具有若干操作模式，其由已在***中授权的用户的状态确定。以发放机构、银行、交易机构(经纪机构)形式分配附加的单元。其余的单元在任何操作模式下都是可访问的(由具体的***实现的特性确定可能的限制)。在其中存在一个以上客户端应用程序的实现是可能的，在客户端应用程序的每一个中对应的单元组是可访问的。

参与者类别

假设在***中存在参与者的三个主要状态。在这种情况下，参与者应当是具有以电子形式存在于***数据库中的有关它们的信息的用户(法人实体或个人)，***数据库利用客户端计算机设备进行与***的交互。该状态产生将被授予参与者的一组权限，从而参与者获得执行***中的某些算法的可能性并且得到***中可用的一定量的信息的访问。

初始状态为参与者等级，其被限制到***内的可能性的组，并且不需要提供用于确认由用户在注册时输入的信息的文件。在初始等级，仅在作为个人时才可能注册。法人实体仅可在从初始等级转变到标准等级的情况下在***中注册。在这种情况下，在***操作模式中，当经由交易机构(经纪机构)执行具有标准状态的用户的电子支票以及银行的电子支票的转账时，初始类别仅用于注册和发送对改变状态(用户分类)的状态请求。

标准状态是为授权的***的参与者设计的等级，无论参与者是个体还是法人实体)。为了获得该状态，参与者有义务提供有关它自身的附加信息和用于其确认的多个文件。该状态使参与者能够向银行提供用于付款的支票并且为其支票选择付款银行。

扩展的状态是为***的发放机构、合作银行和交易机构(经纪机构)的操作设计的等级。

为了确保本发明中提出的方法的可操作性，以下参与者应当有义务在***中注册：

·发放机构–所代表的执行电子支票的发放的组织；

·操作员–确保***的运行的***的权限的所有者；

·至少一个银行－合作银行，其中作为对于发放的支票的保障的货币资金被存入到发放机构的结算账户中；

·至少一个交易机构(经纪机构)－长久地执行与参与者的电子支票购买和出售交易以及从交易机构购买支票的法人实体。

注册为银行、交易机构(经纪机构)的参与者还可充当客户并且使用标准的***功能。

图1中给出类似***的概图。

为了得到对应的状态并且获得在***中工作的可能性，参与者应当完成根据所请求的状态的注册，该注册由不同数量的阶段组成。***中的注册的第一阶段通过客户端应用程序执行并且包括输入参与者的个人数据、设置安全参数、熟悉要约协议，以及产生用于EHS(俄文缩写：АСП)(等效手写签名)的电子密钥。作为注册的第一阶段的结果，参与者被分配唯一的注册号－设计用于EHS验证的公共密钥利用其名字在***服务器中进行注册，并且参与者的数据被记录在***数据库中。

作为注册的第一阶段的结果，用户被分配初始状态。为了获得标准的或扩展的状态，参与者应当经由***产生电子申请，在电子申请中参与者应当指定类别(个人/法人)并且输入所有所请求的信息。为了确认所输入的信息，参与者应当提供文件的正式核准的副本。仅在成功完成文件验证阶段并且如果有必要的话，输入附加的协议(针对银行、交易机构(经纪机构)、发放机构)之后，参与者将被发放所请求的状态并且拥有***内对应的权限的组。

具有***中的任何状态的参与者都可打开以***所支持的币种表示的无限数量的账户。具有大于初始状态的状态的参与者具有选择用作支票的付款银行的银行的能力，支票的票面价值等于账户余额。在打开账户时，参与者将被分配***中唯一的编号，根据该唯一的编号，可毫无疑义地执行参与者的识别。

电子支票

***中的货币资金的等效物是电子支票。电子支票是以非文件形式的持票人支票并且包含以下必要的细节：

·支票编号－支票的唯一标识符；

·包括在文件文本中并且以在其中已经制定了该文件的国家的语言表示的“支票”的描述；

·对付款一定额度(支票的票面价值)的要求；

·付款银行的名称；

·应当从其执行付款的账户的指示；

·付款货种的指示；

·支票执行的日期和地点的指示；

·发放机构的(支票的开票人的)签名。

非文件形式的支票应当被认为是合法的并且根据俄罗斯银行规定“关于在俄罗斯联邦的无现金结算”以这种形式制定的支票被视为有效的付款工具，这意味着下文所描述的电子支票处理方法的特殊性。

电子支票以DB记录的形式提供。电子支票签名以EHS(等效手写签名)形式提供，其由于利用发放机构的不公开密钥加密转换支票细节而获得，并且确保保护电子支票不被伪造，同时允许识别支票出票人和确定电子支票中没有信息失真。

在参与者的账户中执行电子支票的记账。在完成支票兑换操作时，仅一个票面价值为账户余额的支票可涉及***中的一个标准的客户账户。为了向银行提供用于付款的支票的记账的目的，使用专门的账户，该专门的账户中可同时存入若干个电子支票。

电子支票的特征在于以下状态：

·支票是流通的–有效的支票受***参与者中的一个支配；

·支票已被提交用于付款(至付款银行)；

·支票已被提交用于通过托收进行付款；

·支票已支付。

电子支票的状态的变化或支票所有者的变化可由于某些操作(比如支票发放、支票转账、用于付款的支票提交、用于通过托收进行付款的支票提交、支票付款，或兑现)而发生。所有的电子支票交易应当被记录在支票登记簿中并且伴随着利用对应的参与者的EHS进行验证的法律上有效的文件的产生。

电子支票具有有限期限的有效性，在其逾期时，电子支票自动兑换为具有新的编号和发放日期的等效支票。

用于实现电子支票转账的方法

这里所提供的用于实现电子支票转账的方法由一定顺序的过程的主要阶段(无论对执行是必要的或是非必要的)组成。阶段的必要性通过满足以下描述的算法中所公开的某些条件进行确定。实现算法的特殊性(比如编程语言、实现方法的软件的体系架构特殊性)不受给出的本发明限制。

本方法假设参与者的计算机设备配置成使得其允许执行实现该方法并且经由因特网与服务器计算机设备交互的客户端应用程序的程序指令。

实现转账过程的开始是用户的客户端应用程序的启动，在此期间，初始化***中的用于授权的K2客户端单元。在执行该单元的过程中，应当进行利用对应于各自状态的权限对参与者的账户及其投资进行验证。为了执行这些操作，K2客户端单元通过用于与服务器交互的K4单元与用于授权和验证用户参数的S2服务器单元连接。在这种情况下，在K4单元中，当接收到命令和必要的数据时，将执行以下：产生以所需格式的请求、加密、请求的签名、建立与服务器的连接、请求的传输(在受保护的通信信道上经由因特网)，并且处理答复。假设所有客户端单元与服务器单元的交互通过K4单元进行并且不应当被进一步提及。

客户端和服务器授权单元的实现不是本发明的主题，并且可包括用于用户的认证和授权的公知方法的各种组合。

对这些单元必要的是验证参与者的账户、存储的电子密钥的可访问性和正确性，该电子密钥将进一步用于产生请求的等效手写签名(EHS)和电子文件，以及获得有关参与者的状态和对应的权限的信息。基于参与者的状态，参与者执行不由参与者的状态提供的动作的可能性被限制；而且，限制发生在客户端应用程序的等级(在不存在对应的用户界面的情况下，在客户端应用程序中执行支票的算法)和服务端应用程序的等级(在处理所接收的每个请求以验证用户状态和其他参数的情况下包括该应用程序的服务器单元应用于S2单元)两者处。

成功执行授权单元保证了参与者不被移除或限制，其不公开的电子密钥对应于在***中注册的公共密钥。

成功执行授权单元对于传输到用于更新、同步客户端和服务器应用程序数据的下一个K3单元是必要条件。客户端K3单元与用于数据更新、同步客户端和服务器应用程序的服务器S3单元进行通信。在执行K3、S3单元的过程中，接收有关参与者的账户的目前状态、接收的转账和用于支票存入账户中的***的信息。根据参与者的状态，接收对应类型的申请、请求并且更新它们的状态。这些单元的执行应当保证参与者对有关所有转账、用于将支票存入到账户中的***、申请、请求的信息和其他信息的访问，其都由参与者发送和接收(例如，通过使客户端应用程序数据库与服务器应用程序数据库同步)。执行这些单元的方法是公知的并且不是本发明的主题。作为***实现的示例，考虑一个版本，从而从服务器接收的信息被存储在本地数据库中，图4示出了该示例的图示。

在成功完成对K3单元的操作之后，应用程序将显示在用户界面中接收的信息，包括有关所有客户的账户的信息：账户的编号、名称、账户中的有效余额、账户所涉及的电子支票的编号、与账户相关联的银行的细节等等。待接收和显示的信息的量应当由***实现版本来确定。

成功执行用于更新、同步客户端和服务器应用程序数据的S3服务器单元和K3客户端单元对于传输到用于参数输入和执行转账的K5单元是必要条件。

为了初始化该单元，参与者应当选择客户端应用程序的用户界面中的对应部分。

K5单元使用户能够输入对于转账电子支票所需要的初始数据。该单元可提供用于输入转账参数的各种可能性：直接输入参数(输入收款人的账户、可接收的支票数额或将被核销的支票数额、付款的目的)、从可能值的列表中选择参数的变量(从发送者的私人账户的列表中选择、从对应的资信手册选择接收者的账户编号)、基于所接收的用于将支票存入到账户中的***或某些类型的申请(例如，用于购买电子支票的申请)产生转账。后面的变量是基于在执行用于更新、同步客户端和服务器应用程序数据的K3单元的过程中接收的和通过对应于***的具体实现的方法存储在应用程序中(在计算机设备的随机存取存储器中或只读存储器中)的信息的使用。输入转账参数的方法可包括将在参数输入过程中执行的自动验证，从而用户将立即被通知任何错误。该方法可包括将在通过应用程序接收转账数额数据的过程中托收用于转账的佣金的数额的自动计算。可基于应用程序的本地数据(将被存储在随机存取存储器或DB中，例如在接收账户数据的阶段下载的)或基于将通过单独请求从服务器下载的佣金率，通过模块进行佣金的计算。该可能性可用于实现更复杂的佣金设置变量，比如佣金率对分组中参与者的状态的依赖性(在这种情况下，为了确定佣金，将需要有关发送者的数据和有关转账的接收者的数据两者)、设置参与者的个体佣金的可能性等等。在计算佣金之后，模块将通知用户有关将被托收用于转账的佣金的总和以及将被核销的总和(或根据所填入的参数的可接收的总和)。

图7给出用于转账的参数输入、执行的K5单元的操作算法的示例。

该实现是可能的，由此在输入转账参数的过程中，有关转账接收者的信息基于接收者的账户编号进行下载并且被显示给参与者，以最小化输入不正确的数据的风险。

该方法可包括用于初步验证转账参数的阶段，在其过程中，K5单元将产生对于数据验证的电子请求并且将其传输至用于验证电子支票转账参数的S4服务器单元。该请求包括发送者的账户和转账接收者的账户编号、价值、转账的币种。在查核的过程中，S4单元将确定利用指定参数执行转账是否可访问。触发S2服务器单元的执行，在该过程中，执行对发送者的必要验证(包括请求EHS的查核)和对转账接收者的必要验证(包括验证接收者的账户的可访问性)。执行从DB取回有关转账发送者的账户中的电子支票的数据、将支票的票面价值与将被核销的数额相比较(该实现是可能的，由此限制账户中单独的数额，随后发生待核销的数额与可访问的有效余额的比较)，以及由***的具体实现的特殊性提供的其他查核。应当通过与存储在***数据库中的信息核对、查核DB中的账户设置、执行验证电子数字签名的算法来进行查核。

用于转账的参数输入和执行的K5客户端单元从S4单元接收有关查核的结果的信息，并且向用户显示或者有关产生错误的消息，或者具有客户应当重复确认的有关转账的信息的窗口。在该阶段，模块可显示有关转账(数额、收款人的名字、INN等等)、方法的对应实现的任何数据。

已经从参与者接收到交易的确认，K5单元将产生电子请求以执行包含用于核销的账户的编号、用于将支票存入到账户中的***的编号、数额、转账的币种、付款的目的的转账，并且将该电子请求传输至用于注册和执行电子支票转账的S5服务器单元。

已经接收到用于执行转账的请求，S5单元将执行转账注册程序。在该程序过程中，为了查核所接收的请求，执行到S4单元的转账以验证电子支票转账参数(传输所接收的所有数据)，并且在其成功执行之后，有关转账的信息将被记录在***数据库中，佣金的数额将被计算并且记录。在S4单元返回错误的情况下，转账将不被注册，并且转账执行的错误结果将被返回至K5客户端单元(例如，交易的状态、错误代码)。

在发送和注册转账执行请求的阶段，可执行用于产生和存储数字文档的单元(S9)。该方法意指或者在服务器应用程序中或者在客户端应用程序中包含该单元。作为操作该单元(在给定情况下，用于产生用于执行转账的申请的过程)的结果，将产生包含用于电子支票转账的申请的所有细节的单独的电子文件(例如以pdf格式)，并且参与者的EHS将通过数字文件的客户端单元(K17)进行确认。该方法意指用于存储该文件的多个变量，例如，文件可被传输至服务器、与EHS和其他信息一起保存在应用程序数据库中并且之后通过服务器应用程序的专门服务而对于所有利益相关者是可访问的。

在已在服务器上产生文件的情况下，用于数字文件的电子签名的单元(K17)应当实现用于从服务器下载电子文件的过程。

在成功将转账记录在服务器DB中之后，S5单元将执行交易实现过程。图8给出了实现该过程的示例。该过程的输入参数为所接收的有关被执行的转账的所有数据。

用于注册和执行电子支票转账的S5单元从***数据库接收有关转账发送者的账户中的电子支票和佣金数额(“有关用户账户的信息”、“有关电子支票的信息”、“有关电子支票转账的信息”)的数据。

如果发送者的账户上的余额支票的票面价值与转账数额一致，而且不托收用于转账的佣金，则电子支票将从发送者的账户直接转账到接收者的账户。

为了转账支票，S5单元开始用于电子支票管理的S7服务器单元的执行。在这种情况下，触发用于电子支票转账的过程，以下数据被传输至其输入：电子支票的编号、转账发送者的账户的编号、转账接收者的账户的编号。在实现该过程时，执行对在DB中的“有关用户账户的信息”中的信息的修改：有关转账发送者的账户中的支票的信息将被移除、有关余额支票的编号的数据将被导入到账户记录中；有关支票持有者的信息将在“有关电子支票的信息”部分中进行修改。

在该过程的框架中，启动执行S8单元以在登记簿中注册电子支票交易。在触发用于将支票转账交易记录在登记簿中的过程时，输入参数如下：电子支票的编号、转账发送者的账户的编号、转账接收者的账户的编号、交易的类型(“支票转账”)。在支票登记簿中交易的可能类型如下：“支票发放”、“支票转账”、“用于付款的支票提交”、“用于通过托收进行付款的支票提交”、“支票的付款”、“支票托收”。基于输入参数，S8单元从DB取回必要的数据，将记录导入“电子支票登记簿”DB部分，“电子支票登记簿”DB部分包括至少以下信息：交易的编号、日期、时间、数额、币种、被转账的支票的编号、发送者的账户和接收者的账户编号、交易的类型、有关账户中的余额的数据。在成功将交易记录在支票登记簿中之后，将终止用于S7单元的电子支票转账的过程。

该实现是可能的，由此在类似的情况下，当支票的整个票面价值应当被转账至接收者时，电子支票将首先被转账至操作者，并且操作者将会将支票转账至转账接收者。在用于以上描述的电子支票管理的S7服务器单元的用于电子支票转账的过程的框架内进行支票转账(如所有对其的进一步引用中)。

如果上述条件不被满足(支票的票面价值不应当被全部转账至接收者)，S5单元将触发用于兑换用于电子支票管理的S7单元的电子支票的过程。S5单元将以下数据传输至该过程的输入：票面价值为发送者的账户中的余额的电子支票的编号、应当执行兑换的等于转账数额的电子支票的票面价值，以及将被托收用于转账的佣金的数额。

在用于S7单元的电子支票兑换的过程的框架内，发送者的电子支票将被转账至***操作者(执行该过程以供用于电子支票管理的S7服务器单元的电子支票转账，以下数据将被传输至其输入：电子支票的编号、转账发送者的账户的编号、操作者的账户的编号)。

操作者提交所接收的电子支票以向付款银行进行付款。通过执行提交用于电子支票管理的S7单元的付款的支票的过程来进行用于付款的电子支票的提交，以下数据将被传输至其输入：电子支票的编号、有关银行的信息(注册编号)、提供支票的账户(操作者的账户)的编号。在实现该过程时，确定支票将转账的专门的银行账户的编号。然后，类似于标准的支票转账过程执行支票转账。一个不同在于***DB中的电子支票状态变成“提交用于付款”状态(“有关电子支票的信息”部分)以及在交易类型的支票登记簿中的指示：在执行用于在登记簿中注册电子支票交易的S8单元的情况下，“用于付款的支票的提交”或“用于通过托收进行付款的支票的提交”。当电子支票被提供用于付款的银行和用于给定支票的付款银行不一致时，使用交易类型“用于通过托收进行付款的支票的提交”。

在成功执行用于提交用于付款的支票的过程之后，只要电子支票被提交用于付款的银行和用于给定支票的付款银行一致，则触发S7单元的支票核销过程的执行，电子支票编号将被传输至其输入。在“有关电子支票的信息”部分中的该程序的架构内，有关已付支票的数据将被改变，并且将触发用于在登记簿中注册电子支票交易的S8单元的执行。在用于将支票核销交易记录在“电子支票登记簿”部分中的登记簿中的过程的框架内，包含以下数据的记录将被导入：交易的编号、日期、时间、价值、币种、将被核销的支票的编号、将被核销的支票涉及的账户的编号、交易的类型、有关在给定账户中的余额的数据。仅在支票的付款和将等于支票的票面价值的实际货币资金传递至其持票人的情况下或在由已提交用于付款的支票的个人利用***发放机构购买新的电子支票时抵销利用支票的付款放出的货币资金的情况下，执行电子支票的核销过程是可能的。

在成功将交易记录在支票登记簿中之后，将终止用于S7单元的电子支票核销的过程。

利用接收的(放出的)的资金，操作者将从发放机构购买所需票面价值的支票：

○用于转账的数额的支票。

○用于佣金的数额的支票(可以等于0，在等于0的情况下，将不发放支票)。

○用于余额的数额的支票(余额可以等于0，在余额等于0的情况下，将不发放支票)。

为此，在电子支票兑换过程的框架内，S7单元对于正在讨论的每一个支票循序地触发用于电子支票发放的S11单元的执行。有关新的支票的细节的数据应当被传输至该单元的输入，其至少包括以下：票面价值、支票币种、有关付款银行的数据。作为新支票的付款者，将指示所转账用于兑换的支票的付款银行。

在实现S11单元时，从***DB取回用于指示所有支票细节的必要数据，触发用于电子支票签名的S12单元的执行(从而通过执行电子数字签名算法产生代表发放机构的支票签名)，并且将在“有关电子支票的信息”DB部分产生有关新电子支票的记录。

在实现电子支票发放时，S11单元将导致执行将用于电子支票交易的注册的S8单元的支票发放交易记录在登记簿中的过程。在该过程被触发的情况下随着输入参数，以下数据将被传输：电子支票的编号、所发放的支票将涉及的账户(发放机构的账户)的编号、交易的类型(“支票发放”)。在该过程的框架内，记录应当被导入包含以下数据的“电子支票登记簿”DB部分：交易的编号、日期、时间、价值、币种、所发放的支票的编号、交易的类型、所发放的支票将涉及的账户的编号、有关在给定账户中的余额的数据。在将交易成功记录到支票登记簿中之后，将针对已经触发执行的单元的支票终止用于电子支票发放的S11单元的操作。

在成功终止S11单元的操作之后，所发放的支票将转账至操作者(根据用于电子支票管理的S7单元的电子支票转账的过程)。

如果余额支票已成功发放，操作者将该支票转账给转账发送者，在成功终止该动作之后，将针对转账发送者的支票终止用于电子支票兑换的过程。

在S5单元的操作的框架内，操作者将用于转账的数额的支票传送至接收者的账户。S5单元将从数据库(“有关用户账户的信息”部分)取回有关转账接收者的账户中的余额和账户设置的信息。在接收者的账户中存在余额支票或在给定账户的设置中指定与用于转账支票的付款银行不同的银行的情况下，S5单元将触发用于电子支票管理的S7单元的电子支票兑换(整合)的程序(图9)。在该程序的框架内，多个电子支票(一个电子支票)应当从接收者的账户转账至***操作者的账户。

操作者应当向根据转账接收者的“余额支票”指定作为付款银行的银行或在没有余额的情况下在账户的设置中指定的银行提交所接收的用于付款的多个电子支票(一个电子支票)。除了所提供的信息之外，其他方法也可以用于根据转账接收者的新支票确定将作为付款者的银行，例如，代替利用账户设置和目前余额支票的数据，可根据具有更大票面价值的电子支票选择付款银行。

应当在用于电子支票管理的S7单元的提交用于付款的支票的程序的框架内执行向银行提交支票以进行付款。

应当根据用于托收的支票提供的机构进行向银行的用于付款的支票提交，该银行与指定作为用于给定支票的付款银行的银行不同。该程序保证在充当对由发放机构发放的支票的保护的合作银行中发放机构中的结算账户中的足够量的货币资金的可用性。

对于向付款银行提交的用于付款的电子支票(在所描述的实现中，来自转账接收者的账户的余额支票)，触发用于电子支票管理的S7单元的标准支票核销程序的执行。

使用发布的资金，操作者从发放机构得到新的支票，该新的支票的票面价值等于提交用于兑换的支票的票面价值的总和(或等于所提交的用于兑换成另一付款银行的支票的支票的票面价值)。

为此，在用于电子支票兑换(整合)的程序的框架内，S7单元触发用于电子支票发放的S11单元的执行，而将票面价值、支票的币种(等于将被整合的支票的币种)和有关付款银行的数据传送至其输入。新的支票的付款者将会是已执行提交用于兑换的支票的付款的银行。

发放机构应当将所发放的支票转账至***操作者。操作者应当将新的支票转账至转账接收者。在成功实现这些动作之后，将终止用于电子支票兑换(整合)的程序。

该实现是可能的，由此不执行发送者的支票的转账的兑换，并且任何数量的电子支票的记账被保留在接收者的账户中。例如，在所描述的实现中，如果在用于付款的支票提交的框架内进行转账实现并且支票被转账至专门的银行的账户，则不执行用于电子支票的兑换的程序。

在佣金被托管以进行转账的情况下，S5单元将触发用于将佣金支票存入到账户中的S13单元的执行。在所描述的实现中，如果在操作者的账户中有余额支票或在操作者的账户的设置中指示与佣金支票的付款银行不同的银行，则S13单元也将启动用于电子支票管理的S7单元的电子支票兑换(整合)的程序的执行，在此过程中，包括用于完成转账的佣金的数额的新的支票应当被存入到操作者的账户中。操作者的电子支票的兑换顺序类似于转账接收者的支票兑换的兑换，除了涉及到操作者的支票转账和从***操作者接收支票的交易。还必须考虑，如果通过交易机构(经纪机构)执行支票转账，则应当在S13单元中向在转账实现中充当中介机构的交易机构(经纪机构)而不是操作者付款佣金。支票兑换交易总是通过操作者执行，而不管接收者的佣金如何。

在实现用于注册和执行电子支票转账的S5单元的用于执行交易的程序时，触发S9单元的执行以产生和存储数字信息。作为该单元的操作的结果，基于接收的有关转账参数的信息，为了由参与者的EHS对其签名和提供进一步的打印输出的可能性的目的而创建数字报告文件。

在所描述的实现中，在S9单元的操作中，产生以下文件：接受电子支票的证书、提供的服务的证书、形式***。利用对应的一方的EHS签名由于用于数字文件的电子签名的K17单元的执行产生的文件。

在成功执行转账和产生所需的文件之后，S5单元将启动用于发送在线通知的S10单元的执行。有关转账接收者和被发送的消息的类型的信息被传输至该单元的输入。作为执行该单元的结果，触发K3单元的执行以用于更新、同步客户端和服务器应用程序数据。在接收有关转账的信息之后，为了由转账接收者签名接受支票的证书的目的，可触发K17单元的执行以对数字文件进行电子签名。

在终止用于注册和执行电子支票转账的S5单元的操作的情况下，因交易的结果而产生消息，该消息被传输至用于转账的参数输入、执行和存储有关转账发送者的申请的付款有关的消息的K5单元。该实现是可能的(申请的操作模式)，由此不以在线模式执行用于注册和执行电子支票转账的S5单元的执行交易的程序，即，在成功终止S5单元的注册转账的程序之后，有关转账已被***接收的事实的消息将立刻被发送至转账发送者(K5单元)，并且稍后执行交易执行程序。

在接收有关终止交易的消息的情况下，用于转账的参数输入、执行和存储有关转账发送者的付款的信息的K5单元向用户显示有关转账结果的信息，触发用于更新、同步客户端和服务器应用程序数据的K3单元的执行，在K3单元的操作终止时进行有关用户账户中的目前余额的信息的更新。

电子支票发放的方法

以下，提供一种用于电子支票发放的方法，该方法待用于与涉及在转账的实现中自动兑换电子支票的交易不同的情况。该方法的目的在于确保接收利用发放机构的结算账户中接收的实际货币资金(例如，通过交易机构(经纪机构)购买支票，而不是利用用于其他电子支票的付款)发放的用于流通的新的支票的过程的安全。

电子支票发放的过程的开始是通过具有发放机构的账户的用户启动客户端应用程序，在启动过程中初始化用于在***中授权的客户端K2单元，在其之后将启动执行K3单元，以更新、同步客户端和服务器应用程序数据。成功执行K2和K3单元是用于转账到用于对发放电子支票的请求的数据输入和发送的K11单元的必要条件。为了初始化该单元，发放机构应当选择在客户端应用程序的用户界面中对应的部分。

K11单元为用户提供了产生对发放电子支票的请求所需要的初始数据的输入的可能性。该单元可提供对于输入请求参数的多种可能性，例如，直接输入参数、从可能值的列表选择参数变量(从付款银行的列表选择)、基于从交易机构(经纪机构)接收的支票购买请求产生请求。

发放电子支票的请求的必须参数为发放机构的细节(注册编号、描述等等)、票面价值、被发放的支票的币种、付款银行、付款的支票将存入其中的发放机构的结算账户的编号、有关支票购买者和付款者的数据(姓名、INN、注册编号、有关购买申请的数据、用于将支票存入到账户中的购买者的账户)。在发放机构正确完成请求的所有所需参数之后，K11单元将产生以利用发放机构的EHS验证的电子文件的形式发放支票的请求。K11单元将请求传输至用于将支票存入账户中的***、请求、申请的注册的S6服务器。

S6单元执行用于验证发放支票的请求的程序；触发S2服务器单元的执行，在该过程中，发送者和请求接收者两者进行必要的验证(包括请求EHS的验证)。在成功满足所有验证的情况下，将在服务器上注册该请求。记录将被导入到DB中的“有关用于将支票存入账户中的账户、请求、申请的信息”部分中。有关新请求的可用性的消息将通过用于发送在线通知的S10单元发送至接收者(用于被发放的支票的付款银行)。

在进入银行***时或在正接收在线通知的情况下，通过与S3单元交互，用于银行的客户端应用程序的K3单元(更新、同步客户端和服务器应用程序数据)将从服务器下载请求以发放电子支票。

在这种情况下，用于客户端和服务器应用程序DB的数据更新和同步的S3服务器单元将执行对仅通过具有请求中指定的“银行”状态的接收者进行请求下载的事实的验证。

在成功接收请求之后，执行用于银行的客户端应用程序的K13单元的触发以处理所接收的发放电子支票的请求。K13单元将在用户界面中显示有关支票发放请求的信息并且对银行提供拒绝或确认请求的选项。

在已接收请求之后，银行验证对于已从用于电子支票发放的请求中所指明的付款者接收的所发放的支票进行付款的可用性，比较在发放机构的请求中的数据(例如：支票的票面价值、币种、支票购买申请的编号、付款者的细节)与来自发放机构的账户结单的数据。在发放机构的账户中接收用于购买支票的货币资金情况下，银行将通过客户端应用程序确认发放机构的请求。在这种情况下，用于处理所接收的用于电子支票发放的请求的K13单元应当产生对请求的电子确认并且将其传送至用于处理和执行申请、请求的S13服务器单元。

在用于发放电子支票的申请的确认的程序的过程中，S13单元将从DB取回有关被确认的用于发放支票的请求的数据并且执行必要的验证(包括触发用于银行的账户的验证的K2单元)；在它们成功完成之后，触发S11单元的执行以发放电子支票。有关从用于发放的请求接收的新的支票的细节的数据被传输至该单元的输入，该数据包括如下：票面价值、支票币种、有关付款银行的数据。以上给出对S11单元的描述(参见用于执行电子支票转账的方法)。

在成功终止S11单元的操作时，在用于发放电子支票的申请的确认的程序的过程中，为了自动创建和执行所发放的支票从发放机构的账户到支票购买者的账户的转账的目的，S13单元触发用于注册和执行电子支票转账的S5单元的执行(转账注册程序)。来自从DB取回的来自用于发放电子支票的申请的数据，即，接收者的账户、票面价值、支票币种等等，应当被传送至S5单元的用于注册转账的程序的输入。

在终止S5单元的用于注册转账的程序的操作之后，该程序应当被执行以实现S5单元的操作(根据以上给定顺序)。

S13单元将会将成功处理请求的结果传输至银行应用程序的K13客户端单元，其记录所处理的用于支票发放的请求的更新状态，并且通过S10单元记录到支票发放请求的发送者(发放机构)的客户端应用程序(到用于客户端和服务器应用程序DB的数据更新、同步的S3单元，S3单元更新并向发放机构显示请求的更新状态和有关到购买者的支票的自动转账的信息)。

电子支票的付款的方法

以下，提供一种用于电子支票的付款的方法，该方法待用于为了根据持票人的结算账户中的支票接收实际的货币资金的目的而支票被提交至银行的情况。该方法的目的在于，根据既在支票持票人的一部分上也在执行付款的银行的一部分上的支票确保接收付款的过程的安全。

在用于付款的电子支票的提交的过程的开始应当是用户启动客户端应用程序，在该过程中，初始化用于在***中授权的K2客户端单元，在这之后，将启动K3单元的执行以更新和同步客户端和服务器应用程序数据。K2和K3单元的成功执行是传输至用于电子支票的付款的申请的数据输入、发送的K8数据的必要条件。K8单元可对多种用户类别(例如，仅对在***中具有比初始状态更高的状态的法人实体)进行访问。

为了初始化该单元，***参与者选择客户端应用程序的用户界面中对应的部分。

K8单元向用户提供用于产生用于电子支票支付的申请所需的初始数据的输入的可能性，比如将从其进行支票核销的账户、支票的票面价值、用于存入付款的银行细节。基于由用户输入的数据，K8单元根据参与者的支票确定充当付款者的银行。

在正确完成申请的必要细节之后，K8单元将产生用于以利用用户的EHS验证的电子文件的形式的电子支票的付款的申请。K8单元将申请传送至用于对将支票存入账户中的账户、请求、申请的注册的S6服务器单元。

S6单元将执行用于电子支票的付款的申请的验证的程序–触发S2服务器单元的执行，在该过程中，对于发送者和请求接收者两者进行必要的验证(包括请求EHS的验证)，并且执行对用于存入付款的客户的银行细节的正确性(具体而言，根据BIC的适用的银行资信手册)和发送者的账户中资金的充足性的验证，以及用于适当执行交易所必须的其他验证。

在成功满足所有验证的情况下，将在服务器上注册申请。记录将被导入到DB中的“有关用于将支票存入账户中的账户、请求、申请的信息”部分中。有关新申请的可用性的消息将通过用于发送在线通知的S10单元发送至接收者(付款银行)。

当银行进入***时或在接收在线通知的情况下，银行的客户端应用程序的K3单元(更新、同步客户端和服务器应用程序数据)通过与S3单元交互从服务器下载用于电子支票的付款的应用程序。在这种情况下，用于客户端和服务器应用程序DB的数据更新、同步的S3服务器单元执行对仅通过具有请求中指定的“银行”状态的接收者正在进行请求下载的事实的验证。

在成功接收请求之后，执行银行的应用程序的K14单元的触发以处理所接收的用于电子支票的付款的请求。K14单元将在用户界面中显示有关用于电子支票的付款的申请的信息并向银行提供拒绝或确认申请的选项。

在已接收申请之后，银行将验证申请参数的正确性、发放机构的结算账户中的必要数额的资金的可访问性。申请的确认应当是通过用于将支票存入账户的***发放的***。

银行通过执行用于将支票存入账户的***的数据输入、发送的K6客户端单元发放***。在执行该单元的过程中，将产生***，该***的参数基于用于支票的付款的申请确定并且部分由银行完成。银行应当指定被提交用于付款的支票分配的账户的细节。作为***的基础，有必要指定用于支票的付款的申请的编号并指出用于存入付款的支票持票人的银行细节。

在正确完成***细节之后，K6单元将产生以利用用户的EHS验证的电子文件的形式将支票存入账户的***。K6单元将会将***传输至用于对将支票存入账户中的***、请求、申请的注册的S6服务器单元。

S6单元执行用于验证用于将支票存入账户中的***的参数的程序-触发S2服务器单元的执行，在该过程中，发送者和请求接收者两者执行必要的验证(包括请求EHS的验证)。在成功满足所有验证的情况下，将在服务器上注册该***。记录将被导入到DB中的“有关用于将支票存入账户中的***、请求、申请的信息”部分中。有关新***的可用性的消息将通过用于发送在线通知的S10单元发送至接收者。

在成功发放***之后，用于处理所接收的用于电子支票的付款的申请的银行的客户端应用程序的K14单元将执行申请状态的更新。为此，对应的通知将被发送到用于处理和满足申请、请求的S13服务器单元，在该过程中，申请的新的状态将被记录在服务器DB中并且通知将被发送至发送者。

在申请不能被满足的情况下(支票持票人没有通过必要的验证)，银行将选择“拒绝申请”选项并且表明拒绝的依据。在这种情况下，用于处理所接收的用于电子支票的支付的申请的K14单元将向用于处理和执行申请、请求的S13服务器单元发送命令(触发用于通过S13单元拒绝支付的程序)。在执行该程序的过程中，将从DB取回有关被拒绝的申请的数据，将执行必要的验证并且将进行用于产生数字文件的S9单元的触发(用于产生关于拒绝为支票付款的通知的程序)。有关被付款的支票的客户、银行、币种的数据以及拒绝的依据应当被发送至该程序的输入。由于用于数字文件的电子签名的K17单元的执行，将利用银行的EHS对文件进行签名。S13单元将通知客户由客户发送的申请的状态的改变。

已经接收上述将支票存入账户中的***的参与者将执行到在指定的***中的专门账户中的银行的转账。根据上述用于执行电子支票转账的方法进行转账的执行。

已经接收转账的银行(用于处理接收的电子支票转账的K9单元)将执行对为了申请的付款、编号和转账的其他参数符合确认的支票付款申请的参数的目的而指定的支票持票人的细节的事实的验证，并启动用于验证接收的电子支票的程序。下面描述用于电子支票验证的方法。

仅当已接收到关于支票的验证和待“确认”的***中的验证的请求的状态的改变的通知时，银行将通过将各自的货币资金转账到参与者的结算账户执行支票的付款(并且如果参与者是***组织，则转账至其代理账户)并核销支票。

在选择银行的应用程序的用户界面中对应的选项后，发生核销电子支票的过程。在这种情况下，触发用于电子支票核销的K18单元的执行。K18单元将基于经确认的用于验证的请求产生核销包含用于验证的请求的编号的电子支票的电子请求、用银行的EHS验证该电子请求并且将该电子请求发送至用于核销电子支票的S14服务器单元。K18单元可附加地包括付款顺序的参数的银行的输入阶段的执行，在该基础上将进行将实际的货币资金到支票持票人的转账。

用于核销电子支票的S14服务器单元执行验证的阶段，在该过程中从DB取回有关所确认的用于验证支票的请求的数据；触发K2单元以验证银行的账户和请求EHS，并且执行被核销的电子支票的验证。在成功完成所有验证之后，S14单元将进行支票的核销，并且对应的改变将被导入DB中的“有关电子支票的信息”部分中(将改变电子支票状态和其他所需的参数)。

在实现电子支票的核销时，S14单元触发用于利用登记簿中的电子支票注册操作的S8单元的记录支票核销交易的程序的执行。在该程序被触发的情况下，以下数据将作为输入参数被传输：电子支票的编号、被核销的支票曾被存入的账户的编号、交易的类型(“支票核销(已付款)”)。在该程序的框架内，包含以下数据的记录将被导入到“电子支票登记簿”DB部分：交易的编号、日期、时间、价值、币种、被核销的支票的编号、交易的类型、支票涉及的账户的编号、在给定的账户中有关余额的数据。

在支票登记簿中成功记录交易之后，S14执行用于支票付款的申请、用于验证的请求的状态的更新(更新为“已执行支票的付款”)。对应的通知应当通过S10单元发送至***参与者。

用于验证电子支票的方法

用于验证电子支票的方法使银行能够接收对将提交的用于付款的支票的真实性的确认并且应当是在支票付款之前的必要阶段。

当已为了付款的目的而利用有关用于支票的付款的申请的数据的指示接收转账至专门账户的电子支票，银行产生用于验证所提交的电子支票的付款的请求时，验证过程开始。

在银行的“用于验证的请求”选项的选择中，将启动用于对电子支票验证的请求的数据输入和发送的K15单元的执行。K15单元将基于接收的转账向银行提供自动完成请求的参数的可能性。用于验证的请求保护有关电子支票以及有关已提交用于付款的支票的个人的数据。

K15单元将验证以具有银行的EHS的电子文件的形式完成的请求并且将该请求发送至用于对将支票存入账户中的***、请求、申请的注册的S6服务器单元。

S6单元执行用于验证对电子支票进行验证的请求的参数的程序，该程序包括自动验证电子支票细节，在该过程中，验证支票EHS(通过使用发放机构的公共密钥和在DB中有关支票的记录执行电子数字签名的验证的算法，其保证电子支票的所有细节的不变性)，以及电子支票和请求发送者的账户的当前状态(触发S2服务器单元的执行)。

在成功执行所有验证之后，S6单元将确定发放机构的注册编号并且将该请求保存在服务器上。记录将被导入到DB中的“有关用于将支票存入账户中的账户、请求、申请的信息”部分中。有关新请求的可用性的消息将通过用于发送在线通知的S10单元发送至接收者(发放机构)。

当发放机构进入***时或在接收在线通知的情况下，发放机构的客户端应用程序的K3单元(更新、同步客户端和服务器应用程序数据)通过与S3单元交互从服务器下载用于电子支票的验证的请求。在这种情况下，用于客户端和服务器应用程序DB的数据更新、同步的S3服务器单元执行对仅通过具有请求中指定的“发放机构”状态的接收者进行请求下载的事实的验证。

在成功接收请求之后，执行发放机构的客户端应用程序的K12单元的触发以处理所接收的用于验证电子支票的请求。K12单元将在用户界面上显示有关用于验证电子支票的请求的数据并且为发放机构提供拒绝或确认请求的选项。

已接收用于验证的请求的发放机构将通过使用支票登记簿追溯电子支票的历史–验证支票细节的正确性(***提供以图形形式查看电子支票的可能性)、有关支票持票人的数据的可靠性。

如果已成功执行所有验证，发放机构将确认用于验证支票的请求。

在这种情况下，用于处理所接收的用于电子支票的付款的请求的K12单元将该请求发送至S13服务器单元以处理和执行申请、请求(将触发S13单元的用于确认用于验证支票的请求的程序)。在执行该程序的过程中，将从DB取回有关经确认的请求的数据，将执行必要的验证，并且将进行用于产生数字文件的S9单元的触发(用于产生关于电子支票验证的通知的程序)。有关基于用于验证的请求接收的电子支票的数据将被传送至该程序的输入。由于用于数字文件的电子签名的K17单元的执行，将通过发放机构的EHS对文件进行签名。S13单元将通知银行关于由银行发送的申请的状态的改变。

在请求不能被确认的情况下，发放机构将选择“拒绝请求”选择并且指明拒绝的依据。类似于通过银行拒绝用于支票付款的申请产生请求的拒绝。

Claims (38)

1.一种通过电子支票进行结算的电子***，所述电子***包括用于数据处理和存储的至少一个服务器计算机设备、服务器应用程序和用于进行构成它的数据处理的客户端计算机设备，所述客户端计算机设备包括确保所述客户端计算机设备与服务器设备交互的固件客户端模块，所述固件客户端模块提供了在因特网网络上的通信信道上客户端计算机设备和服务器计算机设备之间的连接的可能性，和通过服务器和客户端模块的硬件和软件设施利用加密和电子数字签名保护通信信道的可能性，其中客户端和服务器应用程序至少包含用于在***中用户授权的互连的单元，用于更新和同步客户端和服务器应用程序数据的单元，以及用于输入执行转账的参数和存储有关客户端应用的付款的信息的单元，所述用于输入执行转账的参数和存储有关客户端应用程序的付款的信息的单元，其通过硬件和软件设施与用于验证电子支票转账的参数的单元连接，所述用于验证电子支票转账的参数的单元与用于授权和验证用户参数的单元和用于注册和执行服务器应用程序的电子支票转账的单元连接，所述用于注册和执行服务器应用程序的电子支票转账的单元通过反馈信道与用于电子支票管理的单元连接，以用于将佣金支票存入账户中以及以实时模式向用户发送通知，所述用于电子支票管理的单元连接至用于更新和同步客户端和服务器应用程序数据的单元并且包括由客户端应用程序组成的电子签名单元，所述电子签名单元通过硬件和软件设施与用于产生和存储服务器应用程序的数字文件的单元连接，所述用于产生和存储服务器应用程序的数字文件的单元连接至用于注册和执行电子支票转账的单元；在这种情况下，服务器应用程序的电子支票管理单元呈现为通过硬件和软件设施在反馈信道上与用于利用登记簿中的电子支票注册交易和发放电子支票的互连单元连接，并且连接至用于电子支票签名的单元。

2.根据权利要求1所示的电子***，其中所述客户端应用程序单元呈现为通过对应于由用于客户端和服务器应用程序的授权的单元确定的用户状态的类别分组成模块，并且提供对每个类别预设置支票流通的参数的组的可能性。

3.根据权利要求2所示的电子***，其中所述客户端应用程序单元呈现为通过三个类别分组成模块，所述三个类别包括：初始等级，具有最小组的支票流通参数，提供了向银行提交用于付款的支票和为其支票选择付款银行的可能性；以及扩展等级，提供了产生用于操作***的发放机构、合作银行和交易机构(经纪机构)的附加组的支票循环参数的可能性。

4.根据权利要求1或2中任一项所述的通过电子支票进行结算的电子***，其中所述客户端设备包括具有其自身的用户界面的单独的客户端应用程序和/或在用于通过在网络浏览器中所显示的其自身的用户界面查看因特网网络的资源的标准装置中的内置模块的形式的客户端应用程序；和/或提供将用于信息处理和产生用户界面的单元传送至服务器的可能性的基于网络浏览器的以瘦客户端形式呈现的客户端应用程序。

5.根据权利要求1、2或4中任一项所述的通过电子支票进行结算的电子***，其中包含以瘦客户端模式的用户应用程序的客户端设备已呈现为提供在网络浏览器用户界面中的数据输入、数字文件的电子签名、数据加密、到服务器的数据传送、从服务器的数据接收、解密、输出至网络浏览器用户界面的可能性。

6.一种用于在电子支票结算***中实现电子支票转账的方法，所述电子支票结算***包括用于数据处理和存储的服务器计算机设备、信息显示设备和构成它的服务器应用程序，以及包含用于信息显示的设备的客户端计算机处理设备和在无线和/或因特网通信的信道上连接的客户端应用程序，包括连续实现的阶段：在***中的参与者授权；数据接收的账户；输入电子支票转账参数；验证电子支票参数；注册用于执行电子支票转账的请求；执行将发送者的支票兑换成包括转账支票、佣金支票、余额支票的若干支票的交易；提交用于付款的支票、付款和发放新的支票；在标准用户类别的电子支票的转账时将电子佣金支票存入***操作者的账户和/或交易机构(经纪机构)的账户中以及通过交易机构(经纪机构)存入银行中；将电子支票存入参与者的账户中；伴随着创建和签名电子文件、通知参与者转账的执行，转账终止。

7.根据权利要求6所述的方法，额外包括在将电子支票存入参与者的账户中的阶段之后执行的接收者兑换成一个支票的交易，包括用于付款的支票的提交，尤其是通过托收、付款和发放新的支票。

8.根据权利要求6所述的方法，其中在***中的参与者的授权包括用户启动客户端应用程序，在该过程中，将初始化客户端授权单元，并且账户数据将被输入并通过用于与服务器交互的K4单元通过在受保护的通信信道上的因特网网络传送至用于授权和验证用户参数的S2服务器单元，在S2服务器单元中执行参与者的账户、电子密钥的存储的可访问性和正确性的验证，提供了产生用于请求的等效手写签名(EHS)和电子文件的可能性、确认了参与者的状态和对应的权限，进行客户端和服务器应用程序数据的同步，提供了将有关参与者的账户、转账、用于将所接收的支票存入到账户中的***的当前状态的信息输出至客户端和服务器应用程序终端的可能性，并且执行客户端应用程序的用于转账的参数输入和执行的单元的初始化。

9.根据权利要求8所述的方法，其中应当基于用于授权的客户端单元的初始化执行账户的输入和验证并利用对应于账户类别的权限进行其授权。

10.根据权利要求6所述的方法，其中在成功完成授权阶段之后，用于信息更新的模块的服务器应用程序将执行至少在用户界面中显示账户信息，所述账户信息包括有关所有参与者的账户的信息：账户的编号、描述、账户中的有效余额、账户涉及的电子支票的编号、与账户相关联的银行的数据等等。

11.根据权利要求6所述的方法，其中在用于转账的参数输入、执行的K5单元的初始化时逐步执行转账参数的输入和转账的执行，转账参数的输入和转账的执行在被迫选择在客户端应用程序的用户界面中的对应部分的情况下进行；执行用于电子支票转账所需的初始数据的输入，其在***中针对每个类别的参与者预设置；基于所接收的用于将支票存入账户中的***或某种类型的申请产生转账。

12.根据权利要求6所述的方法，其中转账参数的输入包括在参数输入过程中执行的自动验证，并且同时产生错误消息并且将所述错误消息传输至参与者的客户端应用程序和计算机设备。

13.根据权利要求6所述的方法，包括在接收数据的过程中通过有关转账的数额的应用程序自动计算被托收的用于转账的佣金，其通过软件和硬件设施、通过服务器应用程序执行，同时产生消息和到客户端应用程序和客户端计算设备的消息的传输。

14.根据权利要求13所述的方法，其中基于将被存储到随机存取存储器和/或例如在账户数据的接收阶段下载的应用程序的本地数据和/或基于在服务器计算机设备的存储器中预设置的佣金率通过模块执行佣金的计算；都具有通过来自客户端应用程序的单独的请求、产生有关将被托收用于转账的佣金的数额和将被核销的数额的报告(或基于所完成的参数所能够接收的数额)从服务器更新和转账的可能性，所述报告将被传送到客户端应用程序的K5单元。

15.根据权利要求6所述的方法，额外包括用于初步验证转账参数的阶段，在该阶段过程中，通过用于数据验证的K5单元产生电子请求并传送至用于验证电子支票转账的参数的S4服务器单元；S4单元应当确定在验证过程中采用指定的参数的转账的执行是否是能够访问的，并且在接收到积极响应的情况下，触发S2服务器单元的执行，在该过程中，将从DB取回发送者的真实性的必要验证、至少请求EHS和转账接收者的验证、至少接收者账户的可访问性的验证，以及有关在转账发送者的账户中可用的电子支票的数据，支票的票面价值将与将被核销的数额相比较并且将执行由***的具体实现的特殊性提供的其他验证。

16.根据权利要求15所述的方法，其中应当通过将待核销的数额与能够访问的有效余额的数额进行比较，额外执行账户中的单个账户的限制。

17.根据权利要求15所述的方法，其中用于转账的注册请求及将其记录在***DB中的记录的阶段执行佣金的数额的计算和确定。

18.根据权利要求15所述的方法，其中用于转账的注册请求的阶段额外包括产生和存储数字文件的S9单元的初始化，提供了产生以适合于在纸上打印的格式的电子文件的可能性，该电子文件包含用于电子支票转账的申请的所有细节并且通过数字文件的电子签名的客户端单元(K17)，利用参与者的EHS进行确认。

19.根据权利要求18所述的方法，其中以适合于在纸上打印的格式的电子文件被传输至服务器上的DB并且与EHS和其他信息一起存储在应用程序数据库中。

20.根据权利要求4所述的方法，其中用于注册和执行电子支票转账的单元S5，在转账运行期间，从***数据库接收有关转账发送者的账户中的电子支票和佣金的数额的数据并且执行在发送者的账户中的余额支票的票面价值与转账的数额的比较；在比较的值一致的情况下，进行从发送者的账户到接收者的账户的电子支票的转账。

21.根据权利要求20所述的方法，其中用于支票的转账的S5单元启动电子支票的服务器管理单元S7的执行；在这种情况下，至少关于电子支票的编号、转账发送者的账户的编号、转账接收者账户的编号的数据将被传送至输入，并且在确认了转账的执行的情况下，S7单元将实现DB中信息的变化；而且，将删除有关在转账发送者的账户中的支票的信息，有关新的余额支票的编号的数据将被导入到接收者的账户中并且将改变有关支票持有者的信息；同时，将执行信息到S8单元的传送和通过S8单元的电子支票交易在登记簿中的注册，并且之后将产生有关成功终止转账的信息并且传输至S7单元。

22.根据权利要求20所述的方法，其中所述电子支票将首先转账至操作者，并且操作者将支票传输至转账接收者。

23.根据权利要求20所述的方法，其中在请求转账的情况下，所述支票的票面价值不完全被传输至接收者，并且S5单元将触发用于电子支票管理的S7单元的用于电子支票兑换的程序；在这种情况下，S5单元将以下数据传送至该程序的输入：其票面价值等于发送者的账户中的余额的电子支票的编号、应当被执行兑换成等于转账数额的电子支票的票面价值以及将被托收的用于转账的佣金的数额。

24.根据权利要求23所述的方法，其中在电子支票兑换的情况下，所述S7单元将发送者的电子支票传输至***操作者；在这种情况下，操作者将向付款银行提交所接收的用于付款的电子支票；而且，通过执行用于电子支票管理的S7单元的用于提交用于付款的支票的程序进行用于付款的电子支票的提交，至少以下数据被传输至S7单元的输入：电子支票的编号、有关银行的信息、支票从其被提交的账户的编号，并且在成功执行用于付款的支票提交的程序之后，通过触发用于电子支票管理的S7单元执行用于支票核销的程序的执行，电子支票编号将被传输到S7单元的输入，已付款的支票的数据将被改变并且通过初始化S8单元进行电子支票交易在登记簿中的注册和记录，并且在传输控制信号到S7单元时将终止涉及电子支票核销的交易。

25.根据权利要求24所述的方法，其中在用于电子支票兑换的程序的框架内，S7单元将顺序触发用于为每个指定的支票发放电子支票的S11单元的执行；在这种情况下，有关新支票的细节的数据将被传输至该单元的输入，所述数据至少包括如下：票面价值、支票的币种、有关付款银行的数据，提供了通过操作者从发放机构得到用于转账的数额的新支票和/或用于佣金的数额的支票和/或所需票面价值的余额的数额的支票。

26.根据权利要求25所述的方法，其中在执行S11单元时，将从***DB取回用于详述支票细节的必要数据，并且将触发用于电子支票签名的S12单元的执行并且将在DB中创建有关新的电子支票的记录。

27.根据权利要求24所述的方法，其中在实现电子支票发放时，S11单元将触发用于在登记簿中注册电子支票交易的S8单元的用于记录支票发放交易的程序的执行，并且在登记簿中成功记录之后，由于根据用于电子支票管理的S7单元的用于电子支票转账的程序，对于电子支票，用于电子支票发放的S11单元的操作将被终止，并且所发放的支票将被转账至操作者；在这种情况下，操作者将余额支票转账至转账发送者。

28.根据权利要求24所述的方法，其中在用于执行S5单元的交易的程序的框架内，操作者将执行用于转账的数额的支票到接收者的账户的传输；在这种情况下，S5单元将取回有关转账接收者的账户中的余额和有关账户设置的信息；在这种情况下，如果余额在支票接收者的账户中是可用的和/或在账户参数中指定的与根据转账支票的付款银行不同的银行，则S5单元将触发用于电子支票管理的S7单元的电子支票的兑换和/或整合的程序；在这种情况下，来自接收者的账户的电子支票将被转账至***操作者的账户，并且操作者将向根据转账接收者的“余额支票”指定作为付款者的银行，或向在账户设置中指定的银行提交所接收的用于付款的多个电子支票(一个电子支票)；在没有余额的情况下，对于向付款银行提交的用于付款的电子支票，触发用于电子支票管理的S7单元的用于支票核销的程序的执行，在该程序终止时，操作者将从发放机构得到新支票，该新支票的票面价值将是提交用于兑换的支票的票面价值的总和，和/或该新支票的票面价值等于提交用于兑换成另一付款银行的支票的支票的票面价值；在用于电子支票兑换(整合)的程序的框架内，S7单元将触发用于发放电子支票的S11单元的执行并且确定根据新支票的付款者将是已执行提交用于兑换的支票的付款的银行；发放机构将所发放的支票转账到***操作者，并且操作者将新支票转账至转账操作者，并且在成功实现上述动作之后，将终止用于电子支票兑换和/或整合的程序。

29.根据权利要求24、25、26、27或28中的任一项所述的方法，其中将触发用于产生和存储数字文件的S9单元的执行，并且产生所需的数字报告文件，在实现用于注册和执行电子支票转账的S5单元的用于执行交易的程序时，提供了利用参与者的EHS进行签名和后续的打印输出的可能性。

30.根据权利要求29所述的方法，在执行S9单元时，其中将产生以下文件的数字图像：应当被传送到用于数字文件的电子签名的K17单元的输入的电子支票的接受证书、提供的服务的证书、形式***，并且提供利用对应方的EHS进行签名的可能性。

31.根据权利要求30所述的方法，其中在成功实现转账和产生所需的文件之后，S5单元将启动用于发送在线通知的S10单元的执行；有关转账接收者、被发送的消息的类型的信息将被传输至S10单元的输入；在这种情况下，S10单元将触发用于更新和同步客户端和服务器应用程序数据的K3客户端单元的执行；同时，S5单元将信息传送至K5单元，K5单元保存有关转账发送者的付款的信息。

32.一种用于在电子支票结算***中发放电子支票的方法，所述电子支票结算***包含用于数据处理和存储的服务器计算机设备、信息显示设备和构成它的服务器应用程序设备，以及包含信息显示设备和在无线和/或因特网通信信道上连接的客户端应用程序的客户端计算机处理设备，所述方法至少包括通过用于发放支票的发放机构的请求、银行对发放机构的账户中接收的货币资金的验证的必要阶段，所述阶段用作对于给定支票与请求参数一致以及银行对电子支票发放的确认的保障，并且提供产生在法律上有效的文件和在将产生的并且存储在***服务器中的支票登记簿中反映交易的可能性。

33.根据权利要求32所述的方法，包括通过具有发放机构的账户的用户启动客户端计算机设备上的客户端应用程序和执行在***中的客户授权；在这种情况下，在输入账户数据的过程中，将顺序初始化用于在***中授权的K2客户端单元和用于更新和同步客户端和服务器应用程序数据的K3单元，所述K2客户端单元和所述K3单元将账户数据在通信信道上传送至用于授权的对应的S1服务器单元和用于数据同步的S2单元，其中将账户数据与DB服务器数据相比较，并且在终止处理账户数据的执行时，控制信号将被传送至K2和K3单元以限制或允许账号入口到***入口的访问并且根据账号入口的日期执行数据的更新，提供了在客户端信息显示设备上显示结果的可能性；如果确认授权，则K3单元将账户数据传送至用于发放电子支票的请求的数据输入和发送的K11单元，K11单元利用对应于支票发放交易的界面产生客户端应用程序并且将输入用于电子支票发放的请求的数据，在此基础上，K11单元将产生以利用发放机构的EHS验证的电子文件的形式的用于支票发放的请求并且将该请求传送至用于注册申请的S6服务器单元以将支票存入账户中，S6服务器单元将执行用于验证支票发放请求的参数的程序、产生S2服务器单元的用于授权和初始化执行的请求，在该过程中，将针对发送者的账户(包括请求EHS的验证)和请求接收者的账户两者执行必要的验证，并且在所有数据的验证积极结果的情况下，S2单元将产生有关通过到S6单元的验证的确认消息并且在服务器上注册该请求，并且请求数据将记录在DB中；在这种情况下，有关到银行的K3单元的新请求的可用性的消息将通过用于发送在线消息的S10单元发送至用于所发放的支票的付款银行，并且在基于该请求确认将通过S2和S3单元执行的***中的银行授权之后，银行的K3单元将通过向S3发送具有银行的识别数据的请求来执行用于电子支票发放的请求的数据的下载，并且将有关该请求的数据传送至用于处理所接收的用于发放电子支票的请求的K13银行的客户端单元，提供了在用户界面中有关用于电子支票发放的请求的数据的输出和用于接受或拒绝请求的选择的实现；在这种情况下，银行的K13单元将验证从在针对所发放的支票的用于发放电子支票的请求中指定的付款者接收的付款的可用性并且核对发放机构的请求中的数据与来自从S3接收的发放机构的账户的结单的数据，并且在用于获取支票的发放机构的账户中接收货币资金的情况下，银行的K13单元将产生请求的电子确认并且将其传送至用于处理和执行申请的S13服务器单元，S13服务器单元将从DB取回有关被确认的支票发放的请求的数据，执行对银行的账户的必要验证，以及在它们成功终止时将支票发放数据传送至用于发放电子支票的S11单元，S11单元将执行用于注册和执行电子支票转账的S5单元的初始化，S5单元将产生电子支票并且实现从发放机构的账户到支票购买者的账户的所发放的支票的转账，并产生有关交易的执行和到S11单元的转递的报告，随着该报告随后通过S13传送至S10，并具有产生有关对银行和发放机构的K3单元执行的交易的消息的可能性；在这种情况下，S13单元将支票发放数据传送至银行的K13单元，银行的K13单元将记录所处理的支票发放请求的更新的状态，并且S10单元将更新发放机构的账户数据，并且提供同时向发放机构的信息显示设备输出请求的更新的状态和有关到支票的购买者的自动转账的信息的可能性。

34.根据权利要求33所述的方法，其中用于请求发放电子支票的数据的参数至少包括有关支票细节的数据，其包括以下：票面价值、支票的币种、有关付款银行的数据。

35.一种在电子支票结算***中电子支票的付款的方法，所述电子支票结算***包含用于数据处理和存储的服务器计算机设备、信息显示设备和构成它的服务器应用程序设备，以及包含信息显示设备和在无线和/或因特网通信信道上连接的客户端应用程序的客户端计算机处理设备，所述方法包括启动客户端应用程序，在该过程中将初始化用于在***中授权的K2客户端单元，在K2单元的执行之后，将启动K3单元以更新和同步客户端和服务器应用程序数据，在K3单元成功执行之后，将执行用于数据输入的K8单元的初始化、用于电子支票付款的申请的发送和用于产生电子支票的付款的申请所需的初始数据的输入；在这种情况下，K8单元将基于输入数据确定充当用于参与者的电子支票的付款者的银行，产生以利用用户的EHS验证的电子文件的形式的用于电子支票的付款的申请并且将所述申请传送至S6服务器单元，所述S6服务器单元用于通过S2单元进行的用于将支票存入账户的***、请求、申请的注册，并且通过将它们与待存储在***DB中的数据相比较来执行数据的验证，并且在验证的积极结果的情况下，将在服务器上注册申请，并且记录被导入DB中；而且，有关新申请的可用性的消息将通过用于发送在线通知的S10单元发送至接收者(付款银行)；银行将通过与S3单元交互而从用于电子支票的付款的服务器下载申请；在这种情况下，用于客户端和服务器应用程序DB的数据更新、同步的S3服务器单元将执行对请求下载已通过具有在请求中指定的“银行”状态的接收者进行的事实的验证，将执行银行的客户端应用程序的K14单元的触发以处理所接收的用于电子支票的付款的申请，K14单元将在用户界面中产生和输出有关用于电子支票的付款的申请的数据并且为银行提供拒绝或确认申请的选项；银行将验证申请参数的正确性、发放机构的结算账户中必要数额的资金的可用性，并且在成功验证的情况下，银行将通过执行用于将支票存入账户中的数据输入、发送的客户端应用程序的K6单元，经由***执行将支票存入账户中的***的产生，K6单元将产生以利用用户的EHS验证的电子文件的形式的用于将支票存入账户中的***并且将所述***传送至用于对用于将支票存入账户中的***、请求、申请进行注册的S6服务器单元；S6单元将通过S2服务器单元执行用于将支票存入账户中的***的参数的验证的程序，在成功进行验证的情况下执行在***DB中的服务器上的***的注册，并且通过用于发送在线通知的S10单元产生到接收者的有关新请求的可用性的消息；在接收到***消息的情况下，用于处理所接收的用于电子支票的付款的申请的银行的客户端应用程序的K14单元将执行申请的状态的更新；已接收上述用于将支票存入账户中的***的参与者将进行银行到在***中指定的账户的转账；在这种情况下，在转账通过用于处理所接收的电子支票转账的K9单元进行接收的情况下，将进行付款细节和其他转账参数的验证，将启动与被存储在DB中的所确认的用于支票的付款的申请的参数的比较和用于所接收的电子支票的验证的程序；为了“确认”以下从发放机构接收的支票验证的通知和***中用于验证的请求的状态的变化，银行将根据支票通过向参与者的结算账户汇款各自的货币资金来执行付款并且进行支票的核销。

36.根据权利要求35所述的方法，其中在申请不能被满足和/或支票持票人没有通过必要的验证的情况下，所述银行将选择“拒绝申请”选项并且指明拒绝的依据；在这种情况下，用于处理所接收的用于电子支票的付款的申请的K14单元将向用于申请、请求的处理和执行的S13服务器单元发送命令，并且触发S13单元的用于付款拒绝的程序，在执行该程序的过程中，将从DB取回有关被拒绝的申请的数据，将进行必要的验证并且将执行S9单元的触发以产生数字文件，并且提供产生拒绝支票付款的通知，并且将通过执行K17单元实现利用银行的EHS对数据文件进行电子签名的可能性；在这种情况下，S13单元将通知客户有关由客户发送的申请的状态的改变。

37.根据权利要求35或36中的任一项所述的方法，其中将基于选择银行的应用程序的用户界面中对应的选择执行电子支票核销过程；在这种情况下，将触发用于核销电子支票的K18单元的执行，K18单元将基于所确认的用于验证的请求产生包含用于验证请求的编号的核销电子支票的电子请求、利用银行的EHS验证所述请求并且所述该请求发送至用于核销电子支票的S14服务器单元，在执行验证阶段之后，在此过程中，将从DB取回有关所确认的用于验证支票的请求的数据，将执行用于验证银行的账户的K2单元的触发，请求EHS以及将被核销的电子支票的验证，进行支票的核销并且对应的变化将通过S14单元导入DB中，并且将进行核销交易在登记簿中的记录和注册，在此之后，S14单元将执行用于支票的付款的申请的状态的更新，对验证的请求(成为“已执行付款的支票”)和对应的通知将通过S10单元发送至***参与者。

38.一种用于在电子支票结算***中验证电子支票的方法，所述电子支票结算***包含用于数据处理和存储的服务器计算机设备、信息显示设备和构成它的服务器应用程序设备，以及包含信息显示设备和在无线和/或因特网通信信道上连接的客户端应用程序的客户端计算机处理设备，区别在于，为了付款的目的，所述方法将在银行已接收到利用有关用于支票的付款的申请的数据指示的专门账户的电子支票的转账的情况下启动该方法；在这种情况下，将产生用于验证所提交的用于付款的电子支票的请求；而且，将启动K15单元的执行以用于验证电子支票的请求的数据输入、发送；K15单元将为银行提供基于所接收的转账自动完成请求参数的可能性；在这种情况下，K15单元将利用银行的EHS验证以电子文件形式的请求并且将该请求发送至用于将支票存入账户中的***、请求、申请进行注册的S6服务器单元，S6服务器单元将执行用于验证用于电子支票的验证的请求的参数的程序，并且在成功满足所有验证的情况下，S6服务器单元将确定发放机构的注册编号并将该请求保存至***DB中的服务器；而且，有关新请求的可用性的消息将通过用于发送在线通知的S10单元发送至接收者(发放机构)；发放机构将通过与S3单元交互从服务器下载用于验证电子支票的请求；在这种情况下，用于涉及客户端和服务器应用程序DB的更新、同步的数据的S3服务器将执行对请求下载通过具有在请求中所指示的“发放机构”状态的接收者执行的事实的验证，并且在成功接收请求之后，将进行发放机构的客户端应用程序的触发以处理所接收的用于验证电子支票的请求，K12单元将在用户界面中输出有关用于验证电子支票的请求的数据并且向发放机构提供拒绝或确认请求的选项；在已成功执行所有验证之后，发放机构应当确认用于验证支票的请求；而且，用于处理所接收的用于电子支票的付款的申请的K12单元将该请求发送至用于申请、请求的处理和执行的S13服务器单元，并且触发S13单元的用于确认用于验证支票的请求的程序，在其执行过程中，将从DB取回有关被确认的请求的数据，将进行必要的验证并且将执行S9单元的触发以产生数字文件，提供产生验证电子支票的通知的可能性；而且，通过执行用于数字文件的电子签名的K17单元，文件将利用发放机构的EHS进行签名；S13单元将通知银行有关由发放机构发送的申请的状态的变化。