JP2008191773A - ネットワーク対応機器及び機能提供方法 - Google Patents

Abstract

【課題】機器やコンポーネントソフトウェアのインタフェース情報が任意に変更されていくような状況においても、機器が提供する機能に係るコンポーネントソフトウェアを適応的に実行できるようにすることを目的とする。
【解決手段】コンポーネントソフトウェアと、コンポーネントソフトウェア制御情報と、を管理し、コンポーネントソフトウェア制御情報に基づいてコンポーネントソフトウェアの実行を制御するコンポーネントソフトウェア管理手段と、コンポーネントソフトウェア管理手段に対してコンポーネントソフトウェア及びコンポーネントソフトウェア制御情報の登録を行うコンポーネントソフトウェア操作手段と、コンポーネントソフトウェア管理手段において管理されているコンポーネントソフトウェアのインタフェース情報を基に、ネットワーク対応機器全体としての機能に関するインタフェース情報を合成するインタフェース合成手段と、を有する。
【選択図】図１

Description

本発明は、ネットワーク対応機器及び機能提供方法に関する。

電子計算機技術の進歩により、従来は単一の機能しか有せず相互に接続することができなかった事務機器や家庭用機器においても、ネットワークを通じた処理の連携を実現するための機能が搭載されるようになった。

このようなネットワークを通じた処理の連携を実現するための技術として、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）がある。ＵＰｎＰは、機器のインタフェース情報の交換と機能の呼び出しとを実現するための技術である。同様の目的や機能を有する別の技術としては、ＪｉｎｉやＪｘｔａ等が存在する。

ＵＰｎＰでは幾つかの機器のタイプに関してはインタフェース情報の標準化がされている。そのため、事前にどのようなタイプの機器の機能を用いるのかが確定できる場合には、前記インタフェース情報に対応した処理を予め実装する形態をとることが可能となる。しかし、機器固有の機能を最大限に生かすため、標準化された仕様を独自に拡張するような場合や、或いは標準仕様そのものが機器開発後に拡張された場合等では、拡張された部分に関するインタフェース情報の取り扱いに関して予め決定しておくことはできない。

以上説明してきたＵＰｎＰは主に家庭用機器で構成されるホームネットワークをターゲットにしたものであるが、次に事務機器で構成される業務用ネットワークにおける同様の技術として、Ｗｅｂ Ｓｅｒｖｉｃｅがある。

Ｗｅｂ Ｓｅｒｖｉｃｅは、企業間の商取引を担う大規模なものから単体の事務用機器にいたるまで様々な規模・種類に対応が可能な柔軟な技術である。そのため、複数のＷｅｂ Ｓｅｒｖｉｃｅ同士を繋ぎ合わせて業務ソリューションやアプリケーションを構築するスタイルが、次世代のソフトウェア開発の主流になると予測されている。

Ｗｅｂ Ｓｅｒｖｉｃｅでは、インタフェース情報はＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）によって定義される。ＷＳＤＬを用いたインタフェース情報は、開発者が独自に定義したデータ構造を用いることができる等、ＵＰｎＰに比較してより複雑な内容を含んだものとなる場合が多い。更にＷｅｂ Ｓｅｒｖｉｃｅでは、一つのＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）メッセージに複数のメッセージスキーマ情報に基づいた情報を混在させることができる。ここで、メッセージスキーマ情報とは、メッセージの構造と記述方法とを示した情報である。

このようにＷｅｂ Ｓｅｒｖｉｃｅではサービスのインタフェース情報であるメッセージスキーマ情報の自由度が高い。そのため、これを処理する機器にはＵＰｎＰよりも更に高度なＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）処理とメッセージング処理とが求められることとなる。

しかもＷｅｂ Ｓｅｒｖｉｃｅにおいては、インタフェース情報の内容そのものに関する標準化はなされておらず、ＵＰｎＰのように機器のタイプに応じて標準的なインタフェース情報が定義されていることを期待することはできない。

更に、対象とする業務ソリューションの成長や拡大に伴って、必要とされるインタフェース情報も随時変更をしていく可能性が高い。

Ｗｅｂ Ｓｅｒｖｉｃｅに対応した機器においては、インタフェース情報が任意に変更されていくような状況でも、必要となるソフトウェアを適応的に実行できることが求められている。これは特に業務ソリューションに対応することを目的とした機器の場合に顕著である。

機器の機能を用いるためのメッセージスキーマ情報とそれを解釈して処理するための機器内部のソフトウェアとの関係が固定的（静的）になっていると、以下のような問題がある。つまり、Ｗｅｂ Ｓｅｒｖｉｃｅのように１つのＳＯＡＰメッセージに複数のメッセージスキーマ情報に基づく情報が混在する環境では、受信したメッセージの内容を全て処理できない可能性がでてくる。

パーソナルコンピュータや大型の計算機では計算機資源の制約が比較的低いため、処理する可能性のある全てのメッセージスキーマ情報に対応したメッセージ処理プログラムを待機させておくといったことも可能である。しかしながら、計算機資源の制約を意識しなければならない組み込み機器ではこのようなことは困難である。そのため、処理実行中において処理対象となったメッセージのメッセージスキーマ情報を基に、対応するメッセージ処理プログラムを動的に選択して実行する仕組みが必要となる。

更に、新しく選択されたメッセージ処理プログラムを有効に使用するには、自分自身が処理可能なメッセージスキーマ情報が変化したことを、機器の機能を用いる相手に通知する必要がある。

このような問題に対応して、機器に格納されるソフトウェアの取捨選択を自動的に実行する技術として、例えば以下のようなものがある。

通常のオペレーティングシステムソフトウェアや一部のアプリケーションソフトウェアが実現しているソフトウェアモジュールの管理を行うために使用している技術があり、ここではダイナミックロードライブラリ技術と呼ぶ。ダイナミックロードライブラリ技術は、機能の異なる複数のライブラリソフトウェアをアプリケーションソフトウェアの要求に応じて動的にロード或いはアンロードすることを可能とする技術である。ライブラリソフトウェアが提供する機能が必要とされない限りライブラリソフトウェアは読み込まれて実行されることはなく、また読み込まれた後も多くの計算機環境においてはメモリイメージを共有できる。

しかしながら、本技術のみでは「どのようなライブラリが必要か」といった判断はアプリケーションソフトウェアが実施しなければならなかった。したがって、複数のメッセージスキーマ情報と複数のメッセージ処理プログラムとを相互に結びつける場合、全てを各々のアプリケーションが判断しなければならない構造となってしまう。

