(57)【要約】【課題】ユーザに応じたデバイスのアクセス制御を行う。【解決手段】利用要求受信部２０が、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付けてアクセス管理ＤＢ３２に格納し、ＷｅｂＡＰＩ制御部４２は、登録に応じてＷｅｂＡＰＩを生成し、仮想デバイス制御部４０は、仮想デバイス機能部４６をＷｅｂＡＰＩへのアクセスに対してデバイスと連携して応答する仮想デバイスとして機能させる。そして、ＴＤ制御部４４は、ユーザ端末７０を利用したユーザ認証の結果に基づいて、認証したユーザに対応するＷｅｂＡＰＩへのアクセス方法を含むＴＤをユーザ端末７０に送信し、仮想デバイス機能部４６は、ユーザ端末７０からのＷｅｂＡＰＩへのアクセス（ＷｅｂＡＰＩ呼び出し）を受け付け、デバイスにアクセスする。【選択図】図３
2018180682.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、
前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、
端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、
前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を備える情報処理装置。
【請求項２】
前記通知部が通知する前記情報には、ユーザが利用可能なデバイスの機能を更新するために必要な情報が含まれることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記通知部が通知する前記情報には、前記ＷｅｂＡＰＩへアクセスするためのアドレス情報と、鍵情報が含まれることを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記ＷｅｂＡＰＩへのアクセスを監視する監視部と、
前記監視部の監視結果に基づく処理を実行する実行部と、を更に備える請求項１〜３のいずれか一項に記載の情報処理装置。
【請求項５】
前記アクセス部が前記デバイスにアクセスしたときに取得した情報を記憶しておき、所定時間の間は、記憶してある情報に基づいて前記端末に応答する応答部を更に備える請求項１〜４のいずれか一項に記載の情報処理装置。
【請求項６】
前記アクセス部が前記デバイスにアクセスできなかった場合には、所定時間経過後に、前記デバイスに再アクセスすることを特徴とする請求項１〜５のいずれか一項に記載の情報処理装置。
【請求項７】
前記通知部は、前記デバイスの情報に変更があった場合に、前記端末に対して前記ＷｅｂＡＰＩへのアクセス方法を含む情報の更新を通知することを特徴とする請求項１〜６のいずれか一項に記載の情報処理装置。
【請求項８】
前記ＷｅｂＡＰＩへのアクセス方法を含む情報は、有効期限情報を含むことを特徴とする請求項１〜７のいずれか一項に記載の情報処理装置。
【請求項９】
端末と、デバイスと、情報処理装置とがネットワークに接続された情報処理システムであって、
前記情報処理装置は、
前記端末から、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、
前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、
端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、
前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を有する、
ことを特徴とする情報処理システム。
【請求項１０】
コンピュータが、
ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付け、
前記登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成し、
端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知し、
前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスする、
処理を実行することを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理システム及び情報処理方法に関する。
【背景技術】
【０００２】
近年、ＩｏＴ（Internet of Things）の進展により、様々なデバイスがインターネットなどのネットワークに接続され、様々なデバイス（ＩｏＴデバイスと呼ぶ）からクラウドサービスを利用できるようになってきている。一方、様々なものを共有したり、貸し借りする、シェアードエコノミーと呼ばれるサービス（カーシェアリングやＡｉｒＢｎＢなど）も拡大しつつある。これらのことから、共有のＩｏＴデバイスや他人のＩｏＴデバイスが持つ一部又は全部の機能を一定時間だけ利用できるようにするデバイスのシェアリングも検討されてきている。
【０００３】
最近では、ＩｏＴデバイスをネットワーク経由で操作したり、ＩｏＴデバイスから情報を取得する仕組みの一つとして、ＷｏＴ（Web of Things）と呼ばれるＷｅｂ技術を使ってデバイスにアクセスする技術が検討されている。この技術では、端末は、Thing Descriptionと呼ばれるデバイス名やデバイスが持つ機能名とその機能へのアクセス方法などを記述する文書を用いてデバイスにアクセスする。
【０００４】
なお、デバイスのアクセス制御に関する技術として、端末でデバイスにタッチすることで接続し、認証、鍵交換を行い、その鍵を利用してデバイスへのアクセスを実現する技術が知られている（例えば、特許文献１等参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２０１５−５３００３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
デバイスをシェアリングする場合、ユーザによって利用可能なデバイスや利用可能なデバイスの機能が異なる。したがって、ユーザに応じたアクセス制御を行うことが必要である。
【０００７】
１つの側面では、本発明は、ユーザに応じたデバイスのアクセス制御を行うことが可能な情報処理装置、情報処理システム及び情報処理方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
一つの態様では、情報処理装置は、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を備えている。
【発明の効果】
【０００９】
ユーザに応じたデバイスのアクセス制御を行うことができる。
【図面の簡単な説明】
【００１０】
【図１】一実施形態に係る情報処理システムの構成を概略的に示す図である。
【図２】図２（ａ）は、ユーザ端末のハードウェア構成を示す図であり、図２（ｂ）は、サーバのハードウェア構成を示す図である。
【図３】サーバの機能ブロック図である。
【図４】アクセス管理ＤＢのデータ構造の一例を示す図である。
【図５】図５（ａ）は、ＴＤ管理ＤＢで管理されるＴＤの一例を示す図であり、図５（ｂ）は、ＴＤレポジトリで管理されるＴＤの一例を示す図である。
【図６】ＴＤレポジトリに格納されるデータの一例を示す図である。
【図７】図７（ａ）は、ＴＤ登録処理を示すフローチャートであり、図７（ｂ）は、デバイス登録処理を示すフローチャートである。
【図８】ユーザ登録処理を示すフローチャートである。
【図９】デバイスのアクセス制御処理を示すフローチャートである。
【図１０】図１０（ａ）、図１０（ｂ）は、第２の実施形態に係るＴＤを示す図である。
【図１１】図１１（ａ）は、第３の実施形態に係るＴＤを示す図であり、図１１（ｂ）は、第３の実施形態に係るＨＴＴＰヘッダ部の例を示す図である。
【図１２】第４の実施形態に係るサーバの機能ブロック図である。
【図１３】図１３（ａ）は、第４の実施形態に係るＡＰＩアクセス管理ＤＢのデータ構造を示す図であり、図１３（ｂ）は、アクセスルール管理ＤＢのデータ構造を示す図であり、図１３（ｃ）は、通知フォーマットの例を示す図である。
【図１４】変形例３に係るＴＤを示す図である。
【発明を実施するための形態】
【００１１】
≪第１の実施形態≫
以下、情報処理システムの第１の実施形態について、図１〜図９に基づいて詳細に説明する。
【００１２】
図１には、第１の実施形態に係る情報処理システム１００の構成が概略的に示されている。情報処理システム１００は、デバイス６０と、ユーザ端末７０と、サーバ１０と、を備える。デバイス６０及びユーザ端末７０は、無線ＬＡＮ（Local Area Network）や携帯電話網などを介して、インターネットなどのネットワーク８０に接続されている。また、サーバ１０もネットワーク８０に接続されている。本第１の実施形態の情報処理システム１００は、デバイス６０を管理する管理者（持ち主等）が、ユーザ端末７０を保持するユーザにデバイス６０を利用させるためのシステムである。
【００１３】
デバイス６０は、エアコン、自動車、照明、カメラなど、様々な場所に存在する機器であり、ＷｅｂＡＰＩの呼び出しを受けて、何らかの制御を行ったり、何らかの情報を返答したりするものである。
【００１４】
ユーザ端末７０は、ユーザが持ち歩き、デバイス６０を制御するために利用する端末であり、例えばスマートフォンやタブレット型端末であるものとする。図２（ａ）には、ユーザ端末７０のハードウェア構成の一例が示されている。図２（ａ）に示すように、ユーザ端末７０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、表示部９３、入力部９５、及び可搬型記憶媒体用ドライブ９９等を備えている。これらユーザ端末７０の構成各部は、バス９８に接続されている。ユーザ端末７０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラムをＣＰＵ９０が実行することにより、各種機能を実現する。なお、ユーザ端末７０には、デバイス６０を管理する管理者が利用可能な端末（管理者端末７０’（図３参照））も含まれるものとする。
【００１５】
サーバ１０は、ユーザ端末７０とデバイス６０の間の通信を仲介し、ユーザ端末７０からのデバイス６０に対するアクセス制御を実行する。図２（ｂ）には、サーバ１０のハードウェア構成の一例が示されている。図２（ｂ）に示すように、サーバ１０は、ＣＰＵ（Central Processing Unit）１９０、ＲＯＭ（Read Only Memory）１９２、ＲＡＭ（Random Access Memory）１９４、記憶部（ここではＨＤＤ（Hard Disk Drive））１９６、ネットワークインタフェース１９７、及び可搬型記憶媒体用ドライブ１９９等を備えている。これらサーバ１０の構成各部は、バス１９８に接続されている。サーバ１０では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったプログラムをＣＰＵ１９０が実行することにより、図３に示す各部として機能する。なお、図３には、ＨＤＤ１９６等に格納されている各種ＤＢ等も図示されている。
【００１６】
次に、図３に基づいて、サーバ１０の各部について具体的に説明する。サーバ１０においては、ＣＰＵ１９０がプログラムを実行することで、サービス部１２と、制御部１４として機能する。
【００１７】
図３において、サービス部１２は、サービス毎に用意されており、利用要求受信部２０と、アクセス制御部２２と、を有する。また、制御部１４は、プラットフォームであり、仮想デバイス制御部４０と、ＷｅｂＡＰＩ制御部４２と、ＴＤ制御部４４と、仮想デバイス機能部４６と、を有する。
【００１８】
ここで、Ｗ３Ｃで議論中のＷｏＴでは、端末がデバイスにアクセスする際に、ＴＤ（Thing Description）と呼ばれる情報をもとにアクセスする。端末がＴＤを取得する仕組みについてはさまざまな方法が検討されているが、その一つとして、デバイスが自身のＴＤをサーバ１０（ＴＤレポジトリ５４）に登録し、端末はそのＴＤが持つ情報の一部（例えばデバイスの名前やＩＤ)をキーとして検索することで、そのＴＤを取得する方法がある。本実施形態ではこの方法を応用するものとする。
【００１９】
具体的には、本実施形態では、デバイスの管理者はデバイスにサーバ１０が有するＴＤレポジトリ５４のＵＲＬを登録する代わりに、サーバ１０の仮想デバイス制御部４０のＵＲＬを登録する。これにより、仮想デバイス制御部４０にデバイスのＴＤが送られ、ＴＤをＴＤ管理ＤＢ５２で管理することが可能になる。
【００２０】
また、デバイスの管理者は、デバイスをどのような条件で貸し出すのかを取り決めてサービス事業者と契約する。たとえば、車を貸し出すのであれば、平日は１時間２００円、休日は１時間３００円で貸し出すといった契約を行う。そして、サービス事業者はその条件に応じてさまざまなユーザに車を貸し出すことになる。ユーザと管理者間における契約情報は、デバイスＩＤやユーザＩＤと対応付けてサービス部１２において管理される。
【００２１】
利用要求受信部２０は、アプリ管理ＤＢ３０で管理されているサービスアプリがダウンロードされているユーザ端末７０から、サービスアプリを用いたデバイスの利用手続き（利用契約）が行われた場合に、契約情報をアクセス管理ＤＢ３２に登録する。
【００２２】
より具体的には、ユーザはユーザ端末７０においてサービスアプリを利用し、サービスにアクセスする。そして、ユーザ認証を行った上で、利用要求受信部２０から提供されるプラン（アクセス管理ＤＢ３２に登録されている利用可能なデバイス６０及びデバイス６０の機能の情報）を確認して、その結果として、ある時間からある時間まであるデバイス６０を借りるといった予約（契約）を行う。この契約に関する流れは、通常のネットショッピングやホテル予約のネットサービスなどと同様である。この契約により、アクセス管理ＤＢ３２において、デバイスの管理者が登録したデバイス６０と契約したユーザとが対応付けられる。
【００２３】
ここで、アクセス管理ＤＢ３２は、管理者端末７０’から登録された情報（サービス事業者との契約情報）と、ユーザ端末７０から取得した利用要求（利用契約の内容）とを管理するデータベースである。具体的には、図４に示すように、「デバイスＩＤ」、「機能」、「ユーザＩＤ」、「開始」、「終了」の各フィールドを有する。
【００２４】
「デバイスＩＤ」のフィールドには、デバイス（例えば照明とする）の識別情報が格納される。「機能」のフィールドには、利用契約されたデバイスの機能（図４では照明のon／off）が格納される。「ユーザＩＤ」のフィールドには、契約したユーザの識別情報が格納される。「開始」及び「終了」のフィールドには、デバイスの利用開始日時及び利用終了日時が格納される。図４の例では、デバイスＩＤ「0123-4567-89ab-cdef」の照明の機能「onoff」について、ユーザＩＤ「00000001」のユーザが「2016/10/29 10:00」から「2016/10/29 11:00」まで利用する契約が結ばれたという内容が格納されている。
【００２５】
アクセス制御部２２は、アクセス管理ＤＢ３２に管理者端末７０’から登録された情報を格納する。また、アクセス制御部２２は、ユーザ管理ＤＢ５０やアクセス管理ＤＢ３２を参照して、ＷｅｂＡＰＩ制御部４２に仮想デバイスのＷｅｂＡＰＩを生成させたり、ＴＤ制御部４４に仮想デバイスのＴＤを生成させたりする。更に、アクセス制御部２２は、ユーザ端末７０からＴＤが要求された場合に、ＴＤ制御部４４に指示を出し、ユーザに対応するＴＤをユーザ端末７０に送信させる。
【００２６】
なお、ユーザ管理ＤＢ５０は、ユーザＩＤとパスワードの組み合わせ等を格納するデータベースである。
【００２７】
仮想デバイス制御部４０は、デバイス６０からデバイス６０のＴＤ（Thing Description）を受け付けると、受け付けたＴＤをＴＤ管理ＤＢ５２に格納するとともに、受け付けたＴＤに基づいて、仮想デバイス機能部４６に仮想デバイスを生成する（仮想デバイス機能部４６を仮想デバイスとして機能させる）。仮想デバイス機能部４６は、仮想デバイス制御部４０の指示の下、仮想デバイスとして機能する。また、ＷｅｂＡＰＩ制御部４２は、アクセス管理ＤＢ３２とＴＤに基づいて仮想デバイスのＷｅｂＡＰＩを生成し、仮想デバイスに与える。ＴＤ制御部４４は、アクセス管理ＤＢ３２とＴＤに基づいて仮想デバイスのＴＤを生成し、ＴＤレポジトリ５４に登録する。なお、ＴＤ制御部４４は、ＴＤレポジトリ５４を適宜監視し、ＴＤを更新したり、不要なＴＤを削除したりする。
【００２８】
ここで、ＴＤ管理ＤＢ５２に格納されるＴＤは、一例として図５（ａ）に示すようなものである。このＴＤの情報とアクセス管理ＤＢ３２（図４参照）の情報とに基づいて、ＴＤ制御部４４は、仮想デバイス用のＴＤを生成する。具体的には、図５（ａ）のＴＤでは「rgbw」と「onoff」の２つの機能が提供されている。一方、仮想デバイスのＴＤは、図５（ｂ）に示すように、「onoff」の機能しか存在しない。これは、アクセス管理ＤＢ３２に格納されている契約では「onoff」を利用する契約のみが結ばれているからである。なお、図５（ａ）、図５（ｂ）において、「uris」はデバイス又は仮想デバイスにアクセスするためのＵＲＬの一部を示している。「onoff」の機能にアクセスする場合には、「onoff」の機能の情報が記述しているところに含まれている「hrefs」の情報とＵＲＬとを組み合わせることでアクセスできる。例えば、アクセス先がデバイスの場合は、図５（ａ）より、ＵＲＬ「http://192.168.0.101/LED/onoff」にアクセスすることで「onoff」の機能を呼び出すことができる。一方、アクセス先が仮想デバイスの場合は、図５（ｂ）より、ＵＲＬ「http://192.168.0.1/0123456789abcdef/00000001/xxxxxxxx/onoff」にアクセスすることで「onoff」の機能を呼び出すことができる。また、http-getとhttp-postを使い分けることで、ＷｅｂＡＰＩを、状態を取得することと状態を変更することの両方に使用することができる。すなわち、onoffの値を取得するためにはhttp-getを使い、onoffの値を変更するためにはhttp-postを使う。たとえば、http-getのときには戻り値として、{“value”:true} のような値を返すことで、現在の状態がtrueである(現在照明がついている)ことを把握したり、http-postのときは{“value”:true}をhttp-postのボディ部に持たせることで、値をtrueに変更する（つまり照明をオンにする）ことが可能になる。なお、仮想デバイスのurisは仮想デバイスが扱えるアドレスで、かつ、仮想デバイス内で一意でなければならない。つまり、複数のデバイス用のＴＤとして同じurisを持っていてはならない。そのようにしなければ、仮想デバイスがアクセスを受けたときにどのデバイス向けの要求なのかわからなくなるからである。したがって、ＴＤ生成時には、連番で番号を振っておくなどして、一意になるようにする。なお、「name」は機能の名称、「valueType」はその機能の呼び出し時に指定する引数の型を示している。「onoff」の場合はvalueTypeが「boolean」であるのでtrue/falseを指定する。すなわち、上記で説明したＵＲＬにアクセスする際のＨＴＴＰプロトコルのｂｏｄｙ部にtrueかfalseを指定することでオンにするかオフにするかを指定できる。ＴＤ制御部４４は、図５（ｂ）のＴＤをユーザＩＤに対応付けた、図６に示すようなデータをＴＤレポジトリ５４に登録する。このＴＤレポジトリ５４に対する処理は定期的もしくは不定期的に繰り返して実行する。上記の契約では10/29 10:00-11:00のみ有効であったので、この範囲外の日時である場合はＴＤを登録せず、もし登録されていたら削除する。
【００２９】
上述したようにしてＴＤが登録された後、ユーザは契約日時においてデバイス６０を利用することが可能となる。ユーザがデバイス６０を利用する場合、ユーザ端末７０を通して、ユーザ認証を行う。この場合、アクセス制御部２２は、ユーザ管理ＤＢ５０を参照して、通常のインターネットサービスと同様のユーザ認証を行う。そして、アクセス制御部２２は、ＴＤ制御部４４に指示を出し、ユーザに応じたＴＤをＴＤレポジトリ５４からユーザ端末７０に送信する。これにより、ユーザ端末７０は、ユーザが利用可能なデバイスの機能についてのＴＤを取得することができる。
【００３０】
ユーザ端末７０では、取得したＴＤをパースして機能に対応するＵＲＬを算出して、算出したＵＲＬを用いて仮想デバイスにアクセス（ＷｅｂＡＰＩ呼び出し）する。仮想デバイス機能部４６（仮想デバイス）では、ＷｅｂＡＰＩアクセスを受信して、その受信したＵＲＬをもとにＴＤレポジトリ５４からどのデバイスのどの機能が呼び出されたのかを算出する。
【００３１】
たとえば、http://192.168.0.1/0123456789abcdef/00000001/xxxxxxxx/onoff へアクセスを受けたのであれば、ＴＤレポジトリ５４の情報からデバイスＩＤ「0123-4567-89ab-cdef」の「onoff」機能にアクセスしたことが分かる。すなわち、デバイスＩＤに基づいてデバイスのＴＤをＴＤ管理ＤＢ５２から見つけ、機能名からデバイスの同機能へのアクセス方法を見つけることができる。この情報に基づいて、仮想デバイス機能部４６はデバイスにアクセス（ＷｅｂＡＰＩ呼び出し）する。デバイスはＷｅｂＡＰＩ呼び出しを受けて処理を行う。たとえば、デバイスが照明であれば明かりをつけるなどの処理を行う。そして、デバイスは処理の実行が終了すると仮想デバイス機能部４６に応答を返す。仮想デバイス機能部４６は、デバイスからの応答を受けて、ユーザ端末７０に応答を転送する。以上により、ユーザ端末７０からデバイス６０を制御することが可能となっている。
【００３２】
なお、サーバ１０（仮想デバイス機能部４６）はＷｅｂＡＰＩ呼び出しを受けたときに、ＴＤレポジトリ５４やＴＤ管理ＤＢ５２からデバイスへのアクセス方法を算出するため、もしＷｅｂＡＰＩ呼び出しが契約外であれば、算出に失敗し、デバイスアクセスに失敗する。したがって、本実施形態では、適切なユーザからの契約しているデバイスへのアクセスのみが可能となっている。
【００３３】
（情報処理システム１００の処理について）
次に、図７〜図９に基づいて、情報処理システム１００における処理の流れについてフローチャートに沿って説明する。
【００３４】
（ＴＤ登録処理）
図７（ａ）には、ＴＤ登録処理のフローチャートが示されている。ＴＤ登録処理は、デバイス６０とサーバ１０により実行される処理である。まず、デバイス６０においては、管理者が、サーバ１０の仮想デバイス制御部４０のＵＲＬを登録すると、ステップＳ１０において、ＵＲＬの設定処理を実行する。次いで、デバイス６０では、ステップＳ１２において、管理者が設定したＵＲＬに対してＴＤを送信する。
【００３５】
一方、サーバ１０の仮想デバイス制御部４０は、ステップＳ２０において、ＴＤを受信するまで待機している。仮想デバイス制御部４０は、ＴＤを受信すると、ステップＳ２２に移行し、ＴＤをＴＤ管理ＤＢ５２に格納する。
【００３６】
以上により、ＴＤ登録処理が終了する。
【００３７】
（デバイス登録処理）
図７（ｂ）には、デバイス登録処理のフローチャートが示されている。デバイス登録処理は、管理者端末７０’とサーバ１０により実行される処理である。まず、管理者端末７０’では、ステップＳ３０において、デバイス登録処理を実行する。この場合、管理者は、貸し出すデバイスを管理者端末７０’において入力するため、管理者端末７０’は、入力されたデバイスの情報をサーバ１０に送信する。また、管理者端末７０’では、ステップＳ３２において、プラン登録処理を実行する。この場合、管理者は、どのような条件で貸し出すかを入力するため、管理者端末７０’は、入力された情報をサーバ１０に送信する。
【００３８】
一方、サーバ１０では、アクセス制御部２２は、登録情報を受信し、プラン情報を受信するまで待機している（Ｓ４０、Ｓ４２）。したがって、これらの情報を受信すると、アクセス制御部２２は、ステップＳ４４に移行し、プラン情報をアクセス管理ＤＢ３２に格納する。
【００３９】
以上により、デバイス登録処理が終了する。
【００４０】
（ユーザ登録処理）
図８には、ユーザ登録処理のフローチャートが示されている。図８の処理は、ユーザがデバイスを利用する（借りる）契約を行うために実行される処理である。図８の処理では、まず、ステップＳ５０において、ユーザ端末７０は、ユーザの操作に応じてアプリダウンロード要求をサーバ１０（利用要求受信部２０）に対して送信する。これに対し、サーバ１０側においては、利用要求受信部２０がダウンロード要求が送信されてくるまで待機しているため（Ｓ６０）、要求があった段階で、ステップＳ６２に移行し、アプリ（サービスアプリ）をアプリ管理ＤＢ３０から取得してユーザ端末７０に送信する。この場合、ユーザ端末７０では、ステップＳ５２において、アプリをインストールする。
【００４１】
アプリがインストールされた後、ユーザ端末７０は、ステップＳ５４において、ユーザの操作に応じて、ユーザ認証要求をサーバ１０の利用要求受信部２０に送信する。利用要求受信部２０では、ステップＳ６４においてユーザ認証要求があるまで待機しているため、ユーザ認証要求があると、ステップＳ６６に移行し、ユーザ管理ＤＢ５０に基づいてユーザ認証を実行する。なお、ユーザ認証に成功した場合、ユーザ端末７０上のアプリには、アクセス管理ＤＢ３２に格納されているデータに基づいて、選択可能なプランが表示されるようになっている。
【００４２】
次いで、ユーザ端末７０のユーザの操作によりプラン選択が行われると、ユーザ端末７０は、ステップＳ５６において、プラン選択情報をサーバ１０の利用要求受信部２０に送信する。これに対し、サーバ１０側では、利用要求受信部２０は、ステップＳ６８において、プラン選択情報を受信するまで待機しているため、プラン選択情報を受信した段階で、ステップＳ７０に移行する。
【００４３】
ステップＳ７０に移行すると、利用要求受信部２０は、プラン選択情報をアクセス管理ＤＢ３２に格納する。すなわち、いずれかのプランとユーザのユーザＩＤとを紐づける。
【００４４】
次いで、ステップＳ７２では、ユーザが選択したプランに基づいて、仮想デバイス制御部４０が仮想デバイスを生成する（仮想デバイス機能部４６を機能させる）。また、ＷｅｂＡＰＩ制御部４２が仮想デバイスのＷｅｂＡＰＩを生成し、ＴＤ制御部４４が、仮想デバイスのＴＤを生成する。
【００４５】
以上により、ユーザ登録処理が終了する。
【００４６】
（デバイスのアクセス制御処理）
図９には、デバイスのアクセス制御処理のフローチャートが示されている。デバイスのアクセス制御処理は、ユーザ端末７０、サーバ１０、デバイス６０により実行される処理である。本処理は、ユーザがユーザ端末７０を用いてデバイス６０を利用する際の処理である。
【００４７】
図９の処理では、まずステップＳ１１０において、ユーザ端末７０からユーザＩＤやパスワードを用いたユーザ認証要求が行われる。一方、サーバ１０のアクセス制御部２２は、ユーザ認証があるまで待機しているので（Ｓ１３０）、ユーザ認証要求があると、ステップＳ１３２に移行する。ステップＳ１３２では、アクセス制御部２２は、ユーザ管理ＤＢ５０を参照して、ユーザ認証を行う。
【００４８】
次いで、ステップＳ１１２において、ユーザ端末７０のアプリからＴＤの検索要求が出される。この場合、アクセス制御部２２は、ＴＤの検索要求があるまで待機しているので（Ｓ１３４）、ＴＤの検索要求があると、ステップＳ１３６に移行する。ステップＳ１３６では、アクセス制御部２２は、ＴＤ制御部４４に指示を出して、認証されたユーザに対応するＴＤをＴＤレポジトリ５４から検索して、ユーザ端末７０に送信する。
【００４９】
ユーザ端末７０は、ステップＳ１１４においてＴＤが送信されてくるまで待機しているため、ＴＤが送信されると、ステップＳ１１６に移行し、ＴＤを受信する。
【００５０】
次いで、ステップＳ１１８に移行すると、ユーザ端末７０では、ユーザの操作に応じていずれの機能（いずれのＴＤ）を利用するかを選択し、次のステップＳ１２０では、ＴＤをパースして機能に対応するＵＲＬを算出する。そして、ステップＳ１２２では、ユーザ端末７０は、算出したＵＲＬを用いて仮想デバイスにアクセスする（ＷｅｂＡＰＩ呼び出しを行う）。
【００５１】
一方、サーバ１０の仮想デバイス機能部４６（仮想デバイス）は、ユーザ端末７０からＷｅｂＡＰＩ呼び出しがあるまで待機しているので（Ｓ１３８）、ＷｅｂＡＰＩ呼び出しがあると、ステップＳ１４０に移行する。ステップＳ１４０に移行すると、仮想デバイス機能部４６（仮想デバイス）は、受信したＵＲＬをもとにＴＤレポジトリ５４からどのデバイスのどの機能が呼び出されたのかを算出する。次いで、ステップＳ１４２では、仮想デバイス機能部４６（仮想デバイス）は、算出した情報に基づいて、デバイスにアクセス（ＷｅｂＡＰＩ呼び出し）する。
【００５２】
仮想デバイス機能部４６からアクセス（ＷｅｂＡＰＩ呼び出し）されたデバイス６０では、ステップＳ１５０において、ＷｅｂＡＰＩを受けて処理を実行する。そして、処理の実行が終了すると、デバイス６０は、ステップＳ１５２において、仮想デバイス機能部４６に応答を返す。この場合、仮想デバイス機能部４６は、ステップＳ１４４において、デバイス６０からの応答を受けて、ユーザ端末７０に応答を転送し、ユーザ端末７０では、ステップＳ１２４において応答を受信する。
【００５３】
以上により、デバイスのアクセス制御処理が終了する。
【００５４】
以上詳細に説明したように、本第１の実施形態によると、利用要求受信部２０が、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付けてアクセス管理ＤＢ３２に格納し、ＷｅｂＡＰＩ制御部４２は、登録に応じてＷｅｂＡＰＩを生成し、仮想デバイス制御部４０は、仮想デバイス機能部４６をＷｅｂＡＰＩへのアクセスに対してデバイスと連携して応答する仮想デバイスとして機能させる。そして、ＴＤ制御部４４は、ユーザ端末７０を利用したユーザ認証の結果に基づいて、認証したユーザに対応するＷｅｂＡＰＩへのアクセス方法を含むＴＤをユーザ端末７０に送信し、仮想デバイス機能部４６は、ユーザ端末７０からのＷｅｂＡＰＩへのアクセス（ＷｅｂＡＰＩ呼び出し）を受け付け、デバイスにアクセスする。これにより、本第１の実施形態では、デバイス側に機能を追加することなく、ユーザに応じたデバイスのアクセス制御を行うことができる。この場合、一般的にサーバ１０に比べてリソースが小さいデバイスに機能を追加しないようにしているため、アクセス制御に関する機能がデバイスのリソースを圧迫することがない。また、ユーザは、通常のデバイスへのアクセスと同様の方法で、利用契約したデバイスに対してアクセスすることが可能となる。また、本第1の実施形態では、ユーザ端末７０は、ＴＤから算出される一時的なＵＲＬを用いて仮想デバイスにアクセスするため、セキュリティの向上を図ることができる。
【００５５】
≪第２の実施形態≫
次に、第２の実施形態について、図１０に基づいて説明する。本第２実施形態は、第１の実施形態のＴＤに情報を更に追加する例である。図１０（ａ）は、第１の実施形態のＴＤには存在しなかった情報として“price”の項目を追加した例であり、図１０（ｂ）は、“contractURL”の項目を追加した例である。
【００５６】
図１０（ａ）のＴＤの場合、色の変更（rgbw）のＷｅｂＡＰＩは現状利用できない（“enabled”:false）が、追加コストを支払えば利用できるという情報が追加されている。すなわち、ユーザ端末７０では、ＴＤをパースしてこの情報を取得することで、ユーザに色の変更の機能を追加コストを支払うことで利用できるということを示すことができる。
【００５７】
一方、図１０（ｂ）のＴＤの場合、追加契約用のＷｅｂページにアクセスするためのＵＲＬが、contractURLとして追加されている。ユーザは、新たにデバイスの機能を利用したいと思ったときには、contractURLにアクセスし、Ｗｅｂページで追加手続きを行うことで、利用可能な機能を追加することができる。なお、追加手続きに関しては、第１の実施形態において説明した利用契約と同様の処理により実現することができる。この追加手続きが行われると、アクセス制御部２２は、ＴＤ制御部４４に指示を出し、ＴＤレポジトリ５４に格納されているＴＤを更新する。これにより、仮想デバイス機能部４６（仮想デバイス）によるＷｅｂＡＰＩ呼び出しを受けた際の動作も変わるようになっている。
【００５８】
以上説明したように、本第２の実施形態によると、ＴＤには、ユーザが利用可能なデバイスの機能を更新するために必要な情報が含まれているので、ユーザは、必要に応じて、利用可能なデバイスの機能を適宜追加等することが可能となっている。
【００５９】
≪第３の実施形態≫
次に、第３の実施形態について図１１に基づいて説明する。本第３の実施形態は、ＴＤレポジトリ５４に登録されるＴＤから算出されるＷｅｂＡＰＩのＵＲＬに、推測が困難な情報を付加する点が、第１の実施形態と異なる。
【００６０】
本第３の実施形態では、図１１（ａ）に示すように、擬似乱数などを利用して鍵情報としての文字列を生成し、ＴＤレポジトリ５４に登録するＴＤのurisの部分で指定するＵＲＬに生成した文字列（token）を追加する。上記第１の実施形態で説明したように、仮想デバイスのurisは仮想デバイスが扱えるアドレスで、かつ、仮想デバイス内で一意でなければならないが、これを遵守していれば、文字列は自由に決めることができる。このため、文字列を複雑にすることで、本来権利のない人が文字列を予測して不正アクセスする可能性を低減することができる。
【００６１】
なお、図１１（ａ）の例に限らず、例えばＨＴＴＰアクセスであれば、図１１（ｂ）に示すようにＨＴＴＰのヘッダ部に文字列を追加してもよい。なお、ＨＴＴＰのボディ部に文字列を追加してもよい。なお、文字列は、ＴＤに含ませてユーザ端末７０に渡してもよいし、別のルートでユーザ端末７０に渡してもよい。
【００６２】
仮想デバイス機能部４６（仮想デバイス）は、ユーザ端末７０からＷｅｂＡＰＩ呼び出しを受信した際には、tokenを確認した上で、デバイスのアクセス制御を行うこととする。
【００６３】
以上、説明したように、本第３の実施形態によると、ＴＤには、ＷｅｂＡＰＩへアクセスするためのアドレス情報と、鍵情報としての文字列が含まれているので、第三者からの不正なアクセスの可能性を低減することができる。
【００６４】
≪第４の実施形態≫
次に、第４の実施形態について、図１２、図１３に基づいて、説明する。本第４の実施形態では、サーバ１０がデバイス６０への不正アクセスを防ぐために、仮想デバイスへのアクセスをチェックする。
【００６５】
図１２には、本第４の実施形態に係るサーバ１０’の機能ブロック図が示されている。図１２に示すように、本第４の実施形態では、制御部１４が、ＷｅｂＡＰＩ監視部６４を有するとともに、ＡＰＩアクセス管理ＤＢ６２及びアクセスルール管理ＤＢ６６を有している。また、サービス部１２が、監視通知部２４を有している。
【００６６】
ＷｅｂＡＰＩ監視部６４は、ＡＰＩアクセス管理ＤＢ６２に格納されたユーザ端末７０から仮想デバイスへのアクセス情報と、アクセスルール管理ＤＢ６６に格納されているアクセスルールとに基づいて、不正アクセスがあった可能性があるかを判断する。ＷｅｂＡＰＩ監視部６４は、不正アクセスがあった可能性があると判断した場合に、その旨を監視通知部２４に通知する。監視通知部２４は、ＷｅｂＡＰＩ監視部６４から通知があった場合には、不正アクセスがあった可能性があることを通知先ＵＲＬ（例えばユーザ端末７０）に通知する。
【００６７】
ここで、ＡＰＩアクセス管理ＤＢ６２は、図１３（ａ）に示すようなデータ構造を有する。図１３（ａ）に示すように、ＡＰＩアクセス管理ＤＢ６２は、「ＵＲＬ」、「デバイスＩＤ」、「アクセス元ＩＰアドレス」、「アクセス日時」の各フィールドを有する。「ＵＲＬ」のフィールドには、ユーザ端末７０からアクセスがあったＵＲＬが格納される。「デバイスＩＤ」のフィールドには、仮想デバイスの識別情報が格納される。「アクセス元ＩＰアドレス」のフィールドには、ユーザ端末７０のＩＰアドレスが格納される。「アクセス日時」のフィールドには、ユーザ端末７０からアクセスがあった日時が格納される。
【００６８】
また、アクセスルール管理ＤＢ６６は、図１３（ｂ）に示すようなデータ構造を有する。図１３（ｂ）に示すように、アクセスルール管理ＤＢ６６は、「デバイスＩＤ」、「通知先ＵＲＬ」、「ルールＩＤ」の各フィールドを有する。「デバイスＩＤ」のフィールドには、アクセスがあった仮想デバイスの識別情報が格納され、「通知先ＵＲＬ」のフィールドには、通知先を示すＵＲＬが格納される。「ルールＩＤ」のフィールドには、不正アクセスの可能性があるか否かを判断するためのルールの識別情報が格納される。
【００６９】
仮想デバイスは、ユーザ端末７０からアクセスを受けたときに、受信したＵＲＬに基づいてＴＤレポジトリ５４からデバイスＩＤを特定し、現在の日時と、アクセス元のユーザ端末７０のＩＰアドレスと、をＡＰＩアクセス管理ＤＢ６２に格納する。そして、ＷｅｂＡＰＩ監視部６４は、ＡＰＩアクセス管理ＤＢ６２への情報の追加を受けて、アクセスルール管理ＤＢ６６を参照して、ルールに合っているか（アクセスが正当であるか）否かを検証する。
【００７０】
たとえば、ルールが、「アクセスしてきたＩＰアドレスが以前のアクセスと変わっていない」であれば、ＷｅｂＡＰＩ監視部６４は、アクセス元のＩＰアドレスを確認し、以前のアクセスと変わっていないかを判断する。そして、アクセス元のＩＰアドレスが変わっている場合には、監視通知部２４が通知先ＵＲＬに対して通知を行い、アクセスを許可して良いかを確認する。また、ルールが、「所定時間内（例えば１秒以内）において所定回数（例えば２回）以上アクセスがあった場合」や「所定時間内（１０秒以内）に異なるアクセス元ＩＰアドレスからアクセスがあった場合」であれば、ＷｅｂＡＰＩ監視部６４は、そのようなアクセスがあったか否かを判断する。そして、そのようなアクセスがあった場合には、監視通知部２４が通知先ＵＲＬに通知する。
【００７１】
なお、通知のフォーマットとしては、種々採用することができ、例えば、図１３（ｃ）に示すような通知を行うことができる。
【００７２】
以上、説明したように、本第４の実施形態によると、サーバ１０は、ＷｅｂＡＰＩへのアクセスを監視するＷｅｂＡＰＩ監視部６４と、ＷｅｂＡＰＩ監視部６４の監視結果に基づく通知を行う監視通知部２４と、を備えている。これにより、ＷｅｂＡＰＩ監視部６４により、不正アクセスがあった可能性があると判断された場合に、監視通知部２４は、ユーザ等にその旨を通知することができる。
【００７３】
≪第５の実施形態≫
次に、第５の実施形態について説明する。第５の実施形態は、仮想デバイスがキャッシュ機能を有する点が第１の実施形態と異なる。
【００７４】
上述したように、デバイス６０のonoffの現在の値を取得するときにはhttp-getを用い、変更するときにはhttp-postを用いることとしている。本第５の実施形態では、仮想デバイスは、一度、http-getで値が要求されたときに、デバイス６０にアクセスして値を取得し、ユーザ端末７０に返答するが、その際に値をキャッシュとして記憶しておく。そして、再度http-getで同じ値が要求されたときにはデバイスにアクセスせずに記憶しておいた値をユーザ端末７０に返答する。なお、記憶後、一定時間が経過した場合には記憶しておいた値を消去する。または、一度http-postが呼び出された場合に、記憶しておいた値を消去する。これにより、実際の状態とキャッシュとの不整合を減らすことが可能である。
【００７５】
なお、仮想デバイスは、キャッシュ機能として、オフライン時にＷｅｂＡＰＩアクセスを一時記憶する機能を有していてもよい。すなわち、仮想デバイスがＷｅｂＡＰＩ呼び出しを受け、対応するデバイスにアクセスしたが、アクセスできなかった場合に、ＷｅｂＡＰＩアクセスを一時記憶しておき、所定時間経過した後に、記憶しておいたＷｅｂＡＰＩを用いて再度デバイスにアクセスする。
【００７６】
これにより、デバイスがオンライン状態になっていれば、仮想デバイスがデバイスに再度アクセスすることにより、デバイスが要求を実行することが可能である。
【００７７】
（変形例１）
なお、デバイス６０が電源をオフ／オンした場合や、デバイス６０が移動された場合など、ＩＰアドレスが変更になり、これまでのアクセス方法ではアクセスできなくなる場合がある。この場合には、サーバ１０は、デバイス６０からＴＤを再度取得するようにすればよい。たとえば、デバイス６０は、接続先のネットワークが変わったことを検出した場合に、再度ＴＤの登録を行うようにすればよい。
【００７８】
（変形例２）
上記第１の実施形態で説明したように、利用契約の期間に入った場合、利用契約が終了した場合、及び契約内容が変更された場合には、ＴＤレポジトリ５４内のＴＤは更新されるようになっている。しかしながら、ユーザ端末７０はすでにＴＤを取得している場合があるため、元のＴＤを使って仮想デバイスにアクセスしようとすることがある。
【００７９】
そこで、サーバ１０は、ＴＤが更新された場合に、ユーザ端末７０に対して通知してＴＤの再取得を促すようにしてもよい。このようにするためには、サービスアプリにイベント通知を受け取る機能を実装しておき、サーバ１０がＴＤを再取得するイベントをサービスアプリに対して通知するようにすればよい。
【００８０】
（変形例３）
なお、ＴＤに契約期間を予め記載しておき、その情報に基づいて、ユーザ端末７０がＴＤを再取得するようにしてもよい。この場合、例えば、図１４に示すように、ＴＤに契約期間を追加するようにすればよい。図１４のＴＤには、契約期間の開始日が「begindate」として登録されており、契約期間の終了日が「enddate」として登録されている。
【００８１】
図１４のＴＤを用いる場合、ユーザ端末７０は、契約開始前にＴＤを取得してもよい。この場合、begindateに基づいて、アクセス制御を行うようにすればよい。たとえば、現在の日時がbegindateよりも前であれば、対応するＷｅｂＡＰＩを呼び出したとしても、仮想デバイスでＷｅｂＡＰＩ呼び出しに対応するデバイスにアクセスしないようにすればよい。
【００８２】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。
【００８３】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００８４】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００８５】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【００８６】
なお、以上の第１〜第５の実施形態及び変形例の説明に関して、更に以下の付記を開示する。
（付記１）  ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、
前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、
端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、
前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を備える情報処理装置。
（付記２）  前記通知部が通知する前記情報には、ユーザが利用可能なデバイスの機能を更新するために必要な情報が含まれることを特徴とする付記１に記載の情報処理装置。
（付記３）  前記通知部が通知する前記情報には、前記ＷｅｂＡＰＩへアクセスするためのアドレス情報と、鍵情報が含まれることを特徴とする付記１又は２に記載の情報処理装置。
（付記４）  前記ＷｅｂＡＰＩへのアクセスを監視する監視部と、
前記監視部の監視結果に基づく処理を実行する実行部と、を更に備える付記１〜３のいずれかに記載の情報処理装置。
（付記５）  前記アクセス部が前記デバイスにアクセスしたときに取得した情報を記憶しておき、所定時間の間は、記憶してある情報に基づいて前記端末に応答する応答部を更に備える付記１〜４のいずれかに記載の情報処理装置。
（付記６）  前記アクセス部が前記デバイスにアクセスできなかった場合には、所定時間経過後に、前記デバイスに再アクセスすることを特徴とする付記１〜５のいずれかに記載の情報処理装置。
（付記７）  前記通知部は、前記デバイスの情報に変更があった場合に、前記端末に対して前記ＷｅｂＡＰＩへのアクセス方法を含む情報の更新を通知することを特徴とする付記１〜６のいずれかに記載の情報処理装置。
（付記８）  前記ＷｅｂＡＰＩへのアクセス方法を含む情報は、有効期限情報を含むことを特徴とする付記１〜７のいずれかに記載の情報処理装置。
（付記９）  端末と、デバイスと、情報処理装置とがネットワークに接続された情報処理システムであって、
前記情報処理装置は、
前記端末から、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、
前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、
端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、
前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を有する、
ことを特徴とする情報処理システム。
（付記１０）  コンピュータが、
ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付け、
前記登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成し、
端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知し、
前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスする、
処理を実行することを特徴とする情報処理方法。
（付記１１）  前記情報には、ユーザが利用可能なデバイスの機能を更新するために必要な情報が含まれることを特徴とする付記１０に記載の情報処理方法。
（付記１２）  前記情報には、前記ＷｅｂＡＰＩへアクセスするためのアドレス情報と、鍵情報が含まれることを特徴とする付記１０又は１１に記載の情報処理方法。
（付記１３）  前記ＷｅｂＡＰＩへのアクセスを監視し、
前記監視部の監視結果に基づく処理を実行する、処理を前記コンピュータが更に実行する付記１０〜１２のいずれかに記載の情報処理方法。
（付記１４）  前記デバイスにアクセスしたときに取得した情報を記憶しておき、所定時間の間は、記憶してある情報に基づいて前記端末に応答する、処理を前記コンピュータが更に実行する付記１０〜１３のいずれかに記載の情報処理方法。
（付記１５）  前記デバイスにアクセスできなかった場合に、所定時間経過後に、前記デバイスに再アクセスすることを特徴とする付記１０〜１４のいずれかに記載の情報処理方法。
（付記１６）  前記通知する処理では、前記デバイスの情報に変更があった場合に、前記端末に対して前記ＷｅｂＡＰＩへのアクセス方法を含む情報の更新を通知することを特徴とする付記１０〜１５のいずれかに記載の情報処理方法。
（付記１７）  前記情報は、有効期限情報を含むことを特徴とする付記１０〜１６のいずれかに記載の情報処理方法。
【符号の説明】
【００８７】
１０  サーバ（情報処理装置）
２０  利用要求受信部（受付部）
２４  監視通知部（実行部）
４０  仮想デバイス制御部（生成部の一部）
４２  ＷｅｂＡＰＩ制御部（生成部の一部）
４４  ＴＤ制御部（通知部）
４６  仮想デバイス機能部（アクセス部、応答部）
６０  デバイス
６４  ＷｅｂＡＰＩ監視部（監視部）
７０  ユーザ端末（端末）
８０  ネットワーク
１００  情報処理システム
【図１】
2018180682.tif 000003
【図２】
2018180682.tif 000004
【図３】
2018180682.tif 000005
【図４】
2018180682.tif 000006
【図５】
2018180682.tif 000007
【図６】
2018180682.tif 000008
【図７】
2018180682.tif 000009
【図８】
2018180682.tif 000010
【図９】
2018180682.tif 000011
【図１０】
2018180682.tif 000012
【図１１】
2018180682.tif 000013
【図１２】
2018180682.tif 000014
【図１３】
2018180682.tif 000015
【図１４】
2018180682.tif 000016