JP2017211958A - アプリケーション統合装置およびアプリケーション統合装置の制御プログラム - Google Patents

Abstract

【課題】利便性を向上することのできるアプリケーション統合装置およびアプリケーション統合装置の制御プログラムを提供する。【解決手段】アプリケーション統合装置としてのＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）は、ＭＦＰにインストールされたアプリＤと技術的に統合可能なアプリであって、アプリＤがインストールされるよりも前にＭＦＰにインストールされたアプリＡを検索する。ＭＦＰは、アプリＤとアプリＡとを技術的に統合することが可能であるか否かを判別し、技術的に統合することが可能であると判別した場合に、アプリＤとアプリＡとの統合を許可するか否かを決定する。ＭＦＰは、この決定に従って、アプリＤとアプリＡとを統合する。【選択図】図５

Description

本発明は、アプリケーション統合装置およびアプリケーション統合装置の制御プログラムに関する。より特定的には、本発明は、新アプリケーションと旧アプリケーションとを統合するアプリケーション統合装置およびアプリケーション統合装置の制御プログラムに関する。

電子写真式の画像形成装置には、スキャナー機能、ファクシミリ機能、複写機能、プリンターとしての機能、データ通信機能、およびサーバー機能を備えたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）、ファクシミリ装置、複写機、プリンターなどがある。

ＭＦＰの中には、アプリケーションプラットフォームを有しており、そのアプリケーションプラットフォーム上で稼働するアプリケーション（以降、アプリケーションをアプリと記すことがある）のプログラムをインストールすることにより、ＭＦＰに新規機能を追加することのできるものがある。

ＭＦＰは、通常、複数のユーザーによって使用されるものである。このため、ＭＦＰには必要に応じて個々のユーザーやＭＦＰ管理者などによって様々なアプリがインストールされる。このため、類似した２つのアプリがＭＦＰにインストールされることがある。

類似した２つのアプリがＭＦＰにインストールされる事態は、ＭＦＰのリソースを無駄に使用するという理由で、好ましくない。また、ＭＦＰのユーザーが使用すべきアプリを認識し難くなるという理由で、好ましくない。また、ＭＦＰ管理者によるアプリの管理が煩わしくなるという理由で、好ましくない。また、新たなアプリをインストールしたにも関わらず、それまで使用していたアプリが使用され続けるおそれがあるという理由で、好ましくない。したがって、類似した２つのアプリがＭＦＰにインストールされている場合に、それらを統合することが求められている。

なお、画像形成装置にアプリをインストールする技術は、たとえば下記特許文献１に開示されている。下記特許文献１では、アップデート元のアプリプログラムがインストール済みである場合に、アップデート元のアプリプログラムの設定データとライセンス情報とがインストール要求されたアプリプログラムに引き継がれるようにアプリプログラムがインストールされる。

特開２０１４−１７８７９８号公報

類似した２つのアプリを統合することが要求されている一方で、類似した２つのアプリを統合した場合には、様々な不都合が生じるおそれがあり、利便性が低かった。一例として、それまで使用していた古いアプリの機能を、新たなアプリでは使用することができなくなるという不都合が生じるおそれがある。また、古いアプリの使用を許可されていたユーザーが、新たなアプリの使用を許可されないという不都合が生じるおそれがある。また、古いアプリの利用記録やアカウント設定が、新たなアプリにも引き継がれないおそれがある。

本発明は、上記課題を解決するためのものであり、その目的は、利便性を向上することのできるアプリケーション統合装置およびアプリケーション統合装置の制御プログラムを提供することである。

本発明の一の局面に従うアプリケーション統合装置は、情報処理装置にインストールされた新アプリケーションと技術的に統合可能な旧アプリケーションであって、新アプリケーションがインストールされるよりも前に情報処理装置にインストールされた旧アプリケーションを検索する検索手段と、新アプリケーションと旧アプリケーションとを技術的に統合することが可能であるか否かを判別する判別手段と、新アプリケーションと旧アプリケーションとを技術的に統合することが可能であると判別手段にて判別した場合に、新アプリケーションと旧アプリケーションとの統合を許可するか否かを決定する決定手段と、決定手段による決定に従って、新アプリケーションと旧アプリケーションとを統合する統合手段とを備える。

上記アプリケーション統合装置において好ましくは、旧アプリケーションに関する情報を情報処理装置から取得する取得手段をさらに備え、決定手段は、取得手段にて取得した情報に基づいて、新アプリケーションと旧アプリケーションとの統合を許可するか否かを決定する。

上記アプリケーション統合装置において好ましくは、取得手段は、新アプリケーションに関する情報を情報処理装置からさらに取得する。

上記アプリケーション統合装置において好ましくは、取得手段は、新アプリケーションおよび旧アプリケーションの各々が提供する機能の情報を取得し、決定手段は、新アプリケーションが提供する機能に、旧アプリケーションが提供する機能の少なくとも一部が包含されない場合に、新アプリケーションと旧アプリケーションとの統合を許可しないと決定する。

上記アプリケーション統合装置において好ましくは、取得手段は、新アプリケーションおよび旧アプリケーションの各々が出力するデータの形式の情報を取得し、決定手段は、新アプリケーションが出力するデータの形式と、旧アプリケーションが出力するデータの形式とが一致しない場合に、新アプリケーションと旧アプリケーションとの統合を許可しないと決定する。

上記アプリケーション統合装置において好ましくは、取得手段は、新アプリケーションおよび旧アプリケーションの各々を使用可能なグループの情報を取得し、決定手段は、新アプリケーションを使用可能なグループに、旧アプリケーションを使用可能なグループの少なくとも一部が包含されない場合に、新アプリケーションと旧アプリケーションとの統合を許可しないと決定する。

上記アプリケーション統合装置において好ましくは、取得手段は、新アプリケーションおよび旧アプリケーションの各々を使用可能なユーザーの情報を取得し、決定手段は、新アプリケーションを使用可能なユーザーに、旧アプリケーションを使用可能なユーザーの少なくとも一部が包含されない場合に、新アプリケーションと旧アプリケーションとの統合を許可しないと決定する。

上記アプリケーション統合装置において好ましくは、取得手段は、新アプリケーションおよび旧アプリケーションの各々の管理者の情報を取得し、決定手段は、新アプリケーションの管理者と旧アプリケーションの管理者とが一致しない場合に、新アプリケーションと旧アプリケーションとの統合を許可しないと決定する。

上記アプリケーション統合装置において好ましくは、取得手段は、新アプリケーションおよび旧アプリケーションの各々の課金先の情報を取得し、決定手段は、新アプリケーションの課金先と、旧アプリケーションの課金先とが一致しない場合に、新アプリケーションと旧アプリケーションとの統合を許可しないと決定する。

上記アプリケーション統合装置において好ましくは、取得手段は、旧アプリケーションの使用履歴に関する情報を取得し、決定手段は、旧アプリケーションが第１の期間内に使用された頻度が所定の回数以上である場合、および旧アプリケーションが第２の期間内に使用されている場合のうち少なくともいずれか１つの場合に、新アプリケーションと旧アプリケーションとの統合を許可しないと決定する。

上記アプリケーション統合装置において好ましくは、統合手段は、旧アプリケーションのデータを情報処理装置から削除する削除手段を含む。

上記アプリケーション統合装置において好ましくは、統合手段は、新アプリケーションのプログラムを修正するプログラム修正手段をさらに含む。

上記アプリケーション統合装置において好ましくは、統合手段は、旧アプリケーションを用いたワークフローを実行するプログラムを修正するフロー修正手段をさらに含む。

上記アプリケーション統合装置において好ましくは、情報処理装置とアプリケーション統合装置とは、同一の装置である。