更に、プログラムをコンポーネントソフトウェアとして格納し、管理・実行する技術があり、ここではコンポーネントコンテナ技術と呼称する。本技術はダイナミックロードライブラリ技術を進化させたものであり、システム全体は個別の機能を実現するコンポーネントソフトウェアと、それを複数格納して実行することのできるコンテナソフトウェアと、によって構成される。ユーザからのリクエストはコンテナソフトウェアが受信し、コンテナソフトウェアからの判断によって適切なコンポーネントソフトウェアが実行を開始する。これによればコンポーネントソフトウェアはユーザからのリクエストがなければ実行を開始しなくてもよく、またリクエストが無い場合は停止することも可能なため、適応的なソフトウェアの選択と実行とが可能となっている。

しかしながら、ダイナミックロードライブラリ技術と同様に、本技術はあくまでもソフトウェアの動的な選択に使用可能な環境を提供するだけであり、これのみでメッセージスキーマ情報にあわせたメッセージ処理プログラムの自動処理が実現できるとは言えない。

これらの一般技術は、ソフトウェアの動的な取捨選択を実現するための基本的な処理技術として充分に有用であるが、こうした単独の技術だけでは課題であるメッセージスキーマ情報にあわせたメッセージ処理プログラムの自動処理が実現できるとは言えない。また自機器におけるインタフェース情報の更新も行うことはできない。

更に、特許文献に記載の従来技術としては以下のようなものがある。
まず特許文献１に記載の従来技術は、同一の用途として使用されるデータベースではなくても、スキーマを統合することができるスキーマ統合変換システムを提供する技術である。スキーマ統合変換システムでは、複数の異なったデータスキーマを、予め抽象スキーマグラフと呼んでいるデータから生成するようにすることで統合を図っている。

次に、特許文献２に記載の従来技術は、プログラムの仕様作成時に、プログラムの特殊化要求に応じた仕様の作成と、プログラム作成作業とへの結果の自動的な反映を可能にする技術である。この技術では、プログラムひな型情報と外部データに対するデータ定義の割り当て情報とを基に、プログラム特殊化装置がプログラムひな型情報を特殊化してプログラム仕様として生成する。プログラム開発時においてデータ定義に対応したプログラムを迅速に開発することを目的としている。

更に、特許文献３に記載の従来技術は、実行時にメッセージハンドラのエントリを動的に管理することにより、適切なメッセージハンドラを呼び出すための機構を実現することを目的としている。交換するメッセージ中のオペレーションやデータにワールドワイドでユニックな識別子を付与することにより、適切なメッセージハンドラを探し、存在すればそれを選択する。そして、存在しなければ適切なプログラムモジュールをロード／リンクした上でその中にあるメッセージハンドラを選択し、呼び出す技術である。

特開２００３−１６２５３３号公報 特開平７−１２１３５８号公報 特願平７−２９７９５４号公報

上述した特許文献１の抽象スキーマを用いるアプローチは、Ｗｅｂ Ｓｅｒｖｉｃｅを用いた機器のメッセージ交換においては上述したようにメッセージスキーマ情報の自由度が高く、取り扱うメッセージスキーマ情報が抽象スキーマへと還元できる保証が無い。

また、上述した特許文献２の技術では、プログラム実行時においてデータ定義をキーにプログラムを切り替えることはできない。即ち、実行時におけるメッセージスキーマ情報にあわせたメッセージ処理プログラムの動的な自動処理は実現できない。

また、上述した特許文献３の技術では、メッセージのインスタンスに、それを処理するプログラムを特定可能なＩＤを付与するため、メッセージの発行側と受信側との了解事項としてＩＤ付与を取り扱わなければならない。Ｗｅｂ Ｓｅｒｖｉｃｅを用いた機器のメッセージ交換においては、取り扱うメッセージスキーマ情報において常にこうしたＩＤが付与されていると期待することはできない。また、送受信したメッセージに対してスキーマ処理を行うのではないため、自機器におけるインタフェース情報の更新を行うこともできない。

このように、従来技術はいずれもソフトウェアに関する処理効率性や柔軟なメッセージスキーマの取り扱いといった課題に対しては一定の解決策を提供する。しかしながら、業務ソリューションに対応する場合におけるＷｅｂ Ｓｅｒｖｉｃｅのような、インタフェース情報が随時変更されていくような状況において、必要となるソフトウェアを適応的に実行するという課題に対して十分な解決策を提供していない。

本発明は、機器やコンポーネントソフトウェアのインタフェース情報が任意に変更されていくような状況においても、機器が提供する機能に係るコンポーネントソフトウェアを適応的に実行できるようにすることを目的とする。

そこで、本発明は、ネットワーク対応機器であって、機能を提供し、前記機能に関する要求をコンポーネントソフトウェア外部より受け付ける機構をインタフェース情報として公開するコンポーネントソフトウェアと、前記コンポーネントソフトウェアの制御情報を記述したコンポーネントソフトウェア制御情報と、を管理し、前記コンポーネントソフトウェア制御情報に基づいて前記コンポーネントソフトウェアの実行を制御するコンポーネントソフトウェア管理手段と、前記コンポーネントソフトウェア管理手段に対して前記コンポーネントソフトウェア及び前記コンポーネントソフトウェア制御情報の登録を行うコンポーネントソフトウェア操作手段と、前記コンポーネントソフトウェア管理手段において管理されている前記コンポーネントソフトウェアの前記インタフェース情報を基に、ネットワーク対応機器全体としての機能に関するインタフェース情報を合成するインタフェース合成手段と、を有することを特徴とする。

係る構成とすることにより、例えば、機器の内部を構成しているコンポーネントソフトウェアのインタフェース情報を基に、機器全体のサービスにおけるインタフェース情報を自動生成することができる。また、係る構成とすることにより、例えば、自分自身の処理可能なサービスのインタフェース情報を更新していくことができる。よって、機器やコンポーネントソフトウェアのインタフェース情報が任意に変更されていくような状況においても、機器が提供する機能に係るコンポーネントソフトウェアを適応的に実行できるようにすることができる。

また、本発明は、機能提供方法としてもよい。

本発明によれば、機器やコンポーネントソフトウェアのインタフェース情報が任意に変更されていくような状況においても、機器が提供する機能に係るコンポーネントソフトウェアを適応的に実行できるようにすることができる。

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

図１は、ネットワーク対応機器の処理（機能）の概要の一例を示した図である。なお、図１では本実施形態の処理概要を説明するために構成を簡略化している。本実施形態のソフトウェアを搭載したネットワーク対応機器の詳細な構造に関しては、後述する図２以降においてデジタルカメラ（デジタルカメラ機器）を例に説明を行う。

