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

Description

本発明は、ネットワーク上のサービスと情報処理端末内のアプリケーションが連携する際の技術に関する。

近年、いわゆるスマートフォンと呼ばれる情報処理端末の普及に伴い、複数のアプリケーションの間で連携を図り、より高度なサービスをユーザに提供する仕組みが実現されてきている。

例えば、特許文献１には、第１のアプリケーションが第２のアプリケーションに画像識別子を引き渡すことにより、第２のアプリケーションが、第１のアプリケーションより解像度の高い画像を表示することが可能となる技術が開示されている。

また、インターネット上では、Ｗｅｂサーバ機能を持つＷｅｂサイト内のＷｅｂアプリケーション同士の連携を実現する仕組みが提案されており、Ｗｅｂ Ｉｎｔｅｎｔｓ（ウェブインテンツ）はその一例である。

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

しかし、上記特許文献１の技術は、情報処置端末内の２つのアプリケーションが連携することを可能とするが、インターネット上のＷｅｂアプリケーションとの連携については考慮されていない。

また、Ｗｅｂ Ｉｎｔｅｎｔｓなどの新たな連携の仕組みは、Ｗｅｂアプリケーション同士が連携することを可能とするが、Ｗｅｂサーバ機能を持たない、情報処理端末内の一般的なアプリケーションとの連携を実現することはできない。

本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、情報処理端末内で実行されるアプリケーションとＷｅｂアプリケーションを容易に連携可能な仕組みを提供することである。

本発明は、インターネット上でウェブサイトを提供し、データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、中継するウェブブラウザを備える情報処理端末であって、前記情報処理端末では、該情報処理端末内で動作する複数のアプリケーションの間でデータを受け渡すためのインテンツを用いた仕組みを有しているオペレーティングシステムが実行され、前記情報処理端末内で動作する前記インテンツとして登録されている複数のアプリケーションを、前記ウェブブラウザを介して前記サービスとして呼び出すために、当該複数のアプリケーションのそれぞれに関する定義情報を、前記ウェブブラウザで扱える機能情報の形式に変換する変換手段と、前記クライアントが提供する前記ウェブサイト上に用意された、前記サービスを呼び出すためのボタンの押下に応じて、ユーザに対して、前記機能情報に従う複数のサービスの中から１つのサービスを選択できる一覧を表示する画面を提供するための提供手段と、前記ボタンの押下に応じて、前記クライアントが管理する該ボタンに対応するデータを受け取る受け取り手段と、を有し、前記画面に対するユーザの選択指示に応じて、前記受け取られたデータを該選択指示に対応するアプリケーションで処理させるための前記機能の呼び出しが行われることを特徴とする。

本発明によれば、情報処理端末内のアプリケーションとインターネット上のＷｅｂアプリケーションを容易に連携することが可能となる。

Ｗｅｂ Ｉｎｔｅｎｔｓの基本的なシステム構成を例示する図。 Ｗｅｂ Ｉｎｔｅｎｔｓの基本的な動作の概要を例示するシーケンス図。 Ｗｅｂ Ｉｎｔｅｎｔｓの登録用マークアップ及びＷｅｂ Ｉｎｔｅｎｔｓの基本的なＷｅｂ Ｉｎｔｅｎｔ処理要求の一例を示す図。 Ｌｏｃａｌ Ｉｎｔｅｎｔｓの全体構成を例示する図。 Ｌｏｃａｌ Ｉｎｔｅｎｔｓの基本的な動作の概要を例示するシーケンス図。 Ｌｏｃａｌ Ｉｎｔｅｎｔｓの登録用マークアップおよびＬｏｃａｌ Ｉｎｔｅｎｔｓの基本的なＬｏｃａｌ Ｉｎｔｅｎｔ処理要求の一例を示す図。 本発明の一実施例を示すシステム構成図。 情報処理端末のハードウェア構成を例示する図。 サーバおよび情報処理端末のソフトウェア構成を例示する図。 実施例１のテーブル構成を例示する図。 実施例１のプロキシーアプリケーションのイントール時の動作を例示するシーケンス図。 実施例１のクライアントと連携先アプリケーションの連携の動作を例示するシーケンス図。 実施例１の情報処置端末のＵＩを例示する図。 実施例２のプロキシーアプリケーションのマニフェストファイルとソースコードを例示する図。 実施例３のテーブル構成を例示する図。 実施例３のプロキシーアプリケーションのインストール時の動作を例示するシーケンス図。 実施例３のクライアントと連携先アプリケーションの連携の動作を例示するシーケンス図。 実施例３の情報処置端末のＵＩを例示する図。 実施例４のプロキシーアプリケーションのマニフェストファイルを例示する図。 実施例４の情報処置端末のＵＩを例示する図。

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

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

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

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

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

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

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

図２は、Ｗｅｂ Ｉｎｔｅｎｔｓを利用したサービス提供に関する基本動作を説明するためのシーケンス図である。本シーケンス図は、Ｓ２０１〜Ｓ２０７のサービス登録部と、Ｓ２０８〜Ｓ２２２のサービス実行部から成る。

まず、サービス登録部について説明する。
Ｓ２０１で、ＵＡ１０６は、ユーザの操作によりサービス１０３にアクセスする。Ｓ２０２にて、サービス１０３は、自身が提供する機能をＵＡ１０６に登録してもらうための登録用マークアップを含むＨＴＭＬ応答を作成し、Ｓ２０３でＵＡ１０６に返信する。

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

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

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

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

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

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

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

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

Ｓ２１１にて、ＵＡ１０６は、クライアント１０１から送信されるＨＴＭＬ文書を受け取り、該ＨＴＭＬ文書に基づく画面を表示する。Ｓ２１２にて、ＵＡ１０６は、ユーザによる画面上の「共有」ボタンの押下を検出すると、上述したようにＷｅｂ Ｉｎｔｅｎｔｓ起動用のＥＣＭＡＳｃｒｉｐｔを実行し、クライアント１０１に対して画像データ取得要求を発行する。上記Ｓ２１２の画像データ取得要求を受信すると、クライアント１０１は、画像データを準備し（Ｓ２１３）、該準備した画像データを返信する（Ｓ２１４）。ＵＡ１０６は、クライアント１０１が持つ画像データを受信する。

また、ＵＡ１０６は、上記Ｓ２１２での「共有」ボタン押下により、自身に登録されているＷｅｂ Ｉｎｔｅｎｔの一覧を表示する（Ｓ２１５，Ｓ２１６）。なお、Ｗｅｂ Ｉｎｔｅｎｔの一覧の中に提供機能が登録されていない場合は、Ｓ２２１に進み、処理が失敗した旨をクライアント１０１へ返信する。

ＵＡ１０６は、Ｗｅｂ Ｉｎｔｅｎｔの一覧からユーザがサービス１０３の提供機能を示すＷｅｂ Ｉｎｔｅｎｔを選択したことを検出すると、Ｓ２１７にて、該選択された提供機能を提供するサービス１０３へＨＴＴＰ要求（Ｗｅｂ Ｉｎｔｅｎｔ処理要求）を送信する。その際、ＵＡ１０６は、送信データに、図３（ｂ）のＥＣＭＡＳｃｒｉｐｔが作成したＷｅｂ Ｉｎｔｅｎｔオブジェクトの内容を含める。

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

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

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

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

＜モバイル端末内でのアプリケーション同士の連携に関する基本的な仕組み＞
次に、図４乃至図５を用いて、情報処理端末の一例であるモバイル端末内で動作するアプリケーション同士の連携に関する基本的な仕組みについて説明する。なお、本実施例ではモバイル端末内ではオペレーティングシステム（ＯＳ）としてＡｎｄｒｏｉｄ（登録商標）などが動作する場合の例を説明する。

Ａｎｄｒｏｉｄ（登録商標） ＯＳでは、Ｉｎｔｅｎｔｓで、複数のアプリケーションの間でデータを受け渡しするなどの連携を行う。ここで、ＡｎｄｒｏｉｄにおけるＩｎｔｅｎｔｓとは、アプリケーション同士の連携に際してサービスの呼び出しに用いる登録情報やそれを用いた仕組みのことを示す。また、以降、本明細書ではＷｅｂ Ｉｎｔｅｎｔｓと区別するため、ＡｎｄｒｏｉｄなどのＯＳが行う端末内で動作するアプリケーション同士の機能の呼び出しのための登録情報の一例であるＩｎｔｅｎｔｓを、Ｌｏｃａｌ Ｉｎｔｅｎｔｓと記載する。なお、本発明は、このような端末内で動作するアプリケーション間でデータを受け渡す、乃至はサービス連携を実現するための同様の仕組みを有していれば、ＯＳとしてＡｎｄｒｏｉｄ以外のものが動作する場合も適用可能である。

