JP6627568B2 - 情報処理装置、情報処理プログラムおよび情報処理方法 - Google Patents

Description

本発明は、情報処理装置、情報処理プログラムおよび情報処理方法に関する。

最近、さまざまなデバイスやセンサがネットワークに接続されるＩｏＴ（Internet of Things）の実現が進められている。携帯網や無線ＬＡＮ（Local Area Network）などを介して直接にインターネットに繋がる機能を持つデバイスもあるが、Bluetooth（登録商標）やZigbee（登録商標）などの低消費電力の近距離無線規格を使い、近くにあるスマートフォンなどと接続して利用するものもある。例えば、電池で動作する体重計や血圧計といったデバイスには、計測結果が得られた時のみBluetoothでの接続が可能となる仕組みを持ったものが存在する。

一方で、スマートフォンやＰＣ（Personal Computer）は、携帯網やＷｉ−Ｆｉによりインターネットに接続し、Ｗｅｂ技術（HTTPやWebSocketなどの通信プロトコルおよびHTML/JavaScriptと言ったプログラミング言語）を使ってサーバにアクセスしてそのサーバが提供するサービスを使用することができる。さまざまなサービスがＷｅｂ技術を利用して提供されていることから、Ｗｅｂ技術を取り扱える技術者は非常に多い。そのため、Ｗｅｂ技術により、スマートフォンやＰＣなどのクライアントからさまざまなデバイスにアクセスできることが、デバイスの活用を促進すると考えられる。

そこで、例えば、Ｗ３Ｃ（World Wide Web Consortium）ではＷｏＴ（Web of Things）と呼ぶ、Ｗｅｂ技術でデバイスに接続して利用する方法の検討が行われている。そこでは、前述したようなBluetoothを使うデバイスに、Ｗｅｂ技術でアクセスできるようにプロトコル変換をするゲートウェイも検討されている。ゲートウェイは、クライアントから来たアクセスをもとに、必要に応じてデバイスにアクセスし、またデバイスから情報を受け取った場合は、必要に応じて適切な形式でクライアントに送信する機能を持つ。

一方、複数のインタフェースを備え、プラグアンドプレイでデバイスドライバをインストールすることでアクセス可能なデバイスを増やす技術がある（例えば、特許文献１等を参照）。この技術では、サーバが提供するサービスから扱うことができるデバイスが動的に変わることになり、サービスに応じたデバイスドライバの取得を容易にすることができる。しかし、Web APIアクセスをゲートウェイ（プロトコル変換）する技術ではなく、上述したＷｏＴに適用することはできない。

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

上述したＷｏＴを実現する上で、ゲートウェイにはプロトコル変換を行うデバイスドライバが必要となる。デバイスドライバの提供する機能は、どのようなデバイスに対応するかによって変わるため、デバイスに合わせて開発する必要がある。そのため、例えば、ゲートウェイを部屋に一台置いておき、新しくデバイスを購入して設置したとし、これにもアクセスできるようにゲートウェイに機能を提供して欲しいとユーザが考えた場合、ユーザは何らかの手続きを行って、ゲートウェイ内のデバイスドライバを変更することが必要である。しかし、それはユーザにとっては手間であり、また、ユーザにはそれをするための知識が要求され、誰にとっても容易に行えるものではない。

なお、Web APIアクセスをBluetooth等のプロトコルに変換する場合を中心に説明したが、Web APIアクセスを異なるプロトコルのＷｅｂ ＡＰＩアクセスに変換する場合も対象とすることができる。これにより、統一したWeb APIアクセスによりデバイスを利用することが可能となる。

そこで、開示の形態は、一側面では、ユーザに負担をかけることなくゲートウェイでのデバイスドライバを動的に配備する仕組を提供することを目的とする。

開示の形態は、デバイスに対応するデバイスドライバを取得して配備する手段と、クライアントから前記デバイスの機能を呼び出すためのアドレスを生成し、前記デバイスドライバへのパスと対応付けて登録する手段と、デバイスごとの提供する機能が記述された第１の情報と前記アドレスから、前記デバイスの機能と前記アドレスを含む第２の情報を生成して、前記デバイスの機能の呼び出しを受け付ける第２のサーバに登録する手段と、前記第２の情報を取得するための参照アドレスを、前記クライアントが共通に参照する第１のサーバに登録するか、または、周辺のクライアントに対して報知する手段と、を備える。

開示の形態は、ユーザに負担をかけることなくゲートウェイでのデバイスドライバを動的に配備することができる。

第１の実施例にかかるシステムの構成例を示す図である。 ゲートウェイを中心とした機能構成例を示す図である。 ゲートウェイ等のハードウェア構成例を示す図である。 第１の実施例における処理例を示すフローチャートである。 提供機能情報の例を示す図である。 ＵＲＬ対応表の例を示す図である。 機器情報の例を示す図である。 クライアントからのWeb API呼び出しに対する処理例を示す図である。 第２の実施例においてデバイスドライバから提供機能情報を取得する例を示す図である。 第２の実施例におけるサーバ側とやりとりする処理の例を示すフローチャートである。 第３の実施例におけるサーバ側とやりとりする処理の例を示すフローチャートである。 一覧情報およびゲートウェイＵＩの例を示す図である。 第４の実施例における処理例を示すフローチャートである。 第５の実施例における処理例を示すフローチャートである。 提供機能情報の例を示す図である。 第６の実施例における処理例を示すフローチャートである。 第７の実施例における処理例を示すフローチャートである。 第８の実施例における処理例を示すフローチャートである。

以下、本発明の好適な実施形態につき説明する。

＜第１の実施例＞
［構成］
図１は第１の実施例にかかるシステムの構成例を示す図である。図１において、インターネット等のネットワーク１上にはサーバ（サーバ装置）としてのドライバストア２とデバイスレポジトリ３とが設けられている。ドライバストア２は、利用される可能性のある複数のデバイス６（６Ａ、６Ｂ等）に対応するデバイスドライバを格納しているとともに、各デバイス６の提供する機能（ゲートウェイ５の提供する機能でもある）についての情報（提供機能情報）を格納している。デバイス６として、最近は、Bluetooth low energy（ＢＬＥ）もしくはBluetooth Smartと呼ばれるBluetooth 4.0以降の規格で接続するデバイス（周辺デバイス）が、iPhoneやAndroidなどのスマートフォンで対応されていることもあって増加傾向にあり、スマートウォッチや脈拍・体温などを測定するヘルスケアデバイス等が市販されている。デバイスレポジトリ３は、ユーザがデバイス６を制御するために使用するスマートフォンやＰＣ（Personal Computer）といったクライアント（クライアント端末）７からデバイス６にアクセスするために必要な情報（機器情報）を格納している。なお、後述する他の実施例において説明するが、クライアント７からゲートウェイ５へのアクセス方法によっては、デバイスレポジトリ３が実質的に不要となるケースもある。

ゲートウェイ５は、２つ以上のネットワークインタフェースを持つ。例えば、１つはWi-Fiで、もう一つはBluetooth等である。ゲートウェイ５は、１つのネットワークインタフェースからアクセスポイント４を経由してサーバ（ドライバストア２、デバイスレポジトリ３）やクライアント７と接続して通信することができる。また、ゲートウェイ５は、もう１つのネットワークインタフェースを経由してデバイス６と接続することができる。

なお、ドライバストア２とデバイスレポジトリ３は物理的に分かれている必要はなく、１つの機器上に両方の機能が搭載されていてもよい。また、これらのサーバのどちらかもしくは両方がゲートウェイ５と一体の機器となっていることもありうる。

図２はゲートウェイ５を中心とした機能構成例を示す図である。図２において、ゲートウェイ５は、ネットワークインタフェース５１、５２とゲートウェイ機能管理部５３とドライバ管理部５４とデバイスドライバ５５とＵＲＬ対応表５６とＷｅｂサーバ部５７とドライバ／Ｗｅｂサーバ間接続・変換管理部５８とを備えている。

