申請方法および申請装置
【課題】証券業務の状況を考慮して書類の申請処理を実行する技術を提供する。
【解決手段】申請画面生成部１０４は、受付部９６を介して、顧客に対する証券業務の申請の開始指示を受けつける。取得部１０６は、開始指示を受けつけると、顧客情報記憶部１８に記憶された情報を取得する。申請画面生成部１０４は、取得した情報をもとに、顧客に対する証券業務の申請画面を生成し、これを表示部９８に表示させる。申請画面生成部１０４は、申請者から、証券業務の申請指示を受けつける。移動部１０８は、申請指示を受けつけると、申請画面を生成するために使用した情報を申請情報記憶部２０に記憶させる。
【解決手段】申請画面生成部１０４は、受付部９６を介して、顧客に対する証券業務の申請の開始指示を受けつける。取得部１０６は、開始指示を受けつけると、顧客情報記憶部１８に記憶された情報を取得する。申請画面生成部１０４は、取得した情報をもとに、顧客に対する証券業務の申請画面を生成し、これを表示部９８に表示させる。申請画面生成部１０４は、申請者から、証券業務の申請指示を受けつける。移動部１０８は、申請指示を受けつけると、申請画面を生成するために使用した情報を申請情報記憶部２０に記憶させる。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、申請技術に関し、特に、証券業務に関連した申請を実行する申請方法および申請装置に関する。
【背景技術】
【０００２】
会社等の組織において業務上の責任の所在を明確にするために、一般的に、書類の申請および承認がなされている。従来、書類の申請および承認手続きは、紙媒体を使用してサインや押印によって行われていた。近年、コンピュータおよびネットワークの普及によって、コンピュータによる申請書類の作成が可能となり、申請者の端末にて作成された申請書類のデータが、ネットワークを通じて承認者の端末に伝送される。さらに、承認者の端末において承認入力がなされることによって、書類の申請および承認が迅速かつ容易に行われる。
【０００３】
しかしながら、申請者が書類のデータを管理者に一度申請をしてしまうと、申請後に緊急に書類を修正する必要が発生しても、承認者の承認または非承認を受けるまでは、再度編集できない。そのため、効率的でなかった。これに対応するため、書類データに対して、作成中、申請中、承認済み、申請却下のステータスを付与して一元管理し、申請者の端末でステータスを「作成中」から「申請中」へと変更することにより申請がなされる。また、「申請中」から「作成中」へと変更することにより申請取下げがなされる（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−７１１８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
申請および承認をコンピュータネットワークにて実行するシステムは、証券業務でも必要とされる。例えば、信用取引口座開設申請書、短期売却届出書等を申請して承認を受けるために申請書の作成と承認処理が必要となる。このような証券業務における申請および承認をコンピュータネットワークにて実行するシステムで行おうとする場合、証券業務に特有の課題がある。課題のひとつは、申請を承認するか否かを判断するために申請内容応じた種々の情報が必要であり、例えば顧客の住所、氏名、年齢といった属性情報のみならず、顧客の所有している資産情報や顧客の投資方針等が必要になる場合があることである。ここで、申請・承認の際に必要となる情報は任意のタイミングで更新される必要があり、更新の頻度やタイミングは情報によって異なる。例えば顧客の住所のような属性情報は更新は少なく、更新するタイミングも顧客から連絡があった場合や証券会社の社員が顧客に営業を行うなどして連絡を取った場合のように自由に更新できることが好ましい。一方、顧客の資産情報については例えば、株価は日々変動するため更新頻度は多く、株価情報は通常、定期的に更新されるため、資産情報についてはある程度、定期的に更新できることが好ましい。このように申請および承認に際して必要な様々な情報は多岐にわたり、それぞれ異なる頻度やタイミングで更新できる必要があることが別の課題となっている。以下、この課題を具体的に説明する。
【０００６】
申請および承認の内容を事後的に監査等することを考慮すると、申請および承認の際に参照される情報は少なくとも申請時点において固定された状態で承認申請、承認判断、承認完了という承認申請手続きを経て保存される必要がある。このため、申請および承認をシステムで行うためには、申請および承認に必要な情報を任意のタイミングで更新可能とすることと、申請および承認時に参照された情報が固定されることとを両立させる必要がある。
【０００７】
本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、証券業務の状況を考慮して書類の申請処理を実行する技術を提供することである。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明のある態様の申請装置は、申請者から、証券業務に関する承認申請の開始指示を受けつける第１受付部と、第１受付部が開始指示を受けつけると、顧客の資産情報と顧客の属性情報とを本申請装置とは独立して任意のタイミングで更新して記憶する第１記憶部から、顧客の資産情報と顧客の属性情報とを取得する取得部と、取得部において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成する生成部と、生成部において生成した申請画面を表示させる表示部と、表示部が申請画面を表示させた状態において、申請者から、証券業務の承認申請を行う旨の申請指示を受けつける第２受付部と、第２受付部が申請指示を受けつけると、生成部が申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを固定して第２記憶部に記憶させる移動部と、第２受付部において受けつけた申請指示に対して、承認者からの承認指示を受けつける第３受付部とを備える。第２記憶部は、第２受付部において申請指示を受けつけることで顧客の資産情報と顧客の属性情報との書き込みを実行し、移動部は、第３受付部が承認指示を受けつけると、第２記憶部に記憶された顧客の資産情報と顧客の属性情報を更新不可能な状態で、第２記憶部とは別に設けられた第３記憶部に記憶させる。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、証券業務の状況を考慮して書類の申請処理を実行できる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施例に係る証券業務システムの構成を示す図である。
【図２】図１の申請サーバの構成を示す図である。
【図３】図２の顧客情報生成部の構成を示す図である。
【図４】図１の預りＤＢのデータ構造を示す図である。
【図５】図１の資産ＤＢのデータ構造を示す図である。
【図６】図１の共通属性ＤＢのデータ構造を示す図である。
【図７】図７（ａ）−（ｃ）は、図１の個人属性ＤＢのデータ構造を示す図である。
【図８】図８（ａ）−（ｂ）は、図１の法人属性ＤＢのデータ構造を示す図である。
【図９】図２の書類登録部の構成を示す図である。
【図１０】図９の書類生成部によって生成される申請書類登録画面を示す図である。
【図１１】図９の書類生成部によって生成される申請書類承認者定義画面を示す図である。
【図１２】図２の申請登録・照会部の構成を示す図である。
【図１３】図１２の申請画面生成部によって生成される口座指定・書類選択画面を示す図である。
【図１４】図１２の申請画面生成部によって生成される申請内容編集画面を示す図である。
【図１５】図１２の申請画面生成部によって生成される申請内容照会画面を示す図である。
【図１６】図１２の申請画面生成部によって生成される別の申請内容編集画面を示す図である。
【図１７】図１２の申請画面生成部によって生成される別の申請内容照会画面を示す図である。
【図１８】図１８（ａ）−（ｆ）は、図１の申請顧客情報ＤＢのデータ構造を示す図である。
【図１９】図１の申請管理ＤＢのデータ構造を示す図である。
【図２０】図１の申請管理ＤＢの別のデータ構造を示す図である。
【図２１】図１の申請状況管理ＤＢのデータ構造を示す図である。
【図２２】図１の監査証跡管理ＤＢのデータ構造を示す図である。
【図２３】図１２の申請状況照会部によって生成される申請状況一覧画面を示す図である。
【図２４】図２の承認登録部の構成を示す図である。
【図２５】図２４の承認画面生成部によって生成される承認状況一覧画面を示す図である。
【図２６】図２４の承認画面生成部によって生成される承認内容照会画面を示す図である。
【図２７】図２４の承認画面生成部によって生成される承認者記入欄編集画面を示す図である。
【図２８】図２の事務処理登録部の構成を示す図である。
【図２９】図２８の事務処理登録部によって生成される事務処理状況一覧画面を示す図である。
【図３０】図２の申請保管部の構成を示す図である。
【図３１】図３０の申請保管部によって生成される申請保管一覧画面を示す図である。
【図３２】図２の監査証跡管理部の構成を示す図である。
【図３３】図３２の監査証跡管理部によって生成される申請更新履歴照会画面を示す図である。
【図３４】図１の証券業務システムによる申請処理の手順を示すシーケンス図である。
【図３５】図１の証券業務システムによる承認処理の手順を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
本発明を具体的に説明する前に、まず概要を述べる。本発明の実施例に係る証券業務システムは、証券会社の社員である申請者の操作によって、証券業務における書類を作成し、作成した書類を申請する。また、証券業務システムは、証券会社の別の社員である承認者の操作によって、申請された書類を承認したり、非承認したりするとともに、承認前の書類や承認後の書類を管理する。ここで、書類とは、例えば、信用取引口座開設申請書、短期売却届出書であり、これらには、不正な取引を防止するためのコンプライアンスを遵守するといった目的のために、申請および承認が必要とされる。申請および承認のための証券業務システムでは、証券業務特有の事情を考慮して構成されるべきである。
【００１３】
承認する際に、顧客の資産が考慮されることもある。このような資産には、株、社債、投資信託が含まれ、それらも証券業務システムにて管理されている。それらの価値は日々変動しているので、顧客の資産は日々変動している。また、承認に際しては顧客の氏名や住所といった属性情報も必要であるが、これらの情報は任意のタイミングで変動する。つまり、これらの情報は任意のタイミング、頻度で変動するため、これらをシステムで管理するに際しては任意のタイミングで更新可能としておくことが望ましい。一方、承認対象となる書類において資産や顧客属性の情報は固定されていないと、承認者は承認できず、承認後の監査も困難となる。なお、承認に際して必要な顧客の情報は顧客が個人であるか法人であるかによっても異なる。そのため、書類を作成する際に、顧客の種類に応じて承認に必要な情報が申請および承認時に容易に参照できるようになっていることが望まれる。
【００１４】
これらに対応するために、本実施例に係る証券業務システムでは、申請者が書類を作成する際に、申請および承認に際して求められる情報を任意のタイミングで更新可能な状態で記憶されたデータベースから、必要なデータを抽出する。なお、抽出されるデータは、顧客の種類によって異なる。申請者が作成した書類を申請する際に、証券業務システムは、書類の作成時に抽出したデータを固定して別のデータベースに記憶する。当該別のデータベースでは、固定したデータが記憶されている。承認者が書類を承認する際には、固定したデータが記憶されたデータベースが参照される。このように、申請および承認に必要なデータは、更新可能に記憶された記憶部に保持され任意のタイミングで更新され、申請時にはこの記憶部から取得され、申請完了に伴って固定されることで固定したデータが別のデータベースに格納される。
【００１５】
以下では、説明を明瞭にするために、証券業務システムを複数に分けて説明する。まず、１．全体構成を説明した後に、２．顧客情報生成処理、３．書類登録処理、４．申請登録処理、５．承認登録処理、６．事務処理登録処理、７．申請保管処理、８．監査証跡管理処理の各処理を説明する。その後、９．動作を説明する。
【００１６】
１．全体構成
図１は、本発明の実施例に係る証券業務システム２００の構成を示す。証券業務システム２００は、申請サーバ１０、端末装置１２と総称される第１端末装置１２ａ、第２端末装置１２ｂ、資産情報記憶部１４、顧客属性記憶部１６、顧客情報記憶部１８、申請情報記憶部２０、承認情報記憶部２２、ネットワーク２４、顧客情報生成部７０を含む。資産情報記憶部１４は、預りＤＢ３０、資産ＤＢ３２を含み、顧客属性記憶部１６は、共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８を含み、顧客情報記憶部１８は、既存客情報管理ＤＢ４０、顧客カードＤＢ４２を含む。申請情報記憶部２０は、第１ＤＢ４４、第２ＤＢ４６、申請書類管理ＤＢ５６を含み、第１ＤＢ４４は、申請顧客情報ＤＢ４８を含み、第２ＤＢ４６は、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４を含む。承認情報記憶部２２は、申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４を含む。
【００１７】
端末装置１２は、証券会社の社員が証券業務のための書類を作成する際に使用する装置であり、例えば、ＰＣに相当する。端末装置１２は、通信機能を備え、ネットワーク２４に接続される。図１では、２台の端末装置１２が示されているが、これに限定されない。また、第１端末装置１２ａは、書類を申請すべき社員（以下、「申請者」という）によって使用され、第２端末装置１２ｂは、申請された書類を承認すべき社員（以下、「承認者」という）によって使用されるものとする。
【００１８】
申請サーバ１０は、ネットワーク２４を介して、端末装置１２に接続されたサーバである。申請サーバ１０は、端末装置１２からの指示に応じた処理を実行し、その結果を端末装置１２に返信する。
【００１９】
資産情報記憶部１４は、預りＤＢ３０、資産ＤＢ３２を記憶するための記憶媒体である。資産情報記憶部１４は、ネットワーク２４に接続され、申請サーバ１０からアクセスされることで申請サーバ１０によって必要な情報が取り出されてもよい。図１の態様では、後述する顧客情報生成部７０が資産情報記憶部１４と顧客属性記憶部１６とから顧客の資産情報と顧客属性とをそれぞれ取り込んで顧客ごとに申請および承認に必要な情報を生成した情報を記憶する顧客情報記憶部１８を介して資産情報記憶部１４の情報が申請サーバ１０に取り出されるように構成されている。預りＤＢ３０および資産ＤＢ３２に格納されるデータの内容については後述するが、これらのデータの内容は日々変動する。変動の周期は、一般的に１日よりも短く変動タイミングは一般的に予め定められている。このように、資産情報記憶部１４は、所定のタイミグで更新されるデータを更新可能な状態で記憶するための記憶媒体（第１記憶部）である。
【００２０】
顧客属性記憶部１６は、共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８を記憶するための記憶媒体である。本実施形態では上述した通り顧客属性記憶部１６の情報は顧客情報生成部７０により生成され顧客情報記憶部１８に記憶された情報として申請サーバ１０によって取り出されるように構成されているが、顧客属性記憶部１６は、ネットワーク２４に接続され、申請サーバ１０からアクセスされることで申請サーバ１０が直接、顧客属性記憶部１６から必要な情報を取り出すようにしてもよい。共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８に格納されるデータの内容については後述するが、これらのデータの内容は任意のタイミングで変動する。このように、顧客属性記憶部１６は、任意のタイミングで更新されるデータを更新可能な状態で記憶するための記憶媒体（第１記憶部）である。
【００２１】
顧客情報記憶部１８は、資産情報記憶部１４と顧客属性記憶部１６とから顧客の資産情報と顧客属性とをそれぞれ取り込んで顧客ごとに申請および必要な情報として取り出しやすくした状態として既存客情報管理ＤＢ４０、顧客カードＤＢ４２に情報を記憶するための記憶媒体である。顧客情報記憶部１８は、ネットワーク２４に接続され、申請サーバ１０からアクセスされる。既存客情報管理ＤＢ４０および顧客カードＤＢ４２に格納されるデータは、預りＤＢ３０、資産ＤＢ３２、共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８に格納されたデータをもとに生成される。そのため、顧客情報記憶部１８のデータは、適宜、更新され、顧客情報記憶部１８も適宜、更新されるデータを更新可能な状態で記憶するための記憶媒体である。
【００２２】
申請情報記憶部２０は、申請顧客情報ＤＢ４８、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４、申請書類管理ＤＢ５６を記憶するための記憶媒体である。申請情報記憶部２０は、申請サーバ１０からアクセスされる。申請顧客情報ＤＢ４８、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４、申請書類管理ＤＢ５６は、書類を申請してから承認するまでの期間においてデータを格納する。申請顧客情報ＤＢ４８に格納されたデータは、書類を申請してから承認するまでの期間において固定されている。つまり、削除される場合を除いて編集や修正はなされない。
【００２３】
そのため、申請完了時点では顧客情報記憶部１８と申請顧客情報ＤＢ４８に同様の内容のデータが記憶され、その後、顧客情報記憶部１８のデータ内容が変更されても申請情報記憶部２０には申請時点のデータが内容変更できない（すなわち固定された）状態で記憶される。このように申請完了時点に取得された顧客情報を申請顧客情報ＤＢ４８に固定して記憶させることで編集禁止のデータを誤って編集してしまうが防止され、その後の承認手続きにおいて申請時点の顧客情報を参照することができる。一方、申請情報記憶部２０の申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４、申請書類管理ＤＢ５６に格納されたデータは、編集可能である。このように、申請情報記憶部２０は、固定されたデータが記憶される申請顧客情報ＤＢ４８（第１ＤＢ４４）と申請完了から承認完了までの間、更新可能なデータが記憶される申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４（第２ＤＢ４６）とを備える記憶媒体である。
【００２４】
承認情報記憶部２２は、申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４を記憶するための記憶媒体である。承認情報記憶部２２は、ネットワーク２４に接続され、申請サーバ１０からアクセスされる。申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４は、承認された申請についてのデータを格納する。申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４に格納されたデータは、編集されずに固定された状態で記憶されている。このように承認情報記憶部２２は、固定されたデータを格納するための記憶媒体であるともいえる。
【００２５】
承認情報記憶部２２のうち、申請顧客履歴情報ＤＢ５８には申請完了時点で取得され申請顧客情報ＤＢ４８に固定して記憶された顧客情報が固定して記憶されており、承認手続き中と同様に承認完了後も申請完了時点に取得された顧客情報が保持され参照することができる。申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４に記憶されたデータは、それぞれ申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶されたデータの内容が承認完了時に固定されたものである。そのため、承認手続き中は申請情報記憶部２０の申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４により申請内容や承認申請の状況等を確認しつつ、承認手続き後は申請の内容、履歴、承認履歴等が誤って編集してしまうことを防止して申請内容等を確認することができる。
【００２６】
図２は、申請サーバ１０の構成を示す。申請サーバ１０は、書類登録部７２、申請登録・照会部７４、承認登録部７６、事務処理登録部７８、申請保管部８０、監査証跡管理部８２、ＩＦ部８４を含む。ＩＦ部８４は、図示しないネットワーク２４に接続され、通信機能を実行する。ＩＦ部８４は、ネットワーク２４を介して、図示しない端末装置１２、顧客情報記憶部１８、申請情報記憶部２０、承認情報記憶部２２と通信し、顧客情報記憶部１８と顧客情報生成部７０を介して資産情報記憶部１４および顧客属性記憶部１６にアクセスする。
【００２７】
図１の顧客情報生成部７０は、申請者が端末装置１２を操作して書類を作成する前に、書類の作成に必要な顧客データを収集し、顧客ごとの顧客属性情報と顧客資産情報とを作成する。詳細は後述するが、顧客情報生成部７０は、資産情報記憶部１４および顧客属性記憶部１６に記憶されたデータをもとに、顧客の資産情報と顧客の属性情報とを取得し、加工して顧客情報記憶部１８に記憶する。前述のごとく、資産情報記憶部１４および顧客属性記憶部１６に記憶されたデータは変動するので、顧客情報生成部７０は、これらのデータの変動に合わせて、データを更新する。なお、顧客情報生成部７０は、申請サーバ１０の内部に設けられ、ネットワーク２４を介して資産情報記憶部１４と顧客属性記憶部１６とが申請サーバ１０に接続され、申請サーバ１０が資産情報記憶部１４と顧客属性記憶部１６から必要な情報を取得してもよい。
【００２８】
書類登録部７２は、書類フォーマットの作成者が端末装置１２を操作して作成した書類のフォーマットを更新書類管理ＤＢに登録する。具体的には書類登録部７２は、申請情報記憶部２０の申請書類管理ＤＢ５６に申請書類のフォーマット情報を登録する。申請の処理が開始されると、申請登録・照会部７４は、書類登録部７２で作成され申請書類管理ＤＢ５６に登録されている申請書類のフォーマットの中から申請の種類に応じた書類のフォーマットを呼び出すとともに、顧客情報記憶部１８を介して資産情報記憶部１４と顧客属性記憶部１６に記憶されたデータのうち、申請の種類に応じて必要な顧客情報を抽出し、申請画面を生成する。申請者が申請画面から申請を行う旨の指示（申請指示）を入力すると、申請登録・照会部７４はこの指示を受け付けて、顧客情報記憶部１８を介して資産情報記憶部１４と顧客属性記憶部１６から取得し申請画面に表示した顧客情報を申請情報記憶部２０の申請顧客情報ＤＢに固定した状態で記憶させる。また、申請登録・照会部７４は、申請に関する情報を第２ＤＢ４６に記憶させる。
【００２９】
承認登録部７６は、申請登録・照会部７４が申請者からの承認申請指示を受け付けて登録した後、承認者による端末装置１２の操作に応じて、承認者が行う承認処理の結果を受け付けてその内容を登録する。承認結果が受け付けられて登録されると、承認登録部７６は、申請情報記憶部２０の申請顧客情報ＤＢ４８に固定して記憶していたデータを承認情報記憶部２２に更新不可の状態で記憶させる。事務処理登録部７８は、申請登録・照会部７４が申請指示を受け付けて登録した後、申請内容にしたがった事務処理を登録する。事務処理とは、例えば、申請の内容が信用口座の開設であった場合、実際に信用口座を開設するための処理である。このような事務処理は、申請者や承認者とは異なった証券会社の社員によってなされる。事務処理に際しては申請情報記憶部２０の申請顧客情報ＤＢ４８に記憶していたデータが参照される。
【００３０】
申請保管部８０は、承認登録部７６が承認処理の結果を登録した後、端末装置１２からの指示にしたがって、承認した内容を表示させる。その際、申請保管部８０は、承認情報記憶部２２に記憶されたデータを抽出する。監査証跡管理部８２は、承認登録部７６が承認処理の結果を登録した後、端末装置１２からの指示にしたがって、申請から承認までの履歴を表示させる。その際、監査証跡管理部８２は、監査証跡管理ＤＢ５４または監査証跡履歴管理ＤＢ６４に記憶されたデータを抽出する。
【００３１】
以下の各処理に対する説明では、図１に示した申請処理部１００の構成、図２に示した申請サーバ１０の構成のうち、必要な部分だけを図示する。この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００３２】
２．顧客情報生成処理
図３は、顧客情報生成部７０の構成を示す。顧客情報生成部７０は、第１取込部９０、第２取込部９２を含む。また、顧客情報生成部７０は、資産情報記憶部１４、顧客属性記憶部１６、顧客情報記憶部１８に接続される。なお、資産情報記憶部１４、顧客属性記憶部１６、顧客情報記憶部１８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。前述のごとく、顧客情報生成部７０は、申請サーバ１０の内部に設けられてもよいが、その際、申請サーバ１０は資産情報記憶部１４、顧客属性記憶部１６とネットワークを介して接続され、これら記憶部の情報を取り出して顧客情報生成部７０で必要な情報を生成する。
【００３３】
預りＤＢ３０は、顧客の保有している預り情報を記憶する。預りＤＢ３０では、預りごとの記憶がなされている。図４は、預りＤＢ３０のデータ構造を示す。図示のごとく、ユーザ欄３００、部店欄３０２、口座番号欄３０４、商品欄３０６、銘柄欄３０８、数量欄３１０、取得単価欄３１２、時価欄３１４が含まれる。預りＤＢ３０は、各ユーザから預っているっている株式、債券、投信等の銘柄、数量、価格等を記憶する。預りＤＢ３０に格納されたデータは、商品を売買したタイミング、時価が変動したタイミングにおいて更新される。図３に戻る。
【００３４】
資産ＤＢ３２は、顧客の保有している預り資産を記憶する。資産ＤＢ３２では、口座ごとの記憶がなされている。図５は、資産ＤＢ３２のデータ構造を示す。図示のごとく、ユーザ欄３２０、部店欄３２２、口座番号欄３２４、総資産額欄３２６が含まれる。総資産額欄３２６に含まれた総資産額は、預りＤＢ３０に格納されたデータと図示しない株価情報ＤＢとをもとに導出される。そのため、株価情報ＤＢのデータや預りＤＢ３０に格納されたデータが更新されると、資産ＤＢ３２に格納されたデータ、つまり総資産額も更新される。一般に株価情報ＤＢのデータは所定のタイミング（例えば一日一回）で更新されるため、これに伴って資産ＤＢ３２のデータも更新される。また、預りＤＢ３０は株式等の売買が成立した場合などの任意のタイミングで更新され、資産ＤＢ３２は株価情報ＤＢに対する所定の更新タイミングのみならず、任意で発生する預りＤＢの更新に合わせてもデータが更新可能なように構成されている。図３に戻る。
【００３５】
共通属性ＤＢ３４は、個人客、法人客に共通する属性情報を記憶する。共通属性ＤＢ３４では、口座ごとの記憶がなされている。図６は、共通属性ＤＢ３４のデータ構造を示す。図示のごとく、ユーザ欄３３０、部店欄３３２、口座番号欄３３４、顧客名欄３３６、住所欄３３８、電話番号欄３４０、職業欄３４２、リスク説明不要（株式）欄３４４、リスク説明不要（債券）欄３４６、リスク説明不要（転換社債）欄３４８、リスク説明不要（外証）欄３５０、コンプラランク欄３５２、口座開設日欄３５４が含まれる。例えば、住所欄３３８の住所が変更されたタイミングのような任意の不定期なタイミングにおいて、共通属性ＤＢ３４に格納されたデータは更新される。図３に戻る。
【００３６】
個人属性ＤＢ３６は、個人客に関する属性情報を記憶する。個人属性ＤＢ３６でも、口座ごとの記憶がなされている。図７（ａ）−（ｃ）は、個人属性ＤＢ３６のデータ構造を示す。個人属性ＤＢ３６に格納されたデータの項目数が多いので、ここでは図７（ａ）−（ｃ）に分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄３６０、部店欄３６２、口座番号欄３６４、顧客名欄３６６、生年月日欄３６８、性別欄３７０、勤務先欄３７２、役職欄３７４、取引動機欄３７６、資金性格欄３７８、投資方針欄３８０、資産運用期間欄３８２、投資経験有無（株式現物）欄３８４、投資経験有無（債券）欄３８６、投資経験有無（転換社債）欄３８８、投資経験有無（株式信用）欄３９０、投資経験有無（ワラント）欄３９２、投資経験有無（先物・ＯＰ）欄３９４、投資経験有無（貯蓄型投信）欄３９６、投資経験有無（投資信託）欄３９８、投資経験有無（外国証券）欄４００、投資経験有無（その他）欄４０２、主な収入源欄４０４、推定年収欄４０６、金融資産欄４０８が含まれる。個人属性ＤＢ３６に格納されたデータも、共通属性ＤＢ３４に格納されたデータと同様に、任意の不定期なタイミングにおいて更新される。図３に戻る。
【００３７】
法人属性ＤＢ３８は、法人客に関する属性情報を記憶する。法人属性ＤＢ３８でも、口座ごとの記憶がなされている。図８（ａ）−（ｂ）は、法人属性ＤＢ３８のデータ構造を示す。法人属性ＤＢ３８に格納されたデータの項目数が多いので、ここでは図８（ａ）−（ｂ）に分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄４１０、部店欄４１２、口座番号欄４１４、顧客名欄４１６、取引動機欄４１８、資金性格欄４２０、投資方針欄４２２、資産運用期間欄４２４、投資経験有無（株式現物）欄４２６、投資経験有無（債券）欄４２８、投資経験有無（転換社債）欄４３０、投資経験有無（株式信用）欄４３２、投資経験有無（ワラント）欄４３４、投資経験有無（先物・ＯＰ）欄４３６、投資経験有無（貯蓄型投信）欄４３８、投資経験有無（投資信託）欄４４０、投資経験有無（外国証券）欄４４２、投資経験有無（その他）欄４４４、資本金欄４４６、代表者名欄４４８が含まれる。法人属性ＤＢ３８に格納されたデータも、共通属性ＤＢ３４に格納されたデータと同様に、任意の不定期なタイミングにおいて更新される。図３に戻る。
【００３８】
個人の顧客に対するデータと法人の顧客に対するデータとは異なるので、個人属性ＤＢ３６と法人属性ＤＢ３８とが別に設けられる。なお、個人属性ＤＢ３６に格納されたデータと法人属性ＤＢ３８に格納されたデータは、承認申請の際および承認処理（承認／非承認判断）の際に使用される。承認申請および承認処理の判断に際し、個人の顧客と法人の顧客とでは必要な情報が異なるので、個人属性ＤＢ３６と法人属性ＤＢ３８とが別に設けられている。
【００３９】
第１取込部９０は、各顧客に対して、預りＤＢ３０および資産ＤＢ３２に格納されたデータを読み込む。第１取込部９０は、読み込んだデータを既存客情報管理ＤＢ４０に出力する。第２取込部９２は、各顧客に対して、共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８に格納されたデータを読み込む。なお、顧客の属性の種類に応じて、個人属性ＤＢ３６あるいは法人属性ＤＢ３８が選択される。第１取込部９０は、読み込んだデータを既存客情報管理ＤＢ４０および顧客カードＤＢ４２に出力する。
【００４０】
既存客情報管理ＤＢ４０は、各顧客に対して、第１取込部９０および第２取込部９２からのデータを取り込み、顧客属性情報の一部と顧客資産情報とを記憶する。具体的には、顧客の属性情報の種類が個人である場合、口座開設日、住所、職業、生年月日、性別、電話番号、勤務先、役職、預り資産、コンプラランク、リスク説明不要な商品の情報が含まれる。一方、顧客の属性情報の種類が法人である場合、口座開設日、住所、役職・代表者名、電話番号、業種、資本金、預り資産、コンプラランク、リスク説明不要な商品の情報が含まれる。つまり、顧客情報記憶部１８のうちの既存客情報管理ＤＢ４０では、顧客の属性情報の種類として、複数の種類、具体的には個人と法人が規定されている。
【００４１】
顧客カードＤＢ４２は、各顧客に対して、第２取込部９２からのデータを記憶し顧客属性情報を記憶する。具体的には、投資経験に関する情報、取引種類、資金性格、投資方針、資産運用期間、主な収入源、金融資産、年収が含まれる。顧客カードＤＢ４２に格納されるデータの項目は、顧客の属性情報の種類にかかわらず同一である。既存客情報管理ＤＢ４０および顧客カードＤＢ４２に格納されたデータは、資産情報記憶部１４および顧客属性記憶部１６に格納されたデータの更新に応じて、更新される。そのため、顧客情報記憶部１８に格納されたデータは、所定のまたは任意のタイミングにて更新できるよう構成されている。
【００４２】
３．書類登録処理
図９は、書類登録部７２の構成を示す。書類登録部７２は、書類生成部９４を含む。また、書類登録部７２は、申請情報記憶部２０、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、申請情報記憶部２０、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００４３】
受付部９６は、承認申請の申請者からの入力を受けつける。入力は、キーボードやマウス等の入力機器を介してなされる。ここでの入力は、申請書類のフォーマットを作成するためのデータの入力に相当する。受付部９６は、入力されたデータを書類生成部９４へ出力する。書類生成部９４は、受付部９６からのデータを受けつける。書類生成部９４は、受けつけたデータをもとに、承認申請に用いられる書類（以下、「申請書類」という）のフォーマットを生成する。書類生成部９４は、作成中の申請書類のフォーマットを表示部９８に表示させる。フォーマットが定められた申請書類は、申請書類管理ＤＢに記憶される。
【００４４】
表示部９８は、書類生成部９４からの指示に応じて申請書類のフォーマットを表示する。図１０は、書類生成部９４によって生成される申請書類のフォーマットの登録画面を示す。画面中、書類コード欄６００には、申請書類を識別するために付与される書類コードが表示される。書類分類欄６０２には、申請書類の分類が表示される。書類名欄６０４には、申請書類の名称が表示される。申請書類を新規登録する場合、書類コード欄６００、書類分類欄６０２、書類名欄６０４は、新たに入力される。これらの下段には、申請書類に含まれる項目が示される。書類フォーマットの登録者は、項目内容を編集できる。そのため、右側の内容の部分に表示されるチェックボックス等は任意に設定可能である。
【００４５】
図１１は、書類生成部９４によって生成され承認者を設定するための申請書類承認者定義画面を示す。申請書類は、一般的に、書類の種類に応じて承認者が異なる。図９に戻る。申請書類管理ＤＢ５６は、書類生成部９４によって作成された申請書類のフォーマット情報を記憶する。申請書類管理ＤＢ５６に記憶される申請書類のフォーマット情報には、各書類について設定され登録された承認者情報も含まれる。
【００４６】
４．申請登録処理
図１２は、申請登録・照会部７４の構成を示す。申請登録・照会部７４は、申請処理部１００、申請状況照会部１０２を含み、申請処理部１００は、申請画面生成部１０４、取得部１０６、移動部１０８を含む。また、申請登録・照会部７４は、顧客情報記憶部１８、申請情報記憶部２０、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、顧客情報記憶部１８、申請情報記憶部２０、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００４７】
申請画面生成部１０４は、受付部９６から受けつけた指示であって、かつ申請者からの指示を受けつける。申請画面生成部１０４は、受付部９６で受けつけた指示をもとに、申請書類を作成するための画面を作成し、申請処理を実行する。図１３は、申請画面生成部１０４によって生成され申請書類管理ＤＢから申請の種類に応じて申請書類のフォーマットを呼び出した状態の書類選択画面を示す。書類コード欄６１０、書類分類欄６１２、書類名欄６１４は、図１０の書類コード欄６００、書類分類欄６０２、書類名欄６０４に対応しており、受付部９６が申請者からのこれらの欄への入力または顧客に紐づけられた口座番号の入力を受け付けることによってこれらの欄への入力で特定される申請書類または口座番号により特定される顧客について必要な申請書類のフォーマットが呼び出される。図１３では口座番号が指定されることでこの口座番号に紐づけられた顧客に関する承認申請に必要な複数の申請書類フォーマットの候補が書類コード欄６１０、書類分類欄６１２、書類名欄６１４の下に複数、表示された状態を示している。このように申請書類のフォーマットが示された状態において申請者は申請に必要な書類を特定して、申請入力ボタン６１６を押し下げることで申請書類の作成を開始する指示を入力する。図１２に戻る。申請画面生成部１０４は、申請書類の作成開始指示を受けつけると、申請書類管理ＤＢ５６から特定された申請書類のフォーマットを取得する。また、申請画面生成部１０４は、申請書類の作成開始指示を受けつけると、その旨を取得部１０６に通知する。その際、口座番号欄に入力され口座番号と一意に紐づけられた顧客を特定する情報（例えば顧客コード）も取得部１０６に通知される。
【００４８】
取得部１０６は、申請画面生成部１０４からの申請書類作成開始指示を受けつけると、顧客情報記憶部１８に含まれた既存客情報管理ＤＢ４０と顧客カードＤＢ４２とから、該当する顧客の属性情報および資産情報等を取得する。これらを取得するために、取得部１０６は、顧客コード等による検索を実行する。ここで、顧客情報記憶部１８の顧客情報は、顧客コードに紐づけられ記憶されている。よって、ひとつの顧客コードから、個人の属性情報あるいは法人の属性情報が取得されるので、申請画面生成部１０４から受けつけた顧客コードは、顧客の種類を特定するための情報ともいえる。
【００４９】
前述のごとく、取得部１０６によってアクセスされる顧客情報記憶部１８では、既存客情報管理ＤＢ４０の内容と顧客カードＤＢ４２の内容とが、所定のまたは任意のタイミングにて更新されている。取得部１０６は、顧客情報記憶部１８にアクセスした時点、すなわち、受付部９６が申請者からの申請書類作成指示の入力を受け付けた時点とほぼ同じ時点に顧客情報記憶部１８に保持されている顧客の属性情報と資産情報とを取得し、取得した顧客の資産情報と顧客の属性情報等を申請画面生成部１０４へ出力する。
【００５０】
申請画面生成部１０４は、既に取得した申請書類のフォーマット情報に加えて、取得部１０６において取得した顧客の資産情報と顧客の属性情報等をもとに、顧客に対する証券業務に関する承認申請を行うための申請内容編集画面を生成する。申請画面生成部１０４は、作成した画面を表示部９８に表示させる。表示部９８は、申請画面生成部１０４からの指示に応じて画面を表示する。図１４は、申請画面生成部１０４によって生成された申請内容編集画面を示す。特に、図１４は、顧客が個人である場合の申請内容編集画面である。図中の第１顧客属性表示欄６２０において既存客情報管理ＤＢから取得した顧客の属性情報が表示され、第２顧客属性表示欄６２２において顧客カードＤＢ４２から取得した顧客の属性情報が表示され、図中の預り資産欄６２４において、顧客カードＤＢ４２から取得した顧客の資産情報が表示される。これらの顧客情報表示欄６２０、６２２、６２４の下段には、申請内容が表示される。
【００５１】
図１５は、申請内容を照会するために申請画面生成部１０４によって生成される申請内容照会画面を示す。申請内容照会画面は、図１４の申請書類作成画面において仮保存ボタンが押し下げられたことを受付部９６が受け付けることで生成され、図１４の顧客情報表示欄の下段に表示された申請内容を表示する画面である。図１６は、申請画面生成部１０４によって生成される別の申請内容編集画面を示す。特に、図１６は、顧客が法人である場合の申請内容編集画面である。図中の第１顧客属性表示欄６３０において既存客情報管理ＤＢ４０から取得した顧客の属性情報が表示され、第２顧客属性表示欄６３２において顧客カードＤＢ４２から取得した顧客の属性情報が表示され、図中の預り資産欄６３４において、顧客カードＤＢ４２から取得した顧客の資産情報が表示される。第１顧客属性表示欄６３０に含まれる項目は、図１４の第１顧客属性表示欄６２０に含まれる項目と異なっている。これは、顧客の種類が異なるためである。一方、第２顧客属性表示欄６３２、預り資産欄６３４に含まれる項目は、図１４の第２顧客属性表示欄６２２、預り資産欄６２４に含まれる項目と同一である。
【００５２】
図１７は、申請画面生成部１０４によって生成される別の申請内容照会画面を示す。これは、必要な項目の入力が完了し、申請可能な状態である場合に相当する。そのため、申請ボタン６４０が表示されている。図１２に戻る。表示部９８に申請内容照会画面を表示させた状態において、申請者が申請ボタン６４０を押し下げることで承認申請の開始を行う指示を入力することにより、申請画面生成部１０４は、受付部９６から証券業務の申請開始指示を受けつける。申請画面生成部１０４は、証券業務の申請開始指示を受けつけると、申請に係るデータを申請情報記憶部２０に記憶させるよう、移動部１０８に指示する。
【００５３】
移動部１０８は、申請画面生成部１０４からの指示を受けつけると、申請画面を生成するために使用したデータを申請情報記憶部２０に記憶させる。つまり、申請書類の作成が完了し申請開始が指示された申請に係るデータは、申請情報記憶部２０に記憶される。特に、移動部１０８は、既存客情報管理ＤＢ４０と顧客カードＤＢ４２から取得された顧客の資産情報と顧客の属性情報等とを申請顧客情報ＤＢ４８へ削除以外の編集が不可能な状態（すなわち固定した状態）で記憶させる。また、移動部１０８は、申請開始指示を行ってから承認が完了するまでの間、追加や修正等の編集が行われるデータを申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶させる。申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶させるデータの内容は後述する。
【００５４】
前述のごとく、申請顧客情報ＤＢ４８に記憶されたデータは、申請から承認までの間において、削除される場合を除いて、追加や変更等の編集ができないように固定されている。そのため、既存客情報管理ＤＢ４０と顧客カードＤＢ４２に記憶され種々のタイミングや頻度で更新され変動しうるデータは、申請開始の指示が完了されたタイミングにおいて、申請顧客情報ＤＢ４８に記憶されることによって固定される。一方、申請開始指示により申請顧客情報ＤＢ４８に固定されたデータの元データであって既存客情報管理ＤＢ４０と顧客カードＤＢ４２に記憶されていたデータは、申請顧客情報ＤＢ４８への記憶が行われた後も変動され続けうる。一方、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶されたデータは、申請から承認までの間において、編集可能である。
【００５５】
申請顧客情報ＤＢ４８は、申請書類の作成が完了し申請開始の指示が完了したタイミングで顧客情報を記憶する。申請顧客情報ＤＢ４８では、ひとつの申請につき、１行の情報が登録される。図１８（ａ）−（ｆ）は、申請顧客情報ＤＢ４８のデータ構造を示す。申請顧客情報ＤＢ４８に格納されたデータの項目数が多いので、ここでは図１８（ａ）−（ｆ）に分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄４５０、申請番号欄４５２、部店欄４５４、口座番号欄４５６、顧客名欄４５８、郵便番号欄４６０、住所欄４６２、職業欄４６４、生年月日欄４６６、電話番号欄４６８、口座開設日欄４７０、性別欄４７２、資産欄４７４、コンプラランク欄４７６、役職欄４７８、勤務先欄４８０、代表者名欄４８２、資本金欄４８４、リスク説明不要（株式）欄４８６、リスク説明不要（債券）欄４８８、リスク説明不要（転換社債）欄４９０、リスク説明不要（外証）欄４９２、取引動機欄４９４、投資経験有無（株式現物）欄４９６、投資経験有無（債券）欄４９８、投資経験有無（転換社債）欄５００、投資経験有無（株式信用）欄５０２、投資経験有無（ワラント）欄５０４、投資経験有無（先物・ＯＰ）欄５０６、投資経験有無（貯蓄型投信）欄５０８、投資経験有無（投資信託）欄５１０、投資経験有無（外国証券）欄５１２、投資経験有無（その他）欄５１４、資金性格欄５１６、投資方針欄５１８、主な収入源欄５２０、推定年収欄５２２、金融資産欄５２４、資産運用期間欄５２６が含まれる。申請は、申請番号欄４５２に示された申請番号によって各申請が一意に識別される。他の項目は、既存客情報管理ＤＢ４０および顧客カードＤＢ４２に格納されたデータの項目に類似する。
【００５６】
申請管理ＤＢ５０は、申請開始の指示が完了した申請書類に係るデータを記憶する。申請管理ＤＢ５０は、ふたつの部分によって構成される。ひとつが申請管理であり、もうひとつが申請内容管理である。申請管理は、申請書類の基本的な情報（すなわち属性情報）を記憶する。申請管理では、ひとつの申請につき、１行の情報が登録される。図１９は、申請管理ＤＢ５０のデータ構造を示す。図示のごとく、ユーザ欄５３０、申請番号欄５３２、書類コード欄５３４、部店欄５３６、口座番号欄５３８、顧客名欄５４０、申請者名欄５４２、申請状況欄５４４、申請日時欄５４６、申請完了日欄５４８が含まれる。
【００５７】
一方、申請内容管理は、申請ごとに申請内容を記憶する。つまり、申請内容管理に記憶された内容が、申請書類の実質的な内容に相当し、申請管理は、申請内容管理を識別するためのインデックスに相当する。そのため、申請内容では、ひとつの申請につき、申請書類の項目数に応じた１以上の行の情報が登録される。図２０は、申請管理ＤＢ５０の別のデータ構造を示す。図示のごとく、ユーザ欄５５０、申請番号欄５５２、申請内容の項目番号欄５５４、内容欄５５６が含まれる。申請管理ＤＢのデータは、申請内容等に変更が生じた場合等のタイミングで更新される。
【００５８】
申請状況管理ＤＢ５２は、申請ごとに定義された申請者および承認者の登録状況を記憶する。申請状況管理ＤＢ５２では、ひとつの申請につき、複数行の情報が登録される。複数行は、書類に対する承認者の数と申請者の数との和に相当する。申請状況ＤＢのデータは承認処理が行われたタイミングなどで更新される。図２１は、申請状況管理ＤＢ５２のデータ構造を示す。図示のごとく、ユーザ欄５６０、申請番号欄５６２、役職欄５６４、登録状況欄５６６、登録日時欄５６８、登録者氏名欄５７０が含まれる。登録状況欄５６６において、現在のステータスが示される。
【００５９】
監査証跡管理ＤＢ５４は、申請書類に対する更新の履歴を記憶する。監査証跡管理ＤＢ５４では、ひとつの申請につき、更新した数だけの情報が記憶される。監査証跡管理ＤＢ５４も更新が行われたタイミングで更新される。図２２は、監査証跡管理ＤＢ５４のデータ構造を示す。図示のごとく、ユーザ欄５８０、申請番号欄５８２、更新時間欄５８４、更新者欄５８６、更新内容欄５８８、役職欄５９０が含まれる。更新時間欄５８４では、更新時間が示される。図１２に戻る。
【００６０】
申請状況照会部１０２は、申請開始の指示が完了した後、受付部９６から受けつけた指示であって、照会者からの照会指示を受けつける。当該指示は、申請状況の照会要求である。申請状況照会部１０２は、照会指示を受けつけると、申請状況管理ＤＢ５２に記憶されたデータを取得する。なお、申請状況照会部１０２は、申請管理ＤＢ５０、監査証跡管理ＤＢ５４に記憶されたデータを取得しない。つまり、申請情報記憶部２０は、参照のタイミングに応じて、複数の部分に分割して構成されている。複数の部分は、申請顧客情報ＤＢ４８、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に相当する。このうち、申請顧客情報ＤＢには固定された状態でデータが記憶され削除以外の編集ができない一方、その他のＤＢについてはデータが編集可能に構成されている。申請状況照会部１０２は、取得したデータをもとに申請状況一覧画面を生成し、生成した画面を表示部９８に表示する。図２３は、申請状況照会部１０２によって生成される申請状況一覧画面を示す。図示のごとく、申請状況と承認状況が申請ごとに表示される。複数の承認者が設定されている場合、複数の承認者のそれぞれにおける承認状況が示される。
【００６１】
５．承認登録処理
図２４は、承認登録部７６の構成を示す。承認登録部７６は、承認画面生成部１１０、移動部１１２を含む。また、承認登録部７６は、申請情報記憶部２０、承認情報記憶部２２、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、申請情報記憶部２０、承認情報記憶部２２、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００６２】
承認画面生成部１１０は、受付部９６から受けつけた指示であって、かつ承認者からの承認申請表示指示を受けつける。当該指示は、承認申請を表示させる要求であり、この例では承認状況情報を伴って承認申請案件が表示されるため、承認申請表示要求は、前述の申請状況の照会要求と類似している。申請状況の照会要求では、申請状況と承認状況が申請ごとに表示部９８に表示されるのに対して、承認申請表示要求では、承認状況が申請ごとに表示部９８に表示される。承認画面生成部１１０は、承認申請表示指示を受けつけると、申請状況管理ＤＢ５２に記憶されたデータを取得する。承認画面生成部１１０は、取得したデータをもとに承認申請表示画面を生成し、生成した画面を表示部９８に表示する。図２５は、承認画面生成部１１０によって生成される承認申請表示画面を示す。図示のごとく、承認状況が申請ごとに表示される。承認状況が「承認待ち」であることは、承認あるいは非承認すべき状況に相当する。一方、承認状況が「未承認」であることは、他の承認者が承認あるいは非承認すべき状況に相当する。さらに、承認状況が「承認済」であることは、既に承認した状況に相当する。なお、承認状況が「非承認」であることは、いずれかの承認者によって非承認された状況に相当する。図２４に戻る。
【００６３】
表示部９８に承認申請表示画面を表示させた状態において、承認者が申請番号を特定して押し下げると、承認画面生成部１１０は、受付部９６から、特定された申請番号に対応した申請書類の表示指示を受けつける。承認画面生成部１１０は、受けつけた指示に応じて、該当する顧客の顧客情報を申請顧客情報ＤＢ４８から取得し、申請についての属性情報と申請内容の情報とを申請管理ＤＢ５０から取得する。承認画面生成部１１０は、取得したデータをもとに、承認内容照会画面を作成し、作成した承認内容照会画面を表示部９８に表示させる。
【００６４】
図２６は、承認画面生成部１１０によって生成される承認内容照会画面を示す。図示のごとく、申請書類と同様の内容が表示される。承認者は、承認内容照会画面の内容を確認し、承認する場合、承認ボタン６５０をマウスでクリックする。一方、承認者は非承認する場合、非承認ボタン６５２をマウスでクリックする。なお、承認者記入ボタンがクリックされると、承認画面生成部１１０は、承認者記入欄編集画面を表示部９８に表示させる。図２７は、承認画面生成部１１０によって生成される承認者記入欄編集画面を示す。内容の部分に示された項目は、顧客の属性に応じて規定される。図２４に戻る。
【００６５】
承認者による承認・非承認の指示が入力されると、承認画面生成部１１０は、受付部９６から、承認者による承認処理完了の指示を受けつける。これは、申請開始指示に対する承認処理の完了指示である。承認画面生成部１１０は、承認処理完了の指示を受けつけると、承認対象のデータを移動部１１２に更新不能な状態で記憶するように指示する。なお、複数の承認者が設定されている場合、承認画面生成部１１０は、最後の承認者が承認処理の完了を指示したときに移動部１１２にデータの記録を指示する。承認者が残っている場合、承認画面生成部１１０は、申請状況管理ＤＢ５２および監査証跡管理ＤＢ５４のデータを更新する。
【００６６】
移動部１１２は、承認画面生成部１１０からの指示を受けつけると、申請顧客情報ＤＢ４８に記憶されたデータを申請顧客履歴情報ＤＢ５８に更新不能な状態で記憶させる。ここでのデータは、前述のごとく、顧客の資産情報と顧客の属性情報等に相当する。また、移動部１１２は、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶されたデータを申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４にそれぞれ更新不能な状態で記憶させる。これらのデータは、申請顧客情報ＤＢ４８に記憶されたデータに付随した申請情報ともいえ、申請開始の指示から承認完了の指示までの間において内容が更新可能とされていたデータを元データとする。
【００６７】
一方、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４に記憶された申請情報は、更新不可能である。申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４は、承認情報記憶部２２に格納されているので、承認情報記憶部２２は、承認後のデータを記憶する。なお、申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４でのデータ構造は、申請顧客情報ＤＢ４８、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４でのデータ構造とそれぞれ同様であるので、ここでは説明を省略する。
【００６８】
６．事務処理登録処理
図２８は、事務処理登録部７８の構成を示す。事務処理登録部７８は、申請情報記憶部２０、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、申請情報記憶部２０、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００６９】
事務処理登録部７８は、受付部９６から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、事務処理状況の照会要求である。事務処理登録部７８は、指示を受けつけると、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶されたデータを取得する。
【００７０】
事務処理登録部７８は、取得したデータをもとに事務処理状況一覧画面を生成し、生成した画面を表示部９８に表示する。図２９は、事務処理登録部７８によって生成される事務処理状況一覧画面を示す。図示のごとく、処理状況が申請ごとに表示される。処理状況が「処理待ち」であることは、事務処理を実行すべき状況に相当する。一方、処理状況が「未処理」であることは、他の社員が事務処理を実行すべき状況に相当する。さらに、処理状況が「処理済」であることは、既に処理した状況に相当する。
【００７１】
７．申請保管処理
図３０は、申請保管部８０の構成を示す。申請保管部８０は、承認情報記憶部２２、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、承認情報記憶部２２、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００７２】
申請保管部８０は、受付部９６から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、承認が完了した申請書類の照会要求である。申請保管部８０は、指示を受けつけると、申請状況履歴管理ＤＢ６２に記憶されたデータを取得する。申請保管部８０は、取得したデータをもとに保管している申請を表示する画面を生成し、生成した画面を表示部９８に出力する。図３１は、申請保管部８０によって生成される保管申請表示画面を示す。図示のごとく、承認状況が確認される。なお、申請番号が選択されると、申請保管部８０は、申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０に記憶されたデータを取得し、承認された申請書類を表示部９８に表示してもよい。
【００７３】
８．監査証跡管理処理
図３２は、監査証跡管理部８２の構成を示す。監査証跡管理部８２は、申請情報記憶部２０、承認情報記憶部２２、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、申請情報記憶部２０、承認情報記憶部２２、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００７４】
監査証跡管理部８２は、受付部９６から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、申請書類に対する監査証跡の照会要求である。ここで、照会対象の申請書類に対して、承認が完了している場合があれば、承認が完了していない場合もある。監査証跡管理部８２は、指示とともに申請番号も受けつけており、監査証跡管理ＤＢ５４および監査証跡履歴管理ＤＢ６４を参照することによって、申請番号に対応したデータが格納されている方を特定する。申請番号に対応したデータが監査証跡管理ＤＢ５４に含まれていることは、承認が完了していない申請書類に対する監査証跡を照会することに相当する。
【００７５】
一方、申請番号に対応したデータが監査証跡履歴管理ＤＢ６４に含まれていることは、承認が完了した申請書類に対する監査証跡を照会することに相当する。監査証跡管理部８２は、申請番号に対応したデータが監査証跡管理ＤＢ５４に含まれている場合、監査証跡管理ＤＢ５４に記憶されたデータを取得する。一方、監査証跡管理部８２は、申請番号に対応したデータが監査証跡履歴管理ＤＢ６４に含まれている場合、監査証跡履歴管理ＤＢ６４に記憶されたデータを取得する。監査証跡管理部８２は、取得したデータをもとに申請更新履歴照会画面を生成し、生成した画面を表示部９８に出力する。
【００７６】
ここで、申請情報記憶部２０に記憶された第２ＤＢ４６のうち、監査証跡管理ＤＢ５４だけが使用され、申請管理ＤＢ５０、申請状況管理ＤＢ５２は使用されていない。また、承認情報記憶部２２に記憶された申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４のうち、監査証跡履歴管理ＤＢ６４だけが使用され、残りは使用されていない。つまり、監査証跡管理部８２によって使用される部分は、申請情報記憶部２０および承認情報記憶部２２のうち、対応した部分である。そのため、承認情報記憶部２２は、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４のように、複数の部分に分割して構成されている。このような分割は、第２ＤＢ４６での構成に合わせられている。図３３は、監査証跡管理部８２によって生成される申請更新履歴照会画面を示す。図示のごとく、誰がいつ、何を実施したかが確認可能なような表示がなされる。
【００７７】
９．動作
以上の構成による証券業務システム２００の動作を説明する。図３４は、証券業務システム２００による申請処理の手順を示すシーケンス図である。第１端末装置１２ａは、申請者からの開始指示を申請サーバ１０へ送信する（Ｓ１０）。申請サーバ１０は、顧客情報記憶部１８からデータを取得する（Ｓ１２）。申請サーバ１０は、申請画面を生成する（Ｓ１４）。申請サーバ１０は、生成した申請画面の表示指示を第１端末装置１２ａへ送信する（Ｓ１６）。第１端末装置１２ａは、申請画面を表示する（Ｓ１８）。第１端末装置１２ａは、申請者からの申請開始の指示を申請サーバ１０へ出力する（Ｓ２０）。申請サーバ１０は、申請画面を生成するために取得し、および入力されたデータを申請情報記憶部２０に送信する（Ｓ２２）。申請情報記憶部２０は、データを記憶する（Ｓ２４）。
【００７８】
図３５は、証券業務システム２００による承認処理の手順を示すシーケンス図である。申請サーバ１０は、申請情報記憶部２０からデータを取得する（Ｓ３０）。申請サーバ１０は、承認画面を生成する（Ｓ３２）。申請サーバ１０は、生成した承認画面の表示指示を第２端末装置１２ｂへ送信する（Ｓ３４）。第２端末装置１２ｂは、承認画面を表示する（Ｓ３６）。第２端末装置１２ｂは、承認者からの承認指示を申請サーバ１０へ出力する（Ｓ３８）。申請サーバ１０は、データの移動指示を申請情報記憶部２０へ送信し（Ｓ４０）、申請情報記憶部２０は、データを承認情報記憶部２２に送信する（Ｓ４２）。承認情報記憶部２２は、データを記憶する（Ｓ４４）。
【００７９】
本発明の実施例によれば、顧客が個人であるか法人であるかに応じてコンプライアンスチェックやその他の承認に必要な属性情報が異なっていても、顧客が個人であるか法人であるかに応じて属性情報を別々に記憶するので、属性情報を効率的に記憶できる。また、顧客が個人であるか法人であるかに応じて属性情報を別々に取得して表示するので、承認判断に必要な情報を顧客の種類に応じて的確に参照できる。また、変動する資産情報や属性情報等を予め顧客情報記憶部に記憶しておくので、申請に際して必要な顧客情報を迅速に取得できる。また、申請の指示を受けつけた場合に、顧客情報記憶部に記憶された更新可能な情報を、固定の情報として申請情報記憶部に記憶させるので、申請を承認する際に必要な情報が変動することを防止できる。また、固定すべき情報を誤って更新してしまう危険性を低減できる。
【００８０】
また、情報の性質に応じて、記憶部の構成を分けるので、処理を効率的に実行できる。また、開始指示に対する顧客の種類と、属性情報の種類とが対応しているので、受けつけた顧客の種類に合った属性情報を取得できる。また、受けつけた顧客の種類に合った属性情報が取得されるので、承認判断に必要な属性情報を正確に取得できる。また、承認判断に必要な属性情報が正確に取得されるので、承認の正確な処理を実現できる。
【００８１】
また、承認指示を受けつけた場合に、申請情報記憶部に記憶された更新可能な情報を、更新不可能の情報として承認情報記憶部に記憶させるので、更新不可能な情報を誤って更新してしまう危険性を低減できる。また、更新不可能な情報を誤って更新してしまう危険性が低減されるので、性質の異なった情報を確実に処理できる。また、第２ＤＢは、参照のタイミングに応じて、複数の部分に分割して構成されているので、必要な情報のみにアクセスできる。また、必要な情報のみにアクセスされるので、処理を効率を向上できる。
【００８２】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【符号の説明】
【００８３】
１０ 申請サーバ、 １２ 端末装置、 １４ 資産情報記憶部、 １６ 顧客属性記憶部、 １８ 顧客情報記憶部、 ２０ 申請情報記憶部、 ２２ 承認情報記憶部、 ２４ ネットワーク、 ３０ 預りＤＢ、 ３２ 資産ＤＢ、 ３４ 共通属性ＤＢ、 ３６ 個人属性ＤＢ、 ３８ 法人属性ＤＢ、 ４０ 既存客情報管理ＤＢ、 ４２ 顧客カードＤＢ、 ４４ 第１ＤＢ、 ４６ 第２ＤＢ、 ４８ 申請顧客情報ＤＢ、 ５０ 申請管理ＤＢ、 ５２ 申請状況管理ＤＢ、 ５４ 監査証跡管理ＤＢ、 ５６ 申請書類管理ＤＢ、 ５８ 申請顧客履歴情報ＤＢ、 ６０ 申請履歴管理ＤＢ、 ６２ 申請状況履歴管理ＤＢ、 ６４ 監査証跡履歴管理ＤＢ、 ７２ 書類登録部、 ７４ 申請登録・照会部、 ７６ 承認登録部、 ７８ 事務処理登録部、 ８０ 申請保管部、 ８２ 監査証跡管理部、 ８４ ＩＦ部、 ９０ 第１取込部、 ９２ 第２取込部、 ９４ 書類生成部、 ９６ 受付部、 ９８ 表示部、 １００ 申請処理部、 １０２ 申請状況照会部、 １０４ 申請画面生成部、 １０６ 取得部、 １０８ 移動部、 １１０ 承認画面生成部、 １１２ 移動部、 ２００ 証券業務システム。
【技術分野】
【０００１】
この発明は、申請技術に関し、特に、証券業務に関連した申請を実行する申請方法および申請装置に関する。
【背景技術】
【０００２】
会社等の組織において業務上の責任の所在を明確にするために、一般的に、書類の申請および承認がなされている。従来、書類の申請および承認手続きは、紙媒体を使用してサインや押印によって行われていた。近年、コンピュータおよびネットワークの普及によって、コンピュータによる申請書類の作成が可能となり、申請者の端末にて作成された申請書類のデータが、ネットワークを通じて承認者の端末に伝送される。さらに、承認者の端末において承認入力がなされることによって、書類の申請および承認が迅速かつ容易に行われる。
【０００３】
しかしながら、申請者が書類のデータを管理者に一度申請をしてしまうと、申請後に緊急に書類を修正する必要が発生しても、承認者の承認または非承認を受けるまでは、再度編集できない。そのため、効率的でなかった。これに対応するため、書類データに対して、作成中、申請中、承認済み、申請却下のステータスを付与して一元管理し、申請者の端末でステータスを「作成中」から「申請中」へと変更することにより申請がなされる。また、「申請中」から「作成中」へと変更することにより申請取下げがなされる（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−７１１８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
申請および承認をコンピュータネットワークにて実行するシステムは、証券業務でも必要とされる。例えば、信用取引口座開設申請書、短期売却届出書等を申請して承認を受けるために申請書の作成と承認処理が必要となる。このような証券業務における申請および承認をコンピュータネットワークにて実行するシステムで行おうとする場合、証券業務に特有の課題がある。課題のひとつは、申請を承認するか否かを判断するために申請内容応じた種々の情報が必要であり、例えば顧客の住所、氏名、年齢といった属性情報のみならず、顧客の所有している資産情報や顧客の投資方針等が必要になる場合があることである。ここで、申請・承認の際に必要となる情報は任意のタイミングで更新される必要があり、更新の頻度やタイミングは情報によって異なる。例えば顧客の住所のような属性情報は更新は少なく、更新するタイミングも顧客から連絡があった場合や証券会社の社員が顧客に営業を行うなどして連絡を取った場合のように自由に更新できることが好ましい。一方、顧客の資産情報については例えば、株価は日々変動するため更新頻度は多く、株価情報は通常、定期的に更新されるため、資産情報についてはある程度、定期的に更新できることが好ましい。このように申請および承認に際して必要な様々な情報は多岐にわたり、それぞれ異なる頻度やタイミングで更新できる必要があることが別の課題となっている。以下、この課題を具体的に説明する。
【０００６】
申請および承認の内容を事後的に監査等することを考慮すると、申請および承認の際に参照される情報は少なくとも申請時点において固定された状態で承認申請、承認判断、承認完了という承認申請手続きを経て保存される必要がある。このため、申請および承認をシステムで行うためには、申請および承認に必要な情報を任意のタイミングで更新可能とすることと、申請および承認時に参照された情報が固定されることとを両立させる必要がある。
【０００７】
本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、証券業務の状況を考慮して書類の申請処理を実行する技術を提供することである。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明のある態様の申請装置は、申請者から、証券業務に関する承認申請の開始指示を受けつける第１受付部と、第１受付部が開始指示を受けつけると、顧客の資産情報と顧客の属性情報とを本申請装置とは独立して任意のタイミングで更新して記憶する第１記憶部から、顧客の資産情報と顧客の属性情報とを取得する取得部と、取得部において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成する生成部と、生成部において生成した申請画面を表示させる表示部と、表示部が申請画面を表示させた状態において、申請者から、証券業務の承認申請を行う旨の申請指示を受けつける第２受付部と、第２受付部が申請指示を受けつけると、生成部が申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを固定して第２記憶部に記憶させる移動部と、第２受付部において受けつけた申請指示に対して、承認者からの承認指示を受けつける第３受付部とを備える。第２記憶部は、第２受付部において申請指示を受けつけることで顧客の資産情報と顧客の属性情報との書き込みを実行し、移動部は、第３受付部が承認指示を受けつけると、第２記憶部に記憶された顧客の資産情報と顧客の属性情報を更新不可能な状態で、第２記憶部とは別に設けられた第３記憶部に記憶させる。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、証券業務の状況を考慮して書類の申請処理を実行できる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施例に係る証券業務システムの構成を示す図である。
【図２】図１の申請サーバの構成を示す図である。
【図３】図２の顧客情報生成部の構成を示す図である。
【図４】図１の預りＤＢのデータ構造を示す図である。
【図５】図１の資産ＤＢのデータ構造を示す図である。
【図６】図１の共通属性ＤＢのデータ構造を示す図である。
【図７】図７（ａ）−（ｃ）は、図１の個人属性ＤＢのデータ構造を示す図である。
【図８】図８（ａ）−（ｂ）は、図１の法人属性ＤＢのデータ構造を示す図である。
【図９】図２の書類登録部の構成を示す図である。
【図１０】図９の書類生成部によって生成される申請書類登録画面を示す図である。
【図１１】図９の書類生成部によって生成される申請書類承認者定義画面を示す図である。
【図１２】図２の申請登録・照会部の構成を示す図である。
【図１３】図１２の申請画面生成部によって生成される口座指定・書類選択画面を示す図である。
【図１４】図１２の申請画面生成部によって生成される申請内容編集画面を示す図である。
【図１５】図１２の申請画面生成部によって生成される申請内容照会画面を示す図である。
【図１６】図１２の申請画面生成部によって生成される別の申請内容編集画面を示す図である。
【図１７】図１２の申請画面生成部によって生成される別の申請内容照会画面を示す図である。
【図１８】図１８（ａ）−（ｆ）は、図１の申請顧客情報ＤＢのデータ構造を示す図である。
【図１９】図１の申請管理ＤＢのデータ構造を示す図である。
【図２０】図１の申請管理ＤＢの別のデータ構造を示す図である。
【図２１】図１の申請状況管理ＤＢのデータ構造を示す図である。
【図２２】図１の監査証跡管理ＤＢのデータ構造を示す図である。
【図２３】図１２の申請状況照会部によって生成される申請状況一覧画面を示す図である。
【図２４】図２の承認登録部の構成を示す図である。
【図２５】図２４の承認画面生成部によって生成される承認状況一覧画面を示す図である。
【図２６】図２４の承認画面生成部によって生成される承認内容照会画面を示す図である。
【図２７】図２４の承認画面生成部によって生成される承認者記入欄編集画面を示す図である。
【図２８】図２の事務処理登録部の構成を示す図である。
【図２９】図２８の事務処理登録部によって生成される事務処理状況一覧画面を示す図である。
【図３０】図２の申請保管部の構成を示す図である。
【図３１】図３０の申請保管部によって生成される申請保管一覧画面を示す図である。
【図３２】図２の監査証跡管理部の構成を示す図である。
【図３３】図３２の監査証跡管理部によって生成される申請更新履歴照会画面を示す図である。
【図３４】図１の証券業務システムによる申請処理の手順を示すシーケンス図である。
【図３５】図１の証券業務システムによる承認処理の手順を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
本発明を具体的に説明する前に、まず概要を述べる。本発明の実施例に係る証券業務システムは、証券会社の社員である申請者の操作によって、証券業務における書類を作成し、作成した書類を申請する。また、証券業務システムは、証券会社の別の社員である承認者の操作によって、申請された書類を承認したり、非承認したりするとともに、承認前の書類や承認後の書類を管理する。ここで、書類とは、例えば、信用取引口座開設申請書、短期売却届出書であり、これらには、不正な取引を防止するためのコンプライアンスを遵守するといった目的のために、申請および承認が必要とされる。申請および承認のための証券業務システムでは、証券業務特有の事情を考慮して構成されるべきである。
【００１３】
承認する際に、顧客の資産が考慮されることもある。このような資産には、株、社債、投資信託が含まれ、それらも証券業務システムにて管理されている。それらの価値は日々変動しているので、顧客の資産は日々変動している。また、承認に際しては顧客の氏名や住所といった属性情報も必要であるが、これらの情報は任意のタイミングで変動する。つまり、これらの情報は任意のタイミング、頻度で変動するため、これらをシステムで管理するに際しては任意のタイミングで更新可能としておくことが望ましい。一方、承認対象となる書類において資産や顧客属性の情報は固定されていないと、承認者は承認できず、承認後の監査も困難となる。なお、承認に際して必要な顧客の情報は顧客が個人であるか法人であるかによっても異なる。そのため、書類を作成する際に、顧客の種類に応じて承認に必要な情報が申請および承認時に容易に参照できるようになっていることが望まれる。
【００１４】
これらに対応するために、本実施例に係る証券業務システムでは、申請者が書類を作成する際に、申請および承認に際して求められる情報を任意のタイミングで更新可能な状態で記憶されたデータベースから、必要なデータを抽出する。なお、抽出されるデータは、顧客の種類によって異なる。申請者が作成した書類を申請する際に、証券業務システムは、書類の作成時に抽出したデータを固定して別のデータベースに記憶する。当該別のデータベースでは、固定したデータが記憶されている。承認者が書類を承認する際には、固定したデータが記憶されたデータベースが参照される。このように、申請および承認に必要なデータは、更新可能に記憶された記憶部に保持され任意のタイミングで更新され、申請時にはこの記憶部から取得され、申請完了に伴って固定されることで固定したデータが別のデータベースに格納される。
【００１５】
以下では、説明を明瞭にするために、証券業務システムを複数に分けて説明する。まず、１．全体構成を説明した後に、２．顧客情報生成処理、３．書類登録処理、４．申請登録処理、５．承認登録処理、６．事務処理登録処理、７．申請保管処理、８．監査証跡管理処理の各処理を説明する。その後、９．動作を説明する。
【００１６】
１．全体構成
図１は、本発明の実施例に係る証券業務システム２００の構成を示す。証券業務システム２００は、申請サーバ１０、端末装置１２と総称される第１端末装置１２ａ、第２端末装置１２ｂ、資産情報記憶部１４、顧客属性記憶部１６、顧客情報記憶部１８、申請情報記憶部２０、承認情報記憶部２２、ネットワーク２４、顧客情報生成部７０を含む。資産情報記憶部１４は、預りＤＢ３０、資産ＤＢ３２を含み、顧客属性記憶部１６は、共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８を含み、顧客情報記憶部１８は、既存客情報管理ＤＢ４０、顧客カードＤＢ４２を含む。申請情報記憶部２０は、第１ＤＢ４４、第２ＤＢ４６、申請書類管理ＤＢ５６を含み、第１ＤＢ４４は、申請顧客情報ＤＢ４８を含み、第２ＤＢ４６は、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４を含む。承認情報記憶部２２は、申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４を含む。
【００１７】
端末装置１２は、証券会社の社員が証券業務のための書類を作成する際に使用する装置であり、例えば、ＰＣに相当する。端末装置１２は、通信機能を備え、ネットワーク２４に接続される。図１では、２台の端末装置１２が示されているが、これに限定されない。また、第１端末装置１２ａは、書類を申請すべき社員（以下、「申請者」という）によって使用され、第２端末装置１２ｂは、申請された書類を承認すべき社員（以下、「承認者」という）によって使用されるものとする。
【００１８】
申請サーバ１０は、ネットワーク２４を介して、端末装置１２に接続されたサーバである。申請サーバ１０は、端末装置１２からの指示に応じた処理を実行し、その結果を端末装置１２に返信する。
【００１９】
資産情報記憶部１４は、預りＤＢ３０、資産ＤＢ３２を記憶するための記憶媒体である。資産情報記憶部１４は、ネットワーク２４に接続され、申請サーバ１０からアクセスされることで申請サーバ１０によって必要な情報が取り出されてもよい。図１の態様では、後述する顧客情報生成部７０が資産情報記憶部１４と顧客属性記憶部１６とから顧客の資産情報と顧客属性とをそれぞれ取り込んで顧客ごとに申請および承認に必要な情報を生成した情報を記憶する顧客情報記憶部１８を介して資産情報記憶部１４の情報が申請サーバ１０に取り出されるように構成されている。預りＤＢ３０および資産ＤＢ３２に格納されるデータの内容については後述するが、これらのデータの内容は日々変動する。変動の周期は、一般的に１日よりも短く変動タイミングは一般的に予め定められている。このように、資産情報記憶部１４は、所定のタイミグで更新されるデータを更新可能な状態で記憶するための記憶媒体（第１記憶部）である。
【００２０】
顧客属性記憶部１６は、共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８を記憶するための記憶媒体である。本実施形態では上述した通り顧客属性記憶部１６の情報は顧客情報生成部７０により生成され顧客情報記憶部１８に記憶された情報として申請サーバ１０によって取り出されるように構成されているが、顧客属性記憶部１６は、ネットワーク２４に接続され、申請サーバ１０からアクセスされることで申請サーバ１０が直接、顧客属性記憶部１６から必要な情報を取り出すようにしてもよい。共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８に格納されるデータの内容については後述するが、これらのデータの内容は任意のタイミングで変動する。このように、顧客属性記憶部１６は、任意のタイミングで更新されるデータを更新可能な状態で記憶するための記憶媒体（第１記憶部）である。
【００２１】
顧客情報記憶部１８は、資産情報記憶部１４と顧客属性記憶部１６とから顧客の資産情報と顧客属性とをそれぞれ取り込んで顧客ごとに申請および必要な情報として取り出しやすくした状態として既存客情報管理ＤＢ４０、顧客カードＤＢ４２に情報を記憶するための記憶媒体である。顧客情報記憶部１８は、ネットワーク２４に接続され、申請サーバ１０からアクセスされる。既存客情報管理ＤＢ４０および顧客カードＤＢ４２に格納されるデータは、預りＤＢ３０、資産ＤＢ３２、共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８に格納されたデータをもとに生成される。そのため、顧客情報記憶部１８のデータは、適宜、更新され、顧客情報記憶部１８も適宜、更新されるデータを更新可能な状態で記憶するための記憶媒体である。
【００２２】
申請情報記憶部２０は、申請顧客情報ＤＢ４８、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４、申請書類管理ＤＢ５６を記憶するための記憶媒体である。申請情報記憶部２０は、申請サーバ１０からアクセスされる。申請顧客情報ＤＢ４８、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４、申請書類管理ＤＢ５６は、書類を申請してから承認するまでの期間においてデータを格納する。申請顧客情報ＤＢ４８に格納されたデータは、書類を申請してから承認するまでの期間において固定されている。つまり、削除される場合を除いて編集や修正はなされない。
【００２３】
そのため、申請完了時点では顧客情報記憶部１８と申請顧客情報ＤＢ４８に同様の内容のデータが記憶され、その後、顧客情報記憶部１８のデータ内容が変更されても申請情報記憶部２０には申請時点のデータが内容変更できない（すなわち固定された）状態で記憶される。このように申請完了時点に取得された顧客情報を申請顧客情報ＤＢ４８に固定して記憶させることで編集禁止のデータを誤って編集してしまうが防止され、その後の承認手続きにおいて申請時点の顧客情報を参照することができる。一方、申請情報記憶部２０の申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４、申請書類管理ＤＢ５６に格納されたデータは、編集可能である。このように、申請情報記憶部２０は、固定されたデータが記憶される申請顧客情報ＤＢ４８（第１ＤＢ４４）と申請完了から承認完了までの間、更新可能なデータが記憶される申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４（第２ＤＢ４６）とを備える記憶媒体である。
【００２４】
承認情報記憶部２２は、申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４を記憶するための記憶媒体である。承認情報記憶部２２は、ネットワーク２４に接続され、申請サーバ１０からアクセスされる。申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４は、承認された申請についてのデータを格納する。申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４に格納されたデータは、編集されずに固定された状態で記憶されている。このように承認情報記憶部２２は、固定されたデータを格納するための記憶媒体であるともいえる。
【００２５】
承認情報記憶部２２のうち、申請顧客履歴情報ＤＢ５８には申請完了時点で取得され申請顧客情報ＤＢ４８に固定して記憶された顧客情報が固定して記憶されており、承認手続き中と同様に承認完了後も申請完了時点に取得された顧客情報が保持され参照することができる。申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４に記憶されたデータは、それぞれ申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶されたデータの内容が承認完了時に固定されたものである。そのため、承認手続き中は申請情報記憶部２０の申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４により申請内容や承認申請の状況等を確認しつつ、承認手続き後は申請の内容、履歴、承認履歴等が誤って編集してしまうことを防止して申請内容等を確認することができる。
【００２６】
図２は、申請サーバ１０の構成を示す。申請サーバ１０は、書類登録部７２、申請登録・照会部７４、承認登録部７６、事務処理登録部７８、申請保管部８０、監査証跡管理部８２、ＩＦ部８４を含む。ＩＦ部８４は、図示しないネットワーク２４に接続され、通信機能を実行する。ＩＦ部８４は、ネットワーク２４を介して、図示しない端末装置１２、顧客情報記憶部１８、申請情報記憶部２０、承認情報記憶部２２と通信し、顧客情報記憶部１８と顧客情報生成部７０を介して資産情報記憶部１４および顧客属性記憶部１６にアクセスする。
【００２７】
図１の顧客情報生成部７０は、申請者が端末装置１２を操作して書類を作成する前に、書類の作成に必要な顧客データを収集し、顧客ごとの顧客属性情報と顧客資産情報とを作成する。詳細は後述するが、顧客情報生成部７０は、資産情報記憶部１４および顧客属性記憶部１６に記憶されたデータをもとに、顧客の資産情報と顧客の属性情報とを取得し、加工して顧客情報記憶部１８に記憶する。前述のごとく、資産情報記憶部１４および顧客属性記憶部１６に記憶されたデータは変動するので、顧客情報生成部７０は、これらのデータの変動に合わせて、データを更新する。なお、顧客情報生成部７０は、申請サーバ１０の内部に設けられ、ネットワーク２４を介して資産情報記憶部１４と顧客属性記憶部１６とが申請サーバ１０に接続され、申請サーバ１０が資産情報記憶部１４と顧客属性記憶部１６から必要な情報を取得してもよい。
【００２８】
書類登録部７２は、書類フォーマットの作成者が端末装置１２を操作して作成した書類のフォーマットを更新書類管理ＤＢに登録する。具体的には書類登録部７２は、申請情報記憶部２０の申請書類管理ＤＢ５６に申請書類のフォーマット情報を登録する。申請の処理が開始されると、申請登録・照会部７４は、書類登録部７２で作成され申請書類管理ＤＢ５６に登録されている申請書類のフォーマットの中から申請の種類に応じた書類のフォーマットを呼び出すとともに、顧客情報記憶部１８を介して資産情報記憶部１４と顧客属性記憶部１６に記憶されたデータのうち、申請の種類に応じて必要な顧客情報を抽出し、申請画面を生成する。申請者が申請画面から申請を行う旨の指示（申請指示）を入力すると、申請登録・照会部７４はこの指示を受け付けて、顧客情報記憶部１８を介して資産情報記憶部１４と顧客属性記憶部１６から取得し申請画面に表示した顧客情報を申請情報記憶部２０の申請顧客情報ＤＢに固定した状態で記憶させる。また、申請登録・照会部７４は、申請に関する情報を第２ＤＢ４６に記憶させる。
【００２９】
承認登録部７６は、申請登録・照会部７４が申請者からの承認申請指示を受け付けて登録した後、承認者による端末装置１２の操作に応じて、承認者が行う承認処理の結果を受け付けてその内容を登録する。承認結果が受け付けられて登録されると、承認登録部７６は、申請情報記憶部２０の申請顧客情報ＤＢ４８に固定して記憶していたデータを承認情報記憶部２２に更新不可の状態で記憶させる。事務処理登録部７８は、申請登録・照会部７４が申請指示を受け付けて登録した後、申請内容にしたがった事務処理を登録する。事務処理とは、例えば、申請の内容が信用口座の開設であった場合、実際に信用口座を開設するための処理である。このような事務処理は、申請者や承認者とは異なった証券会社の社員によってなされる。事務処理に際しては申請情報記憶部２０の申請顧客情報ＤＢ４８に記憶していたデータが参照される。
【００３０】
申請保管部８０は、承認登録部７６が承認処理の結果を登録した後、端末装置１２からの指示にしたがって、承認した内容を表示させる。その際、申請保管部８０は、承認情報記憶部２２に記憶されたデータを抽出する。監査証跡管理部８２は、承認登録部７６が承認処理の結果を登録した後、端末装置１２からの指示にしたがって、申請から承認までの履歴を表示させる。その際、監査証跡管理部８２は、監査証跡管理ＤＢ５４または監査証跡履歴管理ＤＢ６４に記憶されたデータを抽出する。
【００３１】
以下の各処理に対する説明では、図１に示した申請処理部１００の構成、図２に示した申請サーバ１０の構成のうち、必要な部分だけを図示する。この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００３２】
２．顧客情報生成処理
図３は、顧客情報生成部７０の構成を示す。顧客情報生成部７０は、第１取込部９０、第２取込部９２を含む。また、顧客情報生成部７０は、資産情報記憶部１４、顧客属性記憶部１６、顧客情報記憶部１８に接続される。なお、資産情報記憶部１４、顧客属性記憶部１６、顧客情報記憶部１８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。前述のごとく、顧客情報生成部７０は、申請サーバ１０の内部に設けられてもよいが、その際、申請サーバ１０は資産情報記憶部１４、顧客属性記憶部１６とネットワークを介して接続され、これら記憶部の情報を取り出して顧客情報生成部７０で必要な情報を生成する。
【００３３】
預りＤＢ３０は、顧客の保有している預り情報を記憶する。預りＤＢ３０では、預りごとの記憶がなされている。図４は、預りＤＢ３０のデータ構造を示す。図示のごとく、ユーザ欄３００、部店欄３０２、口座番号欄３０４、商品欄３０６、銘柄欄３０８、数量欄３１０、取得単価欄３１２、時価欄３１４が含まれる。預りＤＢ３０は、各ユーザから預っているっている株式、債券、投信等の銘柄、数量、価格等を記憶する。預りＤＢ３０に格納されたデータは、商品を売買したタイミング、時価が変動したタイミングにおいて更新される。図３に戻る。
【００３４】
資産ＤＢ３２は、顧客の保有している預り資産を記憶する。資産ＤＢ３２では、口座ごとの記憶がなされている。図５は、資産ＤＢ３２のデータ構造を示す。図示のごとく、ユーザ欄３２０、部店欄３２２、口座番号欄３２４、総資産額欄３２６が含まれる。総資産額欄３２６に含まれた総資産額は、預りＤＢ３０に格納されたデータと図示しない株価情報ＤＢとをもとに導出される。そのため、株価情報ＤＢのデータや預りＤＢ３０に格納されたデータが更新されると、資産ＤＢ３２に格納されたデータ、つまり総資産額も更新される。一般に株価情報ＤＢのデータは所定のタイミング（例えば一日一回）で更新されるため、これに伴って資産ＤＢ３２のデータも更新される。また、預りＤＢ３０は株式等の売買が成立した場合などの任意のタイミングで更新され、資産ＤＢ３２は株価情報ＤＢに対する所定の更新タイミングのみならず、任意で発生する預りＤＢの更新に合わせてもデータが更新可能なように構成されている。図３に戻る。
【００３５】
共通属性ＤＢ３４は、個人客、法人客に共通する属性情報を記憶する。共通属性ＤＢ３４では、口座ごとの記憶がなされている。図６は、共通属性ＤＢ３４のデータ構造を示す。図示のごとく、ユーザ欄３３０、部店欄３３２、口座番号欄３３４、顧客名欄３３６、住所欄３３８、電話番号欄３４０、職業欄３４２、リスク説明不要（株式）欄３４４、リスク説明不要（債券）欄３４６、リスク説明不要（転換社債）欄３４８、リスク説明不要（外証）欄３５０、コンプラランク欄３５２、口座開設日欄３５４が含まれる。例えば、住所欄３３８の住所が変更されたタイミングのような任意の不定期なタイミングにおいて、共通属性ＤＢ３４に格納されたデータは更新される。図３に戻る。
【００３６】
個人属性ＤＢ３６は、個人客に関する属性情報を記憶する。個人属性ＤＢ３６でも、口座ごとの記憶がなされている。図７（ａ）−（ｃ）は、個人属性ＤＢ３６のデータ構造を示す。個人属性ＤＢ３６に格納されたデータの項目数が多いので、ここでは図７（ａ）−（ｃ）に分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄３６０、部店欄３６２、口座番号欄３６４、顧客名欄３６６、生年月日欄３６８、性別欄３７０、勤務先欄３７２、役職欄３７４、取引動機欄３７６、資金性格欄３７８、投資方針欄３８０、資産運用期間欄３８２、投資経験有無（株式現物）欄３８４、投資経験有無（債券）欄３８６、投資経験有無（転換社債）欄３８８、投資経験有無（株式信用）欄３９０、投資経験有無（ワラント）欄３９２、投資経験有無（先物・ＯＰ）欄３９４、投資経験有無（貯蓄型投信）欄３９６、投資経験有無（投資信託）欄３９８、投資経験有無（外国証券）欄４００、投資経験有無（その他）欄４０２、主な収入源欄４０４、推定年収欄４０６、金融資産欄４０８が含まれる。個人属性ＤＢ３６に格納されたデータも、共通属性ＤＢ３４に格納されたデータと同様に、任意の不定期なタイミングにおいて更新される。図３に戻る。
【００３７】
法人属性ＤＢ３８は、法人客に関する属性情報を記憶する。法人属性ＤＢ３８でも、口座ごとの記憶がなされている。図８（ａ）−（ｂ）は、法人属性ＤＢ３８のデータ構造を示す。法人属性ＤＢ３８に格納されたデータの項目数が多いので、ここでは図８（ａ）−（ｂ）に分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄４１０、部店欄４１２、口座番号欄４１４、顧客名欄４１６、取引動機欄４１８、資金性格欄４２０、投資方針欄４２２、資産運用期間欄４２４、投資経験有無（株式現物）欄４２６、投資経験有無（債券）欄４２８、投資経験有無（転換社債）欄４３０、投資経験有無（株式信用）欄４３２、投資経験有無（ワラント）欄４３４、投資経験有無（先物・ＯＰ）欄４３６、投資経験有無（貯蓄型投信）欄４３８、投資経験有無（投資信託）欄４４０、投資経験有無（外国証券）欄４４２、投資経験有無（その他）欄４４４、資本金欄４４６、代表者名欄４４８が含まれる。法人属性ＤＢ３８に格納されたデータも、共通属性ＤＢ３４に格納されたデータと同様に、任意の不定期なタイミングにおいて更新される。図３に戻る。
【００３８】
個人の顧客に対するデータと法人の顧客に対するデータとは異なるので、個人属性ＤＢ３６と法人属性ＤＢ３８とが別に設けられる。なお、個人属性ＤＢ３６に格納されたデータと法人属性ＤＢ３８に格納されたデータは、承認申請の際および承認処理（承認／非承認判断）の際に使用される。承認申請および承認処理の判断に際し、個人の顧客と法人の顧客とでは必要な情報が異なるので、個人属性ＤＢ３６と法人属性ＤＢ３８とが別に設けられている。
【００３９】
第１取込部９０は、各顧客に対して、預りＤＢ３０および資産ＤＢ３２に格納されたデータを読み込む。第１取込部９０は、読み込んだデータを既存客情報管理ＤＢ４０に出力する。第２取込部９２は、各顧客に対して、共通属性ＤＢ３４、個人属性ＤＢ３６、法人属性ＤＢ３８に格納されたデータを読み込む。なお、顧客の属性の種類に応じて、個人属性ＤＢ３６あるいは法人属性ＤＢ３８が選択される。第１取込部９０は、読み込んだデータを既存客情報管理ＤＢ４０および顧客カードＤＢ４２に出力する。
【００４０】
既存客情報管理ＤＢ４０は、各顧客に対して、第１取込部９０および第２取込部９２からのデータを取り込み、顧客属性情報の一部と顧客資産情報とを記憶する。具体的には、顧客の属性情報の種類が個人である場合、口座開設日、住所、職業、生年月日、性別、電話番号、勤務先、役職、預り資産、コンプラランク、リスク説明不要な商品の情報が含まれる。一方、顧客の属性情報の種類が法人である場合、口座開設日、住所、役職・代表者名、電話番号、業種、資本金、預り資産、コンプラランク、リスク説明不要な商品の情報が含まれる。つまり、顧客情報記憶部１８のうちの既存客情報管理ＤＢ４０では、顧客の属性情報の種類として、複数の種類、具体的には個人と法人が規定されている。
【００４１】
顧客カードＤＢ４２は、各顧客に対して、第２取込部９２からのデータを記憶し顧客属性情報を記憶する。具体的には、投資経験に関する情報、取引種類、資金性格、投資方針、資産運用期間、主な収入源、金融資産、年収が含まれる。顧客カードＤＢ４２に格納されるデータの項目は、顧客の属性情報の種類にかかわらず同一である。既存客情報管理ＤＢ４０および顧客カードＤＢ４２に格納されたデータは、資産情報記憶部１４および顧客属性記憶部１６に格納されたデータの更新に応じて、更新される。そのため、顧客情報記憶部１８に格納されたデータは、所定のまたは任意のタイミングにて更新できるよう構成されている。
【００４２】
３．書類登録処理
図９は、書類登録部７２の構成を示す。書類登録部７２は、書類生成部９４を含む。また、書類登録部７２は、申請情報記憶部２０、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、申請情報記憶部２０、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００４３】
受付部９６は、承認申請の申請者からの入力を受けつける。入力は、キーボードやマウス等の入力機器を介してなされる。ここでの入力は、申請書類のフォーマットを作成するためのデータの入力に相当する。受付部９６は、入力されたデータを書類生成部９４へ出力する。書類生成部９４は、受付部９６からのデータを受けつける。書類生成部９４は、受けつけたデータをもとに、承認申請に用いられる書類（以下、「申請書類」という）のフォーマットを生成する。書類生成部９４は、作成中の申請書類のフォーマットを表示部９８に表示させる。フォーマットが定められた申請書類は、申請書類管理ＤＢに記憶される。
【００４４】
表示部９８は、書類生成部９４からの指示に応じて申請書類のフォーマットを表示する。図１０は、書類生成部９４によって生成される申請書類のフォーマットの登録画面を示す。画面中、書類コード欄６００には、申請書類を識別するために付与される書類コードが表示される。書類分類欄６０２には、申請書類の分類が表示される。書類名欄６０４には、申請書類の名称が表示される。申請書類を新規登録する場合、書類コード欄６００、書類分類欄６０２、書類名欄６０４は、新たに入力される。これらの下段には、申請書類に含まれる項目が示される。書類フォーマットの登録者は、項目内容を編集できる。そのため、右側の内容の部分に表示されるチェックボックス等は任意に設定可能である。
【００４５】
図１１は、書類生成部９４によって生成され承認者を設定するための申請書類承認者定義画面を示す。申請書類は、一般的に、書類の種類に応じて承認者が異なる。図９に戻る。申請書類管理ＤＢ５６は、書類生成部９４によって作成された申請書類のフォーマット情報を記憶する。申請書類管理ＤＢ５６に記憶される申請書類のフォーマット情報には、各書類について設定され登録された承認者情報も含まれる。
【００４６】
４．申請登録処理
図１２は、申請登録・照会部７４の構成を示す。申請登録・照会部７４は、申請処理部１００、申請状況照会部１０２を含み、申請処理部１００は、申請画面生成部１０４、取得部１０６、移動部１０８を含む。また、申請登録・照会部７４は、顧客情報記憶部１８、申請情報記憶部２０、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、顧客情報記憶部１８、申請情報記憶部２０、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００４７】
申請画面生成部１０４は、受付部９６から受けつけた指示であって、かつ申請者からの指示を受けつける。申請画面生成部１０４は、受付部９６で受けつけた指示をもとに、申請書類を作成するための画面を作成し、申請処理を実行する。図１３は、申請画面生成部１０４によって生成され申請書類管理ＤＢから申請の種類に応じて申請書類のフォーマットを呼び出した状態の書類選択画面を示す。書類コード欄６１０、書類分類欄６１２、書類名欄６１４は、図１０の書類コード欄６００、書類分類欄６０２、書類名欄６０４に対応しており、受付部９６が申請者からのこれらの欄への入力または顧客に紐づけられた口座番号の入力を受け付けることによってこれらの欄への入力で特定される申請書類または口座番号により特定される顧客について必要な申請書類のフォーマットが呼び出される。図１３では口座番号が指定されることでこの口座番号に紐づけられた顧客に関する承認申請に必要な複数の申請書類フォーマットの候補が書類コード欄６１０、書類分類欄６１２、書類名欄６１４の下に複数、表示された状態を示している。このように申請書類のフォーマットが示された状態において申請者は申請に必要な書類を特定して、申請入力ボタン６１６を押し下げることで申請書類の作成を開始する指示を入力する。図１２に戻る。申請画面生成部１０４は、申請書類の作成開始指示を受けつけると、申請書類管理ＤＢ５６から特定された申請書類のフォーマットを取得する。また、申請画面生成部１０４は、申請書類の作成開始指示を受けつけると、その旨を取得部１０６に通知する。その際、口座番号欄に入力され口座番号と一意に紐づけられた顧客を特定する情報（例えば顧客コード）も取得部１０６に通知される。
【００４８】
取得部１０６は、申請画面生成部１０４からの申請書類作成開始指示を受けつけると、顧客情報記憶部１８に含まれた既存客情報管理ＤＢ４０と顧客カードＤＢ４２とから、該当する顧客の属性情報および資産情報等を取得する。これらを取得するために、取得部１０６は、顧客コード等による検索を実行する。ここで、顧客情報記憶部１８の顧客情報は、顧客コードに紐づけられ記憶されている。よって、ひとつの顧客コードから、個人の属性情報あるいは法人の属性情報が取得されるので、申請画面生成部１０４から受けつけた顧客コードは、顧客の種類を特定するための情報ともいえる。
【００４９】
前述のごとく、取得部１０６によってアクセスされる顧客情報記憶部１８では、既存客情報管理ＤＢ４０の内容と顧客カードＤＢ４２の内容とが、所定のまたは任意のタイミングにて更新されている。取得部１０６は、顧客情報記憶部１８にアクセスした時点、すなわち、受付部９６が申請者からの申請書類作成指示の入力を受け付けた時点とほぼ同じ時点に顧客情報記憶部１８に保持されている顧客の属性情報と資産情報とを取得し、取得した顧客の資産情報と顧客の属性情報等を申請画面生成部１０４へ出力する。
【００５０】
申請画面生成部１０４は、既に取得した申請書類のフォーマット情報に加えて、取得部１０６において取得した顧客の資産情報と顧客の属性情報等をもとに、顧客に対する証券業務に関する承認申請を行うための申請内容編集画面を生成する。申請画面生成部１０４は、作成した画面を表示部９８に表示させる。表示部９８は、申請画面生成部１０４からの指示に応じて画面を表示する。図１４は、申請画面生成部１０４によって生成された申請内容編集画面を示す。特に、図１４は、顧客が個人である場合の申請内容編集画面である。図中の第１顧客属性表示欄６２０において既存客情報管理ＤＢから取得した顧客の属性情報が表示され、第２顧客属性表示欄６２２において顧客カードＤＢ４２から取得した顧客の属性情報が表示され、図中の預り資産欄６２４において、顧客カードＤＢ４２から取得した顧客の資産情報が表示される。これらの顧客情報表示欄６２０、６２２、６２４の下段には、申請内容が表示される。
【００５１】
図１５は、申請内容を照会するために申請画面生成部１０４によって生成される申請内容照会画面を示す。申請内容照会画面は、図１４の申請書類作成画面において仮保存ボタンが押し下げられたことを受付部９６が受け付けることで生成され、図１４の顧客情報表示欄の下段に表示された申請内容を表示する画面である。図１６は、申請画面生成部１０４によって生成される別の申請内容編集画面を示す。特に、図１６は、顧客が法人である場合の申請内容編集画面である。図中の第１顧客属性表示欄６３０において既存客情報管理ＤＢ４０から取得した顧客の属性情報が表示され、第２顧客属性表示欄６３２において顧客カードＤＢ４２から取得した顧客の属性情報が表示され、図中の預り資産欄６３４において、顧客カードＤＢ４２から取得した顧客の資産情報が表示される。第１顧客属性表示欄６３０に含まれる項目は、図１４の第１顧客属性表示欄６２０に含まれる項目と異なっている。これは、顧客の種類が異なるためである。一方、第２顧客属性表示欄６３２、預り資産欄６３４に含まれる項目は、図１４の第２顧客属性表示欄６２２、預り資産欄６２４に含まれる項目と同一である。
【００５２】
図１７は、申請画面生成部１０４によって生成される別の申請内容照会画面を示す。これは、必要な項目の入力が完了し、申請可能な状態である場合に相当する。そのため、申請ボタン６４０が表示されている。図１２に戻る。表示部９８に申請内容照会画面を表示させた状態において、申請者が申請ボタン６４０を押し下げることで承認申請の開始を行う指示を入力することにより、申請画面生成部１０４は、受付部９６から証券業務の申請開始指示を受けつける。申請画面生成部１０４は、証券業務の申請開始指示を受けつけると、申請に係るデータを申請情報記憶部２０に記憶させるよう、移動部１０８に指示する。
【００５３】
移動部１０８は、申請画面生成部１０４からの指示を受けつけると、申請画面を生成するために使用したデータを申請情報記憶部２０に記憶させる。つまり、申請書類の作成が完了し申請開始が指示された申請に係るデータは、申請情報記憶部２０に記憶される。特に、移動部１０８は、既存客情報管理ＤＢ４０と顧客カードＤＢ４２から取得された顧客の資産情報と顧客の属性情報等とを申請顧客情報ＤＢ４８へ削除以外の編集が不可能な状態（すなわち固定した状態）で記憶させる。また、移動部１０８は、申請開始指示を行ってから承認が完了するまでの間、追加や修正等の編集が行われるデータを申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶させる。申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶させるデータの内容は後述する。
【００５４】
前述のごとく、申請顧客情報ＤＢ４８に記憶されたデータは、申請から承認までの間において、削除される場合を除いて、追加や変更等の編集ができないように固定されている。そのため、既存客情報管理ＤＢ４０と顧客カードＤＢ４２に記憶され種々のタイミングや頻度で更新され変動しうるデータは、申請開始の指示が完了されたタイミングにおいて、申請顧客情報ＤＢ４８に記憶されることによって固定される。一方、申請開始指示により申請顧客情報ＤＢ４８に固定されたデータの元データであって既存客情報管理ＤＢ４０と顧客カードＤＢ４２に記憶されていたデータは、申請顧客情報ＤＢ４８への記憶が行われた後も変動され続けうる。一方、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶されたデータは、申請から承認までの間において、編集可能である。
【００５５】
申請顧客情報ＤＢ４８は、申請書類の作成が完了し申請開始の指示が完了したタイミングで顧客情報を記憶する。申請顧客情報ＤＢ４８では、ひとつの申請につき、１行の情報が登録される。図１８（ａ）−（ｆ）は、申請顧客情報ＤＢ４８のデータ構造を示す。申請顧客情報ＤＢ４８に格納されたデータの項目数が多いので、ここでは図１８（ａ）−（ｆ）に分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄４５０、申請番号欄４５２、部店欄４５４、口座番号欄４５６、顧客名欄４５８、郵便番号欄４６０、住所欄４６２、職業欄４６４、生年月日欄４６６、電話番号欄４６８、口座開設日欄４７０、性別欄４７２、資産欄４７４、コンプラランク欄４７６、役職欄４７８、勤務先欄４８０、代表者名欄４８２、資本金欄４８４、リスク説明不要（株式）欄４８６、リスク説明不要（債券）欄４８８、リスク説明不要（転換社債）欄４９０、リスク説明不要（外証）欄４９２、取引動機欄４９４、投資経験有無（株式現物）欄４９６、投資経験有無（債券）欄４９８、投資経験有無（転換社債）欄５００、投資経験有無（株式信用）欄５０２、投資経験有無（ワラント）欄５０４、投資経験有無（先物・ＯＰ）欄５０６、投資経験有無（貯蓄型投信）欄５０８、投資経験有無（投資信託）欄５１０、投資経験有無（外国証券）欄５１２、投資経験有無（その他）欄５１４、資金性格欄５１６、投資方針欄５１８、主な収入源欄５２０、推定年収欄５２２、金融資産欄５２４、資産運用期間欄５２６が含まれる。申請は、申請番号欄４５２に示された申請番号によって各申請が一意に識別される。他の項目は、既存客情報管理ＤＢ４０および顧客カードＤＢ４２に格納されたデータの項目に類似する。
【００５６】
申請管理ＤＢ５０は、申請開始の指示が完了した申請書類に係るデータを記憶する。申請管理ＤＢ５０は、ふたつの部分によって構成される。ひとつが申請管理であり、もうひとつが申請内容管理である。申請管理は、申請書類の基本的な情報（すなわち属性情報）を記憶する。申請管理では、ひとつの申請につき、１行の情報が登録される。図１９は、申請管理ＤＢ５０のデータ構造を示す。図示のごとく、ユーザ欄５３０、申請番号欄５３２、書類コード欄５３４、部店欄５３６、口座番号欄５３８、顧客名欄５４０、申請者名欄５４２、申請状況欄５４４、申請日時欄５４６、申請完了日欄５４８が含まれる。
【００５７】
一方、申請内容管理は、申請ごとに申請内容を記憶する。つまり、申請内容管理に記憶された内容が、申請書類の実質的な内容に相当し、申請管理は、申請内容管理を識別するためのインデックスに相当する。そのため、申請内容では、ひとつの申請につき、申請書類の項目数に応じた１以上の行の情報が登録される。図２０は、申請管理ＤＢ５０の別のデータ構造を示す。図示のごとく、ユーザ欄５５０、申請番号欄５５２、申請内容の項目番号欄５５４、内容欄５５６が含まれる。申請管理ＤＢのデータは、申請内容等に変更が生じた場合等のタイミングで更新される。
【００５８】
申請状況管理ＤＢ５２は、申請ごとに定義された申請者および承認者の登録状況を記憶する。申請状況管理ＤＢ５２では、ひとつの申請につき、複数行の情報が登録される。複数行は、書類に対する承認者の数と申請者の数との和に相当する。申請状況ＤＢのデータは承認処理が行われたタイミングなどで更新される。図２１は、申請状況管理ＤＢ５２のデータ構造を示す。図示のごとく、ユーザ欄５６０、申請番号欄５６２、役職欄５６４、登録状況欄５６６、登録日時欄５６８、登録者氏名欄５７０が含まれる。登録状況欄５６６において、現在のステータスが示される。
【００５９】
監査証跡管理ＤＢ５４は、申請書類に対する更新の履歴を記憶する。監査証跡管理ＤＢ５４では、ひとつの申請につき、更新した数だけの情報が記憶される。監査証跡管理ＤＢ５４も更新が行われたタイミングで更新される。図２２は、監査証跡管理ＤＢ５４のデータ構造を示す。図示のごとく、ユーザ欄５８０、申請番号欄５８２、更新時間欄５８４、更新者欄５８６、更新内容欄５８８、役職欄５９０が含まれる。更新時間欄５８４では、更新時間が示される。図１２に戻る。
【００６０】
申請状況照会部１０２は、申請開始の指示が完了した後、受付部９６から受けつけた指示であって、照会者からの照会指示を受けつける。当該指示は、申請状況の照会要求である。申請状況照会部１０２は、照会指示を受けつけると、申請状況管理ＤＢ５２に記憶されたデータを取得する。なお、申請状況照会部１０２は、申請管理ＤＢ５０、監査証跡管理ＤＢ５４に記憶されたデータを取得しない。つまり、申請情報記憶部２０は、参照のタイミングに応じて、複数の部分に分割して構成されている。複数の部分は、申請顧客情報ＤＢ４８、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に相当する。このうち、申請顧客情報ＤＢには固定された状態でデータが記憶され削除以外の編集ができない一方、その他のＤＢについてはデータが編集可能に構成されている。申請状況照会部１０２は、取得したデータをもとに申請状況一覧画面を生成し、生成した画面を表示部９８に表示する。図２３は、申請状況照会部１０２によって生成される申請状況一覧画面を示す。図示のごとく、申請状況と承認状況が申請ごとに表示される。複数の承認者が設定されている場合、複数の承認者のそれぞれにおける承認状況が示される。
【００６１】
５．承認登録処理
図２４は、承認登録部７６の構成を示す。承認登録部７６は、承認画面生成部１１０、移動部１１２を含む。また、承認登録部７６は、申請情報記憶部２０、承認情報記憶部２２、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、申請情報記憶部２０、承認情報記憶部２２、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００６２】
承認画面生成部１１０は、受付部９６から受けつけた指示であって、かつ承認者からの承認申請表示指示を受けつける。当該指示は、承認申請を表示させる要求であり、この例では承認状況情報を伴って承認申請案件が表示されるため、承認申請表示要求は、前述の申請状況の照会要求と類似している。申請状況の照会要求では、申請状況と承認状況が申請ごとに表示部９８に表示されるのに対して、承認申請表示要求では、承認状況が申請ごとに表示部９８に表示される。承認画面生成部１１０は、承認申請表示指示を受けつけると、申請状況管理ＤＢ５２に記憶されたデータを取得する。承認画面生成部１１０は、取得したデータをもとに承認申請表示画面を生成し、生成した画面を表示部９８に表示する。図２５は、承認画面生成部１１０によって生成される承認申請表示画面を示す。図示のごとく、承認状況が申請ごとに表示される。承認状況が「承認待ち」であることは、承認あるいは非承認すべき状況に相当する。一方、承認状況が「未承認」であることは、他の承認者が承認あるいは非承認すべき状況に相当する。さらに、承認状況が「承認済」であることは、既に承認した状況に相当する。なお、承認状況が「非承認」であることは、いずれかの承認者によって非承認された状況に相当する。図２４に戻る。
【００６３】
表示部９８に承認申請表示画面を表示させた状態において、承認者が申請番号を特定して押し下げると、承認画面生成部１１０は、受付部９６から、特定された申請番号に対応した申請書類の表示指示を受けつける。承認画面生成部１１０は、受けつけた指示に応じて、該当する顧客の顧客情報を申請顧客情報ＤＢ４８から取得し、申請についての属性情報と申請内容の情報とを申請管理ＤＢ５０から取得する。承認画面生成部１１０は、取得したデータをもとに、承認内容照会画面を作成し、作成した承認内容照会画面を表示部９８に表示させる。
【００６４】
図２６は、承認画面生成部１１０によって生成される承認内容照会画面を示す。図示のごとく、申請書類と同様の内容が表示される。承認者は、承認内容照会画面の内容を確認し、承認する場合、承認ボタン６５０をマウスでクリックする。一方、承認者は非承認する場合、非承認ボタン６５２をマウスでクリックする。なお、承認者記入ボタンがクリックされると、承認画面生成部１１０は、承認者記入欄編集画面を表示部９８に表示させる。図２７は、承認画面生成部１１０によって生成される承認者記入欄編集画面を示す。内容の部分に示された項目は、顧客の属性に応じて規定される。図２４に戻る。
【００６５】
承認者による承認・非承認の指示が入力されると、承認画面生成部１１０は、受付部９６から、承認者による承認処理完了の指示を受けつける。これは、申請開始指示に対する承認処理の完了指示である。承認画面生成部１１０は、承認処理完了の指示を受けつけると、承認対象のデータを移動部１１２に更新不能な状態で記憶するように指示する。なお、複数の承認者が設定されている場合、承認画面生成部１１０は、最後の承認者が承認処理の完了を指示したときに移動部１１２にデータの記録を指示する。承認者が残っている場合、承認画面生成部１１０は、申請状況管理ＤＢ５２および監査証跡管理ＤＢ５４のデータを更新する。
【００６６】
移動部１１２は、承認画面生成部１１０からの指示を受けつけると、申請顧客情報ＤＢ４８に記憶されたデータを申請顧客履歴情報ＤＢ５８に更新不能な状態で記憶させる。ここでのデータは、前述のごとく、顧客の資産情報と顧客の属性情報等に相当する。また、移動部１１２は、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶されたデータを申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４にそれぞれ更新不能な状態で記憶させる。これらのデータは、申請顧客情報ＤＢ４８に記憶されたデータに付随した申請情報ともいえ、申請開始の指示から承認完了の指示までの間において内容が更新可能とされていたデータを元データとする。
【００６７】
一方、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４に記憶された申請情報は、更新不可能である。申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４は、承認情報記憶部２２に格納されているので、承認情報記憶部２２は、承認後のデータを記憶する。なお、申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４でのデータ構造は、申請顧客情報ＤＢ４８、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４でのデータ構造とそれぞれ同様であるので、ここでは説明を省略する。
【００６８】
６．事務処理登録処理
図２８は、事務処理登録部７８の構成を示す。事務処理登録部７８は、申請情報記憶部２０、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、申請情報記憶部２０、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００６９】
事務処理登録部７８は、受付部９６から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、事務処理状況の照会要求である。事務処理登録部７８は、指示を受けつけると、申請管理ＤＢ５０、申請状況管理ＤＢ５２、監査証跡管理ＤＢ５４に記憶されたデータを取得する。
【００７０】
事務処理登録部７８は、取得したデータをもとに事務処理状況一覧画面を生成し、生成した画面を表示部９８に表示する。図２９は、事務処理登録部７８によって生成される事務処理状況一覧画面を示す。図示のごとく、処理状況が申請ごとに表示される。処理状況が「処理待ち」であることは、事務処理を実行すべき状況に相当する。一方、処理状況が「未処理」であることは、他の社員が事務処理を実行すべき状況に相当する。さらに、処理状況が「処理済」であることは、既に処理した状況に相当する。
【００７１】
７．申請保管処理
図３０は、申請保管部８０の構成を示す。申請保管部８０は、承認情報記憶部２２、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、承認情報記憶部２２、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００７２】
申請保管部８０は、受付部９６から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、承認が完了した申請書類の照会要求である。申請保管部８０は、指示を受けつけると、申請状況履歴管理ＤＢ６２に記憶されたデータを取得する。申請保管部８０は、取得したデータをもとに保管している申請を表示する画面を生成し、生成した画面を表示部９８に出力する。図３１は、申請保管部８０によって生成される保管申請表示画面を示す。図示のごとく、承認状況が確認される。なお、申請番号が選択されると、申請保管部８０は、申請顧客履歴情報ＤＢ５８、申請履歴管理ＤＢ６０に記憶されたデータを取得し、承認された申請書類を表示部９８に表示してもよい。
【００７３】
８．監査証跡管理処理
図３２は、監査証跡管理部８２の構成を示す。監査証跡管理部８２は、申請情報記憶部２０、承認情報記憶部２２、受付部９６、表示部９８に接続される。受付部９６、表示部９８は、図１の端末装置１２に含まれている。なお、申請情報記憶部２０、承認情報記憶部２２、受付部９６、表示部９８に接続されるためには、図１のネットワーク２４や図２のＩＦ部８４を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
【００７４】
監査証跡管理部８２は、受付部９６から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、申請書類に対する監査証跡の照会要求である。ここで、照会対象の申請書類に対して、承認が完了している場合があれば、承認が完了していない場合もある。監査証跡管理部８２は、指示とともに申請番号も受けつけており、監査証跡管理ＤＢ５４および監査証跡履歴管理ＤＢ６４を参照することによって、申請番号に対応したデータが格納されている方を特定する。申請番号に対応したデータが監査証跡管理ＤＢ５４に含まれていることは、承認が完了していない申請書類に対する監査証跡を照会することに相当する。
【００７５】
一方、申請番号に対応したデータが監査証跡履歴管理ＤＢ６４に含まれていることは、承認が完了した申請書類に対する監査証跡を照会することに相当する。監査証跡管理部８２は、申請番号に対応したデータが監査証跡管理ＤＢ５４に含まれている場合、監査証跡管理ＤＢ５４に記憶されたデータを取得する。一方、監査証跡管理部８２は、申請番号に対応したデータが監査証跡履歴管理ＤＢ６４に含まれている場合、監査証跡履歴管理ＤＢ６４に記憶されたデータを取得する。監査証跡管理部８２は、取得したデータをもとに申請更新履歴照会画面を生成し、生成した画面を表示部９８に出力する。
【００７６】
ここで、申請情報記憶部２０に記憶された第２ＤＢ４６のうち、監査証跡管理ＤＢ５４だけが使用され、申請管理ＤＢ５０、申請状況管理ＤＢ５２は使用されていない。また、承認情報記憶部２２に記憶された申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４のうち、監査証跡履歴管理ＤＢ６４だけが使用され、残りは使用されていない。つまり、監査証跡管理部８２によって使用される部分は、申請情報記憶部２０および承認情報記憶部２２のうち、対応した部分である。そのため、承認情報記憶部２２は、申請履歴管理ＤＢ６０、申請状況履歴管理ＤＢ６２、監査証跡履歴管理ＤＢ６４のように、複数の部分に分割して構成されている。このような分割は、第２ＤＢ４６での構成に合わせられている。図３３は、監査証跡管理部８２によって生成される申請更新履歴照会画面を示す。図示のごとく、誰がいつ、何を実施したかが確認可能なような表示がなされる。
【００７７】
９．動作
以上の構成による証券業務システム２００の動作を説明する。図３４は、証券業務システム２００による申請処理の手順を示すシーケンス図である。第１端末装置１２ａは、申請者からの開始指示を申請サーバ１０へ送信する（Ｓ１０）。申請サーバ１０は、顧客情報記憶部１８からデータを取得する（Ｓ１２）。申請サーバ１０は、申請画面を生成する（Ｓ１４）。申請サーバ１０は、生成した申請画面の表示指示を第１端末装置１２ａへ送信する（Ｓ１６）。第１端末装置１２ａは、申請画面を表示する（Ｓ１８）。第１端末装置１２ａは、申請者からの申請開始の指示を申請サーバ１０へ出力する（Ｓ２０）。申請サーバ１０は、申請画面を生成するために取得し、および入力されたデータを申請情報記憶部２０に送信する（Ｓ２２）。申請情報記憶部２０は、データを記憶する（Ｓ２４）。
【００７８】
図３５は、証券業務システム２００による承認処理の手順を示すシーケンス図である。申請サーバ１０は、申請情報記憶部２０からデータを取得する（Ｓ３０）。申請サーバ１０は、承認画面を生成する（Ｓ３２）。申請サーバ１０は、生成した承認画面の表示指示を第２端末装置１２ｂへ送信する（Ｓ３４）。第２端末装置１２ｂは、承認画面を表示する（Ｓ３６）。第２端末装置１２ｂは、承認者からの承認指示を申請サーバ１０へ出力する（Ｓ３８）。申請サーバ１０は、データの移動指示を申請情報記憶部２０へ送信し（Ｓ４０）、申請情報記憶部２０は、データを承認情報記憶部２２に送信する（Ｓ４２）。承認情報記憶部２２は、データを記憶する（Ｓ４４）。
【００７９】
本発明の実施例によれば、顧客が個人であるか法人であるかに応じてコンプライアンスチェックやその他の承認に必要な属性情報が異なっていても、顧客が個人であるか法人であるかに応じて属性情報を別々に記憶するので、属性情報を効率的に記憶できる。また、顧客が個人であるか法人であるかに応じて属性情報を別々に取得して表示するので、承認判断に必要な情報を顧客の種類に応じて的確に参照できる。また、変動する資産情報や属性情報等を予め顧客情報記憶部に記憶しておくので、申請に際して必要な顧客情報を迅速に取得できる。また、申請の指示を受けつけた場合に、顧客情報記憶部に記憶された更新可能な情報を、固定の情報として申請情報記憶部に記憶させるので、申請を承認する際に必要な情報が変動することを防止できる。また、固定すべき情報を誤って更新してしまう危険性を低減できる。
【００８０】
また、情報の性質に応じて、記憶部の構成を分けるので、処理を効率的に実行できる。また、開始指示に対する顧客の種類と、属性情報の種類とが対応しているので、受けつけた顧客の種類に合った属性情報を取得できる。また、受けつけた顧客の種類に合った属性情報が取得されるので、承認判断に必要な属性情報を正確に取得できる。また、承認判断に必要な属性情報が正確に取得されるので、承認の正確な処理を実現できる。
【００８１】
また、承認指示を受けつけた場合に、申請情報記憶部に記憶された更新可能な情報を、更新不可能の情報として承認情報記憶部に記憶させるので、更新不可能な情報を誤って更新してしまう危険性を低減できる。また、更新不可能な情報を誤って更新してしまう危険性が低減されるので、性質の異なった情報を確実に処理できる。また、第２ＤＢは、参照のタイミングに応じて、複数の部分に分割して構成されているので、必要な情報のみにアクセスできる。また、必要な情報のみにアクセスされるので、処理を効率を向上できる。
【００８２】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【符号の説明】
【００８３】
１０ 申請サーバ、 １２ 端末装置、 １４ 資産情報記憶部、 １６ 顧客属性記憶部、 １８ 顧客情報記憶部、 ２０ 申請情報記憶部、 ２２ 承認情報記憶部、 ２４ ネットワーク、 ３０ 預りＤＢ、 ３２ 資産ＤＢ、 ３４ 共通属性ＤＢ、 ３６ 個人属性ＤＢ、 ３８ 法人属性ＤＢ、 ４０ 既存客情報管理ＤＢ、 ４２ 顧客カードＤＢ、 ４４ 第１ＤＢ、 ４６ 第２ＤＢ、 ４８ 申請顧客情報ＤＢ、 ５０ 申請管理ＤＢ、 ５２ 申請状況管理ＤＢ、 ５４ 監査証跡管理ＤＢ、 ５６ 申請書類管理ＤＢ、 ５８ 申請顧客履歴情報ＤＢ、 ６０ 申請履歴管理ＤＢ、 ６２ 申請状況履歴管理ＤＢ、 ６４ 監査証跡履歴管理ＤＢ、 ７２ 書類登録部、 ７４ 申請登録・照会部、 ７６ 承認登録部、 ７８ 事務処理登録部、 ８０ 申請保管部、 ８２ 監査証跡管理部、 ８４ ＩＦ部、 ９０ 第１取込部、 ９２ 第２取込部、 ９４ 書類生成部、 ９６ 受付部、 ９８ 表示部、 １００ 申請処理部、 １０２ 申請状況照会部、 １０４ 申請画面生成部、 １０６ 取得部、 １０８ 移動部、 １１０ 承認画面生成部、 １１２ 移動部、 ２００ 証券業務システム。
【特許請求の範囲】
【請求項１】
申請者から、証券業務に関する承認申請の開始指示を受けつける第１受付部と、
前記第１受付部が開始指示を受けつけると、顧客の資産情報と顧客の属性情報とを本申請装置とは独立して任意のタイミングで更新して記憶する第１記憶部から、顧客の資産情報と顧客の属性情報とを取得する取得部と、
前記取得部において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成する生成部と、
前記生成部において生成した申請画面を表示させる表示部と、
前記表示部が申請画面を表示させた状態において、申請者から、証券業務の承認申請を行う旨の申請指示を受けつける第２受付部と、
前記第２受付部が申請指示を受けつけると、前記生成部が申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを固定して第２記憶部に記憶させる移動部と、
前記第２受付部において受けつけた申請指示に対して、承認者からの承認指示を受けつける第３受付部とを備え、
前記第２記憶部は、前記第２受付部において申請指示を受けつけることで顧客の資産情報と顧客の属性情報との書き込みを実行し、
前記移動部は、前記第３受付部が承認指示を受けつけると、第２記憶部に記憶された顧客の資産情報と顧客の属性情報を更新不可能な状態で、前記第２記憶部とは別に設けられた第３記憶部に記憶させることを特徴とする申請装置。
【請求項２】
前記第２記憶部は、内容が固定されて記憶される情報を記憶する第１ＤＢと、内容の編集が可能な情報を記憶する第２ＤＢとを備え、
前記移動部は、前記第２受付部が申請指示を受けつけると、前記生成部が申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを前記第１ＤＢに固定して記憶させ、前記第３受付部が承認指示を受けつけると、第１ＤＢに記憶された顧客の資産情報と顧客の属性情報とを更新不可能な状態で第３記憶部に記憶させるとともに、申請指示を受け付けた時点から承認指示を受け付けた時点までの間に生成され前記第２ＤＢに記憶された申請情報も更新不可能な状態で第３記憶部に記憶させることを特徴とする請求項１に記載の申請装置。
【請求項３】
前記移動部によってアクセスされる第２記憶部に記憶された申請情報は、複数の部分に分割して構成されており、
前記移動部によってアクセスされる第３記憶部に記憶された申請情報は、第２記憶部に記憶された申請情報に合わせて、複数の部分に分割して構成されていることを特徴とする請求項２に記載の申請装置。
【請求項４】
申請者から、証券業務に関する申請の開始指示を受けつけるステップと、
開始指示を受けつけると、顧客の資産情報と顧客の属性情報とを申請装置とは独立して任意のタイミングで更新して記憶する第１記憶部から、顧客の資産情報と顧客の属性情報とを取得するステップと、
取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する申請画面を生成するステップと、
生成した申請画面を表示させるステップと、
申請画面を表示させた状態において、申請者から、証券業務の承認申請を行う旨の申請指示を受けつけるステップと、
申請指示を受けつけると、申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを固定して第２記憶部に記憶させるステップと、
受けつけた申請指示に対して、承認者からの承認指示を受けつけるステップと、
承認指示を受けつけると、第２記憶部に記憶された顧客の資産情報と顧客の属性情報を更新不可能な状態で、前記第２記憶部とは別に設けられた第３記憶部に記憶させるステップとを備え、
前記第２記憶部に記憶させるステップにおける第２記憶部は、申請指示を受けつけることで顧客の資産情報と顧客の属性情報との書き込みを実行することを特徴とする申請方法。
【請求項５】
申請者から、証券業務に関する申請の開始指示を受けつけるステップと、
開始指示を受けつけると、顧客の資産情報と顧客の属性情報とを申請装置とは独立して任意のタイミングで更新して記憶する第１記憶部から、顧客の資産情報と顧客の属性情報とを取得するステップと、
取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する申請画面を生成するステップと、
生成した申請画面を表示させるステップと、
申請画面を表示させた状態において、申請者から、証券業務の承認申請を行う旨の申請指示を受けつけるステップと、
申請指示を受けつけると、申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを固定して第２記憶部に記憶させるステップと、
受けつけた申請指示に対して、承認者からの承認指示を受けつけるステップと、
承認指示を受けつけると、第２記憶部に記憶された顧客の資産情報と顧客の属性情報を更新不可能な状態で、前記第２記憶部とは別に設けられた第３記憶部に記憶させるステップとを備え、
前記第２記憶部に記憶させるステップにおける第２記憶部は、申請指示を受けつけることで顧客の資産情報と顧客の属性情報との書き込みを実行することをコンピュータに実行させるためのコンピュータプログラム。
【請求項１】
申請者から、証券業務に関する承認申請の開始指示を受けつける第１受付部と、
前記第１受付部が開始指示を受けつけると、顧客の資産情報と顧客の属性情報とを本申請装置とは独立して任意のタイミングで更新して記憶する第１記憶部から、顧客の資産情報と顧客の属性情報とを取得する取得部と、
前記取得部において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成する生成部と、
前記生成部において生成した申請画面を表示させる表示部と、
前記表示部が申請画面を表示させた状態において、申請者から、証券業務の承認申請を行う旨の申請指示を受けつける第２受付部と、
前記第２受付部が申請指示を受けつけると、前記生成部が申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを固定して第２記憶部に記憶させる移動部と、
前記第２受付部において受けつけた申請指示に対して、承認者からの承認指示を受けつける第３受付部とを備え、
前記第２記憶部は、前記第２受付部において申請指示を受けつけることで顧客の資産情報と顧客の属性情報との書き込みを実行し、
前記移動部は、前記第３受付部が承認指示を受けつけると、第２記憶部に記憶された顧客の資産情報と顧客の属性情報を更新不可能な状態で、前記第２記憶部とは別に設けられた第３記憶部に記憶させることを特徴とする申請装置。
【請求項２】
前記第２記憶部は、内容が固定されて記憶される情報を記憶する第１ＤＢと、内容の編集が可能な情報を記憶する第２ＤＢとを備え、
前記移動部は、前記第２受付部が申請指示を受けつけると、前記生成部が申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを前記第１ＤＢに固定して記憶させ、前記第３受付部が承認指示を受けつけると、第１ＤＢに記憶された顧客の資産情報と顧客の属性情報とを更新不可能な状態で第３記憶部に記憶させるとともに、申請指示を受け付けた時点から承認指示を受け付けた時点までの間に生成され前記第２ＤＢに記憶された申請情報も更新不可能な状態で第３記憶部に記憶させることを特徴とする請求項１に記載の申請装置。
【請求項３】
前記移動部によってアクセスされる第２記憶部に記憶された申請情報は、複数の部分に分割して構成されており、
前記移動部によってアクセスされる第３記憶部に記憶された申請情報は、第２記憶部に記憶された申請情報に合わせて、複数の部分に分割して構成されていることを特徴とする請求項２に記載の申請装置。
【請求項４】
申請者から、証券業務に関する申請の開始指示を受けつけるステップと、
開始指示を受けつけると、顧客の資産情報と顧客の属性情報とを申請装置とは独立して任意のタイミングで更新して記憶する第１記憶部から、顧客の資産情報と顧客の属性情報とを取得するステップと、
取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する申請画面を生成するステップと、
生成した申請画面を表示させるステップと、
申請画面を表示させた状態において、申請者から、証券業務の承認申請を行う旨の申請指示を受けつけるステップと、
申請指示を受けつけると、申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを固定して第２記憶部に記憶させるステップと、
受けつけた申請指示に対して、承認者からの承認指示を受けつけるステップと、
承認指示を受けつけると、第２記憶部に記憶された顧客の資産情報と顧客の属性情報を更新不可能な状態で、前記第２記憶部とは別に設けられた第３記憶部に記憶させるステップとを備え、
前記第２記憶部に記憶させるステップにおける第２記憶部は、申請指示を受けつけることで顧客の資産情報と顧客の属性情報との書き込みを実行することを特徴とする申請方法。
【請求項５】
申請者から、証券業務に関する申請の開始指示を受けつけるステップと、
開始指示を受けつけると、顧客の資産情報と顧客の属性情報とを申請装置とは独立して任意のタイミングで更新して記憶する第１記憶部から、顧客の資産情報と顧客の属性情報とを取得するステップと、
取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する申請画面を生成するステップと、
生成した申請画面を表示させるステップと、
申請画面を表示させた状態において、申請者から、証券業務の承認申請を行う旨の申請指示を受けつけるステップと、
申請指示を受けつけると、申請画面を生成するために使用した顧客の資産情報と顧客の属性情報とを固定して第２記憶部に記憶させるステップと、
受けつけた申請指示に対して、承認者からの承認指示を受けつけるステップと、
承認指示を受けつけると、第２記憶部に記憶された顧客の資産情報と顧客の属性情報を更新不可能な状態で、前記第２記憶部とは別に設けられた第３記憶部に記憶させるステップとを備え、
前記第２記憶部に記憶させるステップにおける第２記憶部は、申請指示を受けつけることで顧客の資産情報と顧客の属性情報との書き込みを実行することをコンピュータに実行させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【公開番号】特開２０１２−１６０１６４（Ｐ２０１２−１６０１６４Ａ）
【公開日】平成２４年８月２３日（２０１２．８．２３）
【国際特許分類】
【出願番号】特願２０１１−２１６５９４（Ｐ２０１１−２１６５９４）
【出願日】平成２３年９月３０日（２０１１．９．３０）
【分割の表示】特願２０１１−１７６６５６（Ｐ２０１１−１７６６５６）の分割
【原出願日】平成２３年８月１２日（２０１１．８．１２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【公開日】平成２４年８月２３日（２０１２．８．２３）
【国際特許分類】
【出願日】平成２３年９月３０日（２０１１．９．３０）
【分割の表示】特願２０１１−１７６６５６（Ｐ２０１１−１７６６５６）の分割
【原出願日】平成２３年８月１２日（２０１１．８．１２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
[ Back to top ]