ネットワーク対応機器３０１は、本実施形態のソフトウェア（又は機能）を搭載した機器であり、ネットワークを経由した通信機能を有する。機器を構成するソフトウェアとしては、まず基本的な処理を提供するオペレーティングシステム・ファームウェア部３１０が搭載されている。その上に構成される本実施形態のソフトウェア構成における特徴部分が、３０２から３０７までである。ネットワーク対応機器３０１の内部的な機能を構成する主要なソフトウェアは、コンポーネントソフトウェア（コンポーネント部）の単位で管理される。コンポーネントソフトウェアの詳細については、後述する図２を用いて説明する。

コンポーネント管理部３０７は、コンポーネントソフトウェアを管理し、コンポーネントソフトウェアのメモリへのロードやアンロード、実行等の処理を行う。図１ではＡコンポーネント部３０２及びＢコンポーネント部３０３の２つのコンポーネントがコンポーネント管理部３０７によって管理されている状態を示しているが、管理対象となるコンポーネントソフトウェアの数は２つ以上でもよいし、１つでもよい。

また、コンポーネント管理部３０７は、コンポーネント制御情報３０６を用いて各コンポーネントソフトウェアの実行を制御する。コンポーネント制御情報３０６に関しては、後述する図３を用いて説明する。

コンポーネント更新部３０５は、コンポーネント管理部３０７において管理の対象となるコンポーネントを、外部のコンポーネントリポジトリ３０９より取得し、コンポーネント管理部３０７に登録する処理を実行する。コンポーネント更新部３０５は、コンポーネント管理部３０７が保持するコンポーネント群の情報を基にコンポーネントリポジトリ３０９に問い合わせを行い、コンポーネントリポジトリ３０９が返送するコンポーネントをコンポーネント管理部３０７に登録する。このことで、新しいコンポーネントを動的にネットワーク対応機器３０１に追加することや、既存のコンポーネントソフトウェアの内容をアップデート（更新）することが可能となる。コンポーネントリポジトリ３０９は、例えば、ネットワーク対応機器３０１と通信可能なサーバ上（サーバのメモリ上）に設けられる。

インタフェース合成部３０４は、搭載されているコンポーネントソフトウェアの機能を反映する形でネットワーク対応機器３０１全体のインタフェースを公開する。インタフェース合成部３０４は、コンポーネント管理部３０７が保持しているコンポーネントソフトウェアの各々のインタフェース情報を基に、ネットワーク対応機器全体としてのインタフェース情報を動的に生成して公開する。インタフェース合成部３０４によって公開されるネットワーク対応機器３０１全体としてのインタフェース情報は、例えば、Ａコンポーネント部３０２が提供するインタフェースとＢコンポーネント部３０３が提供するインタフェースとを反映させたものとなる。

但し、インタフェース合成部３０４は、コンポーネント管理部３０７が管理しているコンポーネントソフトウェアの中でも、特にネットワークにおいて外部に公開可能な機能を提供するコンポーネントソフトウェアのインタフェース情報を用いて合成を行う。従って、例えば、図１においてＡコンポーネント部３０２が提供する機能はネットワークにおいて外部公開が可能な機能であるが、Ｂコンポーネント部３０３が提供する機能は全て内部的に用いられる機能であるとする。すると、インタフェース合成部３０４が合成して発行（又は公開）するインタフェース情報には、Ｂコンポーネント部３０３のインタフェース情報は反映されない。このようにして、インタフェース合成部３０４において生成されたネットワーク対応機器３０１全体のインタフェース情報は、外部機器（他の機器）３０８から利用可能となる。このインタフェース合成部３０４においてどのようにインタフェース情報が合成されるのかは、後述する図５において説明する。なお、外部機器３０８とは、例えば、コンピュータ等である。

次に、図２は、コンポーネントソフトウェアの一例を示す図である。ここで、コンポーネントソフトウェアとは、単独で幾つかの機能を提供することができるソフトウェアのまとまりである。図２では図１におけるＡコンポーネント部３０２と、Ｂコンポーネント部３０３と、をより詳細に示している。

Ａコンポーネント部３０２は、機能Ｆ１と機能Ｆ２とを提供する。各機能はそれぞれインタフェース部によってコンポーネント外部から呼び出すことができる。Ａコンポーネント部３０２においては、機能Ｆ１はインタフェース部（機能Ｆ１インタフェース部）４０４を通じて、コンポーネントソフトウェアの外部より呼び出せるように構成されている。また、機能Ｆ２はインタフェース部（機能Ｆ２インタフェース部）４０５を通じて、コンポーネントソフトウェアの外部より呼び出せるように構成されている。
また、Ａコンポーネント部３０２の内部においては、機能Ｆ１を処理するための処理部（機能Ｆ１処理部）４０１と機能Ｆ２を処理するための処理部（機能Ｆ２処理部）４０２とが存在している。更に、Ａコンポーネント部３０２の内部においては、この両処理部から共通して使用される内部的な機能を提供するための、共通内部処理部４０３も存在している。

Ｂコンポーネント部３０３は、Ａコンポーネント部３０２と異なり、ただ一つの機能である機能Ｆ３を提供する。従って、内部における処理部も機能Ｆ３処理部４１１のみが存在する。
このように、コンポーネントソフトウェアが機能インタフェース部（インタフェース部）において公開する機能は、Ｂコンポーネント部３０３のように１つであってもよいし、Ａコンポーネント部３０２のように複数であってもよい。

本実施形態のコンポーネントソフトウェアは、コンポーネントソフトウェアの外部に公開する機能を必ずインタフェース部によってのみ呼び出し可能となっている。言い換えると、本実施形態のコンポーネントソフトウェアは、提供する機能に関する要求をコンポーネントソフトウェア外部より受け付ける機構をインタフェース情報（又はインタフェース部）として公開している。
そのため、機能Ｆ１処理部４０１、機能Ｆ２処理部４０２、そして共通内部処理部４０３は、このＡコンポーネント部３０２の機能を使用する外部からは隠蔽された存在となる。つまり、実際に機能Ｆ１インタフェース部４０４を使用する他のコンポーネントソフトウェア（つまり外部）からは、４０１、４０２、及び４０３の各処理部の存在は不可視である。逆に言えば、別のコンポーネントソフトウェアが４０１、４０２、４０３といった各処理部を直接呼び出して使用することはできない。これはもちろんＢコンポーネント部３０３においても同様である。コンポーネントソフトウェアの機能は、必ず機能インタフェース部を通じて用いなければならない。これにより、本実施形態においてコンポーネントソフトウェア同士の依存性は単独では存在しない。

また、本実施形態においてはコンポーネントソフトウェアの機能を利用するためのインタフェース部を呼び出すことができるのは、コンポーネント管理部３０７に限られている。各コンポーネントソフトウェアは、内部処理を相互に直接呼び出すことも許されていないし、公開されたインタフェースである機能インタフェース部を直接呼び出すことも許されていない。全てのコンポーネントソフトウェアは、コンポーネント管理部３０７からの制御によってのみ実行することができる。

