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

Description

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

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

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

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

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

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

本発明は、データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を複数備える情報処理端末であって、第１の中継機能を用いて、ネットワーク上のサービスが提供する機能を呼び出すための機能情報を選択するための選択画面を提供する提供手段と、前記第１の中継機能から、第２の中継機能に対して、機能情報を要求する要求手段と、を有し、前記提供手段は、前記要求手段による要求に基づき取得した機能情報が含まれるように、前記選択画面を提供することを特徴とする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、サービス情報格納部９１１から取得した機能情報の一覧の中に、ユーザの利用したい機能に対応する機能情報がない場合、当該Ｗｅｂブラウザは、インテントを利用して他のＷｅｂブラウザから機能情報を取得することができる。この場合、Ｗｅｂブラウザの中央処理部９０７は、ＯＳ部９０１のインテント情報入出力部９０４に、機能情報を提供可能なアプリケーションのリストを取得するためのリクエストを発行する。そして、中央処理部９０７は、該リクエストの結果、機能情報の提供を行うアプリケーションのリストを受信する。このアプリケーションのリストの中からユーザが任意のアプリケーションを選択すると、中央処理部９０７が、該選択されたアプリケーションに対してインテントを利用して機能情報の取得要求を行い、機能情報を取得する。

また、中央処理部９０７は、外部アプリケーションからインテントにより、機能情報の提供依頼（取得要求）を受け付けると、サービス情報入出力９１０を介してサービス情報格納部９１１から機能情報を取得する。そして、中央処理部９０７は、該取得した機能情報を、上記外部アプリケーションに対して提供する。

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

図９のＳ１００１では、ユーザ指示に応じてＵＡ.１がクライアント１０１にアクセスをする。すると、ＵＡ.１は、Ｓ１００２にて、クライアント１０１から「Ｓｈａｒｅ」ボタンによって処理が開始されるＥＭＣＡＳｃｒｉｐｔを含んだＨＴＭＬ情報を受信する。そして、ＵＡ.１のＷｅｂブラウザ画面では、図１０（ａ）に示すような画面が表示される。この画面では、写真コンテンツ情報の提供と「Ｓｈａｒｅ」ボタン１１０１によって、任意のサービスに写真コンテンツ情報を共有する依頼を発行することができる。

Ｓ１００３にて、ユーザが「Ｓｈａｒｅ」ボタン１１０１を押下してサービスを利用することを指示すると、ＵＡ.１は「Ｓｈａｒｅ」ボタン１１０１が押下されたことを検知する。ＵＡ.１は、「Ｓｈａｒｅ」ボタン１１０１の押下を検知し、ユーザからサービスの利用を指示されたと判断すると、Ｓ１００４に処理を移す。Ｓ１００４にて、ＵＡ.１は、写真コンテンツに対する共有を示すアクションとファイルのデータ型に基づいて、サービス情報格納部９１１（図７）に登録されている機能情報のリストを取得して、該取得した機能情報のリスト（一覧）を含む図１０（ｂ）のような選択画面を表示してユーザに提示する。

Ｓ１００４で表示する画面には、図１０（ｂ）に示すように、機能情報のリスト１１０２と、他のＵＡに登録済みの機能情報を参照できる「サービス・インポート」と記載しているリンクボタン１１０３が表示される。また、この画面には、選択した機能情報を決定するためのＯＫボタン１１０４、機能情報の選択をキャンセルするＣａｎｃｅｌボタン１１０５も表示されている。

ユーザは、上記Ｓ１００４で表示された図１０（ｂ）のような画面上の機能情報のリスト１１０２に、利用したい機能情報がない場合、他のブラウザにて登録されている機能情報を利用することができる。この場合、ユーザは、Ｓ１００５にて、図１０（ｂ）の画面の「サービス・インポート」リンクボタン１１０３を押下する。

ＵＡ.１は、「サービス・インポート」リンクボタン１１０３の押下を検知すると、情報処理端末５０１の中で機能情報を提供可能な他のアプリケーションを探す（Ｓ１００６〜Ｓ１００７）。実施例１では、例としてａｎｄｒｏｉｄ（登録商標）のインテントを利用して機能情報を取得する処理シーケンスを記載する。インテントも、Ｗｅｂ Ｉｎｔｅｎｔｓと同様に転送したいデータ型とそのデータに対して何をしたいかというアクションをＯＳが仲介することで適切なアプリケーション間でのデータ転送を可能にするものである。

