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

Description

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

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

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

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

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

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

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

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

本発明は、データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末であって、ネットワーク上の第１のサービスが提供する機能を呼び出すための機能情報に基づき、前記中継機能による登録処理を実行する登録手段と、前記情報処理端末内の第２のサービスが提供する機能の呼び出しに応じて前記中継機能を起動する起動手段と、前記第２のサービスが提供する機能が呼び出された際に指定されていたデータを利用する前記第１のサービスが提供する機能を選択するために、前記起動された中継機能による前記登録処理に従う機能情報を、ユーザに対して提供するための提供手段と、前記第２のサービスが提供する機能が呼び出された際の指定内容の一部を、前記中継機能による登録処理に対応する機能情報に含まれる分類情報の形式に変換する変換手段と、を有し、前記提供手段は、前記変換手段により変換された情報に基づいて前記提供を行うことを特徴とする。

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

Ｗｅｂ Ｉｎｔｅｎｔｓの基本的なシステム構成を例示する図。 Ｗｅｂ Ｉｎｔｅｎｔｓの基本的な動作の概要を例示するシーケンス図。 Ｗｅｂ Ｉｎｔｅｎｔｓの登録用マークアップの一例を示す図。 Ｗｅｂ Ｉｎｔｅｎｔｓの基本的なＷｅｂ Ｉｎｔｅｎｔ処理要求の一例を示す図。 Ｌｏｃａｌ Ｉｎｔｅｎｔｓの基本的なシステム構成を例示する図。 Ｌｏｃａｌ Ｉｎｔｅｎｔｓの基本的な動作の概要を例示するシーケンス図。 Ｌｏｃａｌ Ｉｎｔｅｎｔｓの登録用マークアップの一例を示す図。 Ｌｏｃａｌ Ｉｎｔｅｎｔｓの基本的なＬｏｃａｌ Ｉｎｔｅｎｔ処理要求の一例を示す図。 本発明の一実施例を示すシステム構成図。 モバイル端末及びＷｅｂサーバのハードウェア構成を例示する図。 モバイル端末及びＷｅｂサーバのソフトウェア構成を例示する図。 本実施例においてデータを管理するテーブルの構成の一例を示す図。 プロキシーアプリケーションのイントールの動作を例示するシーケンス図。 連携元アプリケーションとＷｅｂアプリケーションの連携の動作を例示するシーケンス図である。 モバイル端末のＵＩを例示する図。 プロキシーアプリケーションのＩｎｔｅｎｔ変換処理を例示するフローチャート。 プロキシーアプリケーションが作成するＷｅｂ Ｉｎｔｅｎｔ処理要求の別の例を示す図。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図６は、Ｌｏｃａｌ Ｉｎｔｅｎｔｓを利用した機能提供に関する基本動作を説明するためのシーケンス図である。
Ｓ６０１で、モバイル端末５００に対するユーザ操作等に応じて、連携先アプリケーション５０３は、モバイル端末５００にインストールされ、制御部５０２に連携先アプリケーション５０３が提供する機能の情報を登録する。

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

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

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

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

以下、図６の説明に戻る。
Ｓ６０２で、連携元アプリケーション５０１は、ボタン押下などのユーザ操作を受け付けると、制御部５０２に対してアプリケーション連携処理要求として、後述のＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を渡す。ここで、Ｓ６０２で連携元アプリケーション５０１が、ボタン押下の操作を受け付けるためのソースコードの例について図８を用いて説明する。

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

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

再び、図６の説明に戻る。
Ｓ６０３で、ｓｔａｒｔＡｃｔｉｖｉｔｙＦｏｒＲｅｓｕｌｔ（）関数が実行されると、制御部５０２は、上述したように指定されたＬｏｃａｌ Ｉｎｔｅｎｔを処理可能なアプリケーションを一覧表示する。ユーザにより一覧から連携先アプリケーション５０３が選択されると、Ｓ６０４で、制御部５０２は、該選択された連携先アプリケーション５０３へ、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を渡す。この際、制御部５０２は、該処理要求に、Ｌｏｃａｌ Ｉｎｔｅｎｔオブジェクトの内容を含める。

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

Ｓ６０６で、連携先アプリケーション５０３は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理が終了すると、その処理結果を制御部５０２に通知する。この通知を受けると、制御部５０２は、Ｓ６０７で、図８に示したコールバック関数ｏｎＡｃｔｉｖｉｔｙＲｅｓｕｌｔ（）を呼び出す。ＵＡ１０２は、コールバック関数ｏｎＡｃｔｉｖｉｔｙＲｅｓｕｌｔ（）によって連携元アプリケーション５０１へ処理結果を返す。

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

＜本発明の実施例におけるシステム構成＞
図９は、本発明の一実施例に係るモバイル端末とＷｅｂ Ｓｅｒｖｅｒなどのネットワークにおける接続関係を示す図である。

図９において、９０１は、情報処理端末の一例としてのモバイル端末のデバイス（Ｄｅｖｉｃｅ）である。モバイル端末９０１には、Ｗｅｂブラウザがインストールされており、無線ＬＡＮや屋外の携帯データ通信キャリア（以後、携帯キャリア）が提供する無線ネットワークにアクセスすることで様々なサービスを利用することができる。

９０３は無線基地局を表している。無線基地局９０３は、携帯キャリアが提供する無線通信の基地局である。９０４はインターネット（Ｉｎｔｅｒｎｅｔ）であり、９０２はインターネット９０４上でサービスを提供するＷｅｂサーバ（Ｗｅｂ Ｓｅｒｖｅｒ）を表している。モバイル端末９０１は、無線基地局９０３の提供するネットワークを介してインターネット９０４へアクセスし、さらにはＷｅｂサーバ９０２が提供するサービスにアクセスすることができる。Ｗｅｂサーバ９０２は、例えば、写真を共有するなど一般的なフォトサービス（ＰｈｏｔｏＳｅｒｖｉｃｅ）を提供しており、Ｗｅｂ Ｉｎｔｅｎｔｓの仕組みを用いたサービスも提供している。そのため、Ｗｅｂサーバ９０２は、図１におけるサービス１０３に相当する。なお、インターネット９０４は、ＬＡＮやインターネットやその組み合わせなどを想定する。接続形態としては、有線や無線を問わない。

