文件发送系统及方法

本申请是申请号为98122775.9、申请日为1998年12月4日、发 明名称为"文件发送系统和方法"的发明专利申请的分案申请。 技术领域

本发明涉及通过电子数据发送/接收各类文件，伴随此种文件的发 送/接收进行费用支付以及进行这种支付接收的文件发送系统与方法。 技术背景

近年来，在因特网之类的开放网络环境中，已可进行文件数据的接 收与发送以及贸易等，预计将来的形式将更会多种多样。例如现在向专 利局提出专利申请文件等时，申请人已可通过拨号直接接通专利局的服 务器来发送提出的文件数据。而在将来，申请人则可能经由因特网与专 利局连接。另一方面，对于不动产登记或商业登记，或是由相应机关从 事的户口卡和其它证明的发行业务，则要有由申请人直接向登记单位或 相应机关提交文件（各种申请书）的手续。但是，即使是后述这类业务， 将来也很有可能通过因特网执行。

于是，在通过因特网等通信提交电子式文件的情况下，伴随这类文 件的提出，需要支付手续费。相对于专利局、登记所或是机关那样的官 方公共机构提交文件时，多取购入印花票与收讫标签等，将其贴于前述 文件上提交的形式。在通信中，进行文件提出时需有某种手续费的支付 机构。例如日本的专利局的电子申请系统中，首先由文件提出者将若干 金额存入预交户头。而在专利局一方的电子申请系统接收申请时，就从 该预交户头中划拨必要的金额。

