JP6050972B2 - 情報処理装置、情報通知方法及びプログラム - Google Patents

Description

本発明は、連係動作して機能を提供するアプリケーションの管理に関する。

動作上のつながりのある複数のソフトウェアを管理する技術として、特許文献１は、ソフトウェア同士の依存関係を規定したデータベースを参照し、依存関係にある一のソフトウェアが利用不可又は利用可能となる場合に、動作上の不具合が生じないように他のソフトウェアについて対処することを開示している。パッケージ管理システムなどと呼ばれるシステムでも、ソフトウェア同士の依存関係に応じたソフトウェア管理が行われることがある。また、ダイナミックリンクライブラリでは、複数のソフトウェアから参照される部品化されたプログラムが削除されようとした場合に、このプログラムの削除による動作上の不具合の発生を警告するメッセージが表示される。

特開２００５−４４０１１号公報

前述した技術はいずれも、ソフトウェア同士の相互の関係によって、各ソフトウェアについての対処の方法が定まるものである。これに対し、アプリケーションソフトウェア（以下、「アプリケーション」と省略する。）には、単独で動作して機能するもののほか、２以上のアプリケーションが連係動作して機能が提供されるものもある。電子メールの作成などを行うためのメールアプリと、カメラで撮影し写真画像を得るためのカメラアプリとが連係動作した場合、例えば、電子メールの作成中にカメラアプリを動作させて、そのときの撮影により得られた写真画像を電子メールに添付する、という機能が提供される。この種のアプリケーションを利用不可又は利用可能に変更（例えば、アンインストール又はインストール）する場合に、これと連係動作する他のアプリケーションについての対処（例えば、同時にアンインストール又はインストールする）が一律であると、ユーザにとって必要であった機能がユーザの知らぬ間に利用できなくなったり、ユーザにとって必要でなかった機能のアプリケーションが残って、例えばメモリを無駄に消費したりすることが考えられる。
そこで、本発明の目的は、アプリケーションを利用不可又は利用可能に変更する場合に、ユーザにとっての機能の必要性を加味して、連係動作する他のアプリケーションの情報を通知することである。

上述した課題を解決するため、本発明の情報処理装置は、自装置で利用可能なアプリケーションを動作させるアプリケーション動作部と、前記アプリケーション動作部が２以上のアプリケーションを連係動作させて提供される機能について、自装置のユーザによる利用履歴を取得する利用履歴取得部と、第１のアプリケーションを自装置で利用不可又は利用可能に変更する場合に、当該第１のアプリケーションについて前記利用履歴取得部が取得した利用履歴に基づいて、当該第１のアプリケーションと連係動作する第２のアプリケーションの情報をユーザに通知する通知部とを備えることを特徴とする。

本発明において、前記通知部は、自装置で前記第１のアプリケーションと連係動作したことのある前記第２のアプリケーションを通知対象としてもよい。
本発明において、前記通知部は、前記第１のアプリケーションと連係動作した時期が所定期間内に含まれる前記第２のアプリケーション、当該連係動作した回数が所定回数以上である前記第２のアプリケーション、又は、当該第１のアプリケーションプログラムと最後に連係動作した前記第２のアプリケーションを通知対象としてもよい。

また、本発明において、前記通知部による通知に対するユーザの応答を受け付ける応答受付部と、前記応答受付部が受け付けた応答に従って処理を実行する処理実行部とを備え、前記通知部は、前記第２のアプリケーションを自装置で利用不可又は利用可能のいずれとするかをユーザに問い合わせるための通知を行うようにしてもよい。

また、本発明において、前記連係動作するアプリケーションは、自身と連係動作する他のアプリケーションを示す情報を有しないようにしてもよい。
また、本発明において、前記連係動作に用いられるアプリケーションの動作を指定した動作要求に応じて、当該動作が可能なアプリケーションを特定する特定部を備え、前記アプリケーション動作部は、前記第１のアプリケーションを自装置で利用不可又は利用可能に変更する場合に、当該第１のアプリケーションに前記動作要求を行わせ、前記通知部は、前記第１のアプリケーションによる前記動作要求に応じて前記特定部により特定された前記第２のアプリケーションを通知対象としてもよい。

また、本発明において、前記通知部は、前記第１のアプリケーションを利用不可に変更する場合、前記第２のアプリケーションの単独動作が可能か否かに応じて異なる情報を通知するようにしてもよい。
また、本発明において、前記通知部は、前記第１のアプリケーションと連係動作せず、且つ、前記第２のアプリケーションと連係動作する第３のアプリケーションの情報を、ユーザに通知するようにしてもよい。

また、本発明の情報通知方法は、情報処理装置が、自装置で利用可能な２以上のアプリケーションを連係動作させて提供される機能について、自装置のユーザによる利用履歴を取得する利用履歴取得ステップと、前記情報処理装置が、第１のアプリケーションを自装置で利用不可又は利用可能に変更する場合に、当該第１のアプリケーションについて前記利用履歴取得ステップで取得した利用履歴に基づいて、当該第１のアプリケーションと連係動作する第２のアプリケーションの情報をユーザに通知する通知ステップとを有することを特徴とする。

また、本発明のプログラムは、自装置で利用可能なアプリケーションを動作させる情報処理装置のコンピュータに、前記情報処理装置が２以上のアプリケーションの連係動作を連係動作させて提供される機能について、前記情報処理装置のユーザによる利用履歴を取得する利用履歴取得ステップと、第１のアプリケーションを前記情報処理装置で利用不可又は利用可能に変更する場合に、当該第１のアプリケーションについて前記利用履歴取得ステップで取得した利用履歴に基づいて、当該第１のアプリケーションと連係動作する第２のアプリケーションの情報をユーザに通知する通知ステップとを実行させるためのプログラムである。

本発明によれば、アプリケーションを利用不可又は利用可能に変更する場合に、ユーザにとっての機能の必要性を加味して、連係動作する他のアプリケーションの情報を通知することができる。

ユーザ端末のハードウェア構成を示すブロック図。 利用履歴ＤＢの構成例を示す図。 メール作成画面を示す図。 ユーザ端末の制御部の機能構成を示す機能ブロック図。 ユーザ端末における処理の流れを示すフローチャート。 アプリケーションを通知する通知画面を示す図。 ユーザ端末の制御部の機能構成を示す機能ブロック図（変形例２）。 ユーザ端末における処理の流れを示すフローチャート（変形例２）。 アプリケーションを通知する通知画面を示す図（変形例３）。 アプリケーションを通知する通知画面を示す図（変形例４）。 ユーザ端末における処理の流れを示すフローチャート（変形例６）。 アプリケーションを通知する通知画面を示す図（変形例６）。