＜本実施例のモバイル端末９０１のハードウェア構成例＞
図１０（Ａ）は、図９におけるモバイル端末９０１のハードウェア構成を例示するブロック図である。

モバイル端末９０１は、例えば、スマートフォンやタブレットコンピュータなどであり、小型端末用のオペレーティングシステムや、通話、データ通信を制御するプログラムが動いている。モバイル端末９０１におけるハードウェアの各構成要素は、システムバス１００１に接続されている。ＲＯＭ１００３には、モバイル端末９０１におけるオペレーティングシステム及び、通話、データ通信を制御するアプリケーション等のプログラムが格納されており、これらのプログラムはＣＰＵ１００２で実行される。なお、データ通信を制御するアプリケーションとしては、Ｍａｉｌソフト（電子メールソフト）やＷｅｂブラウザなどがある。

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

ネットワークコントローラ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）１００５は、ホームネットワーク（Ｈｏｍｅ Ｎｅｔｗｏｒｋ）等の無線ＬＡＮに参加するための無線ＬＡＮ通信部１０１１と、携帯キャリアの提供するネットワークに参加するための携帯電話データ通信部１０１２の通信制御を行う。

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

位置検出制御部１０１０は、ＧＰＳセンサー１０１６からモバイル端末９０１の位置情報を取得しオペレーティングシステムに提供する。これらの制御は、ＣＰＵ１００２で動くオペレーティングシステムにて制御される。

＜本実施形態のＷｅｂサーバ９０２のハードウェア構成例＞
図１０（Ｂ）は、Ｗｅｂサーバ９０２のハードウェア構成を例示する図である。

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

ＲＯＭ１０５３或いはハードディスクドライブ（ＨＤＤ）１０５６には、オペレーティングシステム等の制御プログラムが格納されている。なお、ＨＤＤ１０５６の代わりに、ソリッドステートドライブ（ＳＳＤ）等の他の記憶装置を設けてもよい。ＣＰＵ１０５１は、前記制御プログラムを必要に応じてＲＯＭ１０５３或いはＨＤＤ１０５６からＲＡＭ１０５２上へ読み出して実行することで、コンピュータとしての機能を発揮する。また、ＣＰＵ１０５１は、表示装置１０５７を介して各種情報の表示を行うと共に、入力装置１０５４やポインティングデバイス１０５８からユーザ指示等を受け付ける。さらに、ＣＰＵ１０５１は、ネットワークインタフェース（ＮｅｔｗｏｒｋＩ／Ｆ）１０５５を介してネットワークに接続して他の装置との通信を行う。

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

モバイル端末９０１において、連携元アプリケーション１１１０、制御部１１２０、プロキシーアプリケーション１１３０、Ｗｅｂブラウザ１１４０、および各処理部は、モバイル端末９０１のＲＯＭ１００３に保存されたファイルとして存在する。これらは、モバイル端末９０１の起動時や各処理部実行時に、制御部１１２０やその他処理部（即ちＣＰＵ１００２）によってＲＡＭ１００４にロードされて実行され、モバイル端末９０１に各種機能を実現させるプログラムモジュールである。

連携元アプリケーション１１１０は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を作成して他のアプリケーションと連携することが可能である。そのため、連携元アプリケーション１１１０は、図５の連携元アプリケーション５０１に相当する。

制御部１１２０は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求をプロキシーアプリケーション１１３０など他のアプリケーションに渡す役割をする。また、制御部１１２０は、他のアプリケーションからの結果を連携元アプリケーション１１１０に渡す役割もする。そのため、制御部１１２０は、図５の制御部５０２に相当する。

プロキシーアプリケーション１１３０は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を受け付けて処理を行う。そのため、プロキシーアプリケーション１１３０は、図５の連携先アプリケーション５０３に相当する。また、プロキシーアプリケーション１１３０は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストに応答して処理を実行するプログラムとして実装される。さらに、プロキシーアプリケーション１１３０は、Ｗｅｂ Ｉｎｔｅｎｔの処理要求を作成して他のＷｅｂアプリケーションと連携することが可能である。そのため、プロキシーアプリケーション１１３０は、図１のクライアント１０１にも相当する。

プロキシーアプリケーション１１３０は、プレゼンテーション部１１３１、Ｉｎｔｅｎｔ変換部１１３２、Ｌｏｃａｌ Ｉｎｔｅｎｔ処理要求作成部１１３３、変換テーブル管理部１１３４を有する。

プレゼンテーション部１１３１は、後述する通信部１１３６を介して受け取ったページ取得要求などに応じてＨＴＭＬ文書を作成するソフトウェアモジュールである。Ｉｎｔｅｎｔ変換部１１３２は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を解析し、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を、Ｗｅｂ Ｉｎｔｅｎｔの処理要求に変換するソフトウェアモジュールである。また、Ｉｎｔｅｎｔ変換部１１３２は、Ｗｅｂ Ｉｎｔｅｎｔの処理結果をＬｏｃａｌ Ｉｎｔｅｎｔの処理結果に変換する。

Ｌｏｃａｌ Ｉｎｔｅｎｔ処理要求作成部１１３３（以下、処理要求作成部１１３３）は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を作成するソフトウェアモジュールである。例えば、処理要求作成部１１３３は、特定のＵＲＬにアクセスするようにウェブブラウザプログラム（Ｗｅｂブラウザ１１４０）を起動するためのＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を作成する。変換テーブル管理部１１３４は、後述する変換テーブル格納部１１３５から、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求をＷｅｂ Ｉｎｔｅｎｔの処理要求に変換するために必要な情報を取得するソフトウェアモジュールである。

