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

Abstract

【課題】ＷｅｂＩｎｔｅｎｔｓクライアントの提供するデータのタイプと、サービスが処理できるデータのタイプが異なる場合においても、ユーザの手を煩わすことなく容易に複数のサービスを連携して所望のサービスを利用する可能とすること。【解決手段】情報処理端末５３０のＷｅｂブラウザ７５０は、ユーザよりクライアント（サーバ５１０）で管理される特定のデータに対する機能の呼び出しが指示された場合に、前記特定のデータを、該呼び出しが指示された機能に対応するカテゴリに属する第１機能情報の処理可能なタイプに適合させるための第２機能情報を特定し（Ｓ９０５（図１２））、前記特定された第２機能情報を用いて呼び出した機能により処理された前記特定のデータを、前記第１機能情報を用いて呼び出した機能で処理するための要求を行い（Ｓ９０７〜Ｓ９１７）、前記要求した処理の処理結果を受信する（Ｓ９１８）。【選択図】図９

Description

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

従来、Ｗｅｂサイト間で処理を委譲する場合、機能を呼び出す側は、機能を提供する側のＡＰＩやＲＥＳＴインターフェイス等の機能の呼び出し方を、知っている必要があった。従って、異なるＷＥＢサイトとの連携を実現するためには、機能の呼び出し側は、それぞれの呼び出し規約に従って呼び出し側の処理が必要になった。

また、機能を呼び出す側が機能を利用するためには、機能を提供する側への認証が必要になることが多い。このために、機能を利用する側は、機能を提供する側の認証情報を保持したり、ＳＡＭＬ等の認証基盤を利用したりする必要があった。但し、認証情報を持つと、それら認証情報を正しく安全に管理する必要があり、ＳＡＭＬ等の認証基盤を利用するためには、機能の提供者と利用者間で事前に合意が必要となり、機能の利用者の負担になっていた。なお、ＡＰＩはApplication Program Interface、ＲＥＳＴはREpresentational State Transfer、ＳＡＭＬはSecurity Assertion Markup Languageを示す。

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

特許文献１には、複数のサーバ管理手段と複数のサーバ提供手段を双方の希望に従って動的に制御する技術が記載されている。

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

ＷｅｂＩｎｔｅｎｔｓの仕組みにおいて、特定のａｃｔｉｏｎと処理可能なｔｙｐｅを提供するＷｅｂＩｎｔｅｎｔｓサービスを選択、利用することはできる。しかし、ＷｅｂＩｎｔｅｎｔｓクライアントの提供するデータのｔｙｐｅが処理できないＷｅｂＩｎｔｅｎｔｓサービスを選択、利用することは出来ないという課題がある。なお、特許文献１は、ＷｅｂＩｎｔｅｎｔｓの連携の仕組みについて、考慮したものではない。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、データを管理するクライアントの提供するデータのタイプと、サービスが処理できるデータのタイプが異なる場合においても、ユーザの手を煩わすことなく容易に複数のサービスを連携して所望のサービスを利用することを可能とする仕組みを提供することである。

本発明は、データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末であって、前記中継機能による、前記サービスが提供する機能を呼び出すための機能情報の登録処理を実行する登録手段と、ユーザより前記クライアントで管理される特定のデータに対する機能の呼び出しが指示された場合に、前記特定のデータを、該呼び出しが指示された機能に対応するカテゴリに属する前記登録手段に登録されている第１機能情報の処理可能なタイプに適合させるための第２機能情報を前記登録手段に登録されている機能情報から特定する特定手段と、前記特定された第２機能情報を用いて呼び出した機能により処理された前記特定のデータを、前記第１機能情報を用いて呼び出した機能で処理するための要求を行う要求手段と、前記要求手段で要求した処理の処理結果を受信する受信手段と、を有することを特徴とする。

本発明によれば、データを管理するクライアントの提供するデータのタイプと、サービスが処理できるデータのタイプが異なる場合においても、ユーザの手を煩わすことなく容易に複数のサービスを連携して所望のサービスを利用することを可能とする。

ＷｅｂＩｎｔｅｎｔｓを実現するための全体構成を例示する図。 ＷｅｂＩｎｔｅｎｔｓを利用したサービス提供に関する基本動作のシーケンス図。 ＷｅｂＩｎｔｅｎｔｓの機能登録用のＨＴＭＬ文書を説明する図。 クライアントからＵＡに返信されるＨＴＭＬ文書を説明する図。 本発明の一実施例を示すシステムの構成を例示する図。 サーバ及び情報処理端末のハードウェア構成を例示する図。 サーバ及び情報処理端末のソフトウェア構成を例示する図。 実施例１の登録済みサービステーブルおよびコンテンツ管理テーブルを例示する図。 実施例１のＷｅｂＩｎｔｅｎｔｓを利用したサービス提供に関する動作のシーケンス図。 ＵＡが表示するクライアントの画面を説明する図。 共有ボタンを押下された際の画面を例示する図。 複数のサービスを連携するためのＵＡの処理を例示するフローチャート。 ＵＡが表示するＷｅｂＩｎｔｅｎｔｓ処理終了ページを例示する図。 実施例２のＷｅｂＩｎｔｅｎｔｓを利用したサービス提供に関する動作のシーケンス図。 実施例２のＷｅｂＩｎｔｅｎｔｓサーバの処理を説明する図。 実施例３のＷｅｂＩｎｔｅｎｔｓを利用したサービス提供に関する動作のシーケンス図。 ＵＡが表示するＷｅｂＩｎｔｅｎｔｓ処理終了ページを例示する図。 実施例３の登録済みサービステーブルを例示する図。 実施例３のＷｅｂＩｎｔｅｎｔ実行ログを例示する図。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜本実施形態のネットワーク、周辺機器、及び、ネットワークサービスの構成例＞
図５は、本発明の一実施例を示すサーバシステムの構成の一例を示す図である。本システムは、情報処理端末５３０と、１台以上のクライアント１０１の機能を提供するサーバ５１０、および、１台以上のサービス１０３を提供するサーバ５２０、５２１を有する。情報処理端末５３０はＬＡＮで接続され、ファイアウォール（Ｆｉｒｅｗａｌｌ）５４０越しにインターネット等のＷＡＮを介してサーバ５１０、およびサーバ５２０、５２１と接続される。

なお、本実施例において、先に説明したサービス１０３に対応する２つのサービス（サービス１、サービス２）を、２台のサーバ（サーバ５２０、サーバ５２１）で提供している。しかし、１台のサーバで複数のサービス機能を提供する場合においても、本提案で同様に処理が可能である。

サーバ５１０は、先に説明したクライアント１０１の機能を提供するものであり、サービス１、２への処理要求を作成する。サーバ５２０、５２１は、先に説明したサービス１０３にあたるサービス１、２の機能を提供するＷｅｂアプリケーションを備えており、ＷｅｂＩｎｔｅｎｔｓ技術を利用してサービスや機能を提供する。情報処理端末５３０は、先に説明したＵＡ１０６の機能を提供するＷｅｂブラウザがインストールされているコンピュータである。なお、サーバ５１０、５２０、５２１、情報処理端末５３０は、汎用コンピュータの構成を有する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サービス判定部７５６は、実行中のＷｅｂＩｎｔｅｎｔｓ処理において、Ｉｎｔｅｎｔｓスクリプトの「アクション（ａｃｔｉｏｎ）」および「タイプ（ｔｙｐｅ）」から第二のサービスが必要かどうかを判定する。

スクリプト処理部７５７は、サービス判定部７５６が第二のサービスが必要だと判定した場合に、サービス情報記憶部７５８に記憶されている第一のサービスで処理を行うために必要な、第二のサービスを利用するための処理を行う。サービス情報記憶部７５８は、データを管理し、サービス情報管理部７５５からの要求に応じてデータの格納と取り出しを行う。また、サービス情報記憶部７５８は、後述する図８（Ａ）に示すような登録済みサービステーブル８００を保持する。以上示したような、Ｗｅｂブラウザ７５０は、情報処理端末５３０のＣＰＵ６０１が、ＨＤＤ６０６等からプログラムをＲＡＭ６０２上へ読み出して実行することにより実現されるものである。

図８は、登録済みサービステーブル８００およびコンテンツ管理テーブル８２０の一例を示す図である。
図８（Ａ）は、情報処理端末５３０のＷｅｂブラウザ７５０が自身に登録されたサービスを管理するためにサービス情報記憶部７５８に保持する登録済みサービステーブル８００の一例である。

登録済みサービステーブル（登録済みＷｅｂＩｎｔｅｎｔｓサービステーブル）８００は、情報処理端末５３０のサービス情報記憶部７５８で保持され、サービス情報管理部７５５によって管理される。登録済みサービステーブル８００には、サービスが提供する機能を呼び出すための機能情報（８０１〜８０６）が登録されている。以下、詳細に説明する。

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

