JP2008152629A - 移動通信ネットワークシステム及びサーバ装置 - Google Patents

Abstract

【課題】移動体端末装置でコンテンツを取得するための時間を十分に短縮すること。
【解決手段】ブラウザ機能を有する携帯電話機１０と、移動通信網１３を介して携帯電話機１０における移動通信を管理する移動通信センター１１とを具備する移動通信ネットワークシステムにおいて、携帯電話機１０からＷｅｂアクセスするためのリクエストを受信すると、移動通信センター１１は、当該リクエストが所定条件を満たすか判定し、当該所定条件を満たす場合に携帯電話機１０からのＨＴＴＰリクエストを連続して受信可能なパイプライン処理を実行することを特徴とする。
【選択図】図１

Description

本発明は、移動通信ネットワークシステム及びサーバ装置に関し、特に、Ｗｅｂブラウザ機能（以下、単に「ブラウザ機能」という）を備える移動体端末装置を有する移動通信ネットワークシステム及びその移動体端末装置の移動通信を管理するサーバ装置に関する。

従来、ブラウザ機能を搭載し、インターネット上のＷｅｂサイトを閲覧することが可能な携帯電話機が普及している。現在、このような携帯電話機においては、主に携帯電話機向けに作成されたＷｅｂサイトを閲覧可能なブラウザ機能を備えるものが普及しているが、近年、携帯電話機向けのＷｅｂサイトではなく、パーソナルコンピュータ向けに作成されたＷｅｂサイトを閲覧可能なブラウザ機能（所謂、フルブラウザ機能）を備えるものが普及し始めている。

一般に、携帯電話機のブラウザ機能においては、ゲートウェイ機能を有する移動通信センターを介して、ＨＴＴＰプロトコルに従ってインターネット上のコンテンツサーバと通信を行い、Ｗｅｂサイトを表示するためのコンテンツ（以下、「単に、コンテンツ」という）を取得する。ＨＴＴＰプロトコルにおいては、通常、クライアントである携帯電話機からコンテンツサーバに送信されるリクエストと、このリクエストに応じてコンテンツサーバから携帯電話機に応答されるレスポンスとを繰り返すことで、コンテンツを取得可能となっている。携帯電話機から送信されるリクエストは、前回送信したリクエストに対するレスポンスを受信し終わった後に発行されるものであるため、通信回線の混雑状況の影響を受け易い。このため、通信回線が混雑している状況下でリクエストとレスポンスとを繰り返す場合には、コンテンツを取得するまでに長時間を要する場合がある。

一方、インターネット標準規格であるＨＴＴＰ／１．１（ＲＦＣ２６１６）においては、クライアントから送信されるリクエストのパイプライン化が定められている（リクエストパイプラン）。このリクエストパイプラインは、複数のリクエストを、個々のレスポンスの受信を待つことなく連続して送信する手法である。このリクエストパイプラインの利用により、これまで前のリクエストに対するレスポンスが返却されるのを待って次のリクエストを送信していたが、当該レスポンスを待たずに連続して送信することが可能になるため、リクエストの送信に要する時間を低減でき、コンテンツを取得するための時間を短縮することが可能となっている。

ここで、リクエストパイプラインを実行するためには、コンテンツサーバがＨＴＴＰ／１．１に対応している必要がある。コンテンツサーバがＨＴＴＰ／１．１に対応していない場合には、上述のようにリクエストとレスポンスとが繰り返されることとなる。そして、従来、このようにコンテンツサーバがＨＴＴＰ／１．１に対応していない場合においても、ユーザ装置とサーバ装置との間の通信をＨＴＴＰプロコトルに従って行うことができる改良データ通信方法が提案されている（例えば、特許文献１参照）。この改良データ通信方法においては、コンテンツサーバがＨＴＴＰ／１．１に対応していない場合にプロキシサーバにてＨＴＴＰプロトコルのバージョンを変換することで、ユーザ装置とコンテンツサーバとの間のＨＴＴＰプロコトル通信を確保している。
特表２００４−５３０２３１号公報

しかしながら、上述した従来の改良データ通信方法においては、コンテンツサーバがＨＴＴＰ／１．１に対応していない場合には、リクエスト又はレスポンスが到来する度にプロキシサーバでＨＴＴＰプロトコルのバージョンを変換しなければならず、この変換処理に要する時間によってコンテンツを取得するための時間を十分に短縮することができないという問題がある。

本発明は、かかる問題点に鑑みて為されたものであり、移動体端末装置でコンテンツを取得するための時間を十分に短縮することができる移動通信ネットワークシステム及びサーバ装置を提供することを目的とする。

本発明の移動通信ネットワークシステムは、ブラウザ機能を有する移動体端末装置と、移動通信網を介して前記移動体端末装置における移動通信を管理するサーバ装置とを具備し、前記移動体端末装置からＷｅｂアクセスするためのリクエストを受信すると、前記サーバ装置は、当該リクエストが所定条件を満たすか判定し、前記所定条件を満たす場合に前記移動体端末装置からのＨＴＴＰリクエストを連続して受信可能なパイプライン処理を実行することを特徴とする。

この構成によれば、移動体端末装置から受信したリクエストが所定条件を満たす場合、サーバ装置により移動体端末装置からのＨＴＴＰリクエストを連続して受信可能なパイプライン処理が実行されることから、移動通信網においてリクエストとレスポンスとが繰り返される結果、移動通信網における通信状況の影響を受けて通信時間が長くなる事態が防止されるので、移動体端末装置でコンテンツを取得するための時間を十分に短縮することが可能となる。

上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記リクエストのＵＡ、ＨＴＴＰバージョン及びメソッドの内容に応じて前記パイプライン処理の実行を判定することが考えられる。例えば、前記リクエストのＵＡが前記パイプライン処理の対応端末であって所定のブラウザからのアクセスであり、ＨＴＴＰバージョンがＨＴＴＰ／１．１であり、所定のメソッドの場合にパイプライン処理を実行することが好ましい。所定のブラウザとしては、例えば、フルブラウザ又は移動体端末装置用ブラウザからのアクセスである場合が考えられる。所定のメソッドとしては、例えば、ＧＥＴ又はＨＥＡＤである場合や、ＧＥＴ、ＨＥＡＤ又はＰＯＳＴである場合が考えられる。この場合には、移動体端末装置からのリクエストのＵＡ、ＨＴＴＰバージョン及びメソッドの内容に応じてパイプライン処理の実行が判定されるので、必要な場合にのみ移動通信網におけるパイプライン処理を実行することが可能となる。