コンポーネント管理部３０７は、コンポーネント制御情報３０６に記述された内容に基づいて、逐次各コンポーネントが提供している機能インタフェース部を実行していく。

次に、図３は、コンポーネント制御情報とコンポーネントソフトウェアとの関係の一例を示した図である。コンポーネント制御情報３０６は、実際のコンポーネントソフトウェアの実行を制御するための情報として、コンポーネント管理部３０７において管理されている情報である。コンポーネント制御情報３０６は、機器が直面する状況とその状況が生起したときに行う処理とを記述したものとなっており、機器が対応する状況の数だけ状況別にコンポーネント管理部３０７において保持される。

ここで状況とは、ネットワーク対応機器３０１に搭載されているソフトウェアに何かの働きかけがあった時に発生する、ソフトウェアで認識可能な一連の状態を示す。例えば、ネットワーク対応機器３０１の電源投入、電源断、ユーザからの操作（外部操作）、ネットワークからの処理要求、機器内部での状態変更等が本実施形態における状況の例として挙げられる。

図３では、ネットワーク対応機器３０１が状況Ｃ１について直面した場合のコンポーネント制御情報３０６の記述を抜き出して例示している。状況Ｃ１が生起したことをネットワーク対応機器３０１が検出した場合には、図３に示される記述に基づいてコンポーネント管理部３０７が、コンポーネント管理部３０７の管理下にある各コンポーネントを実行する。状況Ｃ１における処理情報としては、機能Ｆ１インタフェース部４０４の実行及び機能Ｆ３インタフェース部４１４の実行が指示されている。従って、ネットワーク対応機器３０１に状況Ｃ１が生起した場合には、コンポーネント管理部３０７によって、Ａコンポーネント部３０２における機能Ｆ１インタフェース部４０４がまず実行される。そして、次に、コンポーネント管理部３０７によって、Ｂコンポーネント部３０３における機能Ｆ３インタフェース部４１４が実行される。

機能Ｆ１インタフェース部４０４の入力情報及び出力情報、機能Ｆ３インタフェース部４１４の入力情報及び出力情報といった各情報は、コンポーネント制御情報３０６における、状況Ｃ１が生起した場合に対応する処理の入出力情報に記載される。ここで、機能Ｆ１インタフェース部４０４の入力情報とは、機能Ｆ１インタフェース部４０４に入力値として指定される情報である。また、機能Ｆ１インタフェース部４０４の出力情報とは、機能Ｆ１インタフェース部４０４が処理結果として出力する情報である。また、機能Ｆ３インタフェース部４１４の入力情報とは、機能Ｆ３インタフェース部４１４に入力値として指定される情報である。また、機能Ｆ３インタフェース部４１４の出力情報とは、機能Ｆ３インタフェース部４１４が処理結果として出力する情報である。

状況Ｃ１の場合に実行されるコンポーネントであるＡコンポーネント部３０２とＢコンポーネント部３０３との間でやりとりされる情報は、このコンポーネント制御情報３０６に基づいて、全てコンポーネント管理部３０７が管理する。

図４は、ネットワーク対応機器３０１がデジタルカメラ機器である場合の内部構成の一例を示した図である。デジタルカメラ機器６００は、Ｗｅｂ Ｓｅｒｖｉｃｅ技術を用いることで、デジタルカメラ機器６００の機能である撮影や画像取得等の処理を、ネットワークを介して制御可能としている。

図４において、６２１から６２４までは、デジタルカメラ機器６００が搭載するハードウェアの特徴的部分を示している。演算制御ハードウェア部６２０は、主に機器の制御に係る演算記憶制御を司る。演算制御ハードウェア部６２０が、ストレージ管理ハードウェア部６２２のハードディスク（又はＲＯＭ）等に格納されているプログラムを実行することによって、上部ソフトウェア群を実現（機能）させる。なお、コンポーネント制御情報６１０等は、ストレージ管理ハードウェア部６２２のＲＡＭ、又はハードディスク、又はＲＯＭ等に予め設定（又は定義）され、格納されている。

画像処理ハードウェア部６２１は、デジタルカメラ機器６００におけるレンズやＣＣＤセンサー等の光学処理を含む撮像処理を実現するハードウェア一式を総称したもので、映像をデジタル化処理することを実現する。ストレージ管理ハードウェア部６２２は、画像処理ハードウェア部６２１等が撮影処理した画像を保持する。ストレージ管理ハードウェア部６２２は、不揮発性のＲＡＭやハードディスク等を駆動するためのハードウェア一式を総称したものである。電源管理ハードウェア部６２３は、全てのハードウェア部に対して電源を供給するための装置を総称したもので、充電式バッテリーや外部入力電源の制御等を行う。ネットワーク処理ハードウェア部６２４は、デジタルカメラ機器６００がネットワークを通じて外部と通信（有線又は無線を介した通信）するための手段を提供する。図４では説明の簡略化のため詳細を省略しているがこれ以外にも各ハードウェア部を相互に結びつけるバスハードウェア部や、演算制御ハードウェア部６２０の演算結果を記憶するための主記憶ハードウェア部等が存在する。

更に図４の６０１から６１２までは、デジタルカメラ機器６００が搭載するソフトウェア（又は情報）の特徴的部分を示している。基本的に図４は上述した図１のネットワーク対応機器３０１の構成をより具体的にしたものであるため、機器の種類に起因する相違に影響されない基本的な部分に関しては、図１における各部にそれぞれ対応したものとなっている。

オペレーティングシステム・ファームウェア部６１２は、図１におけるオペレーティングシステム・ファームウェア部３１０と同じものである。オペレーティングシステム・ファームウェア部６１２は、６２１から６２４までで示される各ハードウェア部を制御する手段を提供するための機能を有している。更にオペレーティングシステム・ファームウェア部６１２上で各コンポーネントソフトウェアの制御を実行するためのコンポーネント管理部６１１も、同様に図１におけるコンポーネント管理部３０７と同じものである。また、コンポーネント制御情報６１０も、図１におけるコンポーネント制御情報３０６と同じである。また、コンポーネント更新部６０９も、図１におけるコンポーネント更新部３０５と同じである。

これらの各処理部は、対象となる機器の種類や製造コスト、或いは要求性能等によって実装上の選択が変化する。例えばオペレーティングシステム・ファームウェア部６１２は、図４で示しているデジタルカメラ機器の場合にはＲＴＯＳ（Ｒｅａｌ Ｔｉｍｅ ＯＳ）系の実装が選択される場合が多い。しかしながら、対象となる機器の種類が複写機等の事務機器の場合、オペレーティングシステム・ファームウェア部６１２は、より高機能な一般ＯＳの組み込み版が採用される場合がある。

