JP3632845B2

JP3632845B2 - ファイル交換装置

Info

Publication number: JP3632845B2
Application number: JP2001105043A
Authority: JP
Inventors: 保夫大沼
Original assignee: Nihon Unisys Ltd
Current assignee: Biprogy Inc
Priority date: 2001-04-03
Filing date: 2001-04-03
Publication date: 2005-03-23
Anticipated expiration: 2021-04-03
Also published as: JP2002304341A

Description

【０００１】
【発明の属する技術分野】
本発明はネットワークを介したデータ交換システムに係り、とりわけ、ＥＤＩシステムにおける転送装置及び交換システムに関する。
【０００２】
【従来の技術】
近年、コンピュータネットワークを利用した、電子取引が活発化している。この電子商取引の一例として電子データ交換（ＥｌｅｃｔｒｏｎｉｃＤａｔａＩｎｔｅｒｃｈａｎｇｅ：ＥＤＩ）が普及している。このＥＤＩを使用すれば、取引先との間で受発注などのデータを送受信することができる。また、ＥＤＩの発展型として、Ｗｅｂ−ＥＤＩが知られている。このＷｅｂ−ＥＤＩでは、ＷｅｂサーバとＷｅｂブラウザを使用することで、ＨＴＭＬ形式で作成された受発注データなどを、インターネットを経由して取引先と送受信するものである。
【０００３】
これらのシステムは、特定企業間のデータ交換としてＥＤＩが使用され、一方、不特定の相手とのデータ交換には、Ｗｅｂ−ＥＤＩが使用され、いわゆるシステムの棲み分けがなされていた。
【０００４】
ところで、データ交換をする際には、予めデータ形式などを取り決めて、相互互換性を担保する必要がある。従来型のＥＤＩでは、この取り決めを３段階で行っていた。まず、国内規約として、交換の手順、交換の構造、様式及び使用文字コ−ド等について定めていた。次に取引業界ごとの規約として、交換するデータの種類、内容及び意味などを標準メッセージとして定めていた。そして、それ以外の運用と取引に関する事項は参加企業間で定めていた。
【０００５】
【発明が解決しようとする課題】
従来型のＥＤＩでは、実際の運用に際して、上記の標準仕様に加え、企業独自の内容が付加され、標準仕様が遵守されないケースが多々見受けられた。さらに、商取引の際に発生する付随の情報を交換するためのシステムを、ＥＤＩとは別のシステムにて構築する事例が多く発生していた。そのため、取引先の採用している独自仕様についても、自社のシステムを対応させる必要があった。とりわけ、新規取引先が増えたり、取引内容が部分的に変更されたりすると、システムやその運用の変更に迫られ、開発経費や運用経費がかさむ弊害があった。さらには、取引先ごとに個別のシステムを開発するためには、相当の開発期間が必要となり、新規取引先の参加や取引法式の変更に対してタイムリーに対応できない等の問題があった。
【０００６】
一方、Ｗｅｂ−ＥＤＩでは、サ−バ側にクライアントで利用されるプログラムを用意することで、クライアントとなる取引先にはインターネットに接続できる環境さえ用意すれば、Ｗｅｂ−ＥＤＩに参加できる利点がある。しかし、複数のサ−バや複数のＷｅｂ−ＥＤＩが存在する場合には、それらごとに、画面様式、入力方法及び操作方法が相違するため、入力ミスや商取引の成立解釈等の混乱が発生し、ひいては、商取引でのトラブルにつながる危険があった。
【０００７】
またＷｅｂ−ＥＤＩを採用する企業では、取引内容や取引環境が変更されると、従来型のＥＤＩと同じく、サ−バ側のシステム変更や運用変更を行わなければならず、開発経費、運用経費がかさむとの弊害がある。
【０００８】
さらに、インターネットを通信回線として利用するＥＤＩでは、インターネットが一般の利用者にも利用されるシステムゆえにセキュリティー上の問題があり、例えば、交換情報の盗聴、改ざん及びなりすまし等による被害が発生する危険がある。
【０００９】
なお、上述のデータ交換システムでは、商取引の成立に関して法上の到達主義を採用している。そのため、相手に取引メッセージが届いた時を取引の成立時刻として解釈する。従って、メッセージの取引時刻の確定は非常に重要な意味があり、通信の信頼性を十分に確保する必要がある。従来型のＥＤＩでは交換手順により信頼性を確保していた。これに対し、Ｗｅｂ−ＥＤＩでは、インターネットを利用しているため通信の信頼性が低く、商取引成立の確認を十分に保証できないとの問題を抱えていた。とりわけ、オ−プンなＥＤＩを採用する不特定な取引先との商取引では、そのオープン性ゆえに、内容照合方式や確認結果の交換方式を事前に定めておくことができない。このようなシステムでは、同一データを再度送付して、目で確認する方法を採用する傾向もあるが、同じ内容を複数回送付することは、企業間の二重取引となるとの有識者の指摘もあり解決策とはなっていない。
【００１０】
そこで、本願発明では、取引先の独自仕様に対しても容易に対応可能なデータ交換システムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
本願発明では、上記課題を解決すべく、第１の情報システムにおいて作成されたファイルをネットワークに接続された第２の情報システムへと送信するファイル交換装置において、前記第１の情報システムにおいて作成された複数の内部ファイルを記憶する第１の記憶装置と、前記第１の記憶装置に記憶された複数の前記内部ファイルから中間ファイルまたは前記第２の情報システムに送信するための送受ファイルを作成するための企業コード、ファイル名、および編集区分を記述したレジストリを記憶する第２の記憶装置と、前記第１の記憶装置に記憶されている複数の前記内部ファイルを順次読み出し、読み出した該内部ファイルが、送付先を記述したメッセージガイド情報を有さないファイル形式であるか、または該メッセージガイド情報を有するフォルダ形式であるかを判定する判定手段と、前記判定手段により前記内部ファイルが前記ファイル形式であると判定された場合には、該内部ファイルに含まれる送付先の情報に従って前記レジストリを特定し、一方、前記内部ファイルが前記フォルダ形式であると判定された場合には該内部ファイルの前記メッセージガイド情報に記述されている送付先に従って前記レジストリを特定し、それぞれ特定された該レジストリに含まれている企業コードおよびファイル名に従ったファイル名を付すことで、該内部ファイルから前記中間ファイルを作成して中間エリアに格納する格納手段と、前記中間エリアから前記中間ファイルを読み出し、読み出した該中間ファイルから前記第２の情報システムに送信するための送受ファイルを作成する際に、前記中間ファイルのファイル名に従って前記レジストリを特定し、特定された該レジストリに記述されている編集区分が、送付先が同一である複数の前記中間ファイルを一つにとりまとめることを指示している場合は、複数の前記中間ファイルを一つにとりまとめて送受ファイルを作成する送受ファイル作成手段と、作成された前記送受ファイルを前記第２の情報システムに送信する送信手段と
を備えることを特徴とする。
【００１５】
また、前記格納手段は、前記ファイル形式であると判定された前記内部ファイルに送付先の異なる複数の内部メッセージが含まれている場合は、該内部ファイルを該送付先ごとに分割する分割手段を含むようにしてもよい。
【００２９】
【発明の実施の形態】
［第１の実施形態］
本実施形態では、自己のシステムと取引先システムの間に、統合情報交換システムを設け、双方のシステムの相違を吸収するものである。システムの相違は、取引先ごとに異なるため、取引先ごと変換規則や交換規則を用意する。また、新たな取引先の追加や、既存の取引先のシステム変更に対応するためには、この変換規則又は交換規則を修正するだけで、比較的容易に対応可能である。
【００３０】
図１に本実施形態システム構成を示す。ある企業のイントラネット１５０には、複数のユーザ端末１０１が社内ＬＡＮ１０２を介して業務システム１００と接続されている。ユーザ端末１０１では、Ｗｅｂブラウザソフト、メールソフト及びＦＴＰ等の転送ソフトが実行され、当該ソフトを介して業務システム１００や統合情報交換システム１０３とファイルを送受信する。また、イントラネット１５０内には、ファイルサーバ１０４〜１０６が存在する。これらのファイルサーバは、ユーザ端末１０１、業務システム１００及び統合情報交換システム１０３によりファイルの記憶に利用される。なお、ファイルサーバを設ける代わりに、統合情報交換システム１０３などに内蔵されるハードディスクを利用してもよい。統合情報交換システム１０３は、任意の通信網１１０を介して、取引先のシステムと接続される。なお、本実施形態では、取引当事者のうち、データを送信する側を送付元と称し、取引の相手方、すなわち、データの受信側を送付先（１３０や１４０）と称することがある。なお、送付元から送付先１３０までの間に任意に中継先１２０を設けてもよい。
【００３１】
図２に、業務システム１００、ユーザ端末１０１、統合情報交換システム１０３、中継先１２０及び送付先１３０、１４０のコンピュータの構成を示す。
【００３２】
ＣＰＵ２００は、ハードディスクドライブ（ＨＤＤ）２０６に記憶された各種プログラムを実行する。ＲＡＭ２０１は、ランダムアクセスメモリであり、プログラムの実施に使用される。ＲＯＭ２０２は、リードオンリーメモリであり、コンピュータのＢＩＯＳ等が記憶されている。ディスプレイ２０３は、表示装置である。また、通信ＩＦ２０５はＬＡＮやインターネットへ接続するためのネットワークカード、モデム等の通信装置である。入力装置２０７はキーボードなどにより構成される。
【００３３】
さて、上述の構成に基づいて、送受レジストリと交換先レジストリを用いてＥＤＩ処理を実行する例を説明する。すなわち、送受レジストリと交換先レジストリは継続して取引を行う際に必要となるデータの変換規則やデータの交換規則についての情報集合である。より具体的には、送受レジストリとは、業務システム１００と統合情報交換システム間におけるファイルの編集処理に必要な制御情報を格納するものである。例えば、継続的に取引をしていると、取引相手に対して、業務システム１００で作成されたファイルをしばしば送信することがある。このような場合に、業務システム１００で作成されたファイルを統合情報交換システム１０３で処理できる様式に変更しなければならない。そこで、この様式の変更の際に、変更処理の基準となるデータを送受レジストリに格納するのである。一方、交換先レジストリは、交換先（中継先や送付先など）ごとにファイルを編集する際に必要となる制御情報を格納するものである。例えば、送受レジストリを参照してファイルが作成されると、次に、取引相手の仕様に合わせたファイルの変換処理が必要となる。そこで、取引相手ごとのファイル変換処理の基準となるデータを交換先レジストリに格納するのである。
【００３４】
これら２種類のレジストリは、要素名と、要素名に対応する値とが含まれており、ＸＭＬをベースとして記述される。ＸＭＬをベースとしているので、要素の記述順序は重要ではなく、自由に要素を選択したり、組み合わせたりすることが可能である。言い換えれば、拡張性に富んでいるため、取引先の追加や、取引先システムの変更に容易に対処することが可能となる。例えば、交換内容と送付先が増えた場合や、送付先のシステムに合わせて、従来型のＥＤＩとＷｅｂ−ＥＤＩとのいずれに切り替える場合も、そのレジストリ情報を追加または変更するだけで対応できる。さらに、今後の利用拡大にあたっては、要素を追加することにより対応できる。このように、データ交換のための接続部分のシステムは、送受レジストリ交換先レジストリに基づいて柔軟に処理することができる。
【００３５】
図３に送受レジストリの構成を示す。送受レジストリには、要素名３０１〜３０６とそれに対応する値が含まれている。送受区分３０１とは、送信に使用されるレジストリであるか、または、受信に使用されるレジストリであるかを示すものである。内部ファイル名３０２は、処理待ちエリア内の処理対象ファイル名である。交換先コード３０３とは、内部ファイルの交換先を示す企業コードであり、交換先レジストリに登録された取引先の企業コードと照合するため使用される。交換区分３０４とは、処理対象ファイルに含まれるメッセージの送信先がＶＡＮ、混在または単独であることを示すものである。分割区分３０５とは、送付前に送付先別の分割が必要か、または受信後に送付元の分割が必要かを示すものである。作成区分３０５とは、送付先が同一であるメッセージが内部ファイルに存在する場合に、これらを追記するか個別にファイルを作成して中間エリアに書き出すかを示すものである。
【００３６】
図４に交換先レジストリの構成を示す。交換先レジストリには、要素名４０１〜４０４とそれに対応する値が含まれている。企業コード４０１には、交換先の企業コードが値として格納される。交換先担当者名には、交換先の企業の窓口となる担当者名が値として格納される。交換先ｅ−ｍａｉｌ４０３には、交換先担当者のｅ−ｍａｉｌアドレスが値として格納される。明細部４０４は、要素名４１１〜４１８が格納される。内部ファイル名４１１には、中間エリアに格納されている処理対象ファイルの名称が値として格納される。送受ファイル名４１２には、外部交換用のファイル名が値として格納される。外部（ＶＡＮ会社など）では、このファイル名をもとに中継時の処理を判断する。交換方法４１３には、ＶＡＮ経由で送信するか、相手に直接送信するかが値として格納される。交換手順４１４には、使用するプロトコル名が値として格納される。交換方法４１５には、交換するファイルや交換するメッセージについての変換方法が値として格納される。編集区分４１６には、交換先が同一である複数のファイルを一つにまとめるか否かが値として格納される。送受ディレクトリ４１７には、処理結果を登録するためのディレクトリの名称が値として格納される。統合送付先４１８には、交換ファイルをまとめて他の交換先（ＶＡＮなど）に送付する際の、交換先の企業コードが値として格納される。
【００３７】
本実施形態では、ファイルのみを転送する場合は、ファイル名に基づいて送受レジストリと交換先レジストリを参照して処理を行う。
【００３８】
図５にイントラネット内における処理の概要を示す。業務システム１００やユーザ端末１０１により作成された内部ファイルは、まず、ファイルサーバの処理待ちエリア１０４に格納される。統合情報交換システム１０３は、任意のタイミングで内部ファイルを読み出して、送受レジストリに基づいて中間ファイルを作成する。作成された中間ファイルはファイルサーバの中間エリア１０５に記憶される。統合情報交換システム１０３は、任意のタイミングで中間ファイルを読み出して、交換先ディレクトリに基づいて送信ファイルを作成し、ファイルサーバの送付待ちエリア１０７に格納する。最後に、統合情報交換システム１０３は、任意のタイミングで送信ファイルを送付待ちエリアから読み出して、送付先に向けて送信する。
【００３９】
図６に処理待ちエリアに格納された内部ファイルを処理する際のフローチャートを示す。なお、あらかじめ送受レジストリと交換先レジストリはＥＤＩ管理者が作成しておくものとする。
【００４０】
統合情報交換システム１０３は、任意のタイミングで、内部ファイルを読み込む（Ｓ１０）。このタイミングは、定期的であってもよいし、ユーザの指示に基づくタイミングであってもよい。
図７に、処理待ちエリア１０４の記憶内容を示す。ファイルサーバ上の処理待ちエリア１０４には、ｇｙｏｕｍｕ１０という名称のファイルと、ｆｌｄｒ２０という名称のフォルダが格納されている。内部ファイルｇｙｏｕｍｕ１０は、業務処理システムで作成されたもので、１つのファイル内には少なくとも１つのメッセージが含まれている。各メッセージの先頭には、送付先情報が付加される。各メッセージは、分離記号で区切られ、図７に例示するように、送付先の異なるメッセージが混在することもある。
【００４１】
ｆｌｄｒ２０は、フォルダ形式の内部ファイルである。ｆｌｄｒ２０には、メッセージガイド情報、取引先に送信すべき主要情報及び複数の関連情報が含まれている。フォルダ形式の内部ファイルは、ユーザ端末１０１で作成されたものである。メッセージガイド情報とは、送受レジストリと同等の内容を有する情報に加え、さらに、取引相手先において実行してもらう処理の内容が記述されている。詳細については後述する。なお、メッセージガイド情報は、特有のファイル名を付すことで他のファイルとの識別を可能とする。例えば、ファイル名（あるいはファイル名の先頭ｎ個の文字）の命名規則をあらかじめ定めておけばよい。
【００４２】
統合情報交換システム１０３は、読み込んだファイルにメッセージガイド情報が含まれているか否かにより読み込んだものがファイル形式であるかフォルダ形式であるかを判断する（Ｓ１５）。
【００４３】
次に、統合情報交換システム１０３は、送受レジストリをファイルサーバ１０６から読み込む（Ｓ３０）。具体的には、統合情報交換システムは、処理待ちエリアから取出した内容がフォルダ形式でない場合は、ファイル名（内部ファイル名Ｎとする）を抽出し、送受レジストリの要素「内部ファイル名」の値が内部ファイル名Ｎと一致するような送受レジストリを検索する。図８に送受レジストリのデータ例を示す。この例によれば、処理の対象となっているファイルの名称「ｇｙｏｕｍｕ１」を、要素として有する「値１１」を備えた送受レジストリが選択される。
【００４４】
次に、選択された送受レジストリの”値１１”に記述されている「交換区分」と「分割区分」の値を参照する。図８の例に従えば、それぞれ”混在”、”分割”であり、この場合には、統合情報交換システム１０３は、処理対象の内部ファイルに複数のメッセージが含まれていると判断し、メッセージ単位に分割する処理を実行する（Ｓ４０）。図８の例では、内部ファイルｇｙｏｕｍｕ１０について、メッセージ１〜４を４つに分割する。
【００４５】
次に、Ｓ４０で得られたメッセージについて、メッセージの先頭に付加されている送付先情報を抽出する（Ｓ５０）。例えば、図７に示すメッセージ１の送付先は ”Ｆ１”である。
次に、Ｓ５０で抽出された送付先に対応する交換先レジストリを検索する（Ｓ６０）。図９に交換先レジストリの具体例を示す。例えば、交換先レジストリの「企業コード」と送付先とが一致するものを検索する。図９の例では、内部ファイルｇｙｏｕｍｕ１０におけるメッセージ１の送付先”Ｆ１”である”値２１”が求めるべき交換先レジストリである。
【００４６】
次に、交換先レジストリの「企業コード」の値と明細部の「内部ファイル名」の値に基づいて中間フィル名を作成する。例えば、”企業コード＋内部ファイル名”の如くである。さらに、作成されたファイル名でもって中間ファイルを書き出す（Ｓ７０）。なお、Ｓ３０で読み込んだ送受レジストリの「作成区分」の値が”追記”の場合であって、すでに同じ名称のファイルが中間エリアに存在していれば追記し、存在していなければ新しく作成する。図８の例では、内部ファイルｇｙｏｕｍｕ１０のメッセージ１の後にメッセージ４を追記し、中間エリア１０５に中間ファイル名”Ｆ１＋ｇｙｏｕｍｕ１０”として書き出す。また内部ファイルｇｙｏｕｍｕ１０のメッセージ２の後ろにメッセージ３を追記し、中間エリア１０５に中間ファイル名”Ｇ１＋ｇｙｏｕｍｕ１０”として書き出す。
【００４７】
Ｓ５０からＳ７０までの処理を全てのメッセージについて処理を行い（Ｓ８０）、さらに、全てのファイルについてＳ１０〜Ｓ８０までの処理を実行する（Ｓ９０）。
【００４８】
次に、統合情報交換システムは、中間エリア１０５に保存された中間ファイルを対象として、時間指定あるいは定期的に、送受ファイルを作成し、ファイルサーバの送付待ちエリア１０７に格納する。図１０に、中間エリア１０５のファイルを処理するためのフローチャートを示す。
【００４９】
まず、統合情報交換システム１０３は、Ｓ７０で書き出された中間ファイル（または中間フォルダ、以下同様）を中間エリア１０５から読み込む（Ｓ２１０）。
【００５０】
次に、読み込んだ中間ファイルのファイル名に基づいて交換先レジストリを探す（Ｓ２２０）。中間ファイルのファイル名は前述したように”企業コード＋内部ファイル名”である。そこで、このファイル名から＋を区切り記号として文字処理を行い、企業コードと内部ファイル名を取得し、交換先レジストリの要素「企業コード」の値と明細部の要素「内部ファイル名」の値が取得されたものと一致する交換先レジストリを検索する。
【００５１】
次に、Ｓ２１０の検索により抽出された交換先レジストリについて、その明細部の「編集区分」の値が”まとめ”となっているかを判定する（Ｓ２２５）。判定の結果、まとめ指定となっていれば、送付先が同一の中間ファイルを一つに編集する（Ｓ２３０）。他にまとめ処理の必要な中間ファイルがあるか判定し（Ｓ２３５）、あるなら中間エリア１０５から、まとめ処理の対象となる中間ファイルを読み込む（Ｓ２４０）。以下、全てのまとめ処理が終了するまで処理を継続する。
【００５２】
具体的なまとめ処理の例を以下に説明する。まとめ処理は、要素の値によってことなり、それぞれ、次のような処理を行う。
【００５３】
（１）交換先レジストリの明細部の「交換方法」の値が”直接”であり、「編集区分」の値が”まとめ”である場合
同じ明細部の要素名「送受ディレクトリ」の値と要素名「送受ファイル名」の値を得て記憶する。中間ファイル”Ｇ１＋ｇｙｏｕｍｕ１０”であれば、図９の交換先レジストリの”値２２”から要素名「送受ディレクトリ」の値”ｄ００２”と要素名「送受ファイル名」の値”ｓｎｄ２０”を得て記憶する。同一交換レジストリの他の明細部も参照し記憶した値と一致するものがあり、中間エリアに対応する未処理の中間ファイルが有れば、これも読み込んでとりまとめ対象とする。読み込んだとりまとめ対象の中間ファイルの内容すべてを、追記してとりまとめて記憶し、次のステップへ進む。
【００５４】
（２）交換先レジストリの明細部の「交換方法」の値が"VAN"であり、「編集区分」の値が"まとめ" である場合：
同じ明細部の要素名「送受ディレクトリ」の値と要素名「送受ファイル名」の値を得て記憶する。交換先レジストリの要素名「企業コード」の値(企業コードKとよぶ)をもとに、他の交換先レジストリを探す。他の交換先レジストリにおいて、「統合送付先」の値として企業コードKが登録されていれば(交換先レジストリRとよぶ)、ＶＡＮ経由による送付先の混合した一括送付であることがわかる。この場合に統合情報交換システムが行うとりまとめの処理について図９をもとに説明する。交換先レジストリ"値２３"の要素名「統合送付先」の値に"F1"が有るのでＶＡＮ経由による送付先の混合した一括送付であることがわかる。また要素名「企業コ−ド」の値が"VAN1"で要素名「送受ファイル名」の値が"van10"である事を知る。次に要素名「企業コード」の値が"F1"である交換先レジストリ"値２１"を参照し要素名「送受ファイル名」の値が同じ"van10"となっている明細部１をみつける。この明細部１の要素名「内部ファイル名」の値"gyoumu10"から中間ファイル"F1+gyoumu10"をＶＡＮ送付用としてとりまとめる必要があることがわかる。中間ファイル"F1+gyoumu10"が未処理なら、これを読み込んでとりまとめの対象とする。交換先レジストリ"値２１"の他の明細部の要素名「送受ファイル名」を参照し、「送受ファイル名」の値が同じ"van10"となっているものがあれば、対応する中間ファイルを読み込んでとりまとめ対象とする。同じ送受ファイル名"van10"にてとりまとめるべき中間ファイルが無くなるまでこれを繰り返す。交換先レジストリRの明細部の要素名「統合送付先」の値として、他のものが登録されていれば、これについても同様の処理を繰り返す。この処理が終了したら、読み込んだとりまとめ対象の中間ファイルの内容すべてを、追記してとりまとめて記憶し、次のステップへ進む。
【００５５】
次に、前のステップで記憶した中間ファイル（またはまとめ処理により作成されたファイル）の情報に対して、交換先レジストリの明細部「変換方法」の値に変換方法が指定されているかを判定する（S245)。変換方法が指定されていれば、指定の変換処理方法にて変換処理を実施する（S250）。図９の例では、交換先レジストリの「送受ファイル名」の値が"van10"と"send20"となっているものに対して、CIIシンタックスによる標準メッセージに変換する。"mail100"に対応するものついては主要情報"tmp20"の内容をＸＭＬに変換する。
【００５６】
最後に、以上の処理の施された送受ファイルを送付待ちエリア１０７に書き出す（Ｓ２６０）。具体的には、まず、「企業コード」の値と「送受ファイル名」の値から書き出しファイルのファイル名をファイル名”企業コード＋送受ファイル名”として作成する。続いて、交換先レジストリの「送付ディレクトリ」の値から、ファイルを書き出すべきディレクトリを抽出し、作成されたファイル名でもってファイルを書き出す。なお、書き出す場合に、同一ファイル名がすでに存在するか否かを確認し、存在すればすでに存在するファイルに追記する。存在していなければ、新たにファイルを作成する。図９の例では、”Ｖ００１”ディレクトリに、”ＶＡＮ１＋ｖａｎ１０”という名のファイルが格納される。また、”００２”のディレクトリには、”Ｇ２＋ｓｅｎｄ２０”という名のファイルが格納される。さらに、”ｍ０１０” のディレクトリには”Ｆ１＋ｍａｉｌ１００”という名のフォルダが格納される。
送付待ちエリアの送受ファイルは、定時的にあるいは一定間隔ごとに、交換先レジストリを参照して編集されてデータ交換のために外部へ送信される。
【００５７】
本発明によれば、新規送付先が増えた場合には、新規送付先に関する情報を交換先レジストリに登録するだけでよい。また取引方式が一部変更された場合には、送受レジストリ及び／または交換先レジストリの明細部に必要な修正を行えばよい。なお、新たなレジストリと置換してもよい。
【００５８】
また、従来型のＥＤＩ、Ｗｅｂ−ＥＤＩ又はメールＥＤＩへとシステムを切り替える場合には、そのレジストリ情報を追加または変更するだけで対応できる。これら２種類のレジストリは、ＸＭＬをベースにした要素名と値でもって記述されるため、順序に関係なく要素を選択したり、組み合わせたりすることが可能である。
【００５９】
また今後の利用拡大にあたっては、要素の追加により容易に対応できる。このように、データ交換のための接続部分のシステムは、送受レジストリ、交換先レジストリをもとにして、柔軟に処理をおこなうことができる。システム変更や運用変更を行う必要が無いのでタイムリーにかつ少ない費用で対応できる。
【００６０】
［第２の実施形態］
本実施形態では、相手先に送付すべきデータをフォルダ形式にて送信する場合について説明する。フォルダ形式では、送付先に伝えるべき内容を記載したファイルと、メッセージガイド情報とを一つのフォルダ内に格納し、このフォルダを相手先に送付するものである。なお、メッセージガイド情報はユーザ又は統合情報交換システム１０３により作成される。
【００６１】
図１１に、メッセージガイド情報の構成を示す。また、図１２にメッセージガイド情報の具体的なデータ例を示す。メッセージガイド情報も、先のレジストリと同様に、要素名とそれに対応する値とからなり、ＸＭＬベースにて記載することが可能である。件名１００１は、送付内容の表題を値として格納する。主要情報ファイル名１００２は、取引の内容を記載した主要情報のファイル名を値として格納する。送付種類１００３は、取引される情報の種類を値として格納する。メッセージレベル１００４は、メッセージの取り扱いレベルを値として格納する。送付先１００５は、取引先の企業コードを値として格納する。この値は、交換先レジストリィに登録された取引先の企業コードと照合される。送付先名１００６は、取引先の正式な名称を値として格納する。相手担当者名１００７は、取引先の担当者名を値として格納する。相手担当者ｅ−ｍａｉｌ１００８は、取引先担当者のＥメールアドレスを値として格納する。送付元１００９は、送付元である自社企業コードを値として格納する。作成者１０１０は、メッセージの作成者や発行者を値として格納する。作成者ｅ−ｍａｉｌ１０１１は、メッセージの作成者や発行者のＥメールアドレスを値として格納する。作成日１０１２は、ファイルの作成日や発行日を値として格納する。照合データ１０１３は、改ざん検出に必要となるデータを値として格納する。この値は、ハッシュ演算を施した結果などが格納される。アクション要求１０１４は、取引先に対して任意の処理の実行を要求する際に、その要求内容を値として格納する。アクション結果１０１５は、アクション要求に基づいて取引先が要求された処理を実行し、その実行結果を値として格納する。関連情報ファイル名１０１６は、主要情報に付随して送付される関連情報のファイル名を値として格納する。
【００６２】
さて、図７に示す処理待ちエリア１０４には、処理対象ファイルとしてフォルダfldr20が記憶されている。再び、図６のフローチャートを参照すると、処理待ちエリアから読み込んだものにメッセージガイド情報が含まれているかを判定する(S15)。例えばメッセージガイド情報を持たない場合はファイル形式と判定され、メッセージガイド情報を持つ場合はフォルダ形式と判定される。すなわち、この判定は、処理対象がファイル形式であるかフォルダ形式であるかを判定する処理である。従って、何れかであるかを判定できる処理であれば、他の処理であってもよい。
【００６３】
次に、統合情報交換システム１０３は、フォルダに含まれるメッセージガイド情報を読み込み、以降のステップで必要となるであろう要素名の値を得る（Ｓ２０）。図７と図１２の例では、フォルダｆｌｄｒ２０に内包されたｍｓｇｇｄ２０のメッセージガイド情報から、”値３１”の要素「送付先」の値 ”Ｆ１”と要素「主要情報ファイル名」の値”ｔｍｐ２０”を抽出する。上述のＳ６０以降の処理は、送受ディレクトリに基づいて実行したが、本実施形態では、メッセージガイド情報から抽出した値でもって処理を実行する。例えば、Ｓ６０では、Ｓ２０で抽出した送付先に基づいて、交換先レジストリを検索する。フォルダｆｌｄｒ２０の送付先”Ｆ１”をもとにすると、”値２１”が求める交換先レジストリとして抽出される。Ｓ７０では、フォルダｆｌｄｒ２０について、処理待ちエリアにあったものと同一の状態で、中間エリアにフォルダ名”Ｆ１＋ｔｍｐ２０”として書き出す。以下は、ファイル形式の場合と同様に処理される。
【００６４】
なお、メッセージ情報の作成にあたっては、皆で共用することを目的としたひな型を予め用意しておき、ユーザの利用目的に合わせて、対話形式にて作成可能な作成補助プログラムをユーザ端末１０１で実行すればよい。あるいは、ユーザ端末１０１においてＷｅｂブラウザを起動して統合情報交換システム１０３にアクセスし、ＣＧＩを介して統合情報交換システム１０３の作成補助プログラムを実行することで作成してもよい。後者の場合に、要素ごとに複数の候補を表示し、ラジオボックスにマークを付することで、メッセージ情報を作成する。
【００６５】
［第３の実施形態］
本実施形態では、メッセージガイド情報の他の使用方法として、例えば、メッセージの転送経路の設定や、送付先でのアクション要求に使用する例を開示する。ところで、ＥＤＩでは、ＶＡＮの中継経路の設定と最終送付先等の表現が必須である。この表現としてメッセージガイド情報を採用すれば、中継先での盗聴と改ざんから送付内容を守ることができる。
【００６６】
図１３に本実施形態の概要を示す。本実施形態では、中継先にける中継処理に必要な情報をメッセージ情報部に格納し、最初の中継先との間で取り決めた暗号化方法で暗号化を施す。一方、メッセージガイド情報とは別のファイルに格納された受注データなどの本文や付随資料については、これらの資料の最終的な送付先である取引相手と取り決めた暗号化方法で暗号化を施す。中継先では、開示部（公開部）のみを復号化してメッセージガイド情報を抽出し、次の中継先及び次の中継先と取り決めた暗号化方法を特定して暗号化を施す。最後に、最終的な送付先において全てを復号化する。このように、本実施形態では、中継に必要な情報を開示部とし、取引に関連する情報を非開示部（非公開部）として分けて別個に暗号化を施すので、中継先において取引内容を盗聴されたり改ざんされたりすることはなくなる。
【００６７】
さて次に、図１４に示した本実施形態の処理フローチャートを説明する。送付元の統合情報交換システム１０３において、ユーザ端末１０１において作成されたメッセージガイド情報を読み込む（Ｓ１４０１）。読み込んだメッセージガイド情報から最終的な送付先を特定し（Ｓ１４０２）、ファイルサーバ１０６蓄えられた暗号化テーブルから最終送付先との間で取り決められた暗号化方法を特定する（Ｓ１４０３）。特定された暗号化方法を用いて、非開示部を暗号化する。暗号化された非開示部についてハッシュ演算を施し（Ｓ１４０５）、演算結果をメッセージガイド情報の照合データ１０１３の値として格納する（Ｓ１４０６）。次に、メッセージガイド情報を参照して、最初の中継先を特定する（Ｓ１４０７）。再び暗号化テーブルを参照して、特定された中継先との間で取り決めた暗号化方法を特定する。特定された暗号化方法でもって開示部に暗号化を施す（Ｓ１４０９）。開示部と非開示部をフォルダに内包したりメールに同封したりして、最初の中継先に送信する（Ｓ１４１０）。
【００６８】
最初の中継先１２０では、これを受信し（Ｓ１４１１）、開示部を復号し（Ｓ１４１２）、メッセージガイド情報を抽出する。非開示部に対してハッシュ演算を施し（Ｓ１４１３）、メッセージガイド情報に含まれるデータ照合部の値と演算結果が一致するかを判定する（Ｓ１４１４）。もし、一致しなければ、非開示部が改ざんされたか損傷を受けていることを表しているので、改ざんを検出したものとして報告する（Ｓ１４１５）。もし一致すれば、改ざんはなされていないので次の中継先に転送すべく、次の中継先をメッセージガイド情報から特定する（Ｓ１４１６）。特定された次の中継先に対応する暗号化手法を暗号化テーブルから特定し（Ｓ１４１７）、特定された暗号化方法で開示部を再び暗号化する（Ｓ１４１８）。開示部と非開示部をフォルダに内包したりメールに同封したりして、次の中継先（中継が終了すれば最終的な送付先）に送信する（Ｓ１４１９）。
【００６９】
送付先１３０では、これを受信し（Ｓ１４２０）、開示部を復号し（Ｓ１４２１）、メッセージガイド情報を抽出する。メッセージガイド情報から送付元を特定し（Ｓ１４２２）、特定された送付元に対応する暗号化方法を特定し（Ｓ１４２３）、特定された暗号化方法でもって非開示部を復号する（Ｓ１４２４）、そして処理を終了する（Ｓ１４２５）。
【００７０】
なお、送付元統合情報交換システムで実施した処理をユーザ端末で実施してもよい。その場合は次のような処理となる。
【００７１】
１）本文と付随資料とを最終送付先との取り決められた暗号方式と暗号キィで暗号化する。必要なら本文または付随資料のハッシュ演算を行い、メッセージガイド情報の要素名「照合データ」の値としてハッシュ演算結果を付加しデータの改ざん確認等に用いる。
【００７２】
２）この本文と付随資料を暗号化したものおよびメッセージガイド情報を、最初の中継先との間で取り決められた暗号方式と暗号キィで暗号化し、最初の中継先に送付する。３）中継先では、発行者との取り決められた暗号化に基づくキイにより復号処理を行う。メッセージガイド情報が開示されるのでその値を参照し、次の経路となる中継先を知る。必要なら送達内容のハッシュ演算を実行してメッセージガイド情報の要素名「照合データ」の値と比較し、正当データか否か確認する。本文と付随資料を暗号化したものおよびメッセージガイド情報を、次の経路となる中継先との間で取り決められた暗号方式と暗号キィにより暗号化を行い、次の経路となる中継先に送付する。
以降、中継先毎にこれを繰り返す。
【００７３】
４）最終送付先では、中継者から最終送付先に送付された内容を中継者の暗号化方式に基づく復号キィを用い、内容を復号する。必要なら送達内容のハッシュ演算を実行しメッセージガイド情報の要素名「照合データ」の値と比較し、正当データか否か確認する。次に本文と付随資料を発行者との取り決め暗号方式による復号キィを用い復号する。
【００７４】
このようにメッセージガイド情報を用いて経路設定と暗号化を施す、すなわち開示部、非開示部とを併用することにより、アプリケ−ションレベルで、商取引データの信頼性とインタ−ネット上での盗聴、改ざん、なりすまし等への対処することが可能となる。なお、この方式による情報の開示、非開示の仕組みは企業内の特定部署との間でも適用可能であり、例えば、人事情報等の機密情報交換にも適用できる。
【００７５】
［第４の実施形態］
本実施形態では、メッセージガイド情報を用いて、送付先に所定の処理を実行させるものである。
【００７６】
例えば、商取引において、所定の電子書面の送達をもって取引が成立したものと擬制する場合がある。このような場合に、電子書面の送信したときを送達したときとみなす発信主義と、実際に取引相手が当該電子書面を受信したとき、すなわち電子書面が相手方に到達したときを送達したときとみなす到達主義とがある。発信主義を採するなら、送信元のシステムで送信時刻を記録しておけば、その送信時刻に取引が成立したものとみなせ、相手側には電子書面とともに送信時刻を添付すれば相手側も取引の成立時刻を確認できる。一方、到達主義の場合は、送付先側のシステムで受信時刻を記録し、その受信時刻に取引が成立したものとみなし、送付元にそれを知らせれば、送付元も取引の成立時刻を確認できる。このように、到達主義の場合は、送信した書面の受信確認、すなわち、相手方に取引書面が送達されたことを確認するための何らかの手段が必要となる。
【００７７】
そこで、本実施形態では、上述の送達の確認など、送付先で実施してほしいアクションの要求を可能とするものであり、具体的には、当該要求をメッセージガイド情報に搭載し、送付先に送信する。送付先では、当該ガイド情報の内容に記載された要求に基づいて要求された処理（アクション）を実行する。この実行は、前述のように自動で行ってもよいし、アクション要求がなされている旨を担当者のディスプレイに表示し、それを見た担当者による手動操作により実行してもよい。これにより、例えば、上述の確認をＷｅｂ−ＥＤＩにおいても容易におこなうことができる利点がある。
【００７８】
図１５に、メッセージガイド情報を用いたアクション要求の概念を示す。また、処理のフローチャートを図１６に示す。現在、ＥＤＩによる商取引の成立は、送付先へのデータの到達によって成立するとの解釈が一般的である。従来型のＥＤＩでは、信頼性の高い交換手順を採用することを条件として、双方合意の下で受信確認を省略する傾向にある。しかし、Ｗｅｂ−ＥＤＩでは、インターネットを用いるため、転送の信頼性が低くく、商取引の成立確認を保証できない。本実施形態では、例えば、Ｗｅｂ−ＥＤＩにおける送達確認の仕組みを次の方法で実現する。
【００７９】
図１５の例で、メッセージガイト情報は、送付先に対して送達確認処理の要求する内容を含んでいる。
【００８０】
送付元であるｂ社において、ユーザ端末１０１は、メッセージガイド情報にアクション要求を設定するためのプログラムを起動する（Ｓ１６０１）。プログラムが起動されると、ユーザの端末の表示装置には、内容確認を要求するか、送達確認を要求するかが表示され、インタラクティブに設定可能とする（Ｓ１６０２，Ｓ１６０３）。ここで、内容の確認とは、電子書面に対する改ざんを検出してその結果を送付元に返信する処理である。検出には、前述のハッシュ演算を用い照合が使用できよう。図１５の例では、内容確認及び送達確認ともに実施が必要（ＹＥＳ）と設定されている。ユーザによる設定が終了すると設定プログラムが終了する（Ｓ１６０４）。
【００８１】
その後、図１４のフローに従って送信処理がなされる。例えば、主要情報ファイルＥＤＩ０１（ＥＤＩデータ）に対しハッシュ演算を行い（Ｓ１４０５）、その結果（ハッシュ値）をメッセージガイド情報の「照合データ」の値として格納する（Ｓ１４０６）。送付元”ｂ社”のシステムにおいて、主要情報ファイルＥＤＩ０１（ＥＤＩデータ）とメッセージガイド情報を送付先”ａ社”のシステムに送信する（Ｓ１４１０）。
【００８２】
送付先”ａ社”のシステムは、受信したメッセージガイド情報から「アクション要求」の値を取得し（Ｓ１６１１）、その値に基づいて、内容確認処理が要求されているかを判定する（Ｓ１６１２）。要求されている場合、すなわちＹＥＳの場合は、ＥＤＩデータにハッシュ演算を実施し（Ｓ１６１３）、演算結果とメッセージガイド情報の「照合データ」の値（送付元でのハッシュ値）と照合し（Ｓ１６１４）、照合結果をメッセージガイド情報の要素名「アクション結果」の値としてに格納する（Ｓ１６１５）。なお、ハッシュ演算のプログラムおよび照合のプログラムを送付元であるｂ社などが、Ｗｅｂに登録開示し、ａ社がダウンロードを可能なようにしておけば、送付先でプログラムを作成することなく処理できる。メッセージガイド情報に送達確認が要とされているかを判定し（Ｓ１６１６）、送達確認がＹＥＳであるなら、メッセージガイド情報のみを送付元ｂ社に送信する（Ｓ１６１７）。
【００８３】
送付元ｂ社のシステムでは、返信されたメッセージガイド情報に基づいて、送付履歴と照合し、照合結果を履歴情報として管理したり、照合の結果、必要な場合には担当者に照合結果を送付する。なお、照合の結果、一致しない場合には、再送するようにシステムを構成してもよい。また、ユーザ端末などに履歴情報を表示し、ユーザが送達の確認を行えるようにしてもよい。
【００８４】
このようにメッセージガイド情報を用いることにより、メッセージの送付先での操作要求や実行プロセス等を相互に指定が可能となり、送付先でプログラムを作成することなく、交換されるメッセージの種類や内容に対応した処理を送付先にて行うことができる。また、送付したときのメッセージガイド情報に対して、さらに送達結果が付加されて返信されることから、送付元での照合が容易になる。
【発明の効果】
本願発明によれば、例えば、新規送付先が増えたり、送付先との交換の様式が変更されたり、定期交換や都度交換など交換方法が変更されたり、既存のＥＤＩ手順やインタ−ネットの交換手段が変更されたりした場合であっても、システム内の交換先レジストリ及び送受レジストリ若しくはメッセージガイド情報の要素の値を修正するだけで、これらの変更に対応できる。そのため、システム開発が不要となり、また、タイムリーかつ容易にこれらの変更に対応可能となる。
【００８９】
また、Ｗｅｂ−ＥＤＩにおいても、送付先での処理を指定できるため、送達確認等、商取引の成立の信頼性を確保でき、不特定多数との安全な電子商取引が可能となる。
【図面の簡単な説明】
【図１】本実施形態におけるシステム構成例を示す図である。
【図２】本実施形態における統合情報交換システム等の概略構成を示すブロック図である。
【図３】本実施形態における送受レジストリの内容を示す図である。
【図４】本実施形態における交換先レジストリの内容を示す図である。
【図５】本実施形態における処理の流れを概念的に表現した図である。
【図６】本実施形態における内部ファイルの処理フローチャートである。
【図７】本実施形態における処理待ちエリア内の処理対象ファイルの例を示す図である。
【図８】本実施形態における送受レジストリへのデータの格納例を示す図である。
【図９】本実施形態における交換先レジストリへのデータの格納例を示す図である。
【図１０】本実施形態における中間ファイルの処理フローチャートである。
【図１１】本実施形態におけるメッセージガイド情報の内容を示す図である。
【図１２】本実施形態におけるメッセージガイド情報へのデータの格納例を示す図である。
【図１３】本実施形態における暗号化処理の流れを概念的に表現した図である。
【図１４】本実施形態におけるデータ交換についてのフローチャートである。
【図１５】本実施形態におけるアクション要求処理の流れを概念的に表現した図である。
【図１６】本実施形態におけるアクション要求処理についてのフローチャートである
【符号の説明】
１００…業務システム
１０１…ユーザ端末
１０２…ＬＡＮ
１０３…統合情報交換システム
１０４…ファイルサーバの処理待ちエリア
１０５…ファイルサーバの中間エリア
１０６…ファイルサーバの送受レジストリと交換先レジストリ
１１０…ＥＤＩ網またはインターネット
１２０…中継先のサーバ
１３０…送付先のシステム
１４０…他の送付先システム
１５０…送付元の全体システム