以下、図面を参照しつつ本発明の実施形態を説明する。
図１は、ユーザ端末１０のハードウェア構成を示すブロック図である。図１に示すように、ユーザ端末１０は、制御部１１と、操作部１２、通信部１３と、表示部１４と、記憶部１５とを備える。
制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ(Read Only Memory)及びＲＡＭ（Random Access Memory）を有するマイクロコンピュータを備える。ＣＰＵは、ＲＯＭや記憶部１５に記憶されたプログラムをＲＡＭに読み出して実行することにより、ユーザ端末１０の各部を制御する。操作部１２は、表示部１４の表示面に重ねて設けられたタッチスクリーンやハードボタンを有し、ユーザの操作を受け付ける。通信部１３は、無線通信回路やアンテナを有し、ネットワークに接続して通信するためのインタフェースである。表示部１４は、画像を表示する表示面を有し、この表示面に各種画面を表示する。

記憶部１５は、例えばＥＥＰＲＯＭ（Electronically Erasable and Programmable ROM）やフラッシュメモリなどの記憶装置を備え、制御部１１により実行されるアプリケーションを含む各種プログラムや、利用履歴ＤＢ１５１及びアプリケーション管理情報１５２を記憶する。本実施形態のアプリケーションは、例えば、他のアプリケーションと連係して動作するものを含むが、自身と連係する他のアプリケーションを示す情報を自身では有しない、疎結合なアプリケーションであるものとする。

利用履歴ＤＢ１５１は、２以上のアプリケーションが連係動作して提供される機能について、ユーザによる利用履歴を格納したデータベースである。連係動作とは、アプリケーションが単独で動作して提供される機能とは異なる機能を提供するために、２以上のアプリケーションがつながりをもって動作することをいう。アプリケーションの連係動作は、例えば、一のアプリケーションの動作中に、他のアプリケーションにはたらきかけて動作させる（例えば、起動させる）ことにより実現される動作である。以下の説明では、連係動作をはたらきかけるアプリケーションを「連係元アプリ」といい、このはたらきかけに応じて動作するアプリケーションを「連係先アプリ」という。
なお、連係動作は、これ以外にも、２以上のアプリケーションが同時に動作したり共通のパラメータを用いて動作したりすることにより、アプリケーションが単独で動作したときとは別の機能が提供される動作であればよい。よって、アプリケーション同士の動作上のつながり方は様々な態様がありうる。

図２は、利用履歴ＤＢ１５１の構成例を示す図である。図２に示すように、利用履歴ＤＢ１５１は、「連係元アプリ」と、「連係先アプリ」と、「利用履歴」という各情報を対応付けて格納したデータベースである。
「連係元アプリ」は、ユーザ端末１０において連係元アプリとなりうるアプリケーションを示す。図２において「（利用可能）」と記された連係元アプリは、ユーザ端末１０で利用可能なアプリケーションである。利用可能なアプリケーションは、具体的には、ユーザ端末１０の記憶部１５にインストール済みで、且つ、ユーザ端末１０で動作させることが許可されたアプリケーションである。このようなアプリケーションのことを、ユーザ端末１０において有効化されたアプリケーションという。一方で、図２には図示していないが、利用不可であるアプリケーションは、現時点で、ユーザ端末１０で利用できないアプリケーションであり、具体的には、ユーザ端末１０の記憶部１５にインストールされていない（アンインストール済みを含む。）か、又は、記憶部１５にインストール済みであるがユーザ端末１０で動作させることが許可されていないアプリケーション（つまり、無効化されたアプリケーション）である。ユーザ端末１０におけるアプリケーションの動作の許可又は不許可は、本実施形態では、ユーザが自由に設定変更できるものとする。アプリケーションの無効化は、バックグラウンドでのアプリケーションの動作によるリソースの消費の抑制などを目的として、例えばアプリケーションを一時的に利用不可にしておく場合に、ユーザにより設定される。

図２において、「連係先アプリ」は、ユーザ端末１０において連係先アプリとなりうるアプリケーションを示す。利用履歴ＤＢ１５１で対応付けられた連係元アプリと連係先アプリとは、ユーザ端末１０において連係動作することが可能である。「利用履歴」は、アプリケーションの連係動作により提供される機能のユーザによる利用履歴を示す。本実施形態の「利用履歴」は、「利用日時」と「利用回数」とを含む。「利用日時」は、機能が利用された日時を示し、例えばユーザにより連係先アプリの動作が指示された日時を示す（図２では、図中右側ほど新しい利用日時を示す）。「利用回数」は、機能が利用された回数を示し、ここではユーザにより機能が利用された総回数を示す。ユーザ端末１０では、連係動作により提供される機能が利用されるごとに、利用履歴ＤＢ１５１の利用履歴が更新される。

アプリケーション管理情報１５２は、ユーザ端末１０におけるアプリケーションの管理に関する情報である。アプリケーション管理情報１５２は、記憶部１５にインストール済みのアプリケーションを示す情報や、アプリケーション毎の有効化又は無効化の設定を示す情報などを含む。
以上の構成を有するユーザ端末１０は、ここではスマートフォンであり、図１に示す構成以外にも、撮影するためのカメラや音声の入出力を行うためのマイクロホン及びスピーカなど、通常のスマートフォンと共通の構成を有している。また、ユーザ端末１０は、スマートフォン以外の、例えばタブレット型コンピュータや携帯電話機、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）などの情報処理装置であってもよい。
次に、利用履歴ＤＢ１５１の構成を説明する。
ここで、図２に示したアプリケーションについて簡単に説明する。

「メールアプリ」は、メーラとしての機能を提供するもので、電子メールの作成や送信などの電子メールに関する処理を行うためのアプリケーションである。「電話帳アプリ」は、電話帳機能を提供するもので、登録されたユーザの名前や電子メールアドレス、電話番号などの情報を参照するためのアプリケーションである。「電話アプリ」は、電話を掛ける（つまり、音声通信を行う）ためのアプリケーションである。「カメラアプリＡ」及び「カメラアプリＢ」は、それぞれ、ユーザ端末１０が有するカメラを用いた撮影機能を提供し、撮影結果を示す写真画像を生成するためのアプリケーションである。「表示アプリ」は、メールアプリで送受信された電子メールを特定の表示態様（例えば、送受信相手毎の電子メールのやり取りの流れを表示する。）で表示するための表示機能を提供するアプリケーションである。「写真画像加工アプリ」は、カメラアプリＢを用いて得られた写真画像を加工するためのアプリケーションである。
なお、本実施形態では、カメラアプリＢ、表示アプリ及び写真画像加工アプリは、連係元アプリにはならないものとする。またカメラアプリＡ、表示アプリ及び写真画像加工アプリは、単独動作することはなく、メールアプリとの連係動作のみに利用されるアプリケーションである。前掲のそれ以外のアプリケーションは、単独動作もするアプリケーションである。

