JP2016086269A - 携帯端末およびその制御方法 - Google Patents

Abstract

【課題】アプリケーションが待機状態であることをユーザに通知するユーザインタフェースを備えた携帯端末において、ユーザの使い勝手を向上させる。【解決手段】アプリ実行部４０４は、複数のアプリを並行して実行可能に構成され、かつ、複数のアプリの実行画面の中から選択された１つのアプリの実行画面を、表示部４６の表示画面に表示させる。表示制御部４０６は、各複数のアプリが、処理の終了を待機している待機状態となった場合に、待機状態となったアプリの実行画面に待機画像を表示させる。通知制御部４１０は、アプリ実行部４０４が第１のアプリの実行画面を表示画面に表示させている場合において、第２のアプリが待機状態から復帰したときには、第２のアプリが待機状態から復帰したことを通知するように通知部４８を制御する。【選択図】図２

Description

この発明は、携帯端末およびその制御方法に関し、より特定的には、アプリケーションが処理の終了待ちの待機状態であることをユーザに通知するユーザインタフェースを備えた携帯端末およびその制御方法に関する。

携帯電話やスマートフォンなどの携帯端末においては、アプリケーションが処理の終了待ちの待機状態であることをユーザに通知するユーザインタフェースを備えたものがある。

たとえば特開２００２−２６１９２２号公報（特許文献１）には、Ｗｅｂサーバに情報を要求し、その応答としてＷｅｂサーバから送信される情報を受信し、当該情報をバックライト付きの表示パネルに表示する携帯電話機において、応答待ちの状態になったときにバックライトを消灯させるとともに、応答待ちが解消されたときにバックライトを点灯させる構成が開示されている。

特開２００２−２６１９２２号公報

上記の特許文献１には、Ｗｅｂサーバからの応答がなく、情報の受信を待っているときには表示パネルを照明せず、Ｗｅｂサーバから応答があり、情報を受信したときに表示パネルを照明するようにバックライトの点灯・消灯を制御することができるので、ユーザは、コンテンツ情報を受信するまでに時間がかかったとしても、受信内容を視認することができる、と記載されている（段落０００７参照）。

しかしながら、上記の特許文献１に記載される技術は、一度に起動できるアプリケーションの数が１つに限定されている携帯端末には有効であるが、スマートフォンのように、複数のアプリケーションを一度に起動することができる携帯端末には適応が難しいという課題があった。

本発明は、このような問題を解決するためになされたものであって、その目的は、アプリケーションが待機状態であることをユーザに通知するユーザインタフェースを備えた携帯端末において、ユーザの使い勝手を向上させることである。

この発明のある局面では、携帯端末は、表示画面を有する表示部と、ユーザからの操作を受け付ける入力部と、情報をユーザに通知する通知部と、複数のアプリケーションを並行して実行可能に構成され、かつ、複数のアプリケーションの実行画面の中から選択された１つのアプリケーションの実行画面を、表示画面に表示させるアプリケーション実行部と、アプリケーション実行部が第１のアプリケーションの実行画面を表示画面に表示させている場合において、第２のアプリケーションが待機状態から復帰したときには、第２のアプリケーションが待機状態から復帰したことを通知するように通知部を制御する通知制御部とを備える。

この発明の他の局面では、携帯端末の制御方法であって、携帯端末は、表示画面を有する表示部と、ユーザからの操作を受け付ける入力部と、情報をユーザに通知する通知部とを含む。携帯端末の制御方法は、複数のアプリケーションを並行して実行可能に構成され、かつ、複数のアプリケーションの実行画面の中から選択された１つのアプリケーションの実行画面を、表示画面に表示させるステップと、アプリケーション実行部が第１のアプリケーションの実行画面を表示画面に表示させている場合において、第２のアプリケーションが待機状態から復帰したときには、第２のアプリケーションが待機状態から復帰したことを通知するように通知部を制御するステップとを備える。

この発明によれば、アプリケーションが待機状態であることをユーザに通知するユーザインタフェースを備えた携帯端末において、ユーザの使い勝手を向上させることができる。

本発明の実施の形態に係る携帯端末が適用される通信システムの構成を示す図である。 携帯端末のハードウェア構成の一例を示す図である。 携帯端末のソフトウェア構成の一例を示す図である。 携帯端末の制御構成の一例を示す図である。 携帯端末が提供するユーザインタフェースの一例を示す図である。 テーブルの一例を示す図である。 通知制御部による通知制御処理が実行されたときの表示画面の遷移の一例を示す図である。 通知制御部による通知制御処理が実行されたときの表示画面の遷移の一例を示す図である。 通知制御部による通知制御処理が実行されたときの表示画面の遷移の一例を示す図である。 通知制御部による通知制御処理が実行されたときの表示画面の遷移の一例を示す図である。 通知制御部による通知制御処理が実行されたときの表示画面の遷移の一例を示す図である。 通知制御部による通知制御処理が実行されたときの表示画面の遷移の一例を示す図である。 本実施の形態に係る携帯端末における通信制御処理の流れを示すフローチャートである。 本実施の形態に係る携帯端末における通信制御処理の流れを示すフローチャートである。 本実施の形態に係る携帯端末における通信制御処理の流れを示すフローチャートである。

以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、以下図中の同一または相当部分には同一符号を付して、その説明は原則的に繰返さないものとする。

図１は、本発明の実施の形態に係る携帯端末が適用される通信システムの構成を示す図である。携帯端末の一実施の形態として、スマートフォンを想定するが、携帯電話、ＰＤＡ（Personal Digital Assistant）、タブレットＰＣ（Tablet PC）などの携帯端末であってもよい。

図１を参照して、本実施の形態に係る通信システムは、携帯端末１０と、サーバ５とにより構成されている。サーバ５は、アプリケーションを提供するサーバを含む。携帯端末１０は、その一つの面にタッチスクリーン１０８を備えている。

