(57)【要約】【課題】複数のサービスから構成されるサービスシステムにおいて、平時、警戒時、有事などの外部の状況を踏まえたサービス品質を制御する。【解決手段】複数のサービス提供/利用装置１００及び端末装置１１０が接続したサービスシステムにおいて、サービス品質管理部３０６は、サービス提供部３０２またはサービス利用部３０４（上位レイヤ）から第１のサービスメッセージを受けると、状況レベル管理テーブル３５４から状況レベルを決定し、次に、第１、第２サービス品質定義テーブル３５８、３６０からサービス品質レベルを計算し、その計算結果とサービス品質レベル定義テーブル３５６からサービス品質の仕様を決定し、その仕様から第２のサービスメッセージを作成し、送信先へ送信する。また、第２のサービスメッセージを受けると、そのサービス品質レベルに従って、処理をし、第１のサービスメッセージを作成し、上位レイヤへ渡す。【選択図】図３
2011205277.tif 000002
【特許請求の範囲】
【請求項１】
１以上のサービスの提供および利用を実行するためにサービスメッセージを送受信する複数の装置が通信可能に接続されているサービスシステムにおけるサービス品質制御方法において、
前記装置の記憶部は、
当該装置における外部の状況の状況レベルを示す状況レベル情報と、
前記サービスの種別ごと、かつ、前記状況レベルごとに、当該サービスのサービス品質を示すサービス品質情報と、
前記サービス品質ごとに、当該サービス品質のサービス品質レベルと当該サービス品質仕様とを対応付けるサービス品質レベル情報と、を記憶しており、
前記装置の制御部は、
前記サービスメッセージが、前記装置自身で作成した第１のサービスメッセージであるとき、前記状況レベル情報を参照して、前記状況レベルを特定するステップと、
前記サービス品質情報を参照して、前記第１のサービスメッセージに含まれるサービスの種別について、前記特定した状況レベルに応じたサービス品質を特定するステップと、
前記サービス品質レベル情報を参照して、前記特定したサービス品質に含まれる前記サービス品質レベルに基づいて、前記サービス品質の仕様を特定するステップと、
前記特定した仕様に基づいて、前記サービスメッセージとして他の装置に送信する第２のサービスメッセージを作成するステップとを、実行し、
前記サービスメッセージが、他の装置から受信した前記第２のサービスメッセージであるとき、前記仕様に応じたサービスの利用に要する処理を実行するステップと、
前記第２のサービスメッセージから前記第１のサービスメッセージを作成するステップと、を実行する
ことを特徴とするサービス品質制御方法。
【請求項２】
前記装置は、前記外部の状況に関するイベントの入力を受け付ける入力部を備え、
前記記憶部は、前記イベントと前記状況レベルとを対応付ける状況判定ルールを記憶しており、
前記装置の制御部は、
前記入力部から前記イベントが入力されると、前記状況判定ルールを参照して、前記入力されたイベントに対する前記状況レベルを特定し、前記状況レベル情報を更新するステップと、
前記特定した状況レベルに基づいて、前記第２のサービスメッセージを作成するステップと、を実行する
ことを特徴とする請求項１に記載のサービス品質制御方法。
【請求項３】
前記イベントとは、
（１）前記装置を操作する権限を持つユーザから受け付けた前記状況レベルの変更命令
（２）前記外部の状況を計測する機能を備える前記入力部から入力される計測情報
（３）前記他の装置から受信した前記第２のサービスメッセージ
のいずれかである
ことを特徴とする請求項２に記載のサービス品質制御方法。
【請求項４】
前記サービス品質情報には、前記第２のサービスメッセージの送信先の識別情報が含まれており、
前記装置の制御部は、
前記送信先に基づいて、前記サービス品質の仕様を特定するステップ、を実行する
ことを特徴とする請求項１に記載のサービス品質制御方法。
【請求項５】
前記サービス品質とは、
（１）データ転送性能
（２）データ暗号鍵のサイズ
（３）データキャッシュ機能の利用有無
のうち、少なくとも一つである
ことを特徴とする請求項１に記載のサービス品質制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスシステムにおけるサービス品質制御の技術に関するものである。
【背景技術】
【０００２】
外部環境の急速な変化への対応やソフトウェア及びシステムの再利用性を高めるために、ＳＯＡ（Service Oriented Architecture）という考え方が注目されている。ＳＯＡとは、通信ネットワークで接続された様々なシステムをサービス提供及びサービス利用という形で疎結合的に連携させるアーキテクチャ概念である。現在、ＳＯＡは、企業レベルのシステムを再構築する際の考え方として、全世界的に普及しつつある。
【０００３】
ＳＯＡに基づくサービスシステムは、サービスを提供するシステム及びサービスを利用するシステムから構成される。サービス利用システムは、サービス提供システムに対してサービス要求メッセージを送信し、サービス機能の利用を要求する。サービス提供システムは、サービス要求メッセージを受信すると、サービス処理を実行し、その結果をサービス応答メッセージとして、サービス利用システムへ送信する。このように、サービスシステムは、メッセージを交換することで互いに連携するシステムから構成される。
【０００４】
サービスシステムにおいては、提供する機能だけでなく、サービス品質も重要である。サービス品質とは、非機能要件に位置づけられるものであり、性能、信頼性、セキュリティ、などが挙げられる。このサービス品質は、サービス毎の特性に依存して決定されることになる。例えば、遠隔監視のためのビデオストリーミングサービスでは、通信ネットワーク処理を含む処理の高速性能が求められる。一方、バッチ処理的なサービスシステムであれば、応答性能は比較的要求されない。また、悪意者を含む不特定多数のコンピュータが接続されるインターネット上のサービスシステムであれば、改ざん、成り済まし、盗聴などを防ぐためのセキュリティが必要とされるが、企業内の専用ネットワーク上のサービスシステムであれば、国防で要求されるような強度の高いセキュリティは必要とされないと言える。
【０００５】
従来、サービス品質を確保するための技術が数多く開発されてきた。特許文献１は、ユーザが要求する通信サービス品質を基準としてアプリケーションへのリソース割当を制御する方法を開示している。ここでは、情報サービス側の計算機が、情報システム内のリソース使用状況と通信サービス品質を監視し、リソース環境変動を把握する。このリソース環境変動とユーザが要求する通信サービス品質を踏まえて、リソース割当を最適に設定する。
【０００６】
特許文献２は、通信ネットワークを構成するネットワークノードとネットワーク管理装置が連携して、サービスサーバとクライアント間におけるサービス利用のためのスケジュール及びＱｏＳ（Quality of Service）パラメータを生成し、このパラメータにしたがって、ＱｏＳ制御する方法が開示されている。ネットワーク管理装置は、クライアントから提示されるサービス利用要求条件、サービスサーバが提示するサービスプロパティ、ＱｏＳポリシ、スケジュールポリシ、通信トラフィック統計情報に基づいて、スケジュール及びＱｏＳパラメータを決定する。ここでは、サービス品質としては、通信ネットワーク帯域、通信と処理の遅延時間が例として挙げられている。
【０００７】
特許文献３は、監視システムにおける通信帯域の有効利用方法を開示している。このシステムは、ネットワーク帯域の使用状況を監視し、ネットワークトラフィックが増加したときは、アラーム情報などの制御系のメッセージに優先してネットワーク帯域を割り当てる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００３−６９５６８号公報
【特許文献２】特開２００３−６９６３１号公報
【特許文献３】特開２０００−１５１７１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
従来、サービスシステムにおけるサービス品質を制御するための方法は、予め静的に決められたユーザ要求や通信トラフィックの動的状態に応じた制御方法である。そのため、システムの外部で決定される状況を踏まえてサービス品質を制御することができないという課題があった。
【００１０】
状況としては、平時、警戒時、有事、などの危機的な状況が例として挙げられる。例えば、複数の自治体が連携した防災システムを考えた場合、地震などの天災が発生していないときは、平時、比較的小規模な地震が続いているときは、警戒時、大規模な地震が発生したときは、有事、と捉えることができる。このとき、状況を踏まえたサービス品質制御が必要である。防災システムが、現場のライブ映像サービス、自治体間のメッセージ交換サービス、掲示板サービス、などの複数サービスから構成されるとすると、平時においては、それぞれのサービスは、性能やセキュリティの観点では同等な扱いとなる制御であったとしても、有事においては、メッセージ交換サービスや掲示板サービスよりも、現場のライブ映像サービスの性能を優先するというポリシが考えられる。
【００１１】
本発明の目的は、上記の課題を鑑みたものであり、複数のサービスから構成されるサービスシステムにおいて、平時、警戒時、有事などの外部の状況を踏まえたサービス品質を制御することである。
【課題を解決するための手段】
【００１２】
前記課題を解決するため、本発明では、以下の手順により、システムの外部で決定される状況を踏まえてサービス品質を制御するという課題を解決する。
すなわち、少なくとも一つ以上のサービス提供/利用装置及び端末装置が通信ネットワークで接続されたサービスシステムにおいて、
サービス品質管理部は、サービス提供部、あるいは、サービス利用部から第１のサービスメッセージを受け付けると、状況管理テーブルを検索し、状況レベルを決定し、
次に、サービス品質定義テーブルを参照して、サービスの品質レベルを計算し、計算結果とサービス品質レベル定義テーブルから、サービス品質仕様を決定し、
決定したサービス品質仕様に基づいて、第２のサービスメッセージを作成し、第２のサービスメッセージを送信先へ送信する、
また、サービス品質管理部は、第２のサービスメッセージを受け付けると、第２のサービスメッセージに含まれたサービス品質レベルに従って、処理を行い、第１のサービスメッセージを作成し、サービス提供部、あるいは、サービス利用部へ渡すこと、を特徴とする。
詳細は、後記する。
【発明の効果】
【００１３】
本発明によれば、複数のサービスから構成されるサービスシステムにおいて、平時、警戒時、有事などの外部の状況を踏まえたサービス品質を制御することができる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態に係わるサービスシステムのシステム構成を例示する図である。
【図２】サービス提供/利用装置、あるいは、端末装置のハードウェア構成を例示する図である。
【図３】サービス提供/利用装置、あるいは、端末装置の機能構成を例示する図である。
【図４】第１のサービスメッセージのデータ構造を例示する図である。
【図５】第２のサービスメッセージのデータ構造を例示する図である。
【図６】サービス提供/利用装置、あるいは、端末装置におけるサービスメッセージ処理フローを例示する図である。
【図７】サービス提供/利用装置、あるいは、端末装置における第１のサービスメッセージ処理フローを例示する図である。
【図８】サービス提供/利用装置、あるいは、端末装置における第２のサービスメッセージ処理フローを例示する図である。
【図９】サービス提供/利用装置、あるいは、端末装置におけるイベント処理フローを例示する図である。
【図１０】状況レベル定義テーブルのデータ構造を例示する図である。
【図１１】状況判定ルールテーブルのデータ構造を例示する図である。
【図１２】状況レベル管理テーブルのデータ構造を例示する図である。
【図１３】サービス品質レベル定義テーブルのデータ構造を例示する図である。
【図１４】第１のサービス品質定義テーブルのデータ構造を例示する図である。
【図１５】第２のサービス品質定義テーブルのデータ構造を例示する図である。
【発明を実施するための形態】
【００１５】
以下、本発明を実施するための形態を図面に基づいて詳細に説明する。
【００１６】
図１は、本実施形態に係わるサービスシステムの具体例である防災システムのシステム構成を示すものである。防災システムは、少なくとも１台以上のサービス提供/利用装置１００（１００−Ａ、１００−Ｂ、１００−Ｃ）、及び、少なくとも１台以上の端末装置１１０（１１０−Ａ、１１０−Ｂ、１１０−Ｃ）から構成される。これらの装置は、通信ネットワーク１５０を介して相互に通信を行う。
【００１７】
サービス提供/利用装置１００は、防災に係わるサービス機能（単に、サービスと称する場合がある）の提供や自装置を含む他のサービス提供/利用装置１００が提供するサービス機能の利用を行うものである。サービス機能の例としては、ライブ映像サービス、メッセージ交換サービス、掲示板サービス、が挙げられる。端末装置１１０は、認証されたユーザの操作を受け付けて、サービス提供/利用装置１００が提供するサービス機能を利用するクライアント装置である。また、端末装置１１０は、サービス提供/利用装置１００や他の端末装置１１０が何らかのサービスを利用するのに必要なサービスを提供する。
【００１８】
図２は、サービス提供/利用装置１００と端末装置１１０のハードウェア構成例である。
これらの装置は、中央演算装置であるＣＰＵ（Central Processing Unit）（制御部）２０２、キーボードやマウスなどの入力装置２１０、ハードディスクなどの外部記憶装置２０６や、揮発性の半導体メモリ（ＲＡＭ（Random Access Memory）２０４）などの記憶装置（記憶部）、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ、プリンタなどの出力装置２１２、光磁気メディアなどの記憶媒体２１６を読み書きするための外部メディアインタフェース２１４、通信用の通信インタフェース２０８、がバスなどの内部通信線２５０で接続された構成を持つ汎用的なコンピュータ機器を用いて実現できる。もちろん、コンピュータ機器に限るわけではなく、ユーザに対する入力装置と出力装置、そして通信装置を備えた計算機であれば使用可能である。
【００１９】
サービス提供/利用装置１００と端末装置１１０に備わっている入力装置２１０の中には、センサ装置が含まれる。例えば、位置情報を特定するためのＧＰＳ（Global Positioning System）受信装置、震度計測装置、電磁場計測装置、などがある。
【００２０】
通信ネットワーク１５０は、公衆網、インターネット、ＩＳＤＮ（integrated service digital network）、専用線、ＬＡＮ（Local Area Network）などの有線網や移動通信用基地局や通信用人工衛星を利用した無線網などの通信ネットワークで実現できる。
【００２１】
各装置は、予め装置に設定された通信先相手となる他の装置アドレスを用いて、通信先と接続し、通信を行う。また、ブロードキャスト通信やマルチキャスト通信などを使って、複数の装置と同報的な通信を行ってもよい。さらに、パブリッシュ/サブスクライブ型の通信のように、位置透過型の通信を行ってもよい。
【００２２】
以上の各装置の各機能や各処理部は、それぞれのＣＰＵ２０２が外部記憶装置２０６に格納されたプログラムを実行することにより、具現化される。また、各プログラムは、予め各外部記憶装置２０６に格納されていても良いし、必要に応じて、当該装置が利用可能な、着脱可能な記憶媒体２１６や通信媒体である通信ネットワーク１５０または通信ネットワーク１５０上を伝搬する搬送波やデジタル信号を介して、他の装置から導入されても良い。
【００２３】
図３は、サービス提供/利用装置１００と端末装置１１０のプログラム構成例（ソフトウェア構成例：機能構成例）である。プログラムは、レイヤとして構造化されており、基本的に、各レイヤ間で、機能連携（例：メッセージ交換による機能連携）を行う。各処理部は、メッセージ連携のための入力・出力キューを持つものとする。
【００２４】
サービス提供部３０２は、ライブ映像ストリーミングサービス、メッセージ交換サービス、掲示板サービスなどのサービス機能を提供する。サービス機能の中には、ユーザが利用するサービスだけでなく、制御系のサービスも含まれる。例えば、後述する状況通知サービスは、サービス提供/利用装置１００、あるいは、端末装置１１０において判定された状況に関する情報を他の装置へ通知するサービスである。
【００２５】
サービス利用部３０４は、サービス提供部３０２が提供するサービス機能を利用する部分である。例えば、サービスが、ライブ映像ストリーミングサービスの場合、サービス利用部３０４は、映像ストリーミングデータをユーザに提示するプレイヤー機能を持つ。
【００２６】
サービス品質管理部３０６は、通信機能、セキュリティ機能、データキャッシュ機能などのサービス品質を管理する。さらに、サービス品質管理部３０６は、決定したサービス品質に従って、通信機能を提供する通信機能部３０８、データ暗号機能を提供する暗号機能部３１０、データキャッシュ機能を提供するデータキャッシュ機能部３１２およびその他の機能部を使って、サービス品質を制御する。サービス品質管理部３０６は、後記する複数のデータテーブル、つまり、状況レベル定義テーブル３５０（図１０参照）、状況判定ルールテーブル３５２（状況判定ルール。図１１参照。）、状況レベル管理テーブル３５４（状況レベル情報。図１２参照。）、サービス品質レベル定義テーブル３５６（サービス品質レベル情報。図１３参照。）、第１サービス品質定義テーブル３５８（サービス品質情報。図１４参照。）、第２サービス品質定義テーブル３６０（サービス品質情報。図１５参照。）を利用してサービスメッセージを処理する。状況レベル定義テーブル３５０、状況判定ルールテーブル３５２、状況レベル管理テーブル３５４、サービス品質レベル定義テーブル３５６、第１サービス品質定義テーブル３５８、第２サービス品質定義テーブル３６０は、例えば、外部記憶装置２０６に記憶されている。
【００２７】
オペレーティングシステム部３１４は、サービス提供部３０２、サービス利用部３０４、サービス品質管理部３０６、通信機能部３０８、暗号機能部３１０、データキャッシュ機能部３１２に対して、メモリ管理、プロセス管理、ファイル管理、入出力装置管理、など低レベル機能を提供する。入出力デバイスドライバ部３１６（３１６−Ａ、３１６−Ｂ、３１６−Ｃ・・・）は、図２で示される通信インタフェース２０８、入力装置２１０、出力装置２１２、外部メディアインタフェース２１４、を利用する機能を提供する。
【００２８】
次に、サービス品質管理部３０６の処理について説明する。
図６は、サービス品質管理部３０６が実行するサービスメッセージ処理フロー例である。ステップ６００にて、着目するサービスメッセージが、サービス提供部３０２、あるいは、サービス利用部３０４などの上位レイヤに位置づくプログラムから処理依頼されたサービスメッセージ（第１のサービスメッセージ）であるのか、それとも、他の装置（サービス提供/利用装置１００、あるいは、端末装置１１０）のサービス品質管理部３０６から送信されたサービスメッセージ（第２のサービスメッセージ）なのかどうかを判定する。判定方法としては、例えば、後述するメッセージフォーマットのデータ並びの違いに基づいて判断する。
【００２９】
上位レイヤからの第１のサービスメッセージとは、図４で示すメッセージフォーマットで示される第１のサービスメッセージ４００である。フィールド４０２は、サービスの種別を示すサービスＩＤ（Identifier）を表す。フィールド４０４は、サービス提供部３０２のネットワークアドレスとサービス提供/利用装置１００、あるいは、端末装置１１０内で固有に識別可能なプロセス識別子から構成されるサービス提供元アドレスを表す。フィールド４０６は、サービス利用部３０４のネットワークアドレスとサービス提供/利用装置１００、あるいは、端末装置１１０内で固有に識別可能なプロセス識別子から構成されるサービス提供先アドレスを表す。フィールド４０８は、フィールド４１０に格納されるデータの長さを表す。データを格納するフィールド４１０の具体的なフォーマットは、サービス毎に定義される。
【００３０】
第１のサービスメッセージの具体例は、状況通知サービスメッセージ４２０とライブ映像サービスメッセージ４４０である。状況通知サービスメッセージ４２０にとってのフィールド４１０は、状況（平時、警戒時、有事などの外部の状況）を示すフィールド４３０、サービスメッセージ作成日時である時刻情報を示すフィールド４３２、サービスメッセージ作成位置である位置情報を示すフィールド４３４から構成される。サービスメッセージ作成位置は、サービス提供/利用装置１００に備わる入力装置２１０の一種である位置特定のための装置（例：ＧＰＳ受信装置）から得られたものである。なお、状況通知サービスメッセージ４２０にとってのフィールド４０２、４０４、４０６、４０８はそれぞれフィールド４２２、４２４、４２６、４２８から構成される。
【００３１】
また、ライブ映像サービスメッセージ４４０にとってのフィールド４１０は、映像データが格納されるフィールド４５０から構成され、ライブ映像サービスメッセージ４４０にとってのフィールド４０２、４０４、４０６、４０８はそれぞれフィールド４４２、４４４、４４６、４４８から構成される。
【００３２】
一方、第２のサービスメッセージとは、図５で示すメッセージフォーマットで示される第２のサービスメッセージ５００である。サービス品質管理部３０６は、第１のサービスメッセージ４００を入力として、第２のサービスメッセージ５００を作成する。フィールド５０２は、サービスの種別を示すサービスＩＤを表す。フィールド５０４は、サービス提供部３０２のネットワークアドレスとサービス提供/利用装置１００、あるいは端末装置１１０内で固有に識別可能なプロセス識別子から構成されるサービス提供元アドレスを表す。フィールド５０６は、サービス利用部３０４のネットワークアドレスとサービス提供/利用装置１００、あるいは端末装置１１０内で固有に識別可能なプロセス識別子から構成されるサービス提供先アドレスを表す。フィールド５０８は、後述するサービス品質に係わるレベル値であるサービス品質レベルが格納される。フィールド５１０は、フィールド５１２に格納されるデータの長さを表す。データを格納するフィールド５１２の具体的なフォーマットは、サービス毎に定義される。また、フィールド５０８に格納されるサービス品質レベルを踏まえた処理済みデータが格納される。
【００３３】
第２のサービスメッセージの具体例は、状況通知サービスメッセージ５２０とライブ映像サービスメッセージ５４０である。状況通知サービスメッセージ５２０にとってのフィールド５１２は、状況、サービスメッセージ作成日時である時刻情報、サービスメッセージ作成位置である位置情報を暗号化した暗号化データを示すフィールド５３２から構成される。なお、状況通知サービスメッセージ５２０にとってのフィールド５０２、５０４、５０６、５０８、５１０はそれぞれフィールド５２２、５２４、５２６、５２８、５３０から構成される。
【００３４】
また、ライブ映像サービスメッセージ５４０にとってのフィールド５１２は、映像データを暗号化した暗号化データが格納されるフィールド５５２から構成され、ライブ映像サービスメッセージ４４０にとってのフィールド５０２、５０４、５０６、５０８、５１０はそれぞれフィールド５４２、５４４、５４６、５４８、５５０から構成される。
【００３５】
サービス品質レベル値が格納されるフィールド５２８および５４８の中には、データ転送性能レベル値、暗号通信レベル値、データ可用性レベル値を表す数値が連結されている（「311」、「313」など）。また、データが格納されるフィールド５３２および５５２の中には、サービス品質レベルで示される暗号化処理仕様に基づいた暗号化データが格納されている。
【００３６】
図６に戻り、サービス品質管理部３０６は、サービスメッセージ判定処理６００において、第１のサービスメッセージであると判断すると（ステップ６００でＹｅｓ）、ステップ６０２で、第１のサービスメッセージ処理を実行する。ここで、第１のサービスメッセージ処理の具体的な処理内容について説明する。
【００３７】
図７は、第１のサービスメッセージ処理例を示すフローチャートである。まず、サービス品質管理部３０６は、ステップ７００で、第１のサービスメッセージ４００の解析を行い、各フィールド（４０２、４０４、４０６、４０８、４１０）に格納されたデータを取得する。次に、ステップ７０２で、図１２で示す状況レベル管理テーブル３５４を参照し、フィールド１２０４に格納された状況レベルの値を取得し、状況レベルを決定する。なお、図１２で示す情報レベル管理テーブル３５４の更新方法については、別途、図９を使って後述する。また、状況レベル管理テーブル３５４に関する説明は図１２を使って後述する。
【００３８】
サービス品質管理部３０６は、ステップ７０４にて、図１４で示す第１サービス品質定義テーブル３５８、図１５で示す第２サービス品質定義テーブル３６０を参照し、個々の（第１の、第２の）サービス品質レベルの総和を計算する。そのために、まず、解析した第１のサービスメッセージ４００に含まれるサービスＩＤ（フィールド４０２）とステップ７０２で決定した状況レベル値とそれぞれ一致する、第１サービス品質定義テーブル３５８のフィールド１４０２に格納されたサービスＩＤとフィールド１４０４に格納された状況レベル値を持つ行を特定する。
【００３９】
次に特定された行に含まれるデータ転送性能レベル１４０６、暗号通信レベル１４０８、データ可用性レベル１４１０の値を取得し、一時的にそれぞれの値（つまり、第１のサービス品質レベル値）を記憶する。
【００４０】
次に、図１５で示す第２サービス品質定義テーブル３６０を参照し、解析した第１のサービスメッセージ４００に含まれるサービスＩＤ（フィールド４０２）とサービス提供者アドレス（フィールド４０６）とそれぞれ一致する、第２サービス品質定義テーブル３６０のフィールド１５０２に格納されたサービスＩＤとフィールド１５０４に格納された送信先を持つ行を特定する。
【００４１】
次に、特定された行に含まれるデータ転送性能レベル１５０６、暗号通信レベル１５０８、データ可用性レベル１５１０の値を取得し、一時的にそれぞれの値（つまり、第２のサービス品質レベル値）を記憶する。
【００４２】
次に、第１のサービス品質レベル値と第２のサービス品質レベル値の総和を計算する。例えば、サービスとしてライブ映像サービスがあって、状況レベルが、３であり、第２のサービスメッセージ５００の送信先が、サービス提供/利用装置１００、あるいは端末装置１１０となる意思決定者端末（意思決定者端末のアドレス：送信先の識別情報）であるとすれば、データ転送性能レベルは、３＋３＝６、暗号通信レベルは、１＋１＝２、データ可用性レベルは、３＋１＝４、と計算される。
【００４３】
次に、サービス品質管理部３０６は、ステップ７０６で、ステップ７０４で求めたサービス品質レベル値を正規化する。例えば、１〜３までの正数値へ正規化する。このとき、先に述べた例と同じく、サービスとしてライブ映像サービスがあって、状況レベルが、３であり、第２のサービスメッセージ５００の送信先が、サービス提供/利用装置１００、あるいは端末装置１１０となる意思決定者端末（意思決定者端末のアドレス：送信先の識別情報）であるとすれば、データ転送性能レベル値６は、３へ正規化され、暗号通信レベル値２は、１に正規化され、データ可用性レベル値４は、２と正規化される。
【００４４】
続いて、ステップ７０８で、図１３で示すサービス品質レベル定義テーブル３５６を参照して、正規化されたサービス品質レベル値に対応するサービス品質仕様を決定する。例えば、サービス品質レベル定義テーブル３５６は、３つのデータテーブル（データ転送性能レベル定義テーブル１３００、暗号通信レベル定義テーブル１３１０、データ可用性レベル定義テーブル１３２０）から構成されている（図１３参照）。
【００４５】
データ転送性能レベル定義テーブル１３００は、データ転送性能レベル値（フィールド１３０２に格納）に対する仕様（フィールド１３０４に格納）を管理する。仕様の例としては、ＲＦＣ  ２４７４などで定義されたＩＰ（Internet Protocol）ネットワーク通信フローのＱｏＳ保証方式であるDifferentiated Services（DiffServ）で規定される処理優先度クラスで実現できる。
【００４６】
暗号通信レベル定義テーブル１３１０は、暗号通信レベル値（フィールド１３１２に格納）に対する仕様（フィールド１３１４に格納）を管理する。具体的には、例えば、米国の共通鍵暗号方式であるＦＩＰＳ  ＰＵＢ  １９７で規定されたAdvanced Encryption  Standardの暗号鍵の長さ（鍵の長さが大きいほど、セキュリティ強度が高くなる）が管理される。
【００４７】
データ可用性レベル定義テーブル１３２０は、データ可用性レベル（フィールド１３２２に格納）に対応する仕様を管理する。具体的には、第１のサービスメッセージ４００のデータキャッシュ機能に関する仕様である。データキャッシュ機能とは、受信した第１のサービスメッセージ４００を一時的に記憶領域に格納する機能とその一時記憶した第１のサービスメッセージ４００を再度アクセスすることができる機能である。データキャッシュ機能により、通信ネットワーク上の通信トラブルにより、データ再送が必要となったとしても、上位レイヤのサービス提供部３０２やサービス利用部３０４は、第１のサービスメッセージ４００を再作成する必要がないというメリットがある。データキャッシュの方法としては、一つのサービス提供/利用装置１００、あるいは、端末装置１１０の中で閉じて、データキャッシュするだけでなく、他のサービス提供/利用装置１００、あるいは、端末装置１１０へデータキャッシュ対象である第１のサービスメッセージ４００を送信し、複数のサービス提供/利用装置間で同じ第１のサービスメッセージ４００を共有する方法でもよい。
【００４８】
これらのサービス品質レベル定義テーブル３５６（データ転送性能レベル定義テーブル１３００、暗号通信レベル定義テーブル１３１０、データ可用性レベル定義テーブル１３２０）を参照し、先に述べた例と同じく、サービスとしてライブ映像サービスがあって、状況レベルが、３であり、第２のサービスメッセージ５００の送信先が、サービス提供/利用装置１００、あるいは端末装置１１０となる意思決定者端末（意思決定者端末のアドレス：送信先の識別情報）の場合、サービス品質仕様は、以下のようになる。
・データ転送性能仕様は、DiffServ  金クラス（データ転送性能レベル値３（正規化））
・暗号通信仕様は、AES 128ビット鍵長（暗号通信レベル値１（正規化））
・データ可用性仕様は、キャッシュ有効（データ可用性レベル値２（正規化））
以上から、サービス品質管理部３０６は、状況を踏まえて、サービス品質と位置づけられるデータ転送性能、暗号通信、データ可用性に対応するサービス品質仕様を決定する。
【００４９】
続いて、ステップ７１０にて、サービス品質管理部３０６は、ステップ７０８で決定したサービス品質仕様に基づいて、第１のサービスメッセージ４００から第２のサービスメッセージ５００を作成する。このとき、サービス品質管理部３０６は、通信機能部３０８、暗号機能部３１０、データキャッシュ機能部３１２が提供する機能を利用する。第２のサービスメッセージ５００において、フィールド５０２が示すサービスＩＤ、フィールド５０４が示すサービス提供元アドレス、フィールド５０６が示すサービス提供先アドレスは、それぞれ、第１のサービスメッセージ４００におけるフィールド４０２が示すサービスＩＤ、フィールド４０４が示すサービス提供元アドレス、フィールド４０６が示すサービス提供先アドレスと同じ値となる。
【００５０】
フィールド５０８には、サービス品質レベル定義テーブル３５６で定義されるサービス品質レベル値（フィールド１３０２、１３１２、１３２２）が格納されている。例えば、データ転送性能レベル値、暗号通信レベル値、データ可用性レベル値、が格納されている。サービス品質管理部３０６は、このフィールド５０８のサービス品質レベル値に基づいて、フィールド４１０に格納されたデータを処理する。例えば、先に述べた例と同じく、サービスとしてライブ映像サービスがあって、状況レベルが、３であり、送信先が、意思決定者端末（意思決定者端末のアドレス）の場合、フィールド５１２に格納されるデータは、以下のデータから構成される。
・データ転送性能に関する処理結果：処理結果無し
・暗号通信に関する処理結果：フィールド４１０に格納されたデータをAES 128ビット鍵長で暗号化したデータ
・データ可用性に関する処理結果：フィールド５１２に格納されるデータのキャッシュ
【００５１】
最後に、サービス品質管理部３０６は、ステップ７１２で、作成した第２のサービスメッセージ５００をフィールド５０６に格納されるサービス提供先アドレスで示されるサービス提供/利用装置１００、あるいは端末装置１１０へ送信する。このように、第２のサービスメッセージ５００を、通信ネットワーク１５０に接続したサービス提供/利用装置１００、あるいは端末装置１１０の間で送受信することにより、第２のサービスメッセージ５００を受信した他のサービス提供/利用装置１００、あるいは端末装置１１０のサービス品質管理部３０６が、どのようなサービス品質で処理されているのかどうかを認識することが可能となる。その結果、適切な品質レベルを備えたデータ転送処理（データ転送処理における優先処理など）、暗号通信処理（復号処理など）、データ可用性処理（キャッシュ処理など）、を行うことが可能となる。また、サービス提供部３０２およびサービス利用部３０４は、サービス品質処理に係わる処理コードを含む必要がないため、サービス提供部３０２およびサービス利用部３０４の開発コストや改良コストはそれほどかからないというメリットがある。
【００５２】
図６に戻り、ステップ６００において、サービス品質管理部３０６が、第２のサービスメッセージであると判定すると（ステップ６００でＮｏ）、ステップ６０４にて、他のサービス提供/利用装置１００または他の端末装置１１０のサービス品質管理部３０６から受信した第２のサービスメッセージに対する第２のサービスメッセージ処理を実行する。ここで、第２のサービスメッセージ処理の具体的な処理内容について説明する。
【００５３】
図８は、第２のサービスメッセージ処理例を示すフローチャートである。まず、サービス品質管理部３０６は、ステップ８００にて、第２のサービスメッセージに含まれた、フィールド５０８に格納されたサービス品質レベルを特定する。次に、ステップ８０２にて、特定したサービス品質レベルに応じた処理を実行する。前記処理とは、サービスの利用に必要となる前処理であり、例えば、サービス品質仕様として、ＡＥＳによるデータ暗号化であれば、データを復号する処理が行われる。
【００５４】
次に、ステップ８０４にて、第２のサービスメッセージ５００から第１のサービスメッセージ４００を作成する。第１のサービスメッセージ４００を作成するときには、少なくとも第２のサービスメッセージ５００のフィールド５０８のサービス品質レベルを除く。
次に、ステップ８０６にて、作成した第１のサービスメッセージ４００を上位レイヤであるサービス提供部３０２、あるいは、サービス利用部３０４へ送信する。
【００５５】
図６に戻り、ステップ６０６において、マシン、つまり、サービス提供/利用装置１００または端末装置１１０の停止があったか否かを判定する。停止していれば（ステップ６０６でＹｅｓ）、サービスメッセージ処理全体を終了し、そうでなければ（ステップ６０６でＮｏ）ステップ６００に戻る。
【００５６】
次に、外部の状況が変わるなどして、何らかのイベントが発生したときの処理について説明する。
図９は、サービス提供/利用装置１００、あるいは、端末装置１１０におけるイベント処理例を示すフローである。この処理において、サービス品質管理部３０６は、状況レベル管理テーブル３５４（図１２参照）を管理する。
【００５７】
まず、ステップ９００にて、サービス品質管理部３０６は、イベントを受信する。ここで言うイベントとは、例えば、以下の３種類の入力情報を表す。
（１）第１のイベント：サービス提供/利用装置１００、あるいは端末装置１１０を操作する権限を持つユーザから受け付けた状況レベルの変更命令
（２）第２のイベント：ＧＰＳ装置、地震震度計装置、などの計測機能を持つ入力装置２１０から受け付けた計測情報（例えば、緯度・経度情報、震度、など）
（３）第３のイベント：通信ネットワーク１５０上のサービス提供/利用装置１００、あるいは端末装置１１０から受信した状況通知サービスメッセージ５２０（第２のサービスメッセージ５００）
【００５８】
次に、サービス品質管理部３０６は、状況判定ルールテーブル３５２を参照し、状況レベルを決定する（ステップ９０２）。状況判定ルールテーブル３５２は、図１１に示されており、フィールド１１０２が示す判定ルールＩＤ、フィールド１１０４が示す判定ルールから構成される。サービス品質管理部３０６は、権限を持ったユーザの操作（第１のイベント）を受け付けて、そのイベントについて、フィールド１１０２が示す判定ルールＩＤに対応する判定ルールを解釈し、イベントが判定ルールに該当するのかどうかを判断する。サービス品質管理部３０６は、第２のイベントおよび第３のイベントを受信すると、全ての判定ルールＩＤに対応する判定ルールを解釈し、各イベントが判定ルール該当するのかどうかを判断する。
【００５９】
さらに、図１０に示す状況レベル定義テーブル３５０を参照し、状況レベルを決定する。状況レベル定義テーブル３５０は、状況レベルの値が格納されるフィールド１００２と、外部の状況を示す仕様の値が格納されるフィールド１００４とを備えている。例えば、第２のイベントとして、震度６、という計測情報が入力されると、図１１に示される判定ルールＩＤ１１０２に格納された判定ルールであるＲ００３に従い、状況レベルを有事（＝状況レベル３）と決定する。なお、該当する判定ルールが複数あった場合は、判定ルールＩＤのＲ０００に従い、一番大きな値を持つ状況レベルとする。
【００６０】
サービス品質管理部３０６は、ステップ９０４で、決定した状況レベルの値を、図１２で示す状況レベル管理テーブル３５４に設定することで、状況レベル管理テーブル３５４を更新する。状況レベル管理テーブル３５４は、状況レベルを設定した時刻情報を設定時刻として格納するフィールド１２０２、決定した状況レベルが格納（設定される）されるフィールド１２０４、状況レベル判定の根拠を示す判定ルールＩＤを根拠ルールとして格納するフィールド１２０６から構成される。フィールド１２０６の根拠ルールは、状況判定ルールテーブル３５２のフィールド１１０２が示す判定ルールＩＤから取得される。
【００６１】
次に、ステップ９０６にて、ステップ９０４で設定した状況レベルを含んだ状況通知サービスメッセージ５２０を作成する。次に、ステップ９０８にて、状況通知サービスメッセージ５２０を他のサービス提供/利用装置１００および端末装置１１０へ送信する。
【００６２】
以上、本実施形態によれば、サービス提供/利用装置１００、あるいは、端末装置１１０は、外部の状況を管理し、外部の状況に基づくサービス品質を選択する。その結果、サービスシステムは、各装置が置かれた時間や場所によって変化が生じる状況に追随して適切なサービス品質によるサービス提供及びサービス利用を実現することができる。
【００６３】
前記した各実施形態は、本発明を実施するために好適のものであるが、その実施形式はこれらに限定されるものでなく、本発明の要旨を変更しない範囲内において種々変形することが可能である。
【００６４】
例えば、ハードウェア、ソフトウェア、各フローチャート等の具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【００６５】
なお、前記実施形態は、ＢＣＭ（Business Continuity Management）を実現するために、企業内、企業間、複数組織間で連携して動作する業務システムに組み込むことが可能である。
【符号の説明】
【００６６】
１００    サービス提供/利用装置（装置）
１１０    端末装置（装置）
１５０    通信ネットワーク
２０２    ＣＰＵ（制御部）
２０４    ＲＡＭ（記憶部）
２０６    外部記憶装置（記憶部）
３０２    サービス提供部
３０４    サービス利用部
３０６    サービス品質管理部
３０８    通信機能部
３１０    暗号機能部
３１２    データキャッシュ機能部
３１４    オペレーティングシステム部
３１６    入出力デバイスドライバ部
３５０    状況レベル定義テーブル
３５２    状況判定ルールテーブル（状況判定ルール）
３５４    状況レベル管理テーブル（状況レベル情報）
３５６    サービス品質レベル定義テーブル（サービス品質レベル情報）
３５８    第１サービス品質定義テーブル（サービス品質情報）
３６０    第２サービス品質定義テーブル（サービス品質情報）
【図１】
2011205277.tif 000003
【図２】
2011205277.tif 000004
【図３】
2011205277.tif 000005
【図４】
2011205277.tif 000006
【図５】
2011205277.tif 000007
【図６】
2011205277.tif 000008
【図７】
2011205277.tif 000009
【図８】
2011205277.tif 000010
【図９】
2011205277.tif 000011
【図１０】
2011205277.tif 000012
【図１１】
2011205277.tif 000013
【図１２】
2011205277.tif 000014
【図１３】
2011205277.tif 000015
【図１４】
2011205277.tif 000016
【図１５】
2011205277.tif 000017