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

Description

本発明は、Ｗｅｂ Ｉｎｔｅｎｔｓ（ウェブインテンツ）などの仕組みを用いたサービスを提供する際の技術に関する。

従来、ＷＥＢ（ウェブ）サイト間で処理を委譲する場合、機能を呼び出す側は、機能を提供する側のＡＰＩ（アプリケーション・プログラミング・インタフェース）やＲＥＳＴインタフェース等の機能の呼び出し方を、知っている必要があった。従って、異なるウェブサイトとの連携を実現するためには、機能の呼び出し側は、それぞれの呼び出し規約に従って呼び出し側の処理が必要になった。また、機能を呼び出す側が機能を利用するためには、機能を提供する側への認証が必要になることが多い。このために、機能を利用する側は、機能を提供する側の認証情報を保持したり、ＳＡＭＬ等の認証基盤を利用したりする必要があった。但し、認証情報を持つと、それら認証情報を正しく安全に管理する必要があり、ＳＡＭＬ等の認証基盤を利用するためには、機能の提供者と利用者間で事前に合意が必要となり、機能の利用者の負担になっていた。特許文献１には、従来からＷｅｂで提供されるサービスを利用する技術が開示されている。

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

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

上述したＷｅｂ Ｉｎｔｅｎｔｓなどの新しい連携の仕組みでは、該仕組みのサービスにより提供される提供機能を利用するために、ユーザエージェント（ＵＡ）は、提供機能の機能情報の登録用マークアップを含むＨＴＭＬ文書を処理し、機能情報をＷｅｂ Ｉｎｔｅｎｔとして登録する。なお、ＵＡは、Ｗｅｂ ＩｎｔｅｎｔｓクライアントとＷｅｂ Ｉｎｔｅｎｔｓサービスとをネットワークを介して中継する中継機能として機能するものであり、自身に登録された機能情報を用いてサービスに接続して提供機能の実行を要求することが可能となる。しかし、情報処理端末に中継機能が複数存在する場合、中継機能ごとに個別に機能情報の登録処理が行われ個別に管理される。このため、ある中継機能で、ある機能情報を登録したとしても、その機能情報を他の中継機能から利用することができない。このため、ユーザは、同一の機能情報であっても、中継機能毎に登録処理をくり返し行う必要があり、必ずしも使い勝手の良いものではなかった。よって、このＷｅｂ Ｉｎｔｅｎｔを用いたサービスへの要求やＷｅｂ Ｉｎｔｅｎｔの登録に関しては、ユーザビリティを向上させるための様々な改良が、今後、求められると言える。

そこで、本発明は、現在、提案されているＷｅｂ Ｉｎｔｅｎｔｓなどの新しい連携の仕組みについて、ユーザビリティを向上させるための柔軟な改良を加えることを目的とする。

本発明は、データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を複数備える情報処理端末であって、前記サービスが提供する機能を呼び出すための機能情報の登録処理を実行する１以上の中継機能を指定するための指定画面を提供する提供手段を有し、前記指定画面を介して指定された１以上の中継機能により前記機能情報の登録処理が実行されることを特徴とする。

本発明によれば、Ｗｅｂ Ｉｎｔｅｎｔｓなどの新しい連携の仕組みを提供する中継機能が情報処理端末内に複数存在する場合、それら中継機能の間で機能情報の少なくとも一部を適切に共有することを可能とする。この結果、ユーザは中継機能毎に同一の機能情報の登録を繰り返す必要もなくなり、ユーザの利便性が向上する。よって、現在、提案されているＷｅｂ Ｉｎｔｅｎｔｓなどの新しい連携の仕組みについて、ユーザビリティを向上させることができる。

Ｗｅｂ Ｉｎｔｅｎｔｓの基本的なシステム構成を例示する図。 Ｗｅｂ Ｉｎｔｅｎｔｓの基本的な動作の概要を例示するシーケンス図。 Ｗｅｂ Ｉｎｔｅｎｔｓの登録用マークアップ及び処理要求を例示する図。 Ｗｅｂブラウザを複数インストールしている情報処理端末のＵＩ例。 クライアント及びサービス１０３のハードウェア構成を例示する図。 ＵＡを含む情報処理端末のハードウェア構成を例示する図。 ＵＡを含む情報処理端末のソフトウェア構成を例示する図。 Ｗｅｂブラウザにて管理される機能情報を例示する図。 実施例１において機能情報を相互利用する動作のシーケンス図。 Ｗｅｂブラウザに表示される画面を例示する図。 図９のシーケンスの一部の詳細シーケンス図。 機能情報のデータ構成を例示する図。 実施例１において機能情報を相互利用する処理のフローチャート。 インテントを利用して機能情報を他のＵＡに登録する詳細フローチャート。 実施例２において機能情報を相互利用する動作のシーケンス図。 図１５のシーケンスの一部の詳細シーケンス図。 Ｗｅｂ Ｉｎｔｅｎｔｓを利用して機能情報を他のＵＡに登録する詳細フローチャート。 実施例３において機能情報を相互利用する動作のシーケンス図。 Ｗｅｂブラウザに表示される画面を例示する図。 図１８のシーケンスの一部の詳細シーケンス図。 機能情報のマップを例示する図。 実施例３において機能情報を相互利用する処理のフローチャート。 マップ生成処理の詳細フローチャート。 機能情報の取得処理の詳細フローチャート。 機能情報の共有処理の詳細フローチャート。 実施例４において機能情報を相互利用する動作のシーケンス図。 図２６のシーケンスの一部の詳細シーケンス図。 図２６のシーケンスの一部の詳細シーケンス図。

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

＜Ｗｅｂ Ｉｎｔｅｎｔｓの基本的な仕組み＞
まず、専用のＡＰＩを用いずに任意のＷｅｂサービス（または、Ｗｅｂアプリケーション）と連携するための仕組みの一例であるＷｅｂ Ｉｎｔｅｎｔｓに関する基本的な仕組みについて図１乃至図３を用いて説明する。本発明では、具体例として、Ｗｅｂ Ｉｎｔｅｎｔｓを挙げるが、任意のウェブサービス（または、Ｗｅｂアプリケーション）と連携する技術として、他の同様の仕組みを適用することも可能である。

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

本仕組みにおいては、例えば、クライアント１０１はデータを管理し、サービスを呼び出すボタンなどを配置しているウェブサイトであり、ＵＡ１０６は該ウェブサイトを表示するＷｅｂブラウザ（ウェブＷｅｂブラウザ）である。また、サービス１０３は、ＵＡ１０６を介してクライアント１０１が管理するデータを受け付けて、処理するクライアント１０１の連携先のウェブサイトである。

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

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

また、サービス１０３については、上述した投稿先サービスのような、インターネット上のサービス提供者以外にも、例えば情報処理端末が内蔵するカメラ、プリンタ、スキャナなどといったデバイスもサービス提供者になり得る。また、サービス１０３については、ネットワークで接続されるプリンタ、スキャナ、ネットワークカメラなどの周辺機器や、冷蔵庫やテレビといった家電製品などもサービス提供者になり得る。また、クライアント１０１についても同様に、情報処理端末が内蔵するさまざまなデバイスやアプリケーション、その他にネットワーク上の周辺機器や家電製品、その上で動くプログラムなどもサービスを呼び出す利用者となり得る。クライアント１０１とＵＡ１０６とサービス１０３は、これらの任意の組み合わせが、同一システム内で稼働することもある。具体的には、ウェブＷｅｂブラウザの同等の機能を有する文書編集アプリケーションなどが、クライアント１０１とＵＡ１０６とを含む構成として動作するといったことが考えられる。また、クライアント１０１、ＵＡ１０６、サービス１０３のいずれかが、同じ装置上で動作する機能であってもよい。

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

Ｓ２０１にて、ＵＡ１０６は、ユーザの操作によりサービス１０３にアクセスする。Ｓ２０２にて、サービス１０３は、自身が提供する機能をＵＡ１０６に登録してもらうための登録用マークアップを含むＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）応答をＵＡ１０６に返信する。

図３（ａ）は、Ｓ２０２にてサービス１０３からＵＡ１０６に返信されるＨＴＭＬ文書を例示する図である。以下、図３（ａ）の例を用いて、サービス１０３からＵＡ１０６に返信されるＨＴＭＬ文書の中身について説明する。

＜ｉｎｔｅｎｔ＞タグには、サービス１０３が提供する機能を特定し、サービス１０３が提供する機能を呼び出すための機能情報が記載されている。ａｃｔｉｏｎは、提供機能の分類情報（カテゴリ）を示す。すなわち、ａｃｔｉｏｎは、提供機能がどのような機能、サービスを提供するものであるかの分類情報を示す。なお、提供機能の分類情報には、例えば、データを共有する機能に対応する分類情報「Ｓｈａｒｅ」、データを編集する機能に対応する分類情報「Ｅｄｉｔ」、データを閲覧する機能に対応する分類情報「Ｖｉｅｗ」、データを取得する機能に対応する分類情報「Ｐｉｃｋ」、データを保存する機能に対応する分類情報「Ｓａｖｅ」等が含まれる。即ち、上記機能情報には、分類情報として、例えばＳｈａｒｅ、Ｅｄｉｔ、Ｖｉｅｗ、Ｐｉｃｋ、Ｓａｖｅのいずれかの分類情報が記載されている。

ｔｙｐｅは、提供機能が扱えるデータなどの種類を示す。すなわち、ｔｙｐｅは、ａｃｔｉｏｎに対して扱えるデータ型などを示す。ｈｒｅｆは、提供機能の接続先（ＵＲＬ）を示す。ｔｉｔｌｅは、提供機能のタイトルを示す。また、ｄｉｓｐｏｓｉｔｉｏｎは、呼び出された提供機能がどのように表示されるかを示す。

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

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

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

図３（ｂ）は、Ｓ２０４にてクライアント１０１からＵＡ１０６に返信されるＨＴＭＬ文書を例示する図である。以下、図３（ｂ）の例を用いて、クライアント１０１からＵＡ１０６に返信されるＨＴＭＬ文書の中身について説明する。

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

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

サービス１０３は、上記Ｓ２０７でＵＡ１０６から送信されたＨＴＴＰ要求を受信すると、Ｓ２０８にて、該ＨＴＴＰ要求からＷｅｂ Ｉｎｔｅｎｔオブジェクトを取り出し、ＵＡ１０６を介してユーザと相互作用しながら、選択された提供機能（ここではクライアント１０１の画像データの「共有」）の利用を実現する。

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

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

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

＜本実例における情報処理端末のＵＩ例＞
図４は、本発明の一実施例を示す情報処理端末のＵＩ例を示す図である。
図４において、５０１は、通常のモバイル端末やスマートフォンのような情報処理端末を示している。情報処理端末５０１には、携帯情報端末をターゲットとして開発されたプラットフォームであるａｎｄｒｏｉｄ（登録商標）などのＯＳ（オペレーティングシステム）がインストールされる。

図４の例では、情報処理端末５０１には、アプリケーションプログラムとして複数のＷｅｂブラウザ（ｂｒｏｗｓｅｒＡ，ｂｒｏｗｓｅｒＢ，ｂｒｏｗｓｅｒＣ）がインストールされている。これらのＷｅｂブラウザは、それぞれが図１におけるＵＡ１０６に相当するものであり、それぞれＷｅｂ Ｉｎｔｅｎｔｓを利用可能である。即ち、情報処理端末５０１は、Ｗｅｂ Ｉｎｔｅｎｔｓの中継機能を複数備えるものである。

ユーザは、Ｗｅｂブラウザ使用時に図１の１０３に相当するサービスを発見すると、必要に応じてサービスをＷｅｂブラウザに登録する。Ｗｅｂブラウザが管理している複数のサービスのリストは、Ｗｅｂブラウザ毎のものである。よって、Ｗｅｂブラウザに登録されているＷｅｂ Ｉｎｔｅｎｔｓは、Ｗｅｂブラウザ毎で異なっているのが通常である。