変換テーブル格納部１１３５は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求をＷｅｂ Ｉｎｔｅｎｔの処理要求に変換するために必要な情報を記憶管理する。具体的には、後述する図１２（Ａ）に示すような、Ａｃｔｉｏｎ変換テーブル１２００を記憶管理する。本実施例では、変換テーブル格納部１１３５は、Ａｃｔｉｏｎ変換テーブル１２００を記憶しているが、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求をＷｅｂ Ｉｎｔｅｎｔの処理要求に変換するための情報であればその他の情報を記憶管理するように構成してもよい。

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

Ｗｅｂブラウザ１１４０は、プロキシーアプリケーション１１３０などクライアント１０１の役割をするアプリケーションからの処理要求を、サービス１０３の役割をする他のＷｅｂアプリケーションに渡す役割をする。また、Ｗｅｂブラウザ１１４０は、サービス１０３の役割をする他のＷｅｂアプリケーションからの処理結果をクライアント１０１の役割をするアプリケーションに渡す役割をする。そのため、Ｗｅｂブラウザ１１４０は、図１のＵＡ１０２に相当する。

Ｗｅｂブラウザ１１４０は、通信部１１４１、表示部１１４２、解析部１１４３、サービス管理部１１４４を有する。通信部１１４１は、他の処理部からの要求を受けてＨＴＴＰのリクエストメッセージを外部機器に送信する。また、通信部１１４１は、外部機器からのＨＴＴＰレスポンスメッセージを受信し、後述する解析部１１４３にレスポンスの内容を通知するソフトウェアモジュールである。

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

サービス管理部１１４４は、後述のＷｅｂ Ｉｎｔｅｎｔｓサービス格納部１１４５から登録済みのＷｅｂ Ｉｎｔｅｎｔｓサービスを特定する情報を取得したり、格納したりするソフトウェアモジュールである。Ｗｅｂ Ｉｎｔｅｎｔｓサービス格納部１１４５（以下、サービス格納部１１４５）は、データを記憶管理し、サービス管理部１１４４からの要求に応じてデータの格納と取り出しを行う。サービス格納部１１４５は、後述する図１２（Ｂ）に示すような、登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０を記憶管理する。

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

Ｗｅｂサーバ９０２において、Ｗｅｂアプリケーション１１５０および各処理部は、Ｗｅｂサーバ９０２のＲＯＭ１０５３あるいはＨＤＤ１０５６に保存されたファイルとして存在する。これらは実行時にＯＳやその各処理部を利用する他の処理部（即ちＣＰＵ１０５１）によってＲＡＭ１０５２にロードされ実行されるプログラムモジュールである。

Ｗｅｂアプリケーション１１５０は、例えば、写真などの画像データを保管して、共有するなど一般的なフォトサービス（ＰｈｏｔｏＳｅｒｖｉｃｅ）を提供するアプリケーションである。また、Ｗｅｂアプリケーション１１５０は、Ｗｅｂ Ｉｎｔｅｎｔｓ技術を利用してサービスを提供するＷｅｂ Ｉｎｔｅｎｔｓサービスの機能を有する。そのため、Ｗｅｂアプリケーション１１５０は、図１のサービス１０３に相当する。さらに、Ｗｅｂアプリケーション１１５０は、ＨＴＴＰリクエストに応答して処理を実行するプログラムとして実装される。

Ｗｅｂアプリケーション１１５０は、Ｗｅｂ Ｉｎｔｅｎｔ処理部１１５２、プレゼンテーション部１１５３、画像管理部１１５４を有する。Ｗｅｂ Ｉｎｔｅｎｔ処理部１１５２は、Ｗｅｂ Ｉｎｔｅｎｔオブジェクトを解析し、処理するソフトウェアモジュールである。プレゼンテーション部１１５３は、後述する通信部１１５１を介して受け取ったページ取得要求などに応じてＨＴＭＬ文書を作成するソフトウェアモジュールである。画像管理部１１５４は、他の処理部からの要求に応じて画像データ格納部１１５５から画像データを取得したり、格納したりするソフトウェアモジュールである。

画像データ格納部１１５５は、データを記憶管理し、画像管理部１１５４からの要求に応じてデータの格納と取り出しを行う。通信部１１５１は、外部機器からのＨＴＴＰリクエストメッセージを受信しプレゼンテーション部１１５３にリクエストの内容を通知するソフトウェアモジュールである。また、通信部１１５１は、Ｗｅｂサーバ機能を有しており、プレゼンテーション部１１５３からの要求を受けてＨＴＴＰのレスポンスメッセージを外部機器に送信する。画像データ格納部１１５５では、後述する図１２（Ｃ）に示すような、画像データ管理テーブル１２５０を記憶管理する。なお、画像データ格納部１１５５は、Ｗｅｂサーバ９０２とは別の機器上にあってもよい。

＜本実施形態の各格納部が管理するテーブル＞
図１２（Ａ）は、モバイル端末９０１の変換テーブル格納部１１３５が管理するテーブル構成の一例を示す図である。なお、図１２（Ａ）のテーブル構成は一例であり本例とは異なるテーブル構成であってもよい。

Ａｃｔｉｏｎ変換テーブル１２００で管理する情報は、「Ａｃｔｉｏｎ ＩＤ」、「Ｌｏｃａｌ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎ」、「Ｗｅｂ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎ」である。「Ａｃｔｉｏｎ ＩＤ」は、Ｌｏｃａｌ Ｉｎｔｅｎｔのａｃｔｉｏｎを一意に識別するためのＩＤである。「Ｌｏｃａｌ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎ」は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求のａｃｔｉｏｎを示している。「Ｗｅｂ Ｉｎｔｅｎｔｓ ａｃｔｉｏｎ」は、Ｗｅｂ Ｉｎｔｅｎｔｓのａｃｔｉｏｎを示している。

Ａｃｔｉｏｎ変換テーブル１２００の「Ａｃｔｉｏｎ ＩＤ」が「１」であるレコードを例に説明を行う。このレコードでは、Ｌｏｃａｌ Ｉｎｔｅｎｔｓのａｃｔｉｏｎが「ＡＣＴＩＯＮ＿ＳＥＮＤ」である場合、Ｗｅｂ Ｉｎｔｅｎｔの処理要求では「ｈｔｔｐ：／／Ｗｅｂ Ｉｎｔｅｎｔｓ.ｏｒｇ／ｓｈａｒｅ」に変換する必要があることを示している。なお、本例では多くのＬｏｃａｌ Ｉｎｔｅｎｔｓのａｃｔｉｏｎを変換できるようにしているが、本発明を用いて呼び出したい機能の「ａｃｔｉｏｎ」のみを変換できるように構成しておけばよい。例えば図７で示したマニフェストファイルで宣言した「ａｃｔｉｏｎ」のみを変換できるように構成してもよい。

