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

Abstract

【課題】複数のアプリケーションにおいて共通する画面に関する新規な表示機構を提供すること。【解決手段】情報処理装置は、第一のアプリケーションプログラムの起動の許否を判定する判定部と、前記起動が許可されない場合に、前記第一のアプリケーションプログラムに対して、起動が許可されないことを示す第一の画面の表示を要求し、前記起動が許可される場合であって、所定の情報の出力が必要なときに、第二のアプリケーションプログラムに対して、前記情報を出力する第二の画面の表示を要求する要求部とを有する。【選択図】図４

Description

本発明は、情報処理装置、情報処理方法、及びプログラムに関する。

画面を介したユーザとの対話に応じて処理を実行する各種のアプリケーションにおいて、機能的に共通した画面が表示される場合が有る。

斯かる画面の一例として、或るアプリケーションの利用権限の無いユーザが、当該アプリケーションを起動しようとした場合に、利用権限の無いことをユーザに通知するために表示される画面が挙げられる。

また、各アプリケーションに利用期限が有る場合、各アプリケーションの起動時において、利用期限までの日数を通知する画面を表示することも考えられる。

上記のような、機能的に共通した画面は、例えば、ＯＳ（Operating System）やアプリケーションプラットフォーム等、アプリケーションに対して実行環境を提供するシステム（以下、単に「システム」という。）によって表示されれば、アプリケーションの開発工数を低減することができる。

但し、システムには、複数のアプリケーションや、他のプログラム等が依存するため、システムの改変は、一般的に影響範囲が広い。したがって、例えば、新たな画面の追加等に応じて、システムの改変が要求されるような機構は、望ましい機構であるとは言い難い。

一方で、アプリケーションごとに、上記のような画面の実装が必要とされる場合、アプリケーションの開発工数の増加、画面の統一性の欠如、ユーザが操作する画面の提供の遅れ等の影響が出るといった問題が発生する可能性が有る。

本発明は、上記の点に鑑みてなされたものであって、複数のアプリケーションにおいて共通する画面に関する新規な表示機構を提供することを目的とする。

そこで上記課題を解決するため、情報処理装置は、第一のアプリケーションプログラムの起動の許否を判定する判定部と、前記起動が許可されない場合に、前記第一のアプリケーションプログラムに対して、起動が許可されないことを示す第一の画面の表示を要求し、前記起動が許可される場合であって、所定の情報の出力が必要なときに、第二のアプリケーションプログラムに対して、前記情報を出力する第二の画面の表示を要求する要求部とを有する。

複数のアプリケーションにおいて共通する画面に関する新規な表示機構を提供することができる。

第一の実施の形態における情報処理システムの構成例を示す図である。 第一の実施の形態における情報処理装置のハードウェア構成例を示す図である。 第一の実施の形態における情報処理システムのソフトウェア構成例を示す図である。 通常アプリ及び画面制御アプリの機能構成例を示す図である。 第一の実施の形態において情報処理システムが実行する処理手順の一例を説明するためのシーケンス図である。 ユーザ情報記憶部の構成例を示す図である。 アプリ情報記憶部の構成例を示す図である。 利用制限画面の表示例を示す図である。 警告画面の表示例を示す図である。 第二の実施の形態において情報処理システムが実行する処理手順の一例を説明するためのシーケンス図である。 情報処理装置が機器の操作部として機能する例を説明するための図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態における情報処理システムの構成例を示す図である。図１に示される情報処理システム１において、一以上の情報処理装置１０と認証システム２０とは、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク（有線又は無線の別は問わない）を介して通信可能に接続されている。

情報処理装置１０は、ユーザによって利用されるアプリケーションプログラム（以下、単に「アプリケーション」という。）がインストールされるコンピュータ又は電子機器等である。情報処理装置１０の一例として、ＰＣ（Personal Computer）、タブレット型端末、スマートフォン、携帯電話、画像形成装置、プロジェクタ、テレビ会議システム、又はデジタルカメラ等が挙げられる。

認証システム２０は、情報処理装置１０のユーザについて、認証や各アプリケーションの利用権限の有無の判定等を行う、一以上のコンピュータである。但し、認証システム２０が有する機能は、いずれかの情報処理装置１０、又は各情報処理装置１０が有していてもよい。この場合、認証システム２０は、設置されなくてもよい。

図２は、第一の実施の形態における情報処理装置のハードウェア構成例を示す図である。図２の情報処理装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

情報処理装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って情報処理装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。

