JP4898225B2

JP4898225B2 - アプリケーション装置及びアプリケーション装置の電力の復帰方法

Info

Publication number: JP4898225B2
Application number: JP2006001375A
Authority: JP
Inventors: 英司今尾
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2006-01-06
Filing date: 2006-01-06
Publication date: 2012-03-14
Anticipated expiration: 2026-01-06
Also published as: JP2007183797A; US7809966B2; US20070162777A1

Description

本発明は、アプリケーション装置及びアプリケーション装置の電力の復帰方法に関する。

従来、アプリケーション機器において、アプリケーション通信を行っていない間は、アプリケーション機器を構成する装置の大部分の電源をオフにすることで省電力化を図っていた。そして、利用者は、アプリケーション機器との通信を行いたい場合、例えば、ネットワークを介してアプリケーション機器の電源を投入していた。なお、本明細書では、アプリケーション機器とは、ＴＣＰ／ＩＰプロトコルを下位プロトコルとするアプリケーション通信を、ネットワークを介して行うことが可能な機器のことを指す。

例えばＬＡＮに接続されるＰＣ（パーソナルコンピュータ）においては、ＣＰＵやハードディスク等のシステム装置の電源を停止し、ネットワークに直接接続しているネットワークインタフェースコントローラ（ＮＩＣ）のみが動作することによる省電力化を実現している。

ＮＩＣは、ネットワークから受信するデータセグメントが特定のデータ列を含有しているか否かを検査し、特定のデータ列を含むデータセグメントを受信した場合にＰＣのシステム装置の起動する制御を実行する。

この方法は一般にＷＯＬ（Ｗａｋｅ−Ｏｎ−ＬＡＮ）と呼ばれている。ＰＣにおける代表的な適用事例として、ＭａｇｉｃＰａｃｋｅｔ（登録商標）が挙げられる。図１の２０１は、ＭａｇｉｃＰａｃｋｅｔ（登録商標）における特定のデータ列の形式を表している。ＭａｇｉｃＰａｃｋｅｔ（登録商標）では、ＮＩＣは、１６進数のＦＦ・・・の６回繰り返し（２０２）に、ＭＡＣアドレスの１６回繰り返し（２０３）が続く形式のデータ列を受信したときに、システム装置を起動する。

図２の３０１は、ＵＤＰ／ＩＰパケットにおけるＭａｇｉｃＰａｃｋｅｔ（登録商標）の一例を表している。３０２はＩＰヘッダ、３０３はＵＤＰヘッダを表しており、パケットペイロードに、ＭａｇｉｃＰａｃｋｅｔ（登録商標）のデータ列３０４を含んでいる。

このような特定のデータ列を含むデータセグメントの受信によってアプリケーション機器のシステムの電源を投入する方法は、単純な仕組みである。そのため、特にＭａｇｉｃＰａｃｋｅｔ（登録商標）は、ネットワークを介したコンピュータ機器を遠隔起動する手段（又は方法）として広く実施されている。

また、ネットワークを介してアプリケーション機器の電源を投入して起動させる別の技術もある（例えば、特許文献１参照。）。

特開２０００−１１３１６号公報

しかしながら、ＷＯＬでは、ネットワークを介して、アプリケーション機器を起動させる側の装置等が、特定のデータ列を含むデータセグメントを生成する手段を有する必要があった。このため、遠隔起動させることができる装置が限定される。例えば、ＭａｇｉｃＰａｃｋｅｔ（登録商標）の場合、遠隔起動させる側の装置が、遠隔起動の対象であるアプリケーション機器のＭＡＣアドレスを予め記憶しておく必要がある。更に、遠隔起動を指示する装置が、図１の２０１に示されるデータ形式の送信データセグメントを生成する手段を有していなければならない。

また、ＷＯＬでは、アプリケーション機器を起動させる側の装置等が、アプリケーション機器が通常動作中（消費電力状態）か、または低消費電力状態かを考慮して通信を行う必要がある。

本発明は上記の問題点に鑑みなされたもので、消費電力を節約すると共に、簡単な構成で、ネットワークを介して接続された他の装置からの要求に応じて、低消費電力状態からの復帰を安全に行うことを目的とする。

そこで、上記問題を解決するため、本発明のアプリケーション装置は、ネットワークを介して接続された他の装置との通信を行う通信部と、アプリケーション機能を実行するためのアプリケーションシステム部と、前記他の装置からのＴＣＰパケットのヘッダに含まれるフラグビットフィールドにおいてＳＹＮフラグのみがオンであり、かつ、該ＴＣＰパケットの宛先ポート番号が前記アプリケーションシステム部において実行されるアプリケーション通信の受付ポート番号と一致していることを判定することにより、前記アプリケーションシステム部において実行されるアプリケーション通信のためのコネクション確立のための、前記アプリケーション通信の開始要求を検出する検出手段と、前記アプリケーションシステム部が低消費電力状態のときに、前記他の装置からの前記アプリケーションシステム部において実行されるアプリケーション通信の開始要求を前記検出手段において検出すると、前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させる制御手段と、を有することを特徴とする。

本発明によれば、消費電力を節約すると共に、簡単な構成で、ネットワークを介して接続された他の装置からの要求に応じて、低消費電力状態からの復帰を安全に行うことができる。

以下、本発明の実施形態について図面に基づいて説明する。

（実施形態１）
図３は、アプリケーション機器の一例を示すブロック図（その１）である。図３に示されるように、アプリケーション機器１０１は、そのハードウェア構成として、ネットワーク通信部１０２と、アプリケーションシステム部１０３と、からなる。

ネットワーク通信部１０２のローカルバス１０４には、通信制御部１０５、ローカルＲＡＭ１０６、プロトコル処理部１０７が接続されている。なお、ネットワーク１１６は、例えばイーサネット（登録商標）が想定できるが、無線ネットワークや、光ファイバーネットワーク等であってもよい。また、ネットワーク１１６は、アプリケーション機器１０１の利用者が遠隔地からＴＣＰ／ＩＰプロトコルを用いてアプリケーション通信を行えるものとする。

通信制御部１０５は、ネットワーク１１６に対して伝送フレームの送受信を行う。例えばネットワーク１１６がイーサネット（登録商標）の場合、通信制御部１０５は、イーサネット（登録商標）のＭＡＣ処理（伝送メディア制御処理）や、イーサネット（登録商標）フレームの送受信を行う。

プロトコル処理部１０７は、通信プロトコル処理専用のハードウェア回路装置、或いは通信プロトコル処理用に設計されたマイクロプロセッサであり、汎用的なＴＣＰ／ＩＰプロトコルの通信処理を行う。より具体的には、プロトコル処理部１０７は、ＩＰｖ４（ＩＰバージョン４）、ＩＰｖ６（ＩＰバージョン６）、ＩＣＭＰ、ＵＤＰ、ＴＣＰの各通信プロトコル処理や、送信フロー制御や輻輳制御、通信エラー制御等を行う。また、プロトコル処理部１０７は、電源制御部１１５と制御信号線で接続されており、電源制御部１１５の動作制御を行う。

ローカルＲＡＭ１０６は、通信制御部１０５やプロトコル制御部１０７の処理におけるデータの一時記憶領域に使用される。

また、ネットワーク通信部１０２は、ローカルバス１０４と、アプリケーションシステム部１０３のシステムバス１０９との間のデータ転送を可能とするバスブリッジ回路１０８を有する。即ち、ネットワーク通信部１０２と、アプリケーションシステム部１０３とは、それぞれのバス回路が相互に接続されており、通信データの入出力においてバス転送が行われる仕組みになっている。

アプリケーションシステム部１０３のシステムバス１０９には、ＣＰＵ１１０、システムプログラムが格納されているＲＯＭ１１１、システムプログラム実行時に使用される一時記憶装置であるＲＡＭ１１２、が接続されている。なお、ＲＯＭ１１１からＲＡＭ１１２にシステムプログラムが読み込まれ、ＣＰＵ１１０によって実行される。

また、同じくシステムバス１０９に接続されているアプリケーション機能Ａ（１１３）やアプリケーション機能部Ｂ（１１４）は、アプリケーション機器１０１の特徴的なアプリケーション機能を実現するために使用されるハードウェア処理装置を表している。

電源制御部１１５は、ネットワーク通信部１０２及びアプリケーションシステム部１０３の電力供給を独立的に制御する電源制御部である。電源制御部１１５は、１０９から１１４までの各装置に対して、電源投入の制御、ハードウェアリセット制御、アプリケーションシステム部１０３全体が保持データの破損なく安全に電源をオフにするための停止処理を開始する指示制御等を行う。

ＣＰＵ１１０は、アプリケーション機器１０１の各装置の機能を制御したり、システムプログラムに基づいてアプリケーション処理を実行したりする。ＲＡＭ１１２は、ＣＰＵ１１０によるプログラム実行のための一時記憶領域、またネットワーク通信部１０２や、アプリケーション機能部１１３、１１４が使用する入出力データ領域として使用される。

アプリケーション機器１０１のアプリケーション機能は、アプリケーションシステム部１０３で実現される。また、ＣＰＵ１１０で実行されるシステムプログラムは、アプリケーション機能の一部であるアプリケーション通信を行う。アプリケーション通信は、ＴＣＰ／ＩＰプロトコルをベースとした通信であり、ＴＣＰ／ＩＰプロトコル処理はネットワーク通信部１０２において実行される。

このような通信処理の機能分担を、図４を参照して説明する。図４において、４０１はＴＣＰ／ＩＰプロトコルの階層モデルである。下位層よりリンク層、ネットワーク層、トランスポート層、アプリケーション層４０３の４つに分類される。リンク層のプロトコルは、一般的な有線ＬＡＮにおけるイーサネット（登録商標）、ＩＥＥＥ８０２．１１ｂ／ａ／ｇで規格化されている無線ＬＡＮ等、物理ネットワークの通信プロトコルである。ネットワーク層のプロトコルとしては、ＩＰｖ４、ＩＰｖ６、ＩＣＭＰ、ＩＧＭＰが挙げられる。トランスポート層のプロトコルとしては、ＵＤＰ、ＴＣＰが挙げられる。アプリケーション層４０３には、インターネットにおいて標準的に利用するアプリケーションプロトコルであるＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、ＲＴＰ、ＲＴＣＰ等が挙げられる。また、ＴＣＰ／ＩＰでは独自に定義したアプリケーション層プロトコルによる通信が実施されることも多い。

ネットワーク通信部１０２は、４０２に示す範囲のリンク層、ネットワーク層、トランスポート層のプロトコル処理を実現するものである。また、アプリケーションシステム部１０３が実行するアプリケーション通信は、４０３のアプリケーション層のプロトコル処理を行う。