図４は、Ｌｏｃａｌ Ｉｎｔｅｎｔｓの全体構成を示す図である。
図４において、１０２は、情報処理端末である。情報処理端末１０２において、５０３は、Ｌｏｃａｌ Ｉｎｔｅｎｔｓ技術を利用して機能を提供する連携先アプリケーションである。５０１は、上記連携先アプリケーションの機能を利用する連携元アプリケーションである。５０２は、連携元アプリケーション５０１からの要求を連携先アプリケーション５０３に渡し、連携先アプリケーション５０３からの結果を連携元アプリケーション５０１に渡す役割をする制御部である。なお、制御部５０２は、例えばオペレーティングシステム（ＯＳ）などによって実現することが可能である。

図５は、Ｌｏｃａｌ Ｉｎｔｅｎｔｓを利用した機能提供に関する基本動作を説明するためのシーケンス図である。本シーケンス図は、Ｓ６０１〜Ｓ６０２のアプリケーション登録部と、Ｓ６０３〜Ｓ６１２のアプリケーション実行部から成る。

まず、アプリケーション登録部について説明する。
ユーザ操作等により情報処理端末１０２にインストールされた後、連携先アプリケーション５０３は、Ｓ６０１にて、制御部５０２に、連携先アプリケーション５０３が提供する機能の情報を送付する。制御部５０２は、上記連携先アプリケーション５０３の情報を受信し、Ｓ６０２にて、該受信した連携先アプリケーション５０３が提供する機能の情報を自身に登録する。

図６（ａ）は、Ｓ６０１において、連携先アプリケーション５０３がインストールされるときに連携先アプリケーション５０３が提供する機能を制御部５０２に登録するためのマニフェストファイルの一部を例示する図である。

マニフェストファイル７００には、＜ａｐｐｌｉｃａｔｉｏｎ＞タグが記載されている。＜ａｐｐｌｉｃａｔｉｏｎ＞タグには、連携先アプリケーション５０３が提供する機能の定義情報等を記載する。＜ａｃｔｉｖｉｔｙ＞タグには、連携先アプリケーション５０３が提供する１つの機能に関する情報を記載する。連携先アプリケーション５０３が複数の機能を提供する場合は、＜ａｃｔｉｖｉｔｙ＞タグを、提供する機能の数だけ記載する。

＜ｉｎｔｅｎｔ−ｆｉｌｅｒ＞タグには、本機能がどのようなＬｏｃａｌ Ｉｎｔｅｎｔｓの要求を受け付けることができ、どのようなデータを扱えるかを制御部５０２に伝えるための情報を記載する。具体的には、＜ｉｎｔｅｎｔ−ｆｉｌｅｒ＞タグ内には、＜ａｃｔｉｏｎ＞、＜ｃａｔｅｇｏｒｙ＞、＜ｄａｔａ＞タグを記載する。

ａｃｔｉｏｎは、本機能がどのようなＬｏｃａｌ Ｉｎｔｅｎｔの要求を受け付けることができるかを示す。また、ｃａｔｅｇｏｒｙは、本機能の種類を表す付加的な情報を示す。ｄａｔａは、本機能が扱うことが可能なデータなどの種類を示す。すなわち、ｄａｔａは、ａｃｔｉｏｎに対して扱えるデータ型などを示す。本例のでは、ａｃｉｔｉｖｉｔｙの名前が「ＳｅｎｄＡｃｉｔｉｖｉｔｙ」である機能が、データを送信する(ｉｎｔｅｎｔ.ａｃｔｉｏｎ.ＳＥＮＤ)ためのＬｏｃａｌ Ｉｎｔｅｎｔの要求を受け付けることが示されている。また、＜ｄａｔａ＞タグの記載によって、扱えるデータは、あらゆるフォーマット（＊）の画像データであることを示されている。

次に、アプリケーション実行部について説明する。
Ｓ６０３で、連携元アプリケーション５０１は、ボタン押下などのユーザ操作を受け付けると、他のアプリケーションと連携するため、制御部５０２に対してアプリケーション連携処理要求として、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を送付する。Ｓ６０４にて、制御部５０２は、上記Ｓ６０３の要求を受信する。Ｓ６０５にて、制御部５０２は、連携元アプリケーション５０１と連携可能なアプリケーションの一覧を表示する。ここで、Ｓ６０３で連携元アプリケーション５０１が、ボタン押下の操作を受け付けるためのソースコードの例、及び、Ｓ６０３，Ｓ６０４の動作について図６（ｂ）を用いて詳細に説明する。

図６（ｂ）は、Ｓ６０３で、連携元アプリケーション５０１がボタン押下の操作を受け付けるためのソースコードの一部を例示する図である。
ソースコード８００は、ソースコード８００は、ｏｎＣｌｉｃｋ（）とｏｎＡｃｔｉｖｉｔｙＲｅｓｕｌｔ（）の２つの関数から成る。ｏｎＣｌｉｃｋ（）は、連携元アプリケーション５０１がボタン押下を受け付けた際に実行する関数である。ｏｎＡｃｔｉｖｉｔｙＲｅｓｕｌｔ（）は、連携元アプリケーション５０１が制御部５０２からＬｏｃａｌ Ｉｎｔｅｎｔの処理要求に対する結果を受信した際に実行する関数である。

連携元アプリケーション５０１は、ＵＩに表示するボタンが押下されると、ｏｎＣｌｉｃｋ（）関数を実行する。ｏｎＣｌｉｃｋ（）関数では、新規のＬｏｃａｌ Ｉｎｔｅｎｔオブジェクトを作成し、これを引数にして、制御部５０２のｓｔａｒｔＡｃｔｉｖｉｔｙＦｏｒＲｅｓｕｌｔ（）関数を呼び出す（Ｓ６０３）。この関数が実行されると、制御部５０２はアプリケーション連携処理要求として、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を受信する（Ｓ６０４）。次に、制御部５０２は、自身に登録されているアプリケーションの提供機能の中から、指定されたＬｏｃａｌ ＩｎｔｅｎｔのＡｃｔｉｏｎとＴｙｐｅが一致する提供機能を提供するアプリケーションを抽出し、一覧表示する。その後、ユーザによる、連携するアプリケーションの選択を受け付ける（Ｓ６０５）。図６（ｂ）の例であれば、ＡｃｔｉｏｎがＡＣＴＩＯＮ＿ＳＥＮＤであり、あらゆるフォーマット（＊）の画像データを処理可能なアプリケーションが一覧表示される。つまり、連携先アプリケーション５０３も一覧表示される。

再び、図５の説明に戻る。
ユーザにより一覧から連携先アプリケーション５０３が選択されると、Ｓ６０６で、制御部５０２は、選択された連携先アプリケーション５０３へアプリケーション処理要求を送付する。より具体的には、制御部５０２は選択された連携先アプリケーション５０３へＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を渡す。この際、制御部５０２は、該処理要求に、Ｌｏｃａｌ Ｉｎｔｅｎｔオブジェクトの内容を含める。

Ｓ６０７で、連携先アプリケーション５０３は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を受信する。Ｓ６０８では、連携先アプリケーション５０３は、上記Ｓ６０７で受信したＬｏｃａｌ Ｉｎｔｅｎｔの処理要求からＬｏｃａｌ Ｉｎｔｅｎｔのオブジェクトを取り出し、提供する機能（連携元アプリケーション５０１が要求した機能）を実現する。例えば、連携先アプリケーション５０３は、Ｌｏｃａｌ Ｉｎｔｅｎｔのオブジェクトから画像データを取り出し、自身の管理する領域に画像データを保存する、などの処理を行う。以上のように、Ｌｏｃａｌ Ｉｎｔｅｎｔ処理要求からＬｏｃａｌ Ｉｎｔｅｎｔオブジェクトを取り出し、解析して処理することを、以降ではＬｏｃａｌ Ｉｎｔｅｎｔを処理すると記載する。

連携先アプリケーション５０３は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理が終了すると、Ｓ６０９で、処理結果を制御部５０２に通知する。制御部５０２は、Ｓ６１０にて、前記処理結果を受信すると、Ｓ６１１で、連携元アプリケーション５０１に処理結果を送付するために、図５（ｂ）に記載したコールバック関数ｏｎＡｃｔｉｖｉｔｙＲｅｓｕｌｔ（）を呼び出す。連携元アプリケーション５０１は、Ｓ６１２にて、前記処理結果を受信する。

