JP5019867B2 - サーバ装置、ネットワーク装置、データ提供場所提供方法、データ提供場所提供プログラム及び記録媒体 - Google Patents

Description

本発明は、サーバ装置、ネットワーク装置、データ提供場所提供方法、データ提供場所提供プログラム及び記録媒体に係り、特にクライアント装置がデータ格納場所からデータに関連する情報を取得するシステムにおけるサーバ装置、ネットワーク装置、データ提供場所提供方法、データ提供場所提供プログラム及び記録媒体に関する。

近年、Ｗｅｂサイトの更新情報を公開する方法としてＲＳＳ（Rich Site Summary）が使われるようになった。ＲＳＳとは、Ｗｅｂサイトの見出しや要約などのメタデータを構造化して記述する形式のＸＭＬ（Extensible Markup Language）ベースのフォーマットである。

ＲＳＳで記述された更新情報には、Ｗｅｂサイトの各ページのタイトル，アドレス，見出し，要約，更新時刻等を記述することができる。ＲＳＳで記述された更新情報を利用することにより、更新情報の受信側では多数のＷｅｂサイトの更新情報を統一的な方法で効率的に把握できる。

また、従来の複合機には、通信履歴等の機器管理情報をＲＳＳで提供する機能を有するものがあった（例えば、特許文献１参照）。特許文献１では、クライアント装置となるコンピュータ上で動作するＲＳＳリーダが、複数の複合機のＲＳＳフィードを定期的にポーリングすることで、複数の複合機の機器管理情報を一括管理する例が開示されている。

なお、ＲＳＳフィードとはＲＳＳソースを提供するＵＲＬのことである。ＲＳＳソースとはＲＳＳ形式のフォーマットに従った情報のことである。
特開２００６−５４７３２号公報

しかしながら、特許文献１では利用者がＲＳＳリーダに複数の複合機のＲＳＳフィードを登録する必要がある。したがって、利用者は各複合機が提供するＲＳＳフィードのＵＲＬを、それぞれ調べる必要があり、複合機の台数が多くなると非常に手間が掛かるという問題があった。

また、ＩＴマネージャ等のネットワーク装置や複合機の管理者が、大量のネットワーク装置や複合機を管理する場合において、管理者は管理対象のネットワーク装置や複合機のＲＳＳフィードのＵＲＬを１台ずつ調べてＲＳＳリーダに登録しなければならず、非常に手間が掛かるという問題があった。

本発明は、上記の点に鑑みなされたもので、ネットワーク装置から提供されるデータに関連する情報のデータ格納場所を正確且つ容易に登録可能なサーバ装置、ネットワーク装置、データ提供場所提供方法、データ提供場所提供プログラム及び記録媒体を提供することを目的とする。

上記課題を解決するため、本発明は、提供するデータに関連する情報を、構造化して記述する形式のフォーマットに従って装置外部に提供する１台以上のネットワーク装置の、前記データに関連する情報のデータ格納場所をクライアント装置に提供するサーバ装置であって、前記サーバ装置は、アプリの機能を実現する第１のソフトウェア層と、ハードウェアを制御して前記アプリに機能を提供する第２のソフトウェア層とを含み構成され、前記データに関連する情報のデータ格納場所を１台以上の前記ネットワーク装置から前記第２のソフトウェア層を介して取得するデータ格納場所取得手段と、前記ネットワーク装置から取得した前記データに関連する情報のデータ格納場所を管理するデータ格納場所管理手段と、前記ネットワーク装置の前記データに関連する情報のデータ格納場所を前記クライアント装置に前記第２のソフトウェア層を介して提供するデータ格納場所提供手段とを有することを特徴とする。

また、本発明は、提供するデータに関連する情報を、構造化して記述する形式のフォーマットに従って装置外部に提供するネットワーク装置であって、前記ネットワーク装置は、装置操作を行う為のユーザインターフェース層と、アプリの機能を実現するアプリ層と、ハードウェアを制御して前記アプリに機能を提供するサービス層とを含み構成され、前記サービス層を介して前記データに関連する情報のデータ格納場所をクライアント装置に提供するサーバ装置を特定する特定手段と、特定した前記サーバ装置に、前記サービス層を介して前記データに関連する情報のデータ格納場所を提供する提供手段とを有することを特徴とする。

なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。

本発明によれば、ネットワーク装置から提供されるデータに関連する情報のデータ格納場所を正確且つ容易に登録可能なサーバ装置、ネットワーク装置、データ提供場所提供方法、データ提供場所提供プログラム及び記録媒体を提供可能である。

次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。なお、本実施例では、機器管理情報をＲＳＳフィードによって提供することができる複合機等のネットワーク装置が複数あり、ネットワーク装置の管理者であるＩＴマネージャがクライアント装置のＲＳＳリーダに、それぞれのネットワーク装置が提供するＲＳＳフィードのＵＲＬを登録する例を説明する。つまり、本実施例では、複数のネットワーク装置が提供するＲＳＳフィードのＵＲＬをクライアント装置のＲＳＳリーダに登録し易くする技術について説明する。

図１は本発明によるシステムの一実施例の構成図である。図１のシステムは、１つ以上のネットワーク装置１，サーバ装置２及びＰＣ（クライアント装置）３が、ＬＡＮ４経由で接続されている。なお、ＰＣ３はＩＴマネージャが利用するものである。ＰＣ３はＷＥＢブラウザやＲＳＳリーダ等がインストールされており、利用可能となっている。ＬＡＮ４は一例であって、ＷＡＮやインターネット等であってもよい。

図２は、ネットワーク装置のハードウェア構成を示す一実施例の構成図である。ネットワーク装置１は、プロセッサ１０１，ワークメモリ１０２，フラッシュＲＯＭなどの記憶装置１０３，装置特有のハードウェア１０４，入出力回路１０５を有する。