また、本実施例では、図４に示すようなスマートフォン型の情報処理端末を利用して説明するが、プラットフォームとして情報処理端末の形態には制限がなく、一般的なコンピュータ（例えばパーソナルコンピュータ）にも本発明は適用可能である。

＜クライアント１０１及びサービス１０３のハードウェア構成例＞
図５は、図１におけるクライアント１０１及びサービス１０３のハードウェア構成例を示すブロック図である。
クライアント１０１やサービス１０３は、汎用のコンピュータ等で構成可能である。クライアント１０１やサービス１０３は、ＣＰＵ６０２、ＲＯＭ６０３と、ＲＡＭ６０４を含む。ＣＰＵ６０２は、ＲＯＭ６０３や後述する記憶装置６０８に格納されているプログラムを読み出して実行することにより、装置全体を統括制御する。ＲＯＭ６０３は、システム起動に必要なブートプログラムを記憶するための読み出し専用メモリである。ＲＡＭ６０４は、ＣＰＵ６０２でプログラムを実行する際に必要とされる作業メモリである。

ネットワークインタフェース（Ｎｅｔｗｏｒｋ Ｉ／Ｆ）６０５は、ネットワーク（Ｎｅｔｗｏｒｋ）を介して通信を行う。表示制御部６０６は、表示デバイス６０９の表示を制御する。例えば、表示制御部６０６は、Ｗｅｂサーバを管理するため等の画面表示を制御する。表示デバイス６０９は、表示制御部６０６にて制御された出力信号をＷｅｂサーバ管理者であるオペレータに表示する。入力制御部６０７は、入力デバイス６１０や６１１から受信した入力信号を制御する。入力デバイス６１０は例えばマウス等のポインティングデバイスで、入力デバイス６１１はキーボード等であり、オペレータからの入力を受け付ける。

記憶装置６０８は、ＣＰＵ６０２で実行するプログラムや各種情報を格納する例えば磁気ディスクやフラッシュメモリ等の不揮発性の記憶装置である。クライアント１０１の場合、記憶装置６０８に、クライアント１０１にて提供するコンテンツ情報なども格納する。また、サービス１０３の場合、記憶装置６０８に、サービス１０３が機能を提供するために必要なデータとプログラムなども格納する。

なお、本実施例で示すクライアント１０１、サービス１０３の処理は、それぞれ、クライアント１０１、サービス１０３のＣＰＵ６０２が記憶装置６０８に格納されるプログラムを読み出して実行することにより実現されるものである。

＜情報処理端末５０１のハードウェア構成例＞
図６は、情報処理端末５０１のハードウェア構成を示すブロック図であり、図１におけるＵＡ１０６は、このハードウェア上で実行される。図６に記載の情報処理端末５０１は、通常のモバイル端末やスマートフォンであり、小型端末用のオペレーティングシステムや、通話、データ通信を制御するプログラムが動いている。

情報処理端末５０１のハードウェアの各構成要素は、システムバス８０１に接続されている。ＲＯＭ８０３には、情報処理端末５０１におけるオペレーティングシステム及び、通話、データ通信を制御するアプリケーション等が格納されており、ＣＰＵ８０２により読み出されて実行される。なお、データ通信を制御するアプリケーションには、例えば、ＭａｉｌソフトやＷｅｂブラウザなどがある。

ＲＡＭ８０４は、プログラムを実行するためのワークメモリエリアである。また、ＲＡＭ８０４は、ＷｅｂブラウザがＷｅｂサーバから取得してきたＷｅｂページデータやＷｅｂサービスにアクセスするための認証情報などを一時記憶するためのメモリでもある。記憶装置８０９は不揮発性の記憶装置であり、情報処理端末５０１の再起動後も保持しておく必要のある各種動作モード設定や、稼働ログなどが記憶される。

ネットワークコントローラ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）８０５は、無線ＬＡＮに参加するための無線ＬＡＮ通信部８１１と、携帯キャリアの提供するネットワークに参加するための携帯電話データ通信部８１２の通信制御を行う。一般的に無線ＬＡＮのネットワークに参加できるとき、ネットワークコントローラ８０５は、無線ＬＡＮ通信部８１１を介した無線ＬＡＮの接続を優先する。なお、情報処理端末５０１が無線ＬＡＮのネットワークエリアから外れた場合には、携帯電話データ通信部８１２を介したネットワークコントローラ８０５は、携帯キャリアが提供する無線通信ネットワークへ参加する。

音声制御部８０６は、主に通話アプリケーションが起動しユーザが電話をしているときに利用する。マイク・スピーカ８１３にて音声データの入出力を行い、音声制御部８０６は、その制御プログラムとの仲介を行っている。表示制御部８０７は、情報処理端末５０１のディスプレイ８１４にて出力する情報の制御を行っている。入力制御部８０８は、情報処理端末５０１のボタンやタッチパネル８１５を介してユーザが指示した情報の制御を行っている。これらの音声制御部８０６、表示制御部８０７、入力制御部８０８を利用して、情報処理端末５０１上でのアプリケーションは、ネットワーク通信情報や情報処理端末５０１のさまざまな情報をユーザに提供する。位置検出制御部８１０は、ＧＰＳセンサー８１６から情報処理端末５０１の位置情報を取得しオペレーティングシステムに提供する。これらの制御は、ＣＰＵ８０２で動くオペレーティングシステムにて制御される。

なお、本実施例で示すＵＡ１０６は、情報処理端末５０１のＣＰＵ８０２がＲＯＭ８０３に格納されるプログラムを読み出して実行することにより実現されるものである。

＜情報処理端末５０１のソフトウェア構成例＞
図７は、図４における情報処理端末５０１のソフトウェア構成を示すブロック図である。図７では、主に、本発明に関係のあるアプリケーションのＷｅｂ Ｉｎｔｅｎｔｓリクエスト発行に係る技術と、インテントを利用した機能情報の相互利用に係る機能を説明する。なお、インテントとは、任意のアプリケーション間でデータを送受信する技術である。これは、携帯情報端末をターゲットとして開発されたプラットフォームであるａｎｄｒｏｉｄ（登録商標）上で、利用可能な技術である。また、類似の技術が、他のプラットフォームでも実装されているが、本実施例では、情報処理端末内のアプリケーション間でデータの送受信を行う技術をインテントと呼ぶ。

図７において、５０１は、図４に示した情報処理端末である。ここでは、情報処理端末５０１をモバイル端末やスマートフォンとして説明する。情報処理端末には、一般的に機器を制御するためのオペレーティングシステム（以下、ＯＳ）が動いており、図７ではＯＳ部９０１として表している。また、情報処理端末５０１には、複数のアプリケーションをインストールすることができる。このアプリケーションを図７ではアプリケーション部９０２として表している。図７では、アプリケーション部を１つしか記載していないが、実際には、情報処理端末５０１には複数のアプリケーションがインストールされている。

本発明では、情報処理端末５０１のオペレーティングシステム上で図１のＵＡ１０６として動作するアプリケーションが、情報処理端末５０１内で複数動作する環境を想定している。なお、本実施例では、ＵＡ１０６として動作するアプリケーションの一例としてＷｅｂブラウザを用いて説明するが、ＵＡ１０６として動作するアプリケーションであればどのようなアプリケーションであってもよい。例えば、表計算ソフトのようなアプリケーションがＵＡ１０６の機能を提供するものであってもよい。また、ＯＳがＵＡ１０６として動作する場合も本発明に含まれるものとする。

本実施例で想定しているアプリケーションは、ＷｅｂブラウザのようなＷｅｂ ＩｎｔｅｎｔｓをＵＡ１０６として制御できるアプリケーションであり、また同時に、アプリケーション間でデータの送受信を行うことができるアプリケーションである。アプリケーション間でデータを送受信する技術としては、インテントの他に、Ｗｅｂ Ｉｎｔｅｎｔｓなどがある。実施例１では、インテントを利用してアプリケーション間でデータを送受信する実施例を示す。また、後述する実施例２では、Ｗｅｂ Ｉｎｔｅｎｔｓを利用してアプリケーション間でデータを送受信する実施例を示す。しかし、ここで想定するアプリケーションは、任意のアプリケーション間で、データの送受信を行うことができればよく、特にインテントやＷｅｂ Ｉｎｔｅｎｔｓに限定しない。

なお、図７に示すＯＳ部９０１やアプリケーション部９０２は、情報処理端末５０１のＣＰＵ８０２がＲＯＭ８０３に格納されるＯＳやアプリーションプログラムを読み出して実行することにより実現されるものである。

まず、ＯＳ部９０１について説明する。
ＯＳ部９０１において、９０６はネットワーク制御部である。ネットワーク制御部９０６は、図６のネットワークコントローラ８０５を制御する。情報処理端末５０１は、小型携帯端末であるため移動して利用することが想定されており、ネットワーク制御部９０６は、その場所に応じてアクセス可能なネットワークへ自動的に接続を行う。また、アプリケーション部９０２からの通信リクエストに応じて外部へ通信を行う。また、ネットワーク制御部９０６は、外部からのネットワーク接続要求に対応し、適切なアプリケーション部９０２へと接続要求を振り分ける。

９０４はインテント情報入出力部、９０５はアプリケーション情報格納部である。ＯＳ部９０１は、アプリケーション部９０２からアクションやタイプ（以下、データ型）の情報とともにインテント要求を受けると、そのアクションとデータ型に対応したアプリケーションをインテント情報入出力部９０４に要求する。インテント情報入出力部９０４は、インテント要求を受けると、受信したアクションとデータ型に対応するアプリケーションのリストをアプリケーション情報格納部９０５から取得する。そして、インテント情報入出力部９０４は、取得したアプリケーションのリストをアプリケーション部９０２へ送信する。

また、９０３はユーザ入出力部で、図６の音声制御部８０６、表示制御部８０７、入力制御部８０８を統括して管理する。ユーザ入出力部９０３は、アプリケーション部９０２からユーザへの表示指示があると表示制御部８０７を介してディスプレイ８１４へ表示を行う。また、ユーザがタッチパネル８１５を介して入力を行うと、ユーザ入出力部９０３は、入力制御部８０８にて制御された入力信号をアプリケーション部９０２へと伝える。

次に、アプリケーション部９０２について説明する。
アプリケーション部９０２は、サービス情報管理部９０８、中央処理部９０７、サービス情報検出部９０９、サービス情報入出力部９１０、サービス情報格納部９１１を有する。

９０７は中央処理部で、Ｗｅｂブラウザとして中心的な働きをする。この中央処理部９０７の基本的な役割は、Ｗｅｂ ＩｎｔｅｎｔｓにおけるＵＡ１０６である。そのほかにも中央処理部９０７は、基本的なブラウジング処理や、サービス１０３を検知した時の処理、サービス１０３を利用する際の制御処理、また、インテントを通じたデータの送受信なども行う。例えば、中央処理部９０７は、インテントを利用して、他のアプリケーションから機能情報（サービス１０３が提供する機能を登録するための機能情報）の取得要求に応じたり、他のアプリケーションへ機能情報の登録リクエストを発行したりする。また、中央処理部９０７は、ＯＳ部９０１のインテントを利用しない場合には、後述する実施例２に示すように、サービス情報管理部９０８を用いて、機能情報を他のアプリケーションから取得、または、提供することも可能である。また、中央処理部９０７は、サービス情報管理部９０８を用いて、他のアプリケーションから機能情報の取得要求に応じたり、他のアプリケーションへ機能情報の登録リクエストを発行したりする。なお、サービス情報管理部９０８については、後述する実施例２で説明する。