また、上記移動通信ネットワークシステムにおいて、前記サーバ装置を介して前記移動体端末装置にコンテンツを配信するコンテンツ配信装置を更に具備し、前記サーバ装置は、前記パイプライン処理で連続して受信したＨＴＴＰリクエストを順次前記コンテンツ配信装置に送信する一方、当該ＨＴＴＰリクエストに対応するＨＴＴＰレスポンスを前記コンテンツ配信装置から受信するようにしても良い。この場合には、コンテンツ配信装置からサーバ装置を介して移動体端末装置にコンテンツを配信する場合においても、移動通信網においてリクエストとレスポンスとが繰り返される結果、移動通信網における通信状況の影響を受けて通信時間が長くなる事態が防止されるので、移動体端末装置でコンテンツを取得するための時間を十分に短縮することが可能となる。

特に、コンテンツ配信装置がＨＴＴＰ／１．１に対応しておらず、リクエストパイプラインを実行することができないような場合においても、移動通信網におけるパイプライン処理により、当該移動通信網においてリクエストとレスポンスとが繰り返される結果、移動通信網における通信状況の影響を受けて通信時間が長くなる事態が防止されるので、移動体端末装置でコンテンツを取得するための時間を十分に短縮することが可能となる。また、サーバ装置においては、従来の改良データ通信方法のように、ＨＴＴＰプロトコルのバージョンを変換する必要がないので、プロトコル変換処理に要する時間に応じてコンテンツを取得するまでの時間が長くなるという事態も発生しない。

また、上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正を検出すると、必要に応じて前記移動体端末装置からのＨＴＴＰリクエスト又は前記コンテンツ配信装置からのＨＴＴＰレスポンスを破棄して前記パイプライン処理を継続することが好ましい。この場合には、ＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正が検出された場合においても、必要に応じて移動体端末装置からのＨＴＴＰリクエスト又はコンテンツ配信装置からのＨＴＴＰレスポンスを破棄してパイプライン処理が継続されるので、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正に応じて移動体端末装置とコンテンツ配信装置との間の通信が切断される事態を防止しつつ、移動体端末装置でコンテンツを取得するための時間を短縮することが可能となる。

例えば、上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより大きい場合、必要に応じて前記移動体端末装置からのＨＴＴＰリクエストを破棄する。この場合には、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより大きい場合に必要に応じて移動体端末装置からのＨＴＴＰリクエストが破棄されるので、ＨＴＴＰリクエストが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。

また、上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより小さい場合、必要に応じて前記コンテンツ配信装置からのＨＴＴＰレスポンスを破棄する。この場合には、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより小さい場合に必要に応じてコンテンツ配信装置からのＨＴＴＰレスポンスが破棄されるので、ＨＴＴＰレスポンスが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。

さらに、上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにＣｏｎｔｅｎｔ−ｌｅｎｇｔｈヘッダが存在しない場合、必要に応じて前記移動体端末装置からのＨＴＴＰリクエストを破棄する。この場合には、ＨＴＴＰレスポンスにＣｏｎｔｅｎｔ−ｌｅｎｇｔｈヘッダが存在しない場合に必要に応じて移動体端末装置からのＨＴＴＰリクエストが破棄されるので、ＨＴＴＰリクエストが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。

また、上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスのコネクションヘッダにｃｌｏｓｅが付与されている場合、当該コネクションヘッダの内容をＫｅｅｐ−Ａｌｉｖｅに書き換えて前記パイプライン処理を継続することが好ましい。この場合には、ＨＴＴＰレスポンスにおけるコネクションヘッダにｃｌｏｓｅが付与された場合においても、当該コネクションヘッダの内容をＫｅｅｐ−Ａｌｉｖｅに書き換えてパイプライン処理を継続が継続されるので、コネクションヘッダに付与されたｃｌｏｓｅに従って移動体端末装置とコンテンツ配信装置との間の通信が切断される事態を防止しつつ、移動体端末装置でコンテンツを取得するための時間を短縮することが可能となる。

本発明のサーバ装置は、移動通信網を介して移動体端末装置における移動通信を管理するサーバ装置であって、前記移動体端末装置からのリクエストを受信するリクエスト受信部と、前記リクエスト受信部で受信したリクエストが所定条件を満たすか判定し、前記所定条件を満たす場合に前記移動体端末装置からのＨＴＴＰリクエストを連続して受信可能なパイプライン処理を実行させるパイプライン判定部と、前記パイプライン処理で前記移動体端末装置から連続して受信したＨＴＴＰリクエストを保持するリクエスト保持部と、前記移動体端末装置にレスポンスを送信するレスポンス送信部とを具備することを特徴とする。

この構成によれば、パイプライン判定部が、移動体端末装置から受信したリクエストが所定条件を満たすか判定し、所定条件を満たす場合に移動体端末装置からのＨＴＴＰリクエストを連続して受信可能なパイプライン処理が実行させることから、移動体端末装置からのリクエストが所定条件を満たした場合には、移動通信網においてリクエストとレスポンスとが繰り返される結果、移動通信網における通信状況の影響を受けて通信時間が長くなる事態が防止されるので、移動体端末装置でコンテンツを取得するための時間を十分に短縮することが可能となる。

上記サーバ装置において、前記パイプライン判定部は、前記リクエストのＵＡ、ＨＴＴＰバージョン及びメソッドの内容に応じて前記パイプライン処理を実行させることが考えられる。例えば、前記リクエストのＵＡが前記パイプライン処理の対応端末であって所定のブラウザからのアクセスであり、ＨＴＴＰバージョンがＨＴＴＰ／１．１であり、所定のメソッドである場合にパイプライン処理を実行させることが好ましい。所定のブラウザとしては、例えば、フルブラウザ又は移動体端末装置用ブラウザからのアクセスである場合が考えられる。所定のメソッドとしては、例えば、ＧＥＴ又はＨＥＡＤである場合や、ＧＥＴ、ＨＥＡＤ又はＰＯＳＴである場合が考えられる。この場合には、移動体端末装置からのリクエストのＵＡ、ＨＴＴＰバージョン及びメソッドの内容に応じてパイプライン処理が実行されるので、必要な場合にのみ移動通信網においてパイプライン処理を実行することが可能となる。

