JPWO2015004775A1 - 通信装置、応答データ生成方法、および、プログラム - Google Patents

Abstract

通信インタフェース（111）は、端末（200）からの要求を受信し、端末（200）への応答を送信する。第１のリソースデータ格納部（116）は、端末（200）に正規表示する画面を構成するための各リソースデータであり、通常のデータサイズの通常リソースデータを格納する。第２のリソースデータ格納部（117）は、端末（200）に暫定表示する画面を構成するための各リソースデータであり、通常リソースデータよりもデータサイズの小さい節減リソースデータを格納する。要求起因判定部（113）は、端末（200）から表示する画面が要求された際に、この要求の起因を判定する。応答データ生成部（114）は、要求起因判定部（113）による判定結果に基づいて、通常リソースデータまたは節減リソースデータを含んだ応答データを生成する。

Description

この発明は、電気機器をネットワークに接続させ、ネットワーク上の端末から電気機器へのアクセスを制御する通信装置、応答データ生成方法、および、プログラムに関する。

機器に通信アダプタなどを取り付けて、ＰＣ（Personal Computer）などの端末から遠隔操作を可能にする技術が知られている。例えば、特許文献１には、電気機器（一例として、住宅設備機器、白物家電機器、ヘルスケア機器、センサ機器など）に通信アダプタを接続し、ネットワークを介して、端末のＷｅｂブラウザから、電気機器を遠隔操作したり、電気機器の状態を取得する技術について記載されている。一般に、通信アダプタなどでは、搭載するプロセッサやメモリを安価に抑えることが求められるため、通信の速度性能が低くなりがちである。そのため、ある程度データ量の多いＷｅｂページを表示する際には、端末が組込み装置に画面を要求してからＷｅｂブラウザに表示されるまでに長時間を要してしまい、ユーザにストレスを感じさせる場合もあった。なお、画面表示の体感速度を向上させるために、例えば、特許文献２には、参照される画面を先読みにより予め取得しておく技術について記載されている。

特開２０１１−８５３７０号公報 特開２０００−５７０７８号公報

上記の特許文献２の技術は、文章の多いＷｅｂページを閲覧するなど、同じ画面を長時間表示している状態を利用して、先読みを有効に行うことができる。しかしながら、Ｗｅｂブラウザを使用して電気機器の操作や設定などを行う場合では、Ｗｅｂページの表示切り替えが頻繁に生じるなど、先読みが機能し難いため、応答性が向上しないという問題があった。

この発明は、上記実状に鑑みてなされたもので、電気機器の操作や設定などを行う場合でも、適切に応答性を向上させることのできる通信装置、応答データ生成方法、および、プログラムを提供することを目的とする。

上記目的を達成するために、本発明に係る通信装置は、
電気機器をネットワークに接続させ、当該ネットワーク上の端末から当該電気機器へのアクセスを制御する通信装置であって、
前記端末からの要求を受信し、前記端末への応答を送信する通信インタフェースと、
前記端末に正規表示する画面を構成するための各リソースデータであり、通常のデータサイズの通常リソースデータを格納する第１のリソースデータ格納部と、
前記端末に暫定表示する画面を構成するための各リソースデータであり、前記通常リソースデータよりもデータサイズの小さい節減リソースデータを格納する第２のリソースデータ格納部と、
前記端末から表示する画面が要求された際に、当該要求の起因を判定する要求起因判定部と、
前記要求起因判定部による判定結果に基づいて、前記通常リソースデータまたは前記節減リソースデータを含んだ応答データを生成する応答データ生成部と、
を備える。

本発明によれば、電気機器の操作や設定などを行う場合でも、適切に応答性を向上させることができる。

本発明の実施形態に係る通信装置を含む遠隔操作システムの構成を示すブロック図である。 先読みを起因とする端末と通信装置との間の通信手順を示すシーケンス図である。 ユーザの操作を起因とする端末と通信装置との間の通信手順を示すシーケンス図である。 通信装置における受信処理の一例を示すフローチャートである。 画面取得要求メッセージの一例を示す模式図である。 通信装置における応答処理の一例を示すフローチャートである。 端末に正規表示される画面の一例を示す模式図である。 リソースデータの具体的な比較例を示す模式図である。 端末に暫定表示される画面の一例を示す模式図である。 端末における取得処理の一例を示すフローチャートである。 通信装置における操作応答処理の一例を示すフローチャートである。 操作要求メッセージの一例を示す模式図である。 操作要求メッセージに対する応答メッセージの一例を示す模式図である。

以下に本発明の実施形態を説明する。以下では、理解を容易にするため、通信装置に本発明が適用される実施形態を説明するが、各種のコンピュータ、ＰＤＡ、携帯電話などの情報処理装置においても同様に本発明を適用することができる。すなわち、以下に説明する実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素または全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。

