(57)【特許請求の範囲】
【請求項１】
少なくとも店頭持ち込みから売買受渡しまでを含む期間、券面を識別する記番号の桁数が不揃いである株券を受け取りおよび受け渡し、最終的に株券の真正さを確認する、株券の処理方法において、
店頭に１又は複数の端末を設置し、
前記端末と公的な情報提供機関とを通信可能にする手段を配置し、
前記端末と公的な情報提供機関との両者に通信可能に接続される中間情報処理手段を設け、
前記端末においては、
持ち込まれた株券の記番号をOCR又は類似のセンサーで読みとるステップと、
読み取った株券の記番号を電子化するステップと、
電子化した記番号のデータを前記中間情報処理手段に対して問い合わせるステップと、
を実行し、
前記中間情報処理手段においては、
前記端末から受信した電子化した記番号のデータを株券の文字データの照会に必要な桁数に変換し、その中の一部の文字列を抜き出し数値に変換するステップと、
事故株情報データベースには自社における銘柄および顧客コードが含まれ、公的な情報提供機関に対し繰り返し送信要求をすることによって事故株の情報の提供を受け、提供を受けた事故株の情報を前記事故株情報データベースに追加的にかつ継続的に蓄積するステップと、
前記端末からの問い合わせに対して、前記一部の文字列を抜き出し数値に変換した記番号を用いて前記事故株情報データベースを検索するステップと、
前記検索の結果、問い合わせに係る、前記一部の文字列を抜き出し数値に変換した記番号と同じ部分的記番号を持つ株券に係る問い合わせが重複して存在することおよび同じ部分的記番号に係る問い合わせが過去に存在した回数を、問い合わせた端末に回答するステップと、
さらに、上記一部の文字列を抜き出し数値に変換した記番号と同じ記番号を持つ株券に関する重複する問い合わせがあった事実および重複する問い合わせが過去に存在した回数を、それらが事故の情報であるとないとを問わず前記事故株情報データベースに蓄積するステップと、
を実行し、
前記端末において、さらに、中間情報処理手段から得た回答を表示することで、持ち込まれた株券を事故株であるか否かの判断を支援するステップを実行することを特徴とする、
株券の真正さを同一記番号の重複の可能性に基づいて確認する処理方法
【請求項２】
問い合わせをした端末の問い合わせに関するデータは、他の端末からは、訂正取消しをできないようにするステップと
問い合わせをした端末の問い合わせに関するデータを、他の端末において訂正取消しをできるように、他の端末に特別な権限を与えるステップと
を実行する
前記請求項１の株券の真正さを同一記番号の重複の可能性に基づいて確認する処理方法
【請求項３】
前記端末と前記中間情報処理手段とは、クライアント・サーバーシステムである請求項１又は請求項２に記載の、株券の真正さを同一記番号の重複の可能性に基づいて確認する処理方法
【発明の詳細な説明】
【０００１】
【技術分野】
本発明は、株券、すなわち売買受渡日が４日程度に比較的短期の有価証券を券面の記番号（券面を識別する記号又は番号）によって真正を確認しながら処理する方法に関する。特に、株式取引において、多量の株券をすばやく処理し、決済業務、保管業務を補佐するものであって、株券が、紛失、盗難、再発行など、本来売買できないものでないか、券面を識別する記号又は番号（記番号という。）に関する問い合わせの重複によって株券の真正さを確認しながら処理するための情報を提供する方法に関する。なお、株券および売買受渡日が４日程度に比較的短期の有価証券を、特許請求の範囲および以下本明細書において「株券」という。
【０００２】
【背景技術】
証券会社において、外部から売却を前提に、店頭に持ち込まれた株券を処理するにあたり、帳簿の記入が必須である。信託銀行は、株式を発行する会社から依頼され、株券を管理するが、証券会社ごとに株券識別番号（記番号）を自由に設定しているため、券面番号は普通６桁もしくは７桁の番号が混在している。さらに株券は、発行会社ごとに異なる様式で発行されているため、管理方法が画一的には行えない。また、汚泥等により株券の銘柄、記番号などの全部または一部がはっきりしないことも多い。また、銘柄、券種、ひらがな、カタカナ、英数文字、変体仮名などの記号が用いられることもある。そのように、株券の券面番号の桁数が不統一のままで受け取り、受け渡しの業務を行うので、事務処理が膨大となり、以後の検索も煩雑な作業が伴った。また、事故株との照合においても、株券に記載されている識別番号をすべて入力し、問い合わせを行うと、作業量が非常に多くなるが、正確な照会を行うための基盤作りがなされていない状況において、証券各社は、手作業による独自の方法で管理を行っていた。
【０００３】
【発明が解決しようとする課題】
株券の受け取り、受け渡し時には日時、相手先、銘柄、券種、記号に加え、桁数不揃いの券面番号を記帳し管理しなくてはならないが、現物の株券を確認するのは主に手作業によるのが実情であり、これが非常に手数を要していた。作業にコンピュータやＯＣＲを導入することは既に行われているが、株券を視認して識別コードを入力する作業自体は、手作業によらざるを得ない。また、記帳されたデータが不揃いで統一性が無い場合は、以後の検索作業および事故株の照合に著しい不都合が生じる。
【０００４】
警察や日本証券業協会のような公的機関から事故株の情報が通知されていれば、当然に注意が払われる。しかし、事故の状況によっては、すべての情報が明確になっているとは限らない。例えば、盗難株券の銘柄、記番号の一部がはっきりしないことも多い。
【０００５】
【課題を解決する手段】
本発明は、上記した課題を解決するために、株券を処理するひとつまたは複数の端末処理装置に光学式読取装置（ＯＣＲ）またはセンサーを付属させ、事故株の保証情報ＤＢと照会する。本発明は、同じ記番号の株券はただひとつしかないことに着目し、さらに株券番号の一部の桁の数字を管理することで、事故株の保証情報を集中して管理する情報提供機関ＤＢとの間に設けた中間処理装置によって問い合わせを行うと同時に、中間処理装置は最新に蓄積した保証情報を回答するとともに、該当する株券について問い合わせ（検索依頼）があった事実を計数して蓄積し、問い合わせした端末処理装置へは該当する株券について他の端末処理装置から問い合わせがあった件数等の情報をも併せて回答することによって、株券の真正さをより正確に認識して迅速に処理するものである。また、汚泥等により株券の銘柄、記番号の一部がはっきりしない場合は、一部一致検索で該当株券を表示させ、注意を喚起することで、事故を最小限に押さえることを特徴としている。
【０００６】
【発明の実施の態様】
[請求項１]の発明は、
少なくとも店頭持ち込みから売買受渡しまでを含む期間、券面を識別する記番号の桁数が不揃いである株券を受け取りおよび受け渡し、最終的に株券の真正さを確認する、株券の処理方法において、
店頭に１又は複数の端末を設置し、
前記端末と公的な情報提供機関とを通信可能にする手段を配置し、
前記端末と公的な情報提供機関との両者に通信可能に接続される中間情報処理手段を設け、
前記端末においては、
持ち込まれた株券の記番号をOCR又は類似のセンサーで読みとるステップと、
読み取った株券の記番号を電子化するステップ（[０００９]〜[００１０]）と、
電子化した記番号のデータを前記中間情報処理手段に対して問い合わせるステップ（[００１０]）と、
を実行し、
前記中間情報処理手段においては、
前記端末から受信した電子化した記番号のデータを株券の文字データの照会に必要な桁数に変換し、その中の一部の文字列を抜き出し数値に変換するステップ（[００１０]〜[００１３]）と、
事故株情報データベースには自社における銘柄および顧客コードが含まれ（[００１６]）、公的な情報提供機関に対し繰り返し送信要求をすることによって事故株の情報の提供を受け、提供を受けた事故株の情報を前記事故株情報データベースに追加的にかつ継続的に蓄積するステップ（[００１６]〜[００１７]等）と、
前記端末からの問い合わせに対して、前記一部の文字列を抜き出し数値に変換した記番号を用いて前記事故株情報データベースを検索するステップ（[００１０],[００１３]等）と、
前記検索の結果、問い合わせに係る、前記一部の文字列を抜き出し数値に変換した記番号と同じ部分的記番号を持つ株券に係る問い合わせが重複して存在することおよび同じ部分的記番号に係る問い合わせが過去に存在した回数を、問い合わせた端末に回答するステップと、
さらに、上記一部の文字列を抜き出し数値に変換した記番号と同じ記番号を持つ株券に関する重複する問い合わせがあった事実および重複する問い合わせが過去に存在した回数を、それらが事故の情報であるとないとを問わず前記事故株情報データベースに蓄積するステップ（[００２０]）と、
を実行し、
前記端末において、さらに、中間情報処理手段から得た回答を表示することで、持ち込まれた株券を事故株であるか否かの判断を支援するステップ（[００１４]）を実行することを特徴とする、
株券の真正さを同一記番号の重複の可能性に基づいて確認する処理方法
として実施する。
【０００７】
[請求項２]の発明は、
問い合わせをした端末の問い合わせに関するデータは、他の端末からは、訂正取消しをできないようにするステップと
問い合わせをした端末の問い合わせに関するデータを、他の端末において訂正取消しをできるように、他の端末に特別な権限を与えるステップと
を実行する
前記請求項１の株券の真正さを同一記番号の重複の可能性に基づいて確認する処理方法
として実施する。
【０００８】
[請求項３]の発明は、
前記端末と前記中間情報処理手段とは、クライアント・サーバーシステムである請求項１又は請求項２に記載の、株券の真正さを同一記番号の重複の可能性に基づいて確認する処理方法
として実施する。
【０００９】
【発明の実施例】
図１に本発明の全体構成を示す。また、図３に、より具体的なシステム構成を示す。図のシステムにおいて、ある時点で売却を依頼された株券が支店または本店の店頭に持ち込まれたとする。店頭では端末処理装置［１０１，１０２］より株券識別番号（記番号）等のデータは、キー入力または光学読み取り装置（ＯＣＲ）もしくはセンサーによって入力し、電子データに変換する。株券に印刷されている識別番号の内容を、図２に例示する。さらに、図４に、検索を含むローカルチェック処理構成を示す（詳細は後述）。
【００１０】
店頭では、端末処理装置［１０１，１０２］より、株券識別番号（記番号）等の株券のデータは、キー入力または光学読み取り装置（ＯＣＲ）もしくはセンサーによって入力され、電子データに変換される。株券の記番号の電子データはネットワークで接続された中間処理装置（図１の例では、サーバーコンピュータ［１０４］）に送られ、ＯＣＲ蓄積ＤＢ［１０４ａ］に一旦収納された後、サーバーコンピュータ［１０４］により、照会に必要な桁数（この場合１８桁）の文字から、数字に変換し、事故株情報ＤＢ［１０６］と照らし合わし、該当株券を端末処理装置［１０１，１０２］に返答する。実際の作業はＯＣＲ蓄積ＤＢ［１０４ａ］に登録された株券の文字データをサーバーコンピュータ［１０４］により桁数を揃え、整形した株券番号を一件ずつあいまい検索を行いながら、事故株情報ＤＢ［１０６］のデータから変換した番号を検索する。同じ記番号をもった株券はただ一つしかないはずであるから、同じ又は別の店頭に、同じ頃、売買のために持ち込まれた株券の記番号が一致（重複）することは、通常であればあり得ないことである。同じ記番号の株券の問い合わせが重複した場合、それは事故株券と疑わしい。そこで、真正さを確認する処理を行うため、問い合わせるわけである。
【００１１】
図１に例示したＡからＥまでの信託銀行［１１０］５行は、株式を発行する会社から依頼され、株券を管理するが、券面番号を自由に設定しているため、普通６桁もしくは７桁の番号のものが存在している。具体的に、図２に、株券に印刷されている識別番号の内容を例示する。左から数えて１１桁目から６桁が株券の券面データとして取得され、最終の２桁はチェックサムデータに使用される。
【００１２】
図２の株券識別番号の構成例において、会社名は黒い三角で、券種は●●●で、記号は■■■で、番号は×××××××（図２の例では７桁）で、チェックサムデータＣＤは○○で、それぞれ代表させてある。例として、１８桁文字列：
０５００００２０１００６８９９５１
を表示してある。この券面から株券を識別するに際し、記号または番号の一部の桁を除いたものを処理することで、入力作業の労力を少なくでき、しかも、検索の一致率を下げないですむことが判明した。以下、さらに説明する。
【００１３】
図１に示す構成で照合を次のように行う。ＯＣＲ蓄積ＤＢ［１０４ａ］には、文字として読み取られたデータ列が、例えば
１１１２２２３３３１２３４５６７９９
１１１２２２３３３０１２３４５６９９
１１１２２２３３３００００００１１１
０００１１１
のように累積される。これら文字データを照会に必要な桁数（図１では１８桁）に変換し、その１１桁目より６桁（会社名（黒い三角）、券種●●●および記号■■■の次の番号７桁×××××××の上位１桁を除いた下位６桁××××××）の各文字列を取得した後、それぞれを数値に変換して、
２３４５６７
１２３４５６
１１１
１１１
を得る。これら数値を一件づつＳＱＬ文（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ  構造化問い合わせ用語文）にＬＩＫＥ演算子を付したかたちで、事故株ＤＢのデータ変換後番号と“あいまい検索”を行う。その結果、事故株情報ＤＢのデータより検索回答として、
ＡＢ−１２３４５６７
ＢＢ−０１２３４５６
ＣＢ−１０００１１１
ＤＣ−０００１１１
を得る。これらは、最初の一桁が０から９までのいずれかであって、以下の桁の数値が検索した該当株券の記番号と一致する事故株データベースからの検索回答である。検索された回答は、６桁の数値であり、検索をした株券番号と下６桁で部分一致であるが、もしも記号■■■と番号×××××××とが全て一致していれば、事故株券として処理されなければならない。
【００１４】
図２の実施例においては、識別番号の最初の１桁を除いた数値を入力し、かつ事故株マスターを検索することで、最初の一桁が０から９までのいずれかであって、他の数値が該当株券と一致する事故株データが表示されるから、これを事故株と疑わしいデータとして注意を喚起しながら、手作業又は視認により照会を行うことで、確実な事故株照会を行うことが出来る。もしも、券面の全てのデータを入力する場合を考えると、株券の記号には変体仮名文字も使用されており、それらを手入力する作業は著しく困難を要することや、変体仮名とコードの変換が各信託銀行ごとに異なり、しかも非公開を原則としていることから、著しい労力となる。本発明の実施例のように、記号の一文字分と一桁分の事故株情報とを除いて検索したのち、検索されたデータを事後的に処理すれば、少ない労力で済むことが特徴的な利点である。
【００１５】
かりに１００万株の決済を行う場合、一般的に株券は一千枚にもおよぶ。それらを手入力で管理するには、多量の労力を必要とする。経験によれば、記号と券番号の頭一桁を抜いた番号での検索によれば、入力などの労力が少なくなる一方、事故株一致率はさほど低下はない。あいまい検索により注意を喚起された株券を、再度目視検査を行う方が、全桁数を入力するのと比較して労力が圧倒的に少ないことが、経験により証明された。
【００１６】
図４に、検索を含むローカルチェック処理構成を示す。各部分の記号は図１と同じである。本店のサーバーコンピュータ［１０４］は、事故株券マスタ［１０６］を有する。そのような事故株券マスタ［１０６］は、当初には、銘柄マスター［１０５］から銘柄および顧客コードのデータを自動複写機能によって取得し、入力される。管理端末［１０３］から入力されることもある。そのうえで、店頭の端末処理装置［１０１］［１０２］に持ち込まれた株券の記番号が、キー入力又はＯＣＲによって読み取られる。同じ記番号の重複（ダブリ）があれば、チェックされ、メッセージ（ＭＳＧ）が出る。重複チェックを受けたデータは、送信データ蓄積部［１０４ａ］にインサート処理され、日々累積する。累積したデータについて、事故株券データ（事故株券マスタ）［１０６］ー［１０６］を、図１の手順で一件ずつ検索する。本店サーバー・コンピュータ［１０４］は、送信データ蓄積部［１０４ａ］を介して社外の情報提供機関ＤＢ［１０８］（図１）と繰り返し接続され、株券に関する保証情報の取得を行う。事故株マスター［１０６］には、予め、本店のサーバー・コンピュータ［１０４］により、社外の情報提供機関ＤＢ［１０８］が保有する保証情報をリアルタイムに取得、蓄積されている。これを証券会社店頭［１０１］等に迅速に回答することができる。
【００１７】
図３に、店頭に持ち込まれた株券が事故株券かどうか、保証情報を外部の情報提供機関［１０７］［１０８］に問い合わせて取得したデータと照合し、該当株券を回答する装置と方法を示す。本発明のさらに別の特徴である中間処理装置（保証情報データベース）は、本店のサーバー・コンピュータ［１０４］がそれに該当する。支店（クライアント）店頭［１０１，１０２］では一般的な卓上型コンピュータを端末処理装置として多数台備え、それらは本店のコンピュータに接続されている。本店のコンピュータ［１０４］は、事故株情報を内部に収納できる汎用サーバー型コンピュータであり、これには支店店頭の端末処理装置と同じ卓上型コンピュータが接続されるとともに、管理用の端末処理装置［１０３ａ、１０３ｂ］も接続されている。本店のサーバー・コンピュータには、たとえば外部記録媒体を接続して銘柄マスター［１０５］、事故株マスター［１０６］とし、情報提供機関ＤＢ［１０８］と送受信するデータを蓄積して事故株券情報を収納し、管理する。自社事故株マスター［１０６］は、当初の基礎的構造としては、本店のコンピュータの銘柄マスター［１０５］から、支店（クライアント）または本店（サーバー）の端末を介して、銘柄および顧客コードを自動複写機能により取得すれば、迅速かつ正確にデータの入力を行え、これによって、構築できる。構築した基礎的構造に、外部にある情報提供機関ＤＢ［１０８］から事故株データを、また端末処理装置から問い合わせデータを、いずれも合成蓄積したものが事故株マスター［１０６］となる。
【００１８】
図３のシステムにおいて、ある時点で売却を依頼された株券が支店または本店の店頭に持ち込まれたとする。店頭では端末処理装置より株券識別番号（記番号）等のデータは、キー入力または光学読み取り装置（ＯＣＲ）もしくはセンサーによって入力し、電子データに変換する。
【００１９】
電子データ化した株券の記番号等のデータは、本店のサーバー・コンピュータ［１０４］に転送し、本店事故株券データ［１０６］（または銘柄マスター［１０５］）と照合する。本店のサーバー・コンピュータは、送信データ蓄積部を介して社外の情報提供機関ＤＢ［１０８］と繰り返し接続し、保証情報の取得を行う。そのために、事故株マスターには、予め、本店サーバー・コンピュータにより、社外の情報提供機関ＤＢが保有する株券データが取得、蓄積され、これを保証情報として、証券会社店頭に迅速に与えることができわけである。このシステムによって、支店（クライアント）店頭の端末処理装置から本店のサーバー・コンピュータに対する問い合わせは、株券データの検索のかたちで行う。検索の結果、事故株マスタ［１０６］を接続した本店サーバー・コンピュータにより、社外の情報提供機関ＤＢ［１０８］から送受信データ蓄積部を介して取得された株券データと、店頭［１０１，１０２］に持ち込まれた株券データとが照合される。このとき情報提供機関ＤＢ［１０８］から取得して自社事故株マスターに蓄積したデータは、必ずしも完璧なものではない。たとえば、盗難に遭った株券の記番号が、一部の桁しか判明していないこともある。そこで、検索は全部一致または部分一致検索を試みるのがよい。情報提供機関ＤＢ［１０８］には、日本証券業協会［１０９］および信託銀行［１１０］を通じて事故株の情報が通知されているが、たまたま証券会社の本社サーバー・コンピュータから送信要求があった時点で、事故株である情報を情報提供機関ＤＢ［１０８］が有していず、検索の直後に情報を得ることがある。そのような場合に対処して、検索は、必要に応じて、定期的または不定期に、任意の回数、繰り返して行うことができるようにする。また、必要と認められた場合、後日の事故株券情報の検索において、自動または任意に照合が実行できることが望まれる。自動的に繰り返し事故株券情報と参照することによって、ランダムに起こる事故の情報をよりリアルタイムに取得し、被害を一層未然に防ぐことができる。
【００２０】
株券盗難の事実は、他から知らされる場合ばかりでなく、自社内で判明する場合もある。そのときは、事故の情報は、以上と同じ通信路を経由して、逆方向に、店頭端末処理装置［１０１，１０２］から本店サーバー・コンピュータ［１０４］へ、また、本店サーバー・コンピュータから情報提供機関DBへ送信される。問い合わせがあった株券は、事故株であると判明しないものであっても、現に市場を動いているわけであり、また問い合わせの対象となるような確かめるべきなんらかの事情を伴う場合も多い。したがって、該当株券について問い合わせがあった事実やその回数を蓄積することによって、その株券に関する事故が仮にたまたま発生しても、トラブルの回避に役に立つことが考えられる。したがって、問い合わせがあった事実は、自社事故株マスター［１０６］に蓄積し、また必要であれば、情報提供機関ＤＢ［１０８］に提供する。
【００２１】
信用性を高めるため、任意の時間が経過した場合に、送受信データ蓄積部は保証情報を更新するべきである。１度目のチェック以降に情報提供機関ＤＢ［１０８］が事故情報を更新することがあるが、その場合も、複数回チェックを繰り返すことによって、更新後の情報が取得でき、より被害に遭いにくくなる。繰り返し検索照合を実行するため、支店（クライアント）の端末処理装置にも、また本店のサーバー・コンピュータの送受信データ蓄積部にも、自動ダイアリング、リトライ機能を装備させる。
【００２２】
事故株券情報はネットワーク上の複数サーバーによる共有も可能である。以上の手順により、自社内において照会結果が瞬時に分かるため、業務が短時間で完結する。また、自社の事故株マスターに蓄積されたデータにより照会を行うため、既存のサービス提供会社に支払う料金が節約できる。また、ファジー入力機能により不鮮明な株券データにおいても検索が行える。以上の構成により、とくに大量の株券が持ち込まれた場合に、事務処理をすばやく行うことができる。
【００２３】
本店（サーバー）に問い合わせた株券データを支店（クライアント）から取り消し、または訂正する必要が生じる場合がある。その場合、他の端末処理装置や他の支店からは問い合わせデータを取り消すことができないようにする必要がある。このような必要は、売却および担保価値の確認のために検索を依頼した株券データを、なんらかの都合で売却を断念または売却株券を入れ替えた場合に生ずる。このときは、検索を依頼した端末処理装置のみに訂正取消の権限を与え、それ以外の店頭端末からは誤ってデータを消去することが無いように、端末処理装置番号、取扱者名あるいはなんらかのＩＤやパスワード定義する。これにより、万全のデータ保護機能を装備させる。
【００２４】
将来、同種の事故株券ＤＢが複数設置された場合、内部データの共有を規定することができる。株券の売買における決済日までの期間中に他の支店クライアント（端末）より同番号の問い合わせ（通常あり得ないことである。）があった場合、注意事項として重複チェック機能を持たせると便利である。入力データの重複チェック機能および、ネットワーク化された各サーバーにおいても入力データの重複チェックをすることができる。すべての検索結果において事故株券で無いと判断されたものは、証券取引において安全であると判断できる。なお、本店のサーバー・コンピュータに接続した管理用端末は、すべての業務を行えるようにするのがよい。以上、問い合わせ元である端末処理装置と問い合わせ先である中間処理装置とが、ひとつの会社機構内におけるクライアント・サーバーシステムである例を主として説明した。一方、中間処理装置は、端末処理装置群とは独立した別組織内において運用される情報処理組織であってもよい。
【００２５】
次に、本発明によって盗難株券が処理される場合の事故が防げるプロセスをまとめる。株券の店頭持込みから売買受渡日までの４日間は、事故株の発見につながる同一記番号に関する問い合わせの重複が予測される。事故株と疑わしいものの発見は、該当株券が店頭に持込まれた日から売買受渡の日までの短期間（通常４日）、とくに毎日繰り返して問い合わせがなされる。
《事故が防げるプロセス（本発明）》
［当日］
株券が盗難にあった当日は、被害を受けた投資家［１１２］は未だ気がついていない。その状態で、盗難事故の株券が支店店頭［１０１，１０２］に持ち込まれ、店頭では問い合わせするため、株券を本店に送付する。一方、盗難に遭った投資家が事故に気づいて警察［１１３］および取引の証券会社に連絡して、信託銀行［１１０］、日本証券業協会［１０９］に盗難事故の情報が流され、かりに本店のサーバー・コンピュータ［１０４］の事故株ＤＢ［１０６］に盗難の情報が蓄積されていれば、即日事故防止ができることもある。もっとも、一般的には、即日の対処は難しい。
［翌日］
店頭では、株券が持ち込まれた当日事故が検索されないときにも、安全のため再度株券情報の記番号の一部を、自社事故株マスター（または中間処理装置）に問い合わせる。日本証券業協会では情報提供機関ＤＢ［１０７，１０８］に盗難情報を登録依頼する。この内容は、中間処理装置である証券会社本店サーバー［１０４］に、リアルタイムに蓄積され、証券会社は、リアルタイムに事故の情報を知らされる。同時に、情報提供機関［１０７，１０８］ＤＢでは、書面通達でも事故情報を流す。盗難事故は、自社事故株券マスター［１０６］に盗難情報として登録されるので、店頭では、問い合わせの結果、事故株券だと判る。
［翌翌日］
おそくとも早朝、サーバーコンピュータ［１０４］は店頭［１０１，１０２］からの問い合わせに回答する。店頭に、事故株券であることが知らされる。日本証券業協会の事故株ＤＢには、盗難があった情報がすでに登録されている。
［４日目］
売買金額の受け渡し日、事故株と判明しているので売買は不成立となる。サーバーコンピュータ［１０４］は、問い合わせに対して事故株と報告する。同時に事故株が持ち込まれたことを警察［１１３］に通報するから、事故の波及はない。
【００２６】
【発明の効果】
以上述べたように、本発明は複雑な株券識別番号の読み取りを機械化し、かつ検索の一致率を低下させることなく入力などの処理の労力を軽減し、事務処理の効率化を図ると同時に、株券の真正さをリアルタイムに正確に認識して処理し、事故の波及を防ぐことができるものである。
【００２７】
本発明は、同じ記番号の株券は存在しないことに着目して、同じ記番号の株券に関する重複する問い合わせがあった事実および回数を蓄積し、検索し、事故の迅速な発見につなげることを容易にした。又、事故の発見のために、端末処理装置と情報提供機関との間に中間処理装置である情報処理組織を介在させ、中間処理装置は前記情報提供機関に定期又は不定期に繰り返しアクセスして、保証情報をリアルタイムに蓄積、更新し、端末処理装置からの問い合わせに応じて該当する株券に関して最新に蓄積した保証情報を回答するとともに、該当する株券について問い合わせがあった事実を計数して蓄積し、問い合わせした端末処理装置へは該当する株券について他の端末処理装置から問い合わせがあった件数等の情報をも併せて回答することを容易にした。このことは、単にランダムにおこる事故や盗難の発見を容易にしただけでない。とりわけ自社内で生じた事故があった場合に、公的な情報提供機関を介することなくただちに発見できるという効果を生む。公的な情報提供機関がＤＢファイルを更新した直後の事故や、ある検索の直後に生じた事故も、見逃さない効果がある。したがって、本発明によって、株券の真正さをより迅速に正確に認識する機会を逃さないので、事故の波及をより有効に防ぐことができる顕著な効果を生じる。
【図面の簡単な説明】
【図１】図１は、ＯＣＲにより株券データを読み取り、データを整形した後、事故株との検索を行う場合の本発明の構成を示す。
【図２】図２は、株券に印刷されている識別番号の内訳を示す。
【図３】図３は、本店サーバー・コンピュータによって事故株を検索する場合の本発明の構成を示す。
【図４】図４はローカルチェックの処理構成を示す。
【符号の説明】
１０１、１０２．．．店頭端末処理装置
１０４．．．本店サーバー・コンピュータ（兼中間処理装置）
１０４ａ・・・ＯＣＲデータ蓄積データベース（送信データ蓄積部）
１０５．．．事故株情報記憶装置の銘柄マスター
１０６．．．事故株券マスター
１０７．．．保証情報提供機関
１０８・・・保証情報提供機関の事故情報データベース
１１０・・・信託銀行
【図１】
0004433596.tif 000002
【図２】
0004433596.tif 000003
【図３】
0004433596.tif 000004
【図４】
0004433596.tif 000005