また、上記サーバ装置において、前記移動体端末装置からのリクエストをコンテンツ配信装置に送信するリクエスト送信部と、前記コンテンツ配信装置からのレスポンスを受信するレスポンス受信部と、前記レスポンス受信部で受信したＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正を判定するＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部とを具備し、前記Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部は、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正を検出すると、必要に応じて前記移動体端末装置からのＨＴＴＰリクエスト又は前記コンテンツ配信装置からのＨＴＴＰレスポンスを破棄して前記パイプライン処理を継続することが好ましい。この場合には、ＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正が検出された場合においても、必要に応じて移動体端末装置からのＨＴＴＰリクエスト又はコンテンツ配信装置からのＨＴＴＰレスポンスを破棄してパイプライン処理が継続されるので、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正に応じて移動体端末装置とコンテンツ配信装置との間の通信が切断される事態を防止しつつ、移動体端末装置でコンテンツを取得するための時間を短縮することが可能となる。

例えば、上記サーバ装置において、前記Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより大きい場合、必要に応じて前記移動体端末装置からのＨＴＴＰリクエストを破棄する。この場合には、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより大きい場合に必要に応じて移動体端末装置からのＨＴＴＰリクエストが破棄されるので、ＨＴＴＰリクエストが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。

また、上記サーバ装置において、前記Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより小さい場合、必要に応じて前記コンテンツ配信装置からのＨＴＴＰレスポンスを破棄する。この場合には、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより小さい場合に必要に応じてコンテンツ配信装置からのＨＴＴＰレスポンスが破棄されるので、ＨＴＴＰレスポンスが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。

さらに、上記サーバ装置において、前記Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにＣｏｎｔｅｎｔ−ｌｅｎｇｔｈヘッダが存在しない場合、必要に応じて前記移動体端末装置からのＨＴＴＰリクエストを破棄する。この場合には、ＨＴＴＰレスポンスにＣｏｎｔｅｎｔ−ｌｅｎｇｔｈヘッダが存在しない場合に必要に応じて移動体端末装置からのＨＴＴＰリクエストが破棄されるので、ＨＴＴＰリクエストが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。

また、上記サーバ装置において、前記レスポンス受信部で受信したＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈのコネクションヘッダを判定するコネクションヘッダ判定部を具備し、前記コネクションヘッダ判定部は、ＨＴＴＰレスポンスのコネクションヘッダにｃｌｏｓｅが付与されている場合、当該コネクションヘッダの内容をＫｅｅｐ−Ａｌｉｖｅに書き換えて前記パイプライン処理を継続することが好ましい。この場合には、ＨＴＴＰレスポンスにおけるコネクションヘッダにｃｌｏｓｅが付与された場合においても、当該コネクションヘッダの内容をＫｅｅｐ−Ａｌｉｖｅに書き換えてパイプライン処理が継続されるので、コネクションヘッダに付与されたｃｌｏｓｅに従って移動体端末装置とコンテンツ配信装置との間の通信が切断される事態を防止しつつ、移動体端末装置でコンテンツを取得するための時間を短縮することが可能となる。

本発明に係る移動通信ネットワークシステム及びサーバ装置によれば、移動体端末装置から受信したリクエストが所定条件を満たす場合、移動体端末装置からのＨＴＴＰリクエストを連続して受信可能なパイプライン処理が実行されることから、移動通信網においてリクエストとレスポンスとが繰り返される結果、移動通信網における通信状況の影響を受けて通信時間が長くなる事態が防止されるので、移動体端末装置でコンテンツを取得するための時間を十分に短縮することが可能となる。

以下、本発明の実施の形態について添付図面を参照して詳細に説明する。
図１は、本発明の一実施の形態に係る移動通信ネットワークシステムの構成を示す図である。図１に示すように、本実施の形態に係る移動通信ネットワークシステムは、移動通信端末装置としての携帯電話機１０と、この携帯電話機１０における移動通信を管理するサーバ装置としての移動通信センター１１と、携帯電話機１０を含むクライアントにコンテンツを配信するコンテンツ配信装置としてのコンテンツサーバ１２とを備えている。

携帯電話機１０は、例えば、ＩＭＴ（International Mobile Telecommunication）網等の通信ネットワークで構成される移動通信網１３、並びに、インターネット１４のような通信ネットワークを介してコンテンツサーバ１２にアクセス可能に構成されている。そして、携帯電話機１０は、このような通信ネットワークを介して、後述するように、コンテンツサーバ１２から配信されるコンテンツを閲覧できるようになっている。特に、携帯電話機１０は、ＨＴＴＰ／１．１に対応し、複数のＨＴＴＰリクエスト（以下、単に「リクエスト」という）を、個々のレスポンスの受信を待つことなく連続して送信可能に構成されている（リクエストパイプライン）。以下においては、ＨＴＴＰ／１．１に対応する携帯電話機について、適宜「パイプライン対応端末」と呼ぶものとする。なお、図１においては、移動通信網１３がＩＭＴ網で構成される場合について示しているが、これに限定されるものではなく、ＩＭＴ網以外の網で構成されていても構わない。

移動通信センター１１は、インターネット１４を介してコンテンツサーバ１２と接続されており、移動通信網１３とインターネット１４との間でＨＴＴＰプロトコルに従って通信を行うことができる機能を有している。特に、本実施の形態に係る移動通信センター１１は、携帯電話機１０がパイプライン対応端末であるか判定し、パイプライン対応端末である場合には、携帯電話機１０からのリクエストを連続して受信可能とするモード（以下、適宜「パイプラインモード」という）に移行する。

コンテンツサーバ１２は、インターネット１４を介してアクセスしてきたクライアントに対してコンテンツを配信する。携帯電話機１０がクライアントとしてアクセスしてきた場合には、インターネット１４を介して移動通信センター１１にコンテンツを配信し、この移動通信センター１１を経由してコンテンツを携帯電話機１０に配信する。ここで、コンテンツサーバ１２は、パーソナルコンピュータ向けに作成されたＷｅｂサイトを表示するためのコンテンツを配信するものとする。また、コンテンツサーバ１２は、ＨＴＴＰ／１．０に対応し、携帯電話機１０と異なり、リクエストパイプラインには対応していないものとする。