図１は、本発明の実施形態に係る通信装置１００を含む遠隔操作システムの一例を示すブロック図である。この遠隔操作システムでは、ネットワーク３００（一例として、インターネットやローカルエリアネットワークなど）を介して、通信装置１００と端末２００とが通信可能となっている。ユーザは端末２００を操作し、通信装置１００を通じて、図示せぬ電気機器（一例として、住宅設備機器、白物家電機器、ヘルスケア機器、センサ機器など）を監視したり、当該電気機器の設定を変更したりする。
つまり、通信装置１００は、電気機器をネットワーク３００に接続させ、端末２００から電気機器へのアクセスを制御するための装置であり、図示するように、通信部１１０と、制御部１２０とを備えている。

通信部１１０は、ネットワーク３００を介して、端末２００と通信を行う。より詳細に通信部１１０は、通信インタフェース１１１と、要求メッセージ解釈部１１２と、要求起因判定部１１３と、応答データ生成部１１４と、送信履歴記憶部１１５と、第１のリリースデータ格納部１１６と、第２のリリースデータ格納部１１７とから構成される。

通信インタフェース１１１は、例えば、有線ＬＡＮ（Local Area Network）や無線ＬＡＮなどに対応しており、ネットワーク３００を介した端末２００との間で、ＨＴＴＰ（Hypertext Transfer Protocol）通信を行う。

要求メッセージ解釈部１１２は、通信インタフェース１１１にて受信したＨＴＴＰ要求などの解釈を行う。例えば、要求メッセージ解釈部１１２は、受信したＨＴＴＰ要求が、画面の取得を要求するものであるか、または、機器の操作を要求するものであるかなどを解釈する。

要求起因判定部１１３は、ＨＴＴＰ要求が送信された起因を判定する。例えば、要求起因判定部１１３は、受信したＨＴＴＰ要求が画面の取得を要求するものであった場合に、その要求が端末２００のユーザ操作により送信されたものか、または、先読み機能により送信されたものかなどを判定する。

応答データ生成部１１４は、ＨＴＴＰ要求に応じた応答データを生成する。例えば、応答データ生成部１１４は、要求メッセージ解釈部１１２と要求起因判定部１１３の判定に従い、必要に応じて制御部１２０、送信履歴記憶部１１５、第１のリソースデータ格納部１１６、および、第２のリソースデータ格納部１１７を参照して応答データを生成する。
なお、要求メッセージ解釈部１１２、要求起因判定部１１３、および、応答データ生成部１１４は、一例として、ＲＯＭ（Read Only Memory）などに格納されたプログラム（より詳細には、後述する受信処理などの制御プログラム）をＲＡＭ（Random Access Memory）に読み出して、ＣＰＵ（Central Processing Unit）が実行することにより実現される。

送信履歴記憶部１１５は、過去に送信済みのリソースデータについて、通信相手ごとに記憶する。例えば、送信履歴記憶部１１５は、端末２００に送信したリソースデータ（詳細には、後述する通常リソースデータ）の送信履歴を記憶する。

第１のリソースデータ格納部１１６は、端末２００に正規表示する画面（最終的に表示される画面）を構成するための各リソースデータ（例えば、画像など）であり、通常のデータサイズの通常リソースデータを格納する。

第２のリソースデータ格納部１１７は、端末２００に暫定表示する画面（迅速に表示される画面）を構成するための各リソースデータであり、第１のリソースデータ格納部１１６における各通常リソースデータに対応して、よりデータサイズが小さい節減リソースデータを格納する。
なお、本実施形態では、通常リソースデータまたは節減リソースデータをファイルとして扱う場合、通常リソースファイルまたは節減リソースファイルと呼ぶことがある。

制御部１２０は、監視や設定などを行うための電気機器を制御する。例えば、通信装置１００が空調機に取り付けられている場合、制御部１２０は、その空調機の状態（運転状態や室温など）を取得したり、その空調機に操作コマンド（冷房オンやタイマ登録など）を供給したりする。

一方の端末２００は、例えば、ＰＣ（Personal Computer）やスマートフォンなどからなり、ユーザに操作される。
端末２００は、図示するように、通信インタフェース２１０と、入力部２２０と、表示部２３０と、画面データ記憶部２４０と、制御部２５０とを備え、例えば、ＷｅｂクライアントとなるＷｅｂブラウザがインストールされており、ＨＴＭＬ（Hyper Text Markup Language）ファイル２６０などに基づいたＷｅｂ画面が表示可能となっている。

通信インタフェース２１０は、例えば、有線ＬＡＮや無線ＬＡＮなどに対応しており、ネットワーク３００を介した通信装置１００との間で、ＨＴＴＰ通信を行う。

入力部２２０は、例えば、マウスやキーボード、若しくは、タッチパネルなどからなり、ユーザの操作を受け付ける。

表示部２３０は、例えば、液晶ディスプレイなどからなり、制御部２５０にて処理されたＨＴＭＬファイル２６０などに基づいたＷｅｂ画面などを表示する。

画面データ記憶部２４０は、過去に取得した画面や先読み処理によって取得した画面などを記憶する。

