本发明的目的在于提供使经由通信网络来发送电子文件和交纳 其手续费两者能方便进行的文件发送系统与方法。
根据上述目的，可以在经由因特网等通信提交电子文件之际有需 要支付手续费时，不必要设置预交户口这类的特别户头，也不必要从 信用卡或银行户头由另外的步骤来进行划拨处理，而且即使是费用支 付者与文件提交者不同时，也能恰当地进行文件的提交及其费用的支 付。
本发明的另一个目的在于提供于通信中提交电子文件时，具有不 允许滥用，能合理地确定提出日期与时刻的结构的文件发送系统与方 法。
一种文件接收方法，其特征在于，将对应发送的文件施加单 向函数后所得到的第一压缩数据经由网络从发送文件的装置发 送给文件接收服务器；在所述文件接收服务器中，将接收到的所 述第一压缩数据与所述第一压缩数据的接收时间存储于存储装 置中；在所述第一压缩数据发送后，将前述文件的非压缩数据经 所述网络从所述文件发送装置发送给所述文件接收服务器；在所 述文件接收服务器中，把对所接收到的所述非压缩数据施加单向 函数后所得到的第二压缩数据与所述第一压缩数据进行比较，当 得到所述第一与第二压缩数据相一致的比较结果时，将所述第一 压缩数据的接收时间确定为所述文件的接收时间。
根据本发明的一种实施形式，提供了经由网络从申请人装置相对 于文件接收服务器发送文件的文件发送系统，其中，在前述网络上连 接有支付接收服务器；前述申请人装置具有相对于此支付接收服务器 指定支付金额，委托其进行费用支付的装置；此支付接收服务器具有： 根据来自前述申请人装置的对费用支付的委托，实施相对于金融机关 的支付的信用查询的装置，和根据此信用查询判明前述申请人的费用 支付有保证时，将表示该费用支付得到保证为宗旨的支付证明书制成 不能改动形式发送给前述申请人装置的装置；前述申请人装置具有将 前述支付证明书附于发送的文件中作为附有不能改动形式的支付证 明书的文件发送给前述文件接收服务器的装置；此文件接收服务器具 有在确认由前述申请人装置送来的支付证明书为未曾使用的之后，将 附有此支付证明书的文件加以保管的装置。
根据本发明的另一种实施形式，提供了经由网络从申请人装置， 通过代理人装置代理，相对于文件接收服务器发送文件的文件发送系 统，其中，在前述网络上连接有支付接收服务器；前述申请人装置具 有相对于此支付接收服务器指定支付金额且委托其进行费用支付的 装置；此支付接收服务器具有：根据来自前述申请人装置的对费用支 付的委托，实施相对于金融机关的支付的信用查询的装置，和根据此 信用查询判明前述申请人的费用支付有保证时，将显示该费用支付得 到保证为宗旨的支付证明书制成不能改动形式发送给前述申请人装 置的装置；前述申请人装置具有将前述支付证明书附于发送的文件中 作为附有不能改动形式的支付证明书的文件发送给前述代理人装置 的装置；前述代理人装置具有将接收的附有支付证明书的文件发送给 前述文件接收服务器的装置；此文件接收服务器具有在确认由前述申 请人装置送来的支付证明书为未曾使用的之后将附有此支付证明书 的文件加以保管的装置。
根据本发明的又一种实施形式，提供了经由网络从申请人装置相 对于文件接收服务器发送文件的文件发送系统中，伴随文件发送接收 费用支付的支付接收服务器，它包括有：根据来自前述申请人装置的 对费用支付的委托，实施相对于金融机关的支付的信用查询的装置； 和根据此信用查询判明前述申请人的费用支付有保证时，将显示该费 用支付得到保证为宗旨的支付证明书制成不能改动形式发送给前述 申请人装置的装置。
根据本发明的再一种实施形式，提供了经由网络从预定的装置相 对于文件接收服务器发送文件的文件发送系统，此系统包括：由前述 发送文件的预定装置对欲发送的文件数据作单向函数变换取得压缩 数据，并将此压缩数据以不可改动形式发送给前述文件接收服务器的 装置；由前述文件接收服务器存储所接收的压缩数据之后，将票据发 送给前述发送文件装置的装置；在前述发送文件装置接收至票据时进 行将欲发送的文件数据发送给前述文件接收服务器的装置，在前述文 件接收服务器接收到全部前述文件数据后，把对此文件数据施加单向 数据取得的压缩数据与前述存储的压缩数据相比较，来确认这些压缩 数据是否一致的装置。
根据本发明的又一实施形式，提供了经由网络从申请从装置相对 于文件接收服务器发送文件的文件发送方法，此方法包括下述步骤： 在前述网络上连接支付接收服务器的同时，由前述申请人装置相对于 前述支付接收服务器指定支付金额且委托其进行费用支付的步骤；由 前述支付接收服务器根据来自前述申请人装置的对费用支付的委托， 实施相对于金融机关的支付的信用查询的步骤；根据此信用查询判明 前述申请人的费用支付保证时，将显示该费用支付得到保证为宗旨的 支付证明书制成不能改动形式发送给前述申请人装置的步骤；由前述 申请人装置将前述支付证明书附于应发送的文件中作为附有不能改 动形式的支付证明书的文件发送给前述文件接收服务器的步骤；由前 述文件接收服务器在确认由前述申请人装置送来的支付证明书为未 曾使用之后，将附有此支付证明书的文件加以保管的步骤。
根据本发明的再一种实施形式，提供了经由网络从预定的装置相 对于文件接收服务器发送文件的文件发送方法，此方法包括下述步 骤：由前述发送文件的预定装置对欲发送的文件数据施加单向函数变 换取得压缩数据，并将此压缩数据以不可改动形式发送给前述文件接 收服务器的步骤；在前述文件接收服务器存储所接收的压缩数据之 后，将票据发送给前述发送文件装置的步骤；在前述发送文件装置接 收到票据后进行将欲发送的文件数据发送给前述文件接收服务器的 步骤；在前述文件接收服务器接收到全部前述文件数据后，把对此文 件数据施加单向函数变换取得的数据与前述存储的压缩数据相比较， 来确认这些数据一致的步骤。
根据本发明的实施例，在经由因特网等通信进行电子文件的提交 而需支付费用时，若相对于支付接收服务器提出支付的委托时，此支 付接收服务器则实施信用查询，在费用的支付有保证时，即发放旨在 表明具有不可改动形式的支付证明书，这样，就可不必设置预交户头 之类的特别户头，也不存在在从信用卡或银行户头上由另外方面进行 划拨处理时而未曾划拨的情形，此外，即使费用支付者与进行文件提 交者不同时，也能够恰当地进行文件的提交及其费用的支付。
再者，提供了这样的结构，使得在发送文件之前是将所发送的文 件用单向函数压缩成的压缩数据来发送，然后与相对于实际发送的文 件由相同单向函数压缩成的压缩数据进行比较确认，这样，在由通信 进行电子文件的提交时，就不会发生滥用，而能合理地确定提交的日 期与时刻。
附图说明
图1是本发明的实施例的文件发送系统的总图。
图2是图1中所示文件接收服务器与支付接收服务器的内部结构 图。
图3是图1所示认证局的结构图。
图4是图1所示代理人装置的结构图。
图5是图1所示申请人装置的结构图。
图6示明图1所示实施例的系统中所用支付证明书的内容。
图7示明图1所示实施例的系统中所用支付证明书管理DB的内 容。
图8示明图1所示实施例的系统从文件接收服务器发送给代理人 装置的票据的内容。
图9示明图1所示实施例的系统所用接收管理DB的内容。
图10是示明图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查询此支付证明书是 否是未曾使用过的，如果是未曾使用的，文件接收服务器101便进行 使用结束的处理。
认证局103是发放用于进行申请人或代理人认证的证明书的认证 机构。金融机关服务器106是设有申请人户头的金融机关的服务器。 金融机关认证局107是发放用来进行具有此户头的申请人认证的证明 书的认证机构。
图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 之际，若把实际要发送的文件作为数据原样发送时，需要很长的时间。 因此，容易产生再发送的必要性。这将使此种文件提交的时刻变得不 明确，而且会出现滥用文件提交时刻不明确的问题，因此进行下述①～ ④中的处理。
①首先由代理人装置104将实际欲发送的数据由单向函数例如散 列函数压缩，求得信息提要，将此信息提要发送给文件接收服务器101 (具体地说，附有证明书进行加密通信)。
②在文件接收服务器101中，经票据发行处理部211的票据发放 处理(图17)，取得新的接收编号。然后，文件接收服务器101使此 接收编号与该信息提要相对应进行存储，并在同时将此接收编号发送 给代理人装置。用来发送此接收编号的数据便是票据。如以后所述， 这时的文件接收服务器101便确定与此信息提要相对应的文件接收的 日期与时刻。
③代理人装置104在根据票据接收到接收信号后，即附上此接收 编号作为实际发送的数据发送给文件接收服务器101。
④在文件接收服务器101中，当从代理人装置104接收到全部数 据后，由单向函数(同①中所用的函数)压缩这种数据求得信息提要， 来确认其是否与②中存储的信息提要一致。如果一致，则从票据发行 时由代理人装置104实际发送后，实际接收到的便是目的数据。如果 不一致，则发送的可能是别的数据。
图8示明了本实施例的系统中，从文件接收服务器101发送给代 理人装置104的票据内容。接收编号801是从代理人装置104发送文 件时对应于此文件的发送，文件接收服务器101新分配的编号。发送 者信息802是对发送此文件的送信者(代理人)特定的种种信息。接 收日期与时刻803是文件接收服务器101接收信息提要结束的日期与 时刻。有效期限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是表明此支付证明书是 否使用过的标志。当文件服务接收器101接收文件时，由附于此文件 上的支付证明书的管理编号601来检索支付证明书管理DB234，搜索 相对应的入口。如果此入口的使用状态706为“未使用”时，由于此支 付证明书亦处在未使用情形，则令此使用状态706为“使用完毕”。这 相当于确认已贴附有印花票或收讫标签等。当再次发送使用同一支付 证明书的文件时，由于使用状态706为“使用完毕”，则可确认费用的 支付没有保证。
由于是用图7所示的支付证明书管理DB234来管理支付证明书， 既使支付费用的申请人和实际进行文件发送的代理人不是同一人时， 也可完成相应的手续。此外，支付证明书也可以转让给他人来使用。
再次返回图2继续说明支付接收服务器102的结构。署名生成部 222与加密/译码处理部223，用于在进行支付接收处理时给传输数据 上附上署名，以及用于进行加密/译码。支付证明书生成管理部224生 成图6所示的支付证明书，由图7所示的支付证明书管理DB234进行 此支付证明书的管理处理。SET处理部225在从支付接收服务器102 相对于金融机关服务器106执行申请人的信用查询时，进行遵照SET 协议的处理。通信控制部226进行与因特网110之间的通信控制。
有关由文件接收服务器101和支付服务器102两方共同访问的 DB即接收管理DB231与支付证明书管理DB234，已由图9与图7说 明。密钥与证明书管理DB232，是用来管理文件接收服务器101与支 付服务器102的私有密钥与公开密钥以及由认证局103、107发放的证 明书、进行认证时所用的认证局103、107的公开密钥，还有通信对方 的公开密钥等的DB。申请人与代理管理DB233是用来管理有关与文 件接收服务器101和支付接收服务器102相连接的申请人或代理人的 信息的DB。
在此实施例中，文件接收服务器101与支付接收服务器102是分 别设置而共同使用同一个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进行与因特网110之间的通信控制。
申请书管理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与支付接收服务器100连接，进 行手续费的支付处理(详释于图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来确保新 规定的管理编号1行部分的区域。在步骤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、有效期效 904、信息提要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发送 给文件接收服务器101。文件接收服务器101接收到信息提要A后， 按图17的步骤1701～1702使此信息提要译码，于步骤1703确定文件 A的接收编号同时确定文件A的接收日期与时刻。这一处理即图19 的步骤1901。
另一方面，比信息提要稍晚，代理人装置104’将电子文件B的信 息提要B发送给文件服务器101。同样，文件接收服务器101在接收 到信息提要B后，于步骤1902确定文件B的接收编号同时确定文件 B的接收日期与时刻。
其次，代理人装置104’将附有支付证明书的文件B发送给文件接 收服务器101，然后由代理装置104将附有支付证明书的文件A发送 给文件接收服务器101。如果文件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。
本发明适用于经由因特网将文件发送给专利局、登记所或是机关 等公用机构等的情形。此外也能用于所谓的电子购物等。
本申请是申请号为98122775.9、申请日为1998年12月4日、发 明名称为“文件发送系统和方法”的发明专利申请的分案申请。