JP6271916B2 - 情報処理装置およびその制御方法、並びにプログラム - Google Patents

Description

本願発明は情報処理端末およびその制御方法、システムおよびその制御方法、並びにプログラムに関し、特に、Ｗｅｂ Ｉｎｔｅｎｔｓ（ウェブインテンツ）などの仕組みを用いたサービスを提供する際の技術に関する。

従来、ＷＥＢサイト間で処理を委譲する場合、機能を呼び出す側は、機能を提供する側のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）やＲＥＳＴインターフェイス等の機能の呼び出し方を知っている必要があった。従って、異なるＷＥＢサイトとの連携を実現するためには、機能の呼び出し側は、それぞれの呼び出し規約に従って呼び出し側の処理が必要になる。また、機能を呼び出す側が機能を利用するためには、機能を提供する側への認証が必要になることが多い。このために、機能を呼び出す側は、機能を提供する側の認証情報を保持したり、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等の認証基盤を利用したりする必要があった。但し、認証情報を持つと、それら認証情報を正しく適切に管理する必要があり、ＳＡＭＬ等の認証基盤を利用するためには、機能の提供者と利用者間で事前に合意が必要となり、機能の利用者の負担になっていた。

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

また、従来技術として、ＰＣ等の情報処理装置にデバイスドライバを手動でインストールする際に生成される、デバイスステージの詳細ページに関する特許文献１が挙げられる。例えば、一つのデバイスが複数のサービスを提供する場合、サービスに対応したデバイスドライバごとに、周辺機器の管理機能であるデバイスステージの詳細ページを提供してしまうことがある。これを避けるため、ドライバインストール時に、デバイス詳細ページを一つにまとめている。

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

特許文献１は、サービスごとに詳細ページを用意し、必要に応じて、各詳細ページをまとめることを可能とするが、Ｗｅｂ Ｉｎｔｅｎｔｓなどの新しい連携の仕組みについては、まったく考慮していない。

そこで、本発明は、ウェブサービスが提供するサービス内容が詳細化された場合でも、ウェブクライアントとウェブサービスの連携を柔軟かつ確実に実現できる手法を提供する。更に、サービスが詳細化されることによって管理するウェブサービスの数が増加した場合であっても、ウェブサービスを容易に管理できる手法を提供する。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、ネットワーク上のウェブサイトとしてＨＴＭＬ文書を提供するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを中継する中継機能を備える情報処理端末であって、前記サービスが提供する機能を呼び出すための機能情報を受信する受信手段と、機能のカテゴリとしてのデータ共有に対応するｓｈａｒｅを示す第１の分類情報と、当該第１の分類情報の詳細な分類を示す第２の分類情報とに従って、前記中継機能による前記機能情報の登録処理を実行する登録手段と、前記クライアントから提供されたＨＴＭＬ文書による表示画面上の前記データ共有の機能を指定するための共有ボタンが押下された場合に、前記第２の分類情報に基づき、前記登録処理により登録された機能情報をユーザに対して提供する提供手段と、を有する。

本発明によれば、Ｗｅｂ Ｉｎｔｅｎｔｓなどの連携の仕組みにおいて、ユーザビリティを向上させることができる。

本願発明に係るシステムの概念図。 情報処理端末のハードウェア構成例を示すブロック図。 Ｗｅｂ Ｉｎｔｅｎｔｓの動作の概要を説明するためのシーケンス図。 Ｗｅｂ Ｉｎｔｅｎｔｓの機能登録用のｉｎｔｅｎｔタグの例を示す図。 ＷｅｂＩｎｔｅｎｔｓ起動用のＥＣＭＡＳｃｒｉｐｔの例を示す図。 ソフトウェア構成例を示す図。 第一の実施形態に係るテーブル構成例を示す図。 第一の実施形態に係るサービス提供機能登録処理のシーケンス図。 第一の実施形態に係るｉｎｔｅｎｔタグの例を示す図。 第一の実施形態に係る提供機能登録画面の例を示す図。 第一の実施形態に係るサービス提供機能実行処理のシーケンス図。 第一の実施形態に係るＥＣＭＡＳｃｒｉｐｔの例を示す図。 第一の実施形態に係る提供機能選択画面の例を示す図。 第二の実施形態に係るｉｎｔｅｎｔタグの例を示す図。 第二の実施形態に係るテーブル構成例を示す図。 第二の実施形態に係るサービス提供機能登録処理のシーケンス図。 第三の実施形態に係るｉｎｔｅｎｔタグの例を示す図。 第三の実施形態に係るＥＣＭＡＳｃｒｉｐｔの例の例を示す図。 第三の実施形態に係るテーブル構成例を示す図。 第三の実施形態に係るサービス提供機能登録処理のシーケンス図。 第三の実施形態に係るサービス提供機能実行処理のシーケンス図。 第四の実施形態に係る提供機能登録画面の例を示す図。

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

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

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

本仕組みにおいては、例えば、クライアント１０１はデータを管理し、サービス１０３を呼び出すボタンなどを配置しているウェブサイトである。ＵＡ１０６は、ウェブサイトを表示するウェブブラウザである。また、サービス１０３は、ＵＡ１０６を介してクライアント１０１が管理するデータを受け付けて処理するクライアント１０１の連携先のウェブサイトである。例えば、本仕組みをＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）に適用した場合、サービス１０３はクライアント１０１で管理する写真やコメントの投稿を受け付けて閲覧サイトを構成する投稿先サービスとなる。サービス１０３が機能を提供する際にユーザ認証やユーザによる操作が必要な場合、ＵＡ１０６上でユーザが操作を行う。

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

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

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

［基本シーケンス］
図３は、Ｗｅｂ Ｉｎｔｅｎｔｓを利用したサービス提供に関する基本動作を説明するためのシーケンス図である。本シーケンス図は、Ｓ３０１からＳ３０７までのサービス提供機能登録処理と、Ｓ３０８からＳ３２２までのサービス提供機能実行処理から構成される。なお、本明細書にて説明するシーケンス図において破線矢印は、処理主体間のデータの流れ（送受信）を意味する。

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