このような構成を有し、本実施の形態に係る移動通信ネットワークシステムにおいては、コンテンツサーバ１２がＨＴＴＰ／１．１に対応していない場合においても、移動通信網１３におけるリクエストのパイプライン化を行うものである。具体的には、移動通信センター１１において、携帯電話機１０がパイプライン対応端末であるか判定し、パイプライン対応端末である場合には携帯電話機１０からのリクエストを連続して受信可能とするものである。

図２は、本実施の形態に係る移動通信ネットワークシステムが有する移動通信センター１１の構成を示すブロック図である。なお、図２においては、特に、本実施の形態に係る移動通信センター１１が移動通信網１３におけるリクエストのパイプライン化を行う際に必要な構成について示し、リクエストのパイプライン化を行った後にデータを送受信する構成については省略している。また、図２においては、移動通信網１３及びインターネット１４を省略している。

図２に示す移動通信センター１１において、リクエスト受信部２１は、移動通信網１３を介して携帯電話機１０から到来するリクエストを受信する。リクエスト送信部２２は、携帯電話機１０から受信したリクエストを、インターネット１４を介してコンテンツサーバ１２に送信する。レスポンス受信部２３は、インターネット１４を介してコンテンツサーバ１２から到来するＨＴＴＰレスポンス（以下、単に「レスポンス」という）を受信する。レスポンス送信部２４は、コンテンツサーバ１２から受信したレスポンスを、移動通信網１３を介して携帯電話機１０に送信する。

パイプライン判定部２５は、携帯電話機１０から受信したリクエストのヘッダ部分を解析し、携帯電話機１０がパイプライン対応端末であるか等の所定条件を判定し、パイプライン処理の実行を判定する。なお、パイプライン対応端末であるか等の所定条件の判定については後述する。リクエスト保持部２６は、パイプラインモードに移行した場合に必要なリクエストを保持する。具体的には、パイプラインモードに移行した場合において、携帯電話機１０からのリクエスト（リクエスト１）に対応するレスポンスを受信していない状態で、後続するリクエスト（リクエスト２）を受信した場合に当該リクエスト（リクエスト２）を保持する。

Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ判定部２７は、コンテンツサーバ１２から受信したレスポンスのヘッダ部分を解析し、その解析結果に基づいてＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈが不正であるか判定する。例えば、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値がコンテンツサーバ１２から実際に受信するデータ（以下、適宜「実データ」という）よりも大きい場合、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値が実データよりも小さい場合、並びに、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈが存在しない場合を、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ不正として判定する。そして、判定したＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ不正の内容に応じて、必要な処理を実行する。例えば、リクエスト保持部２６に保持されるリクエストを破棄、コンテンツサーバ１２から受信したレスポンスの破棄などの処理を行う。

コネクションヘッダ判定部２８は、パイプラインモードに移行した場合において、コンテンツサーバ１２から受信したレスポンスのコネクションヘッダの内容を判定し、必要に応じてその内容を書き換える。具体的には、コンテンツサーバ１２から受信したレスポンスのコネクションヘッダに「ｃｌｏｓｅ」が付与されているか判定し、「ｃｌｏｓｅ」が付与されている場合には、これを「Ｋｅｅｐ−Ａｌｉｖｅ」に書き換える。このようにコネクションヘッダに付与される「ｃｌｏｓｅ」を「Ｋｅｅｐ−Ａｌｉｖｅ」に書き換えることで、移動通信網１３におけるパイプライン処理を継続できるようにしている。なお、コンテンツサーバ１２から受信したレスポンスのコネクションヘッダに「Ｋｅｅｐ−Ａｌｉｖｅ」が付与されている場合には、コネクションヘッダの内容を書き換えることはない。

以下、本実施の形態に係る移動通信ネットワークシステムにおいて、移動通信網１３でパイプライン処理が行われる場合の処理について説明する。図３は、本実施の形態に係る移動通信ネットワークシステムにおいて、移動通信網１３でパイプライン処理が行われる場合の処理について説明するためのシーケンス図である。なお、図３においては、上述のように、携帯電話機１０はＨＴＴＰ／１．１に対応し、リクエストパイプラインに対応する一方、コンテンツサーバ１２はＨＴＴＰ／１．０に対応し、リクエストパイプラインには対応していないものとする。

図３に示すように、本実施の形態に係る移動通信ネットワークシステムにおいて、携帯電話機１０から移動通信網１３を介してリクエストが移動通信センター１１に送信されると（ステップ(以下、「ＳＴ」と略す)３０１）、移動通信センター１１において、パイプラインモードに移行する否かを判定するパイプライン判定処理が行われる（ＳＴ３０２）。なお、このパイプライン判定処理は、パイプライン判定部２５により行われる。

ここで、移動通信センター１１により行われるパイプライン判定処理について図４を用いて説明する。図４は、移動通信センター１１により行われるパイプライン判定処理について説明するためのフロー図である。

図４に示すように、移動通信センター１１においては、常に、携帯電話機１０からリクエストを受信するかが監視されている（ＳＴ４０１）。そして、リクエストを受信した場合には、携帯電話機１０がパイプライン対応端末であって、フルブラウザからのアクセスであるかが判定される（ＳＴ４０２）。具体的には、リクエストのＵＡにより特定される携帯電話機１０の機種情報によって、パイプライン対応端末であるかが判定される。なお、パイプライン対応端末であるか否かの判定は、これに限定されるものではなく、その他の情報（例えば、携帯電話機１０の製造番号等）に基づいて行うようにしても良い。

そして、携帯電話機１０がパイプライン対応端末であって、フルブラウザからのアクセスであると判定された場合には、リクエストのＨＴＴＰバージョンがＨＴＴＰ／１．１であるかが判定される（ＳＴ４０３）。また、リクエストのＨＴＴＰバージョンがＨＴＴＰ／１．１であると判定された場合には、リクエストのメソッドがＧＥＴ又はＨＥＡＤであるかが判定される（ＳＴ４０４）。そして、リクエストのメソッドがＧＥＴ又はＨＥＡＤであると判定された場合には、移動通信センター１１の動作モードがパイプラインモードに移行する（ＳＴ４０５）。

