JP2009157444A - サービス提供システム、ゲートウェイ、およびサーバ - Google Patents

Abstract

【課題】
コンテンツをサーバで集中管理することなく，大規模なコンテンツ配信システムを実現する。
【解決手段】
クライアント101，サービスゲートウェイ103，サーバ106が互いにネットワーク102、105を介して接続されているサービス提供システムにおいて，クライアント101は，サーバ106へのメッセージをサービスゲートウェイ103経由で送信する。サービスゲートウェイ103は，クライアント101からのメッセージの処理方法をメッセージ内容の一部を含んだメッセージを用いてサーバ106に問い合わせる。サーバ106は，サービスゲートウェイ103からの処理方法問い合わせに対して，処理方法を記載したプログラムを返答し，サービスゲートウェイ103は受け取った処理方法に基づいてクライアント101からのメッセージ処理を行う。
【選択図】図１

Description

本発明は，分散環境におけるネットワークサービス提供のためのシステムに関するものである。

1990年代に大きな発展を遂げたワールドワイドウェブ(以下ウェブ)は，2007年現在多くのネットワークサービスの基盤となっている。

従来のネットワークサービスは，ユーザが要求したコンテンツをサーバが返答する，というダウンロード中心のデータの流れが支配的であった。しかし，近年，Peer-to-Peer(P2P)型の通信形態や，ブログや画像投稿サイトなどのConsumer Generated Media（CGM）の浸透により，クライアント側からサーバに対して情報を送信するというアップロード型のトラフィックが増加しつつある。また，映像を使った監視などアップロードのみを主体にしたサービスも現れている。

現在の物理ネットワークは，アップロードとダウンロードを比べた場合にダウンロードが圧倒的に多い，という前提で構築されている。例えば，多くの家庭でインターネット接続に使われているAsymmetric Digital Subscriber Line(ADSL)は，アップリンクと比べダウンリンクに広い帯域を割り当てている。また，ダウンロードを減らすことがトラフィック削減につながるため，ダウンロードされたコンテンツを途中のノードにキャッシュすることや，Contents Delivery Network(CDN)技術を用いて，あらかじめユーザに近い位置にコンテンツを配送しておくということが行われていた。

しかし，これらの技術ではアップロードトラフィックの増大による以下の問題に対処することはできない。第一に，アップロード先であるサーバは少数の拠点に置かれているため，広域分散したクライアント群からアップロードが同時並行的に行われると，サーバに大きな負荷がかかる。第二に，クライアント群からサーバに向けて次第にトラフィックが集約されることになるため，ある点において回線容量を超えた場合そこで輻輳が発生し，ネットワークの利用効率を著しく低下させることになる。第三に，サービス提供者はユーザが投稿する情報の量に対応できるよう，あらかじめ大量のストレージを用意する必要がある。

ウェブアクセスの高速化に使われているキャッシュシステムは，クライアントの要求に対して返答されたコンテンツがキャッシュされるのが一般的であり，要求自体をキャッシュすることは行っていない。これは，一般的なウェブサービスが，サーバにアップロードコンテンツを転送しない限り次の処理が実行できないというシステムになっている点に起因する。

特許文献１で開示されているキャッシュ・サーバでは，ファイルのアップロード時に，通信経路にあるキャッシュ上に一時的にその内容をバッファし，回線が空いているときなどにその内容を転送する。また，まだサーバに転送されていないコンテンツに対してのアクセスがサーバに対して行われた場合，サーバはキャッシュからコンテンツを取得したのちに要求に対する返答を行う。

特開2002-196969号公報

上述の従来例では，クライアントに返答するためのコンテンツは最終的にはサーバ上に置かれることを想定しており，トラフィック集中のピークは抑えられるがサーバに向かう総トラフィック量は抑えられず，またサーバにおくストレージの量も削減できない。

本発明の課題は，アップロードトラフィックが与える回線・サーバへの負荷集中をなくすこと，更にはサービス提供開始時におけるサービス事業者のストレージに対する莫大な設備投資を不要とすることが可能なシステムを提供することにある。

本発明の他の課題は，アップロードされたコンテンツが通信経路上の装置に格納されている場合であってもそのままサービスを提供可能とするために，通信経路上の装置において要求に対してコンテンツから返答を動的に生成することを可能とし，通信経路上の装置において永続的にサービスに必要なコンテンツを格納するシステムを提供することにある。

上記の課題を解決するために，本発明においては、クライアント，サービスゲートウェイ，サーバが互いにネットワークを介して接続されているサービス提供システムであって，クライアントは，サーバへのメッセージをサービスゲートウェイを経由させて送信し，サービスゲートウェイは，クライアントからのメッセージの処理方法をメッセージ内容を含んだメッセージを用いてサーバに問い合わせ，サーバは，このサービスゲートウェイからの処理方法問い合わせに対して，処理方法を返答し，サービスゲートウェイは受け取った処理方法に基づいてクライアントからのメッセージ処理を行う構成とする。

また、本発明においては、上記の課題を解決するため、ネットワークを介してクライアント，及びサーバに接続されるサービスゲートウェイであって，処理部と、記憶部と、ネットワークインタフェースを有し、このネットワークインタフェースは、クライアントからサーバへ送信される第一のメッセージを受信し，処理部は，第一のメッセージの処理方法を、第一のメッセージの内容を含んだ第二のメッセージを用いてサーバに問い合わせ、サーバから返答された処理方法を受け取り，受け取った処理方法に基づいて、第一のメッセージの処理を行い、生成された返答メッセージをクライアントに送るサービスゲートウェイを提供する。