以下、Ｓ１００６〜Ｓ１００７について図１１（ａ）を用いて詳細に説明する。
図１１（ａ）に示すように、Ｓ１００６にて、ＵＡ.１は、データの型を「ａｐｐｌｉｃａｔｉｏｎ／Ｗｅｂ Ｉｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ」とし、データ提供を依頼できるアプリケーションを探すためアクションを「ｐｉｃｋ」として、ＯＳ部９０１にインテント依頼を発行する。ＯＳ部９０１は、Ｓ１００７にて、インテントによって、サービスの機能情報を提供できるアプリケーションのリストを、アプリケーション情報格納部９０５から取得する。そして、インテント情報入出力部９０４を介して、ＵＡ.１にＵＡのリストとして返す。

上記Ｓ１００７でＵＡリストを取得したＵＡ.１は、Ｓ１００８にて、ＵＡリストを含む画面を表示してユーザに提示する。ユーザは、この画面にて、あるＵＡ（ここでは、ＵＡ.２とする）に登録されている機能情報を利用したい場合、ＵＡ.２を選択する。ＵＡ.１は、Ｓ１００９にて、ＵＡ.２が選択されたこと検知すると、Ｓ１０１０にて、ＵＡ.２に登録されている機能情報のリストの取得要求を発行する。

以下、Ｓ１０１０〜Ｓ１０１３について図１１（ｂ）を用いて詳細に説明する。
図１１（ｂ）に示すように、Ｓ１０１０にて、ＵＡ.１は、ＵＡ.２に対してインテント呼び出しを行い、データ型を「ａｐｐｉｌｉｃａｔｉｏｎ／Ｗｅｂ ＩｎｔｅｎｔｓＳｅｒｖｉｃｅ」としアクションを「ｐｉｃｋ」として処理を要求する。この要求に応じて、ＵＡ.２は、中間応答として提供可能な機能情報のリストをＵＡ.１に提供する。なお、このデータの送受信は実際にはＯＳ９１を介して行われるが、ここでは簡略化して説明する。

ＵＡ.１は、Ｓ１０１１にて、ＵＡ.２から機能情報リストを受信すると、Ｓ１０１３にて、ＵＡ.２の機能情報リスト（一覧）を表示する。上記Ｓ１０１３にて情報処理端末５０１に表示される画面の例を図１０（ｃ）として示す。図１０（ｃ）では、ＵＡのリストとそのＵＡが管理する機能情報のリストの親子関係がわかるように表示されている。例えば、図１０（ｃ）では、ＵＡとしての「ｂｒｏｗｓｅｒＢ」が管理する機能情報として「ＰｈｏｔｏＳｅｒｖｉｃｅＤ」，「ＰｈｏｔｏＳｅｒｖｉｃｅＥ」が表示されている（１１０６）。しかし、親子関係を表示せず、ＵＡ.１に登録されていない機能情報のリストのみをそのまま表示してもよい。ユーザは、いずれか１又は複数の機能情報を選択した状態でＯＫボンタン１１０７を押下することにより、機能情報の選択を確定する。この際、ＵＡ.１は、機能情報が選択されたことを検出する。

なお、上記Ｓ１００９〜Ｓ１０１３に示したＵＡの選択を検知し該選択されたＵＡに登録されている機能情報リストを取得して表示する処理は、ユーザがＵＡを選択した回数分繰り返される（Ｓ１０１２）。

ＵＡ.１は、Ｓ１０１４にて、上記機能情報リストから、ＵＡ.２に登録されている機能情報が選択されたことを検出すると、Ｓ１０１５にて、ＵＡ.２に対して上記選択された機能情報を取得するためのリクエストを発行し、上記選択した機能情報を取得する（Ｓ１０１１５〜Ｓ１０１６）。

以下、Ｓ１０１５〜Ｓ１０１６について図１２（ａ）を用いて詳細に説明する。
図１２（ａ）に示すように、Ｓ１０１５にて、ＵＡ.１は、インテントの「ｐｉｃｋ」を用いて取得対象の機能情報を指定し、インテントの仕組みを利用して、ＵＡ.２に対して取得要求を発行する。この取得要求に応じて、ＵＡ.２は、Ｓ１０１６にて、上記１０１５のインテントの応答として、上記指定された機能情報を送信する。ここで送信される機能情報は、図１３のように、機能情報が定義されている定義ファイルであ。

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

