JP2014112321A - 情報処理装置、通信端末、アプリケーション提供方法、アプリケーション実行方法、アプリケーション提供プログラム、及びアプリケーション実行プログラム - Google Patents

Abstract

【課題】状況に合わせた適切なアプリケーションを使用できる。
【解決手段】通信端末でアプリケーションを使用する時のユーザの状況を予測する使用時状況予測手段と、前記使用時状況予測手段により予測される使用時状況と、前記通信端末から得られる前記ユーザの現在状況とに基づいて、前記アプリケーションの内容を調整する内容調整手段と、前記内容調整手段により得られる調整済みアプリケーションを前記通信端末に配信するアプリ配信手段とを有する。
【選択図】図２

Description

本発明は、情報処理装置、通信端末、アプリケーション提供方法、アプリケーション実行方法、アプリケーション提供プログラム、及びアプリケーション実行プログラムに関する。

スマートフォンやタブレット端末等の通信端末上で実行させるアプリケーション（以下、「アプリ」という）を、所定のタイミングでサーバから配信して実行させるコンピューティングシステムが提案されてきている。例えば、ユーザの状況（位置等）に合わせてアプリの快適な使い方を実現するヒューマンセントリックコンピューティング（以下、「ＨＣＣ」という）システム等が提案されている。ＨＣＣシステムは、予め設定したユーザ状況（位置）になった時点で、用意しておいたアプリを通信端末にプッシュ配信するシステムである。

しかしながら、従来のＨＣＣシステムは、プッシュ時のユーザ状況に合わせて、開発済みの端末アプリをプッシュするだけであるため、アプリ開発者が細かい状況の違い毎に別アプリを用意する必要がある。そこで、ユーザ状況（端末位置、行動予定）に合わせて表示内容やアクセス可否を調整する従来技術として、プッシュ時や使用時、状況変化時に調整する手法が存在する（例えば、特許文献１〜３参照）。

また、アプリを通信端末にプッシュした後、使用されずにそのまま放置されてしまうという問題もあった。そこで、プッシュ後のアプリの操作状況（未操作期間）に合わせて、アプリ内容を調整する手法が存在する（例えば、特許文献４参照）。

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

しかしながら、上述の従来技術では、アプリ使用開始時に、その時点のユーザ状況やアプリ操作状況に合わせて動作調整済のアプリをすぐに使える状態にしておくことができない。

１つの側面では、本発明は、状況に合わせた適切なアプリケーションを使用できる状態にすることを目的とする。

開示の一態様における情報処理装置は、通信端末でアプリケーションを使用する時のユーザの状況を予測する使用時状況予測手段と、前記使用時状況予測手段により予測される使用時状況と、前記通信端末から得られる前記ユーザの現在状況とに基づいて、前記アプリケーションの内容を調整する内容調整手段と、前記内容調整手段により得られる調整済みアプリケーションを前記通信端末に配信するアプリ配信手段とを有する。

状況に合わせた適切なアプリケーションを使用できる。

アプリケーション提供システムにおける概略構成例を示す図である。 アプリケーション提供サーバにおける機能構成の一例を示す図である。 アプリケーション提供サーバにおけるハードウェア構成の一例を示す図である。 通信端末における機能構成の一例を示す図である。 通信端末におけるハードウェア構成の一例を示す図である。 アプリケーション提供サーバに記憶されるデータ例を示す図（その１）である。 アプリケーション提供サーバに記憶されるデータ例を示す図（その２）である。 通信端末に記憶されるデータ例を示す図である。 初回の端末アプリの生成処理の一例を示すフローチャートである。 ユーザ状況変化時の再調整処理の一例を示すフローチャートである。 予測使用時状況の予測処理の一例を示すフローチャートである。 アプリ使用時状況相関ＤＢの更新処理の一例を示すフローチャートである。 内容調整処理の一例を示すフローチャートである。 再調整要否判定処理の一例を示すフローチャート（その１）である。 再調整要否判定処理の一例を示すフローチャート（その２）である。 ユーザ状況ＤＢの更新処理の一例を示すフローチャート（その１）である。 ユーザ状況ＤＢの更新処理の一例を示すフローチャート（その２）である。 アプリ操作状況更新処理の一例を示すフローチャートである。 調整処理スクリプトの一例を示す図である。

以下、添付図面を参照しながら実施例について詳細に説明する。

＜アプリケーション提供システムの概略構成例＞
図１は、アプリケーション提供システムにおける概略構成例を示す図である。図１に示すアプリケーション提供システム１０は、情報処理装置の一例としてのアプリケーション提供サーバ１１と、通信端末１２−１〜１２−ｎ（以下、必要に応じて「通信端末１２」と総称する）とを有する。また、アプリケーション提供サーバ１１と、通信端末１２とは、通信ネットワーク１３により各種情報の送受信が可能な状態で接続されている。

アプリケーション提供サーバ１１は、通信端末１２を使用するユーザ毎の行動履歴や操作履歴、現在状況、今後のスケジュール等を管理し、所定の時間に所定のアプリ（端末アプリ）を提供するようにスケジュールを管理する。また、アプリケーション提供サーバ１１は、各通信端末１２に、その状況に適切なアプリを、通信ネットワーク１３を介して各通信端末１２に送信する。なお、アプリとは、例えば所定の案件毎の承認や、アンケート、出張精算等の小さな単位のアプリ（マイクロアプリ）等であるが、これに限定されるものではなく、例えばメールソフトやワープロソフト、表計算ソフト等のソフトウェア等も含む。また、アプリは、例えばＨｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＨＴＭＬ）５ファイルや、ＪａｖａＳｃｒｉｐｔ（登録商標）ファイル等で構成されるが、これに限定されるものではない。

また、アプリケーション提供サーバ１１は、通信端末１２を利用するユーザに対して、予め予測される将来のユーザ状況に基づいてアプリを生成して、通信端末１２に配信する。また、アプリケーション提供サーバ１１は、アプリ送付後のユーザ状況を監視し、監視結果等に応じてアプリを再生成したり、再配信する等の再調整を行う。なお、アプリの再調整については、例えば前回生成したアプリに対する差分データのみを生成して配信してもよい。また、アプリの再調整については、例えば端末アプリを配信後に、必須な部分のアプリと付加的な部分のアプリとに分割し、それぞれに対して必要に応じたアプリの再生成が行えるようにしてもよい。

アプリケーション提供サーバ１１は、汎用型のＰｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ（ＰＣ）やサーバ等でもよく、またクラウドシステム等であってもよい。また、アプリケーション提供サーバ１１は、例えば通信端末１２を使用するユーザのスケジュール等を管理するスケジュール管理サーバや、配信ルールの実行を行う配信ルール実行サーバ等を別体の構成にて管理してもよい。

通信端末１２は、例えば各ユーザが使用する移動端末である。例えば、通信端末１２は、予めインストールされた各種アプリや、アプリケーション提供サーバ１１から通信ネットワーク１３を介して配信されたアプリを実行する。通信端末１２に対する位置情報や操作履歴、アプリの実行結果等は、例えば定期的又は所定の操作や実行を開始した等の所定のタイミングで通信ネットワーク１３を介してアプリケーション提供サーバ１１に送信される。

通信端末１２は、スマートフォンやタブレット端末、携帯電話等の無線通信端末でもよく、ノート型ＰＣやゲーム機器、音楽再生装置等であってもよい。

通信ネットワーク１３は、例えばインターネットやＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）等である。通信ネットワーク１３は、例えば有線でも無線でもよく、これらの組み合わせであってもよい。

次に、上述したアプリケーション提供システム１０におけるアプリケーション提供サーバ１１と通信端末１２との各構成等について具体的に説明する。

＜アプリケーション提供サーバ１１の機能構成例＞
図２は、アプリケーション提供サーバにおける機能構成の一例を示す図である。図２に示すアプリケーション提供サーバ１１は、入力手段２１と、出力手段２２と、記憶手段２３と、スケジュール管理手段２４と、配信ルール実行手段２５と、アプリ生成手段２６と、アプリ配信手段２７と、再調整受付手段２８と、使用状況更新手段２９と、送受信手段３０と、制御手段３１とを有する。

入力手段２１は、アプリケーション提供サーバ１１を使用する管理者等からの各種指示の開始や終了、設定の入力等の各種入力を受け付ける。具体的には、入力手段２１は、例えばスケジュール管理指示や配信ルール実行指示等の各指示を受け付ける。

入力手段２１により取得される情報の入力は、例えばキーボードやマウス等の入力インターフェース等による入力でもよく、また画面を用いたタッチパネル形式の入力等でもよい。更に、入力手段２１は、例えばマイクロフォン等により音声を入力する音声入力手段を有していてもよい。

出力手段２２は、入力手段２１により入力された内容や、入力内容に基づいて実行された内容等の出力を行う。なお、出力手段２２は、例えば画面表示により出力する場合には、ディスプレイやモニタ等の表示手段を有し、音声により出力する場合には、例えばスピーカ等の音声出力手段を有していてもよい。また、入力手段２１と出力手段２２とは、例えばタッチパネル等のように入出力が一体型であってもよい。

記憶手段２３は、本実施形態において必要となる各種情報を記憶する。具体的には、記憶手段２３は、例えば端末アプリに対するテンプレートや状況・調整対応データベース（以下、データベースを「ＤＢ」という）、ユーザ状況ＤＢ、入力途中データ、プッシュ済アプリＤＢ、使用履歴、アプリ操作状況ＤＢ等を記憶する。また、記憶手段２３は、アプリ使用時状況相関ＤＢ、想定状況ＤＢ等の各種情報を記憶するが、これに限定されるものではない。

また、記憶手段２３は、本実施形態におけるアプリケーション提供処理が実現可能な各処理を実行するための設定情報等を記憶したり、各種処理の実行経過や結果等を記憶する。また、記憶手段２３は、記憶された各種情報を必要に応じて所定のタイミングで読み出したり、書き込んだりすることができる。また、記憶手段２３は、上述したような多種の情報の集合物であり、それらの情報を、例えばキーワード等を用いて検索し、抽出することができるように体系的に構成されているデータベースとしての機能を有していてもよい。なお、記憶手段２３は、例えばハードディスクやメモリ等からなる。

スケジュール管理手段２４は、通信端末１２を利用する各ユーザに対して予め設定されているスケジュール内容をユーザ毎に管理する。スケジュール内容とは、例えば過去のスケジュールや未来のスケジュール等であるが、これに限定されるものではない。

また、スケジュール管理手段２４は、定期的又は所定の距離以上移動した等の所定のタイミングで通信端末１２の位置情報を取得し、その位置情報から行動履歴や現在状況を管理する。また、スケジュール管理手段２４は、ユーザの通信端末１２に対する操作履歴等を管理する。更に、スケジュール管理手段２４は、通信端末１２に送信する端末アプリ、その他のデータを送信するタイミングをスケジューリングすることもできる。なお、スケジュール管理手段２４における各機能は、例えばスケジュール管理サーバとしてアプリケーション提供サーバ１１とは別体で設けられていてもよい。

配信ルール実行手段２５は、端末アプリを生成するための条件を満たすか否かを判断するため、所定の配信ルールを実行させる。また、配信ルール実行手段２５は、条件を満たす場合に、アプリ生成手段２６により所定の端末アプリを生成させる。

