図面 (/)

技術 ネットワークシステム及びその制御方法

出願人 キヤノン株式会社
発明者 内田百重
出願日 2016年1月19日 (5年5ヶ月経過) 出願番号 2016-007957
公開日 2017年7月27日 (3年11ヶ月経過) 公開番号 2017-129966
状態 特許登録済
技術分野 ストアードプログラム
主要キーワード 上位バージョン 配信設定情報 商品構成 アプリケーション構成情報 商品タイプ 外部記憶機器 プログラム配信サーバ デバイスシリアル番号
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年7月27日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

配信システム画像処理装置インストールされているアプリケーション情報を把握できない場合には、該画像処理装置に適したアプリケーションアップデートの配信をすることができなかった。

解決手段

配信システムは、ネットワーク機器アプリケーション構成情報を参照せずに配信対象の指定アプリケーションの配信を行う第1の配信方法に対応する識別子と、前記指定アプリケーションにアップデート可能なアプリケーションのバージョン情報と、を含む配信予約情報を作成する。また、ネットワーク機器は、前記配信予約情報を前記配信システムから受信した際に、該配信予約情報に前記第1の配信方法に対応する識別子が含まれていたことに応じて、該配信予約情報に含まれる前記バージョン情報に基づき、インストール済みのアプリケーションから前記指定アプリケーションへのアップデート処理を実行する。

概要

背景

従来、プログラム配信サーバーから、ネットワーク機器インストール可能なファームウェアを、ネットワークを介して配信することで更新を行う方法がある。例えば、特許文献1には、画像形成装置が自身に適用されている各ファームウェアのタイプやバージョン情報配信サーバー事前通知することで、配信サーバーが画像形成装置に適用すべきファームウェアを特定する技術が開示されている。特許文献1では、配信サーバーは、適用すべきファームウェアの情報を、ネットワークを介して画像形成装置に応答することにより、ファームウェアの更新を実現している。

概要

配信システム画像処理装置にインストールされているアプリケーション情報を把握できない場合には、該画像処理装置に適したアプリケーションアップデートの配信をすることができなかった。 配信システムは、ネットワーク機器のアプリケーション構成情報を参照せずに配信対象の指定アプリケーションの配信を行う第1の配信方法に対応する識別子と、前記指定アプリケーションにアップデート可能なアプリケーションのバージョン情報と、を含む配信予約情報を作成する。また、ネットワーク機器は、前記配信予約情報を前記配信システムから受信した際に、該配信予約情報に前記第1の配信方法に対応する識別子が含まれていたことに応じて、該配信予約情報に含まれる前記バージョン情報に基づき、インストール済みのアプリケーションから前記指定アプリケーションへのアップデート処理を実行する。

目的

本発明に係るネットワークシステムの構成および各構成が有するプログラムモジュールブロック図
本発明に関する情報処理装置ハードウェア構成
本発明におけるネットワーク機器の一例である画像処理装置におけるハードウェア構成図
実施例1における画像処理装置での処理を説明するためのフローチャート
実施例1における配信管理サーバーでの画像処理装置のアプリケーション構成情報の管理に係る処理を説明するためのフローチャート
実施例1における配信管理サーバーが提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ネットワークを介して接続された配信システムと複数のネットワーク機器とを含むネットワークシステムであって、前記配信システムは、配信対象として指定された指定アプリケーションアップデート可能なアプリケーションのバージョン情報を含む情報をライセンス管理サーバーから取得する取得手段と、前記指定アプリケーションを配信すべきネットワーク機器のアプリケーション構成情報を参照せずに前記指定アプリケーションの配信を行う第1の配信方法に対応する識別子と、前記指定アプリケーションにアップデート可能なアプリケーションのバージョン情報と、を含む配信予約情報を作成する作成手段と、を有し、前記ネットワーク機器は、前記配信予約情報を前記配信システムから受信する受信手段と、前記受信した配信予約情報に前記第1の配信方法に対応する識別子が含まれていたことに応じて、前記受信した配信予約情報における前記指定アプリケーションにアップデート可能なアプリケーションのバージョン情報に基づき、インストール済みのアプリケーションから前記指定アプリケーションへのアップデート処理を実行する実行手段を有することを特徴とするネットワークシステム。

請求項2

前記ネットワーク機器は、前記アプリケーション構成情報を、リモートアップデートが許可されている場合に、前記配信システムに送信することを特徴とする請求項1に記載のネットワークシステム。

請求項3

前記配信システムは、ネットワーク機器から受信した前記アプリケーション構成情報をネットワーク機器ごとに管理する第1の管理手段を有することを特徴とする請求項1又は2に記載のネットワークシステム。

請求項4

前記第1の配信方法は、強制アップデートであることを特徴とする請求項1〜3のいずれか1項に記載のネットワークシステム。

請求項5

前記配信予約情報には、ネットワーク機器を特定する識別子、配信するアプリケーションを特定するためのアプリケーション情報、配信方法を示す識別子、配信日時が含まれることを特徴とする請求項1〜4のいずれか1項に記載のネットワークシステム。

請求項6

前記配信システムは、対象のネットワーク機器の配信履歴情報を管理する第2の管理手段を有し、前記アプリケーションの配信予約手段は、前記配信履歴情報と前記アプリケーション構成情報に基づきアプリケーションの適用確認を行う第1の確認手段を有すること特徴とする請求項1〜5のいずれか1項に記載のネットワークシステム。

請求項7

前記配信システムは、対象のネットワーク機器のライセンス発行履歴情報を前記ライセンス管理サーバーから取得し、前記作成手段は、前記ライセンス発行履歴情報に基づきアプリケーションの適用確認を行う第2の確認手段を有すること特徴とする請求項1〜5のいずれか1項に記載のネットワークシステム。

請求項8

前記ネットワーク機器は、ライセンス情報を管理する第4の管理手段を有し、リモートアップデートが許可されている場合に、前記配信システムに前記ライセンス情報を送信することを特徴とする請求項1〜7のいずれか1項に記載のネットワークシステム。

請求項9

前記ネットワーク機器は、画像処理装置であることを特徴とする請求項1〜8のいずれか1項に記載のネットワークシステム。

請求項10

