JP2018041216A - 認証システム及び認証方法 - Google Patents

Abstract

【課題】スマートフォンなどの携帯端末とＩｏＴデバイス間の認証処理において外部の認証サーバを利用することによる遅延や停止が起きることのない認証システム等を提供することを目的とする。【解決手段】外部の認証サーバを利用せずに、携帯端末の有するＩＣチップにインストールされた認証アプリと、ＩｏＴデバイスの有するＩＣチップにインストールされた認証アプリにより認証を行う。【選択図】図５

Description

ＩＣチップ等の電子情報記憶媒体の技術分野に関する。

近年、ＩｏＴ（Internet of Things）という概念が広く提唱されるようになっている。通信コストの低減化やハードウェアの小型化、高機能化、通信システムのオープン化、クラウド化により、これまでネットワークに接続されてこなかったデバイス（機器）がインターネットに接続されることにより、従来では考えられなかった価値やサービスが実現されるようになっている（以下、ネットワーク接続機能を備え、インターネットに接続するデバイスを「ＩｏＴデバイス」という）。

そうした中、特許文献１に記載のＩｏＴブラウジング方法は、モバイル機器がブラウザーを実行すれば、ブラウザーがＩｏＴデバイスに関する情報を受信し、ＩｏＴデバイスをマップ上にアイコン形態で表示する。これにより、ＩｏＴデバイスをマップ上にアイコン形態で表示して様々なＩｏＴサービスを提供するブラウザーを提供できるようになって、ユーザは数多くのＩｏＴデバイスを容易に検索し接続してサービスを受けることができるようになる。

他方で、昨今、ＩｏＴデバイスにより、利用者認証を行うサービスが現れ始めている。例えば、ＩｏＴデバイスをドアの錠の開閉制御装置として採用し、スマートフォンを鍵として使用する等のサービスである。このようなサービスにおいては、ＩｏＴデバイスは非力な性能しか有していないことから、ネットワークを介して接続する認証サーバにスマートフォンユーザの利用者認証処理を依頼し、処理結果に応じてサービスを提供するか否かを判断する遠隔認証を行っている。

特開２０１４−０８１９３７号公報

しかしながら、遠隔認証では、認証サーバとの通信が発生することによる認証処理の遅延や、認証サーバとの接続が途絶することによる認証機能の停止といった問題が起こり得るため、エンドユーザが利用するサービスをシームレスに提供することが困難である。

そこで、本発明は、スマートフォンなどの携帯端末とＩｏＴデバイス間の認証処理において外部の認証サーバを利用することによる遅延や停止が起きることのない認証システム等を提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、第１ＩＣチップを有する第１装置と、第２ＩＣチップを有する第２装置とを含み、前記第１装置と前記第２装置の間の認証を行う認証システムであって、前記第１ＩＣチップは、前記第２ＩＣチップが記憶する認証アプリケーションにより生成された認証情報を受信する受信手段と、前記第１ＩＣチップが記憶する認証アプリケーションにより認証情報を生成する生成手段と、前記受信手段が受信した認証情報と、前記生成手段が生成した認証情報を照合する照合手段と、を備えることを特徴とする。

請求項２に記載の発明は、請求項１に記載の認証システムであって、前記第１装置及び前記第２装置と通信可能であり、且つ、前記第２ＩＣチップが記憶すべき認証アプリケーションを保持するサーバ装置を更に備え、前記第１ＩＣチップは、前記受信手段が、前記第２ＩＣチップから前記認証アプリケーションを記憶していないことを示すアプリ無し情報を更に受信し、前記アプリ無し情報を受信した場合に前記サーバ装置に対して、前記第２ＩＣチップが記憶すべき認証アプリケーションの前記第２ＩＣチップへのダウンロード依頼を行う依頼手段を更に備え、前記サーバ装置は、前記ダウンロード依頼を受けた際に、前記第２ＩＣチップが記憶すべき認証アプリケーションを前記第２ＩＣチップへダウンロードするダウンロード手段を備え、前記第２ＩＣチップは、前記第２ＩＣチップが記憶すべき認証アプリケーションのダウンロード後に、当該認証アプリケーションにより前記認証情報を生成し、前記第１ＩＣチップに送信する送信手段を備えることを特徴とする。

