JP2016018537A - 情報処理端末、情報処理端末の制御方法、及びプログラム - Google Patents

Abstract

【課題】ネットワーク機器が提供する各種サービスについてユーザに最適なサービス一覧を提供し、ユーザが容易に選択・利用すること。
【解決手段】ＵＡとしての情報処理端末５３０のＷｅｂブラウザは、探索により取得されたローカルサーバ（プリンタ）５２１等が提供するローカルサービスの機能情報、及び、サーバ５２０が提供するサイトを介して取得されたサービスの機能情報を登録可能であり、Ｗｅｂ ＩｎｔｅｎｔｓのＩｎｖｏｃａｔｉｏｎを受信した際に、登録された機能情報の一覧を表示し、ユーザに使用するサービスの選択を促す。なお、探索により既に登録されている機能情報が見つかった場合には、当該探索の結果に従い機能情報の一覧の表示を更新する。
【選択図】図５

Description

本発明は、ネットワーク機器が提供するサービスを利用する技術に関する。

従来、Ｗｅｂサイト間で処理を委譲する場合、機能を呼び出す側は、機能を提供する側のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）やＲＥＳＴ（ＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）インタフェース等の機能の呼び出し方を、知っている必要があった。従って、異なるＷｅｂサイトとの連携を実現するためには、機能の呼び出し側は、それぞれの呼び出し規約に従って呼び出し側の処理を行う必要があった。

専用のＡＰＩを用いずに任意のＷｅｂサービス（または、Ｗｅｂアプリケーション）と連携する仕組みも存在する。一例として、実行時遅延バインディングによりサービス受け側と提供側とを疎結合とし、それらの連携を実現するＷｅｂ Ｉｎｔｅｎｔｓ（ウェブインテンツ）という仕組みが提案されている。

Ｗｅｂ Ｉｎｔｅｎｔｓでは、インターネットのＷｅｂページで提供されるサービスをユーザに提示する。このため、ユーザがＬＡＮに接続したプリンタなどをインターネットのＷｅｂページで提供されるサービスと同様に選択することはできなかった。

この課題を解決する技術として、特許文献１に記載されるような技術がある。特許文献１は、ＵＰｎＰなどによりＬＡＮ内のローカルサービス探索を行うことで、ユーザに情報処理サービスの選択肢をより幅広く提示して各種の機器を利用することを可能にする。

特開２０１３−１９６３５６号公報

特許文献１の技術では、ローカルサービスの探索について、ＳＳＤＰ（Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）をＷｅｂ Ｉｎｔｅｎｔｓ拡張することでＷｅｂ Ｉｎｔｅｎｔｓサービスの探索を行っている。探索結果は、ＵＡ（ユーザエージェント）に登録されないため、Ｗｅｂ ＩｎｔｅｎｔｓのＩｎｖｏｃａｔｉｏｎを受信した際に毎回ローカルサービスの探索を行う必要がある。なお、環境によっては多くのローカルサービスが存在し、探索結果に、ユーザにとって不要なローカルサービスが多く含まれてしまうことがある。このような環境では、毎回、ユーザにとって不要なローカルサービスが探索により発見されて、サービス一覧に表示されてしまう。このため、ユーザは、サービス一覧から自分の利用したいサービスを見つけにくくなってしまうことがある。

このため、インターネット上のサービスやローカルサービス等の、ネットワーク機器が提供する各種サービスを、ユーザが容易に選択・利用することができる仕組みの提案が望まれていた。

なお、ローカルサービスは、インターネットを介して提供されているサービスとは異なり、サービスの提供状態が変動することがある。例えば、ローカルサービスを提供する機器の電源がＯＦＦであるために通信エラーになる場合や、消耗品が不足してサービスを実行できない等、サービスが提供できない場合がある。このため、ローカルサービスをＵＡに登録しても、ユーザによりサービス一覧から選択された際には、該サービスの提供状態が変わっていて使用できない可能性がある。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、ネットワーク機器が提供する各種サービスについてユーザに最適なサービス一覧を提供し、ユーザが容易に選択・利用することを可能にする仕組みを提供することである。

本発明は、データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを中継する中継機能を備える情報処理端末であって、所定のネットワークプロトコルを用いて、ネットワークを介してサービスを探索することで、当該ネットワークに接続されたネットワーク機器が提供する第１のサービスを要求するための第１の機能情報を取得する第１の取得手段と、第２のサービスを提供するネットワーク機器のサイトを介して、当該第２のサービスを要求するための第２の機能情報を取得する第２の取得手段と、前記中継機能による前記第１の取得手段及び前記第２の取得手段により取得された前記第１の機能情報及び前記第２の機能情報の登録処理を実行する登録手段と、前記登録処理に従い登録された前記第１の機能情報及び前記第２の機能情報を含む機能情報の一覧の表示を制御する制御手段と、を有し、前記制御手段は、前記所定のネットワークプロトコルを用いた前記ネットワークを介したサービスの探索により、前記登録処理に従い既に登録された機能情報が見つかった場合には、当該探索の結果に従い前記一覧の表示を更新することを特徴とする。

本発明によれば、ネットワーク機器が提供する各種サービスについてユーザに最適なサービス一覧を提供し、ユーザが容易に選択・利用することを可能にできる。

Ｗｅｂ Ｉｎｔｅｎｔｓを実現するための全体構成を例示する図 Ｗｅｂ Ｉｎｔｅｎｔｓの基本動作を例示するシーケンス図 Ｗｅｂ Ｉｎｔｅｎｔｓの機能登録用のＨＴＭＬ文書を説明する図 クライアントからＵＡに返信されるＨＴＭＬ文書を説明する図 本発明の一実施例を示すシステムの構成を例示する図 ハードウェア構成図 ソフトウェア構成図 ソフトウェア構成図 サービステーブル、コンテンツ管理テーブル、Ｗｅｂ Ｉｎｔｅｎｔｓ設定を例示する図 実施例１におけるシーケンス図 実施例１のＥＣＭＡＳｃｒｉｐｔ、クライアント画面を例示する図 ローカルサービス探索パケット、応答パケットを例示する図 実施例１のサービス一覧画面を例示する図 実施例１におけるＵＡの処理の一例を示すフローチャート 実施例１におけるローカルサービス登録処理のＵＩ画面を例示する図 実施例２におけるシーケンス図 Ｗｅｂ Ｉｎｔｅｎｔｓ拡張情報応答パケットを例示する図 実施例２におけるＵＡの処理の一例を示すフローチャート 更新後のサービステーブルを例示する図 実施例２のサービス一覧画面を例示する図

以下、本発明を実施するための形態について図面を用いて説明する。

＜基本全体概念図＞
図１は、専用のＡＰＩを用いることなく任意のウェブサービス（または、ウェブアプリケーション）等と連携する仕組みの一例であるＷｅｂ Ｉｎｔｅｎｔｓ（ウェブインテンツ）を実現するための全体構成の一例を示す図である。

１０３はＷｅｂ Ｉｎｔｅｎｔｓサービス（以下、サービス）で、Ｉｎｔｅｎｔｓ技術を利用してサービスや機能を提供する。１０１はＷｅｂ Ｉｎｔｅｎｔｓクライアント（以下、クライアント）で、サービス１０３を利用する。１０６はＵｓｅｒＡｇｅｎｔ（ユーザエージェント、以下、ＵＡ）で、クライアント１０１からの要求をサービス１０３に渡し、サービスからの結果をクライアント１０１に渡す役割をする。ＵＡ１０６は、クライアント１０１及びサービス１０３の間で要求を実行したり、データを受け渡したりするための中継機能といえる。また、ＵＡ１０６には、サービス１０３の提供機能を呼び出すための機能情報がＷｅｂ Ｉｎｔｅｎｔｓとして登録される。

例えば、クライアント１０１は、データを管理し、サービスを呼び出すボタンなどを配置しているウェブサイトであり、ウェブサーバ上で動作する。また、ＵＡ１０６は、該ウェブサイトを表示するＷｅｂブラウザ（ウェブブラウザ）であり、パーソナルコンピュータ等の情報処理端末上で動作する。また、サービス１０３は、ＵＡ１０６を介してクライアント１０１が管理するデータを受け付けて処理するクライアント１０１の連携先のウェブサイトであり、ウェブサーバ上で動作する。

具体例として、Ｗｅｂ Ｉｎｔｅｎｔｓの仕組みをＳＮＳ（ソーシャル・ネットワーキング・サービス）に適用した場合には、次のようになる。クライアント１０１は、「いいね」「チェック」「シェア」といったソーシャルボタンを配置しているＷｅｂサイトとなる。また、ＵＡ１０６は、該ウェブサイトを表示するＷｅｂブラウザとなる。さらに、サービス１０３は、上記ソーシャルボタンの押下により、クライアント１０１で管理する写真やコメントの投稿を受け付けて閲覧サイトを構成する投稿先のＷｅｂサイトとなる。ここで、サービス１０３が機能を提供するにあたって、ユーザ認証やユーザによる操作が必要な場合、ＵＡ１０６上でユーザが操作を行う。

なお、ＵＡ１０６は、後述するサービスと連携するための機能を持つものであれば、Ｗｅｂブラウザ以外にも、情報処理端末で動作するオペレーティングシステム（ＯＳ）や任意のアプリケーションなどで実現することも可能である。ここで、情報処理端末の例としては、パーソナルコンピュータ、スマートフォン、タブレット型コンピュータ、カーナビゲーション装置などが挙げられる。

また、サービス１０３については、上述した投稿先サービスのようなインターネット上のサービス提供者以外にも、例えば情報処理端末が内蔵するカメラ、画像形成装置、スキャナなどといったデバイスもサービス提供者になり得る。また、ＵＡ１０６とネットワークで接続される画像形成装置、スキャナ、ネットワークカメラなどの周辺機器や、冷蔵庫やテレビといった家電製品などが提供するウェブサービスもサービス１０３に対応するサービス提供者になり得る。

また、クライアント１０１についても同様に、情報処理端末が内蔵するさまざまなデバイスやアプリケーション、その他にネットワーク上の周辺機器や家電製品、その上で動くプログラムなどもサービスを呼び出す利用者となり得る。

クライアント１０１とＵＡ１０６とサービス１０３は、これらの任意の組み合わせが、同一システム内で稼働することもある。具体的には、Ｗｅｂブラウザの同等の機能を有する文書編集アプリケーションなどが、クライアント１０１とＵＡ１０６とを含む構成として動作するといったことが考えられる。

なお、クライアント１０１、ＵＡ１０６、サービス１０３の機能を提供する各装置のハードウェア構成については、後述する図６に例示する。

＜Ｗｅｂ Ｉｎｔｅｎｔｓシーケンス図、および、データの例＞
図２は、Ｗｅｂ Ｉｎｔｅｎｔｓを利用したサービス提供に関する基本動作を説明するためのシーケンス図である。

Ｓ２０１において、ＵＡ１０６は、ユーザの操作に応じてサービス１０３にアクセスする。Ｓ２０２において、サービス１０３は、提供する機能をＵＡ１０６に登録してもらうための登録用マークアップを含むＨＴＭＬ応答をＵＡ１０６に返信する。ここで、図３の例を用いて、サービス１０３からＵＡ１０６に返信されるＨＴＭＬ応答の中身について説明する。

図３は、Ｗｅｂ Ｉｎｔｅｎｔｓの機能登録用のＨＴＭＬ文書を説明する図である。
図３において、＜ｉｎｔｅｎｔ＞タグには、提供機能を特定する情報が記載されている。Ａｃｔｉｏｎは、提供機能のカテゴリを示している。Ｔｙｐｅは、提供機能が扱えるデータなどの種類を示している。ｈｒｅｆは、提供機能の接続先（ＵＲＬ）を示している。ｔｉｔｌｅは、提供機能のタイトルを示している。また、ｄｉｓｐｏｓｉｔｉｏｎは呼び出された提供機能がどのように表示されるかを示す。

図３の例では、提供機能のカテゴリが"ｓｈａｒｅ（共有）"であり、扱えるデータなどの種類が"あらゆるフォーマット（＊）の画像データ（ｉｍａｇｅ）"である。また、接続先は"ｓｈａｒｅ．ｈｔｍｌ"であり、タイトルは"Ｓｈａｒｅ ｉｍａｇｅ ｕｓｉｎｇ ｅ−ｍａｉｌ"である。さらに、この機能が、ＵＡ１０６を介して別ウィンドウ（Ｗｉｎｄｏｗ）で表示されることを示している。