図４の例を用いて、サービス１０３からＵＡ１０６に返信されるＨＴＭＬ文書の中身について説明する。ｉｎｔｅｎｔタグには提供機能を特定する情報が記載されている。ａｃｔｉｏｎ属性は、提供機能のカテゴリを示し、ｔｙｐｅ属性は提供機能が扱えるデータなどの種類を示している。ｈｒｅｆ属性は提供機能の接続先（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を示し、ｔｉｔｌｅ属性は提供機能のタイトルを示している。また、ｄｉｓｐｏｓｉｔｉｏｎ属性は、呼び出された提供機能がどのように表示されるかを示す。ｉｎｔｅｎｔタグにおける各属性およびその値は、例えばＷｅｂ Ｉｎｔｅｎｔｓの仕様にて共通的に規定されている。例えば、ａｃｔｉｏｎ属性においては、“ｅｄｉｔ”、“ｓｈａｒｅ”、“ｐｉｃｋ”、“ｖｉｅｗ”、“ｓｕｂｓｃｒｉｂｅ”、“ｓａｖｅ”などの値がある。

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

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

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

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

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

Ｓ３１２の画像データ取得要求を受信すると、Ｓ３１３にて、クライアント１０１は、画像データを準備する。そして、Ｓ３１４にて、クライアント１０１は、ＵＡ１０６へ準備した画像データを返信する。

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

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

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

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

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

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

図１（ｂ）は、本発明を実施したＷｅｂ Ｉｎｔｅｎｔｓの仕組みを適用したネットワークシステムの構成例を示す図である。図１（ｂ）において、情報処理端末１０２上では、ＷｅｂＩｎｔｅｎｔｓのユーザエージェント（ＵＡ）として機能するウェブブラウザが動作する。また、サーバ１０４上では、Ｗｅｂ Ｉｎｔｅｎｔｓのクライアントが動作し、サーバ１０５上では、Ｗｅｂ Ｉｎｔｅｎｔｓのサービスが動作する。情報処理端末１０２、サーバ１０４、サーバ１０５は、ネットワーク１０７を介して相互に通信可能である。また、ネットワーク１０７としては、ＬＡＮやインターネットやその組み合わせなどが想定される。接続形態としては、有線や無線を問わない。

［ハードウェア構成］
図２は、ＵＡ１０６として機能するプログラム（ウェブブラウザやＯＳなど）が実行される情報処理端末のハードウェアの構成例を示すブロック図である。また、クライアント１０１、サービス１０３として機能するプログラム（ウェブサイトなど）が動作するサーバも同様のハードウェア構成を取ることができる。

図２において、情報処理端末は、ＣＰＵ２０２、ＲＡＭ２０３、ＲＯＭ２０４、及び外部記憶装置２０９を備える。ＣＰＵ２０２は、ＲＯＭ２０４や外部記憶装置２０９に記憶されたプログラム、或いはＬＡＮなどのネットワーク１０７よりダウンロードしたプログラムを実行し、システムバス２１１に接続された各デバイスを総括的に制御する。ＲＡＭ２０３は、ＣＰＵ２０２の主メモリあるいはワークエリアなどとして機能する。外部記憶装置２０９は、ハードディスク（ＨＤ）、フロッピー（登録商標）ディスク（ＦＤ）等を含む。外部記憶装置２０９は、ブートプログラム、ＯＳ、認証サーバ、認証クライアントを含む各種のアプリケーション、データベースデータ、ユーザファイル等を記憶する。

さらに情報処理端末において、キーボードコントローラ（ＫＢＤＣ）２０６は、キーボード（ＫＢＤ）２０５やポインティングデバイス（不図示）からの入力情報をＣＰＵ２０２に送る。ビデオコントローラ（ＶＣ）２０８は、ＣＲＴやＬＣＤ等からなる表示装置２０７の表示を制御する。ディスクコントローラ（ＤＫＣ）２１０は、外部記憶装置２０９とのアクセスを制御する。通信コントローラ（ＣＯＭＭ Ｉ／Ｆ）２１２および各処理部は、サーバ１０４の外部記憶装置２０９に保存されたファイルとして存在する。これらは実行時にＯＳやその各処理部を利用する他の処理部によってＲＡＭ２０３にロードされ実行されるプログラムモジュールである。

［ソフトウェア構成］
クライアント１０１は、例えば画像データや文書データの保管などのストレージサービスを提供するアプリケーションである。クライアント１０１は、ＨＴＴＰリクエストに応答して処理を実行するプログラムとして実装される。図６（ａ）を用いてクライアント１０１のソフトウェアモジュールの構成例について説明する。クライアント１０１は、Ｉｎｔｅｎｔ処理要求作成部６０２、プレゼンテーション部６０３、詳細アクション作成部６０４、およびデータ管理部６０５を有する。

Ｉｎｔｅｎｔ処理要求作成部６０２は、Ｉｎｔｅｎｔの処理要求であるＥＣＭＡＳｃｒｉｐｔを作成する。プレゼンテーション部６０３は、通信部６０１を介して受け取ったページ取得要求などに応じてＨＴＭＬ文書を作成する。詳細アクション作成部６０４は、クライアント１０１がＷｅｂ Ｉｎｔｅｎｔｓサービスへの処理要求を作成する際に、アクションを詳細に指定する。

データ管理部６０５は、プレゼンテーション部６０３からの要求に応じてクライアントデータ格納部６０６から画像等のデータを取得したり、格納したりする。クライアントデータ格納部６０６は、データを管理し、他の処理部からの要求に応じてデータの格納と取り出しを行う。通信部６０１は、外部機器からのＨＴＴＰリクエストメッセージを受信しプレゼンテーション部６０３にリクエストの内容を通知する。また、通信部６０１は、プレゼンテーション部６０３からの要求を受けてＨＴＴＰのレスポンスメッセージを外部機器に送信する。なお、クライアントデータ格納部６０６は、サーバ１０４とは別の機器上にあってもよい。

図６（ｂ）は、サーバ１０５のソフトウェアモジュールの構成例を示す図である。サーバ１０５において、サービス１０３および各処理部はサーバ１０５の外部記憶装置２０９に保存されたファイルとして存在する。これらは実行時にＯＳやその各処理部を利用する他の処理部によってＲＡＭ２０３にロードされ実行されるプログラムモジュールである。

サービス１０３は、画像データや文書データの保管機能や編集機能を提供する。また、サーバ１０５は、Ｉｎｔｅｎｔｓ技術を利用してサービスを提供するＷｅｂ Ｉｎｔｅｎｔｓサービスの機能を有する。さらにサービス１０３は、ＨＴＴＰリクエストに応答して処理を実行するプログラムとして実装される。サービス１０３は、Ｉｎｔｅｎｔ処理部６３２、プレゼンテーション部６３３、ｉｎｔｅｎｔタグ作成部６３４、およびデータ管理部６３５を有する。