請求項３に記載の発明は、第１ＩＣチップを有する第１装置と、第２ＩＣチップを有する第２装置とを含み、前記第１装置と前記第２装置の間の認証を行う認証システムによる認証方法であって、前記第１ＩＣチップが、前記第２ＩＣチップが記憶する認証アプリケーションにより生成された認証情報を受信する受信工程と、前記第１ＩＣチップが、前記第１ＩＣチップが記憶する認証アプリケーションにより認証情報を生成する生成工程と、前記第１ＩＣチップが、前記受信工程により受信した認証情報と、前記生成工程により生成した認証情報を照合する照合工程と、を含むことを特徴とする。

本発明によれば、第１装置の備える第１ＩＣチップが記憶する認証アプリケーションにより生成された認証情報と、第２装置の備える第２ＩＣチップが記憶する認証アプリケーションにより生成された認証情報とを第１ＩＣチップが照合することにより認証処理が行われることから、外部の認証サーバから独立して認証処理が可能となり、認証サーバとの通信障害や認証サーバの障害による認証処理の遅延や停止を防止することができる。

本実施形態における扉錠制御システムＳの構成例を示す図である。 本実施形態における携帯端末１の構成例を示す図である。 本実施形態における扉錠制御装置２の構成例を示す図である。 本実施形態におけるアプリ管理サーバ３の構成例を示す図である。 本実施形態における扉錠制御システムＳの動作例を示すシーケンス図である。 変形例における扉錠制御システムＳの動作例を示すシーケンス図である。

以下、図面を参照して本発明の実施形態について詳細に説明する。本実施形態は、本願発明を、扉錠制御システムＳに適用した場合の実施形態である。

［１．扉錠制御システムＳの構成］
図１に示すように、本実施形態の扉錠制御システムＳは、携帯端末１と、ＩｏＴデバイスである扉錠制御装置２と、アプリ管理サーバ３を含んで構成されている。携帯端末１と扉錠制御装置２間は、近距離無線通信規格（例えば、ＢＬＵＥＴＯＯＴＨ（登録商標）、ＩＳＯ／ＩＥＣ １４４４３、ＩＳＯ／ＩＥＣ １８０９２等）に則り、通信が可能となっている。アプリ管理サーバ３は、携帯端末１や扉錠制御装置２と移動体通信網ＭＮを介して、通信が可能となっている。扉錠制御装置２は、図示しない扉の錠の開閉（解錠／施錠）を制御する。

扉錠制御システムＳでは、携帯端末１のユーザが携帯端末１を扉錠制御装置２に翳す（近づく）と、携帯端末１と扉錠制御装置２間で相互認証処理が行われて、扉錠制御装置２が携帯端末１を正当な権限を持つと認証した場合に扉の錠を解錠する。相互認証処理は、携帯端末１のＵＳＩＭ（Universal Subscriber Identity Module）にインストールされた相互認証アプリケーション（「認証アプリ」という）と、扉錠制御装置２のＵＳＩＭにインストールされた認証アプリにより行われる。

［２．携帯端末１の構成］
次に、図２を参照して、携帯端末１の概要構成及び機能について説明する。携帯端末１は、制御部１１、記憶部１２、近距離無線通信インターフェース１３、表示部１４、入力部１５、ベースバンド１６を備え、これらの構成要素はバス１９を介して相互に接続される。また、ベースバンド１６は、移動体通信網インターフェース１７及びＵＳＩＭカード１８が接続されている。なお、携帯端末１は、例えば携帯電話機やスマートフォン、タブレット端末等である。

