JPH11316779A

JPH11316779A - 立会人システム

Info

Publication number: JPH11316779A
Application number: JP12129598A
Authority: JP
Inventors: Motoi Kojima; 基小島; Toshihiko Kaji; 俊彦鍛冶; Yasuharu Ito; 康晴伊藤
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1998-04-30
Filing date: 1998-04-30
Publication date: 1999-11-16
Also published as: US7418397B2; US20030078862A1; US20090063313A1

Abstract

(57)【要約】【課題】本発明は立会人システムに関し、販売企業と
購買企業間の効率良い物流、及び決済処理を行うべく、
ＥＤＩ（電子データ交換）を使用し、且つ情報の安全性
を確保した立会人システム、及び当該立会人システムを
利用した決済処理を提供するものである。【解決手段】購買企業のコンピュータ５は納品伝票や
発注伝票に従って認証用書類を作成し、公証局７を介し
て販売企業のコンピュータ６に送る。販売企業側では送
付された認証用書類を自己が発した納品伝票や発注伝票
と対比し、内容に相違がないか確認し、内容が正しけれ
ば公証局７に対し確認応答を行う。公証局７は上記認証
用書類を立会人サーバ８の収納明細テーブル２０に登録
し、立会人によって認証したことを購買企業及び販売企
業に通知する。このように構成することにより、以後認
証されたデータに基づいて例えば支払明細書を作成し、
振り込み依頼を行う際、正確な支払明細書の作成を可能
とし、更に当該支払明細書に関す照合を購買企業及び販
売企業は上記立会人サーバ８を参照することによって容
易に行うことができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はＥＤＩ（電子データ
交換）を用い、販売者と購買者間の物流、及び決済シス
テムをサポートする立会人システムに関する。

【０００２】

【従来の技術】今日の流通システムは、多種類であり且
つ大量の商品を複雑な流通メディアを介して行われてい
る。このため販売者と購買者間で行う決済処理も複雑に
なっている。

【０００３】例えば、図５２に示すシステムは従来の決
済システムを示す図である。先ず、購買人（販売企業）
側では商品の納入の度に販売人（販売企業）から送られ
てくる（又は手渡される）納品伝票を精査し、例えば企
業内システムを利用して支払い対象となる明細伝票を確
定する。この際、明細伝票には納入企業名、納入日、納
入品目、単価、数量、合計金額、等が記載されている。

【０００４】その後、例えば支払期日単位で、明細伝票
を累積／合算し、支払明細書を作成する。この支払明細
書の作成は、上述のように各明細伝票を累積／合算した
結果であり、支払明細書では明細伝票の細かい項目は省
略される。例えば、納入企業名や支払期日、合計金額等
は記載されるが、より詳細な内容である納入日や納入品
目、単価、数量、等の情報は通常省略される。

【０００５】例えば、支払期日が月１回であり、毎日多
品目の商品を納入している場合の販売人と購買人間で
は、相当量の明細伝票が一枚の支払明細書中にまとめら
れることになり、支払明細書によってこれらを合算した
合計金額のみが確定される。

【０００６】また、購買人側では上述の支払明細書を使
用して、販売人側への振り込みを銀行に依頼する。銀行
では、例えば全銀為替システムを使用し、振り込み依頼
を受けた販売人に対し支払明細書の金額を振り込む。こ
の結果、支払いを受けた販売人は、銀行からの通知によ
り、自身の銀行口座に取引先企業（購買人）から合計い
くらの入金があったかを知る。

【０００７】

【発明が解決しようとする課題】従来の上記システムに
おいては、以下の問題が発生する。すなわち、従来のシ
ステムで使用される支払明細書は、前述のように複数の
納品伝票を取りまとめて支払い合計額を確定した書類で
あり、受け取った販売人側では支払われた金額の中に、
どの納品伝票が含まれているか判断できない。このこと
は、支払明細書には個々の取引の納入日、納入品目、単
価、数量、等が記載されないことに起因する。

【０００８】かかる場合、販売人は受け取った金額を確
認する際に、購買人に明細内容を確認する必要がある。
例えば、販売企業の経理担当者は、支払われた金額と請
求金額が合致しない場合には、販売企業に対し明細伝票
の内容確認や、支払い金額に対する個別の問い合わせを
行う必要が生じる。このことは経理部門に大きな負担を
与えることになり、決済処理の効率化の大きな障害とな
っている。

【０００９】すなわち、支払明細書により大量取引の一
括決済を行った場合、支払明細書の中の個別明細内容の
突き合わせに時間と人手が膨大に必要となる。また、大
量に売買を行う取引相手との決済において、売掛金／買
掛金の相殺処理を行うためには取引最小単位での決済、
すなわち伝票単位での決済が必要になる。しかし、上述
のように一括決済では支払い金額に対する個別の問い合
わせが必要となる。

【００１０】一方、今日インターネットの普及に伴っ
て、各種分野でＥＤＩ（電子データ交換）による情報交
換システムの構築が試みられている。特に企業間におい
て、このシステムを利用することにより、複雑な流通経
路における物流、決済処理を効率良く行えるようになる
ことが期待されている。

【００１１】本発明は販売企業と購買企業間の効率良い
物流、及び決済処理を行うべく、ＥＤＩ（電子データ交
換）を使用し、且つ情報の安全性を確保した立会人シス
テム、及び当該立会人システムを利用した決済処理を提
供するものである。

【００１２】

【課題を解決するための手段】請求項１記載の発明は上
記課題を解決するため、販売人から送られた販売人側記
録に基づいて、前記販売人側記録毎に確認用書類を作成
する確認用書類作成手段と、該確認用書類作成手段によ
って作成された書類を公証局に送付し、該書類を前記公
証局から更に前記販売人に送付する送付手段と、前記販
売人が、前記送付手段によって送付された前記書類の内
容と、前記販売人側記録の内容が一致しているか確認す
る確認手段と、該確認手段によって前記一致が確認され
たとき、前記書類が正確であることを確認する立会人
と、該立会人によって確認された書類を記憶する記憶手
段とを有する立会人システムを提供することによって達
成できる。

【００１３】ここで、販売人から送られた販売人側記録
は、例えば納品伝票、見積書、請求書、等であり、購買
人が納品された商品の明細を作成する際の商品名、個
数、単価、金額を特定できる書類である。また、購買人
及び販売人は企業、個人商店、等であり、法人、個人の
別を問わない。

【００１４】公証局は、納品伝票等に基づき販売人が作
成した明細の送付を受け、この明細を更に販売人に送信
し、明細の内容と納品伝票等の内容が一致しているかの
確認を求める。そして、販売人が両内容の一致を確認す
るとその通知を受け、立会人は上記明細を正しい書類と
確認すると共に、当該明細の確認を上記購買人、及び販
売人に行う。

【００１５】このように構成することにより、購買人の
作成した個々の納品の明細は購買人と販売人間で確認さ
れ、第三者である立会人によっても確認されたものであ
り、上記明細は正確なデータとして決済の際有効に使用
することができる。

【００１６】請求項２の記載は、前記請求項１記載の発
明において、前記確認用書類の作成は、例えば購買人が
行う構成である。すなわち、上記確認用書類の作成は、
販売人から納品伝票等の販売人側記録が送られた場合購
買人が作成するからである。但し、ＥＤＩ（電子データ
交換）による情報交換システムが構築され、納品伝票等
の販売人側記録が電子データ化されている場合には当該
データを使用することになる。

【００１７】請求項３の記載は、前記請求項１、又は２
記載の発明において、前記立会人が確認用書類を確認す
るとき、例えば該確認を購買人と販売人に通知する構成
である。

【００１８】このように構成することにより、購買人及
び販売人は確認用書類が立会人によって確認されたこと
を知ることができる。請求項４の記載は、前記請求項１
記載の発明において、前記確認用書類が前記販売人から
前記公証局に送付されたとき、例えば該書類を登録し、
該書類の登録の事実を公証する。

【００１９】前記確認用書類が前記販売人から公証局に
送信されたとき、該確認用書類が送付された事実を登録
する構成である。請求項５の記載は、上記請求項１又は
２記載の発明において、前記確認手段による前記一致の
確認において、前記両内容が一致しないとき、前記立会
人に対し内容不一致の通知を行う構成である。

【００２０】前記確認手段による前記一致の確認におい
て、例えば前記両内容が一致しないとき、前記立会人に
対し内容不一致の通知を行う構成である。このように構
成することにより、立会人は確認用書類を認証すること
がなく、この時点で販売人は購買人の作成した書類に誤
りがあることが分かり、購買人に対し通知し、書類の修
正により正確な確認用書類を作成させることができる。

【００２１】請求項６の記載は、上記請求項１又は２記
載の発明において、前記記憶手段による前記書類の記憶
は、例えば購買人毎に行う構成である。このように構成
することにより、立会人が確認した書類が記憶手段に複
数記憶され、購買人及び販売人はこの記憶手段を自由に
検索することによって、認証データを有効に活用するこ
とができ、更に販売人は取引のある購買人毎に明細の利
用を行うことができ、極めて有効な記憶手段となる。

【００２２】尚、上記記憶手段はＲＡＭ、ＲＯＭ、ＥＥ
ＰＲＯＭ、フロッピーディスク、ハードディスク、等の
各種メモリで構成することができる。請求項７記載の発
明は上記課題を解決するため、販売人から送られた販売
人側記録に基づいて、前記販売人側記録毎に公証用書類
を作成する公証用書類作成手段と、該公証用書類作成手
段によって作成した書類を公証局に送付し、該書類を前
記公証局から更に前記販売人に送付する送付手段と、前
記販売人が、前記送付手段によって送付された前記書類
の内容と、前記販売人側記録の内容が一致しているか確
認する確認手段と、該確認手段によって前記一致が確認
されたとき、前記書類が正確であることを公証する立会
人と、該立会人によって公証された書類を記憶する記憶
手段と、該記憶手段に記憶した前記公証用書類を参照し
て、購買人が前記販売人に支払う支払明細書を作成する
支払明細書作成手段と、該支払明細書作成手段により作
成した支払明細書に基づき、振り込み依頼を行う振込依
頼手段と、該振込依頼手段による振り込み依頼に基づい
て前記販売人に振り込みが行われたとき、当該振り込み
の事実を前記立会人に通知する通知手段とを有する立会
人システムを利用した決済方式を提供することによって
達成できる。

【００２３】本例は前記立会人システムを利用し、例え
ば商品代金の支払いを振り込みによって行う場合の決算
方式を実現するための構成である。この場合、販売人に
支払う商品代金等の支払い明細は上記立会人、又は購買
人が作成し、その作成の際、販売人の内容確認に従って
立会人が公証した公証書類に従って作成される。

【００２４】したがって、このように構成することによ
り、正確な支払明細書に基づいて振り込み決済を行うも
のであり、決済処理の際従来のように個々の納品伝票や
請求書を確認する必要がなく、決済処理を容易に行うこ
とができる。

【００２５】請求項８の記載は、上記請求項７記載の発
明において、前記支払明細書の作成は、例えば支払条件
に従って作成する構成である。ここで、上記支払条件
は、例えば支払日や支払方法であり、支払日としては１
９９８年〇月〇日という具体的な日付、又は毎週〇曜日
というような指定である。

【００２６】請求項９の記載は、上記請求項８の記載に
おいて、前記支払条件は前記立会人によって管理される
構成である。ここで、管理とはメモリに予め支払日と支
払方法を記憶し、支払明細書作成の際有効に使用するも
のである。

【００２７】このように構成することにより、納品伝票
等の前記公証書類と同様、立会人によって支払明細書の
作成に必要な書類が管理され支払明細書の作成を効率良
く行うことができる。