図４の４０５は、アプリケーション機器１０１が実行する通信処理を、４０１のＴＣＰ／ＩＰプロトコルの階層モデルに対応付けて階層的に表している。ネットワーク通信部１０２が実行する処理は、図４の４０５に示す範囲の処理である。

その中で、４０７で示される範囲、即ち以下の３つの処理は、通信制御部１０５において実行される。
ＭＡＣ（メディアアクセス制御装置）としてのネットワーク１１６の物理媒体に対する伝送制御処理
ＭＡＣ制御を行うＭＡＣドライバの処理
ＩＰアドレスとＭＡＣアドレスとの対応付けを解決するためのプロトコルであるＡＲＰプロトコルの処理

また、４０８で示される範囲、即ちネットワーク層プロトコルであるＩＰｖ４、ＩＰｖ６、ＩＣＭＰの処理や、トランスポート層プロトコルであるＵＤＰ、ＴＣＰの処理は、プロトコル処理部１０７において実行される。

一方、アプリケーションシステム部１０３が実行する処理は、４０６の範囲であり、アプリケーション機器１０１のアプリケーション通信で使用する全てのアプリケーション層プロトコル処理である。

４０４に示すＴＣＰ／ＩＰ通信の分担処理によって、アプリケーション機器１０１のアプリケーション通信は、アプリケーションシステム部１０３がネットワーク通信部１０２の通信機能を利用して実現する。

以上のような実施構成において、アプリケーション機器１０１がアプリケーション層のプロトコルを用いて通信を実行している状態では、少なくともネットワーク通信部１０２、システムバス１０９、ＣＰＵ１１０、ＲＯＭ１１１、ＲＡＭ１１２、電源制御部１１５が動作している。このときの消費電力の状態を、消費電力の通常状態と呼ぶものとする。通常状態では、アプリケーションシステム部１０３内のその他の装置であるアプリケーション機能部Ａ（１１３）や、アプリケーション機能部Ｂ（１１４）が動作する場合には消費電力が上昇し、動作しない場合にはそれらの分の消費電力が抑えられる。上述したように、アプリケーションシステム部の１０９から１１４までのハードウェア装置への電力供給の制御が、電源制御部１１５によってなされている。

一方、アプリケーション通信を実行しない期間は、アプリケーション機器１０１は、アプリケーションシステム部１０３内の１０９から１１４までのハードウェア装置の電源をオフにして動作を停止する。そして、アプリケーション機器１０１は、ネットワーク通信部１０２と、電源制御部１１５とだけを動作させておく。このことによって、アプリケーション機器１０１は、消費電力を大きく低減させる低消費電力状態にすることができる。

図５は、アプリケーション機器１０１の消費電力の通常状態と、低消費電力状態との状態遷移図である。５０１は消費電力の通常状態を表し、５０２は低消費電力状態を表す。消費電力の通常状態では、アプリケーション通信を実行中のとき（５０３）そのまま通常状態を維持する。

そして、全てのアプリケーション通信が終了してからアプリケーション機器１０１のＲＯＭ１１１等に予め設定されたある一定時間が経過した場合（５０４）、低消費電力状態５０２に移行する。或いは、アプリケーション機器１０１が初めて電源を投入された初期起動処理後、ＲＯＭ１１１等に予め設定されたある一定時間内にアプリケーション通信が１つも実行されていない場合にも、低消費電力状態５０２に移行する。

一方の５０２の低消費電力状態では、アプリケーション機器１０１に利用者からのアプリケーション通信の開始要求を受信したとき（５０５）に、消費電力の通常状態５０１に移行する。

次に、アプリケーション機器１０１が低消費電力状態においてクライアント機器等からアプリケーション通信の開始要求を受信したときの動作の概略を、図６を参照して説明する。
図６の６０１はアプリケーション機器を表し、図３におけるアプリケーション機器１０１と一致する。アプリケーション機器６０１は、ネットワーク通信部６０２と、アプリケーションシステム部６０３とで構成されており、それぞれ、図３のネットワーク通信部１０２と、アプリケーションシステム部１０３とに一致する。

アプリケーション機器６０１は、クライアント機器６０４で表されており、アプリケーション機器６０１との間にはネットワーク経路６０５が存在している。６０５のネットワーク経路はＬＡＮ、又はＬＡＮ間をＷＡＮで経由したネットワーク、更にインターネットを経由することがあってもよい。

利用者であるクライアント機器６０４は、アプリケーション機器６０１に対してアプリケーション通信の開始要求６０６を送信する。アプリケーション機器（サーバ機器）６０１では、ネットワーク通信部６０２がアプリケーション通信の開始要求６０６の受信を行う。ネットワーク通信部６０２は、アプリケーション通信の開始要求６０６を受信すると、クライアント機器６０４に確認応答６０７を送信すると共に、アプリケーションシステム部６０３に電源を投入する（６０９）。

次に、アプリケーション機器１０１の低消費電力状態において、ネットワーク通信部１０２における通信処理について説明する。まず、ネットワーク通信部１０２は、ネットワーク１１６へ能動的にフレームを送信する又は通信することは行わない。即ち、ネットワーク１１６から到着するデータフレームの受信処理を行い、フレームの送信が必要である場合において送信を行う。

以下、ネットワーク１１６がイーサネット（登録商標）である場合を例に挙げて説明する。通信制御部１０５は、ネットワーク１１６（イーサネット（登録商標））を流れるフレームの中で、宛て先アドレスが自装置のＭＡＣアドレス、或いはブロードキャストアドレスのフレームだけを受信してローカルＲＡＭ１０６に書き込む。その後、通信制御部１０５は、受信フレームのフレームヘッダを解析し、フレームが格納するデータの通信プロトコルを調べる。

図７は、イーサネット（登録商標）プロトコル通信におけるデータフレーム形式を表す図である。図７の７０１は宛先アドレス、７０２は送信元のアドレスを表す。続く７０３は、上位層のプロトコルを区別するタイプＩＤ（識別子）を示し、７０４は、フレームが運ぶデータである。７０３のタイプＩＤの値は、７０４のデータがＩＰパケットの場合は０ｘ０８００、７０４のデータがＡＲＰプロトコルのパケットの場合は０ｘ０８０６が設定される。

フレームの最後には４バイトのＦＣＳ（ＦｒａｍｅＣｈｅｃｋＳｅｑｕｅｎｃｅ）が格納される。ＦＣＳは、７０１の宛先アドレスから７０４のデータまでにビット誤りが発生していないかを検出する為に付与されるＣＲＣ（ＣｙｃｌｉｃＲｅｄｕｎｄａｎｃｙＣｈｅｃｋ）コードである。

したがって、通信制御部１０５は、受信フレームのヘッダを解析し、図７の７０３に示すイーサネット（登録商標）ヘッダのタイプフィールドが０ｘ０８００であれば、ＩＰプロトコルであるのでプロトコル処理部１０７に受信処理を開始させる。イーサネット（登録商標）ヘッダのタイプフィールドが、０ｘ０８０６であれば、ＡＲＰパケットを受信したことになり、ＡＲＰパケットの解析を行う。

通信制御部１０５は、ＡＲＰパケットを受信した場合、ＡＲＰパケットが自アプリケーション機器１０１のＩＰアドレス対応するＭＡＣアドレスを尋ねるＡＲＰリクエストであるならば、以下の処理を行う。つまり、通信制御部１０５は、ＡＲＰリクエストの送信元に自装置のＭＡＣアドレスを返答するため、ＡＲＰリプライパケットを作成しネットワーク１１６に送信する。一方、ＡＲＰパケットが自アプリケーション機器１０１のＩＰアドレス対応するＭＡＣアドレスを尋ねるＡＲＰリクエストでなければ、通信制御部１０５は、ＡＲＰパケットを破棄して何も処理を行わない。

次に、アプリケーション機器１０１が低消費電力状態であるときのプロトコル処理部１０７の処理について説明する。通信制御部１０５によって受信したフレームデータが、ローカルＲＡＭ１０６に記憶され、更にＩＰパケットを含むと判定された場合、プロトコル処理部１０７は、通信制御部１０５から処理開始指示の通知を受け取って、処理を開始する。

プロトコル処理部１０７の主な役割は、受信ＩＰパケットが、アプリケーション層におけるアプリケーション通信の開始要求であるならば、電源制御指示を行い、アプリケーションシステム部１０２を低消費電力状態から復帰させ、アプリケーション通信を開始できるようにすることである。

プロトコル処理部１０７は、ネットワーク１１６から受信するフレームデータが、以下の条件１〜３を全て満たす場合、アプリケーション機器１０１が提供しているアプリケーション通信の開始要求であると判定する。条件１：アプリケーション機器１０１宛てのＴＣＰパケットである。条件２：ＴＣＰコネクション開始要求のＴＣＰパケットである。条件３：ＴＣＰパケットの宛先ポート番号がアプリケーション通信の受付けポート番号に一致する。

そして、プロトコル処理部１０７は、宛先ポート番号によって、アプリケーション機器１０１が提供するアプリケーション通信の何れの開始要求であるかを判断する。

またプロトコル処理部１０７は、アプリケーション機器１０１の低消費電力状態において、アプリケーション通信を行うために起動する必要があるアプリケーションシステム部１０３内の装置に電源を投入するため、電源制御部１１５に対して電源制御指示を行う。このために、プロトコル処理部１０７は、ローカルＲＡＭ１０６に、アプリケーション通信と、その受付けＴＣＰポート番号と、電源制御部１１５への電源制御指示コードとの対応付けデータを保持している。図８は、対応付けデータの一例を示す図（その１）である。

図８において、１２０１の列は受付けＴＣＰポート番号である。１２０２の列はＴＣＰポート番号に対応するアプリケーション通信の内容である。１２０３の列はアプリケーション通信のアプリケーションプロトコル名である。１２０４の列は電源制御部１１５に対する電源制御指示コードである。

例えば、テーブル１２０５において、ある欄では、アプリケーション機器１０１が受付けるＴＣＰポート番号が８０であり、そのアプリケーション通信の内容は、Ｗｅｂブラウジング用にアプリケーション機器１０１の操作ページの転送を示している。また、アプリケーション通信に使用されるプロトコルはＨＴＴＰプロトコルであることを示している。そして、このアプリケーション通信によって、アプリケーション機器１０１を低消費電力状態から起動するときは、プロトコル処理部１０７が電源制御部１１５に対して、電源制御指示コードの０ｘ４１を設定することを示している。