ネットワークインタフェース５１は、ドライバストア２、デバイスレポジトリ３およびクライアント７と接続するためのものであり、例えばWi-Fiにより通信を行うものある。ネットワークインタフェース５２は、デバイス６と接続するためのものであり、例えばBluetoothやＢＬＥにより通信を行うものある。

ゲートウェイ機能管理部５３は、ゲートウェイ５を全体的に管理する機能を有しており、ネットワークインタフェース５２によるデバイススキャン、ネットワークインタフェース５１を介したドライバストア２からの提供機能情報の取得、Ｗｅｂ呼び出しのアドレスであるＵＲＬ（Uniform Resource Locator）の生成、ＵＲＬとデバイスドライバ５５へのパスとの対応付けのＵＲＬ対応表５６への登録、機器情報（ＴＤ：Thing Description）の生成およびデバイスレポジトリ３への登録等を行う。ドライバ管理部５４は、ネットワークインタフェース５１を介してドライバストア２からデバイスドライバを取得し、使用可能な状態に配備する機能を有している。デバイスドライバ５５は、ネットワークインタフェース５２を介してデバイス６と接続して制御を行う。

Ｗｅｂサーバ部５７は、クライアント７のアプリ（アプリケーションプログラム）７１からデバイス６の機能を利用するＷｅｂ呼び出しを受け付け、後続のドライバ／Ｗｅｂサーバ間接続・変換管理部５８に渡すとともに、ドライバ／Ｗｅｂサーバ間接続・変換管理部５８からデバイス６側からの応答をクライアント７のアプリ７１に渡す機能を有している。ドライバ／Ｗｅｂサーバ間接続・変換管理部５８は、Ｗｅｂサーバ部５７から渡されたＷｅｂ呼び出しのＵＲＬからＵＲＬ対応表５６を参照してデバイスドライバ５５へのパスを取得し、呼び出しを変換してデバイスドライバ５５に渡すとともに、デバイスドライバ５５からの応答を変換してＷｅｂサーバ部５７に渡す機能を有している。

図３はゲートウェイ５等（ドライバストア２、デバイスレポジトリ３、クライアント７も同様）のハードウェア構成例を示す図である。図３において、ゲートウェイ５等は、バス５０７を介して相互に接続されたＣＰＵ（Central Processing Unit）５０１、ＲＯＭ（Read Only Memory）５０２、ＲＡＭ（Random Access Memory）５０３、ＨＤＤ（Hard Disk Drive）／ＳＳＤ（Solid State Drive）５０４、接続Ｉ／Ｆ（Interface）５０５、通信Ｉ／Ｆ５０６を備えている。ＣＰＵ５０１は、ＲＡＭ５０３をワークエリアとしてＲＯＭ５０２またはＨＤＤ／ＳＳＤ５０４等に格納されたプログラムを実行することで、ゲートウェイ５等の動作を統括的に制御する。接続Ｉ／Ｆ５０５は、ゲートウェイ５等に接続される機器とのインタフェースである。通信Ｉ／Ｆ５０６は、ネットワークを介して他の情報処理装置と通信を行うためのインタフェースである。図２で説明したゲートウェイ５等の機能は、ＣＰＵ５０１において所定のプログラムが実行されることで実現される。プログラムは、記録媒体を経由して取得されるものでもよいし、ネットワークを経由して取得されるものでもよいし、ＲＯＭ組込でもよい。

［動作］
図４は第１の実施例における処理例を示すフローチャートである。図４において、ゲートウェイ５での処理は、大きく分けて、サーバ（ドライバストア２、デバイスレポジトリ３）側とやりとりする処理と、クライアント７側とやりとりする処理に分けられる。まずは、サーバ側とやりとりする処理について説明する。

ゲートウェイ５のゲートウェイ機能管理部５３は、デバイススキャン（ステップＳ１０１）によって、デバイス６を発見しようとする。例えば、ＢＬＥ対応デバイスは、定期的にアドバタイズと呼ばれる処理が実行されており、アドバタイジングパケットを定期的に送信しているので、ゲートウェイ５はそれを受信することで、デバイス６を発見することができる。

そして、新たにデバイス６が発見された場合（ステップＳ１０２のＹｅｓ）、ゲートウェイ機能管理部５３は、デバイス６から得られる情報をもとに、ドライバストア２から対応する提供機能情報を取得する（ステップＳ１０３）。ドライバストア２はさまざまなデバイスタイプ用の提供機能情報を提供しているため、その中からどの提供機能情報を取得するかを判定して取得する。この判定には、ＢＬＥ対応デバイスの場合は、アドバタイジングパケットの中の情報を用いることができる。アドバタイジングパケットの中には、デバイス６ごとに重複しないように割り振られたアドレスやデバイス名、デバイスベンダ独自記述部分、サービスUUID（Universally Unique Identifier）等が含まれている。サービスUUIDを使うことで、デバイス６がどのようなサービスを提供しているかを識別することができる。サービスUUIDは、Bluetooth special interest groupによって定義されており、通常はそれを使う（例えば、血圧サービスは0x1810）。しかし、デバイスベンダが、例えば独自サービス向けに、独自の値を使うことも可能である。例えば、このサービスUUIDをドライバストア２に送信し、ドライバストア２はそのサービスUUIDに合う提供機能情報を応答する。

提供機能情報には、特定のデバイス６がどのようなＡＰＩ（Application Programming Interface）を提供するかが記述されている。図５は提供機能情報の例を示している。この例では、提供機能情報全体の情報として、機能情報名（name）、そして、ＡＰＩ個々の情報として、ＡＰＩの種別（@type）、ＡＰＩ名（name）、読み込み・書き込みするデータの型（outputData）、書き込みできるか（writable）、を記述している。なお、@typeはどのように使えるＡＰＩかを表しており、Propertyは属性を読み書きするＡＰＩを意味している。

次いで、図４に戻り、ドライバ管理部５４は、ドライバストア２からデバイスドライバ５５を取得（ダウンロード）する（ステップＳ１０４）。デバイスドライバについても、ドライバストア２で複数のデバイスドライバが提供されている中から、発見したデバイス６に合ったものを取得する。そのため、ドライバ管理部５４は、提供機能情報と同様にサービスUUID等をドライバストア２に送信することで、対応するデバイスドライバを取得することが考えられる。しかし、デバイスドライバは、サービスUUIDごとではなく、同じサービスを提供するデバイスであっても、異なるベンダごとやさらには異なる機種ごとに提供されるのが通常である。そのため、サービスUUIDに加えて、デバイスベンダ独自記述部分（例えば、この中にベンダＩＤや機種名を入れる）をドライバストア２に送信することで、その区別をすることが可能になる。

次いで、ドライバ管理部５４は、デバイスドライバをダウンロードした後、デバイスドライバを配備し、配備したデバイスドライバ５５を呼び出すための方法（パス）を取得する（ステップＳ１０４）。このパスとしては、例えばデバイスドライバがJavaScript（登録商標）で記述されたものである場合、JavaScriptのインスタンスを用いることができる。

次いで、ゲートウェイ機能管理部５３は、ゲートウェイとして提供するWeb APIにクライアント７がアクセスするためのＵＲＬを生成する。その上で、ＵＲＬとパスの対応付けを行い、ＵＲＬ対応表５６に記憶する（ステップＳ１０５）。

図６は、図５に示した提供機能情報のデバイス"MyLED"に対して生成したＵＲＬ"http://192.168.0.10:8445/MyLED"と、デバイスドライバのJavaScriptのインスタンスをパス"driver["MyLED"]"として登録した例を示している。このＵＲＬにＡＰＩ名（ledOnOff）を追加することでWeb APIを呼び出すことができる。このＵＲＬは、ゲートウェイ５が持つ、アクセスポイント４に割り振られたＩＰアドレス（192.168.0.10）とWeb APIを受信するためにリッスンしているポート番号（8445）と提供機能情報から取得した機能情報名（MyLED）で構成している。なお、このＵＲＬはWeb APIへのアクセスを提供機能情報ごとに区別できる方法であれば、どのような方法で作成しても問題ない。例えば、追番でＩＤを生成して、それを使ってもよい（例えば、最初のデバイス用にはhttp://192.168.0.10:8445/0、次のデバイス用はhttp://192.168.0.10:8445/1等）。

