JPH08115373A - 分散システムにおける通知方式 - Google Patents

Abstract

(57)【要約】 【構成】図１を用いて示す。本計算機システムは、口座
番号ごとに取引明細を蓄積する取引明細蓄積手段１０、
上記口座番号を所有する取引先に対応するキューを挿入
する通知キュー挿入手段２０、上記キューを取り出して
取引内容を取引先へ送信する取引通知手段３０、取引先
の通知承認要求メッセージを他ＣＰＵへ送信する取引通
知承認要求手段４０、他ＣＰＵからの通知承認要求メッ
セージを受信して該当する取引先の取引内容をまとめる
取引通知連携手段５０とからなる。 【効果】口座番号ごとに取引明細を蓄積した取引明細蓄
積ファイルの店群という切り口で通知処理を並列化した
とき、複数の店群に口座をもつ取引先への通知が少しず
つ頻繁に行われることを防ぐことができ、効率的な通信
ができると同時に、通知を受け取る取引先の労力や資源
の浪費を防ぐことができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、金融機関における取引
内容を取引先へ通知する方法および装置に係り、例えば
ファックスを通して給与振込み状況を通知する勘定系の
サブシステム並びにそれに好適な通知方式に関する。

【０００２】

【従来の技術】本発明に関連する公知例として、日立製
作所のアプリケーションプログラムプロダクト「ＥＢ−
２１システム（外部接続システム）」が挙げられる。こ
のシステムは、取引明細蓄積ファイルを店群ごとに別ボ
リュームとし、通知キューを取引先の地区ごとに別とし
て、１つのＣＰＵが一括管理している。

【０００３】

【発明が解決しようとする課題】前記公知例に対して、
取引明細蓄積ファイルのボリュームごとに別ＣＰＵを割
り当てることにより通知能力を向上することを考える。
このとき、取引先をＣＰＵにくくりつける、つまり各取
引先に対して通知するＣＰＵを１つ予め決めておく方法
がある。並列システムを構築する際、各ＣＰＵの構成要
素をできるだけ同一にするという観点からすると、前記
の方法は各ＣＰＵ別に取引先情報という要素が入り込む
分、好ましくない。そこで、取引先をＣＰＵにくくりつ
けない方法を考えると、以下の問題がある。

【０００４】各ＣＰＵが全取引先に対する通知キューを
独自に管理するため、複数の店群に口座を所有する取引
先に対しては各ＣＰＵがばらばらに通知を行うことにな
り、通知をする側の通信効率が悪いと同時に、受け取る
取引先も労力の浪費、および紙などの資源の浪費という
点で迷惑する。

【０００５】各ＣＰＵが連携することにより各取引先に
対して必ず一括通知する場合、連携によるオーバーヘッ
ドのため、緊急を要する通知が遅延する恐れがある。

【０００６】特定の店群に対する通知処理が集中した場
合、それに対応するＣＰＵに負荷が集中し、並列化によ
る処理能力の向上ができない。

【０００７】

【課題を解決するための手段】図１を用いて示す。本計
算機システムは、口座番号ごとに取引明細を蓄積する取
引明細蓄積手段１０、上記口座番号を所有する取引先に
対応するキューを挿入する通知キュー挿入手段２０、上
記キューを取り出して取引内容を取引先へ送信する取引
通知手段３０、取引先の通知承認要求メッセージを他通
知手段へ送信する取引通知承認要求手段４０、他通知手
段からの通知承認要求メッセージを受信して該当する取
引先の取引内容をまとめる取引通知連携手段５０とから
なる。

【０００８】図２を用いて示す。本計算機システムは、
上記の取引明細蓄積手段１０、通知キュー挿入手段２０
および取引通知手段３０に加えて、一括管理サーバーか
ら各通知手段へキューを振り分けるキュー振り分け手段
６０とからなる。