図１２（Ｂ）は、モバイル端末９０１のサービス格納部１１４５が管理するテーブル構成の一例である。なお、図１２（Ｂ）のテーブル構成は一例であり、本例とは異なるテーブル構成であってもよい。

登録済Ｗｅｂ Ｉｎｔｅｎｔｓサービステーブル１２３０（以下、登録済サービステーブル１２３０）は、Ｗｅｂブラウザ１１４０が仲介することができるＷｅｂ Ｉｎｔｅｎｔｓサービスの提供機能を管理する。登録済サービステーブル１２３０で管理する情報は、「ＳｅｒｖｉｃｅＩＤ」、「ａｃｔｉｏｎ」、「ｔｙｐｅ」、「ｈｒｅｆ」、「ｄｉｓｐｏｓｉｔｉｏｎ」、「ｂａｓｅＵＲＩ」等である。

「ＳｅｒｖｉｃｅＩＤ」は、Ｗｅｂブラウザ１１４０内でＷｅｂ Ｉｎｔｅｎｔｓサービスの提供機能を一意に識別するためのＩＤである。「ａｃｔｉｏｎ」は、提供機能のカテゴリを示すものであり、どのような機能、サービスを提供するかを示す情報である。「ｔｙｐｅ」は、提供機能が扱えるデータなどの種類を示すものであり、ａｃｔｉｏｎに対して何を扱えるかを示している。「ｈｒｅｆ」は、提供機能の相対ＵＲＬを示す。「ｔｉｔｌｅ」は、提供機能のタイトルを示すものである。また、「ｄｉｓｐｏｓｉｔｉｏｎ」は、呼び出された提供機能がどのように表示されるかを示す。「ｂａｓｅＵＲＩ」は、提供機能の基準となるＵＲＬを示す。

例えば、登録済サービステーブル１２３０のＳｅｒｖｉｃｅＩＤが「１」であるレコードを例にして説明する。このレコードでは、Ｗｅｂブラウザ１２４０は、「ｈｔｔｐ：／／ａａａ.ｃｏｍ／ａａａ＿ｓｈａｒｅ.ｈｔｍｌ」にＷｅｂ Ｉｎｔｅｎｔの処理要求を仲介できることが分かる。

図１２（Ｃ）は、Ｗｅｂサーバ９０２の画像データ格納部１１５５が管理するテーブル構成の一例である。なお、図１２（Ｃ）のテーブル構成は一例であり、本例とは異なるテーブル構成であってもよい。

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

＜本実施形態のプロキシーアプリケーション１１３０のインストール＞
以下、図１３のシーケンス図を用いて、プロキシーアプリケーション１１３０をモバイル端末９０１にインストールする動作について説明する。
図１３は、プロキシーアプリケーション１１３０をモバイル端末９０１にインストールする動作を例示するシーケンス図である。

まず、ユーザ操作等を受け付けて、モバイル端末９０１にプロキシーアプリケーション１１３０のインストールを開始する。Ｓ１３０１で、プロキシーアプリケーション１１３０は、制御部１１２０に自身が提供する機能の情報の登録を依頼する。Ｓ１３０２で、制御部１１２０は、プロキシーアプリケーション１１３０が提供する機能の情報を登録する処理を行い、該登録結果をプロキシーアプリケーション１１３０に通知する。

なお、ここでは、プロキシーアプリケーション１１３０のマニフェストファイルは、例えば図７で説明したマニフェストファイル７００と同じものとする。つまり、ａｃｉｔｉｖｉｔｙの名前が「ＳｅｎｄＡｃｉｔｉｖｉｔｙ」である機能を持ち、データを送信する（ｉｎｔｅｎｔ.ａｃｔｉｏｎ.ＳＥＮＤ）ためのＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を受け付けることができる。そして、あらゆるフォーマット（＊）の画像データを扱うことが可能である。

Ｓ１３０３で、プロキシーアプリケーション１１３０の処理要求作成部１１３３は、Ｗｅｂブラウザ１１４０を起動するためのＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を作成して制御部１１２０に処理を依頼する。この際、Ｗｅｂブラウザ１１４０がアクセスするＵＲＬとして、プロキシーアプリケーション１１３０が公開する、Ｗｅｂ Ｉｎｔｅｎｔｓサービスを登録するためのページを指定する。指定するＵＲＬはｌｏｃａｌｈｏｓｔとなる。

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

Ｓ１３０６で、プロキシーアプリケーション１１３０は、Ｗｅｂ Ｉｎｔｅｎｔｓサービスの登録用マークアップを作成する。なお、本例で作成するＷｅｂ Ｉｎｔｅｎｔｓサービスの登録用マークアップは、Ｗｅｂアプリケーション１１５０がＷｅｂ Ｉｎｔｅｎｔｓサービスの提供機能を登録するためのものである。Ｓ１３０７で、プロキシーアプリケーション１１３０は、上記Ｓ１３０６で作成した登録用マークアップを含むＨＴＭＬ文書をＨＴＴＰレスポンスとして、Ｗｅｂブラウザ１１４０に送信する。

Ｗｅｂブラウザ１１４０は、上記Ｓ１３０７のＨＴＭＬ文書を受信すると、Ｓ１３０８で、該ＨＴＭＬ文書に含まれる登録用マークアップを解析し、ＵＡ１０２として、Ｗｅｂ Ｉｎｔｅｎｔｓサービスの提供機能を自身に登録する。具体的には、Ｗｅｂブラウザ１１４０の解析部１１４３が登録用マークアップの解析を行い、Ｗｅｂ Ｉｎｔｅｎｔｓサービスの特定を行う。その後、Ｗｅｂブラウザ１１４０のサービス管理部１１４４が必要な情報をサービス格納部１１４５の登録済サービステーブル１２３０に登録する。

