JP5214488B2 - 団体のデータ管理装置 - Google Patents

Description

この発明は、データ処理技術に関し、特に、会員の拠出金に基づいて定期的に商品を購入する団体のデータを管理する技術に関する。

持株会は、典型的には、企業の従業員等が給与等からの天引きにより自社や関連企業の株式を定期的かつ継続的に買い付けていく制度であり、多くの企業において導入されている。持株会が導入されることにより、企業にとっての安定株主を確保し、従業員の経営参加意識を高揚させる等の利点がある。

本出願人は、持株会を適切に普及させるとともに、従業員に対する法定外福利厚生予算を活用して従業員に自社株式の取得を奨励するために、特許文献１に係る持株会事務処理システムを提案している。

特開２００５−２８４４６１号公報

持株会が運営されていく中では、書類の記載ミス等、誤りが発生することがある。その結果、持株会のデータを管理する装置（以下、適宜「持株会管理装置」とも呼ぶ。）で保持されるデータであって、持株会に関する属性情報に誤ったデータが設定されることがある。持株会はその属性に応じて株式を一括購入し、各会員に配分する仕組みであるため、当初の誤り範囲は小さくても、時間の経過とともに誤り範囲は拡大しやすい。したがって、修正すべき箇所が多数となり、その修正作業に長い時間を要することで、持株会管理装置のユーザの利便性を損なうことがあった。

本発明は、こうした課題に鑑みてなされたものであり、その主たる目的は、持株会等、会員の拠出金に基づいて定期的に商品を購入する団体を管理する装置において、ユーザの利便性を向上させる技術を提供することである。

上記課題を解決するために、本発明のある態様の団体のデータ管理装置は、会員の拠出金に基づいて定期的に商品を購入する団体のデータを管理する装置であって、団体に関する属性情報を記憶する団体属性記憶部と、ユーザから受け付けられた属性情報に対する更新要求にしたがって属性情報を更新する属性情報更新部と、ユーザから受け付けられた更新要求を逐次記憶する更新要求記憶部と、バックアップ処理により生成された属性情報のコピーデータを記憶するバックアップデータ記憶部と、過去時点における誤りに起因して属性情報に生じている誤りを修正すべき際、その過去時点より前に生成された属性情報のコピーデータを、そのコピーデータの生成時点より後に受け付けられた更新要求にしたがって更新することにより、団体に関する新たな属性情報を設定する属性情報修正部と、を備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、会員の拠出金に基づいて定期的に商品を購入する団体のデータを管理する装置において、ユーザの利便性を向上できる。

本発明の実施の形態である持株会システムの構成を示す図である。 図１の持株会管理装置の機能構成を示すブロック図である。 持株会属性のデータモデルを示すＥＲ図である。 更新要求記憶部に保持されるデータ構造を示す図である。 持株会管理装置の動作を示すフローチャートである。 図５のＳ２０の詳細を示すフローチャートである。

本発明の実施の形態について、その構成を説明する前に概要を説明する。
持株会では、複数の会員のそれぞれが、月々所定の金額を拠出する。持株会の事務局はその拠出金をとりまとめて、持株会の残高管理や株式の買い付けを委託している証券会社（以下、適宜「担当証券会社」とも呼ぶ。）に対して、自社株式の買付を定期的に指示する。担当証券会社はその発注指示にしたがって株式を買付け、持株会の事務局は買付けられた株式を会員に配分する。以下では、持株会の事務局担当者や、持株会の会員や、持株会の担当証券会社の担当者等を、単に「ユーザ」とも呼ぶこととする。

持株会管理装置は、持株会に関する各種属性を示すデータ（以下、適宜「持株会属性」とも呼ぶ。）、例えば持株会そのものの属性や会員の属性等を保持する。そして、その持株会属性に応じて、株式の買付けに必要となるデータ（以下、適宜「株式注文データ」とも呼ぶ。）を定期的に作成する等により、ユーザの負担を軽減する。持株会管理装置において保持される持株会属性には、持株会やその会員が特定されるような情報（例えば名前や住所、コード番号のような識別符号等）、持株会やその会員が持つ株式の数や金銭の額のような残高情報等があり、新規会員の加入や株式の購入等によって更新される。

本実施の形態の持株会管理装置は、持株会属性の更新を要求するデータ（以下、単に「更新要求」とも呼ぶ。）をユーザから受け付け、その更新要求にしたがって持株会属性を更新する。更新要求は、システムレベルの要求であってもよいが、典型的には、持株会属性の更新を業務レベル、すなわちユーザの業務視点から要求するものである。したがって、特定のデータベース・テーブル・カラム等を指定した更新要求、例えばＳＱＬ（Structured Query Language）クエリーとは異なる。

ところで、持株会の事務局や担当証券会社における連絡ミスや手続ミス等により、その持株会属性に誤った情報が設定されることがある。上述したように、持株会では一括して株式が購入されて各会員に配分されるため、持株会属性の僅少な範囲の誤りに起因して、持株会属性の多くの範囲に誤りを生じさせる結果となる。したがって、持株会属性の誤りにユーザが気づいた時点では、修正すべき箇所が多数存在し、その修正作業に長い時間を要することがあった。

さらに、持株会属性に誤りが生じているとき、単に現在の状態を正しく修正するだけでは、問題が解決しないことがある。持株会属性に応じて過去に作成した帳票、例えば持株会の事務局向けの帳票や、会員向けの帳票についても修正する必要があるからである。したがって、複数の過去時点における持株会属性の状態についても正しく修正する必要があり、その修正作業にさらに長い時間を要することがあった。

以下提案する持株会管理装置においては、過去時点における持株会属性のバックアップデータを保持する。そして、誤りが生じた過去時点より前のバックアップデータを、そのバックアップデータの生成時点以降に受け付けられた更新要求で更新する。これにより、過去時点における誤りに起因して現在の持株会属性に生じている誤りが、遡及的に修正された持株会属性（以下、適宜「新たな持株会属性」とも呼ぶ。）を設定する。

