JP2009157648A - 通信端末、通信方法および通信プログラム - Google Patents

Abstract

【課題】携帯端末等ハードウェア資源の乏しい通信端末においてウィジェットを稼動させる場合の通信トラフィックの増大を抑制する。
【解決手段】処理内容を記述したスクリプトを格納するスクリプト格納部と、スクリプト格納部に格納されたスクリプトの記述に従ってリクエストを生成するリクエスト生成部と、リクエスト生成部が生成したリクエストをバッファリングするリクエストバッファ部と、リクエストバッファ部にバッファリングされたリクエストを所定の送信タイミングで読み出し、読み出したリクエストを送信するリクエスト送信部と、リクエスト送信部が送信したリクエストに応答する応答データを受信する応答データ受信部と、応答データ受信部が受信した応答データをスクリプトの記述に従って処理する応答データ処理部と、を備える通信端末を提供する。
【選択図】図２

Description

本発明は、通信端末、通信方法および通信プログラムに関する。本発明は、特に、ウィジェットに代表される、スクリプトに基づいてたとえばウェブサーバにリクエストを発行して、当該リクエストに対するレスポンスを表示等処理する小規模アプリケーションソフトウェアに適用して効果的な通信端末、通信方法および通信プログラムに関する。

従来、ウィジェットに代表される小規模アプリケーションプログラムが知られている。ウィジェットは、スクリプトに基づき、たとえばウェブサーバにリクエストを発行して、当該リクエストに対する応答の結果送信されてきたデータをたとえば表示等処理する。処理結果は表示部に設けた小規模な窓に表示する。

たとえば、特許文献１は、相異なる通信プロトコルを有する複数のネットワークを単一の統一フレームワークに統合して、ユーザアプリケーションがさまざまなネットワークデバイスを発見および利用することを可能にするアクティブコンフィグレーションフレームワークシステムを開示する。当該フレームワークシステムは、サービスとサービスユーザとを相互に接続して、プラグアンドプレイ（ＰｎＰ）ブローカを用いたネットワーキングサービスの発見および利用を提供する。サービスユーザは、サービスを提供するデバイスにより使用される通信プロトコルとは独立に、ＰｎＰブローカのインタフェースを通じてサービスと通信する。
特開２００１−２９０７２４号公報

ウィジェットは各々独立にウェブサーバに接続される。よって多数のウィジェットを稼動させた場合、ウェブサーバに対しランダムにリクエストが発行され、ウィジェットを稼動する通信端末における通信トラフィックが増大する。特に、通信端末が携帯端末である場合には、ハードウェア資源の乏しさに起因して、リクエスト発行に伴う処理負担が増大する場合がある。処理負担の増大は、通信端末のパフォーマンスを低下させる要因になる可能性があり、消費電力を増加させる要因にもなる可能性がある。さらに、通信トラフィックの増大は、通信制御装置であるサーバあるいはネットワークへの負荷を増加させる要因になる可能性がある。

上記課題を解決するために、本発明の第１の形態においては、処理内容を記述したスクリプトを格納するスクリプト格納部と、スクリプト格納部に格納されたスクリプトの記述に従ってリクエストを生成するリクエスト生成部と、リクエスト生成部が生成したリクエストをバッファリングするリクエストバッファ部と、リクエストバッファ部にバッファリングされたリクエストを所定の送信タイミングで読み出し、読み出したリクエストを送信するリクエスト送信部と、リクエスト送信部が送信したリクエストに応答する応答データを受信する応答データ受信部と、応答データ受信部が受信した応答データをスクリプトの記述に従って処理する応答データ処理部と、を備える通信端末を提供する。

なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではない。また、これらの特徴群のサブコンビネーションもまた、発明となりうる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、本実施形態の通信端末１００を用いるネットワークシステム１０の概要を示す。図１に示すシステムは、通信端末１００と、ウェブアプリケーションサーバ２００と、ネットワーク４００を備える。

