(57)【要約】【課題】  取引当事者間において、サーバーにデータを保管することなく電子取引データを当事者のみが保有するとともに同質化させ、取引の一例の処理を効率化し、安全性を高めるシステムを提供する。【解決手段】  取引当事者が同種の専用アプリケーションプログラムを備え、当該専用アプリケーションからのアクセスのみを受信する認証サーバーを設置する。取引ごとに取引データを取引先に送信する。受信側の取引内容と照合し、取引・決済内容等の電子取引データの一致を確認した後に、同質化させる。また来ず亜データの取得、口座選択、残高照合や、電子取引データによる請求書等の電子的な出力を可能にする。【選択図】  図１
2005316534.tif 000002
【特許請求の範囲】
【請求項１】
電子商取引用プログラムを備えるクライアント端末である取引当事者端末において操作により情報処理が行われるシステムであって、少なくとも複数の取引当事者端末と、前記取引当事者端末同士のデータ送受信を仲介するための認証サーバーと、前記取引当事者端末および認証サーバーを接続するネットワークとを含み構成され、
前記認証サーバーは、各取引当事者に関する情報と、当該取引当事者を認証するための認証データを記憶する認証データ記憶手段と、
認証サーバーにアクセスする取引当事者を前記認証データを用いて照合することにより認証する取引当事者認証手段と、
いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、送信側の取引当事者端末から送信された取引データに含まれるとともに、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にする鍵情報を変換する鍵情報変換手段と、
送信側の取引当事者端末から受信した取引データを受信側の取引当事者端末に送信する取引データ中継手段と、を少なくとも備え、
前記取引当事者端末は、送信側の取引当事者端末から送信された取引データを仲介する認証サーバーから受信する取引データ受信手段と、
前記取引当事者端末において入力した取引データ、および受信した取引データを自己の取引データとして記憶する取引データ記憶手段と、
受信した取引データを前記電子商取引用プログラムに取り込んで、前記鍵情報を用いて参照可能にする取引データ開錠手段と、
前記電子商取引用プログラムに取り込まれた取引データを、自己の取引データとして同質化させる取引データ同質化手段と、
いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にする鍵情報を取引データに付与する鍵情報付与手段と、
他の取引当事者端末に送信する取引データを仲介する認証サーバーに送信する取引データ送信手段と、を少なくとも備え、
取引当事者端末同士の間における電子商取引のためのデータ送受信において、専用アプリケーションを利用することにより、取引データを当事者間で共有することなく同質化することにより、取引当事者が自己の取引データをそれぞれ保管することを特徴とする、電子商取引システム。
【請求項２】
前記取引データは、前記認証サーバーを含むサーバーには蓄積されることなく、取引当事者が自己の取引データをそれぞれ保管することを特徴とする、電子商取引システム。
【請求項３】
前記認証サーバーが備える認証データ記憶手段には、氏名または名称、電子メールアドレス、ＩＰアドレス、ユーザーＩＤ、電子商取引用プログラムＩＤのいずれかを少なくとも含む各取引当事者に関する情報と、
ユーザーＩＤ、パスワード、電子商取引用プログラムＩＤのいずれかを少なくとも含む当該取引当事者を認証するための認証データとが記憶されており、
前記取引当事者認証手段は、認証サーバーに前記電子商取引用プログラムを用いてアクセスする取引当事者を前記認証データを用いて照合することにより認証することを特徴とする、請求項１または２のいずれかに記載の電子商取引システム。
【請求項４】
前記鍵情報は、各取引当事者端末が備える前記電子商取引用プログラムごとに発行されたものであり、前記認証サーバーが備える認証データ記憶手段には、当該鍵情報がさらに記憶されたことを特徴とする、請求項１〜３のいずれかに記載の電子商取引システム。
【請求項５】
前記取引当事者認証手段は、前記取引当事者端末からアクセスされるごとに、当該取引当事者端末が備える前記電子商取引用プログラムに対し次回のアクセスに用いる認証データを発行することを特徴とする、請求項１〜４のいずれかに記載の電子商取引システム。
【請求項６】
前記取引当事者認証手段は、認証サーバーにアクセスする送信側の取引当事者と、さらに受信側の取引当事者とを前記認証データを用いて照合することにより認証するものであり、少なくともいずれかの取引当事者の認証ができない場合には、当該取引データの送信の仲介をしないことを特徴とする、請求項１〜５のいずれかに記載の電子商取引システム。
【請求項７】
前記鍵情報変換手段は、いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、送信側の取引当事者端末から送信された取引データに付与された鍵情報を、受信側の取引当事者端末が備える電子商取引用プログラムのみが利用可能な開錠キーに変換し、当該取引データとともに送信することにより、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にすることを特徴とする、請求項１〜６のいずれかに記載の電子商取引システム。
【請求項８】
前記鍵情報変換手段は、いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、送信側の取引当事者端末において当該取引当事者端末が備える電子商取引用プログラム固有の認証データを開錠キーとして暗号化した後に、当該取引当事者端末から送信された取引データに付与された鍵情報を、送信側の取引当事者情報をキーとして開錠キーを抽出し、当該取引データを開錠した後に、受信側の取引当事者情報をキーとして受信側の取引当事者端末が備える電子商取引用プログラムのみが利用可能な開錠キーに変換し、当該取引データとともに送信することにより、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムのみが参照可能にすることを特徴とする、請求項７に記載の電子商取引システム。
【請求項９】
前記取引当事者端末において入力した取引データ、および受信した取引データを自己の取引データとして記憶する前記取引データ記憶手段は、当該取引当事者端末が備える電子商取引用プログラムが参照するために設けられたメールボックスであることを特徴とする、請求項１〜８のいずれかに記載の電子商取引システム。
【請求項１０】
前記取引データ記憶手段に記憶される取引データは、取引データごとの行を有するとともに、当該取引データに含まれるデータ項目ごとの列を有する表形式のデータ構造として記憶可能なものであることを特徴とする、請求項１〜９のいずれかに記載の電子商取引システム。
【請求項１１】
前記取引データ記憶手段に記憶される取引データは、未確定取引データ層、確定取引データ層、未確定決済予定データ層、確定決済予定データ層、決済済みデータ層の内のいずれか複数を少なくとも含む、取引の段階に対応するデータ層を有するデータ構造として記憶可能なものであることを特徴とする、請求項１〜１０のいずれかに記載の電子商取引システム。
【請求項１２】
前記電子商取引用プログラムに取り込まれた取引データを、自己の取引データとして同質化させる前記取引データ同質化手段は、受信した取引データに含まれるデータ項目を、取引当事者間で一致するデータ、取引当事者間で対照的であるデータ、それら以外のデータに分類し、同質化する処理を行うことにより、一方の取引当事者のデータ入力の一部または全部を不要にしたことを特徴とする、請求項１〜１１のいずれかに記載の電子商取引システム。
【請求項１３】
前記電子商取引用プログラムに取り込まれた取引データを、自己の取引データとして同質化させる前記取引データ同質化手段は、受信した取引データと、既存の未確定取引データ階層に記憶されている取引データとを照合し、既存の未確定取引データ階層に記憶されていない場合または既存の未確定取引データ階層に記憶されている取引データとのデータ項目の相違がある場合には、当該相違点を抽出し表示することを特徴とする、請求項１１または１２のいずれかに記載の電子商取引システム。
【請求項１４】
前記相違点についてデータ項目ごとまたは取引データごとに、受信側の取引当事者端末において承認された場合には、受信した前記取引データは未確定取引データ階層に記憶されることを特徴とする、請求項１３に記載の電子商取引システム。
【請求項１５】
前記相違点についてデータ項目ごとまたは取引データごとに、受信側の取引当事者端末において承認された場合には、当該取引データが同質化されたことを示すデータを送信側の取引当事者端末に送信し通知することを特徴とする、請求項１４に記載の電子商取引システム。
【請求項１６】
前記取引当事者端末において同質化され承認された取引データは、改竄防止機能を有する確定取引データ層に記憶されることを特徴とする、請求項１１〜１５のいずれかに記載の電子商取引システム。
【請求項１７】
電子商取引用プログラムを備えるクライアント端末である取引当事者端末において操作により情報処理が行われるシステムであって、少なくとも複数の取引当事者端末と、前記取引当事者端末同士のデータ送受信を仲介するための認証サーバーと、前記取引当事者端末および認証サーバーを接続するネットワークと、さらに少なくともいずれか一の取引当事者の口座情報を管理する金融機関システムとを含み構成され、
前記認証サーバーが備える認証データ記憶手段は、各金融機関システムに関する情報と、当該金融機関システムを認証するための認証データを記憶する機能を備え、
前記取引当事者認証手段は、認証サーバーにアクセスする金融機関システム前記認証データを用いて照合することにより認証する機能を備え、
前記鍵情報変換手段は、いずれか一の取引当事者端末または金融機関システムから他の取引当事者端末または金融機関システムに取引データを送信する際に、送信側端末から送信された取引データに含まれるとともに、当該取引データを受信側端末が備える電子商取引用プログラムが参照可能にする鍵情報を変換する機能を備え、
前記取引データ中継手段は、いずれか一の取引当事者端末または金融機関システムから他の取引当事者端末または金融機関システムに取引データを送信する送信側の取引当事者端末から受信した取引データを受信側の取引当事者端末に送信する機能を備え、
前記金融機関システムは、前記取引当事者端末から送信された取引データを、データ送受信を仲介する認証サーバーから受信する取引データ受信手段と、
前記取引当事者の口座データを、データ送受信を仲介する認証サーバーに対し送信する取引データ送信手段とを少なくとも備え、残高や資金移動その他の口座データを取引当事者端末が備える電子商取引用プログラムが取得可能にされたことを特徴とする、請求項１〜１６のいずれかに記載の電子商取引システム。
【請求項１８】
前記取引当事者同士の取引データごとに、当該取引当事者の口座データを前記金融機関システムから前記認証サーバーを中継して取得することにより、当該取引当事者間の口座の資金移動情報をそれぞれの取引当事者端末において取得可能にされたことを特徴とする、請求項１７に記載の電子商取引システム。
【請求項１９】
前記取引データには、支払期限、支払予定日、納品期限、納品予定日、支払日、納品日、契約日、支払方法、口座情報の内の少なくともいずれかが含まれており、前記取引当事者端末または前記金融機関システムにおいて、契約書、請求書、納品書、領収書、支払通知書、未払通知書、その他の契約または支払または納品に関する帳票データとして出力可能にされたことを特徴とする、請求項１〜１８のいずれかに記載の電子商取引システム。
【請求項２０】
前記取引当事者端末において、前記金融機関システムから受信した口座データに基づき、口座残高と支払予定額とを比較して残高不足か否かのデータを取得可能にされたことを特徴とする、請求項１７〜１９のいずれかに記載の電子商取引システム。
【請求項２１】
前記取引当事者端末が備える電子商取引用プログラムは、前記口座情報ごとの残高管理機能を備え、前記取引データに基づく入金予定および出金予定を反映した、前記取引当事者または前記金融機関におけるキャッシュ・フロー予測を管理可能にされたことを特徴とする、請求項１７〜２０のいずれかに記載の電子商取引システム。
【請求項２２】
前記取引当事者端末が備える電子商取引用プログラムは、前記取引当事者の複数の口座情報ごとの残高管理機能を備え、残高情報、入金予定情報、口座振替手数料の内の少なくともいずれかを参照して自動口座選択が可能にされたことを特徴とする、請求項１７〜２１のいずれかに記載の電子商取引システム。
【請求項２３】
前記取引当事者端末が備える電子商取引用プログラムは、前記取引当事者の複数の口座情報ごとの残高管理機能を備えるとともに、さらにあらかじめ当該複数の口座ごとに適正残高範囲が設定可能にされたことを特徴とする、請求項１７〜２２のいずれかに記載の電子商取引システム。
【請求項２４】
前記取引当事者の複数の口座情報ごとの残高情報を制約条件として、口座振替手数料を最小化する支払利用口座の組み合わせの自動選択が可能にされたことを特徴とする、請求項１７〜２３のいずれかに記載の電子商取引システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子商取引システムに関する。
より詳しくは、多数の経済主体（企業・家庭・金融機関）の金銭取引及び非金銭取引においてが、電子取引データを共有化せずに各々の経済主体が保有しつつ、かつ、電子取引データを同質化することにより、リアルタイムの取引内容照合から決済・残高管理さらに会計システムへのエントリーまでのプロセスにおける情報を管理・保管する電子商取引システムに関するものである。
【背景技術】
【０００２】
従来より、コンピュータによる販売管理、在庫管理、会計システム、決済システムその他のコンピュータシステムやソフトウェアが開発され利用されている。また、インターネットの普及に伴い、各種の電子商取引や電子決済が行われ、これらのウェブアプリケーションも開発されている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、取引証憑に基づいて当事者のそれぞれが取引データを入力し、又は請求書に基づいて取引データを入力するため、取引各社が同じ取引データの入力する必要があった。
また、オンライン・バンキングシステムへの入力に際しても、支払企業は各銀行のオンライン・バンキング(ホームバンキング)・システムへマニュアルで入力する必要がある。
また、一般に、企業間の取引(取引全般)及び企業と家庭の取引(主として公共料金)に係る支払いとして、請求書又は口座振替の案内・領収書が郵送で発行され、支払人は郵便局・銀行等の金融機関やコンビニのレジで支払いをする必要があり、煩雑なものである。また、現在、携帯電話端末を利用した電子請求書等が考案されているが、端末設置場所へ赴く必要があり、不便さは解消されないことが想定される。また携帯電話端末はパーソナルコンピュータ等のコンピュータ装置にくらべ、データ量に限界があり、また、商品ライフサイクルが短期である携帯端末については、請求書発行企業の管理コスト及び貸し倒れリスクはあまり軽減されない。さらに、携帯電話端末では、家庭への電子請求書が前提としており、一般企業においては普及が見込めない。
【０００４】
また、企業間の残高照合等の照合業務において、相手先企業との共同作業のため、営業時間内に実施する必要があった。また、一部の銀行では２４時間対応のオンラインバンキングがなされているものの、地方銀行等の多くの金曜機関では決済依頼等について営業時間に金融機関に赴き決済する必要があるなどの営業時間という時間的制約があった。
【０００５】
【特許文献１】特開２００１−３２５５３７号公報
【特許文献２】特開２００１−２３６３９２号公報
【特許文献３】特開２００１−２４３４０３号公報
【０００６】
特開２００１−３２５５３７「インターネットを介する受発注システム」においては、統一注文フォーマットを定めて、それを受信して発注先の業種フォーマットに変換する仲介装置をインターネット上に設け、さらに受発注データによるデータベース更新に際しては、それに関連するすべてのテーブルも同時にデータ更新することが記載されている。
しかしながら、上記発明によれば、統一注文フォーマットを用いてフォーマットの仲介をすることができるものの、取引証憑に基づいて当事者のそれぞれが取引データを入力し、又は請求書に基づいて取引データを入力するため、取引各社が同じ取引データの入力する必要があることには変わりない。
【０００７】
特開２００１−２３６３９２「電子商取引システムと連動する基幹業務処理装置」においては、低コストで電子商取引ができる機能を備えたシステムと、従来企業で利用されている基幹業務システムを連動させて、作業効率の高い基幹業務処理装置を提供することを目的として、データベースを共用として電子商取引毎に不整合が生じないように、そのデータベースを更新して、次回の電子商取引がいつでも行えるようにした基幹業務処理装置が提案されている。
上記発明によれば、データを受信し、受注／入金データとしてインターネットデータ交換
処理手段により整合性を保ちつつ、データベースのすべての関連テーブルが更新されるものであるが、これには下記のような問題がある。
【０００８】
すなわち、第三者機関においてウェブ上で集中管理した場合には、電子取引データがウェブサーバーやデータベースサーバー等に残るため、機密性の高い取引データが取引当事者以外の第三者機関に蓄積されることとなる。このため、取引データの漏洩リスクが相対的に高まる。また、情報が取引当事者以外の第三者機関において一元管理された場合には、第三者機関のみに情報が蓄積され、取引証憑である取引内容・請求書・領収書等が企業の手元に残らない問題があった。
【０００９】
特開２００１−２４３４０３「決済システムおよび決済方法」においては、企業や決済 金融機関だけでなく顧客にとっての利便性を向上させることのできる決済システムおよび決済方法が提案されている。
加盟企業システムは振替請求データを作成し、加盟企業用インタフェースサーバは、振替請求データを共通フォーマットに変換するとともに加盟企業独自の顧客コードを共通の決済会員コードに変換し、決済データセンターシステムは、振替請求データの内容を記録するとともに各金融期間別に振り分け、金融機関インタフェースサーバは、決済会員コードを基に、振替口座を決定するものである
しかしながら、上記発明においても、決済データセンターシステムがセンターサーバーとしてデータ管理を行うものであり、図面からも明らかなように、取引データ、履歴データが第三者機関においてウェブ上で集中管理した場合には、電子取引データがウェブサーバーやデータベースサーバー等に残るため、機密性の高い取引データが取引当事者以外の第三者機関に蓄積され集中管理される。電子取引データがウェブサーバーやデータベースサーバー等に残るため、機密性の高い取引データが取引当事者以外の第三者機関に蓄積され、取引内容・請求書・領収書等が企業の手元に残らない問題があった。
【００１０】
【特許文献４】特開２００１−２９７０７５号公報
【００１１】
特開２００１−２９７０７５「データ変換プロトコルの変換装置及び取引システム」においては、下記のような発明が開示されている。
インターネットに端末と、各端末間の文書を交換するサーバとを接続したシステムにおいて、前記文書を交換するＥＤＩプロトコルをＸＭＬにより記述し、かつＸＭＬのＤＴＤに基づきメッセージフローと各文書（発注書，発注確認書，請求書）とを関連づけて定義するとともに、文書内の項目とデータ内容とを関連づけて定義し、サーバは一方の端末から他方の端末宛への文書要求を受信するとメッセージフローにしたがって文書を選択し、その文書を他方の端末のプロトコルに適合した文書に変換して他方の端末へ送信するものである。
しかしながら、上記発明は、それぞれ異なるデータ変換プロトコルを有する各通信相手とデータ通信を行う際に、各通信相手毎にデータ変換プロトコルを変更することなくデータ通信を可能にすることを目的とするものであり、本願発明が解決しようとする課題とは異なる目的を有するものである。
【００１２】
また、従来の技術によれば、各企業で独自の請求書を作成しており、請求書を受け取った企業は社内管理のため、請求書とは別に支払伝票等の伝票を作成し管理する必要があった。
さらに、従来、取引契約、取引確認、債権残高管理、請求書の発行、領収書の発行の一連の取引プロセスが取引先との情報の共有化とオンライン化により、取引先の支払予定情報が利用者の入金予定情報として利用でき、効率的な資金管理が可能となる。
銀行など金融機関の側においても、各企業の決済予定情報が振込依頼が実際にあるまで予測することができず、Ｂufferとして銀行内に資金を留保する必要があり、また、当該予測を超えた資金需要があった場合、当該銀行はInter-Ｂank市場等から資金供給する必要があり、資金調達コストが発生していた。
【００１３】
そこで本発明においては、上記の様々な課題を解決し、多数の経済主体（企業・家庭・金融機関）の金銭取引及び非金銭取引においてが、電子取引データを共有化せずに各々の経済主体が保有しつつ、かつ、電子取引データを同質化することにより、リアルタイムの取引内容照合から決済・残高管理さらに会計システムへのエントリーまでのプロセスにおける情報を管理・保管する電子商取引システムを提供することを目的とする。
各経済主体が取引データをそれぞれ保有しつつ、かつ、電子取引データの同質化を図るとともに、取引当事者間のみで同質の電子取引データを保有することより、取引から決済及び残高管理までの一連の取引サイクルにおいて、機密性の高い取引内容が第三者であるサーバー管理者に取引データが蓄積されることなく、取引当事者にとって安全性が高く情報漏洩リスクを軽減でき、業務効率を改善するシステムを提供することを目的とする。
さらに、取引証憑に基づいて当事者のそれぞれが取引データを入力し、または請求書に基づいて取引データを入力する手間と時間を軽減し、しかもすべての取引データは専用アプリケーションにおいて電子データとして一元管理することにより、データ入力コストと証憑保管コストを削減することの可能なシステムを提供することを目的とする。
さらに、現状、売り手は請求書によって買い手に支払期限を通知するのみで、売り手は正確な入金予定日、すなわち、買い手の支払予定日を把握することは困難である。そこで、買い手が自己のアプリケーションに入力した支払予定情報(支払予定日、支払予定口座情報等)データが、売り手に入金予定情報(入金予定日、入金予定口座情報等)として通知されることにより、売り手はより正確な入金予定情報に基づいて口座ごとのキャッシュ・フロー管理が可能となり、また、当該入金予定情報を反映した口座残高をベースとして、他のデータ(取引先ごと振込口座ごとの取引データ又は取引データの集合、口座残高の制約条件、手数料情報等)を用いることにより、口座残高の制約条件の範囲内で、口座振込手数料を最小化する支払口座の自動選択が可能なシステムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するため、請求項１に記載の発明においては、
電子商取引用プログラムを備えるクライアント端末である取引当事者端末において操作により情報処理が行われるシステムであって、少なくとも複数の取引当事者端末と、前記取引当事者端末同士のデータ送受信を仲介するための認証サーバーと、前記取引当事者端末および認証サーバーを接続するネットワークとを含み構成され、
前記認証サーバーは、各取引当事者に関する情報と、当該取引当事者を認証するための認証データを記憶する認証データ記憶手段と、
認証サーバーにアクセスする取引当事者を前記認証データを用いて照合することにより認証する取引当事者認証手段と、
いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、送信側の取引当事者端末から送信された取引データに含まれるとともに、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にする鍵情報を変換する鍵情報変換手段と、
送信側の取引当事者端末から受信した取引データを受信側の取引当事者端末に送信する取引データ中継手段と、を少なくとも備え、
前記取引当事者端末は、送信側の取引当事者端末から送信された取引データを仲介する認証サーバーから受信する取引データ受信手段と、
前記取引当事者端末において入力した取引データ、および受信した取引データを自己の取引データとして記憶する取引データ記憶手段と、
受信した取引データを前記電子商取引用プログラムに取り込んで、前記鍵情報を用いて参照可能にする取引データ開錠手段と、
前記電子商取引用プログラムに取り込まれた取引データを、自己の取引データとして同質化させる取引データ同質化手段と、
いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にする鍵情報を取引データに付与する鍵情報付与手段と、
他の取引当事者端末に送信する取引データを仲介する認証サーバーに送信する取引データ送信手段と、を少なくとも備え、
取引当事者端末同士の間における電子商取引のためのデータ送受信において、専用アプリケーションを利用することにより、取引データを当事者間で共有することなく同質化することにより、取引当事者が自己の取引データをそれぞれ保管する、電子商取引システムであることを特徴としている。
【００１５】
また、上記課題を解決するため、請求項２に記載の発明においては、
前記取引データは、前記認証サーバーを含むサーバーには蓄積されることなく、取引当事者が自己の取引データをそれぞれ保管することを特徴とする、電子商取引システムであることを特徴としている。
Web方式により電子商取引を管理した場合の情報漏洩リスク
（課  題）第三者機関においてWeb上で集中管理した場合、電子取引データがWeb及び中央サーバーに残るため、機密性の高い取引データが取引当事者以外の第三者機関に蓄積されることとなる。取引データの漏洩リスクが相対的に高まる。
【００１６】
また、上記課題を解決するため、請求項３に記載の発明においては、
前記認証サーバーが備える認証データ記憶手段には、氏名または名称、電子メールアドレス、ＩＰアドレス、ユーザーＩＤ、電子商取引用プログラムＩＤのいずれかを少なくとも含む各取引当事者に関する情報と、
ユーザーＩＤ、パスワード、電子商取引用プログラムＩＤのいずれかを少なくとも含む当該取引当事者を認証するための認証データとが記憶されており、
前記取引当事者認証手段は、認証サーバーに前記電子商取引用プログラムを用いてアクセスする取引当事者を前記認証データを用いて照合することにより認証する、請求項１または２のいずれかに記載の電子商取引システムであることを特徴としている。
【００１７】
また、上記課題を解決するため、請求項４に記載の発明においては、
前記鍵情報は、各取引当事者端末が備える前記電子商取引用プログラムごとに発行されたものであり、前記認証サーバーが備える認証データ記憶手段には、当該鍵情報がさらに記憶された、請求項１〜３のいずれかに記載の電子商取引システムであることを特徴としている。
【００１８】
また、上記課題を解決するため、請求項５に記載の発明においては、
前記取引当事者認証手段は、前記取引当事者端末からアクセスされるごとに、当該取引当事者端末が備える前記電子商取引用プログラムに対し次回のアクセスに用いる認証データを発行する、請求項１〜４のいずれかに記載の電子商取引システムであることを特徴としている。
【００１９】
また、上記課題を解決するため、請求項６に記載の発明においては、
前記取引当事者認証手段は、認証サーバーにアクセスする送信側の取引当事者と、さらに受信側の取引当事者とを前記認証データを用いて照合することにより認証するものであり、少なくともいずれかの取引当事者の認証ができない場合には、当該取引データの送信の仲介をしない、請求項１〜５のいずれかに記載の電子商取引システムであることを特徴としている。
【００２０】
また、上記課題を解決するため、請求項７に記載の発明においては、
前記鍵情報変換手段は、いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、送信側の取引当事者端末から送信された取引データに付与された鍵情報を、受信側の取引当事者端末が備える電子商取引用プログラムのみが利用可能な開錠キーに変換し、当該取引データとともに送信することにより、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にする、請求項１〜６のいずれかに記載の電子商取引システムであることを特徴としている。
【００２１】
また、上記課題を解決するため、請求項８に記載の発明においては、
前記鍵情報変換手段は、いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、送信側の取引当事者端末において当該取引当事者端末が備える電子商取引用プログラム固有の認証データを開錠キーとして暗号化した後に、当該取引当事者端末から送信された取引データに付与された鍵情報を、送信側の取引当事者情報をキーとして開錠キーを抽出し、当該取引データを開錠した後に、受信側の取引当事者情報をキーとして受信側の取引当事者端末が備える電子商取引用プログラムのみが利用可能な開錠キーに変換し、当該取引データとともに送信することにより、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムのみが参照可能にする、請求項７に記載の電子商取引システムであることを特徴としている。
【００２２】
また、上記課題を解決するため、請求項９に記載の発明においては、
前記取引当事者端末において入力した取引データ、および受信した取引データを自己の取引データとして記憶する前記取引データ記憶手段は、当該取引当事者端末が備える電子商取引用プログラムが参照するために設けられたメールボックスである、請求項１〜８のいずれかに記載の電子商取引システムであることを特徴としている。
データの送受信においてメールボックス方式を採用し、サーバーの機能として認証機能のみを持たせることにより、第三者であるサーバー管理者に取引及び決済データが蓄積することなく、取引当事者間のみで電子取引データを保有することが可能となる。また、機密性の高い取引内容が第三者であるサーバー管理者に取引データが蓄積されないシステムにすることで、ウェブ方式により電子商取引を管理した場合のサーバー管理者からの情報漏洩リスクを解決することが可能となり、社会インフラとしての信頼性を確保することが可能となる。これにより、情報が取引当事者以外の第三者機関において一元管理された場合、第三者機関のみに情報が蓄積され、取引証憑である取引内容・請求書・領収書等が企業の手元に残らず、各経済主体は取引データを電子化した状態で保管することができないといった問題がなくなる。
【００２３】
また、上記課題を解決するため、請求項１０に記載の発明においては、
前記取引データ記憶手段に記憶される取引データは、取引データごとの行を有するとともに、当該取引データに含まれるデータ項目ごとの列を有する表形式のデータ構造として記憶可能なものである、請求項１〜９のいずれかに記載の電子商取引システムであることを特徴としている。
【００２４】
また、上記課題を解決するため、請求項１１に記載の発明においては、
前記取引データ記憶手段に記憶される取引データは、未確定取引データ層、確定取引データ層、未確定決済予定データ層、確定決済予定データ層、決済済みデータ層の内のいずれか複数を少なくとも含む、取引の段階に対応するデータ層を有するデータ構造として記憶可能なものである、請求項１〜１０のいずれかに記載の電子商取引システムであることを特徴としている。
【００２５】
また、上記課題を解決するため、請求項１２に記載の発明においては、
前記電子商取引用プログラムに取り込まれた取引データを、自己の取引データとして同質化させる前記取引データ同質化手段は、受信した取引データに含まれるデータ項目を、取引当事者間で一致するデータ、取引当事者間で対照的であるデータ、それら以外のデータに分類し、同質化する処理を行うことにより、一方の取引当事者のデータ入力の一部または全部を不要にした、請求項１〜１１のいずれかに記載の電子商取引システムであることを特徴としている。
これにより、取引発生時点において、取引証憑に基づいて当事者のそれぞれが取引データを入力し、または請求書に基づいて取引データを入力するため、取引各社が同じ取引データを社内システムに入力する必要を軽減し、売り手が電子化した取引データを、認証サーバーを介して買い手と送受信することにより、買い手は入力業務を要する取引内容を電子化することが可能になる。
【００２６】
また、上記課題を解決するため、請求項１３に記載の発明においては、
前記電子商取引用プログラムに取り込まれた取引データを、自己の取引データとして同質化させる前記取引データ同質化手段は、受信した取引データと、既存の未確定取引データ階層に記憶されている取引データとを照合し、既存の未確定取引データ階層に記憶されていない場合または既存の未確定取引データ階層に記憶されている取引データとのデータ項目の相違がある場合には、当該相違点を抽出し表示する、請求項１１または１２のいずれかに記載の電子商取引システムであることを特徴としている。
【００２７】
また、上記課題を解決するため、請求項１４に記載の発明においては、
前記相違点についてデータ項目ごとまたは取引データごとに、受信側の取引当事者端末において承認された場合には、受信した前記取引データは未確定取引データ階層に記憶される、請求項１３に記載の電子商取引システムであることを特徴としている。
【００２８】
また、上記課題を解決するため、請求項１５に記載の発明においては、
前記相違点についてデータ項目ごとまたは取引データごとに、受信側の取引当事者端末において承認された場合には、当該取引データが同質化されたことを示すデータを送信側の取引当事者端末に送信し通知する、請求項１４に記載の電子商取引システムであることを特徴としている。
【００２９】
また、上記課題を解決するため、請求項１６に記載の発明においては、
前記取引当事者端末において同質化され承認された取引データは、改竄防止機能を有する確定取引データ層に記憶される、請求項１１〜１５のいずれかに記載の電子商取引システムであることを特徴としている。
【００３０】
また、上記課題を解決するため、請求項１７に記載の発明においては、
電子商取引用プログラムを備えるクライアント端末である取引当事者端末において操作により情報処理が行われるシステムであって、少なくとも複数の取引当事者端末と、前記取引当事者端末同士のデータ送受信を仲介するための認証サーバーと、前記取引当事者端末および認証サーバーを接続するネットワークと、さらに少なくともいずれか一の取引当事者の口座情報を管理する金融機関システムとを含み構成され、
前記認証サーバーが備える認証データ記憶手段は、各金融機関システムに関する情報と、当該金融機関システムを認証するための認証データを記憶する機能を備え、
前記取引当事者認証手段は、認証サーバーにアクセスする金融機関システム前記認証データを用いて照合することにより認証する機能を備え、
前記鍵情報変換手段は、いずれか一の取引当事者端末または金融機関システムから他の取引当事者端末または金融機関システムに取引データを送信する際に、送信側端末から送信された取引データに含まれるとともに、当該取引データを受信側端末が備える電子商取引用プログラムが参照可能にする鍵情報を変換する機能を備え、
前記取引データ中継手段は、いずれか一の取引当事者端末または金融機関システムから他の取引当事者端末または金融機関システムに取引データを送信する送信側の取引当事者端末から受信した取引データを受信側の取引当事者端末に送信する機能を備え、
前記金融機関システムは、前記取引当事者端末から送信された取引データを、データ送受信を仲介する認証サーバーから受信する取引データ受信手段と、
前記取引当事者の口座データを、データ送受信を仲介する認証サーバーに対し送信する取引データ送信手段とを少なくとも備え、残高や資金移動その他の口座データを取引当事者端末が備える電子商取引用プログラムが取得可能にされた、請求項１〜１６のいずれかに記載の電子商取引システムであることを特徴としている。
【００３１】
また、上記課題を解決するため、請求項１８に記載の発明においては、
前記取引当事者同士の取引データごとに、当該取引当事者の口座データを前記金融機関システムから前記認証サーバーを中継して取得することにより、当該取引当事者間の口座の資金移動情報をそれぞれの取引当事者端末において取得可能にされた、請求項１７に記載の電子商取引システムであることを特徴としている。
これにより、たとえば、売り手が指定入金口座情報を買い手に送受信する際に、取引コードをキーとして前記のプロセスの取引当事者が合意した取引データと当該指定口座情報を結びつけることにより、買い手は入力業務を要することなく決済データを作成することが可能となる。取引によって生じた債権・債務と決済データが照合されるため、債権・債務管理も可能となる。そして金融機関のオンライン・バンキングを利用する場合には、既に社内の基幹システムへの入力によって取引データは電子化されているものの、ウェブ上の専用入力画面に決済データを１件ごとに入力する必要があり、入力が煩雑なため従来通り金融機関の窓口を利用する煩雑さがあったが、それらの必要をなくし、同一の取引について取引内容と決済内容での二重に入力する手間がなくなる。
【００３２】
また、上記課題を解決するため、請求項１９に記載の発明においては、
前記取引データには、支払期限、支払予定日、納品期限、納品予定日、支払日、納品日、契約日、支払方法、口座情報の内の少なくともいずれかが含まれており、前記取引当事者端末または前記金融機関システムにおいて、契約書、請求書、納品書、領収書、支払通知書、未払通知書、その他の契約または支払または納品に関する帳票データとして出力可能にされた、請求項１〜１８のいずれかに記載の電子商取引システムであることを特徴としている。
これにより、一般に、企業間の取引(取引全般)及び企業と家庭の取引(主として公共料金)に係る支払いとして、請求書又は口座振替の案内・領収書が郵送で発行され、支払人は郵便局・銀行等の金融機関やコンビニのレジで支払いをする必要があったが、決済情報を送受信することにより、請求書の発行が不要となる。
また、各企業で独自の様々な請求書を作成しており、請求書を受取側の企業は社内管理のため、請求書とは別に支払伝票等の伝票を作成し管理する必要があったが、取引当事者間で合意済みの電子取引データの内容が同質化された時点でロックされるようにすれば、取引当事者間で合意済みで、かつ、互いに同質の確定電子取引データを利用して「請求書兼仕入伝票」及び「領収書兼売上伝票」のように、外部証憑と内部証憑を一体で印刷することができるようになる。また、請求書の発送コスト及び社内管理のための伝票が不要となる。
【００３３】
また、上記課題を解決するため、請求項２０に記載の発明においては、
前記取引当事者端末において、前記金融機関システムから受信した口座データに基づき、口座残高と支払予定額とを比較して残高不足か否かのデータを取得可能にされた、請求項１７〜１９のいずれかに記載の電子商取引システムであることを特徴としている。
【００３４】
また、上記課題を解決するため、請求項２１に記載の発明においては、
前記取引当事者端末が備える電子商取引用プログラムは、前記口座情報ごとの残高管理機能を備え、前記取引データに基づく入金予定および出金予定を反映した、前記取引当事者または前記金融機関におけるキャッシュ・フロー予測を管理可能にされた、請求項１７〜２０のいずれかに記載の電子商取引システムであることを特徴としている。
銀行などの金融機関においては、各企業の決済予定情報について、通常、振込依頼を実際に受けるまで予測することができず、Ｂufferとして銀行内に資金を留保する必要があり、また当該予測を超えた資金需要があった場合にはInter-Ｂank市場等から資金供給する必要があり、資金調達コストが発生していた。これに対し、取引金融機関の口座残高管理機能をソフトウェアに設定することにより「銀行間の資金決済情報の予測不可能性」を解決する。また支払予定日が提示されることにより、入金予定日が判明するため、当日の予想キャッシュ・フローの算定及び資金運用・調達が効率化される。
【００３５】
また、上記課題を解決するため、請求項２２に記載の発明においては、
前記取引当事者端末が備える電子商取引用プログラムは、前記取引当事者の複数の口座情報ごとの残高管理機能を備え、残高情報、入金予定情報、口座振替手数料の内の少なくともいずれかを参照して自動口座選択が可能にされた、請求項１７〜２１のいずれかに記載の電子商取引システムであることを特徴としている。
【００３６】
また、上記課題を解決するため、請求項２３に記載の発明においては、
前記取引当事者端末が備える電子商取引用プログラムは、前記取引当事者の複数の口座情報ごとの残高管理機能を備えるとともに、さらにあらかじめ当該複数の口座ごとに適正残高範囲が設定可能にされた、請求項１７〜２２のいずれかに記載の電子商取引システムであることを特徴としている。
あらかじめ口座マスターにおいて口座ごとに適正残高の範囲(上限及び下限)を設定し、入金予定情報と口座振替手数料マスターに従って、自動口座振替をすることにより、変数である支払予定情報を決定することにより自動口座選択を可能とする。これにより、利用者の設定する適切な口座残高管理が可能となる。
【００３７】
また、上記課題を解決するため、請求項２４に記載の発明においては、
前記取引当事者の複数の口座情報ごとの残高情報を制約条件として、口座振替手数料を最小化する支払利用口座の組み合わせの自動選択が可能にされたことを特徴とする、請求項１７〜２３のいずれかに記載の電子商取引システム。
【発明の効果】
【００３８】
本発明によれば、多数の経済主体（企業・家庭・金融機関）の金銭取引及び非金銭取引においてが、電子取引データを共有化せずに各々の経済主体が保有しつつ、かつ、電子取引データを同質化することにより、リアルタイムの取引内容照合から決済・残高管理さらに会計システムへのエントリーまでのプロセスにおける情報を管理・保管する電子商取引システムを提供することができる。
各経済主体が取引データをそれぞれ保有しつつ、かつ、電子取引データの同質化を図るとともに、取引当事者間のみで同質の電子取引データを保有することより、取引から決済及び残高管理までの一連の取引サイクルにおいて、機密性の高い取引内容が第三者であるサーバー管理者に取引データが蓄積されることなく、取引当事者にとって安全性が高く情報漏洩リスクを軽減でき、業務効率を改善するシステムを提供することができる。
電子取引データを共有化せずに同質化することにより、専用Ａpplication 内での取引・決済データの一元管理が可能である。また、電子化された証憑であるため保存が容易である。さらに、ブラウザ上にて、電子取引データを管理しないため、取引当事者以外の第三者から情報が漏洩することがない。
【００３９】
さらに、売り手の取引データが買い手の端末に伝達されるため、買い手の入力業務が大幅に削減される。
さらに、取引証憑に基づいて当事者のそれぞれが取引データを入力し、または請求書に基づいて取引データを入力する手間と時間を軽減し、しかもすべての取引データは専用アプリケーションにおいて電子データとして一元管理することにより、データ入力コストと証憑保管コストを削減することの可能なシステムを提供することができる。取引当事者の一方が入力した電子取引データが企業Ｂの専用端末に送信されることにより、他方の取引当事者は相手方の入力した電子取引データが正確性の検証のみで自社の電子取引データとして取り込むことができる。
また、紙媒体及び電子データによる請求書不発行による郵送コスト及び通信コストを削減するとともに、企業の従来の請求書と伝票を一体化することが可能となり、また、データ上で上席者の承認することにより、用紙自体が不要となる。取引時点で取引内容が確定（納品が必要な場合は納品部署の承認後）するため、請求書・領収書の発行が不要となり、資源の節約につながる。
【００４０】
さらに、現状、売り手は請求書によって買い手に支払期限を通知するのみで、売り手は正確な入金予定日、すなわち、買い手の支払予定日を把握することは困難である。そこで、買い手が自己のアプリケーションに入力した支払予定情報(支払予定日、支払予定口座情報等)データが、売り手に入金予定情報(入金予定日、入金予定口座情報等)として通知されることにより、売り手はより正確な入金予定情報に基づいて口座ごとのキャッシュ・フロー管理が可能となり、また、当該入金予定情報を反映した口座残高をベースとして、他のデータ(取引先ごと振込口座ごとの取引データ又は取引データの集合、口座残高の制約条件、手数料情報等)を用いることにより、口座残高の制約条件の範囲内で、口座振込手数料を最小化する支払口座の自動選択が可能となる。
また、Ａpplication内で取引先毎に集計され、定期的に債権債務残高情報の自動照合を可能とさせることにより、確度の高い残高データを即時に提供できるため、それにより現状行われている紙媒体を利用した残高照合が不要となり、企業の月次決算の早期化につながるものである。
【発明を実施するための最良の形態】
【００４１】
以下、本発明の実施の形態について図面を参照して説明する。
図１は、本発明のシステムの基本的な構成の一例を示すシステム構成図である。
本発明の電子商取引システムは、電子商取引用プログラムを備えるクライアント端末である取引当事者端末において操作により情報処理が行われるシステムであって、少なくとも複数の取引当事者端末と、前記取引当事者端末同士のデータ送受信を仲介するための認証サーバーと、前記取引当事者端末および認証サーバーを接続するネットワークとを含み構成される。
【００４２】
本発明のサーバーシステムに接続するための取引当事者端末としては、通常、パーソナルコンピュータやワークステーションなどのコンピュータ端末が用いられる。この他、取引当事者端末には、インターネット等に接続可能なブラウザ機能を搭載した携帯電話をはじめとする無線通信端末、携帯情報端末や、インターネットＴＶ、ゲーム機器、テレビ会議システム、その他のネットワーク接続機能を備えた家電製品などの機器を広く含む。コンピュータ端末は、制御手段、記憶手段、入力手段、出力手段、表示手段などを備える。またインターネットに代表されるコンピュータネットワークに接続し、データの送受信を行う機能を備え、ブラウザや電子メールソフトウェア、ワードプロセッサなどのアプリケーションプログラムや、オペレーティングシステム（ＯＳ）を備えることが通常の形態である。
【００４３】
認証サーバーは、インターネットに代表されるネットワークに接続されて備えられ、ネットワークに接続する取引当事者端末からアクセスされる。ネットワークには、インターネットをはじめとして、専用線により接続されたネットワーク形態や、企業内ＬＡＮ、企業間ＬＡＮ、ＷＡＮなどの形態を広く含む。またここで用いられる通信回線の形態には、有線通信、無線通信の形態を広く含み、衛星通信や、Ｂｌｕｅｔｏｏｔｈなどを用いた形態を含むようにしてもよい。
サーバーは、通常は、アプリケーションサーバー、データベースサーバー、認証サーバー、ウェブサーバー、その他必要に応じメールサーバー、その他の各種装置により構成することができる。これらの各サーバーは、物理的に同一の装置に設けられる形態や、物理的に複数の装置からなる形態、あるいはネットワークを介して接続される物理的に複数の装置からなる形態などを含み、機能的に同様の機能が実現されるならば、様々な形態を含む。
【００４４】
（認証サーバー）
初めに、認証サーバーの構成について説明する。
認証サーバーは、各取引当事者に関する情報と、当該取引当事者を認証するための認証データを記憶する認証データ記憶手段を備えている。
認証サーバーが備える認証データ記憶手段には、取引当事者ごとに、氏名または会社名などの名称、電子メールアドレス、ＩＰアドレス、ユーザーＩＤ、電子商取引用プログラムＩＤのいずれかを少なくとも含む各取引当事者に関する情報が記憶されている。また、住所、連絡先、担当者名、電話番号、ファクシミリ番号、その他の取引当事者に関するデータを記憶することができる。
また認証データ記憶手段には、ユーザーＩＤ、パスワード、電子商取引用プログラムＩＤのいずれかを少なくとも含む当該取引当事者を認証するための認証データとが記憶されている。
【００４５】
次に認証サーバーは、認証サーバーにアクセスする取引当事者を前記認証データを用いて照合することにより認証する取引当事者認証手段を備えている。
取引当事者認証手段は、認証サーバーに前記電子商取引用プログラムを用いてアクセスする取引当事者を前記認証データを用いて照合することにより認証する。
認証データは、ユーザーＩＤやパスワードなどを、認証サーバーにアクセスした取引当事者であるユーザーがウェブサイト上で、あるいは認証サーバーに接続するための専用のアプリケーションプログラムである電子商取引用プログラムを用いて画面上で入力し、送信するようにしてもよい。また、認証サーバーにアクセスすることにより自動的に電子商取引プログラムＩＤやＩＰアドレスなどが認証データとして送信されるようにしてもよい。
【００４６】
取引当事者認証手段は、好ましい形態の一例によれば、前記取引当事者端末からアクセスされるごとに、当該取引当事者端末が備える前記電子商取引用プログラムに対し次回のアクセスに用いる認証データを発行する。これにより認証とセキュリティをより厳重にすることができる。その他、データセキュリティや認証方法に関しては、知られている他の様々な方法を採用したり、あるいは組み合わせたりして利用することができる。
【００４７】
取引当事者認証手段は、認証サーバーにアクセスする送信側の取引当事者と、さらに受信側の取引当事者とを前記認証データを用いて照合することにより認証するものであり、少なくともいずれかの取引当事者の認証ができない場合には、当該取引データの送信の仲介をしない。
取引当事者の認証ができた場合には、当該取引当事者同士の端末間における取引データの送受信の仲介を許可する。
【００４８】
また、前記認証サーバーが備える認証データ記憶手段には、当該鍵情報がさらに記憶されるようにしてもよい。鍵情報は、具体的には各取引当事者ごとに発行され、取引データを開錠するための電子鍵である。鍵情報は、取引当事者端末間において送受信される取引データを開錠するために用いるものである。
また、鍵情報は、請求書、領収書その他の帳票類などの各種データの暗号化や、後述する金融機関システムとの間で送受信される取引データ、口座データなどの開錠に用いることもできる。
鍵情報は、好ましい形態の一例によれば、各取引当事者端末が備える前記電子商取引用プログラムごとに発行されたものである。これにより、取引当事者として認証されたことにより受信した取引データを、当該取引当事者の電子商取引用プログラムのみで開錠することができるようにする。電子商取引用プログラムは、鍵情報を用いたデータ暗号化、復号化をするための機能を備える専用アプリケーションプログラムであることが望ましい。
【００４９】
次に認証サーバーは、いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、送信側の取引当事者端末から送信された取引データに含まれるとともに、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にする鍵情報を変換する鍵情報変換手段を備えている。
鍵情報変換手段は、いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、送信側の取引当事者端末から送信された取引データに付与された鍵情報を、受信側の取引当事者端末が備える電子商取引用プログラムのみが利用可能な開錠キーに変換し、当該取引データとともに送信することにより、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムのみが参照可能にする。
【００５０】
より好ましくは、鍵情報変換手段は、いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、送信側の取引当事者端末において当該取引当事者端末が備える電子商取引用プログラム固有の認証データを開錠キーとして暗号化した後に、当該取引当事者端末から送信された取引データに付与された鍵情報を、送信側の取引当事者情報をキーとして開錠キーを抽出し、当該取引データを開錠した後に、受信側の取引当事者情報をキーとして受信側の取引当事者端末が備える電子商取引用プログラムのみが利用可能な開錠キーに変換し、当該取引データとともに送信することにより、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムのみが参照可能にする。
すなわち、送信側の取引当事者端末から送信され、送信側の鍵情報が付与された取引データは、認証サーバーにおいて受信される。このとき、認証サーバーには当該システム利用者の利用者情報のほか、取引当事者の専用アプリケーションの暗号開錠キーが登録されており、送信された取引データは送信元のアドレス情報等をキーにして、認証サーバーに登録されている取引当事者記憶手段から送信側取引当事者の発信元アドレス情報等をキーにして認証サーバーにて開錠キーで開錠する一方で、送信先である受信側取引当事者のアドレス情報等をキーにして認証サーバーに登録されている開錠キーに交換する。
【００５１】
次に認証サーバーは、送信側の取引当事者端末から受信した取引データを受信側の取引当事者端末に送信する取引データ中継手段を備えている。鍵情報変換手段により開錠キーに変換し、当該取引データとともに送信することにより、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にする。
これにより、電子取引方法において、取引データは当該受信側の電子商取引用プログラムでのみ開錠できることになる。
また、前記取引データは、前記認証サーバーを含むサーバーには蓄積されることなく、取引当事者が自己の取引データをそれぞれ保管する。
【００５２】
（取引当事者端末）
次に、取引当事者端末について説明する。
取引当事者端末は、送信側の取引当事者端末から送信された取引データを仲介する認証サーバーから受信する取引データ受信手段を備えている。取引データの送信、受信は、電子メール形式、ウェブメール形式、ＦＴＰ、その他のデータ送受信方法を採用することができる。電子商取引用プログラムは、認証サーバーを経由したデータの送受信をするための機能を備える専用アプリケーションプログラムであることが望ましい。
【００５３】
次に取引当事者端末は、取引当事者端末において入力した取引データ、および受信した取引データを自己の取引データとして記憶する取引データ記憶手段を備えている。
取引データ記憶手段は、各取引当事者端末が備える取引データを蓄積するためのデータベースである。データベースの形式には、関係データベースや、ＣＳＶ形式、ＸＭＬなどのタグ情報を利用したデータベースなど、各種の構成を採用することができる。汎用的なデータ形式を用いることにより、各取引当事者端末においては、既存の販売管理システム、会計システム、在庫管理システム、その他のシステムにおいてデータの利用をすることができる。
また、取引当事者端末において入力した取引データ、および受信した取引データを自己の取引データとして記憶する取引データ記憶手段の好ましい形態の代表的な一例は、当該取引当事者端末が備える電子商取引用プログラムが参照するために設けられたメールボックスである。
【００５４】
取引データ記憶手段に記憶される取引データは、取引データごとの行を有するとともに、当該取引データに含まれるデータ項目ごとの列を有する表形式のデータ構造として記憶可能なものである。データ項目は、取引コード、取引先、取引内容、数量、単価、金額、その他の項目などである。
また、取引データ記憶手段に記憶される取引データは、未確定取引データ層、確定取引データ層、未確定決済予定データ層、確定決済予定データ層、決済済みデータ層の内のいずれか複数を少なくとも含む、取引の段階に対応するデータ層を有するデータ構造として記憶可能なものである。
これらのデータ構造の具体的な例については後述する。
【００５５】
次に取引当事者端末は、受信した取引データを前記電子商取引用プログラムに取り込んで、前期鍵情報を用いて参照可能にする取引データ開錠手段を備えている。鍵情報変換手段により変換された、当該取引当事者のみが利用可能な開錠キーにし、当該取引データとともに受信することにより、当該取引データを受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にする。電子商取引用プログラムは、鍵情報を用いたデータ暗号化、復号化をするための機能を備える専用アプリケーションプログラムであることが望ましい。
これにより、電子取引方法において、取引データは当該受信側の電子商取引用プログラムでのみ開錠できることになる。
【００５６】
次に取引当事者端末は、電子商取引用プログラムに取り込まれた取引データを、自己の取引データとして同質化させる取引データ同質化手段を備えている。
電子商取引用プログラムに取り込まれた取引データを、自己の取引データとして同質化させる前記取引データ同質化手段は、受信した取引データに含まれるデータ項目を、取引当事者間で一致するデータ、取引当事者間で対照的であるデータ、それら以外のデータに分類し、同質化する処理を行うことにより、一方の取引当事者のデータ入力の一部または全部を不要にしたものである。
取引当事者間で一致するデータは、たとえば契約日、購入日、支払期日、金額、数量などの取引当事者間で共通するデータ項目である。また、取引当事者間で対照的であるデータは、たとえば販売・購入、売掛・買掛、支払・入金など、取引の一方と他方とが対照的となるデータ項目である。
同質化処理の具体的な一例については後述する。
【００５７】
電子商取引用プログラムに取り込まれた取引データを、自己の取引データとして同質化させる前記取引データ同質化手段は、受信した取引データと、既存の未確定取引データ階層に記憶されている取引データとを照合し、既存の未確定取引データ階層に記憶されていない場合または既存の未確定取引データ階層に記憶されている取引データとのデータ項目の相違がある場合には、当該相違点を抽出し表示する。
【００５８】
前記相違点についてデータ項目ごとまたは取引データごとに、受信側の取引当事者端末において承認された場合には、受信した前記取引データは未確定取引データ階層に記憶される。
前記相違点についてデータ項目ごとまたは取引データごとに、受信側の取引当事者端末において承認された場合には、当該取引データが同質化されたことを示すデータを送信側の取引当事者端末に送信し通知する。
前記取引当事者端末において同質化され承認された取引データは、前記改竄防止機能を有する確定取引データ層に記憶される。
【００５９】
たとえば、買い手（または売り手）は、売り手（または買い手）が送信した電子的な取引データを認証サーバーを介して受信し、内容確認後、買い手（または売り手）の専用アプリケーションプログラムにおいて取引データとして反映される。一方、受信した取引データの一部に誤りがあれば、買い手（または売り手）は、訂正後に取引データを取り込む。受信側である買い手（または売り手）の認識した電子取引データの内容は、自動的に送信元である売り手（または買い手）に送信され、売り手（または買い手）は、買い手（または売り手）の内容を確認した後に、当該電子的な取引データを取り込む。
上記のプロセスを経ることにより、取引のデータエントリー時点で、原則として取引当事者の一方が取引データを電子化した後に、取引先に送信することにより、受信側は送信元の取引データを自己の取引データとして取り扱うことができる。このため、大幅な入力業務の削減をすることが可能となる。また、自己の取引データとしてアプリケーションプログラムに取り込む際に、自動照合機能により２重送受信がないこと等を確認することができる。取引当事者間において、取引内容照合を自動で行い、電子取引データを共有化せずに同質化することが可能となる。
【００６０】
次に取引当事者端末は、いずれか一の取引当事者端末から他の取引当事者端末に取引データを送信する際に、受信側の取引当事者端末が備える電子商取引用プログラムが参照可能にする鍵情報を取引データに付与する鍵情報付与手段を備えている。
取引当事者間において、その一方である送信側取引当事者は、取引相手方である受信側取引当事者との取引内容を示す取引データを、電子商取引用プログラムを用いて入力する。
入力された取引データは、前記の電子商取引用プログラムを用いて暗号化した後に送信する。当該暗号化された取引データは、鍵情報の変換をする前の時点では、送信側取引当事者端末の専用アプリケーション固有の鍵により開錠することができる。
なお、取引当事者間においてデータ送受信を行うのであるから、送信側取引当事者が相手からデータを受信して受信側取引当事者ともなるものであり、送信側、受信側という用語は、本明細書においてはある一つの取引データの送信行為に着目した場合の送信側、受信側を示している。
【００６１】
次に取引当事者端末は、他の取引当事者端末に送信する取引データを仲介する認証サーバーに送信する取引データ送信手段を備えている。
前述したように、送信、受信は、電子メール形式、ウェブメール形式、ＦＴＰ、その他のデータ送受信方法を採用することができる。電子商取引用プログラムは、認証サーバーを経由したデータの送受信をするための機能を備える専用アプリケーションプログラムであることが望ましい。
以上の構成により、取引当事者端末同士の間における電子商取引のためのデータ送受信において、専用アプリケーションを利用することにより、取引データを当事者間で共有することなく同質化することにより、取引当事者が自己の取引データをそれぞれ保管する。電子商取引及び既存の取引における電子商取引環境および既存の取引環境における、不特定多数の経済主体を前提とした取引照合から決済の一連のプロセスにおけるネットワークと、その管理システムにおいて、取引当事者一方の電子化された取引データを送受信することにより、他の取引当事者の入力業務を軽減し、かつ、下データと修正データとの照合機能を有する専用アプリケーションにより、個々の取引当事者が電子取引データを共有することなく、データベース層（受信Ｂox）間の移動により、同質の電子取引データを保管、取引データを納品情報、決済情報、会計情報として利用することができる。
【００６２】
（金融機関システム）
次に、金融機関システムについて説明する。
本発明の電子商取引システムは、電子商取引用プログラムを備えるクライアント端末である取引当事者端末において操作により情報処理が行われるシステムであって、少なくとも複数の取引当事者端末と、前記取引当事者端末同士のデータ送受信を仲介するための認証サーバーと、前記取引当事者端末および認証サーバーを接続するネットワークとを含み構成されることはこれまでに説明したとおりである。
さらに、少なくともいずれか一の取引当事者の口座情報を管理する金融機関システムとを含み構成され、取引データを金融機関等が利用することができ、取引当事者にとっては決済や、残高管理などに連動して利用することができる。また、金融機関にとっても、重複するデータ入力や、取引内容・取引相手の確認などの手間を軽減することができる。
【００６３】
金融機関としては、銀行や郵政関連の金融機関などのほか、証券会社（総合口座など）、クレジットカード会社、リース会社、オンラインの各種金融機関や、さらに代引決済などを行う配送会社、コンビニエンスストア、その他狭義の金融機関以外の各種の機関を含めることができる。
前記認証サーバーが備える認証データ記憶手段は、各金融機関システムに関する情報と、当該金融機関システムを認証するための認証データを記憶する機能を備える。
また、前記取引当事者認証手段は、認証サーバーにアクセスする金融機関システム前記認証データを用いて照合することにより認証する機能を備える。
また、前記鍵情報変換手段は、いずれか一の取引当事者端末または金融機関システムから他の取引当事者端末または金融機関システムに取引データを送信する際に、送信側端末から送信された取引データに含まれるとともに、当該取引データを受信側端末が備える電子商取引用プログラムが参照可能にする鍵情報を変換する機能を備える。
また、前記取引データ中継手段は、いずれか一の取引当事者端末または金融機関システムから他の取引当事者端末または金融機関システムに取引データを送信する送信側の取引当事者端末から受信した取引データを受信側の取引当事者端末に送信する機能を備える。
すなわち、金融機関システムは、前述した取引当事者端末と同様の処理により、認証サーバーを経由して取引データの送受信を行い、認証サーバーにデータが蓄積しないようにされたものである。
取引当事者端末においては、さらに前記取引当事者の口座情報が記憶される。口座情報は、金融機関名、本支店名、金融機関コード、本支店コード、口座種類、口座番号、その他の口座情報などである。また、取引当事者ごとに、一つあるいは複数の金融機関に関する口座情報を記憶することができる。
また、各取引当事者端末においては、顧客（取引先）マスタ、商品マスタ、口座マスタ、手数料マスタ、会計処理マスタ等のマスタデータが記憶される。なお、口座マスタには、銀行口座情報（銀行・支店・口座番号）および当該口座残
高の上限、下限、目標残高を記憶し管理することが好ましい。
【００６４】
金融機関システムは、各金融機関の基幹システムや、基幹システムと連携して備えられるウェブアプリケーションシステム、オンライン金融機関システム、本発明の電子商取引システムと連携するための専用システム、その他の各種のコンピュータシステムであってよい。
金融機関システムは、前記取引当事者端末から送信された取引データを、データ送受信を仲介する認証サーバーから受信する取引データ受信手段を備えている。
また、取引当事者の口座データを、データ送受信を仲介する認証サーバーに対し送信する取引データ送信手段を備えている。
これらのデータ処理システム間における取引データの送受信により、残高や資金移動その他の口座データを取引当事者端末が備える電子商取引用プログラムが取得可能にされている。
前記取引当事者同士の取引データごとに、当該取引当事者の口座データを前記金融機関システムから前記認証サーバーを中継して取得することにより、当該取引当事者間の口座の資金移動情報をそれぞれの取引当事者端末において取得可能にされている。
取引当事者同士それぞれの利用する金融機関が異なる場合にも、同質化されるそれぞれの取引データは、認証サーバーを経由してそれぞれの金融機関システムに送信されるので、口座間の資金移動その他のやりとりが可能である。
金融機関システムへのデータ送受信に際しても、前述した取引当事者間のデータ送受信と同様に、認証、データ暗号化・復号化、鍵情報の交換などを行うことが望ましい。
【００６５】
取引データには、支払期限、支払予定日、納品期限、納品予定日、支払日、納品日、契約日、支払方法、口座情報の内の少なくともいずれかが含まれており、前記取引当事者端末または前記金融機関システムにおいて、契約書、請求書、納品書、領収書、支払通知書、未払通知書、その他の契約または支払または納品に関する帳票データとして出力可能にされている。
出力は、各取引当事者端末、あるいは金融機関システムにおいて行うことができる。
【００６６】
好ましくは、取引当事者端末において、前記金融機関システムから認証サーバーを中継して受信した口座データに基づき、口座残高と支払予定額とを比較して残高不足か否かのデータを取得可能にされていることが望ましい。
さらに、取引当事者端末が備える電子商取引用プログラムは、前記口座情報ごとの残高管理機能を備えることとすれば、前記取引データに基づく入金予定および出金予定を反映した、前記取引当事者または前記金融機関におけるキャッシュ・フロー予測を管理可能にされる。
【００６７】
このように、取引当事者端末において金融機関口座情報を備え、対応する口座の残高情報と資金移動情報を取得した後に、請求情報及び領収情報と照合し、結果を相手方取引当事者に通知することができる。
この口座情報により該当する口座管理機関にアクセスし、残高や資金移動の情報を取得する。請求情報については取引当事者の口座残高と請求予定額を比較して残高不足ならばその旨を通知し、領収情報については支払金額と支払先と領収情報を照合して不整合がないかチェックして取引当事者に通知する。
このため、取引当事者端末においては、相手方取引当事者の管理情報と、相手方取引当事者に対応付けて電子請求書ファイルおよび電子領収書ファイルの現物を格納する機能、電子請求書ファイルおよび電子領収書ファイルの詳細情報を取得して請求書及び領収書管理情報として格納する機能を備えることが好ましい。請求書や領収書が電子署名を施して暗号化された状態で送付する場合には、前記相手方取引当事者の管理情報に解読のための鍵情報を付与する。
【００６８】
また、請求書、領収書等の電子帳票を、別の運用機関システムにおいて発行するようにしてもよい。
取引当事者はあらかじめ運用機関と契約を結び、請求書・領収書の発行機関に対し、送付先として認証サーバーとこれを経由する取引当事者端末のアドレスを指定する。運用機関としては専門の預託機関の他に、クレジット会社や金融機関が代行することが想定される。契約時に、取引当事者の氏名または名称、住所、連絡先等の取引当事者情報と、当該運用機関システムを送付先として登録した相手方取引当事者の情報を取得し、取引当事者の識別番号と対応付けて取引当事者情報として格納する。請求書・領収書を暗号化して送付する相手方取引当事者がある場合には、その相手方取引当事者に対応する解読のための鍵を預かり、取引当事者識別番号および取引当事者と関連付けて格納する。
取引当事者が物品を購入し、支払いをクレジットや割賦で指定すると、発行機関ではその請求情報を請求書として発行し、認証サーバーに送信する。認証サーバーにおいては、データファイルの宛名名や送信元アドレスから、受信した情報の発行元と請求対象者である取引当事者の情報を取得して対応する取引当事者を特定し、請求書ファイルを格納する。さらに請求書ファイルを開いて請求情報を取得し、管理データベースに格納する。領収書についても同様の処理を行う。システムは定期的に請求情報と領収情報の照合を行い、請求に対する領収が存在するか確認する。照合結果は不整合の有無やまたは個別の照合結果情報として取引当事者に通知する。また、取引当事者がアクセスして随時情報を確認できる手段も提供する。
【００６９】
さらに本発明の好ましい形態に一例によれば、前記取引当事者端末が備える電子商取引用プログラムは、前記取引当事者の複数の口座情報ごとの残高管理機能を備え、残高情報、入金予定情報、口座振替手数料の内の少なくともいずれかを参照して自動口座選択が可能にされている。
また、別の好ましい形態の一例によれば、前記取引当事者端末が備える電子商取引用プログラムは、前記取引当事者の複数の口座情報ごとの残高管理機能を備えるとともに、さらにあらかじめ当該複数の口座ごとに適正残高範囲が設定可能にされている。
また、別の好ましい形態の一例によれば、取引当事者の複数の口座情報ごとの残高情報を制約条件として、口座振替手数料を最小化する支払利用口座の組み合わせの自動選択が可能にされている。
これらの処理の具体的な一例については、以下の実施例において適宜、説明する。
【実施例】
【００７０】
以下、本発明のシステムの好ましい実施形態と、その基本的な処理の流れの一例について説明する。なお、ここに示す処理の流れは一例であって、これに限定されるものではなく、様々な応用や変形が可能である。
【００７１】
図２は、本発明の電子商取引システムの好ましい実施形態の一例を示す図である。
取引当事者間(企業間又は企業と家庭)が専用アプリケーションを利用することにより、ネットワーク上の認証サーバーを経由したシステムにおける電子取引一連のプロセスの方法であって、専用アプリケーションを利用することにより、取引の初期段階から当事者が必要十分な完全な電子取引データを当事者間で共有することなく同質化するという特徴とする。
認証サーバーは、これまでに説明したように、利用者である取引当事者の名称や電子メールアドレス、ＩＰアドレス等の取引当事者に関する情報と、暗号化された電子的な取引データを開錠するためのパスワードなどの認証データがマスター登録されている認証サーバーであり、暗号化された電子取引データを開錠するための開錠期キー（パスワード等の認証データ）について、送信元の開錠キーから受信者の開錠キーへ変換する機能を有する。
また、各取引当事者端末が備える電子商取引用プログラムは、専用アプリケーションプログラムであることが好ましく、各取引当事者・金融機関システムを含む各経済主体の端末に設定されている暗号化データ通信可能で受信データと既存保管データとの照合機能及び自動口座振替機能等を有するソフトウェアである。大きく分類すると企業用・家庭用・銀行用に分類することができる。
【００７２】
なお、本発明のシステムにおける電子取引データの分類の一例を図８に示す。ここでは説明の便宜上、電子取引データを下記の6つに分類する。
未確定取引データとは、電子化された取引内容について取引当事者間で合意前の電子取引データである。発注・受注段階において、当事者が取引データを入力した段階であり、入力データの正確性は合意が得られていない段階の電子取引データである。
また、確定取引データとは、電子化された取引内容について取引当事者間で合意された電子取引データである。発注及び受注した取引について、電子化された取引内容について取引当事者の合意がなされた電子取引データである。
また、納品予定データとは、納品予定日・納品場所等について確定している電子取引データである。
また、納品（検収）済みデータとは、納品について検収が完了したデータである。納品後、納品されたことを企業Ｂ（買い手)が確認した電子取引データである。
また、未確定決済予定データとは、支払先口座情報や支払期限等の決済条件について未確定である電子取引データである。
また、確定決済予定データとは、決済予定日及び指定入金口座情報が反映されている電子取引データである。
また、取引完了（決済済み）データとは、決済が完了した電子取引データである。
【００７３】
図３は、電子商取引用プログラムが参照する取引データのデータ階層の一例を示す模式図である。
未確定電子取引データ層には、電子取引データについて売り手と買い手が合意していないデータが保管される。データ化された取引データに取引当事者が合意したら、確定電子取引データ層に移る。
確定電子取引データ層には、決済データ以外の電子データについて合意したデータが保管される。決済のための口座データや決済日が確定すると未確定決済予定データ層に移る。また、企業の会計システムへ自動的に仕訳がエントリーされる。
未確定決済予定データは、決済予定日ごとに分類され、当該企業にとって最適な利用支払口座が決定され、当該電子データは確定決済予定データ層へ移り、取扱銀行端末に支払依頼データとして伝達される。
決済日において取扱銀行から、決済完了のデータが当該企業の端末に伝達され、決済済みデータ層に移る。決済済みデータ層に移った電子取引データについて、当該企業の会計システムへ自動的にエントリーされる。
【００７４】
これらの取引データは、取引当事者端末において自動会計処理に利用することができる。
取引当事者端末においては、未確定取引データ層、確定取引データ層、未確定決済予定データ層、確定決済予定データ層に格納された電子的な取引データについて、勘定マスターに登録された債権債務勘定が相手勘定として自動エントリーされる。また、決済完了データ層に格納された電子取引データにより、上記債権債務勘定を預金勘定へ振り替える。
スケジュール（明細表）の作成及びエントリー機能、総勘定元帳及び試算表等の自動作成機能、財務諸表等、財務書類等及びの作成(Reporting機能）などを、電子商取引用プログラムあるいはこれと連携して取引データを取り込み可能な会計プログラム等の他のプログラムまたは既存システムが備えることが好ましい。
【００７５】
本実施形態における「リアルタイムの取引内容照合から決済・残高管理さらに会計システムへのエントリーまでのプロセスにおける情報を管理・保管する情報管理システム」の運用例について説明する。
ここでは、企業Ｂの売り手であり、かつ企業Ｃの買い手である企業Ａを中心に説明をしていく。すなわち、各取引当事者について説明すると、
企業Ａ：企業Ｂに対する売り手またはサービス提供する主体であり、また、企業Ｃの買い手またはサービス利用者である。
企業Ｂ：企業Ａに対する買い手またはサービス利用者である。
企業Ｃ：企業Ａに対する売り手またはサービス提供者である。
【００７６】
また、ここでは決済機関を金融機関のほかクレジット会社を例にとって説明する。
金融機関Ｅ：金融機関
金融機関Ｆ：金融機関
金融機関Ｇ：金融機関
また、認証サーバーには、本発明のシステムを利用する取引当事者に関する顧客情報の他、利用者のアドレス及び利用者が使用しているアプリケーション固有の開錠キーが登録されている。
【００７７】
初めに、取引当事者端末における取引データの入力について説明する。
対企業Ｂとの取引において、企業Ａ（売り手またはサービス提供者）は、企業Ｂとの取引内容を専用アプリケーションプログラムの入力画面を用いて取引データとして入力する。取引データの一例は、取引日、取引先コード、取引先、商品コード、商品、単価、数量、単位、金額、自社入金口座、取引先支払口座、決済期限、入金日、取引先担当者、自社担当者などである。
【００７８】
取引データの代表的な形式の一例は、図４に一例が示されるような一覧表形式のものであり、一般的な表計算プログラムのように列データと行データに配列されている。
行データは取引ごとに配列され、列データには取引データ項目が配列される。
表計算プログラムと同様の入力方法も可能にすることにより、当該Ａpplication導入時におけるInterfaceが自動化されていない場合における企業の入力作業の軽減を図ることができる。
受注企業（企業Ａ）は取引データを作成し、取引番号、取引先名・取引先Ｃode、商品名・商品Ｃode、数量、単価、金額、取引日、決済日、決済方法（預金口座等）および勘定科目・勘定Ｃodeを電子的な取引データとして入力し、ネットワークサーバーを経由し、相手方取引当事者（企業Ｂ）に取引データを送信する。
【００７９】
次に、取引データの暗号化を行い送信する。
企業Ａ（売り手またはサービス提供者）は、取引データを専用アプリケーションプログラムにより当該プログラム固有の暗号鍵を用いて暗号化した後に送信する。当該暗号は、企業Ａの専用アプリケーションプログラム固有の鍵により開錠することができる。送信された取引データは、認証サーバーを経由するため、認証サーバーにおいて受信される。
図４を参照すると、個々の行データは電子メールデータとして、取引先Ｃodeに基づいて送信される。
【００８０】
次に、認証サーバーにおいては、鍵の交換処理を行う。
認証サーバーには、本発明のシステム利用者の取引当事者情報のほか、取引当事者の専用アプリケーションプログラムの暗号開錠キーが登録されている。
認証サーバーにおいて受信された取引データは、送信側取引当事者のアドレス情報等をキーにして、認証サーバーに登録されている取引当事者情報記憶手段から企業Ａの発信元アドレス情報等をキーにして認証サーバーにて開錠キーで開錠する一方で、送信先である受信側取引当事者のアドレス情報等をキーにして、認証サーバーに登録されている開錠キーに交換する。これにより、電子取引方法において、電子取引データは当該受信側取引当事者端末のアプリケーションプログラムでのみ開錠できることになる。
【００８１】
次に、取引データは受信側取引当事者端末において受信され、開錠される。
企業Ｂ（買い手またはサービス利用者）は、認証サーバーを経由した際に開錠キーが受信先である企業Ｂのアプリケーションプログラムの開錠キーに変換された、企業Ａの送信した取引データを受信する。受信した取引データは、企業Ｂの専用アプリケーションの受信Ｂoxに格納される。
【００８２】
企業Ａが取引データ（未確定電子取引データ）を専用アプリケーションプログラムに入力した後（または企業Ａの専用ウェブサイトから専用アプリケーションプログラムにＡuto Ｆeedした後）に、認証サーバーを経由して、企業Ｂの専用アプリケーションプログラムに当該電子取引データが取り込まれ、企業Ａの入力セルの属性に基づいて一定の法則で企業ＢのセルにＡuto Ｆeedされる。
図５は、企業Ａの取引データを受信した企業Ｂが、企業Ｂの取引データに取り込まれた一例を示す図である。
企業Ａの入力セルの情報と同様のセル情報が企業Ｂの専用アプリケーションプログラムにＡuto Ｆeedされ、企業Ａの送信データ（専用アプリケーションプログラム固有のＩＤ等）に基づいて、企業Ｂの専用アプリケーションプログラムに企業Ａの文字が入力される。
【００８３】
図６は、データ同質化の一例を示す図である。
企業Ａより送信された未確定電子取引データが正しい場合には、企業Ｂは残りの項目（自社支払口座・支払予定日・自社担当者等）を入力し、送信する。受信した企業ＡはＡgreeボタンを押す等により承認する。企業ＡのＡgreeの返事について、企業ＢがＡgreeを押す等により承認すると、確定電子取引データとなる。
企業Ａより送信された未確定電子取引データに誤りがある場合、企業Ｂはその箇所を修正して送信する。企業Ａではアラームが鳴り、企業Ｂの修正箇所を取り込み、Ａgreeのボタンを押す。企業ＡのＡgreeの返事について、企業ＢもＡgreeした場合、確定電子取引データとなる。
企業Ｂの入力セルの情報と同様のセル情報が企業Ａの専用アプリケーションプログラムにＡuto Ｆeedされ、企業Ａの送信データ（専用アプリケーションプログラム固有のＩＤ等）に基づいて、企業Ｂの専用アプリケーションプログラムに企業Ｂの文字が入力される。
【００８４】
電子的な取引データを照合した結果、相違点があった場合には、相違点についてセルなどのデータ項目ごとまたは取引ごとに承認され、当該電子取引データは企業Ｂのアプリケーションプログラムが記憶するデータの未確定取引データ階層に格納される。取り込まれた結果は、自動的に企業Ａの専用アプリケーションプログラムに伝達される。
受信Ｂoxに受信した取引データは、既存の未確定取引データ階層に格納されている電子取引データとが照合され、既存の未確定取引データ階層にない場合または既存の未確定取引データ階層の電子取引データとセル項目などのデータ項目が異なる場合には、不一致部分が一覧になって表示される。
再度図４を参照すると、受信された行データ（電子メールデータ）は、受信Ｂoxに収納される。収納されたデータは、電子商取引用プログラムにより照合され、受信Ｂox内の取引データと照合され、差異は取引データ（列データ）ごと及び項目データ（行データ）ごとに表示される。
差異については、受信側で取り込むか否かを判断し、結果が送信元に伝達される。受信側の受信した電子取引データのうち、取り込まれなかった項目についてはアラームとして、色等により区別される。また、属性に従い、受信側の一覧表として表示される。
【００８５】
図７は、企業Ａより送信された未確定電子取引データに誤りがある場合において、企業Ｂがその箇所を修正して送信する一例を示す図である。
企業Ａではアラームが鳴り、企業Ｂの修正箇所を取り込み、Ａgreeのボタンを押す等により承認する。企業ＡのＡgreeの返事について、企業ＢもＡgreeした場合に、確定電子取引データとなる。最終入力者は相手方のＡgreeの返事の後で、Ａgreeすることになる。
【００８６】
上記のプロセスを繰り返すことにより、企業Ａと企業Ｂの未確定電子取引データはそれぞれのアプリケーションにおいて同質化され、相違点部分が解消される。
同質化された時点で最終変更者が取引を承認することにより、認証ＩＤが添付され、企業Ａ及び企業Ｂの電子取引データは確定取引データ層へ移管される。
確定取引データ層に移管された電子取引データは決済データ（支払期限、支払予定日等）以外はロックされ改竄することが不可能となる。
図８は、取引データが確定取引データ層へ移管されるまでの処理の概要を示す図である。
【００８７】
未確定電子取引データ層から確定電子取引データ層へ移った後、確定電子取引データについて、決済情報以外はロックがかかり、原則として修正できない。
また、確定電子取引データを修正した場合、修正履歴が残るとともに、再び未確定電子取引データ層に移動し、再度、取引先との送受信及び承認プロセス(同質化プロセス)を経て、確定電子取引データ層に移管される。
(取引当事者内部のコントロール)
確定データについては、ロックをかけることにより、原則、修正自体を抑制するとともに、例外として、修正が必要となった場合には、当該当事者内部の管理統制のため、修正履歴を残すことにより、事後的なコントロールを可能とすることにより、改竄を防止する。
(取引当事者間のコントロール)
確定電子取引データ層から未確定電子取引データ層に移管され、再度、相手方の修正内容の承認を求めることにより、当事者一方のみで修正することを抑制し、改竄を防止する機能です。
【００８８】
図９は、確定電子取引データまでの処理の流れの一例を示すフローチャートである。
企業Ａ（売り手）が電子的な取引データを入力し、企業Ｂ（買い手）にデータを送信する。
企業Ｂ（買い手）は、受信した取引データを取り込むか否かを選択する。なお、既に入力済みの取引データがある場合には、受信データと既入力データとが照合され、差異について一覧が表示される。
照合段階においては、電子取引データは入力セルの属性により、必ず一致するべきデータ、対照的なデータ、その他のデータに分類される。必ず一致するべきデータ、対照的なデータについて一致していない場合には、その旨を示す電子データが発信され、企業Ａと企業Ｂの端末の不一致箇所にアラームが鳴る、色が変わる等の警告を発する。取引データが一致した後に、アラームが解除され色が通常色に戻る。
すべての企業Ａと企業Ｂの電子取引データが一致した場合には、当該取引データは企業Ａと企業Ｂとの合意を取り付けた後に、確定電子取引データとして決済関連以外の項目は修正できないようにロックされる。
【００８９】
図１０および図１１は、納品と決済の関係の好ましい一例を示すフローチャートである。
取引の確認後、すなわち確定電子取引データとなった後の取引データは、納品と決済の関係により、３つの電子取引データ・フローに分類される。
（１）企業Ａ（売り手）の納品後、企業Ｂ（買い手）の検収後、決済予定日が確定し、決済される場合（後払いの場合）、「納品予定データ」・「検収済みデータ」・「決済予定データ」および「決済済みデータ」の順に形成される。
（２）入金確認後に商品・サービスが提供される場合（前払いの場合）、「決済予定データ」、「決済済みデータ」、「納品予定データ」および「検収済みデータ」の順に形成される。
（３）納品・サービスの提供と決済のタイミングが無差別の場合には、電子取引データはパラレルに形成される。すなわち、「決済予定データ」と「決済済みデータ」が形成される一方、「納品予定データ」と「検収済みデータ」が形成される。
【００９０】
次に、取引データ確定後の処理について説明する。
請求期限のデータを相手方取引当事者に送信するときは、企業Ａは確定取引データ層に格納された電子取引データに支払期限、指定入金金融機関口座を入力または顧客マスターデータから取り込んだ後に、企業Ｂに送信する。
相手方取引当事者端末においては、受信した支払期限および指定入金金融機関口座情報を有する取引データは、取引コードと認証ＩＤをキーとして、企業Ｂの確定取引データ層の当該確定取引データの取引コードにより検索される。検索された当該取引データについて、確定取引データ層に格納されている電子取引データに反映され、また、当該取引データは、未確定決済予定データに格納される。これらのデータは、企業Ｂのアプリケーションから一覧として表示される。
【００９１】
図１２は、これらの照合プロセスを繰り返し、入力ミスや誤認データを修正後、売り手と買い手が電子取引データに合意して確定し、決済予定電子データ、決済電子データへと処理される流れの一例を示す図である。
企業Ｂは、未確定決済予定データに収納された取引データに、支払予定日を入力または顧客マスターから取り込んで入力する。また、取引確定後または支払期限一定期限前になった場合、または口座残高が上限を超えた場合等には、支払予定日が自動的に入力されることにより、入力漏れを回避する機能を有することが望ましい。
未確定決済予定データについては、その後、企業Ｂ（買い手）の支払利用口座および支払予定日データが、登録データベースから、または直接入力され、当該データが企業Ａ（売り手）に送信されて通知され、取引先入金予定口座・入金予定日情報として処理される。
好ましくは、企業Ａのアプリケーションプログラムに、企業Ｂからの支払情報が企業Ａの入金予定情報として取り込まれたことを通知する信号が企業Ｂへ発信されるとともに、支払情報が取り込まれた企業Ａの未確定予定データは確定決済予定データとして格納される。企業Ｂの取引当事者端末においては、企業Ａに支払情報が取り込まれたことを通知する信号を受信した後に、当該未確定決済予定データは確定決済予定データとして格納される。
【００９２】
口座残高などの口座データは、金融機関システムからデータを取得することができ、口座データを取引当事者端末において管理することにより、入金予定のキャッシュ・フローを金融機関の口座ごとに管理することができる。
口座ごとの入金予定を反映した口座残高と、未確定取引データの支払予定日をキーにして支払口座を決定する。
【００９３】
図１３は、未確定決済予定データが、決済予定日ごとに分類され、当該企業にとって最適な利用支払口座が決定され、当該電子データは確定決済予定データ層へ移り、取扱銀行端末に支払依頼データとして伝達される処理の一例を示すフローチャートである。
確定電子取引データについて、同一取引先に債権債務を有するか、取引先Ｃodeにより検索する。
同一取引先Ｃodeが存在する場合には、Nettingされ、完全に相殺される項目については取引のマイナス金額の電子取引データが自動認識され、直近の決済データより相殺され、債権債務相殺差額の端数については、新たな電子取引データとして自動認識される。
相殺後の取引データについて、取引ポジション（売りまたは買い）により、それぞれ入金予定データまたは支払予定データとして分類される。入金予定データは入金予定日付ごとに分類され、かつ、入金口座ごとに集計される。一方、支払予定データも同様支払い予定日付ごとに分類された後、（自社）支払預金口座ごとに分類される。一方で、取引先支払予定日付ごとに分類し、銀行・支店・基準金額ごとの取り扱い件数を集計する。手数料率との積により、最適手数料が算定される。
最適化後に、（自社）支払預金口座ごとに再分類され、入金預金口座ごとに分類されることにより、予想預金口座残高が算定される。
【００９４】
次に、口座振込プロセスにおける銀行手数料最小化を計算による支払予定口座の自動選択処理について説明する。
取引当事者端末にある取引データと口座マスタ、口座情報、手数料マスタを利用して、支払口座の決定及び口座残高管理が自動化され、支払口座を自動選択する取引照合から決済までを自動的に行うことができる。
未確定決済予定データの支払予定口座を変数として、あらかじめ口座マスターに登録されている口座残高下限値、上限値、目標値、および手数料マスターに登録されているデータ、さらに入金予定データを反映した口座残高を利用して、未確定決済予定データごとに支払予定口座を決定する。
取引先である企業Ａには、支払予定データとして送信することにより、企業Ａの取引当事者端末において受信される。当該支払予定情報を取引コードをキーにして企業Ａのアプリケーションにある決済予定データと照合した後に、企業Ｂの支払予定情報が企業Ａの入金予定情報として反映される。
【００９５】
入金予定口座・入金予定日情報が反映された企業Ａの口座預金額をベースに、企業Ａの企業ＣへのＤＢに登録されている銀行口座振替手数料データと最低預金口座残高(Ｂuffer)データにより、企業Ａの銀行手数料を最小化する企業Ｃへの支払予定口座が決定される。また、支払予定日は（T+1）から決済期日まで自由に決定できる。
各企業は銀行とＣommitment契約（借越契約）を締結し、fail取引により決済できない場合には、銀行へ自動的に伝達される。
【００９６】
一例として具体的な演算を下記に示す。
未確定決済予定データ： Ａ, Ｂ, Ｃ, Ｄ, Ｅ
未確定決済予定データの金額： Vol (Ａ), Vol (Ｂ),  Vol (Ｃ), Vol (Ｄ), Vol (Ｅ)
支払予定口座：  X, Y, Z
口座残高下限値：  Min (X),  Min (Y), Min (Z)
口座残高上限値：  Max (X), Max
(Y), Min (Z)
口座残高目標値：  Target (X),
Target (Y), Target (Z)
とする。また、
入金予定データ反映後口座残高：  Ｂal’ (X), Ｂal’ (Y), Ｂal’ (Z)
最終口座残高：   Ｂal (X), Ｂal (Y), Ｂal (Z)
口座Xの手数料：  同一支店a円、同一銀行b円、他行c円（a≦b≦c)
口座Yの手数料：  同一支店a’円、同一銀行b’円、他行c’円（a’≦b’≦c’)
口座Zの手数料：  同一支店a’’円、同一銀行b’’円、他行c’’円(a’’≦b’’≦c’’)
とする。
支払口座Xによって未確定決済予定データＡが支払われる場合をfxＡとし、=0,1となる変数とする。(fxＡ=1のとき、fyＡ=fzＡ=0となる）
決済予定取引データはf*Vol(Ａ)となる。
【００９７】
未確定決済予定データの指定支払口座がについて最適な組み合わせを選択する。
Ａ：Xと同一銀行同一支店口座、Ｂ：Xと同一銀行他店口座、Ｃ：Yと同一銀行同一支店口座、Ｄ：Yと同一銀行他店口座、Ｅ：Zと同一銀行同一支店口座、Ｆ：Zと同一銀行他店支店口座、Ｇ：X,Y,Zと異なる銀行口座、であるとき、
Min (X,Y,Zの手数料）= a*fx(Vol(Ａ))+b*fx*(Vol(Ｂ))+・・・・・・・・+c’’fz*(Vol(Ｇ))
Ｂal (X)=fx*Vol (Ａ) +fx*Vol(Ｂ)+fx*Vol (Ｅ)-(a*fx(Vol(Ａ))+・・・・・+c*fx(Vol(Ｇ))
制約条件：Min(X)≦Ｂal(X)≦Max(X)、
適合性：Min(Taget(X)-Ｂal(X))
Ｂal (Y)とＢal (Z)も同様にして、未確定決済予定データＡの支払予定口座組み合わせ考える(fxＡ=1, fyＡ=fzＡ=0)。
他の未確定決済予定データも同様である。
組み合わせは口座数の未確定決済データ数乗数通りの組み合わせが存在する。
上記制約条件の範囲内で、かつ、手数料が最小化される組み合わせを決定する。手数料が最小化される組み合わせが複数存在する場合、適合性がよいもの等のように優先順位を決定する。
【００９８】
次に、金融機関システムへの振込依頼処理について説明する。
確定決済予定データによる口座振込依頼は、企業Ｂの確定決済予定データが、金融機関Ｂに振込依頼データとして送信されることにより行われる。
金融機関システムにおいては、企業Ｂより受信した振込依頼データを支払予定日ごと、支払口座ごとに集計し、当該支払依頼情報を振込用紙に印刷する。振込完了後、振込完了の確認ボタンを押すなどの取引データごとの確認処理により、振込完了を示す通知が企業Ｂの取引当事者端末に送信され通知される。または、銀行用アプリケーションプログラムと企業Ｂの基幹システムとを接続することにより、データの送受信が可能となり、上記の手続きを自動化するようにしてもよい。
企業Ｂの取引当事者端末においては、金融機関Ｂからの振込依頼通知データを受信し、企業Ｂのアプリケーションの確定決済データと照合し、当該データを取引完了データとして格納する。
【００９９】
図１４は、これまでに説明した本発明のシステムの処理の全体像を示す図である。
取引当事者は、電子請求書などの電子的な帳票管理と、口座データを利用した残高照合管理をすることができる。
認証サーバーにおいて各企業の企業Ｃodeと当該企業の取引当事者端末のアドレス等が登録されており、送信された電子的な取引データのうち、送信側取引当事者企業のＣodeと当該取引当事者端末のアドレスと、認証サーバーの取引当事者情報記憶手段に登録されたデータとを照合し、一致していた場合のみ送信先へ電子取引データを送信する。
受注企業（企業Ａ）は取引データを作成し、取引番号、取引先名・取引先Ｃode、商品名・商品Ｃode、数量、単価、金額、取引日、決済日、決済方法（預金口座等）および勘定科目・勘定Ｃodeを取引データとして、電子商取引用プログラムのメーラー機能を用いて入力し、認証サーバーを経由して相手方取引当事者企業（企業Ｂ）に取引データを送信する。
一方、発注企業（企業Ｂ）は、取引データを作成し、取引番号、取引先名・取引先Ｃode、商品名・商品Ｃode、数量、単価、金額、取引日、決済日、決済方法（預金口座等）および勘定科目・勘定Ｃodeを取引データとして、電子商取引用プログラムのメーラー機能を用いて入力し、認証サーバーを経由して相手方取引当事者企業（企業Ａ）に取引データを送信する。
企業Ａと企業Ｂの各社は相手企業からの電子取引データを受信して、それぞれの電子商取引用プログラムが参照するように記憶されている電子取引データと相手方から受信した電子取引データの照合を行う。取引データの照合において、不一致の場合には、自動的に相手方にエラーメッセージが送信される。取引データが一致の有無を確認し、取引内容を確認する。
電子取引データの一致を確認した後に、当該電子取引データをもとに企業Ａでは売上証憑がアウトプットされるとともに、製造部門に電子取引データが送信される。一方、企業Ｂでは購買証憑及び請求書がアウトプットされるとともに、倉庫部門等に当該電子取引データが送信される。
すべての電子取引データは電子データとしてファイルされ、取引先ごと取引先ごとなどの入力項目に呼び出すことができる。
支払日において、月末及び年度末において残高照合部門において残高照合が実施される。
【０１００】
以上、詳細に説明した本発明のシステムにおいて、電子商取引用プログラムは、専用のアプリケーションプログラムであることを特徴としているが望ましい。好ましい電子商取引用プログラムの代表的な一例は、これまでに説明した下記の各機能を備えるものである。
（１）取引データ更新、参照機能
データを作成、更新する機能で、一覧リストからの入力と一括入力でき、各データの帳票印刷、表示条件を指定しての表示ができる。
（外部的要件）
取引データを登録、修正、削除することができる。
データは取引日、取引先、商品、勘定科目単位でそれぞれ管理される。
新規データの作成は請求する側のみ作成可能で受取側とその後のやり取りは更新のみでステータスを変化させていく方法とする。また確定された取引データは両側のデータともロックされる。
リスト上から直接一覧リストへの入力できる。
規定のフォーマットでのクリップボードデータ（コピーデータ）を用いて一括入力することができる。
各種データの一覧、個別帳票(請求書、領収書／カスタマイズ可能)を印刷することができる。
全修正履歴の一覧を表示、印刷することができる。
決済予定データを銀行口座、入金予定日、出金予定日ごとに集計表示(ソート)がすることができる。
【０１０１】
（２）取引データ送受信機能
取引データを送受信する機能である。
（外部的要件）
最新の送受信状況データを一覧リストで確認することができる。
最新データを取引相手に送信する機能と取引相手の最新データを受信することができる。
新規登録請求データの取引コードの割り当ては1取引コード単位で、中央サーバーより割り当てられる。
送受信の方法としては、認証サーバーを経由しデータの暗号化を行って通信を行う。
【０１０２】
（３）取引データ照合機能
送受信された最新のデータを照合し双方のデータを同質化できる機能である。
（外部的要件）
（２）の取引データ送受信機能で最新の情報として送受信されたデータを照合することができる。
データの不整合項目をリストのセルの色を変化させることにより通知し、ユーザーの判断でどちらのデータを最新データとして扱うかを比較して決定することができる。
【０１０３】
（４）マスター情報設定機能
各マスター情報を設定する。
（外部要件）
取引先情報を設定することができる。
口座情報を設定することができる。（上限及び下限も含む）
勘定科目を設定することができる。
ネットワーク利用者情報を設定することができる。（最新情報をサーバーより取込可）
承認権限情報を設定できる。
帳票レイアウトを設定できる。
支払予定日を設定できる。
手数料データを設定できる(最新情報をサーバーより取込可)
【０１０４】
（５）口座残高管理機能
マスターに設定されている上限、下限をもとに銀行の口座残高を確認する機能である。
（外部要件）
口座残高が上限、および下限を超えた場合画面に通知を行う。
（６）銀行手数料最小化機能
出金データに対して相手の指定口座への支払の場合、最適な口座手数料の銀行、支店名を通知する。
（外部要件）
出金対象データに対し、最適な口座手数料の銀行、支店名が表示される。
支店単位、出金日単位それぞれの帳票印刷ができる。
【０１０５】
（７）決済予定データ転送機能(口座振込依頼機能)
日単位の出金予定データの情報を銀行へ振り込み依頼情報をして通知する。 
（外部要件）
振込み依頼情報を帳票出力ができる。
支店単位、出金日単位それぞれの帳票印刷ができる。
各支店への振込依頼通知が送信できる。
（８）債権債務・銀行口座残高照合機能
照合済みの取引データを取引先ごとに取引高・債権債務残高を集計し、互いに通知される。
金融機関より残高を送信・通知される。
相手先より受信した残高データは自社残高データと照合される。
（外部要件）
自社残高と確認残高が一覧を出力ができる。
【０１０６】
（９）残高不足通知機能
一時的に口座残高がマイナスになる場合に、あらかじめＣommitment契約を行っている金融機関に通知する機能である。
(外部要件)  利用者のキャッシュ・フロー情報が取引金融機関に転送される。
（１０）暗号化
電子取引データ送受信の際、取引データを暗号化する機能である。
（外部要件）
暗号化と開錠キーを設定する。
【産業上の利用可能性】
【０１０７】
以上詳細に説明したように、本発明によれば、上記の様々な課題を解決し、多数の経済主体（企業・家庭・金融機関）の金銭取引及び非金銭取引においてが、電子取引データを共有化せずに各々の経済主体が保有しつつ、かつ、電子取引データを同質化することにより、リアルタイムの取引内容照合から決済・残高管理さらに会計システムへのエントリーまでのプロセスにおける情報を管理・保管する電子商取引システムを提供することができる。
各経済主体が取引データをそれぞれ保有しつつ、かつ、電子取引データの同質化を図るとともに、取引当事者間のみで同質の電子取引データを保有することより、取引から決済及び残高管理までの一連の取引サイクルにおいて、機密性の高い取引内容が第三者であるサーバー管理者に取引データが蓄積されることなく、取引当事者にとって安全性が高く情報漏洩リスクを軽減でき、業務効率を改善するシステムを提供することができる。
さらに、取引証憑に基づいて当事者のそれぞれが取引データを入力し、または請求書に基づいて取引データを入力する手間と時間を軽減し、しかもすべての取引データは専用アプリケーションにおいて電子データとして一元管理することにより、データ入力コストと証憑保管コストを削減することの可能なシステムを提供することが可能になる。
さらに、当日の予想キャッシュ・フローの算定及び資金運用・調達が効率化されるシステムを提供することが可能になる。
【図面の簡単な説明】
【０１０８】
【図１】本発明のシステムの基本的な構成の一例を示すシステム構成図である。
【図２】本発明の電子商取引システムの好ましい実施形態の一例を示す図である。
【図３】電子商取引用プログラムが参照する取引データのデータ階層の一例を示す模式図である。
【図４】一覧表形式である取引データの代表的な形式の一例を示す図である。
【図５】企業Ａの取引データを受信した企業Ｂが、企業Ｂの取引データに取り込まれた一例を示す図である。
【図６】データ同質化の一例を示す図である。
【図７】企業Ａより送信された未確定電子取引データに誤りがある場合において、企業Ｂがその箇所を修正して送信する一例を示す図である。
【図８】取引データが確定取引データ層へ移管されるまでの処理の概要を示す図である。
【図９】確定電子取引データまでの処理の流れの一例を示すフローチャートである。
【図１０】納品と決済の関係の好ましい一例を示すフローチャートである。
【図１１】納品と決済の関係の好ましい一例を示すフローチャートである。
【図１２】売り手と買い手が電子取引データに合意して確定し、決済予定電子データ、決済電子データへと処理される流れの一例を示す図である。
【図１３】未確定決済予定データが、決済予定日ごとに分類され、当該企業にとって最適な利用支払口座が決定され、当該電子データは確定決済予定データ層へ移り、取扱銀行端末に支払依頼データとして伝達される処理の一例を示すフローチャートである。
【図１４】本発明のシステムの処理の全体像を示す図である。
【図３】
2005316534.tif 000003
【図４】
2005316534.tif 000004
【図５】
2005316534.tif 000005
【図６】
2005316534.tif 000006
【図７】
2005316534.tif 000007
【図８】
2005316534.tif 000008
【図９】
2005316534.tif 000009
【図１０】
2005316534.tif 000010
【図１１】
2005316534.tif 000011
【図１２】
2005316534.tif 000012
【図１３】
2005316534.tif 000013
【図１４】
2005316534.tif 000014
【図１】
2005316534.tif 000015
【図２】
2005316534.tif 000016