８０４はｈｒｅｆであり、サービス１、２の相対ＵＲＬを示す。８０５はｔｉｔｌｅであり、サービス１、２のタイトルを示す。また、８０６はｄｉｓｐｏｓｉｔｉｏｎであり、サービス１、２がどのように表示されるかを示す。つまり、情報処理端末５３０は、Ｗｅｂブラウザ７５０を介して、登録済みサービステーブル８００を参照することで、各サービス１、２へＩｎｔｅｎｔの処理要求を出すことが可能である。

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

以下、図９のシーケンス図を用いて、情報処理端末５３０がサーバ５１０により提供されるＷｅｂサイトにアクセスして、サーバ５２０、５２１により提供されるサービス１、２に、Ｉｎｔｅｎｔの処理要求を仲介する動作について説明する。
図９は、実施例１におけるＷｅｂＩｎｔｅｎｔｓを利用したサービス提供に関する動作の一例を示すシーケンス図である。

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

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

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

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

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

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

以下、図９のシーケンス図の説明に戻る。
ユーザにより共有ボタン１００５（図１０（Ｂ））が押下されたことを検知すると、情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９０５の処理を実行する。Ｓ９０５において、情報処理端末５３０のＷｅｂブラウザ７５０は、登録済みサービステーブル８００を参照し、登録済みのサービスで、共有ボタン１００５に対応する処理が可能か判定し、表示部７５３に一覧表示するサービスを判断する。このＳ９０５の処理は、複数のＷｅｂＩｎｔｅｎｔｓサービスを連携した処理（例えば、サービス２で編集した後にサービス１で共有）などを行うための処理を行うためのものである。ここで、図１２を参照して、Ｓ９０５の処理について詳細に説明する。

図１２は、図９のＳ９０５の処理の一例を示すフローチャートである。この処理は、情報処理端末５３０のＷｅｂブラウザ７５０が実行する処理に対応し、複数の連携したサービス処理を行うための処理である。

Ｓ１２０１において、情報処理端末５３０のＷｅｂブラウザ７５０は、クライアント１０１としてのサーバ５１０のＷｅｂアプリケーション７００が図９のＳ９０２で作成し、Ｓ９０３で応答したページ情報を、解析部７５２で解析する。

Ｓ１２０２において、Ｗｅｂブラウザ７５０は、サービス情報管理部７５５を経由して、サービス情報記憶部７５８から登録済みサービステーブル８００を取得する。

Ｓ１２０３において、Ｗｅｂブラウザ７５０のサービス判定部７５６は、Ｓ１２０２で取得した登録済みのＷｅｂＩｎｔｅｎｔｓサービスの中に、リクエストのＴｙｐeのデータに対しリクエストのａｃｔｉｏｎが可能なサービスが存在するか否かを判定する。詳細には、サービス判定部７５６は、まず、登録済みのＷｅｂＩｎｔｅｎｔｓサービスの中に、リクエストのａｃｔｉｏｎが可能なサービス（第１のサービス）が存在するか否か判定する。そして、第１のサービスが存在する場合、該第１のサービスが、リクエストのｔｙｐｅのデータを処理可能か否かを判定する。以上により、リクエストのＴｙｐeのデータに対しリクエストのａｃｔｉｏｎが可能なサービスが存在するか判定する。

本実施例においては、具体的には、画像ファイルｔｙｐｅ＝ｐｎｇの"ｉｍａｇｅ００１．ｐｎｇ"が選択され、共有ボタン１００５が押下されている場合を説明する。図８の例では、ＳｅｒｖｉｃｅＩＤ８０１＝"１"、"３"、"４"のサービスが、リクエストのａｃｔｉｏｎ＝ｓｈａｒｅを処理できる第１のサービスと判定される。さらに、ｔｙｐｅ８０３の判定により、ｔｙｐｅ８０３＝"ｉｍａｇｅ／＊"であるＳｅｒｖｉｃｅＩＤ８０１＝"４"の"ｃｃｃ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ"のみが、リクエストのＴｙｐe＝"ｉｍａｇｅ／ｐｎｇ"のデータを共有処理可能と判定される。即ち、ＳｅｒｖｉｃｅＩＤ８０１＝"４"の"ｃｃｃ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ"のみが、"ｉｍａｇｅ００１．ｐｎｇ"の共有処理が可能と判定される。この判定結果により、サービス判定部７５６は、リクエストのａｃｔｉｏｎ及びｔｙｐeと一致するサービスが登録済みであると判定し（Ｓ１２０３でＹｅｓと判定し）、後述のＳ１２０８に処理を遷移させることとなる。

なお、ＳｅｒｖｉｃｅＩＤ８０１＝"４"のサービスが登録済みでなかった場合について以下に説明する。この場合、ｔｙｐｅ８０３の判定により、ｔｙｐｅ８０３＝"ｉｍａｇｅ／ｊｐｅｇ"であるＳｅｒｖｉｃｅＩＤ８０１＝"１"と"３"では、リクエストのＴｙｐe＝"ｉｍａｇｅ／ｐｎｇ"のデータの共有処理が不可能と判定される。即ち、ＳｅｒｖｉｃｅＩＤ８０１＝"１"と"３"では、"ｉｍａｇｅ００１．ｐｎｇ"の共有処理を行うことが不可能と判定される。この場合、この判定結果により、サービス判定部７５６は、リクエストのａｃｔｉｏｎ及びｔｙｐeと一致するサービスが登録済みでないと判定し（Ｓ１２０３でＮｏと判定し）、後述のＳ１２０４に処理を遷移させることとなる。

Ｓ１２０３でＮｏの場合、Ｓ１２０４において、サービス判定部７５６は、サービス情報管理部７５５を経由して、サービス情報記憶部７５８から登録済みサービステーブル８００を取得する。なお、登録済みサービステーブル８００からデータ変換可能なサービスのみを取得してもよい。

次に、Ｓ１２０５において、サービス判定部７５６は、リクエストのＴｙｐeのデータを、第１のサービスのｔｙｐｅ８０３のデータに変換可能なサービスが、上記S１２０４で取得した登録済みのＷｅｂＩｎｔｅｎｔｓサービスの中にあるか判定する。具体的には、登録済のサービスの中から、リクエストのＴｙｐe＝"ｉｍａｇｅ／ｐｎｇ"のデータを、第１のサービスの対応するｔｙｐｅ＝"ｉｍａｇｅ／ｊｐｅｇ"のデータへ変換可能な第２のサービスの検索を行い、判定する。即ち、ｐｎｇ形式の画像データをｊｐｅｇ形式の画像データに変換可能なサービスがあるか判定する。

図８の例では、ＳｅｒｖｉｃｅＩＤ８０１＝"２"のサービス（ａｃｔｉｏｎ８０２＝ｅｄｉｔ、ｔｙｐｅ８０３＝ｉｍａｇｅ／＊）が、"ｉｍａｇｅ００１．ｐｎｇ"をｔｙｐｅ＝"ｉｍａｇｅ／ｊｐｅｇ"に変換する処理を行う事が可能と判定される。この判定結果により、サービス判定部７５６は、適切なデータ変換が可能な第２のサービスが登録済みであると判定し（Ｓ１２０５でＹｅｓと判定し）、後述のＳ１２０６に処理を遷移させることとなる。

なお、ＳｅｒｖｉｃｅＩＤ８０１が"２"のサービスが登録済みでなかった場合、について以下に説明する。この場合、"ｉｍａｇｅ００１．ｐｎｇ"をｔｙｐｅ＝"ｉｍａｇｅ／ｊｐｅｇ"に変換する処理を行うことが可能なサービスが登録されていないと判定される。この判定結果により、サービス判定部７５６は、適切なデータ変換が可能なサービスが登録済みでないと判定し（Ｓ１２０５でＮｏと判定し）、後述のＳ１２０８に処理を遷移させることとなる。

Ｓ１２０５がＹｅｓの場合、Ｓ１２０６において、Ｗｅｂブラウザ７５０は、上記検索されたデータ変換サービスである第２のサービスを選択する。上述した例では、ＳｅｒｖｉｃｅＩＤ８０１＝"２"の"ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅ"を、第２のサービスとして選択する。即ち、Ｗｅｂブラウザ７５０は、リクエストのデータタイプ（ｔｙｐｅ）を、リクエストのａｃｔｉｏｎに対応する第１のサービスで処理可能なデータタイプ（ｔｙｐｅ）に適合させるための第２のサービスを特定する。

次に、Ｓ１２０７において、Ｗｅｂブラウザ７５０は、スクリプト処理部７５７において、第２のサービスの処理を行った後に第１のサービスを連携して行うためのスクリプトを生成する。さらに、Ｗｅｂブラウザ７５０の表示部７５３に、第２のサービスと第１のサービスが連携したメニューを表示、処理するためスクリプトを含むＨＴＭＬファイルを生成する。図１１（Ａ）にメニューの表示例を示す。

