特許 7455601 情報処理装置とその制御方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-03-15

(45)【発行日】2024-03-26

(54)【発明の名称】情報処理装置とその制御方法、及びプログラム

(51)【国際特許分類】

   H04N 1/00 20060101AFI20240318BHJP

   B41J 29/38 20060101ALI20240318BHJP

   G06F 8/61 20180101ALI20240318BHJP

   G06Q 10/10 20230101ALI20240318BHJP

   G06F 3/12 20060101ALI20240318BHJP

【ＦＩ】

H04N1/00 912

B41J29/38 203

H04N1/00 127A

G06F8/61

G06Q10/10

G06F3/12 330

G06F3/12 320

【請求項の数】 7

(21)【出願番号】P 2020018214

(22)【出願日】2020-02-05

(65)【公開番号】P2021125800

(43)【公開日】2021-08-30

【審査請求日】2023-01-27

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】110003281

【氏名又は名称】弁理士法人大塚国際特許事務所

(72)【発明者】

【氏名】王 暁立

【審査官】花田 尚樹

(56)【参考文献】

【文献】特開２００７－０５３５５８（ＪＰ，Ａ）

【文献】特表２０１９－５０１４３１（ＪＰ，Ａ）

【文献】特開２０１５－０２６１２０（ＪＰ，Ａ）

【文献】特開２０１０－０１１４６８（ＪＰ，Ａ）

【文献】特開２０１９－１５９８２５（ＪＰ，Ａ）

【文献】特開２０１９－０８７９２２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ １／００

Ｂ４１Ｊ ２９／００ －２９／７０

Ｇ０６Ｆ ８／００ － ８／３８

８／６０ － ８／７７

９／４４ － ９／４４５

９／４５１

Ｇ０６Ｆ １９／００

Ｇ０６Ｑ １０／００ －１０／１０

３０／００ －３０／０８

５０／００ －５０／２０

５０／２６ －９９／００

Ｇ０６Ｆ ３／０９ － ３／１２

(57)【特許請求の範囲】

【請求項1】

拡張機能を提供するアプリをインストールして実行できる情報処理装置であって、
ログインしたユーザに紐づけられた、或いは当該ログインしたユーザにより指定されたコンテナ化されたアプリをサーバから取得する取得手段と、
前記取得手段により取得した前記コンテナ化されたアプリを記憶する記憶手段と、
前記記憶手段の空き容量が所定量以下の場合、前記記憶手段に記憶されている複数のコンテナ化されたアプリのそれぞれに対して、当該コンテナ化されたアプリを利用しているユーザの数が多いほど大きい重みを付ける重み付け手段と、
前記ログインしたユーザのログアウトに応じて、前記記憶手段に記憶されている前記コンテナ化されたアプリのそれぞれの前記重みの小さい順に、前記記憶手段の空き容量が前記所定量よりも大きくなるまで前記記憶手段に記憶されているコンテナ化されたアプリを削除する削除手段と、
を有することを特徴とする情報処理装置。

【請求項2】

前記取得手段は、前記ログインしたユーザのユーザ情報に紐づけられた前記コンテナ化されたアプリを前記サーバから取得することを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記削除手段は、前記記憶手段の空き容量が前記所定量以下のときに前記コンテナ化されたアプリを削除することを特徴とする請求項１又は２に記載の情報処理装置。

【請求項4】

前記取得手段は、前記ログインしたユーザに紐づけられた、或いは当該ログインしたユーザにより指定されたコンテナ化されたアプリを前記情報処理装置が有していない場合に、当該コンテナ化されたアプリを前記サーバから取得することを特徴とする請求項１に記載の情報処理装置。

【請求項5】

前記コンテナ化されたアプリは、アプリケーションと、ライブラリ及びＯＳ（オペレーティングシステム）の一部を含み、コンテナエンジンの上で動作することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。

【請求項6】

拡張機能を提供するアプリをインストールして実行できる情報処理装置を制御する制御方法であって、
ログインしたユーザに紐づけられた、或いは当該ログインしたユーザにより指定されたコンテナ化されたアプリをサーバから取得する取得工程と、
前記取得工程により取得した前記コンテナ化されたアプリを記憶手段に記憶する記憶工程と、
前記記憶手段の空き容量が所定量以下の場合、前記記憶手段に記憶されている複数のコンテナ化されたアプリのそれぞれに対して、当該コンテナ化されたアプリを利用しているユーザの数が多いほど大きい重みを付ける重み付け工程と、
前記ログインしたユーザのログアウトに応じて、前記記憶手段に記憶されている前記コンテナ化されたアプリのそれぞれの前記重みの小さい順に、前記記憶手段の空き容量が前記所定量よりも大きくなるまで前記記憶手段に記憶されているコンテナ化されたアプリを削除する削除工程と、
を有することを特徴とする制御方法。

【請求項7】

コンピュータを、請求項１乃至５のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