なお、デバイスドライバはどのような言語で書かれていてもよいが、本実施例ではJavaScriptで記述されていることを想定している。配備として、JavaScriptで記述されたデバイスドライバを実行することで、JavaScriptからアクセス可能なデバイスドライバのインスタンスを作成する。そして、そのインスタンスをパスとしてＵＲＬと対応付けてＵＲＬ対応表５６に記憶する。図６のＵＲＬ対応表５６内のdriver["MyLED"]がデバイスドライバのインスタンスである。

次いで、図４に戻り、ゲートウェイ機能管理部５３は、生成したＵＲＬをもとに機器情報を生成する（ステップＳ１０６）。図７は、図５に示した提供機能情報のデバイス"MyLED"に対応する機器情報の例を示している。なお、機器情報の例は、Ｗ３ＣのWeb of Things Interest Groupで検討されているＴＤ（Thing Description）の記述形式をもとにしている。機器情報の中には、作成したＵＲＬ（符号ａで示す部分）と提供機能情報（符号ｂで示す部分）が含まれている。クライアント７はこれを取得することで、ゲートウェイ５のWeb APIにアクセスすることができるようになる。

次いで、図４に戻り、ゲートウェイ機能管理部５３は、作成した機器情報をデバイスレポジトリ３に登録する（ステップＳ１０７）。デバイスレポジトリ３への登録の仕方は、通常のHTTP-POSTなどを使えばよい。なお、機器情報は、クライアント７がデバイス６にアクセスするときに、どのデバイス６にアクセスするかを選択しやすいように、場所の情報や所有者の情報などを含んでもよい。それらの情報は、ゲートウェイ５で設定したり、場所であればＧＰＳ（Global Positioning System）情報から自動で取得したりするなどの方法が考えられる。機器情報の登録の後、デバイススキャン（ステップＳ１０１）から処理を繰り返す。

次に、クライアント７側とやりとりする処理について説明する。クライアント７上には、デバイス６と連携して動作するアプリ７１が動作している。例えば、体温計や体重計、血圧計のデバイス６などと連携して、日々測定した結果を管理するヘルスケアアプリや、電灯や家電機器などのリモコンとして使用可能なリモコンアプリなどである。クライアント７は、デバイスレポジトリ３にアクセスし、機器情報を取得する（ステップＳ１１１）。なお、登録された複数の機器情報の中から、クライアント７を操作するユーザがアクセスしたいデバイス６を選択するために、機能情報名や場所・所有者の情報などで検索する方法を提供することが望ましい。

次いで、クライアント７は、機器情報を取得した後、そこに記述されたＡＰＩ情報を用いて、ゲートウェイ５に対してWeb APIアクセスを行う（ステップＳ１１２）。例えば、図７に示した機器情報を取得した場合には、部分ｂに記述された"ledOnOff"を使用し、ＬＥＤランプをオンにするものとすると、部分ａに記述されたuriを用い、図８に示すように、"http://192.168.0.10:8445/MyLED/ledOnOff"のＵＲＬに対して、ボディ部に、{value:"true"}を記述してHTTP-POSTを行う（ステップＳ１１）。なお、プロトコルはHTTPに限られず、CoAPやWebSocketといった他のプロトコルを使ってもよい。

図４に戻り、ゲートウェイ５のＷｅｂサーバ部５７は、Web APIアクセスを待っており（ステップＳ１１３）、クライアント７からWeb APIが呼び出されることで（ステップＳ１１２）、このWeb APIを受信する（ステップＳ１１４）。Ｗｅｂサーバ部５７から受信した呼び出しを渡されたドライバ／Ｗｅｂサーバ間接続・変換管理部５８は、アクセスしてきたＵＲＬとＵＲＬ対応表５６をもとにデバイスドライバ５５へのパスを取得する（ステップＳ１１５）。そして、ドライバ／Ｗｅｂサーバ間接続・変換管理部５８は、そのパス経由で、Web APIアクセスで受信した情報をもとに変換を行ってデバイスドライバ５５を呼び出す（ステップＳ１１６、Ｓ１１７）。また、その際には、Ｗｅｂサーバ部５７へ結果を返答するために、Web APIを識別する情報（Web API識別情報）も含める。その後、デバイスドライバ５５はデバイス６にアクセスし、デバイス６が要求された動作を行って結果を返す。デバイスドライバ５５がその情報を受信すると（ステップＳ１１８）、ドライバ／Ｗｅｂサーバ間接続・変換管理部５８およびＷｅｂサーバ部５７を介してクライアント７にWeb API呼び出しに対する応答を送信し（ステップＳ１１９）、クライアント７は応答を受信する（ステップＳ１２０）。

Web API呼び出しを受けた場合の処理を図８を用いて説明する。ドライバ／Ｗｅｂサーバ間接続・変換管理部５８は、呼び出しの内容を渡されると（ステップＳ１２）、まず、アクセスしてきたＵＲＬ"http://192.168.0.10:8445/MyLED/ledOnOff"からＡＰＩ名に相当する"ledOnOff"以降を取り除いた部分をもとにＵＲＬ対応表５６から、パスとしてJavaScriptのインスタンスである"driver["MyLED"]"を取得する。そして、"driver["MyLED"]"がもつexec関数を、ＡＰＩ名およびHTTP-POSTのボディ部として渡された情報と、Web APIを識別する情報（Web API識別情報）"1"を引数として呼び出す（ステップＳ１３）。このWeb API識別情報"1"はWeb APIへのアクセスごとにカウントアップして使う。これにより、デバイスドライバ５５はＡＰＩ名と引数、応答に必要となるWeb API識別情報を渡されたことになる。なお、この例では、ＡＰＩ名（ledOnOff）をそのままexec関数の引数として使用したが、例えば、別に表を持っておき、その表をもとに別の引数に置き換えるなどしてもかまわない。表を持つことで、デバイスドライバ５５とWeb APIの関数名を合わせる必要がなくなる。また、exec関数を呼び出す前に、呼び出されたＡＰＩが機器情報として記述したＡＰＩであるかを確認してもよい。上記の変換方法では、機器情報に存在しないＡＰＩも呼び出すことが可能であり、デバイスドライバ５５の公開していない内部関数を呼び出されることが考えられるが、チェックによりクライアント７による不正利用を防止することができる。

デバイスドライバ５５は、渡された情報にもとづきデバイス６へアクセスを行う（ステップＳ１４）。この場合は、プロパティ"ledOnOff"に対して"true"が渡されたので、ＬＥＤランプを点灯するための処理を行う。デバイス６がＢＬＥ対応デバイスであれば、接続してなければ、まずＢＬＥのGATTプロトコルで接続した上で、サービスの検索や点灯機能に対応するCharacteristicのreadなどを行い、そのCharacteristicにwriteを行う処理などをすることになる。

そして、デバイスドライバ５５はデバイス６から結果を受信して（ステップＳ１５）、結果をドライバ／Ｗｅｂサーバ間接続・変換管理部５８に渡す（ステップＳ１６）。ドライバ／Ｗｅｂサーバ間接続・変換管理部５８は形式の変換を行ってＷｅｂサーバ部５７に渡す（ステップＳ１７）。これは、例えば、デバイスドライバ５５を呼び出すときに引数として渡された情報を、JavaScript APIであるthing.notifyを引数付きで呼び出すことで行う。thing.notifyはＷｅｂサーバ部５７に値を渡すための関数である。複数のWeb APIアクセスがあった場合でも、対応するWeb APIアクセスに対して結果を応答する必要があるため、識別するための情報として、デバイスドライバ呼び出し時に引数として与えたWeb API識別情報"1"を引数として追加している。したがって、この方式の場合、Ｗｅｂサーバ部５７はWeb APIアクセスにより設立されたセッションとWeb API識別情報を対応付けて記憶しておく。なお、JavaScriptで記述されたデバイスドライバ５５を動的に入れ替える方法を用いたために、Web API識別情報を使用する方法で説明したが、デバイスドライバ５５からの応答を適切にWeb APIアクセスの応答として返すことができればよいため、この方法には限られない。

