米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 株式会社日本興業銀行

発明の名称 電子取引システムおよび電子取引方法
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2001−125959(P2001−125959A)
公開日 平成13年5月11日(2001.5.11)
出願番号 特願平11−301825
出願日 平成11年10月25日(1999.10.25)
代理人 【識別番号】100102336
【弁理士】
【氏名又は名称】久保田 直樹 (外1名)
【テーマコード(参考)】
5B049
【Fターム(参考)】
5B049 BB11 CC05 DD01 EE05 FF01 GG02 
発明者 岩崎 豊
要約 目的


構成
特許請求の範囲
【請求項1】取引に関する情報を電子的にやり取りする電子取引システムにおいて、デリミタとして指定した特定の記号により任意の文字列を囲んだタグによって、タグと対応する情報の種別を識別可能に構成したテキストファイルから成るフォーマットにより取引に関する情報を表現した取引情報を生成する生成手段と、前記取引情報を記録する記録手段と取引の進行に基づき、前記記録手段に記録されている取引情報を更新する更新手段と、を備えたことを特徴とする電子取引システム。
【請求項2】前記更新手段は、前記取引の進行と対応して、前記取引情報に新たなタグを追加し、新たな取引に関する情報を前記タグと対応して記入することを特徴とする請求項1に記載の電子取引システム。
【請求項3】前記更新手段は、前記取引の各段階と対応して、一つ前の段階の前記取引情報の末尾に新たな取引段階を示すタグを追加し、当該段階における取引に関する情報を前記新たな取引段階を示すタグによって囲まれた領域に記入することを特徴とする請求項2に記載の電子取引システム。
【請求項4】前記更新手段は、取引の業種情報および取引の現在の状態情報に基づき、新たに入力された取引情報に対して、為すべき処理および移行すべき状態に関する情報を出力するワークフロー処理手段を備えたことを特徴とする請求項1に記載の電子取引システム。
【請求項5】前記ワークフロー処理手段は、業種毎に設けられた状態遷移テーブルに登録された処理および遷移の情報に基づき処理を実行すると共に、取引の任意の段階における期限管理および商品追跡管理を行うことを特徴とする請求項2に記載の電子取引システム。
【請求項6】取引に関する情報を電子的にやり取りする電子取引システムにおいて、デリミタとして指定した特定の記号により任意の文字列を囲んだタグによって、タグと対応する情報の種別を識別可能に構成したテキストファイルから成るフォーマットにより取引に関する情報を表現した取引情報を生成し、記録する工程と、前記取引の進行と対応して、前記取引情報に新たなタグを追加し、新たな取引に関する情報を前記タグと対応して記入することにより取引情報を更新する工程とを含むことを特徴とする電子取引方法。
発明の詳細な説明
【0001】
【発明の属する技術分野】本発明は電子取引システムおよび電子取引方法に関し、特に、取引の履歴情報の管理が容易な電子取引システムおよび電子取引方法に関する。
【0002】
【従来の技術】従来、例えば自動車の部品を輸入するような取引の場合、取引に関する注文書、注文請書、送り状などの取引に関する情報は全て紙の書類によって処理されていた。そして、各書類はそれぞれ個別にファイリングされ、1つの取引に関する情報を遡って検索する場合には、複数書類の日付、相手会社名、商品名、数量などの情報を目視にて照合して検索を行っていた。
【0003】
【発明が解決しようとする課題】上記したような従来のシステムでは、書類による管理が行われているために、取引に関する履歴情報を遡って検索することが非常に困難であるという問題点があった。また、取引書類の紛失や内容の改変等がないことをチェックするために多くの労力が必要であるという問題点もあった。本発明は、上記した従来の問題点を解決し、取引の履歴情報の管理が容易な電子取引システムおよび電子取引方法を提供することを目的とする。
【0004】
【課題を解決するための手段】本発明は、取引に関する情報を電子的にやり取りする電子取引システムにおいて、デリミタとして指定した特定の記号により任意の文字列を囲んだタグによって、タグと対応する情報の種別を識別可能に構成したテキストファイルから成るフォーマットにより取引に関する情報を表現した取引情報を生成する生成手段と、前記取引情報を記録する記録手段と、取引の進行に基づき、前記記録手段に記録されている取引情報を更新する更新手段とを備えたことを特徴とする。
【0005】本発明によれば、取引の進行に従って、テキストファイルに取引に関する情報を順次追加して記録していくので、取引の履歴情報が容易に保存、検索できる。また、タグを使用したテキスト形式のファイルを使用するので、専用のデータベースシステムが不要となり、ワープロやエディタ等の汎用ソフトウェアを使用することによって容易に内容を閲覧可能である。
【0006】
【発明の実施の形態】以下、本発明の実施の形態について、図を参照しながら詳細に説明する。図2は、本発明の電子取引システムのハードウェア構成を示すブロック図である。電子取引を行うEDI(Electoronic Data Interchange)センターを構成するEDIサーバ装置90はインターネット97を介して輸出者(債権者)処理装置91、輸入者(債務者)処理装置92、商社処理装置95、物流業者処理装置96と接続可能に構成されている。輸出者処理装置91およびEDIサーバ装置90と取引銀行である銀行処理装置94の間、および輸入者処理装置92およびEDIサーバ装置90と取引銀行である銀行処理装置93の間は周知のファームバンキング網98、99によって接続されている。更に、銀行処理装置93と銀行処理装置94の間は例えば全銀為替網等の周知の銀行間ネットワーク100によって接続されている。
【0007】なお、本発明を実施する上において、EDIサーバ装置90と銀行処理装置93、94との間をインターネット97において接続する必要はないが、ファームバンキング網98、99あるいは銀行間ネットワーク100の代わりにインターネット97を使用することも可能である。また、各装置間の通信に使用する通信網としてはインターネットに限らず、専用線、電話網、データ通信網など公知の任意の通信網を使用可能である。
【0008】EDIサーバ装置90のハードウェアについては、市販されている周知のサーバ装置等を使用可能であり、OS等のソフトウェアもWindowsNT(登録商標)や市販のサーバ用ソフトなどのソフトウェアを組み合わせて構成可能である。通信プロトコルとしては使用する通信網に対応して全銀手順、TCP/IP、HTTP、FTPなどの周知のプロトコルを組み合わせて使用することにより実施可能である。輸出者処理装置91、輸入者処理装置92、銀行処理装置93、94、商社処理装置95、物流業者処理装置96については、やはり市販のサーバ装置やパソコン、あるいは既存の任意のコンピュータシステムを使用可能である。
【0009】図3は、本発明の電子取引システムにおける取引に関するデータのやり取りの概要を示す説明図である。例えば輸入者がインターネット経由で注文書(P/O)をEDIセンターへ送信すると、EDIセンターにおいては、注文書データを記録すると共に、宛先の輸出者へ転送する。輸出者がこの注文を請け、注文請書(ACK)をEDIセンターに送信すると、EDIセンターにおいては、注文請書を対応する注文書データに追加する形で記録すると共に、宛先の輸入者へ転送する。同様に、パレット情報PAL、コンテナ情報CON、船積予定通知書ASN、貨物受取証B/L(Way bill)等の物流系の書類データがやり取りされる。
【0010】これとは別に、送り状INVの発送以降、金融系の書類データである請求書が送信される。輸入者はEDIセンターあるいは取引銀行に対して支払通知(依頼)を行い、輸出者は入金通知を受け取ると、入金(請求、売掛)の消し込み処理が行われる。なお、これらの金融系書類データの一部は、既存のファームバンキング網経由でやり取りしてもよい。
【0011】図1は、本発明のEDIセンター10およびユーザ側処理装置11、12の機能を示すブロック図である。EDIセンター10(90)と、例えば輸出者(債権者)であるユーザAの処理装置11(91)、輸入者(債務者)であるユーザBの処理装置12(92)とはインターネット13(97)によって接続可能に構成されている。そして、取引情報は全てEDIセンター10を経由して転送される。
【0012】EDIセンター10内の取引履歴データベース20には、各取引と対応して、後述するようなテキストファイル形式の履歴情報ファイルが格納されている。そして、例えば複数ファイルの中から指定した文字列を含むファイル全てを抽出する周知のフルテキストサーチツール(プログラム)を使用して、目的とする取引に関する履歴情報ファイルを抽出する。
【0013】各端末処理装置11、12から送信された取引情報は受信部23によって受信され、IDチェック部22に入力されて、後述するIDチェック処理が行われる。そして、IDが正常である取引情報はワークフロー処理部21に入力される。ワークフロー処理部21においては、後述するように、取引履歴データベース20および状態遷移テーブルデータベース31を参照して、入力された取引情報のチェックおよび転送、取引履歴の更新等を実行する。そして、転送すべき取引情報は送信部24を介して宛先のユーザ側処置装置に送信される。なお、受信部23、送信部24はSSLなどの周知の暗号化機能を備えていてもよい。
【0014】各端末処理装置11、12は例えば同じ機能を実装している。受信部26によって受信された取引情報は、フォーマット変換部27に入力され、取引データが抽出される。抽出された取引データは一旦記憶装置に格納されると共に、データ生成部28に入力される。データ生成部28においては、入力された取引情報を表示部30を介して表示装置に表示すると共に、必要に応じて受信した取引情報に対して生成すべき取引情報を入力する画面を表示する。ユーザから入力された取引情報は入力部29を介して読み込まれ、受信した情報およびユーザから入力された情報に基づき、送信すべき取引情報が合成される。合成された取引情報はフォーマット変換部27に入力されてフォーマット変換され、送信部25からEDIセンター10に向けて送信される。
【0015】図4は、本発明のEDIセンター10における処理の内容を示すフローチャートである。この処理は例えばEDIセンター10が任意の取引情報を受信するたびに起動される。S10においてはユーザ識別情報であるIDがチェックされる。即ち、端末処理装置11、12からのアクセスに関するIDをキーに、予め登録されているパスワードを検索し、登録パスワードとユーザにより入力されたパスワードとの一致をチェックする。そしてパスワードが不一致である場合には、切断処理に移行して接続を切断する。この機能は、図1のIDチェック部22に相当する。
【0016】S11においては、取引情報に必ず含まれているキー情報、即ち、例えば注文番号、アイテム番号、発注者名、受注者名の4つの情報に基づき、キー情報が一致する取引履歴情報が取引履歴データベース20に格納されているか否か調べ、ある場合には当該履歴情報を読み出す。S12においては、読み出した履歴情報と受信した取引情報とを照合し、一致すべき取引履歴データが一致しているか否かが判定される。そして、判定結果がエラーである場合にはエラー処理1に移行し、例えばエラーとなった原因の情報等を示したエラー通知書を送信元端末処理装置に対して送信する。一方、S12における判定結果がOKである場合にはS13に移行する。
【0017】S13においては、発注者あるいは受注者の属する業種の情報に基づき該当する状態遷移テーブルを読み出す。そして、読み出した履歴情報中の最新バージョンのステータス情報から判明する取引の現在の状態、受信した取引情報中の追加情報であるイベントデータの内容に基づいて、該当する状態遷移テーブルを検索し、イベントデータの正常性および実行すべき処理、移行すべき状態に関する情報を読み出す。S14においては、当該イベントデータが正常であるか否かが判定され、異常である場合にはエラー処理2に移行して、例えばエラーとなった原因の情報等を示したエラー通知書を送信元端末処理装置に対して送信する。一方、S14における判定結果が正常である場合にはS15に移行する。S15においては、履歴情報に、受信した取引情報を追加し、履歴情報を更新(保存)する。S16においては、受信した取引情報を宛先の端末処理装置へ転送する。S11〜S16の機能が図1のワークフロー処理部21に相当する。
【0018】図5は、本発明におけるユーザ側処理装置の処理内容を示すフローチャートである。S20においては、受信データのフォーマット変換を行い、取引情報を抽出する。S21においては、抽出した取引情報をハードディスク等の記憶装置に一旦格納すると共に、ユーザの閲覧操作に従って表示装置へ表示する。この際、当該取引情報に基づいて生成すべき取引情報の入力エリアも同時にあるいは操作に応じて表示する。そして、ユーザは画面の所定の入力エリアに取引情報を入力する。
【0019】S22においては、ユーザによって入力された取引情報を読み取り、S23においては、受信した取引情報および入力された取引情報に基づき、送信すべき取引情報を合成する。S24においては、合成された取引情報をフォーマット変換して送信データを生成する。S25においては送信データをEDIセンターへ送信する。
【0020】図7は、伝送あるいは蓄積される取引データの内容例を示す説明図である。取引データ40は例えばテキストデータであり、公知のページ記述言語であるXMLに類似したタグを利用して、1レコードで全ての取引データ履歴を保存、管理する構造を取る。タグは、取引内容を記述する文字列中で使用しない(使用禁止の)特定の記号(デリミタ:当実施例では”<”および”>”)で囲まれた固有の文字列(例えば<status>など)であり、2つの対応するタグ(例えば<status>と</status>)で囲まれた文字列(例えばPO:注文書など)が取引データの内容である。
【0021】取引データのフォーマットは、ヘッダ(header)41と内容(contents)42に分かれている。そして、ヘッダと内容のそれぞれは1つあるいは複数のバージョン(version)43〜45、46〜48を含んでいる。バージョンの後には、1から始まる通し番号が付与されており、各番号は取引データの発生した順序と対応している。そして、取引が各段階に進んだ時点で新たなバージョンが追加されていく。なお、業種等によって取引の状態遷移テーブルが異なるので、バージョン番号と取引の状態(ステータス)とは一致しない。
【0022】それぞれのバージョン内には項目が存在する。それぞれのバージョンはそのバージョンより数字が低いバージョンの項目内容を引き継ぐ。後のバージョンで同一項目がある場合は、前バージョンの項目内容を置き換える。また、内容を削除する場合は”DELETE”を記入する。取引データをこのような構造で伝送あるいは保存するので、1レコードで履歴管理を行うことができ、冗長性が無く、ポータブル性に富む。従って、各種書類データの作成、管理が容易になる。
【0023】次に、動作を説明する。図8は、取引において最初に生成される注文書データの表示、入力例を示す説明図である。図3に示すように、取引は注文書(P/O)の作成から始まる。ユーザが注文書を作成する場合には、指示に基づいてデータ生成部28が図8に示すような注文書作成画面を表示し、ユーザが所定の箇所にデータを書き込む(図8は書き込んだ後の状態を示している)ことにより作成される。あるいは、ユーザがEDIセンター10から、同じ受注者、部品に対する以前の注文書データを読み出して注文書作成画面にデフォルト値として設定しておき、書き替えが必要な部分のみを入力するようにしてもよい。作成された注文書データはフォーマット変換部27においてフォーマット変換される。
【0024】図9は、フォーマット変換された注文書データ例を示す説明図である。注文書データはEDIセンター10へ送信され、EDIセンター10においては前記した図4に示すような処理を実行し、受信した注文書データをそのまま取引履歴データベース20に格納すると共に、指定されている受注者の端末処理装置へ転送する。受注者側端末処理装置においては、前記したように図5に示すような処理が実行される。
【0025】図10は、受注者側端末処理装置において受信した注文書データに基づき、注文請書データを合成する例を示す説明図である。受信した注文書データは表示されると共に、送信データとしてコピーされる。そして新たなバージョンであるバージョン2のタグがバージョン1のタグの後ろに追加され、ステータス(<status>)と共に新たに入力された応答日付(<ack date>)や受注者参照番号(<sellersref no>)情報に関する項目(タグ+内容)がバージョン2のタグ間に追加、挿入される。
【0026】合成、変換された注文請書データはEDIセンター10へ送信され、EDIセンター10においては前記した図4に示すような処理を実行し、受信した注文請書データの正常性をチェックした後、取引履歴データベース20に格納すると共に、指定されている受注者の端末処理装置へ転送する。以上のような処理を繰り返すことによって取引が進行する。
【0027】図11は、取引における状態遷移の一例を示す説明図である。状態遷移のパターンは例えば業種毎に異なっている。この状態遷移例においては、1つの注文書(P/O)について複数の注文請書(ACK)が発生する可能性があり、更に1つの注文請書(ACK)について複数のパレット情報(PAL)が発生する可能性がある。そして、コンテナ情報(CON)は注文請書(ACK)と対応しており、船積予定通知書(ASN)は注文書(P/O)と対応している。なお、A/Nは入港通知、C/Nは通関通知である。
【0028】図12は、ワークフロー処理において使用される状態遷移テーブルの内容例を示す説明図である。この状態遷移テーブルは、図11に示した状態遷移に対応したテーブルである。テーブルの縦の列はそれぞれ1つの状態を示しており、横の行は発生するイベント(書類データ)を表している。例えば現在の状態がP/O(発注書が発行されている状態)であり、イベントとしてP/O ACKが発生した場合には、テーブルにおけるステータスP/Oの列とイベントP/O ACKの行の交点に示されている処理が実行される。即ち、バージョン2が指定された数だけsub#で分割され、ACK状態へ移行する。
【0029】図4のS13の処理において、例えば業種毎に、あるいは個々の企業毎に図12に示すような状態遷移テーブルを設けることにより、任意の取引形態に対応することができる。また、図11の状態遷移例において、P/OからC/Nまでの一連の商流系イベントに加えて、送り状INV以降の金融系のイベントである請求書や支払通知等のイベントが並行して発生する。従って、金融系イベントを処理するための状態遷移テーブルを別に設けてもよい。
【0030】図6は、本発明における取引データの内容の変更例を示す説明図である。ユーザが取引データを変更する場合には、変更すべき項目と対応するタグを使用して新しいデータを登録する。例えば、発注者が発注書(バージョン1)で指定した配送日時(<delivery date>)を受注者が変更する場合には、同じタグ(<delivery date>)を使用して配送日時情報を登録する。履歴情報の中に同じ項目(タグ)が複数ある場合には、最新(後ろ)のバージョンの項目(タグ)の内容が有効となる。
【0031】図13は、本発明における取引の処理の分割例を示す説明図である。図11に示すように、取引の途中で分割が発生する場合がある。このような場合には分割した取引と対応して複数のバージョン項目を設け、バージョンの通し番号に子番号を付けて記録する。図13においては、発注請書ACKにおいて発注をsub01とsub02の2つに分割した場合に、EDIセンターに記録される履歴情報の例を示しており、バージョン2が2.0と2.1の2つ生成され、それぞれにsub01とsub02の内容が記録されている。以上説明したような記録方式を採用することにより、実際の取引において発生する様々な状態に対応可能となる。
【0032】以上実施例を開示したが、本発明には以下に示すような変形例も考えられる。実施例においては、端末処理装置側において、タグを使用したフォーマットに変換して伝送する例を開示したが、本発明においては少なくともEDIセンター10において記録される取引情報のフォーマットがタグを使用したフォーマットであればよく、EDIセンターにフォーマット変換機能を備えれば、EDIセンターと端末処理装置間の伝送は固定長フォーマットなど任意のフォーマットで実施してもよい。EDIセンターから端末処理装置への取引情報の送信は、保管されている履歴情報全てを送信する必要はなく、必要事項のみ、即ちキー情報と次の取引情報を生成するために必要な情報のみでもよい。また、端末処理装置からEDIセンターへの取引情報の送信は、取引を特定するキー項目および更新/追加されたデータのみであってもよい。
【0033】実施例においてはXMLと類似したタグを使用する例を開示したが、例えば改行コードや次のタグまでの間の文字列が情報であると定義すれば、後ろのタグ(”/”を含むタグ)は省略可能である。なお、バージョンタグ内の各項目の順序は任意であってもよく、バージョン項目の順序も任意であってもよい。EDIセンターにおいては取引履歴データベース20として、例えばディスクの所定の領域に単に図7に示すようなファイルを保存し、キー情報となる文字列に基づき、当該領域をフルテキストサーチする例を開示したが、例えば新規の取引が発生するたびに通し番号等の固有な識別情報を発生し、該識別情報を取引情報ファイル内の1項目として記録するか、あるいはファイル名として使用することにより、検索等の処理がより容易となる。
【0034】実施例においては、取引データは必ずEDIセンター10を通り、データがEDIセンターに保存される例を開示したが、例えば、ユーザは取引データをEDIセンターと共に相手側処理装置に直接送信し、EDIセンターにおいては、受信した取引データを転送せずにチェックと保存のみ行うようにしてもよい。このようにすれば、EDIセンターの処理負荷は小さくなる。更に、ユーザは全ての履歴情報を含む取引データを相手側処理装置に直接送信するようにしてもよい。このようにすれば、EDIセンターなしでも本発明を実施可能である。
【0035】記録される履歴情報には各取引データの受信日付(バージョン毎の日付情報)の項目を含むようにしてもよい。また、状態遷移テーブルにおいてエラーとされるイベントが発生した場合に、該エラーイベントに関する情報をエラー情報専用タグを使用して記録するようにしてもよい。ワークフロー機能としては、イベントとして書類データの受信により起動される例を開示したが、例えば発注書に対して発注請書を10日以内に発行することになっている場合に、発注書の受信時に対応するタイマを起動し、10日経ってもEDIセンターにおいて発注請書が受信されない場合に、受注者に対して発注請書の発行の催促通知を出すような期限管理機能を付加してもよい。
【0036】実施例においては各端末処理装置において書類データを受信し、その書類データに応答する書類データを生成して送信する例を開示したが、端末側処理装置から自発的にEDIセンターに対して、取引情報の検索、閲覧を行う機能を備えていてもい。このような機能によって、過去の取引の履歴を参照したり、発送した部品の現在の位置や状態を任意の関係者が追跡することができる。なお、実施例においては車体メーカと部品メーカとの取引の例を挙げたが、本発明は任意の地域における任意数の業種の企業あるいは個人の取引に適用可能である。
【0037】
【発明の効果】以上のように、本発明においては、取引に関する情報を電子的にやり取りする電子取引システムにおいて、デリミタとして指定した特定の記号により任意の文字列を囲んだタグによって、タグと対応する情報の種別を識別可能に構成したテキストファイルから成るフォーマットにより取引に関する情報を表現した取引情報を生成する生成手段と、前記取引情報を記録する記録手段と、取引の進行に基づき、前記記録手段に記録されている取引情報を更新する更新手段とを備えたことを特徴とする。従って、本発明によれば、取引の進行に従って、テキストファイルに取引に関する情報を順次追加して記録していくので、取引の履歴情報が容易に保存、検索できるという効果がある。。また、タグを使用したテキスト形式のファイルを使用するので、記録するデータ長に制限がなく、また新規の項目を自由に追加可能である。という特徴もある。更に、専用のデータベースシステムが不要となり、ワープロやエディタ等の汎用ソフトウェアを使用することによって容易に内容を閲覧可能であるという効果もある。更に、EDIセンターにおいて取引情報を全て管理するので、改変や紛失等の心配がないという効果もある。




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013