ネットワークを介して接続された配信システムと複数のネットワーク機器とを含むネットワークシステムの制御方法であって、前記配信システムは、配信対象として指定された指定アプリケーションにアップデート可能なアプリケーションのバージョン情報を含む情報をライセンス管理サーバーから取得する取得工程と、前記指定アプリケーションを配信すべきネットワーク機器のアプリケーション構成情報を参照せずに前記指定アプリケーションの配信を行う第1の配信方法に対応する識別子と、前記指定アプリケーションにアップデート可能なアプリケーションのバージョン情報と、を含む配信予約情報を作成する作成工程と、を実行し、前記ネットワーク機器は、前記配信予約情報を前記配信システムから受信する受信工程と、前記受信した配信予約情報に前記第1の配信方法に対応する識別子が含まれていたことに応じて、前記受信した配信予約情報における前記指定アプリケーションにアップデート可能なアプリケーションのバージョン情報に基づき、インストール済みのアプリケーションから前記指定アプリケーションへのアップデート処理を実行する実行工程を実行することを特徴とするネットワークシステムの制御方法。

技術分野

背景技術

0002

従来、プログラム配信サーバーから、ネットワーク機器にインストール可能なファームウェアを、ネットワークを介して配信することで更新を行う方法がある。例えば、特許文献1には、画像形成装置が自身に適用されている各ファームウェアのタイプやバージョン情報配信サーバー事前通知することで、配信サーバーが画像形成装置に適用すべきファームウェアを特定する技術が開示されている。特許文献1では、配信サーバーは、適用すべきファームウェアの情報を、ネットワークを介して画像形成装置に応答することにより、ファームウェアの更新を実現している。

先行技術

0003

特開2012-056199号公報

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

0004

上述した特許文献1では、画像形成装置にインストールされているファームウェアなどのプログラムの情報を、配信サーバーで把握していることが前提となっている。
ここで、ファームウェアなどソフトウェアの配信を制御する配信管理サーバーがネットワーク機器にインストールされている各ソフトウェアの構成情報(ソフトウェアの識別情報やバージョン情報)を把握できない場合がある。具体的には、ネットワーク機器を保有している顧客がセキュリティなどの理由で、配信管理サーバーへのアプリケーションプログラムの構成情報の提供を許可していない場合などである。このような状況では、特許文献1のような手法で、該機器に適用すべきアプリケーションプログラムを配信することができなかった。一方で、アプリケーションプログラムは、様々な要因で更新が行われる必要があり、上記のような状況下であっても、適切なバージョンのものにリモートからアップデートさせたいという要望も存在する。

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

0005

上記目的を達成するために、本発明は以下の構成を備える。
ネットワークを介して接続された配信システムと複数のネットワーク機器とを含むネットワークシステムであって、前記配信システムは、配信対象として指定された指定アプリケーションにアップデート可能なアプリケーションのバージョン情報を含む情報をライセンス管理サーバーから取得する取得手段と、前記指定アプリケーションを配信すべきネットワーク機器のアプリケーション構成情報を参照せずに前記指定アプリケーションの配信を行う第1の配信方法に対応する識別子と、前記指定アプリケーションにアップデート可能なアプリケーションのバージョン情報と、を含む配信予約情報を作成する作成手段と、を有し、前記ネットワーク機器は、前記配信予約情報を前記配信システムから受信する受信手段と、前記受信した配信予約情報に前記第1の配信方法に対応する識別子が含まれていたことに応じて、前記受信した配信予約情報における前記指定アプリケーションにアップデート可能なアプリケーションのバージョン情報に基づき、インストール済みのアプリケーションから前記指定アプリケーションへのアップデート処理を実行する実行手段を有することを特徴とする。

発明の効果

0006

本発明によれば、ネットワーク機器にインストールされたアプリケーションを配信システムが把握していなくとも、配信予約情報に含まれるアプリケーションのバージョン情報に基づき適切にアプリケーションの更新を行うことができる。

図面の簡単な説明

0007

本発明に係るネットワークシステムの構成および各構成が有するプログラムモジュールブロック図
本発明に関する情報処理装置ハードウェア構成
本発明におけるネットワーク機器の一例である画像処理装置におけるハードウェア構成図
実施例1における画像処理装置での処理を説明するためのフローチャート
実施例1における配信管理サーバーでの画像処理装置のアプリケーション構成情報の管理に係る処理を説明するためのフローチャート
実施例1における配信管理サーバーが提供する配信アプリ検索画面の表示例
実施例1における配信管理サーバーが提供する配信アプリ確定画面の表示例
実施例1における配信管理サーバーでの配信予約を行う際の処理を説明するためのフローチャート
実施例1における配信管理サーバーが提供する画面の表示例
実施例1における画像処理装置での更新制御の処理を説明するためのフローチャート
実施例1における画像処理装置でのアプリケーションのアップデート処理を説明するためのフローチャート
実施例2における配信管理サーバーでの配信予約を行う際の処理を説明するためのフローチャート
実施例2における配信管理サーバーでの配信アプリケーションの適用確認処理を説明するためのフローチャート
実施例3における配信管理サーバーでの配信アプリケーションの適用確認処理を説明するためのフローチャート
実施例3におけるライセンス管理サーバーでの商品種別特定処理を説明するためのフローチャート
実施例4における配信管理サーバーでの配信予約を行う際の処理を説明するためのフローチャート
実施例4における画像処理装置でのライセンス情報送付の処理を説明するためのフローチャート
実施例4における配信管理サーバーでの配信アプリケーションの適用確認処理を説明するためのフローチャート
実施例4におけるライセンス管理サーバーでのバージョンアップ属性の確認処理を説明するためのフローチャート

0008

以下、本発明を実施するための形態について図面を用いて説明する。
本発明の実施例を説明する前に、本発明を適用可能なシステム構成について説明する。
なお、この実施形態に記載されている構成要素は例示であり、この発明の範囲を限定するものではない。したがって、以下では、ネットワーク機器の一例として、ネットワークプリンターなどの画像処理装置について説明するがこれに限定されるものではない。具体的に、本発明が適用可能なネットワーク機器には、複写機デジタル医療機器ネットワークカメラ家電製品車載端末など、種々の機器が含まれる。
また以降の説明において、アプリケーションプログラムをアプリ略記することもあるが、アプリケーションと同義とする。

0009

<用語の定義>
・リモートアップデートについて
画像処理装置から配信管理サーバー上で管理されるアプリケーションをネットワーク経由でダウンロードすることによって、画像処理装置103内のアプリケーションをアップデートすることをリモートアップデートと定義する。

0010