制御部２５０は、例えば、ＲＯＭ、ＲＡＭ、および、ＣＰＵなどを備えており、端末２００全体を制御する。
一例として、制御部２５０は、通信装置１００から送られたＨＴＭＬファイル２６０などをＲＡＭに格納し、それに基づいて、表示部２３０にＷｅｂ画面を表示させる。

ＨＴＭＬファイル２６０は、通信装置１００に対して要求して得られた画面の基となるデータであり、先読み処理記述部２６１や、更新処理記述部２６２が含まれている。
先読み処理記述部２６１は、例えば、JavaScript（登録商標）などのＷｅｂ画面に組み込み可能なプログラミング言語による記述部であり、先読み機能を実現させる。
更新処理記述部２６２も、例えば、JavaScript（登録商標）などのプログラミング言語による記述部であり、通常リソースデータを取得して画面更新を実現させる。具体的に更新処理記述部２６２には、正規表示するＷｅｂ画面（最終的に表示するＷｅｂ画面）を構成する通常リソースデータのＵＲＬ（Uniform Resource Locator）などを含んでおり、後述するように、端末２００におけるユーザの操作間隔が一定時間以上開いたときに、通信装置１００に対して対象となる通常リソースデータを要求するなどの処理が記述されている。

このような構成の通信装置１００、および、端末２００の動作概要について、図２，図３を参照して説明する。図２は、先読みを起因とする端末２００と通信装置１００との間の通信手順を示すシーケンス図である。つまり、先読み機能により、端末２００が通信装置１００からＷｅｂ画面を取得するまでの処理を表している。また、図３は、ユーザの操作を起因とする端末２００と通信装置１００との間の通信手順を示すシーケンス図である。つまり、端末２００のユーザ操作により、端末２００が通信装置１００からＷｅｂ画面を取得するまでの処理を表している。

最初に、図２のシーケンス図に沿って、先読みを起因とするＷｅｂ画面の取得動作を説明する。
図示するように、端末２００は、まず、取得したいＷｅｂ画面のＨＴＭＬファイルの取得要求を通信装置１００に送信する（Ｓｑ１０）。なお、このとき要求するＨＴＭＬファイル名は、後述するように、拡張子の前に特定の文字列が含まれている。
通信装置１００は、この要求に応じたＨＴＭＬファイルを返信する（Ｓｑ２０）。このとき、後述するように、ＨＴＭＬファイル（拡張子の前に特定の文字列が含まれているＨＴＭＬファイル）から参照される画像などのリソースファイルは、通常リソースファイルとなる。

端末２００は、受信したＨＴＭＬファイルを解析し（Ｓｑ３０）、リソースファイルが参照されている場合に、そのリソースファイル（通常リソースファイル）の取得要求を通信装置１００に送信する（Ｓｑ４０）。
通信装置１００は、この要求に応じたリソースファイル（通常リソースファイル）を返信する（Ｓｑ５０）。なお、ＨＴＭＬファイルからリソースファイルが複数参照されている場合には、これらＳｑ４０，Ｓｑ５０のシーケンスが複数回繰り返される。
そして、端末２００は、受信したリソースファイル（通常リソースファイル）を、画面データ記憶部２４０に記憶する（Ｓｑ６０）。

続いて、図３のシーケンス図に沿って、ユーザの操作を起因とするＷｅｂ画面の取得動作を説明する。
図示するように、端末２００は、まず、取得したいＷｅｂ画面のＨＴＭＬファイルの取得要求を通信装置１００に送信する（Ｓｑ１１）。なお、このとき要求するＨＴＭＬファイル名は、上記図２のＳｑ１０とは異なり、拡張子の前に特定の文字列が含まれていない。
通信装置１００は、この要求に応じたＨＴＭＬファイルを返信する（Ｓｑ２１）。このとき、後述するように、ＨＴＭＬファイル（拡張子の前に特定の文字列が含まれていないＨＴＭＬファイル）から参照される画像などのリソースファイルは、節減リソースファイルとなる。なお後述するように、対象の通常リソースファイルが送信済みであれば、参照されるリソースファイルは、通常リソースファイルとなる。

端末２００は、受信したＨＴＭＬファイルを解析し（Ｓｑ３０）、リソースファイルが参照されている場合に、そのリソースファイル（節減リソースファイル）の取得要求を通信装置１００に送信する（Ｓｑ４１）。
通信装置１００は、この要求に応じたリソースファイル（節減リソースファイル）を返信する（Ｓｑ５１）。なお、ＨＴＭＬファイルからリソースファイルが複数参照されている場合には、これらＳｑ４１，Ｓｑ５１のシーケンスが複数回繰り返される。
そして、端末２００は、受信したリソースファイル（節減リソースファイル）によるＷｅｂ画面を表示する（Ｓｑ６０）。