携帯端末１０は、ネットワークを介してサーバ５と通信可能に設けられている。なお、ネットワークを介さずに直接にサーバ５と通信する方式としてもよい。

図２は、携帯端末１０のハードウェア構成の一例を示す図である。図２を参照して、携帯端末１０は、主たる構成要素として、ＣＰＵ（Central Processing Unit）１００と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、記憶装置１０４と、通信ＩＦ（Interface）１０５と、電源回路１０６と、操作キー１０７と、タッチスクリーン１０８と、スピーカ１１４と、マイク１１６と、バイブレータ１１８とを備える。各構成要素は、データバスによって相互に接続されている。

ＣＰＵ１００は、プログラムを実行する。ＣＰＵ１００は、携帯端末１０の各部を統括的に制御する制御部を構成する。制御部の主な制御構成については、後述する。

ＲＯＭ１０２は、ＯＳ（Operating System）と、携帯端末１０で実行される制御プログラムとを不揮発的に格納する。ＲＡＭ１０３は、ＣＰＵ１００によるプログラムの実行により生成されたデータ、または入力装置を介して入力されたデータを揮発的に格納する。

記憶装置１０４は、たとえばフラッシュメモリなどの不揮発性メモリにより構成され、データを不揮発的に格納する。記憶装置１０４に格納されるデータは、携帯端末１０の各部を制御するためのプログラムの他、各種アプリケーション（たとえば、電話、電子メール、スケジュール管理、地図など）を含んでいる。本明細書では、「アプリケーション」を適宜「アプリ」と略す。

通信ＩＦ１０５は、サーバ５（図１）に対するデータの送信処理またはサーバ５から送信されたデータの受信処理を行なう。電源回路１０６は、商用電源などの外部電源から電圧の供給を受けて携帯端末１０の各部の電源電圧を生成する回路である。操作キー１０７は、携帯端末１０のユーザが主電源をオンまたはオフするためのキー（操作ボタン）を含む。

タッチスクリーン１０８は、各種のデータの表示とともに、ユーザの入力操作を受け付ける、表示一体型入力装置である。具体的には、タッチスクリーン１０８は、ディスプレイ１１０（表示部）とタッチパネル１１２（入力部）とにより構成される。ディスプレイ１１０は、画像を表示するための表示画面を含んでいる。

スピーカ１１４は、ＣＰＵ１００から出力されるデータを表わす音のデータを出力する。スピーカ１１４が出力する音データには、人間の発する音声の周波数帯域に含まれる音のデータ（音声データ）が含まれる。

マイク１１６は、外部からの音の入力を受け付ける。マイク１１６は、主に音声データの入力を受け付ける。マイク１１６は、入力された音声データをＣＰＵ１００へ出力する。

バイブレータ１１８は、ＣＰＵ１００から出力される信号に基づいて、予め定められた周波数で発振動作を実行する。

携帯端末１０における処理は、各ハードウェアおよびＣＰＵ１００により実行されるソフトウェアによって実現される。このようなソフトウェアは、記憶装置１０４に予め格納されている場合がある。また、ソフトウェアは、その他の記憶媒体に格納されて、プログラムプロダクトとして流通している場合もある。あるいは、ソフトウェアは、いわゆるインターネットに接続されている情報提供事業者によってダウンロード可能なプログラムプロダクトとして提供される場合がある。このようなソフトウェアは、読取装置によってその記憶媒体から読み取られて、あるいは通信ＩＦ１０５等を介してダウンロードされた後、実行可能なプログラムの形式で記憶装置１０４に一旦格納される。当該ソフトウェアは、ＣＰＵ１００によって記憶装置１０４から読み出され、実行可能なプログラムの形式でＲＡＭ１０３に格納される。ＣＰＵ１００はそのプログラムを実行する。

同図に示される携帯端末１０を構成する各構成要素は、スマートフォンの構成要素として一般的なものである。したがって、本実施形態の本質的な部分は、ＲＯＭ１０２、ＲＡＭ１０３および記憶装置１０４、記憶媒体に格納されたソフトウェア、あるいはネットワークを介してダウンロード可能なソフトウェアであるともいえる。

図３は、携帯端末１０のソフトウェア構成の一例を示す図である。図３を参照して、ＣＰＵ１００（図２）で実行されるソフトウェアは、ＯＳ２２と、複数のアプリ３０＿１〜３０＿ｎ（ｎは２以上の整数）とを含む。

複数のアプリ３０＿１〜３０＿ｎは、特定の作業の目的に応じて任意に作成されたプログラムであり、サーバ５＿１〜５＿ｎからそれぞれ提供される。

ＯＳ２２は、ＣＰＵ１００が複数のアプリ３０＿１〜３０＿ｎの各々を実行するための基本的な実行環境を提供する。ＯＳ２２およびハードウェア２４は、複数のアプリ３０＿１〜３０＿ｎを動作させるために必要な基盤として機能するプラットフォーム２０を構成する。プラットフォーム２０は、複数のアプリ３０＿１〜３０＿ｎを同時に実行する際に、互いに独立して動作できるように、種々のユーザインタフェース（User Interface：ＵＩ）をユーザに提示する。

図４は、携帯端末１０の制御構成の一例を示す図である。図４を参照して、携帯端末１０は、制御部４０と、入力部４２と、通信部４４と、表示部４６と、通知部４８とを含む。図４に示す制御構成は、基本的には、携帯端末１０のＣＰＵ１００がメモリ（ＲＯＭ１０２、ＲＡＭ１０３および記憶装置１０４）に格納されたＯＳ２２およびアプリケーション３０＿１〜３０＿ｎを実行し、携帯端末１０の構成要素へ指示を与えることなどによって実現される。すなわち、ＣＰＵ１００は、携帯端末１０の動作を統括的に制御する制御部４０としての機能を有する。

