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

Abstract

【課題】Ｗｅｂ Ｉｎｔｅｎｔｓの仕組みにおいて、ユーザに対して表示されるＷｅｂサービスの表示順序は特定のルールに従っており、必ずしもユーザにとって利用しやすい表示順序となっていない。【解決手段】データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末であって、前記中継機能による前記サービスが提供する機能を呼び出すための機能情報の受信に伴い、当該機能情報の提供に関連する参考情報を受信する受信手段と、前記受信した機能情報の登録処理を実行する登録手段と、前記参考情報に基づく表示順序及び表示配置の少なくとも何れかに従い、前記登録処理により登録された機能情報をユーザに対して提供する提供手段と、を有する。【選択図】 図９

Description

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

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

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

また、従来技術として、特許文献１に記載されるような技術がある。これによれば、ユーザにより選択された連携先アプリが連携元アプリへ処理できないデータを返すことで発生するエラー回数をカウントする。エラー回数が閾値を超えた連携先アプリは連携時に表示させない。

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

しかしながら、特許文献１は、Ｗｅｂ Ｉｎｔｅｎｔｓなどの仕組みを利用したＷｅｂサービス間連携に関するものではない。また、こういったＷｅｂサービスに限らず、現状のサービス間連携の仕組みにおいて、ユーザに対して表示される選択対象のサービスの表示の順序や配置などは、必ずしもユーザにとって利用しやすいものになっていないという課題がある。

本発明では、Ｗｅｂサービスを含むサービス間連携の仕組みを用いる際に、特定の条件に従い、ユーザにとって利用しやすいサービスの表示手法の提供を可能することを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末であって、前記中継機能による前記サービスが提供する機能を呼び出すための機能情報の受信に伴い、当該機能情報の提供に関連する参考情報を受信する受信手段と、前記受信した機能情報の登録処理を実行する登録手段と、前記参考情報に基づく表示順序及び表示配置の少なくとも何れかに従い、前記登録処理により登録された機能情報をユーザに対して提供する提供手段と、を有する。

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

Ｗｅｂ Ｉｎｔｅｎｔｓの全体構成図。 Ｗｅｂ Ｉｎｔｅｎｔｓの基本的な動作を示したシーケンス図。 Ｗｅｂ Ｉｎｔｅｎｔｓサービスが持つ登録用マークアップの一例を示す図。 Ｗｅｂ Ｉｎｔｅｎｔｓクライアントが生成するＩｎｔｅｎｔ処理要求の一例を示す図。 第一の実施形態に係るシステム構成図。 第一の実施形態に係るモバイル端末とデバイスのハードウェア構成図。 第一の実施形態に係るモバイル端末のソフトウェア構成図。 第一の実施形態に係るモバイル端末が保持するテーブルおよび応答例を示す図。 第一の実施形態に係るモバイル端末がデバイスへＩｎｔｅｎｔｓを発行する際のシーケンス図。 第一の実施形態に係るモバイル端末の画面例を示す図。 第一の実施形態に係るモバイル端末ＯＳ部のサービス表示処理を示したフローチャート。 第一の実施形態に係るモバイル端末ＯＳ部の画面例を示す図。 第一の実施形態に係るモバイル端末ＯＳ部の画面例を示す図。 第二の実施形態に係るシステム構成図。 第二の実施形態に係るハードウェア構成図。 第二の実施形態に係るソフトウェア構成図。 第二の実施形態に係るモバイル端末が保持するテーブルを示す図。 第二の実施形態に係るモバイル端末がＷｅｂ ＩｎｔｅｎｔｓサービスへＩｎｔｅｎｔｓを発行する際のシーケンス図。 第二の実施形態に係るモバイル端末の画面例を示す図。 第二の実施形態に係るモバイル端末ＯＳ部のサービス表示処理を示すフローチャート。 第二の実施形態に係るモバイル端末ＯＳ部の画面例を示す図。 第三の実施形態に係るモバイル端末が保持するテーブルを示す図。 第三の実施形態に係るモバイル端末がＷｅｂ ＩｎｔｅｎｔｓサービスへＩｎｔｅｎｔｓを発行する際のシーケンス図。 第三の実施形態に係るモバイル端末ＯＳ部のサービス表示処理を示すフローチャート。 第三の実施形態に係るモバイル端末ＯＳ部の画面例を示す図。 第四の実施形態に係るモバイル端末ＯＳ部のサービス表示処理を示すフローチャート。

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

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

図１は、Ｗｅｂ Ｉｎｔｅｎｔｓの全体構成を示す図である。Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３は、Ｉｎｔｅｎｔｓ技術を利用してサービスや機能を提供する。Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３が提供するサービスを利用する。ＵＡ（ユーザエージェント）１０２は、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１からの要求をＷｅｂ Ｉｎｔｅｎｔｓサービス１０３に渡す。また、ＵＡ１０２は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３からの結果をＷｅｂ Ｉｎｔｅｎｔｓクライアント１０１に渡す役割を担う。この役割により、ＵＡ１０２は、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１とＷｅｂ Ｉｎｔｅｎｔｓサービス１０３との間の各種データの受け渡しのための中継機能を備える。

ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）サイトの「いいね」「チェック」「シェア」といったソーシャルボタンをＷｅｂ Ｉｎｔｅｎｔｓの仕組みで例えると、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１は、ボタンを配置しているサイトとなる。ＵＡ１０２はウェブブラウザ（以下、ブラウザ）に相当し、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３は「いいね」などの投稿先サービスに相当する。また、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３が機能を提供するにあたって、ユーザ認証やユーザによる操作が必要な場合、ＵＡ１０２上でユーザが操作を行う。

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

また、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３については、上記の投稿先サービスのようなインターネット上のサービス提供者以外にも、例えば情報処理端末が内蔵するカメラや、インストールされているアプリケーションも含まれる。また、ネットワークで接続されるプリンター、スキャナ、ネットワークカメラなどの周辺機器や、冷蔵庫やテレビといった家電製品などもサービス提供者になり得る。

［基本シーケンス］
図２は、Ｗｅｂ Ｉｎｔｅｎｔｓを利用したサービス提供に関する基本動作を説明するためのシーケンス図である。Ｓ２０１にて、ＵＡ１０２は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３の登録処理として、ユーザの操作によりＷｅｂ Ｉｎｔｅｎｔｓサービス１０３にアクセスする。Ｓ２０２にて、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３は、提供するサービスをＵＡ１０２に登録してもらうための登録用マークアップを含むＨＴＭＬ応答を作成し、ＵＡ１０２に返信する。

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

図３に示す例の場合、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３があらゆるフォーマットの画像データを“ｓｈａｒｅ（共有）”できることを示している。また、その際の接続先は“ｓｈａｒｅ．ｈｔｍｌ”であり、タイトルは“Ｓｈａｒｅ ｉｍａｇｅ ｕｓｉｎｇ ｅ−ｍａｉｌ”となる。また、サービスの接続先は、別ウィンドウで表示する（“ｗｉｎｄｏｗ”）ことを示している。

ＵＡ１０２は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３からのＨＴＭＬ応答を受信すると、ユーザに対してＷｅｂ Ｉｎｔｅｎｔｓサービス１０３をＵＡ１０２に登録するか否か確認する。例えば、ＵＡ１０２がブラウザであれば、ポップアップウィンドウを表示させユーザに選択を促す。ユーザがこのＷｅｂ Ｉｎｔｅｎｔｓサービスの登録を選択すると、ＵＡ１０２はこれを内部に記憶する。

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

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

Ｓ２０５にて、ＵＡ１０２は、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１から、ＨＴＭＬ応答を受け取り、表示する。Ｓ２０６にて、ＵＡ１０２は、ユーザにより画面上の「共有」ボタン（不図示）が押下されると、上述したようにＷｅｂ Ｉｎｔｅｎｔｓ起動用のＥＣＭＡＳｃｒｉｐｔ（図４）が実行され、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１が持つ画像データを取得する。また、「共有」ボタンの押下により、ＵＡ１０２に登録されているＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の一覧が表示される。