このような節減リソースファイルは、暫定的な表示データであるため、端末２００は、節減リソースファイルに対応する通常リソースデータの取得要求を通信装置１００に送信する（Ｓｑ４０）。なお後述するように、この要求は、端末２００におけるユーザの操作を妨げないように、ユーザの操作が途切れたタイミングで少量ずつ要求する。
通信装置１００は、この要求に応じたリソースファイル（通常リソースファイル）を返信する（Ｓｑ５０）。なお、ＨＴＭＬファイルからリソースファイルが複数参照されている場合には、これらＳｑ４０，Ｓｑ５０のシーケンスが複数回繰り返される。
そして、端末２００は、受信したリソースファイル（通常リソースファイル）を、画面データ記憶部２４０に記憶し、Ｗｅｂ画面を更新して表示する（Ｓｑ６１）。

このように、通常リソースデータの取得が全て完了すると、端末２００は、表示しているＷｅｂ画面から遷移し得る別画面を先読み処理により取得する。この処理は、図２に示したシーケンスに従う。

次に、通信装置１００、および、端末２００の動作を詳細に説明する。まず、通信装置１００の動作を、図４〜図９を参照して説明する。

最初に、図４のフローチャートに沿って、通信装置１００における受信処理を説明する。
まず、通信装置１００は、画面取得要求を受信したか否かを判別する（ステップＳ４０１）。すなわち、要求メッセージ解釈部１１２は、端末２００から受信したメッセージが画面取得要求であるか、または、操作要求であるかを判定する。なお画面取得要求は、Ｗｅｂブラウザ上に表示する画面を取得するためのメッセージであり、一例として、図５に示すように、ＨＴＴＰのＧＥＴメソッドとファイル名（ＨＴＭＬファイル名やリソースファイル名）から構成される。一方、操作要求は、制御部１２０（本実施形態では空調機コントローラ）の操作を指定するメッセージであり、詳細は後述する。

図４に戻って、通信装置１００は、画面取得要求であると判別すると（ステップＳ４０１；Ｙｅｓ）、画面取得要求に対する処理を実行する（ステップＳ４０２）。
一方、画面取得要求でないと判別した場合（ステップＳ４０１；Ｎｏ）に、通信装置１００は、操作要求に対する処理を実行する（ステップＳ４０３）。

このステップＳ４０２の画面取得要求に対する処理の一例を示したのが、図６のフローチャートである。以下、図６のフローチャートに沿って、通信装置１００における応答処理を説明する。なおこの応答処理では、具体例として、図７に示すような画面を端末２００に正規表示（最終的に表示）させることになる。
図７は、一例として、通信装置１００が空調機に取り付けられている場合において、空調機の運転状態のモニタ／操作を行う画面である。この画面において、符号６０１や符号６０２にて示される箇所は、テキスト文字（文字列データ）ではなく、画像データによって構成されている。また、符号６０３ａ〜符号６０３ｈにて示される箇所は、グループごとの空調機を表す画像データによって構成されている。同様に、符号６０４ａ〜符号６０４ｈにて示される箇所は、設定温度を表す画像データ、そして、符号６０５ａ〜符号６０５ｈにて示される箇所は、室温を表す画像データによって構成されている。
また、符号６０６にて示されるエリアには、各テキスト文字が配置され、それぞれに、遷移し得る別画面へのリンクが張られている。

図６に示すように、まず、通信装置１００は、ＨＴＭＬファイルの取得要求であるか否かを判別する（ステップＳ５０１）。
例えば、通信装置１００は、端末２００からの要求が、ＨＴＭＬファイルの取得要求であるか、または、リソースファイルの取得要求であるかを判定する。なお両者の違いは、ファイルの拡張子によって判定でき、「.html」や「.htm」であればＨＴＭＬファイルであり、それ以外であればリソースファイルである。

通信装置１００は、ＨＴＭＬファイルの取得要求でないと判別すると（ステップＳ５０１；Ｎｏ）、指定されたリソースデータを返信する（ステップＳ５０２）。
すなわち、端末２００からの要求が、リソースファイルの取得要求であるため、応答データ生成部１１４は、指定されたリソースデータを返す応答メッセージを生成する。

一方、ＨＴＭＬファイルの取得要求であると判別した場合に（ステップＳ５０１；Ｙｅｓ）、通信装置１００は、雛形となるＨＴＭＬファイルを取得する（ステップＳ５０３）。
すなわち、応答データ生成部１１４は、応答するＨＴＭＬファイルの可変部分をブランクにしたＨＴＭＬファイルを取得する。本実施形態においては、空調機の計測値など制御部１２０が管理する情報や、参照するリソースデータのファイル名などが可変部分になる。

通信装置１００は、ＨＴＭＬファイルの共通部分を生成する（ステップＳ５０４）。
すなわち、応答データ生成部１１４は、応答するＨＴＭＬファイルの共通部分を生成する。この共通部分は、ユーザ操作を起因とする画面の取得、および、先読みを起因とする画面の取得の何れに拘わらず、応答データへの設定が必要になる部分である。本実施形態においては、制御部１２０が取得した空調機の設定温度と室温の値などが共通部分になる。