以上の処理により、連携元アプリケーション５０１は、制御部５０２を介して、連携先アプリケーション５０３が提供する機能を呼び出すことが可能となる。

＜本発明の実施例におけるシステム構成＞
図７は、本発明を実施したＷｅｂ Ｉｎｔｅｎｔｓの仕組みを適用したネットワークシステムの構成例を示す図である。

図７において、情報処理端末１０２上では、Ｗｅｂ Ｉｎｔｅｎｔｓのユーザエージェント（ＵＡ）として機能するＷｅｂブラウザ１０６、制御部５０２、連携先アプリケーション５０３が動作する。また、情報処理端末１０２上では、後述する図９（ｂ）に示すプロキシーアプリケーション９０１も動作する。サーバ１０４上では、Ｗｅｂ Ｉｎｔｅｎｔｓのクライアント１０１が動作する。

情報処理端末１０２、サーバ１０４は、ネットワーク１０５を介して相互に通信可能である。また、ネットワーク１０５としては、ＬＡＮやインターネットやその組み合わせなどが想定される。接続形態としては、有線や無線を問わない。

＜本実施例の情報処理端末１０２のハードウェア構成例＞
図８は、ＵＡ１０６、連携先アプリケーション５０３、プロキシーアプリケーション９０１として機能するプログラムが実行される情報処理端末１０２のハードウェア構成を示すブロック図である。また、クライアント１０１として機能するプログラム（ウェブサイトなど）が動作するサーバ１０４も同様のハードウェア構成を取ることができる。

図８において、情報処理端末１０２は、ＣＰＵ１００２、ＲＡＭ１００３、ＲＯＭ１００４、外部記憶装置１００９を備える。ＣＰＵ１００２は、ＲＯＭ１００４や外部記憶装置１００９に記憶されたプログラム、或いはＬＡＮやインターネットなどのネットワーク１０５よりダウンロードしたプログラムを実行し、システムバス１０１１に接続された各デバイスを総括的に制御する。

ＲＡＭ１００３は、ＣＰＵ１００２の主メモリあるいはワークエリアなどとして機能する。外部記憶装置１００９は、ハードディスク（ＨＤ）、メモリーカード（ＭＣ）等からなる。外部記憶装置１００９は、ブートプログラム、オペレーティングシステム、認証サーバ、認証クライアントを含む各種のアプリケーション、データベースデータ、ユーザファイル等を記憶する。

１００６はキーボードコントローラ（ＫＢＤＣ）であり、キーボード（ＫＢＤ）１００５や図示しないポインティングデバイスからの入力情報をＣＰＵ１００２に送る。なお、情報処理端末１０２がモバイル端末の場合、キーボード１００５はソフトウェアで実現されるのが一般的である。

１００８はビデオコントローラ（ＶＣ）であり、ＣＲＴやＬＣＤ等からなる表示装置１００７の表示を制御する。１０１０はディスクコントローラ（ＤＫＣ）であり、外部記憶装置１００９とのアクセスを制御する。１０１２は通信コントローラ（ＣＯＭＭ Ｉ／Ｆ）であり、これを介してネットワーク１０５に接続される。

＜本実施例のサーバ１０４のソフトウェア構成例＞
図９（ａ）は、サーバ１０４のソフトウェア（処理部）の構成の一例を示す図である。

サーバ１０４において、クライアント１０１および各処理部は、サーバ１０４の外部記憶装置１００９に保存されたファイルとして存在する。これらは、実行時に、ＯＳやその各処理部を利用する他の処理部（即ちサーバ１０４のＣＰＵ１００２）によって、サーバ１０４のＲＡＭ１００３にロードされ実行されるプログラムモジュールである。

クライアント１０１は、例えば画像データや文書データの保管などのストレージサービスを提供するアプリケーションである。クライアント１０１は、ＨＴＴＰリクエストに応答して処理を実行するプログラムとして実装される。クライアント１０１は、Ｉｎｔｅｎｔ処理要求作成部１１０２、プレゼンテーション部１１０３、および、データ管理部１１０５を有する。

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

クライアントデータ格納部１１０６は、データを記憶管理し、他の処理部からの要求に応じてデータの格納と取り出しを行う。クライアントデータ格納部１１０６では、後述する図１０（ａ）に示すような、画像データ管理テーブル１２１０及び画像データ等のデータを記憶管理する。なお、クライアントデータ格納部１１０６は、サーバ１０４とは別の機器上にあってもよい。

通信部１１０１は、外部機器からのＨＴＴＰリクエストメッセージを受信し、プレゼンテーション部１１０３にリクエストの内容を通知するソフトウェアモジュールである。また、通信部１１０１は、プレゼンテーション部１１０３からの要求を受けて、ＨＴＴＰのレスポンスメッセージを外部機器に送信する。

＜本実施例の情報処理端末１０２のソフトウェア構成例＞
図９（ｂ）は、情報処理端末１０２のソフトウェア（処理部）の構成の一例を示す図である。

情報処理端末１０２において、制御部５０２、ＵＡ１０６、連携先アプリケーション５０３、プロキシーアプリケーション９０１、および各処理部は、情報処理端末１０２の外部記憶装置１００９に保存されたファイルとして存在する。これらは実行時にＯＳやその各処理部を利用する他の処理部（即ち、情報処理端末１０２のＣＰＵ１００２）によって情報処理端末１０２のＲＡＭ１００３にロードされ実行されるプログラムモジュールである。

制御部５０２には、アプリケーション情報格納部１１２１が接続されている。例えば、図５のＳ６０１が実行されると、Ｓ６０２にて、制御部５０２は、図６（ａ）に例示したマニフェストファイルに記載されている情報を、アプリケーション情報格納部１１２１に登録する。アプリケーション情報格納部１１２１では、後述する図１０（ｂ）に示すような、登録済アプリケーション管理テーブル１２２０を記憶管理する。

ＵＡ１０６は、表示部１１４２、解析部１１４３、および、サービス管理部１１４４を有する。表示部１１４２は、ＨＴＭＬ文書をレンダリングするソフトウェアモジュールである。また、表示部１１４２は、他の処理部の要求に応じて、サービスの選択を受け付ける画面を表示する。

解析部１１４３は、ＨＴＭＬ文書を解析するソフトウェアモジュールである。また、解析部１１４３は、Ｉｎｔｅｎｔ処理要求であるＥＣＭＡＳｃｒｉｐｔも解析する。サービス管理部１１４４は、後述のサービス格納部１１４５から登録済みの提供機能を特定する情報を取得したり、格納したりするソフトウェアモジュールである。サービス格納部１１４５は、図１に示したサービス１０３や後述のプロキシーアプリケーション９０１が提供する機能を含むＷｅｂ Ｉｎｔｅｎｔｓの提供機能を一覧管理し、サービス管理部１１４４からの要求に応じてデータの格納と取り出しを行う。サービス格納部１１４５は、後述する図１０（ｃ）に示すような、登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０を記憶管理する。なお、サービス格納部１１４５は、情報処理端末１０２の外部記憶装置１００９内に設けられてもよいし、情報処理端末１０２とは別の機器上にあってもよい。

プロキシーアプリケーション９０１は、プレゼンテーション部１１１１、Ｉｎｔｅｎｔ変換部１１１２、変換テーブル管理部１１１３、Ｉｎｔｅｎｔ処理部１１１４を有する。プレゼンテーション部１１１１は、連携先アプリケーション５０３の情報を制御部５０２に登録するための要求などに応じて、ＨＴＭＬ文書を作成するソフトウェアモジュールである。なお、連携先アプリケーション５０３が提供する機能は、ＵＡ１０６による登録処理のための形式（Ｗｅｂ Ｉｎｔｅｎｔｓの形式）に未対応である。

Ｉｎｔｅｎｔ変換部１１１２は、Ｗｅｂ Ｉｎｔｅｎｔｓ形式の情報とＬｏｃａｌ Ｉｎｔｅｎｔｓ形式の情報の変換を行うソフトウェアモジュールである。変換テーブル管理部１１１３は、後述の変換テーブル格納部１１１５からＩｎｔｅｎｔ変換部１１１２が情報の変換を行う際に使用する変換テーブルを取得したり、格納したりするソフトウェアモジュールである。Ｉｎｔｅｎｔ処理部１１１４は、Ｌｏｃａｌ Ｉｎｔｅｎｔｓ情報の取得など、Ｌｏｃａｌ Ｉｎｔｅｎｔｓに関する処理を司るソフトウェアモジュールである。

