(57)【特許請求の範囲】
【請求項１】
端末に搭載されたコンピュータで、
前記端末に含まれるアプリケーションに対して前記端末で検出したデバイスの利用が予め許可されている場合に、前記アプリケーションから、前記デバイスに対応した予め定めたタグが含まれる位置を特定し、
前記アプリケーションの特定した位置に、前記予め定めたタグに対応した前記デバイスを利用するためのロジックを挿入する
アプリケーション機能拡張方法。
【請求項２】
前記端末に含まれる表示装置に、前記デバイスに対応付けた識別画像を表示し、
前記アプリケーションから、ユーザによって選択された識別画像で表される前記デバイスに対応した前記予め定めたタグが含まれる位置を特定する
請求項１に記載のアプリケーション機能拡張方法。
【請求項３】
前記端末に含まれる表示装置に、前記アプリケーションと、前記デバイスと、の連携開始の指示を受け付ける画面アイテムを表示する
請求項１又は請求項２に記載のアプリケーション機能拡張方法。
【請求項４】
前記端末は撮像装置を備え、
前記撮像装置で撮像した画像からデバイスを検知する
請求項１〜請求項３の何れか１項に記載のアプリケーション機能拡張方法。
【請求項５】
前記検知したデバイスを前記端末に含まれる表示装置に強調表示する
請求項４記載のアプリケーション機能拡張方法。
【請求項６】
端末に搭載されたコンピュータに、
前記端末に含まれるアプリケーションに対して前記端末で検出したデバイスの利用が予め許可されている場合に、前記アプリケーションから、前記デバイスに対応した予め定めたタグが含まれる位置を特定し、
前記アプリケーションの特定した位置に、前記予め定めたタグに対応した前記デバイスを利用するためのロジックを挿入する
ことを含む処理を実行させるためのアプリケーション機能拡張プログラム。
【請求項７】
端末に含まれるアプリケーションに対して検知部で検知したデバイスの利用が予め許可されている場合に、前記アプリケーションから、前記デバイスに対応した予め定めたタグが含まれる位置を特定する特定部と、
前記特定部で特定した前記アプリケーションの位置に、前記予め定めたタグに対応した前記デバイスを利用するためのロジックを挿入する挿入部と、
を含むアプリケーション機能拡張装置。
【発明の詳細な説明】
【技術分野】
【０００１】
開示の技術は、アプリケーション機能拡張方法、アプリケーション機能拡張プログラム、及びアプリケーション機能拡張装置に関する。
【背景技術】
【０００２】
近年、スマートフォン及びタブレット端末等の携帯情報端末の高性能化に伴い、これまでパーソナルコンピュータが担っていた情報処理の一部を、携帯情報端末で実行する機会が増加している。多くの場合、携帯情報端末で実行されるアプリケーションは、インターネット等の通信回線を経由して接続されたサーバ等と連携して情報を処理するＷｅｂ(World Wide Web)アプリケーション（以降、「アプリケーション」と表す）である。そのため、ネットワークを利用するアプリケーションに適した情報処理の形態が検討されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−５０２４１号公報
【特許文献２】特開２０１３−８１１２７号公報
【特許文献３】特開２０１３−２３５３８７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
携帯情報端末でアプリケーションを実行する際、ユーザはアプリケーションで扱われる情報を、プリンタ、外部スピーカ、外部モニタ等、携帯情報端末に接続される周辺デバイス（以降、「デバイス」と表す）に出力したい場合が生じることがある。【０００５】
しかしながら、アプリケーションにデバイスを制御するためのコード（ロジック）が含まれていなければ、例えデバイスに対応するドライバが携帯情報端末にインストールされていたとしても、携帯情報端末からデバイスを利用することができない。【０００６】
しかも、アプリケーションにロジックを追加するためにはアプリケーションを改修する必要があるため、アプリケーションに関する専門的知識を持たない携帯情報端末のユーザではアプリケーションの改修が困難となる場合が多い。【０００７】
一つの側面として、開示の技術は、デバイスとの連携が考慮されていないアプリケーションであっても、アプリケーションを改修することなくアプリケーションからデバイスが利用できるように、アプリケーションの機能を拡張することを目的とする。
【課題を解決するための手段】
【０００８】
一つの態様では、コンピュータに、端末に含まれるアプリケーションから、前記端末で検知したデバイスに対応した予め定めたタグが含まれる位置を特定させる。そして、コンピュータに、アプリケーションの特定した位置に、予め定めたタグに対応したデバイスを利用するためのロジックを挿入させる。
【発明の効果】
【０００９】
一つの側面として、開示の技術は、デバイスとの連携が考慮されていないアプリケーションであっても、アプリケーションを改修することなくアプリケーションからデバイスが利用できるように、アプリケーションの機能を拡張できる、という効果を有する。
【図面の簡単な説明】
【００１０】
【図１】第１実施形態及び第２実施形態に係るＷｅｂシステムの構成例を示す図である。
【図２】対応デバイスＤＢのデータ構造の一例を示す図である。
【図３】デバイス制御ロジックの一例を示す図である。
【図４】デバイス制御ロジックリストＤＢのデータ構造の一例を示す図である。
【図５】ドライバＤＢのデータ構造の一例を示す図である。
【図６】第１実施形態及び第２実施形態に係る端末をコンピュータで実現する場合の構成例を示す図である。
【図７】第１実施形態に係るアプリケーション機能拡張処理の流れの一例を示すフローチャートである。
【図８】アプリケーションにプリンタのロジックが挿入される前の端末の一例を示す図である。
【図９】アプリケーションにプリンタのロジックが挿入された後の端末の一例を示す図である。
【図１０】アプリケーションに外部スピーカのロジックが挿入される前の端末の一例を示す図である。
【図１１】アプリケーションに外部スピーカのロジックが挿入された後の端末の一例を示す図である。
【図１２】アプリケーションに外部モニタのロジックが挿入される前の端末の一例を示す図である。
【図１３】アプリケーションに外部モニタのロジックが挿入された後の端末の一例を示す図である。
【図１４】デバイス制御ロジックの一例を示す図である。
【図１５】クロスサイトリクエストの一例を示す図である。
【図１６】ＣＯＲＳを適用したクロスサイトリクエストの一例を示す図である。
【図１７】第２実施形態に係るアプリケーション機能拡張処理の流れの一例を示すフローチャートである。
【図１８】デバイスの選択画面の一例を示す図である。
【図１９】選択したデバイスとの連携を指示する画面の一例を示す図である。
【図２０】第３実施形態に係るＷｅｂシステムの構成例を示す図である。
【図２１】第３実施形態に係る端末をコンピュータで実現する場合の構成例を示す図である。
【図２２】第３実施形態に係るアプリケーション機能拡張処理の流れの一例を示すフローチャートである。
【図２３】端末で利用可能なデバイスを検知した場合の表示例を示す図である。
【図２４】アプリケーションとデバイスとの連携の際の表示例を示す図である。
【図２５】アプリケーションでのドライバの共有について説明するための模式図である。
【図２６】ロジックの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照して開示の技術の実施形態の一例を詳細に説明する。なお、機能が同じ働きを担う構成要素及び処理には、全図面を通して同じ符号を付与し、重複する説明を適宜省略する場合がある。
【００１２】
（第１実施形態）
携帯情報端末（以降、「端末」と表す）のアプリケーションからデバイスを利用するためには、端末内に利用するデバイスに対応したドライバを実装する必要がある。ドライバはデバイスを直接制御するための関数群を含み、アプリケーションはドライバに含まれる関数群を呼び出すことで、ドライバに対応したデバイスを利用する。このように、アプリケーションの開発者は、ドライバの関数群を経由してデバイスを利用することで、デバイスの詳細な制御手順はドライバの関数群に任せた上で、デバイスを利用することができる。従って、アプリケーションの開発者は、ドライバの関数群に相当するコードを自作する場合に比べて、アプリケーションの開発時間を短縮することができる。
【００１３】
ドライバは、アプリケーションとは独立に例えばデバイスの開発元等から供給される。従って、ドライバは、アプリケーションと異なるタイミングで端末内にインストールすることが可能となる。また、アプリケーションに、予め規定されたドライバの関数群を利用してデバイスを制御するためのコード、すなわちロジックを記述すれば、複数のアプリケーションで同じデバイスが利用可能となる。
【００１４】
図２５は、複数のアプリケーションで同じドライバを使用する状況を表した図である。図２５に示すように、アプリケーションＡで使用するドライバは、アプリケーションＡと分離した形態で存在するため、アプリケーションＢでも使用することが可能となる。従って、アプリケーションＡ及びアプリケーションＢに、ドライバを利用するロジックを記述しておくことで、ドライバに対応したデバイスを共有することができる。
【００１５】
図２６は、アプリケーションにおけるロジックの一例を示す図である。アプリケーションは図２６に示すように、例えばＨＴＭＬ(Hyper Text Markup Language)等のマークアップ言語で記述される。なお、図２６に示すアプリケーションの記述言語は一例である。アプリケーションの記述言語は、例えばＸＭＬ等のメタ言語、又はスクリプト言語等、アプリケーションの記述内容に従ってアプリケーションを実行する実行部（例えばブラウザ等）で解釈可能な言語であれば如何なる言語であってもよい。
【００１６】
図２６の例では、“<input ・・・>”で表されるinputタグに相当する行がロジックに相当する。例えばユーザが端末の画面に表示される「画像を印刷」と表記されたボタンを押すことで、ドライバのpicprint関数が呼び出され、“www.foo.com/pic1.jpg”で表される画像ファイルの画像がpicprint関数を含むドライバに対応したプリンタから出力される。
【００１７】
このように、例えばアプリケーションからプリンタを利用するには、アプリケーションにプリンタから画像を出力するためのロジックが予め含まれている必要がある。しかし、アプリケーションの中には、例えば端末の画面に画像を表示するだけで、プリンタ等のデバイスの利用を当初から想定していないアプリケーションも存在する。デバイスの利用を想定していないアプリケーションでデバイスを利用するためには、アプリケーションのコードを改修して、アプリケーションにデバイスに対応したロジックを追加する必要がある。しかし、アプリケーションに精通していない端末のユーザが、アプリケーションにデバイスに対応したロジックを追加するのは通常困難である。
【００１８】
以下では、アプリケーションにロジックが含まれない場合であっても、アプリケーションを改修することなくアプリケーションからデバイスが利用できるように、アプリケーションの機能を拡張する例について説明する。
【００１９】
図１は、第１実施形態に係るＷｅｂシステム１の構成例を示す図である。
【００２０】
図１に示すように、Ｗｅｂシステム１は、例えば端末１０、クラウドサーバ３０、デバイス４０、及び通信回線５０を含む。端末１０及びクラウドサーバ３０は、例えばインターネット回線である通信回線５０に接続され、通信回線５０を経由してデータの送受信を行う。また、端末１０及びデバイス４０も接続され、端末１０及びデバイス４０の間でデータの送受信を行う。
【００２１】
なお、通信回線５０の種類に制限はなく、例えばインターネット回線の他、イントラネット回線、又は専用線等のような回線であってもよく、更に、有線、無線、又は有線と無線との混在の何れの接続形態であってもよい。また、端末１０及びデバイス４０を接続する接続形態も、有線、無線、又は有線と無線との混在の何れの接続形態であってもよい。
【００２２】
端末１０は、例えば実行部１１、検知部１２、決定部１３、取得部１４、特定部１５、及び挿入部１６の各機能部を含む。また、端末１０は、例えば対応デバイスＤＢ(Database)２０、デバイス制御ロジックリストＤＢ２２、及びドライバＤＢの各ＤＢと、例えばクラウドサーバ３０のように通信回線５０に接続されるサーバから取得したアプリケーション１７と、を含む。
【００２３】
実行部１１は、アプリケーション１７のコードをメモリ１０４に展開して、メモリ１０４に展開されたアプリケーション１７を１行ずつ読み込み、読み込んだ行の記述内容を解釈しながらアプリケーション１７を実行する。なお、実行部１１は、アプリケーション１７を実行する際、検知部１２を呼び出す。
【００２４】
検知部１２は、実行部１１から呼び出されると端末１０に接続可能なデバイス４０を検知すると共に、対応デバイスＤＢ２０を参照して、検知したデバイス４０が端末１０に対応しているか、すなわち検知したデバイス４０が端末１０で利用可能か否かを検知する。
【００２５】
図２は、対応デバイスＤＢ２０におけるデータ構造の一例を示す図である。対応デバイスＤＢ２０は、例えば端末１０に対応したデバイス名が記載された情報（対応デバイス情報）を含む。検知部１２は、検知したデバイス４０のデバイス名が対応デバイス情報に含まれていれば、端末１０に対応するデバイス４０を検知したと判定する。なお、対応デバイス情報に含まれるデバイス名に重複はなく、デバイス名から一意にデバイス４０を特定することができる。
【００２６】
検知部１２は、端末１０に対応するデバイス４０を検知した場合、検知したデバイス４０のデバイス名を決定部１３に出力する。
【００２７】
決定部１３は、デバイス制御ロジックリストＤＢ２２を参照して、検知部１２から受け付けたデバイス名に対応するデバイス制御ロジック３４が既に端末１０内に存在するか否かを判定する。
【００２８】
ここで、デバイス制御ロジック３４とは、デバイス４０を制御するためのコード、すなわちロジックと、アプリケーション１７におけるロジックの挿入位置を示すタグと、を対応づけた情報（ロジック対応情報）を含む情報である。
【００２９】
図３に、デバイス制御ロジック３４の一例を示す。図３に示すデバイス制御ロジック３４は、ドライバ３２の関数群を呼び出してアプリケーション１７からデバイス４０を利用するためのロジックと、タグと、を行方向に対応づける。
【００３０】
なお、図３に示すデバイス制御ロジック３４において、‘Ｘ’及び‘Ｙ’の記号は、デバイス４０への出力対象となるリソースのファイル名を表す。また、図３に示すデバイス制御ロジック３４には２つのロジック対応情報が含まれているが、デバイス制御ロジック３４に含まれるロジック対応情報の数に制限はない。また、図３に示すデバイス制御ロジック３４のロジックはＨＴＭＬ言語で記述されているが他の言語でもよく、ロジックを記述したファイルのＵＲＬ(Uniform Resource Locator)を指定する情報であってもよい。
【００３１】
図４は、デバイス制御ロジックリストＤＢ２２のデータ構造の一例を示す図である。デバイス制御ロジックリストＤＢ２２は、例えばデバイス名と、デバイス名に対応するデバイス制御ロジック３４と、を対応付ける。決定部１３は、デバイス制御ロジックリストＤＢ２２のデバイス名欄に検知部１２から入力されたデバイス名が含まれる場合、検知部１２から入力されたデバイス名に対応するデバイス制御ロジック３４が端末１０内に存在すると判定する。そして、決定部１３は、検知部１２から入力されたデバイス名を特定部１５に出力する。
【００３２】
一方、検知部１２から入力されたデバイス名に対応するデバイス制御ロジック３４が端末１０内に存在しない場合、決定部１３は、検知部１２から入力されたデバイス名を取得部１４に出力する。
【００３３】
取得部１４は、決定部１３から入力されたデバイス名に対応したドライバ３２及びデバイス制御ロジック３４を取得する。一例としてドライバ３２及びデバイス制御ロジック３４は、デバイス名毎にクラウドサーバ３０に予め用意され、取得部１４は、デバイス名に対応したドライバ３２及びデバイス制御ロジック３４をクラウドサーバ３０から取得する。
【００３４】
取得部１４は、取得したデバイス制御ロジック３４をデバイス名と対応づけ、デバイス制御ロジックリストＤＢ２２に格納する。更に、取得部１４は、取得したドライバ３２をドライバＤＢ２４に格納すると共に、デバイス名とドライバ３２を対応づける情報（ドライバ対応情報）をドライバＤＢ２４に格納する。
【００３５】
図５は、ドライバＤＢ２４のデータ構造の一例を示す図である。ドライバＤＢ２４ではデバイス名とドライバ３２とが行方向に対応づけられ、例えば図５に示す例では、デバイス名“dev1”に対応するドライバは“dev1.drv”であることを示している。
【００３６】
取得部１４は、決定部１３から入力されたデバイス名に対応したドライバ３２及びデバイス制御ロジック３４を取得した後、例えば取得終了を知らせる通知を決定部１３に出力する。
【００３７】
決定部１３は、取得部１４から通知を受け付けると、検知部１２から入力されたデバイス名を特定部１５に出力する。
【００３８】
特定部１５は、デバイス制御ロジックリストＤＢ２２を参照して、決定部１３から入力されたデバイス名に対応したデバイス制御ロジック３４を取得する。そして、特定部１５は、メモリ１０４に展開されたアプリケーション１７のコードを読み込み、アプリケーション１７にデバイス制御ロジック３４のタグと同じコードが含まれるか否かを判定する。
【００３９】
アプリケーション１７にデバイス制御ロジック３４のタグと同じコードが含まれる場合は、特定部１５はアプリケーション１７におけるタグと同じコードが含まれる行の行番号を特定する。この際、特定部１５は、ドライバ対応情報を参照して、決定部１３から入力されたデバイス名に対応したドライバ３２をドライバＤＢ２４から取得してメモリ１０４に展開することで、取得したドライバ３２をアプリケーション１７から利用可能にする。
【００４０】
そして、特定部１５は、特定した行番号及び決定部１３から入力されたデバイス名に対応したデバイス制御ロジック３４のロジックを挿入部１６に出力する。
【００４１】
挿入部１６は、メモリ１０４に展開されたアプリケーション１７に対して、特定部１５から受け付けたロジックを、特定部１５から受け付けた行番号の次の行に挿入する。アプリケーション１７へのロジック挿入後、挿入部１６はアプリケーションの再読み込みを指示する通知を実行部１１に出力する。
【００４２】
実行部１１は、挿入部１６から通知を受け付けると、メモリ１０４に展開されたロジック挿入後のアプリケーション１７を再読み込みし、アプリケーション１７を実行する。
【００４３】
一方、クラウドサーバ３０は、デバイス名に対応するドライバ３２及びデバイス制御ロジック３４を含む。クラウドサーバ３０は、ドライバ３２及びデバイス制御ロジック３４をデバイス名と紐付けて管理し、端末１０からデバイス名を受信した際、受信したデバイス名に対応するドライバ３２及びデバイス制御ロジック３４を端末１０に送信する。
【００４４】
次に、図６に、端末１０をコンピュータで実現する場合の構成図を示す。
【００４５】
コンピュータ１００は、ＣＰＵ１０２、メモリ１０４、及び不揮発性の記憶部１０６を含む。ＣＰＵ１０２、メモリ１０４、及び不揮発性の記憶部１０６は、バス１０８を介して互いに接続されている。また、コンピュータ１００は、他の装置とコンピュータ１００とを接続し、互いにデータを送受信するためのＩ／Ｏ（Input/Output）１１０を備え、Ｉ／Ｏ１１０はバス１０８に接続されている。また、Ｉ／Ｏ１１０には、例えば入力装置１１２、表示装置１１４、及び通信装置１１６が接続されている。
【００４６】
入力装置１１２は、例えば表示装置１１４の表示画面上に設置されたタッチパネル等の、ユーザがコンピュータ１００に指示を与えるためのインターフェース装置を含む。また、入力装置１１２は、例えばＣＤ−ＲＯＭ又はフラッシュメモリ等の、記録媒体１６０に記録されるデータを読み取るための読み取り装置を含む。表示装置１１４は、例えばコンピュータ１００での処理結果を表示する表示デバイス等を含む。また、通信装置１１６は、デバイス４０、及び通信回線５０に接続するためのインターフェースを含み、デバイス４０、及びクラウドサーバ３０等の、他の電子機器とデータの送受信を行う。なお、記憶部１０６はＨＤＤ(Hard Disk Drive)又はフラッシュメモリ等によって実現できる。
【００４７】
記憶部１０６には、コンピュータ１００を図１に示す端末１０として機能させるためのアプリケーション機能拡張プログラム１１８が記憶されている。記憶部１０６に記憶されているアプリケーション機能拡張プログラム１１８は、例えば検知プロセス１２０、決定プロセス１２２、取得プロセス１２４、特定プロセス１２６、挿入プロセス１２８、及び実行プロセス１３０を含む。
【００４８】
ＣＰＵ１０２は、アプリケーション機能拡張プログラム１１８を記憶部１０６から読み出してメモリ１０４に展開し、アプリケーション機能拡張プログラム１１８が有する各プロセスを実行する。
【００４９】
ＣＰＵ１０２が、アプリケーション機能拡張プログラム１１８を記憶部１０６から読み出してメモリ１０４に展開し、アプリケーション機能拡張プログラム１１８を実行することで、コンピュータ１００が図１に示す端末１０として動作する。また、ＣＰＵ１０２が検知プロセス１２０を実行することで、コンピュータ１００が図１に示す検知部１２として動作する。また、ＣＰＵ１０２が決定プロセス１２２を実行することで、コンピュータ１００が図１に示す決定部１３として動作する。また、ＣＰＵ１０２が取得プロセス１２４を実行することで、コンピュータ１００が図１に示す取得部１４として動作する。また、ＣＰＵ１０２が特定プロセス１２６を実行することで、コンピュータ１００が図１に示す特定部１５として動作する。また、ＣＰＵ１０２が挿入プロセス１２８を実行することで、コンピュータ１００が図１に示す挿入部１６として動作する。また、ＣＰＵ１０２が実行プロセス１３０を実行することで、コンピュータ１００が図１に示す実行部１１として動作する。
【００５０】
更に、記憶部１０６には、デバイス制御ロジックリスト情報格納領域１３４、対応デバイス情報格納領域１３６、ドライバ情報格納領域１３８、及びアプリケーション情報格納領域１４０が記憶されている。
【００５１】
ＣＰＵ１０２が、デバイス制御ロジックリスト情報格納領域１３４に格納されたロジック対応情報を生成する情報をメモリ１０４に展開することで、メモリ１０４にデバイス制御ロジックリストＤＢ２２が生成される。また、ＣＰＵ１０２が、対応デバイス情報格納領域１３６に格納された対応デバイス情報を生成する情報をメモリ１０４に展開することで、メモリ１０４に対応デバイスＤＢ２０が生成される。また、ＣＰＵ１０２が、ドライバ情報格納領域１３８に格納されたドライバ３２及びドライバ対応情報を生成する情報をメモリ１０４に展開することで、メモリ１０４にドライバＤＢ２４が生成される。また、ＣＰＵ１０２が、アプリケーション情報格納領域１４０に格納されたアプリケーション１７を生成する情報をメモリ１０４に展開することで、アプリケーション１７がＣＰＵ１０２で実行可能な状態となる。
【００５２】
なお、コンピュータ１００は、例えば半導体集積回路、より詳しくはＡＳＩＣ(Application Specific Integrated Circuit)等で実現することも可能である。
【００５３】
次に、第１実施形態の作用について説明する。第１実施形態に係る端末１０は、例えば端末１０の利用者が、入力装置１１２で指定したアプリケーション１７の実行を端末１０に指示し、指定したアプリケーション１７がメモリ１０４に展開されて実行される際に、アプリケーション機能拡張処理を実行する。
【００５４】
図７は、第１実施形態に係る端末１０で実行されるアプリケーション機能拡張処理の流れの一例を示すフローチャートである。
【００５５】
まず、ステップＳ１０において、検知部１２は、通信装置１１６を介して端末１０に接続可能なデバイス４０を検知する。通信装置１１６を介して端末１０に接続可能なデバイス４０を検知する手法には公知の技術を利用することができる。
【００５６】
例えば、通信装置１１６に無線ＬＡＮが含まれる場合、検知部１２は、端末１０を無線アクセスポイントに接続し、無線アクセスポイントに接続されているデバイス４０の情報をスキャンすることで、端末１０に接続可能なデバイス４０のデバイス名を取得する。なお、検知部１２は、デバイス４０の情報をスキャンする際、例えばＵＰｎＰ(Universal Plug and Play)、又はＤＬＮＡ（登録商標）等の公知の接続プロトコルを利用して、端末１０に接続可能なデバイス名を取得できる。また、デバイス名の替わりに、ＳＳＩＤ等、デバイス４０を識別することができる識別情報を取得し、ＳＳＩＤからデバイス名を特定するようにしてもよい。
【００５７】
また、通信装置１１６にブルートゥース(Bluetooth（登録商標）)が含まれる場合、ブルートゥースのペアリングモードを利用して、端末１０に接続可能なデバイス名を取得する。この他、検知部１２は、ＮＦＣ(Near Field Communication)等の近距離無線通信、又はＲＦＩＤ(Radio Frequency IDentifier)を利用して、端末１０に接続可能なデバイス名を取得するようにしてもよい。なお、ここでは説明の便宜上、検知部１２は公知のデバイス検知手法により、端末１０に接続可能なデバイス４０のデバイス名を１つ取得するものとして説明を進める。
【００５８】
ステップＳ２０において、検知部１２は、ステップＳ１０の処理で取得したデバイス名で表されるデバイス４０が、端末１０で利用可能か否かを判定する。具体的には、検知部１２は、メモリ１０４に展開された対応デバイスＤＢ２０に記憶されている対応デバイス情報にステップＳ１０の処理で取得したデバイス名が含まれる場合、ステップＳ１０の処理で検知したデバイスが端末１０で利用可能と判定する。一方、検知部１２は、対応デバイス情報にステップＳ１０の処理で取得したデバイス名が含まれない場合、ステップＳ１０の処理で検知したデバイス４０が端末１０で利用できないと判定する。
【００５９】
ステップＳ２０における判定処理が否定判定の場合には、端末１０で利用可能なデバイス４０が存在しないため、アプリケーション機能拡張処理を終了し、端末１０はデバイス４０と連携することなくユーザが指定したアプリケーション１７を実行する。一方、ステップＳ２０における判定処理が肯定判定の場合には、ステップＳ３０に移行する。この際、検知部１２は、ステップＳ１０の処理で取得したデバイス名をメモリ１０４の予め定めた領域に記憶する。
【００６０】
ステップＳ３０において、決定部１３は、メモリ１０４からステップＳ１０の処理で取得されたデバイス名を取得する。そして、決定部１３は、図４に示したデバイス制御ロジックリストＤＢ２２を参照して、デバイス制御ロジックリストＤＢ２２のデバイス名欄に、取得したデバイス名が含まれるか否かを判定する。
【００６１】
肯定判定の場合には、端末１０は、取得したデバイス名に対応したドライバ３２及びデバイス制御ロジック３４を既に取得しているため、ステップＳ５０に移行する。一方、否定判定の場合には、端末１０には取得したデバイス名に対応したドライバ３２及びデバイス制御ロジック３４が存在しないため、ステップＳ４０に移行する。
【００６２】
ステップＳ４０において、取得部１４は、メモリ１０４からステップＳ１０の処理で取得されたデバイス名を取得する。そして、取得部１４は、取得したデバイス名をクラウドサーバ３０に送信し、送信したデバイス名に対応するドライバ３２及びデバイス制御ロジック３４を、クラウドサーバ３０から取得する。
【００６３】
なお、第１実施形態では、ドライバ３２及びデバイス制御ロジック３４が、インターネット回線等の通信回線５０に接続されたクラウドサーバ３０に配置される例について説明する。しかし、ドライバ３２及びデバイス制御ロジック３４は、インターネット回線に接続されないサーバ（ローカルサーバ）、又はデバイス４０自体に配置してもよい。
【００６４】
クラウドサーバ３０にドライバ３２及びデバイス制御ロジック３４を配置した場合、インターネット回線に接続可能な端末１０であれば、何れの端末１０からもアクセス可能となる。従って、クラウドサーバ３０以外の他の情報機器にドライバ３２及びデバイス制御ロジック３４を配置する場合に比べ、ドライバ３２及びデバイス制御ロジック３４の公開性が向上する。
【００６５】
また、ローカルサーバにドライバ３２及びデバイス制御ロジック３４を配置した場合、ドライバ３２及びデバイス制御ロジック３４へのアクセス許可範囲を、ローカルサーバが接続されるローカルネットワーク内の端末１０に限定できる。従って、ローカルサーバ以外の他の情報機器にドライバ３２及びデバイス制御ロジック３４を配置する場合に比べ、ドライバ３２及びデバイス制御ロジック３４の秘匿性が向上する。
【００６６】
また、デバイス４０にドライバ３２及びデバイス制御ロジック３４を配置した場合、クラウドサーバ３０又はローカルサーバが不要となる。従って、デバイス４０以外の他の情報機器にドライバ３２及びデバイス制御ロジック３４を配置する場合に比べ、ドライバ３２及びデバイス制御ロジック３４の取得に必要となる情報機器数を削減することができる。
【００６７】
取得部１４は、取得したデバイス制御ロジック３４を取得したデバイス名と対応づけ、デバイス制御ロジックリストＤＢ２２に格納する。更に、取得部１４は、取得したドライバ３２をドライバＤＢ２４に格納すると共に、取得したドライバ３２をデバイス名と対応づけて、図５に示したドライバＤＢ２４のドライバ対応情報に追加する。
【００６８】
ステップＳ５０において、特定部１５は、メモリ１０４からステップＳ１０の処理で取得されたデバイス名を取得する。そして、特定部１５は、デバイス制御ロジックリストＤＢ２２を参照して、デバイス制御ロジックリストＤＢ２２のデバイス名欄に、取得したデバイス名が設定されている行データから、取得したデバイス名に対応するデバイス制御ロジック３４を取得する。
【００６９】
ステップＳ６０において、特定部１５は、メモリ１０４に展開されたアプリケーション１７へのロジックの挿入位置を特定する。具体的には、特定部１５は、メモリ１０４に展開されたアプリケーション１７のコードを読み込み、アプリケーション１７における、取得したデバイス制御ロジック３４のタグと同じコードが含まれる行の行番号を、ロジックの挿入位置として特定する。なお、アプリケーション１７に、取得したデバイス制御ロジック３４のタグと同じコードが複数含まれる場合、特定部１５は、各々のコードが含まれる行の行番号をロジックの挿入位置として特定する。
【００７０】
ステップＳ７０において、特定部１５は、ステップＳ６０の処理で特定したロジックの挿入位置が少なくとも１つ以上あるか否かを判定する。否定判定の場合、メモリ１０４に展開されたアプリケーション１７には、ステップＳ５０の処理で取得したデバイス制御ロジック３４に含まれるロジックを挿入する位置が存在しない。従って、アプリケーション機能拡張処理を終了し、端末１０はデバイス４０と連携することなくユーザが指定したアプリケーション１７を実行する。
【００７１】
一方、肯定判定の場合、ステップＳ８０に移行する。この際、特定部１５は、ステップＳ５０の処理で取得したデバイス制御ロジック３４に含まれるロジックと、ステップＳ６０の処理で取得したアプリケーション１７の行番号と、をメモリ１０４の予め定めた領域に記憶する。また、特定部１５は、ドライバＤＢ２４のドライバ対応情報を参照して、取得したデバイス名に対応するドライバ３２をドライバＤＢ２４から取得してメモリ１０４に展開することで、取得したドライバ３２をアプリケーション１７から利用可能にする。なお、メモリ１０４へのドライバの展開タイミングは、ステップＳ７０を処理するタイミングに限定されないことは言うまでもない。
【００７２】
ステップＳ８０において、挿入部１６は、メモリ１０４からステップＳ７０の判定処理で肯定判定となった場合に記憶された、ロジック及びアプリケーション１７の行番号を取得する。そして、挿入部１６は、メモリ１０４に展開されたアプリケーション１７の、取得した行番号で表される行以降の位置に、取得したロジックを挿入する。なお、実行中のアプリケーション１７へのロジックの挿入は、例えばメモリ１０４に展開されたアプリケーション１７にアクセスすることができるＡＰＩ(Application Programming Interface)であるＤＯＭ(Document Object Model)を利用することで実現できる。
【００７３】
ステップＳ９０において、実行部１１はメモリ１０４から、ステップＳ８０の処理でロジックが挿入されたアプリケーション１７を再読み込みし、アプリケーション１７を実行する。
【００７４】
以上、図７に示すアプリケーション機能拡張処理により、実行中のアプリケーション１７に、端末１０が検知したデバイス４０のロジックがユーザの操作なしに自動的に挿入され、アプリケーション１７からデバイス４０の利用が可能となる。
【００７５】
なお、第１実施形態では一例として、デバイス４０に対応したロジック及びタグをデバイス制御ロジック３４に含めて一体に管理したが、ロジックとタグとの対応づけが行われさえすれば、ロジックとタグとを別々に管理するようにしてもよい。例えばデバイス制御ロジック３４にロジックを含め、ロジックに対応するタグは図示しないＤＢで管理するようにしてもよい。
【００７６】
また、第１実施形態では一例として、ステップＳ１０の処理において、端末１０に接続可能なデバイス４０のデバイス名が１つ取得されるものとして説明を進めた。仮にステップＳ１０の処理において複数のデバイス名が取得される場合には、取得した複数のデバイス名に含まれるデバイス名毎にステップＳ２０〜Ｓ９０の処理を実行すればよい。
【００７７】
また、第１実施形態では一例として、ステップＳ１０の処理において、端末１０のユーザが指定したアプリケーション１７がメモリ１０４に展開されて実行される際に、端末１０に接続可能なデバイス４０を検知するようにした。しかし、端末１０の起動後から定期的に端末１０に接続可能なデバイス４０を検知するようにしてもよい。この場合、アプリケーション１７の実行前にデバイス４０の検知が終了しているため、アプリケーション１７を実行してからデバイス４０を検知する場合に比べて、アプリケーション１７からデバイス４０が利用可能になるまでに要する時間を短縮することができる。
【００７８】
しかし、定期的に端末１０に接続可能なデバイス４０を検知する場合、デバイス４０の検知回数が増加するため、アプリケーション１７の実行に合わせてデバイス４０を検知する場合と比較して、端末１０の消費電力が増加する。従って、端末１０の消費電力低減の観点からは、アプリケーション１７の実行に合わせてデバイス４０を検知する方が好ましい。
【００７９】
また、第１実施形態では一例として、クラウドサーバ３０から取得したデバイス制御ロジック３４を端末１０に保存し、検知したデバイス４０に対応するデバイス制御ロジックが端末１０に存在する場合は、端末１０に保存したデバイス制御ロジック３４を用いた。しかし、デバイス制御ロジック３４を端末１０に保存せずに、端末１０でデバイスを検知する度にクラウドサーバ３０からデバイス制御ロジック３４を取得するようにしてもよい。
【００８０】
図８は、メモリ１０４に展開された、画像を表示するアプリケーション１７に、端末１０が検知したデバイス４０のロジックが挿入される前の端末１０を示す図である。なお、図８に例示するアプリケーション１７は、“<img src=“URL”>”で表されるimgタグを含む。imgタグは、「src=“URL”」で指定される画像ファイルの画像を端末１０の表示装置１１４に表示する命令である。
【００８１】
端末１０が図８に例示するアプリケーション１７を実行した場合、端末１０の表示装置１１４に「src=“URL”」で指定される画像ファイルの画像が表示される。しかし、図８に例示するアプリケーション１７には、デバイス４０の一例であるプリンタと連携して、画像をプリンタに出力するロジックが含まれていない。
【００８２】
一方、図７に示すアプリケーション機能拡張処理を実行することで、例えば端末１０が利用可能なデバイス４０としてプリンタを検知する。検知したプリンタに対応するデバイス制御ロジック３４のタグにimgタグが含まれる場合、端末１０は画像をプリンタに出力するロジックをアプリケーション１７のimgタグの直後の行に挿入する。
【００８３】
図９は、図７に示すアプリケーション機能拡張処理を実行し、メモリ１０４に展開された図８に示すアプリケーション１７に、端末１０が検知したデバイス４０（この場合、プリンタ）のロジックが挿入された後の端末１０を示す図である。
【００８４】
なお、図９に例示したアプリケーション１７に挿入されるロジックは、例えば「画像を印刷」と表記されたボタン６０を端末１０の表示装置１１４に表示する命令を含む。端末１０のユーザがボタン６０を押した場合に、検知したプリンタに対応するドライバ３２に含まれるphotoprint関数が呼び出され、imgタグで“ＵＲＬ”として指定された画像ファイルの画像がデバイス４０から出力される。
【００８５】
また、図１０は、メモリ１０４に展開された、音を出力するアプリケーション１７に端末１０が検知したデバイス４０のロジックが挿入される前の端末１０を示す図である。なお、図１０に例示するアプリケーション１７は、“<audio src=“URL”controls>”で表されるaudioタグを含む。audioタグは、「src=“URL”」で指定される音声ファイルの音声を端末１０に内蔵された図示しない音声出力装置から出力する命令である。また、audioタグの“controls”は、端末１０の表示装置１１４に音声の一時停止、及び再生位置の指定等を行うための操作アイテム６２を表示する命令である。
【００８６】
端末１０が図１０に例示するアプリケーション１７を実行した場合、端末１０の表示装置１１４に操作アイテム６２が表示されると共に、端末１０に内蔵された図示しない音声出力装置から「src=“URL”」で指定される音声ファイルの音声が出力される。しかし、図１０に例示するアプリケーション１７には、デバイス４０の一例である外部スピーカと連携して、音声を外部スピーカから出力するロジックが含まれていない。
【００８７】
一方、図７に示すアプリケーション機能拡張処理を実行することで、例えば端末１０が利用可能なデバイス４０として外部スピーカを検知する。検知した外部スピーカに対応するデバイス制御ロジック３４のタグにaudioタグが含まれる場合、端末１０は音声を外部スピーカに出力するロジックをアプリケーション１７のaudioタグの直後の行に挿入する。
【００８８】
図１１は、図７に示すアプリケーション機能拡張処理を実行し、メモリ１０４に展開された図１０に示すアプリケーション１７に、端末１０が検知したデバイス４０（この場合、外部スピーカ）のロジックが挿入された後の端末１０を示す図である。
【００８９】
なお、図１１に例示したアプリケーション１７に挿入されるロジックは、例えば「スピーカで再生」と表記されたボタン６０を端末１０の表示装置１１４に表示する命令を含む。端末１０のユーザがボタン６０を押した場合に、検知した外部スピーカに対応するドライバ３２に含まれるaplay関数が呼び出され、audioタグで“ＵＲＬ”として指定された音声ファイルの音声がデバイス４０である外部スピーカから出力される。
【００９０】
また、図１２は、メモリ１０４に展開された、動画を表示するアプリケーション１７に端末１０が検知したデバイス４０のロジックが挿入される前の端末１０を示す図である。なお、図１２に例示するアプリケーション１７は、“<video src=“URL”controls>”で表されるvideoタグを含む。videoタグは、「src=“URL”」で指定される動画ファイルに含まれる音声を端末１０に内蔵された図示しない音声出力装置から出力すると共に、動画ファイルに含まれる画像を端末１０の表示装置１１４に表示する命令である。また、videoタグの“controls”は、既に述べたように動画の一時停止、及び再生位置の指定等を行うための操作アイテム６２を表示する命令である。
【００９１】
端末１０が図１２に例示するアプリケーション１７を実行した場合、端末１０の表示装置１１４には、「src=“URL”」で指定される動画ファイルの映像、及び操作アイテム６２が表示される。また、端末１０に内蔵された図示しない音声出力装置から「src=“URL”」で指定される動画ファイルの音声が出力される。
【００９２】
しかし、図１２に例示するアプリケーション１７には、デバイス４０の一例である外部モニタと連携して、動画を外部モニタから出力するロジックが含まれていない。
【００９３】
一方、図７に示すアプリケーション機能拡張処理を実行することで、例えば端末１０が利用可能なデバイス４０として外部モニタを検知する。検知した外部モニタに対応するデバイス制御ロジック３４のタグにvideoタグが含まれる場合、端末１０は動画を外部モニタに出力するロジックをアプリケーション１７のvideoタグの直後の行に挿入する。
【００９４】
図１３は、図７に示すアプリケーション機能拡張処理を実行し、メモリ１０４に展開された図１２に示すアプリケーション１７に、端末１０が検知したデバイス４０（この場合、外部モニタ）のロジックが挿入された後の端末１０を示す図である。
【００９５】
なお、図１３に例示したアプリケーション１７に挿入されるロジックは、例えば「モニタで再生」と表記されたボタン６０を端末１０の表示装置１１４に表示する命令を含む。端末１０のユーザがボタン６０を押した場合に、検知した外部モニタに対応するドライバ３２に含まれるvplay関数が呼び出され、videoタグで“ＵＲＬ”として指定された動画ファイルの動画がデバイス４０である外部モニタから出力される。
【００９６】
なお、図９、図１１、及び図１３に示したアプリケーション１７とデバイス４０との連携例では、アプリケーション１７は表示装置１１４に、アプリケーション１７とデバイス４０との連携開始の指示を受け付けるボタン６０を表示する。そして、アプリケーション１７は、端末１０のユーザによりボタン６０が押下されたタイミングで、アプリケーション１７とデバイス４０との連携を開始する。しかし、ボタン６０の表示は必須ではなく、例えばアプリケーション１７は、端末１０のユーザの指示を待たずに自動的にアプリケーション１７とデバイス４０との連携を開始してもよい。
【００９７】
このように、図７に示すアプリケーション機能拡張処理では、検知部１２で検知した端末１０で利用可能なデバイス４０のロジックを自動的にアプリケーション１７に挿入され、アプリケーション１７がプリンタ等のデバイス４０と連携できるようになる。
【００９８】
しかし、アプリケーション１７の中には、例えば機密情報を扱うアプリケーション１７もある。こうした機密情報を扱うアプリケーション１７では、機密情報を外部に持ち出せないようにするため、例えばアプリケーション１７から機密情報をプリンタに出力させたくないといった事情が存在することがある。
【００９９】
この場合、例えば図３に示したデバイス制御ロジック３４の替わりに、図１４に示すデバイス制御ロジック３４Ａを用いることで解決することができる。
【０１００】
デバイス制御ロジック３４Ａは、デバイス４０に対応したロジックとタグの他、更にデバイス４０に対応したアプリケーション１７のアプリケーション名を対応づけるロジック対応情報を含む。デバイス制御ロジック３４Ａのアプリケーション名には、対応するロジックの挿入を許可するアプリケーション名が記載される。
【０１０１】
図７のステップＳ６０の処理において、特定部１５は、まず取得したデバイス制御ロジック３４Ａのアプリケーション名が、実行部１１で実行中のアプリケーション１７のアプリケーション名と一致するか否を判定する。そして、肯定判定の場合には、特定部１５は引き続き既に説明したステップＳ６０の処理を続行する。一方、否定判定の場合には、特定部１５は、ロジックの挿入位置を特定せずに図７に示すアプリケーション機能拡張処理を終了する。
【０１０２】
以上の処理により、デバイス制御ロジック３４Ａのアプリケーション名欄に記載されたアプリケーション１７だけに、デバイス制御ロジック３４Ａに対応するデバイス４０のロジックが挿入される。従って、端末１０は、連携可能なデバイス４０をアプリケーション１７毎に指定することができる。
【０１０３】
なお、図１４に示すデバイス制御ロジック３４Ａのアプリケーション名には、対応するロジックの挿入を禁止するアプリケーション名を記載してもよい。この場合、取得したデバイス制御ロジック３４Ａのアプリケーション名が実行中のアプリケーション１７のアプリケーション名と一致すれば、特定部１５でロジックの挿入位置を特定することなく、図７に示すアプリケーション機能拡張処理を終了すればよい。
【０１０４】
また、アプリケーション１７は、例えば通信回線５０に接続された情報機器から端末１０にダウンロードされ実行される。この際、アプリケーション１７の取得元である情報機器のドメインと、取得したアプリケーション１７に挿入されるロジックを規定したデバイス制御ロジック３４を含むクラウドサーバ３０のドメインと、が異なる場合がある。なお、ドメインとは、情報機器を識別するため、互いに重複しないように割り当てられた通信回線５０上のアドレス情報である。
【０１０５】
この場合、互いに異なるドメインから取得したアプリケーション１７に、デバイス制御ロジック３４のロジックを挿入することになる。しかし、アプリケーション１７の取得元である情報機器のドメインと異なるドメインからデバイス制御ロジック３４を取得する動作は、所謂クロスサイトリクエストと言われ、実行部１１において禁止されることがある。なぜなら、アプリケーション１７とデバイス制御ロジック３４との取得元のドメインが異なるということは、アプリケーション１７とデバイス制御ロジック３４との管理者が異なる可能性がある。従って、アプリケーション１７の管理者以外が提供するデバイス制御ロジック３４には、不正サイトへの誘導等、悪意のあるロジックが記載されている可能性があるため、セキュリティの観点から、実行部１１はデバイス制御ロジック３４の取得を禁止する。
【０１０６】
図１５は、クロスサイトリクエストの例を示す図である。図１５に示すように、端末１０は、例えば“www.server1.com”のドメインで表されるＷｅｂサーバ３１からアプリケーション１７を取得する。そして、端末１０で図７に示したアプリケーション機能拡張処理を実行し、例えば“www.server2.com”のドメインで表されるクラウドサーバ３０からデバイス制御ロジック３４を取得しようとする。しかし、既に説明したようにセキュリティの観点から、実行部１１がデバイス制御ロジック３４の取得を拒否する場合がある。
【０１０７】
こうしたクロスサイトリクエストを回避するための仕組みとして、例えばＣＯＲＳ(Cross Origin Resource Sharing)が知られている。このため、例えば端末１０及びクラウドサーバ３０をＣＯＲＳに対応させることで、クラウドサーバ３０からデバイス制御ロジック３４を取得することができるようになる。
【０１０８】
図１６は、ＣＯＲＳを適用したクロスサイトリクエストの例を示す図である。取得部１４は、アプリケーション１７の取得元と異なるドメインからデバイス制御ロジック３４を取得する際、アプリケーション１７の取得元のドメイン（www.server1.com）をoriginヘッダに付加してクラウドサーバ３０に送信する。一方、クラウドサーバ３０は、デバイス制御ロジック３４を含む電文のAccess-Control-Allow-Originヘッダに、originヘッダに付加されたアプリケーション１７の取得元のドメインを付加する。そして、クラウドサーバ３０は、Access-Control-Allow-Originヘッダが設定されたデバイス制御ロジック３４を含む電文を端末１０に送信する。端末１０では、Access-Control-Allow-Originヘッダに、originヘッダに付加したドメインと同じドメインが含まれる場合、実行部１１により取得部１４でのデバイス制御ロジックの取得が許可される。
【０１０９】
以上、端末１０でアプリケーション１７を実行する際、併せて図７に示したアプリケーション機能拡張処理を実行することにより、デバイス４０との連携が考慮されていないアプリケーション１７に、デバイス４０に対応するロジックを挿入することができる。従って、デバイス４０との連携が考慮されていないアプリケーション１７であっても、デバイス４０を利用することができるようになる。
【０１１０】
更に、アプリケーション機能拡張処理は、メモリ１０４に展開されたアプリケーション１７にロジックを挿入するため、記憶部１０６に記憶されるアプリケーション１７自体のコードが書き換えられることもない。
【０１１１】
（第２実施形態）
第１実施形態に係るアプリケーション機能拡張処理は、端末１０が検出したアプリケーション１７と連携可能なデバイス４０のロジックを、ユーザの操作なしに自動的にアプリケーション１７に挿入する。従って、ユーザが予め利用したいデバイス４０を決めている場合であっても、アプリケーション１７と連携可能な全てのデバイス４０のロジックがアプリケーション１７に挿入されてしまい、アプリケーション１７が不必要なデバイス４０と連携する場合がある。
【０１１２】
そこで、第２実施形態では、ユーザが利用したいデバイス４０を選択し、アプリケーション１７が、ユーザが選択したデバイス４０と連携するようにしたアプリケーション機能拡張処理について説明する。なお、第２実施形態におけるＷｅｂシステムの構成、及び端末１０を実現するコンピュータ構成は、第１実施形態におけるＷｅｂシステム１の構成（図１）、及びコンピュータ構成（図６）と同様の構成となる。
【０１１３】
次に、第２実施形態の作用について説明する。第２実施形態に係る端末１０は、第１実施形態の場合と同様のタイミングでアプリケーション機能拡張処理を実行する。
【０１１４】
図１７は、第２実施形態に係る端末１０で実行されるアプリケーション機能拡張処理の流れの一例を示すフローチャートである。図１７に示すフローチャートが図７に示す第１実施形態におけるアプリケーション機能拡張処理のフローチャートと異なる点は、ステップＳ２２及びステップＳ２４の処理が追加された点である。
【０１１５】
ステップＳ２２において、検知部１２は、ステップＳ２０の判定処理によって端末１０で利用可能と判定したデバイス４０に対応付けられたアイコンを表示装置１１４に表示する。
【０１１６】
ステップＳ２４において、検知部１２は、端末１０のユーザによってアイコンが選択されたか否か判定し、肯定判定になるまで、すなわちアイコンが選択されるまでステップＳ２４の処理を繰り返す。端末１０のユーザによってアイコンが選択されると、検知部１２は、端末１０のユーザによって選択されたアイコンに対応するデバイス４０のデバイス名を、メモリ１０４の予め定めた領域に記憶する。そして、ステップＳ３０に移行する。
【０１１７】
以後、既に説明したステップＳ３０〜ステップＳ９０の処理を実行することで、アプリケーション１７からユーザが選択したデバイス４０のみを利用することができるようになる。
【０１１８】
図１８は、ステップＳ２２の処理を実行した場合に、端末１０の表示装置１１４に表示される画面例を示す図である。ステップＳ２２の処理により、例えば表示装置１１４の下部に位置する領域６４に、端末１０で利用可能なデバイス４０に対応するアイコンが表示される。
【０１１９】
アイコンには、例えば対応するデバイス４０の外観等を模式的に示す図案が用いられるが、対応するデバイス４０を一意に表すことができる形態であれば、文字、又は図案と文字との組み合わせ等であってもよい。なお、図１８の例では、例えばプリンタを示すアイコン６６、及び記憶装置を示すアイコン６８が表示されている。また、領域６４の位置は一例であり、表示装置１１４の何れの位置に配置してもよいことは言うまでもない。
【０１２０】
ユーザが領域６４に表示されるアイコンの中から、例えばアイコン６６を選択すれば、実行中のアプリケーション１７とアイコン６６で示されるプリンタとを連携させることができる。
【０１２１】
図１９は、アイコン６６選択後に、端末１０の表示装置１１４に表示される画面例を示す図である。
【０１２２】
例えば、アイコン６６で表されるプリンタに対応するデバイス制御ロジック３４のロジックにボタン６０を表示する命令が含まれる場合、領域６４にはプリンタに画像の出力を指示するボタン６０が表示される。この際、図１９に示すように、ボタン６０に加え、更にユーザが選択したアイコン（この場合、アイコン６６）を表示してもよい。ユーザが選択したアイコンを表示することで、アイコンを表示しない場合に比べて、アプリケーション１７が何れのデバイス４０と連携しているかをユーザに通知することができる。
【０１２３】
このように第２実施形態に係るアプリケーション機能拡張処理によれば、端末１０で利用可能なデバイス４０の一覧を示すユーザインターフェースを提供し、ユーザに利用したいデバイス４０を選択させることができる。
【０１２４】
（第３実施形態）
第１実施形態及び第２実施形態に係る図７及び図１７のアプリケーション機能拡張処理では、ステップＳ１０において通信装置１１６を用いた公知の技術により、端末１０に接続可能なデバイス４０を検知する例を説明した。一方、第３実施形態では、カメラ等の撮像装置を用いて、端末１０に接続可能なデバイス４０を検知する例について説明する。
【０１２５】
図２０は、第３実施形態に係るＷｅｂシステムの構成例を示す図である。図２０に示すＷｅｂシステム２が図１に示したＷｅｂシステム１と異なる点は、新たに撮像装置１５０が追加され、検知部１２が検知部１２Ａに置き換えられた点である。
【０１２６】
検知部１２Ａは、実行部１１でのアプリケーション１７の実行に伴い、撮像装置１５０によって端末１０Ａ周辺の画像を撮像させる。検知部１２Ａは、撮像された画像に含まれるデバイス４０を検知し、対応デバイスＤＢ２０を参照して、検知したデバイス４０が端末１０で利用可能か否かを検知する。そして、検知部１２Ａは、デバイス４０が利用可能である場合、決定部１３に検知したデバイス４０のデバイス名を出力する。
【０１２７】
次に、図２１に、第３実施形態に係る端末１０Ａをコンピュータで実現する場合の構成例を示す。図２１に示すコンピュータ１００Ａの構成例が図６に示したコンピュータ１００の構成例と異なる点は、Ｉ／Ｏ１１０に新たに撮像装置１５０が接続され、検知プロセス１２０が検知プロセス１２０Ａに置き換えられた点である。なお、検知プロセス１２０Ａへの置き換えに伴い、アプリケーション機能拡張プログラム１１８がアプリケーション機能拡張プログラム１１８Ａに置き換えられる。
【０１２８】
撮像装置１５０は、画像を撮像し、撮像した画像を画像データに変換する機能を有する装置であり、具体的には例えばカメラが適用される。また、ＣＰＵ１０２が検知プロセス１２０Ａを実行することで、コンピュータ１００Ａが図２０に示す検知部１２Ａとして動作する。
【０１２９】
なお、コンピュータ１００Ａは、例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することも可能である。
【０１３０】
次に、第３実施形態の作用について説明する。第３実施形態に係る端末１０Ａがアプリケーション機能拡張処理を実行するタイミングは、第１実施形態及び第２実施形態と同様である。すなわち、端末１０Ａは、例えば端末１０Ａの利用者が、入力装置１１２で指定したアプリケーション１７の実行を端末１０Ａに指示し、指定したアプリケーション１７がメモリ１０４に展開されて実行される際に、アプリケーション機能拡張処理を実行する。
【０１３１】
なお、第３実施形態に係るアプリケーション機能拡張処理を実行するにあたり、デバイス４０には予めデバイス４０を特定するための識別情報、例えばデバイス名を表す文字が記載されたラベルが、外部から目視できる位置に貼り付けられているものとする。なお、ラベルには文字に代えて、デバイス名を表すバーコード等が記載されていてもよい。
【０１３２】
図２２は、第３実施形態に係る端末１０Ａで実行されるアプリケーション機能拡張処理の流れの一例を示すフローチャートである。図２２に示すフローチャートが図７に示す第１実施形態のフローチャートと異なる点は、ステップＳ１０及びＳ２０の処理が、それぞれステップＳ１１及びＳ２１に置き換えられ、新たにステップＳ２３、Ｓ２５、及びＳ２７の処理が追加された点である。
【０１３３】
まず、ステップＳ１１において、検知部１２Ａは、撮像装置１５０で撮像された端末１０Ａ周辺の画像（撮像画像）を取得する。そして、検知部１２Ａは、撮像画像にデバイス名を記載したラベルが含まれる場合、公知の文字認識技術を用いてラベルからデバイス名を読み取り、撮像画像に含まれるデバイス４０を検知する。
【０１３４】
ステップＳ２１において、検知部１２Ａは、ステップＳ１１の処理で検知した撮像画像に含まれるデバイス４０が、端末１０Ａで利用可能なデバイス４０であるか否かを判定する。判定の方法は既に図７のステップＳ２０の処理で説明したように、対応デバイスＤＢ２０を参照して判定すればよい。ステップＳ２１の判定処理が否定判定の場合にはステップＳ２５に移行する。
【０１３５】
ステップＳ２５において、検知部１２Ａは、例えば入力装置１１２から撮像の終了指示が通知されたか否かを判定する。そして、肯定判定の場合は図２２に示すアプリケーション機能拡張処理を終了し、否定判定の場合はステップＳ１１に移行して、検知部１２Ａは撮像画像に含まれるデバイス４０を検知する処理を繰り返す。
【０１３６】
一方、ステップＳ２１の判定処理が肯定判定の場合には、ステップＳ２３に移行する。ステップＳ２３において、検知部１２Ａは、例えば表示装置１１４に表示される撮像画像において、検知したデバイス４０が何処に存在するかをユーザに示すため、検知したデバイス４０を強調して表示する。ここでデバイス４０を強調して表示する方法としては、例えばデバイス４０を矢印等で指し示す、デバイス４０を枠で囲む、又はデバイス４０の色を変える等、の方法が考えられる。
【０１３７】
ステップＳ２７において、検知部１２Ａはユーザが撮像画像に含まれるデバイス４０を選択したか否かを判定する。当該判定は、例えばユーザが表示装置１１４に表示されたデバイス４０を指で押すことで、表示装置１１４の表面に設置された入力装置１１２の１つであるタッチパネルから通知される操作情報を、検知部１２Ａが取得することで判定できる。すなわち、検知部１２Ａがタッチパネルから操作情報を取得した場合にはステップＳ３０に移行し、操作情報を取得できない場合にはステップＳ２７の処理を繰り返し、検知したデバイス４０が選択されるまで待機する。
【０１３８】
以降、ステップＳ３０〜Ｓ９０の各処理を実行することで、実行中のアプリケーション１７は、ユーザが撮像画像の中から選択したデバイス４０を利用することができるようになる。
【０１３９】
図２３は、端末１０Ａで利用可能なデバイス４０を検知した場合の撮像画像の表示例を示す図である。
【０１４０】
端末１０Ａの表示装置１１４には撮像画像が表示され、図２３の例では、アプリケーション機能拡張処理によって検知したデバイス４０を強調して表示するため、例えばデバイス４０を囲む枠７０、及びデバイス４０を指し示すアイコン７２が表示される。
【０１４１】
更に、例えば「プリンタＡと連携」と表記した吹き出しを表示して、アプリケーション１７と連携させるデバイス名を表示装置１１４に表示するようにしてもよい。
【０１４２】
また、表示装置１１４には、実行中のアプリケーション１７によって表示されるアプリケーション画像７４も表示される。この場合、図２３に示すように、表示装置１１４に撮像画像を表示している期間は、ユーザに検知したデバイス４０を確認し易くさせるため、アプリケーション画像７４を半透明で表示することが好ましい。
【０１４３】
図２４は、ユーザがアプリケーション１７と連携させるデバイス４０を選択した場合の表示例を示す図である。
【０１４４】
ユーザがアプリケーション１７と連携させるデバイス４０を選択した場合、アプリケーション１７のアプリケーション画像７４と、連携させるデバイス４０と、の対応をわかりやすく表示することが好ましい。図２４の例では、例えばアプリケーション画像７４と、連携させるデバイス４０と、を対応付ける線分７６を表示装置１１４に表示している。そして、ユーザが表示装置１１４のデバイス４０が表示されている箇所を押下することで、例えば表示装置１１４に「印刷を実行」と表記した吹き出しを表示して、デバイス４０（この場合、プリンタ）から印刷結果を出力する。
【０１４５】
このように第３実施形態に係るアプリケーション機能拡張処理によれば、撮像画像を用いたＡＲ(Augmented Reality)技術により、ユーザは実際のデバイス４０の画像を見ながらアプリケーション１７と連携させるデバイス４０を選択することができる。従って、例えばデバイス名の一覧からアプリケーション１７と連携させるデバイス４０を選択する場合に比べて、アプリケーション１７とデバイス４０との連携に係る操作性を向上させることができる。
【０１４６】
以上、各実施形態を用いて開示の技術を説明したが、開示の技術は各々の実施形態に記載の範囲には限定されない。開示の技術の要旨を逸脱しない範囲で各々の実施形態に多様な変更または改良を加えることができ、当該変更または改良を加えた形態も開示の技術の技術的範囲に含まれる。例えば、開示の技術の要旨を逸脱しない範囲で処理の順序を変更してもよい。
【０１４７】
また、各実施形態では、アプリケーション機能拡張プログラムが記憶部に予め記憶（インストール）されている態様を説明したが、これに限定されるものではない。開示の技術に係るアプリケーション機能拡張プログラムは、コンピュータ読取可能な記録媒体１６０に記録されている形態で提供することも可能である。例えば、開示の技術に係るアプリケーション機能拡張プログラムは、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、及びＵＳＢメモリ等の可搬型記録媒体に記録されている形態で提供することも可能である。また、開示の技術に係るアプリケーション機能拡張プログラムは、フラッシュメモリ等の半導体メモリ等に記録されている形態で提供することも可能である。
【０１４８】
また、各実施形態では、実行中のアプリケーション１７に、端末１０で検知したデバイスのロジックを挿入する形態について説明した。しかし、例えばメモリ１０４に展開された実行待ち状態のアプリケーション１７に、端末１０で検知したデバイスのロジックを挿入するようにしてもよい。
【０１４９】
なお、第１実施形態のアプリケーション機能拡張処理で示した示唆は、第２実施形態、及び第３実施形態のアプリケーション機能拡張処理にも適用することができる。
【図１】
0006468293.tif 000002
【図２】
0006468293.tif 000003
【図３】
0006468293.tif 000004
【図４】
0006468293.tif 000005
【図５】
0006468293.tif 000006
【図６】
0006468293.tif 000007
【図７】
0006468293.tif 000008
【図８】
0006468293.tif 000009
【図９】
0006468293.tif 000010
【図１０】
0006468293.tif 000011
【図１１】
0006468293.tif 000012
【図１２】
0006468293.tif 000013
【図１３】
0006468293.tif 000014
【図１４】
0006468293.tif 000015
【図１５】
0006468293.tif 000016
【図１６】
0006468293.tif 000017
【図１７】
0006468293.tif 000018
【図１８】
0006468293.tif 000019
【図１９】
0006468293.tif 000020
【図２０】
0006468293.tif 000021
【図２１】
0006468293.tif 000022
【図２２】
0006468293.tif 000023
【図２３】
0006468293.tif 000024
【図２４】
0006468293.tif 000025
【図２５】
0006468293.tif 000026
【図２６】
0006468293.tif 000027