【０００９】図３を用いて示す。本計算機システムは、
上記の取引明細蓄積手段１０、通知キュー挿入手段２
０、取引通知手段３０、取引通知承認要求手段４０、お
よび取引通知連携手段５０に加えて、取引先の契約内容
に従い他通知手段と連携するか否かを決定する契約者管
理手段７０とからなる。

【００１０】図４を用いて示す。本計算機システムは、
上記の取引明細蓄積手段１０、通知キュー挿入手段２
０、取引通知手段３０、取引通知承認要求手段４０、取
引通知連携手段５０、および契約者管理手段７０に加え
て、全通知手段の通知キュー情報を保持しておく負荷平
滑手段８０とからなる。

【００１１】図５を用いて示す。本計算機システムは、
上記の取引明細蓄積手段１０、通知キュー挿入手段２
０、取引通知手段３０、およびキュー振り分け手段６０
に加えて、全通知手段の通知キュー情報を保持しておく
一括管理サーバー内の負荷平滑手段９０、および各通知
手段が自分の保有する通知キュー情報を管理する負荷平
滑手段１００とからなる。

【００１２】

【作用】図６のフローチャートを用いて示す。まず取引
明細蓄積手段１０を用いて他システムから取得した取引
明細を口座番号順に蓄積しておく（ステップ１００
０）。通知キュー挿入手段２０は前記口座番号順の蓄積
内容を参照して取引先ごとに通知キューを作成する（ス
テップ２０００）。取引通知手段３０は前記通知キュー
が空でなければ（ステップ３０００）、先頭から１つ取
り出し（ステップ３５００）、取引先へ通知する（ステ
ップ８０００）前に、他の通知手段に前記取引先の通知
キューが存在するか否かを調べるため、取引通知承認要
求手段４０を用いて他の通知手段へ問い合わせる（ステ
ップ４０００）。すると他の通知手段における取引通知
連携手段５０がそれを受取り（ステップ５０００）、前
記取引先に対する通知の予定があれば（ステップ６００
０）、取引明細蓄積手段１０によって格納された取引内
容を前記取引通知承認要求手段４０へ転送し（ステップ
６５００）、通知キューから削除する（ステップ６７０
０）。取引通知承認要求手段４０が他の通知手段の取引
内容を受信すると（ステップ７０００）、取引通知手段
３０は、自分が保持する取引内容と合わせて、取引先へ
一括通知する（ステップ８０００）。

【００１３】図７のフローチャートを用いて示す。まず
一括管理サーバー内の取引明細蓄積手段１０を用いて他
システムから取得した取引明細を口座番号順に蓄積して
おく（ステップ１００）。一括管理サーバー内の通知キ
ュー挿入手段２０は前記口座番号順の蓄積内容を参照し
て取引先ごとに通知キューを作成する（ステップ２０
０）。キュー振り分け手段６０は前記通知キューが空で
なければ（ステップ３００）、先頭から１つずつ取り出
し（ステップ３５０）、通知手段の中から１つを選び
（ステップ４００）、前記選択された通知手段へ取引内
容を送信する（ステップ５００）。取引内容を受信した
通知手段は、取引明細蓄積手段１０を用いてその内容を
口座番号ごとに蓄積し（ステップ１０００）、さらに通
知キュー挿入手段２０を用いて取引先ごとに通知キュー
を作成する（ステップ２０００）。取引通知手段３０は
前記通知キューが空でなければ（ステップ３０００）先
頭から１つ取り出し（ステップ３５００）、取引先ごと
に一括して通知する（ステップ８０００）。

