特許 6152289 情報処理装置、端末システム、情報処理プログラム、および、アプリケーションの更新用データの取得方法

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

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

(11)【特許番号】6152289

(24)【登録日】2017年6月2日

(45)【発行日】2017年6月21日

(54)【発明の名称】情報処理装置、端末システム、情報処理プログラム、および、アプリケーションの更新用データの取得方法

(51)【国際特許分類】

   G06F 11/00 20060101AFI20170612BHJP

   G06F 9/445 20060101ALI20170612BHJP

   G06F 13/00 20060101ALI20170612BHJP

【ＦＩ】

   G06F9/06 630B

   G06F9/06 610Q

   G06F9/06 630E

   G06F13/00 530B

【請求項の数】19

【全頁数】25

(21)【出願番号】特願2013-84217(P2013-84217)

(22)【出願日】2013年4月12日

(65)【公開番号】特開2014-115973(P2014-115973A)

(43)【公開日】2014年6月26日

【審査請求日】2016年2月12日

(31)【優先権主張番号】特願2012-251043(P2012-251043)

(32)【優先日】2012年11月15日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000233778

【氏名又は名称】任天堂株式会社

(74)【代理人】

【識別番号】100158780

【弁理士】

【氏名又は名称】寺本 亮

(74)【代理人】

【識別番号】100121359

【弁理士】

【氏名又は名称】小沢 昌弘

(74)【代理人】

【識別番号】100130269

【弁理士】

【氏名又は名称】石原 盛規

(72)【発明者】

【氏名】坂井 仁

(72)【発明者】

【氏名】徳永 英治

(72)【発明者】

【氏名】小椋 信弥

【審査官】 多胡 滋

(56)【参考文献】

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

【文献】 特開２００８−２６９３９４（ＪＰ，Ａ）

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

【文献】 国際公開第２００８／１１４４９１（ＷＯ，Ａ１）

【文献】 清水理史，誰でも使えるＣｏｎｓｕｍｅｒ Ｐｒｅｖｉｅｗ版登場！ Ｗｉｎｄｏｗｓ ８のベールをはぐ！！，ＤＯＳ／Ｖ ＰＯＷＥＲ ＲＥＰＯＲＴ，日本，株式会社インプレスジャパン，２０１２年 ３月２９日，第22巻，第5号，pp.75-84

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

Ｇ０６Ｆ １１／００

Ｇ０６Ｆ ９／４４５

Ｇ０６Ｆ １３／００

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

【請求項1】

ネットワークを介してサーバと通信可能な情報処理装置であって、
アプリケーション毎に更新の有無を判定可能な更新情報を第１のタイミングで前記サーバから取得し、取得した更新情報を保存する更新情報取得部と、
前記第１のタイミングとは独立したタイミングであって、前記情報処理装置が非使用モードに移行することに応じたタイミングである第２のタイミングで、前記情報処理装置がアクセス可能な記憶部に記憶される少なくとも１つのアプリケーションについて更新があるか否かを、前記保存された更新情報に基づいて判定する第１更新判定部と、
前記第１更新判定部によって更新があると判定されたアプリケーションについて更新に用いられる更新用データを前記サーバから取得する第１更新用データ取得部とを備え、
前記第１更新判定部は、前記記憶部に記憶されるアプリケーションのうちから、前記記憶部に記憶されているアプリケーションの実行履歴に基づいて選択される１以上のアプリケーションについて、更新があるか否かを前記第２のタイミングで判定する、情報処理装置。

【請求項2】

所定の第１条件が満たされたか否かに基づいて前記第１のタイミングとなったか否かを判定する第１タイミング判定部と、
前記第１条件とは異なる第２条件が満たされたか否かに基づいて前記第２のタイミングとなったか否かを判定する第２タイミング判定部とをさらに備え、
前記第１更新判定部は、前記第２のタイミングとなったと前記第２タイミング判定部によって判定された場合に判定を行う、請求項１に記載の情報処理装置。

【請求項3】

前記更新情報取得部は、複数のアプリケーションについて更新の有無を判定可能な更新情報を前記サーバから取得し、
前記第１更新判定部は、１つのアプリケーションについて更新があるか否かを判定する、請求項１または請求項２に記載の情報処理装置。

【請求項4】

前記更新情報取得部は、複数のアプリケーションについて更新の有無を判定可能な更新情報を前記サーバから取得し、
前記第１更新判定部は、前記更新情報が示す前記複数のアプリケーションのうちの一部のアプリケーションについて更新があるか否かを判定する、請求項１または請求項２に記載の情報処理装置。

【請求項5】

前記第１のタイミングは、所定の第１操作をユーザが行ったことに起因するタイミングであり、
前記第２のタイミングは、前記第１操作とは異なる所定の第２操作をユーザが行ったことに起因するタイミングである、請求項１から請求項４のいずれか１項に記載の情報処理装置。

【請求項6】

前記第１のタイミングは、前記情報処理装置の起動から、前記記憶部に記憶されるアプリケーションを起動する指示が行われるまでのタイミングである、請求項１から請求項５のいずれか１項に記載の情報処理装置。

【請求項7】

前記第１のタイミングは、前記記憶部に記憶されるアプリケーションを起動する指示をユーザが行うことが可能なメニュー画像を表示する処理に応じたタイミングである、請求項１から請求項６のいずれか１項に記載の情報処理装置。

【請求項8】

前記第１更新判定部は、前記記憶部に記憶されるアプリケーションを起動する指示が行われたことに応じたタイミングで、起動が指示されたアプリケーションについて更新があるか否かをさらに判定する、請求項１から請求項７のいずれか１項に記載の情報処理装置。

【請求項9】

前記第１更新用データ取得部は、更新があると判定されたアプリケーションについて、当該アプリケーションの起動前に更新用データを取得し、
前記記憶部に記憶されるアプリケーションを起動する指示が行われた場合、更新用データによる更新が反映されたアプリケーションを実行する第１アプリケーション実行部をさらに備える、請求項８に記載の情報処理装置。

【請求項10】