通信装置１００は、先読みによる要求であるか否かを判別する（ステップＳ５０５）。すなわち、要求起因判定部１１３は、受信したメッセージが先読み処理を起因とする要求であるか、または、ユーザ操作を起因とする要求であるかを判定する。なお先読み処理は、上述した先読み処理記述部２６１のJavaScript（登録商標）にて記述されているものとする。その記述において、先読み処理で指定するファイル名には、一例として、拡張子の前に「_pl」という文字列を入れるという規則を設けておく（plは、preloadの意）。例えば、ＨＴＭＬのアンカータグにより、ユーザ操作で要求されるファイル名が「monitor.html」であれば、先読み処理で先読みするファイル名は、「monitor_pl.html」となる。

通信装置１００は、先読みによる要求であると判別すると（ステップＳ５０５；Ｙｅｓ）、参照先を通常リソースデータとしたＨＴＭＬファイルを返信する（ステップＳ５０６）。
すなわち、応答データ生成部１１４は、先読みを起因とする要求であるため、応答性が重視されないとの判断から、応答するＨＴＭＬファイルから参照されるリソースデータを、全て通常リソースデータとする。

一方、先読みによる要求でないと判別した場合（ステップＳ５０５；Ｎｏ）、通信装置１００は、ＨＴＭＬファイルから参照されるリソースデータを１つ取り出す（ステップＳ５０７）。
つまり、応答データ生成部１１４は、ユーザ操作を起因とする要求であるため、応答性が重視されるとの判定から、以降、通常よりデータサイズが小さい節減リソースデータを参照したＨＴＭＬファイルを生成することになる。

通信装置１００は、未処理のリリースデータがあるか否かを判別する（ステップＳ５０８）。通信装置１００は、未処理のリリースデータがないと判別すると（ステップＳ５０８；Ｎｏ）、処理を終える。つまり、取り出すべきリソースデータがなくなるまで、以降の処理を繰り返す。

通信装置１００は、未処理のリリースデータがあると判別した場合（ステップＳ５０８；Ｙｅｓ）に、そのリソースデータが送信済みであるか否かを判別する（ステップＳ５０９）。
すなわち、応答データ生成部１１４は、送信履歴記憶部１１５を参照して、取り出したリソースデータに対応する通常リソースデータが、接続中の端末２００に送信済みであるか否かを判別する。

通信装置１００は、リソースデータが送信済みであると判別すると（ステップＳ５０９；Ｙｅｓ）、参照先を通常リソースデータとする（ステップＳ５１０）。
すなわち、応答データ生成部１１４は、通常リソースデータを表示する際に、端末２００の画面データ記憶部２４０中から取得可能であると判断し、通常リソースデータのＵＲＬを設定する。

一方、リソースデータが送信済みでないと判別した場合（ステップＳ５０９；Ｎｏ）、通信装置１００は、参照先を節減リソースデータとする（ステップＳ５１１）。
すなわち、応答データ生成部１１４は、次の通信でリソースデータを取得する要求を受けるものと判断し、節減リソースデータのＵＲＬを設定する。
なお、節減リソースデータは、例えば、画像の解像度を落とす、カラー画像の場合は色を白黒にする、共通化できるデータは共通化する、などにより、通常リソースデータよりもデータサイズを小さくしたデータである。
具体的に、上述した図７における符号６０２の画像データを一例として説明すると、図８に示すように、符号６０２−１にて示される画像データが通常リソースデータであり、符号６０２−２にて示される画像データが節減リソースデータである。図８の例では、通常リソースデータ（符号６０２−１）の解像度を落とすことにより、節減リソースデータ（符号６０２−２）が生成されている。

図６に戻って、通信装置１００は、節減リリースデータに対応する通常リソースデータの取得処理の記述を追加する（ステップＳ５１２）。
すなわち、応答データ生成部１１４は、例えば、JavaScript（登録商標）にて記述した節減リリースデータに対応する通常リソースデータの取得処理を応答するＨＴＭＬファイルに追加する。この取得処理の詳細については、後述する端末２００の動作と共に説明する。

このように、通信装置１００は、上述したステップＳ５０７〜Ｓ５１２の処理を繰り返し、ステップＳ５０８にて未処理のリソースデータがなくなると、ＨＴＭＬファイルの送信を終えることになる。
このようにして送られたＨＴＭＬファイルによって、端末２００にて暫定表示される画面の一例を図９に示す。
この図９は、上述した図７に先んじて暫定表示される画面であり、各符号も同じ箇所を示している。

図９において、符号６０１にて示される画像データは、ユーザの操作に影響しないため、灰色の四角形の画像データ（節減リソースデータ）に置き換えられている。また、符号６０２にて示される画像データは、解像度を落とした画像データ（節減リソースデータ）に置き換えられている。
また、符号６０３ａ〜符号６０３ｈにて示される画像データは共通化され、同じ灰色の四角形の画像データ（節減リソースデータ）に置き換えられている。同様に、符号６０４ａ〜符号６０４ｈ、および、符号６０５ａ〜符号６０５ｈにて示される画像データは、画像の意味をより少ないバイト数で表す別の画像データ（節減リソースデータ）に置き換えられている。