サービス情報検出部９０９は、アクセス時にサービス１０３から受信したＷｅｂページに含まれる＜ｉｎｔｅｎｔ＞タグを検出し、サービス１０３が提供する機能を登録するための機能情報を認識する。サービス情報入出力部９１０は、サービス情報格納部９１１への機能情報の入出力を制御する。サービス情報格納部９１１には、図８に示すような情報が格納される。

図８は、ＵＡとしてのＷｅｂブラウザにて管理される機能情報を例示する図である。
例えば、図８に示す例では、サービスが提供する提供機能の名称１４０１、提供機能の接続先ＵＲＩ１４０２、Ｗｅｂ Ｉｎｔｅｎｔｓリクエストを受け付ける際のアクション（ａｃｔｉｏｎ）１４０３、データ型（ｔｙｐｅ）１４０４などを含む情報がサービス情報格納部９１１に格納されている。

以下、アプリケーション部９０２の各モジュールの動きを簡単に説明する。
ユーザが情報処理端末５０１のアプリケーションであるＷｅｂブラウザ（ＵＡ１０６に対応）を利用して、Ｗｅｂ Ｉｎｔｎｔｓの仕組みを利用した或るサービス（Ｗｅｂサイト）へアクセスする。すると、アプリケーション部９０２のサービス情報検出部９０９は、アクセス時にサービスから受信したＷｅｂページに含まれる＜ｉｎｔｅｎｔ＞タグを検出し、サービスが提供する機能を登録するための機能情報（Ｗｅｂ Ｉｎｔｅｎｔｓサービス情報）を認識し、中央処理部９０７へ通知する。通知をうけた中央処理部９０７は、ユーザ入出力部９０３を介してユーザに対して、この機能情報をＷｅｂ Ｉｎｔｅｎｔとして登録するか否かの選択を仰ぐ。ここで、ユーザから登録が指示された場合、中央処理部９０７は、サービス情報入出力部９１０へ上記＜ｉｎｔｅｎｔ＞タグで特定される機能情報を保管する指示を発行する。サービス情報入出力部９１０は、上記機能情報の保管指示を受けると、サービス情報格納部９１１へ上記機能情報を格納する。

なお、情報処理端末５０１は、ユーザに機能情報を登録するか否かの選択を仰ぐ際に、情報処理端末５０１内または外の他のアプリケーションに対しても機能情報を登録するか否かの選択をユーザに仰ぐ。例えば、ここでの情報処理端末５０１の画面例を図１０（ａ）に示す。ユーザが、この画面で「ＯＫ」ボタン１１０２を押下すると、操作中のアプリケーションに上記機能情報が登録される。また、ユーザが「Ｏｐｔｉｏｎ」ボタン１１０３を押下すると、他の登録候補となるアプリケーションが表示され、選択されたアプリケーションに上記機能情報が登録される。

情報処理端末５０１の処理としては、ユーザから他のアプリケーションに対する登録指示を受けた場合、中央処理部９０７は、機能情報をインテント（後述する実施例２ではＷｅｂ Ｉｎｔｅｎｔｓ）を利用して他のアプリケーションに登録依頼を発行する。例えば、インテントを利用する場合、ＯＳ部９０１のインテント情報入出力部９０４に機能情報の登録を受け付けるアプリケーションリストの登録依頼を発行する。登録依頼を受け取ったインテント情報入出力部９０４は、対応するアプリケーションのリストをアプリケーション情報格納部９０５から取得し、応答として返す。インテントによって機能情報を登録可能なアプリケーションのリストを受信した中央処理部９０７は、ユーザ入出力部９０３を介して、アプリケーションリストを表示する。ここでユーザは登録したい対象のアプリケーションを選択し、アプリケーションのリストを返すと、中央処理部９０７は、インテントを利用して、上記選択された他のアプリケーションへ機能情報の登録依頼を発行する。

また逆に、他のアプリケーションからインテントにより機能情報の登録指示を受けると、中央処理部９０７は、サービス情報管理部９０８に処理依頼を発行する。サービス情報管理部９０８は、リクエストが適切であることを判定すると、サービス情報入出力部９１０を介してサービス情報格納部９１１へ機能情報の登録を行う。

なお、ユーザがサービスに処理を依頼する場合、中央処理部９０７は、サービス情報入出力部９１０を介して、サービス情報格納部９１１から機能情報を取得する。そして、中央処理部９０７は、該取得した機能情報の一覧を表示し、該一覧から選択された機能情報に対応するサービスに対してＷｅｂ Ｉｎｔｅｎｔｓ処理要求とコンテンツ情報を送信する。

＜実施例１おける機能情報の相互利用に関するシーケンス図の例＞
図９は、情報処理端末５０１のユーザがあるＷｅｂブラウザを用いてＷｅｂ Ｉｎｔｅｎｔｓを検出した際に、自Ｗｅｂブラウザだけでなく他のＷｅｂブラウザに機能情報の登録を依頼する動作例を説明するためのシーケンス図である。なお、図９では、図２で説明したＷｅｂ Ｉｎｔｅｎｔｓの基本シーケンスに拡張を行っている。図９中、９０２は情報処理端末５０１内のＷｅｂブラウザを想定しており、Ｗｅｂ Ｉｎｔｅｎｔｓの役割としてはＵＡとなる。図９では、ＵＡが複数存在し、機能情報を検出する側のＷｅｂブラウザをＵｓｅｒＡｇｅｎｔ.１（以下、ＵＡ.１）とし、検出された機能情報が提供される側のＷｅｂブラウザをＵｓｅｒＡｇｅｎｔ.２（以下、ＵＡ.２）とする。
なお、図１０は、ＵＡ.１のＷｅｂブラウザ画面に表示される画面を例示する図である。
また、図１１、図１２は、図９のシーケンスの一部の詳細シーケンス図である。

図９のＳ１００１では、ユーザ指示に応じてＵＡ.１がクライアント１０１にアクセスをする。すると、ＵＡ.１は、Ｓ１００２にて、サービス１０３が提供する機能の機能情報を表す＜ｉｎｔｅｎｔ＞タグを含んだＨＴＭＬ情報を受信する。Ｓ１００３にて、情報処理端末５０１のサービス情報検出部９０９は、アクセスしたＷｅｂサイトが、機能を提供していることを検出する。さらに、サービス情報検出部９０９は、アクセスしたサービス１０３が初めて訪れたサイトであることを検出する。すると、ＵＡ.１は、ユーザにこのＷｅｂサイトの提供する機能の機能情報を登録するか否かを確認するために、Ｓ１００４で、図１０（ａ）に示すような、機能情報の登録画面を表示する。

Ｓ１００４で表示する画面には、図１０（ａ）に示すように、「Ｃａｎｃｅｌ」ボタン１１０１、「ＯＫ」ボタン１１０２、「Ｏｐｔｉｏｎ」ボタン１１０３が表示されている。「Ｃａｎｃｅｌ」ボタン１１０１を押下すると、機能情報の登録をキャンセルすることができる。「ＯＫ」ボタン１１０２を押下すると、機能情報を自身に登録することができる。「Ｏｐｔｉｏｎ」ボタン１１０３を押下すると、機能情報を複数のＵＡに登録することができる。本シーケンス図では、複数のＵＡに機能情報を登録する処理について記載する。

Ｓ１００５にて、ＵＡ.１は、「Ｏｐｔｉｏｎ」ボタン１１０３が押下されたことを検知すると、Ｓ１００６に処理を進める。Ｓ１００６では、ＵＡ.１は、ＯＳ部９０１に対して、ＵＡリストの取得リクエストを発行し、Ｓ１００７にて、ＵＡリストを応答として受信する。

以下、Ｓ１００６〜Ｓ１００７について図１１（ａ）を用いて詳細に説明する。
図１１（ａ）に示すように、Ｓ１００６にて、ＵＡ.１は、インテント技術を利用して、機能情報を登録可能なアプリケーションのリストを取得するためのリクエストの発行を行う。例えば、Ａｃｔiｏｎに相当するものとして「Ｓｈａｒｅ」をリクエストし、データタイプとして「ａｐｐｌｉｃａｔｉｏｎ／Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」をリクエストする。Ｓ１００７にて、ＵＡ.１は、ＯＳ部９０１からインテントの応答として、リクエストに対応するアプリケーションのリストを受信する。

次に、図９のＳ１００８にて、ＵＡ.１は、機能情報の登録を受け付けるアプリケーションのリスト（Ｓ１００７で受信）であるＵＡリストをユーザ画面に表示する。このときのＵＡ.１のＷｅｂブラウザ画面では、図１０（ｂ）に示すような指定画面を表示する。図１０（ｂ）に示す画面には、ＵＡリスト１１０４、「Ｃａｎｃｅｌ」ボタン１１０５、「ＯＫ」ボタン１１０６が表示されている。なお、このＵＡリスト１１０４には、ＵＡ.１も含めてもよい。「Ｃａｎｃｅｌ」ボタン１１０５を押下すると、ＵＡの選択をキャンセルすることができる。ＵＡリスト１１０４から機能情報を登録したいアプリケーション（ＵＡ）を１つ以上選択指定した状態で「ＯＫ」ボタン１１０６を押下すると、機能情報の登録を依頼するＵＡの選択指定を確定することができる。

Ｓ１００９にて、ＵＡ.１は、図１０（ｂ）の画面で１つ以上のアプリケーション（ＵＡ）が選択されたことを検知すると、Ｓ１０１０に処理を移行する。Ｓ１０１０にて、ＵＡ.１は、インテントを利用して、上記選択されたアプリケーション（ここではＵＡ.２とする）に対して、機能情報の登録依頼を発行し、Ｓ１０１１にて、応答として登録処理結果を受信する。

以下、Ｓ１０１０〜Ｓ１０１１について図１１（ｂ）を用いて詳細に説明する。
図１１（ａ）に示すように、Ｓ１０１１にて、ＵＡ.１は、インテント技術を利用し、データ（機能情報）を送信する。この際、Ａｃｔｉｏｎを「Ｓｈａｒｅ」、Ｔｙｐｅを「ａｐｐｌｉｃａｔｉｏｎ／Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」として機能情報の登録依頼を発行する。ここで送信するデータタイプは、例えば図１２に示すようなデータ構成である。そして、Ｓ１０１１では、ＵＡ.１は、ＵＡ.２より、登録リクエストの処理結果を応答として受信する。

図１２は、Ｓ１０１０でＵＡ.１からＵＡ.２送信される機能情報のデータ構成を例示する図である。
図１２に示すように、機能情報のデータには、提供機能の名称と、提供機能を受け付けるＵＲＩ、また、提供機能を提供する際のアクション（ａｃｔｉｏｎ）とデータの型（ｔｙｐｅ）が含まれている。

なお、上述した図９のＳ１００９〜Ｓ１０１１に示したＵＡの選択を検知し該選択されたＵＡに機能情報の登録依頼を発行する処理は、ユーザがＵＡを選択した回数分繰り返される（Ｓ１０１２）。以上にようにして、ＵＡ.１が検出した機能情報を他のＵＡで管理する機能情報としても登録することができる。

＜実施例１のＵＡの処理フローチャートの例＞
図１３は、ＵＡがサービスから＜ｉｎｔｅｎｔ＞タグを含むＨＴＭＬを受信してから、機能情報を外部のアプリケーションに登録するまでの処理を例示するフローチャートである。なお、図１３及び後述する図１４に示すフローチャートの処理は、図７に示す情報処理端末５０１内のソフトウェアの処理の一部を示したものである。これらのフローチャートの処理は、情報処理端末５０１のＣＰＵ８０２が、ＲＯＭ８０３、記憶装置８０９等に記憶されたプログラムを必要に応じてＲＡＭ８０４に展開して実行することにより実現される。

