以下、添付図面を参照しながら、実施形態を詳細に説明する。
(第1実施形態)
図1は、第1実施形態のアクセスシステム100の一例を示す構成図である。図1に示すように、アクセスシステム100は、アクセス装置110と、サーバ装置130と、アクセス対象装置150と、を備える。
アクセス装置110とアクセス対象装置150とは、ローカルネットワーク101を介して接続されている。また、アクセス装置110及びアクセス対象装置150は、ローカルネットワーク101及び外部ネットワーク102を介してサーバ装置130と接続されている。
ローカルネットワーク101は、無線LAN(Local Area Network)やイーサネット(登録商標)などで構成されたネットワークであり、例えば、宅内LANや社内LANなどの各種LANなどにより実現できる。第1実施形態では、ローカルネットワーク101が宅内LANであり、アクセス装置110及びアクセス対象装置150が同一宅内に存在する場合を例に取り説明するが、これに限定されるものではない。
なお、ローカルネットワーク101は、上記形態に限定されるものではなく、PLC(Power Line Communications)、PAN(Personal Area Network)、又はセルラー回線などであってもよい。PANは、例えば、USB(Universal Serial Bus)、赤外線、Bluetooth(登録商標)、又はZigbee(登録商標)などで構成できる。ローカルネットワーク101がセルラー回線である場合、アクセス装置110は、アクセス対象装置150にセルラー回線で接続する方法(例えば、SIP Name)を予め保持しておくことが望ましい。
外部ネットワーク102は、例えば、インターネットやNGN(Next Generation Network)などにより実現できる。NGNは、品質保証された閉域網である。第1実施形態では、外部ネットワーク102がインターネットである場合を例に取り説明するが、これに限定されるものではない。
アクセス装置110は、アクセス対象装置150の機能にアクセスするものであり、例えば、タブレット端末、パーソナルコンピュータ、スマートフォン、携帯電話、デジタルテレビ、又は専用端末などにより実現できる。つまり、アクセス装置110は、CPU(Central Processing Unit)などの制御装置、ROM(Read Only Memory)やRAM(Random Access Memory)などの記憶装置、HDD(Hard Disk Drive)やSSD(Solid State Drive)などの外部記憶装置、ディスプレイなどの表示装置、各種入力装置、及びNICなどの通信I/Fを備えた通常のコンピュータを利用したハードウェア構成で実現できる。第1実施形態では、アクセス装置110がローカルネットワーク101と接続可能なタブレット端末である場合を例に取り説明するが、これに限定されるものではない。
サーバ装置130は、アクセス装置110がアクセス対象装置150の機能にアクセスするためのアクセス対象装置150の所有者による承認(以下、「ユーザ承認」と称する)以外の承認を行うものである。ユーザ承認以外の承認は、アクセス対象装置150の所有者以外にアクセス装置110によるアクセス対象装置150の機能へのアクセスを管理したいものの承認であればよい。サーバ装置130は、CPUなどの制御装置、ROMやRAMなどの記憶装置、HDDやSSDなどの外部記憶装置、ディスプレイなどの表示装置、各種入力装置、及びNICなどの通信I/Fを備えた通常のコンピュータを利用したハードウェア構成で実現できる。第1実施形態では、ユーザ承認以外の承認は、アクセス対象装置150の製造者による承認(以下、「製造者承認」と称する)であり、サーバ装置130は、アクセス対象装置150の製造会社や関連会社がインターネット上で運営するサーバである場合を例に取り説明するが、これらに限定されるものではない。
アクセス対象装置150は、アクセス装置110のアクセス対象の機能を有し、かつアクセス装置110がアクセス対象装置150の機能にアクセスするためのユーザ承認を行うものである。アクセス対象装置150は、例えば、デジタルテレビ、パーソナルコンピュータ、ハードディスクレコーダ、スマートフォン、携帯電話、タブレット端末、エア・コンディショナー、電気自動車、電気自動車の充電器、又は機器を制御する通信装置であるHEMS(Home Energy Management Server)などにより実現できる。つまり、アクセス対象装置150は、CPUなどの制御装置、ROMやRAMなどの記憶装置、HDDやSSDなどの外部記憶装置、ディスプレイなどの表示装置、各種入力装置、及びNICなどの通信I/Fを備えた通常のコンピュータを利用したハードウェア構成で実現できる。第1実施形態では、アクセス対象装置150がローカルネットワーク101と接続可能なデジタルテレビである場合を例に取り説明するが、これに限定されるものではない。
アクセス装置110は、図1に示すように、第1取得部111と、第2取得部113と、記憶部115と、アクセス部117と、を備える。第1取得部111、第2取得部113、及びアクセス部117は、例えば、CPU(Central Processing Unit)などの処理装置にプログラムを実行させること、即ち、ソフトウェアにより実現できる。記憶部115は、例えば、HDD(Hard Disk Drive)、SSD(Solid State Drive)、RAM(Random Access Memory)、メモリカードなどの磁気的、光学的、又は電気的に記憶可能な記憶装置の少なくともいずれかにより実現できる。
第1取得部111は、ユーザ承認を得る。具体的には、第1取得部111は、ローカルネットワーク101を介してアクセス対象装置150と通信し、アクセス対象装置150からユーザ承認を得る。第1取得部111は、例えば、ユーザ承認としてユーザ認可証を得る。
なお、第1取得部111がユーザ認可証の取得に使用する通信プロトコルは、例えば、HTTP(HyperText Transfer Protocol)、FTP(File Transfer Protocol)、SMTP(Simple Mail Transfer Protocol)、IMAP(Internet Message Access Protocol)、ECHONET Lite、SEP2(Smart Enegy Profile 2)、又はCoAP(Constrained Application Protocol)などを用いることができる。
また、第1取得部111がいずれの通信プロトコルを用いるかは、予めプログラムなどで定めておいてもよいし、第1取得部111がユーザ認可証を取得するタイミングで、UPnP(Universal Plug and Play)、mDNS(multicast Domain Name System)、又はNetBIOS(Network Basic Input Output System)などの機器やサービスを発見する手法を用いて取得してもよい。
第2取得部113は、ローカルネットワーク101及び外部ネットワーク102を介してサーバ装置130と通信し、サーバ装置130からユーザ承認以外の承認を得る。第1実施形態では、ユーザ承認以外の承認は、製造者承認であるものとするが、これに限定されるものではない。第2取得部113は、例えば、製造者承認としてサーバ認可証を得る。
具体的には、第2取得部113は、アクセス装置110に関する情報であるアクセス装置情報をサーバ装置130に送信し、サーバ装置130におけるアクセス装置情報の認証に成功すると、認可内容を決定し、決定した認可内容に応じたサーバ認可証を取得する。アクセス装置情報は、アクセス装置110の製造者、販売者、所有者、個体識別情報、機種、又は装置種別などの識別情報や、アクセス装置110がユーザ認可証及びサーバ認可証を安全に管理できるか否かを示す情報などを含む。これは、ユーザ認可証及びサーバ認可証が秘密情報であるためである。なお、アクセス装置情報は、なりすましを防止するため、第三者機関による署名などが施されていることが望ましいが、これを必須とするものではない。
記憶部115は、第1取得部111により取得されたユーザ承認及び第2取得部113により取得された製造者承認を記憶する。記憶部115は、例えば、ユーザ認可証及びサーバ認可証を記憶する。
アクセス部117は、ユーザ承認及び製造者承認を用いて、ローカルネットワーク101を介してアクセス対象装置150の機能にアクセスする。具体的には、アクセス部117は、ユーザ認可証及びサーバ認可証をアクセス対象装置150に送信し、アクセス対象装置150におけるユーザ認可証及びサーバ認可証の認証に成功すると、アクセス装置110の機能にアクセスする。
機能にアクセス(以下、「機能アクセス」と称する場合がある)とは、例えば、アクセス対象装置150がアクセス装置110に応答を返すことにより、アクセス対象装置150の機能をアクセス装置110に提供する(アクセス装置110がアクセス対象装置150の機能を受け付ける)ことが該当する。アクセス対象装置150の機能をアクセス装置110に提供するとは、例えば、アクセス対象装置150が録画コンテンツリストをアクセス装置110に応答することにより、アクセス装置110でアクセス対象装置150の録画コンテンツリストを表示させることなどが該当する。
機能アクセスはこれに限られず、例えば、アクセス対象装置150が提供可能な情報(例えば、録画コンテンツリスト)をアクセス対象装置150に対して要求し、当該情報を取得する処理も該当する。更に、機能アクセスは、例えば、アクセス対象装置150の状態を変えるなどアクセス対象装置150に機能を実行させることなどであってもよい。アクセス対象装置150に機能を実行させるとは、例えば、アクセス対象装置150にチャンネルを変更させることやアクセス対象装置150に録画コンテンツを操作(再生や削除など)させることなどが該当する。
なお、アクセス部117が機能アクセスに使用する通信プロトコルは、例えば、HTTP、FTP、SMTP、IMAP、ECHONET Lite、SEP2、又はCoAPなどを用いることができる。また、アクセス部117がアクセス対象装置150の機能にアクセスするための手順は、予めプログラムなどで定めておいてもよいし、アクセス部117が機能アクセスを行うタイミングで、UPnP、mDNS、又はNetBIOSなどの機器やサービスを発見する手法を用いて取得してもよい。
サーバ装置130は、図1に示すように、第2承認部131を備える。第2承認部131は、例えば、CPUなどの処理装置にプログラムを実行させること、即ち、ソフトウェアにより実現できる。
第2承認部131は、外部ネットワーク102及びローカルネットワーク101を介してアクセス装置110と通信し、製造者承認をアクセス装置110に発行する。第2承認部131は、例えば、製造者承認としてサーバ認可証を発行する。サーバ認可証は、有効期限が設定されているものとするが、これに限定されるものではない。
具体的には、第2承認部131は、アクセス装置110からアクセス装置情報を受信し、受信したアクセス装置情報を認証する。そして第2承認部131は、認証に成功すると、認可内容を決定し、決定した認可内容に応じたサーバ認可証を発行する。なお、第2承認部131は、認証に失敗した場合、サーバ認可証を発行しない。
アクセス対象装置150は、図1に示すように、第1承認部151と、提供部153と、を備える。第1承認部151及び提供部153は、例えば、CPUなどの処理装置にプログラムを実行させること、即ち、ソフトウェアにより実現できる。
第1承認部151は、ローカルネットワーク101を介してアクセス装置110と通信し、ユーザ承認をアクセス装置110に発行する。第1承認部151は、例えば、ユーザ承認としてユーザ認可証を発行する。ユーザ認可証は、有効期限が設定されているものとするが、これに限定されるものではない。具体的には、第1承認部151は、アクセス装置110との通信が開始されると、図示せぬ表示装置上にユーザ承認画面を表示し、当該ユーザ承認画面上でアクセス対象装置150の所有者による承認操作を受け付けると、ユーザ認可証をアクセス装置110に送信する。ユーザ承認画面は、例えば、Webページや電子的な取扱説明書などに表示される。
図2は、第1実施形態のユーザ承認画面の一例を示す図である。図2に示す例では、アクセス対象装置150の所有者が、アクセス装置110からのアクセスを承認する機能をチェックボックス10で選択し、承認ボタン11を押下すると、第1承認部151が所有者の承認操作を受け付ける。なお、CAPCHAなどコンピュータによる判読が困難な情報をユーザ承認画面に含め、承認ボタン11の押下に加えて、コンピュータによる判読が困難な情報の入力を所有者の承認操作としてもよい。また、承認ボタン11の押下に加えて、アクセス対象装置150の表示装置に表示された文字や数字などアクセス対象装置150の所有者以外は容易に知り得ない情報の入力を所有者の承認操作としてもよい。一方、所有者が拒否ボタン12を押下し、第1承認部151が所有者の拒否操作を受け付けた場合、第1承認部151は、ユーザ認可証をアクセス装置110に送信しない。
なお、アクセス対象装置150からのアクセス対象の機能のリストについては、アクセス対象装置150側で管理してもよいし、アクセス装置110側で管理してもよい。アクセス装置110側で管理する場合、アクセス装置110は、当該リストをアクセス対象装置150に送信すればよい。
また、第1承認部151がユーザ認可証の発行に使用する通信プロトコルは、例えば、HTTP、FTP、SMTP、IMAP、ECHONET Lite、SEP2、又はCoAPなどを用いることができる。また、第1承認部151がいずれの通信プロトコルを用いるかは、予めプログラムなどで定めておいてもよいし、第1取得部111がユーザ認可証を取得するタイミングで、UPnP、mDNS、又はNetBIOSなどの機器やサービスを発見する手法を用いて取得してもよい。また、第1承認部151は、アクセス対象装置150の所有者による承認操作を受け付けた後に、上述の通信プロトコルを用いた通信を有効にすることが望ましい。
また、第1承認部151は、毎回同一のユーザ認可証を発行してもよい。但し、ユーザ認可証は、原則、アクセス装置110及びアクセス対象装置150以外には秘密にすべき情報であるため、第1承認部151は、毎回、異なるユーザ認可証を発行したり、一定時間毎にユーザ認可証を変更して発行したりすることが望ましい。
提供部153は、アクセス装置110からローカルネットワーク101を介して送信されたユーザ承認及び製造者承認に基づいてアクセス装置110に機能を提供する。具体的には、提供部153は、アクセス装置110からユーザ認可証及びサーバ認可証を受信し、受信したユーザ認可証及びサーバ認可証の有効期限の確認などユーザ認可証及びサーバ認可証の認証を行う。提供部153は、例えば、ユーザ認可証の認証は自身で行い、サーバ認可証の認証はローカルネットワーク101及び外部ネットワーク102を介してサーバ装置130と通信することによって行う。
そして提供部153は、認証に成功すれば、アクセス対象の機能を、ローカルネットワーク101を介してアクセス装置110に提供する。例えば、提供部153は、アクセス対象装置150の録画コンテンツリストをアクセス装置110に送信することにより、録画コンテンツリストの表示機能をアクセス装置110に提供する。なお、提供部153は、アクセス対象装置150の機能をアクセス装置110に提供するのではなく、アクセス対象装置150上で実行してもよい。
なお、アクセス装置110、サーバ装置130、及びアクセス対象装置150は、上述した機能部の全てを必須の構成とする必要はなく、その一部を省略した構成としてもよい。例えば、アクセス装置110は、記憶部115を備えなくてもよい。この場合、アクセス装置110は、機能アクセスを行う際に、毎回ユーザ認可証及びサーバ認可証を取得すればよい。
また、アクセス装置110、サーバ装置130、及びアクセス対象装置150が備える機能部を、アクセス装置110、サーバ装置130、及びアクセス対象装置150間で入れ替えてもよい。例えば、アクセス対象装置150が備える第1承認部151を、アクセス装置110が備えるようにしてもよい。
図3は、第1実施形態のアクセスシステム100で行われる機能アクセス処理の手順の流れの一例を示すシーケンス図である。
まず、アクセス装置110は、アクセス部117に機能アクセスを依頼する(ステップS101)。続いて、アクセス部117は、ローカルネットワーク101を介してアクセス対象装置150の機能へのアクセスを試みる(ステップS103)。但し、この時点では、ユーザ認可証及びサーバ認可証が未だ取得されていないため、提供部153は、ローカルネットワーク101を介してアクセス部117にエラー(機能アクセス拒否)を送信し(ステップS105)、アクセス部117は、アクセス装置110にエラーを返却する(ステップS107)。
なお、ステップS101の時点では、記憶部115にユーザ認可証及びサーバ認可証は記憶されていないため、アクセス装置110が機能アクセスを行うためにユーザ認可証及びサーバ認可証が必要であることを予め知っている場合は、ステップS101〜S107を省略してもよい。また、ステップS103の時点でも記憶部115にユーザ認可証及びサーバ認可証は記憶されていないため、アクセス部117は、機能アクセスを試みずにアクセス装置110にエラーを返却してもよい。つまり、ステップS103、S105を省略してもよい。
続いて、アクセス装置110は、第1取得部111にユーザ認可証の取得を依頼する(ステップS109)。続いて、第1取得部111は、ローカルネットワーク101を介して第1承認部151にユーザ認可証を要求する(ステップS111)。続いて、第1承認部151は、図2に示すユーザ承認画面を表示し、当該ユーザ承認画面上でアクセス対象装置150の所有者による承認操作を受け付けると、ローカルネットワーク101を介してユーザ認可証を第1取得部111に送信し(ステップS113)、第1取得部111は、アクセス装置110にユーザ認可証を返却する(ステップS115)。続いて、アクセス装置110は、ユーザ認可証を記憶部115に記憶する。
続いて、アクセス装置110は、第2取得部113にサーバ認可証の取得を依頼する(ステップS117)。続いて、第2取得部113は、ローカルネットワーク101及び外部ネットワーク102を介して第2承認部131にアクセス装置情報を送信し、サーバ認可証を要求する(ステップS119)。続いて、第2承認部131は、アクセス装置情報を認証し、認証に成功すれば、外部ネットワーク102及びローカルネットワーク101を介してサーバ認可証を第2取得部113に送信し(ステップS121)、第2取得部113は、アクセス装置110にサーバ認可証を返却する(ステップS123)。続いて、アクセス装置110は、サーバ認可証を記憶部115に記憶する。
なお、ユーザ認可証及びサーバ認可証の取得順序は、上述したように、ユーザ認可証、サーバ認可証の順序であってもよいし、サーバ認可証、ユーザ認可証の順序であってもよいし、同時であってもよい。
続いて、アクセス装置110は、記憶部115からユーザ認可証及びサーバ認可証を取得し、アクセス部117に再度機能アクセスを依頼する(ステップS125)。続いて、アクセス部117は、ローカルネットワーク101を介して提供部153にユーザ認可証及びサーバ認可証を送信し、機能アクセスを依頼する(ステップS127)。続いて、提供部153は、ユーザ認可証及びサーバ認可証を認証し、認証に成功すれば、アクセス対象の機能を、アクセス部117を介してアクセス装置110に提供する(ステップS129、S131)。
図4は、第1実施形態のアクセスシステム100で行われる機能アクセス処理の手順の流れの一例を示すフローチャートである。
まず、アクセス装置110は、記憶部115にユーザ認可証があるか否かを確認する(ステップS140)。ユーザ認可証がない場合(ステップS140でNo)、第1取得部111は、アクセス対象装置150からユーザ認可証を取得し(ステップS142)、アクセス装置110は、ユーザ認可証を記憶部115に記憶する。一方、ユーザ認可証がある場合(ステップS140でYes)、ステップS142の処理は行われない。
続いて、アクセス装置110は、記憶部115にサーバ認可証があるか否かを確認する(ステップS144)。サーバ認可証がない場合(ステップS144でNo)、第2取得部113は、サーバ装置130からサーバ認可証を取得し(ステップS146)、アクセス装置110は、サーバ認可証を記憶部115に記憶する。一方、サーバ認可証がある場合(ステップS144でYes)、ステップS146の処理は行われない。
なお、ユーザ認可証及びサーバ認可証の取得順序は、上述したように、ユーザ認可証、サーバ認可証の順序であってもよいし、サーバ認可証、ユーザ認可証の順序であってもよいし、同時であってもよい。
続いて、アクセス装置110は、記憶部115からユーザ認可証及びサーバ認可証を取得し、アクセス部117は、ユーザ認可証及びサーバ認可証を用いてアクセス対象装置150への機能アクセスを試みる(ステップS148)。
機能アクセスに成功した場合(ステップS150でYes)、アクセス装置110にアクセス対象装置150の機能が提供される。一方、機能アクセスに失敗した場合(ステップS150でNo)、ユーザ認可証又はサーバ認可証の有効期限が切れている可能性が高いため、アクセス装置110は、記憶部115からユーザ認可証及びサーバ認可証を破棄して(ステップS152)、ステップS140へ戻り、ユーザ認可証及びサーバ認可証の取得をやり直す。
なお、ユーザ認可証及びサーバ認可証のうち有効期限が切れている認可証のみを破棄し、当該認可証の取得のみをやり直すようにしてもよい。また、第1承認部151は、アクセス対象装置150の所有者がユーザ承認画面等で承認(認可)の取り消しを明示的に設定していない場合、所有者の承認を得ずに、ユーザ認可証を再発行してもよい。また、第1承認部151は、アクセス対象装置150の所有者がユーザ承認画面等で承認(認可)の取り消しを明示的に設定している場合、所有者の承認を得ずに、エラーを発行してもよい(ユーザ認可証を再発行しなくてもよい)。
以上のように、第1実施形態によれば、アクセス対象装置150でユーザ承認を行うため、サーバ装置130でのユーザ管理を不要とすることができ、サーバ装置130でのユーザ管理が不要なアクセス認可を実現できる。特に第1実施形態によれば、アクセス装置110のユーザ承認をアクセス対象装置150で行うため、ユーザ承認に用いるユーザ情報を外部に提供する必要がなく、セキュリティを向上できる。
なお、第1実施形態では、アクセス装置110及びアクセス対象装置150は、ローカルネットワーク101及び外部ネットワーク102を介してサーバ装置130と接続されている例を説明したが、これに限られない。アクセス装置110は、ローカルネットワーク101を介さず、外部ネットワーク102を介してサーバ装置130に接続されていてもよい。例えば、アクセス装置110は、2つの外部ネットワーク102を介してサーバ装置130に接続する場合がある。この場合、2つの外部ネットワーク102は、例えば、アクセス装置102とインターネットとを接続する外部ネットワーク102と、インターネットである。この場合、アクセス装置110の第2取得部113は、ローカルネットワーク101を介さず、外部ネットワーク102を介してサーバ装置130と通信する。
(第2実施形態)
第2実施形態では、アプリケーション(以下、「アプリ」と称する)が機能アクセスを行う例について説明する。以下では、第1実施形態との相違点の説明を主に行い、第1実施形態と同様の機能を有する構成要素については、第1実施形態と同様の名称・符号を付し、その説明を省略する。
図5は、第2実施形態のアクセスシステム200の一例を示す構成図である。図5に示すように、第2実施形態のアクセスシステム200は、配信装置270を更に備える。また、第2実施形態のアクセス装置210は、実行部221及び転送部223を更に備える。
配信装置270は、外部ネットワーク102及びローカルネットワーク101を介してアクセス装置210と接続されている。
配信装置270は、アクセス装置210にアプリを配信するものであり、CPUなどの制御装置、ROMやRAMなどの記憶装置、HDDやSSDなどの外部記憶装置、ディスプレイなどの表示装置、各種入力装置、及びNICなどの通信I/Fを備えた通常のコンピュータを利用したハードウェア構成で実現できる。第2実施形態では、配信装置270が配信するアプリは、ブラウザ上で実行されるWebアプリであり、配信装置270は、インターネット上に存在するWebサーバである場合を例に取り説明するが、これに限定されるものではない。
配信装置270は、図5に示すように、配信部271を備える。配信部271は、例えば、CPUなどの処理装置にプログラムを実行させること、即ち、ソフトウェアにより実現できる。
配信部271は、機能アクセスを行うアプリを外部ネットワーク102及びローカルネットワーク101を介してアクセス装置210に配信する。
アクセス装置210の実行部221及び転送部223は、例えば、CPUなどの処理装置にプログラムを実行させること、即ち、ソフトウェアにより実現できる。第2実施形態では、実行部221及び転送部223は、Webブラウザの機能であるものとするが、これに限定されるものではない。
実行部221は、配信装置270から配信されたアプリを実行する。具体的には、実行部221は、配信装置270から配信されたWebアプリを実行すること、例えば、HTML(HyperText Markup Language)のレンダリングやJavaScript(登録商標)を実行することにより、Webブラウザ上でWebアプリを動作させる。
転送部223は、第1承認を第1取得部111から第2取得部113に転送する。具体的には、転送部223は、第1取得部111により取得されたユーザ認可証をWebアプリに認知されない形で、第2取得部113に転送する。なお、第2取得部113が第2承認を先に取得する場合には、転送部223は、第2承認を第2取得部113から第1取得部111に転送してもよい。具体的には、転送部223は、第2取得部113により取得されたサーバ認可証をWebアプリに認知されない形で、第1取得部111に転送する。
第1取得部111は、Webアプリの指示に基づいて第1承認を取得する。また第2実施形態では、第1取得部111がアクセス装置210のWebブラウザ上でユーザ承認画面を表示する。但し、第1実施形態同様、第1承認部151がユーザ承認画面を表示してもよい。
図6は、第2実施形態のユーザ承認画面の一例を示す図である。図6に示す例では、アクセス対象装置150の所有者が、Webアプリからのアクセスを承認する機能をチェックボックス20で選択し、承認ボタン21を押下すると、第1取得部111が所有者の承認操作を受け付け、第1承認部151にユーザ認可証を要求する。一方、所有者が拒否ボタン22を押下し、第1取得部111が所有者の拒否操作を受け付けた場合、第1取得部111は、第1承認部151にユーザ認可証を要求しない。
なお、第2取得部113が第2承認を先に取得する場合には、第1取得部111は、転送部223から転送された第2承認をアクセス対象装置150に送信し、アクセス対象装置150から第2承認を兼ねた第1承認を取得し、Webアプリに渡してもよい。第2承認を兼ねた第1承認は、例えば、第2承認を暗号化したものである。
第2取得部113は、転送部223から転送された第1承認をサーバ装置130に送信し、サーバ装置130から第1承認を兼ねた第2承認を取得する。第1承認を兼ねた第2承認は、例えば、第1承認を暗号化したものである。そして第2取得部113は、第1承認を兼ねた第2承認をWebアプリに渡す。
なお、第2取得部113が第2承認を先に取得する場合には、第2取得部113は、Webアプリの指示に基づいて第2承認を取得してもよい。
アクセス部117は、Webアプリから渡された第1承認を兼ねた第2承認を用いて、機能アクセスを行う。但し、アクセス部117は、第2取得部113からWebアプリを介さずに第1承認を兼ねた第2承認を取得可能な場合には、第2取得部113から直接取得する。
なお、第2取得部113が第2承認を先に取得する場合には、アクセス部117は、Webアプリから渡された第2承認を兼ねた第1承認を用いて、機能アクセスを行ってもよい。但し、アクセス部117は、第1取得部111からWebアプリを介さずに第2承認を兼ねた第1承認を取得可能な場合には、第1取得部111から直接取得する。
図7は、第2実施形態のアクセスシステム200で行われる機能アクセス処理の手順の流れの一例を示すシーケンス図である。
まず、実行部221は、ローカルネットワーク101及び外部ネットワーク102を介して配信部271に機能アクセスを行うWebアプリを要求する(ステップS201)。例えば、実行部221は、アクセス装置210のWebブラウザから配信部271(Webサーバ)のURL(Uniform Resource Locator)にアクセスすることで、Webアプリを要求する。続いて、配信部271は、要求されたWebアプリを外部ネットワーク102及びローカルネットワーク101を介して実行部221に配信する(ステップS203)。続いて、実行部221は、配信部271から配信されたWebアプリを実行する(ステップS205)。これにより、アクセス装置210のWebブラウザ上でWebアプリが動作する。
続いて、Webアプリは、アクセス部117に機能アクセスを依頼する(ステップS207)。例えば、Webアプリは、機能アクセスを行うためのJavaScript API(Application Program Interface)を呼び出し、アクセス部117に機能アクセスを依頼する。続いて、アクセス部117は、ローカルネットワーク101を介してアクセス対象装置150の機能へのアクセスを試みる(ステップS209)。例えば、アクセス部117は、提供部153(Webサーバ)にHTTPリクエストを送信し、アクセス対象装置150の機能へのアクセスを試みる。但し、この時点では、ユーザ認可証及びサーバ認可証が未だ取得されていないため、提供部153は、ローカルネットワーク101を介してアクセス部117にエラー(機能アクセス拒否)を送信し(ステップS211)、アクセス部117は、Webアプリにエラーを返却する(ステップS213)。
なお、ステップS207の時点では、記憶部115にユーザ認可証及びサーバ認可証は記憶されていないため、Webアプリが機能アクセスを行うためにユーザ認可証及びサーバ認可証が必要であることを予め知っている場合は、ステップS207〜S213を省略してもよい。第2実施形態の記憶部115は、例えば、Cookie、WebSQL、WebStorage、又はIndexedDBなどとすることができる。また、ステップS103の時点でも記憶部115にユーザ認可証及びサーバ認可証は記憶されていないため、アクセス部117は、機能アクセスを試みずにWebアプリにエラーを返却してもよい。つまり、ステップS209、S211を省略してもよい。
続いて、Webアプリは、アクセス装置210のWebブラウザを第1承認部151(Webサーバ)のURLにリダイレクトさせる。リダイレクトは、Webブラウザで表示中又は表示しようとしているWebアプリを破棄して、他のURLへのアクセスに置き換えることである。第1承認部151のURLは、アクセス装置210が予め保持していてもよいし、Webアプリの取得時などにネットワーク経由で取得してもよいし、リダイレクトするタイミングで、UPnP、mDNS、又はNetBIOSなどの機器やサービスを発見する手法を用いて取得してもよい。
続いて、第1承認部151は、リダイレクトに対するHTTPレスポンスとして、図6に示すユーザ承認画面を表示するための情報を第1取得部111に送信する。これにより、第1取得部111は、アクセス装置110のWebブラウザに図6に示すユーザ承認画面を表示する。なお、Webアプリは、Webブラウザをリダイレクトさせる際に、当該WebアプリのアプリIDを付与することで、第1承認部151は、ユーザ承認画面を表示するための情報に、当該Webアプリの名称やアクセス対象の機能名など当該Webアプリに関する情報を含めることができる。この結果、第1取得部111は、図6に示すように、ユーザ承認画面内にWebアプリの名称やアクセス対象の機能名などを表示できる。アプリIDは、なりすましを防止するため、第三者機関による署名などが施されていることが望ましいが、これを必須とするものではない。
なお、Webアプリに関する情報は、アプリIDに紐付けられた情報として、予めアクセス対象装置150が保持していてもよいし、アクセス対象装置150が、初回ネットワーク接続時、初期設定時、ユーザ認可証の要求時、又はユーザ認可証の発行時などの通信で、図示せぬアプリID管理サーバなどから取得するようにしてもよい。また、Webアプリが、Webブラウザをリダイレクトさせる際に、当該Webアプリに関する情報も付与している場合には、アクセス対象装置150は、Webアプリによって付与されたWebアプリに関する情報を用いてもよい。
続いて、図6に示すユーザ承認画面上でアクセス対象装置150の所有者による承認操作が行われると、第1取得部111は、ユーザ認可証の取得依頼として受け付け(ステップS215)、HTTPリクエストを第1承認部151に送信し、ユーザ認可証を要求する(ステップS217)。続いて、第1承認部151は、HTTPレスポンスとしてユーザ認可証を第1取得部111に送信する(ステップS219)。この際、第1承認部151は、第1取得部111へ転送部223の使用を指示する。例えば、第1承認部151は、第1承認部151のHTTPレスポンスを、第2承認部131(Webサーバ)のURLへのリダイレクトとし、第1取得部111へ転送部223の使用を指示する。続いて、第1取得部111は、ユーザ認可証とともに転送部223の使用指示を受けると、ユーザ認可証をWebアプリではなく転送部223に渡し(ステップS221)、転送部223は、ユーザ認可証を第2取得部113へ渡し、サーバ認可証の取得を依頼する(ステップS223)。これにより、秘密情報であるユーザ認可証をWebアプリに知らせないですむので、安全性の向上を期待できる。
一方、図6に示すユーザ承認画面上でアクセス対象装置150の所有者による拒否操作が行われると、第1取得部111は、第1承認部151にユーザ認可証を要求せず、第1承認部151は、ユーザ認可証を第1取得部111に送信しない。この際、アクセス装置210のWebブラウザを第1承認部151のURLから配信部271のURLにリダイレクトさせれば、Webアプリにエラーを通知することができる。
続いて、第2取得部113は、ローカルネットワーク101及び外部ネットワーク102を介して第2承認部131にユーザ認可証及びアクセス装置情報を送信し、サーバ認可証を要求する(ステップS225)。例えば、第2取得部113は、第2承認部131にHTTPリクエストでユーザ認可証及びアクセス装置情報を送信し、サーバ認可証を要求する。
続いて、第2承認部131は、アクセス装置情報を認証し、認証に成功すれば、ユーザ認可証を兼ねたサーバ認可証(以下、「ユーザ認可証兼サーバ認可証」と称する)を生成し、外部ネットワーク102及びローカルネットワーク101を介して第2取得部113に送信する(ステップS227)。第2承認部131は、例えば、アクセス装置情報の粒度に応じた秘密鍵を保持しており、この秘密鍵でユーザ認可証を暗号化し、ユーザ認可証兼サーバ認可証を生成する。なお、秘密鍵の対となる公開鍵は、アクセス対象装置150が予め保持していてもよいし、アクセス対象装置150が、初回ネットワーク接続時、初期設定時、ユーザ認可証の要求時、又はユーザ認可証の発行時などの通信で、第2承認部131などから取得するようにしてもよい。
続いて、第2取得部113は、転送部223等を介してWebアプリにユーザ認可証兼サーバ認可証を返却する(ステップS229〜S233)。続いて、Webアプリは、ユーザ認可証兼サーバ認可証を記憶部115に記憶する。
続いて、Webアプリは、記憶部115からユーザ認可証兼サーバ認可証を取得し、アクセス部117に再度機能アクセスを依頼する(ステップS235)。続いて、アクセス部117は、ローカルネットワーク101を介して提供部153にユーザ認可証兼サーバ認可証を送信し、機能アクセスを依頼する(ステップS237)。続いて、提供部153は、公開鍵を用いてユーザ認可証兼サーバ認可証を復号してユーザ認可証を取り出し、ユーザ認可証を認証する。提供部153は、ユーザ認可証の認証に成功した場合、サーバ認可証の認証にも成功したことになるので、アクセス対象の機能を、アクセス部117を介してWebアプリに提供する(ステップS239、S241)。
なお、ユーザ認可証及びサーバ認可証の取得については、第1実施形態と同様の手法で行ってもよい。
図8は、第2実施形態のアクセスシステム200で行われる機能アクセス処理の手順の流れの一例を示すフローチャートである。
まず、Webアプリは、記憶部115にユーザ認可証兼サーバ認可証があるか否かを確認する(ステップS250)。ユーザ認可証兼サーバ認可証がない場合(ステップS250でNo)、第1取得部111は、アクセス対象装置150からユーザ認可証を取得し(ステップS252)、転送部223は、ユーザ認可証を第1取得部111から第2取得部113へ転送し、第2取得部113は、ユーザ認可証をサーバ装置130に送信し、サーバ装置130からユーザ認可証兼サーバ認可証を取得する(ステップS254)。一方、ユーザ認可証兼サーバ認可証がある場合(ステップS250でYes)、ステップS252、S254の処理は行われない。
続いて、Webアプリは、記憶部115からユーザ認可証兼サーバ認可証を取得し、アクセス部117は、ユーザ認可証兼サーバ認可証を用いてアクセス対象装置150への機能アクセスを試みる(ステップS256)。
機能アクセスに成功した場合(ステップS258でYes)、Webアプリにアクセス対象装置150の機能が提供される。一方、機能アクセスに失敗した場合(ステップS258でNo)、ユーザ認可証又はサーバ認可証の有効期限が切れている可能性が高いため、Webアプリは、記憶部115からユーザ認可証兼サーバ認可証を破棄して(ステップS260)、ステップS250へ戻り、ユーザ認可証及びサーバ認可証の取得をやり直す。
例えば、サーバ認可証の有効期限が切れている場合、サーバ認可証の暗号化は古い秘密鍵で行われ、ユーザ認可証兼サーバ認可証の復号は新しい公開鍵で行われることになるので、ユーザ認可証兼サーバ認可証の復号に失敗し、機能アクセスに失敗する。また例えば、ユーザ認可証の有効期限が切れている場合、ユーザ認可証兼サーバ認可証を復号して得たユーザ認可証の認証に失敗し、機能アクセスに失敗する。
以上のように、第2実施形態によれば、Webアプリが機能アクセスを行う場合であっても、秘密情報を漏洩させてしまう可能性があるWebアプリに対しユーザ認可証を秘匿できるので、セキュリティを向上できる。特に第2実施形態によれば、Webアプリが不正なアプリであったとしても、ユーザ認可証を秘匿できるので、セキュリティを向上できる。
また第2実施形態によれば、Webアプリが機能アクセスを行う場合であっても、秘密情報を漏洩させてしまう可能性があるWebアプリに対しサーバ認可証を秘匿することもできる。
(第3実施形態)
第3実施形態では、アクセス対象装置とは異なる承認装置がユーザ承認を行う例について説明する。以下では、第2実施形態との相違点の説明を主に行い、第2実施形態と同様の機能を有する構成要素については、第2実施形態と同様の名称・符号を付し、その説明を省略する。
図9は、第3実施形態のアクセスシステム300の一例を示す構成図である。図9に示すように、第3実施形態のアクセスシステム300は、複数のアクセス対象装置350−1〜350−n(n≧2)及び承認装置390を更に備える。
アクセス装置210、複数のアクセス対象装置350−1〜350−n、及び承認装置390は、ローカルネットワーク101を介して接続されている。なお、複数のアクセス対象装置350−1〜350−nは、ローカルネットワーク101以外のネットワークで承認装置390と接続されてもよい。また、アクセス対象装置は、単数であってもよい。
複数のアクセス対象装置350−1〜350−nは、アクセス装置210のアクセス対象の機能を有するものである。複数のアクセス対象装置350−1〜350−nは、例えば、家電(デジタルテレビ、エア・コンディショナー、照明、冷蔵庫、又は電子レンジなど)、パーソナルコンピュータ、ハードディスクレコーダ、スマートフォン、携帯電話、タブレット端末、電気自動車、電気自動車の充電器、燃料電池、太陽電池、蓄電池、又はセンサー類などにより実現できる。
複数のアクセス対象装置350−1〜350−nは、図9に示すように、それぞれ、提供部353−1〜353−nを備える。提供部353−1〜353−nは、第1、2実施形態で説明した提供部153と同様であるため、説明を省略する。
承認装置390は、アクセス装置210が複数のアクセス対象装置350−1〜350−nの機能にアクセスするためのユーザ承認を行うものである。承認装置390は、例えば、デジタルテレビ、パーソナルコンピュータ、ハードディスクレコーダ、スマートフォン、携帯電話、タブレット端末、充電管理装置、又は機器を制御する通信装置であるHEMS(Home Energy Management Server)などにより実現できる。つまり、承認装置390は、CPUなどの制御装置、ROMやRAMなどの記憶装置、HDDやSSDなどの外部記憶装置、ディスプレイなどの表示装置、各種入力装置、及びNICなどの通信I/Fを備えた通常のコンピュータを利用したハードウェア構成で実現できる。
承認装置390は、図9に示すように、第1承認部391(承認部の一例)と、検出部393とを、備える。
検出部393は、複数のアクセス対象装置350−1〜350−nのローカルネットワーク101への接続状態の変化(例えば、参加や離脱など)を検出する。
第1承認部391は、第1、2実施形態で説明した第1承認部151と同様である。但し、第1承認部391は、検出部393により複数のアクセス対象装置350−1〜350−nのローカルネットワーク101への接続状態の変化が検出されると、発行済みのユーザ承認を無効化する。例えば、第1承認部391は、検出部393により新たなアクセス対象装置のローカルネットワーク101への接続が検出されると、発行済みのユーザ認可証を無効化する。このため、アクセス部117が当該ユーザ認可証を用いて機能アクセスを行った場合、失敗となる。
アクセスシステム300の動作は、基本的に第2実施形態と同様である。但し、アクセス部117の機能アクセスの対象は、複数のアクセス対象装置350−1〜350−nのいずれかであり、第1取得部111のユーザ認可証の取得対象は、承認装置390となる。
また第1取得部111は、第3実施形態では、図10に示すようなユーザ承認画面を表示する。図10は、第3実施形態のユーザ承認画面の一例を示す図である。図10に示す例では、アクセス対象装置150の所有者が、Webアプリからのアクセスを承認する家電(アクセス対象装置)をチェックボックス30で選択し、承認ボタン31を押下すると、第1取得部111が所有者の承認操作を受け付け、第1承認部391にユーザ認可証を要求する。一方、所有者が拒否ボタン32を押下し、第1取得部111が所有者の拒否操作を受け付けた場合、第1取得部111は、第1承認部391にユーザ認可証を要求しない。
但し、第1承認部391は、検出部393により新たなアクセス対象装置のローカルネットワーク101への接続が検出されると、発行済みのユーザ認可証を無効化する。このため、アクセス部117が当該ユーザ認可証を用いて機能アクセスを行った場合、失敗となる。この結果、第1取得部111から第1承認部391へユーザ認可証の発行が再要求されるが、この際に第1取得部111により表示されるユーザ承認画面は、図11に示すように、検出部393により検出された新たな家電(アクセス対象装置)が含まれる。これにより、新たな家電(アクセス対象装置)についてもユーザ承認を求めることができる。
なお、複数のアクセス対象装置350−1〜350−nが、ローカルネットワーク101以外のネットワークで承認装置390と接続されている場合、アクセス部117は、承認装置390を介して複数のアクセス対象装置350−1〜350−nの機能へアクセスする。この場合、アクセス部117及び承認装置390間の通信プロトコルに例えばHTTPなどが利用され、承認装置390及び複数のアクセス対象装置350−1〜350−n間の通信プロトコルに例えばECHONET LiteやSEP2などが利用される。
また、この場合、承認装置390は、提供部353−1〜353−nの一部機能を変わりに実現できる。より具体的には、承認装置390は、提供部353−1〜353nに代わって、アクセス装置110から第1承認及び第2承認を受信し、受信した第1承認及び第2承認の認証を行うことができる。この場合、提供部353−1〜353−nは、第1承認の認証及び第2承認の認証は行わず、承認装置390の認証結果に基づき、アクセス装置390への機能提供のみを行えばよい。なお、承認装置390は、第1承認及び第2承認両方の認証を行わず、片方の認証を行ってもよい。
図12は、第3実施形態のアクセスシステム300をスマートグリッドシステム400に適用した場合の複数のアクセス対象装置350−1〜350−nの一例を示す図である。この場合、複数のアクセス対象装置350−1〜350−nは、風呂401、照明402、エア・コンディショナー403、デジタルテレビ404、冷蔵庫405、蓄電池406、燃料電池407、及び太陽電池409などが該当する。
以上のように、第3実施形態によれば、新たなアクセス対象装置が検出されると、発行済みのユーザ認可証が無効化されるので、新たなアクセス対象装置についてのユーザ承認なしに当該新たなアクセス対象装置への機能アクセスが行われてしまうことを防止できる。
(変形例)
上記各実施形態では、アクセス装置がローカルネットワークを介してユーザ認可証を取得する例について説明したが、ユーザ認可証の取得手法はこれに限定されるものではない。例えば、アクセス装置は、アクセス対象装置から、QRコード(登録商標)、近接無線通信、又はメディアなどを介してユーザ認可証を取得してもよいし、ユーザの手入力によりユーザ認可証を取得してもよい。この場合、アクセス装置にQRコードを読み取らせたり、アクセス装置を近接無線通信可能な位置までアクセス対象装置に近付けたり、ユーザ認可証を手入力したことをもって、ユーザに承認の意思があると判断することができる。
また上記第1実施形態においても、第3実施形態同様、アクセス装置へのアクセス対象の機能の提供をアクセス対象装置で行い、アクセス装置がアクセス対象装置の機能にアクセスするためのアクセス対象装置の所有者による承認を承認装置で行うようにしてもよい。
(ハードウェア構成)
上記各実施形態及び変形例のアクセス装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでCD−ROM、CD−R、メモリカード、DVD、フレキシブルディスク(FD)等のコンピュータで読み取り可能な記憶媒体に記憶されて提供される。
また、上記各実施形態及び変形例のアクセス装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するようにしてもよい。また、上記各実施形態及び変形例のアクセス装置で実行されるプログラムを、インターネット等のネットワーク経由で提供または配布するようにしてもよい。
また、上記各実施形態及び変形例のアクセス装置で実行されるプログラムを、ROM等に予め組み込んで提供するようにしてもよい。
上記各実施形態及び変形例のアクセス装置で実行されるプログラムは、上述した各部をコンピュータ上で実現させるためのモジュール構成となっている。実際のハードウェアとしては、例えば、制御装置が外部記憶装置からプログラムを記憶装置上に読み出して実行することにより、上記各部がコンピュータ上で実現されるようになっている。
以上説明したとおり、上記各実施形態及び変形例によれば、サーバ装置でのユーザ管理を不要とすることができる。
なお本発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また上記各実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせても良い。
例えば、上記各実施形態のフローチャートにおける各ステップを、その性質に反しない限り、実行順序を変更し、複数同時に実施し、あるいは実施毎に異なった順序で実施してもよい。