Ｉｎｔｅｎｔ処理部６３２は、Ｉｎｔｅｎｔオブジェクトを解析し、処理する。プレゼンテーション部６３３は、通信部６３１を介して受け取ったページ取得要求などに応じてＨＴＭＬ文書を作成する。ｉｎｔｅｎｔタグ作成部６３４は、サービスデータ格納部６３６に格納されている提供機能の情報をＵＡに通知するためのｉｎｔｅｎｔタグを作成する。データ管理部６３５は他の処理部からの要求に応じてサービスデータ格納部６３６から画像等のデータを取得したり、格納したりする。サービスデータ格納部６３６は、データを管理し、ｉｎｔｅｎｔタグ作成部６３４やデータ管理部６３５からの要求に応じてデータの取り出しや格納を行う。通信部６３１は、外部機器からのＨＴＴＰリクエストメッセージを受信しプレゼンテーション部６３３にリクエストの内容を通知する。また、通信部６３１は、プレゼンテーション部６３３からの要求を受けてＨＴＴＰのレスポンスメッセージを外部機器に送信する。なお、サービスデータ格納部６３６はサーバ１０５とは別の機器上にあってもよい。

図６（ｃ）は、情報処理端末１０２のソフトウェアモジュールの構成例を示す図である。情報処理端末１０２において、ウェブブラウザに代表されるＵＡ１０６および各処理部は、情報処理端末１０２の外部記憶装置２０９に保存されたファイルとして存在する。これらは実行時にＯＳやその各処理部を利用する他の処理部によってＲＡＭ２０３にロードされ実行されるプログラムモジュールである。

ＵＡ１０６は、表示部６５２、解析部６５３、および提供機能管理部６５４を有する。表示部６５２は、ＨＴＭＬ文書をレンダリングする。また、表示部６５２は、他の処理部の要求に応じて、提供機能の選択を受け付ける画面を表示する。解析部６５３は、ＨＴＭＬ文書を解析する。また、解析部６５３は、Ｉｎｔｅｎｔ処理要求であるＥＣＭＡＳｃｒｉｐｔも解析する。提供機能管理部６５４は、後述の提供機能格納部６５５から登録済みの提供機能を特定する情報を取得したり、格納したりする。

提供機能格納部６５５は、サービス１０３の提供機能を含むＷｅｂ Ｉｎｔｅｎｔｓのサービスを一覧管理し、提供機能管理部６５４からの要求に応じてデータの格納と取り出しを行う。通信部６５１は、他の処理部からの要求を受けてＨＴＴＰのリクエストメッセージを外部機器に送信する。また、通信部６５１は、外部機器からのＨＴＴＰレスポンスメッセージを受信し、解析部６５３にレスポンスの内容を通知する。なお、提供機能格納部６５５は、サーバ１０５とは別の機器上にあってもよい。

［管理テーブル］
図７（ａ）は、サーバ１０４のクライアントデータ格納部６０６が管理するテーブルの構成例である。なお、図７（ａ）のテーブル構成は一例であり、ここで示す構成とは異なるテーブル構成であってもよい。

データ管理テーブル７０１は、クライアント１０１が扱う各種データを管理するためのテーブルである。データ管理テーブル７０１が管理する情報は、ＩＤおよびＦｉｌｅである。ＩＤは、クライアント１０１内で各種データを一意に識別するための識別子である。Ｆｉｌｅは、各種データのファイル名を表す。つまり、データ管理テーブル７０１の例では、ｉｍａｇｅ００１．ｊｐｇとｄｏｃ００２．ｐｄｆの２つのデータファイルを管理している。

図７（ｂ）は、サーバ１０５のサービスデータ格納部６３６が管理するテーブルの構成例である。なお、図７（ｂ）のテーブル構成は一例であり、本例とは異なるテーブル構成であってもよい。

サービスデータ格納部６３６は、機能管理テーブル７０２とデータ管理テーブル７０３を管理する。機能管理テーブル７０２は、サービス１０３の提供機能に関する情報を管理するためのテーブルである。なお、機能管理テーブル７０２には、予め、情報が登録されていることを想定する。例えば、サービス１０３がサーバ１０５にインストールされる際に、サービス１０３が提供機能の情報を機能管理テーブル７０２に登録することなどが考えられる。また、サービス１０３がバージョンアップされる際に、機能管理テーブル７０２が更新されることも考えられる。

機能管理テーブル７０２で管理する情報は、ＩＤ、ａｃｔｉｏｎ、ｔｙｐｅ、ｈｒｅｆ、ｔｉｔｌｅ、およびｄｉｓｐｏｓｉｔｉｏｎである。これは図４で説明したｉｎｔｅｎｔタグが示す情報とほぼ同様の情報である。ＩＤは、サービス１０３内で提供機能を一意に識別する識別子である。ａｃｔｉｏｎは提供機能のカテゴリを示し、ｔｙｐｅは提供機能が扱えるデータなどの種類を示す。ｈｒｅｆは提供機能の接続先（ＵＲＬ）を示し、ｔｉｔｌｅは提供機能のタイトルを示す。また、ｄｉｓｐｏｓｉｔｉｏｎは呼び出された提供機能がどのように表示されるかを示す。

データ管理テーブル７０３は、サービス１０３が扱う各種データを管理するためのテーブルである。データ管理テーブル７０３が管理する情報は、ＩＤ、およびＦｉｌｅである。ＩＤは、サービス１０３内で各種データを一意に識別するための識別子である。Ｆｉｌｅは、各種データのファイル名を表す。つまり、データ管理テーブル７０３の例では、ｉｍａｇｅ０１１．ｊｐｇとｄｏｃ０１２．ｐｄｆの２つのデータファイルを管理している。

図７（ｃ）は、情報処理端末１０２の提供機能格納部６５５が管理するテーブルの構成例である。なお、図７（ｃ）のテーブル構成は一例であり、ここで示す構成とは異なるテーブル構成であってもよい。

提供機能管理テーブル７０４は、ＵＡ１０６が仲介することができるＷｅｂ Ｉｎｔｅｎｔｓのサービスの提供機能に関する情報を管理するためのテーブルである。