制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、及びＲＡＭ（Random Access Memory）等により構成される。記憶部１２は、例えばフラッシュメモリ等の不揮発性メモリにより構成される。上記ＲＯＭ又は記憶部１２には、携帯端末１のＯＳ（Operating System）及びミドルウェアが記憶される。また、記憶部１２には、携帯端末１にインストールされたＡＰＩ（Application Program Interface）及びアプリ等が記憶される。ＡＰＩは、アプリからオペレーティングシステムの機能を利用するためのインターフェースである。アプリは、例えば所定のサーバからダウンロード可能なプログラムである。

近距離無線通信インターフェース１３は、アンテナを有し、携帯端末１と扉錠制御装置２が近づいたことを検知し、相互間の近距離無線通信を制御する。

表示部１４は、例えばタッチパネル方式の表示パネルを有し、表示パネルへの表示制御、及びユーザからの操作指示の受け付けを行う。入力部１５は、ユーザからの操作指示を入力するための操作ボタンを有し、操作ボタンに応じた信号を制御部１１に出力する。

ベースバンド１６は、移動体通信網ＭＮに接続するための機能を有するハードウェアである。移動体通信網インターフェース１７は、アンテナを有し、移動体通信網ＭＮにおける基地局との間で行われる無線通信を制御する。

ＵＳＩＭカード１８は、ＵＩＣＣ（Universal Integrated Circuit Card）の一つであり、例えば、従来のＳＩＭ（Subscriber Identity Module）をベースに機能を拡張された接触型ＩＣチップを搭載する。ＵＳＩＭカード１８は移動体通信網ＭＮに接続する際、契約者認証のために用いられる。

ＵＳＩＭカード１８はＩＣチップを有し、ＩＣチップは、ＣＰＵ、ＲＡＭ、不揮発性メモリ、及びＩ／Ｏ回路等を備え、これらの構成要素はバスを介して相互に接続される。ＲＡＭには、例えばＩＣチップのＯＳ、各種アプリが機能するうえで一時的に必要となるデータが記憶される。不揮発性メモリは、例えばフラッシュメモリやElectrically Erasable Programmable Read-Only Memoryであり、例えばＩＣチップのＯＳや各種アプリ（契約者認証の際に用いられるＳＩＭアプリケーションや、認証アプリ（「携帯側認証アプリ」という場合がある））がインストールされる。

［３．扉錠制御装置２の構成］
次に、図３を参照して、扉錠制御装置２の概要構成及び機能について説明する。扉錠制御装置２は、制御部２１、記憶部２２、近距離無線通信インターフェース２３、扉錠開閉部２４、入力部２５、ベースバンド２６を備え、これらの構成要素はバス２９を介して相互に接続される。また、ベースバンド２６は、移動体通信網インターフェース２７及びＵＳＩＭカード２８が接続されている。

制御部２１は、ＣＰＵ、ＲＯＭ、及びＲＡＭ等により構成される。記憶部２２は、例えばフラッシュメモリ等の不揮発性メモリにより構成される。上記ＲＯＭ又は記憶部２２には、扉錠制御装置２のＯＳ及びミドルウェアが記憶される。

近距離無線通信インターフェース２３は、アンテナを有し、携帯端末１と扉錠制御装置２が近づいたことを検知し、相互間の無線通信を制御する。

扉錠開閉部２４は、認証アプリによる相互認証処理により近づいてきた携帯端末１が正当な権限を持つと認証された場合に扉の錠を解錠する。入力部２５は、扉錠制御装置２の管理者からの操作指示を入力するための操作ボタンを有し、操作ボタンに応じた信号を制御部２１に出力する。

ベースバンド２６は、移動体通信網ＭＮに接続するための機能を有するハードウェアである。移動体通信網インターフェース２７は、アンテナを有し、移動体通信網ＭＮにおける基地局との間で行われる無線通信を制御する。

ＵＳＩＭカード２８は、ＵＩＣＣの一つであり、例えば、従来のＳＩＭをベースに機能を拡張された接触型ＩＣチップを搭載する。ＵＳＩＭカード２８は移動体通信網ＭＮに接続する際、契約者認証のために用いられる。