続いて、この図９に示すような画面を表示した端末２００の動作について、図１０を参照して説明する。図１０は、端末２００における取得処理の一例を説明するためのフローチャートである。なおこの取得処理は、上述した図１の更新処理記述部２６２の記述に基づいて処理される。つまり、通信装置１００が上述した図６の応答処理におけるステップＳ５１２にて追加した記述に従って、端末２００にて図１０の取得処理が実行される。

まず、端末２００は、未取得の通常リソースデータがあるか否かを判別する（ステップＳ７０１）。
端末２００は、未取得の通常リソースデータがあると判別すると（ステップＳ７０１；Ｙｅｓ）、一定時間、ユーザの操作の有無を監視する（ステップＳ７０２）。一例として、端末２００は、図９の画面において、３０秒の間、ユーザ操作を監視する。

端末２００は、監視中に、ユーザの操作を検知したか否かを判別する（ステップＳ７０３）。
端末２００は、ユーザの操作を検知したと判別すると（ステップＳ７０３；Ｙｅｓ）、ステップＳ７０２に処理を戻す。つまり、ユーザの操作が行われている場合には、その操作を妨げないように、後続処理には移らず、監視を継続する。

一方、監視中に、ユーザの操作を検知しなかったと判別した場合（ステップＳ７０３；Ｎｏ）、端末２００は、一定バイト分の通常リソースデータを、通信装置１００から取得する（ステップＳ７０４）。
すなわち、端末２００は、通信を長時間続けることによりユーザの操作を妨げないように、一定バイト分（一例として、５ｋバイト）ずつ、通常リソースデータを取得する。なお、一度に取得するバイト数の指定は、例えば、ＨＴＴＰメッセージのＲａｎｇｅヘッダを使用することにより行われる。また、このときの通信装置１００側の処理は、上述した図６の応答処理におけるステップＳ５０２を通るパスとなる。

端末２００は、１ファイル分の取得を完了したか否かを判別する（ステップＳ７０５）。
端末２００は、１ファイル分の取得を完了していないと判別すると（ステップＳ７０５；Ｎｏ）、上述したステップＳ７０２に処理を戻し、ステップＳ７０２〜Ｓ７０５の処理を繰り返し実行する。

一方、１ファイル分の取得を完了したと判別すると（ステップＳ７０５；Ｙｅｓ）、端末２００は、節減リソースデータを通常リソースデータに置き換えて表示する（ステップＳ７０６）。
つまり、端末２００は、取得した通常リソースデータを表示するために、画面表示を更新する。
そして、端末２００は、上述したステップＳ７０１に処理を戻し、残りの節減リソースデータに対応する通常リソースデータを継続する。そして、未取得の通常リソースデータがないと判別した場合（ステップＳ７０１；Ｎｏ）に、端末２００は、全ての節減リソースデータに対応する通常リソースデータを取得したため、処理を終える。
こうして、端末２００は、上述した図９の画面を更新して、上述した図７の画面を表示する。

この後、端末２００は、表示された画面から遷移し得る別画面、すなわち、図７の画面における符号６０６で示された各文字列から参照されるリンク先の画面の先読みを実行する。先読み処理では、上述したように、取得要求のＨＴＭＬファイルには、拡張子の前に「_pl」という文字列を入れる。また、先読み処理では、リソースデータの取得処理と同様に、ユーザの操作を監視しながら要求を送信する。そして、このときの通信装置１００側の処理は、上述した図６の応答処理におけるステップＳ５０６を通るパスとなる。そのため、通信装置１００は、節減リソースファイルのＵＲＬを設定することなく、通常リソースファイルのＵＲＬを設定した応答データを返信することになる。

最後に、上述した図４のステップＳ４０３における操作取得要求に対する処理の詳細を図１１を参照して説明する。図１１は、通信装置１００における操作応答処理の一例を示すフローチャートである。

まず、通信装置１００は、受信したメッセージから操作コマンドを抽出する（ステップＳ８０１）。
すなわち、応答データ生成部１１４は、例えば、図１２に示すような操作要求メッセージから、操作コマンドを抽出する。なお、図１２の操作要求メッセージは、一例として、グループ１（図７の画面では、一例として、エントランス）の電源をオフにする操作が示されている。
具体的に応答データ生成部１１４は、図１２における、ＨＴＴＰメッセージのボディ部のＸＭＬの記述（「<?xml」から「</Command>」まで）を、操作コマンドとして抽出する。