プロセッサ１０１は、自装置の制御等を行う。プロセッサ１０１はネットワーク装置１に特有の機能を、装置特有のハードウェア１０４を組み合わせて実行する。また、プロセッサ１０１は、ネットワーク装置１においてＷｅｂサーバ機能を実行するためにも使用される。

ワークメモリ１０２はソフトウェアの実行や、それに伴う作業の為の一時記憶領域として用いられる。記憶装置１０３は電気的に書き換えが可能なフラッシュＲＯＭなどの記憶媒体であって、ネットワーク装置１の機能を実現するための制御プログラムや本発明によるプログラム等のソフトウェアを記憶している。装置特有のハードウェア１０４はネットワーク装置１に特有のハードウェアである。入出力回路１０５は、ＬＡＮ４との接続の為に用いられる。

図３は、ネットワーク装置のソフトウェア構成を示す一実施例の構成図である。図３のネットワーク装置１は、ソフトウェア２０及びハードウェア２１で構成されている。

ソフトウェア２０はユーザーインターフェース層，アプリ層及びサービス層によって構成されている。ユーザーインターフェース層は利用者に対してユーザーインターフェースを提供する。アプリ層は各アプリ機能を実現する。サービス層はハードウェア２１を制御して、各アプリにそれぞれの機能を提供する。

ユーザーインターフェース層は、機器ユーザーインターフェース（ＵＩ）２０１及びＷｅｂＵＩ２０２を有する。機器ＵＩ２０１は、ネットワーク装置１が有する操作パネルにユーザーインターフェースを提供する。ＷｅｂＵＩ２０２はネットワーク装置１の利用者がＰＣ１等からＷｅｂブラウザを用いてネットワーク装置１の操作を行う為のユーザーインターフェースを提供する。

アプリ層は、コピーアプリ２１１，ファックスアプリ２１２，プリンタアプリ２１３及びスキャナアプリ２１４を有する。コピーアプリ２１１はコピー機能を実現する為のものである。ファックスアプリ２１２はファックス機能を実現する為のものである。プリンタアプリ２１３はプリンタ機能を実現する為のものである。また、スキャナアプリ２１４はスキャナ機能を実現する為のものである。

サービス層は、印刷サービス２２１，読み取りサービス２２２，ネットワークサービス２２３及びメモリサービス２２４を有する。印刷サービス２２１はハードウェア２１に含まれるプロッタ装置を制御する。読み取りサービス２２２はハードウェア２１に含まれる原稿読み取り装置を制御する。ネットワークサービス２２３は入出力回路１０５を制御する。メモリサービス２２４はワークメモリ１０２を管理する。

例えば利用者がネットワーク装置１の操作パネルを使って原稿をコピーしようとする場合は、最初に機器ＵＩ２０１が利用者からの指示を受け付ける。次に、機器ＵＩ２０１はコピーアプリ２１１にコピー動作の内容を指示する。コピーアプリ２１１は、機器ＵＩ２０１からのコピー動作の指示に従って、読み取りサービス２２２と印刷サービス２２１とに対して原稿の読み取りと印刷とを指示する。こうして、利用者は原稿のコピー出力結果を得ることができる。

図４はＷｅｂＵＩの構成を示す一実施例の構成図である。図４のＷｅｂＵＩ２０２はＷｅｂ画面提供部３０１，ＲＳＳフィード提供部３０２，ＯＰＭＬファイル提供部３０３を有する。

Ｗｅｂ画面提供部３０１はネットワークサービス２２３を通じて、利用者が操作しているＰＣ３上で動作しているＷｅｂブラウザからの要求を受信する。Ｗｅｂ画面提供部３０１は受信した要求に基づき、機器管理情報が記載されたＷｅｂページをＰＣ３に送信して利用者に提供する機能を有する。

ここで、機器管理情報とは、例えば機器状態，省エネ状態，エラー発生状態，トナー残量，給紙トレイ状態，ジョブ履歴情報などの各種情報のことを指す。これら各種の機器管理情報は、全ての情報を一つのＷｅｂページによって提供してもよいが、通常、その種別に応じて複数のＷｅｂページに分けて提供することが多い。例えば、Ｗｅｂページは機器の総合的な状態を示すトップページとして機器状態，省エネ状態，エラー発生状態を表示するＷｅｂページ、プリンタのジョブの履歴を示すページとしてジョブ履歴情報を表示するＷｅｂページなどに分けられる。

ＲＳＳフィード提供部３０２はネットワークサービス２２３を通じて、利用者が操作しているＰＣ３上で動作しているＲＳＳリーダからの要求を受信する。ＲＳＳフィード提供部３０２は受信した要求に基づき、機器管理情報が記述されたＲＳＳフィードをＰＣ３に送信し、利用者に提供する機能を有する。

ＲＳＳフィードに記述される情報には、具体的に、機器管理情報の概要と、機器管理情報の詳細を確認することができるＷｅｂページへのリンク情報が含まれる。利用者が使用しているＲＳＳリーダで通常表示される情報は機器管理情報の概要である。その機器管理情報の詳細を確認したいと思った利用者は、ＲＳＳリーダで表示される機器管理情報の詳細を確認することができるＷｅｂページへのリンクをたどり、Ｗｅｂブラウザや、あるいはＲＳＳリーダに内蔵のＷｅｂブラウザ機能を用いて、Ｗｅｂ画面提供部３０１が提供するＷｅｂページを表示させ、機器管理情報の詳細を確認することができる。

ＲＳＳフィードとして提供する各種情報は、前述したＷｅｂページと同様に、全ての情報を一つのＲＳＳフィードによって提供してもよい。しかし、異なる種別の情報が混在するＲＳＳフィードは利用者にとって扱いにくい。また、通常のＲＳＳリーダでは、複数のＲＳＳフィードの内容をリミックスして表示させる機能を持つことから、利用者側で必要に応じた利用方法ができるように、その種別に応じて別のＲＳＳフィードとして提供することが好ましい。