【００１４】図８のフローチャートを用いて示す。取引
明細蓄積手段１０を用いて他システムから取得した取引
明細を口座番号順に蓄積しておき（ステップ１００
０）、通知キュー挿入手段２０を用いて前記口座番号順
の蓄積内容を参照して取引先ごとに通知キューを作成し
（ステップ２０００）、取引通知手段３０を用いて前記
通知キューが空でなければ（ステップ３０００）、先頭
から１つ取り出す（ステップ３５００）までは請求項１
における作用と同様。ここで、契約者管理手段７０を用
いて前記取引先に対する契約状況を参照し、取引発生後
即時に通知するという契約者でなければ（ステップ３７
００）、前記請求項１における作用と同様の操作を行
う。すなわち、他の通知手段に前記取引先の通知キュー
が存在するか否かを調べるため、取引通知承認要求手段
４０を用いて他の通知手段へ問い合わせ（ステップ４０
００）、他の通知手段における取引通知連携手段５０が
それを受取り（ステップ５０００）、前記取引先に対す
る通知の予定があれば（ステップ６０００）、取引明細
蓄積手段１０によって格納された取引内容を前記取引通
知承認要求手段４０へ転送し（ステップ６５００）、通
知キューから削除し（ステップ６７００）、取引通知承
認要求手段４０が他の通知手段の取引内容を受信すると
（ステップ７０００）、取引通知手段３０は、自分が保
持する取引内容と合わせて、取引先へ一括通知する（ス
テップ８０００）。一方、取引発生後即時に通知すると
いう契約者であったときには（ステップ３７００）、他
の通知手段と連携すること無く即座に取引先へ通知する
（ステップ８０００）。

【００１５】図９のフローチャートを用いて示す。まず
取引明細蓄積手段１０を用いて他システムから取得した
取引明細を口座番号順に蓄積しておく（ステップ１００
０）。通知キュー挿入手段２０は前記口座番号順の蓄積
内容を参照して取引先ごとに通知キューを作成するが
（ステップ２０００）、ここでさらに負荷平滑手段８０
を用いて通知キュー情報も生成、あるいは更新しておく
（ステップ２５００）。取引通知手段３０は前記通知キ
ューが空でなければ（ステップ３０００）、先頭から１
つ取り出し（ステップ３５００）、契約者管理手段７０
を用いて前記取引先に対する契約状況を参照し、取引発
生後即時に通知するという契約者でなければ（ステップ
３７００）、他の通知手段に前記取引先の通知キューが
存在するか否かを調べるため、取引通知承認要求手段４
０を用いて他の通知手段へ問い合わせる（ステップ４０
００）。ここでさらに、負荷平滑手段８０を用いて前記
通知キュー情報も送信しておく（ステップ４５００）。
他の通知手段における取引通知連携手段５０がそれを受
取り（ステップ５０００）、前記取引先に対する通知の
予定があれば（ステップ６０００）、取引明細蓄積手段
１０によって格納された取引内容を前記取引通知承認要
求手段４０へ転送するが（ステップ６５００）、ここで
負荷平滑手段８０により自分の保持する通知キュー情報
を考慮し、先に受信した情報と比較し、自分の負荷が高
いと判断したときは（ステップ６６００）、通知キュー
の一部とそれに対応する取引内容も転送し（６６５
０）、通知キューから削除する（ステップ６７００）。
取引通知承認要求手段４０が他の通知手段の取引内容を
受信すると（ステップ７０００）、取引通知手段３０
は、自分が保持する取引内容と合わせて、取引先へ一括
通知する（ステップ８０００）と同時に、受信した通知
キューとそれに対応する取引内容を取引明細蓄積手段１
０を用いて蓄積する（ステップ８５００）。一方、取引
発生後即時に通知するという契約者であったときには
（ステップ３７００）、他の通知手段と連携すること無
く即座に取引先へ通知する（ステップ８０００）。