入力部４２は、携帯端末１０に対するユーザからの操作を受け付ける。入力部４２は、主に、ＣＰＵ１００と操作キー１０７およびタッチパネル１１２とが連係して動作することで実現される。

通信部４４は、ネットワーク上の各種のサーバとの間で情報の送受信の処理を行なう。当該処理は、複数のアプリ３０＿１〜３０＿ｎをそれぞれ提供する複数のサーバ５＿１〜５＿ｎとの間でデータを送受信する処理を含む。通信部４４は、通信ＩＦ１０５により実現される。

表示部４６は、表示画面を有しており、制御部４０からの指示に基づいて情報を表示する。表示部４６は、タッチスクリーン１０８のディスプレイ１１０により実現される。

通知部４８は、制御部４０からの指示に基づいて情報をユーザに通知する。通知部４８は、ディスプレイ１１０、スピーカ１１４およびバイブレータ１１８の少なくともいずれかにより実現される。すなわち、通知部４８は、視覚的、聴覚的、触覚的またはこれらの組み合わせによって、情報をユーザに通知する。

制御部４０は、入力部４２を介してアプリを起動する指示を受け付けると、対応するアプリを起動する。その後、制御部４０は、ユーザからの各種指示に基づいてアプリを実行する。具体的には、制御部４０は、アプリ格納部４０２と、アプリ実行部４０４と、表示制御部４０６と、通知制御部４１０とを含む。

アプリ格納部４０２は、予めインストールされた１つ以上のアプリ３０＿１〜３０＿ｎを不揮発的に格納する。アプリ格納部４０２は、ＲＡＭ１０３あるいは記憶装置１０４で実現される機能である。

アプリ実行部４０４は、アプリ３０＿ｉ（ｉは１以上ｎ以下の整数）の起動指示を受け付けた場合に、アプリ格納部４０２に格納されたアプリ３０＿ｉを起動する。そして、アプリ実行部４０４は、ユーザからの各種指示に基づいてアプリ３０＿ｉを実行する。アプリ３０＿ｉの実行中、アプリ実行部４０４は、通信部４４を介して、アプリ３０＿ｉを提供するサーバ５＿ｉからデータを受信するとともに、サーバ５＿ｉへデータを送信する。

アプリ実行部４０４は、複数のアプリを並行して実行可能に構成されている。したがって、たとえば、電子メールのアプリ（メールアプリ）を実行している最中に、ユーザは、Ｗｅｂページを閲覧するためのアプリ（ブラウザアプリ）を起動することができる。

ここで、スマートフォンなどの携帯端末においては、プラットフォームが、並行して動作する複数のアプリケーションにそれぞれ固有のウィンドウを割り当てる、いわゆるマルチウィンドウ表示機能を有していないものが多い。このマルチウィンドウ表示機能とは、従来、パソコンのプラットフォームなどで採用されている機能であって、画面上に複数のウィンドウが重畳しない状態で表示されている場合に、ユーザによる操作の対象となっているウィンドウ（アクティブウィンドウ）を画面の一番手前に表示させるものである。そして、アクティブウィンドウ以外のウィンドウ（非アクティブウィンドウ）を選択する操作をユーザが行なうことで、そのウィンドウをアクティブウィンドウに切り替えることができる。

一方、携帯端末の多くは、上記のようなマルチウィンドウ表示ができないため、並行して動作する複数のアプリのうち、アクティブ状態になっている１つのアプリのみが表示画面を占有することになる。なお、「アクティブ状態」とは、表示部４６の表示画面に表示され、かつ、ユーザにより操作可能な状態をいう。具体的には、表示制御部４０６は、アクティブ状態のアプリの実行画面のみを、表示部４６の表示画面（ディスプレイ１１０）に表示させる。言い換えれば、アクティブ状態のアプリのみを可視状態とすることにより、ユーザは可視状態のアプリのみを操作することができる。

ここで、実行中のアプリが、処理の終了を待機している待機状態となった場合を考える。たとえば、アプリがサーバからの応答待ちである場合や、アプリが大量のデータを処理しているような場合には、処理に時間が掛かってしまうためにアプリが待機状態となる。このような場合、携帯端末１０のプラットフォーム２０は、その上で動作するアプリが待機状態であることをユーザに知らせるためのＵＩを提示する。

具体的には、表示制御部４０６は、図５に示すようなＵＩを表示部４６の表示画面（ディスプレイ１１０）に表示させる。図５は、携帯端末１０が提供するユーザインタフェースの一例を示す図である。図５を参照して、表示制御部４０６は、“Ｐｌｅａｓｅ Ｗａｉｔ・・・（お待ちください）”というメッセージを含む画像で構成されたＵＩを、表示部４６の表示画面の一番手前に表示（ポップアップ）させる。以下の説明では、図５に示すような、アプリの待機状態を示す画像からなるＵＩを、「待機画像」とも称する。

表示制御部４０６は、複数のアプリ３０＿１〜３０＿ｎ（図３）の各々に対応付けられたＵＩを表す情報であるＵＩ情報を表すテーブル４０８を有している。ＵＩ情報には図５に示すような待機画像が含まれている。図６は、テーブル４０８の一例を示す図である。図６を参照して、テーブル４０８において、アプリと、アプリの待機状態を示すＵＩである待機画像とが一対一の関係で対応付けられている。図６では、アプリ１には待機画像１が対応付けられ、アプリ２には待機画像２が対応付けられている。

図４に戻って、表示制御部４０６は、実行中のアプリが待機状態になった場合には、テーブル４０８（図６）を参照することにより、そのアプリに対応付けられる待機画像を特定する。そして、表示制御部４０６は、特定した待機画像をアプリの実行画面に表示させる処理を行なう。なお、表示制御部４０６は、待機状態になったアプリがアクティブ状態の場合には、その待機画像を表示させたアプリの実行画面を、表示部４６の表示画面に表示させるが、待機画像を表示させたアプリが非アクティブ状態の場合には、その待機画像を表示させたアプリの実行画面を、表示部４６の表示画面に表示させない。