電子機器では、アプリケーションをインストールすることによって、本来有している基本機能に加えて、新たな別の機能を追加することができる。例えば、スマートフォンでは、アプリストアから拡張アプリケーションをダウンロードすることで、そのスマートフォンに新たな機能を追加することができる。また、スマートフォンより前の時代でも、パソコンにアプリケーションをインストールして、そのパソコンで実行できる機能を追加することができた。同様に、プリンタ等の画像形成装置においても、パソコンやスマートフォン等のように、新たにアプリケーションをインストールすることにより、その機能を追加することができる。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１９－１４９１９２号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

昨今、コンテナ技術と呼ばれる、必要なソフト部品をパッケージ化し、実行環境を選ぶことなく、どこでも動作できるようにする技術が提案されている。例えば特許文献１は、コンテナ単位ではなく、複数のコンテナで構成されたタスク単位でリソースを管理することで、ソフトウェアの管理や調整をしやすくできる技術を記載している。

【0005】

本来、コピーやプリントなどの基本機能を実現するため設計された画像形成装置では、ハードウェアのリソースが限られている。このため、拡張機能を利用できるアプリを事前に画像形成装置にインストールしておくと、大容量のアプリを格納できるだけの容量をストレージに確保できなくなる。特に多くのユーザが使用する画像形成装置の場合、多様なユーザのニーズやユースケースに対応するため、大量のアプリをインストールする必要があるが、ストレージの容量の点で、これらアプリをインストールすることができなかった。

【0006】

本発明の目的は、上記従来技術の課題の少なくとも一つを解決することにある。

【0007】

本発明の目的は、インストールしたコンテナ化されたアプリによる記憶手段の空きメモリ容量の減少を防止できる技術を提供することにある。

【課題を解決するための手段】

【0008】

上記目的を達成するために本発明の一態様に係る情報処理装置は以下のような構成を備える。即ち、
拡張機能を提供するアプリをインストールして実行できる情報処理装置であって、
ログインしたユーザに紐づけられた、或いは当該ログインしたユーザにより指定されたコンテナ化されたアプリをサーバから取得する取得手段と、
前記取得手段により取得した前記コンテナ化されたアプリを記憶する記憶手段と、
前記記憶手段の空き容量が所定量以下の場合、前記記憶手段に記憶されている複数のコンテナ化されたアプリのそれぞれに対して、当該コンテナ化されたアプリを利用しているユーザの数が多いほど大きい重みを付ける重み付け手段と、
前記ログインしたユーザのログアウトに応じて、前記記憶手段に記憶されている前記コンテナ化されたアプリのそれぞれの前記重みの小さい順に、前記記憶手段の空き容量が前記所定量よりも大きくなるまで前記記憶手段に記憶されているコンテナ化されたアプリを削除する削除手段と、を有することを特徴とする。

【発明の効果】

【0009】

本発明によれば、インストールしたコンテナ化されたアプリによる記憶手段の空きメモリ容量の減少を防止できるという効果がある。

【0010】

本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

【図面の簡単な説明】

【0011】

添付図面は明細書に含まれ、その一部を構成し、本発明の実施形態を示し、その記述と共に本発明の原理を説明するために用いられる。

【図1】本発明の実施形態に係る画像形成装置のハードウェア構成を説明するブロック図。

【図2】実施形態に係る画像形成装置のコントローラのハードウェア構成を説明するブロック図。

【図3】一般的な画像形成装置におけるネイティブアプリと仮想マシンでのソフトウェアシステム構成を説明する図。

【図4】実施形態に係るコンテナ技術を説明する図。

【図5】従来技術もしくはそれをコンテナ化した場合の課題を説明する図。

【図6】実施形態に係る画像形成装置を含むシステム構成を説明する図。

【図7】実施形態に係る画像形成装置におけるユーザのプロファイルとアプリの分類の一例を示す図。

【図8】実施形態に係る画像形成装置におけるアプリの取得及び実行処理を説明するフローチャート。

【図9】実施形態に係る画像形成装置における終了処理を説明するフローチャート。

【図10】実施形態に係る画像形成装置におけるアプリケーションの取得を説明する図。

【発明を実施するための形態】

【0012】

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これら複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一もしくは同様の構成に同一の参照番号を付し、重複した説明は省略する。尚、以下の実施形態では、本発明に係る情報処理装置の一例を画像形成装置を例に説明する。

【0013】

図１は、本発明の実施形態に係る画像形成装置１０１のハードウェア構成を説明するブロック図である。

【0014】

スキャナ１０２は、原稿の画像を光学的に読み取ってデジタル画像データに変換する。プリンタ部１０４は、デジタル画像データに基づいて用紙に画像を形成（印刷）する。操作部１０５は、この画像形成装置１０１に対するユーザの操作を受付けるとともに、各種情報をユーザに提示する。尚、この操作部１０５は、タッチパネル機能を有する表示部を有していてもよい。ストレージ１０６は、デジタル画像データや制御プログラム等を記憶する大容量の記憶装置である。このストレージ１０６は、例えばハードデスクドライブ（ＨＤＤ）或いはＳＤメモリ等を含んでいる。ＦＡＸ部１０７は、電話回線等を介してデジタル画像データをファクシミリで送受信する。コントローラ（制御部）１０３は、前述した各部と接続し、各部を制御することで画像形成装置１０１上で各種ジョブを実行することができる。また画像形成装置１０１は、ＬＡＮ１０８経由で、コンピュータ１０９との間でデジタル画像データ等の送受信を行うことができる。またコンピュータ１０９は、画像形成装置１０１に対してジョブを発行したり、機器の指示等も行なうことが可能である。