例えば、現在の持株会属性の誤りがシステムのバグに起因するものであれば、そのバグがシステムに混入する時点より前の持株会属性と、その持株会属性のバックアップ時点より後の更新要求とに基づいて新たな持株会属性を設定する。また、現在の持株会属性の誤りが過去時点での誤った更新要求に起因するものであれば、その更新要求が受け付けられる前の持株会属性と、その持株会属性のバックアップ時点より後の更新要求であって、その誤りが修正された更新要求とに基づいて新たな持株会属性を設定する。これにより、過去時点から現在時点まで一貫して誤りのない持株会属性が迅速に再構築され、持株会管理装置のユーザの利便性を向上させる。

図１は、本発明の実施の形態である持株会システムの構成を示す。持株会システム１００は、ユーザ端末１０で総称される第１のユーザ端末１０ａ、第２のユーザ端末１０ｂ、第３のユーザ端末１０ｃと、取引所装置１４と、帳票出力装置１６と、持株会管理装置２０とを備える。これらの各装置は、ＬＡＮ・ＷＡＮ・インターネット等の公知の通信手段を含む通信網を介して適宜相互に接続される。

持株会管理装置２０は、複数の証券会社を主たるユーザとし、各証券会社がそれぞれ担当する複数の顧客企業の持株会の管理を行うために用いられ、いわゆるマルチユーザ（複数証券会社）により共同利用される装置である。持株会管理装置２０は、複数の持株会を管理し、各持株会の事務局、会員、担当証券会社からの各種要求に応じた情報処理を実行する。具体的には、複数の持株会それぞれに関する持株会属性を保持し、それぞれの持株会属性に応じて、各持株会に対するデータ処理を実行する。また、過去の誤りに起因してその持株会属性に誤りが生じている場合、上述したように、その誤りが修正された新たな持株会属性を設定する。持株会管理装置２０の詳細な構成は後述する。

ユーザ端末１０は、複数の持株会のそれぞれにかかわるユーザにより操作される一般的なＰＣ端末である。ユーザ端末１０は、持株会管理装置２０に対して、持株会属性の参照要求や更新要求を送信する。また、持株会管理装置２０から送信されたデータを画面表示させてユーザに提示する。

取引所装置１４は、持株会管理装置２０から送信された株式注文データにしたがって、株式の購入処理を実施し、株式取引の成立状態を示すデータ（以下、適宜「約定データ」とも呼ぶ。）を持株会管理装置２０へ送信する。帳票出力装置１６は、持株会管理装置２０から送信された帳票作成を指示するデータにしたがって、各種帳票の作成処理を実施する。

図２は、図１の持株会管理装置２０の機能構成を示すブロック図である。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

持株会管理装置２０は、データ処理において参照・更新される各種データを記憶する記憶領域である持株会属性記憶部２２、更新要求記憶部２６、バックアップデータ記憶部３２とを有する。さらに、各種データ処理を実行する更新要求受付部２４、ユーザ通知部２８、持株会処理実行部３０、バックアップ実行部３４、属性情報修正部３６とを有する。属性情報修正部３６は修正要求を受け付ける修正要求受付部３８を含み、通常のユーザの業務視点から要求される更新要求は更新要求受付部２４で受け付けられる一方、現状の状態を修正するだけではなく過去に作成した帳票等の過去のデータを修正する遡及処理を要求する修正要求は修正要求受付部３８で受け付けられ、前者は正系、後者は副系という別々の系統での処理に供される。

持株会属性記憶部２２は、持株会属性を記憶する。持株会属性は、リレーショナルデータベースに格納された複数のテーブルで構成される。図３は持株会属性のデータモデルを示すＥＲ（Entity Relation）図である。同図の企業属性テーブル６０には、持株会が設立された企業に関する属性データが記録される。銘柄情報テーブル６２には、持株会で購入される株式銘柄に関する属性データが記録される。会属性テーブル６４には、持株会そのものに関する属性データが記録される。会員属性テーブル６６には、持株会の会員に関する属性データが記録される。

注文明細テーブル６８には、取引所装置１４に対して株式の買付けを指示するためのデータが記録される。約定明細テーブル７０には、取引所装置１４における株式取引の成立状態が記録される。帳票属性テーブル７２には、帳票出力装置１６に対して帳票の作成を指示するためのデータが記録される。なお、注文明細テーブル６８、約定明細テーブル７０、帳票属性テーブル７２それぞれのレコードを、以下、注文明細レコード、約定明細レコード、帳票レコードと呼ぶこととする。

また、持株会属性記憶部２２は、複数の持株会それぞれの持株会属性を同一のテーブルに記憶する。したがって、例えば、会属性テーブル６４には、各持株会に関する属性データが、異なる持株会コードをキーとして保持される。また、会員属性テーブル６６には、各持株会の会員に関する属性データが、異なる持株会コードをキーとして保持される。

なお、図３で示すテーブル間の関連設定は一例であり、他の態様で関連が設定されてもよい。例えば、株式の注文や約定を持株会でのイベントとして扱う場合、会属性テーブル６４にはそのイベントに関する情報を保持するイベントテーブルとの関連が設定されてもよい。この場合、そのイベントテーブルには、注文明細テーブル６８、約定明細テーブル７０のそれぞれとの関連が設定されてもよい。図２に戻る。

ユーザ通知部２８は、約定データ等、ユーザに確認させるべき情報をユーザ端末１０に通知する。更新要求受付部２４は、会属性や会員属性等の持株会属性に対する更新要求をユーザ端末１０から受け付ける。また、更新要求受付部２４は、受け付けた更新要求を、その更新要求の受付日時と対応づけて更新要求記憶部２６に記憶させる。