変換テーブル格納部１１１５は、Ｗｅｂ Ｉｎｔｅｎｔｓ形式の情報とＬｏｃａｌ Ｉｎｔｅｎｔｓ形式の情報の変換を行うテーブルを管理し、変換テーブル管理部１１１３からの要求に応じてデータの格納と取り出しを行う。変換テーブル格納部１１１５は、後述する図１０（ｄ）に示すような、Ａｃｔｉｏｎ変換テーブル１２４０、アプリケーション情報変換テーブル１２５０、登録済アプリケーション管理テーブル１２６０を記憶管理する。なお、変換テーブル格納部１１１５は、情報処理端末１０２の外部記憶装置１００９内に設けられてもよいし、情報処理端末１０２とは別の機器上にあってもよい。

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

図１０は、実施例１のテーブル構成を例示する図である。
図１０（ａ）は、サーバ１０４のクライアント１０１が管理する画像データ管理テーブル１２１０の構成の一例である。なお、図１０（ａ）のテーブル構成は一例であり、本例とは異なるテーブル構成であってもよい。

画像データ管理テーブル１２１０は、クライアント１０１が扱う画像データを管理するテーブルである。画像データ管理テーブル１２１０が管理する情報は、ＩｍａｇｅＩＤ、Ｆｉｌｅ等である。ＩｍａｇｅＩＤは、クライアント１０１内で各種データを一意に識別するためのＩＤである。Ｆｉｌｅは、各種データのファイル名を表している。つまり、画像データ管理テーブル１２１０の例では、「ｉｍａｇｅ１２５.ｊｐｇ」と「ｉｍａｇｅ４３５.ｊｐｇ」の２つの画像データファイルを管理していることになる。

図１０（ｂ）は、情報処理端末１０２の制御部５０２が管理する登録済アプリケーション管理テーブル１２２０の構成の一例である。なお、図１０（ｂ）のテーブル構成は一例であり、本例とは異なるテーブル構成であってもよい。

登録済アプリケーション管理テーブル１２２０は、情報処理端末１０２に登録されているアプリケーションの提供機能を一覧管理するテーブルである。登録済アプリケーション管理テーブル１２２０が管理する情報は、Ａｐｐ ＩＤ、アプリ名、ａｃｔｉｏｎ、ｍｉｍｅ ｔｙｐｅ等である。Ａｐｐ ＩＤは、制御部５０２内で各アプリケーションの提供機能を一意に識別するためのＩＤである。アプリ名は、アプリケーションの名称を表している。ａｃｔｉｏｎは、それぞれのアプリケーションが提供可能な機能のカテゴリを表す。ｍｉｍｅ ｔｙｐｅは、アプリケーションが扱えるデータなどの種類を表す。

図１０（ｃ）は、情報処理端末１０２のＵＡ１０６が管理する登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０の構成の一例である。なお、図１０（ｃ）のテーブル構成は一例であり、本例とは異なるテーブル構成であってもよい。

登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０は、ＵＡ１０６が仲介することができるＷｅｂ Ｉｎｔｅｎｔｓの提供機能に関する情報を管理するテーブルである。登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０で管理する情報は、ＩＤ、ａｃｔｉｏｎ、ｔｙｐｅ、ｈｒｅｆ、ｔｉｔｌｅ、ｂａｓｅ ＵＲＬ等である。これらは、図３（ａ）で説明した＜ｉｎｔｅｎｔ＞タグが示す情報に対応している。

ＩＤは、ＵＡ１０６内でＷｅｂ Ｉｎｔｅｎｔｓの提供機能を一意に識別するＩＤである。ａｃｔｉｏｎは、提供機能のカテゴリを示す。ｔｙｐｅは、提供機能が扱えるデータなどの種類を示す。ｈｒｅｆは、提供機能の接続先（ＵＲＬ）を示す。ｔｉｔｌｅは、提供機能のタイトルを示す。ｂａｓｅ ＵＲＬは、提供機能を提供するサイトの基準となるＵＲＬを示す。

図１０（ｄ）は、情報処理端末１０２のプロキシーアプリケーション９０１が管理する各テーブルの構成の一例である。なお、図１０（ｄ）のテーブル構成は一例であり、本例とは異なるテーブル構成であってもよい。
プロキシーアプリケーション９０１は、Ａｃｔｉｏｎ変換テーブル１２４０、アプリケーション情報変換テーブル１２５０、登録済アプリケーション管理テーブル１２６０を管理する。

Ａｃｔｉｏｎ変換テーブル１２４０は、Ｗｅｂ ＩｎｔｅｎｔｓのａｃｔｉｏｎとＬｏｃａｌ Ｉｎｔｅｎｔｓのａｃｔｉｏｎの変換方法を管理するテーブルである。アプリケーション情報変換テーブル１２５０は、情報処理端末１０２内のアプリケーションの情報をＷｅｂ Ｉｎｔｅｎｔｓ形式の情報に変換した結果を管理するテーブルである。登録済アプリケーション管理テーブル１２６０は、図１０（ｂ）の登録済アプリケーション管理テーブル１２２０と同様である。

Ａｃｔｉｏｎ変換テーブル１２４０で管理する情報は、ＩＤ、Ｗｅｂ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎ、Ｌｏｃａｌ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎ等である。ＩＤは、プロキシーアプリケーション９０１内で変換方法を一意に識別するＩＤである。Ｗｅｂ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎは、Ｗｅｂ Ｉｎｔｅｎｔｓのａｃｔｉｏｎ情報を示す。Ｌｏｃａｌ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎは、Ｌｏｃａｌ Ｉｎｔｅｎｔｓのａｃｔｉｏｎ情報を示す。

アプリケーション情報変換テーブル１２５０で管理する情報は、ＩＤ、Ａｐｐ ＩＤ、ａｃｔｉｏｎ、ｔｙｐｅ、ｈｒｅｆ、ｔｉｔｌｅ、ｂａｓｅ ＵＲＬ等である。ＩＤは、変換されたＷｅｂ Ｉｎｔｅｎｔｓ情報を一意に識別するＩＤである。Ａｐｐ ＩＤは、本テーブルで情報変換されるアプリケーションを一意に識別するＩＤである。本例では、登録済アプリケーション管理テーブル１２６０のＡｐｐ ＩＤに対応したＩＤが格納されている。ａｃｔｉｏｎ、ｔｙｐｅ、ｈｒｅｆ、ｔｉｔｌｅ、ｂａｓｅ ＵＲＬは、登録済アプリケーション管理テーブル１２６０のアプリ名、ａｃｔｉｏｎ、ｍｉｍｅ ｔｙｐｅから生成された情報が格納される。生成のルールは後述する。

登録済アプリケーション管理テーブル１２６０は、図１０（ｂ）の登録済アプリケーション管理テーブル１２２０と同様のテーブルであるため、説明を省略する。

次に、図１１、図１２を用いて、クライアント１０１と情報処理端末１０２内の連携先アプリケーション５０３が連携する際の動作について説明する。
まず、図１１のシーケンス図を用いて、情報処理端末１０２にプロキシーアプリケーション９０１がインストールされ、ＵＡ１０６にＷｅｂ Ｉｎｔｅｎｔｓの情報が格納されるまでの動作について説明する。

図１１は、実施例１における情報処理端末１０２にプロキシーアプリケーション９０１がインストールされ、ＵＡ１０６にＷｅｂ Ｉｎｔｅｎｔｓの情報が格納されるまでの動作を示すシーケンス図である。ここでは、連携先アプリケーション５０３の情報は、図５のＳ６０１、Ｓ６０２と同様の手段で制御部５０２に事前登録され、登録済アプリケーション管理テーブル１２２０にて管理されているものとする。

Ｓ１３０１では、ユーザ操作等を受け付けて、制御部５０２が、情報処理端末１０２にプロキシーアプリケーション９０１をインストールする。ファイルコピーなど、インストールに伴う処理が完了し、プロキシーアプリケーション９０１が起動されると、Ｓ１３０２にて、プロキシーアプリケーション９０１は、制御部５０２へのアプリケーション情報の登録など、インストールに伴う処理を実行する。