本発明の他の局面に従うアプリケーション統合装置の制御プログラムは、情報処理装置にインストールされた新アプリケーションと技術的に統合可能な旧アプリケーションであって、新アプリケーションがインストールされるよりも前に情報処理装置にインストールされた旧アプリケーションを検索する検索ステップと、新アプリケーションと旧アプリケーションとを技術的に統合することが可能であるか否かを判別する判別ステップと、新アプリケーションと旧アプリケーションとを技術的に統合することが可能であると判別ステップにて判別した場合に、新アプリケーションと旧アプリケーションとの統合を許可するか否かを決定する決定ステップと、決定ステップにおける決定に従って、新アプリケーションと旧アプリケーションとを統合する統合ステップとをコンピューターに実行させる。

本発明によれば、利便性を向上することのできるアプリケーション統合装置およびアプリケーション統合装置の制御プログラムを提供することができる。

本発明の一実施の形態における画像形成システムの構成を概念的に示す図である。 本発明の一実施の形態におけるＭＦＰ１００のハードウェア構成を示すブロック図である。 本発明の一実施の形態におけるサーバー２００のハードウェア構成を示すブロック図である。 本発明の一実施の形態におけるＭＦＰ１００−１のソフトウェア構成を示すブロック図である。 本発明の一実施の形態におけるＭＦＰ１００−１の動作の概要を模式的に示す図である。 アプリＤとアプリＡとの統合を許可するか否かの第３の判断基準を示す図である。 アプリＤとアプリＡとの統合を許可するか否かの第４の判断基準を示す図である。 アプリＤとアプリＡとの統合を許可するか否かの第５〜第７の判断基準を示す図である。 本発明の一実施の形態におけるＭＦＰ１００−１の動作を示すフローチャートである。 本発明の一実施の形態の変形例における各アプリの保存場所の一例と、アプリＡが組み込まれたワークフローの一例を示す図である。 本発明の一実施の形態の変形例における各アプリの保存場所の他の例を示す図である。 本発明の一実施の形態の変形例において、ワークフローの一部を実行するアプリを統合する場合のＭＦＰ１００−１の動作を示す図である。

以下、本発明の一実施の形態について、図面に基づいて説明する。

以下の実施の形態では、アプリケーション統合装置がＭＦＰである場合について説明する。アプリケーション統合装置は、プリンター、複写機、またはファクシミリなどの、ＭＦＰ以外の画像形成装置であってもよい。またアプリケーション統合装置は、画像読取装置、携帯電話、またはスマートフォンなどの、画像形成装置以外の装置あってもよい。

また、以下の実施の形態においては、アプリケーション統合装置が、自機にインストールされた２つのアプリの統合を許可するか否かを判別する場合（アプリケーション統合装置と情報処理装置とが同一の装置である場合）について説明する。アプリケーション統合装置は、アプリケーション統合装置とは別体の情報処理装置にインストールされた２つのアプリの統合を許可するか否かを判別するものであってもよい。

［画像形成システムの構成］

図１は、本発明の一実施の形態における画像形成システムの構成を概念的に示す図である。

図１を参照して、本実施の形態における画像形成システムは、ＭＦＰ１００−１（アプリ統合装置の一例）、１００−２、および１００−３と、サーバー２００とを備えている（以降、ＭＦＰ１００−１、１００−２、および１００−３を纏めてＭＦＰ１００と記すことがある）。ＭＦＰ１００の各々とサーバー２００とは、たとえばオフィス内のネットワーク３００を通じて相互に接続されている。

ネットワーク３００は、たとえば有線または無線のＬＡＮなどの専用回線を用いたものである。ネットワーク３００は、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）のプロトコルを用いて各種機器を接続する。ネットワーク３００に接続された機器は、お互いに各種データのやり取りが可能となっている。ネットワーク３００はインターネットに接続されていてもよい。

図２は、本発明の一実施の形態におけるＭＦＰ１００のハードウェア構成を示すブロック図である。

図２を参照して、ＭＦＰ１００は、システムコントローラー１０１と、メモリ１０２と、ネットワークインターフェース１０３と、プリントエンジン部１０４と、出力画像処理部１０５と、記憶装置１０６と、認証装置１０７と、操作パネル１０８と、スキャナー部１０９と、入力画像処理部１１０とを備えている。システムコントローラー１０１には、メモリ１０２、ネットワークインターフェース１０３、プリントエンジン部１０４、出力画像処理部１０５、記憶装置１０６、認証装置１０７、操作パネル１０８、スキャナー部１０９、および入力画像処理部１１０の各々が接続されている。

システムコントローラー１０１は、スキャンジョブ、コピージョブ、メール送信ジョブ、およびプリントジョブなどの各種ジョブについて、ＭＦＰ１００全体の制御を行う。システムコントローラー１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１２１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２２などを含んでいる。ＣＰＵ１２１は、ＲＯＭ１２２に記憶された制御プログラムを実行する。ＲＯＭ１２２は、ＭＦＰ１００の動作を行うための各種プログラムと、各種固定データとを格納している。システムコントローラー１０１は、所定の処理を行うことにより、メモリ１０２からのデータの読み込みや、メモリ１０２へのデータの書き込みを行う。

メモリ１０２は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）よりなっている。メモリ１０２は、ＣＰＵ１２１が制御プログラムを実行する際に必要なデータや画像データを一時的に記憶する。

ネットワークインターフェース１０３は、システムコントローラー１０１からの指示に従って、ネットワーク３００を介してサーバー２００や他のＭＦＰ１００などの外部機器との通信を行う。

プリントエンジン部１０４は、出力画像処理部１０５にて処理された印刷データを用いて、用紙などへ画像を形成する（プリントジョブを行う）。プリントエンジン部１０４は、おおまかに、トナー像形成部、定着装置、および用紙搬送部などで構成される。トナー像形成部は、いわゆるタンデム方式で４色の画像を合成し、用紙（記録媒体）にカラー画像を形成する。トナー像形成部は、Ｃ（シアン）、Ｍ（マゼンタ）、Ｙ（イエロー）、Ｋ（ブラック）の各色について設けられた感光体と、感光体からトナー像が転写（１次転写）される中間転写ベルトと、中間転写ベルトから用紙に画像を転写（２次転写）する転写部などで構成される。定着装置は、加熱ローラーおよび加圧ローラーを有する。定着装置は、加熱ローラーと加圧ローラーとでトナー像が形成された用紙を挟みながら搬送し、その用紙に加熱および加圧を行う。これにより、定着装置は、用紙に付着したトナーを溶融させて用紙に定着させ、用紙に画像を形成する。用紙搬送部は、給紙ローラー、搬送ローラー、およびそれらを駆動するモーターなどで構成されている。用紙搬送部は、用紙を給紙カセットから給紙して、ＭＦＰ１００の筐体の内部で搬送する。また、用紙搬送部は、画像が形成された用紙をＭＦＰ１００の筐体の外部に排出する。

出力画像処理部１０５は、画像の印刷を行う場合などに、その画像データの形式を印刷データに変換する変換処理を行う。

記憶装置１０６は、たとえばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）よりなっている。記憶装置１０６は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、各種アプリのプログラムおよびデータベース、アプリ統合プログラム１６１、ならびにアプリ管理テーブル１６２
（図４）などの各種データを記憶する。

認証装置１０７は、ＭＦＰ１００を操作するユーザーを認証する。

操作パネル１０８は、各種情報を表示し、各種操作を受け付ける。

スキャナー部１０９は、原稿を光学的に読取って画像データを得る。

入力画像処理部１１０は、スキャナー部１０９で画像を読み取った場合などに、その画像データの形式を変換する変換処理を行う。

なお、ＭＦＰ１００−１、ＭＦＰ１００−２、および１００−３の各々は、同様の構成を有していてもよいし、互いに異なる構成を有していてもよい。