Ｗｅｂサーバ部５７は得られた結果を、対応するクライアント７からのWeb API呼び出しに対する応答として送信する（ステップＳ１８）。この例では、正しく値が変更された（点灯した）ことを示すために、{"value":true}を応答している。

以上の処理により、クライアント７からのアクセスを、発見したデバイス６に応じてゲートウェイする機能を自動構成する仕組を実現することができる。

＜第２の実施例＞
第１の実施例では、提供機能情報をドライバストア２から取得する方法を説明したが、この情報が、取得したデバイスドライバ５５に含まれていてもよい。例えば、デバイスドライバ５５がｚｉｐファイル化されていて、２つのファイル（デバイスドライバのファイルと提供機能情報のファイル）が同時に取得できるのでもよい。また、デバイスドライバ５５の中にその情報を取得するためのＡＰＩが定義されていてもよいし、デバイスドライバ５５のコードをパーズして、その結果から作成できてもよい。

図９は第２の実施例においてデバイスドライバ５５から提供機能情報を取得する例を示す図である。図９（ａ）は、デバイスドライバ５５の中でgetInfo関数を定義していて、デバイスドライバ５５の配備後にそのgetInfo関数を実行することで提供機能情報を取得することができる。図９（ｂ）は、デバイスドライバ５５の中に、コメントとしてＡＰＩの情報が書かれており、これから提供機能情報を取得（抽出）することができる。コメントアウトした部分に書かれた内容からＡＰＩの仕様を取得することは、例えば、Java言語のJavadocという、コメントを元にＡＰＩ仕様書を作成する技術で使われており、同様の手法により実現することができる。

図１０は第２の実施例におけるサーバ側とやりとりする処理の例を示すフローチャートであり、デバイスドライバ５５から提供機能情報を取得する処理を含み、図４のステップＳ１０１〜Ｓ１０７に置き換わるものである。他の処理は図４と同様である。システム構成および機能構成についても図１および図２と同様である。

図１０の処理は、図４のステップＳ１０３の処理が除去されるとともに、ステップＳ１０４の処理の後に、提供機能情報を取得するためのＡＰＩ呼び出しまたはドライバパーズの処理（ステップＳ２０４）が挿入された点が異なる。ステップＳ２０１は図４のステップＳ１０１に、ステップＳ２０２は図４のステップＳ１０２に、ステップＳ２０３は図４のステップＳ１０４に、ステップＳ２０５は図４のステップＳ１０５に、ステップＳ２０６は図４のステップＳ１０６に、ステップＳ２０７は図４のステップＳ１０７に、それぞれ対応している。

＜第３の実施例＞
第１の実施例では、提供機能情報の取得とデバイスドライバ５５の取得を、デバイス６の発見をトリガとして行ったが、それに限定されない。ここでは、提供機能情報が別のトリガで行われる例を説明する。

例えば、Bluetoothでは、対応機器同士を接続するための事前手続きとしてペアリングという処理が規定されている。なお、Classic Bluetoothとも呼ばれるBluetooth 4.0以前の仕様では、ペアリングをすることが必須であり、Bluetooth 4.0以降（ＢＬＥを含む）では、ペアリングは必須ではない。ペアリングは、異なる機器に接続することを防ぐ仕組みであり、通常、片方の機器をペアリングモードにしたうえで、もう一方の機器からスキャンをして相手の機器を確認し、ユーザがＰＩＮ（Personal Identification Number）の入力やＰＩＮの確認をすることで行う。デバイスの発見時ではなく、このペアリング処理時に提供機能情報の取得とデバイスドライバの取得を行ってもよい。

また、ユーザによる設定や、他の機器からの要求をトリガとして提供機能情報の取得とデバイスドライバの取得を行ってもよい。図１１はユーザ設定をトリガとして提供機能情報の取得とデバイスドライバの取得を行う処理例を示しており、図４のステップＳ１０１〜Ｓ１０７に置き換わるものである。他の処理は図４と同様である。システム構成については図１と同様である。機能構成については、ドライバストア２がゲートウェイＵＩを表示するための一覧情報を保持し、ゲートウェイ機能管理部５３がその取得を行ってゲートウェイＵＩを提供する機能が追加される以外は図２と同様である。

図１１において、ゲートウェイ５においてユーザ操作に応じてユーザ設定が開始されると（ステップＳ３０１）、ゲートウェイ機能管理部５３は、ドライバストア２から一覧情報を取得する（ステップＳ３０２）。一覧情報には、サービスUUIDやデバイスを識別するためのＩＤが含まれている。図１２（ａ）は一覧情報の例を示しており、「ヘルスケア」という分類の下に「血圧サービス」等が含まれ、その下に「血圧計Ａ（Ａ社）」等が含まれることを示している。なお、「ヘルスケア」の他に「家電操作」等の分類が並列に存在する。

図１１に戻り、ゲートウェイ機能管理部５３は、取得した一覧情報に基づいてゲートウェイＵＩ（User Interface）を表示してユーザから選択を受け付けて設定を行う（ステップＳ３０３）。図１２（ｂ）はゲートウェイＵＩの例を示しており、左の画面から「ヘルスケア」が選択され、中央の画面から「血圧サービス」が選択され、右の画面から「血圧計Ａ（Ａ社）」が選択された状態を示している。

図１１に戻り、ゲートウェイ機能管理部５３は、ユーザ設定されたデバイスに対応する提供機能情報をドライバストア２から取得する（ステップＳ３０４）。その後のステップＳ３０５〜Ｓ３０８の処理は、図４のステップＳ１０４〜Ｓ１０７と同様である。

なお、設定のためのＵＩをゲートウェイ５自身が提供する場合について説明したが、ゲートウェイ５がサーバとなってＰＣやスマートフォンなどの別の機器から設定を行うことができるようになっていてもよい。また、単純に、ＵＩを使わずに、サーバからの要求に応じて指定された提供機能情報とデバイスドライバを取得するようにしてもよい。

＜第４の実施例＞
第１の実施例では、クライアント７がゲートウェイ５へのアクセス方法としての機器情報を取得する手段として、デバイスレポジトリ３を使用した。しかし、その方法に限られず、機器情報は、ゲートウェイ５のＷｅｂサーバ部５７がWeb APIを提供するのと同様に、ゲートウェイ５が提供してもよい。その場合には、機器情報を取得するための方法をクライアント７が知る必要がある。それを伝える方法として、機器情報をデバイスレポジトリ３に登録する代わりに、デバイスレポジトリ３に機器情報アクセス用のＵＲＬを登録する方法や、ＵＰｎＰなどのデバイス発見技術と同様にマルチキャストを使ってローカルネットワーク内の機器にＵＲＬを伝える方法、近距離無線（例えばＮＦＣ（Near Field Communication）など）を使ってＵＲＬを伝える方法がある。

図１３は第４の実施例における処理例を示すフローチャートである。システム構成については図１と同様である。機能構成については、ゲートウェイ５が機器情報５９を保持し、ゲートウェイ機能管理部５３が機器情報を提供する機能が追加される以外は図２と同様である。

図１３において、図４の処理と異なるのは、サーバ側とのやりとりとしては、ステップＳ４０７において機器情報を登録する先がゲートウェイ５内の機器情報５９になる点と、ステップＳ４０８において機器情報アクセス用の機器情報ＵＲＬを生成してデバイスレポジトリ３に登録する点である。また、クライアント７側の処理としては、ステップＳ４１１においてデバイスレポジトリ３から取得するのが機器情報ＵＲＬになる点と、ステップＳ４１２において機器情報ＵＲＬに基づいてゲートウェイ５から機器情報を取得する点である。ゲートウェイ５側は、ステップＳ４１４、Ｓ４１５において機器情報の取得のためのアクセスなのかWeb APIアクセスなのかを判断して処理を分岐する点と、ステップＳ４１６においてゲートウェイ機能管理部５３が機器情報を提供する点である。他の処理は図４と同様である。

