WO2008075600A1

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

Info

Publication number: WO2008075600A1
Application number: PCT/JP2007/073967
Authority: WO
Inventors: Sohei Tani; Tomonori Nakamura; Hisashi Hamada
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2006-12-19
Filing date: 2007-12-12
Publication date: 2008-06-26
Anticipated expiration: 2009-06-19
Also published as: JP2008152629A; US20110119323A1; EP2096548A1; CN101584180A; JP4976121B2; EP2096548A4; US8271580B2; CN101584180B

Abstract

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

Description

明細書

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

技術分野

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

背景技術

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

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

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

[0005] ここで、リクエストパイプラインを実行するためには、コンテンツサーバが HTTP/1 . 1に対応している必要がある。コンテンツサーバが HTTP/1. 1に対応していない場合には、上述のようにリクエストとレスポンスとが繰り返されることとなる。そして、従来、このようにコンテンツサーバが HTTP/1. 1に対応していない場合においても、ユーザ装置とサーバ装置との間の通信を HTTPプロコトルに従って行うことができる改良データ通信方法が提案されている (例えば、特許文献 1参照）。この改良データ通信方法においては、コンテンツサーバが HTTP/1. 1に対応していない場合にプロキシサーバにて HTTPプロトコルのバージョンを変換することで、ユーザ装置とコンテンッサーバとの間の HTTPプロコトノレ通信を確保している。

特許文献 1 :特表 2004— 530231号公報

発明の開示

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

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

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

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

[0010] 上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記リクエストの UA、 HTTPバージョン及びメソッドの内容に応じて前記パイプライン処理の実行を判定することが考えられる。例えば、前記リクエストの UAが前記パイプライン処理の対応端末であって所定のブラウザからのアクセスであり、 HTTPバージョンが HTTP /1. 1であり、所定のメソッドの場合にパイプライン処理を実行することが好ましい。所定のブラウザとしては、例えば、フルブラウザ又は移動体端末装置用ブラウザからのアクセスである場合が考えられる。所定のメソッドとしては、例えば、 GET又は HE ADである場合や、 GET、 HEAD又は POSTである場合が考えられる。この場合には、移動体端末装置からのリクエストの UA、 HTTPバージョン及びメソッドの内容に応じてパイプライン処理の実行が判定されるので、必要な場合にのみ移動通信網におけるパイプライン処理を実行することが可能となる。

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

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

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

[0014] 例えば、上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記コンテンッ配信装置からの HTTPレスポンスにおける Content— length値が当該コンテンッ配信装置力実際に送信されるデータより大きい場合、必要に応じて前記移動体端末装置からの HTTPリクエストを破棄する。この場合には、 Content -length 値が当該コンテンツ配信装置力実際に送信されるデータより大きい場合に必要に応じて移動体端末装置からの HTTPリクエストが破棄されるので、 HTTPリクエストが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。 [0015] また、上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記コンテンッ配信装置からの HTTPレスポンスにおける Content— length値が当該コンテンッ配信装置から実際に送信されるデータより小さい場合、必要に応じて前記コンテンッ配信装置からの HTTPレスポンスを破棄する。この場合には、 Content— length 値が当該コンテンツ配信装置力実際に送信されるデータより小さい場合に必要に応じてコンテンツ配信装置からの HTTPレスポンスが破棄されるので、 HTTPレスポンスが残存することに起因して後続するパイプライン処理が制限される事態を防止すること力 S可倉となる。

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

[0017] また、上記移動通信ネットワークシステムにおいて、前記サーバ装置は、前記コンテンッ配信装置からの HTTPレスポンスのコネクションヘッダに closeが付与されている場合、当該コネクションヘッダの内容を Keep— Aliveに書き換えて前記パイプライン処理を継続することが好ましい。この場合には、 HTTPレスポンスにおけるコネクションヘッダに closeが付与された場合においても、当該コネクションヘッダの内容を Kee p— Aliveに書き換えてパイプライン処理を継続が継続されるので、コネクションへッダに付与された closeに従って移動体端末装置とコンテンツ配信装置との間の通信が切断される事態を防止しつつ、移動体端末装置でコンテンツを取得するための時間を短縮することが可能となる。

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

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

[0020] 上記サーバ装置において、前記パイプライン判定部は、前記リクエストの UA、 HT TPバージョン及びメソッドの内容に応じて前記パイプライン処理を実行させることが考えられる。例えば、前記リクエストの UAが前記パイプライン処理の対応端末であつて所定のブラウザからのアクセスであり、 HTTPバージョンが HTTP/1. 1であり、所定のメソッドである場合にパイプライン処理を実行させることが好まし!/、。所定のブラゥザとしては、例えば、フルブラウザ又は移動体端末装置用ブラウザからのアクセスである場合が考えられる。所定のメソッドとしては、例えば、 GET又は HEADである場合や、 GET、 HEAD又は POSTである場合が考えられる。この場合には、移動体端末装置からのリクエストの UA、 HTTPバージョン及びメソッドの内容に応じてパイプライン処理が実行されるので、必要な場合にのみ移動通信網においてパイプライン処理を実行することが可能となる。

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

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

[0023] また、上記サーバ装置において、前記 Content— length判定部は、前記コンテンッ配信装置からの HTTPレスポンスにおける Content— length値が当該コンテンツ配信装置から実際に送信されるデータより小さい場合、必要に応じて前記コンテンツ配信装置からの HTTPレスポンスを破棄する。この場合には、 Content— length値が当該コンテンツ配信装置力実際に送信されるデータより小さい場合に必要に応じてコンテンツ配信装置からの HTTPレスポンスが破棄されるので、 HTTPレスポンスが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。

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

[0025] また、上記サーバ装置において、前記レスポンス受信部で受信した HTTPレスポンスにおける Content— lengthのコネクションヘッダを判定するコネクションヘッダ判定部を具備し、前記コネクションヘッダ判定部は、 HTTPレスポンスのコネクションへッダに closeが付与されている場合、当該コネクションヘッダの内容を Keep— Alive に書き換えて前記パイプライン処理を継続することが好ましい。この場合には、 HTT Pレスポンスにおけるコネクションヘッダに closeが付与された場合においても、当該コネクションヘッダの内容を Keep—Aliveに書き換えてパイプライン処理が継続されるので、コネクションヘッダに付与された closeに従って移動体端末装置とコンテンツ配信装置との間の通信が切断される事態を防止しつつ、移動体端末装置でコンテンッを取得するための時間を短縮することが可能となる。

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

図面の簡単な説明

[0027] [図 1]本発明の一実施の形態に係る移動通信ネットワークシステムの構成を示す図 [図 2]上記実施の形態に係る移動通信ネットワークシステムが有する移動通信センタ一の構成を示すブロック図

[図 3]上記実施の形態に係る移動通信ネットワークシステムにおいて、移動通信網でパイプライン処理が行われる場合の処理を説明するためのシーケンス図

[図 4]上記実施の形態に係る移動通信ネットワークシステムの移動通信センターにより行われるパイプライン判定処理について説明するためのフロー図

[図 5]上記実施の形態に係る移動通信ネットワークシステムの移動通信センターにより行われるレスポンス判定処理について説明するためのフロー図発明を実施するための最良の形態

[0028] 以下、本発明の実施の形態について添付図面を参照して詳細に説明する。

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

[0029] 携帯電話機 10は、例えば、 IMT (International Mobile Telecommunication)網等の通信ネットワークで構成される移動通信網 13、並びに、インターネット 14のような通信ネットワークを介してコンテンツサーバ 12にアクセス可能に構成されている。そして、携帯電話機 10は、このような通信ネットワークを介して、後述するように、コンテンツサーバ 12から配信されるコンテンツを閲覧できるようになつている。特に、携帯電話機 1 0は、 HTTP/1. 1に対応し、複数の HTTPリクエスト（以下、単に「リクエスト」という）を、個々のレスポンスの受信を待つことなく連続して送信可能に構成されている（リクェストパイプライン)。以下においては、 HTTP/1. 1に対応する携帯電話機について、適宜「パイプライン対応端末」と呼ぶものとする。なお、図 1においては、移動通信網 13が IMT網で構成される場合について示している力これに限定されるものではなぐ IMT網以外の網で構成されて!/、ても構わな!/、。

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