配信ルール実行手段２５は、通信端末１２から定期的又は状況変化時に送信される各ユーザの操作履歴、通信端末１２の位置情報等に基づいて、実行している配信ルール内に記述されている条件を満たすか否かを判断する。

アプリ生成手段２６は、配信ルール実行手段２５からのアプリ生成指示等に基づいて、指示内容に対応する端末アプリを生成する。なお、アプリ生成手段２６は、例えば過去のアプリ操作履歴や今後のユーザの行動予定等のスケジュール内容に基づいて端末アプリの内容を決定し、決定した内容に基づいて端末アプリを生成する。

アプリ生成手段２６は、予め記憶手段２３に記憶された端末アプリテンプレートに基づいて、端末アプリを生成する。なお、アプリ生成手段２６は、使用時状況予測手段４１−１と、内容調整手段４１−２とを有する。

使用時状況予測手段４１−１は、ユーザ毎に通信端末１２で使用されるアプリ使用時の状況を予測する。この場合、使用時状況予測手段４１−１は、通信端末１２の現在位置や操作内容等から使用時の状況を予測してもよく、更に上述したスケジュール管理手段２４により得られるスケジュール内容や行動履歴等に基づいてアプリ使用時の状況を予測してもよい。使用時状況予測手段４１−１は、例えばアプリ種別毎の過去に使用されたユーザ状況の頻度から得られるユーザ状況毎の相関度に基づいて、アプリを使用するユーザの使用時状況を予測してもよい。

また、内容調整手段４１−２は、使用時状況予測手段４１−１により予測されたアプリ使用時の状況と、現在状況と、記憶手段２３に記憶された状況・調整対応ＤＢと、入力途中データとに基づいて、端末アプリの調整を行う。内容調整手段４１−２は、例えば通信端末１２の現在状況に応じて、端末アプリにより通信端末１２の画面に表示される内容を変更する。これにより、例えば、ユーザが社外で使用すると予測する端末アプリについては、通信端末１２の画面に表示される内容に社外秘情報を含まないように調整することができる。また、内容調整手段４１−２は、ユーザの現在状況が社外であれば社外秘情報を含まず、また現在状況が社内であれば社外秘情報も画面に表示させるように調整することができる。また、内容調整手段４１−２は、調整に使用した予測使用時状況と、現在状況とを、想定状況ＤＢに記憶する。

アプリ配信手段２７は、端末アプリ（調整済端末アプリ）、想定状況等の各種データを対象の通信端末１２に配信（プッシュ）する。また、アプリ配信手段２７は、通信端末１２毎に配信したデータを管理するため、配信後にプッシュ済アプリＤＢを更新する。なお、アプリ配信手段２７は、上述したスケジュール管理手段２４により得られるスケジュール内容に基づいて、ユーザが使用する時点での状況を予測し、予測した状況に合わせて事前に又は適切なタイミングで所定の端末アプリの配信を行うことができる。例えば、ユーザが社外にいて、社内に戻ってから使用すると予測される社外秘情報を含む端末アプリを配信する場合には、ユーザが社内に戻ってから配信するようにすることができる。

再調整受付手段２８は、通信端末１２から得られる再調整要求データを受信し、受信した再調整要求データを記憶手段２３に記憶する。なお、再調整要求データは、再調整の対象となる端末アプリのリスト（再調整対象アプリリスト）等であるが、これに限定されるものではない。

再調整受付手段２８は、再調整対象アプリリスト内の各端末アプリに対して、配信する端末アプリの再調整を行う。具体的には、再調整受付手段２８は、再調整対象アプリリスト内の各アプリに対して、端末アプリの再生成を行い、再生成された端末アプリを、再調整要求データを送信した通信端末１２に再配信する。なお、端末アプリの再生成は、アプリ生成手段２６により実行され、端末アプリの再配信は、アプリ配信手段２７により配信される。再調整受付手段２８は、そのための要求を上述した各手段等に対して行う。

使用状況更新手段２９は、通信端末１２から得られる端末アプリの使用状況に基づいて、記憶手段２３に記憶された使用状況の相関ＤＢの更新を行う。本実施形態では、ユーザ毎の端末アプリの使用状況に応じて、上述した端末アプリの再調整を行うことができる。

送受信手段３０は、例えば通信ネットワーク１３を介して通信端末１２等の外部装置と各種情報の送受信を行うための通信手段である。送受信手段３０は、外部装置等にすでに記憶されている各種情報等を受信することができ、またアプリケーション提供サーバ１１で処理された結果を、通信ネットワーク１３を介して外部装置等に送信することもできる。

制御手段３１は、アプリケーション提供サーバ１１の各構成部全体の制御を行う。具体的には、制御手段３１は、例えばユーザ等による入力手段２１からの指示等に基づいて、アプリケーション提供に関する各制御を行う。ここで、各制御とは、例えば上述したスケジュール管理手段２４における各ユーザのスケジュール管理や、配信ルール実行手段２５による配信ルールの実行、アプリ生成手段２６による端末アプリの生成、アプリ配信手段２７による端末アプリの配信等がある。また、各制御とは、再調整受付手段２８によるアプリの再調整の受付や、使用状況更新手段２９による通信端末１２での端末アプリの使用状況の相関の更新等がある。なお、各制御の種類については、これに限定されるものではない。これらの制御は、プログラムの実行やユーザの指示等による所定の操作入力に基づいて行われてもよく、所定の時間間隔で定期的に行われてもよい。

＜アプリケーション提供サーバ１１のハードウェア構成例＞
ここで、上述したアプリケーション提供サーバ１１においては、各機能をコンピュータに実行させることができる実行プログラム（アプリケーション提供プログラム）を生成し、例えば汎用のＰＣやサーバ等にその実行プログラムをインストールすることにより、本実施形態におけるアプリケーション提供処理を実現することができる。ここで、本実施形態におけるアプリケーション提供処理が実現可能なコンピュータのハードウェア構成例について図を用いて説明する。

図３は、アプリケーション提供サーバにおけるハードウェア構成の一例を示す図である。図３におけるコンピュータ本体には、入力装置５１と、出力装置５２と、ドライブ装置５３と、補助記憶装置５４と、主記憶装置５５と、各種制御を行うＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）５６と、ネットワーク接続装置５７とを有するよう構成されており、これらはシステムバスＢで相互に接続されている。

入力装置５１は、ユーザ等が操作するキーボード及びマウス等のポインティングデバイスや、マイクロフォン等の音声入力デバイスを有しており、ユーザ等からのプログラムの実行指示、各種操作情報、ソフトウェア等を起動するための情報等を入力する。

出力装置５２は、本実施形態における処理を行うためのコンピュータ本体を操作するのに必要な各種ウィンドウやデータ等を表示するディスプレイを有し、ＣＰＵ５６が有する制御プログラムによりプログラムの実行経過や結果等を表示することができる。また、出力装置５２は、上述の処理結果等を紙等の印刷媒体に印刷して、ユーザ等に提示することができる。

ここで、本実施形態においてコンピュータ本体にインストールされる実行プログラムは、例えば、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）メモリやＣＤ−ＲＯＭ、ＤＶＤ等の可搬型の記録媒体５８等により提供される。プログラムを記録した記録媒体５８は、ドライブ装置５３にセット可能であり、ＣＰＵ５６からの制御信号に基づき、記録媒体５８に含まれる実行プログラムが、記録媒体５８からドライブ装置５３を介して補助記憶装置５４にインストールされる。

補助記憶装置５４は、例えばハードディスクドライブやＳｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）等のストレージ手段等である。補助記憶装置５４は、ＣＰＵ５６からの制御信号に基づき、本実施形態における実行プログラムや、コンピュータに設けられた制御プログラム等を記憶し、必要に応じて入出力を行うことができる。補助記憶装置５４は、ＣＰＵ５６からの制御信号等に基づいて、記憶された各情報から必要な情報を読み出したり、書き込むことができる。

主記憶装置５５は、ＣＰＵ５６により補助記憶装置５４から読み出された実行プログラム等を格納する。なお、主記憶装置５５は、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）やＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）等からなる。なお、補助記憶装置５４及び主記憶装置５５は、例えば上述した記憶手段２３に対応している。

ＣＰＵ５６は、オペレーティングシステム等の制御プログラム、及び主記憶装置５５に格納されている実行プログラムに基づいて、各種演算や各ハードウェア構成部とのデータの入出力等、コンピュータ全体の処理を制御して各処理を実現することができる。なお、プログラムの実行中に必要な各種情報等は、補助記憶装置５４から取得することができ、また実行結果等を格納することもできる。

具体的には、ＣＰＵ５６は、例えば入力装置５１から得られるプログラムの実行指示等に基づき、補助記憶装置５４にインストールされたアプリケーション提供プログラムを実行させることにより、主記憶装置５５上でプログラムに対応する処理を行う。例えば、ＣＰＵ５６は、アプリケーション提供プログラムを実行させることで、上述したスケジュール管理手段２４によるスケジュールの管理や、配信ルール実行手段２５による配信ルールの実行、アプリ生成手段２６による端末アプリの生成等の制御を行う。また、ＣＰＵ５６は、アプリ配信手段２７による端末アプリの配信や、再調整受付手段２８によるアプリの再調整の受付、使用状況更新手段２９による通信端末１２での端末アプリの使用状況の相関情報の更新等の処理を行う。なお、ＣＰＵ５６における処理内容は、これに限定されるものではない。ＣＰＵ５６により実行された内容は、必要に応じて補助記憶装置５４に記憶させることができる。

ネットワーク接続装置５７は、ＣＰＵ５６からの制御信号に基づき、通信ネットワーク１３等と接続することにより、実行プログラムやソフトウェア、設定情報等を、通信ネットワーク１３に接続されている外部装置等から取得する。また、ネットワーク接続装置５７は、プログラムを実行することで得られた実行結果又は本実施形態における実行プログラム自体を外部装置等に提供することができる。

上述したようなハードウェア構成により、本実施形態におけるアプリケーション提供処理を実行することができる。また、プログラムをインストールすることにより、汎用のＰＣやサーバ等で本実施形態におけるアプリケーション提供処理を容易に実現することができる。

＜通信端末１２の機能構成例＞
図４は、通信端末における機能構成の一例を示す図である。図４に示す通信端末１２は、入力手段６１と、出力手段６２と、記憶手段６３と、センシング手段６４、ユーザ状況把握手段６５と、アプリ実行手段６６と、アプリ操作状況把握手段６７と、再調整要否判定手段６８と、再調整要求手段６９と、送受信手段７０と、制御手段７１とを有する。

入力手段６１は、通信端末１２を使用するユーザ等からの各種指示の開始や終了、設定の入力等の各種入力を受け付ける。具体的には、入力手段６１は、例えば本実施形態におけるアプリ実行指示等の各指示を受け付ける。

入力手段６１により取得される情報の入力は、例えば所定のボタン群（キー）等の入力インターフェース等による入力でもよく、また画面を用いたタッチパネル形式の入力等でもよい。更に、入力手段６１は、例えばマイクロフォン等により音声を入力する音声入力手段を有していてもよい。

出力手段６２は、入力手段６１により入力された内容や、入力内容に基づいて実行された内容等の出力を行う。なお、出力手段６２は、例えば画面表示により出力する場合には、ディスプレイやモニタ等の表示手段を有し、音声により出力する場合には、例えばスピーカ等の音声出力手段を有していてもよい。また、入力手段６１と出力手段６２とは、例えばタッチパネル等のように入出力が一体型であってもよい。