図３は、本発明の一実施の形態におけるサーバー２００のハードウェア構成を示すブロック図である。

図３を参照して、サーバー２００は、ＭＦＰ１００にインストールされている複数のアプリケーションを用いたワークフローを制御する（詳細は後述する）。サーバー２００は、ＣＰＵ２０１と、ＲＯＭ２０２と、メモリ２０３と、ネットワークインターフェース２０４と、記憶装置２０５と、表示部２０６と、操作部２０７とを含んでいる。ＣＰＵ２０１と、ＲＯＭ２０２、メモリ２０３、ネットワークインターフェース２０４、記憶装置２０５、表示部２０６、および操作部２０７の各々とは、バスなどで相互に接続されている。

ＣＰＵ２０１は、制御プログラムを実行する。ＲＯＭ２０２は、制御プログラムを格納する。メモリ２０３は、ＣＰＵ２０１の作業用のメモリであり、各種情報を一時的に記憶する。ネットワークインターフェース２０４は、ＣＰＵ２０１からの指示に従ってネットワーク３００を介して外部機器との通信を行う。記憶装置２０５は、ワークフローのプログラムなどの各種情報を記憶する。表示部２０６は、各種情報を表示する。操作部２０７は、各種操作を受け付ける。

サーバー２００は、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、携帯電話、またはスマートフォンなどであってもよい。

図４は、本発明の一実施の形態におけるＭＦＰ１００−１のソフトウェア構成を示すブロック図である。

図４を参照して、ＭＦＰ１００−１は、アプリケーション層１５０と、アプリケーションＰＦ（Ｐｌａｔｆｏｒｍ）層１６０と、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）層１７０とを含んでいる。ＯＳ層１７０上に、アプリケーションＰＦ層１６０が形成され、アプリケーションＰＦ層１６０上にアプリケーション層１５０が形成される。

ＯＳ層１７０には、ＣＰＵ１２１がＯＳプログラムを実行するタスクが属する。ＯＳ層１７０に属するタスクは、ＭＦＰ１００のハードウェア資源を制御する処理を実行する。これにより、ＭＦＰ１００の本体機能（スキャナー機能、ファクシミリ機能、複写機能、プリンターとしての機能、データ通信機能、およびサーバー機能など）が実現される。

アプリケーションＰＦ層１６０は、アプリケーション層１５０とＯＳ層１７０との間に配置され、アプリケーション層１５０に属する複数のタスクを調停するとともに、アプリケーション層１５０に属する複数のタスクが出力するアプリコマンドを制御するタスクが属する。

アプリケーション層１５０には、ＭＦＰ１００−１にインストールされたアプリを実行するタスクが属する。これらのアプリは、ＭＦＰ１００−１の使用開始後にＭＦＰ１００−１のユーザーによってインストールされたアプリを含んでいる。

なお、特に断りの無い限り、ＭＦＰ１００−１には、アプリＡ、アプリＢ、アプリＣ、およびアプリＤの各々がインストールされているものとする。これらはアプリケーション層１５０に属するものである。

本実施の形態では、複数のアプリを統合するためのアプリ統合プログラム１６１や、アプリ管理テーブル１６２は、アプリケーションＰＦ層１６０に属している。アプリ統合プログラム１６１やアプリ管理テーブル１６２は、アプリケーション層１５０に属していてもよい。

［ＭＦＰ１００−１の動作］

続いて、本実施の形態におけるＭＦＰ１００−１の動作について説明する。この動作は、アプリ統合プログラム１６１に基づいてＣＰＵ１２１が実行するものである。

図５は、本発明の一実施の形態におけるＭＦＰ１００−１の動作の概要を模式的に示す図である。

図５（ａ）を参照して、ＭＦＰ１００−１は、新アプリがインストールされた後の任意のタイミングで、ＭＦＰ１００−１にインストールされたアプリを検索する。

本実施の形態では、新アプリがアプリＤであり、検索により抽出されたアプリがアプリＡである場合について説明する。アプリＡは、アプリＤに統合される候補となる。アプリＡおよびアプリＤの各々は、基本機能（たとえばモノクロコピー機能など）および応用機能（たとえばカラーコピー機能など）を有している。

アプリＡのデータは、アプリＡに関するプログラム１５１ａと、アプリＡに関するデータベース１５２ａとを含んでいる。データベース１５２ａはユーザー情報テーブル１５３ａを含んでいる。同様に、アプリＤのデータは、アプリＤに関するプログラム１５１ｂと、アプリＤに関するデータベース１５２ｂとを含んでいる。データベース１５２ｂはユーザー情報テーブル１５３ｂを含んでいる。

次にＭＦＰ１００−１は、プログラム１５１ａとプログラム１５１ｂとを取得する。ＭＦＰ１００−１は、プログラム１５１ａとプログラム１５１ｂとを比較することにより、アプリＤとアプリＡとを技術的に統合することが可能であるか否かを判別する。

２つのアプリが技術的に統合可能とは、２つのアプリの機能が類似しており、かつ新アプリのプログラムまたは新アプリの修正したプログラムにより、新アプリに統合される候補となるアプリの機能を実現可能であることを意味している。

アプリＤとアプリＡとを技術的に統合することが可能である場合、アプリＡは、旧アプリとして抽出される。旧アプリとは、新アプリと技術的に統合可能なアプリであって、新アプリがインストールされるよりも前にＭＦＰ１００−１にインストールされたアプリである。

図５（ｂ）を参照して、アプリＤとアプリＡとを技術的に統合することが可能である場合、ＭＦＰ１００−１は、アプリＡに関するデータ（ユーザー情報テーブル１５３ａなど）を取得する。ＭＦＰ１００−１は、アプリＤに関するデータ（ユーザー情報テーブル１５３ｂなど）をさらに取得してもよい。

ＭＦＰ１００−１は、取得したデータに基づいて、アプリＤとアプリＡとの統合を許可するか否かを決定する。アプリＤとアプリＡとの統合を許可するか否かの具体的な決定方法は後述する。

ところで、アプリケーションＰＦは、通常（アプリの動作時など）、ユーザーや管理者の枠組みを越えてアプリ統合プログラム１６１がアプリのデータベースからユーザー情報テーブルを取得することを許可しない。アプリケーションＰＦは、アプリ統合プログラム１６１が２つのアプリの統合を許可するか否かを判断する場合に限って、アプリ統合プログラム１６１がアプリのデータベースからユーザー情報テーブルを取得することを許可する。

図５（ｃ）および図５（ｄ）を参照して、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可すると決定した場合に、アプリＡをアプリＤに統合する。２つのアプリを統合する際には、旧アプリが新アプリに統合され、旧アプリは削除される。一方、ＭＦＰ１００−１は、アプリＤとアプリＡとを技術的に統合することが不可能である場合、またはアプリＤとアプリＡとの統合を許可しないと決定した場合に、アプリＡをアプリＤに統合しない。この場合、アプリＡおよびアプリＤは、修正および削除されることなくＭＦＰ１００−１にインストールされたままになる。

アプリＡをアプリＤに統合する処理は、次の（ＰＲ１）〜（ＰＲ３）の処理よりなる。なお、（ＰＲ１）および（ＰＲ２）の処理は、必要に応じて行われればよい。

（ＰＲ１） ＭＦＰ１００−１は、アプリＤの機能に含まれていないアプリＡの機能が存在する場合、その機能がアプリＤでも実現可能となるように、アプリＡのプログラム１５１ａに基づいて、アプリＤのプログラム１５１ｂを修正する（図５（ｃ））。一例として、ＭＦＰ１００−１は、アプリＤの機能に含まれていないアプリＡの機能に対応するプログラム１５１ａの一部１５４ｂを、アプリＤのプログラム１５１ｂに追加してもよい。