アプリケーション機器１０１が低消費電力状態であるときのプロトコル処理部１０７の処理を、図９、図１０、図１１及び図１２を参照しながら説明する。図９及び図１０は、アプリケーション機器１０１が低消費電力状態であるときのプロトコル処理部１０７の処理の一例を示すフローチャートである。また、図１１は、ＩＰパケットのパケットデータ形式を示す図である。図１２はＴＣＰパケットデータ形式を示す図である。

プロトコル処理部１０７の処理は、図９のＳ８０１から始まり、まずＳ８０２において、受信したＩＰパケットヘッダを解析し、宛先ＩＰアドレスが、アプリケーション機器１０１に設定されている自ＩＰアドレスに一致しているか否かを調べる。

宛先ＩＰアドレスが一致していない場合、また例えばブロードキャストされたＩＰパケットのような場合、プロトコル処理部１０７は、Ｓ８０６に進み、受信したＩＰパケットを破棄して終了する。

ここでＩＰパケットは、図１１に示す形式になっており、プロトコル処理部１０７は、受信パケットの宛先ＩＰアドレスを、１０１０のフィールドを調べることによって確認する。プロトコル処理部１０７は、宛先ＩＰアドレスが自ＩＰアドレスと一致する場合は、Ｓ８０３に進み、受信したＩＰパケットのデータがＴＣＰパケットか否かを調べる。

プロトコル処理部１０７は、ＩＰパケットのデータがＴＣＰパケットか否かを、受信ＩＰパケットにおいて図１１の１００９が示すフィールドの値を検査することによって調べる。本実施の形態において、プロトコル処理部１０７は、図１１の１００９が示すフィールドの値が６の場合、ＩＰパケットのデータがＴＣＰパケットであると判定する。

Ｓ８０３において、プロトコル処理部１０７は、ＩＰパケットのデータがＴＣＰパケットであると判定するとＳ８０４に進み、ＩＰパケットのデータがＴＣＰパケットでないと判定するとＳ８０６に進み、受信したＩＰパケットを破棄して処理を終了する。

Ｓ８０４において、プロトコル処理部１０７は、ＴＣＰパケットのＴＣＰヘッダを解析する。つまり、プロトコル処理部１０７は、図１２の１１０７から１１１２で示されるフラグビットフィールドを調べる。プロトコル処理部１０７は、フラグのＳＹＮ（１１１１）がオンであり、他のフラグビットであるＵＲＧ（１１０７）、ＡＣＫ（１１０８）、ＰＳＨ（１１０９）、ＲＳＴ（１１１０）、ＦＩＮ（１１１２）がオフであるならば、Ｓ８０５に進む。つまり、プロトコル処理部１０７は、ＴＣＰコネクションの開始要求であると判断する。プロトコル処理部１０７は、フラグのＳＹＮ（１１１１）だけがオンな訳ではない（つまり、例えば他のフラグもオンである等）と判定すると、無効なＴＣＰパケットであると判断し、Ｓ８０６において受信したＩＰパケットを破棄して処理を終了する。

Ｓ８０５において、プロトコル処理部１０７は、ＴＣＰパケットの宛先ポート番号が、アプリケーション機器（サーバ装置）１０１が提供するアプリケーション通信の受付けポート番号であるか否かを調べる。プロトコル処理部１０７は、ローカルＲＡＭ１０６に保持する、図８に示したような対応付けデータの中に、宛先ポート番号に一致する受付けポート番号があるかを検索することによって調べる。プロトコル処理部１０７は、宛先ポート番号が、受付け可能なポート番号と一致したならばＳ８０７に進み、受付け可能なポート番号と一致しなかったらＳ８０６に進み、受信したＩＰパケットを破棄して処理を終了する。

以上までの処理フローにおいて、Ｓ８０７に進んだ場合、プロトコル処理部１０７は、アプリケーション通信の開始要求を受信したと判定する。そして、Ｓ８０７において、プロトコル処理部１０７は、電源制御部１１５に図８の１２０４で示される電源制御コードの中から、該当する電源制御コードを送信する。

電源制御部１１５は、電源制御指示コードに従って、アプリケーションシステム部１０３を構成する１０９から１１４までのハードウェア装置に選択的に電源を投入する処理を実行する。

プロトコル処理部１０７は、Ｓ８０７でアプリケーションシステム部１０３の起動を指示すると、起動完了を待たず、Ｓ８０８において、ＴＣＰコネクションの開始要求に対する確認応答のＴＣＰ／ＩＰパケットを作成する。そして、プロトコル処理部１０７は、作成した確認応答用のＴＣＰ／ＩＰパケットを、通信制御部１０５を介してアプリケーション通信の要求元であるクライアント機器に送出する。

この確認応答用のＴＣＰ／ＩＰパケットは、ＴＣＰヘッダのフラグビットのＳＹＮ（図１２の１１１１）と、ＡＣＫ（図１２の１１０８）とがオンである。また、このＴＣＰ／ＩＰパケットは、応答確認番号（図１２の１１０４）に、受信したＩＰパケットが格納していたＴＣＰパケットのＴＣＰシーケンス番号（図１２の１１０４）の値がセットされている。

Ｓ８０９と、Ｓ８１０とは、プロトコル処理部１０７が、クライアント機器に送信した確認応答パケットに対して、クライアント機器から送信されるべき確認応答パケットの受信を、予め設定されたタイムアウト時間まで待つ処理である。

プロトコル処理部１０７は、Ｓ８０９では確認応答を待ち、Ｓ８１０では受信を待っている時間がタイムアウトしているか否かを調べる。プロトコル処理部１０７は、もしタイムアウト期限時間内にクライアント機器からの確認応答を受信できなかった場合には、Ｓ８１４に進み、受信できた場合にはＳ８１１に進む。

Ｓ８１４において、プロトコル処理部１０７は、ＴＣＰコネクションの強制終了を行う。つまり、プロトコル処理部１０７は、クライアント機器に対して、コネクションの中断のため、ＴＣＰヘッダのフラグビットのＲＳＴ（図１２の１１１０）がオンであるＴＣＰ／ＩＰパケットを作成し、通信制御部１０５からネットワーク１１６に送出する。こうして、プロトコル処理部１０７は、クライアント機器から要求されたアプリケーション通信の開始要求を取り消す。

Ｓ８１５において、プロトコル処理部１０７は、アプリケーションシステム部１０３を再び低消費電力状態に移行するよう、電源制御部１１５に電源制御指示を電源制御部１１５に送信する。電源制御部１１５は、前記指示を受け取ると、アプリケーションシステム部１０３に対して、全体の電源をオフにして停止させる処理の開始指示を送信する。この指示を受け取ると、アプリケーションシステム部１０３は、アプリケーション機器１０１の低消費電力状態からの復帰動作中であっても、即時にシステムの停止処理を開始し、電源をオフにする。

Ｓ８１１からＳ８１３までは、プロトコル処理部１０７が、アプリケーションシステム部１０３の起動完了の通知を待ちながら、起動完了までの間にクライアント機器からのパケットを受信したときにアプリケーション通信時のデータを一時保存しておく処理を行う。

アプリケーションシステム部１０３のＣＰＵ１１０は、起動完了を確認すると、プロトコル処理部１０７に対して起動完了した旨の通知（起動完了通知）を行う。Ｓ８１１において、プロトコル処理部１０７は、この起動完了通知を受け取ったか否かを確認する。プロトコル処理部１０７は、起動完了通知を受け取っていないと判定すると、Ｓ８１２に進む。

Ｓ８１２において、プロトコル処理部１０７は、通信制御部１０５等を介して、クライアント機器からアプリケーション通信パケットを受信しているか否かを判断する。プロトコル処理部１０７は、通信制御部１０５等を介して、クライアント機器からアプリケーション通信パケットを受信していると判断すると、Ｓ８１３に進む。一方、プロトコル処理部１０７は、通信制御部１０５等を介して、クライアント機器からアプリケーション通信パケットを受信していないと判断すると、Ｓ８１１に戻る。

Ｓ８１３において、プロトコル処理部１０７は、アプリケーション通信データをローカルＲＡＭ１０６に記憶しておく。

一方、Ｓ８１１において、プロトコル処理部１０７が、起動完了通知を受け取ったと判定すると、Ｓ８１６に進む。なお、Ｓ８１６は、図１０のＳ９０１へと続き、次のプロトコル処理部１０７の処理は、Ｓ９０２となる。

Ｓ９０２において、プロトコル処理部１０７は、アプリケーションシステム部１０３に対して、どのアプリケーション通信を開始するべきかを通知する。より具体的に説明すると、プロトコル処理部１０７は、ＣＰＵ１１０で動作するシステムプログラムに、図８の１２０２と、１２０３とで示されるアプリケーション通信の内容（種類）及び使用するアプリケーションプロトコルを通知する。

ＣＰＵ１１０で動作するシステムプログラムは、プロトコル処理部１０７からの通知で指定されたアプリケーション通信に必要なアプリケーションシステム部１０３の準備処理を行う。そして、ＣＰＵ１１０で動作するシステムプログラムは、アプリケーション通信データの出力と、入力とで使用するＲＡＭ１１２上のメモリ領域のアドレス及びサイズを、プロトコル処理部１０７に通知する。つまり、ＣＰＵ１１０で動作するシステムプログラムは、アプリケーション通信に使用する送信バッファと、受信バッファとの通知を行う。

プロトコル処理部１０７の処理はＳ９０２からＳ９０３に進む。Ｓ９０３からＳ９０６までは、プロトコル処理部１０７が、アプリケーション通信に使用する送信バッファと、受信バッファとの通知を待つ。そして、プロトコル処理部１０７は、通知を待つ間に、クライアント機器からアプリケーション用のパケットであるアプリケーション通信パケットを受信した場合には、そのアプリケーション通信パケットをアプリケーション通信データとして一時保存しておく。

Ｓ９０３において、プロトコル処理部１０７は、アプリケーションシステム部１０３から送信バッファと、受信バッファとの通知を受け取っているか否かを判断する。プロトコル処理部１０７は、通知を受け取っていると判断した場合、Ｓ９０４に進み、通知を受け取っていないと判断した場合Ｓ９０５に進む。

Ｓ９０５において、プロトコル処理部１０７は、通信制御部１０５等を介して、クライアント機器からアプリケーション通信パケットを受信しているか否かを判断する。プロトコル処理部１０７は、通信制御部１０５等を介して、クライアント機器からアプリケーション通信パケットを受信していると判断すると、Ｓ９０６に進む。一方、プロトコル処理部１０７は、通信制御部１０５等を介して、クライアント機器からアプリケーション通信パケットを受信していないと判断すると、Ｓ９０３に戻る。Ｓ９０６において、プロトコル処理部１０７は、クライアント機器からのアプリケーション通信データをローカルＲＡＭ１０６に記憶する。