図３は、メールアプリの実行中に表示部１４に表示される画面を示す図である。図３（ａ）は、電子メールの作成中に表示されるメール作成画面ｓｃ１を示す図である。メール作成画面ｓｃ１は、作成中の電子メールを表示する領域と、各種操作を行うためのソフトボタンが複数配置された領域とを含む。メール作成画面ｓｃ１において、「アプリ」と記されたソフトボタンｂ１がユーザにより操作されると、メール作成画面ｓｃ１は図３（ｂ）に示す表示に変わる。このメール作成画面ｓｃ１は、メールアプリを連係元アプリとして連係動作することが可能なアプリケーションの一覧を示したウィンドウＷ１を含む。具体的に、ウィンドウＷ１には、アプリケーション管理情報１５２に基づいて、利用可能なアプリケーションのうち、メールアプリとの連係動作が可能な「電話帳アプリ」、「電話アプリ」、「カメラアプリＡ」、「カメラアプリＢ」及び「表示アプリ」と記されたソフトボタンｂ１１〜ｂ１５が配置されている。ユーザは、操作部１２の操作によりソフトボタンｂ１１〜ｂ１５のいずれかを選択して、連係先アプリを選択する。
ここで、連係動作により提供される機能について簡単に説明する。

まず、連係元アプリをメールアプリとした連係動作を説明する。連係先アプリを電話帳アプリとした場合、電子メールの送信先の電子メールアドレスを、電話帳アプリを用いて設定する機能が提供される。連係先アプリを電話アプリとした場合、電子メールの送信先として指定された相手に、電話アプリを用いて電話を掛ける機能が提供される（必要な電話番号は、例えば電話帳機能を用いて得られる）。連係先アプリを「カメラアプリＡ」とした場合、カメラアプリＡにより得られた写真画像を作成中の電子メールに添付する機能が提供される。連係先アプリを「カメラアプリＢ」とした場合、カメラアプリＢにより得られた写真画像を作成中の電子メールに添付する機能が提供される。連係先アプリを表示アプリとした場合、前述したように、メールアプリで送受信された電子メールを特定の表示態様で表示するための表示機能が提供される。
これ以外に、カメラアプリＡを連係元アプリとし、連係先アプリを写真画像加工アプリとすれば、カメラアプリＡで得られた写真画像を、写真画像加工アプリを用いて加工する機能が提供される。電話帳アプリや電話アプリが連係元アプリとなった場合にも、他のアプリケーションと連係動作することで、単独動作の場合とは別の機能が提供される。
次に、ユーザ端末１０の機能構成を説明する。

図４は、ユーザ端末１０の制御部１１の機能構成を示す機能ブロック図である。図４に示すように、ユーザ端末１０の制御部１１は、アプリケーション動作部１１１と、利用履歴更新部１１２と、利用履歴取得部１１３と、変更指示受付部１１４と、通知部１１５と、応答受付部１１６と、処理実行部１１７とに相当する機能を実現する。
アプリケーション動作部１１１は、ユーザ端末１０で利用可能なアプリケーションを記憶部１５から読み出し、読み出したアプリケーションを動作させる。アプリケーション動作部１１１は、アプリケーションを単独で動作させる場合もあれば、２以上のアプリケーションを連係動作させる場合もある。
利用履歴更新部１１２は、アプリケーション動作部１１１により行われたアプリケーションの連係動作に基づいて、利用履歴ＤＢ１５１を更新する。利用履歴更新部１１２は、連係動作が行われた連係元アプリと連係先アプリとに対応付けて、その利用日時を利用履歴ＤＢ１５１に格納するとともに利用回数を更新する（増加させる）。

利用履歴取得部１１３は、利用履歴ＤＢ１５１に格納された連係動作の利用履歴を取得する。
変更指示受付部１１４は、第１のアプリケーションをユーザ端末１０で利用不可又は利用可能に変更する変更指示を、操作部１２の操作によりユーザから受け付ける。

通知部１１５は、前述の第１のアプリケーションについて利用履歴取得部１１３が取得した利用履歴に基づいて、この第１のアプリケーションと連係動作する第２のアプリケーションの情報を、表示部１４の表示によりユーザに通知する。通知部１１５は、例えば、ユーザ端末１０で第１のアプリケーションと連係動作したことのある第２のアプリケーションを通知対象とする。ここにおいて、通知部１１５は、変更指示受付部１１４が第１のアプリケーションを利用不可（つまり、アンインストール又は無効化）にする変更指示を受け付けていた場合に、第２のアプリケーションをユーザ端末１０で利用不可又は利用可能のいずれとするかをユーザに問い合わせるための通知を行う。

応答受付部１１６は、通知部１１５による通知に対するユーザの応答を、ユーザの操作部１２の操作により受け付ける。
処理実行部１１７は、応答受付部１１６が受け付けたユーザからの応答に従って処理を実行する。処理実行部１１７は、例えば、直接は利用不可に変更することが指示されていない第２のアプリケーションについて、ユーザの応答に従って、利用不可としたりそのまま利用可能としたりするよう、アプリケーション管理情報１５２を更新したり、アプリケーションのアンインストールなどを行ったりする。

次に、ユーザ端末１０の動作を説明する。以下では、アプリケーションを利用不可にすることがユーザに指示された場合のユーザ端末１０の動作を説明するが、これとは別に、ユーザ端末１０の制御部１１は、連係動作により提供される機能の利用に応じて利用履歴ＤＢ１５１を更新したり、アプリケーション管理情報１５２を更新したりする。

図５は、アプリケーションを利用不可にすることがユーザに指示された場合のユーザ端末１０における処理の流れを示すフローチャートである。
ユーザ端末１０の制御部１１は、アプリケーションを利用不可に変更する変更指示を、操作部１２の操作によりユーザから受け付ける（ステップＳＡ１）。ここでは、制御部１１がメールアプリをアンインストールする変更指示（以下、「アンインストール指示」という。）を受け付けたものとする。