また、Ｓ１２０３でＹｅｓ又はＳ１２０５でＮｏの場合、Ｓ１２０８において、Ｗｅｂブラウザ７５０は、通常のＷｅｂＩｎｔｅｎｔｓを行うメニューを作成する処理を行う。即ち、リクエストのａｃｔｉｏｎ及びｔｙｐｅが一致する単独のサービスのみが選択肢として表示されるメニューを作成する。

上述のように、本実施例では、共有ボタン１００５が押下されている場合を想定しているので、ａｃｔｉｏｎ８０２＝"ｓｈａｒｅ"であるＳｅｒｖｉｃｅＩＤ８０１＝"１"、"３"、"４"が対象のサービスとなる。しかし、"ｓｈａｒｅ"したいデータであるＷｅｂＩｎｔｅｎｔｓクライアント（サーバ５１０）の保持するコンテンツ"ｉｍａｇｅ００１．ｐｎｇ"、"ｉｍａｇｅ００２．ｐｎｇ"（８２２）は画像ファイルのｔｙｐｅが"ｐｎｇ"フォーマットの画像形式である。ａｃｔｉｏｎ８０２＝"ｓｈａｒｅ"であるＳｅｒｖｉｃｅＩＤ８０１＝"１"と"３"は、ｔｙｐｅ８０３が"ｉｍａｇｅ／ｊｐｅｇ"しか扱えないため、リクエストの"ｓｈａｒｅ"対象のサービスとはならない。ＳｅｒｖｉｃｅＩＤ８０１＝"４"のサービスだけがｔｙｐｅ８０３が"ｉｍａｇｅ／＊"のため、"ｐｎｇ"フォーマットの画像を共有するための対象サービスとなる。従来では、このような場合、ユーザが共有ボタン１００５を押下しても、ＳｅｒｖｉｃｅＩＤ８０１＝"１"や"３"のサービスを利用して、"ｉｍａｇｅ００１．ｐｎｇ"などのｔｙｐｅ８０３が対象外のデータであるｐｎｇ形式の画像ファイルを"ｓｈａｒｅ"することはできない。

そのため、本実施例では、ユーザが通常利用しているＳｅｒｖｉｃｅＩＤ８０１＝"１"のサービスを利用して、画像ファイルｔｙｐｅ８０３＝"ｐｎｇ"の画像を"ｓｈａｒｅ"するために、先ず連携するＷｅｂＩｎｔｅｎｔｓサービスで"Ｅｄｉｔ"を行う。Ｗｅｂブラウザ７５０は、ユーザからの指示によりＳｅｒｖｉｃｅＩＤ８０１＝"１"の"ｓｈａｒｅ"サービスで共有するために、連携する"Ｅｄｉｔ"サービスで画像フォーマットの変換処理を行い、続いて"ｓｈａｒｅ"サービスで共有処理を行う。図１２のＳ１２０７では、このような複数のサービスが連携したサービスを実行するためのスクリプトやメニューが作成される。

なお、図１２に示した例では、リクエストのａｃｔｉｏｎ及びｔｙｐｅが一致するサービスが登録済みの場合（Ｓ１２０３でＹｅｓの場合）には、上述した複数のサービスを連携するメニューは作成せず、通常のメニューを作成する場合（Ｓ１２０８）を示した。しかし、このような場合にも、上述した複数のサービスを連携するメニューを作成してもよい。例えば図８の例の場合、リクエストを単独で処理できるＳｅｒｖｉｃｅＩＤ８０１＝"４"のサービスの選択肢と、"２"と"１"を連携したサービスの選択肢と、"２"と"３"を連携したサービスの選択肢を全て含むメニューを作成するように構成してもよい。

以下、図９のシーケンス図の説明に戻る。
Ｓ９０６において、Ｗｅｂブラウザ７５０の解析部７５２は、Ｓ９０５（図１２のＳ１２０７等）で作成した、複数のサービスが連携したメニューを表示するためスクリプト及びＨＴＭＬを解析し、表示部７５３がメニューの表示を実行する。これにより、Ｗｅｂブラウザ７５０には、複数のサービスを連携させたサービスを含むサービスの一覧を示す図１１（Ａ）のような画面が表示される。なお、この一覧の表示は、図２のＳ２０５で示した通常の「登録されているＷｅｂＩｎｔｅｎｔｓの一覧の表示」とは異なり、ＷｅｂＩｎｔｅｎｔｓ起動用のＥＣＭＡＳｃｒｉｐｔの実行前に行われる。

図１１（Ａ）は、図９のＳ９０６において情報処理端末５３０のＷｅｂブラウザ７５０に表示される画面の一例を示す。
１１００は、共有ボタン１００５が押下されることで、情報処理端末５３０のＷｅｂブラウザ７５０が表示するポップアップ画面の一例である。なお、１１０１は、図９のＳ９０５で表示対象と判定されてサービスの一覧である。この一覧画面では、複数のＷｅｂＩｎｔｅｎｔｓサービスを連携したサービス（例えば「ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅで編集して共有」）の表示を行う。そして、図１１（Ｂ）のように、「ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅで編集して共有」が選択さ、ＯＫボタン１１０３が押下されると、これらのサービスを提供する各サーバで順次処理が行われる。なお、図１１の例では、複数のＷｅｂＩｎｔｅｎｔｓサービスを連携したサービスが「ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅで編集して共有」のみしか表示されていないが、"ｐｎｇ"を"ｊｐｅｇ"に変更可能なサービスが複数登録されている場合には、複数のＷｅｂＩｎｔｅｎｔｓサービスを連携した複数のサービスが一覧表示される。

これにより、リクエストのａｃｔｉｏｎとは一致するがｔｙｐｅが一致しないサービスであっても、他のサービスと連携することでリクエストを処理可能な場合には、このようなｔｙｐｅが対応していないサービスも含めて選択、利用できるようになる。なお、本実施例では、"ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅ"は、サーバ２５１が提供するサービス２に対応するものとする。また、"ＡＡＡ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ"は、サーバ２５０が提供するサービス１に対応するものとする。

以下、図９のシーケンス図の説明に戻る。
Ｓ９０６で表示されたサービスの一覧から、例えば、図１１（ｂ）のように「ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅで編集して共有」がユーザにより選択されＯＫボタン１１０３が押下されたことを検知すると、Ｗｅｂブラウザ７５０はＳ９０７の処理を実行する。

Ｓ９０７において、Ｗｅｂブラウザ７５０のスクリプト処理部７５７は、選択されたサービスに対応するＥＣＭＡＳｃｒｉｐｔを解析し、スクリプトを実行する（ＷｅｂＩｎｔｅｎｔｓサービス実行処理）。さらに、スクリプト処理部７５７は、送信データにＥＣＭＡＳｃｒｉｐｔが作成したＩｎｔｅｎｔオブジェクトの内容を含めて各サービスで処理を連携させるための情報を作成し、管理する。これらの情報（選択されたサービスの情報も含む）は、サービス情報記憶部７５８に記憶される。また、この情報を利用して、図１１（Ｂ）の「同様の形式は同じ処理を行う」チェックボックス１１０２が設定されている場合は、以後、同様の条件が発生した際に同処理を行うように制御する。具体的には、スクリプト処理部７５７は、サーバ５１０から同様のデータフォーマットを受信し、サービスで同様の処理（本例では"Ｅｄｉｔ"）が必要と判断すると、同様のサービスが選択されたものとして、上記一覧を表示せず、Ｓ９０７に処理を進める。上記例では「ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅで編集して共有」が選択されたものとして、上記一覧を表示せず、Ｓ９０７に処理を進める。即ち、Ｗｅｂブラウザ７５０は、チェックボックス１１０２が設定されている場合は、リクエストのＡｃｔｉｏｎ及びｔｙｐｅと一覧１０１１で選択指定され利用されたサービス（第２のサービス（及び第１のサービス））とを対応付けて設定（記憶）しておく。そして、以後、リクエストのＡｃｔｉｏｎ及びｔｙｐｅと上記設定されたＡｃｔｉｏｎ及びｔｙｐｅとが同一の場合には、該Ａｃｔｉｏｎ及びｔｙｐｅと対応付けて設定されたサービスを利用して処理を要求するように制御する。

なお、上述したＳ９０７で実行した処理では、Ｗｅｂブラウザ７５０は、先ず、サービス２（ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃ）を提供するサーバ５２１を利用する１つ目のスクリプト処理を実行する。具体的には、１つ目のスクリプト内の無名関数を実行して、新規のＩｎｔｅｎｔオブジェクトを作成し、これを引数にしてｓｔａｒｔＡｃｔｉｖｅｔｙ（）関数を呼び出すように制御する。続いて、Ｗｅｂブラウザ７５０は、サービス１（ＡＡＡ Ｓｈａｒｅ Ｓｅｒｖｉｃ）を提供するサーバ５２０のＷｅｂアプリケーション７３０に対して２つ目のスクリプト処理を行うための情報を管理、記憶する。

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