提供機能管理テーブル７０４で管理する情報は、ＩＤ、ａｃｔ−ｍａｉｎ、ａｃｔ−ｄｅｔａｉｌ、ｔｙｐｅ、ｈｒｅｆ、ｔｉｔｌｅ、およびｄｉｓｐｏｓｉｔｉｏｎである。これは、ａｃｔ−ｍａｉｎ、ａｃｔ−ｄｅｔａｉｌを除いて、図４で説明したｉｎｔｅｎｔタグが示す情報とほぼ同様の情報である。ＩＤは、サービス１０３内で提供機能を一意に識別する識別子である。ａｃｔ−ｍａｉｎ、ａｃｔ−ｄｅｔａｉｌは、図４で説明したｉｎｔｅｎｔタグのａｃｔｉｏｎ属性を主要部と詳細部に分割したものである。ａｃｔ−ｍａｉｎは提供機能のカテゴリを示し、ａｃｔ−ｄｅｔａｉｌはカテゴリの詳細を示す。ｔｙｐｅは提供機能が扱えるデータなどの種類を示す。ｈｒｅｆは提供機能の接続先（ＵＲＬ）を示し、ｔｉｔｌｅは提供機能のタイトルを示す。また、ｄｉｓｐｏｓｉｔｉｏｎは呼び出された提供機能がどのように表示されるかを示す。

なお、本実施形態では、ａｃｔｉｏｎ属性を主要部と詳細部とから構成している。ここで、ａｃｔｉｏｎ属性の主要部は、Ｗｅｂ Ｉｎｔｅｎｔｓの仕様で定義される情報であり、“ｅｄｉｔ”、“ｓｈａｒｅ”、“ｐｉｃｋ”、“ｖｉｅｗ”、“ｓｕｂｓｃｒｉｂｅ”、“ｓａｖｅ”などの値が示される。本実施形態においてａｃｔｉｏｎ属性の情報を「第一の分類情報」とも記述する。一方、本実施形態に特有のａｃｔｉｏｎ属性の詳細部には、例えば“ｉｍａｇｅ”、“ｐｄｆ“などの情報が定義され、この情報を「第二の分類情報」と記述する。

［処理シーケンス］
（登録処理）
次に、図８のシーケンス図を用いて、情報処理端末１０２がサーバ１０５のサービス１０３にアクセスして、サービス１０３の提供機能をＵＡ１０６に登録する動作（図３のサービス提供機能登録処理に相当）について説明する。Ｓ８０１からＳ８０４までは、図３のＳ３０１からＳ３０４とほぼ同様である。

Ｓ８０１にて、ＵＡ１０６は、サービス１０３にアクセスする。Ｓ８０２にて、サービス１０３のｉｎｔｅｎｔタグ作成部６３４が機能管理テーブル７０２からｉｎｔｅｎｔタグを作成し、プレゼンテーション部６３３がＨＴＭＬ応答を作成する。ここでは、機能管理テーブル７０２に登録されている３つのサービスを表すｉｎｔｅｎｔタグが作成されるものとする。

図９は、Ｓ８０２にてｉｎｔｅｎｔタグ作成部６３４が作成するｉｎｔｅｎｔタグの例である。ここでは、機能管理テーブル７０２のＩＤが“１”であるレコードの情報を例に取っている。図４のｉｎｔｅｎｔタグとの違いは、ａｃｔｉｏｎとして、“ｓｈａｒｅ”を詳細化した“ｓｈａｒｅ ｉｍａｇｅ”が指定されている点である。つまり、ａｃｔｉｏｎ属性には、主要部と詳細部とから構成された情報が記載されている。

Ｓ８０３にて、サーバ１０５の通信部６３１は、作成したＨＴＭＬ応答を、ＵＡ１０６に返信する。

Ｓ８０４にて、情報処理端末１０２の通信部６５１が、サーバ１０５から送信されたＨＴＭＬ応答を受信する。Ｓ８０５にて、解析部６５３は、受信したＨＴＭＬ応答から検出したｉｎｔｅｎｔタグのａｃｔｉｏｎ属性が細分化可能か否かを判定する。細分化可能か否かは、ａｃｔｉｏｎ属性に指定されている文字列にセパレータが含まれているか否かにより判定できる。本実施形態では、ａｃｔｉｏｎ属性のセパレータとしての所定の文字（もしくは文字列）がスペース（‘ ’）であると仮定する。図９の例では、文字列“ｓｈａｒｅ”と“ｉｍａｇｅ”との間にスペースが含まれているため、ａｃｔｉｏｎ属性の細分化が可能であると判定される。細分化が可能である場合には（Ｓ８０５にてＹＥＳ）Ｓ８０６へ進み、細分化が不可である場合には（Ｓ８０５にてＮＯ）Ｓ８０８へ進む。

Ｓ８０６にて、解析部６５３は、ａｃｔｉｏｎ属性をセパレータの前後で、主要部と詳細部に分割する。図９の例では、“ｓｈａｒｅ”が主要部、“ｉｍａｇｅ”が詳細部となる。

Ｓ８０７にて、Ｓ８０４でＵＡ１０６が受信したＨＴＭＬ応答に複数のｉｎｔｅｎｔタグが含まれていた場合、ａｃｔｉｏｎ属性の主要部が同一であるｉｎｔｅｎｔタグをグループ化する。本実施形態では、機能管理テーブル７０２のＩＤが“１”であるレコードと、ＩＤが“３”であるレコードのｉｎｔｅｎｔタグにおいて、ａｃｔｉｏｎ属性の主要部“ｓｈａｒａ”が同一であるため、これらのレコードがグループ化される。

Ｓ８０８にて、表示部６５２はＵＡ１０６上に提供機能登録画面を表示する。図１０は、Ｓ８０８にて表示される提供機能登録画面１０００の例である。図１０において、ボタン１００１は、Ｓ８０４で受信したＨＴＭＬ応答に含まれるｉｎｔｅｎｔタグが表現するサービス１０３の提供機能すべてをＵＡ１０６に登録するために用いられる。ボタン１００２は、Ｓ８０７でグループ化したｉｎｔｅｎｔタグ毎に提供機能をＵＡ１０６に登録するために用いられる。ボタン１００３は、個別に提供機能をＵＡ１０６に登録するために用いられる。