【００２８】請求項１０の記載は、上記請求項７記載の
発明において、前記販売人は前記記憶手段に記憶した書
類を参照して前記支払明細書の照合を行う構成である。
このように構成することにより、立会人又は販売人によ
って作成された支払明細書の照合を、販売人側が公証書
類を参照して行うことができる。すなわち、立会人又は
購買人による支払明細書の作成内容を販売人がチェック
する構成であり、支払明細書の作成内容を販売人が確認
するものである。

【００２９】請求項１１の記載は、前記支払明細書の作
成は、前記のように例えば購買人が行うことを示し、又
請求項１２の記載は、前記支払明細書の作成を前記立会
人が行うを示す。

【００３０】請求項１３の記載は、上記請求項１２の記
載において、前記購買人は前記記憶手段に記憶した書類
を参照して前記支払明細書の照合を行う構成である。こ
のように構成することにより、立会人が作成した支払明
細書の照合を、購買人が公証書類を参照して行うことが
できる。すなわち、立会人による支払明細書の作成内容
を購買人がチェックする構成である。

【００３１】請求項１４の記載は、前記請求項２又は３
に対応するものであり、前記公証用書類の作成は購買人
が行うこと、及び前記立会人が公証用書類を公証すると
き、該公証を購買人と販売人に通知することである。

【００３２】これらの請求項は立会人システムを利用し
た決済方式に適用するものである。請求項１５記載の発
明は上記課題を解決するため、販売人から送られた販売
人側記録に基づいて、前記販売人側記録毎に公証用書類
を作成する公証用書類作成手段と、該公証用書類作成手
段によって作成した書類を公証局に送付し、該書類を前
記公証局から更に前記販売人に送付する送付手段と、前
記販売人が、前記送付手段によって送付された前記書類
の内容と、前記販売人側記録の内容が一致しているか確
認する確認手段と、該確認手段によって前記一致が確認
されたとき、前記書類が正確であることを公証する立会
人と、該立会人によって公証された書類を記憶する記憶
手段と、前記購買人は前記記憶手段に記憶した前記書類
を参照して、前記購買人が前記販売人に支払う支払明細
書を作成する支払明細書作成手段と、該支払明細書作成
手段により作成した支払明細書に基づき、前記購買人に
対す小切手の振り出しを金融機関に請求する請求手段と
を有する立会人システムを利用した決済方式を提供する
ことによって達成できる。

【００３３】本発明は請求項７記載の発明と同様、前記
立会人システムを利用し、例えば商品代金の支払いを振
り込みによって行う場合の決算方式を実現するための構
成であり、前述と同様立会人によって公証されたデータ
に従って正確な支払明細書を作成し、これに基づいて小
切手の発行を請求して決済を行うものであり、決済処理
の際従来のように個々の納品伝票や請求書を確認する必
要がなく、決済処理を容易に行うことができる。

【００３４】請求項１６の記載は、上記請求項１５の記
載において、前記小切手の発行請求に基づき小切手を発
行したとき、前記立会人に通知する構成である。請求項
１７記載の発明は上記課題を解決するため、販売人から
送られた販売人側記録に基づいて、前記販売人側記録毎
に公証用書類を作成する公証用書類作成手段と、該公証
用書類作成手段によって作成した書類を公証局に送付
し、該書類を前記公証局から更に前記販売人に送付する
送付手段と、前記販売人が、前記送付手段によって送付
された前記書類の内容と、前記販売人側記録の内容が一
致しているか確認する確認手段と、該確認手段によって
前記一致が確認されたとき、前記書類が正確であること
を認証する立会人と、該立会人によって認証された書類
を記憶する記憶手段と、前記記憶手段に記憶した前記書
類を参照して、前記購買人が前記販売人に支払う支払明
細書を作成する支払明細書作成手段と、該支払明細書作
成手段により作成した支払明細書に基づき、前記購買人
に対す手形の振り出しを金融機関に請求する請求手段と
を有する立会人システムを利用した決済方式を提供する
ことによって達成できる。

【００３５】本発明も上述の発明と同様、前記立会人シ
ステムを利用し、例えば商品代金の支払いを振り込みに
よって行う場合の決算方式を実現するための構成であ
り、前述と同様立会人によって公証されたデータに従っ
て正確な支払明細書を作成し、これに基づいて手形の発
行を請求して決済を行うものであり、決済処理の際従来
のように個々の納品伝票や請求書を確認する必要がな
く、決済処理を容易に行うことができる。

【００３６】請求項１８の記載は、上記請求項１７の記
載において、前記手形の発行請求に基づき手形を発行し
たとき、前記立会人に通知する構成である。請求項１９
の記載は、上記請求項７、１５、又は１７記載の発明に
おいて、例えば前記購買人が前記販売人に対し売掛金を
有している場合、相殺処理を行う構成である。

【００３７】例えば、購買人が販売人に対し商品代金等
の逆の売掛金を有している場合、同じように支払明細書
を作成することは処理を複雑化するため、両請求代金を
相殺し、支払明細書の作成を行うものである。

【００３８】このように構成することにより、支払明細
書の作成処理をより容易にすることができる。請求項２
０の記載は、上記請求項１又は２記載の発明において、
前記立会人はシステムを利用する購買人、及び販売人を
予め認証し、手続きを行う際には認証証明書を用いて行
う構成である。

【００３９】このように構成することにより、以後の手
続きの際システムへの参加資格を認証証明書によって簡
単に確認することができシステムのセキュリティーを図
ることができる。

【００４０】請求項２１の記載は、上記請求項７、１
５、又は１７記載の発明において、前記立会人はシステ
ムを利用する購買人、及び販売人を予め認証し、手続き
を行う際には認証証明書を用いて行う構成である。

【００４１】このように構成することにより、以後の決
済処理の際、システムへの参加資格を認証証明書によっ
て確認し、安全な決済処理を行うことができる。請求項
２２の記載は、上記請求項１又は２記載の発明におい
て、例えば前記立会人、購買人、及び販売人間で行う送
受信データを暗号化する構成である。

【００４２】このように構成することにより、システム
の安全を確保することができる。請求項２３の記載は、
上記請求項７、１５、又は１７記載の発明において、例
えば前記立会人、購買人、及び販売人間で行う送受信デ
ータを暗号化する構成である。

【００４３】このように構成することにより、本システ
ムを使用する決済処理を安全に行うことができる。請求
項２４の記載は、上記請求項２２の記載において、例え
ば前記送受信データを前記立会人が公証する構成であ
る。

【００４４】請求項２５記載の発明は上記課題を解決す
るため、販売人から送られた販売人側記録に基づいて、
前記販売人側記録毎に確認用書類を作成する確認用書類
作成処理と、該確認用書類作成手段によって作成した書
類を立会人に送付し、該書類を前記立会人から更に前記
販売人に送付する送付処理と、前記販売人が、前記送付
手段によって送付された前記書類の内容と、前記販売人
側記録の内容が一致しているか確認する確認処理と、該
確認処理によって前記一致を確認するとき、立会人は前
記書類が正確であることを確認し、該確認を前記購買人
と前記販売人に通知する通知処理と、前記確認された書
類を記憶する記憶処理とを行う立会人システムによる書
類の確認方法を提供することによって達成できる。

【００４５】本発明は立会人認証方法であり、前記請求
項１の立会人システムをプロセスによって実現するもの
であり、このように構成しても第三者である立会人によ
って認証された認証書類に基づき各種決済処理を行うこ
とができる。

【００４６】請求項２６記載の発明は上記課題を解決す
るため、販売人から送られた販売人側記録に基づいて、
前記販売人側記録毎に公証用書類を作成する公証用書類
作成処理と、該公証用書類作成手段によって作成した書
類を公証局に送付し、該書類を前記公証局から更に前記
販売人に送付する送付処理と、前記販売人が、前記送付
手段によって送付された前記書類の内容と、前記販売人
側記録の内容が一致しているか確認する確認処理と、該
確認処理によって前記一致を確認するとき、立会人は前
記書類が正確であることを公証し、該公証を前記購買人
と前記販売人に通知する通知処理と、前記公証された書
類を記憶する記憶処理と、該記憶処理によって記憶した
前記公証用書類を参照して、前記購買人が前記販売人に
支払う支払明細書を作成する支払明細書作成処理と、該
支払明細書作成処理により作成した支払明細書に基づ
き、前記販売人に対する振り込み依頼を行う振込依頼処
理とを行う立会人システムを利用した決済方法を提供す
ることによって達成できる。

【００４７】本発明は立会人認証方法を利用した決済方
法であり、前記請求項１０の振り込み方式の決済処理を
プロセスによって実現するものであり、このように構成
しても第三者である立会人によって公証された公証書類
に基づき振り込み方式の決済処理を容易に行うことがで
きる。

【００４８】請求項２７記載の発明は上記課題を解決す
るため、販売人から送られた販売人側記録に基づいて、
前記販売人側記録毎に確認用書類を作成する確認用書類
作成処理と、該確認用書類作成手段によって作成した書
類を立会人に送付し、該書類を前記立会人から更に前記
販売人に送付する送付処理と、前記販売人が、前記送付
手段によって送付された前記書類の内容と、前記販売人
側記録の内容が一致しているか確認する確認処理と、該
確認処理によって前記一致を確認するとき、立会人は前
記書類が正確であることを確認し、該確認を前記購買人
と前記販売人に通知する通知処理と、前記確認された書
類を記憶する記憶処理とから成る立会人システムによる
書類の確認プロセスをコンピュータに実行させるプログ
ラムを格納した前記コンピュータが読み取り可能な記憶
媒体をを提供することによって達成できる。

【００４９】本例は、立会人システムを記憶媒体に記憶
した上記プログラムによって実現するものである。請求
項２８記載の発明は上記課題を解決するため、販売人か
ら送られた販売人側記録に基づいて、前記販売人側記録
毎に公証用書類を作成する公証用書類作成処理と、該公
証用書類作成手段によって作成した書類を公証局に送付
し、該書類を前記公証局から更に前記販売人に送付する
送付処理と、前記販売人が、前記送付手段によって送付
された前記書類の内容と、前記販売人側記録の内容が一
致しているか確認する確認処理と、該確認処理によって
前記一致を確認するとき、立会人は前記書類が正確であ
ることを公証し、該公証を前記購買人と前記販売人に通
知する通知処理と、前記公証された書類を記憶する記憶
処理と、該記憶処理によって記憶した前記公証用書類を
参照して、前記購買人が前記販売人に支払う支払明細書
を作成する支払明細書作成処理と、該支払明細書作成処
理により作成した支払明細書に基づき、前記販売人に対
する振り込み依頼を行う振込依頼処理とから成る立会人
システムを利用した決済プロセスをコンピュータに実行
させるプログラムを格納した前記コンピュータが読み取
り可能な記憶媒体を提供することによって達成できる。

【００５０】本例は、立会人システムを利用した決済処
理を記憶媒体に記憶した上記プログラムによって実現す
るものである。請求項２９記載の発明は上記課題を解決
するため、書類データを作成する第１の計算機手段と、
前記書類データの内容を確認する第２の計算機手段と、
前記確認に基づいて前記書類データの記憶、或いは公証
を行う第３の計算機手段とから成ることを特徴とする立
会人システムを提供することによって達成できる。

【００５１】また、請求項３０の記載は、上記請求項２
９記載の発明において、前記書類データの記憶及び内容
の確認は、前記計算機手段の画面表示に基づいて行う構
成である。

【００５２】請求項３１記載の発明は上記課題を解決す
るため、書類データは、遺言書、契約書、申込書、私
信、報告書、召喚状の１つ、又は組み合わせであること
を特徴とする。