通信端末１００は、たとえば携帯端末であり、デスクトップ型のパーソナルコンピュータ等と比較して演算速度、メモリ容量等のハードウェア資源に乏しい。通信端末１００では、たとえばウィジェットのようなウェブアクセス等を実行する小規模アプリケーションプログラムが稼動する。

ウィジェット１２０は、スクリプトに従った処理を実行する。ウィジェット１２０が実行する処理には、ウェブアクセス等のリクエスト送信が含まれる。ウィジェット１２０は小規模アプリケーションプログラムの一種であって、実行結果を表示部１１８に生成した窓に表示する。ウィジェット１２０は、たとえばニュースサイトにアクセスして１行ニュースを取得および表示する。ウィジェット１２０は、たとえば書籍ランキングサイトにアクセスしてランキング結果を取得および表示する。

ウェブアプリケーションサーバ２００は、ウィジェット１２０がリクエストを発行して、情報等を提供するサービスサーバであってよい。ここではサービスとしてウェブアプリケーションを例示しているが、サービスはウェブアプリケーションには限られない。たとえばデータベース等を提供するサービスであってもよい。ネットワーク４００は、たとえばＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｌｏｔｏｃｏｌ）に従うプロトコルで通信環境を提供する。

図２は、通信端末１００の機能構成例を示す。通信端末１００は、スクリプト１０２を格納するスクリプト格納部１０４と、リクエスト生成部１０６と、サブバッファ部１０８と、リクエストバッファ部１１０と、リクエスト送信部１１２と、応答データ受信部１１４と、応答データ処理部１１６と、表示部１１８と、現在位置検知部１２２と、タイマ１２４とを備える。

スクリプト１０２は、ウィジェット１２０の処理内容を記述する。スクリプト１０２は、たとえばＥＣＭＡＳｃｒｉｐｔをＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）の構文に用いたテキスト文書として記述できる。スクリプト格納部１０４は、スクリプト１０２を格納する。

リクエスト生成部１０６は、スクリプト格納部１０４に格納されたスクリプト１０２の記述に従ってリクエストを生成する。リクエスト生成部１０６は、たとえばウェブサーバからウェブページを取得することを目的にＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｌｏｔｏｃｏｌ）リクエストを生成する。

サブバッファ部１０８は、スクリプト１０２ごとに設けられる。サブバッファ部１０８は、サブバッファ部１０８に対応するスクリプト１０２に従ってリクエスト生成部１０６が生成したリクエストをバッファリングする。そしてサブバッファ部１０８は、バッファリングされたリクエストを所定の転送タイミングでリクエストバッファ部１１０に転送する。また、サブバッファ部１０８は、バッファリングされている全てのリクエストを転送タイミングにおいて送信して、リクエストの送信の後に、リクエストがバッファリングされていたバッファ領域を開放する。

サブバッファ部１０８における転送タイミングは、バッファ期間の満了時またはバッファ数上限値に達した時の何れかであってよい。サブバッファ部１０８におけるバッファ期間またはバッファ数上限値は、対応するスクリプトごとに異なってよい。サブバッファ部１０８におけるバッファ期間またはバッファ数上限値は、時間帯に応じて変更できる。

サブバッファ部１０８におけるバッファ期間またはバッファ数上限値は、ネットワーク４００における通信量が平均通信量より多くなる時間帯に含まれる期間では大通信量用バッファ期間または大通信量用バッファ数上限値に設定できる。ネットワーク４００における通信量が平均通信量より少なくなる時間帯に含まれる期間では大通信量用バッファ期間より短い小通信量用バッファ期間または大通信量用バッファ数上限値より小さい小通信量用バッファ数上限値に設定されてよい。サブバッファ部１０８は、バッファリングされているリクエストのうち幾つかのリクエストが同一の送信先に送信される場合には、同一送信先の複数のリクエストを統合して、一つのリクエストとして扱ってよい。