【0015】

スキャナ１０２は、原稿束を積載して、自動的に原稿を給紙できる原稿給紙ユニット１２１、原稿を光学スキャンしてデジタル画像データに変換するスキャナユニット１２２を有しており、変換された画像データはコントローラ１０３に送信される。プリンタ部１０４は、用紙束から一枚ずつ用紙（シート）を給紙可能な給紙ユニット１４２、給紙した用紙に画像データを印刷するためのマーキングユニット１４１、印刷後の用紙を排紙するための排紙ユニット１４３を有している。

【0016】

またコンピュータ１０９は、ＬＡＮ１０８を経由で、コントローラ１０３に指示を出してジョブを実行させる。この実施形態では、コンピュータ１０９はコントローラ１０３にＯＦＦ指示を送信することにより、コントローラ１０３は画像形成装置１０１のＯＦＦプロセスを制御することができる。

【0017】

この画像形成装置１０１は、多彩なジョブを実行可能である。これらジョブの一例を以下に記載する。
・複写機能
スキャナ１０２で読み込んだ原稿の画像の画像データをストレージ１０６に記録し、プリンタ部１０４を使用して印刷を行なう。
・画像送信機能
スキャナ１０２から得られた画像データをＬＡＮ１０８を介してコンピュータ１０９に送信する。
・画像保存機能
スキャナ１０２から読み込んだ画像をストレージ１０６に記憶し、必要に応じて画像送信や印刷を行なう。
・画像印刷機能
コンピュータ１０９から送信された例えばページ記述言語を解析し、プリンタ部１０４で印刷する。

【0018】

図２は、実施形態に係る画像形成装置１０１のコントローラ１０３のハードウェア構成を説明するブロック図である。

【0019】

コントローラ１０３は、メインボード２００と、サブシステム２２０とを具備している。メインボード２００はいわゆる汎用的なＣＰＵシステムである。メインボード２００は、ボード全体を制御するメインＣＰＵ２０１、ブートプログラムを記憶するブートロム２０２、メインＣＰＵ２０１がワークメモリとして使用するメモリ２０３を有している。更にメインボード２００は、外部バスとのブリッジ機能を持つバスコントローラ２０４、電源がオフされた場合でもその内容が消えない不揮発性メモリ２０５、時計機能を有するＲＴＣ２１１を有している。メインボード２００は更に、ストレージ１０６を制御するディスクコントローラ２０６と、半導体デバイスで構成された比較的小容量な不揮発性記憶装置であるフラッシュディスク（ＳＳＤ等）２０７、ＵＳＢを制御可能なＵＳＢコントローラ２０８を有している。こうしてメインボード２００には外部に、ＵＳＢメモリ２０９、操作部１０５、ストレージ１０６等が接続される。

【0020】

サブボード２２０は、比較的小さな汎用サブＣＰＵシステムと、画像処理ハードウェアを有している。サブボード２２０は、ボード全体を制御するサブＣＰＵ２２１、ＣＰＵ２２１がワークメモリとして使用するメモリ２２３、外部バスとのブリッジ機能を持つバスコントローラ２２４、電源がオフされた場合でもその内容が消えない不揮発性メモリ２２５を有している。サブボード２２０は更に、リアルタイムでデジタル画像処理を行なう画像処理プロセッサ２２７と、それぞれがプリンタ部１０４とスキャナ１０２とを制御するエンジンコントローラ２２６，２２８を有している。スキャナ１０２とプリンタ部１０４は、プリンタコントローラであるエンジンコントローラ２２６、及びスキャナコントローラであるエンジンコントローラ２２８を介してデジタル画像データの受け渡しを行なう。尚、ＦＡＸ部１０７は、サブＣＰＵ２２１が直接制御を行なう。

【0021】

尚、この図２はあくまでもブロック図で簡略化して示している。例えばメインＣＰＵ２０１、サブＣＰＵ２２１等にはチップセット、バスブリッジ、クロックジェネレータ等のＣＰＵ周辺のハードウェアが多数含まれているが、これらは実施形態の説明に不必要であるため簡略化して記載している。

【0022】

次に、コントローラ１０３による制御処理について、例えば用紙への画像複写を例に説明する。

【0023】