[0031] コンテンツサーバ 12は、インターネット 14を介してアクセスしてきたクライアントに対してコンテンツを配信する。携帯電話機 10がクライアントとしてアクセスしてきた場合には、インターネット 14を介して移動通信センター 11にコンテンツを配信し、この移動通信センター 11を経由してコンテンツを携帯電話機 10に配信する。ここで、コンテンッサーバ 12は、パーソナルコンピュータ向けに作成された Webサイトを表示するためのコンテンツを配信するものとする。また、コンテンツサーバ 12は、 HTTP/1. 0 に対応し、携帯電話機 10と異なり、リクエストパイプラインには対応していないものとする。

[0032] このような構成を有し、本実施の形態に係る移動通信ネットワークシステムにおいては、コンテンツサーバ 12が HTTP/1. 1に対応していない場合においても、移動通信網 13におけるリクエストのパイプライン化を行うものである。具体的には、移動通信センター 11において、携帯電話機 10がパイプライン対応端末であるか判定し、パイプライン対応端末である場合には携帯電話機 10からのリクエストを連続して受信可倉とするあのである。

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

[0034] 図 2に示す移動通信センター 11において、リクエスト受信部 21は、移動通信網 13 を介して携帯電話機 10から到来するリクエストを受信する。リクエスト送信部 22は、携帯電話機 10から受信したリクエストを、インターネット 14を介してコンテンツサーバ 12 に送信する。レスポンス受信部 23は、インターネット 14を介してコンテンツサーバ 12 力、ら到来する HTTPレスポンス（以下、単に「レスポンス」という）を受信する。レスポンス送信部 24は、コンテンツサーバ 12から受信したレスポンスを、移動通信網 13を介して携帯電話機 10に送信する。

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