前記更新情報取得部は、前記更新情報とともに当該更新情報のバージョンを表す更新バージョン情報を取得して保存し、次に前記第１のタイミングが到来した場合、前記更新バージョン情報を前記サーバから取得し、取得した更新バージョン情報に基づいて前記更新情報を取得するか否かを判定する、請求項１から請求項９のいずれか１項に記載の情報処理装置。

【請求項11】

前記更新情報取得部は、前記サーバにおいて設定される１以上のアプリケーションについて、当該アプリケーションが前記記憶部に記憶されているか否かに関わらず、更新情報を取得する、請求項１から請求項１０のいずれか１項に記載の情報処理装置。

【請求項12】

前記更新情報取得部は、前記情報処理装置が実行可能なアプリケーションと、前記更新用データとのうちの少なくとも一方を当該情報処理装置に提供可能な前記サーバから前記更新情報を取得する、請求項１から請求項１１のいずれか１項に記載の情報処理装置。

【請求項13】

前記更新情報が取得されたことに応じて、前記第２のタイミングにかかわらず、前記記憶部に記憶されているアプリケーションのうちの所定の条件を満たすアプリケーションについて更新があるか否かを当該更新情報に基づいて判定する第２更新判定部と、
前記第２更新判定部によって更新があると判定されたアプリケーションについて更新に用いられる更新用データを前記サーバから取得する第２更新用データ取得部とをさらに備える、請求項１から請求項１２のいずれか１項に記載の情報処理装置。

【請求項14】

前記第２更新判定部は、前記所定の条件を満たすアプリケーションを、前記記憶部に記憶されているアプリケーションの実行履歴に基づいて決定する、請求項１３に記載の情報処理装置。

【請求項15】

前記第２更新用データ取得部は、更新用データに対応するアプリケーション以外のアプリケーションが前記情報処理装置において実行されているか否かにかかわらず、当該更新用データを取得する、請求項１３または請求項１４に記載の情報処理装置。

【請求項16】

前記第２更新判定部によって更新があると判定されたアプリケーションを起動する指示が行われた場合、前記更新用データによる更新が反映されたアプリケーションを実行する第２アプリケーション実行部をさらに備える、請求項１３から請求項１５のいずれか１項に記載の情報処理装置。

【請求項17】

ネットワークを介してサーバと通信可能な端末システムであって、
アプリケーション毎に更新の有無を判定可能な更新情報を第１のタイミングで前記サーバから取得し、取得した更新情報を保存する更新情報取得部と、
前記第１のタイミングとは独立したタイミングであって、前記端末システムが非使用モードに移行することに応じたタイミングである第２のタイミングで、前記端末システムがアクセス可能な記憶部に記憶される少なくとも１つのアプリケーションについて更新があるか否かを、前記保存された更新情報に基づいて判定する判定部と、
前記判定部によって更新があると判定されたアプリケーションについて更新に用いられる更新用データを前記サーバから取得する更新用データ取得部とを備え、
前記判定部は、前記記憶部に記憶されるアプリケーションのうちから、前記記憶部に記憶されているアプリケーションの実行履歴に基づいて選択される１以上のアプリケーションについて、更新があるか否かを前記第２のタイミングで判定する、端末システム。

【請求項18】

ネットワークを介してサーバと通信可能な情報処理装置のコンピュータにおいて実行される情報処理プログラムであって、
アプリケーション毎に更新の有無を判定可能な更新情報を第１のタイミングで前記サーバから取得し、取得した更新情報を保存する更新情報取得手段と、
前記第１のタイミングとは独立したタイミングであって、前記情報処理装置が非使用モードに移行することに応じたタイミングである第２のタイミングで、前記情報処理装置がアクセス可能な記憶部に記憶される少なくとも１つのアプリケーションについて更新があるか否かを、前記保存された更新情報に基づいて判定する判定手段と、
前記判定手段によって更新があると判定されたアプリケーションについて更新に用いられる更新用データを前記サーバから取得する更新用データ取得手段として前記コンピュータを機能させ、
前記判定手段は、前記記憶部に記憶されるアプリケーションのうちから、前記記憶部に記憶されているアプリケーションの実行履歴に基づいて選択される１以上のアプリケーションについて、更新があるか否かを前記第２のタイミングで判定する、情報処理プログラム。

【請求項19】

ネットワークを介してサーバと通信可能な端末システムにおいて実行される、アプリケーションの更新用データの取得方法であって、
アプリケーション毎に更新の有無を判定可能な更新情報を第１のタイミングで前記サーバから取得し、取得した更新情報を保存する更新情報取得ステップと、
前記第１のタイミングとは独立したタイミングであって、前記端末システムが非使用モードに移行することに応じたタイミングである第２のタイミングで、前記端末システムがアクセス可能な記憶部に記憶される少なくとも１つのアプリケーションについて更新があるか否かを、前記保存された更新情報に基づいて判定する判定ステップと、
前記判定ステップにおいて更新があると判定されたアプリケーションについて更新に用いられる更新用データを前記サーバから取得する更新用データ取得ステップとを備え、
前記判定ステップにおいては、前記記憶部に記憶されるアプリケーションのうちから、前記記憶部に記憶されているアプリケーションの実行履歴に基づいて選択される１以上のアプリケーションについて、更新があるか否かを前記第２のタイミングで判定する、更新用データの取得方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アプリケーションの更新用データを取得するための情報処理装置、端末システム、情報処理プログラム、および、更新用データの取得方法に関する。

【背景技術】

【0002】

従来、情報処理装置が実行可能なアプリケーションについて、アップデートを自動的に行う技術がある。例えば非特許文献１に記載のゲーム装置では、指定された時間になるとアプリケーションのアップデートが自動的に実行される。このとき、ゲーム装置は、アプリケーションの更新が必要かどうかをチェックする処理、更新が必要な場合に更新用データを取得する処理、および、更新用データを用いてアプリケーションを更新する処理という一連の処理を続けて実行する。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】“PlayStation(R)3 System Software 4.20 User's Guide （プレイステーション３システムソフトウェア４．２０ ユーザガイド）Automatic Update（自動アップデート）”、［online］、株式会社ソニー・コンピュータエンタテインメント、［２０１２年１０月１５日検索］、インターネット〈URL：http://manuals.playstation.net/document/en/ps3/current/settings/autodownload.html〉