いま利用者が操作部１０５から画像の複写（コピー）を指示すると、メインＣＰＵ２０１は、サブＣＰＵ２２１を介してスキャナ１０２に画像読み取り命令を送る。これによりスキャナ１０２は、原稿を光学的にスキャンして読み取り、その原稿の画像に対応するデジタル画像データに変換し、エンジンコントローラ２２８を介して画像処理プロセッサ２２７に入力する。画像処理プロセッサ２２７は、そのデジタル画像データをＤＭＡ転送でメモリ２２３に一時保存する。メインＣＰＵ２０１は、デジタル画像データがメモリ２２３に一定量もしくは全て記憶されたことを確認すると、サブＣＰＵ２２１を介してプリンタ部１０４に画像出力指示を出す。サブＣＰＵ２２１は、画像処理プロセッサ２２７にメモリ２２３における画像データのアドレスを教え、プリンタ部１０４からの同期信号に従ってメモリ２２３の画像データをプリンタ部１０４に送信する。このとき画像処理プロセッサ２２７とエンジンコントローラ２２６を介して画像データがプリンタ部１０４に送信され、プリンタ部１０４で用紙（シート）にデジタル画像データが印刷される。

【0024】

また複数部の印刷を行なう場合、メインＣＰＵ２０１がメモリ２２３の画像データをストレージ１０６に保存し、２部目以降は、スキャナ１０２から画像データを入手せずに、ストレージ１０６から読み出した画像データをプリンタ部１０４に出力して印刷させることが可能である。

【0025】

尚、実施形態に係る画像形成装置１０１のコントローラ１０３は、図２のように、メインボードとサブボードとで構成されるものに限定されない。

【0026】

図３は、一般的な画像形成装置におけるネイティブアプリと仮想マシンでのソフトウェアシステム構成を説明する図である。

【0027】

図３（Ａ）は、ネイティブアプリを説明する図である。ネイティブアプリでは、動作に必要なハードウェア（ＨＷ）３０１で、それを管理する基本ソフト（ＯＳ：オペレーティングシステム）３０２があり、アプリ３０５に対して機能を提供するライブラリ群３０３－１～３０３－Ｎ）が存在している。いまアプリ３０５が動作してユーザに機能を提供する場合、アプリ３０５は、ライブラリ群３０３－１～３０３－Ｎを使用して基本ソフト３０２及びハードウェア３０１の資源にアクセスする。

【0028】

図３（Ａ）に示すソフトウェアシステムで、アプリ３０５が動作するために使われるライブラリや基本ソフト部品以外、使われないライブラリや基本ソフト部品が存在する。そのため、システムが肥大化し、大量にメモリ容量を消費する。

【0029】

図３（Ｂ）は、仮想マシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）を説明する図である。

【0030】

ハードウェア（ＨＷ）３１１に、基本ソフト３１２（ホストＯＳ）と仮想マシンハイパーバイザ（ＶＭ Ｈｙｐｅｒｖｉｓｏｒ）３１３と呼ばれる仮想ソフトがある。そして、その仮想マシンハイパーバイザ３１３上で複数の仮想マシン３１４－１～３１４－Ｎが動作する。これらの仮想マシン３１４－１～３１４－Ｎは、ハイパーバイザ３１３を介してハードウェア３１１にアクセスする。これにより、複数のシステムがハードウェアをシェアすることができるようになる。

【0031】

このように仮想マシンシステムは、ネイティブ環境と比べて、仮想マシンの可搬性があり、仮想マシンハイパーバイザ３１３がインストールされた環境で実行可能である。尚、運用上、必要となる際にイメージと呼ばれる仮想マシンファイルから作成し、使わなくなるとシャットダウンすることで、ネイティブよりリソースを有効に利用することができる。

【0032】

しかし、仮想マシンシステムは、ネイティブシステムと同様に、使わないソフト部品が大量に存在するため、ストレージの無駄が生じやすく、画像形成装置の立ち上がりから機能を提供するまでに多くの時間を要することがある。

【0033】

図４は、実施形態に係るコンテナ技術を説明する図である。

【0034】

昨今、コンテナと呼ばれる新しい仮想化技術が使使用されるようになっている。仮想マシンとは、複数のソフトウェアシステムが、１つのハードウェアをシェアすることである。仮想マシンの場合、図３（Ｂ）に示すように、ホストＯＳ３１２上に、ゲストＯＳ１～ゲストＯＳＮがまるごと存在し、その上のライブラリ群もＬｉｂ群１～Ｌｉｂ群Ｎまで全部揃っている（ネイティブアプリソフトシステムと同様）とする。

【0035】

一方、図４（Ａ）のように、コンテナ技術を適用した場合、コンテナ１は、アプリ１（Ａｐｐ１）の実行に必要なライブラリ群１（４０１）と必要なＯＳ部品１（４０２）のみ含んでいる。このコンテナ技術は、アプリを実行するときに、必要なライブラリとＯＳの一部、及びその設定をまとめてコンテナ化するものである。このコンテナは、実行環境でのコンテナエンジン（例えば、Docker Engine）で上で動作する。このときコンテナエンジンは、コンテナとハードウェアとの差分を吸収する。このようにコンテナは、必要なソフトウェア部品しか持っていないため軽量で、可搬性が高く、且つ、実行環境を選ばない（コンテナエンジンがある限り）という利点を有している。

【0036】