【００１６】図１０のフローチャートを用いて示す。ま
ず一括管理サーバー内の取引明細蓄積手段１０を用いて
他システムから取得した取引明細を口座番号順に蓄積し
ておく（ステップ１００）。一括管理サーバー内の通知
キュー挿入手段２０は前記口座番号順の蓄積内容を参照
して取引先ごとに通知キューを作成する（ステップ２０
０）。キュー振り分け手段６０は前記通知キューが空で
なければ（ステップ３００）、先頭から１つずつ取り出
し（ステップ３５０）、通知手段の中から１つを選び
（ステップ４００）、前記通知手段へ取引内容を送信す
る（ステップ５００）。取引内容を受信した通知手段
は、取引明細蓄積手段１０を用いてその内容を口座番号
ごとに蓄積し（ステップ１０００）、さらに通知キュー
挿入手段２０を用いて取引先ごとに通知キューを作成す
る（ステップ２０００）。ここで、負荷平滑手段１００
を用いて自分が保持する通知キュー情報を生成、あるい
は更新し（ステップ２３００）、さらに一括管理サーバ
ーへ前記情報を送信しておく（２６００）。前記情報を
受信したキュー振り分け手段６０は、負荷平滑手段９０
を用いて前記通知手段の通知キュー情報を更新し（ステ
ップ６００）、次回の選択（ステップ４００）における
判断材料とする。通知手段内の取引通知手段３０は前記
通知キューが空でなければ（ステップ３０００）、先頭
から１つ取り出し（ステップ３５００）、取引先ごとに
一括して通知し（ステップ８０００）、負荷平滑手段１
００を用いて通知キュー情報を更新する（ステップ９０
００）。

【００１７】

【実施例】図６および図１１を用いて示す。図１１は本
発明の１実施例を示すプロセス構成、およびファイル構
成である。勘定系システムから取引通知ＣＰＵへ口座番
号および取引内容を記述した取引明細１１が送られる
と、それを取引明細蓄積プロセス１２が受取り、口座番
号ごとに取引明細数および取引内容という形式で取引明
細蓄積ファイル１３へ格納する（ステップ１０００）。
さらに、図１２に示す顧客ＩＤ変換テーブル１４により
上記口座番号に対応する取引先を求め、該当する地区の
通知キューへ挿入する（ステップ２０００）。上記キュ
ーには図１３に示す通り、取引先および取引明細蓄積フ
ァイル１３上の格納位置という情報が保持されている。
取引通知プロセス３１は上記通知キューが空でなければ
（ステップ３０００）、先頭からキューを取り出し（ス
テップ３５００）、図１４に示す通知管理テーブル３２
を通知中と更新した後、他ＣＰＵの取引通知連携プロセ
ス５１へ上記取引先に対する取引通知承認要求メッセー
ジを送信する（ステップ４０００）。すると、他ＣＰＵ
の取引通知連携プロセス５１がそれを受取り（ステップ
５０００）、前記取引先に対する通知の予定があるか否
かを各自の通知キューによってチェックする。予定があ
るときは（ステップ６０００）、さらに通知管理テーブ
ル３２によって通知中か否かをチェックする。通知中で
ないときは、上記取引通知プロセス３１へ該当する取引
先の取引内容とともに取引通知承認メッセージとして送
信し（ステップ６５００）、通知キューを取り出して通
知管理テーブル３２を通知済と更新する（ステップ６７
００）。一方、通知中であるときは、上記取引通知プロ
セス３１に取引通知拒否メッセージを送信する。全ＣＰ
Ｕの取引通知連携プロセス５１から取引承認メッセージ
を受信した取引通知プロセス３１は（ステップ７００
０）、前記受信した取引内容と合わせて取引先へ一括通
知し（ステップ８０００）、通知管理テーブル３２を通
知済と更新する。取引通知拒否メッセージを１つでも受
け取った取引通知プロセス３１は、取引通知承認メッセ
ージを送信したＣＰＵ分の取引内容のみを一括通知し
（ステップ８０００）、通知管理テーブル３２を通知済
と更新する。以上の処理を繰り返し、通知キューが空に
なったところで、取引通知プロセス３１は一定時間休眠
する。休眠からさめた取引通知プロセス３１は、同様の
処理を行う。