ＵＳＩＭカード２８はＩＣチップを有し、ＩＣチップは、ＣＰＵ、ＲＡＭ、不揮発性メモリ、及びＩ／Ｏ回路等を備え、これらの構成要素はバスを介して相互に接続される。ＲＡＭには、例えばＩＣチップのＯＳ、各種アプリが機能するうえで一時的に必要となるデータが記憶される。不揮発性メモリは、例えばフラッシュメモリやElectrically Erasable Programmable Read-Only Memoryであり、例えばＩＣチップのＯＳや各種アプリ（契約者認証の際に用いられるＳＩＭアプリケーションや、認証アプリ（「ＩｏＴ側認証アプリ」という場合がある））がインストールされる。

［４．アプリ管理サーバ３の構成］
次に、図４を参照して、アプリ管理サーバ３の概要構成及び機能について説明する。アプリ管理サーバ３は、制御部３１、記憶部３２、入力部３３、表示部３４、移動体通信網インターフェース３５を備え、これらの構成要素はバス３６を介して相互に接続される。

制御部３１は、ＣＰＵ、ＲＯＭ、及びＲＡＭ等により構成される。記憶部３２は、例えばハードディスクドライブやフラッシュメモリ等の不揮発性メモリにより構成される。上記ＲＯＭ又は記憶部３２には、アプリ管理サーバ３のＯＳや携帯端末１のＵＳＩＭカード１８にダウンロードする認証アプリ等の各種アプリケーションが記憶される。

入力部３３は、ユーザからの操作指示を入力するためのキーボードやマウスからなり、入力操作に応じた信号を制御部３１に出力する。表示部３４は、例えば液晶ディスプレイ及び表示制御部からなり、液晶ディスプレイに各種画面等を表示する。

［５．扉錠制御システムＳの動作例］
次に、図５を参照して、扉錠制御システムＳの動作例について説明する。

まず、携帯端末１のユーザが携帯端末１を扉錠制御装置２に翳すと、扉錠制御装置２の近距離無線通信インターフェース２３の機能により携帯端末１が翳されたことを検知し（ステップＳ１０１）、その旨を扉錠制御装置２の制御部２１に通知する。次いで、制御部２１が、ＵＳＩＭカード２８に対して携帯端末１の検知を通知するとＵＳＩＭカード２８の制御部は、ＩｏＴ側認証アプリの機能により、近距離無線通信により携帯端末１に対して認証情報を要求する（ステップＳ１０２）。

これに対して、携帯端末１の近距離無線通信インターフェース１３がＵＳＩＭカード２８からの認証情報の要求を受信すると、その旨を携帯端末１の制御部１１に通知する。次いで、制御部１１が、ＵＳＩＭカード１８に対して認証情報を要求する（ステップＳ１０３）。これを受けて、ＵＳＩＭカード１８の制御部は、携帯側認証アプリの機能により認証情報を生成し（ステップＳ１０４）、近距離無線通信により扉錠制御装置２に送信する（ステップＳ１０５）。

一方、扉錠制御装置２の近距離無線通信インターフェース２３がＵＳＩＭカード１８からの認証情報を受信すると、その旨を扉錠制御装置２の制御部２１に通知する。更に、制御部２１が、ＵＳＩＭカード２８に対して認証情報を引き渡す（ステップＳ１０６）。これを受けて、ＵＳＩＭカード２８の制御部は、ＩｏＴ側認証アプリの機能により、自らが生成した認証情報と、携帯側認証アプリの機能により生成された認証情報（ＵＳＩＭカード１８から受信した認証情報）を照合し（ステップＳ１０７）、照合結果が一致であるか否かを判定する（ステップＳ１０８）。このとき、ＵＳＩＭカード２８の制御部は、照合結果が一致であると判定した場合には（ステップＳ１０８：ＹＥＳ）、扉錠開閉部２４に扉の錠を解錠させる（ステップＳ１０９）。一方、ＵＳＩＭカード２８の制御部は、照合結果が一致しないと判定した場合には（ステップＳ１０８：ＮＯ）、認証エラーを報知する（ステップＳ１１０）。例えば、図示しないスピーカからエラー音を出力したり、認証エラーであった旨を近距離無線通信により携帯端末１に通知したりする。