【発明の概要】

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

【0004】

従来においては、上記一連の処理が続けて実行されるため、アプリケーションの更新に関する処理を効率良く実行することができないおそれがあった。

【0005】

それ故、本発明の目的は、アプリケーションの更新を効率良く実行することができる情報処理装置、端末システム、情報処理プログラム、および、更新用データの取得方法を提供することである。

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

【0006】

上記の課題を解決すべく、本発明は、以下の（１）〜（１７）の構成を採用した。

【0007】

（１）
本発明の一例は、ネットワークを介してサーバと通信可能な情報処理装置である。情報処理装置は、更新情報取得部と、第１更新判定部と、第１更新用データ取得部とを備える。更新情報取得部は、アプリケーション毎に更新の有無を判定可能な更新情報を第１のタイミングでサーバから取得し、取得した更新情報を保存する。第１更新判定部は、第１のタイミングとは独立したタイミングであって、前記情報処理装置が非使用モードに移行することに応じたタイミングである第２のタイミングで、情報処理装置がアクセス可能な記憶部に記憶される少なくとも１つのアプリケーションについて更新があるか否かを、保存された更新情報に基づいて判定する。第１更新用データ取得部は、第１更新判定部によって更新があると判定されたアプリケーションについて更新に用いられる更新用データをサーバから取得する。

【0008】

なお、上記において「更新情報を第１のタイミングでサーバから取得する」とは、第１のタイミングで常に更新情報を取得することと、第１のタイミングで必要に応じて（例えば、後述する実施形態のように、新しい更新情報がある場合に）更新情報を取得することとの両方を含む意味である。

【0009】

上記（１）の構成によれば、情報処理装置は、更新情報の取得処理と、更新用データの取得処理とを独立したタイミングで実行する。これによって、情報処理装置は、アプリケーションについての更新の有無の確認と、（更新がある場合の）更新用データの取得とを効率良く行うことができる。また、非使用モードにおいて更新用データが取得されるので、ユーザに待たせることなく（ユーザは更新用データの取得を待つ必要がない）、適切なタイミングで更新用データを取得することができる。

【0010】

（２）
情報処理装置は、第１タイミング判定部と、第２タイミング判定部とをさらに備えていてもよい。第１タイミング判定部は、所定の第１条件が満たされたか否かに基づいて第１のタイミングとなったか否かを判定する。第２タイミング判定部は、第１条件とは異なる第２条件が満たされたか否かに基づいて第２のタイミングとなったか否かを判定する。このとき、第１更新判定部は、第２のタイミングとなったと第２タイミング判定部によって判定された場合に判定を行う。

【0011】

上記（２）の構成によれば、第１のタイミングとは異なる条件で第２のタイミングとなったか否かを判定することにより、更新の有無を判定するタイミングを適切に決定することができる。

【0012】

（３）
更新情報取得部は、複数のアプリケーションについて更新の有無を判定可能な更新情報をサーバから取得してもよい。第１更新判定部は、１つのアプリケーションについて更新があるか否かを判定してもよい。

【0013】

上記（３）の構成によれば、更新情報の取得は複数のアプリケーションについてまとめて１回で行われるのに対して、更新の有無の判定はアプリケーション毎に個別に行われる。これによれば、更新情報の取得をまとめて行うことによって取得処理の回数を減らすことができるとともに、アプリケーション毎に更新の有無を判定することによって判定処理を効率良く行うことができる。

【0014】

（４）
更新情報取得部は、複数のアプリケーションについて更新の有無を判定可能な更新情報をサーバから取得してもよい。第１更新判定部は、更新情報が示す複数のアプリケーションのうちの一部のアプリケーションについて更新があるか否かを判定してもよい。

【0015】

上記（４）の構成によれば、更新情報の取得は複数のアプリケーションについてまとめて１回で行われるのに対して、更新の有無の判定はその一部について行われる。これによれば、更新情報の取得をまとめて行うことによって取得処理の回数を減らすことができるとともに、一部のアプリケーションについてのみ更新の有無を判定することによって判定処理を効率良く行うことができる。

【0016】

（５）
第１のタイミングは、所定の第１操作をユーザが行ったことに起因するタイミングであってもよい。第２のタイミングは、第１操作とは異なる所定の第２操作をユーザが行ったことに起因するタイミングであってもよい。

【0017】

上記（５）の構成によれば、第１および第２のタイミングはそれぞれ、ユーザの操作に応じた到来（発生）する。これによれば、情報処理装置は、定期的に到来するタイミングを測定しなくともよいので、更新に関する処理（更新情報および更新用データの取得処理等）を容易に実行することができる。

【0018】

（６）
第１のタイミングは、情報処理装置の起動から、記憶部に記憶されるアプリケーションを起動する指示が行われるまでのタイミングであってもよい。

【0019】

上記（６）の構成によれば、アプリケーションが起動される前に情報処理装置は新しい更新情報を取得することができる。これによって、情報処理装置は、アプリケーションの実行前に当該アプリケーションについて更新の有無を判定し、必要に応じて更新を行うことができる。

【0020】

（７）
第１のタイミングは、記憶部に記憶されるアプリケーションを起動する指示をユーザが行うことが可能なメニュー画像を表示する処理に応じたタイミングであってもよい。

【0021】

上記（７）の構成によれば、メニュー画像の表示タイミングに応じたタイミングで更新情報が取得される。メニュー画像は、ある程度の頻度で表示されるので、情報処理装置は、更新情報を適切な頻度で取得することができる。これによって、例えば、更新情報の取得処理の頻度が低すぎるために最新の更新情報が取得されない結果、アプリケーションを最新のものに更新できなくなる可能性を低減することができる。

【0022】

（８）
第１更新判定部は、記憶部に記憶されるアプリケーションを起動する指示が行われたことに応じたタイミングで、起動が指示されたアプリケーションについて更新があるか否かをさらに判定してもよい。

【0023】

