JP5970819B2 - ネットワーク制御装置 - Google Patents

Description

本発明は、通信プロトコルの機能を拡張するためのネットワーク制御装置に関する。

近年、ネットワークで機器を連携させることで新たな付加価値を提供する傾向が増加している。このためネットワーク機能の追加や接続性の向上が必要となっている。このような拡張への対応として、通信プロトコル処理を部品化しアプリケーション非依存とするＡＰＩを提供することで、開発工数を削減し機能追加を容易にする方法が既に知られている。

上記に関し、特許文献１には、プロトコルや装置に依存しないアプリケーションやコンテンツを作成し、そのコンテンツを任意のプロトコルや装置に適合させて使用可能にすることが目的で、リソース記述フレームワーク（ＲＤＦ）によって任意のプロトコルや装置で扱うコンテンツデータへ変換する方法が開示されている。また、特許文献２には、Ｗｅｂサービスを提供するアプリケーションの開発および追加を容易とする目的で、処理の共通部品化とその構成が開示されている。

しかし、特許文献１に開示された方法や特許文献２に開示された構成には、次のような課題がある。まず、通信プロトコルの機能を追加・拡張するために多くの開発工数を要するという課題がある。また、通信プロトコル毎に独立した開発を行ったり、ＯＳＳなどの既存リソースを流用した場合に、通信プロトコル全体で重複した処理が多く、ＲＯＭ／ＲＡＭなどリソースに無駄が発生するという課題もある。このことは、組み込み系で使用できるリソースが限定されている場合に顕著である。

さらに、重複した処理が多いため、バグ修正等の変更が多岐に渡りメンテナンス性が低くなるという課題や、通信プロトコルとアプリケーション層との境界があいまいなものが多く、複数のアプリケーションが存在した場合に、あるアプリケーションの中に通信処理が一部含まれることによる開発工数の無駄が発生するという課題もある。

本発明は上記課題に鑑みてなされたものであり、高い通信品質を維持したままで、通信プロトコルの機能を追加・拡張するために多くの開発工数を要することがない、リソースの無駄も発生させない、メンテナンス性も低くない、組み込み系にも適用できるネットワーク制御装置を提供することを目的とする。

上記の課題を解決するため、本発明のネットワーク制御装置は、複数の端末とネットワーク通信を行うネットワークインターフェースと、複数の通信プロトコルを利用する上位アプリケーションと通信を行う上位アプリケーションインターフェースと、複数の通信プロトコルにより複数の端末とネットワーク通信を行うためプロトコル処理手順の複数を制御するプロトコル処理手順制御手段と、複数の通信プロトコルに基づいてプロトコル通信処理を実行するプロトコル通信処理手段とを備え、プロトコル通信処理手段は複数の通信プロトコルがそれぞれ有する複数のプロトコルヘッダを管理するプロトコルヘッダ管理手段を備え、プロトコル通信処理手段は、受け取ったデータの特徴と該データを上位アプリケーションへ転送する転送条件とを対応付けた対応表に基づいて、該データを転送する上位アプリケーションを特定することを特徴とする。

本発明によれば、高い通信品質を維持したままで、通信プロトコル機能追加・拡張にかかる開発工数を削減し、無駄なリソース使用を減らし、メンテナンス性を高くし、かつ組み込み系に適用することが可能となる。

本発明の実施形態のネットワーク制御装置によるシステム構成例を表すブロック図である。 本発明の実施形態のネットワーク制御装置のハードウェア構成を表すブロック図である。 本発明の実施形態のネットワーク制御装置に関する機能ブロック図である。 本発明の実施形態のネットワーク制御装置に関し、ネットワーク送信依頼の要求データの、データフォーマット及び例を表した図である。 本発明の実施形態のネットワーク制御装置に関し、ネットワーク送信依頼の要求に対する応答データの、データフォーマット及び例を表した図である。 本発明の実施形態のネットワーク制御装置に関し、ネットワーク受信共有の要求データの、データフォーマット及び例を表した図である。 本発明の実施形態のネットワーク制御装置に関し、Ｒｅｍｏｔｅのネットワーク受信共有の応答データの、データフォーマット及び例を表した図である。 本発明の第１実施形態のネットワーク制御装置を搭載した装置がサーバとして動作する場合のシーケンスの例である。 本発明の第１実施形態のネットワーク制御装置を搭載した装置がサーバとして動作する場合のシーケンスの例である。 本発明の第１実施形態のネットワーク制御装置を搭載した装置がサーバとして動作する場合のシーケンスの例である。 本発明の第１実施形態のネットワーク制御装置を搭載した装置がサーバとして動作する場合のシーケンスの例である。 本発明の第２実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして動作する場合のシーケンスの例である。 本発明の第２実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして動作する場合のシーケンスの例である。 本発明の第２実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして動作する場合のシーケンスの例である。 本発明の第２実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして動作する場合のシーケンスの例である。 本発明の第２実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして動作する場合のシーケンスの例である。 本発明の第２実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして動作する場合のシーケンスの例である。 本発明の第２実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして動作する場合のシーケンスの例である。 本発明の第２実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして動作する場合のシーケンスの例である。 本発明の第３実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰＳクライアントとして暗号通行う場合のシーケンスの例である。 本発明の第３実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰＳクライアントとして暗号通行う場合のシーケンスの例である。 本発明の第３実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰＳクライアントとして暗号通行う場合のシーケンスの例である。 本発明の第３実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰＳクライアントとして暗号通行う場合のシーケンスの例である。

本発明の実施の形態を説明する。本発明は、通信プロトコルを実現する構成に関して、以下の特徴を有する。すなわち本発明は、通信プロトコルにおいて「通信相手とやり取りを行う手順」と「パケット構造の解析」および「通信プロトコル非依存なＡＰＩ」をすべての通信プロトコルの共通処理として持ち、プロトコルヘッダ（通信制御部）を解析する部分だけを個別処理とする構成を特徴とするものである。上記記載の本発明の特徴について、以下図面を用いて詳細に解説する。

本発明の実施形態のネットワーク制御装置によるシステム構成例について、図１を用いてその概略を説明する。図１におけるシステム構成は、ネットワーク制御装置１、投影装置２及び入力装置３で構成される。

ネットワーク制御装置１は、ＵＩ（ユーザインターフェース）を備え、アプリケーションによる機能を実現し、外部装置との通信制御を行うものである。投影装置２は、例えば液晶プロジェクターなどの投影装置であり、ネットワーク制御装置１からの画像データ等をランプにより壁面などに投影させる。また入力装置３は、ネットワーク制御装置１に対する入力データを送信する装置であり、例えば電源ボタンや選択指示ボタンなどをいう。

次に、本発明の実施形態のネットワーク制御装置１のハードウェア構成について図２を用いて説明する。すなわち、本発明の実施形態のネットワーク制御装置１は、通信プロセッサ、１１メインプロセッサ１２及び外部装置１３の各ハードウェアで構成される。

通信プロセッサ１１は、通信（ネットワーク）制御を行うプロセッサであり、ＣＰＵ１０１・ＲＯＭ１０２・ローカル／ＩＦ１０３・ストレージ１０４・ＲＡＭ１０５・ネットワーク／ＩＦ１０６で構成される。メインプロセッサ１２は、いわゆるＣＰＵ（中央演算処理装置）である。また、外部装置１３は、上述の投影装置などのように、画像データ等を外部出力させる装置である。

通信プロセッサ１１は、本発明の実施形態のネットワーク制御装置１によるネットワーク制御の中枢を担うプロセッサである。なお、ローカル／ＩＦ１０３はＵＳＢやＰＣＩｅなどに代表されるインターフェースである。またネットワーク／ＩＦ１０６は無線ＬＡＮや有線ＬＡＮなどのネットワークインターフェースである。

本発明の実施形態のネットワーク制御装置１に関する機能について、図３のブロック図を用いて説明する。本発明の実施形態のネットワーク制御装置１による通信制御は、クライアント手順保持部２０１・サーバ手順保持部２０２・アプリケーション層手順管理部２０３・アプリケーション層パケット処理部２０５・アプリケーション層ペイロード管理部２０８・アプリケーション層ヘッダ管理部２０９・各プロトコルヘッダ管理部・通信データフォーマット制御部２１５・機器情報管理部２１６のそれぞれの機能の実行によって処理される。

また、各プロトコルヘッダ管理部としては、ＤＮＳヘッダ管理部２１０・ＨＴＴＰヘッダ管理部２１１・ＰＪＬｉｎｋヘッダ管理部２１２・ＤＨＣＰｖ４ヘッダ管理部２１３・ＳＮＭＰヘッダ管理部２１４がある。各管理部からのヘッダ情報をアプリケーション層ヘッダ管理部２０９において個別に解析することができる。

クライアント手順保持部２０１（プロトコル処理手順制御手段）は、ネットワーク制御装置がクライアント端末として通信制御を処理する場合の、接続後のクライアントの具体的なパケット送受信手順を保持する。クライアント手順保持部２０１は、複数のクライアント手順を順次実行してパケット送受信処理を実現する。なお、クライアント手順には、ＤＮＳクライアント手順・ＨＴＴＰクライアント手順・ＨＴＴＰクライアント手順（プロキシ認証方式取得用）があるが、クライアント手順保持部２０１が同時に実行する手順はその内の１の手順である。

サーバ手順保持部２０２（プロトコル処理手順制御手段）は、ネットワーク制御装置がサーバとして通信制御を処理する場合の、接続後のサーバの具体的なパケット送受信手段を保持する。

アプリケーション層手順管理部２０３は、アプリケーション層におけるパケット送受信の全体の進捗を管理する。また、アプリケーション層手順管理部２０３は、通信接続制御や通信切断制御を行う。その際、アプリケーション層手順管理部２０３は、プロトコル再送情報表２０４に保持されるプロトコルのタイムアウト時間およびリトライ回数を参照する。

アプリケーション層パケット処理部２０５（プロトコル解析手段）は、アプリケーション層におけるパケットがヘッダとペイロードから構成されることを知っている。アプリケーション層パケット処理部２０５は、上位層（アプリケーション）から受け取ったデータからアプリケーション層のパケットを作成し、次の処理を行う下位層へ渡す処理を行う。また、アプリケーション層パケット処理部２０５は、下位層から受け取ったデータからアプリケーション層のパケットを解析し、次の処理を行う上位層に渡す。また、アプリケーション層パケット処理部２０５は、チャンクのエンコード／デコード処理を行う。

アプリケーション層パケット処理部２０５は、下位層から受け取ったデータからアプリケーション層のパケットを解析し、次の処理を行う上位層に渡す際、上位アプリケーション振り分け表２０６（対応表）を参照する。上位アプリケーション振り分け表２０６については後述する。

上記のアプリケーション層手順管理部２０３及びアプリケーション層パケット処理部２０５は、必要に応じてＳＳＬ／ＴＬＳ２０７を利用する。ＳＳＬ／ＴＬＳ２０７は、アプリケーション層の下位層における暗号通信制御を行う。アプリケーション層手順管理部２０３は、ＳＳＬ／ＴＬＳハンドシェイク（暗号鍵共有や通信相手の認証など）においてＳＳＬ／ＴＬＳ２０７を利用し、アプリケーション層パケット処理部２０５は、送受信するデータの暗号化および復号化においてＳＳＬ／ＴＬＳ２０７を利用する。

