(57)【要約】【課題】リアルタイム処理とバッチ処理が共存するネットワークに接続した計算機システムにおいて、バッチ処理の実行中であっても、リアルタイム要求を受付けて、リアルタイム処理及びバッチ処理ともにデータベースの更新を可能とするリアルタイム要求受付システム及び方法を提供することが課題である。【解決手段】バッチ処理を行う第１の処理部と、リアルタイム処理を行う第２の処理部と、リアルタイムの要求を受付ける要求受付部と、処理すべきレコードを保持しておくデータベースと、前記レコードに第１の処理部と第２の処理部の一方の処理が完了したことを示す第１のフィールドと、前記一方の処理が実行されるための条件を示す第２のフィールドとを設け、前記レコードに対する第１の処理部の実行中に第２の処理部が実行する処理を優先的に割り込ませ、第２の処理部では第１の処理部が実行する処理を含めて実行する。【選択図】  図２
2004171339.tif 000002
【特許請求の範囲】
【請求項１】
バッチ処理とリアルタイム処理とが共存しバッチ処理の実行中にリアルタイムの要求を受付けて実行する計算機システムにおけるリアルタイム要求受付システムであって、
バッチ処理を行う第１の処理部と、リアルタイム処理を行う第２の処理部と、前記第２の処理部に対してリアルタイムの要求を受付ける要求受付部と、リアルタイムの要求を受付けたことを記憶しておく第１の共有メモリ部と、処理すべきレコードのポインタを記憶しておく第２の共有メモリ部と、前記レコードを保持しておくデータベースと、前記データベースのレコードに前記第１の処理部と前記第２の処理部のどちらか一方の処理が完了したことを示す第１のフィールドと、前記一方の処理が実行されるための条件を示す第２のフィールドとを備え、前記レコードに対する第１の処理部の実行中に第２の処理部の実行する処理を優先的に割り込ませ、前記第２の処理部の実行する処理に前記第１の処理部の実行する処理を含めて実行することを、
特徴とするリアルタイム要求受付システム。
【請求項２】
バッチ処理とリアルタイム処理とが共存しバッチ処理の実行中にリアルタイムの要求を受付けて実行する計算機システムにおけるリアルタイム要求受付システムを用いて行うリアルタイム要求受付方法であって、
データベースに保持してあるレコードに前記バッチ処理とリアルタイム処理の一方の処理が完了したことを示す第１のフィールドと、一方の処理が実行されるための条件を示す第２のフィールドとを備え、前記レコードに対するバッチ処理の実行中にリアルタイムの処理を優先的に割り込ませ、前記リアルタイムの処理に前記バッチ処理で実行する処理を含めて実行することを、
特徴とするリアルタイム要求受付方法。
【請求項３】
前記リアルタイム要求受付方法は、前記バッチ処理において前記第１のフィールドが“未完了”状態を示す値でかつ第２のフィールドの値が前記の実行されるための条件を満たす場合に第１のフィールドを“完了”状態を示す値に更新して、所定の処理を実行するステップ１と、リアルタイムの要求を検知するステップ２と、前記レコードに対する処理を終えた後、次に処理すべきレコードのポインタを保持しておくステップ３と、ステップ３にて保持しているポインタを取得し該当するレコードに対し順次処理を再開するステップ４とを含むことを特徴とする請求項２に記載のリアルタイム要求受付方法。
【請求項４】
前記リアルタイム要求受付方法は、前記リアルタイム処理において前記第１のフィールドが“未完了”状態を示す値でかつ第２のフィールドの値が前記の実行されるための条件を満たす場合に第１のフィールドを“完了”状態を示す値に更新して、所定の処理を実行するステップ５と、リアルタイムにて要求された処理を実施するステップ６とを含むことを特徴とする請求項２又は請求項３に記載のリアルタイム要求受付方法。
【請求項５】
前記リアルタイム要求受付方法は、前記リアルタイム処理において前記第１のフィールドが“完了”状態を示す値でかつ第２のフィールドの値が前記の実行されるための条件を満たす場合にリアルタイムにて要求された処理を実施する前記ステップ６を実行することを特徴とする請求項２乃至請求項４のいずれか１項に記載のリアルタイム要求受付方法。
【請求項６】
前記リアルタイム要求受付方法は、前記リアルタイム処理において前記第１のフィールドの状態に関わらず、第２のフィールドの値が前記の実行されるための条件を満たさない場合にはリアルタイム要求の要求元に実行不可を示す情報を通知することを特徴とする請求項２乃至請求項５のいずれか１項に記載のリアルタイム要求受付方法。
【請求項７】
バッチ処理とリアルタイム処理とが共存しバッチ処理の実行中にリアルタイムの要求を受付けて実行する計算機システムにおけるリアルタイム要求受付方法に用いられるリアルタイム要求受付プログラムあって、請求項２乃至請求項６に記載のリアルタイム要求受付方法を実現させることを特徴とするリアルタイム要求受付プログラム。
【請求項８】
請求項７に記載のリアルタイム要求受付プログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はバッチ処理とリアルタイム処理とが共存する、ネットワークに接続した計算機システムにおいて、バッチ処理の実施中であっても、リアルタイム要求を受付けるリアルタイム要求受付システム及びその方法に関する。
【０００２】
【従来の技術】
近年、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）網において複数のサービス事業者システムのバックエンドで動作する共通的な課金・決済システムの提案、導入が進められている（例えば非特許文献１を参照）。このような共通的なシステムは、会員の登録時には信用照会（与信）の後に登録処理を実施し、会員への課金時は決済機関に会員の支払能力などを問い合わせた（オーソリ）後にリアルタイムにサービス提供可否をサービス事業者システムへ返却し、課金を実施している。
【０００３】
このような共通的な課金・決済システムでは、例えば会員の登録処理（会員のクレジットカードの有効性確認、会員ＩＤの払出し、データベースへの反映）などの処理は、データの整合性やトランザクションの応答を保証するために、リアルタイム処理の終了後に一括して実施することが多い。すなわち、日中はリアルタイムで会員の登録要求を受付けておき、夜間はリアルタイムでの要求受付けを停止してバッチ処理でデータベースへ反映することが一般的である。
【０００４】
ところが、顧客へのサービス向上の観点からは２４時間／日、３６５日／年のリアルタイム要求受付を実施することが望ましい。このようなサービスを実現する従来技術としては次のものがある（例えば特許文献１参照）。特許文献１には、バンキングシステムにおいて顧客の口座残高を表す「口座ファィル」へのバッチ処理（更新）を、リアルタイム処理（参照・更新）の一部として実施するようにした技術が開示されている。この方式では、元帳である「口座ファイル」に対し、更新の対象となるレコードを指示する「更新情報ファイル」という別のファイルを用意しておき、これをリアルタイム処理が参照しながら「口座ファイル」データベースに反映している。データベースへの反映はリアルタイム処理のみが担当することで、バッチによるファイル集計処理とリアルタイム処理を並行実施できるよう工夫されている。
【０００５】
【特許文献１】
特開平８−４４６７０号公報（段落〔０００７〕−〔００１５〕）
【非特許文献１】
三宅武司、外３名著「柔軟なサービス課金を可能にするＩＰ課金プラットフォーム」、ＮＴＴ技術ジャーナル、社団法人電気通信協会、２０００年１０月１日、Ｖｏｌ．１２、Ｎｏ．１０、Ｐ．１９−Ｐ．２２
【０００６】
【発明が解決しようとする課題】
例えば、会員登録を行うバッチ処理を実行中にリアルタイムの課金要求を受付けようとする場合、課金要求を受付けた時点ではまだ課金対象となる会員が登録されていないという状況が起こり得る。このような課題に対し、特許文献１に開示されている技術を適用して課題を回避することは可能である。しかしながら、特許文献１に開示されている技術では「口座ファイル」データベースへ更新情報を反映するのはあくまでリアルタイム処理のみであり、バッチ処理では「口座ファイル」データベースへの反映を実施しない。従って、バッチ処理であれば当然のことながらレコードの検索やソートなど、レコードに対する各操作に関して本来のデータベースの技術を利用できるがリアルタイム処理の特性を考慮するとこの利用が難しい。また、データベースを使用せずにバッチによるファイル集計処理を実施する分、多くのファイルの管理と整合性確認の処理を必要とし、処理コスト（メモリ使用率やＣＰＵ使用率など）が膨大になる可能性がある。以上を鑑みるにシステムとして提供するサービス品質の観点からは、このような処理形態は好ましいとは言い難い。
【０００７】
そこで本発明の課題は、リアルタイム要求受付けとバッチ処理が共存するネットワークに接続した計算機システムにおいて、バッチ処理の実施中であっても、リアルタイム要求を受付けて、リアルタイム処理及びバッチ処理ともにデータベースの更新を可能とするリアルタイム要求受付システム及びその方法を提供することにある。
【０００８】
【課題を解決するための手段】
前記課題を解決するために、バッチ処理とリアルタイム処理とが共存しバッチ処理の実行中にリアルタイムの要求を受付けて実行する計算機システムにおいて、計算機システムがリアルタイム処理の要求を受けると、バッチ処理を一時中断し、リアルタイムで受付けた要求の対象となるレコードをデータベースから取得して、下記に示す第１のフィールドと第２のフィールドを参照して処理の条件が一致すれば優先的に処理を実施する。このとき、当該レコードに対しバッチ処理で行うべき処理がまだ行われていない場合はバッチで行われる処理を含めて実行する。データベースに保持してあるレコードには前記バッチ処理とリアルタイム処理の一方の処理が完了したことを示す第１のフィールドと一方の処理が実行されるための条件を示す第２のフィールドとを備えている。当該処理が終了すると当該レコードの第１のフィールドを“未完了”状態を示す値から“完了”状態を示す値に更新する。一方でバッチ処理は、第１フィールド及び第２フィールドの状態を参照することにより当該レコードがバッチ処理の対象か否かを判断しながら処理を実施していく。
【０００９】
これにより、リアルタイム要求受付けを停止させることなくバッチ処理を実施でき、かつリアルタイム処理及びバッチ処理ともにデータベースの更新を可能とすることで常に最新の状態となっているデータベースを利用することができる。
【００１０】
【発明の実施の形態】
以下、本発明の実施形態を図面を用いて説明する。本発明の実施形態として、予約登録のあった会員をバッチ処理で会員登録するバッチ会員登録処理と会員への課金要求をリアルタイムで処理するリアルタイム課金処理について説明する。図１は本発明のリアルタイム要求受付システム及び方法に係るシステムの処理スケジュール例（バッチ会員登録処理及びリアルタイム課金処理）を示した図である。この例では、システムは会員Ａ・・・会員Ｍの登録要求を６月中に受け、前記会員を会員データベース（会員ＤＢ）へ予約会員として暫定的に登録しておく。暫定的に登録された予約会員は７月１日深夜からのバッチ処理によって予約会員から正会員（会員）として登録することを想定している。このバッチ処理は深夜０：００に開始され、会員Ａ、会員Ｂ、…のレコードに対して順に会員ＤＢを更新していき、同日の朝１０：００に終了するものとする。ここで、時刻２：００に、この時点で暫定登録の会員Ｍに対する課金要求を受けると、システムはバッチ処理をいったん中断し、会員Ｍを優先的に会員登録する処理を実施する。
【００１１】
本発明の実施形態に係るシステムの構成例を図２に示す。ただし、本図ではバッチ会員登録処理及びリアルタイム課金処理に必要な構成のみを示してある。ここで、請求項１に記載のリアルタイム要求受付システムは課金・決済システムに相当し、データベースは会員データベース（会員ＤＢ２３０）に相当する。符号２００はＩＰ網上で課金や決済を代行する課金・決済システムを表す。符号２０１はＩＰ網上でデジタルコンテンツの販売などを実施するサービス事業者システムを表す。サービス事業者システム２０１を運用するサービス事業者は、クレジットカード会社と加盟店契約を締結していることを想定している。符号２０２はクレジットカード会社またはクレジットカード会社への接続を代行する機関などの決済機関システムを表す。課金・決済システム２００とサービス事業者システム２０１はネットワーク２２０により接続されている。ネットワーク２２０はインターネットなどのオープンネットワークであっても、専用線などのプライベートネットワークでも構わない。ただし、オープンネットワークである場合には、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）やＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）などの方式により、セキュリテイが確保されているものとする。また、課金・決済システム２００と決済機関システム２０２は専用線などのプライベートネットワーク２２１により接続されている。
【００１２】
課金・決済システム２００は、メモリ部２１０、会員情報を管理する会員ＤＢ２３０、会員としての登録がなされなかった対象を蓄積するリジェクトＤＢ２３１を含んで構成される。メモリ部２１０には、サービス事業者システム２０１からリアルタイムで課金要求や会員登録要求を受付ける要求受付部２１１、深夜や月末などに会員ＤＢ２３０やリジェクトＤＢ２３１から順次レコードを読込み、会員登録処理を実施する第１の処理部２１２、サービス事業者システムからの要求があった際に特定のレコードに対し課金処理や会員登録を実施する第２の処理部２１３、決済機関システムとの間でデータ形式の変換などを実施するインタフェース部２１４、データベースを制御・管理するＤＢ管理部２１５の５つの機能がロードされる。また、メモリ部２１０は、“要求受付部２１１がサービス事業者システム２０１からリアルタイムの要求を受付けた”ことを表す情報（これはブール値でもよい）を保持した第１の共有メモリ部２１６と、会員ＤＢ２３０またはリジェクトＤＢ２３１のレコードのポインタを保持した第２の共有メモリ部２１７を持つ。
【００１３】
本明細書で述べる会員とは、サービス事業者の直接の顧客であり、当該サービス事業者からコンテンツを購入したり、その他のサービスを利用したりするエンドユーザのことを指す。会員ＤＢ２３０に蓄積された情報には登録の対象となる会員の氏名、住所、年齢、性別などの基本的な情報やクレジットカード番号などの決済に必要な情報が含まれる。また、会員ＤＢ２３０の情報は所定の日（月末や月初）や、所定の時刻（深夜０：００など）に第１の処理部２１２によってバッチ処理され、更新される。リジェクトＤＢ２３１は例えば月末や月初に実施するバッチ処理時に会員ＤＢ２３０へ入力されたクレジットカード番号が無効であることが判明した場合など、会員としての登録がなされなかった対象を蓄積するＤＢである。
【００１４】
図３は本発明にかかる会員ＤＢ２３０のレコード構成例を示した図である。符号３００は主キーとなるレコードの識別子（予約ＩＤ）である。符号３０１は会員の識別子（会員ＩＤ）である。符号３１０は登録を予約した会員の基本情報を表し、氏名３１１や住所３１２などから構成される。符号３２０は登録を予約した会員の決済情報を表し、クレジットカード番号３２１やクレジットカードの有効期限３２２などから構成される。符号３３０は会員ステータスを表す。会員ステータス３３０は“暫定登録”と“登録済み”の２値からなり、会員登録のバッチ処理またはリアルタイムの課金処理などによって暫定登録から登録済みへと更新される。なお、本例では会員ステータス３３０は２値と想定したが、これ以外にも例えば“退会”や“削除”といった値をとってもよい。暫定登録の場合は会員ＩＤ３０１はＮＵＬＬ値となる。バッチ会員登録処理またはリアルタイム課金処理は会員ステータス３３０のフィールドを参照することで、対象となる会員が既に登録済みかどうかを判別する。反映日３３１は暫定登録された予約会員を会員登録するバッチ会員登録処理を実施する日を表す。ここで会員ステータス３３０は請求項１乃至請求項６に記載した第１フィールドに相当し、反映日３３１は、第２フィールドに相当する。また、請求項に記載した第１フィールドの“未完了”状態を示す値とはこの実施形態では会員の“暫定登録”に相当し、“完了”状態を示す値とは“登録済み”に相当する。同様に第２フィールドの値が前記の実行されるための条件を満たす場合とはこの実施形態では該当レコードが“バッチ会員登録処理を実施する日”であり第２フィールドの値が前記の実行されるための条件を満たさない場合とは“バッチ会員登録処理を実施する日とは異なる日”に相当する。
【００１５】
なお、以下に説明する方法は、コンピュータを用いて、リアルタイム要求受付プログラムとしてコンピュータのプログラムで実現することができる。また、これらリアルタイム要求受付プログラムは、記録媒体に記録することができる。
【００１６】
次に、本発明に係る各構成部間の関連について図４を用いて、適宜図２を参照しながら説明する。各構成部間の関連フローチャートを図４に示す。なお、各部のフローチャートの詳細は後述する。まず、第１の処理部２１２は、バッチ処理にて予約会員を会員登録するバッチ会員登録処理（ＳＴ４００）を行いながら、第１の共有メモリ部２１６を参照（ＳＴ４０１）してリアルタイム要求が有るかをチェック（ＳＴ４０２）する。リアルタイム要求があれば（ＳＴ４０２でＹｅｓ）、第２の処理部２１３を起動するための制御信号を送信（ＳＴ４０３）する。その後第１の処理部２１２は、第２の処理部２１３の処理の完了したことを示す制御信号を受信（ＳＴ４０４）して次に処理すべきレコードに対して処理を続行（ＳＴ４０５）する。リアルタイム要求がなければ（ＳＴ４０２でＮｏ）、処理を続行（ＳＴ４０５）する。
【００１７】
第２の処理部２１３は、第１の処理部２１２からの制御信号を受信（ＳＴ４１０）すると課金処理の条件をチェック（ＳＴ４１１）してＯＫであれば（ＳＴ４１１でＹｅｓ）、会員の登録確定処理（ＳＴ４１３）、リアルタイムの課金処理（ＳＴ４１４）を行い第１の処理部２１２に処理の完了を意味する制御信号を送信（ＳＴ４１５）する。そしてサービス事業者システム２０１に対してＯＫを返却（ＳＴ４１６）する。なお会員の登録確定処理（ＳＴ４１３）は通常第１の処理部２１２のＳＴ４００で実行するステップである。課金処理の条件がＯＫでなければ（ＳＴ４１１でＮｏ）、ＮＧを返却（ＳＴ４１２）する。
【００１８】
サービス事業者システム２０１から課金要求処理（ＳＴ４３０）がなされると、要求受付部２１１は、処理要求レコードに対して第１の処理部２１２が実行中かチェック（ＳＴ４２０）して実行中でなければ（ＳＴ４２０でＮｏ）、第２の処理部２１３を起動（ＳＴ４２１）する。第１の処理部２１２が実行中であれば（ＳＴ４２０でＹｅｓ）、すなわちこの状態は第１の処理部２１２がバッチ処理で会員登録処理を行っている状態である。この場合要求受付部２１１は、リアルタイムの要求有りを第１の共有メモリ部２１６へ登録（ＳＴ４２２）する。第１の処理部２１２は、この第１の共有メモリ部２１６を参照（ＳＴ４０１）して前述したようにリアルタイム要求があれば（ＳＴ４０２でＹｅｓ）第２の処理部２１３に対して制御信号を送信（ＳＴ４０３）する。
【００１９】
このようにしてバッチ処理の実行中にリアルタイムの処理を優先的に割り込ませ、リアルタイムの処理にバッチ処理で実行する処理を含めて実行することが可能である。
【００２０】
次に、各構成部の処理フローについて図５から図８を用いて、適宜図１、図２及び図３を参照しながら説明する。図５は本発明に係るシステムの、会員登録をバッチで実施する処理（バッチ会員登録処理）のフローチャートを示した図である。まず、第１の処理部２１２が所定の時刻に起動（ＳＴ５００）される。本例では第１の処理部２１２は図１に記載したように７月１日の深夜０：００に起動されるものとする。第１の処理部２１２はまず、処理すべきレコードの先頭アドレスを示すポインタを初期値に設定（ＳＴ５０１）する。次に会員ＤＢ２３０へ接続し、設定したポインタ値と処理すべき最終レコードのポインタ値とを比較（ＳＴ５０２）する。後者の方が大きな値である場合（ＳＴ５０２でＮｏ）、第１の処理部２１２はレコードを１件ＤＢから読み込む（ＳＴ５０３）。一方で前者の方が大きな値である場合は（ＳＴ５０２でＹｅｓ）、第１の処理部２１２は処理を終了する。ＳＴ５０３の後、第１の処理部２１２はレコードの会員ステータス３３０が“暫定登録”か“登録済み”かによって処理を分岐する（ＳＴ５０４）。“暫定登録”でなければ（ＳＴ５０４でＮｏ）すなわち“登録済み”となっていれば当該レコードに対する処理は実施せずＳＴ５０７にジャンプする。一方、“暫定登録”であれば（ＳＴ５０４でＹｅｓ）当該レコードの反映日が本日（当該処理の日）と一致しているかどうかを判別（ＳＴ５０５）する。一致していれば（ＳＴ５０５でＹｅｓ）第１の処理部２１２は登録確定処理（ＳＴ５０６）を実施する。登録確定処理例の詳細は図８で説明する。一方、反映日が本日でなければ（ＳＴ５０５でＮｏ）当該レコードに対する処理は実施せずＳＴ５０７にジャンプする。次に第１の処理部２１２は第１の共有メモリ部２１６を読込み、リアルタイム要求を受付けているかどうかを判別（ＳＴ５０７）する。リアルタイム要求を受付けていない場合（ＳＴ５０７でＮｏ）、第１の処理部２１２は所定の値だけポインタをインクリメント（ＳＴ５０８）した後、ＳＴ５０２の処理へジャンプする。一方、ＳＴ５０７にてリアルタイム要求を受付けている場合（ＳＴ５０７でＹｅｓ）、ＳＴ５０８においてインクリメントした値だけポインタをインクリメント（ＳＴ５０９）した後、このポインタを第２の共有メモリ部２１７へ登録（ＳＴ５１０）する。次に第１の処理部２１２は第２の処理部２１３へ、“レコードに対する処理を開始してよい”ということを表す制御信号を送信（ＳＴ５１１）する。この処理はＤＢ管理部２１５によるレコードのロックが解除されたことを表す。第１の処理部２１２は、第２の処理部２１３による処理が完了するのを待ち、第２の処理部２１３から制御信号を受信（ＳＴ５１２）すると、第１の処理部２１２はＳＴ５１０で保持していたポインタを第２の共有メモリ部２１７から取得（ＳＴ５１３）し、次に処理すべきレコードに対しバッチ会員登録処理を再開する。ここで、請求項３に記載のステップ１はＳＴ５０６（登録確定処理）、ステップ２はＳＴ５０７、ステップ３はＳＴ５０９及びＳＴ５１０、ステップ４はＳＴ５１３に相当する。
【００２１】
図６（ａ−１）及び図６（ａ−２）は本発明の実施形態に係るシステムの、課金処理をリアルタイムで実施する処理（リアルタイム課金処理）のフローチャートを示した図である。まず、図６（ａ−１）にて要求受付部２１１の処理フローを説明する。要求受付部２１１はまず、サービス事業者システム２０１からの要求を受付ける。この要求は図１に記載したように７月１日の時刻２：００に実施されるものとする。次に会員ＤＢがロックされているかどうかを確認（ＳＴ６００ａ）する。ロックされていれば（ＳＴ６００ａでＹｅｓ）、第１の共有メモリ部２１６へ“ＤＢのロック解除待ち”であることを示す情報を登録（ＳＴ６０１ａ）する。一方ロックされていなければ（ＳＴ６００ａでＮｏ）、要求受付部２１１は第２の処理部２１３を起動（ＳＴ６０２ａ）する。次に、図６（ａ−２）にて第２の処理部２１３の処理フローを説明する。要求受付部２１１によって起動された第２の処理部２１３は、会員レコードを会員ＤＢ２３０から取得（ＳＴ６０３ａ）する。該当する予約ＩＤでの対象となる会員レコ―ドが存在しない場合（ＳＴ６０４ａでＮｏ）、第２の処理部２１３はサービス事業者システムへＮＧを返却（ＳＴ６１０ａ）する。一方、会員レコードが存在した場合（ＳＴ６０４ａでＹｅｓ）、第２の処理部２１３は反映日（図３の３３１）を参照し、バッチ会員登録処理が本日に実施されるかどうかによって処理を分岐する（ＳＴ６０５ａ）。次に第２の処理部２１３は会員ステータス（図３の３３０）を参照し、当該会員が“暫定登録”であるか“登録済み”であるかによって処理を分岐する（ＳＴ６０６ａ）。リアルタイム課金処理が該当レコードを取得した時点で、当該レコードに対するバッチ会員登録処理が第１の処理部２１２によって完了されていなければ、当該レコードの会員ステータス（図３の３３０）は“暫定登録”のままである。この場合（ＳＴ６０６ａでＹｅｓ）、第２の処理部２１３は登録確定処理（ＳＴ６０７ａ）を実施した後、課金処理（ＳＴ６０８ａ）を実施する。課金処理（ＳＴ６０８ａ）の詳細は図７で説明する。一方で、リアルタイム課金処理が該当レコードを取得した時点ですでに当該レコードに対するバッチ会員登録処理が第１の処理部２１２によって完了されていれば、当該レコードの会員ステータス（図３の３３０）は“登録済み”となっている。この場合（ＳＴ６０６ａでＮｏ）、第２の処理部２１３は課金処理（ＳＴ６０８ａ）のみを実施する。最後に、第２の処理部は要求元へ“処理が終了した”というＯＫを返却（ＳＴ６０９ａ）する。また、第２の処理部２１３は反映日（図３の３３１）を参照し、反映日が本日でない場合（ＳＴ６０５ａでＮｏ）は、サービス事業者システムにＮＧを返却（ＳＴ６１０ａ）する。これはまだ会員登録の期日になっていないのでＮＧの返却となる。なお、本例ではリアルタイム課金処理が予約ＩＤをキーとして対象のレコードを検索する例を説明したが、第２の処理部２１３は会員ＩＤをキーにして対象のレコードを検索してもよい。予約ＩＤをキーにするか会員ＩＤをキーにするかは本発明にかかるシステムの上位側のアプリケーションに依存する事柄であるため、会員ＩＤをキーとする動作の説明は省略する。なお、ここで、請求項４に記載のステップ５はＳＴ６０７ａ（登録確定処理）に相当し、請求項４及び請求項５に記載のステップ６はＳＴ６０８ａ（課金処理）に相当する。また、請求項６はステップＳＴ６１０ａに相当する。
【００２２】
本実施形態から明らかなように、本発明に係るリアルタイム要求受付方法では、リアルタイム処理を実行中であるときはバッチ処理は中断している。すなわち、任意のレコードに対し二つの処理が競合することはない。
【００２３】
図６（ｂ）は第２の処理部２１３が第１の処理部２１２からの制御信号を受信して起動する場合のフローチャートを示した図である。このフローに沿った動作は、図６（ａ−１）のＳＴ６００ａにおいて要求受付部２１１が第１の共有メモリ部２１６へ“ＤＢのロック解除待ち”を登録した場合、すなわち、第１の処理部２１２が図５のＳＴ５１１にて第２の処理部２１３へ制御信号を送信する場合に発生する。
【００２４】
まず、第２の処理部２１３が第１の処理部２１２から制御信号を受信（ＳＴ６００ｂ）することで起動される。起動された第２の処理部２１３は、会員のレコードを会員ＤＢから取得（ＳＴ６０１ｂ）する。該当する予約ＩＤでの対象となる会員レコ―ドが存在しない場合（ＳＴ６０２ｂでＮｏ）、第２の処理部２１３はサービス事業者システム２０１へＮＧを返却する（ＳＴ６０９ｂ）。一方、対象の会員レコードがある場合（ＳＴ６０２ｂでＹｅｓ）、第２の処理部２１３は反映日（図３の３３１）を参照し、バッチ会員登録処理が本日に実施されるかどうかによって処理を分岐する（ＳＴ６０３ｂ）。次に第２の処理部２１３は会員ステータス（図３の３３０）を参照し、当該会員が“暫定登録”であるか“登録済み”であるかによって処理を分岐する（ＳＴ６０４ｂ）。リアルタイム課金処理が該当レコードを取得した時点で、当該レコードに対するバッチ会員登録処理が第１の処理部２１２によって完了されていなければ、当該レコードの会員ステータス（図３の３３０）は“暫定登録”のままである。この場合（ＳＴ６０４ｂでＹｅｓ）、第２の処理部２１３は登録確定処理（ＳＴ６０５ｂ）を実施した後、課金処理（ＳＴ６０６ｂ）を実施する。課金処理（ＳＴ６０６ｂ）の詳細は図７で説明する。一方で、リアルタイム課金処理が該当レコードを取得した時点ですでに当該レコードに対するバッチ会員登録処理が第１の処理部２１２によって完了されていれば、当該レコードの会員ステータス（図３の３３０）は“登録済み”となっている。この場合（ＳＴ６０４ｂでＮｏ）、第２の処理部２１３は課金処理（ＳＴ６０６ｂ）のみを実施する。次に第２の処理部２１３は第１の処理部２１２へ“第２の処理部の処理が終了したので、第１の処理部の処理を再開してよい”という制御信号送信（ＳＴ６０７ｂ）を行う。最後に、第２の処理部は要求元へ“処理が終了した”というＯＫを返却（ＳＴ６０８ｂ）する。また、第２の処理部２１３は反映日（図３の３３１）を参照し、反映日が本日でない場合（ＳＴ６０３ｂでＮｏ）は、サービス事業者システムにＮＧを返却（ＳＴ６０９ｂ）する。ここで、請求項４に記載のステップ５はＳＴ６０５ｂ（登録確定処理）に相当し、請求項４及び請求項５に記載のステップ６はＳＴ６０６ｂ（課金処理）に相当する。また、請求項６はステップＳＴ６０９ｂに相当する。
【００２５】
図７は課金処理のフローチャート（図６（ａ−２）のＳＴ６０８ａまたは図６（ｂ）のＳＴ６０６ｂ）を示した図である。本例における課金処理ではサービス事業者システムから受けた課金要求に対し、会員ＩＤ、クレジットカード番号、課金額などをもとに会員が指定された課金額分の支払いが可能かどうかを図２の決済機関システム２０２へ問い合わせて確認（オーソリ）することを想定している。オーソリＯＫであれば（ＳＴ７００でＹｅｓ）、課金ＤＢ（図示せず）へレコード（課金額）を追加（ＳＴ７０１）する。また、オーソリがＯＫでなければ（ＳＴ７００でＮｏ）、サービス事業者システム２０１へＮＧを返却（ＳＴ７０２）する。
【００２６】
図８は図５に記載した登録確定処理（ＳＴ５０６）及び図６（ａ−２）に記載した登録確定処理（ＳＴ６０７ａ）のフローチャートを示した図である。登録確定処理はバッチ会員登録処理またはリアルタイム課金処理から呼び出され、システムが会員を登録するための処理である。システムはまず、会員のクレジットカード番号が有効かどうかを図２の決済機関システム２０２へ問い合わせて確認（与信）する。ここで、与信と図７の説明で述べたオーソリとの違いは前者がクレジットカード番号を確認の対象とするのに対し、後者はクレジットカード番号及び課金額を対象とする点にある。与信ＯＫであれば（ＳＴ８００でＹｅｓ）、システムは会員用のレコードの会員ステータスを“暫定登録”から“登録済み”へと更新（ＳＴ８０１）する。一方、与信がＯＫでなければ（ＳＴ８００でＮｏ）、システムは当該レコードの情報のコピーをリジェクトＤＢ２３１へレコードとして追加（ＳＴ８０２）する。
【００２７】
このようにしてバッチ処理の実行中にリアルタイムの処理を優先的に割り込ませ、リアルタイムの処理にバッチ処理で実行する処理を含めて実行することが可能である。
【００２８】
以上説明した本発明は、バッチ処理とリアルタイム処理が共存する計算機システムにおいて前記した実施形態に限定されることなく幅広く変形実施することができる。
【００２９】
【発明の効果】
本発明によれば、リアルタイム要求受付けを停止させることなくバッチ処理を実施でき、かつリアルタイム処理及びバッチ処理ともにデータベースの更新を可能とすることで常に最新の状態となっているデータベースを利用することができる。また、バッチ処理を深夜、週末、月末など特定の時間に限定せずに実行することができ、担当者はともすれば深夜または休日に実施していた作業を通常の時間に実行でき作業の効率向上が図れる。
【図面の簡単な説明】
【図１】本発明のリアルタイム要求受付システム及び方法に係るシステムの処理スケジュール例を示した図である。
【図２】本発明の実施形態に係るシステムの構成例を示した図である。
【図３】会員ＤＢのレコード構成例を示した図である。
【図４】構成間の関連フローチャートを示した図である。
【図５】バッチ会員登録処理のフローチャートを示した図である。
【図６】（ａ−１）  リアルタイム課金処理のフローチャート（要求受付部のフロー）を示した図である。
（ａ−２）  リアルタイム課金処理のフローチャート（第２の処理部のフロー）を示した図である。
（ｂ）  リアルタイム課金処理のフローチャート（第１の処理部から起動された時の第２の処理部のフロー）を示した図である。
【図７】課金処理のフローチャートを示した図である。
【図８】登録確定処理のフローチャートを示した図である。
【符号の簡単な説明】
２００・・・リアルタイム要求受付システム（課金・決済システム）
２０１・・・サービス事業者システム
２０２・・・決済機関システム
２１０・・・メモリ部
２１１・・・要求受付部
２１２・・・第１の処理部
２１３・・・第２の処理部
２１４・・・インタフェース部
２１５・・・ＤＢ管理部
２１６・・・第１の共有メモリ部
２１７・・・第２の共有メモリ部
２３０・・・会員ＤＢ
２３１・・・リジェクトＤＢ
３３０・・・第１のフィールド（会員ステータス）
３３１・・・第２のフィールド（反映日）
【図１】
2004171339.tif 000003
【図２】
2004171339.tif 000004
【図３】
2004171339.tif 000005
【図４】
2004171339.tif 000006
【図５】
2004171339.tif 000007
【図６】
2004171339.tif 000008
【図７】
2004171339.tif 000009
【図８】
2004171339.tif 000010