図４は、更新要求記憶部２６に保持されるデータ構造を示す。同図の更新要求ＩＤは、更新要求を一意に特定するための識別情報であり、更新要求受付部２４が更新要求を受け付けた際に採番してもよい。同図の第１の更新要求レコード８０は、持株会Ａに所属する会員αの月々の拠出金額を「１万円」に変更するための更新要求を示している。第２の更新要求レコード８２は、株式買付のための入金が持株会Ｂから行われたことを示している。第３の更新要求レコード８４は、持株会Ｂにおける株式買付の約定状態を示す情報である。図２に戻る。

また、更新要求受付部２４は、特定の持株会について、その持株会属性の修正要求が受け付けられた旨を属性情報修正部３６から通知されてから、修正処理が完了した旨を属性情報修正部３６から通知されるまでの間、その持株会属性に対する更新要求の受け付けを拒否する。例えば、上述の通知には持株会コードが指定されており、その持株会コードが指定された更新要求については、受け付けられない旨をユーザ端末１０に通知する。その一方で、修正対象ではない持株会の持株会コードが指定された更新要求については、他の持株会の持株会属性が修正中であっても、継続して受け付ける。

持株会処理実行部３０は、更新要求受付部２４において受け付けられた更新要求にしたがって、持株会属性記憶部２２に記録された持株会属性を更新する。例えば、図４の第１の更新要求レコード８０が示す更新要求にしたがって、会員属性テーブル６６の拠出金額を変更する。また、図４の第２の更新要求レコード８２が示す更新要求にしたがって、会属性テーブル６４の入金フラグを入金有りの状態に設定する。また、図４の第３の更新要求レコード８４が示す更新要求にしたがって、約定明細テーブル７０の約定株数を設定する。

また、持株会処理実行部３０は、持株会属性記憶部２２に記憶された持株会属性に応じて、その持株会属性の更新や外部装置との通信等の各種バッチ処理を実行する。このバッチ処理は、その実行条件として特定の日時が設定されており、その特定の日時となったことを契機に実行される。また、その実行条件には、持株会属性の特定の状態が加重条件としてさらに設定されてもよい。この場合、特定の日時となり、かつ、そのときに持株会属性が特定の状態であることを条件としてバッチ処理が実行される。

持株会処理実行部３０において実行されるバッチ処理の例を示す。
（１）会属性テーブル６４の入金フラグが入金有りの状態を示すとき、注文明細テーブル６８に新たな注文明細レコードを設定する「注文明細レコード設定処理」。
（２）新たな注文明細レコードに基づいて株式注文データを生成して取引所装置１４に送信する「株式注文処理」。
（３）約定データを取引所装置１４から取得して、ユーザ通知部２８を介してユーザ端末１０に提供する「約定状態通知処理」。なお、ユーザによってその内容が了承された約定データは、第３の更新要求レコード８４のように、更新要求受付部２４において更新要求として受け付けられる。

（４）新たな約定明細レコードに基づいて、その約定数量を個々の会員に配分する「株式配分処理」。例えば、会員属性テーブル６６における各会員の拠出金額に応じて、各会員の持株数を適宜増加させる。
（５）約定明細テーブル７０や会員属性テーブル６６の更新状況に応じて、定期的に帳票属性テーブル７２に新たな帳票レコードを設定し、帳票作成を指示するデータを帳票出力装置１６へ送信する「帳票出力処理」。

バックアップデータ記憶部３２は、持株会属性のバックアップデータを記憶する。バックアップ実行部３４は、持株会属性記憶部２２に記憶された持株会属性について、複数の持株会それぞれの持株会属性を定期的に抽出してバックアップする。具体的には、バックアップを実行すべき所定のタイミングを検出して、各持株会の持株会属性のコピーデータと、そのコピーデータの生成日時とを対応づけてバックアップデータ記憶部３２に記憶させる。このバックアップのタイミングは、適宜決定されてよく、例えば毎月末である。ここでバックアップ実行部３４は、持株会属性記憶部２２において同一テーブルに記憶された複数の持株会についてのデータの中から、持株会コード等を用いて１つの持株会についてのデータを抽出することで持株会毎にまとめられたバックアップデータを作成し、これをバックアップデータ記憶部３２に記憶させる。これにより、持株会属性記憶部２２では複数の持株会についてのデータを同一のテーブルに記憶させながら、持株会毎に遡及処理を行うことを可能とする。

図３を参照してバックアップ処理の具体例を示す。バックアップ実行部３４は、会属性テーブル６４、会員属性テーブル６６、注文明細テーブル６８、約定明細テーブル７０、帳票属性テーブル７２については、その持株会コードごとのコピーデータを作成する。例えば、２００８年１２月の持株会Ａの持株会属性、２００８年１２月の持株会Ｂの持株会属性、２００９年１月の持株会Ａの持株会属性・・・のように区別されたコピーデータを作成する。持株会コードをキーとしない、企業属性テーブル６０、銘柄情報テーブル６２については、各持株会のバックアップデータとは別に持株会共通のコピーデータとして作成されてもよい。また、各持株会のバックアップデータのそれぞれに、これらのコピーデータが含まれてもよい。

属性情報修正部３６は、誤りのある持株会属性に対する修正処理を実行する。典型的には、過去時点において持株会属性に対する誤った更新要求が受け付けられて持株会属性に反映された結果、誤りのある持株会属性が生じている。したがって、属性情報修正部３６は、誤った更新要求が受け付けられる前の持株会属性のバックアップデータを、その誤りが修正された更新要求のデータ（以下、適宜「修正データ」とも呼ぶ。）にしたがって更新する。これにより、その誤りが修正された持株会属性（以下、適宜「新たな持株会属性」とも呼ぶ。）のデータを設定する。