アプリケーション層ペイロード管理部２０８（ペイロード解析手段）は、アプリケーション層のペイロードの構造を知っている。

アプリケーション層ヘッダ管理部２０９（プロトコルヘッダ解析手段）は、アプリケーション層のヘッダの構造を知っている。さらに、アプリケーション層ヘッダ管理部２０９は、その配下にＤＮＳヘッダ管理部２１０・ＨＴＴＰヘッダ管理部２１１・ＰＪＬｉｎｋヘッダ管理部２１２・ＤＨＣＰｖ４ヘッダ管理部２１３・ＳＮＭＰヘッダ管理部２１４の各プロトコルヘッダを個別に管理する構成を備える。

ＤＮＳヘッダの種別ごとのヘッダ構造を知っている。またＤＮＳヘッダ管理部２１０は、ＤＮＳヘッダに格納される情報を知っている。さらにＤＮＳヘッダ管理部２１０は、ＤＮＳヘッダを送受信する通信相手を知っている。

ＨＴＴＰヘッダ管理部２１１はＨＴＴＰヘッダの構造を知っており、ＰＪＬｉｎｋヘッダ管理部２１２はＰＪＬｉｎｋコマンドフォーマットを知っている。また、ＤＨＣＰｖ４ヘッダ管理部２１３はＤＨＣＰｖ４ヘッダの構造を知っており、ＳＮＭＰヘッダ管理部２１４はＳＮＭＰヘッダの構造を知っている。

通信データフォーマット管理部２１５はアプリケーション層のペイロードのデータフォーマットを知っており、機器情報管理部２１６は機器情報２１７を知っている。

認証情報管理部２１８は、プロトコルで転送可能な認証情報のフォーマットを知っている。認証情報管理部２１８は、ＨＴＴＰヘッダ管理部２１１・ＰＪＬｉｎｋヘッダ管理部２１２・機器情報管理部２１６それぞれの認証情報

入出力データ保持部２１９は、プロトコル処理に対する入力データと出力データを保持する。プロトコル処理に必要な入力と処理結果を保持する箱で全般でアクセスする。

ここで、上位アプリケーション振り分け表２０６について、表１を使用して説明する。

上位アプリケーション振り分け表２０６は、アプリケーション層パケット処理部２０５が上位アプリケーションへデータを転送するときに使用する振り分け表である。上位アプリケーション振り分け表２０６は、「使用リソースと転送制御方式」を決めるためのルールを規定したものである。

表１における「コンテンツデータの特徴」について説明する。「コンテンツデータの特徴」は、ＨＴＴＰなどのアプリケーションプロトコルのヘッダ情報（制御情報）から得ることができる。「操作対象」とは、振り分け先のアプリケーションを決めるものであり、各データの内容に対応して、「／ｓｅｒｖｉｃｅ／ｐｒｏｊｅｃｔｉｏｎ」・「／ｓｔａｔｅ」・「／ｐｒｏｐｅｒｔｙ」の各操作対象がある。

「操作方法」とは、ペイロードに含まれるコンテンツデータに対する操作を決めるものであり、各データの内容に対応して、「ＰＯＳＴ」・「ＰＵＴ」・「ＧＥＴ」の各操作方法がある。

また「ＭＩＭＥタイプ」とは、ペイロードに含まれるコンテンツデータのタイプを決めるものであり、各データの内容に対応して、「ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ」・「ｉｍａｇｅ／ｊｐｅｇ」・「ｖｉｄｅｏ／ｘ−ｒｎｃｂ」の各タイプがある。

さらに「操作対象が存在するサブシステム名」とは、システム構成によって決められ、各データを転送するときに使うメモリを転送先の場所毎に決めるものである。「操作対象が存在するサブシステム名」には、各データの内容に対応して「ＯＭＡＰ」・「Ｓｈｏｃｋｌｅｙ」の各サブシステムがある。

次に、表１における「使用リソースと転送制御方式」について説明する。「データ転送時に制御情報を含める」とは、アプリケーションへヘッダ情報を渡すかどうかを決めるものであり、各データの内容に応じて「Ｙｅｓ」・「Ｎｏ」で決められる。

また、「使用するバッファ」とは、データ転送時に使うバッファタイプを決めるものであり、各データの内容に対応して、「ＳＲＡＭ_ＷＨＩＯ（サイズ小）」・「ＳＲＡＭ_ＷＨＩＯ（サイズ大）」・「ＳＲＡＭ_ＤＡＴＡ」の各バッファタイプがある。

さらに、「転送単位」とは、１度に送るデータ転送の単位を決めるものであり、各データに対応して「バッファサイズｏｒ実データサイズ」・「チャンクサイズ（通信相手が指定した分割データ単位）」の各転送単位が用意される。

例えば、データの内容がＮｏ．３の投影データ（ＰＣ画面）である場合、操作対象は「／ｓｅｒｖｉｃｅ／ｐｒｏｊｅｃｔｉｏｎ」となり、操作方法は「ＰＵＴ」であり、ＭＩＮＥタイプは「ｖｉｄｅｏ／ｘ−ｒｎｃｂ」となり、操作対象が存在するサブシステム名は「ＯＭＡＰ」となる。さらに、データ転送時に制御情報を含めるかについては「Ｙｅｓ」となり、使用するバッファは「ＳＲＡＭ_ＷＨＩＯ（サイズ大）」となり、転送単位は「チャンクサイズ（通信相手が指定した分割データ単位）」となる。

次に、アプリケーションからの要求でネットワークにデータを送信する場合のデータフォーマットと例について、図４を用いて説明する。内部リソースと送信したいデータサイズによりデータが分割される。図の一番左側にデータフォーマット（アプリレベル分割前）を示し、右へ順に分割されたデータの例（要求データ１〜３）を示す。

各フィールドについて以下説明ずる。「分割データサイズ」とは、分割されたデータサイズであり、物理レベルの送信データサイズを表すものである。例えば、要求データ１であれば分割前のアプリデータ４６２０バイトに対し、分割されたデータが２０３２バイトであることが分かる。なお、要求データ１は「ＨＴＴＰヘッダ・ボディ」としてのデータとなるため、分割されたデータの２０３２バイト中、５２４バイトが制御パラメータ用に割り当てられる。

「ＥＯＦ」とは、分割されたデータに対して最後のデータかどうかを示すパラメータである。「アプリデータサイズ」とは、論理レベルの送信データサイズであり、分割された場合は各分割データサイズの合計と等しくなることはいうまでもない。

また「宛先」とは、装置内でデータをやり取りするための情報で，次に処理を行うモジュールを特定するパラメータである。「制御メッセージＩＤ」とは、要求または応答を特定するパラメータである。「メッセージＩＤ詳細」とは、アプリケーションからネットワークへの要求若しくは応答か、又はネットワークからアプリケーションへの要求若しくは応答かを特定するパラメータである。

「送信先ホスト」及び「送信先ポート」は、外部装置の宛先情報を示すパラメータである。具体的には、「送信先ホスト」はＩＰアドレス（又はドメイン名）であり、「送信先ポート」はネットワークポート番号である。

「プロトコル種別」とは、ＨＴＴＰ、ＨＴＴＰＳ（ＨＴＴＰ ｏｖｅｒ ＳＳＬ）などアプリケーションプロトコルを指定するパラメータである。また、「証明書ＣＮ名」・「認証証明書セット」・「サーバ認証失敗時の動作」・「証明書ＣＮチェック可否」の各パラメータは、ＳＳＬ／ＴＬＳ２０７による暗号通信で使う情報である。暗号通信に必要な情報を一度に指定することで、本発明の実施形態におけるＳＳＬ／ＴＬＳの処理内容を隠蔽する。

「プロキシ利用可否」とは、プロキシ経由で接続するかどうかを指定するパラメータである。プロキシサーバの宛先、本発明の実施形態におけるプロキシ経由の接続の処理内容を隠蔽する。「コンテンツデータ」は、外部装置の通信相手へ届けたいデータの中身を示すものである。なお、上記以外の図中のパラメータ（通信モード・バイブ・予約）については、本発明の実施形態による処理内容とは無関係であるため、説明を省略する。

次に、ネットワーク送信依頼に対する応答データについて、図５を用いて説明する。既に図４で説明した内容については説明を省略する。「送信元」とは、通信モジュールの識別子を示すパラメータであり、このメッセージを受け取るアプリケーションが見る情報である。「送信結果」とは、送信処理を行った結果を示すパラメータである。例えば、応答データ１において送信結果が「０ｘ０１（成功）」であり、応答データのみであるのでコンテンツデータは０バイトであり、アプリデータ４バイトは制御パラメータとして４バイトのみが割り当てられる。

さらに、ネットワーク受信データ共有要求データのフォーマットと例について、図６を用いて説明する。なお、既に図４で説明した内容については説明を省略する。「コンテンツ種別」とは、データの中身に入っている内容を示す情報パラメータである。

さらに、Ｒｅｍｏｔｅのネットワーク受信共有要求に対する応答データのデータフォーマットとその例について、図７を用いて説明する。なお、既に図４で説明した内容については説明を省略する。なお、受信結果の応答データのみであるので、アプリデータ４バイトは制御パラメータとして４バイトのみが割り当てられる。

［第１実施形態］
本発明の第１実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰサーバとして動作する場合の処理内容の手順を図８〜図１１のシーケンス図を用いて以下説明する。図の上部に各処理を行う処理部を示す。

図の左から順に、人（ＴＲＡＮＳ_ＲＸＴＸ１_ＴＡＳＫ）３０１・アプリケーション層プロトコル処理タスク３０２・データキュー３０３・サーバ手順保持部２０２・アプリケーション層パケット処理部２０５・ＨＴＴＰヘッダ管理部２１１・アプリケーション層ペイロード管理部２０８・上位アプリケーションへの振り分け表２０６・ソケットＩＦブリッジ３０４・アプリケーション層とのブリッジ３０５・装置情報とのブリッジ３０６となる。

図８において、人３０１がアプリケーション層プロトコル処理タスク３０２を起動する（ステップＳ１）。そして、アプリケーション層プロトコル処理タスク３０２によりサーバ手順保持部２０２に対し、プロトコル手順開始処理が行われる（ステップＳ２）。サーバ手順保持部２０２はソケットＩＦブリッジ３０４を介して他の装置（ＨＴＴＰクライアント）から接続されるまでデータを受信待ち受けする（ステップＳ３）。

サーバ手順保持部２０２は、最初のパケットを生成し（ステップＳ４）、アプリケーションが使用するメモリ領域（ｈｅａｐ）を確保する。アプリケーション層パケット処理部２０５にはＨＴＴＰリクエスト２０５１を、ＨＴＴＰヘッダ管理部２１１にはリクエストヘッダ２１１１を、アプリケーション層ペイロード管理部２０８にはリクエストボディ２０８１を使用するメモリ領域をそれぞれ確保する。

サーバ手順保持部２０２は、アプリケーション層プロトコル処理タスク３０２からのプロトコル処理実行を受け（ステップＳ５）次の手順を取得する（ステップＳ６）。そして、ソケットＩＦブリッジ３０４を介して他の装置（ＨＴＴＰクライアント）から受信した（ステップＳ８）ＨＴＴＰリクエストパケットを解析する（ステップＳ７）。

なお、パケット解析中にｓｈｏｃｋｌｅｙ内部でエラーが発生した場合のエラー処理について説明する。ソケットエラーの場合は、パケットはサーバ手順保持部２０２へパケット解析終了及びソケットエラーの情報を返し、サーバ手順保持部２０２はパケットを破棄して手順を終了する。