図４（Ｂ）は、複数のコンテナが動作する場合を説明する図である。図４（Ｂ）では、コンテナ１～Ｎがコンテナエンジン４０３上で動作している。このコンテナエンジン４０３は、ハードウェア４０４とコンテナ１～Ｎとの差分を吸収する。

【0037】

尚、このようなコンテナは、専用ツールを使用して、コンテナイメージファイルと呼ばれるコンテナの雛形やテンプレートを作成される。そして、新たな機能を機器に提供する際は、そのイメージファイルを用いてコンテナの実例（インスタンス）を生成する。そして、そのインスタンスをコンテナエンジン（Ｃｏｎｔａｉｎｅｒ Ｅｎｇｉｎｅ）４０３と呼ばれるソフトウェア上で実行することで、その機能を提供することができる。そして、その機能が必要でなくなると、そのインスタンスを停止或いは削除することによって、リソースを解放する。

【0038】

このようなコンテナ技術を用いることにより、従来の仮想マシンと比べて、必要ソフトウェア部品しか必要としないため、新たな機能を提供するためのアプリを実装しても、それにより消費されるメモリ容量が比較的に小さくて済む。そのため、新たな機能を提供するためのオーバーヘッド（起動するための時間、リソースなど）が少なくなり、アクセス数が予想しにくい場合等に柔軟に対応できる。例えば、ユーザ数が不定な通販サイトの場合などで、ユーザによるアクセスが発生し、その数が増えた場合は、新たなインスタンスを立ち上げて、更に機能を提供することができる。そして、そのアクセスが終了した場合は、そのインスタンスを削除してメモリを解放することができる。

【0039】

このようにコンテナ技術と仮想マシンとを比較すると、コンテナ技術では以下のような利点がある。
（１）不要なソフトウェア部品を持っていないため、消費されるメモリ容量が小さく、起動時のオーバーヘッドが小さい。
（２）仮想マシンと同様に、一定な可搬性を持っているコンテナエンジン４０３があれば実行できる。またネイティブアプリのように、アプリケーションのインストールが不要である。

【0040】

図５は、従来技術もしくはそれをコンテナ化した場合の課題を説明する図である。

【0041】

従来技術（ネイティブアプリ）の場合、ユーザがアプリを利用する前に、ユーザアプリ５０１を不揮発性メモリ５０４にインストールする必要がある。このように、利用する前にアプリ５０１をインストールする必要があるため、管理者に負荷がかかる。

【0042】

例えば画像形成装置の場合、ユーザアプリ５０１を不揮発性メモリ５０４もしくはストレージ５０５にインストールする必要がある。どのアプリをインストールするか、或いはアプリのバージョンアップなどは管理者によって管理される。

【0043】

一方、画像形成装置が、プリントやスキャンなどの基本機能を実現するための装置である場合、拡張機能を実現するためのアプリを格納する領域が大きくはない。

【0044】

図５では、不揮発性メモリ５０４が画像形成装置を制御するプログラムを格納する記憶装置であるため、最小限の容量をしか持たないので、拡張機能を実現するアプリを不揮発性メモリ５０４にはインストールするのは望ましくない。

【0045】

一方、ストレージ５０５の場合、コピー時では、スキャンで得られた画像データをプリントする前に、一時格納する画像領域５０２のデータ量が大きくなり、ユーザアプリ５０１の格納に使える領域であるアプリ領域５０３のメモリ容量が小さくなる。

【0046】

以上の説明をまとめると、利用するユーザアプリ５０１は、ストレージのアプリ領域５０３へインストールする必要がある。しかしながらアプリ領域５０３の容量が、例えば数ＧＢしかない場合に対して、ユーザアプリ５０１が一本あたり、数十ＭＢ～数百ＭＢ程度のメモリ容量を消費する。そのため通常、インストールできるアプリの数は１０本程度に制限されることになる。これはコンテナ技術を利用した場合に、多少改善される。

【0047】

一方、世の中のコワーキングスペース（複数の会社や団体がオフィスをシェアすること）やフリーアドレス制（固定した座席を持たないこと）の普及によって、従来より画像形成装置を利用するユーザ数が増えると見込まれる。このように、同じ職場に、異なる組織や職種のユーザが、異なるアプリを利用する状況を想定すると、現行技術のように、ローカルストレージでネイティブアプリをインストールして機能を提供すると、提供する機能が不十分か、ストレージが満杯となる恐れがある。

【0048】

図６は、実施形態に係る画像形成装置１０１を含むシステム構成を説明する図である。ここでは上記課題を解決するため、コンテナ化したアプリをサーバに置き、画像形成装置１０１が必要に応じてサーバからコンテナを取得する技術を提案する。

【0049】

業者６０１は、既存アプリをコンテナに変換し、ユーザのオンプレサーバ６０２及びＷｅｂサーバ６０３へ納入する。オンプレサーバ６０２には容量制限があるため、比較的に利用頻度の高いアプリ、もしくはユーザが指定したアプリがオンプレサーバ６０２に格納される。尚、ここでオンプレミスとは、サーバやソフトウェアなどの情報システムを使用者（ビジネス利用の場合は企業）が管理する設備内に設置し、運用することを指す。一方、ユーザ側の管理者６０４は、オンプレサーバ６０２と画像形成装置１０１に対して設定を行い、アプリのコンテナ（以下単に、コンテナと言う）の取得先などを入力する。