上記（８）の構成によれば、アプリケーションが起動される場合に情報処理装置は更新用データを取得する。これによれば、利用（実行）されるかどうかがわからないアプリケーションについて更新用データを取得することがなく、更新用データを効率良く取得することができる。また、情報処理装置は、第２のタイミングの前の第１のタイミングで更新情報を予め取得しておくので、アプリケーションの起動時には更新情報を取得しなくてもよい。したがって、アプリケーションの起動指示から実行までの期間を短縮することができ、アプリケーションを起動するまでのユーザの待ち時間を短縮することができる。

【0024】

（９）
第１更新用データ取得部は、更新があると判定されたアプリケーションについて、当該アプリケーションの起動前に更新用データを取得してもよい。このとき、情報処理装置は、第１アプリケーション実行部をさらに備えていてもよい。第１アプリケーション実行部は、記憶部に記憶されるアプリケーションを起動する指示が行われた場合、更新用データによる更新が反映されたアプリケーションを実行する。

【0025】

上記（９）の構成によれば、情報処理装置は、アプリケーションの実行前に当該アプリケーションを更新する。したがって、ユーザは、更新後の新しいバージョンでアプリケーションを利用することができる。

【0026】

（１０）
第１更新判定部は、情報処理装置がアクセス可能な記憶部に記憶されるアプリケーションのうちから、記憶部に記憶されているアプリケーションの実行履歴に基づいて選択される１以上のアプリケーションについて、更新があるか否かを第２のタイミングで判定してもよい。

【0027】

上記（１０）の構成によれば、使用される可能性が高いアプリケーションについて更新の有無の判定を行うので、更新用データを効率良く取得することができる。

【0028】

（１１）
更新情報取得部は、更新情報とともに当該更新情報のバージョンを表す更新バージョン情報を取得して保存し、次に第１のタイミングが到来した場合、更新バージョン情報をサーバから取得し、取得した更新バージョン情報に基づいて更新情報を取得するか否かを判定してもよい。

【0029】

上記（１１）の構成によれば、情報処理装置は、サーバから取得される更新バージョン情報を用いて更新情報を取得するか否かを判定するので、更新情報の取得を効率良く行うことができる。

【0030】

（１２）
更新情報取得部は、サーバにおいて設定される１以上のアプリケーションについて、当該アプリケーションが記憶部に記憶されているか否かに関わらず、更新情報を取得してもよい。

【0031】

上記（１２）の構成によれば、更新情報を送信するサーバは、端末システムから更新情報の送信の要求があった際、どのアプリケーションに関する更新情報を送信するかの判断を行う必要がない。したがって、上記（１２）の構成によれば、サーバにおける処理負担を軽減することができる。

【0032】

（１３）
更新情報取得部は、情報処理装置が実行可能なアプリケーションと、更新用データとのうちの少なくとも一方を当該情報処理装置に提供可能なサーバから更新情報を取得してもよい。

【0033】

上記（１３）の構成によれば、アプリケーションの更新情報を提供するサーバが、そのアプリケーションの更新用データおよび／またはそのアプリケーション自身を提供する。これによれば、提供されるアプリケーションに追加・変更があった場合にサーバにおける管理が容易になる。

【0034】

（１４）
情報処理装置は、第２更新判定部と、第２更新用データ取得部とをさらに備えていてもよい。第２更新判定部は、更新情報が取得されたことに応じて、第２のタイミングにかかわらず、記憶部に記憶されているアプリケーションのうちの所定の条件を満たすアプリケーションについて更新があるか否かを当該更新情報に基づいて判定する。第２更新用データ取得部は、第２更新判定部によって更新があると判定されたアプリケーションについて更新に用いられる更新用データをサーバから取得する。

【0035】

上記（１４）の構成によれば、所定のアプリケーションについては、第２のタイミングにかかわらず更新の有無が判定され、更新があれば更新用データが取得される。これによれば、情報処理装置は、所定のアプリケーションについては第２のタイミング後に更新用データを取得しなくてもよいので、第２のタイミングからアプリケーションの実行までの時間を短縮することができる。

【0036】

（１５）
第２更新判定部は、所定の条件を満たすアプリケーションを、記憶部に記憶されているアプリケーションの実行履歴に基づいて決定してもよい。

【0037】

上記（１５）の構成によれば、実行される可能性が高いアプリケーションについては、第２のタイミングの前に予め更新用データが取得される。これによれば、当該アプリケーションについては第２のタイミングから実行までの期間に更新用データを取得しなくてもよいので、当該期間を短縮することができる。

【0038】

（１６）
第２更新用データ取得部は、更新用データに対応するアプリケーション以外のアプリケーションが情報処理装置において実行されているか否かにかかわらず、当該更新用データを取得してもよい。

【0039】

上記（１６）の構成によれば、更新用データに対応する所定のアプリケーション以外の他のアプリケーションが実行されている場合であっても、情報処理装置は更新用データを取得する。したがって、所定のアプリケーションの更新用データが取得される場合であっても、ユーザは、少なくとも他のアプリケーションを利用することができる。

【0040】

（１７）
情報処理装置は、第２更新判定部によって更新があると判定されたアプリケーションを起動する指示が行われた場合、更新用データによる更新が反映されたアプリケーションを実行する第２アプリケーション実行部をさらに備えていてもよい。

【0041】

上記（１７）の構成によれば、上記所定のアプリケーションについて、ユーザは、更新後の新しいバージョンでアプリケーションを利用することができる。

【0042】

なお、本発明の別の一例は、上記（１）〜（１７）の情報処理装置における各部と同等の機能を備える情報処理システムであってもよいし、当該各部における処理を情報処理装置のコンピュータに実行させる情報処理プログラムであってもよい。また、本発明の別の一例は、上記（１）〜（１７）において実行される更新用データの取得方法であってもよい。

【発明の効果】

【0043】

本発明によれば、更新情報の取得と更新用データの取得とを独立したタイミングで実行することによって、アプリケーションについての更新の有無の確認と、（更新がある場合の）更新用データの取得とを効率良く行うことができる。

【図面の簡単な説明】

【0044】

【図1】情報処理システムの一例の構成を示すブロック図