また、タイムアウトエラーの場合は、パケットはサーバ手順保持部２０２へパケット解析完了及びタイムアウトエラー情報を返し、サーバ手順保持部２０２は再送処理を行う。なお、再送処理の内容はプロトコル別に異なる。

さらに、パケット内部エラーの場合は、パケットはエラー情報として保持し、サーバ手順保持部２０２へパケット解析完了及びエラーなし情報を返す。パケットは、次のパケットを作成する際にエラー情報を次のパケットに引き継ぎ、ｃｏｍｐｏｓｅでエラー応答を返す。

アプリケーション層パケット処理部２０５は、ＨＴＴＰヘッダ管理部２１１におけるＨＴＴＰリクエストヘッダを解析する（ステップＳ９）。そして、アプリケーション層パケット処理部２０５は上位アプリケーションへの振り分け表２０６を使用し、リソース識別情報とリソースＭＩＮＥタイプを指定して一致するリソース情報を取得する（ステップＳ１０）。そして、装置情報とのブリッジ３０６を介して投影データを外部装置（例えば投影装置）へ転送してよいかを調べる（ステップＳ１１）。すなわち、アプリケーション層パケット処理部２０５は転送先アプリケーションを特定する。

なお、リソースの検索においてエラーが発生した場合、上位アプリケーションへの振り分け表２０６はアプリケーション層パケット処理部２０５にエラー応答（Ｅ_ＲＳＯＵＲＣＥ_ＩＮＦＯ_ＥＲＲＯＲ_ＲＥＡＯＮＳＮ_ＮＯＴ_ＦＯＵＮＤ・Ｅ_ＲＳＯＵＲＣＥ_ＩＮＦＯ_ＥＲＲＯＲ_ＲＥＡＯＮＳＮ_ＵＮＳＵＰＰＯＲＴ_ＯＰＥＲＡＴＩＯＮ・Ｅ_ＲＳＯＵＲＣＥ_ＩＮＦＯ_ＥＲＲＯＲ_ＲＥＡＯＮＳＮ_ＵＮＳＵＰＰＯＲＴ_ＭＥＤＩＡ）を返す。

また、ステップＳ１１で投影データを転送してよいかを調べた場合に、電力状態が省エネモードである等の理由で転送できない場合に装置情報とのブリッジを介して外部装置がアプリケーション層パケット処理部２０５にエラー応答を返す。

次に、図９において、サーバ手順保持部２０２は、アプリケーション層プロトコル処理タスク３０２からのプロトコル手順実行を受け（ステップＳ１２）次の手順を取得する（ステップＳ１３）。そして、サーバ手順保持部２０２はアプリケーション層パケット処理部２０５を解析し（ステップＳ１４）、アプリケーション層パケット処理部２０５はＨＴＴＰリクエストボディを解析する（ステップＳ１５）。

アプリケーション層パケット処理部２０５は、アプリケーション層とのブリッジ３０５を介してバッファを取得し（ステップＳ１６）、ソケットＩＦブリッジ３０４を介してペイロードデータを受信する（ステップＳ１７）。そして、アプリケーション層パケット処理部２０５は受信したペイロードデータを解析し（ステップＳ１８）、アプリケーション層とのブリッジ３０５を介してアプリケーションへ解析したデータを送信する（ステップＳ１９）。

上記ステップＳ１６からステップＳ１９までの処理は、サブシステム間の通信でありネットワーク受信データ共有の要求コマンドを送信することにより行われる。また、上記ステップＳ１６からステップＳ１９までの処理は、ペイロードの解析が完了するまで繰り返される。

なお、ユーザからコンテンツ用のバッファを取得する場合、ペイロードの解析が完了するまで「ＳＥＭ_ＴＲＡＮＳ_ＣＮＴＮＴ」により排他制御をかける。ペイロードに排他制御がかかっている場合、１秒以内に排他制御が解除されない場合、アプリケーション層パケット処理部２０５はアプリケーション層とのブリッジ３０５を介してアプリケーションへ未検出の応答を返す。

また、アプリケーション層パケット処理部２０５は、ステップＳ１９において、コンテンツバッファの場合はヘッダのみ先にＯＭＡＰへ転送する。転送のタイミングは、チャンクでない場合はユーザのバッファがフルになったとき、ペイロードの解析が完了したときであり、チャンクの場合はユーザのバッファがフルになったとき、１チャンク分のペイロード解析が完了したときである。

次に、図１０において、サーバ手順保持部２０２はアプリケーション層プロトコル処理タスクからのプロトコル手順実行（ステップＳ２０）を受け次の手順を取得する（ステップＳ２１）。そして、サーバ手順保持部２０２はアプリケーション層パケット処理部２０５に対し次のパケットを作成する処理を行う（ステップＳ２２）。アプリケーション層パケット処理部２０５は、アプリケーションからデータを受け取りＨＴＴＰレスポンス２０５２を作成するメモリ領域を確保する（ｈｅａｐ）。

アプリケーション層パケット処理部２０５は、ＨＴＴＰヘッダ管理部２１１に対し次のヘッダを作成する処理を行い（ステップＳ２３）、ＨＴＴＰヘッダ管理部２１１はＨＴＴＰレスポンスヘッダ２１１２を作成するメモリ領域を確保する（ｈｅａｐ）。

またアプリケーション層パケット処理部２０５は、アプリケーション層ペイロード管理部２０８に対し次のペイロードを作成する処理を行い（ステップＳ２４）、アプリケーション層ペイロード管理部２０８はＨＴＴＰレスポンスボディ２０８２を作成するメモリ領域を確保する（ｈｅａｐ）。

なお、レスポンスパケットを作成処理に伴い、アプリケーション層パケット処理部２０５・ＨＴＴＰヘッダ管理部２１１・アプリケーション層ペイロード管理部２０８によるリクエスト処理を終了する（ステップＳ２５〜ステップＳ２７、ｄｅｓｔｒｏｙ）。

サーバ手順保持部２０２は、アプリケーション層パケット処理部２０５においてＨＴＴＰレスポンスパケットを作成し（ステップＳ２８）、上位アプリケーションからの入力データ待ちとなる。そして、アプリケーション層プロトコル処理タスク３０２は、データキュー３０３からのキュー待ちとなる（ステップＳ２９）。

次に、図１１において、サーバ手順保持部２０２は、アプリケーション層プロトコル処理タスク３０２からのプロトコル手順実行を受け（ステップＳ３０）、次の手順を取得する（ステップＳ３１）。そして、サーバ手順保持部２０２は、アプリケーション層パケット処理部２０５においてＨＴＴＰレスポンス２０５２を作成する（ステップＳ３２）。

アプリケーション層パケット処理部２０５は、ＨＴＴＰヘッダ管理部２１１においてＨＴＴＰレスポンスヘッダ２１１２を作成する（ステップＳ３３）。なお、ＯＭＡＰでエラーが発生した場合、ネットワーク受信データ共有の応答コマンドにエラー情報が含まれているので、それをエラー応答として返すことになる。そして、アプリケーション層パケット処理部２０５は、ソケットＩＦブリッジ３０４を介し他の装置（ＨＴＴＰクライアント）へＨＴＴＰレスポンスヘッダ２１１２を送信する（ステップＳ３４）。

次に、サーバ手順保持部２０２は、アプリケーション層プロトコル処理タスク３０２からのプロトコル手順実行を受け（ステップＳ３５）、次の手順を取得する（ステップＳ３６）。そして、サーバ手順保持部２０２は、アプリケーション層パケット処理部２０５においてＨＴＴＰレスポンス２０５２を作成する（ステップＳ３７）。

アプリケーション層パケット処理部２０５は、アプリケーション層ペイロード管理部２０８においてＨＴＴＰレスポンスボディを作成する（ステップＳ３８）。そして、アプリケーション層パケット処理部２０５は、ソケットＩＦブリッジ３０４を介し他の装置（ＨＴＴＰクライアント）へＨＴＴＰレスポンスボディ２０８２を送信する（ステップＳ３９）。その後、アプリケーション層パケット処理部２０５は、アプリケーション層とのブリッジ３０５を介しバッファを解放する（ステップＳ４０）。

次に、サーバ手順保持部２０２は、アプリケーション層プロトコル処理タスク３０２からのプロトコル手順実行を受け（ステップＳ４１）、アプリケーション層パケット処理部２０５に対しセッションを再利用するか確認する（ステップＳ４２）。そして、アプリケーション層パケット処理部２０５は、ＨＴＴＰヘッダ管理部２１１に対しセッションを再利用するか確認する（ステップＳ４３）。

セッションを再利用する場合、セッションクローズせずステップ３の受信待ちへ戻る（ＬＯＯＰ１）。また、セッションを再利用しない場合、セッションクローズしステップ３の受信待ちへ戻る（ＬＯＯＰ１）。

なお、レスポンスパケット送信処理に伴い、アプリケーション層パケット処理部２０５・ＨＴＴＰヘッダ管理部２１１・アプリケーション層ペイロード管理部２０８によるレスポンス処理を終了する（ステップＳ４４〜ステップＳ４６、ｄｅｓｔｒｏｙ）。

そして、サーバ手順保持部２０２は、アプリケーション層プロトコル処理タスク３０２のプロトコル手順終了処理を受け（ステップＳ４５）、ソケットＩＦブリッジ３０４を介して他の端末（ＨＴＴＰクライアント）との接続を切断する（ステップＳ４７）。アプリケーション層プロトコル処理タスク３０２は、接続切断に伴いサーバ手順保持部２０２による処理を終了する（ステップＳ４８、ｄｅｓｔｒｏｙ）。

ここで、ＨＴＴＰヘッダの解析およびＨＴＴＰヘッダの作成以外のサーバ処理は共通部で実現することとする。また、データ受信やセッション再利用受信待ち等のタイムアウトはアプリケーション層手順管理部２０３がプロトコル再送情報表２０４のタイムアウト時間を参照することで実現することとする。

［第２実施形態］
次に本発明の第２実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして動作する場合の処理内容の手順を図１２〜図１９のシーケンス図を用いて以下説明する。図の上部に各処理を行う処理部を示す。

図の左から順に人（ＴＲＡＮＳ_ＲＸＴＸ１_ＴＡＳＫ）４０１・アプリケーション層プロトコル処理タスク４０２・アプリケーション層ＩＮ／ＯＵＴパラメータ情報リスト４０３・ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４・アプリケーション層パケット処理部４０５・ＨＴＴＰヘッダ管理部４０６・ＨＴＴＰクライアント（プロキシ経由接続用）手順保持部４０７・ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８・ソケットＩＦブリッジ４０９・装置情報とのブリッジ４１０、一段下がってＤＮＳクライアント手順保持部４１１となる。

図１２において、アプリケーション層プロトコル処理タスク４０２が人４０１により起動する（ステップＳ１０１）。アプリケーション層プロトコル処理タスク４０２は、「ｒｃｖ_ｄｔｐ」処理（ステップＳ１０２）、「ｓｔａｒｔ Ａｐｐ Ｐｒｏｃ」処理（ステップＳ１０３）の後、アプリケーション層ＩＮ／ＯＵＴパラメータ情報リスト４０３におけるメモリ領域を確保する（ｈｅａｐ）。