マルチキャストや近距離無線を使う場合は、ステップＳ４０８のゲートウェイ５による機器情報ＵＲＬ登録およびステップＳ４１１のクライアント７による機器情報ＵＲＬ取得が、デバイスレポジトリ３を経由する代わりに、マルチキャストや近距離無線を使うことになる。

＜第５の実施例＞
これまで説明した実施例では、デバイスドライバ５５の取得後にクライアント７は機器情報を取得可能になったが、機器情報の取得はデバイスドライバ５５の取得前でもかまわない。その代わり、デバイスドライバ５５の取得前にクライアント７がデバイス６にアクセスする可能性があるため、ゲートウェイ５はデバイスドライバ５５を配備していない状態で応答をする必要がある。Bluetooth搭載のデバイス６では、省電力を実現するために、測定後にのみ一定時間（例えば１分）だけ発見されるためのアドバタイズを行う血圧計などが存在する。デバイス６がアドバタイズを始める前に、クライアント７が機器情報にアクセスできることで、例えば、血圧計の存在をユーザに通知して、血圧測定を促すようなことが可能になる。

図１４は第５の実施例における処理例を示すフローチャートである。システム構成については図１と同様である。機能構成については、ゲートウェイ５がデフォルト値情報５１０を保持し、ゲートウェイ機能管理部５３がＵＲＬをパスと対応させずにＵＲＬ対応表５６に登録し、デバイスドライバ５５の取得後にＵＲＬにパスを対応付ける機能が追加され、Ｗｅｂサーバ部５７がＵＲＬに対応するパスがない場合にデフォルト値を取得して応答する機能が追加される以外は図２と同様である。

図１４において、ステップＳ５０１〜Ｓ５０４の処理は、図１１に示した第３の実施例のステップＳ３０１〜Ｓ３０４と同様に行っている。なお、提供機能情報はこれまでの実施例のものを拡張し、デフォルト値を含んだものとしている。図１５は拡張した提供機能情報の例を示しており、デフォルト値"default"を含んでいる。図示の例の"rgbValueWhite"については"outputData": "xsd:unsignedByte"に対応させて"0"が設定され、"ledOnOff"については"outputData": "xsd:boolean"に対応させて"true"が設定されている。

図１４に戻り、ゲートウェイ機能管理部５３は、提供機能情報に含まれるデフォルト値を、後で応答するときに使うためにデフォルト値情報５１０に登録する（ステップＳ５０５）。次いで、ゲートウェイ機能管理部５３はＵＲＬを作成するが、デバイスドライバ５５はまだ配備しておらず、対応するパスはないため、ＵＲＬだけをＵＲＬ対応表５６に登録する（ステップＳ５０６）。次いで、ゲートウェイ機能管理部５３は、機器情報を生成し（ステップＳ５０７）、生成した機器情報をデバイスレポジトリ３に登録する（ステップＳ５０８）。この結果、クライアント７はデバイスレポジトリ３から機器情報を取得して、Web APIにアクセスできるようになる。

その後、ゲートウェイ機能管理部５３は、デバイススキャンを行い（ステップＳ５０９）、デバイス６を発見した場合（ステップＳ５１０のＹｅｓ）、デバイスドライバ５５の取得および配備を行い（ステップＳ５１１）、ＵＲＬ対応表５６のＵＲＬにパスを対応付ける（ステップＳ５１２）。

一方、クライアント７からのアクセスについては、ＵＲＬからパスの取得を試み（ステップＳ５２５）、パスがあるか否か判断し（ステップＳ５２６）、ない場合はデフォルト値情報５１０からデフォルト値を取得（ステップＳ５２７）して応答（ステップＳ５３１）する以外は、図４のステップＳ１１１〜Ｓ１２０と同様である。

なお、応答するデフォルト値は、提供機能情報として提供されている値を使用したが、提供機能情報を使わずに、単にエラーコードを返すような実装もありうる。例えば、{"error": true, "description": "no connection error"}のような、どのWeb APIが呼ばれても、同じ応答を返してもよい。

＜第６の実施例＞
これまで説明した実施例は、デバイス６が発見されて、それ以降、利用可能な状態であるところまでについて記述した。ここでは、デバイス６が存在しなくなった場合について述べる。Bluetoothなどで接続されるデバイス６は、省電力を実現するために、発見のためのアドバタイズを一定時間して、発見・接続された後、しばらく経つと、ネットワーク機能をオフにする血圧計などが存在する。このような機器の場合は、切断に応じた処理が必要である。

図１６は第６の実施例における処理例を示すフローチャートであり、デバイス消失時の処理である。なお、この処理の前提として、第１の実施例の仕組みにより、デバイススキャンによりデバイス６を発見して、機器情報をデバイスレポジトリ３経由で公開しているとする。

図１６において、ゲートウェイ５のゲートウェイ機能管理部５３は、デバイス６の消失を判断するために、デバイススキャンをする（ステップＳ６０１）。そして、発見済みでデバイスドライバ５５を配備しているデバイス６が消失しているかどうかを判定する（ステップＳ６０２）。消失している場合（ステップＳ６０２のＹｅｓ）、そのデバイス６に接続中であるか判定する（ステップＳ６０３）。多くのデバイス６では、デバイス６が接続された後、アドバタイズを止めるため、デバイスに接続している間は、デバイススキャンを行ったとしても、発見できない。そのためにこのチェックが必要である。

そして、デバイス６が消失しており接続中でない場合（ステップＳ６０３のＮｏ）、ゲートウェイ機能管理部５３は、デバイスレポジトリ３に登録した機器情報の削除要求を行い（ステップＳ６０４）、デバイスレポジトリ３は登録した機器情報を削除する。なお、登録した機器情報を削除するために、機器情報が持つ名前を指定して行ってもよいし、ゲートウェイ５もしくはデバイスレポジトリ３がその機器情報用のＩＤを生成して、それを管理しておき、ＩＤを指定することで削除してもよい。また、デバイスレポジトリ３は、その機器情報の削除に応じて、クライアント７に通知する（ステップＳ６１４）。この通知についても、名前やＩＤを通知することでクライアント７はどのデバイス６がアクセスできなくなったのかを判定することができる。クライアント７は、それまでのWeb API呼び出しの処理（ステップＳ６１１〜Ｓ６１３）の後に機器情報の削除の通知を受けると（ステップＳ６１４）、ユーザに使えなくなった旨などを通知する（ステップＳ６１５）。

次いで、ゲートウェイ５のゲートウェイ機能管理部５３は、自身の内部から機器情報を削除した後、配備したデバイスドライバ５５を削除し（ステップＳ６０５）、ＵＲＬ対応表５６に登録したＵＲＬとパスの対応情報を削除する（ステップＳ６０６）。ＵＲＬとパスの対応付けがなくなったことにより、もしクライアント７がWeb APIにアクセスしてきたとしても、対応するパスを取得できないことから、現在提供していないWeb APIであることが判断することができる。そのため、Web APIの提供を終了した状態になる。これにより、デバイス６の消失時の対応を実現することができる。

なお、第５の実施例で述べた方法と合わせて、デバイスドライバ５５の配備／削除と機器情報の登録／削除のタイミングを別にしてもよい。図１６では、機器情報の削除処理を行ったが、これに関しては、例えば、ユーザの設定の変更により、設定・削除を行うとし、デバイスドライバ５５については、発見・消失に合わせて行うようにすることができる。ユーザの設定の変更については、第３の実施例で説明した方法を使用することができる。図１２（ｂ）では設定をするためのＵＩを示したが、例えば、このチェックを外すタイミングで機器情報の削除処理を行えばよい。そして、デバイス６の消失時には、機器情報の削除は行わずにデバイスドライバ５５の削除とＵＲＬ／パスの削除のうち、パスの削除のみを行う。これにより、第５の実施例で述べたＵＲＬ作成した結果だけが登録された状態、すなわち、デバイスドライバ５５の取得前の状態となる。以降は、第５の実施例と同様に動作する。

＜第７の実施例＞
ここまで説明した実施例では、Web APIとして提供するデバイスと実デバイス／デバイスドライバが１対１で、さらに、デバイスドライバ５５が提供する機能をWeb APIとして提供するだけであった。しかし、それらの関係は１対１に限られず、また、デバイスドライバ５５では提供できない機能を追加することができる。