更に６０１から６０８までは、デジタルカメラ機器６００がＷｅｂ Ｓｅｒｖｉｃｅで制御可能なデジタルカメラ機器であるために必要となるソフトウェア処理部である。

撮影処理コンポーネント部６０１は、デジタルカメラ機器６００としての基本的な機能である撮影処理を実行する。より具体的に説明すると、撮影処理コンポーネント部６０１は、画像処理ハードウェア部６２１を制御することで撮影処理を実現する。

画像保持コンポーネント部６０２は、撮影処理コンポーネント部６０１が撮影した画像を保持する。より具体的に説明すると、画像保持コンポーネント部６０２は、ストレージ管理ハードウェア部６２２を制御することで画像の保存を実現する。

これらの処理部は各ハードウェア部が提供する機能をソフトウェアから制御するために設けられているものである。しかしながらデジタルカメラ機器６００は、更に、ネットワークを経由して制御が可能となる機能を有するために、ネットワーク処理を行うためのソフトウェア処理部も必要となる。

撮影サービスコンポーネント部６０３は、撮影処理コンポーネント部６０１の機能及び画像保持コンポーネント部６０２の機能をサービスとしてネットワーク上に公開するための機能を提供する。

ＨＴＴＰ処理コンポーネント部６０４は、ＨＴＴＰプロトコルによる情報の送受信機能を提供する。ＷＳＤＬ処理コンポーネント部６０５は、デジタルカメラ機器６００の機能をＷｅｂ Ｓｅｒｖｉｃｅで公開するためのインタフェース情報を記述するためのＷＳＤＬを処理する。

ＳＯＡＰ処理コンポーネント部６０６は、ＳＯＡＰの仕様に基づいて送受信されたＸＭＬメッセージを解釈する処理部である。ＸＭＬ処理コンポーネント部６０７は、ＸＭＬで記述された情報を解析し、各ソフトウェア処理部が処理可能な形態に変換したり、或いは各ソフトウェア処理部が処理した情報をＸＭＬ形式に変換したりする処理を実行する。

ＳＯＡＰ処理コンポーネント部６０６は、ＳＯＡＰの仕様に基づいて送受信されたＸＭＬメッセージを解釈する処理部である。ＸＭＬ処理コンポーネント部６０７は、ＸＭＬで記述された情報を解析し、各ソフトウェア処理部が処理可能な形態に変換したり、或いは各ソフトウェア処理部が処理した情報をＸＭＬ形式に変換したりする処理を実行する。

デジタルカメラ機器６００が、あるＳＯＡＰメッセージを受信した場合には、ＨＴＴＰ処理コンポーネント部６０４が前記ＳＯＡＰメッセージまずＨＴＴＰとして受け取り、これをＸＭＬ処理コンポーネント部６０７が解析する。そして、ＸＭＬ処理コンポーネント部６０７が解析した結果をＳＯＡＰ処理コンポーネント部６０６が処理する流れになる。より具体的な処理は、後述する図５において説明する。

これら６０１から６０７までの各ソフトウェア処理部は、図１におけるＡコンポーネント部３０２或いはＢコンポーネント部３０３に相当するものである。即ち、図１におけるコンポーネント管理部３０７（図４におけるコンポーネント管理部６１１）においてメモリへのロードやアンロード、実行等が行われる対象となる処理部である。またこれらの処理部は、図３において示したようにコンポーネント制御情報３０６（図４におけるコンポーネント制御情報６１０）に具体的な処理の手順が定義されている。

ＷＳＤＬ生成部６０８は、図１におけるインタフェース合成部３０４に対応するものである。デジタルカメラ機器６００は、Ｗｅｂ Ｓｅｒｖｉｃｅを用いた機器であるため、インタフェース情報はＷＳＤＬの仕様に準じて公開される。

次に、図５は、デジタルカメラ機器６００が、ネットワークよりＷｅｂ Ｓｅｒｖｉｃｅに準拠したメッセージを受信して撮影の実行を行う際に発生する内部処理に関して、ソフトウェア各部が果たす処理を示した図である。図５Ａは、処理のフローチャートを示した図である。図５Ｂは、各処理がデジタルカメラ機器６００の内部のどの処理部において実施されたのかを示した図である。

ステップＳ７０１において、コンポーネント管理部６１１は、デジタルカメラ機器６００に搭載されている各コンポーネントソフトウェアのインタフェース情報を処理するインタフェース処理を実行する。より具体的に説明すると、コンポーネント管理部６１１は、デジタルカメラ機器６００に搭載されている各コンポーネント部が提供するインタフェース情報を全て収集し、その中で機器の外部へ公開可能なもののみを選択する。各コンポーネント部とは、６０１、６０２、６０３、６０４、６０５、６０６、６０７の各コンポーネント部である。

本実施形態においては、公開可能なサービスを提供するコンポーネントソフトウェアは撮影サービスコンポーネント部６０３のみである。そのため、コンポーネント管理部６１１は、撮影サービスコンポーネント部６０３が保持するインタフェース情報である画像取得インタフェース部７５４及び撮影実行インタフェース部７５３のみを収集する。ステップＳ７０１の処理は、デジタルカメラ機器６００が機能を外部に公開する処理が実行開始する前に行われる。なお、この処理は、典型的にはデジタルカメラ機器６００への電源が投入されたときや、デジタルカメラ機器６００に対するネットワーク接続状況が変化したとき等に行われる。

ステップＳ７０２において、ＷＳＤＬ生成部６０８は、ステップＳ７０１によって収集されたインタフェース情報を基に、デジタルカメラ機器６００全体のインタフェースとなるＷＳＤＬを生成する処理を行う。より具体的には、ＷＳＤＬ生成部６０８は、画像取得インタフェース部７５４及び撮影実行インタフェース部７５３が提供する情報を基に、前記情報をＷＳＤＬの仕様に即した情報（ＷＳＤＬ情報）に変換する。このＷＳＤＬ情報は、図５ＢにおけるＷＳＤＬ（ＷＳＤＬ情報）７１０に示すように、画像取得インタフェース部７５４及び撮影実行インタフェース部７５３を呼び出すために必要な情報を記載したメッセージスキーマ情報を含んだ情報となる。

ステップＳ７０３において、コンポーネント管理部６１１が、ＨＴＴＰ処理コンポーネント部６０４にステップＳ７０２において作成されたＷＳＤＬ情報を登録することで、ＷＳＤＬ情報を公開する。これにより、ネットワークを通じてデジタルカメラ機器６００の機能をどのように使用することができるのかが記述されたＷＳＤＬ情報が、デジタルカメラ機器６００の外部より取得できる状態となる。