アプリケーション層プロトコル処理タスク４０２は、「ｃｒｅａｔｅ Ａｐｐ Ｐｒｏｃ」処理（ステップＳ１０４）の後、装置情報とのブリッジ４１０を介し、外部装置の設定情報を取得する（ステップＳ１０５）。そして、アプリケーション層プロトコル処理タスク４０２は、アプリケーション層ＩＮ／ＯＵＴパラメータ情報リスト４０３に対しパラメータを追加する（ステップＳ１０６）。

上記ステップＳ１０６においては、ＳＨｏｓｔＩｎｆｏ構造体を値として持つ「ＵＡｐｐ Ｌａｙｅｒ Ｐａｒａｍ Ｖａｌｕｅ」構造体をリストに追加する。

「Ｓ Ｈｏｓｔ Ｉｎｆｏ」構造体の「ｆ_ｈｏｓｔ_ｎａｍｅ」として、プロキシを使用する場合、ＩＮＦＯからプロキシサーバ名を取得し、これをセットする。一方、プロキシを使用しない場合、ネットワーク送信依頼のあて先ホストをセットする。

また、「Ｓ Ｈｏｓｔ Ｉｎｆｏ」構造体の「ｆ_ｈｏｓｔ_ｐｏｒｔ」として、プロキシを使用する場合、ＩＮＦＯからプロキシサーバのポート番号を取得し、セットする。一方、プロキシを使用しない場合、ネットワーク送信依頼のあて先ポートをセットする。

アプリケーション層プロトコル処理タスク４０２は、ＤＮＳクライアント手順保持部４１１において処理を行うためのメモリ領域をそれぞれ確保する（ｈｅａｐ）。このとき、あて先がＩＰアドレスのときはＤＮＳ手順を生成しない。「ｇｅｔ Ｉｎｅｔ Ａｄｄｒ」によりバイナリＩＰアドレスへ変換しＨＴＴＰ手順のコンストラクタへ渡す（ネットワークバイトオーダー）。

また、「Ａｐｐ Ｌａｙｅｒ Ｌｉｓｔ」に含まれるＳＨｏｓｔＩｎｆｏ構造体の「ｆｉｓ_ｆｉｘｅｄ」、及び「ｆｉｓ_ｒｅｃｅｉｖｅｄ_ｒｅｓｐｏｎｓｅ」は次のように設定する。すなわち、ＤＮＳを使用する場合は「ＴＲＡＮＳ_ＦＡＬＳＥ」と、ＤＮＳを使用する場合は「ＴＲＡＮＳ_ＴＲＵＥ」と設定する。

また、アプリケーション層プロトコル処理タスク４０２は、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４において処理を行うためのメモリ領域をそれぞれ確保する（ｈｅａｐ）。このとき、ネットワーク送信依頼のメンバをチェックし、プロキシを使用する場合のみＨＴＴＰクライアント（プロキシ認証方式取得用）手順を生成する。

また、アプリケーション層プロトコル処理タスク４０２は、ＨＴＴＰクライアント（プロキシ経由接続用）手順保持部４０７において処理を行うためのメモリ領域をそれぞれ確保する（ｈｅａｐ）。このとき、ネットワーク送信依頼のメンバをチェックし、プロキシかつＨＴＴＰを使用する場合、プロキシ経由接続用の用途で、「Ｃｌｉｅｎｔ Ｐｒｏｃ」のインスタンスを生成する。

さらに、アプリケーション層プロトコル処理タスク４０２は、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８において処理を行うためのメモリ領域をそれぞれ確保する（ｈｅａｐ）。ネットワーク送信依頼のメンバをチェックし、プロキシかつＨＴＴＰを使用する場合の処理手順はＨＴＴＰクライアント（プロキシ経由接続用）手順保持部４０７の場合と同様である。

次に、アプリケーション層プロトコル処理タスク４０２は、新たにアプリケーション層ＩＮ／ＯＵＴパラメータ情報リスト４０３に対しパラメータを追加する（ステップＳ１０７）。このとき、「Ｓ Ｕｓｅｒ Ｄａｔａ」構造体を値として持つ「ＵＡｐｐ Ｌａｙｅｒ Ｐａｒａｍ Ｖａｌｕｅ」構造体をリストに追加する。

アプリケーション層プロトコル処理タスク４０２は、ＤＮＳクライアント手順保持部４１１に対し、プロトコル手順開始処理を行い（ステップＳ１０８）、次いでプロトコル手順実行処理を行い（ステップＳ１０９）、その後プロトコル手順終了処理を行う（ステップＳ１１０）。このとき、名前解決の結果として、「Ａｐｐ Ｌａｙｅｒ Ｐａｒａｍ Ｌｉｓｔ」に含まれる「Ｓ Ｈｏｓｔ Ｉｎｆｏ」構造体の「ｆｉｐｖ４_ａｄｄｒｅｓｓ」、「ｆｉｓ_ｆｉｘｅｄ」をセットする。

上記ステップＳ１１０の処理は、ＤＮＳクライアントの手順が完了するまで繰り返される（ＬＯＯＰ４１）。また、各クライアント手順の終了までにソケットエラーが発生した場合（キャンセルを含む）、次のエラー処理を行う。すなわち、（ａ）実行中の手順と待機中の手順を削除する処理、（ｂ）ネットワーク送信依頼の要求のユーザバッファを解放する処理、（ｃ）ＯＭＡＰにネットワーク送信依頼の応答（ホスト接続失敗・０ｘ０２）を返す処理を行う。

その後、アプリケーション層プロトコル処理タスク４０２は、ＤＮＳクライアント手順保持部４１１による処理を終了し（ステップＳ１１１、ｄｅｓｔｒｏｙ）、「ｕｐｄａｔｅ Ｅｘｅｃｕｔｉｎｇ Ｐｒｏｃ」処理を実行する（ステップＳ１１２）。

ステップＳ１１２において、あて先情報が確定の場合（Ｈｏｓｔ Ｉｎｆｏ→ｆｉｓ_ｆｉｘｅｄがＴＲＡＮＳ_ＴＲＵＥ）、待機中の手順を次に実行する手順とする（ｔｈｅ_ｅｘｅｃｕｔｉｎｇ_ｐｒｏｃに設定する）。

ステップＳ１１２において、あて先情報が未確定の場合（Ｈｏｓｔ Ｉｎｆｏ→ｆｉｓ_ｆｉｘｅｄがＴＲＡＮＳ_ＦＡＬＳＥ）であって、プライマリＤＮＳサーバに問い合わせた結果、応答があった場合（Ｈｏｓｔ Ｉｎｆｏ→ｆｉｓ_ｒｅｃｅｉｖｅｄ_ｒｅｓｐｏｎｓｅがＴＲＡＮＳ_ＴＲＵＥ）、エラー（ホスト接続失敗・０ｘ０２）を返す。

また、プライマリＤＮＳサーバに問い合わせた結果、応答がなかった場合（Ｈｏｓｔ Ｉｎｆｏ→ｆｉｓ_ｒｅｃｅｉｖｅｄ_ｒｅｓｐｏｎｓｅがＴＲＡＮＳ_ＦＡＬＳＥ）、あて先をセカンダリＤＮＳサーバとして、ＤＮＳ手順オブジェクトを生成・実行する。このとき、セカンダリＤＮＳサーバが「０．０．０．０」の場合、エラー（ホスト接続失敗・０ｘ０２）を返す。さらに、セカンダリＤＮＳサーバに問い合わせて名前解決できなかった場合は、エラー（ホスト接続失敗・０ｘ０２）を返す。

次に、図１３において、アプリケーション層プロトコル処理タスク４０２は、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４に対しプロトコル開始処理を行う（ステップＳ１１３）。

ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、ソケットＩＦブリッジ４０９においてソケットを作成し（ステップＳ１１４）、ソケットオプション（接続タイムアウト情報）を設定し（ステップＳ１１５）、接続処理を行い（ステップＳ１１６）、ソケットオプション（送信タイムアウト情報）を設定し（ステップＳ１１７）、ソケットオプション（受信タイムアウト情報）を設定する（ステップＳ１１８）。

ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、パケット生成処理を行い（ステップＳ１１９）、アプリケーション層パケット処理部４０５・ＨＴＴＰヘッダ管理部４０６にリクエスト４０５１及びリクエストヘッダ４０６１を生成するためのメモリ領域をそれぞれ確保する（ｈｅａｐ）。

次に、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ１２０）、次の手順を取得する（ステップＳ１２１）。そして、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層パケット処理部４０５に対し「ｃｏｍｐｏｓｅ（ｇｅｔ Ｎｅｘｔ Ａｃｔｉｏｎで示されたアクション・Ｅ_ＮＥＸＴ_ＡＣＴＩＯＮ_ＣＯＭＰＯＳＥ）」処理を行う（ステップＳ１２２）。

アプリケーション層パケット処理部４０５は、ＨＴＴＰヘッダ管理部４０６に対し解析処理を行う（ステップＳ１２３）。これは、ＯＭＡＰからのネットワーク送信依頼に含まれるＨＴＴＰヘッダを解析するものである。このとき、ネットワーク送信依頼のメンバをチェックし、リクエストＵＲＩを絶対ＵＲＩに変換する。

アプリケーション層パケット処理部４０５は、ＨＴＴＰヘッダ管理部４０６において、リクエストヘッダ４０６１を作成し（ステップＳ１２４）、次いでソケットＩＦブリッジ４０９を介して他の端末に対しリクエストパケットを送信する（ステップＳ１２５）。

次に、図１４において、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ１２６）、次の手順を取得する（ステップＳ１２７）。そして、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層パケット処理部４０５において、リクエスト４０５１を作成する（ステップＳ１２８）。

次いで、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ１２９）、次の手順を取得する（ステップＳ１３０）。そして、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層パケット処理部４０５において次のパケットを作成する処理を行う（ステップＳ１３１）。このときレスポンス４０５２を作成するためのメモリ領域を確保する（ｈｅａｐ）。

アプリケーション層パケット処理部４０５は、ＨＴＴＰヘッダ管理部４０６において次のヘッダを作成する処理を行う（ステップＳ１３２）。このとき、レスポンスヘッダ４０６２を作成するためのメモリ領域を確保する（ｈｅａｐ）。

その後、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層パケット処理部４０５及びＨＴＴＰヘッダ管理部４０６における処理を終了する（ステップＳ１３３、ステップＳ１３４、共にｄｅｓｔｒｏｙ）。

次いで、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層パケット処理部４０５に対し解析処理を行う（ステップＳ１３５）。そして、アプリケーション層パケット処理部４０５は、ソケットブリッジＩＦ４０９を介してＨＴＴＰレスポンスを受信する（ステップＳ１３６）。

アプリケーション層パケット処理部４０５は、ＨＴＴＰヘッダ管理部４０６に対し解析処理を行い（ステップＳ１３７）、認証情報管理部４１２において認証情報を取り出すためのメモリ領域を確保する（ｈｅａｐ）。

このとき、ステータスコードが４１７（Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅ）の場合、ヘッダに認証情報が含まれるので、「Ａｕｔｈ Ｉｎｆｏ」を作成し、「Ａｕｔｈ Ｉｎｆｏ」を値として持つ「Ｕ Ａｐｐ Ｌａｙｅｒ Ｐａｒａｍ Ｖａｌｕｅ」構造体を「Ａｐｐ Ｌａｙｅｒ Ｐａｒａｍ Ｌｉｓｔ」に追加する。