図１１に戻って、通信装置１００は、制御部１２０を介して、操作コマンドを送信する（ステップＳ８０２）。つまり、通信装置１００は、電気機器に向けて操作コマンド（一例として、グループ１の電源オフ）を送信する。
通信装置１００は、制御部１２０を介して、応答を受信する（ステップＳ８０３）。つまり、通信装置１００は、電気機器に向けて発した操作コマンドの成否（結果の成否）を電気機器から受信する。この結果の成否は、例えば、操作コマンドに対応するＸＭＬデータで得られる。

通信装置１００は、応答メッセージを生成する（ステップＳ８０４）。
すなわち、応答データ生成部１１４は、例えば、図１３に示すような応答メッセージを生成する。なお、図１３の応答メッセージは、一例として、グループ１の電源オフが成功した旨が示されている。

図１１に戻って、通信装置１００は、生成した応答メッセージを端末２００に返信する（ステップＳ８０５）。
そして、端末２００は、応答メッセージを受信することにより、送信した操作コマンドの成否を知ることができる。

以上のように、本実施形態では、端末２００からの画面の表示要求を受信した場合に、通信装置１００は、その要求がユーザ操作を起因として送信されたものか、先読み処理を起因として送信されたものかを判定する。そして、ユーザ操作を起因として送信されたされたものである場合に、通信装置１００は、応答性を重視した画面を端末２００に表示させることにより、画面表示の完了までユーザが画面を操作ができないために感じるストレスを軽減させることができる。つまり、通信装置１００は、通常より転送サイズの小さいデータ（節減リソースデータ）を送信し、暫定的な画面を端末２００に表示させることで、ユーザ操作の応答性を高めることができる

また、暫定的な画面を表示した後に、端末２００は、小さいデータを通常のデータ（通常リソースデータ）に置き換えることにより、画面表示の視認性を徐々に回復させることができる。
その際、端末２００は、ユーザの操作を監視し、ユーザが操作していないタイミングにて通常のデータを取得するため、操作の途中でトラフィックが発生することによる操作性の低下を防ぐことができる。
更に、端末２００は、通常のデータを取得する場合に、一度に取得するデータの量を制限することにより、操作の途中でトラフィックが発生することによる操作性の低下を防ぐことができる。

また、端末２００への送信履歴を記憶しておくことにより、通信装置１００は、通常のデータを送信済みの場合、その通常のデータを参照させる。そのため、端末２００は、受信済みの通常のデータを用いた画面を表示することが可能となり、画面表示の視認性を損なうことなく、ユーザ操作の応答性を高めることができる。

この結果、本発明によれば、電気機器の操作や設定などを行う場合でも、適切に応答性を向上させることができる。

上記の実施形態では、通信装置１００に本発明が適用される場合について説明したが、専用のシステムによらず、通常のコンピュータシステムを用いて実現可能である。例えば、前記の動作を実行するためのコンピュータプログラムを、コンピュータが読み取り可能な記録媒体（フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなど）に格納して配布し、当該コンピュータプログラムをコンピュータにインストールすることにより、前記の処理を実行する通信装置１００を構成してもよい。また、インターネットなどの通信ネットワーク上のサーバ装置が有する記憶装置に当該コンピュータプログラムを格納しておき、通常のコンピュータシステムがダウンロードなどすることで通信装置１００を構成してもよい。

また、通信装置１００の機能を、ＯＳ（オペレーティングシステム）とアプリケーションプログラムの分担、またはＯＳとアプリケーションプログラムとの協働により実現する場合などには、アプリケーションプログラム部分のみを記録媒体や記憶装置に格納してもよい。

また、搬送波にコンピュータプログラムを重畳し、通信ネットワークを介して配信することも可能である。例えば、通信ネットワーク上の掲示板（BBS, Bulletin Board System）に前記コンピュータプログラムを掲示し、ネットワークを介して前記コンピュータプログラムを配信してもよい。そして、このコンピュータプログラムを起動し、ＯＳの制御下で、他のアプリケーションプログラムと同様に実行することにより、前記の処理を実行できるように構成してもよい。

本発明は、電気機器をネットワークに接続させ、ネットワーク上の端末から電気機器へのアクセスを制御する通信装置、応答データ生成方法、および、プログラムに好適に採用され得る。

１００ 通信装置、１１０ 通信部、１１１ 通信インタフェース、１１２ 要求メッセージ解析部、１１３ 要求起因判定部、１１４ 応答データ生成部、１１５ 送信履歴記憶部、１１６ 第１のリソースデータ格納部、１１７ 第２のリソースデータ格納部、１２０ 制御部、２００ 端末、２１０ 通信インタフェース、２２０ 入力部、２３０ 表示部、２４０ 画面データ記憶部、２５０ 制御部、２６０ ＨＴＭＬファイル、２６１ 先読み処理記述部、２６２ 更新処理記述部、３００ ネットワーク