【0050】

次にユーザ６０６が画像形成装置１０１にログインする。画像形成装置１０１は、ログインしたユーザのプロファイルやユーザの操作に応じて、６０５で、コンテナをオンプレサーバ６０２に要求する。オンプレサーバ６０２は、この要求に応じて、６０６でコンテナを画像形成装置１０１に転送する。

【0051】

このとき画像形成装置１０１が要求したコンテナがオンプレサーバ６０２にない場合、画像形成装置１０１は、６０７で、Ｗｅｂサーバ６０３にそれを要求し、６０８で、その要求したコンテナを取得する。そして、ユーザがその機能を利用した後、そのコンテナ（もしくはその一部）を削除する。このようにして、画像形成装置１０１のストレージ１０６のメモリの利用量を削減することができる。

【0052】

重み付け部６０９は、こうしてストレージ１０６に格納されたアプリの重み付けを行う。そしてユーザ６０６がログアウトすると、削除部６１０は、ストレージ１０６に格納されているアプリを、その重み付けに従って削除することで、ストレージ１０６の空き容量が所定量以下にならないようにしている。これらの処理は図９のフローチャート等を参照して詳しく後述する。

【0053】

図７は、実施形態に係る画像形成装置１０１におけるユーザのプロファイルとアプリの分類の一例を示す図である。これは以下の説明の便宜上、アプリをコンテナ化した場合、ユーザやアプリの分類例を示す一実施形態であり、本発明の解決に必須のものとは限らない。尚、この分類の目的は、ユーザのプロファイルに応じて使われそうなアプリを取得することによって、ストレージの利用量を制限できる。

【0054】

図７（Ａ）は、画像形成装置１０１を利用するユーザのプロファイルの一例を示す。

【0055】

「役割」を基準にして分類すると、社員は「経営陣」、「管理職」、「一般職」、「委託」などに分類することができる。また「職種」を基準に分類すると、社員は「経理」、「企画」、「人事」、「営業」、「知財」、「研究開発」、「品保」、「製造」、「販売」などに分類することができる。また、ここで一人の社員は、複数のグループに属することができる。例えば、Ａさんは「一般職」グループ、「営業」グループに属し、Ｂさんは「管理職」グループ、「研究開発」グループに属しても良い。そして管理者が、これらグループと、所定のコンテナとを紐づける。

【0056】

図７（Ｂ）は、アプリの分類を説明する図である。

【0057】

ここで「基本アプリ」は、誰でも使用できるアプリである（例えばネットワークプリント等）。そのため実施形態では、常に画像形成装置１０１に保持されている。「グループアプリ」は、グループに紐付いているアプリである。例えば「営業」の場合、その「営業」に紐づいているアプリとして名刺管理ソフトなどがある。従って、例えば「営業」グループのユーザがログインすると、画像形成装置１０１は、その名刺管理ソフトのコンテナをサーバから取得する。このグループアプリは、通常、事前に指定しなければならないので、オンプレサーバ６０２に格納される。

【0058】

「個人アプリ」は、ユーザ個人が指定したアプリである。例えば、営業のＡさんの場合、Ａさんは外回り営業を行うため、予定情報を管理するため「スケジュール管理」アプリを指定する。

【0059】

「他アプリ」は、上記グループのいずれにも属さないアプリである。例えばユーザが事前に指定しなかったが、そのユーザが画像形成装置１０１を利用している途中で指定するアプリである。

【0060】

このように画像形成装置１０１は、ログインしたユーザのプロファイルに応じて、必要なアプリをサーバから取得することができる。

【0061】

図８は、実施形態に係る画像形成装置１０１におけるアプリの取得及び実行処理を説明するフローチャートである。尚、このフローチャートで示す処理は、メインＣＰＵ２０１（以下、単にＣＰＵ２０１）がメモリ２０３に展開したプログラムを実行することにより実現される。この処理は、ユーザが画像形成装置１０１にログインすることにより開始される。ここでユーザは、パスワードの入力、もしくはカードをかざす等により認証に成功するとＣＰＵ２０１は、そのユーザを特定した後、以下の処理を実行する。尚、以下で説明するアプリは、コンテナ化されたアプリケーションを指す。

【0062】

先ずＳ８０１でＣＰＵ２０１は、サーバに問い合わせて、そのログインしたユーザのユーザ情報を取得するか、或いはログイン用カードに書かれたユーザ情報を取得する。尚、このとき、画像形成装置１０１がそのログインしたユーザのユーザ情報を記憶している場合は、サーバへの問い合わせは行わない。次にＳ８０２に進みＣＰＵ２０１は、そのユーザ情報に基づいて、そのユーザが所属する「グループ」に紐付いているアプリ、及びそのユーザが指定した「個人アプリ」が画像形成装置１０１に存在するか判定する。ここで存在しないと判定した場合はＳ８０３に進みＣＰＵ２０１は、そのアプリをサーバから取得してＳ８０４に進む。一方、Ｓ８０２で画像形成装置１０１に存在すると判定した場合は、そのままＳ８０４に進む。