另一方面，在所谓电子购物的贸易中，可经由因特网购入种种商品。 它的支付可从信用卡或银行户头进行划拨。具体地说，购物者经通信将 信用卡或银行户头的帐号发送出，而在售货一方则据此帐号从信用卡或 银行户头划拨预定的金额。此外，近年来还提出了称作SET(安全电子交易）的因特网的电子结帐方式。有关SET，例如可参看"SET Secure Electronic Transaction Specification Book I: Business Description", Version 1.0， March 31， 1997。

通过因特网等通信提交电子文件时需支付手续费时，在如上述的日 本专利局的电子申请系统之类装置从预交户头划拨方式下，提交文件者 必须设置预交户头这一点是不方便的。在不动产等的申请中，这类文件 的提出者通常一生中也只办理一次这样的手续。因而难怪申请人把设置 预交户口视为麻烦的事情。

作为不依赖预交户头的支付方法有从信用卡或银行户口划拨的方 法。这时需使从申请者指定的信用卡或银行户头所作的划拨处理与经由 通信进行文件提出的接收处理分别进行。从而有可能发生在文件提交之 后，由于户头中预存的金额不足需划拨的金额而不能划拨的情形。

若是根据上述SET的协议，则能在因特网上进行电子结帐。这时 的购物者与货款的支付者是同一个人，是以在提出商品购入的同时进行 结帐为前提。因此，对于专利局、登记所或是某种机关那样的公共机构 所适用的贴付印花票或收讫标签的手续便不熟悉了。这样的手续，有时 是由文件申请者的代理人代替申请者进行文件的发送。这就是说，附到 文件上的证明书或印花票等应由文件的申请者支付其费用，而另一方面

文件则是由代理人提出。由于费用的支付者和文件的提交者不同，这时 文件的提交手续和相关的关系就不能进行SET的协议进行支付手续。如 果文件提交的费用的支付是同文件的提交本身无关的进行，则在费用的 支付中可以使用SET的协议。但在这种情况下费用的支付手续与文件的 提交手续有关系时，那就要费工夫的。

再有，在提交各类文件时，有时需要明确规定提交的日期时间。由 通信来提交文件时，当通信线路状态恶劣时，就会产生重新发送的必要， 会产生文件提交时间不明确的不便情形。特别是在把开始发送文件的时 刻作为文件提交的时刻时的情形，在开始发送而确保提交的日期和时刻 后，由于会发生再发送，之后会发送其它内容的文件，当这份文件是在 前述的提交日子时刻提交时，便有可能发生滥用主张的恶果。于是需要有合理地确定通信中提交文件之际的提交时刻的结构。 发明内容

本发明的目的在于提供使经由通信网络来发送电子文件和交纳其 手续费两者能方便进行的文件发送系统与方法。

根据上述目的，可以在经由因特网等通信提交电子文件之际有需要 支付手续费时，不必要设置预交户口这类的特别户头，也不必要从信用 卡或银行户头由另外的步骤来进行划拨处理，而且即使是费用支付者与 文件提交者不同时，也能恰当地进行文件的提交及其费用的支付。

本发明的另一个目的在于提供于通信中提交电子文件时，具有不允 许滥用，能合理地确定提出日期与时刻的结构的文件发送系统与方法。

一种文件接收系统，其特征在于，此系统包括

通信网络，

与此通信网络连接来发送文件的装置，及

与此通信网络连接并经由此通信网络接收前述文件且包含有 存储装置的文件接收服务器，

所述文件发送装置将对所述文件施加单向函数后所得的第一

压缩数据经前述网络发送给前述文件接收服务器；

前述文件接收服务器将所接收的前述压缩数据以及前述的第 一压缩数据的接收时间存储于前述存储装置中；

前述文件发送装置在所述第一压缩数据发送后将上述文件的 非压缩数据通过所述网络发送给前述文件接收服务器；

前述文件接收服务器把对所接收的前述非压缩数据施加单向 函数后所得的第二压缩数据与前述第一压缩数据比较，在得到此第 一与第二压缩数据相一致的比较结果时，把所述第一压缩数据的接

收时间确定为前述文件的接收时间。

根据本发明的一种实施形式，提供了经由网络从申请人装置相对于 文件接收服务器发送文件的文件发送系统，其中，在前述网络上连接有 支付接收服务器；前述申请人装置具有相对于此支付接收服务器指定支 付金额，委托其进行费用支付的装置；此支付接收服务器具有：根据来自前迷申请人装置的对费用支付的委托，实施相对于金融机关的支付的 信用查询的装置，和根据此信用查询判明前述申请人的费用支付有保证 时，将表示该费用支付得到保证为宗旨的支付证明书制成不能改动形式

发送给前述申请人装置的装置；前述申请人装置具有将前述支付证明书 附于发送的文件中作为附有不能改动形式的支付证明书的文件发送给 前述文件接收服务器的装置；此文件接收服务器具有在确认由前述申请 人装置送来的支付证明书为未曾使用的之后，将附有此支付证明书的文 件加以保管的装置。

根据本发明的另一种实施形式，提供了经由网络从申请人装置，通 过代理人装置代理，相对于文件接收服务器发送文件的文件发送系统， 其中，在前述网络上连接有支付接收服务器；前述申请人装置具有相对 于此支付接收服务器指定支付金额且委托其进行费用支付的装置；此支 付接收服务器具有：根据来自前述申请人装置的对费用支付的委托，实 施相对于金融机关的支付的信用查询的装置，和根据此信用查询判明前 述申请人的费用支付有保证时，将显示该费用支付得到保证为宗旨的支 付证明书制成不能改动形式发送给前述申请人装置的装置；前述申请人

的支付证明书的文件发送给前述代理人装置的装置；前述代理人装置具 有将接收的附有支付证明书的文件发送给前述文件接收服务器的装置； 此文件接收服务器具有在确认由前述申请人装置送来的支付证明书为 未曽使用的之后将附有此支付证明书的文件加以保管的装置。

根据本发明的又一种实施形式，提供了经由网络从申请人装置相对 于文件接收服务器发送文件的文件发送系统中，伴随文件发送接收费用 支付的支付接收服务器，它包括有：根据来自前述申请人装置的对费用 支付的委托，实施相对于金融机关的支付的信用查询的装置；和根据此 信用查询判明前述申请人的费用支付有保证时，将显示该费用支付得到 保证为宗旨的支付证明书制成不能改动形式发送给前述申请人装置的 装置。

根据本发明的再一种实施形式，提供了经由网络从预定的装置相对于文件接收服务器发送文件的文件发送系统，此系统包括：由前述发送 文件的预定装置对欲发送的文件数据作单向函数变换取得压缩数据，并

将此压缩数据以不可改动形式发送给前述文件接收服务器的装置；由前

述文件接收服务器存储所接收的压缩数据之后，将票据发送给前述发送

文件装置的装置；在前述发送文件装置接收至票据时进行将欲发送的文 件数据发送给前述文件接收服务器的装置，在前述文件接收服务器接收 到全部前述文件数据后，把对此文件数据施加单向数据取得的压缩数据 与前述存储的压缩数据相比较，来确认这些压缩数据是否一致的装置。 根据本发明的又一实施形式，提供了经由网络从申请从装置相对于

文件接收服务器发送文件的文件发送方法，此方法包括下述步骤：在前

述网络上连接支付接收服务器的同时，由前述申请人装置相对于前迷支

付接收服务器指定支付金额且委托其进行费用支付的步骤；由前述支付 接收服务器根据来自前述申请人装置的对费用支付的委托，实施相对于 金融机关的支付的信用查询的步骤；根据此信用查询判明前述申请人的 费用支付保证时，将显示该费用支付得到保证为宗旨的支付证明书制成 不能改动形式发送给前述申请人装置的步骤；由前述申请人装置将前述

的文件发送给前述文件接收服务器的步骤；由前述文件接收服务器在确 认由前述申请人装置送来的支付证明书为未曾使用之后，将附有此支付 证明书的文件加以保管的步骤。

根据本发明的再一种实施形式，提供了经由网络从预定的装置相对 于文件接收服务器发送文件的文件发送方法，此方法包括下述步骤：由 前述发送文件的预定装置对欲发送的文件数据施加单向函数变换取得 压缩数据，并将此压缩数据以不可改动形式发送给前述文件接收服务器 的步骤；在前述文件接收服务器存储所接收的压缩数据之后，将票据发 送给前述发送文件装置的步骤；在前述发送文件装置接收到票据后进行 将欲发送的文件数据发送给前述文件接收服务器的步骤；在前述文件接 收服务器接收到全部前述文件数据后，把对此文件数据施加单向函数变 换取得的数据与前述存储的压缩数据相比较，来确认这些数据一致的步根据本发明的实施例，在经由因特网等通信进行电子文件的提交而 需支付费用时，若相对于支付接收服务器提出支付的委托时，此支付接 收服务器则实施信用查询，在费用的支付有保证时，即发放旨在表明具 有不可改动形式的支付证明书，这样，就可不必设置预交户头之类的特 别户头，也不存在在从信用卡或银行户头上由另外方面进行划拨处理时 而未曾划拨的情形，此外，即使费用支付者与进行文件提交者不同时， 也能够恰当地进行文件的提交及其费用的支付。

再者，提供了这样的结构，使得在发送文件之前是将所发送的文件 用单向函数压缩成的压缩数据来发送，然后与相对于实际发送的文件由 相同单向函数压缩成的压缩数据进行比较确认，这样，在由通信进行电 子文件的提交时，就不会发生滥用，而能合理地确定提交的日期与时刻。

附图说明

图1是本发明的实施例的文件发送系统的总图。

图2是图1中所示文件接收服务器与支付接收服务器的内部结构图。

图3是图1所示认证局的结构图。

图4是图1所示代理人装置的结构图。

图5是图1所示申请人装置的结构图。

图6示明图1所示实施例的系统中所用支付证明书的内容。

图7示明图1所示实施例的系统中所用支付证明书管理DB的内容。

图8示明图1所示实施例的系统从文件接收服务器发送给代理人装 置的票据的内容。

图9示明图1所示实施例的系统所用接收管理DB的内容。

图IO是示明图1所示实施例的系统中从代理人装置到申请人装置 的文件发送流程的流程图。

图11是示明图1所示实施例中接收从代理人装置发送给申请人装 置的数据的申请人装置处理流程的流程图；图12是示明图1所示实施例中申请人的费用支付处理流程的流程图。

图13是示明图1所示实施例中支付接收服务器的支付接收处理流 程的流程图。

图14是示明图1所示实施例中从申请人装置向代理人装置发送文 件流程的流程图。

图15是图1所示实施例中从申请人接收数据的代理人装置的处理 流程的流程图。

图16是图1所示实施例中从代理人装置向文件接收服务器发送附 有支付证明书的文件的处理流程的流程图。

图17是图1所示实施例中表明文件接收服务器的票据发放处理流 程的流程图。

图18是图1所示实施例中表明文件接收服务器的文件接收处理流 程的流程图。

图19概示图1所示实施例中文件接收服务器的文件接收日期与时 刻确定的时间图。 具体实施方式

下面根据附图说明本发明的实施例。

图1是本发明一实施例的文件发送系统的总图。在因特网110上连 接有文件接收服务器101、支付接收服务器102、认证局103、代理人装 置104、申请人装置105、金融机关服务器106以及金融机关认证局107。 此101 ~ 107的装置各为计算机节点。

现在概述图1的系统中的处理流程。为简化说明，加密/译码处理 或数字署名处理都予除去（关于它们将在以后参照流程图证明）。

申请人装置105是支付规定费用并提交文件的申请人操作的装置， 代理人装置104是代理该申请人进行文件提交（实际的文件发送）的由 代理人操作的装置。提交的文件首先由代理人根据申请人的委托通过代 理人装置104制成。制成的文件数据发送给申请人装置105。申请人确 认接收的文件数据的内容后即保存该文件数据。此外，申请人从申请人装置105连接到支付接收服务器102，进行费用支付处理。支付接收服务器102是伴随文件的提交进行有关费用支付处理的 服务器。在收到申请人装置105的用费支付处理要求时，与金融机关服 务器106相连接对相应申请人实施信用查询后，将支付证明书返送给申 请人装置105。支付证明书是证明申请人进行了费用支付（或已保证进 行的支付预约）的数据，是相当于印花票或收讫标签的数据，详述于后。 支付证明书在本实施例中由文件接收服务器101与支付接收服务器102 两者能共同访问的支付证明书管理DB管理。申请人从申请人装置105 接收其支付证明书，将支付证明书附于所保存的文件数据中发送给代理 人装置104。代理人通过代理人装置104接收此数据后即加以保管。在 以后的任意时期中，代理人可把该数据发送给文件接收服务器101。文件接收服务器101是接收代理人装置104发送来的电子式的提交 文件的服务器。文件接收服务器101接收由代理人发送的数据（于文件 数据中附有支附证明书的数据），验证支付证明书，保管文件数据。所 谓支付证明书的验证是向支付证明书DB查询此支付证明书是否是未曾 使用过的，如果是未曾使用的，文件接收服务器IOI便进行使用结束的 处理。认证局103是发放用于进行申请人或代理人认证的证明书的认证 机构。金融机关服务器106是设有申请人户头的金融机关的服务器。金认证机构。图2示明图1的文件接收服务器101与支付接收服务器102的内部结构。文件接收服务器101包括票据发放处理部211、文件接收处理部 212、署名生成部213、加密/译码处理部214以及通信控制部215。支付 接收服务器102包括支付接收处理部211、署名生成部222、加密/译码 处理部223、支付证明书生成管理部224、 SET处理部225以及通信控 制部226。此外，作为文件接收服务器101与支付接收服务器102两方 能共同访问的DB，配备有接收管理DB231、密钥与证明书管理DB232、申请人与代理人管理DB233以及支付证明书管理DB234。文件接收服务器101通过因特网110 (图1)接收代理人装置104 发送来的文件。文件接收处理部212则进行这种文件的接收处理（详见 图18的说明）。票据发放处理部211在进行文件接收处理时，于接收 到实际文件数据之前进行票据的发放处理（详见图17的说明）。票据 的发放用于确定文件接收服务器101的文件提出日期与时刻的处理。这 就是说，从代理人装置104将文件发送给文件接收服务器101之际，若 把实际要发送的文件作为数据原样发送时，需要很长的时间。因此，容 易产生再发送的必要性。这将使此种文件提交的时刻变得不明确，而且 会出现滥用文件提交时刻不明确的问题，因此进行下述(D ~ ©中的处 理。① 首先由代理人装置104将实际欲发送的数据由单向函数例如散 列函数压缩，求得信息提要，将此信息提要发送给文件接收服务器101(具体地说，附有证明书进行加密通信）。② 在文件接收服务器101中，经票据发行处理部211的票据发放处 理（困17),取得新的接收编号。然后，文件接收服务器101使此接收 编号与该信息提要相对应进行存储，并在同时将此接收编号发送给代理 人装置。用来发送此接收编号的数据便是票据。如以后所述，这时的文 件接收服务器101便确定与此信息提要相对应的文件接收的日期与时 刻。③ 代理人装置104在根据票据接收到接收信号后，即附上此接收编 号作为实际发送的数据发送给文件接收服务器101。④ 在文件接收服务器101中，当从代理人装置104接收到全部数据 后，由单向函数（同①中所用的函数）压缩这种数据求得信息提要，来 确认其是否与②中存储的信息提要一致。如果一致，则从票据发行时由 代理人装置104实际发送后，实际接收到的便是目的数据。如果不一致， 则发送的可能是别的数据。图8示明了本实施例的系统中，从文件接收服务器IOI发送给代理 人装置104的票据内容。接收编号801是从代理人装置104发送文件时对应于此文件的发送，文件接收服务器101新分配的编号。发送者信息 802是对发送此文件的送信者（代理人）特定的种种信息。接收日期与 时刻803是文件接收服务器IOI接收信息提要结束的日期与时刻。有效 期限804表示的是此票据的有效期限。从代理人装置104发送文件时， 即使发生再发送的问题，也可只把发送该文件的那段充分的时间取作有 效期限（也可取从票据发行时起的一段预定时间）。为了防止文件发送 的极端过迟才确定了有效期限804。署名805是相对于801 ~ 804的数据 附加文件接收服务器101的电子署名。图9示明本实施例的系统中所用图1的接收管理DB231的内容。 文件接收服务器101在上述②的票据发放处理（图17)中取得新的接收 编号时，在此接收管理DB231上即取得新的接收编号，并确保与所接收 编号相对应的1行的区域。在接收编号901、发送者信息902、接收曰 期与时刻903以及有效期限904中，存储有与设定在发送票据（图8) 中的信息801 - 804相同的内容。在信息提要905与发送者证明书906 中存储有上述①中由代理人装置104发送来的信息。此外，票据管理信 息907存储有此票据使用与否的标记信息，且令初始值为"未使用"。 文件的内容908是存储从代理人装置104送来的文件中全部数据的区 域。在上述④中确认信息提要是一致时，文件接收服务器101在票据管 理信息907 "使用完毕"时，即把接收的文件数据存储于文件内容908 中。再回到图2，继续说明文件接收服务器101的结构。署名生成部213 与加密/译码处理部214用于在进行文件接收处理中给发送数据附上署 名，以及用于进行加密/译码处理。通信控制部215进行和因特网110 之间的通信控制。支付接收服务器102从申请人接收费用支付。在此实施例系统中， 申请人从申请人装置105连接到支付接收服务器102,从而进行费用支 付处理。在图2中，支付接收处理部221进行接收申请人费用支付要求 的处理（由图13作详细说明），将表明申请人已进行了费用支付（或 已保证支付）的支付证明书发放给申请人。支付证明书起到印花票，收讫标签或代用券与商品券之类的作用。支付证明书的发放，是就申请人 而言相对于金融机关在执行支付信用查询与支付预约时所发放的。因此，文件接收服务器101与支付接收服务器102的管理机关必然可以相 应申请人的户头上划拨支付证明书所发放的金额。支付证明书与预先交 费不同，它首先不必开设预交户口。支付证明书如同印花票那样，可用 于别的文件中或是赠与他人。图6中示明本实施例的系统中所用支付证明书的内容。支付证明书 包括管理编号601、支付金额602、申请人信息603、有效期限604以及 支付接收服务器102的署名605。管理编号601是支付证明书固有的管 理编号。支付金额602是指定申请人支付的金额的信息。申请人信息603 是具体规定提出支付请求并接收相应支付证明书的申请人的信息。有效 期限604是此支付证明书的有效期限。署名605是发放此支付证明书的 支付接收服务器102的署名，由此保证此支付证明书确实是从支付接收 服务器102所发放的。这些信息604~ 605是在相对于支付接收服务器 102,在此即为费用支付人也即申请人，发放上述支付证明书时设定的。图7示明本实施例的系统中所用图1的支付证明书管理DB234的 内容。支付接收服务器102由此支付证明书管理DB管理所发放的支付 证明书。在支付证明书管理DB234的701 - 705中，存储有发放的支付 证明书601~ 605的信息。使用状态706是表明此支付证明书是否使用 过的标志。当文件服务接收器IOI接收文件时，由附于此文件上的支付 证明书的管理编号601来检索支付证明书管理DB234，搜索相对应的入 口。如果此入口的使用状态706为"未使用"时，由于此支付证明书亦 处在未使用情形，则令此使用状态706为"使用完毕"。这相当于确认 已贴附有印花票或收讫标签等。当再次发送使用同一支付证明书的文件 时，由于使用状态706为"使用完毕"，则可确认费用的支付没有保证。由于是用图7所示的支付证明书管理DB234来管理支付证明书， 既4吏支付费用的申请人和实际进行文件发送的代理人不是同一人时，也 可完成相应的手续。此外，支付证明书也可以转让给他人来使用。再次返回图2继续说明支付接收服务器102的结构。署名生成部222与加密/译码处理部223，用于在进行支付接收处理时给传输数据上 附上署名，以及用于进行加密/译码。支付证明书生成管理部224生成图 6所示的支付证明书，由图7所示的支付证明书管理DB234进行此支付 证明书的管理处理。SET处理部225在从支付接收服务器102相对于金 融机关服务器106执行申请人的信用查询时，进行遵照SET协议的处 理。通信控制部226进行与因特网IIO之间的通信控制。有关由文件接收服务器101和支付服务器102两方共同访问的DB 即接收管理DB231与支付证明书管理DB234，已由图9与图7说明。 密钥与证明书管理DB232，是用来管理文件接收服务器101与支付服务 器102的私有密钥与公开密钥以及由认证局103、 107发放的证明书、 进行认证时所用的认证局103、 107的公开密钥，还有通信对方的公开 密钥等的DB。申请人与代理管理DB233是用来管理有关与文件接收服 务器101和支付接收服务器102相连接的申请人或代理人的信息的DB。在此实施例中，文件接收服务器101与支付接收服务器102是分别 设置而共同4吏用同一个DB230的，但也可取不用共同的DB而是完全分 开的DB的结构。这时的支付管理DB231可由文件接收服务器101管理。 在这种情形下，文件接收服务器101可对支付证明书管理DB234进行 访问，要求使检索入口的使用状态706从"未使用"变更到"使用完毕" 的情形代之以文件接收服务器101相对于支付接收服务器使该入口的使 用状态从"未使用"变更到"使用完毕"。相反，文件接收服务器101 与支付接收服务器102也可包括DB203而在一台装置上构成。这时的 通信控制部215与226、署名生成部213与222以及加密/译码处理部214 与223也可具有共同的结构。图3示明图1所示认证局103的结构。认证局103包括证明书发放 处理部301、证明书管理部302、通信控制部304及以证明书管理DB311。 认证局103首先是发放证明书给代理人或申请人。图4示明图1所示代理人装置104的结构。代理人装置104包括申 请书编辑部401、署名生成部402、加密/译码处理部403、文件发送处 理部404、文件接收处理部405、通信控制部406、申请书管理DB411以及密钥与证明书管理DB412。申请书编辑部401是代理人用来制成发送的文件的编辑程序。文件 输送处理部404进行把文件发送给申请人装置105的处理（由图10详 释）或是进行把附有支付证明书的文件发送给文件接收服务器101的处 理（由图16详释）。署名生成部402与加密/译码处理部403是在把署 名附于发送/接收的数据上时，以及在进行加密/译码处理时使用。通信 控制部406进行与因特网IIO之间的通信控制。申请书管理DB411是把代理人用申请书编辑部401制成的文件或 由申请人装置105送来的附有支付证明书的文件加以保存、管理的DB。 密钥与证明书管理DB412是用来管理代理人装置104的私有密钥、公 开密钥以及认证局103与107发放的证明书、进行认证时所用的认证局 103、 107的公开密钥以及通信对方的公开密钥等的DB。图5示明图1中所示申请人装置105的结构。申请人装置105包括 文件接收处理部501、接收文件管理部502、加密/译码处理部503、署 名生成部504、支付处理部505、文件发送处理部506、支付证明书管理 部507、通信控制部508、申请书管理DB511、密钥与证明书管理DB512 以及支付证明书管理DB513。文件接收处理部501进行从代理人发送来的文件的接收处理（详释 于图11中）。接收文件管理部502将接收的文件在申请书管理DB231 中加以保存并管理。支付处理部505与支付接收服务器IOO连接，进行 手续费的支付处理（详释于图12中）。文件输送处理部506相对于代 理人进行附有支付证明书的文件等的发送处理（详释于图14中）。署 名生成部504与加密/译码处理部503用于在将署名附于发送数据上时， 以及进行加密/译码处理时。支付证明书管理部507对支付接收服务器 102发放的支付证明书由支付证明书管理DB513进行管理处理。通信控 制部508进行与因特网之间的通信控制。申请书管理DB511是对代理人发送来的文件等进行保存与管理的 DB。密钥与证明书管理DB512是管理申请人装置105的私有密钥与公 开密钥以认证局103与107发行的证明书、进行认证时所用的认证局103与107的公开密钥及通信对象的公开密钥等的DB。支付证明书管理 DB513是保存与管理支付接收服务器102发放的支付证明书，它的结构 与图7所示的支付接收服务器102的支付证明书管理DB234相同。但 是，此支付证明书管理DB513是管理申请人所接收的支付证明书，而使 用状态706则表明此申请人使用与否的信息。下面，参照图10-图18的流程图及图19的时间图详细说明图1 的系统的各处理。图10是示明从代理人装置104到申请人装置105的文件发送流的 流程图。此流程的处理主要是由图4所示的文件处理部404所进行的处 理。首先由代理人根据申请人委托用图4所示的申请书编辑部401制成 文件。在步骤1001相对于所发送的文件实施代理人的电子署名。具体 地说，由单向函数（散列函数等）压缩文件数据，然后将此压缩数据（信 息提示）用代理人的私有密钥加密得到的署名数据附于原始的文件数据 上，制成附有代理人署名的文件。随后于步骤1002形成使附有代理人 署名的文件加密的共用密钥，由此共用密钥使代理人署名的文件加密。 再于步骤1003用申请人的公开密钥使上述共用密钥加密。在步骤1004， 将已加密的附有代理人署名的文件与共用密钥同代理人的证明书一起 发送给申请人装置105，结束处理。首先从认证局103取得代理人的证明书。所谓代理人的证明书是使 代理人的公开密钥与有关此代理人的种种信息相连系，并对于此连系的 数据由认证局103的私有密钥附上署名的数据。认证局103在接收代理 人的证明书发放委托时，进行此代理人的身分确认后，发放证明书。当 把此证明书附于代理人装置104发送的数据上，即可由此证明书验证此 数据确实为该代理人关来的数据，亦能从此证明书取得对此代理人的公 开密钥或代理人特别规定的种种信息。同样，申请人也是首先从认证局 预先取得证明书。图11示明根据图10的处理，接收从代理人装置104发送给申请人 装置105数据的，申请人装置105的处理流程。这一处理主要是由图5 的文件接收处理部501进行的处理。首先，于步骤1101验证接收数据中代理的证明书，同时用申请人的私有密钥使接收数据中的加密的共用密钥译码。在步骤1102,用译码后的共用密钥对附有代理的署名的文件 译码。于步骤1103用代理人的公开密钥验证附有此代理人署名的文件 的署名。这一验证是用来确认，由代理人公开密钥使署名数据译码的值， 是否等于由单向函数（采用与图10的步骤1001所用的相同的函数）压 缩的压缩数据（信息提要）。如果验证的结果是恰当的署名（步骤1104 中的"否"），则于步骤1105保管附有此代理人署名的文件。如果验 证的结果不是恰当的署名（步骤1104中的"是"），则申请人便于步 骤1106中报告申请文件被改动并结束此处理。图12是示明申请人费用支付处理的流程的流程图。这项处理主要 是由图5的支付处理部505进行的处理。首先于步骤1201中从申请人 装置105连接上支付接收服务器102,确定并输送支付的金额。在步骤 1202,将申请人的证明书（从认证局103取得的证明书）出示给支付接 收服务器102。步骤1203是支付接收服务器102方向的处理，由图13 于以后说明。在步骤1203之后，从支付接收服务器102发送由申请人 的公开密钥加密的共用密钥与由此共用密钥加密的支付证明书（图6)。 在步骤1204,由申请人的私有密钥使从支付接收服务器102发送的已加 密的共用密钥译码。在步骤1205,采用已译码的共用密钥使加密的支付 证明书译码。在步骤1206，将译码的支付证明书保管于支付证明书管理 DB513 (图7)中，结束处理。图13是示明图12的步骤1203的处理即支付接收服务器中支付接 收处理流程的流程图。这一处理主要是由图2中支付接收处理部221进 行的处理。首先于步骤1301中，验证申请人送来的证明书，取得申请 人的公开密钥。其次于步骤1302中，例如采用SET的协议，相对于金 融机实施来自申请人信用查询。具体地说，向图1的金融机关服务器106 发送特定的申请人与划拨的金额的信息，确保从此申请人的户头应划拨 下的金额。在对金融机关实施支付信用查询时，为了需要相对金融机关证明使 用支付接收服务器102的机关本身，此使用支付接收服务器102的机关需预先从金融机关认证局107取得证明书。同时，由于此支付信用查询 也应进行有关进行划拨的申请人的认证（必须确认是否确实是来自此申 请人的划拨委托），申请人首先也应从金融认证局107领得证明书，同 时在步骤1202将此金融机关的证明书发送给支付接收服务器102。此支 付接收服务器102在步骤1302实施信用查询时，需附上此申请人的金 融机关的证明书实施信用查询。

