JP4739369B2

JP4739369B2 - ウェブコンテンツ変換編集システム

Info

Publication number: JP4739369B2
Application number: JP2008128176A
Authority: JP
Inventors: 暁田中; 聡西澤
Original assignee: SoftBank Mobile Corp
Current assignee: SoftBank Corp
Priority date: 2008-05-15
Filing date: 2008-05-15
Publication date: 2011-08-03
Anticipated expiration: 2022-11-20
Also published as: JP2008251031A

Description

本発明は、ウェブ上に位置するコンテンツ提供元のアプリケーションサーバから移動通信網における移動局が、コンテンツを取得するためのウェブコンテンツ変換編集システムに関するものである。

一般に、１９８０年代のアナログ方式の移動通信システム（ＮＴＴ方式，ＡＭＰＳ（Advanced Mobile Phone Service），ＴＡＣＳ（Total Access Communications System）など）が第１世代と呼ばれ、１９９０年代のディジタル方式の移動通信システム（ＰＤＣ（Personal Digital Cellular telecommunication system），ＧＳＭ（global system for mobile communication），ＩＳ−５４，ＩＳ−９５など）が第２世代（以下、「２Ｇシステム」という）と呼ばれている。これらの移動通信システムの普及はめざましく、我が国においては移動電話の普及台数は６０００万台を超えるまでに至っている。このような移動電話は携帯電話機として普及しており、携帯電話機を端末としてインターネットメールを送受信することや、ウェブコンテンツをインターネット上のサーバから取得することが行われるようになってきている。

オフィスや家庭におけるパーソナルコンピュータ等に導入されている一般的なウェブブラウザや、ウェブサイト上で公開されている各種コンテンツ等は、パーソナルコンピュータ等の大型のディスプレイ装置に表示することを前提として設計されて提供されている。一方、携帯電話機においては携帯性を重視していることから、ディスプレイにおけるメッセージ表示領域や、取得したデータを格納するメモリ領域が制限されている。また、携帯電話機のほとんどは、一般的なウェブブラウジング機能を備えているが、パーソナルコンピュータ等にインストールされているウェブブラウザの豊富な機能の全てを備えてはいない。従って、携帯電話機からインターネット上で公開されている各種コンテンツを取得しようとしてもコンテンツを完全に取得できない場合があるという問題点があった。また、各種コンテンツを取得した場合に、表示できなかったり表示されても異常な表示になってしまうという問題点があった。

そこで、本発明は、移動局における制約を吸収することのできるウェブコンテンツ変換編集システムを提供することを目的としている。

上記目的を達成するために、本発明のウェブコンテンツ変換編集システムは、移動局とコンテンツ提供元との間で送受信されるメッセージの変換編集を行うウェブコンテンツ変換編集システムであって、前記移動局からのコンテンツを要求する要求メッセージを処理して前記コンテンツ提供元に送信する第１制御手段と、前記要求メッセージに対応して前記コンテンツ提供元から取得した応答メッセージを処理して前記移動局へ送信する第２制御手段とを備え、前記第１制御手段は、前記移動局から圧縮されたコンテンツを要求する要求メッセージを受け取った際に、前記要求メッセージのリクエストヘッダにおいてコンテンツの圧縮タイプのいずれかが指定されている場合、あるいは、前記リクエストヘッダにおいてコンテンツの圧縮タイプが指定されていない場合には、当該リクエストヘッダに、前記コンテンツ提供元からコンテンツを圧縮して送信させないことを通知するための値を設定して前記コンテンツ提供元に送信するようにしている。

また、上記本発明のウェブコンテンツ変換編集システムにおいて、前記第２制御手段は、前記コンテンツ提供元から非圧縮とされているコンテンツを取得し、前記リクエストヘッダにおいて圧縮タイプのいずれかが指定されている場合は、前記非圧縮とされているコンテンツを前記リクエストヘッダにおいて指定された圧縮タイプになるよう圧縮処理して前記移動局へ送信し、前記リクエストヘッダにおいてコンテンツの圧縮タイプが指定されていない場合には、前記非圧縮とされているコンテンツを所定の圧縮タイプになるよう圧縮処理して前記移動局へ送信するようにしてもよい。
さらに、上記本発明のウェブコンテンツ変換編集システムにおいて、前記移動局からのコンテンツを取得する要求メッセージの前記リクエストヘッダにおいて、受け入れられる圧縮タイプ情報が指定されていた場合は、前記第２制御手段は、前記移動局が受け入れることができるコンテンツサイズが少なくとも設定されている定義ファイルに設定されているコンテンツサイズと、前記第１制御手段により編集された要求メッセージに対応して前記コンテンツ提供元から取得した非圧縮のコンテンツのコンテンツサイズとを対比して、取得した当該コンテンツのコンテンツサイズが前記定義ファイルに設定されているコンテンツサイズ以上とされている場合に、前記取得した非圧縮のコンテンツを指定された圧縮タイプになるよう圧縮処理して前記移動局へ送るようにしてもよい。

