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