なお、提供機能のカテゴリには、例えば、Ｓｈａｒｅ、Ｅｄｉｔ、Ｖｉｅｗ、Ｐｉｃｋ、Ｓｕｂｓｃｒｉｂｅ、Ｓａｖｅ、Ｂｒｏｗｓｅｒ、Ｐｒｉｎｔ等がある。Ｓｈａｒｅはデータの共有、Ｅｄｉｔはデータの編集、Ｖｉｅｗはデータの閲覧、Ｐｉｃｋはデータを外部サービスから取得、Ｓｕｂｓｃｒｉｂｅはデータの購読、Ｓａｖｅはデータの保存、Ｐｒｉｎｔはデータの印刷を示す。

ＵＡ１０６は、Ｓ２０２の応答を受信すると、ユーザに対してサービス１０３の提供機能をＵＡ１０６に登録するか否か確認する。例えば、ＵＡ１０６がＷｅｂブラウザであれば、ポップアップウィンドウを表示させユーザに登録の可否の選択を促す。ユーザがこの提供機能をＷｅｂ Ｉｎｔｅｎｔｓとして登録することを選択すると、ＵＡ１０６は、Ｓ２０２で受信した情報を内部に記憶する登録処理を実行する。具体的には、この情報は、ＵＡ１０６が動作する情報処理端末の記憶領域に記憶され、ＵＡ１０６にＷｅｂ Ｉｎｔｅｎｔｓとして登録される。

Ｓ２０３において、ＵＡ１０６は、ユーザの操作に応じて、クライアント１０１にアクセスする。Ｓ２０４において、クライアント１０１は、サービス１０３の提供機能（Ｗｅｂ Ｉｎｔｅｎｔｓ）を利用することが記載されたＨＴＭＬ文書を、ＵＡ１０６へ返信する。例えば、クライアント１０１としてのＷｅｂサイトで、画像と「共有」ボタンが表示されている場合に、該Ｗｅｂサイトは、図４に示すようなＥＣＭＡＳｃｒｉｐｔを含むＨＴＭＬ文書をＵＡ１０６へ返す。ここで、図４の例を用いて、クライアント１０１からＵＡ１０６に返信されるＨＴＭＬ文書の中身について説明する。

図４は、クライアント１０１からＵＡ１０６に返信されるＨＴＭＬ文書を説明する図である。
図４に示すように、ＥＣＭＡＳｃｒｉｐｔは、ＨＴＭＬ内のＩＤ「ｓｈａｒｅ−ｐｈｏｔｏ」を持つボタンがクリックされると指定された無名関数を実行することを示している。無名関数は、まず、新規のＩｎｔｅｎｔオブジェクトを作成し、これを引数にしてｓｔａｒｔＡｃｔｉｖｅｔｙ（）関数を呼び出す。この関数を実行すると、ＵＡ１０６は、自身に登録されているＷｅｂ Ｉｎｔｅｎｔｓの中から、指定されたＩｎｔｅｎｔオブジェクトのＡｃｔｉｏｎとＴｙｐｅが一致するものを抽出し、一覧表示させることでユーザに選択を要求する。また、無名関数内で呼び出しているｇｅｔＩｍａｇｅＦｒｏｍ（）関数を実行することにより、クライアント１０１が持つ画像データを取得する。

クライアント１０１は、Ｓ２０４にて、例えば、画像と「共有」ボタンと、図４に示すＥＣＭＡＳｃｒｉｐｔを含むＨＴＭＬ文書をＵＡ１０６に返信する。ＵＡ１０６は、クライアント１０１からＨＴＭＬ応答を受け取ると、ユーザへ受信した内容を表示する。Ｓ２０５において、ＵＡ１０６は、ユーザによる表示画面上の「共有」ボタンの押下を検出すると、上述したようにＷｅｂ Ｉｎｔｅｎｔｓ起動用のＥＣＭＡＳｃｒｉｐｔを実行し、Ｓ２０６において、クライアント１０１が持つ画像データを取得する。また、上記Ｓ２０５で「共有」ボタン押下を検出した際に、ＵＡ１０６は、自身に登録されているＷｅｂ Ｉｎｔｅｎｔｓの一覧を表示する。この一覧からユーザによるサービス１０３の提供機能を示すＷｅｂ Ｉｎｔｅｎｔｓの選択を検出すると、Ｓ２０７において、ＵＡ１０６は、該選択されたサービス１０３へＨＴＴＰ要求を送信する。その際、ＵＡ１０６は、送信データに、図４に示したＥＣＭＡＳｃｒｉｐｔが作成したＩｎｔｅｎｔオブジェクトの内容を含める。

Ｓ２０８において、サービス１０３は、上記Ｓ２０７のＨＴＴＰ要求からＩｎｔｅｎｔオブジェクトを取り出し、ＵＡ１０６を介してユーザと相互作用しながら、選択された提供機能（ここではクライアント１０１の画像データの「共有」）の利用を実現する。例えば、ユーザが画像、共有ボタンがあるＷｅｂサイトに訪れ、共有ボタンを押下すると、ポップアップウィンドウにサービス一覧が表示される。そこで、Ｗｅｂメールサービスを選択したとすると、画像データを添付した新規メールが作成され、ユーザにより電子メールを送信することが出来る。

サービス１０３は、処理が終了すると、Ｓ２０９において、処理結果をクライアント１０１に伝えるＥＣＭＡＳｃｒｉｐｔを含む応答を返す。Ｓ２１０において、ＵＡ１０６は、Ｓ２０９の応答中に含まれるＥＣＭＡＳｃｒｉｐｔを実行し、Ｓ２０５のｓｔａｒｔＡｃｔｉｖｅｔｙ（）関数の引数で指定されたコールバック関数ｏｎＳｕｃｃｅｓｓ（）を呼び出す。Ｓ２１１において、ＵＡ１０６は、コールバック関数ｏｎＳｕｃｃｅｓｓ（）によってクライアント１０１へ処理結果を返す。

図２のシーケンスにより、Ｗｅｂメール機能を利用する例について説明する。まず、ユーザがＷｅｂブラウザ（ＵＡ１０６）で、写真データを管理するウェブストレージ（クライアント１０１）のＷｅｂ Ｉｎｔｅｎｔｓの呼び出しボタンが用意されたサイトに訪れ、当該ボタンを押下する。すると、Ｗｅｂブラウザ（ＵＡ１０６）が登録サービス一覧を含むポップアップウィンドウを表示する。そこで、ユーザがＷｅｂメール機能を選択したとすると、該機能を提供するＷｅｂサイト（サービス１０３）が別ウィンドウで表示され、処理結果として、そのウィンドウ上では写真データを添付した新規メールが作成されている。

以上の処理により、クライアント１０１は、ＵＡ１０６を介して、サービス１０３が提供するＷｅｂ Ｉｎｔｅｎｔｓの機能（この例では画像の「共有」）を呼び出すことが可能となる。

＜本実施形態のネットワーク、周辺機器、及び、ネットワークサービスの構成例＞
図５は、本発明の一実施例を示すシステムの構成の一例を示す図である。
図５に示すように、本システムでは、ＬＡＮ５０８で接続された情報処理端末５３０と、ローカルサーバ５２１であるプリンタが、ルータ５０７越しにＷＡＮ５０６に接続されている。さらに、本システムは、インターネット５０５に接続される、１台以上のクライアント１０１の機能を提供するサーバ５１０、および、１台以上のサービス１０３を提供するサーバ５２０を有する。サーバ５２０とサーバ５１０は、インターネット５０５経由でサービスを提供している。情報処理端末５３０は、ルータ５０７越しにＷＡＮ５０６、インターネット５０５を介してサーバ５１０、およびサーバ５２０と接続される。

なお、本実施例において、先に説明したサービス１０３に対応するサービス（サービス、ローカルサービス）を、サーバ５２０、ローカルサーバ５２１等で提供している。しかし、３台以上のサーバでサービス機能を提供する場合においても、本発明は適用可能である。

サーバ５１０は、先に説明したクライアント１０１の機能を提供するものであり、サービス、ローカルサービスへの処理要求を作成する。サーバ５２０、ローカルサーバ５２１は、それぞれ先に説明したサービス１０３にあたるサービス、ローカルサービス（ＬＡＮ）の機能を提供するＷｅｂアプリケーションを備えており、Ｗｅｂ Ｉｎｔｅｎｔｓ技術を利用してサービスや機能を提供する。

上述したように、ローカルサーバ５２１は、ＬＡＮ５０８に接続されたサーバである。本実施例においてローカルサーバ５２１がプリンタである例を示したが、Ｗｅｂ Ｉｎｔｅｎｔｓサービス機能を有する他の形態、例えば汎用コンピュータや、情報家電等でもよい。また、ＬＡＮ５０８は、有線であっても無線であってもよい。

情報処理端末５３０は、先に説明したＵＡ１０６の機能を提供するＷｅｂブラウザがインストールされているコンピュータである。さらに、情報処理端末５３０は、機器内にローカルサービスの機能を提供するＷｅｂアプリケーションを備えるものとする（後述する図７Ｂ（ｄ）のローカルサービス（機器内サービス）参照）。なお、サーバ５１０、サーバ５２０、情報処理端末５３０は、汎用コンピュータの構成を有する。

本実施例では、情報処理端末５３０を汎用コンピュータとして示したが、他の形態の情報処理端末、タブレット型コンピュータ、スマートフォンなどで処理された場合も、同様に本発明を適用可能である。

図６は、本実施例のシステムを構成する機器のハードウェアブロック図である。
図６（Ａ）は、サーバ５１０、５２０及び情報処理端末５３０のハードウェア構成の一例を示すブロック図である。

図６（Ａ）に示すように、ＣＰＵ６０１、ＲＡＭ６０２、ＲＯＭ６０３、ネットワークインタフェース（Ｎｅｔｗｏｒｋ Ｉ／Ｆ）６０５、ハードディスクドライブ（ＨＤＤ）６０６がシステムバス６０９を介して互いに通信可能に接続されている。また、ＬＣＤ等の表示装置６０７、キーボード等の入力装置６０４、及びマウスやタッチパネル等のポインティングデバイス６０８も、システムバス６０９を介して互いに通信可能に接続されている。

ＲＯＭ６０３或いはＨＤＤ６０６には、オペレーティングシステムや各種アプリケーションプログラム等の制御プログラムが格納されている。ＣＰＵ６０１は、前記制御プログラムを必要に応じてＲＯＭ６０３或いはＨＤＤ６０６からＲＡＭ６０２上へ読み出して実行することで、コンピュータとしての機能を発揮する。また、ＣＰＵ６０１は、表示装置６０７を介して各種情報の表示を行うと共に、入力装置６０４やポインティングデバイス６０８からユーザ指示等を受け付ける。更に、ＣＰＵ６０１は、ネットワークインタフェース６０５を介して他の装置との通信を行う。

図６（Ｂ）は、ローカルサーバ５２１のハードウェア構成の一例を示すブロック図である。図６（Ｂ）では一例として複合機（ＭＦＰ；ＭｕｌｔｉＦｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）の構成を示す。

図６（Ｂ）に示すように、ＣＰＵ６１１、ＲＡＭ６１２、Ｒ１Ｍ６０３、ネットワークインタフェース（Ｎｅｔｗｏｒｋ Ｉ／Ｆ）６１５、ハードディスクドライブ（ＨＤＤ）６１６がシステムバス６１９を介して互いに通信可能に接続されている。また、操作部６１４、スキャナ部６１７、及びプリンタ部６１８も、システムバス６１９を介して互いに通信可能に接続されている。

ＲＯＭ６１３或いはＨＤＤ６１６には、オペレーティングシステムや各種アプリケーションプログラム等の制御プログラムが格納されている。ＣＰＵ６１１は、前記制御プログラムを必要に応じてＲＯＭ６１３或いはＨＤＤ６１６からＲＡＭ６１２上へ読み出して実行することで、複合機としての機能を発揮する。また、ＣＰＵ６１１は、操作部６１４を介して各種情報の表示を行うと共に、操作部６１４からユーザ指示等を受け付ける。更に、ＣＰＵ６１１は、ネットワークインタフェース６１５を介して他の装置との通信を行う。