作为步骤1302的信用查询的结果，在步骤1303如果能确保上述所 划拨的金额部分的划拨范围便进行步骤1304。如果信用查询结果存在某 些问题便结束处理。在步骤1304，取得新发行的支付证明书的管理编号， 具体上是由图7所示结构的支付证明书管理DB234来确保新规定的管 理编号l行部分的区域。在步骤1305，从申请人的证明书提取表征申请 人的信息。在步骤1306，对管理编号、支付金额、表征申请人的信息以 及有效期效等相连接的数据实施电子署名，制成支付证明书（图6)。 具体地说，由单向函数压缩上述关联的数据，把由支付接收服务器102 的私有密钥加密此压缩数据的署名数据附于原始的相关数据上，制成支 付证明书。

在步骤1307，将此制成的支付证明书中所含信息记录于支付证明 书管理DB234 (图7)。然后于步骤1308生成支付证明书加密用的共 用密钥，用此共用密钥使支付证明书加密，再于步骤1309由申请人的 公开密钥使前述共用密钥加密。于步骤1301，将加密的共用密钥与由此 共用密钥加密的支付证明书发送给申请人装置105，结束处理。

图14是表示从申请人装置105向代理人装置104进行文件发送的 流程的流程图。主要由图5的文件发送处理部506进行处理。