[0036] Content— Length判定部 27は、コンテンツサーバ 12から受信したレスポンスのへッダ部分を解析し、その解析結果に基づレ、て Content— Lengthが不正であるか判定する。例えば、 Content— Length値がコンテンツサーバ 12から実際に受信するデータ（以下、適宜「実データ」という）よりも大きい場合、 Content— Length値が実データよりも小さい場合、並びに、 Content— Lengthが存在しない場合を、 Conten t— Length不正として判定する。そして、判定した Content— Length不正の内容に応じて、必要な処理を実行する。例えば、リクエスト保持部 26に保持されるリクエストを破棄、コンテンツサーバ 12から受信したレスポンスの破棄などの処理を行う。

[0037] コネクションヘッダ判定部 28は、パイプラインモードに移行した場合において、コンテンッサーバ 12から受信したレスポンスのコネクションヘッダの内容を判定し、必要に応じてその内容を書き換える。具体的には、コンテンツサーバ 12から受信したレスポンスのコネクションヘッダに「close」が付与されて!/、るか判定し、「close」が付与されている場合には、これを「Keep— Alive」に書き換える。このようにコネクションへッダに付与される 1036」を¾6印一八1 6」に書き換えることで、移動通信網 13におけるパイプライン処理を継続できるようにしている。なお、コンテンツサーバ 12から受信したレスポンスのコネクションヘッダに「Keep— Alive」が付与されている場合には、コネクションヘッダの内容を書き換えることはない。

[0038] 以下、本実施の形態に係る移動通信ネットワークシステムにおいて、移動通信網 1 3でパイプライン処理が行われる場合の処理について説明する。図 3は、本実施の形態に係る移動通信ネットワークシステムにおいて、移動通信網 13でパイプライン処理が行われる場合の処理について説明するためのシーケンス図である。なお、図 3においては、上述のように、携帯電話機 10は HTTP/ 1 · 1に対応し、リクエストパイプラインに対応する一方、コンテンツサーバ 12は ΗΤΤΡ/1 · 0に対応し、リクエストパイプラインには対応して!/、な!/、ものとする。 [0039] 図 3に示すように、本実施の形態に係る移動通信ネットワークシステムにおいて、携帯電話機 10から移動通信網 13を介してリクエストが移動通信センター 11に送信されると (ステップ (以下、「ST」と略す) 301)、移動通信センター 11において、パイプラインモードに移行する否かを判定するパイプライン判定処理が行われる（ST302)。なお、このパイプライン判定処理は、パイプライン判定部 25により行われる。

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

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