また、ＯＰＭＬファイル提供部３０３は、ネットワークサービス２２３を通じて、ＲＳＳフィード提供部３０２が提供する全てのＲＳＳフィードのリストをひとまとめにしたＯＰＭＬファイルを提供する機能を有する。ここで、ＯＰＭＬファイルを提供するＵＲＬのことをＯＰＭＬフィード、ＯＰＭＬファイルの中身のことをＯＰＭＬソースと呼ぶ。

図５は、サーバ装置のハードウェア構成を示す一実施例の構成図である。サーバ装置２は、プロセッサ４０１，ワークメモリ４０２，ハードディスクドライブ（ＨＤＤ）などの記憶装置４０３，装置特有のハードウェア４０４，入出力回路４０５を有する。

プロセッサ４０１は、自装置の制御等を行う。プロセッサ４０１はサーバ装置２に特有の機能を、装置特有のハードウェア４０４を組み合わせて実行する。また、プロセッサ４０１は、サーバ装置２においてＷｅｂサーバ機能を実行するためにも使用される。

ワークメモリ４０２は記憶装置４０３から読み出されたソフトウェアの実行や、それに伴う作業の為の一時記憶領域として用いられる。記憶装置４０３は、書き換えが可能なＨＤＤ等の記憶媒体であって、サーバ装置２の機能を実現するための制御プログラムや本発明によるプログラム等のソフトウェアを記憶している。装置特有のハードウェア４０４はサーバ装置２に特有のハードウェアである。入出力回路４０５は、ＬＡＮ４との接続の為に用いられる。

図６は、サーバ装置のソフトウェア構成を示す一実施例の構成図である。図６のサーバ装置２は、ソフトウェア５０及びハードウェア５１で構成されている。

ソフトウェア５０はアプリ層及びサービス層によって構成されている。アプリ層は各アプリ機能を実現する。サービス層はハードウェア５１を制御して、各アプリにそれぞれの機能を提供する。

アプリ層は、ＤＨＣＰアプリ５０１，ＲＳＳアプリ５０２及びＳＭＴＰアプリ５０３を有する。ＤＨＣＰアプリ５０１はＤＨＣＰ機能を実現する為のものである。ＲＳＳアプリ５０２はＲＳＳ機能を実現する為のものである。ＳＭＴＰアプリ５０３はメール受信機能を実現する為のものである。

サービス層はネットワークサービス５１１及びメモリサービス５１２を有する。ネットワークサービス５１１は入出力回路４０５を制御する。メモリサービス５１２はワークメモリ４０２を管理する。

図７はＲＳＳアプリの構成を示す一実施例の構成図である。図７のＲＳＳアプリ５０２はＲＳＳフィード提供部６０２，ＯＰＭＬファイル提供部６０３，外部ＲＳＳフィード取得部６０４，外部ＲＳＳフィード管理部６０５，外部ＯＰＭＬファイル取得部６０６を有する。

ＲＳＳフィード提供部６０２はネットワークサービス５１１を通じて、利用者が操作しているＰＣ３上で動作しているＲＳＳリーダからの要求を受信する。ＲＳＳフィード提供部６０２は受信した要求に基づき、機器管理情報が記述されたＲＳＳフィードをＰＣ３に送信し、利用者に提供する機能を有する。

ＲＳＳフィードに記述される情報には、具体的に、機器管理情報の概要と、機器管理情報の詳細を確認することができるＷｅｂページへのリンク情報が含まれる。利用者が使用しているＲＳＳリーダで通常表示される情報は機器管理情報の概要である。その機器管理情報の詳細を確認したいと思った利用者は、ＲＳＳリーダで表示される機器管理情報の詳細を確認することができるＷｅｂページへのリンクをたどり、Ｗｅｂブラウザや、あるいはＲＳＳリーダに内蔵のＷｅｂブラウザ機能を用いて、ネットワーク装置１のＷｅｂ画面提供部３０１が提供するＷｅｂページを表示させ、機器管理情報の詳細を確認することができる。

ＲＳＳフィードとして提供する各種情報は、前述したＷｅｂページと同様に、全ての情報を一つのＲＳＳフィードによって提供してもよい。しかし、異なる種別の情報が混在するＲＳＳフィードは利用者にとって扱いにくい。また、通常のＲＳＳリーダでは、複数のＲＳＳフィードの内容をリミックスして表示させる機能を持つことから、利用者側で必要に応じた利用方法ができるように、その種別に応じて別のＲＳＳフィードとして提供することが好ましい。

また、ＯＰＭＬファイル提供部６０３は、ネットワークサービス５１１を通じて、ＲＳＳフィード提供部６０２が提供する全てのＲＳＳフィードのリストをひとまとめにしたＯＰＭＬファイルを提供する機能を有する。ここで、ＯＰＭＬファイルを提供するＵＲＬのことをＯＰＭＬフィード、ＯＰＭＬファイルの中身のことをＯＰＭＬソースと呼ぶ。

また、外部ＲＳＳフィード取得部６０４は、ネットワークサービス５１１を通じて、ＬＡＮ４上のネットワーク装置１から、機器管理情報が記述されたＲＳＳフィードを取得する機能を有する。

また、外部ＲＳＳフィード管理部６０５は、外部ＲＳＳフィード取得部６０４が取得したＲＳＳフィードを保持し、ＲＳＳフィード提供部６０２に対して、そのＲＳＳフィードを提供する機能を有する。