Ｓ１３０３では、プロキシーアプリケーション９０１のＩｎｔｅｎｔ処理部１１１４は、制御部５０２に対して、登録済アプリケーション情報の取得要求を送付する。例えば、Ａｎｄｒｏｉｄ ＯＳでは、ＰａｃｋａｇｅＭａｎａｇｅｒクラスのｇｅｔＩｎｓｔａｌｌｅｄＡｐｐｌｉｃａｔｉｏｎｓ（）など、各種関数を呼び出すことによって本要求の発行が可能である。

制御部５０２は、Ｓ１３０４で、上記Ｓ１３０３の取得要求を受信すると、アプリケーション情報格納部１１２１から図１０（ｂ）で示したような登録済アプリケーション管理テーブル１２２０を取得する。その後、制御部５０２は、Ｓ１３０５にて、上記取得した登録済アプリケーション管理テーブル１２２０の情報を、登録済アプリケーション情報の収集結果として、プロキシーアプリケーション９０１に返却する。

Ｓ１３０６にて、プロキシーアプリケーション９０１は、上記Ｓ１３０５の収集結果を受信し、そのコピーを、変換テーブル管理部１１１３経由で変換テーブル格納部１１１５内の登録済アプリケーション管理テーブル１２６０に格納する。

Ｓ１３０７にて、プロキシーアプリケーション９０１は、登録済アプリケーション管理テーブル１２６０とＡｃｔｉｏｎ変換テーブル１２４０を使って、アプリケーション情報変換テーブル１２５０を、変換テーブル格納部１１１５内に作成する。

例えば、アプリケーション情報変換テーブル１２５０のＩＤが「１」のエントリーの情報を作成する場合、Ａｐｐ ＩＤには、登録済アプリケーション管理テーブル１２６０のＡｐｐ ＩＤ（本例では「１」）を格納する。

ａｃｔｉｏｎには、登録済アプリケーション管理テーブル１２６０のａｃｔｉｏｎの値を、Ａｃｔｉｏｎ変換テーブル１２４０を用いて変換した値を格納する。本例では、登録済アプリケーション管理テーブル１２６０のａｃｔｉｏｎの値が「ＡＣＴＩＯＮ＿ＳＥＮＤ」である。これをＡｃｔｉｏｎ変換テーブル１２４０を用いて変換すると、アプリケーション情報変換テーブル１２５０のａｃｔｉｏｎの値は「ｈｔｔｐ：／／Ｗｅｂ Ｉｎｔｅｎｔｓ．ｏｒｇ／ｓｈａｒｅ」となる。本実施例では、これを「ｓｈａｒｅ」と省略する。

また、アプリケーション情報変換テーブル１２５０のｔｙｐｅは、登録済アプリケーション管理テーブル１２６０のｍｉｍｅ ｔｙｐｅの値を格納する。ｈｒｅｆは、相対的な接続先（ＵＲＬ）として、プロキシーアプリケーション９０１が識別可能な接続先が登録される。ここでは、登録済アプリケーション管理テーブル１２６０のａｃｔｉｏｎの値から生成した文字列（ＡＣＴＩＯＮ＿ＳＥＮＤ．ｈｔｍｌ）を登録している。

アプリケーション情報変換テーブル１２５０のｔｉｔｌｅは、登録済アプリケーション管理テーブル１２６０のアプリ名の値を格納する。アプリケーション情報変換テーブル１２５０のｂａｓｅ ＵＲＩには、「ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｐｒｏｘｙ／」に、アプリ名「ａａａ Ａｐｐ」を付加した、「ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｐｒｏｘｙ／ａａａ＿Ａｐｐ」を登録する。ここで、「ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｐｒｏｘｙ／」は、プロキシーアプリケーション９０１自身の基準ＵＲＬである。上記ｈｒｅｆとｂｅｓｅ ＵＲＩを組み合わせることによってＷｅｂ Ｉｎｔｅｎｔｓの公開ページを生成することが可能となる。

なお、ここではｔｙｐｅ、ｔｉｔｌｅは、ｍｉｍｅ ｔｙｐｅ、アプリ名の値をそのまま格納したが、別途変換テーブルを持つように構成してもよい。また、ｈｒｅｆ、ｂａｓｅ ＵＲＩも別の生成ルールで生成されたものを登録してもよい。以上のように、プロキシーアプリケーション９０１のＩｎｔｅｎｔ変換部１１１２は、情報処理端末１０２内のアプリケーションの定義情報に含まれる分類を、Ｗｅｂ Ｉｎｔｅｎｔｓの機能情報に含まれる分類情報の形式に合わせて変換する。

Ｓ１３０８では、プロキシーアプリケーション９０１のＩｎｔｅｎｔ処理部１１１４がＵＡ１０６を起動するためのＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を作成し、制御部５０２に送付する。この際、ＵＡ１０６がアクセスするＵＲＬとして、プロキシーアプリケーション９０１が公開する、Ｗｅｂ Ｉｎｔｅｎｔｓサービスを登録するためのページを指定する。指定するＵＲＬは、ここでは「ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｐｒｏｘｙ／」となる。

制御部５０２は、Ｓ１３０９にて、通信部１１５０経由で、上記Ｓ１３０８のＬｏｃａｌ Ｉｎｔｅｎｔ処理要求を受信すると、Ｓ１３１０にて、上記Ｓ１３０８で指定されたＵＲＬにアクセスするように、ＵＡ１０６を起動する。

ＵＡ１０６は、制御部５０２によって起動されると、Ｓ１３１１にて、上記Ｓ１３１０で指定されたＵＲＬに対して、ＨＴＴＰリクエストとしてＨＴＭＬの取得要求を送信する。つまり、ＵＡ１０６は、上記Ｓ１３０８で指定された、プロキシーアプリケーション９０１が公開するページにアクセスする。この際、具体的には、ＵＡ１０６からのＨＴＴＰリクエストは、通信部１１５０を介してプロキシーアプリケーション９０１に渡る。

Ｓ１３１２にて、公開ページへのアクセスを検出すると、プロキシーアプリケーション９０１のプレゼンテーション部１１１１は、Ｓ１３１３にて、Ｗｅｂ Ｉｎｔｅｎｔｓサービスの登録用マークアップを作成する。なお、本例で作成するＷｅｂ Ｉｎｔｅｎｔｓサービスの登録用マークアップは、上記Ｓ１３０７で作成したアプリケーション情報変換テーブル１２５０に登録されている、Ｗｅｂ Ｉｎｔｅｎｔｓ形式の情報を登録するためのものである。

Ｓ１３１４にて、プロキシーアプリケーション９０１のプレゼンテーション部１１１１は、上記Ｓ１３１３で作成した登録用マークアップを含むＨＴＭＬ文書をＨＴＴＰレスポンスとして、ＵＡ１０６に送信する。Ｓ１３１５にて、ＵＡ１０６が、上記Ｓ１３１３のＨＴＴＰレスポンスを受信すると、ＵＡ１０６の解析部１１４３は、Ｓ１３１６にて、上記Ｓ１３１５で受信したＨＴＭＬ文書に含まれる登録用マークアップを解析し、Ｗｅｂ Ｉｎｔｅｎｔｓサービスを登録する。具体的には、解析部１１４３が登録用マークアップの解析を行い、Ｗｅｂ Ｉｎｔｅｎｔｓサービスの特定を行う。その後、ＵＡ１０６のサービス管理部１１４４が、必要な情報をサービス格納部１１４５の登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０に登録する。

以上示したように、本シーケンスが実行されることによって登録されるＷｅｂ Ｉｎｔｅｎｔｓサービスは、登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０のＩＤの値が「４」、「５」、「６」の項目である。
以上で、図１１のシーケンス図の説明を終了する。

次に、図１２のシーケンス図を用いて、クライアント１０１と連携先アプリケーション５０３が連携する動作について説明する。
図１２は、クライアント１０１と連携先アプリケーション５０３が連携する動作について説明するシーケンス図である。なお、図１２のＳ１４０１〜Ｓ１４０９の処理は、図２のＳ２０８〜Ｓ２１６の処理と同様である。以下、図１３のＵＩ例を用いて、上記ステップの処理を補う。なお、図１３は、クライアント１０１と連携先アプリケーション５０３が連携する場合に情報処理端末１０２の表示装置１００７に表示されるＵＩ画面を例示する図である。

図１３（ａ）は、Ｓ１４０４にて、ＵＡ１０６がクライアント１０１から受信したＨＴＭＬを表示したＵＩ例である。図１３（ａ）は、クライアント１０１が「ｉｍａｇｅ１２５．ｊｐｇ」１５０２を他のサービスに送信するためのＵＩに対応する。図１３（ａ）のＵＩにおいて、「送信する」ボタン１５０１の押下を受け付けると（Ｓ１４０５）、ＵＡ１０６は、Ｗｅｂ Ｉｎｔｅｎｔｓ起動用のＥＣＭＡＳｃｒｉｐｔを実行し、クライアント１０１に対して画像データ取得要求を発行する。