[0042] そして、携帯電話機 10がパイプライン対応端末であって、フルブラウザからのァクセスであると判定された場合には、リクエストの HTTPバージョンが HTTP/1. 1であるかが判定される（ST403)。また、リクエストの HTTPバージョンが HTTP/1. 1であると判定された場合には、リクエストのメソッドが GET又は HEADであるかが判定される（ST404)。そして、リクエストのメソッドが GET又は HEADであると判定された場合には、移動通信センター 11の動作モードがパイプラインモードに移行する（ST40 5)。

[0043] すなわち、本実施の形態において、移動通信センター 11は、リクエストの UAがパィプライン対応端末であり、フルブラウザからのアクセスであって（ST402)、 HTTP バージョンが ΗΤΤΡ/1 · 1であって（ST403)、メソッドが GET又は HEADである場合（ST404)に限り、パイプラインモードに移行できるようになつている。このように、携帯電話機 10力ものリクエストの UA、 HTTPバージョン及びメソッドの内容に応じてパィプラインモードへの移行が判定されるので、必要な場合にのみ移動通信網 13におけるパイプラインモードへの移行が可能となる。パイプラインモードに移行した場合においては、後続する携帯電話機 10からのリクエストがパイプライン処理によって処理されることとなる。つまり、移動通信センター 11において、携帯電話機 10からのリクェストに対するコンテンツサーバ 12からのレスポンスを待たず、連続してリクエストを受信することが可能となる。このようにパイプラインモードへの移行が決定された後、パィプライン判定処理が終了する。

[0044] なお、図 4に示すパイプライン判定処理においては、パイプラインモードへの移行条件として、フルブラウザからのアクセスであるか否かを判定している力これに代えてブラウザの種類のよって判定するようにしても良い。例えば、判定の対象となるブラゥザは、携帯電話機用ブラウザであっても良い。また、パイプラインモードへの移行条件として、リクエストのメソッドが GET又は HEADであるか否かにつ!/、て判定して!/、る 1S これに代えて GET、 HEAD又は POSTであるか否かを判定するようにしても良い。

[0045] なお、 ST402において、携帯電話機 10がパイプライン対応端末でないか、フルブラウザからのアクセスでないと判定された場合、 ST403において、リクエストの HTTP バージョンが HTTP/1. 1でないと判定された場合、並びに、 ST404において、リクェストのメソッドが GET又は HEADでな!/、と判定された場合には、移動通信センター 11の動作モードが通常モード（携帯電話機 10からのリクエストに対して通常の処理を行うモード）に移行する（ST406)。このように通常モードへの移行が決定された後、ノィプライン判定処理が終了する。

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

[0047] リクエストを受信すると、これに応じてコンテンツサーバ 12から移動通信センター 11 に対してレスポンスが送信される（ST304)。そして、このリクエストを受信すると、移動通信センター 11から携帯電話機 10に対してレスポンスが送信される（ST305)。このリクエストを受信すると、携帯電話機 10から複数のリクエストが、個々のレスポンスの受信を待つことなく連続して移動通信センター 11に送信される。図 3にお!/、ては、 3つのリクエスト 1〜リクエスト 3が連続して移動通信センター 11に送信される場合にっレヽてしてレヽる（ST306〜ST308)。