ユーザにより一覧からＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が選択されると、Ｓ２０７にて、ＵＡ１０２は、選択されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３へ要求を送信する。その際、ＵＡ１０２は、送信データに、図４のＥＣＭＡＳｃｒｉｐｔが作成したＩｎｔｅｎｔオブジェクトの内容を含める。Ｓ２０８にて、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３は、要求からＩｎｔｅｎｔオブジェクトを取り出し、ＵＡ１０２を介してユーザと相互作用しながら、選択されたサービス（ここでは画像の「共有」）の利用を実現する。

例えば、ユーザが画像および共有ボタンが設けられたＷｅｂサイトを訪れ、その共有ボタンを押下すると、ポップアップウィンドウにサービス一覧が表示される。そこでＷｅｂメールサービスを選択したとすると、画像データを添付した新規メールが作成され、ユーザにより電子メールを送信することが出来る。

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

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

［システム構成］
図５は、本実施形態に係るＷｅｂ Ｉｎｔｅｎｔｓクライアント１０１、ＵＡ１０２、およびＷｅｂ Ｉｎｔｅｎｔｓサービス１０３がインターネットを介して接続された関係を示す図である。図５において、情報処理端末であるモバイル端末５０１は、上述したＷｅｂ Ｉｎｔｅｎｔｓクライアント１０１とＵＡ１０２を含むモバイル端末である。前述では、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１は一般的なＷｅｂサイトと説明したが、モバイル端末５０１にインストールされているローカルアプリケーションもこれに相当する。例えば、コンテンツ表示・編集アプリ、ＳＮＳアプリ、ストレージアプリ、メールアプリなどがこれに相当する。また、ＵＡ１０２についてもＰＣ上のブラウザと説明したが、モバイル端末５０１内のブラウザやＯＳ部分もこれに相当する。本実施形態では、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１はモバイル端末５０１内のアプリケーション部分とし、ＵＡ１０２はＯＳ部分と想定して説明する。

デバイス５０２は、上述したＷｅｂ Ｉｎｔｅｎｔｓサービス１０３に相当する。本実施形態では、対象ドキュメントを印刷、保存するなどの機能・サービスを提供する画像形成装置を想定する。モバイル端末５０１およびデバイス５０２はネットワーク５０３を介して相互に接続されている。

なお、本実施形態において、通信プロトコルは、ＨＴＴＰやＨＴＴＰＳなどのプロトコルを想定しているが、これに限定するものではない。例えば、図５の例において、モバイル端末５０１およびデバイス５０２は、ＨＴＴＰＳを利用してデータの送受信を行っている。また、ネットワーク５０３による通信環境における接続形態は有線／無線を問わない。また、図５ではモバイル端末５０１とデバイス５０２がそれぞれ一台のみ示されているが、これに限定するものではなく、複数の装置が含まれてもよい。

［ハードウェア構成］
図６（Ａ）は、本実施形態に係るモバイル端末５０１のハードウェア構成を示す図である。ＲＯＭ６０３は内部記憶装置であり、ＯＳ、通話もしくはデータ通信を制御するアプリケーション、モバイル端末５０１の再起動後も保持しておく必要のある各種動作モード設定などのデータが格納されている。また、ＲＯＭ６０３には、モバイル端末５０１のスペックや開発ベンダ情報などの端末情報も記憶される。

モバイル端末５０１は、上記アプリケーションや、ＯＳなどのプログラムを実行するＣＰＵ６０１を備え、内部バス６０６を介して各制御部を総括的に制御する。ＲＡＭ６０２は、プログラムを実行するためのメモリエリアである。また、ブラウザがＷｅｂサーバから取得してきたＷｅｂページデータやＷｅｂサービスにアクセスするための認証情報などを一時記憶するためのメモリでもある。記憶装置６０４は、取り外し可能な不揮発性の外部記憶装置であり、稼働ログ、コンテンツ（写真、動画、文書など）の他、ＲＯＭ６１３に格納されている各種データを保存することも可能である。

ネットワークＩ／Ｆ６０５は、無線ＬＡＮに参加するための無線ＬＡＮ通信部と、通信キャリアが提供するネットワーク５０３に参加するための携帯電話データ通信部の通信制御を行う。内部バス６０６には、ＣＰＵ６０１、ＲＡＭ６０２、ＲＯＭ６０３、記憶装置６０４、ネットワークＩ／Ｆ６０５、及び入出力Ｉ／Ｆ６０７が接続されている。入出力Ｉ／Ｆ６０７は、例えば、マイク・スピーカ、ディスプレイ、タッチパネルなどにより音声データの入出力、ユーザからの指示制御をするためのＩ／Ｆである。これによりユーザは、声によるモバイル端末の制御、電話、各アプリケーションの起動などの指示をモバイル端末５０１に対して行うことが可能となる。

図６（Ｂ）は、本実施形態に係るデバイス５０２のハードウェア構成を示す図である。デバイス５０２は例えば、デジタル複合機、ファクシミリ装置、レーザービームプリンタ、インクジェットプリンタ、スキャナ装置などの画像形成装置に適用することができる。デバイス５０２は、ＣＰＵ６１１、ＲＡＭ６１２、ＲＯＭ６１３、記憶装置６１４、ネットワークＩ／Ｆ６１５、内部バス６１６、デバイス制御６１７、定着器などを含む印刷部６１８で構成される。

ＣＰＵ６１１は、ＲＯＭ６１３に格納されているプログラムを実行することにより、内部バス６１６を介して各デバイスを総括的に制御する。ＲＯＭ６１３にはデバイス５０２が出荷される地域を意味する仕向け情報（リージョン）も格納されている。この仕向け情報に従って入出力装置６２０で表示する言語は決定される。ＲＡＭ６１２は、ＣＰＵ６１１のメモリやワークエリアとして機能する。ネットワークＩ／Ｆ６１５は、ネットワーク５０３を介して、外部のネットワーク機器あるいはパーソナルコンピュータ（ＰＣ）と肩方向または双方向にデータをやり取りし、デバイス制御６１７は印刷部６１８を制御する。

ＣＰＵ６１１は、ＲＡＭ６１２やＲＯＭ６１３を用いてプログラムの実行処理を行うとともに、記憶装置６１４等の記録媒体に画像データを記録する処理を行う。記憶装置６１４は、外部記憶装置として機能し、画像データ等を記憶するほか、ＲＡＭ６１２に代わって、上記のカウンタ情報、システム情報及び監視情報を保存することも可能である。入出力装置６２０は、ユーザからの入力（スキャン、ボタン入力など）を受け付け、入出力Ｉ／Ｆ６１９によって各処理部へその旨を伝える。

［ソフトウェア構成］
図７（Ａ）は、モバイル端末５０１のソフトウェア構成の一例を示す図である。モバイル端末５０１において、アプリケーション部７００および各処理部は、モバイル端末５０１の記憶装置６０４等に保存されたファイルとして存在する。これらは実行時にＯＳや他の処理部によってＲＡＭ６０２にロードされ実行されるプログラムモジュールである。

アプリケーション部７００は、例えばコンテンツ表示・編集アプリ、ＳＮＳアプリ、ストレージアプリ、メールアプリなどを制御するソフトウェアモジュール群である。アプリケーション部７００は、Ｉｎｔｅｎｔ処理要求部７０１、表示処理要求部７０２、コンテンツ管理部７０３、及びアプリケーション処理部を含む。Ｉｎｔｅｎｔ処理要求部７０１は、ＯＳ部７１０に対してＩｎｔｅｎｔの処理要求を生成する。表示処理要求部７０２は、アプリケーションの表示方法、モバイル端末５０１の画面に対象コンテンツの表示方法をＯＳ部７１０に要求する。コンテンツ管理部７０３は、必要に応じてデータベースサービス部７２０を介して記憶装置６０４からコンテンツを取得したり、格納したりする。アプリケーション処理部７０４は、各種アプリケーションの処理を実行する。