Claims

第１の情報システムにおいて作成されたファイルをネットワークに接続された第２の情報システムへと送信するファイル交換装置において、
前記第１の情報システムにおいて作成された複数の内部ファイルを記憶する第１の記憶装置と、
前記第１の記憶装置に記憶された複数の前記内部ファイルから中間ファイルまたは前記第２の情報システムに送信するための送受ファイルを作成するための企業コード、ファイル名、および編集区分を記述したレジストリを記憶する第２の記憶装置と、
前記第１の記憶装置に記憶されている複数の前記内部ファイルを順次読み出し、読み出した該内部ファイルが、送付先を記述したメッセージガイド情報を有さないファイル形式であるか、または該メッセージガイド情報を有するフォルダ形式であるかを判定する判定手段と、
前記判定手段により前記内部ファイルが前記ファイル形式であると判定された場合には、該内部ファイルに含まれる送付先の情報に従って前記レジストリを特定し、一方、前記内部ファイルが前記フォルダ形式であると判定された場合には該内部ファイルの前記メッセージガイド情報に記述されている送付先に従って前記レジストリを特定し、それぞれ特定された該レジストリに含まれている企業コードおよびファイル名に従ったファイル名を付すことで、該内部ファイルから前記中間ファイルを作成して中間エリアに格納する格納手段と、
前記中間エリアから前記中間ファイルを読み出し、読み出した該中間ファイルから前記第２の情報システムに送信するための送受ファイルを作成する際に、前記中間ファイルのファイル名に従って前記レジストリを特定し、特定された該レジストリに記述されている編集区分が、送付先が同一である複数の前記中間ファイルを一つにとりまとめることを指示している場合は、複数の前記中間ファイルを一つにとりまとめて送受ファイルを作成する送受ファイル作成手段と、
作成された前記送受ファイルを前記第２の情報システムに送信する送信手段と
を備えることを特徴とするファイル交換装置。
前記格納手段は、
前記ファイル形式であると判定された前記内部ファイルに送付先の異なる複数の内部メッセージが含まれている場合は、該内部ファイルを該送付先ごとに分割する分割手段を含むことを特徴とする請求項１に記載のファイル交換装置。