[0048] 3つのリクエスト 1〜リクエスト 3を受信すると、移動通信センター 11からコンテンツサーバ 12に対してリクエスト 1が送信される（ST309)。このとき、移動通信センター 11 においては、リクエスト 2及びリクエスト 3がリクエスト保持部 26に保持される。リクエスト保持部 26に保持されたリクエスト 2 (リクエスト 3)は、後述するように、それぞれリクエスト 1 (リクエスト 2)に対するレスポンス 1 (レスポンス 2)の受信を契機としてコンテンツサーバ 12に送信される。

[0049] リクエスト 1を受信すると、コンテンツサーバ 12からリクエスト 1に応じたレスポンス 1が移動通信センター 11に送信される（ST310)。なお、レスポンス 1には、コネクションヘッダに「close」が付与されているものとする。レスポンス 1を受信すると、移動通信センター 11にお!/、て、その内容を判定するレスポンス判定処理が行われる（ST311 )。なお、このレスポンス判定処理は、 Content— Length判定部 27及びコネクションヘッダ判定部 28により行われる。

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

[0051] 図 5に示すように、移動通信センター 11においては、常に、コンテンツサーバ 12からレスポンスを受信するかが監視されている（ST501)。そして、レスポンスを受信した場合には、そのレスポンスのコネクションヘッダに「close」が付与されている力、、「Kee p—Alive」が付与されているかが判定される（ST502)。ここで、コネクションヘッダに「close」が付与されていると判定された場合には、これが「Keep—Alive」に書き換えられ（ST503)、 ST504に移行する。一方、コネクションヘッダに「Keep—Alive」が付与されていると判定された場合には、書き換えが行われず、そのまま ST504に移行する。

[0052] 通常、コンテンツサーバ 12から送信されるレスポンスには、そのコネクションヘッダに「close」が付与されている。し力、し、コネクションヘッダに「close」が付与されたレスポンスをそのまま携帯電話機 10に送信した場合には、移動通信センター 11と携帯電話機 10とのコネクションが切断されてしまう。このため、本実施の形態に係る移動通信センター 11においては、レスポンスのコネクションヘッダに付与された「close」を、「 Keep— Alive」に書き換えることで携帯電話機 10とコンテンツサーバ 12との通信が切断される事態を防止してレ、る。

[0053] ST503でコネクションヘッダの内容力 S「Keep— AliveJに書き換えられた後、或いは、 ST502でコネクションヘッダの内容が「Keep—Alive」に維持された後、移動通信センター 11にお!/、ては、 Content— Lengthが存在するかが判定される（ST504 )。 Content— Lengthが存在するかを判定するのは、 Content— Lengthが存在しない不正を判定するためである。なお、図 5に示すフローにおいては、レスポンスのコネクシヨンヘッダに付与された「close」の書き換え等を行った後に Content— Lengt hの判定を行う場合について示している力力、かる処理順序については、これに限定されるものではなく適宜変更が可能である。

[0054] Content— Lengthが存在すると判定された場合には、 Content— Length値が実データよりも大きいかが判定される（ST505)。ここで、 Content— Length値が実データよりも大きいと判定された場合には、実データ分のデータが携帯電話機 10に送信された後、携帯電話機 10と移動通信センター 11との間、並びに、移動通信センター 11とコンテンツサーバ 12との間の TCP接続が一時的に切断され、リクエスト保持部 26にリクエストが残っている場合には当該リクエストが破棄される（ST506)。このように、 Content— length値が実データより大きい場合、必要に応じて携帯電話機 10 力ものリクエストが破棄されるので、リクエストが残存することに起因して後続するパイプライン処理が制限される事態を防止している。これらの処理を行った後、レスポンス判定処理が終了する。

[0055] Content— Length値が実データよりも大きくないと判定された場合には、 Conten t— Length値が実データよりも小さいかが判定される（ST507)。ここで、 Content— Length値が実データよりも小さいと判定された場合には、 Content— Length値分のデータが携帯電話機 10に送信された後、残りのレスポンスを受信した場合には当該レスポンスが破棄される（ST508)。このように、 Content— length値が実データより小さい場合、必要に応じてコンテンツサーバ 12からのレスポンスが破棄されるので、レスポンスが残存することに起因して後続するパイプライン処理が制限される事態を防止することが可能となる。これらの処理を行った後、レスポンス判定処理が終了する。