このような本発明によれば、移動局から圧縮されたコンテンツを要求された際には、コンテンツ提供元からは非圧縮のコンテンツを取得し、指定された圧縮タイプに圧縮して送るようにしている。これにより、コンテンツ提供元から取得したコンテンツを解凍した後に、さらに圧縮する処理を行う必要をなくすことができ、処理効率が低下することを防止することができる。また、移動局の仕様上の制約等を極力吸収することができ、移動局におけるウェブ通信におけるユーザビリティを向上することができるようになる。

本発明の実施の形態のウェブコンテンツ変換編集システムを備えるネットワークの概略構成を図１に示す。
図１に示すネットワークは、移動通信網とインターネット等の他のネットワークとを有しており、移動通信網は、例えば携帯電話機とされる移動局（ＭＳ）１０と無線通信路１１として示されている。また、他のネットワークはそのネットワーク上に位置しているアプリケーションサーバ１３ａ、１３ｂ、１３ｃとして示されている。本発明にかかるウェブコンテンツ変換編集システム１２は、移動通信網と他のネットワークとの間に配置されており、移動局１０とコンテンツ提供元であるアプリケーションサーバ１３ａ〜１３ｃとの間で送受信されるメッセージの変換編集を行っている。

移動局１０は、アプリケーションサーバ１３ａ〜１３ｃのいずれかからコンテンツを取得する際にＨＴＴＰ（HyperText Transport Protocol）リクエスト（Request）をアプリケーションサーバ１３ａ〜１３ｃに向けて送信する。このＨＴＴＰリクエストを受けたアプリケーションサーバ１３ａ〜１３ｃは、要求されたコンテンツをエンティテイボディとするＨＴＴＰレスポンス（Response）を移動局１０へ向けて送り出す。この場合において、移動局１０とアプリケーションサーバ１３ａ〜１３ｃとの間に配置されている本発明にかかるウェブコンテンツ変換編集システム１２は、次に説明するウェブコンテンツ変換編集に関する後述する各種処理を実行する。

ウェブコンテンツ変換編集システム１２が実行するウェブコンテンツ変換編集処理の一つにページサイズチェック処理がある。このページサイズチェック処理は、移動局１０がコンテンツを取得する際に、アプリケーションサーバ１３ａ〜１３ｃのいずれかから送られて来たＨＴＴＰレスポンスにおけるコンテンツであるエンティテイボディのバイト長をチェックする処理である。このページサイズチェック処理を行うことにより、移動局１０が不用意にコンテンツ提供側のアプリケーションサーバ１３ａ〜１３ｃから大きなコンテンツを取得することを防止し、無線通信路１１のリソースを有効に利用できるようになる。ページサイズチェック処理においてあらかじめ設定する上限バイト長は、ＨＴＴＰ／１．１のレスポンスヘッダで指定されるコンテンツタイプ（text（テキスト）、image（イメージ）、application（アプリケーション）等）毎にページサイズチェック定義ファイルで設定するようにしている。