記憶手段６３は、本実施形態において必要となる各種情報を記憶する。具体的には、記憶手段６３は、例えばユーザ状況ＤＢ、入力途中データ、使用履歴、アプリ操作状況ＤＢ、想定状況ＤＢ等の各種情報を記憶するが、これに限定されるものではない。また、記憶手段６３は、本実施形態におけるアプリケーション実行処理が実現可能な各処理を実行するための設定情報等を記憶したり、各種処理の実行経過や結果等を記憶する。また、記憶手段６３は、記憶された各種情報を必要に応じて所定のタイミングで読み出したり、書き込んだりすることができる。また、記憶手段６３は、上述したような多種の情報の集合物であり、それらの情報を、例えばキーワード等を用いて検索し、抽出することができるように体系的に構成されているデータベースとしての機能を有していてもよい。なお、記憶手段６３は、例えばハードディスクやメモリ等からなる。

センシング手段６４は、例えば通信端末１２の位置情報（現在位置）や向き、移動方向、移動速度等を取得する位置情報取得手段である。この場合、センシング手段６４は、例えば位置情報を取得するためのＧＰＳ機能を有し、ＧＰＳ機能による測位を行うことで、例えば緯度経度からなる位置情報や所定の座標系に置き換えた位置情報を取得する。また、センシング手段６４は、ＷｉＦｉ（登録商標）やＢｌｕｅｔｏｏｔｈ（登録商標）等の近距離通信機能を有する場合には、例えば近距離通信により通信可能な他の端末（中継装置や無線基地局等）の位置情報を通信端末１２の位置情報として取得してもよい。

また、センシング手段６４は、例えば加速度センサや角度センサ等を有し、通信端末１２の向きや移動方向、移動速度等について取得することができるが、これに限定されるものではない。

ユーザ状況把握手段６５は、例えば定期的又は所定のタイミングでユーザ状況の更新処理を実行し、ユーザの状況が変化した場合には、再調整要否判定手段６８に変化したユーザ状況を出力して再調整の要否判定を行わせる。

アプリ実行手段６６は、アプリケーション提供サーバ１１から得られる使用可能な状態となっている端末アプリを所定のタイミングで起動して実行可能な状態にする。なお、端末アプリは、予めアプリケーション提供サーバ１１により、ユーザが使用する時点での状況を予測してそれに合わせて配信されている。端末アプリの実行により得られる情報は、使用履歴として記憶手段６３に記憶され、所定のタイミングでアプリケーション提供サーバ１１に送信される。

また、アプリ実行手段６６は、起動時に後述するアプリＤＢ等からアプリリストを取得して画面に表示し、表示されているアプリのうち、ユーザが選択したアプリを起動することもできる。また、アプリ実行手段６６は、ユーザ状況を取得し、取得したユーザ状況に対応させて使用履歴を更新することができる。

アプリ操作状況把握手段６７は、ユーザが使用（実行）したアプリ操作の状況を把握する。把握した状況の内容は、記憶手段６３に記憶されてもよく、通信ネットワーク１３を介してアプリケーション提供サーバ１１に送信してもよい。

再調整要否判定手段６８は、所定の条件による端末アプリの再調整の要否を判定し、判定結果に基づいて再調整が必要な端末アプリを含むアプリリストを生成し、生成した再調整の必要なアプリリストを再調整要求手段６９に出力する。

再調整要求手段６９は、再調整要否判定手段６８により得られるアプリリストの各アプリに関して、再調整要求データを生成する。生成した再調整要求データは、送受信手段７０により、通信ネットワーク１３を介してアプリケーション提供サーバ１１に送信される。

送受信手段７０は、例えば通信ネットワーク１３を介してアプリケーション提供サーバ１１等の外部装置と各種情報の送受信を行うための通信手段である。送受信手段７０は、外部装置等にすでに記憶されている各種情報等を受信することができ、また通信端末１２で処理された結果を、通信ネットワーク１３を介して外部装置等に送信することもできる。

具体的には、送受信手段７０は、アプリケーション提供サーバ１１から得られる端末アプリ（調整済アプリ等も含む）や想定状況等の各種データを受信し、それぞれのデータを例えばアプリＤＢや想定状況ＤＢ等の記憶手段６３等に記憶する。

制御手段７１は、通信端末１２の各構成部全体の制御を行う。具体的には、制御手段７１は、例えばユーザ等による入力手段６１からの指示等に基づいて、アプリケーション提供に関する各制御を行う。ここで、各制御とは、例えば上述したセンシング手段６４による通信端末１２の位置情報等の取得や、ユーザ状況把握手段６５によるユーザ状況の把握、アプリ実行手段６６によるアプリ実行、アプリ操作状況把握手段６７によるアプリ操作状況の把握、再調整要否判定手段６８による再調整要否判定、再調整要求手段６９による再調整要求等がある。なお、各制御の種類については、これに限定されるものではない。なお、これらの制御は、プログラムの実行やユーザの指示等による所定の操作入力に基づいて行われてもよく、所定の時間間隔で定期的に行われてもよい。

＜通信端末１２のハードウェア構成例＞
ここで、上述した通信端末１２においては、各機能をコンピュータに実行させることができる実行プログラム（アプリケーション実行プログラム）を生成し、例えばスマートフォンやタブレット端末等にその実行プログラムをインストールすることにより、本実施形態におけるアプリケーション実行処理を実現することができる。ここで、本実施形態におけるアプリケーション実行処理が実現可能なコンピュータのハードウェア構成例について図を用いて説明する。

図５は、通信端末におけるハードウェア構成の一例を示す図である。図５におけるコンピュータ本体には、入力装置８１と、出力装置８２と、ドライブ装置８３と、補助記憶装置８４と、主記憶装置８５と、ＣＰＵ８６と、ネットワーク接続装置８７と、測位装置８８と、加速度センサ８９と、角速度センサ９０とを有し、これらはシステムバスＢで相互に接続されている。

入力装置８１は、例えば通信端末１２のユーザ等が操作するキーボード及びマウス等のポインティングデバイスや、マイクロフォン等の音声入力デバイスを有している。入力装置８１は、ユーザ等からのプログラムの実行指示、各種操作情報、設定情報、ソフトウェアを起動するための情報等を入力する。

出力装置８２は、本実施形態における処理を行うためのコンピュータ本体を操作するのに必要な各種ウィンドウやデータ等を表示するディスプレイを有し、ＣＰＵ８６が有する制御プログラムによりプログラムの実行経過や結果等を表示することができる。

ここで、本実施形態においてコンピュータ本体にインストールされる実行プログラムは、例えばメモリカードやＵＳＢメモリ等の可搬型の記録媒体９１等により提供される。プログラムを記録した記録媒体９１は、ドライブ装置８３にセット可能であり、ＣＰＵ８６からの制御信号に基づき、記録媒体９１に含まれる実行プログラムが、記録媒体９１からドライブ装置８３を介して補助記憶装置８４にインストールされる。

補助記憶装置８４は、例えばハードディスクドライブやＳＳＤ等のストレージ手段等である。補助記憶装置８４は、ＣＰＵ８６からの制御信号に基づき、本実施形態における実行プログラムやコンピュータに設けられた制御プログラム、実行経過や実行結果等を記憶する。また、補助記憶装置８４は、ＣＰＵ８６からの制御信号等に基づいて、記憶された各情報から必要な情報を読み出したり、書き込むことができる。

主記憶装置８５は、ＣＰＵ８６により補助記憶装置８４から読み出された実行プログラム等を格納する。なお、主記憶装置８５は、例えばＲＯＭやＲＡＭ等である。

ＣＰＵ８６は、オペレーティングシステム等の制御プログラム、及び主記憶装置８５に格納されている実行プログラムに基づいて、各種演算や各ハードウェア構成部とのデータの入出力等、コンピュータ全体の処理を制御して各処理を実現することができる。なお、プログラムの実行中に必要な各種情報等は、補助記憶装置８４から取得することができ、また実行結果等を格納することもできる。

具体的には、ＣＰＵ８６は、例えば入力装置８１から得られるプログラムの実行指示等に基づき、補助記憶装置８４にインストールされたプログラムを実行させることにより、主記憶装置８５上でプログラムに対応する処理を行う。

例えば、ＣＰＵ８６は、プログラムを実行させることで、例えば上述したセンシング手段６４による通信端末１２の位置情報等の取得や、ユーザ状況把握手段６５によるユーザ状況の把握、アプリ実行手段６６によるアプリ実行等の実行制御を行う。また、ＣＰＵ８６は、アプリ操作状況把握手段６７によるアプリ操作状況の把握、再調整要否判定手段６８による再調整要否判定、再調整要求手段６９による再調整要求等の実行制御を行う。なお、ＣＰＵ８６における処理内容は、上述した内容に限定されるものではない。ＣＰＵ８６により実行された内容（実行経過や実行結果）等は、必要に応じて補助記憶装置８４に記憶させることができる。

ネットワーク接続装置８７は、ＣＰＵ８６からの制御信号に基づき、通信ネットワーク１３等と接続することにより、実行プログラムやソフトウェア、各種命令等を、通信ネットワーク１３に接続されている外部装置等から取得する。また、ネットワーク接続装置８７は、プログラムを実行することで得られた実行結果又は本実施形態における実行プログラム自体を外部装置等に提供することができる。

なお、ネットワーク接続装置８７としては、例えばＷｉＦｉやＢｌｕｅｔｏｏｔｈ等による通信を可能にする通信手段でもよい。また、ネットワーク接続装置８７は、電話端末との通話を可能にする通話手段でもよい。更には、上述した構成を組み合わせたものでもよい。

測位装置８８は、例えばＧＰＳ機能として、ＧＰＳ衛星から送信されたＧＰＳデータを受信し、通信端末１２の現在の測位情報（例えば、測位座標等）を取得する。また、測位装置８８は、ＧＰＳ機能を用いた測位の他にも、データの送受信を行う中継装置や無線基地局等の位置情報に基づいて通信端末１２の位置情報を取得してもよい。その場合、位置情報は、例えば無線基地局や中継装置等の位置情報を用いることができる。更に、測位装置８８は、位置情報を単位時間あたりの時系列で取得し、取得した単位時間あたりの位置情報の変位から速度情報を取得することができる。

加速度センサ８９は、通信端末１２の３軸方向（Ｘ軸方向、Ｙ軸方向、Ｚ軸方向）毎の重力加速度情報を、単位時間あたりの時系列で取得する。角速度センサ９０は、通信端末１２の移動時の回転量（方位）を、単位時間あたりの時系列で取得する。つまり、加速度センサ８９や角速度センサ９０は、通信端末１２の位置や方向等を取得するための手段であり、他のセンサ系等により測定してもよい。上述したようなハードウェア構成により、本実施形態におけるアプリケーション実行処理を実行することができる。

＜各種データ例＞
ここで、上述したアプリケーション提供サーバ１１の記憶手段２３及び通信端末１２の記憶手段６３に記憶される各種データ例について、図を用いて説明する。図６、図７は、アプリケーション提供サーバに記憶されるデータ例を示す図（その１，その２）である。