以下、図９のシーケンス図の説明に戻る。
ＵＡ.１は、上記Ｓ１０１６で機能情報を登録するために必要な情報を取得すると、Ｓ１０１７にて、自身に、上記取得した機能情報を登録する。即ち、ＵＡ.１の中央処理部９０７は、サービス情報入出力部９１０を介して、上記Ｓ１０１６で取得した機能情報をサービス情報格納部９１１へ格納する。その後、Ｓ１０１８にて、ＵＡ.１は、自身に登録されている機能情報のリストを再び図１０（ｂ）のような選択画面を表示してユーザに提示する。ＵＡ.１は、Ｓ１０１９にて、ユーザにより、上記Ｓ１０１８で表示した機能情報リストの中から、ある機能情報を選択されたことを検知すると、Ｓ１０２０に処理を進める。Ｓ１０２０では、ＵＡ.１は、上記選択された機能情報に対応するサービス（ここではサービス１０３）に対して、「ｓｈａｒｅ」を処理するためのＨＴＴＰ要求（Ｗｅｂ Ｉｎｔｅｎｔ処理要求）を送信する。

以下、Ｓ１０２０〜Ｓ１０２１について図１２（ｂ）を用いて詳細に説明する。
図１２（ｂ）に示すように、Ｓ１０２０にて、ＵＡ.１は、サービス１０３に対して、データ型「ｉｍａｇｅ／ｊｐｅｇ」、アクション「ｓｈａｒｅ」のＷｅｂ Ｉｎｔｅｎｔｓ処理要求を発行する。このＷｅｂ Ｉｎｔｅｎｔｓ処理要求に応じて、サービス１０３は、Ｓ１０２１にて、該Ｗｅｂ Ｉｎｔｅｎｔｓ処理要求に対する処理を実行し、実行結果を応答としてＵＡ.１に返す。そして、ＵＡ.１は、上記Ｓ１０２１の応答を受信する。

＜実施例１のＵＡの処理フローチャートの例＞
図１４は、ＵＡがクライアントからＥＣＭＡＳｃｒｉｐｔを受信してから、機能情報を外部から取得し、サービスにリクエストを発行するまでのソフトウェアの処理を例示するフローチャートである。なお、このフローチャートの処理は、図７に示す情報処理端末５０１内のソフトウェアの処理の一部を示したものである。このフローチャートの処理は、情報処理端末５０１のＣＰＵ８０２が、ＲＯＭ８０３、記憶装置８０９等に記憶されたプログラムを必要に応じてＲＡＭ８０４に展開して実行することにより実現される。

Ｓ１７０１にて、情報処理端末５０１のネットワーク制御部９０６は、クライアント１０１からＷｅｂ Ｉｎｔｅｎｔｓリクエストを発行するためのＥＣＭＡＳｃｒｉｐｔを含むＨＴＭＬを受信すると、処理をＳ１７０２へ進める。

Ｓ１７０２では、中央処理部９０７は、受信したＨＴＭＬ情報に基づいて画面を構成し、ユーザ入出力部９０３を介して図１０（ａ）のような画面を表示し、ユーザに受信情報を提示し、処理をＳ１７０３へ進める。Ｓ１７０３では、中央処理部９０７は、画面操作でユーザからＷｅｂ Ｉｎｔｅｎｔｓリクエストの発行指示を受け取ったか否かを判断する。なお、中央処理部９０７は、「ｓｈａｒｅ」ボタン１１０１の押下を検知した場合に、Ｗｅｂ Ｉｎｔｅｎｔｓリクエストの発行指示を受け取ったと判断する。

Ｗｅｂ Ｉｎｔｅｎｔｓリクエストの発行指示を受け取っていないと判定した場合（Ｓ１７０３でＮｏの場合）、中央処理部９０７は、Ｓ１７０３の処理を返し、ユーザからの発行指示を待つ。なお、図示しないが、ユーザの指示によりその他のＷｅｂページへ移動するリクエストを受けると、中央処理部９０７は、本フローチャートの処理から外れ、リクエストに応じた処理を行う。

一方、Ｗｅｂ Ｉｎｔｅｎｔｓリクエストの発行指示を受け取ったと判定した場合（Ｓ１７０３でＹｅｓの場合）、中央処理部９０７は、Ｓ１７０４に処理を進める。Ｓ１７０４では、中央処理部９０７は、サービス情報入出力部９１０に対して、上記Ｗｅｂ Ｉｎｔｅｎｔｓリクエストに対応する機能情報の登録を問い合わせる。ここで該当する機能情報の登録があれば、中央処理部９０７は、ユーザ入出力部９０３を介して、図１０（ｂ）で示したような機能情報のリスト１１０２を表示し、ユーザに提示する。そして、処理をＳ１７０５へ進める。