【図2】情報処理システムにおける動作の一例を示す図

【図3】更新情報の取得処理における動作の一例を示す図

【図4】優先アプリケーションの更新に関する動作の一例を示す図

【図5】端末システムの記憶部に設定されるデータ領域の一例を示す図

【図6】制御部のＣＰＵが実行する情報処理の流れの一例を示すフローチャート

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

【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】

アプリケーションの更新が行われるタイミングは、更新用データの取得処理後における任意のタイミングでよい。本実施形態においては、更新用データの取得処理に続けてアプリケーションの更新が行われる。ただし、他の実施形態においては、更新用データの取得とアプリケーションの更新とは、連続して行われなくてもよい。

【0087】

また、本実施形態においては、アプリケーションの更新はアプリケーションの実行前に行われる（図２参照）。すなわち、アプリケーションの更新が完了すると、端末システム３は更新後のアプリケーションを実行する。このように、本実施形態においては、端末システム３は、更新があると判定されたアプリケーションについて、当該アプリケーションの起動前に更新用データを取得し、更新用データによる更新が反映されたアプリケーションを実行する。したがって、本実施形態によれば、更新が反映されたアプリケーションが実行されるので、ユーザは、更新後の新しいバージョン（理想的には最新バージョン）でアプリケーションを利用することができる。

【0088】

（２−７：他のタイミングで更新用データを取得する処理）
上述のように、本実施形態においては、基本的には第１のタイミングと異なる第２タイミングでアプリケーションの更新の有無が判定される。ただし、本実施形態において、記憶部１５に記憶されるアプリケーションのうちの所定のアプリケーション（以下、「優先アプリケーション」と呼ぶ。）については、更新の有無の判定が第１のタイミングに続けて（更新情報の取得に続けて）実行される。そして、更新があると判定される場合には、更新用データの取得処理が続けて実行される。つまり、本実施形態において端末システム３は、優先アプリケーションについては起動前に予め更新用データを取得しておくことによって、起動時に要する時間を短縮するようにしている。以下、優先アプリケーションの更新に関する動作の詳細を説明する。

【0089】

図４は、優先アプリケーションの更新に関する動作の一例を示す図である。図４において、更新情報の取得処理は図２と同様である。更新情報の取得処理が完了すると、端末システム３は、１以上の優先アプリケーションについて更新の有無の判定を行う（ステップＳ７）。更新の有無の判定方法は、優先アプリケーション以外の他のアプリケーションの場合と同様である。また、優先アプリケーションが複数である場合、端末システム３は、各優先アプリケーションについて更新の有無を判定する。

【0090】

上記判定の結果、優先アプリケーションについて更新があると判定された場合、端末システム３は、判定処理に続いて更新用データの取得処理を実行する（図４参照）。更新用データの取得処理の具体的な動作は、優先アプリケーション以外の他のアプリケーションの場合と同様である。なお、複数の優先アプリケーションについて更新があると判定された場合、端末システム３は、各優先アプリケーションについて更新用データの取得処理を実行する。

【0091】

なお、優先アプリケーションについての更新用データの取得処理は、バックグラウンドで行われてもよい。すなわち、表示部１３にメニュー画像が表示された後、他のアプリケーションが端末システム３において実行される場合、端末システム３は、当該他のアプリケーションの実行中に更新用データの取得処理を実行してもよい。このように、本実施形態においては、端末システム３は、更新用データに対応する優先アプリケーション以外の他のアプリケーションが実行されているか否かにかかわらず、当該更新用データを取得する。これによれば、優先アプリケーションの更新用データが取得される場合であっても、ユーザは、メニュー画像の表示後すぐに他のアプリケーションを利用することができる。

【0092】

また、優先アプリケーションについての更新用データの取得処理は、当該優先アプリケーションの実行中においてもバックグラウンドで実行されてもよい。つまり、端末システム３は、アプリケーション（更新用データが取得中のアプリケーションを含む）が情報処理装置において実行されているか否かにかかわらず、更新用データを取得してもよい。なお、更新用データの取得処理がその更新用データに対応する優先アプリケーションの実行中において行われる場合、端末システム３は、取得された更新用データによる更新を、実行中の優先アプリケーションが終了した後で行うようにしてもよい。例えば、取得された更新用データによる更新は、次に当該優先アプリケーションが起動されるタイミングで行われてもよい。

【0093】

また、図４に示すように、優先アプリケーションについて第２のタイミングが到来した場合、端末システム３は、当該優先アプリケーションの更新を行う（ステップＳ８）。すなわち、優先アプリケーションを起動する第２操作がユーザによって行われた場合、端末システム３は、更新用データを用いて当該優先アプリケーションの更新を行う。なお、更新の具体的な方法は、優先アプリケーション以外の他のアプリケーションの場合と同様である。

【0094】

優先アプリケーションを更新した後、端末システム３は、更新後の優先アプリケーションを実行する（ステップＳ９）。すなわち、更新があると判定された優先アプリケーションを起動する指示が行われた場合、端末システム３は、更新用データによる更新が反映されたアプリケーションを実行する。したがって、優先アプリケーションについても他のアプリケーションと同様、ユーザは、更新後の新しいバージョン（理想的には最新バージョン）でアプリケーションを利用することができる。

【0095】

優先アプリケーションはどのように決定されてもよいが、本実施形態においては、（今後に）実行される可能性が高いアプリケーションが優先アプリケーションとして決定される。つまり、本実施形態において端末システム３は、実行される可能性が高いアプリケーションについては、起動指示が行われる前に予め更新用データを取得しておく。これによれば、当該アプリケーションの起動指示から実行までの期間に更新用データを取得しなくてもよいので、当該期間を短縮することができる。

【0096】

具体的には、本実施形態においては、優先アプリケーションは、起動された日時が新しいものから所定数のアプリケーションである。つまり、最近起動された所定数のアプリケーションが優先アプリケーションとなる。最近起動されたアプリケーションは、今後も実行される可能性が高いと推定できるからである。なお、他の実施形態においては、例えば過去所定期間以内（例えば１週間以内）に実行されたアプリケーションが、優先アプリケーションとして選択されてもよい。また例えば、ユーザがお気に入りとして登録したアプリケーションが、優先アプリケーションとして選択されてもよい。また例えば、実行回数が多いものから順に所定数のアプリケーション、あるいは、（通算の）実行時間が長いものから順に所定数のアプリケ−ションが、優先アプリケーションとして選択されてもよい。