Ｓ８０９にて、表示部６５２は、提供機能が選択されたか否かを検出する。提供機能の選択は、提供機能登録画面１０００上でユーザがボタン１００１〜１００３のいずれかが押下されることによって行われる。提供機能が選択された場合（Ｓ８０９にてＹＥＳ）、Ｓ８１０に進む。提供機能が選択されていない場合（Ｓ８０９にてＮＯ）、本フローチャートを終了する。

Ｓ８１０にて、提供機能管理部６５４は、選択された提供機能の情報を提供機能管理テーブル７０４に登録する。Ｓ８０６で分割したａｃｔｉｏｎ属性の主要部はａｃｔ−ｍａｉｎ列に、詳細部はａｃｔ−ｄｅｔａｉｌ列にそれぞれ登録される。そして、本フローチャートを終了する。

（実行処理）
次に、図１１のシーケンス図を用いて、情報処理端末１０２がサーバ１０４のクライアント１０１にアクセスして、サーバ１０５のサービス１０３にＩｎｔｅｎｔの処理要求を仲介する動作（図３のサービス提供機能実行処理に相当）について説明する。Ｓ１１０１〜Ｓ１１０７は、図３のＳ３０８〜Ｓ３１４と同様であるため、説明を省略する。

ただし、Ｓ１１０２では、クライアント１０１は、図１２に例示するような細分化可能なａｃｔｉｏｎ属性を含むＨＴＭＬ応答を作成する。図１２は、本実施形態のＳ１１０２で作成されるＨＴＭＬ応答の中身の例である。図５の例との違いは、新規のＩｎｔｅｎｔオブジェクトを作成する際に指定するａｃｔｉｏｎ属性が細分化可能になっている点である。

Ｓ１１０８にて、図３のＳ３１５と同様に、提供機能管理部６５４は、提供機能格納部６５５にＷｅｂ Ｉｎｔｅｎｔの一覧が登録されているか否かを判定する。具体的には、提供機能管理テーブル７０４に１つ以上のエントリーが存在するか否かを判定する。登録されている場合は（Ｓ１１０８にてＹＥＳ）、Ｓ１１０９に進む。登録されていない場合は（Ｓ１１０８にてＮＯ）、Ｓ１１２０に進む。

Ｓ１１０９にて、解析部６５３は、Ｓ１１０４で受信したＨＴＭＬ文書に含まれるＥＣＭＡＳｃｒｉｐｔのａｃｔｉｏｎ属性の値が細分化可能か否かを判定する。細分化可能か否かの判定は、図８のＳ８０５と同様であるため、説明を省略する。細分化可能であると場合は（Ｓ１１０９にてＹＥＳ）、Ｓ１１１０に進む。細分化が不可である場合は（Ｓ１１０９にてＮＯ）、Ｓ１１１３に進む。

Ｓ１１１０にて、解析部６５３は、ＥＣＭＡＳｃｒｉｐｔのａｃｔｉｏｎをセパレータの前後で、主要部と詳細部に分割する。図１２の例では、“ｓｈａｒｅ”が主要部、“ｉｍａｇｅ”が詳細部となる。

Ｓ１１１１にて、提供機能管理部６５４は、提供機能管理テーブル７０４のエントリーの中からＳ１１１０で細分化した主要部および詳細部と同じ値を持つエントリーを抽出できるか否かを判定する。抽出できる場合は（Ｓ１１１１にてＹＥＳ）、Ｓ１１１２に進む。抽出できない場合は（Ｓ１１１１にてＮＯ）、Ｓ１１１４に進む。

Ｓ１１１２にて、表示部６５２は、Ｓ１１１１で抽出したエントリーをＵＡ１０６上に一覧表示する。図１３は、Ｓ１１１２にて表示される提供機能選択画面１３００の例である。図１２において、ボタン１３０１は、Ｓ１１１１で抽出されたエントリーのｔｉｔｌｅが表示された、提供機能を選択するために用いられる。なお、Ｓ１１１１にて複数のエントリーが抽出された場合は、提供機能選択画面１３００において、上記ボタンが複数列挙される。

Ｓ１１１３にて、解析部６５３は、ＥＣＭＡＳｃｒｉｐｔのａｃｔｉｏｎの値をそのまま、主要部と判定する。

Ｓ１１１４にて、提供機能管理部６５４は、提供機能管理テーブル７０４のエントリーの中から、Ｓ１１１０またはＳ１１１３で主要部とされた値と同じ値を持つエントリーを抽出できるか否かを判定する。抽出できる場合は（Ｓ１１１４にてＹＥＳ）、Ｓ１１１５に進む。抽出できない場合は（Ｓ１１１４にてＮＯ）、Ｓ１１２０に進む。

Ｓ１１１５にて、表示部６５２は、Ｓ１１１４で抽出したエントリーをＵＡ１０６上に一覧表示する。本ステップで表示される画面の例は図１３と同一であるため、説明を省略する。Ｓ１１１６〜Ｓ１１２１は、図３のＳ３１７〜Ｓ３２２と同様であるため、説明を省略する。

なお、図８では、ＵＡ１０６が、受信したｉｎｔｅｎｔタグのａｃｔｉｏｎ属性を解析して提供機能をグループ化する場合について説明したが、ａｃｔｉｏｎ属性とは無関係の新規属性を導入することによって、提供機能をグループ化するようにしてもよい。この場合、機能管理テーブル７０２や提供機能管理テーブル７０４には、新規属性に対応する列が追加される。また、Ｓ８０５に相当するステップでは、ｉｎｔｅｎｔタグの中に新規属性が含まれるか否かを判定することになる。さらに、Ｓ８０６、Ｓ８０７に相当するステップでは、新規属性が一致するｉｎｔｅｎｔタグをグループ化することになる。なお、新規属性は、サービスを提供するベンダーを表すｖｅｎｄｏｒ属性や、キーワードを自由に設定できるｋｅｙｗｏｒｄ属性などが考えられるが、これに限定されるものではない。新規属性は本願発明に特有の属性となるため、第２の分類情報として扱うことができる。このグループ化に関する方法については、以下に説明する実施形態でも同様である。