次に、制御部１１は、変更指示を受け付けたアプリケーションを連係元アプリとした場合の、連係先アプリがあるか否かを判断する（ステップＳＡ２）。制御部１１は、アプリケーション管理情報１５２を参照して、連係先アプリの有無を判断する。ここではメールアプリのアンインストール指示を受け付けたから、制御部１１は、ステップＳＡ２の処理で「ＹＥＳ」と判断し、ステップＳＡ３の処理に進む。
次に、制御部１１は、変更指示を受け付けたアプリケーションについての利用履歴を、利用履歴ＤＢ１５１から取得する（ステップＳＡ３）。ここでは、制御部１１は、メールアプリとの連係動作が可能な電話帳アプリ、電話アプリ、カメラアプリＡ、カメラアプリＢ及び表示アプリの利用履歴を取得する。

次に、制御部１１は、ステップＳＡ３で取得した利用履歴に基づいて、連係元アプリととともに利用不可の候補とする連係先アプリを、通知画面を表示部１４に表示させてユーザに通知する（ステップＳＡ４）。ここでは、制御部１１は、（Ｉ）連係動作で提供された機能の利用回数が閾値（例えば、１０回）以上であり、（II）現在日時から遡って所定期間内（例えば、過去２週間以内）にこの機能が利用され、且つ、（III）連係元アプリと最後に連係動作したアプリケーションを、連係先アプリとして通知対象とする。ここにおいて、（Ｉ），（II）及び（III）の条件を満たすアプリケーションは、「カメラアプリＢ」である。この（Ｉ），（II）及び（III）を通知の条件とすることで、連係元アプリをメールアプリとし、連係先アプリをカメラアプリＢとして提供される機能が、メールアプリを用いた連係動作により提供される機能として、ユーザによって最近最もよく利用されている機能と推測できる。一方、電話帳アプリ、電話アプリ、カメラアプリＡ及び表示アプリは、（Ｉ），（II）及び（III）のいずれかの条件を満たさないので、ここでは通知対象とならない。

図６は、メールアプリのアンインストール指示があった場合の通知画面ｓｃ２を示す図である。
図６に示すように、通知画面ｓｃ２は、アンインストールの候補とするアプリケーションの一覧を含み、各アプリケーションを利用可能又は利用不可のいずれとするかをユーザに問い合わせるための画面である。具体的に、通知画面ｓｃ２は、「メールアプリを削除すると、カメラアプリＢが使用できなくなります。以下の中から対処方法を選択してください。」というメッセージのほか、「メールアプリだけを削除する」と記されたソフトボタンｂ２１と、「メールアプリとカメラアプリＢの両方を削除する」と記されたソフトボタンｂ２２と、「メールアプリとカメラアプリＢの両方を削除しない」と記されたソフトボタンｂ２３を含むウィンドウＷ２を含む。

ユーザ端末１０が連係先アプリの情報を通知する理由は、変更指示を受け付けたアプリケーションのアンインストールにより、ユーザが知らないうちに、よく利用している連係動作による機能が利用できなくなってしまうことを回避し、また、連係動作に用いられるアプリケーションが無駄に記憶部１５に残ってしまうことを回避するためである。一方で、その他の機能については、ユーザにあまり利用されていない連係動作による機能が利用できなくなってしまっても、ユーザにおいて支障を来たす可能性が低いので、ここではその機能を通知対象としないようにしている。このようにユーザにより利用されないか、又は、ほとんど利用されていない連係先アプリについては通知対象とならない。これにより、ユーザに通知される情報の量が膨大になったり、ユーザが応答操作するべき操作量が過大になったりすることを回避できる。

ここでユーザは、自身が指示したアプリケーションのみをアンインストールしようとした場合は、「メールアプリだけを削除する」と記されたソフトボタンｂ２１を選択する。メールアプリのほか、このメールアプリとともに連係動作によりよく利用していたアプリケーションも同時にアンインストールしようとしたユーザは、「メールアプリとカメラアプリＢの両方を削除する」と記されたソフトボタンｂ２２を選択する。メールアプリをアンインストールしようとしたが、この連係動作による機能を今後も利用したいと考えたユーザは、「メールアプリとカメラアプリＢの両方を削除しない」と記されたソフトボタンｂ２３を選択する。

図５に戻って説明する。
制御部１１は、通知画面ｓｃ２におけるソフトボタンｂ２１〜ｂ２３のいずれかが選択されるまで待機し、いずれかを選択する操作を受け付けると、ステップＳＡ４の通知に対するユーザからの応答を受け付ける（ステップＳＡ５）。
次に、制御部１１は、通知画面ｓｃ２を用いたユーザからの応答に従った処理を実行する（ステップＳＡ６）。ここでは、制御部１１は、ソフトボタンｂ２１〜ｂ２３のうちの選択されたボタンに従って処理を実行する。ソフトボタンｂ２１が選択された場合、制御部１１は記憶部１５に記憶されたメールアプリをアンインストールする。ソフトボタンｂ２２が選択された場合、制御部１１は記憶部１５に記憶されたメールアプリ及びカメラアプリをアンインストールするとともに、ここでは、通知対象とならなかったアプリケーションのうち、連係元アプリとならず、且つ、単独で動作しないアプリケーション（ここでは、表示アプリ）も同時にアンインストールする。ソフトボタンｂ２３が選択された場合、制御部１１は、メールアプリ及びカメラアプリを含めアプリケーションのアンインストールしない。

ここにおいて、制御部１１は、ソフトボタンｂ２２が選択された場合、通知対象とならなかった表示アプリも自発的にアンインストールする。表示アプリは連係動作が利用されることが少ないので、メールアプリ及びカメラアプリＢをアンインストールするとユーザが考えた場合に、この表示アプリを用いた機能が利用できなくなることによる不都合は比較的少ないと推測できるからである。一方で、連係元アプリとなるか、又は、単独で動作するアプリケーションをアンインストールの対象としない理由は、今回アンインストールされる連係元アプリとの連係動作以外でも利用される可能性があるためであり、ユーザが知らないうちに必要なアプリケーションがアンインストールされるのを防ぐためである。
ところで、ステップＳＡ２の処理で、制御部１１が、連係先アプリが無いと判断した場合には（ステップＳＡ２；ＮＯ）、アンインストール指示を受け付けたアプリケーションのみをアンインストールする（ステップＳＡ７）。
以上が、ユーザ端末１０の動作の説明である。以上の説明では、ユーザ端末１０がアプリケーションのアンインストール指示を受け付けた場合の、連係元アプリ及び連係先アプリのアンインストールの手順を説明した。これに対し、ユーザ端末１０がアプリケーションを無効化する変更指示を受け付けた場合は、上述した説明における「アンインストール」や「削除」を、「無効化」と読み替えることにより説明することができる。また、ユーザ端末１０は、変更指示がアンインストール指示である場合に、連係元アプリについてはアンインストールするが、連係先アプリについては無効化に設定変更するなど、連係元アプリと連係先アプリとで、利用不可にする処理態様を異ならせてもよい。