さらに、外部ＯＰＭＬ取得部６０６はネットワークサービス５１１を通じて、ＬＡＮ４上のネットワーク装置１から、そのネットワーク装置１が提供する全てのＲＳＳフィードのリストをひとまとめにしたＯＰＭＬファイルを取得する機能を有する。外部ＯＰＭＬ取得部６０６は、そのＯＰＭＬファイルに記述されたＲＳＳフィードの情報を、外部ＲＳＳフィード取得部６０４に対して提供する機能も有する。

本発明は、ＬＡＮ４に接続されている管理対象のネットワーク装置１が、自身のＲＳＳフィードを自動的にサーバ装置２へ登録するものである。つまり、ネットワーク装置１のＲＳＳフィードはサーバ装置２に集まる。ＩＴマネージャはサーバ装置２にアクセスすることにより、複数のネットワーク装置１のＲＳＳフィードを登録することができる。

また、通常のネットワーク装置１に必要なプロトコルのサーバ機能をサーバ装置２に持たせることで、管理対象のネットワーク装置１は特別な機能を設けることなく、サーバ装置２を以下のように特定できる。

（サーバ装置２の特定）
図８はネットワーク装置がサーバ装置にＲＳＳフィードを通知する処理を表した一例のフローチャートである。図８のフローチャートは、ネットワーク装置１の起動時、自身のＲＳＳフィードの通知先として登録されているサーバ装置２のアドレス（登録サーバアドレス）の登録・変更時、又は前回の通知から一定時間経過後に開始される。

ステップＳ１に進み、ネットワーク装置１のネットワークサービス２２３は記憶装置１０３から登録サーバアドレスを読み出す。ステップＳ２に進み、ネットワークサービス２２３は入出力回路１０５からＬＡＮ４を通して、登録サーバアドレスに対応するサーバ装置２へ自身のＲＳＳフィードを通知する。このように、ネットワーク装置１は予め登録されている登録サーバアドレスに基づきサーバ装置２を特定する。

図９はネットワーク装置がサーバ装置にＲＳＳフィードを通知する処理を表した他の例のフローチャートである。ここでは、サーバ装置２がＤＨＣＰサーバであるとする。図９のフローチャートは、ネットワーク装置１の起動時又は前回ＤＨＣＰサーバであるサーバ装置２から割り振られたＩＰアドレスのリース期間の半分が経過した後に開始される。

ステップＳ１１に進み、ネットワーク装置１のネットワークサービス２２３は入出力回路１０５からＬＡＮ４を通して、サーバ装置２にＩＰアドレスの割り振りを依頼する。ステップＳ１２に進み、ネットワークサービス２２３はＬＡＮ４を通してサーバ装置２からＩＰアドレスの割り振り結果を受信し、その受信からサーバ装置２のＩＰアドレスを取得する。ステップＳ１３に進み、ネットワークサービス２２３はステップＳ１２で取得したサーバ装置２のＩＰアドレスを登録サーバアドレスとして記憶装置１０３に記憶する。

ステップＳ１４に進み、ネットワーク装置１のネットワークサービス２２３は記憶装置１０３から登録サーバアドレスを読み出す。ステップＳ１５に進み、ネットワークサービス２２３は入出力回路１０５からＬＡＮ４を通して、登録サーバアドレスに対応しているサーバ装置２へ自身のＲＳＳフィードを通知する。このように、ネットワーク装置１はＤＨＣＰプロトコルによってＩＰアドレスを割り振ったＤＨＣＰサーバをサーバ装置２として特定する。

図１０はネットワーク装置がサーバ装置にＲＳＳフィードを通知する処理を表した他の例のフローチャートである。図１０のフローチャートはネットワーク装置１の起動時、登録サーバアドレスの登録・変更時、又は前回の通知から一定時間経過後に開始される。

ステップＳ２１に進み、ネットワーク装置１のネットワークサービス２２３は記憶装置１０３から自身のＲＳＳフィードの通知先として登録されているサーバ装置２の名称（登録サーバ名称）を読み出す。

ステップＳ２２に進み、ネットワークサービス２２３は、入出力回路１０５からＬＡＮ４を通して、ＤＮＳサーバに名前解決を依頼する。ステップＳ２３に進み、ネットワークサービス２２３はＬＡＮ４を通してＤＮＳサーバから名前解決の結果を受信し、その名前解決の結果からサーバ装置２のＩＰアドレスを取得する。

ステップＳ２４に進み、ネットワーク装置１のネットワークサービス２２３はステップＳ２３で取得したＩＰアドレスに対応しているサーバ装置２へ、入出力回路１０５からＬＡＮ４を通して、自身のＲＳＳフィードを通知する。このように、ネットワーク装置１は予め登録されている登録サーバ名称（サーバ装置２の固有名称）に基づき、ＤＮＳサーバに問い合わせることで名前解決をし、サーバ装置２を特定する。

（ネットワーク装置１からサーバ装置２へのＲＳＳフィードの送信）
図１１は、ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した一例のシーケンス図である。なお、ネットワーク装置１は、ＲＳＳフィードを応答するため、Ｗｅｂサービスが起動されている。

サーバ装置２は、ネットワーク装置１をみつけたタイミング（ＡＲＰ要求やＤＨＣＰによるＩＰアドレスの割り当て要求を受け取ったとき）で、図１１のシーケンス図に示す動作を開始する。

ステップＳ３１に進み、サーバ装置２はＳＯＡＰリクエスト（SOAP REQUEST）としてネットワーク装置１のＲＳＳフィードを取得する為のメソッド（getRSSUrl()）を送信する。ステップＳ３２に進み、ネットワーク装置１はレスポンスとしてＳＯＡＰレスポンス（SOAP RESPONSE）を返答する。このＳＯＡＰレスポンスにはネットワーク装置１のＲＳＳフィードが含まれている。