（ＰＲ２） ＭＦＰ１００−１は、アプリＡのユーザー情報テーブル１５３ａに記載された情報のうちアプリＤのユーザー情報テーブル１５３ｂに含まれていない情報を、アプリＤのユーザー情報テーブル１５３ｂに追加する（図５（ｃ））。これにより、アプリＡのユーザー情報テーブル１５３ａに記載された情報は、アプリＤのユーザー情報テーブル１５３ｂに引き継がれる。

（ＰＲ３） ＭＦＰ１００−１は、アプリＡのプログラム１５１ａおよびデータベース１５２ａをＭＦＰ１００−１から削除する（図５（ｄ））。

なお、ＭＦＰ１００−１は、アプリＡをアプリＤに統合した後で、アプリＤのアイコンを操作パネル１０８に表示するなどのアプリ統合後処理を行ってもよい。

アプリＤとアプリＡとの統合を許可するか否かは、たとえば以下の方法で決定される。

図５（ｂ）を参照して、第１の判断基準は、アプリが提供する機能に関する判断基準である。ＭＦＰ１００−１は、アプリＡのプログラム１５１ａおよびアプリＤのプログラム１５１ｂを参照し、アプリＡおよびアプリＤの各々が提供する機能の情報を取得する。ＭＦＰ１００−１は、アプリＤが提供する機能に、アプリＡが提供する全ての機能が包含される場合に、アプリＤとアプリＡとの統合を許可すると決定する。

アプリＤが提供する機能に、アプリＡが提供する全ての機能が包含される場合には、アプリＡがアプリＤに統合されても、アプリＡが提供する全ての機能は引き続きアプリＤが提供することができる。このため、アプリＡをアプリＤに統合しつつ、アプリＡを使用していたユーザーの利便性の低下を抑止することができる。

一方、ＭＦＰ１００−１は、アプリＤが提供する機能に、アプリＡが提供する機能の少なくとも一部が包含されない場合に、アプリＤとアプリＡとの統合を許可しないと決定する。

アプリＤが提供する機能に、アプリＡが提供する機能の少なくとも一部が包含されない場合には、アプリＡがアプリＤに統合されると、アプリＡが提供する機能の少なくとも一部はアプリＤによって提供することができない。このため、アプリＡをアプリＤに統合しないことにより、アプリＡを使用していたユーザーの利便性の低下を抑止することができる。

第２の判断基準は、アプリが出力するデータの形式に関する判断基準である。ＭＦＰ１００−１は、アプリＡのプログラム１５１ａおよびアプリＤのプログラム１５１ｂを参照し、アプリＡおよびアプリＤの各々が出力するデータの形式の情報を取得する。ＭＦＰ１００−１は、アプリＤが出力するデータの形式と、アプリＡが出力するデータの形式とが一致する場合に、アプリＤとアプリＡとの統合を許可すると決定する。ＭＦＰ１００−１は、アプリＡのプログラム１５１ａおよびアプリＤのプログラム１５１ｂの各々のコード解析を行い、アプリが呼び出すＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）に変更があるか判断してもよい。

アプリＤが出力するデータの形式と、アプリＡが出力するデータの形式とが一致する場合には、アプリＡがアプリＤに統合されても、アプリＤは引き続きアプリＡと同じ形式のデータを出力することができる。このため、アプリＡをアプリＤに統合しつつ、アプリＡを使用していたユーザーの利便性の低下を抑止することができる。

一方、ＭＦＰ１００−１は、アプリＤが出力するデータの形式と、アプリＡが出力するデータの形式とが一致しない場合に、アプリＤとアプリＡとの統合を許可しないと決定する。

アプリＤが出力するデータの形式と、アプリＡが出力するデータの形式とが一致しない場合には、アプリＡがアプリＤに統合されると、アプリＤは、アプリＡとは異なる形式のデータを出力し、出力先のアプリがデータを正しく使用することができない事態となる。このため、アプリＡをアプリＤに統合しないことにより、アプリＡを使用していたユーザーの利便性の低下を抑止することができる。

一例として、アプリＤおよびアプリＡがリモートログを送信するアプリであり、アプリＤが日時情報、ログ内容、およびアプリ名のデータを送信し、アプリＡが日時情報およびログ内容のデータを送信するものである場合には、リモートログの受け取り側であるアプリは、ログを正しく利用することができない事態となる。

図６は、アプリＤとアプリＡとの統合を許可するか否かの第３の判断基準を示す図である。

図６を参照して、ユーザー情報テーブルは、アプリの使用が許可されているユーザーに関する情報を含むテーブルである。ユーザー情報テーブルは、アプリがＭＦＰ１００−１にインストールされた後に、アプリの管理者やＭＦＰ１００−１の管理者などによってアプリ毎に設定される。

図６では、ユーザー情報テーブルは、アプリを使用可能なグループの情報が記載されたものであり、アプリの使用が許可されているグループの項目と、そのグループのメンバーの項目と、そのグループのメンバーが使用を許可されているアプリの機能の項目とを含んでいる。各グループは、１人以上のユーザーで構成されている。

図６（ａ）に示すアプリＡのユーザー情報テーブル１５３ａによれば、アプリＡは、「ＧＲＯＵＰ＿Ａ」、「ＧＲＯＵＰ＿Ｂ」、および「ＧＲＯＵＰ＿Ｃ」の各々に使用が許可されている。「ＧＲＯＵＰ＿Ａ」のメンバーは、「ｕｓｅｒ＿ａ１」、「ｕｓｅｒ＿ａ２」、および「ｕｓｅｒ＿ａ３」という各ユーザーである。「ＧＲＯＵＰ＿Ａ」のメンバーには、アプリＡの基本機能のみの使用が許可されている（応用機能の使用は許可されていない）。「ＧＲＯＵＰ＿Ｂ」のメンバーは、「ｕｓｅｒ＿ｂ１」および「ｕｓｅｒ＿ｂ２」という各ユーザーである。「ＧＲＯＵＰ＿Ｂ」のメンバーには、アプリＡの基本機能および応用機能の使用が許可されている。「ＧＲＯＵＰ＿Ｃ」のメンバーは、「ｕｓｅｒ＿ｃ１」、「ｕｓｅｒ＿ｃ２」、「ｕｓｅｒ＿ｃ３」、および「ｕｓｅｒ＿ｃ４」という各ユーザーである。「ＧＲＯＵＰ＿Ｃ」のメンバーには、アプリＡの基本機能のみの使用が許可されている。

第３の判断基準は、アプリを使用可能なグループに関する判断基準である。ＭＦＰ１００−１は、アプリＡのユーザー情報テーブル１５３ａおよびアプリＤのユーザー情報テーブル１５３ｂの各々を取得する。ＭＦＰ１００−１は、アプリＤを使用可能なグループに、アプリＡを使用可能なグループ全部が包含される場合（つまり、アプリＤのユーザー情報テーブル１５３ｂの内容が、アプリＡのユーザー情報テーブル１５３ａの内容と同一である場合、またはアプリＡのユーザー情報テーブル１５３ａの内容を包含している場合（図６（ｂ）））、アプリＤとアプリＡとの統合を許可すると決定する。

アプリＤを使用可能なグループに、アプリＡを使用可能なグループ全部が包含される場合には、アプリＡがアプリＤに統合されても、アプリＡの使用が許可されていたユーザーは、引き続きアプリＤを使用することができる。このため、アプリＡをアプリＤに統合しつつ、アプリＡの使用が許可されているユーザーの利便性の低下を抑止することができる。