ＯＳ部７１０は、Ｗｉｎｄｏｗｓ（登録商標）、Ａｎｄｏｒｏｉｄ、ｉＯＳ、Ｔｉｚｅｎなど一般的なオペレーティングシステムである。表示部７１１は、表示処理要求部７０２から要求された表示方法を受け取り、その内容に応じて表示する。Ｉｎｔｅｎｔ処理部７１２は、Ｉｎｔｅｎｔ処理要求部７０１からのＩｎｔｅｎｔ処理要求を受け、その内容に応じて他の処理部に処理要求を行う。また、Ｉｎｔｅｎｔ処理部７１２は、ユーザによって選択されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３に対してＩｎｔｅｎｔ処理を要求する。サービス管理部７１３は、データベースサービス部７２０を介して記憶装置６０４から登録済みのＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を管理するテーブルから情報を取得したり、格納したりする。通信部７１４は、他の処理部から要求を受けて、ネットワークＩ／Ｆ６０５を介して通信制御を行う。データベースサービス部７２０は、他の処理部からの要求に応じて、記憶装置６０４等へのコンテンツの格納と取り出しを行う。

図７（Ｂ）は、デバイス５０２のソフトウェア（処理部）構成の一例を示す図である。デバイス５０２は、Ｉｎｔｅｎｔ処理部７５０、表示部７５１、デバイス情報制御部７５２、画像形成部７５３、通信部７５４、記憶部７５５、及び操作部７５６を含む。Ｉｎｔｅｎｔ処理部７５０は、モバイル端末５０１から送られたＩｎｔｅｎｔオブジェクトを解析し、要求に応じて他の処理部へ処理を指示する。表示部７５１は、ユーザに対してデバイス５０２の状態情報、設定情報などを表示する。デバイス情報制御部７５２は、デバイス５０２の印刷制御や異常状態の管理などを行うとともに、カウンタ情報の管理や通知情報の管理も行う。また、デバイス情報制御部７５２は、色味調整や印刷モード、その他機能の設定に関する制御も行う。

画像形成部７５３は、印刷データを生成し出力する機能を有する。通信部７５４は、ネットワーク５０３に接続され、デバイス５０２が、ネットワーク５０３上の他の情報機器と相互通信するために用いられる。記憶部７５５は、ＲＡＭ６１２、ＲＯＭ６１３、記憶装置６１４の記憶領域と情報のやり取りを行う。また、記憶部７５５は、デバイス５０２の動作履歴や様々な異常状態を表すデータなども記憶する。操作部７５６は、入出力Ｉ／Ｆ６１９、入出力装置６２０を介して、ユーザによる印刷指示をはじめとするデバイス５０２に対する操作指示を可能とする。

［テーブル構成］
図８（Ａ）は、モバイル端末５０１の端末情報を管理するために保持する端末情報テーブルの一例である。端末情報テーブル８００は、例えばモバイル端末５０１内のＲＯＭ６０３で保持され、データベースサービス部７２０によって制御される。ｉｔｅｍ８０１は、端末情報の各項目を示す情報である。端末情報とは例えば、モデル名、ＯＳのバージョン、シリアル番号、ベンダ名などである。ｖａｌｕｅ８０２は、端末情報の各項目の値を示す。

図８（Ｂ）は、モバイル端末５０１のＯＳ部７１０が、登録処理によって自身に登録されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を管理するために保持する登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブルの一例である。登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル８１０は、モバイル端末５０１内の記憶装置６０４で保持され、データベースサービス部７２０によって制御される。Ｓｅｒｖｉｃｅ ＩＤ８１１は、ＯＳ部７１０内のサービス管理部７１３がＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を一意に識別するためのＩＤ（識別情報）である。ａｃｔｉｏｎ８１２は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３がどのような機能、サービスを提供するかを示す情報である。

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

ｖｅｎｄｏｒ８１７は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３の開発ベンダを示す。ｅｘｔｅｎｄ８１８は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３に関する詳細情報を示す。ｖｅｎｄｏｒ８１７およびｅｘｔｅｎｄ８１８は、ＵＡ１０２がＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を登録する際にＷｅｂ Ｉｎｔｅｎｔｓサービス１０３から提供される情報である。

図８（Ｃ）は、ＵＡ１０２がＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を登録する際にＷｅｂ Ｉｎｔｅｎｔｓサービス１０３から送信されるＨＴＭＬ応答の一例である。図２のＳ２０２にて送信される情報に相当する。なお、ここでは、モバイル端末５０１がデバイス５０２をＷｅｂ Ｉｎｔｅｎｔｓサービス１０３として登録する際にｉｎｔｅｎｔタグ内に記述されたｖｅｎｄｏｒ属性、ｅｘｔｅｎｄ属性のパラメータとしてベンダ情報および詳細情報を取得する例を示した。しかし、これらの情報を取得する方法は、これに限るものではない。例えば、図３に示したような既存のｉｎｔｅｎｔタグを拡張することなく、既存のｔｉｔｌｅ属性やｈｒｅｆ属性といったタグに含まれる情報の一部として、ベンダ情報や詳細情報を含めてもよい。または、ｉｎｔｅｎｔタグが記載されている部分以外の箇所、例えば、ｉｎｔｅｎｔタグの取得時のＨＴＴＰのヘッダ部分に含めるといったことも可能である。あるいは、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３の登録時に異なるセッションにおいて、または、登録前後の異なるタイミングの通信でＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の関連情報として、ベンダ情報や詳細情報を取得するようにしてもよい。Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３が登録されることにより、ＨＴＭＬ応答として取得した各種情報が図８（Ｂ）に示す登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル８１０にて管理されることとなる。

図８（Ｄ）は、モバイル端末５０１のＯＳ部７１０がＷｅｂ Ｉｎｔｅｎｔｓサービス１０３に関するｅｘｔｅｎｄ８１８を解析するために保持する詳細情報テーブルの一例である。詳細情報テーブル８２０は、モバイル端末５０１内の記憶装置６０４で保持され、データベースサービス部７２０によって制御される。ｅｘｔｅｎｄ８２１、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３に関する詳細情報を示し、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル８１０のｅｘｔｅｎｄ８１８に設定される値に対応する。ｆｕｎｃｔｉｏｎ８２２は、ｅｘｔｅｎｄ８２１の値の意味を示す。

ＯＳ部７１０は、端末情報テーブル８００と詳細情報テーブル８２０を参照することにより、モバイル端末５０１とＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の開発ベンダが同一であることを確認する。同一ベンダであった場合、ＯＳ部７１０はＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の詳細情報を解析することができる。本実施形態の場合、例えば、Ｓｅｒｖｉｃｅ ＩＤ８１１が「３」の印刷サービス「ｂｂｂ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ」は、カラー印刷（“ｃｌ”）、両面印刷（“ｄｕｐｌｅｘ”）、ホチキス止め（“ｓｔａｐｌｅ”）の機能を提供することが可能であることを意味する。

詳細情報として設定されるｅｘｔｅｎｄ８１８の値は開発ベンダによって異なる。しかし、本実施形態のようにモバイル端末５０１の開発ベンダとＷｅｂ Ｉｎｔｅｎｔｓサービスの提供元が同一であれば、モバイル端末５０１側でｅｘｔｅｎｄ８１８の内容（例えば、提供可能な機能情報）を把握することが可能となる。

［処理要求発行シーケンス］
図９は、モバイル端末５０１からデバイス５０２に対してＩｎｔｅｎｔｓの処理要求を発行する際のシーケンス図である。本実施形態ではモバイル端末５０１内のアプリケーションによりコンテンツを表示し、その後、デバイス５０２に対して印刷を要求する処理を説明する。ここではモバイル端末５０１にＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が既に登録されている状態で、アプリケーション部７００によりコンテンツへの処理を行うところから処理の説明をする。