・リモートアップデートの許可・不許可について
リモートアップデートの実行を許可するかどうかの設定は画像処理装置に個別に設定することができる。
リモートアップデートを許可した画像処理装置は、配信管理サーバーに該画像処理装置103内にインストールされているアプリケーション情報を任意のタイミングで送付する。そして、リモートアップデートを実行することができる。
画像処理装置にインストールされているアプリケーション情報は顧客情報のため、配信管理サーバーへの情報送付に抵抗がある場合や、自動でアプリケーションが更新されてしまうことに問題がある場合などは、リモートアップデートを不許可に設定できる。
リモートアップデートを許可していない画像処理装置は、配信管理サーバーに該画像処理装置内にインストールされているアプリケーションの情報は一切送付しない。そして、リモートアップデートは基本的に実行できない。

0011

・通常アップデートと強制アップデートについて
リモートアップデートには、配信方法として、通常アップデートと強制アップデートの2つの方法がある。
通常アップデートとは、リモートアップデートを許可している画像処理装置に対してのみアプリケーション配信を行う方法である。リモートアップデートを許可している画像処理装置が対象となるため、配信先の画像処理装置内にインストールされているアプリケーション情報は配信設定時に配信管理サーバーが把握できることが特徴である。
一方、リモートアップデートを許可していない画像処理装置に対してもアプリケーション配信を行う方法が強制アップデートである。
強制アップデートを行う場合の例としては、アプリケーションにセキュリティ上の問題が見つかるなど、そのままアプリケーションを使用し続けると問題が発生するようなアプリケーションをバージョンアップする場合である。強制アップデートの場合は、配信対象のアプリケーションがインストール可能かどうかを配信設定時に配信管理サーバーでは判断できないのが特徴である。

0012