なお、携帯側認証アプリとＩｏＴ側認証アプリ間で行われる相互認証の方式については、従来公知の方法を採用することができる。例えば移動体通信における契約者認証で広く用いられているＡＫＡ（Authentication and Key Agreement）認証や、一般的なChallenge-Response認証、公開鍵や証明書に基づく認証など、当該サービスの認証に必要なセキュリティグレードの認証方式を選択し、適宜適用することができる。このため、本実施形態では、認証情報の授受は１往復であるが、認証方式に従って複数回実施しても良い。認証方式は認証アプリによって適宜使い分けられる。認証アプリそのものを入れ替えることにより、認証方式を切り替えても良いし、単一のアプリに複数の認証方式を備えたうえで、パラメータによって用いる認証方式を変更しても良い。

以上説明したように、上記実施形態によれば、扉錠制御システムＳ（「認証システム」の一例）は、ＵＳＩＭカード２８（「第１ＩＣチップ」の一例）を有する扉錠制御装置２（「第１装置」の一例）と、ＵＳＩＭカード１８（「第２ＩＣチップ」の一例）を有する携帯端末１（「第２装置」の一例）とを含み、扉錠制御装置２と携帯端末１の間の認証を行うシステムであって、ＵＳＩＭカード２８の制御部（「受信手段」、「生成手段」、照合手段）の一例）が、ＵＳＩＭカード１８が記憶する携帯側認証アプリにより生成された認証情報を受信し、ＵＳＩＭカード２８が記憶するＩｏＴ側認証アプリにより認証情報を生成し、前記受信した認証情報と、前記生成した認証情報を照合する。

したがって、上記実施形態によれば、ＩｏＴ側認証アプリにより生成された認証情報と、携帯側認証アプリにより生成された認証情報とをＵＳＩＭカード２８の制御部が照合することにより認証処理が行われることから、外部の認証サーバから独立して認証処理が可能となり、認証サーバとの通信障害や認証サーバの障害による認証処理の遅延や停止を防止することができる。

［６．変形例］
次に、上記実施形態の変形例について説明する。なお、以下に説明する変形例は適宜組み合わせることができる。

［６．１．変形例１］
上記実施形態では、扉錠制御装置２と携帯端末１の双方のＵＳＩＭカード１８、２８に、認証アプリがダウンロードされている状態でなければ認証処理を実施できなかった。そこで、本変形例では、扉錠制御装置２に認証アプリをダウンロードする手順について説明する。

扉錠制御装置２は携帯端末１と異なり、常時、移動体通信網ＭＮに接続されており、加えてアプリ管理サーバ３側から指示を送ることにより、扉錠制御装置２側の更新を実行可能であることが一般的である。そこで、ＩｏＴ側認証アプリのダウンロードは、アプリ管理サーバ３の指示を契機として実施することができる。具体的には、アプリ管理サーバ３のＲＯＭ又は記憶部３２は、扉錠制御装置２のＵＳＩＭカード２８にダウンロードする認証アプリを記憶させておき、アプリ管理サーバ３の指示を契機にＯＴＡ（Over The Air）でＵＳＩＭカード２８へ認証アプリをダウンロードする技術は、従来公知の技術（例えば、ＥＴＳＩ ＴＳ１０２．２２６記載のＲＡＭ（Remote Applet Management）や、ＧｌｏｂａｌＰｌａｔｆｏｒｍ Ｃａｒｄ Ｓｐｅｃｉｆｉｃａｔｉｏｎ記載の既存技術）を採用することができる。扉錠制御装置２については、このようなダウンロードをシステムのサービス提供前、又は夜間等のサービス提供時間帯以外の時間に実施しておくことで、上記実施形態を実施する準備を整えることができる。