まず、一つのデバイス６が複数の機能を提供しており、その結果として、複数の機器情報を提供する場合を考える。例えば、腕時計型デバイスが、体温計機能と脈拍測定機能の両方の機能を持っている、といった場合である。このような場合は、この２つの機能を１つのデバイスとして見せてもよいが、体温計デバイスと脈拍測定デバイスの２つのデバイスとして、クライアント７に見せても構わない。第１の実施例では、どの提供機能情報を取得するかを決めるために、アドバタイジングパケットのサービスUUIDを利用した。デバイス６が複数の機能を提供する場合は、アドバタイジングパケットには複数のサービスUUIDが記述されている。したがって、この複数分の提供機能情報を取得すればよい。しかし、デバイス自体は１つであるため、デバイスドライバ５５は１つである。したがって、作成するＵＲＬは提供機能情報の数にしたがって２つになるが、それに対応付けられるデバイスドライバ５５は１つであるため、それらの機能に対応するWeb APIはそれぞれ異なるＵＲＬではあるが、同じパスを使って呼び出すことになる。したがって、ＵＲＬ対応表５６のパスに同じ情報が入ることになる。

なお、それ以外に、複数のデバイス６を組み合わせてマッシュアップした機能を１つのWeb APIで見せたり、デバイスドライバ５５では提供できない機能を追加したりするためにデバイスドライバ５５を制御するアプリを合わせて配備することができる。マッシュアップとは、例えば、Web APIとして目覚ましAlarmを提供する場合に、存在するデバイスによって何によって通知するのか（時計デバイス、音楽プレイヤ、カーテン自動開閉機構、それらの組み合わせなど）が変わるようにすることである。ゲートウェイ５がデバイス６個々へのWeb APIを提供して、クライアント７側でマッシュアップしてもよいが、ゲートウェイ５側で取りまとめることで、その目覚まし設定された時間にクライアント７がひとつずつ制御するのではなく、ゲートウェイ５側に事前に設定しておくことで、クライアント７は目覚まし設定された時間にはアクセスする必要がなくなる。また、前述したように、省電力を実現するために、ネットワーク機能を常時提供していないデバイスが存在する。そのようなデバイスへのキャッシュ情報をアプリに蓄えておくことができれば、クライアント７はいつでもデバイスの情報にアクセスできるようになる。以下、この場合の処理について説明する。

図１７は第７の実施例における処理例を示すフローチャートである。この例では、第５の実施例と同様に提供機能情報の取得はユーザ設定によって行うものをベースにしている。また、本実施例では、ドライバストア２がゲートウェイアプリも提供するものとしてゲートウェイアプリ／ドライバストア２'に拡張されている。また、ゲートウェイ５のドライバ管理部５４（またはゲートウェイ機能管理部５３）はゲートウェイアプリの取得および配備を行うように拡張されている。

図１７において、提供機能情報の取得まで（ステップＳ７０１〜Ｓ７０４）は、第５の実施例と同様である。そして、ドライバ管理部５４は、提供機能情報を取得するのに合わせてゲートウェイアプリを取得して配備する（ステップＳ７０５）。デバイスドライバはある固有のデバイスに対応付けられているのに対して、ゲートウェイアプリは固有のデバイスに対応付けられておらず、デバイスドライバ経由でデバイスにアクセスするものである。一方で、デバイスドライバと同様に、Ｗｅｂサーバ部５７と連携してクライアント７からのWeb APIアクセスをもとに呼び出されることができる。

ゲートウェイアプリが配備された後、ゲートウェイ機能管理部５３は、提供機能情報に対応するＵＲＬを作成した後、配備したゲートウェイアプリを呼び出すためのパスを対応付けてＵＲＬ対応表５６に登録する（ステップＳ７０６）。そして、ゲートウェイ機能管理部５３は、提供機能情報に対応する機器情報を生成して（ステップＳ７０７）、デバイスレポジトリ３に登録する（ステップＳ７０８）。そして、ゲートウェイ機能管理部５３は、デバイススキャンを行い（ステップＳ７０９）、デバイス６を発見した場合（ステップＳ７１０のＹｅｓ）、デバイスドライバ５５を取得して配備する（ステップＳ７１１）。また、デバイス６を発見してデバイスドライバ５５を配備したことを受けて、ゲートウェイアプリにそのデバイスドライバ５５を呼び出すためのパスを伝える。これにより、ゲートウェイアプリはデバイスドライバ５５を呼び出すことができるようになる。

そして、クライアント７がデバイスレポジトリ３から機器情報を取得し（ステップＳ７２１）、ＡＰＩ呼び出しを行い（ステップＳ７２２）、ゲートウェイ５のＷｅｂサーバ部５７が、クライアント７からのWeb APIへのアクセスを受けると（ステップＳ７２３、Ｓ７２４）、ＵＲＬ対応表５６からパスを取得する（ステップＳ７２５）。取得したパスは、デバイスドライバ５５へのパスではなく、ゲートウェイアプリへのパスであり、このパスを通して、ゲートウェイアプリを呼び出す（ステップＳ７２６）。ゲートウェイアプリを呼び出す時の変換方法は、これまでの実施例のデバイスドライバ５５を呼び出す時の変換方法と同じである。ゲートウェイアプリは、その呼び出しに応じて、必要であれば、デバイスドライバ５５にアクセスする（ステップＳ７２７）。デバイスドライバ５５はデバイス６にアクセスして（ステップＳ７２８、Ｓ７２９）、デバイス６からの応答をゲートウェイアプリに返す。ゲートウェイアプリは、Web API呼び出しに対する応答を返し、Ｗｅｂサーバ部５７はクライアント７に応答を返し（ステップＳ７３０）、クライアント７はＡＰＩ呼び出し結果を受信する（ステップＳ７３１）。例えば、ゲートウェイアプリにキャッシュ機能が実装されていた場合であれば、デバイス６が見つからない場合、つまり、デバイスドライバ５５が配備されておらず、デバイスドライバ５５へのパスがない場合には、ゲートウェイアプリは、デバイスドライバ５５にアクセスすることなく、以前に取得した値を返す。デバイス発見後は、デバイスドライバ５５経由でデバイス６から情報を取得して、その取得した情報を記憶しておくことになる。

＜第８の実施例＞
デバイスドライバを介在することによりデバイスの違いを吸収した上で、Web APIを提供することが可能である。しかし、クライアントが、デバイス特有の機能を使いたい場合もありうる。一つの方法としては、機器情報には、すべてのデバイス特有の機能用のWeb APIも用意しておく方法である（１）。そして、その機能を持っていないデバイスを使っている場合は、その機能に対するWeb APIアクセスに対して、例えば、エラーを返す。これであれば、これまでに述べた実施例で実現できている。もう一つの方法は、別のデバイスとして扱う方法である（２）。デバイスレポジトリには別のデバイスとしてそれぞれの機器情報を登録する。クライアントからは、別のデバイスとしてアクセスでき、それぞれの独自機能を利用可能である。さらにもう一つの方法は、同じデバイスとして取り扱うが、発見したデバイスが以前発見したデバイスと異なる独自機能を持つ場合に、機器情報を更新する方法である（３）。（１）と（２）についてはこれまでの実施例で実現できるため、（３）について以下に説明する。

図１８は第８の実施例における処理例を示すフローチャートである。図１８において、最初の機器情報の登録まで（ステップＳ８０１）は、第５の実施例と同様でよい。次いで、ゲートウェイ機能管理部５３は、デバイススキャンを行い（ステップＳ８０２）、デバイス６を発見した場合（ステップＳ８０３のＹｅｓ）、ドライバストア２から独自提供機能情報を取得する（ステップＳ８０４）。独自提供機能情報は提供機能情報と同じフォーマットでよい。

そして、ゲートウェイ機能管理部５３は、作成済みの機器情報に対してこの独自提供機能分のＡＰＩ情報を追加することで機器情報を更新し、デバイスレポジトリ３上にある機器情報についても更新を行う（ステップＳ８０５）。デバイスレポジトリ３は、機器情報の更新を受けて、クライアント７に通知し、クライアント７は受信する（ステップＳ８２２）。これらは、第６の実施例として述べたデバイスの消失時と、更新か削除かの違いだけであり、動作自体は同様でよい。

