(57)【要約】本発明は、取引情報を提供する方法に関するものである。従来技術では、取引情報システムがそれぞれ取引情報をメール送信するので、てんでに多くのメールが利用者に届く。取引情報システム毎のメール形式や利用者の登録になる恐れもある。これらの不便を解決すること、及び、メールによる提供に比べ、より利便性のある提供方法として、１以上の取引情報システムから受理した取引情報を集約し、利用者へのメール又は利用者からのサーバアクセスにより提供する。
2003001422.tif 000002
【特許請求の範囲】
【請求項１】
１以上の取引情報システムから、電子メールアドレス付きの取引情報を受理し、前記受理した取引情報を少なくとも前記電子メールアドレス別に集約し、送信命令により前記集約した取引情報を、前記電子メールアドレスあてにメール送信する、ことを特徴とする取引情報の提供方法。
【請求項２】
１以上の取引情報システムから、口座番号付きの取引情報を受理し、前記受理した取引情報を少なくとも前記口座番号別に集約し、送信命令により前記集約した取引情報を、前記口座番号に対応した電子メールアドレスあてにメール送信する、ことを特徴とする取引情報の提供方法。
【請求項３】
１以上の取引情報システムから、口座番号付きの取引情報を受理し、前記受理した取引情報を少なくとも前記口座番号別にファイルに集約し、利用者の端末から当該利用者の利用権限がある口座番号の前記集約したファイルにアクセスさせる、ことを特徴とする取引情報の提供方法。
【請求項４】
１以上の取引情報システムから、口座番号付きの取引情報を受理し、前記受理した取引情報をデータベースに集約し、利用者の端末から当該利用者の利用権限がある口座番号に対応する前記データベースに集約した取引情報にアクセスさせる、ことを特徴とする取引情報の提供方法。
【発明の詳細な説明】
技術分野
本発明は、取引情報を利用者に提供する方法に関する。
背景技術
取引情報を利用者に提供する方法については、例えば、日本国特許公開２０００−１６３６５２や日本国特許公開平１１−７３４６７に、販売店のＰＯＳ端末装置、金融機関の自動取引装置、及びそれらの装置とホストコンピュータの連携システムから、取引情報を電子メール（以下、「メール」と言う）として提供する技術が公開されている（以下、前記装置や前記連携システムを含み、取引情報を取り扱うコンピュータシステムを取引情報システムと言う。）。
従来技術では、取引情報の提供手段はメールであり、取引情報発生の都度メールが送信され、取引情報や送信先の入力手段からメール送信手段までの装置又はシステムは一体である、ことが特徴である。
従来の技術の場合、取引情報システムがそれぞれ取引情報をメール送信するので、てんでに多くのメールが利用者に届くことになる。また、取引情報システム毎のメール形式や利用者の登録になる恐れもある。
これらの点は利用者にとって不便であるから、その問題点の解決を図ること、また、従来のメールによる提供に比べ、より利便性のある提供方法を発明することを課題とする。
発明の開示
本発明は、個々の取引情報システムから独立して、１以上の取引情報システムの取引情報を集約して利用者に提供する（以下、この方法により取引情報を利用者に提供するコンピュータシステムを取引情報提供システムと言う。）。また、取引情報の提供形態として、従来のメールによる提供に加えて、サーバアクセスによる提供を設けた。
本発明は、メールによる提供の場合、１以上の取引情報システムから、メールアドレス付きの取引情報を受理し、少なくともメールアドレス別に集約し、送信命令により当該メールアドレスに取引情報を送信する。
また、本発明は、メールによる提供の場合、１以上の取引情報システムから、口座番号付きの取引情報を受理し、取引情報を少なくとも口座番号別に集約し、送信命令により当該口座番号に対応したメールアドレスに取引情報を送信する。
また、本発明は、サーバアクセスによる提供の場合、１以上の取引情報システムから、口座番号付きの取引情報を受理し、少なくとも口座番号別のファイルに集約し、利用者の端末から、利用者に利用権限のある口座番号のファイルにアクセスさせる。
また、本発明は、サーバアクセスによる提供の場合、１以上の取引情報システムから、口座番号付きの取引情報を受理し、データベースに集約し、利用者の端末から、利用者に利用権限のある口座番号に対応するデータベースに集約された取引情報にアクセスさせる。
発明を実施するための最良の形態
本発明をより詳細に説述するために、添付の図面に従ってこれを説明する。
第１図は、本発明の概念図である。
コンピュータ１１０は、１以上の取引情報システム１０ｘから、受理手段１２０で取引情報を受理し、受理ファイル１２ｘに保存する。集約手段１３０は受理ファイル１２ｘを読み、メールアドレス又は口座番号を区別して集約ファイル１３ｘに集約する。提供手段１６０は、通信網１７０を通じて、利用者端末１８ｘに集約ファイル１３ｘに集約された取引情報を提供する。なお、本発明においてデータベースはファイルの一種である。
第２図は、請求の範囲第１項による取引情報の提供方法の実施例を示す図である。この例では１日分の取引情報を集約して毎日利用者にメールで提供するものとする。
コンピュータ２１０は、取引情報システム２０ａ、２０ｂ、…、２０ｎから、記憶媒体上のデータ又は通信データとして、メールアドレス付きの取引情報を受理手段２２０で毎日、１回又は複数回に分けて受理する。受理した取引情報は受理ファイル２２ａ、２２ｂ、…、２２ｎに保存する。
集約プログラム２３０は受理が完了してクローズされたファイル２２ａ、２２ｂ、…、２２ｎをオープンして取引情報を読み、メールアドレス別の集約ファイル２３ａ、２３ｂ、…、２３ｎに集約する。ファイル２３ａ、２３ｂ、…、２３ｎが存在しない場合は新規に生成する。集約処理が終わった受理ファイル２２ａ、２２ｂ、…、２２ｎはバックアップして削除する。
口座番号テーブル２４０は、口座番号と、メールアドレスと、追加メールアドレスと、のフィールドを持つファイルである。口座番号テーブル２４０は、取引情報に付属したメールアドレスに無条件にメール送信する場合は不要である。
口座番号テーブル２４０は、予め利用者にメールアドレスを登録させ、その存在をチェックしてからメール送信する運用を行う場合や、取引情報に付属したメールアドレス以外のメールアドレスにも取引情報の写しをメール送信する運用を行う場合は必要である。
後者の場合、取引情報に付属したメールアドレスで口座番号テーブル２４０を参照し、追加メールアドレスのフィールドに記憶されたメールアドレスに取引情報の写しをメール送信する。なお、本実施例では、口座番号のフィールドには、内部管理用の番号を入れておけばよい。
当日受理分の取引情報の集約が完了すると、送信命令プログラム２５０は、メールメッセージを生成し、ＭＴＡ（Ｍａｉｌ  Ｔｒａｎｓｐｏｒｔ  Ａｇｅｎｔ）２６０にメール送信命令を出す。
ＭＴＡ２６０は例えば、Ｓｅｎｄｍａｉｌである。−ｔオプションを付けてＳｅｎｄｍａｉｌを起動し、生成したメールメッセージを与える。前記メールメッセージは、ヘッダ部と１行の空行とボディ部からなる。ヘッダ部はタイトルフィールド、Ｔｏ：フィールド、Ｃｃ：フィールド、Ｂｃｃ：フィールド等からなる。Ｔｏ：フィールドには集約ファイル２３ａ、２３ｂ、…、２３ｎの送信先である取引情報のメールアドレスを入れる。
口座番号テーブル２４０を参照して追加メールアドレスにメール送信する場合は、Ｔｏフィールド、Ｃｃフィールド又はＢｃｃフィールドのいずれかにそれらのメールアドレスを入れる。いずれのフィールドに入れてもメールは送信されるがＢｃｃ：フィールドは転送前にメールメッセージから削除される。あるいは、追加メールアドレスへは、別のメールとして送信することも考えられる。
ボディ部には、集約ファイル２３ａ、２３ｂ、…、２３ｎの取引情報を入れる。
Ｓｅｎｄｍａｉｌの−ｔオプションは、与えたメールメッセージのヘッダ部のＴｏ：フィールド、Ｃｃ：フィールド、Ｂｃｃ：フィールドからメールの送信先を読み取らせる指示である。−ｔオプションを付けない場合は、Ｓｅｎｄｍａｉｌを起動するとき、パラメータでメールの送信先を与える必要がある。
メールは、ＳｅｎｄｍａｉｌによりＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）でインターネット２７０を経由して配送されるが、ＵＵＣＰ（Ｕｎｉｘ（登録商標）  ｔｏ  Ｕｎｉｘ（登録商標）  Ｃｏｐｙ）で配送される場合もある。
送信済みの集約ファイル２３ａ、２３ｂ、…、２３ｎはバックアップして削除する。
利用者は利用者端末２８ａ、２８ｂ、…、２８ｎから自己のＰＯＰ（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ）やＩＭＡＰ（Ｉｎｔｅｒｎｅｔ  Ｍｅｓｓａｇｅ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）等の受信メールサーバにアクセスしてメールを読み出す。
受理ファイル２２ａ、２２ｂ、…、２２ｎや集約ファイル２３ａ、２３ｂ、…、２３ｎは前日の未処理分と混同しないように、日付を含んだファイル名にするか、日付により保存するディレクトリを分けるほうがよい。
第３図は、請求の範囲第２項による取引情報の提供方法の実施例を示す図である。この例では１日分の取引情報を集約して毎日利用者にメールで提供するものとする。
コンピュータ３１０は、取引情報システム３０ａ、３０ｂ、…、３０ｎから、記憶媒体上のデータ又は通信データとして、口座番号付きの取引情報を受理手段３２０で毎日、１回又は複数回に分けて受理する。受理した取引情報は受理ファイル３２ａ、３２ｂ、…、３２ｎに保存する。
集約プログラム３３０は受理が完了してクローズされた受理ファイル３２ａ、３２ｂ、…、３２ｎをオープンして取引情報を読み、口座番号別の集約ファイル３３ａ、３３ｂ、…、３３ｎに集約する。集約ファイル３３ａ、３３ｂ、…、３３ｎが存在しない場合は新規に生成する。集約処理が終わった受理ファイル３２ａ、３２ｂ、…、３２ｎはバックアップして削除又はクリアする。
口座番号テーブル３４０は、口座番号と、当該口座番号にかかる取引情報を利用できる１以上の利用者のメールアドレスと、を記憶したファイルである。
当日受理分の取引情報の集約が完了すると、送信命令プログラム３５０は、メールメッセージを生成し、ＭＴＡ３６０にメール送信命令を出す。
ＭＴＡ３６０は例えば、Ｓｅｎｄｍａｉｌである。−ｔオプションを付けてＳｅｎｄｍａｉｌを起動し、生成したメールメッセージを与える。前記メールメッセージは、ヘッダ部と１行の空行とボディ部からなる。ヘッダ部はタイトルフィールド、Ｔｏ：フィールド、Ｃｃ：フィールド、Ｂｃｃ：フィールド等からなる。Ｔｏ：フィールドには集約ファイル３３ａ、３３ｂ、…、３３ｎの取引情報の口座番号から口座番号テーブル３４０を参照して求めた送信先のメールアドレスを入れる。送信先が複数の場合は、Ｔｏフィールド、Ｃｃフィールド又はＢｃｃフィールドのいずれかにそれらのメールアドレスを入れる。いずれのフィールドに入れてもメールは送信されるがＢｃｃ：フィールドは転送前にメールメッセージから削除される。あるいは、別々のメールとして送信することも考えられる。
ボディ部には、集約ファイル３３ａ、３３ｂ、…、３３ｎの取引情報を入れる。
Ｓｅｎｄｍａｉｌの−ｔオプションは、与えたメールメッセージのヘッダ部のＴｏ：フィールド、Ｃｃ：フィールド、Ｂｃｃ：フィールドからメールの送信先を読み取らせる指示である。−ｔオプションを付けない場合は、Ｓｅｎｄｍａｉｌのパラメータでメールの送信先を与える必要がある。
メールは、ＳｅｎｄｍａｉｌによりＳＭＴＰでインターネット３７０を経由して配送されるが、ＵＵＣＰで配送される場合もある。
送信済みの集約ファイル３３ａ、３３ｂ、…、３３ｎはバックアップして削除する。
利用者は利用者端末３８ａ、３９ｂ、…、３９ｎから自己のＰＯＰやＩＭＡＰ等の受信メールサーバにアクセスしてメールを読み出す。
受理ファイル３２ａ、３２ｂ、…、３２ｎや集約ファイル３３ａ、３３ｂ、…、３３ｎは前日の未処理分と混同しないように、日付を含んだファイル名にするか、日付により保存するディレクトリを分けるほうがよい。
第４図は、請求の範囲第３項による取引情報の提供方法の実施例を示す図である。この例では１日分の取引情報を１つのファイルに集約してＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）サーバで提供するものとする。
コンピュータ４１０は、取引情報システム４０ａ、４０ｂ、…、４０ｎから、記憶媒体上のデータ又は通信データとして、口座番号付きの取引情報を受理手段４２０で毎日、１回又は複数回に分けて受理する。受理した取引情報はファイル４２ａ、４２ｂ、…、４２ｎに保存する。
口座番号テーブル４４０は、口座番号と、当該口座番号にかかる取引情報を利用できる１以上の利用者のホームディレクトリ名と、を記憶したファイルである。
集約プログラム４３０は受理が完了してクローズされた受理ファイル４２ａ、４２ｂ、…、４２ｎをオープンして取引情報を読み、口座番号別の集約ファイル４３ａ、４３ｂ、…、４３ｎに集約する。集約ファイル４３ａ、４３ｂ、…、４３ｎが存在しない場合は新規に生成する。この場合、集約プログラム４３０は口座番号テーブル４４０を参照し、予め登録された口座番号かどうかを確認する。集約処理が終わった受理ファイル４２ａ、４２ｂ、…、４２ｎはバックアップして削除又はクリアする。
当日受理分の取引情報の集約が完了した集約ファイル４３ａ、４３ｂ、…、４３ｎは、利用者のホームディレクトリ４５０に集約ファイル４５ａ、４５ｂ、…、４５ｎとして移動させる。一つの口座番号の利用者が複数ある場合は、それらの利用者のホームディレクトリ４５０にもコピーする。
利用者は、インターネット４７０を経由し、利用者端末４８ａ、４８ｂ、…、４８ｎから、ユーザＩＤ及びパスワードを入力して、ＦＴＰサーバ４６０にログインし、当該利用者のホームディレクトリ４５０にある集約ファイル４５ａ、４５ｂ、…、４５ｎをダウンロードする。
この他、予め口座番号とパスワードを関連付けしたテーブルを用意し、利用者の端末から、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）サーバを経由して、口座番号とパスワードを入力させることにより、当該口座番号のファイルを閲覧したり、ダウンロードさせることもできる。
受理ファイル４２ａ、４２ｂ、…、４２ｎや集約ファイル４３ａ、４３ｂ、…、４３ｎは前日の未処理分と混同しないように、日付を含んだファイル名にするか、日付により保存するディレクトリを分けるほうがよい。特に、集約ファイル４５ａ、４５ｂ、…、４５ｎは、利用者が削除せず以前のものが残ってる可能性が高いので、日付を含んだファイル名にするか、日付により保存するディレクトリを分ける必要がある。利用者によって削除されず、残っているファイルは一定期間経過後に削除する必要がある。
この実施例では、集約ファイルの提供手段をＦＴＰサーバとしたが、リモートファイルサーバとかネットワークファイルシステムとか呼ばれる、ＵＮＩＸ（登録商標）系のＮＦＳ（Ｎｅｔｗｏｒｋ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）やＷｉｎｄｏｗｓ（登録商標）系のＳＭＢ（Ｓｅｓｓｉｏｎ  Ｍｅｓｓａｇｅ  Ｂｌｏｃｋ）プロトコルを利用したサーバ等としてもよい。なお、ＵＮＩＸ（登録商標）でもＳａｍｂａというソフトウェアを使用すれば、ＳＭＢを利用したファイルサーバを構築することができる。
第５図は、請求の範囲第４項による取引情報の提供方法の実施例を示す図である。この例ではファイルの一種であるリレーショナル型のデータベースに取引情報を累積して、利用者にＷＷＷサーバを通じて検索等高度な利用環境を提供する。
コンピュータ５１０は、取引情報システム５０ａ、５０ｂ、…、５０ｎから、記憶媒体上のデータ又は通信データとして、口座番号付きの取引情報を受理手段５２０で毎日、１回又は複数回に分けて受理する。受理した取引情報は受理ファイル５２ａ、５２ｂ、…、５２ｎに保存する。
口座番号テーブル５４０には、予め登録された口座番号が記憶されている。
集約プログラム５３０は受理が完了してクローズされた受理ファイル５２ａ、５２ｂ、…、５２ｎをオープンして取引情報を読み、当該取引情報をリレーショナル型のデータベース５３１の口座番号別の集約テーブル５３ａ、５３ｂ、…、５３ｎにインサートする。集約テーブル５３ａ、５３ｂ、…、５３ｎが存在しない場合は新規に生成する。この場合、集約プログラム５３０は口座番号テーブル５４０を参照し、予め登録された口座番号かどうかを確認する。集約処理が終わった受理ファイル５２ａ、５２ｂ、…、５２ｎはバックアップして削除する。
利用者は、インターネット５７０を経由し、利用者端末５８ａ、５８ｂ、…、５８ｎから、ＷＷＷサーバ５６０に接続し、口座番号とパスワード又はユーザＩＤとパスワードを入力して、データベース５３１にある当該利用者の利用権限がある集約テーブル５３ａ、５３ｂ、…、５３ｎの取引情報に、ＷＷＷ−ＲＤＢＭＳ連携システム５５０及びＲＤＢＭＳ５３２の機能を通してアクセスする。
口座番号とパスワードでアクセスさせる場合は、口座番号テーブル５４０に、口座番号に対応するパスワードを記憶して認証に利用する。この場合、一つの口座番号に一つのパスワードとすると、一つの口座番号の利用者は全員同じパスワードを使うことになるから、それぞれの利用者に当該パスワードを自由に変更させるような運用は困難である。
ユーザＩＤとパスワードでアクセスさせる場合は、ユーザＩＤと、当該ユーザＩＤに対応するパスワードと、当該ユーザＩＤで利用できる１以上の口座番号と、の関連を記憶した認証用テーブルを設ける必要がある。
この実施例では、一つのデータベースの中に口座番号別の集約テーブルとしたが、口座番号別のデータベースや複数の口座番号をグループ化したデータベースにしてもよいし、全部の口座番号又は複数の口座番号の取引情報を一つの集約テーブルに入れることも可能である。なお、複数の口座番号の取引情報を一つ集約のテーブルに入れる場合は、当該集約テーブルに口座番号フィールドは必須である。
本発明において取引情報とは、店頭での対面取引、ＡＴＭ等の自動取引装置や自動販売機での無人取引、郵便、電話、ＦＡＸ、インターネット等による通信取引、等の取引に伴い発生したコンピュータデータである。
その内容は、例えば、取引日、取扱日、曜日、時刻、取引社名、取引場所、店名、電話番号、機械番号、レジ番号、口座番号、会員番号、担当者名、取引内容、品名、サービス名、仕様、単価、数量、価格、消費税、合計金額、入金額、出金額、振込金額、預入れ額、貸出し額、お釣の額、残高、利率、金種、サービスポイント、コメント、関連情報、関連情報のホームページのＵＲＬ、各種手数料、決済データ、等の項目（フィールド）又は要素（エレメント）と呼ばれるものからなる。
本発明において、集約はこれらの項目の並びや要素のタグ名を一致させることを含むが、取引情報のフォーマットが標準化されていない場合は、変換処理をする必要が生じるので、予め、例えばＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅ）形式なら項目の並び順を統一し、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書なら少なくともタグ名を統一するか、その文書型定義（ＤＴＤ：Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）又はＸＭＬ  Ｓｃｈｅｍａ等のスキーマを標準化するのが好ましい。
パソコンを利用者端末に使う場合、普通、ＪＩＳコード、シフトＪＩＳコードやＥＵＣコード、ＩＳＯ／ＩＥＣ−１０６４６（Ｕｎｉｃｏｄｅ）等の文字コードには対応しているが、汎用コンピュータで使われるＥＢＣＤＩＣコードやメーカー独自の２バイト漢字コードには対応していないので、文字コードの変換処理が必要になることがある。汎用コンピュータでは、ゾーン１０進、パック１０進、バイナリ等のデータ型で数値を持つことがあるが、ＣＳＶ形式やＸＭＬ形式等パソコンで利用できるようにするには、当該数値を数字の文字列に変換する必要がある。
その他、空白、ＴＡＢ区切り、カンマ区切りのような項目間の区切り文字を変換するとか、項目の追加、項目の削除、項目並びの入れ替え、ソート、整形、ＨＴＭＬやＸＭＬへの形式変換、暗号化等が必要な場合がある。
以上の説明において取引情報提供システムとは、取引精報を利用者に提供するコンピュータシステムである。実施例ではＵＮＩＸ（登録商標）マシンの利用を想定している。
以上の説明において取引情報システムとは、取引情報を取り扱うコンピュータシステムであり、例えばＰＯＳ端末、ＡＴＭ装置、自動販売機、それらを管理するホストコンピュータ、電子商取引のサーバ、取引情報を入力するパソコンやＡＳＰ（アプリケーションサービスプロバイダ）のサーバ等である。
以上の説明において口座番号は、取引情報を集約するための仕訳コードであり、同等の役割を果たせるコード、例えば利用者を識別するユーザＩＤを含む。利用者が取引情報を複数に仕訳したい場合は、ユーザＩＤを複数発行したり、ユーザＩＤに枝番を付けて口座番号としたり、ユーザＩＤとは別のコード体系で口座番号を発行する。ユーザＩＤや口座番号は数字だけでなく、例えば英字やハイフン等を含んでもよい。
取引情報を複数の送信先にメール送信する場合や、複数の口座番号に入れる場合は、一つの取引情報に複数のメールアドレスや口座番号を付加するようにするか、取引情報提供システムに、メールアドレスや口座番号に関連したメールアドレスや口座番号を記憶するテーブルを用意する。
以上の説明において、受理手段は、媒体読取装置と媒体読取プログラム又は通信装置と通信プログラムで構成される。媒体読取装置は媒体読取プログラムの制御を受け、磁気テープや光磁気ディスク等の記憶媒体を読み取る。通信装置は、インターネット、専用回線、公衆回線、通信衛星等の通信網に接続されたルータ、モデム、ＴＡ、地球局等であり、通信プログラムの制御を受け、ＦＴＰ、ＨＴＴＰ、ＳＭＴＰ、ＳＭＢ等の通信プロトコルでデータ通信を行う
受理した取引情報は、ファイル又はデータベースに、口座番号又はメールアドレスにより区別して保存する。つまり、取引情報の口座番号又はメールアドレスといった情報が失われないように保存する。
例えば、ファイルやデータベースやテーブルの名称を、口座番号又はメールアドレスが一意に対応する名前にして保存するとか、口座番号やメールアドレスが異なる取引情報を同じファイルやデータベースやテーブルに保存する場合に、口座番号又はメールアドレス付きで保存するとか、である。
メールやダウンロードで集約した取引情報を提供する場合は、その取引情報は例えば項目の並びを統一したＣＳＶ形式のテキストファイルでよい。
実施例の受理ファイル及び請求の範囲第４項以外の実施例の集約ファイルにこういう単純なテキストファイルを想定する場合、集約プログラムは受理ファイルの取引情報を順に読み、集約ファイルの最後にアペンドするだけでよい。なお、集約が終わった後で、集約ファイルを取引時刻等でソートしてもよい。
集約ファイルは、場合によっては汎用コンピュータにおける固定長レコードや可変長レコードの順編成ファイル、直接編成ファイル、索引編成ファイル、区分編成ファイル、ＶＳＡＭ（Ｖｉｒｔｕａｌ  Ｓｔｏｒａｇｅ  Ａｃｃｅｓｓ  Ｍｅｔｈｏｄ  Ｏｒｇａｎｉｚａｔｉｏｎ）ファイルを使うこともありえる。また、パソコンの特定のアプリケーションに対応したファイル、圧縮や暗号化したファイル、ＳＹＬＫ（Ｓｙｍｂｏｌｉｃ  Ｌｉｎｋ  Ｆｉｌｅ）ファイル等もありえる。
例えば、取引情報をメールの添付ファイルで受理する場合は、メールで様々なファイルを送信するための規約であるＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎｓ）で規定する変換方法の一つであるＢａｓｅ６４でエンコードされたメールメッセージファイルを扱うことになる。
より高度な利用、例えば利用者端末のインターネットブラウザから、ＷＷＷサーバを経由して取引情報の検索、ソート、計算等の多様な利用をさせる場合は、集約するファイルはリレーショナル型のデータベースを用いるのが好ましい。
ＸＭＬ形式の取引情報はテキストファイルのままでも、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔ  Ｌａｎｇｕａｇｅ）ファイルを用いることでデータベースとして利用が可能である。取引情報がＸＭＬ形式の場合、又は利用者にＸＭＬ形式で提供する場合は、受理ファイルや集約ファイルをテキストファイルとする以外に、リレーショナル型のデータベースに保存したり、ＸＭＬ専用のデータベースを利用したりすることもできる。
取引情報を集約したファイルをファイルサーバで提供する場合や、利用者端末のインターネットブラウザ上の専用ソフトから当該ファイルにアクセスさせる場合は、独自に定めたファイル形式でもよい。
請求の範囲第４項の実施例では、データベースをリレーショナル型（表型、テーブルタイプ）としたが、データベースのデータモデルは、他に網型（ネットワークタイプ）、木型（ツリータイプ）があり、これらのデータベースを使ってもよい。この実施例ではデータベースをリレーショナルデータベース（ＲＤＢ）としたため、そのデータベース管理システム（ＤＢＭＳ：Ｄａｔａｂａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）はリレーショナルデータベース管理システム（ＲＤＢＭＳ）である。
この実施例のＷＷＷ−ＲＤＢＭＳ連携システムは、例えば、ＷＷＷブラウザからの要求に応じ、ＷＷＷサーバがプログラムを起動する仕組みであるＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）を用いることができる。また、Ｍｉｃｒｏｓｆｔ社のＷＷＷサーバソフトであるＩＩＳ（Ｉｎｔｅｒｎｅｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｅｒ）を使う場合は、その拡張機能であるＡＳＰ（Ａｃｔｉｖｅ  Ｓｅｒｖｅｒ  Ｐａｇｅｓ）を用いることができる。ＷＷＷサーバソフトがＡｐａｃｈｅの場合は、ＰＨＰ（Ｈｙｐｅｒｔｅｘｔ  Ｐｒｅｐｒｏｃｅｓｓｏｒ）モジュールを組み込むことで実現できる。
請求の範囲第１項に「取引情報を少なくとも前記電子メールアドレス別に集約」とあり、請求の範囲第２項に「取引情報を少なくとも前記口座番号別に集約」とあり、請求の範囲第３項に「取引情報を少なくとも前記口座番号別にファイルに集約」とあるのは、さらに日別や月別等のファイルに分けてもよいという意味である。
請求の範囲第１項、第２項及び第３項の実施例では、メールアドレス別又は口座番号別に加えて、日別に集約するものとしている。
メール送信では、取引情報をメール本文に入れてもよいし、添付ファイルにしてもよい。複数の口座番号の取引情報を同時に同じメールアドレスに送信する場合は、一つのメールとして送信してもよい。その場合、両方の取引情報を一つの本文に入れてもいいし、一つの添付ファイルに集約してもよいし、二つの添付ファイルでもよい。
メールで送信すべき過去のファイルが取引情報提供システムに残存しているような場合、例えば、日別の場合、送信命令プログラムは前日以前の取引情報のファイルを読み、メール送信命令を発行する。送信すべき取引情報がないときは取引情報なしというメールを送ってもよい。利用者に予め選択させる場合は、選択しない場合のデフォルトを決め、ＷＷＷの画面で設定できるようにしてもよい。
送信命令プログラムは集約した取引情報を送信するための条件が整ったときに送信命令を発行するが、運用により多くのパターンが存在し、例えば次のような場合に送信命令を発行するようにプログラムする必要がある。
つまり、口座番号又はユーザＩＤの閉鎖に伴い未送信の取引情報があるとき、取引情報提供システムが設定した日時（何月何日何時に）が到来したとき、取引情報提供システムが設定した一定期間（毎月、毎週、毎日等）が到来したとき、取引情報提供システムが設定した頻度（月に何回等）でそのタイミングが到来したとき、個々の集約ファイルがクローズしたとき、一定期間に受理した取引情報の集約処理が終わったとき、集約ファイルの取引情報が一定件数以上になったとき、集約ファイルの容量が一定量以上になったとき、受理する取引情報に命令を挿入することを許す場合においてメール送信の指示があったとき、取引情報システムのオペレータ又は利用者が指定したスケジュールによるとき、等である。
利用者が自由に送信スケジュールを設定できるようにする場合は、例えばＷＷＷの画面で送信スケジュールを入力させて設定ファイルに保存し、システムタイマーと設定ファイルを監視しながら送信のタイミングを判断するプログラムを常駐プロセスとする。
送信命令プログラムを常駐させない場合は、例えばＵＮＩＸ（登録商標）では、予め指定した日付や時間等にコマンドを自動的に起動する仕組みであるＣＲＯＮを利用して起動させる。
なお、請求の範囲第１項と第２項の実施例では、毎日取引情報を集約して、毎日メール送信することとしているが、必ずしも集約とメール送信を同期させる必要はない。例えば毎日取引情報を集約しても、メール送信は１週間に１回という形でもよい。
請求の範囲第１項と第２項の実施例では、送信命令プログラムは、ＭＴＡの一種であるＳｅｎｄｍａｉｌを呼び出したが、例えばｍａｉｌやｍａｉｌｘのコマンドも利用できる。ただし、配送はＭＴＡに依頼する。
ｍａｉｌコマンド等はＭＵＡ（Ｍａｉｌ  Ｕｓｅｒ  Ａｇｅｎｔ）の一種である。送信命令プログラムは、ｍａｉｌコマンドを子プロセスで実行する。このとき、メールのサブジェクト（題名）、送信先のメールアドレス、ＣＣ（Ｃａｒｂｏｎ  Ｃｏｐｙ）やＢＣＣ（Ｂｌｉｎｄ  Ｃａｒｂｏｎ  Ｃｏｐｙ）のメールアドレス等をコマンドオプションとして、送信する集約ファイルは入力のリダイレクトで与える。あるいは、パイプを用いて、集約ファイルを指定したｃａｔコマンドの標準出力を、ｍａｉｌコマンドの標準入力として、メール送信することも可能である。
利用者は利用者端末から、メールソフトを用いて自分の受信メールサーバから取引情報のメールを受信したり、ＦＴＰクライアントソフトで取引情報提供システムのＦＴＰサーバに接続して取引情報の集約ファイルをダウンロードしたり、ＳＭＢクライアントソフトで取引情報提供システムのＳＭＢファイルサーバに接続して集約ファイルにアクセスしたり、ＷＷＷブラウザソフトで取引情報提供システムのＷＷＷサーバに接続してデータベースを利用したり、する。
取引情報提供システムがＴｅｌｎｅｔによるアクセスを利用者に開放している場合、利用者は利用者端末からＴｅｌｎｅｔクライアントソフトでＴｅｌｎｅｔサーバに接続して、ＵＮＩＸ（登録商標）の基本コマンドであるｃａｔコマンドを入力して、集約ファイルの内容を表示したり、集約ファイルをｍａｉｌコマンドでメール送信したり、その他様々な処理をすることができる。
取引情報のエラー対策としては、受理する取引情報や利用者へ送信する取引情報に今回分又は前回分を含めた連番を付ければ、漏れや重複のチェックに利用できる。取引情報の数値項目を合計した情報を添付する等、エラー検出の対策を講じるのが好ましい。
エラーチェックを通らない取引情報、データベースに反映できない取引情報、エラーメールで返信された取引情報は、発信者に通知又は返戻するのが好ましい
エラーメールは再送信を試みるか、廃棄して新たに追加されたデータも含めて送信してもよい。一定回数以上失敗した場合は送信を停止する。
取引情報は取引発生後、すぐ受理できるとは限らない。取引情報の入力が取引と同時に行われない場合や、営業時間終了後にバッチ処理で取引情報提供システムに取引情報を一括送信する場合もある。利用者がメールで欲しい又はデータベースに反映して欲しい時までに受理や集約ができないこともある。
取引情報提供システムに届いた日時で集約する場合はともかく、取引日時や入力日時で集約する場合、当該期間分の取引情報の受理が完了したという保証はない。メール送信後に受理することもあり、遅れた取引情報は次回送信分に含めるか、別途送信するしかない。
取引情報に取引日時を含む場合で、当該取引日時が海外の現地時間のときは、自国の時間帯に変換する方がよい。日本時間の１日で集約してメール送信する場合や、日本時間で範囲指定してデータベース検索する場合に扱いやすくなる。
当日分の取引にかかる取引情報が全て届いたという判断は、全ての取引情報システムから送信完了の通知をもらわないとできないことであるし、取引情報システムによっては当日分の取引にかかる取引情報をすぐに処理するとは限らないから、不可能に近い。
しかし、当日受理したという事実は取引情報提供システムにとって明確であるから、請求の範囲第１項から第３項までの実施例においては「当日届いた取引情報の集約が完了」というように、当日受理したことをもって判断している。ただし、取引情報システムからの取引情報が一括のファイル転送で当日と翌日にまたがって行われた場合は、どちらかに入れないと、ファイルの途中で当日と翌日に分けるのもややこしい。
取引情報システムが常時接続し、取引情報を１件づつ受理するような場合は、その時刻によって当日と翌日に分ける。当日受理した取引情報を翌日になってから一気に処理する方法は、特定の時間帯に処理が集中する。処理の分散ということでは、集約プログラムを常駐プロセスとして、取引情報の受理が終わってクローズされた受理ファイルから集約処理をしてしまうことが好ましい。
取引情報を送ってくる取引情報システムの発信者は、取引情報提供システムに予め登録した者に限定することが好ましい。特定できない発信者からは、不正な取引情報を受理する可能性がある。専用回線を通じて取引情報を受理したり、認証機能がある通信プロトコルで受理したり、電子署名を用いて受理したりすることは、発信者を特定できるので好ましい。
取引情報の利用者は特定の一人とは限らない。法人等では権限や担当業務に応じて複数人が利用したり、親権者が未成年の子の取引情報をチェックしたり、破産管財人や成年後後見人が取引情報を見ることがある。サーバアクセスにより特定の取引情報を利用できるのは取引した本人又は関係者で、予め利用者としての登録が必要である。公共機関の取引情報で広く一般に公開する場合や、統計的に加工された情報は誰でも閲覧のみ可能にしてもよい。
メールによる取引情報の提供は、送信先のメールアドレスを有する者が利用者として登録しているとは限らない。取引情報に付加されたメールアドレスや取引情報提供システムに用意したテーブルに記憶されたメールアドレスが間違っていれば、迷惑メールになる可能性がある。
データベースについて、例えば、法的に取引情報提供システムのデータベースが取引記録として認められた場合、取引情報の脱落や改竄を防止するため、取引情報は必ずデータベースに反映させ、その修正の記録もすべて保存して取り出せる運用や、利用者本人には変更不可能なデータベースを構築することもありえる。
請求の範囲第４項の実施例では、受理した取引情報を無条件にデータベースの口座番号別の集約テーブルにインサートしているが、例えば受理した取引情報を一旦仮口座のテーブルに入れる運用も可能である。この場合、利用者に仮口座のテーブルの取引情報を確認させ、本口座の集約テーブルに反映するか、ゴミ箱テーブルに移すか、完全に消去するか、の選択をさせることになる。
なお、利用者に本口座の取引情報の追記、削除、変更を許す運用をする場合、取引情報の修正ミスを防止するため、少なくとも一つ前の状態に戻す機能を設けることが好ましい。
利用のイメージとしては、次のようになる。ＷＷＷのトップページからユーザＩＤとパスワードでログインすると、利用権限のある口座番号の一覧が表示される。入力画面では手入力で取引情報をデータベースに入れることができる。仮口座、本口座、ゴミ箱テーブルがある。本口座は複数ありえるが、仮口座やゴミ箱は一つでもよい。仮口座の取引情報を本口座に移動する画面があり、取引内容や送信元を目で確認して、追加や廃棄ができる。廃棄分はゴミ箱に入り、ゴミ箱のクリア操作で完全削除する。
本発明では、取引情報システム、取引情報提供システム及び利用者端末システムの処理の分担範囲を明確することが好ましい。例えば、受理する媒体の種類、データフォーマット、タイミング、どちらから接続するか、通信プロトコル、発生の都度リアルタイムに取引情報を送信するのか、受理した取引情報の保存期限、取引情報に含まれるコードの変換はどこでするのか等である。
以上の実施例では、受理手段と集約手段を分け、受理した取引情報は一旦受理ファイルに保存する形態としている。これは、取引情報提供システムを構築する場合、汎用コンピュータを使う場合も、ＵＮＩＸ（登録商標）マシン等を使う場合も、こういう形態を取ることが一般的であろうということと、受理手段を構成する媒体読取プログラムや通信プログラムに既存のソフトウェアを使おうとしているためである。
つまり、媒体読取プログラムはコンピュータのオペレーティングシステムに用意されたユーティリティプログラム等の汎用的なプログラムを使い、受信プログラムはＦＴＰサーバプログラム等の汎用的なプログラムを使うということである。しかし、受理手段を構成するプログラムと集約プログラムを一体として作成することもできる。取引情報を受理しながら直接集約ファイルに書き込むことも可能であり、この場合は受理ファイルは不要となる。
また、ＵＮＩＸ（登録商標）には、あるプログラムの出力を他のプログラムの入力にできるパイプという機能があり、受理手段を構成するプログラムと集約プログラムをパイプでつないだ場合は、受理ファイルのような中間ファイルを生成しないシステムにすることも可能である。
本発明では、取引情報を空間的時間的に集約する。空間的に集約するというのは、空間軸に存在する１以上複数の取引情報システムからの取引情報を集約するということである。時間的に集約するというのは、時間軸上の一定範囲に存在する取引情報を集約するということである。
請求の範囲各項の「１以上の取引情報システム」は１の場合を含むが、１の場合も意味がある。本発明の取引情報提供システムが、たった一つの取引情報システムから取引情報を受理する場合であっても、時間軸方向には取引情報を集約して提供できるからである。
以上の説明は、取引情報提供システムが１台のコンピュータで構築されている例を述べたが、複数コンピュータに負荷分散や機能分散してもよい。取引情報を受理する専用コンピュータや取引情報を蓄積するファイルサーバやデータベースサーバの専用機を置いたり、他が運営管理するデータベースサーバやファイルサーバを用いることも可能である。また、メールとサーバアクセスの両方のサービスをすることも可能である。
産業上の利用可能性
本発明により、利用者により便利な形で取引情報を提供することができる。
一つは、１以上の取引情報システムからの取引情報を集約することにより、てんでに多くのメールが利用者に届くこと及び取引情報システム毎のメール形式や利用者の登録になることを防ぎ、利用者が受け取った取引情報のメールの取り扱いが楽になる。
もう一つは、取引情報システムからの取引情報を集約し、サーバアクセスにより利用させることにより、従来のメールによる提供に比べ、より便利で高度な利用を可能としたことである。
【図面の簡単な説明】
第１図は、本発明の概念図であり、第２図から第５図は、本発明の請求の範囲第１項から第４項にそれぞれ対応する好ましい実施例を示す図である。
【図１】
2003001422.tif 000003
【図２】
2003001422.tif 000004
【図３】
2003001422.tif 000005
【図４】
2003001422.tif 000006
【図５】
2003001422.tif 000007
【手続補正書】
【提出日】平成15年7月7日(2003.7.7)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
利用者の端末に取引情報を提供する方法であって、１以上の取引情報システムから、電子メールアドレス付きの取引情報を受理し、前記受理した取引情報を少なくとも前記電子メールアドレス別に集約し、送信命令により、前記集約した取引情報を少なくとも前記電子メールアドレスあてにメール送信する、ことを特徴とする取引情報の提供方法。
【請求項２】
利用者の端末に取引情報を提供する方法であって、１以上の取引情報システムから、口座番号付きの取引情報を受理し、前記受理した取引情報を少なくとも前記口座番号別に集約し、送信命令により、前記集約した取引情報を前記口座番号に対応した電子メールアドレスあてにメール送信する、ことを特徴とする取引情報の提供方法。
【請求項３】
利用者の端末に取引情報を提供する方法であって、１以上の取引情報システムから、口座番号付きの取引情報を受理し、前記受理した取引情報を少なくとも前記口座番号別にファイルに集約し、前記利用者の端末から、前記利用者の利用権限がある口座番号の、前記集約したファイルにアクセスさせる、ことを特徴とする取引情報の提供方法。
【請求項４】
利用者の端末に取引情報を提供する方法であって、１以上の取引情報システムから、口座番号付きの取引情報を受理し、前記受理した取引情報をデータベースに集約し、前記利用者の端末から、前記利用者の利用権限がある口座番号の、前記データベースに集約した取引情報に、アクセスさせる、ことを特徴とする取引情報の提供方法。
【請求項５】
さらに、前記受理した取引情報に含まれた取引日時を、自国の時間帯に変換することを含む、請求の範囲１から４のいずれかに記載した取引情報の提供方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００２
【補正方法】変更
【補正の内容】
【０００２】
取引情報を集約して利用者に提供する（以下、この方法により取引情報を利用者に提供するコンピュータシステムを取引情報提供システムと言う。）。また、取引情報の提供形態として、従来のメールによる提供に加えて、サーバアクセスによる提供を設けた。
本発明は、メールによる提供の場合、１以上の取引情報システムから、メールアドレス付きの取引情報を受理し、少なくともメールアドレス別に集約し、送信命令により少なくとも前記メールアドレスに取引情報を送信する。
また、本発明は、メールによる提供の場合、１以上の取引情報システムから、口座番号付きの取引情報を受理し、取引情報を少なくとも口座番号別に集約し、送信命令により当該口座番号に対応したメールアドレスに取引情報を送信する。
また、本発明は、サーバアクセスによる提供の場合、１以上の取引情報システムから、口座番号付きの取引情報を受理し、少なくとも口座番号別のファイルに集約し、利用者の端末から、利用者に利用権限のある口座番号のファイルにアクセスさせる。
また、本発明は、サーバアクセスによる提供の場合、１以上の取引情報システムから、口座番号付きの取引情報を受理し、データベースに集約し、利用者の端末から、利用者に利用権限のある口座番号に対応するデータベースに集約された取引情報にアクセスさせる。
また、本発明は、以上の発明に、さらに、受理した取引情報に含まれた取引日時を、自国の時間帯に変換することを含む。
図面の簡単な説明
第１図は、本発明の概念図であり、第２図から第５図は、本発明の請求の範囲第１項から第４項にそれぞれ対応する好ましい実施例を示す図である。
発明を実施するための最良の形態
本発明をより詳細に説述するために、添付の図面に従ってこれを説明する。