操作部６１４は、ボタン及び表示装置、或いは、タッチパネル入力付き液晶表示画面、或いはその組み合わせにより、６１１からのユーザへの情報表示や、ユーザの入力をＣＰＵ６１１へと通知する。

スキャナ部６１７は、原稿の画像を読み取り、ユーザからの指示により、その原稿画像に応じた画像データを、プリンタ部６１８に出力する、或いは、ＨＤＤ６１６等に保存する。さらに、スキャナ部６１７は、ネットワークＩ／Ｆ６１５を介してネットワークに接続された外部装置に画像データを送信することも可能である。

プリンタ部６１８は、スキャナ部６１７により読み取られた原稿や、ＨＤＤ６１６に格納された画像データを印刷する。さらに、プリンタ部６１８は、ネットワークに接続された外部装置からの印刷ジョブを印刷する。

また、ＣＰＵ６１１が、ネットワーク上の他の情報機器とネットワークＩ／Ｆ６１５を介して相互通信し、ウェブプリント機能などのローカルサービス（ＬＡＮ）の提供を制御する。なお、装置内に、サービスを提供するハードウェア構成として、もう１つのＣＰＵなどを用いる設計も可能である。

図７Ａ、図７Ｂは、サーバ５１０、５２０、ローカルサーバ５２１及び情報処理端末５３０のソフトウェア構成の一例を示すブロック図である。

図７Ａ（ａ）は、クライアント１０１の機能を提供するサーバ５１０のソフトウェアの構成の一例を示す。
サーバ５１０において、Ｗｅｂアプリケーション７００および各処理部は、サーバ５１０のＨＤＤ６０６に保存されたファイルとして存在する。これらは、実行時にＯＳやその各処理部を利用する他の処理部によってＲＡＭ６０２にロードされ実行されるプログラムモジュールである。

Ｗｅｂアプリケーション７００は、例えば画像データの保管などのストレージサービスを提供するアプリケーションである。Ｗｅｂアプリケーション７００は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストに応答して処理を実行するプログラムとして実装される。Ｗｅｂアプリケーション７００は、Ｉｎｔｅｎｔ処理要求作成部７０２、プレゼンテーション部７０３、コンテンツ管理部７０４を有する。

Ｉｎｔｅｎｔ処理要求作成部７０２は、Ｉｎｔｅｎｔの処理要求であるＥＣＭＡＳｃｒｉｐｔを作成するソフトウェアモジュールである。プレゼンテーション部７０３は、通信部７０１を介して受け取ったページ取得要求などに応じてＨＴＭＬ文書を作成するソフトウェアモジュールである。コンテンツ管理部７０４は、プレゼンテーション部７０３からの要求に応じてデータベースサービス部７０５によりＨＤＤ６０６からコンテンツを取得したり、格納したりするソフトウェアモジュールである。

データベースサービス部７０５は、他の処理部からの要求に応じて、ＨＤＤ６０６へのコンテンツの格納と取り出しを行うソフトウェアモジュールである。また、データベースサービス部７０５は、後述する図８（Ｃ）に示すようなコンテンツ管理テーブル８２０を管理する。また、データベースサービス部７０５は、サーバ５１０と別の機器上にあってもよい。以上示したような、Ｗｅｂアプリケーション７００は、サーバ５１０のＣＰＵ６０１が、ＨＤＤ６０６等からプログラムをＲＡＭ６０２上へ読み出して実行することにより実現されるものである。

図７Ａ（ｂ）は、サービス１０３に対応するサービスを提供するサーバ５２０のソフトウェアの構成の一例を示す。
サーバ５２０において、Ｗｅｂアプリケーション７３０および各処理部は、サーバ５２０のＨＤＤ６０６に保存されたファイルとして存在する。これらは、実行時にＯＳやその各処理部を利用する他の処理部によってＲＡＭ６０２にロードされ実行されるプログラムモジュールである。

Ｗｅｂアプリケーション７３０は、画像データの保管などのストレージサービスを提供するアプリケーションである。また、Ｗｅｂアプリケーション７３０は、Ｉｎｔｅｎｔｓ技術を利用してサービスを提供する機能を有する。さらに、Ｗｅｂアプリケーション７３０は、ＨＴＴＰリクエストに応答して処理を実行するプログラムとして実装される。Ｗｅｂアプリケーション７３０は、Ｉｎｔｅｎｔ処理部７３２、プレゼンテーション部７３３、コンテンツ処理部７３４を有する。

Ｉｎｔｅｎｔ処理部７３２は、Ｉｎｔｅｎｔオブジェクトを解析し、処理するソフトウェアモジュールである。プレゼンテーション部７３３は、通信部７３１を介して受け取ったページ取得要求などに応じてＨＴＭＬ文書を作成するソフトウェアモジュールである。コンテンツ処理部７３４は、Ｉｎｔｅｎｔ処理部７３２からの指示を受けて、コンテンツに対して処理をするソフトウェアモジュールである。例えば、画像データを編集したり、要求に応じてデータベースサービス部７３５を介してＨＤＤ６０６へコンテンツを格納したりするソフトウェアモジュールである。

データベースサービス部７３５は、他の処理部からの要求に応じて、データの格納と取り出しを行う。また、データベースサービス部７３５は、サーバ５２０と別の機器上にあってもよい。以上示したような、Ｗｅｂアプリケーション７３０は、サーバ５２０のＣＰＵ６０１が、ＨＤＤ６０６等からプログラムをＲＡＭ６０２上へ読み出して実行することにより実現されるものである。

図７Ａ（ｃ）は、サービス１０３に対応するローカルサービス（ＬＡＮ）を提供するローカルサーバ５２１のソフトウェアの構成の一例を示す。
ローカルサーバ５２１において、Ｗｅｂアプリケーション７４０および各処理部は、ローカルサーバ５２１のＨＤＤ６１６に保存されたファイルとして存在する。これらは、実行時にＯＳやその各処理部を利用する他の処理部によってＲＡＭ６１２にロードされ実行されるプログラムモジュールである。

Ｗｅｂアプリケーション７４０は、画像データの印刷サービスを提供するアプリケーションである。また、Ｗｅｂアプリケーション７４０は、Ｉｎｔｅｎｔｓ技術を利用してサービスを提供する機能を有する。さらに、Ｗｅｂアプリケーション７４０は、ＨＴＴＰリクエストに応答して処理を実行するプログラムとして実装される。Ｗｅｂアプリケーション７４０は、Ｉｎｔｅｎｔ処理部７４２、プレゼンテーション部７４３、コンテンツ処理部７４４、探索処理部７４６を有する。

Ｉｎｔｅｎｔ処理部７４２は、Ｉｎｔｅｎｔオブジェクトを解析し、処理するソフトウェアモジュールである。プレゼンテーション部７４３は、通信部７４１を介して受け取ったページ取得要求などに応じてＨＴＭＬ文書を作成するソフトウェアモジュールである。コンテンツ処理部７４４は、Ｉｎｔｅｎｔ処理部７４２からの指示を受けて、コンテンツに対して処理をするソフトウェアモジュールである。例えば、コンテンツ処理部７４４は、画像の印刷要求に応じて印刷サービス部（不図示）を介してコンテンツを印刷するソフトウェアモジュールである。

データベースサービス部７４５は、他の処理部からの要求に応じて、データの格納と取り出しを行う。また、データベースサービス部７４５は、ローカルサーバ５２１と別の機器上にあってもよい。探索処理部７４６は、後述する情報処理端末５３０の探索部７５９からのＳＳＤＰ（Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）などの所定のネットワークプロトコルを用いた探索要求を処理する。なお、探索処理に用いるネットワークプロトコルは、ＳＳＤＰに限定されるものではない。

以上示したような、Ｗｅｂアプリケーション７４０は、ローカルサーバ５２１のＣＰＵ６１１が、ＨＤＤ６１６等からプログラムをＲＡＭ６１２上へ読み出して実行することにより実現されるものである。

図７Ｂ（ｄ）は、ＵＡ１０６の機能を提供する情報処理端末５３０のソフトウェアの構成の一例を示す。
情報処理端末５３０において、Ｗｅｂブラウザ７５０、Ｗｅｂアプリケーション７６０および各処理部は、情報処理端末５３０のＨＤＤ６０６に保存されたファイルとして存在する。これらは、実行時にＯＳやその各処理部を利用する他の処理部によってＲＡＭ６０２にロードされ実行されるプログラムモジュールである。

Ｗｅｂブラウザ７５０は、通信部７５１、解析部７５２、表示部７５３、サービス情報入出力部７５４、サービス情報管理部７５５、サービス判定部７５６、スクリプト処理部７５７、サービス情報記憶部７５８を有する。

通信部７５１は、他の処理部からの要求を受けてＨＴＴＰのリクエストメッセージを外部機器に送信する。また、通信部７５１は、外部機器からのＨＴＴＰレスポンスメッセージを受信し、解析部７５２にレスポンスの内容を通知するソフトウェアモジュールである。

解析部７５２は、ＨＴＭＬ文書を解析するソフトウェアモジュールである。また、解析部７５２は、Ｉｎｔｅｎｔ処理要求であるＥＣＭＡＳｃｒｉｐｔも解析する。表示部７５３は、ＨＴＭＬ文書をレンダリングするソフトウェアモジュールである。また、表示部７５３は、他の処理部の要求に応じて、サービスの選択を受け付ける画面を表示する。

サービス情報入出力部７５４は、解析部７５２で解析されたＥＣＭＡＳｃｒｉｐｔから、Ｗｅｂ Ｉｎｔｅｎｔｓスクリプトの「アクション（Ａｃｔｉｏｎ）」やデータタイプを示す「タイプ（Ｔｙｐｅ）」の受信解析や送信データの生成を行う。サービス情報管理部７５５は、後述のサービス情報記憶部７５８から登録済みのサービスを特定する情報を取得したり、格納したりするソフトウェアモジュールである。

サービス判定部７５６は、実行中のＷｅｂ Ｉｎｔｅｎｔｓ処理において、Ｉｎｔｅｎｔｓスクリプトの「アクション（Ａｃｔｉｏｎ）」および「タイプ（Ｔｙｐｅ）」から探索の必要等を判定する。該判定の際、サービス判定部７５６は、図８（Ｄ）に示すようなＷｅｂ Ｉｎｔｅｎｔｓ設定を用いる（詳細は後述する）。スクリプト処理部７５７がサービス判定部７５６で探索が必要だと判定した場合には、探索部７５９が探索処理を行う。

サービス情報記憶部７５８は、データを管理し、サービス情報管理部７５５からの要求に応じてデータの格納と取り出しを行う。また、サービス情報記憶部７５８は、後述する図８（Ａ）や図８（Ｂ）に示すようなサービステーブル８００を保持する。探索部７５９は、スクリプト処理部７５７からの探索要求を受け付け、ＬＡＮ５０８上のローカルサービスの探索を行う。

なお、情報処理端末５３０は、ローカルサービスの機能を提供するＷｅｂアプリケーション７６０を有する（ローカルサービス（機器内サービス））。Ｗｅｂアプリケーション７６０は、Ｗｅｂアプリケーション７３０と同様である。即ち、Ｉｎｔｅｎｔ処理部７４２、プレゼンテーション部７４３、コンテンツ処理部７４４、探索処理部７４６、データベースサービス部７４５は、それぞれ、Ｉｎｔｅｎｔ処理部７６２、プレゼンテーション部７６３、コンテンツ処理部７６４、探索処理部７６６、データベースサービス部７６５と同様である。なお、コンテンツ処理部７６４は、例えば、画像データを編集したり、要求に応じてデータベースサービス部７６５を介してＨＤＤ６０６へコンテンツを格納したりするソフトウェアモジュールである。

以上示したような、Ｗｅｂブラウザ７５０、Ｗｅｂアプリケーション７６０は、情報処理端末５３０のＣＰＵ６０１が、ＨＤＤ６０６等からプログラムをＲＡＭ６０２上へ読み出して実行することにより実現されるものである。

図８は、サービステーブル８００、コンテンツ管理テーブル８２０、Ｗｅｂ Ｉｎｔｅｎｔｓ設定８３０の一例を示す図である。
図８（Ａ）、図８（Ｂ）は、情報処理端末５３０のＷｅｂブラウザ７５０が自身に登録されたサービスを管理するためにサービス情報記憶部７５８に保持するサービステーブル８００の一例である。図８（Ａ）と図８（Ｂ）は、サービステーブル８００の別の登録例を示している。