リクエストバッファ部１１０は、リクエスト生成部１０６が生成したリクエストをバッファリングする。リクエストバッファ部１１０は、バッファリングされているリクエストのうち幾つかのリクエストが同一の送信先に送信される場合には、同一送信先の複数のリクエストを統合して、一つのリクエストとして扱ってよい。

リクエスト送信部１１２は、リクエストバッファ部１１０にバッファリングされたリクエストを所定の送信タイミングで読み出して、読み出したリクエストを送信する。リクエスト送信部１１２における送信タイミングは、リクエストバッファ部１１０のバッファ期間の満了時またはバッファ数上限値に達した時の何れかであってよい。リクエストバッファ部１１０のバッファ期間またはバッファ数上限値は、対応するスクリプトごとに異なってよい。リクエストバッファ部１１０のバッファ期間またはバッファ数上限値は、時間帯に応じて変更できる。

リクエストバッファ部１１０のバッファ期間またはバッファ数上限値は、ネットワーク４００における通信量が平均通信量より多くなる時間帯に含まれる期間では大通信量用バッファ期間または大通信量用バッファ数上限値に設定できる。ネットワーク４００における通信量が平均通信量より少なくなる時間帯に含まれる期間では大通信量用バッファ期間より短い小通信量用バッファ期間または大通信量用バッファ数上限値より小さい小通信量用バッファ数上限値に設定できる。リクエストバッファ部１１０は、バッファリングされている全てのリクエストを送信タイミングにおいて送信して、リクエストの送信の後に、リクエストがバッファリングされていたバッファ領域を開放する。

応答データ受信部１１４は、リクエスト送信部１１２が送信したリクエストに応答する応答データを受信する。応答データは、たとえばＸＭＬ文書が例示できる。応答データ処理部１１６は、応答データ受信部１１４が受信した応答データをスクリプト１０２の記述に従って処理する。

表示部１１８は、応答データ処理部１１６が処理した応答データの処理結果を表示する。たとえば処理結果をウィジェット１２０として表示できる。現在位置検知部１２２は、現在位置を検知する。現在位置検知部１２２として、たとえばＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）が例示できる。

サブバッファ部１０８またはリクエストバッファ部１１０のバッファ期間またはバッファ数上限値は、現在位置検知部１２２が検知した現在位置に応じて変更できる。たとえば現在位置検知部１２２によって現在位置が自宅であると判断できる場合には、バッファ期間またはバッファ数上限値を小さく設定して、ウィジェット１２０が頻繁に更新されるように設定してもよい。あるいは現在位置検知部１２２によって外出中であると判断できる場合には、バッファ期間またはバッファ数上限値を大きく設定して、ウィジェット１２０の更新頻度を低くしてもよい。予めスケジュールが決まっている場合、タイマ１２４によって、現在位置を検知できる。たとえば朝の出勤時間帯に電車内にいることが予定されている場合には、タイマ１２４によって現在位置を推定でき、たとえば電車内にいるときにはバッファ期間またはバッファ数上限値を小さく設定してウィジェット１２０の更新頻度を高く設定できる。

図３は、リクエスト送信の処理フロー例を示す。ウィジェット１２０がスクリプト１０２を参照してリクエストを生成する。その後サブバッファ部１０８に生成したリクエストを送信する（ステップ５０２）。サブバッファ部１０８はリクエストをバッファリングする（ステップ５０４）。転送タイミングに達したかを判断して（ステップ５０６）、未だ転送タイミングではないと判断した場合（ステップ５０６のＮｏ）、転送タイミングに達するまで待機する（ステップ５０６）。

転送タイミングに達したと判断した場合（ステップ５０６のＹｅｓ）、サブバッファ部１０８は、バッファリングしているリクエストをリクエストバッファ部１１０に送信する（ステップ５０８）。サブバッファ部１０８は、バッファリングしていたリクエストを送信した後、バッファリングしていたバッファ領域を開放する（ステップ５１０）。その後サブバッファ部１０８はアイドル状態となって、新たなリクエストの送信を待機する（ステップ５１２）。