Ｓ９０４において、プロトコル処理部１０７は、図９のＳ８１３や、Ｓ９０６においてクライアント機器からのアプリケーション通信データをローカルＲＡＭ１０６に記憶していたか否かを判断する。プロトコル処理部１０７は、アプリケーション通信データをローカルＲＡＭ１０６に記憶していた場合は、Ｓ９０７に進み、アプリケーション通信データをローカルＲＡＭ１０６に記憶していなかった場合は、Ｓ９０８に進む。

Ｓ９０７において、プロトコル処理部１０７は、ローカルＲＡＭ１０６に記憶しておいたアプリケーション通信データをＲＡＭ１１２の受信バッファ領域に転送する。

Ｓ９０８において、プロトコル処理部１０７は、アプリケーション通信の開始を、アプリケーションシステム部１０３に通知する。ＣＰＵ１１０で動作中のシステムプログラムは、この通知を確認すると、アプリケーション通信を開始する。

以上が、アプリケーション機器１０１が低消費電力状態であるときのプロトコル処理部１０７における処理動作である。なお、上記では、プロトコル処理部１０７の処理において、ＩＰパケットのＩＰヘッダチェックサムや、ＴＣＰパケットのＴＣＰチェックサムの検査についての処理は、説明を省略した。プロトコル処理部１０７は、それぞれのパケットのヘッダ解析時（Ｓ８０２やＳ８０４）において、チェックサムの検査をい、パケットにデータ誤りがあると判断すると、受信パケットを破棄するものとする。

次にアプリケーション機器１０１と、クライアント機器との間のアプリケーション通信の開始初期における正常系の送受信シーケンスを、図１３を参照しながら説明する。

図１３の１３０１はクライアント機器側の時間軸、１３０２はアプリケーション機器１０１側の時間軸を表し、両時間軸間にある１３０３から１３１０までの矢印は、通信データの送信方向を示す。

１３０３はＴＣＰコネクションの開始要求の通信パケットを表す。即ちアプリケーション通信の開始を要求するＴＣＰパケットのことである。アプリケーション機器１０１は、開始要求の通信パケット１３０３を受信すると、ＴＣＰコネクションの開始要求に対する確認応答のＴＣＰパケット１３０４を送信する。クライアント機器は、確認応答のＴＣＰパケット１３０４を受信すると、確認応答のＴＣＰパケット１３０４に対する１３０５の確認応答のＴＣＰパケットを、アプリケーション機器１０１に送信する。

クライアント機器及びアプリケーション機器１０１は、この３回のＴＣＰパケットのやり取り（１３１１）によってＴＣＰコネクションは確立されたものとみなす。１３１１のＴＣＰコネクションを確立する通信は、３ウェイハンドシェイクと呼ばれている。

こうしてクライアント機器と、アプリケーション機器との間でＴＣＰコネクションが確立されると、クライアント機器は、アプリケーション機器１０１に対し、ＨＴＴＰやＦＴＰ等のアプリケーションプロトコルによる通信を始める。１３０６〜１３０７までの矢印が示す通信パケットは、アプリケーション通信（１３１２）を表している。

アプリケーション機器１０１が低消費電力状態（アプリケーションシステム部１０３において電源制御部１１５を除くハードウェア装置の電力の供給をオフにした状態）において、クライアント機器からアプリケーション通信の開始要求を受信し、アプリケーションシステム部１０３が起動される。この場合、１３１１のＴＣＰコネクションを確立するまでの通信をネットワーク通信部１０２で実行する。そして、１３１２のアプリケーション通信は、ネットワーク通信部１０２と、起動されたアプリケーションシステム部１０３とによって実行されることになる。

本実施形態によれば、アプリケーション機器１０１がアプリケーション通信を実行しない間は、アプリケーションシステム部１０３において電源制御部１１５を除くハードウェア装置の電力の供給をオフにすることができ、低消費電力を実現することができる。

また、本実施形態によれば、アプリケーション通信の開始要求を、ＴＣＰ通信コネクションを開始する宛先ポート番号がアプリケーション通信毎の受付けポート番号の何れかであるＴＣＰパケットを受信した場合としている。このことにより、標準的なＴＣＰ／ＩＰプロトコル通信で、アプリケーション機器１０１の遠隔起動を実現することができ、特別な手段を設ける必要がない。

更に、本実施形態によれば、アプリケーション機器１０１の低消費電力状態においてアプリケーションシステム部１０３内の電源がオフである装置の内、アプリケーション通信の実行に必要となる装置だけを選択的に起動する。よって、低消費電力状態からの復帰にかかる時間を短縮することができる。更にプロトコル処理部１０７が、アプリケーションシステム部１０３の起動完了を待たずにアプリケーション通信のＴＣＰコネクションを確立するため、アプリケーションシステム部１０７は起動後に直ぐにアプリケーション通信を開始することができる。

（実施形態２）
本実施形態では、実施形態１で示したアプリケーション機器１０１の一例としてネットワークカメラ１４０１を用いて説明を行う。

本実施形態のネットワークカメラ１４０１は、撮影静止画データ或いは撮影動画データを配信する。また、ネットワークカメラ１４０１は、ネットワークカメラ１４０１と離れた場所にいるクライアント機器側の指示により、カメラ撮影開始や撮影停止、パン／チルト／ズーム等の制御が可能である。また、ネットワークカメラ１４０１は、撮影した静止画や動画を蓄積する２次記憶装置を有し、以前に撮影した静止画や動画データをクライアント機器に転送できる。また、ネットワークカメラ１４０１は、組込みＷｅｂサーバの機能を有している。つまり、利用者は、ネットワークを介して接続されたＰＣや携帯電話等のＷｅｂブラウザから、撮影画像の表示、カメラ操作、或いはシステム設定を行うことができる。なお、これらの各機能はネットワークを介した通信を利用して実現されている。

図１４は、ネットワークカメラの一例を示すブロック図（その１）である。図３と同じ符号の構成は第１の実施の形態において説明した機能と同様の機能を果たすものとしてその説明を省略する。図１４に示されるように、アプリケーションシステム部１０３としてカメラシステム部１４０３が構成されたものである。

カメラシステム部１４０３のＲＯＭ１１２は、カメラシステムを実行するプログラムが格納されている。ＲＯＭ１１１からＲＡＭ１１２にカメラシステムプログラムが読み込まれ、ＣＰＵ１１０によって実行される。

また、システムバス１０９に接続されている二次記憶装置１４１３は、例えばハードディスク装置、或いはＣＦカードやＳＤカード等の記憶容量が大きなメモリに記憶するための不揮発性メモリ装置である。二次記憶装置１４１３は、主にネットワークカメラ１４０１が撮影した静止画や動画データをファイル形式で保存するために使用される。

また、システムバス１０９に接続されている撮像部１４１４は、ネットワークカメラ１４０１の撮像部であり、レンズ、ＣＣＤ（光電変換素子）、ＣＣＤ制御部等を含む。撮像部１４１４は、レンズを通して投影される撮像を、ＣＣＤによってアナログ電気信号に変換する。また、撮像部１４１４は、アナログ電気信号に変換された撮像画像から、ノイズ除去等の処理を施し、デジタルデータに変換するＡ／Ｄ変換を行う。

また、システムバス１０９に接続されているエンコーダ１４１５は、非圧縮デジタル画像データのエンコード（圧縮符号化）を実行する。撮像部１４１４が一定の周期で非圧縮デジタル画像データを出力し、エンコーダ１４１５が非圧縮デジタル画像データをエンコードすることにより、クライアント機器に配信する静止画データや、動画が生成される。なお、本実施形態におけるエンコーダ１４１５は、画像データの高速なエンコード処理を実現するハードウェア装置であり、複数のエンコード形式に対応する。エンコード形式には、ＪＰＥＧや、ＭＰＥＧ４を含む。

ネットワークカメラ１４０１のアプリケーション機能は、カメラシステム部１４０３で実現される。また、ＣＰＵ１１０で実行されるシステムプログラムは、アプリケーション機能の一部であるアプリケーション通信を行う。例えば、撮影映像のストリーミング配信は、撮像部１４１４が撮影した非圧縮画像フレームデータをエンコーダ１４１５によってエンコードし、圧縮画像データをＲＡＭ１１２に出力する。ＣＰＵ１１０で実行されるシステムプログラムは、ＲＡＭ１１２上の圧縮画像データからストリーミングプロトコルで送信可能な形式のストリーミングデータを作成する。そして、ＣＰＵ１１０で実行されるシステムプログラムは、下位層のＴＣＰ／ＩＰプロトコル処理機能を有するネットワーク通信部１０２を利用して、ストリーミングデータを配信先に送信する。

また、遠隔撮影操作に応じた撮影等は、ＣＰＵ１１０が実行するカメラシステムプログラムが、クライアント機器からの撮影操作コマンドを受信、解釈する。そして撮像部１４１４、エンコーダ１４１５に撮影操作コマンドに応じた動作制御を指示することで実行される。なお、より詳細に説明すると、まず、ネットワーク通信部１０２が通信パケットを受信し、ＴＣＰ／ＩＰプロトコルのパケット受信処理が行われる。その後、撮影操作コマンド用のプロトコルのデータ形式であるデータセグメントが、システムプログラムに入力されることによって、利用者からの撮影操作コマンドの受信がなされる。

ネットワークカメラ１４０１は、アプリケーション通信を実行している間は、少なくともネットワーク通信部１０２、システムバス１０９、ＣＰＵ１１０、ＲＯＭ１１１、ＲＡＭ１１２、電源制御部１１５が動作している。一方、ネットワークカメラ１４０１は、アプリケーション通信を実行しない期間は、カメラシステム部１４０３内の各ハードウェア装置の電源をオフにして動作を停止する。そして、ネットワークカメラ１４０１は、ネットワーク通信部１０２と、電源制御部１１５とだけを動作させておく。このことにより、消費電力を大きく低減させる低消費電力状態にすることができる。

ネットワークカメラ１４０１は、低消費電力状態において、ネットワーク通信部１０２と、電源制御部１１５とだけが動作し、クライアント機器からのアプリケーション通信の開始要求を待機する。また、ネットワーク通信部１０２は、アプリケーション通信の開始要求を受信すると、カメラシステム部１４０３を構成する装置の内、アプリケーション通信を実行するのに必要な装置の電源をオンにする。このことによって、カメラシステム部１４０３と、ネットワーク通信部１０２とが動作してアプリケーション通信を開始することができる。