【００５３】請求項３２記載の発明は上記課題を解決す
るため、第１の計算機手段は、書類データを暗号化して
第３の計算機手段を介して第２の計算機手段に送信し、
該第２の計算機手段は暗号化された前記書類データを復
号し、内容を確認して更に暗号化して前記第３の計算機
手段に送付し、該第３の計算機手段は第２の計算機手段
から送られたデータを更に暗号化し、第１、第２の計算
機手段に送付することを特徴とする。

【００５４】請求項３３記載の発明は上記課題を解決す
るため、第１、第２、第３の計算機手段間のデータの送
受信は、予め送信側の公開キーを受信側に送り、受信側
の公開キーを送信側に送付し、送信側においては、送信
側の秘密キーでメッセージを暗号化し、メッセージをＤ
ＥＳで暗号化したものに、ＤＥＳを復号化するＤＥＫを
受信側の公開キーで暗号化したものを加えて得たものを
送信データとして送信し、受信側においては、送信デー
タを受信し、該データを受信側の前記公開キーに対応す
る秘密キーで復号化してＤＥＫを取り出し、該ＤＥＫに
よりＤＥＳで暗号化されたデータを復号化し、送信側の
公開キーで送信側の前記秘密キーで暗号化されたデータ
を復号化することを特徴とする。

【００５５】請求項３４記載の発明は上記課題を解決す
るため、購買者側において、支払い対象の明細書を作成
し、支払い依頼と共に送信する支払い依頼手段と、該支
払い依頼手段で送信された支払い明細書と、販売者側の
販売記録とを比較する比較手段と、を備えたことを特徴
とする。

【００５６】

【発明の実施の形態】以下、本発明の実施形態例を図面
を用いて詳細に説明する。《第１実施形態例》図２は本実施形態例の立会人システ
ムの基本構成を説明する図である。

【００５７】本立会人システムは、基本的には購買人と
しての購買企業１と、販売人としての販売企業２、及び
購買企業１と販売企業２間で納品伝票等の販売人側記録
を認証する立会人３で構成されている。購買企業１は販
売企業２から商品を購入する、例えば大手スーパーや商
店等であり、販売企業２は例えば大手スーパー等に商品
を納入する業者であり、納入する商品としては例えば食
料品や衣類品、又は日用雑貨品等のあらゆる商品が対象
となる。

【００５８】先ず、購買企業１は確認してほしいデー
タ、例えば商品の納入伝票に記載のデータを立会人３に
送る（図２に示す）。このデータを受信した立会人３
は、先ず依頼を受けた事実のみを記録し、そのまま販売
企業２に送る（図２に示す）。確認依頼を受けた販売
企業２は上記データ内の記載内容を確認し、合意するか
否かの結果を立会人３に確認応答を行う（図２に示す
）。立会人３は確認応答を受信し、販売企業２が記載
内容に合意するならば、立会人３は当事者双方が上記デ
ータを認証したものとして購買企業１、販売企業２双方
に確認応答を送信する（図２に示す）。

【００５９】上記のようにシステムが機能することによ
り、立会人３は先ず購買企業１から送られたデータを受
信した事実を単に記録する機能と、更に進んで購買企業
１と販売企業２間で行われるデータ（確認用書類）の確
認を行う機能を有する。また、決済部４は上記データを
立会人３が保管し、支払明細書を作成し振り込み等の決
済を行う際使用する。

【００６０】図１は、本システムの具体的な構成を示す
図である。同図において、５は上述の図２に示す購買企
業１のコンピュータであり、６は販売企業２のコンピュ
ータである。また、立会人ＰＣ９は前述の立会人３に対
応する。この立会人ＰＣ９は、例えば購買企業１のコン
ピュータ５から出力される納品伝票データ等を確認し、
又販売企業２のコンピュータ６から出力される確認応答
を受信する。

【００６１】立会人サーバ８は立会人ＰＣ９が確認した
納品伝票等の確認書類を記憶する納品明細テーブル２
０、及び後述する支払条件テーブル２１、明細グループ
テーブル２２等を有する。上述のコンピュータ５及び６
は立会人サーバ８を直接アクセスし、上述の確認書類等
を参照することができる。

【００６２】また、各コンピュータ５及び６は、図３に
示すように不図示のＣＰＵがＲＡＭやハードディスク等
のメモリに記憶されたプログラム（データ）に従って後
述する処理を行う。また、上記プログラムはＣＤ−ＲＯ
Ｍやフロッピーディスクから供給を受けてもよく、また
回線を介してプログラム（データ）提供者から供給を受
けてもよい。

【００６３】また、図１に示すように、購買企業１のコ
ンピュータ５は確認依頼（処理Ｊ）、及び業務処理（処
理Ｋ）を行う。上記処理はコンピュータ５内のデータベ
ース５ａ、ライブラリデータベース５ｂを使用して行
い、その際ライブラリとのインターフェイス５ｃを使用
する。一方、販売企業２のコンピュータ６も同様な機能
を有し、データ確認処理（処理Ｌ）、業務処理（処理
Ｍ）を行う。上記処理もコンピュータ６内のデータベー
ス６ａ、ライブラリデータベース６ｂを使用して行い、
その際ライブラリとのインターフェイス６ｃを使用す
る。尚、同図に示す網掛け部分は企業クライアントのラ
イブラリであり、例えばネットワーク回線と接続する際
のインターフェイス等の機能を有する。

【００６４】以上の構成の立会人システムにおいて、以
下にその処理動作を説明する。図４は上述の処理Ｊ、Ｋ
をコンピュータ５が実行する際、又は処理Ｌ、Ｍをコン
ピュータ６が実行する際の手順を示す図である。尚、図
４ではディスプレイに表示される画面推移として示して
いる。

【００６５】先ず、購買企業１の処理を開始するために
はコンピュータ５の電源を投入し、ネットワークユーザ
ー名、パスワードを入力し、例えば画面上の「ＯＫ」表
示をクリックすることで、基本ＯＳ（オペレーティング
システム）に本システムのアイコン表示を行い、更に当
該アイコンをダブルクリックすることで立ち上げること
ができる。尚、同様に販売企業２のコンピュータ６、及
び立会人ＰＣ９を立ち上げる場合にも同様の処理を行
う。

【００６６】上述の処理によって、コンピュータ５（及
びコンピュータ６）のディスプレイには図５に示すログ
イン画面が表示される。このログイン画面は本例の立会
人システムを開始するためのものである。尚、このログ
イン画面は、図４においてスタート画面となる。

【００６７】このログイン画面において、ユーザＩＤと
パスワードを入力し、ログインボタンを押下すること
で、例えばコンピュータ５（コンピュータ６）は上記ユ
ーザＩＤとパスワードを確認し、一致していればメニュ
ー表示に移行し、メニュー画面を表示する。尚、キャン
セルボタンを押下すると、前のＯＳの初期画面に戻る。

【００６８】図６は上述のログインボタンを押下し、初
期メニューをディスプレイに表示した画面である。当該
初期メニューは、４個のボタン（表示）２７ａ〜２７ｄ
とメニューバーで構成されている。尚、メニューバーに
は図７に示すように、システムの終了バーがある。

【００６９】先ず、初期メニューの各ボタン（表示）に
ついて説明すると、２７ａは確認依頼を指示する際押下
するボタンであり、２７ｂは支払い一覧照会を指示する
際押下するボタンであり、２７ｃは確認済みデータ一覧
を指示する際押下するボタンであり、２７ｄは本例のプ
ログラムを終了する際押下するボタンである。尚、各ボ
タンの押下は、例えばマウスを操作してカーソルを指定
するボタン表示２７ａ〜２７ｄに移動し、マウスのボタ
ンをダブルクリックして行う。

【００７０】前述のように、購買企業１のコンピュータ
５が行う処理にはＪ、Ｋの処理があり、販売企業２のコ
ンピュータ６が行う処理にはＬ、Ｍの処理があり、以下
具体的に説明する。＜確認依頼処理（処理Ｊ）＞この処理は購買企業１が行
う処理であり、販売人側記録としての納品伝票、発注伝
票、又は請求書に基づいて購買企業１が行う処理であ
る。すなわち、購買企業１は販売企業２から送られた上
述の伝票に基づいて確認用書類を作成し、立会人３に送
る。

【００７１】この処理を具体的に説明する図が図８であ
る。また、図９はコンピュータ５が行う処理を説明する
フローチャートである。購買企業１は販売企業２から商
品の納入を受ける毎に、その際受け取る納品伝票のデー
タをコンピュータ５から立会人ＰＣ９に出力する。

【００７２】例えば、図８に示すように販売企業２であ
るＡ商店は購買企業１であるＢスーパーに食料品を納入
し、その際に納品伝票をＢスーパーに送る（手渡す）。
コンピュータ５は納品伝票の入力を待っており（ステッ
プ（以下Ｓで示す）１がＮ（ノー））、納品伝票が入力
すると（Ｓ１がＹ（イエス））、伝票情報の入力処理を
行う（Ｓ２）。例えば、図８に示す例では、購買企業１
（Ｂスーパー）は確認用書類Ｘ１として上述の納品伝票
のデータを作成する。この確認用書類Ｘ１には「納入者
（販売企業２）名」、「納入日」、「納入物品名」、
「納入金額」、等が含まれ、例えば「納入者名」として
上述のＡ商店、「納入日」として９８／０２／１０、
「納入物品名」としてマグロ、「納入金額」として￥１
５,０００が記載されている。この確認用書類Ｘ１は購
買企業１から立会人３に送信される（Ｓ３）（図８に示
す）。その後、購買企業１のコンピュータ５は上述の
送信データに対する応答を待つ（Ｓ４）。

【００７３】図１０は立会人ＰＣ９の処理を説明するフ
ローチャートである。立会人ＰＣ９は上述のコンピュー
タ５からの入力を待ち（Ｓ５がＮ）、データの入力があ
ると（Ｓ５がＹ）、入力データの内容を確認し（Ｓ
６）、例えば立会人ＰＣ９に供給されたデータが上述の
確認用書類Ｘ１であれば、当該確認用書類Ｘ１を前述の
収納明細テーブル２０に登録する（Ｓ７）（図８に示す
）。そして、確認用書類Ｘ１をそのまま販売企業２側
のコンピュータ６に出力する（Ｓ８）。＜データ確認処理（処理Ｋ）＞図１１は販売企業２のコ
ンピュータ６が行う処理を説明するフローチャートであ
る。上述のように立会人ＰＣ９から送付された確認用書
類Ｘ１の入力を待ち（Ｓ９がＮ）、確認用書類Ｘ１が入
力すると（Ｓ９がＹ）、自己が送った（手渡した）納品
伝票の内容と確認用書類Ｘ１の内容を比較する（Ｓ１
０）。そして内容に誤りがないか確認する。この確認作
業は上述のように販売企業２が行うものである。但し、
販売企業２が商品を納さめている購買企業は、上述の特
定の企業（上述の購買企業１）に限らない。このため、
販売企業２は上述の確認作業の際、コンピュータ６の初
期メニュー（図６）の確認依頼確認のボタン２７ａを押
下し、図１２に示す確認データ一覧画面を表示して行
う。

【００７４】例えば、同図に示す例は確認データ一覧画
面の検索ボタン４０ａを操作し、「（株）Ｂスーパー」
を選択した例である。また、販売企業２はこの証明書を
確認すべく明細ボタン４０ｂを押下し、詳細画面の表示
を行う。尚、終了ボタン４０ｃを押下すると前述の初期
メニューに戻る。

【００７５】ここで、上述の明細ボタン４０ｂを押下
し、詳細画面の表示を行うと、図１３の詳細画面が表示
される。販売企業２はこの画面を見ながら自己の発行し
た納品伝票等の内容と立会人３から送信された認証用書
類Ｘ１の内容を比較する（Ｓ１０）。そして、誤りがな
いか判断する（Ｓ１１）。ここで、両内容が一致してい
れば確認ＯＫボタン４１ａを押下し、確認データを作成
して立会人ＰＣ９に送信する（Ｓ１１がＹ、Ｓ１２、Ｓ
１３）（図８に示す）。