【００１８】図７および図１５を用いて示す。図１５は
本発明の１実施例を示すプロセス構成、およびファイル
構成である。勘定系システムから一括管理サーバーＣＰ
Ｕへ口座番号および取引内容を記述した取引明細１１が
送られると、それを取引明細蓄積プロセス１２が受取
り、口座番号ごとに取引明細数および取引内容という形
式で取引明細蓄積ファイル１３へ格納する（ステップ１
００）。さらに、図１２に示す顧客ＩＤ変換テーブル１
４により上記口座番号に対応する取引先を求め、該当す
る地区の通知キューへ挿入する（ステップ２００）。上
記キューには図１３に示す通り、取引先および取引明細
蓄積ファイル１３上の格納位置という情報が保持されて
いる。キュー振り分けプロセス６１は上記通知キューが
空でなければ（ステップ３００）、先頭からキューを１
つ取り出し（ステップ３５０）、取引通知ＣＰＵ１〜ｍ
の中から１つを選択し（ステップ４００）、前記選択さ
れたＣＰＵ内の取引明細蓄積プロセス１２へ、前記通知
キューとそれに対応する取引内容を送信する（ステップ
５００）。一括管理サーバーＣＰＵから取引通知ＣＰＵ
へ口座番号および取引内容を記述した取引明細１１が送
られると、それを取引明細蓄積プロセス１２が受取り、
口座番号ごとに取引明細数および取引内容という形式で
取引明細一時蓄積ファイル１５へ格納する（ステップ１
０００）。さらに、図１２に示す顧客ＩＤ変換テーブル
１４により上記口座番号に対応する取引先を求め、該当
する地区の通知キューへ挿入する（ステップ２００
０）。上記キューには図１３に示す通り、取引先および
取引明細一時蓄積ファイル１５上の格納位置という情報
が保持されている。取引通知プロセス３１は上記通知キ
ューが空でなければ（ステップ３０００）、先頭からキ
ューを取り出し（ステップ３５００）、取引先へ通知す
る（ステップ８０００）。この場合、一括管理ＣＰＵが
各取引先に対する取引内容をまとめているので、取引通
知ＣＰＵ同志の連携は必要ない。

【００１９】図８および図１６を用いて示す。図１６は
本発明の１実施例を示すプロセス構成、およびファイル
構成である。勘定系システムから取引通知ＣＰＵへ口座
番号および取引内容を記述した取引明細１１が送られる
と、それを取引明細蓄積プロセス１２が受取り、口座番
号ごとに取引明細数および取引内容という形式で取引明
細蓄積ファイル１３へ格納する（ステップ１０００）。
さらに、図１２に示す顧客ＩＤ変換テーブル１４により
上記口座番号に対応する取引先を求め、該当する地区の
通知キューへ挿入する（ステップ２０００）。上記キュ
ーには図１３に示す通り、取引先および取引明細蓄積フ
ァイル１３上の格納位置という情報が保持されている。
取引通知プロセス３１は上記通知キューが空でなければ
（ステップ３０００）、先頭からキューを取り出す（ス
テップ３５００）。ここで、図１７に示す契約管理テー
ブル７１を参照し、前記キューに対応する取引先に対す
る契約が取引発生後即時に通知という契約であれば（ス
テップ３７００）、取引先へ通知する（ステップ８００
０）。上記以外の契約であれば、図１４に示す通知管理
テーブル３２を通知中と更新した後、他ＣＰＵの取引通
知連携プロセス５１へ上記取引先に対する取引通知承認
要求メッセージを送信する（ステップ４０００）。する
と、他ＣＰＵの取引通知連携プロセス５１がそれを受取
り（ステップ５０００）、前記取引先に対する通知の予
定があるか否かを各自の通知キューによってチェックす
る。予定があるときは（ステップ６０００）、さらに通
知管理テーブル３２によって通知中か否かをチェックす
る。通知中でないときは、上記取引通知プロセス３１へ
該当する取引先の取引内容とともに取引通知承認メッセ
ージとして送信し（ステップ６５００）、通知キューを
取り出して通知管理テーブル３２を通知済と更新する
（ステップ６７００）。一方、通知中であるときは、上
記取引通知プロセス３１に取引通知拒否メッセージを送
信する。全ＣＰＵの取引通知連携プロセス５１から取引
承認メッセージを受信した取引通知プロセス３１は（ス
テップ７０００）、前記受信した取引内容と合わせて取
引先へ一括通知し（ステップ８０００）、通知管理テー
ブルを通知済と更新する。取引通知拒否メッセージを１
つでも受け取った取引通知プロセス３１は、取引通知承
認メッセージを送信したＣＰＵ分の取引内容のみを一括
通知し（ステップ８０００）、通知管理テーブル３２を
通知済と更新する。以上の処理を繰り返し、通知キュー
が空になったところで、取引通知プロセス３１は一定時
間休眠する。休眠からさめた取引通知プロセス３１は、
同様の処理を行う。

