(57)【要約】  アプリケーションを実行する際の認証における利便性を向上するため、アプリケーションサーバが、端末の状態を示すコンテキスト情報を端末から取得し、取得したコンテキスト情報に基づいて、アプリケーションを実行する際の認証の要否に関する情報（認証要否テーブル）を生成し、当該認証要否テーブルと、該テーブルに記述された認証モジュールと、を端末１０に対して送信する。そして、端末が、認証要否テーブルと認証テーブルと、に基づいて、アプリケーションを実行する前に認証が必要か否かを判断し（Ｓ１１０）、認証が必要と判断された場合に、アプリケーションの実行に先立って、認証モジュールの読み出し先をアプリケーションの読み出し先に変更して（Ｓ１１２）、認証モジュールを実行する（Ｓ１１６〜Ｓ１２０）。
2014030227.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションを端末装置に対して提供するサーバが、前記端末装置の状態を示すコンテキスト情報を前記端末装置から取得する工程と、
前記サーバが、取得した前記コンテキスト情報に基づいて、前記アプリケーションを実行する際の認証の要否に関する情報を生成する工程と、
前記サーバが、前記認証の要否に関する情報と、当該情報において必要とされている認証を実行するための認証モジュールと、を前記端末装置に対して送信する工程と、
前記端末装置が、前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断する工程と、
前記端末装置が、前記アプリケーションの実行に先立って、前記判断する工程において必要と判断された認証を実行するための認証モジュールの読み出し先を前記アプリケーションの読み出し先に変更して、前記認証モジュールを実行する工程と、を含む認証方法。
【請求項２】
前記認証の要否に関する情報は、前記端末装置の操作者を撮影装置を用いて撮影してログを取得するログモードを実行するか否かに関する情報を含み、
前記認証モジュールを実行する工程では、前記認証モジュールとして前記ログモードを実行可能な監視モジュールを実行することを特徴とする請求項１に記載の認証方法。
【請求項３】
前記生成する工程では、前記サーバは、前記取得したコンテキスト情報に対応する認証の要否に関する情報と、前記取得したコンテキスト情報とは異なるコンテキスト情報に対応する認証の要否に関する情報と、を生成し、
前記認証モジュールを実行する工程では、前記端末装置は、前記アプリケーションを実行する前の当該端末装置のコンテキスト情報に基づいて、前記認証が必要か否かを判断することを特徴とする請求項１又は２に記載の認証方法。
【請求項４】
前記認証の要否に関する情報は、アプリケーション毎に作成されることを特徴とする請求項１〜３のいずれか一項に記載の認証方法。
【請求項５】
サーバに対して、端末装置のコンテキスト情報を提供し、
サーバから、アプリケーションと、前記コンテキスト情報に基づいて生成された前記アプリケーションを実行する際の認証の要否に関する情報と、前記認証の要否に関する情報において必要とされている認証を実行するための認証モジュールと、を取得し、
前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断し、
前記アプリケーションの実行に先立って、前記判断する処理において必要と判断された認証を実行するための認証モジュールの読み出し先を前記アプリケーションの読み出し先に変更して、前記認証モジュールを実行する、処理をコンピュータに実行させることを特徴とする認証プログラム。
【請求項６】
前記認証の要否に関する情報は、前記端末装置の操作者を撮影装置を用いて撮影してログを取得するログモードを実行するか否かに関する情報を含み、
前記認証モジュールを実行する処理では、前記認証モジュールとして前記ログモードを実行可能な監視モジュールを実行することを特徴とする請求項５に記載の認証プログラム。
【請求項７】
前記認証の要否に関する情報は、前記提供する処理で前記サーバに対して提供したコンテキスト情報に対応する認証の要否に関する情報と、前記提供したコンテキスト情報とは異なるコンテキスト情報に対応する認証の要否に関する情報と、を含み、
前記認証モジュールを実行する処理では、前記アプリケーションを実行する前の当該端末装置のコンテキスト情報に基づいて、必要な認証を判断することを特徴とする請求項５又は６に記載の認証プログラム。
【請求項８】
前記認証の要否に関する情報は、アプリケーション毎に作成された情報であることを特徴とする請求項５〜７のいずれか一項に記載の認証プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本件は、認証方法及び認証プログラムに関する。
【背景技術】
【０００２】
パーソナルコンピュータ並の性能を持った携帯端末であるスマートフォンの普及が進んでいる。また、３Ｇ／ＬＴＥ（Long Term Evolution）／ホットスポットの充実等により、スマートフォンが常時ネットワークに接続できる環境が整ってきている。【０００３】
このような環境を活かし、最近では、アプリを配信するアプリケーションサーバから携帯端末に必要なタイミングでアプリを送信して、携帯端末にて当該アプリを実行させる技術が出現しつつある（例えば、非特許文献１参照）。このような技術（アプリプッシュ技術と呼ばれている）を利用することで、例えば、部下から業務の依頼が生じた場合には、業務の処理に必要なアプリ（承認アプリ）がサーバから承認者所有の携帯端末に配信されるので、承認者は携帯端末にて承認業務を行うことができる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】プレスリリース（技術）“時間や場所に応じて必要なアプリケーションが自動配信・自動実行される情報端末技術を開発”、平成２３年７月１９日、株式会社富士通、[平成２４年８月７日検索]、インターネット＜http://pr.fujitsu.com/jp/news/2011/07/19-1.html＞
【特許文献】
【０００５】
【特許文献１】特開２００４−１７８４０８号公報
【特許文献２】特開２００３−１８６８３６号公報
【特許文献３】国際公開第２００７／０６６４８０号
【特許文献４】特開２００１−０６７３３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、個人が所有する携帯端末に配信された業務に関するアプリを用いて業務が実行される場合（ＢＹＯＤ（Beyond Your Own Device）と呼ばれる）、携帯端末のセキュリティが重要になる。この場合、各携帯端末のセキュリティレベルは千差万別であるため、セキュリティレベルをある一定以上確保するためには、ユーザに対して会社等が定めたセキュリティポリシを強制することが考えられる。セキュリティポリシとしては、例えば「ロック解除のためのＰＩＮ（Personal Identification Number）を所定文字数以上にする」など定めることができる。しかるに、このようなセキュリティポリシをユーザに強制した場合、携帯端末の使い勝手が低下するおそれがある。【０００７】
また、アプリプッシュにＤＲＭ（Digital Rights Management）と同様の思想を導入するならば、アプリに適合した認証モジュールを各アプリに持たせる方法も考えられる。しかるに、当該方法を用いる場合、端末とアプリとの間やアプリとアプリとの間に連携がないため、アプリを実行するごとに認証を行わなければならず、携帯端末の使い勝手が低下するおそれがある。【０００８】
なお、認証に関する技術としては、特許文献１〜４などがある。【０００９】
１つの側面では、本発明は、アプリケーションを実行する際の認証における利便性を向上することが可能な認証方法及び認証プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本明細書に記載の認証方法は、アプリケーションを端末装置に対して提供するサーバが、前記端末装置の状態を示すコンテキスト情報を前記端末装置から取得する工程と、前記サーバが、取得した前記コンテキスト情報に基づいて、前記アプリケーションを実行する際の認証の要否に関する情報を生成する工程と、前記サーバが、前記認証の要否に関する情報と、当該情報において必要とされている認証を実行するための認証モジュールと、を前記端末装置に対して送信する工程と、前記端末装置が、前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断する工程と、前記端末装置が、前記アプリケーションの実行に先立って、前記判断する工程において必要と判断された認証を実行するための認証モジュールの読み出し先を前記アプリケーションの読み出し先に変更して、前記認証モジュールを実行する工程と、を含んでいる。【００１１】
本明細書に記載の認証プログラムは、サーバに対して、端末装置のコンテキスト情報を提供し、サーバから、アプリケーションと、前記コンテキスト情報に基づいて生成された前記アプリケーションを実行する際の認証の要否に関する情報と、前記認証の要否に関する情報において必要とされている認証を実行するための認証モジュールと、を取得し、前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断し、前記アプリケーションの実行に先立って、前記判断する処理において必要と判断された認証を実行するための認証モジュールの読み出し先を前記アプリケーションの読み出し先に変更して、前記認証モジュールを実行する、処理をコンピュータに実行させる認証プログラムである。
【発明の効果】
【００１２】
本実施例に記載の認証方法及び認証プログラムは、アプリケーションを実行する際の認証における利便性を向上することができるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】一実施形態に係る情報処理システムの構成を概略的に示す図である。
【図２】図２（ａ）は、端末のハードウェア構成を示す図であり、図２（ｂ）は、アプリケーションサーバのハードウェア構成を示す図である。
【図３】端末及びアプリケーションサーバの機能ブロック図である。
【図４】図４（ａ）は、認証テーブルを示す図であり、図４（ｂ）は、認証要否テーブルを示す図である。
【図５】テーブル作成基準を示す図である。
【図６】アプリケーションサーバの処理を示すフローチャートである。
【図７】端末の処理を説明するための図（その１）である。
【図８】端末の処理を説明するための図（その２）である。
【図９】端末の処理を説明するための図（その３）である。
【発明を実施するための形態】
【００１４】
以下、一実施形態に係る情報処理システムについて、図１〜図９に基づいて詳細に説明する。図１には、一実施形態に係る情報処理システム２００の構成が概略的に示されている。
【００１５】
図１に示すように、情報処理システム２００は、複数の端末装置（以下、「端末」と呼ぶ）１０と、サーバとしてのアプリケーションサーバ１００と、複数の撮影装置７０と、を備える。端末１０とアプリケーションサーバ１００と撮影装置７０とは、インターネットや３Ｇ回線などのネットワーク８０に接続されている。
【００１６】
端末１０は、スマートフォンなどの情報端末装置である。端末１０は、例えば会社組織に属するユーザ個人が所有する端末であるものとし、ユーザは端末１０を私的利用するとともに、会社の業務（アプリケーションサーバ１００から配信されるアプリケーションの実行）にも利用するものとする。
【００１７】
図２（ａ）には、端末１０のハードウェア構成が示されている。図２（ａ）に示すように、端末１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、表示部９３、入力部９５、ＧＰＳ（Global Positioning System）モジュール８９、及び可搬型記憶媒体用ドライブ９９等を備えている。これら端末１０の各部は、バス９８に接続されている。
【００１８】
表示部９３は、液晶ディスプレイや有機ＥＬ（Electro Luminescence）ディスプレイである。入力部９５は、キーボードやタッチパネル、入力ボタン等である。ＧＰＳモジュール８９は、端末１０の位置を検出する。端末１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（認証プログラム）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（認証プログラム）をＣＰＵ９０が実行することにより、図３の各部の機能が実現される。
【００１９】
図１に戻り、アプリケーションサーバ１００は、業務を最小タスク（ユーザが最低限実行しなくてはならない仕事）に分解してアプリケーション化し、当該アプリケーションを端末１０に対して送信する。また、アプリケーションサーバ１００は、端末１０においてアプリケーションを実行する際に行われる認証に関する処理も行う。
【００２０】
図２（ｂ）には、アプリケーションサーバ１００のハードウェア構成が示されている。図２（ｂ）に示すように、アプリケーションサーバ１００は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ここではＨＤＤ）１９６、及び可搬型記憶媒体用ドライブ１９９等を備え、各部は、バス１９８に接続されている。なお、アプリケーションサーバ１００も、端末１０と同様、表示部や入力部を備えていてもよい。アプリケーションサーバ１００では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったプログラムをＣＰＵ１９０が実行することにより、図３の各部の機能が実現される。
【００２１】
図３には、端末１０とアプリケーションサーバ１００の機能ブロック図が示されている。図３に示すように、端末１０は、ＣＰＵ９０がプログラムを実行することで、アプリプッシュ実行部１２、アプリ・モジュール管理部１４、コンテキスト監視部１６、鍵管理部１８、の各機能を実現する。なお、図３には、ＨＤＤ９６等に設けられる監視モジュール格納部２０と、認証モジュール格納部２２と、アプリ格納部２４についても図示されている。
【００２２】
アプリプッシュ実行部１２は、アプリケーションサーバ１００から配信されるアプリケーションのほか、認証モジュールや監視モジュールを実行する。
【００２３】
アプリ・モジュール管理部１４は、アプリケーションサーバ１００から配信されるアプリケーション、認証モジュール及び監視モジュールを保持し、アプリプッシュ実行部１２が実行すべきアプリケーションやモジュールをアプリプッシュ実行部１２に実行させる。ここで、アプリ・モジュール管理部１４は、切替部３０と、監視モジュール格納部２０と、認証モジュール格納部２２と、アプリ格納部２４と、を有する。切替部３０は、認証モジュール格納部２２に格納されている認証モジュールや監視モジュール格納部２０に格納されている監視モジュールの名前（読み出し先）を、アプリ格納部２４に格納されているアプリケーションの名前（読み出し先）と切替えることで（redirection）、実行する必要のあるモジュールをアプリプッシュ実行部１２に自動実行させる。
【００２４】
コンテキスト監視部１６は、端末１０の状態を示すコンテキスト情報（ＧＰＳモジュール８９（図２（ａ））による位置検出結果など）を取得し、鍵管理部１８に通知する。また、コンテキスト監視部１６は、アプリケーションサーバ１００のコンテキスト取得部４２に対してコンテキスト情報を送信する。なお、コンテキスト情報としては、ＧＰＳモジュール８９による位置検出結果（端末１０の位置）の他、端末１０を操作している人が「本人である可能性」や、端末１０からの情報の「漏洩リスク」などが含まれる。
【００２５】
「本人である可能性」については、コンテキスト監視部１６は、例えば、（１）現在の場所でユーザ認証が一定時間内に行われたか否か、（２）同一のアプリケーションが配信される端末（例えば、同じ部署のユーザが保有する端末）が近くに存在するか否か、（３）過去においてユーザの近くに存在していた確率が高い装置（wi-fiガジェットなど）が近くに存在するか否か、などの判断基準の少なくとも１つを用いて判断する。なお、（１）ユーザ認証に関しては、（Ａ）その端末を使用して行われたか否か、（Ｂ）ユーザ認証が行われた機器（入退出ゲートやパソコンなど）の近くに端末が存在しているか否か、などを考慮して本人である可能性を判断することができる。
【００２６】
また、「漏洩リスク」については、コンテキスト監視部１６は、例えば、（１）ユーザ認証後に、端末１０の電源がＯＦＦされたり、再起動されたり、機器構成の変更が行われたりしたか否か、（２）端末１０がデバッグモードであったり、ＵＳＢ通信が行われているか否か、（３）ユーザが所有するいずれかの端末から端末１０を紛失したという情報が出ているか否か、などの判断基準の少なくとも１つを用いて判断する。ここで、上記（３）の場合、ユーザが端末１０以外に利用する端末（ＰＣ等）のブラウザに「端末１０の盗難・紛失報告」のボタンを設けておき、当該ボタンがユーザによって押されたときに、端末１０が盗難又は紛失状態にあると判断してもよい。
【００２７】
なお、漏洩リスクは、アプリケーションの内容に基づいて判断することとしてもよい。例えば、電子メールであれば添付ファイルと本文、画像であればサムネイルと拡大画像、文書であれば黒塗り文書と原本、管理情報であれば社内情報と顧客情報のように分類し、各重要度に応じて漏洩リスクを判断してもよい。
【００２８】
鍵管理部１８は、アプリケーションや認証モジュール、監視モジュールを実行するために必要な鍵（Ｋｅｙ）をアプリケーションサーバ１００から取得し、管理する。また、鍵管理部１８は、アプリプッシュ実行部１２に対して、管理している鍵（Ｋｅｙ）を送信する。
【００２９】
また、鍵管理部１８は、端末１０において過去にどの認証が行われたかなどの情報（過去の認証実績情報）を認証テーブル２６において管理する。認証テーブル２６には、図４（ａ）に示すように、認証方法ごとに、過去に行った認証の履歴情報を示す「ステータス」、及び認証の「正解値」の各フィールドが用意されている。図４（ａ）の例では、端末１０におけるユーザ認証（ロック解除）が３分前にＰＩＮを用いて行われており、当該認証における正解値がＰＩＮであるという情報が格納されている。また、図４（ａ）の例では、認証１が未だ行われておらず、当該認証１における正解値が%&suであるという情報についても格納されている。
【００３０】
図３に戻り、アプリケーションサーバ１００は、ＣＰＵ１９０がプログラムを実行することで、アプリ送信部４０、コンテキスト取得部４２、テーブル生成部４４、情報送信部４６、の各機能を実現する。
【００３１】
アプリ送信部４０は、業務を最小タスクに分解してアプリケーション化し、該アプリケーション及び該アプリケーションのＩＤ（AppID）を端末１０に対して送信する機能を有する。なお、送信されたアプリケーションは、アプリプッシュ実行部１２を経由して、アプリ格納部２４に格納される。
【００３２】
コンテキスト取得部４２は、端末１０のコンテキスト監視部１６から送信されてくるコンテキスト情報を取得し、テーブル生成部４４に対して送信する。
【００３３】
テーブル生成部４４は、コンテキスト取得部４２から受信したコンテキスト情報に基づいて、認証要否テーブルを生成する。ここで、認証要否テーブルは、アプリケーションを実行する際の認証の要否に関する情報を含んでおり、図４（ｂ）に示すように、「AppID」、「Lifetime」、「ロック解除」、「位置１」、「位置２」…の各フィールドを有する。
【００３４】
「AppID」のフィールドには、アプリ送信部４０が端末１０に対して送信したアプリケーション（タスク）のＩＤが入力される。
【００３５】
「Lifetime」のフィールドには、アプリケーション（タスク）ごとに定められた処理期限、例えば「2012/08/05 12:00」が入力される。なお、アプリケーションの処理期限は、業務をアプリケーションサーバ１００に登録したユーザが定めるものとする。したがって、アプリケーションによっては、処理期限が定められない場合もあるものとする。
【００３６】
「ロック解除」のフィールドには、端末１０におけるユーザ認証（ロック解除）が所定時間内に行われていれば他の認証を必要としないとする場合の、当該所定時間が入力される。図４（ｂ）では、一例として「５分未満」が入力されている。すなわち、図４（ｂ）では、端末１０におけるユーザ認証（ロック解除）が５分以内に行われている場合には、認証１などの認証を一切行う必要がないことが定義されている。
【００３７】
「位置１」、「位置２」…のフィールドには、図５のテーブル作成基準に基づいて必要な認証の種別が入力される。図５は、テーブル生成部４４が認証要否テーブルを作成する際に用いるテーブル作成基準の一例である。本実施形態では、図５のテーブル作成基準は、アプリケーション毎に用意されているものとする。この図５のテーブル作成基準においては、場所のリスクの大小、漏洩リスクの高低、本人の可能性の大小に基づいて、端末１０の存在位置毎の認証の要否を決定することができるようになっている。ここで、「位置１」、「位置２」のうち、位置１は、リスクが大きい位置（例えば、会社外）であるものとし、位置２は、リスクが小さい位置（例えば、会社内）であるものとする。なお、位置１、２（例えば、会社の位置）は、予めユーザ等により設定されているものとする。
【００３８】
なお、図４（ｂ）では、図５の本人の可能性が小、漏洩リスクが低の場合の認証要否テーブルが示されている。また、図４（ｂ）の「位置２」のフィールドには、「認証１」と「監視１」とが入力されているが、これらは、アプリケーション（タスク）の緊急度（処理期限（Lifetime）が迫っているか否か）に応じて使い分けられるものとする。
【００３９】
図３に戻り、情報送信部４６は、AppIDと、テーブル生成部４４によって生成された認証要否テーブルと、認証要否テーブルに記述されている認証を実行するための認証モジュールと、認証要否テーブルに記述されている監視を実行するための監視モジュールと、鍵（Ｋｅｙ）と、を端末１０の鍵管理部１８に対して送信する。
【００４０】
図１に戻り、撮影装置７０は、例えば、会社内や街中などに設置された防犯カメラなどの撮影装置であるものとする。撮影装置７０は、端末１０において監視モジュールが実行されたタイミングで撮影を行い、当該撮影結果をアプリケーションサーバ１００のＨＤＤ１９６等にログファイルとして格納する。また、アプリケーションサーバ１００はログファイルが作成されたタイミングで、監視モジュールを実行した端末１０（鍵管理部１８）に対して、ログファイルが作成された旨を通知する。なお、端末１０において監視モジュールが実行されている間は、撮影装置７０を用いてログを取得するログモードが実行されているといえる。
【００４１】
次に、アプリケーションサーバ１００及び端末１０の処理について詳細に説明する。
【００４２】
（アプリケーションサーバ１００の処理）
まず、アプリケーションサーバ１００の処理について、図６のフローチャートに沿って説明する。
【００４３】
図６の処理では、まず、ステップＳ１０において、アプリ送信部４０が、アプリケーション及びAppIDを端末１０に対して送信する。なお、本実施形態では、AppID＝１であるものとする。なお、アプリ送信部４０は、例えば、ある業務（承認に関する業務など）がユーザによってアプリケーションサーバ１００上に登録された段階で、ステップＳ１０の処理を行うものとする。
【００４４】
次いで、ステップＳ１２では、コンテキスト取得部４２が、コンテキスト監視部１６から端末１０のコンテキスト情報を取得する。また、コンテキスト取得部４２は、テーブル生成部４４に対して取得したコンテキスト情報を送信する。
【００４５】
次いで、ステップＳ１４では、テーブル生成部４４が、コンテキスト情報と、図５のテーブル作成基準に基づいて、図４（ｂ）に示す認証要否テーブルを生成する。なお、テーブル生成部４４は、現在の端末１０の位置（例えば位置１とする）における認証の要否以外に、端末１０の移動する可能性のある位置（例えば位置２とする）における認証の要否についても認証要否テーブルに含めるものとする。
【００４６】
次いで、ステップＳ１６では、情報送信部４６が、AppID、認証要否テーブル、該認証要否テーブルに記述されている認証１モジュールや監視１モジュール、各モジュールの鍵及びAppID＝１のアプリケーションの鍵、を鍵管理部１８に対して送信する。なお、鍵管理部１８は、受信した認証１モジュール及び監視１モジュールをアプリ・モジュール管理部１４に送信する。また、アプリ・モジュール管理部１４では、受信した認証１モジュールを認証モジュール格納部２２に格納するとともに、受信した監視１モジュールを監視モジュール格納部２０に格納する。以上のようにして、図６の処理が終了する。
【００４７】
図６の処理が終了した段階では、図３のアプリ格納部２４にAppID＝１のアプリケーションが格納される。また、監視モジュール格納部２０に監視１モジュールが格納され、認証モジュール格納部２２に認証１モジュールが格納される。一方、鍵管理部１８は、受信したアプリケーションの鍵、各モジュールの鍵、認証要否テーブルを保持している。なお、情報送信部４６は、アプリ・モジュール管理部１４が既に格納部２０，２２で保持しているモジュールについては、送信しないようにしてもよい。
【００４８】
（端末１０の処理）
次に、図６の処理が行われた後に行われる端末１０の処理（必要な認証を行うとともに、アプリケーションサーバ１００から配信されたアプリケーションを実行する処理）について、図７〜図９に基づいて説明する。
【００４９】
図７〜図９には、端末１０（アプリプッシュ実行部１２、アプリ・モジュール管理部１４、鍵管理部１８）の処理が示されている。この図７〜図９では、図４（ｂ）の認証要否テーブルに基づく処理を示している。なお、図７〜図９の処理の前提として、コンテキスト監視部１６から鍵管理部１８に対して、端末１０のコンテキスト情報（位置情報）が通知されているものとする。
【００５０】
図７の処理では、まず、ステップＳ１０２において、アプリプッシュ実行部１２が、AppID＝１のアプリケーションのIndex.htmlを起動する。次いで、ステップＳ１０４では、アプリプッシュ実行部１２が、AppID＝１のアプリケーションの鍵（Ｋｅｙ２とする）を鍵管理部１８に対して要求する。
【００５１】
次いで、ステップＳ１０６では、鍵管理部１８が、端末１０の直前のロック解除から５分未満か否かについて判断する。ここでの判断が否定された場合、すなわち、直前のロック解除から５分以上経過している場合には、ステップＳ１０８に移行する。なお、直前のロック解除から５分経過していない場合（ステップＳ１０６の判断が肯定される場合）に関する処理については、後述する。
【００５２】
ステップＳ１０８に移行した場合、鍵管理部１８が、AppID＝１のアプリケーションが期限付きであるか否か、すなわち、図４（ｂ）の認証要否テーブルのLifetimeのフィールドに期限が記載されているか否か、を判断する。ここでの判断が否定された場合には、図８の処理に移行する。一方、ステップＳ１０８の判断が肯定された場合には、図９の処理に移行する。
【００５３】
図８の処理に移行した場合（アプリケーションが期限付きでない場合）、鍵管理部１８は、ステップＳ１１０において、アプリ実行に必要な認証が既にされているか否かを判断する。具体的には、鍵管理部１８は、コンテキスト監視部１６から通知されるコンテキスト情報に基づいて、必要な認証を認証要否テーブル上で確認し、必要な認証を過去行ったか否かを認証テーブル２６の「ステータス」において確認する。例えば、図４（ａ）、図４（ｂ）の例において、コンテキスト情報が「位置１（会社外）」であったとする。この場合、図４（ｂ）の認証要否テーブルでは、「認証１」が必要であり、図４（ａ）の認証テーブルの認証１の「ステータス」が「−（認証されていない）」であるので、ステップＳ１１０の判断は否定されることになる。また、コンテキスト情報が「位置２（会社内）」であった場合にも、図４（ｂ）において緊急度の低い「認証１」が必要であり、図４（ａ）の認証テーブルの認証１の「ステータス」が「−（認証されていない）」であるので、ステップＳ１１０の判断は否定されることになる。
【００５４】
ステップＳ１１０の判断が否定された場合、ステップＳ１１２において、アプリ・モジュール管理部１４の切替部３０は、鍵管理部１８の指示の下、認証１モジュールが実行されるよう認証１モジュールの名前（読み出し先）を変更（redirection）する。この場合、切替部３０は、AppID＝１のアプリケーションの代わりに、認証１モジュールが自動実行されるように、認証１モジュールの読み出し先をアプリケーションの読み出し先に変更する。なお、この場合には、AppID＝１のアプリケーションが認証１モジュールと同時に実行されないようにするために、認証１モジュールの名前を変更するとともに、アプリケーションの名前も別の名前に変更しておく必要がある。
【００５５】
次いで、ステップＳ１１４では、鍵管理部１８が、認証１モジュールの鍵（Ｋｅｙ１とする）をアプリプッシュ実行部１２に対して送信する。次いで、ステップＳ１１６では、アプリプッシュ実行部１２が、AppID＝１及びＫｅｙ１を用いて（すなわち、Load(AppID=1,Key1)で）、Index.htmlを実行する。
【００５６】
次いで、ステップＳ１１８では、アプリ・モジュール管理部１４の切替部３０が、認証１モジュールのIndex.htmlを読み出す。次いで、ステップＳ１２０では、アプリプッシュ実行部１２が認証１モジュールを用いて認証１（チャレンジ／レスポンス認証）を実行し、ユーザの入力したパスワード等を用いてＲｅｓ値を計算する。そして、ステップＳ１２２では、アプリプッシュ実行部１２がAppID＝１とＲｅｓ値を鍵管理部１８に対して送信する。
【００５７】
鍵管理部１８では、ステップＳ１２４において、Ｒｅｓ値と認証テーブルの正解値とを用いた照合を行う。そして、ステップＳ１２６において、照合により認証できたと判断された場合には、鍵管理部１８は、ステップＳ１２８に移行する。なお、認証できなかった場合には、端末１０の全処理が終了するものとする。ただし、これに限らず、認証できなかった場合には、所定回数認証を繰り返すこととしてもよい。
【００５８】
ステップＳ１２８に移行すると、鍵管理部１８は、AppID＝１の鍵（Ｋｅｙ２）をアプリプッシュ実行部１２に対して送信する。次いで、ステップＳ１３０では、アプリ・モジュール管理部１４の切替部３０が、認証１モジュール及びアプリケーションの名前を元の名前に戻す。そして、ステップＳ１３２では、アプリプッシュ実行部１２が、AppID＝１及びＫｅｙ２を用いて（すなわち、Load(AppID=1,Key2)で）、Index.htmlを実行することで、AppID＝１のアプリケーションを実行する。
【００５９】
なお、ステップＳ１１０の判断が肯定された場合、鍵管理部１８は、ステップＳ１２８に直接移行する。すなわち、アプリケーションの実行に必要な認証（ここでは、認証１）が既に行われている場合には、端末１０では、認証を行うことなく、アプリケーションを実行することができるようになっている。
【００６０】
以上のように、図８の処理が行われることで、アプリケーションの実行に必要な認証を既に行っている場合には、認証を行わなくてもアプリケーションを実行することができる。これにより、必要以上の認証を省略できるので、認証の効率化を図ることができる。また、切替部３０は、アプリケーションと認証１モジュールの名前（読み出し先）を変更することで、認証１モジュールをアプリプッシュ実行部１２に自動実行させる。このため、通常のアプリケーションの実行を妨げることなく、アプリプッシュ実行部１２は、認証１モジュールを実行することができる。
【００６１】
なお、図７のステップＳ１０６の判断が肯定された場合、すなわち、端末１０のユーザ認証（ロック解除）から５分未満である場合には、図８のステップＳ１２８に移行する。そして、ステップＳ１２８〜Ｓ１３２の処理を上述したのと同様に実行する（認証なしでアプリケーションを実行する）。このように、ユーザ認証から５分未満であり、端末１０を操作している人が真のユーザである可能性が高いような場合には、認証なしでアプリケーションを実行できるので、ユーザの利便性を向上することができる。
【００６２】
一方、図７のステップＳ１０８の判断が肯定された場合（アプリケーションが期限付きの場合）、図９の処理に移行し、鍵管理部１８は、ステップＳ１５０においてAppID＝１のアプリケーションの処理期限終了の直前か否か（アプリケーション（タスク）の緊急度が高いか否か）を判断する。なお、直前か否かの基準は、ユーザ等によって予め定められているものとする。なお、ステップＳ１５０において、端末１０が位置１に存在している場合には、図４（ｂ）に示すように、緊急度とは無関係に認証１が必要となる。このように認証方法が緊急度と無関係な場合には、無条件で、ステップＳ１５０の判断が否定されるようにすればよい。
【００６３】
ステップＳ１５０の判断が否定された場合、図８のステップＳ１１０に移行し、前述したのと同様の処理（Ｓ１１０〜Ｓ１３２）が行われる。一方、ステップＳ１５０の判断が肯定された場合、すなわち、処理期限終了直前である場合（アプリケーション（タスク）の緊急度が高い場合）には、ステップＳ１５２において、鍵管理部１８は、ロックの一時解除を端末１０のＯＳ（Operating System）に対して指示する。なお、ＯＳとしては、Ａｎｄｒｏｉｄ（登録商標）を採用することができる。ただし、これに限らず、ＯＳとしてはＡｎｄｒｏｉｄ（登録商標）以外のＯＳを採用してもよい。
【００６４】
次いで、ステップＳ１５４では、ＯＳがロック解除を行い、次のステップＳ１５６において、ロック解除の完了通知を鍵管理部１８に対して送信する。
【００６５】
次いで、ステップＳ１５８では、アプリ・モジュール管理部１４の切替部３０が、鍵管理部１８の指示の下、監視１モジュールが実行されるよう監視１モジュールの名前（読み出し先）をアプリケーションの読み出し先に変更する。なお、この場合には、AppID＝１のアプリケーションが監視１モジュールと同時に実行されないようにするために、監視１モジュールの名前（読み出し先）を変更するとともに、アプリケーションの名前（読み出し先）も別のものに変更しておく必要がある。なお、監視１モジュールは、端末１０を操作している操作者を撮影装置７０を用いて撮影してログを取得するモード（ログモード）を実行するモジュールである。
【００６６】
次いで、ステップＳ１６０では、鍵管理部１８が、監視１モジュールの鍵（Ｋｅｙ３とする）をアプリプッシュ実行部１２に対して送信する。次いで、ステップＳ１６２では、アプリプッシュ実行部１２が、AppID＝１及びＫｅｙ３を用いて（すなわち、Load(AppID=1,Key3)で）、Index.htmlを実行する。この場合、アプリ・モジュール管理部１４の切替部３０は、監視１モジュールのIndex.htmlを読み出すことになる。
【００６７】
次いで、ステップＳ１６４では、鍵管理部１８が、撮影装置７０のログファイルが生成されるまで（ログファイルが作成されたことがアプリケーションサーバ１００から通知されるまで）待機する。そして、ログファイルが作成された段階で、アプリ・モジュール管理部１４の切替部３０は、鍵管理部１８の指示の下、ステップＳ１６６において、監視１モジュール及びアプリケーションの名前を元の名前に戻す。
【００６８】
次いで、ステップＳ１６８では、鍵管理部１８が、AppID＝１の鍵（Ｋｅｙ２）をアプリプッシュ実行部１２に対して送信する。そして、次のステップＳ１７０では、アプリプッシュ実行部１２が、AppID＝１及びＫｅｙ２を用いて（すなわち、Load(AppID=1,Key2)で）、Index.htmlを実行することで、AppID＝１のアプリケーションを実行する。
【００６９】
以上のように、本実施形態では、端末１０が図９の処理を実行することで、アプリケーションの処理期限の終了が直前に迫っている場合（緊急度が高い場合）に、撮影装置７０による撮影下において、認証をすることなくアプリケーションを実行することができる。これにより、処理期限終了直前の緊急度が高い場合においては早急にアプリケーションを実行することができるとともに、認証なしでも撮影装置７０の撮影によりセキュリティを確保することができる（例えば、端末１０を保有するユーザ以外が端末１０を操作していた場合でも、後で撮影画像から確認することができる）。
【００７０】
なお、図７〜図９の処理は、アプリケーションサーバ１００から端末１０に対してアプリケーションが送信されてくる度に実行される。なお、図４（ｂ）の認証要否テーブルにおいて、端末１０の位置に対応する監視モジュールが存在していない場合には、図９のステップＳ１５０の判断が常に否定されるようにすればよい。
【００７１】
以上、詳細に説明したように、本実施形態によると、アプリケーションサーバ１００が、端末１０の状態を示すコンテキスト情報を端末１０から取得し（Ｓ１２）、取得したコンテキスト情報に基づいて、アプリケーションを実行する際の認証の要否に関する情報（認証要否テーブル）を生成し（Ｓ１４）、当該認証要否テーブルと、該テーブルに記述された認証モジュールと、を端末１０に対して送信する（Ｓ１６）。そして、端末１０は、認証要否テーブルと認証テーブル２６と、に基づいて、アプリケーションを実行する前に認証が必要か否かを判断し（Ｓ１１０）、認証が必要と判断された場合に、アプリケーションの実行に先立って、認証モジュールの読み出し先をアプリケーションの読み出し先に変更して（Ｓ１１２）、認証モジュールを実行する（Ｓ１１６〜Ｓ１２０）。このようにすることで、アプリケーションの実行に必要な認証のうち、必要な（未だ行われていない）認証のみを端末１０のユーザに行わせることができる。したがって、セキュリティが重要となるＢＹＯＤの分野に個人所有の端末１０を用いたとしても、認証による端末１０の使い勝手の低下が引き起こされるのを抑制することができる。また、本実施形態では、認証モジュールの読み出し先をアプリケーションの読み出し先に変更することで、認証モジュールをアプリプッシュ実行部１２に自動実行させるので、通常のアプリケーションの実行を妨げることなく、認証モジュールを実行することができる。
【００７２】
また、本実施形態では、認証要否テーブルに、端末１０の操作者を撮影装置７０を用いて撮影してログを取得する監視モードの実行要否が記述されており、アプリ・モジュール管理部１４は、認証要否テーブルに基づいて、監視モジュールをアプリプッシュ実行部１２に実行させる。これにより、端末１０において早急にアプリケーションを実行することができるとともに、認証なしでも撮影装置７０の撮影によりセキュリティを確保することができる。
【００７３】
また、本実施形態では、図４（ｂ）に示すように、認証要否テーブルがアプリケーション毎（AppID毎）に作成されるので、アプリケーションの重要度等に応じて、認証の要否を定めることができる。これにより、アプリケーションに応じた認証レベルの設定が可能となるので、ユーザは、個人で保有する端末１０全体のセキュリティレベルを上げる（例えば、ＰＩＮの文字数を増やす）などする必要がなくなる。これにより、ユーザは、自由に端末１０の管理を行うことが可能となる。
【００７４】
なお、アプリケーション実行中に端末１０の位置が変化した場合には、コンテキスト監視部１６から鍵管理部１８に対して、変化通知が送信される。この場合、鍵管理部１８は、変化通知に基づいて、認証要否テーブル（図４（ｂ））と認証テーブル（図４（ａ））を確認し、実行する必要のある認証モジュールが存在しているか否かをチェックする。そして、実行する必要のある認証モジュールが存在していた場合には、アプリケーションの実行を中断して、当該認証モジュールを実行するようにする。これにより、ユーザが移動して、端末１０の位置が変わった場合でも、位置に応じた適切な認証（モジュール）を適切なタイミングで実行することが可能となる。なお、このような端末１０の変化に応じた認証の要否の判断ができるのは、テーブル生成部４４が、端末１０のコンテキスト情報に含まれる位置（例えば位置１）における認証の要否以外に、端末１０が移動する可能性のある位置（例えば位置２）における認証の要否についても認証要否テーブルに含めているためである（ステップＳ１４）。
【００７５】
なお、コンテキスト情報の位置以外の情報が変更された場合（例えば、本人の可能性や漏洩リスクが変わった場合）には、認証要否テーブルを生成し直すこととしてもよい。この認証要否テーブルの生成し直し処理により、認証要否テーブルに異なる認証モジュールや監視モジュールが含まれるようになった場合には、情報送信部４６は、新たに認証要否テーブルに含まれるようになったモジュールや、該モジュール用の鍵を鍵管理部１８に送信するようにすればよい。
【００７６】
なお、上記実施形態では、端末１０の位置変化に対応可能な認証要否テーブルを生成する場合について説明したが、これに限られるものではない。例えば、認証要否テーブル生成時に取得したコンテキスト情報（位置）のみに対応した認証要否テーブルを生成してもよい。
【００７７】
なお、上記実施形態では特に言及していないが、端末１０を保持するユーザを撮影装置７０で追跡するために、アプリプッシュ実行部１２が撮影装置７０を制御することとしてもよい。この場合、例えば、アプリプッシュ実行部１２が、端末１０に装備されている赤外線発光部から一定間隔で端末１０のＩＤを出力し、撮影装置７０が有する赤外線を受光可能な赤外線受光部における受光結果（ＩＤの取得結果）に基づいて、端末１０を保持するユーザを追跡するようにしてもよい。
【００７８】
また、ユーザの顔が撮影装置７０側を常に向くように、ＡＲ（Augmented Reality）技術等を用いて、端末１０の表示部９３上におけるアプリケーションの表示態様を変更するようにしてもよい。この場合、例えば、ユーザの顔が撮影装置７０側を向いている間だけアプリケーションの大きさや向きなどが適切に表示されるようにアプリケーションの表示態様を変更するなどすればよい。
【００７９】
なお、上述した「端末１０の盗難・紛失報告」のボタンが押された場合には、端末１０の位置のログを取得したり、端末１０に搭載されているカメラによる撮影及びログファイルの作成を開始することとしてもよい。なお、その後に、端末１０においてユーザ認証が行われ、端末１０を真のユーザが保持していることが確認できた場合には、アプリケーションサーバ１００のログファイルを消去することとすればよい。
【００８０】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。
【００８１】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００８２】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００８３】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【符号の説明】
【００８４】
１０  端末（端末装置）
２６  過去に行った認証の履歴情報（認証テーブル）
１００  アプリケーションサーバ（サーバ）
【図１】
2014030227.tif 000003
【図２】
2014030227.tif 000004
【図３】
2014030227.tif 000005
【図４】
2014030227.tif 000006
【図５】
2014030227.tif 000007
【図６】
2014030227.tif 000008
【図７】
2014030227.tif 000009
【図８】
2014030227.tif 000010
【図９】
2014030227.tif 000011
【手続補正書】
【提出日】平成27年2月3日(2015.2.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アプリケーションを端末装置に対して提供するサーバが、前記端末装置の状態を示すコンテキスト情報を前記端末装置から取得する工程と、
前記サーバが、取得した前記コンテキスト情報に基づいて、前記アプリケーションを実行する際の認証の要否に関する情報を生成する工程と、
前記サーバが、前記認証の要否に関する情報と、当該情報において必要とされている認証を実行するための認証モジュールと、を前記端末装置に対して送信する工程と、
前記端末装置が、前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断する工程と、
前記端末装置が、前記アプリケーションの実行に先立って、前記判断する工程において必要と判断された認証を実行するための認証モジュールの読み出し先を前記アプリケーションの読み出し先に変更して、前記認証モジュールを実行する工程と、を含む認証方法。
【請求項２】
前記認証の要否に関する情報は、前記端末装置の操作者を撮影装置を用いて撮影してログを取得するログモードを実行するか否かに関する情報を含み、
前記認証モジュールを実行する工程では、前記認証モジュールとして前記ログモードを実行可能な監視モジュールを実行することを特徴とする請求項１に記載の認証方法。
【請求項３】
前記生成する工程では、前記サーバは、前記取得したコンテキスト情報に対応する認証の要否に関する情報と、前記取得したコンテキスト情報とは異なるコンテキスト情報に対応する認証の要否に関する情報と、を生成し、
前記認証モジュールを実行する工程では、前記端末装置は、前記アプリケーションを実行する前の当該端末装置のコンテキスト情報に基づいて、前記認証が必要か否かを判断することを特徴とする請求項１又は２に記載の認証方法。
【請求項４】
前記認証の要否に関する情報は、アプリケーション毎に作成されることを特徴とする請求項１〜３のいずれか一項に記載の認証方法。
【請求項５】
サーバに対して、端末装置のコンテキスト情報を提供し、
サーバから、アプリケーションと、前記コンテキスト情報に基づいて生成された前記アプリケーションを実行する際の認証の要否に関する情報と、前記認証の要否に関する情報において必要とされている認証を実行するための認証モジュールと、を取得し、
前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断し、
前記アプリケーションの実行に先立って、前記判断する処理において必要と判断された認証を実行するための認証モジュールの読み出し先を前記アプリケーションの読み出し先に変更して、前記認証モジュールを実行する、処理をコンピュータに実行させることを特徴とする認証プログラム。
【手続補正書】
【提出日】平成28年6月8日(2016.6.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アプリケーションを端末装置に対して提供するサーバが、前記端末装置の状態を示すコンテキスト情報を前記端末装置から取得する工程と、
前記サーバが、取得した前記コンテキスト情報に基づいて、前記アプリケーションを実行する際の認証の要否に関する情報を生成する工程と、
前記サーバが、前記認証の要否に関する情報と、当該情報において必要とされている認証を実行するための認証モジュールと、を前記端末装置に対して送信する工程と、
前記端末装置が、前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断する工程と、
前記端末装置が、前記アプリケーションの実行に先立って、前記判断する工程において必要と判断された認証を実行するための認証モジュールの名前を前記アプリケーションの名前に変更し、前記アプリケーションの名前を別の名前に変更して、前記アプリケーションの代わりに前記認証モジュールを実行する工程と、
前記アプリケーションの実行中に前記コンテキスト情報が変化した場合、前記端末装置が、他の認証が必要か否かを判断する工程と、
を含む認証方法。
【請求項２】
前記認証の要否に関する情報は、前記端末装置の操作者を撮影装置を用いて撮影してログを取得するログモードを実行するか否かに関する情報を含み、
前記認証モジュールを実行する工程では、前記認証モジュールとして前記ログモードを実行可能な監視モジュールを実行することを特徴とする請求項１に記載の認証方法。
【請求項３】
前記生成する工程では、前記サーバは、前記取得したコンテキスト情報に対応する認証の要否に関する情報と、前記取得したコンテキスト情報とは異なるコンテキスト情報に対応する認証の要否に関する情報と、を生成し、
前記認証モジュールを実行する工程では、前記端末装置は、前記アプリケーションを実行する前の当該端末装置のコンテキスト情報に基づいて、前記認証が必要か否かを判断することを特徴とする請求項１又は２に記載の認証方法。
【請求項４】
前記認証の要否に関する情報は、アプリケーション毎に作成されることを特徴とする請求項１〜３のいずれか一項に記載の認証方法。
【請求項５】
サーバに対して、端末装置のコンテキスト情報を提供し、
サーバから、アプリケーションと、前記コンテキスト情報に基づいて生成された前記アプリケーションを実行する際の認証の要否に関する情報と、前記認証の要否に関する情報において必要とされている認証を実行するための認証モジュールと、を取得し、
前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断し、
前記アプリケーションの実行に先立って、前記判断する処理において必要と判断された認証を実行するための認証モジュールの名前を前記アプリケーションの名前に変更し、前記アプリケーションの名前を別の名前に変更して、前記アプリケーションの代わりに前記認証モジュールを実行し、
前記アプリケーションの実行中に前記コンテキスト情報が変化した場合、他の認証が必要か否かを判断する、処理をコンピュータに実行させることを特徴とする認証プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
本明細書に記載の認証方法は、アプリケーションを端末装置に対して提供するサーバが、前記端末装置の状態を示すコンテキスト情報を前記端末装置から取得する工程と、前記サーバが、取得した前記コンテキスト情報に基づいて、前記アプリケーションを実行する際の認証の要否に関する情報を生成する工程と、前記サーバが、前記認証の要否に関する情報と、当該情報において必要とされている認証を実行するための認証モジュールと、を前記端末装置に対して送信する工程と、前記端末装置が、前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断する工程と、前記端末装置が、前記アプリケーションの実行に先立って、前記判断する工程において必要と判断された認証を実行するための認証モジュールの名前を前記アプリケーションの名前に変更し、前記アプリケーションの名前を別の名前に変更して、前記アプリケーションの代わりに前記認証モジュールを実行する工程と、前記アプリケーションの実行中に前記コンテキスト情報が変化した場合、前記端末装置が、他の認証が必要か否かを判断する工程と、を含んでいる。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
本明細書に記載の認証プログラムは、サーバに対して、端末装置のコンテキスト情報を提供し、サーバから、アプリケーションと、前記コンテキスト情報に基づいて生成された前記アプリケーションを実行する際の認証の要否に関する情報と、前記認証の要否に関する情報において必要とされている認証を実行するための認証モジュールと、を取得し、前記認証の要否に関する情報と、過去に行った認証の履歴情報と、に基づいて、前記アプリケーションを実行する前に認証が必要か否かを判断し、前記アプリケーションの実行に先立って、前記判断する処理において必要と判断された認証を実行するための認証モジュールの名前を前記アプリケーションの名前に変更し、前記アプリケーションの名前を別の名前に変更して、前記アプリケーションの代わりに前記認証モジュールを実行し、前記アプリケーションの実行中に前記コンテキスト情報が変化した場合、他の認証が必要か否かを判断する、処理をコンピュータに実行させる認証プログラムである。
【国際調査報告】
2014030227.tif 000012
2014030227.tif 000013
2014030227.tif 000014
2014030227.tif 000015