例えば、新規会員の加入が持株会属性に反映されていなかった場合、更新属性を「会員属性追加」とし、その新規会員の会員属性を更新データとする更新要求が過去のある時点で行われたことにする修正要求に対応した修正データが設定される。また例えば、会員の拠出金額を５千円から２万円に変更すべきところ、誤った更新要求によって５千円から１万円に変更されていた場合、既存の更新要求における更新データを「拠出金額＝２万円」と変更する修正要求に対応した修正データが設定される。

属性情報修正部３６は、修正要求受付部３８と、修正情報受付部４０と、修正状態通知部４２と、バックアップデータ取得部４４と、修正属性記憶部４６と、修正実行部４８と、修正属性反映部５０とを含む。修正属性記憶部４６は、修正対象となる持株会属性を一時的に保持する記憶領域である。修正属性記憶部４６は、持株会属性記憶部２２において持株会属性が保持されたテーブルとは異なるテーブルにおいて、修正対象となる持株会属性を記憶する。具体的には、バックアップ実行部３４により作成され持株会単位でまとめられバックアップデータ記憶部３２に保持されたバックアップデータを取得し、これをコピーして作成されるファイルを修正対象として保持する。

修正要求受付部３８は、新たな持株会属性の設定処理に対する各種指示をユーザ端末１０から受け付ける。例えば、持株会属性の修正を要求する旨のデータ（以下、適宜「修正要求」とも呼ぶ。）を受け付ける。この修正要求では、誤りを修正すべき持株会属性の持株会コードと、持株会属性に誤りが発生した年月日（以下、適宜「誤り発生日」とも呼ぶ。）と、持株会属性の修正処理を一時的に中断すべき過去時点（以下、適宜「中断時点」とも呼ぶ。）とが指定される。この中断時点は複数個指定されてもよく、例えば毎月末が中断時点として設定されてもよい。

また、修正要求受付部３８は、修正要求を受け付けた際、その修正要求で指定された持株会コードを更新要求受付部２４に通知する。これにより、その持株会コードで特定される持株会属性に対する更新要求の受付制限を開始させる。

修正情報受付部４０は、誤りのあった更新要求を特定する修正データをユーザ端末１０から受け付ける。例えば、修正要求で指定された持株会コードを含む更新要求を、更新要求記憶部２６から取得してユーザ端末１０に提供し、更新要求ＩＤの指定を含むことで修正対象を特定する修正データをユーザ端末１０から受け付ける。

修正状態通知部４２は、新たな持株会属性の設定に際して、その状態を適宜ユーザ端末１０に通知する。例えば、新たな持株会属性が中断時点の状態となった場合、その状態の持株会属性をユーザ端末１０に通知する。また、新たな持株会属性が所定の異常状態となった場合、その旨およびその状態の持株会属性をユーザ端末１０に通知する。

バックアップデータ取得部４４は、まず、バックアップデータ記憶部３２を参照して、修正要求において指定された持株会コードで特定され持株会単位とされたバックアップデータを特定する。そして、そのデータのうち、修正要求において指定された誤り発生日の直前に生成されたデータをコピーしてバックアップデータ記憶部３２から取得し、「修正基礎データ」として修正属性記憶部４６に記憶させる。例えば、毎月末にバックアップデータが作成され、誤り発生日が１２月１５日である場合、１１月３０日に生成されたバックアップデータのコピーが修正基礎データとして修正属性記憶部４６に記録される。

修正実行部４８は、更新要求記憶部２６を参照して、修正要求において指定された持株会コードで特定される更新要求であって、修正基礎データのバックアップ時点よりも後に受け付けられた更新要求を「設定対象データ」として取得する。修正実行部４８は、基本的には持株会処理実行部３０と同様の処理を実行する。すなわち、修正属性記憶部４６に記憶された修正基礎データを設定対象データにしたがって更新する。ここで、更新要求ＩＤが修正データと共通する設定対象データについては、修正データを適用して修正基礎データを更新する。

また、修正実行部４８は、設定対象データおよび修正データにしたがって新たな持株会属性を設定中に、その持株会属性が中断時点の状態となったことを検出すると、新たな持株会属性の設定処理を一時中断する。例えば、中断時点が１月３１日である場合、１月３１日に受け付けられた設定対象データを全て新たな持株会属性に設定した時点で、その設定処理を一時中断してもよい。修正実行部４８は、中断時点の持株会属性の状態を、修正状態通知部４２を介して、ユーザ端末１０に通知する。修正要求受付部３８において新たな持株会属性の設定を再開すべき旨の指示がユーザ端末１０から受け付けられると、修正実行部４８は新たな持株会属性の設定を再開する。

また、修正実行部４８は、新たな持株会属性を設定中に、その持株会属性の状態が所定の異常状態となったことを検出すると、新たな持株会属性の設定処理を中止する。そして、その異常状態を示すデータと、設定中止時点の持株会属性の状態とを、修正状態通知部４２を介して、ユーザ端末１０に通知する。この場合、修正データに誤りが含まれると考えられるため、ユーザ側にて修正データの誤りが訂正されて、ユーザ端末１０から修正要求および修正データが再度送信される。この場合、新たな持株会属性の設定処理をはじめからやり直す。

なお、持株会属性についての所定の異常状態とは、持株会の各種属性として通常時にはあり得ないと想定される値が持株会属性に設定された状態を意味する。例えば、各テーブルにおける株式数や金額等の数値がマイナスとなること、または、各種属性に対して予め定められた所定の値範囲外となることでもよい。