先ず、ユーザ操作によってアプリケーションが起動され、対象コンテンツが表示される。その後、再びユーザ操作によりアプリケーションのメニューボタン（不図示）が押下される。図１０（Ａ）は、モバイル端末５０１のアプリケーション部７００にてコンテンツ１０００が表示されている状態を示す。

Ｓ９０１にて、アプリケーション部７００は、メニューボタンが押下されたことを検知し、メニューを表示する。図１０（Ｂ）は、メニューボタンが押下された後、メニュー１００１が表示された状態を示す。その後、ユーザにより「印刷」ボタン１００２が選択されると、Ｓ９０２にて、アプリケーション部７００は、Ｉｎｔｅｎｔ処理要求を生成する。生成されるＩｎｔｅｎｔ処理要求には、対象コンテンツのｔｙｐｅ、パス、及び選択されたメニューのａｃｔｉｏｎが含まれる。本実施形態は、対象画像を印刷することを想定しているため、ｔｙｐｅは“ｉｍａｇｅ／＊”が指定され、ａｃｔｉｏｎは“ｐｒｉｎｔ”が指定される。ここで記号“＊”は、任意の文字を意味する。Ｓ９０３にて、アプリケーション部７００は、生成したＩｎｔｅｎｔ処理要求をＯＳ部７１０に対して送信する。これは、図２にて示したＳ２０４および図４に相当する。ＯＳ部７１０は、アプリケーション部７００からＩｎｔｅｎｔ処理要求を受け取ると、Ｓ９０４にてサービス表示処理を行う。

Ｓ９０４のサービス表示処理について、図１１のフローチャートを用いて詳細に説明する。Ｓ１１０１にて、ＯＳ部７１０は、アプリケーション部７００が生成したＩｎｔｅｎｔ処理要求を受信する。Ｓ１１０２にて、ＯＳ部７１０は、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル８１０を参照する。Ｓ１１０３にて、ＯＳ部７１０は、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル８１０の内容と、要求内容を照らし合わせ、対象のＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を抽出する。ここでは、ｔｙｐｅが“ｉｍａｇｅ／＊”であり、ａｃｔｉｏｎが“ｐｒｉｎｔ”であるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が対象となる。図８（Ｂ）に示す例では、具体的には、Ｓｅｒｖｉｃｅ ＩＤ８１１が、「１」、「３」、「４」のＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の情報が抽出される。

Ｓ１１０４にて、ＯＳ部７１０は、Ｓ１１０３の抽出処理で対象のサービスが存在したか否かを確認する。Ｓ１１０４の確認の結果、対象サービスが存在しない場合（Ｓ１１０４にてＮＯ）、Ｓ１１１０にてＯＳ部７１０は、エラーメッセージを表示し、サービス表示処理を終了する。図１２（Ａ）は、その際のメッセージ表示画面１２０１の例を示す。一方、Ｓ１１０４の確認の結果、対象サービスが存在する場合（Ｓ１１０４にてＹＥＳ）、Ｓ１１０５にてＯＳ部７１０は、端末情報テーブル８００を参照し、ベンダ情報（ｖｅｎｄｏｒの値）を確認する。

Ｓ１１０６にて、ＯＳ部７１０は、Ｓ１１０３で抽出したＷｅｂ Ｉｎｔｅｎｔｓサービス１０３のｖｅｎｄｏｒ８１７と、Ｓ１１０５で確認したモバイル端末５０１のｖｅｎｄｏｒ情報を比較する。そして、ＯＳ部７１０は、モバイル端末５０１の開発ベンダと同一のベンダであるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が登録されて存在するか確認する。ここでは、モバイル端末５０１の開発ベンダは端末情報テーブル８００より「ＢＢＢ」である。一方、Ｓ１１０３で抽出されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３のうち、ｖｅｎｄｏｒ８１７が「ＢＢＢ」であるものはＳｅｒｖｉｃｅ ＩＤ８１１が「３」の“ｂｂｂ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ”となる。

Ｓ１１０６の確認の結果、対象のＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が存在する場合（Ｓ１１０６にてＹＥＳ）、Ｓ１１０７にてＯＳ部７１０は、対象となったＷｅｂ Ｉｎｔｅｎｔｓサービス１０３にｅｘｔｅｎｄ８１８の情報が存在するか否かを確認する。Ｓ１１０７の確認の結果、対象サービスに詳細情報が存在する場合（Ｓ１１０７にてＹＥＳ）、Ｓ１１０８にてＯＳ部７１０は、詳細情報テーブル８２０を用いてｅｘｔｅｎｄ８１８の詳細情報を解析する。

Ｓ１１０９にて、ＯＳ部７１０は、Ｓ１１０５にて対象となったＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を上位とし、Ｓ１１０３にて抽出されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の表示順序を決定する。また、詳細情報が存在するサービスを上位に配置するようにしてもよい。ここでの表示順序の上位とは、例えば、抽出されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３をリスト形式にて表示する際によりユーザが認識しやすい上位に位置することを意味する。そして、ＯＳ部７１０は、Ｓ１１０８で解析した詳細情報と共に表示する。上位表示の対象となるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が複数存在する場合、その中で一定のルールに従って表示順位が決定する。ここでの一定のルールとは、アルファベット順、ＪＩＳコード順などの一般的なソートルールである。これらのルールは予め定義され、ＯＳ部７１０にて管理されているものとする。

Ｓ１１０６の確認の結果、対象のＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が存在しない場合（Ｓ１１０６にてＮＯ）、Ｓ１１０９にてＯＳ部７１０は、一定のルールに従って表示順序を決定し、表示を行う。また、Ｓ１１０７の確認の結果、対象のＷｅｂ Ｉｎｔｅｎｔｓサービス１０３に詳細情報が存在しない場合も（Ｓ１１０７にてＮＯ）、Ｓ１１０９にてＯＳ部７１０は、一定のルールに従って表示順序を決定し、表示を行う。

図１２（Ｂ）は、その際に表示されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３のリスト１２０２を示す。ここでは、抽出されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３として印刷サービスが３つあるが、モバイル端末５０１の開発ベンダと同一ベンダで、詳細情報を持つ「ｂｂｂ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ」がリスト１２０２の最上位に表示される。また、その際、デバイス５０２がカラー・両面印刷、ホチキス止め機能を持つことがわかるように詳細情報１２０３がリスト１２０２に表示される。そして、本処理フローを終了し、図９のシーケンスに戻る。

その後、ユーザによってＯＳ部７１０が表示したリスト１２０２より、あるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が選択されると、Ｓ９０５にてＯＳ部７１０は、選択されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３に対してＩｎｔｅｎｔを発行する。本実施形態では、モバイル端末５０１のＯＳ部７１０がデバイス５０２に対して処理を要求する。その際、ＯＳ部７１０は、デバイス５０２への送信データにＳ９０３でアプリケーション部７００から送信された要求内容とコンテンツを含める。

Ｓ９０６にて、デバイス５０２のＩｎｔｅｎｔ処理部７５０は、Ｓ９０５で発行された要求からＩｎｔｅｎｔオブジェクトを取り出して解析し、Ｉｎｔｅｎｔの処理を開始する。本実施形態ではデバイス５０２のＩｎｔｅｎｔ処理部７５０は、モバイル端末５０１のＯＳ部７１０を介してユーザと相互作用しながら、Ｉｎｔｅｎｔオブジェクトに含まれるコンテンツを印刷するサービスを提供する。Ｓ９０７にて、デバイス５０２は、Ｉｎｔｅｎｔの処理が終了すると、処理結果をＯＳ部７１０に通知する。

Ｓ９０８にて、ＯＳ部７１０は、デバイス５０２から通知されたＩｎｔｅｎｔ処理結果を画面に表示するなどして、ユーザに結果を知らせる。図１２（Ｃ）は、ＯＳ部７１０が表示する処理結果の結果表示画面１２０４の例を示す。