Ｓ１７０５では、中央処理部９０７は、図１０（ｂ）に示した画面において「サービス・インポート」リンクボタン１１０３が押下されたか否かを判定する。そして、「サービス・インポート」リンクボタン１１０３が押下されたと判定した場合（Ｓ１７０５でＹｅｓの場合）、中央処理部９０７は、Ｓ１７０６に処理を進める。Ｓ１７０６では、機能情報リスト取得・登録処理を実行する。なお、実施例１におけるＳ１７０６の詳細は、後述する図１５に示す。そして、上記Ｓ１７０６の処理を終了すると、中央処理部９０７は、Ｓ１７０４に処理を進め、上記Ｓ１７０６で取得した情報を含む機能情報のリストの選択画面（図１０（ｂ）のような画面）を表示する。

一方、「サービス・インポート」リンクボタン１１０３が押下されなかったと判定した場合（Ｓ１７０５でＮｏの場合）、中央処理部９０７は、Ｓ１７０７に処理を進める。Ｓ１７０７では、中央処理部９０７は、ユーザによる機能情報の選択を検知すると、処理をＳ１７０８へ進める。Ｓ１７０８では、中央処理部９０７は、上記Ｓ１７０３で発行指示を出したコンテンツ情報を利用してＷｅｂ Ｉｎｔｅｎｔｓリクエストを作成し、Ｓ１７０９に処理を進める。Ｓ１７０９では、中央処理部９０７は、上記Ｓ１７０８にて作成したＷｅｂ Ｉｎｔｅｎｔｓリクエストを、上記Ｓ１７０５で選択検知された機能情報に対応するサービスに対して発行し、本フローチャートの処理を終了する。

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

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

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

一方、ＯＳ部９０１からアプリケーションのリストを受信したと判定した場合（Ｓ１７２３でＹｅｓの場合）、中央処理部９０７は、Ｓ１７２５に処理を進める。Ｓ１７２５では、中央処理部９０７は、ユーザ入出力９０３を介してディスプレイ８１４に、上記Ｓ１７２３にて取得したアプリケーションのリストを表示し、ユーザへ提示する。そして、Ｓ１７２６に処理を進める。

Ｓ１７２６では、中央処理部９０７は、上記Ｓ１７２５にて表示したアプリケーションのリストの中から１つのアプリケーションがユーザにより選択されたことを検知すると、処理をＳ１７２７へ進める。Ｓ１７２７では、中央処理部９０７は、上記Ｓ１７２６にて選択されたアプリケーションに対して、インテントを利用し、アクション「ｐｉｃｋ」、データ型「Ｗｅｂ ＩｎｔｅｎｔｓＳｅｒｖｉｃｅ」に対応する機能情報のリストを要求する。そして、処理をＳ１７２８へ進める。

Ｓ１７２８では、中央処理部９０７は、上記Ｓ１７２７にて要求した機能情報のリストを受信し、処理をＳ１７２９へ進める。Ｓ１７２９では、中央処理部９０７は、上記Ｓ１７２８で受信した機能情報のリストと、既にサービス情報格納部９１１にて登録済みの機能情報を比較する。該比較の結果、中央処理部９０７は、既に登録済みの機能情報を除外し、処理をＳ１７３０へ進める。

Ｓ１７３０では、中央処理部９０７は、ユーザ入出力部９０３を介して受信した機能情報のリストをディスプレイ８１４に表示する。ここで表示する画面は、図１０（ｃ）のような画面となる。

図１０（ｃ）の例では、中央処理部９０７は、上記Ｓ１７２６にて、「ｂｒｏｗｓｅｒＢ」と「ｂｒｏｗｓｅｒＣ」からなるアプリケーションのリストを表示する。ユーザは、「ｂｒｏｗｓｅｒＢ」に登録されている機能情報リストを取得する場合、「ｂｒｏｗｓｅｒＢ」をタッチする。すると、中央処理部９０７は、Ｓ１７３０にて、ディレクトリ構造を示す画面左側の三角形を１１０８のように傾け、「ｂｒｏｗｓｅｒＢ」に登録されている機能情報リスト１１０６を表示する。この機能情報リスト１１０６から、ユーザはアプリケーションに取り込みたい機能情報を１つ又は複数選択をする。

