JP2006178976A - ホームネットワークにおけるデバイス及びユーザ認証システム並びに方法 - Google Patents

Abstract

【課題】本発明は、ホームネットワークにおけるデバイス認証システム及びその方法を提供する。
【解決手段】本発明は、制御デバイスの制御に従ってサービスコンテンツを提供するサービスデバイスと、各デバイスに対する認証情報に従って各デバイスに対するネットワークを設定するホームサーバと、各制御デバイスの性格に応じてサービス許可に対する情報を有する許可サーバと、ホームサーバを介してネットワーク認証を行い、要請されたサービスコンテンツに対する許可／不許可に従って、サービスデバイスから当該サービスコンテンツの提供を受ける制御デバイスとを備える。これにより、レガシーデバイスまたはゲストデバイスなどのような制御デバイスに対する認証とネットワーク設定を同時に実現することができる。
【選択図】図２

Description

本発明は、ホームネットワークにおけるデバイス認証システム並びに方法に係り、特に、各デバイスとユーザに対する接近権限に差別化を図って認証するホームネットワークにおけるデバイス及びユーザ認証システム並びに方法に関する。

ホームネットワークとは、家庭内で情報家電製品をネットワークで連結して、時間と場所に拘束されずに自由に使用できるようにする物理的なネットワークの技術である。ホームネットワークの構築対象は、アナログ型ではなくデジタル機器であって、ホームネットワークにおいてインターネットで作動可能な冷蔵庫や洗濯機、デジタルＴＶ、デジタルカムコーダ、カメラ、コンピュータ、エアコンなどがすべて連結可能である。転送技術としては、有線及び無線技術をすべて活用することができる。近年、研究が盛んに行われている無線技術には、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）を用いるホームＲＦ、Ｂｌｕｅｔｏｏｔｈ、無線ＬＡＮ、赤外線を利用したＩｒＤＡなどがある。

一方、ホームネットワークでは、デバイス間またはサーバとデバイス間のデータ通信において、受信側では送信側のメッセージが正当なものであるか、あるいは送信側が正当なユーザであるかに対する確認及び認証が必要である。同時に、サーバとデバイス間の通信においては、各デバイスがサーバとの正常な通信を行なうために、まず、登録し認証を受けることが必要であり、この際にも、相互間の通信のための様々な認証方法が考えられている。

一般のホームネットワークは、一つ以上のデバイスとデバイスを管理するホームサーバとで構成される。デバイスは、家庭で使用される電子製品などであり、例えば、洗濯機、冷蔵庫、エアコン、ＴＶ、オディオシステムである。ここで、ホームサーバとデバイス間は有無線通信手段によって連結され、サーバからの指示に従って各デバイスが制御される。

なお、ホームサーバと各デバイス間は、有線ラインを介して連結することも可能である。なお、ホームサーバと各デバイス間の無線通信手段としては、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）（Ｗｉｒｅｌｅｓｓ ＬＡＮ）、Ｂｌｕｅｔｏｏｔｈ、赤外線通信（ＩｒＤＡ）などが考えられる。

このように、ホームサーバがデバイスを制御するためには、デバイスが最初に設置される時に当該デバイスをホームサーバに登録することが必要であり、ホームサーバとデバイス間の通信手段が無線である場合には、相互間の通信データの保安及びデバイスの認証のための作業が必要となる。即ち、無線環境では、デバイス認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）が必須的に要求される基本的な保安サービスであり、これは、各デバイスに対してサーバに接続することを許可するために、正当なデバイスであるか否かを判断するためのものである。