ステップ５０８の後、リクエストバッファ部１１０は、サブバッファ部１０８から送信されたリクエストをバッファリングする（ステップ５１４）。送信タイミングに達したかを判断して（ステップ５１６）、未だ送信タイミングではないと判断した場合（ステップ５１６のＮｏ）、送信タイミングに達するまで待機する（ステップ５１６）。送信タイミングに達したと判断した場合（ステップ５１６のＹｅｓ）、リクエストバッファ部１１０は、バッファリングしているリクエストを送信する（ステップ５１８）。リクエストバッファ部１１０は、バッファリングしていたリクエストを送信した後、バッファリングしていたバッファ領域を開放する（ステップ５２０）。その後リクエストバッファ部１１０はアイドル状態となって、新たなリクエストの送信を待機する（ステップ５２２）。

図４は、応答データの処理フロー例を示す。まず、応答データ受信部１１４が応答データを受信したかを判断する（ステップ６０２）。応答データを受信した場合はステップ６０４に進み、受信しない場合はステップ６０２に戻って応答データの受信を待機する。

ステップ６０４では、応答データの受信を完了して（ステップ６０６）、応答データの基礎となったリクエストを特定する（ステップ６０６）。その後、スクリプト１０２に従って応答データを処理する（ステップ６０８）。当該処理の後、処理データを表示する（ステップ６１０）。その後ステップ６０２に戻って応答データの受信を待機する。

以上説明した実施形態によれば、ウィジェットからのリクエストをサブバッファ部１０８およびリクエストバッファ部１１０にバッファリングする。この結果、ウィジェット１２０がばらばらにリクエストを発行した場合であってもバッファリングすることによりリクエストのタイミングを合わせて一度に送信できる。このため、通信トラフィックを低減でき、また携帯端末等ハードウェア資源が制限された環境でもウィジェットを快適に使用できる。

また、ウィジェット１２０ごと（スクリプト１０２ごと）のサブバッファ部１０８を設けたから、ウィジェット１２０ごとのリクエストを一つに纏めて送信できる。複数回のリクエストによってウィジェットが正常に表示されるような場合、リクエストバッファ部１１０により表示が不完全になる事態を回避できる。

図５は、本実施形態に係る通信端末１００のハードウェア構成の一例を示す。本実施形態に係る通信端末１００は、ホスト・コントローラ１５８２により相互に接続されるＣＰＵ１５０５、ＲＡＭ１５２０、グラフィック・コントローラ１５７５、および表示装置１５８０を有するＣＰＵ周辺部を備える。また通信端末１００は、入出力コントローラ１５８４によりホスト・コントローラ１５８２に接続される通信インターフェイス１５３０、ハードディスクドライブ１５４０、およびＣＤ−ＲＯＭドライブ１５６０を有する入出力部を備える。さらに通信端末１００は、入出力コントローラ１５８４に接続されるＲＯＭ１５１０、フレキシブルディスク・ドライブ１５５０、および入出力チップ１５７０を有するレガシー入出力部を備える。

ホスト・コントローラ１５８２は、ＲＡＭ１５２０と、高転送レートでＲＡＭ１５２０をアクセスするＣＰＵ１５０５およびグラフィック・コントローラ１５７５とを接続する。ＣＰＵ１５０５は、ＲＯＭ１５１０およびＲＡＭ１５２０に格納されたプログラムに基づいて動作して、各部を制御する。グラフィック・コントローラ１５７５は、ＣＰＵ１５０５等がＲＡＭ１５２０内に設けたフレーム・バッファ上に生成する画像データを取得して、表示装置１５８０上に表示させる。これに代えて、グラフィック・コントローラ１５７５は、ＣＰＵ１５０５等が生成する画像データを格納するフレーム・バッファを、内部に含んでもよい。