図１２はネットワーク装置とサーバ装置との間で通信するＳＯＡＰ情報の一例の構成図である。図１２のＳＯＡＰ情報はプロトコルヘッダ及びＳＯＡＰエンベロープから構成されている。また、ＳＯＡＰエンベロープは、ＳＯＡＰヘッダ及びＳＯＡＰメッセージから構成されている。ＲＳＳフィードを取得する為のメソッド（getRSSUrl()）は、ＳＯＡＰメッセージのメッセージ本体に含まれる。

このように、ネットワーク装置１からサーバ装置２へのＲＳＳフィードの送信にはＳＯＡＰ Ｉ／Ｆによる通信手順を利用できる。

図１３は、ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した他の例のシーケンス図である。なお、ネットワーク装置１は、ＲＳＳフィードを応答するため、ＲＥＳＴ Ｉ／Ｆ解析モジュールが起動されている。

サーバ装置２は、ネットワーク装置１をみつけたタイミング（ＡＲＰ要求やＤＨＣＰによるＩＰアドレスの割り当て要求を受け取ったとき）で、図１３のシーケンス図に示す動作を開始する。図１３では、ＲＥＳＴ Ｉ／Ｆアーキテクチャにおいて代表的な実装であるＨＴＴＰによる方法を示している。ここでは、情報であるＲＳＳフィードを取得する目的で使用されているため、ＨＴＴＰ ＧＥＴによる方法を示す。

ステップＳ４１に進み、サーバ装置２はＨＴＴＰ ＧＥＴを送信する。ステップＳ４２に進み、ネットワーク装置１はＨＴＴＰ ＧＥＴに対するレスポンスとしてネットワーク装置１のＲＳＳフィードを返答する。図１４はネットワーク装置とサーバ装置との間で通信するＲＥＳＴ情報の一例の構成図である。図１４のＲＥＳＴ情報はＲＳＳフィード「ｈｔｔｐ：／／１６９．９６．２２８．８８／ｒｓｓｕｒｌ．ｈｔｍｌ」が含まれた例を表している。

このように、ネットワーク装置１からサーバ装置２へのＲＳＳフィードの送信にはＲＥＳＴ Ｉ／Ｆによる通信手順を利用できる。

図１５は、ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した他の例のシーケンス図である。図１５のシーケンス図に表した処理は、図８のステップＳ２や図９のステップＳ１５で利用される。なお、サーバ装置２には、ＲＳＳフィードを受信する為にＳＭＴＰサーバが起動されている。

ステップＳ５１に進み、ネットワーク装置１はＳＭＴＰでサーバ装置２へ自身のＲＳＳフィードを送信する。図１６はネットワーク装置とサーバ装置との間で通信するメール情報の一例の構成図である。図１６のメール情報は、ＲＳＳフィード「ｈｔｔｐ：／／１６９．９６．２２８．８８／ｒｓｓｕｒｌ．ｈｔｍｌ」がメールの本文の中に含まれた例を表している。

このように、ネットワーク装置１からサーバ装置２へのＲＳＳフィードの送信にはＳＭＴＰによるメールの本文を利用できる。

図１７は、ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した他の例のシーケンス図である。図１７のシーケンス図に表した処理は、図８のステップＳ２や図９のステップＳ１５で利用される。なお、サーバ装置２には、ＲＳＳフィードを受信する為にＳＭＴＰサーバが起動されている。

ステップＳ６１に進み、ネットワーク装置１はＳＭＴＰでサーバ装置２へ自身のＲＳＳフィードを送信する。図１８はネットワーク装置とサーバ装置との間で通信するメール情報の一例の構成図である。図１８のメール情報は、ＲＳＳフィード「ｈｔｔｐ：／／１６９．９６．２２８．８８／ｒｓｓｕｒｌ．ｈｔｍｌ」がメールのタイトル（Subject）の中に記載された例を表している。

このように、ネットワーク装置１からサーバ装置２へのＲＳＳフィードの送信にはＳＭＴＰによるメールのタイトルを利用できる。

図１９は、ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した一例のシーケンス図である。なお、サーバ装置２はネットワーク装置１からのＡＲＰ要求を監視している。

例えばネットワーク装置１はＬＡＮ４に接続されたタイミングで、図１９のシーケンス図に示す動作を開始する。ステップＳ７１に進み、ネットワーク装置１はブロードキャストでＡＲＰ要求を送信する。ステップＳ７２に進み、ＡＲＰ要求を監視していたサーバ装置２はＡＲＰ要求元のネットワーク装置１へＡＲＰ応答する。

ステップＳ７３に進み、サーバ装置２はＡＲＰ要求元のネットワーク装置１に対してＲＳＳフィードの問い合わせを行う。ＲＳＳフィードの問い合わせ方法としては、前述したＳＯＡＰ Ｉ／Ｆ，ＲＥＳＴ Ｉ／Ｆなどを利用できる。ステップＳ７４に進み、ネットワーク装置１はレスポンスとしてＲＳＳフィードをサーバ装置２に返答する。

図１９のシーケンス図によれば、サーバ装置２が、ＡＲＰ要求のあったネットワーク装置１に対してＡＲＰ応答を行ったあと、ＡＲＰ要求元にＲＳＳフィードを問い合わせて取得することで、ＬＡＮ４に接続されたネットワーク装置１のＲＳＳフィードを自動的に取得できる。

（管理テーブルの更新）
サーバ装置２は、管理対象のネットワーク装置１のＲＳＳフィードを管理テーブルにより管理している。サーバ装置２は、管理テーブルを以下のように更新している。図２０はサーバ装置におけるタイマー処理を表した一例のフローチャートである。

図２０のフローチャートは例えばＩＴマネージャがタイマー入力画面を選択した後に開始される。ステップＳ１００に進み、サーバ装置２はタイマー待ち画面を表示する。タイマー入力は図５の装置特有のハードウェアを利用して行われる。