【００７６】一方、前述の納品伝票等と確認用書類Ｘ１
との内容一致判断において両内容が不一致であれば（Ｓ
１１がＮ）、図１３に示す確認ＮＧボタン４１ｂを押下
し、図１４に示す表示を行う。すなわち、この場合には
ＮＧの理由を記述し（Ｓ１４）、図４２のＯＫボタン４
２ａを押下し、ＮＧ応答を立会人ＰＣ９に送る（Ｓ１
５）。

【００７７】立会人ＰＣ９はこのＮＧ応答があると（図
１０のＳ５がＹ）、入力データの内容を判断し（Ｓ
６）、ＮＧ応答であればその応答データをそのまま購買
企業１のコンピュータ５に送り（Ｓ１６）、修正データ
の入力を待つ（Ｓ１７）。購買企業１のコンピュータ５
は前述のように受信データを待っており（Ｓ４）、応答
データが入力した際ＮＧ応答であれば（Ｓ１８（図９参
照）がＹ）、対応する確認用書類Ｘ１のデータ修正を行
う（Ｓ１９）。そして修正したデータは再度立会人ＰＣ
９に送られ（Ｓ２０）、立会人ＰＣ９の収納明細テーブ
ル２０を修正する（Ｓ１７がＹ、Ｓ２１）。すなわち、
販売人２は購買人１の作成した明細に誤りがあることを
知り、購買人１に対し通知し、例えば明細の内容を修正
することにより、例えば収納明細テーブル２０の内容を
更新し正確な明細を作成させることができる（図８に示
す）。

【００７８】以上の処理は、購買企業１と販売企業２間
で納品伝票が送られる度に行われ、図８に示す納品明細
テーブル２０には多数の認証書類が登録される。例え
ば、図８に示すように、「納入者名」がＡ商店、「納入
日」が９８／０２／１１、「納入物品名」としてサン
マ、「納入金額」として￥１０,０００が記載された確
認用書類Ｘ２等も、同様の処理によって納品明細テーブ
ル２０に登録される。

【００７９】尚、上述の処理において、販売企業２の内
容判断において確認用書類Ｘ１の内容と納品伝票の内容
に誤りがなく、確認応答を立会人ＰＣ９に送った場合に
は立会人ＰＣ９は入力データの内容を確認し（図１０の
Ｓ５、Ｓ６）、双方が確認したデータであることを購買
企業１、及び販売企業２に通知する（Ｓ２２）。

【００８０】すなわち、立会人３は販売企業２から確認
完了入力があると、例えば上述の認証用書類Ｘ１、Ｘ
２、等に関する確認済みの確認書Ａ１、Ａ２、等を購買
企業１、及び販売企業２に送信する（図２に示す）。
このようにして、立会人３から送信された情報は、購買
企業１と販売企業２が互いに確認したものであり、納品
伝票等に基づく確認用書類の内容に誤りがないことを証
明するものである。

【００８１】上述のようにして確認処理が完了すると、
収納明細テーブル２０には多数の納品伝票の基づく確認
書類が登録される。この状態において、収納明細テーブ
ル２０に登録した確認登録済みデータを参照する場合、
図６に示す初期メニューの状態から確認済みデータ一覧
のボタン７ｃを押下して、図１５に示す確認済みデータ
一覧画面を表示する。この確認済データ一覧画面は、例
えば取引先を選択することで、前述の「（株）〇〇フー
ズ」、「××ハム（株）」、「（株）□□」、等の取引
のある購買企業１を選択でき、また区分のエリアにある
「仕入」、「相殺」、「発注」、「売掛」、「支払修
正」、「契約」の項目を指定して確認したい項目を選択
する。また、詳細ボタン４５ａを押下することで、図１
６に示す確認済データ明細画面を表示する。

【００８２】例えば、図１６の例は前述の項目として
「発注」を選択した時の詳細画面であり、同図に示すよ
うに、選択した「項目」の詳細情報が表示され、例えば
同図に示す商品の名称、数量“１０（個）”原単価“１
００（円）”、原価金額“１０００（円）”等の具体的
な認証内容を詳細に参照することができる。＜業務処理（処理Ｌ、及びＭ）＞次に、業務処理につい
て説明する。この業務処理（処理Ｌ）には支払い修正、
支払い明細表示、等の各種処理が含まれている。支払い
修正は前述の販売企業２からの指摘により認証用書類の
金額や商品名等の修正処理である。また、支払い確定
は、例えば立会人３が作成した支払明細書を確認して行
う応答処理や、購買企業１自らが作成した支払明細書を
出力する処理である。以下、具体的に説明する。

【００８３】図１７は例えばコンピュータ５のディスプ
レイに表示される支払一覧画面である。尚、この支払一
覧画面は、図６に示す初期メニューの状態から支払一覧
照会のボタン２７ｂを押下することによって表示するこ
とができる。そして、この支払一覧画面は立会人３が作
成したものであり、支払元を選択することにより、前述
の「（株）〇〇フーズ」や「××ハム（株）」、又は
「（株）□□」等の取引のある支払元を選択することが
できる。また、支払先についても同様に指定し、期日を
指定すると当日が支払日の支払一覧が表示される。

【００８４】この明細一覧画面には支払い伝票の納品
日、伝票ＮＯ、店舗名、仕入れ金額、値引き率が表示さ
れている。オペレータは更に知りたい支払い伝票を指定
し、詳細ボタン４４ａを押下すると、図１８の明細画面
に移行することができる。

【００８５】例えば、図１８の例は支払元「（株）〇〇
フーズ」に対する「（株）△△△」への締日１９９７年
８月１２日の支払伝票である。購買企業１、又は販売企
業２のオペレータはこの表示をディスプレイに行うと、
商品名、単位重量、数量、原単価、原価金額等を調べ、
もし疑問があれば前述の収納明細テーブル２０に登録さ
れている個々の明細を確認する。例えば、合計金額に自
己に有する納品伝票で行った合計金額と異なる場合、収
納明細テーブル２０に登録した個々の明細を確認する。

【００８６】この場合、収納明細テーブル２０に登録し
た確認登録済みデータを参照することになる。すなわ
ち、図６に示す初期メニューの状態から確認済データ一
覧のボタン７ｃを押下することにより、前述の図１５に
示す一覧画面を表示する。さらに、確認済データ明細画
面を表示して支払いデータ照合を行うことができる。

【００８７】また、支払明細書の作成は上述のように、
例えば立会人３が行い、この支払明細書作成の際には支
払条件テーブル２１を参照して作成する。尚、この支払
条件テーブル２１は、予め購買企業１と立会人３間、及
び販売企業２と立会人３間で取り決められ、例えば締日
や、支払日、振入口座等が企業毎に登録されている。ま
た、前述の収納明細テーブル２０には明細番号が付さ
れ、購買企業１や販売企業２がデータを参照する際の便
宜のため明細番号をグループ化した明細グループテーブ
ル２２も作成されている。

【００８８】尚、図１９は上述の照合処理を模式的に示
す図である。販売企業２は立会人３に対して詳細情報の
照会を行い（図１９に示す）、収納明細テーブル２０
又は支払条件テーブル２１を参照して必要な明細情報を
得る（図１９に示す）。一方、購買企業１も必要に応
じて立会人３に対して詳細情報の照会を行い（図１９に
示す）、収納明細テーブル２０又は支払条件テーブル
２１を参照して必要な明細情報を得る（図１９に示す
）。

【００８９】次に、立会人３は前述の支払明細書に基づ
き、決済部４（即ち指定銀行）の振入口座を指定して振
り込み依頼を行う（図８に示す）。ここで、この振り
込み処理を上述の照合処理も一部に含めて図２０を用い
て説明する。

【００９０】立会人３の立会人サーバ８には前述のよう
に認証された書類が登録されている。先ず、立会人３は
収納明細テーブル２０に登録されているデータを基づい
て支払明細書を作成し、購買企業１に確認を依頼する
（図２０に示す）。購買企業１では送られてきた支払
明細書を確認し、振り込み依頼としてその支払明細書を
返送する（図２０に示す）。この際、支払明細書には
当該支払明細に対応する納品伝票のインデックスを付与
しておく。

【００９１】上述の振り込み依頼は立会人３に届けら
れ、不図示の銀行へ伝送される（図２０に示す）。立
会人３が銀行に送る振り込み指示としての情報は、金
額、振込元、振込先等の情報と、明細インデックスであ
る。振り込み指示を受けた銀行では銀行システム（例え
ば、前述の全銀為替システム）を用い、販売企業２の取
引銀行の口座に振り込みを行う。また、支払い銀行は販
売企業２に対し支払い通知を行う（図２０に示す）。

【００９２】以上のように処理することにより、購買企
業１及び販売企業２は多くの伝票や、請求書を所有する
ことなく、立会人サーバ９のデータを共有して使用し、
効率よい決算処理を行うことができる。《第２実施形態例》次に、本発明の第２実施形態例につ
いて説明する。本例は購買企業１と販売企業２が入れ替
わった場合、それぞれの支払明細書を前述の第１実施形
態例と同じように作成していたのでは効率が悪いので相
殺処理を行い、支払明細書を作成するものである。

【００９３】したがって、図１〜図３に示すシステム構
成、及び図４に示す画面推移の例は前述の実施形態例と
同じであり、販売企業２側からの納品伝票等に基づく認
証用書類Ｘの作成、販売企業２における確認処理、立会
人３による認証処理等は同様であり、立会人サーバ８の
収納明細テーブル２０には認証された多数枚のデータが
登録され、立会人３は支払条件テーブル２１の支払い日
に合わせて支払明細書を作成する。

【００９４】図２１は本例の相殺の場合の処理の流れを
示す図であり、図２２は相殺処理のフローチャートであ
る。本例では、前述の購買企業１と販売企業２の関係に
よって購買企業１が販売企業２に対して商品代金の支払
い債務を負うと共に、販売企業２も購買企業１から例え
ば異なる商品を購入し、逆に代金支払い債務を負ってい
る場合、それぞれの代金を相殺するものである。この場
合、図２１に示すように、納品明細テーブル２０の納入
者と購入者の欄に購買企業１及び販売企業２が登録され
ている明細を全て抽出する（ステップ（以下、図２２に
おいてＳＴで示す）１）。そして、それぞれの支払い金
額を表示し（ＳＴ２）、例えば購買企業１が購入者であ
って販売企業２が納入者である金額をプラス（＋）し、
販売企業２が購入者であって購買企業１が納入者である
金額をマイナス（−）し、相殺金額を計算する（ＳＴ
３）。

【００９５】上述の計算により、購買企業１と販売企業
２間の相互売買の支払い金額は相殺され、例えば上述の
例の場合、合計金額がプラス（＋）になれば購買企業１
が販売企業２に対して計算結果の合計金額を支払う（Ｓ
Ｔ４がＹ、ＳＴ５）。一方、逆に合計金額がマイナス
（−）になれば販売企業２が購買企業１に対して計算結
果の合計金額を支払う（ＳＴ４がＮ、ＳＴ６）。

【００９６】このようにして得られた金額を支払明細書
として作成し、前述と同様立会人３は前述の支払明細書
に基づき、決済部４（即ち指定銀行）の振入口座を指定
して振り込み依頼を行う（図２１に示す）。以上のよ
うに処理することにより、支払明細書の作成枚数を減ら
すことができ、支払明細書を効率良く作成することがで
きる。

【００９７】尚、購買企業１と販売企業２間の支払い金
額の相殺方法は上述の例に限らず他の方法を用いること
もできる。《第３実施形態例》次に、本発明の第３実施形態例につ
いて説明する。