入出力コントローラ１５８４は、ホスト・コントローラ１５８２と、比較的高速な入出力装置である通信インターフェイス１５３０、ハードディスクドライブ１５４０、ＣＤ−ＲＯＭドライブ１５６０を接続する。通信インターフェイス１５３０は、ネットワークを介して他の装置と通信する。ハードディスクドライブ１５４０は、通信端末１００内のＣＰＵ１５０５が使用するプログラムおよびデータを格納する。ＣＤ−ＲＯＭドライブ１５６０は、ＣＤ−ＲＯＭ１５９５からプログラムまたはデータを読み取り、ＲＡＭ１５２０を介してハードディスクドライブ１５４０に提供する。

また、入出力コントローラ１５８４には、ＲＯＭ１５１０と、フレキシブルディスク・ドライブ１５５０、および入出力チップ１５７０の比較的低速な入出力装置とが接続される。ＲＯＭ１５１０は、通信端末１００が起動時に実行するブート・プログラム、通信端末１００のハードウェアに依存するプログラム等を格納する。フレキシブルディスク・ドライブ１５５０は、フレキシブルディスク１５９０からプログラムまたはデータを読み取り、ＲＡＭ１５２０を介してハードディスクドライブ１５４０に提供する。入出力チップ１５７０は、フレキシブルディスク・ドライブ１５５０、例えばパラレル・ポート、シリアル・ポート、キーボード・ポート、マウス・ポート等を介して各種の入出力装置を接続する。

ＲＡＭ１５２０を介してハードディスクドライブ１５４０に提供される通信プログラムは、フレキシブルディスク１５９０、ＣＤ−ＲＯＭ１５９５、またはＩＣカード等の記録媒体に格納されて利用者によって提供される。通信プログラムは、記録媒体から読み出され、ＲＡＭ１５２０を介して通信端末１００内のハードディスクドライブ１５４０にインストールされ、ＣＰＵ１５０５において実行される。通信端末１００にインストールされて実行される通信プログラムは、ＣＰＵ１５０５等に働きかけて、通信端末１００を、図１から図４にかけて説明した各部として機能させる。すなわち、当該通信プログラムは、通信端末１００を、スクリプト格納部１０４、リクエスト生成部１０６、サブバッファ部１０８、リクエストバッファ部１１０、リクエスト送信部１１２、応答データ受信部１１４、応答データ処理部１１６、表示部１１８、現在位置検知部１２２およびタイマ１２４として機能させる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本実施形態の通信端末１００を用いるネットワークシステム１０の概要を示す。 通信端末１００の機能構成例を示す。 リクエスト送信の処理フロー例を示す。 応答データの処理フロー例を示す。 本実施形態に係る通信端末１００のハードウェア構成の一例を示す。

符号の説明

１０ ネットワークシステム
１００ 通信端末
１０２ スクリプト
１０４ スクリプト格納部
１０６ リクエスト生成部
１０８ サブバッファ部
１１０ リクエストバッファ部
１１２ リクエスト送信部
１１４ 応答データ受信部
１１６ 応答データ処理部
１１８ 表示部
１２０ ウィジェット
１２２ 現在位置検知部
１２４ タイマ
２００ ウェブアプリケーションサーバ
４００ ネットワーク
１５０５ ＣＰＵ
１５１０ ＲＯＭ
１５２０ ＲＡＭ
１５３０ 通信インターフェイス
１５４０ ハードディスクドライブ
１５５０ フレキシブルディスク・ドライブ
１５６０ ＣＤ−ＲＯＭドライブ
１５７０ 入出力チップ
１５７５ グラフィック・コントローラ
１５８０ 表示装置
１５８２ ホスト・コントローラ
１５８４ 入出力コントローラ
１５９０ フレキシブルディスク
１５９５ ＣＤ−ＲＯＭ

Claims (11)

1. 処理内容を記述したスクリプトを格納するスクリプト格納部と、
   前記スクリプト格納部に格納された前記スクリプトの記述に従ってリクエストを生成するリクエスト生成部と、
   前記リクエスト生成部が生成した前記リクエストをバッファリングするリクエストバッファ部と、
   前記リクエストバッファ部にバッファリングされた前記リクエストを所定の送信タイミングで読み出し、読み出した前記リクエストを送信するリクエスト送信部と、
   前記リクエスト送信部が送信した前記リクエストに応答する応答データを受信する応答データ受信部と、
   前記応答データ受信部が受信した前記応答データを前記スクリプトの記述に従って処理する応答データ処理部と、
   を備える通信端末。