表示制御部４０６はさらに、処理が終了することによってアプリが待機状態から復帰した場合には、アプリの実行画面から待機画像の表示を消去する処理を行なう。したがって、アプリの実行画面が表示部４６の表示画面に表示されている場合、すなわち、待機状態から復帰したアプリが未だアクティブ状態である場合には、ユーザは、待機画像の表示が消去されたことに基づいて、アプリが待機状態から復帰したことを確認することができる。

しかしながら、アクティブ状態のアプリが待機状態になった場合、すなわち、待機画像（図５）が表示部４６の表示画面に表示された場合において、ユーザは、アクティブ状態のアプリ以外のアプリ（非アクティブのアプリ）を選択する操作を行なうことが往々にしてある。このような場合、非アクティブのアプリがアクティブ状態に切り替わり、表示部４６の表示画面を占有することになる。すなわち、切り替え後のアプリの実行画面のみが可視状態となる。そのため、切り替え前のアプリの実行画面に表示された待機画像（図５）は非可視状態となってしまう。したがって、ユーザは最早待機画像の表示の有無に基づいて、アプリが待機状態から復帰したか否かを確認することが困難となる。その結果、ユーザは、アプリの実行画面を切り替える操作を行なうことで、切り替え前のアプリが待機状態から復帰したか否かを確認しなければならず、ユーザの手間が増えることになる。なお、携帯端末において同時に動作できるアプリの数が増えるに伴なって、ユーザの手間はさらに煩雑となるため、ユーザの使い勝手を低下させる虞がある。

したがって、本実施の形態に係る携帯端末１０では、アプリが待機状態となったときのユーザの手間を低減して使い勝手を向上させるために、通知制御部４１０は、通知部４８を用いて以下に説明するような通知を行なう。

具体的には、通知制御部４１０は、表示制御部４０６がアプリの実行状況に応じてアプリの実行画面に表示させる画像を監視している。表示制御部４０６が待機画像（図５）をアプリの実行画面に表示させたときには、通知制御部４１０は、テーブル４０８（図６）を参照することにより、この待機画像を基に待機状態となったアプリを特定する。さらに、通知制御部４１０は、この待機画像を監視することにより、特定したアプリが待機状態から復帰したか否かを判定する。詳細には、待機画像がアプリの実行画面に表示されている間は、通知制御部４１０は、アプリが待機状態中であると判定する。そして、アプリの実行画面から待機画像の表示が消去されたときに、通知制御部４１０は、アプリが待機状態から復帰したと判定する。この場合、通知制御部４１０は、アプリが待機状態から復帰したことを通知するように通知部４８を制御する。

以下、図７から図１２を参照して、通知制御部４１０が実行する通知制御処理について説明する。図７から図１２は、通知制御部４１０による通知制御処理が実行されたときの表示画面の遷移の一例を示す図である。

図７を参照して、アプリ実行部４０４においてアクティブとなるアプリが切り替えられた場合、表示制御部４０６は切り替え後のアプリの実行画面を表示画面（ディスプレイ１１０）に表示させる。図７では、ホームのアプリがアクティブとなっている例が示されている。

図７に示すように、ディスプレイ１１０に表示される画面は、ピクト領域ＲＰ、ウィンドウ領域ＲＷおよびキー領域ＲＫにより構成されている。ピクト領域ＲＰには、現在時刻、バッテリの残量を示す残量メータおよび電波の強度を示す強度メータ（ともに図示せず）、各種通知情報に対応する通知アイコンなどが表示される。

ウィンドウ領域ＲＷには、アクティブ状態のアプリの実行画面が表示される。たとえば、図７に示すように、ホームのアプリがアクティブ状態である場合、ウィンドウ領域ＲＷにホーム画面が表示される。ホーム画面には、電話、電子メールなどの各種アプリに対応する起動用アイコン１２０が配列される。

キー領域ＲＫには操作キー群１２２が表示される。操作キー群１２２は、各種設定を行なう設定画面をディスプレイ１１０に表示させるための設定キー１２２ａ、ディスプレイ１１０の表示を他の画面からホーム画面に移行させるためのホームキー１２２ｂ、および実行された処理を１ステップ前の処理に戻すためのバックキー１２２ｃから構成される。なお、実行されるアプリによっては、ピクト領域ＲＰおよびキー領域ＲＫの少なくとも１つが表示されず、表示されない領域までウィンドウ領域ＲＷが拡がる場合がある。

通知制御部４１０は、待機状態であるアプリを特定するための情報（以下「待機アプリ情報」とも称する）をディスプレイ１１０に一覧表示するための操作が行なわれたと判定すると、待機アプリ情報の一覧画面（図８参照）をディスプレイ１１０（ウィンドウ領域ＲＷ）に表示する。なお、一覧表示のための操作とは、たとえば、図７に示すように、ユーザがピクト領域ＲＰにタッチした指Ｆを下方に所定の距離以上スライドさせる操作である。

図８は、待機アプリ情報の一覧画面の一例を示す図である。図８に示すように、一覧画面には、待機アプリ情報に対応付けられた通知アイコン１３０，１３２，１３４が表示される。通知アイコン１３０，１３２，１３４の各々には、対応する待機アプリ情報に基づいて、待機状態のアプリの種類とともに「待機状態中」というメッセージが表示される。図８では、電子メールアプリ、カレンダーアプリ、およびブラウザアプリがそれぞれ待機状態である例が示されている。