Ｓ１７０１にて、情報処理端末５０１のネットワーク制御部９０６は、サービス１０３から＜ｉｎｔｅｎｔ＞タグを含むＨＴＭＬを受信すると、処理をＳ１７０２へ進める。Ｓ１７０２では、中央処理部９０７は、受信したＨＴＭＬ情報からＷｅｂブラウザ画面を構成しユーザに表示する。そして、処理をＳ１７０３へ進める。

Ｓ１７０３では、サービス情報検出部９０９は、上記Ｓ１７０１で受信したＨＴＭＬに＜ｉｎｔｅｎｔ＞タグがあることを検知し、アクセスしたＷｅｂサイトで機能を提供していることを把握する。すると、中央処理部９０７は、ユーザに対してアクセスしたサービスが提供する機能の機能情報をＵＡに登録するか否かを問うウィンドウ（例えば図１０（ａ））を表示し、処理をＳ１７０４へ進める。

Ｓ１７０４では、中央処理部９０７は、機能情報の登録指示を受信した（図１０（ａ）の「ＯＫ」ボタン１１０２が押下された）か否かを判断する。ここで機能情報の登録指示を受けたと判断した場合（Ｓ１７０４でＹｅｓの場合）、中央処理部９０７は、処理をＳ１７０５へ進める。Ｓ１７０５では、中央処理部９０７は、サービス情報入出力部９１０に対して、機能情報の登録指示を発行し、該機能情報のＵＡへの登録が完了したら、Ｗｅｂブラウザに制御を返す。そして、処理を終了する（Ｓ１７０９）。

一方、上記Ｓ１７０４にて、機能情報の登録指示を受けなかったと判断した場合（Ｓ１７０４でＮｏの場合）、中央処理部９０７は、処理をＳ１７０６へ進める。Ｓ１７０６では、中央処理部９０７は、機能情報の登録Ｏｐｔｉｏｎ指示を受信した（図１０（ａ）の「Ｏｐｔｉｏｎ」ボタン１１０３が押下された）か否かを判断する。ここで機能情報の登録Ｏｐｔｉｏｎ指示を受けたと判断した場合（Ｓ１７０６でＹｅｓの場合）、中央処理部９０７は、処理をＳ１７０７へ進める。Ｓ１７０７では、機能情報の他ＵＡへの登録処理を実行する。なお、実施例１におけるＳ１７０７の詳細は、後述する図１４に示す。そして、上記Ｓ１７０７の処理を終了すると、中央処理部９０７は、Ｗｅｂブラウザに制御を返す。そして、処理を終了する（Ｓ１７０９）。

一方、上記Ｓ１７０６にて機能情報の登録Ｏｐｔｉｏｎ指示を受信しなかったと判定した場合（Ｓ１７０６でＮｏの場合）、中央処理部９０７は、処理をＳ１７０８へ進める。この場合は、ユーザからＣａｎｃｅｌ指示を受信した（図１０（ａ）の「Ｃａｎｃｅｌ」ボタン１１０１が押下された）場合に対応するため、中央処理部９０７は、Ｓ１７０８にて、上記Ｓ１７０３にて表示した登録問い合わせのためウィンドウ（図１０（ａ））を閉じ、Ｗｅｂブラウザに制御を返す。そして、処理を終了する（Ｓ１７０９）。

＜機能情報の他ＵＡへの登録処理のフローチャート＞
図１４は、実施例１における機能情報の他ＵＡへの登録処理（図１３のＳ１７０７）の詳細を示すフローチャートである。

図１３のＳ１７０７に示した機能情報の他ＵＡへの登録処理を開始すると（Ｓ１７２１）、中央処理部９０７は、Ｓ１７２２へ処理を進める。Ｓ１７２２では、中央処理部９０７は、ＯＳ部９０１に対してアクションを「Ｓｈａｒｅ」、データタイプを「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」としてインテントのリクエストを発行し、処理をＳ１７２３へ進める。

Ｓ１７２３では、中央処理部９０７は、ＯＳ部９０１からインテントにてリクエストした応答として、１つ以上のアプリケーションからなるリストを受信したか否かを判定する。そして、１つ以上のアプリケーションからなるリストを受信できなかったと判定した場合（Ｓ１７２３でＮｏの場合）、中央処理部９０７は、処理をＳ１７２４へ進める。Ｓ１７２４では、中央処理部９０７は、インテントで対応するアプリケーションを探したがデバイス内に対応するアプリケーションが存在しないことをユーザに通知し（例えばメッセージを画面表示し）、処理をＳ１７２５へ進め、図１３のＳ１７０４へ処理を戻す。

一方、１つ以上のアプリケーションからなるリストを受信したと判定した場合（Ｓ１７２３でＹｅｓの場合）、中央処理部９０７は、処理をＳ１７２６へ進める。Ｓ１７２６では、中央処理部９０７は、ユーザ入出力９０３を介してユーザへ上記Ｓ１７２３にて取得したアプリケーションのリストを含む画面（例えば図１０（ｂ））を表示し、処理をＳ１７２７へ進める。

Ｓ１７２７では、中央処理部９０７は、上記Ｓ１７２６にて表示したアプリケーションリストの中から１つ以上のアプリケーションがユーザにより選択されたか否かを検知する。ここでアプリケーションが選択された画面例は、図１０（ｂ）のような画面となる。図１０（ｂ）では、機能情報を登録するＵＡとして「ｂｒｏｗｓｅｒＡ」及び「ｂｒｏｗｓｅｒＢ」が指定されている状態が示されている。

上記Ｓ１７２７にて、「Ｃａｎｃｅｌ」ボタン１１０５が押下されアプリケーションが選択されなかったと判断した場合（Ｓ１７２７でＮｏの場合）、中央処理部９０７は、処理をＳ１７２５へ進め、図１３のＳ１７０４へ処理を戻す。

一方、上記Ｓ１７２７で、１つ以上のアプリケーションが選択され「ＯＫ」ボタン１１０６が押下されたと判断した場合（Ｓ１７２７でＹｅｓの場合）、中央処理部９０７は、処理をＳ１７２８へ進める。

Ｓ１７２８では、中央処理部９０７は、上記Ｓ１７２６にて選択された１つ以上のアプリケーションのうち、１つを選択し、処理をＳ１７２９へ進める。Ｓ１７２９では、中央処理部９０７は、上記Ｓ１７２８で選択されたアプリケーションに対して、アクションを「Ｓｈａｒｅ」、データタイプを「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」とし、インテントを利用した、機能情報の登録要求を発行する。この要求を受けたアプリケーションは、機能情報の登録を行い、応答として登録結果を返す。なお、このデータの送受信は実際にはＯＳ部９０１を介して行われるが、ここでは簡略化して説明する。そして、中央処理部９０７は、上記Ｓ１７２９にて発行した登録要求の応答を受信し、上記Ｓ１７２８で選択したアプリケーションの処理を終えると、Ｓ１７３０にて、アプリケーションリストから上記Ｓ１７２８で選択したアプリケーションを削除し、処理をＳ１７３１へ進める。

Ｓ１７３１では、中央処理部９０７は、上記Ｓ１７２３で受信したアプリケーションのリストが空になったか否かを判断する。そして、アプリケーションのリストにまだ１つ以上のアプリケーションが残っていると判断した場合（Ｓ１７３１でＮｏの場合）、中央処理部９０７は、処理をＳ１７２８へと戻す。

一方、上記Ｓ１７３１にて、アプリケーションのリストが空になっていると判断した場合（Ｓ１７３１でＹｅｓの場合）、中央処理部９０７は、処理をＳ１７３２へと進める。Ｓ１７３２まで処理が進むと、ユーザの望んだすべてのアプリケーション（ＵＡ）に機能情報が登録されたこととなり、中央処理部９０７は、登録処理に利用したウィンドウ（図１０（ｂ））を閉じ、Ｗｅｂブラウザに制御を返す。そして、機能情報の他ＵＡへの登録処理を終了する（Ｓ１７３３）。

以上説明したように、実施例１によれば、同じ情報処理端末内に複数のＵＡが存在する場合に、あるＵＡで検出した機能情報を、インテントの仕組みを用いて、複数のＵＡに登録することができる。

上記実施例１では、例えばａｎｄｒｏｉｄ（登録商標）系プラットフォームのインテントを利用して他のＵＡに機能情報を登録要求する構成について説明した。これに対し、実施例２では、インテントを利用せず、Ｗ３ＣのＷｅｂ Ｉｎｔｅｎｔｓを利用して他のＵＡに機能情報を登録要求する構成について説明する。

図７に示したアプリケーション部９０２のサービス情報管理部９０８は、ＨＴＴＰクライアントの機能およびＷｅｂ Ｉｎｔｅｎｔｓサービスの機能を有する。サービス情報管理部９０８は、Ｗｅｂ Ｉｎｔｅｎｔｓの仕組みを利用して外部のアプリケーションへ機能情報の登録依頼を発行する。また、サービス情報管理部９０８は、Ｗｅｂ Ｉｎｔｅｎｔｓの仕組みを利用して外部アプリケーションからアクションおよびデータのタイプ情報とともに機能情報の登録依頼を受け付けると、中央処理部９０７、サービス情報入出力９１０を介してサービス情報格納部９１１に機能情報を登録する。

＜実施例２における機能情報の相互利用に関する他のシーケンス図の例＞
図１５は、実施例２において情報処理端末５０１のユーザがあるＷｅｂブラウザを用いてＷｅｂ Ｉｎｔｅｎｔｓを検出した際に、自Ｗｅｂブラウザだけでなく他のＷｅｂブラウザに機能情報の登録を依頼する動作例を説明するためのシーケンス図である。なお、図９と同一のステップには同一のステップ番号を付してある。以下、図９と異なる部分のみ説明する。
なお、図１６は、図１５のシーケンスの一部の詳細シーケンス図である。

Ｓ１００１〜Ｓ１００５の処理は、図９と同様であるので説明を省略する。実施例２の情報処理端末５０１では、ローカルエリアネットワーク（Ｌｏｃａｌ Ｎｅｔｗｏｒｋ）１５０１から機能情報を提供可能なアプリケーションまたはサービス（以下、単にサービスという）を探索する。具体的には、Ｓ１００５にて、ＵＡ.１は、「Ｏｐｔｉｏｎ」ボタン１１０３（図１０（ａ））が押下されたことを検知すると、Ｓ１６０１にて、Ｌｏｃａｌ Ｎｅｔｗｏｒｋ１５０１に対してサービスの探索を実行する。このネットワーク探索に関して、以下、図１６を用いて詳細に説明する。

図１６に示すように、ＵＡ.１は、Ｓ１６０１にて、Ｌｏｃａｌ Ｎｅｔｗｏｒｋ１５０１に対してサービスの探索を行う。ここでは、例えば、Ａｐｐｌｅ社のゼロ・コンフィギュレーション技術であるＢｏｎｊｏｕｒにおけるＭｕｌｔｉｃａｓｔＤＮＳなどの技術を用いてリンクローカル内のネットワークサービスを探索する。
Ｓ１６０２にて、ＵＡ.１は、各サービスから応答を受ける。本実施例では、Ｌｏｃａｌ Ｎｅｔｗｏｒｋ１５０１内で探索を行うので、同じ情報処理端末内のサービスから応答を受けることの他に、ネットワークの届く範囲にあるサービスからも応答を受けることができる。このネットワークの範囲は、ここでは限定しない。

次に、ＵＡ.１は、Ｓ１６０３にて、上記Ｓ１６０２で応答を受けたサービスから、データ型に「ａｐｐｌｉｃａｔｉｏｎ／Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」、アクションに「Ｓｈａｒｅ」を提供するサービスを検出してリスト化する。なお、この際、検出に必要な情報が不足している場合には、上記Ｓ１６０２で応答を受けた各サービスにアクセスして取得してもよい。このような処理により、ローカルエリアネットワーク内に存在する機能情報を提供可能なサービスを探索することができる。
次に、Ｓ１６０４にて、ＵＡ.１は、上記Ｓ１６０３で検出したサービスのリストを表示してユーザへ提示し、Ｓ１００９に処理を進める。その後の処理は、図９と同様であるので説明を省略する。