従来のホームネットワーク認証方式には、チケット方式（ｔｏｋｅｎ方式）、接続制御リスト（Ａｃｃｅｓｓ ｃｏｎｔｒｏｌ Ｌｉｓｔ；ＡＣＬ）による方法、動的ホスト設定プロトコル（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ；以下、「ＤＨＣＰ」という。）による方法、イーサネット（登録商標）におけるポイントツーポイントプロトコル（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ ｏｎ Ｅｔｈｅｒｎｅｔ(登録商標））（以下、「ＰＰＯＥ（ＰＰｏＥ）」という。）による方法、ＩＰアドレス自動設定を用いて認証を行なわない方法などがある。

まず、チケット方式（ｔｏｋｅｎ方式）は、転送サービスに幾つかの種類の接続権限に対する所有を指定する。この時、ユーザは、サービスの提供を受ける前に（つまり、接続する前に）管理システムからチケットを取得する必要があり、このチケットは、接続時間まで指定することができる。しかし、チケット方式は、チケットの管理及び適用が難しいという短所がある。

ＡＣＬによる方法は、ユーザに対するアクセスリストに応じて接続権限が異なるようにする方法である。しかし、この方法は、デバイスとユーザ間の連係がなされておらず、管理が難しいという短所がある。

ＤＨＣＰを介する認証方法は、ＤＨＣＰプロトコルに追加的に認証アルゴリズムを使用する方法である。しかし、キー分配が難しいという短所があり、通信のための二つの装置（即ち、クライアントとサーバ）間のプロトコルの互換性がないという短所がある。

ＰＰＰＯＥを介した認証方法は、外部接続ネットワークの認証方法であり、ＰＰＰリンク及びイーサネット（登録商標）上のＰＰＰプロトコルを使用する。しかし、ソースルーティングを介したプロセッシングオーバヘッド（ｐｒｏｃｅｓｓｉｎｇ ｏｖｅｒｈｅａｄ）があるという短所があり、付加的なパケットヘッドによるプロセッシングオーバヘッドがあるという短所がある。

一方、ＩＰアドレス自動設定や認証のないネットワーク設定のような認証を行なわない方法は、誰もが使用権限を自由に持つことができる反面、ユーザすべてに同じ権限を与えることが、プライベート侵害などの問題をもたらす。
その結果、ホームネットワークの効率的な実現のために、デバイスアクセス時のユーザ及び当該デバイスに対する効果的な認証方法が切実に要求されている。

本発明は、前記のような従来の問題点を解決するためになされたものであって、その目的は、ユーザがホームネットワークのサービスを受ける際及びデバイスをホーム内で接続する際に、ユーザ及びデバイスに対する認証を同時に行なうホームネットワークにおけるデバイス及びユーザ認証システム並びに方法を提供することである。

本発明の他の目的は、ホームネットワークの各コンテンツに対してユーザまたはデバイス毎に接近権限を与えるホームネットワークにおいて、デバイス及びユーザ認証システム並びに方法を提供することである。

本発明のさらに他の目的は、ＤＨＣＰサーバとＰＰＰＯＥサーバをホームサーバ内で同時に実現することで、様々な種類のデバイスに対する効果的な認証を行うことができるホームネットワークにおいて、デバイス及びユーザ認証システム並びに方法を提供することである。

本発明のさらに他の目的は、ホームネットワークの各デバイス及びユーザに対する認証とネットワーク設定手続きを同時に行なうことができるホームネットワークにおけるデバイス及びユーザ認証システム並びに方法を提供することである。

前述した目的を達成するための本発明に係るシステムは、ホームサーバを介して一つ以上のデバイスが管理されるホームネットワークシステムにおいて、制御デバイスの制御に従ってサービスコンテンツを提供するサービスデバイスと、前記各デバイスに対する認証情報を有し、前記認証情報に従って前記各デバイスに対するネットワークを設定するホームサーバと、前記ホームサーバと接続され、前記各制御デバイスの性格に応じてサーバ許可に対する情報を有する許可サーバと、前記ホームサーバを介してネットワーク認証を行い、前記要請されたサービスコンテンツに対する前記許可サーバの許可／不許可に従って、前記サービスデバイスから前記サービスコンテンツの提供を受ける前記制御デバイスと、を備える。

前記許可サーバは、前記各制御デバイスの性格に応じてサービス許可に対する情報をテーブル形態で管理する装置及び許可リストデータベースを有することが好ましい。

また、前記装置及び許可リストデータベースは、前記各制御デバイスの性格に応じてサービスデバイス許可に対する情報をさらに有することができる。

前記ホームサーバは、前記各デバイスに対する認証情報を前記各デバイスとマッピングして保存する認証テーブルを有することが好ましい。

前記ホームサーバにおける前記各制御デバイスに対する認証は、前記制御デバイスの媒体接続制御階層のアドレス情報で行なうことを特徴とし、前記ホームサーバにおける前記各制御デバイスに対する認証は、ユーザＩＤ及びパスワード情報で行なうことを特徴とする。

また、前記ホームサーバは、前記制御デバイスに対するユーザ認証、デバイス認証、及びネットワーク設定を同時に処理することを特徴とし、前記制御デバイスからのＤＨＣＰパケットとＰＰＰＯＥパケットを同時に処理できることを特徴とする。

なお、前記ホームサーバは、ネットワーク設定を要請した前記制御デバイスからの入力パケットデータ類型を確認するイーサネット（登録商標）型検査部と、前記イーサネット（登録商標）型検査部で検査された入力パケットデータの類型に応じてＰＰＰＯＥ処理を行うことができるＰＰＰＯＥサーバと、前記イーサネット（登録商標）型検査部で検査された入力パケットデータ類型に応じてＤＨＣＰ処理を行うことができるＤＨＣＰサーバと、前記各ＰＰＰＯＥ及びＤＨＣＰ処理後、ユーザ及びデバイス認証を行なうユーザ／デバイス認証データベースを有することを特徴とする。

ここで、前記ＰＰＰＯＥサーバは、ＰＰＰＯＥ処理要請に従ってプロセスを実行するＰＰＰＯＥデモンと、前記ＰＰＰＯＥデモン実行後ＰＰＰ処理要請に従ってプロセスを実行するＰＰＰデモンと、前記ＰＰＰデモン実行後ＰＰＰＯＥにおけるユーザ認証を担当するユーザ認証部とを有することができる。

また、前記ＤＨＣＰサーバは、ＤＨＣＰパケットに対するポート番号を検査するＤＨＣＰポート検査部と、前記ＤＨＣＰポート番号検査後、ＤＨＣＰ処理要請に従ってプロセスを実行するＤＨＣＰデモンと、前記ＤＨＣＰデモン実行後、前記ＤＨＣＰパケットのＭＡＣアドレスを認証するＭＡＣアドレス認証部とを有することができる。

一方、前記イーサネット（登録商標）型検査部は、前記入力パケットデータのデータフィールドの中で、イーサネット（登録商標）型情報を含むフィールドを確認し、前記フィールドに記録された情報に従って前記入力パケットデータがＤＨＣＰパケットであるか、ＰＰＰＯＥパケットであるかを判断することを特徴とする。

また、前記イーサネット（登録商標）型検査部で確認した前記入力パケットデータのイーサネット（登録商標）型がＤＨＣＰである場合、ペイロードのＩＰパケット領域を介してＩＰパケット情報を確認することが好ましく、前記イーサネット（登録商標）型検査部で確認した前記入力パケットデータのイーサネット（登録商標）型がＤＨＣＰである場合、ペイロードのＩＰパケット領域を介してＵＤＰ情報を確認することが好ましい。

前記ホームサーバは、前記ＤＨＣＰサーバのＤＨＣＰデモンと前記ＰＰＰＯＥサーバのＰＰＰＯＥデモンが割当て可能なＩＰ情報を含むＩＰプールデータベースに同時にアクセス可能であることを特徴とする。

一方、前記目的を達成するために、本発明による方法は、ホームネットワークの各種サービスデバイスを制御して、前記サービスデバイスからサービスの提供を受けようとするユーザは、制御デバイスがホームサーバを介して認証を受ける段階と、前記制御デバイスが前記ホームサーバに前記サービスデバイスに対するサービス要請を行なう段階と、前記サービス要請に従って前記制御デバイスが前記ホームサーバと連動する許可サーバを介して前記要請されたサービスに対するサービス許可を受ける段階と、前記サービス許可を受け入れた後、前記制御デバイスが前記サービスデバイスから前記要請したサービスの提供を受ける段階と、を含む。

この時、前記方法は、制御デバイスがホームネットワークにアクセスする際に、前記制御デバイス１２０をホームサーバの認証テーブルに登録する段階と、前記ホームサーバが許可サーバにサービス許可登録メッセージを伝送する段階と、前記許可サーバが前記当該制御デバイスに対する許可情報を前記許可サーバに登録する段階と、前記制御デバイスから前記ホームサーバにサービスデバイスからのサービス提供要請を行なう段階と、前記ホームサーバが前記制御デバイスが要請した前記サービスの提供が許可されたサービスであるかを前記許可サーバによって確認する段階と、前記確認結果、許可が受け入れられる場合、前記サービスデバイスから前記制御デバイスによって要請されたサービスが提供される段階とを含むことができる。

また、前記方法は、前記要請されたサービスの許可が受け入れられる時、前記ホームサーバ、制御デバイス及び前記要請されたメディアコンテンツを提供する当該サービスデバイス間でマッチングするプロトコル、ポート及びフォーマットに対する選択を行なう段階と、前記ホームサーバが前記制御デバイスと前記サービスデバイス間のルーティングテーブル及びブリッジングテーブルを更新する段階とをさらに含むことができる。

一方、前記許可サーバは、前記各制御デバイスに対する性格に応じてサービス許可に対する情報をテーブル形態で管理することが好ましく、前記各制御デバイスに対する性格に応じたサービスデバイス許可に対する情報をさらに含むことができる。

前記ホームサーバは、前記各デバイスに対する認証情報を前記各デバイスとマッピングして保存する認証テーブルを含むことを特徴とする。

この時、前記ホームサーバにおいて、前記各制御デバイスに対する認証は、前記制御デバイスの媒体接続制御階層のアドレス情報で行うことができ、ユーザＩＤ及びパスワード情報で行うこともできる。

前記ホームサーバは、前記制御デバイスに対するユーザ認証、デバイス認証、及びネットワーク設定を同時に処理することを特徴とし、前記制御デバイスからのＤＨＣＰパケットとＰＰＰＯＥパケットを同時に処理できることを特徴とする。

一方、前記サービス許可が受け入れられない場合には、前記許可サーバが前記ホームサーバのサービス許可要請メッセージの応答としてサービス許可拒絶メッセージを前記ホームサーバに転送する段階と、前記許可サーバから前記サービス許可拒絶メッセージを受信した前記ホームサーバが、前記当該制御デバイスに拒絶メッセージを転送する段階とをさらに含むことを特徴とする。

前記目的を達成するために、本発明の第１実施形態による方法は、制御デバイスがホームサーバにネットワーク設定を要請する段階と、前記制御デバイスが転送した入力パケットのプロトコルを確認する段階と、前記確認結果、ＤＨＣＰであると確認される場合、前記制御デバイスに対するＭＡＣアドレスが認証テーブルに登録されているか否かを確認する段階と、前記確認結果、ＭＡＣアドレスが認証テーブルに登録されている場合、前記制御デバイスにＩＰアドレスを割当てる段階と、前記制御デバイスが前記ホームサーバとのネットワーク設定を完了する段階と、前記制御デバイスのサービス許可と関連する情報を許可テーブルに登録する段階と、前記制御デバイスのサービス要請後、前記許可テーブルに前記要請されたサービスが許可されたか否かを判断する段階と、前記判断結果、前記要請されたサービスが許可された場合、前記要請されたサービスを提供する段階をさらに含むことを特徴とする。

この時、前記認証テーブルの登録／不登録を確認した結果、ＭＡＣアドレスが認証テーブルに登録されていない場合、前記制御デバイスをゲストデバイスとして認識し、ネットワーク設定を再要請する段階をさらに含むことを特徴とする。

前記目的を達成するために、本発明の第２実施形態による方法は、制御デバイスがホームサーバにネットワーク設定を要請する段階と、前記制御デバイスが転送した入力パケットのプロトコルを確認する段階と、前記確認した結果、ＰＰＰＯＥであると確認される場合、前記制御デバイスに対するＭＡＣアドレスが認証テーブルに登録されているか否かを確認する段階と、前記確認した結果、ＭＡＣアドレスが認証テーブルに登録されている場合、前記制御デバイスにＰＰＰＯＥデモンによってネットワーク設定を行なう段階と、前記制御デバイスのサービス許可と関連する情報を許可テーブルに登録する段階と、前記制御デバイスのサービス要請後、前記許可テーブルに前記要請されたサービスが許可されたか否かを判断する段階と、前記判断結果、前記要請されたサービスが許可された場合、前記要請されたサービスを提供する段階をさらに含むことを特徴とする。

この時、前記認証テーブルの登録／不登録を確認した結果、ＭＡＣアドレスが認証テーブルに登録されていない場合、前記制御デバイスのＭＡＣアドレスを認証テーブルに登録する段階をさらに含むことを特徴とする。

前記目的を達成するために、本発明の第３実施形態による方法は、制御デバイスがホームサーバにネットワーク設定を要請する段階と、前記制御デバイスに対してＩＰアドレス自動設定であるか否かを確認する段階と、前記確認結果、ＩＰアドレス自動設定であると確認される場合、前記制御デバイスに対するＭＡＣアドレスが認証テーブルに登録されているか否かを確認する段階と、前記確認結果、ＭＡＣアドレスが認証テーブルに登録されている場合、ネットワーク設定を完了する段階と、前記制御デバイスのサービス許可と関連する情報を許可テーブルに登録する段階と、前記制御デバイスのサービス要請後、前記許可テーブルに前記要請されたサービスが許可されたか否かを判断する段階と、前記判断結果、前記要請されたサービスが許可された場合、前記要請されたサービスを提供する段階をさらに含むことを特徴とする。

この時、前記確認結果、ＭＡＣアドレスが認証テーブルに登録されていない場合、前記制御デバイスにＰＰＰＯＥクライアントモジュールが存在するか否かを確認する段階と、前記確認結果、ＰＰＰＯＥクライアントモジュールが存在する場合、前記制御デバイスにＰＰＰＯＥデモンによってネットワーク設定を行なう段階とをさらに含むことを特徴とし、前記確認結果、ＰＰＰＯＥクライアントモジュールが存在しない場合、前記制御デバイスにＰＰＰＯＥクライアントファイルを転送する段階と、前記制御デバイスが前記受信したＰＰＰＯＥクライアントファイルを実行し、前記ＰＰＰＯＥクライアントモジュールを生成する段階と、をさらに含むことを特徴とする。

本発明は、ホームネットワークにおいて、ゲストデバイスに対するユーザ認証、デバイス認証及びネットワーク設定（つまり、ＩＰアドレス割当）を同一に処理する。また、本発明は、ＤＨＣＰとＰＰＰＯＥをすべて支援できるホームサーバ及びユーザ認証を提案する。

一方、本発明は、ホーム内部のレガシーデバイス（ｌｅｇａｃｙ ｄｅｖｉｃｅ）に対して、ハードウェアＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを介して認証を行い、一時的な訪問デバイスに対しては、ユーザＩＤ及びパスワードによって認証を行なう。

また、すべてのゲストデバイスは、本発明によるホームサーバを経由しなければ、ホーム内の各種デバイス及びサービスにアクセスすることができない。ここで、ホームサーバを経由するゲストデバイスは、指定されたユーザＩＤ及びパスワードによって、ホーム内のデバイス及びサービスに対する権限が異なるように設定される。

従来一般のＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）でのＩＰアドレス設定部分は、ユーザ及びデバイスに対する認証部分を含まなかったが、本発明によれば、デバイス及びユーザに対する認証を行うことができる。

同時に、本発明は、前記のような認証手続きによってネットワーク設定されたデバイス及びユーザに対し、作業スケジューリングを効率的に行うことができるトラフィック優先順位（ｔｒａｆｆｉｃ ｐｒｉｏｒｉｔｙ）を付与することによって、効率的なＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を提供することができる。

前記のように、本発明は、ホームネットワークにおいて、レガシーデバイスまたはゲストデバイスなどのような制御デバイスに対する認証とネットワーク設定を同時に実現できる。

また、本発明によれば、デバイス、サービス及びコンテンツに対する制限された接続制御が可能となり、さらに、デバイス及びユーザ毎にネットワークトラフィックの優先順位を異なるようにする優先順位の付与が可能である。

以下、添付図面に基づいて本発明の好適な実施形態を詳述する。
図１は、本発明が適用されるホームネットワークにおけるデバイスのアクセス状況を示す図面である。図１に示すように、ホームネットワーク内において、レガシーデバイス１１０またはゲストデバイス１２０がホームサーバ１００を介して一つ以上の対象デバイス（例えば、エンターテイメントサービスデバイス１１１、ビデオデバイス１１２など）と通信できる。レガシーデバイス１１０は、ホームネットワーク内に既に設けられたデバイスを意味し、ゲストデバイス１２０は、外部デバイス１２１などのように、一時的にホームネットワークに訪問するデバイスを意味する。

どのようなデバイスをホームネットワーク内部に持ってきても使用可能であるが、認証過程を必ず行なう必要がある。ここで、本発明に従って、ＰＰＰＯＥまたはＤＨＣＰ方式によってレガシーデバイス１１０またはゲストデバイス１２０に対するユーザ認証を行い、これにより、利用できるコンテンツ及びサービスの差別化を図ることができる。

例えば、ゲストデバイス１２０が訪問してホームネットワークにアクセスする場合、ゲストデバイス１２０に対してはホームネットワーク内の資料を非公開に設定することが好ましく、息子の友達などの場合には、アダルトコンテンツに対するアクセス制限を設定することが好ましい。また、泥棒が侵入した場合には、ホームネットワーク内のすべてのデバイスやサービスに対するアクセスを不可能に設定することが好ましい。このように、本実施形態では、ホームネットワーク内部で各種サービスを提供する様々なデバイス（例えば、エンターテイメントサービスデバイス１１１、ビデオデバイス１１２など、以下、「サービスデバイス」という。）を制御するためのデバイス（つまり、レガシーデバイス１１０またはゲストデバイス１２０、以下、「制御デバイス」という。）がホームサーバ１００を介して認証を行い、このとき、ホームサーバ１００を介して制御デバイス毎にサービス及びサービスデバイスに対する許可を差別化して設定することができる。

ホームサーバ１００は、インターネット１４０のような外部ネットワークと接続するゲートウェイの役割を担ったり、ホームサーバ１００の外部に設けられた別途のゲートウェイ（図示せず）を介して外部ネットワークと通信したりすることができる。ここで、ホームサーバ１００は、ｘＤＳＬ、ケーブル、光などの通信手段によってインターネット１４０と接続される。

一方、本発明では、ホームネットワーク内部にホームサーバ１００と連動する許可サーバ（Ｐｅｒｍｉｓｓｉｏｎ Ｓｅｒｖｅｒ）１３０を有し、許可サーバ１３０を介してホームサーバ１００に接続する各種制御デバイスに対する装置及びサービス許可などを制御できる。これにより、許可サーバ１３０は、各制御デバイスに対する許可情報を装置及び許可リストデータベース１３１内にテーブル形態で構成して含むことができる。即ち、ホームネットワーク内の各種サービスデバイスなどを制御するために、各制御デバイスは、ホームサーバ１００を介して許可サーバ１３０に接続し、許可サーバ１３０内の装置及び許可リストデータベース１３１に含まれた自身の許可テーブルを介して各サービスデバイス及びサービスに対する許可を受けることができる。一方、許可サーバ１３０は、その実現方法によって、ホームサーバ１００内に存在したり、インターネット１４０を介した外部ネットワークに存在したりする。

次に、図２を参照して本実施形態に係るホームサーバ１００の機能をより具体的に説明する。
図２は、本実施形態に係るホームネットワークにおいて、デバイス及びユーザの認証システムを示す図面である。図２に示すように、レガシーデバイス１１０は前記したように、ホームネットワーク内に設定された既存の制御デバイスであって、ホームサーバ１００を介して各サービスデバイス（例えば、ビデオデバイス１１２、エンターテイメントサービスデバイス１１１、ＣＥデバイス（Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃ Ｄｅｖｉｃｅ）１１３など）を制御できると共に、ホームサーバ１００を介することなく、直接サービスデバイスを制御することが可能である。

しかし、ゲストデバイス１２０の場合、直接サービスデバイスを制御するよりは、本実施形態のように、ホームサーバ１００を介して認証及び許可手続きを経てからホームサーバ１００を介して各種サービスデバイスを許可レベルなどに従って制御するように実現することが好ましい。

即ち、新たなゲストデバイス１２０がホームネットワークにアクセスして、サービスデバイスを制御またはサービスデバイスのサービスを受けようとする場合、まずホームサーバ１００を介してネットワークの接続を設定し、認証を受ける必要がある。許可サーバ１３０を介して許可サーバ１３０内の装置及び許可リストデータベース１３１に設定された許可レベルまたは許可されるサービスの種類情報によってサービスデバイスからサービスの提供を受ける。ここで、許可サーバ１３０がホームネットワーク内でホームサーバ１００の外部に別途設けられる場合には、ゲストデバイス１２０は、ホームサーバ１００を介して許可サーバ１３０と接続できる。
装置及び許可リストデータベース１３１に構成される許可テーブルを表１に示す。

表１によれば、ゲストデバイス１２０毎に各デバイスの性格（つまり、訪問者の関係及びレベルなど）に応じた許可情報を構成し、許可情報に従ってサービス及びデバイスの制御を制限的に提供することができる。ここで、各デバイスに対する区別は、各デバイスのＭＡＣアドレスの確認を通じて行なうことができる。

例えば、ゲスト１がマスターの制御デバイスである場合、すべての使用を許可する設定を行なうことができ、ゲスト２が息子の制御デバイスである場合、アダルト用ではないイメージ、映画、インターネットなどに制御可能に設定することができる。また、ゲスト３に対しては、各サービスデバイスのみを制御可能に設定し、ゲスト４に対しては、インターネットのみを使用可能に設定できる。このように、許可サーバ１３０の装置及び許可リストデータベース１３１を備えることにより、各制御デバイスに対するホームネットワーク内での提供サービスの許可レベルをそれぞれの特性に応じて設定し、その機能を制限することができる。

一方、ホームサーバ１００は、レガシーデバイス１１０またはゲストデバイス１２０の通信可能なプロトコルの種類に関係なくネットワークアクセスが可能であるようにＤＨＣＰ及びＰＰＰＯＥをすべて支援するように構成される。

これにより、ホームサーバ１００は、本実施形態に従って、ＤＨＣＰサーバ２００及びＰＰＰＯＥサーバ２１０を有する。ここで、ＤＨＣＰサーバ２００は、当該制御デバイスにＩＰプールデータベース（ＩＰ ｐｏｏｌ ＤＢ）２２０を介してネットワーク接続のための固有ＩＰを提供する。また、ＰＰＰＯＥサーバ２１０は、制御デバイスにＰＰＰＯＥでのＩＰ提供プロトコルであるＩＰＣＰ（ＩＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）２１２によってＩＰプールデータベース（ＩＰ ｐｏｏｌ ＤＢ）２２０を介してネットワーク接続のための固有ＩＰを提供する。

同時に、ＰＰＰＯＥサーバ２１０は、ＰＰＰＯＥによるネットワーク接続のために、ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）２１１によってデータリンク設定を行い、Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／Ｃｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＰＡＰ／ＣＨＡＰ）２１３によって認証を行なう。ここで、ＰＡＰ／ＣＨＡＰ２１３は、本実施形態に従って、制御デバイス毎に設定された認証テーブルによって認証を行なうことができる。
例えば、前記認証テーブルは、表２のように構成される。

表２によれば、ホームサーバ１００内で認証を行なうための認証テーブルは、制御デバイス毎にＭＡＣアドレス、デバイスＩＤ、ＩＰ及び状態情報などを含むことができる。

一方、ゲストデバイス１２０がホームサーバ１００のＰＰＰＯＥサーバ２１０を介してＰＰＰＯＥによるネットワーク接続設定を行なうと、ゲストデバイス１２０は、ＰＰＰＯＥクライアント２３０として動作する。

これにより、例えば、ゲストデバイス１２０のＩＤがゲスト２であり、ゲストデバイス１２０のＭＡＣアドレスがＭ３であり、ＰＰＰＯＥを介してネットワーク設定が可能である場合、ゲストデバイス１２０には、ホームサーバ１００のＰＰＰＯＥサーバ２１０を介してネットワーク設定及びＩＰが割り当てられる。従って、ゲストデバイス１２０とホームサーバ１００との間では、ＰＰＰＯＥトンネルリングが設定される。このとき、前記したように、ホームサーバ１００は、ゲストデバイス１２０のＭＡＣアドレスによって表２の認証テーブルを確認し、ＩＰ割り当て及び状態の設定を行なう。また、ホームサーバ１００は、ホームサーバ１００と連結される許可サーバ１３０の装置及び許可リストデータベース１３１に保存された表１のような許可テーブルによってゲストデバイス１２０の設定された許可デバイス及びサービスを確認することになる。ここで、ゲストデバイス１２０に対する許可手続きの際にも、ゲストデバイス１２０のＭＡＣアドレスを使用することができる。

次に、図３乃至図５を参照して、各デバイスのネットワーク設定方式によるホームサーバでのネットワーク設定機能をより具体的に説明する。

ここで、ホームサーバ１００は、前記したように、ＤＨＣＰとＰＰＰＯＥを同時に支援可能に実現できる。

図３は、本実施形態に係るホームネットワークシステムにおけるホームサーバの機能的な構成を示すブロック図である。

図３に示すように、ホームサーバ１００は、イーサネット（登録商標）型検査部３１０、ＰＰＰＯＥデモン３２０、ＰＰＰデモン３３０、ユーザ認証部（ＰＡＰ／ＣＨＡＰ）３４０、ＤＨＣＰポート番号検査部３５０、ＤＨＣＰデモン３６０、ＭＡＣアドレス認証部３７０、及びユーザ／デバイス認証データベース３８０などで構成される。

即ち、ホームサーバ１００は、イーサネット（登録商標）型検査部３１０で検査された入力パケットデータ類型に応じてそれぞれＰＰＰＯＥ処理を行なうＰＰＰＯＥサーバ２１０（図２参照）を構成するＰＰＰＯＥデモン３２０、ＰＰＰデモン３３０及びユーザ認証部（ＰＡＰ／ＣＨＡＰ）３４０と、ＤＨＣＰ処理を行なうＤＨＣＰサーバ２００（図２参照）を構成するＤＨＣＰポート番号検査部３５０、ＤＨＣＰデモン３６０及びＭＡＣアドレス認証部３７０で構成される。また、各ＰＰＰＯＥ及びＤＨＣＰ処理後、ホームサーバ１００は、ユーザ／デバイス認証データベース３８０を介してユーザ及びデバイス認証を行なう。

ホームサーバ１００のイーサネット（登録商標）型検査部３１０で入力パケットデータのイーサネット（登録商標）タイプを検査し、検査した入力パケットデータのイーサネット（登録商標）タイプがＰＰＰＯＥである場合には、ＰＰＰＯＥデモン３２０、ＰＰＰデモン３３０及びユーザ認証部３４０などによって処理し、ＤＨＣＰである場合には、ＤＨＣＰポート番号検査部３５０、ＤＨＣＰデモン３６０及びＭＡＣアドレス認証部３７０などによって処理する。

より具体的には、イーサネット（登録商標）型検査部３１０では、入力パケットデータのデータフィールドの中で、イーサネット（登録商標）タイプ情報を含むフィールド（一般に２バイトで構成される。）を確認し、このフィールドに記録された情報によって入力パケットデータがＤＨＣＰパケットであるか、ＰＰＰＯＥパケットであるかを判断する。

このとき、入力パケットデータは、一般に図５に示すように構成される。図５は、本実施形態に係るイーサネット（登録商標）パケットの構造を示す図面である。図３に示すように、ホームサーバ１００に入力される一般の入力パケットデータは、６バイトの目的地アドレス領域（Ｄｅｓｔｉｎａｔｉｏｎ ＭＡＣ）５１０、６バイトの発信地アドレス領域（Ｓｏｕｒｃｅ ＭＡＣ）５２０、２バイトのイーサネット（登録商標）型情報領域（Ｅｔｈｅｒ＿Ｔｙｐｅ）５３０、ペイロード領域（ｐａｙｌｏａｄ）５４０、及びＦＣＳ領域（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）５５０などで構成される。また、ペイロード領域５４０は、２バイトのプロトコル型領域５４１と２バイトのポート番号領域５４２を含むことができる。

従って、イーサネット（登録商標）型検査部３１０では、入力パケットデータのフィールド領域の中で、イーサネット（登録商標）型情報領域５３０を確認することによって、入力パケットデータがＤＨＣＰパケットであるか、ＰＰＰＯＥパケットであるかを判定する。

一方、入力パケットデータがＤＨＣＰパケットである場合、一般に、ペイロード領域５４０内には２０バイトのＩＰ領域が割り当てられ、ＩＰ領域の中に２バイトのプロトコル番号情報が含まれる。これに対し、入力パケットデータがＰＰＰＯＥパケットである場合には、一般に、ペイロード領域５４０内にはＩＰ領域のみならず、６バイトのＰＰＰＯＥ領域が割り当てられる。

即ち、イーサネット（登録商標）型検査部３１０では、入力パケットデータのイーサネット（登録商標）型情報領域５３０を確認し、イーサネット（登録商標）タイプ情報が「０ｘ８８６３」または「０ｘ８８６４」である場合には、入力パケットをＰＰＰＯＥパケットであると判断し、ＰＰＰＯＥデモン３２０、ＰＰＰデモン３３０及びユーザ認証部（ＰＡＰ／ＣＨＡＰ）３４０によってＰＰＰＯＥパケット処理を行なう。

もし、イーサネット（登録商標）型検査部３１０で確認した入力パケットデータのイーサネット（登録商標）型がＤＨＣＰである場合には、イーサネット（登録商標）型検査部３１０は、ペイロードのＩＰパケット領域を介してＩＰパケット情報「０ｘ０８００」及びＵＤＰ（Ｕｓｅｒ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）「０ｘ０６」を確認する。また、入力パケットデータがＩＰ及びＵＤＰパケットで構成される場合には、ＤＨＣＰポート番号検査部３５０では、ポート番号領域５４２を介して当該パケットのポート番号（つまり、０ｘ６７、０ｘ６８）を確認する。その後、ＤＨＣＰデモン３６０及びＭＡＣアドレス認証部３７０によってＤＨＣＰパケット処理を行なう。

このように、ホームサーバ１００は、入力パケットデータの形式に応じてそれぞれＰＰＰＯＥ方式またはＤＨＣＰ方式でユーザ認証及びＭＡＣアドレス認証を行なった後、ユーザ／デバイス認証データベース３８０の表２のような認証テーブルによってユーザ／デバイス認証を行なう。

従って、ホームサーバ１００は、ＤＨＣＰサーバ２００及びＰＰＰＯＥサーバ２１０を同時に備え、各制御デバイスの特性に応じてＤＤＨＣＰ方式及びＰＰＰＯＥ方式の処理を同時に行なうことができる。また、図２に示すように、ＤＨＣＰデモン３６０とＰＰＰＯＥデモン３２０が一つのＩＰプールデータベース２２０に同時にアクセスすることができる。

次に、図４を参照して、ホームサーバ１００が入力パケットデータに基づきネットワーク設定を行なう手続きを説明する。

図４は、本実施形態に係るホームサーバにおけるプロトコル選択手続きを示すフローチャートである。図４に示すように、まず、制御デバイスがホームサーバ１００に入力パケットデータに対するネットワーク設定要請を行なうと（Ｓ４０１）、前記したように、イーサネット（登録商標）型検査部３１０が、入力パケットデータがＰＰＰＯＥパケットであるかを確認する（Ｓ４０３）。

イーサネット（登録商標）型検査部３１０が、入力パケットデータがＰＰＰＯＥパケットであると確認した場合（ＰＰＰＯＥを発見した場合、Ｓ４０３で「Ｙ」）、ＰＰＰＯＥセッションを行い、認証モジュールによる入力パケットデータの認証処理を行なう（Ｓ４０５）。ここで、入力パケットがＰＰＰＯＥパケットであると確認されたがＰＰＰＯＥが発見されない場合、またはＰＰＰＯＥセッションが処理されなかった場合には、ブリッジング（Ｂｒｉｄｇｉｎｇ）及びルーティング（Ｒｏｕｔｉｎｇ）などによって他のプロトコルを実行する（Ｓ４０８）。

一方、入力パケットデータがＰＰＰＯＥパケットではない場合（Ｓ４０３で「Ｎ」）には、イーサネット（登録商標）形検査部３１０が、入力パケットデータがＩＰ／ＵＤＰパケットであるか否か判断する（Ｓ４０４）。

入力パケットデータがＩＰ／ＵＤＰパケットであると判断した場合（Ｓ４０４で「Ｙ」）、入力パケットデータがＤＨＣＰパケットであるかを確認する（Ｓ４０７）。

パケットデータがＤＨＣＰパケットであると確認された場合には（Ｓ４０７で「Ｙ」）、ＤＨＣＰを発見できるか否か確認する（Ｓ４０９）。

ＤＨＣＰを発見した場合には（Ｓ４０９で「Ｙ」）、前記のように、認証モジュールによる入力パケットデータの認証処理を行なう（Ｓ４０５）。

ＤＨＣＰが発見されない場合（Ｓ４０９で「Ｎ」）には、ネットワーク設定処理を行なう（Ｓ４１１）。

入力パケットデータがＤＨＣＰパケットではない場合（Ｓ４０７で「Ｎ」）、または入力パケットデータがＩＰ／ＵＤＰパケットではなく、その他のパケットであると判断される場合には（Ｓ４０４で「Ｎ」）、ブリッジング及びルーティングなどによって他のプロトコルを実行する（Ｓ４１３）。

以上、本実施形態に係るホームサーバ１００の構成と処理手続きを詳細に説明した。次に、図６及び図７を参照して、制御デバイス１１０、１２０がホームサーバ１００を介して認証した後、サービスデバイス１１１，１１２，１１３からサービスの提供を受ける手続きを説明する。

図６は、本実施形態に係るホームネットワークのデバイス及びユーザ認証の手続きを示す図面である。図６に示すように、ホームネットワークの各種サービスデバイス１１１，１１２，１１３を制御して、サービスデバイス１１１，１１２，１１３からサービスの提供を受けようとするユーザは、ホームサーバ１００を介して制御デバイス１１０，１２０の認証を受け、許可サーバ１３０を介してサービス許可を受ける。

より具体的には、まず、ＵＰｎＰメディアレンダラー（ＵＰｎＰ Ｍｅｄｉａ ｒｅｎｄｅｒｅｒ）である制御デバイス１２０は、新たにホームネットワークにアクセスしようとするとき、制御デバイス１２０をホームサーバ１００の認証テーブルに登録した後、ホームサーバ１００に対してユーザ認証及びネットワーク設定を行なう（Ｓ６０１）。このとき、制御デバイス１２０がゲストデバイス１２０である場合には、制御デバイス１２０の入力手段によって登録されたＩＤ及びパスワードを入力しホームサーバ１００に転送することで、ゲストデバイス１２０に対する認証が行なわれ、ＩＰが割り当てられてネットワーク設定が完了する。ここで、制御デバイス１２０の情報入力は、図７のように実現される。即ち、図７に示すように、制御デバイス１２０のユーザ情報入力窓７００でユーザ氏名７１０とパスワード７２０を入力できる。このとき、ユーザ情報入力窓７００の下段には、現在、認証中であるか認証が完了したかを示すメッセージが出力される。このように、入力されたユーザ氏名７１０とパスワード７２０情報によってホームサーバ１００は制御デバイス１２０を認証する。

その後、ホームサーバ１００は、許可サーバ１３０にサービス許可登録メッセージ（Ｓｅｒｖｉｃｅ Ｐｅｒｍｉｓｓｉｏｎ Ｒｅｇｉｓｔｅｒ ｍｅｓｓａｇｅ）を転送し（Ｓ６０２）、許可サーバ１３０が当該制御デバイス１２０に対する許可情報を許可サーバ１３０内の装置及び許可リストデータベース１３１で構成された表１のような許可テーブルに登録するようにする。

このように、ホームネットワークに接続しようとする制御デバイス１２０に対する許可情報が登録された後、制御デバイス１２０はホームサーバ１００に所定のメディアコンテンツに対するサービス提供要請を行なう（Ｓ６０３）。

ここで、ホームサーバ１００は、制御デバイス１２０が要請した当該メディアコンテンツに対するサービス提供が許可されたサービス及びデバイスであるかを許可サーバ１３０を通じて確認する。即ち、ホームサーバ１００は、許可サーバ１３０にサービス許可要請メッセージ（Ｓｅｒｖｉｃｅ Ｐｅｒｍｉｓｓｉｏｎ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）を転送する（Ｓ６０４）。

もし、制御デバイス１２０のユーザが未成年である場合には、許可サーバ１３０の許可テーブルに登録された当該制御デバイス１２０の許可情報がアダルト用に対する提供禁止と設定されることが好ましい。よって、制御デバイス１２０が要請したメディアコンテンツがＡｄｕｌｔ．ａｖｉというアダルト動画ファイルである場合、許可サーバ１３０では、ホームサーバ１００のサービス許可要請メッセージの応答としてサービス許可拒絶メッセージ（Ｓｅｒｖｉｃｅ Ｐｅｒｍｉｓｓｉｏｎ Ｒｅｊｅｃｔ ｍｅｓｓａｇｅ）をホームサーバ１００に転送する（Ｓ６０５）。

許可サーバ１３０からサービス許可拒絶メッセージを受信したホームサーバ１００は、当該制御デバイス１２０に拒絶メッセージ（Ｒｅｊｅｃｔ ｍｅｓｓａｇｅ）を転送する（Ｓ６０６）。

一方、制御デバイス１２０は、ホームサーバ１００に他のメディアコンテンツを再び要請することができる（Ｓ６０７）。

これにより、ホームサーバ１００では、前記したように、許可サーバ１３０にサービス許可要請メッセージ（Ｓｅｒｖｉｃｅ Ｐｅｒｍｉｓｓｉｏｎ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）を転送する（Ｓ６０８）。もし、再度要請したメディアコンテンツが「Ｐｒｉｎｃｅｓｓ．ｍｐｇ」のような未青年に許可された動画ファイルであり、制御デバイス１２０に対して当該動画ファイルに対する提供が許可されたものであると判断される場合、許可サーバ１３０では、ホームサーバ１００に当該サービス許可要請に対するサービス許可許容メッセージ（Ｓｅｒｖｉｃｅ Ｐｅｒｍｉｓｓｉｏｎ Ａｌｌｏｗ ｍｅｓｓａｇｅ）を転送する（Ｓ６０９）。

これにより、許可サーバ１３０からサービス許可許容メッセージを受信したホームサーバ１００は、当該制御デバイス１２０に正常受信メッセージ（Ａｃｋ ｍｅｓｓａｇｅ）を転送することによって（Ｓ６１０）、制御デバイス１２０が要請したメディアコンテンツが提供可能であることを知らせる。

このとき、ホームサーバ１００、制御デバイス１２０、及び要請されたメディアコンテンツを提供する当該サービスデバイス１１１，１１２，１１３の間でマッチングするプロトコル、ポート、及びフォーマットに対する選択手続きが実行される（Ｓ６１１）。これにより、ホームサーバ１００は、制御デバイス１２０とサービスデバイス１１１，１１２，１１３間のルーティングテーブル及びブリッジングテーブルをアップデートする。

その後、ホームサーバ１００では、制御デバイス１２０に当該メディアコンテンツ（つまり、Ｐｒｉｎｃｅｓｓ．ｍｐｇファイル）を転送し（Ｓ６１２）、当該サービスデバイス１１１乃至１１３に当該メディアコンテンツ（つまり、Ｐｒｉｎｃｅｓｓ．ｍｐｇファイル）に対する再生レンダリングを行なう（Ｓ６１３）。

最後に、制御デバイス１２０は、対象デバイス１１１，１１２、１１３に当該メディアコンテンツを転送して再生することによって（Ｓ６１４）、すべてのサービス手続きが完了する。

次に、図８〜１２を参照して、制御デバイス１１０、１２０がホームネットワークにアクセスしてネットワーク設定を行い、サービス要請に従ってサービスの提供を受けるまでの手続きをより詳細に説明する。まず、図８〜１０を参照して各通信プロトコルによるネットワーク設定手続きを説明し、図１２を参照してネットワーク設定完了後にサービスを提供する手続きを説明する。

一方、ホームサーバ１００は、前記したように、ホームネットワークにアクセスしようとする各制御デバイス１１０、１２０に対し、制御デバイス１１０、１２０で支援するプロトコル方式に応じてＤＨＣＰ及びＰＰＰＯＥ方式をすべて提供できる。よって、各プロトコル方式に応じて図８〜１０を参照して、ＤＨＣＰ方式、ＰＰＰＯＥ方式、及び自動ＩＰ設定方式によるネットワーク設定手続きを説明する。

図８は、本実施形態に係るデバイスがＤＨＣＰでアクセスする場合のネットワーク設定手続きを示す。
図８に示すように、まず、制御デバイス１１０、１２０がホームサーバ１００にネットワーク設定要請を行う（Ｓ８０１）。

制御デバイス１１０、１２０が転送した入力パケットを介してＤＨＣＰを発見し（Ｓ８０２）、前記したように、ＤＨＣＰプロトコルに応じてネットワーク設定処理を行なう。

ここで、図１１Ａに示すように、制御デバイス１１０、１２０に対するＭＡＣアドレス１１００がＭ３、デバイスＩＤ１１１０がＰＤＡであり（ここで、デバイス１１０、１２０がＤＨＣＰでアクセスするので、ユーザＩＤ１１２０とパスワード１１３０がない。）、以下の表３のように、制御デバイス１１０、１２０が、認証テーブルに登録されているか否か判断し（Ｓ８０３）、制御デバイス１１０、１２０が認証テーブルに登録されている場合（Ｓ８０３で「Ｙ」）には、制御デバイス１１０、１２０を既存のホームデバイス、つまり、レガシーデバイス１１０であると判断し（Ｓ８０４）、ホームネットワーク内のデバイス及び外部へのすべてのアクセスが可能に設定される。

このように、制御デバイス１１０、１２０がＤＨＣＰ方式であるので、ＤＨＣＰ ＩＰがＩＰプールデータベース２２０から提供（ＤＨＣＰ ＩＰ Ｏｆｆｅｒ）され、ＤＨＣＰ ＩＰの要請（ＤＨＣＰ ＩＰ Ｒｅｑｕｅｓｔ）に従って提供（ＤＨＣＰ ＩＰ Ａｃｋ）されたＩＰが制御デバイス１２０、つまり、レガシーデバイス１１０に割り当てる（Ｓ８０５）。

これにより、ネットワーク設定が完了する（Ｎｅｔｗｏｒｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｓｕｃｃｅｓｓ）。

一方、制御デバイス１１０、１２０に対するＭＡＣアドレスがＭ３であり、表４のように、認証テーブルに登録されていない場合（Ｓ８０３で「Ｎ」）、制御デバイスを外部から新たに流入したデバイス１２０、つまり、ゲストデバイス１２０であると判断する（Ｓ８０７）。
ゲストデバイス１２０がホームサーバ１００にネットワーク設定要請を行なう（Ｓ８０８）。

ここで、ホームサーバ１００は、ゲストデバイス１２０に対し、表４のような認証テーブルに登録せず、ネットワーク構成のみを提供できる。

従って、この場合にも前記したように、制御デバイス１２０がＤＨＣＰ方式であるので、ＤＨＣＰ ＩＰがＩＰプールデータベース２２０から提供（ＤＨＣＰ ＩＰ Ｏｆｆｅｒ）され、ＤＨＣＰ ＩＰの要請（ＤＨＣＰ ＩＰ Ｒｅｑｕｅｓｔ）に従って提供（ＤＨＣＰ ＩＰ Ａｃｋ）されたＩＰが制御デバイス１２０、つまり、ゲストデバイス１２０に割り当てられ（Ｓ８０５）、ネットワーク設定が完了する（Ｎｅｔｗｏｒｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｓｕｃｃｅｓｓ）。

そして、例えば、ゲストデバイス１２０が単にＤＨＣＰで動作することを望む場合には、これは認証を必要としない制御デバイスであるので、インターネット程度の制限されたサービスのみ許容し、ホームネットワーク内部の各種サービスデバイス１１１，１１２，１１３に対する接近を許容しないように実現できる。また、ゲストデバイス１２０に対してインターネットサービスをも遮断したい場合には、ブリッジング及びルーティングテーブルによって遮断することができる。

図９は、他の実施形態によるデバイスがＰＰＰＯＥでアクセスする場合のネットワーク設定手続きを示すフローチャートである。
図９に示すように、まず、ゲストデバイス１２０からホームサーバ１００にネットワーク設定要請がある（Ｓ９０１）。

ゲストデバイス１２０が転送した入力パケットを介してＰＰＰＯＥを発見し（Ｓ９０２）、ＰＰＰＯＥプロトコルに従ってネットワーク設定処理を行なう。

ここで、図１１Ｂに示すように、ゲストデバイス１２０に対するＭＡＣアドレス１１００がＭ３、デバイスＩＤ１１１０がＰＤＡ、ユーザＩＤ１１４０がゲスト２、パスワード１１５０が＊＊＊＊（パスワード保護のために）である。

ゲストデバイス１２０が認証テーブルに登録されているか否か判断する（Ｓ９０３）。
以下の表５のように、ゲストデバイス１２０が認証テーブルに登録されている場合（ここで、ＩＰ及び状態情報は登録されていない。）（Ｓ９０３で「Ｙ」）、追加的なＭＡＣアドレス登録過程なしで、ゲストデバイス１２０に対し、前記したように、ＰＰＰＯＥプロトコルに応じてネットワーク設定処理を行なう。

即ち、前記のように、ゲストデバイス１２０がＰＰＰＯＥ方式であるので、ＰＰＰＯＥデモンが実行され（Ｓ９０５）、ＰＰＰＯＥセッションが実行され（Ｓ９０６）、ＰＰＰＯＥプロトコルによるＰＰＰＯＥセッションステージ（つまり、前記ＰＰＰ ＬＣＰ、ＩＰＣＰ、ＰＡＰ、ＣＨＡＰなど）が実行される（Ｓ９０７）。

最後に、ホームサーバ１００とゲストデバイス１２０間のトンネルリングが完成し、ゲストＩＤ、ユーザＩＤに対するＩＰを前記表５のような認証テーブルに登録し（Ｓ９０８）、ネットワーク設定が成功的に完了する（Ｎｅｔｗｏｒｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｓｕｃｃｅｓｓ）。

一方、図１１Ｂに示すように、ゲストデバイス１２０に対するＭＡＣアドレス１１００がＭ３、デバイスＩＤ１１１０がＰＤＡ、ユーザＩＤ１１４０がゲスト２、パスワード１１５０が＊＊＊＊（パスワード保護のために）であり、以下の表６のように、認証テーブルに登録されていない場合（Ｓ９０３で「Ｎ」）、追加的なＭＡＣアドレス登録過程を経て（Ｓ９０４）、表６を表５のように、テーブルアップデート（つまり、ＭＡＣアドレスを先に登録）した後、ゲストデバイス１２０に対し、前記と同様に、ＰＰＰＯＥプロトコルに応じてネットワーク設定処理を行なう。

この場合も、前記したように、ゲストデバイス１２０がＰＰＰＯＥ方式であるので、ＰＰＰＯＥデモンが実行され（Ｓ９０５）、ＰＰＰＯＥセッションが実行され（Ｓ９０６）、ＰＰＰＯＥプロトコルによるＰＰＰＯＥセッションステージ（つまり、ＰＰＰ ＬＣＰ、ＩＰＣＰ、ＰＡＰ、ＣＨＡＰなど）が行なわれる（Ｓ９０７）。

最後に、ホームサーバ１００と前記ゲストデバイス１２０間のトンネルリングが完成し、前記ゲストＩＤ、ユーザＩＤに対するＩＰを前記表５のような認証テーブルに登録し（Ｓ９０８）、ネットワーク設定が成功的に完了する（Ｎｅｔｗｏｒｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｓｕｃｃｅｓｓ）。

図１０は、更に他の実施形態に係るデバイスが自動ＩＰでアクセスする場合のネットワーク設定手続きを示すフローチャートである。
図１０に示すように、まず、制御デバイス１１０、１２０からホームサーバ１００にネットワーク設定要請が行なわれる（Ｓ１００１）。

ホームサーバ１００が、制御デバイス１１０、１２０が自動ＩＰ設定デバイス（Ａｕｔｏ ＩＰ ｄｅｖｉｃｅ）であるか否か判断する（Ｓ１００３）。

制御デバイス１１０、１２０が自動ＩＰ設定デバイス（Ａｕｔｏ ＩＰ ｄｅｖｉｃｅ）である場合（Ｓ１００３で「Ｙ」）には、後述するＭＡＣアドレス確認（Ｓ１００３）及びＰＰＰＯＥクライアントモジュールが存在するか否かを確認し（Ｓ１００５）、ネットワークネットワーク設定手続きを行なう。

この時、図１１Ｂに示すように、制御デバイス１１０、１２０に対するＭＡＣアドレス１１００がＭ３、デバイスＩＤ１１１０がＰＤＡ、ユーザＩＤ１１４０がゲスト２、パスワード１１５０が＊＊＊＊（パスワード保護のために）であり、以下の表７のように、認証テーブルに登録されている場合（ここで、ＩＰ及び状態情報は登録されていない。）（Ｓ１００３で「Ｙ」）、制御デバイス１１０、１２０をレガシーデバイス１１０であると判断し、追加的なＰＰＰＯＥ処理過程なしでレガシーデバイス１１０に対するネットワーク設定処理を行なう（Ｓ１０１１）。

一方、図１１Ｂに示すように、制御デバイス１１０、１２０に対するＭＡＣアドレス１１００がＭ３、デバイスＩＤ１１１０がＰＤＡ、ユーザＩＤ１１４０がゲスト２、パスワード１１５０が＊＊＊＊（パスワード保護のために）であり、以下の表８のように、認証テーブルに登録されていない場合（Ｓ１００３で「Ｎ」）、制御デバイス１１０、１２０をゲストデバイス１２０として認識し（Ｓ１００４）、ゲストデバイス１２０にＰＰＰＯＥクライアントモジュール（ＰＰＰＯＥ Ｃｌｉｅｎｔ Ｍｏｄｕｌｅ）が存在するか否かを確認する（Ｓ１００５）。

ゲストデバイス１２０にＰＰＰＯＥクライアントモジュールが存在する場合（Ｓ１００５で「Ｙ」）には、ＰＰＰＯＥデモンが実行され（Ｓ１００８）、ＰＰＰＯＥセッションが実行され（Ｓ１００９）、ＰＰＰＯＥプロトコルによるＰＰＰＯＥセッションステージ（つまり、前記ＰＰＰ ＬＣＰ、ＩＰＣＰ、ＰＡＰ、ＣＨＡＰなど）が実行される（Ｓ１０１０）。

ホームサーバ１００とゲストデバイス１２０間のトンネルリングが完成し、ゲストデバイス１２０のＭＡＣアドレス、ユーザＩＤ及び割り当てられたＩＰアドレスなどを表７のように認証テーブルに登録して、表８を表７のように、テーブルアップデートする。このようにして、ゲストデバイス１２０に対するネットワーク設定が成功的に完了する（Ｎｅｔｗｏｒｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｓｕｃｃｅｓｓ）（Ｓ１０１１）。

ゲストデバイス１２０にＰＰＰＯＥクライアントモジュールが存在しない場合（Ｓ１００５で「Ｎ」）には、ゲストデバイス１２０にＰＰＰＯＥデモンを生成した後、前記したようなＰＰＰＯＥによるネットワーク設定手続きを行なう。このとき、ゲストデバイス１２０に対するＰＰＰＯＥクライアントモジュール生成方法としては、ホストサーバ１００からゲストデバイス１２０にＰＰＰＯＥクライアントモジュール生成のためのＰＰＰＯＥクライアントファイル（例えば、ＰＰＰＯＥクライアントバイナリファイル（ＰＰＰＯＥ Ｃｌｉｅｎｔ Ｂｉｎａｒｙ ｆｉｌｅ）を転送する（Ｓ１００６）。このときＰＰＰＯＥクライアントファイルの転送は、ＪＶＭ（Ｊａｖａ（登録商標） Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）によって実現できる。

ＰＰＰＯＥクライアント生成のためのファイルを受信したゲストデバイス１２０は、受信したＰＰＰＯＥクライアントファイルを実行してＰＰＰＯＥクライアントモジュールを生成する（Ｓ１００７）。

このように、ゲストデバイス１２０にＰＰＰＯＥクライアントモジュールが生成されれば、ゲストデバイス１２０に対してＰＰＰＯＥによるネットワーク設定手続きが正常的に実行される。
即ち、ＰＰＰＯＥデモンが実行され（Ｓ１００８）、ＰＰＰＯＥセッションが実行され（Ｓ１００９）、ＰＰＰＯＥプロトコルによるＰＰＰＯＥセッションステージ（つまり、ＰＰＰ ＬＣＰ、ＩＰＣＰ、ＰＡＰ、ＣＨＡＰなど）が行なわれる（Ｓ１０１０）。

最後に、ホームサーバ１００とゲストデバイス１２０間のトンネルリングが完成し、ゲストデバイス１２０のＭＡＣアドレス、ユーザＩＤ及び割り当てられたＩＰアドレスなどを表７のように認証テーブルに登録して、表８を表７のように、テーブルアップデートする。このようにして、ゲストデバイス１２０に対するネットワーク設定が完了する（Ｎｅｔｗｏｒｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｓｕｃｃｅｓｓ）（Ｓ１０１１）。

以上のように、各制御デバイス１１０、１２０の通信プロトコル形式に応じて各制御デバイス１１０、１２０がホームサーバ１００を介してネットワークを設定する手続きを説明した。

次に、図１２を参照して制御デバイス１１０、１２０に対するネットワーク設定後にサービスが提供される手続きを説明する。

図１２は、他の実施形態に係るネットワーク設定後、デバイス毎にサービスを提供する手続きを示すフローチャートである。
図１２に示すように、前記のように、ネットワーク設定が完了すれば（Ｓ１２０１）、ゲストデバイス１２０に対する認証が完了することによって、ゲストデバイス１２０の登録手続きが行なわれる（Ｓ１２０２）。

一方、前記のようなサービス許可に対する登録メッセージは、以下のようなｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）文書で作製することができる。

この文書において、ｐｕｂｌｉｃＫｅｙＴｏｋｅｎ＝“４ｃ４９９６０３９ｅｄｅ”は、制御デバイス１１０、１２０のＭＡＣアドレスを示し、＜ＵｓｅｒＩｎｆｏ＞はユーザＩＤを意味する。

これにより、ゲストデバイス１２０に対する許可情報が許可サーバ１３０内に含まれた装置及び許可リストデータベース１３１の許可テーブルに登録される（Ｓ１２０３）。例えば、前記登録されるゲストデバイス１２０のＩＤがゲスト２、ＭＡＣアドレスがＭ３であり、ゲストデバイス１２０のユーザが未成年である場合には、以下の表９のように登録することができる。

許可テーブルの登録が完了した後、ゲストデバイス１２０がホームサーバ１００を介してサービス要請を行う（Ｓ１２０４）。

ホームサーバ１００が、登録された許可テーブルの許可情報を確認し、サービスの許可／不許可を判断する（Ｓ１２０５）。この時、サービスが許容される場合（Ｓ１２０５「Ｙ」）、要請されたサービスを提供するが（Ｓ１２０６）、サービスの提供が許容されない場合には、当該サービスを提供せず、ホームサーバ１００がゲストデバイス１２０にサービス拒絶メッセージを転送する（Ｓ１２０７）。
ここで、前記サービス要請メッセージは、以下のＸＭＬ文書で作成することができる。

この文章において、＜ａｃｔｉｖａｔｅｄ ＳｅｒｖｉｃｅＮａｍｅ＝“Ｍｏｖｉｅ＿Ａｄｕｌｔ．ｍｐｇ”／＞は、当該制御デバイス１１０、１２０が要請するサービスコンテンツを示し、＜ａｃｔｉｖａｔｅｄ ＳｅｒｖｉｃｅＮｕｍｂｅｒ＝“８”／＞は、要請したサービスの番号を示す。
また、サービス要請による許可メッセージは、以下のＸＭＬ文書で作成することができる。

この文章において、＜Ｒｅｓｕｌｔ＝“Ａｌｌｏｗ”／＞部分がサービス要請が許可されたことを意味する。

このサービスの提供が終了した場合、または、サービス拒絶メッセージを転送された場合に、他のサービス要請があるかどうか確認する（Ｓ１２０８）。
他のサービス要請がある場合には（Ｓ１２０８で「Ｙ」）、ステップＳ１２０５に戻る。

他のサービス要請がない場合には（Ｓ１２０８で「Ｎ」）、ゲストデバイス１２０がＰＰＰＯＥ方式である場合には、ＰＰＰＯＥデモンを解除して終了し、ゲストデバイス１２０がＤＨＣＰ方式である場合には、ＤＨＣＰデモンを解除して終了する（Ｓ１２０９）。

以上、制御デバイス１２０のホームサーバ１００によるホームネットワークのネットワークアクセス及びサービス提供手続きを説明した。
次に、図１３及び図１４を参照して、ホームサーバ１００を実際にハードウェアまたはソフトウェア上で実現した一例について説明する。

図１３は、本実施形態に係るホームサーバを実際に実現した一例を示す図面である。
図１３に示すように、ホームサーバ１００は、前記のように、装置及び許可リストデータベース１３１を含む許可サーバ１３０と連結されたり、許可サーバ１３０を含めて構成することができる。

一方、ホームサーバ１００は、ＰＰＰＯＥサーバ機能及びＤＨＣＰサーバ機能を同時に実行するために、従来のホームサーバ１００構成にＰＰＰＯＥアプリケーション１３３０及びＤＨＣＰアプリケーション１３４０を同時に含む構成を有する。

また、ホームサーバ１００と許可サーバ１３０、または制御デバイス１１０、１２０間で本発明による許可及びサービス要請メッセージを送受信するために、所定のＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書を生成するＸＭＬ Ｐａｒｓｅｒ／Ｇｅｎｅｒａｔｏｒ１３００をさらに含む。

同時に、前記のように、制御デバイス１１０、１２０がＰＰＰＯＥ形式のパケットであるか、ＤＨＣＰ形式のパケットであるかを判別し、各形式に応じた処理を行なうために、イーサネット（登録商標）型検査及びＭＡＣアドレスマッピングテスク（Ｅｔｈｅｒｎｅｔ（登録商標） ｔｙｐｅ ｃｈｅｃｋ＆ＭＡＣ ａｄｄｒｅｓｓ ｍａｐｐｉｎｇ Ｔａｓｋ）１３２０を含む。また、制御デバイス１１０、１２０の認証のために、サービス及び装置リストデータベース（Ｓｅｒｖｉｃｅ＆ｄｅｖｉｃｅ ｌｉｓｔ ＤＢｓ）１３１０をさらに含む。

図１４は、本発明の実施形態に従ってホームサーバ装置を実現した細部機能ブロックを示すブロック図である。即ち、図１３に示すホームサーバ１００をデバイス詳細機能（Ｄｅｖｉｃｅ Ｓｐｅｃｉｆｉｃ ｆｕｎｃｔｉｏｎ）に従って、図１４のように、細部機能ブロックで示すことができる。

このように、図１４に示すように、本実施形態による機能を実行するために、一般のホームサーバ１００の各種デバイスにＵＰｎＰ１４００、デバイスリストＤＢ１３１２、サービスリストＤＢ１３１１、ＸＭＬパーサ／生成器１３００、ＰＰＰ１４１０，ＰＰＰＯＥサーバ１４２０、ＤＨＣＰサーバ１４３０、イーサネット（登録商標）ヘッダ型検査モジュール１３２１、及びＭＡＣアドレスマッピングモジュール１３２２などをさらに含む。

本発明が適用されるホームネットワークのデバイスアクセス状況を示す。 本発明によるホームネットワークのデバイス及びユーザの認証システムを示す。 本発明の実施形態によるホームネットワークシステムのホームサーバの機能的な構成を示す。 本発明の実施形態によるホームサーバのプロトコル選択手続きを示すフロー図である。 本発明の実施形態によるイーサネット（登録商標）パケットの構造を示す。 本発明の実施形態によるホームネットワークのデバイス及びユーザ認証手続きを示すフロー図である。 本発明の実施形態による外部デバイスのユーザ認証のためのユーザ情報入力窓を示す。 本発明の第１実施形態によるデバイスがＤＨＣＰで接続する場合のネットワーク設定手続きを示す。 本発明の第２実施形態によるデバイスがＰＰＰＯＥで接続する場合のネットワーク設定手続きを示す。 本発明の第３実施形態によるデバイスが自動ＩＰで接続する場合のネットワーク設定手続きを示す。 本発明の実施形態によるゲストデバイスの情報構成を示す。 本発明の実施形態によるゲストデバイスの情報構成を示す。 本発明の実施形態による他のネットワーク設定後にデバイス毎にサービスを提供する手続きを示すフロー図である。 本発明の実施形態によるホームサーバの実際の実現例を示す。 本発明の実施形態に従ってホームサーバ装置を実現した細部機能ブロックを示す。

符号の説明

１００ ホームサーバ
１１０ レガシーデバイス
１２０ ゲストデバイス
１２１ 外部デバイス
１３０ 許可サーバ
１３１ 装置及び許可リストＤＢ
１４０ インターネット
２００ ＤＨＣＰ処理部
２１０ ＰＰＰＯＥ処理部
２２０ ＩＰプールＤＢ
２３０ ＰＰＰＯＥクライアント
３００ ユーザ及びデバイス認証装置
３１０ イーサネット（登録商標）型検査部
３２０ ＰＰＰＯＥデモン
３３０ ＰＰＰデモン
３４０ ユーザ認証部
３５０ ＤＨＣＰポート番号検査部
３６０ ＤＨＣＰデモン
３７０ ＭＡＣアドレス認証部
３８０ ユーザ及びデバイス認証ＤＢ

Claims (33)

1. サービスコンテンツを提供するサービスデバイスと、
   ホームネットワークの一つ以上のデバイスを管理し、前記各デバイスに対する認証情報を含み、前記認証情報に従って前記各デバイスに対するネットワークを設定するホームサーバと、
   前記ホームサーバを介してネットワーク認証を行なう制御デバイスと、
   前記ホームサーバと連結され、前記サービスコンテンツに対する前記許可サーバにおける許可／不許可に従って、前記サービスデバイスから前記サービスコンテンツの提供を受ける前記制御デバイス、前記制御デバイスの性格に応じてサービス許可に対する情報を含む許可サーバと、
   を備えることを特徴とするホームネットワークにおけるデバイス及びユーザ認証システム。
2. 前記許可サーバは、
   前記制御デバイスの性格に応じてサービス許可に対する情報をテーブル形態で管理する装置及び許可リストデータベースを有することを特徴とする請求項１に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
3. 前記装置及び許可リストデータベースは、前記制御デバイスの性格に応じたサービスデバイス許可に対する情報をさらに有することを特徴とする請求項２に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
4. 前記ホームサーバは、
   前記各デバイスに対する認証情報を前記各デバイスとマッピングして保存する認証テーブルを有することを特徴とする請求項１に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
5. 前記ホームサーバにおいて、前記制御デバイスに対する認証は、前記制御デバイスの媒体接続制御階層のアドレス情報で行なうことを特徴とする請求項１に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
6. 前記ホームサーバにおいて、前記制御デバイスに対する認証は、ユーザＩＤ及びパスワード情報で行なうことを特徴とする請求項１に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
7. 前記ホームサーバは、
   前記制御デバイスに対するユーザ認証、デバイス認証及びネットワーク設定を同時に処理することを特徴とする請求項１に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
8. 前記ホームサーバは、
   前記制御デバイスからのＤｙｎａｍｉｃ ｈｏｓｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｒｏｔｏｃｏｌ（ＤＨＣＰ）パケットと、Ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ（登録商標）（ＰＰＰＯＥ）パケットを同時に処理できることを特徴とする請求項１に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
9. 前記ホームサーバは、
   ネットワーク設定を要請した前記制御デバイスからの入力パケットデータの類型を確認するイーサネット（登録商標）型検査部と、
   前記イーサネット（登録商標）型検査部で検査された入力パケットデータ類型に応じてＰＰＰＯＥ処理を行なうことができるＰｏｉｎｔ−ｔｏ−ｐｏｉｎｔ ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ（登録商標）（ＰＰＰＯＥ）サーバと、
   前記イーサネット（登録商標）型検査部で検査された入力パケットデータ類型に応じてＤＨＣＰ処理を行なうことができるＤｙｎａｍｉｃ ｈｏｓｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｒｏｔｏｃｏｌ（ＤＨＣＰ）サーバと、
   前記各ＰＰＰＯＥ及びＤＨＣＰ処理後、ユーザ及びデバイス認証を行なうユーザ／デバイス認証データベースと、
   を有することを特徴とする請求項１に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
10. 前記ＰＰＰＯＥサーバは、
    ＰＰＰＯＥ処理要請に従ってプロセスを実行するＰＰＰＯＥデモンと、
    前記ＰＰＰＯＥデモン実行後、ＰＰＰ処理要請に従ってプロセスを実行するＰＰＰデモンと、
    前記ＰＰＰデモン実行後、ＰＰＰＯＥにおけるユーザ認証を担当するユーザ認証部と、
    を有することを特徴とする請求項９に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
11. 前記ＤＨＣＰサーバは、
    ＤＨＣＰパケットに対するポート番号を検査するＤＨＣＰポート番号検査部と、
    前記ＤＨＣＰポート番号検査後、ＤＨＣＰ処理要請に従ってプロセスを実行するＤＨＣＰデモンと、
    前記ＤＨＣＰデモン実行後、前記ＤＨＣＰパケットのｍｅｄｉａ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ（ＭＡＣ）アドレスを認証するＭＡＣアドレス認証部と、
    を有することを特徴とする請求項１０に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
12. 前記イーサネット（登録商標）型検査部は、
    前記入力パケットデータのデータフィールドの中でイーサネット（登録商標）型情報を含むフィールドを確認し、前記フィールドに記録された情報によって前記入力パケットデータがＤＨＣＰパケットであるか、ＰＰＰＯＥパケットであるかを判断することを特徴とする請求項９に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
13. 前記イーサネット（登録商標）型検査部で確認した前記入力パケットデータのイーサネット（登録商標）型がＤＨＣＰパケットである場合、ペイロードのＩＰパケット領域によってＩｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ（ＩＰ）パケット情報を確認することを特徴とする請求項１２に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
14. 前記イーサネット（登録商標）型検査部で確認した前記入力パケットデータのイーサネット（登録商標）型がＤＨＣＰパケットである場合、ペイロードのＩＰパケット領域によってＵｓｅｒ ｄａｔａ ｐｒｏｔｏｃｏｌ（ＵＤＰ）情報を確認することを特徴とする請求項１２に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
15. 前記ホームサーバは、
    前記ＤＨＣＰサーバのＤＨＣＰデモンと前記ＰＰＰＯＥサーバのＰＰＰＯＥデモンが割当可能なＩＰ情報を含むＩＰプールデータベースに同時にアクセス可能であることを特徴とする請求項１１に記載のホームネットワークにおけるデバイス及びユーザ認証システム。
16. ホームネットワークの各種サービスデバイスを制御して、前記サービスデバイスからサービスの提供を受けようとするユーザは、制御デバイスがホームサーバを介して認証を受ける段階と、
    前記制御デバイスが前記ホームサーバに前記サービスデバイスに対するサービス要請を行なう段階と、
    前記サービス要請に従って前記制御デバイスが前記ホームサーバと連動する許可サーバを介して前記要請されたサービスに対するサービス許可を受ける段階と、
    前記サービス許可に従って、前記制御デバイスが前記サービスデバイスから前記要請したサービスの提供を受ける段階と、
    を含むことを特徴とするホームネットワークにおけるデバイス及びユーザ認証方法。
17. 制御デバイスがホームネットワークにアクセスする際に、前記制御デバイスをホームサーバの認証テーブルに登録する段階と、
    前記ホームサーバから許可サーバにサービス許可登録メッセージを転送する段階と、
    前記許可サーバが前記当該制御デバイスに対する許可情報を前記許可サーバに登録する段階と、
    前記制御デバイスが前記ホームサーバにサービスデバイスからのサービス提供要請を行なう段階と、
    前記ホームサーバが前記制御デバイスが要請した前記サービス提供の許可されたサービスであるかを前記許可サーバによって確認する段階と、
    前記確認結果、許可が許容された場合、前記サービスデバイスから前記制御デバイスによって要請されたサービスが提供される段階と、
    を含むことを特徴とする請求項１６に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
18. 前記要請されたサービスの許可が許容される時、
    前記ホームサーバ、制御デバイス及び前記要請されたメディアコンテンツを提供する当該サービスデバイス間でマッチングするプロトコル、ポート及びフォーマットに対する選択を行なう段階と、
    前記ホームサーバが前記制御デバイスと前記サービスデバイス間のルーティングテーブル及びブリッジングテーブルを更新する段階と、
    を含むことを特徴とする請求項１７に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
19. 前記許可サーバは、前記制御デバイスの性格に応じてサービス許可に対する情報をテーブル形態で管理することを特徴とする請求項１６に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
20. 前記許可サーバは、前記制御デバイスに対する性格に応じたサービスデバイス許可に対する情報をさらに含むことを特徴とする請求項１９に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
21. 前記ホームサーバは、前記各デバイスに対する認証情報を前記各デバイスとマッピングして保存する認証テーブルを含むことを特徴とする請求項１６に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
22. 前記ホームサーバにおいて、前記制御デバイスに対する認証は、前記制御デバイスの媒体接続制御階層のアドレス情報で行なわれることを特徴とする請求項１６に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
23. 前記ホームサーバにおいて、前記制御デバイスに対する認証は、ユーザＩＤ及びパスワード情報で行なわれることを特徴とする請求項１６に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
24. 前記ホームサーバは、前記制御デバイスに対するユーザ認証、デバイス認証及びネットワーク設定を同時に処理することを特徴とする請求項１６に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
25. 前記ホームサーバは、前記制御デバイスからのｄｙｎａｍｉｃ ｈｏｓｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｒｏｔｏｃｏｌ（ＤＨＣＰ）パケットと、Ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｅｔｅｒｎｅｔ（ＰＰＰＯＥ）パケットを同時に処理できることを特徴とする請求項１６に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
26. 前記サービス許可が許容されない場合には、
    前記許可サーバが前記ホームサーバのサービス許可要請メッセージの応答としてサービス許可拒絶メッセージを前記ホームサーバに転送する段階と、
    前記許可サーバから前記サービス許可拒絶メッセージを受信した前記ホームサーバが前記当該制御デバイスに拒絶メッセージを転送する段階と、
    をさらに含むことを特徴とする請求項１６に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
27. 制御デバイスがホームサーバにネットワーク設定のための要請を転送する段階と、
    前記制御デバイスが転送した入力パケットのプロトコルを確認する段階と、
    前記確認結果、入力パケットのプロトコルがＤＨＣＰプロトコルであると確認される場合、前記制御デバイスに対するＭＡＣアドレスが認証テーブルに登録されているか否かを確認する段階と、
    前記確認結果、ＭＡＣアドレスが認証テーブルに登録されている場合には、前記制御デバイスにｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ（ＩＰ）を割り当てる段階と、
    前記制御デバイスが前記ホームサーバとのネットワーク設定を完了する段階と、
    前記制御デバイスのサービス許可と関連する情報を許可テーブルに登録する段階と、
    前記許可テーブルに前記要請されたサービスが許可されたか否かを判断する段階と、
    前記判断結果、前記要請されたサービスが許可された場合、前記要請されたサービスを提供する段階と、
    をさらに含むことを特徴とするホームネットワークにおけるデバイス及びユーザ認証方法。
28. 前記認証テーブルの登録／不登録を確認した結果、ＭＡＣアドレスが認証テーブルに登録されていない場合には、前記制御デバイスをゲストデバイスとして認識し、ネットワーク設定を再要請する段階をさらに含むことを特徴とする請求項２７に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
29. 制御デバイスがホームサーバにネットワーク設定のための要請を転送する段階と、
    前記制御デバイスから転送された入力パケットのプロトコルを確認する段階と、
    前記確認結果、入力パケットのプロトコルがＰＰＰＯＥプロトコルであると確認される場合、前記制御デバイスに対するＭＡＣアドレスが認証テーブルに登録されているか否かを確認する段階と、
    前記確認結果、ＭＡＣアドレスが認証テーブルに登録されている場合、前記制御デバイスにＰＰＰＯＥデモンによってネットワーク設定を行う段階と、
    前記制御デバイスのサービス許可に関連する情報を許可テーブルに登録する段階と、
    前記許可テーブルに前記要請されたサービスが許可されたか否かを判断する段階と、
    前記判断結果、前記要請されたサービスが許可された場合、前記要請されたサービスを提供する段階と、
    をさらに含むことを特徴とするホームネットワークにおけるデバイス及びユーザ認証方法。
30. 前記認証テーブルの登録／不登録を確認した結果、ＭＡＣアドレスが認証テーブルに登録されていない場合、前記制御デバイスのＭＡＣアドレスを認証テーブルに登録する段階をさらに含むことを特徴とする請求項２９に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
31. 制御デバイスがホームサーバにネットワーク設定のための要請を転送する段階と、
    前記制御デバイスに対してＩＰアドレス自動設定であるか否かを確認する段階と、
    前記確認結果、ＩＰアドレス自動設定である場合、前記制御デバイスに対するＭＡＣアドレスが認証テーブルに登録されているか否かを確認する段階と、
    前記確認結果、ＭＡＣアドレスが認証テーブルに登録されている場合、ネットワーク設定を完了する段階と、
    前記制御デバイスのサービス許可に関連する情報を許可テーブルに登録する段階と、
    前記許可テーブルに前記要請されたサービスが許可されたか否かを判断する段階と、
    前記判断結果、前記要請されたサービスが許可された場合、前記要請されたサービスを提供する段階と、
    をさらに含むことを特徴とするホームネットワークにおけるデバイス及びユーザ認証方法。
32. 前記確認結果、ＭＡＣアドレスが認証テーブルに登録されていない場合、前記制御データベースにＰＰＰＯＥクライアントモジュールが存在するか否かを確認する段階と、
    前記確認結果、ＰＰＰＯＥクライアントモジュールが存在する場合、前記制御デバイスにＰＰＰＯＥデモンによってネットワーク設定を行なう段階と、
    をさらに含むことを特徴とする請求項３０に記載のホームネットワークにおけるデバイス及びユーザ認証方法。
33. 前記確認結果、ＰＰＰＯＥクライアントモジュールが存在しない場合、前記制御デバイスにＰＰＰＯＥクライアントファイルを転送する段階と、
    前記制御デバイスが前記受信したＰＰＰＯＥクライアントファイルを実行し、前記ＰＰＰＯＥクライアントモジュールを生成する段階と、
    をさらに含むことを特徴とする請求項３２に記載のホームネットワークにおけるデバイス及びユーザ認証方法。

Images