ネットワークを介して接続された端末装置から、所定の顧客についての証券業務に関する承認申請の開始指示を受けつける第1受付部と、複数の顧客のそれぞれに対して、顧客の資産情報と顧客の属性情報とを記憶する第1記憶部と、前記第1受付部において受けつけた開始指示に対する顧客の情報を参照して、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報から、当該顧客についての資産情報と属性情報とを取得する取得部と、前記取得部において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成する生成部と、前記生成部において生成した承認申請画面を前記端末装置に表示させるために、ネットワークを介して前記端末装置へ承認申請画面を出力する出力部と、前記出力部から出力した承認申請画面が前記端末装置に表示された状態において、前記端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつける第2受付部と、前記第1記憶部とは別に設けられた第2記憶部と、前記第2受付部が申請指示を受けつけると、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、前記第2受付部において受けつけた顧客の資産情報と顧客の属性情報を前記第2記憶部に記憶させる登録部と、を備えることを特徴とする申請装置。所定のタイミングで更新される顧客の資産情報と顧客の属性情報とを逐次記憶する元情報記憶部と、前記元情報記憶部に記憶した顧客の資産情報と顧客の属性情報であって、かつ所定のタイミングで更新された顧客の資産情報と顧客の属性情報によって、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報を更新する更新制御部とをさらに備え、前記更新制御部による顧客の資産情報と顧客の属性情報との更新方向は、前記元情報記憶部から前記第1記憶部への一方向であることを特徴とする請求項1に記載の申請装置。前記第1受付部において受けつけた開始指示には、顧客が個人であるか法人であるかを識別するための識別情報が含まれ、前記生成部は、前記第1受付部において受けつけた識別情報をもとに、顧客が個人であるか法人であるかを特定し、特定した結果に応じて異なった形式の承認申請画面を生成することを特徴とすることを特徴とする請求項1または2に記載の申請装置。ネットワークを介して接続された端末装置から、所定の顧客についての証券業務に関する承認申請の開始指示を受けつけるステップと、複数の顧客のそれぞれに対して、顧客の資産情報と顧客の属性情報とを記憶する第1記憶部から、受けつけた開始指示に対する顧客の情報を参照して、当該顧客についての資産情報と属性情報とを取得するステップと、取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成するステップと、生成した承認申請画面を前記端末装置に表示させるために、ネットワークを介して前記端末装置へ承認申請画面を出力するステップと、出力した承認申請画面が前記端末装置に表示された状態において、前記端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつけるステップと、申請指示を受けつけると、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、申請指示とともに受けつけた顧客の資産情報と顧客の属性情報を、前記第1記憶部とは別に設けられた第2記憶部に記憶させるステップと、を備えることを特徴とする申請方法。ネットワークを介して接続された端末装置から、所定の顧客についての証券業務に関する承認申請の開始指示を受けつけるステップと、複数の顧客のそれぞれに対して、顧客の資産情報と顧客の属性情報とを記憶する第1記憶部から、受けつけた開始指示に対する顧客の情報を参照して、当該顧客についての資産情報と属性情報とを取得するステップと、取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成するステップと、生成した承認申請画面を前記端末装置に表示させるために、ネットワークを介して前記端末装置へ承認申請画面を出力するステップと、出力した承認申請画面が前記端末装置に表示された状態において、前記端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつけるステップと、申請指示を受けつけると、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、申請指示とともに受けつけた顧客の資産情報と顧客の属性情報を、前記第1記憶部とは別に設けられた第2記憶部に記憶させるステップと、をコンピュータに実行させるためのコンピュータプログラム。申請および承認をコンピュータネットワークにて実行するシステムは、証券業務でも必要とされる。例えば、信用取引口座開設申請書、短期売却届出書等を申請して承認を受けるために申請書の作成と承認処理が必要となる。このような証券業務における申請および承認をコンピュータネットワークにて実行するシステムで行おうとする場合、証券業務に特有の課題がある。課題のひとつは、申請を承認するか否かを判断するために申請内容応じた種々の情報が必要であり、例えば顧客の住所、氏名、年齢といった属性情報のみならず、顧客の所有している資産情報や顧客の投資方針等が必要になる場合があることである。ここで、申請承認の際に必要となる情報は任意のタイミングで更新される必要があり、更新の頻度やタイミングは情報によって異なる。例えば顧客の住所のような属性情報は更新は少なく、更新するタイミングも顧客から連絡があった場合や証券会社の社員が顧客に営業を行うなどして連絡を取った場合のように自由に更新できることが好ましい。一方、顧客の資産情報については例えば、株価は日々変動するため更新頻度は多く、株価情報は通常、定期的に更新されるため、資産情報についてはある程度、定期的に更新できることが好ましい。このように申請および承認に際して必要な様々な情報は多岐にわたり、それぞれ異なる頻度やタイミングで更新できる必要があることが別の課題となっている。以下、この課題を具体的に説明する。申請および承認の内容を事後的に監査等することを考慮すると、申請および承認の際に参照される情報は少なくとも申請時点において固定された状態で承認申請、承認判断、承認完了という承認申請手続きを経て保存される必要がある。このため、申請および承認をシステムで行うためには、申請および承認に必要な情報を任意のタイミングで更新可能とすることと、申請および承認時に参照された情報が固定されることとを両立させる必要がある。本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、証券業務の状況を考慮して書類の申請処理を実行する技術を提供することである。上記課題を解決するために、本発明のある態様の申請装置は、ネットワークを介して接続された端末装置から、所定の顧客についての証券業務に関する承認申請の開始指示を受けつける第1受付部と、複数の顧客のそれぞれに対して、顧客の資産情報と顧客の属性情報とを記憶する第1記憶部と、第1受付部において受けつけた開始指示に対する顧客の情報を参照して、第1記憶部に記憶した顧客の資産情報と顧客の属性情報から、当該顧客についての資産情報と属性情報とを取得する取得部と、取得部において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成する生成部と、生成部において生成した承認申請画面を端末装置に表示させるために、ネットワークを介して端末装置へ承認申請画面を出力する出力部と、出力部から出力した承認申請画面が端末装置に表示された状態において、端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつける第2受付部と、第1記憶部とは別に設けられた第2記憶部と、第2受付部が申請指示を受けつけると、第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、第2受付部において受けつけた顧客の資産情報と顧客の属性情報を第2記憶部に記憶させる登録部と、を備える。この態様によると、第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、承認申請画面に含まれた顧客の資産情報と顧客の属性情報を第2記憶部に記憶させるので、上記課題を解決できる。本発明の別の態様は、申請方法である。この方法は、ネットワークを介して接続された端末装置から、所定の顧客についての証券業務に関する承認申請の開始指示を受けつけるステップと、複数の顧客のそれぞれに対して、顧客の資産情報と顧客の属性情報とを記憶する第1記憶部から、受けつけた開始指示に対する顧客の情報を参照して、当該顧客についての資産情報と属性情報とを取得するステップと、取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成するステップと、生成した承認申請画面を端末装置に表示させるために、ネットワークを介して端末装置へ承認申請画面を出力するステップと、出力した承認申請画面が端末装置に表示された状態において、端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつけるステップと、申請指示を受けつけると、第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、申請指示とともに受けつけた顧客の資産情報と顧客の属性情報を、第1記憶部とは別に設けられた第2記憶部に記憶させるステップと、を備える。なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。本発明によれば、証券業務の状況を考慮して書類の申請処理を実行できる。本発明を具体的に説明する前に、まず概要を述べる。本発明の実施例に係る証券業務システムは、証券会社の社員である申請者の操作によって、証券業務における書類を作成し、作成した書類を申請する。また、証券業務システムは、証券会社の別の社員である承認者の操作によって、申請された書類を承認したり、非承認したりするとともに、承認前の書類や承認後の書類を管理する。ここで、書類とは、例えば、信用取引口座開設申請書、短期売却届出書であり、これらには、不正な取引を防止するためのコンプライアンスを遵守するといった目的のために、申請および承認が必要とされる。申請および承認のための証券業務システムでは、証券業務特有の事情を考慮して構成されるべきである。承認する際に、顧客の資産が考慮されることもある。このような資産には、株、社債、投資信託が含まれ、それらも証券業務システムにて管理されている。それらの価値は日々変動しているので、顧客の資産は日々変動している。また、承認に際しては顧客の氏名や住所といった属性情報も必要であるが、これらの情報は任意のタイミングで変動する。つまり、これらの情報は任意のタイミング、頻度で変動するため、これらをシステムで管理するに際しては任意のタイミングで更新可能としておくことが望ましい。一方、承認対象となる書類において資産や顧客属性の情報は固定されていないと、承認者は承認できず、承認後の監査も困難となる。なお、承認に際して必要な顧客の情報は顧客が個人であるか法人であるかによっても異なる。そのため、書類を作成する際に、顧客の種類に応じて承認に必要な情報が申請および承認時に容易に参照できるようになっていることが望まれる。これらに対応するために、本実施例に係る証券業務システムでは、申請者が書類を作成する際に、申請および承認に際して求められる情報を任意のタイミングで更新可能な状態で記憶されたデータベースから、必要なデータを抽出する。なお、抽出されるデータは、顧客の種類によって異なる。申請者が作成した書類を申請する際に、証券業務システムは、書類の作成時に抽出したデータを固定して別のデータベースに記憶する。当該別のデータベースでは、固定したデータが記憶されている。承認者が書類を承認する際には、固定したデータが記憶されたデータベースが参照される。このように、申請および承認に必要なデータは、更新可能に記憶された記憶部に保持され任意のタイミングで更新され、申請時にはこの記憶部から取得され、申請完了に伴って固定されることで固定したデータが別のデータベースに格納される。以下では、説明を明瞭にするために、証券業務システムを複数に分けて説明する。まず、1.全体構成を説明した後に、2.顧客情報生成処理、3.書類登録処理、4.申請登録処理、5.承認登録処理、6.事務処理登録処理、7.申請保管処理、8.監査証跡管理処理の各処理を説明する。その後、9.動作を説明する。さらに、10.全体構成の追記を説明する。1.全体構成図1は、本発明の実施例に係る証券業務システム200の構成を示す。証券業務システム200は、申請サーバ10、端末装置12と総称される第1端末装置12a、第2端末装置12b、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22、ネットワーク24、顧客情報生成部70を含む。資産情報記憶部14は、預りDB30、資産DB32を含み、顧客属性記憶部16は、共通属性DB34、個人属性DB36、法人属性DB38を含み、顧客情報記憶部18は、既存客情報管理DB40、顧客カードDB42を含む。申請情報記憶部20は、第1DB44、第2DB46、申請書類管理DB56を含み、第1DB44は、申請顧客情報DB48を含み、第2DB46は、申請管理DB50、申請状況管理DB52、監査証跡管理DB54を含む。承認情報記憶部22は、申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64を含む。端末装置12は、証券会社の社員が証券業務のための書類を作成する際に使用する装置であり、例えば、PCに相当する。端末装置12は、通信機能を備え、ネットワーク24に接続される。図1では、2台の端末装置12が示されているが、これに限定されない。また、第1端末装置12aは、書類を申請すべき社員以下、申請者というによって使用され、第2端末装置12bは、申請された書類を承認すべき社員以下、承認者というによって使用されるものとする。申請サーバ10は、ネットワーク24を介して、端末装置12に接続されたサーバである。申請サーバ10は、端末装置12からの指示に応じた処理を実行し、その結果を端末装置12に返信する。資産情報記憶部14は、預りDB30、資産DB32を記憶するための記憶媒体である。資産情報記憶部14は、ネットワーク24に接続され、申請サーバ10からアクセスされることで申請サーバ10によって必要な情報が取り出されてもよい。図1の態様では、後述する顧客情報生成部70が資産情報記憶部14と顧客属性記憶部16とから顧客の資産情報と顧客属性とをそれぞれ取り込んで顧客ごとに申請および承認に必要な情報を生成した情報を記憶する顧客情報記憶部18を介して資産情報記憶部14の情報が申請サーバ10に取り出されるように構成されている。預りDB30および資産DB32に格納されるデータの内容については後述するが、これらのデータの内容は日々変動する。変動の周期は、一般的に1日よりも短く変動タイミングは一般的に予め定められている。このように、資産情報記憶部14は、所定のタイミグで更新されるデータを更新可能な状態で記憶するための記憶媒体第1記憶部である。顧客属性記憶部16は、共通属性DB34、個人属性DB36、法人属性DB38を記憶するための記憶媒体である。本実施形態では上述した通り顧客属性記憶部16の情報は顧客情報生成部70により生成され顧客情報記憶部18に記憶された情報として申請サーバ10によって取り出されるように構成されているが、顧客属性記憶部16は、ネットワーク24に接続され、申請サーバ10からアクセスされることで申請サーバ10が直接、顧客属性記憶部16から必要な情報を取り出すようにしてもよい。共通属性DB34、個人属性DB36、法人属性DB38に格納されるデータの内容については後述するが、これらのデータの内容は任意のタイミングで変動する。このように、顧客属性記憶部16は、任意のタイミングで更新されるデータを更新可能な状態で記憶するための記憶媒体第1記憶部である。顧客情報記憶部18は、資産情報記憶部14と顧客属性記憶部16とから顧客の資産情報と顧客属性とをそれぞれ取り込んで顧客ごとに申請および必要な情報として取り出しやすくした状態として既存客情報管理DB40、顧客カードDB42に情報を記憶するための記憶媒体である。顧客情報記憶部18は、ネットワーク24に接続され、申請サーバ10からアクセスされる。既存客情報管理DB40および顧客カードDB42に格納されるデータは、預りDB30、資産DB32、共通属性DB34、個人属性DB36、法人属性DB38に格納されたデータをもとに生成される。そのため、顧客情報記憶部18のデータは、適宜、更新され、顧客情報記憶部18も適宜、更新されるデータを更新可能な状態で記憶するための記憶媒体である。申請情報記憶部20は、申請顧客情報DB48、申請管理DB50、申請状況管理DB52、監査証跡管理DB54、申請書類管理DB56を記憶するための記憶媒体である。申請情報記憶部20は、申請サーバ10からアクセスされる。申請顧客情報DB48、申請管理DB50、申請状況管理DB52、監査証跡管理DB54、申請書類管理DB56は、書類を申請してから承認するまでの期間においてデータを格納する。申請顧客情報DB48に格納されたデータは、書類を申請してから承認するまでの期間において固定されている。つまり、削除される場合を除いて編集や修正はなされない。そのため、申請完了時点では顧客情報記憶部18と申請顧客情報DB48に同様の内容のデータが記憶され、その後、顧客情報記憶部18のデータ内容が変更されても申請情報記憶部20には申請時点のデータが内容変更できないすなわち固定された状態で記憶される。このように申請完了時点に取得された顧客情報を申請顧客情報DB48に固定して記憶させることで編集禁止のデータを誤って編集してしまうが防止され、その後の承認手続きにおいて申請時点の顧客情報を参照することができる。一方、申請情報記憶部20の申請管理DB50、申請状況管理DB52、監査証跡管理DB54、申請書類管理DB56に格納されたデータは、編集可能である。このように、申請情報記憶部20は、固定されたデータが記憶される申請顧客情報DB48第1DB44と申請完了から承認完了までの間、更新可能なデータが記憶される申請管理DB50、申請状況管理DB52、監査証跡管理DB54第2DB46とを備える記憶媒体である。承認情報記憶部22は、申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64を記憶するための記憶媒体である。承認情報記憶部22は、ネットワーク24に接続され、申請サーバ10からアクセスされる。申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64は、承認された申請についてのデータを格納する。申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64に格納されたデータは、編集されずに固定された状態で記憶されている。このように承認情報記憶部22は、固定されたデータを格納するための記憶媒体であるともいえる。承認情報記憶部22のうち、申請顧客履歴情報DB58には申請完了時点で取得され申請顧客情報DB48に固定して記憶された顧客情報が固定して記憶されており、承認手続き中と同様に承認完了後も申請完了時点に取得された顧客情報が保持され参照することができる。申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64に記憶されたデータは、それぞれ申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶されたデータの内容が承認完了時に固定されたものである。そのため、承認手続き中は申請情報記憶部20の申請管理DB50、申請状況管理DB52、監査証跡管理DB54により申請内容や承認申請の状況等を確認しつつ、承認手続き後は申請の内容、履歴、承認履歴等が誤って編集してしまうことを防止して申請内容等を確認することができる。図2は、申請サーバ10の構成を示す。申請サーバ10は、書類登録部72、申請登録照会部74、承認登録部76、事務処理登録部78、申請保管部80、監査証跡管理部82、IF部84を含む。IF部84は、図示しないネットワーク24に接続され、通信機能を実行する。IF部84は、ネットワーク24を介して、図示しない端末装置12、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22と通信し、顧客情報記憶部18と顧客情報生成部70を介して資産情報記憶部14および顧客属性記憶部16にアクセスする。図1の顧客情報生成部70は、申請者が端末装置12を操作して書類を作成する前に、書類の作成に必要な顧客データを収集し、顧客ごとの顧客属性情報と顧客資産情報とを作成する。詳細は後述するが、顧客情報生成部70は、資産情報記憶部14および顧客属性記憶部16に記憶されたデータをもとに、顧客の資産情報と顧客の属性情報とを取得し、加工して顧客情報記憶部18に記憶する。前述のごとく、資産情報記憶部14および顧客属性記憶部16に記憶されたデータは変動するので、顧客情報生成部70は、これらのデータの変動に合わせて、データを更新する。なお、顧客情報生成部70は、申請サーバ10の内部に設けられ、ネットワーク24を介して資産情報記憶部14と顧客属性記憶部16とが申請サーバ10に接続され、申請サーバ10が資産情報記憶部14と顧客属性記憶部16から必要な情報を取得してもよい。書類登録部72は、書類フォーマットの作成者が端末装置12を操作して作成した書類のフォーマットを更新書類管理DBに登録する。具体的には書類登録部72は、申請情報記憶部20の申請書類管理DB56に申請書類のフォーマット情報を登録する。申請の処理が開始されると、申請登録照会部74は、書類登録部72で作成され申請書類管理DB56に登録されている申請書類のフォーマットの中から申請の種類に応じた書類のフォーマットを呼び出すとともに、顧客情報記憶部18を介して資産情報記憶部14と顧客属性記憶部16に記憶されたデータのうち、申請の種類に応じて必要な顧客情報を抽出し、申請画面を生成する。申請者が申請画面から申請を行う旨の指示申請指示を入力すると、申請登録照会部74はこの指示を受け付けて、顧客情報記憶部18を介して資産情報記憶部14と顧客属性記憶部16から取得し申請画面に表示した顧客情報を申請情報記憶部20の申請顧客情報DBに固定した状態で記憶させる。また、申請登録照会部74は、申請に関する情報を第2DB46に記憶させる。承認登録部76は、申請登録照会部74が申請者からの承認申請指示を受け付けて登録した後、承認者による端末装置12の操作に応じて、承認者が行う承認処理の結果を受け付けてその内容を登録する。承認結果が受け付けられて登録されると、承認登録部76は、申請情報記憶部20の申請顧客情報DB48に固定して記憶していたデータを承認情報記憶部22に更新不可の状態で記憶させる。事務処理登録部78は、申請登録照会部74が申請指示を受け付けて登録した後、申請内容にしたがった事務処理を登録する。事務処理とは、例えば、申請の内容が信用口座の開設であった場合、実際に信用口座を開設するための処理である。このような事務処理は、申請者や承認者とは異なった証券会社の社員によってなされる。事務処理に際しては申請情報記憶部20の申請顧客情報DB48に記憶していたデータが参照される。申請保管部80は、承認登録部76が承認処理の結果を登録した後、端末装置12からの指示にしたがって、承認した内容を表示させる。その際、申請保管部80は、承認情報記憶部22に記憶されたデータを抽出する。監査証跡管理部82は、承認登録部76が承認処理の結果を登録した後、端末装置12からの指示にしたがって、申請から承認までの履歴を表示させる。その際、監査証跡管理部82は、監査証跡管理DB54または監査証跡履歴管理DB64に記憶されたデータを抽出する。以下の各処理に対する説明では、図1に示した申請処理部100の構成、図2に示した申請サーバ10の構成のうち、必要な部分だけを図示する。この構成は、ハードウエア的には、任意のコンピュータのCPU、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。2.顧客情報生成処理図3は、顧客情報生成部70の構成を示す。顧客情報生成部70は、第1取込部90、第2取込部92を含む。また、顧客情報生成部70は、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18に接続される。なお、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。前述のごとく、顧客情報生成部70は、申請サーバ10の内部に設けられてもよいが、その際、申請サーバ10は資産情報記憶部14、顧客属性記憶部16とネットワークを介して接続され、これら記憶部の情報を取り出して顧客情報生成部70で必要な情報を生成する。預りDB30は、顧客の保有している預り情報を記憶する。預りDB30では、預りごとの記憶がなされている。図4は、預りDB30のデータ構造を示す。図示のごとく、ユーザ欄300、部店欄302、口座番号欄304、商品欄306、銘柄欄308、数量欄310、取得単価欄312、時価欄314が含まれる。預りDB30は、各ユーザから預っているっている株式、債券、投信等の銘柄、数量、価格等を記憶する。預りDB30に格納されたデータは、商品を売買したタイミング、時価が変動したタイミングにおいて更新される。図3に戻る。資産DB32は、顧客の保有している預り資産を記憶する。資産DB32では、口座ごとの記憶がなされている。図5は、資産DB32のデータ構造を示す。図示のごとく、ユーザ欄320、部店欄322、口座番号欄324、総資産額欄326が含まれる。総資産額欄326に含まれた総資産額は、預りDB30に格納されたデータと図示しない株価情報DBとをもとに導出される。そのため、株価情報DBのデータや預りDB30に格納されたデータが更新されると、資産DB32に格納されたデータ、つまり総資産額も更新される。一般に株価情報DBのデータは所定のタイミング例えば一日一回で更新されるため、これに伴って資産DB32のデータも更新される。また、預りDB30は株式等の売買が成立した場合などの任意のタイミングで更新され、資産DB32は株価情報DBに対する所定の更新タイミングのみならず、任意で発生する預りDBの更新に合わせてもデータが更新可能なように構成されている。図3に戻る。共通属性DB34は、個人客、法人客に共通する属性情報を記憶する。共通属性DB34では、口座ごとの記憶がなされている。図6は、共通属性DB34のデータ構造を示す。図示のごとく、ユーザ欄330、部店欄332、口座番号欄334、顧客名欄336、住所欄338、電話番号欄340、職業欄342、リスク説明不要株式欄344、リスク説明不要債券欄346、リスク説明不要転換社債欄348、リスク説明不要外証欄350、コンプラランク欄352、口座開設日欄354が含まれる。例えば、住所欄338の住所が変更されたタイミングのような任意の不定期なタイミングにおいて、共通属性DB34に格納されたデータは更新される。図3に戻る。個人属性DB36は、個人客に関する属性情報を記憶する。個人属性DB36でも、口座ごとの記憶がなされている。図7a-cは、個人属性DB36のデータ構造を示す。個人属性DB36に格納されたデータの項目数が多いので、ここでは図7a-cに分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄360、部店欄362、口座番号欄364、顧客名欄366、生年月日欄368、性別欄370、勤務先欄372、役職欄374、取引動機欄376、資金性格欄378、投資方針欄380、資産運用期間欄382、投資経験有無株式現物欄384、投資経験有無債券欄386、投資経験有無転換社債欄388、投資経験有無株式信用欄390、投資経験有無ワラント欄392、投資経験有無先物OP欄394、投資経験有無貯蓄型投信欄396、投資経験有無投資信託欄398、投資経験有無外国証券欄400、投資経験有無その他欄402、主な収入源欄404、推定年収欄406、金融資産欄408が含まれる。個人属性DB36に格納されたデータも、共通属性DB34に格納されたデータと同様に、任意の不定期なタイミングにおいて更新される。図3に戻る。法人属性DB38は、法人客に関する属性情報を記憶する。法人属性DB38でも、口座ごとの記憶がなされている。図8a-bは、法人属性DB38のデータ構造を示す。法人属性DB38に格納されたデータの項目数が多いので、ここでは図8a-bに分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄410、部店欄412、口座番号欄414、顧客名欄416、取引動機欄418、資金性格欄420、投資方針欄422、資産運用期間欄424、投資経験有無株式現物欄426、投資経験有無債券欄428、投資経験有無転換社債欄430、投資経験有無株式信用欄432、投資経験有無ワラント欄434、投資経験有無先物OP欄436、投資経験有無貯蓄型投信欄438、投資経験有無投資信託欄440、投資経験有無外国証券欄442、投資経験有無その他欄444、資本金欄446、代表者名欄448が含まれる。法人属性DB38に格納されたデータも、共通属性DB34に格納されたデータと同様に、任意の不定期なタイミングにおいて更新される。図3に戻る。個人の顧客に対するデータと法人の顧客に対するデータとは異なるので、個人属性DB36と法人属性DB38とが別に設けられる。なお、個人属性DB36に格納されたデータと法人属性DB38に格納されたデータは、承認申請の際および承認処理承認/非承認判断の際に使用される。承認申請および承認処理の判断に際し、個人の顧客と法人の顧客とでは必要な情報が異なるので、個人属性DB36と法人属性DB38とが別に設けられている。第1取込部90は、各顧客に対して、預りDB30および資産DB32に格納されたデータを読み込む。第1取込部90は、読み込んだデータを既存客情報管理DB40に出力する。第2取込部92は、各顧客に対して、共通属性DB34、個人属性DB36、法人属性DB38に格納されたデータを読み込む。なお、顧客の属性の種類に応じて、個人属性DB36あるいは法人属性DB38が選択される。第1取込部90は、読み込んだデータを既存客情報管理DB40および顧客カードDB42に出力する。既存客情報管理DB40は、各顧客に対して、第1取込部90および第2取込部92からのデータを取り込み、顧客属性情報の一部と顧客資産情報とを記憶する。具体的には、顧客の属性情報の種類が個人である場合、口座開設日、住所、職業、生年月日、性別、電話番号、勤務先、役職、預り資産、コンプラランク、リスク説明不要な商品の情報が含まれる。一方、顧客の属性情報の種類が法人である場合、口座開設日、住所、役職代表者名、電話番号、業種、資本金、預り資産、コンプラランク、リスク説明不要な商品の情報が含まれる。つまり、顧客情報記憶部18のうちの既存客情報管理DB40では、顧客の属性情報の種類として、複数の種類、具体的には個人と法人が規定されている。顧客カードDB42は、各顧客に対して、第2取込部92からのデータを記憶し顧客属性情報を記憶する。具体的には、投資経験に関する情報、取引種類、資金性格、投資方針、資産運用期間、主な収入源、金融資産、年収が含まれる。顧客カードDB42に格納されるデータの項目は、顧客の属性情報の種類にかかわらず同一である。既存客情報管理DB40および顧客カードDB42に格納されたデータは、資産情報記憶部14および顧客属性記憶部16に格納されたデータの更新に応じて、更新される。そのため、顧客情報記憶部18に格納されたデータは、所定のまたは任意のタイミングにて更新できるよう構成されている。3.書類登録処理図9は、書類登録部72の構成を示す。書類登録部72は、書類生成部94を含む。また、書類登録部72は、申請情報記憶部20、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、申請情報記憶部20、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。受付部96は、承認申請の申請者からの入力を受けつける。入力は、キーボードやマウス等の入力機器を介してなされる。ここでの入力は、申請書類のフォーマットを作成するためのデータの入力に相当する。受付部96は、入力されたデータを書類生成部94へ出力する。書類生成部94は、受付部96からのデータを受けつける。書類生成部94は、受けつけたデータをもとに、承認申請に用いられる書類以下、申請書類というのフォーマットを生成する。書類生成部94は、作成中の申請書類のフォーマットを表示部98に表示させる。フォーマットが定められた申請書類は、申請書類管理DBに記憶される。表示部98は、書類生成部94からの指示に応じて申請書類のフォーマットを表示する。図10は、書類生成部94によって生成される申請書類のフォーマットの登録画面を示す。画面中、書類コード欄600には、申請書類を識別するために付与される書類コードが表示される。書類分類欄602には、申請書類の分類が表示される。書類名欄604には、申請書類の名称が表示される。申請書類を新規登録する場合、書類コード欄600、書類分類欄602、書類名欄604は、新たに入力される。これらの下段には、申請書類に含まれる項目が示される。書類フォーマットの登録者は、項目内容を編集できる。そのため、右側の内容の部分に表示されるチェックボックス等は任意に設定可能である。図11は、書類生成部94によって生成され承認者を設定するための申請書類承認者定義画面を示す。申請書類は、一般的に、書類の種類に応じて承認者が異なる。図9に戻る。申請書類管理DB56は、書類生成部94によって作成された申請書類のフォーマット情報を記憶する。申請書類管理DB56に記憶される申請書類のフォーマット情報には、各書類について設定され登録された承認者情報も含まれる。4.申請登録処理図12は、申請登録照会部74の構成を示す。申請登録照会部74は、申請処理部100、申請状況照会部102を含み、申請処理部100は、申請画面生成部104、取得部106、移動部108を含む。また、申請登録照会部74は、顧客情報記憶部18、申請情報記憶部20、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、顧客情報記憶部18、申請情報記憶部20、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。申請画面生成部104は、受付部96から受けつけた指示であって、かつ申請者からの指示を受けつける。申請画面生成部104は、受付部96で受けつけた指示をもとに、申請書類を作成するための画面を作成し、申請処理を実行する。図13は、申請画面生成部104によって生成され申請書類管理DBから申請の種類に応じて申請書類のフォーマットを呼び出した状態の書類選択画面を示す。書類コード欄610、書類分類欄612、書類名欄614は、図10の書類コード欄600、書類分類欄602、書類名欄604に対応しており、受付部96が申請者からのこれらの欄への入力または顧客に紐づけられた口座番号の入力を受け付けることによってこれらの欄への入力で特定される申請書類または口座番号により特定される顧客について必要な申請書類のフォーマットが呼び出される。図13では口座番号が指定されることでこの口座番号に紐づけられた顧客に関する承認申請に必要な複数の申請書類フォーマットの候補が書類コード欄610、書類分類欄612、書類名欄614の下に複数、表示された状態を示している。このように申請書類のフォーマットが示された状態において申請者は申請に必要な書類を特定して、申請入力ボタン616を押し下げることで申請書類の作成を開始する指示を入力する。図12に戻る。申請画面生成部104は、申請書類の作成開始指示を受けつけると、申請書類管理DB56から特定された申請書類のフォーマットを取得する。また、申請画面生成部104は、申請書類の作成開始指示を受けつけると、その旨を取得部106に通知する。その際、口座番号欄に入力され口座番号と一意に紐づけられた顧客を特定する情報例えば顧客コードも取得部106に通知される。取得部106は、申請画面生成部104からの申請書類作成開始指示を受けつけると、顧客情報記憶部18に含まれた既存客情報管理DB40と顧客カードDB42とから、該当する顧客の属性情報および資産情報等を取得する。これらを取得するために、取得部106は、顧客コード等による検索を実行する。ここで、顧客情報記憶部18の顧客情報は、顧客コードに紐づけられ記憶されている。よって、ひとつの顧客コードから、個人の属性情報あるいは法人の属性情報が取得されるので、申請画面生成部104から受けつけた顧客コードは、顧客の種類を特定するための情報ともいえる。前述のごとく、取得部106によってアクセスされる顧客情報記憶部18では、既存客情報管理DB40の内容と顧客カードDB42の内容とが、所定のまたは任意のタイミングにて更新されている。取得部106は、顧客情報記憶部18にアクセスした時点、すなわち、受付部96が申請者からの申請書類作成指示の入力を受け付けた時点とほぼ同じ時点に顧客情報記憶部18に保持されている顧客の属性情報と資産情報とを取得し、取得した顧客の資産情報と顧客の属性情報等を申請画面生成部104へ出力する。申請画面生成部104は、既に取得した申請書類のフォーマット情報に加えて、取得部106において取得した顧客の資産情報と顧客の属性情報等をもとに、顧客に対する証券業務に関する承認申請を行うための申請内容編集画面を生成する。申請画面生成部104は、作成した画面を表示部98に表示させる。表示部98は、申請画面生成部104からの指示に応じて画面を表示する。図14は、申請画面生成部104によって生成された申請内容編集画面を示す。特に、図14は、顧客が個人である場合の申請内容編集画面である。図中の第1顧客属性表示欄620において既存客情報管理DBから取得した顧客の属性情報が表示され、第2顧客属性表示欄622において顧客カードDB42から取得した顧客の属性情報が表示され、図中の預り資産欄624において、顧客カードDB42から取得した顧客の資産情報が表示される。これらの顧客情報表示欄620、622、624の下段には、申請内容が表示される。図15は、申請内容を照会するために申請画面生成部104によって生成される申請内容照会画面を示す。申請内容照会画面は、図14の申請書類作成画面において仮保存ボタンが押し下げられたことを受付部96が受け付けることで生成され、図14の顧客情報表示欄の下段に表示された申請内容を表示する画面である。図16は、申請画面生成部104によって生成される別の申請内容編集画面を示す。特に、図16は、顧客が法人である場合の申請内容編集画面である。図中の第1顧客属性表示欄630において既存客情報管理DB40から取得した顧客の属性情報が表示され、第2顧客属性表示欄632において顧客カードDB42から取得した顧客の属性情報が表示され、図中の預り資産欄634において、顧客カードDB42から取得した顧客の資産情報が表示される。第1顧客属性表示欄630に含まれる項目は、図14の第1顧客属性表示欄620に含まれる項目と異なっている。これは、顧客の種類が異なるためである。一方、第2顧客属性表示欄632、預り資産欄634に含まれる項目は、図14の第2顧客属性表示欄622、預り資産欄624に含まれる項目と同一である。図17は、申請画面生成部104によって生成される別の申請内容照会画面を示す。これは、必要な項目の入力が完了し、申請可能な状態である場合に相当する。そのため、申請ボタン640が表示されている。図12に戻る。表示部98に申請内容照会画面を表示させた状態において、申請者が申請ボタン640を押し下げることで承認申請の開始を行う指示を入力することにより、申請画面生成部104は、受付部96から証券業務の申請開始指示を受けつける。申請画面生成部104は、証券業務の申請開始指示を受けつけると、申請に係るデータを申請情報記憶部20に記憶させるよう、移動部108に指示する。移動部108は、申請画面生成部104からの指示を受けつけると、申請画面を生成するために使用したデータを申請情報記憶部20に記憶させる。つまり、申請書類の作成が完了し申請開始が指示された申請に係るデータは、申請情報記憶部20に記憶される。特に、移動部108は、既存客情報管理DB40と顧客カードDB42から取得された顧客の資産情報と顧客の属性情報等とを申請顧客情報DB48へ削除以外の編集が不可能な状態すなわち固定した状態で記憶させる。また、移動部108は、申請開始指示を行ってから承認が完了するまでの間、追加や修正等の編集が行われるデータを申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶させる。申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶させるデータの内容は後述する。前述のごとく、申請顧客情報DB48に記憶されたデータは、申請から承認までの間において、削除される場合を除いて、追加や変更等の編集ができないように固定されている。そのため、既存客情報管理DB40と顧客カードDB42に記憶され種々のタイミングや頻度で更新され変動しうるデータは、申請開始の指示が完了されたタイミングにおいて、申請顧客情報DB48に記憶されることによって固定される。一方、申請開始指示により申請顧客情報DB48に固定されたデータの元データであって既存客情報管理DB40と顧客カードDB42に記憶されていたデータは、申請顧客情報DB48への記憶が行われた後も変動され続けうる。一方、申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶されたデータは、申請から承認までの間において、編集可能である。申請顧客情報DB48は、申請書類の作成が完了し申請開始の指示が完了したタイミングで顧客情報を記憶する。申請顧客情報DB48では、ひとつの申請につき、1行の情報が登録される。図18a-fは、申請顧客情報DB48のデータ構造を示す。申請顧客情報DB48に格納されたデータの項目数が多いので、ここでは図18a-fに分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄450、申請番号欄452、部店欄454、口座番号欄456、顧客名欄458、郵便番号欄460、住所欄462、職業欄464、生年月日欄466、電話番号欄468、口座開設日欄470、性別欄472、資産欄474、コンプラランク欄476、役職欄478、勤務先欄480、代表者名欄482、資本金欄484、リスク説明不要株式欄486、リスク説明不要債券欄488、リスク説明不要転換社債欄490、リスク説明不要外証欄492、取引動機欄494、投資経験有無株式現物欄496、投資経験有無債券欄498、投資経験有無転換社債欄500、投資経験有無株式信用欄502、投資経験有無ワラント欄504、投資経験有無先物OP欄506、投資経験有無貯蓄型投信欄508、投資経験有無投資信託欄510、投資経験有無外国証券欄512、投資経験有無その他欄514、資金性格欄516、投資方針欄518、主な収入源欄520、推定年収欄522、金融資産欄524、資産運用期間欄526が含まれる。申請は、申請番号欄452に示された申請番号によって各申請が一意に識別される。他の項目は、既存客情報管理DB40および顧客カードDB42に格納されたデータの項目に類似する。申請管理DB50は、申請開始の指示が完了した申請書類に係るデータを記憶する。申請管理DB50は、ふたつの部分によって構成される。ひとつが申請管理であり、もうひとつが申請内容管理である。申請管理は、申請書類の基本的な情報すなわち属性情報を記憶する。申請管理では、ひとつの申請につき、1行の情報が登録される。図19は、申請管理DB50のデータ構造を示す。図示のごとく、ユーザ欄530、申請番号欄532、書類コード欄534、部店欄536、口座番号欄538、顧客名欄540、申請者名欄542、申請状況欄544、申請日時欄546、申請完了日欄548が含まれる。一方、申請内容管理は、申請ごとに申請内容を記憶する。つまり、申請内容管理に記憶された内容が、申請書類の実質的な内容に相当し、申請管理は、申請内容管理を識別するためのインデックスに相当する。そのため、申請内容では、ひとつの申請につき、申請書類の項目数に応じた1以上の行の情報が登録される。図20は、申請管理DB50の別のデータ構造を示す。図示のごとく、ユーザ欄550、申請番号欄552、申請内容の項目番号欄554、内容欄556が含まれる。申請管理DBのデータは、申請内容等に変更が生じた場合等のタイミングで更新される。申請状況管理DB52は、申請ごとに定義された申請者および承認者の登録状況を記憶する。申請状況管理DB52では、ひとつの申請につき、複数行の情報が登録される。複数行は、書類に対する承認者の数と申請者の数との和に相当する。申請状況DBのデータは承認処理が行われたタイミングなどで更新される。図21は、申請状況管理DB52のデータ構造を示す。図示のごとく、ユーザ欄560、申請番号欄562、役職欄564、登録状況欄566、登録日時欄568、登録者氏名欄570が含まれる。登録状況欄566において、現在のステータスが示される。監査証跡管理DB54は、申請書類に対する更新の履歴を記憶する。監査証跡管理DB54では、ひとつの申請につき、更新した数だけの情報が記憶される。監査証跡管理DB54も更新が行われたタイミングで更新される。図22は、監査証跡管理DB54のデータ構造を示す。図示のごとく、ユーザ欄580、申請番号欄582、更新時間欄584、更新者欄586、更新内容欄588、役職欄590が含まれる。更新時間欄584では、更新時間が示される。図12に戻る。申請状況照会部102は、申請開始の指示が完了した後、受付部96から受けつけた指示であって、照会者からの照会指示を受けつける。当該指示は、申請状況の照会要求である。申請状況照会部102は、照会指示を受けつけると、申請状況管理DB52に記憶されたデータを取得する。なお、申請状況照会部102は、申請管理DB50、監査証跡管理DB54に記憶されたデータを取得しない。つまり、申請情報記憶部20は、参照のタイミングに応じて、複数の部分に分割して構成されている。複数の部分は、申請顧客情報DB48、申請管理DB50、申請状況管理DB52、監査証跡管理DB54に相当する。このうち、申請顧客情報DBには固定された状態でデータが記憶され削除以外の編集ができない一方、その他のDBについてはデータが編集可能に構成されている。申請状況照会部102は、取得したデータをもとに申請状況一覧画面を生成し、生成した画面を表示部98に表示する。図23は、申請状況照会部102によって生成される申請状況一覧画面を示す。図示のごとく、申請状況と承認状況が申請ごとに表示される。複数の承認者が設定されている場合、複数の承認者のそれぞれにおける承認状況が示される。5.承認登録処理図24は、承認登録部76の構成を示す。承認登録部76は、承認画面生成部110、移動部112を含む。また、承認登録部76は、申請情報記憶部20、承認情報記憶部22、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、申請情報記憶部20、承認情報記憶部22、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。承認画面生成部110は、受付部96から受けつけた指示であって、かつ承認者からの承認申請表示指示を受けつける。当該指示は、承認申請を表示させる要求であり、この例では承認状況情報を伴って承認申請案件が表示されるため、承認申請表示要求は、前述の申請状況の照会要求と類似している。申請状況の照会要求では、申請状況と承認状況が申請ごとに表示部98に表示されるのに対して、承認申請表示要求では、承認状況が申請ごとに表示部98に表示される。承認画面生成部110は、承認申請表示指示を受けつけると、申請状況管理DB52に記憶されたデータを取得する。承認画面生成部110は、取得したデータをもとに承認申請表示画面を生成し、生成した画面を表示部98に表示する。図25は、承認画面生成部110によって生成される承認申請表示画面を示す。図示のごとく、承認状況が申請ごとに表示される。承認状況が承認待ちであることは、承認あるいは非承認すべき状況に相当する。一方、承認状況が未承認であることは、他の承認者が承認あるいは非承認すべき状況に相当する。さらに、承認状況が承認済であることは、既に承認した状況に相当する。なお、承認状況が非承認であることは、いずれかの承認者によって非承認された状況に相当する。図24に戻る。表示部98に承認申請表示画面を表示させた状態において、承認者が申請番号を特定して押し下げると、承認画面生成部110は、受付部96から、特定された申請番号に対応した申請書類の表示指示を受けつける。承認画面生成部110は、受けつけた指示に応じて、該当する顧客の顧客情報を申請顧客情報DB48から取得し、申請についての属性情報と申請内容の情報とを申請管理DB50から取得する。承認画面生成部110は、取得したデータをもとに、承認内容照会画面を作成し、作成した承認内容照会画面を表示部98に表示させる。図26は、承認画面生成部110によって生成される承認内容照会画面を示す。図示のごとく、申請書類と同様の内容が表示される。承認者は、承認内容照会画面の内容を確認し、承認する場合、承認ボタン650をマウスでクリックする。一方、承認者は非承認する場合、非承認ボタン652をマウスでクリックする。なお、承認者記入ボタンがクリックされると、承認画面生成部110は、承認者記入欄編集画面を表示部98に表示させる。図27は、承認画面生成部110によって生成される承認者記入欄編集画面を示す。内容の部分に示された項目は、顧客の属性に応じて規定される。図24に戻る。承認者による承認非承認の指示が入力されると、承認画面生成部110は、受付部96から、承認者による承認処理完了の指示を受けつける。これは、申請開始指示に対する承認処理の完了指示である。承認画面生成部110は、承認処理完了の指示を受けつけると、承認対象のデータを移動部112に更新不能な状態で記憶するように指示する。なお、複数の承認者が設定されている場合、承認画面生成部110は、最後の承認者が承認処理の完了を指示したときに移動部112にデータの記録を指示する。承認者が残っている場合、承認画面生成部110は、申請状況管理DB52および監査証跡管理DB54のデータを更新する。移動部112は、承認画面生成部110からの指示を受けつけると、申請顧客情報DB48に記憶されたデータを申請顧客履歴情報DB58に更新不能な状態で記憶させる。ここでのデータは、前述のごとく、顧客の資産情報と顧客の属性情報等に相当する。また、移動部112は、申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶されたデータを申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64にそれぞれ更新不能な状態で記憶させる。これらのデータは、申請顧客情報DB48に記憶されたデータに付随した申請情報ともいえ、申請開始の指示から承認完了の指示までの間において内容が更新可能とされていたデータを元データとする。一方、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64に記憶された申請情報は、更新不可能である。申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64は、承認情報記憶部22に格納されているので、承認情報記憶部22は、承認後のデータを記憶する。なお、申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64でのデータ構造は、申請顧客情報DB48、申請管理DB50、申請状況管理DB52、監査証跡管理DB54でのデータ構造とそれぞれ同様であるので、ここでは説明を省略する。6.事務処理登録処理図28は、事務処理登録部78の構成を示す。事務処理登録部78は、申請情報記憶部20、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、申請情報記憶部20、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。事務処理登録部78は、受付部96から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、事務処理状況の照会要求である。事務処理登録部78は、指示を受けつけると、申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶されたデータを取得する。事務処理登録部78は、取得したデータをもとに事務処理状況一覧画面を生成し、生成した画面を表示部98に表示する。図29は、事務処理登録部78によって生成される事務処理状況一覧画面を示す。図示のごとく、処理状況が申請ごとに表示される。処理状況が処理待ちであることは、事務処理を実行すべき状況に相当する。一方、処理状況が未処理であることは、他の社員が事務処理を実行すべき状況に相当する。さらに、処理状況が処理済であることは、既に処理した状況に相当する。7.申請保管処理図30は、申請保管部80の構成を示す。申請保管部80は、承認情報記憶部22、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、承認情報記憶部22、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。申請保管部80は、受付部96から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、承認が完了した申請書類の照会要求である。申請保管部80は、指示を受けつけると、申請状況履歴管理DB62に記憶されたデータを取得する。申請保管部80は、取得したデータをもとに保管している申請を表示する画面を生成し、生成した画面を表示部98に出力する。図31は、申請保管部80によって生成される保管申請表示画面を示す。図示のごとく、承認状況が確認される。なお、申請番号が選択されると、申請保管部80は、申請顧客履歴情報DB58、申請履歴管理DB60に記憶されたデータを取得し、承認された申請書類を表示部98に表示してもよい。8.監査証跡管理処理図32は、監査証跡管理部82の構成を示す。監査証跡管理部82は、申請情報記憶部20、承認情報記憶部22、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、申請情報記憶部20、承認情報記憶部22、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。監査証跡管理部82は、受付部96から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、申請書類に対する監査証跡の照会要求である。ここで、照会対象の申請書類に対して、承認が完了している場合があれば、承認が完了していない場合もある。監査証跡管理部82は、指示とともに申請番号も受けつけており、監査証跡管理DB54および監査証跡履歴管理DB64を参照することによって、申請番号に対応したデータが格納されている方を特定する。申請番号に対応したデータが監査証跡管理DB54に含まれていることは、承認が完了していない申請書類に対する監査証跡を照会することに相当する。一方、申請番号に対応したデータが監査証跡履歴管理DB64に含まれていることは、承認が完了した申請書類に対する監査証跡を照会することに相当する。監査証跡管理部82は、申請番号に対応したデータが監査証跡管理DB54に含まれている場合、監査証跡管理DB54に記憶されたデータを取得する。一方、監査証跡管理部82は、申請番号に対応したデータが監査証跡履歴管理DB64に含まれている場合、監査証跡履歴管理DB64に記憶されたデータを取得する。監査証跡管理部82は、取得したデータをもとに申請更新履歴照会画面を生成し、生成した画面を表示部98に出力する。ここで、申請情報記憶部20に記憶された第2DB46のうち、監査証跡管理DB54だけが使用され、申請管理DB50、申請状況管理DB52は使用されていない。また、承認情報記憶部22に記憶された申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64のうち、監査証跡履歴管理DB64だけが使用され、残りは使用されていない。つまり、監査証跡管理部82によって使用される部分は、申請情報記憶部20および承認情報記憶部22のうち、対応した部分である。そのため、承認情報記憶部22は、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64のように、複数の部分に分割して構成されている。このような分割は、第2DB46での構成に合わせられている。図33は、監査証跡管理部82によって生成される申請更新履歴照会画面を示す。図示のごとく、誰がいつ、何を実施したかが確認可能なような表示がなされる。9.動作以上の構成による証券業務システム200の動作を説明する。図34は、証券業務システム200による申請処理の手順を示すシーケンス図である。第1端末装置12aは、申請者からの開始指示を申請サーバ10へ送信するS10。申請サーバ10は、顧客情報記憶部18からデータを取得するS12。申請サーバ10は、申請画面を生成するS14。申請サーバ10は、生成した申請画面の表示指示を第1端末装置12aへ送信するS16。第1端末装置12aは、申請画面を表示するS18。第1端末装置12aは、申請者からの申請開始の指示を申請サーバ10へ出力するS20。申請サーバ10は、申請画面を生成するために取得し、および入力されたデータを申請情報記憶部20に送信するS22。申請情報記憶部20は、データを記憶するS24。図35は、証券業務システム200による承認処理の手順を示すシーケンス図である。申請サーバ10は、申請情報記憶部20からデータを取得するS30。申請サーバ10は、承認画面を生成するS32。申請サーバ10は、生成した承認画面の表示指示を第2端末装置12bへ送信するS34。第2端末装置12bは、承認画面を表示するS36。第2端末装置12bは、承認者からの承認指示を申請サーバ10へ出力するS38。申請サーバ10は、データの移動指示を申請情報記憶部20へ送信しS40、申請情報記憶部20は、データを承認情報記憶部22に送信するS42。承認情報記憶部22は、データを記憶するS44。10.全体構成の追記ここでは、1.全体構成において説明した証券業務システム200の構成を別の観点から説明する。図36は、本発明の実施例に係る証券業務システム200の別の構成を示す。証券業務システム200は、端末装置12と総称される第1端末装置12a、第2端末装置12b、ネットワーク24、Webアプリケーションサーバ210、BLBusinessLogicサーバ212、DBDataBaseサーバ214を含む。BLサーバ212は、申請承認処理部216、管理部218を含み、DBサーバ214は、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22を含む。また、管理部218は、顧客情報生成部70を含む。ここで、申請承認処理部216、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22は、申請機能実行部230としてまとめられ、管理部218、資産情報記憶部14、顧客属性記憶部16は、管理機能実行部232としてまとめられる。まず、図36の証券業務システム200と図1の証券業務システム200との対応を説明する。同一の符号で示された端末装置12、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22、ネットワーク24、顧客情報生成部70は、互いに対応する。また、図36の申請承認処理部216は、図1の申請サーバ10に対応する。Webアプリケーションサーバ210は、一方において、ネットワーク24を介して端末装置12と接続され、他方において、BLサーバ212と接続される。そのため、Webアプリケーションサーバ210は、証券業務システム200のうち、端末装置12とのインターフェイスの役割を担う。つまり、Webアプリケーションサーバ210は、ネットワーク24を介して端末装置12からの要求等の信号を受信するとともに、ネットワーク24を介して端末装置12へ応答や画面等の信号を送信する。BLサーバ212は、Webアプリケーションサーバ210に接続され、Webアプリケーションサーバ210からの要求に応じて処理を実行する。BLサーバ212は、実行すべき処理の内容に応じて複数の機能を実行しており、ここでは、一例として、申請承認処理部216、管理部218が含まれる。なお、端末装置12からの要求は、各機能に対応しており、Webアプリケーションサーバ210において割振りがなされる。また、申請承認処理部216は、処理を実行するために、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22と連携しており、これらによってなされる機能が申請機能実行部230である。管理部218は、処理を実行するために、資産情報記憶部14、顧客属性記憶部16と連携しており、これらによってなされる機能が管理機能実行部232である。ここでは、管理機能実行部232の処理をまず説明する。これは、2.顧客情報生成処理に関連する。資産情報記憶部14は、図3のごとく、預りDB30、資産DB32を備えている。預りDB30、資産DB32に記憶されたデータは、所定のタイミングで更新される。ここでは、更新処理を説明する。顧客が商品を売買したタイミングや、資産の時価が変動したタイミングにおいて、証券会社の担当者は、端末装置12を操作して、預りDB30に記憶されたデータの変更要求をWebアプリケーションサーバ210へ出力する。Webアプリケーションサーバ210は、預りDB30の変更要求であるので、BLサーバ212から管理部218を選択し、選択した管理部218へ変更要求を出力する。管理部218は、変更要求を受けつけてから対応可能になると、Webアプリケーションサーバ210を介して端末装置12へ、対応可能になったことが示された応答を送信する。端末装置12が応答を受信すると、担当者は端末装置12を操作して、変更内容を入力する。端末装置12は、Webアプリケーションサーバ210を介して、変更内容を管理部218へ出力する。管理部218は、変更内容に応じて、預りDB30のうちの対応したデータを更新する。前述のごとく、資産DB32に格納されたデータは、預りDB30に格納されたデータに依存する。そのため、管理部218は、預りDB30に格納されたデータを更新すると、資産DB32に格納されたデータも更新する。さらに、DBサーバ214には、図示しない株価情報DBが含まれており、当該株価情報DBは、定期的に更新されるので、管理部218は、予め定められた時刻に株価情報DBにアクセスし、株価情報DBに格納されたデータの更新を確認する。株価情報DBに更新があれば、管理部218は、それを反映させるように、資産DB32に格納されたデータを更新する。このように、預りDB30は、担当者の操作によって更新されるが、資産DB32は自動的に更新される。また、顧客属性記憶部16は、図3のごとく、共通属性DB34、個人属性DB36、法人属性DB38を含む。共通属性DB34、個人属性DB36、法人属性DB38も、預りDB30と同様に、担当者の操作によって更新されるので、ここでは説明を省略する。このように、資産情報記憶部14や顧客属性記憶部16は、所定のタイミングで更新される顧客の資産情報と顧客の属性情報とを逐次記憶する。顧客情報生成部70は、資産情報記憶部14、顧客属性記憶部16に記憶されたデータに更新があった場合、予め定められた一部の種類のデータによって、顧客情報記憶部18に記憶したデータを更新する。予め定められた一部の種類のデータは、例えば、顧客属性情報である。このような更新は、資産情報記憶部14、顧客属性記憶部16においてデータの更新がなされてから、一定の期間内に自動的になされる。その結果、一部の種類のデータについては、顧客情報記憶部18において最新の状態が維持される。また、更新には、AQ連携が使用される。さらに、夜間等の予め定められたタイミングにおいて、顧客情報生成部70は、残りの種類のデータによって、顧客情報記憶部18に記憶したデータを更新する。つまり、変更に追従して変更がなされなかった種類のデータが、一括して変更される。このように顧客情報生成部70は、管理機能実行部232内のデータによって、申請機能実行部230内のデータを更新する。これは、機能をまたいでデータを更新することに相当する。ここで、顧客情報生成部70による顧客の資産情報と顧客の属性情報との更新方向は、資産情報記憶部14、顧客属性記憶部16から、顧客情報記憶部18への一方向である。つまり、顧客情報記憶部18から、資産情報記憶部14、顧客属性記憶部16の方向への更新はなされない。これは、顧客情報記憶部18に格納されたデータよりも、資産情報記憶部14、顧客属性記憶部16に格納されたデータの方が重要性が高いためである。これは、資産情報記憶部14、顧客属性記憶部16が主となり、顧客情報記憶部18が従となるような主従関係が存在するためであるともいえる。次に、申請機能実行部230の処理を説明する。これは、3.書類登録処理、4.申請登録処理、5.承認登録処理、6.事務処理登録処理、7.申請保管処理、8.監査証跡管理処理に関連する。ここでは、特に、4.申請登録処理を説明する。申請者は、第1端末装置12aを操作することによって、所定の顧客についての証券業務に関する承認申請の開始指示を入力する。第1端末装置12aは、ネットワーク24を介して開始指示をWebアプリケーションサーバ210へ出力する。Webアプリケーションサーバ210は、第1端末装置12aから、証券業務に関する承認申請の開始指示を受けつける。当該開始指示には、対象となる顧客に関する顧客コードが含まれるとともに、顧客が個人であるか法人であるかを識別するための識別情報も含まれる。Webアプリケーションサーバ210は、開始指示をもとに、申請承認処理部216を選択し、申請承認処理部216に開始指示を出力する。図12の取得部106は、Webアプリケーションサーバ210からの開始指示を入力する。取得部106は、受けつけた開始指示に対する顧客コードを参照して、顧客情報記憶部18に記憶した顧客の資産情報と顧客の属性情報等から、当該顧客についての資産情報と属性情報とを取得する。前述のごとく、取得部106によってアクセスされる顧客情報記憶部18では、既存客情報管理DB40の内容と顧客カードDB42の内容とが、所定のまたは任意のタイミングにて更新されている。取得部106は、顧客情報記憶部18にアクセスした時点、すなわち、受付部96が申請者からの申請書類作成指示の入力を受け付けた時点とほぼ同じ時点に顧客情報記憶部18に保持されている顧客の属性情報と資産情報とを取得する。その後、顧客情報記憶部18に記憶された顧客の属性情報と資産情報とが更新されても、更新内容は、取得部106において取得された顧客の属性情報と資産情報に反映されない。図12の申請画面生成部104は、取得部106において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する申請内容編集画面を生成する。申請画面生成部104において生成される申請内容編集画面は、前述のとおりであり、取得部106での取得後における顧客の属性情報と資産情報の更新を反映しない。また、顧客の属性情報と資産情報の更新履歴も含まれない。申請画面生成部104は、顧客コードをもとに、顧客が個人であるか法人であるかを特定する。なお、前述のごとく、顧客の種別と顧客コードとの紐づけは予めなされている。申請画面生成部104は、特定した結果に応じて異なった形式の申請内容編集画面を生成する。例えば、顧客が個人である場合の申請内容編集画面は、図14のように示され、顧客が法人である場合の申請内容編集画面は、図16のように示される。このように、申請画面生成部104に入力される顧客の資産情報と顧客の属性情報は、顧客が個人であるか法人であるかにかかわらず同一であるのに対して、申請画面生成部104によって生成される申請内容編集画面は、顧客が個人であるか法人であるかに応じて異なる。申請画面生成部104は、生成した申請内容編集画面をWebアプリケーションサーバ210に出力する。また、顧客情報等には、さまざまな項目が存在しており、顧客情報生成部70によって顧客情報記憶部18へ移動される際に項目が絞られるとともに、申請画面生成部104において画面を生成する際にも項目が絞られている。つまり、顧客情報等に含まれた項目は、2段階で絞られている。Webアプリケーションサーバ210は、申請画面生成部104において生成した申請内容編集画面を第1端末装置12aに表示させるために、ネットワーク24を介して第1端末装置12aへ申請内容編集画面を出力する。第1端末装置12aは、図示しないモニタに申請内容編集画面を表示する。申請者は、申請内容編集画面が第1端末装置12aに表示された状態において、図17の申請ボタン640を押し下げることによって、承認申請を行う旨の申請指示を入力する。第1端末装置12aは、証券業務の承認申請を行う旨の申請指示をWebアプリケーションサーバ210に出力する。なお、当該申請指示には、申請内容編集画面に含まれた顧客の資産情報と顧客の属性情報も含まれる。Webアプリケーションサーバ210は、申請指示を受けつけるとともに、申請内容編集画面に含まれた顧客の資産情報と顧客の属性情報も受けつける。Webアプリケーションサーバ210は、これらを申請承認処理部216に出力する。ここでは、図12の取得部106が登録部であるとする。登録部は、Webアプリケーションサーバ210が申請指示を受けつけると、Webアプリケーションサーバ210において受けつけた顧客の資産情報と顧客の属性情報を申請情報記憶部20に記憶させる。つまり、顧客情報記憶部18に記憶した顧客の資産情報と顧客の属性情報ではなく、第1端末装置12aにおいて申請者に直接確認された顧客の資産情報と顧客の属性情報とが記憶される。これは、申請者によって、所定の顧客についての証券業務に関する承認申請の開始指示が入力されてから申請指示が入力されるまでの間に、顧客情報記憶部18に記憶されたデータが更新されても、それが申請情報記憶部20に記憶されるデータに反映されないことに相当する。つまり、承認申請処理において、開始指示が入力されたタイミングでの顧客の資産情報と顧客の属性情報が使用されており、その後の更新内容は無視される。これより、更新履歴も記憶されない。仮に、申請者が、更新された顧客の資産情報と顧客の属性情報を反映させたいと考えれば、それまでの申請処理が破棄され、新たな開始指示が入力される。本発明の実施例によれば、顧客が個人であるか法人であるかに応じてコンプライアンスチェックやその他の承認に必要な属性情報が異なっていても、顧客が個人であるか法人であるかに応じて属性情報を別々に記憶するので、属性情報を効率的に記憶できる。また、顧客が個人であるか法人であるかに応じて属性情報を別々に取得して表示するので、承認判断に必要な情報を顧客の種類に応じて的確に参照できる。また、変動する資産情報や属性情報等を予め顧客情報記憶部に記憶しておくので、申請に際して必要な顧客情報を迅速に取得できる。また、申請の指示を受けつけた場合に、顧客情報記憶部に記憶された更新可能な情報を、固定の情報として申請情報記憶部に記憶させるので、申請を承認する際に必要な情報が変動することを防止できる。また、固定すべき情報を誤って更新してしまう危険性を低減できる。また、情報の性質に応じて、記憶部の構成を分けるので、処理を効率的に実行できる。また、開始指示に対する顧客の種類と、属性情報の種類とが対応しているので、受けつけた顧客の種類に合った属性情報を取得できる。また、受けつけた顧客の種類に合った属性情報が取得されるので、承認判断に必要な属性情報を正確に取得できる。また、承認判断に必要な属性情報が正確に取得されるので、承認の正確な処理を実現できる。また、承認指示を受けつけた場合に、申請情報記憶部に記憶された更新可能な情報を、更新不可能の情報として承認情報記憶部に記憶させるので、更新不可能な情報を誤って更新してしまう危険性を低減できる。また、更新不可能な情報を誤って更新してしまう危険性が低減されるので、性質の異なった情報を確実に処理できる。また、第2DBは、参照のタイミングに応じて、複数の部分に分割して構成されているので、必要な情報のみにアクセスできる。また、必要な情報のみにアクセスされるので、処理を効率を向上できる。また、申請の指示を受けつけた場合に、顧客情報記憶部に記憶された更新可能な顧客情報等ではなく、端末装置に表示された顧客情報等を申請情報記憶部に記憶させるので、申請者が確認した内容で申請を実行できる。また、端末装置に表示された顧客情報等が更新されても、申請情報記憶部は更新した内容を記憶しないので、固定すべき情報を誤って更新してしまう危険性を低減できる。また、資産情報記憶部、顧客属性記憶部から、顧客情報記憶部への一方向の更新がなされ、逆方向の更新がなされないので、資産情報記憶部、顧客属性記憶部が主であり、顧客情報記憶部が従である関係を維持できる。また、主従関係が維持されるので、資産情報記憶部、顧客属性記憶部が誤って更新されることを回避できる。また、顧客情報等が同一であっても、顧客が個人であるか法人であるかによって異なった画面が生成されるので、顧客の種類に適した画面を生成できる。また、顧客の種類に適した画面が生成されるので、申請者の利便性を向上できる。以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。