図６（Ａ）は、スケジュールＤＢのデータ例を示している。図６（Ａ）に示すスケジュールＤＢは、ユーザ毎に予め設定された今後の行動予定（件名）等のスケジュール内容が記憶されている。なお、スケジュールＤＢは、例えば過去の履歴情報が格納されていてもよい。スケジュールＤＢの項目としては、例えば、開始日時と、終了日時と、件名と、場所とを有するが、これに限定されるものではなく、例えばユーザを識別するユーザ識別情報等を有してもよい。

図６（Ｂ）は、端末アプリテンプレートのデータ例を示している。図６（Ｂ）に示す端末アプリテンプレートは、アプリ生成手段２６が、端末アプリを生成するために使用する予め設定されたテンプレートである。端末アプリテンプレートには、例えばテンプレートを識別する識別情報（テンプレートＩＤ）と、そのテンプレートに対応した内容とを対応付けて記憶されている。端末アプリテンプレートには、図６（Ｂ）に示すように１又は複数のパラメータ部分を含み、それぞれのパラメータに可変の値を設定できるため、各ユーザに適切な端末アプリを生成することができる。

端末アプリテンプレートは、ＩＤ毎にアプリケーションに用いられる各動作単位のテンプレートが管理される。アプリ生成手段２６は、通信端末１２の現在の状況等に対応するテンプレートを予め記憶された複数の端末アプリテンプレートから選択し、そのテンプレートの各パラメータ部分に関し、例えばメソッド引数パラメータの対応する値に置換して端末アプリを生成する。なお、上述の処理は、例えば予め設定されたＨＴＭＬ用テンプレートエンジン等を使用して取得することができるが、これに限定されるものではない。

また、図６（Ｃ）は、状況・調整対応ＤＢのデータ例を示している。図６（Ｃ）に示す状況・調整対応ＤＢは、例えば後述する調整処理スクリプトに対して、そのスクリプトが実行される条件となる対象アプリ種別や状況種別、予測状況（予測使用時状況）、現在状況等が予め設定されている。

つまり、状況・調整対応ＤＢには、例えば対象アプリ種別や状況種別等に対応する予測状況や現在状況等が記憶される。また、状況・調整対応ＤＢには、記憶した状況等に対応させて、端末アプリテンプレートから生成されるアプリの内容を調整するためのスクリプト等が記憶される。なお、状況・調整対応ＤＢは、例えば上述した内容調整手段４１−２が参照する。

ここで、状況・調整対応ＤＢにおいて、「対象アプリ種別」が"空"の場合には、全アプリ種別に対して調整処理スクリプトが適用される。また、「予測状況」又は「現在状況」が"空"の場合には、それぞれ全状況に対して調整処理スクリプトが適用される。多くの場合は、「予測状況」のみに基づいてスクリプトを実行し、「現在状況」は"空"とする。ただし、状況の１つである「社内社外状況」に関しては、現在状況に基づく動作が必要であるため、予測状況を"空"にして登録しておく。

例えば、「現在状況」が"社外"で、「予測状況」が"社内"の場合、通信端末１２で実行されるアプリの画面上に社外秘情報を含まないようにするための調整処理スクリプトが設定される。また、「対象アプリ種別」が"アンケート"で、「状況種別」が"アプリ操作状況"で「現在状況」が"非使用期間１−２週間"である場合には、アンケート項目を減らして必須項目のみに調整するための調整処理スクリプトが設定される。なお、設定される調整処理スクリプトの内容については、これに限定されるものではない。

また、図６（Ｄ）は、プッシュ済アプリＤＢのデータ例を示している。図６（Ｄ）に示すプッシュ済アプリＤＢには、例えばアプリケーション提供サーバ１１から通信端末１２に送信されたプッシュ済アプリを識別するための識別情報（プッシュ済アプリＩＤ）とアプリ種別とを対応付けて記憶する。プッシュ済アプリＤＢは、図７（Ａ）に示すアプリ使用時状況相関ＤＢを更新する際に、プッシュ済アプリＩＤからアプリ種別を取得するために参照される。なお、どの通信端末１２に対して配信したアプリであるかを管理するために、プッシュ済アプリＤＢにユーザ識別情報や端末識別情報等を有してもよい。

また、図７（Ａ）は、アプリ使用時状況相関ＤＢのデータ例を示している。図７（Ａ）に示すアプリ使用時状況相関ＤＢの項目としては、例えば、アプリ種別と、ユーザ状況種別と、ユーザ状況と、状況との相関度と、頻度（出現回数）とを有するが、これに限定されるものではない。

アプリ使用時状況相関ＤＢは、アプリ使用時状況を予測するために使用されるＤＢである。具体的には、アプリ使用時状況相関ＤＢは、アプリ種別毎に、どのアプリがどのようなユーザ状況で使用されているかが、他のユーザ状況との相関度（確率）等により管理されている。アプリ使用時状況相関ＤＢにおいて、「頻度（出現回数）」は、過去にそのアプリを使用したときのユーザ状況毎の回数が記憶される。また、「頻度（出現回数）」は、使用状況更新手段２９によって更新され、更新された頻度情報等に基づいて「状況との相関度」が更新される。

また、図７（Ｂ）は、想定状況ＤＢのデータ例を示している。図７（Ｂ）に示す想定状況ＤＢの項目としては、アプリ種別と、アプリＩＤと、対象状況種別と、対象状況と、想定値とを有するが、これに限定されるものではない。

想定状況ＤＢは、通信端末１２とアプリケーション提供サーバ１１との両方に設けられる。通信端末１２上における想定状況ＤＢは、アプリケーション提供サーバ１１からのアプリ受信時に更新され、再調整要否を判定するために使用される。

また、アプリケーション提供サーバ１１上の想定状況ＤＢのうち、対象状況種別が「アプリ操作状況」である場合の入力は、例えばアプリ開発者等によって更新される。また、対象状況種別が「ユーザ状況」の場合の入力は、アプリ生成手段２６が、使用時状況予測手段４１−１により取得した予測使用時状況の値が設定される。アプリケーション提供サーバ１１は、アプリ配信時に、該当するアプリ用の想定状況があれば、配信データに含めて通信端末１２に転送される。

想定状況ＤＢとして、「対象状況」と、その「想定値」を記憶することで、例えばアプリが使用されると予測される「時間帯」等を記憶し、社内や社外を何度も行き来する場合でも、途中の状況変化時の調整を抑制することができ、適切なアプリを提供することができる。

なお、上述した図７（Ｂ）に示す想定状況ＤＢは、再調整時にプッシュ済アプリがどのような状況に基づいて調整されたものかを調べ、その状況の変化を考慮した調整を行うために使用することもできる。例えば、アプリを再生成して、その全てを転送するのではなく、通信端末１２に転送済アプリの一部を変更する差分データを転送するような場合に、変更箇所の決定のために想定状況ＤＢを使用することもできる。例えば、状況の変化に伴い、アプリ内のどの部分をどのように変更するか等の処理を行う場合に、想定状況ＤＢを参照して状況に対応した調整処理スクリプトを取得し、取得したスクリプトを実行させることができる。

図８は、通信端末に記憶されるデータ例を示す図である。図８（Ａ）は、ユーザ状況ＤＢのデータ例を示している。図８（Ａ）に示すユーザ状況ＤＢは、ユーザ状況把握手段６５により更新されるデータが記憶される。ユーザ状況ＤＢの項目としては、例えばユーザ状況種別と、値とを有するが、これに限定されるものではない。

図８（Ａ）の例では、ユーザ状況種別が"社内社外状況"であり値が"社内"のデータと、ユーザ状況種別が"電車移行中状況"であり値が"Ｎｏ"のデータ例を示している。ユーザ状況の違いに応じて複数のデータが記憶される。図８（Ａ）に示すユーザ状況ＤＢは、例えば再調整要否判定やアプリ使用時状況予測を行う場合等に使用される。

また、図８（Ｂ）は、入力途中データのデータ例を示している。図８（Ｂ）に示す入力途中データは、通信端末１２で実行されている端末アプリが入力途中で終了された場合に、その入力途中までのデータを記憶する。

なお、入力途中データは、端末アプリを実行途中に終了されて、再度起動された場合に、入力中のデータを反映した形で続きから使用できるようにするためのデータである。再調整時に、入力途中データを入力済みの値として埋め込んだり、入力途中データがあれば入力項目を省略する等の調整を行ったりするためにも使用される。

入力途中データの項目としては、例えばアプリＩＤと、変数名と、入力途中データ内容とを有するが、これに限定されるものではない。入力途中データへのデータの記憶は、例えば端末アプリが、途中終了する場合に、それまで入力された内容を通信端末１２内の記憶手段６３に記憶する機能を有することで実現することができるが、これに限定されるものではない。

また、図８（Ｃ）は、アプリＤＢのデータ例を示している。図８（Ｃ）に示すアプリＤＢは、通信端末１２にある端末アプリのアプリリスト及びアプリの本体を記憶する。本実施形態では、アプリ実行手段６６がアプリリストを画面に表示するために使用することもできる。アプリＤＢの項目としては、例えばアプリＩＤと、アプリ種別と、アプリ本体とを有するが、これに限定されるものではない。アプリ種別は、上述した再調整要求手段６９が、アプリ種別のみ渡された場合に、そのアプリ種別からアプリＩＤを取得するために使用される。

また、アプリ本体としては、例えばＨＴＭＬ５ファイルや、ＪａｖａＳｃｒｉｐｔファイル等のアプリを実行するための各ファイル本体が記憶される。

また、図８（Ｄ）は、使用履歴ＤＢのデータ例を示している。図８（Ｄ）に示す使用履歴ＤＢの項目としては、例えばアプリＩＤと、使用日時と、使用時状況リストとを有するが、これに限定されるものではない。

使用履歴ＤＢに含まれる「使用時状況リスト」は、上述した図７（Ａ）に示すアプリ使用時状況相関ＤＢを更新するためのものである。したがって、使用履歴ＤＢは、定期的又は所定のタイミングでアプリケーション提供サーバ１１に送信される。また、「使用日時」は、後述する図８（Ｅ）に示すアプリ操作状況ＤＢの非使用期間を更新するためのものである。

また、図８（Ｅ）は、アプリ操作状況ＤＢのデータ例を示している。図８（Ｅ）に示すアプリ操作状況ＤＢは、上述した再調整要否判定手段６８における再調整要否判定に使うためのデータが記憶されている。アプリ操作状況ＤＢは、例えばアプリＩＤと、非使用期間とが対応付けられて記憶されている。なお、上述したアプリ操作状況ＤＢは、定期的又は所定のタイミングでアプリケーション提供サーバ１１に送信される。

なお、本実施形態では、上述した図７（Ａ）や、図８（Ａ）等に示すように、例えばユーザの行動予定を取得して、対象のユーザ状況として「スケジュール予定」を含めることで、スケジュールに基づく適切なタイミングでの調整や、より適切な調整要否判定等を行うことができる。

＜アプリケーション提供処理及びアプリケーション実行処理について＞
次に、アプリケーション提供サーバ１１におけるアプリケーション提供処理及び通信端末１２におけるアプリケーション実行処理について、フローチャート等を用いて説明する。

＜初回の端末アプリの生成処理＞
図９は、初回の端末アプリの生成処理の一例を示すフローチャートである。図９の例では、アプリケーション提供サーバ１１におけるアプリケーション提供処理の一例として、
初回の端末アプリの生成と配信（プッシュ）時の処理とを含めて説明する。