以上説明した実施形態では、ユーザ端末１０は、連係元アプリを利用不可にすることが指示されると、その連係元アプリと連係動作する連係先アプリの利用履歴に応じて、その連係先アプリの対処の方法についてユーザに問い合わせる。これにより、例えばユーザがよく利用している連係動作により提供される機能をうっかり忘れていて、今後も使用した連係動作に関わるアプリケーションを誤って利用不可にしてしまう可能性を抑えられる。また、ユーザ端末１０によれば、連係先アプリが連係動作でしか利用できない場合に、連係元アプリのみがユーザの意図しないうちに残ってしまい、記憶部１５の記憶容量を無駄に消費することを防ぐこともできる。また、ユーザ端末１０は、ユーザにあまり利用されていないアプリケーションについて、ここでは通知対象としないので、通知画面においてユーザに強いられる操作負担が過大になることもない。

［変形例］
本発明は、上述した実施形態と異なる形態で実施することが可能である。本発明は、例えば、以下のような形態で実施することも可能である。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
（変形例１）
上述した実施形態では、ユーザ端末１０は、（Ｉ）連係動作で提供された機能の利用回数が閾値以上であり、（II）現在日時から遡って所定期間内にこの機能が利用され、且つ、（III）連係元アプリと最後に連係動作したアプリケーションを、連係先アプリとして通知対象としていたが、これ以外の条件に基づいて通知対象の連係先アプリを決定してもよい。
例えば、ユーザ端末１０は、（Ｉ）から（III）のいずれか１つ又は２つを満たすことを条件としてもよい。例えばユーザ端末１０は、現在日時から遡って所定期間内（例えば、過去１週間以内）に連係動作したことのみを条件とすれば、たとえ利用回数が少なくとも、最近になってユーザが利用しだした連係先アプリの情報を通知する（この場合、表示アプリが通知対象となる）。また、利用回数のみを通知条件とすれば、ユーザ端末１０は、過去によく利用している機能の情報を通知することとなる（この場合、電話帳アプリが通知対象となる）。また、最後に連係動作したことを条件としても、ユーザ端末１０は、たとえ利用回数が少なくとも、アプリケーション毎に最も近い時期に利用した連係先アプリの情報を通知することができる（この場合、カメラアプリＢが通知対象となる）。

また、ユーザ端末１０は、（Ｉ）から（III）に関する複数条件を用いた重みづけ演算により通知対象を決めてもよい。例えば、ユーザ端末１０は、連係動作した時期が近いほど重みづけを大きくし、連係動作した回数が多いほど重みづけを大きくし、また、アプリケーション毎に、より近い時期に利用した場合ほど重みづけを大きくして、予め決められた演算により重みづけ演算の結果を算出する。そして、ユーザ端末１０は、この演算結果に応じたアプリケーションを通知する。
なお、ユーザ端末１０は、前掲の利用履歴以外に、アプリケーションの利用頻度などの、ユーザの連係動作で提供される機能の利用度合いの高低を表す利用履歴を用いるようにしてもよい。

（変形例２）
上述した実施形態では、ユーザ端末１０は、連係元アプリと連係先アプリとの関係をアプリケーション管理情報１５２で保持していたが、連係元アプリと連係先アプリとの関係を記憶部１５で保持しない構成であってもよい。ユーザ端末１０は、例えば暗黙的インテントなどと呼ばれる手法を利用して、連係元アプリと連係先アプリとの関係を特定してもよい。要するに、ユーザ端末１０は、上述した実施形態のように、連係先アプリを直接指定することに代えて、“写真を撮る”、“電話を掛ける”などの、連係動作において連係先アプリに要求する動作を指示する（つまり、アプリケーションを間接的に指定するような態様である）。この場合、制御部１１は、連係元アプリにより動作要求に応じた動作が可能なアプリケーションを探し出して、ユーザにアプリケーションの選択肢を提示する。ユーザは提示された機能の中から実行したいものがあれば、その場でアプリケーションを呼び出して動作させることができる。
なお、本実施形態では、ユーザ端末１０は、連係元アプリと連係先アプリとの対応関係を規定するデータを保持していなくてもよい。

図７は、本変形例のユーザ端末１０の制御部１１の機能構成を示す機能ブロック図である。図７に示すように、ユーザ端末１０の制御部１１は、アプリケーション動作部１１１と、利用履歴更新部１１２と、利用履歴取得部１１３と、変更指示受付部１１４と、通知部１１５と、応答受付部１１６と、処理実行部１１７と、特定部１１８とに相当する機能を実現する。
特定部１１８は、第１のアプリケーションによる連係動作の要求に基づいて、この第１のアプリケーションと連係動作する第２のアプリケーションを特定する。
アプリケーション動作部１１１は、第１のアプリケーションを自装置で利用不可に変更する場合に、この第１アプリケーションにより連係動作の要求を行わせる。
通知部１１５は、特定部１１８により特定された第２のアプリケーションの情報を通知する。
ここで説明しなかった制御部１１の機能は、基本的には上述した実施形態と同じでよい。

図８は、アプリケーションを利用不可にすることがユーザに指示された場合の、ユーザ端末１０における処理の流れを示すフローチャートである。以下の説明で図５と同じ符号を付した処理ステップでは、同じ処理が実行されるので、ここではその説明を省略する。
ユーザ端末１０の制御部１１は、アプリケーションを利用不可にする変更指示を受け付けると（ステップＳＡ１）、このアプリケーションに連係動作の要求を行わせる（ステップＳＡ８）。そして、制御部１１は、ステップＳＡ８の処理で要求した連係動作が可能なアプリケーションを特定する（ステップＳＡ９）。ユーザ端末１０は、アプリケーションがインストールされたときに、このアプリケーションで実現可能な動作の情報を、例えばＯＳ（Operating System）の機能を利用して保持している。そして、制御部１１は、この情報に基づいて、連係動作が可能なアプリケーションを特定する。制御部１１は、この特定結果に応じた連係先アプリに基づいて、上述した実施形態と同様にして、ステップＳＡ２以降の処理を実行する。

この変形例によれば、ユーザ端末１０は、連係元アプリと連係先アプリとの対応関係を規定するアプリケーション管理情報１５２を保持したり、アプリケーション管理情報１５２に相当する情報を参照したりしなくてもよい。