一方、アプリＤを使用可能なグループに、アプリＡを使用可能なグループの少なくとも一部が包含されない場合（つまり、アプリＤのユーザー情報テーブル１５３ｂの内容が、アプリＡのユーザー情報テーブル１５３ａの内容と異なっており、かつアプリＡのユーザー情報テーブル１５３ａの内容を包含していない場合（図６（ｃ）および図６（ｄ）の場合））、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可しないと決定する。

アプリＤを使用可能なグループに、アプリＡを使用可能なグループの少なくとも一部が包含されない場合には、アプリＡがアプリＤに統合されると、アプリＡの使用が許可されていたユーザーの少なくとも一部は、引き続きアプリＤを使用することができない事態となる。このため、アプリＡをアプリＤに統合しないことにより、アプリＡの使用が許可されているユーザーの利便性の低下を抑止することができる。

図６（ｂ）に示すアプリＤのユーザー情報テーブル１５３ｂの内容は、図６（ａ）に示すアプリＡのユーザー情報テーブル１５３ａの内容と、次の点において異なっている。図６（ｂ）に示すアプリＤのユーザー情報テーブル１５３ｂでは、「ＧＲＯＵＰ＿Ｃ」のメンバーに、アプリＤの基本機能に加えてさらに応用機能の使用が許可されている。また、「ＧＲＯＵＰ＿Ｄ」のメンバーである「ｕｓｅｒ＿ｄ１」というユーザーに、アプリＤの基本機能のみの使用が許可されている。アプリＡのユーザー情報テーブル１５３ａの内容は、図６（ｂ）に示すアプリＤのユーザー情報テーブル１５３ｂの内容に包含されている。このため、アプリＡがアプリＤに統合されても、アプリＡの使用が許可されているユーザーは、引き続きアプリＤにおいて、アプリＡで使用が許可されている機能と同様の機能を使用することが可能である。

図６（ｃ）に示すアプリＤのユーザー情報テーブル１５３ｂの内容は、「ＧＲＯＵＰ＿Ｃ」が含まれていない点で、図６（ａ）に示すアプリＡのユーザー情報テーブル１５３ａの内容と異なっている。この場合、アプリＡがアプリＤに統合されると、アプリＡの使用が許可されている「ＧＲＯＵＰ＿Ｃ」のメンバーは、引き続きアプリＤを使用することができない事態となる。

図６（ｄ）に示すアプリＤのユーザー情報テーブル１５３ｂの内容は、「ＧＲＯＵＰ＿Ｂ」のメンバーに応用機能の使用が許可されていない点で、図６（ａ）に示すアプリＡのユーザー情報テーブル１５３ａの内容と異なっている。この場合、アプリＡがアプリＤに統合されると、「ＧＲＯＵＰ＿Ｂ」のメンバーは、引き続きアプリＤで応用機能を使用することができない事態となる。

図７は、アプリＤとアプリＡとの統合を許可するか否かの第４の判断基準を示す図である。

図７を参照して、アプリＡのユーザー情報テーブル１５３ａおよびアプリＤのユーザー情報テーブル１５３ｂの各々は、アプリの使用が許可されているユーザーの項目と、そのユーザーが使用を許可されているアプリの機能の項目とを含んでいる。

図７（ａ）に示すアプリＡのユーザー情報テーブル１５３ａによれば、「ｕｓｅｒ＿ａ１」、「ｕｓｅｒ＿ａ２」、および「ｕｓｅｒ＿ａ３」という各ユーザーには、アプリＡの基本機能のみの使用が許可されている。「ｕｓｅｒ＿ｂ１」というユーザーには、アプリＡの基本機能および応用機能の使用が許可されている。

第４の判断基準は、アプリを使用可能なユーザーに関する判断基準である。ＭＦＰ１００−１は、アプリＡのユーザー情報テーブル１５３ａおよびアプリＤのユーザー情報テーブル１５３ｂの各々を取得する。ＭＦＰ１００−１は、アプリＤを使用可能なユーザーに、アプリＡを使用可能なユーザー全部が包含される場合（つまり、アプリＤのユーザー情報テーブル１５３ｂの内容が、アプリＡのユーザー情報テーブル１５３ａの内容と同一である場合、またはアプリＡのユーザー情報テーブル１５３ａの内容を包含している場合（図７（ｂ）））、アプリＤとアプリＡとの統合を許可すると決定する。

アプリＤを使用可能なユーザーに、アプリＡを使用可能なユーザー全部が包含される場合には、アプリＡがアプリＤに統合されても、アプリＡの使用が許可されていたユーザーは、引き続きアプリＤを使用することができる。このため、アプリＡをアプリＤに統合しつつ、アプリＡの使用が許可されているユーザーの利便性の低下を抑止することができる。

一方、アプリＤを使用可能なユーザーに、アプリＡを使用可能なユーザーの少なくとも一部が包含されない場合（つまり、アプリＤのユーザー情報テーブル１５３ｂの内容が、アプリＡのユーザー情報テーブル１５３ａの内容と異なっており、かつアプリＡのユーザー情報テーブル１５３ａの内容を包含していない場合（図７（ｃ）および図７（ｄ）の場合））、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可しないと決定する。

アプリＤを使用可能なユーザーに、アプリＡを使用可能なユーザーの少なくとも一部が包含されない場合には、アプリＡがアプリＤに統合されると、アプリＡの使用が許可されていたユーザーの少なくとも一部は、引き続きアプリＤを使用することができない事態となる。このため、アプリＡをアプリＤに統合しないことにより、アプリＡの使用が許可されているユーザーの利便性の低下を抑止することができる。

図７（ｂ）に示すアプリＤのユーザー情報テーブル１５３ｂの内容は、図７（ａ）に示すアプリＡのユーザー情報テーブル１５３ａの内容と、次の点において異なっている。図７（ｂ）に示すアプリＤのユーザー情報テーブル１５３ｂでは、「ｕｓｅｒ＿ａ３」というユーザーに、アプリＤの基本機能に加えてさらに応用機能の使用が許可されている。また、「ｕｓｅｒ＿ｂ２」というユーザーに、アプリＤの基本機能および応用機能の使用が許可されている。アプリＡのユーザー情報テーブル１５３ａの内容は、図６（ｂ）に示すアプリＤのユーザー情報テーブル１５３ｂの内容に包含されている。このため、アプリＡがアプリＤに統合されても、アプリＡの使用が許可されているユーザーは、引き続きアプリＤにおいて、アプリＡで使用が許可されている機能と同様の機能を使用することが可能である。

図７（ｃ）に示すアプリＤのユーザー情報テーブル１５３ｂの内容は、「ｕｓｅｒ＿ｂ１」というユーザーに、応用機能の使用が許可されていない点で、図７（ａ）に示すアプリＡのユーザー情報テーブル１５３ａの内容と異なっている。この場合、アプリＡがアプリＤに統合されると、「ｕｓｅｒ＿ｂ１」というユーザーは、引き続きアプリＤにおいて応用機能を使用することができない事態となる。

図７（ｄ）に示すアプリＤのユーザー情報テーブル１５３ｂの内容は、「ｕｓｅｒ＿ａ３」というユーザーに、基本機能の使用が許可されていない点で、図７（ａ）に示すアプリＡのユーザー情報テーブル１５３ａの内容と異なっている。この場合、アプリＡがアプリＤに統合されると、「ｕｓｅｒ＿ａ３」というユーザーは、引き続きアプリＤを使用することができない事態となる。

なお、第３および第４の判断基準において、使用可能な機能に関わらず、アプリＤを使用可能なユーザーに、アプリＡを使用可能なユーザーの少なくとも一部が包含されない場合に、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可しないと決定してもよい。

また、ＭＦＰ１００−１は、以下に説明するようにユーザー情報テーブルを参照する代わりにアプリ管理テーブルを参照することにより、アプリＤとアプリＡとの統合を許可するか否かを決定してもよい。