ステップＳ７０４において、外部機器３０８は、ステップＳ７０３において公開されたＷＳＤＬ情報をデジタルカメラ機器６００より取得する。外部機器３０８は、例えば、上述したようにコンピュータである。なお、ＷＳＤＬ情報の取得にはＨＴＴＰが用いられる。ＷＳＤＬ情報を取得した外部機器３０８は、以降はデジタルカメラ機器６００の機能を呼び出すことができるメッセージをどのように生成したらいいのかを知ることができる。

ステップＳ７０５において、外部機器３０８は、デジタルカメラ機器６００に対して撮影を実行するためのメッセージ（撮影実行メッセージ）を送信する。この撮影実行メッセージをデジタルカメラ機器６００のＨＴＴＰ処理コンポーネント部６０４が受信する。

ステップＳ７０６において、ＨＴＴＰ処理コンポーネント部６０４は、撮影実行メッセージを受信すると、コンポーネント管理部６１１に「外部より撮影実行メッセージが到着した」という状況が生起したことを通知する。
ステップＳ７０７において、コンポーネント管理部６１１は、この通知を受けて、この状況に該当（適合）する制御情報をコンポーネント制御情報６１０より取得（又は決定）する。図５Ｂに示すように、コンポーネント管理部６１１は、例えば、
「ＸＭＬ処理コンポーネント部６０７のＸＭＬ解析インタフェース部７２１、ＳＯＡＰ処理コンポーネント部６０６のＳＯＡＰ解析インタフェース部７２２、撮影サービスコンポーネント部６０３の撮影実行インタフェース部７５３、を実行する」
という制御情報を得る。

ステップＳ７０８において、コンポーネント管理部６１１は、ステップＳ７０７において取得（又は決定）した制御情報を基に、逐次各コンポーネントにおける指定された各インタフェース部を呼び出す。コンポーネント管理部６１１は、各コンポーネント処理部が実行した結果を、先ほど得られた制御情報に蓄積していく。

ＸＭＬ処理コンポーネント部６０７のＸＭＬ解析インタフェース部７２１が呼び出されることで、ＸＭＬ処理コンポーネント部６０７は、ステップＳ７０５において外部機器３０８より送信された撮影実行メッセージをＸＭＬ情報として解析する。次に、ＳＯＡＰ処理コンポーネント部６０６のＳＯＡＰ解析インタフェース部７２２が呼び出されることで、ＳＯＡＰ処理コンポーネント部６０６は、ＸＭＬの内容がＳＯＡＰの仕様に準拠したものとみなし、撮影パラメータとして解釈する。最後に撮影サービスコンポーネント部６０３の撮影実行インタフェース部７５３が呼び出されることで、撮影サービスコンポーネント部６０３は、前記撮影パラメータに基づいて、撮影（撮影処理）を実行する。
図５には図示していないが、更に内部的には撮影サービスコンポーネント部６０３から撮影処理コンポーネント部６０１へと処理が発生し、ここからオペレーティングシステム・ファームウェア部６１２を経由して画像処理ハードウェア部６２１が駆動される。

ステップＳ７０９において、コンポーネント管理部６１１は、処理の結果をＨＴＴＰ処理コンポーネント部６０４に転送する。続いて、ステップＳ７１０において、ＨＴＴＰ処理コンポーネント部６０４は、撮影処理の実行結果としての情報を外部機器３０８に返信（送信）する。

このように、デジタルカメラ機器６００は、外部機器３０８に自分自身の機能である撮影実行インタフェースを公開する。外部機器３０８は、公開された撮影実行インタフェースを用いることでデジタルカメラ機器６００に対して撮影を行わせることができる。

図６は、デジタルカメラ機器６００が、ネットワークよりＷｅｂ Ｓｅｒｖｉｃｅに準拠したメッセージを受信して画像の圧縮を行う際に発生する内部処理に関して、ソフトウェア各部が果たす処理を示したものである。但し、図５に示した画像の撮影実行処理とは異なり、この段階でのデジタルカメラ機器６００に画像の圧縮機能を有するコンポーネントソフトウェア部は存在していないものとする。図６Ａは、処理のフローチャート示した図である。図６Ｂは、各処理がデジタルカメラ機器６００の内部のどの処理部において実施されたのかを示した図である。

ステップＳ８０１において、外部機器３０８より画像圧縮処理を要求するメッセージがデジタルカメラ機器６００に対して発行（送信）される。この段階ではデジタルカメラ機器６００には、図５に示されるように画像の圧縮処理機能を有するコンポーネントソフトウェア部は搭載されていないものとする。従って、デジタルカメラ機器６００が公開するＷＳＤＬは、図５に示されるＷＳＤＬ７１０のままであり、画像圧縮メッセージスキーマ情報が存在しているわけではない。よって、図５におけるステップＳ７０４のＷＳＤＬ取得処理は、図６においては存在しない。画像圧縮処理を要求するメッセージは、図５と同様に、デジタルカメラ機器６００におけるＨＴＴＰ処理コンポーネント部６０４において受信される。

ステップＳ８０２において、ＨＴＴＰ処理コンポーネント部６０４は、画像圧縮処理を要求するメッセージを受信すると、コンポーネント管理部６１１に「外部より画像圧縮処理を要求するメッセージが到着した」という状況が生起したことを通知する。
ステップＳ８０３において、コンポーネント管理部６１１は、この通知を受けて、この状況に該当する制御情報をコンポーネント制御情報６１０より取得（又は決定）しようとする。このとき、コンポーネント管理部６１１は、自分自身が公開しているインタフェース情報に定義されていないメッセージスキーマ情報であることを検出し、「外部より新規メッセージが到着した」という状況が生起したと判断する。そして、コンポーネント管理部６１１は、この状況に該当する制御情報をコンポーネント制御情報６１０より取得（又は決定）する。この結果、コンポーネント管理部６１１は、図６Ｂに示すように、本状況に該当する処理の記述として「コンポーネント更新部を実行」を得る。

ステップＳ８０４において、コンポーネント管理部６１１は、前記処理の記述に基づいてコンポーネント更新部６０９に画像圧縮処理に係るコンポーネントソフトウェアの更新を要求する。

ステップＳ８０５において、この要求を受信したコンポーネント更新部６０９は、ネットワーク上に存在するコンポーネントリポジトリ３０９に対して画像圧縮処理に係るコンポーネントソフトウェアの要求を発行する。上述したように、コンポーネントリポジトリ３０９は、例えば、サーバ上に設けられている。コンポーネントリポジトリ３０９は、前記発行された画像圧縮処理に係るコンポーネントソフトウェアの要求（要求情報）を基に、内部に保存されているコンポーネントソフトウェアとコンポーネントソフトウェアに対応する制御情報とを検索する。