図３は、第一の実施の形態における情報処理システムのソフトウェア構成例を示す図である。図３において、情報処理装置１０は、プラットフォーム１１、及びプラットフォーム１１上で動作する複数のアプリケーション等を有する。これらは、ＣＰＵ１０４に所定の処理を実行させるプログラムである。

プラットフォーム１１は、アプリケーションの実行環境を提供する。プラットフォーム１１は、アプリケーションの起動及び停止の制御や、複数のアプリケーションに共通の機能の実行等を行う。当該共通の機能は、例えば、プラットフォーム１１が有するＡＰＩ（Application Program Interface）を介して、各アプリケーションから利用される。プラットフォーム１１は、また、情報処理装置１０へのユーザのログインの制御を行ってもよい。なお、プラットフォーム１１の一例として、ＯＳ（Operating System）が挙げられる。また、ＯＳ及びＪａｖａ（登録商標）仮想マシン等のアプリケーションプラットフォーム等が、プラットフォーム１１を構成してもよい。

本実施の形態において、情報処理装置１０のアプリケーションは、その役割に応じて、通常アプリ１２及びサービスアプリ１３に分類される。通常アプリ１２は、ユーザに対して機能を提供するアプリケーションである。すなわち、通常アプリ１２は、ユーザから直接利用されるアプリケーションである。図３において、Ａアプリ１２ａ及びＢアプリ１２ｂが、通常アプリ１２の一例として示されている。Ａアプリ１２ａ及びＢアプリ１２ｂのそれぞれの機能は、特定のものに限定されない。

サービスアプリ１３は、各通常アプリ１２から共通に利用されるサービスを提供するアプリケーションである。図３において、共通画面アプリ１３ａ及び画面制御アプリ１３ｂが、サービスアプリ１３の一例として示されている。共通画面アプリ１３ａは、各通常アプリ１２に対して共通の画面（以下、「共通画面」という。）の表示を実行するサービスアプリ１３である。斯かる共通画面の一例として、通常アプリ１２の利用に関して、何らかの通知（何らかの情報の出力）を行う画面が挙げられる。画面制御アプリ１３ｂの機能については、後述される。

一方、認証システム２０は、認証部２１、利用可否判定部２２、ユーザ情報記憶部２３、及びアプリ情報記憶部２４等を有する。認証部２１及び利用可否判定部２２は、認証システム２０を構成するコンピュータにインストールされたプログラムが当該コンピュータのＣＰＵに実行させる処理により実現される。ユーザ情報記憶部２３及びアプリ情報記憶部２４は、認証システム２０を構成する記憶装置を用いて実現可能である。

認証部２１は、例えば、情報処理装置１０にログインするユーザの認証を行う。利用可否判定部２２は、情報処理装置１０にログインしたユーザ（以下、「ログインユーザ」という。）について、通常アプリ１２の利用の可否（又は許否）等の判定を行う。ユーザ情報記憶部２３は、各ユーザの属性情報を記憶する。ユーザの属性情報には、当該ユーザの認証情報や、当該ユーザが利用権限を有する通常アプリ１２の識別情報等が含まれる。アプリ情報記憶部２４は、各通常アプリ１２の利用を制限するための情報を記憶する。本実施の形態では、各通常アプリ１２を利用可能な期間を示す情報が、アプリ情報記憶部２４に記憶される。但し、例えば、役職や所属部署等に応じて、利用の可否を異ならせたい場合、通常アプリ１２ごとに、利用が許可される又は利用が許可されない役職や所属部署等が、アプリ情報記憶部２４に記憶されてもよい。また、他の情報が、アプリ情報記憶部２４に記憶されてもよい。

各通常アプリ１２及び画面制御アプリ１３ｂの詳細について説明する。図４は、通常アプリ及び画面制御アプリの機能構成例を示す図である。

図４に示されるように、Ａアプリ１２ａ及びＢアプリ１２ｂ等の各通常アプリ１２は、メイン部１２１及びアプリテンプレート１２２等を有する。メイン部１２１は、当該通常アプリ１２に固有の処理が実行された部分である。すなわち、メイン部１２１は、当該通常アプリ１２の本来の機能を実現する部分である。

アプリテンプレート１２２は、各通常アプリ１２に共通の部分であって、予め雛型化されて実装されている部分である。例えば、各通常アプリ１２の開発者には、アプリテンプレート１２２のソースコードが配布されてもよいし、当該ソースコードがコンパイルされたオブジェクトコードが配布されてもよい。ソースコードが配布される場合、情報処理装置１０は、当該ソースコードの改竄の有無をチェックする機構が設けられることが望ましい。