＜実施例２の機能情報の他ＵＡへの登録処理のフローチャート＞
図１７は、実施例２における機能情報の他ＵＡへの登録処理（図１３のＳ１７０７）の詳細を示すフローチャートである。このフローチャートの処理は、情報処理端末５０１のＣＰＵ８０２が、ＲＯＭ８０３、記憶装置８０９等に記憶されたプログラムを必要に応じてＲＡＭ８０４に展開して実行することにより実現される。

図１３のＳ１７０７に示した機能情報の他ＵＡへの登録処理を開始すると（Ｓ１７４１）、中央処理部９０７は、Ｓ１７４２へ処理を進める。Ｓ１７４２では、サービス情報管理部９０８は、Ｌｏｃａｌ Ｎｅｔｗｏｒｋ１５０１に対して、Ｗｅｂ Ｉｎｔｅｎｔｓの仕組みを利用した機能を提供しているアプリケーションまたはサービス（以下、単にサービス）を探索する（図１５及び図１６のＳ１６０１〜Ｓ１６０４に対応）。探索対象は、アクションを「Ｓｈａｒｅ」、データ型「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」としているサービスである。探索のリクエストは、Ａｐｐｌｅ社のｂｏｎｊｏｕｒなどで利用しているｍｕｌｔｉｃａｓｔＤＮＳなどのサービス探索用のプロトコルを利用してリクエストを発行する。

次に、Ｓ１７４３において、サービス情報管理部９０８は、上記Ｓ１７４２の探索の結果、対応する１以上のサービスを発見したか否かを判定する。そして、サービス情報管理部９０８は、対応する１以上のサービスを発見できなかったと判定した場合（Ｓ１７４３でＮｏの場合）、処理をＳ１７４４へ進める。Ｓ１７４４では、サービス情報管理部９０８は、中央処理部９０７を介して、サービスを探した結果として、ネットワーク探索範囲内に対応するサービスが存在しないことをユーザに通知し（例えばメッセージを画面表示し）、処理をＳ１７４５へ進め、図１３のＳ１７０４へ処理を戻す。

一方、１つ以上のサービスからなるリストを受信したと判定した場合（Ｓ１７４３でＹｅｓの場合）、サービス情報管理部９０８は、処理をＳ１７４６へ進める。Ｓ１７４６では、中央処理部９０７は、ユーザ入出力９０３を介して、ユーザへ上記Ｓ１７４３にて取得したサービスのリストを含む画面（例えば図１０（ｂ））を表示し、処理をＳ１７４７へ進める。

Ｓ１７４７では、中央処理部９０７は、上記Ｓ１７４６にて表示したサービスリスト（例えば図１０（ｂ）の１１０４）の中から１つ以上のサービスがユーザにより選択されたか否かを検知する。ここでサービスが選択された画面例は、図１０（ｂ）のような画面となる。図１０（ｂ）では、機能情報を登録するＵＡとして「ｂｒｏｗｓｅｒＡ」及び「ｂｒｏｗｓｅｒＢ」が指定されている状態が示されている。

上記Ｓ１７４７にて、「Ｃａｎｃｅｌ」ボタン１１０５が押下されサービスが選択されなかったと判断した場合（Ｓ１７４７でＮｏの場合）、中央処理部９０７は、処理をＳ１７４５へ進め、図１３のＳ１７０４へ処理を戻す。

一方、上記Ｓ１７４７で、１つ以上のサービスが選択され「ＯＫ」ボタン１１０６が押下されたと判断した場合（Ｓ１７４７でＹｅｓの場合）、中央処理部９０７は、処理をＳ１７４８へ進める。

Ｓ１７４８では、サービス情報管理部９０８は、上記Ｓ１７４６にて選択された１つ以上のサービスのうち、１つを選択し、処理をＳ１７４９へ進める。Ｓ１７４９では、サービス情報管理部９０８は、上記Ｓ１７４８で選択されたサービスに対して、アクションを「Ｓｈａｒｅ」、データタイプを「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」とし、Ｗｅｂ Ｉｎｔｅｎｔｓを利用した、機能情報の登録要求を発行する。この要求を受けたサービスは、機能情報の登録を行い、応答として登録結果を返す。そして、サービス情報管理部９０８は、上記Ｓ１７４９にて発行した登録要求の応答を受信し、上記Ｓ１７４８で選択したサービスの処理を終えると、Ｓ１７５０にて、サービスリストから上記Ｓ１７４８で選択したサービスを削除し、処理をＳ１７５１へ進める。

Ｓ１７５１では、サービス情報管理部９０８は、上記Ｓ１７２３で受信したサービスのリストが空になったか否かを判断する。そして、サービスのリストにまだ１つ以上のサービスが残っていると判断した場合（Ｓ１７５１でＮｏの場合）、サービス情報管理部９０８は、処理をＳ１７４８へと戻す。

一方、上記Ｓ１７５１にて、サービスのリストが空になっていると判断した場合（Ｓ１７５１でＹｅｓの場合）、サービス情報管理部９０８は、処理をＳ１７５２へと進める。Ｓ１７５２まで処理が進むと、ユーザの望んだすべてのサービス（ＵＡ）に機能情報が登録されたこととなり、サービス情報管理部９０８は、中央処理部９０７を介して、登録処理に利用したウィンドウ（図１０（ｂ））を閉じ、Ｗｅｂブラウザに制御を返す。そして、機能情報の他ＵＡへの登録処理を終了する（Ｓ１７５３）。

以上説明したように、実施例２によれば、同じ情報処理端末内に複数のＵＡが存在する場合に、あるＵＡで検出した機能情報を、Ｗｅｂ Ｉｎｔｅｎｔｓの仕組みを用いて、複数のＵＡに登録することができる。

上記実施例１及び実施例２では、アプリケーションに機能情報を登録する際に他のアプリケーションにも登録することで機能情報の相互利用を実現する構成を説明した。また、機能情報の情報共有のために、実施例１ではインテントを利用し、実施例２ではＷｅｂ Ｉｎｔｅｎｔｓを利用する例についても説明した。

しかし、機能情報を発見するたびに、ユーザが登録すべきアプリケーションを選択し、一つ一つのアプリケーションに機能情報の登録依頼を発行することを煩わしい作業と感じるユーザが存在する可能性がある。ユーザは、使用しているアプリケーションのどれかに発見した機能情報を登録しておき、あるタイミングで他のアプリケーションから取り込みと共有を実行できればよい。実施例３では、あるアプリケーションを利用時に他の１つ以上のアプリケーションから機能情報を取得すること、及び、他のアプリケーションにまだ登録されていない機能情報を提供する構成について説明する。

＜実施例３おける機能情報の相互利用に関するシーケンス図の例＞
図１８は、実施例３において情報処理端末５０１のユーザがあるＷｅｂブラウザを用いて他のＷｅｂブラウザと登録されている機能情報を同期させるためのシーケンス図である。即ち、この図では、情報処理端末５０１のユーザがあるＷｅｂブラウザを利用し、他の１つ以上のＷｅｂブラウザに登録されている機能情報を取得し、さらに取得した機能情報を他のまだ登録されていないＷｅｂブラウザに提供し登録依頼を発行する動作例を説明する。なお、図１８では、図２で説明したＷｅｂ Ｉｎｔｅｎｔｓの基本シーケンスに拡張を行っている。図１８中、９０２は情報処理端末５０１内のＷｅｂブラウザを想定しており、Ｗｅｂ Ｉｎｔｅｎｔｓの役割としてはＵＡとなる。図１８では、ＵＡが複数存在する。機能情報を収集し、さらに提供するリクエストを発行するＷｅｂブラウザをＵＡ.１とする。また、インテントサービス（後述する実施例４ではＷｅｂ Ｉｎｔｅｎｔｓサービス）を提供しリクエストに応じて機能情報を提供したり、登録依頼を受け付けたりするＷｅｂブラウザをＵＡ.２とする。また、実際には、ＵＡ.２は複数存在するが、図中ではＵＡ.２を１つ用いて説明する。
なお、図１９は、ＵＡ.１のＷｅｂブラウザ画面に表示される画面を例示する図である。
また、図２０は、図１８のシーケンスの一部の詳細シーケンス図である。
さらに、図２１は、ＵＡに登録されている機能情報のマップを例示する図である。

図１８のＳ１８０１では、ユーザがＵＡ.１を利用して機能情報の取込み、及び、共有指示を発行する。ここでの情報処理端末５０１の画面例を、図１９に示す。ユーザは、Ｗｅｂブラウザを立ち上げるとアプリケーションに設定しているホーム画面が表示される。ここでは、ユーザはある検索サイトを設定しているものとし、図１９（ａ）のような画面が表示されるものとする。ここでユーザは、さらに図１９（ｂ）に示すように、Ｗｅｂブラウザメニューを表示し、このメニュー内の「サービス情報の取込／共有」メニュー１９０１（図１９（ｂ）内で「サービス情報を同期」と表記）を押下する。該「サービス情報の取込／共有」メニュー１９０１の押下を検知すると、ＵＡ.１は、機能情報の同期が指示されたと判断し、Ｓ１８０２に処理を進める。

Ｓ１８０２では、ＵＡ.１は、ＯＳ部９０１に対してインテントを利用して機能情報の提供を行うアプリケーションのリストを取得要求する。この要求に応じて、ＯＳ部９０１は、Ｓ１８０３にて、インテント情報入出力部９０４を介して機能情報の提供が可能なアプリケーションのリストをアプリケーション情報格納部９０５から取得し応答する。そして、ＵＡ.１は、この応答（アプリケーションリスト）を受信すると、Ｓ１８０４に処理を進める。

Ｓ１８０４では、ＵＡ.１は、上記Ｓ１８０３で取得したアプリケーションの１つ（ここではＵＡ.２）に対して機能情報リストの取得要求を発行する。この要求に応じて、ＵＡ.２は、Ｓ１８０５にて、自身が管理する機能情報のリストを応答する。そして、ＵＡ.１は、この応答（機能情報リスト）を受信する。

ここで、Ｓ１８０４〜Ｓ１８０５について図２０（ａ）を用いて詳細に説明する。
図２０（ａ）に示すように、Ｓ１８０４にて、ＵＡ.１は、インテント技術を利用して、機能情報を他のアプリケーションから取得するためのリクエストの発行を行う。例えば、Ａｃｔiｏｎに相当するものとして「Ｐｉｃｋ」をリクエストし、データタイプとして「ａｐｐｌｉｃａｔｉｏｎ／Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」をリクエストする。Ｓ１８０５では、上記Ｓ１８０４で発行したインテントの応答としてＵＡ.２に登録されている機能情報のリストがＵＡ.１に返される。

そして、図１８のＳ１８０６に示すように、ＵＡ.１は、上記Ｓ１８０４〜Ｓ１８０５の処理を、上記Ｓ１８０３にて取得したアプリケーションの数だけ繰り返し実行すると、Ｓ１８０７に処理を進める。

Ｓ１８０７では、ＵＡ.１は、上記Ｓ１８０６で各ＵＡから収集した機能情報リストを元にマップを生成する。このマップには、各ＵＡに登録されているそれぞれの機能情報のリスト情報が描かれる。