すなわち、本実施の形態において、移動通信センター１１は、リクエストのＵＡがパイプライン対応端末であり、フルブラウザからのアクセスであって（ＳＴ４０２）、ＨＴＴＰバージョンがＨＴＴＰ／１．１であって（ＳＴ４０３）、メソッドがＧＥＴ又はＨＥＡＤである場合（ＳＴ４０４）に限り、パイプラインモードに移行できるようになっている。このように、携帯電話機１０からのリクエストのＵＡ、ＨＴＴＰバージョン及びメソッドの内容に応じてパイプラインモードへの移行が判定されるので、必要な場合にのみ移動通信網１３におけるパイプラインモードへの移行が可能となる。パイプラインモードに移行した場合においては、後続する携帯電話機１０からのリクエストがパイプライン処理によって処理されることとなる。つまり、移動通信センター１１において、携帯電話機１０からのリクエストに対するコンテンツサーバ１２からのレスポンスを待たず、連続してリクエストを受信することが可能となる。このようにパイプラインモードへの移行が決定された後、パイプライン判定処理が終了する。

なお、図４に示すパイプライン判定処理においては、パイプラインモードへの移行条件として、フルブラウザからのアクセスであるか否かを判定しているが、これに代えてブラウザの種類のよって判定するようにしても良い。例えば、判定の対象となるブラウザは、携帯電話機用ブラウザであっても良い。また、パイプラインモードへの移行条件として、リクエストのメソッドがＧＥＴ又はＨＥＡＤであるか否かについて判定しているが、これに代えてＧＥＴ、ＨＥＡＤ又はＰＯＳＴであるか否かを判定するようにしても良い。

なお、ＳＴ４０２において、携帯電話機１０がパイプライン対応端末でないか、フルブラウザからのアクセスでないと判定された場合、ＳＴ４０３において、リクエストのＨＴＴＰバージョンがＨＴＴＰ／１．１でないと判定された場合、並びに、ＳＴ４０４において、リクエストのメソッドがＧＥＴ又はＨＥＡＤでないと判定された場合には、移動通信センター１１の動作モードが通常モード（携帯電話機１０からのリクエストに対して通常の処理を行うモード）に移行する（ＳＴ４０６）。このように通常モードへの移行が決定された後、パイプライン判定処理が終了する。

図３に戻り、その説明を続ける。なお、ここでは、ＳＴ３０２のパイプライン判定処理において上記全ての条件が満たされ、移動通信センター１１の動作モードがパイプラインモードに移行したものとする。パイプライン判定処理が行われた後、移動通信センター１１からコンテンツサーバ１２に対してリクエストが送信される（ＳＴ３０３）。

リクエストを受信すると、これに応じてコンテンツサーバ１２から移動通信センター１１に対してレスポンスが送信される（ＳＴ３０４）。そして、このリクエストを受信すると、移動通信センター１１から携帯電話機１０に対してレスポンスが送信される（ＳＴ３０５）。このリクエストを受信すると、携帯電話機１０から複数のリクエストが、個々のレスポンスの受信を待つことなく連続して移動通信センター１１に送信される。図３においては、３つのリクエスト１〜リクエスト３が連続して移動通信センター１１に送信される場合について示している（ＳＴ３０６〜ＳＴ３０８）。

３つのリクエスト１〜リクエスト３を受信すると、移動通信センター１１からコンテンツサーバ１２に対してリクエスト１が送信される（ＳＴ３０９）。このとき、移動通信センター１１においては、リクエスト２及びリクエスト３がリクエスト保持部２６に保持される。リクエスト保持部２６に保持されたリクエスト２（リクエスト３）は、後述するように、それぞれリクエスト１（リクエスト２）に対するレスポンス１（レスポンス２）の受信を契機としてコンテンツサーバ１２に送信される。

リクエスト１を受信すると、コンテンツサーバ１２からリクエスト１に応じたレスポンス１が移動通信センター１１に送信される（ＳＴ３１０）。なお、レスポンス１には、コネクションヘッダに「ｃｌｏｓｅ」が付与されているものとする。レスポンス１を受信すると、移動通信センター１１において、その内容を判定するレスポンス判定処理が行われる（ＳＴ３１１）。なお、このレスポンス判定処理は、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ判定部２７及びコネクションヘッダ判定部２８により行われる。

ここで、移動通信センター１１により行われるレスポンス判定処理について図５を用いて説明する。図５は、移動通信センター１１により行われるレスポンス判定処理について説明するためのフロー図である。なお、図５においては、説明の便宜上、携帯電話機１０へのレスポンスの送信処理について記載している。

図５に示すように、移動通信センター１１においては、常に、コンテンツサーバ１２からレスポンスを受信するかが監視されている（ＳＴ５０１）。そして、レスポンスを受信した場合には、そのレスポンスのコネクションヘッダに「ｃｌｏｓｅ」が付与されているか、「Ｋｅｅｐ−Ａｌｉｖｅ」が付与されているかが判定される（ＳＴ５０２）。ここで、コネクションヘッダに「ｃｌｏｓｅ」が付与されていると判定された場合には、これが「Ｋｅｅｐ−Ａｌｉｖｅ」に書き換えられ（ＳＴ５０３）、ＳＴ５０４に移行する。一方、コネクションヘッダに「Ｋｅｅｐ−Ａｌｉｖｅ」が付与されていると判定された場合には、書き換えが行われず、そのままＳＴ５０４に移行する。

通常、コンテンツサーバ１２から送信されるレスポンスには、そのコネクションヘッダに「ｃｌｏｓｅ」が付与されている。しかし、コネクションヘッダに「ｃｌｏｓｅ」が付与されたレスポンスをそのまま携帯電話機１０に送信した場合には、移動通信センター１１と携帯電話機１０とのコネクションが切断されてしまう。このため、本実施の形態に係る移動通信センター１１においては、レスポンスのコネクションヘッダに付与された「ｃｌｏｓｅ」を、「Ｋｅｅｐ−Ａｌｉｖｅ」に書き換えることで携帯電話機１０とコンテンツサーバ１２との通信が切断される事態を防止している。