アプリテンプレート１２２は、固定部１２２１及び変更部１２２２を含む。固定部１２２１は、各通常アプリ１２が有しているべき、外部（例えば、サービスアプリ１３）から呼び出し可能なインタフェースと、当該インタフェースに対する固定的な実装とを含む。固定的な実装とは、書き換えが禁止されている実装をいう。したがって、固定部１２２１は、複数の通常アプリ１２において共通の実装であるといえる。本実施の形態において、固定部１２２１は、共通画面の表示要求を受け付けるインタフェースと、当該表示要求に応じて共通画面を表示させるための実装とを含む。変更部１２２２は、固定部１２２１の一部をカスタマイズするための機構を提供する部分である。したがって、変更部１２２２において、固定部１２２１に関して、通常アプリ１２ごとに固有の変更を行うことができる。変更部１２２２は、例えば、固定部１２２１が表示させる共通画面の表示態様等を変更する。但し、変更部１２２２によってカスタマイズ可能な範囲は限られている。例えば、固定部１２２１に実装されている処理のうち、各ＵＩアプリが必ず実行すべき処理を、変更部１２２２において取り消すことはできない。

通常アプリ１２の実装に、オブジェクト指向プログラミングが利用される場合、変更部１２２２は、固定部１２２１のサブクラスであってもよい。この場合、サブクラス内において、固定部１２２１が表示させる画面のカスタマイズ処理が行われる。または、変更部１２２２は、固定部１２２１が、所定のタイミングで呼び出しを予定している所定の関数であってもよい。この場合、所定の関数内において、固定部１２２１が表示させる画面のカスタマイズ処理が行われる。または、変更部１２２２は、固定部１２２１が所定のタイミングで読み込むスクリプトファイルであってもよい。この場合、スクリプトファイル内に、固定部１２２１が表示させる画面のカスタマイズ処理を示すスクリプトが記述される。固定部１２２１は、当該スクリプトを解釈して、当該スクリプトに定義された内容を、画面に反映させる。または、変更部１２２２は、固定部１２２１が読み込む設定ファイルであってもよい。この場合、設定ファイル内には、例えば、画面の表示要素（表示部品）の各種属性に対して、値が設定される。例えば、ラベルのように、文字列を表示させる表示要素に対しては、文字列が設定される。固定部１２２１は、当該設定ファイルに設定された値を、画面に反映させる。

ところで、各通常アプリ１２が含む固定部１２２１の機能と、共通画面アプリ１３ａの機能とは、共通画面を表示させるといった点において共通している。但し、両者が表示させる共通画面には違いが有る。具体的には、固定部１２２１は、通常アプリ１２の利用の制限に強制力が必要な共通画面を表示させる。一方、共通画面アプリ１３ａは、斯かる強制力が不要な共通画面を表示させる。通常アプリ１２の利用の制限に強制力が必要な共通画面の一例として、当該共通画面が表示されている間において、ユーザは、当該通常アプリ１２を操作することができず、当該共通画面がクローズ（消去）されると、当該通常アプリ１２も終了してしまうような画面が挙げられる。一方、斯かる強制力が不要な共通画面の一例として、当該共通画面が表示されている間であっても、ユーザは、当該通常アプリ１２を操作することができ、当該共通画面が消去された後も、ユーザは、当該通常アプリ１２を利用できる画面が挙げられる。

このような利用制限の強制力の要否に応じて、共通画面の表示主体が異なる理由について説明する。プラットフォーム１１から見た場合、各通常アプリ１２と、共通画面アプリ１３ａとは、それぞれ独立した一つのアプリケーションである。したがって、各通常アプリ１２が表示させる画面と、共通画面アプリ１３ａが表示させる画面との間に優劣は無く、最上位に表示される画面又は操作対象とされる画面は、ユーザの操作によって切り替えられる。すなわち、共通画面アプリ１３ａが表示させる共通画面では、共通画面アプリ１３ａとは別のアプリケーションである通常アプリ１２のメイン画面等の操作を制限するのは困難である。一方、通常アプリ１２が表示させる共通画面であれば、当該通常アプリ１２の利用を制限するのは容易である。通常アプリ１２の固定部１２２１において、当該共通画面の表示後に、当該通常アプリ１２が終了されるように実装されていれば、ユーザは、当該共通画面が表示された場合、当該通常アプリ１２を利用することはできないからである。