首先在步骤1401,取出由图11的步骤1105保管的附有代理人署 名的文件。在步骤1402，对于含有附有代理署名的文件及支付证明书的 数据实施申请人电子署名，称其为附有支付证明书的文件。另外，此处 使用的支付证明书，在由图7的结构中由支付证明书管理DB513管理的 支付证明书中，使使用状况706为"未使用"的。

其次，在步骤1403中，生成共用密钥，用该共用密钥将附有支付证明书文件加密。在步骤1404，使用代理人的公开密钥，将前述共用密 钥加密。在步骤1405,将加密后的共用密钥和用该共用密钥加密的附有 支付证明书的文件发送给代理人装置104。

图15示明接收由图14的申请人发送的数据的代理人装置104的处 理流程图。此项处理主要是由图4所示文件接收处理部405的处理。首 先于步骤1501用代理人的私有密钥将接收数据中的加密共用密钥译码。 在步骤1502，用译码的共用密钥使附有支付证明书的文件译码。在步骤 1503，用申请人的公开密钥验证添加在附有此支付证明书文件上申请人 的电子署名。具体地说，进行处理来确认，由申请人公开密钥译码的署 名数据的值是否等于由单向函数（与图14步骤1402的署名中所用的相 同的函数）压缩附有支付证明书的文件所得的压缩数据。