以上のようにしてプロキシーアプリケーション１１３０のインストールが行われる。なお、上記Ｓ１３０３〜Ｓ１３０８で示した処理は、本件における必須な構成ではない。しかし、このようにインストール時にＷｅｂ Ｉｎｔｅｎｔｓサービスの提供機能をＷｅｂブラウザ１１４０に登録することで、連携を行う際に連携先のＷｅｂ ＩｎｔｅｎｔｓサービスがＷｅｂブラウザに１つも登録されていないという現象を回避することができる。また、プロキシーアプリケーション１１３０を開発したベンダーがお奨めするＷｅｂ ＩｎｔｅｎｔｓサービスをＷｅｂブラウザ１１４０に登録することもできる。

＜本実施例のアプリケーションの連携＞
以下、図１４乃至図１７を用いて、連携元アプリケーション１１１０とＷｅｂアプリケーション１１５０が連携する動作について説明する。

図１４は、連携元アプリケーション１１１０とＷｅｂアプリケーション１１５０が連携する一連の動作を例示するシーケンス図である。
まず、ユーザ操作に応じて、連携元アプリケーション１１１０は、図１５（Ａ）のＵＩを表示する。

図１５は、連携元アプリケーション１１１０とＷｅｂアプリケーション１１５０が連携する場合にモバイル端末９０１のディスプレイ１０１４に表示されるＵＩ画面を例示する図である。
図１５（Ａ）のＵＩは、連携元アプリケーション１１１０から「ｉｍａｇｅ００１．ｊｐｇ」１５０２を他のアプリケーションに送信するためのＵＩを示す。図１５（Ａ）のＵＩにおいて、ユーザからの「送信する」ボタン１５０１の押下を受け付けると、連携元アプリケーション１１１０は、図１４のＳ１４０１の処理を行う。

Ｓ１４０１で、連携元アプリケーション１１１０は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を作成して、そのＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を、制御部１１２０に渡す。なお、ここで連携元アプリケーション１１１０がＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を作成するためのソースコードは、例えば図８で示したソースコード８００と同じであるとする。つまり、ａｃｔｉｏｎとして「ＡＣＴＩＯＮ＿ＳＥＮＤ」を扱うことができ、あらゆる画像データのフォーマットを処理できるアプリケーションとの連携を要求している。なお、上記Ｓ１４０１の処理は図６のＳ６０２に対応する。

制御部１１２０は、上記Ｓ１４０１のＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を受信すると、該Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を解析する。そして、制御部１１２０は、自身に登録されているアプリケーションの提供機能の中から、指定されたＬｏｃａｌ Ｉｎｔｅｎｔのａｃｔｉｏｎとｔｙｐｅが一致するアプリケーションの提供機能を抽出し、該提供機能のアプリ名を、図１５（Ｂ）のように一覧表示させることでユーザに選択を要求する。

図１５（Ｂ）のＵＩでは、プロキシーアプリケーション１１３０とメールアプリケーションが選択肢１５１１，１５１２として表示されている。これらのアプリケーションが上記Ｓ１４０１で受信したＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を処理可能であることが分かる。ユーザにより図１５（Ｂ）のＵＩの一覧からプロキシーアプリケーション１１３０（選択肢１５１１）が選択されたことを受け付けると、制御部１１２０は、Ｓ１４０２の処理を実行する。

Ｓ１４０２で、制御部１１２０は、上記Ｓ１４０１で連繋元アプリケーション１１０から渡されたＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を、連携先アプリケーションとしてのプロキシーアプリケーション１１３０に渡す（これにより、「ＡＣＴＩＯＮ＿ＳＥＮＤ」の実行を要求する）。なお、この処理は、図６のＳ６０４に対応する。

プロキシーアプリケーション１１３０は、上記Ｓ１４０２のＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を受信すると、Ｓ１４０３の処理を実行する。Ｓ１４０３で、プロキシーアプリケーション１１３０の処理要求作成部１１３３は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求を作成して制御部１１２０に渡す。

なお、上記Ｓ１４０３で作成するＬｏｃａｌ Ｉｎｔｅｎｔの処理要求は、プロキシーアプリケーション１１３０が公開するページ（Ｗｅｂサイト）にアクセスするようにＷｅｂブラウザ１１４０を起動するためのＬｏｃａｌ Ｉｎｔｅｎｔの処理要求である。ここで指定するプロキシーアプリケーション１１３０が公開するページは、クライアント１０１として、Ｗｅｂ Ｉｎｔｅｎｔｓサービスの提供機能を呼び出すためのページ（Ｗｅｂサイト）である。

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

Ｓ１４０６で、プロキシーアプリケーション１１３０は、上記Ｓ１４０２で受け取ったＬｏｃａｌ Ｉｎｔｅｎｔの処理要求から、Ｗｅｂ Ｉｎｔｅｎｔの処理要求を作成する。ここで、図１６を用いて、Ｓ１４０６におけるプロキシーアプリケーション１１３０の処理について説明する。

図１６は、Ｓ１４０６におけるプロキシーアプリケーション１１３０の処理を例示するフローチャートである。なお、このフローチャートの各ステップの処理はモバイル端末９０１のＣＰＵ１００２がＲＯＭ１００３等の不揮発性の記憶装置に記憶された本発明に特有な制御プログラムを読み込み実行することに応じて実現されるものとする。

Ｓ１６０１で、プレゼンテーション部１１３１は、ＨＴＴＰのリクエスト（図１４のＳ１４０５）を受信したかを監視する。そして、ＨＴＴＰのリクエストを受信していないと判定した場合（Ｓ１６０１でＮｏの場合）、プレゼンテーション部１１３１は、Ｓ１６０１の監視を続ける。一方、プレゼンテーション部１１３１がＨＴＴＰのリクエストを受信したと判定した場合（Ｓ１６０１でＹｅｓの場合）、Ｉｎｔｅｎｔ変換部１１３２が、Ｓ１６０２を実行する。