上記目的を達成するために、本発明に係る通信装置は、
電気機器をネットワークに接続させ、当該ネットワーク上の端末から当該電気機器へのアクセスを制御する通信装置であって、
前記端末からの要求を受信し、前記端末への応答を送信する通信インタフェースと、
前記端末に正規表示する画面を構成するための各リソースデータであり、通常のデータサイズの通常リソースデータを格納する第１のリソースデータ格納部と、
前記端末に暫定表示する画面を構成するための各リソースデータであり、前記通常リソースデータよりもデータサイズの小さい節減リソースデータを格納する第２のリソースデータ格納部と、
前記端末から表示する画面が要求された際に、当該要求の起因を判定する要求起因判定部と、
前記要求起因判定部による判定結果に基づいて、前記通常リソースデータまたは前記節減リソースデータを含んだ応答データを生成する応答データ生成部と、を備え、
前記要求起因判定部は、画面の要求が前記端末のユーザ操作に起因するものであるか否かを判定し、
前記応答データ生成部は、前記要求起因判定部によって前記ユーザ操作に起因するものと判定された場合に、前記節減リソースデータと、前記通常リソースデータの取得処理の記述とを含んだ応答データを生成する。

Claims (8)

1. 電気機器をネットワークに接続させ、当該ネットワーク上の端末から当該電気機器へのアクセスを制御する通信装置であって、
   前記端末からの要求を受信し、前記端末への応答を送信する通信インタフェースと、
   前記端末に正規表示する画面を構成するための各リソースデータであり、通常のデータサイズの通常リソースデータを格納する第１のリソースデータ格納部と、
   前記端末に暫定表示する画面を構成するための各リソースデータであり、前記通常リソースデータよりもデータサイズの小さい節減リソースデータを格納する第２のリソースデータ格納部と、
   前記端末から表示する画面が要求された際に、当該要求の起因を判定する要求起因判定部と、
   前記要求起因判定部による判定結果に基づいて、前記通常リソースデータまたは前記節減リソースデータを含んだ応答データを生成する応答データ生成部と、
   を備える通信装置。
2. 前記要求起因判定部は、画面の要求が前記端末のユーザ操作に起因するものであるか否かを判定し、
   前記応答データ生成部は、前記要求起因判定部によって前記ユーザ操作に起因するものと判定された場合に、前記節減リソースデータと、前記通常リソースデータの取得処理の記述とを含んだ応答データを生成する、請求項１に記載の通信装置。
3. 前記取得処理の記述は、前記端末におけるユーザの操作間隔が一定時間以上開いたときに、前記端末から前記通常リソースデータを要求するための記述である、請求項２に記載の通信装置。
4. 前記取得処理の記述は、前記端末から前記通常リソースデータを要求する際に、データ量を一定以内に抑えるための記述である、請求項２または３に記載の通信装置。
5. 前記応答データ生成部は、前記端末に表示する画面から遷移し得る別画面の先読み処理の記述を更に含んだ応答データを生成する、請求項２乃至４の何れか１項に記載の通信装置。
6. 前記端末に対して送信した前記通常リソースデータの送信履歴を記憶する送信履歴記憶部を更に備え、
   前記応答データ生成部は、前記送信履歴に基づいて、送信済みのリソースデータについては、前記通常リソースデータを参照し、未送信のリソースデータについては、前記節減リソースデータを参照する応答データを生成する、請求項１乃至５の何れか１項に記載の通信装置。
7. 電気機器をネットワークに接続させ、当該ネットワーク上の端末から当該電気機器へのアクセスを制御する通信装置における応答データ生成方法であって、
   前記通信装置は、前記端末からの要求を受信し、前記端末への応答を送信する通信インタフェースと、前記端末に正規表示する画面を構成するための各リソースデータであり、通常のデータサイズの通常リソースデータを格納する第１のリソースデータ格納部と、前記端末に暫定表示する画面を構成するための各リソースデータであり、前記通常リソースデータよりもデータサイズの小さい節減リソースデータを格納する第２のリソースデータ格納部と、を有するものであり、
   前記端末から表示する画面が要求された際に、当該要求の起因を判定する要求起因判定ステップと、
   前記要求起因判定ステップによる判定結果に基づいて、前記通常リソースデータまたは前記節減リソースデータを含んだ応答データを生成する応答データ生成ステップと、
   を備える応答データ生成方法。
8. 電気機器をネットワークに接続させ、当該ネットワーク上の端末から当該電気機器へのアクセスを制御するコンピュータを、
   前記端末からの要求を受信し、前記端末への応答を送信する通信インタフェース、
   前記端末に正規表示する画面を構成するための各リソースデータであり、通常のデータサイズの通常リソースデータを格納する第１のリソースデータ格納部、
   前記端末に暫定表示する画面を構成するための各リソースデータであり、前記通常リソースデータよりもデータサイズの小さい節減リソースデータを格納する第２のリソースデータ格納部、
   前記端末から表示する画面が要求された際に、当該要求の起因を判定する要求起因判定部、
   前記要求起因判定部による判定結果に基づいて、前記通常リソースデータまたは前記節減リソースデータを含んだ応答データを生成する応答データ生成部、
   として機能させるプログラム。

Images