本実施形態では、開発ベンダの情報（ｖｅｎｄｏｒ８１７）や詳細情報（ｅｘｔｅｎｄ８１８）などを参考情報として表示するサービスの表示順位や表示内容、配置を決定したがこれに限定するものではない。例えば、Ｓ９０４のサービス表示処理において、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３の状態を考慮して表示順位を決定することも可能である。本実施形態のようにモバイル端末５０１と対象のＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の開発ベンダが同一であれば、モバイル端末５０１はＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の状態情報を取得することが可能である。

例えば、あるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の状態情報をモバイル端末５０１が取得し、そのＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が機能していない状態（障害などにより）だと認識したとする。その場合、ＯＳ部７１０は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３のリストを表示させる際、該当サービスの状態情報を表示させるようにしてもよい（図１３（Ａ）のアイコン１３０１参照）。また、状態情報を表示させ、リストの下位に表示させるようにしてもよい（図１３（Ｂ）のリスト１３０２参照）。また、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３の開発ベンダ情報（登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル８１０のｖｅｎｄｏｒ８１７）が不明な場合は、一覧に表示させないようにしてもよい。

本実施形態では、モバイル端末５０１のＯＳ部７１０がＷｅｂ Ｉｎｔｅｎｔｓサービス１０３のベンダ情報や、詳細情報から、表示順序を決定する仕組みについて説明した。以上により、モバイル端末５０１はユーザにとって利便性の高いＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の表示を提供することが可能となる。

また、本実施形態では、Ｗｅｂ Ｉｎｔｅｎｔｓクライアントはモバイル端末５０１に含まれているものとして説明した。しかし、前述した通り、一般的なＷｅｂサイトに置き換えても実現可能である。同様にＵＡをモバイル端末内のＯＳ部として説明したが、ＰＣ上のブラウザに置き換えることも可能である。

また、本発明は、表示順序以外にも、ベンダ情報や、詳細情報などの特定の条件に従い、表示配置の方法を切り替えることで、ユーザにとって利便性の高いサービスの提供方法を実現することもできる。具体的には、特定のＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の選択領域を拡大表示する、他のＷｅｂ Ｉｎｔｅｎｔｓサービス１０３よりも画面上で相対的に上位階層に表示するといった配置の切り替えが行える。なお、以降に説明する実施形態についても、表示順序以外に、ユーザの利便性を考慮して、このような表示配置の方法を切り替えることも可能である。

また、本実施形態において、各サーバや装置の構成、ソフトモジュールの構成、複数サービスを同時に利用する処理フローを示してきたが、これらは一例であり、これに限るものではない。

＜第二の実施形態＞
第二の実施形態では、モバイル端末における各Ｗｅｂ Ｉｎｔｅｎｔｓサービスアカウントのログイン状態によって、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３の表示順序を決定する方法について説明する。

［システム構成］
図１４は、本実施形態に係るＷｅｂ Ｉｎｔｅｎｔｓクライアント１０１、ＵＡ１０２、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３がインターネットを介して接続された関係を示す図である。図１４において、モバイル端末１４０１は、第一の実施形態と同様にＷｅｂ Ｉｎｔｅｎｔｓクライアント１０１とＵＡ１０２を含む。本実施形態でも、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１はモバイル端末１４０１内のアプリケーション部分とし、ＵＡ１０２はＯＳ部分と想定して説明する。Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２は、上述したＷｅｂ Ｉｎｔｅｎｔｓサービス１０３に相当し、ここでは画像を編集、保存、またはＳＮＳへ投稿するなどの機能、サービスを提供するＷｅｂサイト（Ｗｅｂアプリケーション）を表す汎用コンピュータである。ネットワーク１４０３は、第一の実施形態のネットワーク５０３と同様である。

［ハードウェア構成］
本実施形態に係るモバイル端末１４０１のハードウェア構成は、第一の実施形態において図６（Ａ）にて説明したものと同様のため、ここでは説明を省略する。

図１５は、本実施形態に係るＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２のハードウェア構成を示す図である。Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２は、ＲＯＭ１５０３に格納されているプログラムを実行するＣＰＵ１５０１を備え、内部バス１５０６を介して各デバイスを総括的に制御する。内部バス１５０６には、ＲＡＭ１５０２、ＲＯＭ１５０３、記憶装置１５０４、ネットワークＩ／Ｆ１５０５、及び入出力Ｉ／Ｆ１５０７が接続される。入出力Ｉ／Ｆ１５０７は、例えばＰＳ２やＵｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ Ｉ／Ｆ）、アナログやデジタルのディスプレイＩ／Ｆを備える。入出力装置１５０８は、キーボードやマウス、ＣＲＴや液晶ディスプレイであり、ユーザは入出力Ｉ／Ｆ１５０７を介してＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２と接続することができる。

［ソフトウェア構成］
本実施形態に係るモバイル端末１４０１のソフトウェア構成は、第一の実施形態において図７（Ａ）にて説明したものと同様のため、ここでは説明を省略する。

図１６は、本実施形態に係るＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２のソフトウェア構成を示す図である。Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２において、Ｗｅｂアプリケーション１６５０および各処理部は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２の記憶装置１５０４に保存されたファイルとして存在する。これらは実行時にＯＳやその各処理部を利用する他の処理部によってＲＡＭ１５０２にロードされ実行されるプログラムモジュールである。

Ｗｅｂアプリケーション１６５０は、例えば画像データなどのコンテンツを保管するストレージ機能や、コンテンツの編集などを提供するアプリケーションである。Ｗｅｂアプリケーション１６５０は、ＨＴＴＰリクエストに応答して処理を実行するプログラムとして実装される。Ｗｅｂアプリケーション１６５０は、Ｉｎｔｅｎｔ処理部１６５１、プレゼンテーション部１６５２、及びコンテンツ処理部１６５３を含む。

Ｉｎｔｅｎｔ処理部１６５１は、Ｉｎｔｅｎｔオブジェクトを解析し、モバイル端末１４０１からの要求に応じて他の処理部へ処理を指示する。プレゼンテーション部１６５２は、通信部１６５４を介して受け取ったページ取得要求などに応じてＨＴＭＬ文書を作成する。コンテンツ処理部１６５３は、Ｉｎｔｅｎｔ処理部１６５１からの指示を受けて、コンテンツに対して処理をする。コンテンツ処理部１６５３は、例えば、画像データを編集したり、要求に応じてデータベースサービス部１６５５を介して記憶装置１５０４へコンテンツを格納したりする。データベースサービス部１６５５は、他の処理部からの要求に応じて、データの格納と取り出しを行う。また、データベースサービス部１６５５は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２と別の機器上にあってもよい。

［テーブル構成］
図１７（Ａ）は、モバイル端末１４０１のＯＳ部７１０が自身に登録されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を管理するために保持する登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブルの一例である。登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル１７１０は、モバイル端末１４０１内の記憶装置６０４で保持され、データベースサービス部７２０によって制御される。登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル１７１０に含まれる１７１１〜１７１６は、第一の実施形態で説明した８１１〜８１６と同じであるため、説明は省略する。ａｃｃｏｕｎｔ ｔｙｐｅ１７１７は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３を利用する際に必要となるアカウント情報である。

図１７（Ｂ）は、モバイル端末１４０１のＯＳ部７１０が保持するアカウント管理テーブルの一例である。アカウント管理テーブル１７２０にて管理されるアカウントは、ユーザがモバイル端末１４０１を介して、様々なサービスにアクセスする際に利用される。ｕｓｅｒ ｉｄ１７２１は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３を利用する際のユーザＩＤである。ｐａｓｓｗｐｒｄ１７２２は、ｕｓｅｒ ｉｄ１７２１に対するパスワードである。ｓｔａｔｕｓ１７２３は、アカウントのログイン状態を意味し、モバイル端末１４０１において各アカウントのログイン状態を意味する。ａｃｃｏｕｎｔ ｔｙｐｅ１７２４は、どのＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２のアカウントであるかを表している。アカウント管理テーブル１７２０のａｃｃｏｕｎｔ ｔｙｐｅ１７２４は、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル１７１０のａｃｃｏｕｎｔ ｔｙｐｅ１７１７にて示される値に対応する。