在步骤1504,如果验正的结果是恰当的署名，则进行步骤1506。 在步骤1506,用支付接收服务器102的公开密钥来验证包括在附有支付 证明书文件中的支付证明书中的电子署名。这项验证是进行处理以确 认：由支付接收服务器102的公开密钥将署名数据译码的值，是否等于 由单向函数（与图13的步骤1306的署名中所用的相同的函数）压缩与 支付证明书中包括的管理编号、支付金额、表征申请人的信息以及有效 期限相连接的数据而得到的数据。

在步骤1507，如果验证的结果是恰当的署名，则进到步骤1509。 于步骤1509,用代理人的私有密钥验证附有支付证明书的文件中所含附 有代理人署名的文件中的代理人署名。在步骤1510，如果验证结果是恰 当的署名，则于步骤1512中保管附有支付证明书的文件，结束处理。 如果在步骤1504、 1507、 1510任一个之中的验证结果表明是署名不恰， 则向代理人报告在步骤1505、 1508、 1511中改动了文件。

图16示明从代理人装置104向文件接收服务器101发送处理附有 支附证明书的文件的流程。这项处理主要是由图4中的文件发送处理部 404进行的处理。首先于步骤1601由单向函数压缩欲发送的附有支付证 明书的文件，生成压缩数据（信息提要）。然后于步骤1602生成共用 密钥，由此共用密钥使上述信息提要加密。在步骤1604，将代理人证明书加到由加密的共用密钥和由此共用密钥加密的信息提要中，发送给文