【0097】

本実施形態においては、優先アプリケーションは、記憶部１５に記憶されている各アプリケーションの実行履歴に基づいて決定される。具体的には、本実施形態において、端末システム３は、アプリケーションが起動された日時を上記実行履歴として保存しておき、当該日時が新しいものから順に所定数のアプリケーションを示すリスト（優先リスト）を作成する。この優先リストは、アプリケーションが実行される度に更新される。優先アプリケーションについて更新の有無を判定する場合、端末システム３は、上記優先リストに基づいて優先アプリケーションを決定する。

【0098】

なお、優先アプリケーションは、実行履歴に基づく決定方法に関わらず、他の方法（条件）に基づいて決定されてもよい。例えば他の実施形態においては、端末システム３は、ユーザが指定したアプリケーションを優先アプリケーションとして決定してもよい。また例えば、サーバ２が指定したアプリケーションを優先アプリケーションとして決定してもよい。すなわち、サーバ２が更新用データの緊急度あるいは重要度等に応じて優先アプリケーションを決定してもよい。

【0099】

以上のように、本実施形態においては、端末システム３は、更新情報が取得されたことに応じて、第２のタイミングにかかわらず、記憶部１５に記憶されているアプリケーションのうちの所定の条件を満たすアプリケーション（優先アプリケーション）について更新があるか否かを当該更新情報に基づいて判定する。そして、端末システム３は、更新があると判定されたアプリケーションについて更新に用いられる更新用データを（第２のタイミングが到来したか否かにかかわらず）サーバ２から取得する。優先アプリケーションについては、端末システム３は、ユーザによって起動指示が行われた後で更新用データを取得しなくてもよい。そのため、本実施形態によれば、優先アプリケーションについては、起動指示から実行までの時間を短縮することができる。

【0100】

また、本実施形態においては、実行される可能性が高いアプリケーションを優先アプリケーションとするので、第２のタイミングの到来前に取得された更新用データが（そのアプリケーションが起動されないために）使用されないままになる可能性が低い。すなわち、本実施形態においては、更新用データを効率良く取得することができる。

【0101】

また、本実施形態において、端末システム３は、記憶部１５に記憶されているアプリケーションのうちのいくつかのアプリケーションについては、常に最新の更新が反映された状態でアプリケーションが実行されるようにしてもよい。すなわち、端末システム３は、上記いくつかのアプリケーションについては、起動時において更新情報を取得するようにしてもよいし、起動時に常に更新用データを取得するようにしてもよい。なお、上記いくつかのアプリケーションは例えばサーバ２によって指定されてもよい。

【0102】

［３．情報処理システムにおける処理の詳細］
（３−１）情報処理に用いられるデータ
以下、図５および図６を参照して、本実施形態において情報処理システム１（端末システム３）で実行される具体的な処理の一例について説明する。図５は、本実施形態において端末システム３の記憶部１５に設定されるデータ領域の一例を示す図である。図５に示すように、端末システム３の記憶部１５は、プログラム格納領域３１および処理用データ格納領域３３を有する。なお、記憶部１５には、図５に示すデータの他、表示部１３へ出力すべき画像やそれを生成するために用いられる画像のデータ等が記憶される。

【0103】

プログラム格納領域３１には、情報処理プログラム３２が記憶される。情報処理プログラム３２は、端末システム３のコンピュータ（制御部１４）に実行させるためのプログラムである。なお、本実施形態においては、情報処理プログラム３２は、制御部１４がアクセス可能であって端末システム３の内部または外部に設けられるプログラム格納部（記憶装置または記憶媒体等）に記憶されている。プログラム格納部に記憶される情報処理プログラム３２の一部または全部が適宜のタイミングで読み込まれて制御部１４のメモリに記憶され、ＣＰＵによって実行される。また、情報処理プログラム３２の一部または全部は、制御部１４を有する情報処理装置内に予め記憶されていてもよい。

【0104】

また、プログラム格納領域３１には、端末システム３において実行可能なアプリケーション２４が記憶される。なお、図１および図５においてはアプリケーションを１つのみ示すが、プログラム格納領域３１には、１以上のアプリケーションが記憶されてもよい。

【0105】

処理用データ格納領域３３には、端末システム３において実行される情報処理（図６に示す情報処理）において用いられる各種のデータが記憶される。処理用データ格納領域３３には、図１に示す更新情報２５および更新用データ２６が記憶される。更新情報２５は、最新のもの（サーバ２から最後に取得されたもの）のみが記憶されてもよい。更新用データ２６は、アプリケーション毎に、アプリケーションの実行に必要なもののみが記憶されてもよい。

【0106】

また、処理用データ格納領域３３には、上述の更新バージョン情報３４が記憶される。更新バージョン情報３４は、最新のもの（サーバ２から最後に取得されたもの）のみが記憶されてもよい。また、処理用データ格納領域３３には、優先リストデータ３５が記憶される。優先リストデータ３５は、１以上の優先アプリケーションを示す上記優先リストを表すデータである。

【0107】

（３−２）情報処理の具体例
次に、本実施形態における情報処理の詳細な流れを説明する。図６は、本実施形態において制御部１４のＣＰＵが実行する情報処理の流れの一例を示すフローチャートである。本実施形態においては、端末システム３が起動されると、制御部１４のＣＰＵは、メモリ等を初期化し、プログラム格納部から情報処理プログラム３２をメモリに読み込む。そして、ＣＰＵによって当該情報処理プログラム３２の実行が開始される。

【0108】

なお、図６に示すフローチャートにおける各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよいし、各ステップの処理に加えて（または代えて）別の処理が実行されてもよい。また、本実施形態では、上記フローチャートの各ステップの処理を制御部１４のＣＰＵが実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、ＣＰＵ以外のプロセッサや専用回路が実行するようにしてもよい。