本実施形態では、Ｓｅｒｖｉｃｅ ＩＤが「２」の「ｂｂｂ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ」に対して、ユーザはモバイル端末５０１にてｕｓｅｒ ｉｄ「ｂ」でログイン状態にあることを意味している。この場合、ａｃｃｏｕｎｔ ｔｙｐｅが同じ「ＢＢＢ」である「ｂｂｂ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ」、「ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅ」を利用する際に改めて認証処理をする必要がなくなる。

［処理要求発行シーケンス］
図１８は、モバイル端末１４０１からＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２に対してＩｎｔｅｎｔｓの処理要求を発行する際のシーケンス図である。本実施形態ではモバイル端末１４０１内のアプリケーションによりコンテンツを表示し、その後、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２に対してコンテンツに対する処理を要求する流れを説明する。ここでは第一の実施形態と同様、モバイル端末１４０１にＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２が登録されている状態で、アプリケーション部７００によりコンテンツへの処理を行うところから処理の説明をする。

先ず、ユーザ操作によってモバイル端末１４０１上で、あるアカウントでログインを行う。本実施形態では、ｕｓｅｒ ｉｄ「ｂ」でログインすることを想定して説明する。Ｓ１８０１にて、アプリケーション部７００はログインを受け、アカウント処理を行う。具体的には、アカウント管理テーブル１７２０のｓｔａｔｕｓ１７２３を、ログイン状態を表す「ｉｎ」に設定する。次に、ユーザ操作によってアプリケーションが起動され、対象コンテンツが表示される。図１９（Ａ）は、アプリケーション部７００にてコンテンツ１９００が表示されている状態を示す。その後、再びユーザ操作によりアプリケーションのメニューボタン（不図示）が押下されると、Ｓ１８０２にてアプリケーション部７００は、メニューボタンが押下されたことを検知し、メニュー画面を表示する。図１９（Ｂ）は、メニューボタンが押下された後、メニュー画面１９０１が表示された状態を示す。

メニュー画面１９０１が表示され、ユーザにより「共有」ボタン１９０２が選択されると、Ｓ１８０３にて、アプリケーション部７００はＩｎｔｅｎｔ処理要求を生成する。生成される処理要求には、対象コンテンツのｔｙｐｅ、パス、及び選択されたメニューのａｃｔｉｏｎが含まれる。本実施形態では、対象コンテンツをＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２に共有（提供）することを想定しているため、ｔｙｐｅは“ｉｍａｇｅ／＊”が指定され、ａｃｔｉｏｎは“ｓｈａｒｅ”が指定される。Ｓ１８０４にて、アプリケーション部７００は、生成したＩｎｔｅｎｔ処理要求をＯＳ部７１０に対して送信する。ＯＳ部７１０は、アプリケーション部７００からＩｎｔｅｎｔ処理要求を受け取ると、Ｓ１８０５でサービス表示処理を行う。

Ｓ１８０５のサービス表示処理について、図２０のフローチャートを用いて説明する。Ｓ２００１にて、ＯＳ部７１０は、アプリケーション部７００が生成したＩｎｔｅｎｔ処理要求を受信する。Ｓ２００２にて、ＯＳ部７１０は、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル１７１０を参照する。Ｓ２００３にて、ＯＳ部７１０は、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル１７１０の内容と、要求内容を照らし合わせ、対象のＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を抽出する。ここでは、ｔｙｐｅが“ｉｍａｇｅ／＊”、ａｃｔｉｏｎが“ｓｈａｒｅ”であるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が対象となる。図１７（Ａ）に示す例では、具体的には、Ｓｅｒｖｉｃｅ ＩＤが「１」、「２」、および「５」のＷｅｂ Ｉｎｔｅｎｔｓサービスが抽出される。

Ｓ２００４にて、ＯＳ部７１０は、Ｓ２００３の抽出処理で対象のサービスが存在したか否かを確認する。Ｓ２００４の確認の結果、対象サービスが存在しない場合（Ｓ２００４にてＮＯ）、Ｓ２００９にてＯＳ部７１０は、エラーメッセージを表示し、サービス表示処理を終了する。図２１（Ａ）はメッセージ表示画面２１０１の例を示す。

Ｓ２００４の確認の結果、対象サービスが存在する場合（Ｓ２００４にてＹＥＳ）、Ｓ２００５にて、ＯＳ部７１０は、アカウント管理テーブル１７２０を参照し、各アカウントのログイン状態を確認する。Ｓ２００６にて、ＯＳ部７１０は、ログイン状態であるアカウントが存在するか否かを確認する。Ｓ２００６の確認の結果、ログイン状態であるアカウントが存在する場合（Ｓ２００６にてＹＥＳ）、Ｓ２００７にて、ＯＳ部７１０は、ログイン状態であるアカウントのａｃｃｏｕｎｔ ｔｙｐｅ１７２４を確認する。そして、ＯＳ部７１０は、そのａｃｃｏｕｎｔ ｔｙｐｅ１７２４の値と同じａｃｃｏｕｎｔ ｔｙｐｅ１７１７を有するＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を抽出し、それを上位としたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３の表示順序を決定する。本実施形態では、ログイン状態であるアカウントｕｓｅｒ ｉｄ「ｂ」のａｃｃｏｕｎｔ ｔｙｐｅ１７２４は「ＢＢＢ」となるので、「ｂｂｂ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ」を上位とした表示順序となる。

図２１（Ｂ）は、その際に表示されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３のリスト２１０２を示す。ここでは、抽出された共有サービスは３つあるが、ログイン状態であるアカウントと同じａｃｃｏｕｎｔ ｔｙｐｅ１７２４の「ｂｂｂ Ｓｈａｒｅ Ｓｅｒｖｉｃｅ」が最上位に表示される。

Ｓ２００６の確認の結果、ログイン状態であるアカウントが存在しない場合（Ｓ２００６にてＮＯ）、Ｓ２００８にて、ＯＳ部７１０は、一定のルールに従って表示順序を決定し、表示を行う。ここでの一定のルールとは、アルファベット順、ＪＩＳコード順などの一般的なソートルールである。ここで用いられるルールは予め定義され、ＯＳ部７１０にて管理されているものとする。上位表示の対象となるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が複数存在した場合、つまり、ａｃｃｏｕｎｔ ｔｙｐｅ１７１７が「ＢＢＢ」であるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が複数存在した場合も一定のルールに従って表示順位を決定する。そして、本処理フローを終了し、図１８のシーケンスに戻る。

その後、ユーザによってＯＳ部７１０が表示したメニューより、あるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が選択されると、Ｓ１８０６にてＯＳ部７１０は、選択されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３に対してＩｎｔｅｎｔを発行する。本実施形態では、モバイル端末１４０１のＯＳ部７１０がＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２に対して処理を要求する。その際、ＯＳ部７１０は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２への送信データにＳ１８０４にてアプリケーション部７００から送信された要求内容とコンテンツを含める。

Ｓ１８０７にて、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２のＩｎｔｅｎｔ処理部１６５１は、Ｓ１８０６にて発行された要求からＩｎｔｅｎｔオブジェクトを取り出して解析し、Ｉｎｔｅｎｔの処理を開始する。本実施形態ではＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２のＩｎｔｅｎｔ処理部１６５１は、モバイル端末１４０１のＯＳ部７１０を介してユーザと相互作用しながら、Ｉｎｔｅｎｔオブジェクトに含まれるコンテンツを共有するサービスを提供する。Ｓ１８０８にて、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２は、Ｉｎｔｅｎｔの処理が終了すると、処理結果をモバイル端末１４０１のＯＳ部７１０に通知する。