なお、利用制限に対して強制力が不要である共通画面についても、各通常アプリ１２の固定部１２２１が表示するようにすることも可能である。但し、全ての種類の共通画面を各通常アプリ１２の固定部１２２１が表示することになると、固定部１２２１の実装規模は大きくなる。固定部１２２１の実装規模が大きくなればなるほど、各通常アプリ１２のデータサイズは大きくなり、メモリの使用量は増加する。そこで、本実施の形態では、共通画面アプリ１３ａが設けられているのである。すなわち、メモリの使用量の低下等の観点からは、出来るだけ、共通画面アプリ１３ａによって、各通常アプリ１２に共通な各種の画面が表示されるのが好ましいが、各通常アプリ１２の利用を制限させるための共通画面については、アプリテンプレート１２２の固定部１２２１によって表示させることで、利用制限に対する強制力を確保しようというわけである。

このように、通常アプリ１２の固定部１２２１と、共通画面アプリ１３ａとによって、共通画面の表示が行われる状況において、画面制御アプリ１３ｂは、上記の強制力の要否に応じて、通常アプリ１２の固定部１２２１と、共通画面アプリ１３ａとの呼び分けを行うといった責務を担う。斯かる責務を実現するため、画面制御アプリ１３ｂは、判定部１３１及び要求部１３２等を含む。判定部１３１は、起動対象として選択された通常アプリ１２について、起動の許否（許可されるか否か）を判定する。要求部１３２は、判定部１３１による判定結果に応じ、当該通常アプリ１２の固定部１２２１、又は共通画面アプリ１３ａに対して、共通画面の表示を要求する。すなわち、当該通常アプリ１２の起動が許可されない場合、画面制御アプリ１３ｂは、当該通常アプリ１２の固定部１２２１に対して、起動が許可されないことを示す共通画面の表示を要求する。当該通常アプリ１２の起動は許可されるが、ユーザに対して何らかの通知（所定の情報の出力）を行う必要が有る場合、画面制御アプリ１３ｂは、共通画面アプリ１３ａに対し、当該通知を示す（当該情報を出力する）共通画面の表示を要求する。

以下、情報処理システム１において実行される処理手順について説明する。図５は、第一の実施の形態において情報処理システムが実行する処理手順の一例を説明するためのシーケンス図である。図５の初期状態は、既に、プラットフォーム１１によって、ユーザが認証されている状態であるとする。認証は、例えば、次のように行われる。まず、プラットフォーム１１が表示装置１０６に表示させているログイン画面に、ユーザ名及びパスワードが入力される。プラットフォーム１１は、当該ユーザ名及びパスワードが指定された認証要求を認証システム２０に送信する。認証システム２０の認証部２１は、当該ユーザ名及びパスワードを、ユーザ情報記憶部２３に記憶されているユーザ名及びパスワードと照合することにより認証を行い、認証結果をプラットフォーム１１に返信する。認証に成功した場合、プラットフォーム１１は、初期画面（以下、「ホーム画面」）を表示装置１０６に表示させる。

例えば、ログインユーザによって、Ａアプリ１２ａの起動指示が情報処理装置１０に対して入力されると、Ａアプリ１２ａの固定部１２２１は、プラットフォーム１１より、起動指示が入力されたことを示す通知（起動通知）を受け取る（Ｓ１０１）。起動通知の形態は、例えば、イベント又はシグナル等である。すなわち、固定部１２２１には、起動通知を示すイベント又はシグナル等に対するコールバックが実装されている。なお、ログインユーザによる、通常アプリ１２の起動指示は、例えば、情報処理装置１０のホーム画面において表示されている、各通常アプリ１２のアイコンが選択させることにより入力されてもよい。

続いて、固定部１２２１は、当該コールバック内において、画面制御アプリ１３ｂに対して、共通画面の表示制御を要求する（Ｓ１０２）。なお、各アプリケーション間の通信については、プロセス間通信、イベント、又はシグナル等、公知の技術を利用して実現可能である。また、Ａアプリ１２ａの起動通知は、Ａアプリ１２ａの固定部１２２１を介してではなく、画面制御アプリ１３ｂに対して、直接伝達されるようにしてもよい。

続いて、画面制御アプリ１３ｂは、Ａアプリ１２ａの固定部１２２１が有するインタフェースを介して、起動待機画面の表示を当該固定部１２２１に要求する（Ｓ１０３）。当該要求に応じ、Ａアプリ１２ａの固定部１２２１は、起動待機画面を表示させる。起動待機画面とは、アプリケーションの起動までに時間を要する場合等に、フリーズしていないことをユーザに示すために、例えば、「しばらくお待ちください。」等のメッセージを表示させる共通画面である。

続いて、画面制御アプリ１３ｂの判定部１３１は、ログインユーザによる、Ａアプリ１２ａの利用の可否を、認証システム２０に問い合わせる（Ｓ１０４）。当該問い合わせには、ログインユーザのユーザ名と、Ａアプリ１２ａの識別情報（以下、「アプリＩＤ」という。）が指定される。