商品とアプリケーションの関係
アプリケーションとは、画像処理装置上で動作するプログラムであり、ライセンス管理サーバー上で暗号化して管理される。
商品とは、アプリケーションを動作させるための条件(利用回数期限など)を含めた概念であり、ライセンス管理サーバー上で管理される。画像処理装置上でアプリケーションを利用可能にするためには、商品を利用するための権利であるライセンスアクセス番号(LA#)をライセンス管理サーバーから発行する必要がある。さらにライセンスアクセス番号(LA#)からアプリケーションを復号化するために必要なライセンスを発行することによって、画像処理装置上にアプリケーションをインストールすることが可能となる。

0013

図1は本発明に関するアプリケーションの配信に係るネットワークシステム構成およびプログラムモジュールのブロック図を例示している。
本発明におけるネットワークシステムは、配信管理サーバー101、ユーザー端末102、画像処理装置103、ライセンス管理サーバー104から構成される。なお、画像処理装置は複数台、存在してもよい。その場合は、配信管理サーバー101は複数台の画像処理装置の情報を管理することになる。
配信管理サーバー101は、アプリ情報取得部107、配信情報管理部108から構成される。さらにアプリ情報や配信設定情報を管理するデータベース105を備えている。配信管理サーバー101は複数の情報処理装置からなる配信システムとして実現することが可能である。各情報処理装置にアプリ情報取得部107、配信情報管理部108のそれぞれの機能を配置してもよいし、各情報処理装置にそれらすべての機能を配置して負荷分散されるように協調動作してもよい。
配信管理サーバー101への処理依頼は表示部109および入力部110を備えたユーザー端末102からウェブブラウザなどを用いて行う。
アプリケーションをインストールおよび実行可能な画像処理装置103は、アプリ情報管理部111、制御部112、アップデート部113から構成される。
ライセンス管理サーバー104は、アプリ・商品情報管理部114、アプリ・商品情報やライセンス情報を管理するデータベース106を備えている。
なお、図1には、配信履歴管理部1401、ライセンス情報管理部1402及びライセンス情報管理部1901が記載されているが、実施例1では不要なモジュールである。これらは、後述の実施例に関するモジュールであり、具体的には、各実施例のところで説明する。

0014

図2は、配信管理サーバー101を構成する情報処理装置のハードウェア構成図を示す。また、ユーザー端末102、ライセンス管理サーバー104のハードウェア構成図も同一である。
図2において、CPU201は本装置上の各処理を司る。書換え不可能なROM202は本装置の各処理に関わるプログラムやデータを記憶する。RAM203は、本装置の各処理に関わる一時的なデータを電気的に記憶でき、かつ書き換え可能である。HDD204は、後述する本発明の特徴となる処理を実現するために実行されるプログラムや本装置のそれ以外の各処理に関わるプログラムやデータ、および一時的なデータ、監視対象ネットワークデバイスに関する情報、およびネットワークデバイスから収集した情報などを記憶する。たとえば、稼働情報などがハードディスクに保存される。
たとえば配信管理サーバー101の場合、後述する図5の処理を行うプログラムをHDD204に記憶している。このプログラムは、RAM203を一時保存領域として使用し、CPU201によって呼び出され実行される。
操作部205は、本装置への指示入力受け付けキーボードである。表示部206は、本装置の動作状況や、本装置上で動作する各プログラムが出力する情報を表示する。NetworkI/F208は、ネットワーク経由でLANおよびインターネット120に接続し、外部と情報交換を行う。外部機器I/F207は外部記憶機器等を接続する。それら要素がシステムバス209により結び付き、データをやりとりしている。

0015

図3は、画像処理装置103におけるハードウェア構成図を示す。ネットワークデバイスとしては、具体的には、プリンタ及びファクシミリ機能統合的に設けられた複合機、PCなどからデータを受信し印刷するプリンタ(電子写真方式及びインクジェット方式を含む)や、スキャナーや、ファクシミリなどが挙げられる。本図では、ネットワークデバイスの一例として複合機の構成を示している。
イメージリーダ302は、原稿給送部301で原稿を読み込む。画像形成部303は、イメージリーダ302で読み込んだ原稿やNetworkI/F305からネットワーク経由で受信したデータを印刷画像に変換・印刷出力する。排紙部304は印刷出力した紙を排出し、ソートステイプルといった処理を施す。NetworkI/F305はネットワーク経由でLANおよびインターネット120に接続し、外部と情報交換を行う。

0016

CPU306は本装置上の各処理を司る。画像処理装置103の動作状態監視し、障害等の特定のイベントが発生した場合には、その状態を示す状態情報を、あらかじめ定めた宛先へと送信する。宛先はたとえば監視装置などである。書換え不可能なROM307は本装置の各処理に関わるプログラムやデータを記憶する。RAM308は、本装置の各処理に関わる一時的なデータを電気的に記憶でき、かつ書き換え可能である。HDD309は、後述する本発明の特徴となる処理を実現するために実行されるプログラムや本装置のそれ以外の各処理に関わるプログラムやデータ、および一時的なデータ、本装置へ送信されてきたユーザデータなどを記憶する。
画像処理装置103は、後述する図4の処理を行うプログラムをHDD309に記憶している。このプログラムは、RAM308を一時保存領域として使用し、CPU306によって呼び出され実行される。
操作部310は本装置への指示入力を受け付ける。表示部311は本装置の動作状況および操作部310に対する操作に関わる情報を表示する。そしてそれらがシステムバス312により結び付き、データをやりとりしている。

0017

本発明における実施例1について説明する。
図4で示すフローチャートを用いて、画像処理装置103上のアプリ情報管理部111で実行される処理について説明する。本処理は、CPU306が本発明に係るプログラムを実行することで実現されるものである。
本発明における画像処理装置103では、画像処理装置103起動時に処理を開始する。
処理が開始(S401)されると、リモートアップデートが許可されているか確認(S402)を行う。S402での確認の結果、リモートアップデートが許可されていない場合は、配信管理サーバー101にアプリケーション情報を通知しないため、処理を終了(S407)する。S402での確認の結果、リモートアップデートが許可されている場合は、次に、該画像処理装置103内にアプリケーションがインストールされているか確認(S403)する。一つもアプリケーションがインストールされていない場合は、配信管理サーバー101に送付するアプリケーション情報が存在しないため、処理を終了(S407)する。S403での確認の結果、アプリケーションがインストールされている場合は、配信管理サーバー101にアプリケーション構成情報が送信済みであるか確認(S404)し、すべての情報を送信済みの場合は処理を終了(S407)する。S404での確認の結果、情報を送信していないアプリケーションがある場合は、配信管理サーバー101へ未送信のアプリケーション構成情報を生成(S405)する。配信管理サーバー101へアプリケーション構成情報を送信(S406)し、処理を終了(S407)する。

0018

図5で示すフローチャートを用いて、配信管理サーバー101のアプリ情報取得部107で実行される処理について説明する。本処理は、CPU201が本発明に係るプログラムを実行することで実現されるものである。
画像処理装置103のアプリ情報管理部111がアプリケーション構成情報を送信すると処理が開始(S501)される。画像処理装置103から画像処理装置を一意に特定するデバイスシリアル番号(DS#)とアプリケーション構成情報を受信(S502)すると、データベース105内に、DS#ごとにアプリケーション構成情報を保存(S503)する。その後、処理を終了(S504)する。

0019

下記表1は、データベース105内で、DS#ごとに管理されるアプリケーション構成情報の例を示している。DS#「AAA00500」からアプリケーション構成情報として「AppA/V1.0とAppB/V2.1」を、DS#「AAA00501」から「AppA/V2.0」を、DS#「AAA00502」から「AppA/V2.1」を受信した場合である。

0020

図6は、配信管理サーバー101の配信情報管理部108がユーザー端末102に提供する配信アプリ検索画面を示している。当該検索画面への操作は、画面提供を受けたユーザー端末102を介して行われる。
配信アプリ検索画面601には、アプリケーションIDで検索するか、登録番号で検索するかの検索種別を指定するラジオタン602がある。また、検索種別でアプリケーションIDを指定した場合にアプリケーションIDを選択するプルダウン603およびバージョンを選択するプルダウン604もある。さらに、検索種別で登録番号を指定した場合の登録番号を入力するテキストボックス605およびパスワードを入力するテキストボックス606、検索を実行する「検索」ボタン607、検索条件クリアするリセットボタン608から構成される。
なお、登録番号とは、ライセンス管理サーバー104上でアプリケーションのAppIDとVersionを一意に特定可能な識別子である。

0021

図7は、配信管理サーバー101の配信情報管理部108がユーザー端末102に提供する配信アプリ確定画面を示している。当該画面への操作は、画面提供を受けたユーザー端末102を介して行われる。
配信アプリ確定画面701は、図6で図示した配信アプリ検索画面で、検索条件として指定された条件でライセンス管理サーバー104に問い合わせたアプリケーション情報の結果を、アプリケーションID702、バージョン703を表示する。また、画像処理装置103にアプリを配信後、アプリの状態をアップデート前の状態にするか、開始状態にするか、停止状態にするかを指定するラジオボタン704を有効な状態で表示する。さらに、配信アプリ検索画面へ戻るための「戻る」ボタン705、配信対象画像処理装置103選択画面へ進む「次へ」ボタン706から構成される。
配信アプリ検索画面でアプリの検索を実行する際、図7に図示したようにアプリケーション情報を表示するだけではなく、取得したアプリケーションへアップデート可能なバージョン情報を合わせて取得する。
下記表2は、ライセンス管理サーバー104で管理される、バージョンアップ属性情報である。

0022

配信アプリ検索画面601で検索条件として指定するアプリケーションIDとバージョンの組み合わせで、アップデート可能なバージョンとして取得されるバージョン情報が異なる。

0023

図8で示すフローチャートを用いて、配信管理サーバー101の配信情報管理部108での配信予約を行う際の処理について説明する。本処理は、CPU201が本発明に係るプログラムを実行することで実現されるものである。
処理が開始(S801)されると、図6で図示した配信アプリ検索画面601から配信対象のアプリを指定(S802)し、指定された検索条件に従ってライセンス管理サーバー104からアプリ情報を取得(S803)する。取得したアプリ情報を図7で図示した配信アプリ確定画面701に表示する。そして、配信対象の指定アプリケーションをインストール可能なアプリケーション(AppID/Version)がインストールされている画像処理装置を図9(a)で示す配信対象の画像処理装置の選択画面901に表示(S804)する。配信対象アプリをインストール可能な画像処理装置は、リモートアップデートを許可している画像処理装置である。それは、該画像処理装置内にインストールされているアプリケーション情報を配信管理サーバー101が把握している画像処理装置の中から、配信アプリ検索時に取得したアップデート可能なバージョン情報を元に抽出する。
次に配信対象アプリの配信方法によって処理を切り替えるために、配信方法を確認(S805)する。

0024

本実施例では、図6で図示した検索種別にアプリケーションIDを選択した場合は、通常アップデートでリモートアップデートを実施し、検索種別に登録番号を選択した場合は、強制アップデートでリモートアップデートを実施すると判断している。しかし、別の方法でリモートアップデートの実施方法を切り替えてもよい。
配信方法が通常アップデートの場合は、配信方法に対応して、強制アップデートフラグをOFFに設定(S806)し、配信対象の画像処理装置の選択処理(S811)へ進む。
(S805)の確認の結果、配信方法が強制アップデートの場合は、配信対象の画像処理装置の選択画面にリモートアップデートを許可していない画像処理装置も表示する。つまり、該画像処理装置にインストールされているアプリケーション情報が不明な画像処理装置も表示(S807)する。リモートアップデートを許可していない画像処理装置が表示されている例は図9(b)に示す。
次に、ライセンス管理サーバー104から取得した配信対象アプリにアップデート可能なバージョン情報を配信予約情報に追加(S808)する。強制アップデートであるので、ネットワーク機器のアプリケーション構成情報を参照することなく行われる。そして、強制アップデートフラグをONに設定(S809)する。

0025

ここで、配信予約情報とは、画像処理装置103に配信を実行するために必要な情報を定義したものである。該配信予約情報は、対象の画像処理装置103を識別するためのDS#、配信対象アプリを特定するためのアプリケーション情報(AppID/Version)、配信方法を示す強制アップデートフラグ、配信日時のデータから構成される。
その後リモートアップデートを許可していない画像処理装置を配信対象の画像処理装置として図9(b)で示す登録画面1001において選択(S810)する。
続いて、リモートアップデートを許可している画像処理装置103でかつ配信対象アプリにアップデート可能なバージョンのアプリケーションがインストールされている画像処理装置103を選択(S811)する。
そして、配信日時の設定(S812)、配信予約情報の作成処理(S813)を行い、処理を終了(S814)する。

0026

下記表3は、強制アップデートで配信対象アプリに、「AppA/V3.0」のアプリを指定した場合の配信予約情報の例を示している。

0027

DS#に配信対象の画像処理装置として選択された画像処理装置を一意に識別する情報を設定する。また、AppIDには配信対象アプリの識別子、Versionには配信対象アプリのバージョン、配信日時には設定された配信日時を設定する。
さらに強制アップデートフラグは配信方法が強制アップデートであるため、それに対応してONが設定され、アップデート可能バージョンには、配信アプリ検索時にライセンス管理サーバー104から受信したアップデート可能なバージョン情報を設定する。
また、通常アップデートの場合の配信予約情報の例を下記表4に示す。DS#/AppID/Version/配信日時の情報は強制アップデートの場合と同様だが、強制アップデートフラグがOFF、またアップデート可能なバージョン情報は設定しない。

0028

図9(a)は、配信管理サーバー101の配信情報管理部108がユーザー端末102に提供する、通常アップデート時の配信対象となる画像処理装置の選択画面を図示している。該選択画面への操作は、ユーザー端末102を介して行われる。
通常アップデート時の配信対象の画像処理装置の選択画面901には、表示されている複数の画像処理装置の中から対象の画像処理装置を選択するチェックボックス902が含まれる。また、画像処理装置を一意に特定するデバイスシリアル番号(DS#)903も含まれる。さらに、画像処理装置にインストールされているアプリケーション情報(AppID/Version)904、リモートアップデートを許可しているかどうかの情報905、配信日時設定画面へ進む「次へ」ボタン909も含まれる。図7で図示した配信アプリ確定画面で表示した配信アプリケーションにアップデート可能なアプリケーション(AppID/Version)がインストールされている画像処理装置を表示する(906〜908)。なお、配信アプリ確定画面で確定した配信対象アプリと同じAppIDのアプリケーション情報には「※」印をつけた例を示しているが、赤字や太字にするなど、同じAppIDであることを表現する方法はこの方法に限らない。

0029

図9(b)は、配信管理サーバー101の配信情報管理部108がユーザー端末102に提供する、強制アップデート時の配信対象の画像処理装置の選択画面を図示している。該選択画面への操作は、ユーザー端末102を介して行われる。
強制アップデート時の配信対象画像処理装置103の選択画面1001は、表示項目1002〜1008および1011は図9(a)で図示した902〜908および909と同様だが、それ以外は、表示内容が異なる。通常アップデート時には、インストールされているアプリケーション情報を把握している画像処理装置103が表示の対象であった。しかし、強制アップデート時には、上記に追加し、インストールされているアプリケーション情報が不明な画像処理装置103も表示の対象1009、1010となる。また、インストールされているアプリケーション情報が不明なため、画像処理装置103にインストールされているアプリケーション情報(AppID/Version)1004の項目は表示なしとなる。さらに、リモートアップデートを許可しているかどうかの情報1005は「不許可」となる。

0030

図9(c)は、配信管理サーバー101の配信情報管理部108がユーザー端末102に提供する、配信日時の登録画面を図示している。当該登録画面への操作は、ユーザー端末102を介して行われる。
配信日時登録画面1101は、図9(a)もしくは図9(b)の配信対象画像処理装置103の選択画面で選択した画像処理装置103ごとに配信日時を設定する画面である。
配信対象画像処理装置選択画面で選択した画像処理装置を一意に識別するデバイスシリアル番号(DS#)1102、該画像処理装置103にインストールされている配信対象アプリと同じAppIDの現在のVersion 1103が表示される。さらに、配信日を入力するテキストボックス1104、配信時刻を入力するテキストボックス1105が表示される。そして、これらの項目に対して、配信対象画像処理装置103の選択画面で選択された画像処理装置毎表示1106〜1109される。また、配信対象画像処理装置103を再選択するための「戻る」ボタン1110、入力した配信日時の登録を実行する「登録」ボタン1111、配信設定自体を削除する「削除」ボタン1112から構成される。

0031

図10で示すフローチャートを用いて、画像処理装置103の制御部112での更新制御の処理について説明する。本処理は、CPU306が本発明に係るプログラムを実行することで実現されるものである。
制御部112の処理は、画像処理装置103が起動すると開始(S1201)される。任意の間隔で、配信管理サーバー101へ配信予約の有無を確認(S1202)し、予約がなければ任意の間隔で配信予約の有無確認を実施する。(S1202)の確認の結果、配信予約ありと判断した場合、配信管理サーバー101から配信予約情報を取得(S1203)する。配信予約情報取得後、該画像処理装置103にインストール済みのアプリケーション情報(AppID/Version)を取得(S1204)する。(S1204)で取得したアプリケーション情報の中に、(S1203)で取得した配信予約情報で配信対象となっているアプリケーションが含まれるか確認(S1205)する。そして、配信対象アプリケーションが含まれないのであれば、配信管理サーバー101にエラーを通知(S1210)し、処理を終了(S1211)する。

0032

S1205での確認の結果、配信対象アプリケーションが含まれる場合は、配信予約情報の強制アップデートフラグの状態を確認(S1206)する。強制アップデートフラグがOFFの場合は、アップデート処理(S1209)を実行し、処理を終了(S1211)する。強制アップデートフラグがONの場合は、配信予約情報から配信対象アプリケーションにアップデート可能なバージョン情報を取得(S1207)する。続いて、S1204で取得したアプリケーション情報(AppID/Version)のVersionがS1207で取得したアップデート可能なバージョンに含まれるか確認(S1208)する。S1208での確認の結果、アップデート可能なバージョンに含まれない場合は、配信管理サーバー101にエラーを通知(S1210)する。また、アップデート可能なバージョンに含まれる場合は、アップデート処理(S1209)を実行し、処理を終了(S1211)する。S1209のアップデート処理については図11でその詳細を後述する。
たとえば、リモートアップデートを許可していない画像処理装置103、DS#「BBB00401」に「AppA/V2.0」がインストールされている状態で、下記表5に示す配信予約情報を受け取った場合には、次のようになる。制御部112のS1208での確認処理で、アップデート可能バージョン情報に該画像処理装置103にインストールされているV2.0が含まれるため、アップデート可能と判断され、アップデート処理を続行される。

0033

図11で示すフローチャートを用いて、画像処理装置103のアップデート部113のアプリケーションのアップデート処理を説明する。
図10で例示した制御部112の処理において、アップデート可能と判断された場合に、処理が開始(S1301)される。配信予約情報内の配信予約日時になるまで、日時確認処理を実施(S1302)し、配信予約日時を過ぎた場合、配信管理サーバー101に該配信予約が有効かどうかの確認(S1303)を行う。S1303での確認の結果、配信が無効(キャンセル)であった場合は、そのまま処理を終了(S1309)する。配信が有効である場合は、配信対象アプリを取得するためのURLを配信管理サーバー101から取得(S1305)し、取得したURLから配信対象アプリをダウンロード(S1306)する。ダウンロード後、配信対象アプリをインストール(S1307)し、配信管理サーバー101へ結果を通知(S1308)後、処理を終了(S1309)する。

0034

本実施例では、図8、10で示したように、リモートアップデートの実施方法(通常アップデート又は強制アップデート)によって、配信対象アプリのアップデート可否の確認の実施を、配信管理サーバー101と画像処理装置103で切り分ける方法を示した。
これにより、状況に応じて適したアプリケーションのリモートアップデートを実現することが可能となる。

0035

実施例1では本発明の基本構成について説明した。実施例2では、配信管理サーバー101の配信履歴情報を利用して、配信対象アプリのバージョンアップ属性情報を確認する例について説明する。

0036

配信管理サーバー101で管理される配信履歴情報は、画像処理装置103が配信管理サーバー101を利用してアプリケーションをインストールした場合の履歴情報である。履歴として管理される情報は、処理を実行した画像処理装置103を特定するためのDS#、ライセンス管理サーバー104上の商品を特定するためのLA#、処理を実行した日時である。

0037

ライセンス管理サーバー104では、アプリケーション(AppID/Version)ごとにアップデート可能なバージョン情報(バージョンアップ属性情報)を管理している。このため、同じアプリケーション(AppID/Version)を複数の異なる商品として登録することができる。
よって、同じアプリケーション(AppID/Version)であっても、商品構成によっては、配信対象のアプリケーションにアップデートできない場合もある。

0038

たとえば、商品AはAppID:AppA、Version:V2.0のアプリケーションから構成され、V2.1とV3.0のアプリケーションへアップデート可能な設定になっているとする。
一方商品BはAppID:AppA、Version:V2.1のアプリケーションから構成され、アップデート可能な上位バージョンは設定されていないとする。
上記商品構成の場合、AppID:AppA、Version:V2.1のアプリケーションを画像処理装置103にインストールするパターンとして、以下のパターンが考えられる。
パターン1)商品Aを購入し、V2.0をインストール後にV2.1へアップデートする
パターン2)商品Bを購入し、V2.1をインストールする

0039

上記状況で、AppA/V3.0のアプリケーションを配信対象アプリに設定すると、ライセンス管理サーバー104の設定上は、パターン1の画像処理装置103のみアップデートが可能となる。しかし、画像処理装置103にアプリをインストールした後は、ライセンス管理サーバー104内の商品情報を特定できない。このため、パターン1でアプリをインストールした画像処理装置103もパターン2でアプリをインストールした画像処理装置103も配信対象アプリにアップデート可能となってしまう。

0040

本実施例では、配信管理サーバー101経由でアプリケーションのインストールを実行した画像処理装置103に限定して、ライセンス管理サーバー104内の商品を特定するための方法を示す。以降、実施例1と共通する部分については説明を省略し、本実施例に特有な構成についてより詳しく説明する。

0041

図12で示すフローチャートを用いて、配信管理サーバー101の配信情報管理部108での配信予約を行う際の処理について説明する。なお、図8と共通する説明については省略する。
図12では、まず、リモートアップデートを許可している画像処理装置でかつ配信対象アプリにアップデート可能なバージョンのアプリケーションがインストールされている画像処理装置を選択(S811)する。その後、選択した画像処理装置ごとに、配信アプリケーションの適用確認処理(S1501)を実施する。適用確認処理の詳細は図13で説明する。

0042

図13で示すフローチャートを用いて、配信管理サーバー101の配信履歴管理部1401での配信アプリケーションの適用確認処理について説明する。
図12で例示した適用確認処理(S1501)を実行することによって、処理が開始(S1601)される。配信対象の画像処理装置として選択されたすべての画像処理装置の配信アプリ適用確認処理を実施したか確認(S1602)し、すべての画像処理装置の確認が終了した場合は、処理を終了(S1610)する。確認の終わっていない画像処理装置が存在する場合は、配信履歴管理部1401で管理する履歴情報から、該画像処理装置の履歴を取得(S1603)する。履歴情報が存在するか確認(S1604)し、履歴が存在しないのであれば、次の画像処理装置の確認(S1609)を行う。(S1604)の確認の結果、履歴が存在する場合は、ライセンス管理サーバー104に履歴情報を通知し、該当する商品情報を取得(S1605)する。取得した商品情報に配信対象アプリが含まれるか確認(S1606)する。含まれる場合は、配信対象アプリにアップデート可能な画像処理装置に設定(S1607)する。含まれない場合には、配信対象アプリにアップデート不可な画像処理装置に設定(S1608)後、次の画像処理装置の確認(S1609)を行う。

0043

下記表6は、配信管理サーバー101の配信履歴管理部1401内で管理される配信履歴情報の例を示している。

0044

DS#は画像処理装置103を一意に特定する識別子、LA#はライセンス管理サーバー104上で商品を利用するために商品ごとに発行される番号で、LA#から商品情報を特定することができる識別子である。また、配信管理サーバー101を利用してアプリケーションを取得した日時を配信日時として履歴を管理している。
配信履歴管理部1401では、該画像処理装置103に関する履歴が上記表6に存在するかを(S1604)の処理で確認する。たとえば、DS#「CCC00601」の画像処理装置103が処理を行った場合には、該画像処理装置103の履歴が存在することになるため、(1605)以降の処理を続行することになる。続く(S1605)の処理では、LA#「AG97-HFL2-56RW-XY84」をライセンス管理サーバー104に通知する。ライセンス管理サーバー104では、商品ごとに発行したLA#の情報を管理しているため、その情報からLA#に紐付く商品情報を特定する。

0045

下記表7は、ライセンス管理サーバー104での商品とLA#の関連情報を示している。

0046

上記表7の場合に、LA#「AG97-HFL2-56RW-XY84」から特定される商品は「商品A」、LA#「F234-49L2-SW82-35JD」から特定される商品は「商品B」となる。
また、ライセンス管理サーバー104では、商品に含まれるアプリケーション情報を管理し、さらにアプリケーションはバージョンごとにアップデート可能なバージョン情報を管理している。
下記表8は、商品が含むアプリケーション情報を示した例である。

0047

さらに下記表9は、アプリケーションごとにアップデート可能なバージョン情報の管理状態を示している。

0048

ライセンス管理サーバー104の商品とアプリの管理状態が上記3つの表の状態の場合には、次のように判断される。配信対象アプリに「AppA/V3.0」を指定した場合は、商品AをインストールしているDS#「CCC00601」の画像処理装置はアップデート可能と判断される。また、商品BをインストールしているDS#「BBB00401」の画像処理装置はアップデート不可と判断されることになる。

0049

本実施例で示した方法により、配信管理サーバー101上に配信履歴が存在する画像処理装置については、ライセンス管理サーバー104の商品情報に応じて、正しく配信設定を実施することが可能となる。

0050

実施例2では、配信管理サーバー内の配信履歴を利用して、ライセンス管理サーバーの商品情報と連携して配信アプリ適用が可能かどうかの確認処理を行うものであった。
実施例3では、リモートアップデートを許可していない画像処理装置内にインストールされているアプリケーション情報をライセンス管理サーバー104のライセンス発行履歴および商品情報から特定する方法について説明する。

0051

<配信アプリ適用確認の処理フロー:配信管理サーバー>
図14で示すフローチャートを用いて、配信管理サーバー101の配信情報管理部108による適用確認処理について説明する。図12で例示した配信アプリ適用確認処理(S1501)を実行することによって、処理が開始(S1701)される。まず、配信対象アプリに指定したアプリケーションに関連する商品種別を特定する処理を実施(S1702)する。S1702での処理を実行後、特定したすべての商品が特定タイプ以外の商品であるか確認(S1703)し、特定タイプの商品が含まれる場合は、そのまま処理を終了(S1712)する。S1703での確認の結果、特定タイプの商品が含まれない場合は、インストール済みのアプリケーション情報を取得できていない画像処理装置を特定(S1704)する。

0052

特定したすべての画像処理装置に対するライセンス発行履歴の確認を実施したか確認(S1705)し、すべての画像処理装置の確認終了後、処理を終了(S1712)する。確認の終わっていない画像処理装置が存在する場合は、該画像処理装置に関するライセンス発行履歴が、ライセンス管理サーバー104上に存在するかライセンス情報管理部1402を通して確認(S1706)する。ライセンス発行履歴情報が存在するか確認(S1707)し、履歴が存在しないのであれば、次の画像処理装置の確認(S1711)を行う。S1707での確認の結果、履歴が存在する場合は、履歴情報から特定した商品に配信対象アプリが含まれるか確認(S1708)する。含まれる場合は、配信対象アプリにアップデート可能な画像処理装置103に設定(S1709)する。含まれない場合には、配信対象アプリにアップデート不可な画像処理装置103に設定(S1710)後、次の画像処理装置103の確認(1711)を行う。

0053

なお、特定タイプの商品とは、画像処理装置103を固定せずに利用できる商品タイプの商品種別であり、ライセンス管理サーバー104上で商品種別として定義される情報である。
特定タイプ以外の商品のライセンス発行履歴情報の例を下記表10に示す。商品を一意に特定可能なLA#の情報と画像処理装置103を一意に特定可能なDS#の情報をライセンス発行日時とともに管理している。

0054

配信対象アプリを含むすべての商品が特定タイプ以外の場合は、ライセンス発行履歴に画像処理装置103の履歴情報が存在する。このため、強制アップデート時に選択されたリモートアップデートを許可していない画像処理装置103については、ライセンス管理サーバー104のライセンス発行履歴から商品を特定することが可能である。商品特定後には、バージョンアップ属性情報を確認することで、選択された画像処理装置103に配信対象アプリにアップデート可能かどうかの判断(S1708)を実行する。

0055

図15で示すフローチャートを用いて、ライセンス管理サーバー104のアプリ・商品情報管理部117の商品種別の特定処理を説明する。
図14で例示した商品種別特定処理(S1702)が実行されると処理が開始(S1801)される。配信管理サーバー101から受信したAppIDを含むすべての商品を特定(1802)し、すべての商品の確認を実施したか確認(S1803)する。すべての商品の確認が終了したら、特定タイプの商品を含まないアプリであることを配信管理サーバー101に通知し、処理を終了(S1808)する。確認の終わっていない商品が存在する場合は、該商品の商品種別を確認(S1804)後、商品種別が特定タイプの商品か確認(S1805)する。特定タイプの商品の場合は、特定タイプの商品を含むアプリであることを配信管理サーバー101に通知し、処理を終了(S1807)する。S1805での確認の結果、特定タイプの商品でない場合は、次の商品を確認(S1806)する。

0056

本実施例で示した方法により、リモートアップデートを許可していない画像処理装置103であっても、ある条件を満たした場合は、配信対象アプリにアップデートできない画像処理装置103を特定することができる。

0057

実施例3の方法では、リモートアップデートを許可していない画像処理装置103について強制アップデートがされた場合に、ライセンス管理サーバー内のライセンス発行履歴情報に基づいて配信対象アプリにアップデートできるかどうか特定することができた。
実施例4では、リモートアップデートを許可している画像処理装置103内のライセンス情報を配信管理サーバー101が取得し、さらに、該配信管理サーバーが、該ライセンス情報をライセンス管理サーバーに通知する。これにより、ライセンス発行履歴から商品情報を特定し、バージョンアップ属性に応じて正しく配信アプリをアップデートする方法について説明する。

0058

図16で示すフローチャートを用いて、配信管理サーバー101の配信情報管理部108での配信予約を行う際の処理について説明する。
図8で例示した配信方法確認(S805)の処理において、通常アップデートであると判断された際のS806〜S813に代わって、本処理が開始(S2001)される。まず、強制アップデートフラグをOFFに設定(S2002)し、配信対象画像処理装置103を選択(S2003)する。その後選択したすべての画像処理装置103のバージョンアップ属性チェックを実施したか確認(S2004)し、すべての画像処理装置103の確認終了後、配信日時の設定(S2010)以降の処理を行う。確認の終わっていない画像処理装置103が存在する場合は、バージョンアップ属性確認処理を実施(S2005)する。正しくバージョンアップ属性確認ができたか確認(S2006)後、正しく確認できた場合には、バージョンアップ属性チェックフラグをONに設定(S2007)する。正しくチェックできなかった場合は、バージョンアップ属性チェックフラグをOFFに設定(S2008)後、次の画像処理装置103の確認を実施(S2009)する。すべての画像処理装置103の確認が終了したら、配信日時を設定(S2010)し、配信予約情報を作成(S2011)後、処理を終了(S2012)する。
なお、正しくバージョンアップ属性が確認できたかどうかの判断は、確認対象の画像処理装置103にインストールされているアプリケーション構成情報から商品情報を特定できたかどうかで判断する。

0059

図17で示すフローチャートを用いて、画像処理装置103の制御部112でのライセンス情報送付の処理について説明する。
制御部112の本処理は、画像処理装置103が起動すると開始(S2101)される。任意の間隔で、配信管理サーバー101へ配信予約の有無を確認(S2102)し、予約がなければ任意の間隔で配信予約の有無確認を実施する。S2102での確認の結果、配信予約ありと判断した場合、配信管理サーバー101から配信予約情報を取得(S2103)する。配信予約情報取得後、該画像処理装置103自身内にインストール済みのアプリケーション情報(AppID/Version)を取得(S2104)する。S2104で取得したアプリケーション情報の中に、S2103で取得した配信予約情報で配信対象となっているアプリケーションが含まれるか確認(S2105)する。配信対象アプリケーションが含まれないのであれば、配信管理サーバー101にエラーを通知(S2109)し、処理を終了(S2110)する。S2105での確認の結果、配信対象アプリケーションが含まれる場合は、該画像処理装置103のリモートアップデート許可フラグの状態を確認し、リモートアップデート許可フラグがOFFの場合は処理を終了(2110)する。リモートアップデート許可フラグがONの場合は、配信予約情報のバージョンアップ属性チェックフラグの状態を確認し、バージョンアップ属性チェックフラグがONの場合は処理を終了(S2110)する。バージョンアップ属性チェックフラグがOFFの場合は、配信アプリ適用確認(S2108)処理を実施し、処理を終了(S2110)する。
なお、配信管理サーバー101へ配信アプリ適用確認処理を依頼する際に情報として送信するライセンス情報は、ライセンス情報管理部1901で管理される情報である。

0060

図18で示すフローチャートを用いて、配信管理サーバー101の配信情報管理部108での配信アプリケーションの適用確認処理について説明する。
図17で例示した適用確認処理が実行(S2108)されると処理が開始(S2201)される。画像処理装置103から受信した配信予約情報を特定する配信IDから配信対象アプリを特定(S2202)する。特定したアプリ情報を元にライセンス管理サーバー104にバージョンアップ属性チェック処理を依頼(S2203)する。依頼の際には、画像処理装置103から受信したライセンス情報(ライセンスID)および配信IDから特定したアプリケーション情報(AppID/Version)を送信する。
ライセンス管理サーバー104のバージョンアップ属性チェック処理の結果、配信対象アプリを適用可能か判断(S2204)する。適用可能であればそのまま処理を終了(S2206)し、適用不可であれば配信予約を停止(S2205)し、処理を終了(S2206)する。
(S2205)の処理で配信予約を停止することによって、図11の画像処理装置103のアップデート部113の配信予約の有効確認処理(S1304)で配信が無効と判断される。本処理によって配信対象アプリがアップデート不可と判断された場合は、不要な配信処理を停止することになる。

0061

図19で示すフローチャートを用いて、ライセンス管理サーバー104のライセンス情報管理部1402におけるバージョンアップ属性の確認処理について説明する。
図18で示した適用確認処理においてバージョンアップ属性チェック処理の依頼が実行(S2203)されると、本処理が開始(S2301)される。配信管理サーバー101から受信したライセンスIDから商品を特定(S2302)し、特定した商品に含まれるAppIDを取得(S2303)する。取得したAppIDの中に、配信管理サーバー101から受信したAppIDが含まれるか確認(S2304)し、含まないのであれば、バージョンアップは不可であることを配信管理サーバーに通知し、処理を終了(S2308)する。配信管理サーバー101から受信したAppIDを含むのであれば、S2302で特定した商品のバージョンアップ属性を取得(S2305)する。その後、配信管理サーバー101から受信したAppID/VersionのアプリケーションがS2305で取得したバージョンアップ属性に含まれるか確認(S2306)する。含む場合は、バージョンアップ可であることを配信管理サーバー101に通知(S2307)し、含まない場合は、バージョンアップ不可であることを配信管理サーバー101に通知し、処理を終了(S2308)する。

0062

本実施例で示した方法では、リモートアップデートを許可している画像処理装置103のライセンス情報をライセンス管理サーバー104に通知する。これにより、ライセンス発行履歴から商品情報を特定し、バージョンアップ属性に応じて正しくアプリを配信することができる。

実施例

0063

(その他の実施例)
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
また、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成が可能である。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、制御方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

0064

101配信管理サーバー
102ユーザー端末
103画像処理装置
104 ライセンス管理サーバー

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