2. 前記スクリプトごとのサブバッファ部をさらに備え、
   前記サブバッファ部は、前記サブバッファ部に対応するスクリプトに従って前記リクエスト生成部が生成したリクエストをバッファリングし、バッファリングされた前記リクエストを所定の転送タイミングで前記リクエストバッファ部に転送する、
   請求項１に記載の通信端末。
3. 前記リクエストバッファ部または前記サブバッファ部は、バッファリングされている全ての前記リクエストを前記送信タイミングまたは前記転送タイミングにおいて送信し、前記リクエストの送信の後に、前記リクエストがバッファリングされていたバッファ領域を開放する、
   請求項２に記載の通信端末。
4. 前記送信タイミングまたは前記転送タイミングは、バッファ期間の満了時またはバッファ数上限値に達した時の何れかである、
   請求項３に記載の通信端末。
5. 前記バッファ期間または前記バッファ数上限値は、対応するスクリプトごとに異なる、
   請求項４に記載の通信端末。
6. 前記バッファ期間または前記バッファ数上限値は、時間帯に応じて変更される、
   請求項４に記載の通信端末。
7. 前記バッファ期間または前記バッファ数上限値は、ネットワークにおける通信量が平均通信量より多くなる時間帯に含まれる期間では大通信量用バッファ期間または大通信量用バッファ数上限値に設定され、ネットワークにおける通信量が平均通信量より少なくなる時間帯に含まれる期間では前記大通信量用バッファ期間より短い小通信量用バッファ期間または前記大通信量用バッファ数上限値より小さい小通信量用バッファ数上限値前記に設定される、
   請求項６に記載の通信端末。
8. 前記通信端末は、携帯通信端末であり、
   現在位置を検知する現在位置検知部をさらに備え、
   前記バッファ期間または前記バッファ数上限値は、前記現在位置検知部が検知した現在位置に応じて変更される、
   請求項４に記載の通信端末。
9. 前記リクエストバッファ部または前記サブバッファ部は、バッファリングされている前記リクエストのうち幾つかのリクエストが同一の送信先に送信される場合には、同一送信先の複数のリクエストを統合して、一つのリクエストとして扱う、
   請求項２に記載の通信端末。
10. 処理内容を記述したスクリプトを格納するスクリプト格納段階と、
    前記スクリプト格納段階において格納された前記スクリプトの記述に従ってリクエストを生成するリクエスト生成段階と、
    前記リクエスト生成段階で生成した前記リクエストをバッファリングするリクエストバッファ段階と、
    前記リクエストバッファ段階でバッファリングされた前記リクエストを所定の送信タイミングで読み出し、読み出した前記リクエストを送信するリクエスト送信段階と、
    前記リクエスト送信段階で送信した前記リクエストに応答する応答データを受信する応答データ受信段階と、
    前記応答データ受信段階で受信した前記応答データを前記スクリプトの記述に従って処理する応答データ処理段階と、
    を備える通信方法。
11. 通信端末で利用できる通信プログラムであって、前記通信端末を、
    処理内容を記述したスクリプトを格納するスクリプト格納部、
    前記スクリプト格納部に格納された前記スクリプトの記述に従ってリクエストを生成するリクエスト生成部、
    前記リクエスト生成部が生成した前記リクエストをバッファリングするリクエストバッファ部、
    前記リクエストバッファ部にバッファリングされた前記リクエストを所定の送信タイミングで読み出し、読み出した前記リクエストを送信するリクエスト送信部、
    前記リクエスト送信部が送信した前記リクエストに応答する応答データを受信する応答データ受信部、
    前記応答データ受信部が受信した前記応答データを前記スクリプトの記述に従って処理する応答データ処理部、
    として機能させる通信プログラム。

Images