更に、本発明においては、ネットワークを介してサービスゲートウェイ経由でクライアントに接続されるサーバであって，処理部と、記憶部と、ネットワークインタフェースを有し、このネットワークインタフェースは、クライアントからサーバへ送信される第一のメッセージを受信したサービスゲートウェイから、第一のメッセージの処理方法を問い合わせるための、第一のメッセージの内容を含んだ第二のメッセージを受け取り、その処理部は，第二のメッセージに基づき、第一のメッセージの処理方法、好適には、返答メッセージのテンプレートとテンプレートの空欄を埋めるための生成ロジックの組を生成するサーバを提供する。

本発明によれば、サーバにアップロードされるデータをサービスゲートウェイ上に蓄積することで，サービスゲートウェイとサーバ間にあるネットワークの必要帯域を削減することができる。

更に，クライアントから物理的に近い位置に存在するサービスゲートウェイ上で返答を生成することにより，クライアントにおける要求-返答のターンアラウンドタイムを高速化することが可能となる。

また更に，コンテンツ自体はサービスゲートウェイのストレージに格納するため，そのストレージに対する投資をアップロード者自身が行えば，サービス提供者がサービス開始時に必要なストレージに対する設備投資を削減することが可能となる。

本発明の種々の実施例を説明するに先立ち、本発明のサービス提供システムの概略構成の一例について、図１を用いて説明する。

図1にサービス提供システムの全体構成図を示す。クライアント101，サービスゲートウェイ103，サーバ106は，アクセス網102，コア網105といったネットワークを介して接続されている。クライアント101は，サーバ106への第一のメッセージを、サービスゲートウェイ103を経由させて送信し，サービスゲートウェイ103は，クライアント101からのメッセージの処理方法を、受信したメッセージ内容の一部を含んだ第二のメッセージを用いてサーバ106に問い合わせる。サーバ106は，サービスゲートウェイ103からの処理方法問い合わせに対して，処理方法を記載したプログラムを返答し，サービスゲートウェイ103は受け取った処理方法に基づいてクライアント101からのメッセージ処理を行う。これにより，サーバ106にはクライアント101からのメッセージの一部のみが到達することになり，トラフィックの削減を実現可能になる。

サービスゲートウェイ103は，サーバから受け取った処理方法をサービスゲートウェイ103内の記憶部内に格納してもよい。これにより，クライアント101からの2回目以降の要求に対してサーバ106にアクセスする必要が無くなる。

サービスゲートウェイ103は，処理方法に従って生成されたクライアント101への返答メッセージをサービスゲートウェイ103の記憶部内に格納してもよい。これにより，2回目以降の要求に対して，静的なコンテンツと比べ負荷の高い返答生成処理を行うコストを削減できる。

また，サービスゲートウェイ103は，処理方法に従って解析したクライアント101からのメッセージの一部あるいは全部を，サービスゲートウェイ103の記憶部内に格納してもよい。

そして，記憶部に格納されたデータに対してサービスゲートウェイ103内で一意な識別子を付与し，識別子をサーバ106に送信する。これにより，画像の登録などのサイズの大きな要求を受けたとき，サービスゲートウェイ上103上の記憶部上に大きなコンテンツを格納し，そのメタ情報(画像の格納位置，説明，タイトルなど)のみをサーバ106が管理することでサーバ106側の記憶容量を削減可能である。

サーバ106における処理方法の記述方法は，好適には返答メッセージのテンプレート，およびテンプレートの空欄を埋めるためのプログラムの組で表現する。サービスゲートウェイは，このテンプレートの空欄に対し，プログラムを実行した結果を埋め込むことで動的なコンテンツを生成する。

サービスゲートウェイ103では，クライアント101をメッセージに含まれる認証トークンによって識別する。ここでいう認証トークンとは，HTTPにおける認証ヘッダ(Authorization Header)などをさす。そして，この認証トークンを用いて要求の処理の可否を判定することも可能である。

また，処理方法のプログラムとして、広告サーバなどの外部のサーバから返答メッセージ生成に必要な情報を取得するための手段・方法を記述することで，広告提供者から広告を受け取り，その内容をコンテンツに埋め込む，という処理も可能となる。

第一の実施例での分散サービス提供システムでは，Webベースの画像登録システムについて記述する。図2は，実施例１の分散サービス提供システムの構成の一例を示す図である。

実施例１の分散サービス提供システムは，クライアント101-1〜2，アクセス網102-1〜3，サービスゲートウェイ103-1〜3，コア網105を備える。

サービスゲートウェイ103は，図3に示すように中央処理部（Central Processing Unit, CPU）301，半導体メモリ302，二次記憶303，ネットワークインタフェース304を備えるコンピュータである。半導体メモリ302と二次記憶303に関しては本実施例では同一視して記憶部（メモリ）として扱うため，以後は両者を統合して単にメモリ305と呼称する。データを送受信するネットワークインタフェース304はアクセス網102，コア網105に接続されている。CPU301は、これから順次説明される、サービスゲートウェイ103の機能を対応するプログラムを処理することにより実現する。

サーバ106，クライアント101もサービスゲートウェイ103と同様の構成をとるコンピュータである。ただし，メモリ305内に書き込まれている情報，およびネットワークインタフェース304の接続先がアクセス網102になっている点が異なる。

図4A、４B、４Cにサービスゲートウェイ103がそのメモリ305にもつテーブル群を示す。

図4Aに示すパーソナルストレージ401は，ユーザごとにコンテンツを格納するためのテーブルであり，登録者ID402，ファイルID403，データ404からなるエントリ405を保持する。登録者ID402は，本システム内で一意に定まるユーザの識別子である。ファイルID403は，単一サービスゲートウェイ103内で一意に定まるコンテンツ格納位置の識別子である。データ404は，コンテンツ本体をあらわす。例えばエントリ406は「Cli.A」によって登録され，「000001」という場所に格納されたXML文書を示している。