図８（Ａ）、図８（Ｂ）に示す、サービステーブル（サービステーブル）８００は、情報処理端末５３０のサービス情報記憶部７５８で保持され、サービス情報管理部７５５によって管理される。サービステーブル８００には、サービスが提供する機能を呼び出すための機能情報（８０１〜８０５）、及び、本実施例の特徴的な情報８０６〜８０７が登録されている。以下、詳細に説明する。

８０１はＳｅｒｖｉｃｅＩＤであり、Ｗｅｂブラウザ７５０内でサービスを一意に識別するためのＩＤである。８０２はＡｃｔｉｏｎであり、サービス、ローカルサービスが提供する提供機能のカテゴリ（サービスがどのような機能、サービスを提供するか）を示す。８０３はＴｙｐｅであり、Ａｃｔｉｏｎ８０２で扱えるデータなどの種類（データの形式）を示す。８０４はｈｒｅｆであり、サービス、ローカルサービスのＵＲＬを示す。８０５はｔｉｔｌｅであり、サービス、ローカルサービスのタイトルを示す。

また、８０６はローカルサービスＦｌａｇであり、図２のＳ２０１〜Ｓ２０２に示したようにサーバから登録（Ｒｅｇｉｓｔｒａｔｉｏｎ）されたサービスと、探索されたサービスを識別するための情報である。ローカルサービスＦｌａｇ８０６がＯＮのサービスは、探索されたサービスに対応する。なお、ＬＡＮ上で探索されたローカルサービスのローカルサービスＦｌａｇ８０６には「ＯＮ（ＬＡＮ）」が格納される。また、情報処理端末５３０の機器内で探索されたローカルサービスのローカルサービスＦｌａｇ８０６には「ＯＮ（機器内サービス）」が格納される。また、ユーザにより手動で登録されたローカルサービスのローカルサービスＦｌａｇ８０６には「ＯＮ（マニュアル設定サービス）が格納される。

８０７は、探索時に探索応答情報、または、探索後にＷｅｂ Ｉｎｔｅｎｔｓ拡張情報などで取得したサービス拡張情報を示す。なお、ユーザにより手動で登録されたローカルサービスの場合、登録時にユーザにより入力された情報が格納される。

情報処理端末５３０は、Ｗｅｂブラウザ７５０を介して、上述したようなサービステーブル８００を参照することで、各サービス、ローカルサービスへＩｎｔｅｎｔの処理要求を出すことが可能である。

図８（Ｃ）は、サーバ５１０のＷｅｂアプリケーション７００が扱う画像データを管理するコンテンツ管理テーブル８２０の一例である。
コンテンツ管理テーブル８２０は、サーバ５１０内のＨＤＤ６０６で保持され、データベースサービス部７０５によって管理される。８２１はＩｍａｇｅＩＤであり、Ｗｅｂアプリケーション７００内で画像データを一意に識別するためのＩＤである。８２２はＦｉｌｅであり、画像データのファイル名を表している。サーバ５１０は、本テーブル参照することでコンテンツ管理部７０４により、画像データをＨＤＤ６０６から取得することが可能となる。

図８（Ｄ）は、Ｗｅｂ Ｉｎｔｅｎｔｓ設定の一例である。
８３１は設定ＩＤであり、Ｗｅｂブラウザ７５０のサービス判定部７５６が判定条件を一意に決定するためのＩＤである。８３２はＡｃｔｉｏｎであり、サービス、ローカルサービスが提供する提供機能のカテゴリ（サービスがどのような機能、サービスを提供するか）を示す。８３３はＴｙｐｅであり、Ａｃｔｉｏｎ８３２で扱えるデータなどの種類（データの形式）を示す。Ｔｙｐｅの仕様は、ＲＦＣ５３２２、ＲＦＣ８２２、ＲＦＣ２８２２のＣｏｎｔｅｎｔ−Ｔｙｐｅで表される。８３４はローカルサービスＦｌａｇであり、ローカルサービスＦｌａｇ８０６と同じＦｌａｇを表す。

サービステーブル８００に、Ａｃｔｉｏｎ８３２、Ｔｙｐｅ８３３、及びローカルサービスＦｌａｇ８３４が一致するサービスが登録されている場合、サービス判定部７５６は、後述するローカルサービス探索処理８３６、ローカルサービス登録処理８３７、ローカルサービス更新処理８３８を設定に従って行う。

なお、Ａｃｔｉｏｎ８３２、Ｔｙｐｅ８３３が同一の設定が複数登録されている場合は、サービス判定部７５６は、該Ａｃｔｉｏｎ８３２、Ｔｙｐｅ８３３が同一の設定のうち、同一Ａｃｔｉｏｎ，Ｔｙｐｅでの優先度８３５の優先順位が最も高い設定に基づいて、処理（探索、登録、更新）の実行の有無を判定する。即ち、同一Ａｃｔｉｏｎ，Ｔｙｐｅでの優先度８３５の値は、同一のＡｃｔｉｏｎ８３２，Ｔｙｐｅ８３３の設定がＷｅｂ Ｉｎｔｅｎｔｓ設定８３０に複数登録されている場合に、どの設定を優先するかを示す。

８３６はローカルサービス探索処理であり、Ａｃｔｉｏｎ８３２、Ｔｙｐｅ８３３、ローカルサービスＦｌａｇ８３４が一致するサービスが、サービステーブル８００に登録済みの場合に、ローカルサービス探索処理を行うか、行わないかを判定する設定を示す。８３７はローカルサービス登録処理であり、ローカルサービス探索処理を行った場合に、探索結果をサービステーブル８００に登録するか、しないかを判定する設定を示す。８３８はローカルサービス更新処理であり、ローカルサービス探索処理を行わなかった場合に、ローカルサービスの拡張探索処理を行うか、行わないかを判定するための設定を示す。なお、ローカルサービス更新処理８３８の詳細は実施例２で説明する。

即ち、図８（Ｄ）に示すＷｅｂ Ｉｎｔｅｎｔｓ設定では、サービステーブル８００へのローカルサービスの登録状態を上限として、"ローカルサービス探索を行う"又は"ローカルサービス探索を行わない"ことを設定可能である。また、Ｗｅｂ Ｉｎｔｅｎｔｓ設定では、ローカルサービス探索を行う場合における、探索結果のサービステーブル８００への登録の有無を設定可能である。さらに、Ｗｅｂ Ｉｎｔｅｎｔｓ設定では、ローカルサービス探索を行わない場合における、ローカルサービスの状態を含むサービス拡張情報の更新処理の実行の有無を設定可能である。

これらＷｅｂ Ｉｎｔｅｎｔｓ設定の設定値は、全ての項目が含まれている必要は無い。設定値がある項目のみサービス判定部７５６での判定処理で利用される（後述する図１３のＳ１３０５参照）。
なお、リクエストを処理可能なサービスがサービステーブル８００に１つも登録されていない場合や、リクエストに対応するＷｅｂ Ｉｎｔｅｎｔｓ設定が存在しない場合には、サービス判定部７５６は、ローカルサービスを探索し、該探索されたローカルサービスを登録すると判定するものとする。

以下、図９のシーケンス図を用いて、情報処理端末５３０がサーバ５１０により提供されるＷｅｂサイトにアクセスして、ローカルサーバ５２１により提供されるローカルサービスに、Ｉｎｔｅｎｔの処理要求を仲介する動作について説明する。
図９は、実施例１におけるＷｅｂ Ｉｎｔｅｎｔｓを利用したサービス提供に関する動作の一例を示すシーケンス図である。なお、図９では、ローカルサービス（ＬＡＮ）を探索し、処理を依頼するシーケンスのみを図示しているが、ローカルサービス（機器内サービス）についても同様である。

情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９００で、サーバ５２０のＷｅｂアプリケーション７３０からＲｅｇｉｓｔｒａｔｉｏｎされたサービスを、サービス情報記憶部７５８に登録する。例えば、この時点のサービステーブル８００を図８（Ｂ）に示した状態として以下を説明する。

情報処理端末５３０のＷｅｂブラウザ７５０は、アドレスバーなどにサーバ５１０（クライアント）のＷｅｂアプリケーション７００のＵＲＬを入力する等のユーザ操作を受け付けることで、Ｓ９０１の処理を実行する。Ｓ９０１において、Ｗｅｂブラウザ７５０は、通信部７５１を介して、クライアント１０１として機能するサーバ５１０に、ＨＴＴＰのリクエストメッセージとしてページの要求を送信する。

サーバ５１０のＷｅｂアプリケーション７００は、情報処理端末５３０から送信された上記ページの要求を受信すると、Ｓ９０２の処理を実行する。Ｓ９０２において、サーバ５１０のＷｅｂアプリケーション７００は、ページの作成を行う。Ｓ９０３において、サーバ５１０のＷｅｂアプリケーション７００は、上記Ｓ９０２で作成したページを、情報処理端末５３０のＷｅｂブラウザ７５０へＨＴＴＰのレスポンスメッセージとして応答する（Ｉｎｖｏｃａｔｉｏｎ処理）。

情報処理端末５３０のＷｅｂブラウザ７５０は、サーバ５１０から応答された上記ページを受信すると、Ｓ９０４の処理を実行する。Ｓ９０４において、情報処理端末５３０のＷｅｂブラウザ７５０の表示部７５３は、上記受信したページを表示する。具体的には、解析部７５２が、上記ページに対応するＨＴＭＬ文書を解析し、表示部７５３がレンダリングすることで上記受信したページを表示する。ここで、Ｓ９０４で表示する画面について、図１０を用いて説明する。

図１０は、図９のＳ９０４で表示する画面を説明するための図である。
図１０（Ａ）は、Ｓ９０２でサーバ５１０のＷｅｂアプリケーション７００によって作成され、Ｓ９０４で情報処理端末５３０のＷｅｂブラウザ７５０が表示するＨＴＭＬ内に記述されたＥＣＭＡＳｃｒｉｐｔの一例を示す。なお、図１０（Ａ）の内容は、図４で説明したものと同様のため、詳細な説明は省略する。

図１０（Ｂ）は、Ｓ９０４で情報処理端末５３０のＷｅｂブラウザ７５０が表示する画面の一例を示す。
画面１０００は、Ｗｅｂブラウザ７５０の表示部７５３が表示する画面である。１００１〜１００２は"ｉｍａｇｅ００１.ｐｎｇ"〜"ｉｍａｇｅ００２.ｐｎｇ"の画像データであり、１００３〜１００４はこれらの画像を選択するためのラジオボタンである。

１００５は「印刷する」ボタンであり、ラジオボタン１００３〜１００４で選択されている画像データを、サービスへ渡し印刷するためのボタンである。ここでは、「印刷する」ボタン１００５には、ＨＴＭＬ内のＩＤ「Ｐｒｉｎｔ―ｐｈｏｔｏ」が割り当てられているものとする。情報処理端末５３０のＷｅｂブラウザ７５０は、「印刷する」ボタン１００５が押下されたことを検知すると、図１０（Ａ）のＥＣＭＡＳｃｒｉｐｔを実行する。

以下、図９のシーケンス図の説明に戻る。
上記Ｓ９０４で表示された画面において、ユーザにより「印刷する」ボタン１００５（図１０（Ｂ））が押下されたことを検知すると、ＵＡ１０６である情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９０５の処理を実行する。Ｓ９０５において、情報処理端末５３０のＷｅｂブラウザ７５０は、表示部７５３に表示するサービスの探索実行判定処理を行う。

サービスの探索実行判定処理では、まず、情報処理端末５３０のＷｅｂブラウザ７５０は、サービステーブル８００（ここでは図８（Ｂ）の状態）内の登録済みのサービスと、Ｗｅｂ Ｉｎｔｅｎｔｓ設定（例えば図８（Ｄ））を参照し、表示部７５３に一覧表示する、上記押下された「印刷する」ボタン１００５に対応するＡｃｔｉｏｎの処理が可能なローカルサービスを探索するか否かを判定する。このＳ９０５の処理は、「印刷」などＳ９０４で指定されたＷｅｂ ＩｎｔｅｎｔｓのＡｃｔｉｏｎの処理が可能なサービスの探索を行うか否かを判定するためのものである。ここで、図１３を参照して、Ｓ９０５の処理を含む情報処理端末５３０のＷｅｂブラウザ７５０の処理について詳細に説明する。