Ｓ１６０２で、Ｉｎｔｅｎｔ変換部１１３２は、図１４のＳ１４０２で受け取ったＬｏｃａｌ Ｉｎｔｅｎｔの処理要求を読み込み、Ｓ１６０３に処理を遷移させる。Ｓ１６０３で、Ｉｎｔｅｎｔ変換部１１３２は、上記Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求のａｃｔｉｏｎを、Ｗｅｂ Ｉｎｔｅｎｔｓのａｃｔｉｏｎに変換し、Ｓ１６０４に処理を遷移させる。

より具体的には、Ｉｎｔｅｎｔ変換部１１３２は、変換テーブル管理部１１３４に対して、上記Ｓ１４０２で受け取ったＬｏｃａｌ Ｉｎｔｅｎｔの処理要求のａｃｔｉｏｎを渡す。変換テーブル管理部１１３４は、変換テーブル格納部１１３５で管理されるＡｃｔｉｏｎ変換テーブル１２００から上記Ｓ１４０２で受け取ったＬｏｃａｌ Ｉｎｔｅｎｔの処理要求のａｃｔｉｏｎに紐づくＷｅｂ Ｉｎｔｅｎｔｓのａｃｔｉｏｎを取得する。そして、変換テーブル管理部１１３４は、取得したＷｅｂ ＩｎｔｅｎｔｓのａｃｔｉｏｎをＩｎｔｅｎｔ変換部１１３２に渡す。例えば、上記Ｓ１４０２で受け取ったＬｏｃａｌ Ｉｎｔｅｎｔの処理要求のａｃｔｉｏｎが「ＡＣＴＩＯＮ＿ＳＥＮＤ」であった場合、「ｈｔｔｐ:／／Ｗｅｂ Ｉｎｔｅｎｔｓ.ｏｒｇ／ｓｈａｒｅ」に変換される。

Ｓ１６０４で、Ｉｎｔｅｎｔ変換部１１３２は、上記Ｓ１４０２で受け取ったＬｏｃａｌ Ｉｎｔｅｎｔの処理要求のｔｙｐｅをＷｅｂ Ｉｎｔｅｎｔｓのｔｙｐｅに変換し、Ｓ１６０５に処理を遷移させる。本実施例では、Ｌｏｃａｌ Ｉｎｔｅｎｔｓ、Ｗｅｂ Ｉｎｔｅｎｔｓともに、ｔｙｐｅはＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ）のＣｏｎｔｅｎｔ−Ｔｙｐｅの形で記載されている。そのため、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求のｔｙｐｅに記載されている内容をそのままＷｅｂ Ｉｎｔｅｎｔの処理要求に使用する。

例えば、図４で示したＬｏｃａｌ Ｉｎｔｅｎｔの処理要求のｔｙｐｅは、「ｉｍａｇｅ／＊」であるため、Ｗｅｂ Ｉｎｔｅｎｔの処理要求としても「ｉｍａｇｅ／＊」を使用する。なお、ｔｙｐｅについても別の形式で記載されるような場合は、ａｃｔｉｏｎの場合と同じく、変換テーブル格納部１１３５にｔｙｐｅを変換するテーブルを持つように構成してもよい。以上のように、Ｉｎｔｅｎｔ変換部１１３２は、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求に含まれる指定内容の一部を、ＵＡの中継機能による登録処理に対応する機能情報に含まれる分類情報（ａｃｔｉｏｎに記載される情報）やデータ種類の情報（ｔｙｐｅに記載される情報）等の形式に変換する。

Ｓ１６０５で、Ｉｎｔｅｎｔ変換部１１３２は、上記Ｓ１６０３，Ｓ１６０４で変換したａｃｔｉｏｎ、ｔｙｐｅを用いてＷｅｂ Ｉｎｔｅｎｔの処理要求を作成し、本フローチャートの処理を終了する。なお、本例では、上記Ｓ１４０２で受け取ったＬｏｃａｌ Ｉｎｔｅｎｔの処理要求の内容が図８で示したＬｏｃａｌ Ｉｎｔｅｎｔの処理要求であるとする。そして、上記Ｓ１４０６で作成したＷｅｂ Ｉｎｔｅｎｔの処理要求は、図４で示したものとなる。以上のようにして、Ｌｏｃａｌ Ｉｎｔｅｎｔの処理要求からＷｅｂ Ｉｎｔｅｎｔの処理要求を作成する。

以下、図１４の説明に戻る。
Ｓ１４０７で、プレゼンテーション部１１３１は、クライアント１０１として、通信部１１３６を介して、上記Ｓ１４０６で作成したＷｅｂ Ｉｎｔｅｎｔの処理要求を含むＨＴＭＬ文書を、ＨＴＴＰレスポンスとして、ＵＡ１０２としてのＷｅｂブラウザ１１４０に送信する。なお、この処理は図２のＳ２０４に対応する。

Ｓ１４０８で、Ｗｅｂブラウザ１１４０は、ＵＡ１０２として、上記Ｓ１４０７で受信したＨＴＭＬ文書を表示する。具体的には、Ｗｅｂブラウザ１１４０の解析部１１４３が、上記ＨＴＭＬ文書を解析し、表示部１１４２がＨＴＭＬ文書の表示を行う。

ここで、図１５（Ｃ）のＵＩは、上記Ｓ１４０８でＷｅｂブラウザ１１４０がＵＡ１０２として表示するＵＩである。図１５（Ｃ）のＵＩにおいては、「共有する」ボタン１５２１は、ＩＤが「ｓｈａｒｅ−ｐｈｏｔｏ」であり、ボタン押下すると図４で示したＷｅｂ Ｉｎｔｅｎｔ処理要求に含まれる無名関数が実行される。つまり、ユーザ操作により「共有する」ボタン１５２１が押下されたことを受け付けて、Ｗｅｂブラウザ１１４０は、ＵＡ１０２として、Ｓ１４０９の処理を実行する。なお、この処理は図２のＳ２０５に対応する。