【００２０】図９および図１８を用いて示す。図１８は
本発明の１実施例を示すプロセス構成、およびファイル
構成である。勘定系システムから取引通知ＣＰＵへ口座
番号および取引内容を記述した取引明細１１が送られる
と、それを取引明細蓄積プロセス１２が受取り、口座番
号ごとに取引明細数および取引内容という形式で取引明
細蓄積ファイル１３へ格納する（ステップ１０００）。
さらに、図１２に示す顧客ＩＤ変換テーブル１４により
上記口座番号に対応する取引先を求め、該当する地区の
通知キューへ挿入する（ステップ２０００）。上記キュ
ーには図１３に示す通り、取引先および取引明細蓄積フ
ァイル１３上の格納位置という情報が保持されている。
また、このとき自ＣＰＵが保有する通知キュー数をメモ
リ上にセットしておく。取引通知プロセス３１は上記通
知キューが空でなければ（ステップ３０００）、先頭か
らキューを取り出す（ステップ３５００）。ここで、図
１７に示す契約管理テーブル７１を参照し、前記キュー
に対応する取引先に対する契約が取引発生後即時に通知
という契約であれば（ステップ３７００）、取引先へ通
知する（ステップ８０００）。上記以外の契約であれ
ば、図１４に示す通知管理テーブル３２を通知中と更新
した後、他ＣＰＵの取引通知連携プロセス５１へ上記取
引先に対する取引通知承認要求メッセージを送信し（ス
テップ４０００）、さらに前記メモリ上にセットしてい
た通知キュー数を送信する（ステップ４５００）。する
と、他ＣＰＵの取引通知連携プロセス５１がそれを受取
り（ステップ５０００）、前記取引先に対する通知の予
定があるか否かを各自の通知キューによってチェックす
る。予定があるときは（ステップ６０００）、さらに通
知管理テーブル３２によって通知中か否かをチェックす
る。通知中でないときは、上記取引通知プロセス３１へ
該当する取引先の取引内容とともに取引通知承認メッセ
ージとして取引通知プロセスへ送信した後（ステップ６
５００）、前記受信した通知キュー数と自ＣＰＵ内のメ
モリ上にセットしてある通知キュー数を比較し、自ＣＰ
Ｕ内の通知キュー数が多ければ（ステップ６６００）、
その差のｎ分の１の通知キューとそれに対応する取引内
容を、取引明細蓄積プロセス１２へ送信する（ステップ
６６５０）。ただし、ｎは並列数（ここでは取引通知Ｃ
ＰＵ数）のことである。そして、前記通知キューを取り
出して通知管理テーブルを通知済と更新し、通知キュー
数もその分減らしておく（ステップ６７００）。一方、
通知中であるときは、上記取引通知プロセス３１に取引
通知拒否メッセージを送信する。全ＣＰＵの取引通知連
携プロセス５１から取引承認メッセージを受信した取引
通知プロセス３１は（ステップ７０００）、前記受信し
た取引内容と合わせて取引先へ一括通知し、メモリ上の
通知キュー数を１減らし、通知管理テーブル３２を通知
済と更新する（ステップ８０００）。取引通知拒否メッ
セージを１つでも受け取った取引通知プロセス３１は、
取引通知承認メッセージを送信したＣＰＵ分の取引内容
のみを一括通知し（ステップ８０００）、通知管理テー
ブル３２を通知済と更新する。また、他ＣＰＵから送信
された通知キューとそれに対応する取引内容を受信した
取引明細蓄積プロセス１２は、口座番号ごとに取引明細
数および取引内容という形式で取引明細蓄積ファイル１
３へ格納し、通知キュー数をその分増やしておく（ステ
ップ８５００）。以上の処理を繰り返し、通知キューが
空になったところで、取引通知プロセス３１は一定時間
休眠する。休眠からさめた取引通知プロセス３１は、同
様の処理を行う。