図１３は、実施例１におけるＵＡ１０６である情報処理端末５３０のＷｅｂブラウザ７５０の処理の一例を示すフローチャートである。この処理は、情報処理端末５３０のＷｅｂブラウザ７５０が実行する処理に対応し、図９のＳ９０４で指定されたＷｅｂ ＩｎｔｅｎｔｓのＡｃｔｉｏｎの処理が可能なサービスを探索して表示するための処理を含む。

Ｓ１３０１において、情報処理端末５３０のＷｅｂブラウザ７５０は、クライアント１０１としてのサーバ５１０のＷｅｂアプリケーション７００が図９のＳ９０２で作成し、Ｓ９０３で応答したページ情報を、ＨＴＴＰのレスポンスメッセージとして受信する。さらに、情報処理端末５３０のＷｅｂブラウザ７５０は、解析部７５２で受信データを解析し、Ｗｅｂ ＩｎｔｅｎｔｓリクエストのＥＭＣＡＳｃｒｉｐｔを含むデータをスクリプト処理部７５７で処理する。

次に、Ｓ１３０２において、情報処理端末５３０のＷｅｂブラウザ７５０は、上記Ｓ１３０１で取得したＨＴＭＬを表示部７５３に表示する（図９のＳ９０４に対応）。
次に、Ｓ１３０３において、情報処理端末５３０のＷｅｂブラウザ７５０は、上記Ｓ１３０２で表示部７５３に表示した画面から、ユーザによるＷｅｂ Ｉｎｔｅｎｔｓリクエストの発行指示の受信を待つ。例えば、Ｗｅｂ Ｉｎｔｅｎｔｓリクエストの発行指示は、本実施例では、画像ファイルＴｙｐｅ８０３が「ｐｎｇ」の「ｉｍａｇｅ００１．ｐｎｇ」が選択され、「印刷する」ボタン１００５が押下されたことにより発行されるものとする。

そして、上記Ｓ１３０３において、Ｗｅｂ Ｉｎｔｅｎｔｓリクエストの発行指示を受信したと判定した場合（Ｓ１３０３でＹｅｓの場合）、情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ１３０４に処理を進める。

Ｓ１３０４では、情報処理端末５３０のＷｅｂブラウザ７５０は、サービス情報管理部７５５を経由して、サービス情報記憶部７５８からサービステーブル８００（Ｗｅｂ Ｉｎｔｅｎｔｓリスト）および、Ｗｅｂ Ｉｎｔｅｎｔｓ設定８３０を取得する。ここでは、例えば、サービステーブル８００を図８（Ｂ）、Ｗｅｂ Ｉｎｔｅｎｔｓ設定を図８の８３０に示した設定として説明する。

Ｗｅｂ Ｉｎｔｅｎｔｓ設定としては、Ａｃｔｉｏｎ８０２やＴｙｐｅ８０３、及びローカルサービスＦｌａｇ８０６が「Ｏｎ」のサービスの登録に応じて、探索を行うか否かを判断するための情報を含む。図８（Ｄ）に示す例では、Ａｃｔｉｏｎ８０２＝「ｐｒｉｎｔ」については、ローカルサービスＦｌａｇが「ＯＮ」のサービスを優先する設定（優先順位を高くする設定）となっている。また、Ａｃｔｉｏｎ８０２＝「Ｓｈａｒｅ」については、ローカルサービスＦｌａｇ８０６による判断は行わない設定となっている。

すなわち、図８（Ｄ）に示す例では、Ａｃｔｉｏｎ８０２が「ｐｒｉｎｔ」の設定の場合、従来のＷｅｂ ＩｎｔｅｎｔｓのＲｅｇｉｓｔｒａｔｉｏｎがなされたサービス（図９のＳ９００のように登録されたサービス）よりも、ローカルサービスＦｌａｇが「Ｏｎ」のサービス（探索されたサービス）を優先的に利用する設定である。また、サービステーブル８００に、ローカルサービスＦｌａｇがＯＮ設定されたサービスが存在せず、且つ、従来のサーバからＲｅｇｉｓｔｒａｔｉｏｎされたサービスが存在する場合は、探索処理を行う設定である。また、Ａｃｔｉｏｎ８０２＝「Ｓｈａｒｅ」については、ローカルサービスＦｌａｇの優先設定がされていないために、サービステーブル８００に、従来のサーバからＲｅｇｉｓｔｒａｔｉｏｎされたサービスが存在する場合は探索処理を行わない設定である。また、Ａｃｔｉｏｎ８０２が「ｐｒｉｎｔ」、「Ｓｈａｒｅ」以外の設定はないため、「ｐｒｉｎｔ」、「Ｓｈａｒｅ」以外の場合（例えば「Ｅｄｉｔ」、「Ｓａｖｅ」等）、探索処理を行う設定である。

Ｓ１３０５において、情報処理端末５３０のＷｅｂブラウザ７５０は、上記Ｓ１３０３で受信したＷｅｂ Ｉｎｔｅｎｔｓリクエストの発行指示、及び、上記Ｓ１３０４で取得したサービステーブル８００、Ｗｅｂ Ｉｎｔｅｎｔｓ設定に基づいて、探索（ローカルサービス探索処理）を行うか否かを判定する。

以下、Ｓ１３０５の判定について具体例を用いて説明する。
まず、情報処理端末５３０のＷｅｂブラウザ７５０のサービス判定部７５６は、登録済みのＷｅｂ Ｉｎｔｅｎｔｓに、リクエストされたＡｃｔｉｏｎの処理が可能なサービスが存在するか否かを判定する。この判定では、サーバ５１０からのリクエストのデータＴｙｐｅおよびＡｃｔｉｏｎを処理できるサービスが存在するか否かを判定する。

ここでは、画像ファイルＴｙｐｅ８０３がｐｎｇの「ｉｍａｇｅ００１．ｐｎｇ」が選択され、「印刷する」ボタン１００５が押下された場合を例に具体的に説明する。ここでサービステーブル８００（図８（Ｂ）の状態とする）に登録されているサービスは、ＳｅｒｖｉｃｅＩＤ８０１＝"１"のサービスのみである。ＳｅｒｖｉｃｅＩＤ８０１＝"１"はＡｃｔｉｏｎ８０２＝"ｐｒｉｎｔ"且つＴｙｐｅ８０３＝"ｉｍａｇｅ／＊"であるため、リクエストされたＡｃｔｉｏｎを処理できるサービスと判定される。なお、このサービスは、ローカルサービスＦｌａｇ８０６≠"ＯＮ"のため、従来のサーバからＲｅｇｉｓｔｒａｔｉｏｎされたサービスとなる。一方、Ｗｅｂ Ｉｎｔｅｎｔｓ設定では、設定ＩＤ８３１＝"１"の設定がＡｃｔｉｏｎ８３２＝"ｐｒｉｎｔ"、Ｔｙｐｅ８３３＝"ｉｍａｇｅ／＊"、ローカルサービスＦｌａｇ８３４≠"ＯＮ"のため、上記ＳｅｒｖｉｃｅＩＤ８０１＝"１"のサービスと一致する。設定ＩＤ８３１＝"１"の設定は、ローカルサービス探索処理８３６＝"ローカルサービス探索を行う"、且つ、ローカルサービス登録処理８３７＝"ローカルサービスを登録する"の設定である。よって、この場合、サービス判定部７５６は、ローカルサービスを探索し、該探索されたローカルサービスを登録すると判定する。

上記Ｓ１３０５において、探索を行うと判定した場合（Ｓ１３０５でＹｅｓの場合）、情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ１３０６に処理を進める。Ｓ１３０６では、情報処理端末５３０のＷｅｂブラウザ７５０は、探索部７５９により、探索を実行する（図９のＳ９０６に対応）。上述の例では、Ａｃｔｉｏｎ＝"ｐｒｉｎｔ"でＴｙｐｅが"ｐｎｇ"を含むローカルサービスを探索する。これにより、例えば、ローカルサーバ５２１が提供するローカルサービス（ＬＡＮ）等が探索される。

探索部７５９が探索処理の際に送信する探索要求パケット例を図１１（Ａ）に示す。
図１１（Ａ）は、探索要求パケットを例示する図である。
上記Ｓ１３０６の探索の結果、例えば、ローカルサーバ（プリンタ）５２１が提供するローカルサービス（ＬＡＮ）や、情報処理端末５３０内のローカルサービス（機器内サービス）等が探索応答する（Ｓ９０７、Ｓ９０８）。

探索要求パケットに対する探索応答パケット例を図１１（Ｂ）に示す。
図１１（Ｂ）は、探索応答パケットを例示する図である。
本実施例では、ＳＳＤＰのマルチキャスト探索例を示したが、他の探索パケットにおいても上述の探索処理は実現可能である。

なお、サービスの探索処理では、Ａｃｔｉｏｎ、Ｔｙｐｅを指定することなく探索を行い、応答のあったサービスに対して、Ａｃｔｉｏｎ、Ｔｙｐｅ等のＷｅｂ Ｉｎｔｅｎｔｓの機能情報でフィルタリングして、所望のＡｃｔｉｏｎ、Ｔｙｐｅを処理可能なサービスを探索する構成でもよいし、初めからＡｃｔｉｏｎ、Ｔｙｐｅを指定して探索を行ってもよい。また、探索されたサービスに対してサービス拡張情報８０７を要求して取得する構成でもよいし、探索応答パケットにサービス拡張情報８０７が含まれていてもよい。さらに、探索応答パケットにはＷｅｂ Ｉｎｔｅｎｔｓの機能情報が含まず、応答のあったサービスに対して、Ｗｅｂ Ｉｎｔｅｎｔｓの機能情報を要求し、Ａｃｔｉｏｎ、Ｔｙｐｅ等を含むＷｅｂ Ｉｎｔｅｎｔｓの機能情報を取得するように構成してもよい。

上記Ｓ１３０６の探索処理の後、Ｓ１３０７において、情報処理端末５３０のＷｅｂブラウザ７５０は、探索されたサービスの情報をサービステーブル８００に保存する登録処理を行う。この登録処理では、探索結果としてローカルサービスＦｌａｇ８０６も合わせて保存する。この際、ＬＡＮ５０８内のサービスについてはローカルサービスＦｌａｇ８０６に"ＯＮ（ＬＡＮ）"、ｌｏｃａｌｈｏｓｔのサービスについてはローカルサービスＦｌａｇ８０６に"ＯＮ（機器内サービス）"と登録するものとする。なお、登録処理の際、既にサービステーブル８００に登録されているが、上記Ｓ１３０６の探索で発見されなかったローカルサービスについては、サービステーブル８００から削除するものとする。

なお、図１３には示していないが、上記Ｓ１３０５の判定で用いたＷｅｂ Ｉｎｔｅｎｔｓ設定においてローカルサービス登録処理８３７＝"ローカルサービスを登録しない"と設定されていた場合には、Ｓ１３０７の処理をスキップしてＳ１３０８に処理を進めるものとする。

ここで、図１４を用いて、上記Ｓ１３０７の登録処理について説明する。
図１４は、Ｗｅｂ Ｉｎｔｅｎｔｓ設定８３０のローカルサービス登録処理におけるＵＩ画面を例示する図である。
サービス判定部７５６が探索されたローカルサービスを登録すると判定した場合、のＷｅｂブラウザ７５０は、Ｗｅｂ Ｉｎｔｅｎｔｓ設定ダイアログ１４０１を表示する。ここでは、Ｗｅｂ ＩｎｔｅｎｔｓのＡｃｔｉｏｎとして"Ｐｒｉｎｔ"の例を示し、プリンタ設定ダイアログを示す。Ｗｅｂ Ｉｎｔｅｎｔｓ設定ダイアログ１４０１には、探索されたローカルサービスが表示される。図１４の例では、ローカルサービス探索処理の結果、３台のプリンタ（ローカルサービス）が探索された場合を示している。

１４０２はＷｅｂ Ｉｎｔｅｎｔｓ設定メニューである。図１４に示す例では、"ＭｙＰｒｉｎｔｅｒ"に対して"Ｗｅｂ Ｉｎｔｅｎｔｓへ登録"を選択することで、ＭｙＰｒｉｎｔｅｒ"の機能情報をサービス情報記憶部７５８（サービステーブル８００）に登録する場合を示している。