ＳＴ５０３でコネクションヘッダの内容が「Ｋｅｅｐ−Ａｌｉｖｅ」に書き換えられた後、或いは、ＳＴ５０２でコネクションヘッダの内容が「Ｋｅｅｐ−Ａｌｉｖｅ」に維持された後、移動通信センター１１においては、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈが存在するかが判定される（ＳＴ５０４）。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈが存在するかを判定するのは、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈが存在しない不正を判定するためである。なお、図５に示すフローにおいては、レスポンスのコネクションヘッダに付与された「ｃｌｏｓｅ」の書き換え等を行った後にＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの判定を行う場合について示しているが、かかる処理順序については、これに限定されるものではなく適宜変更が可能である。

Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈが存在すると判定された場合には、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値が実データよりも大きいかが判定される（ＳＴ５０５）。ここで、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値が実データよりも大きいと判定された場合には、実データ分のデータが携帯電話機１０に送信された後、携帯電話機１０と移動通信センター１１との間、並びに、移動通信センター１１とコンテンツサーバ１２との間のＴＣＰ接続が一時的に切断され、リクエスト保持部２６にリクエストが残っている場合には当該リクエストが破棄される（ＳＴ５０６）。このように、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が実データより大きい場合、必要に応じて携帯電話機１０からのリクエストが破棄されるので、リクエストが残存することに起因して後続するパイプライン処理が制限される事態を防止している。これらの処理を行った後、レスポンス判定処理が終了する。

Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値が実データよりも大きくないと判定された場合には、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値が実データよりも小さいかが判定される（ＳＴ５０７）。ここで、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値が実データよりも小さいと判定された場合には、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値分のデータが携帯電話機１０に送信された後、残りのレスポンスを受信した場合には当該レスポンスが破棄される（ＳＴ５０８）。このように、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が実データより小さい場合、必要に応じてコンテンツサーバ１２からのレスポンスが破棄されるので、レスポンスが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。これらの処理を行った後、レスポンス判定処理が終了する。

なお、ＳＴ５０７において、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値が実データよりも小さくないと判定された場合には、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値と実データとが同一であるとして、当該実データが携帯電話機１０に送信される（ＳＴ５０９）。その後、レスポンス判定処理が終了する。

また、ＳＴ５０４において、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈが存在しないと判定された場合には、携帯電話機１０に対してＢＯＤＹ部が送信された後、携帯電話機１０と移動通信センター１１との間、並びに、移動通信センター１１とコンテンツサーバ１２との間のＴＣＰ接続が一時的に切断され、リクエスト保持部２６にリクエストが残っている場合には当該リクエストが破棄される（ＳＴ５１０）。このように、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈが存在しない場合、必要に応じて携帯電話機１０からのリクエストが破棄されるので、リクエストが残存することに起因して後続するパイプライン処理が制限される事態を防止している。これらの処理を行った後、レスポンス判定処理が終了する。

なお、上記ＳＴ５０６及びＳＴ５１０において、携帯電話機１０と移動通信センター１１との間、並びに、移動通信センター１１とコンテンツサーバ１２との間のＴＣＰ接続が一時的に切断された場合には、携帯電話機１０から移動通信センター１１に対してリクエストが再送されるように構成されている（図３に不図示）。この場合において、移動通信センター１１からのレスポンスを受信中にＴＣＰ接続が切断された場合には、パイプライン処理によりレスポンスを待機中であった全てのリクエストが再送される。なお、ＴＣＰ接続の切断が発生したレスポンスに対応するリクエストについては再送処理の対象外とされる。しかしながら、レスポンスを受信していない場合において、リクエストを再送する場合には、パイプライン処理の先頭のリクエストは再送対象とされる。

このように本実施の形態に係る移動通信ネットワークシステムにおいては、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈの不正が発生した場合、ＳＴ５０６、ＳＴ５０８及びＳＴ５１０において、適宜、携帯電話機１０からのリクエスト又はコンテンツサーバ１２からのレスポンスを破棄することで、移動機から到来する再リクエストを正常に受信することができるようにしている。

図３に戻り、その説明を続ける。ここで、ＳＴ３１１のレスポンス判定処理においては、ＳＴ５０３においてコネクションヘッダに付与された「ｃｌｏｓｅ」が「Ｋｅｅｐ−Ａｌｉｖｅ」に書き換えられ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値と実データとが同一であると判定されたものとする。レスポンス判定処理が行われた後、移動通信センター１１から携帯電話機１０に対してレスポンス１が送信される（ＳＴ３１２）。この場合において、レスポンス１には、コネクションヘッダに「Ｋｅｅｐ−Ａｌｉｖｅ」が付与されている。

レスポンス１が携帯電話機１０に送信されると、これに続いて、移動通信センター１１からコンテンツサーバ１２に対してリクエスト２が送信される（ＳＴ３１３）。リクエスト２を受信すると、コンテンツサーバ１２からリクエスト２に応じたレスポンス２が移動通信センター１１に送信される（ＳＴ３１４）。なお、レスポンス２には、コネクションヘッダに「ｃｌｏｓｅ」が付与されているものとする。

レスポンス２を受信すると、移動通信センター１１において、上述した要領でレスポンス判定処理が行われる（ＳＴ３１５）。ここで、ＳＴ３１５のレスポンス判定処理においては、ＳＴ３１１と同様に、ＳＴ５０３においてコネクションヘッダに付与された「ｃｌｏｓｅ」が「Ｋｅｅｐ−Ａｌｉｖｅ」に書き換えられ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値と実データとが同一であると判定されたものとする。レスポンス判定処理が行われた後、移動通信センター１１から携帯電話機１０に対してレスポンス１が送信される（ＳＴ３１６）。この場合において、レスポンス２には、コネクションヘッダに「Ｋｅｅｐ−Ａｌｉｖｅ」が付与されている。

レスポンス２が携帯電話機１０に送信されると、これに続いて、移動通信センター１１からコンテンツサーバ１２に対してリクエスト３が送信される（ＳＴ３１７）。リクエスト３を受信すると、コンテンツサーバ１２からリクエスト３に応じたレスポンス３が移動通信センター１１に送信される（ＳＴ３１８）。なお、レスポンス３には、コネクションヘッダに「Ｋｅｅｐ−Ａｌｉｖｅ」が付与されているものとする。

レスポンス３を受信すると、移動通信センター１１において、上述した要領でレスポンス判定処理が行われる（ＳＴ３１９）。ここで、ＳＴ３１９のレスポンス判定処理においては、ＳＴ３１１やＳＴ３１５と異なり、コネクションヘッダに付与された「Ｋｅｅｐ−Ａｌｉｖｅ」が書き換えられることなく維持され、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ値と実データとが同一であると判定されたものとする。レスポンス判定処理が行われた後、移動通信センター１１から携帯電話機１０に対してレスポンス３が送信される（ＳＴ３２０）。この場合において、レスポンス３には、コネクションヘッダに「Ｋｅｅｐ−Ａｌｉｖｅ」が付与されている。