さらに、本実施形態では、ＵＡ１０６がサービス１０３にアクセスした直後に、提供機能登録画面を表示する場合について説明したが、提供機能登録画面は、例えば、ＵＡ１０６の起動時や終了時に表示されてもよい。あるいは、ユーザが任意のタイミングでＵＡ１０６のメニューから指示できるようにしてもよい。この場合、ＵＡ１０６はサービス１０３にアクセスした後、提供機能登録画面に表示すべき情報をＲＡＭ２０３や外部記憶装置２０９に一時的に保持しておく。そして、ＵＡ１０６は、自身の起動、終了、ユーザによる指示などのトリガを受け、一時保持された情報をＲＡＭ２０３や外部記憶装置２０９から読み出し、提供機能登録画面上に表示する。

＜第二の実施形態＞
第一の実施形態では、ａｃｔｉｏｎ属性を主要部と詳細部に分割する例を説明したが、本実施形態では、ｔｙｐｅ属性を拡張する例を説明する。つまり、本実施形態では、Ｗｅｂ Ｉｎｔｅｎｔｓの仕様で定義されるａｃｔｉｏｎ属性の情報が「第一の分類情報」となる。一方、本実施形態に特有の構成を有するｔｙｐｅ属性の情報が「第二の分類情報」となる。

図１４は、本実施形態にてサービス１０３のｉｎｔｅｎｔタグ作成部６３４が作成するｉｎｔｅｎｔタグの例である。図４のｉｎｔｅｎｔタグとの違いは、ｔｙｐｅ属性にデータの種類が複数指定されている点である。

図１５（ａ）の機能管理テーブル１５０１は、本実施形態においてサーバ１０５のサービスデータ格納部６３６が管理するテーブルの構成例であり、図７（ｂ）の機能管理テーブル７０２と類似のものである。なお、図１５（ａ）のテーブル構成は一例であり、本例とは異なるテーブル構成であってもよい。機能管理テーブル７０２ではａｃｔｉｏｎ列に詳細化可能なａｃｔｉｏｎ属性の値を指定可能であるが、機能管理テーブル１５０１ではｔｙｐｅ列にｔｙｐｅ属性の値を複数指定可能である。

図１５（ｂ）の提供機能管理テーブル１５０２は、本実施形態において情報処理端末１０２の提供機能格納部６５５が管理するテーブルの構成例であり、図７（ｃ）の提供機能管理テーブル７０４と類似のものである。なお、図１５（ｂ）のテーブル構成は一例であり、本例とは異なるテーブル構成であってもよい。第一の実施形態にて述べた提供機能管理テーブル７０４では、詳細化されたａｃｔｉｏｎ属性の情報を格納するために、ａｃｔ−ｍａｉｎ列とａｃｔ−ｄｅｔａｉｌ列が設けられていた。一方、本実施形態に係る提供機能管理テーブル１５０２では、ｉｎｔｅｎｔタグのｔｙｐｅ属性に複数のデータ種類が指定された場合に対応するため、ｔｙｐｅ列に複数のデータ種類の情報を格納できるようになっている。

［処理シーケンス］
（登録処理）
次に、図１６のシーケンス図を用いて、情報処理端末１０２がサーバ１０５のサービス１０３にアクセスして、サービス１０３の提供機能をＵＡ１０６に登録する動作（図３のサービス提供機能登録処理に相当）について説明する。Ｓ１６０１〜Ｓ１６０６は、図３のＳ３０１〜Ｓ３０６と同様のため、説明を省略する。

Ｓ１６０７にて、解析部６５３は、Ｓ１６０６にてユーザによって選択された提供機能に対応するｉｎｔｅｎｔタグのｔｙｐｅ属性が細分化可能か否かを判定する。細分化可能か否かは、ｔｙｐｅ属性に指定されている文字列にセパレータが含まれているか否かで判定できる。本実施形態では、ｔｙｐｅ属性のセパレータとしての所定の文字（もしくは文字列）がスペース（‘ ’）であると仮定する。図１４の例では、“ｉｍａｇｅ／＊”と“ａｐｐｌｉｃａｔｉｏｎ／ｐｄｆ”の間にスペースが含まれているため、ｔｙｐｅ属性は細分化が可能であると判定される。

Ｓ１６０８にて、解析部６５３は、ｔｙｐｅ属性をセパレータの前後で個々の要素に分割する。

Ｓ１６０９にて、提供機能管理部６５４は、選択された提供機能の情報を提供機能管理テーブル１５０２に登録する。Ｓ１６０８で分割したｔｙｐｅ属性の個々の要素はｔｙｐｅ列に登録される。以上により、本実施形態に係るサービス提供機能登録処理が終了する。

本実施形態に係るサービス提供機能実行処理については、Ｓ３１５に相当するステップ以外は第一の実施形態にて述べた図３のサービス提供機能実行処理と同様であるため、説明を省略する。

Ｓ３１５に相当するステップは、本実施形態では、提供機能管理部６５４が、提供機能管理テーブル１５０２からａｃｔｉｏｎ列の値、およびｔｙｐｅ列に登録されている要素のいずれか１つの値と一致したエントリーを抽出できるか否かを判定する。

以上により、第二の実施形態においても、第一の実施形態と同様の効果を得ることが可能となる。

＜第三の実施形態＞
本実施形態では、ａｃｔｉｏｎ属性に加えて、新規属性“ｓｕｂ−ａｃｔｉｏｎ”を追加する例を説明する。つまり、本実施形態では、Ｗｅｂ Ｉｎｔｅｎｔｓの仕様で定義されるａｃｔｉｏｎ属性の情報が「第一の分類情報」となる。一方、本実施形態にて新たに設けられる特有のｓｕｂ−ａｃｔｉｏｎ属性の情報が「第二の分類情報」となる。

図１７は、本実施例にてサービス１０３のｉｎｔｅｎｔタグ作成部６３４が作成するｉｎｔｅｎｔタグの例である。図４のｉｎｔｅｎｔタグとの違いは、ａｃｔｉｏｎ属性を補足するためのｓｕｂ−ａｃｔｉｏｎ属性が新たに追加されている点である。なお、ｓｕｂ−ａｃｔｉｏｎ属性の値は、セパレータで区切って複数指定できてもよい。図１７の例では、ａｃｔｉｏｎ属性として、“ｅｄｉｔ”（「編集」の意）が指定されているが、これに限定されるものではない。また、ｓｕｂ−ａｃｔｉｏｎ属性の値として、“ｆｏｒｍａｔ”（「フォーマット変換」の意）と“ｃｏｌｏｒ”（「色変換」の意）が指定されているが、これに限定されるものではない。つまり、処理や扱うデータの属性等に応じて設定値を定義できるようにしても構わない。