図4Bに示すロジック/テンプレート/コンテンツキャッシュ411は，クライアント101からの要求に対して行う操作を格納しておくためのテーブルであり，URL412，テンプレート413，生成ロジック414，生成済みコンテンツ415からなるエントリ416を保持する。URL412は，クライアントからの要求のヘッダに含まれ，要求の内容を示すための文字列である。テンプレート413は，返答を生成する場合の雛形となるものであり，テンプレート中の特定の部位を生成ロジック414に含まれるプログラムにしたがって置き換えることでクライアン101への返答を作成する。生成済みコンテンツ415は，生成後の返答コンテンツの内容が今後も変化しない場合などにサーバからの指示に従って返答コンテンツをキャッシュするためのものである。例えばエントリ417は，クライアントから「/CliA/list/new/5」という文字列を含むURLを受信した場合に，テンプレート「<html>...」で示されるHTML文書の特定の部位に，最新の記事5件のURLを埋め込む，という情報を示している。当該エントリの生成済みコンテンツがNullとなっているのは，最新の記事情報に関しては常にサーバに問い合わせて生成する必要があるため，キャッシュに記録されていないということを示している。

図4Cに示す生成リンク管理テーブル421は，クライアント101への返答生成時に生成されたURLを管理するためのテーブルである。このテーブルによって，ユーザのアクセス制限を行う。本テーブルは，URL422，SGW-ID423，ユーザID424，ファイルID425，参照可能ユーザID426からなるエントリ427を保持する。URL422は，生成したURL文字列である。SGW-ID423は，当該URLへアクセスがあった場合にコンテンツを取得する先のサービスゲートウェイの識別子である。ユーザID424は，当該コンテンツの登録者ID402を示す。ファイルID425は当該コンテンツが格納されているサービスゲートウェイ103内でのファイルIDを示す。参照可能ユーザID426は，当該URLを用いてアクセスすることを許可されているユーザのIDを示す。例えば，エントリ428は，サービスゲートウェイ103に対し「/0abc3a4f8eab83」という文字列を含むURLへのアクセスに対し，全てのユーザに対して，SGW-IDが「SGW-1」であるサービスゲートウェイからユーザIDが「Cli.A」，ファイルIDが「000001」であるコンテンツが対応付けられるということを示している。

上記テーブル群は，サービスゲートウェイ103内のメモリ305に格納される。

図5A、5Bにサーバ106がもつテーブル群を示す。

図5Aに示すコンテンツ格納位置管理テーブル501は，クライアント101の登録したコンテンツの格納位置を管理するためのテーブルであり，データID502，SGW-ID503，ユーザID504，ファイルID505からなるエントリ506を保持する。データID502は，サーバ106内で一意に定まるデータの識別子である。SGW-ID503は，当該コンテンツが格納されているサービスゲートウェイ103の識別子である。ユーザID504は，当該コンテンツを登録したユーザの識別子である。ファイルID505は，当該コンテンツが格納されているサービスゲートウェイ103内でのファイルIDを示す。例えば，エントリ507は，サーバ内で「a00000001」という識別子で管理されているデータは，識別子が「Sgw-1」であるサービスゲートウェイ103で管理されており，登録ユーザは「ClientA」，ファイルIDは「0000001」である，ということを示す。サーバ内では，全てのコンテンツはデータIDによって管理される。

図5Bに示す生成ロジック管理テーブル511は，クライアント101からの要求に対する返答の生成方法を管理するためのテーブルであり，URL512，サーバロジック513，テンプレート514，SGW生成ロジック515，アクセス権516，キャッシュ可能性517を含んだエントリ518からなる。URL512は，クライアントからの要求のヘッダに含まれ，要求の内容を保持するための文字列である。サーバロジック513は，当該URLに要求があった場合のサーバ側でのコンテンツ生成ルールを示す。サーバロジックに記載がない場合は，以下に説明するテンプレート514,SGW生成ロジック515をサービスゲートウェイ103に含まれる値が返答となる。テンプレート514は，当該URLへの要求を受けたときにサービスゲートウェイ103に返答するテンプレートを示す。SGW生成ロジック515は，サービスゲートウェイ103において当該URLに対するコンテンツを生成するために実行するプログラムを示す。アクセス権516は，コンテンツへアクセス可能なユーザのIDを格納する。「All」となっているものは，全てのユーザから自由にアクセス可能なコンテンツであることを示す。キャッシュ可能性517は，サービスゲートウェイ103にて永続的に格納することが可能な要素を示す。例えばエントリ519は，サーバ106が「/CliA/list/new/{n}」というパターンにマッチする要求を受信したとき，サーバはサービスゲートウェイに対してテンプレート「<html...>...」と「最新の記事n件のデータIDの位置をサーバに問い合わせて，URLを生成して埋め込む」というプログラムを返答する。このとき，そのコンテンツに対するアクセスは自由であり，また，返答したテンプレートとSGW生成ロジックはサービスゲートウェイ103内のロジック/テンプレート/コンテンツキャッシュ411内に格納可能となる。

図6にサービスゲートウェイ103がクライアント101からの要求を受信した場合のCPU301での処理フローを示す。

サービスゲートウェイ103がクライアント101からの要求を受信すると，まず要求のヘッダ部分からURLを抽出する(ステップ601)。次に当該URLをキーとして，生成リンク管理テーブル421内を検索する(ステップ602)。生成リンク管理テーブル421内にエントリが存在している場合，要求の送信元のユーザIDが当該エントリの参照可能ユーザID426内に含まれているかを調べる(ステップ603)。含まれていない場合，このアクセスは許可されないため，クライアント101に対してエラーを返す(ステップ604)。含まれている場合は，当該URLをキーとしてロジック/テンプレート/コンテンツキャッシュを検索する(ステップ605)。キャッシュに存在しない場合，生成リンク管理テープル421のエントリに含まれるSWG-ID423を抽出し，IDの指し示すサービスゲートウェイ103から，エントリに含まれるユーザID，ファイルIDのコンテンツを取得する。そして，その返答をロジック/テンプレート/コンテンツキャッシュ411に登録した後，クライアントにコンテンツを返答する(ステップ606)。ロジック/テンプレート/コンテンツキャッシュ411にエントリが存在した場合は，そのエントリの生成済みコンテンツ415に示す内容をクライアントに返答する(ステップ607)。