Ｓ１８０９にて、ＯＳ部７１０は、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２から通知されたＩｎｔｅｎｔ処理結果を画面に表示するなどして、ユーザに結果を知らせる。図２１（Ｃ）は、ＯＳ部７１０が表示する処理結果の結果表示画面２１０３を示す。

なお、本実施形態ではログイン状態であるアカウントが１つであることを想定して説明したが、ログイン状態であるアカウントが複数存在した場合は所定のルールに従って、表示順序を決定するようにしてもよい。例えば、第一の実施形態の構成と組み合わせて、モバイル端末１４０１の開発ベンダと同じ開発ベンダであるＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２を優先的に表示してもよい。

以上、本実施形態のようにログイン状態を参考情報として用いることによっても、第一の実施形態にユーザビリティの高い表示を提供することができる。

＜第三の実施形態＞
第三の実施形態では、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３がローカルアプリケーション／サービスなのか、ネットワーク経由で利用するＷｅｂアプリケーション／サービスなのかによって、表示順序を決定する方法について説明する。

本実施形態に係るＷｅｂ Ｉｎｔｅｎｔｓクライアント１０１、ＵＡ１０２、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３の関係を示す図については、第二の実施形態にて示した図１４と同様のため、ここでは説明を省略する。本実施形態においても、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１はモバイル端末１４０１内のアプリケーション部分とし、ＵＡ１０２はＯＳ部分と想定して説明する。また、モバイル端末１４０１、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２のハードウェア構成、ソフトウェア構成についても図６（Ａ）、図１５、図７（Ａ）、図１６と同じであるため説明は省略する。

［テーブル構成］
図２２は、モバイル端末１４０１のＯＳ部７１０が自身に登録されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３を管理するために保持する登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブルの一例である。登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル２２１０は、モバイル端末１４０１内の記憶装置６０４で保持され、データベースサービス部７２０によって制御される。登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル２２１０の２２１１〜２２１６は第一の実施形態で説明した８１１〜８１６と同じであるため、説明は省略する。

［処理要求発行シーケンス］
図２３は、モバイル端末１４０１からＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２に対してＩｎｔｅｎｔの処理要求を発行する際のシーケンス図である。Ｓ２３０４でのサービス表示処理以外のＳ２３０１〜Ｓ２３０８は第一の実施形態で説明した処理と同様のため説明は省略する。

Ｓ２３０４のサービス表示処理について、図２４のフローチャートを用いて説明する。Ｓ２４０１〜Ｓ２４０４の処理については第二の実施形態で説明したＳ２００１〜２００４の処理と同様のため説明は省略する。

Ｓ２４０４の確認の結果、対象サービスが存在する場合（Ｓ２４０４にてＹＥＳ）、Ｓ２４０５にてＯＳ部７１０は、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル２２１０を参照し、対象サービスのｈｒｅｆ２２１４を確認する。ＯＳ部７１０は、ｈｒｅｆ２２１４のＵＲＬ文字列からＷｅｂ Ｉｎｔｅｎｔｓサービス１０３がモバイル端末１４０１内のアプリケーションなのか、ネットワーク１４０３経由で利用するＷｅｂアプリケーション／サービスなのかを判定する。図２２に示す例の場合、Ｓｅｒｖｉｃｅ ＩＤが「２」のＷｅｂ Ｉｎｔｅｎｔｓサービスのｈｒｅｆ２２１４には「ｌｏｃａｌｈｏｓｔ」の文字列を確認することができ、本サービスがモバイル端末１４０１内のアプリケーションであることがわかる。すなわち、ＵＲＬの情報から、接続先の位置（自装置内／ネットワーク上）を判定することができる。

Ｓ２４０６にて、ＯＳ部７１０は、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル２２１０にローカルで動作するアプリケーション／サービスが存在するか確認する。Ｓ２４０６の確認の結果、ローカルで動作するアプリケーション／サービスが存在する場合（Ｓ２４０６にてＹＥＳ）、Ｓ２４０７にてＯＳ部７１０は、ローカルアプリケーション／サービスを上位とした表示順序を決定し、表示する。図２２の例の場合、ｈｒｅｆ２２１４に「ｌｏｃａｌｈｏｓｔ」の文字列が含まれるＳｅｒｖｉｃｅ ＩＤが「２」の「ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅ」が最上位に表示される。図２５は、その際に表示されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３のリスト２５０１を示す。上位表示の対象となるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が複数存在した場合、つまりローカルアプリケーション／サービスが複数存在した場合は一定のルールに従って表示順位を決定する。予め定義された一定のルールとは、アルファベット順、ＪＩＳコード順などの一般的なソートルールである。Ｓ２４０８〜Ｓ２４０９の処理については、第二の実施形態で説明したＳ２００８〜Ｓ２００９と同様のため説明は省略する。

図２３において、Ｓ２３０４の処理後、Ｓ２３０５〜Ｓ２３０８の処理についても、第二の実施形態で説明した図１８のＳ１８０５〜Ｓ１８０８と同様のため説明は省略する。

以上、本実施形態のようにアプリケーションの位置（サービスを利用する際の接続先）を参考情報として用いることによっても、第一の実施形態にユーザビリティの高い表示を提供することができる。

なお、第一、第二の実施形態の構成と組み合わせて表示順序を制御するようにしてもよい。

＜第四の実施形態＞
第四の実施形態では、ＵＡ１０２の状態に応じて表示順序を決定する方法について説明する。本実施形態に係るＷｅｂ Ｉｎｔｅｎｔｓクライアント１０１、ＵＡ１０２、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１０３の関係を示す図については、第二の実施形態にて示した図１４と同様のため、ここでは説明を省略する。本実施形態においても、Ｗｅｂ Ｉｎｔｅｎｔｓクライアント１０１はモバイル端末１４０１内のアプリケーション部分とし、ＵＡ１０２はＯＳ部分と想定して説明する。モバイル端末１４０１、Ｗｅｂ Ｉｎｔｅｎｔｓサービス１４０２のハードウェア構成、ソフトウェア構成は、図６（Ａ）、図１５、図７（Ａ）、図１６と同じであるため説明は省略する。また、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブルについても、第三の実施形態にて示した登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル２２１０と同じであるため説明は省略する。

［処理要求発行シーケンス］
モバイル端末１４０１からＷｅｂ Ｉｎｔｅｎｔｓサービス１４０２に対してＩｎｔｅｎｔｓの処理要求を発行する際のシーケンスにおいて、サービス表示処理以外は図２３と同様である。したがって、Ｓ２３０１〜Ｓ２３０８の処理についても第二の実施形態で説明した通りである。

Ｓ２３０４のサービス表示処理について、図２６のフローチャートを用いて説明する。Ｓ２６０１〜Ｓ２６０４の処理については第二の実施形態で説明したＳ２００１〜２００４の処理と同様のため説明は省略する。

Ｓ２６０４の確認の結果、対象サービスが存在する場合（Ｓ２６０４にてＹＥＳ）、Ｓ２６０５にて、ＯＳ部７１０は、モバイル端末１４０１の通信状態を確認する。ここでの通信状態とは、ネットワーク１４０３を介した外部との通信が可能か否かを意味し、ＯＳ部７１０内の通信部７１４で検知される。Ｓ２６０５の確認の結果、モバイル端末１４０１のネットワーク通信が可能である場合（Ｓ２６０５にてＹＥＳ）、Ｓ２６０６にてＯＳ部７１０は、一定のルールに従って表示順序を決定し、表示する。ここでの一定のルールとは、アルファベット順、ＪＩＳコード順などの一般的なソートルールである。また、表示順序の決定方法は、第一、第二の実施形態で説明したものでもよい。