なお、通知アイコン１３０，１３２，１３４の上方には、すべての通知アイコンを一覧画面から一括して消去するための消去用アイコン１３６が表示されている。この消去用アイコン１３６に対してユーザがシングルタップ操作を行なった場合、通知制御部４１０は、すべての通知アイコン１３０，１３２，１３４を一覧画面から消去する。通知制御部４１０はさらに、消去された通知アイコン１３０，１３２，１３４に対応する待機アプリ情報を、通知制御の対象から削除する。

あるいは、図９に示すように、複数の通知アイコン１３０，１３２，１３４のうちの１つの通知アイコン１３４を消去するための操作が行なわれた場合には、通知制御部４１０は、この通知アイコン１３４を一覧画面から消去する。なお、１つの通知用アイコンを消去するための操作とは、たとえば、図９に示すように、ユーザが、消去したい通知アイコン１３４にタッチした指Ｆを横方向（たとえば、左方向）に所定の距離以上スライドさせる操作である。図１０は、通知アイコン１３４を消去した後の一覧画面を示す図である。通知制御部４１０は、消去された通知アイコン１３４に対応する待機アプリ情報を通知制御の対象から削除する。

上記のように通知制御の対象から削除された待機アプリ情報については、通知制御部４１０は、待機状態から復帰した場合においても、アプリが待機状態から復帰したことを通知しないように通知部４８を制御する。図９では、ブラウザアプリの通知アイコン１３４が一覧画面から消去される例が示されている。したがって、この例では、ブラウザアプリが待機状態から復帰した際に、ブラウザアプリの復帰がユーザに通知されないことになる。これによれば、ユーザは、待機状態から復帰したことの通知が不要と判断するアプリに対しては、そのアプリに対応する通知アイコンを一覧画面から消去する操作を行なうことで、復帰の通知が行なわれないようにすることができる。

通知制御部４１０は、待機アプリ情報により特定されるアプリの各々について、アプリの実行画面上の待機画像を監視することにより、待機状態から復帰したか否かを判定する。アプリの実行画面から待機画像が消去されたことに基づいて、アプリが待機状態から復帰したと判定した場合には、通知制御部４１０は、アプリが待機状態から復帰したことを通知する。具体的には、図１１を参照して、通知制御部４１０は、待機アプリ情報の一覧画面において、待機状態から復帰したアプリに対応付けられる通知アイコン１３０に、「待機状態から復帰」というメッセージを表示する。図１１では、電子メールアプリが待機状態から復帰した例が示されている。したがって、ユーザは、この一覧画面を見ることで、アプリの実行画面を切り替える操作を行なうことなく、切り替え前のアプリが待機状態から復帰したことを確認することができる。

なお、待機アプリ情報の一覧画面の表示を終了する操作が行なわれた後、通知制御部４１０は、待機状態から復帰したアプリに対応する待機アプリ情報を通知制御の対象から削除する。一覧画面の表示を終了する操作とは、たとえば、ユーザがウィンドウ領域ＲＷにタッチした指を上方に所定の距離以上スライドさせる操作である。これにより、待機アプリ情報を一覧表示するための操作が再度行なわれたことに応答してディスプレイ１１０に表示される、待機アプリ情報の一覧画面では、復帰したアプリに対応する通知アイコン１３０が消去されている。このようにして、通知制御部４１０は、待機状態であるアプリケーションが待機状態から復帰するごとに、待機アプリ情報の一覧画面を更新する。

さらに、通知制御部４１０は、図１２に示すように、アクティブ状態のアプリの実行画面の一部分において、アプリが待機状態から復帰したことを通知するＵＩを表示させる。図１２では、電話アプリがアクティブ状態であるときに、電子メールアプリが待機状態から復帰した例が示されている。この例では、ウィンドウ領域ＲＷには、電話アプリの実行画面１３８が表示されるとともに、キー領域ＲＫには、電話アプリを実行するための操作キー群が表示される。そして、ピクト領域ＲＰにおいて、電子メールアプリが待機状態から復帰したことを通知するメッセージ（たとえば、“Ｅメール 待機状態から復帰”）からなるＵＩ１４０が表示されている。

なお、本例における通知制御部４１０は、アプリの実行画面のピクト領域ＲＰにＵＩ１４０を表示する構成について説明したが、特にこれに限られず、ウィンドウ領域ＲＷまたはキー領域ＲＫにＵＩ１４０を表示するようにしてもよい。

さらに、通知制御部４１０による通知の方法は、上記のようにＵＩに限られず、種々の方法を採用することが可能である。たとえば、スピーカ１１４（図２）を通じて「Ｅメール 待機状態から復帰」といった音声を出力するようにしてもよい。あるいは、バイブレータ１１８の振動機能を用いても通知してもよい。

以上説明したように、通知制御部４１０は、通信制御処理として、待機アプリ情報の一覧画面を表示する処理（図８〜図１１）、およびアクティブ状態のアプリの実行画面の一部分にＵＩを表示する処理（図１２）を実行する。なお、通知制御部４１０は、これら２つの処理を、各々単独で実行してもよいし、組み合わせて実行してもよい。このように、アプリが待機状態から復帰したことがユーザに通知されることにより、ユーザは、アクティブとなっているアプリ以外のアプリ（非アクティブのアプリ）が待機状態から復帰したか否かを容易に確認することができる。この結果、アプリが待機状態となったときのユーザの手間が低減されるため、ユーザの使い勝手を向上させることが可能となる。

なお、本実施の形態に係る携帯端末１０において、通知制御部４１０は、表示制御部４６がアプリの実行画面に表示させる画像を監視している。しかし、通知制御部４１０は、アプリ実行部４０４を介してアプリの実行状況を直接監視し、アプリが待機状態にあること、およびアプリが待機状態から復帰したことを判断してもよい。