認証システム２０の利用可否判定部２２は、当該問い合わせに応じ、ユーザ情報記憶部２３及びアプリ情報記憶部２４を参照して、ログインユーザによるＡアプリ１２ａの利用権限の有無等を判定する。

図６は、ユーザ情報記憶部の構成例を示す図である。図６において、ユーザ情報記憶部２３は、ユーザごとに、ユーザ名、パスワード、所属部署、役職、及び利用可能アプリ等を記憶する。ユーザ名及びパスワードは、認証の際に利用される。所属部署及び役職は、ユーザの属性情報を構成する項目の一例である。利用可能アプリは、ユーザが利用権限を有する通常アプリ１２のアプリＩＤである。図６では、日本語によってアプリＩＤが示されているが、アプリＩＤは、アルファベットや数字等であってもよい。

ユーザ情報記憶部２３において、問い合わせに指定されたユーザ名に対応付けられて、問い合わせに指定されたアプリＩＤが、利用可能アプリの項目に記憶されている場合、利用可否判定部２２は、ログインユーザによるＡアプリ１２ａの利用権限は有ると判定する。一方、ユーザ情報記憶部２３において、問い合わせに指定されたユーザ名に対応付けられて、問い合わせに指定されたアプリＩＤが、利用可能アプリの項目に記憶されていない場合、利用可否判定部２２は、ログインユーザによるＡアプリ１２ａの利用権限は無いと判定する。

ログインユーザによるＡアプリ１２ａの利用権限が有ると判定された場合、利用可否判定部２２は、更に、アプリ情報記憶部２４を参照する。

図７は、アプリ情報記憶部の構成例を示す図である。図７において、アプリ情報記憶部２４は、各通常アプリ１２のアプリＩＤに対応付けて、利用可能期間を記憶する。利用可能期間は、各通常アプリ１２の利用が許可される期間を示す情報である。

利用可否判定部２２は、アプリ情報記憶部２４を参照して、現在日時が、Ａアプリ１２ａの利用可能期間内であるか否かを判定する。

利用可否判定部２２は、上記の判定の結果を含む応答を、画面制御アプリ１３ｂに返信する（Ｓ１０５）。当該応答には、ログインユーザによるＡアプリ１２ａの利用権限の有無を示す情報が含まれる。利用権限が有る場合、当該応答には、更に、現在日時からＡアプリ１２ａの利用可能期間の末尾までの残り日数を示す情報が含まれる。但し、現在日時が、Ａアプリ１２ａの利用可能期間外である場合、当該応答には、利用可能期間の期限切れを示す情報が含まれる。

画面制御アプリ１３ｂは、利用可否判定部２２からの応答を受信すると、当該応答の内容に応じて、処理を分岐させる。

当該応答に、ログインユーザにＡアプリ１２ａの利用権限が無いことを示す情報が含まれている場合、画面制御アプリ１３ｂの判定部１３１は、ログインユーザによるＡアプリの起動は許可されないことを判定する。そこで、画面制御部１３ｂの要求部１３２は、Ａアプリ１２ａの固定部１２２１が有するインタフェースを介して、利用制限画面の表示を、当該固定部１２２１に要求する（Ｓ１１１）。利用制限画面とは、共通画面の一つであり、通常アプリ１２の利用を制限させる（利用を許可しない）ために表示される画面である。

利用制限画面の表示要求に応じ、Ａアプリ１２ａの固定部１２２１は、Ａアプリ１２ａの変更部１２２２より、既定の利用制限画面に対する変更情報を取得する（Ｓ１１２、Ｓ１１３）。続いて、当該固定部１２２１は、利用制限画面を生成する（Ｓ１１４）。

続いて、画面制御アプリ１３ｂの要求部１３２は、起動待機画面のクローズを、Ａアプリ１２ａの固定部１２２１が有するインタフェースを介して、当該固定部１２２１に要求する（Ｓ１１５）。当該固定部１２２１は、起動待機画面をクローズする。また、当該起動待機画面のクローズに応じ、当該固定部１２２１は、ステップＳ１１４において生成した利用制限画面を表示装置１０６に表示させる（Ｓ１１６）。