そして、ゲートウェイ機能管理部５３は、デバイスドライバ５５を取得して配備し（ステップＳ８０６）、ＵＲＬ対応表５６を新たなデバイスドライバ５５へのパスに更新することで（ステップＳ８０７）、クライアント７はデバイス独自の機能にWeb APIを通してアクセス可能になる。すなわち、ＡＰＩアクセスに対するゲートウェイ５の処理（ステップＳ８１３〜Ｓ８２０）は第５の実施例と同様であり（デフォルト値の取得は省略）、クライアント７は、最初は機器情報を取得しＡＰＩ呼び出しを行って結果を受信する（ステップＳ８１１、Ｓ８１２、Ｓ８２１）。機器情報の更新通知を受けると（ステップＳ８２２）、機器情報を更新し（ステップＳ８２３）、それに基づいてＡＰＩ呼び出しを行い（ステップＳ８２４）、結果を受信する（ステップＳ８２５）。なお、ここでは、一つの機器情報に共通機能と独自機能の両方を記述し、クライアント７からは一つのデバイスとして扱う場合を説明したが、共通機能と独自機能を別のデバイスとして取り扱い、２つの機器情報を提供する仕組みにしてもかまわない。

＜総括＞
以上説明したように、本実施形態によれば、ユーザに負担をかけることなくゲートウェイでのデバイスドライバを動的に配備することができる。

以上、好適な実施の形態により説明した。ここでは特定の具体例を示して説明したが、特許請求の範囲に定義された広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により限定されるものと解釈してはならない。

以上の説明に関し、更に以下の項を開示する。
（付記１）
デバイスに対応するデバイスドライバを取得して配備する手段と、
クライアントから前記デバイスの機能を呼び出すためのアドレスを生成し、前記デバイスドライバへのパスと対応付けて登録する手段と、
デバイスごとの提供する機能が記述された第１の情報と前記アドレスから、前記デバイスの機能と前記アドレスを含む第２の情報を生成して登録する手段と、
を備えたことを特徴とする情報処理装置。
（付記２）
前記クライアントから前記第２の情報に基づく機能の呼び出しを受け付けた場合に、呼び出しを受けたアドレスに対応するデバイスドライバに呼び出しを変換して送信する手段と、
前記デバイスドライバから機能の呼び出しに対する結果を受信し、結果を変換して前記クライアントに送信する手段と、
を備えたことを特徴とする付記１に記載の情報処理装置。
（付記３）
前記第１の情報を前記デバイスドライバとは別に取得する手段、または、前記第１の情報を前記デバイスドライバを介して取得する手段、
を備えたことを特徴とする付記１または２に記載の情報処理装置。
（付記４）
前記第１の情報または前記デバイスドライバの取得を、周辺に存在するデバイスの発見、ペアリングの設定、ユーザによる設定、または、他の機器からの要求、のいずれかをトリガとして行う、
ことを特徴とする付記１乃至３のいずれか一項に記載の情報処理装置。
（付記５）
前記第２の情報を、前記クライアントが共通に参照する第１のサーバ、または、前記デバイスの機能の呼び出しを受け付ける第２のサーバに登録し、該第２のサーバに登録する場合は、前記第２の情報を取得するための参照アドレスを、前記第１のサーバに登録するか、または、周辺のクライアントに対して報知する、
ことを特徴とする付記１乃至４のいずれか一項に記載の情報処理装置。
（付記６）
前記呼び出しを受けたアドレスに対応するデバイスドライバが配備されていない場合、前記第１の情報で規定された値またはエラーを応答する手段、
を備えたことを特徴とする付記２に記載の情報処理装置。
（付記７）
前記デバイスが発見できなくなったことまたは前記デバイスとの接続が切断されたことをトリガとして、配備した前記デバイスドライバの削除、前記アドレスと前記デバイスドライバへのパスとの対応付けの削除、前記デバイスの機能の呼び出しの受け付けの終了、または、前記第２の情報の削除、を行う、
ことを特徴とする付記１乃至６のいずれか一項に記載の情報処理装置。
（付記８）
前記デバイスの機能を補助するアプリを取得する手段と、
前記デバイスドライバへのパスに代えて前記アプリへのパスを登録する手段と、
前記アプリと前記デバイスドライバとを対応付ける手段と、
を備えたことを特徴とする付記１乃至７のいずれか一項に記載の情報処理装置。
（付記９）
前記クライアントから機能の呼び出しを受け付けた場合に、前記第２の情報に含まれる機能であるか否かを確認し、含まれる機能である場合に処理を継続する、
ことを特徴とする付記２に記載の情報処理装置。
（付記１０）
前記デバイスが発見できなくなり、他のデバイスが発見され、機能に差分がある場合に、該差分に応じて前記第２の情報を更新する手段、
を備えたことを特徴とする付記１乃至９のいずれか一項に記載の情報処理装置。
（付記１１）
デバイスに対応するデバイスドライバを取得して配備し、
クライアントから前記デバイスの機能を呼び出すためのアドレスを生成し、前記デバイスドライバへのパスと対応付けて登録し、
デバイスごとの提供する機能が記述された第１の情報と前記アドレスから、前記デバイスの機能と前記アドレスを含む第２の情報を生成して登録する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。
（付記１２）
前記クライアントから前記第２の情報に基づく機能の呼び出しを受け付けた場合に、呼び出しを受けたアドレスに対応するデバイスドライバに呼び出しを変換して送信し、
前記デバイスドライバから機能の呼び出しに対する結果を受信し、結果を変換して前記クライアントに送信する、
ことを特徴とする付記１１に記載の情報処理プログラム。
（付記１３）
前記第１の情報を前記デバイスドライバとは別に取得し、または、前記第１の情報を前記デバイスドライバを介して取得する、
ことを特徴とする付記１１または１２に記載の情報処理プログラム。
（付記１４）
前記第１の情報または前記デバイスドライバの取得を、周辺に存在するデバイスの発見、ペアリングの設定、ユーザによる設定、または、他の機器からの要求、のいずれかをトリガとして行う、
ことを特徴とする付記１１乃至１３のいずれか一項に記載の情報処理プログラム。
（付記１５）
前記第２の情報を、前記クライアントが共通に参照する第１のサーバ、または、前記デバイスの機能の呼び出しを受け付ける第２のサーバに登録し、該第２のサーバに登録する場合は、前記第２の情報を取得するための参照アドレスを、前記第１のサーバに登録するか、または、周辺のクライアントに対して報知する、
ことを特徴とする付記１１乃至１４のいずれか一項に記載の情報処理プログラム。
（付記１６）
前記呼び出しを受けたアドレスに対応するデバイスドライバが配備されていない場合、前記第１の情報で規定された値またはエラーを応答する、
ことを特徴とする付記１２に記載の情報処理プログラム。
（付記１７）
前記デバイスが発見できなくなったことまたは前記デバイスとの接続が切断されたことをトリガとして、配備した前記デバイスドライバの削除、前記アドレスと前記デバイスドライバへのパスとの対応付けの削除、前記デバイスの機能の呼び出しの受け付けの終了、または、前記第２の情報の削除、を行う、
ことを特徴とする付記１１乃至１６のいずれか一項に記載の情報処理プログラム。
（付記１８）
前記デバイスの機能を補助するアプリを取得し、
前記デバイスドライバへのパスに代えて前記アプリへのパスを登録し、
前記アプリと前記デバイスドライバとを対応付ける、
ことを特徴とする付記１１乃至１７のいずれか一項に記載の情報処理プログラム。
（付記１９）
前記クライアントから機能の呼び出しを受け付けた場合に、前記第２の情報に含まれる機能であるか否かを確認し、含まれる機能である場合に処理を継続する、
ことを特徴とする付記１２に記載の情報処理プログラム。
（付記２０）
前記デバイスが発見できなくなり、他のデバイスが発見され、機能に差分がある場合に、該差分に応じて前記第２の情報を更新する、
ことを特徴とする付記１１乃至１９のいずれか一項に記載の情報処理プログラム。
（付記２１）
デバイスに対応するデバイスドライバを取得して配備し、
クライアントから前記デバイスの機能を呼び出すためのアドレスを生成し、前記デバイスドライバへのパスと対応付けて登録し、
デバイスごとの提供する機能が記述された第１の情報と前記アドレスから、前記デバイスの機能と前記アドレスを含む第２の情報を生成して登録する、
処理をコンピュータが実行することを特徴とする情報処理方法。
（付記２２）
前記クライアントから前記第２の情報に基づく機能の呼び出しを受け付けた場合に、呼び出しを受けたアドレスに対応するデバイスドライバに呼び出しを変換して送信し、
前記デバイスドライバから機能の呼び出しに対する結果を受信し、結果を変換して前記クライアントに送信する、
ことを特徴とする付記２１に記載の情報処理方法。
（付記２３）
前記第１の情報を前記デバイスドライバとは別に取得し、または、前記第１の情報を前記デバイスドライバを介して取得する、
ことを特徴とする付記２１または２２に記載の情報処理方法。
（付記２４）
前記第１の情報または前記デバイスドライバの取得を、周辺に存在するデバイスの発見、ペアリングの設定、ユーザによる設定、または、他の機器からの要求、のいずれかをトリガとして行う、
ことを特徴とする付記２１乃至２３のいずれか一項に記載の情報処理方法。
（付記２５）
前記第２の情報を、前記クライアントが共通に参照する第１のサーバ、または、前記デバイスの機能の呼び出しを受け付ける第２のサーバに登録し、該第２のサーバに登録する場合は、前記第２の情報を取得するための参照アドレスを、前記第１のサーバに登録するか、または、周辺のクライアントに対して報知する、
ことを特徴とする付記２１乃至２４のいずれか一項に記載の情報処理方法。
（付記２６）
前記呼び出しを受けたアドレスに対応するデバイスドライバが配備されていない場合、前記第１の情報で規定された値またはエラーを応答する、
ことを特徴とする付記２２に記載の情報処理方法。
（付記２７）
前記デバイスが発見できなくなったことまたは前記デバイスとの接続が切断されたことをトリガとして、配備した前記デバイスドライバの削除、前記アドレスと前記デバイスドライバへのパスとの対応付けの削除、前記デバイスの機能の呼び出しの受け付けの終了、または、前記第２の情報の削除、を行う、
ことを特徴とする付記２１乃至２６のいずれか一項に記載の情報処理方法。
（付記２８）
前記デバイスの機能を補助するアプリを取得し、
前記デバイスドライバへのパスに代えて前記アプリへのパスを登録し、
前記アプリと前記デバイスドライバとを対応付ける、
ことを特徴とする付記２１乃至２７のいずれか一項に記載の情報処理方法。
（付記２９）
前記クライアントから機能の呼び出しを受け付けた場合に、前記第２の情報に含まれる機能であるか否かを確認し、含まれる機能である場合に処理を継続する、
ことを特徴とする付記２２に記載の情報処理方法。
（付記３０）
前記デバイスが発見できなくなり、他のデバイスが発見され、機能に差分がある場合に、該差分に応じて前記第２の情報を更新する、
ことを特徴とする付記２１乃至２９のいずれか一項に記載の情報処理方法。