また、修正実行部４８は、新たな持株会属性の設定において、その持株会属性に応じたバッチ処理を実行する。なお、修正実行部４８において実行されるバッチ処理は、上述した持株会処理実行部３０とは異なり、取引所装置１４との通信処理に係るバッチ処理は実行されず、持株会属性の設定および帳票作成処理に係るバッチ処理が実行される。したがって、上に例示したバッチ処理のうち修正実行部４８において実行されるバッチ処理は、（１）注文明細レコード設定処理、（４）株式配分処理、（５）帳票出力処理となる。修正データによって例えば会員の拠出金額が変更された場合には、注文明細レコードにおける注文株数、約定明細レコードにおける約定株数、会員属性における持株数も変更されるため、これらの処理における出力内容も修正データに応じて変更される。

なお、既述したように取引所装置１４との間で実際の通信は実行されないため、（１）注文明細レコードの設定処理において、その注文株数を修正データに応じて変更しなくてもよい。また、図４の第３の更新要求レコード８４が示す約定情報について、その約定株数を変更すべき場合には、本来の注文株数を約定株数として設定すればよい。この約定情報の変更、例えば第３の更新要求レコード８４の変更は、修正データを設定するユーザにより実施されてもよい。また、修正実行部４８が本来の注文株数を約定株数として設定することにより実施してもよい。

また、修正実行部４８は、特定の日時に実行されたバッチ処理について、新たな持株会属性がその日時の状態を示すことを条件として実行する。例えば、ある過去日の２２時に実行されたバッチ処理については、その日の２２時より前に受け付けられた設定対象データにしたがって新たな持株会属性に更新後、２２時より後に受け付けられた設定対象データにしたがって新たな持株会属性を更新する前に、そのバッチ処理を実行する。なお、修正実行部４８は、バッチ処理を実行すべき日時データを、そのバッチ処理に予め設定された実行条件から取得してもよく、実際の実行日時が記録された所定のログファイルを参照して取得してもよい。

また、修正実行部４８は、持株会属性がバッチ処理を実行すべき日時の状態であっても、その時点での持株会属性の内容がバッチ処理の実行条件を充足しない場合、バッチ処理を実行しない。例えば、会属性テーブル６４の入金フラグが入金無しの状態を示す場合、（１）注文明細レコード設定処理は実行しない。また、約定明細テーブル７０の約定株数が更新されていない場合、（４）株式配分処理は実行しない。

また、修正実行部４８は、新たな持株会属性の設定処理が終了すると、その時点の持株会属性の状態を、修正状態通知部４２を介して、ユーザ端末１０に通知する。その持株会属性の状態を了承する旨の通知を、修正要求受付部３８を介して、ユーザ端末１０から取得すると、新たな持株会属性を持株会属性記憶部２２およびバックアップデータ記憶部３２に反映させるための持株会属性更新指示を修正属性反映部５０に対して送出する。

修正属性反映部５０は、持株会属性更新指示を修正実行部４８から受け付けると、修正属性記憶部４６に記憶された新たな持株会属性を持株会属性記憶部２２およびバックアップデータ記憶部３２に反映する。具体的には、持株会属性記憶部２２に記憶された持株会属性のうち、更新要求において指定された持株会コードが設定された各レコードを新たな持株会属性で更新する。なお、持株会コードをキーとしない、企業属性テーブル６０・銘柄情報テーブル６２のデータが変更された場合、持株会属性記憶部２２の企業属性テーブル６０・銘柄情報テーブル６２における同一の企業コード・銘柄コードのデータを上書き更新する。また、バックアップデータ記憶部３２については、新たな持株会属性を作成するためのコピー元となったバックアップデータを、新たな持株会属性と入れ替える。

また、修正属性反映部５０は、新たな持株会属性を持株会属性記憶部２２およびバックアップデータ記憶部３２に反映後、修正要求で指定された持株会コードを更新要求受付部２４に通知する。これにより、その持株会コードで特定される持株会属性に対する更新要求の受付制限を解除させる。

なお、図２には図示しないが、持株会管理装置２０は、持株会属性記憶部２２に記憶された持株会属性の参照要求をユーザ端末１０から受け付ける参照要求受付部をさらに有する。また、その参照要求により指定された持株会属性を持株会属性記憶部２２から取得してユーザ端末１０に送信する持株会属性提供部をさらに有する。

以上の構成による動作を以下説明する。
図５は、持株会管理装置２０の動作を示すフローチャートである。修正要求受付部３８は、持株会属性の修正要求をユーザ端末１０から受け付ける（Ｓ１０）。修正要求受付部３８は修正要求の受付を更新要求受付部２４に通知し、更新要求受付部２４は修正対象の持株会属性に対する更新要求の受付制限を開始する（Ｓ１２）。修正情報受付部４０は、誤った更新要求に対する修正データを受け付ける（Ｓ１４）。バックアップデータ取得部４４は、バックアップデータ記憶部３２を参照して、修正対象の持株会属性のバックアップデータであって、誤り発生日よりも前に生成されたバックアップデータを特定する。そして、持株会属性記憶部２２およびバックアップデータ記憶部３２において持株会属性が保持された正系テーブルとは異なるテーブルであって、修正属性記憶部４６において修正対象の持株会属性を一時的に保持する副系テーブルに、そのバックアップデータをコピーしてリストアする（Ｓ１６）。

修正実行部４８は、更新要求記憶部２６を参照して、副系テーブルにリストアされたバックアップデータの生成時点よりも後に受け付けられた更新データを設定対象データとして取得する（Ｓ１８）。修正実行部４８は、後述する副系テーブル更新処理を実行する（Ｓ２０）。修正実行部４８は、副系テーブル更新処理後の持株会属性をユーザに通知する。その持株会属性がユーザに了承されると（Ｓ２２のＹ）、修正属性反映部５０は副系テーブルの持株会属性を正系テーブルに反映する（Ｓ２４）。副系テーブル更新処理後の持株会属性がユーザに了承されなければ（Ｓ２２のＮ）、Ｓ２４はスキップされる。修正属性反映部５０は持株会属性の修正完了を更新要求受付部２４に通知し、更新要求受付部２４は修正対象であった持株会属性に対する更新要求の受付制限を解除する（Ｓ２６）。

