(57)【要約】【課題】被メンテナンス装置がメンテナンス情報を自ら取得する手段を実装していない場合でも被メンテナンス装置のメンテナンス情報を取得する。【解決手段】１以上の被メンテナンス装置と前記被メンテナンス装置からメンテナンス情報の問い合わせ先を特定する情報を収集し、前記被メンテナンス装置に対応したメンテナンス問い合わせ先より前記メンテナンス情報を入手するメンテナンスから構成され、前記メンテナンス手段が、前記メンテナンス情報の問い合わせ先から前記被メンテナンス装置のメンテナンス情報を代理で取得する。【選択図】  図１
2004260683.tif 000002
【特許請求の範囲】
【請求項１】
１以上の被メンテナンス装置と前記被メンテナンス装置からメンテナンス情報の問い合わせ先を特定する情報を収集し、前記被メンテナンス装置に対応したメンテナンス問い合わせ先より前記メンテナンス情報を入手するメンテナンス手段からなるメンテナンスシステム。
【請求項２】
前記メンテナンス手段は前記メンテナンス情報を前記被メンテナンス装置に配信することを特徴とする請求項１に記載のメンテナンスシステム。
【請求項３】
前記メンテナンス情報の問い合わせ先を特定する情報はＷｅｂサイトのＵＲＬ（Ｕｎｉｆｏｒｍ＿Ｒｅｓｏｕｒｃｅ＿Ｌｏｃａｔｏｒ）とする請求項１または２に記載のメンテナンスシステム。
【請求項４】
前記メンテナンス情報の問い合わせ先を特定する情報は少なくとも前記被メンテナンス装置の製造事業者を特定する情報又は販売業者を特定する情報のいずれかを含むことを特徴とする請求項１または２に記載の被メンテナンスシステム。
【請求項５】
前記メンテナンス情報はソフトウェアの最新情報、又はファームウェアの最新情報、又は機器障害の情報、又は機器使用・操作方法の情報、又は新機能あるいは新製品の情報のうち、少なくとも一つの情報を含むことを特徴とする請求項１から４のいずれかに記載のメンテナンスシステム。
【請求項６】
前記被メンテナンス装置が２以上（複数）ある場合に実質的に同時に前記メンテナンス情報を問い合わせることを特徴とする請求項１から５のいずれかに記載のメンテナンスシステム。
【請求項７】
前記メンテナンス手段と前記メンテナンス情報問い合わせ先は公衆網で接続されることを特徴とする請求項１から６のいずれかに記載のメンテナンスシステム。
【請求項８】
前記公衆網はインターネットとする請求項７に記載のメンテナンスシステム
【請求項９】
前記メンテナンス手段と前記被メンテナンス装置はローカルエリアネットワークで接続されることを特徴とする請求項１から６のいずれかに記載のメンテナンスシステム。
【請求項１０】
前記ローカルエリアネットワークはイーサネット（登録商標）で構成されることを特徴とする請求項９に記載のメンテナンスシステム。
【請求項１１】
前記ローカルエリアネットワークはエコーネットのプロトコルを用いたネットワークで構成されることを特徴とする請求項９に記載のメンテナンスシステム。
【請求項１２】
前記ローカルエリアネットワークはＩＥＥＥ１３９４のプロトコルを用いたネットワークで構成されることを特徴とする請求項９に記載のメンテナンスシステム。
【請求項１３】
前記ローカルエリアネットワークは無線を用いたネットワークで構成されることを特徴とする請求項９に記載のメンテナンスシステム。
【請求項１４】
前記メンテナンス手段は公衆網に接続するプロトコルを実装することを特徴とする請求項１から１１のいずれかに記載のメンテナンスシステム。
【請求項１５】
前記被メンテナンス装置は公衆網に接続するプロトコルを実装していないことを特徴とする請求項１から１１のいずれかに記載のメンテナンスシステム。
【請求項１６】
前記被メンテナンス装置のメンテナンス情報の問い合わせ先を特定する情報を格納する被メンテナンス装置。
【請求項１７】
前記メンテナンス情報の問い合わせ先を特定する情報は、ＷｅｂサイトのＵＲＬ（Ｕｎｉｆｏｒｍ＿Ｒｅｓｏｕｒｃｅ＿Ｌｏｃａｔｏｒ）とする請求項１６に記載の被メンテナンス装置。
【請求項１８】
前記メンテナンス情報の問い合わせ先を特定する情報は少なくとも前記被メンテナンス装置の製造事業者を特定する情報又は販売業者を特定する情報のいずれかを含むことを特徴とする請求項１６または１７に記載の被メンテナンスシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は伝送路を介して機器のメンテナンス情報を入手する被メンテナンス装置とメンテナンスシステムに関するものである。
【０００２】
【従来の技術】
近年、インターネット等の発達により、伝送路（ネットワーク）を介して、機器のメンテナンス情報を問い合わせ、必要であれば機器を最新の状態に更新する方法が一般化している。特にＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  ＤｉｇｉｔａｌＳｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）の普及により、一般家庭でも２４時間常時インターネットに接続する環境が整っている。
【０００３】
ここでメンテナンス情報とは、ソフトウェアの最新版の情報および更新、マイコン等を用いてハードウェアを制御するファームウェアの最新版の情報および更新、機器障害の情報、機器使用・操作方法の情報（操作マニュアル）、新機能や新製品の情報等、機器に関して有用なあらゆる情報を意味する。
【０００４】
一方、メンテナンスを行うためには機器の現在の状態を把握しておくことが必要であり、その情報は機器本体に格納しておくことが当業者にはよく知られている。例えば機器情報を、ＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）として定義し、機器本体に格納する提案として、Ｐｒｏｐｏｓｅｄ  ＳＭＰＴＥ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  Ｐｒａｃｔｉｃｅ  −  Ｐｒｏ−ＡＶ  ＭＩＢ−１  Ａ  ｐｒｏｆｅｓｓｉｏｎａｌ  Ａｕｄｉｏ／Ｖｉｓｕａｌ  Ｐｒｏｄｕｃｔ  Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  ＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ  （Ｓ２２．４９０−２６０７Ｂ  ：  ２００２年１２月提案）がある。この提案は、機器の、製造事業者名、機種情報、シリアル番号、ソフトウェアおよびファームウェアのバージョン情報等をＭＩＢとして定義するものである。ＭＩＢは、ＴＣＰ／ＩＰあるいはＵＤＰ／ＩＰの上位層に実装されるプロトコルであるＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）を用いて取得する。
【０００５】
ネットワークに接続してメンテナンス情報を取得する機器としてはパーソナルコンピュータ（パソコン）が代表的である。例えば、オペレーティングシステムに、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）を搭載したパソコンの場合は、Ｗｉｎｄｏｗｓ（登録商標）  Ｕｐｄａｔｅと称する機能によりＭｉｃｒｏｓｏｆｔ社のウェブサイト（Ｗｅｂサーバ）にアクセスして、オペレーティングシステムおよびそれに関連するソフトウェアの更新の有無を問い合わせ、ユーザが望めばウェブサイトよりダウンロードして最新の状態にすることが可能である（以下、従来技術１と称す）。
【０００６】
さらに、Ｍｉｃｒｏｓｏｆｔ社のウェブサイトから不具合の情報、修正プログラム等の最新情報を２４時間自動収集し、複数の管理対象となるコンピュータから収束したソフトウェア情報と照らし合わせて、プログラムの不具合をレポートしたり、更新するソフトウェアも市販されている（以下、従来技術２と称す）。
【０００７】
また、ソフトウェアを更新する別の方法として、複数のコンピュータシステムにある同一のファイルの更新処理を略同時に行うものがある（例えば特開平５−２５７７８１号公報（以下、従来技術３））。
【０００８】
また、複数の装置をオンライン状態でリモートからのブロードキャストにより一括して同時にプログラムデータのダウンロードを行うものがある（例えば、特開平５−１５８７０３号公報（以下、従来技術４））。
【０００９】
【特許文献１】
特開平５−２５７７８１号公報
【特許文献２】
特開平５−１５８７０３号公報
【非特許文献２】
プロポーッズド  エス・エム・ピー・ティー・イー  レコメンデイション  プラクティス  プロ  エイヴィ  エム・アイ・ビー−１−エイ  プロフィッショナル  オーディオ／ヴィジュアル  シンプル  ネットワーク  マネージメント  プロトコル  マネージメント  インフォーメイション  ベイス（エス２２．４９０−２６０７Ｂ  ：  ２００２年１２月提案）
Ｐｒｏｐｏｓｅｄ  ＳＭＰＴＥ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  Ｐｒａｃｔｉｃｅ  −  Ｐｒｏ−ＡＶ  ＭＩＢ−１  Ａ  ｐｒｏｆｅｓｓｉｏｎａｌ  Ａｕｄｉｏ／Ｖｉｓｕａｌ  Ｐｒｏｄｕｃｔ  Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ  （Ｓ２２．４９０−２６０７Ｂ  ：  ２００２年１２月提案）
【００１０】
【発明が解決しようとする課題】
しかしながら上記従来の構成では以下のような問題点を有していた。
【００１１】
近年、上記のパソコン等のコンピュータ機器だけでなく、例えば、オーディオ、テレビ、ビデオ（ＶＴＲ）あるいは、洗濯機や冷蔵庫といったような家庭電化製品（家電）等、従来ネットワークとは関係がなかった機器もネットワークに接続されるようになった。以下、ネットワークに接続される家電をネットワーク家電と称す。ネットワーク家電もネットワークを介してメンテナンス情報を取得して、機能の付加や不具合の改善を行う、あるいは該機器に関する様々な情報を収集することは有用である。
【００１２】
しかしながら、上記従来技術で説明したようなパソコン等では、アップデート対象の機器そのものが、インターネットに接続してソフトウェアの更新等のメンテナンス情報を問い合わせる機能を有している。逆の見方をすると、そのような機能を有さない装置についてはインターネットを介してメンテナンス情報を入手するのは不可能である。
【００１３】
また、仮に機器がメンテナンス情報を問い合わせる機能を有している場合であっても、全ての機器分のインターネット接続回線が確保できるわけではないので全ての機器が直接メンテナンス情報を取得するのは現実的ではい。
【００１４】
一般的にネットワーク家電においては、実装メモリ量削減等製品コスト削減や開発コストの削減さらには消費電力低減のために必ずしも必要でない機能を削減して製品化する。例えば、ネットワーク家電では、必ずしも全ての機器が単独でインターネットに接続する必要はないため、多くの機器はインターネットに接続するためのプロトコルは実装していない。実装しないプロトコルの一例としては、イーサネット（登録商標）で接続された  ＬＡＮ  のユーザーを  インターネットに接続するための仕様  （規格）である、ＰＰＰｏＥ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ  ｏｖｅｒ  Ｅｔｈｅｒｎｅｔ（登録商標））等がある。このプロトコルは、インターネットのプロバイダに接続するために使用される。
【００１５】
上記のことから、ネットワーク家電ではメンテナンス情報の取得が有用であるにもかかわらず、当該機器が直接メンテナンス情報を取得することができないと言う問題点を有していた。
【００１６】
また、仮にインターネットに接続するためのプロトコルを実装していた場合でもすべての家電が独自に更新情報を取得するのは非効率であり、インターネットに接続するための回線も１回線あるいは複数あった場合でも、全ての機器分が用意されているわけでない。
【００１７】
また、上記従来技術３および４は、同一の機種（ソフトウェア）のアップデートを対象としており、異なる機種の更新には対応できなかった。また、同時に同じファイルに更新する場合には有効であるが、ユーザが取捨選択する場合には対応できなかった。また、ユーザが望むタイミングで更新することも不可能であった。これは、更新ファイルを送る側が一方的にファイルを送る仕組みに起因するものである。
【００１８】
また、上記従来技術２においては、同一の機種（ソフトウェア）のアップデートを対象とするため単一の問い合わせ先（ウェブサイト）の時にのみ有効であった。
【００１９】
さらに、一般的に家電は様々な製造事業者の製品で構成されているので、複数の製造事業者のメンテナンス問い合わせ先にアクセスする必要がある。
【００２０】
本願発明は、上記課題を解決するために、更新の問い合わせ機能を有していない機器を代理して、更新問い合わせを行う仕組みを備えることで更新を実現する。
【００２１】
また、製造事業者が異なる製品がネットワークに接続されている場合でも代理で一括して問い合わせることで、実質的に同時に更新が可能とする。
【００２２】
【課題を解決するための手段】
上記課題を解決するために、本願発明は、１以上の被メンテナンス装置と前記被メンテナンス装置からメンテナンス情報の問い合わせ先を特定する情報を収集し、前記被メンテナンス装置に対応したメンテナンス問い合わせ先より前記メンテナンス情報を入手するメンテナンス手段から構成される。
【００２３】
この構成により、メンテナンス手段が被メンテナンス手段のメンテナンス情報問い合わせ先からメンテナンス情報を代理で取得することが可能となる。
【００２４】
【発明の実施の形態】
（実施の形態１）
本実施の形態では、メンテナンス対象の機器（被メンテナンス装置）自身が単独ではメンテナンス情報を取得できない場合に、被メンテナンス装置が接続されたローカルエリアネットワーク内にある、メンテナンス情報を取得することが可能な機器（メンテナンス手段）が代理で被メンテナンス装置のメンテナンス情報を取得する例を説明する。
【００２５】
図１は本願におけるメンテナンスシステムの模式図である。図１において１００はメンテナンス手段、１０１および１０２は被メンテナンス装置、１０３はローカルエリアネットワーク（以下、ＬＡＮ）、１０６は公衆網、１０４および１０５は公衆網１０６に接続されたＷｅｂサーバである。
【００２６】
本実施の形態では、一実施例としてメンテナンス手段１００はパソコン、被メンテナンス装置１０１はＶＴＲ、被メンテナンス装置１０２は冷蔵庫を例とする。一般には被メンテナンス装置はパソコン、サーバ等のコンピュータ以外の家電を示す。
【００２７】
またＬＡＮ１０３は家庭内のネットワークであり、イーサネット（登録商標）を利用した家庭内ネットワークや、電灯線を利用するエコーネット、ＩＥＥＥ１３９４あるいは無線のＩＥＥＥ８０２．１１ｂ等の利用が考えられる。本実施の形態ではイーサネット（登録商標）を例とする。公衆網１０６はインターネットを例とする。
【００２８】
図１においては、ＶＴＲ１０１および冷蔵庫１０２は内部にマイコン等の通信プロトコルを処理する手段が具備されている。したがって、ＬＡＮ１００でのパソコン１００との通信はＴＣＰ／ＩＰ等のプロトコルを使用して通信可能である。また、ＶＴＲ１０１および冷蔵庫１０２には当該機器自身の情報が格納されている。本実施の形態では、少なくともメンテナンス情報の問い合わせ先を格納する。
【００２９】
しかしながら、ＶＴＲ１０１および冷蔵庫１０２はＰＰＰｏＥ等のインターネットへ接続するためのプロトコルは具備していないので、単独でインターネット１０６への接続を機能は備えていない。本願実施の形態ではパソコン１００がメンテナンス情報を提供するインターネット上のＷｅｂサーバを代理でアクセスしてメンテナンス情報を取得する。
【００３０】
次にメンテナンス情報取得の具体例として、ＶＴＲ１０１の内蔵ファームウェアの更新を例として具体的に説明する。ファームウェアの更新により、新機能の追加や不具合の修正等が可能となる。なお、実施の形態１では被メインテナンス装置はＶＴＲ１０１、１台で説明し、冷蔵庫１０２は本実施形態では説明しない。
【００３１】
図２は内蔵ファームウェア更新の通信手順を示す図である。なお、図２においてパソコン１００がインターネット１０６に接続する手順は既に確立されているものとして図示していない。
【００３２】
パソコン１００は最初にＶＴＲ１０１のメンテナンス情報問い合わせ先情報を要求する（２００）。ＶＴＲ１０１はメンテナンス情報の問い合わせ先を回答する（２０１）。メンテナンス情報問い合わせ先は、ＶＴＲ１０１がＡ社製品であるとすると、Ａ社のＷｅｂサイトのＵＲＬを例えば、ｈｔｔｐ：／／ｗｗｗ．ａ．ｃｏｍ  （ただし２００３年２月１６日現在、このようなＵＲＬ登録はない）等とＶＴＲ１０１が回答する方法がある。
【００３３】
パソコン１００はインターネット上でのＡ社製品の問い合わせ先を（Ｗｅｂサーバ）を取得できたので、インターネット１０６を介してＡ社のＷｅｂサーバにＶＴＲ１０１のメンテナンス情報を問い合わせる（２０２）。メンテナンス情報問い合わせのタイミングとしては、例えば一日一回、午前０時に行う等、スケジュール化する等とすればよい。
【００３４】
本実施の形態ではファームウェアの更新を例としているので、更新すべきファームウェアのファイルを取得する（２０３）。なお、更新ファイルの取得に先立ち、更新ファイルに関する情報をあらかじめ取得し、ユーザーに更新が必要であるか否かを判断させてもよい。これはパソコン１００のソフトウェアで容易に実現可能である。
【００３５】
パソコン１００は取得したファームウェアのファイルをＶＴＲ１００に転送して更新する（２０４）。なお、ファームウェアの更新の必要がなければこれらの処理は行われない。その場合は２０３でファームウェアの更新の必要がない旨を通知するなどとすればよい。
【００３６】
以上のように、メンテナンス情報更新の仕組みを持たない装置でも代理でメンテナンス情報取得の仕組みを備えることによりメンテナンスが可能となる。
【００３７】
（実施の形態２）
次に、異なる装置を実質的に同時にメンテナンスを行う方法について説明する。本実施の形態においては、図１において、Ａ社製ＶＴＲ１０１およびＢ社製冷蔵庫１０２を同時にメンテナンスを行う方法を説明する。この場合、製造事業者が異なるので、メンテナンス情報を問い合わせするＷｅｂサーバのＵＲＬも異なる。
【００３８】
図３は上記の異なる製造事業者の製品の内蔵ファームウェア更新の通信手順を示す図である。
【００３９】
まず、パソコン１００はＶＴＲ１０１に対して、メンテナンス情報の問い合わせ先の情報を要求する（３００）。同様にパソコン１００は冷蔵庫１０２に対してもメンテナンス情報の問い合わせ先の情報を要求する（３０１）。ＶＴＲ１０１は図２で説明したのと同様にＡ社のＷｅｂサイトのＵＲＬ情報を回答する（３０２）。また、冷蔵庫１０２も同様にＢ社のＷｅｂサイトのＵＲＬ情報を回答する（３０３）。Ｂ社のＷｅｂサイトのＵＲＬは例えば、ｈｔｔｐ：／／ｗｗｗ．ｂ．ｃｏ．ｊｐ  （ただし２００３年２月１７日現在、このようなＵＲＬ登録はない）である。なお、ＶＴＲ１０１および冷蔵庫１０２の回答に要する時間の差により、問い合わせ回答３０２と３０３の順序が入れ替わる場合もある。また、問い合わせ順序（３００、３０１）も入れ替わってもよい。これら一連の手順により、パソコン１００はＡ社およびＢ社のＷｅｂサイトを知ることが可能となる。
【００４０】
次に、パソコン１００はＡ社のＷｅｂサイト（１０４）に対してメンテナンス情報要求を行う（３０４）。さらに、パソコン１００はＢ社のＷｅｂサイト１０５に対してメンテナンス情報要求を行う（３０５）。図３は図示の都合上３０４と３０５の処理に時間差があるように図示されているが、パソコンのソフトウェア処理は高速に動作しており、（３０４）の処理直後に（３０５）の処理をすることにより、実質的には同時に問い合わせが可能である。なお、３０４と３０５の順序は入れ替わってもよい。
【００４１】
Ａ社のＷｅｂサーバ１０４は、ＶＴＲ１０１のメンテナンス情報を回答する（３０６）。Ｂ社のＷｅｂサーバ１０５は、冷蔵庫１０２のメンテナンス情報を回答する（３０７）。なお、Ｗｅｂサーバの応答時間の違いにより（３０６）と（３０７）の順序は入れ替わる可能性がある。また、現在使用しているファームウェアのバージョンが最新であり、更新する必要がなければ、その旨を回答する。
【００４２】
（３０６）および（３０７）の処理により、ファームウェアの更新が可能であれば、パソコン１００にはＶＴＲ１０１および冷蔵庫１０２のファームウェアのアップデート版がダウンロードされている。
【００４３】
次に、パソコン１００はＶＴＲ１０１に対してファームウェアの更新を行う（３０８）。さらにパソコン１００は冷蔵庫１０２に対してファームウェアの更新を行う（３０９）。なお、ファームウェアの更新の必要がなければこれらの処理は行われない。
【００４４】
以上の処理により、異なる製造事業者の製品がネットワーク上にある場合でも実質的に同時にメンテナンス情報を取得することが可能となる。
【００４５】
以上、実施の形態１および実施の形態２で一例をあげて説明したように、本願発明は実現される。
【００４６】
なお、本願の実施の形態においては、（２００）、（２０１）の手順および（３００）から（３０３）の一連の手順は、メンテナンス情報の問い合わせの度に行う必要はなく、パソコン１００がＬＡＮ１０３上に接続されている機器にあらかじめメンテナンス情報問い合わせ先を要求して取得して保持しておいてもよい。
【００４７】
また、被メンテナンス装置から回答する情報は、ＵＲＬのみとしたが、ＶＴＲ、冷蔵庫等の機種情報および現在のファームウェア、ソフトウェアのバージョン情報も同時に回答して、それらの情報をＷｅｂサーバに送信して、当該装置に必要なメンテナンス情報のみを回答するとしてもよい。
【００４８】
また、本願実施の形態では、ファームウェアの更新を例としたが、ソフトウェアの更新の場合でも本願発明の範囲から排除するものではない。
【００４９】
また、機器操作方法の情報や新製品等の広告情報等、更新を行わず情報の収集のみ行う場合でも本願発明の範囲から排除するものではない。その場合、メンテナンス情報はメンテナンス手段（パソコン）のディスプレイに表示すればよい。つまり、メンテナンス情報を被メンテナンス装置に配信することは必要に応じて行うものであり、それらを省略する場合でも本願発明の範囲から排除するものではない。
【００５０】
また、被メンテナンス装置が液晶等の表示手段を備える場合は、メンテナンス手段から被メンテナンス装置にメンテナンス情報を配信（転送）して表示させてもよい。
【００５１】
また、本願実施の形態では、被メンテナンス装置が直接インターネットに接続するプロトコルを備えている場合でも以下の点で有効である。インターネットへ接続するポートは、例えば家庭の場合ではＡＤＳＬ回線が一つであり、全ての機器が直接インターネットへ接続できるわけではなく、また、例えば被メンテナンス装置がイーサネット（登録商標）のポートを具備していても、インターネットの接続の形状が電話線の形状である場合は直接接続することは不可能であり、本願実施の形態のように、パソコン等を介して接続することになるので本願発明は有効であり、したがって、そのような場合でも本願発明の範囲から排除するものではない。
【００５２】
また、ＬＡＮ上に同一機種が複数ある場合は、複数回メンテナンス情報を問い合わせる必要がなく、パソコンで一回メンテナンス情報を入手してそれを同一機種に使用することで、インターネット上でのトラフィックを削減可能となり、回線帯域の有効活用が可能となる。
【００５３】
また、本願実施の形態では、被メンテナンス装置の製造事業者が異なることでメンテナンス情報を問い合わせするＷｅｂサーバが異なる場合を例としたが、同一の製造事業者の製品であっても、例えばＶＴＲと冷蔵庫のメンテナンス情報の問い合わせ先が異なる場合は、本願発明が有効であることは言うまでもない。
【００５４】
また、本願実施の形態では、メンテナンス情報の問い合わせ先を特定する情報として、ＷｅｂサイトのＵＲＬを直接、被メンテナンス装置から取得する方法を例としたが、必ずしもこれに限らず、例えば、パソコン１００が製造事業者とメンテナンス情報を関連づけた情報を保持している場合は、被メンテナンス装置から製造事業者名を取得すれば、問い合わせ先を特定することができるので、そのような場合でも本願発明の範囲から排除するものではない。
【００５５】
また、本願実施の形態では、メンテナンス情報問い合わせ先を製造事業者としたが、販売会社等、製造事業者以外がメンテナンス情報を提供する場合でも、それらの問い合わせ先を用いることで本願は実現可能であり、そのような場合でも本願発明の範囲から排除するものではない。
【００５６】
また、本願実施の形態では、複数の被メンテナンス装置のメンテナンス情報を同時に取得する場合を例としたが、必ずしも同時でなくても、スケジュール化して時間分散させてメンテナンス情報を問い合わせたり、取得する場合でも本願発明の範囲から排除するものではない。
【００５７】
また、本願実施の形態では、Ｗｅｂサーバにアクセスするために使用する回線を公衆網（インターネット）の場合を例としたが、一般ユーザの使用例が最も多い場合を例示したものであり、必ずしも公衆網とは限らず、本願発明はネットワーク経由でメンテナンス情報を提供するものにアクセスできればどのような回線でも本願発明の範囲から排除するものではない。つまり、本願発明は被メンテナンス装置とメンテナンス手段を接続するネットワーク（第一のネットワーク）とメンテナンス手段とメンテナンス情報を提供する装置を接続するネットワーク（第二のネットワーク）はどのようなものでもよい。また、第一のネットワークと第二のネットワークが同一のネットワークで構成されてもよい。この場合第一のネットワークと第二のネットワークは論理的にのみ存在することになる。
【００５８】
また、本願実施の形態では、ファームウェアの更新を行う場合を例としたが、仮に現在のファームウェアより新しいバージョンに更新可能であるとしても、例えば新しいバージョンで追加機能がある場合は、その機能が必要であるかどうかを判断して、必要である場合にのみ更新すればよい。その場合、あらかじめ新しいバージョンで追加された機能の情報をメンテナンス手段で取得し、ユーザが更新するか否かをメンテナンス手段で指示することで、更新する場合にのみ、新しいバージョンの実態（更新ファイル）をＷｅｂサーバから取得して更新すればよい。これにより、不必要なネットワークトラフィックを避け、ネットワーク帯域の有効活用が可能となる。
【００５９】
また、本願実施の形態では、被メンテナンス装置が一個あるいは二個の場合を例としたが、三個以上の場合でも、全ての装置へメンテナンス手段から被メンテナンス手段への問い合わせを行い、必要に応じてメンテナンス情報問い合わせ先を増やすことで本願発明は実施可能であることは明らかである。したがって、そのような場合でも本願発明の範囲から排除するものではない。
【００６０】
また、本願実施の形態では、被メンテナンス装置としてネットワーク家電を例としたが、被メンテナンス装置が独自でメンテナンス情報を取得する機能を有さないネットワーク家電以外でも本願発明は有効である。また、被メンテナンス装置が独自でメンテナンス情報を取得する機能を有している場合でも、例えば公衆網に接続する回線が一回線しかない場合など、全ての装置が公衆網に直接接続できない場合は、メンテナンス手段が代理でメンテナンス情報を取得することで、少ない回線数で全ての被メンテナンス装置のメンテナンス情報を取得できるので本願発明が有効である。したがって、そのような場合でも本願発明の範囲から排除するものではない。
【００６１】
また、本願発明はローカルエリアネットワークで使用する通信プロトコルが公衆網に接続する仕組みを備えていない場合にも有効であることは言うまでもない。
【００６２】
また、本願実施の形態の図１において、パソコン１００がインターネット１０６とＬＡＮ１０３への接続のポートをそれぞれ具備する場合を例として図示したが、両者のポートを具備する機器としてはルータ等を用いてもよい。すなわち、メンテナンス手段が公衆網とＬＡＮとの論理的に接続されていることが本願発明の要旨である。したがってそのような場合でも本願発明の範囲から排除するものではない。
【００６３】
【発明の効果】
以上説明したように、本願発明においてはメンテナンス情報取得の仕組みを持たない被メンテナンス装置が、メンテナンス情報取得先情報（問い合わせ先）を開示することにより、メンテナンス手段が代理でメンテナンス情報取得を行い、被メンテナンス装置のメンテナンス情報取得が可能となる。これは、被メンテナンス装置が自身のメンテナンス情報の問い合わせ先を特定する情報を格納することで実現可能となるものである。
【００６４】
また、メンテナンス情報の問い合わせ先が異なる被メンテナンス装置がローカルエリアネットワーク上に存在する場合でも、代理でメンテナンスを行うメンテナンス手段を介して、同時にあるいはスケジュール化して全ての被メンテナンス装置のメンテナンス情報取得を可能とする。
【００６５】
これらの仕組みにより、メンテナンスを必要とする被メンテナンス装置に直接メンテナンス取得プロトコルを実装しなくてよくなるため、被メンテナンス装置の開発を容易にするとともに、安価に構成することが可能となる。
【００６６】
また、個々の被メンテナンス装置が個別に外部ネットワークに接続を行わないため、ローカルエリアネットワークおよび公衆網（インターネット等）共に通信トラフィック量の削減が可能となり、通信帯域を有効に利用可能となる。
【００６７】
また、代理でメンテナンスを行うメンテナンス手段のみを公衆網（インターネット）に接続すればよいため、少ない回線の契約で全ての被メンテナンス装置のメンテナンスが可能となり回線コストの低下が可能となる。
【図面の簡単な説明】
【図１】メンテナンスシステムの模式図
【図２】内蔵ファームウェア更新の通信手順を示す図
【図３】製造事業者の製品の内蔵ファームウェア更新の通信手順を示す図
【符号の説明】
１００  メンテナンス手段（パソコン）
１０１  被メンテナンス装置（ＶＴＲ）
１０２  被メンテナンス装置（冷蔵庫）
１０３  ローカルエリアネットワーク
１０４  メンテナンス情報問い合わせ先
１０５  メンテナンス情報問い合わせ先
１０６  公衆網１０６（インターネット）
【図１】
2004260683.tif 000003
【図２】
2004260683.tif 000004
【図３】
2004260683.tif 000005