図８は、アプリＤとアプリＡとの統合を許可するか否かの第５〜第７の判断基準を示す図である。

図８を参照して、アプリ管理テーブル１６２は、ＭＦＰ１００−１にインストールされているアプリの管理に関する情報を含むテーブルである。アプリ管理テーブル１６２は、アプリがＭＦＰ１００−１にインストールされた後に、アプリの管理者やＭＦＰ１００−１の管理者などによって設定される。アプリ管理テーブル１６２は、各アプリについての管理者の項目と、そのアプリが使用された場合の課金対象者（課金先）の項目と、そのアプリがインストールされた日時と、そのアプリの最新の使用日時の項目と、そのアプリが１ヶ月以内に使用された回数の項目とを含んでいる。なお本実施の形態では、現在（アプリＤとアプリＡとの統合を許可するか否かの決定時）の日時が「２０１６年５月１８日１５時」であるものとする。

図８（ａ）に示すアプリ管理テーブル１６２によれば、アプリＡの管理者は「ｕｓｅｒ＿ａ１」であり、課金対象者は「ｕｓｅｒ＿ａ２」であり、インストール日時は「２０１１年１１月２０日１５時２３分」であり、最新の使用日時は「２０１５年１月３日９時３５分」であり、１ヶ月以内の使用回数は「０」回である。アプリＤの管理者は「ｕｓｅｒ＿ａ１」であり、課金対象者は「ｕｓｅｒ＿ａ２」であり、インストール日時は「２０１６年５月１８日８時２１分」であり、最新の使用日時は「２０１６年５月１８日１０時５０分」であり、１ヶ月以内の使用回数は「２」回である。

第５の判断基準は、アプリの管理者に関する判断基準である。ＭＦＰ１００−１は、アプリＤおよびアプリＡの各々の管理者の情報を取得する。アプリ管理テーブル１６２が図８（ａ）に示す内容である場合、アプリＤの管理者およびアプリＡの管理者はいずれも「ｕｓｅｒ＿ａ１」である。このように、アプリＤの管理者とアプリＡの管理者とが一致する場合に、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可すると決定する。

アプリＤの管理者とアプリＡの管理者とが一致する場合、アプリＡがアプリＤに統合されても、アプリＤの管理者は、アプリＡの機能であってアプリＤに追加された機能を容易に管理することがである。このため、アプリＡをアプリＤに統合しつつ、アプリＤの管理者の利便性の低下を抑止することができる。

一方、アプリ管理テーブル１６２が図８（ｂ）に示す内容である場合、アプリＤの管理者が「ｕｓｅｒ＿ａ１」であるのに対して、アプリＡの管理者は「ｕｓｅｒ＿ｄ１」である。このように、アプリＤの管理者とアプリＡの管理者とが一致しない場合に、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可しないと決定する。

アプリＤの管理者とアプリＡの管理者とが一致しない場合、アプリＡがアプリＤに統合されると、アプリＤの管理者は、アプリＤに追加されたアプリＡの機能を管理する必要が生じる。この管理はアプリＤの管理者にとって不慣れなものである可能性がある。このため、アプリＡをアプリＤに統合しないことにより、アプリＤの管理者の利便性の低下を抑止することができる。

第６の判断基準は、アプリの課金先に関する判断基準である。ＭＦＰ１００−１は、アプリＤおよびアプリＡの各々の課金先の情報を取得する。アプリ管理テーブル１６２が図８（ａ）に示す内容である場合、アプリＤの課金先およびアプリＡの課金先はいずれも「ｕｓｅｒ＿ａ２」である。このように、アプリＤの課金先とアプリＡの課金先とが一致する場合に、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可すると決定する。

アプリＤの機能とアプリＡの機能とは類似しているため、アプリＤの課金先とアプリＡの課金先とが一致する場合、アプリＡがアプリＤに統合されても、課金される機能の差は小さく、アプリＤの課金先の不利益は小さい。このため、アプリＡをアプリＤに統合しつつ、アプリＤの課金先の利便性の低下を抑止することができる。

一方、アプリ管理テーブル１６２が図８（ｃ）に示す内容である場合、アプリＤの課金先が「ｕｓｅｒ＿ａ２」であるのに対して、アプリＡの管理者は「ｕｓｅｒ＿ｄ３」である。このように、アプリＤの課金先とアプリＡの課金先とが一致しない場合に、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可しないと決定する。

アプリＤの課金先とアプリＡの課金先とが一致しない場合、アプリＡを使用していたユーザーが新たにアプリＤの使用を開始すると、アプリＤの課金先が受ける不利益は大きい。このため、アプリＡをアプリＤに統合しないことにより、アプリＤの課金先の利便性の低下を抑止することができる。

第７の判断基準は、アプリの使用履歴に関する判断基準である。ＭＦＰ１００−１は、アプリＡの最新の使用日時および使用回数の情報を取得する。アプリ管理テーブル１６２が図８（ａ）に示す内容である場合、アプリＡの最新の使用日時は「２０１５年１月３日１０時５０分」であり、現在から１ヶ月以内の使用回数は「０」回である。このように、アプリＡが第１の期間（ここでは現在から１ヶ月前までの期間）内に使用された頻度が所定の回数（ここでは２回）未満であり、かつアプリＡが第２の期間（ここでは３ヶ月）内に使用されていない場合に、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可すると決定する。

アプリＡの使用頻度が低い場合、アプリＡがアプリＤに統合されても、アプリＡの使用者の不利益は小さい。このため、アプリＡをアプリＤに統合しつつ、アプリＡの使用者の利便性の低下を抑止することができる。

一方、アプリ管理テーブル１６２が図８（ｄ）に示す内容である場合、アプリＡの最新の使用日時は「２０１６年５月１２日２０時４７分」であり、現在から１ヶ月以内の使用回数は「４」回である。このように、アプリＡが第１の期間（ここでは現在から１ヶ月前までの期間）内に使用された頻度が所定の回数（ここでは２回）以上である場合、およびアプリＡが第２の期間（ここでは３ヶ月）内に使用されている場合のうち少なくともいずれか１つに該当する場合、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可しないと決定する。

アプリＡの使用頻度が高い場合、アプリＡがアプリＤに統合されると、アプリＡの使用者の不利益が大きい。このため、アプリＡをアプリＤに統合しないことにより、アプリＡの使用者の利便性の低下を抑止することができる。

なお、ＭＦＰ１００−１は、アプリＡが第１の期間内に使用された頻度が所定の回数以上であるか否か、およびアプリＡが第２の期間内に使用されているか否かのうちいずれか一方のみを判断基準としてもよい。

上記第１〜第７の判断基準は、互いに組み合わせることができる。たとえば、第１〜第７の判断基準の全てを組み合わせてもよい。すなわち、アプリＤが提供する機能に、アプリＡが提供する機能の少なくとも一部が包含されない場合（第１の判断基準）、アプリＤが出力するデータの形式と、アプリＡが出力するデータの形式とが一致しない場合（第２の判断基準）、アプリＤを使用可能なグループに、アプリＡを使用可能なグループの少なくとも一部が包含されない場合（第３の判断基準）、アプリＤを使用可能なユーザーに、アプリＡを使用可能なユーザーの少なくとも一部が包含されない場合（第４の判断基準）、アプリＤの管理者とアプリＡの管理者とが一致しない場合（第５の判断基準）、アプリＤの課金先とアプリＡの課金先とが一致しない場合（第６の判断基準）、アプリＡが第１の期間内に使用された頻度が所定の回数以上である場合（第７の判断基準）、およびアプリＡが第２の期間内に使用されている場合（第７の判断基準）のうち少なくとも１つに該当する場合、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可しないようにしてもよい。