［６．２．変形例２］
本変形例では、携帯端末１に認証アプリをダウンロードする手順について説明する。携帯端末１側に対しても、扉錠制御装置２と同様にサーバ契機でのダウンロードが可能である。その一方で、携帯端末１側に認証アプリがダウンロードされていないことにより、相互認証処理を実施できずサービスを利用できないことは、サービス提供者及びユーザの利益損失に繋がる。このような事態を回避する手順として、本変形例では、図６を用いて、扉錠制御装置２と携帯端末１の認証処理開始を契機とした、携帯端末１のＵＳＩＭカード１８への携帯側認証アプリのダウンロード手順について説明する。

図６のステップＳ２０１−Ｓ２０３の処理は、図５のステップＳ１０１−Ｓ１０３の処理と同様であるので説明を省略する。ステップＳ２０３の処理後、ＵＳＩＭカード１８の制御部は、携帯側認証アプリが存在するか（ダウンロード・インストール済であるか）を確認し、未存在であることを検知する（ステップＳ２０４）。なお、携帯側認証アプリが存在する場合には図５のステップＳ１０４の処理に移行する。本変形例は携帯側認証アプリが未存在であることを前提とするので、ここでは、未存在であることを検知することとする。次いで、ＵＳＩＭカード１８の制御部は、携帯側認証アプリが未存在であることを示す認証アプリ未存在情報を、近距離無線通信により扉錠制御装置２に送信する（ステップＳ２０５）。

これに対して、扉錠制御装置２の近距離無線通信インターフェース２３がＵＳＩＭカード１８からの認証アプリ未存在情報を受信すると、その旨を扉錠制御装置２の制御部２１に通知する。次いで、制御部２１が、ＵＳＩＭカード２８に対して認証アプリ未存在情報を引き渡す（ステップＳ２０６）。なお、認証アプリ未存在情報を引き渡さなくとも、ＵＳＩＭカード２８に携帯側認証アプリが未存在であることを通知するだけでもよい。次いで、ＵＳＩＭカード２８の制御部は、移動体通信網ＭＮを介して、アプリ管理サーバ３に対して携帯側認証アプリを携帯端末１にダウンロードするように依頼する（ステップＳ２０７）。

アプリ管理サーバ３の移動体通信網インターフェース３５がＵＳＩＭカード２８からの認証アプリのダウンロード依頼を受信すると、これを制御部３１に通知する。そして、制御部３１は、当該依頼に基づいてダウンロード先の携帯端末１を特定し（ステップＳ２０８）、携帯側認証アプリをダウンロードする（ステップＳ２０９）。なお、携帯端末１への携帯側認証アプリのダウンロードが完了した以降の処理については、図５のステップＳ１０４の処理以降と同様であるので説明を省略する。

ところで、ステップＳ２０８の処理において制御部３１が携帯用認証アプリをダウンロードするためには、依頼元の扉錠制御装置２（ＵＳＩＭカード２８）及び携帯端末１（ＵＳＩＭカード１８）を特定する必要がある（前者は正当な依頼元であるかを判定するために特定する必要があり、後者はダウンロード先を特定する必要がある）。そこで、これらを特定するために用いられる携帯端末１（ＵＳＩＭカード１８）、扉錠制御装置２（ＵＳＩＭカード２８）を識別する識別情報について説明する。これらの識別情報として、例えば、次のものが挙げられる。
（Ｉ）扉錠制御装置２を識別する情報
（Ｉ−Ｉ）扉錠制御装置２自身に付与された情報
・ＭＡＣアドレス
（Ｉ−ＩＩ）ＵＳＩＭカード２８（又はＳＥ：Secure Element）に付与された情報
・扉錠制御装置２側ＵＳＩＭ ＩＣＣＩＤ
・扉錠制御装置２側ＵＳＩＭ ＩＭＳＩ
・電話番号（ＭＳＩＳＤＮ）
（ＩＩ）携帯端末１を識別する情報
（ＩＩ−Ｉ）携帯端末１自身に付与された情報
・ＩＭＥＩ（International Mobile Equipment Identity）
（Ｉ−ＩＩ）ＵＳＩＭカード１８に付与された情報
・ＩＣＣＩＤ
・ＩＭＳＩ
・電話番号（ＭＳＩＳＤＮ）