Ｓ１４０９で、ＵＡ１０２としてのＷｅｂブラウザ１１４０は、図４で示した無名関数を実行し、ＵＡ１０２としてのＷｅｂブラウザ１１４０に登録されているＷｅｂ Ｉｎｔｅｎｔｓサービスの提供機能の一覧を表示する。より詳細には、サービス管理部１１４４は、サービス格納部１１４５の登録済サービステーブル１２３０から、情報を取得する。その取得する情報とは、Ｗｅｂ Ｉｎｔｅｎｔ処理要求で指定されたａｃｔｉｏｎとｔｙｐｅに合致するＷｅｂ Ｉｎｔｅｎｔｓサービスの提供機能を特定する情報である。例えば、Ｗｅｂ Ｉｎｔｅｎｔ処理要求が図４で示したものであった場合は、ａｃｔｉｏｎが「ｓｈａｒｅ」であり、ｔｙｐｅが「ｉｍａｇｅ／＊」である。そのため、サービス管理部１１４４は、登録済サービステーブル１２３０のＳｅｒｖｉｃｅＩＤが「１」と「３」であるレコードの情報を取得する。

図１５（Ｄ）は、上記Ｓ１４０９においてＷｅｂブラウザ１１４０がサービスの提供機能の一覧表示を行うＵＩの一例である。図１５（Ｄ）のＵＩでは、登録済サービステーブル１２３０のＳｅｒｖｉｃｅＩＤが「１」と「３」であるＷｅｂ Ｉｎｔｅｎｔｓサービスの提供機能を呼び出すためのボタン（選択肢としてのボタン１５３１，１５３２）が表示されている。図１５（Ｄ）のＵＩにおいて「Ｉｍａｇｅ ｓｈａｒｅ ｓｅｒｖｉｃｅ」ボタン１５３１が押下されると、ＵＡ１０２としてのＷｅｂブラウザ１１４０は、Ｓ１４１０の処理を実行する。

なお、本例では、上記Ｓ１４０６で作成するＷｅｂ Ｉｎｔｅｎｔの処理要求を図４で示したものとしたが、別の例として、以下、上記Ｓ１４０６で作成するＷｅｂ Ｉｎｔｅｎｔの処理要求を図１７とした場合について説明する。

図１７は、Ｓ１４０６にて作成されるＷｅｂ Ｉｎｔｅｎｔの処理要求を含むＨＴＭＬ文書を例示する図である。図１７のＷｅｂ Ｉｎｔｅｎｔの処理要求は、ボタン押下時に無名関数を実行するのではなく、当該ＨＴＭＬページをｌｏａｄしたときに無名関数を実行するように記載されている。そのため、上記Ｓ１４０８で示した図１５（Ｃ）のようなＵＩが表示されることなく、無名関数が実行され、Ｓ１４０９で表示した図１５（Ｄ）のＵＩが表示されることになる。このようにすることで、図１５（Ｃ）のＵＩでは必要だった「共有する」ボタンを押下するというユーザ操作の手間を省くことができる。

以下、図１４の説明に戻る。
Ｓ１４１０で、Ｗｅｂブラウザ１１４０は、ＵＡ１０２として、サービス１０３としてのＷｅｂサーバ９０２のＷｅｂアプリケーション１１５０に、上記Ｓ１４０７で受け取ったＷｅｂ Ｉｎｔｅｎｔの処理要求をＨＴＴＰリクエストとして送信する。その際、送信するデータには、上記Ｓ１４０９で実行した図４（又は図１７）の無名関数によって作成されたＷｅｂ Ｉｎｔｅｎｔオブジェクトも含める。なお、この処理は図２のＳ２０７に対応する。

上記Ｓ１４１０のＨＴＴＰリクエストを受信すると、Ｗｅｂアプリケーション１１５０は、Ｓ１４１１の処理を実行する。Ｓ１４１１で、Ｗｅｂアプリケーション１１５０は、サービス１０３として、上記Ｓ１４１０で受信したＷｅｂ Ｉｎｔｅｎｔの処理要求からＷｅｂ Ｉｎｔｅｎｔオブジェクトを取り出し、提供機能の処理として、Ｗｅｂ Ｉｎｔｅｎｔオブジェクトに含まれる画像データの保存を行う。より詳細には、Ｗｅｂアプリケーション１１５０のＷｅｂ Ｉｎｔｅｎｔ処理部１１５２は、受信したＷｅｂ Ｉｎｔｅｎｔの処理要求を解析し、Ｗｅｂ Ｉｎｔｅｎｔオブジェクトに含まれる画像データを取得して、画像管理部１１５４に渡す。画像管理部１１５４は、受け取った画像データを、画像データ格納部１１５５の画像データ管理テーブル１２５０に登録する。つまり、本例であると、図１５（Ａ）で連携元アプリケーション１１１０が表示していた「ｉｍａｇｅ００１.ｊｐｇ」１５０２の画像データが、サービス１０３としてのＷｅｂサーバ９０２の画像データ格納部１１５５に登録される。なお、上記Ｓ１４１１の処理は図２のＳ２０８に対応する。

Ｗｅｂサーバ９０２のＷｅｂアプリケーション１１５０は、サービス１０３としてのＷｅｂ Ｉｎｔｅｎｔの処理が終了すると、Ｓ１４１２の処理を実行する。

Ｓ１４１２で、Ｗｅｂサーバ９０２のＷｅｂアプリケーション１１５０は、サービス１０３として、Ｗｅｂ Ｉｎｔｅｎｔの処理結果を、クライアント１０１としてのプロキシーアプリケーション１１３０に伝えるＥＣＭＡＳｃｒｉｐｔを含む応答を、ＵＡ１０２としてのＷｅｂブラウザ１１４０に返す。なお、この処理は図２のＳ２０９に対応する。

Ｗｅｂブラウザ１１４０は、ＵＡ１０２として、上記Ｓ１４１２の応答を受信すると、Ｓ１４１３の処理を実行する。Ｓ１４１３で、Ｗｅｂブラウザ１１４０は、ＵＡ１０２として、上記Ｓ１４１２の応答に含まれるＥＣＭＡＳｃｒｉｐｔを実行し、ｓｔａｒｔＡｃｔｉｖｅｔｙ（）関数の引数で指定されたコールバック関数ｏｎＳｕｃｃｅｓｓ（）を呼び出す。なお、この処理は図２のＳ２１０に対応する。