図１３および図１４は、本実施の形態に係る携帯端末１０における通信制御処理の流れを示すフローチャートである。以下の各ステップは、ＣＰＵ１００がＲＯＭ１０２または記憶装置１０４に予め格納されるプログラムを実行することによって実現される。図１３および図１４のフローチャートに従う通知制御処理は、ＣＰＵ１００によって所定周期毎に繰り返し実行される。

図１３には、プラットフォーム２０側の処理のフローチャート（左側）と、アプリ３０＿１〜３０＿ｎ側の処理のフローチャート（右側）とが示されている。アプリ側の処理は、ＣＰＵ１００が実現する制御部４０のうち、主にアプリ実行部４０４および表示制御部４０６が連係して動作することにより実現される。プラットフォーム側の処理は、主に表示制御部４０６および通知制御部４１０が連係して動作することにより実現される。

図１３を参照して、アプリ側では、アプリの実行中、ＣＰＵ１００は、ステップＳ２１により、待機状態が発生したか否かを判定する。待機状態が発生していないと判定した場合（Ｓ２１のＮＯ判定時）、ＣＰＵ１００は処理を終了する。一方、待機状態が発生したと判定した場合（Ｓ２１のＹＥＳ判定時）には、ＣＰＵ１００は、ステップＳ２２により、アプリの実行画面に待機画像（図５）を表示する。このとき、ＣＰＵ１００は、図６のテーブルを参照することにより、待機状態となったアプリに対応付けられる待機画像を実行画面に表示させる。

ＣＰＵ１００は、ステップＳ２３により、待機状態のアプリが待機状態から復帰したか否かを判定する。待機状態から復帰していないと判定した場合（Ｓ２３のＮＯ判定時）、ＣＰＵ１００は処理を終了する。一方、待機状態から復帰したと判定すると（Ｓ２３のＹＥＳ判定時）、ＣＰＵ１００は、ステップＳ２４により、アプリの実行画面から待機画像を消去する。

プラットフォーム側では、複数のアプリが並行して実行されている場合において、ＣＰＵ１００は、ステップＳ０１により、これら複数のアプリのうちのアクティブとなっているアプリの実行画面を表示部４６の表示画面（ディスプレイ１１０）に表示させる。

ＣＰＵ１００は、ステップＳ０２により、複数のアプリのいずれかにおいて、アプリの実行画面に待機画像が表示されているか否かを判定する。いずれのアプリにおいても実行画面に待機画像が表示されていないと判定した場合（Ｓ０２のＮＯ判定時）、ＣＰＵ１００は処理を終了する。一方、複数のアプリのいずれかにおいて、アプリの実行画面に待機画像が表示されていると判定した場合（Ｓ０２のＹＥＳ判定時）には、ＣＰＵ１００は、ステップＳ０３に進み、図６のテーブルを参照することにより、待機画像に基づいて、待機状態となっているアプリを特定する。そして、ＣＰＵ１００は、特定したアプリを含めるように、待機アプリ情報を更新する。

ＣＰＵ１００は、ステップＳ０４により、待機状態となっているアプリの実行画面から待機画像が消去されたか否かを判定する。待機画像が消去されていないと判定した場合（Ｓ０４のＮＯ判定時）、ＣＰＵ１００は処理を終了する。一方、待機画像が消去されたと判定した場合（Ｓ０４のＹＥＳ判定時）には、ＣＰＵ１００は、ステップＳ０５に進み、図６のテーブルを参照することにより、消去した待機画像に基づいて、待機状態から復帰したアプリを特定する。そして、ＣＰＵ１００は、特定したアプリがアクティブ状態のアプリであるか否かを判定する。待機状態から復帰したアプリがアクティブ状態のアプリでない、すなわち、非アクティブのアプリであると判定した場合（Ｓ０５のＮＯ判定時）、ＣＰＵ１００は処理を終了する。

これに対して、待機状態から復帰したアプリがアクティブ状態のアプリであると判定した場合（Ｓ０５のＹＥＳ判定時）には、ＣＰＵ１００はステップＳ０６に進み、復帰したアプリに対応する待機アプリ情報を、通知制御の処理対象から削除する。

図１４は、プラットフォーム２０側において、図１３で示した処理に並行して実行される処理であって、通知制御処理の一態様として、待機アプリ情報の一覧画面を表示する処理の流れを示している。

図１４を参照して、ＣＰＵ１００は、ステップＳ１１により、待機アプリ情報をディスプレイ１１０に一覧表示させるための操作がなされたか否かを判定する。一覧表示させるための操作は、たとえば図７に示したように、ユーザがピクト領域ＲＰにタッチした指を下方に所定の距離以上スライドさせる操作である。

一覧表示させるための操作がなされたと判定すると（Ｓ１１のＹＥＳ判定時）、ＣＰＵ１００は、ステップＳ１２により、待機アプリ情報の一覧画面（図８参照）をディスプレイ１１０に表示する。一方、一覧表示させるための操作がなされていないと判定した場合（Ｓ１１のＮＯ判定時）、ＣＰＵ１００は処理を終了する。

ＣＰＵ１００は、ステップＳ１３により、待機状態となっているアプリの実行画面から待機画像が消去されたか否かを判定する。待機画像が消去されたと判定した場合（Ｓ１３のＹＥＳ判定時）には、ＣＰＵ１００は、ステップＳ１４に進み、図１３のステップＳ０５によって特定された待機状態から復帰したアプリについて、待機アプリ情報の一覧画面において、特定したアプリが待機状態から復帰したことを通知する（図１１参照）。ＣＰＵ１００はさらに、ステップＳ１５により、復帰したアプリに対応する待機アプリ情報を、通知制御の処理対象から削除する。