アプリケーション通信の開始要求は、ネットワークカメラ１４０１宛てのＴＣＰパケットであり、且つＴＣＰコネクション開始要求のパケットであり、更にＴＣＰパケットの宛先ポート番号がアプリケーション通信の受付けポート番号に一致することが条件である。この条件が満たされた場合、アプリケーション通信の開始要求であると判定される。

このアプリケーション通信の開始要求の判定処理は、プロトコル処理部１４０７によって実行される。ネットワークカメラ１４０１が低消費電力状態の場合、プロトコル処理部１０７は、アプリケーション通信の開始要求であると判定した場合、カメラシステム部１４０３内の装置に電源を投入するため、電源制御部１４１６に対して電源制御指示を行う。

プロトコル処理部１０７は、アプリケーション通信の開始要求の判定処理を行うため、ローカルＲＡＭ１０６にアプリケーション通信、その受付けＴＣＰポート番号、及び電源制御部１１５への電源制御指示コードの対応付けデータを保持している。図１５は、対応付けデータの一例を示す図（その２）である。

図１５において、１５０１の項目は受付けＴＣＰポート番号である。１５０２の項目はＴＣＰポート番号に対応するアプリケーション通信の内容（種類）である。１５０３の項目はアプリケーション通信のアプリケーションプロトコル名である。１５０４の項目は電源制御部１１５に対する電源制御指示コードである。また、１５０４の項目はその電源制御指示コードによって起動される、カメラシステム部１４０３内の装置である。

例えば１５０６のエントリでは、ネットワークカメラ１４０１が受付けるＴＣＰポート番号が８０８０であり、そのアプリケーション通信は、ネットワークカメラ１４０１が撮影する映像のストリーミング配信であることを示している。また、１５０６のエントリでは、ストリーミング配信に使用するアプリケーションプロトコルはＨＴＴＰプロトコルであることを示している。また、１５０６のエントリでは、このアプリケーション通信によって、ネットワークカメラ１４０１が低消費電力状態から起動するときは、プロトコル処理部１０７が電源制御部１４１６に対して、電源制御指示コード０ｘ８１を設定することを示している。また、１５０６のエントリでは、電源を投入して起動される装置は、システムバス１０９、ＣＰＵ１１０、ＲＯＭ１１１、ＲＡＭ１１２、撮像部１４１４、エンコーダ１４１５であることを示している。
その他の処理は第１の実施の形態と同様であるので、その説明を省略する。

本実施形態によれば、ネットワークカメラ１４０１は、アプリケーション通信を実行しない間、カメラシステム部１４０３の電源制御部１１５を除く全てのハードウェア装置の電源をオフにすることができ、消費電力を抑えることができる。

また、本実施形態では、アプリケーション通信の開始要求を、ＴＣＰ通信コネクションを開始する宛先ポート番号がアプリケーション通信毎の受付けポート番号の何れかであるＴＣＰパケットを受信した場合としている。よって、標準的なＴＣＰ／ＩＰプロトコル通信で、遠隔起動を実現することができる。

また、本実施形態では、ネットワークカメラ１４０１の低消費電力状態においてカメラシステム部１４０３内の電源がオフである装置の内、アプリケーション通信の実行に必要となる装置だけを選択的に起動する。よって、低消費電力状態からの復帰にかかる時間を短縮することができる。

また、本実施形態では、プロトコル処理部１０７が、カメラシステム部１４０３の起動完了を待たずにアプリケーション通信のＴＣＰコネクションを確立する。よって、カメラシステム部１４０３は起動後直ぐにアプリケーション通信を開始することが可能となる。

（実施形態３）
実施形態３では、クライアント機器からのアプリケーション通信開始要求に応じて、必要ならばアプリケーション機器が、クライアント機器の認証を行って、認証に成功すると低消費電力状態から復帰する例を説明する。なお、実施形態３では、主に実施形態１とは異なる点を説明し、同じ点は説明を省略する。

図１６は、アプリケーション機器の一例を示すブロック図（その２）である。図１６に示されるように、アプリケーション機器１０１は、ネットワーク通信部１０２と、アプリケーションシステム部１０３と、から構成される。

図１６に示される構成は、実施形態１の図３に示した構成と比べて、ネットワーク通信部１０２に、暗号処理部１１５と、鍵管理・認証処理部１１６と、が更に含まれている点が異なる。

ネットワーク通信部１０２の暗号化通信に関する機能は、プロトコル処理部１０７と、暗号処理部１１７と、鍵管理・認証処理部１１８と、によって実現される。暗号化通信セッションの開設のネゴシエーション処理や、暗号化通信プロトコル処理は、プロトコル処理部１０７が実行する。プロトコル処理部１０７は、通信データの暗号化処理や、復号化の計算処理、通信データのメッセージダイジェストの計算処理を、暗号処理部１１７を制御して実行する。また、プロトコル処理部１０７は、クライアント機器の認証に関わる処理や、通信データの暗号化や復号化に使用する鍵データの管理を、鍵管理・認証処理部１１８を制御して実行する。

暗号化処理部１１７は、暗号化通信における通信データの圧縮／伸長、暗号化／復号化のアルゴリズム計算処理や、暗号鍵を使用した通信データのメッセージダイジェストの計算処理を行うハードウェア装置である。また、暗号化処理部１１７は、所定範囲内の乱数を生成する。暗号化処理部１１７が対応可能な暗号化アルゴリズムには、例えばＲＣ２、ＲＣ４、ＤＥＳ、３ＤＥＳ、ＡＥＳ、ＲＳＡ、ＤＨ、ＤＳＳが挙げられる。また、暗号化処理部１１７が対応可能なメッセージダイジェストの計算アルゴリズムには、例えばＭＤ５、ＳＨＡ１が挙げられる。

鍵管理・認証処理部１１８は、暗号化通信の鍵管理や、クライアント機器の認証に関わる複数の処理を実行するハードウェア装置である。まず、鍵管理・認証処理部１１８は、公開鍵暗号方式におけるアプリケーション機器１０１の公開鍵と、秘密鍵との管理、アプリケーション機器１０１自身の電子証明書を管理する。また、鍵管理・認証処理部１１８は、複数の認証処理を実行する。例えば、鍵管理・認証処理部１１８は、クライアント機器の電子証明書を検証し、信頼できる相手であるか否かを判断する認証処理や、クライアント機器のＩＤと、パスワードとで利用権限を認証する認証処理等を行う。更に、鍵管理・認証処理部１１８は、各々の認証処理における各種秘匿情報の管理も行う。また、鍵管理・認証処理部１１８は、各々の暗号化通信セッションで通信の暗号化に使用する共通鍵の生成と、管理とを行う。

ローカルＲＡＭ１０６は、通信制御部１０５や、プロトコル制御部１０７、暗号処理部１１７、鍵管理・認証処理部１１８の処理におけるデータの一時記憶領域に使用される。

なお、本実施形態において、クライアント機器も、図１６に示されるようなネットワーク通信部１０２や、電源制御部１１５等を有する構成であってもよい。

アプリケーション機器１０１のアプリケーション機能は、アプリケーションシステム部１０３で実現される。また、ＣＰＵ１１０で実行されるシステムプログラムは、アプリケーション機能の一部であるアプリケーション通信を行う。アプリケーション通信はＴＣＰ／ＩＰプロトコルを利用した通信である。またアプリケーション通信によっては、暗号化通信を必要とする。ＴＣＰ／ＩＰプロトコル処理と、暗号化通信処理とはネットワーク通信部１０２において実行される。このような通信処理の機能分担について図１７を参照して説明する。

図１７に示す階層モデル４０１において、暗号化通信プロトコルは、トランスポート層と、アプリケーション層４０３との間に位置するセッション層で表される。セッション層は、下位にトランスポート層のプロトコルを使用し、上位層のアプリケーションプロトコルに論理的な通信リンクを提供する。ＳＳＬや、ＴＬＳはセッション層のプロトコルであり、アプリケーション通信の内容を暗号化し、下位層のプロトコルにＴＣＰを利用して信頼性のある送受信を行うための通信リンク（暗号化通信セッション）を開設する。

４０８で示される範囲、即ちネットワーク層プロトコルであるＩＰｖ４、ＩＰｖ６、ＩＣＭＰの処理や、トランスポート層プロトコルであるＵＤＰ、ＴＣＰの処理はプロトコル処理部１０７において実行される。そして、ＳＳＬや、ＴＬＳの暗号化通信処理は、プロトコル処理部１０７と、暗号処理部１１７と、鍵管理・認証処理部１１８とが協調動作して実行される。

次に、低消費電力状態において利用者からのアプリケーション通信の開始要求を受信したときの通信動作の概略を、図１８を参照して説明する。図１８の６０１はアプリケーション機器を表し、図１６におけるアプリケーション機器１０１と一致する。アプリケーション機器６０１は、ネットワーク通信部６０２と、アプリケーションシステム部６０３とで構成しており、それぞれ、図１６のネットワーク通信部１０２と、アプリケーションシステム部１０３とに一致する。説明の簡略化のため、図６との差異の部分のみを説明する。

利用者であるクライアント機器６０４は、アプリケーション機器６０１に対してアプリケーション通信の開始要求６０６を送信する。アプリケーション機器６０１では、ネットワーク通信部６０２がアプリケーション通信の開始要求６０６の受信を行う。ネットワーク通信部６０２は、アプリケーション通信の開始要求を受信すると、クライアント機器６０４との間に通信コネクション６０７を確立する。

開始要求されたアプリケーション通信がクライアント機器６０４の認証を必要とする場合、ネットワーク通信部６０２は、通信コネクション６０７上に暗号化通信セッション６０８を開設する。ネットワーク通信部６０２における認証処理は、暗号化通信セッション６０８の開設時のネゴシエーションのときか、或いは暗号化通信セッション６０８の開設後の暗号化通信のときに実行される。なお、クライアント機器６０４の認証を必要としない場合は、ネットワーク通信部６０２は、暗号化通信セッション６０８を開設（生成）しない。こうしてアプリケーション通信を行うための通信の準備が整うと、ネットワーク通信部６０２は、アプリケーションアプリケーションシステム部６０３に電源を投入する（６０９）。