ステップＳ１０１に進み、サーバ装置２はタイマー値の入力があったか否かをチェックする。なお、ステップＳ１０１の処理はタイマー値の入力があるまで繰り返される。タイマー値の入力があると、サーバ装置２はステップＳ１０２に進み、タイマー値をセットする。ステップＳ１０３に進み、サーバ装置２はタイマーをスタートする。

サーバ装置２はセットしたタイマー値となると、図２１に示すフローチャートの処理を開始する。図２１は管理テーブル更新処理を表した一例のフローチャートである。

ステップＳ１１０に進み、サーバ装置２はネットワーク装置１を識別する為のＮを０とする。ステップＳ１１１に進み、サーバ装置２はＮに対応するネットワーク装置１にＲＳＳをサポートしているか問い合わせる。

Ｎに対応するネットワーク装置１がＲＳＳをサポートしていなければ、サーバ装置２はステップＳ１１２に進み、管理対象のネットワーク装置１のＲＳＳフィードを管理している管理テーブルからＮに対応するネットワーク装置１を削除する。そして、サーバ装置２はステップＳ１１３に進む。また、Ｎに対応するネットワーク装置１がＲＳＳをサポートしていれば、サーバ装置２はステップＳ１１３に進む。

ステップＳ１１３に進み、サーバ装置２は、他にもネットワーク装置１があるかを判定する。他にもネットワーク装置１があると判定すれば、サーバ装置２はステップＳ１１４に進み、Ｎに１を加算したあと、ステップＳ１１１に戻る。一方、他にネットワーク装置１がないと判定すれば、サーバ装置２はステップＳ１１５に進み、タイマーをリスタートさせる。

図２２はネットワーク装置における通知用タイマー処理を表した一例のフローチャートである。なお、通知用タイマーの入力は図２０のフローチャートに示すように行う。

ネットワーク装置１は通知用タイマーのタイムアウトと判定するまで、ステップＳ１２０の処理を繰り返す。通知用タイマーのタイムアウトと判定すると、ネットワーク装置１はステップＳ１２１に進み、サーバ装置２へＲＳＳフィードを通知する。ステップＳ１２２に進み、ネットワーク装置１は通知用タイマーをリスタートしたあと、ステップＳ１２０に戻る。図２２に示した通知用タイマー処理によれば、ネットワーク装置１は通知用タイマーのタイムアウト毎に、サーバ装置２へＲＳＳフィードを通知できる。

図２３は管理テーブル更新処理を表した一例のフローチャートである。ステップＳ１３０に進み、サーバ装置２はＲＳＳフィードの通知がネットワーク装置１からあるかを判定する。ネットワーク装置１からＲＳＳフィードの通知があれば、サーバ装置２はステップＳ１３１に進み、ＲＳＳフィードの通知があったＮに対応するネットワーク装置１のタイマーをリスタートしたあと、ステップＳ１３０に戻る。

一方、ネットワーク装置１からＲＳＳフィードの通知がなければ、サーバ装置２はステップＳ１３２に進み、ネットワーク装置１を識別する為のＮを０とする。ステップＳ１３３に進み、サーバ装置２はＮに対応するネットワーク装置１の有効期限確認タイマーがタイムアウトしたか判定する。

Ｎに対応するネットワーク装置１の有効期限確認タイマーがタイムアウトしたと判定すると、サーバ装置２はステップＳ１３４に進み、Ｎに対応するネットワーク装置１を管理テーブルから削除する。そして、サーバ装置２はステップＳ１３５に進む。また、Ｎに対応するネットワーク装置１の有効期限確認タイマーがタイムアウトしていないと判定すると、サーバ装置２はステップＳ１３５に進む。

ステップＳ１３５に進み、サーバ装置２は、他にもネットワーク装置１があるかを判定する。他にもネットワーク装置１があると判定すれば、サーバ装置２はステップＳ１３６に進み、Ｎに１を加算したあと、ステップＳ１３３に戻る。一方、他にネットワーク装置１がないと判定すれば、サーバ装置２はステップＳ１３０に戻る。

例えば、通知用タイマーを１０分、有効期限確認タイマーを６０分とすると、ステップＳ１３３における有効期限確認タイマーのタイムアウトはネットワーク装置１が動作している限り起きず、ネットワーク装置１の管理されている状態を続けることができる。

（ＯＰＭＬ形式によるＲＳＳフィードの保存）
サーバ装置２は、管理対象のネットワーク装置１のＲＳＳフィードをＯＰＭＬ形式で保存することもできる。図２４はＲＳＳフィードをＯＰＭＬ形式で保存する処理を表した一例のフローチャートである。

ステップＳ１４０に進み、サーバ装置２はネットワーク装置１を識別する為のＮを０とする。ステップＳ１４１に進み、サーバ装置２はＮに対応するネットワーク装置１のＲＳＳフィードを獲得する。ステップＳ１４２に進み、サーバ装置２は獲得したネットワーク装置１のＲＳＳフィードをＯＰＭＬ形式で追加保存する。

ステップＳ１４３に進み、サーバ装置２は、他にもネットワーク装置１があるかを判定する。他にもネットワーク装置１があると判定すれば、サーバ装置２はステップＳ１４４に進み、Ｎに１を加算したあと、ステップＳ１４１に戻る。他にネットワーク装置１がないと判定すれば、サーバ装置２は図２４のフローチャートに示す処理を終了する。

図２５は複数のネットワーク装置から獲得して記憶したＲＳＳフィードを含んだＯＰＭＬソースの一例である。図２５のＯＰＭＬソースは、機器状態、トナー残量、給紙トレイ状態、通信履歴の４種類のＲＳＳフィードをサポートした例を表している。