図８は、利用制限画面の表示例を示す図である。図８において、利用制限画面５１０は、選択された通常アプリ１２の利用権限が無いことを示すメッセージ、及び確認ボタン５１１等を含む。なお、利用制限画面５１０等、アプリテンプレート１２２の固定部１２２１によって表示される共通画面は、例えば、アプリケーションモーダルダイアログとして生成される。アプリケーションモーダルダイアログとは、当該ダイアログの表示中において、当該ダイアログを表示したアプリケーションの操作が不能となるダイアログをいう。但し、アプリテンプレート１２２の固定部１２２１によって表示される共通画面は、システムモーダルダイアログであってもよい。システムモーダルダイアログは、当該ダイアログの表示中において、ＯＳ等の操作すらできなくなるダイアログをいう。したがって、利用制限画面５１０の表示前に、仮に、Ａアプリ１２ａのメイン部１２１によって、Ａアプリ１２ａのメイン画面が表示されていたとしても、利用制限画面５１０の表示中において、ログインユーザは、当該メイン画面を介してＡアプリ１２ａを利用することはできない。

続いて、ログインユーザによって、利用制限画面５１０の確認ボタン５１１が押下されると（Ｓ１１７）、Ａアプリ１２ａの固定部１２２１は、Ａアプリ１２ａのプロセス又はスレッドを終了させる（Ｓ１１８）。すなわち、当該固定部１２２１は、Ａアプリ１２ａの起動を中止させる。その結果、ログインユーザは、Ａアプリ１２ａを利用することはできない。

一方、利用可否判定部２２からの応答に、ログインユーザにＡアプリ１２ａの利用権限が有ることと、利用可能期間の期限切れであることを示す情報が含まれている場合、ステップＳ１２１〜Ｓ１２８において、ステップＳ１１１〜Ｓ１１８と同様の処理が実行される。この場合も、ログインユーザによるＡアプリ１２ａの利用を制限（禁止）しなければならないからである。但し、ログインユーザによるＡアプリ１２ａの利用を制限するために表示される共通画面としては、アプリ期限切れ画面が表示される。アプリ期限切れ画面は、例えば、アプリケーションの利用可能期間の期限切れであることを示すメッセージが表示される点を除いて、利用制限画面５１０と同様の画面（ダイアログ）でよい。

また、利用可否判定部２２からの応答に、ログインユーザにＡアプリ１２ａの利用権限が有ることと、Ａアプリ１２ａの利用可能期間の末尾までの残り日数を示す情報が含まれている場合、画面制御アプリ１３ｂの要求部１３２は、共通画面アプリ１３ａに対して、警告画面の表示を要求する（Ｓ１３１）。当該要求には、警告画面に表示させるメッセージ等、警告画面の表示内容を示す情報が含まれてもよい。警告画面とは、共通画面の一つであり、ユーザに何らかの情報を通知するための画面である。共通画面アプリ１３ａは、当該要求に応じ、警告画面を生成し、表示させる（Ｓ１３２）。

図９は、警告画面の表示例を示す図である。図９において、警告画面５２０は、選択されたアプリケーションの利用期限まで残り３日であることを示すメッセージ、及び確認ボタン５２１等を含む。なお、警告画面５２０は、モーダルダイアログでなくてもよいし、アプリケーションモーダルダイアログであってもよい。すなわち、共通画面アプリ１３ａによって表示される共通画面は、システムモーダルダイアログ以外であればよい。

続いて、画面制御アプリ１３ｂの要求部１３２は、Ａアプリ１２ａの固定部１２２１が有するインタフェースを介して、起動待機画面のクローズを、当該固定部１２２１に要求する（Ｓ１３３）。当該固定部１２２１は、当該要求に応じ、起動待機画面をクローズさせる。その後、Ａアプリ１２ａのメイン部１２１によってＡアプリ１２ａの本来の機能に関する処理が実行される。例えば、Ａアプリ１２ａのメイン画面が表示される。Ａアプリ１２ａのメイン画面が表示されている状態において、警告画面５２０が表示されたままであっても、Ａアプリ１２ａのメイン画面は操作可能である。

上述したように、第一の実施の形態によれば、通常アプリ１２の利用を制限させる必要が有る場合、画面制御アプリ１３ｂは、当該通常アプリ１２の固定部１２２１に対して共通画面の表示を要求する。ここで、固定部１２２１は、固定的に実装されている部分であり、各開発者による上書きが禁止されている部分である。したがって、画面制御アプリ１３ｂが予定している通り又は期待している通りの処理（例えば、共通画面の表示後に終了するといった処理）を、通常アプリ１２に実行させることができる。その結果、通常アプリ１２の利用制限を適切に実現することができる。また、予め、アプリテンプレート１２２が用意されることにより、各開発者の作業負担の軽減や、各共通画面の統一性の確保等を期待することができる。