本実施の形態におけるプロトコル処理部１０７は、第１の実施形態の処理に加えて、アプリケーション通信がクライアント機器の認証が必要なアプリケーション通信か否かを判断する。プロトコル処理部１０７は、クライアント機器の認証が必要なアプリケーション通信であると判断すると、認証方法を決定する。なお、クライアント機器の認証を必要とする場合、何れのアプリケーション通信も暗号化通信となる。プロトコル処理部１０７は、クライアント機器とのＴＣＰコネクションの確立後に、暗号処理部１１７と、鍵管理・認証処理部１１８とを制御して、ＳＳＬ或いはＴＬＳをベースとした暗号化通信セッションの開設処理を実行する。また、プロトコル処理部１０７は、暗号処理部１１７と、鍵管理・認証処理部１１８とを制御して、クライアント機器の認証処理を行う。

また、クライアント機器の認証が必要でない場合或いはクライアント機器の認証が成功した場合、プロトコル処理部１０７は、電源制御部１１５に対して電源制御指示を行う。電源制御部１１５は、前記電源制御指示に基づいて、アプリケーション通信に係るアプリケーションシステム部１０３内のハードウェア装置に電源を投入する。

本実施の形態において、図８に示す項目に加えて、クライアント機器の認証方法に関する項目を加えたデータをテーブルとして保持している。図１９は、対応付けデータテーブルの一例であるテーブル１９０６を示す図（その３）である。図８と同一符号は同一の項目を示している。

図１９において、項目１９０４はアプリケーション通信におけるクライアント機器の認証方法である。

例えば、テーブル１９０６のある欄では、アプリケーション機器１０１が受付けるＴＣＰポート番号が８０である場合、そのアプリケーション通信の内容は、Ｗｅｂブラウジング用のアプリケーション機器１０１を操作するページの転送を示している。また、アプリケーション通信に使用されるプロトコルはＨＴＴＰプロトコルであることを示している。また、項目１９０４を参照すると、このアプリケーション通信はクライアント機器の認証が必要ないことを示している。そして、このアプリケーション通信によって、アプリケーション機器１０１を低消費電力状態から起動するときは、プロトコル処理部１０７が電源制御部１１５に対して、電源制御指示コードの０ｘ４１を設定することを示している。

アプリケーション機器１０１が低消費電力状態であるときのプロトコル処理部１０７の処理を、図２０、図２１、図２２及び図２３を参照しながら説明する。図２０〜図２３は、アプリケーション機器１０１が低消費電力状態であるときのプロトコル処理部１０７の処理フローチャートである。なお、図２０のＳ１０１からＳ１０６までの処理は、図９のＳ８０１からＳ８０６までの処理と同様であるので説明を省略する。

以上の処理において、Ｓ１０８に進んだ場合、プロトコル処理部１０７は、アプリケーション通信の開始要求を受信したと判定する。

Ｓ１０８において、プロトコル処理部１０７は、前記受付けポート番号に基づいて、ローカルＲＡＭ１０６に保持する、図１９に示したような対応付けデータをテーブルから検索し、クライアント機器の認証が必要であるか否かを判断する。プロトコル処理部１０７は、クライアント機器の認証が必要であると判断すると、Ｓ１１０に進み、クライアント機器の認証が必要でないと判断すると、Ｓ１０９に進む。

Ｓ１０９において、プロトコル処理部１０７は、電源制御部１１５に図１９の１９０５で示される電源制御コードの中から、該当する電源制御コードを送信する。電源制御部１１５は、電源制御指示コードに従って、アプリケーションシステム部１０３を構成する１０９から１１４までのハードウェア装置に選択的に電源を投入する処理を実行する。

Ｓ１１０において、プロトコル処理部１０７は、ＴＣＰコネクションの開始要求に対する確認応答のＴＣＰ／ＩＰパケットを作成し、通信制御部１０５を介してアプリケーション通信の要求元であるクライアント機器に送出する。このＴＣＰ／ＩＰパケットは、ＴＣＰヘッダのフラグビットのＳＹＮ（図１２の１１１１）と、ＡＣＫ（図１２の１１０８）とがオンである。また、このＴＣＰ／ＩＰパケットは、応答確認番号（図１２の１１０４）に、受信したＩＰパケットが格納していたＴＣＰパケットのＴＣＰシーケンス番号（図１２の１１０４）の値がセットされている。

なお、Ｓ１１０の処理は、Ｓ１０９においてアプリケーションシステム部１０３へ起動を指示した場合は、アプリケーションシステム部１０３の起動完了を待たずに実行される。

Ｓ１１１は、図２１のＳ２０１へと続き、次のプロトコル処理部１０７の処理は、Ｓ２０２となる。図２１のＳ２０２と、Ｓ２０３とは、プロトコル処理部１０７が、Ｓ１１０においてクライアント機器に送信した確認応答パケットに対して、クライアント機器から送信されるべき確認応答パケットの受信を、予め設定されたタイムアウト時間まで待つ処理である。なお、Ｓ２０３からＳ２０６までの処理は、図９のＳ８１０からＳ８１７までの処理と同様のため説明を省略する。

Ｓ２０２において、クライアント機器からの確認応答パケットを受信すると、クライアント機器とアプリケーション機器１０１との間でＴＣＰコネクションが確立したことになる。そしてＳ２０７において、プロトコル処理部１０７は、Ｓ１０８と同様、開始しようとしているアプリケーション通信がクライアント機器の認証を必要とするか否かを判断する。

プロトコル処理部１０７は、認証が必要であると判断すると、Ｓ２１２に進み、認証が必要でないと判断すると、Ｓ２０８に進む。Ｓ２１２は、図２２のＳ３０１へと続き、次のプロトコル処理部１０７の処理は、Ｓ３０２となる。

Ｓ２０８からＳ２１０までは、プロトコル処理部１０７が、アプリケーションシステム部１０３の起動完了の通知を待ちながら、起動完了までの間にクライアント機器からのパケットを受信したときにアプリケーション通信データを一時保存しておく処理を行う。

アプリケーションシステム部１０３のＣＰＵ１１０は、起動完了を確認すると、プロトコル処理部１０７に対して起動完了した旨の通知（起動完了通知）を行う。Ｓ２０８において、プロトコル処理部１０７は、この起動完了通知を受け取ったか否かを確認する。プロトコル処理部１０７は、起動完了通知を受け取っていないと判定すると、Ｓ２０９に進み、起動完了通知を受け取ったと判定すると、Ｓ２１１に進む。Ｓ２１１は、図２３のＳ４０１へと続き、次のプロトコル処理部１０７の処理は、Ｓ４０２となる。

Ｓ２０９及びＳ２１０の処理は、図９のＳ８１２及びＳ８１３の処理と同様のため説明を省略する。

本実施形態において、クライアント機器の認証方法は、大別して暗号化通信セッションの開設時のネゴシエーションの際に行う場合と、一旦暗号化通信セッションを開設した後に暗号化通信を利用してクライアント機器のユーザ認証を行う場合とに分けられる。

Ｓ３０２において、プロトコル処理部１０７は、クライアント機器と、ＳＳＬ又はＴＬＳの暗号化通信セッションを開設する通信処理を実行する。なお、クライアント機器の認証を暗号化通信セッションの開設時のネゴシエーションにおいて行う場合は、プロトコル処理部１０７は、認証処理も含めて通信処理を実行する。Ｓ３０２において、プロトコル処理部１０７がクライアント機器の認証を行う場合、認証に失敗すると、暗号化通信セッションを開設することはできない。ここで、プロトコル処理部１０７は、図１９に示した対応付けデータに含まれる、該当する認証方法１９０４に基づいて、クライアント機器の認証を暗号化通信セッションの開設時のネゴシエーションにおいて行うか否か判断する。

Ｓ３０３において、プロトコル処理部１０７は、暗号化通信セッションを開設できたか否かを判断する。プロトコル処理部１０７は、暗号化通信セッションを開設できたと判断すると、Ｓ３０６に進み、暗号化通信セッションを開設できなかったと判断すると、Ｓ３０４に進む。Ｓ３０４において、プロトコル処理部１０７は、クライアント機器とのＴＣＰコネクションを終了し、Ｓ３０５に進み、処理を終了する。

一方、Ｓ３０６において、プロトコル処理部１０７は、図１９に示した対応付けデータに含まれる、該当する認証方法１９０４に基づいて、ユーザ認証が必要か否かを判断する。プロトコル処理部１０７は、ユーザ認証の必要があると判断すると、Ｓ３０７に進み、ユーザ認証の必要がないと判断すると、Ｓ３１０に進む。

Ｓ３０７において、プロトコル処理部１０７は、暗号化通信を利用し、クライアント機器に係るユーザのユーザ認証を行う。より具体的に説明すると、プロトコル処理部１０７は、クライアント機器に対して、アプリケーション通信に係るユーザＩＤと、パスワードとを要求する。プロトコル処理部１０７は、クライアント機器からユーザＩＤと、パスワードとを受信すると、鍵管理・認証部１１５に、開始しようとしているアプリケーション通信において、ユーザＩＤと、パスワードとの組でユーザ認証できるか否かを問い合わせる。鍵管理・認証部１１５は、ユーザＩＤと、パスワードとの組でユーザ認証できるか否かの応答を、プロトコル処理部１０７に対して行う。また、鍵管理・認証部１１５は、ユーザ認証できる場合は、ユーザ認証を行い、ユーザ認証が成功したか否かの情報をプロトコル処理部１０７に返す。

Ｓ３０８において、プロトコル処理部１０７は、ユーザ認証できたか否かを判断する。プロトコル処理部１０７は、ユーザ認証できたと判断すると、Ｓ３１０に進み、ユーザ認証できなかったと判断すると、Ｓ３０９に進む。プロトコル処理部１０７は、鍵管理・認証部１１５よりユーザ認証が成功した旨の情報を受け取ると、ユーザ認証できたと判断する。

Ｓ３０９において、プロトコル処理部１０７は、クライアント機器との暗号化通信セッションを終了し、Ｓ３０４に進む。一方、Ｓ３１０において、プロトコル処理部１０７は、プロトコル処理部１０７は、電源制御部１１５に図８の１２０４で示される電源制御コードの中から、該当する電源制御コードを送信する。電源制御部１１５は、電源制御指示コードに従って、アプリケーションシステム部１０３を構成する１０９から１１４までのハードウェア装置に選択的に電源を投入する処理を実行する。

Ｓ８１１からＳ８１３までは、プロトコル処理部１０７が、アプリケーションシステム部１０３の起動完了の通知を待ちながら、起動完了までの間にクライアント機器からのパケットを受信したときにアプリケーション通信データを一時保存しておく処理を行う。

アプリケーションシステム部１０３のＣＰＵ１１０は、起動完了を確認すると、プロトコル処理部１０７に対して起動完了した旨の通知（起動完了通知）を行う。Ｓ３１１において、プロトコル処理部１０７は、この起動完了通知を受け取ったか否かを確認する。プロトコル処理部１０７は、起動完了通知を受け取っていないと判定すると、Ｓ３１２に進む。