ＵＳＩＭカード２８は、図６のステップＳ２０７の処理において上述した４つの種類の識別情報の組み合わせとともに、アプリ管理サーバ３に対して携帯用認証アプリのダウンロード要求を行う。これに対して、アプリ管理サーバ３の制御部３１は、受信した扉錠制御装置２（ＵＳＩＭカード２８）の識別情報が予め正当な識別情報として登録されているか判定し、正当な識別情報として登録されていると判定した場合に、次いで、図６のステップＳ２０８の処理において、受信した携帯端末１（ＵＳＩＭカード１８）携帯端末１（ＵＳＩＭカード１８）の識別情報に基づいて、ダウンロード先の携帯端末１（ＵＳＩＭカード１８）を特定し（ステップＳ２０８）、携帯側認証アプリをダウンロードする（ステップＳ２０９）。４つの種類の識別情報の組み合わせとして、以下のパターンが考えられる。
（Ａ）扉錠制御装置２自身に付与された情報（ＭＡＣアドレス）と、携帯端末１自身に付与された情報（ＩＭＥＩ）
（Ｂ）扉錠制御装置２自身に付与された情報（ＭＡＣアドレス）と、ＵＳＩＭカード１８に付与された情報（ＩＣＣＩＤ、ＩＭＳＩ、ＭＳＩＳＤＮ）
（Ｃ）ＵＳＩＭカード２８に付与された情報（ＩＣＣＩＤ、ＩＭＳＩ、ＭＳＩＳＤＮ）と、携帯端末１自身に付与された情報（ＩＭＥＩ）
（Ｄ）ＵＳＩＭカード２８に付与された情報（ＩＣＣＩＤ、ＩＭＳＩ、ＭＳＩＳＤＮ）と、ＵＳＩＭカード１８に付与された情報（ＩＣＣＩＤ、ＩＭＳＩ、ＭＳＩＳＤＮ）

ＵＳＩＭカードに付与された情報（ＩＣＣＩＤ、ＩＭＳＩ、ＭＳＩＳＤＮ）のうち、いずれを使用するかは適宜決定することができる。

なお、アプリ管理サーバ３は扉錠制御システムＳ以外のシステムに属するＩｏＴデバイスについても識別情報をダウンロードさせるべきアプリケーションと対応付けて記憶しておき、ダウンロード依頼とともに受信するＩｏＴデバイスの識別情報に対応するアプリケーションをダウンロードすることとしてもよい。これにより、アプリ管理サーバ３は、ダウンロードの依頼元に応じてダウンロードさせるアプリケーションを選択することにより、複数の種類のアプリケーションをダウンロードさせることができる。

以上説明したように、本変形例によれば、扉錠制御システムＳが、扉錠制御装置２及び携帯端末１と通信可能であり、且つ、携帯側認証アプリ（「第２ＩＣチップが記憶すべき認証アプリケーション」の一例）を保持するアプリ管理サーバ３（「サーバ装置」の一例）を更に備え、ＵＳＩＭカード２８の制御部（「受信手段」、「依頼手段」の一例）は、ＵＳＩＭカード１８から携帯側認証アプリを記憶していないことを示すアプリ未存在情報（「アプリ無し情報」の一例）を更に受信し、アプリ未存在情報を受信した場合にアプリ管理サーバ装置３に対して、携帯側認証アプリのＵＳＩＭカード１８へのダウンロード依頼を行う。そして、アプリ管理サーバ３の制御部３１（「ダウンロード手段」の一例）は、ダウンロード依頼を受けた際に、携帯側認証アプリをＵＳＩＭカード１８へダウンロードする。ＵＳＩＭカード１８の制御部（「送信手段」の一例）は、携帯側認証アプリのダウンロード後に、携帯側認証アプリにより認証情報を生成し、ＵＳＩＭカード２８に送信する。