また、通常アプリ１２の利用を制限させる必要が無い場合、画面制御アプリ１３ｂは、共通画面アプリ１３ａに対して共通画面の表示を要求する。共通画面アプリ１３ａによって表示される共通画面により、ユーザに通知すべき情報を、通常アプリ１２の利用を制限しない状態で通知することができる。また、共通画面の表示に関する実装が、共通画面アプリ１３ａに集約されることにより、メモリの消費量の増加の抑制、共通画面アプリ１３ａのバージョンアップによる各共通画面のバージョンアップの容易化、及び各共通画面の統一性の確保等を期待することができる。

このように、本実施の形態によれば、複数のアプリケーションにおいて共通する画面に関する新規な表示機構の提供を目的とする。

なお、通常アプリ１２の利用を制限させるために、共通画面アプリ１３ａが表示する共通画面を、システムモーダルダイアログとし、当該共通画面のクローズ時に、共通画面アプリ１３ａが、当該通常アプリ１２に対して、強制終了のシグナルを通知することも考えられる。但し、この場合、当該共通画面が表示されている間は、選択された通常アプリ１２以外の操作も行えなくなってしまい、情報処理装置１０全体の操作性を劣化させる可能性が有る。また、通常アプリ１２が強制終了されることにより、通常アプリ１２は、終了化処理を正常に行うことができず、通常アプリ１２の動作の不安定化を招く可能性が考えられる。したがって、通常アプリ１２の利用を制限させるための共通画面は、本実施の形態のように、当該通常アプリ１２によって表示されるのが望ましいと考える。

なお、各通常アプリ１２の固定部１２２１は、必ずしもアプリテンプレート１２２といった形態で配布されなくてもよい。例えば、各通常アプリ１２が実装すべきインタフェースが規定され、固定部１２２１に相当する部分の実装は、各通常アプリ１２の開発者に委ねられてもよい。この場合、当該インタフェースに対する実装の自由度は高くなるため、変更部１２２２は必ずしも必要ではない。

また、本実施の形態では、通常アプリ１２の画面の表示に関する機構は、基本的に、アプリケーションによって実現されている。すなわち、本実施の形態は、プラットフォーム１１に対する依存度が低い。したがって、例えば、新たな共通画面の追加が必要となった場合、アプリテンプレート１２２又は共通画面アプリ１３ａを改変すればよく、プラットフォーム１１を改変する必要性は低下させることができる。

次に、第二の実施の形態について説明する。第二の実施の形態では第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でもよい。

第二の実施の形態では、アプリテンプレート１２２の変更部１２２２において、共通画面アプリ１３ａに対するカスタム情報についても、保持が可能とされる例について説明する。この場合、図５のステップＳ１３１に応じて、例えば、図１０に示されるような処理手順が実行されてもよい。

図１０は、第二の実施の形態において情報処理システムが実行する処理手順の一例を説明するためのシーケンス図である。図１０中、図５と同一ステップには同一ステップ番号を付している。

共通画面アプリ１３ａは、警告画面の表示要求に応じ（Ｓ１３１）、Ａアプリ１２ａの変更部１２２２より、警告画面のカスタム情報を取得する（Ｓ１４１、Ｓ１４２）。続いて、共通画面アプリ１３ａは、警告画面を生成し、表示させる（Ｓ１４３）。当該警告画面には、Ａアプリ１２ａの変更部１２２２より取得されたカスタム情報が反映される。例えば、異なるメッセージが表示されてもよい。

上述したように、第二の実施の形態によれば、共通画面アプリ１３ａが表示させる共通画面についても、通常アプリ１２ごとに、カスタマイズを行うことが可能となる。

なお、上記各実施の形態における情報処理装置１０は、画像形成装置やプロジェクタ等、操作部（操作パネル）を有する機器の操作部として機能してもよい。

図１１は、情報処理装置が機器の操作部として機能する例を説明するための図である。図１１において、機器３０は、情報処理装置１０と通信可能に接続される。機器３０と情報処理装置１０との通信は、例えば、ＵＳＢ（Universal Serial Bus）、近距離無線通信、又はＬＡＮ（有線又は無線の別は問わない）等のネットワークを介して行われる。情報処理装置１０が、機器３０等の操作部として機能する場合、タブレット型端末やスマートフォン等が情報処理装置１０として好適である。

情報処理装置１０は、例えば、機器３０の所定の位置（例えば、操作パネルが配置される位置）に固定されて設置される。したがって、情報処理装置１０及び機器３０とは、一台の装置として把握されてもよい。または、情報処理装置１０は、機器３０から取り外し可能（分離可能）であってもよい。情報処理装置１０が取り外された状態において、情報処理装置１０は、無線通信等を介して、機器３０の操作部として機能可能であってもよい。