Ｓ９０９において、サーバ５１０のコンテンツ管理部７０４は、データベースサービス部７０５のコンテンツ管理テーブル８２０から、Ｓ９０８で受信した画像データの取得要求で指定された画像データを取得する。例えば、画像データの取得要求で指定された画像データのファイル名が"ｉｍａｇｅ００１.ｐｎｇ"であれば、コンテンツ管理テーブル８２０の最初のレコードの画像データを取得する。Ｓ９１０において、サーバ５１０のプレゼンテーション部７０３は、通信部７０１を介して、Ｓ９０９で取得した画像データをＨＴＴＰレスポンスメッセージとして、情報処理端末５３０に送信する。

情報処理端末５３０のＷｅｂブラウザ７５０は、サーバ５１０から応答された上記画像データを受信すると、Ｓ９１１に処理を移行する。Ｓ９１１〜Ｓ９１３では、"ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅ"（サービス２）を提供するサーバ５２１を利用している。Ｓ９０９で取得したｐｎｇ形式の画像データであるｉｍａｇｅ００１.ｐｎｇを、"ＡＡＡ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ"（サービス１）で利用可能なデータｔｙｐｅであるｊｐｅｇ形式のｉｍａｇｅ００１.ｊｐｅｇに"Ｅｄｉｔ"（変換）する。以下、詳細に説明する。

Ｓ９１１において、情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９０６で表示された一覧で選択されたサービス内の１つ目のサービス（第２のサービス、ここではサービス２）を提供するサーバ５２１へ要求を送信する。本例では、サーバ５２１のＷｅｂアプリケーション７３０に対して要求する。この処理で、情報処理端末５３０のＷｅｂブラウザ７５０は、送信データに、ＷｅｂＩｎｔｅｎｔオブジェクトの内容を含める。

サーバ５２１のＷｅｂアプリケーション７３０は、Ｓ９１１の要求を受信すると、Ｓ９１２を実行する。Ｓ９１２において、サーバ５２１のＷｅｂアプリケーション７３０のＩｎｔｅｎｔ処理部７３２は、Ｓ９１１の要求からＩｎｔｅｎｔオブジェクトを取り出して解析する。さらに、Ｉｎｔｅｎｔ処理部７３２は、解析したＩｎｔｅｎｔの処理を開始する。本実施例では、サーバ５２１のＷｅｂアプリケーション７３０は、情報処理端末５３０のＷｅｂブラウザ７５０を介してユーザと相互作用しながら、Ｉｎｔｅｎｔオブジェクトに含まれる画像データを編集するサービスを提供する。

例えば、サーバ５２１のＷｅｂアプリケーション７３０は、画像データのファイル名の入力と保存する操作を受け付けるためのＨＴＭＬを作成し、情報処理端末５３０に送信する。情報処理端末５３０のＷｅｂブラウザ７５０は、ＨＴＭＬ文書を受信し、ＵＩを表示する。そして、情報処理端末５３０のＷｅｂブラウザ７５０は、ユーザ指示に応じた画像編集処理を行い、処理した結果のデータをサーバ５２１のＷｅｂアプリケーション７３０に送信し、該データは、サーバ５２１で保持される。本実施例では、サーバ５２１の「Ｅｄｉｔ」機能で画像編集を行って、ＰＮＧ形式のｉｍａｇｅ００１.ｐｎｇから、ＪＰＥＧ形式のｉｍａｇｅ００１.ｊｐｅｇにデータ変換し、データベースサービス部７３５のコンテンツ管理テーブル８２０で保持管理する。

Ｓ９１３において、サーバ５２１のＷｅｂアプリケーション７３０は、Ｉｎｔｅｎｔの処理が終了すると、処理結果をＷｅｂＩｎｔｅｎｔｓクライアントに伝えるＥＣＭＡＳｃｒｉｐｔを含む応答を返す。本例では、Ｅｄｉｔ処理後の画像データとして"ｉｍａｇｅ００１.ｊｐｅｇ"を含むデータを、情報処理端末５３０のＷｅｂブラウザ７５０に返信する。この処理では、サーバ５２１のコンテンツ処理部７３４が、データベースサービス部７３５のコンテンツ管理テーブル８２０で保持管理しているユーザに指定された画像ｔｙｐｅとファイル名で画像データを返信する。

続いて、Ｓ９１４において、情報処理端末５３０のスクリプト処理部７５７は、２つ目のサービス（第１のサービス、ここではサービス１）を提供するサーバ５２０の呼び出し処理を行う。２つ目のサービスは「Ｓｈａｒｅ」機能である。この処理は、前述のＳ９１３で取得した"ｉｍａｇｅ００１.ｊｐｅｇ"を２つ目のサービスの呼び出しパラメータとして利用する。

Ｓ９１５において、情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９０６で表示し、ユーザに選択されたサービス内の２つ目のサービスを提供するサーバ５２０へ要求を送信する。これにより、サーバ５２１でのＳ９１１〜Ｓ９１３における１つ目のスクリプト処理に続き、サーバ５２０のＷｅｂアプリケーション７３０に対して処理要求を行う。

サーバ５２０のＷｅｂアプリケーション７３０は、Ｓ９１５の要求を受信すると、Ｓ９１６の処理を実行する。Ｓ９１６において、サーバ５２０のＷｅｂアプリケーション７３０のＩｎｔｅｎｔ処理部７３２は、Ｓ９１５で受信した要求からＩｎｔｅｎｔオブジェクトを取り出して解析する。続けて、解析したＩｎｔｅｎｔの処理を開始する。本実施例では、サーバ５２０のＷｅｂアプリケーション７３０は、情報処理端末５３０のＷｅｂブラウザ７５０を介してユーザと相互作用を行う。さらに、Ｉｎｔｅｎｔオブジェクトに含まれる画像データを共有する「ｓｈａｒｅ」サービスを提供する。

例えば、サーバ５２０のＷｅｂアプリケーション７３０は、画像データのファイル名の入力と保存する操作を受け付けるためのＨＴＭＬ文書を作成し、情報処理端末５３０に送信する。情報処理端末５３０のＷｅｂブラウザ７５０は、ＨＴＭＬ文書を受信し、ＵＩを表示する。そして、情報処理端末５３０のＷｅｂブラウザ７５０は、ユーザによる"Ｓｈａｒｅ"操作を検知すると、サーバ５２０のＷｅｂアプリケーション７３０に、画像データの共有要求を送信する。サーバ５２０のＷｅｂアプリケーション７３０は、画像データの共有要求を受信すると、コンテンツ処理部７３４がデータベースサービス部７３５のコンテンツ管理テーブル８２０に、ユーザに指定されたファイル名で画像データを登録する。

Ｓ９１７において、サーバ５２０のＷｅｂアプリケーション７３０は、Ｉｎｔｅｎｔの処理が終了すると、処理結果をクライアント（サーバ５１０）に伝えるＥＣＭＡＳｃｒｉｐｔを含む応答を、情報処理端末５３０のＷｅｂブラウザ７５０に返す。

情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９１７の応答を受信すると、Ｓ９１８の処理を実行する。Ｓ９１８において、情報処理端末５３０のＷｅｂブラウザ７５０は、応答中に含まれるＥＣＭＡＳｃｒｉｐｔを実行し、上述した１つ目のスクリプト内のｓｔａｒｔＡｃｔｉｖｅｔｙ（）関数の引数で指定されたコールバック関数を呼び出す。例えば、ＥＣＭＡＳｃｒｉｐｔ図１０（Ａ）であれば、コールバック関数ｏｎＳｕｃｃｅｓｓ（）を実行する。

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

サーバ５１０のＷｅｂアプリケーション７００は、Ｓ９１９のＷｅｂＩｎｔｅｎｔ処理結果を受信すると、Ｓ９２０の処理を実行する。Ｓ９２０において、サーバ５１０のＷｅｂアプリケーション７００のプレゼンテーション部７０３は、Ｉｎｔｅｎｔの処理が終了したことを通知するためのページであるＷｅｂＩｎｔｅｎｔｓ処理の終了ページをＨＴＭＬ文書で作成する。

Ｓ９２１において、サーバ５１０のＷｅｂアプリケーション７００のプレゼンテーション部７０３は、通信部７０１を介して、Ｓ９２０で作成したＷｅｂＩｎｔｅｎｔｓ処理の終了ページを情報処理端末５３０に送信する。

情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９２１のＷｅｂＩｎｔｅｎｔｓ処理の終了ページを受信すると、Ｓ９２２の処理を実行する。Ｓ９２２において、情報処理端末５３０のＷｅｂブラウザ７５０の表示部７５３は、Ｓ９２１で受信したＷｅｂＩｎｔｅｎｔｓ処理の終了ページを表示する。