Ｓ２６０５の確認の結果、モバイル端末１４０１のネットワーク通信が可能でない場合（Ｓ２６０５にてＮＯ）、Ｓ２６０７にてＯＳ部７１０は、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル２２１０を参照し、対象サービスのｈｒｅｆ２２１４を確認する。ＯＳ部７１０は、ｈｒｅｆ２２１４のＵＲＬ文字列からＷｅｂ Ｉｎｔｅｎｔｓサービス１０３がモバイル端末１４０１内のアプリケーションなのか、ネットワーク１４０３経由で利用するＷｅｂアプリケーション／サービスなのかを判定する。図２２に示す例の場合、Ｓｅｒｖｉｃｅ ＩＤが「２」のＷｅｂ Ｉｎｔｅｎｔｓサービスのｈｒｅｆ２２１４には「ｌｏｃａｌｈｏｓｔ」の文字列を確認することができ、本サービスがモバイル端末１４０１内のアプリケーションであることがわかる。

Ｓ２６０８にて、ＯＳ部７１０は、登録済みＷｅｂ Ｉｎｔｅｎｔｓサービステーブル２２１０にローカルで動作するアプリケーション／サービスが存在するか否かを判定する。Ｓ２６０８の確認の結果、ローカルで動作するアプリケーション／サービスが存在する場合（Ｓ２６０８にてＹＥＳ）、Ｓ２６０９にてＯＳ部７１０は、ローカルアプリケーション／サービスを上位とした表示順序を決定し、表示する。本実施形態の場合、ｈｒｅｆ２２１４に「ｌｏｃａｌｈｏｓｔ」が含まれるＳｅｒｖｉｃｅ ＩＤが「２」の「ｂｂｂ Ｅｄｉｔ Ｓｅｒｖｉｃｅ」が最上位に表示される。図２５は、その際に表示されたＷｅｂ Ｉｎｔｅｎｔｓサービス１０３のリスト２５０１を示す。上位表示の対象となるＷｅｂ Ｉｎｔｅｎｔｓサービス１０３が複数存在しり場合、つまりローカルアプリケーション／サービスが複数存在した場合は一定のルールに従って表示順位を決定する。一定のルールとは、アルファベット順、ＪＩＳコード順などの一般的なソートルールである。

Ｓ２６０８の確認の結果、ローカルで動作するアプリケーション／サービスが存在しない場合（Ｓ２６０８にてＮＯ）、Ｓ２６１０にてＯＳ部７１０は、エラーメッセージを表示する。

以上、本実施形態のようにＵＡの状態を参考情報として用いることによっても、第一の実施形態にユーザビリティの高い表示を提供することができる。

なお、第一〜第三の実施形態の構成と組み合わせて表示順序を制御するようにしてもよい。

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

Claims (21)

1. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末であって、
   前記中継機能による前記サービスが提供する機能を呼び出すための機能情報の受信に伴い、当該機能情報の提供に関連する参考情報を受信する受信手段と、
   前記受信した機能情報の登録処理を実行する登録手段と、
   前記参考情報に基づく表示順序及び表示配置の少なくとも何れかに従い、前記登録処理により登録された機能情報をユーザに対して提供する提供手段と、
   を有することを特徴とする情報処理端末。
2. 前記ネットワークは、インターネットであることを特徴とする請求項１に記載の情報処理端末。
3. 前記クライアント、前記サービス、及び前記中継機能の少なくとも２つは、同じ端末で動作する機能であることを特徴とする請求項１または２に記載の情報処理端末。
4. 前記機能情報には、機能に対する分類情報として、ｓｈａｒｅ、ｅｄｉｔ、ｖｉｅｗ、ｐｉｃｋ、ｓａｖｅのいずれかが記述されていることを特徴とする請求項１乃至３のいずれか一項に記載の情報処理端末。
5. 前記参考情報は、前記受信手段が受信した前記機能情報を含むデータのうち、前記機能情報が記載された部分以外に記述されていることを特徴とする請求項１乃至４のいずれか一項に記載の情報処理端末。
6. 前記参考情報は、前記受信手段が受信した前記機能情報を含むデータの通信のためのヘッダ部分に含まれることを特徴とする請求項５に記載の情報処理端末。
7. 前記参考情報は、前記受信手段が受信した前記機能情報を含むデータのうち、前記機能情報の部分に含まれて記述されていることを特徴とする請求項１乃至４のいずれか一項に記載の情報処理端末。
8. 前記機能情報を構成するｔｉｔｌｅ属性またはｈｒｅｆ属性の何れかのパラメータとして、前記参考情報が埋め込まれることを特徴とする請求項７に記載の情報処理端末。
9. 前記受信手段は、前記機能情報を含むデータの通信とは異なるセッションにより、前記参考情報を受信することを特徴とする請求項１乃至４のいずれか一項に記載の情報処理端末。
10. 前記受信手段は、前記機能情報を含むデータの通信とは異なるタイミングの通信により、前記参考情報を受信することを特徴とする請求項１乃至４のいずれか一項に記載の情報処理端末。
11. 前記中継機能は、前記情報処理端末のＯＳまたはブラウザの機能として提供されることを特徴とする請求項１乃至１０のいずれか一項に記載の情報処理端末。
12. 前記参考情報は、サービスの提供元のベンダ情報を含むことを特徴とする請求項１乃至１１のいずれか一項に情報処理端末。
13. 前記参考情報は、サービスで提供される機能、もしくは、サービスの状態の何れかを含むことを特徴とする請求項１乃至１２のいずれか一項に記載の情報処理端末。
14. 前記参考情報は、アカウント情報を含むことを特徴とする請求項１乃至１３のいずれか一項に記載の情報処理端末。
15. 前記提供手段は、前記サービスの提供元が、前記情報処理端末の内部で動作するか否かに従って、ユーザに対して前記登録された機能情報の提供を行うことを特徴とする請求項１乃至１４のいずれか一項に記載の情報処理端末。
16. 前記提供手段は、前記情報処理端末が外部のサービスと通信が可能か否かに従って、ユーザに対して前記登録された機能情報の提供を行うことを特徴とする請求項１乃至１５のいずれか一項に記載の情報処理端末。
17. 前記提供手段は、前記登録処理により登録された機能情報を表示する際、前記参考情報を併せて表示することを特徴とする請求項１乃至１６のいずれか一項に記載の情報処理端末。
18. 前記提供手段は、前記登録処理により登録された機能情報のうち、前記参考情報が、前記情報処理端末の端末情報に一致する機能情報を優先して提供することを特徴とする請求項１２または１４に記載の情報処理端末。
19. 前記提供手段は、前記登録処理により登録された機能情報をリストにてユーザに提供し、
    前記参考情報に基づく表示順序及び表示配置は、前記リストにおける表示順序及び表示配置であることを特徴とする請求項１乃至１８のいずれか一項に記載の情報処理端末。
20. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備える情報処理端末の制御方法であって、
    前記中継機能による前記サービスが提供する機能を呼び出すための機能情報の受信に伴い、当該機能情報の提供に関連する参考情報を受信する受信工程と、
    前記受信した機能情報の登録処理を実行する登録工程と、
    前記参考情報に基づく表示順序及び表示配置の少なくとも何れかに従い、前記登録処理により登録された機能情報をユーザに対して提供する提供工程と、
    を有することを特徴とする制御方法。
21. データを管理するクライアントと、当該クライアントで管理されるデータを利用して機能を提供するサービスとを、ネットワークを介して中継する中継機能を備えるコンピュータを、
    前記中継機能による前記サービスが提供する機能を呼び出すための機能情報の受信に伴い、当該機能情報の提供に関連する参考情報を受信する受信手段、
    前記受信した機能情報の登録処理を実行する登録手段、
    前記参考情報に基づく表示順序及び表示配置の少なくとも何れかに従い、前記登録処理により登録された機能情報をユーザに対して提供する提供手段、
    として機能させるためのプログラム。

Images