なお、探索による登録以外でも、ユーザが明示的にＷｅｂ Ｉｎｔｅｎｔｓ設定ダイアログ１４０１を使用して、ローカルサービスの登録や設定変更を行うことが可能である。
例えば、Ｗｅｂ Ｉｎｔｅｎｔｓ設定ダイアログ１４０１から"ネットワークデバイスの追加"等を行い、該追加したネットワークデバイスが提供するサービスを、Ｗｅｂ Ｉｎｔｅｎｔｓ設定メニュー１４０２から、Ｗｅｂ Ｉｎｔｅｎｔｓに登録することができる。この場合、登録されたローカルサービスは、図８（Ａ）のＳｅｒｖｉｃｅＩＤ８０１が"３"のように、ローカルサービスＦｌａｇ８０６＝"ＯＮ（マニュアル設定サービス）"のように登録される。

上述したローカルサービスの探索処理では、ＬＡＮ５０８上の不特定のローカルサービスを検出する必要があるために、マルチキャスト探索を行う。マルチキャスト探索では、マルチキャストパケット（例えば図１１（Ａ））で指定したＬＡＮ５０８上の探索要求に応答できるローカルサービス全てが応答を返信する（例えば図１１（Ｂ））。このため、ユーザが利用を希望しない不要なローカルサービスが存在する場合は、不要なサービスが探索される。探索されたサービスを全て登録してしまうと不要なサービスがサービス情報記憶部７５８に保存されてしまう可能性がある。しかし、図１４に示したようなＵＩでユーザが明示的に登録指示を行うことで、ユーザが所望のサービスを選択的にサービス情報記憶部７５８へ登録することが可能となる。

以下、図１３のフローチャートの説明に戻る。
上記Ｓ１３０７の登録処理後のサービステーブルの状態を、例えば図８（Ａ）に示した状態として以下を説明する。
上記Ｓ１３０７の登録処理後、情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ１３０８に処理を進める
また、上記Ｓ１３０５において、探索を行わないと判定した場合（Ｓ１３０５でＮｏの場合）、情報処理端末５３０のＷｅｂブラウザ７５０は、そのままＳ１３０８に処理を進める。

Ｓ１３０８では、情報処理端末５３０のＷｅｂブラウザ７５０は、サービスのリスト（サービス一覧）を作成する。詳細には、Ｗｅｂブラウザ７５０は、サービステーブルに基づいて、リクエストとＡｃｔｉｏｎ，Ｔｙｐｅが一致するサービスのリストを作成し（Ｓ９０９）、該作成したサービスのリストを表示する（Ｓ９１０）。ここで、表示されるサービスのリスト（一覧）は、探索の結果に従い更新されたものである。例えば、Ｗｅｂブラウザ７５０は、探索の結果、サービステーブル８００から機能情報の登録が削除されたサービスについては、一覧に含まないように作成、表示する。また、探索の結果、サービス拡張情報８０７（即ち、サービスの状態）からサービスを提供できない状態のサービスについても、一覧に含まないように作成、表示するものとする。

図１２は、実施例１におけるＷｅｂブラウザ７５０で表示するサービスリストを例示する図である。
１２００は、「印刷する」ボタン１００５（図１０）が押下されることで、情報処理端末５３０のＷｅｂブラウザ７５０が表示するポップアップ画面例である。１２０１は、ユーザが行ったリクエスト（ここでは「印刷する」ボタン１００５押下）に対応するサービスのリスト（一覧）である。

サービスのリスト１２０１からユーザがいずれかのサービスを選択すると、Ｗｅｂブラウザ７５０は、Ｓ１３０９に処理を遷移する。
Ｓ１３０９では、Ｗｅｂブラウザ７５０は、ユーザが選択したサービスを特定し、サービス情報記憶部７５８からサーバビスの情報を取得する。
次に、Ｓ１３１０において、Ｗｅｂブラウザ７５０のスクリプト処理部７５７は、Ｗｅｂ Ｉｎｔｅｎｔｓリクエストを作成する。
さらに、Ｓ１３１１において、スクリプト処理部７５７は、対象のＷｅｂ Ｉｎｔｅｎｔｓサービスにリクエストを発行する。

上記Ｓ１３１０、Ｓ１３１１について、図９を用いてより具体的に説明する。
まず、情報処理端末５３０のＷｅｂブラウザ７５０の解析部７５２は、通信部７５１を介して、サーバ５１０に対して画像データの取得要求をＨＴＴＰリクエストメッセージとして送信する。なお、これはＥＣＭＡＳｃｒｉｐｔ図１０（Ａ）内の無名関数内で呼び出しているｇｅｔＩｍａｇｅＦｒｏｍ（）関数を実行することで実現する。例えば、図１０に示したＵＩ１０００でラジオボタン１００３が選択されていれば、"ｉｍａｇｅ００１．ｐｎｇ"の取得要求を行う。本実施例では、サーバ５１０に対して取得要求を行っているが、取得要求を行わずに、既にＷｅｂブラウザ７５０が取得しているＨＴＭＬ文書内の画像データを使用するように構成してもよい。

上記Ｓ９１１の取得要求に応じて、サーバ５１０のコンテンツ管理部７０４は、Ｓ９１２において、データベースサービス部７０５のコンテンツ管理テーブル８２０から、上記Ｓ９１１の処理ステップで受信した画像データの取得要求で指定された画像データを取得する。例えば、画像データの取得要求で指定された画像データのファイル名が"ｉｍａｇｅ００１．ｐｎｇ"であれば、コンテンツ管理テーブル８２０の最初のレコードの画像データを取得する。

次に、Ｓ９１３において、サーバ５１０のプレゼンテーション部７０３は、通信部７０１を介して、Ｓ９１２の処理ステップで取得した画像データをＨＴＴＰレスポンスメッセージとして、情報処理端末５３０に送信する。そして、情報処理端末５３０のＷｅｂブラウザ７５０は、上記Ｓ９１２で送信されたメッセージを受信し、Ｓ９１４に処理を進める。

Ｓ９１４では、情報処理端末５３０のスクリプト処理部７５７は、Ｗｅｂ Ｉｎｔｅｎｔｓリクエストを作成し、例えば、ローカルサーバ（プリンタ）５２１が提供するローカルサービス（ＬＡＮ）の呼び出し処理を行う。この処理では、上記Ｓ９１３で取得した"ｉｍａｇｅ００１．ｐｎｇ"をローカルサービス（ＬＡＮ）の呼び出しパラメータとして利用する。そして、Ｓ９１５において、情報処理端末５３０のＷｅｂブラウザ７５０は、上記Ｓ９１０で表示し、ユーザに選択されたサービスへ要求を送信する。例えば、ローカルサーバ５２１のＷｅｂアプリケーション７４０に対して要求を送信する。

上記Ｓ９１５の要求に応じて、ローカルサーバ５２１のＷｅｂアプリケーション７４０のＩｎｔｅｎｔ処理部７４２は、Ｓ９１６において、上記Ｓ９１５で受信した要求からＩｎｔｅｎｔオブジェクトを取り出して解析する。続けて、解析したＩｎｔｅｎｔの処理を開始する。例えば、ローカルサーバ５２１のＷｅｂアプリケーション７４０は、情報処理端末５３０のＷｅｂブラウザ７５０を介してユーザと相互作用しながら、Ｉｎｔｅｎｔオブジェクトに含まれる画像データを印刷する「Ｐｒｉｎｔ」サービスを提供する。例えば、ローカルサーバ５２１のＷｅｂアプリケーション７４０は、画像データのファイル名の入力と保存する操作を受け付けるためのＨＴＭＬ文書を作成し、情報処理端末５３０に送信する。情報処理端末５３０のＷｅｂブラウザ７５０は、ＨＴＭＬ文書を受信し、ＵＩを表示する。そして、情報処理端末５３０のＷｅｂブラウザ７５０は、ユーザによる"Ｐｒｉｎｔ"操作を検知すると、ローカルサーバ５２１のＷｅｂアプリケーション７４０に、画像データの印刷要求を送信する。ローカルサーバ５２１のＷｅｂアプリケーション７４０は、画像データの印刷要求を受信すると、コンテンツ処理部７３４がデータベースサービス部７３５のコンテンツ管理テーブル８２０に、ユーザに指定された画像データを印刷する。

ローカルサーバ５２１のＷｅｂアプリケーション７４０は、Ｉｎｔｅｎｔの処理が終了すると、Ｓ９１７において、処理結果をサーバ５１０に伝えるＥＣＭＡＳｃｒｉｐｔを含む応答を返す。
Ｓ９１８において、情報処理端末５３０のＷｅｂブラウザ７５０は、上記Ｓ９１７の応答中に含まれるＥＣＭＡＳｃｒｉｐｔを実行し、上記Ｓ９０４で表示したページに含まれるｓｔａｒｔＡｃｔｉｖｅｔｙ（）関数の引数で指定されたコールバック関数を呼び出す。例えば、ＥＣＭＡＳｃｒｉｐｔが図１０（Ａ）であれば、コールバック関数ｏｎＳｕｃｃｅｓｓ（）を実行する。

次に、Ｓ９１９において、情報処理端末５３０のＷｅｂブラウザ７５０はコールバック関数によってサーバ５１０のＷｅｂアプリケーション７００へＷｅｂ Ｉｎｔｅｎｔｓ処理結果を返す。

上記Ｓ９１９で返送されたＷｅｂ Ｉｎｔｅｎｔｓ処理結果を受信すると、サーバ５１０のＷｅｂアプリケーション７００のプレゼンテーション部７０３は、Ｓ９２０において、Ｉｎｔｅｎｔの処理が終了したことを通知するためのページである終了ページをＨＴＭＬ文書で作成する。さらに、Ｓ９２１において、サーバ５１０のＷｅｂアプリケーション７００のプレゼンテーション部７０３は、通信部７０１を介して、上記Ｓ９２０で作成した終了ページを情報処理端末５３０に送信する。
Ｓ９２２において、情報処理端末５３０のＷｅｂブラウザ７５０は、上記Ｓ９２１で受信したＷｅｂ Ｉｎｔｅｎｔｓ処理の終了ページを表示する。

以上示したＳ９００〜Ｓ９２２のステップを行うと、ローカルＷｅｂ Ｉｎｔｅｎｔｓの探索結果がサービス情報記憶部７５８に保存される。例えば、この時点のサービステーブル８００を図８（Ａ）に示した状態として以下を説明する。

上記Ｓ９０７の探索応答処理により、ローカルサーバ５２１が提供するローカルサービス（ＬＡＮ）の情報が、例えば、図８（Ａ）のＳｅｒｖｉｃｅＩＤ８０１が"２"の行に"ＬＢＰ−１００ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ"記録される。また同様に探索応答処理により、ＳｅｒｖｉｃｅＩＤ８０１が"３"で示される情報処理端末５３０の機器内で提供される"Ｐｒｉｎｔ ｔｏ Ｆｉｌｅ Ｓｅｒｖｉｃｅ"が登録される。なお、図９のＳ９０６〜Ｓ９０７では、ローカルサービス（ＬＡＮ）の探索・応答のみを図示しているが、ローカルサービス（機器内サービス）についても同様である。さらに、ＳｅｒｖｉｃｅＩＤ８０１が"４"で示される手動でアドレスなどのＷｅｂ Ｉｎｔｅｎｔｓ情報が入力された"ＬＢＰ−３００ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ（手動入力）"が登録される。この状態で、情報処理端末５３０のＷｅｂブラウザ７５０は、アドレスバーなどにサーバ５１０（クライアント）のＷｅｂアプリケーション７００のＵＲＬを入力する等のユーザ操作を受け付けることで、以降の処理を開始する。

本実施例では、Ｗｅｂアプリケーション７３０のＵＲＬの例を示すが、上記Ｓ９０１と同様のＵＲＬである必要はない。Ｗｅｂアプリケーション７３０以外のＵＲＬを指定しても、情報処理端末５３０のＷｅｂブラウザ７５０において、次のステップに続くＷｅｂ ＩｎｔｅｎｔｓのＩｎｖｏｃａｔｉｏｎ処理が行えれば良い。

Ｓ９２３において、Ｗｅｂブラウザ７５０は、通信部７５１を介してサーバ５１０にＨＴＴＰのリクエストメッセージとしてページの要求を送信する（上記Ｓ９０１と同様）。
サーバ５１０のＷｅｂアプリケーション７００は、情報処理端末５３０から送信された上記ページの要求を受信すると、Ｓ９２４の処理を実行する。Ｓ９２４において、サーバ５１０のＷｅｂアプリケーション７００は、ページの作成を行う（上記Ｓ９０２と同様）。Ｓ９２５において、サーバ５１０のＷｅｂアプリケーション７００は、上記Ｓ９２４で作成したページを、情報処理端末５３０のＷｅｂブラウザ７５０へＨＴＴＰのレスポンスメッセージとして応答する（Ｉｎｖｏｃａｔｉｏｎ処理）（上記Ｓ９０３と同様）。