[0056] なお、 ST507において、 Content— Length値が実データよりも小さくないと判定された場合には、 Content— Length値と実データとが同一であるとして、当該実データが携帯電話機 10に送信される（ST509)。その後、レスポンス判定処理が終了する

〇

[0057] また、 ST504において、 Content— Lengthが存在しないと判定された場合には、携帯電話機 10に対して BODY部が送信された後、携帯電話機 10と移動通信センタ一 11との間、並びに、移動通信センター 11とコンテンツサーバ 12との間の TCP接続が一時的に切断され、リクエスト保持部 26にリクエストが残っている場合には当該リクェストが破棄される（ST510)。このように、 Content— lengthが存在しない場合、必要に応じて携帯電話機 10からのリクエストが破棄されるので、リクエストが残存することに起因して後続するパイプライン処理が制限される事態を防止している。これらの処理を行った後、レスポンス判定処理が終了する。

[0058] なお、上記 ST506及び ST510において、携帯電話機 10と移動通信センター 11との間、並びに、移動通信センター 11とコンテンツサーバ 12との間の TCP接続が一時的に切断された場合には、携帯電話機 10から移動通信センター 11に対してリクエストが再送されるように構成されてレ、る（図 3に不図示）。この場合にお!/、て、移動通信センター 11からのレスポンスを受信中に TCP接続が切断された場合には、パイプライン処理によりレスポンスを待機中であった全てのリクエストが再送される。なお、 TC P接続の切断が発生したレスポンスに対応するリクエストについては再送処理の対象外とされる。し力もながら、レスポンスを受信していない場合において、リクエストを再送する場合には、パイプライン処理の先頭のリクエストは再送対象とされる。

[0059] このように本実施の形態に係る移動通信ネットワークシステムにおいては、 Conten t一： Lengthの不正カ発生した場合、 ST506, ST508及び ST510におレヽて、適宜、携帯電話機 10力ものリクエスト又はコンテンツサーバ 12からのレスポンスを破棄することで、移動機から到来する再リクエストを正常に受信することができるようにしている

〇

[0060] 図 3に戻り、その説明を続ける。ここで、 ST311のレスポンス判定処理においては、

3丁503にぉぃてコネクションへッダに付与された「。1036」が「1¾^ ー八1^^」に書き換えられ、 Content— Length値と実データとが同一であると判定されたものとする。レスポンス判定処理が行われた後、移動通信センター 11から携帯電話機 10に対してレスポンス 1が送信される（ST312)。この場合において、レスポンス 1には、コネクシヨンヘッダに「Keep—Alive」が付与されている。

[0061] レスポンス 1が携帯電話機 10に送信されると、これに続いて、移動通信センター 11 力、らコンテンツサーバ 12に対してリクエスト 2が送信される（ST313)。リクエスト 2を受信すると、コンテンツサーバ 12からリクエスト 2に応じたレスポンス 2が移動通信センタ一 11に送信される（ST314)。なお、レスポンス 2には、コネクションヘッダに「close」が付与されているものとする。

[0062] レスポンス 2を受信すると、移動通信センター 11において、上述した要領でレスポンス判定処理が行われる（ST315)。ここで、 ST315のレスポンス判定処理においては、 ST311と同様に、 ST503においてコネクションヘッダに付与された「close S「Ke ep- Alive Jに書き換えられ、 Content— Length値と実データとが同一であると判定されたものとする。レスポンス判定処理が行われた後、移動通信センター 11から携帯電話機 10に対してレスポンス 1が送信される（ST316)。この場合において、レスポンス 2には、コネクションヘッダに「Keep— Alive」が付与されている。

[0063] レスポンス 2が携帯電話機 10に送信されると、これに続いて、移動通信センター 11 力、らコンテンツサーバ 12に対してリクエスト 3が送信される（ST317)。リクエスト 3を受信すると、コンテンツサーバ 12からリクエスト 3に応じたレスポンス 3が移動通信センタ一 11に送信される（ST318)。なお、レスポンス 3には、コネクションヘッダに「Keep - Alive jが付与されて!/、るものとする。