【００９８】第３実施形態例は、立会人を利用した決済
システムにおいて安全に決済を行うための発明であり、
購買企業１及び販売企業２を予め認証した後認証番号に
従って処理を行う。また、購買企業１と立会人３、及び
販売企業２と立会人３間で送受信するデータは全て暗号
化し、データの安全を期するものである。以下、具体的
に説明する。

【００９９】図２３は、本システムの具体的な構成を示
す図である。同図において、５は前述の実施形態例と同
様購買企業１のコンピュータであり、６は販売企業２の
コンピュータである。また、公証局７及び立会人サーバ
８は前述の立会人３に対応し、立会人ＰＣ９に含まれ
る。また、この立会人ＰＣ９は本システムに参加する企
業を予め認証する認証局２４を含む。また、本例では立
会人ＰＣ９は購買企業１のコンピュータ５から出力され
る納品伝票データ等を公証し、又販売企業２のコンピュ
ータ６から出力される確認応答を受信する。

【０１００】立会人サーバ８は立会人ＰＣ９が公証した
納品伝票等の公証書類を記憶する収納明細テーブル２
０、及び支払条件テーブル２１、明細グループテーブル
２２等を有する。上述のコンピュータ５及び６は立会人
サーバ８を直接アクセスし、上述の公証書類等を参照す
ることができる。

【０１０１】また、図２３に示すように、購買企業１の
コンピュータ５は、企業証明書の取得処理（処理Ａ）、
企業登録処理（処理Ｂ）、及び公証依頼処理（処理
Ｃ）、業務処理（処理Ｄ）を行う。一方、販売企業２の
コンピュータ６は企業証明書の取得処理（処理Ｅ）、企
業登録処理（処理Ｆ）、及び公証データ確認処理（処理
Ｇ）、業務処理（処理Ｈ）を行う。

【０１０２】また、認証局２４は購買企業１及び販売企
業２（コンピュータ５及び６）が行う企業証明書取得処
理（処理Ａ及びＥ）に関して発行される証明書申請に対
する認証を行う。また、公証局７も購買企業１又は販売
企業２（コンピュータ５又は６）が行う企業登録処理
（処理Ｂ及びＦ）に関して発行される証明書発行登録申
請に対する公証を行う。

【０１０３】図２４及び２５は本例の処理をディスプレ
イ上の表示画面に沿って説明する図である。以下、具体
的に説明する。本例においても、各コンピュータ５、
６、立会人ＰＣ９の電源を投入し、立会人システムのプ
ログラムを立ち上げる。

【０１０４】上述の処理によって、コンピュータ５（及
びコンピュータ６）のディスプレイには図２６に示すロ
グイン画面が表示される。このログイン画面は本例の立
会人システムを開始するためのものであり、このログイ
ン画面は、図２４においてスタート画面となる。このロ
グイン画面において、前述の実施形態例と同様、ユーザ
ＩＤとパスワードを入力し、ログインボタンを押下する
ことで、例えばコンピュータ５（コンピュータ６）は上
記ユーザＩＤとパスワードを確認し、一致していればメ
ニュー表示に移行し、メニュー画面を表示する。尚、キ
ャンセルボタンを押下すると、前のＯＳの初期画面に戻
る。

【０１０５】図２７は上述のログインボタンを押下し、
初期メニューをディスプレイに表示した画面である。当
該初期メニューは、４個のボタン（表示）１０ａ〜１０
ｄと、メニューバー１１で構成されている。尚、図２８
はメニューバー１１の詳細を示す図である。先ず、初期
メニューの各ボタン（表示）について説明すると、１０
ａは公証依頼確認を指示する際押下するボタンであり、
１０ｂは支払い一覧照会を指示する際押下するボタンで
あり、１０ｃは公証済みデータ一覧を指示する際押下す
るボタンであり、１０ｄは本例のプログラムを終了する
際押下するボタンである。

【０１０６】また、メニューバー１１は図２８に示すよ
うに、終了バー１１ａ、企業登録１１ｂ（企業証明書取
得バー１１ｂ’、企業登録バー１１ｂ”）、企業情報バ
ー１１ｃ、環境設定バー１１ｄ、バージョン情報バー１
１ｅで構成されている。尚、各バーにそれぞれ付加され
ているアルファベット（Ｘ、Ｅ、Ｉ、Ｓ、Ａ）は、キー
ボードを利用して指定する際に使用するものである。

【０１０７】前述のように、購買企業１のコンピュータ
５が行う処理にはＡ〜Ｄの処理があり、販売企業２のコ
ンピュータ６が行う処理にはＥ〜Ｈの処理があり、以下
具体的に説明する。＜企業証明書取得処理（処理Ａ及びＥ）＞先ず、企業証
明書の取得処理について説明する。

【０１０８】この処理は本システムに加入するための処
理であり、例えば本システムを導入する際最初に行う必
要がある。この処理の指定は、前述の図２８（図２７）
に示すメニュー画面の企業証明書取得バー１１ｂ’を指
定し、図２９に示す企業証明書取得画面を表示する。上
述のように、企業証明書取得処理（処理Ａ）は本例の立
会人システムに参加企業を登録する処理であり、証明書
を取得する企業の企業登録ＩＤ、認証局のＵＲＬ、サー
バ名、証明書のタイプを指定する。

【０１０９】次に、入力した企業登録ＩＤ、認証局のＵ
ＲＬ、サーバ名、等で問題なければ、証明書申請ボタン
１２ａを押下して確認番号表示画面にする。尚、終了ボ
タン１２ｂを押下すると図２７の初期メニューに戻る。

【０１１０】図３０は確認番号表示画面を示す。オペレ
ータは表示される番号を確認した後、次へのボタン１３
ａを押下し、認証局の約款を表示する。尚、この場合も
キャンセルボタン１３ｂを押下すると、前の図２９に示
す企業証明書取得画面に戻る。

【０１１１】図３１は約款表示画面であり、証明局の約
款を表示する。例えば、本システムに加入する際の規
定、確認事項等が記載されている。オペレータはこの約
款を読み、同意できるのであれば承諾のボタン１４ａを
押下し、同意できなければキャンセルのボタン１４ｂを
押下する。承諾ボタン１４ａを押下した場合、次の証明
書取得画面に移行する。

【０１１２】図３２は証明書取得画面であり、企業名、
所在地、その他当該企業に関する情報を対応するエリア
に記載し、申請依頼を行う。この申請依頼は、上記各記
載が間違っていないことを確認した後、申請依頼ボタン
１５ａを押下することにより依頼する。この依頼によ
り、認証局２４は上述の企業を登録する。＜企業登録処理（処理Ｂ及びＦ）＞上述のようにして企
業証明書取得処理が終了した後、次に企業登録処理を行
う。

【０１１３】図３３は企業登録画面であり、前述の初期
メニューの状態から企業登録バー１１ｂ”を押下するこ
とにより表示することができる。この企業登録処理は参
加企業を公証局７に登録する処理であり、公証局７のＵ
ＲＬ、サーバ名、、立会人ＩＤを指定する（尚、上述の
サーバ名、及び立会人ＩＤを省略してもよい）。また、
企業の企業登録ＩＤを指定する。

【０１１４】次に、指定した企業登録ＩＤ、公証局７の
ＵＲＬ、サーバ名、等に問題なければ、登録ボタン１６
ａを押下して公証局７の約款画面とする。尚、終了ボタ
ン１６ｂを押下すると前述の初期メニュー画面に戻る。

【０１１５】図３４は公証局約款画面である。前述の証
明局の約款画面と同様、例えば本システムに加入する際
の規定事項、確認事項等が記載されている。オペレータ
はこの約款を読み、同意できるのであれば承諾のボタン
１７ａを押下し、同意できなければキャンセルのボタン
１７ｂを押下する。承諾ボタン１７ａを押下した場合、
次の企業登録依頼画面に移行する。

【０１１６】図３５は企業登録依頼画面であり、所在
地、企業名、その他当該企業に関する情報を対応するエ
リアに記載し、申請依頼を行う。この申請依頼は、上記
各記載が間違っていないことを確認した後、申請依頼ボ
タン１８ａを押下することにより依頼する（尚、この依
頼処理を中止する時には、キャンセルのボタン１８ｂを
押下する）。

【０１１７】上述の依頼により、公証局７は立会人サー
バ９に上述の企業を登録する。この時、立会人サーバ９
にはグループ別に上記企業の情報が登録される。＜企業一覧表示＞以上のようにして各企業が公証局７及
び認証局８に登録処理を行うと、立会人サーバ９には多
数の企業の登録データが登録される。そこで、本システ
ムではユーザの指定により登録企業を一覧表示すること
ができる。

【０１１８】この企業一覧表示は、初期メニューの状態
から企業情報バー１１ｃを押下することにより表示する
ことができる。図３６は登録企業の一覧表示画面を示す
ものであり、登録されている企業ＩＤ、企業名、登録日
時が表示される。本例ではエリア１に企業名「（株）〇
〇フーズ」が登録され、エリア２に企業名「××ハム
（株）」が登録され、エリア３に企業名「（株）□□」
が登録されている。ユーザは上述の画面表示を行った
後、詳細に確認したい企業が存在する場合、企業名を指
定して詳細ボタン１９ａを押下する。

【０１１９】図３７は上述の詳細ボタン１９ａの押下に
よって表示される企業詳細情報画面である。この表示は
企業ＩＤ、企業名、所在地、署名用証明書情報、暗号用
証明書情報で構成される。例えば、上述の図２８に示す
エリア３に登録された企業名「（株）□□」が選択され
た時、企業ＩＤのエリアには「（株）□□」のＩＤが登
録され、所在地のエリアには「（株）□□」の会社所在
地である「北海道×××市ＹＹＹ９−９９９」が登録さ
れる。また、署名用証明書情報のエリアには企業
「（株）□□」の公証局への登録情報が表示され、例え
ば発行日が１９９７年１１月９日に証明書番号２０とし
て、１９９８年５月１０日迄有効な企業登録が行われて
いることが分かる。

【０１２０】以上のようにして、本システムへの参加企
業（購買企業１、販売企業２等）の認証処理が終了する
と、次に暗号を用いた処理を行う。＜公証依頼処理（処理Ｃ）＞この処理は購買企業１が行
う処理であり、販売人側記録としての納品伝票、発注伝
票、又は請求書に基づいて購買企業１が行う処理であ
る。すなわち、購買企業１は販売企業２から送られた上
述の伝票に基づいて公証用書類を作成し、立会人３に公
証を求めるものである。

【０１２１】この処理を具体的に説明する図が図３８で
ある。同図は購買企業１及び販売企業２が受けた上述の
証明書を添付して行う認証処理の模式図である。購買企
業１は認証用書類に購買企業１の証明書である「Ａ」を
付加して立会人３に書類を送る（図３８に示すの処
理）。立会人３は送られた認証用書類をそのまま確認用
として販売企業２に送る（図３８に示すの処理）。販
売企業２は送られた書類を確認し、例えば納品伝票の内
容と一致しているか確認した後、内容に間違いがなけれ
ば販売企業２の証明書「Ｂ」を付加して立会人３に送る
（図３８に示す処理）。立会人３は前述の収納明細テ
ーブル２０に認証用書類のデータを登録すると共に、認
証用書類を認証したことを示す通知を購買企業１及び販
売企業２に送る（図３８に示すの処理）。この時、立
会人３の証明書「Ｃ」を付加して行う。このように各書
類の送付に証明書を付加することで、公証局７（立会人
３）は本システムに参加資格のある企業の書類であるこ
とを常に確認することができ、安全な手続きを行うこと
ができる。