これに対して、ステップＳ１３において待機画像が消去されていないと判定した場合（Ｓ１３のＮＯ判定時）、ステップＳ１７に進み、一覧画面に表示される通知アイコンを消去するための操作がなされたか否かを判定する。通知アイコンを消去するための操作は、たとえば図９に示したように、ユーザが、消去したい通知アイコンにタッチした指を横方向に所定の距離以上スライドさせる操作である。または、消去用アイコン１３６をユーザがシングルタップする操作である。通知アイコンを消去するための操作がなされていないと判定した場合（Ｓ１７のＮＯ判定時）には、ＣＰＵ１００は処理をステップＳ１６に進める。

一方、通知アイコンを消去するための操作がなされたと判定すると（Ｓ１７のＹＥＳ判定時）、ＣＰＵ１００は、ステップＳ１８により、この通知アイコンに対応する待機アプリ情報を一覧画面から消去する（図１０参照）。ＣＰＵ１００はさらにステップＳ１９により、消去した待機アプリ情報を通知制御の対象から削除する。

ＣＰＵ１００は、ステップＳ１６により、待機アプリ情報の一覧表示を終了するための操作が行なわれたか否かを判定する。一覧表示を終了するための操作は、ユーザがウィンドウ領域ＲＷにタッチした指を上方に所定の距離以上スライドさせる操作である。一覧表示を終了するための操作がなされていないと判定すると（Ｓ１６のＮＯ判定時）、ＣＰＵ１００は処理をステップＳ１２に戻す。

一方、一覧表示を終了するための操作がなされたと判定した場合（Ｓ１６のＹＥＳ判定時）には、ＣＰＵ１００は、ディスプレイ１１０から一覧画面を消去する。これにより、ディスプレイ１１０には、一覧画面が表示される前の画面（図７参照）が表示される。

図１５は、本実施の形態に係る携帯端末１０における通信制御処理の流れを示すフローチャートである。図１５のフローチャートは、通知制御処理の一態様として、アクティブ状態のアプリの実行画面の一部分にＵＩを表示する処理の流れを示している。図１３および図１４のフローチャートと同様に、以下の各ステップは、ＣＰＵ１００がＲＯＭ１０２または記憶装置１０４に予め格納されるプログラムを実行することによって実現される。また、図１５のフローチャートに従う通知制御処理は、ＣＰＵ１００によって所定周期毎に繰り返し実行される。

図１５には、プラットフォーム２０側の処理のフローチャート（左側）と、アプリ３０＿１〜３０＿ｎ側の処理のフローチャート（右側）とが示されている。アプリ側の処理は、ＣＰＵ１００が、図１３と同様のステップＳ２１〜Ｓ２４により、アプリの実行中における待機状態の発生の有無に応じて、アプリの実行画面において待機画像の表示または待機画像の消去を行なう。

プラットフォーム側では、複数のアプリが並行して実行されている場合において、ＣＰＵ１００は、図１３と同様のステップＳ０１により、これら複数のアプリのうちのアクティブとなっているアプリの実行画面を表示部４６の表示画面（ディスプレイ１１０）に表示させる。

ＣＰＵ１００は、図１３と同様のステップＳ０２により、複数のアプリのいずれかにおいて、アプリの実行画面に待機画像が表示されているか否かを判定する。いずれのアプリにおいても実行画面に待機画像が表示されていないと判定した場合（Ｓ０２のＮＯ判定時）、ＣＰＵ１００は処理を終了する。一方、複数のアプリのいずれかにおいて、アプリの実行画面に待機画像が表示されていると判定した場合（Ｓ０２のＹＥＳ判定時）には、ＣＰＵ１００は、図１３と同様のステップＳ０３に進み、図６のテーブルを参照することにより、待機画像に基づいて、待機状態となっているアプリを特定する。ＣＰＵ１００は、特定したアプリを含めるように、待機アプリ情報を更新する。

ＣＰＵ１００は、図１３と同様のステップＳ０４により、待機状態となっているアプリの実行画面から待機画像が消去されたか否かを判定する。待機画像が消去されていないと判定した場合（Ｓ０４のＮＯ判定時）、ＣＰＵ１００は処理を終了する。一方、待機画像が消去されたと判定した場合（Ｓ０４のＹＥＳ判定時）には、ＣＰＵ１００は、図１３と同様のステップＳ０５に進み、図６のテーブルを参照することにより、消去した待機画像に基づいて、待機状態から復帰したアプリを特定する。そして、ＣＰＵ１００は、特定したアプリがアクティブ状態のアプリであるか否かを判定する。待機状態から復帰したアプリがアクティブ状態のアプリであると判定した場合（Ｓ０５のＹＥＳ判定時）、ＣＰＵ１００は処理を終了する。

これに対して、待機状態から復帰したアプリがアクティブ状態のアプリではない、すなわち、非アクティブのアプリであると判定した場合（Ｓ０５のＮＯ判定時）には、ＣＰＵ１００は、ステップＳ０７により、アクティブ状態のアプリの実行画面の一部分に、非アクティブのアプリが待機状態から復帰したことを通知するＵＩを表示させる（図１２参照）。

以上説明したように、本実施の形態に係る携帯端末によれば、アクティブとなっているアプリ以外のアプリ（非アクティブのアプリ）が待機状態から復帰したことが、待機アプリ情報の一覧表示、またはアプリの実行画面の一部分に表示されたＵＩを通じて、ユーザに通知される。これにより、ユーザは、非アクティブのアプリが待機状態から復帰したか否かを容易に確認することができる。この結果、アプリが待機状態となったときのユーザの手間が低減されるため、ユーザの使い勝手を向上させることが可能となる。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