件接收服务器101。由于信息提要的发送时间比与之相应的整个文件的

发送时间短，因而可以减少因通信线路不良带来的恶劣影响的可能性。

步骤1605是文件接收服务器101这一方的票据发放处理，由图17 在以后说明。在步骤1605之后，从文件接收服务器101来发送由代理 人公开密钥加密的共用密钥（由文件接收服务器101方面生成的密钥） 和由此共用密钥加密的票据（图8)。

在步骤1606,用代理人的私有密钥将文件接收服务器101送来的 加密的共用密钥译码。在步骤1607，用文件接收服务器101的公开密钥 来验证附于票据（图8)上的电子署名。在步骤1609，如果验证的结果 表明是恰当的署名，由于能确保文件接收服务器101的接收的或提交的 日期与时刻，便进行步骤1611。在步骤1609，如果署名不恰，则向代 理人报告在步骤1610中票据有了改动，结束此处理。

如果接收到正确的票据，则于步骤1611生成共用密钥，而在步骤 1612由此共用密钥将附有支付证明书的文件加密。随后于步骤1614, 由文件接收服务器101的公开密钥将上述共用密钥加密。再在步骤1615 将此加密的共用密钥以及由此共用密钥加密的票据和附有支付证明书 的文件发送给文件接收服务器101。步骤1616是文件接收服务器101 一方的处理，由图18于以后说明。步骤1616之后，由文件接收服务器 101发送由代理人的公开密钥加密的共用密钥和由此共用密钥加密的接 收确认书。