ステップ602にて当該URLが生成リンク管理テーブル内に存在しなかった場合，次に当該URLをキーとしてロジック/テンプレート/コンテンツキャッシュ411を検索する(ステップ608)。エントリが存在しない場合，サービスゲートウェイはクライアントからの要求をそのままサーバ106に転送する(ステップ609)。エントリが存在した場合，生成済みコンテンツ415に示す内容が「Null」であるかどうか調べる(ステップ610)。「Null」でなかった場合は，生成済みコンテンツ415に示す内容をクライアントに返答する(ステップ611)。「Null」であった場合，テンプレート413，生成ロジック414にしたがってコンテンツを生成し，クライアントに返答する(ステップ612)。

図7にサービスゲートウェイ103がステップ609にてサーバ106に転送した要求に対して返答が来た時のCPU301での処理フローを示す。

サーバ106からの受信内容がテンプレート/生成ロジックか，テンプレート/生成ロジック/解析ロジック/返答テンプレートであるか，他の返答であるかによって処理が3つに分岐する(ステップ701)。テンプレート/生成ロジックが返答された場合，返答からキャッシュ可能性情報を抽出する(ステップ702)。キャッシュ可能性情報として，テンプレート/ロジックがキャッシュ可能であると記載されているかを調べる(ステップ703)。キャッシュ可能である場合テンプレート/生成ロジックを，返答に含まれるURLをキーとしてロジック/テンプレート/コンテンツキャッシュ411に登録する(ステップ704)。テンプレート/ロジックキャッシュが不可能，あるいはキャッシュへの登録が完了した場合，テンプレート/生成ロジックに従い，返答するページを生成する(ステップ705)。ここで改めてキャッシュ可能性情報を調べ，生成後のページがキャッシュ可能かどうかを調べる(ステップ706)。キャッシュ可能な場合，ステップ704と同様に生成後のページをキャッシュに格納する(ステップ707)。キャッシュ不能の場合，あるいはキャッシュへの格納完了後，生成したページをクライアントに返送する(ステップ708)。

ステップ701において，受信内容がテンプレート/生成ロジック/解析ロジック/返答テンプレートであると判定された場合，返答から各種情報を抽出する(ステップ709)。そして，返答に含まれるURLをキーとして，解析ロジックおよび返答テンプレートを，それぞれ生成ロジック，テンプレートとしてロジック/テンプレート/コンテンツキャッシュ411に登録する(ステップ710)。その後はステップ702から708の処理を実行してクライアント101への返答を行う。
ステップ701において，その他の返答であると判定された場合，一般のWebキャッシュと同様の処理を行う。すなわち，返答内のpragmaヘッダ情報からコンテンツのキャッシュ可能性を抽出する(ステップ711)。キャッシュ可能であるならば，要求したURLをキーとしてロジック/テンプレート/コンテンツキャッシュ411の生成済みコンテンツ415の示す内容としてコンテンツを格納する(ステップ713)。そして，受信内容をそのままクライアント101に返答する(ステップ714)。

図8に，サーバ106が要求を受信した場合の、サーバ106の処理部（CPU）の処理フローを示す。

サーバ106は，サービスゲートウェイ103から転送された要求からURLの情報を抽出する(ステップ801)。そして，当該URLをキーとして生成ロジック/コンテンツ格納テーブル511を検索する(ステップ802)。エントリが存在しない場合，サービスゲートウェイに対してエラー返答を行う(ステップ803)。エントリが存在する場合，要求ヘッダに含まれるユーザIDとしてのAuthorization Headerを抽出する(ステップ804)。そして，当該エントリのアクセス権516情報との照合を行う(ステップ805)。アクセス不可の場合，ステップ803に進みエラー返答を行う。アクセス可能な場合，当該エントリのサーバロジック513を参照し，その値が「Null」であるかを調べる(ステップ806)。値が「Null」でない場合，当該エントリのサーバロジック513に格納されたプログラムを実行し(ステップ807)，生成された返答をサービスゲートウェイ103に返答する(ステップ808)。ステップ806にて値が「Null」であると判定された場合，当該エントリ内のテンプレート514，SGW生成ロジック515を返答する(ステップ809)。

以下では，本実施例における代表的なシーケンスと，そのときに交換されるメッセージ例について述べる。

図9は，本実施例においてクライアントA 101-1が自分の登録したページを取得するシーケンス，およびクライアントB 101-2が一覧ページを取得するシーケンスを示している。

処理901は，クライアントA 101-1がサービスゲートウェイ1 103-1を介してサーバ106に対して第一のメッセージとしてページ取得要求を出している。処理901で送信されるメッセージの詳細を図11中のメッセージ1101に示す。本メッセージには，自分の登録ページを示すURLが含まれている。なお，HTTPにしたがって要求を出した場合，Authorization Headerのユーザ/パスワード部はBASE64エンコードされているが，ここでは単純化のため平文で示している。本実施例ではHTTP上の認証トークンを利用しているが，IPアドレス，MACアドレスなど，物理回線情報など他の情報からユーザIDを抽出してもよい。
このメッセージ1101を受け取ったサービスゲートウェイ1 103-1は，図6のフローにしたがって処理を進める。本例の場合，生成リンク管理テーブル421およびロジック/テンプレート/コンテンツキャッシュ411内にエントリが存在しなかったものとして，処理609によってメッセージ1101はサーバ106に向けてそのまま、第二のメッセージとして転送される(902)。