図９は、本発明の一実施の形態におけるＭＦＰ１００−１の動作を示すフローチャートである。

図９を参照して、ＭＦＰ１００−１のＣＰＵ１２１は、新アプリがインストールされると（Ｓ１０１）、ＭＦＰ１００−１内に新アプリとは別のアプリがインストールされているか否かを判別する（Ｓ１０３）。

ステップＳ１０３において、ＭＦＰ１００−１内に別のアプリがインストールされていると判別した場合（Ｓ１０３でＹＥＳ）。ＣＰＵ１２１は、ＭＦＰ１００−１の記憶装置１０６内で、新アプリと技術的に統合可能なアプリを検索し、新アプリと技術的に統合可能なアプリが存在するか否かを判別する（Ｓ１０５）。

ステップＳ１０５において、新アプリと技術的に統合可能なアプリが存在すると判別した場合（Ｓ１０５でＹＥＳ）、ＣＰＵ１２１は、検索により抽出したアプリを旧アプリとして、新アプリと旧アプリとの統合を許可するか否かを判別する（Ｓ１０７）。ステップＳ１０７においては、上述の第１〜第７の判断基準のうち少なくともいずれかが用いられる。

ステップＳ１０７において、新アプリと旧アプリとの統合を許可すると判別した場合（Ｓ１０７でＹＥＳ）、ＣＰＵ１２１は、旧アプリを新アプリに統合する処理を行う（Ｓ１０９）。次にＣＰＵ１２１は、ＭＦＰ１００−１の操作パネル１０８に新アプリのアイコンを表示するなどのアプリの統合後の処理を行い（Ｓ１１１）、処理を終了する。

ステップＳ１０３において、ＭＦＰ１００−１内に別のアプリがインストールされていないと判別した場合（Ｓ１０３でＮＯ）、ステップＳ１０５において、新アプリと技術的に統合可能なアプリが存在しないと判別した場合（Ｓ１０５でＮＯ）、またはステップＳ１０７において、新アプリと旧アプリとの統合を許可しないと判別した場合（Ｓ１０７でＮＯ）、ＣＰＵ１２１は、処理を終了する。

［ワークフローの一部を実行するアプリを統合する場合のＭＦＰ１００−１の動作］

続いて、本実施の形態の変形例として、ワークフローの一部を実行するアプリを統合する場合のＭＦＰ１００−１の動作について説明する。この動作は、アプリ統合プログラム１６１に基づいてＣＰＵ１２１が実行するものである。

図１０は、本発明の一実施の形態の変形例における各アプリの保存場所の一例と、アプリＡが組み込まれたワークフローの一例を示す図である。図１０（ａ）は各アプリの保存場所の一例を示す図であり、図１０（ｂ）はアプリＡが組み込まれたワークフローの一例を示す図である。

図１０（ａ）を参照して、この例においては、ＭＦＰ１００−１の記憶装置１０６には、スキャンアプリであるアプリＡのプログラムおよびデータベースと、ファクシミリ送信アプリであるアプリＢのプログラムおよびデータベースと、ボックス保存アプリであるアプリＣのプログラムおよびデータベースと、スキャンアプリであるアプリＤのプログラムおよびデータベースと、アプリ統合プログラム１６１と、ＷＦ（Ｗｏｒｋｆｌｏｗ）アプリ１６３のプログラムおよびデータベースとが記憶されている。

図１０（ｂ）を参照して、ＷＦアプリ１６３は、アプリＡ、アプリＢ、およびアプリＣを用いたワークフローを実行するアプリである。具体的には、ＷＦアプリ１６３は、次の（１）〜（３）に示す処理をこの順序で実行する。

（１） スキャンアプリであるアプリＡを呼び出して、アプリＡを用いて、ＭＦＰ１００−１にセットされている原稿のスキャン画像を得る。

（２） ファクシミリ送信アプリであるアプリＢを呼び出して、アプリＢを用いて、スキャン画像を所定の送信先にファクシミリ送信する。

（３） ボックス保存アプリであるアプリＣを呼び出して、アプリＣを用いて、スキャン画像を記憶装置１０６内の所定のボックスに保存する。

図１１は、本発明の一実施の形態の変形例における各アプリの保存場所の他の例を示す図である。

図１１を参照して、この例においては、ＭＦＰ１００−１の記憶装置１０６には、スキャンアプリであるアプリＡのプログラムおよびデータベースと、スキャンアプリであるアプリＤのプログラムおよびデータベースと、アプリ統合プログラム１６１とが記憶されている。ＭＦＰ１００−２の記憶装置１０６には、ファクシミリ送信アプリであるアプリＢのプログラムおよびデータベースが記憶されている。ＭＦＰ１００−３の記憶装置１０６には、ボックス保存アプリであるアプリＣのプログラムおよびデータベースが記憶されている。サーバー２００の記憶装置２０５には、図１０（ｂ）に示すワークフローを実行するＷＦアプリ１６３のデータが記憶されている。

なお、図１１に示す他の例において、ＷＦアプリ１６３のデータは、ＭＦＰ１００−１、ＭＦＰ１００−２、またはＭＦＰ１００−３などに記憶されていてもよい。また、ＷＦアプリ１６３が実行するワークフローは、少なくともアプリＡを用いたものであればよい。

図１２は、本発明の一実施の形態の変形例において、ワークフローの一部を実行するアプリを統合する場合のＭＦＰ１００−１の動作を示す図である。

図１２（ａ）を参照して、アプリＡがＭＦＰ１００−１にインストールされた後で、アプリＤがＭＦＰ１００−１にインストールされる。ＭＦＰ１００−１は、アプリＤがインストールされた後の任意のタイミングで、ＭＦＰ１００−１内のアプリを検索し、アプリＡを抽出し、アプリＤとアプリＡとを技術的に統合することが可能であると判別する。続いてＭＦＰ１００−１は、アプリＤとアプリＡとの統合を許可するか否かを決定する。この決定の際には、上述の第１〜第７の判断基準のうち少なくともいずれかが用いられる。なお、

図１２（ｂ）を参照して、アプリＤとアプリＡとの統合を許可すると決定した場合、ＭＦＰ１００−１は、矢印で示すように、アプリＡのユーザー情報テーブルに記載された情報を、アプリＤのユーザー情報テーブルに引き継ぐ。

図１２（ｃ）を参照して、続いてＭＦＰ１００−１は、ＷＦアプリ１６３のプログラムを修正することにより、ＷＦアプリ１６３におけるスキャンアプリの呼出し先を、アプリＡからアプリＤに変更する。

図１２（ｄ）を参照して、続いてＭＦＰ１００−１は、アプリＡのデータをＭＦＰ１００−１から削除する。以上により統合に関する処理が完了する。

なお、アプリＤとアプリＡとの統合を許可しないと決定した場合、ＭＦＰ１００−１は、アプリＤとアプリＡとの統合を行わず（アプリＡのデータを削除せず）、ＷＦアプリ１６３の修正（呼出し先の変更）も行わない。

［実施の形態の効果］

本実施の形態によれば、類似の古いアプリを新たなアプリに統合することで、ＭＦＰのリソースを増やすことができる。また、ＭＦＰのユーザーが使用すべきアプリを認識しやすくなる。また、ＭＦＰ管理者によるアプリの管理が容易になる。また、新たなアプリをインストールしたにも関わらず古いアプリが使用され続ける事態を回避することができる。一方、古いアプリを新たなアプリに統合した場合に不都合が発生するおそれがあるときは、敢えて統合しない（旧アプリの機能を残す）ことで、統合による混乱を抑止することができる。その結果、利便性を向上することができる。

