サービス再開装置およびサービス再開プログラム
【課題】 サービス実行装置の再起動時に効率のよいサービス再開を実現することが可能なサービス受付再開装置を提供する。
【解決手段】 本発明の実施形態は、利用者端末３とサービス実行サーバ２との間にサービス受付サーバ１を設ける。利用者端末３からのサービス要求メッセージは、サービス受付サーバ１で監視され、サービスの利用状況がサービス状態記憶部１０３で保持される。サービス実行サーバ２の再起動時、サービス処理再開部１０５は再起動前のサービス利用状況から再開するサービスの優先順位を決定する。
【解決手段】 本発明の実施形態は、利用者端末３とサービス実行サーバ２との間にサービス受付サーバ１を設ける。利用者端末３からのサービス要求メッセージは、サービス受付サーバ１で監視され、サービスの利用状況がサービス状態記憶部１０３で保持される。サービス実行サーバ２の再起動時、サービス処理再開部１０５は再起動前のサービス利用状況から再開するサービスの優先順位を決定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用者にサービスを提供するサービス提供システムで用いるサービス再開装置およびサービス再開プログラムに関する。
【背景技術】
【０００２】
従来、利用者端末からのサービス要求メッセージを受信してサービスに必要な処理を実行するサービス実行サーバにおいては、サービス実行サーバ起動後に、サービスに必要なプログラムをサービス実行サーバ内のメモリへロードする等の準備作業が必要である。準備作業が完了後最初にサービス要求メッセージを受信すると、まずそのサービス要求メッセージの処理に要するすべてのシステム資源を確保する作業を行い、次いでサービス要求メッセージの処理を行う。2回目以降のサービス要求メッセージ受信時には、システム資源の確保作業を行う必要がないため、最初のサービス要求メッセージよりも短時間で処理を完了することができる。
【０００３】
サービス実行サーバで使用するファームウェアの更新や、システム異常等によりサービス実行サーバが停止し再起動を行う場合、再起動後に最初のサービス要求メッセージを受信した時点で上述のシステム資源の確保を行うと、最初のサービス要求メッセージの処理完了までの時間が長くなる。そのため、サービス実行サーバ再起動後に上述の準備作業が完了した時点でダミーのサービス要求メッセージを投入し、実際のサービス要求メッセージ到来に先行してシステム資源の確保を行う方法を取っている。なお、本出願に関する従来技術の参考文献として、特許文献1が知られている。
【特許文献１】特開２００２−１４９４３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、上述のサービス実行サーバ再起動後にダミーのサービス要求メッセージを投入する方法では、サービス実行サーバの提供するサービスの種類が増えるにつれ、再起動後にダミーのサービス要求メッセージに対する処理が集中しサービス実行サーバに負荷を与えることとなる。さらに、全てのダミーサービス要求メッセージの処理が終了するまでサービスの開始ができないようなサービス実行サーバにおいては、再起動後のサービス開始に時間がかかる。また、サービス実行サーバ再起動時でサービスが停止した状態では、利用者端末からのサービス要求に対して応答することができない。
【０００５】
特許文献１には、利用者端末とサービス実行サーバとの間にサービス要求サーバを設け、このサービス要求サーバで予めサービスごとに優先度を設定する方法が紹介されている。しかし、サービスの利用状況は利用される時間帯等により流動的に変化するものであり、予めサービスの優先度を決める方法では利用状況に応じた効率的なサービス再開を行うことはできない。また、サービス停止時に利用者端末からのサービス要求に対して応答するができないという課題を解決する方法に関しては具体的な解決策は示されていない。
【０００６】
本発明は上記事情を考慮してなされたもので、その目的は、サービス実行サーバの再起動時におけるサービス再開を利用状況に応じて効率よく実施することおよび、サービス実行サーバ再起動時でサービスが中断している状態においても利用者端末からのサービス要求メッセージに対して応答することが可能なサービス再開装置を提供することにある。
【課題を解決するための手段】
【０００７】
本発明は上記の課題を解決するためになされたもので、請求項1に記載の発明は、複数のサービスのそれぞれにおいて必要となる一連の処理を実行するサービス実行装置に対しサービス再開処理を行うサービス再開装置であって、利用者端末からサービス要求メッセージを受信するサービス受付部と、前記サービス要求メッセージで要求されたサービスの情報を記憶するサービス状態記憶部と、前記サービス実行装置の故障状態を確認する故障監視部と、前記故障監視部で前記サービス実行装置が再起動中であることを確認した場合に、前記サービスの処理再開を行うサービス処理再開部とを備え、前記サービス処理再開部は、前記サービス状態記憶部で記憶した情報に基づいてサービスの優先度を決定する優先度決定手段と、前記優先順位決定手段の結果に基づいて、優先度の高いサービスから順番にサービス再開処理を行うサービス再開手段と、を備えていることを特徴としている。
【０００８】
また、請求項２に記載の発明は、請求項１に記載の発明において、前記サービス状態記憶部は、過去一定時間内における、前記サービスの処理を実施終了した実施終了処理数と前記サービスの処理が実行途中である実行中処理数とを保持し、前記優先度決定手段は、前記サービス実行装置が再起動を行う直前の前記一定時間内における前記実施終了処理数と前記実行中処理数との加算演算処理を行い、加算演算処理の演算結果を優先度とすることを特徴としている。
【０００９】
また、請求項３に記載の発明は、請求項２に記載の発明において、前記加算演算処理は、
前記実施終了処理数と前記実行中処理数とに重み付けを行うことを特徴としている。
【００１０】
また、請求項４に記載の発明は、請求項１から請求項３のいずれか1項に記載の発明において、前記サービス実行装置の再起動時に受信した前記サービス要求メッセージに対して予約を受け付ける予約受付手段と、予約を受け付けたサービス要求メッセージを保存する予約保存手段と、前記優先度決定手段で決定した優先度に基づいてサービス再開に要する時間を推定し、前記推定した時間を前記利用者端末へ通知する推定再開時間通知手段と、前記サービス実行装置の再起動後に前記予約保存手段で保存したサービス要求メッセージを前記サービス実行装置へ送信する送信手段と、を備えていることを特徴としている。
【００１１】
また、請求項５に記載の発明は、複数のサービスのそれぞれにおいて必要となる一連の処理を実行するサービス実行装置に対しサービス再開処理を行うコンピュータに、利用者端末からサービス要求メッセージを受信するサービス受付手順と、前記サービス要求メッセージで要求されたサービスの情報を記憶するサービス状態記憶手順と、前記サービス実行装置の故障状態を確認する故障監視手順と、前記故障監視手順で前記サービス実行装置が再起動中であることを確認した場合に、前記サービス状態記憶手順で記憶した情報に基づいてサービスの優先度を決定する優先度決定手順と、前記優先順位決定手順の結果に基づいて優先度の高いサービスから順番にサービス再開処理を行うサービス再開手順と、前記サービス実行装置の再起動時に受信した前記サービス要求メッセージに対して予約を受け付ける予約受付手順と、予約を受け付けたサービス要求メッセージを保存する保存手順と、前記優先度決定手順で決定した優先度に基づいてサービス再開に要する時間を推定し、前記推定した時間を前記利用者端末へ通知する推定再開時間通知手順と、前記サービス実行装置の再起動後に前記予約保存手順で保存したサービス要求メッセージを前記サービス実行装置へ送信する送信手順と、を実行させるサービス再開プログラムである。
【発明の効果】
【００１２】
本発明によれば、サービス受付サーバでサービスの利用状況を監視し、サービス実行サーバ再起動直前の利用状況からサービスの優先度を決定するため、再起動時に最も必要とされているサービスを優先的に再開することができる。また、サービス実行サーバ再起動時にサービスが中断している間においても、サービス受付サーバが予約を受け付けることが可能になる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して本発明の実施形態について説明する。図１は本発明の実施形態にかかるサービス受付サーバ（サービス受付装置）を用いたサービス提供システムの構成図であり、サービス受付サーバ１、サービス実行サーバ（サービス実行装置）２、利用者端末３、情報記憶部４）とから構成される。
【００１４】
図１において、サービス受付サーバ１は、利用者端末3、３、・・・からのサービス要求メッセージを受信するもので、サービス実行サーバ２は、サービス受付サーバ１の指示に従って利用者が要求するサービスを提供するために必要な一連の処理（トランザクション）を実行するものである。情報記憶部4、４、・・・は、サービス実行サーバ２で実行するサービスのプログラムを保持するものである。ネットワーク５は利用者端末３、３、・・・とサービス受付サーバ１とをつなぐものであり、ネットワーク６はサービス受付サーバ１とサービス実行サーバ２とをつなぐものであり、ネットワーク７はサービス実行サーバ２と情報記憶部４、４、・・・とをつなぐものである。
【００１５】
サービス受付サーバ１内のサービス受付部１０１は、利用者端末３からのサービス要求メッセージを受信するものである。サービス振分部１０２は、サービス受付部１０１で受信したサービス要求メッセージに応じて処理を行うものである（詳細は後述する）。サービス状態記憶部１０３は、受信したサービス要求メッセージで要求されたサービスの情報を保持するものである。故障監視部１０４は、サービス実行サーバ２の状態を確認するものである。サービス処理再開部１０５は、サービス実行サーバ２の再起動後にサービスを再開する処理を制御するものである。通信部１０６はサービス実行サーバ２と通信を行うものである。
【００１６】
サービス実行サーバ２内の通信部２０１は、サービス受付サーバ１との通信を行うものである。サービス実行部２０２、・・・は、サービスを提供するために必要な処理を実行するものであり、サービスごとに１つのサービス実行部がある。サービス２０３、・・・は、各サービス実行部２０２で使用するサービスのプログラムである。サービス接続処理部２０４は、サービス実行サーバ２外部の情報記憶部４と通信を行うものである。
【００１７】
次に、上述した実施形態の動作を図１から図６を参照して説明する。図１において、利用者端末３が送信したサービス要求メッセージは、サービス受付部１０１で受信され、サービス振分部１０２で処理される。サービス振分部１０２は、サービス要求メッセージで要求されたサービスの種類およびそのサービス要求メッセージを受信した時刻をサービス状態記憶部１０３へ書き込む。またサービス振分部１０２は、サービス実行サーバ２が再起動中でないかを故障監視部１０４へ問い合わせ、再起動中でなければサービス要求メッセージを通信部１０６からサービス実行サーバ２の通信部２０１へ送信する。サービス実行サーバ２が再起動中である場合は、サービス要求メッセージに対して予約を受け付ける処理（予約処理）を行うが、この予約処理に関しては後述する。
【００１８】
サービス状態記憶部１０３は、サービス振分部１０２から入力する情報をもとに、利用者端末３から要求されたサービスの種類および、そのサービスの開始・終了時間を記憶する。ここで、サービス状態記憶部１０３で記憶するのは過去一定時間（ｔ秒）におけるサービス利用状況である。
【００１９】
サービス実行サーバ２の通信部２０１がサービス要求メッセージを受信すると、そのサービス要求メッセージをサービス接続処理部２０４へと出力する。サービス接続処理部２０４は、サービス実行部２０２に対して、サービス要求メッセージで要求された処理を行うように指示を出す。サービス実行部２０２における処理の過程で利用者端末３へ情報を送信する場合は、サービス受付サーバ１を経由して送信する。このように、利用者端末３とサービス実行サーバ２とがサービス受付サーバ１を介して情報の送受信を行うことで、サービス実行サーバ２は利用者端末３へサービスを提供する。
【００２０】
続いて、サービス実行サーバ２が、そのサーバで使用するファームウェアの更新やシステム異常等により停止し再起動を行った場合の動作を説明する。図２のＡに示した時点でサービス実行サーバ２が再起動を行うと、図１の故障監視部１０４が再起動を検出する。サービス実行サーバ２の再起動前ｔ秒間のサービス利用状況は、サービス受付サーバ１のサービス状態記憶部１０３で記憶されている。図２の例では、サービス状態記憶部１０３は、図３に示すｔ時間内トランザクション状態テーブルでサービスの種類及びサービスの開始・終了時刻を保持する。また、サービス状態記憶部１０３は、ｔ時間内トランザクション状態テーブルを編集し、図４に示すｔ時間内サービス状態テーブルを作成する。ｔ時間内サービス状態テーブルは、過去ｔ秒の間に実行された、および実行中のサービス数を保持するものである。
【００２１】
図５はサービス実行サーバ２再起動時における、サービス受付サーバ１のサービス処理再開部１０５での処理を示したフローチャートである。故障監視部１０４がサービス実行サーバ２の再起動を検出すると、再起動の情報がサービス処理開始部１０５へと出力される。サービス処理開始部１０５がサービス実行サーバ２再起動の情報を入力すると、サービス状態記憶部１０３で保持するｔ時間内サービス状態テーブルを参照し、サービス再開の優先度を決定し（優先度決定手段）、優先度の高い順に優先順位を付与する（ステップＳ５０１）。
【００２２】
ここで、優先度を決定する方法としては、実行中のトランザクション数（実行中処理数）と実施終了済みのトランザクション数（実施終了処理数）の和、すなわち図４に示したｔ時間内サービス状態テーブルの「計」に示した列の値を用いる（加算演算）。図４の例では、サービスＢの優先度が３（優先順位が１）、サービスＡの優先度が２（優先順位が２）、そしてサービスＣの優先度が１（優先順位が３）となる。
【００２３】
優先度を決定する別の例として、前述の和を求める方法において、実施中のトランザクション数に重み付けを行う方法が考えられる。優先度をＰｒ、実施中のトランザクション数をＸ、実施終了済みのトランザクション数をＹ、ＸのＹに対する重み付け係数をａとおき、優先度Ｐｒ＝ａＸ＋Ｙと定義する。この方法は、例えば、実行中のトランザクション数の多いサービス、すなわちサービス実行サーバの再起動により中断された処理数の多いサービス、を優先して再開するのに最適である。
【００２４】
サービス再開の優先順位が求まると、サービス実行サーバ２の再起動が終了した後（図２のＢの時点）にその優先順位に従ってサービス再開処理を行う（サービス再開手段、図５のステップＳ５０２〜ステップＳ５０７）。サービス再開処理では、まずサービス再開処理部１０５が優先順位１のサービスに対応するダミーのサービス要求メッセージを、ネットワーク６を介してサービス実行サーバ２へ投入する（ステップＳ５０３）。図２の例ではサービスＢの優先順位が１であり、サービスＢに対するダミーのサービス要求メッセージを投入する。
【００２５】
サービス実行サーバ２が上記サービスＢに対するダミーのサービス要求メッセージを受信すると、サービス接続処理部２０４は、サービスＢに必要なプログラムをメモリへロードしサービス要求メッセージに処理の要する全てのシステム資源を確保する等の作業を行うようサービス実行部２０２へ指示を出す。このとき、サービスＢで必要となるプログラムの全体もしくは一部を外部の情報記憶部４が保持する場合は、サービス接続処理部２０４は情報記憶部４から必要なプログラムをダウンロードする。
【００２６】
サービスＢの準備作業が終了し、サービス実行部２０２がダミーのサービス要求メッセージに対する処理を完了すると、サービス処理再開部１０５へ処理完了の通知を行う。この通知により、ダミーのサービスメッセージへの処理が完了したことをサービス処理再開部１０５が認識すると（図５のステップＳ５０４：Ｙｅｓ）、サービスＢのサービス開始処理を行う（ステップＳ５０５）。サービス開始処理においては、サービス処理再開部１０５がサービス振分部１０２へサービスＢの再開が可能であることを通知する。通知を受けたサービス振分部１０２は、サービス実行サーバ２への、利用者端末３からのサービスＢに対するサービス要求メッセージ送信を再開する。
【００２７】
サービス開始処理が終了しサービスＢが再開されると（ステップＳ５０６：Ｙｅｓ）、優先順位が１のサービスＢに対するサービス再開処理が終了し、続いて優先度が２であるサービスＡの再開処理、優先順位が３であるサービスＣの再開処理の順にステップＳ５０２〜ステップＳ５０７の手順を行う。全てのサービスに対して再開処理が終了すると、サービス処理再開部１０５はサービス再開の手順を終了する。
【００２８】
本発明のサービス再開処理では、サービス実行サーバ２の再起動直前におけるサービスの利用状況に応じてサービスの優先度を決定するため、再起動時に必要とされるサービスから優先的に再開するという効率的なサービス再開を行うことが可能である。また、ダミーのサービス要求メッセージの処理を終えた時点でそのサービスを再開するため、全てのダミーサービス要求メッセージを処理した後に全サービスを再開する従来技術と比較して、優先度の高いサービスほど短時間でサービスを再開することができる。
【００２９】
続いて、サービス実行サーバ２が再起動中にサービス振分部１０２が行う前述の予約処理に関して、図６から図８を参照して説明する。図６は予約処理におけるサービス振分部１０２の手順を示したフローチャートである。サービス実行サーバ２が再起動中に、サービス振分部１０２がサービス要求メッセージを入力すると（ステップＳ６０１）、サービス実行サーバ２が故障のため復旧中であり、サービス要求の予約を行うかを利用者端末３へ問い合わせる（ステップＳ６０２）。
【００３０】
図７はサービス受付サーバ１からの問い合わせ時に、利用者端末３で表示される画面の一例であり、利用者はサービス要求の予約を行うかどうかを選択することができる。予約を行うかどうかだけではなく、利用者がその予約を継続する時間を指定する形態を取ることも可能である。
【００３１】
利用者がサービス要求の予約を行う旨を記したデータをサービス受付サーバ１へ送信し、サービス振分部１０２でそのデータが処理されると（予約受付手段、図６のステップＳ６０３：Ｙｅｓ）、サービス振分部１０２はステップＳ６０１で受信したサービス要求メッセージを予約待ち状態として保存する（予約保存手段、ステップＳ６０４）。この後、サービス状態記憶部１０３で保持するｔ時間内サービス状態テーブルを参照し、予約待ちにしたサービスの優先度からサービス再開の優先順位を判定する。サービス振分部１０２は、判定した優先順位からサービス再開にかかる時間を予想し利用者端末３へサービス再開までの予想時間を通知する（推定再開時間通知手段、ステップＳ６０５）。
【００３２】
図５のステップＳ５０５でサービス振分部１０２がサービス再開の通知をサービス処理再開部１０５から入力すると（図６のステップＳ６０６：Ｙｅｓ）、利用者端末３に対してサービス再開を通知する。それとともに、予約していた利用者端末３からのサービス要求メッセージをサービス実行サーバ２へ送信し（送信手段）、利用者端末３へのサービス提供を再開する（ステップＳ６０７）。
【００３３】
サービスが再開されるまで待機するステップＳ６０６において、前述の利用者が予約を継続する時間を指定する形態では、指定された継続時間経過後にサービス振分部１０２が利用者端末３へ予約の解除を通知し、サービス要求メッセージの予約を解除する方法を取ることが可能である。また、予約継続時間の設定可能時間に上限を設け、その上限の時間が経過した後にサービス要求メッセージの予約解除を行うこともできる。
【００３４】
また、サービス実行サーバ２が再起動を行っている間、利用者端末３からサービス要求の予約を受け付けるだけでなく、サービス実行サーバ２の再起動状態を利用者端末３へ通知する方法も考えられる。図８において、再起動状態確認サーバ８は、サービス実行サーバ２と通信を行い、サービス実行サーバ２の再起動状態を取得するものである。例えば、サービス実行サーバ２の状態がサービスＢの立ち上げを終了しサービスＡの立ち上げ中であり、サービスＣ起動までの全体の処理の５０％を終了しているときは、再起動状態確認サーバ８は利用者端末３へその情報を送信し、利用者端末３はその画面に再起動状態が５０％終了している旨を表示する。なお、上記再起動状態確認サーバ８の機能は、サービス受付サーバ１の機能として実現してもよい。
【００３５】
以上、本発明の実施形態を詳述してきたが、具体的な動作は本実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も可能である。例えば、サービス実行サーバ２を現用系と待機系とに冗長化した分散処理システムにおいて、現用系のサービス実行サーバから待機系のサービス実行サーバへと切り替えるときのサービス回復手段としても利用可能である。
【産業上の利用可能性】
【００３６】
本発明は、利用者端末にサービスを提供するサービス提供システムに用いて好適である。
【図面の簡単な説明】
【００３７】
【図１】本発明の実施形態にかかるサービス受付サーバを用いたサービス提供システムを示したブロック図である。
【図２】図１のサービス実行サーバ２の再起動前後において実行されるサービスの一例を示した模式図である。
【図３】図１のサービス状態記憶部１０３で保持するｔ時間内トランザクションテーブルの一例を示した表である。
【図４】図１のサービス状態記憶部１０３で保持するｔ時間内サービス状態テーブルの一例を示した表である。
【図５】図１のサービス実行サーバ２が再起動時に、サービス処理再開部１０５が実行するサービス再開処理を示したフローチャートである。
【図６】図１のサービス実行サーバ２が再起動時に、サービス振分部１０２が実行する予約受付処理を示したフローチャートである。
【図７】図１のサービス受付サーバ１で行う予約受付処理を示した図である。
【図８】図１の利用者端末３で再起動状態を表示する仕組みを示した図である。
【符号の説明】
【００３８】
１ … サービス受付サーバ（サービス受付装置）
２ … サービス実行サーバ（サービス実行装置）
３ … 利用者端末
４ … 情報記憶部
８ … 再起動状態確認サーバ
１０１ … サービス受付部
１０２ … サービス振分部
１０３ … サービス状態記憶部
１０４ … 故障監視部
１０５ … サービス処理再開部
１０６ … 通信部
２０１ … 通信部
２０２ … サービス実行部
２０３ … サービス
２０４ … サービス接続処理部
【技術分野】
【０００１】
本発明は、利用者にサービスを提供するサービス提供システムで用いるサービス再開装置およびサービス再開プログラムに関する。
【背景技術】
【０００２】
従来、利用者端末からのサービス要求メッセージを受信してサービスに必要な処理を実行するサービス実行サーバにおいては、サービス実行サーバ起動後に、サービスに必要なプログラムをサービス実行サーバ内のメモリへロードする等の準備作業が必要である。準備作業が完了後最初にサービス要求メッセージを受信すると、まずそのサービス要求メッセージの処理に要するすべてのシステム資源を確保する作業を行い、次いでサービス要求メッセージの処理を行う。2回目以降のサービス要求メッセージ受信時には、システム資源の確保作業を行う必要がないため、最初のサービス要求メッセージよりも短時間で処理を完了することができる。
【０００３】
サービス実行サーバで使用するファームウェアの更新や、システム異常等によりサービス実行サーバが停止し再起動を行う場合、再起動後に最初のサービス要求メッセージを受信した時点で上述のシステム資源の確保を行うと、最初のサービス要求メッセージの処理完了までの時間が長くなる。そのため、サービス実行サーバ再起動後に上述の準備作業が完了した時点でダミーのサービス要求メッセージを投入し、実際のサービス要求メッセージ到来に先行してシステム資源の確保を行う方法を取っている。なお、本出願に関する従来技術の参考文献として、特許文献1が知られている。
【特許文献１】特開２００２−１４９４３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、上述のサービス実行サーバ再起動後にダミーのサービス要求メッセージを投入する方法では、サービス実行サーバの提供するサービスの種類が増えるにつれ、再起動後にダミーのサービス要求メッセージに対する処理が集中しサービス実行サーバに負荷を与えることとなる。さらに、全てのダミーサービス要求メッセージの処理が終了するまでサービスの開始ができないようなサービス実行サーバにおいては、再起動後のサービス開始に時間がかかる。また、サービス実行サーバ再起動時でサービスが停止した状態では、利用者端末からのサービス要求に対して応答することができない。
【０００５】
特許文献１には、利用者端末とサービス実行サーバとの間にサービス要求サーバを設け、このサービス要求サーバで予めサービスごとに優先度を設定する方法が紹介されている。しかし、サービスの利用状況は利用される時間帯等により流動的に変化するものであり、予めサービスの優先度を決める方法では利用状況に応じた効率的なサービス再開を行うことはできない。また、サービス停止時に利用者端末からのサービス要求に対して応答するができないという課題を解決する方法に関しては具体的な解決策は示されていない。
【０００６】
本発明は上記事情を考慮してなされたもので、その目的は、サービス実行サーバの再起動時におけるサービス再開を利用状況に応じて効率よく実施することおよび、サービス実行サーバ再起動時でサービスが中断している状態においても利用者端末からのサービス要求メッセージに対して応答することが可能なサービス再開装置を提供することにある。
【課題を解決するための手段】
【０００７】
本発明は上記の課題を解決するためになされたもので、請求項1に記載の発明は、複数のサービスのそれぞれにおいて必要となる一連の処理を実行するサービス実行装置に対しサービス再開処理を行うサービス再開装置であって、利用者端末からサービス要求メッセージを受信するサービス受付部と、前記サービス要求メッセージで要求されたサービスの情報を記憶するサービス状態記憶部と、前記サービス実行装置の故障状態を確認する故障監視部と、前記故障監視部で前記サービス実行装置が再起動中であることを確認した場合に、前記サービスの処理再開を行うサービス処理再開部とを備え、前記サービス処理再開部は、前記サービス状態記憶部で記憶した情報に基づいてサービスの優先度を決定する優先度決定手段と、前記優先順位決定手段の結果に基づいて、優先度の高いサービスから順番にサービス再開処理を行うサービス再開手段と、を備えていることを特徴としている。
【０００８】
また、請求項２に記載の発明は、請求項１に記載の発明において、前記サービス状態記憶部は、過去一定時間内における、前記サービスの処理を実施終了した実施終了処理数と前記サービスの処理が実行途中である実行中処理数とを保持し、前記優先度決定手段は、前記サービス実行装置が再起動を行う直前の前記一定時間内における前記実施終了処理数と前記実行中処理数との加算演算処理を行い、加算演算処理の演算結果を優先度とすることを特徴としている。
【０００９】
また、請求項３に記載の発明は、請求項２に記載の発明において、前記加算演算処理は、
前記実施終了処理数と前記実行中処理数とに重み付けを行うことを特徴としている。
【００１０】
また、請求項４に記載の発明は、請求項１から請求項３のいずれか1項に記載の発明において、前記サービス実行装置の再起動時に受信した前記サービス要求メッセージに対して予約を受け付ける予約受付手段と、予約を受け付けたサービス要求メッセージを保存する予約保存手段と、前記優先度決定手段で決定した優先度に基づいてサービス再開に要する時間を推定し、前記推定した時間を前記利用者端末へ通知する推定再開時間通知手段と、前記サービス実行装置の再起動後に前記予約保存手段で保存したサービス要求メッセージを前記サービス実行装置へ送信する送信手段と、を備えていることを特徴としている。
【００１１】
また、請求項５に記載の発明は、複数のサービスのそれぞれにおいて必要となる一連の処理を実行するサービス実行装置に対しサービス再開処理を行うコンピュータに、利用者端末からサービス要求メッセージを受信するサービス受付手順と、前記サービス要求メッセージで要求されたサービスの情報を記憶するサービス状態記憶手順と、前記サービス実行装置の故障状態を確認する故障監視手順と、前記故障監視手順で前記サービス実行装置が再起動中であることを確認した場合に、前記サービス状態記憶手順で記憶した情報に基づいてサービスの優先度を決定する優先度決定手順と、前記優先順位決定手順の結果に基づいて優先度の高いサービスから順番にサービス再開処理を行うサービス再開手順と、前記サービス実行装置の再起動時に受信した前記サービス要求メッセージに対して予約を受け付ける予約受付手順と、予約を受け付けたサービス要求メッセージを保存する保存手順と、前記優先度決定手順で決定した優先度に基づいてサービス再開に要する時間を推定し、前記推定した時間を前記利用者端末へ通知する推定再開時間通知手順と、前記サービス実行装置の再起動後に前記予約保存手順で保存したサービス要求メッセージを前記サービス実行装置へ送信する送信手順と、を実行させるサービス再開プログラムである。
【発明の効果】
【００１２】
本発明によれば、サービス受付サーバでサービスの利用状況を監視し、サービス実行サーバ再起動直前の利用状況からサービスの優先度を決定するため、再起動時に最も必要とされているサービスを優先的に再開することができる。また、サービス実行サーバ再起動時にサービスが中断している間においても、サービス受付サーバが予約を受け付けることが可能になる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して本発明の実施形態について説明する。図１は本発明の実施形態にかかるサービス受付サーバ（サービス受付装置）を用いたサービス提供システムの構成図であり、サービス受付サーバ１、サービス実行サーバ（サービス実行装置）２、利用者端末３、情報記憶部４）とから構成される。
【００１４】
図１において、サービス受付サーバ１は、利用者端末3、３、・・・からのサービス要求メッセージを受信するもので、サービス実行サーバ２は、サービス受付サーバ１の指示に従って利用者が要求するサービスを提供するために必要な一連の処理（トランザクション）を実行するものである。情報記憶部4、４、・・・は、サービス実行サーバ２で実行するサービスのプログラムを保持するものである。ネットワーク５は利用者端末３、３、・・・とサービス受付サーバ１とをつなぐものであり、ネットワーク６はサービス受付サーバ１とサービス実行サーバ２とをつなぐものであり、ネットワーク７はサービス実行サーバ２と情報記憶部４、４、・・・とをつなぐものである。
【００１５】
サービス受付サーバ１内のサービス受付部１０１は、利用者端末３からのサービス要求メッセージを受信するものである。サービス振分部１０２は、サービス受付部１０１で受信したサービス要求メッセージに応じて処理を行うものである（詳細は後述する）。サービス状態記憶部１０３は、受信したサービス要求メッセージで要求されたサービスの情報を保持するものである。故障監視部１０４は、サービス実行サーバ２の状態を確認するものである。サービス処理再開部１０５は、サービス実行サーバ２の再起動後にサービスを再開する処理を制御するものである。通信部１０６はサービス実行サーバ２と通信を行うものである。
【００１６】
サービス実行サーバ２内の通信部２０１は、サービス受付サーバ１との通信を行うものである。サービス実行部２０２、・・・は、サービスを提供するために必要な処理を実行するものであり、サービスごとに１つのサービス実行部がある。サービス２０３、・・・は、各サービス実行部２０２で使用するサービスのプログラムである。サービス接続処理部２０４は、サービス実行サーバ２外部の情報記憶部４と通信を行うものである。
【００１７】
次に、上述した実施形態の動作を図１から図６を参照して説明する。図１において、利用者端末３が送信したサービス要求メッセージは、サービス受付部１０１で受信され、サービス振分部１０２で処理される。サービス振分部１０２は、サービス要求メッセージで要求されたサービスの種類およびそのサービス要求メッセージを受信した時刻をサービス状態記憶部１０３へ書き込む。またサービス振分部１０２は、サービス実行サーバ２が再起動中でないかを故障監視部１０４へ問い合わせ、再起動中でなければサービス要求メッセージを通信部１０６からサービス実行サーバ２の通信部２０１へ送信する。サービス実行サーバ２が再起動中である場合は、サービス要求メッセージに対して予約を受け付ける処理（予約処理）を行うが、この予約処理に関しては後述する。
【００１８】
サービス状態記憶部１０３は、サービス振分部１０２から入力する情報をもとに、利用者端末３から要求されたサービスの種類および、そのサービスの開始・終了時間を記憶する。ここで、サービス状態記憶部１０３で記憶するのは過去一定時間（ｔ秒）におけるサービス利用状況である。
【００１９】
サービス実行サーバ２の通信部２０１がサービス要求メッセージを受信すると、そのサービス要求メッセージをサービス接続処理部２０４へと出力する。サービス接続処理部２０４は、サービス実行部２０２に対して、サービス要求メッセージで要求された処理を行うように指示を出す。サービス実行部２０２における処理の過程で利用者端末３へ情報を送信する場合は、サービス受付サーバ１を経由して送信する。このように、利用者端末３とサービス実行サーバ２とがサービス受付サーバ１を介して情報の送受信を行うことで、サービス実行サーバ２は利用者端末３へサービスを提供する。
【００２０】
続いて、サービス実行サーバ２が、そのサーバで使用するファームウェアの更新やシステム異常等により停止し再起動を行った場合の動作を説明する。図２のＡに示した時点でサービス実行サーバ２が再起動を行うと、図１の故障監視部１０４が再起動を検出する。サービス実行サーバ２の再起動前ｔ秒間のサービス利用状況は、サービス受付サーバ１のサービス状態記憶部１０３で記憶されている。図２の例では、サービス状態記憶部１０３は、図３に示すｔ時間内トランザクション状態テーブルでサービスの種類及びサービスの開始・終了時刻を保持する。また、サービス状態記憶部１０３は、ｔ時間内トランザクション状態テーブルを編集し、図４に示すｔ時間内サービス状態テーブルを作成する。ｔ時間内サービス状態テーブルは、過去ｔ秒の間に実行された、および実行中のサービス数を保持するものである。
【００２１】
図５はサービス実行サーバ２再起動時における、サービス受付サーバ１のサービス処理再開部１０５での処理を示したフローチャートである。故障監視部１０４がサービス実行サーバ２の再起動を検出すると、再起動の情報がサービス処理開始部１０５へと出力される。サービス処理開始部１０５がサービス実行サーバ２再起動の情報を入力すると、サービス状態記憶部１０３で保持するｔ時間内サービス状態テーブルを参照し、サービス再開の優先度を決定し（優先度決定手段）、優先度の高い順に優先順位を付与する（ステップＳ５０１）。
【００２２】
ここで、優先度を決定する方法としては、実行中のトランザクション数（実行中処理数）と実施終了済みのトランザクション数（実施終了処理数）の和、すなわち図４に示したｔ時間内サービス状態テーブルの「計」に示した列の値を用いる（加算演算）。図４の例では、サービスＢの優先度が３（優先順位が１）、サービスＡの優先度が２（優先順位が２）、そしてサービスＣの優先度が１（優先順位が３）となる。
【００２３】
優先度を決定する別の例として、前述の和を求める方法において、実施中のトランザクション数に重み付けを行う方法が考えられる。優先度をＰｒ、実施中のトランザクション数をＸ、実施終了済みのトランザクション数をＹ、ＸのＹに対する重み付け係数をａとおき、優先度Ｐｒ＝ａＸ＋Ｙと定義する。この方法は、例えば、実行中のトランザクション数の多いサービス、すなわちサービス実行サーバの再起動により中断された処理数の多いサービス、を優先して再開するのに最適である。
【００２４】
サービス再開の優先順位が求まると、サービス実行サーバ２の再起動が終了した後（図２のＢの時点）にその優先順位に従ってサービス再開処理を行う（サービス再開手段、図５のステップＳ５０２〜ステップＳ５０７）。サービス再開処理では、まずサービス再開処理部１０５が優先順位１のサービスに対応するダミーのサービス要求メッセージを、ネットワーク６を介してサービス実行サーバ２へ投入する（ステップＳ５０３）。図２の例ではサービスＢの優先順位が１であり、サービスＢに対するダミーのサービス要求メッセージを投入する。
【００２５】
サービス実行サーバ２が上記サービスＢに対するダミーのサービス要求メッセージを受信すると、サービス接続処理部２０４は、サービスＢに必要なプログラムをメモリへロードしサービス要求メッセージに処理の要する全てのシステム資源を確保する等の作業を行うようサービス実行部２０２へ指示を出す。このとき、サービスＢで必要となるプログラムの全体もしくは一部を外部の情報記憶部４が保持する場合は、サービス接続処理部２０４は情報記憶部４から必要なプログラムをダウンロードする。
【００２６】
サービスＢの準備作業が終了し、サービス実行部２０２がダミーのサービス要求メッセージに対する処理を完了すると、サービス処理再開部１０５へ処理完了の通知を行う。この通知により、ダミーのサービスメッセージへの処理が完了したことをサービス処理再開部１０５が認識すると（図５のステップＳ５０４：Ｙｅｓ）、サービスＢのサービス開始処理を行う（ステップＳ５０５）。サービス開始処理においては、サービス処理再開部１０５がサービス振分部１０２へサービスＢの再開が可能であることを通知する。通知を受けたサービス振分部１０２は、サービス実行サーバ２への、利用者端末３からのサービスＢに対するサービス要求メッセージ送信を再開する。
【００２７】
サービス開始処理が終了しサービスＢが再開されると（ステップＳ５０６：Ｙｅｓ）、優先順位が１のサービスＢに対するサービス再開処理が終了し、続いて優先度が２であるサービスＡの再開処理、優先順位が３であるサービスＣの再開処理の順にステップＳ５０２〜ステップＳ５０７の手順を行う。全てのサービスに対して再開処理が終了すると、サービス処理再開部１０５はサービス再開の手順を終了する。
【００２８】
本発明のサービス再開処理では、サービス実行サーバ２の再起動直前におけるサービスの利用状況に応じてサービスの優先度を決定するため、再起動時に必要とされるサービスから優先的に再開するという効率的なサービス再開を行うことが可能である。また、ダミーのサービス要求メッセージの処理を終えた時点でそのサービスを再開するため、全てのダミーサービス要求メッセージを処理した後に全サービスを再開する従来技術と比較して、優先度の高いサービスほど短時間でサービスを再開することができる。
【００２９】
続いて、サービス実行サーバ２が再起動中にサービス振分部１０２が行う前述の予約処理に関して、図６から図８を参照して説明する。図６は予約処理におけるサービス振分部１０２の手順を示したフローチャートである。サービス実行サーバ２が再起動中に、サービス振分部１０２がサービス要求メッセージを入力すると（ステップＳ６０１）、サービス実行サーバ２が故障のため復旧中であり、サービス要求の予約を行うかを利用者端末３へ問い合わせる（ステップＳ６０２）。
【００３０】
図７はサービス受付サーバ１からの問い合わせ時に、利用者端末３で表示される画面の一例であり、利用者はサービス要求の予約を行うかどうかを選択することができる。予約を行うかどうかだけではなく、利用者がその予約を継続する時間を指定する形態を取ることも可能である。
【００３１】
利用者がサービス要求の予約を行う旨を記したデータをサービス受付サーバ１へ送信し、サービス振分部１０２でそのデータが処理されると（予約受付手段、図６のステップＳ６０３：Ｙｅｓ）、サービス振分部１０２はステップＳ６０１で受信したサービス要求メッセージを予約待ち状態として保存する（予約保存手段、ステップＳ６０４）。この後、サービス状態記憶部１０３で保持するｔ時間内サービス状態テーブルを参照し、予約待ちにしたサービスの優先度からサービス再開の優先順位を判定する。サービス振分部１０２は、判定した優先順位からサービス再開にかかる時間を予想し利用者端末３へサービス再開までの予想時間を通知する（推定再開時間通知手段、ステップＳ６０５）。
【００３２】
図５のステップＳ５０５でサービス振分部１０２がサービス再開の通知をサービス処理再開部１０５から入力すると（図６のステップＳ６０６：Ｙｅｓ）、利用者端末３に対してサービス再開を通知する。それとともに、予約していた利用者端末３からのサービス要求メッセージをサービス実行サーバ２へ送信し（送信手段）、利用者端末３へのサービス提供を再開する（ステップＳ６０７）。
【００３３】
サービスが再開されるまで待機するステップＳ６０６において、前述の利用者が予約を継続する時間を指定する形態では、指定された継続時間経過後にサービス振分部１０２が利用者端末３へ予約の解除を通知し、サービス要求メッセージの予約を解除する方法を取ることが可能である。また、予約継続時間の設定可能時間に上限を設け、その上限の時間が経過した後にサービス要求メッセージの予約解除を行うこともできる。
【００３４】
また、サービス実行サーバ２が再起動を行っている間、利用者端末３からサービス要求の予約を受け付けるだけでなく、サービス実行サーバ２の再起動状態を利用者端末３へ通知する方法も考えられる。図８において、再起動状態確認サーバ８は、サービス実行サーバ２と通信を行い、サービス実行サーバ２の再起動状態を取得するものである。例えば、サービス実行サーバ２の状態がサービスＢの立ち上げを終了しサービスＡの立ち上げ中であり、サービスＣ起動までの全体の処理の５０％を終了しているときは、再起動状態確認サーバ８は利用者端末３へその情報を送信し、利用者端末３はその画面に再起動状態が５０％終了している旨を表示する。なお、上記再起動状態確認サーバ８の機能は、サービス受付サーバ１の機能として実現してもよい。
【００３５】
以上、本発明の実施形態を詳述してきたが、具体的な動作は本実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も可能である。例えば、サービス実行サーバ２を現用系と待機系とに冗長化した分散処理システムにおいて、現用系のサービス実行サーバから待機系のサービス実行サーバへと切り替えるときのサービス回復手段としても利用可能である。
【産業上の利用可能性】
【００３６】
本発明は、利用者端末にサービスを提供するサービス提供システムに用いて好適である。
【図面の簡単な説明】
【００３７】
【図１】本発明の実施形態にかかるサービス受付サーバを用いたサービス提供システムを示したブロック図である。
【図２】図１のサービス実行サーバ２の再起動前後において実行されるサービスの一例を示した模式図である。
【図３】図１のサービス状態記憶部１０３で保持するｔ時間内トランザクションテーブルの一例を示した表である。
【図４】図１のサービス状態記憶部１０３で保持するｔ時間内サービス状態テーブルの一例を示した表である。
【図５】図１のサービス実行サーバ２が再起動時に、サービス処理再開部１０５が実行するサービス再開処理を示したフローチャートである。
【図６】図１のサービス実行サーバ２が再起動時に、サービス振分部１０２が実行する予約受付処理を示したフローチャートである。
【図７】図１のサービス受付サーバ１で行う予約受付処理を示した図である。
【図８】図１の利用者端末３で再起動状態を表示する仕組みを示した図である。
【符号の説明】
【００３８】
１ … サービス受付サーバ（サービス受付装置）
２ … サービス実行サーバ（サービス実行装置）
３ … 利用者端末
４ … 情報記憶部
８ … 再起動状態確認サーバ
１０１ … サービス受付部
１０２ … サービス振分部
１０３ … サービス状態記憶部
１０４ … 故障監視部
１０５ … サービス処理再開部
１０６ … 通信部
２０１ … 通信部
２０２ … サービス実行部
２０３ … サービス
２０４ … サービス接続処理部
【特許請求の範囲】
【請求項１】
複数のサービスのそれぞれにおいて必要となる一連の処理を実行するサービス実行装置に対しサービス再開処理を行うサービス再開装置において、
利用者端末からサービス要求メッセージを受信するサービス受付部と、
前記サービス要求メッセージで要求されたサービスの情報を記憶するサービス状態記憶部と、
前記サービス実行装置の故障状態を確認する故障監視部と、
前記故障監視部で前記サービス実行装置が再起動中であることを確認した場合に、前記サービスの処理再開を行うサービス処理再開部とを備え、
前記サービス処理再開部は、
前記サービス状態記憶部で記憶した情報に基づいてサービスの優先度を決定する優先度決定手段と、
前記優先順位決定手段の結果に基づいて、優先度の高いサービスから順番にサービス再開処理を行うサービス再開手段と、
を備えていることを特徴とするサービス再開装置。
【請求項２】
前記サービス状態記憶部は、
過去一定時間内における、前記サービスの処理を実施終了した実施終了処理数と前記サービスの処理が実行途中である実行中処理数とを保持し、
前記優先度決定手段は、
前記サービス実行装置が再起動を行う直前の前記一定時間内における前記実施終了処理数と前記実行中処理数との加算演算処理を行い、加算演算処理の演算結果を優先度とすることを特徴とする請求項１に記載のサービス再開装置。
【請求項３】
前記加算演算処理は、
前記実施終了処理数と前記実行中処理数とに重み付けを行うことを特徴とする請求項２に記載のサービス再開装置。
【請求項４】
前記サービス実行装置の再起動時に受信した前記サービス要求メッセージに対して予約を受け付ける予約受付手段と、
予約を受け付けたサービス要求メッセージを保存する予約保存手段と、
前記優先度決定手段で決定した優先度に基づいてサービス再開に要する時間を推定し、前記推定した時間を前記利用者端末へ通知する推定再開時間通知手段と、
前記サービス実行装置の再起動後に前記予約保存手段で保存したサービス要求メッセージを前記サービス実行装置へ送信する送信手段と、
を備えていることを特徴とする請求項１から請求項３のいずれか１項に記載のサービス再開装置。
【請求項５】
複数のサービスのそれぞれにおいて必要となる一連の処理を実行するサービス実行装置に対しサービス再開処理を行うコンピュータに、
利用者端末からサービス要求メッセージを受信するサービス受付手順と、
前記サービス要求メッセージで要求されたサービスの情報を記憶するサービス状態記憶手順と、
前記サービス実行装置の故障状態を確認する故障監視手順と、
前記故障監視手順で前記サービス実行装置が再起動中であることを確認した場合に、前記サービス状態記憶手順で記憶した情報に基づいてサービスの優先度を決定する優先度決定手順と、
前記優先順位決定手順の結果に基づいて優先度の高いサービスから順番にサービス再開処理を行うサービス再開手順と、
前記サービス実行装置の再起動時に受信した前記サービス要求メッセージに対して予約を受け付ける予約受付手順と、
予約を受け付けたサービス要求メッセージを保存する保存手順と、
前記優先度決定手順で決定した優先度に基づいてサービス再開に要する時間を推定し、前記推定した時間を前記利用者端末へ通知する推定再開時間通知手順と、
前記サービス実行装置の再起動後に前記予約保存手順で保存したサービス要求メッセージを前記サービス実行装置へ送信する送信手順と、
を実行させるためのサービス再開プログラム。
【請求項１】
複数のサービスのそれぞれにおいて必要となる一連の処理を実行するサービス実行装置に対しサービス再開処理を行うサービス再開装置において、
利用者端末からサービス要求メッセージを受信するサービス受付部と、
前記サービス要求メッセージで要求されたサービスの情報を記憶するサービス状態記憶部と、
前記サービス実行装置の故障状態を確認する故障監視部と、
前記故障監視部で前記サービス実行装置が再起動中であることを確認した場合に、前記サービスの処理再開を行うサービス処理再開部とを備え、
前記サービス処理再開部は、
前記サービス状態記憶部で記憶した情報に基づいてサービスの優先度を決定する優先度決定手段と、
前記優先順位決定手段の結果に基づいて、優先度の高いサービスから順番にサービス再開処理を行うサービス再開手段と、
を備えていることを特徴とするサービス再開装置。
【請求項２】
前記サービス状態記憶部は、
過去一定時間内における、前記サービスの処理を実施終了した実施終了処理数と前記サービスの処理が実行途中である実行中処理数とを保持し、
前記優先度決定手段は、
前記サービス実行装置が再起動を行う直前の前記一定時間内における前記実施終了処理数と前記実行中処理数との加算演算処理を行い、加算演算処理の演算結果を優先度とすることを特徴とする請求項１に記載のサービス再開装置。
【請求項３】
前記加算演算処理は、
前記実施終了処理数と前記実行中処理数とに重み付けを行うことを特徴とする請求項２に記載のサービス再開装置。
【請求項４】
前記サービス実行装置の再起動時に受信した前記サービス要求メッセージに対して予約を受け付ける予約受付手段と、
予約を受け付けたサービス要求メッセージを保存する予約保存手段と、
前記優先度決定手段で決定した優先度に基づいてサービス再開に要する時間を推定し、前記推定した時間を前記利用者端末へ通知する推定再開時間通知手段と、
前記サービス実行装置の再起動後に前記予約保存手段で保存したサービス要求メッセージを前記サービス実行装置へ送信する送信手段と、
を備えていることを特徴とする請求項１から請求項３のいずれか１項に記載のサービス再開装置。
【請求項５】
複数のサービスのそれぞれにおいて必要となる一連の処理を実行するサービス実行装置に対しサービス再開処理を行うコンピュータに、
利用者端末からサービス要求メッセージを受信するサービス受付手順と、
前記サービス要求メッセージで要求されたサービスの情報を記憶するサービス状態記憶手順と、
前記サービス実行装置の故障状態を確認する故障監視手順と、
前記故障監視手順で前記サービス実行装置が再起動中であることを確認した場合に、前記サービス状態記憶手順で記憶した情報に基づいてサービスの優先度を決定する優先度決定手順と、
前記優先順位決定手順の結果に基づいて優先度の高いサービスから順番にサービス再開処理を行うサービス再開手順と、
前記サービス実行装置の再起動時に受信した前記サービス要求メッセージに対して予約を受け付ける予約受付手順と、
予約を受け付けたサービス要求メッセージを保存する保存手順と、
前記優先度決定手順で決定した優先度に基づいてサービス再開に要する時間を推定し、前記推定した時間を前記利用者端末へ通知する推定再開時間通知手順と、
前記サービス実行装置の再起動後に前記予約保存手順で保存したサービス要求メッセージを前記サービス実行装置へ送信する送信手順と、
を実行させるためのサービス再開プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００６−３０２０８１（Ｐ２００６−３０２０８１Ａ）
【公開日】平成１８年１１月２日（２００６．１１．２）
【国際特許分類】
【出願番号】特願２００５−１２４８５４（Ｐ２００５−１２４８５４）
【出願日】平成１７年４月２２日（２００５．４．２２）
【出願人】（０００１０２７２８）株式会社エヌ・ティ・ティ・データ (438)
【Ｆターム（参考）】
【公開日】平成１８年１１月２日（２００６．１１．２）
【国際特許分類】
【出願日】平成１７年４月２２日（２００５．４．２２）
【出願人】（０００１０２７２８）株式会社エヌ・ティ・ティ・データ (438)
【Ｆターム（参考）】
[ Back to top ]