(57)【要約】【課題】ネットワーク上の多様なサービスの最新情報を常時取得すること。【解決手段】  サービス利用装置１００に対して、ネットワーク上の複数のサービス提供装置１０１、１０２、１０３からのサービスを提供する。複数のサービス提供装置１０１、１０２、１０３の機能をマークアップ言語によって記述した同期用データを生成し、登録する。いずれかのサービス提供装置において機能の変更があった場合に、登録された同期用データを更新する。サービス利用装置１００は、登録され、随時更新された同期用データを取得して、サービスリストを生成し、表示する。【選択図】  図１
2008152397.tif 000002
【特許請求の範囲】
【請求項１】
サービス利用装置に対して、ネットワーク上の複数のサービス提供装置からのサービスを提供する情報処理方法において、
複数のサービス提供装置の機能をマークアップ言語によって記述した閲覧用データを生成する生成ステップと、
前記閲覧用データを登録する登録ステップと、
いずれかのサービス提供装置において機能の変更があった場合に、登録された前記閲覧用データを随時更新する更新ステップと、
サービス利用装置が、登録され随時更新された前記閲覧用データを取得して、サービスリストを生成し、表示するサービスリスト表示ステップと、
を含むことを特徴とする情報処理方法。
【請求項２】
前記閲覧用データは、ＸＭＬによって記述されることを特徴とする請求項１に記載の情報処理方法。
【請求項３】
前記閲覧用データは、ＲＳＳまたはＡｔｏｍの形式で記述されることを特徴とする請求項２に記載の情報処理方法。
【請求項４】
前記生成ステップは、
前記複数のサービス提供装置のそれぞれが自身の機能をマークアップ言語によって記述した閲覧用データを生成するステップと、
前記複数のサービス提供装置が生成した複数の閲覧用データを組み合わせるステップとを含むことを特徴とする請求項１に記載の情報処理方法。
【請求項５】
サービス利用装置に対して、ネットワーク上の複数のサービス提供装置からのサービスを提供する情報処理システムにおいて、
複数のサービス提供装置の機能をマークアップ言語によって記述した閲覧用データを生成する生成手段と、
前記閲覧用データを登録する登録手段と、
いずれかのサービス提供装置において機能の変更があった場合に、登録された前記閲覧用データを更新する更新手段と、
サービス利用装置が、登録された前記閲覧用データを取得して、サービスリストを生成し、表示するサービスリスト表示手段と、
を含むことを特徴とする情報処理システム。
【請求項６】
サービス利用装置に対して、ネットワーク上の複数のサービス提供装置からのサービスを提供する情報処理プログラムにおいて、
複数のサービス提供装置の機能をマークアップ言語によって記述した閲覧用データを生成する生成ステップと、
前記閲覧用データを登録する登録ステップと、
いずれかのサービス提供装置において機能の変更があった場合に、登録された前記閲覧用データを更新する更新ステップと、
サービス利用装置が、登録された前記閲覧用データを取得して、サービスリストを生成し、表示するサービスリスト表示ステップと、
をコンピュータに実行させることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上でサービスを検索する技術に関する。
【背景技術】
【０００２】
従来から、複数の情報機器が接続されたネットワークシステムであって、クライアント装置に対する操作によって、ネットワーク上の装置から所望のサービスを享受できるシステムが存在する。従来型のシステムでは、サービス提供装置が、自身の持つ機能をサービスとして構築し、サービス管理サーバにそのサービスを登録していた。サービス管理サーバは、複数の場所にある多様なサービスを一元管理し、サービス利用装置からのアクセスに対して、そのサービス群の情報を提供し、ユーザが利用したいサービスを提供していた（特許文献１）。
【特許文献１】特開２００１−１０９６９３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、従来の技術において、タイムラグにより、サービス検索時に収集した複数の場所にある多様なサービス情報と、実際に利用する際のサービスの実体とが異なる場合があった。
【０００４】
本発明は、上記従来技術の課題を解決するためになされたものである。そしてその目的は、ネットワーク上の多様なサービスの最新情報を常時取得することのできる技術を提供することにある。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、本発明に係る方法は、以下の発明特定事項を含む。
サービス利用装置に対して、ネットワーク上の複数のサービス提供装置からのサービスを提供する情報処理方法において、
複数のサービス提供装置の機能をマークアップ言語によって記述した閲覧用データを生成する生成ステップ。
前記閲覧用データを登録する登録ステップ。
いずれかのサービス提供装置において機能の変更があった場合に、登録された前記閲覧用データを随時更新する更新ステップ。
サービス利用装置が、登録され随時更新された前記閲覧用データを取得して、サービスリストを生成し、表示するサービスリスト表示ステップ。
を含むことを特徴とする。
【０００６】
上記目的を達成するため、本発明に係るシステムは、以下の発明特定事項を含む。
サービス利用装置に対して、ネットワーク上の複数のサービス提供装置からのサービスを提供する情報処理システムにおいて、
複数のサービス提供装置の機能をマークアップ言語によって記述した閲覧用データを生成する生成手段。
前記閲覧用データを登録する登録手段。
いずれかのサービス提供装置において機能の変更があった場合に、登録された前記閲覧用データを更新する更新手段。
サービス利用装置が、登録された前記閲覧用データを取得して、サービスリストを生成し、表示するサービスリスト表示手段。
を含むことを特徴とする。
【０００７】
上記目的を達成するため、本発明に係るプログラムは、以下の工程をコンピュータに実行させる。
サービス利用装置に対して、ネットワーク上の複数のサービス提供装置からのサービスを提供する情報処理プログラムにおいて、
複数のサービス提供装置の機能をマークアップ言語によって記述した閲覧用データを生成する生成ステップ。
前記閲覧用データを登録する登録ステップ。
いずれかのサービス提供装置において機能の変更があった場合に、登録された前記閲覧用データを更新する更新ステップ。
サービス利用装置が、登録された前記閲覧用データを取得して、サービスリストを生成し、表示するサービスリスト表示ステップ。
をコンピュータに実行させることを特徴とする。
【発明の効果】
【０００８】
本発明によれば、ネットワーク上の多様なサービスの最新情報を常時取得することができる。
【発明を実施するための最良の形態】
【０００９】
以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されている構成要素はあくまで例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。なお、本明細書中、サービスとは、サービス提供装置が、サービス利用装置に対して提供できる機能を表わすものである。
図１は、本発明の実施形態に係るネットワークシステムの構成を示す図である。情報処理システムとしてのサービス利用装置１００、サービス提供装置１０１，１０２，１０３はＬＡＮ４００に繋がれてネットワークを構築している。サービス提供装置１０１，１０２，１０３は、各機器が持つ様々な機能をサービスとして外部に提供する。サービス利用装置１００はユーザ９９の指示により（またはサービス利用装置１００自身が所定の条件に基づき判断して）、サービス提供装置１０１，１０２，１０３において提供されたサービスを、ネットワークを介して利用する。
【００１０】
さらに、サービス提供装置１０１，１０２，１０３は、サービスを提供するために、事前に自身が持つサービスを示す情報を外部に提示することもできる。この技術は、サービス管理サーバにて実現され、サービス利用装置１００は検索要求を示すパケットをＬＡＮ４００に送出することにより、各サービス提供装置が提示する上記情報の中から検索要求に応じたものを発見し、その結果をユーザ９９に提示する。ユーザ９９はその中から利用するサービスを決定し、実際にサービスを利用することになる。つまり、各サービス提供装置１０１，１０２，１０３は自身の持つ機能をサービスとして公開し、サービス利用装置１００がそのサービスを利用したい場合に、サービス利用装置１００において、それらのサービスを検索可能な構成となっている。
【００１１】
このサービス管理の技術に関しては、例えばＷｅｂサービス技術におけるＵＤＤＩ（Universal Description, Discovery and Integration）技術が広く一般的に知られている。ＵＤＤＩはいわゆるサービスリポジトリである。サービス提供者は公開したいサービスの情報、例えばサービス名やサービスの種類、インタフェイス定義、アクセスポイントなどをこのＵＤＤＩに登録する。そしてサービス利用者はこのＵＤＤＩに対してどんなサービスがあるかを問い合わせ、サービスに関する情報を得ることができる。本実施形態におけるサービスの検索においては、このＵＤＤＩ技術を用いるものとするが、もちろん他の方法も採用し得る。
【００１２】
次に、サービス利用装置の構成の一例について、図２を用いて説明する。リーダ部２００は、原稿画像を光学的に読み取り、画像データに変換する。リーダ部２００は、原稿を読み取るための機能を持つスキャナユニット２１０と、原稿用紙を搬送するための機能を持つ原稿給紙ユニット２５０とを備える。機器構成によっては、原稿給紙ユニット２５０を持たないもの（この場合、ユーザがプラテンガラス（原稿台）に原稿を置き読み取りを実行させる）もある。プリンタ部３００は、記録紙を搬送し、その上に画像データを可視画像として形成して装置外に排紙する。プリンタ部３００は複数種の記録紙カセットを持つ給紙ユニット３６０と、画像データを記録紙に転写、定着させるマーキングユニット３１０、印字された記録紙をソート、ステイプルして機外へ出力する排紙ユニット３７０とで構成される。コントローラ１１０は、リーダ部２００、プリンタ部３００と電気的に接続され、さらにＬＡＮ４００に接続されている。コントローラ１１０は、ＣＰＵ、ワーク用のメモリなどを有し、ＨＤＤ１６０に記憶されているプログラムコードをワーク用のメモリにロードし、このプログラムコードをＣＰＵが解釈することによりサービス利用装置全体の動作を制御する。また、コントローラ１１０は、リーダ部２００を制御して、原稿上の画像を読み取って得た画像データをプリンタ部３００に出力し、記録用紙上に画像を形成するコピー機能を提供する。また、リーダ部２００で原稿上の画像を読み取って得た画像データをコードデータに変換し、ＬＡＮ４００を介してホストコンピュータへ送信するネットワークスキャナ機能を提供する。さらには、ホストコンピュータからＬＡＮ４００を介して受信したコードデータを画像データに変換し、プリンタ部３００に出力するプリンタ機能を提供する。操作部１５０は液晶表示部と液晶表示部上に張り付けられたタッチパネル入力装置と、複数個のハードキーを有し、ユーザが様々な操作を行うためのユーザＩ／Ｆを提供する。タッチパネルまたはハードキーにより入力された信号はコントローラ１１０に伝えられ、液晶表示部はコントローラ１１０から送られてきた画像データを表示する。１６０はハードディスクであり、コントローラ１１０が実行するプログラムコードを記憶する他、サービス情報やシンジケーションデータを保存していく記憶領域を有している。また、サービス提供装置１０１、１０２、１０３もサービス利用装置１００と同様の以上のような構成を有するものとする。
【００１３】
図３に、ＵＤＤＩを利用した場合の構成の一例を示す。サービス管理サーバ（ＵＤＤＩ）１０９に対して、サービス提供装置１０４，１０５，１０６並びに１０１，１０２，１０３からサービス情報を登録し、サービス利用装置１００からこのサービス管理サーバ（ＵＤＤＩ）１０９に対して検索を行う。サービス管理サーバ（ＵＤＤＩ）１０９は複数存在する場合もある。
【００１４】
次に図４、図５を用いてＵＤＤＩに相当するサービス管理サーバの所在について説明する。図４においては、各サービス提供装置において、サービス管理サーバを保持し、図５においては、１台のサービス提供装置１０１においてサービス管理サーバを保持している。本実施形態は何れのシステムにも適用可能である。
【００１５】
図４は、前述したＵＤＤＩに相当するサービス管理サーバを、各サービス提供装置で保持する場合の例である。サービス提供装置１０１，１０２，１０３ではそれぞれ、自身で持っている機能をサービス化し（他の装置から利用可能とし）、自身で保持したサービス管理サーバ１０１０，１０２０，１０３０に対して、サービスリストとして登録する。これにより、例えば、サービスリスト５０１，５０２，５０３のように、登録したサービスが列挙され保持されている状態となる。この場合、サービス利用装置１００から各サービス提供装置に対してサービス検索を行う。
【００１６】
一方、図５は、前述したＵＤＤＩに相当するサービス管理サーバを、サービス提供装置１０１のみで実現する場合の例である。サービス提供装置１０１，１０２，１０３ではそれぞれ、自身で持っている機能をサービス化し（他の装置から利用可能とし）、サービス提供装置１０１に配備されたサービス管理サーバ１０１１に対してサービスリスト５０４として登録する。そして、サービス利用装置１００から、サービス提供装置１０１に配備されたサービス管理サーバ１０１１に対してのみサービス検索を行うことになる。
【００１７】
インターネットＷｅｂ技術分野において、最新ニュースなどをシンジケーション（配給）するために用いられるＲＳＳの各バージョンやＡｔｏｍなどのＸＭＬ応用が多用され始めている。本実施形態では、サービス提供装置からサービス管理サーバに対して、サービスの更新・履歴情報を、ＲＳＳの各バージョンやＡｔｏｍなどのＸＭＬを利用してシンジケーションする。本明細書においてシンジケーションとは更新情報／サマリー情報を配信、通知することを意味する。そして、シンジケーションデータはＲＳＳリーダによって更新情報、サービス情報を閲覧させるための閲覧データを指す。
【００１８】
図６は、サービス提供装置で行なわれる処理の流れを示すフローチャートである。本フローチャートはサービス提供装置のＨＤＤ１６０に記憶されているプログラムコードに基づきコントローラ１１０が実行する処理の流れを示すものである。
【００１９】
Ｓ７０１では、サービス提供装置が、自身の持っているサービス情報をシンジケーションデータとして生成する。Ｓ７０２では、サービス情報をサービス管理サーバに送信して登録し、それと同時に、Ｓ７０３で、Ｓ７０１で作成したシンジケーションデータをサービス管理サーバに送信して登録する。これにより、サービス管理サーバ側で、サービス提供装置が提供するサービス情報の更新情報や最新情報を監視できるようになる。
【００２０】
ここで、Ｓ７０２で登録したサービス情報は、サービス利用装置１００がサービス提供装置のサービスを利用すべく参照する情報であり、サービス利用装置とサービス提供装置との間でのみ利用される固有の形式の情報である。一方、Ｓ７０３で登録したシンジケーションデータは、ＲＳＳやＡｔｏｍなどの汎用的な形式の情報であり、汎用のＲＳＳリーダを用いて参照可能である。ただし、シンジケーションデータはサービスの内容を確認するためだけに用いられる。
次に、Ｓ７０４では、サービス提供装置において、自身のサービス情報に変更があったか、または新しいサービスが追加されたかどうかを判断している。もしここでサービスの情報更新・追加があった場合は、Ｓ７０５にてシンジケーションデータを再構築し、サービス管理サーバに登録し直す。このときの再構築とは、更新部分のみの構築になる。そしてＳ７０４に戻り、サービスの情報更新・新しいサービスの追加の監視処理に戻る。また、この再構築では、サービス管理サーバに既に登録されているシンジケーションデータに、更新頻度や更新予定時刻が含まれており、サービス管理サーバがこれに従い更新の有無を問い合わせてくるので、その問い合わせに対し、Ｓ７０５でシンジケーションデータを再構築していればそれを送信し登録し直すものである。
図７はサービス管理サーバの処理フローについて説明したものである。本フローチャートはサービス管理サーバのＨＤＤに記憶されているプログラムコードに基づきサービス管理サーバのコントローラ１１０が実行する処理の流れを示すものである。
【００２１】
Ｓ７１１では、図６のＳ７０２、Ｓ７０３で述べたように、サービス提供装置からサービス管理サーバに対してサービス情報／シンジケーションデータの登録があったかどうかを、サービス管理サーバ側で判断している。次にＳ７１２において、Ｓ７１１で登録があった、サービス提供装置のシンジケーションデータを元データとして、サービス利用装置に提供すべきサービス群情報を、シンジケーションデータとして生成する。このとき、サービス提供装置は複数ある場合が多いが、複数のサービス情報を１つのシンジケーションデータとして生成する。このとき、どのサービスがどのサービス提供装置が提供できるサービスかが判別できる形式とする。そしてＳ７１３にて、このシンジケーションデータの提供を開始する。これにより、サービス利用装置側で、複数の多様なサービス群情報の更新情報を、１つのデータとして監視できるようになる。次に、Ｓ７１４では、サービス提供装置のシンジケーションデータの監視を開始し、Ｓ７１５にて、シンジケーションデータの更新状況の問い合わせを行う。
【００２２】
このとき、シンジケーションデータに含まれた、更新頻度や、更新予定時刻を元に、定期的に問い合わせを行う。Ｓ７１６においては、シンジケーションデータが更新されたかどうかを判断している。更新されている場合はＳ７１７に進み、サービス利用装置に提供するサービス群情報をシンジケーションデータとして再構築することになる。このとき、シンジケーションデータは、更新のあった一部のみの再構築となる。そして再構築が終わると、Ｓ７１３にてシンジケーションデータの提供の処理に戻る。
【００２３】
このサービス管理サーバが構築したシンジケーションデータは、ＬＡＮ４００上のＲＳＳリーダ機能を持った装置から参照が可能であるものとする。従って、ユーザは汎用的なＲＳＳリーダを用いてサービス管理サーバにアクセスするのみによってＬＡＮ４００上の複数のサービス提供装置が提供可能な全てのサービスを参照することができる。
【００２４】
図８はサービス利用装置の処理フローについて説明したものである。本フローチャートはサービス利用装置のＨＤＤ１６０に記憶されているプログラムコードに基づきコントローラ１１０が実行する処理の流れを示すものである。サービス利用装置では、例えば装置が起動したときに、サービス情報を一度に取得する。これは、起動時に１回サービス情報を取得してしまえば、シンジケーションデータを利用した更新情報管理により、その後のサービス情報の最新情報を取得できるため、ユーザが都度検索するよりも効率的だからである。もちろん、これ以外のタイミングで検索を行うようにしてもよい。
【００２５】
起動時、Ｓ７２１で本サービス利用装置が利用可能なサービス群情報をサービス管理サーバに問い合わせ、Ｓ７２２にてサービスリストを生成する。サービス利用装置が利用可能なサービス群とは、サービス利用装置の機能とサービス提供装置の機能によって制限される。そしてユーザがサービスリストを表示するよう操作した場合、そのサービスリストをＳ７２３にて操作部１５０に表示する。そしてＳ７２４にてサービス管理サーバにあるシンジケーションデータの監視を開始し、Ｓ７２５にて、そのシンジケーションデータの更新状況の問い合わせを行う。このとき、問い合わせは、シンジケーションデータに含まれた、更新頻度や、更新予定時刻を元に、定期的に問い合わせを行う。Ｓ７２６においては、シンジケーションデータが更新されたかどうかを判断している。更新されている場合はＳ７２７に進み、サービスリストを再構築する。このとき、シンジケーションデータは、更新のあった一部のみの再構築となる。そして再構築が終わると、Ｓ７２３にて操作部１５０に表示する処理に戻る。この場合、前回の表示の際と変更のあった部分が判別できるように表示するようにしてもよい。
【００２６】
また、サービス利用装置が構築したシンジケーションデータは、ＬＡＮ４００上のＲＳＳリーダ機能を持った装置から参照が可能であるものとする。従って、ユーザは汎用的なＲＳＳリーダを用いてサービス利用装置にアクセスするのみによってＬＡＮ４００上の複数のサービス提供装置がサービス利用装置に対して提供可能なサービスを参照することができる。
【００２７】
図９に、図６のＳ７０１においてサービス提供装置１００が生成するサービス情報のシンジケーションデータ（同期用データ）の一例を示す。ここでは、シンジケーションデータをＲＳＳ１．０の形式に従ったメタデータとして記載するが、本発明はこれに限定されるものではなく、他にもＲＳＳ２．０、Ａｔｏｍなどの形式で記載してもよい。
【００２８】
２００１はこのデータ内で使用する、ボキャブラリの一意性を保つための名前空間の定義である。２００２はｃｈａｎｎｅｌ要素であり、属性として、本シンジケーションデータのＵＲＩが記載されている。２００３はｔｉｔｌｅ要素であり、本データのタイトルで、本図の場合は「Ｓｅｎｄ  Ｂ」サービスについてのデータであることがわかる。２００４はｌｉｎｋ要素であり、「Ｓｅｎｄ  Ｂ」サービスのＵＲＩが書かれている。２００５はｄｅｓｃｒｉｐｔｉｏｎ要素であり、本データについての説明が書かれている。図９の場合はデバイスＢ（サービス提供装置１０２）上のサービス情報であることを示している。２００６はｉｔｅｍｓ要素であり、下記ｉｔｅｍで羅列されるリソースデータ（ＵＲＩ）が２００７に書かれている。ｉｔｅｍ要素が複数存在する場合は、このリソースデータ（ＵＲＩ）は複数記載される。
【００２９】
２００８はｉｔｅｍ要素であり、シンジケーションデータの具体的な説明が記載されている。２００９はｉｔｅｍ要素であり、その属性として、ｉｔｅｍ要素に記載される具体的なリソースデータ（ＵＲＩ）が記載されている。２０１０はｔｉｔｌｅ要素であり、本図の場合は「Ｓｅｎｄ  Ｂ」サービスに関する情報であることが記載されている。２０１１は実際アクセスするためのリソースデータ（ＵＲＩ）であり、ｉｔｅｍ要素に記載されるＵＲＩと同じものになる。２０１２はｄｅｓｃｒｉｐｔｉｏｎ要素であり、本ｉｔｅｍについての説明が書かれている。本実施の形態においては、このｄｅｓｃｒｉｐｔｉｏｎ要素に、各サービスでサポートするサービス内容、例えばＳｅｎｄサービスであればそのプロトコル情報が記載されている。本図においては、「Ｓｅｎｄ  Ｂ」サービスにおいて、ＦＴＰプロトコル、ＳＭＢプロトコルがサポートされていることを知ることができる。２０１３はｄｃ：ｄａｔｅ要素であり、本データが作成（更新）された日付情報（ここでは２００６年５月１４日）が書かれている。２０１４はｓｙ：ｕｐｄａｔｅＰｅｒｉｏｄ要素であり、データの更新期間（ここでは一週間毎）が書かれている。この２０１３と２０１４の両要素により、シンジケーションデータを取得するサービス管理サーバが、例えば、図７におけるＳ７１５で、次にいつデータを取得すればよいのかを判断することができる。
【００３０】
次に、Ｓ７０２、Ｓ７０３で、サービス情報及びサービス情報のシンジケーションデータをサービス管理サーバに登録する場合のデータの一例について説明する。図１０においては、２０２１で名前空間を定義している。ここで、シンジケーションデータ登録のため、スキーマを拡張しているので、独自の名前空間ｒｒというものの定義も行っている。２０２２はｎａｍｅ要素であり、サービス名を登録している。本図においては、「Ｓｅｎｄ  Ｂ」というサービス名でサービスを登録している。２０２３はｒｒ：ｒｓｓ要素であり、ここで、図９で説明したシンジケーションデータのＵＲＩを記載することにより、シンジケーションデータの登録を行っている。２０２４はａｃｃｅｓｓＰｏｉｎｔ要素であり、実際のサービスを動作させる際にアクセスするＵＲＩである。２０２５はｏｖｅｒｖｉｅｗＵＲＬ要素であり、サービスのインタフェイス定義情報が記載されているＷＳＤＬファイルの所在（ＵＲＩ）を表している。この処理により、サービス管理サーバ側としては、Ｓ７１１で登録待ちであった状態から、Ｓ７１２のシンジケーションデータ生成処理に進むことになる。
【００３１】
次に、図７におけるＳ７１２のシンジケーションデータ生成処理について図１１、１２を参照しながら説明を行う。図１１と図１２は１つのデータであるが図１１ではｃｈａｎｎｅｌ要素まで、図１２では主にｉｔｅｍ要素について記載している。
【００３２】
図１１、１２は、図７のＳ７１２においてサービス管理サーバが生成する複数のサービス群情報をシンジケーションデータ化したデータの一例である。２０３１はこのデータ内で使用する、ボキャブラリの一意性を保つための名前空間の定義である。２０３２はｃｈａｎｎｅｌ要素であり、属性として、本シンジケーションデータのＵＲＩが記載されている。２０３３はｔｉｔｌｅ要素であり、本データのタイトルで、本図の場合はサービス群全体についてのデータであることがわかる。２０３４はｌｉｎｋ要素であり、本サービスについての情報が書かれたＵＲＩが書かれている。２０３５はｄｅｓｃｒｉｐｔｉｏｎ要素であり、本データについての説明が書かれている。本図の場合はネットワーク上に存在するサービス群の情報であることを示している。２０３６はｉｔｅｍｓ要素であり、下記ｉｔｅｍで羅列されるリソースデータ（ＵＲＩ）が２０３７に書かれている。本図においては、サービス情報のすべては記載せず、一部のみに省略している。
【００３３】
図１２における２０３８はｉｔｅｍ要素であり、シンジケーションデータの具体的な説明が記載されている。２０３９はｉｔｅｍ要素であり、その属性として、ｉｔｅｍ要素に記載される具体的なリソースデータ（ＵＲＩ）が記載されている。２０４０はｔｉｔｌｅ要素であり、「Ｓｅｎｄ  Ｂ」サービスに関する情報であることが記載されている。２０４１は実際アクセスするためのリソースデータ（ＵＲＩ）であり、ｉｔｅｍ要素に記載されるＵＲＩと同じものになる。２０４２はｄｅｓｃｒｉｐｔｉｏｎ要素であり、本ｉｔｅｍについての説明が書かれている。本実施の形態においては、このｄｅｓｃｒｉｐｔｉｏｎ要素に、各サービスでサポートするサービス内容、例えばＳｅｎｄサービスであればそのプロトコル情報が記載されている。本図においては、「Ｓｅｎｄ  Ｂ」サービスにおいて、ＦＴＰプロトコル、ＳＭＢプロトコルがサポートされていることを知ることができる。２０４３はｄｃ：ｄａｔｅ要素であり、本データが作成（更新）された日付情報が書かれている。２０４４はｓｙ：ｕｐｄａｔｅＰｅｒｉｏｄ要素であり、データの更新期間が書かれている。この２０４３と２０４４の両要素により、シンジケーションデータを取得するサービス利用装置が、例えば図８におけるＳ７２５で、次にいつデータを取得すればよいのかを判断することができる。
【００３４】
図１２における他のサービスのｉｔｅｍ要素については、２０３８〜２０４４と同様のためその詳しい説明は割愛する。ここではｉｔｅｍ要素として、サービス管理サーバで集約したサービス群情報のすべて（ここでは「Ｓｅｎｄ  Ａ」「Ｓｅｎｄ  Ｂ」「Ｓｅｎｄ  Ｄ」「Ｆａｘ  Ａ」）を羅列している。
【００３５】
次に図１３、１４において、図８のＳ７２１においてサービス利用装置がサービス管理サーバに対してサービス情報を問い合わせる場合について説明する。Ｓ７２１で説明したように、例えば機器が起動したときに、サービス情報を一度に取得することなどが考えられる。これは、起動時に１回サービス情報を取得してしまえば、シンジケーションデータを利用した更新情報管理により、その後のサービス情報の最新情報を取得できるため、ユーザが都度検索するよりも効率的だからである。この検索は、２段階になっており、まず図１３に示すデータによりサービスがあるかどうかを問い合わせ、図１４でサービスの詳細情報を取得に行く。
【００３６】
図１３における２０５１が、サービス利用装置がサービス管理サーバに問い合わせを行う部分である。２０５１におけるｆｉｎｄ＿ｓｅｒｖｉｃｅ要素を用いて問い合わせを行う。この２０５１のｆｉｎｄ＿ｓｅｒｖｉｃｅ要素におけるｎａｍｅ要素に、サービス名に関係する文字列を埋め込むことにより、サービス管理サーバがそれに合致するサービスを返す。この場合、ｎａｍｅ要素の値として「％」を用いると、すべてのサービス情報を返すことになる。２０５２はサービス管理サーバからのレスポンスデータである。２０５３はシンジケーションデータ監視のため、スキーマを拡張しているので、独自の名前空間ｒｒというものの定義も行っている。また、２０５４はｒｒ：ｒｓｓ要素であり、サービス管理サーバが管理するサービス群のシンジケーションデータのＵＲＩを記載している。また、ｓｅｒｖｉｃｅｉｎｆｏｓ要素の中にｓｅｒｖｉｃｅｉｎｆｏ要素が羅列され、サービスの情報が返される。例えば２０５５では「Ｓｅｎｄ  Ｂ」サービスの情報が返る。図１４で説明する詳細情報の取得の際には、このｓｅｒｖｉｃｅｉｎｆｏ要素の中のｓｅｒｖｉｃｅＫｅｙ属性を要求データに含めることにより、サービス管理サーバは「Ｓｅｎｄ  Ｂ」サービスであることを特定する。
【００３７】
次に図１４について説明する。サービス利用装置がサービスの詳細情報を取得する必要がある場合は、２０５６でｇｅｔ＿ｓｅｒｖｉｃｅＤｅｔａｉｌ要素を用いて問い合わせを行う。この２０５６のｇｅｔ＿ｓｅｒｖｉｃｅＤｅｔａｉｌ要素におけるｓｅｒｖｉｃｅＫｅｙ要素に、図１３で説明したｓｅｒｖｉｃｅｉｎｆｏ要素２０５５内のｓｅｒｖｉｃｅＫｅｙ属性で得られたＩＤを埋め込む。これにより、サービス管理サーバでは「Ｓｅｎｄ  Ｂ」サービスであることを特定し、レスポンスを返す。このとき、サービス名を識別子として扱う場合は、名前の衝突が考えられるため、サービス管理サーバが各サービスに対して割り振ったｓｅｖｉｃｅＫｅｙをＩＤとして用いる。２０５７は問い合わせに対するサービス管理サーバのレスポンスである。２０５８はａｃｃｅｓｓＰｏｉｎｔ要素であり、実際のサービスを動作させる際にアクセスするＵＲＩである。２０５９はｏｖｅｒｖｉｅｗＵＲＬ要素であり、サービスのインタフェイス定義情報が記載されているＷＳＤＬファイルの所在（ＵＲＩ）を表している。ただし、このサービスの詳細情報問い合わせは必ずしも必要ではない。これは、図１３で説明したとおり、サービス群の情報は、図１１、１２に示すシンジケーションデータにより取得可能であるからである。
【００３８】
図８のＳ７２１において、図１４の問い合わせフォームでサービス群情報を取得したら、図８のＳ７２２にてサービスリスト５１０を作成し、Ｓ７２３にて操作部に表示する。サービスリスト５１０は図１５に示したとおりである。また、このサービスリスト５１０を元に、図１６のように、操作部１５０にサービスリスト表示を行う。図１５のサービスリストには、サービス名６２１、サービス情報６２２、デバイス名６２３、サービスのＵＲＩ６２４が記載されている。図１６の操作部表示では、６２５が操作部全面を表しており、６２６がコピーやファクスなどの機能を設定するフィールド、６２７がサービスリスト表示となっている。
【００３９】
次に、サービス提供装置において登録されたサービス情報が変更された場合について、図１７にて説明する。図６のＳ７０４において、サービス情報の更新、例えば「Ｓｅｎｄ  Ｂ」サービスにおいて、ＦＴＰのプロトコルが使用できなくなった場合について説明する。図９とほぼ同じであるが、ＦＴＰプロトコルが使用できなくなったことにより、３００１のｉｔｅｍ要素内のｄｅｓｃｒｉｐｔｉｏｎ要素３００２からＦＴＰの記述が消えている。これにより、図７のＳ７１４にて監視、Ｓ７１５にて状況問い合わせしていたサービス管理サーバが変化を検知し、Ｓ７１７でサービス管理サーバが持つシンジケーションデータを再構築する。再構築したデータについては図１８、１９に記載がある。これは図１２、１３とほぼ同じであるが、ＦＴＰプロトコルが使用できなくなったことにより、３００３のｉｔｅｍ要素内のｄｅｓｃｒｉｐｔｉｏｎ要素３００４からＦＴＰの記述が消えている。これにより、図８のＳ７２４にて監視、Ｓ７２５にて状況問い合わせしていたサービス利用装置が変化を検知し、Ｓ７２７でサービスリストを再構築する。再構築したリストについては図２０に記載がある。図２０のサービス情報６５１にあるように、「Ｓｅｎｄ  Ｂ」サービスのサービス情報からＦＴＰプロトコルが削除される。そして、図２１のサービスリスト表示６５２のように、ＦＴＰプロトコルが削除されたサービスリスト表示になる。
【００４０】
また、図２２は、ＰＣ上のＲＳＳリーダ機能付きＷｅｂブラウザで閲覧できるサービス情報について説明している。６６１が、図１１において説明した、サービス管理サーバで提供しているシンジケーションデータのＴｉｔｌｅ２０３３要素で表現した要素を表している。また、６６２には、同じく図１１の２０３７、図１２の２０３８において説明した、サービス群の情報が羅列されている。このように、標準技術を使用することにより、一般的なＷｅｂブラウザを用いてのサービス情報を閲覧することが可能となる。また、ＲＳＳリーダ機能を持った他のクライアントソフトウェアでも、ユーザはサービスの最新情報を得ることができる。
【００４１】
本実施形態によると、ユーザは、サービス管理サーバ、あるいはサービス利用装置に対して問い合わせをするだけで、複数の場所にある多様なサービスの最新情報を常時取得することができる。サービス管理サーバには、複数の場所にある多様なサービスが登録されているが、これらのサービスをシンジケーションデータとして管理することで、容易に一元管理できる。
【００４２】
また、サービス管理サーバにおいて、サービスの情報を集約する際に、サービス提供装置からの情報を、サービス利用者にとって適切な情報に整形して情報提供できるため、柔軟なサービス管理が実現できる。
【００４３】
さらには、標準技術を利用することにより、一般的なＷｅｂブラウザなどから情報を取得できるため、ユーザはサービス利用装置の前に行くことなく、自席のＰＣなどからサービス群の最新情報を取得することも可能である。
【００４４】
（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【００４５】
なお、本発明は、前述した実施形態の機能を実現するプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置が、供給されたプログラムコードを読み出して実行することによっても達成される。従って、本発明の機能処理をコンピュータで実現するために、コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。
【００４６】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【００４７】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスクがある。また、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【００４８】
その他、クライアントＰＣのブラウザを用いてインターネットサイトに接続し、本発明に係るプログラムそのもの、もしくは更に自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードするという利用方法もある。また、本発明に係るプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明の範疇に含まれる。  また、本発明に係るプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布してもよい。所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００４９】
また、プログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【００５０】
さらに、ＰＣの機能拡張ユニットに備わるメモリに本発明に係るプログラムが書き込まれ、そのプログラムに基づき、その機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行なう場合も、本発明の範疇に含まれる。
【図面の簡単な説明】
【００５１】
【図１】本発明に関わるシステム構成の一例を説明した図である。
【図２】本発明に関わるサービス利用装置の一例を説明した図である。
【図３】従来技術のシステム構成の一例を説明した図である。
【図４】本発明に関わるシステム構成の一例を説明した図である。
【図５】本発明に関わるシステム構成の一例を説明した図である。
【図６】本発明に関わるフローチャートの一例を説明した図である。
【図７】本発明に関わるフローチャートの一例を説明した図である。
【図８】本発明に関わるフローチャートの一例を説明した図である。
【図９】本発明に関わるシンジケーションデータの一例を説明した図である。
【図１０】本発明に関わるサービス情報登録のためのデータの一例を説明した図である。
【図１１】本発明に関わるシンジケーションデータの一例を説明した図である。
【図１２】本発明に関わるシンジケーションデータの一例を説明した図である。
【図１３】本発明に関わるサービス情報検索のためデータの一例を説明した図である。
【図１４】本発明に関わるサービス情報検索のためデータの一例を説明した図である。
【図１５】本発明に関わるサービスリストの一例を説明した図である。
【図１６】本発明に関わる操作部（サービスリスト表示）の一例を説明した図である。
【図１７】本発明に関わるシンジケーションデータの一例を説明した図である。
【図１８】本発明に関わるシンジケーションデータの一例を説明した図である。
【図１９】本発明に関わるシンジケーションデータの一例を説明した図である。
【図２０】本発明に関わるサービスリストの一例を説明した図である。
【図２１】本発明に関わる操作部（サービスリスト表示）の一例を説明した図である。
【図２２】本発明に関わるＰＣ上のＷｅｂブラウザ表示の一例を説明した図である。
【符号の説明】
【００５２】
９９  ユーザ
１００  サービス利用装置
１０１，１０２，１０３，１０４，１０５，１０６  サービス提供装置
１０９  サービス管理サーバ（ＵＤＤＩ）
５０１，５０２  サービスリスト
１１０  制御装置
１５０  操作部
１６０  ＨＤＤ
２００  リーダ装置
２１０  スキャナユニット
２５０  原稿給紙ユニット
４００  ＬＡＮ
【図１】
2008152397.tif 000003
【図２】
2008152397.tif 000004
【図３】
2008152397.tif 000005
【図４】
2008152397.tif 000006
【図５】
2008152397.tif 000007
【図６】
2008152397.tif 000008
【図７】
2008152397.tif 000009
【図８】
2008152397.tif 000010
【図９】
2008152397.tif 000011
【図１０】
2008152397.tif 000012
【図１１】
2008152397.tif 000013
【図１２】
2008152397.tif 000014
【図１３】
2008152397.tif 000015
【図１４】
2008152397.tif 000016
【図１５】
2008152397.tif 000017
【図１６】
2008152397.tif 000018
【図１７】
2008152397.tif 000019
【図１８】
2008152397.tif 000020
【図１９】
2008152397.tif 000021
【図２０】
2008152397.tif 000022
【図２１】
2008152397.tif 000023
【図２２】
2008152397.tif 000024