１ ネットワーク
２ ドライバストア
２' ゲートウェイアプリ／ドライバストア
３ デバイスレポジトリ
４ アクセスポイント
５ ゲートウェイ
５１、５２ ネットワークインタフェース
５３ ゲートウェイ機能管理部
５４ ドライバ管理部
５５ デバイスドライバ
５６ ＵＲＬ対応表
５７ Ｗｅｂサーバ部
５８ ドライバ／Ｗｅｂサーバ間接続・変換管理部
５９ 機器情報
５１０ デフォルト値情報
６、６Ａ、６Ｂ デバイス
７ クライアント
７１ アプリ

Claims (11)

1. デバイスに対応するデバイスドライバを取得して配備する手段と、
   クライアントから前記デバイスの機能を呼び出すためのアドレスを生成し、前記デバイスドライバへのパスと対応付けて登録する手段と、
   デバイスごとの提供する機能が記述された第１の情報と前記アドレスから、前記デバイスの機能と前記アドレスを含む第２の情報を生成して、前記デバイスの機能の呼び出しを受け付ける第２のサーバに登録する手段と、
   前記第２の情報を取得するための参照アドレスを、前記クライアントが共通に参照する第１のサーバに登録するか、または、周辺のクライアントに対して報知する手段と、
   を備えたことを特徴とする情報処理装置。
2. 前記クライアントから前記第２の情報に基づく機能の呼び出しを受け付けた場合に、呼び出しを受けたアドレスに対応するデバイスドライバに呼び出しを変換して送信する手段と、
   前記デバイスドライバから機能の呼び出しに対する結果を受信し、結果を変換して前記クライアントに送信する手段と、
   を備えたことを特徴とする請求項１に記載の情報処理装置。
3. 前記第１の情報を前記デバイスドライバとは別に取得する手段、または、前記第１の情報を前記デバイスドライバを介して取得する手段、
   を備えたことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記第１の情報または前記デバイスドライバの取得を、周辺に存在するデバイスの発見、ペアリングの設定、ユーザによる設定、または、他の機器からの要求、のいずれかをトリガとして行う、
   ことを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 前記呼び出しを受けたアドレスに対応するデバイスドライバが配備されていない場合、前記第１の情報で規定された値またはエラーを応答する手段、
   を備えたことを特徴とする請求項２に記載の情報処理装置。
6. 前記デバイスが発見できなくなったことまたは前記デバイスとの接続が切断されたことをトリガとして、配備した前記デバイスドライバの削除、前記アドレスと前記デバイスドライバへのパスとの対応付けの削除、前記デバイスの機能の呼び出しの受け付けの終了、または、前記第２の情報の削除、を行う、
   ことを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 前記デバイスの機能を補助するアプリを取得する手段と、
   前記デバイスドライバへのパスに代えて前記アプリへのパスを登録する手段と、
   前記アプリと前記デバイスドライバとを対応付ける手段と、
   を備えたことを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
8. 前記クライアントから機能の呼び出しを受け付けた場合に、前記第２の情報に含まれる機能であるか否かを確認し、含まれる機能である場合に処理を継続する、
   ことを特徴とする請求項２に記載の情報処理装置。
9. 前記デバイスが発見できなくなり、他のデバイスが発見され、機能に差分がある場合に、該差分に応じて前記第２の情報を更新する手段、
   を備えたことを特徴とする請求項１乃至８のいずれか一項に記載の情報処理装置。
10. デバイスに対応するデバイスドライバを取得して配備し、
    クライアントから前記デバイスの機能を呼び出すためのアドレスを生成し、前記デバイスドライバへのパスと対応付けて登録し、
    デバイスごとの提供する機能が記述された第１の情報と前記アドレスから、前記デバイスの機能と前記アドレスを含む第２の情報を生成して、前記デバイスの機能の呼び出しを受け付ける第２のサーバに登録し、
    前記第２の情報を取得するための参照アドレスを、前記クライアントが共通に参照する第１のサーバに登録するか、または、周辺のクライアントに対して報知する、
    処理をコンピュータに実行させることを特徴とする情報処理プログラム。
11. デバイスに対応するデバイスドライバを取得して配備し、
    クライアントから前記デバイスの機能を呼び出すためのアドレスを生成し、前記デバイスドライバへのパスと対応付けて登録し、
    デバイスごとの提供する機能が記述された第１の情報と前記アドレスから、前記デバイスの機能と前記アドレスを含む第２の情報を生成して、前記デバイスの機能の呼び出しを受け付ける第２のサーバに登録し、
    前記第２の情報を取得するための参照アドレスを、前記クライアントが共通に参照する第１のサーバに登録するか、または、周辺のクライアントに対して報知する、
    処理をコンピュータが実行することを特徴とする情報処理方法。

Images