図６は、図５のＳ２０の詳細を示すフローチャートである。まず、副系テーブルにリストアされたバックアップデータが生成された過去日から現在日までの日次処理ループが開始される（Ｓ３０）。修正実行部４８は、新たな持株会属性の状態が示す過去時点である処理対象日において実行されたバッチ処理を特定し、そのバッチ処理の実行前に受け付けられた設定対象データを新たな持株会属性に設定する（Ｓ３２）。その設定後の新たな持株会属性の状態がバッチ処理の実行条件を充足するとき（Ｓ３４のＹ）、修正実行部４８はバッチ処理を実行する（Ｓ３６）。バッチ処理の実行条件が充足されなければ（Ｓ３４のＮ）、Ｓ３６はスキップされる。そして修正実行部４８は、バッチ処理の実行後に受け付けられた設定対象データを新たな持株会属性に設定する（Ｓ３８）。なお、Ｓ３２およびＳ３４において特定の設定対象データに対する修正データがユーザ端末１０から受け付けられていた場合、その設定対象データに代えて修正データを新たな持株会属性に設定する。

修正実行部４８は、新たな持株会属性の状態に対応する処理対象日が、修正要求にて指定された中断時点であるとき（Ｓ４０のＹ）、新たな持株会属性の設定処理を中断し、中断時点の持株会属性をユーザに通知する（Ｓ４２）。その持株会属性がユーザに了承されると（Ｓ４４のＹ）、修正実行部４８は、新たな持株会属性の処理対象日を１日進めて日次処理ループを繰り返す。この日次処理ループは、新たな持株会属性の処理対象日が現在日となり、その日の新たな持株会属性の設定処理が完了した時点で終了する。新たな持株会属性の状態に対応する処理対象日が、修正要求にて指定された中断時点でなければ（Ｓ４０のＮ）、Ｓ４２およびＳ４４はスキップされる。中断時点の持株会属性がユーザに了承されなければ（Ｓ４４のＮ）、新たな持株会属性の設定処理は中止される。すなわち、日次処理ループを抜け、図５におけるＳ２２のＮと同様に処理される。

以上説明した持株会管理装置２０によれば、過去時点で受け付けられた誤った更新要求や、過去時点でシステムに混入したバグに起因して持株会属性に生じている誤りを、人に負担を課すことなく迅速に修正できる。例えば、誤り範囲が持株会属性の広範囲に亘る場合でも、ユーザはその原因となった更新要求のみを修正することで、持株会属性全体を正しい状態に修正でき、ユーザの利便性が向上する。

また、持株会管理装置２０によれば、現在時点の持株会属性を修正するだけでなく、持株会属性の状態を過去時点から一貫して正しい状態に修正できるため、内容が修正された帳票を迅速に作成できる。また、バックアップデータ記憶部３２および更新要求記憶部２６に対して十分な記憶容量を割り当てることで、数年レベルで過去に遡り、その過去時点からの持株会属性の状態を一貫して正しい状態に修正できる。

さらに、持株会管理装置２０によれば、ユーザから指定された中断時点において持株会属性の修正を一時的に中断してその時点の持株会属性をユーザに提供する。そして、ユーザの了承を得た上で持株会属性の修正を再開する。これにより、ユーザは修正途中での持株会属性の状態を確認できる。例えば、複数の過去日においてそれぞれ入力された更新要求に誤りが含まれ、複数の修正データが入力される場合、修正途中でのユーザ確認が実現されることにより、複数の修正データそれぞれの正誤の確認が容易になる。

さらにまた、持株会管理装置２０によれば、持株会属性の修正中にその持株会属性が所定の異常状態となった場合、その修正処理を中止して、その異常状態をユーザに通知する。処理が途中で中止されるため、ユーザに対して迅速な異常通知がなされ、ユーザによる修正データの早期訂正を支援できる。

さらにまた、持株会管理装置２０によれば、互いに異なる複数の持株会それぞれに関する持株会属性が、異なる持株会コードと対応づけられて、同一のテーブルにおいて保持される。これにより、持株会管理装置２０での管理対象として新たな持株会が追加された場合でも、新たな持株会の属性を示すレコードを既存テーブルに追加することで容易に対応できる。言い換えれば、管理対象が追加されても、データベースインスタンスの追加や、持株会属性記憶部２２におけるテーブル構成の変更は不要であるため、システムリソースの消費量および追加工数を低減できる。

さらにまた、持株会管理装置２０によれば、修正対象の持株会属性が展開され、新たな持株会属性が設定されるテーブルは、修正対象外の持株会属性が保持されるテーブルと異なる。これにより、修正対象の持株会についての新たな持株会属性の設定処理が、修正対象外の持株会へ与える影響を排除できる。例えば、新たな持株会属性の設定処理中であっても、修正対象外の持株会属性に対する更新要求は通常どおり受け付けて、その更新要求にしたがって修正対象外の持株会属性を更新できる。また、新たな持株会属性の設定処理中は、修正対象の持株会属性に対する更新要求は拒否されるため、その持株会における持株会属性の整合性が維持される。また、持株会属性のバックアップデータは持株会ごとに保持され、その持株会属性に対する更新要求が設定対象データとして抽出されるため、新たな持株会属性を迅速に設定できる。