【0063】

Ｓ８０４でＣＰＵ２０１は、そのユーザによるユーザ操作を受け付ける。そしてＳ８０５に進みＣＰＵ２０１は、ユーザの操作で更に「他アプリ」が指定されたかどうか判定する。ここで「他アプリ」が指定されないときはＳ８０３で取得した「グループアプリ」或いは「個人アプリ」による処理であるためＳ８０７に進む。一方、Ｓ８０５で「他アプリ」が指定されたときはＳ８０６に進みＣＰＵ２０１は、その「他アプリ」が画像形成装置１０１に存在するかどうか判定する。ここで存在しないと判定した場合はＳ８０８に進みＣＰＵ２０１は、オンプレサーバ６０２もしくはＷｅｂサーバ６０３から、その「他アプリ」を取得してＳ８０７に進む。一方、Ｓ８０６で「他アプリ」が画像形成装置１０１に存在すると判定した場合はＳ８０７に進む。Ｓ８０７でＣＰＵ２０１は、そのユーザにより指定された「グループアプリ」、「個人アプリ」或いは「他アプリ」を実行して処理を行う。そしてＳ８０９に進みＣＰＵ２０１は、ユーザがログアウトしたかどうか判定し、ログアウトしたときはこの処理を終了し、ログアウトしていないときはＳ８０４に進んで、ユーザ操作に応じた処理を実行する。尚、ユーザがユーザログアウトするとＳ８１０に進んでＣＰＵ２０１は終了処理を行った後、次のユーザログインを待つ。

【0064】

以上説明したようにこの処理によれば、ログインしたユーザのユーザ情報に紐づけられたアプリ、或いはそのユーザが指定した個人アプリを、ユーザが操作する前に事前に取得して実行できるようにしておくことにより、ログインしたユーザは直ぐに所望の処理を実行できる。またユーザがログインすることで初めてアプリを取得するので、画像形成装置のストレージのメモリが、常にそれらアプリで占有されるのを防止できる。

【0065】

また、ログインしたユーザに関連するアプリ以外のアプリは、そのユーザが指示して初めて外部のサーバから取得されるので、画像形成装置のストレージのメモリが、常にそれらアプリで占有されるのを防止できる。

【0066】

図９は、実施形態に係る画像形成装置１０１における終了処理を説明するフローチャートである。尚、このフローチャートで示す処理は、ＣＰＵ２０１がメモリ２０３に展開したプログラムを実行することにより実現される。この処理は、ユーザがログアウトした後、次のユーザがログインする際に使えるようにするために画像形成装置１０１がストレージ１０６のメモリ容量を解放するものである。

【0067】

画像形成装置１０１が終了処理を開始するとＳ９０１に進みＣＰＵ２０１は、ログアウトした以前のユーザがログイン時にＷｅｂサーバからアプリを取得していた場合、そのアプリをオンプレサーバ６０２へ転送する。この理由は、オンプレサーバ６０２にないアプリが使われていたため、今後、そのアプリが再度使用される可能性があるため、そのアプリをオンプレサーバ６０２に保持するためである。これはまた、Ｗｅｂサーバ６０３からオンプレサーバ６０２へアプリを転送すると、帯域を圧迫する事となるため、画像形成装置１０１からオンプレサーバ６０２にアプリを転送するのが望ましい。つまり、オンプレサーバ６０２がＷｅｂサーバ６０３のキャッシュとして機能することになる。

【0068】

次にＳ９０２に進みＣＰＵ２０１は、ストレージ１０６の空きメモリ容量が所定量以上か（インストールしているアプリの容量が所定量以下であるか）を判定し、そうであればＳ９０５に進みＣＰＵ２０１は、処理不要で、ログアウト処理を継続し、この終了処理を終了する。

【0069】

一方、Ｓ９０２でＣＰＵ２０１が、ストレージ１０６の空きメモリ容量が所定量よりも少ない、即ち、記憶している全アプリの容量が所定量以上であると判定した場合は、アプリがストレージ１０６のメモリ容量を圧迫しているためＳ９０３に進む。Ｓ９０３でＣＰＵ２０１は、一定基準で、ストレージ１０６に記憶しているアプリの内、基本プリ以外のアプリに点数をつける。そしてＳ９０４に進みＣＰＵ２０１は、その点数の低い順に、ストレージ１０６の空きメモリ容量が所定量以上になるまで、即ち、全アプリの容量が所定量よりも少なくなるまでアプリを削除して、この処理を終了する。

【0070】