転送されたメッセージを受け取ったサーバ106は，図8のフローにしたがって処理を進める。本例では，ステップ802において生成ロジック/コンテンツ格納テーブル511の2番目のエントリにマッチし，ステップ805でアクセス権があることを確認し，ステップ806でサーバロジックがNullと判定されたとして，ステップ809を実行する。サービスゲートウェイに返答を行う際に，テンプレート514およびSGW生成ロジック515に含まれるデータIDは，コンテンツ格納位置管理テーブル501に従い，SGW-ID 503，ユーザID 504，ファイルID 505の組に変換されて送付される(903)。

処理903において送付されるメッセージの詳細を図11のメッセージ1102に示す。メッセージ1102には，URL情報，キャッシュ可能性情報，テンプレート，生成ロジックが含まれる。

サーバ106からの返答を受け取ったサービスゲートウェイ1 103-1は，図7に示すフローにしたがって処理を行う。本例では，テンプレート/生成ロジックの含まれたメッセージ1102を受信するため，ステップ702の処理にすすみ，メッセージ内に含まれるキャッシュ可能性情報として生成ロジック，テンプレート，生成済みページがキャッシュ可能であるものとしてステップ703から708が実行される。

生成されたコンテンツは処理904でサービスゲートウェイ1 103-1からクライアントA 101-1に送付される。ここで送信される返答メッセージを図12のメッセージ1201に示す。メッセージ1201は，メッセージ1102に含まれるテンプレート中の「<?sgw ... ?>」で示される部分を生成ロジックを実行した結果に置き換えたものになっている。これにより，サーバ側がロジックのみを提供し，サービスゲートウェイ内のメモリ内に格納されたコンテンツを使ってページが生成されることが示された。

次に，異なるサービスゲートウェイ103に属するクライアント101から，一覧ページの取得要求が来た場合のシーケンスについて述べる。

クライアントB 101-2は，サービスゲートウェイ2 103-2を介してサーバ106に、一覧ページの取得要求を行う(905)。ここで送信される第一のメッセージは，メッセージ1101のURLおよびユーザIDおよびパスワード部分が変更されたものであり，詳細は省略する。当該メッセージを受け取ったサービスゲートウェイ2 103-2は，ここでは生成リンク管理テーブル421およびロジック/テンプレート/コンテンツキャッシュ411に該当するエントリが無かったものとしてサーバにメッセージを転送する(906)。サーバ106ではアクセス権のチェック，および生成ロジック/格納テーブル511からの適切なエントリの選択を行ってサービスゲートウェイ2 103-2に対して返答を行う(907)。

返答を受け取ったサービスゲートウェイ2 103-2は，テンプレート/生成ロジックを適切にキャッシュに格納した後，コンテンツを生成する。ここでの生成ロジックには，隣接するサービスゲートウェイ1 103-1からのデータ取得を行うロジックが記載されているものとする。サービスゲートウェイ2 103-2は，このロジックに従い，サービスゲートウェイ1 103-1に対してクライアントAのもつコンテンツの取得要求を行う(908)。ここで送信されるメッセージを，図12のメッセージ1202に示す。サービスゲートウェイ103間の通信は，ここではHTTPを用いて行っているものとする。本メッセージは，URLにユーザIDおよびファイルIDを埋め込むことによって，必要なコンテンツの取得要求を表現している。メッセージ1201を受け取ったサービスゲートウェイ1 103-1は，パーソナルストレージ401から該当するエントリを取り出し，サービスゲートウェイ2 103-2に返答する(909)。このとき送信されるメッセージを図12のメッセージ1203に示す。

サービスゲートウェイ2 103-2は，メッセージ1203に含まれるコンテンツを使用してページを生成し，クライアントB 101-2に生成されたページを返答する(910)。これによって，異なるサービスゲートウェイ103に属するクライアント間で，コンテンツが適切に転送・キャッシュされることが示された。

最後に，クライアントA 101-1がコンテンツの投稿を行う際のシーケンスについて述べる。

クライアントA 101-1は，サービスゲートウェイ1 103-1を介して，サーバ106に対して投稿用ページの要求を行う(1001)。処理1001で送信される第一のメッセージを図13のメッセージ1301に示す。サービスゲートウェイ1 103-1は，メッセージ1301を受信すると，サーバ106に対して転送する。ここでも同様にメッセージ1301と同じメッセージが第二のメッセージとして送信される(1002)。当該メッセージを受け取ったサーバ106は，図8に示したフローにしたがって要求を処理する。ここでは，要求に含まれるURLに対して，投稿ページ生成用のテンプレート/生成ロジック，投稿要求解析用のテンプレート/生成ロジックを含むエントリが存在し，それに基づいてサービスゲートウェイ1 103-1に対して返答を行ったものとする(1003)。このときに送信される返答メッセージを図13のメッセージ1302に示す。メッセージ1302は，文字列「--AAAAA」を区切りとして6つのパートに分かれており，それぞれ要求元URL情報，テンプレート，生成ロジック，追加のURL，テンプレート，生成ロジックとなっている。メッセージ1302を受け取ったサービスゲートウェイ1 103-1は，後半の追加のURL，テンプレート，生成ロジックをステップ709,710にもとづいてロジック/テンプレート/コンテンツキャッシュ411に追加した後，返答を前半の要求元URL情報，テンプレート，生成ロジックに従って生成する。そして，クライアントAに対して生成したページを返答する(1004)。生成されたメッセージを図14のメッセージ1401に示す。

クライアントA 101-1はここで生成されたページに含まれるフォームを用いて投稿処理を行う。具体的には，フォームに含まれるURLに対して，コンテンツを含んだPOST要求を送信する(1005)。処理1005で送信されるメッセージを図15のメッセージ1501に示す。メッセージ1501には，投稿コンテンツとして，画像のタイトル，画像の説明，画像ファイルが含まれる。