ここで、図３（ｂ）のＥＣＭＡＳｃｒｉｐｔ４００が実行されたと仮定すると、「送信する」ボタンの押下によって、ａｃｔｉｏｎが「ｈｔｔｐ：／／Ｗｅｂ Ｉｎｔｅｎｔｓ．ｏｒｇ／ｓｈａｒｅ」であるＷｅｂ Ｉｎｔｅｎｔｓが実行される。ＵＡ１０６は、クライアント１０１から画像データとして「ｉｍａｇｅ１２５．ｊｐｇ」を受け取り、ＵＡ１０６自身に登録されているＷｅｂ Ｉｎｔｅｎｔｓサービスの提供機能の一覧を表示する（Ｓ１４０８、Ｓ１４０９）。具体的には、図１０（ｃ）の登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０に登録されているＷｅｂ Ｉｎｔｅｎｔｓ情報から、ａｃｔｉｏｎが「ｓｈａｒｅ」のものを抽出して、選択肢として一覧表示する。このＵＩ例を、図１３（ｂ）に示す。図１３（ｂ）の例では、選択肢として、１５１１〜１５１４が一覧表示されている。

以下、図１２に戻って、説明を続ける。
Ｓ１４１０では、図２のＳ２１７と同様に、ＵＡ１０６は、上記ＵＩ画面に対するユーザの選択指示に応じて、選択された提供機能の接続先となるサービスへＨＴＴＰ要求を送信する。その際、ＵＡ１０６が、送信データに図３（ｂ）のＥＣＭＡＳｃｒｉｐｔ４００が作成したＩｎｔｅｎｔオブジェクトの内容を含める点も、図２のＳ２１７と同様である。なお、ここでは、ユーザによってプロキシーアプリケーション９０１が提供する提供機能（「ａａａ Ａｐｐ」１５１３又は「ｂｂｂ Ａｐｐ」１５１４）が選択されたことにする。この場合、プロキシーアプリケーション９０１が、上記Ｓ１４１０のＨＴＴＰ要求を受信する。

Ｓ１４１１では、プロキシーアプリケーション９０１は、上記Ｓ１４１０で受信したＨＴＴＰ要求からＷｅｂ Ｉｎｔｅｎｔのオブジェクトを取り出し、これをＬｏｃａｌ Ｉｎｔｅｎｔｓ形式に変更する。具体的には、図１０（ｄ）のＡｃｔｉｏｎ変換テーブル１２４０を用いながら、Ｗｅｂ ＩｎｔｅｎｔオブジェクトのａｃｔｉｏｎをＬｏｃａｌ Ｉｎｔｅｎｔのａｃｔｉｏｎに変換する。また、プロキシーアプリケーション９０１で定められたルールに従って、ｔｙｐｅをｍｉｍｅ ｔｙｐｅに変更する。同様に、ＵＡ１０６によって呼び出されたＵＲＬから連携先アプリケーションの情報を切り出す。

Ｓ１４１２では、プロキシーアプリケーション９０１は、上記Ｓ１４１１で変換された情報を用いて、連携元アプリケーション５０１として、連携先アプリケーション５０３を明示的に指定して、Ｌｏｃａｌ Ｉｎｔｅｎｔ処理要求を、制御部５０２に送付する（図５のＳ６０３に対応）。制御部５０２は、上記Ｌｏｃａｌ Ｉｎｔｅｎｔ処理要求に基づき連携先アプリケーション５０３を選択し、該連携先アプリケーション５０３へアプリケーション処理要求を送付する（図５のＳ６０４〜Ｓ６０６に対応）。連携先アプリケーション５０３は、要求された処理を実行し、結果を、制御部５０２を介して、連携元アプリケーション５０１としてのプロキシーアプリケーション９０１に返却する（図５のＳ６０７〜Ｓ６１３に対応）。本ステップは、図５のＳ６０３〜Ｓ６１２と同様であるため、詳細は省略する。

次に、Ｓ１４１３で、プロキシーアプリケーション９０１は、連携先アプリケーション５０３から受信したＬｏｃａｌ Ｉｎｔｅｎｔ処理の結果を、Ｗｅｂ Ｉｎｔｅｎｔｓ形式の処理結果に変換する。具体的には、プロキシーアプリケーション９０１のＩｎｔｅｎｔ処理部１１１４は、図５（ｂ）に記載したコールバック関数ｏｎＡｃｔｉｖｉｔｙＲｅｓｕｌｔ（）によって連携先アプリケーションでのＬｏｃａｌ Ｉｎｔｅｎｔ処理の結果（成功／失敗など）を受信する。次に、プロキシーアプリケーション９０１のＩｎｔｅｎｔ変換部１１１２は、前記受信した処理結果からクライアント１０１に伝えるＥＣＭＡＳｃｒｉｐｔを含む応答を作成する。

次に、Ｓ１４１４で、プロキシーアプリケーション９０１は、サービス１０３として、上記Ｓ１４１３で作成した応答を、ＵＡ１０６に返信する。Ｓ１４１５〜Ｓ１４１７は、図２のＳ２２０〜Ｓ２２２と同様であるため、説明を省略する。
以上で、図１２のシーケンス図の説明を終了する。
以上で、実施例１の説明を終了する。

以上示したように、実施例１では、プロキシーアプリケーション９０１が、Ｗｅｂアプリケーションからの処理実行要求を情報処理端末内のアプリケーションが処理可能な処理実行要求に変換し、仲介する（インテンツ解釈やデータ転送を行う）。これにより、インターネット上のＷｅｂアプリケーション（クライアント１０１）からの処理要求を、情報処理端末内のアプリケーション（連携先アプリケーション５０３）で処理させることができる。即ち、ネットワーク上のサービス（インターネット上のＷｅｂアプリケーション）と情報処理端末内のアプリケーションとを容易に連携することができる。

上記実施例１では、プロキシーアプリケーション９０１がインストールされる際に、既に存在しているアプリケーションの情報をＵＡ１０６に登録する例を説明した。実施例２では、プロキシーアプリケーション９０１がインストールされた後に、情報処理端末１０２に新たにインストールされたアプリケーションの情報を、ＵＡ１０６に登録する例を説明する。

図１４は、実施例２のマニフェストファイルおよびプロキシーアプリケーション９０１のソースコードの一部を例示する図である。
図１４（ａ）は、実施例２のプロキシーアプリケーション９０１が持つマニフェストファイルの一部を例示する。

図１４（ａ）に示すように、プロキシーアプリケーション９０１が持つマニフェストファイル１６００には、＜ｒｅｃｅｉｖｅｒ＞タグが記載されている。＜ｒｅｃｅｉｖｅｒ＞タグには、プロキシーアプリケーション９０１が受信するブロードキャストインテントの情報を記載する。

図１４（ａ）に示す例では、プロキシーアプリケーション９０１が受信するブロードキャストインテントとして、「ＰＡＣＫＡＧＥ＿ＡＤＤＥＤ（新しいアプリケーションが情報処理端末にインストールされた）」を記載している。なお、ブロードキャストインテントは、情報処理端末１０２の状態に何らかの変化が起こった際に、制御部５０２がブロードキャストで送付するＩｎｔｅｎｔである。

図１４（ｂ）は、実施例２のプロキシーアプリケーション９０１のソースコードの一部を例示する。
プロキシーアプリケーション９０１のソースコード１７００には、ｏｎＲｅｃｅｉｖｅ（）関数が記載されている。ｏｎＲｅｃｅｉｖｅ（）は、制御部５０２から送付されたブロードキャストインテントを、プロキシーアプリケーション９０１が受信した際に実行する関数である。

プロキシーアプリケーション９０１がインストールされた後に、情報処理端末１０２に、他のアプリケーションがインストールされると、制御部５０２によって、ブロードキャストインテントが送付され、上記ｏｎＲｅｃｅｉｖｅ（）が呼び出される。プロキシーアプリケーション９０１は、上記ｏｎＲｅｃｅｉｖｅ（）が呼び出されたことを検知すると、図１１のＳ１３０３を実行する。即ち、プロキシーアプリケーション９０１は、制御部５０２に対して、登録済アプリケーション情報の取得要求を送付する。その結果、ＵＡ１０６の登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０に前記アプリケーションの情報が、Ｗｅｂ Ｉｎｔｅｎｔｓの情報に変換されて登録される（図１１のＳ１３０４〜Ｓ１３１６）。これ以降のクライアント１０１と連携先アプリケーション５０３が連携する手順は、実施例１の図１２と同様である。
以上で、実施例２の説明を終了する。