このように、移動通信センター１１から送信されるレスポンスを順次受信し、表示画面で表示することにより、携帯電話機１０でコンテンツサーバ１２から配信されるコンテンツを閲覧することが可能となる。このようにして、本実施の形態に係る移動通信ネットワークシステムにおいて、移動通信網１３でパイプライン処理が行われる場合の一連の処理が完了する。

このように本実施の形態に係る移動通信ネットワークシステムによれば、携帯電話機１０から受信したリクエストが所定条件を満たす場合、移動通信センター１１により携帯電話機１０からのリクエストを連続して受信可能なパイプライン処理が実行されることから、移動通信網１３においてリクエストとレスポンスとが繰り返される結果、移動通信網１３における通信状況の影響を受けて通信時間が長くなる事態が防止されるので、携帯電話機１０でコンテンツを取得するための時間を十分に短縮することが可能となる。

特に、本実施の形態に係る移動通信ネットワークシステムにおいては、移動通信センター１１を介して携帯電話機１０にコンテンツを配信するコンテンツサーバ１２を更に具備し、移動通信センター１１は、パイプラインモードで携帯電話機１０から連続して受信したリクエストを順次コンテンツサーバ１２に送信する一方、当該リクエストに対応するレスポンスをコンテンツサーバ１２から受信する。このため、コンテンツサーバ１２から移動通信センター１１を介して携帯電話機１０にコンテンツを配信する場合においても、移動通信網１３においてリクエストとレスポンスとが繰り返される結果、移動通信網１３における通信状況の影響を受けて通信時間が長くなる事態が防止されるので、携帯電話機１０でコンテンツを取得するための時間を十分に短縮することが可能となる。

また、本実施の形態に係る移動通信ネットワークシステムにおいては、移動通信センター１１は、コンテンツサーバ１２からのレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正を検出すると、必要に応じて携帯電話機１０からのリクエスト又はコンテンツサーバ１２からのレスポンスを破棄してパイプライン処理を継続する。このように、コンテンツサーバ１２からのレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正が検出された場合においても、必要に応じて携帯電話機１０からのリクエスト又はコンテンツサーバ１２からのレスポンスを破棄してパイプライン処理が継続されるので、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正に応じて携帯電話機１０とコンテンツサーバ１２との間の通信が切断される事態を防止しつつ、携帯電話機１０でコンテンツを取得するための時間を短縮することが可能となる。

なお、本発明は、上記実施の形態に限定されず、本発明の効果を発揮する範囲内において種々変更して実施することが可能である。また、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。

例えば、上記実施の形態においては、携帯電話機１０が移動通信センター１１を介してコンテンツサーバ１２が配信するコンテンツ（パーソナルコンピュータ向けに作成されたＷｅｂサイトを表示するためのコンテンツ）を受信する場合について説明しているが、携帯電話機１０が受信するコンテンツについては、これに限定されるものではなく、適宜変更が可能である。例えば、携帯電話機１０向けに作成されたＷｅｂサイトを表示するためのコンテンツを移動通信センター１１から受信する場合に本発明を適用しても良い。この場合においても、移動通信網１３においてリクエストとレスポンスとが繰り返される結果、移動通信網１３における通信状況の影響を受けて通信時間が長くなる事態が防止されるので、携帯電話機１０でコンテンツを取得するための時間を十分に短縮することが可能となる。

本発明の一実施の形態に係る移動通信ネットワークシステムの構成を示す図である。 上記実施の形態に係る移動通信ネットワークシステムが有する移動通信センター１１の構成を示すブロック図である。 上記実施の形態に係る移動通信ネットワークシステムにおいて、移動通信網でパイプライン処理が行われる場合の処理を説明するためのシーケンス図である。 上記実施の形態に係る移動通信ネットワークシステムの移動通信センターにより行われるパイプライン判定処理について説明するためのフロー図である。 上記実施の形態に係る移動通信ネットワークシステムの移動通信センターにより行われるレスポンス判定処理について説明するためのフロー図である。

符号の説明

１０ 携帯電話機（移動体端末装置）
１１ 移動通信センター（サーバ装置）
１２ コンテンツサーバ（コンテンツ配信装置）
１３ 移動通信網
１４ インターネット
２１ リクエスト受信部
２２ リクエスト送信部
２３ レスポンス受信部
２４ レスポンス送信部
２５ パイプライン判定部
２６ リクエスト保持部
２７ Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ判定部
２８ コネクションヘッダ判定部

Claims (25)