尚、ここでＳ９０３におけるアプリの点数付け（重み付け）の基準には、例えば以下に示すような、アプリの特性或いはアプリケーションの使用状況などに基づく基準が考えられる。
（１）アプリのサイズ（ストレージ１０６の占有しているメモリ容量）が大きいほど点数を低くする。
（２）所定期間におけるアプリの使用頻度が大きいほど点数を高くする。
（３）アプリを利用しているユーザの数が多いほど点数を高くする。
（４）直近にアプリが使用された日時が、現在の日時により近いほど点数を高くする。

【0071】

このようにして、ログアウトしたユーザが使用した、基本アプリ以外のアプリを、そのユーザがログアウトすると削除することにより、ストレージ１０６の空きメモリ容量が所定量よりも少なくなるのを防止できる。

【0072】

ここで一つの事例を説明する。ここでは営業のＡさんが画像形成装置１０１にログインしてからログアウトするまでの流れで説明する。

【0073】

営業のＡさんは、通常、外回り営業を担当しており、カレンダアプリで、自分のスケジュール管理をしている。このスケジュールには、時間、場所、顧客名などが記述されている。Ａさんが画像形成装置１０１にログインすると、画像形成装置１０１は、そのＡさんの位置（画像形成装置１０１の直ぐ側）を特定する。

【0074】

次に、Ａさんが属するグループに紐づけられている所定のアプリを取得する。所定のアプリは、例えば、カレンダアプリ、地図アプリ、メールアプリなどである。そしてカレンダアプリで次の予定（時間、場所）を確認し、地図アプリで、移動の所要時間を算出する。また出発しなければならない時刻を計算し、ユーザに通知する。メール送信、および地図、道順の出力を提示する。

【0075】

例えば、Ａさんが１５：００に池袋オフィスの画像形成装置にログインし、次の予定は１６：００に渋谷（歩行を含めて移動時間が３０分）とする。ここで１５分前の１５：４５に渋谷に到着するためには、１５：１５までに池袋を出発しなければならない。このような情報をユーザに提示し、メール送信或いは印刷等を行う。

【0076】

そしてＡさんがログアウトすると、上記カレンダアプリ、地図アプリ、メールアプリの容量を所定量以上かどうか判定し、そうであれば、それらコンテナ化されたアプリを、上記点数に従ってストレージ１０６から削除する。

【0077】

図１０は、実施形態に係る画像形成装置１０１におけるアプリケーションの取得を説明する図である。

【0078】

ユーザもしくは管理者は、画像形成装置１０１へのログイン時、サーバ１０００から転送してほしい機能を選択することができる。このとき業者は、既存のアプリをコンテナ化して事前にサーバ１０００に格納している。ここでは管理のため、アプリのコンテナごとにＩＤが付与され、そのコンテナ名、バージョン、ＩＤ、及びユーザのグループとの関連等がアプリ一覧１００１に格納される。

【0079】

画像形成装置１０１が納入される際に（もしくは製造される際に）、サーバ１０００からアプリ一覧１００１が画像形成装置１０１に送られて保存される。こうして画像形成装置１０１に保存されたアプリは、取得、削除、更新などのタイミングで、その内容が更新される。

【0080】

いまユーザが、画像形成装置１０１の操作部１０５を操作し、そのユーザの個人アプリとして利用する機能として、例えば機能２、機能３を選択する。これにより、それら機能に紐付いたアプリ２、アプリ３のコンテナが選択される。そして画像形成装置１０１でユーザが、アプリ一覧１００２で、それらコンテナのＩＤを特定する。これにより画像形成装置１０１は、サーバ１０００から、各対応するアプリのコンテナを取得し、画像形成装置１０１は、それらアプリに対応する機能を有することになる。

【0081】

尚、図１０において、サーバ１０００は、業者のＷｅｂサーバと同期し、そのＷｅｂサーバから、その業者が作成したコンテナを利用する。一方、ユーザが自前で作成したコンテナの場合、そのコンテナ化されたアプリをサーバ１０００のみに格納する。

【0082】

またアプリの処理内容によって、画像形成装置装置１０１による処理、或いはサーバ１０００による処理に切り替えることができる。ユーザの操作に対する反応時間を考慮した場合は、画像形成装置１０１での処理が望ましい。一方で、処理性能を重視する場合、画像形成装置１０１で実行するより、サーバ１０００による実行の方が望ましい場合もあり得る。

【0083】

以上説明したように、コンテナ化されたアプリの場合、可搬性が高く、同じアプリが画像形成装置１０１もしくは、サーバ１０００（オンプレサーバ、Ｗｅｂサーバも）での実行が可能である。そのため、従来のようなネイティブでの実行の場合と比べて、拡張できる機能数が増えるだけではなく、サーバ１０００の性能を利用することによって、画像形成装置１０１だけでは実現しなかった機能の拡張もできるようになる。

【0084】

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

【0085】

本発明は上記実施形態に制限されるものではなく、本発明の精神及び範囲から逸脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。

【符号の説明】

【0086】

１０１…画像形成装置、１０２…スキャナ、１０３…コントローラ（制御部）、１０４…プリンタ部、１０５…操作部、１０６…ストレージ、１０８…ＬＡＮ、１０９…コンピュータ、６０２…オンプレサーバ、６０３…Ｗｅｂサーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】