【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
本発明において取引情報とは、店頭での対面取引、ＡＴＭ等の自動取引装置や自動販売機での無人取引、郵便、電話、ＦＡＸ、インターネット等による通信取引、等の取引に伴い発生したコンピュータデータである。
その内容は、例えば、取引日、取扱日、曜日、時刻、取引者名、取引場所、店名、電話番号、機械番号、レジ番号、預貯金口座番号、会員番号、担当者名、取引内容、品名、サービス名、仕様、単価、数量、価格、消費税、合計金額、入金額、出金額、振込金額、預入れ額、貸出し額、お釣の額、残高、利率、金種、サービスポイント、コメント、関連情報、関連情報のホームページのＵＲＬ、各種手数料、決済データ、等の項目（フィールド）又は要素（エレメント）と呼ばれるものからなる。
本発明において、集約はこれらの項目の並びや要素のタグ名を一致させることを含むが、取引情報のフォーマットが標準化されていない場合は、変換処理をする必要が生じるので、予め、例えばＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅ）形式なら項目の並び順を統一し、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書なら少なくともタグ名を統一するか、その文書型定義（ＤＴＤ：Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）又はＸＭＬ  Ｓｃｈｅｍａ等のスキーマを標準化するのが好ましい。
パソコンを利用者端末に使う場合、普通、ＪＩＳコード、シフトＪＩＳコードやＥＵＣコード、ＩＳＯ／ＩＥＣ−１０６４６（Ｕｎｉｃｏｄｅ）等の文字コードには対応しているが、汎用コンピュータで使われるＥＢＣＤＩＣコードやメーカー独自の２バイト漢字コードには対応していないので、文字コードの変換処理が必要になることがある。汎用コンピュータでは、ゾーン１０進、パック１０進、バイナリ等のデータ型で数値を持つことがあるが、ＣＳＶ形式やＸＭＬ形式等パソコンで利用できるようにするには、当該数値を数字の文字列に変換する必要がある。
その他、空白、ＴＡＢ区切り、カンマ区切りのような項目間の区切り文字を変換