そして、ステップＳ８０６において、コンポーネントリポジトリ３０９は、該当する画像圧縮処理に係るコンポーネントソフトウェアと制御情報とをコンポーネント更新部６０９に返信する。なお、ステップＳ８０６では、図６Ｂに示されるように、圧縮サービスコンポーネント部８２０とこの圧縮サービスコンポーネント部８２０制御するための制御情報である新規制御情報８２２とが返信されるものとする。

ステップＳ８０７において、コンポーネント更新部６０９は、受信した圧縮サービスコンポーネント部８２０と新規制御情報８２２とをコンポーネント管理部６１１に登録する。この登録によって、圧縮サービスコンポーネント部８２０の使用が可能な状態となる。

ステップＳ８０８において、コンポーネント管理部６１１は、新たに登録された新規制御情報８２２を参照する。新規制御情報８２２によれば、圧縮サービスコンポーネント部８２０の圧縮処理インタフェース部８２１を実行することが指示されている。よって、コンポーネント管理部６１１は、こうして得られた新規制御情報８２２を基に、圧縮処理インタフェース部８２１を呼び出す。圧縮サービスコンポーネント部８２０は、指定された処理である画像圧縮処理を実行し、実行結果をコンポーネント管理部６１１に返す。コンポーネント管理部６１１は、圧縮サービスコンポーネント部８２０が実行した実行結果を、新規制御情報８２２に蓄積（記述）する。

また、ステップＳ８０９において、コンポーネント管理部６１１は、画像圧縮処理の処理結果をＨＴＴＰ処理コンポーネント部６０４に転送する。ステップＳ８１０において、ＨＴＴＰ処理コンポーネント部６０４は、画像圧縮処理の処理結果を外部機器３０８に返信する。

ステップＳ８１１において、コンポーネント管理部６１１は、ステップＳ８０７で登録された圧縮サービスコンポーネント部８２０に対して、インタフェース処理を行う。この処理は、図５におけるステップＳ７０１の処理と同じである。

ステップＳ８１２において、ＷＳＤＬ生成部６０８は、ステップＳ８１１で収集されたインタフェース情報を基に、ＷＳＤＬを生成する処理を行う。この処理は、図５におけるステップＳ７０２の処理と同じである。即ち、ＷＳＤＬ生成部６０８は、ステップＳ８１１で収集されたインタフェース情報を基に、デジタルカメラ機器６００全体のインタフェースとなるＷＳＤＬを生成するためのＷＳＤＬ生成を行う。

より具体的には、ＷＳＤＬ生成部６０８は、画像取得インタフェース部７５４、撮影実行インタフェース部７５３、圧縮処理インタフェース部８２１、が提供する情報を基に、これらの情報をＷＳＤＬの仕様に即した情報に変換する。このＷＳＤＬは図６ＢのＷＳＤＬ８３０に示したように、合計３つのインタフェース部を呼び出すために必要な情報を記載したメッセージスキーマ情報を含んだものとなる。即ち、図５ＢのＷＳＤＬ７１０と比較して「３．圧縮処理メッセージスキーマ」が追加された情報となる。

ステップＳ８１３において、コンポーネント管理部６１１が、ＨＴＴＰ処理コンポーネント部６０４にステップＳ８１２において作成されたＷＳＤＬ（ＷＳＤＬ情報）を登録することで、ＷＳＤＬ情報を公開する。この処理は、図５におけるステップＳ７０３の処理と同じである。これにより、ネットワークを通じてデジタルカメラ機器６００の機能をどのように使用することができるのかが記述されたＷＳＤＬ情報が、デジタルカメラ機器６００の外部より取得できる状態となる。

このようにデジタルカメラ機器６００は、ネットワークよりＷｅｂ Ｓｅｒｖｉｃｅに準拠した画像圧縮処理を要求するメッセージに対して、動的に外部より対応するコンポーネントを取得し、これを実行することで要求された処理を実行する。また、デジタルカメラ機器６００は、前記コンポーネント（新規コンポーネント）が提供する機能に基づいて自分自身のインタフェース情報を更新する。図６Ｃは、更新されたデジタルカメラ機器６００の内部構成の一例を示した図である。図６Ｃには、図４に示した段階では存在しなかった圧縮サービスコンポーネント部８２０が、コンポーネント管理部６１１が管理する対象として追加されている。

このように、デジタルカメラ機器６００は、通信処理に必要となるソフトウェアを効率的に実行すると共に、サービスのインタフェース情報が任意に変更されていくような状況においても、使用するソフトウェアを適応的に実行することできる。即ち、デジタルカメラ機器６００は、随時変化する個別のインタフェース情報に柔軟に対応できるメッセージスキーマ処理機能を有している。デジタルカメラ機器６００は、デジタルカメラ機器６００の内部を構成しているコンポーネントソフトウェアのインタフェース情報を基に、デジタルカメラ機器６００全体のサービス（又は機能）のインタフェース情報を自動生成することができる。このことにより、自分自身の処理可能なサービスのインタフェース情報を更新していくことが可能となっている。

従来であれば機器をネットワーク化する際には、予め設計開発時時において対応するサービスのインタフェース情報を決定し、どのようなメッセージスキーマ処理を行うかを事前に決定しておかなければならなかった。しかしながら、デジタルカメラ機器６００では設計開発後の市場等においても変更することができる。このため、デジタルカメラ機器６００は、未知の形式を含むメッセージスキーマ処理が必要とされる状況に柔軟に対応することができる。

なお、本実施形態は複数の機器（例えばホストコンピュータ、インタフェース機器等）から構成される装置に適用しても、一つの機器からなる装置に適用してもよい。

以上、上述したように本実施形態によれば、機器やコンポーネントソフトウェアのインタフェース情報が任意に変更されていくような状況においても、機器が提供する機能に係るコンポーネントソフトウェアを適応的に実行できるようにすることができる。

（その他の実施形態）
また、本発明の目的は、以下のようにすることによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（又は記憶媒体）を、システム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する。この場合、記録媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。

また、コンピュータが読み出したプログラムコードを実行することにより、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）等が実際の処理の一部又は全部を行う。その処理によって上述した実施形態の機能が実現される場合も含まれる。

更に、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれたとする。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって上述した実施形態の機能が実現される場合も含まれる。

本発明を前記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャート（の全て又は一部）に対応するプログラムコードが格納されることになる。

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