図１８は、本実施形態にてクライアント１０１からＵＡ１０６に返信されるＨＴＭＬ応答の中のＥＣＭＡＳｃｒｉｐｔの例である。図５のＥＣＭＡＳｃｒｉｐｔとの違いは、ａｃｔｉｏｎ属性を補足するためのｓｕｂ−ａｃｔｉｏｎ属性が追加されている点である。なお、ｓｕｂ−ａｃｔｉｏｎ属性の値は、セパレータで区切って複数指定できてもよい。

図１９（ａ）の機能管理テーブル１９０１は、本実施形態においてサーバ１０５のサービスデータ格納部６３６が管理するテーブルの構成例であり、図７（ｂ）の機能管理テーブル７０２と類似のものである。なお、図１９（ａ）のテーブル構成は一例であり、ここで示す構成とは異なるテーブル構成であってもよい。本実施形態に係る機能管理テーブル１９０１には、上述した機能管理テーブル７０２には存在しない、ｓｕｂ−ａｃｔｉｏｎ属性の値を保持するためのｓｕｂ−ａｃｔｉｏｎ列が追加されている。

図１９（ｂ）の提供機能管理テーブル１９０２は、本実施形態において情報処理端末１０２の提供機能格納部６５５が管理するテーブルの構成例であり、図７（ｃ）の提供機能管理テーブル７０４と類似のものである。なお、図１９（ｂ）のテーブル構成は一例であり、ここで示す構成とは異なるテーブル構成であってもよい。提供機能管理テーブル１９０２には、提供機能管理テーブル７０４には存在しない、ｓｕｂ−ａｃｔｉｏｎ属性の値を保持するためのｓｕｂ−ａｃｔｉｏｎ列が追加されている。

［処理フロー］
（登録処理）
次に、図２０のシーケンス図を用いて、情報処理端末１０２がサーバ１０５のサービス１０３にアクセスして、サービス１０３の提供機能をＵＡ１０６に登録する動作（図３のサービス提供機能登録処理に相当）について説明する。図２０のシーケンスは、ほとんどの部分で第二の実施形態にて示した図１６のシーケンスと同一である。したがって、図１６の各ステップと違いがあるステップのみ説明する。Ｓ２００１〜Ｓ２００６は、Ｓ１６０１〜Ｓ１６０６と同様であるため、説明を省略する。

Ｓ２００７は、図１６のＳ１６０７に相当するステップであり、本実施形態では、細分化可能か否かを判定する対象となる属性が、ｓｕｂ−ａｃｔｉｏｎ属性となる。Ｓ２００８は、図１６のＳ１６０８に相当するステップであり、本実施形態では、個々の要素に分割する対象となる属性が、ｓｕｂ−ａｃｔｉｏｎ属性となる。Ｓ２００９は、図１６のＳ１６０９に相当するステップであり、提供機能の情報の登録先が提供機能管理テーブル１９０２となり、Ｓ２００８で分割された個々の要素がｓｕｂ−ａｃｔｉｏｎ列に登録される。

（実行処理）
次に、図２１のシーケンス図を用いて、情報処理端末１０２がサーバ１０４のクライアント１０１にアクセスし、サーバ１０５のサービス１０３にＩｎｔｅｎｔの処理要求を仲介する動作（図３のサービス提供機能実行処理に相当）について説明する。図２１のシーケンスは、第一の実施形態にて示した図１１のシーケンス図と類似しているため、図１１の各ステップと違いがあるステップのみ説明する。Ｓ２１０１〜Ｓ２１０８は、Ｓ１１０１〜Ｓ１１０８と同様であるため、説明を省略する。

Ｓ２１０９にて、解析部６５３は、Ｓ２１０４で受信したＨＴＭＬ文書にｓｕｂ−ａｃｔｉｏｎ属性が存在するか否かを判定する。ｓｕｂ−ａｃｔｉｏｎ属性が存在する場合（Ｓ２１０９ＹＥＳ）、さらに、解析部６５３は、ｓｕｂ−ａｃｔｉｏｎ属性の値をスペース（‘ ’）などのセパレータの前後で個々の要素に分割する。最後に、提供機能管理部６５４は、提供機能管理テーブル１９０２のエントリーの中からｓｕｂ−ａｃｔｉｏｎ属性のすべての要素が一致するエントリーを抽出できるか否かを判定する。なお、すべての要素が一致するエントリーが存在しない場合は、一部の要素が一致するエントリーを抽出できるか否かを判定する。抽出できる場合は（Ｓ２１０９にてＹＥＳ）Ｓ２１１０に進む。抽出できない場合は（Ｓ２１０９にてＮＯ）、Ｓ２１１１に進む。

Ｓ２１１０は、図１１のＳ１１１２と同様で、表示部６５２がＳ２１０９で抽出したエントリーをＵＡ１０６上に一覧表示する。本ステップで表示される画面の例は第一の実施形態にて示した図１３と同一であるため、説明を省略する。

Ｓ２１１１にて、提供機能管理部６５４は、提供機能管理テーブル１９０２のエントリーの中からａｃｔｉｏｎ属性の値が一致するエントリーを抽出できるか否かを判定する。抽出できる場合は（Ｓ２１１１にてＹＥＳ）Ｓ２１１２に進む。抽出できない場合は（Ｓ２１１１にてＮＯ）、Ｓ２１１７に進む。

Ｓ２１１２は、図１１のＳ１１１５と同様で、表示部６５２がＳ２１１１で抽出したエントリーをＵＡ１０６上に一覧表示する。本ステップで表示される画面の例は図１３と同一であるため、説明を省略する。Ｓ２１１３〜Ｓ２１１８は、Ｓ１１１６〜Ｓ１１２１と同様であるため、説明を省略する。

以上により、第二の実施形態においても、第一の実施形態と同様の効果を得ることが可能となる。

＜第四の実施形態＞
本実施形態では、第一の実施形態において図１０に例示した提供機能登録画面１０００がスマートフォンやタブレットなどの表示領域が小さい情報処理端末上で表示される際の例を説明する。

図２２は、本実施形態に係る提供機能登録画面２２００の例を示す。図２２において、情報処理端末１０２はスマートフォンやタブレットなどの情報処理端末であり、ＵＡ１０６は、ブラウザなどのＵＡである。提供機能登録画面２２００は、ＵＡ１０６上に表示される提供機能登録画面である。

