通信装置であって、ネットワークを介して接続された他の装置と通信を行う通信部と、アプリケーション機能を実行するためのアプリケーションシステム部と、を有し、前記通信部は、前記通信装置宛のARPパケットを受信した場合、当該ARPパケットを送信した他の装置に、前記アプリケーションシステム部を介すことなく応答を送信し、前記通信装置宛のARPパケットとは異なる所定の種別のパケットを受信した場合、前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させるための処理を行うことを特徴とする通信装置。前記アプリケーションシステム部が低消費電力状態である際に、前記通信装置宛のARPパケットを受信すると、前記通信部が、当該ARPパケットを送信した他の装置に応答を送信することを特徴とする請求項1に記載の通信装置。前記所定の種別のパケットとは、前記アプリケーションシステム部における通信の開始を要求するTCP/IPパケットであることを特徴とする請求項1または2に記載の通信装置。前記他の装置からのパケットが、前記通信装置宛であるか否かを判定する判定手段を更に有することを特徴とする請求項1乃至3のいずれか1項に記載の通信装置。ネットワークを介して接続された他の装置と通信を行う通信部と、アプリケーション機能を実行するためのアプリケーションシステム部と、を有する通信装置の電力の復帰方法であって、前記通信部が、前記通信装置宛のARPパケットを受信した場合、当該ARPパケットを送信した他の装置に、前記アプリケーションシステム部を介すことなく応答を送信する工程と、前記通信部が、前記通信装置宛のARPパケットとは異なる所定の種別のパケットを受信した場合、前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させるための処理を行う工程とを有することを特徴とする通信装置の電力の復帰方法。しかしながら、WOLでは、ネットワークを介して、アプリケーション機器を起動させる側の装置等が、特定のデータ列を含むデータセグメントを生成する手段を有する必要があった。このため、遠隔起動させることができる装置が限定される。例えば、MagicPacket登録商標の場合、遠隔起動させる側の装置が、遠隔起動の対象であるアプリケーション機器のMACアドレスを予め記憶しておく必要がある。更に、遠隔起動を指示する装置が、図1の201に示されるデータ形式の送信データセグメントを生成する手段を有していなければならない。また、WOLでは、アプリケーション機器を起動させる側の装置等が、アプリケーション機器が通常動作中消費電力状態か、または低消費電力状態かを考慮して通信を行う必要がある。本発明は上記の問題点に鑑みなされたもので、消費電力を節約すると共に、簡単な構成で、ネットワークを介して接続された他の装置からの要求に応じて、低消費電力状態からの復帰を安全に行うことを目的とする。そこで、上記問題を解決するため、本発明の通信装置は、ネットワークを介して接続された他の装置と通信を行う通信部と、アプリケーション機能を実行するためのアプリケーションシステム部と、を有し、前記通信部は、前記通信装置宛のARPパケットを受信した場合、当該ARPパケットを送信した他の装置に、前記アプリケーションシステム部を介すことなく応答を送信し、前記通信装置宛のARPパケットとは異なる所定の種別のパケットを受信した場合、前記アプリケーションシステム部を低消費電力状態から通常状態へと復帰させるための処理を行うことを特徴とする。本発明によれば、アプリケーションシステム部を低消費電力状態から通常状態へと復帰させるための処理を行う通信部が、ARPパケットに対してはアプリケーションシステム部を介すことなく応答するので、省電力とすることができる。以下、本発明の実施形態について図面に基づいて説明する。実施形態1図3は、アプリケーション機器の一例を示すブロック図その1である。図3に示されるように、アプリケーション機器101は、そのハードウェア構成として、ネットワーク通信部102と、アプリケーションシステム部103と、からなる。ネットワーク通信部102のローカルバス104には、通信制御部105、ローカルRAM106、プロトコル処理部107が接続されている。なお、ネットワーク116は、例えばイーサネット登録商標が想定できるが、無線ネットワークや、光ファイバーネットワーク等であってもよい。また、ネットワーク116は、アプリケーション機器101の利用者が遠隔地からTCP/IPプロトコルを用いてアプリケーション通信を行えるものとする。通信制御部105は、ネットワーク116に対して伝送フレームの送受信を行う。例えばネットワーク116がイーサネット登録商標の場合、通信制御部105は、イーサネット登録商標のMAC処理伝送メディア制御処理や、イーサネット登録商標フレームの送受信を行う。プロトコル処理部107は、通信プロトコル処理専用のハードウェア回路装置、或いは通信プロトコル処理用に設計されたマイクロプロセッサであり、汎用的なTCP/IPプロトコルの通信処理を行う。より具体的には、プロトコル処理部107は、IPv4IPバージョン4、IPv6IPバージョン6、ICMP、UDP、TCPの各通信プロトコル処理や、送信フロー制御や輻輳制御、通信エラー制御等を行う。また、プロトコル処理部107は、電源制御部115と制御信号線で接続されており、電源制御部115の動作制御を行う。ローカルRAM106は、通信制御部105やプロトコル制御部107の処理におけるデータの一時記憶領域に使用される。また、ネットワーク通信部102は、ローカルバス104と、アプリケーションシステム部103のシステムバス109との間のデータ転送を可能とするバスブリッジ回路108を有する。即ち、ネットワーク通信部102と、アプリケーションシステム部103とは、それぞれのバス回路が相互に接続されており、通信データの入出力においてバス転送が行われる仕組みになっている。アプリケーションシステム部103のシステムバス109には、CPU110、システムプログラムが格納されているROM111、システムプログラム実行時に使用される一時記憶装置であるRAM112、が接続されている。なお、ROM111からRAM112にシステムプログラムが読み込まれ、CPU110によって実行される。また、同じくシステムバス109に接続されているアプリケーション機能A113やアプリケーション機能部B114は、アプリケーション機器101の特徴的なアプリケーション機能を実現するために使用されるハードウェア処理装置を表している。電源制御部115は、ネットワーク通信部102及びアプリケーションシステム部103の電力供給を独立的に制御する電源制御部である。電源制御部115は、109から114までの各装置に対して、電源投入の制御、ハードウェアリセット制御、アプリケーションシステム部103全体が保持データの破損なく安全に電源をオフにするための停止処理を開始する指示制御等を行う。CPU110は、アプリケーション機器101の各装置の機能を制御したり、システムプログラムに基づいてアプリケーション処理を実行したりする。RAM112は、CPU110によるプログラム実行のための一時記憶領域、またネットワーク通信部102や、アプリケーション機能部113、114が使用する入出力データ領域として使用される。アプリケーション機器101のアプリケーション機能は、アプリケーションシステム部103で実現される。また、CPU110で実行されるシステムプログラムは、アプリケーション機能の一部であるアプリケーション通信を行う。アプリケーション通信は、TCP/IPプロトコルをベースとした通信であり、TCP/IPプロトコル処理はネットワーク通信部102において実行される。このような通信処理の機能分担を、図4を参照して説明する。図4において、401はTCP/IPプロトコルの階層モデルである。下位層よりリンク層、ネットワーク層、トランスポート層、アプリケーション層403の4つに分類される。リンク層のプロトコルは、一般的な有線LANにおけるイーサネット登録商標、IEEE802.11b/a/gで規格化されている無線LAN等、物理ネットワークの通信プロトコルである。ネットワーク層のプロトコルとしては、IPv4、IPv6、ICMP、IGMPが挙げられる。トランスポート層のプロトコルとしては、UDP、TCPが挙げられる。アプリケーション層403には、インターネットにおいて標準的に利用するアプリケーションプロトコルであるHTTP、FTP、SMTP、RTP、RTCP等が挙げられる。また、TCP/IPでは独自に定義したアプリケーション層プロトコルによる通信が実施されることも多い。ネットワーク通信部102は、402に示す範囲のリンク層、ネットワーク層、トランスポート層のプロトコル処理を実現するものである。また、アプリケーションシステム部103が実行するアプリケーション通信は、403のアプリケーション層のプロトコル処理を行う。図4の405は、アプリケーション機器101が実行する通信処理を、401のTCP/IPプロトコルの階層モデルに対応付けて階層的に表している。ネットワーク通信部102が実行する処理は、図4の405に示す範囲の処理である。その中で、407で示される範囲、即ち以下の3つの処理は、通信制御部105において実行される。MACメディアアクセス制御装置としてのネットワーク116の物理媒体に対する伝送制御処理MAC制御を行うMACドライバの処理IPアドレスとMACアドレスとの対応付けを解決するためのプロトコルであるARPプロトコルの処理また、408で示される範囲、即ちネットワーク層プロトコルであるIPv4、IPv6、ICMPの処理や、トランスポート層プロトコルであるUDP、TCPの処理は、プロトコル処理部107において実行される。一方、アプリケーションシステム部103が実行する処理は、406の範囲であり、アプリケーション機器101のアプリケーション通信で使用する全てのアプリケーション層プロトコル処理である。404に示すTCP/IP通信の分担処理によって、アプリケーション機器101のアプリケーション通信は、アプリケーションシステム部103がネットワーク通信部102の通信機能を利用して実現する。以上のような実施構成において、アプリケーション機器101がアプリケーション層のプロトコルを用いて通信を実行している状態では、少なくともネットワーク通信部102、システムバス109、CPU110、ROM111、RAM112、電源制御部115が動作している。このときの消費電力の状態を、消費電力の通常状態と呼ぶものとする。通常状態では、アプリケーションシステム部103内のその他の装置であるアプリケーション機能部A113や、アプリケーション機能部B114が動作する場合には消費電力が上昇し、動作しない場合にはそれらの分の消費電力が抑えられる。上述したように、アプリケーションシステム部の109から114までのハードウェア装置への電力供給の制御が、電源制御部115によってなされている。一方、アプリケーション通信を実行しない期間は、アプリケーション機器101は、アプリケーションシステム部103内の109から114までのハードウェア装置の電源をオフにして動作を停止する。そして、アプリケーション機器101は、ネットワーク通信部102と、電源制御部115とだけを動作させておく。このことによって、アプリケーション機器101は、消費電力を大きく低減させる低消費電力状態にすることができる。図5は、アプリケーション機器101の消費電力の通常状態と、低消費電力状態との状態遷移図である。501は消費電力の通常状態を表し、502は低消費電力状態を表す。消費電力の通常状態では、アプリケーション通信を実行中のとき503そのまま通常状態を維持する。そして、全てのアプリケーション通信が終了してからアプリケーション機器101のROM111等に予め設定されたある一定時間が経過した場合504、低消費電力状態502に移行する。或いは、アプリケーション機器101が初めて電源を投入された初期起動処理後、ROM111等に予め設定されたある一定時間内にアプリケーション通信が1つも実行されていない場合にも、低消費電力状態502に移行する。一方の502の低消費電力状態では、アプリケーション機器101に利用者からのアプリケーション通信の開始要求を受信したとき505に、消費電力の通常状態501に移行する。次に、アプリケーション機器101が低消費電力状態においてクライアント機器等からアプリケーション通信の開始要求を受信したときの動作の概略を、図6を参照して説明する。図6の601はアプリケーション機器を表し、図3におけるアプリケーション機器101と一致する。アプリケーション機器601は、ネットワーク通信部602と、アプリケーションシステム部603とで構成されており、それぞれ、図3のネットワーク通信部102と、アプリケーションシステム部103とに一致する。アプリケーション機器601は、クライアント機器604で表されており、アプリケーション機器601との間にはネットワーク経路605が存在している。605のネットワーク経路はLAN、又はLAN間をWANで経由したネットワーク、更にインターネットを経由することがあってもよい。利用者であるクライアント機器604は、アプリケーション機器601に対してアプリケーション通信の開始要求606を送信する。アプリケーション機器サーバ機器601では、ネットワーク通信部602がアプリケーション通信の開始要求606の受信を行う。ネットワーク通信部602は、アプリケーション通信の開始要求606を受信すると、クライアント機器604に確認応答607を送信すると共に、アプリケーションシステム部603に電源を投入する609。次に、アプリケーション機器101の低消費電力状態において、ネットワーク通信部102における通信処理について説明する。まず、ネットワーク通信部102は、ネットワーク116へ能動的にフレームを送信する又は通信することは行わない。即ち、ネットワーク116から到着するデータフレームの受信処理を行い、フレームの送信が必要である場合において送信を行う。以下、ネットワーク116がイーサネット登録商標である場合を例に挙げて説明する。通信制御部105は、ネットワーク116イーサネット登録商標を流れるフレームの中で、宛て先アドレスが自装置のMACアドレス、或いはブロードキャストアドレスのフレームだけを受信してローカルRAM106に書き込む。その後、通信制御部105は、受信フレームのフレームヘッダを解析し、フレームが格納するデータの通信プロトコルを調べる。図7は、イーサネット登録商標プロトコル通信におけるデータフレーム形式を表す図である。図7の701は宛先アドレス、702は送信元のアドレスを表す。続く703は、上位層のプロトコルを区別するタイプID識別子を示し、704は、フレームが運ぶデータである。703のタイプIDの値は、704のデータがIPパケットの場合は0x0800、704のデータがARPプロトコルのパケットの場合は0x0806が設定される。フレームの最後には4バイトのFCSFrameCheckSequenceが格納される。FCSは、701の宛先アドレスから704のデータまでにビット誤りが発生していないかを検出する為に付与されるCRCCyclicRedundancyCheckコードである。したがって、通信制御部105は、受信フレームのヘッダを解析し、図7の703に示すイーサネット登録商標ヘッダのタイプフィールドが0x0800であれば、IPプロトコルであるのでプロトコル処理部107に受信処理を開始させる。イーサネット登録商標ヘッダのタイプフィールドが、0x0806であれば、ARPパケットを受信したことになり、ARPパケットの解析を行う。通信制御部105は、ARPパケットを受信した場合、ARPパケットが自アプリケーション機器101のIPアドレス対応するMACアドレスを尋ねるARPリクエストであるならば、以下の処理を行う。つまり、通信制御部105は、ARPリクエストの送信元に自装置のMACアドレスを返答するため、ARPリプライパケットを作成しネットワーク116に送信する。一方、ARPパケットが自アプリケーション機器101のIPアドレス対応するMACアドレスを尋ねるARPリクエストでなければ、通信制御部105は、ARPパケットを破棄して何も処理を行わない。次に、アプリケーション機器101が低消費電力状態であるときのプロトコル処理部107の処理について説明する。通信制御部105によって受信したフレームデータが、ローカルRAM106に記憶され、更にIPパケットを含むと判定された場合、プロトコル処理部107は、通信制御部105から処理開始指示の通知を受け取って、処理を開始する。プロトコル処理部107の主な役割は、受信IPパケットが、アプリケーション層におけるアプリケーション通信の開始要求であるならば、電源制御指示を行い、アプリケーションシステム部102を低消費電力状態から復帰させ、アプリケーション通信を開始できるようにすることである。プロトコル処理部107は、ネットワーク116から受信するフレームデータが、以下の条件1~3を全て満たす場合、アプリケーション機器101が提供しているアプリケーション通信の開始要求であると判定する。条件1:アプリケーション機器101宛てのTCPパケットである。条件2:TCPコネクション開始要求のTCPパケットである。条件3:TCPパケットの宛先ポート番号がアプリケーション通信の受付けポート番号に一致する。そして、プロトコル処理部107は、宛先ポート番号によって、アプリケーション機器101が提供するアプリケーション通信の何れの開始要求であるかを判断する。またプロトコル処理部107は、アプリケーション機器101の低消費電力状態において、アプリケーション通信を行うために起動する必要があるアプリケーションシステム部103内の装置に電源を投入するため、電源制御部115に対して電源制御指示を行う。このために、プロトコル処理部107は、ローカルRAM106に、アプリケーション通信と、その受付けTCPポート番号と、電源制御部115への電源制御指示コードとの対応付けデータを保持している。図8は、対応付けデータの一例を示す図その1である。図8において、1201の列は受付けTCPポート番号である。1202の列はTCPポート番号に対応するアプリケーション通信の内容である。1203の列はアプリケーション通信のアプリケーションプロトコル名である。1204の列は電源制御部115に対する電源制御指示コードである。例えば、テーブル1205において、ある欄では、アプリケーション機器101が受付けるTCPポート番号が80であり、そのアプリケーション通信の内容は、Webブラウジング用にアプリケーション機器101の操作ページの転送を示している。また、アプリケーション通信に使用されるプロトコルはHTTPプロトコルであることを示している。そして、このアプリケーション通信によって、アプリケーション機器101を低消費電力状態から起動するときは、プロトコル処理部107が電源制御部115に対して、電源制御指示コードの0x41を設定することを示している。アプリケーション機器101が低消費電力状態であるときのプロトコル処理部107の処理を、図9、図10、図11及び図12を参照しながら説明する。図9及び図10は、アプリケーション機器101が低消費電力状態であるときのプロトコル処理部107の処理の一例を示すフローチャートである。また、図11は、IPパケットのパケットデータ形式を示す図である。図12はTCPパケットデータ形式を示す図である。プロトコル処理部107の処理は、図9のS801から始まり、まずS802において、受信したIPパケットヘッダを解析し、宛先IPアドレスが、アプリケーション機器101に設定されている自IPアドレスに一致しているか否かを調べる。宛先IPアドレスが一致していない場合、また例えばブロードキャストされたIPパケットのような場合、プロトコル処理部107は、S806に進み、受信したIPパケットを破棄して終了する。ここでIPパケットは、図11に示す形式になっており、プロトコル処理部107は、受信パケットの宛先IPアドレスを、1010のフィールドを調べることによって確認する。プロトコル処理部107は、宛先IPアドレスが自IPアドレスと一致する場合は、S803に進み、受信したIPパケットのデータがTCPパケットか否かを調べる。プロトコル処理部107は、IPパケットのデータがTCPパケットか否かを、受信IPパケットにおいて図11の1009が示すフィールドの値を検査することによって調べる。本実施の形態において、プロトコル処理部107は、図11の1009が示すフィールドの値が6の場合、IPパケットのデータがTCPパケットであると判定する。S803において、プロトコル処理部107は、IPパケットのデータがTCPパケットであると判定するとS804に進み、IPパケットのデータがTCPパケットでないと判定するとS806に進み、受信したIPパケットを破棄して処理を終了する。S804において、プロトコル処理部107は、TCPパケットのTCPヘッダを解析する。つまり、プロトコル処理部107は、図12の1107から1112で示されるフラグビットフィールドを調べる。プロトコル処理部107は、フラグのSYN1111がオンであり、他のフラグビットであるURG1107、ACK1108、PSH1109、RST1110、FIN1112がオフであるならば、S805に進む。つまり、プロトコル処理部107は、TCPコネクションの開始要求であると判断する。プロトコル処理部107は、フラグのSYN1111だけがオンな訳ではないつまり、例えば他のフラグもオンである等と判定すると、無効なTCPパケットであると判断し、S806において受信したIPパケットを破棄して処理を終了する。S805において、プロトコル処理部107は、TCPパケットの宛先ポート番号が、アプリケーション機器サーバ装置101が提供するアプリケーション通信の受付けポート番号であるか否かを調べる。プロトコル処理部107は、ローカルRAM106に保持する、図8に示したような対応付けデータの中に、宛先ポート番号に一致する受付けポート番号があるかを検索することによって調べる。プロトコル処理部107は、宛先ポート番号が、受付け可能なポート番号と一致したならばS807に進み、受付け可能なポート番号と一致しなかったらS806に進み、受信したIPパケットを破棄して処理を終了する。以上までの処理フローにおいて、S807に進んだ場合、プロトコル処理部107は、アプリケーション通信の開始要求を受信したと判定する。そして、S807において、プロトコル処理部107は、電源制御部115に図8の1204で示される電源制御コードの中から、該当する電源制御コードを送信する。電源制御部115は、電源制御指示コードに従って、アプリケーションシステム部103を構成する109から114までのハードウェア装置に選択的に電源を投入する処理を実行する。プロトコル処理部107は、S807でアプリケーションシステム部103の起動を指示すると、起動完了を待たず、S808において、TCPコネクションの開始要求に対する確認応答のTCP/IPパケットを作成する。そして、プロトコル処理部107は、作成した確認応答用のTCP/IPパケットを、通信制御部105を介してアプリケーション通信の要求元であるクライアント機器に送出する。この確認応答用のTCP/IPパケットは、TCPヘッダのフラグビットのSYN図12の1111と、ACK図12の1108とがオンである。また、このTCP/IPパケットは、応答確認番号図12の1104に、受信したIPパケットが格納していたTCPパケットのTCPシーケンス番号図12の1104の値がセットされている。S809と、S810とは、プロトコル処理部107が、クライアント機器に送信した確認応答パケットに対して、クライアント機器から送信されるべき確認応答パケットの受信を、予め設定されたタイムアウト時間まで待つ処理である。プロトコル処理部107は、S809では確認応答を待ち、S810では受信を待っている時間がタイムアウトしているか否かを調べる。プロトコル処理部107は、もしタイムアウト期限時間内にクライアント機器からの確認応答を受信できなかった場合には、S814に進み、受信できた場合にはS811に進む。S814において、プロトコル処理部107は、TCPコネクションの強制終了を行う。つまり、プロトコル処理部107は、クライアント機器に対して、コネクションの中断のため、TCPヘッダのフラグビットのRST図12の1110がオンであるTCP/IPパケットを作成し、通信制御部105からネットワーク116に送出する。こうして、プロトコル処理部107は、クライアント機器から要求されたアプリケーション通信の開始要求を取り消す。S815において、プロトコル処理部107は、アプリケーションシステム部103を再び低消費電力状態に移行するよう、電源制御部115に電源制御指示を電源制御部115に送信する。電源制御部115は、前記指示を受け取ると、アプリケーションシステム部103に対して、全体の電源をオフにして停止させる処理の開始指示を送信する。この指示を受け取ると、アプリケーションシステム部103は、アプリケーション機器101の低消費電力状態からの復帰動作中であっても、即時にシステムの停止処理を開始し、電源をオフにする。S811からS813までは、プロトコル処理部107が、アプリケーションシステム部103の起動完了の通知を待ちながら、起動完了までの間にクライアント機器からのパケットを受信したときにアプリケーション通信時のデータを一時保存しておく処理を行う。アプリケーションシステム部103のCPU110は、起動完了を確認すると、プロトコル処理部107に対して起動完了した旨の通知起動完了通知を行う。S811において、プロトコル処理部107は、この起動完了通知を受け取ったか否かを確認する。プロトコル処理部107は、起動完了通知を受け取っていないと判定すると、S812に進む。S812において、プロトコル処理部107は、通信制御部105等を介して、クライアント機器からアプリケーション通信パケットを受信しているか否かを判断する。プロトコル処理部107は、通信制御部105等を介して、クライアント機器からアプリケーション通信パケットを受信していると判断すると、S813に進む。一方、プロトコル処理部107は、通信制御部105等を介して、クライアント機器からアプリケーション通信パケットを受信していないと判断すると、S811に戻る。S813において、プロトコル処理部107は、アプリケーション通信データをローカルRAM106に記憶しておく。一方、S811において、プロトコル処理部107が、起動完了通知を受け取ったと判定すると、S816に進む。なお、S816は、図10のS901へと続き、次のプロトコル処理部107の処理は、S902となる。S902において、プロトコル処理部107は、アプリケーションシステム部103に対して、どのアプリケーション通信を開始するべきかを通知する。より具体的に説明すると、プロトコル処理部107は、CPU110で動作するシステムプログラムに、図8の1202と、1203とで示されるアプリケーション通信の内容種類及び使用するアプリケーションプロトコルを通知する。CPU110で動作するシステムプログラムは、プロトコル処理部107からの通知で指定されたアプリケーション通信に必要なアプリケーションシステム部103の準備処理を行う。そして、CPU110で動作するシステムプログラムは、アプリケーション通信データの出力と、入力とで使用するRAM112上のメモリ領域のアドレス及びサイズを、プロトコル処理部107に通知する。つまり、CPU110で動作するシステムプログラムは、アプリケーション通信に使用する送信バッファと、受信バッファとの通知を行う。プロトコル処理部107の処理はS902からS903に進む。S903からS906までは、プロトコル処理部107が、アプリケーション通信に使用する送信バッファと、受信バッファとの通知を待つ。そして、プロトコル処理部107は、通知を待つ間に、クライアント機器からアプリケーション用のパケットであるアプリケーション通信パケットを受信した場合には、そのアプリケーション通信パケットをアプリケーション通信データとして一時保存しておく。S903において、プロトコル処理部107は、アプリケーションシステム部103から送信バッファと、受信バッファとの通知を受け取っているか否かを判断する。プロトコル処理部107は、通知を受け取っていると判断した場合、S904に進み、通知を受け取っていないと判断した場合S905に進む。S905において、プロトコル処理部107は、通信制御部105等を介して、クライアント機器からアプリケーション通信パケットを受信しているか否かを判断する。プロトコル処理部107は、通信制御部105等を介して、クライアント機器からアプリケーション通信パケットを受信していると判断すると、S906に進む。一方、プロトコル処理部107は、通信制御部105等を介して、クライアント機器からアプリケーション通信パケットを受信していないと判断すると、S903に戻る。S906において、プロトコル処理部107は、クライアント機器からのアプリケーション通信データをローカルRAM106に記憶する。S904において、プロトコル処理部107は、図9のS813や、S906においてクライアント機器からのアプリケーション通信データをローカルRAM106に記憶していたか否かを判断する。プロトコル処理部107は、アプリケーション通信データをローカルRAM106に記憶していた場合は、S907に進み、アプリケーション通信データをローカルRAM106に記憶していなかった場合は、S908に進む。S907において、プロトコル処理部107は、ローカルRAM106に記憶しておいたアプリケーション通信データをRAM112の受信バッファ領域に転送する。S908において、プロトコル処理部107は、アプリケーション通信の開始を、アプリケーションシステム部103に通知する。CPU110で動作中のシステムプログラムは、この通知を確認すると、アプリケーション通信を開始する。以上が、アプリケーション機器101が低消費電力状態であるときのプロトコル処理部107における処理動作である。なお、上記では、プロトコル処理部107の処理において、IPパケットのIPヘッダチェックサムや、TCPパケットのTCPチェックサムの検査についての処理は、説明を省略した。プロトコル処理部107は、それぞれのパケットのヘッダ解析時S802やS804において、チェックサムの検査をい、パケットにデータ誤りがあると判断すると、受信パケットを破棄するものとする。次にアプリケーション機器101と、クライアント機器との間のアプリケーション通信の開始初期における正常系の送受信シーケンスを、図13を参照しながら説明する。図13の1301はクライアント機器側の時間軸、1302はアプリケーション機器101側の時間軸を表し、両時間軸間にある1303から1310までの矢印は、通信データの送信方向を示す。1303はTCPコネクションの開始要求の通信パケットを表す。即ちアプリケーション通信の開始を要求するTCPパケットのことである。アプリケーション機器101は、開始要求の通信パケット1303を受信すると、TCPコネクションの開始要求に対する確認応答のTCPパケット1304を送信する。クライアント機器は、確認応答のTCPパケット1304を受信すると、確認応答のTCPパケット1304に対する1305の確認応答のTCPパケットを、アプリケーション機器101に送信する。クライアント機器及びアプリケーション機器101は、この3回のTCPパケットのやり取り1311によってTCPコネクションは確立されたものとみなす。1311のTCPコネクションを確立する通信は、3ウェイハンドシェイクと呼ばれている。こうしてクライアント機器と、アプリケーション機器との間でTCPコネクションが確立されると、クライアント機器は、アプリケーション機器101に対し、HTTPやFTP等のアプリケーションプロトコルによる通信を始める。1306~1307までの矢印が示す通信パケットは、アプリケーション通信1312を表している。アプリケーション機器101が低消費電力状態アプリケーションシステム部103において電源制御部115を除くハードウェア装置の電力の供給をオフにした状態において、クライアント機器からアプリケーション通信の開始要求を受信し、アプリケーションシステム部103が起動される。この場合、1311のTCPコネクションを確立するまでの通信をネットワーク通信部102で実行する。そして、1312のアプリケーション通信は、ネットワーク通信部102と、起動されたアプリケーションシステム部103とによって実行されることになる。本実施形態によれば、アプリケーション機器101がアプリケーション通信を実行しない間は、アプリケーションシステム部103において電源制御部115を除くハードウェア装置の電力の供給をオフにすることができ、低消費電力を実現することができる。また、本実施形態によれば、アプリケーション通信の開始要求を、TCP通信コネクションを開始する宛先ポート番号がアプリケーション通信毎の受付けポート番号の何れかであるTCPパケットを受信した場合としている。このことにより、標準的なTCP/IPプロトコル通信で、アプリケーション機器101の遠隔起動を実現することができ、特別な手段を設ける必要がない。更に、本実施形態によれば、アプリケーション機器101の低消費電力状態においてアプリケーションシステム部103内の電源がオフである装置の内、アプリケーション通信の実行に必要となる装置だけを選択的に起動する。よって、低消費電力状態からの復帰にかかる時間を短縮することができる。更にプロトコル処理部107が、アプリケーションシステム部103の起動完了を待たずにアプリケーション通信のTCPコネクションを確立するため、アプリケーションシステム部107は起動後に直ぐにアプリケーション通信を開始することができる。実施形態2本実施形態では、実施形態1で示したアプリケーション機器101の一例としてネットワークカメラ1401を用いて説明を行う。本実施形態のネットワークカメラ1401は、撮影静止画データ或いは撮影動画データを配信する。また、ネットワークカメラ1401は、ネットワークカメラ1401と離れた場所にいるクライアント機器側の指示により、カメラ撮影開始や撮影停止、パン/チルト/ズーム等の制御が可能である。また、ネットワークカメラ1401は、撮影した静止画や動画を蓄積する2次記憶装置を有し、以前に撮影した静止画や動画データをクライアント機器に転送できる。また、ネットワークカメラ1401は、組込みWebサーバの機能を有している。つまり、利用者は、ネットワークを介して接続されたPCや携帯電話等のWebブラウザから、撮影画像の表示、カメラ操作、或いはシステム設定を行うことができる。なお、これらの各機能はネットワークを介した通信を利用して実現されている。図14は、ネットワークカメラの一例を示すブロック図その1である。図3と同じ符号の構成は第1の実施の形態において説明した機能と同様の機能を果たすものとしてその説明を省略する。図14に示されるように、アプリケーションシステム部103としてカメラシステム部1403が構成されたものである。カメラシステム部1403のROM112は、カメラシステムを実行するプログラムが格納されている。ROM111からRAM112にカメラシステムプログラムが読み込まれ、CPU110によって実行される。また、システムバス109に接続されている二次記憶装置1413は、例えばハードディスク装置、或いはCFカードやSDカード等の記憶容量が大きなメモリに記憶するための不揮発性メモリ装置である。二次記憶装置1413は、主にネットワークカメラ1401が撮影した静止画や動画データをファイル形式で保存するために使用される。また、システムバス109に接続されている撮像部1414は、ネットワークカメラ1401の撮像部であり、レンズ、CCD光電変換素子、CCD制御部等を含む。撮像部1414は、レンズを通して投影される撮像を、CCDによってアナログ電気信号に変換する。また、撮像部1414は、アナログ電気信号に変換された撮像画像から、ノイズ除去等の処理を施し、デジタルデータに変換するA/D変換を行う。また、システムバス109に接続されているエンコーダ1415は、非圧縮デジタル画像データのエンコード圧縮符号化を実行する。撮像部1414が一定の周期で非圧縮デジタル画像データを出力し、エンコーダ1415が非圧縮デジタル画像データをエンコードすることにより、クライアント機器に配信する静止画データや、動画が生成される。なお、本実施形態におけるエンコーダ1415は、画像データの高速なエンコード処理を実現するハードウェア装置であり、複数のエンコード形式に対応する。エンコード形式には、JPEGや、MPEG4を含む。ネットワークカメラ1401のアプリケーション機能は、カメラシステム部1403で実現される。また、CPU110で実行されるシステムプログラムは、アプリケーション機能の一部であるアプリケーション通信を行う。例えば、撮影映像のストリーミング配信は、撮像部1414が撮影した非圧縮画像フレームデータをエンコーダ1415によってエンコードし、圧縮画像データをRAM112に出力する。CPU110で実行されるシステムプログラムは、RAM112上の圧縮画像データからストリーミングプロトコルで送信可能な形式のストリーミングデータを作成する。そして、CPU110で実行されるシステムプログラムは、下位層のTCP/IPプロトコル処理機能を有するネットワーク通信部102を利用して、ストリーミングデータを配信先に送信する。また、遠隔撮影操作に応じた撮影等は、CPU110が実行するカメラシステムプログラムが、クライアント機器からの撮影操作コマンドを受信、解釈する。そして撮像部1414、エンコーダ1415に撮影操作コマンドに応じた動作制御を指示することで実行される。なお、より詳細に説明すると、まず、ネットワーク通信部102が通信パケットを受信し、TCP/IPプロトコルのパケット受信処理が行われる。その後、撮影操作コマンド用のプロトコルのデータ形式であるデータセグメントが、システムプログラムに入力されることによって、利用者からの撮影操作コマンドの受信がなされる。ネットワークカメラ1401は、アプリケーション通信を実行している間は、少なくともネットワーク通信部102、システムバス109、CPU110、ROM111、RAM112、電源制御部115が動作している。一方、ネットワークカメラ1401は、アプリケーション通信を実行しない期間は、カメラシステム部1403内の各ハードウェア装置の電源をオフにして動作を停止する。そして、ネットワークカメラ1401は、ネットワーク通信部102と、電源制御部115とだけを動作させておく。このことにより、消費電力を大きく低減させる低消費電力状態にすることができる。ネットワークカメラ1401は、低消費電力状態において、ネットワーク通信部102と、電源制御部115とだけが動作し、クライアント機器からのアプリケーション通信の開始要求を待機する。また、ネットワーク通信部102は、アプリケーション通信の開始要求を受信すると、カメラシステム部1403を構成する装置の内、アプリケーション通信を実行するのに必要な装置の電源をオンにする。このことによって、カメラシステム部1403と、ネットワーク通信部102とが動作してアプリケーション通信を開始することができる。アプリケーション通信の開始要求は、ネットワークカメラ1401宛てのTCPパケットであり、且つTCPコネクション開始要求のパケットであり、更にTCPパケットの宛先ポート番号がアプリケーション通信の受付けポート番号に一致することが条件である。この条件が満たされた場合、アプリケーション通信の開始要求であると判定される。このアプリケーション通信の開始要求の判定処理は、プロトコル処理部1407によって実行される。ネットワークカメラ1401が低消費電力状態の場合、プロトコル処理部107は、アプリケーション通信の開始要求であると判定した場合、カメラシステム部1403内の装置に電源を投入するため、電源制御部1416に対して電源制御指示を行う。プロトコル処理部107は、アプリケーション通信の開始要求の判定処理を行うため、ローカルRAM106にアプリケーション通信、その受付けTCPポート番号、及び電源制御部115への電源制御指示コードの対応付けデータを保持している。図15は、対応付けデータの一例を示す図その2である。図15において、1501の項目は受付けTCPポート番号である。1502の項目はTCPポート番号に対応するアプリケーション通信の内容種類である。1503の項目はアプリケーション通信のアプリケーションプロトコル名である。1504の項目は電源制御部115に対する電源制御指示コードである。また、1504の項目はその電源制御指示コードによって起動される、カメラシステム部1403内の装置である。例えば1506のエントリでは、ネットワークカメラ1401が受付けるTCPポート番号が8080であり、そのアプリケーション通信は、ネットワークカメラ1401が撮影する映像のストリーミング配信であることを示している。また、1506のエントリでは、ストリーミング配信に使用するアプリケーションプロトコルはHTTPプロトコルであることを示している。また、1506のエントリでは、このアプリケーション通信によって、ネットワークカメラ1401が低消費電力状態から起動するときは、プロトコル処理部107が電源制御部1416に対して、電源制御指示コード0x81を設定することを示している。また、1506のエントリでは、電源を投入して起動される装置は、システムバス109、CPU110、ROM111、RAM112、撮像部1414、エンコーダ1415であることを示している。その他の処理は第1の実施の形態と同様であるので、その説明を省略する。本実施形態によれば、ネットワークカメラ1401は、アプリケーション通信を実行しない間、カメラシステム部1403の電源制御部115を除く全てのハードウェア装置の電源をオフにすることができ、消費電力を抑えることができる。また、本実施形態では、アプリケーション通信の開始要求を、TCP通信コネクションを開始する宛先ポート番号がアプリケーション通信毎の受付けポート番号の何れかであるTCPパケットを受信した場合としている。よって、標準的なTCP/IPプロトコル通信で、遠隔起動を実現することができる。また、本実施形態では、ネットワークカメラ1401の低消費電力状態においてカメラシステム部1403内の電源がオフである装置の内、アプリケーション通信の実行に必要となる装置だけを選択的に起動する。よって、低消費電力状態からの復帰にかかる時間を短縮することができる。また、本実施形態では、プロトコル処理部107が、カメラシステム部1403の起動完了を待たずにアプリケーション通信のTCPコネクションを確立する。よって、カメラシステム部1403は起動後直ぐにアプリケーション通信を開始することが可能となる。実施形態3実施形態3では、クライアント機器からのアプリケーション通信開始要求に応じて、必要ならばアプリケーション機器が、クライアント機器の認証を行って、認証に成功すると低消費電力状態から復帰する例を説明する。なお、実施形態3では、主に実施形態1とは異なる点を説明し、同じ点は説明を省略する。図16は、アプリケーション機器の一例を示すブロック図その2である。図16に示されるように、アプリケーション機器101は、ネットワーク通信部102と、アプリケーションシステム部103と、から構成される。図16に示される構成は、実施形態1の図3に示した構成と比べて、ネットワーク通信部102に、暗号処理部115と、鍵管理認証処理部116と、が更に含まれている点が異なる。ネットワーク通信部102の暗号化通信に関する機能は、プロトコル処理部107と、暗号処理部117と、鍵管理認証処理部118と、によって実現される。暗号化通信セッションの開設のネゴシエーション処理や、暗号化通信プロトコル処理は、プロトコル処理部107が実行する。プロトコル処理部107は、通信データの暗号化処理や、復号化の計算処理、通信データのメッセージダイジェストの計算処理を、暗号処理部117を制御して実行する。また、プロトコル処理部107は、クライアント機器の認証に関わる処理や、通信データの暗号化や復号化に使用する鍵データの管理を、鍵管理認証処理部118を制御して実行する。暗号化処理部117は、暗号化通信における通信データの圧縮/伸長、暗号化/復号化のアルゴリズム計算処理や、暗号鍵を使用した通信データのメッセージダイジェストの計算処理を行うハードウェア装置である。また、暗号化処理部117は、所定範囲内の乱数を生成する。暗号化処理部117が対応可能な暗号化アルゴリズムには、例えばRC2、RC4、DES、3DES、AES、RSA、DH、DSSが挙げられる。また、暗号化処理部117が対応可能なメッセージダイジェストの計算アルゴリズムには、例えばMD5、SHA1が挙げられる。鍵管理認証処理部118は、暗号化通信の鍵管理や、クライアント機器の認証に関わる複数の処理を実行するハードウェア装置である。まず、鍵管理認証処理部118は、公開鍵暗号方式におけるアプリケーション機器101の公開鍵と、秘密鍵との管理、アプリケーション機器101自身の電子証明書を管理する。また、鍵管理認証処理部118は、複数の認証処理を実行する。例えば、鍵管理認証処理部118は、クライアント機器の電子証明書を検証し、信頼できる相手であるか否かを判断する認証処理や、クライアント機器のIDと、パスワードとで利用権限を認証する認証処理等を行う。更に、鍵管理認証処理部118は、各々の認証処理における各種秘匿情報の管理も行う。また、鍵管理認証処理部118は、各々の暗号化通信セッションで通信の暗号化に使用する共通鍵の生成と、管理とを行う。ローカルRAM106は、通信制御部105や、プロトコル制御部107、暗号処理部117、鍵管理認証処理部118の処理におけるデータの一時記憶領域に使用される。なお、本実施形態において、クライアント機器も、図16に示されるようなネットワーク通信部102や、電源制御部115等を有する構成であってもよい。アプリケーション機器101のアプリケーション機能は、アプリケーションシステム部103で実現される。また、CPU110で実行されるシステムプログラムは、アプリケーション機能の一部であるアプリケーション通信を行う。アプリケーション通信はTCP/IPプロトコルを利用した通信である。またアプリケーション通信によっては、暗号化通信を必要とする。TCP/IPプロトコル処理と、暗号化通信処理とはネットワーク通信部102において実行される。このような通信処理の機能分担について図17を参照して説明する。図17に示す階層モデル401において、暗号化通信プロトコルは、トランスポート層と、アプリケーション層403との間に位置するセッション層で表される。セッション層は、下位にトランスポート層のプロトコルを使用し、上位層のアプリケーションプロトコルに論理的な通信リンクを提供する。SSLや、TLSはセッション層のプロトコルであり、アプリケーション通信の内容を暗号化し、下位層のプロトコルにTCPを利用して信頼性のある送受信を行うための通信リンク暗号化通信セッションを開設する。408で示される範囲、即ちネットワーク層プロトコルであるIPv4、IPv6、ICMPの処理や、トランスポート層プロトコルであるUDP、TCPの処理はプロトコル処理部107において実行される。そして、SSLや、TLSの暗号化通信処理は、プロトコル処理部107と、暗号処理部117と、鍵管理認証処理部118とが協調動作して実行される。次に、低消費電力状態において利用者からのアプリケーション通信の開始要求を受信したときの通信動作の概略を、図18を参照して説明する。図18の601はアプリケーション機器を表し、図16におけるアプリケーション機器101と一致する。アプリケーション機器601は、ネットワーク通信部602と、アプリケーションシステム部603とで構成しており、それぞれ、図16のネットワーク通信部102と、アプリケーションシステム部103とに一致する。説明の簡略化のため、図6との差異の部分のみを説明する。利用者であるクライアント機器604は、アプリケーション機器601に対してアプリケーション通信の開始要求606を送信する。アプリケーション機器601では、ネットワーク通信部602がアプリケーション通信の開始要求606の受信を行う。ネットワーク通信部602は、アプリケーション通信の開始要求を受信すると、クライアント機器604との間に通信コネクション607を確立する。開始要求されたアプリケーション通信がクライアント機器604の認証を必要とする場合、ネットワーク通信部602は、通信コネクション607上に暗号化通信セッション608を開設する。ネットワーク通信部602における認証処理は、暗号化通信セッション608の開設時のネゴシエーションのときか、或いは暗号化通信セッション608の開設後の暗号化通信のときに実行される。なお、クライアント機器604の認証を必要としない場合は、ネットワーク通信部602は、暗号化通信セッション608を開設生成しない。こうしてアプリケーション通信を行うための通信の準備が整うと、ネットワーク通信部602は、アプリケーションアプリケーションシステム部603に電源を投入する609。本実施の形態におけるプロトコル処理部107は、第1の実施形態の処理に加えて、アプリケーション通信がクライアント機器の認証が必要なアプリケーション通信か否かを判断する。プロトコル処理部107は、クライアント機器の認証が必要なアプリケーション通信であると判断すると、認証方法を決定する。なお、クライアント機器の認証を必要とする場合、何れのアプリケーション通信も暗号化通信となる。プロトコル処理部107は、クライアント機器とのTCPコネクションの確立後に、暗号処理部117と、鍵管理認証処理部118とを制御して、SSL或いはTLSをベースとした暗号化通信セッションの開設処理を実行する。また、プロトコル処理部107は、暗号処理部117と、鍵管理認証処理部118とを制御して、クライアント機器の認証処理を行う。また、クライアント機器の認証が必要でない場合或いはクライアント機器の認証が成功した場合、プロトコル処理部107は、電源制御部115に対して電源制御指示を行う。電源制御部115は、前記電源制御指示に基づいて、アプリケーション通信に係るアプリケーションシステム部103内のハードウェア装置に電源を投入する。本実施の形態において、図8に示す項目に加えて、クライアント機器の認証方法に関する項目を加えたデータをテーブルとして保持している。図19は、対応付けデータテーブルの一例であるテーブル1906を示す図その3である。図8と同一符号は同一の項目を示している。図19において、項目1904はアプリケーション通信におけるクライアント機器の認証方法である。例えば、テーブル1906のある欄では、アプリケーション機器101が受付けるTCPポート番号が80である場合、そのアプリケーション通信の内容は、Webブラウジング用のアプリケーション機器101を操作するページの転送を示している。また、アプリケーション通信に使用されるプロトコルはHTTPプロトコルであることを示している。また、項目1904を参照すると、このアプリケーション通信はクライアント機器の認証が必要ないことを示している。そして、このアプリケーション通信によって、アプリケーション機器101を低消費電力状態から起動するときは、プロトコル処理部107が電源制御部115に対して、電源制御指示コードの0x41を設定することを示している。アプリケーション機器101が低消費電力状態であるときのプロトコル処理部107の処理を、図20、図21、図22及び図23を参照しながら説明する。図20~図23は、アプリケーション機器101が低消費電力状態であるときのプロトコル処理部107の処理フローチャートである。なお、図20のS101からS106までの処理は、図9のS801からS806までの処理と同様であるので説明を省略する。以上の処理において、S108に進んだ場合、プロトコル処理部107は、アプリケーション通信の開始要求を受信したと判定する。S108において、プロトコル処理部107は、前記受付けポート番号に基づいて、ローカルRAM106に保持する、図19に示したような対応付けデータをテーブルから検索し、クライアント機器の認証が必要であるか否かを判断する。プロトコル処理部107は、クライアント機器の認証が必要であると判断すると、S110に進み、クライアント機器の認証が必要でないと判断すると、S109に進む。S109において、プロトコル処理部107は、電源制御部115に図19の1905で示される電源制御コードの中から、該当する電源制御コードを送信する。電源制御部115は、電源制御指示コードに従って、アプリケーションシステム部103を構成する109から114までのハードウェア装置に選択的に電源を投入する処理を実行する。S110において、プロトコル処理部107は、TCPコネクションの開始要求に対する確認応答のTCP/IPパケットを作成し、通信制御部105を介してアプリケーション通信の要求元であるクライアント機器に送出する。このTCP/IPパケットは、TCPヘッダのフラグビットのSYN図12の1111と、ACK図12の1108とがオンである。また、このTCP/IPパケットは、応答確認番号図12の1104に、受信したIPパケットが格納していたTCPパケットのTCPシーケンス番号図12の1104の値がセットされている。なお、S110の処理は、S109においてアプリケーションシステム部103へ起動を指示した場合は、アプリケーションシステム部103の起動完了を待たずに実行される。S111は、図21のS201へと続き、次のプロトコル処理部107の処理は、S202となる。図21のS202と、S203とは、プロトコル処理部107が、S110においてクライアント機器に送信した確認応答パケットに対して、クライアント機器から送信されるべき確認応答パケットの受信を、予め設定されたタイムアウト時間まで待つ処理である。なお、S203からS206までの処理は、図9のS810からS817までの処理と同様のため説明を省略する。S202において、クライアント機器からの確認応答パケットを受信すると、クライアント機器とアプリケーション機器101との間でTCPコネクションが確立したことになる。そしてS207において、プロトコル処理部107は、S108と同様、開始しようとしているアプリケーション通信がクライアント機器の認証を必要とするか否かを判断する。プロトコル処理部107は、認証が必要であると判断すると、S212に進み、認証が必要でないと判断すると、S208に進む。S212は、図22のS301へと続き、次のプロトコル処理部107の処理は、S302となる。S208からS210までは、プロトコル処理部107が、アプリケーションシステム部103の起動完了の通知を待ちながら、起動完了までの間にクライアント機器からのパケットを受信したときにアプリケーション通信データを一時保存しておく処理を行う。アプリケーションシステム部103のCPU110は、起動完了を確認すると、プロトコル処理部107に対して起動完了した旨の通知起動完了通知を行う。S208において、プロトコル処理部107は、この起動完了通知を受け取ったか否かを確認する。プロトコル処理部107は、起動完了通知を受け取っていないと判定すると、S209に進み、起動完了通知を受け取ったと判定すると、S211に進む。S211は、図23のS401へと続き、次のプロトコル処理部107の処理は、S402となる。S209及びS210の処理は、図9のS812及びS813の処理と同様のため説明を省略する。本実施形態において、クライアント機器の認証方法は、大別して暗号化通信セッションの開設時のネゴシエーションの際に行う場合と、一旦暗号化通信セッションを開設した後に暗号化通信を利用してクライアント機器のユーザ認証を行う場合とに分けられる。S302において、プロトコル処理部107は、クライアント機器と、SSL又はTLSの暗号化通信セッションを開設する通信処理を実行する。なお、クライアント機器の認証を暗号化通信セッションの開設時のネゴシエーションにおいて行う場合は、プロトコル処理部107は、認証処理も含めて通信処理を実行する。S302において、プロトコル処理部107がクライアント機器の認証を行う場合、認証に失敗すると、暗号化通信セッションを開設することはできない。ここで、プロトコル処理部107は、図19に示した対応付けデータに含まれる、該当する認証方法1904に基づいて、クライアント機器の認証を暗号化通信セッションの開設時のネゴシエーションにおいて行うか否か判断する。S303において、プロトコル処理部107は、暗号化通信セッションを開設できたか否かを判断する。プロトコル処理部107は、暗号化通信セッションを開設できたと判断すると、S306に進み、暗号化通信セッションを開設できなかったと判断すると、S304に進む。S304において、プロトコル処理部107は、クライアント機器とのTCPコネクションを終了し、S305に進み、処理を終了する。一方、S306において、プロトコル処理部107は、図19に示した対応付けデータに含まれる、該当する認証方法1904に基づいて、ユーザ認証が必要か否かを判断する。プロトコル処理部107は、ユーザ認証の必要があると判断すると、S307に進み、ユーザ認証の必要がないと判断すると、S310に進む。S307において、プロトコル処理部107は、暗号化通信を利用し、クライアント機器に係るユーザのユーザ認証を行う。より具体的に説明すると、プロトコル処理部107は、クライアント機器に対して、アプリケーション通信に係るユーザIDと、パスワードとを要求する。プロトコル処理部107は、クライアント機器からユーザIDと、パスワードとを受信すると、鍵管理認証部115に、開始しようとしているアプリケーション通信において、ユーザIDと、パスワードとの組でユーザ認証できるか否かを問い合わせる。鍵管理認証部115は、ユーザIDと、パスワードとの組でユーザ認証できるか否かの応答を、プロトコル処理部107に対して行う。また、鍵管理認証部115は、ユーザ認証できる場合は、ユーザ認証を行い、ユーザ認証が成功したか否かの情報をプロトコル処理部107に返す。S308において、プロトコル処理部107は、ユーザ認証できたか否かを判断する。プロトコル処理部107は、ユーザ認証できたと判断すると、S310に進み、ユーザ認証できなかったと判断すると、S309に進む。プロトコル処理部107は、鍵管理認証部115よりユーザ認証が成功した旨の情報を受け取ると、ユーザ認証できたと判断する。S309において、プロトコル処理部107は、クライアント機器との暗号化通信セッションを終了し、S304に進む。一方、S310において、プロトコル処理部107は、プロトコル処理部107は、電源制御部115に図8の1204で示される電源制御コードの中から、該当する電源制御コードを送信する。電源制御部115は、電源制御指示コードに従って、アプリケーションシステム部103を構成する109から114までのハードウェア装置に選択的に電源を投入する処理を実行する。S811からS813までは、プロトコル処理部107が、アプリケーションシステム部103の起動完了の通知を待ちながら、起動完了までの間にクライアント機器からのパケットを受信したときにアプリケーション通信データを一時保存しておく処理を行う。アプリケーションシステム部103のCPU110は、起動完了を確認すると、プロトコル処理部107に対して起動完了した旨の通知起動完了通知を行う。S311において、プロトコル処理部107は、この起動完了通知を受け取ったか否かを確認する。プロトコル処理部107は、起動完了通知を受け取っていないと判定すると、S312に進む。S312において、プロトコル処理部107は、通信制御部105等を介して、クライアント機器から暗号化通信データを受信しているか否かを判断する。プロトコル処理部107は、通信制御部105等を介して、クライアント機器から暗号化通信データを受信していると判断すると、S313に進む。一方、プロトコル処理部107は、通信制御部105等を介して、クライアント機器から暗号化通信データを受信していないと判断すると、S311に戻る。S313において、プロトコル処理部107は、暗号処理部117を用いて暗号化通信データを復号化してアプリケーション通信データを生成し、ローカルRAM106に記憶しておく。一方、S311において、プロトコル処理部107が、起動完了通知を受け取ったと判定すると、S314に進む。なお、S314は、図23のS401へと続き、次のプロトコル処理部107の処理は、S402となる。以上までの処理フローにおいて、図21のS211から図23のS401に至った場合、アプリケーション機器101と、クライアント機器とは、TCPを利用した非暗号化通信を行う。一方、図22のS314から図23のS401に至った場合、アプリケーション機器101と、クライアント機器とは、TCPコネクション、及びそのTCPコネクション上の暗号化通信セッションを利用した暗号化通信を行う。S402からS409までの処理は、図10のS902からS908までの処理と同様のため説明を省略する。但し、S406において、プロトコル処理部107は、クライアント機器と暗号化通信中である場合は、クライアント機器からの暗号化通信データを、暗号処理部117を用いて復号化し、アプリケーション通信データを生成する。そして、プロトコル処理部107は、生成したアプリケーション通信データをローカルRAM106に記憶する。次にアプリケーション機器101と、クライアント機器との間のアプリケーション通信の開始初期における正常系の送受信シーケンスを、図24、図25及び図26を参照しながら説明する。なお、アプリケーション通信がクライアント機器の認証を必要としない場合の正常系通信のシーケンス図は、図13と同様である。図24は、アプリケーション通信がクライアント機器の認証を必要とし、認証方法として暗号化通信開始後にユーザ認証を行う場合の正常系の通信シーケンス図である。図24において1601はクライアント機器側の時間軸、1602はアプリケーション機器101側の時間軸を表す。また、1603から1605までの通信は上述した3ウェイハンドシェイク1616であり、クライアント機器と、アプリケーション機器101との間にTCPコネクションを確立する。次に1606から1609までは、クライアント機器からアプリケーション機器101に対する、暗号化通信セッションを開設するためのネゴシエーション1617を表す。アプリケーション機器101は、1607のCertificateメッセージで自器の電子証明書をクライアント機器に送信している。クライアント機器は、この電子証明書の検証を行い、アプリケーション機器101を信頼できる機器だと認証できれば、残りのネゴシエーションを継続する。このようにクライアント機器が、アプリケーション機器101の電子証明書によって、アプリケーション機器101を認証する方法は、SSLや、TLSにおいてサーバ認証と呼ばれる。1617の暗号化通信セッションの開設のネゴシエーションが完了すると、以降の通信データはすべて暗号化されることになる。続いてアプリケーション機器101は、1610でクライアント機器に対して、ユーザIDと、パスワードとの送信を要求する。クライアント機器は1611でユーザIDと、パスワードとを送信する。アプリケーション機器101は、受信したユーザIDと、パスワードとで認証を実行する。認証が成功すると、アプリケーション機器101は、1612でユーザ認証完了を通知する。つまり、1610から1612は、アプリケーション通信に必要なクライアント機器のユーザ認証1618に係る通信であり、暗号化通信によって実行される。こうしてクライアント機器に対するユーザ認証が成功すれば、クライアント機器は、アプリケーション機器101に対し、アプリケーションプロトコルによる通信を始める。1613から1615までの矢印が示す通信データは、アプリケーション通信1619を表している。アプリケーション機器101が低消費電力状態において、クライアント機器からアプリケーション通信の開始要求を受信し、クライアント機器のユーザ認証を行ってアプリケーションシステム部103を起動する。この場合、1616のTCPコネクションを確立する通信と、1617の暗号化通信セッション開設時のネゴシエーションの通信と、1618のユーザ認証の通信とは、ネットワーク通信部102だけで実行される。また、1619のアプリケーション通信は、ネットワーク通信部102と、アプリケーションシステム部103とによって実行される。図25は、アプリケーション通信がクライアント機器の認証を必要とし、認証方法としてクライアント機器からの暗号化通信セッション開設のネゴシエーションにおいてクライアント機器を認証する場合の正常系の通信シーケンス図である。図25において1701はクライアント機器側の時間軸、1702はアプリケーション機器101側の時間軸を表す。また、1703から1705までの通信は上述した3ウェイハンドシェイク1713であり、クライアント機器と、アプリケーション機器101との間にTCPコネクションを確立する。次に1706から1709までは、クライアント機器からアプリケーション機器101に対する、暗号化通信セッションの開設するためのネゴシエーション1714を表す。アプリケーション機器101は、1707のCertificateメッセージで自器の電子証明書をクライアント機器に送信している。また、同時に、アプリケーション機器101は、CertificateRequestメッセージで、電子証明書の送信をクライアント機器に要求している。クライアント機器は、アプリケーション機器101の電子証明書の検証を行い、アプリケーション機器101を信頼できる機器だと認証できれば、残りのネゴシエーションを継続する。上述したように、この認証はSSLや、TLSにおけるサーバ認証である。クライアント機器は、1708においてCertificateメッセージで、アプリケーション機器101から要求された自器の電子証明書を送信する。また、同時に、クライアント機器は、CertificateVerifyメッセージで、電子証明書を送信した主体者がクライアント機器であることを証明する文字列を送信する。アプリケーション機器101は、1708を受信すると、クライアント機器から送信された電子証明書を検証し、クライアント機器が信頼できるクライアント機器としての認証処理を行う。認証できれば、アプリケーション機器101は、残りの1709の通信を行う。このように、アプリケーション機器101がクライアント機器の電子証明書を要求し、送信された電子証明書によってクライアント機器を認証する方法は、SSLや、TLSにおいてクライアント認証と呼ばれる。1714の暗号化通信セッション開設のネゴシエーションを完了すると、以降の通信データはすべて暗号化されることになる。そして、クライアント機器は、アプリケーション機器101に対してアプリケーションプロトコルによる通信を始める。1710から1712までの矢印が示す通信データは、アプリケーション通信1715を表している。アプリケーション機器101が、低消費電力状態において、クライアント機器からアプリケーション通信の開始要求を受信する。そして、アプリケーション機器101が、クライアント機器から開始される暗号化通信セッション開設時のネゴシエーションにおいてクライアント機器の認証を行って、アプリケーションシステム部103を起動する。この場合、1713のTCPコネクションを確立する通信と、1714の暗号化通信セッション開設時のネゴシエーションの通信とは、ネットワーク通信部102だけで実行される。また、1715のアプリケーション通信は、ネットワーク通信部102と、アプリケーションシステム部103とによって実行される。図26は、アプリケーション通信がクライアント機器の認証を必要とし、認証方法としてアプリケーション機器101からの暗号化通信セッション開設のネゴシエーションにおいてクライアント機器を認証する場合の正常系通信シーケンスを説明する。図26において1801はクライアント機器側の時間軸、1802はアプリケーション機器101側の時間軸を表す。また、1803から1805までの通信は上述した3ウェイハンドシェイク1813であり、クライアント機器と、アプリケーション機器101との間にTCPコネクションを確立する。次に1806から1809までは、アプリケーション機器101からクライアント機器に対して暗号化通信セッションの開設するためのネゴシエーション1814を表す。クライアント機器は、1807のCertificateメッセージで自器の電子証明書をアプリケーション機器101に送信している。アプリケーション機器101は、この電子証明書の検証を行い、クライアント機器を信頼できるクライアント機器だと認証できれば、残りのネゴシエーションを継続する。上述したように、この認証はSSLや、TLSにおけるサーバ認証である。1814の暗号化通信セッション開設のネゴシエーションを完了すると、以降の通信データはすべて暗号化されることになる。クライアント機器は、アプリケーション機器101に対してアプリケーションプロトコルによる通信を始める。1810から1812までの矢印が示す通信データは、アプリケーション通信1815を表している。アプリケーション機器101は、低消費電力状態において、クライアント機器からアプリケーション通信の開始要求を受信し、クライアント機器の認証を暗号化通信セッションの開設時のネゴシエーションで行う。そして、アプリケーション機器101は、アプリケーションシステム部103を起動する。この場合、1713のTCPコネクションを確立する通信と、1714の暗号化通信セッション開設時のネゴシエーションの通信は、ネットワーク通信部102だけで実行される。また、1715のアプリケーション通信は、ネットワーク通信部102とアプリケーションシステム部103によって実行される。アプリケーション機器101が、低消費電力状態において、クライアント機器からアプリケーション通信の開始要求を受信する。そして、アプリケーション機器101から開始する暗号化通信セッション開設時のネゴシエーションにおいてクライアント機器の認証を行って、アプリケーションシステム部103を起動する。この場合、1813のTCPコネクションを確立する通信と、1814の暗号化通信セッション開設時のネゴシエーションの通信とは、ネットワーク通信部102だけで実行される。また、1815のアプリケーション通信は、ネットワーク通信部102と、アプリケーションシステム部103とによって実行される。なお、図26において1813のTCPコネクションの確立後、直ぐにアプリケーション機器101からクライアント機器に対して暗号化通信セッション開設のネゴシエーションを開始している。しかし、先にクライアント機器が暗号化通信を要求する通知を送信し、その通知をトリガとして、アプリケーション101が、クライアント機器への暗号化通信セッション開設のネゴシエーションを開始してもよい。本実施形態によれば、アプリケーション機器101がアプリケーション通信を実行しない間、ネットワーク通信部102を動作させ、アプリケーションシステム部103の電源制御部115を除くハードウェア装置の電源をオフにして低消費電力状態を実現する。また、アプリケーション機器101がアプリケーション通信を実行しない間でも、ネットワーク通信部102を動作させているので、クライアント機器からアプリケーション通信要求を受付けることが可能となる。また、本実施形態によれば、アプリケーション通信の開始要求を、TCP通信コネクションを開始する宛先ポート番号がアプリケーション通信毎の受付けポート番号の何れかであるTCPパケットを受信した場合としている。よって、クライアント機器の認証を必要としない場合、標準的なTCP/IPプロトコル通信で、アプリケーション機器101の遠隔起動を実現することができ、特別な手段を設ける必要がない。一方、クライアント機器の認証を必要とする場合、ネットワーク通信部102が、暗号化通信セッションを開設してクライアント機器を認証し、認証が成功したときにアプリケーションシステム部103に電源を投入する。よって、アプリケーション通信を開始要求するクライアント機器を認証できない場合は、アプリケーション機器101の低消費電力状態をそのまま継続することができるため、より効率的に省電力効果を得ることができる。実施形態4本実施形態は、実施形態3で示したアプリケーション機器101の一例としてネットワークカメラ1401を適用した例である。なお、実施形態4では、主に実施形態2とは異なる点を説明し、同じ点は説明を省略する。図27は、ネットワークカメラの一例を示すブロック図その2である。図27に示されるように、ネットワークカメラ1401は、ネットワーク通信部102と、カメラシステム部1403と、から構成される。図27に示される構成は、実施形態2の図14に示した構成と比べて、ネットワーク通信部1402に、暗号処理部117と、鍵管理認証処理部118と、が更に含まれている点が異なる。図28は、プロトコル処理部107が保持する対応付けデータを示すテーブル2007の一例を示す図その4である。図28において、図19と同一の符号は同一の項目を示している。例えば2007のテーブルでは、ネットワークカメラ1401が受付けるTCPポート番号が5963の場合、そのアプリケーション通信の内容は、ネットワークカメラ1401が撮影する映像のストリーミング配信と、遠隔カメラ操作とであることを示している。また、ストリーミング配信と、遠隔カメラ操作とに使用するアプリケーションプロトコルは、独自アプリケーションプロトコルであることを示している。また、2007のテーブルでは、このアプリケーション通信を実行するには、クライアント機器の認証が必要であって、認証方法はSSLや、TLSにおけるクライアント認証であることを示している。更に、2007のテーブルでは、TCPポート番号が5963の場合、ネットワークカメラ1401が低消費電力状態から起動するときは、プロトコル処理部107が電源制御部115に対して、電源制御指示コード0x81を設定する。なお、電源制御指示コード0x81によって、電源制御部1416が電源を投入して起動させるハードウェア装置は、例えば、システムバス1409、CPU1411、ROM1411、RAM1412、撮像部1414、エンコーダ1415である。以上、上述した各実施形態によれば、消費電力を節約すると共に、簡単な構成で、ネットワークを介して接続された他の装置からの要求に応じて、低消費電力状態からの復帰を安全に行うことができる。以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形変更が可能である。