以下、本発明を実施するための形態について図面を用いて説明する。
<Web Intentsの基本的な仕組み>
まず、専用のAPIを用いずに任意のWebサービス(または、Webアプリケーション)と連携するための仕組みの一例であるWeb Intentsに関する基本的な仕組みについて図1乃至図3を用いて説明する。本発明では、具体例として、Web Intentsを挙げるが、任意のウェブサービス(または、Webアプリケーション)と連携する技術として、他の同様の仕組みを適用することも可能である。
図1は、Web Intentsの全体構成を示す図である。
図1において、103は、Web Intents技術を利用してサービスや機能を提供するWeb Intentsサービス(以下、サービス)である。101は、サービス103を利用するWeb Intentsクライアント(以下、クライアント)である。106は、クライアント101からの要求をサービス103に渡し、サービス103からの結果をクライアントに渡す役割をするUserAgent(ユーザエージェント;以下、UA)である。UA106は、クライアント101及びサービス103の間で要求を実行したり、データを受け渡したりするための中継機能といえる。また、UA106には、サービス103の提供機能を呼び出すための機能情報であるWeb Intentが登録される。
本仕組みにおいては、例えば、クライアント101はデータを管理し、サービスを呼び出すボタンなどを配置しているウェブサイトであり、UA106は該ウェブサイトを表示するWebブラウザ(ウェブWebブラウザ)である。また、サービス103は、UA106を介してクライアント101が管理するデータを受け付けて、処理するクライアント101の連携先のウェブサイトである。
例えば、本仕組みをSNS(ソーシャル・ネットワーキング・サービス)に適用した場合には、サービス103はクライアントで管理する写真やコメントの投稿を受け付けて閲覧サイトを構成する投稿先サービスとなる。SNSサイトの「いいね」「チェック」「シェア」といったソーシャルボタンをWeb Intentsの仕組みで例えると、クライアント101はボタンを配置しているサイトになり、UA106はWebブラウザになり、サービス103は「いいね」などの投稿先サービスになる。なお、サービス103が機能を提供するにあたって、ユーザ認証やユーザによる操作が必要な場合、UA106上でユーザが操作を行う。
なお、UA106は、後述するサービスと連携するための機能を持つのであれば、Webブラウザ以外にも、情報処理端末で動作するオペレーティングシステム(OS)やアプリケーションなどで実現することも可能である。ここで、情報処理端末の例としては、パーソナルコンピュータ、スマートフォン、タブレット型コンピュータ、カーナビゲーション装置などが挙げられる。
また、サービス103については、上述した投稿先サービスのような、インターネット上のサービス提供者以外にも、例えば情報処理端末が内蔵するカメラ、プリンタ、スキャナなどといったデバイスもサービス提供者になり得る。また、サービス103については、ネットワークで接続されるプリンタ、スキャナ、ネットワークカメラなどの周辺機器や、冷蔵庫やテレビといった家電製品などもサービス提供者になり得る。また、クライアント101についても同様に、情報処理端末が内蔵するさまざまなデバイスやアプリケーション、その他にネットワーク上の周辺機器や家電製品、その上で動くプログラムなどもサービスを呼び出す利用者となり得る。クライアント101とUA106とサービス103は、これらの任意の組み合わせが、同一システム内で稼働することもある。具体的には、ウェブWebブラウザの同等の機能を有する文書編集アプリケーションなどが、クライアント101とUA106とを含む構成として動作するといったことが考えられる。また、クライアント101、UA106、サービス103のいずれかが、同じ装置上で動作する機能であってもよい。
<Web Intentsシーケンス図、および、データの例>
図2は、Web Intentsを利用したサービス提供に関する基本動作を説明するためのシーケンス図である。
S201にて、UA106は、ユーザの操作によりサービス103にアクセスする。S202にて、サービス103は、自身が提供する機能をUA106に登録してもらうための登録用マークアップを含むHTML(HyperText Markup Language)応答をUA106に返信する。
図3(a)は、S202にてサービス103からUA106に返信されるHTML文書を例示する図である。以下、図3(a)の例を用いて、サービス103からUA106に返信されるHTML文書の中身について説明する。
<intent>タグには、サービス103が提供する機能を特定し、サービス103が提供する機能を呼び出すための機能情報が記載されている。actionは、提供機能の分類情報(カテゴリ)を示す。すなわち、actionは、提供機能がどのような機能、サービスを提供するものであるかの分類情報を示す。なお、提供機能の分類情報には、例えば、データを共有する機能に対応する分類情報「Share」、データを編集する機能に対応する分類情報「Edit」、データを閲覧する機能に対応する分類情報「View」、データを取得する機能に対応する分類情報「Pick」、データを保存する機能に対応する分類情報「Save」等が含まれる。即ち、上記機能情報には、分類情報として、例えばShare、Edit、View、Pick、Saveのいずれかの分類情報が記載されている。
typeは、提供機能が扱えるデータなどの種類を示す。すなわち、typeは、actionに対して扱えるデータ型などを示す。hrefは、提供機能の接続先(URL)を示す。titleは、提供機能のタイトルを示す。また、dispositionは、呼び出された提供機能がどのように表示されるかを示す。
図3(a)の例では、提供機能のカテゴリが"share(共有)"であり、扱えるデータ等の種類が"あらゆるフォーマット(*)の画像データ"であり、接続先は"share.html"である。また、タイトルは" Share image using e−mail"である。さらに、この機能がUA106を介して別ウィンドウで表示されることを示している。
UA106は、上記S202のHTML応答を受信すると、ユーザに対してサービス103の提供機能をUA106に登録するか否か確認する。例えば、UA106がWebブラウザであれば、ポップアップウィンドウを表示させユーザに登録の可否の選択を促す。ユーザがこの提供機能をWeb Intentとして登録することを選択すると、UA106は、上記S202で受信した情報を内部に記憶する登録処理を実行する。具体的には、上記S202で受信した情報はUA106が動作する情報処理端末の記憶領域に記憶され、UA106にWeb Intentsとして登録される。
S203で、UA106は、ユーザの操作によりクライアント101にアクセスする。S204で、クライアント101は、サービス103の提供機能(Web Intent)を利用することが記載されたHTML文書を、UA106へ返信する。例えば、クライアント101としてのWebサイトで、画像と「共有」ボタンが表示される場合に、該Webサイトは、Web Intentの処理要求である図3(b)で示すようなECMAScriptを含むHTML文書をUA106へ返す。
図3(b)は、S204にてクライアント101からUA106に返信されるHTML文書を例示する図である。以下、図3(b)の例を用いて、クライアント101からUA106に返信されるHTML文書の中身について説明する。
ECMAScriptは、HTML内のID「share―photo」を持つボタンがクリックされると指定された無名関数を実行することを示している。無名関数は、まず、新規のIntentオブジェクトを作成し、これを引数にしてstartActivety()関数を呼び出す。この関数を実行すると、UA106は自身に登録されているWeb Intentsの中から、指定されたWeb Intentオブジェクトのactionとtypeが一致するものを抽出し、一覧表示させることでユーザに選択を要求する。また、UA106は、無名関数内で呼び出しているgetImageFrom()関数を実行することにより、クライアント101が持つ画像データを取得する。
上記S204にて、UA106は、クライアント101から送信されるHTML文書を受け取り、該HTML文書に基づく画面を表示する。S205にて、UA106は、ユーザによる画面上の「共有」ボタンの押下を検出すると、上述したようにWeb Intents起動用のECMAScriptを実行し、S206にて、クライアント101が持つ画像データを取得する。また、上記S205で「共有」ボタン押下を検出した際に、UA106は、自身に登録されているWeb Intentsの一覧を表示する。UA106は、この一覧からユーザがサービス103の提供機能を示すWeb Intentを選択したことを検出すると、S207にて、該選択された提供機能を提供するサービス103へHTTP要求(Web Intent処理要求)を送信する。その際、UA106は、送信データに、図3(b)のECMAScriptが作成したWeb Intentオブジェクトの内容を含める。
サービス103は、上記S207でUA106から送信されたHTTP要求を受信すると、S208にて、該HTTP要求からWeb Intentオブジェクトを取り出し、UA106を介してユーザと相互作用しながら、選択された提供機能(ここではクライアント101の画像データの「共有」)の利用を実現する。
例えば、ユーザがWebブラウザ(UA106)で、写真データを管理するウェブストレージ(クライアント101)のWeb Intentsの呼び出しボタンが用意されたサイトに訪れ、当該ボタンを押下する。すると、Webブラウザ(UA106)が登録サービス一覧を含むポップアップウィンドウを表示する。そのポップアップウィンドウで、ユーザがサービスとしてWebメール機能を選択したとすると、該機能を提供するサイトが別ウィンドウで表示され、処理結果として、そのウィンドウ上では写真データを添付した新規メールが作成される。これにより、ユーザは電子メールを送信することが出来る。
サービス103は、提供機能に関する処理が終了すると、S209にて、処理結果をクライアント101に伝えるECMAScriptを含む応答をUA106に返す。UA106は、上記S209の応答を受信すると、S210にて、該応答中に含まれるECMAScriptを実行し、上記S205のstartActivety()関数の引数で指定されたコールバック関数onSuccess()を呼び出す。S211にて、UA106は、該コールバック関数onSuccess()によってクライアント101へ処理結果を返す。
以上の処理により、クライアント101は、UA106を介して、サービス103が提供するWeb Intentsの機能(この例では画像の「共有」)を呼び出すことが可能となる。
<本実例における情報処理端末のUI例>
図4は、本発明の一実施例を示す情報処理端末のUI例を示す図である。
図4において、501は、通常のモバイル端末やスマートフォンのような情報処理端末を示している。情報処理端末501には、携帯情報端末をターゲットとして開発されたプラットフォームであるandroid(登録商標)などのOS(オペレーティングシステム)がインストールされる。
図4の例では、情報処理端末501には、アプリケーションプログラムとして複数のWebブラウザ(browserA,browserB,browserC)がインストールされている。これらのWebブラウザは、それぞれが図1におけるUA106に相当するものであり、それぞれWeb Intentsを利用可能である。即ち、情報処理端末501は、Web Intentsの中継機能を複数備えるものである。
ユーザは、Webブラウザ使用時に図1の103に相当するサービスを発見すると、必要に応じてサービスをWebブラウザに登録する。Webブラウザが管理している複数のサービスのリストは、Webブラウザ毎のものである。よって、Webブラウザに登録されているWeb Intentsは、Webブラウザ毎で異なっているのが通常である。
また、本実施例では、図4に示すようなスマートフォン型の情報処理端末を利用して説明するが、プラットフォームとして情報処理端末の形態には制限がなく、一般的なコンピュータ(例えばパーソナルコンピュータ)にも本発明は適用可能である。
<クライアント101及びサービス103のハードウェア構成例>
図5は、図1におけるクライアント101及びサービス103のハードウェア構成例を示すブロック図である。
クライアント101やサービス103は、汎用のコンピュータ等で構成可能である。クライアント101やサービス103は、CPU602、ROM603と、RAM604を含む。CPU602は、ROM603や後述する記憶装置608に格納されているプログラムを読み出して実行することにより、装置全体を統括制御する。ROM603は、システム起動に必要なブートプログラムを記憶するための読み出し専用メモリである。RAM604は、CPU602でプログラムを実行する際に必要とされる作業メモリである。
ネットワークインタフェース(Network I/F)605は、ネットワーク(Network)を介して通信を行う。表示制御部606は、表示デバイス609の表示を制御する。例えば、表示制御部606は、Webサーバを管理するため等の画面表示を制御する。表示デバイス609は、表示制御部606にて制御された出力信号をWebサーバ管理者であるオペレータに表示する。入力制御部607は、入力デバイス610や611から受信した入力信号を制御する。入力デバイス610は例えばマウス等のポインティングデバイスで、入力デバイス611はキーボード等であり、オペレータからの入力を受け付ける。
記憶装置608は、CPU602で実行するプログラムや各種情報を格納する例えば磁気ディスクやフラッシュメモリ等の不揮発性の記憶装置である。クライアント101の場合、記憶装置608に、クライアント101にて提供するコンテンツ情報なども格納する。また、サービス103の場合、記憶装置608に、サービス103が機能を提供するために必要なデータとプログラムなども格納する。
なお、本実施例で示すクライアント101、サービス103の処理は、それぞれ、クライアント101、サービス103のCPU602が記憶装置608に格納されるプログラムを読み出して実行することにより実現されるものである。
<情報処理端末501のハードウェア構成例>
図6は、情報処理端末501のハードウェア構成を示すブロック図であり、図1におけるUA106は、このハードウェア上で実行される。図6に記載の情報処理端末501は、通常のモバイル端末やスマートフォンであり、小型端末用のオペレーティングシステムや、通話、データ通信を制御するプログラムが動いている。
情報処理端末501のハードウェアの各構成要素は、システムバス801に接続されている。ROM803には、情報処理端末501におけるオペレーティングシステム及び、通話、データ通信を制御するアプリケーション等が格納されており、CPU802により読み出されて実行される。なお、データ通信を制御するアプリケーションには、例えば、MailソフトやWebブラウザなどがある。
RAM804は、プログラムを実行するためのワークメモリエリアである。また、RAM804は、WebブラウザがWebサーバから取得してきたWebページデータやWebサービスにアクセスするための認証情報などを一時記憶するためのメモリでもある。記憶装置809は不揮発性の記憶装置であり、情報処理端末501の再起動後も保持しておく必要のある各種動作モード設定や、稼働ログなどが記憶される。
ネットワークコントローラ(Network Controller)805は、無線LANに参加するための無線LAN通信部811と、携帯キャリアの提供するネットワークに参加するための携帯電話データ通信部812の通信制御を行う。一般的に無線LANのネットワークに参加できるとき、ネットワークコントローラ805は、無線LAN通信部811を介した無線LANの接続を優先する。なお、情報処理端末501が無線LANのネットワークエリアから外れた場合には、携帯電話データ通信部812を介したネットワークコントローラ805は、携帯キャリアが提供する無線通信ネットワークへ参加する。
音声制御部806は、主に通話アプリケーションが起動しユーザが電話をしているときに利用する。マイク・スピーカ813にて音声データの入出力を行い、音声制御部806は、その制御プログラムとの仲介を行っている。表示制御部807は、情報処理端末501のディスプレイ814にて出力する情報の制御を行っている。入力制御部808は、情報処理端末501のボタンやタッチパネル815を介してユーザが指示した情報の制御を行っている。これらの音声制御部806、表示制御部807、入力制御部808を利用して、情報処理端末501上でのアプリケーションは、ネットワーク通信情報や情報処理端末501のさまざまな情報をユーザに提供する。位置検出制御部810は、GPSセンサー816から情報処理端末501の位置情報を取得しオペレーティングシステムに提供する。これらの制御は、CPU802で動くオペレーティングシステムにて制御される。
なお、本実施例で示すUA106は、情報処理端末501のCPU802がROM803に格納されるプログラムを読み出して実行することにより実現されるものである。
<情報処理端末501のソフトウェア構成例>
図7は、図4における情報処理端末501のソフトウェア構成を示すブロック図である。図7では、主に、本発明に関係のあるアプリケーションのWeb Intentsリクエスト発行に係る技術と、インテントを利用した機能情報の相互利用に係る機能を説明する。なお、インテントとは、任意のアプリケーション間でデータを送受信する技術である。これは、携帯情報端末をターゲットとして開発されたプラットフォームであるandroid(登録商標)上で、利用可能な技術である。また、類似の技術が、他のプラットフォームでも実装されているが、本実施例では、情報処理端末内のアプリケーション間でデータの送受信を行う技術をインテントと呼ぶ。
図7において、501は、図4に示した情報処理端末である。ここでは、情報処理端末501をモバイル端末やスマートフォンとして説明する。情報処理端末には、一般的に機器を制御するためのオペレーティングシステム(以下、OS)が動いており、図7ではOS部901として表している。また、情報処理端末501には、複数のアプリケーションをインストールすることができる。このアプリケーションを図7ではアプリケーション部902として表している。図7では、アプリケーション部を1つしか記載していないが、実際には、情報処理端末501には複数のアプリケーションがインストールされている。
本発明では、情報処理端末501のオペレーティングシステム上で図1のUA106として動作するアプリケーションが、情報処理端末501内で複数動作する環境を想定している。なお、本実施例では、UA106として動作するアプリケーションの一例としてWebブラウザを用いて説明するが、UA106として動作するアプリケーションであればどのようなアプリケーションであってもよい。例えば、表計算ソフトのようなアプリケーションがUA106の機能を提供するものであってもよい。また、OSがUA106として動作する場合も本発明に含まれるものとする。
本実施例で想定しているアプリケーションは、WebブラウザのようなWeb IntentsをUA106として制御できるアプリケーションであり、また同時に、アプリケーション間でデータの送受信を行うことができるアプリケーションである。アプリケーション間でデータを送受信する技術としては、インテントの他に、Web Intentsなどがある。実施例1では、インテントを利用してアプリケーション間でデータを送受信する実施例を示す。また、後述する実施例2では、Web Intentsを利用してアプリケーション間でデータを送受信する実施例を示す。しかし、ここで想定するアプリケーションは、任意のアプリケーション間で、データの送受信を行うことができればよく、特にインテントやWeb Intentsに限定しない。
なお、図7に示すOS部901やアプリケーション部902は、情報処理端末501のCPU802がROM803に格納されるOSやアプリーションプログラムを読み出して実行することにより実現されるものである。
まず、OS部901について説明する。
OS部901において、906はネットワーク制御部である。ネットワーク制御部906は、図6のネットワークコントローラ805を制御する。情報処理端末501は、小型携帯端末であるため移動して利用することが想定されており、ネットワーク制御部906は、その場所に応じてアクセス可能なネットワークへ自動的に接続を行う。また、アプリケーション部902からの通信リクエストに応じて外部へ通信を行う。また、ネットワーク制御部906は、外部からのネットワーク接続要求に対応し、適切なアプリケーション部902へと接続要求を振り分ける。
904はインテント情報入出力部、905はアプリケーション情報格納部である。OS部901は、アプリケーション部902からアクションやタイプ(以下、データ型)の情報とともにインテント要求を受けると、そのアクションとデータ型に対応したアプリケーションをインテント情報入出力部904に要求する。インテント情報入出力部904は、インテント要求を受けると、受信したアクションとデータ型に対応するアプリケーションのリストをアプリケーション情報格納部905から取得する。そして、インテント情報入出力部904は、取得したアプリケーションのリストをアプリケーション部902へ送信する。
また、903はユーザ入出力部で、図6の音声制御部806、表示制御部807、入力制御部808を統括して管理する。ユーザ入出力部903は、アプリケーション部902からユーザへの表示指示があると表示制御部807を介してディスプレイ814へ表示を行う。また、ユーザがタッチパネル815を介して入力を行うと、ユーザ入出力部903は、入力制御部808にて制御された入力信号をアプリケーション部902へと伝える。
次に、アプリケーション部902について説明する。
アプリケーション部902は、サービス情報管理部908、中央処理部907、サービス情報検出部909、サービス情報入出力部910、サービス情報格納部911を有する。
907は中央処理部で、Webブラウザとして中心的な働きをする。この中央処理部907の基本的な役割は、Web IntentsにおけるUA106である。そのほかにも中央処理部907は、基本的なブラウジング処理や、サービス103を検知した時の処理、サービス103を利用する際の制御処理、また、インテントを通じたデータの送受信なども行う。例えば、中央処理部907は、インテントを利用して、他のアプリケーションから機能情報(サービス103が提供する機能を登録するための機能情報)の取得要求に応じたり、他のアプリケーションへ機能情報の登録リクエストを発行したりする。また、中央処理部907は、OS部901のインテントを利用しない場合には、後述する実施例2に示すように、サービス情報管理部908を用いて、機能情報を他のアプリケーションから取得、または、提供することも可能である。また、中央処理部907は、サービス情報管理部908を用いて、他のアプリケーションから機能情報の取得要求に応じたり、他のアプリケーションへ機能情報の登録リクエストを発行したりする。なお、サービス情報管理部908については、後述する実施例2で説明する。
サービス情報検出部909は、アクセス時にサービス103から受信したWebページに含まれる<intent>タグを検出し、サービス103が提供する機能を登録するための機能情報を認識する。サービス情報入出力部910は、サービス情報格納部911への機能情報の入出力を制御する。サービス情報格納部911には、図8に示すような情報が格納される。
図8は、UAとしてのWebブラウザにて管理される機能情報を例示する図である。
例えば、図8に示す例では、サービスが提供する提供機能の名称1401、提供機能の接続先URI1402、Web Intentsリクエストを受け付ける際のアクション(action)1403、データ型(type)1404などを含む情報がサービス情報格納部911に格納されている。
以下、アプリケーション部902の各モジュールの動きを簡単に説明する。
ユーザが情報処理端末501のアプリケーションであるWebブラウザ(UA106に対応)を利用して、Web Intntsの仕組みを利用した或るサービス(Webサイト)へアクセスする。すると、アプリケーション部902のサービス情報検出部909は、アクセス時にサービスから受信したWebページに含まれる<intent>タグを検出し、サービスが提供する機能を登録するための機能情報(Web Intentsサービス情報)を認識し、中央処理部907へ通知する。通知をうけた中央処理部907は、ユーザ入出力部903を介してユーザに対して、この機能情報をWeb Intentとして登録するか否かの選択を仰ぐ。ここで、ユーザから登録が指示された場合、中央処理部907は、サービス情報入出力部910へ上記<intent>タグで特定される機能情報を保管する指示を発行する。サービス情報入出力部910は、上記機能情報の保管指示を受けると、サービス情報格納部911へ上記機能情報を格納する。
なお、情報処理端末501は、ユーザに機能情報を登録するか否かの選択を仰ぐ際に、情報処理端末501内または外の他のアプリケーションに対しても機能情報を登録するか否かの選択をユーザに仰ぐ。例えば、ここでの情報処理端末501の画面例を図10(a)に示す。ユーザが、この画面で「OK」ボタン1102を押下すると、操作中のアプリケーションに上記機能情報が登録される。また、ユーザが「Option」ボタン1103を押下すると、他の登録候補となるアプリケーションが表示され、選択されたアプリケーションに上記機能情報が登録される。
情報処理端末501の処理としては、ユーザから他のアプリケーションに対する登録指示を受けた場合、中央処理部907は、機能情報をインテント(後述する実施例2ではWeb Intents)を利用して他のアプリケーションに登録依頼を発行する。例えば、インテントを利用する場合、OS部901のインテント情報入出力部904に機能情報の登録を受け付けるアプリケーションリストの登録依頼を発行する。登録依頼を受け取ったインテント情報入出力部904は、対応するアプリケーションのリストをアプリケーション情報格納部905から取得し、応答として返す。インテントによって機能情報を登録可能なアプリケーションのリストを受信した中央処理部907は、ユーザ入出力部903を介して、アプリケーションリストを表示する。ここでユーザは登録したい対象のアプリケーションを選択し、アプリケーションのリストを返すと、中央処理部907は、インテントを利用して、上記選択された他のアプリケーションへ機能情報の登録依頼を発行する。
また逆に、他のアプリケーションからインテントにより機能情報の登録指示を受けると、中央処理部907は、サービス情報管理部908に処理依頼を発行する。サービス情報管理部908は、リクエストが適切であることを判定すると、サービス情報入出力部910を介してサービス情報格納部911へ機能情報の登録を行う。
なお、ユーザがサービスに処理を依頼する場合、中央処理部907は、サービス情報入出力部910を介して、サービス情報格納部911から機能情報を取得する。そして、中央処理部907は、該取得した機能情報の一覧を表示し、該一覧から選択された機能情報に対応するサービスに対してWeb Intents処理要求とコンテンツ情報を送信する。
<実施例1おける機能情報の相互利用に関するシーケンス図の例>
図9は、情報処理端末501のユーザがあるWebブラウザを用いてWeb Intentsを検出した際に、自Webブラウザだけでなく他のWebブラウザに機能情報の登録を依頼する動作例を説明するためのシーケンス図である。なお、図9では、図2で説明したWeb Intentsの基本シーケンスに拡張を行っている。図9中、902は情報処理端末501内のWebブラウザを想定しており、Web Intentsの役割としてはUAとなる。図9では、UAが複数存在し、機能情報を検出する側のWebブラウザをUserAgent.1(以下、UA.1)とし、検出された機能情報が提供される側のWebブラウザをUserAgent.2(以下、UA.2)とする。
なお、図10は、UA.1のWebブラウザ画面に表示される画面を例示する図である。
また、図11、図12は、図9のシーケンスの一部の詳細シーケンス図である。
図9のS1001では、ユーザ指示に応じてUA.1がクライアント101にアクセスをする。すると、UA.1は、S1002にて、サービス103が提供する機能の機能情報を表す<intent>タグを含んだHTML情報を受信する。S1003にて、情報処理端末501のサービス情報検出部909は、アクセスしたWebサイトが、機能を提供していることを検出する。さらに、サービス情報検出部909は、アクセスしたサービス103が初めて訪れたサイトであることを検出する。すると、UA.1は、ユーザにこのWebサイトの提供する機能の機能情報を登録するか否かを確認するために、S1004で、図10(a)に示すような、機能情報の登録画面を表示する。
S1004で表示する画面には、図10(a)に示すように、「Cancel」ボタン1101、「OK」ボタン1102、「Option」ボタン1103が表示されている。「Cancel」ボタン1101を押下すると、機能情報の登録をキャンセルすることができる。「OK」ボタン1102を押下すると、機能情報を自身に登録することができる。「Option」ボタン1103を押下すると、機能情報を複数のUAに登録することができる。本シーケンス図では、複数のUAに機能情報を登録する処理について記載する。
S1005にて、UA.1は、「Option」ボタン1103が押下されたことを検知すると、S1006に処理を進める。S1006では、UA.1は、OS部901に対して、UAリストの取得リクエストを発行し、S1007にて、UAリストを応答として受信する。
以下、S1006〜S1007について図11(a)を用いて詳細に説明する。
図11(a)に示すように、S1006にて、UA.1は、インテント技術を利用して、機能情報を登録可能なアプリケーションのリストを取得するためのリクエストの発行を行う。例えば、Actionに相当するものとして「Share」をリクエストし、データタイプとして「application/Web Intents Service」をリクエストする。S1007にて、UA.1は、OS部901からインテントの応答として、リクエストに対応するアプリケーションのリストを受信する。
次に、図9のS1008にて、UA.1は、機能情報の登録を受け付けるアプリケーションのリスト(S1007で受信)であるUAリストをユーザ画面に表示する。このときのUA.1のWebブラウザ画面では、図10(b)に示すような指定画面を表示する。図10(b)に示す画面には、UAリスト1104、「Cancel」ボタン1105、「OK」ボタン1106が表示されている。なお、このUAリスト1104には、UA.1も含めてもよい。「Cancel」ボタン1105を押下すると、UAの選択をキャンセルすることができる。UAリスト1104から機能情報を登録したいアプリケーション(UA)を1つ以上選択指定した状態で「OK」ボタン1106を押下すると、機能情報の登録を依頼するUAの選択指定を確定することができる。
S1009にて、UA.1は、図10(b)の画面で1つ以上のアプリケーション(UA)が選択されたことを検知すると、S1010に処理を移行する。S1010にて、UA.1は、インテントを利用して、上記選択されたアプリケーション(ここではUA.2とする)に対して、機能情報の登録依頼を発行し、S1011にて、応答として登録処理結果を受信する。
以下、S1010〜S1011について図11(b)を用いて詳細に説明する。
図11(a)に示すように、S1011にて、UA.1は、インテント技術を利用し、データ(機能情報)を送信する。この際、Actionを「Share」、Typeを「application/Web Intents Service」として機能情報の登録依頼を発行する。ここで送信するデータタイプは、例えば図12に示すようなデータ構成である。そして、S1011では、UA.1は、UA.2より、登録リクエストの処理結果を応答として受信する。
図12は、S1010でUA.1からUA.2送信される機能情報のデータ構成を例示する図である。
図12に示すように、機能情報のデータには、提供機能の名称と、提供機能を受け付けるURI、また、提供機能を提供する際のアクション(action)とデータの型(type)が含まれている。
なお、上述した図9のS1009〜S1011に示したUAの選択を検知し該選択されたUAに機能情報の登録依頼を発行する処理は、ユーザがUAを選択した回数分繰り返される(S1012)。以上にようにして、UA.1が検出した機能情報を他のUAで管理する機能情報としても登録することができる。
<実施例1のUAの処理フローチャートの例>
図13は、UAがサービスから<intent>タグを含むHTMLを受信してから、機能情報を外部のアプリケーションに登録するまでの処理を例示するフローチャートである。なお、図13及び後述する図14に示すフローチャートの処理は、図7に示す情報処理端末501内のソフトウェアの処理の一部を示したものである。これらのフローチャートの処理は、情報処理端末501のCPU802が、ROM803、記憶装置809等に記憶されたプログラムを必要に応じてRAM804に展開して実行することにより実現される。
S1701にて、情報処理端末501のネットワーク制御部906は、サービス103から<intent>タグを含むHTMLを受信すると、処理をS1702へ進める。S1702では、中央処理部907は、受信したHTML情報からWebブラウザ画面を構成しユーザに表示する。そして、処理をS1703へ進める。
S1703では、サービス情報検出部909は、上記S1701で受信したHTMLに<intent>タグがあることを検知し、アクセスしたWebサイトで機能を提供していることを把握する。すると、中央処理部907は、ユーザに対してアクセスしたサービスが提供する機能の機能情報をUAに登録するか否かを問うウィンドウ(例えば図10(a))を表示し、処理をS1704へ進める。
S1704では、中央処理部907は、機能情報の登録指示を受信した(図10(a)の「OK」ボタン1102が押下された)か否かを判断する。ここで機能情報の登録指示を受けたと判断した場合(S1704でYesの場合)、中央処理部907は、処理をS1705へ進める。S1705では、中央処理部907は、サービス情報入出力部910に対して、機能情報の登録指示を発行し、該機能情報のUAへの登録が完了したら、Webブラウザに制御を返す。そして、処理を終了する(S1709)。
一方、上記S1704にて、機能情報の登録指示を受けなかったと判断した場合(S1704でNoの場合)、中央処理部907は、処理をS1706へ進める。S1706では、中央処理部907は、機能情報の登録Option指示を受信した(図10(a)の「Option」ボタン1103が押下された)か否かを判断する。ここで機能情報の登録Option指示を受けたと判断した場合(S1706でYesの場合)、中央処理部907は、処理をS1707へ進める。S1707では、機能情報の他UAへの登録処理を実行する。なお、実施例1におけるS1707の詳細は、後述する図14に示す。そして、上記S1707の処理を終了すると、中央処理部907は、Webブラウザに制御を返す。そして、処理を終了する(S1709)。
一方、上記S1706にて機能情報の登録Option指示を受信しなかったと判定した場合(S1706でNoの場合)、中央処理部907は、処理をS1708へ進める。この場合は、ユーザからCancel指示を受信した(図10(a)の「Cancel」ボタン1101が押下された)場合に対応するため、中央処理部907は、S1708にて、上記S1703にて表示した登録問い合わせのためウィンドウ(図10(a))を閉じ、Webブラウザに制御を返す。そして、処理を終了する(S1709)。
<機能情報の他UAへの登録処理のフローチャート>
図14は、実施例1における機能情報の他UAへの登録処理(図13のS1707)の詳細を示すフローチャートである。
図13のS1707に示した機能情報の他UAへの登録処理を開始すると(S1721)、中央処理部907は、S1722へ処理を進める。S1722では、中央処理部907は、OS部901に対してアクションを「Share」、データタイプを「Web Intents Service」としてインテントのリクエストを発行し、処理をS1723へ進める。
S1723では、中央処理部907は、OS部901からインテントにてリクエストした応答として、1つ以上のアプリケーションからなるリストを受信したか否かを判定する。そして、1つ以上のアプリケーションからなるリストを受信できなかったと判定した場合(S1723でNoの場合)、中央処理部907は、処理をS1724へ進める。S1724では、中央処理部907は、インテントで対応するアプリケーションを探したがデバイス内に対応するアプリケーションが存在しないことをユーザに通知し(例えばメッセージを画面表示し)、処理をS1725へ進め、図13のS1704へ処理を戻す。
一方、1つ以上のアプリケーションからなるリストを受信したと判定した場合(S1723でYesの場合)、中央処理部907は、処理をS1726へ進める。S1726では、中央処理部907は、ユーザ入出力903を介してユーザへ上記S1723にて取得したアプリケーションのリストを含む画面(例えば図10(b))を表示し、処理をS1727へ進める。
S1727では、中央処理部907は、上記S1726にて表示したアプリケーションリストの中から1つ以上のアプリケーションがユーザにより選択されたか否かを検知する。ここでアプリケーションが選択された画面例は、図10(b)のような画面となる。図10(b)では、機能情報を登録するUAとして「browserA」及び「browserB」が指定されている状態が示されている。
上記S1727にて、「Cancel」ボタン1105が押下されアプリケーションが選択されなかったと判断した場合(S1727でNoの場合)、中央処理部907は、処理をS1725へ進め、図13のS1704へ処理を戻す。
一方、上記S1727で、1つ以上のアプリケーションが選択され「OK」ボタン1106が押下されたと判断した場合(S1727でYesの場合)、中央処理部907は、処理をS1728へ進める。
S1728では、中央処理部907は、上記S1726にて選択された1つ以上のアプリケーションのうち、1つを選択し、処理をS1729へ進める。S1729では、中央処理部907は、上記S1728で選択されたアプリケーションに対して、アクションを「Share」、データタイプを「Web Intents Service」とし、インテントを利用した、機能情報の登録要求を発行する。この要求を受けたアプリケーションは、機能情報の登録を行い、応答として登録結果を返す。なお、このデータの送受信は実際にはOS部901を介して行われるが、ここでは簡略化して説明する。そして、中央処理部907は、上記S1729にて発行した登録要求の応答を受信し、上記S1728で選択したアプリケーションの処理を終えると、S1730にて、アプリケーションリストから上記S1728で選択したアプリケーションを削除し、処理をS1731へ進める。
S1731では、中央処理部907は、上記S1723で受信したアプリケーションのリストが空になったか否かを判断する。そして、アプリケーションのリストにまだ1つ以上のアプリケーションが残っていると判断した場合(S1731でNoの場合)、中央処理部907は、処理をS1728へと戻す。
一方、上記S1731にて、アプリケーションのリストが空になっていると判断した場合(S1731でYesの場合)、中央処理部907は、処理をS1732へと進める。S1732まで処理が進むと、ユーザの望んだすべてのアプリケーション(UA)に機能情報が登録されたこととなり、中央処理部907は、登録処理に利用したウィンドウ(図10(b))を閉じ、Webブラウザに制御を返す。そして、機能情報の他UAへの登録処理を終了する(S1733)。
以上説明したように、実施例1によれば、同じ情報処理端末内に複数のUAが存在する場合に、あるUAで検出した機能情報を、インテントの仕組みを用いて、複数のUAに登録することができる。
上記実施例1では、例えばandroid(登録商標)系プラットフォームのインテントを利用して他のUAに機能情報を登録要求する構成について説明した。これに対し、実施例2では、インテントを利用せず、W3CのWeb Intentsを利用して他のUAに機能情報を登録要求する構成について説明する。
図7に示したアプリケーション部902のサービス情報管理部908は、HTTPクライアントの機能およびWeb Intentsサービスの機能を有する。サービス情報管理部908は、Web Intentsの仕組みを利用して外部のアプリケーションへ機能情報の登録依頼を発行する。また、サービス情報管理部908は、Web Intentsの仕組みを利用して外部アプリケーションからアクションおよびデータのタイプ情報とともに機能情報の登録依頼を受け付けると、中央処理部907、サービス情報入出力910を介してサービス情報格納部911に機能情報を登録する。
<実施例2における機能情報の相互利用に関する他のシーケンス図の例>
図15は、実施例2において情報処理端末501のユーザがあるWebブラウザを用いてWeb Intentsを検出した際に、自Webブラウザだけでなく他のWebブラウザに機能情報の登録を依頼する動作例を説明するためのシーケンス図である。なお、図9と同一のステップには同一のステップ番号を付してある。以下、図9と異なる部分のみ説明する。
なお、図16は、図15のシーケンスの一部の詳細シーケンス図である。
S1001〜S1005の処理は、図9と同様であるので説明を省略する。実施例2の情報処理端末501では、ローカルエリアネットワーク(Local Network)1501から機能情報を提供可能なアプリケーションまたはサービス(以下、単にサービスという)を探索する。具体的には、S1005にて、UA.1は、「Option」ボタン1103(図10(a))が押下されたことを検知すると、S1601にて、Local Network1501に対してサービスの探索を実行する。このネットワーク探索に関して、以下、図16を用いて詳細に説明する。
図16に示すように、UA.1は、S1601にて、Local Network1501に対してサービスの探索を行う。ここでは、例えば、Apple社のゼロ・コンフィギュレーション技術であるBonjourにおけるMulticastDNSなどの技術を用いてリンクローカル内のネットワークサービスを探索する。
S1602にて、UA.1は、各サービスから応答を受ける。本実施例では、Local Network1501内で探索を行うので、同じ情報処理端末内のサービスから応答を受けることの他に、ネットワークの届く範囲にあるサービスからも応答を受けることができる。このネットワークの範囲は、ここでは限定しない。
次に、UA.1は、S1603にて、上記S1602で応答を受けたサービスから、データ型に「application/Web Intents Service」、アクションに「Share」を提供するサービスを検出してリスト化する。なお、この際、検出に必要な情報が不足している場合には、上記S1602で応答を受けた各サービスにアクセスして取得してもよい。このような処理により、ローカルエリアネットワーク内に存在する機能情報を提供可能なサービスを探索することができる。
次に、S1604にて、UA.1は、上記S1603で検出したサービスのリストを表示してユーザへ提示し、S1009に処理を進める。その後の処理は、図9と同様であるので説明を省略する。
<実施例2の機能情報の他UAへの登録処理のフローチャート>
図17は、実施例2における機能情報の他UAへの登録処理(図13のS1707)の詳細を示すフローチャートである。このフローチャートの処理は、情報処理端末501のCPU802が、ROM803、記憶装置809等に記憶されたプログラムを必要に応じてRAM804に展開して実行することにより実現される。
図13のS1707に示した機能情報の他UAへの登録処理を開始すると(S1741)、中央処理部907は、S1742へ処理を進める。S1742では、サービス情報管理部908は、Local Network1501に対して、Web Intentsの仕組みを利用した機能を提供しているアプリケーションまたはサービス(以下、単にサービス)を探索する(図15及び図16のS1601〜S1604に対応)。探索対象は、アクションを「Share」、データ型「Web Intents Service」としているサービスである。探索のリクエストは、Apple社のbonjourなどで利用しているmulticastDNSなどのサービス探索用のプロトコルを利用してリクエストを発行する。
次に、S1743において、サービス情報管理部908は、上記S1742の探索の結果、対応する1以上のサービスを発見したか否かを判定する。そして、サービス情報管理部908は、対応する1以上のサービスを発見できなかったと判定した場合(S1743でNoの場合)、処理をS1744へ進める。S1744では、サービス情報管理部908は、中央処理部907を介して、サービスを探した結果として、ネットワーク探索範囲内に対応するサービスが存在しないことをユーザに通知し(例えばメッセージを画面表示し)、処理をS1745へ進め、図13のS1704へ処理を戻す。
一方、1つ以上のサービスからなるリストを受信したと判定した場合(S1743でYesの場合)、サービス情報管理部908は、処理をS1746へ進める。S1746では、中央処理部907は、ユーザ入出力903を介して、ユーザへ上記S1743にて取得したサービスのリストを含む画面(例えば図10(b))を表示し、処理をS1747へ進める。
S1747では、中央処理部907は、上記S1746にて表示したサービスリスト(例えば図10(b)の1104)の中から1つ以上のサービスがユーザにより選択されたか否かを検知する。ここでサービスが選択された画面例は、図10(b)のような画面となる。図10(b)では、機能情報を登録するUAとして「browserA」及び「browserB」が指定されている状態が示されている。
上記S1747にて、「Cancel」ボタン1105が押下されサービスが選択されなかったと判断した場合(S1747でNoの場合)、中央処理部907は、処理をS1745へ進め、図13のS1704へ処理を戻す。
一方、上記S1747で、1つ以上のサービスが選択され「OK」ボタン1106が押下されたと判断した場合(S1747でYesの場合)、中央処理部907は、処理をS1748へ進める。
S1748では、サービス情報管理部908は、上記S1746にて選択された1つ以上のサービスのうち、1つを選択し、処理をS1749へ進める。S1749では、サービス情報管理部908は、上記S1748で選択されたサービスに対して、アクションを「Share」、データタイプを「Web Intents Service」とし、Web Intentsを利用した、機能情報の登録要求を発行する。この要求を受けたサービスは、機能情報の登録を行い、応答として登録結果を返す。そして、サービス情報管理部908は、上記S1749にて発行した登録要求の応答を受信し、上記S1748で選択したサービスの処理を終えると、S1750にて、サービスリストから上記S1748で選択したサービスを削除し、処理をS1751へ進める。
S1751では、サービス情報管理部908は、上記S1723で受信したサービスのリストが空になったか否かを判断する。そして、サービスのリストにまだ1つ以上のサービスが残っていると判断した場合(S1751でNoの場合)、サービス情報管理部908は、処理をS1748へと戻す。
一方、上記S1751にて、サービスのリストが空になっていると判断した場合(S1751でYesの場合)、サービス情報管理部908は、処理をS1752へと進める。S1752まで処理が進むと、ユーザの望んだすべてのサービス(UA)に機能情報が登録されたこととなり、サービス情報管理部908は、中央処理部907を介して、登録処理に利用したウィンドウ(図10(b))を閉じ、Webブラウザに制御を返す。そして、機能情報の他UAへの登録処理を終了する(S1753)。
以上説明したように、実施例2によれば、同じ情報処理端末内に複数のUAが存在する場合に、あるUAで検出した機能情報を、Web Intentsの仕組みを用いて、複数のUAに登録することができる。
上記実施例1及び実施例2では、アプリケーションに機能情報を登録する際に他のアプリケーションにも登録することで機能情報の相互利用を実現する構成を説明した。また、機能情報の情報共有のために、実施例1ではインテントを利用し、実施例2ではWeb Intentsを利用する例についても説明した。
しかし、機能情報を発見するたびに、ユーザが登録すべきアプリケーションを選択し、一つ一つのアプリケーションに機能情報の登録依頼を発行することを煩わしい作業と感じるユーザが存在する可能性がある。ユーザは、使用しているアプリケーションのどれかに発見した機能情報を登録しておき、あるタイミングで他のアプリケーションから取り込みと共有を実行できればよい。実施例3では、あるアプリケーションを利用時に他の1つ以上のアプリケーションから機能情報を取得すること、及び、他のアプリケーションにまだ登録されていない機能情報を提供する構成について説明する。
<実施例3おける機能情報の相互利用に関するシーケンス図の例>
図18は、実施例3において情報処理端末501のユーザがあるWebブラウザを用いて他のWebブラウザと登録されている機能情報を同期させるためのシーケンス図である。即ち、この図では、情報処理端末501のユーザがあるWebブラウザを利用し、他の1つ以上のWebブラウザに登録されている機能情報を取得し、さらに取得した機能情報を他のまだ登録されていないWebブラウザに提供し登録依頼を発行する動作例を説明する。なお、図18では、図2で説明したWeb Intentsの基本シーケンスに拡張を行っている。図18中、902は情報処理端末501内のWebブラウザを想定しており、Web Intentsの役割としてはUAとなる。図18では、UAが複数存在する。機能情報を収集し、さらに提供するリクエストを発行するWebブラウザをUA.1とする。また、インテントサービス(後述する実施例4ではWeb Intentsサービス)を提供しリクエストに応じて機能情報を提供したり、登録依頼を受け付けたりするWebブラウザをUA.2とする。また、実際には、UA.2は複数存在するが、図中ではUA.2を1つ用いて説明する。
なお、図19は、UA.1のWebブラウザ画面に表示される画面を例示する図である。
また、図20は、図18のシーケンスの一部の詳細シーケンス図である。
さらに、図21は、UAに登録されている機能情報のマップを例示する図である。
図18のS1801では、ユーザがUA.1を利用して機能情報の取込み、及び、共有指示を発行する。ここでの情報処理端末501の画面例を、図19に示す。ユーザは、Webブラウザを立ち上げるとアプリケーションに設定しているホーム画面が表示される。ここでは、ユーザはある検索サイトを設定しているものとし、図19(a)のような画面が表示されるものとする。ここでユーザは、さらに図19(b)に示すように、Webブラウザメニューを表示し、このメニュー内の「サービス情報の取込/共有」メニュー1901(図19(b)内で「サービス情報を同期」と表記)を押下する。該「サービス情報の取込/共有」メニュー1901の押下を検知すると、UA.1は、機能情報の同期が指示されたと判断し、S1802に処理を進める。
S1802では、UA.1は、OS部901に対してインテントを利用して機能情報の提供を行うアプリケーションのリストを取得要求する。この要求に応じて、OS部901は、S1803にて、インテント情報入出力部904を介して機能情報の提供が可能なアプリケーションのリストをアプリケーション情報格納部905から取得し応答する。そして、UA.1は、この応答(アプリケーションリスト)を受信すると、S1804に処理を進める。
S1804では、UA.1は、上記S1803で取得したアプリケーションの1つ(ここではUA.2)に対して機能情報リストの取得要求を発行する。この要求に応じて、UA.2は、S1805にて、自身が管理する機能情報のリストを応答する。そして、UA.1は、この応答(機能情報リスト)を受信する。
ここで、S1804〜S1805について図20(a)を用いて詳細に説明する。
図20(a)に示すように、S1804にて、UA.1は、インテント技術を利用して、機能情報を他のアプリケーションから取得するためのリクエストの発行を行う。例えば、Actionに相当するものとして「Pick」をリクエストし、データタイプとして「application/Web Intents Service」をリクエストする。S1805では、上記S1804で発行したインテントの応答としてUA.2に登録されている機能情報のリストがUA.1に返される。
そして、図18のS1806に示すように、UA.1は、上記S1804〜S1805の処理を、上記S1803にて取得したアプリケーションの数だけ繰り返し実行すると、S1807に処理を進める。
S1807では、UA.1は、上記S1806で各UAから収集した機能情報リストを元にマップを生成する。このマップには、各UAに登録されているそれぞれの機能情報のリスト情報が描かれる。
上記S1807で生成されるマップを図21(a)に例示する。
図21(a)に示すように、左から4列(2101〜2104)には、各UAから取得できた機能情報が記されており、レコードごとにユニークに全ての機能情報が登録されている。ここでは、機能情報に対応する提供機能の名称2101、提供機能の接続先URI2102、Web Intentsリクエストを受け付ける際のアクション(Action)2103、データ型(Type)2104などが記録されている。左から5列目以降(2105〜2107)については可変であり、アプリケーション(UA)の数分列が登録され、各UAにそのレコードに対応する機能情報が登録されているか否かを示すマップとなっている。図18のS1807でマップが作成された際には、マップは初期の登録状態を表したものとなっており、それぞれのUAに各機能情報が登録されているか、否かが記されている。登録されている場合には「Yes」が記されており、登録されていない場合には「No」が記載されている。
S1808にて、UA.1は、マップを利用してUA.1に登録のない機能情報を抽出し、その機能情報がどのアプリケーションに登録されているかを取得する。S1809にて、UA.1は、UA.1に登録のない機能情報の登録されているアプリケーション(ここではUA.2とする)に対し、その機能情報の取得要求を、インテントを利用して発行する。S1810にて、UA.2は、上記S1809の取得要求に対する応答として、機能情報を返し、UA.1は、この応答を受信する。
ここで、S1808〜S1809について図20(b)を用いて詳細に説明する。
図20(b)に示すように、S1809にて、UA.1は、アクション「Pick」で、データタイプ「Web Intents Service」のインテント要求を発行する。ここでは、ある特定の機能情報(上述したUA.1に登録のない機能情報)を指定してUA.2に要求を発行する。また、S1810では、UA.1はS1809にて発行したインテントの応答として、上記指定した機能情報を受信する。なお、上記S1809〜S1810の処理は、UA.1に登録されていない機能情報の複数あり、それらが、それぞれ異なるアプリケーションで管理されているような場合には、UA.1に登録されていない全ての機能情報の取得が完了するまで、何度でも実行されるものとする。
次に、図18のS1811では、UA.1は、上記S1810で取得した機能情報をUA.1が管理する機能情報として登録し、さらに上記S1807で作成したマップ情報を更新する。ここで更新したマップの状態を、図21(b)に示す。図21(b)では、上述した図21(a)の状態では2レコード目でUA.1が管理していなかった「Photo Shares」の機能情報が更新され、URI2102、アクション2103、データタイプ2104などが追記され、UA.1での登録状態2105も「Yes」へと更新されている。
次に、UA.1は、S1812にて、OS部901に対してインテントを利用して機能情報の登録受付を行うアプリケーションのリストを取得要求する。この要求に応じて、OS部901は、S1813にて、インテント情報入出力部904を介して機能情報の登録受付が可能なアプリケーションのリストをアプリケーション情報格納部905から取得し応答する。そして、UA.1は、この応答(アプリケーションリスト)を受信すると、S1814に処理を進める。
S1814では、UA.1は、上記取得したリスト内の各アプリケーションの登録にない機能情報リストを抽出する。図21(b)に示した例で説明すると、UA.3 register列2107の「No」に相当するレコードに対応する機能情報のリスト(「Intens Service」,「Photo Shares」)を抽出する。
次に、S1815にて、UA.1は、上記リスト内のアプリケーションの1つ(ここではUA.2)に対して機能情報リストの登録要求を発行する。この要求に応じて、UA.2は、S1816にて、機能情報を登録し登録結果を応答する。そして、UA.1は、この応答を受信する。
ここで、S1815〜S1816について図20(c)を用いて詳細に説明する。
図20(c)に示すように、S1815にて、UA.1は、対象となるアプリケーション(ここではUA.2とする)に対して、アクション「Share」で、データタイプ「Web Intents Service」のインテント要求で、特定の機能情報(そのアプリケーションの登録されていない機能情報)とともに登録要求を発行する。S1816では、上記S1815で発行したインテントの応答として登録結果がUA.1に返される。
そして、図18のS1817に示すように、UA.1は、上記S1815〜S1816の処理を、上記S1813にて取得したアプリケーション毎に、上記S1814で抽出した機能情報の数だけそれぞれ繰り返し実行し、S1818に処理を進める。
S1818では、UA.1は、マップを更新し同期処理を完了させる。このときのマップの状態は、最終的に図21(c)に記載した状態となり、機能情報の統合が完了する。
<実施例3のUAの処理フローチャートの例>
図22は、UAがユーザからの「サービス情報の取込/共有」指示を受信してから機能情報の取込/共有処理が終了するまでの処理を例示するフローチャートである。なお、図22及び後述する図23〜図25に示すフローチャートの処理は、図7に示す情報処理端末501内のソフトウェアの処理の一部を示したものである。これらのフローチャートの処理は、情報処理端末501のCPU802が、ROM803、記憶装置809等に記憶されたプログラムを必要に応じてRAM804に展開して実行することにより実現される。
図22のフローチャートでは、処理を大きく3つの処理に分けて説明する。
まず、UA.1は、S2401にてユーザによる「サービス情報の取込/共有」メニュー1901の押下を検知すると、ユーザより機能情報の取込/共有の指示があったと判断し、まずS2402の「機能情報の取得/共有のためのマップ生成処理」を行う(詳細は図23に示す)。次に、UA.1は、S2403の「各アプリケーションからの機能情報の取得処理」を行う(詳細は図24に示す)。さらに、UA.1は、S2404の「各アプリケーションへWeb Intentsサービス情報の共有処理」を行う(詳細は図25に示す)。そして、UA.1は、S2405において、機能情報の取得/共有処理を終了する。
以下、上記S2402、S2403、S2404の処理を、各詳細フローチャートを利用して説明する。
<機能情報の取得/共有のためのマップ作成処理のフローチャートの例>
図23は、図22のS2402の機能情報の取得/共有のためのマップ生成処理の詳細を表すフローチャートである。
S2420にて、UA.1の中央処理部907は処理を開始すると、S2421へ処理を進める。S2421で、中央処理部907は、情報処理端末501にインストールされている各アプリケーションにて管理されている機能情報を収集し一括して管理するためのマップテーブルを作成する。このマップとは、図21(a)にて説明したように機能情報と各UAの登録情報を記録するマップである。このマップを初期化し準備が完了したら、中央処理部907は、処理をS2422へ進める。
S2422では、中央処理部907は、OS部901に対してアクションを「Pick」、データタイプを「Web Intents Service」としてインテントのリクエストを発行し、処理をS2423へ進める。S2423では、中央処理部907は、OS部901からインテントリクエストした応答として、1以上のアプリケーションの情報(アプリケーションのリスト)を受信したか否かを判定する。
そして、OS部901から1以上のアプリケーションの情報を受信できなかったと判定した場合(S2423でNoの場合)、中央処理部907は、処理をS2424へ進める。この場合は、インテントで対応するアプリケーションを探したが情報処理端末501内に対応するアプリケーションが存在しないことがわかった場合である。これは、機能情報を取得/共有するためのアプリケーションが情報処理端末501にインストールされていない環境を意味する。したがって、S2424では、中央処理部907は、ユーザに取得/共有することができない旨の通知し(例えばメッセージを画面表示し)、機能情報の取得/共有処理を終了する(S2424)。
一方、上記S2423にてOS部901から1以上のアプリケーションの情報を受信したと判定した場合(S2423でYesの場合)、中央処理部907は、処理をS2425へ進める。S2425では、中央処理部907は、上記取得したアプリケーションの情報をリスト化し(2順目以降では行わない)、そのリストから任意に1つのアプリケーションを選択し、処理をS2426へ進める。
S2426では、中央処理部907は、上記S2425にて選択したアプリケーションに対して、アクション「Pick」、データタイプを「Web Intents Service」としインテントを利用した、機能情報リストの取得要求を発行する。そして、処理をS2427へ進める。S2427では、中央処理部907は、上記S2426で取得要求を行ったアプリケーションから機能情報リストを受信できたか否かを判断する。
そして、機能情報のリストを受信できなかったと判断した場合(S2427でNoの場合)、中央処理部907は、処理をS2429へ進める。一方、機能情報のリストを受信したと判断した場合(S2427でYesの場合)、中央処理部907は、処理をS2428へ進める。S2428では、中央処理部907は、上記S2425で選択したアプリケーションとそのアプリケーションから取得できた機能情報のリストを関連付けてマップの更新処理を行う。この更新処理が完了すると、中央処理部907は、処理をS2429へ進める。
S2429では、中央処理部907は、上記S2425で選択したアプリケーションをアプリケーションリストの中から削除し、処理をS2430へ進める。S2430では、中央処理部907は、アプリケーションリスト内の情報が空になっているか否かを判断する。そして、アプリケーションリスト内にまだアプリケーションがあると判断した場合(S2430でNoの場合)、中央処理部907は、処理をS2425へ戻す。
一方、上記S2430にて、アプリケーションリスト内にアプリケーションがないと判断した場合(S2430でYesの場合)、中央処理部907は、機能情報の取得/共有のためのマップ生成処理を終了し(S2431)、処理を図22のS2403へ進める。
次に、図22のS2403について図24を用いて説明する。
<各アプリケーションからの機能情報の取得処理のフローチャートの例>
図24は、図22のS2403の各アプリケーションからの機能情報の取得処理の詳細を表すフローチャートである。
S2461にて、UA.1の中央処理部907は処理を開始すると、S2462へ処理を進める。S2462では、中央処理部907は、マップ(図22のS2402で生成されたマップ)に登録されている機能情報のうち、UA.1に登録されていない機能情報(ここでは名称)を取得し、処理をS2463へ進める。S2463では、中央処理部907は、上記S2462にて1つ以上の機能情報の情報(機能情報のリスト)を取得できたか否かを判断する。
そして、1つ以上の機能情報の情報を取得できなかったと判断した場合(S2463でNoの場合)中央処理部907は、処理をS2471に進める。この場合、情報処理端末501内の各UAに登録されている全ての機能情報をUA.1は既に管理していることになる。したがって、この場合、中央処理部907は、S2471にて、各アプリケーションからの機能情報の取得処理を終了させる(S2471)。
一方、上記S2463にて、1つ以上の機能情報の情報を取得したと判断した場合(S2463でYesの場合)、中央処理部907は、処理をS2464へ進める。S2464では、中央処理部907は、上記S2462で取得した機能情報の情報(名称)をリスト化し(2順目以降では行わない)、任意の機能情報を1つ選択する。そして、処理をS2465へ進める。
S2465では、中央処理部907は、上記マップから、上記S2464にて選択した機能情報を管理しているアプリケーションの情報を取得し、処理をS2466へ進める。S2466では、中央処理部907は、上記S2465にて取得したアプリケーションに対して、アクション「Pick」、データタイプ「Web Intents Service」とし、インテントを利用した、機能情報の取得要求を発行する。そして、処理をS2467へ進める。
S2467では、中央処理部907は、上記S2466にて発行した取得要求の応答として機能情報を受信したか否かを判断する。そして、機能情報を受信できなかったと判定した場合(S2467でNoの場合)、中央処理部907は、処理をS2469へ進める。
一方、上記S2467にて、機能情報を受信したと判断した場合(S2467でNoの場合)、中央処理部907は、処理をS2468へ進める。S2468では、中央処理部907は、上記S2467にて取得した機能情報を用いて上記マップの情報を更新し、処理をS2469へ進める。また、中央処理部907は、上記S2467にて取得した機能情報を、サービス情報入出力部910を介してサービス情報格納部911に登録する。
S2469で、中央処理部907は、上記S2463で取得した機能情報のリストから、上記S2464にて選択した機能情報の情報を削除し、処理をS2470へ進める。S2470では、上記S2464にて作成した機能情報のリスト内にまだ機能情報が残っているか否かを判断する。そして、まだリスト内に機能情報が残っていると判断した場合(S2470でNoの場合)、中央処理部907は、処理をS2464へ戻す。
一方、上記S2470にて、リスト内に機能情報が残っていないと判断した場合(S2470でYesの場合)、中央処理部907は、各アプリケーションからの機能情報の取得処理を終了し(S2471)、処理を図22のS2404へ進める。
次に、図22のS2404について図25を用いて説明する。
<各アプリケーションへの機能情報の共有処理のフローチャートの例>
図25は、図22のS2404の各アプリケーションへの機能情報の共有処理の詳細を表すフローチャートである。
S2481にて、UA.1の中央処理部907は処理を開始すると、S2482へ処理を進める。S2482では、中央処理部907は、図22のS2403で更新されたマップに登録されている機能情報で登録していない機能情報があるアプリケーションを、上記マップから取得し、処理をS2483へ進める。
S2483では、中央処理部907は、マップから取得できたアプリケーションが1つ以上存在するか否かを判断する。そして、1つ以上のアプリケーションを取得できなかったと判断した場合(S2483でNoの場合)、中央処理部907は、そのまま、各アプリケーションへの機能情報の共有処理を終了する(S2493)。この場合、情報処理端末501内に登録されている全ての機能情報は全てのアプリケーションで共有されていることになるため、処理を終了する。
一方、上記S2483にて、1つ以上のアプリケーションを取得したと判断した場合(S2483でYesの場合)、中央処理部907は、処理をS2484へ進める。S2484では、中央処理部907は、上記S2483で取得した1つ以上のアプリケーションの情報をリスト化し(2順目以降では行わない)、そのリストから任意のアプリケーションを1つ選択し、処理をS2485へ進める。
S2485では、中央処理部907は、上記S2484で選択したアプリケーションに対して登録すべき機能情報(そのアプリケーションに登録されていない機能情報)の情報(名称)を、上記マップから取得し、処理をS2486へ進める。S2486では、中央処理部907は、上記S2485で取得した結果、1つ以上の機能情報の情報(機能情報のリスト)を取得できたか否かを判断する。そして、1つ以上の機能情報の情報が取得できなかったと判断した場合(S2486でNoの場合)、中央処理部907は、処理をS2491へ進める。
一方、上記S2486で、1つ以上の機能情報の情報を取得できたと判断した場合(S2486)、中央処理部907は、処理をS2487へ進める。S2487では、中央処理部907は、上記S2484にて選択したアプリケーションに登録すべき機能情報の情報(上記S2485で取得)をリスト化し(2順目以降では行わない)、該リストから任意に1つの機能情報を選択し、処理をS2488へ進める。
S2488では、中央処理部907は、上記S2484にて選択したアプリケーションに対して、アクション「Pick」、データタイプを「Web Intents Service」とし、インテントを利用し、機能情報(上記S2487で選択)の登録要求を発行する。これにより、上記S2484にて選択したアプリケーションに上記S2487で選択した機能情報を登録する。そして、処理をS2489へ進める。
S2489では、中央処理部907は、上記機能情報のリストから上記S2487にて選択した機能情報を削除し、処理をS2490へ進める。S2490では、中央処理部907は、機能情報のリストに機能情報がなくなったか否かを判断する。そして、まだ機能情報のリストに機能情報が残っていると判断した場合(S2490でNoの場合)、中央処理部907は、処理をS2487へ戻す。
一方、上記S2490にて、機能情報のリストに機能情報が残っていないと判断した場合(S2490でYesの場合)、中央処理部907は、処理をS2491へ進める。S2491では、中央処理部907は、上記S2484で作成したアプリケーションのリストから上記S2484で選択したアプリケーションを削除し、処理をS2492へ進める。S2492では、中央処理部907は、上記S2484で作成したアプリケーションリスト内にアプリケーションが残っているか否かを判断する。そして、アプリケーションのリスト内にまだアプリケーションが残っていると判断した場合(S2492でNoの場合)、中央処理部907は、処理をS2484へ戻す。
一方、上記S2492にて、アプリケーションのリスト内にアプリケーションが残っていないと判断した場合(S2492でYesの場合)、中央処理部907は、各アプリケーションへの機能情報の共有処理を終了し(S2493)、処理を図22のS2405へ進める。図22のS2405では、中央処理部907は、機能情報の取得/共有処理を終了する。
以上示したように、実施例3によれば、同じ情報処理端末内に複数のUAが存在する場合に、ユーザが所望のタイミングで或るUAから指示することにより、インテントを利用して、他の1つ以上のUAから自UAに登録されていない機能情報を取得して登録するとともに、他のUAにまだ登録されていない機能情報を自UAから他のUAに提供することができる。
上記実施例3では、インテントを利用して他のUAと機能情報を同期する構成について説明した。これに対し、実施例4では、Web Intentsを利用して他のUAと機能情報を同期する構成について説明する。
<実施例4おける機能情報の相互利用に関するシーケンス図の例>
図26は、実施例4において情報処理端末501のユーザがあるWebブラウザを用いて他のWebブラウザと登録されている機能情報を同期させるためのシーケンス図である。なお、図18と同一のステップには同一のステップ番号を付してある。以下、図18と異なる部分のみ説明する。
また、図27、図28は、図26のシーケンスの一部の詳細シーケンス図である。
S1801の処理は、図18と同様であるので説明を省略する。実施例4の情報処理端末501では、ローカルエリアネットワーク(Local Network)1501から機能情報を提供可能なアプリケーションまたはサービス(以下、単にサービスという)を探索する。具体的には、S1801にて、UA.1は、「サービス情報の取込/共有」メニュー1901(図19(b))が押下されたことを検知すると、S2301にて、Local Network1501に対してサービスの探索を実行する。このネットワーク探索に関して、以下、図27(a)を用いて詳細に説明する。
図27(a)に示すように、UA.1は、S2301にて、Local Network1501に対してサービスの探索を行う。ここでは、例えば、Apple社のゼロ・コンフィギュレーション技術であるBonjourにおけるMulticastDNSなどの技術を用いてリンクローカル内のネットワークサービスを探索する。
S2302にて、UA.1は、各サービスから応答を受ける。本実施例では、Local Network1501内で探索を行うので、同じ情報処理端末内のサービスから応答を受けることの他に、ネットワークの届く範囲にあるサービスからも応答を受けることができる。このネットワークの範囲は、ここでは限定しない。なお、UA.1は、上記探索結果として収集したサービスから機能情報を提供可能なサービスのリストと、機能情報を登録可能なサービスのリストを生成しておくものとする。
次に、図26のS2303では、UA.1は、探索結果として収集した機能情報を提供可能なサービスのリストから1つのサービスを選択し、該選択したサービスを提供しているアプリケーション(ここではUA.2とする)に対して、登録されている機能情報リストの取得要求を発行する。そして、S2304にて、UA.1は、機能情報のリストの応答を受信する。
以下、上記S2303〜S2304について図27(b)を用いて詳細に説明する。
図27(b)に示すように、UA.1は、S2303にて、選択した1つのアプリケーション(ここではUA.2とする)に対して、アクション「Pick」でデータタイプを「application/Web Intents Service」のWeb Intents要求を発行する。S2304では、UA.1は、UA.2からWeb Intentsの要求の応答として、UA.2に登録されている機能情報リストを受信する。
次のS1806〜S1808は、図18と同様であるので説明を省略する。
次に、S2305では、UA.1は、自身に登録されていない機能情報を管理するサービス(ここではUA.2とする)に対して、該機能情報の取得要求を、Web Intentsのリクエストとして発行する。S2306では、UA.2は、上記S2305の取得要求に対する応答として機能情報を返す。
以下、上記S2305〜S2306について図28(a)を用いて詳細に説明する。
図28(a)に示すように、S2305にて、UA.1は、アクション「Pick」、データタイプ「Web Intents Service」のWeb Intentsリクエストで、ある特定の機能情報(UA.1に登録されていない機能情報)を指定して取得要求する。また、S2306では、UA.1は、UA.2から、上記S2305にて発行したWeb Intentsリクエストの応答として、指定した機能情報を受信する。
次のS1811、S1814は、図18と同様であるので説明を省略する。なお、図18のシーケンス図では、S1812、S1813にて、UA.1は、インテントを利用して機能情報を登録可能なアプリケーションリストを要求しているが、図26のシーケンスでは、これらの処理は行わない。図26のシーケンスでは、S2301〜S2302の探索の際に、必要な情報を収集することができるから、再度、探索して機能情報を登録可能なアプリケーションリストを取得する必要がないためである。
次に、S2307では、UA.1は、各サービスに対して機能情報の登録要求を発行する。S2308で、UA.1は、上記S2307で発行した要求の応答を受信する。
以下、上記S2307〜S2308について図28(b)を用いて詳細に説明する。
図28(b)に示すように、S2307にて、UA.1は、対象となるサービス(ここではUA.2とする)に対して、アクション「Share」で、データタイプ「Web Intents Service」のWeb Intents要求で、特定の機能情報(そのサービスに登録されていない機能情報)とともに、登録要求を発行する。S2308では、上記S2307で発行したWeb Intents要求の応答として登録結果がUA.1に返される。
そして、図18のS2309に示すように、UA.1は、上記S2307〜S2308の処理を、機能情報の登録処理が可能なサービス毎に、上記S1814で抽出した機能情報の数だけそれぞれ繰り返し実行し、S1818に処理を進め、UA.1による機能情報の取込/共有処理が完了すると、処理を終了する。
以上示したように、実施例4によれば、同じ情報処理端末内に複数のUAが存在する場合に、ユーザが所望のタイミングで或るUAから指示することにより、Web Intentsを利用して、他の1つ以上のUAから自UAに登録されていない機能情報を取得して登録するとともに、他のUAにまだ登録されていない機能情報を自UAから他のUAに提供することができる。
なお、実施例3及び実施例4では、ユーザによる「サービス情報の取込/共有」メニュー1901の押下を検知すると、機能情報の取得/共有処理を実行する構成について説明した。しかし、機能情報の取得/共有処理を、設定等に応じて定期的に実行する構成でもよい。これにより、ユーザからの指示がなくても自動的に複数の中継機能において機能情報の相互利用を実現することができる。
上記各実施例では、情報処理端末501の内部のアプリケーション間で機能情報を相互利用する構成を示した。ここでの相互利用とは、実施例1,2では他のアプリケーションへの登録を示し、実施例3,4では、他のアプリケーションからの取込み及び他のアプリケーションへの登録を示すものであった。しかし、ユーザが機能情報を相互利用しようとしたときには、必ずしも相互利用の相手がアプリケーションである必要はなく、インターネット上のサービスであってもよい。
例えば、実施例1,2では、UAとしてのWebブラウザに機能情報を登録する際、インターネット上の機能情報リストを管理するサービスにも上記機能情報を登録しておく。また、実施例3,4では、「サービスの取込/共有」を実行したときに、インターネット上の機能情報を管理するサービスを対象に取得、提供を行う。このようにすることで、機能情報リストの相互利用先はアプリケーション同士でなくても可能となり、実施例1〜4と同様の効果を得ることができる。
実施例2、4に示したように、機能情報リストをWeb Intentsを利用して取得しようとした場合、あるWebブラウザで利用可能な機能情報が、自Webブラウザでは利用できないケースがある。例えば、情報処理端末501内に存在するサービスが提供する機能のURLが、ローカルループバックアドレス(http://127.0.0.1/〜)を示すURLであったとする。このようなURLを含む機能情報を、要求元のWebブラウザに提供したとしても、提供されたWebブラウザ(要求元のWebブラウザ)では、ネットワークを介して該機能情報に対応するサービスの提供機能を利用することができない。
このような場合には、提供する側のWebブラウザは、機能情報を要求している側(要求側)の条件に応じて、利用可能な機能情報のみを提供するように構成する。また、サービスが提供する機能では、URLだけでなく、特別なactionやtypeを規定して利用する場合がある。よって、提供側は、要求側が要求するactionやtypeに応じて要求側の利用可能な機能情報のみを提供するように構成する。以上のような構成により、上述したように要求元で利用できない機能情報が無駄に登録されてしまうことを防止することができ、利用者の利便性を向上させることができる。
また、機能情報の提供を受けたWebブラウザが、機能情報を取得した場合に自身で利用可能か判別し、利用不可能な機能情報であった場合には、該機能情報をユーザに選択肢(例えば図10(b)の画面のUAリスト1104)として表示しないといった回避方法も考えられる。この構成でも、同様に、要求元で利用できない機能情報が無駄に登録されてしまうこと等を防止することができ、利用者の利便性を向上させることができる。
実施例3,4では、他のWebブラウザに登録されている機能情報を他のWebブラウザから自Webブラウザに取り込み、逆に、自Webブラウザに登録されている機能情報を他のWebブラウザに登録要求することで、機能情報の相互利用を実現する構成を示した。これにより、登録している機能情報の統合を実現することができる。しかし、その他の相互利用の方法として、複数のWebブラウザ間で、それぞれが管理する機能情報を同期して一致させることで、効果的な使用方法を提供できる。Webブラウザに新しく登録した機能情報や、Webブラウザから削除した機能情報をそれぞれ記憶しておき、「サービス情報の取込/共有」を実施する際に、上記記憶しておいた新しく登録した機能情報を各Webブラウザでも同様に登録要求する。また、上記記憶しておいた以前に削除した機能情報が他のWebブラウザに登録されていた場合には、他のWebブラウザから削除するようにすることにより、機能情報の同期を行う構成も、本発明に含まれるものである。
以上示したように、本発明によれば、Web Intentsなどの新しい連携の仕組みを提供する中継機能が情報処理端末内に複数存在する場合、同じ機能情報の登録処理を複数の中継機能で実行させる等の制御を行うことにより、それら中継機能の間で機能情報の少なくとも一部を適切に共有することを可能とする。この結果、ユーザは中継機能毎に同一の機能情報の登録を繰り返す必要もなくなり、ユーザの利便性が向上する。よって、現在、提案されているWeb Intentsなどの新しい連携の仕組みについて、ユーザビリティを向上させることができる。
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。
(他の実施例)
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形(各実施例の有機的な組合せを含む)が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。