1. ブラウザ機能を有する移動体端末装置と、移動通信網を介して前記移動体端末装置における移動通信を管理するサーバ装置とを具備し、前記移動体端末装置からＷｅｂアクセスするためのリクエストを受信すると、前記サーバ装置は、当該リクエストが所定条件を満たすか判定し、前記所定条件を満たす場合に前記移動体端末装置からのＨＴＴＰリクエストを連続して受信可能なパイプライン処理を実行することを特徴とする移動通信ネットワークシステム。
2. 前記サーバ装置は、前記リクエストのＵＡ、ＨＴＴＰバージョン及びメソッドの内容に応じて前記パイプライン処理の実行を判定することを特徴とする請求項１記載の移動通信ネットワークシステム。
3. 前記サーバ装置は、前記リクエストのＵＡが前記パイプライン処理の対応端末であって所定のブラウザからのアクセスであり、ＨＴＴＰバージョンがＨＴＴＰ／１．１であり、所定のメソッドの場合に前記パイプライン処理を実行することを特徴とする請求項２記載の移動通信ネットワークシステム。
4. 前記サーバ装置は、前記所定のブラウザがフルブラウザからのアクセスである場合に前記パイプライン処理を実行することを特徴とする請求項３記載の移動通信ネットワークシステム。
5. 前記サーバ装置は、前記所定のブラウザが前記移動体端末装置用ブラウザからのアクセスである場合に前記パイプライン処理を実行することを特徴とする請求項３記載の移動通信ネットワークシステム。
6. 前記サーバ装置は、前記リクエストのメソッドがＧＥＴ又はＨＥＡＤである場合に前記パイプライン処理を実行することを特徴とする請求項３から請求項５のいずれかに記載の移動通信ネットワークシステム。
7. 前記サーバ装置は、前記リクエストのメソッドがＧＥＴ、ＨＥＡＤ又はＰＯＳＴである場合に前記パイプライン処理を実行することを特徴とする請求項３から請求項５のいずれかに記載の移動通信ネットワークシステム。
8. 前記サーバ装置を介して前記移動体端末装置にコンテンツを配信するコンテンツ配信装置を更に具備し、前記サーバ装置は、前記パイプライン処理で連続して受信したＨＴＴＰリクエストを順次前記コンテンツ配信装置に送信する一方、当該ＨＴＴＰリクエストに対応するＨＴＴＰレスポンスを前記コンテンツ配信装置から受信することを特徴とする請求項１から請求項７のいずれかに記載の移動通信ネットワークシステム。
9. 前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正を検出すると、必要に応じて前記移動体端末装置からのＨＴＴＰリクエスト又は前記コンテンツ配信装置からのＨＴＴＰレスポンスを破棄して前記パイプライン処理を継続することを特徴とする請求項８記載の移動通信ネットワークシステム。
10. 前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより大きい場合、必要に応じて前記移動体端末装置からのＨＴＴＰリクエストを破棄することを特徴とする請求項９記載の移動通信ネットワークシステム。
11. 前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより小さい場合、必要に応じて前記コンテンツ配信装置からのＨＴＴＰレスポンスを破棄することを特徴とする請求項９又は請求項１０記載の移動通信ネットワークシステム。
12. 前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにＣｏｎｔｅｎｔ−ｌｅｎｇｔｈヘッダが存在しない場合、必要に応じて前記移動体端末装置からのＨＴＴＰリクエストを破棄することを特徴とする請求項９から請求項１１のいずれかに記載の移動通信ネットワークシステム。
13. 前記サーバ装置は、前記コンテンツ配信装置からのＨＴＴＰレスポンスのコネクションヘッダにｃｌｏｓｅが付与されている場合、当該コネクションヘッダの内容をＫｅｅｐ−Ａｌｉｖｅに書き換えて前記パイプライン処理を継続することを特徴とする請求項９から請求項１２のいずれかに記載の移動通信ネットワークシステム。
14. 移動通信網を介して移動体端末装置における移動通信を管理するサーバ装置であって、
    前記移動体端末装置からのリクエストを受信するリクエスト受信部と、前記リクエスト受信部で受信したリクエストが所定条件を満たすか判定し、前記所定条件を満たす場合に前記移動体端末装置からのＨＴＴＰリクエストを連続して受信可能なパイプライン処理を実行させるパイプライン判定部と、前記パイプライン処理で前記移動体端末装置から連続して受信したＨＴＴＰリクエストを保持するリクエスト保持部と、前記移動体端末装置にレスポンスを送信するレスポンス送信部とを具備することを特徴とするサーバ装置。
15. 前記パイプライン判定部は、前記リクエストのＵＡ、ＨＴＴＰバージョン及びメソッドの内容に応じて前記パイプライン処理の実行を判定することを特徴とする請求項１４記載のサーバ装置。
16. 前記パイプライン判定部は、前記リクエストのＵＡが前記パイプライン処理の対応端末であって所定のブラウザからのアクセスであり、ＨＴＴＰバージョンがＨＴＴＰ／１．１であり、所定のメソッドの場合に前記パイプライン処理を実行することを特徴とする請求項１５記載のサーバ装置。
17. 前記パイプライン判定部は、前記所定のブラウザがフルブラウザからのアクセスである場合に前記パイプライン処理を実行することを特徴とする請求項１６記載のサーバ装置。
18. 前記パイプライン判定部は、前記所定のブラウザが前記移動体端末装置用ブラウザからのアクセスである場合に前記パイプライン処理を実行することを特徴とする請求項１６記載のサーバ装置。
19. 前記パイプライン判定部は、前記リクエストのメソッドがＧＥＴ又はＨＥＡＤである場合に前記パイプライン処理を実行することを特徴とする請求項１６から請求項１８のいずれかに記載のサーバ装置。
20. 前記パイプライン判定部は、前記リクエストのメソッドがＧＥＴ、ＨＥＡＤ又はＰＯＳＴである場合に前記パイプライン処理を実行することを特徴とする請求項１６から請求項１８のいずれかに記載のサーバ装置。
21. 前記移動体端末装置からのリクエストをコンテンツ配信装置に送信するリクエスト送信部と、前記コンテンツ配信装置からのレスポンスを受信するレスポンス受信部と、前記レスポンス受信部で受信したＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正を判定するＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部とを具備し、
    前記Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部は、Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈの不正を検出すると、必要に応じて前記移動体端末装置からのＨＴＴＰリクエスト又は前記コンテンツ配信装置からのＨＴＴＰレスポンスを破棄して前記パイプライン処理を継続することを特徴とする請求項１４から請求項２０のいずれかに記載のサーバ装置。
22. 前記Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより大きい場合、必要に応じて前記移動体端末装置からのＨＴＴＰリクエストを破棄することを特徴とする請求項２１記載のサーバ装置。
23. 前記Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈ値が当該コンテンツ配信装置から実際に送信されるデータより小さい場合、必要に応じて前記コンテンツ配信装置からのＨＴＴＰレスポンスを破棄することを特徴とする請求項２１又は請求項２２記載のサーバ装置。
24. 前記Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ判定部は、前記コンテンツ配信装置からのＨＴＴＰレスポンスにＣｏｎｔｅｎｔ−ｌｅｎｇｔｈヘッダが存在しない場合、必要に応じて前記移動体端末装置からのＨＴＴＰリクエストを破棄することを特徴とする請求項２１から請求項２３のいずれかに記載のサーバ装置。
25. 前記レスポンス受信部で受信したＨＴＴＰレスポンスにおけるＣｏｎｔｅｎｔ−ｌｅｎｇｔｈのコネクションヘッダを判定するコネクションヘッダ判定部を具備し、前記コネクションヘッダ判定部は、ＨＴＴＰレスポンスのコネクションヘッダにｃｌｏｓｅが付与されている場合、当該コネクションヘッダの内容をＫｅｅｐ−Ａｌｉｖｅに書き換えて前記パイプライン処理を継続することを特徴とする請求項１４から請求項２４のいずれかに記載のサーバ装置。

Images