このページサイズチェック定義ファイルでは、コンテンツタイプおよびそのサイズ長が、間に「，」を入れて示されている。その一例を説明すると、「text/x-mml,1024」は、コンテンツがx-mmlタイプのテキストファイルのバイト長の上限が１０２４バイト長未満とされていることを意味しており、当該タイプのバイト長が１０２４バイト以上とされている場合は、チェックエラーを送信する。また、「text/*,0」は、コンテンツがページサイズチェック定義ファイルで定義されている以外のテキスト系コンテンツとされている場合は、非許容コンテンツとしてエラー送信することを意味している。さらに、「image/png.2048」はＰＮＧ（Portable Network Graphics）タイプのイメージファイルのバイト長の上限が２０４８バイト未満とされていることを意味しており、当該タイプのバイト長が２０４８バイト以上とされている場合は、チェックエラーを送信する。他のコンテンツタイプに対するサイズ長も、図３に示すページサイズチェック定義ファイルにおける該当する定義ファイルを同様に解釈することができる。

ウェブコンテンツ変換編集システム１２が実行するコンテンツ変換編集処理におけるページサイズチェック処理では、アプリケーションサーバ１３ａ〜１３ｃのいずれかからコンテンツを取得した時に、エンティテイボディのバイト長情報を得る。そして、ページサイズチェック定義ファイルを参照して、この定義ファイルに設定されているコンテンツタイプおよびサイズ長と、取得されたコンテンツのコンテンツタイプとエンティテイボディのバイト長とを対比する。ここで、アプリケーションサーバ１３ａ〜１３ｃのいずれかから取得したコンテンツのコンテンツタイプが一致しない場合は、コンテンツタイプが異なる旨のエラーメッセージを、要求されたコンテンツに代えて移動局１０へ送信する。また、エンティテイボディのバイト長が設定されているサイズ長以上と判断された際に、あらかじめ用意されているコンテンツのサイズが大きすぎる旨のエラーメッセージを、要求されたコンテンツに代えて移動局１０へ送信する。なお、ＨＴＴＰ／１．１のレスポンスヘッダにおいてコンテンツがＣＧＩ（Common Gateway Interface）等のプログラムとされてコンテンツサイズが未指定とされている場合は、エンティティボディ部のサイズを計算してそのバイト長を算出し、算出結果に基づいてページサイズチェック処理を行うようにする。

ここで、ウェブコンテンツ変換編集システム１２が実行するページサイズチェック処理のフローチャートを図２に示す。
ページサイズチェック処理がスタートすると、ステップＳ１０にてアプリケーションサーバ１３ａ〜１３ｃのいずれかからＨＴＴＰリクエストに対して取得されたＨＴＴＰレスポンスにおけるレスポンスヘッダよりtext/HTML等のコンテンツタイプ（Content-Type）を取得する。次いで、ステップＳ１１にてレスポンスヘッダから取得されたコンテンツタイプと、ページサイズチェック定義ファイル中で設定されているコンテンツタイプとを対比してコンテンツタイプが一致するか否かが判断される。ここで、一致すると判断された場合はステップＳ１３に分岐してページサイズチェック定義ファイル中で設定されている当該コンテンツタイプのサイズの設定値が”０”か否かが判断される。ここで、当該コンテンツタイプのサイズの設定値が”０”と判断されると、そのコンテンツタイプはサポートされていないことからステップＳ２０に分岐して「未サポートコンテンツである」旨のページを移動局１０へ送信して、移動局１０の表示部にそのページを表示させる。この場合、コンテンツは取得されず移動局１０へ送られない。

また、ステップＳ１４にて当該コンテンツタイプのサイズの設定値が”０”でないと判断されると、ステップＳ１４に進んでレスポンスヘッダにコンテンツのサイズ（Content-Length）が設定されているか否かが判断される。ここで、レスポンスヘッダにコンテンツのサイズ（Content-Length）が設定されていると判断された場合は、ステップＳ１５に進んでレスポンスヘッダより「１２３６」等のコンテンツのサイズ（Content-Length）が取得される。また、ステップＳ１４にてレスポンスヘッダにコンテンツのサイズ（Content-Length）が設定されていないと判断された場合は、ステップＳ１６へ分岐してＨＴＴＰレスポンスのエンティティボディ部のサイズを計算して代用する。ただし、コンテンツを分割して送るチャンクド（Chunked）転送コーディングとされている場合は、分割されているコンテンツを結合後、エンティティボディ部のサイズを計算して代用する。

そして、ステップＳ１５あるいはステップＳ１６の処理が終了すると、ステップＳ１７にて取得あるいは計算されたコンテンツのサイズが、ページサイズチェック定義ファイル中で設定されている当該コンテンツタイプのサイズ以上か否かが判断される。ここで、ページサイズチェック定義ファイル中で設定されている当該コンテンツタイプのサイズより小さいと判断された場合は、ＨＴＴＰレスポンスにおけるコンテンツのサイズが移動局１０の仕様に合ったサイズとされていることからステップＳ１８に進み、取得されたＨＴＴＰレスポンスが編集されることなくそのまま移動局１０へ送信される。また、ページサイズチェック定義ファイル中で設定されている当該コンテンツタイプのサイズ以上と判断された場合はステップＳ１９に進み、ＨＴＴＰレスポンスにおけるコンテンツのサイズが大きすぎて移動局１０の仕様を逸脱していることから、「コンテンツサイズが大きすぎる」旨のページを、コンテンツに替えて移動局１０へ送信して、移動局１０の表示部にそのページを表示させる。なお、ステップＳ１１にてページサイズチェック定義ファイル中で設定されているコンテンツタイプとを対比してコンテンツタイプが一致しないと判断された場合は、そのコンテンツタイプを制限する条件が設定されていないことからステップＳ１２に進んで取得されたＨＴＴＰレスポンスが編集されることなくそのまま移動局１０へ送信される。

以上説明したページサイズチェック処理においては、コンテンツを分割して送るチャンクド転送コーディングが指定されている場合は、コンテンツをアプリケーションサーバ１３ａ〜１３ｃのいずれかからコンテンツを分割して取得してウェブコンテンツ変換編集システム１２が移動局１０へ送る際に、分割されたコンテンツを結合した全体のサイズにおいてページサイズチェック処理を行うようにする。なお、コンテンツタイプおよびサイズを定義するページサイズチェック定義ファイルはその設定内容が変更可能とされている。

次に、ウェブコンテンツ変換編集システム１２が実行するウェブコンテンツ変換編集処理の一つにレンジリクエスト対応処理がある。レンジリクエストとは、コンテンツの内で範囲を指定してその範囲だけを取得するリクエストである。ところで、コンテンツが圧縮処理等されている場合は、コンテンツの圧縮処理の形態がウェブコンテンツ変換編集システム１２を間に挟んで異なる場合があり、この場合には移動局１０側とアプリケーションサーバ１３ａ〜１３ｃのコンテンツ提供側において、コンテンツのサイズ等の物理的実体が異なる場合がある。すると、移動局１０がレンジリクエストにより部分コンテンツの要求をした際に、要求した部分コンテンツと取得した部分コンテンツとの間にデータの矛盾が生じるおそれがあることになる。

そこで、これを防止するために、ウェブコンテンツ変換編集システム１２は、移動局１０から受け取ったＨＴＴＰリクエストにおけるヘッダーにレンジを指定するヘッダがあった場合（レンジリクエスト）は、このレンジを指定しているレンジリクエストのヘッダーを削除してアプリケーションサーバ１３ａ〜１３ｃ側へ送り、アプリケーションサーバ１３ａ〜１３ｃ側からのレスポンスとして全コンテンツを受け取るようにする。そして、ウェブコンテンツ変換編集システム１２は、受け取った全コンテンツの内のレンジリクエストのヘッダーにおいて指定された範囲の部分コンテンツを移動局１０へ送るようにする。これにより、要求した部分コンテンツと取得した部分コンテンツとの間にデータの矛盾が生じるおそれを防止することができる。しかし、移動局１０からの全てのレンジリクエストの要求を拒否してしまうと、アプリケーションサーバ１３ａ〜１３ｃ側から常に全コンテンツを送信することになり通信効率が低下することになる。そこで、要求した部分コンテンツと取得した部分コンテンツとの間にデータの矛盾が生じるおそれが通常は生じないファイルタイプをレンジリクエスト対象処理外のファイルとして定義している。このRangeリクエスト対象処理外定義ファイルの一例を図５に示す。そして、ＨＴＴＰリクエストにより要求されたコンテンツのファイルタイプの拡張子が、図５に示す定義された拡張子と一致する場合は、レンジリクエストをそのままアプリケーションサーバ１３ａ〜１３ｃへ向けて送信する。これにより、通信効率の低下を防止することができる。

ここで、Rangeリクエスト対応処理のフローチャートを図４に示す。
Rangeリクエスト対応処理がスタートされると、ステップＳ３０にてＨＴＴＰリクエストのリクエストヘッダよりコンテンツのファイルタイプを示す拡張子が取得される。次いで、ステップＳ３１にてリクエストヘッダから取得された拡張子がRangeリクエスト対象処理外定義ファイル中で設定されている拡張子と一致するか否かが判断される。Rangeリクエスト対象処理外定義ファイルの一例が図５に示されており、レンジリクエスト対応処理対象外のファイルタイプを示す拡張子が設定されている。ステップＳ３１にてリクエストヘッダから取得された拡張子がRangeリクエスト対象処理外定義ファイル中で設定されている拡張子と一致すると判断された場合は、リクエストされているコンテンツのファイルタイプは、レンジリクエスト対応処理対象外のファイルタイプとなる。そこで、ステップＳ３５に分岐してリクエストヘッダを編集することなく、そのままアプリケーションサーバ１３ａ〜１３ｃへ向けてウェブコンテンツ変換編集システム１２から送信される。この場合、レンジリクエストとされていてもそのままアプリケーションサーバ１３ａ〜１３ｃに、そのＨＴＴＰリクエストが送信される。

また、ステップＳ３１にてリクエストヘッダから取得された拡張子がRangeリクエスト対象処理外定義ファイル中で設定されている拡張子と一致しないと判断された場合は、リクエストされているコンテンツのファイルタイプは、レンジリクエスト対応処理が行われるファイルタイプとなる。そこで、ステップＳ３２に進んで、ＨＴＴＰリクエストのリクエストヘッダにレンジ（Range）が指定されているレンジリクエストとされているか否かが判断される。ここで、ＨＴＴＰリクエストがレンジリクエストと判断された場合は、ステップＳ３４へ分岐してリクエストヘッダからレンジ（Range）部分を削除して、アプリケーションサーバ１３ａ〜１３ｃへ向けて編集したＨＴＴＰリクエストを送信する。

これにより、コンテンツ提供元であるアプリケーションサーバ１３ａ〜１３ｃからは全コンテンツのＨＴＴＰレスポンスが送信され、ウェブコンテンツ変換編集システム１２は、ＨＴＴＰレスポンスとして全コンテンツを受け取るようになる。そして、ウェブコンテンツ変換編集システム１２は、受け取った全コンテンツの内のレンジリクエストにおいて指定された範囲の部分コンテンツを移動局１０へ送るようにする。また、ステップＳ３２にてリクエストヘッダにレンジ（Range）が指定されておらずレンジリクエストでないと判断された場合は、ステップＳ３３に進んでリクエストヘッダを編集することなく、そのままアプリケーションサーバ１３ａ〜１３ｃへ向けてＨＴＴＰリクエストを送信する。

このように、レンジリクエストのリクエストヘッダからレンジ（Range）部分を削除しないファイルタイプをRangeリクエスト対象処理外定義ファイルにて設定して、該当するファイルタイプのレンジリクエストを受け取ったときには、レンジリクエストヘッダからレンジ（Range）部分を削除することなくアプリケーションサーバ１３ａ〜１３ｃ側へ送るようにしている。これにより、通信効率の低下を防止することができる。なお、Rangeリクエスト対象処理外定義ファイルで設定しておくRangeリクエスト対応処理の対象外のファイルタイプとしては、図５に示すように移動局１０側とアプリケーションサーバ１３ａ〜１３ｃのコンテンツ提供側において、コンテンツのサイズ等の物理的実体が異なるおそれの少ないjpegやpngのファイルタイプとされる。

次に、ウェブコンテンツ変換編集システム１２が実行するウェブコンテンツ変換編集処理の一つにＨＴＴＰエンティティボディの圧縮処理がある。
ＨＴＴＰエンティティボディの圧縮処理は、移動局１０側とコンテンツを提供するアプリケーションサーバ１３ａ〜１３ｃ側の間で転送されるデータ量を減らし、無線通信路１１のリソースを有効に利用するために行われる。ウェブコンテンツ変換編集システム１２は、アプリケーションサーバ１３ａ〜１３ｃ側から受信したＨＴＴＰレスポンスにおいて、移動局１０からの要求に応じエンティティボディ（コンテンツ）を圧縮して移動局１０側に送信する。なお、アプリケーションサーバ１３ａ〜１３ｃから圧縮したエンティティボディを送ると、その圧縮タイプを移動局１０において受け入れられない場合があることから、ウェブコンテンツ変換編集システム１２において圧縮されているエンティティボディを解凍してから圧縮することになり、処理効率が低下する。これを防止するために、ウェブコンテンツ変換編集システム１２はアプリケーションサーバ１３ａ〜１３ｃ側から非圧縮のエンティティボディを、ＨＴＴＰレスポンスとして受け取るようにする。そして、ウェブコンテンツ変換編集システム１２において、コンテンツの変換及び編集処理を行った後、圧縮処理を行うようにする。

ところで、移動局１０はＨＴＴＰリクエストにおけるアクセプト・エンコーディング（Accept-Encoding）ヘッダにより、受け入れられる圧縮タイプを指定するようにしている。このアクセプト・エンコーディングヘッダにおいて、指定している圧縮タイプの値がＮＵＬＬ値（または、「identify」）とされている場合は、移動局１０においてコンテンツ圧縮が許容されていない場合である。また、圧縮タイプのいずれかが指定されている場合、および、アクセプト・エンコーディングヘッダが指定されていない場合は、移動局１０においてコンテンツ圧縮が許容されている場合であり、この場合に限ってウェブコンテンツ変換編集システム１２において、移動局１０において受け入れられる圧縮タイプのエンティティボディの圧縮を行うようにしている。

この場合、コンテンツ提供側においてはコンテンツを圧縮して送信させないことを通知するため、ウェブコンテンツ変換編集システム１２は、移動局１０からのＨＴＴＰリクエストにＮＵＬＬ値（または、「identify」）を設定したアクセプト・エンコーディングヘッダを追加し、コンテンツ提供側であるアプリケーションサーバ１３ａ〜１３ｃに送信する。これにより、アプリケーションサーバ１３ａ〜１３ｃ側からのＨＴＴＰレスポンスは非圧縮となる。なお、移動局１０からのＨＴＴＰリクエストにおけるアクセプト・エンコーディングヘッダにおいて、指定している圧縮タイプの値がＮＵＬＬ値（または、「identify」）とされている場合は、前述したようにコンテンツ圧縮が非許容とされているため、ウェブコンテンツ変換編集システム１２は、コンテンツ圧縮を行わない。また、ウェブコンテンツ変換編集システム１２が行う圧縮タイプとしては、一般にDEFLATE形式またはGZIP形式が用いられる。

ここで、ウェブコンテンツ変換編集システム１２が実行するＨＴＴＰエンティティボディ圧縮処理１のフローチャートを図６に示す。このＨＴＴＰエンティティボディ圧縮処理１では、移動局１０からのＨＴＴＰリクエストのヘッダの編集が行われる。
ＨＴＴＰエンティティボディ圧縮処理１がスタートすると、ステップＳ４０にて移動局１０からのＨＴＴＰリクエストのリクエストヘッダにおける圧縮タイプを指定するAccept-Encodingが取得される。次いで、取得したAccept-Encodingにおいて圧縮タイプが指定されているか否かが判断される。ここで、Accept-Encodingにおいて圧縮タイプが指定されていないと判断された場合は、移動局１０においてコンテンツ圧縮が許容されている場合であり、ステップＳ４４に分岐する。ステップＳ４４では、リクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）を設定して、コンテンツ提供側であるアプリケーションサーバ１３ａ〜１３ｃに送信する。これにより、アプリケーションサーバ１３ａ〜１３ｃ側からのＨＴＴＰレスポンスは非圧縮となる。

また、ステップＳ４１にてAccept-Encodingにより圧縮タイプが指定されていると判断された場合は、ステップＳ４２に進みリクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）が設定されているか否かが判断される。ここで、Accept-EncodingにＮＵＬＬ値（または、「identify」）が設定されていると判断された場合は、移動局１０においてコンテンツ圧縮が許容されていない場合であり、ステップＳ４５に分岐する。ステップＳ４５ではリクエストヘッダのAccept-Encodingを編集することなく、コンテンツ提供側であるアプリケーションサーバ１３ａ〜１３ｃに送信する。これにより、アプリケーションサーバ１３ａ〜１３ｃ側からのＨＴＴＰレスポンスは非圧縮となる。

また、ステップＳ４２にてAccept-EncodingにＮＵＬＬ値（または、「identify」）ではない圧縮タイプが設定されていると判断された場合は、移動局１０において設定された圧縮タイプのコンテンツ圧縮が許容されている場合であり、ステップＳ４３に進む。ステップＳ４３では、リクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）を設定して、コンテンツ提供側であるアプリケーションサーバ１３ａ〜１３ｃに送信する。これにより、アプリケーションサーバ１３ａ〜１３ｃ側からのＨＴＴＰレスポンスは非圧縮となる。このようにして、コンテンツ提供側であるアプリケーションサーバ１３ａ〜１３ｃからのＨＴＴＰレスポンスは非圧縮とされてウェブコンテンツ変換編集システム１２が受信するようになる。そして、ウェブコンテンツ変換編集システム１２は、移動局１０からのＨＴＴＰリクエストにおけるリクエストヘッダのAccept-Encodingの指定に応じた圧縮タイプでエンティティボディを圧縮したＨＴＴＰレスポンスを移動局に送信する。

ところで、圧縮するか否かをコンテンツタイプおよびエンティティボディのバイト長が、ページサイズチェック定義ファイルで設定されているコンテンツタイプおよび設定されているサイズ長を超える場合に圧縮するようにしてもよい。この場合、圧縮対象となるコンテンツタイプおよびサイズ長を定義するページサイズチェック定義ファイルは変更可能とされている。さらにまた、ウェブコンテンツ変換編集システム１２は、エンティティボディの圧縮を行ったＨＴＴＰレスポンスにコンテンツ・エンコーディング（Content-Encoding）ヘッダを追加することにより、圧縮タイプを指定して移動局１０に送信するようにしている。このコンテンツ・エンコーディングに設定する値は、例えば「DEFLATE」または「GZIP」とされる。なお、画像ファイルは通常圧縮されているため、圧縮対象のコンテンツタイプから除外されている。

ここで、ウェブコンテンツ変換編集システム１２が実行するＨＴＴＰエンティティボディ圧縮処理２のフローチャートを図７に示す。このＨＴＴＰエンティティボディ圧縮処理２では、取得したＨＴＴＰレスポンスのエンティティボディの圧縮処理が行われる。
ＨＴＴＰエンティティボディ圧縮処理２がスタートすると、ステップＳ５０にてコンテンツ提供側であるアプリケーションサーバ１３ａ〜１３ｃからのＨＴＴＰレスポンスのレスポンスヘッダからコンテンツタイプ（Content-Type）を取得する。次いで、ステップＳ５１にてレスポンスヘッダから取得されたコンテンツタイプと、ページサイズチェック定義ファイル中で設定されているコンテンツタイプとを対比してコンテンツタイプが一致するか否かが判断される。ここで、一致すると判断された場合はステップＳ５３に分岐してレスポンスヘッダより「１２３６」等のコンテンツのサイズ（Content-Length）が取得される。

次いで、ページサイズチェック定義ファイル中で設定されている当該コンテンツタイプのサイズ以上か否かが判断される。ここで、ページサイズチェック定義ファイル中で設定されている当該コンテンツタイプのサイズより小さいと判断された場合は、ＨＴＴＰレスポンスにおけるコンテンツのサイズが移動局１０の仕様に合ったサイズとされていることからステップＳ５５に進み、取得されたＨＴＴＰレスポンスのエンティティボディが圧縮されることなくそのまま移動局１０へ送信される。また、ページサイズチェック定義ファイル中で設定されている当該コンテンツタイプのサイズ以上と判断された場合は、ＨＴＴＰレスポンスにおけるコンテンツのサイズが移動局１０の仕様より大きすぎることから、ステップＳ５６に進みＨＴＴＰレスポンスのエンティティボディの圧縮が行われる。この場合、ＨＴＴＰレスポンスのエンティティボディを例えばDEFLATE形式あるいはGZIP形式で圧縮を行い、その圧縮タイプの値をコンテンツ・エンコーディング（Content-Encoding）に設定して移動局１０に送信する。これにより、ＨＴＴＰレスポンスにおけるコンテンツのサイズが移動局１０の仕様を超える場合でも、圧縮することによりコンテンツサイズの条件をクリアして移動局１０はコンテンツを取得することができるようになる。

なお、レンジリクエストであって、かつ、コンテンツの圧縮が指定されている場合は、ウェブコンテンツ変換編集システム１２は、非圧縮の全コンテンツを要求するＨＴＴＰリクエストのリクエストヘッダに編集してコンテンツ提供元であるアプリケーションサーバ１３ａ〜１３ｃに送信する。これにより、アプリケーションサーバ１３ａ〜１３ｃからのＨＴＴＰレスポンスは非圧縮の全コンテンツとなる。そこで、ウェブコンテンツ変換編集システム１２は、指定された範囲のコンテンツに指定されている圧縮タイプの圧縮処理を施して移動局１０へ送信するようにしている。
以上説明したように本発明は、移動局から圧縮されたコンテンツを要求された際には、コンテンツ提供元からは非圧縮のコンテンツを取得し、指定された圧縮タイプに圧縮して送るようにしている。これにより、コンテンツ提供元から取得したコンテンツを解凍した後に、さらに圧縮する処理を行う必要をなくすことができ、処理効率が低下することを防止することができる。また、移動局の仕様上の制約等を極力吸収することができ、移動局におけるウェブ通信におけるユーザビリティを向上することができるようになる。

本発明においては、取得したコンテンツタイプやサイズが設定外とされている場合は、コンテンツに替えてその旨を示す情報を移動局へ送るようにしてもよい。このようにすると、移動局の制約から取得できないコンテンツを取得しないと共にそのことをユーザに知らせることができる。この場合、取得できないコンテンツは移動局へ送られないことから、限られた無線リソースを無駄に使用することを防止することができる。
また、移動局からコンテンツの一部を要求された際には、コンテンツ提供元から全コンテンツを取得して、指定された一部のコンテンツを移動局へ送るようにしてもよい。このようにすると、データ矛盾を生じることなく移動局が一部のコンテンツを取得することができるようになる。

本発明の実施の形態のウェブコンテンツ変換編集システムを備えるネットワークの概略構成を示す図である。本発明の実施の形態のウェブコンテンツ変換編集システムで実行するページサイズチェック処理のフローチャートである。本発明の実施の形態のウェブコンテンツ変換編集システムで設定されているページサイズチェック定義ファイルである。本発明の実施の形態のウェブコンテンツ変換編集システムで実行するRangeリクエスト対応処理のフローチャートである。本発明の実施の形態のウェブコンテンツ変換編集システムで設定されているRangeリクエスト対応処理対象外定義ファイルである。本発明の実施の形態のウェブコンテンツ変換編集システムで実行するＨＴＴＰエンティティボディ圧縮処理１のフローチャートである。本発明の実施の形態のウェブコンテンツ変換編集システムで実行するＨＴＴＰエンティティボディ圧縮処理２のフローチャートである。

符号の説明

１０移動局、１１無線通信路、１２ウェブコンテンツ変換編集システム、１３ａアプリケーションサーバ

Claims

移動局とコンテンツ提供元との間で送受信されるメッセージの変換編集を行うウェブコンテンツ変換編集システムであって、
前記移動局からのコンテンツを要求する要求メッセージを処理して前記コンテンツ提供元に送信する第１制御手段と、
前記要求メッセージに対応して前記コンテンツ提供元から取得した応答メッセージを処理して前記移動局へ送信する第２制御手段とを備え、
前記第１制御手段は、前記移動局から圧縮されたコンテンツを要求する要求メッセージを受け取った際に、前記要求メッセージのリクエストヘッダにおいてコンテンツの圧縮タイプのいずれかが指定されている場合、あるいは、前記リクエストヘッダにおいてコンテンツの圧縮タイプが指定されていない場合には、当該リクエストヘッダに、前記コンテンツ提供元からコンテンツを圧縮して送信させないことを通知するための値を設定して前記コンテンツ提供元に送信するようにしたことを特徴とするウェブコンテンツ変換編集システム。
前記第２制御手段は、前記コンテンツ提供元から非圧縮とされているコンテンツを取得し、前記リクエストヘッダにおいて圧縮タイプのいずれかが指定されている場合は、前記非圧縮とされているコンテンツを前記リクエストヘッダにおいて指定された圧縮タイプになるよう圧縮処理して前記移動局へ送信し、前記リクエストヘッダにおいてコンテンツの圧縮タイプが指定されていない場合には、前記非圧縮とされているコンテンツを所定の圧縮タイプになるよう圧縮処理して前記移動局へ送信するようにしたことを特徴とする請求項１記載のウェブコンテンツ変換編集システム。
前記移動局からのコンテンツを取得する要求メッセージの前記リクエストヘッダにおいて、受け入れられる圧縮タイプ情報が指定されていた場合は、前記第２制御手段は、前記移動局が受け入れることができるコンテンツサイズが少なくとも設定されている定義ファイルに設定されているコンテンツサイズと、前記第１制御手段により編集された要求メッセージに対応して前記コンテンツ提供元から取得した非圧縮のコンテンツのコンテンツサイズとを対比して、取得した当該コンテンツのコンテンツサイズが前記定義ファイルに設定されているコンテンツサイズ以上とされている場合に、前記取得した非圧縮のコンテンツを指定された圧縮タイプになるよう圧縮処理して前記移動局へ送るようにしたことを特徴とする請求項１記載のウェブコンテンツ変換編集システム。