上記Ｓ１８０７で生成されるマップを図２１（ａ）に例示する。
図２１（ａ）に示すように、左から４列（２１０１〜２１０４）には、各ＵＡから取得できた機能情報が記されており、レコードごとにユニークに全ての機能情報が登録されている。ここでは、機能情報に対応する提供機能の名称２１０１、提供機能の接続先ＵＲＩ２１０２、Ｗｅｂ Ｉｎｔｅｎｔｓリクエストを受け付ける際のアクション（Ａｃｔｉｏｎ）２１０３、データ型（Ｔｙｐｅ）２１０４などが記録されている。左から５列目以降（２１０５〜２１０７）については可変であり、アプリケーション（ＵＡ）の数分列が登録され、各ＵＡにそのレコードに対応する機能情報が登録されているか否かを示すマップとなっている。図１８のＳ１８０７でマップが作成された際には、マップは初期の登録状態を表したものとなっており、それぞれのＵＡに各機能情報が登録されているか、否かが記されている。登録されている場合には「Ｙｅｓ」が記されており、登録されていない場合には「Ｎｏ」が記載されている。

Ｓ１８０８にて、ＵＡ.１は、マップを利用してＵＡ.１に登録のない機能情報を抽出し、その機能情報がどのアプリケーションに登録されているかを取得する。Ｓ１８０９にて、ＵＡ.１は、ＵＡ.１に登録のない機能情報の登録されているアプリケーション（ここではＵＡ.２とする）に対し、その機能情報の取得要求を、インテントを利用して発行する。Ｓ１８１０にて、ＵＡ.２は、上記Ｓ１８０９の取得要求に対する応答として、機能情報を返し、ＵＡ.１は、この応答を受信する。

ここで、Ｓ１８０８〜Ｓ１８０９について図２０（ｂ）を用いて詳細に説明する。
図２０（ｂ）に示すように、Ｓ１８０９にて、ＵＡ.１は、アクション「Ｐｉｃｋ」で、データタイプ「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」のインテント要求を発行する。ここでは、ある特定の機能情報（上述したＵＡ.１に登録のない機能情報）を指定してＵＡ.２に要求を発行する。また、Ｓ１８１０では、ＵＡ.１はＳ１８０９にて発行したインテントの応答として、上記指定した機能情報を受信する。なお、上記Ｓ１８０９〜Ｓ１８１０の処理は、ＵＡ.１に登録されていない機能情報の複数あり、それらが、それぞれ異なるアプリケーションで管理されているような場合には、ＵＡ.１に登録されていない全ての機能情報の取得が完了するまで、何度でも実行されるものとする。

次に、図１８のＳ１８１１では、ＵＡ.１は、上記Ｓ１８１０で取得した機能情報をＵＡ.１が管理する機能情報として登録し、さらに上記Ｓ１８０７で作成したマップ情報を更新する。ここで更新したマップの状態を、図２１（ｂ）に示す。図２１（ｂ）では、上述した図２１（ａ）の状態では２レコード目でＵＡ.１が管理していなかった「Ｐｈｏｔｏ Ｓｈａｒｅｓ」の機能情報が更新され、ＵＲＩ２１０２、アクション２１０３、データタイプ２１０４などが追記され、ＵＡ.１での登録状態２１０５も「Ｙｅｓ」へと更新されている。

次に、ＵＡ.１は、Ｓ１８１２にて、ＯＳ部９０１に対してインテントを利用して機能情報の登録受付を行うアプリケーションのリストを取得要求する。この要求に応じて、ＯＳ部９０１は、Ｓ１８１３にて、インテント情報入出力部９０４を介して機能情報の登録受付が可能なアプリケーションのリストをアプリケーション情報格納部９０５から取得し応答する。そして、ＵＡ.１は、この応答（アプリケーションリスト）を受信すると、Ｓ１８１４に処理を進める。

Ｓ１８１４では、ＵＡ.１は、上記取得したリスト内の各アプリケーションの登録にない機能情報リストを抽出する。図２１（ｂ）に示した例で説明すると、ＵＡ.３ ｒｅｇｉｓｔｅｒ列２１０７の「Ｎｏ」に相当するレコードに対応する機能情報のリスト（「Ｉｎｔｅｎｓ Ｓｅｒｖｉｃｅ」，「Ｐｈｏｔｏ Ｓｈａｒｅｓ」）を抽出する。

次に、Ｓ１８１５にて、ＵＡ.１は、上記リスト内のアプリケーションの１つ（ここではＵＡ.２）に対して機能情報リストの登録要求を発行する。この要求に応じて、ＵＡ.２は、Ｓ１８１６にて、機能情報を登録し登録結果を応答する。そして、ＵＡ.１は、この応答を受信する。

ここで、Ｓ１８１５〜Ｓ１８１６について図２０（ｃ）を用いて詳細に説明する。
図２０（ｃ）に示すように、Ｓ１８１５にて、ＵＡ.１は、対象となるアプリケーション（ここではＵＡ.２とする）に対して、アクション「Ｓｈａｒｅ」で、データタイプ「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」のインテント要求で、特定の機能情報（そのアプリケーションの登録されていない機能情報）とともに登録要求を発行する。Ｓ１８１６では、上記Ｓ１８１５で発行したインテントの応答として登録結果がＵＡ.１に返される。

そして、図１８のＳ１８１７に示すように、ＵＡ.１は、上記Ｓ１８１５〜Ｓ１８１６の処理を、上記Ｓ１８１３にて取得したアプリケーション毎に、上記Ｓ１８１４で抽出した機能情報の数だけそれぞれ繰り返し実行し、Ｓ１８１８に処理を進める。

Ｓ１８１８では、ＵＡ.１は、マップを更新し同期処理を完了させる。このときのマップの状態は、最終的に図２１（ｃ）に記載した状態となり、機能情報の統合が完了する。

＜実施例３のＵＡの処理フローチャートの例＞
図２２は、ＵＡがユーザからの「サービス情報の取込／共有」指示を受信してから機能情報の取込／共有処理が終了するまでの処理を例示するフローチャートである。なお、図２２及び後述する図２３〜図２５に示すフローチャートの処理は、図７に示す情報処理端末５０１内のソフトウェアの処理の一部を示したものである。これらのフローチャートの処理は、情報処理端末５０１のＣＰＵ８０２が、ＲＯＭ８０３、記憶装置８０９等に記憶されたプログラムを必要に応じてＲＡＭ８０４に展開して実行することにより実現される。

図２２のフローチャートでは、処理を大きく３つの処理に分けて説明する。
まず、ＵＡ.１は、Ｓ２４０１にてユーザによる「サービス情報の取込／共有」メニュー１９０１の押下を検知すると、ユーザより機能情報の取込／共有の指示があったと判断し、まずＳ２４０２の「機能情報の取得／共有のためのマップ生成処理」を行う（詳細は図２３に示す）。次に、ＵＡ.１は、Ｓ２４０３の「各アプリケーションからの機能情報の取得処理」を行う（詳細は図２４に示す）。さらに、ＵＡ.１は、Ｓ２４０４の「各アプリケーションへＷｅｂ Ｉｎｔｅｎｔｓサービス情報の共有処理」を行う（詳細は図２５に示す）。そして、ＵＡ.１は、Ｓ２４０５において、機能情報の取得／共有処理を終了する。

以下、上記Ｓ２４０２、Ｓ２４０３、Ｓ２４０４の処理を、各詳細フローチャートを利用して説明する。
＜機能情報の取得／共有のためのマップ作成処理のフローチャートの例＞
図２３は、図２２のＳ２４０２の機能情報の取得／共有のためのマップ生成処理の詳細を表すフローチャートである。

Ｓ２４２０にて、ＵＡ.１の中央処理部９０７は処理を開始すると、Ｓ２４２１へ処理を進める。Ｓ２４２１で、中央処理部９０７は、情報処理端末５０１にインストールされている各アプリケーションにて管理されている機能情報を収集し一括して管理するためのマップテーブルを作成する。このマップとは、図２１（ａ）にて説明したように機能情報と各ＵＡの登録情報を記録するマップである。このマップを初期化し準備が完了したら、中央処理部９０７は、処理をＳ２４２２へ進める。

Ｓ２４２２では、中央処理部９０７は、ＯＳ部９０１に対してアクションを「Ｐｉｃｋ」、データタイプを「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」としてインテントのリクエストを発行し、処理をＳ２４２３へ進める。Ｓ２４２３では、中央処理部９０７は、ＯＳ部９０１からインテントリクエストした応答として、１以上のアプリケーションの情報（アプリケーションのリスト）を受信したか否かを判定する。

そして、ＯＳ部９０１から１以上のアプリケーションの情報を受信できなかったと判定した場合（Ｓ２４２３でＮｏの場合）、中央処理部９０７は、処理をＳ２４２４へ進める。この場合は、インテントで対応するアプリケーションを探したが情報処理端末５０１内に対応するアプリケーションが存在しないことがわかった場合である。これは、機能情報を取得／共有するためのアプリケーションが情報処理端末５０１にインストールされていない環境を意味する。したがって、Ｓ２４２４では、中央処理部９０７は、ユーザに取得／共有することができない旨の通知し（例えばメッセージを画面表示し）、機能情報の取得／共有処理を終了する（Ｓ２４２４）。

一方、上記Ｓ２４２３にてＯＳ部９０１から１以上のアプリケーションの情報を受信したと判定した場合（Ｓ２４２３でＹｅｓの場合）、中央処理部９０７は、処理をＳ２４２５へ進める。Ｓ２４２５では、中央処理部９０７は、上記取得したアプリケーションの情報をリスト化し（２順目以降では行わない）、そのリストから任意に１つのアプリケーションを選択し、処理をＳ２４２６へ進める。

Ｓ２４２６では、中央処理部９０７は、上記Ｓ２４２５にて選択したアプリケーションに対して、アクション「Ｐｉｃｋ」、データタイプを「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」としインテントを利用した、機能情報リストの取得要求を発行する。そして、処理をＳ２４２７へ進める。Ｓ２４２７では、中央処理部９０７は、上記Ｓ２４２６で取得要求を行ったアプリケーションから機能情報リストを受信できたか否かを判断する。

そして、機能情報のリストを受信できなかったと判断した場合（Ｓ２４２７でＮｏの場合）、中央処理部９０７は、処理をＳ２４２９へ進める。一方、機能情報のリストを受信したと判断した場合（Ｓ２４２７でＹｅｓの場合）、中央処理部９０７は、処理をＳ２４２８へ進める。Ｓ２４２８では、中央処理部９０７は、上記Ｓ２４２５で選択したアプリケーションとそのアプリケーションから取得できた機能情報のリストを関連付けてマップの更新処理を行う。この更新処理が完了すると、中央処理部９０７は、処理をＳ２４２９へ進める。

Ｓ２４２９では、中央処理部９０７は、上記Ｓ２４２５で選択したアプリケーションをアプリケーションリストの中から削除し、処理をＳ２４３０へ進める。Ｓ２４３０では、中央処理部９０７は、アプリケーションリスト内の情報が空になっているか否かを判断する。そして、アプリケーションリスト内にまだアプリケーションがあると判断した場合（Ｓ２４３０でＮｏの場合）、中央処理部９０７は、処理をＳ２４２５へ戻す。

一方、上記Ｓ２４３０にて、アプリケーションリスト内にアプリケーションがないと判断した場合（Ｓ２４３０でＹｅｓの場合）、中央処理部９０７は、機能情報の取得／共有のためのマップ生成処理を終了し（Ｓ２４３１）、処理を図２２のＳ２４０３へ進める。

次に、図２２のＳ２４０３について図２４を用いて説明する。
＜各アプリケーションからの機能情報の取得処理のフローチャートの例＞
図２４は、図２２のＳ２４０３の各アプリケーションからの機能情報の取得処理の詳細を表すフローチャートである。