（ＲＳＳソースの保存）
サーバ装置２は、管理対象のネットワーク装置１のＲＳＳフィードからＲＳＳソースを獲得し、一つのＲＳＳソースとして保存することもできる。図２６はＲＳＳソースを保存する処理を表した一例のフローチャートである。

ステップＳ１５０に進み、サーバ装置２はネットワーク装置１を識別する為のＮを０とする。ステップＳ１５１に進み、サーバ装置２はＮに対応するネットワーク装置１のＲＳＳソースを獲得する。ステップＳ１５２に進み、サーバ装置２は獲得したネットワーク装置１のＲＳＳソースをＲＳＳ形式で追加保存する。

ステップＳ１５３に進み、サーバ装置２は、他にもネットワーク装置１があるかを判定する。他にもネットワーク装置１があると判定すれば、サーバ装置２はステップＳ１５４に進み、Ｎに１を加算したあと、ステップＳ１５１に戻る。他にネットワーク装置１がないと判定すれば、サーバ装置２は図２６のフローチャートに示す処理を終了する。図２７は複数のネットワーク装置から獲得したＲＳＳソースをマージしたＲＳＳソースの一例である。

（サーバ装置２によるＲＳＳフィードの提供）
なお、サーバ装置２も何らかの情報（例えば社内報など）をＲＳＳフィードによって提供できる。また、サーバ装置２は外部の一般サーバにおいて提供されているＲＳＳソースを取り込んで提供することもできる。

図２８はサーバ装置が提供するＲＳＳフィードをＲＳＳリーダで購読した場合の画面例である。図２８の画面例では、サーバ装置２が提供する社内報，複数のネットワーク装置１が提供する機器管理情報，外部の一般サーバが提供する経済ニュース及びＩＴニュースが表示されている。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

本発明によるシステムの一実施例の構成図である。 ネットワーク装置のハードウェア構成を示す一実施例の構成図である。 ネットワーク装置のソフトウェア構成を示す一実施例の構成図である。 ＷｅｂＵＩの構成を示す一実施例の構成図である。 サーバ装置のハードウェア構成を示す一実施例の構成図である。 サーバ装置のソフトウェア構成を示す一実施例の構成図である。 ＲＳＳアプリの構成を示す一実施例の構成図である。 ネットワーク装置がサーバ装置にＲＳＳフィードを通知する処理を表した一例のフローチャートである。 ネットワーク装置がサーバ装置にＲＳＳフィードを通知する処理を表した他の例のフローチャートである。 ネットワーク装置がサーバ装置にＲＳＳフィードを通知する処理を表した他の例のフローチャートである。 ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した一例のシーケンス図である。 ネットワーク装置とサーバ装置との間で通信するＳＯＡＰ情報の一例の構成図である。 ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した他の例のシーケンス図である。 ネットワーク装置とサーバ装置との間で通信するＲＥＳＴ情報の一例の構成図である。 ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した他の例のシーケンス図である。 ネットワーク装置とサーバ装置との間で通信するメール情報の一例の構成図である。 ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した他の例のシーケンス図である。 ネットワーク装置とサーバ装置との間で通信するメール情報の一例の構成図である。 ネットワーク装置からサーバ装置へのＲＳＳフィードを送信する処理を表した一例のシーケンス図である。 サーバ装置におけるタイマー処理を表した一例のフローチャートである。 管理テーブル更新処理を表した一例のフローチャートである。 ネットワーク装置における通知用タイマー処理を表した一例のフローチャートである。 管理テーブル更新処理を表した一例のフローチャートである。 ＲＳＳフィードをＯＰＭＬ形式で保存する処理を表した一例のフローチャートである。 複数のネットワーク装置から獲得して記憶したＲＳＳフィードを含んだＯＰＭＬソースの一例である。 ＲＳＳソースを保存する処理を表した一例のフローチャートである。 複数のネットワーク装置から獲得したＲＳＳソースをマージしたＲＳＳソースの一例である。 サーバ装置が提供するＲＳＳフィードをＲＳＳリーダで購読した場合の画面例である。

符号の説明

１ ネットワーク装置
２ サーバ装置
３ ＰＣ（クライアント装置）
４ ＬＡＮ
２０，５０ ソフトウェア
２１，５１ ハードウェア
１０１ プロセッサ
１０２ ワークメモリ
１０３ 記憶装置
１０４ 装置特有のハードウェア
１０５ 入出力回路
２０１ 機器ユーザーインターフェース（ＵＩ）
２０２ ＷｅｂＵＩ
２１１ コピーアプリ
２１２ ファックスアプリ
２１３ プリンタアプリ
２１４ スキャナアプリ
２２１ 印刷サービス
２２２ 読み取りサービス
２２３，５１１ ネットワークサービス
２２４，５１２ メモリサービス
３０１ Ｗｅｂ画面提供部
３０２，６０２ ＲＳＳフィード提供部
３０３，６０３ ＯＰＭＬファイル提供部
４０１ プロセッサ
４０２ ワークメモリ
４０３ 記憶装置
４０４ 装置特有のハードウェア
４０５ 入出力回路
５０１ ＤＨＣＰアプリ
５０２ ＲＳＳアプリ
５０３ ＳＭＴＰアプリ
６０４ 外部ＲＳＳフィード取得部
６０５ 外部ＲＳＳフィード管理部
６０６ 外部ＯＰＭＬファイル取得部

Claims (15)