図１３は、ＷｅｂＩｎｔｅｎｔｓ処理の終了ページの一例を示す図である。
図１３において、１３００はＷｅｂＩｎｔｅｎｔｓ処理の終了ページで、各サービスの処理結果を表示する。この処理結果は、共有指示された画像データについて、第２のサービス"ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｅｒ"で"ｐｎｇ"から"ｊｐｅｇ"への「画像編集」（変換）を完了し、第１のサービス"ＡＡＡ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ"で画像共有を完了したことを示す。即ち、Ｗｅｂブラウザ７５０は、要求した処理に成功した場合、共有等を指示したデータを第２のサービスにより処理完了した旨、及び、第２のサービスで処理された前記データを第１のサービスにより処理完了した旨を表示する。このように、Ｗｅｂブラウザ７５０は、要求した処理の処理結果を、前記機能情報を用いて呼び出した機能ごとに表示する（例えば、図１３、後述する図１７（Ａ））。

本実施例では、情報処理端末５３０のＷｅｂブラウザ７５０がクライアントへ複数のサービスを提供する仕組みについて説明した。以上の処理により、ユーザは、情報処理端末５３０のＷｅｂブラウザ７５０を介して、そのデータｔｙｐｅに対応していないサービスを容易に利用することが可能となる。

本実施例において、各サーバや装置の構成、ソフトモジュールの構成、また、画像データを変換することにより、リクエストとｔｙｐｅ８０３の異なるサービスを利用する処理フローを示したが、これらは一例であり、これに限るものではない。

例えば、データ変換を行うｔｙｐｅ８０３として、ｊｐｅｇやｐｎｇ等の画像データのフォーマットの変換の他に、次のようなものでもよい。例えば、ＲＦＣ２０４５、ＲＦＣ２０４６，ＲＦＣ２０４７，ＲＦＣ２０４８，ＲＦＣ２０４９などで規定されているＭＩＭＥタイプで規定されているフォーマットの変換を行う場合に適用できる。例えば、アプリケーションデータ、動画データや音声データ、音楽データ、アドレス帳データなど様々なデータに適用できる。これらのデータについても、サービスの連携により、複数のサービス（３つ以上のサービスでもよい）を適切に利用することで、例えばリクエストとｔｙｐｅが異なっていても、ユーザが利用したいａｃｔｉｏｎに応じたサービスを利用できるようになる。

本実施例で、サーバ５１０を、画像とソーシャルボタンを提供するＷｅｂサイトを実現するサーバとして説明した。また、サーバ５２０、５２１を、画像データを編集、保存、共有する機能を提供するＷｅｂサイトを実現するサーバとして説明した。しかし、サーバ５１０を画像形成装置、サーバ５２０、５２１をプリントサーバなどのＭＰＳ（Ｍａｎａｇｅｄ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ）に対して適用することも可能である。

以上の処理により、第２のサービスと第１のサービスを連携し、第２のサービスが第１のサービスの対応するデータに変換することにより、第１のサービスが対応していないデータについてもＷｅｂＩｎｔｅｎｔｓで処理することが可能となる。よって、クライアント１０１の保持するデータｔｙｐｅと、サービスが処理できるデータｔｙｐｅが異なる場合においても、ユーザの手を煩わすことなく容易にそのサービスを利用することが可能となる。

上記実施例１では、ＵＡ１０６として機能するＷｅｂブラウザ７５０が第２のサービスと第１のサービスを連携して複数のサービスへ処理を依頼する構成を説明した。実施例２では、ＵＡ１０６としてＷｅｂブラウザ７５０が第２のサービスに対して、第１のサービスの処理方法を渡すことによって、複数のサービスが連携し処理する構成について説明する。なお、実施例１と同等の構成や処理については、実施例１で説明したものと同じであるため説明は省略する。

以下、図１４のシーケンス図を用いて、情報処理端末５３０がサーバ５１０により提供されるＷｅｂサイトにアクセスして、サーバ５２０、５２１により提供されるサービス１、２に、Ｉｎｔｅｎｔの処理要求を仲介する動作について説明する。
図１４は、実施例２におけるＷｅｂＩｎｔｅｎｔｓを利用したサービス提供に関する動作の一例を示すシーケンス図である。

Ｓ９１１において、情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９０６で表示された一覧で選択されたサービス内の１つ目のサービス（サービス２）を提供するサーバ５２１へ要求を送信する。本例では、サーバ５２１のＷｅｂアプリケーション７３０に対して要求する。この処理で、情報処理端末５３０のＷｅｂブラウザ７５０は、送信データに、ＷｅｂＩｎｔｅｎｔオブジェクトの内容を含める。また、この際、送信データに、後述する図１５（Ｂ）の１５５２のような、連携する２つ目のサービスのＩｎｔｅｎｔｓ処理内容を特定する情報を含める。また、２つ目のサービスを利用するために入力情報が必要な場合には、必要な入力情報を、上記送信データに含めるようにしてもよい。例えば、認証情報が必要な場合には認証情報を上記送信データに含める。また、画像データを保存するファイル名が必要な場合にはファイル名を上記送信データに含めるものとする。

サーバ５２１のＷｅｂアプリケーション７３０は、Ｓ９１１の要求を受信すると、Ｓ９１２を実行する。Ｓ９１２において、サーバ５２１のＷｅｂアプリケーション７３０のＩｎｔｅｎｔ処理部７３２は、Ｓ９１１の要求からＩｎｔｅｎｔオブジェクトを取り出して解析する。さらに、Ｉｎｔｅｎｔ処理部７３２は、解析したＩｎｔｅｎｔの処理を開始する。本実施例では、サーバ５２１のＷｅｂアプリケーション７３０は、「Ｅｄｉｔ」機能で画像編集を行うことで、ＰＮＧ形式の"ｉｍａｇｅ００１.ｐｎｇ"からＪＰＥＧ形式の"ｉｍａｇｅ００１.ｊｐｅｇ"への変換を行う。

続いて、Ｓ１４０１で、サーバ５２１のＩｎｔｅｎｔ処理部７３２は、Ｉｎｔｅｎｔの処理が終了すると、処理結果を次のサーバ５２０で処理するように、ＥＣＭＡＳｃｒｉｐｔを含む要求リクエストを作成する。本実施例では、Ｅｄｉｔ処理後の画像データとして"ｉｍａｇｅ００１.ｊｐｅｇ"を含むＷｅｂＩｎｔｅｎｔｓ要求が含まれる。

続いて、Ｓ１４０２において、サーバ５２１のＩｎｔｅｎｔ処理部７３２は、２つ目のサーバ５２０に対してＷｅｂＩｎｔｅｎｔｓの送信処理を行う。このステップでは、Ｓ９１２の処理ステップにより取得したｉｍａｇｅ００１.ｊｐｅｇを２つ目のサーバ５２０の呼び出しパラメータとして処理する。

Ｓ１４０３で、サーバ５２０のＷｅｂアプリケーション７３０のＩｎｔｅｎｔ処理部７３２は、上記Ｓ１４０２の処理で受信した要求からＩｎｔｅｎｔオブジェクトを取り出して解析を行う。サーバ５２０のＩｎｔｅｎｔ処理部７３２は、解析したＩｎｔｅｎｔの処理を実行する。本実施例ではサーバ５２０のＷｅｂアプリケーション７３０は、Ｉｎｔｅｎｔオブジェクトに含まれる画像データを共有する「ｓｈａｒｅ」サービスを提供する。

具体的には、サーバ５２０のＷｅｂアプリケーション７３０は、Ｓ１４０２で送信された"ｉｍａｇｅ００１.ｊｐｅｇ"の画像データの保存要求を受信する。すると、コンテンツ処理部７３４がデータベースサービス部７３５のコンテンツ管理テーブル８２０に、ユーザに指定されたファイル名で画像データを登録する。

Ｓ１４０４において、サーバ５２０のＷｅｂアプリケーション７３０は、上記Ｓ１４０３のＩｎｔｅｎｔの処理が終了すると、処理結果をサーバ５２１のＩｎｔｅｎｔ処理部７３２に返信する。

Ｓ９１３において、サーバ５２１のＷｅｂアプリケーション７３０のＩｎｔｅｎｔ処理部７３２は、上記Ｓ１４０４で返信されたＩｎｔｅｎｔの処理を解析し、上記Ｓ９１１の処理に対応する返信処理を行う。この処理は、クライアント（サーバ５１０）に伝えるＥＣＭＡＳｃｒｉｐｔを含む応答を返す。本例では、Ｓｈａｒｅ処理後のＨＴＭＬを含むデータが返信される。