一方、ステータスコードが４１７以外の場合、プロキシ認証なしとみなす。このとき、「Ａｕｔ ｈＩｎｆｏ」を作成せず、「Ａｕｔｈ Ｉｎｆｏ」を値として持つ「Ｕ Ａｐｐ Ｌａｙｅｒ Ｐａｒａｍ Ｖａｌｕｅ」構造体も「Ａｐｐ Ｌａｙｅｒ Ｐａｒａｍ Ｌｉｓｔ」に追加しない。

ＨＴＴＰヘッダ管理部４０６は、アプリケーション層ＩＮ／ＯＵＴパラメータ情報リスト４０３にパラメータを追加する処理を行う（ステップＳ１３８）。次いで、ＨＴＴＰヘッダ管理部４０６は、認証情報管理部４１２において認証データの解析処理を行う（ステップＳ１３９）。

ステップＳ１３９において、「ＴＲＡＮＳ_ＦＡＬＳＥ」が返ってきた場合、「Ｓ Ａｕｔｈ Ｉｎｆｏ→ｆｉｓ_ｆａｉｌｅｄ」を「ＴＲＡＮＳ_ＴＲＵＥ」にする。「ｄｅｃｏｍｐｏｓｅ」が「ＴＲＡＮＳ_ＦＡＬＳＥ」になるのは、次の２通りである。すなわち、（ｅ）サポートしない認証方式のときと、（ｆ）認証情報のフォーマットエラーのときである。

次に、図１５において、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ１４０）、次の手順を取得する（ステップＳ１４１）。そして、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層パケット処理部４０５においてレスポンスの解析処理を行う（ステップＳ１４２）。

次いで、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ１４３）、次の手順を取得する（ステップＳ１４４）。そしてＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４はアプリケーション層パケット処理部４０５における処理を終了し（ステップＳ１４５、ｄｅｓｔｒｏｙ）、アプリケーション層パケット処理部４０５はＨＴＴＰヘッダ管理部４０６における処理を終了する（ステップＳ１４６、ｄｅｓｔｒｏｙ）。

アプリケーション層プロトコル処理タスク４０２は、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４に対し、プロトコル手順終了処理を行い（ステップＳ１４７）、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４はソケットＩＦブリッジ４０９との接続を切断する処理を行う（ステップＳ１４８）。

その後、アプリケーション層プロトコル処理タスク４０２は、ＨＴＴＰクライアント（プロキシ認証方式取得用）手順保持部４０４における処理を終了する（ステップＳ１４９、ｄｅｓｔｒｏｙ）。このとき、「Ａｐｐ Ｐａｒａｍ Ｌｉｓｔ」の「Ｓ Ａｕｔｈ Ｉｎｆｏ→ｆｉｓ−ｆａｉｌｅｄ」を確認して、「ＴＲＡＮＳ_ＴＲＵＥ」の場合、次の処理を行う。

すなわち、（ｇ）ネットワーク送信依頼の応答（プロキシ認証失敗・０ｘ０６）をＯＭＡＰに返す処理、（ｈ）実行中の手順と待機中の手順を削除する処理、（ｉ）ネットワーク送信依頼の要求のユーザバッファを解放する処理である。

その後の処理は、ａｌｔ４２１（ＨＴＴＰクライアントで情報を受け取る・平文データ転送）処理又はａｌｔ４２２（ＨＴＴＰクライアントで情報を受け取る・プロキシ経由接続及びＳＳＬ／ＴＬＳデータ転送）処理に分岐する。

次に、図１６において、上記ａｌｔ４２１（ＨＴＴＰクライアントで情報を受け取る・平文データ転送）処理に分岐した場合の処理手順を説明する。

処理ブロックとして、図の上部左から順にアプリケーション層プロトコル処理タスク４０２・アプリケーション層ＩＮ／ＯＵＴパラメータ情報リスト４０３・ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８・アプリケーション層パケット処理部４０５・ＨＴＴＰヘッダ管理部４０６・認証情報管理部４１２・アプリケーション層ペイロード管理部４１３・ソケットＩＦブリッジ４０９・アプリケーション層とのブリッジ４１４・装置情報とのブリッジ４１０・暗号変換ブリッジ４１５となる。

ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順開始処理を受け（ステップＳ１５０）、ソケットＩＦブリッジ４０９においてソケット作成処理を行う（ステップＳ１５１）。なお、プロトコル手順開始処理にエラーが発生した場合、次のエラー処理を行う。

エラー処理としては、（ｊ）実行中の手順を削除する処理、（ｋ）ネットワーク送信依頼の要求のユーザバッファを解放する処理、（ｌ）ＯＭＡＰにネットワーク送信依頼の応答（ホスト接続失敗・０ｘ０２）を返す処理がある。

次いで、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、ソケットＩＦブリッジ４０９においてソケットオプション（接続タイムアウト情報）を設定し（ステップＳ１５２）、接続処理を行い（ステップＳ１５３）、ソケットオプション（送信タイムアウト情報）を設定し（ステップＳ１５４）、ソケットオプション（受信タイムアウト情報）を設定する（ステップＳ１５５）。

その後、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、リクエストパケット生成処理を行い（ステップＳ１５６）、アプリケーション層パケット処理部４０５・ＨＴＴＰヘッダ管理部４０６・アプリケーション層ペイロード管理部４１３において、リクエスト４０５３・リクエストヘッダ４０６３・リクエストボディ４１３１を作成する処理を行うためのメモリ領域を確保する（ｈｅａｐ）。

次いで、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ１５７）、次の手順を取得する（ステップＳ１５８）。そして、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層パケット処理部４０５においてリクエスト４０５３を作成する処理を行う（ステップＳ１５９）。

アプリケーション層パケット処理部４０５は、アプリケーション層とのブリッジ４１４においｔバッファを解放する処理を行う（ステップＳ１６０）。ここでロケフリの場合のみ、パケットの送信バッファにユーザから取得したコンテンツバッファを使用する。ロケフリの場合、ＨＴＴＰヘッダのサイズが８Ｋを超える場合があるからである。

次いでアプリケーション層パケット処理部４０５は、ＨＴＴＰヘッダ管理部４０６においてリクエストヘッダ４０６３を作成する処理を行う（ステップＳ１６１）。ＨＴＴＰヘッダ管理部４０６は、認証情報管理部４１２に対し「ｓｅｔＵＲＩ」処理を行い（ステップＳ１６２）、次に「ｓｅｔＭｅｔｈｏｄ」処理を行う（ステップＳ１６３）。

ＨＴＴＰヘッダ管理部４０６は、認証情報管理部４１２において認証情報を作成する処理を行う（ステップＳ１６４）。このとき、プロキシを使用する場合のみａｌｔ４３の処理へ分岐する。また、その際、認証に使用するユーザ名とパスワードはＩＮＦＯから取得する。なお、プロキシを使用するか否かは、ＡｕｔｈＩｎｆｏの有無によって判定する。

分岐したａｌｔ４３において、認証情報管理部４１２は装置情報とのブリッジ４１０を介して外部装置から設定値を取得する（ステップＳ１６５）。そして、さらにＢａｓｉｃ認証のときはａｌｔ４３１へ分岐し、ダイジェスト認証のときはａｌｔ４３２へ分岐する。

ａｌｔ４３１においては、認証情報管理部４１２は暗号変換ブリッジ４１５において「ｂａｓｅ６４」でデコードする処理を行う（ステップＳ１６６）。また、ａｌｔ４３２においては、認証情報管理部４１２は暗号変換ブリッジ４１５において乱数を生成する処理を行い（ステップＳ１６７）、次いでダイジェスト計算処理を行う（ステップＳ１６８）。

アプリケーション層パケット処理部４０５は、ソケットＩＦブリッジ４０９を介して、他の装置へリクエストパケットを送信する処理を行い（ステップＳ１６９）、次いでバッファを解放する処理を行う（ステップＳ１７０）。ロケフリの場合のみ、パケットの送信バッファにユーザから取得したコンテンツバッファを使用しているからである。

また、ユーザから取得したコンテンツバッファは、「ｄｈ Ｓｔａｒｔ」処理を行わないと解放されない。そのため、「ｇｅｔ Ｄｈ Ｂｕｆ Ａｓ Ｐａｃｋｅｔ」処理で取得したコンテンツバッファを保持しておき、次の「ｇｅｔ Ｄｈ Ｂｕｆ」が呼ばれたタイミングで、保持しているコンテンツバッファを返す。

さらに、ロケフリの場合、「ｆｒｅｅ Ｄｈ Ｂｕｆ Ａｓ Ｐａｃｋｅｔ」処理を行った後、必ずネットワーク送信依頼の応答を返し、「ｇｅｔ Ｄｈ Ｂｕｆ／ｄｈ Ｓｔａｒｔ」処理が行われるため、コンテンツバッファの解放漏れがない。

次に、図１７において、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ１７１）、次の手順を取得する（ステップＳ１７２）。そして、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層パケット処理部４０５においてリクエスト４０５３を作成する処理を行う（ステップＳ１７３）。

アプリケーション層パケット処理部４０５は、アプリケーション層ペイロード管理部４１３においてリクエストボディ４１３１を作成する処理を行い（ステップＳ１７４）、ソケットＩＦブリッジ４０９を介して他の装置へリクエストボディを送信する処理を行う（ステップＳ１７５）。

次いで、アプリケーション層パケット処理部４０５は、アプリケーション層とのブリッジ４１４においてバッファを解放する処理を行う（ステップＳ１７６）。ここでは、ネットワーク送信依頼の要求コマンドのユーザバッファを解放する。なお、アプリケーション層パケット処理部４０５は、「Ｓ Ｕｓｅｒ Ｄａｔａ」構造体を値として持つ「Ｕ Ａｐｐ Ｌａｙｅｒ Ｐａｒａｍ Ｖａｌｕｅ」構造体をリストから削除する。

さらに、アプリケーション層パケット処理部４０５は、アプリケーション層とのブリッジ４１４においてバッファを取得する処理を行う（ステップＳ１７７）。ユーザからコンテンツ用のバッファを取得する場合、「ＳＥＭ_ＴＲＡＮＳ_ＣＮＴＮＴ」処理により排他をかける。排他がかかっている場合、排他が解除されるのを待つことになる。なお、排他をかけることで複数のコンテンツがＯＭＡＰ転送時に混ざって、ＯＭＡＰ側で見分けがつかなくなることを防ぐことができる。

アプリケーション層パケット処理部４０５は、アプリケーション層とのブリッジ４１４を介して、サブシステム間の通信においてネットワーク送信依頼の応答コマンドを送信する。ただし、最後のネットワーク送信依頼に対する応答については、「Ａｐｐ Ｐａｒａｍ Ｌｉｓｔ」に「Ｓ Ａｕｔｈ Ｉｎｆｏ」がある場合、応答コマンドを送信しない。アプリケーション層パケット処理部４０５は、コンテンツ用バッファの排他を解除する。

アプリケーション層プロトコル処理タスク４０２は、ユーザ待ち処理の後、アプリケーション層ＩＮ／ＯＵＴパラメータ情報リスト４０３にパラメータを追加する処理を行う（ステップＳ１７９）。アプリケーション層プロトコル処理タスク４０２は、「Ｓ Ｕｓｅｒ Ｄａｔａ」構造体を値として持つ「Ｕ Ａｐｐ Ｌａｙｅｒ Ｐａｒａｍ Ｖａｌｕｅ」構造体をリストに追加する。なお、ステップＳ１７１〜ステップＳ１７９までの処理はペイロードの作成が完了するまで繰り返される（ＬＯＯＰ４２）。