メッセージ1501を受信したサービスゲートウェイ1 103-1は，図6のフローにしたがって処理を進める。ここでは，処理1004によって要求解析のためのテンプレートおよびロジックが登録されたため，生成リンク管理テーブル421内にエントリが存在せず，ロジック/テンプレート/テンプレート/コンテンツキャッシュ411内にエントリが存在し，かつ生成済みコンテンツ415がNullであったものとして扱われ，要求解析のためのロジックおよびテンプレートが使用される。メッセージ1302に含まれる要求解析ロジックには，パーソナルストレージ401に対して画像タイトル，画像説明，画像ファイルと，画像ファイルから生成したサムネイルを登録し，登録先のサービスゲートウェイID，ユーザID，ファイルIDおよび画像タイトルをサーバ106に送り，テンプレートを使って投稿完了のページを生成する処理が記述されている。

これにより，まずサーバ106に対してメタ情報が送信される(1006)。処理1006にて送信されるメッセージを図16のメッセージ1601に示す。メッセージ1601を受信したサーバ106は，図8に示されるフローに従い，生成ロジック/コンテンツ格納テーブル511の3番目のエントリに含まれるサーバロジックを実行，生成内容を返答する(1007)。サービスゲートウェイ1 103-1は，返答ページを生成し，クライアントA 101-1へ送信する(1008)。

以上説明した実施例１により，コンテンツがサービスゲートウェイ103上のパーソナルストレージ401に格納されつつ，サーバ106が当該コンテンツの位置情報を管理できることが示された。

第二の実施例として、コンテンツに対しての広告挿入を実現する実施例を示す。実施例1との差異は，図17に示すとおり広告原稿を管理する広告サーバ1701ユーザ属性を管理するユーザ属性サーバ1702が構成に追加され，サーバ106から返答されるテンプレートに広告を埋め込む領域が定義されていること，生成ロジックにユーザIDから属性を取得し，その属性をもとに広告を取得するプログラムが追加されている点である。

図17では，異なるアクセス網に広告サーバ1701とユーザ属性サーバ1702を記載しているが，ネットワーク的に到達可能であればどこの位置にあってもよい。また，サービスゲートウェイ103やサーバ106内に当該機能を実装しても良い。

図18に，本実施例による広告挿入を行う際の代表的なシーケンス例を示す。クライアントA 101-1は，ページを取得するためにサービスゲートウェイ1 103-1を介してサーバ106に要求を行う(1801,1802)。メッセージを受け取ったサーバは，実施例1と同様の処理を行い，広告を埋め込むための領域を定義したテンプレートおよび広告取得方法を記述した生成ロジックを含んだメッセージを返答する(1804)。1804で送付されるメッセージの例を1901に示す。

サービスゲートウェイ1 103-1は，返答を受け取ると生成ロジックにしたがって広告を含んだページの生成を始める。テンプレートに含まれる指示に従い，まず，ユーザ属性サーバ1702に対し，ユーザ属性取得要求を送信する(1805)。この要求には，ユーザIDが含まれる。この要求メッセージの例を2001に示す。この例では，”ClientA”というユーザIDが要求メッセージの1行目に記載されている。ユーザ属性サーバ1702は，ユーザ属性テーブル2101を使ってユーザIDから当該ユーザの属性(年齢，性別など)を検索し，返答する(1806)。2003に返答メッセージの例を示す。ここでは，返答のボディ部にユーザの属性を記述している。サービスゲートウェイ1 103-1は，受け取った属性と生成するページのURLを広告サーバ1701に対して送信する(1807)。1807で送信されるメッセージ例を2003に示す。

広告サーバ1701は，ページのURL，ユーザ属性から，そのページにふさわしい広告を選択し，広告で表示するイメージのURLおよび広告で誘導する先のサイトURLを返答する(1808)。１808で送信されるメッセージ例を2004に示す。サービスゲートウェイ103-1は，受け取った情報を生成ロジックにしたがってテンプレートに埋め込み，ページを生成する。そして，生成したページをクライアントA 101-1に対して返答する。返答メッセージの例を2005に示す。この例では1901に含まれるテンプレートの“<?sgw …?>”の部分広告のURLに置き換えられている。

以上の手順により，クライアントの属性と，ページの属性をもとに，広告が挿入されることが示された。本実施例では，広告サーバ1701側にユーザIDが直接転送されない方式をとっているため，個人情報の流出が抑えられる。サーバ106にてサービスを提供する業者は，テンプレートを用いて広告の挿入箇所を細かく制御できるという利点がある。

実施例3は、Webカメラを用いた映像モニタリングシステムに関する実施例を示す。

図22に本実施例が対象とするネットワークの構成図を示す。Webカメラ2201が複数つながれたアクセス網とコア網の間にサービスゲートウェイ103を配置し，他のアクセス網に収容されているクライアント101からWebカメラ2201への要求を仲介する。本実施例では，実施例１で述べたサーバとしてWebカメラ2201を置いた形態をとっており，クライアント101がWebカメラ2201群に対して画像ファイルを継続的に取得することで映像によるモニタリングを行うものである。

サービスゲートウェイ103がない従来型のシステムでこれを行った場合，画像の重要性，他のカメラ群との優先順位などを考慮することなくクライアント101が画像を取得することとなり，コア網に流れ込むトラフィックが増大してしまう問題がある。

本実施例では，カメラ群2201とネットワーク的に近い位置にサービスゲートウェイ103を置き，そこで優先度を判断してクライアント101への返答を制御する。これにより，複数のカメラ群2201との間で返答優先度の調停を行うことが可能となるため，より少ないトラフィックで高品質の映像モニタリングを行うことが可能となる。