以上示したように、実施例２によれば、実施例１の効果に加えて、プロキシーアプリケーション９０１がインストールされた後に、情報処理端末１０２にアプリケーションがインストールされた場合にも、クライアント１０１と連携先アプリケーション５０３が連携することが可能となる。

なお、実施例１及び実施例２では、情報処理端末１０２にアプリケーションがインストールされたタイミングで、プロキシーアプリケーション９０１が制御部５０２を介して、アプリケーションの提供する機能の情報をＷｅｂ Ｉｎｔｅｎｔｓの形式に変換してＵＡ１０６に登録する例を示した。しかし、制御部５０２又はプロキシーアプリケーション９０１又はＵＡ１０６等が定期的に情報処理端末１０２内を検索し、該定期的な検索で新たに登録すべきアプリケーションの提供する機能の情報を検出したタイミング、該情報をＷｅｂ Ｉｎｔｅｎｔｓの形式に変換してＵＡ１０６に登録するようにしてもよい。また、ＵＡ１０６を起動されたときに新たに登録すべきアプリケーションの提供する機能の情報を検索し、該検索で新たに登録すべきアプリケーションの提供する機能の情報を検出した場合に、該情報をＷｅｂ Ｉｎｔｅｎｔｓの形式に変換してＵＡ１０６に登録するようにしてもよい。

実施例３では、ＵＡ１０６に登録するサービスの情報は、プロキシーアプリケーション９０１の提供機能の情報のみとする。そして、ユーザがＷｅｂ Ｉｎｔｅｎｔの処理要求先として、プロキシーアプリケーション９０１の提供機能を選択した際に、プロキシーアプリケーション９０１の公開ページに連携可能なアプリケーションを列挙する例を説明する。

図１５は、実施例３のテーブル構成を例示する図である。
図１５（ａ）〜（ｃ）は、図１０（ｂ）〜（ｄ）で説明したテーブルに、実施例３に適合したデータを格納した例を示している。

次に、図１６、図１７を用いて、実施例３におけるクライアント１０１と情報処理端末１０２内の連携先アプリケーション５０３が連携する際の動作について説明する。

まず、図１６のシーケンス図を用いて、情報処理端末１０２にプロキシーアプリケーション９０１がインストールされ、ＵＡ１０６にプロキシーアプリケーション９０１のＷｅｂ Ｉｎｔｅｎｔｓの情報が格納されるまでの動作について説明する。

図１６は、実施例３において情報処理端末１０２にプロキシーアプリケーション９０１がインストールされ、ＵＡ１０６にＷｅｂ Ｉｎｔｅｎｔｓの情報が格納されるまでの動作を示すシーケンス図である。

図１１のＳ１３０１，Ｓ１３０２と同様の処理によりプロキシーアプリケーション９０１がインストールされ、起動されると、プロキシーアプリケーション９０１は、Ｓ１９０１の処理を実行する。Ｓ１９０１では、プロキシーアプリケーション９０１は、図１５（ｃ）に示したＡｃｔｉｏｎ変換テーブル１２４０を使って、図１５（ｃ）に示したアプリケーション情報変換テーブル１２５０を作成する。

この際、アプリケーション情報変換テーブル１２５０のＡｐｐ ＩＤは、実施例３では使用しないため空欄とする。ａｃｔｉｏｎには、Ａｃｔｉｏｎ変換テーブル１２４０のＷｅｂ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎに格納されている値のうち、異なる値のもののみを格納する。本例では、ＩＤ＝４、ＩＤ＝６のＷｅｂ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎの値は、それぞれＩＤ＝３、ＩＤ＝５と同一であるため、アプリケーション情報変換テーブル１２５０のａｃｔｉｏｎには格納されない。即ち、連携先アプリケーションが提供し得る全ての機能のカテゴリに対する情報を列挙するようにアプリケーション情報変換テーブル１２５０を作成する。

ｔｙｐｅは、すべてのタイプを意味する「＊」を格納する。ｈｒｅｆの値の格納方法はＳ１３０７で説明した方法と同様であるため、説明を省略する。ｔｉｔｌｅには、プロキシーアプリケーション９０１自身のアプリ名である「Ｐｒｏｘｙ Ａｐｐｌｉｃａｔｉｏｎ」を格納する。ｂａｓｅ ＵＲＩには、プロキシーアプリケーション９０１の基準ＵＲＬである「ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｐｒｏｘｙ／」を登録する。上記ｈｒｅｆとｂｅｓｅ ＵＲＩを組み合わせることによってプロキシーアプリケーション９０１のＷｅｂ Ｉｎｔｅｎｔｓの公開ページを生成することが可能となる。

Ｓ１９０２は、図１１のＳ１３０８〜Ｓ１３１６までの処理と同様であるため、説明を省略する。なお、Ｓ１９０１を実行する前に、図１１のＳ１３０３〜Ｓ１３０６で示したアプリケーション情報収集処理を実行し、事前に、図１５（ｃ）に例示した登録済アプリケーション管理テーブル１２６０を生成しておいてもよい。この場合、後述の図１７に示すＳ２００３の処理は、登録済アプリケーション管理テーブル１２６０の値を更新する処理となる。
以上で、本シーケンス図の説明を終了する。

次に、図１７のシーケンス図を用いて、クライアント１０１と連携先アプリケーション５０３が連携する動作について説明する。
図１７は、実施例３においてクライアント１０１と連携先アプリケーション５０３が連携する動作を例示するシーケンス図である。

Ｓ２００１の処理は、図１２のＳ１４０１〜Ｓ１４０９の処理と同様であるため、説明を省略する。ここでは、クライアント１０１は、ａｃｔｉｏｎが「ｓｈａｒｅ」であるＷｅｂ Ｉｎｔｅｎｔｓ要求を発行する。この際、ＵＡ１０６は、図１８（ａ）に例示するようなＵＩを表示して、ユーザによるＷｅｂ Ｉｎｔｅｎｔｓの処理先の選択を受け付ける。

クライアント１０１は、ａｃｔｉｏｎが「ｓｈａｒｅ」であるＷｅｂ Ｉｎｔｅｎｔｓ要求を発行したので、ＵＡ１０６は、図１５（ｂ）の登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０からａｃｔｉｏｎが「ｓｈａｒｅ」であるサービスを抽出して、１８０１〜１８０３のように選択肢として、一覧表示する。

Ｓ２００２では、上記Ｓ２００１の一覧表示に基づくＷｅｂ Ｉｎｔｅｎｔｓの選択を受ける。ここで、Ｗｅｂ Ｉｎｔｅｎｔｓの処理先として、１８０３のプロキシーアプリケーション９０１が選択されたと仮定する。ＵＡ１０６は、プロキシーアプリケーション９０１へＷｅｂ Ｉｎｔｅｎｔｓを処理するためのＨＴＴＰ要求を送信する。

Ｓ２００３では、プロキシーアプリケーション９０１は、アプリケーション情報収集処理を実行し、図１５（ｃ）に示した登録済アプリケーション管理テーブル１２６０に値を格納する。なお、Ｓ２００３の処理は、図１１のＳ１３０３〜Ｓ１３０６と同様であるため、説明を省略する。

Ｓ２００４では、プロキシーアプリケーション９０１は、クライアント１０１で要求されたａｃｔｉｏｎ（本例では「ｓｈａｒｅ」）と一致する機能を提供可能なアプリケーションを抽出して、一覧表示する。なお、上記抽出を実現するために、プロキシーアプリケーション９０１は、Ａｃｔｉｏｎ変換テーブル１２４０と登録済アプリケーション管理テーブル１２６０を用いる。

具体的には、Ａｃｔｉｏｎ変換テーブル１２４０を使って、Ｗｅｂ Ｉｎｔｅｎｔｓのａｃｔｉｏｎ（ｈｔｔｐ：／／Ｗｅｂ Ｉｎｔｅｎｔｓ．ｏｒｇ／ｓｈａｒｅ）をＬｏｃａｌ Ｉｎｔｅｎｔのａｃｔｉｏｎ（ＡＣＴＩＯＮ＿ＳＥＮＤ）に変換する。次に、登録済アプリケーション管理テーブル１２６０を使って、ａｃｔｉｏｎに「ＡＣＴＩＯＮ＿ＳＥＮＤ」を持つ提供機能のアプリケーション（アプリ名）を抽出する。