情報処理端末５３０のＷｅｂブラウザ７５０は、サーバ５１０から応答された上記ページを受信すると、Ｓ９２６の処理を実行する。Ｓ９２６において、情報処理端末５３０のＷｅｂブラウザ７５０の表示部７５３は、上記受信したページを表示する（上記Ｓ９０４と同様）。具体的には、解析部７５２が、上記ページに対応するＨＴＭＬ文書を解析し、表示部７５３がレンダリングすることで上記受信したページを表示する。

上記Ｓ９２６で表示された画面において、ユーザにより「印刷する」ボタンが押下されたことを検知すると、ＵＡ１０６である情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９２７の処理を実行する。Ｓ９２７において、情報処理端末５３０のＷｅｂブラウザ７５０は、表示部７５３に表示するサービスの探索実行判定処理を行う。

Ｓ９２７の処理は、「印刷」などＳ９２６で指定されたＷｅｂ ＩｎｔｅｎｔｓのＡｃｔｉｏｎの処理が可能なサービスの探索を行うか否かを判定するためのものである。具体的には、情報処理端末５３０のＷｅｂブラウザ７５０は、サービス情報記憶部７５８からサービステーブル８００および、Ｗｅｂ Ｉｎｔｅｎｔｓ設定８３０を取得する（図１３のＳ１３０４）。続いて、情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ１３０３で受信したＷｅｂ Ｉｎｔｅｎｔｓリクエストの発行指示、及び、上記Ｓ１３０４で取得したサービステーブル８００、Ｗｅｂ Ｉｎｔｅｎｔｓ設定に基づいて、探索（ローカルサービス探索処理）を行うか否かを判定する。Ｓ９２７の場合、上記Ｓ９０６〜Ｓ９０８で探索されたローカルサービスが、ＳｅｒｖｉｃｅＩＤ８０１の"２"に既に登録されている。よって、サービス判定部７５６は、Ａｃｔｉｏｎ８０２が"Ｐｒｉｎｔ"でＴｙｐｅが"ｉｍａｇｅ／＊"のデータを処理する場合、設定ＩＤ８３１が"２"の設定でローカルサービス探索処理の判定を行う。設定ＩＤ８３１が"２"のローカルサービス探索処理８３６＝"ローカルサービス探索を行わない"であるため、探索は行わないと判定される。このため、ローカルサービス探索を行わず、サービス情報管理部７５５は、Ｓ９２８において、サービス情報記憶部７５８に登録済みのサービスからサービス一覧を作成し、表示する（図１３のＳ１３０８）。

Ｓ９２８以降の処理は、上述したＳ９１０〜Ｓ９２２と同様のステップで処理を実現できる。以上のように、既に探索済みのローカルサービスが、探索情報と共にサービス情報記憶部７５８に記録されることで、不要な探索を行わないでローカルサービスを利用できるようになる。

上述したように、本実施例では、情報処理端末５３０のＷｅｂブラウザ７５０が、従来からのＷｅｂ ＩｎｔｅｎｔｓのＲｅｇｉｓｔｒａｔｉｏｎされたＵＡに保存、管理されているサービスと、探索されたローカルサービスとを識別（区別）して管理する。

また、Ｗｅｂ ＩｎｔｅｎｔｓのＩｎｖｏｃａｔｉｏｎ受信時に毎回ローカルサービスの探索を行わず、Ｗｅｂ Ｉｎｔｅｎｔｓ設定に基づいて、以前に登録したローカルサービスを利用する構成を説明した。この構成により、Ｉｎｖｏｃａｔｉｏｎ受信毎に探索が行われてユーザの不要なサービスが登録されてしまうことを防止でき、ユーザは自分の利用したいサービスを見つけやすくなる。また、探索によるネットワークトラフィックの増加を抑えることができる。

このように本実施例によれば、ローカルサービスを利用する時に、最適なローカルサービスの探索制御を行うことができ、不要な探索の繰り返しや、利用できないサービスの登録／表示を抑制し、ユーザに最適なサービス一覧を提供することが可能となる。このように、インターネット上のサービス及びローカルサービス等のネットワーク機器が提供する各種サービスを、ユーザが容易に選択・利用することを可能にできるサービス実行環境を構築可能となる。

実施例１では、情報処理端末５３０のＷｅｂブラウザ７５０がリクエストを処理可能なサービスがサービス情報記憶部７５８に存在する場合、Ｗｅｂ Ｉｎｔｅｎｔｓ設定（特にローカルサービス探索処理８３６の設定）に応じて、ローカルサービス探索の実行の有無を制御する構成について説明した。

実施例２では、情報処理端末５３０のＷｅｂブラウザ７５０がローカルサービス探索を行わない場合に、Ｗｅｂ Ｉｎｔｅｎｔｓ設定（特にローカルサービス更新処理８３８の設定）に応じて、登録済みのローカルサービスを更新する構成について説明する。なお、実施例１と同等の構成や処理については説明を省略する。

以下、図１５のシーケンス図、および、図１７のフローチャートを用いて、情報処理端末５３０のＷｅｂブラウザ７５０がローカルサービス探索を行わない場合に、登録済みのローカルサービスを更新する処理について説明する。

図１５は、実施例２におけるＷｅｂ Ｉｎｔｅｎｔｓを利用したサービス提供に関する動作の一例を示すシーケンス図である。なお、図１５では、ローカルサービス（ＬＡＮ）の拡張情報を更新するシーケンスのみを図示しているが、ローカルサービス（機器内サービス）についても同様である。また、図９と同一のステップには同一のステップ番号を付してある。

図１７は、実施例２におけるＵＡ１０６である情報処理端末５３０のＷｅｂブラウザ７５０の処理の一例を示すフローチャートである。なお、図１３と同一のステップには同一のステップ番号を付してある。

Ｓ１３０６において、情報処理端末５３０のＷｅｂブラウザ７５０は、探索部７５９により、探索を実行する（Ｓ９０６に対応）。上述の例では、Ａｃｔｉｏｎ＝"ｐｒｉｎｔ"でＴｙｐｅが"ｐｎｇ"を含むローカルサービスを探索する。これにより、例えば、ローカルサーバ５２１が提供するローカルサービス（ＬＡＮ）等が探索される。具体的には、探索部７５９が送信を行う探索要求パケット例を図１１（Ａ）に示す。この実施例では、ＳＳＤＰのマルチキャスト探索例を示す。この結果、例えば、ローカルサーバ（プリンタ）５２１が提供するローカルサービス（ＬＡＮ）や、情報処理端末５３０内のローカルサービス（機器内サービス）等が探索応答する（Ｓ９０７、Ｓ９０８）。探索応答パケット例を図１１（Ｂ）に示す。

上記Ｓ１３０６の探索処理の後、Ｓ１３０７において、情報処理端末５３０のＷｅｂブラウザ７５０は、探索されたサービスの情報をサービステーブル８００に保存する登録処理を行う。この登録処理では、探索結果としてローカルサービスＦｌａｇ８０６も合わせて保存する。この際、ＬＡＮ５０８内のサービスについてはローカルサービスＦｌａｇ８０６に"ＯＮ（ＬＡＮ）"、ｌｏｃａｌｈｏｓｔのサービスについてはローカルサービスＦｌａｇ８０６に"ＯＮ（機器内サービス）"と登録するものとする。上記Ｓ１３０７の登録処理後のサービステーブルの状態を、例えば図８（Ａ）に示した状態として以下を説明する。なお、Ｓ９０９〜Ｓ９２２の説明は省略する。

続いて、この状態で、Ｓ９２３以降の処理を行う。
Ｓ９２３において、Ｗｅｂブラウザ７５０は、通信部７５１を介してサーバ５１０にＨＴＴＰのリクエストメッセージとしてページの要求を送信する（上記Ｓ９０１と同様）。なお、Ｓ９２４〜Ｓ９２６の説明は省略する。
その後、上記Ｓ９２６で表示された画面において、ユーザは「印刷する」ボタンを押下し、サービス情報記憶部７５８に記憶されている登録済みサービスを一覧から選択することが可能となる。

しかし、ローカルサービスは、Ｉｎｔｅｒｎｅｔ５０５を介して提供されているサービスと違い、サービスの提供状態が登録時から変わっている可能性がある。例えば、ローカルサーバ５２１（プリンタ）が提供するローカルサービス（ＬＡＮ）を提供できない場合がある。例えば、ローカルサーバ５２１（プリンタ）の電源がＯＦＦであるために通信エラーになる場合や、ローカルサーバ５２１（プリンタ）において、トナーやインク、紙などの消耗品が不足して印刷ができない等、サービスが提供できない場合がある。このように、ローカルサービスがサービス情報記憶部７５８に記憶されている場合、利用できないサービスをユーザが選択してしまう可能性がある。

しかし、Ｉｎｖｏｃａｔｉｏｎを受信した際に毎回、ローカルサービスの探索処理を行うと、環境によっては、ユーザの利用しない複数のローカルサービスが発見され、このようなサービスが一覧に含まれてしまい、ユーザが所望のサービスを選択し辛くなる可能性がある。本実施例では、ローカルサービスＦｌａｇ８３４を利用することで、効率的にサービス情報記憶部７５８に記憶されているローカルサービスの状態を更新することが可能となる。

Ｓ９２７において、情報処理端末５３０のＷｅｂブラウザ７５０は、サービス情報記憶部７５８からサービステーブル８００および、Ｗｅｂ Ｉｎｔｅｎｔｓ設定８３０に基づいて、探索（ローカルサービス探索処理）を行うか否かを判定する。Ｓ９２７の場合、上記Ｓ９０６〜Ｓ９０８で探索されたローカルサービスが、ＳｅｒｖｉｃｅＩＤ８０１の"２"に既に登録されている。よって、サービス判定部７５６は、Ａｃｔｉｏｎ８０２が"Ｐｒｉｎｔ"でＴｙｐｅが"ｉｍａｇｅ／＊"のデータを処理する場合、設定ＩＤ８３１が"２"の設定でローカルサービス探索処理の判定を行う。設定ＩＤ８３１が"２"のローカルサービス探索処理８３６＝"ローカルサービス探索を行わない"であるため、探索は行わないと判定される。しかし、設定ＩＤ８３１が"２"のローカルサービス更新処理８３８＝"ローカルサービス情報更新する"設定のため、情報処理端末５３０のＷｅｂブラウザ７５０は、ローカルサービス探索を行わず、ローカルサービス更新処理のみ行うと判定する。

Ｓ１７０１において、情報処理端末５３０のＷｅｂブラウザ７５０は、登録済みのＷｅｂ Ｉｎｔｅｎｔｓサービスの更新を行う。このローカルサービス更新処理は、上述したＳＳＤＰのマルチキャスト探索によるローカルサービス探索処理とは異なり、サービス情報記憶部７５８に記憶されているサービスへのユニキャスト情報取得により、登録済みのローカルサービスの状態のみを更新することが可能となる。

なお、図１７には示していないが、上記Ｓ１３０５の判定で用いたＷｅｂ Ｉｎｔｅｎｔｓ設定においてローカルサービス更新処理８３８＝"ローカルサービス情報更新しない"と設定されていた場合には、Ｓ１７０１の処理をスキップしてＳ１３０８に処理を進めるものとする。

以下、ローカルサービス更新処理（Ｓ１７０１）について具体的に説明する。
まず、Ｓ１５０１において、Ｗｅｂブラウザ７５０は、サービス情報記憶部７５８に記憶されているローカルサービス（ローカルサービスＦｌａｇ＝８０６"ＯＮ"のサービス）のｈｒｅｆ８０４アドレスへ、ＨＴＭＬのＧｅｔリクエスト（不図示）を送信する。