以下，図23に示す代表シーケンスに従い，本実施例の処理内容を説明する。
クライアント101は，Webカメラ2201-1にアクセスするために，サービスゲートウェイ103を経由してWebカメラ2201-1に対しアクセス要求を行う(2301,2302)。2301,2302で送信されるメッセージの例を2401に示す。

この要求に対し，Webカメラ2201-1は、内蔵する処理部でアクセス権をチェックし，アクセスが許可された場合，当該URLに対するテンプレート/ロジックを選択，サービスゲートウェイ103に対して返答する(2303)。2303で送信される返答メッセージの例を2402に示す。ここには，画像取得要求用情報となるWebカメラ2201から画像を取得するためのURL，およびそのURLにアクセスした場合のテンプレート，ロジックが含まれる。

サービスゲートウェイ103は，メッセージ2402に含まれるテンプレート/ロジックをキャッシュし，クライアント101に対して画像取得要求用情報である画像取得要求用URLを返答する(2304)。

クライアント101は返答メッセージに含まれるURLを用い，Webカメラ2201-1に対する画像取得要求を送信する(2305)。2305で送信されるメッセージの例を2501に示す。

画像取得要求を中継するサービスゲートウェイ103は，要求の解析を開始する。メッセージ2402に含まれている解析ロジックのフローチャートを図26に示す。まずステップ2601にてWebカメラ2201-1から画像取得を行う。そしてこの画像を返答すべきかを判定するために，以下の判定を行う。ステップ2602にて，画像取得の繰り返し回数の判定を行い(2602)，規定の回数(ここでは10回)の繰り返しを行っていた場合は画像の返答を行う(2606)。これは，優先度が低い状態でもある程度の頻度で画像を返すべきであるという判断である。そして，ステップ2603にて，返答メッセージ2401に含まれている画像優先度情報を抽出する(2603)。

本実施例では，返答ヘッダ「X-Precedence」内に画像優先度情報を格納している。そして，ステップ2604にて，サービスゲートウェイ103が収容している他のカメラ群2201の最近の画像優先度との比較を行い，もし優先度が高いグループに属する(ここでは上位3カメラ)と判定された場合(2605)，画像の返答を行う(2606)。そうでない場合は，ステップ2601からリトライする。

クライアント101は，画像の返答が届き次第，次の画像取得要求を送る。これを繰り返すことにより，クライアント101にはWebカメラ2201の画像を継続的に受信，動画として利用することが可能となる。

以上の手順により，サービスゲートウェイ103とWebカメラ2201の間は一定の頻度で画像取得を行い，コア網を経由するサービスゲートウェイ103とクライアント101の間では，多数のカメラからの間で情報転送の優先度を調停し，優先度の低いデータは低い頻度で，優先度の高いデータは高い頻度でクライアント101に返答されることが示された。

以上種々の実施例により説明してきた、本発明のシステムは，ネットワーク上で提供されるサービス全般に利用可能である。

本発明の分散サービス提供システムの概略構成を示す図である。 実施例1の分散サービス提供システムの構成図である。 実施例1のサービスゲートウェイの構成図である。 実施例1のサービスゲートウェイがもつパーソナルストレージテーブルを示す図である。 実施例1のサービスゲートウェイがもつロジック/テンプレート/コンテンツキャッシュテーブルを示す図である。 実施例1のサービスゲートウェイがもつ生成リンク管理テーブルを示す図である。 実施例1のサーバがもつコンテンツ格納位置管理テーブルを示す図である。 実施例1のサーバがもつ生成ロジック/コンテンツ格納テーブルを示す図である。 実施例1のサービスゲートウェイがクライアントから要求を受信した際の動作を示すフローチャートである。 実施例1のサービスゲートウェイがサーバから返答を受信した際の動作を示すフローチャートである。 実施例1のサーバが要求を受信した際の動作を示すフローチャートである。 実施例1のクライアントがページを要求した際のシーケンスを示す図である。 実施例1のクライアントがコンテンツの投稿を行った際のシーケンスを示す図である。 実施例1のシーケンス内で交換されるメッセージ詳細(その1)を示す図である。 実施例1のシーケンス内で交換されるメッセージ詳細(その2)を示す図である。 実施例1のシーケンス内で交換されるメッセージ詳細(その3)を示す図である。 実施例1のシーケンス内で交換されるメッセージ詳細(その4)を示す図である。 実施例1のシーケンス内で交換されるメッセージ詳細(その5)を示す図である。 実施例1のシーケンス内で交換されるメッセージ詳細(その6)を示す図である。 実施例1の分散サービス提供システムの構成図である。 実施例2にてクライアントがページを要求した際のシーケンスである。 実施例2のシーケンス内で交換されるメッセージ詳細(その1)を示す図である。 実施例2のシーケンス内で交換されるメッセージ詳細(その2)を示す図である。 実施例2のユーザ属性サーバが持つテーブルを示す図である。 実施例3の映像モニタリングシステムの構成図である。 実施例3にてクライアントが画像を要求した際のシーケンスを示す図である。 実施例3のシーケンス内で交換されるメッセージ詳細(その1)を示す図である。 実施例3のシーケンス内で交換されるメッセージ詳細(その2)を示す図である。 実施例3の解析ロジックのフローチャートである。

符号の説明

101…クライアント
102…アクセス網
103…サービスゲートウェイ
105…コア網
106…サーバ
107…テンプレート/生成ロジック
108…コンテンツ素材
201…画像投稿データ
202…画像表示用テンプレート
2201…Webカメラ。

Claims (20)

1. クライアント，サービスゲートウェイ，サーバがネットワークを介して接続されるサービス提供システムであって，
   前記クライアントは，前記サーバへの第一のメッセージを、前記サービスゲートウェイを経由させて送信し，
   前記サービスゲートウェイは，前記クライアントからの前記第一のメッセージの処理方法を、前記第一のメッセージの内容を含んだ第二のメッセージを用いて前記サーバに問い合わせ，
   前記サーバは，前記サービスゲートウェイからの問い合わせに対して，前記処理方法を返答し，
   前記サービスゲートウェイは、受け取った前記処理方法に基づき、前記第一のメッセージの処理を行う、
   ことを特徴とするサービス提供システム。