【００２１】図１０および図１９を用いて示す。図１９
は本発明の１実施例を示すプロセス構成、およびファイ
ル構成である。勘定系システムから一括管理サーバーＣ
ＰＵへ口座番号および取引内容を記述した取引明細１１
が送られると、それを取引明細蓄積プロセス１２が受取
り、口座番号ごとに取引明細数および取引内容という形
式で取引明細蓄積ファイル１３へ格納する（ステップ１
００）。さらに、図１２に示す顧客ＩＤ変換テーブル１
４により上記口座番号に対応する取引先を求め、該当す
る地区の通知キューへ挿入する（ステップ２００）。上
記キューには図１３に示す通り、取引先および取引明細
蓄積ファイル１３上の格納位置という情報が保持されて
いる。キュー振り分けプロセス６１は上記通知キューが
空でなければ（ステップ３００）、先頭からキューを取
り出し（ステップ３５０）、取引通知ＣＰＵ１〜ｍの中
から１つを選択し（ステップ４００）、前記ＣＰＵ内の
取引明細蓄積プロセス１２へ、前記通知キューとそれに
対応する取引内容を送信する（ステップ５００）。一括
管理サーバーＣＰＵから取引通知ＣＰＵへ口座番号およ
び取引内容を記述した取引明細１１が送られると、それ
を取引明細蓄積プロセス１２が受取り、口座番号ごとに
取引明細数および取引内容という形式で取引明細一時蓄
積ファイル１５へ格納する（ステップ１０００）。さら
に、図１２に示す顧客ＩＤ変換テーブル１４により上記
口座番号に対応する取引先を求め、該当する地区の通知
キューへ挿入する（ステップ２０００）。上記キューに
は図１３に示す通り、取引先および取引明細一時蓄積フ
ァイル１５上の格納位置という情報が保持されている。
また、このとき通知キュー数をメモリ上にセットし、前
記キュー振り分けプロセス６１へ送信しておく（ステッ
プ２６００）。取引通知プロセス３１は上記通知キュー
が空でなければ（ステップ３０００）、先頭からキュー
を取り出し（ステップ３５００）、取引先へ通知した後
（ステップ８０００）、通知キュー数を１減らす（ステ
ップ９０００）。前記通知キュー数を受信したキュー振
り分けプロセス６１は、送信元ＣＰＵの通知キュー数を
メモリにセットしておく。以上の処理を通知キューが空
になるまで繰り返すが、全取引通知ＣＰＵから１つ選択
するとき（ステップ４００）、最も通知キュー数の多い
ＣＰＵを選択することにより、取引通知ＣＰＵ間の負荷
を平滑化できる。

【００２２】

【発明の効果】口座番号ごとに取引明細を蓄積した取引
明細蓄積ファイルの店群という切り口で通知処理を並列
化したとき、複数の店群に口座をもつ取引先への通知が
少しずつ頻繁に行われることを防ぐことができ、効率的
な通信ができると同時に、通知を受け取る取引先の労力
や資源の浪費を防ぐことができる。

【００２３】請求項１および２の効果に加えて、取引先
の契約形態に応じた取引通知処理を行うことにより、緊
急を要する通知の遅延を防ぐことができる。

【００２４】ＣＰＵ間の負荷を平滑化することにより、
特定店群に口座を持つ取引先に対する通知の遅延を防ぐ
ことが出来る。

【図面の簡単な説明】

【図１】計算機システム構成図である。

【図２】計算機システム構成図である。

【図３】計算機システム構成図である。

【図４】計算機システム構成図である。