したがって、本変形例によれば、携帯端末１を扉錠制御装置２に翳した際に、ＵＳＩＭカード１８に携帯側認証アプリがダウンロード（インストール）されていない場合であっても、ＵＳＩＭカード２８のＩｏＴ側認証アプリの機能によりアプリ管理サーバ３からダウンロードされることから、サービス提供者及びユーザの利益損失を防ぐことができる。

Ｓ 扉錠制御システム
１ 携帯端末
１１ 制御部
１２ 記憶部
１３ 近距離無線通信インターフェース
１４ 表示部
１５ 入力部
１６ ベースバンド
１７ 移動体通信網インターフェース
１８ ＵＳＩＭカード
１９ バス
２ 扉錠制御装置
２１ 制御部
２２ 記憶部
２３ 近距離無線通信インターフェース
２４ 扉錠開閉部
２５ 入力部
２６ ベースバンド
２７ 移動体通信網インターフェース
２８ ＵＳＩＭカード
２９ バス
３ アプリ管理サーバ
３１ 制御部
３２ 記憶部
３３ 入力部
３４ 表示部
３５ 近距離無線通信インターフェース
ＭＮ 移動体通信網

Claims (3)

1. 第１ＩＣチップを有する第１装置と、第２ＩＣチップを有する第２装置とを含み、前記第１装置と前記第２装置の間の認証を行う認証システムであって、
   前記第１ＩＣチップは、
   前記第２ＩＣチップが記憶する認証アプリケーションにより生成された認証情報を受信する受信手段と、
   前記第１ＩＣチップが記憶する認証アプリケーションにより認証情報を生成する生成手段と、
   前記受信手段が受信した認証情報と、前記生成手段が生成した認証情報を照合する照合手段と、
   を備えることを特徴とする認証システム。
2. 請求項１に記載の認証システムであって、
   前記第１装置及び前記第２装置と通信可能であり、且つ、前記第２ＩＣチップが記憶すべき認証アプリケーションを保持するサーバ装置を更に備え、
   前記第１ＩＣチップは、
   前記受信手段が、前記第２ＩＣチップから前記認証アプリケーションを記憶していないことを示すアプリ無し情報を更に受信し、
   前記アプリ無し情報を受信した場合に前記サーバ装置に対して、前記第２ＩＣチップが記憶すべき認証アプリケーションの前記第２ＩＣチップへのダウンロード依頼を行う依頼手段を更に備え、
   前記サーバ装置は、
   前記ダウンロード依頼を受けた際に、前記第２ＩＣチップが記憶すべき認証アプリケーションを前記第２ＩＣチップへダウンロードするダウンロード手段を備え、
   前記第２ＩＣチップは、前記第２ＩＣチップが記憶すべき認証アプリケーションのダウンロード後に、当該認証アプリケーションにより前記認証情報を生成し、前記第１ＩＣチップに送信する送信手段を備えることを特徴とする認証システム。
3. 第１ＩＣチップを有する第１装置と、第２ＩＣチップを有する第２装置とを含み、前記第１装置と前記第２装置の間の認証を行う認証システムによる認証方法であって、
   前記第１ＩＣチップが、前記第２ＩＣチップが記憶する認証アプリケーションにより生成された認証情報を受信する受信工程と、
   前記第１ＩＣチップが、前記第１ＩＣチップが記憶する認証アプリケーションにより認証情報を生成する生成工程と、
   前記第１ＩＣチップが、前記受信工程により受信した認証情報と、前記生成工程により生成した認証情報を照合する照合工程と、
   を含むことを特徴とする認証方法。
   

Images