上記Ｓ１５０１のリクエストに応じて、ローカルサーバ５２１のＷｅｂアプリケーション７４０は、Ｓ１５０２において、ＨＴＭＬのＧｅｔリクエストの返信データを作成する。続いて、Ｓ１５０３において、ローカルサーバ５２１のＷｅｂアプリケーション７４０は、Ｗｅｂブラウザ７５０に対して、Ｗｅｂ Ｉｎｔｅｎｔｓの登録用マークアップに、Ｗｅｂ Ｉｎｔｅｎｔｓ拡張情報を含んだ応答を返信する。この返信の例を図１６に示す。

図１６（Ａ）は、ローカルサーバ５２１のＷｅｂアプリケーション７４０が返信する、Ｗｅｂ Ｉｎｔｅｎｔｓ拡張情報に、機器の状態「ｓｔａｔｅ＝"Ｒｅａｄｙ"」を含んだ応答パケット例に対応する。

図１６（Ｂ）は、ローカルサーバ５２１のＷｅｂアプリケーション７４０が返信する、Ｗｅｂ Ｉｎｔｅｎｔｓ拡張情報に、Ｔｙｐｅ８０３の異なる複数のサービスの状態を含んだ応答パケット例に対応する。なお、図１６（Ｂ）では、Ｔｙｐｅ８０３が異なる複数のサービスの状態を含んだ応答パケット例を示したが、Ａｃｔｉｏｎ８０２が異なる複数のサービスの状態を含んだ場合などにも同様に適用できる。

また、応答パケットに、拡張情報として、動的に変動する可能性がある消耗品情報等を含めることも可能であり、これらの動的情報を元にサービス判定部７５６がサービスの状態を判定することができる。例えば、「Ｓｔａｔｅ＝Ａ４−ｐａｐｅｒｌｏｗ」などの消耗品情報等を含めることも可能であり、そのサービスを提供するプリンタに収納されたＡ４用紙の残量が少なくなっていることを判定できる。

Ｗｅｂブラウザ７５０のサービス情報管理部７５５は、ローカルサービスからの応答結果に基づいて、サービス情報記憶部７５８（サービステーブル８００）に登録されているサービスの情報を更新する。なお、応答パケットを受け取る前にタイムアウトしたサービスについては、サービス情報記憶部７５８（サービステーブル８００）から削除するものとする。続いて、Ｓ１３０８において、情報処理端末５３０のＷｅｂブラウザ７５０は、サービスのリスト（サービス一覧）を作成し表示する（Ｓ９２８）。ここで、表示されるサービスのリスト（一覧）は、更新処理（Ｓ１７０１）の結果に従い更新されたものである。例えば、Ｗｅｂブラウザ７５０は、更新処理の結果、サービステーブル８００から機能情報の登録が削除されたサービスについては、一覧に含まないように作成、表示する。また、更新処理の結果、サービス拡張情報８０７（即ち、サービスの状態）からサービスを提供できない状態のサービスについても、一覧に含まないように作成、表示するものとする。
以降の処理は、実施例１と同様なため省略する。

なお、ここでは、サービステーブル８００のＳｅｒｖｉｃｅＩＤ８０１＝"２"のサービスに対して、Ｓ１５０１でＷｅｂブラウザ７５０が送信したＨＴＴＰリクエストがタイムアウトした場合の例を示す。この場合、ローカルサーバ５２１のＷｅｂアプリケーション７４０は、Ｓ１５０３の返信処理を行わないため、Ｗｅｂブラウザ７５０のサービス判定部７５６は、サービス情報記憶部７５８（サービステーブル８００）に記憶されているＳｅｒｖｉｃｅＩＤ８０１＝"２"の情報を図１８（Ａ）に示すように更新する。

図１８は、図１７のＳ１７０１の登録済みサービスの更新後のサービステーブル８００を例示する図である。
図１８（Ａ）に示す例では、ＳｅｒｖｉｃｅＩＤ８０１＝"２"のローカルサービスから応答がなかったため、該ローカルサービスが存在しなくなったと判定され、削除されている。

また別の例として、サービステーブル８００のＳｅｒｖｉｃｅＩＤ８０１＝"２"のサービスが、Ｗｅｂ Ｉｎｔｅｎｔｓ拡張情報として「Ｓｔａｔｅ＝Ａ４−ｐａｐｅｒｌｏｗ，ｃｏｌｏｒｐｒｉｎｔ」を含む応答パケットを返した場合の例を示す。この場合、Ｗｅｂブラウザ７５０のサービス判定部７５６は、サービス情報記憶部７５８（サービステーブル８００）に記憶されているＳｅｒｖｉｃｅＩＤ８０１＝"２"の情報を図１８（Ｂ）に示すように更新する。

図１８（Ｂ）に示す例では、ＳｅｒｖｉｃｅＩＤ８０１＝"２"のローカルサービスのサービス拡張情報（ｅｘｔｅｎｄ）８０７が"Ｓｔａｔｅ＝Ａ４−ｐａｐｅｒｌｏｗ，ｃｏｌｏｒｐｒｉｎｔ"のように更新されている。

図１９は、実施例２におけるＷｅｂブラウザ７５０で表示するサービスリストを例示する図である。なお、図１２と同一のものには同一の符号を付してある。
図１９では、ローカルサービスのサービス情報をサービス情報記憶部７５８（サービステーブル８００）に登録する場合に、Ｗｅｂ Ｉｎｔｅｎｔｓ情報の登録ＵＩを表示しないで自動で更新を行う設定ＵＩ例を示す。

１９０１は、「ローカルサービスの更新を自動で行う」ためのチェックボックスを示す。このチェックボックスが設定されている（チェックされている）場合、サービス情報更新時に、ユーザに通知を表示しないで更新を行う。

具体的には、Ｓ１７０１で情報処理端末５３０のＷｅｂブラウザ７５０は、登録済みのＷｅｂ Ｉｎｔｅｎｔｓサービスの更新を行う場合に、Ｓ１５０３で受信したＷｅｂ Ｉｎｔｅｎｔｓ拡張情報を、サービス情報記憶部７５８（サービステーブル８００）に登録する時に、ユーザに登録する情報の確認表示は行わず登録する。このため、ユーザは、更新の度に確認表示が表示されなくなり情報更新時の利便性が向上する。

本実施例では、情報処理端末５３０のＷｅｂブラウザ７５０が、効率的にサービス情報記憶部７５８に記憶されているローカルサービスの状態を更新することが可能となり、ユーザに最適なサービス一覧を提供することが可能となる。また、ローカルサービスの探索（不要な探索の繰り返し等）を減らし、また利用できないサービスの登録／表示を抑制することでユーザ操作性の向上や、ネットワークトラフィックを低減することができる。さらに、更新の度に確認表示が表示されることもなく、情報更新時の利便性が向上する。よって、インターネット上のサービス及びローカルサービス等のネットワーク機器が提供する各種サービスを、ユーザが容易に選択・利用することを可能にする。

なお、前述の各実施例においては、専用のＡＰＩを用いずに任意のＷｅｂサービス（または、Ｗｅｂアプリケーション）と連携する技術として、Ｗｅｂ Ｉｎｔｅｎｔｓを利用した場合の説明を行っている。しかし、Ｗｅｂ Ｉｎｔｅｎｔｓを用いての説明はあくまでも一例であり、同様な中継機能を介したクライアントとサービスを連携するための他の仕組みを利用してもよい。例えば、Ｗｅｂ Ａｃｔｉｖｉｔｉｅｓ（Ｍｏｚｉｌｌａ社）と呼ばれる技術を利用してもよいし、同様の独自仕様を用いて本発明を実現することが可能である。この場合、「ａｃｔｉｏｎ」、「ｔｙｐｅ」、「ｈｒｅｆ」、「ｔｉｔｌｅ」等に相当する情報が、異なる名称で定義される場合がある。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
以上示したように、ネットワーク機器が提供する各種サービスについてユーザに最適なサービス一覧を提供し、ユーザが容易に選択・利用することを可能にする。

Claims (12)

1. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを中継する中継機能を備える情報処理端末であって、
   所定のネットワークプロトコルを用いて、ネットワークを介してサービスを探索することで、当該ネットワークに接続されたネットワーク機器が提供する第１のサービスを要求するための第１の機能情報を取得する第１の取得手段と、
   第２のサービスを提供するネットワーク機器のサイトを介して、当該第２のサービスを要求するための第２の機能情報を取得する第２の取得手段と、
   前記中継機能による、前記第１の取得手段により取得された前記第１の機能情報、及び、前記第２の取得手段により取得された前記第２の機能情報の登録処理を実行する登録手段と、
   前記登録処理に従い登録された前記第１の機能情報及び前記第２の機能情報を含む機能情報の一覧の表示を制御する制御手段と、を有し、
   前記制御手段は、前記所定のネットワークプロトコルを用いた前記ネットワークを介したサービスの探索により、前記登録処理に従い既に登録された機能情報が見つかった場合には、当該探索の結果に従い前記一覧の表示を更新することを特徴とする情報処理端末。
2. 前記探索の結果には、既に登録された機能情報に対応するサービスの状態が含まれることを特徴とする請求項１に記載の情報処理端末。
3. 前記探索の結果に含まれるサービスの状態に従い既に登録された機能情報の登録が削除された場合には、前記制御手段は、該削除された機能情報を含めないように前記一覧の表示を更新することを特徴とする請求項２に記載の情報処理端末。
4. 前記第２の取得手段により取得された第２の機能情報に対応する第２のサービスに対しては、状態の取得のための探索は行われないことを特徴とする請求項２又は３に記載の情報処理端末。
5. 前記登録処理に従い登録された機能情報について、第１の取得手段により取得された第１の機能情報と、第２の取得手段により取得された第２の機能情報と、を区別して管理する管理手段をさらに有することを特徴とする請求項２乃至４のいずれか１項に記載の情報処理端末。
6. 前記管理手段は、前記第１の機能情報の拡張情報として、前記所定のネットワークプロトコルを用いて取得されるサービスの状態をさらに管理することを特徴とする請求項５に記載の情報処理端末。
7. 前記登録手段への前記第１の機能情報の登録状態を条件として前記探索を行うか否かを設定する設定手段と、
   前記第１の取得手段は、前記登録手段への前記第１の機能情報の登録状態および前記設定手段の設定に基づいて、前記探索の実行を制御することを特徴とする請求項２乃至６のいずれか１項に記載の情報処理端末。
8. 前記第１の取得手段は、前記探索を行わない場合、前記既に登録されている機能情報を提供するネットワーク機器から該機能情報に対応するサービスの状態を取得する更新処理を行うことを特徴とする請求項７に記載の情報処理端末。
9. 前記設定手段は、前記更新処理を行うか否かを設定可能であり、
   前記第１の取得手段は、前記探索を行わない場合、前記設定手段の設定に基づいて、前記更新処理の実行を制御することを特徴とする請求項８に記載の情報処理端末。
10. 前記第１の取得手段は、ネットワークを介して接続されたネットワーク機器を探索し、ネットワーク機器が提供する第１のサービスを要求するための第１の機能情報を取得するものであり、
    前記登録手段は、前記第１の取得手段によるネットワーク機器の探索結果を示す画面を介して、ユーザにより選択されたネットワーク機器が提供するサービスを要求するための機能情報の登録の指示があった場合に、該登録の指示があったネットワーク機器が提供する第１のサービスを要求するための第１の機能情報を登録することを特徴とする請求項１乃至９のいずれか１項に記載の情報処理端末。
11. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを中継する中継機能を備える情報処理端末の制御方法であって、
    所定のネットワークプロトコルを用いて、ネットワークを介してサービスを探索することで、当該ネットワークに接続されたネットワーク機器が提供する第１のサービスを要求するための第１の機能情報を取得する第１の取得ステップと、
    第２のサービスを提供するネットワーク機器のサイトを介して、当該第２のサービスを要求するための第２の機能情報を取得する第２の取得ステップと、
    前記中継機能による、前記第１の取得ステップにより取得された前記第１の機能情報、及び、前記第２の取得ステップにより取得された前記第２の機能情報の登録処理を実行する登録ステップと、
    前記登録処理に従い登録された前記第１の機能情報及び前記第２の機能情報を含む機能情報の一覧の表示を制御する制御ステップと、を有し、
    前記制御ステップでは、前記所定のネットワークプロトコルを用いた前記ネットワークを介したサービスの探索により、前記登録処理に従い既に登録された機能情報が見つかった場合には、当該探索の結果に従い前記一覧の表示を更新することを特徴とする情報処理端末の制御方法。
12. コンピュータを、請求項１乃至１０のいずれか１項に記載された手段として機能させるためのプログラム。

Images