【０１２２】以下、図３９を用いて具体的に説明する。
先ず、Ａ商店は購買企業１であるＢスーパーに食料品を
納入し、その際に納品伝票をＢスーパーに送る（手渡
す）。購買企業１（Ｂスーパー）は公証用書類Ｙとして
上述の納品伝票のデータを作成する。この公証用書類Ｙ
には「納入者（販売企業２）名」、「納入日」、「納入
物品名」、「納入金額」、等が含まれ、例えば「納入者
名」として上述のＡ商店、「納入日」として９８／０２
／１０、「納入物品名」としてマグロ、「納入金額」と
して￥１５,０００が記載されている。この公証用書類
Ｙは購買企業１から立会人３に送信される（図３９に示
す）。ここで、購買企業１から販売企業２に送付する
公証用書類Ｙは暗号化されて送られる。

【０１２３】図４０はその例である。同図において、Pa
rticipantＵとＶはある企業Ｕから企業Ｖへ公証用書類
Ｙを送る場合の一般例であり、上述の例に対応させる
と、同図に示すａの部分が購買企業１から販売企業２に
送付する公証用書類Ｙ１のメッセージ（Message）に対
応する。すなわち、同図に示すＤＡＴＡは上述の「納入
者（販売企業２）名」、「納入日」等のデータであり、
このデータをＤＥＳによって暗号化し、ハッシュ関数
（ＳＨＡ）を適用し、更に購買企業１の秘密キー（ＳＫ
Ａ）によって施鍵し、公証局７に送る。尚、前もって販
売企業２用に、上記秘密キー（ＳＫＡ）に対する公開キ
ー（ＰＫＡ）も送付しておく。購買企業１の秘密キー
（ＳＫＡ）で施鍵するのは、そのメッセージが購買企業
１から送付されてきたことを販売企業２で確認するため
である。

【０１２４】尚、企業Ｕから企業Ｖに送られる送信デー
タの全体は、上述したメッセージと同じものにハッシュ
関数（ＳＨＡ）を適用したものを企業Ｕの秘密キー（Ｓ
ＫＵ）で施鍵し、これを更に上述したメッセージとをＤ
ＥＫで施鍵したものに、ＤＥＳに対応したＤＥＫを企業
Ｖの公開キー（ＰＫＶ）で施鍵したものである。企業Ｖ
の公開キー（ＰＫＶ）で施鍵するのは、その送信データ
全体が企業Ｖのみで解読できるようにするためである。
具体的には、上記送信データの全体は、購買企業１から
販売企業２に対して送付される。＜公証データ確認処理（処理Ｇ）＞次に、立会人３は納
品伝票を送った販売企業２に対し上記公証用書類Ｙをそ
のまま販売企業２に送り、確認依頼を行う（図３９に示
す）。販売企業２は自己が発行した納品伝票等の内容
と立会人３から送信された公証用書類Ｙの内容とを比較
し、誤りがないか確認する。尚、上述のデータ（ＤＡＴ
Ａ）の解鍵は上述の公開キー（ＰＫＡ）により行う。

【０１２５】尚、送信データ全体を受信した販売企業２
は、先ず公開キー（ＰＫＶ）に対応する秘密キー（ＳＫ
Ｖ）で解鍵してＤＥＫを得て、ＤＥＫでＤＥＳを解鍵
し、次に上述したように、購買企業１の公開キー（ＰＫ
Ａ）を用いる。

【０１２６】上述のように確認作業は販売企業２が行う
ものである。但し、販売企業２が商品を納さめている購
買企業は、上述の特定の企業（上述の購買企業１）に限
らない。このため、販売企業２は上述の確認作業の際、
コンピュータ６の初期メニュー（図２７）の公証依頼確
認のボタン１０ａを押下し、図４１に示す公証データ一
覧画面を表示して行う。

【０１２７】例えば、同図に示す例は公証データ一覧画
面の検索ボタン２０ａを操作し、「（株）Ｂスーパー」
を選択した例である。また、販売企業２はこの証明書を
確認すべく明細ボタン２０ｂを押下し、詳細画面の表示
を行う。

【０１２８】ここで、上述の明細ボタン２０ｂを押下
し、詳細画面の表示を行うと、図４２の詳細画面が表示
される。販売企業２はこの画面を見ながら自己の発行し
た納品伝票等の内容と立会人３から送信された公証用書
類Ｙ１の内容を比較し、誤りがないか確認する。そし
て、両内容が一致していれば確認ＯＫボタン２１ａを押
下し、完了を立会人３に送信する（図３９に示す）。

【０１２９】このとき販売企業２が立会人３に送付する
確認応答は、上述の図４０に示すｂの部分である。すな
わち、前述の公証用書類Ｙ１の暗号データにハッシュ関
数（ＳＨＡ）と販売企業２の秘密キー（ＳＫＢ）によっ
て施鍵し、公証局７に送る。尚、この時、同時に公証局
７に対し上記秘密キー（ＳＫＢ）に対する公開キー（Ｐ
ＫＢ）も送付する。

【０１３０】尚、前述の納品伝票等と公証用書類Ｙ１と
の内容一致判断において両内容が不一致であれば、図４
２に示す確認ＮＧボタン２１ｂを押下し、図４３に示す
表示を行う。すなわち、この場合にはＮＧの理由を記述
し、ＯＫボタン２２ａを押下する。この場合、立会人は
明細を公証することがなく、この時点で販売人２は購買
人１の作成した明細に誤りがあることを知り、購買人１
に対し通知し、例えば明細の内容を修正することによ
り、例えば収納明細テーブル２０の内容を更新し正確な
公証明細を作成させることができる（図３９に示す
）。

【０１３１】次に、立会人３は販売企業２から確認応答
入力があると、上述の公証用書類Ｙ１に関する認証済み
の証明書を購買企業１、及び販売企業２に送信する（図
２に示す）。

【０１３２】このとき販売企業２が立会人３に送付する
証明書は、上述の図４０に示すｃの部分である。すなわ
ち、前述の公証用書類Ｙ１の暗号データと販売企業２か
らの確認応答を更にハッシュ関数（ＳＨＡ）と立会人３
の秘密キー（ＳＫＮ）によって施鍵したメッセージであ
る。また、この時購買企業１及び販売企業２に対し上記
秘密キー（ＳＫＮ）に対する公開キー（ＰＫＮ）も送付
する。

【０１３３】このようにして、立会人３から送信された
暗号化情報は、購買企業１と販売企業２が互いに確認し
た証明書であり、納品伝票等に基づく認証用書類の内容
に誤りがないことを証明する公証書類である。

【０１３４】上述のようにして公証処理が完了すると、
収納明細テーブル２０には多数の証明書が登録される。
この状態において、収納明細テーブル２０に登録した公
証登録済みデータを参照する場合、図２７に示す初期メ
ニューの状態から公証済みデータ一覧を参照するボタン
１０ｃを押下し、図４４に示す公証済みデータ一覧画面
を表示する。この公証済データ一覧画面は、例えば取引
先を選択することで、前述の「（株）〇〇フーズ」、
「××ハム（株）」、「（株）□□」、等の取引のある
購買企業１を選択でき、また区分のエリアにある「仕
入」、「相殺」、「発注」、「売掛」、「支払修正」、
「契約」の項目を指定して確認したい項目を選択する。
また、詳細ボタン２５ａを押下することで、図４５に示
す公証済データ明細画面を表示する。

【０１３５】例えば、図４５の例は前述の項目として
「発注」を選択した時の詳細画面であり、同図に示すよ
うに、選択した「項目」の詳細情報が表示され、例えば
同図に示す商品の名称、数量“１０（個）”原単価“１
００（円）”、原価金額“１０００（円）”等の具体的
な認証内容を詳細に参照することができる。＜業務処理（処理Ｄ、及びＨ）＞次に、業務処理につい
て説明する。この業務処理（処理Ｄ）には支払い修正、
支払い明細表示、等の各種処理が含まれている。支払い
修正は前述の販売企業２からの指摘により認証用書類の
金額や商品名等の修正処理である。また、支払い確定
は、例えば立会人３が作成した支払明細書を確認して行
う応答処理や、購買企業１自らが作成した支払明細書を
出力する処理である。以下、具体的に説明する。

【０１３６】図４６は例えばコンピュータ５のディスプ
レイに表示される支払一覧画面である。尚、この支払一
覧画面は、図２９に示す初期メニューの状態から支払一
覧照会のボタン１０ｂを押下することによって表示する
ことができる。そして、この支払一覧画面は立会人３が
作成したものであり、支払元を選択することにより、前
述の「（株）〇〇フーズ」や「××ハム（株）」、又は
「（株）□□」等の取引のある支払元を選択することが
できる。また、支払先についても同様に指定し、期日を
指定すると当日が支払日の支払一覧が表示される。

【０１３７】この明細一覧画面には支払い伝票の納品
日、伝票ＮＯ、店舗名、仕入れ金額、値引き率が表示さ
れている。オペレータは更に知りたい支払い伝票を指定
し、詳細ボタン２４ａを押下すると、図４７の明細画面
に移行することができる。

【０１３８】例えば、図４７の例は支払元「（株）〇〇
フーズ」に対する「（株）△△△」への締日１９９７年
８月１２日の支払伝票である。購買企業１、又は販売企
業２のオペレータはこの表示をディスプレイに行うと、
商品名、単位重量、数量、原単価、原価金額等を調べ、
もし疑問があれば前述の収納明細テーブル２０に登録さ
れている個々の明細を確認する。例えば、合計金額に自
己に有する納品伝票で行った合計金額と異なる場合、収
納明細テーブル２０に登録した個々の明細を確認する。

【０１３９】この場合、収納明細テーブル２０に登録し
た公証登録済みデータを参照することになる。すなわ
ち、図２７に示す初期メニューの状態から公証済データ
一覧のボタン１０ｃを押下することにより、前述の図４
４に示す一覧画面を表示する。さらに、公証済データ明
細画面を表示して支払いデータ照合を行うことができ
る。

【０１４０】また、支払明細書の作成は上述のように、
例えば立会人３が行い、この支払明細書作成の際には支
払条件テーブル２１を参照して作成する。尚、この支払
条件テーブル２１は、予め購買企業１と立会人３間、及
び販売企業２と立会人３間で取り決められ、例えば締日
や、支払日、振入口座等が企業毎に登録されている。ま
た、前述の収納明細テーブル２０には明細番号が付さ
れ、購買企業１や販売企業２がデータを参照する際の便
宜のため明細番号をグループ化した明細グループテーブ
ル２２も作成されている。

【０１４１】次に、立会人３は前述の支払明細書に基づ
き、決済部４（即ち指定銀行）の振入口座を指定して振
り込み依頼を行う（図３９に示す）。図４８はこの振
り込み処理を説明する図である。

【０１４２】立会人３は収納明細テーブル２０に登録さ
れているデータを基づいて支払明細書を作成し、購買企
業１に確認を依頼する（図４８に示す）。購買企業１
では送られてきた支払明細書を確認し、振り込み依頼と
してその支払明細書を返送する（図４８に示す）。こ
の際、支払明細書には当該支払明細に対応する納品伝票
のインデックスを付与しておく。

【０１４３】上述の振り込み依頼は公証局７を経由して
立会人３に届けられ、不図示の銀行へ伝送される（図４
８に示す）。立会人３が銀行に送る振り込み指示とし
ての情報は、金額、振込元、振込先等の情報と、明細イ
ンデックスである。振り込み指示を受けた銀行では銀行
システム（例えば、前述の全銀為替システム）を用い、
販売企業２の取引銀行の口座に振り込みを行う。また、
支払い銀行は販売企業２に対し支払い通知を行う（図４
８に示す）。

【０１４４】以上のように処理することにより、購買企
業１及び販売企業２は多くの伝票や、請求書を所有する
ことなく、立会人サーバ９のデータを共有して使用し、
効率よい決算処理を行うことができる。