５，５＿１〜５＿ｎ サーバ、１０ 携帯端末、２０ プラットフォーム、２２ ＯＳ、２４ ハードウェア、３０＿１〜３０＿ｎ アプリ、４０ 制御部、４２ 入力部、４４ 通信部、４６ 表示部、４８ 通知部、１００ ＣＰＵ、１０２ ＲＯＭ、１０３ ＲＡＭ、１０４ 記憶装置、１０５ 通信ＩＦ、１０６ 電源回路、１０７ 操作キー、１０８ タッチスクリーン、１１０ ディスプレイ、１１２、タッチパネル、１１４、スピーカ、１１６ マイク、１１８ バイブレータ、１２０ 起動用アイコン、１２２ 操作キー群、１３０，１３２，１３４ 通知アイコン、１３６ 消去用アイコン、１４０ ＵＩ、４０２ アプリ格納部、４０４ アプリ実行部、４０６ 表示制御部４０６ テーブル、４１０ 通知制御部、ＲＰ ピクト領域、ＲＷ ウィンドウ領域、ＲＫ キー領域。

Claims (14)

1. 表示画面を有する表示部と、
   ユーザからの操作を受け付ける入力部と、
   情報をユーザに通知する通知部と、
   複数のアプリケーションを並行して実行可能に構成され、かつ、前記複数のアプリケーションの実行画面の中から選択された１つのアプリケーションの実行画面を、前記表示画面に表示させるアプリケーション実行部と、
   前記アプリケーション実行部が第１のアプリケーションの実行画面を前記表示画面に表示させている場合において、第２のアプリケーションが待機状態から復帰したときには、前記第２のアプリケーションが待機状態から復帰したことを通知するように前記通知部を制御する通知制御部とを備える、携帯端末。
2. 各前記複数のアプリケーションが、処理の終了を待機している待機状態となった場合において、待機状態となったアプリケーションの実行画面に待機画像を表示させるように構成された表示制御部をさらに備え、
   前記通知制御部は、各前記複数のアプリケーションの実行画面に表示される前記待機画像を監視することにより、待機状態のアプリケーションが待機状態から復帰したか否かを判定する、請求項１に記載の携帯端末。
3. 前記通知部は、前記表示部の前記表示画面を含み、
   前記通知制御部は、前記第１のアプリケーションの実行画面が表示されている前記表示画面の一部分において、前記第２のアプリケーションが待機状態から復帰したことを通知するユーザインタフェースを表示させる、請求項１または２に記載の携帯端末。
4. 前記通知部は、前記表示部の前記表示画面を含み、
   前記通知制御部は、待機状態であるアプリケーションを特定するための特定情報の表示を促す操作を前記入力部が受け付けたことに基づいて、前記特定情報の一覧画面を前記表示画面に表示させる、請求項１または２に記載の携帯端末。
5. 前記通知制御部は、待機状態であるアプリケーションが待機状態から復帰するごとに、前記特定情報の一覧画面を更新する、請求項４に記載の携帯端末。
6. 前記通知制御部は、前記特定情報の一覧画面から前記特定情報を消去する操作を前記入力部が受け付けた場合には、前記消去された特定情報により特定されるアプリケーションが待機状態から復帰したことを通知しないように前記通知部を制御する、請求項４または５に記載の携帯端末。
7. 前記通知制御部は、前記第２のアプリケーションが待機状態から復帰したときには、前記特定情報の一覧画面において前記第２のアプリケーションの復帰を通知した後、前記第２のアプリケーションを前記特定情報の一覧画面から削除する、請求項４から６のいずれか１項に記載の携帯端末。
8. 携帯端末の制御方法であって、
   前記携帯端末は、表示画面を有する表示部と、ユーザからの操作を受け付ける入力部と、情報をユーザに通知する通知部とを含み、
   複数のアプリケーションを並行して実行可能に構成され、かつ、前記複数のアプリケーションの実行画面の中から選択された１つのアプリケーションの実行画面を、前記表示画面に表示させるステップと、
   第１のアプリケーションの実行画面を前記表示画面に表示させている場合において、第２のアプリケーションが待機状態から復帰したときには、前記第２のアプリケーションが待機状態から復帰したことを通知するように前記通知部を制御するステップとを備える、携帯端末の制御方法。
9. 各前記複数のアプリケーションが、処理の終了を待機している待機状態となった場合において、待機状態となったアプリケーションの実行画面に待機画像を表示させるステップをさらに備え、
   前記通知部を制御するステップは、各前記複数のアプリケーションの実行画面に表示される前記待機画像を監視することにより、待機状態のアプリケーションが待機状態から復帰したか否かを判定する、請求項８に記載の携帯端末の制御方法。
10. 前記通知部は、前記表示部の前記表示画面を含み、
    前記通知部を制御するステップは、前記第１のアプリケーションの実行画面が表示されている前記表示画面の一部分において、前記第２のアプリケーションが待機状態から復帰したことを通知するユーザインタフェースを表示させる、請求項８または９に記載の携帯端末の制御方法。
11. 前記通知部は、前記表示部の前記表示画面を含み、
    前記通知部を制御するステップは、待機状態であるアプリケーションを特定するための特定情報の表示を促す操作を前記入力部が受け付けたことに基づいて、前記特定情報の一覧を前記表示画面に表示させる、請求項８または９に記載の携帯端末の制御方法。
12. 前記通知部を制御するステップは、待機状態であるアプリケーションが待機状態から復帰するごとに、前記特定情報の一覧を更新する、請求項１１に記載の携帯端末の制御方法。
13. 前記通知部を制御するステップは、前記特定情報の一覧から前記特定情報を消去する操作を前記入力部が受け付けた場合には、前記消去された特定情報により特定されるアプリケーションが待機状態から復帰したことをユーザに通知しないように前記通知部を制御する、請求項１１または１２に記載の携帯端末の制御方法。
14. 前記通知部を制御するステップは、前記第２のアプリケーションが待機状態から復帰したときには、前記特定情報の一覧において前記第２のアプリケーションの復帰を通知した後、前記第２のアプリケーションを前記特定情報の一覧から削除する、請求項１１から１３のいずれか１項に記載の携帯端末の制御方法。

Images