なお、上記各実施の形態において、通常アプリ１２は、第一のアプリケーションプログラムの一例である。共通画面アプリ１３ａは、第二のアプリケーションプログラムの一例である。固定部１２２１は、共通部の一例である。変更部１２２２は、固有部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１ 情報処理システム
１０ 情報処理装置
１１ プラットフォーム
１２ 通常アプリ
１２ａ Ａアプリ
１２ｂ Ｂアプリ
１３ サービスアプリ
１３ａ 共通画面アプリ
１３ｂ 画面制御アプリ
２０ 認証システム
２１ 認証部
２２ 利用可否判定部
２３ ユーザ情報記憶部
２４ アプリ情報記憶部
３０ 機器
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
１２１ メイン部
１２２ アプリテンプレート
１３１ 判定部
１３２ 要求部
１２２１ 固定部
１２２２ 変更部
Ｂ バス

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

Claims (9)

1. 第一のアプリケーションプログラムの起動の許否を判定する判定部と、
   前記起動が許可されない場合に、前記第一のアプリケーションプログラムに対して、起動が許可されないことを示す第一の画面の表示を要求し、前記起動が許可される場合であって、所定の情報の出力が必要なときに、第二のアプリケーションプログラムに対して、前記情報を出力する第二の画面の表示を要求する要求部とを有する情報処理装置。
2. 前記第一のアプリケーションプログラムは、複数の前記第一のアプリケーションプログラムに対して共通に実装される共通部を含み、
   前記要求部は、前記起動が許可されない場合に、当該起動に係る前記第一のアプリケーションプログラムの前記共通部に対して、前記第一の画面の表示を要求し、
   前記共通部は、前記第一の画面の表示と、前記起動の中止とを、当該情報処理装置に実行させる請求項１記載の情報処理装置。
3. 前記第一のアプリケーションプログラムは、前記共通部の一部に対して前記第一のアプリケーションごとに固有の変更を行う固有部を含み、
   前記固有部は、前記第一の画面の表示態様の変更を、当該情報処理装置に実行させる請求項２記載の情報処理装置。
4. 第一のアプリケーションプログラムの起動の許否を判定する判定手順と、
   前記起動が許可されない場合に、前記第一のアプリケーションプログラムに対して、起動が許可されないことを示す第一の画面の表示を要求し、前記起動が許可される場合であって、所定の情報の出力が必要なときに、第二のアプリケーションプログラムに対して、前記情報を出力する第二の画面の表示を要求する要求手順とを情報処理装置が実行する情報処理方法。
5. 前記第一のアプリケーションプログラムは、複数の前記第一のアプリケーションプログラムに対して共通に実装される共通部を含み、
   前記要求手順は、前記起動が許可されない場合に、当該起動に係る前記第一のアプリケーションプログラムの前記共通部に対して、前記第一の画面の表示を要求し、
   前記共通部は、前記第一の画面の表示と、前記起動の中止とを、前記情報処理装置に実行させる請求項４記載の情報処理方法。
6. 前記第一のアプリケーションプログラムは、前記共通部の一部に対して前記第一のアプリケーションごとに固有の変更を行う固有部を含み、
   前記固有部は、前記第一の画面の表示態様の変更を、前記情報処理装置に実行させる請求項５記載の情報処理方法。
7. 第一のアプリケーションプログラムの起動の許否を判定する判定手順と、
   前記起動が許可されない場合に、前記第一のアプリケーションプログラムに対して、起動が許可されないことを示す第一の画面の表示を要求し、前記起動が許可される場合であって、所定の情報の出力が必要なときに、第二のアプリケーションプログラムに対して、前記情報を出力する第二の画面の表示を要求する要求手順とを情報処理装置に実行させるプログラム。
8. 前記第一のアプリケーションプログラムは、複数の前記第一のアプリケーションプログラムに対して共通に実装される共通部を含み、
   前記要求手順は、前記起動が許可されない場合に、当該起動に係る前記第一のアプリケーションプログラムの前記共通部に対して、前記第一の画面の表示を要求し、
   前記共通部は、前記第一の画面の表示と、前記起動の中止とを、前記情報処理装置に実行させる請求項７記載のプログラム。
9. 前記第一のアプリケーションプログラムは、前記共通部の一部に対して前記第一のアプリケーションごとに固有の変更を行う固有部を含み、
   前記固有部は、前記第一の画面の表示態様の変更を、前記情報処理装置に実行させる請求項８記載のプログラム。

Images