次に、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ１８０）、次の手順を取得する（ステップＳ１８１）。そして、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層パケット処理部４０５において次のパケットを作成する処理を行う（ステップＳ１８２）。つまり、レスポンス４０５４を作成するためのメモリ領域を確保する（ｈｅａｐ）。

また、アプリケーション層パケット処理部４０５は、ＨＴＴＰヘッダ管理部４０６において次のヘッダを作成する処理を行う（ステップＳ１８３）。つまり、レスポンスヘッダ４０６４を作成するためのメモリ領域を確保する（ｈｅａｐ）。

さらに、アプリケーション層パケット処理部４０５は、アプリケーション層ペイロード管理部４１３において次のペイロードを作成する処理を行う（ステップＳ１８４）。つまり、レスポンスボディ４１３２を作成するためのメモリ領域を確保する（ｈｅａｐ）。

ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層パケット処理部４０５における処理を終了する（ステップＳ１８５、ｄｅｓｔｒｏｙ）。また、アプリケーション層パケット処理部４０５は、ＨＴＴＰヘッダ管理部４０６・アプリケーション層ペイロード管理部４１３における処理をそれぞれ終了する（ステップＳ１８６、ステップＳ１８７、ｄｅｓｔｒｏｙ）。

次いで、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層パケット処理部４０５において解析処理を行う（ステップＳ１８８）。アプリケーション層パケット処理部４０５は、ソケットＩＦブリッジ４０９に対し「ｒｅｃｖ Ｓｏｃｋｅｔ」処理を行う（ｓテップＳ１８９）。

さらに、アプリケーション層パケット処理部４０５は、ソケットＩＦブリッジ４０９に対し「ｄｅｃｏｍｐｏｓｅ」処理を行う（ステップＳ１９０）。このとき、ステータスコードが４１７（Ｐｒｏｘｙ−Ａｕｔｈｅｎｔｉｃａｔｅ）の場合、「Ａｐｐ Ｐａｒａｍ Ｌｉｓｔ」の「Ｓ Ａｕｔｈ Ｉｎｆｏ→ｆｉｓ_ｆａｉｌｅｄ」を「ＴＲＡＮＳ_ＴＲＵＥ」にする。

また、ステータスコードが４１７以外の場合は、「Ａｐｐ Ｐａｒａｍ Ｌｉｓｔ」の「ＳＡｕｔｈＩｎｆｏ→ｆｉｓ_ｆａｉｌｅｄ」を「ＴＲＡＮＳ_ＦＡＬＳＥ」にする。

また、ＨＴＴＰヘッダ管理部４０６は、「ｄｅｃｏｍｐｏｓｅ」のｏｕｔパラメータの「ｐａｃｋｅｔ_ａｔｔｒ」を使用して、ペイロードのサイズが分かっているか不明かをアプリケーション層パケット処理部４０５に返す。ペイロードサイズが分かっている場合、「ｐａｃｋｅｔ_ａｔｔｒ．ｆ_ｈａｓ_ｐａｙｌｏａｄ_ｓｉｚｅ」は「ＴＲＡＮＳ_ＴＲＵＥ」であり、ペイロードサイズが不明の場合、「ｐａｃｋｅｔ_ａｔｔｒ．ｆ_ｈａｓ_ｐａｙｌｏａｄ_ｓｉｚｅ」は「ＴＲＡＮＳ_ＦＡＬＳＥ」である。

なお、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、「Ａｐｐ Ｐａｒａｍ Ｌｉｓｔ」に「Ａｕｔｈ Ｉｎｆｏ」が含まれる場合、「ＳＡｕｔｈＩｎｆｏ→ｆｉｓ_ｆａｉｌｅｄ」が「ＴＲＡＮＳ_ＴＲＵＥ」であれば、ネットワーク送信依頼の応答（プロキシ認証失敗・０ｘ０６）を、「ＴＲＡＮＳ_ＦＡＬＳＥ」であれば、ネットワーク送信依頼の応答（成功・０ｘ０１）を返す。

次に、図１８において、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ１９１）、次の手順を取得する（ステップＳ１９２）。そして、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層パケット処理部４０５に対し解析処理を行う（ステップＳ１９３）。

アプリケーション層パケット処理部４０５は、アプリケーション層ペイロード管理部４１３に対し、ペイロードのデータフォーマットセット処理を行う（ステップＳ１９４）。このとき、ペイロードサイズが分かっている場合、「ｈａｓ_ｐａｙｌｏａｄ_ｓｉｚｅ」を「ＴＲＡＮＳ_ＴＲＵＥ」と、「ｐａｙｌｏａｄ_ｓｉｚｅ」を「ペイロードサイズ」とセットする。

一方、ペイロードサイズが不明な場合、「ｈａｓ_ｐａｙｌｏａｄ_ｓｉｚｅ」を「ＴＲＡＮＳ_ＦＡＬＳＥ」と、「ｐａｙｌｏａｄ_ｓｉｚｅ」を「０」とセットする。

次いで、アプリケーション層パケット処理部４０５は、アプリケーション層とのブリッジ４１４に対し「ｇｅｔ Ｄｈ Ｂｕｆ」処理を行う（ステップＳ１９５）。このときユーザからコンテンツ用のバッファを取得する場合、ペイロードの解析が完了するまで「ＳＥＴ_ＴＲＡＮＳ_ＣＮＴＮＴ」処理で排他をかける。なお、ステップＳ１９５〜後述するステップＳ１９９までの処理はペイロードの解析が完了するまで繰り返される（ＬＯＯＰ４３）。

次いで、アプリケーション層パケット処理部４０５は、ソケットＩＦブリッジ４０９に対し「ｒｅｃｖ Ｓｏｃｋｅｔ」処理を行う（ステップＳ１９６）。

次に、「ｒｅｃｖ Ｓｏｃｋｅｔ」処理においてエラーが発生したときは、ａｌｔ４４へ分岐する。ここで、アプリケーション層パケット処理部４０５は、アプリケーション層とのブリッジ４１４に対し「ｄｈ Ｓｔａｒｔ」処理を行う（ステップＳ１９７）。つまり、未転送のデータをＯＭＡＰに転送して、ループ（ＬＯＯＰ４３）を抜けることになる。なお、「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ」なしのＨＴＴＰレスポンスを受信しサーバから切断される場合、このパスを通る。

次いで、アプリケーション層パケット処理部４０５は、アプリケーション層ペイロード管理部４１３に対し「ｄｅｃｏｍｐｏｓｅ」処理を行う（ステップＳ１９８）。ここで、ペイロードサイズが分かっている場合、ペイロードを全て受信した段階で「Ｅ_ＰＡＹＲＯＡＤ_ＲＥＳＵＬＴ_ＣＯＭＰＬＥＴＥ」を返し、それまでは「Ｅ_ＰＡＹＲＯＡＤ_ＲＥＳＵＬＴ_ＮＯＴ_ＣＯＭＰＬＥＴＥ」を返す。また、ペイロードサイズが不明な場合、常に「Ｅ_ＰＡＹＲＯＡＤ_ＲＥＳＵＬＴ_ＮＯＴ_ＣＯＭＰＬＥＴＥ」を返す。

次いで、アプリケーション層パケット処理部４０５は、アプリケーション層とのブリッジ４１４に対し「ｄｈ Ｓｔａｒｔ」処理を行う（ステップＳ１９９）。このとき、アプリケーション層パケット処理部４０５は、ヘッダだけ先にＯＭＡＰへ転送する。また、ＯＭＡＰへの転送のタイミングは次の条件を満たす場合である。

その条件は、チャンクでない場合は、ユーザのバッファがフルになったとき、及びペイロードの解析が完了したときであり、チャンクの場合は、ユーザのバッファがフルになったとき、及び１チャンク分のペイロード解析が完了したときである。

その後、アプリケーション層パケット処理部４０５は、ユーザからのコンテンツ用のバッファの排他を解除する。なお、アプリケーション層パケット処理部４０５は、ソケットエラーが発生した場合、ｏｕｔパラメータの「ｅｒｒｏｒ_ｒｅａｓｏｎ」でＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８にエラー理由を返す。

また、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、ソケットエラーが発生した場合、「Ｅ_ＴＡＲＮＳ_ＥＸＥＣＵＴＥ_ＲＥＳＵＬＴ_ＣＯＭＰＬＥＴＥＤ」をアプリケーション層プロトコル処理タスク４０２に返す。

アプリケーション層プロトコル処理タスク４０２は、ネットワークデータ受信共有の応答を受信する。なお、アプリケーション層プロトコル処理タスク４０２は、ソケットエラーで手順を終了した場合、ネットワーク受信データ共有の応答は、「Ａｐｐ Ｐｒｏｔｏｃｏｌ Ｔａｓｋ」処理により破棄する。

次に、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層プロトコル処理タスク４０２からのプロトコル手順実行を受け（ステップＳ２００）、次の手順を取得する（ステップＳ２０１）。そして、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層パケット処理部４０５に対しセッション再利用を問い合わせる処理を行う（ステップＳ２０２）。

アプリケーション層パケット処理部４０５は、ＨＴＴＰヘッダ管理部４０６に対し「ｋｅｅｐ Ａｌｉｖｅ」問い合わせ処理を行う（ステップＳ２０３）。その後、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、アプリケーション層パケット処理部４０５における処理を終了し（ステップＳ２０４、ｄｅｓｔｒｏｙ）、アプリケーション層パケット処理部４０５は、ＨＴＴＰヘッダ管理部４０６及びアプリケーション層ペイロード管理部４１３における処理を終了する（ステップＳ２０５、ステップＳ２０６、ｄｅｓｔｒｏｙ）。

ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、「ｋｅｅｐ Ａｌｉｖｅ」ありの場合、ａｌｔ４５へ分岐する。ここで、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、パケットを生成する処理を行う（ステップＳ２０７）。つまり、ヘッダ、ペイロードを持つパケットのインスタンスを作成する。

このとき、「ｆｉｓ_ｓｅｃｕｒｅｄ」が「ＴＡＲＮＳ_ＴＲＵＥ」の場合、「Ａｐｐ Ｌａｙｅｒ Ｐａｃｋｅｔ・ｓｅｔ Ｌｏｗ Ｌａｙｅｒ Ｓｅｃｕｒｅｄ」を呼び出し、セキュア通信を継続して行えるようにする。

次に、図１９において、セッション再利用なしの場合（ａｌｔ４６）とセッション再利用ありの場合（ａｌｔ４７）に分岐するそれぞれの処理について説明する。

セッション再利用なしの場合（ａｌｔ４６）、アプリケーション層プロトコル処理タスク４０２は、「ｃｌｅａｒ Ａｐｐ Ｐｒｏｃ」処理（ステップＳ２０８）の後、アプリケーション層とのブリッジ４１４においてネットワーク受信データ要求のバッファを解放する処理を行う（ステップＳ２０９）。

次いで、アプリケーション層プロトコル処理タスク４０２は、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８に対し、プロトコル手順終了処理を行い（ステップＳ２１０）、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、ソケットＩＦブリッジ４０９に対し接続を切断する処理を行う（ステップＳ２１１）。