（変形例３）
上述した実施形態において、ユーザ端末１０は、連係先アプリの単独動作が可能であるか否かに応じて、通知する情報を異ならせてもよい。例えば、連係先アプリの単独動作が可能であれば、ユーザがそのアプリケーションを連係動作で利用しなくとも、単独で利用する場合もあるので、ユーザの連係先アプリに対する対処方法に影響することがある。そこで、制御部１１は、ステップＳＡ４の処理で、図９に示す通知画面ｓｃ３を表示させることとなる。図９に示す通知画面ｓｃ３は、変更指示がアンインストール指示である場合の通知画面である。
図９に示すように、通知画面ｓｃ３は、「メールアプリを削除すると、カメラアプリＢが使用できなくなりますが、カメラアプリＢは単独で使用することもできます。以下の中から対処方法を選択してください。」というメッセージのほか、「メールアプリだけを削除する」と記されたソフトボタンｂ３１と、「すべてのアプリを削除する」と記されたソフトボタンｂ３２と、「すべてのアプリを削除しない」と記されたソフトボタンｂ３３を含むウィンドウＷ３を含む。ここでユーザは、今後も単独でカメラアプリＢを利用すると考えて、自身が指示したアプリケーションのみをアンインストールしようとした場合は、「メールアプリだけを削除する」と記されたソフトボタンｂ３１を選択する。メールアプリのほか、このメールアプリとともに単独でもカメラアプリＢを利用せず同時にアンインストールしようとしたユーザは、「メールアプリとカメラアプリＢの両方を削除する」と記されたソフトボタンｂ３２を選択する。メールアプリをアンインストールしようとしたが、この連係動作による機能を今後も利用したいと考えたユーザは、「すべてのアプリを削除しない」と記されたソフトボタンｂ３３を選択する。
なお、本変形例においても、制御部１１は、通知対象としなかったアプリケーションのうち、連係元アプリになりえないものは利用不可に変更してもよい。

この変形例によれば、ユーザが連係先アプリの単独動作ができることを知らないで、誤ってアプリケーションを利用不可にしてしまう可能性を抑制できる。
また、この変形例において、ユーザ端末１０は、アプリケーションの単独動作の利用履歴を利用履歴ＤＢ１５１などで管理し、この利用履歴に応じて、最近の利用度合いが一定レベル以上である場合に、単独動作に関する通知をしてもよい。また、ユーザ端末１０は、連係先アプリの単独動作が可能であれば、その旨の通知も含めて通知してもよい。

（変形例４）
上述した実施形態において、ユーザ端末１０は、変更指示のあった連係元アプリと連係動作する連係先アプリだけでなく、この連係先アプリを、連係元アプリとした場合の連係先アプリ（第３アプリケーション）の情報も通知してもよい。例えば、図３に示す写真画像加工アプリは、メールアプリとは連係動作しないものの、カメラアプリＡと連係動作するものである。よって、メールアプリのアンインストール指示によりカメラアプリＡがアンインストールされる場合には、これもアンインストールされることが好ましいと考えることもできる。

そこで、制御部１１は、ステップＳＡ４の処理においては、通知条件を満たした連係先アプリを連係元アプリとした場合の連係先アプリも、通知条件を満たすものとして扱い、通知対象とする。この場合、制御部１１は、図１０に示す通知画面をステップＳＡ４の処理で表示させることとなる。図１０に示す通知画面ｓｃ４は、変更指示がアンインストール指示である場合の通知画面である。
図１０に示すように、通知画面ｓｃ４は、「メールアプリを削除すると、カメラアプリＢと、カメラアプリＢで使用できる写真画像加工アプリが使用できなくなります。以下の中から対処方法を選択してください。」というメッセージのほか、「メールアプリだけを削除する」と記されたソフトボタンｂ４１と、「すべてのアプリを削除する」と記されたソフトボタンｂ４２と、「すべてのアプリを削除しない」と記されたソフトボタンｂ４３を含むウィンドウＷ４を含む。ここでユーザは、自身が指示したアプリケーションのみをアンインストールしようとした場合は、「メールアプリだけを削除する」と記されたソフトボタンｂ４１を選択する。メールアプリのほか、このメールアプリとともに連係動作によりよく利用していたアプリケーションも同時にアンインストールしようとしたユーザは、「すべてのアプリを削除する」と記されたソフトボタンｂ４２を選択する。メールアプリをアンインストールしようとしたが、この連係動作による機能を今後も利用したいと考えたユーザは、「すべてのアプリを削除しない」と記されたソフトボタンｂ４３を選択する。
なお、本変形例においても、ユーザ端末１０は、通知対象とならなかったアプリケーションのうち、連係元アプリになりえず、且つ、単独起動できないものは利用不可に変更してもよい。
この変形例のユーザ端末１０によれば、連係先の連係先といったアプリケーションで不要なものが記憶部１５に残ってしまう可能性を抑制できる。

（変形例５）
また、ユーザ端末１０は、通知対象とする連係先アプリの数を１つに限るのではなく、複数としてもよい。例えば、ユーザ端末１０は、最後に利用されたものに限らず、最近の所定回数に連係動作させた複数の連係先アプリ通知対象としてもよいし、所定期間内に利用されたすべてのアプリケーションを通知対象としてもよい。この場合、図６、図９及び図１０に示す通知画面ｓｃ４に相当する通知画面は、通知対象の各アプリケーションについての対処をユーザに問い合わせる内容となる。
また、ユーザ端末１０は、連係元アプリ毎に一部の連係先アプリだけを通知するのではなく、すべての連係先アプリを通知してもよい。
このようにユーザ端末１０は、連係先アプリの通知条件として、どのような条件を採用してもよいが、利用不可にする変更指示のあった連係元アプリと連係動作したことのある連係先アプリを通知対象とすることが好ましい。

（変形例６）
上述した実施形態では、ユーザ端末１０は、アプリケーションを利用不可にする変更指示を受け付けたときに、連係先アプリの情報を通知していたが、アプリケーションを利用可能に変更する（つまり、インストール又は有効化する）変更指示を受け付けたときに、連係先アプリの情報を通知してもよい。この変形例のユーザ端末１０の具体的な動作は、図１１に示すとおりである。

図１１は、アプリケーションを利用可能にすることがユーザに指示された場合のユーザ端末１０における処理の流れを示すフローチャートである。
ユーザ端末１０の制御部１１は、アプリケーションを利用可能に変更する変更指示を、操作部１２の操作によりユーザから受け付ける（ステップＳＢ１）。ここでは、制御部１１がメールアプリをインストールする変更指示（以下、「インストール指示」という。）を受け付けたものとする。