Ｓ３１２において、プロトコル処理部１０７は、通信制御部１０５等を介して、クライアント機器から暗号化通信データを受信しているか否かを判断する。プロトコル処理部１０７は、通信制御部１０５等を介して、クライアント機器から暗号化通信データを受信していると判断すると、Ｓ３１３に進む。一方、プロトコル処理部１０７は、通信制御部１０５等を介して、クライアント機器から暗号化通信データを受信していないと判断すると、Ｓ３１１に戻る。

Ｓ３１３において、プロトコル処理部１０７は、暗号処理部１１７を用いて暗号化通信データを復号化してアプリケーション通信データを生成し、ローカルＲＡＭ１０６に記憶しておく。

一方、Ｓ３１１において、プロトコル処理部１０７が、起動完了通知を受け取ったと判定すると、Ｓ３１４に進む。なお、Ｓ３１４は、図２３のＳ４０１へと続き、次のプロトコル処理部１０７の処理は、Ｓ４０２となる。

以上までの処理フローにおいて、図２１のＳ２１１から図２３のＳ４０１に至った場合、アプリケーション機器１０１と、クライアント機器とは、ＴＣＰを利用した非暗号化通信を行う。一方、図２２のＳ３１４から図２３のＳ４０１に至った場合、アプリケーション機器１０１と、クライアント機器とは、ＴＣＰコネクション、及びそのＴＣＰコネクション上の暗号化通信セッションを利用した暗号化通信を行う。

Ｓ４０２からＳ４０９までの処理は、図１０のＳ９０２からＳ９０８までの処理と同様のため説明を省略する。但し、Ｓ４０６において、プロトコル処理部１０７は、クライアント機器と暗号化通信中である場合は、クライアント機器からの暗号化通信データを、暗号処理部１１７を用いて復号化し、アプリケーション通信データを生成する。そして、プロトコル処理部１０７は、生成したアプリケーション通信データをローカルＲＡＭ１０６に記憶する。

次にアプリケーション機器１０１と、クライアント機器との間のアプリケーション通信の開始初期における正常系の送受信シーケンスを、図２４、図２５及び図２６を参照しながら説明する。なお、アプリケーション通信がクライアント機器の認証を必要としない場合の正常系通信のシーケンス図は、図１３と同様である。

図２４は、アプリケーション通信がクライアント機器の認証を必要とし、認証方法として暗号化通信開始後にユーザ認証を行う場合の正常系の通信シーケンス図である。図２４において１６０１はクライアント機器側の時間軸、１６０２はアプリケーション機器１０１側の時間軸を表す。また、１６０３から１６０５までの通信は上述した３ウェイハンドシェイク（１６１６）であり、クライアント機器と、アプリケーション機器１０１との間にＴＣＰコネクションを確立する。

次に１６０６から１６０９までは、クライアント機器からアプリケーション機器１０１に対する、暗号化通信セッションを開設するためのネゴシエーション（１６１７）を表す。アプリケーション機器１０１は、１６０７の"Ｃｅｒｔｉｆｉｃａｔｅ"メッセージで自器の電子証明書をクライアント機器に送信している。クライアント機器は、この電子証明書の検証を行い、アプリケーション機器１０１を信頼できる機器だと認証できれば、残りのネゴシエーションを継続する。

このようにクライアント機器が、アプリケーション機器１０１の電子証明書によって、アプリケーション機器１０１を認証する方法は、ＳＳＬや、ＴＬＳにおいてサーバ認証と呼ばれる。１６１７の暗号化通信セッションの開設のネゴシエーションが完了すると、以降の通信データはすべて暗号化されることになる。

続いてアプリケーション機器１０１は、１６１０でクライアント機器に対して、ユーザＩＤと、パスワードとの送信を要求する。クライアント機器は１６１１でユーザＩＤと、パスワードとを送信する。アプリケーション機器１０１は、受信したユーザＩＤと、パスワードとで認証を実行する。認証が成功すると、アプリケーション機器１０１は、１６１２でユーザ認証完了を通知する。つまり、１６１０から１６１２は、アプリケーション通信に必要なクライアント機器のユーザ認証（１６１８）に係る通信であり、暗号化通信によって実行される。こうしてクライアント機器に対するユーザ認証が成功すれば、クライアント機器は、アプリケーション機器１０１に対し、アプリケーションプロトコルによる通信を始める。１６１３から１６１５までの矢印が示す通信データは、アプリケーション通信（１６１９）を表している。

アプリケーション機器１０１が低消費電力状態において、クライアント機器からアプリケーション通信の開始要求を受信し、クライアント機器のユーザ認証を行ってアプリケーションシステム部１０３を起動する。この場合、１６１６のＴＣＰコネクションを確立する通信と、１６１７の暗号化通信セッション開設時のネゴシエーションの通信と、１６１８のユーザ認証の通信とは、ネットワーク通信部１０２だけで実行される。また、１６１９のアプリケーション通信は、ネットワーク通信部１０２と、アプリケーションシステム部１０３とによって実行される。

図２５は、アプリケーション通信がクライアント機器の認証を必要とし、認証方法としてクライアント機器からの暗号化通信セッション開設のネゴシエーションにおいてクライアント機器を認証する場合の正常系の通信シーケンス図である。図２５において１７０１はクライアント機器側の時間軸、１７０２はアプリケーション機器１０１側の時間軸を表す。また、１７０３から１７０５までの通信は上述した３ウェイハンドシェイク（１７１３）であり、クライアント機器と、アプリケーション機器１０１との間にＴＣＰコネクションを確立する。

次に１７０６から１７０９までは、クライアント機器からアプリケーション機器１０１に対する、暗号化通信セッションの開設するためのネゴシエーション（１７１４）を表す。アプリケーション機器１０１は、１７０７の"Ｃｅｒｔｉｆｉｃａｔｅ"メッセージで自器の電子証明書をクライアント機器に送信している。また、同時に、アプリケーション機器１０１は、"ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔ"メッセージで、電子証明書の送信をクライアント機器に要求している。クライアント機器は、アプリケーション機器１０１の電子証明書の検証を行い、アプリケーション機器１０１を信頼できる機器だと認証できれば、残りのネゴシエーションを継続する。上述したように、この認証はＳＳＬや、ＴＬＳにおけるサーバ認証である。

クライアント機器は、１７０８において"Ｃｅｒｔｉｆｉｃａｔｅ"メッセージで、アプリケーション機器１０１から要求された自器の電子証明書を送信する。また、同時に、クライアント機器は、"ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ"メッセージで、電子証明書を送信した主体者がクライアント機器であることを証明する文字列を送信する。
アプリケーション機器１０１は、１７０８を受信すると、クライアント機器から送信された電子証明書を検証し、クライアント機器が信頼できるクライアント機器としての認証処理を行う。認証できれば、アプリケーション機器１０１は、残りの１７０９の通信を行う。このように、アプリケーション機器１０１がクライアント機器の電子証明書を要求し、送信された電子証明書によってクライアント機器を認証する方法は、ＳＳＬや、ＴＬＳにおいてクライアント認証と呼ばれる。

１７１４の暗号化通信セッション開設のネゴシエーションを完了すると、以降の通信データはすべて暗号化されることになる。そして、クライアント機器は、アプリケーション機器１０１に対してアプリケーションプロトコルによる通信を始める。１７１０から１７１２までの矢印が示す通信データは、アプリケーション通信（１７１５）を表している。

アプリケーション機器１０１が、低消費電力状態において、クライアント機器からアプリケーション通信の開始要求を受信する。そして、アプリケーション機器１０１が、クライアント機器から開始される暗号化通信セッション開設時のネゴシエーションにおいてクライアント機器の認証を行って、アプリケーションシステム部１０３を起動する。この場合、１７１３のＴＣＰコネクションを確立する通信と、１７１４の暗号化通信セッション開設時のネゴシエーションの通信とは、ネットワーク通信部１０２だけで実行される。また、１７１５のアプリケーション通信は、ネットワーク通信部１０２と、アプリケーションシステム部１０３とによって実行される。

図２６は、アプリケーション通信がクライアント機器の認証を必要とし、認証方法としてアプリケーション機器１０１からの暗号化通信セッション開設のネゴシエーションにおいてクライアント機器を認証する場合の正常系通信シーケンスを説明する。図２６において１８０１はクライアント機器側の時間軸、１８０２はアプリケーション機器１０１側の時間軸を表す。また、１８０３から１８０５までの通信は上述した３ウェイハンドシェイク（１８１３）であり、クライアント機器と、アプリケーション機器１０１との間にＴＣＰコネクションを確立する。

次に１８０６から１８０９までは、アプリケーション機器１０１からクライアント機器に対して暗号化通信セッションの開設するためのネゴシエーション（１８１４）を表す。クライアント機器は、１８０７の"Ｃｅｒｔｉｆｉｃａｔｅ"メッセージで自器の電子証明書をアプリケーション機器１０１に送信している。アプリケーション機器１０１は、この電子証明書の検証を行い、クライアント機器を信頼できるクライアント機器だと認証できれば、残りのネゴシエーションを継続する。上述したように、この認証はＳＳＬや、ＴＬＳにおけるサーバ認証である。

１８１４の暗号化通信セッション開設のネゴシエーションを完了すると、以降の通信データはすべて暗号化されることになる。クライアント機器は、アプリケーション機器１０１に対してアプリケーションプロトコルによる通信を始める。１８１０から１８１２までの矢印が示す通信データは、アプリケーション通信（１８１５）を表している。

アプリケーション機器１０１は、低消費電力状態において、クライアント機器からアプリケーション通信の開始要求を受信し、クライアント機器の認証を暗号化通信セッションの開設時のネゴシエーションで行う。そして、アプリケーション機器１０１は、アプリケーションシステム部１０３を起動する。この場合、１７１３のＴＣＰコネクションを確立する通信と、１７１４の暗号化通信セッション開設時のネゴシエーションの通信は、ネットワーク通信部１０２だけで実行される。また、１７１５のアプリケーション通信は、ネットワーク通信部１０２とアプリケーションシステム部１０３によって実行される。

アプリケーション機器１０１が、低消費電力状態において、クライアント機器からアプリケーション通信の開始要求を受信する。そして、アプリケーション機器１０１から開始する暗号化通信セッション開設時のネゴシエーションにおいてクライアント機器の認証を行って、アプリケーションシステム部１０３を起動する。この場合、１８１３のＴＣＰコネクションを確立する通信と、１８１４の暗号化通信セッション開設時のネゴシエーションの通信とは、ネットワーク通信部１０２だけで実行される。また、１８１５のアプリケーション通信は、ネットワーク通信部１０２と、アプリケーションシステム部１０３とによって実行される。