在步骤1617,由代理人的私有密钥使由文件接收服务器101发送 的加密的共用密钥译码。在步骤1618,用译码的共用密钥使编码化的接 收确认书译码。在步骤1619，验证添加到接收确认书上的文件接收服务 器101的电子署名。在步骤1620,如果验证结果表明署名恰当，则于步 骤1622保管此接收确认书，结束处理。在步骤1620，如果验证结果表 明署名不恰，则向代理人报告于步骤1620中改动了某些数据，结束处 理。

图17是表明图16的步骤1605的处理即文件接收服务器101的票据发放处理的流程。这项处理主要是由图2的票据发行处理部211进行 的处理。首先于步骤1701，用文件接收服务器101的私有密钥使代理人 发送来的共用密钥译码。随之于步骤1702，用此共用密钥使信息提要译 码。再于步骤1703取得新的接收编号，将此接收编号901、有关代理人 (发送者）的信息902、接收的日期与时刻903、有效期效卯4、信息提 要905及代理人的证明书906保存于接收管理DB231(困9)中。此外， 有关代理人的信息设定为从代理人发送来的数据中所包含的代理人证 明书中抽取出的信息。有效期限设定为在现在的时间上加上预定时间而 得到的时间。票据的管理信息907初始化为"未使用"。

在步骤1704生成连接接收编号801、有关代理人的信息802、接收 的日期与时刻803以及有效期效804的数据，对此连接数据实施电子署 名805。附有此电子署名的数据即票据（图8)。具体地说，用单向函 数（图16的步骤1601或1608中所用的同一函数）压缩上述连接数据， 把由文件接收服务器101的私有密钥加密此压缩数据而成的署名数据， 相对于原来的连接数据制成票据（图8),然后于步骤1705生成共用密 钥，由此共用密钥使上述票据加密。在步骤1707把加密的共用密钥以 及为此共用密钥编码化的票据发送给代理人，结束此处理。