図９の例に示す生成処理は、まず配信ルール実行手段２５により、ある所定の配信ルール（例えば、"配信ルール１"）が、アプリ配信Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）を呼び出す（Ｓ０１）。

なお、ある所定の配信ルールとしては、例えばユーザがセミナー室等の出口に来た場合に、アンケート回答状況を取得し、アンケートが未回答である場合に、アンケートフォームをそのユーザに送信するといった配信ルールであるが、これに限定されるものではない。つまり、アプリケーション提供サーバ１１は、配信ルール実行手段２５により所定の配信ルールを実行すると共に、通信端末１２から操作内容や現在位置等を受信して、アプリを生成するための所定の条件を満たすか否かを定期的に判断する。

次に、生成処理は、配信ルール実行手段２５において、配信ルール１における上述した所定の条件を満たす場合に、アプリ生成手段２６を呼び出す（Ｓ０２）。また、生成処理は、アプリ生成手段２６によって、上述した図６（Ｂ）に示すような所定の端末アプリテンプレートを用いて端末アプリを生成する（Ｓ０３）。また、生成処理は、使用時状況予測手段４１−１から予測使用時状況を取得する（Ｓ０４）。

次に、生成処理は、内容調整手段４１−２により、予測した使用時の状況（予測使用時状況）と、現在状況と、上述した図６（Ｃ）に示す状況・調整対応ＤＢとに基づいて、端末アプリを調整する（Ｓ０５）。また、生成処理は、内容調整手段４１−２により調整に使用した予測使用時状況と、現在状況とに基づいて、使用される端末アプリ等の対象状況や想定値等を設定し、想定状況ＤＢに記憶する（Ｓ０６）。

また、生成処理は、アプリ配信手段２７において、端末アプリと、想定状況ＤＢに含まれる想定状況とを対象の通信端末１２に配信し（Ｓ０７）、上述した図６（Ｄ）に示すようにプッシュ済アプリＤＢを更新する（Ｓ０８）。

上述したように、アプリケーション提供サーバ１１から送信された端末アプリと想定状況ＤＢの内容は、通信端末１２の送受信手段７０で受信され、それぞれが記憶手段６３のアプリＤＢ（図８（Ｃ））と想定状況ＤＢに記憶される。

＜ユーザ状況変化時の再調整処理＞
図１０は、ユーザ状況変化時の再調整処理の一例を示すフローチャートである。なお、図１０の例では、通信端末１２におけるアプリケーション実行処理の一例として、ユーザ状況変化時の端末アプリの再調整処理を示している。

図１０の例に示す再調整処理は、ユーザ状況把握手段６５により定期的又はユーザ状況が変化した等の所定のタイミングで上述した図８（Ａ）に示すユーザ状況ＤＢの更新処理を実行する（Ｓ１１）。また、再調整処理は、センシング手段６４により通信端末１２の現在位置や移動方向等に伴うユーザ状況を取得する（Ｓ１２）。

次に、再調整処理は、ユーザ状況に変化があったか否かを判断し（Ｓ１３）、変化があった場合、（Ｓ１３において、ＹＥＳ）、ユーザ状況把握手段６５により、ユーザ状況ＤＢを更新し（Ｓ１４）、再調整要否判定手段６８に、変化したユーザ状況を出力する（Ｓ１５）。また、再調整処理は、再調整要否判定手段６８により再調整要否を判定し（Ｓ１６）、再調整が必要なアプリがあるか否かを判断する（Ｓ１７）。

再調整処理は、再調整が必要なアプリがある場合（Ｓ１７において、ＹＥＳ）、再調整要求手段６９に、再調整用のアプリリスト（例えば、アプリ種別、アプリＩＤ等）を出力して、再調整を要求する（Ｓ１８）。

次に、再調整処理は、アプリリストの各アプリに対して、アプリケーション提供サーバ１１へ送信するサーバ送信用データを作成する（Ｓ１９）。具体的には、Ｓ２０〜Ｓ２３の処理をアプリリストが終了するまで繰り返し行う（アプリリスト作成ループ）。

再調整処理は、各アプリのアプリＩＤが空か否かを判断し（Ｓ１９）、空でない場合（Ｓ１９において、ＮＯ）、アプリＩＤに対応するサーバ送信用データを作成して、サーバ送信用データリスト（再調整要求データ）に追加する（Ｓ２１）。

また、再調整処理は、アプリＩＤが空である場合（Ｓ１９において、ＹＥＳ）、上述した図８（Ｃ）に示すアプリＤＢをアプリ種別で検索してアプリＩＤを取得する（Ｓ２２）。また、再調整処理は、各アプリＩＤに対応するサーバ送信用データを作成してサーバ送信用データリスト（再調整要求データ）に追加する（Ｓ２３）。

次に、再調整処理は、再調整要求手段６９により、再調整要求データをアプリケーション提供サーバ１１に送信する（Ｓ２４）。また、再調整処理は、上述したＳ２４の処理に対応してアプリケーション提供サーバ１１から送られた各種データ等を受信し、受信したデータを各ＤＢに記憶する（Ｓ２５）。また、再調整処理は、アプリケーション提供サーバ１１により再調整された端末アプリを受信し、上述した図８（Ｃ）に示すアプリＤＢに記憶し（Ｓ２６）、処理を終了する。

なお、再調整処理は、上述したＳ１３の処理において、ユーザ状況の変化がなかった場合（Ｓ１３において、ＮＯ）、又はＳ１７の処理において、再調整が必要なアプリがなかった場合（Ｓ１７において、ＮＯ）、処理を終了する。

＜サーバ側でのアプリ再調整処理＞
なお、アプリケーション提供サーバ側でのアプリ再調整処理については、通信端末１２から送信される再調整対象アプリリスト内の各アプリに対して、上述した図９に示すＳ０３〜Ｓ０８の処理を行えばよい、そのため、ここでの具体的な説明は省略する。

なお、図１０の処理では、各アプリＩＤに関するサーバ送信用データは、入力途中データ、アプリ操作状況ＤＢ、使用履歴ＤＢを有し、最終的なサーバ送信用データ（再調整要求データ）は、更にユーザ状況ＤＢを追加した形になる。

＜アプリ使用時状況予測処理＞
ここで、アプリケーション提供処理の一例として、上述した使用時状況予測手段４１−１における予測使用時状況の予測処理についてフローチャートを用いて具体的に説明する。図１１は、予測使用時状況の予測処理の一例を示すフローチャートである。図１１の例に示す予測処理は、まずアプリ生成手段２６によって、使用時状況予測手段４１−１にアプリ種別を渡して、アプリ使用時状況を取得し（Ｓ３１）、上述した図７（Ａ）に示すようにアプリ使用時状況相関ＤＢを、アプリ種別で検索する（Ｓ３２）。

次に、予測処理は、アプリ使用時状況相関ＤＢに含まれるユーザ状況種別毎に、相関度が最大の項目を抽出する（Ｓ３３）。図７（Ａ）の例では、「社内社外状況：社内」（相関度０．３１）、「電車以上中状況：Ｎｏ」（相関度０．０８）、「スケジュール予定：（無し）」（相関度０．０１）が抽出される。

また、予測処理は、抽出された項目のうち、相関度が予め設定された閾値以下の項目を削除し（Ｓ３４）、残ったユーザ状況を、予測したアプリ使用時ユーザ状況リストとしてアプリ生成手段２６に出力する（Ｓ３５）。

例えば、図７（Ａ）に示すアプリ使用時状況相関ＤＢから予測ユーザ状況を取得する際に、予め相関度が０．３以下の項目を削除すると設定していたとする。その場合、最終的なユーザ状況リストとして、アプリ種別が「アンケート」の場合に、ユーザ状況種別が「社内社外状況」、ユーザ状況が「社内」が出力される。

＜アプリ使用時状況相関ＤＢ更新処理＞
次に、アプリケーション提供処理の一例として、使用状況更新手段２９における上述した図７（Ａ）に示すアプリ使用時状況相関ＤＢの更新処理についてフローチャートを用いて具体的に説明する。図１２は、アプリ使用時状況相関ＤＢの更新処理の一例を示すフローチャートである。

図１２の例に示す使用状況更新処理は、まず再調整受付手段２８により、通信端末１２から受信したデータ中の使用履歴ＤＢを記憶する（Ｓ４１）。次に、使用状況更新処理は、使用状況更新手段２９により、記憶手段２３に記憶された使用履歴ＤＢを取得し（Ｓ４２）、各アプリＩＤをアプリ種別に置換する（Ｓ４３）。なお、Ｓ４３の処理では、プッシュ済アプリＤＢをアプリＩＤで検索し、アプリ種別を取得する。

次に、使用状況更新処理は、各使用時状況リストの各要素について、アプリ使用時状況相関ＤＢの該当する項目の頻度（例えば、出現回数等）をインクリメント（＋１）する（Ｓ４４）。その後、使用状況更新処理は、各相関度の値を、例えば項目毎の頻度を全合計頻度で除算（頻度／全合計頻度）することで、更新する（Ｓ４５）。

＜端末アプリの内容調整処理＞
次に、アプリケーション提供処理の一例として、内容調整手段４１−２における内容調整処理についてフローチャートを用いて具体的に説明する。図１３は、内容調整処理の一例を示すフローチャートである。

図１３の例に示す内容調整処理は、アプリ生成手段２６において上述した図６（Ｂ）に示す端末アプリテンプレートを読み込む（Ｓ５１）。また、内容調整処理は、アプリ生成手段２６により、端末アプリテンプレート内の各パラメータ部分に対し、メソッド引数パラメータの対応する値に置換して、端末アプリを生成する（Ｓ５２）。

次に、内容調整処理は、内容調整手段４１−２により、上述した図８（Ｅ）に示すアプリ操作状況ＤＢを、調整対象のアプリＩＤで検索する（Ｓ５３）。この検索により、現在のアプリ操作状況を取得する。

次に、内容調整処理は、上述した図６（Ｃ）に示す状況・調整対応ＤＢを検索し、検索条件に一致するエントリがあれば、該当する調整処理を、端末アプリに適用する（Ｓ５４）。なお、検索条件としては、例えば対象アプリ種別が"生成された端末アプリのアプリ種別と同一"で、状況種別が"アプリ操作状況"で、現在状況が"現在アプリ操作状況と同一"の場合等があるが、これに限定されるものではない。

また、内容調整処理は、使用時状況予測手段４１−１により使用時状況を予測し、予測した結果を含む予測ユーザ状況リストを出力する（Ｓ５５）。次に、内容調整処理は、内容調整手段４１−２により、使用時状況予測手段４１−１から現在状況リストを取得し（Ｓ５６）、予測ユーザ状況リストと、現在状況リストの全組み合わせを作成する（Ｓ５７）。

また、内容調整処理は、図６（Ｃ）に示す状況・調整対応ＤＢ内から、対象アプリ種別が、生成された端末アプリのアプリ種別に一致し、状況種別が"ユーザ状況"の全エントリを取得する（Ｓ５８）。なお、Ｓ５８の処理では、予測状況（予測使用時状況）と現在状況の組のリストを作成してもよい。

次に、内容調整処理は、予測状況と現在状況の組のリストが空か否かを判断し（Ｓ５９）、リストが空でない場合（Ｓ５９において、ＮＯ）、リストから１つを取得する（Ｓ６０）。また、取得したリストの１つが、上述したＳ５７の処理により得られる全組み合わせに含まれるか否かを判断する（Ｓ６１）。