Ｓ１４１４で、Ｗｅｂブラウザ１１４０は、ＵＡ１０２として、上記Ｓ１４１３で呼び出したコールバック関数ｏｎＳｕｃｃｅｓｓ（）によって、クライアント１０１としてのプロキシーアプリケーション１１３０へ処理結果を返す。なお、この処理は図２のＳ２１１に対応する。

プロキシーアプリケーション１１３０は、ＵＡ１０２として、上記Ｓ１４１４の処理結果を受信すると、Ｓ１４１５の処理を実行する。Ｓ１４１５で、プロキシーアプリケーション１１３０のＩｎｔｅｎｔ変換部１１３２は、連携先アプリケーション５０３として、上記Ｓ１４１４で受け取ったＷｅｂ Ｉｎｔｅｎｔの処理結果に応じてＬｏｃａｌ Ｉｎｔｅｎｔの処理結果を作成する。ここでは、上記Ｓ１４１４で受け取った結果は成功であるとし、成功を示す識別子をＬｏｃａｌ Ｉｎｔｅｎｔの処理結果に含めるものとする。なお、上記Ｓ１４１４で受け取った結果は失敗の場合、失敗を示す識別子をＬｏｃａｌ Ｉｎｔｅｎｔの処理結果に含めるものとする。

Ｓ１４１６で、プロキシーアプリケーション１１３０は、連携先アプリケーションとして、上記Ｓ１４１５で作成したＬｏｃａｌ Ｉｎｔｅｎｔの処理結果を、制御部１１２０に通知する。なお、この処理は、図６のＳ６０６に対応する。

制御部１１２０は、上記Ｓ１４１６の通知を受け取ると、Ｓ１４１７の処理を実行する。Ｓ１４１７で、制御部１１２０は、図８のソースコード８００で示したコールバック関数ｏｎＡｃｔｉｖｉｔｙＲｅｓｕｌｔ（）を呼び出し、連携元アプリケーション１１１０に、上記Ｓ１４１６のＬｏｃａｌ Ｉｎｔｅｎｔ処理結果を通知する。なお、この処理は、図６のＳ６０７に対応する。

以上のように、本実施例のプロキシーアプリケーション１１３０は、情報処理端末９０１内のアプリケーションの処理実行要求をＷｅｂアプリケーションが解析可能な処理実行要求に変換し、仲介する。これにより、Ｗｅｂ Ｉｎｔｅｎｔｓに未対応の情報処理端末内で動作するアプリケーション連携の仕組み（例えばＡｎｄｒｏｉｄのＩｎｔｅｎｔｓのようなＬｏｃａｌ Ｉｎｔｅｎｔｓ）から、Ｗｅｂ Ｉｎｔｅｎｔｓなどのネットワーク上のウェブサービス連携を利用することができる。従って、モバイル端末等の情報処理端末内のアプリケーションと、ネットワーク上のサービス（インターネット上のＷｅｂアプリケーション）とを、容易に連携することが可能となる。

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

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

Claims (8)

1. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末であって、
   ネットワーク上の第１のサービスが提供する機能を呼び出すための機能情報に基づき、前記中継機能による登録処理を実行する登録手段と、
   前記情報処理端末内の第２のサービスが提供する機能の呼び出しに応じて前記中継機能を起動する起動手段と、
   前記第２のサービスが提供する機能が呼び出された際に指定されていたデータを利用する前記第１のサービスが提供する機能を選択するために、前記起動された中継機能による前記登録処理に従う機能情報を、ユーザに対して提供するための提供手段と、
   前記第２のサービスが提供する機能が呼び出された際の指定内容の一部を、前記中継機能による登録処理に対応する機能情報に含まれる分類情報の形式に変換する変換手段と、を有し、
   前記提供手段は、前記変換手段により変換された情報に基づいて前記提供を行うことを特徴とする情報処理端末。
2. 前記変換手段は、前記提供手段で提供された機能情報に基づいて選択された前記第１のサービスが提供する機能による前記データを利用した処理結果の前記中継機能を介した通知に応じて、該処理結果を前記第２のサービスが提供する機能の処理結果の形式に変換することを特徴とする請求項１に記載の情報処理端末。
3. 前記ネットワークは、インターネットであることを特徴とする請求項１または２に記載の情報処理端末。
4. 前記クライアント、前記サービス及び前記中継機能の少なくとも２つは、同じ装置で動作する機能であることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理端末。
5. 前記機能情報には、分類情報として、データを共有する機能に対応する分類情報、データを編集する機能に対応する分類情報、データを閲覧する機能に対応する分類情報、データを取得する機能に対応する分類情報、データを保存する機能に対応する分類情報のいずれかが記載されていることを特徴とする請求項１乃至４のいずれか１項に記載の情報処理端末。
6. 前記起動手段は、前記中継機能として動作するウェブブラウザプログラムを起動することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理端末。
7. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末の制御方法であって、
   ネットワーク上の第１のサービスが提供する機能を呼び出すための機能情報に基づき、前記中継機能による登録処理を実行する登録ステップと、
   前記情報処理端末内の第２のサービスが提供する機能の呼び出しに応じて前記中継機能を起動する起動ステップと、
   前記第２のサービスが提供する機能が呼び出された際に指定されていたデータを利用する前記第１のサービスが提供する機能を選択するために、前記起動された中継機能による前記登録処理に従う機能情報を、ユーザに対して提供するための提供ステップと、
   前記第２のサービスが提供する機能が呼び出された際の指定内容の一部を、前記中継機能による登録処理に対応する機能情報に含まれる分類情報の形式に変換する変換ステップと、を有し、
   前記提供ステップにおいて、前記変換ステップにおいて変換された情報に基づいて前記提供を行うことを特徴とする情報処理端末の制御方法。
8. コンピュータを、請求項１乃至６のいずれか１項に記載された手段として機能させるためのプログラム。

Images