そして、アプリケーション層プロトコル処理タスク４０２は、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８及びアプリケーション層ＩＮ／ＯＵＴパラメータ情報リスト４０３における処理を終了する（ステップＳ２１２、ステップＳ２１３、ｄｅｓｔｒｏｙ）。このとき、リストに残っている「Ｓ Ｈｏｓｔ Ｉｎｆｏ」構造体を値として持つ「Ｓ Ａｐｐ Ｌａｙｅｒ Ｐａｒａｍ」構造体と、「Ｓ Ａｕｔｈ Ｉｎｆｏ」構造体を値として持つ「Ｓ Ａｐｐ Ｌａｙｅｒ Ｐａｒａｍ」構造体を削除する。そして、ステップＳ１０２（ｒｃｖ_ｄｔｐ）の処理へ戻る。

一方、セッション再利用ありの場合（ａｌｔ４７）、「ｔｒｃｖ_ｄｔｑ」処理（ステップＳ２１４）の後、さらに分岐する（ａｌｔ４７１、ａｌｔ４７２）。Ｅ_ＯＫ以外の場合（ａｌｔ４７１）、「ｃｌｅａｒＡｐｐＰｒｏｃ」処理を行い、ステップＳ１０２の処理（ｒｃｖ_ｄｔｐ）へ戻る。

また、Ｅ_ＯＫの場合（ａｌｔ４７２）、さらに分岐する（ａｌｔ４７２１、ａｌｔ４７２２）。あて先のアドレスとポート番号が異なる場合（ａｌｔ４７２１）、「ｃｌｅａｒ Ａｐｐ Ｐｒｏｃ」処理を行い、ステップＳ１０２の処理（ｒｃｖ_ｄｔｐ）へ戻る。

あて先のアドレスとポート番号が同じ場合（ａｌｔ４７２２）、アプリケーション層プロトコル処理タスク４０２は、ＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８に対し「ｉｓ Ｃｏｎｎｅｃｔｉｏｎ Ｅｓｔａｂｌｉｓｈｅｄ」処理を行う（ステップＳ２１５）。そしてＨＴＴＰクライアント（プロトコルデフォルト）手順保持部４０８は、ソケットＩＦブリッジ４０９に対しサーバとの接続維持を確認する（ステップＳ２１６）。

その後、さらに処理は分岐する（ａｌｔ４７２２１、ａｌｔ４７２２２）。接続が維持されている（ｉｓ Ｃｏｎｎｅｃｔｅｄの戻りが「ＴＲＡＮＳ_ＴＲＵＥ」）の場合（ａｌｔ４７２２１）、ステップＳ１０３の処理（ｓｔａｒｔ Ａｐｐ Ｐｒｏｃ）へ戻る。この場合、実行中の手順が既に存在するので、「ｅｘｃｕｔｅ」処理までスキップされる。

一方、接続が維持されていない（ｉｓ Ｃｏｎｎｅｃｔｅｄの戻りが「ＴＲＡＮＳ_ＦＡＬＳＥ」）の場合（ａｌｔ４７２２２）、「ｃｌｅａｒ Ａｐｐ Ｐｒｏｃ」処理を行い、ステップＳ１０２の処理（ｒｃｖ_ｄｔｐ）へ戻る。

［第３実施形態］
次に本発明の第３実施形態のネットワーク制御装置を搭載した装置がＨＴＴＰクライアントとして暗号通信を行う場合の処理内容の手順を図２０〜図２３のシーケンス図を用いて以下説明する。図の上部に各処理を行う処理部を示す。なお、アプリケーションから受け取ったデータからＨＴＴＰリクエストパケットを作成する処理内容についての説明は、第２実施形態と同様であるので省略し、暗号通信処理を中心に説明する。

本発明の第３実施形態と第２実施形態との違いは、第３実施形態においては暗号通信を行うためにＳＳＬ／ＴＬＳのセッションの開始および終了処理を行う点にある。つまり、データの送受信にＳＳＬ／ＴＬＳを使用し、データを暗号化して送信、そして復号して受信という操作を行う点である。なお、図４で説明したネットワーク送信依頼要求の属性（証明書ＣＮ名・認証証明書セット・サーバ認証失敗時の動作・証明書ＣＮチェック可否）により暗号化通信の手続をすべて隠蔽する。

図の左から順に人（ＴＲＡＮＳ_ＲＸＴＸ１_ＴＡＳＫ）５０１・アプリケーション層プロトコル処理タスク５０２・クライアント手順保持部５０６・アプリケーション層パケット処理部５０７・アプリケーション層ペイロード管理部５０８・ＨＴＴＰヘッダ管理部５１１・ソケットＩＦブリッジ５０３・アプリケーション層とのブリッジ５０４・ＳＳＬ／ＴＬＳ５０５となる。

人５０１からのタスク起動を受け、アプリケーション層プロトコル処理タスク５０２が起動される（ステップＳ４０１）。アプリケーション層プロトコル処理タスク５０２は、データキュー待ちを行う（ステップＳ４０２）。キュー待ちは、ユーザからの割り込みによりデータキューへセットする。このとき、サブシステム間の通信において図４で説明したネットワーク送信依頼要求データを受信する。

なお、デバイスヘッダの場合、分割データサイズとしてＯＭＡＰ省エネ０がセットされ、ＥＯＦは「０ｘ００」である。一方、アプリヘッダの場合、アプリデータサイズとしてＯＭＡＰ通信が通信データサイズをセットする。このときのあて先は「０ｘ０００３（ＲＸＴＸ３）」であり、制御メッセージは「０ｘ０２」であり、メッセージＩＤ詳細が「０ｘ０Ｄ」であり、通信モードが「０ｘ００」であり、バイブが「０ｘ００」である。

その後、「ｈａｎｄｌｅ Ｄａｔａ Ｑｕｅｕｅ Ｅｖｅｎｔ」（ステップＳ４０３）・「ｈａｎｄｌｅ Ｕｓｅｒ Ｅｖｅｎｔ」（ステップＳ４０４）を経て、「ｓｔａｒｔ Ａｐｐ Ｐｒｏｃ」の関数を実行する（ステップＳ４０５）。この関数により「ｏｐｅｎ_ｅｒｒｏｒ_ｒｅａｓｏｎ」を定義し、呼び出される関数によりアウトパラメータで引き渡す。

アプリケーション層プロトコル処理タスク５０２は、クライアント手順保持部５０６に対しコンストラクタによりクライアント手順を処理するメモリ領域を確保する（ｈｅａｐ）。このとき、ＳＳＬ通信を行うかどうかを判断するフラグを第３引数によりセットする。そして、アプリケーション層プロトコル処理タスク５０２は、クライアント手順保持部５０６に対し「ｏｐｅｎ」により開始処理を行う。

クライアント手順保持部５０６は、アクションメソッドにより開始処理を行う（ステップＳ４０６）。そして、クライアント手順保持部５０６は、ソケットＩＦブリッジ５０３にソケットを作成し、外部の「ＳＯＣＫ_Ｓｏｃｋｅｔ」を呼び出す（ステップＳ４０７）。クライアント手順保持部５０６は、クライアントのプロトコル手順開始処理を行う（ステップＳ４０８）。

次に、クライアント手順保持部５０６は、ソケットＩＦブリッジ５０３に対しソケットオプションを設定し、外部の「ＳＯＣＫ_Ｓｅｔ Ｓｏｃｋ Ｏｐｔｉｏｎ」を呼び出す（ステップＳ４０９）。そして、クライアント手順保持部５０６は、ソケットＩＦブリッジ５０３を介し外部装置と接続する（ステップＳ４１０）。このとき、外部の「ＳＯＣＫ_Ｃｏｎｎｅｃｔ」を呼び出す。

クライアント手順保持部５０６は、ＳＳＬ／ＴＬＳ５０５に対しＳＳＬ／ＴＬＳセッションの開始処理を行う（ステップＳ４１１）。このとき、サブシステム間通信のネットワーク送信依頼要求データのパラメータを参照し、プロトコル種別がＨＴＴＰＳ（０ｘ０２）のときに「ＴＬＳ_Ｏｐｅｎ Ｓｏｃｋｅｔ」を呼び出す。また、このタイミングで属性が「ｆｉｓ_ｓｅｃｕｒｅｄ」によりＳＳＬ／ＴＬＳであることを保持しておく。

クライアント手順保持部５０６は、アプリケーション層パケット処理部５０７・アプリケーション層ペイロード管理部５０８・ＨＴＴＰヘッダ管理部５１１に、ＨＴＴＰリクエスト５０５１・リクエストボディ５０８１・リクエストヘッダ５１１１を作成するためのメモリ領域を確保する（ｈｅａｐ）。また、クライアント手順保持部５０６は、アプリケーション層パケット処理部５０７に対しセキュア通信であることをセットする（ステップＳ４１２）。

なお、クライアント手順保持部５０６は、アプリケーション層プロトコル処理タスク５０２へのエラー応答時は、「ｓｅｎｄ Ｅｒｒｏｒ Ｒｅｓｐｏｎｓｅ」でエラー応答を返す。ＯＭＡＰへ応答する送信結果との対応は「０ｘ０１」が成功、「０ｘ０２」がホストへの接続が失敗、「０ｘ０３」がＳＳＬ接続が失敗、「０ｘ０４」がサーバ認証が失敗、「０ｘ０５」がクライアント認証が失敗、「０ｘ０６」がプロキシ認証が失敗、「０ｘ０７」がデータ通信が失敗という対応関係になる。

次に、クライアント手順保持部５０６は、アプリケーション層プロトコル処理タスク５０２からのプロトコル手順実行を受け（ステップＳ４１３）、次の手順を取得する（ステップＳ４１４）。そして、クライアント手順保持部５０６は、アプリケーション層パケット処理部５０７においてＨＴＴＰリクエスト５０５１を作成する（ステップＳ４１５）。

また、アプリケーション層パケット処理部５０７は、ＨＴＴＰヘッダ管理部５１１においてリクエストヘッダ５１１１を作成し（ステップＳ４１６）、ＳＳＬ／ＴＬＳ５０５を介して暗号化送信処理を開始する（ステップＳ４１７）。このとき、「ｆｉｓ_ｌｏｗ_ｌａｙｅｒ_ｓｅｃｕｒｅｄ（ＴＲＡＮＳ_ＴＲＵＥ）」の場合、「ＴＬＳ_ＷｒｉｔｅＳｏｃｋｅｔ」をコールする。また、ｆｉｓ_ｌｏｗ_ｌａｙｅｒ_ｓｅｃｕｒｅｄ（ＴＲＡＮＳ_ＦＡＬＳＥ）」の場合、「ＳＯＣＫ_Ｗｒｉｔｅ」をコールする。

次に、図２１において、クライアント手順保持部５０６は、アプリケーション層プロトコル処理タスク５０２からのプロトコル手順実行を受け（ステップＳ４１８）、次の手順を取得する（ステップＳ４１９）。そして、クライアント手順保持部５０６は、アプリケーション層パケット処理部５０７においてＨＴＴＰリクエスト５０５１を作成する（ステップＳ４２０）。

アプリケーション層パケット処理部５０７は、アプリケーション層ペイロード管理部５０８においてリクエストボディ５０８１を作成する（ステップＳ４２１）。また、アプリケーション層パケット処理部５０７は、ＳＳＬ／ＴＬＳ５０５に対し暗号化送信処理を行う（ステップＳ４２２）。