Ｓ２４６１にて、ＵＡ.１の中央処理部９０７は処理を開始すると、Ｓ２４６２へ処理を進める。Ｓ２４６２では、中央処理部９０７は、マップ（図２２のＳ２４０２で生成されたマップ）に登録されている機能情報のうち、ＵＡ.１に登録されていない機能情報（ここでは名称）を取得し、処理をＳ２４６３へ進める。Ｓ２４６３では、中央処理部９０７は、上記Ｓ２４６２にて１つ以上の機能情報の情報（機能情報のリスト）を取得できたか否かを判断する。

そして、１つ以上の機能情報の情報を取得できなかったと判断した場合（Ｓ２４６３でＮｏの場合）中央処理部９０７は、処理をＳ２４７１に進める。この場合、情報処理端末５０１内の各ＵＡに登録されている全ての機能情報をＵＡ.１は既に管理していることになる。したがって、この場合、中央処理部９０７は、Ｓ２４７１にて、各アプリケーションからの機能情報の取得処理を終了させる（Ｓ２４７１）。

一方、上記Ｓ２４６３にて、１つ以上の機能情報の情報を取得したと判断した場合（Ｓ２４６３でＹｅｓの場合）、中央処理部９０７は、処理をＳ２４６４へ進める。Ｓ２４６４では、中央処理部９０７は、上記Ｓ２４６２で取得した機能情報の情報（名称）をリスト化し（２順目以降では行わない）、任意の機能情報を１つ選択する。そして、処理をＳ２４６５へ進める。

Ｓ２４６５では、中央処理部９０７は、上記マップから、上記Ｓ２４６４にて選択した機能情報を管理しているアプリケーションの情報を取得し、処理をＳ２４６６へ進める。Ｓ２４６６では、中央処理部９０７は、上記Ｓ２４６５にて取得したアプリケーションに対して、アクション「Ｐｉｃｋ」、データタイプ「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」とし、インテントを利用した、機能情報の取得要求を発行する。そして、処理をＳ２４６７へ進める。

Ｓ２４６７では、中央処理部９０７は、上記Ｓ２４６６にて発行した取得要求の応答として機能情報を受信したか否かを判断する。そして、機能情報を受信できなかったと判定した場合（Ｓ２４６７でＮｏの場合）、中央処理部９０７は、処理をＳ２４６９へ進める。

一方、上記Ｓ２４６７にて、機能情報を受信したと判断した場合（Ｓ２４６７でＮｏの場合）、中央処理部９０７は、処理をＳ２４６８へ進める。Ｓ２４６８では、中央処理部９０７は、上記Ｓ２４６７にて取得した機能情報を用いて上記マップの情報を更新し、処理をＳ２４６９へ進める。また、中央処理部９０７は、上記Ｓ２４６７にて取得した機能情報を、サービス情報入出力部９１０を介してサービス情報格納部９１１に登録する。

Ｓ２４６９で、中央処理部９０７は、上記Ｓ２４６３で取得した機能情報のリストから、上記Ｓ２４６４にて選択した機能情報の情報を削除し、処理をＳ２４７０へ進める。Ｓ２４７０では、上記Ｓ２４６４にて作成した機能情報のリスト内にまだ機能情報が残っているか否かを判断する。そして、まだリスト内に機能情報が残っていると判断した場合（Ｓ２４７０でＮｏの場合）、中央処理部９０７は、処理をＳ２４６４へ戻す。

一方、上記Ｓ２４７０にて、リスト内に機能情報が残っていないと判断した場合（Ｓ２４７０でＹｅｓの場合）、中央処理部９０７は、各アプリケーションからの機能情報の取得処理を終了し（Ｓ２４７１）、処理を図２２のＳ２４０４へ進める。

次に、図２２のＳ２４０４について図２５を用いて説明する。
＜各アプリケーションへの機能情報の共有処理のフローチャートの例＞
図２５は、図２２のＳ２４０４の各アプリケーションへの機能情報の共有処理の詳細を表すフローチャートである。

Ｓ２４８１にて、ＵＡ.１の中央処理部９０７は処理を開始すると、Ｓ２４８２へ処理を進める。Ｓ２４８２では、中央処理部９０７は、図２２のＳ２４０３で更新されたマップに登録されている機能情報で登録していない機能情報があるアプリケーションを、上記マップから取得し、処理をＳ２４８３へ進める。

Ｓ２４８３では、中央処理部９０７は、マップから取得できたアプリケーションが１つ以上存在するか否かを判断する。そして、１つ以上のアプリケーションを取得できなかったと判断した場合（Ｓ２４８３でＮｏの場合）、中央処理部９０７は、そのまま、各アプリケーションへの機能情報の共有処理を終了する（Ｓ２４９３）。この場合、情報処理端末５０１内に登録されている全ての機能情報は全てのアプリケーションで共有されていることになるため、処理を終了する。

一方、上記Ｓ２４８３にて、１つ以上のアプリケーションを取得したと判断した場合（Ｓ２４８３でＹｅｓの場合）、中央処理部９０７は、処理をＳ２４８４へ進める。Ｓ２４８４では、中央処理部９０７は、上記Ｓ２４８３で取得した１つ以上のアプリケーションの情報をリスト化し（２順目以降では行わない）、そのリストから任意のアプリケーションを１つ選択し、処理をＳ２４８５へ進める。

Ｓ２４８５では、中央処理部９０７は、上記Ｓ２４８４で選択したアプリケーションに対して登録すべき機能情報（そのアプリケーションに登録されていない機能情報）の情報（名称）を、上記マップから取得し、処理をＳ２４８６へ進める。Ｓ２４８６では、中央処理部９０７は、上記Ｓ２４８５で取得した結果、１つ以上の機能情報の情報（機能情報のリスト）を取得できたか否かを判断する。そして、１つ以上の機能情報の情報が取得できなかったと判断した場合（Ｓ２４８６でＮｏの場合）、中央処理部９０７は、処理をＳ２４９１へ進める。

一方、上記Ｓ２４８６で、１つ以上の機能情報の情報を取得できたと判断した場合（Ｓ２４８６）、中央処理部９０７は、処理をＳ２４８７へ進める。Ｓ２４８７では、中央処理部９０７は、上記Ｓ２４８４にて選択したアプリケーションに登録すべき機能情報の情報（上記Ｓ２４８５で取得）をリスト化し（２順目以降では行わない）、該リストから任意に１つの機能情報を選択し、処理をＳ２４８８へ進める。

Ｓ２４８８では、中央処理部９０７は、上記Ｓ２４８４にて選択したアプリケーションに対して、アクション「Ｐｉｃｋ」、データタイプを「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」とし、インテントを利用し、機能情報（上記Ｓ２４８７で選択）の登録要求を発行する。これにより、上記Ｓ２４８４にて選択したアプリケーションに上記Ｓ２４８７で選択した機能情報を登録する。そして、処理をＳ２４８９へ進める。

Ｓ２４８９では、中央処理部９０７は、上記機能情報のリストから上記Ｓ２４８７にて選択した機能情報を削除し、処理をＳ２４９０へ進める。Ｓ２４９０では、中央処理部９０７は、機能情報のリストに機能情報がなくなったか否かを判断する。そして、まだ機能情報のリストに機能情報が残っていると判断した場合（Ｓ２４９０でＮｏの場合）、中央処理部９０７は、処理をＳ２４８７へ戻す。

一方、上記Ｓ２４９０にて、機能情報のリストに機能情報が残っていないと判断した場合（Ｓ２４９０でＹｅｓの場合）、中央処理部９０７は、処理をＳ２４９１へ進める。Ｓ２４９１では、中央処理部９０７は、上記Ｓ２４８４で作成したアプリケーションのリストから上記Ｓ２４８４で選択したアプリケーションを削除し、処理をＳ２４９２へ進める。Ｓ２４９２では、中央処理部９０７は、上記Ｓ２４８４で作成したアプリケーションリスト内にアプリケーションが残っているか否かを判断する。そして、アプリケーションのリスト内にまだアプリケーションが残っていると判断した場合（Ｓ２４９２でＮｏの場合）、中央処理部９０７は、処理をＳ２４８４へ戻す。

一方、上記Ｓ２４９２にて、アプリケーションのリスト内にアプリケーションが残っていないと判断した場合（Ｓ２４９２でＹｅｓの場合）、中央処理部９０７は、各アプリケーションへの機能情報の共有処理を終了し（Ｓ２４９３）、処理を図２２のＳ２４０５へ進める。図２２のＳ２４０５では、中央処理部９０７は、機能情報の取得／共有処理を終了する。

以上示したように、実施例３によれば、同じ情報処理端末内に複数のＵＡが存在する場合に、ユーザが所望のタイミングで或るＵＡから指示することにより、インテントを利用して、他の１つ以上のＵＡから自ＵＡに登録されていない機能情報を取得して登録するとともに、他のＵＡにまだ登録されていない機能情報を自ＵＡから他のＵＡに提供することができる。

上記実施例３では、インテントを利用して他のＵＡと機能情報を同期する構成について説明した。これに対し、実施例４では、Ｗｅｂ Ｉｎｔｅｎｔｓを利用して他のＵＡと機能情報を同期する構成について説明する。

＜実施例４おける機能情報の相互利用に関するシーケンス図の例＞
図２６は、実施例４において情報処理端末５０１のユーザがあるＷｅｂブラウザを用いて他のＷｅｂブラウザと登録されている機能情報を同期させるためのシーケンス図である。なお、図１８と同一のステップには同一のステップ番号を付してある。以下、図１８と異なる部分のみ説明する。
また、図２７、図２８は、図２６のシーケンスの一部の詳細シーケンス図である。

Ｓ１８０１の処理は、図１８と同様であるので説明を省略する。実施例４の情報処理端末５０１では、ローカルエリアネットワーク（Ｌｏｃａｌ Ｎｅｔｗｏｒｋ）１５０１から機能情報を提供可能なアプリケーションまたはサービス（以下、単にサービスという）を探索する。具体的には、Ｓ１８０１にて、ＵＡ.１は、「サービス情報の取込／共有」メニュー１９０１（図１９（ｂ））が押下されたことを検知すると、Ｓ２３０１にて、Ｌｏｃａｌ Ｎｅｔｗｏｒｋ１５０１に対してサービスの探索を実行する。このネットワーク探索に関して、以下、図２７（ａ）を用いて詳細に説明する。

図２７（ａ）に示すように、ＵＡ.１は、Ｓ２３０１にて、Ｌｏｃａｌ Ｎｅｔｗｏｒｋ１５０１に対してサービスの探索を行う。ここでは、例えば、Ａｐｐｌｅ社のゼロ・コンフィギュレーション技術であるＢｏｎｊｏｕｒにおけるＭｕｌｔｉｃａｓｔＤＮＳなどの技術を用いてリンクローカル内のネットワークサービスを探索する。
Ｓ２３０２にて、ＵＡ.１は、各サービスから応答を受ける。本実施例では、Ｌｏｃａｌ Ｎｅｔｗｏｒｋ１５０１内で探索を行うので、同じ情報処理端末内のサービスから応答を受けることの他に、ネットワークの届く範囲にあるサービスからも応答を受けることができる。このネットワークの範囲は、ここでは限定しない。なお、ＵＡ.１は、上記探索結果として収集したサービスから機能情報を提供可能なサービスのリストと、機能情報を登録可能なサービスのリストを生成しておくものとする。

次に、図２６のＳ２３０３では、ＵＡ.１は、探索結果として収集した機能情報を提供可能なサービスのリストから１つのサービスを選択し、該選択したサービスを提供しているアプリケーション（ここではＵＡ.２とする）に対して、登録されている機能情報リストの取得要求を発行する。そして、Ｓ２３０４にて、ＵＡ.１は、機能情報のリストの応答を受信する。