[0064] レスポンス 3を受信すると、移動通信センター 11において、上述した要領でレスポンス判定処理が行われる（ST319)。ここで、 ST319のレスポンス判定処理においては、 ST311や ST315と異なり、コネクションヘッダに付与された「： eep— Alive」が書き換えられることなく維持され、 Content— Length値と実データとが同一であると判定されたものとする。レスポンス判定処理が行われた後、移動通信センター 11から携帯電話機 10に対してレスポンス 3が送信される（ST320)。この場合において、レスポンス 3には、コネクションヘッダに「Keep—Alive」が付与されている。

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

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

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

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

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

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

産業上の利用可能性

[0071] 以上説明したように、本発明に係る移動通信ネットワークシステム及びサーバ装置は、移動体端末装置からの Webアクセスするためのリクエストが所定条件を満たす場合に移動体端末装置からの HTTPリクエストを連続して受信可能なパイプライン処理を実行し、移動体端末装置でコンテンツを取得するための時間を十分に短縮するものであり、産業上の利用可能性を有する。

Claims

請求の範囲

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

[2] 前記サーバ装置は、前記リクエストの UA、 HTTPバージョン及びメソッドの内容に応じて前記パイプライン処理の実行を判定することを特徴とする請求項 1記載の移動通信ネットワークシステム。

[3] 前記サーバ装置は、前記リクエストの UAが前記パイプライン処理の対応端末であつて所定のブラウザからのアクセスであり、 HTTPバージョンが HTTP/1. 1であり、所定のメソッドの場合に前記パイプライン処理を実行することを特徴とする請求項 2記載の移動通信ネットワークシステム。

[4] 前記サーバ装置は、前記所定のブラウザがフルブラウザからのアクセスである場合に前記パイプライン処理を実行することを特徴とする請求項 3記載の移動通信ネットワークシステム。

[5] 前記サーバ装置は、前記所定のブラウザが前記移動体端末装置用ブラウザからのアクセスである場合に前記パイプライン処理を実行することを特徴とする請求項 3記載の移動通信ネットワークシステム。

[6] 前記サーバ装置は、前記リクエストのメソッドが GET又は HEADである場合に前記パイプライン処理を実行することを特徴とする請求項 3記載の移動通信ネットワークシステム。

[7] 前記サーバ装置は、前記リクエストのメソッドが GET、 HEAD又は POSTである場合に前記パイプライン処理を実行することを特徴とする請求項 3記載の移動通信ネットワークシステム。

[8] 前記サーバ装置を介して前記移動体端末装置にコンテンツを配信するコンテンツ配信装置を更に具備し、前記サーバ装置は、前記パイプライン処理で連続して受信した HTTPリクエストを順次前記コンテンツ配信装置に送信する一方、当該 HTTPリタエストに対応する HTTPレスポンスを前記コンテンツ配信装置から受信することを特徴とする請求項 1記載の移動通信ネットワークシステム。

前記サーバ装置は、前記コンテンツ配信装置からの HTTPレスポンスにおける Co ntent— lengthの不正を検出すると、必要に応じて前記移動体端末装置からの HT TPリクエスト又は前記コンテンツ配信装置からの HTTPレスポンスを破棄して前記パィプライン処理を継続することを特徴とする請求項 8記載の移動通信ネットワークシステム。

前記サーバ装置は、前記コンテンツ配信装置からの HTTPレスポンスにおける Co ntent— length値が当該コンテンツ配信装置から実際に送信されるデータより大きい場合、必要に応じて前記移動体端末装置からの HTTPリクエストを破棄することを特徴とする請求項 9記載の移動通信ネットワークシステム。

前記サーバ装置は、前記コンテンツ配信装置からの HTTPレスポンスにおける Co ntent— length値が当該コンテンツ配信装置から実際に送信されるデータより小さい場合、必要に応じて前記コンテンツ配信装置からの HTTPレスポンスを破棄することを特徴とする請求項 9記載の移動通信ネットワークシステム。