図１５（Ａ）は、サーバ５２１のＩｎｔｅｎｔ処理部７３２が行う、図１４のＳ９１２、Ｓ１４０１、Ｓ１４０２，Ｓ１４０３、Ｓ１４０４、Ｓ９１３での処理を説明するためのフローチャートである。以下、図１５（Ａ）を用いて、図１４のＳ９１２、Ｓ１４０１、Ｓ１４０２，Ｓ１４０３、Ｓ１４０４、Ｓ９１３での処理をより詳細に説明する。

Ｓ１５０１において、サーバ５２１のＷｅｂアプリケーション７３０のプレゼンテーション部７０３は、通信部７０１を介してページ要求を受信したか監視する。そして、ページ要求（Ｓ９１１）を受信したと判定した場合（Ｓ１５０１でＹｅｓの場合）は、Ｓ１５０２に処理を遷移させる。

Ｓ１５０２において、サーバ５２１のＩｎｔｅｎｔ処理部７３２は、Ｉｎｔｅｎｔ処理要求の解析を行う。Ｉｎｔｅｎｔ処理部７３２は、情報処理端末５３０のＷｅｂブラウザ７５０が送信したＥＣＭＡＳｃｒｉｐｔ１５５０（例えば図１５（Ｂ））から、ａｃｔｉｏｎやｔｙｐｅなどのサービスの実行パラメータを取得する。また、サーバ５２１のＩｎｔｅｎｔ処理部７３２は、Ｉｎｔｅｎｔ処理要求に、図１５（Ｂ）の１５５１に示すようなｅｘｔｒａデータ含まれる場合、該ｅｘｔｒａデータから連携するサービスに対して実行処理を行うためのパラメータを取得する。

Ｓ１５０３において、サーバ５２１のＩｎｔｅｎｔ処理部７３２は、Ｓ１５０２で取得したサーバの実行パラメータから、Ｉｎｔｅｎｔ処理要求を実行する。この処理は、図１４に示したＳ９１２の処理ステップに対応する。本実施例では、サーバ５２１で、ａｃｔｉｏｎ８０２が"ｅｄｉｔ"、ｔｙｐｅ８０３が"ｉｍａｇｅ／＊"の"ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅ"の処理を行う。具体的には、"ｉｍａｇｅ００１．ｐｎｇ"データから"ｉｍａｇｅ００１．ｊｐｅｇ"データへのｅｄｉｔ処理が行われる。

Ｓ１５０４において、サーバ５２１のＩｎｔｅｎｔ処理部７３２は、連携する転送Ｉｎｔｅｎｔ処理要求が含まれるか否かを判定する。図１５（Ｂ）のｅｘｔｒａデータ１５５１のような連携するサービスに対して実行処理を行うためのパラメータが含まれる場合には、連携する転送Ｉｎｔｅｎｔ処理要求が含まれると判定し、Ｓ１５０５に処理を遷移させる。一方、ｅｘｔｒａデータのような連携するサービスに対して実行処理を行うためのパラメータが含まれない場合には、連携する転送Ｉｎｔｅｎｔ処理要求が含まれないと判定し、Ｓ１５０７に処理を遷移させる。

Ｓ１５０５において、サーバ５２１のＩｎｔｅｎｔ処理部７３２は、上記Ｓ１５０２で取得したパラメータを用いて、連携するサービス（ここではサーバ５２０が提供する）に対する転送Ｉｎｔｅｎｔｓ処理要求を実行する。本実施例では、これにより、サーバ５２０でａｃｔｉｏｎ８０２が"ｓｈａｒｅ"、ｔｙｐｅ８０３が"ｉｍａｇｅ／ｊｐｅｇ"の"ＡＡＡ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ"を実行する。この処理は、図１４に示したＳ１４０１の処理ステップに対応する。

Ｓ１５０６において、サーバ５２１のＩｎｔｅｎｔ処理部７３２は、Ｓ１５０５での要求に従い、サーバ５２０で実行されたサービスの処理結果を受信し、処理する。この処理は、前述したＳ１４０４の処理ステップに対応する。

Ｓ１５０７において、サーバ５２１のＩｎｔｅｎｔ処理部７３２は、サーバ５２０から受信した処理結果（又はＳ１５０３の処理結果）を、要求元である情報処理端末５３０のＷｅｂブラウザ７５０に返信する。この処理は、図１４に示したＳ９１３の処理ステップに対応する。

情報処理端末５３０のＷｅｂブラウザ７５０が作成するＥＣＭＡＳｃｒｉｐｔの一例を、図１５（Ｂ）を用いて説明する。
図１５（Ｂ）は、情報処理端末５３０のＷｅｂブラウザ７５０が作成するＥＣＭＡＳｃｒｉｐｔの一例を示す図である。このスクリプトは、図１４に示したＳ９１１で作成される。なお、図１５（Ｂ）に示すスクリプトはあくまで一例であり、情報処理端末５３０であるＷｅｂブラウザ７５０が解釈できれば、他の形式、表記でもよい。

ＥＣＭＡＳｃｒｉｐｔ１５５０は、図４のＥＣＭＡＳｃｒｉｐｔとほぼ同じであるため、異なる点のみを説明する。
ｅｘｔｒａデータ１５５１には、サーバ５２１が実行する、連携する２つ目のＩｎｔｅｎｔｓ処理内容を特定する情報１５５２を記載する。具体的には、サーバ５２１のＩｎｔｅｎｔ処理部７３２が、サーバ５２０のＩｎｔｅｎｔ処理部７３２に対して実行処理を行ためのパラメータを指定する。このパラメータには、サービスを特定し、ＷｅｂＩｎｔｅｎｔｓを実行するための情報を記載する。例えば、Ｆｏｒｗａｒｄａｃｔｉｏｎ、ＮｅｘｔＦｏｒｗａｒｄｔｙｐｅ、ＦｏｒｗａｒｄＴｉｔｌｅ、ＦｏｒｗａｒｄＨｒｅｆ、ＦｏｒｗａｒｄＤｉｓｐｏｓｉｔｉｏｎ、ＦｏｒｗａｒｄＢａｓｅＵＲＩなどがパラメータに指定される。

ＷｅｂＩｎｔｅｎｔサービスの連携を行うための、ＥＣＭＡＳｃｒｉｐｔ１５５０の作成処理は、図１４のＳ９０４で表示された画面において、ユーザにより「共有する」ボタン１００５が押下された時に実行される。

先ず、情報処理端末５３０のＷｅｂブラウザ７５０は、図１４のＳ９０５において、登録済みサービステーブル８００を取得する。さらに、スクリプト処理部７５７は、サービス情報記憶部７５８に記憶されている第１のサービスで処理を行うために必要な第２のサービスを選択し、第２のサービスを利用するために必要なａｃｔｉｏｎ８０２、ｔｙｐｅ８０３を決定する。ＥＣＭＡＳｃｒｉｐｔ１５５０の例では、最初に情報処理端末５３０のＷｅｂブラウザ７５０は、サーバ５２１に対してａｃｔｉｏｎ８０２が"ｅｄｉｔ"、ｔｙｐｅ８０３が"ｉｍａｇｅ／＊"の処理を行う。続いて、サーバ５２１は、サーバ５２０に対してａｃｔｉｏｎ８０２が"ｓｈａｒｅ"であり、ｔｙｐｅ８０３が"ｉｍａｇｅ／ｊｐｅｇ"である処理を行う。

さらに、複数のＷｅｂＩｎｔｅｎｔｓ連携処理を行う場合は、複数の転送サービスおよび、ＷｅｂＩｎｔｅｎｔｓ処理を特定する情報を、上記ｅｘｔｒａデータ１５５１内のパラメータとして記載することも可能である。例えば、"ForwardAction":["http://webintents.org/edit","http:// webintents.org/share",]、"ForwardType":["image/*","image/jpeg"]、"ForwardBaseURI":["http://bbb111.com"," http://ccc111.com "]などのＷｅｂＩｎｔｅｎｔｓ処理を行うためのパラメータを記載することも可能である。

この例では、第１のサービスを提供する１つ目のサーバのＩｎｔｅｎｔ処理部７３２は、ＷｅｂＩｎｔｅｎｔｓ処理を行った後に、ｅｘｔｒａデータ１５５１で指示された連携するＷｅｂＩｎｔｅｎｔｓ処理を行う。その後、連携するＷｅｂＩｎｔｅｎｔｓ処理として、２つ目のサービスである"http://bbb111.com"に対して、"edit"処理を行うためのパラメータ、および、ｅｘｔｒａデータ１５５１として"http://ccc111.com"に対して"share"処理を行うためのパラメータを生成して送信する。

２つ目のサービスである"http://bbb111.com"を提供する２つ目のサーバのＩｎｔｅｎｔ処理部７３２は、ＷｅｂＩｎｔｅｎｔｓ処理の"edit"処理を行った後に、ｅｘｔｒａデータ１５５１で指示された連携するＷｅｂＩｎｔｅｎｔｓ処理を行う。具体的には、３つ目のサービスである"http://ccc111.com"に対して、"share"処理を行うためのパラメータを生成して、送信する。そして、３つ目のサービスである"http://ccc111.com"を提供する３つ目のサーバでは、"share"のＷｅｂＩｎｔｅｎｓ処理が実行される。