【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
途送信するしかない。
取引情報に取引日時を含む場合で、当該取引日時が海外の現地時間のときは、自国の時間帯（利用者端末又は取引情報提供システムが属するタイムゾーン）に変換する方がよい。例えば、日本時間の１日で集約してメール送信する場合や、日本時間で範囲指定してデータベース検索する場合に扱いやすくなる。
当日分の取引にかかる取引情報が全て届いたという判断は、全ての取引情報システムから送信完了の通知をもらわないとできないことであるし、取引情報システムによっては当日分の取引にかかる取引情報をすぐに処理するとは限らないから、不可能に近い。
しかし、当日受理したという事実は取引情報提供システムにとって明確であるから、請求の範囲第１項から第３項までの実施例においては「当日届いた取引情報の集約が完了」というように、当日受理したことをもって判断している。ただし、取引情報システムからの取引情報が一括のファイル転送で当日と翌日にまたがって行われた場合は、どちらかに入れないと、ファイルの途中で当日と翌日に分けるのもややこしい。
取引情報システムが常時接続し、取引情報を１件づつ受理するような場合は、その時刻によって当日と翌日に分ける。当日受理した取引情報を翌日になってから一気に処理する方法は、特定の時間帯に処理が集中する。処理の分散ということでは、集約プログラムを常駐プロセスとして、取引情報の受理が終わってクローズされた受理ファイルから集約処理をしてしまうことが好ましい。
取引情報を送ってくる取引情報システムの発信者は、取引情報提供システムに予め登録した者に限定することが好ましい。特定できない発信者からは、不正な取引情報を受理する可能性がある。専用回線を通じて取引情報を受理したり、認証機能がある通信プロトコルで受理したり、電子署名を用いて受理したりすることは、発信者を特定できるので好ましい。
取引情報の利用者は特定の一人とは限らない。法人等では権限や担当業務に応じ




【国際調査報告】
2003001422.tif 000008
2003001422.tif 000009
2003001422.tif 000010
2003001422.tif 000011