前記サーバ装置は、前記コンテンツ配信装置からの HTTPレスポンスに Content lengthヘッダが存在しない場合、必要に応じて前記移動体端末装置からの HTT pリクエストを破棄することを特徴とする請求項 9記載の移動通信ネットワークシステム前記サーバ装置は、前記コンテンツ配信装置からの HTTPレスポンスのコネクションヘッダに closeが付与されている場合、当該コネクションヘッダの内容を Keep— A1 iveに書き換えて前記パイプライン処理を継続することを特徴とする請求項 9記載の移動通信ネットワークシステム。

移動通信網を介して移動体端末装置における移動通信を管理するサーバ装置であってゝ

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

[15] 前記パイプライン判定部は、前記リクエストの UA、 HTTPバージョン及びメソッドの内容に応じて前記パイプライン処理の実行を判定することを特徴とする請求項 14記載のサーバ装置。

[16] 前記パイプライン判定部は、前記リクエストの UAが前記パイプライン処理の対応端末であって所定のブラウザからのアクセスであり、 HTTPバージョンが HTTP/1. 1 であり、所定のメソッドの場合に前記パイプライン処理を実行することを特徴とする請求項 15記載のサーバ装置。

[17] 前記パイプライン判定部は、前記所定のブラウザがフルブラウザからのアクセスである場合に前記パイプライン処理を実行することを特徴とする請求項 16記載のサーバ装置。

[18] 前記パイプライン判定部は、前記所定のブラウザが前記移動体端末装置用ブラウザからのアクセスである場合に前記パイプライン処理を実行することを特徴とする請求項 16記載のサーバ装置。

[19] 前記パイプライン判定部は、前記リクエストのメソッドが GET又は HEADである場合に前記パイプライン処理を実行することを特徴とする請求項 16記載のサーバ装置。

[20] 前記パイプライン判定部は、前記リクエストのメソッドが GET、 HEAD又は POSTである場合に前記パイプライン処理を実行することを特徴とする請求項 16記載のサーバ装置。

[21] 前記移動体端末装置からのリクエストをコンテンツ配信装置に送信するリクエスト送信部と、前記コンテンツ配信装置からのレスポンスを受信するレスポンス受信部と、前記レスポンス受信部で受信した HTTPレスポンスにおける Content— lengthの不正を判定する Content— length判定部とを具備し、

前記 Content— length判定部は、 Content— lengthの不正を検出すると、必要に応じて前記移動体端末装置からの HTTPリクエスト又は前記コンテンツ配信装置力、らの HTTPレスポンスを破棄して前記パイプライン処理を継続することを特徴とする請求項 14記載のサーバ装置。

[22] 前記 Content— length判定部は、前記コンテンツ配信装置からの HTTPレスポンスにおける Content— lengtW直が当該コンテンツ配信装置から実際に送信されるデータより大きい場合、必要に応じて前記移動体端末装置からの HTTPリクエストを破棄することを特徴とする請求項 21記載のサーバ装置。

[23] 前記 Content— length判定部は、前記コンテンツ配信装置からの HTTPレスポンスにおける Content— lengtW直が当該コンテンツ配信装置から実際に送信されるデータより小さい場合、必要に応じて前記コンテンツ配信装置からの HTTPレスポンスを破棄することを特徴とする請求項 21記載のサーバ装置。

[24] 前記 Content— length判定部は、前記コンテンツ配信装置からの HTTPレスポンスに Content— lengthヘッダが存在しない場合、必要に応じて前記移動体端末装置からの HTTPリクエストを破棄することを特徴とする請求項 21記載のサーバ装置。

[25] 前記レスポンス受信部で受信した HTTPレスポンスにおける Content— lengthのコネクションヘッダを判定するコネクションヘッダ判定部を具備し、前記コネクションへッダ判定部は、 HTTPレスポンスのコネクションヘッダに closeが付与されて!/、る場合、当該コネクションヘッダの内容を Keep— Aliveに書き換えて前記パイプライン処理を継続することを特徴とする請求項 14記載のサーバ装置。