【0109】

本実施形態においては、まずステップＳ１１において、制御部１４は、メニュー画像の表示処理を開始する。本実施形態において、ステップＳ１１で開始されたメニュー画像の表示処理は、後述するステップＳ１５の処理の前に完了すればよい。

【0110】

ステップＳ１２において、制御部１４は更新情報の取得処理を実行する。更新情報の取得処理は、上記"（２−３：更新情報の取得処理）"で述べた方法で行われてもよい。具体的な処理としては、制御部１４は、通信部１１を介してサーバ２から取得された更新情報２５を記憶部１５に記憶する。

【0111】

ステップＳ１３において、制御部１４は、優先アプリケーションについて更新の有無を判定する。本実施形態においては、制御部１４は、記憶部１５に記憶される優先リストデータ３５を読み出して参照することによって、優先アプリケーションを特定する。そして、特定した優先アプリケーションについて、例えば上記"（２−４：アプリケーションの更新の有無の判定）"で述べた方法で更新の有無の判定を行う。ステップＳ１３の判定結果が肯定である場合、ステップＳ１４の処理が実行される。一方、ステップＳ１３の判定結果が否定である場合、ステップＳ１４の処理がスキップされてステップＳ１５の処理が実行される。

【0112】

ステップＳ１４において、制御部１４は、更新があると判定された優先アプリケーションについて更新用データの取得処理を開始する。なお、ステップＳ１４で開始される取得処理は、優先アプリケーション自身が起動されなければ、ステップＳ１５の処理以降においてもバックグラウンドで実行されてもよい。また、他の実施形態においては、更新用データの取得処理中に優先アプリケーション自身が起動される場合でも、ステップＳ１５の処理以降において更新用データの取得処理がバックグラウンドで実行されてもよい。このとき、例えば更新用データの取得が完了した後で優先アプリケーションが起動されるタイミングで、取得された更新用データを用いた更新が行われる。

【0113】

ステップＳ１５において、制御部１４は、アプリケーションの起動指示が行われたか否かを判定する。ステップＳ１５の処理は、上記第２のタイミングとなったか否かを判定するための処理である。例えば、ステップＳ１の処理によって表示部１３にメニュー画像が表示され、当該メニュー画像に含まれるアプリケーションのアイコンを指定する操作（第２操作）が行われた場合、制御部１４は、アプリケーションの起動指示が行われたと判定する。ステップＳ１５の判定結果が肯定である場合、ステップＳ１６の処理が実行される。一方、ステップＳ１５の判定結果が否定である場合、ステップＳ１５の処理が再度実行される。つまり、制御部１４は、アプリケーションの起動指示が行われるまでステップＳ１５を繰り返し実行する。

【0114】

ステップＳ１６において、制御部１４は、起動指示が行われたアプリケーションが優先アプリケーションであるか否かを判定する。なお、ステップＳ１６の判定は、記憶部１５に記憶される優先リストデータ３５を読み出して参照することによって行うことができる。ステップＳ１６の判定結果が否定である場合、ステップＳ１７の処理が実行される。一方、ステップＳ１６の判定結果が肯定である場合、後述するステップＳ２０の処理が実行される。

【0115】

ステップＳ１７において、制御部１４は、起動指示が行われたアプリケーションについて更新の有無を判定する。すなわち、制御部１４は、起動指示が行われたアプリケーションについて、例えば上記"（２−４：アプリケーションの更新の有無の判定）"で述べた方法で更新の有無の判定を行う。ステップＳ１７の判定結果が肯定である場合、ステップＳ１８の処理が実行される。一方、ステップＳ１７の判定結果が否定である場合、ステップＳ１８およびＳ１９の処理がスキップされて後述するステップＳ２２の処理が実行される。

【0116】

ステップＳ１８において、制御部１４は、起動指示が行われたアプリケーションについて更新用データを取得する。制御部１４は、例えば上記"（２−５：更新用データの取得処理）"で述べた方法で更新用データをサーバ２から取得する。取得された更新用データ２６は記憶部１５に記憶される。

【0117】

ステップＳ１９において、制御部１４は、起動指示が行われたアプリケーションの更新を行う。制御部１４は、例えば、上記"（２−６：アプリケーションの更新）"で述べた方法で更新を行う。ステップＳ１９の次に、制御部１４は後述するステップＳ２２の処理を実行する。

【0118】

一方、ステップＳ２０において、制御部１４は、起動指示が行われたアプリケーションについて更新用データが取得されているか否かを判定する。この判定は、起動指示が行われたアプリケーションについて、更新に用いられていない更新用データがあるか否かによって行われる。具体的には、制御部１４は、直前のステップＳ１４において更新用データが取得されたか否かを判定する。ステップＳ２０の判定結果が肯定である場合、ステップＳ２１の処理が実行される。一方、ステップＳ２０の判定結果が否定である場合、ステップＳ２１の処理がスキップされてステップＳ２２の処理が実行される。

【0119】

ステップＳ２１において、制御部１４は、起動指示が行われたアプリケーションの更新を行う。ステップＳ２１の処理は、ステップＳ１９の処理と同様である。ステップＳ２１の次に、制御部１４はステップＳ２２の処理を実行する。

【0120】

ステップＳ２２において、制御部１４は、起動指示が行われたアプリケーションを実行する。本実施形態においては、上記ステップＳ１９またはＳ２１の処理によって必要に応じてアプリケーションが更新されるので、更新後の新しいバージョンでアプリケーションが実行される。また、ステップＳ２２においてアプリケーションが実行されると、制御部１４は当該アプリケーションについての実行履歴（具体的には起動日時）を更新する。さらに、制御部１４は、必要に応じて上記優先リストデータ３５の内容を更新する。

【0121】

ステップＳ２２においてアプリケーションが終了すると、上記ステップＳ１１の処理が実行される。つまり、アプリケーションが終了すると、表示部１３にはメニュー画像が再度表示される。そして、ステップＳ１２の処理が再度実行される。したがって、本実施形態においては、端末システム３の起動直後にメニュー画像が表示された場合と、アプリケーションの終了後にメニュー画像が表示された場合とにおいて更新情報が取得される。なお、他の実施形態においては、端末システム３は、上記２つの場合のうちいずれか一方の場合にのみ更新情報を取得するようにしてもよい。以上で、図６に示す処理の説明を終了する。