ここで、内容調整処理は、全組み合わせに含まれない場合（Ｓ６１において、ＮＯ）、Ｓ５９の処理に戻る。また、内容調整処理は、全組み合わせに含まれる場合（Ｓ６１において、ＹＥＳ）、想定状況ＤＢに予測状況、現在状況を記憶する（Ｓ６２）。具体的には、例えば、予測状況と、現在状況とに基づいて、使用される端末アプリ等の対象状況や想定値等を想定状況ＤＢに記憶する。また、内容調整処理は、状況・調整対応ＤＢから、該当する調整処理（例えば、スクリプト等）を取得する（Ｓ６３）。また、取得した調整処理を、端末アプリに適用し（Ｓ６４）、Ｓ５９の処理に戻る。なお、Ｓ６４の処理では、状況に一致する調整処理を全て適用することができるが、これに限定されるものではない。

また、内容調整処理は、上述したＳ５９の処理において、リストが空である場合（Ｓ５９において、ＹＥＳ）、端末アプリを配信し（Ｓ６５）、処理を終了する。

＜再調整要否判定処理＞
次に、アプリケーション実行処理の一例として、再調整要否判定手段６８における再調整要否判定処理についてフローチャートを用いて具体的に説明する。図１４は、再調整要否判定処理の一例を示すフローチャート（その１）である。なお、図１４の例では、ユーザ状況変化時における再調整要否判定処理の一例を示している。

図１４の例に示す再調整要否判定処理は、ユーザ状況把握手段６５により、上述した図８（Ａ）に示すユーザ状況ＤＢを更新後、再調整要否判定手段６８に再調整判定を依頼する（Ｓ７１）。なお、Ｓ７１の処理では、例えば「更新ユーザ状況、値」を含むリストを再調整要否判定手段６８に出力する。「更新ユーザ状況、値」の具体例としては、例えば「＜更新ユーザ状況＞社内社外状況：＜値＞社内」、「＜更新ユーザ状況＞電車移動中状況：＜値＞Ｎｏ」等があるが、これに限定されるものではない。

次に、再調整要否判定処理は、想定条件ＤＢの対象状況種別が、"ユーザ状況"のエントリを検索し、アプリＩＤ毎にグルーピングして、各グループ毎に再調整要否を判定する（Ｓ７２）。具体的には、再調整要否判定処理は、図１４に示すように、グループ内の各エントリ（例えば、アプリ種別、アプリＩＤ、対象状況、想定値）に対してＳ７４〜Ｓ７６のループ処理を行う（Ｓ７３）。また、再調整要否判定処理は、更新ユーザ状況リストの各エントリ（例えば、更新ユーザ状況、値）に対してＳ７５、Ｓ７６のループ処理を行う（Ｓ７４）。

再調整要否判定処理は、対象状況が更新ユーザ状況と一致し、想定値が更新ユーザ状況の値と一致しないか否かを判定し（Ｓ７５）、上述の条件を満たす場合（Ｓ７５において、ＹＥＳ）、アプリ種別とアプリＩＤとを再調整用アプリリストに追加する（Ｓ７６）。また、再調整要否判定処理は、上述したＳ７５における条件を満たさない場合（Ｓ７５において、ＮＯ）、何も処理をしない。

次に、再調整要否判定処理は、上述したＳ７２〜Ｓ７４の処理におけるループ処理が終了後、その検索結果が空であるか否かを判断し（Ｓ７７）、検索結果が空でない場合（Ｓ７７において、ＮＯ）、再調整用アプリリストを、再調整用要求手段６９に渡して、再調整を依頼する（Ｓ７８）。また、再調整要否判定処理は、上述した検索結果が空である場合（Ｓ７７において、ＹＥＳ）、再調整の必要がないと判断して、そのまま処理を終了する。

図１５は、再調整要否判定処理の一例を示すフローチャート（その２）である。なお、図１５の例では、アプリ操作状況変化時における再調整要否判定処理の一例を示している。

図１５の例に示す再調整要否判定処理は、アプリ操作状況把握手段６７により上述した図８（Ｅ）に示すアプリ操作状況ＤＢを更新後、再調整要否判定手段６８に再調整判定を依頼する（Ｓ８１）。なお、Ｓ８１の処理では、例えば「更新アプリＩＤ、更新アプリ操作状況、値」を含むリストを再調整要否判定手段６８に出力する。「更新アプリＩＤ、更新アプリ操作状況、値」の具体例としては、例えば「＜更新アプリＩＤ＞ｅｎｑｕｅｔｅ−２０１２０７２６１９４３０１：＜更新アプリ操作状況＞非使用期間：＜値＞１週間未満」がある。また、他の例としては、「＜更新アプリＩＤ＞出張旅費承認−２０１２１１１９１６０８０１：＜更新アプリ操作状況＞非使用期間：＜値＞３日未満」等があるが、これに限定されるものではない。

次に、再調整要否判定処理は、想定条件ＤＢの対象状況種別が、"アプリ操作状況"のエントリを検索し、アプリＩＤ毎にグルーピングして、各グループ毎に再調整要否を判定する（Ｓ８２）。具体的には、図１５に示すように、グループ内の各エントリ（アプリ種別、アプリＩＤ、対象状況、想定値）に対してＳ８４〜Ｓ８６のループ処理を行い（Ｓ８３）、更新ユーザ状況リストの各エントリ（アプリＩＤ、更新アプリ操作状況、値）に対してＳ８５、Ｓ８６のループ処理を行う（Ｓ８４）。

再調整要否判定処理は、アプリＩＤが更新アプリＩＤと一致し、対象状況が更新アプリ操作状況と一致し、想定値が更新アプリ操作状況の値と一致しないか否かを判定し（Ｓ８５）、上述の条件を満たす場合（Ｓ８５において、ＹＥＳ）、アプリ種別とアプリＩＤとを再調整用アプリリストに追加する（Ｓ８６）。また、再調整要否判定処理は、上述したＳ８５における条件を満たさない場合（Ｓ８５において、ＮＯ）、何も処理をしない。

次に、再調整要否判定処理は、上述したＳ８２〜Ｓ８４の処理におけるループ処理が終了後、その検索結果が空であるか否かを判断し（Ｓ８７）、検索結果が空でない場合（Ｓ８７において、ＮＯ）、再調整用アプリリストを、再調整用要求手段６９に渡して、再調整を依頼する（Ｓ８８）。また、再調整要否判定処理は、上述した検索結果が空である場合（Ｓ８７において、ＹＥＳ）、再調整の必要がないと判断して、そのまま処理を終了する。なお、上述した図１４と図１５の処理は、適宜組み合わせて処理することもできる。

＜ユーザ状況ＤＢ更新処理＞
次に、アプリケーション実行処理の一例として、ユーザ状況把握手段６５におけるユーザ状況ＤＢの更新処理についてフローチャートを用いて具体的に説明する。図１６は、ユーザ状況ＤＢの更新処理の一例を示すフローチャート（その１）である。

図１６の例に示すユーザ状況ＤＢの更新処理は、ユーザ状況把握手段６５により、センシング手段６４からＧＰＳ情報として、緯度経度等の位置情報等を取得する（Ｓ９１）。次に、更新処理は、ユーザ状況ＤＢ内の社内社外状況の現在の値（以下、「現在値」という）を取得する（Ｓ９２）。

ここで、ユーザ状況ＤＢの更新処理は、Ｓ９１の処理で取得した緯度経度が社内の範囲であるか否かを判断する（Ｓ９３）。緯度経度が社内でない場合（Ｓ９３において、ＮＯ）、Ｓ９２の処理で取得した現在値が"社外"であるか否かを判断し（Ｓ９４）、"社外"でない場合（Ｓ９４において、ＮＯ）、ユーザ状況ＤＢ内の社内社外状況の値を"社外"に設定する（Ｓ９５）。

また、Ｓ９３の処理において、緯度経度が社内である場合（Ｓ９３において、ＹＥＳ）、現在値が"社内"であるか否かを判断し（Ｓ９６）、"社内"でない場合（Ｓ９６において、ＮＯ）、ユーザ状況ＤＢ内の社内社外状況の値を"社内"に設定する（Ｓ９７）。つまり、上述したＳ９５及びＳ９７の処理では、値が変化した場合に、ＤＢの更新を行う。

次に、更新処理は、Ｓ９５又はＳ９７の処理が終了後、再調整要否判定手段６８に再調整要否判定依頼を行い（Ｓ９８）、再調整が必要なアプリがあるか否かを判断する（Ｓ９９）。更新処理は、再調整が必要なアプリがある場合（Ｓ９９において、ＹＥＳ）、再調整要求手段６９に再調整を要求し（Ｓ１００）、再調整要求手段６９は、ユーザ状況ＤＢ内容等をアプリケーション提供サーバ１１に送信する（Ｓ１０１）。これにより、アプリケーション提供サーバ１１の再調整受付手段２８は、通信端末１２から送信されたデータのうちのユーザ状況ＤＢの内容を記憶手段２３に記憶する。
なお、更新処理は、上述したＳ９４の処理において、現在値が社外である場合（Ｓ９４において、ＹＥＳ）、Ｓ９６の処理において、現在が社内である場合（Ｓ９６において、ＹＥＳ）、又は、Ｓ９９の処理において、再調整が必要なアプリがない場合（Ｓ９９において、ＮＯ）、そのまま処理を終了する。

なお、ユーザ状況把握手段６５は、上述した更新処理を所定のタイミングで行うことで、ユーザ状況を適切に把握することができる。なお、更新条件としては、上述した例に限定されるものではなく、例えば上述した図７（Ｂ）に示す想定状況ＤＢを参照して、所定の対象状況に対してのみユーザ状況ＤＢを更新してもよい。

具体的には、想定状況ＤＢ内で、対象状況種別が「ユーザ状況」の項目の対象状況の値のリストを取得する。図７（Ｂ）の例では、「対象状況"社内社外状況"で想定値が"社外"」と、「対象状況"時間帯"で想定値が"１７時台"」との２つのデータがリストで取得される。この場合、対象状況のリストの各状況に対して、上述した図１６に示すように、更新処理を行う。これにより、所定の対象状況に対してのみユーザ状況ＤＢを更新する処理を行うため、バッテリ消費量を削減することができる。

また、上述したユーザ状況ＤＢ更新処理は、ユーザ状況としてスケジュール情報を付加して更新処理を行うことができる。つまり、過去の履歴や今度の行動予定等のスケジュール内容を組み合わせて、ユーザ状況ＤＢの更新処理を行う。例えば、アプリ使用時状況相関ＤＢのユーザ状況としてスケジュール予定を入れ、使用状況更新手段２９による更新処理を追加する。

図１７は、ユーザ状況ＤＢの更新処理の一例を示すフローチャート（その２）である。図１７の例に示すユーザ状況ＤＢの更新処理は、まず、予め記憶手段等に記憶されているユーザ状況ＤＢ更新ありフラグをオフに初期化し（Ｓ１１１）、ユーザ状況ＤＢから「ユーザ状況種別」のリストを取得する（Ｓ１１２）。次に、ユーザ状況ＤＢの更新処理は、「ユーザ状況種別」のリストの各状況種別に対して、更新処理を行う（Ｓ１１３）。

