【手続補正書】
【提出日】平成15年5月22日(2003.5.22)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の名称】有価証券の真性さを確認して処理する方法および装置
【特許請求の範囲】
【請求項１】有価証券を処理する複数の端末処理装置と有価証券の真正さを表示する保証情報を集中して管理する１又は複数の情報提供機関とを通信回線で接続し、端末処理装置において有価証券の真正さを確認して処理する方法において、前記端末処理装置と前記情報提供機関との双方に接続される情報処理組織を設け、その情報処理組織は、前記情報提供機関に繰り返し接続して、保証情報をリアルタイムに取得して蓄積し、端末処理装置からの問い合わせに応じて、該当する有価証券に関して蓄積した保証情報を回答するとともに、該当する有価証券について問い合わせがあった事実に関する情報をも蓄積し、問い合わせした端末処理装置へは該当する有価証券について他の端末処理装置から問い合わせがあった事実に関する情報をも併せて回答することを特徴とする、有価証券の真正さを確認して処理する方法
【請求項２】前記問い合わせは、有価証券の番号の全部又は一部の桁によることを特徴とする請求項１に記載の有価証券の真正さを確認して処理する方法
【請求項３】前記有価証券の番号は、前記端末処理装置に付属するＯＣＲによって読み取るとともに、問い合わせは有価証券の番号の一部の桁の数字によることとし、回答は前記一部の桁の数字に基づいて検索された結果であることを特徴とする請求項２に記載の有価証券の真正さを確認して処理する方法
【請求項４】前記情報処理組織は、前記複数の情報提供機関への送信要求又は少なくとも１つの情報提供機関からの受信要求によりリアルタイムに保証情報を得て蓄積する中間処理装置であることを特徴とする請求項１〜３に記載の有価証券の真正さを確認して処理する方法
【請求項５】有価証券を処理する複数の端末処理装置と、前記端末処理装置に通信回線を介して接続され、有価証券の真正さを表示する保証情報を管理する１又は複数の情報提供機関とを備える有価証券の真正さを確認して処理する装置であって、前記端末処理装置と前記情報提供機関との双方に接続するように情報処理組織を設け、前記情報処理組織は、前記情報提供機関に繰り返し送信要求するか又は前記情報提供機関から繰り返し受信要求を受けて、前記保証情報を蓄積する第１の蓄積手段と、該当する有価証券に関する端末処理装置からの問い合わせ情報を蓄積する第２の蓄積手段とを備え、さらに、端末処理装置からの問い合わせに対して、前記第１の蓄積手段および第２の蓄積手段における該当する有価証券についての情報を検索し、併せて回答する手段を有することを特徴とする、有価証券の真正さを確認して処理する装置
【請求項６】前記端末処理装置と前記情報処理組織とは、クライアント・サーバーシステムである請求項５に記載の有価証券の真正さを確認して処理する装置
【請求項７】有価証券を処理する店頭側の処理装置と有価証券の保証情報を集中して保有する１又は複数の情報提供機関との双方に回線接続を有する情報処理組織であって、情報提供機関に繰り返し接続して情報提供機関から保証情報を取得して蓄積する手段、店頭側からの検索要求に応じ、蓄積した保証情報を店頭側に提供し、併せて、店頭側から検索要求があった事実および店頭において事故があった場合にはその事実を蓄積し、それらを情報提供機関に送信する手段を備え、さらに、前記店頭側から検索要求があった事実および店頭において事故があった場合にはその事実を併せて店頭側に回答する手段を備えることを特徴とする、有価証券の真正さに関連する保障情報を処理する情報処理組織である中間処理装置
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、有価証券とくに株式取引において、紛失、盗難または再発行などにより本来、売買できない株券、債券その他の有価証券を早期に発見し、損害を未然に防止する方法および装置に関する。
【０００２】
【従来の技術】証券会社において、外部から売却を前提に持ち込まれた株券を処理するにあたり、真性さの保証が必要である。ところが、株券は、裏書きされた氏名と現に株券を所有する人物とが一致しなくても、真正として売買される。したがって、精巧に偽造された株券、紛失、盗難または再発行などにより本来、売買できない株券や債券であっても、その事実が店頭で知られることなく、売却等の処理がされてしまうことがある。
【０００３】
図６に従来実施されていたシステムの構成を示す。株券の真性さを表示する保証情報を得るため、店頭では、たとえば株券を処理するに際して、店頭の端末処理装置［６０２］と保証情報を集中して管理する情報提供機関［６０７］の事故株データベース（ＤＢ）［６０８］とを通信回線で接続し、店頭の端末処理装置によって情報提供機関ＤＢから保証情報を貰い、株券などの有価証券の真正さを確認したうえで処理することが、普通行われる。いますこし詳しく説明すると、店頭では当該株券を本社におくる。一方、情報提供機関［６０７］では、日本証券業協会［６０９］および信託銀行［６１０］等から送られる事故株券等の情報を得てＤＢ［６０８］として管理する。本店では情報提供機関ＤＢに接続している端末処理装置を使って株券の真正性及び事故株券との関連性につき照会し、回答を得た後に売却するという手順を踏んでいた。事故は、いつ起こるかわからない。事故が起こる時点は全くランダムである。そのことで、以下に説明するように、事故株券の発見に時間がかかり、調査後に事故情報が届いたり、すでに売買されていることもあり、その場合には多大な損害が発生した。
【０００４】
以下、盗難を例として、事故が起こるプロセスや、その情報が証券会社店頭に通知される経過を説明する。
《事故が起こるプロセス（従来の例）》
［当日］
株券が盗難に遭った当日、被投資家は当然まだ気がついていない。その状態で、株券が支店店頭に持ち込まれる。大量に持ち込まれることもある。支店店頭では、株券が事故株でないか問い合わせするため、株券を本店に送付する。一方、投資家［６１２］が盗難事件に気づいて、警察［６１３］および取引する証券会社［６１１］に連絡する。盗難事故があった情報は、信託銀行［６１０］、日本証券業協会［６０９］に知らされる。
［翌日］
持ち込まれた株券（実は事故株券）が、本店に到着する。本店は、株券情報を自社の事故株マスターに問い合わせるが、事故株マスターに事故の事実は蓄積されていない。盗難事故があった情報は、日本証券業協会の事故株を管理する情報提供機関ＤＢ［６０８］に登録依頼される。しかし、証券会社からの問い合わせに応じ得る状態ではない。
［翌翌日］
証券会社本店は、早朝再度問い合わせを行う。これに対して、自社の事故株マスターからの回答では、事故株券ではあることは未だ知らされる状態にない。この時点で、盗難事故があった情報は、日本証券業協会の事故株ＤＢ［６０８］に登録はされる。
［４日目］
４日目は、持ち込まれた株券の売買金額の受け渡し日である。しかし、日本証券業協会の事故株ＤＢ［６０８］に登録された情報は、未だ各証券会社の店頭にまでは通知されていず、金の受け渡しが行われてしまう。なお、それまでの株券の保管状態によっては、盗難事故が発見されないこともあり、その場合、トラブルはずっと後まで波及することになる。結局、盗難事故があった情報は、事故当日から相当遅れて判明することになる。参考までに、事故株券情報として警察等から送られてくる情報には、次の内容が含まれている。
知らせがあった日付
知らせ番号（事件を表示する番号）
盗難の事実
盗難の日時
盗難株券の銘柄
盗難株券の枚数
盗難株券の記番号
事故の状況によっては、すべての情報が明確になっているとは限らない。例えば、盗難株券の銘柄、記番号などの全部または一部がはっきりしないことも多い。
【０００５】
【発明が解決しようとする課題】株券について盗難事件があったなどの事実は、信託銀行［６１０］および日本証券業協会［６０９］を通じて情報提供機関ＤＢ［６０８］に蓄積され、管理される。情報提供機関ＤＢはひとつとは限らず、地域ごと、業種ごと、あるいは通信回線契約形態ごとに複数にわかれ、それぞれでデータを分配あるいは共有することもある。これら１または複数の情報提供機関ＤＢにおいて、データは、有価証券の真正さを表示する保証情報として管理され、定期的に各証券会社店頭に通知される。しかしながら、預かった株券の真性さを確認するのは主に手作業によるのが実情であり、これが非常な手数を要していた。作業にコンピュータを導入することは行われているが、株券を視認して確認する作業自体は手作業によらざるを得ない。その主たる原因は、情報提供機関ＤＢから取得する保証情報の取得時期がリアルタイムでないことにあった。すなわち、証券の確認に特有な手順を全て行うと、該当株券を入庫してから売却するまで必然的に２〜３日を要した。あまり遅れると、売却のタイミングを逸して顧客の利益を害するおそれもある。情報検索のための時間を短縮すると、事故株を知らずに処理することがおこる。
【０００６】
また、情報提供機関ＤＢに入力される事故株券等の情報は、事故に遭った投資家［６１２］本人から日本証券業協会および信託銀行を通じて通知されたものであるため、情報の取得が遅れ、株券が証券会社に持ち込まれた時点では、事故株券として情報化されていず、真正かつ適正な株券と区別できずに売却されてしまい、後、しばらくして事故株券であることが判明し、その時点では売却主と連絡がとれないことが多く、そのような売却時からの時間の経過に起因して、トラブルが増幅される原因となる場合があった。厳密に盗難等がないことを確認するには、株券を売却した後も、相当期間検索を継続する必要がある。これらの事情のため、従来のシステム［図６］では、不正な株券を預かって処理してしまう危険は避けることが困難であった。本発明は、以上のようなトラブルによる損害を未然に防止し、証券取引の安全性を高めることを目的とする。
【０００７】
【課題を解決する手段】本発明は、上記した課題を解決するために、株券等の有価証券を処理する複数の店頭端末処理装置と保証情報を集中して管理する情報提供機関ＤＢとの間に情報処理組織を介在させた。そして、情報処理組織は、前記情報提供機関ＤＢに定期又は不定期に繰り返しアクセスして保証情報をよりリアルタイムに取得して蓄積し、店頭の端末処理装置からの問い合わせに応じて該当する有価証券に関して最新に蓄積して更新した保証情報を回答するとともに、該当する有価証券について問い合わせがあった事実を計数して蓄積し、問い合わせした端末処理装置へは該当する有価証券について他の端末処理装置から問い合わせがあった件数等の情報をも併せて回答することによって、有価証券の真正さをより正確に認識して迅速に処理するものである。他の端末処理装置から問い合わせがあった事実を蓄積することは、事故株券等の発見に重要な意味を持つ。たとえば、別の支店の端末から同番号の株券について問い合わせがあった場合（通常あり得ないことである。）、要注意と判断される。
【０００８】
【発明の実施の形態】
請求項１の発明は、有価証券を処理する複数の端末処理装置と有価証券の真正さを表示する保証情報を集中して管理する１又は複数の情報提供機関とを通信回線で接続し、端末処理装置において有価証券の真正さを確認して処理する方法において、前記端末処理装置と前記情報提供機関との双方に接続される情報処理組織を設け、その情報処理組織は、前記情報提供機関に繰り返し接続して、保証情報をリアルタイムに取得して蓄積し、端末処理装置からの問い合わせに応じて、該当する有価証券に関して蓄積した保証情報を回答するとともに、該当する有価証券について問い合わせがあった事実に関する情報をも蓄積し、問い合わせした端末処理装置へは該当する有価証券について他の端末処理装置から問い合わせがあった事実に関する情報をも併せて回答することを特徴とする、有価証券の真正さを確認して処理する方法として実施される。
【０００９】
請求項２の発明は、前記問い合わせは、有価証券の番号の全部又は一部の桁によることを特徴とする請求項１に記載の有価証券の真正さを確認して処理する方法として実施される。
【００１０】
請求項３の発明は、前記有価証券の番号は、前記端末処理装置に付属するＯＣＲによって読み取るとともに、問い合わせは有価証券の番号の一部の桁の数字によることとし、回答は前記一部の桁の数字に基づいて検索された結果であることを特徴とする請求項２に記載の有価証券の真正さを確認して処理する方法として実施される。
【００１１】
請求項４の発明は、前記情報処理組織は、前記１又は複数の情報提供機関への送信要求又は少なくとも１つの情報提供機関からの受信要求によりリアルタイムに保証情報を得て蓄積する中間処理装置であることを特徴とする請求項１〜３に記載の有価証券の真正さを確認して処理する方法として実施される。
【００１２】
請求項５の発明は、有価証券を処理する複数の端末処理装置と、前記端末処理装置に通信回線を介して接続され、有価証券の真正さを表示する保証情報を管理する１又は複数の情報提供機関とを備える有価証券の真正さを確認して処理する装置であって、前記端末処理装置と前記情報提供機関との双方に接続するように情報処理組織を設け、前記情報処理組織は、前記情報提供機関に繰り返し送信要求するか又は前記情報提供機関から繰り返し受信要求を受けて、前記保証情報を蓄積する第１の蓄積手段と、有価証券に関する端末処理装置からの問い合わせ情報を蓄積する第２の蓄積手段とを備え、さらに、端末処理装置からの問い合わせに対して、前記第１の蓄積手段および第２の蓄積手段における該当する有価証券についての情報を検索し、併せて回答する手段を有することを特徴とする、有価証券の真正さを確認して処理する装置として実施される。
【００１３】
請求項６の発明は、前記端末処理装置と前記情報処理組織とは、クライアント・サーバーシステムである請求項５に記載の有価証券の真正さを確認して処理する装置として実施される。
【００１４】
請求項７の発明は、有価証券を処理する店頭側の処理装置と有価証券の保証情報を集中して保有する１又は複数の情報提供機関ＤＢとの双方に回線接続を有する情報処理組織であって、情報提供機関ＤＢに繰り返し接続して情報提供機関ＤＢから保証情報を取得して蓄積する手段、店頭側からの検索要求に応じ、蓄積した保証情報を店頭側に提供し、併せて、店頭側から検索要求があった事実および店頭において事故があった場合にはその事実を蓄積し、それらを情報提供機関ＤＢに送信する手段を備え、さらに、前記店頭側から検索要求があった事実および店頭において事故があった場合にはその事実を併せて店頭側に回答する手段を備えることを特徴とする、有価証券の真正さに関連する保障情報を処理する情報処理組織である中間処理装置として実施される。
【００１５】
【実施例１】図１に本発明の第１の実施例の全体構成を示す。図１の例では、本発明の特徴部である保証情報を処理する情報処理組織（中間処理装置）は、本店のサーバー・コンピュータ［１０４］が該当する。支店（クライアント）店頭［１０１］［１０２］では一般的な卓上型コンピュータを端末処理装置として多数台備え、それらは本店のコンピュータ［１０４］に接続されている。本店のコンピュータは、事故株情報を内部に収納できる汎用サーバー型コンピュータであり、これには支店店頭の端末処理装置と同じ卓上型コンピュータが接続されるとともに、管理用の端末処理装置［１０３ａ］［１０３ｂ］も接続されている。本店のサーバー・コンピュータには、たとえば外部記録媒体を接続して事故株マスター［１０６］とし、情報提供機関ＤＢ［１０８］と送受信するデータを蓄積して事故株券情報を収納し、管理する。そのような自社事故株マスター［１０６］は、当初の基礎的構造としては、本店のコンピュータの銘柄マスター［１０５］から、支店（クライアント）または本店（サーバー）の端末を介して、銘柄および顧客コードを自動複写機能により取得すれば、迅速かつ正確にデータの入力を行え、これによって、構築できる。構築した基礎的構造に、外部にある情報提供機関ＤＢ［１０８］から事故株データを、また端末処理装置から問い合わせデータを、いずれも合成蓄積したものが事故株マスター［１０６］となる。図１のシステムにおいて、ある時点で売却を依頼された株券が支店または本店の店頭に持ち込まれたとする。店頭では端末処理装置より株券識別番号（記番号）等のデータは、キー入力または光学読み取り装置（ＯＣＲ）もしくはセンサーによって入力し、電子データに変換する。電子データ化した株券の記番号等のデータは、本店のサーバー・コンピュータ［１０４］に転送し、本店事故株券データ（自社事故株マスター）と照合する。本店のサーバー・コンピュータは、送信データ蓄積部［１０４ａ］を介して社外の情報提供機関ＤＢ［１０８］と繰り返し接続し、保証情報の取得を行う。そのために、事故株マスター［１０６］には、予め、本店サーバー・コンピュータ［１０４］により、社外の情報提供機関ＤＢ［１０８］が保有する株券データが取得、蓄積され、これを保証情報として、証券会社店頭［１０１］等に迅速に与えることができるわけである。このシステムによって、支店（クライアント）店頭の端末処理装置から本店のサーバー・コンピュータに対する問い合わせは、株券データの検索のかたちで行う。
【００１６】
図７に、検索を含むローカルチェック処理構成を示す。各部分の記号は図１と同じである。本店のサーバーコンピュータ［１０４］は、事故株券マスタ［１０６］を有する。事故株券マスタ［１０６］は、当初には、銘柄マスター［１０５］から銘柄および顧客コードのデータを自動複写機能によって取得し、入力されている。管理端末［１０３］から入力されることもある。そのうえで、店頭の端末処理装置［１０１］［１０２］に持ち込まれた株券等の有価証券の番号が、キー入力又はＯＣＲによって読み取られる。同番号の重複（ダブリ）があれば、チェックしてメッセージ（ＭＳＧ）を出す。重複チェックを受けたデータは、送信データ蓄積部［１０４ａ］にインサート処理され、日々累積する。累積したデータについて、事故株券データ（事故株券マスタ）［１０６］ー［１０６］を一件ずつ検索する。本店サーバー・コンピュータ［１０４］は、送信データ蓄積部［１０４ａ］を介して社外の情報提供機関ＤＢ［１０８］（図１）と繰り返し接続され、有価証券に関する保証情報の取得を行っている。事故株マスター［１０６］には、予め、本店のサーバー・コンピュータ［１０４］により、社外の情報提供機関ＤＢ［１０８］が保有する保証情報がリアルタイムに取得、蓄積され、証券会社店頭［１０１］等に迅速に与えることができる。
【００１７】
検索の結果、事故株マスター［１０６］を接続した本店サーバー・コンピュータ［１０４］により、社外の情報提供機関ＤＢ［１０８］から送受信データ蓄積部［１０４ａ］を介して取得された株券データと、店頭［１０１］［１０２］に持ち込まれた株券データとが照合される。このとき情報提供機関ＤＢ［１０８］から取得して自社事故株マスター［１０６］に蓄積したデータは、必ずしも完璧なものではない。たとえば、盗難に遭った株券の記番号が、一部の桁しか判明していないこともある。そこで、検索は全部一致または部分一致検索を試みるのがよい。
【００１８】
情報提供機関ＤＢには、日本証券業協会［１０９］および信託銀行［１１０］を通じて事故株の情報が通知されているが、たまたま証券会社の本社サーバー・コンピュータ［１０４］から送信要求があった時点で、事故株である情報を情報提供機関ＤＢ［１０８］が有していず、検索の直後に情報を得ることがある。そのような場合に対処して、検索は、必要に応じて、定期的または不定期に、任意の回数、繰り返して行うことができるようにする。
【００１９】
また、必要と認められた場合、後日の事故株券情報の検索において、自動または任意に照合が実行できることが望まれる。自動的に繰り返し事故株券情報と参照することによって、事故の情報をよりリアルタイムに取得し、被害を一層未然に防ぐことができる。
【００２０】
株券盗難の事実は、他から知らされる場合ばかりでなく、自社内で判明する場合もある。そのときは、事故の情報は、以上と同じ通信路を経由して、逆方向に、店頭端末処理装置［１０１］から本店サーバー・コンピュータ［１０４］へ、また、本店サーバー・コンピュータ［１０４］から情報提供機関ＤＢ［１０８］へ送信される。問い合わせがあった株券は、事故株であると判明しないものであっても、現に市場を動いているわけであり、また問い合わせの対象となるような確かめるべきなんらかの事項を伴う場合の多い株券である。したがって、該当株券について問い合わせがあった事実やその回数を蓄積することによって、その株券に関する事故が仮にたまたま発生しても、トラブルの回避に役に立つことが考えられる。したがって、問い合わせがあった事実は、自社事故株マスター［１０６］に蓄積し、また必要であれば、情報提供機関ＤＢ［１０８］に提供する。
【００２１】
信用性を高めるため、任意の時間が経過した場合に、送受信データ蓄積部［１０４ａ］は保証情報を更新するべきである。１度目のチェック以降に情報提供機関ＤＢ［１０８］がたまたま事故情報を更新することがあるが、その場合も、自社サーバー・コンピュータ［１０４］から複数回チェックを繰り返すことによって、更新後の情報が取得でき、より被害に遭いにくくなる。繰り返し検索照合を実行するため、支店（クライアント）の端末処理装置［１０１］にも、また本店のサーバー・コンピュータの送受信データ蓄積部［１０４ａ］にも、自動ダイアリング、リトライ機能を装備させる。
【００２２】
事故株券情報はネットワーク上の複数サーバーによる共有も可能である。以上の手順により、自社内において照会結果が瞬時に分かるため、業務が短時間で完結する。また、自社の事故株マスター［１０６］に蓄積されたデータにより照会を行うため、既存のサービス提供会社に支払う料金が節約できる。また、ファジー入力機能により不鮮明な株券データにおいても検索が行える。以上の構成により、とくに大量の株券が持ち込まれた場合に、事務処理をすばやく行うことができる。
【００２３】
本店（サーバー）［１０４］に問い合わせた株券データを支店（クライアント）［１０１］等から取り消し、または訂正する必要が生じる場合がある。その場合、他の端末処理装置や他の支店からは問い合わせデータを取り消すことができないようにする。このような必要は、売却および担保価値の確認のために検索を依頼した株券データを、なんらかの都合で売却を断念または売却株券を入れ替えた場合に生ずる。このときは、検索を依頼した端末処理装置のみに訂正取消の権限を与え、それ以外の店頭端末からは誤ってデータを消去することが無いように、端末処理装置番号、取扱者名あるいはなんらかのＩＤやパスワード定義する。これにより、万全のデータ保護機能を装備させる。
【００２４】
将来、同種の事故株券ＤＢ［１０８］が複数設置された場合、内部データの共有を規定することができる。株券の売買における決済日までの期間中に他の支店クライアント（端末）［１０２］等より同番号の問い合わせあった場合、注意事項として重複チェック機能を持たせると便利である。入力データの重複チェック機能および、ネットワーク化された各サーバーにおいても入力データの重複チェックをすることができる。
【００２５】
すべての検索結果において事故株券で無いと判断されたものは、証券取引において安全であると判断できる。なお、本店のサーバー・コンピュータに接続した管理用端末［１０３ａ］［１０３ｂ］は、すべての業務を行えるようにするのがよい。以上、問い合わせ元である端末処理装置と問い合わせ先である保証情報を処理する中間処理装置とが、ひとつの会社機構内におけるクライアント・サーバーシステムである例を説明した。
【００２６】
【実施例２】図２に本発明の第２の実施例の全体構成を示す。この例では、保証情報を処理する中間処理装置は、端末処理装置群とは独立した別組織内において運用される情報処理組織である。  図２において、有価証券を処理する証券会社店頭［２０１］［２０２］の端末処理装置は、直接または本社の独立したサーバー・コンピュータ［２０４］を経由して、さらに独立した中間処理装置［２２０］である情報処理組織に問い合わせを行う。中間処理装置［２２０］は、端末処理装置［２０１］等と情報提供機関ＤＢ［２０８］との双方に回線接続されている。中間処理装置［２２０］は、情報提供機関ＤＢ［２０８］に繰り返し送信要求するか、または情報提供機関ＤＢ［２０８］の受信要求を受けて、情報提供機関ＤＢ［２０８］から保証情報を繰り返し取得して蓄積する。そして、店頭側（本店のコンピュータ［２０４］を経由してもよい。）からの検索要求に応じて、蓄積した保証情報を店頭側［２０１］等に提供し、併せて、店頭側から検索要求があった事実および店頭において事故があった場合にはその事実をも蓄積し、それらを情報提供機関ＤＢ［２０８］に送信する手段［２０４ａ］を備えている。
【００２７】
【実施例３】図３に本発明の第３の実施例の全体構成を示す。ひとつの中間処理装置［３２０］である情報処理組織は、複数の情報提供機関ＤＢ［３０８ａ］［３０８ｂ］等と繰り返し送受信することができる。情報提供機関ＤＢが複数であるのは、前記したように、地域ごと、業種ごと、あるいは通信回線契約形態ごとに情報提供機関ＤＢがわかれ、それぞれでデータを分配したり、あるいは共有することがあるからである。
【００２８】
【実施例４】図４に本発明の第４の実施例の全体構成を示す。中間処理装置［４２０ａ］・・・・［４２０ｄ］等である情報処理組織および／又は情報提供機関［４０７ａ］［４０７ｂ］等のデータベース（ＤＢ）［４０８ａ］［４０８ｂ］等が複数設けられる。この場合も、地域ごと、業種ごと、あるいは通信回線契約形態ごとに中間処理装置や情報提供機関ＤＢがわかれ、それぞれでデータを分配、共有するとともに、中間処理装置［４２０ａ］・・・・［４２０ｄ］である情報処理組織との間で先の実施例と同様、繰り返し送受信する機能を達成する。
【００２９】
【実施例５】図５に本発明の第５の実施例の全体構成を示す。ひとつの中間処理装置［５２０］である情報処理組織は、複数の証券会社［５３０ａ］・・・・［５３０ｄ］等に対して情報を提供することができ、また情報提供機関［５０７］のデータベース（ＤＢ）［５０８］とも接続されて、先の実施例と同様、繰り返し送受信する機能を達成する。この場合、中間処理装置［５２０］である情報処理組織は、複数の証券会社各証券会社間で、有価証券の真正さに関連する保障情報を互いに交換し、あるいは各証券会社に対して共通的に保証情報を提供する独立した営業を行う組織とすることもできる。
【００３０】
次に、本発明によって盗難株券が処理される場合の事故が防げるプロセスを、例として図１の実施例について、まとめる。
《事故が防げるプロセス》
［当日］
株券が盗難にあった当日は、被投資家は未だ気がついていない。その状態で、盗難事故の株券が支店店頭［１０１］等に持ち込まれ、店頭では問い合わせするため、株券を本店に送付する。一方、盗難に遭った投資家［１１２］が事故に気づいて警察［１１３］および取引の証券会社［１１１］に連絡して、信託銀行［１１０］、日本証券業協会［１０９］に盗難事故の情報が流され、かりに本店のサーバー・コンピュータ［１０４］の事故株ＤＢ［１０６］に盗難の情報が蓄積されていれば、即日事故防止ができることもある。もっとも、一般的には、即日の対処は難しい。
［翌日］
店頭では、株券が持ち込まれた当日事故が検索されないときにも、安全のため再度株券情報を自社事故株マスター［１０６］（または別の中間処理装置）に問い合わせる。日本証券業協会では情報提供機関ＤＢに盗難情報を登録依頼する。この内容は、（図１の例では）中間処理装置である証券会社本店サーバー［１０４］に、リアルタイムに蓄積され、証券会社は、リアルタイムに事故の情報を知らされる。同時に、情報提供機関ＤＢ［１０８］では、書面通達によっても事故情報を流す。盗難事故は、自社事故株券マスター［１０６］に盗難情報として登録されるので、店頭［１０１］では、問い合わせの結果、事故株券だと判る。
［翌翌日］
おそくとも早朝、サーバーコンピュータ［１０４］は店頭［１０１］からの問い合わせに回答する。店頭に、事故株券であることが知らされる。日本証券業協会の事故株ＤＢには、盗難があった情報がすでに登録されている。
［４日目］
売買金額の受け渡し日である４日目には、すでに事故株と判明しているので売買は不成立となる。サーバー・コンピュータ［１０４］は、問い合わせに対して事故株と報告する。同時に事故株が持ち込まれたことを警察に通報するから、事故の波及はない。
【００３１】
証券会社［５３０ａ］・・・・［５３０ｄ］が複数の場合（図５）、互いに事故株券等に関する情報を交換し、情報を共有するので、店頭［１０１］［１０２］等に対して、情報が一層リアルタイムに提供される。
【００３２】
なお、特許請求の範囲および明細書各実施例において「中間処理装置」の名称で説明したものは、店頭の端末処理装置および外部の情報提供機関の双方と回線接続されて保証情報を蓄積し処理する情報処理組織であって、設置場所は、前記したように、証券会社サーバー・コンピュータの内部、証券会社とは別の情報提供機関ＤＢ、又はそれらと接続された通信回線上の位置であればよい。
【００３３】
【発明の効果】以上述べたように、本発明は、端末処理装置と情報提供機関との間に中間処理装置として情報処理組織を介在させ、中間処理装置は前記情報提供機関に定期又は不定期に繰り返しアクセスして、ランダムな時点で起こる事故や盗難などの保証情報をリアルタイムに蓄積、更新し、端末処理装置からの問い合わせに応じて該当する有価証券に関して最新に蓄積した保証情報を回答するとともに、該当する有価証券について問い合わせがあった事実を計数して蓄積し、問い合わせした端末処理装置へは該当する有価証券について他の端末処理装置から問い合わせがあった件数等の情報をも併せて回答するようにしたので、有価証券の真正さをリアルタイムに正確に認識して処理し、事故の波及を防ぐことができる効果を生じる。
【図面の簡単な説明】
【図１】図１は、本店サーバー・コンピュータによって事故株を検索する場合の本発明の全体構成を示す。
【図２】図２は、独立したサーバーコンピュータに事故株情報を蓄積する場合の、本発明の構成を示す。
【図３】図３は、情報提供機関ＤＢが複数である場合の、本発明の構成を示す。
【図４】図４は、情報処理組織（中間処理装置）および情報提供機関ＤＢが複数である場合の、本発明の構成を示す。
【図５】図５は、証券会社が複数の場合の本発明の構成を示す。
【図６】図６は従来の装置構成を示す。
【図７】図７はローカルチェックの処理構成を示す。
【符号の説明】
１０１、２０１、３０１．．．店頭端末処理装置
１０２，２０２，３０２．．．店頭端末処理装置
１０４．．．本店サーバー・コンピュータ（兼情報処理組織）
２０４，３０４，４０４．．．本店サーバー・コンピュータ
１０４ａ、２０４ａ，３０４ａ，４０４ａ．．．送信データ蓄積部
１０５、２０５，３０５，４０５．．．銘柄マスター
１０６、２０６，３０６，４０６．．．事故株券情報記憶装置（事故株マスター）
１０７、２０７、３０７ａ、３０７ｂ、４０７ａ、４０７ｂ、５０７、６０７．．．情報提供機関
２２０、３２０、４２０ａ、４２０ｂ、４２０ｃ、４２０ｄ、５２０．．．情報処理組織（中間処理装置）