以下、図１５のフローチャートの説明に戻る。
上記Ｓ１７３０で表示された画面での操作を検知すると、中央処理部９０７は、Ｓ１７３１に処理を進める。Ｓ１７３１では、中央処理部９０７は、上記Ｓ１７３０で表示した機能情報リストの中から取り込むべき機能情報が選択されたことを検知したか否かを判定する。そして、機能情報が選択されずアプリケーション（例えば「ｂｒｏｗｓｅｒＣ」）が選択されたことを検知したと判定した場合（Ｓ１７３１でＮｏの場合）、中央処理部９０７は、Ｓ１７２６へ処理を進める。

一方、上記Ｓ１７３０で表示した機能情報リストの中から取り込むべき機能情報が選択されたことを検知したと判定した場合（Ｓ１７３１でＹｅｓの場合）、中央処理部９０７は、処理をＳ１７３２へ進める。Ｓ１７３２では、中央処理部９０７は、上記選択された機能情報を管理しているアプリケーションに対して、該選択された機能情報を、インテントを利用して要求し、処理をＳ１７３３へ進める。

Ｓ１７３３では、中央処理部９０７は、上記対象のアプリケーションから上記選択した機能情報を受信し、処理をＳ１７３４へ進める。Ｓ１７３４では、中央処理部９０７は、サービス情報入出力部９１０を介してサービス情報格納部９１１へ受信した機能情報を登録する。そして、機能情報の取得・登録処理を終了する（Ｓ１７３５）。

以上示したように、同じ情報処理端末内に複数のＵＡが存在する場合に、インテントの仕組みを用いて、他のＵＡから、他のＵＡに登録されるサービスの機能情報を取得して使用することができる。よって、同じ情報処理端末内に複数のＵＡが存在する場合、それぞれのＵＡで別々に登録されたサービスの機能情報を共有することが可能となる。

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

図７に示したアプリケーション部９０２のサービス情報管理部９０８は、ＨＴＴＰクライアントの機能を有する。サービス情報管理部９０８は、外部のアプリケーションへ機能情報の取得依頼を発行する。さらに、サービス情報管理部９０８は、該取得依頼に応じて、外部のアプリケーションから機能情報を受け取ると、中央処理部９０７を介してサービス情報入出力部９１０へＷｅｂＩｎｔｅｎｔｓサービス情報の保管依頼を発行する。

また、サービス情報管理部９０８は、Ｗｅｂ Ｉｎｔｅｎｔｓサービスの機能を有する。サービス情報管理部９０８は、Ｗｅｂ Ｉｎｔｅｎｔｓの仕組みを利用して外部アプリケーションからアクションおよびデータのタイプ情報とともに機能情報の取得依頼を受け付けると、中央処理部９０７、サービス情報入出力９１０を介してサービス情報格納部９１１から機能情報を取得し、該取得した機能情報を依頼元に提供する。

＜機能情報の相互利用に関する他のシーケンス図の例＞
図１６は、実施例２において他のＷｅｂブラウザが管理する機能情報のリストを参照して利用する他の動作を例示するシーケンス図である。なお、図９と同一のステップには同一のステップ番号を付してある。以下、図９と異なる部分のみ説明する。
なお、図１７は、図１６のシーケンスの一部の詳細シーケンス図である。

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

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

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

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

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

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

一方、サービス情報管理部９０８は、対応する１以上のサービスを発見したと判定した場合（Ｓ１７４３でＹｅｓの場合）、処理をＳ１７４５へ進める。Ｓ１７４５では、サービス情報管理部９０８は、中央処理部９０７を介して、上記Ｓ１７４３にてユーザ入出力９０３を介して取得したサービスのリストを表示し、処理をＳ１７４６へ進める。

Ｓ１７４６では、サービス情報管理部９０８は、中央処理部９０７を介して、上記Ｓ１７４５にて表示したサービスのリストの中から１つのサービスがユーザにより選択されたことを検知すると、処理をＳ１７４７へ進める。Ｓ１７４７では、サービス情報管理部９０８は、上記Ｓ１７４６にて選択されたサービスに対して、Ｗｅｂ Ｉｎｔｅｎｔｓを利用して、アクション「ｐｉｃｋ」、データ型を「Ｗｅｂ ＩｎｔｅｎｔｓＳｅｒｖｉｃｅ」とした機能情報のリストを要求する。そして、処理をＳ１７４８へ進める。