2. 前記サービスゲートウェイは，
   請求項１記載のサービス提供システムであって、
   前記サービスゲートウェイは記憶部を有し、前記サーバから受け取った前記処理方法を、前記サービスゲートウェイの前記記憶部に格納する、
   ことを特徴とするサービス提供システム。
3. 請求項１記載のサービス提供システムであって、
   前記サービスゲートウェイは記憶部を有し，受け取った前記処理方法に従って生成した前記クライアントへの返答メッセージを、前記サービスゲートウェイの前記記憶部に格納する、
   ことを特徴とするサービス提供システム。
4. 請求項１記載のサービス提供システムであって、
   前記サービスゲートウェイは記憶部を有し，前記処理方法に従って解析した前記クライアントからの前記第一のメッセージの一部あるいは全部を，前記サービスゲートウェイの前記記憶部に格納する、
   ことを特徴とするサービス提供システム。
5. 請求項４記載のサービス提供システムであって、
   前記サービスゲートウェイは，前記記憶部に格納したデータに対し、前記サービスゲートウェイ内で一意な識別子を付与し，前記識別子を前記サーバに送信する、
   ことを特徴とするサービス提供システム。
6. 請求項１記載のサービス提供システムであって、
   前記サービスゲートウェイは，前記クライアントを前記第一のメッセージに含まれる認証トークンによって識別し、前記認証トークンを用いて要求の処理の可否を判定する、
   ことを特徴とするサービス提供システム。
7. 請求項１記載のサービス提供システムであって、
   前記サーバは，前記処理方法を、前記クライアントへの返答メッセージのテンプレートと前記テンプレートの空欄を埋めるための生成ロジックの組で表現する、
   ことを特徴とするサービス提供システム。
8. 請求項１記載のサービス提供システムであって、
   前記サーバは，前記処理方法として、前記クライアントへの返答メッセージの生成に必要な情報を、外部サーバから取得するための方法を記述した生成ロジックを含ませる、
   ことを特徴とするサービス提供システム。
9. 請求項１記載のサービス提供システムであって、
   前記サーバは、Webカメラであり、前記処理方法は、前記Webカメラから画像を取得するための画像取得要求用情報を含む、
   ことを特徴とするサービス提供システム。
10. ネットワークを介してクライアント，及びサーバに接続されるサービスゲートウェイであって，
    処理部と、記憶部と、ネットワークインタフェースを有し、
    前記ネットワークインタフェースは、前記クライアントから前記サーバへ送信される第一のメッセージを受信し，
    前記処理部は，
    前記第一のメッセージの処理方法を、前記第一のメッセージの内容を含んだ第二のメッセージを用いて、前記サーバに問い合わせ、
    前記サーバから返答される前記処理方法を受け取り，
    受け取った前記処理方法に基づき前記第一のメッセージの処理を行い、
    生成された返答メッセージを前記クライアントに送る、
    ことを特徴とするサービスゲートウェイ。
11. 請求項１０記載のサービスゲートウェイであって、
    前記処理部は、前記サーバから受け取った前記処理方法を前記記憶部に格納する、
    ことを特徴とするサービスゲートウェイ。
12. 請求項１０記載の前記サービスゲートウェイであって、
    前記処理部は、前記返答メッセージを前記記憶部に格納する、
    ことを特徴とするサービスゲートウェイ。
13. 請求項１０記載のサービスゲートウェイであって、
    前記処理部は，前記処理方法に従って解析した前記クライアントからの前記第一のメッセージの一部あるいは全部を，前記記憶部に格納する、
    ことを特徴とするサービスゲートウェイ。
14. 請求項１０記載のサービスゲートウェイであって、
    前記処理部は，前記記憶部に格納されたデータに対して、一意な識別子を付与し，前記識別子を前記サーバに送信する、
    ことを特徴とするサービスゲートウェイ。
15. 請求項１０記載のサービスゲートウェイであって、
    前記処理部は，前記クライアントを前記第一のメッセージに含まれる認証トークンによって識別する、
    ことを特徴とするサービスゲートウェイ。
16. 請求項１５記載のサービスゲートウェイであって、
    前記処理部は、前記クライアントの前記認証トークンを用いて、処理の可否を判定する、
    ことを特徴とするサービスゲートウェイ。
17. ネットワークを介してサービスゲートウェイ経由でクライアントに接続されるサーバであって，
    処理部と、記憶部と、ネットワークインタフェースを有し、
    前記ネットワークインタフェースは、前記クライアントから前記サーバへ送信される第一のメッセージを受信した前記サービスゲートウェイから、前記第一のメッセージの処理方法を問い合わせるための、前記第一のメッセージの内容を含んだ第二のメッセージを受け取り、
    前記処理部は，
    前記第二のメッセージに基づき、前記第一のメッセージの前記処理方法を生成する、
    ことを特徴とするサーバ。
18. 請求項１７記載のサーバであって、
    前記処理部は，生成する前記処理方法を，前記クライアントへの返答メッセージのテンプレートと、前記テンプレートの空欄を埋めるための生成ロジックの組とする
    ことを特徴とするサーバ。
19. 請求項１７記載のサーバであって、
    前記処理部は、生成する前記処理方法に、前記クライアントへの返答メッセージの生成に必要な情報を外部サーバから取得するための方法を記述した生成ロジックを含ませる、
    ことを特徴とするサーバ。
20. 請求項１７記載のサーバであって、
    前記処理部は、前記第二のメッセージに含まれる認証トークンに基づき、前記クライアントのアクセス可否の照合を行う、
    ことを特徴とするサーバ。

Images