以下、上記Ｓ２３０３〜Ｓ２３０４について図２７（ｂ）を用いて詳細に説明する。
図２７（ｂ）に示すように、ＵＡ.１は、Ｓ２３０３にて、選択した１つのアプリケーション（ここではＵＡ.２とする）に対して、アクション「Ｐｉｃｋ」でデータタイプを「ａｐｐｌｉｃａｔｉｏｎ／Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」のＷｅｂ Ｉｎｔｅｎｔｓ要求を発行する。Ｓ２３０４では、ＵＡ.１は、ＵＡ.２からＷｅｂ Ｉｎｔｅｎｔｓの要求の応答として、ＵＡ.２に登録されている機能情報リストを受信する。

次のＳ１８０６〜Ｓ１８０８は、図１８と同様であるので説明を省略する。
次に、Ｓ２３０５では、ＵＡ.１は、自身に登録されていない機能情報を管理するサービス（ここではＵＡ.２とする）に対して、該機能情報の取得要求を、Ｗｅｂ Ｉｎｔｅｎｔｓのリクエストとして発行する。Ｓ２３０６では、ＵＡ.２は、上記Ｓ２３０５の取得要求に対する応答として機能情報を返す。

以下、上記Ｓ２３０５〜Ｓ２３０６について図２８（ａ）を用いて詳細に説明する。
図２８（ａ）に示すように、Ｓ２３０５にて、ＵＡ.１は、アクション「Ｐｉｃｋ」、データタイプ「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」のＷｅｂ Ｉｎｔｅｎｔｓリクエストで、ある特定の機能情報（ＵＡ.１に登録されていない機能情報）を指定して取得要求する。また、Ｓ２３０６では、ＵＡ.１は、ＵＡ.２から、上記Ｓ２３０５にて発行したＷｅｂ Ｉｎｔｅｎｔｓリクエストの応答として、指定した機能情報を受信する。

次のＳ１８１１、Ｓ１８１４は、図１８と同様であるので説明を省略する。なお、図１８のシーケンス図では、Ｓ１８１２、Ｓ１８１３にて、ＵＡ.１は、インテントを利用して機能情報を登録可能なアプリケーションリストを要求しているが、図２６のシーケンスでは、これらの処理は行わない。図２６のシーケンスでは、Ｓ２３０１〜Ｓ２３０２の探索の際に、必要な情報を収集することができるから、再度、探索して機能情報を登録可能なアプリケーションリストを取得する必要がないためである。

次に、Ｓ２３０７では、ＵＡ.１は、各サービスに対して機能情報の登録要求を発行する。Ｓ２３０８で、ＵＡ.１は、上記Ｓ２３０７で発行した要求の応答を受信する。

以下、上記Ｓ２３０７〜Ｓ２３０８について図２８（ｂ）を用いて詳細に説明する。
図２８（ｂ）に示すように、Ｓ２３０７にて、ＵＡ.１は、対象となるサービス（ここではＵＡ.２とする）に対して、アクション「Ｓｈａｒｅ」で、データタイプ「Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」のＷｅｂ Ｉｎｔｅｎｔｓ要求で、特定の機能情報（そのサービスに登録されていない機能情報）とともに、登録要求を発行する。Ｓ２３０８では、上記Ｓ２３０７で発行したＷｅｂ Ｉｎｔｅｎｔｓ要求の応答として登録結果がＵＡ.１に返される。

そして、図１８のＳ２３０９に示すように、ＵＡ.１は、上記Ｓ２３０７〜Ｓ２３０８の処理を、機能情報の登録処理が可能なサービス毎に、上記Ｓ１８１４で抽出した機能情報の数だけそれぞれ繰り返し実行し、Ｓ１８１８に処理を進め、ＵＡ.１による機能情報の取込／共有処理が完了すると、処理を終了する。

以上示したように、実施例４によれば、同じ情報処理端末内に複数のＵＡが存在する場合に、ユーザが所望のタイミングで或るＵＡから指示することにより、Ｗｅｂ Ｉｎｔｅｎｔｓを利用して、他の１つ以上のＵＡから自ＵＡに登録されていない機能情報を取得して登録するとともに、他のＵＡにまだ登録されていない機能情報を自ＵＡから他のＵＡに提供することができる。

なお、実施例３及び実施例４では、ユーザによる「サービス情報の取込／共有」メニュー１９０１の押下を検知すると、機能情報の取得／共有処理を実行する構成について説明した。しかし、機能情報の取得／共有処理を、設定等に応じて定期的に実行する構成でもよい。これにより、ユーザからの指示がなくても自動的に複数の中継機能において機能情報の相互利用を実現することができる。

上記各実施例では、情報処理端末５０１の内部のアプリケーション間で機能情報を相互利用する構成を示した。ここでの相互利用とは、実施例１，２では他のアプリケーションへの登録を示し、実施例３，４では、他のアプリケーションからの取込み及び他のアプリケーションへの登録を示すものであった。しかし、ユーザが機能情報を相互利用しようとしたときには、必ずしも相互利用の相手がアプリケーションである必要はなく、インターネット上のサービスであってもよい。

例えば、実施例１，２では、ＵＡとしてのＷｅｂブラウザに機能情報を登録する際、インターネット上の機能情報リストを管理するサービスにも上記機能情報を登録しておく。また、実施例３，４では、「サービスの取込／共有」を実行したときに、インターネット上の機能情報を管理するサービスを対象に取得、提供を行う。このようにすることで、機能情報リストの相互利用先はアプリケーション同士でなくても可能となり、実施例１〜４と同様の効果を得ることができる。

実施例２、４に示したように、機能情報リストをＷｅｂ Ｉｎｔｅｎｔｓを利用して取得しようとした場合、あるＷｅｂブラウザで利用可能な機能情報が、自Ｗｅｂブラウザでは利用できないケースがある。例えば、情報処理端末５０１内に存在するサービスが提供する機能のＵＲＬが、ローカルループバックアドレス（ｈｔｔｐ：／／１２７．０．０．１／〜）を示すＵＲＬであったとする。このようなＵＲＬを含む機能情報を、要求元のＷｅｂブラウザに提供したとしても、提供されたＷｅｂブラウザ（要求元のＷｅｂブラウザ）では、ネットワークを介して該機能情報に対応するサービスの提供機能を利用することができない。

このような場合には、提供する側のＷｅｂブラウザは、機能情報を要求している側（要求側）の条件に応じて、利用可能な機能情報のみを提供するように構成する。また、サービスが提供する機能では、ＵＲＬだけでなく、特別なａｃｔｉｏｎやｔｙｐｅを規定して利用する場合がある。よって、提供側は、要求側が要求するａｃｔｉｏｎやｔｙｐｅに応じて要求側の利用可能な機能情報のみを提供するように構成する。以上のような構成により、上述したように要求元で利用できない機能情報が無駄に登録されてしまうことを防止することができ、利用者の利便性を向上させることができる。

また、機能情報の提供を受けたＷｅｂブラウザが、機能情報を取得した場合に自身で利用可能か判別し、利用不可能な機能情報であった場合には、該機能情報をユーザに選択肢（例えば図１０（ｂ）の画面のＵＡリスト１１０４）として表示しないといった回避方法も考えられる。この構成でも、同様に、要求元で利用できない機能情報が無駄に登録されてしまうこと等を防止することができ、利用者の利便性を向上させることができる。

実施例３，４では、他のＷｅｂブラウザに登録されている機能情報を他のＷｅｂブラウザから自Ｗｅｂブラウザに取り込み、逆に、自Ｗｅｂブラウザに登録されている機能情報を他のＷｅｂブラウザに登録要求することで、機能情報の相互利用を実現する構成を示した。これにより、登録している機能情報の統合を実現することができる。しかし、その他の相互利用の方法として、複数のＷｅｂブラウザ間で、それぞれが管理する機能情報を同期して一致させることで、効果的な使用方法を提供できる。Ｗｅｂブラウザに新しく登録した機能情報や、Ｗｅｂブラウザから削除した機能情報をそれぞれ記憶しておき、「サービス情報の取込／共有」を実施する際に、上記記憶しておいた新しく登録した機能情報を各Ｗｅｂブラウザでも同様に登録要求する。また、上記記憶しておいた以前に削除した機能情報が他のＷｅｂブラウザに登録されていた場合には、他のＷｅｂブラウザから削除するようにすることにより、機能情報の同期を行う構成も、本発明に含まれるものである。

以上示したように、本発明によれば、Ｗｅｂ Ｉｎｔｅｎｔｓなどの新しい連携の仕組みを提供する中継機能が情報処理端末内に複数存在する場合、同じ機能情報の登録処理を複数の中継機能で実行させる等の制御を行うことにより、それら中継機能の間で機能情報の少なくとも一部を適切に共有することを可能とする。この結果、ユーザは中継機能毎に同一の機能情報の登録を繰り返す必要もなくなり、ユーザの利便性が向上する。よって、現在、提案されているＷｅｂ Ｉｎｔｅｎｔｓなどの新しい連携の仕組みについて、ユーザビリティを向上させることができる。

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

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

Claims (13)

1. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を複数備える情報処理端末であって、
   前記サービスが提供する機能を呼び出すための機能情報の登録処理を実行する１以上の中継機能を指定するための指定画面を提供する提供手段を有し、
   前記指定画面を介して指定された１以上の中継機能により前記機能情報の登録処理が実行されることを特徴とする情報処理端末。
2. 前記提供手段は、第１の中継機能を用いて前記機能情報の登録処理が行われる際に、当該機能情報の登録処理を行うべき別の中継機能を指定するために、前記指定画面を提供することを特徴とする請求項１に記載の情報処理端末。
3. 前記提供手段は、前記第１の中継機能の機能として実現され、当該第１の中継機能はさらに、前記指定画面で指定された別の中継機能に対して前記機能情報の登録処理を要求することを特徴とする請求項２に記載の情報処理端末。
4. 前記指定画面は、前記情報処理端末が備える複数の中継機能の中から、１以上の中継機能を指定するための指定画面であることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理端末。
5. 前記複数の中継機能により登録処理が実行されている機能情報を同期させる同期処理の実行を指示する指示手段と、
   前記指示手段による指示に応じて、前記複数の中継機能により登録処理が実行されている機能情報を同期させる同期手段と、
   をさらに有することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理端末。
6. 前記複数の中継機能は、前記情報処理端末のオペレーティングシステム上で動作するアプリケーションの機能として提供されることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理端末。
7. 前記ネットワークは、インターネットであることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理端末。
8. 前記クライアント、前記サービス及び前記中継機能の少なくとも２つは、同じ装置で動作する機能であることを特徴とする請求項１乃至７のいずれか１項に記載の情報処理端末。
9. 前記機能情報には、分類情報として、データを共有する機能に対応する分類情報、データを編集する機能に対応する分類情報、データを閲覧する機能に対応する分類情報、データを取得する機能に対応する分類情報、データを保存する機能に対応する分類情報のいずれかが記載されていることを特徴とする請求項１乃至８のいずれか１項に記載の情報処理端末。
10. 他の中継機能を探索する探索手段をさらに有し、
    前記提供手段は、前記サービスが提供する機能を呼び出すための機能情報の登録処理を実行する１以上の中継機能として、前記探索手段による探索で見つかった中継機能を指定するための指定画面を提供することを特徴とする請求項１乃至９のいずれか１項に記載の情報処理端末。
11. 前記探索手段は、前記情報処理端末内またはローカルエリアネットワーク内を探索することを特徴とする請求項１０に記載の情報処理端末。
12. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を複数備える情報処理端末の制御方法であって、
    前記サービスが提供する機能を呼び出すための機能情報の登録処理を実行する１以上の中継機能を指定するための指定画面を提供する提供ステップと、
    前記指定画面を介して指定された１以上の中継機能により前記機能情報の登録処理が実行される登録ステップと、
    を有することを特徴とする情報処理端末の制御方法。
13. コンピュータを、請求項１乃至１１のいずれか１項に記載された手段として機能させるためのプログラム。

Images