ネットワーク対応機器の処理（機能）の概要の一例を示した図である。 コンポーネントソフトウェアの一例を示す図である。 コンポーネント制御情報とコンポーネントソフトウェアとの関係の一例を示した図である。 ネットワーク対応機器３０１がデジタルカメラ機器である場合の内部構成の一例を示した図である。 デジタルカメラ機器６００が、ネットワークよりＷｅｂ Ｓｅｒｖｉｃｅに準拠したメッセージを受信して撮影の実行を行う際に発生する内部処理のフローチャートを示した図である。 デジタルカメラ機器６００が、ネットワークよりＷｅｂ Ｓｅｒｖｉｃｅに準拠したメッセージを受信して撮影の実行を行う際に発生する各処理が機器６００の内部のどの処理部において実施されたのかを示した図である。 デジタルカメラ機器６００が、ネットワークよりＷｅｂ Ｓｅｒｖｉｃｅに準拠したメッセージを受信して画像の圧縮を行う際に発生する内部処理のフローチャート示した図である。 デジタルカメラ機器６００が、ネットワークよりＷｅｂ Ｓｅｒｖｉｃｅに準拠したメッセージを受信して画像の圧縮を行う際に発生する各処理が機器６００の内部のどの処理部において実施されたのかを示した図である。 更新されたデジタルカメラ機器６００の内部構成の一例を示した図である。

符号の説明

３０１ ネットワーク対応機器
３０２ Ａコンポーネント部
３０３ Ｂコンポーネント部
３０４ インタフェース合成部
３０５ コンポーネント更新部
３０６ コンポーネント制御情報
３０７ コンポーネント管理部
３０８ 外部機器（サービスリクエスタ）
３０９ コンポーネントリポジトリ
６００ デジタルカメラ機器
６０１ 撮影処理コンポーネント部
６０２ 画像保持コンポーネント部
６０３ 撮影サービスコンポーネント部
６０４ ＨＴＴＰ処理コンポーネント部
６０５ ＷＳＤＬ処理コンポーネント部
６０６ ＳＯＡＰ処理コンポーネント部
６０７ ＸＭＬ処理コンポーネント部
６０８ ＷＳＤＬ生成部
６０９ コンポーネント更新部
６１０ コンポーネント制御情報
６１１ コンポーネント管理部
６１２ オペレーティングシステム・ファームウェア部
６２０ 演算制御ハードウェア部
６２１ 画像処理ハードウェア部
６２２ ストレージ管理ハードウェア部
６２３ 電源管理ハードウェア部
６２４ ネットワーク処理ハードウェア部
８２０ 圧縮サービスコンポーネント部

Claims (7)

1. ネットワーク対応機器であって、
   機能を提供し、前記機能に関する要求をコンポーネントソフトウェア外部より受け付ける機構をインタフェース情報として公開するコンポーネントソフトウェアと、前記コンポーネントソフトウェアの制御情報を記述したコンポーネントソフトウェア制御情報と、を管理し、前記コンポーネントソフトウェア制御情報に基づいて前記コンポーネントソフトウェアの実行を制御するコンポーネントソフトウェア管理手段と、
   前記コンポーネントソフトウェア管理手段に対して前記コンポーネントソフトウェア及び前記コンポーネントソフトウェア制御情報の登録を行うコンポーネントソフトウェア操作手段と、
   前記コンポーネントソフトウェア管理手段において管理されている前記コンポーネントソフトウェアの前記インタフェース情報を基に、ネットワーク対応機器全体としての機能に関するインタフェース情報を合成するインタフェース合成手段と、
   を有することを特徴とするネットワーク対応機器。
2. 前記コンポーネントソフトウェア管理手段は、複数の前記コンポーネントソフトウェアを管理し、
   前記コンポーネント制御情報は、前記コンポーネントソフトウェアが提供するインタフェース情報を、各々どのように呼び出していけばよいかを状況別に示した情報であることを特徴とする請求項１に記載のネットワーク対応機器。
3. 前記コンポーネントソフトウェア管理手段は、前記インタフェース合成手段によって合成されたネットワーク機器全体の機能に関するインタフェース情報へ外部より要求が発行された場合、前記要求に関する状況に適合する前記コンポーネント制御情報を選択し、選択した前記コンポーネント制御情報に基づいて、前記コンポーネントソフトウェアが提供するインタフェース情報を呼び出し、前記コンポーネントソフトウェアの実行を制御することを特徴とする請求項２に記載のネットワーク対応機器。
4. 前記コンポーネントソフトウェア管理手段は、ネットワーク対応機器の内部処理又は外部操作に応じてネットワーク対応機器の状況が変化した場合、前記変化した状況に適合する前記コンポーネント制御情報を選択し、選択した前記コンポーネント制御情報に基づいて、前記コンポーネントソフトウェアが提供するインタフェース情報を呼び出し、前記コンポーネントソフトウェアの実行を制御することを特徴とする請求項２に記載のネットワーク対応機器。
5. 前記コンポーネントソフトウェア管理手段が管理しているコンポーネントソフトウェアでは提供できない機能に関する要求が外部機器よりなされた場合、前記コンポーネントソフトウェア操作手段は、前記機能を提供することができるコンポーネントソフトウェア及びコンポーネントソフトウェア制御情報を前記コンポーネントソフトウェア管理手段に新たに登録することを特徴とする請求項１乃至４の何れか１項に記載のネットワーク対応機器。
6. 前記コンポーネントソフトウェア操作手段が、前記機能を提供することができるコンポーネントソフトウェア及びコンポーネントソフトウェア制御情報を前記コンポーネントソフトウェア管理手段に登録した場合、前記インタフェース合成手段は、前記新たに登録されたコンポーネントソフトウェア及びコンポーネントソフトウェア制御情報を用いて、前記機能に関するインタフェース情報を合成することを特徴とする請求項５に記載のネットワーク対応機器。
7. ネットワーク対応機器における機能提供方法であって、
   コンポーネントソフトウェア管理手段が、機能を提供し、前記機能に関する要求をコンポーネントソフトウェア外部より受け付ける機構をインタフェース情報として公開するコンポーネントソフトウェアと、前記コンポーネントソフトウェアの制御情報を記述したコンポーネントソフトウェア制御情報と、を管理し、前記コンポーネントソフトウェア制御情報に基づいて前記コンポーネントソフトウェアの実行を制御するコンポーネントソフトウェア管理ステップと、
   前記コンポーネントソフトウェア管理手段に対して前記コンポーネントソフトウェア及び前記コンポーネントソフトウェア制御情報の登録を行うコンポーネントソフトウェア操作ステップと、
   前記コンポーネントソフトウェア管理手段において管理されている前記コンポーネントソフトウェアの前記インタフェース情報を基に、ネットワーク対応機器全体としての機能に関するインタフェース情報を合成するインタフェース合成ステップと、
   を含むことを特徴とする機能提供方法。

Images