【0122】

なお、図６に示す情報処理は、ユーザによる所定の指示に応じて終了される。例えばメニュー画像が表示される場合に終了指示を行うことができるようにしてもよい。このとき、例えば端末システム３がサーバ２と通信中（例えば更新情報あるいは更新用データの取得中）である場合には、端末システム３は、通信が終了してから図６に示す情報処理を終了するようにしてもよい。

【0123】

［４．変形例］
（非使用モード移行時における処理）
また、他の実施形態においては、端末システム３が非使用モードを有する場合、非使用モードに移行するタイミングで、更新に関する処理（更新情報および更新用データの取得処理等）が実行されてもよい。ここで、非使用モードとは、ユーザによる端末システム３の使用が行われない状態であり、例えば、いわゆるスリープモードである。なお、非使用モードは、表示装置がオフにされるモード（省電力モード）であってもよい。また例えば、端末システム３が開閉可能（折りたたみ可能）な情報処理装置を含む場合、当該情報処理装置が閉じられた状態において非使用モードに移行してもよい。本実施形態において、非使用モードにおいては、使用モードに移行するための指示入力以外は受け付けられず、端末システム３において予め定められた処理が実行される。例えば、端末システム３は、非使用モードへ移行する旨のユーザ指示が行われたことを条件として、非使用モードに移行する。また例えば、端末システム３は、使用モードにおいてユーザによる入力が一定時間行われないことを条件として、非使用モードに移行する。

【0124】

上記第２のタイミングは、端末システム３が非使用モードに移行することに応じたタイミングであってもよい。すなわち、端末システム３が非使用モードに移行したことに応じて、制御部１４は、アプリケーションの更新の有無を判定してもよい。より具体的には、制御部１４は、端末システム３が非使用モードに移行する条件（例えば、非使用モードへ移行する旨のユーザ操作が行われたことや、使用モードにおいてユーザによる入力が一定時間行われないこと等）が満たされたか否かを判定し、条件が満たされた場合に、更新の有無の判定を行う。そして、更新があると判定されるアプリケーションについて、制御部１４は更新用データを取得してもよく、さらに、アプリケーションの更新を行ってもよい。

【0125】

このとき、更新の判定の対象となるアプリケーションは任意であるが、例えば、上述したアプリケーションの実行履歴に基づいて選択されてもよい。すなわち、端末システム３は、上記“（２−７：他のタイミングで更新用データを取得する処理）”で述べた優先リストと同様の、以下のアプリケーションを示すリストを実行履歴に基づき生成し、生成したリストで示されるアプリケーションについて更新の有無を判定してもよい。
・最近起動された所定数（１つでもよいし、複数でもよい）のアプリケーション
・過去所定期間以内（例えば１週間以内）に実行されたアプリケーション
・実行回数が多いものから順に所定数のアプリケーション
・（通算の）実行時間が長いものから順に所定数のアプリケ−ション
また、更新の有無を判定するアプリケーションは、上記の他、ユーザがお気に入りとして登録したアプリケーションであってもよいし、サーバ２が指定したアプリケーションであってもよい。また、更新の有無を判定するアプリケーションは、端末システム３において記憶されている（全ての）アプリケーションであってもよい。

【0126】

以上によっても、上記実施形態と同様、端末システム３は、更新情報の取得処理と、更新用データの取得処理とを別々のタイミングで実行することができ、アプリケーションについての更新の有無の確認と、（更新がある場合の）更新用データの取得とを効率良く行うことができる。また、第２のタイミングで更新の有無を判定する対象となるアプリケーションが実行履歴に基づいて選択される場合には、使用される可能性が高いアプリケーションについて更新用データを取得することができるので、更新用データを効率良く取得することができる。また、上記によれば、端末システム３は、更新情報の取得は複数のアプリケーションについてまとめて１回で行われるのに対して、当該複数のアプリケーションのうちの一部のアプリケーションについて更新の有無を判定する。そのため、上記実施形態と同様、判定処理を効率良く行うことができる。

【0127】

また、端末システム３は、第２のタイミングとして、上記実施形態で述べたアプリケーションの起動タイミング（優先アプリケーションについては更新情報の取得後のタイミング）と、非使用モードに移行することに応じたタイミングとの両方で、更新の有無を判定してもよい。これによって、端末システム３は、最新の更新用データを取得しやすくなり、アプリケーションを最新の状態に維持しやすくなる。

【0128】

また、他の実施形態においては、端末システム３は、上記実施形態で述べたメニュー画面の表示タイミングに加え（または代えて）、非使用モードに移行するタイミングで、更新情報を取得するようにしてもよい。すなわち、端末システム３は、非使用モードに移行すると、まず、更新情報の取得処理を実行してもよい。その後、端末システム３は、取得した更新情報を用いて、上述した更新の有無の判定処理を実行してもよい。これによれば、端末システム３は、最新の更新情報を取得しやすくなり、アプリケーションを最新の状態に維持しやすくなる。

【0129】

また、他の実施形態においては、端末システム３は、非使用モード中において一定時間毎に繰り返し、更新情報の取得処理と、更新の有無の判定処理（および、更新処理）とを実行してもよい。これによれば、更新の有無の判定を行う頻度を高くすることができ、アプリケーションを最新の状態に維持しやすくなる。

【産業上の利用可能性】

【0130】

以上のように、上記実施形態は、アプリケーションの更新を効率良く実行すること等を目的として、例えばアプリケーションを実行する情報処理装置や端末システム等に利用することが可能である。

【符号の説明】

【0131】

１ 情報処理システム
２ サーバ
３ 端末システム
４ ネットワーク
１１ 通信部
１２ 入力部
１３ 表示部
１４ 制御部
１５ 記憶部
２１，２６ 更新用データ
２２，２５ 更新情報
２４ アプリケーション
３２ 情報処理プログラム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】