さらにまた、持株会管理装置２０によれば、過去時点の持株会属性に応じて実行されたバッチ処理についても、その実行日時に応じて、新たな持株会属性の設定に際して適宜実行される。これにより、ユーザ契機の更新要求のみならず、日時契機の処理も含めて、新たな持株会属性が設定され、新たな持株会属性を一層正確な内容で再構築できる。また、帳票出力処理等、日時基準の処理についても適宜実行できる。また、バッチ処理の実行に際し、そのバッチ処理の実行条件が充足されたか否かに応じて、そのバッチ処理の実行有無が決定される。これにより、不要なバッチ処理の実行は排除され、新たな持株会属性をさらに迅速に設定できる。このように、持株会管理装置２０は、それぞれが複数の顧客企業の持株会を管理する複数の証券会社に利用される場合において、同じ装置を利用する他の証券会社による当該装置を利用したサービス提供に支障をきたすことを回避しつつ、ある証券会社が担当する持株会の追加やその属性情報の変更を行うことが容易となる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。

第１の変形例を説明する。図３の企業属性テーブル６０および銘柄情報テーブル６２には、持株会コードがキーとして追加されてもよい。言い換えれば、持株会属性の全テーブルにおいて持株会コードが少なくとも１つのキーとして設定されてもよい。この変形例によれば、持株会属性のレコードはいずれも持株会ごとに異なるものとなるため、修正対象の持株会について企業属性テーブル６０および／または銘柄情報テーブル６２の情報が変更されても、修正対象外の持株会についての持株会属性には影響は及ばない。したがって、同一の企業コードおよび／または同一の銘柄コードが設定される異なる持株会、例えば同一企業における従業員持株会と役員持株会とについても、それぞれ同時に新たな持株会属性を設定できる。

第２の変形例を説明する。上述の実施の形態ではユーザ契機の更新要求について記載したが、変形例においてはシステム契機の更新要求を受け付けて持株会属性を適宜更新してもよい。例えば、実施の形態では、取引所装置１４から送信された約定データをユーザ端末１０に通知して、ユーザ端末１０からの更新要求として受け付けた。変形例においては、取引所装置１４から送信された約定データを直接更新要求として受け付けて、約定明細テーブル７０を更新してもよい。

第３の変形例を説明する。上述の実施の形態において、（１）注文明細レコード設定処理等の処理は、持株会属性がバッチ処理を実行すべき日時の状態であっても、その時点での持株会属性の内容がバッチ処理の実行条件を充足しない場合、実行されなかった。変形例において、これらの処理は、持株会属性がバッチ処理を実行すべき日時の状態であっても、その時点以前に受け付けられた設定対象データまたは修正データの内容が実行条件を充足しない場合に実行されなくてもよい。例えば、「入金情報」の設定対象データが存在しない場合、（１）注文明細レコード設定処理は実行されなくてもよい。また、「約定情報」の設定対象データが存在しない場合、（４）株式配分処理は実行されなくてもよい。

第４の変形例を説明する。上述の実施の形態において、（１）注文明細レコード設定処理等は、特定の日時をトリガとするバッチ処理として実行された。変形例において、これらの処理は、対応する更新要求が受け付けられた際、遅滞なく実行されてもよい。言い換えれば、これらの処理は略リアルタイム処理として実行されてもよい。例えば、図４の第２の更新要求レコード８２で示したような「入金情報」の更新要求が受け付けられた際、持株会処理実行部３０は、会属性テーブル６４の入金フラグを更新するとともに、特定の日時となるのを待つことなく、（１）注文明細レコード設定処理を実行してもよい。修正実行部４８においても同様に、「入金情報」の更新要求を新たな持株会属性に設定するとともに、（１）注文明細レコード設定処理を実行してもよい。

第５の変形例を説明する。修正実行部４８は、新たな持株会属性を設定中、バックアップデータが過去生成された時点、例えば毎月末等の所定時点の設定処理が完了したことを契機として、修正属性記憶部４６に記憶された新たな持株会属性のコピーデータをスナップショットデータとして修正属性記憶部４６に記憶させてもよい。修正属性反映部５０は、新たな持株会属性をバックアップデータに反映する際、バックアップデータ記憶部３２に記憶された１以上のバックアップデータを、その持株会コードが共通し、かつ、その生成時点に対応する１以上のスナップショットデータとそれぞれ入れ替えてもよい。

第６の変形例を説明する。修正実行部４８は、新たな持株会属性を設定中、バックアップデータが過去生成された時点、例えば毎月末等の所定時点の設定処理を完了したことを契機として、バックアップデータの生成指示をバックアップ実行部３４に送出してもよい。バックアップ実行部３４は、バックアップデータの生成指示を受け付けると、修正属性記憶部４６に記憶された新たな持株会属性のコピーデータを生成する。バックアップ実行部３４は、バックアップデータ記憶部３２に記憶されたバックアップデータのうち、新たな持株会属性を設定中の持株会コードで特定され、そのときの新たな持株会属性が示す時点に対応するバックアップデータに代えて、そのコピーデータをバックアップデータ記憶部３２に記憶させる。なお、バックアップ実行部３４は、新たな持株会属性のコピーデータをバックアップデータ記憶部３２のバックアップデータに即座に反映しなくてもよい。この場合、修正実行部４８は、持株会属性更新指示を修正属性反映部５０へ送出する際に、バックアップデータ更新指示をバックアップ実行部３４に送出する。バックアップ実行部３４は、バックアップデータ更新指示を受け付けたことを契機としてバックアップデータを更新してもよい。第５および第６の変形例によれば、バックアップデータ記憶部３２に記憶されたバックアップデータを、その生成時点の新たな持株会属性の状態を示すデータに更新できる。これにより、再度新たな持株会属性を設定する際、その前に設定された新たな持株会属性を修正基礎データとして活用できる。