图18示明图16的步骤1616的处理即文件接收服务器101中的文 件接收处理流程。这项处理主要是由图2的文件接收处理部212进行的 处理。首先于步骤1801用文件接收服务器101的私有密钥使由代理人 发送来的共用密钥译码。随后在步骤1802，用已译码的共用密钥，使票 据和附有支付证明书的文件译码。然后于步骤1803,验证附于票据上的 电子署名以及有效期限。验证的结果，当于步骤1804中署名恰当且在 有效期限内时，进行步骤1806。当署名不恰或超过有效期限，则于步骤 1805表明票据不当，结束处理。

在步骤1806,用代理人装置104所用的单向函数（图16的步骤1601 或1608中所用的同一函数），将代理人送来的附有支付证明书的文件 压缩，生成信息提要。于步骤1807，从代理人送来的票据中提取接收编 号。然后，参照接收管理DB231 (图9)，取出对应于此接收编号的票据，索求的信息提要，与步骤1806生成的信息提要比较。比较的结果 据步骤1808是同一时，由于能确切地认定在票据索取时欲发送的内容 和发送来的相同，便进到步骤1810。当于步骒1808中比较的结杲不同 时，由于在票据索取时输送了与欲发送的内容有别的内容，在步骤1809 进行数据不一致的显示，结束此处理。

在步骤1810,从支付证明书管理DB234 (图7)中检索支付证明 书中所包括的管理编号的数据，验证其使用状况706是否为"未使用"。 在步骤1811，在"未使用"时，即由步骤1813将支付证明书管理DB234 中相应于该管理编号的支付证明书的使用状况706变更为"使用完毕"。 其次，于步骤1814,将该接收编号的票据的管理信息907变更为"使用 完毕"。再于步骤1815,保管附有支付证明书的文件。文件的保管通过 存储于图9的接收管理DB231的文件的内容908进行。

在步骤1816，制成包含接收编号等接收信息的接收确认书，进行 电子署名。在步骤1817，生成共用密钥，由此共用密钥使上述附有电子 署名的接收确认书加密。于步骤1818,由代理人的公开密钥使上述共用 密钥加密。在步骤1819,将加密的共用密钥以及由此共用密钥加密了的 附有电子署名的接收确认书发送给代理人，结束此处理。

根据上述实施形式的系统，申请人取得支付证明书，而代理人能将 此支付证明书附于提交文件上发送给文件接收服务器。支付证明书能像 印花票、收讫标签、货币代用券或商品券那样地作用，由于附有支付接 收服务器的署名，不容易改动。实际的结帐则可用任意哪一种形式进行。 在支付信用查询的阶段，由于保证了可以进行划拨，在文件接收服务器 一方必然能征收到费用。同时，申请人将支付证明书附于文件上，并于 其全部材料上附有署名发送给代理人，因而这成为表明了申请人对该文 件内容了解的一种意志，使以后的代理人也不能改动此文件。

在确定文件提交时刻之中，首先用单向函数压缩提交者发送的文件 数据而求得信息提要，把它与证明书一道发送给文件接收服务器，由文 件接收服务器存储此信息提要，返回票据。然后，在由提交者发送全部 文件数据时，求出此信息提要，与票据发放时存储的信息提要比较，以确认从一开始送出的预定文件已送出，由此可把票据发放时刻视作为文 件提交的时刻。

图19示明能由两个代理人装置分别将各自的电子文件基本上同时 送到文件接收服务器101中时，确定文件接收时间的情形。

图中，首先由代理人装置104将电子文件A的信息提要A发送给 文件接收服务器IOI。文件接收服务器IOI接收到信息提要A后，按图 17的步骤1701 ~ 1702使此信息提要译码，于步骤1703确定文件A的 接收编号同时确定文件A的接收曰期与时刻。这一处理即图19的步骤 1901。

另一方面，比信息提要稍晚，代理人装置104，将电子文件B的信 息提要B发送给文件服务器101。同样，文件接收服务器101在接收到 信息提要B后，于步骤1902确定文件B的接收编号同时确定文件B的 接收日期与时刻。

其次，代理人装置104，将附有支付证明书的文件B发送给文件接 收服务器101,然后由代理装置104将附有支付证明书的文件A发送给 文件接收服务器IOI。如果文件A与B中任一个都是合理的文件时，文 件接收服务器101便给代理人装置104与104，发放文件接收确认书。

从图19可知，从代理人装置104向文件接收服务器101的信息提 要A的发送，要比从代理人装置104，的信息提要B的发送快，但文件A 的发送则比文件B的发送慢。这时，给以文件A由步骤1901确定的接 收曰期与时刻，给以文件B由步骤1902确定的接收日期与时刻。这就 是说，文件A的接收日期与时刻比文件B的早。若是文件A与B为同 一内容的专利申请说明书，假定文件接收服务器101是专利局，则专利 局将决定文件A这一方为最前的专利申请。

子，但申请人也可不经由代理人而对文件接收服务器直接进行文件的发送。

另外，在上述实施例中，是以采用SET为例说明支付方式，但也 可采用SET之外的支付方式，例如不使用SET的信用卡的支付方式等。再者，此述实施例中，申请人与手续费支付人虽为同一人，但本发 明也适用于申请人与支付人为不同的情形。这时，支付人的计算机即支

付人装置可以由与图5所示申请人装置105相同的结构实现。支付人装 置接收申请人手续费的支付委托，对支付接收服务器102提出支付处理 要求。支付接收服务器102在实施支付人的信用查询后给支付人发送支 付证明书。此支付证明书从支付人装置转送给申请人装置105。

本发明适用于经由因特网将文件发送给专利局、登记所或是机关等 公用机构等的情形。此外也能用于所谓的电子购物等。