次に、制御部１１は、変更指示を受け付けたアプリケーションを連係元アプリとした場合の連係先アプリがあるか否かを判断する（ステップＳＢ２）。制御部１１は、例えば利用履歴ＤＢ１５１を参照して連係先アプリの有無を判断する。ここでは、メールアプリをインストールするインストール指示を受け付けたから、制御部１１はステップＳＢ２の処理で「ＹＥＳ」と判断し、ステップＳＢ３の処理に進む。
次に、制御部１１は、変更指示を受け付けたアプリケーションについての利用履歴を、利用履歴ＤＢ１５１から取得する（ステップＳＢ３）。ここでは、制御部１１は、メールアプリとの連係動作が可能な電話帳アプリ、電話アプリ、カメラアプリＡ、カメラアプリＢ及び表示アプリの利用履歴を取得する。

次に、制御部１１は、ステップＳＢ３で取得した利用履歴に基づいて、連係元アプリととともに利用可能の候補とする連係先アプリを、通知画面を表示部１４に表示させてユーザに通知する（ステップＳＢ４）。ここでは、制御部１１は、（Ｉ）連係動作で提供された機能の利用回数が閾値（ここでは、１０回）以上であり、（II）現在日時から遡って所定期間内（例えば、過去３ヶ月以内）に利用され、（III）連係元アプリと最後に連係動作したアプリケーションを、連係先アプリとしての通知対象とする。

図１２は、メールアプリを利用可能にする場合の通知画面を示す図である。
図１２に示すように、通知画面ｓｃ５は、利用可能に変更する候補のアプリケーションの一覧を含み、各アプリケーションを利用可能又は利用不可のいずれとするかをユーザに問い合わせるための画面である。具体的に、通知画面ｓｃ５は「メールアプリを追加すると、カメラアプリＢを使用できます。以下の中から対処方法を選択してください。」というメッセージのほか、「メールアプリを追加する」と記されたソフトボタンｂ５１と、「メールアプリを追加し、カメラアプリＢを有効化する」と記されたソフトボタンｂ５２とを含むウィンドウＷ５を含む。

ここで、（Ｉ）から（III）の条件を満たす連係先アプリの情報を通知する理由は、今回のアプリケーションのインストールにより、ユーザが以前によく利用していた連係動作による機能が利用できるように予め通知されるようにするためである。一方で、利用回数が閾値未満であるアプリケーション、現在日時から遡って所定期間内に利用されていないアプリケーション、又は、利用可能に変更するアプリケーションと最後に連係していないアプリケーションを通知しない理由は、ユーザがあまり利用していない機能が利用できるようになっても、ユーザのメリットは少なく、通知される情報が膨大になる可能性があるためである。このように、ユーザ端末１０は、ユーザにより利用されない、又は、ほとんど利用されていない連係先アプリについては通知対象としない。

図１２に戻って説明する。
制御部１１は、通知画面ｓｃ５におけるソフトボタンｂ５１又はｂ５２のいずれかが選択されるまで待機し、いずれかを選択する操作を受け付けると、ステップＳＢ４の通知に対するユーザからの応答を受け付ける（ステップＳＢ５）。
次に、制御部１１は、通知画面を介したユーザからの応答に従った処理を実行する（ステップＳＢ６）。ここでは、制御部１１は、ソフトボタンｂ５１〜ｂ５２の選択されたボタンに従って処理を実行する。ソフトボタンｂ５１が選択された場合、制御部１１は記憶部１５に記憶されたメールアプリをインストールする。ソフトボタンｂ５２が選択された場合、制御部１１はメールアプリをインストールし、且つ、無効化されていたカメラアプリＢを有効化する。

ところで、ステップＳＢ２の処理で、制御部１１が、連係先アプリが無いと判断した場合には（ステップＳＢ２；ＮＯ）、インストール指示を受け付けたアプリケーションをインストールする（ステップＳＢ７）。
また、以上の動作説明では、ユーザ端末１０がアプリケーションのインストール指示を受け付けた場合の連係元アプリ及び連係先アプリのインストールの手順を説明したが、ユーザ端末１０がアプリケーションを有効化に変更する変更指示を受け付けた場合、以上の説明のうち、アプリケーションの「追加」や「インストール」を「有効化」と読み替えることにより説明することができる。また、以上の動作説明では、ユーザ端末１０がアプリケーションを利用可能にする場合に、このアプリケーションを連係元アプリとしたときの連係先アプリを無効化から有効化に変更していた。これ以外にも、ユーザ端末１０は、例えば所定のサーバにアクセスするなどして、この連係先アプリをインストールすることができるのであれば、連係先アプリを記憶部１６にインストールしてから有効化してもよい。
なお、この変形例においても、ユーザ端末１０は、例えば、変形例（１）でも説明したような、様々な手法で通知対象の連係先アプリを決めてもよいし、変形例（２）のような動作要求を用いて連係先アプリを特定してもよく、利用不可に変更する場合の処理を適宜採用することができる。

（変形例７）
上述した実施形態において、ユーザ端末１０は、連係先アプリのうち連係元アプリ（例えば、電話帳アプリや電話アプリ）となりうるものや、単独動作が可能な連係先アプリ（例えば、カメラアプリＢ）については、連係元アプリを利用不可に変更するときの通知対象としないようにしてもよい。連係動作以外でも利用可能なアプリについては、様々な目的で利用される可能性があるので、必ずしも、連係アプリを利用不可にするときに同時に利用不可にすることが好ましいわけではないと考えられるからである。このようにすればユーザが必要なアプリケーションについての通知が増大することを抑えられる。
また、ユーザ端末１０は、利用履歴ＤＢ１５１を参照して連係元アプリとしての利用履歴や単独動作での利用履歴に基づいて、この通知の有無を判断してもよい。

（変形例８）
上述した実施形態において、ユーザ端末１０がアプリケーション管理情報１５２を記憶していたが、これに相当する情報を外部装置が記憶しており、ユーザ端末１０は通信部１３の通信により、この外部装置からアプリケーション管理情報を取得してもよい。
例えば、外部装置がアプリケーションを販売するなどして提供するサーバ装置であれば、提供したアプリケーションの情報をユーザ毎に保持していることがある。そこで、ユーザ端末１０は、このサーバ装置と通信してアプリケーション管理情報を取得すればよい。また、ユーザ端末１０は、自装置内で利用履歴ＤＢ１５１を記憶していなくてもよく、外部装置が記憶していてもよい。この場合、ユーザ端末１０は、連係動作による機能を利用する毎にその旨を外部装置に通知して、利用履歴ＤＢを更新させるとよい。