アイコン２２０１は提供機能を表現するためのアイコンであり、ＨＴＭＬ文書を返信する際（Ｓ３０３／Ｓ８０３／Ｓ１６０３／Ｓ２００３）に、サービス１０３がＵＡ１０６に渡す。アイコン２２０１は、サービスごとに１つのアイコンを持ってもよいし、提供機能ごとに１つのアイコンを持ってもよい。これらのアイコンは、予め登録されているものとする。サービスごとに１つのアイコンを持つ場合、返信されるＨＴＭＬ文書のｈｅａｄタグの中のｌｉｎｋタグが、例えば、以下のように記載されることによって、ＵＡ１０６がアイコンファイルを取得することが可能となる。
＜ｌｉｎｋ ｒｅｌ＝“ｉｃｏｎ” ｈｒｅｆ＝“ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｆａｖｉｃｏｎ．ｉｃｏ” ｔｙｐｅ＝“ｉｍａｇｅ／ｖｎｄ．ｍｉｃｒｏｓｏｆｔ．ｉｃｏｎ”／＞

一方、提供機能ごとに１つのアイコンを持つ場合、返信されるＨＴＭＬ文書のｉｎｔｅｎｔタグの中にアイコンファイルを指定するための属性（例えば、ｉｃｏｎ属性）が記載されることによって、ＵＡ１０６がアイコンファイルを取得することが可能となる。取得したアイコンの情報は、提供機能管理テーブル７０４、１５０２１９０２にｉｃｏｎ列を追加することによって、管理可能となる。

ツールチップ２２０２は、アイコンのツールチップであり、提供機能管理テーブル７０４、１５０２、１９０２のｔｉｔｌｅ列に格納されている情報が表示される。

以上、提供機能の登録時において、アイコンやツールチップを用いて表示することで、表示領域が小さい情報処理端末でもユーザの利便性を低下させることなく提供機能のグループ化が可能となる。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (14)

1. ネットワーク上のウェブサイトとしてＨＴＭＬ文書を提供するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを中継する中継機能を備える情報処理端末であって、
   前記サービスが提供する機能を呼び出すための機能情報を受信する受信手段と、
   機能のカテゴリとしてのデータ共有に対応するｓｈａｒｅを示す第１の分類情報と、当該第１の分類情報の詳細な分類を示す第２の分類情報とに従って、前記中継機能による前記機能情報の登録処理を実行する登録手段と、
   前記クライアントから提供されたＨＴＭＬ文書による表示画面上の前記データ共有の機能を指定するための共有ボタンが押下された場合に、前記第２の分類情報に基づき、前記登録処理により登録された機能情報をユーザに対して提供する提供手段と、
   を有することを特徴とする情報処理端末。
2. 前記ネットワークは、インターネットであることを特徴とする請求項１に記載の情報処理端末。
3. 前記サービス、及び前記中継機能は、同じ装置で動作する機能であることを特徴とする請求項１または２に記載の情報処理端末。
4. 前記第２の分類情報は、前記機能情報において、機能が扱えるデータの種類を定義する領域に含まれることを特徴とする請求項１乃至３のいずれか一項に記載の情報処理端末。
5. 前記第２の分類情報は、前記機能情報において、前記第１の分類情報を定義する領域に含まれることを特徴とする請求項１乃至３のいずれか一項に記載に情報処理端末。
6. 前記第２の分類情報は、前記機能情報において、新たな領域を設け、当該新たな領域に含まれることを特徴とする請求項１乃至３のいずれか一項に記載の情報処理端末。
7. 前記機能情報において、１の第１の分類情報に対して、１または複数の第２の分類情報が含まれることを特徴とする請求項１乃至６のいずれか一項に記載の情報処理端末。
8. 前記登録手段は、前記機能情報に含まれる前記第１および第２の分類情報の少なくとも一方を用いた表示画面を介したユーザの入力に従い、前記登録処理を実行することを特徴とする請求項１乃至７のいずれか一項に記載の情報処理端末。
9. 前記登録手段は、前記第１もしくは第２の分類情報が同一である機能をグループ化し、グループごとにユーザの入力が可能なように前記表示画面を表示することを特徴とする請求項８に記載の情報処理端末。
10. 前記登録手段は、グループ化した機能を表示する際に、グループに含まれる機能それぞれをアイコンにて表現することを特徴とする請求項９に記載の情報処理端末。
11. 前記登録手段は、前記中継機能の起動時もしくは終了時に、前記機能情報の登録処理に対するユーザの入力を受け付ける前記表示画面を表示することを特徴とする請求項８乃至１０のいずれか一項に記載の情報処理端末。
12. 前記中継機能は、前記情報処理端末のＯＳの機能として提供されることを特徴とする請求項１乃至１１のいずれか一項に記載の情報処理端末。
13. ネットワーク上のウェブサイトとしてＨＴＭＬ文書を提供するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを中継する中継機能を備える情報処理端末の制御方法であって、
    前記サービスが提供する機能を呼び出すための機能情報を受信する受信工程と、
    機能のカテゴリとしてのデータ共有に対応するｓｈａｒｅを示す第１の分類情報と、当該第１の分類情報の詳細な分類を示す第２の分類情報とに従って、前記中継機能による前記機能情報の登録処理を実行する登録工程と、
    前記クライアントから提供されたＨＴＭＬ文書による表示画面上に前記データ共有の機能を指定するための共有ボタンが押下された場合に、前記第２の分類情報に基づき、前記登録処理により登録された機能情報をユーザに対して提供する提供工程と、
    を有することを特徴とする制御方法。
14. ネットワーク上のウェブサイトとしてＨＴＭＬ文書を提供するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを中継する中継機能を備えるコンピュータを、
    前記サービスが提供する機能を呼び出すための機能情報を受信する受信手段、
    機能のカテゴリとしてのデータ共有に対応するｓｈａｒｅを示す第１の分類情報と、当該第１の分類情報の詳細な分類を示す第２の分類情報とに従って、前記中継機能による前記機能情報の登録処理を実行する登録手段、
    前記クライアントから提供されたＨＴＭＬ文書による表示画面上の前記データ共有の機能を指定するための共有ボタンが押下された場合に、前記第２の分類情報に基づき、前記登録処理により登録された機能情報をユーザに対して提供する提供手段、
    として機能させるためのプログラム。

Images