さらに、アプリケーション層パケット処理部５０７は、ソケットＩＦブリッジ５０３に対し、バッファ解放処理（ステップＳ４２３）、バッファ取得処理（ステップＳ４２４）、送信処理（ステップＳ４２５）を行う。このとき、アプリケーション層パケット処理部５０７は、ネットワーク送信依頼応答データを送信する。送信元は「ＴＲＡＮＳ_ＲＸＴＸ３（０ｘ０００３）」であり、送信結果は成功（０ｘ０１）である。

また、このとき、デバイスヘッダとしては、分割データサイズが４バイトであり、ＥＯＦは「０ｘ００」である。一方、アプリヘッダとしては、アプリデータサイズが４バイトであり、あて先は「０ｘ０００１」であり、制御メッセージＩＤは「０ｘ０３」であり、メッセージＩＤ詳細が「０ｘＯＤ」であり、通信モードが「０ｘ００」であり、バイブが「０ｘ００」である。

次に、アプリケーション層パケット処理部５０７は、戻り値を決定する（ステップＳ４２６）。ここで、ＯＭＡＰから送られてくるデータが分割データの場合、次のように戻り値が決定され「ｅｘｅｃｕｔｅ」からパケットの「ｃｏｍｐｏｓｅ」処理を繰り返すこととなる。すなわち「Ａｐｐ Ｌａｙｅｒ Ｐａｙｒｏａｄ」の戻り値は「Ｅ_ＰＡＹＲＯＡＤ_ＲＥＳＵＬＴ_ＮＯＴ_ＣＯＭＰＬＥＴＥＤ」であり、「Ａｐｐ Ｌａｙｅｒ Ｐａｃｋｅｔ」の戻り値は「Ｅ_ＰＡＣＫＥＴ_ＲＥＳＵＬＴ_ＮＯＴ_ＣＯＭＰＬＥＴＥ_ＷＡＩＴ_ＩＮＰＵＴ」である。

次に、クライアント手順保持部５０６は、アプリケーション層プロトコル処理タスク５０２からのプロトコル手順実行を受け（ステップＳ４２７）、次の手順を取得する（ステップＳ４２８）。そして、クライアント手順保持部５０６は、アプリケーション層パケット処理部５０７・アプリケーション層ペイロード管理部５０８・ＨＴＴＰヘッダ管理部５１１においてレスポンスパケットを作成する処理を行うが、上記の通り、この点については第２実施形態と同様であるので説明を省略する（ステップＳ４２９〜ステップＳ４４２）。

次に、図２２において、クライアント手順保持部５０６は、アプリケーション層パケット処理部５０７において、ステップＳ４３７で作成されたＨＴＴＰレスポンス５０５３を解析する処理を行う（ステップＳ４４３）。アプリケーション層パケット処理部５０７は、ＳＳＬ／ＴＬＳ５０５を介して復号されたデータを受信する（ステップＳ４４４）。アプリケーション層パケット処理部５０７は、ＨＴＴＰヘッダ管理部５１１においてレスポンスヘッダ５１１３を解析する（ステップＳ４４５）。

次に、図２３において、クライアント手順保持部５０６は、アプリケーション層プロトコル処理タスク５０２からのプロトコル手順実行を受け（ステップＳ４４６）、次の手順を取得する（ステップＳ４４７）。そして、クライアント手順保持部５０６は、アプリケーション層パケット処理部５０７に対し解析処理を開始する（ステップＳ４４８）。

アプリケーション層パケット処理部５０７は、アプリケーション層とのブリッジ５０４を介しバッファを取得する（ステップＳ４４９）。このとき、ＨＴＴＰヘッダのみ先にＯＭＡＰへ送る。そして、アプリケーション層パケット処理部５０７は、アプリケーション層とのブリッジ５０４を介し送信処理を行い（ステップＳ４５０）、ＳＳＬ／ＴＬＳ５０５を介し復号されたデータを受信する（ステップＳ４５１）。

アプリケーション層パケット処理部５０７は、アプリケーション層ペイロード管理部５０８に対し解析処理を行い（ステップＳ４５２）、アプリケーション層とのブリッジ５０４を介し送信処理を行う（ステップＳ４５３）。

次に、クライアント手順保持部５０６は、アプリケーション層プロトコル処理タスク５０２からのプロトコル手順実行を受け（ステップＳ４５４）、次の手順を取得する（ステップＳ４５５）。そして、クライアント手順保持部５０６はアプリケーション層パケット処理部５０７における処理を終了し（ステップＳ４５６、ｄｅｓｔｒｏｙ）、アプリケーション層パケット処理部５０７はＨＴＴＰヘッダ管理部５１１における処理を終了し（ステップＳ４５７、ｄｅｓｔｒｏｙ）、アプリケーション層ペイロード管理部５０８における処理を終了する（ステップＳ４５８、ｄｅｓｔｒｏｙ）。

最後に、クライアント手順保持部５０６は、アプリケーション層プロトコル処理タスク５０２からのプロトコル手順終了を受け（ステップＳ４５９）、暗号通信セッションをクローズする（ステップＳ４６０）。そして、クライアント手順保持部５０６は、ソケットＩＦブリッジ５０３に対して接続を切断する処理を行う（ステップＳ４６１）。アプリケーション層プロトコル処理タスク５０２は、クライアント手順保持部５０６における処理を終了する（ステップＳ４６２）。

本発明は、プロトコルヘッダ解析手段が、プロトコル処理手順制御手段によるセッション再利用するか否かを指定できることを特徴としてもよい。これにより、通信プロトコル毎にセッション再利用の仕組みを実装する必要がなく工数の削減を実現することが可能となる。

本発明は、上位アプリケーションインターフェースは、暗号通信を行うか否かを指定できることを特徴としてもよい。これにより、通信プロトコル毎に暗号通信の実装を行う必要がなく工数の削減を実現することが可能となる。

本発明は、上位アプリケーションインターフェースが、中継器を経由する否かを指定できることを特徴としてもよい。これにより、プロトコル毎にプロキシサーバ接続など中継器を経由するための実装を行う必要がなく工数の削減を実現することが可能となる。

本発明は、上位アプリケーションインターフェースが、通信相手をドメイン名で指定できることを特徴としてもよい。これにより、プロトコル毎にＤＮＳリゾルバによる名前解決の制御を行う必要がなく工数の削減を実現することが可能となる。

本発明は、プロトコルヘッダ解析手段が、複数の通信プロトコルのヘッダ情報を上位アプリケーションへ渡すことを特徴としてもよい。これにより、ＨＴＴＰプロトコルのように、ヘッダの中に転送方式などの通信制御情報とそれ以外の情報が混在するプロトコルに対して、通信制御に係る処理を済ませてからそれ以外の情報をアプリケーションへ渡すことになるので、アプリケーション側の開発工数の削減を実現することが可能となる。

本発明は、上位アプリケーションインターフェースにより複数の端末から受け取った要求から複数のプロトコル処理手順を組み合わせてプロトコル通信処理を実行するための対応表を備えることを特徴としてもよい。これにより、複数の通信プロトコルを組み合わせて機能実現する場合の工数の削減を実現することが可能となる。

本発明は、プロトコル解析手段が、通信プロトコルのペイロードのデータフォーマットを個別に解析するペイロード解析手段をさらに備えることを特徴としてもよい。これにより、ＪＳＯＮ、ＸＭＬ、ＭＩＢ等ネットワークで送受信するデータフォーマットの拡張だけを行えば、これまでの通信プロトコルとの組み合わせで機能実現が可能となるので工数の削減を実現することが可能となる。

搭載された通信プロトコルにより機器情報の設定変更および取得を行う機器情報管理部をさらに備えることを特徴としてもよい。これにより、ネットワーク制御装置で扱う機器情報が増えてもプロトコル毎に対応が必要ないため工数の削減を実現することが可能となる。さらに、機器情報の変更による通信プロトコルの品質低下することがない。

なお、上述する各実施の形態は、本発明の好適な実施の形態であり、本発明の要旨を逸脱しない範囲内において種々変更実施が可能である。

１ ネットワーク制御装置
２ 投影装置
３ 入力装置
１１ 通信プロセッサ
１２ メインプロセッサ
１３ 外部装置
２０１ クライアント手順保持部
２０２ サーバ手順保持部
２０３ アプリケーション層手順管理部
２０５ アプリケーション層パケット処理部
２０６ 上位アプリケーション振り分け表
２０７ ＳＳＬ／ＴＬＳ
２０８ アプリケーション層ペイロード管理部
２０９ アプリケーション層ヘッダ管理部
２１０ ＤＮＳヘッダ管理部
２１１ ＨＴＴＰヘッダ管理部
２１２ ＰＪＬｉｎｋヘッダ管理部
２１３ ＤＨＣＰｖ４ヘッダ管理部
２１４ ＳＮＭＰヘッダ管理部
２１５ 通信データフォーマット管理部
２１６ 機器情報管理部
２１７ 機器情報
２１８ 認証情報管理部
２１９ 入出力データ保持部

特表２００４−５０６９７７号公報 特開２００４−００５５０３号公報

Claims (9)

1. 複数の端末とネットワーク通信を行うネットワークインターフェースと、
   複数の通信プロトコルを利用する上位アプリケーションと通信を行う上位アプリケーションインターフェースと、
   前記複数の通信プロトコルにより前記複数の端末とネットワーク通信を行うためプロトコル処理手順の複数を制御するプロトコル処理手順制御手段と、
   前記複数の通信プロトコルに基づいてプロトコル通信処理を実行するプロトコル通信処理手段とを備え、
   前記プロトコル通信処理手段は前記複数の通信プロトコルがそれぞれ有する複数のプロトコルヘッダを管理するプロトコルヘッダ管理手段を備え、
   前記プロトコル通信処理手段は、受け取ったデータの特徴と該データを上位アプリケーションへ転送する転送条件とを対応付けた対応表に基づいて、該データを転送する上位アプリケーションを特定する
   ことを特徴とするネットワーク制御装置。
2. 前記プロトコル通信処理手段は、前記複数の端末から受け取った要求から前記プロトコル処理手順の複数を組み合わせてプロトコル通信処理を実行する
   ことを特徴とする請求項１記載のネットワーク制御装置。
3. 前記プロトコルヘッダ管理手段は、前記プロトコル処理手順制御手段によるセッション再利用するか否かを指定する機能を有することを特徴とする請求項１又は２記載のネットワーク制御装置。
4. 前記上位アプリケーションインターフェースは、暗号通信を行うか否かを指定できることを特徴とする請求項１から３のいずれか１項に記載のネットワーク制御装置。
5. 前記上位アプリケーションインターフェースは、中継器を経由するか否かを指定できることを特徴とする請求項１から４のいずれか１項に記載のネットワーク制御装置。
6. 前記上位アプリケーションインターフェースは、通信相手をドメイン名で指定できることを特徴とする請求項１から５のいずれか１項に記載のネットワーク制御装置。
7. 前記プロトコルヘッダ管理手段は、前記複数の通信プロトコルのヘッダ情報を上位アプリケーションへ渡す機能を有することを特徴とする請求項１から６のいずれか１項に記載のネットワーク制御装置。
8. 前記プロトコル通信処理手段は、前記複数の通信プロトコルがそれぞれ有するペイロードのデータフォーマットを管理するペイロード管理手段を備えることを特徴とする請求項１から７のいずれか１項に記載のネットワーク制御装置。
9. 搭載された通信プロトコルにより機器情報の設定変更および取得を行う機器情報管理部をさらに備えることを特徴とする請求項１から８のいずれか１項に記載のネットワーク制御装置。

Images