Ｓ１７４８では、サービス情報管理部９０８は、上記Ｓ１７４７にて要求した機能情報リストを受信すると、処理をＳ１７４９へ進める。Ｓ１７４９では、サービス情報管理部９０８は、中央処理部９０７を介して、上記Ｓ１７４８で受信した機能情報のリストと、既にサービス情報格納部９１１にて登録済みの機能情報とを比較する。該比較した結果、既に登録済みの機能情報を除外し、処理をＳ１７５０へ進める。

Ｓ１７５０では、サービス情報管理部９０８は、中央処理部９０７、ユーザ入出力部９０３を介して、上記機能情報のリストを表示する。ここでは、例えば図１０（ｃ）のような画面を表示する。ユーザは、あるアプリケーションに登録されている機能情報のリストを取得する場合、「ｂｒｏｗｓｅｒＢ」をタッチする。すると、ディレクトリ構造を示す画面左側の三角形が１１０８のように傾き、Ｓ１７５０にて示している機能情報リスト１１０６を表示した状態となる。この機能情報リスト１１０６から、ユーザはアプリケーションに取り込みたい機能情報を１つ又は複数選択をする。

以下、フローチャートの説明に戻る。
上記Ｓ１７５０で表示された画面での操作を検知すると、サービス情報管理部９０８は、Ｓ１７５１に処理を進める。Ｓ１７５１では、サービス情報管理部９０８は、中央処理部９０７を介して、上記Ｓ１７５０で表示した機能情報リストの中から取り込むべき機能情報が選択されたことを検知したか否かを判定する。そして、機能情報が選択されずアプリケーション（例えば「ｂｒｏｗｓｅｒＣ」）が選択されたことを検知したと判定した場合（Ｓ１７５１でＮｏの場合）、サービス情報管理部９０８は、Ｓ１７４６へ処理を進める。

一方、上記Ｓ１７５０で表示した機能情報リストの中から取り込むべき機能情報が選択されたことを検知したと判定した場合（Ｓ１７５１でＹｅｓの場合）、サービス情報管理部９０８は、Ｓ１７５２に処理を進める。Ｓ１７５２では、サービス情報管理部９０８は、上記選択された機能情報を管理しているサービスに対して、機能情報をＷｅｂ ｉｎｔｅｎｔｓを利用して要求し、処理をＳ１７５３へ進める。

Ｓ１７５３では、サービス情報管理部９０８は、上記対象のサービスから上記選択した機能情報を受信し、処理をＳ１７５４へ進める。Ｓ１７５４では、サービス情報管理部９０８は、中央処理部９０７、サービス情報入出力部９１０を介してサービス情報格納部９１１へ受信した機能情報を登録する。そして、機能情報の取得・登録処理を終了する（Ｓ１７５５）。

以上示したように、同じ情報処理端末に複数のＵＡが存在する場合に、Ｗｅｂ ｉｎｔｅｎｔｓの仕組みを用いて、ＵＡごとに別々に登録されたサービスの機能情報を取得して使用することが可能となる。

実施例１では、インテントを利用して、情報処理端末５０１の内部のアプリケーション間でサービスが提供する機能の機能情報を相互利用する例を示した。また、実施例２では、Ｗｅｂ Ｉｎｔｅｎｔｓを利用して、ローカルネットワーク上のアプリケーションと機能情報を相互利用する例を示した。

しかし、ユーザが機能情報を取得しようとしたときには、必ずしも相互利用の相手が内部又はローカルネットワーク上のアプリケーションまたはサービスである必要はなく、インターネット上のサービスであってもよい。例えば、ＵＡとしてのＷｅｂブラウザに機能情報を登録する際、インターネット上の機能情報リストを管理するサービスにも上記機能情報を登録しておく。次に、ユーザは他のＷｅｂブラウザでサービスの利用を考え、図１０（ｂ）の「サービス・インポート」リンクボタン１１０３を押下する。すると、Ｗｅｂブラウザは、インターネット上の機能情報リストを管理するサービスに接続し、機能情報リストの取得要求を発行する。このようにすることで、機能情報リストの相互利用先はローカルネットワーク内のアプリケーション同士でなくても可能となり、実施例１や実施例２と同様の効果を得ることができる。

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

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

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

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

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

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

Claims (12)

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

Images