【０１４５】また、上述の処理において購買企業１、販
売企業２、公証局７、立会人間で送受信されるデータは
暗号化され、それぞれ送信目的に応じて作成される。例
えば、図４９に示すデータは購買企業１（Ａ）が、販売
企業２（Ｂ）及び立会人３（Ｗ）に内容を開示する目的
で作成されたデータであり、この場合予め購買企業１が
保持する販売企業２の公開鍵（ＰＫＢ）、及び立会人３
の公開鍵（ＰＫＷ）によって閉鍵したデータを、更にハ
ッシュ関数と購買企業１の秘密鍵（ＳＨＡ）で閉鍵し、
公開鍵（ＰＫＮ）を添付して送る。このように構成する
ことにより、上述のデータは販売企業２の秘密鍵、及び
立会人３の秘密鍵がなければ解放することができず、販
売企業２と立会人３以外知ることができない情報とな
る。

【０１４６】尚、上述の実施形態例では相殺について述
べていないが、同様に実施することができる。《第４実施形態例》先ず、第４実施形態例について説明
する。

【０１４７】本例は特に小切手の場合と、手形の場合の
決済システムを説明するものであり、前述の第１実施形
態例によるシステム、及び第２実施形態例によるシステ
ムの双方で実現できるものである。以下、それぞれにつ
いて説明する。＜小切手の場合の処理＞次に、小切手の場合の例を説明
する。

【０１４８】図５０は小切手の場合の決済例を説明する
図である。同図において、管理センター５０は公証局５
１と立会人５２で構成され、前述の立会人システムを採
用したセンターであり、更に銀行で発行する小切手の管
理も行う。また、銀行Ｘは支払人としての購買企業１の
取引銀行であり、銀行Ｙは受取人としての販売企業２の
取引銀行である。

【０１４９】先ず、購買企業（支払人）１は小切手の発
行を行う。この場合、商品の代金として小切手を発行し
たい購買企業（支払人）１は、小切手を入手するため取
引銀行Ｘに対し小切手の発行を依頼する（図５０に示す
）。銀行Ｘでは申し込み人の資格審査を行い、小切手
の発行を決定すると管理センター５０に購買企業１に対
する小切手の発行を登録する（図５０に示す）と共
に、購買企業１に対し発行許可を行う（図５０に示す
）。

【０１５０】小切手を入手した購買企業１はこの小切手
を使用し、商品代金支払いの都度、受取人及び金額等を
記入した小切手を販売企業（受取人）に渡す（図５０に
示す）。一方、販売企業２は受け取った小切手を前述
の銀行Ｘに持ち込み取り立て依頼を行う（図５０に示す
）。

【０１５１】銀行Ｘでは持ち込まれた小切手を前述の管
理センター５０に問い合わせを行い、正当なものである
ことを確認すると共に、支払い通知により当該小切手が
支払い済みである登録を行う（図５０に示す）。その
後、銀行Ｘは指定された例えば銀行Ｙの口座に前述の全
銀システムを利用して資金移動を行い、銀行Ｙは販売企
業２に対し取り立て通知を行う（図５０に示す）。

【０１５２】本例では、前述のように管理センターは公
証局と立会人で構成されており、上述のネットワーク上
で小切手を管理し、販売企業２側は銀行Ｙに資金移動を
依頼するものである。＜手形の場合の処理＞次に、手形の場合の例を説明す
る。

【０１５３】図５１は手形の場合の決済例を説明する図
である。同図において、管理センター５３は小切手の場
合と同様、公証局５４と立会人５５で構成され、前述の
立会人システムを採用したセンターであり、更に銀行で
発行する小切手の管理も行う。また、銀行Ｘは支払人と
しての購買企業１の取引銀行であり、銀行Ｙは受取人と
しての販売企業２の取引銀行である。

【０１５４】先ず、購買企業（支払人）１は取引銀行で
あるＸに対し手形の発行許可を受ける（図５１に示す
の処理）。次に、手形の発行を行いたい時に管理センタ
ー５５に対し発行登録を行う（図５１に示す）。管理
センター５５はこれを記録し、購買企業１に対し登録番
号を通知する（図５１に示す）。

【０１５５】その後、購買企業１は受け取った登録番号
と期日、振出人、受取人などの情報を付加し、販売企業
（受取人）２に送る（図５１に示す）。販売企業２は
この手形を自己の取引銀行であるＹに持ち込み、例えば
手形割引を依頼する（図５１に示す）。

【０１５６】銀行Ｙでは管理センター５３に当該手形の
情報を確認し、更に自らが新しい受取人になることを管
理センター５３に登録する（図５１に示す）。また、
銀行Ｙは割引かれた金額を販売企業２に支払う（図５１
に示す）。

【０１５７】そして最後に、期日が到来し換金する際、
振出銀行に対し取り立て請求を行い（図５１に示す
）、取り立て請求を受けた銀行Ｘは、銀行Ｙの口座に
前述の全銀システムを利用して資金移動を行い、銀行Ｙ
は管理センター５３に対し完了通知を行う（図５１に示
す）。

【０１５８】本例の処理についても、管理センター５３
は公証局５４と立会人５５で構成され、上述のネットワ
ーク上で手形の流れを管理し、本例の立会人システムを
利用することができる。

【０１５９】

【発明の効果】以上説明したように、本発明によれば以
下のような効果が発生する。一の発明によれば、立会人
が発注伝票や納品伝票のデータを記憶、管理するので正
確な支払明細書を作成することができる。

【０１６０】また、作成された支払明細書を購買人及び
販売人が自由に照合できるので、購買人や販売人は別に
発注伝票や納品伝票を持つ必要がなく、伝票の整理等の
煩雑な作業を行う必要がない。

【０１６１】また、従来のように購買人が発注伝票や納
品伝票を確認しながら支払明細を作成し、当該支払明細
を販売人が確認するという煩雑な作業を行う必要がなく
なる。さらに、本発明のシステムに参加する際参加資
格を認証し、暗号化したデータで情報の授受を行うので
システムの安全性が確保できる。

【図面の簡単な説明】

【図１】本システムの具体的な構成を示す図である。

【図２】第１実施形態例の立会人システムの基本構成を
説明する図である。

【図３】記憶媒体に本例のプログラムを記憶する構成を
示す図である。

【図４】処理Ｊ、Ｋをコンピュータが実行する際、又は
処理Ｌ、Ｍをコンピュータが実行する際の手順を示す図
である。

【図５】ログイン画面を説明する図である。

【図６】初期メニューをディスプレイに表示した画面で
ある。

【図７】メニューバーの詳細を示す図である。

【図８】第１実施形態例を具体的に説明する図である。

【図９】コンピュータ５の行う処理を説明するフローチ
ャートである。

【図１０】立会人ＰＣが行う処理を説明するフローチャ
ートである。

【図１１】コンピュータ６の行う処理を説明するフロー
チャートである。

【図１２】確認データ一覧画面を表示する図である。

【図１３】データ確認画面を表示する図である。

【図１４】データ確認画面を表示する図である。

【図１５】確認済みデータ一覧画面を表示する図であ
る。

【図１６】確認済みデータ明細画面を表示する図であ
る。

【図１７】ディスプレイに表示される支払一覧画面を示
す図である。

【図１８】ディスプレイに表示される支払表示画面を示
す図である。

【図１９】照合処理を模式的に示す図である。

【図２０】振り込みの場合の決済システムを説明する図
である。

【図２１】相殺の場合の処理の流れを示す図である。

【図２２】相殺処理を説明するフローチャートである。

【図２３】第３実施形態例の立会人システムの基本構成
を説明する図である。

【図２４】第３実施形態例の処理をディスプレイ上の表
示画面に沿って説明する図である。

【図２５】第３実施形態例の処理をディスプレイ上の表
示画面に沿って説明する図である。

【図２６】ログイン画面を説明する図である。

【図２７】初期メニューをディスプレイに表示した画面
である。

【図２８】メニューバーの詳細を示す図である。

【図２９】企業証明書取得画面を表示する図である。

【図３０】確認番号表示画面を表示する図である。

【図３１】約款表示画面であり、認証局の約款を表示す
る。

【図３２】証明書取得画面である。

【図３３】企業登録画面である。

【図３４】公証局約款画面である。

【図３５】企業登録依頼画面である。

【図３６】企業一覧画面である。

【図３７】企業詳細情報画面である。

【図３８】証明書を利用した立会人システムを説明する
図である。

【図３９】第３実施形態例を具体的に説明する図であ
る。

【図４０】暗号化データのデータフォーマットを説明す
る図である。

【図４１】公証データ一覧画面を表示する図である。

【図４２】公証データ確認画面を表示する図である。

【図４３】公証データ確認画面を表示する図である。

【図４４】公証済みデータ一覧画面を表示する図であ
る。

【図４５】公証済みデータ明細画面を表示する図であ
る。

【図４６】ディスプレイに表示される支払一覧画面を示
す図である。

【図４７】ディスプレイに表示される支払表示画面を示
す図である。

【図４８】振り込みの場合の決済システムを説明する図
である。

【図４９】他の暗号化データの例を示す図である。

【図５０】小切手の場合の処理を説明する図である。

【図５１】手形の場合の処理を説明する図である。

【図５２】従来例を説明する図である。

【符号の説明】

１購買人２販売企業３立会人４決済部５、６コンピュータ５ａ、６ａデータベース５ｂ、６ｂライブラリデータベース５ｃ、６ｃインターフェイス７公証局８立会人サーバ９立会人ＰＣ１０ａ公証依頼確認用ボタン１０ｂ支払一覧照会用ボタン１０ｃ公証済みデータ一覧用ボタン１０ｄシステム終了ボタン１１メニューバー１１ａ終了バー１１ｂ企業登録バー１１ｂ’ 企業証明書取得バー１１ｂ” 企業登録バー１１ｃ企業情報バー１１ｄ環境設定バー１１ｅバージョン情報バー１２ａ明細書申請ボタン１２ｂ終了ボタン１３ａ次へボタン１３ｂキャンセルボタン１４ａ承諾ボタン１４ｂキャンセルボタン１５ａ申請依頼ボタン１５ｂキャンセルボタン１６ａ登録ボタン１６ｂ終了ボタン１７ａ承諾ボタン１７ｂキャンセルボタン１８ａ登録依頼ボタン１８ｂキャンセルボタン１９ａ詳細情報ボタン２０収納明細テーブル２０ａ検索ボタン２０ｂ明細ボタン２０ｃ終了ボタン２１支払条件テーブル２１ａ確認ＯＫボタン２１ｂ確認ＮＧボタン２２明細グループテーブル２２ａＯＫボタン２４ａ、２５ａ詳細ボタン５０、５３管理センター５１、５４公証局５２、５５立会人

Claims

【特許請求の範囲】