【図５】計算機システム構成図である。

【図６】作用を示すフローチャートである。

【図７】作用を示すフローチャートである。

【図８】作用を示すフローチャートである。

【図９】作用を示すフローチャートである。

【図１０】作用を示すフローチャートである。

【図１１】１実施例を示すファイル構成およびプロセス
構成である。

【図１２】顧客ＩＤ変換テーブルのフォーマットであ
る。

【図１３】通知キューのフォーマットである。

【図１４】通知管理テーブルのフォーマットである。

【図１５】１実施例を示すファイル構成およびプロセス
構成である。

【図１６】１実施例を示すファイル構成およびプロセス
構成である。

【図１７】契約管理テーブルのフォーマットである。

【図１８】１実施例を示すファイル構成およびプロセス
構成である。

【図１９】１実施例を示すファイル構成およびプロセス
構成である。

【符号の説明】

１０…取引明細蓄積手段、 １１…取引明細、
１２…取引明細蓄積プロセス、 １３…取引明細蓄
積ファイル、１４…顧客ＩＤ変換テーブル、 １５
…取引明細一時蓄積ファイル、２０…通知キュー挿入手
段、 ３０…取引通知手段、３１…取引通知プロ
セス、 ３２…通知管理テーブル、４０…取引
通知承認要求手段、 ５０…取引通知連携手段、５
１…取引通知連携プロセス、 ６０…キュー振り分
け手段、６１…キュー振り分けプロセス、 ７０…契
約者管理手段、７１…契約管理テーブル、 ８
０…負荷平滑手段、９０…負荷平滑手段、
１００…負荷平滑手段。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 下山 高寿 神奈川県川崎市幸区鹿島田890番地の12 株式会社日立製作所情報システム事業部内

Claims (5)

【特許請求の範囲】
1. 【請求項１】口座番号ごとに取引明細を蓄積した取引明
   細蓄積ファイルと、その取引内容を一定時間間隔で取引
   先ごとに通知する手段とからなる計算機システムにおい
   て、取引明細蓄積ファイルの店群ごとに通知手段を設け
   ることにより通知処理を並列化する際、複数の店群にま
   たがって口座を所有する取引先に対しては、上記通知手
   段同士が連携することにより、一括して通知することを
   特徴とする分散システムにおける通知方式。
2. 【請求項２】口座番号ごとに取引明細を蓄積した取引明
   細蓄積ファイルと、その取引内容を一定時間間隔で取引
   先ごとに通知する手段とからなる計算機システムにおい
   て、取引明細蓄積ファイルの店群ごとに通知手段を設け
   ることにより通知処理を並列化する際、取引明細蓄積フ
   ァイルおよび通知キューを一括管理するサーバーを設け
   て通知手段への通知キューの振り分けを行うことによ
   り、複数の店群にまたがって口座を所有する取引先に対
   して一括通知することを特徴とする分散システムにおけ
   る通知方式。
3. 【請求項３】請求項１記載の計算機システムにおいて、
   取引発生後即時に通知するという契約をしている取引先
   に対しては、前記通知手段間の連携を行わないことによ
   り、通知に時間のかかることを防ぐことを特徴とする分
   散システムにおける通知方式。
4. 【請求項４】請求項３記載の計算機システムにおいて通
   知手段同志が連携する際、相手方通知手段の保有する通
   知キュー情報を取得しておき、相手方通知手段の負荷が
   軽いと判断したときには通知キューとそれに対応する取
   引内容を相手方通知手段へ移動することにより、通知手
   段間の負荷を平滑化することを特徴とする分散システム
   の通知方式。
5. 【請求項５】請求項２記載の計算機システムにおいて一
   括管理サーバーが通知手段へ通知キューを振り分ける
   際、各通知手段の保有する通知キュー情報を取得してお
   き、負荷が軽いと判断された通知手段へ優先的に通知キ
   ューを振り分けることにより、通知手段間の負荷を平滑
   化することを特徴とする分散システムの通知方式。