まず、ユーザ状況ＤＢの更新処理は、社内社外状況の更新処理を行う（Ｓ１１４）。この処理は、例えば上述した図１６におけるＳ９１〜Ｓ９７の処理を用いることができる。また、Ｓ１１４の処理では、上述したＳ９５及びＳ９７の処理を実行した場合にユーザ状況ＤＢ更新ありフラグをオンに設定する。

次に、更新処理は、アプリケーション提供サーバ１１から現在時刻のスケジュール予定の"件名"の値を取得し（Ｓ１１５）、ユーザ状況ＤＢ内のスケジュール予定状況の現在値を取得する（Ｓ１１６）。ここで、現在値とスケジュール予定とが一致するか否かを判断し（Ｓ１１７）、現在値とスケジュール予定とが一致しない場合（Ｓ１１７において、ＮＯ）、ユーザ状況ＤＢ内のスケジュール予定状況の値を更新する（Ｓ１１８）。つまり、Ｓ１１７の処理では、値が変化した場合にＤＢの更新を行う。また、Ｓ１１８の処理の終了後、ユーザ状況ＤＢ更新ありフラグをオンに設定する。

また、更新処理は、Ｓ１１９の処理終了後、又はＳ１１７の処理において、現在値とスケジュール値とが一致する場合（Ｓ１１７において、ＹＥＳ）、時間帯状況の更新を行う（Ｓ１２０）。Ｓ１２０の処理では、例えばユーザ状況ＤＢ内の時間帯状況の現在値を取得し、現在の時間と比較して、一致しない場合に、ユーザ状況ＤＢ内の時間帯状況の値を更新し、ユーザ状況ＤＢ更新ありフラグをオンに設定する。

ここで、更新処理は、ユーザ状況ＤＢ更新ありフラグがオンであるか否かを判断し（Ｓ１２１）、ユーザ状況ＤＢ更新ありフラグがオンである場合（Ｓ１２１において、ＹＥＳ）、再調整要否判定手段に再調整要否判定を依頼する（Ｓ１２２）。

また、更新処理は、再調整が必要なアプリがあるか否かを判断し（Ｓ１２３）、再調整が必要なアプリがある場合（Ｓ１２３において、ＹＥＳ）、再調整要求手段６９に再調整を要求する（Ｓ１２４）。また、再調整要求手段６９は、ユーザ状況ＤＢの内容等をアプリケーション提供サーバ１１に送信する（Ｓ１２５）。また、上述したＳ１２１の処理において、ユーザ状況ＤＢ更新ありフラグがオンでない場合（Ｓ１２１において、ＮＯ）、及びＳ１２３の処理において、再調整が必要なアプリがない場合（Ｓ１２３において、ＮＯ）、処理を終了する。

＜アプリ操作状況更新処理＞
次に、アプリケーション実行処理の一例として、アプリ操作状況把握手段６７におけるアプリ操作状況更新処理についてフローチャートを用いて具体的に説明する。図１８は、アプリ操作状況更新処理の一例を示すフローチャートである。

図１８の例に示すアプリ操作状況更新処理は、上述した図８（Ｃ）に示すようなアプリＤＢからアプリＩＤリストを取得し（Ｓ１３１）、各アプリＩＤに対して、アプリ操作状況を更新する（Ｓ１３２）。なお、Ｓ１３２の処理は、後述するＳ１３３〜Ｓ１３８の処理を、各アプリＩＤに対する処理が終了するまでループ処理を行う。

具体的には、アプリ操作状況更新処理は、アプリ操作状況ＤＢをアプリＩＤで検索して、非使用期間の現在値を取得する（Ｓ１３３）。次に、アプリ操作状況更新処理は、使用履歴ＤＢをアプリＩＤで検索して、最新の使用日時（最終使用日時）を取得する（Ｓ１３４）。ここで、現在日時から最終使用日時を減算して得られる値を更新値とし（Ｓ１３５）、更新値が現在値に含まれるか否かを判断する（Ｓ１３６）。

ここで、更新値が現在値（例えば、１週間未満）に含まれない場合（Ｓ１３６において、ＮＯ）、アプリ操作状況ＤＢを更新し（Ｓ１３７）、アプリＩＤと、更新値とを更新アプリ操作状況リストに追加する（Ｓ１３８）。また、Ｓ１３６の処理において、更新値が現在値に含まれる場合（Ｓ１３６において、ＹＥＳ）、何も処理を行わない。つまり、値が変化した場合のみＤＢの更新を行う。

次に、アプリ操作状況更新処理は、更新アプリ操作状況リストが空か否かを判断し（Ｓ１３９）、更新アプリ操作状況リストが空でない場合（Ｓ１３９において、ＮＯ）、再調整要否判定手段６８に再調整要否判定を行う（Ｓ１４０）。また、アプリ操作状況更新処理は、再調整が必要なアプリがあるか否かを判断し（Ｓ１４１）、再調整が必要なアプリがある場合（Ｓ１４１において、ＹＥＳ）、再調整要求手段６９に再調整要求を行う（Ｓ１４２）。その後、アプリ操作状況更新処理は、再調整要求手段６９により、アプリ操作状況ＤＢの内容をアプリケーション提供サーバ１１に送信する（Ｓ１４３）。これにより、アプリケーション提供サーバ１１の再調整受付手段２８は、受信したデータのうちのアプリ操作状況ＤＢ内容を、アプリ操作状況ＤＢに記憶することができる。

また、上述したＳ１３９の処理において、更新アプリ操作状況リストが空の場合（Ｓ１３９において、ＹＥＳ）、又はＳ１４１の処理において、再調整が必要なアプリがない場合（Ｓ１４１において、ＮＯ）、何も処理を行わずに処理を終了する。

＜本実施形態で適用されるアプリの提供例（状況変化時の調整）＞
次に、本実施形態で適用されるアプリの提供例について具体的に説明する。本実施形態で提供される端末アプリの例としては、例えば、部下からの申請に対して上司が申請を承認するための申請承認アプリがある。この端末アプリでは、ユーザが社外に出たら、社外秘情報をぼかす調整を行う調整処理スクリプトを実行する。

また、他の端末アプリの例としては、アンケート記入アプリ（調査記入アプリ）が、暫く回答されてなかったら、必須項目のみにしたアプリに変更するよう調整する。この場合には、前回画面で表示されたアンケート項目よりも少ない内容で表示させるように調整するスクリプトを実行する。これにより、画面が簡素になるため、ユーザにアンケートの回答をさせやすくすることができる。

また、他の例として、ｅ−Ｌｅａｒｎｉｎｇアプリにおいて、ユーザが社外に出たら、社外秘情報が含まれる部分をスキップさせ、またユーザが社内に戻った時点で、スキップした部分のみを表示するような調整処理スクリプトを実行する。この場合、参照済みの項目を上述した入力途中データとして記憶しておくことで、アプリケーション提供サーバ１１におけるアプリ調整時に、参照済み以外の項目に関して、アプリを生成することができる。

また、本実施形態では、スケジュール予定等に基づいて、出張から帰ったら出張の精算を申請させるアプリをアプリケーション提供サーバ１１から通信端末１２に配信（プッシュ）することができる。このアプリは、出張毎に精算することもでき、次の出張が連続している場合には、次の出張も含めた形のアプリに調整することもできる。

つまり、本実施形態によれば、端末アプリを１申請で複数の出張精算が可能な形式に調整することで、上司の処理件数を削減することができる。また、出張先に近づいた時点で出張報告アプリをプッシュ（議事録アプリも同様）し、出張先から出ると、開始・終了時刻、参加者（ユーザ情報）が自動的に入力されてもよい。更に、出張期間中に更新や参照したファイルと関連付けが行われて、報告書の記入時に参照可能にしてもよい。なお、端末アプリの種類は、これに限定されるものではない。

ここで、図１９は、調整処理スクリプトの一例を示す図である。図１９の例では、アプリ内容の調整処理として、通信端末１２の位置やユーザの状況等に基づいて、社外秘情報をぼかす調整を行う。

本実施形態では、図１９に示すように、社外秘とする情報（例えば、"ド○○"、"郵○○社"、"○○○○ホン商談"）に対して、所定のワード（例えば"Ｄ社"、"Ｐ社"、"Ｒ商談"等に変更する調整を行うスクリプトが予め設定されている。

通信端末１２のユーザ状況把握手段６５は、センシング手段６４からＧＰＳ情報を定期的に取得し、緯度経度が予め設定された社内の範囲内に含まれているか否かにより、ユーザが社内にいるか、社外にいるかを判定する。この判定結果は、上述した図８（Ａ）に示すユーザ状況ＤＢ等に記憶されると共に、ユーザ状況ＤＢがアプリケーション提供サーバ１１に送信される。

ここで、アプリケーション提供サーバ１１は、例えば幹部社員Ａ用の配信ルールで、「承認を得る」メソッドが呼び出される。このときの引数は、例えば｛"ｔｉｔｌｅ"："ド○○の○○○○ホン商談"，"ｃｏｎｔｅｎｔ"："..."｝である。

アプリケーション提供サーバ１１のアプリ生成手段２６は、上述した引数に基づいて端末アプリを生成する。また、アプリ生成手段２６は、使用時状況予測手段４１−１を呼び出して、予測使用時状況を取得する。内容調整手段４１−２は、引数で渡された予測使用時状況と現在状況とに基づいて、アプリ生成手段２６で生成した端末アプリを調整する。

なお、調整時には、例えばユーザ状況ＤＢやアプリ操作状況ＤＢから現在状況リストを取得し、引数で渡された予測使用時状況（リスト）と現在状況（リスト）の全組み合わせを作成する。また、状況・調整対応ＤＢ内の、各エントリの＜予測状況と現在状況の組＞が、全組み合わせ中に含まれていれば、該当エントリの調整処理スクリプトを取得し、調整処理スクリプトを適用する。

また、状況・調整対応ＤＢ内の各エントリに対してループし、予測状況リストと現在状況リストの全組み合わせの内に一致するものがあったエントリの調整処理スクリプト「社外秘情報をぼかす」を取得する。したがって、内容調整手段４１−２は、調整処理として図１９に示すような「社外秘情報をぼかす」を生成した端末アプリ対して適用する。

アプリ生成手段２６は、調整済みの端末アプリをアプリ配信手段２７に渡して幹部社員Ａの端末に配信させる。

図１９に示す「社外秘情報をぼかす」調整処理スクリプトは、まず社外秘情報の特定を行う。例えば、個人名、会社名リストデータの各名前文字列を、端末アプリ内で文字列検索する。検索の結果"ド○○"、"郵○○社"、"○○○○ホン商談"等が抽出される。次に、図１９に示す調整処理スクリプトは、社外秘情報を他人が理解できない形式にぼかす。具体的には、個人名や会社名を各代替文字列で置換する（図１９の例では、"ド○○"→"Ｄ社"、"郵○○社"→"Ｐ社"、"○○○○ホン商談"→"Ｒ商談"等）。

したがって、通信端末１２の現在位置が社外の場合には、この調整処理スクリプトにより画面に表示される情報が変更されることにより、社外秘の情報の漏洩を防止することができる。図１９に示すようなスクリプトは、例えばＪａｖａＳｃｒｉｐｔ関数として、予め記憶手段等に記憶されていてもよい。