本実施例では、情報処理端末５３０のＷｅｂブラウザ７５０が、第２のサービスである"edit"の処理を行う第２のサーバと、第１のサービスである"share"の処理を行う第１のサーバへのパラメータを作成し、第２のサーバに送信する。そして、各サーバが連携してこれを実行することにより、連携してＩｎｔｅｎｔｓ処理を行うことができるようになる。このため、連携する複数のＷｅｂＩｎｔｅｎｔｓサービスが、各サービス間で情報処理端末５３０のＷｅｂブラウザ７５０を介することなく連携できるようになる。また、本実施例では、主に２つのサービス間での連携例方法を示したが、同様の処理により、３つ以上のサービス間で連携することもできるようになる。

実施例３では、複数の連携するサービスでＷｅｂＩｎｔｅｎｔｓ処理を行う場合に、サービスでの処理が失敗してユーザが選択した処理が完了しない場合の処理方法、および、連携するサービスの選択方法について説明する。なお、上述した実施例１、２と同等の構成や処理については、実施例１、２で説明したものと同じであるため説明は省略する。

以下、図１６のシーケンス図を用いて、情報処理端末５３０がサーバ５２１のＩｎｔｅｎｔ処理を実行し、処理に失敗した場合の動作について説明する。
図１６は、実施例３におけるＷｅｂＩｎｔｅｎｔｓを利用したサービス提供に関する動作の一例を示すシーケンス図である。

情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９１１からＳ９１３において、ＷｅｂＩｎｔｅｎｔｓ処理を行う。Ｓ９１２において、サーバ５２１のＷｅｂアプリケーション７３０のＩｎｔｅｎｔ処理部７３２は、Ｓ９１１で受信した処理要求からＩｎｔｅｎｔオブジェクトを取り出して解析する。Ｉｎｔｅｎｔ処理部７３２は、解析したＩｎｔｅｎｔの処理を行う。本実施例では、サーバ５２１のＷｅｂアプリケーション７３０は、「Ｅｄｉｔ」機能で画像編集を行うことで、ＰＮＧ形式の"ｉｍａｇｅ００１.ｐｎｇ"から、ＪＰＥＧ形式の"ｉｍａｇｅ００１.ｊｐｅｇ"の変換を行う。

Ｓ１６０１においた、サーバ５２０のＷｅｂアプリケーション７３０は、Ｓ９１２の処理でＩｎｔｅｎｔの処理結果を判定する。例えば、Ｉｎｔｅｎｔ処理部７３２が画像変換に失敗した場合や、メモリ不足など、処理結果が失敗した場合など、処理の失敗の検出を行う。Ｓ１６０１において、処理の失敗が検出されると、Ｓ９１３において、サーバ５２１のＷｅｂアプリケーション７３０のＩｎｔｅｎｔ処理部７３２は、Ｓ９１２におけるＩｎｔｅｎｔの処理結果を解析し、Ｓ９１１の処理に対応する返信処理を行う。この処理は、クライアント（サーバ５１０）に伝えるＥＣＭＡＳｃｒｉｐｔを含む応答を、情報処理端末１０６のＷｅｂブラウザ７５０に返す。本例では、"Ｅｄｉｔ"処理のエラー結果を含むＨＴＭＬデータが返信（応答）される。

そして、Ｓ９１８において、情報処理端末５３０のＷｅｂブラウザ７５０は、上記サーバ５２１からの応答内に含まれるＥＣＭＡＳｃｒｉｐｔを実行し、１つ目のサービスを呼び出す１つ目のスクリプト内のｓｔａｒｔＡｃｔｉｖｅｔｙ（）関数の引数で指定されたコールバック関数を呼び出す。本実施例では、Ｓ９１３で、サーバ５２１から"Ｅｄｉｔ"処理のエラー結果を含むスクリプトが返信される。このため、例えば、図１０（Ａ）に示したＥＣＭＡＳｃｒｉｐｔであれば、コールバック関数"ｏｎＥｒｒｏｒ（）"を実行する。

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

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

そして、Ｓ９２２において、情報処理端末５３０のＷｅｂブラウザ７５０は、Ｓ９２１の処理ステップで受信したＷｅｂＩｎｔｅｎｔｓ処理の処理失敗ページを表示する。

図１７（Ａ）は、処理失敗ページの一例を示す図である。
１７００は各サーバの処理結果を表示する。処理結果表示部１７０１では、共有指示された画像データについて、第２のサービス"ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｅｒ"で"ｐｎｇ"から"ｊｐｅｇ"への「画像編集」（変換）に失敗したことを示している。さらに、１７０１では、この変換失敗のために、第１のサービス"ＡＡＡ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ"で画像共有が完了できなかったことを示している。即ち、Ｗｅｂブラウザ７５０は、第２のサービスで処理に失敗した場合、共有等を指示したデータを第２のサービスによる処理で失敗した旨、及び、該失敗のため前記データを第１のサービスにより処理完了できなかった旨を表示する。

図１７（Ａ）で示した処理失敗ページで、「ＯＫ」ボタン１７０２が押下されると、図１６のＳ９０４で共有ボタンが押下され、サービスを選択する画面に遷移する。また、図１７（Ａ）で示した処理失敗ページで、「キャンセル」ボタン１７０３が押下されると、処理を中止して以降の処理を行わない。また、この情報を利用して、図１７（Ａ）の「同様の形式は同じ処理を行う」１７０４のチェックボックスが設定されている場合は、以後、同様の条件が発生した際に同じ処理を行う。

図１７（Ａ）で示した処理失敗ページで、「ＯＫ」ボタン１７０２が押下された場合の、サーバを選択する画面例を図１７（Ｂ）に示す。
１７０５は、「ＯＫ」ボタン１７０２が押下されることで、情報処理端末５３０のＷｅｂブラウザ７５０が表示するポップアップ画面例である。１７０６は、図１６のＳ９０５の処理ステップで表示対象となったサーバの一覧である。即ち、Ｗｅｂブラウザ７５０は、要求した処理でエラーが発生した場合、再度、サービスの指定をユーザから受け付ける。

図１７（Ｂ）の例は、一覧に「ａａａ Ｅｄｉｔ Ｓｅｒｖｉｃｅ」１７０８、「ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅ」１７０９をＷｅｂブラウザ７５０で表示した画面例である。選択画面（一覧）１７０６では、"ａａａ Ｅｄｉｔ Ｓｅｒｖｉｃｅで編集して共有"１７０８が優先的に表示され、"ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅで編集して共有"１７０９が第２候補としてメニューに表示されている。なお、優先順位の判定は、スクリプト処理部７５７が、情報処理端末５３０のＷｅｂブラウザ７５０の登録済みサービステーブル８００（図１８）を参照して判定を行う。

図１８は、実施例３における登録済みサービステーブル８００の一例を示す図である。
ＲｅｇｉｓｔｒａｔｉｏｎＤａｔｅ１８０１は、ＷｅｂＩｎｔｅｎｔｓサービスが登録された日時を示す。Ｃｏｕｎｔ１８０２は、ＷｅｂＩｎｔｅｎｔｓサービスの過去の利用回数を示す。

上述した優先順位の判定方法の一例としては、ＷｅｂＩｎｔｅｎｔｓサービスが登録された日時ＲｅｇｉｓｔｒａｔｉｏｎＤａｔｅ１８０１の新しいサービス、または、古いサービスを優先して表示する。また、ＷｅｂＩｎｔｅｎｔｓサービスの利用回数Ｃｏｕｎｔ１８０２に応じて優先順位の判定を行う方法でもよい。なお、サーブスの利用回数の他に、サービスの利用頻度を登録済みサービステーブル８００に登録してもよい。この場合、また、サービスの利用頻度に応じて優先順位の判定を行う方法でもよい。

さらに、第２候補としてメニューに表示している"ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅで編集して共有"１７０９には、ＷｅｂＩｎｔｅｎｔの実行結果Ｓｔａｔｕｓ１９１０（図１９）から、過去にエラーが発生した処理を判定し、エラー表示（！）１７０９を表示する。即ち、Ｗｅｂブラウザ７５０は、サービスの指定をユーザから受け付ける場合に、図１９に示すログにエラーの発生が記憶されているサービスについては、過去にエラーが発生したことを示す情報を表示する。又は、エラーが発生したサービスをメニューリスト（一覧１７０６）に表示しないことも可能である。また、図１７（Ｂ）の「同様の形式は同じ処理を行う」１７０７のチェックボックスが設定されている場合は、これらの処理を行った情報を利用して、以後、同様の条件が発生した際に同処理を行う。