第７の変形例を説明する。上述の実施の形態では、新たな持株会属性設定における中断時点はユーザにより設定された。変形例においては、ユーザによる設定に代えて、もしくは加えて、予め設定された所定の中断時点を修正実行部４８が検出したときに、新たな持株会属性の設定処理を一時的に中断してもよい。この中断時点は、新たな持株会属性の正誤をユーザが判定しやすいと想定される時点であることが好ましく、例えば、上述した（１）注文明細レコード設定処理、（４）株式配分処理、（５）帳票出力処理等、バッチ処理の実行直後であってもよく、過去時点における毎月末であってもよい。

第８の変形例を説明する。上述の実施の形態では、持株会を管理する持株会管理装置２０について説明したが、本発明の技術思想は持株会のみならず、会員の拠出金に基づいて定期的に商品を購入する様々な団体の管理に適用可能である。例えば、確定給付年金や確定拠出年金等の様々な形態の年金についてその加入者団体の管理、損害保険や生命保険等の様々な形態の保険についてその加入者団体の管理にも適用できる。

上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。

請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

２０ 持株会管理装置、 ２２ 持株会属性記憶部、 ２４ 更新要求受付部、 ２６ 更新要求記憶部、 ２８ ユーザ通知部、 ３０ 持株会処理実行部、 ３２ バックアップデータ記憶部、 ３４ バックアップ実行部、 ３６ 属性情報修正部、 ３８ 修正要求受付部、 ４０ 修正情報受付部、 ４２ 修正状態通知部、 ４４ バックアップデータ取得部、 ４６ 修正属性記憶部、 ４８ 修正実行部、 ５０ 修正属性反映部、 １００ 持株会システム。

Claims (8)

1. 会員の拠出金に基づいて定期的に商品を購入する団体のデータを管理する装置であって、
   前記団体に関する属性情報を記憶する団体属性記憶部と、
   ユーザから受け付けられた前記属性情報に対する更新要求にしたがって前記属性情報を更新する属性情報更新部と、
   前記ユーザから受け付けられた更新要求を逐次記憶する更新要求記憶部と、
   バックアップ処理により生成された前記属性情報のコピーデータを記憶するバックアップデータ記憶部と、
   過去時点における誤りに起因して前記属性情報に生じている誤りを修正すべき際、その過去時点より前に生成された前記属性情報のコピーデータを、そのコピーデータの生成時点より後に受け付けられた更新要求にしたがって更新することにより、前記団体に関する新たな属性情報を設定する属性情報修正部と、
   前記属性情報修正部における前記新たな属性情報の設定処理を一時的に中断させる時点であって、前記過去時点より後の過去時点を示す中断時点の指定を前記ユーザから受け付ける中断要求受付部と、
   属性情報提供部と、
   を備え、
   前記属性情報修正部は、前記新たな属性情報の設定中に、当該属性情報が前記中断時点の状態になった際、その設定を一時的に中断し、
   前記属性情報提供部は、前記中断時点の状態の属性情報を前記ユーザに提供することを特徴とする団体のデータ管理装置。
2. 前記団体属性記憶部は、互いに異なる複数の団体について、各団体に関する属性情報を同一の正系テーブルにおいて記憶し、
   前記属性情報修正部は、一の団体の属性情報に生じている誤りを修正すべき際、前記過去時点より前に生成された前記属性情報のコピーデータを前記正系テーブルとは異なる副系テーブルに展開して前記新たな属性情報を設定し、前記正系テーブルに記憶された当該団体の属性情報を、前記新たな属性情報における当該団体の属性情報によって更新することを特徴とする請求項１に記載の団体のデータ管理装置。
3. 前記バックアップデータ記憶部は、前記複数の団体それぞれの属性情報に対応する複数のコピーデータを記憶し、
   前記属性情報修正部は、前記一の団体の属性情報に生じている誤りを修正すべき際、前記過去時点より前に生成された当該団体の属性情報に対応するコピーデータを前記副系テーブルに展開して前記新たな属性情報を設定することを特徴とする請求項２に記載の団体のデータ管理装置。
4. 前記属性情報更新部は、前記属性情報修正部において前記新たな属性情報が設定されている間であっても、前記一の団体以外の属性情報に対する更新要求については、その更新要求にしたがって前記一の団体以外の属性情報を更新することを特徴とする請求項２または３に記載の団体のデータ管理装置。
5. 前記属性情報修正部は、前記過去時点において受け付けられた更新要求に誤りがあった場合、その過去時点より前に生成された前記属性情報のコピーデータを、そのコピーデータの生成時点より後に受け付けられた更新要求であって、その誤りが修正された更新要求にしたがって更新することを特徴とする請求項１から４のいずれかに記載の団体のデータ管理装置。
6. 異常状態通知部をさらに備え、
   前記属性情報修正部は、前記新たな属性情報の設定中に、当該属性情報が所定の異常状態になった際、その設定を中止し、
   前記異常状態通知部は、当該属性情報が異常状態となったことを前記ユーザに通知することを特徴とする請求項１から５のいずれかに記載の団体のデータ管理装置。
7. 前記更新要求記憶部は、前記更新要求が受け付けられた日時を前記更新要求に対応づけてさらに記憶し、
   前記属性情報修正部は、所定の過去時点になったことを契機に前記属性情報に応じて実行された所定のデータ処理について、当該過去時点より前に受け付けられた更新要求にしたがって前記新たな属性情報を設定した後、当該過去時点より後に受け付けられた更新要求にしたがって前記新たな属性情報を設定する前に、前記新たな属性情報に応じて前記所定のデータ処理を実行することを特徴とする請求項１から６のいずれかに記載の団体のデータ管理装置。
8. 前記所定のデータ処理には、その実行条件が対応づけられており、
   前記属性情報修正部は、前記過去時点より前に受け付けられた更新要求、または、前記新たな属性情報の前記過去時点の状態が当該実行条件を充足するとき、前記新たな属性情報に応じて前記所定のデータ処理を実行することを特徴とする請求項７に記載の団体のデータ管理装置。

Images