(57)【特許請求の範囲】
【請求項１】
情報処理端末が、
当該情報処理端末に関して検知される状況について、所定のプログラムの利用が許可される第１の状況への適合の度合いを算出し、
前記適合の度合いが、前記第１の状況に該当することを示す第１の値から所定の範囲内になると、前記適合の度合いが前記第１の値を示す前に前記所定のプログラムを取得して記憶部に記憶し、
前記所定のプログラムを取得後に前記適合の度合いが前記第１の値を示すまで前記所定のプログラムの利用を制限し、前記適合の度合いが前記第１の値を示すと、前記記憶部に記憶された前記所定のプログラムの利用を許可する、
処理を実行することを特徴とするプログラム取得方法。
【請求項２】
前記適合の度合いが前記第１の値を示す間に利用許可された前記所定のプログラムを、前記適合の度合いが前記第１の値を示さなくなった場合に利用不許可にする、
処理を前記情報処理端末が実行することを特徴とする請求項１記載のプログラム取得方法。
【請求項３】
前記適合の度合いが、前記所定の範囲外になると、前記所定のプログラムを前記記憶部から削除する、
処理を前記情報処理端末が実行することを特徴とする請求項１又は２記載のプログラム取得方法。
【請求項４】
情報処理端末であって、
当該情報処理端末に関して検知される状況について、所定のプログラムの利用が許可される第１の状況への適合の度合いを算出する算出部と、
前記適合の度合いが、前記第１の状況に該当することを示す第１の値から所定の範囲内になると、前記適合の度合いが前記第１の値を示す前に前記所定のプログラムを取得して記憶部に記憶する取得部と、
前記所定のプログラムを取得後に前記適合の度合いが前記第１の値を示すまで前記所定のプログラムの利用を制限し、前記適合の度合いが前記第１の値を示すと、前記記憶部に記憶された前記所定のプログラムの利用を許可する制限部と、
を有することを特徴とする情報処理端末。
【請求項５】
情報処理端末に、
当該情報処理端末に関して検知される状況について、所定のプログラムの利用が許可される第１の状況への適合の度合いを算出し、
前記適合の度合いが、前記第１の状況に該当することを示す第１の値から所定の範囲内になると、前記適合の度合いが前記第１の値を示す前に前記所定のプログラムを取得して記憶部に記憶し、
前記所定のプログラムを取得後に前記適合の度合いが前記第１の値を示すまで前記所定のプログラムの利用を制限し、前記適合の度合いが前記第１の値を示すと、前記記憶部に記憶された前記所定のプログラムの利用を許可する、
処理を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム取得方法、情報処理端末、及びプログラムに関する。
【背景技術】
【０００２】
スマートフォン等の情報処理端末に対して、当該情報処理端末のユーザの状況（居場所や時間等）に対応したアプリケーションが、自動的に配信される仕組みが有る。例えば、ユーザの状況が、所定の状況になったことが検知されると、当該所定の状況に対応するアプリケーションが、当該ユーザの情報処理端末に配信される。換言すれば、斯かるアプリケーションは、所定の状況下においてのみ利用が許可される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開第２０１０／１０９７７６号
【特許文献２】特開２０１４−１１２３２１号公報
【特許文献３】国際公開第２０１０／０７９７７２号
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、所定の状況になってからアプリケーションの配信が開始されたのでは、ユーザは、所定の状況下において直ちにアプリケーションを利用することが困難である。また、所定の状況において、情報処理端末がネットワークに接続できない場合、ユーザは、所定の状況であるにも拘わらず、アプリケーションを入手することができない。【０００５】
そこで、一側面では、所定の状況下で利用が許可されるプログラムの利用を円滑化することを目的とする。
【課題を解決するための手段】
【０００６】
一つの案では、情報処理端末は、当該情報処理端末に関して検知される状況について、所定のプログラムの利用が許可される第１の状況への適合の度合いを算出し、前記適合の度合いが、前記第１の状況に該当することを示す第１の値から所定の範囲内になると、前記適合の度合いが前記第１の値を示す前に前記所定のプログラムを取得して記憶部に記憶し、前記所定のプログラムを取得後に前記適合の度合いが前記第１の値を示すまで前記所定のプログラムの利用を制限し、前記適合の度合いが前記第１の値を示すと、前記記憶部に記憶された前記所定のプログラムの利用を許可する、処理を実行する。
【発明の効果】
【０００７】
一態様によれば、所定の状況下で利用が許可されるプログラムの利用を円滑化することができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の実施の形態におけるシステム構成例を示す図である。
【図２】本発明の実施の形態におけるユーザ端末のハードウェア構成例を示す図である。
【図３】本発明の実施の形態におけるアプリ管理サーバ及びユーザ端末の機能構成例を示す図である。
【図４】ルール記述の受信に応じてユーザ端末が実行する処理の処理手順の一例を説明するためのフローチャートである。
【図５】ルール記述の構成例を示す図である。
【図６】要素確率評価部が実行する処理手順の一例を説明するためのフローチャートである。
【図７】センサ値から要素確率への第１の変換例を説明するための図である。
【図８】センサ値から要素確率への第２の変換例を説明するための図である。
【図９】ルール確率評価部が実行する処理手順の一例を説明するためのフローチャートである。
【図１０】ルール確率の算出例を示す図である。
【図１１】アプリ制御部によるルール確率の受信に応じて実行される処理手順の一例を説明するためのフローチャートである。
【図１２】Ｗｅｂアプリに関する制御の一例を説明するための図である。
【図１３】第一のルール記述に関してユーザ端末が実行する処理内容を説明するための図である。
【図１４】第二のルール記述に関してユーザ端末が実行する処理内容を説明するための図である。
【図１５】第三のルール記述に関してユーザ端末が実行する処理内容を説明するための図である。
【発明を実施するための形態】
【０００９】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。図１において、アプリ管理サーバ２０は、無線ＬＡＮ（Local Area Network）や移動体通信網等の無線通信、又は有線ＬＡＮやシリアル通信等の有線通信等を介して１以上のユーザ端末１０と通信可能である。なお、説明の便宜上、図１に示されるシステム構成は、或る企業内（以下、「企業Ａ」という。）において構築されていることとする。
【００１０】
ユーザ端末１０は、ユーザによって直接操作される端末である。ユーザ端末１０の一例として、スマートフォン及びタブレット端末等のスマート端末が挙げられる。但し、ＰＣ（Personal Computer）等、他の種類の情報処理端末であって、無線又は有線通信が可能な情報処理端末が、ユーザ端末１０として利用されてもよい。
【００１１】
アプリ管理サーバ２０は、各ユーザ端末１０のユーザのコンテキストに対応したＷｅｂアプリケーションプログラム（以下、「Ｗｅｂアプリ」という。）を、各ユーザ端末１０に配信するコンピュータである。コンテキストとは、例えば、現在の所在地、現在の日時、現在の天候等、ユーザが置かれた状況を示す概念である。なお、ユーザ端末１０は、ユーザによって携帯される。したがって、ユーザのコンテキストは、ユーザ端末１０に関するコンテキストであるといえる。
【００１２】
なお、Ｗｅｂアプリとは、ＨＴＭＬ（HyperText Markup Language）、ＣＳＳ（Cascading Style Sheets）、及びＪａｖａＳｃｒｉｐｔ（登録商標）等を構成要素とするアプリケーションプログラムである。例えば、本実施の形態におけるＷｅｂアプリは、Ｐａｃｋａｇｅｄ  Ｗｅｂ  Ａｐｐｓ形式（http://www.w3.org/TR/widgets/参照）のＷｅｂアプリであってもよい。
【００１３】
図２は、本発明の実施の形態におけるユーザ端末のハードウェア構成例を示す図である。図２において、ユーザ端末１０は、ＣＰＵ１０１、メモリ１０２、補助記憶装置１０３、タッチパネル１０４、無線通信装置１０５、及びセンサ群１０６等を有する。
【００１４】
補助記憶装置１０３は、ユーザ端末１０にインストールされたプログラム等を記憶する。メモリ１０２は、プログラムの起動指示があった場合に、補助記憶装置１０３からプログラムを読み出して記憶する。ＣＰＵ１０１は、メモリ１０２に記憶されたプログラムに従ってユーザ端末１０に係る機能を実現する。
【００１５】
タッチパネル１０４は、入力機能と表示機能との双方を備えた電子部品であり、情報の表示や、ユーザからの入力の受け付け等を行う。タッチパネル１０４は、表示装置１１１及び入力装置１１２等を含む。
【００１６】
表示装置１１１は、液晶ディスプレイ等であり、タッチパネル１０４の表示機能を担う。入力装置１１２は、表示装置１１１に対する接触物の接触を検出するセンサを含む電子部品である。接触物の接触の検出方式は、静電方式、抵抗膜方式、又は光学方式等、公知の方式のいずれであってもよい。なお、接触物とは、タッチパネル１０４の接触面（表面）に接触する物体をいう。斯かる物体の一例として、ユーザの指や専用又は一般のペン等が挙げられる。無線通信装置１０５は、無線通信を行うために必要とされる電子部品である。
【００１７】
センサ群１０６は、１以上の種類のセンサの集合である。例えば、ＧＰＳ（Global Positioning System）センサ、時間センサ（タイマー）、ＮＦＣ（Near field communication）センサ等が、センサ群１０６を構成してもよい。本実施の形態において、センサ群１０６は、ユーザ端末１０のユーザのコンテキストを把握するために用いられる。
【００１８】
図３は、本発明の実施の形態におけるアプリ管理サーバ及びユーザ端末の機能構成例を示す図である。図３において、アプリ管理サーバ２０は、ルール配信部２１及びアプリ配信部２２等を有する。これら各部は、アプリ管理サーバ２０にインストールされた１以上のプログラムが、アプリ管理サーバ２０のＣＰＵに実行させる処理により実現される。アプリ管理サーバ２０は、また、ルール記憶部２３及びアプリ記憶部２４等を利用する。これら各記憶部は、アプリ管理サーバ２０が有する補助記憶装置、又はアプリ管理サーバ２０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【００１９】
ルール配信部２１は、ルール記憶部２３に記憶されているルール記述を、各ユーザ端末１０に配信する。ルール記述とは、ルールが記述されているデータをいう。ルールとは、Ｗｅｂアプリの実行条件を含む情報をいう。Ｗｅｂアプリの実行条件とは、当該Ｗｅｂアプリの実行（又は利用）が許可されるために満たされるべき条件をいう。実行条件は、コンテキストに基づいて設定される。すなわち、実行条件は、Ｗｅｂアプリの実行が許可されるコンテキストを示す情報である。複数の状態又は状況の組み合わせによって、実行条件が形成されてもよい。実行条件の一例として、以下の例１〜例３が挙げられる。
例１）１０：００〜１１：００の間だけ実行可能
例２）１０：００〜１１：００の間で、かつ、武蔵中原駅構内で実行可能
例３）１０：００〜１１：００の間、又は、武蔵な原駅構内で実行可能
ルール記憶部２３は、Ｗｅｂアプリごとにルール記述を記憶する。但し、同じコンテキストに対して複数のＷｅｂアプリの実行が許可される場合、これらの複数のＷｅｂアプリの集合（以下、「アプリセット」という。）に対して１つのルール記述が設定されてもよい。ルール記述の配信は、例えば、ルール記憶部２３に対するルールの登録に応じて行われる。
【００２０】
アプリ配信部２２は、ルール記述における実行条件を満たしたユーザ端末１０に対して、当該ルール記述に係るＷｅｂアプリを配信する。アプリ記憶部２４は、配信候補のＷｅｂアプリを記憶する。
【００２１】
一方、ユーザ端末１０は、ルール受信部１１、要素確率評価部１２、ルール確率評価部１３、アプリ制御部１４、アプリ取得部１５、及びアプリ実行部１６等を有する。これら各部は、ユーザ端末１０にインストールされた１以上のプログラムが、ＣＰＵ１０１に実行させる処理により実現される。ユーザ端末１０は、また、アプリ記憶部１２１を有する。アプリ記憶部１２１は、例えば、補助記憶装置１０３を用いて実現可能である。
【００２２】
ルール受信部１１は、アプリ管理サーバ２０から配信されるルール記述を受信する。ルール受信部１１は、受信したルール記述を、ルール確率評価部１３に設定する。
【００２３】
要素確率評価部１２は、センサ群１０６を構成するセンサごとに存在する。要素確率評価部１２は、当該要素確率評価部１２が対応するセンサによって検知される値について、ルール記述に含まれる実行条件の構成要素（以下、「条件要素」という。）のうち、当該センサに対応する条件要素への適合の度合い（以下、「要素確率」という。）を評価する。条件要素とは、実行条件を構成する１つの状況に対応する条件をいう。例えば、上記の例２の実行条件では、「１０：００〜１１：００の間」と、「武蔵中原駅構内」とのそれぞれが、条件要素に該当する。前者の条件要素は時間に対する条件あり、後者の条件要素は所在位置に対する条件ある。したがって、この場合、前者の条件要素に関する要素確率は、時計であるセンサに対応する要素確率評価部１２によって評価される。後者の条件要素に関する要素確率は、ＧＰＳセンサに対応する要素確率評価部１２によって評価される。
【００２４】
要素確率は、０．０〜１．０（０％〜１００％）の間で、ユーザ端末１０に関する現在の状況が、当該条件要素を充足する状況にどの程度適合しているのか、又はどの程度近似しているのかを示す情報である。
【００２５】
ルール確率評価部１３は、ルール記述ごとに、当該ルール記述の実行条件が満たされる確率を評価する。ルール記述の実行条件が満たされる確率（以下、「ルール確率」という。）率は、当該実行条件を構成する条件要素ごとの要素確率に基づいて評価される。すなわち、ルール確率は、０．０〜１．０（０％〜１００％）の間で、ユーザ端末１０に関する現在の状況が、実行条件を充足する状況にどの程度適合しているのか、又はどの程度近似しているのかを示す情報である。
【００２６】
アプリ制御部１４は、Ｗｅｂアプリの取得時期と起動時期とを判断する。例えば、アプリ制御部１４は、ルール確率評価部１３によって評価されるルール確率が閾値以上となると、当該ルール確率に係るＷｅｂアプリの取得を、アプリ取得部１５に指示する。また、アプリ制御部１４は、ルール確率評価部１３によって評価されるルール確率が１．０（１００％）になると、当該ルール確率に係るＷｅｂアプリの起動を、アプリ実行部１６に指示する。
【００２７】
アプリ取得部１５は、アプリ制御部１４から取得を指示されたＷｅｂアプリを、アプリ管理サーバ２０から取得（ダウンロード）する。取得されたＷｅｂアプリは、アプリ記憶部１２１に記憶される。この際、取得されたＷｅｂアプリは、ユーザによる利用が制限された状態（以下、「利用制限状態」という。）でアプリ記憶部１２１に記憶される。アプリ取得部１５によってＷｅｂアプリが取得された時点においては、Ｗｅｂアプリの実行条件は満たされていないため、当該実行条件が満たされるまで、当該Ｗｅｂアプリの利用が許可されるのは適切ではないからである。利用制限状態の実現方法は、所定のものに限定されない。例えば、ユーザからＷｅｂアプリの存在が隠蔽されてもよい。Ｗｅｂアプリの存在の隠蔽は、Ｗｅｂアプリのアイコンがホーム画面に表示されないことによって実現されてもよい。また、Ｗｅｂアプリへのアクセスが行われてもＷｅｂアプリを解読できないように、Ｗｅｂアプリが暗号化されてアプリ記憶部１２１に記憶されてもよい。又は、Ｗｅｂアプリのアイコンがホーム画面に表示されるか否かを問わず、Ｗｅｂアプリの起動が許可されないようにしてもよい。また、Ｗｅｂアプリの一部の機能の利用が制限されてもよい。
【００２８】
アプリ実行部１６は、アプリ制御部１４から取得を指示されたＷｅｂアプリを起動する。
【００２９】
以下、ユーザ端末１０が実行する処理手順について説明する。図４は、ルール記述の受信に応じてユーザ端末が実行する処理の処理手順の一例を説明するためのフローチャートである。
【００３０】
ステップＳ１０１において、ルール受信部１１は、アプリ管理サーバ２０のルール配信部２１によって配信されたルール記述を受信する。一度に複数のルール記述が受信されてもよい。ルール受信部１１は、受信したルール記述を、ルール確率評価部１３に設定する。
【００３１】
続いて、ルール確率評価部１３は、設定されたルール確率を解析し、ルール記述から条件要素と、条件要素間の論理演算子とを抽出する（Ｓ１０２）。
【００３２】
図５は、ルール記述の構成例を示す図である。図５には、一つのルール記述の例が示されている。図５において、ルール記述は、ルールＩＤ、アプリＩＤ、及び実行条件等を含む。ルールＩＤは、ルール記述ごとの識別情報である。アプリＩＤは、Ｗｅｂアプリごと、又はアプリセットごとの識別情報である。実行条件は、当該ルール記述におけるアプリＩＤに係るＷｅｂアプリに対する実行条件である。
【００３３】
図５において、実行条件は、「ＡＮＤ（Ａ，Ｂ）」と記載されている。ここで、ＡＮＤは、引数（ＡＮＤに続く括弧内にカンマ区切りで示されている値）に指定される条件要素間の論理関係を示す論理演算子である。当該括弧内には、３つ以上の引数（条件要素）が列挙されてもよい。ＡＮＤ演算子の引数である「Ａ」及び「Ｂ」のそれぞれは、条件要素である。なお、「Ａ」及び「Ｂ」は、実際には具体的な条件が指定されるが、図５において、各条件要素は、便宜上、符号化されて表現されている。例えば、「Ａ」は、「１０：００〜１１：００」であり、「Ｂ」は、「武蔵中原駅構内」であってもよい。
【００３４】
したがって、ステップＳ１０２では、条件要素として、「Ａ」及び「Ｂ」が抽出され、論理演算子として「ＡＮＤ」が抽出される。なお、論理演算子としては、例えば、ＡＮＤ、ＯＲ、ＮＯＴ、及びＳＥＱ等が使用可能であってもよい。本実施の形態において、各論理演算子の意味は、例えば、以下の通りである。
【００３５】
ＡＮＤ演算子は、引数の全ての条件要素の要素確率の平均値（１／ｎΣＳｉ）を示す。
【００３６】
ＯＲ演算子は、引数の全ての条件要素の要素確率の最大値（ｍａｘ｛Ｓ１，Ｓ２，・・・Ｓｎ｝）を示す。
【００３７】
ＮＯＴ演算子は、引数の条件要素の要素確率を１から差し引いた値（１−Ｓ）を示す。なお、ＮＯＴ演算子の引数は、１つである。
【００３８】
ＳＥＱ演算子は、引数の全ての条件要素の要素確率が引数の順番で満たされる過程における、全ての要素確率の平均値（１／ｎΣＳｉ）を示す。すなわち、ＳＥＱ演算子は、条件要素が満たされる順番に対して制約が有る点において、ＡＮＤ演算子と異なる。例えば、ＳＥＱ（Ａ，Ｂ，Ｃ）の場合、Ａ、Ｂ、Ｃの順で、条件要素が満たされる（要素確率が１．０となる）ことが必要とされる。仮に、Ａの要素確率が、０．０である状態において、Ｂ又はＣの要素確率が１．０となった場合、当該ＳＥＱ演算子の値は、０．０となる。また、Ａの要素確率が１．０になった後であって、Ｂの要素確率が１．０になる前に、Ｃの要素確率が１．０となった場合も、当該ＳＥＱ演算子の値は、０．０となる。
【００３９】
なお、上記において、ｎは、引数の数である。Ｓｉは、ｉ番目の引数に係る条件要素の要素確率である。
【００４０】
なお、上記各論理演算子の意味は、適宜変更されてもよい。また、他の論理演算子が追加されてもよい。
【００４１】
続いて、ルール確率評価部１３は、抽出された条件要素ごとに、当該条件要素に対応する要素確率評価部１２に当該条件要素とルールＩＤとを設定する（Ｓ１０３）条件要素を設定された要素確率評価部１２は、例えば、メモリ１０２に、ルールＩＤに関連付けて条件要素を記憶する。
【００４２】
続いて、条件要素を設定された各要素確率評価部１２が実行する処理手順について説明する。図６は、要素確率評価部が実行する処理手順の一例を説明するためのフローチャートである。
【００４３】
ステップＳ２０１において、要素確率評価部１２は、センサ群１０６のうち、自らに対応するセンサによって検知、検出、測定、又は計測された値（以下、「センサ値」という）を取得する。続いて、要素確率評価部１２は、取得されたセンサ値を、自らに設定されている条件要素に基づいて要素確率に変換する（Ｓ２０２）。センサ値の要素確率への変換は、例えば、要素確率評価部１２ごとに予め実装されている評価関数に基づいて行われる。例えば、時間に対する条件要素であれば、図７に示されるような評価関数によって、要素確率への変換が行われてもよい。
【００４４】
図７は、センサ値から要素確率への第１の変換例を説明するための図である。図７には、条件要素が１０：００〜１１：００である場合の評価関数の一例が示されている。すなわち、図７に示されている曲線は、当該評価関数を示す曲線である。
【００４５】
図７の例では、１０時に近づくにしたがって、要素確率が上昇し、１０：００〜１１：００の期間において、要素確率は１．０となり、１１：００を経過すると、要素確率は下降し始めるような評価関数が示されている。なお、時間の場合、変化の方向は一方向であるため、１１：００の直後が、当該要素条件への適合の度合いが最も低いともいえる。したがって、１１：００の直後において、要素確率が０．０になるような評価関数が用いられてもよい。なお、時間のように、一定かつ一方向に変化する事象については、或る状況に対する適合の度合いは正確に把握可能である。
【００４６】
また、場所、温度、湿度等、変化の速度が比較的ゆっくりである事象についても、図７と同様の考え方で評価関数が生成されてもよい。すなわち、要素条件に指定されている範囲に近付けば近づくほど、要素確率が１．０に近くなるような評価関数によって、センサ値が要素確率に変換されてもよい。
【００４７】
一方、ＮＦＣタグに記憶されている値のように、離散的な値をセンサ値とするセンサに対応する要素確率評価部１２は、例えば、各センサ値間の遷移確率に基づいて、当該センサ値を要素確率に変換してもよい。
【００４８】
図８は、センサ値から要素確率への第２の変換例を説明するための図である。図８において、各円内の値（Ａ、Ｂ、Ｃ）は、例えば、３つのＮＦＣタグのそれぞれに記憶されている値（センサ値）である。図８では、Ａが検知された後にＢが検知される確率が０．８であり、Ａが検知された後にＣが検知される確率が０．２であることが示されている。また、Ｂが検知された後にＣが検知される確率が０．９であり、Ｂが検知された後にＡが検知される確率が０．１であることが示されている。
【００４９】
このような遷移確率は、各ＮＦＣタグが配置されている位置から、他のＮＦＣタグが配置されている位置にユーザが移動する確率であってもよい。すなわち、ＮＦＣタグに関するセンサ値は、当該ＮＦＣタグの配置位置を識別する情報として解釈されてもよい。例えば、Ｃに係るＮＦＣタグがユーザの職場に設置されており、Ｂに係るＮＦＣタグが職場の正門に設置されており、Ａが職場の最寄り駅に設置されているとする。この場合、ユーザが、地点Ａに到達した場合、地点Ｃに向かう可能性が発生する。図８では、当該可能性は、０．２の要素確率として示されている。また、ユーザが、Ｂに到達した場合、地点Ｃに向かう可能性は高くなる。図８では、当該可能性は、０．９の要素確率として示されている。
【００５０】
図８に示されるような評価関数を有し、要素条件としてＣが設定されている要素確率評価部１２は、例えば、センサ値としてＡが取得された場合は、要素確率として、０．２を出力する。
【００５１】
続いて、要素確率評価部１２は、ステップＳ２０２において得られた最新の要素確率が、前回のセンサ値の取得時において得られた要素確率と異なるか否かを判定する（Ｓ２０３）。最新の要素確率が、前回の要素確率と異なる場合（Ｓ２０３でＹｅｓ）、要素確率評価部１２は、最新の要素確率と、当該要素確率に係る条件要素に対応するルールＩＤとをルール確率評価部１３に送信する（Ｓ２０４）。一方、最新の要素確率が、前回の要素確率と同じである場合（Ｓ２０３でＮｏ）、ステップＳ２０４は実行されなくてもよい。
【００５２】
続いて、要素確率評価部１２は、要素確率の評価を終了すべきか否かを判定する（Ｓ２０５）。要素確率評価部１２は、要素確率の評価を継続すべきであると判定した場合（Ｓ２０５でＮｏ）、センサ値の取得を待機して（Ｓ２０６）、ステップＳ２０１以降を繰り返す。センサ値の取得の待機は、例えば、一定時間の待機であってもよいし、ＮＦＣタグが検知されるまでといったように、センサからセンサ値が入力されるまでの待機であってもよい。
【００５３】
一方、要素確率評価部１２は、要素確率の評価を終了すべきであると判定した場合（Ｓ２０５でＹｅｓ）、図６の処理を終了する。例えば、当該要素確率評価部１２に設定されている条件要素が無効となったことがルール確率評価部１３から通知された場合や、ユーザによる操作によって強制的に評価の中止が指示された場合等に、要素確率評価部１２は、要素確率の評価を終了すべきであると判定する。
【００５４】
なお、一つの要素確率評価部１２に対して複数の条件要素が設定された場合、例えば、ステップＳ２０２においては、条件要素ごとに要素確率への変換が実行される。また、ステップＳ２０３の判定は、条件要素別に実行される。
【００５５】
続いて、各要素確率評価部１２から要素確率を受信するルール確率評価部１３が実行する処理手順について説明する。図９は、ルール確率評価部が実行する処理手順の一例を説明するためのフローチャートである。
【００５６】
ルール確率評価部１３は、各要素確率評価部１２からの要素確率の受信を待機している（Ｓ３０１）。いずれかの要素確率評価部１２から送信された要素確率及びルールＩＤが受信されると（Ｓ３０１でＹｅｓ）、ルール確率評価部１３は、当該ルールＩＤに対応付けて当該要素確率を、例えば、メモリ１０２に記憶する（Ｓ３０２）。すなわち、ルールＩＤごとに、当該ルールＩＤに係る各条件要素の要素確率が記憶される。
【００５７】
続いて、ルール確率評価部１３は、ステップＳ３０１において受信された要素確率（以下、「対象要素確率」という。）に係る条件要素が属するルール記述（以下、「対象ルール記述」という。）のルール確率を評価する（Ｓ３０３）。例えば、対象ルール記述を構成する条件要素が１つである場合、対象要素確率がそのままルール確率とされる。一方、対象ルール記述を構成する条件要素が複数である場合、対象要素確率と、当該ルールを構成するその他の条件要素に対する要素確率（以下、「関連要素確率」という。）とが、対象ルール記述の実行条件に当てはめられることにより、ルール確率が算出される。関連要素確率は、ステップＳ３０１において受信されたルールＩＤに対応付けられてメモリ１０２に記憶されているはずである。但し、一度も受信されていない関連要素確率の値は０．０とされる。
【００５８】
図１０は、ルール確率の算出例を示す図である。図１０には、具体的な実行条件ごとに、具体的な要素確率と、ルール確率の算出結果とが示されている。
【００５９】
（１）は、ルール記述が、ＡＮＤ（Ａ，Ｂ，Ｃ）であって、Ａの要素確率が０．９、Ｂの要素確率が０．５、Ｃの要素確率が０．７である場合のルール確率の算出結果を示す。ＡＮＤ演算子は、全ての要素確率の平均であるため、この場合、（０．９＋０．５＋０．７）÷３＝０．７が、ルール確率となる。
【００６０】
（２）は、ルール記述が、ＯＲ（Ａ，Ｂ，Ｃ）であって、Ａの要素確率が０．９、Ｂの要素確率が０．５、Ｃの要素確率が０．７である場合のルール確率の算出結果を示す。ＯＲ演算子は、全ての要素確率の中の最大値であるため、この場合、０．９が、ルール確率となる。
【００６１】
（３）は、ルール記述が、ＮＯＴ（Ａ）であって、Ａの要素確率が０．９である場合のルール確率の算出結果を示す。この場合、１−０．９＝０．１が、ルール確率となる。
【００６２】
（４）は、ルール記述が、ＳＥＱ（Ａ，Ｂ，Ｃ）であって、Ａの要素確率が１．０、Ｂの要素確率が１．０、Ｃの要素確率が０．５である場合のルール確率の算出結果を示す。但し、Ａ、Ｂの順に、要素確率が１．０になったこととする。この場合、（１．０＋１．０＋０．５）÷３＝０．８３が、ルール確率となる。
【００６３】
（５）は、ルール記述が、ＡＮＤ（Ａ，ＯＲ（Ｄ，Ｅ），Ｃ）であって、Ａの要素確率が０．９、Ｃの要素確率が０．７、Ｄの要素確率が０．６、Ｅの要素確率が０．３である場合のルール確率の算出結果を示す。この場合、Ｄ及びＥのうちの最大値は、０．６である。したがって、ＯＲ（Ｄ，Ｅ）の値は、０．６である。よって、この場合、（０．９＋０．６＋０．７）÷３＝０．７３が、ルール確率となる。
【００６４】
続いて、ルール確率評価部１３は、ステップＳ３０３における評価結果（ルール確率）が、対象ルール記述に関する前回の評価結果（ルール確率）と異なるか否かを判定する（Ｓ３０４）。対象ルール記述に関する評価結果が前回と異なる場合、ルール確率評価部１３は、ステップＳ３０３における評価結果であるルール確率と、対象ルール記述のアプリＩＤとをアプリ制御部１４に送信し（Ｓ３０５）、ステップＳ３０１以降を繰り返す。一方、対象ルール記述に関する評価結果が前回と同じである場合（Ｓ３０４でＮｏ）、ステップＳ３０５は実行されずに、ステップＳ３０１以降が繰り返されてもよい。
【００６５】
続いて、ルール確率評価部１３から送信されたルール確率がアプリ制御部１４によって受信されることにより実行される処理手順について説明する。図１１は、アプリ制御部によるルール確率の受信に応じて実行される処理手順の一例を説明するためのフローチャートである。
【００６６】
アプリ制御部１４は、ルール確率評価部１３から送信されたルール確率を受信すると、当該ルール確率が、閾値以上であるか否かを判定する（Ｓ４０１）。閾値は、全ルール記述に対して共通の値であってもよいし、ルール記述ごとに異なる値であってもよい。閾値がルール記述ごとに異なる場合、ルール記述に閾値が含まれてもよい。この場合、図９のステップＳ３０５において、ルール確率及びアプリＩＤと共に、対象ルール記述に含まれている閾値が、アプリ制御部１４に送信されてもよい。
【００６７】
ルール確率が閾値以上である場合（Ｓ４０１でＹｅｓ）、すなわち、ルール確率が、１．０から所定の範囲内である場合、アプリ制御部１４は、ルール確率と共に受信されたアプリＩＤを含む、Ｗｅｂアプリの取得要求を、アプリ取得部１５に送信する。
【００６８】
アプリ取得部１５は、Ｗｅｂアプリの取得要求に応じ、当該取得要求に含まれているアプリＩＤ（以下、「対象アプリＩＤ」という。）に対応するＷｅｂアプリ（以下、「対象アプリ」という。）を、取得済みか否かを判定する（Ｓ４０２）。斯かる判定は、当該アプリＩＤに対応するＷｅｂアプリがアプリ記憶部１２１に記憶されているか否かに基づいて行うことができる。
【００６９】
対象アプリがアプリ記憶部１２１にされていない場合（Ｓ４０２でＮｏ）、アプリ取得部１５は、対象アプリＩＤを含む、Ｗｅｂアプリの配信要求をアプリ管理サーバ２０に送信する（Ｓ４０３）。アプリ管理サーバ２０のアプリ配信部２２は、当該配信要求に含まれているアプリＩＤに対応する対象アプリをアプリ記憶部２４から取得し、対象アプリをアプリ取得部１５に返信する。アプリ取得部１５は、返信された対象アプリを受信し、対象アプリを対象アプリＩＤに対応付けてアプリ記憶部１２１に記憶する（Ｓ４０４）。この際、アプリ取得部１５は、対象アプリを暗号化して、アプリ記憶部１２１に記憶してもよい。なお、対象アプリがアプリ記憶部１２１にされている場合（Ｓ４０２でＹｅｓ）、ステップＳ４０３及びＳ４０４は実行されずに、ステップＳ４０５に進む。
【００７０】
続いて、アプリ制御部１４は、ルール確率が１．０であるか否かを判定する（Ｓ４０５）。ルール確率が１．０未満である場合（Ｓ４０５でＮｏ）、アプリ制御部１４は、対象アプリを利用制限状態にする（Ｓ４０６）。例えば、対象アプリが起動されている場合、アプリ制御部１４は、対象アプリの停止をアプリ実行部１６に要求する。アプリ実行部１６は、当該要求に応じ、対象アプリを強制的に停止させる（対象アプリの利用を不許可にする）。また、アプリ制御部１４は、ホーム画面において、対象アプリのアイコンを非表示とする。
【００７１】
ルール確率が１．０である場合（Ｓ４０５でＹｅｓ）、アプリ制御部１４は、対象アプリの利用制限状態を解除する（Ｓ４０７）。例えば、対象アプリのアイコンがホーム画面に表示される。続いて、対象アプリのアイコンがユーザによって操作されると、アプリ実行部１６は、対象アプリを起動させる（対象アプリの利用を許可する）（Ｓ４０８）。但し、対象アプリの起動は、ステップＳ４０７に続いて自動的に行われてもよい。
【００７２】
一方、ルール確率が閾値未満である場合（Ｓ４０１でＮｏ）、すなわち、ルール確率が１．０から所定の範囲外である場合、アプリ制御部１４は、対象アプリＩＤと共に、ルール確率が閾値以下であることを示す情報をアプリ取得部１５に送信する。アプリ取得部１５は、当該情報を受信すると、対象アプリＩＤに対応するＷｅｂアプリ（すなわち、対象アプリ）が、アプリ記憶部１２１に記憶されているか否かを判定する（Ｓ４０９）。対象アプリがアプリ記憶部１２１に記憶されている場合（Ｓ４０９でＹｅｓ）、アプリ取得部１５は、アプリ記憶部１２１の記憶容量の残量が不足しているか否かを判定する（Ｓ４１０）。例えば、当該残量が所定値以下であるか否かが判定される。当該残量が所定値以下である場合（Ｓ４１０でＹｅｓ）、アプリ取得部１５は、対象アプリをアプリ記憶部１２１から削除する（Ｓ４１１）。対象アプリがアプリ記憶部１２１に記憶されていない場合（Ｓ４０９でＮｏ）、又は記憶容量が不足していない場合（Ｓ４１０でＮｏ）、ステップＳ４１１は実行されない。但し、対象アプリがアプリ記憶部１２１に記憶されていれば、アプリ記憶部１２１の記憶容量の残量に拘わらず、ステップＳ４１１が実行されてもよい。
【００７３】
図１１において説明した処理手順に基づいて実現されるＷｅｂアプリに関する制御の一例について説明する。図１２は、Ｗｅｂアプリに関する制御の一例を説明するための図である。図１２では、説明の便宜上、１０：００〜１１：００を実行条件とするルール記述に基づくＷｅｂアプリの制御例が示されている。また、対象アプリは、配信されていない状態であるとする。
【００７４】
９：３０において、ルール確率が閾値以上になると、図４のステップＳ４０３及びＳ４０４が実行され、対象アプリが取得される。但し、この時点においてルール確率は、１．０未満であるため、対象アプリは利用制限状態とされる。１０：００において、ルール確率が１．０になると、図１１のステップＳ４０７及びＳ４０８が実行され、対象アプリの利用制限状態が解除され、対象アプリが起動される。その後、１１：００までは、ルール確率が１．０であるため、ユーザは、対象アプリを利用することができる。
【００７５】
１１：００を経過して、ルール確率が１．０未満になると、図１１のステップＳ４０６が実行され、対象アプリは利用制限状態となる。ルール確率が更に低下して、閾値未満になると、アプリ記憶部１２１の記憶容量の残量に応じて、図１１のステップＳ４１１が実行される。その結果、対象アプリはアプリ記憶部１２１から削除される。
【００７６】
続いて、具体的なルール記述ごとに、ユーザ端末１０が実行する処理内容について説明する。図１３は、第一のルール記述に関してユーザ端末が実行する処理内容を説明するための図である。
【００７７】
アプリ管理サーバ２０において、１０：００〜１１：００にＷｅｂアプリａ１の実行を許可することを示すルール記述ｒ１が、ルール記憶部２３に登録されると、ルール配信部２１は、ルール記述ｒ１を、各ユーザ端末１０に配信する（Ｓ５０１）。なお、特定のユーザ端末１０に対してのみ有効なルール記述ｒ１が登録されてもよい。この場合、ルール配信部２１は、当該特定のユーザ端末１０に対してルール記述ｒ１を配信すればよい。
【００７８】
ユーザ端末１０のルール受信部１１は、ルール記述ｒ１を受信すると、ルール記述ｒ１をルール確率評価部１３に設定する（Ｓ５０２）。ルール確率評価部１３は、ルール記述ｒ１の条件要素である「１０：００〜１１：００」を、時間センサ１０６ａに対応する要素確率評価部１２ａに設定する（Ｓ５０３ａ）。なお、時間センサ１０６ａは、センサ群１０６を構成する一つのセンサである。例えば、時間センサ１０６ａは、時計でもよい。「１０：００〜１１：００」が条件要素として設定された要素確率評価部１２ａは、例えば、１０：００に近付くほど要素確率が高くなる評価関数に基づいて、定期的に要素確率を評価し、評価結果をルール確率評価部１３に通知する（Ｓ５０４ａ）。ルール確率評価部１３は、当該要素確率をルール確率として、アプリ制御部１４に通知する（Ｓ５０５）。アプリ制御部１４は、ルール確率評価部１３から定期的に通知されるルール確率が閾値以上になると、ルール記述ｒ１に含まれているアプリＩＤに係るＷｅｂアプリの取得をアプリ取得部１５に要求する（Ｓ５０６）。アプリ取得部１５は、当該要求に応じ、当該アプリＩＤに係るＷｅｂアプリａ１を、アプリ管理サーバ２０のアプリ配信部２２から取得し（Ｓ５０７）、取得されたＷｅｂアプリａ１をアプリ記憶部１２１に記憶する。この時点において、Ｗｅｂアプリａ１は、利用制限状態とされる。
【００７９】
その後、時刻が１０：００になり、ルール確率が１．０になると、アプリ制御部１４は、Ｗｅｂアプリａ１の利用制限状態を解除し、アプリ実行部１６に対してＷｅｂアプリａ１の起動を要求する（Ｓ５０８）。アプリ実行部１６は、当該要求に応じ、Ｗｅｂアプリａ１をアプリ記憶部１２１から読み込んで起動する（Ｓ５０９）。
【００８０】
時刻が１１：００を経過し、ルール確率が１．０未満になると、アプリ制御部１４は、Ｗｅｂアプリａ１の停止をアプリ実行部１６に要求する（Ｓ５１０）。アプリ実行部１６は、当該要求に応じ、Ｗｅｂアプリａ１を強制的に停止させる。この際、Ｗｅｂアプリａ１は、利用制限状態とされる。また、ルール確率が閾値未満になると、アプリ制御部１４は、必要に応じて、Ｗｅｂアプリａ１の削除をアプリ取得部１５に要求する（Ｓ５１１）。アプリ取得部１５は、Ｗｅｂアプリａ１を、アプリ記憶部１２１から削除する（Ｓ５１２）。
【００８１】
図１４は、第二のルール記述に関してユーザ端末が実行する処理内容を説明するための図である。図１４中、図１３と同一部分又は同一ステップには同一符号を付し、その説明は適宜省略する。
【００８２】
図１４では、１０：００〜１１：００において渋谷駅でＷｅｂアプリａ２の実行を許可することを示すルール記述ｒ２が、ルール記憶部２３に登録された例が示されている。
【００８３】
この場合、ルール確率評価部１３は、ルール記述ｒ２の第１の条件要素である「１０：００〜１１：００」を、要素確率評価部１２ａに設定する（Ｓ５０３ａ）。また、ルール確率評価部１３は、ルール記述ｒ２の第２の条件要素である「渋谷駅」を、ＧＰＳセンサ１０６ｂに対応する要素確率評価部１２ｂに設定する（Ｓ５０３ｂ）。なお、ＧＰＳセンサ１０６ｂは、センサ群１０６を構成する一つのセンサであり、ＧＰＳによって計測される緯度及び経度を出力する。
【００８４】
要素確率評価部１２ａは、図１３と同様に、要素確率をルール確率評価部１３に通知する（Ｓ５０４ａ）。要素確率評価部１２ｂは、例えば、「渋谷駅」を、緯度及び経度に基づく範囲情報に変換し、ＧＰＳセンサ１０６ｂによって検知される緯度及び経度が、当該範囲情報の示す範囲に近付けば近付くほど要素確率が高くなる評価関数に基づいて、要素確率を評価し、評価結果をルール確率評価部１３に通知する（Ｓ５０４ｂ）。なお、要素確率評価部１２ａが要素確率を通知するタイミングと、要素確率評価部１２ｂが要素確率を通知するタイミングとは、相互に異なっていてもよい。
【００８５】
ルール確率評価部１３は、いずれかの要素確率評価部１２から要素確率が通知されるたびに、２つの要素確率と、論理演算子ＡＮＤとに基づいて、ルール確率を評価する。本実施の形態において論理演算子ＡＮＤは、全要素確率の平均を示す。したがって、ルール確率は、２つの要素確率の平均値をルール確率とし、当該ルール確率をアプリ制御部１４に通知する（Ｓ５０５）。
【００８６】
その他の事項については、図１３と同様でよい。
【００８７】
図１５は、第三のルール記述に関してユーザ端末が実行する処理内容を説明するための図である。図１５中、図１３と同一部分又は同一ステップには同一符号を付し、その説明は適宜省略する。
【００８８】
図１５では、ＮＦＣタグの値として「Ｃ」が検知されたら、Ｗｅｂアプリａ３の実行を許可することを示すルール記述ｒ３が、ルール記憶部２３に登録された例が示されている。
【００８９】
この場合、ルール確率評価部１３は、ルール記述ｒ３の条件要素である「ＮＦＣ＝Ｃ」を、ＮＦＣセンサ１０６ｃに対応する要素確率評価部１２ｃに設定する（Ｓ５０３ｃ）。ＮＦＣセンサ１０６ｃは、センサ群１０６を構成する一つのセンサであり、ＮＦＣタグから読み取られた値を出力する。
【００９０】
要素確率評価部１２ｃは、図８に示した遷移モデルに基づいて、要素確率を評価し、評価結果をルール確率評価部１３に通知する（Ｓ５０４ｃ）。ルール確率評価部１３は、当該要素確率をルール確率としてアプリ制御部１４に通知する（Ｓ５０５）。
【００９１】
その他の事項は、図１３と同様でよい。
【００９２】
上述したように、本実施の形態によれば、Ｗｅｂアプリの実行条件が充足される前に、当該Ｗｅｂアプリがユーザ端末に配信される。したがって、当該実行条件の充足時には、ユーザは、直ちに当該Ｗｅｂアプリを利用することが可能となる。したがって、所定の状況下で利用が許可されるＷｅｂアプリの利用を円滑化することができる。
【００９３】
また、実行条件の充足前に配信されたＷｅｂアプリは、実行条件が充足するまで利用制限状態とされる。したがって、コンテキストに応じてＷｅｂアプリの利用を許可するといった仕組みが、Ｗｅｂアプリの事前配信によって没却されてしまうのを回避することができる。
【００９４】
また、Ｗｅｂアプリの事前配信のタイミングは、実行条件に基づいて判定される。したがって、管理者等が、実行条件とは別に配信条件等を設定する必要性を低減することができ、管理者等の作業負担の増加を抑制することができる。
【００９５】
更に、実行条件に基づいて判定される、Ｗｅｂアプリの事前配信のタイミングは、ユーザ端末１０ごとに異なる。すなわち、ルール確率が閾値以上となるタイミングは、ユーザ端末１０ごとに異なる。したがって、多数のユーザ端末１０が、一斉にＷｅｂアプリの配信を要求することによる、アプリ管理サーバ２０の負荷の急激な増加を抑制することができる。
【００９６】
なお、本実施の形態において、Ｗｅｂアプリは、所定のプログラムの一例である。すなわち、本実施の形態は、Ｗｅｂアプリ以外のプログラムに関して適用されてもよい。また、ユーザ端末１０は、情報処理端末の一例である。ルール確率評価部１３は、算出部の一例である。アプリ取得部１５は、取得部の一例である。アプリ制御部１４は、制限部の一例である。
【００９７】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００９８】
１０          ユーザ端末
１１          ルール受信部
１２          要素確率評価部
１３          ルール確率評価部
１４          アプリ制御部
１５          アプリ取得部
１６          アプリ実行部
２０          アプリ管理サーバ
２１          ルール配信部
２２          アプリ配信部
２３          ルール記憶部
２４          アプリ記憶部
１０１        ＣＰＵ
１０２        メモリ
１０３        補助記憶装置
１０４        タッチパネル
１０５        無線通信装置
１０６        センサ群
１０６ａ      時間センサ
１０６ｂ      ＧＰＳセンサ
１０６ｃ      ＮＦＣセンサ
１１１        表示装置
１１２        入力装置
１２１        アプリ記憶部
【図１】
0006572967.tif 000002
【図２】
0006572967.tif 000003
【図３】
0006572967.tif 000004
【図４】
0006572967.tif 000005
【図５】
0006572967.tif 000006
【図６】
0006572967.tif 000007
【図７】
0006572967.tif 000008
【図８】
0006572967.tif 000009
【図９】
0006572967.tif 000010
【図１０】
0006572967.tif 000011
【図１１】
0006572967.tif 000012
【図１２】
0006572967.tif 000013
【図１３】
0006572967.tif 000014
【図１４】
0006572967.tif 000015
【図１５】
0006572967.tif 000016