図１９は、ＵＡ１０６のＷｅｂＩｎｔｅｎｔ実行ログの一例を示す図である。
ＬｏｇＩＤ１９０１は、ＵＡ１０６のＷｅｂＩｎｔｅｎｔ処理を一意に識別するためのＩＤである。ａｃｔｉｏｎ１９０２は、サーバ５２０の機能、サービスを示す情報である。ｔｙｐｅ１９０３は、ａｃｔｉｏｎ８０２に対してどのようなデータ形式を扱えるかを示している。ｈｒｅｆ１９０４は、サーバ５２０、５２１が提供するサービスの相対ＵＲＬを示している。ｔｉｔｌｅ１９０５は、サーバ５２０、５２１が提供するサービスのタイトルを示している。また、ｄｉｓｐｏｓｉｔｉｏｎ１９０６は、サーバ５２０、５２１が提供するサービスがどのように表示されるかを示す。ＲｅｇｉｓｔｒａｔｉｏｎＤａｔｅ１９０７は、ＷｅｂＩｎｔｅｎｔｓサーバが登録された日時を示す。Ｔｒａｎｓａｃｔｉｏｎ１９０８は、ＵＡが同一のユーザのリクエストで処理した一連のサーバ処理を示す。Ｉｎｐｕｔ Ｄａｔａ ｔｙｐｅ１９０９は、処理の入力パラメータとして指定されたデータのｔｙｐｅを示す。Ｓｔａｔｕｓ１９１０は、ＷｅｂＩｎｔｅｎｔの実行結果を示す。なお、図１９に示したＵＡ１０６のＷｅｂＩｎｔｅｎｔ実行ログは、サービス情報記憶部７５８又は情報処理端末５３０のＨＤＤ６０６の他の記憶領域に記憶される。

本実施例では、複数の連携するサーバでＷｅｂＩｎｔｅｎｔｓ処理を行う場合に、サーバでの処理が失敗してユーザが選択した処理が完了しない場合にユーザに処理の失敗を表示する構成を示した。また、連携するサーバの優先順位を表示、選択する構成について説明した。

以上の処理により、連携する複数のサービスでエラーが発生した場合でもユーザがエラーを容易に認識でき、他のＷｅｂＩｎｔｅｎｔｓサービスを選択して処理することが可能となる。よって、クライアントの保持するデータｔｙｐｅと、サービスが処理できるデータｔｙｐｅが異なる場合においても、ユーザの手を煩わすことなく容易に複数のサービスを連携して所望のサービスを利用することが可能となる。
従って、本発明の各実施例によれば、データを管理するＷｅｂＩｎｔｅｎｔｓクライアントの提供するデータのタイプを処理ができないサービスであっても、他のサービスを連携して、容易に選択、利用することを出来るようにすることができる。

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

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

Claims (17)

1. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末であって、
   前記中継機能による、前記サービスが提供する機能を呼び出すための機能情報の登録処理を実行する登録手段と、
   ユーザより前記クライアントで管理される特定のデータに対する機能の呼び出しが指示された場合に、前記特定のデータを、該呼び出しが指示された機能に対応するカテゴリに属する前記登録手段に登録されている第１機能情報の処理可能なタイプに適合させるための第２機能情報を前記登録手段に登録されている機能情報から特定する特定手段と、
   前記特定された第２機能情報を用いて呼び出した機能により処理された前記特定のデータを、前記第１機能情報を用いて呼び出した機能で処理するための要求を行う要求手段と、
   前記要求手段で要求した処理の処理結果を受信する受信手段と、
   を有することを特徴とする情報処理端末。
2. 前記要求手段は、前記特定のデータを、前記第２機能情報を用いて呼び出す機能により処理するための要求を、該機能を提供するサービスに対して行い、さらに、前記第２機能情報を用いて呼び出した機能により処理された前記特定のデータを、前記第１機能情報を用いて呼び出す機能により処理するための要求を、該機能を提供するサービスに対して行うものであり、
   前記受信手段は、前記第１機能情報を用いて呼び出した機能を提供するサービスから、処理結果を受信することを特徴とする請求項１に記載の情報処理端末。
3. 前記要求手段は、前記特定のデータを、前記第２機能情報を用いて呼び出す機能により処理するための要求、及び、前記第２機能情報を用いて呼び出す機能により処理された前記特定のデータを、前記第１機能情報を用いて呼び出す機能により処理するための要求を、前記第２機能情報を用いて呼び出す機能を提供するサービスに対して行うものであり、
   前記受信手段は、前記第２機能情報を用いて呼び出した機能を提供するサービスから、処理結果を受信することを特徴とする請求項１に記載の情報処理端末。
4. 前記第１機能情報に連携する前記第２機能情報を一覧表示し、該一覧から利用する第２機能情報の指定をユーザから受け付ける指定手段を有し、
   前記指定手段で受け付けた指定に従い、前記要求を行うことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理端末。
5. 前記機能情報を用いて呼び出した機能による処理の処理結果を記憶する記憶手段を有し、
   前記指定手段は、前記記憶手段にエラーの発生が記憶されている機能情報については、前記一覧に、過去にエラーが発生したことを示す情報を表示することを特徴とする請求項４に記載の情報処理端末。
6. 前記登録手段は、登録されている機能情報の利用回数又は利用頻度を記憶するものでああり、
   前記指定手段は、前記一覧を、利用回数又は利用頻度に応じた優先順に機能情報を表示することを特徴とする請求項４又は５に記載の情報処理端末。
7. 前記要求手段で要求した処理でエラーが発生した場合、前記指定手段は、再度、前記指定をユーザから受け付けることを特徴とする請求項４乃至６のいずれか１項に記載の情報処理端末。
8. 前記要求手段で要求した処理の処理結果を、前記機能情報を用いて呼び出した機能ごとに表示する表示手段を有することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理端末。
9. 前記表示手段は、前記要求手段で要求した処理に成功した場合、前記特定のデータを前記第２機能情報を用いて呼び出した機能により処理完了した旨、及び、前記第２機能情報を用いて呼び出した機能により処理された前記特定のデータを前記第１機能情報を用いて呼び出した機能により処理完了した旨を表示することを特徴とする請求項８に記載の情報処理端末。
10. 前記表示手段は、前記要求手段で要求した処理が前記第２機能情報を用いて呼び出した機能で処理に失敗した場合、前記特定のデータを前記第２機能情報を用いて呼び出した機能により処理することに失敗した旨、及び、前記特定のデータを前記第１機能情報を用いて呼び出す機能による処理を完了できなかった旨を表示することを特徴とする請求項８又は９に記載の情報処理端末。
11. 前記ネットワークは、インターネットであることを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理端末。
12. 前記クライアント、前記サービス及び前記中継機能の少なくとも２つは、同じ装置で動作する機能であることを特徴とする請求項１乃至１１のいずれか１項に記載の情報処理端末。
13. 前記カテゴリは、前記特定のデータの共有するカテゴリ、前記特定のデータの編集するカテゴリ、前記特定のデータの閲覧するカテゴリ、前記特定のデータを外部サービスから取得するカテゴリ、前記特定のデータの購読するカテゴリ、前記特定のデータの保存するカテゴリの少なくともいずれかを含むことを特徴とする請求項１乃至１２のいずれか１項に記載の情報処理端末。
14. 前記中継機能は、前記情報処理端末のオペレーティングシステムまたはウェブブラウザの機能として提供されることを特徴とする請求項１乃至１３のいずれか１項に記載の情報処理端末。
15. 前記カテゴリ及び前記特定のデータのタイプと利用された前記機能情報とを対応付けて設定する設定手段を有し、
    前記要求手段は、前記設定手段により設定されたカテゴリ及びデータのタイプと同一のカテゴリ及びデータのタイプの処理を要求する場合には、該カテゴリ及びデータのタイプと対応付けされた機能情報を利用することを特徴とする請求項１乃至１４のいずれか１項に記載の情報処理端末。
16. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末の制御方法であって、
    前記中継機能による、前記サービスが提供する機能を呼び出すための機能情報の登録処理を実行する登録ステップと、
    ユーザより前記クライアントで管理される特定のデータに対する機能の呼び出しが指示された場合に、前記特定のデータを、該呼び出しが指示された機能に対応するカテゴリに属する前記登録されている第１機能情報の処理可能なタイプに適合させるための第２機能情報を前記登録されている機能情報から特定する特定ステップと、
    前記特定された第２機能情報を用いて呼び出した機能により処理された前記特定のデータを、前記第１機能情報を用いて呼び出した機能で処理するための要求を行う要求ステップと、
    前記要求ステップで要求した処理の処理結果を受信する受信ステップと、
    を有することを特徴とする情報処理端末の制御方法。
17. コンピュータを、請求項１乃至１５のいずれか１項に記載の手段として機能させるためのプログラム。

Images