なお、図２６において１８１３のＴＣＰコネクションの確立後、直ぐにアプリケーション機器１０１からクライアント機器に対して暗号化通信セッション開設のネゴシエーションを開始している。しかし、先にクライアント機器が暗号化通信を要求する通知を送信し、その通知をトリガとして、アプリケーション１０１が、クライアント機器への暗号化通信セッション開設のネゴシエーションを開始してもよい。

本実施形態によれば、アプリケーション機器１０１がアプリケーション通信を実行しない間、ネットワーク通信部１０２を動作させ、アプリケーションシステム部１０３の電源制御部１１５を除くハードウェア装置の電源をオフにして低消費電力状態を実現する。

また、アプリケーション機器１０１がアプリケーション通信を実行しない間でも、ネットワーク通信部１０２を動作させているので、クライアント機器からアプリケーション通信要求を受付けることが可能となる。

また、本実施形態によれば、アプリケーション通信の開始要求を、ＴＣＰ通信コネクションを開始する宛先ポート番号がアプリケーション通信毎の受付けポート番号の何れかであるＴＣＰパケットを受信した場合としている。よって、クライアント機器の認証を必要としない場合、標準的なＴＣＰ／ＩＰプロトコル通信で、アプリケーション機器１０１の遠隔起動を実現することができ、特別な手段を設ける必要がない。

一方、クライアント機器の認証を必要とする場合、ネットワーク通信部１０２が、暗号化通信セッションを開設してクライアント機器を認証し、認証が成功したときにアプリケーションシステム部１０３に電源を投入する。よって、アプリケーション通信を開始要求するクライアント機器を認証できない場合は、アプリケーション機器１０１の低消費電力状態をそのまま継続することができるため、より効率的に省電力効果を得ることができる。

（実施形態４）
本実施形態は、実施形態３で示したアプリケーション機器１０１の一例としてネットワークカメラ１４０１を適用した例である。なお、実施形態４では、主に実施形態２とは異なる点を説明し、同じ点は説明を省略する。

図２７は、ネットワークカメラの一例を示すブロック図（その２）である。図２７に示されるように、ネットワークカメラ１４０１は、ネットワーク通信部１０２と、カメラシステム部１４０３と、から構成される。

図２７に示される構成は、実施形態２の図１４に示した構成と比べて、ネットワーク通信部１４０２に、暗号処理部１１７と、鍵管理・認証処理部１１８と、が更に含まれている点が異なる。

図２８は、プロトコル処理部１０７が保持する対応付けデータを示すテーブル２００７の一例を示す図（その４）である。

図２８において、図１９と同一の符号は同一の項目を示している。

例えば２００７のテーブルでは、ネットワークカメラ１４０１が受付けるＴＣＰポート番号が５９６３の場合、そのアプリケーション通信の内容は、ネットワークカメラ１４０１が撮影する映像のストリーミング配信と、遠隔カメラ操作とであることを示している。また、ストリーミング配信と、遠隔カメラ操作とに使用するアプリケーションプロトコルは、独自アプリケーションプロトコルであることを示している。また、２００７のテーブルでは、このアプリケーション通信を実行するには、クライアント機器の認証が必要であって、認証方法はＳＳＬや、ＴＬＳにおけるクライアント認証であることを示している。

更に、２００７のテーブルでは、ＴＣＰポート番号が５９６３の場合、ネットワークカメラ１４０１が低消費電力状態から起動するときは、プロトコル処理部１０７が電源制御部１１５に対して、電源制御指示コード０ｘ８１を設定する。なお、電源制御指示コード０ｘ８１によって、電源制御部１４１６が電源を投入して起動させるハードウェア装置は、例えば、システムバス１４０９、ＣＰＵ１４１１、ＲＯＭ１４１１、ＲＡＭ１４１２、撮像部１４１４、エンコーダ１４１５である。

以上、上述した各実施形態によれば、消費電力を節約すると共に、簡単な構成で、ネットワークを介して接続された他の装置からの要求に応じて、低消費電力状態からの復帰を安全に行うことができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

ＭａｇｉｃＰａｃｋｅｔ（登録商標）における特定のデータ列の形式を示す図である。ＭａｇｉｃＰａｃｋｅｔ（登録商標）におけるＵＤＰ／ＩＰパケットを示す図である。アプリケーション機器の一例を示すブロック図（その１）である。通信処理の機能分担を示す図（その１）である。アプリケーション機器の消費電力の通常状態と、低消費電力状態との状態遷移図である。アプリケーション機器が低消費電力状態において利用者等からアプリケーション通信の開始要求を受信したときの動作の概略を示す図（その１）である。イーサネット（登録商標）プロトコル通信におけるデータフレーム形式を表す図である。対応付けデータの一例を示す図（その１）である。アプリケーション機器が低消費電力状態であるときのプロトコル処理部の処理の一例を示すフローチャート（その１）である。アプリケーション機器が低消費電力状態であるときのプロトコル処理部の処理の一例を示すフローチャート（その２）である。ＩＰパケットのパケットデータ形式を示す図である。ＴＣＰパケットデータ形式を示す図である。アプリケーション機器と、クライアント機器との間のアプリケーション通信の開始初期における正常系の送受信シーケンスを示す図（その１）である。ネットワークカメラの一例を示すブロック図（その１）である。対応付けデータの一例を示す図（その２）である。アプリケーション機器の一例を示すブロック図（その２）である。通信処理の機能分担を示す図（その２）である。アプリケーション機器が低消費電力状態において利用者等からアプリケーション通信の開始要求を受信したときの動作の概略を示す図（その２）である。対応付けデータの一例を示す図（その３）である。アプリケーション機器が低消費電力状態であるときのプロトコル処理部の処理の一例を示すフローチャート（その３）である。アプリケーション機器が低消費電力状態であるときのプロトコル処理部の処理の一例を示すフローチャート（その４）である。アプリケーション機器が低消費電力状態であるときのプロトコル処理部の処理の一例を示すフローチャート（その５）である。アプリケーション機器が低消費電力状態であるときのプロトコル処理部の処理の一例を示すフローチャート（その６）である。アプリケーション機器と、クライアント機器との間のアプリケーション通信の開始初期における正常系の送受信シーケンスを示す図（その２）である。アプリケーション機器と、クライアント機器との間のアプリケーション通信の開始初期における正常系の送受信シーケンスを示す図（その３）である。アプリケーション機器と、クライアント機器との間のアプリケーション通信の開始初期における正常系の送受信シーケンスを示す図（その４）である。ネットワークカメラの一例を示すブロック図（その２）である。対応付けデータの一例を示す図（その４）である。

符号の説明

１０１アプリケーション機器
１０２ネットワーク通信部
１０３アプリケーションシステム部
１１５電源制御部
１４０１ネットワークカメラ
１４０２ネットワーク通信部
１４０３カメラシステム部

Claims

ネットワークを介して接続された他の装置との通信を行う通信部と、
アプリケーション機能を実行するためのアプリケーションシステム部と、
前記他の装置からのＴＣＰパケットのヘッダに含まれるフラグビットフィールドにおいてＳＹＮフラグのみがオンであり、かつ、該ＴＣＰパケットの宛先ポート番号が前記アプリケーションシステム部において実行されるアプリケーション通信の受付ポート番号と一致していることを判定することにより、前記アプリケーションシステム部において実行されるアプリケーション通信のためのコネクション確立のための、前記アプリケーション通信の開始要求を検出する検出手段と、
前記アプリケーションシステム部が低消費電力状態のときに、前記他の装置からの前記アプリケーションシステム部において実行されるアプリケーション通信の開始要求を前記検出手段において検出すると、前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させる制御手段と、
を有することを特徴とするアプリケーション装置。
前記アプリケーション通信に対応する受付ポート番号を管理する管理手段を有することを特徴とする請求項１に記載のアプリケーション装置。
前記アプリケーション通信に対応する受付ポート番号と、当該アプリケーション通信の開始要求が検出されたときに前記アプリケーションシステム部を通常状態に復帰させる際の電源制御指示コードとを対応させて管理する管理手段を有し、
前記制御手段は、前記他の装置から受信したＴＣＰパケットの宛先ポート番号に対応する電源制御指示コードにより前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させることを特徴とする請求項１に記載のアプリケーション装置。
前記制御手段は、前記開始要求に応じた認証方法に基づいて認証を行って、前記認証が成功すると、前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させることを特徴とする請求項２又は３に記載のアプリケーション装置。
前記検出手段により前記アプリケーション通信の開始要求が検出された場合に、前記他の装置を認証するか否かを判定する判定手段を有し、
前記判定手段により前記他の装置を認証しないと判定した場合は、前記制御手段は、前記他の装置を認証することなく前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させ、前記他の装置を認証すると判定した場合は、前記他の装置を認証できると前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させることを特徴とする請求項２又は３に記載のアプリケーション装置。
前記通信部は、前記制御手段により前記アプリケーションシステム部を低消費電力状態から通常状態への復帰を指示してから前記アプリケーションシステム部の前記通常状態への復帰完了までの間に受信した、前記アプリケーション通信のデータを記憶する記憶手段と、
前記アプリケーションシステム部の前記通常状態への復帰が完了すると、前記記憶手段に記憶した前記アプリケーション通信のデータを前記アプリケーションシステム部に転送する転送手段と、を有することを特徴とする請求項１乃至５のいずれか１項に記載のアプリケーション装置。
ネットワークを介して接続された他の装置との通信を行う通信部と、アプリケーション機能を実行するためのアプリケーションシステム部と、を有するアプリケーション装置の電力の復帰方法であって、
前記他の装置からのＴＣＰパケットのヘッダに含まれるフラグビットフィールドにおいてＳＹＮフラグのみがオンであり、かつ、該ＴＣＰパケットの宛先ポート番号が前記アプリケーションシステム部において実行されるアプリケーション通信の受付ポート番号と一致していることを判定することにより、前記アプリケーションシステム部において実行されるアプリケーション通信のためのコネクション確立のための、前記アプリケーション通信の開始要求を検出する検出工程と、
前記アプリケーションシステム部が低消費電力状態のときに、前記他の装置からの前記アプリケーションシステム部において実行されるアプリケーション通信の開始要求を前記検出工程において検出すると、前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させる制御工程と、
を有することを特徴とするアプリケーション装置の電力の復帰方法。