図１８（ｂ）は、Ｓ２００４の実行後に表示されるＵＩ例である。図１８（ｂ）のＵＩ例では、「ａａａ Ａｐｐ」１８１１と「ｂｂｂ Ａｐｐ」１８１２が、選択肢として一覧表示されている。

なお、一覧表示すべき項目が１つのみであった場合、プロキシーアプリケーション９０１は図１８（ｂ）に示すようなＵＩ画面を表示させず、その１つの項目が選択されたものとして、Ｓ２００５を実行せず、Ｓ２００６に処理を進めてもよい。また、一致するものがない場合は、図１２のＳ１４１４と同様の方法で、処理が失敗した旨をクライアント１０１に返信する。

Ｓ２００５では、連携元アプリケーションとしてのプロキシーアプリケーション９０１は、ユーザによる連携先アプリケーションの選択を受け付ける。具体的には、図１８（ｂ）のＵＩ例において、「ａａａ Ａｐｐ」１８１１または「ｂｂｂ Ａｐｐ」１８１２の選択を受け付ける。そして、「ａａａ Ａｐｐ」１８１１または「ｂｂｂ Ａｐｐ」１８１２の選択を検知すると、連携元アプリケーションとしてのプロキシーアプリケーション９０１は、Ｓ２００６に処理を進める。

Ｓ２００６は、図１２のＳ１４１２〜Ｓ１４１７の処理と同様であるため、説明を省略する。以上で、図１７のシーケンス図の説明を終了する。また、以上で、実施例３の説明を終了する。

以上示したように、実施例３によれば、実施例１の効果に加えて、情報処理端末上でアプリケーションの追加・削除が発生した場合であっても、Ｗｅｂ Ｉｎｔｅｎｔｓ要求が有った場合にアプリケーションの情報を更新することにより、適切にウェブアプリケーションと当該アプリケーションの連携を動的に構築することができる。

実施例４では、ＵＡ１０６のＵＩ上からプロキシーアプリケーション９０１に対して連携先アプリケーション情報の更新処理を発行する例を説明する。

図１９は、実施例４のプロキシーアプリケーション９０１が持つマニフェストファイルの一部を例示する図である。
図１９のマニフェストファイル２２００と、マニフェストファイル７００との差分は、＜ｉｎｔｅｎｔ−ｆｉｌｅｒ＞タグ内の＜ａｃｔｉｏｎ＞タグにてＵＡ１０６からの更新処理を受け付けるための「ｉｎｔｅｎｔ.ａｃｔｉｏｎ.ＳＹＮＣ」というａｃｔｉｏｎが記載されている点である。

図１２のＳ１４０１〜Ｓ１４０９と同様の処理が行われ、ＵＡ１０６により、ユーザがＷｅｂ Ｉｎｔｅｎｔｓの処理先の選択するための一覧が表示される。この際、実施例４のＵＡ１０６は、図２０に示すようなＵＩを表示して、ユーザによる選択を受け付ける。

図２０は、実施例４を実現するＵＩを例示する図である。
図２０において、「更新」ボタン２３０１は、連携先アプリケーションの情報を更新するためのものである。

ユーザによる図２０のＵＩの「更新」ボタン２３０１の押下を検知すると、ＵＡ１０６は、プロキシーアプリケーション９０１に対して、連携先アプリケーションの情報を更新するためのＬｏｃａｌ Ｉｎｔｅｎｔｓ処理（ａｃｔｉｏｎが「ｉｎｔｅｎｔ.ａｃｔｉｏｎ.ＳＹＮＣ」）を発行する。これにより、プロキシーアプリケーション９０１は、「ｉｎｔｅｎｔ.ａｃｔｉｏｎ.ＳＹＮＣ」機能に対応する処理を実行する。この際、プロキシーアプリケーション９０１、制御部５０２、ＵＡ１０６は、図１１のＳ１３０３〜Ｓ１３１６と同等の処理を実行し、登録済アプリケーション管理テーブル１２２０を更新する。

即ち、実施例４では、Ｗｅｂ Ｉｎｔｅｎｔｓの一覧を表示する画面での「更新」ボタン２３０１の押下による更新指示に応じて、プロキシーアプリケーション９０１が制御部５０２を介して新たに登録すべきアプリケーションが提供する機能の情報を検索し、該検索により新たに登録すべきアプリケーションが提供する機能の情報を検出したタイミングで、該情報をＷｅｂ Ｉｎｔｅｎｔｓの形式に変換してＵＡ１０６に登録する。
以上で、実施例４の説明を終了する。

以上示したように、実施例４によれば、実施例１の効果に加えて、また、情報処理端末上でアプリケーションの追加・削除が発生した場合であっても、ユーザの指示に応じてアプリケーションの情報を更新でき、適切にウェブアプリケーションと当該アプリケーションの連携を動的に構築することができる。

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

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

Claims (6)

1. インターネット上でウェブサイトを提供し、データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、中継するウェブブラウザを備える情報処理端末であって、
   前記情報処理端末では、該情報処理端末内で動作する複数のアプリケーションの間でデータを受け渡すためのインテンツを用いた仕組みを有しているオペレーティングシステムが実行され、
   前記情報処理端末内で動作する前記インテンツとして登録されている複数のアプリケーションを、前記ウェブブラウザを介して前記サービスとして呼び出すために、当該複数のアプリケーションのそれぞれに関する定義情報を、前記ウェブブラウザで扱える機能情報の形式に変換する変換手段と、
   前記クライアントが提供する前記ウェブサイト上に用意された、前記サービスを呼び出すためのボタンの押下に応じて、ユーザに対して、前記機能情報に従う複数のサービスの中から１つのサービスを選択できる一覧を表示する画面を提供するための提供手段と、
   前記ボタンの押下に応じて、前記クライアントが管理する該ボタンに対応するデータを受け取る受け取り手段と、を有し、
   前記画面に対するユーザの選択指示に応じて、前記受け取られたデータを該選択指示に対応するアプリケーションで処理させるための前記機能の呼び出しが行われる
   ことを特徴とする情報処理端末。
2. 前記変換手段は、前記アプリケーションの定義情報に含まれる分類を、前記機能情報に含まれる分類情報の形式に合わせて変換することを特徴とする請求項１に記載の情報処理端末。
3. 前記変換手段による変換は、前記情報処理端末にアプリケーションがインストールされたタイミング、定期的な検索で新たに登録すべき情報を検出したタイミング、前記ウェブブラウザを起動されたときに新たに登録すべき情報を検出した場合、の少なくともいずれかで実行されることを特徴とする請求項１又は２に記載の情報処理端末。
4. 前記クライアントが提供する前記ウェブサイト上に用意された前記ボタンは、前記クライアントが管理する前記データを前記情報処理端末内で動作するアプリケーションに共有するための共有ボタンであり、
   前記提供手段は、前記共有ボタンの押下に応じて、ユーザに対して、前記機能情報の中のデータを共有する機能に対応する分類情報に対応する複数のサービスの中から１つのサービスを選択できる一覧を表示する画面を提供することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理端末。
5. インターネット上でウェブサイトを提供し、データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、中継するウェブブラウザを備える情報処理端末の制御方法であって、
   前記情報処理端末では、該情報処理端末内で動作する複数のアプリケーションの間でデータを受け渡すためのインテンツを用いた仕組みを有しているオペレーティングシステムが実行され、
   前記情報処理端末内で動作する前記インテンツとして登録されている複数のアプリケーションを、前記ウェブブラウザを介して前記サービスとして呼び出すために、当該複数のアプリケーションのそれぞれに関する定義情報を、前記ウェブブラウザで扱える機能情報の形式に変換する変換ステップと、
   前記クライアントが提供する前記ウェブサイト上に用意された、前記サービスを呼び出すためのボタンの押下に応じて、ユーザに対して、前記機能情報に従う複数のサービスの中から１つのサービスを選択できる一覧を表示する画面を提供するための提供ステップと、
   前記ボタンの押下に応じて、前記クライアントが管理する該ボタンに対応するデータを受け取る受け取りステップと、を有し、
   前記画面に対するユーザの選択指示に応じて、前記受け取られたデータを該選択指示に対応するアプリケーションで処理させるための前記機能の呼び出しが行われる
   ことを特徴とする情報処理端末の制御方法。
6. コンピュータを、請求項１乃至４のいずれか１項に記載された手段として機能させるためのプログラム。

Images