（変形例９）
上述した実施形態では、ユーザ端末１０はユーザによる変更指示に従って利用可能又は利用不可を変更していたが、この変更指示の受け付け以外の契機に変更してもよい。例えば、ユーザ端末１０は、あまり利用されなくなったアプリケーションを自動で判別して、このアプリケーションを利用不可に変更してもよい。また、ユーザ端末１０は、ユーザがよく利用する機能からお勧めのアプリケーションを推奨する場合に、このアプリケーションを利用可能に変更してもよい。このような契機に、ユーザ端末１０は、前述のような利用履歴に基づいた連係先アプリの情報を通知してもよい。

（変形例１０）
ユーザ端末１０が通知するアプリケーション（連係元アプリや連係先アプリ）の情報は、アプリケーションを利用不可又は利用可能のいずれとするかをユーザに問い合わせるものに限らない。ユーザ端末１０は、例えばアプリケーション名を表示するだけであってもよいし、利用履歴に応じてユーザがどの程度機能を利用しているかを通知するものであってもよい。このように、ユーザ端末１０は、変更指示を受け付けたアプリケーションを用いた連係動作の存在をユーザに知らしめるための通知を行えばよい。

（変形例１１）
上述した実施形態では、利用履歴ＤＢ１５１は、連係元アプリと連係先アプリとに対応付けて利用履歴を格納していたが、“電子メールの作成中の撮影により得た写真画像の添付”とか、“電子メールの送信先の電子メールアドレスを、電話帳アプリを用いて設定する”といったような、連係動作により提供される機能に対応付けて利用履歴を格納してもよい。このようにすれば、共通の機能が提供される連係動作の種類（言い換えれば、アプリケーションの組み合わせ）が複数ある場合であっても、ユーザ端末１０は、連係動作により提供される機能毎の利用履歴を参照することができる。

（変形例１２）
上述した実施形態において、連係動作するアプリケーションはいわゆる疎結合なアプリケーションであるが、本発明において連係動作するアプリケーションは、少なくとも、他のアプリケーションと連係して動作することにより機能が提供されるものであればよい。
ユーザ端末１０の制御部１１が実現する各機能は、複数のプログラムの組み合わせによって実現され、又は、複数のハードウェア資源の協働によって実現されうる。
また、本発明の情報処理装置は、コンピュータや制御部１１が実行するプログラムや情報通知方法として把握することも可能である。

１０…ユーザ端末、１１…制御部、１１１…アプリケーション動作部、１１２…利用履歴更新部、１１３…利用履歴取得部、１１４…変更指示受付部、１１５…通知部、１１６…応答受付部、１１７…処理実行部、１１８…特定部、１２…操作部、１３…通信部、１４…表示部、１５…記憶部、１５１…利用履歴ＤＢ、１５２…アプリケーション管理情報

Claims (10)

1. 自装置で利用可能なアプリケーションを動作させるアプリケーション動作部と、
   前記アプリケーション動作部が２以上のアプリケーションを連係動作させて提供される機能について、自装置のユーザによる利用履歴を取得する利用履歴取得部と、
   第１のアプリケーションを自装置で利用不可又は利用可能に変更する場合に、当該第１のアプリケーションについて前記利用履歴取得部が取得した利用履歴に基づいて、当該第１のアプリケーションと連係動作する第２のアプリケーションの情報をユーザに通知する通知部と
   を備えることを特徴とする情報処理装置。
2. 前記通知部は、
   自装置で前記第１のアプリケーションと連係動作したことのある前記第２のアプリケーションを通知対象とする
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記通知部は、
   前記第１のアプリケーションと連係動作した時期が所定期間内に含まれる前記第２のアプリケーション、当該連係動作した回数が所定回数以上である前記第２のアプリケーション、又は、当該第１のアプリケーションプログラムと最後に連係動作した前記第２のアプリケーションを通知対象とする
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記通知部による通知に対するユーザの応答を受け付ける応答受付部と、
   前記応答受付部が受け付けた応答に従って処理を実行する処理実行部と
   を備え、
   前記通知部は、
   前記第２のアプリケーションを自装置で利用不可又は利用可能のいずれとするかをユーザに問い合わせるための通知を行う
   ことを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
5. 前記連係動作するアプリケーションは、自身と連係動作する他のアプリケーションを示す情報を有しない
   ことを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
6. 前記連係動作に用いられるアプリケーションの動作を指定した動作要求に応じて、当該動作が可能なアプリケーションを特定する特定部を備え、
   前記アプリケーション動作部は、
   前記第１のアプリケーションを自装置で利用不可又は利用可能に変更する場合に、当該第１のアプリケーションに前記動作要求を行わせ、
   前記通知部は、
   前記第１のアプリケーションによる前記動作要求に応じて前記特定部により特定された前記第２のアプリケーションを通知対象とする
   ことを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
7. 前記通知部は、
   前記第１のアプリケーションを利用不可に変更する場合、前記第２のアプリケーションの単独動作が可能か否かに応じて異なる情報を通知する
   ことを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
8. 前記通知部は、
   前記第１のアプリケーションと連係動作せず、且つ、前記第２のアプリケーションと連係動作する第３のアプリケーションの情報を、ユーザに通知する
   ことを特徴とする請求項１から７のいずれか１項に記載の情報処理装置。
9. 情報処理装置が、自装置で利用可能な２以上のアプリケーションを連係動作させて提供される機能について、自装置のユーザによる利用履歴を取得する利用履歴取得ステップと、
   前記情報処理装置が、第１のアプリケーションを自装置で利用不可又は利用可能に変更する場合に、当該第１のアプリケーションについて前記利用履歴取得ステップで取得した利用履歴に基づいて、当該第１のアプリケーションと連係動作する第２のアプリケーションの情報をユーザに通知する通知ステップと
   を有することを特徴とする情報通知方法。
10. 自装置で利用可能なアプリケーションを動作させる情報処理装置のコンピュータに、
    前記情報処理装置が２以上のアプリケーションの連係動作を連係動作させて提供される機能について、前記情報処理装置のユーザによる利用履歴を取得する利用履歴取得ステップと、
    第１のアプリケーションを前記情報処理装置で利用不可又は利用可能に変更する場合に、当該第１のアプリケーションについて前記利用履歴取得ステップで取得した利用履歴に基づいて、当該第１のアプリケーションと連係動作する第２のアプリケーションの情報をユーザに通知する通知ステップと
    を実行させるためのプログラム。

Images