【請求項１】販売人から送られた販売人側記録に基づ
いて、前記販売人側記録毎に確認用書類を作成する確認
用書類作成手段と、該確認用書類作成手段によって作成された書類を立会人
に送付し、該書類を前記立会人から更に前記販売人に送
付する送付手段と、前記販売人が、前記送付手段によって送付された前記書
類の内容と、前記販売人側記録の内容が一致しているか
確認する確認手段と、該確認手段によって前記一致が確認されたとき、前記書
類が正確であることを確認する立会人と、該立会人によって確認された書類を記憶する記憶手段
と、を有することを特徴とする立会人システム。
【請求項２】前記確認用書類の作成は購買人が行うこ
とを特徴とする請求項１記載の立会人システム。
【請求項３】前記立会人が確認用書類を確認すると
き、該確認を購買人と販売人に通知することを特徴とす
る請求項１、又は２記載の立会人システム。
【請求項４】前記確認用書類が前記販売人から前記立
会人に送付されたとき、該書類を登録し、該書類の登録
の事実を確認することを特徴とする請求項１記載の立会
人システム。
【請求項５】前記確認手段による前記一致の確認にお
いて、前記両内容が不一致のとき、前記立会人に対し内
容不一致の通知を行うことを特徴とする請求項１、又は
２記載の立会人システム。
【請求項６】前記記憶手段による前記書類の記憶は、
販売人毎及び購買人毎に行うことを特徴とする請求項
１、又は２記載の立会人システム。
【請求項７】販売人から送られた販売人側記録に基づ
いて、前記販売人側記録毎に公証用書類を作成する公証
用書類作成手段と、該公証用書類作成手段によって作成した書類を公証局に
送付し、該書類を前記公証局から更に前記販売人に送付
する送付手段と、前記販売人が、前記送付手段によって送付された前記書
類の内容と、前記販売人側記録の内容が一致しているか
確認する確認手段と、該確認手段によって前記一致が確認されたとき、前記書
類が正確であることを公証する公証局を含む立会人と、該立会人によって公証された書類を記憶する記憶手段
と、該記憶手段に記憶した前記公証用書類を参照して、前記
販売人に対して前記購買人が支払う支払明細書を作成す
る支払明細書作成手段と、該支払明細書作成手段により作成した支払明細書に基づ
き、振り込み依頼を行う振込依頼手段と、該振込依頼手段による振り込み依頼に基づいて前記販売
人に振り込みが行われたとき、当該振り込みの事実を前
記立会人に通知する通知手段と、を有することを特徴とする立会人システムを利用した決
済方式。
【請求項８】前記支払明細書の作成は、支払条件に従
って作成することを特徴とする請求項７記載の立会人シ
ステムを利用した決済方式。
【請求項９】前記支払条件は前記立会人によって管理
されていることを特徴とする請求項８記載の立会人シス
テムを利用した決済方式。
【請求項１０】前記販売人は、前記記憶手段に記憶し
た書類を参照して前記支払明細書の照合を行うことを特
徴とする請求項７記載の立会人システムを利用した決済
方式。
【請求項１１】前記支払明細書の作成は、前記購買人
が行うことを特徴とする請求項７記載の立会人システム
を利用した決済方式。
【請求項１２】前記支払明細書の作成は、前記立会人
が行うことを特徴とする請求項７記載の立会人システム
を利用した決済方式。
【請求項１３】前記購買人は、前記記憶手段に記憶し
た書類に従って前記支払明細書の照合を行うことを特徴
とする請求項１２記載の立会人システムを利用した決済
方式。
【請求項１４】前記立会人が公証用書類を公証すると
き、該公証を購買人と販売人に通知することを特徴とす
る請求項７記載の立会人システムを利用した決済方式。
【請求項１５】販売人から送られた販売人側記録に基
づいて、前記販売人側記録毎に公証用書類を作成する公
証用書類作成手段と、該公証用書類作成手段によって作成した書類を公証局に
送付し、該書類を前記公証局から更に前記販売人に送付
する送付手段と、前記販売人が、前記送付手段によって送付された前記書
類の内容と、前記販売人側記録の内容が一致しているか
確認する確認手段と、該確認手段によって前記一致が確認されたとき、前記書
類が正確であることを公証する立会人と、該立会人によって公証された書類を記憶する記憶手段
と、前記購買人は前記記憶手段に記憶した前記書類を参照し
て、前記購買人が前記販売人に支払う支払明細書を作成
する支払明細書作成手段と、該支払明細書作成手段により作成した支払明細書に基づ
き、前記購買人に対す小切手の振り出しを金融機関に請
求する請求手段と、を有することを特徴とする立会人システムを利用した決
済方式。
【請求項１６】前記金融機関は、前記小切手の発行請
求に基づき小切手を発行したとき、前記立会人に通知す
ることを特徴とする請求項１５記載の立会人システムを
利用した決済方式。
【請求項１７】販売人から送られた販売人側記録に基
づいて、前記販売人側記録毎に公証用書類を作成する公
証用書類作成手段と、該公証用書類作成手段によって作成した書類を公証局に
送付し、該書類を前記公証局から更に前記販売人に送付
する送付手段と、前記販売人が、前記送付手段によって送付された前記書
類の内容と、前記販売人側記録の内容が一致しているか
確認する確認手段と、該確認手段によって前記一致が確認されたとき、前記書
類が正確であることを認証する立会人と、該立会人によって公証された書類を記憶する記憶手段
と、前記記憶手段に記憶した前記書類を参照して、前記購買
人が前記販売人に支払う支払明細書を作成する支払明細
書作成手段と、該支払明細書作成手段により作成した支払明細書に基づ
き、前記購買人に対す手形の振り出しを金融機関に請求
する請求手段と、を有することを特徴とする立会人システムを利用した決
済方式。
【請求項１８】前記金融機関は、前記手形の振出請求
に基づき手形を発行したとき、前記立会人に通知するこ
とを特徴とする請求項１７記載の立会人システムを利用
した決済方式。
【請求項１９】前記支払明細書を作成する際、前記購
買人が前記販売人に対し売掛金を有している場合、相殺
処理を行うことを特徴とする請求項７、１５、又は１７
記載の立会人システムを利用した決済方式。
【請求項２０】前記立会人はシステムを利用する購買
人、及び販売人を予め認証し、手続きを行う際には認証
証明書を用いて行うことを特徴とする請求項１、又は２
記載の立会人システム。
【請求項２１】前記立会人はシステムを利用する購買
人、及び販売人を予め認証し、手続きを行う際には認証
証明書を用いて行うことを特徴とする請求項７、１５、
又は１７記載の立会人システムを利用した決済方式。
【請求項２２】前記立会人、購買人、及び販売人間で
行う送受信データを暗号化することを特徴とする請求項
１、又は２記載の立会人システム。
【請求項２３】前記立会人、購買人、及び販売人間で
行う送受信データを暗号化することを特徴とする請求項
７、１５、又は１７記載の立会人システムを利用した決
済方式。
【請求項２４】前記送受信データを前記立会人が公証
することを特徴とする請求項２２記載の立会人システ
ム。
【請求項２５】販売人から送られた販売人側記録に基
づいて、前記販売人側記録毎に確認用書類を作成する確
認用書類作成処理と、該確認用書類作成手段によって作成した書類を立会人に
送付し、該書類を前記立会人から更に前記販売人に送付
する送付処理と、前記販売人が、前記送付手段によって送付された前記書
類の内容と、前記販売人側記録の内容が一致しているか
確認する確認処理と、該確認処理によって前記一致を確認するとき、立会人は
前記書類が正確であることを確認し、該確認を前記購買
人と前記販売人に通知する通知処理と、前記確認された書類を記憶する記憶処理と、を行うことを特徴とする立会人システムによる書類の確
認方法。
【請求項２６】販売人から送られた販売人側記録に基
づいて、前記販売人側記録毎に公証用書類を作成する公
証用書類作成処理と、該公証用書類作成手段によって作成した書類を公証局に
送付し、該書類を前記公証局から更に前記販売人に送付
する送付処理と、前記販売人が、前記送付手段によって送付された前記書
類の内容と、前記販売人側記録の内容が一致しているか
確認する確認処理と、該確認処理によって前記一致を確認するとき、立会人は
前記書類が正確であることを公証し、該公証を前記購買
人と前記販売人に通知する通知処理と、前記公証された書類を記憶する記憶処理と、該記憶処理によって記憶した前記公証用書類を参照し
て、前記購買人が前記販売人に支払う支払明細書を作成
する支払明細書作成処理と、該支払明細書作成処理により作成した支払明細書に基づ
き、前記販売人に対する振り込み依頼を行う振込依頼処
理と、を行うことを特徴とする立会人システムを利用した決済
方法。
【請求項２７】販売人から送られた販売人側記録に基
づいて、前記販売人側記録毎に確認用書類を作成する確
認用書類作成処理と、該確認用書類作成手段によって作成した書類を立会人に
送付し、該書類を前記立会人から更に前記販売人に送付
する送付処理と、前記販売人が、前記送付手段によって送付された前記書
類の内容と、前記販売人側記録の内容が一致しているか
確認する確認処理と、該確認処理によって前記一致を確認するとき、立会人は
前記書類が正確であることを確認し、該確認を前記購買
人と前記販売人に通知する通知処理と、前記確認された書類を記憶する記憶処理と、から成る立会人システムによる書類の確認プロセスをコ
ンピュータに実行させるプログラムを格納した前記コン
ピュータが読み取り可能な記憶媒体。
【請求項２８】販売人から送られた販売人側記録に基
づいて、前記販売人側記録毎に公証用書類を作成する公
証用書類作成処理と、該公証用書類作成手段によって作成した書類を公証局に
送付し、該書類を前記公証局から更に前記販売人に送付
する送付処理と、前記販売人が、前記送付手段によって送付された前記書
類の内容と、前記販売人側記録の内容が一致しているか
確認する確認処理と、該確認処理によって前記一致を確認するとき、立会人は
前記書類が正確であることを公証し、該公証を前記購買
人と前記販売人に通知する通知処理と、前記公証された書類を記憶する記憶処理と、該記憶処理によって記憶した前記公証用書類を参照し
て、前記購買人が前記販売人に支払う支払明細書を作成
する支払明細書作成処理と、該支払明細書作成処理により作成した支払明細書に基づ
き、前記販売人に対する振り込み依頼を行う振込依頼処
理と、から成る立会人システムを利用した決済プロセスをコン
ピュータに実行させるプログラムを格納した前記コンピ
ュータが読み取り可能な記憶媒体。
【請求項２９】書類データを作成する第１の計算機手段
と、前記書類データの内容を確認する第２の計算機手段と、前記確認された書類データの記憶、或いは公証を行う第
３の計算機手段と、から成ることを特徴とする立会人システム。
【請求項３０】前記書類データの記憶及び内容の確認
は、前記計算機手段の画面表示に基づいて行うことを特
徴とする請求項２９記載の立会人システム。
【請求項３１】前記書類データは、遺言書、契約書、申
込書、私信、報告書、召喚状の１つ、又は組み合わせで
あることを特徴とする請求項２９記載の立会人システ
ム。
【請求項３２】前記第１の計算機手段は、前記書類デー
タを暗号化して前記第３の計算機手段を介して前記第２
の計算機手段に送信し、該第２の計算機手段は暗号化さ
れた前記書類データを復号し、内容を確認して更に暗号
化して前記第３の計算機手段に送付し、該第３の計算機
手段は前記第２の計算機手段から送られたデータを更に
暗号化し、前記第１、第２の計算機手段に送付すること
を特徴とする請求項２９記載の立会人システム。
【請求項３３】前記第１、第２、第３の計算機手段間の
データの送受信は、予め送信側の公開キーを受信側に送
り、受信側の公開キーを送信側に送付し、前記送信側においては、送信側の秘密キーでメッセージ
を暗号化し、前記メッセージをＤＥＳで暗号化したもの
に、ＤＥＳを復号化するＤＥＫを受信側の前記公開キー
で暗号化したものを加えて得たものを送信データとして
送信し、前記受信側においては、前記送信データを受信し、該デ
ータを受信側の前記公開キーに対応する秘密キーで復号
化してＤＥＫを取り出し、該ＤＥＫによりＤＥＳで暗号
化されたデータを復号化し、送信側の前記公開キーで送
信側の前記秘密キーで暗号化されたデータを復号化する
ことを特徴とする請求項３２記載の立会人システム。
【請求項３４】購買者側において、支払い対象の明細
書を作成し、支払い依頼と共に送信する支払い依頼手段
と、該支払い依頼手段で送信された支払い明細書と、販売者
側の販売記録とを比較する比較手段と、を備えたことを特徴とする決済処理システム。