1. 提供するデータに関連する情報を、構造化して記述する形式のフォーマットに従って装置外部に提供する１台以上のネットワーク装置の、前記データに関連する情報のデータ格納場所をクライアント装置に提供するサーバ装置であって、
   前記サーバ装置は、アプリの機能を実現する第１のソフトウェア層と、ハードウェアを制御して前記アプリに機能を提供する第２のソフトウェア層とを含み構成され、
   前記データに関連する情報のデータ格納場所を１台以上の前記ネットワーク装置から前記第２のソフトウェア層を介して取得するデータ格納場所取得手段と、
   前記ネットワーク装置から取得した前記データに関連する情報のデータ格納場所を管理するデータ格納場所管理手段と、
   前記ネットワーク装置の前記データに関連する情報のデータ格納場所を前記クライアント装置に前記第２のソフトウェア層を介して提供するデータ格納場所提供手段と
   を有することを特徴とするサーバ装置。
2. 管理対象の前記ネットワーク装置を管理する管理テーブル手段と、
   所定期間毎に前記ネットワーク装置へ前記フォーマットをサポートしているかを確認して前記フォーマットをサポートしていない前記ネットワーク装置を前記管理テーブル手段から削除する削除手段と
   を有することを特徴とする請求項１記載のサーバ装置。
3. 管理対象の前記ネットワーク装置を管理する管理テーブル手段と、
   管理対象の前記ネットワーク装置から前記データに関連する情報のデータ格納場所が所定期間の間、通知されていなければ前記ネットワーク装置を前記管理テーブル手段から削除する削除手段と
   を有することを特徴とする請求項１記載のサーバ装置。
4. 前記データ格納場所取得手段は、ＡＲＰ（アドレス解決プロトコル）要求に対して応答したあと、前記ＡＲＰ要求元から前記データに関連する情報のデータ格納場所を取得することを特徴とする請求項１記載のサーバ装置。
5. 提供するデータに関連する情報を、構造化して記述する形式のフォーマットに従って装置外部に提供するネットワーク装置であって、
   前記ネットワーク装置は、装置操作を行う為のユーザインターフェース層と、アプリの機能を実現するアプリ層と、ハードウェアを制御して前記アプリに機能を提供するサービス層とを含み構成され、
   前記サービス層を介して前記データに関連する情報のデータ格納場所をクライアント装置に提供するサーバ装置を特定する特定手段と、
   特定した前記サーバ装置に、前記サービス層を介して前記データに関連する情報のデータ格納場所を提供する提供手段と
   を有することを特徴とするネットワーク装置。
6. 前記特定手段は、予め登録されているアドレスに基づいて前記サーバ装置を特定することを特徴とする請求項５記載のネットワーク装置。
7. 前記特定手段は、アドレスの割り振りを行う装置を前記サーバ装置として特定することを特徴とする請求項５記載のネットワーク装置。
8. 前記特定手段は、予め登録されている前記サーバ装置の固有名称に基づいて前記サーバ装置を特定することを特徴とする請求項５記載のネットワーク装置。
9. 前記提供手段は、ＳＯＡＰインターフェースを利用して前記サーバ装置に前記データに関連する情報のデータ格納場所を提供することを特徴とする請求項５記載のネットワーク装置。
10. 前記提供手段は、ＲＥＳＴインターフェースを利用して前記サーバ装置に前記データに関連する情報のデータ格納場所を提供することを特徴とする請求項５記載のネットワーク装置。
11. 前記提供手段は、メールの本文に前記データに関連する情報のデータ格納場所を記載して前記サーバ装置に前記データに関連する情報のデータ格納場所を提供することを特徴とする請求項５記載のネットワーク装置。
12. 前記提供手段は、メールのタイトルに前記データに関連する情報のデータ格納場所を記載して前記サーバ装置に前記データに関連する情報のデータ格納場所を提供することを特徴とする請求項５記載のネットワーク装置。
13. 提供するデータに関連する情報を、構造化して記述する形式のフォーマットに従って装置外部に提供する１台以上のネットワーク装置の、前記データに関連する情報のデータ格納場所をクライアント装置に提供するサーバ装置のデータ提供場所提供方法であって、
    前記ネットワーク装置は、装置操作を行う為のユーザインターフェース層と、アプリの機能を実現するアプリ層と、ハードウェアを制御して前記アプリに機能を提供するサービス層とを含み構成され、
    前記サーバ装置は、アプリの機能を実現する第１のソフトウェア層と、ハードウェアを制御して前記アプリに機能を提供する第２のソフトウェア層とを含み構成され、
    前記データに関連する情報のデータ格納場所を１台以上の前記ネットワーク装置から前記第２のソフトウェア層を介して取得するデータ格納場所取得ステップと、
    前記ネットワーク装置から取得した前記データに関連する情報のデータ格納場所を管理するデータ格納場所管理ステップと、
    前記第２のソフトウェア層を介して前記ネットワーク装置の前記データに関連する情報のデータ格納場所を前記クライアント装置に提供するデータ格納場所提供ステップと
    を有することを特徴とするデータ提供場所提供方法。
14. 装置操作を行う為のユーザインターフェース層と、アプリの機能を実現するアプリ層と、ハードウェアを制御して前記アプリに機能を提供するサービス層とを含み構成され、提供するデータに関連する情報を、構造化して記述する形式のフォーマットに従って装置外部に提供する１台以上のネットワーク装置の、前記データに関連する情報のデータ格納場所をクライアント装置に提供するアプリの機能を実現する第１のソフトウェア層と、ハードウェアを制御して前記アプリに機能を提供する第２のソフトウェア層とを含み構成されるサーバ装置に、
    前記データに関連する情報のデータ格納場所を１台以上の前記ネットワーク装置から前記第２のソフトウェア層を介して取得するデータ格納場所取得ステップと、
    前記ネットワーク装置から取得した前記データに関連する情報のデータ格納場所を管理するデータ格納場所管理ステップと、
    前記ネットワーク装置の前記データに関連する情報のデータ格納場所を前記クライアント装置に前記第２のソフトウェア層を介して提供するデータ格納場所提供ステップと
    を実行させるためのデータ提供場所提供プログラム。
15. 請求項１４記載のデータ提供場所提供プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images