さらに、ワークフローの一部を実行するアプリを統合する場合、ワークフローを実行するプログラムを修正することにより、ワークフローに影響を与えることなくアプリを統合することができる。特に古いアプリが不具合を含んでいる場合には、古いアプリを新たなアプリに統合することで不具合を解消することができる。一方、ワークフローの一部を実行するアプリを統合しない場合、ユーザーが引き続きワークフローを利用することができ、ワークフローの正しい出力を得ることができる。

［その他］

上述の実施の形態は適宜組み合わせることができる。

上述の実施の形態における処理は、ソフトウェアにより行っても、ハードウェア回路を用いて行ってもよい。また、上述の実施の形態における処理を実行するプログラムを提供することもできるし、そのプログラムをＣＤ−ＲＯＭ、フレキシブルディスク、ハードディスク、ＲＯＭ、ＲＡＭ、メモリカードなどの記録媒体に記録してユーザーに提供することにしてもよい。プログラムは、ＣＰＵなどのコンピューターにより実行される。また、プログラムはインターネットなどの通信回線を介して、装置にダウンロードするようにしてもよい。

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

１００，１００−１，１００−２，１００−３ ＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）
１０１ システムコントローラー
１０２，２０３ メモリ
１０３，２０４ ネットワークインターフェース
１０４ プリントエンジン部
１０５ 出力画像処理部
１０６，２０５ 記憶装置
１０７ 認証装置
１０８ 操作パネル
１０９ スキャナー部
１１０ 入力画像処理部
１２１，２０１ ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）
１２２，２０２ ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）
１５０ アプリケーション層
１５１ａ，１５１ｂ プログラム
１５２ａ，１５２ｂ データベース
１５３ａ，１５３ｂ ユーザー情報テーブル
１５４ｂ プログラムの一部
１６０ アプリケーションＰＦ（Ｐｌａｔｆｏｒｍ）層
１６１ アプリ統合プログラム
１６２ アプリ管理テーブル
１６３ ＷＦ（Ｗｏｒｋｆｌｏｗ）アプリ
１７０ ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）層
２００ サーバー
２０６ 表示部
２０７ 操作部
３００ ネットワーク

Claims (15)

1. 情報処理装置にインストールされた新アプリケーションと技術的に統合可能な旧アプリケーションであって、前記新アプリケーションがインストールされるよりも前に前記情報処理装置にインストールされた旧アプリケーションを検索する検索手段と、
   前記新アプリケーションと前記旧アプリケーションとを技術的に統合することが可能であるか否かを判別する判別手段と、
   前記新アプリケーションと前記旧アプリケーションとを技術的に統合することが可能であると前記判別手段にて判別した場合に、前記新アプリケーションと前記旧アプリケーションとの統合を許可するか否かを決定する決定手段と、
   前記決定手段による決定に従って、前記新アプリケーションと前記旧アプリケーションとを統合する統合手段とを備えた、アプリケーション統合装置。
2. 前記旧アプリケーションに関する情報を前記情報処理装置から取得する取得手段をさらに備え、
   前記決定手段は、前記取得手段にて取得した情報に基づいて、前記新アプリケーションと前記旧アプリケーションとの統合を許可するか否かを決定する、請求項１に記載のアプリケーション統合装置。
3. 前記取得手段は、前記新アプリケーションに関する情報を前記情報処理装置からさらに取得する、請求項２に記載のアプリケーション統合装置。
4. 前記取得手段は、前記新アプリケーションおよび前記旧アプリケーションの各々が提供する機能の情報を取得し、
   前記決定手段は、前記新アプリケーションが提供する機能に、前記旧アプリケーションが提供する機能の少なくとも一部が包含されない場合に、前記新アプリケーションと前記旧アプリケーションとの統合を許可しないと決定する、請求項３に記載のアプリケーション統合装置。
5. 前記取得手段は、前記新アプリケーションおよび前記旧アプリケーションの各々が出力するデータの形式の情報を取得し、
   前記決定手段は、前記新アプリケーションが出力するデータの形式と、前記旧アプリケーションが出力するデータの形式とが一致しない場合に、前記新アプリケーションと前記旧アプリケーションとの統合を許可しないと決定する、請求項３または４に記載のアプリケーション統合装置。
6. 前記取得手段は、前記新アプリケーションおよび前記旧アプリケーションの各々を使用可能なグループの情報を取得し、
   前記決定手段は、前記新アプリケーションを使用可能なグループに、前記旧アプリケーションを使用可能なグループの少なくとも一部が包含されない場合に、前記新アプリケーションと前記旧アプリケーションとの統合を許可しないと決定する、請求項３〜５のいずれかに記載のアプリケーション統合装置。
7. 前記取得手段は、前記新アプリケーションおよび前記旧アプリケーションの各々を使用可能なユーザーの情報を取得し、
   前記決定手段は、前記新アプリケーションを使用可能なユーザーに、前記旧アプリケーションを使用可能なユーザーの少なくとも一部が包含されない場合に、前記新アプリケーションと前記旧アプリケーションとの統合を許可しないと決定する、請求項３〜６のいずれかに記載のアプリケーション統合装置。
8. 前記取得手段は、前記新アプリケーションおよび前記旧アプリケーションの各々の管理者の情報を取得し、
   前記決定手段は、前記新アプリケーションの管理者と前記旧アプリケーションの管理者とが一致しない場合に、前記新アプリケーションと前記旧アプリケーションとの統合を許可しないと決定する、請求項３〜７のいずれかに記載のアプリケーション統合装置。
9. 前記取得手段は、前記新アプリケーションおよび前記旧アプリケーションの各々の課金先の情報を取得し、
   前記決定手段は、前記新アプリケーションの課金先と、前記旧アプリケーションの課金先とが一致しない場合に、前記新アプリケーションと前記旧アプリケーションとの統合を許可しないと決定する、請求項３〜８のいずれかに記載のアプリケーション統合装置。
10. 前記取得手段は、前記旧アプリケーションの使用履歴に関する情報を取得し、
    前記決定手段は、前記旧アプリケーションが第１の期間内に使用された頻度が所定の回数以上である場合、および前記旧アプリケーションが第２の期間内に使用されている場合のうち少なくともいずれか１つの場合に、前記新アプリケーションと前記旧アプリケーションとの統合を許可しないと決定する、請求項２〜９のいずれかに記載のアプリケーション統合装置。
11. 前記統合手段は、前記旧アプリケーションのデータを前記情報処理装置から削除する削除手段を含む、請求項１〜１０のいずれかに記載のアプリケーション統合装置。
12. 前記統合手段は、前記新アプリケーションのプログラムを修正するプログラム修正手段をさらに含む、請求項１１に記載のアプリケーション統合装置。
13. 前記統合手段は、前記旧アプリケーションを用いたワークフローを実行するプログラムを修正するフロー修正手段をさらに含む、請求項１１または１２に記載のアプリケーション統合装置。
14. 前記情報処理装置と前記アプリケーション統合装置とは、同一の装置である、請求項１〜１３のいずれかに記載のアプリケーション統合装置。
15. 情報処理装置にインストールされた新アプリケーションと技術的に統合可能な旧アプリケーションであって、前記新アプリケーションがインストールされるよりも前に前記情報処理装置にインストールされた旧アプリケーションを検索する検索ステップと、
    前記新アプリケーションと前記旧アプリケーションとを技術的に統合することが可能であるか否かを判別する判別ステップと、
    前記新アプリケーションと前記旧アプリケーションとを技術的に統合することが可能であると前記判別ステップにて判別した場合に、前記新アプリケーションと前記旧アプリケーションとの統合を許可するか否かを決定する決定ステップと、
    前記決定ステップにおける決定に従って、前記新アプリケーションと前記旧アプリケーションとを統合する統合ステップとをコンピューターに実行させる、アプリケーション統合装置の制御プログラム。

Images