上述したように本実施形態では、通信端末等の状況に合わせた適切なアプリケーションを使用できる状態にすることができる。具体的には、端末アプリを生成するサーバでは、予測される将来のユーザ状況に基づいてアプリ生成して配信（プッシュ）することができる。つまり、過去のアプリ操作履歴や今後のユーザの行動予定を参照し、参照結果に応じてアプリ生成方法を決定することができる。

また、ユーザの現在状況に合わせて端末アプリを生成や調整するのではなく、ユーザが使う時点での状況を予測して、それに合わせてアプリを生成したり、調整して通信端末１２にプッシュしておく。なお、例外として、今は社外にいて、社内に戻ってから使うと予測される場合、社外秘情報は含めない。または、社内に戻った時点でプッシュすることができる。なお、本実施形態では、例えば端末アプリで表示されるデータの内容によって、プッシュするタイミングを調整してもよい。

また、本実施形態では、サーバ側で過去のアプリ使用時のユーザ状況から学習して予測することができる。例えば、過去の履歴によると、午後から出張が入っているユーザは、出張先で端末アプリ（案件毎の承認アプリ）を使うことが多い場合、午前中に案件発生してアプリ生成する際に、アプリ生成時点では社内にいるが社外用アプリを生成することができる。

また、サーバ側では、アプリ送付後のユーザ状況を監視し、必要である場合にアプリ再編集する。端末へ送信後において、端末位置等のユーザ状況やアプリの操作状況（特に未回答時）を監視し、監視結果に応じてアプリの変更要否を決定することができる。また、端末アプリのプッシュ後にユーザの状況が変わった場合、アプリの再生成や再プッシュを行う。また、再生成の必要な状況変化があった時点で、再生成や再プッシュを行うこともできる。

なお、他のバリエーションとしては、再生成でなく、例えば差分データのみ転送してもよい。つまり、ユーザ状況やアプリ操作状況に合わせて、端末アプリを分割して配信することができる。例えば、アンケート必須入力項目と、追加的な入力項目とに分割して、それぞれ端末アプリを生成し直すことができる。また、本実施形態では、社内のみで作業可能な社外秘情報が含まれるアプリと、それ以外のアプリに分割することができる。

更に、生成時に調整に使用した予測使用時状況や現在状況を、想定状況として、通信端末１２の再調整要否判定手段に登録することで、想定状況から外れた場合に再調整が必要と判定することができる。

また、本実施形態では、使用されるタイミングを予測して、予測される状況に合わせて事前に調整を行っておくことにより、バッテリ消費を抑えることが可能である。例えば、調整時に入力履歴をアプリに埋め込む等の調整を行う場合には、使用されるタイミングの直前に調整を行う方がよい。

したがって、本実施形態を適用することで、ユーザは、アプリ使用時にその時点の状況に合わせたアプリをすぐに使える状態となる。また、状況変化が激しい場合でも、無駄な調整処理や端末アプリ転送を抑制することにより、通信コストやバッテリ消費を削減することができる。また、社外秘情報は、社外にいる間は端末内に保持されないため、情報漏洩を防止することができる。また、社内の場合は、端末内に保持されるため、使用開始時の転送待ち時間がなくなる。

また、サーバ上の配信ルールからの同じメソッド呼び出しでも、システムがユーザの状況に合わせて端末アプリ内容を調整するため、ユーザの状況に合わせた動作の開発を容易化できる。

以上、各実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、上記変形例以外にも種々の変形及び変更が可能である。

なお、以上の実施例に関し、更に以下の付記を開示する。
（付記１）
通信端末でアプリケーションを使用する時のユーザの状況を予測する使用時状況予測手段と、
前記使用時状況予測手段により予測される使用時状況と、前記通信端末から得られる前記ユーザの現在状況とに基づいて、前記アプリケーションの内容を調整する内容調整手段と、
前記内容調整手段により得られる調整済みアプリケーションを前記通信端末に配信するアプリ配信手段とを有することを特徴とする情報処理装置。
（付記２）
前記アプリ配信手段により前記調整済みアプリケーションを配信した前記通信端末から再調整要求を受け付け、受け付けた再調整要求に基づいて、前記アプリケーションを再生成させる再調整受付手段を有することを特徴とする付記１に記載の情報処理装置。
（付記３）
前記内容調整手段は、
前記通信端末の現在状況に応じて、前記アプリケーションにより前記通信端末の画面に表示される内容を変更することを特徴とする付記１又は２に記載の情報処理装置。
（付記４）
前記使用時状況予測手段は、
前記アプリケーションの過去に使用されたユーザ状況の頻度から得られるユーザ状況毎の相関度に基づいて、前記アプリケーションを使用する前記ユーザの使用時状況を予測することを特徴とする付記１乃至３の何れか１項に記載の情報処理装置。
（付記５）
所定の配信ルールを実行する配信ルール実行手段を有し、
前記配信ルール実行手段は、定期的又は状況変化時に取得される前記通信端末の現在状況が所定の条件を満たす場合に、前記アプリケーションを生成させることを特徴とする付記１乃至４の何れか１項に記載の情報処理装置。
（付記６）
サーバから配信されたアプリケーションに対する使用時のユーザ状況又は操作状況と、予め設定された前記アプリケーションの使用時の想定条件とに基づいて、前記アプリケーションの再調整の要否を判定する再調整要否判定手段と、
前記再調整要否判定手段により再調整が必要と判定されたアプリケーションの再調整を前記サーバに要求する再調整要求手段とを有することを特徴とする通信端末。
（付記７）
通信端末でアプリケーションを使用する時のユーザの状況を予測する使用時状況予測ステップと、
前記使用時状況予測ステップにより予測される使用時状況と、前記通信端末から得られる前記ユーザの現在状況とに基づいて、前記アプリケーションの内容を調整する内容調整ステップと、
前記内容調整ステップにより得られる調整済みアプリケーションを前記通信端末に配信するアプリ配信ステップとを有することを特徴とするアプリケーション提供方法。
（付記８）
サーバから配信されたアプリケーションに対する使用時のユーザ状況又は操作状況と、予め設定された前記アプリケーションの使用時の想定条件とに基づいて、前記アプリケーションの再調整の要否を判定する再調整要否判定ステップと、
前記再調整要否判定ステップにより再調整が必要と判定されたアプリケーションの再調整を前記サーバに要求する再調整要求ステップとを有することを特徴とするアプリケーション実行方法。
（付記９）
通信端末でアプリケーションを使用する時のユーザの状況を予測し、
予測される使用時状況と、前記通信端末から得られる前記ユーザの現在状況とに基づいて、前記アプリケーションの内容を調整し、
調整済みアプリケーションを前記通信端末に配信する、処理をコンピュータに実行させるためのアプリケーション提供プログラム。
（付記１０）
サーバから配信されたアプリケーションに対する使用時のユーザ状況又は操作状況と、予め設定された前記アプリケーションの使用時の想定条件とに基づいて、前記アプリケーションの再調整の要否を判定し、
再調整が必要と判定されたアプリケーションの再調整を前記サーバに要求する、処理をコンピュータに実行させるためのアプリケーション実行プログラム。

１０ アプリケーション提供システム
１１ アプリケーション提供サーバ
１２ 通信端末
１３ 通信ネットワーク
２１，６１ 入力手段
２２，６２ 出力手段
２３，６３ 記憶手段
２４ スケジュール管理手段
２５ 配信ルール実行手段
２６ アプリ生成手段
２７ アプリ配信手段
２８ 再調整受付手段
２９ 使用状況更新手段
３０，７０ 送受信手段
３１，７１ 制御手段
４１−１ 使用時状況予測手段
４１−２ 内容調整手段
５１，８１ 入力装置
５２，８２ 出力装置
５３，８３ ドライブ装置
５４，８４ 補助記憶装置
５５，８５ 主記憶装置
５６，８６ ＣＰＵ
５７，８７ ネットワーク接続装置
５８，９１ 記憶媒体
６４ センシング手段
６５ ユーザ状況把握手段
６６ アプリ実行手段
６７ アプリ操作状況把握手段
６８ 再調整要否判定手段
６９ 再調整要求手段
８８ ＧＰＳ
８９ 加速度センサ
９０ 角速度センサ

Claims (9)

1. 通信端末でアプリケーションを使用する時のユーザの状況を予測する使用時状況予測手段と、
   前記使用時状況予測手段により予測される使用時状況と、前記通信端末から得られる前記ユーザの現在状況とに基づいて、前記アプリケーションの内容を調整する内容調整手段と、
   前記内容調整手段により得られる調整済みアプリケーションを前記通信端末に配信するアプリ配信手段とを有することを特徴とする情報処理装置。
2. 前記アプリ配信手段により前記調整済みアプリケーションを配信した前記通信端末から再調整要求を受け付け、受け付けた再調整要求に基づいて、前記アプリケーションを再生成させる再調整受付手段を有することを特徴とする請求項１に記載の情報処理装置。
3. 前記内容調整手段は、
   前記通信端末の現在状況に応じて、前記アプリケーションにより前記通信端末の画面に表示される内容を変更することを特徴とする請求項１又は２に記載の情報処理装置。
4. 所定の配信ルールを実行する配信ルール実行手段を有し、
   前記配信ルール実行手段は、定期的に取得される前記通信端末の現在状況が所定の条件を満たす場合に、前記アプリケーションを生成させることを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
5. サーバから配信されたアプリケーションに対する使用時のユーザ状況又は操作状況と、予め設定された前記アプリケーションの使用時の想定条件とに基づいて、前記アプリケーションの再調整の要否を判定する再調整要否判定手段と、
   前記再調整要否判定手段により再調整が必要と判定されたアプリケーションの再調整を前記サーバに要求する再調整要求手段とを有することを特徴とする通信端末。
6. 通信端末でアプリケーションを使用する時のユーザの状況を予測する使用時状況予測ステップと、
   前記使用時状況予測ステップにより予測される使用時状況と、前記通信端末から得られる前記ユーザの現在状況とに基づいて、前記アプリケーションの内容を調整する内容調整ステップと、
   前記内容調整ステップにより得られる調整済みアプリケーションを前記通信端末に配信するアプリ配信ステップとを有することを特徴とするアプリケーション提供方法。
7. サーバから配信されたアプリケーションに対する使用時のユーザ状況又は操作状況と、予め設定された前記アプリケーションの使用時の想定条件とに基づいて、前記アプリケーションの再調整の要否を判定する再調整要否判定ステップと、
   前記再調整要否判定ステップにより再調整が必要と判定されたアプリケーションの再調整を前記サーバに要求する再調整要求ステップとを有することを特徴とするアプリケーション実行方法。
8. 通信端末でアプリケーションを使用する時のユーザの状況を予測し、
   予測される使用時状況と、前記通信端末から得られる前記ユーザの現在状況とに基づいて、前記アプリケーションの内容を調整し、
   調整済みアプリケーションを前記通信端末に配信する、処理をコンピュータに実行させるためのアプリケーション提供プログラム。
9. サーバから配信されたアプリケーションに対する使用時のユーザ状況又は操作状況と、予め設定された前記アプリケーションの使用時の想定条件とに基づいて、前記アプリケーションの再調整の要否を判定し、
   再調整が必要と判定されたアプリケーションの再調整を前記サーバに要求する、処理をコンピュータに実行させるためのアプリケーション実行プログラム。

Images