JP6504000B2

JP6504000B2 - データ配信制御プログラム、データ配信制御方法及びデータ配信装置

Info

Publication number: JP6504000B2
Application number: JP2015182964A
Authority: JP
Inventors: 竜志里本
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2015-09-16
Filing date: 2015-09-16
Publication date: 2019-04-24
Anticipated expiration: 2035-09-16
Also published as: JP2017058935A

Description

本発明は，データ配信制御プログラム、データ配信制御方法及びデータ配信装置に関する。

企業や官公庁（以下まとめて企業）は、スマートホンやパッド端末などスマートデバイスを業務に利用することを積極的に行っている。企業は、スマートデバイス用の業務アプリを開発し、業務アプリをスマートデバイスにダウンロードし、業務を効率化する。

さらに、業務で利用されるスマートデバイスは、企業が社員に支給する社給スマートデバイスから、社員が個人所有するスマートデバイス（BYOD: Bring Your Own Device、以下個人スマートデバイス）に拡がっている。

このようにスマートデバイスに業務アプリをダウンロードして業務に活用する場合、業務アプリの新規導入、障害修正、アップグレードなどのために、スマートデバイスに業務アプリの配信が一斉に行われる。特に、業務アプリのセキュリティ障害の修正のための修正アプリは、迅速に配信しなければならない。以下、簡単のためにスマートデバイスを端末装置または端末と称する。

一般に、企業は、業務アプリのデータを配信するアプリ配信サーバと、業務アプリのデータを保管する管理サーバとを配備し、アプリ配信サーバは、端末からの業務アプリのダウンロード要求に応じて、端末装置に要求された業務アプリをダウンロードする。

特開２００４−６２８９２号公報特開２００４−２４１９７５号公報国際公開第２０１４／０３０４２６号米国特許出願公開第２００５／０１５４７５９号明細書

アプリ配信サーバは、一斉配信の場合、アプリ配信要求を受け付けてから管理サーバが保管する業務アプリのデータをダウンロードして内部のメモリに保存し、要求元の端末に内部メモリに保存した業務アプリをダウンロードする。ダウンロード後、アプリ配信サーバはダウンロードされた業務アプリを内部メモリから削除する。

しかしながら、一斉配信の場合、複数の端末が一斉にまたは時間を空けてアプリ配信要求を行うため、アプリ配信要求のたびに管理サーバからアプリをダウンロードして内部メモリに保存する処理が発生し、アプリ配信要求に対するレスポンスが低下する。

一方、一斉配信の場合複数の端末がアプリ配信要求を行うので、アプリ配信サーバが一旦ダウンロードして内部メモリに保存したアプリを保持し続けて、次のアプリ配信要求に応答して内部メモリ内のアプリを即座にダウンロードすることで、上記のレスポンスの低下を回避できる。

しかしながら、複数種類の業務アプリが一斉配信の対象になると、アプリ配信サーバの内部メモリの最大記憶容量を超えるアプリの保持が必要になり、内部メモリの容量を増大することによるコストアップを招く。

そこで，実施の形態の第１の側面の目的は，アプリの配信性能を向上させたデータ配信制御プログラム、データ配信制御方法及びデータ配信装置を提供することにある。

第１の態様は，端末装置に対するアプリケーションの導入または更新に用いられるデータの配信を行うデータ配信装置に、
前記データの格納元から取得され前記配信装置の記憶部に記憶された前記データが第１の端末装置に配信された場合、第２の端末装置の利用者の前記第２の端末装置と異なる第２の他の端末装置のログ情報と、データの前記第２の端末装置への配信実績情報とに基づいて、前記第２の他の端末装置にて前記データの利用申請が実行されたタイミング後に、前記配信装置が前記第２の端末装置から配信要求を受け付けるタイミングの第１の時刻を特定し、
前記データの格納元から前記配信装置の記憶部への前記データのダウンロードに要する時間が、前記特定した第１の時刻までの時間より長い場合は、前記記憶部に記憶された前記データを保持し、前記ダウンロードに要する時間が前記特定した第１の時刻までの時間より短い場合は、前記記憶部に記憶された前記データを消去する、
処理を実行させるデータ配信制御プログラムである。

一つの側面によれば，アプリの配信性能が向上する。

業務用のアプリを端末に配信するためのアプリ配信システムの構成を示す図である。従来のアプリ配信のシーケンスを示す図である。従来のアプリ配信のシーケンスを示す図である。管理サーバ１１の構成例を示す図である。社内アプリストア１２の構成例を示す図である。配信サーバ１３の構成例を示す図である。端末の構成例を示す図である。パソコン１５、１７の構成例を示す図である。第１の実施の形態におけるアプリ配信処理のシーケンス図である。第１の実施の形態におけるアプリ配信処理のシーケンス図である。第１の実施の形態におけるアプリ配信処理のシーケンス図である。配信サーバによるアプリ配信処理の概略を示すフローチャート図である。配信サーバによるアプリ管理処理の詳細を示すフローチャート図である。端末の動作例を示すフローチャート図である。第１の実施の形態におけるパソコンの操作ログとアプリ配信実績の一例を示す図である。パソコンの操作ログの例とアプリ配信実績の例を示す図である。

図１は、業務用のアプリを端末に配信するためのアプリ配信システムの構成を示す図である。企業内には、配信するアプリとそのマニフェストファイルとを保管する管理サーバ１１と、利用者がアプリの利用申請を行う社内アプリストア１２と、アプリを端末に配信する配信サーバ１３と、イントラネットNET1が設けられる。さらに、企業内には、複数の端末（スマートデバイス）１４、１６とそれぞれのユーザが業務で使用する複数のパソコン１５、１７が配置される。つまり、ユーザAは端末１４とパソコン１５を操作し、ユーザBは端末１６とパソコン１７を操作する。

パソコンは、イントラネットNET1を介して社内アプリストア１２と配信サーバ１３にアクセス可能である。また、管理サーバ１１は、イントラネットNET1を介して社内アプリストア１２と配信サーバ１３と通信可能である。

企業内ネットワークであるイントラネットNET1は、ファイアウオールFWを介して外部のインターネットNET2と接続可能であり、インターネットNET2にはPNSサーバ１０が配置されている。PNS(Push Notification Service)サーバは、スマートデバイスなどの端末にプッシュ通信を行うサーバである。端末は、イントラネットNET1とインターネットNET2を介して、または、図示しない電話通信回線とインターネットNET2を介してPNSサーバ１０にアクセス可能である。

［従来のアプリ配信］
図２、図３は、従来のアプリ配信のシーケンスを示す図である。配信サーバ１３から端末１４、１６にアプリが一斉に配信される処理のシーケンスを簡単に説明する。まず、事前に、管理サーバ１１は、端末１４、１６とパソコン１５、１７からアドレスや端末ID、パソコンIDなどのインベントリ情報を収集する（S1）。また、管理サーバ１１には、配信するアプリのデータとそのマニフェストファイルが格納されている。さらに、図示しないが、端末１４、１６は、予め配信サーバ１３にアクセスして、端末の登録を行い、それぞれの端末の認証情報を取得している。この端末の認証情報はアプリ配信時の配信サーバでの認証に使用される。

次に、パソコン１５が、社内アプリストア１２にアクセスし、端末１４へのアプリAの利用申請を行う（S2）。同様に、パソコン１７が、社内アプリストア１２にアクセスし、端末１６へのアプリAの利用申請を行う（S3）。つまり、複数のパソコン１５、１７が社内アプリストラ１２にアプリAの利用申請を行う。これに応じて、社内アプリストア１２は、管理サーバ１１に、端末１４、１６へアプリAを配信するアプリ配信タスクを登録する（S4）。これにより、社内のアプリ配信システムは、複数の端末に対してアプリをダウンロードすることが必要になる。

配信サーバ１３は、管理サーバ１１に定期的にアクセスして、配信するアプリの有無を確認する（S7）。これに応答して、管理サーバ１１は、配信サーバ１３に、端末１４、１６に対して配信するアプリがあることを返信する（S8）。

その後、配信サーバ１３は、端末１４、１６に対して配信すべきアプリを通知するために、PNSサーバ１０に端末１４、１６へのアプリ配信の通知を依頼し、PSNサーバに端末１４、１６へのプッシュ通知を登録する(S9)。

図３に移り、端末１４が、PNSサーバ１０にアクセスしアプリ配信通知有無の確認を行う（S15）。端末１４はこのような確認を定期的に実行する。これに応答して、PSNサーバ１０は、端末１４に対するアプリAの配信タスクの登録があることを、端末１４に返信する（S16）。これが、PNSサーバ１０から端末１４へのプッシュ通信である。

そこで、端末１４は、このプッシュ通信に応答して、配信サーバ１３にアクセスし、配信アプリのマニフェストファイルの配信を要求する（S17）。マニフェストファイルは、後述するとおり、端末１４が配信アプリのダウンロードの承認を端末画面で行うためのプログラムファイルであり、データ容量は非常に小さい。配信サーバ１３は、このマニフェスト配信要求に応答して、管理サーバ１１から対応するマニフェストファイルをダウンロードし（S17_1）、端末１４にマニフェストファイルをダウンロードする(S17_2)。そこで、端末１４のディスプレイに表示された承認画面で利用者がダウンロードを承認する操作を行うと（S18）、端末１４は配信サーバ１３にアクセスしてアプリAの配信要求を行う（S19）。配信サーバ１３は、このアプリ配信要求に応答して、管理サーバ１１から対応するアプリAのデータをダウンロードしてメモリに格納し（S19_1）、端末１４にアプリAのデータをダウンロードする(S19_2)。そして、端末１４はダウンロードしたアプリAをインストールする（S20）。また、配信サーバ１３は、ダウンロード完了後に、そのアプリAをメモリから削除する（S19_3）。

一方、端末１６も、PNSサーバ１０にアクセスしアプリ配信通知有無の確認を行う（S23）。これに応答して、PSNサーバ１０は、端末１６に対するアプリAの配信タスクの登録があることを、端末１６に返信する（S24）。その後の動作は、端末１４がアプリAをダウンロードする場合の動作と同じであり、端末１６が配信サーバ１３にマニフェストファイルの配信要求を送信し（S25）、配信サーバ１３が管理サーバ１１からマニフェストファイルをダウンロードし（S25_1）、端末１６にダウンロードする（S25_2）。端末１６の利用者が承認画面で承認操作を行うと（S26）、端末１６が配信サーバ１３にアプリAの配信要求を送信し（S27）、配信サーバ１３が管理サーバ１１からアプリAのデータをダウンロードし（S27_1）、端末１６にダウンロードする（S27_2）。端末１６はダウンロードしたアプリAをインストールする（S28）。また、配信サーバ１３は、ダウンロード完了後に、そのアプリAをメモリから削除する（S27_3）。

上記の通り、従来のアプリ配信によれば、配信サーバ１３が端末からのアプリ配信要求に応答して管理サーバ１１からアプリをダウンロードしメモリ内に格納し、端末にアプリをダウンロードした後、アプリをメモリから削除している。これにより、配信サーバ１３は内部メモリの容量を最小限に抑えることができる。

しかしながら、アプリのデータ容量は比較的大きく、端末からのアプリ配信要求を受けるたびに管理サーバ１１からダウンロードして内部メモリに格納すると、そのダウンロードとメモリへの格納に時間を要する。特に、複数の端末に同じアプリAを一斉に配信する場合、アプリ配信要求を受信するたびに管理サーバからアプリをダウンロードする必要が生じ、アプリ配信要求に対するレスポンスの低下が発生する。

［第１の実施の形態］
第１の実施の形態では、第１の端末へのアプリのダウンロードが完了した時に、第２の端末がアプリ配信要求を送信する時刻を、第２の端末の利用者による第２のパソコンからの利用申請の操作ログと、第２の端末のアプリ配信実績（過去のアプリ配信時での第２のパソコンによる利用申請から第２の端末による配信要求までに要した時間）とから、今回の第２の端末のアプリ配信要求の時刻を予測する。そして、管理サーバからのアプリのダウンロード時間をその時のネットワーク状態やアプリのデータ容量などに基づいて予測し、予測ダウンロード時間が現在からアプリ配信要求の予測時刻までの時間以上長い場合、配信サーバはアプリを内部メモリ内に保持し、未満であればアプリを内部メモリから削除する。

これにより、配信サーバ内の内部メモリを効率的に利用し、アプリの一斉配信でのアプリ配信要求に対するレスポンスの低下を抑制できる。

以下、各装置、端末の構成を説明した後、第１の実施の形態におけるアプリ配信のシーケンスを説明する。

図４は、管理サーバ１１の構成例を示す図である。管理サーバ１１は、配信対象のアプリとそのマニフェストファイルを保管し、アプリ配信の管理と企業内のパソコンの操作ログを収集する。端末が個人所有の場合、管理サーバは端末の操作ログを収集することはプライバシーの観点から好ましくない。したがって、第１の実施の形態では、端末の操作ログの収集は行っていない。また、端末によるアプリ配信要求の操作時刻は配信サーバがその要求を受信したことで収集する。

管理サーバ１１は、CPU２０と、メインメモリ２１と、ネットワークインターフェースカード（NIC）２２と、バス２３と、補助記憶装置であるストレージ２４、２５を有する。ストレージ２４内には、アプリ配信用の配信管理プログラム２４１と、操作ログ収集プログラム２４２とが記憶され、これらのプログラムはメモリ２１に展開されCPU２０により実行される。また、ストレージ２５内には、配信対象のアプリ２５２とそのマニフェストファイル２５１とが記憶される。新たにアプリが開発された場合や、アプリがアップデートされた場合、さらに修正パッチファイルが作成された場合、それらのアプリデータが管理サーバ１１内のストレージ２５に格納される。さらに、ストレージ２５内には、アプリ配信タスク情報（端末に対する配信対象のアプリとマニフェストファイルとの対応情報）２５３と、パソコンの操作ログ２５３とが記憶される。さらに、ストレージ２５内には、端末とパソコンの情報を登録した登録ファイル２５４が記憶される。

図５は、社内アプリストア１２の構成例を示す図である。社内アプリストア１２は、サーバなどの情報処理装置であり、各端末の利用者が使用するパソコンからのアプリ利用申請を受け付けるウエブサイトを提供し、アプリ利用申請を受け付けると、その利用申請情報を管理サーバ１１のアプリ配信タスク情報２５３に登録する。社内アプリストア１２は、管理サーバ１１と同じサーバ内に構築されても良い。

社内アプリストア１２は、CPU３０と、メインメモリ３１と、NIC３２と、バス３３と、補助記憶装置であるストレージ３４、３５を有する。ストレージ３４内には、アプリストアのウエブサービスを提供するためのストアWEBプログラム３４１が記憶され、メインメモリ３１に展開されてCPU３０により実行される。さらに、ストレージ３５内に、配信対象のアプリのカタログデータ３５１と、利用申請情報（利用申請された端末に対する配信対象アプリの対応情報）３５２とが記憶される。パソコンからのアプリ利用申請を受け付けると、利用申請情報３５２内に登録され、前述の管理サーバ１１のアプリ配信タスク情報２５３に登録される。

図６は、配信サーバ１３の構成例を示す図である。配信サーバ１３は、CPU４０と、メインメモリ４１と、NIC４２と、バス４３と、ストレージ４４、４５を有する。ストレージ４４内には、アプリの配信を制御する配信プログラム４４１と、管理サーバからのアプリのダウンロードとメインメモリ内のアプリの保持と削除の制御を行うアプリ管理プログラム４４２とが記憶され、これらのプログラムはメインメモリ内に展開されCPUにより実行される。ストレージ４５内には、管理サーバ１１から通知されるアプリ配信タスク情報４５１と、端末の認証情報４５２とが記憶される。端末の認証情報は、配信サーバが端末からマニフェストファイルやアプリの配信要求を受信したときの認証に利用される。

また、配信サーバ１３のメインメモリ（または内部メモリ）４１内には、管理サーバからダウンロードした配信対象のアプリのデータ２５２と、そのマニフェストファイル２５１とが記憶される。配信サーバ１３は、内部メモリ４１内に記憶されたマニフェストファイルとアプリのデータを、配信要求を送信してきた端末にダウンロードする。

上記の配信プログラム４４１とアプリ管理プログラム４４２が、第１の実施の形態におけるデータ配信プログラムに対応する。

図７は、端末の構成例を示す図である。端末１４、１６は、CPU５０と、メインメモリ５１と、無線通信回路５２と、入出力装置（タッチパネル、表示装置）５６と、バス５３と、ストレージ５４、５５を有する。

ストレージ５４内には、オペレーションシステム（OS）５４１と、PNSサーバにアクセスするためのPNSサーバアプリ５４２と、管理サーバに端末を登録するための社内管理アプリ５４３とが記憶される。OSとPNSサーバアプリと社内管理アプリは、メインメモリ内に展開されCPUにより実行される。また、ストレージ５５内には、ダウンロードしたアプリのアーカイブ５５１と、配信サーバ１３から取得した配信サーバへのアクセス時に使用する認証情報５５２とが記憶される。アプリアーカイブ内のアプリもメインメモリに展開されCPUにより実行される。

図８は、パソコン１５、１７の構成例を示す図である。パソコンは企業から利用者に支給されるパーソナルコンピュータであり、主に業務に使用される。パソコンは、CPU６０と、メインメモリ６１と、NIC６２と、入出力装置（キーボード、マウス、表示装置など）６６と、バス６３と、ストレージ６４、６５を有する。ストレージ６４内には、業務で使用される業務プログラム６４１と、社内アプリストアにアクセスするための社内アプリストアアプリ６４２と、管理サーバに登録する為の社内管理アプリ６４３とが記憶される。また、ストレージ６５内には、業務データベース６５１と、社内アプリストアにアクセスするときの認証情報６５２とが記憶される。

図９、図１０、図１１は、第１の実施の形態におけるアプリ配信処理のシーケンス図である。図中、従来のシーケンスの図２、図３と同じ処理には同じ処理番号を付している。したがって、図２、図３にない処理番号は、第１の実施の形態で実行される処理である。以下の説明では、図２、図３の処理の説明も重複して行う。また、第１の実施の形態に特有の処理については、その都度説明する。

図９に示すとおり、まず、事前に、管理サーバ１１は、端末１４、１６とパソコン１５、１７からアドレスや端末IDなどのインベントリ情報を収集する（S1）。また、管理サーバ１１には、配信するアプリのデータとそのマニフェストファイルが格納されている。さらに、図示しないが、端末１４、１６は、予め配信サーバ１３にアクセスして、端末の登録を行い、それぞれの端末の認証情報を取得している。

第１の実施の形態では、管理サーバ１１が、常時、パソコン１５、１７の操作ログを収集し操作ログDBに格納する。収集される操作ログの種類は、予め指定されていて、少なくともアプリの利用申請と、業務で良く行われるブラウザやエディタまたはワープロやメーラーの起動、ファイルの更新などである。さらに、管理サーバ１１は、過去のパソコンによるアプリ利用申請時刻T0_1に加えて、端末によるアプリ配信要求時刻T1_1の履歴も、ユーザ毎（端末とパソコン毎）に収集しておく。端末によるアプリ配信要求時刻T1_1は、配信サーバがアプリ配信要求を受信した時刻から取得可能である。

図１６は、パソコンの操作ログの例とアプリ配信実績の例を示す図である。図１６のPC操作ログには、ユーザ１のPC１における操作のログ（操作内容と操作時刻）の一例が示されている。

図９に戻り、配信サーバ１３は、管理サーバ１１に定期的にアクセスして、配信するアプリの有無を確認する（S7）。これに応答して、管理サーバ１１は、配信サーバ１３に、端末１４、１６に対して配信するアプリがあることを返信する（S8）。これにより、配信サーバ内のアプリ配信タスク４５１（図６参照）に端末１４、１６にアプリAを配信するタスクが登録される。

その後、配信サーバ１３は、端末１４、１６に対してアプリ配信の通知をするために、PNSサーバ１０に端末１４、１６にアプリ配信通知を依頼し、端末１４、１６へのプッシュ通知を登録する(S9)。

ここで、第１の実施の形態では、配信サーバ１３が管理サーバ内のパソコン１５の操作ログ等を参照して、過去の操作ログからパソコン１５によるアプリ利用申請時刻T0_1と端末１４によるアプリ配信要求時刻T1_1を取得し、利用申請時刻T0_1からアプリ配信要求時刻T1_1までの時間t１を過去の配信実績として算出する（S10）。さらに、配信サーバ１３は、操作ログを参照して、今回の操作ログからパソコン１５による今回のアプリ利用申請時刻T0_2を取得し、その時刻T0_2に前述の過去の時間t1を加算して、今回のアプリ配信要求時刻T1_2を予測する（S10）。そして、現在時刻Tpと予測アプリ配信要求時刻T1_2との時間差（Tp-T1_2）を、現在時刻から端末１４によるアプリ配信要求時刻までの予測時間requestTimeとして算出する。

また、配信サーバは、現在のネットワークNET1の状況（例えば通信速度）とアプリAの容量に基づいて、管理サーバから配信サーバへのアプリAのダウンロードに要するダウンロード予測時間downloadTimeを算出する（S11）。そして、配信サーバは、配信要求予測時間requestTimeとダウンロード予測時間downloadTimeとを比較し、管理サーバにアプリAのダウンロードを要求すべきか否かを判定する。図９の例ではこの時点でrequestTime>downloadTime故、まだ管理サーバにダウンロード要求を行わない。

そして、管理サーバ１１は、パソコン１５、１７の操作ログの収集を継続する(S12)。また、配信サーバは、現在時刻の経過に伴い前述の現在時刻Tpと予測アプリ配信要求時刻T1_2との時間差（Tp-T1_2）である配信要求予測時間requestTimeを更新し、ダウンロード予測時間downloadTimeと比較し、管理サーバにアプリAのダウンロード要求を送信すべきか否かの判定を繰り返す。そして、判定結果がrequestTime≦downloadTimeになると、配信サーバは管理サーバにアプリA（とそのマニフェストファイル）のダウンロードを要求する（S14,図１０参照）。これにより、配信サーバは、アプリ配信要求を端末１４から受信した時点で、内部メモリ内にアプリA（とマニフェストファイル）を格納済み状態にできるので、アプリ配信要求から即刻アプリAを端末１４にダウンロードすることができ、迅速なアプリ配信を実現できる。なお、マニフェストファイルのデータ容量は微小であるので、配信サーバはアプリ配信タスク情報を受信した時（S8）にマニフェストファイルだけ先に管理サーバからダウンロードしてもよい。

図９において、配信サーバ１３は、管理サーバ内のパソコン１５の操作ログを参照して、工程S10で予測した端末１４によるアプリ配信要求時刻T1_2の修正を行ってもよい（S13）。簡単に説明すると、たとえばパソコン１５の操作が完了した時点で端末によるアプリ配信要求が行われる蓋然性が高くなるので、操作完了を検出した場合アプリ配信要求時刻T1_2を修正し、配信要求予測時間requestTimeを0または所定の短い時間に修正する。この修正方法については、第２の実施の形態で説明する。

図１０に移り、配信サーバ１３は、前述したとおり、適切なタイミング（requestTime≦downloadTimeのとき）で管理サーバ１１からアプリAをダウンロードする（S14）。そして、端末１４が、PNSサーバ１０にアクセスしアプリ配信通知有無の確認を行う（S15）。端末１４はこのような確認を定期的に実行する。これに応答して、PSNサーバ１０は、端末１４に対するアプリAの配信タスクの登録があることを端末１４に通知する（S16）。これが、PNSサーバ１０から端末１４へのプッシュ通信である。

そこで、端末１４は、プッシュ通信に応答して、配信サーバ１３にアクセスし、配信アプリのマニフェストファイルの配信を要求する（S17）。このマニフェスト配信要求は、マニフェストを受信するとOSが自動的に実行する。

第１の実施の形態では、既にマニフェストファイルをダウンロードしてメインメモリ内に格納済みであるので、配信サーバ１３は、マニフェストファイル配信要求に応答して、即座に端末１４にマニフェストファイルをダウンロードする(S17)。

そこで、端末１４のディスプレイに表示された承認画面で利用者がダウンロードを承認する操作を行うと（S18）、端末１４は配信サーバ１３にアクセスしてアプリAの配信要求を行う（S19）。このアプリの配信要求も承認操作に応答してOSが自動的に実行する。第１の実施の形態では、既にアプリAをダウンロードしてメインメモリ内に格納済みであるので、配信サーバ１３は、このアプリ配信要求に応答して、即座に端末１４にアプリAのデータをダウンロードする(S19)。そして、端末１４はダウンロードしたアプリAをインストールする（S20）。

第１の実施の形態では、配信サーバが、アプリAを端末１４にダウンロード完了した時点で、次の端末１６からアプリAの配信要求が来るまでの時間requestTimeを予測する（S21）。端末１６によるアプリ配信要求予測時間requestTimeの算出方法は、前述の端末１４によるアプリ配信要求予測時間の算出方法と同じである。さらに、配信サーバは、現在のネットワークの状況とアプリAのデータ容量に基づいてダウンロード予測時間downloadTimeを算出する（S22）。そして、配信サーバは、端末１６によるアプリ配信要求予測時間requestTimeとダウンロード予測時間downloadTimeとを比較し、メインメモリ内に格納済みのアプリAを保持するか削除するかの判定を行う。配信サーバは、判定結果がrequestTime≦downloadTimeであれば、アプリA（及びマニフェスト）をメインメモリ内に保持し、判定結果がrequestTime＞downloadTimeであれば、アプリA（及びマニフェスト）をメインメモリから削除する（S22）。図１０の例では、配信サーバはアプリA（及びマニフェスト）をメモリ内に保持している。なお、マニフェストはデータ容量が小さいのでメインメモリに保持するようにしてもよい。

配信サーバは、アプリAをメインメモリから削除した場合は、端末１４へのアプリAの配信時と同様に、時間の経過に伴い、アプリ配信要求予測時間requestTimeを更新し、requestTime≦downloadTimeになるタイミングで管理サーバから再度アプリAをダウンロードする。

図１１に移り、端末１６が、PNSサーバ１０にアクセスしアプリ配信通知有無の確認を行う（S23）。これに応答して、PSNサーバ１０は、端末１６に対するアプリAの配信タスクの登録があることを端末１６に返信する（S24）。

そこで、PSNサーバからのプッシュ通知に応答して、端末１６が配信サーバ１３にマニフェストファイルの配信要求を送信する（S25）。第１の実施の形態では、端末１４へのアプリAのダウンロード完了時にアプリAとマニフェストをメインメモリ内に保持しているので、配信サーバ１３は、配信要求に応答して即刻、マニフェストを端末１６にダウンロードする（S25）。

そこで、端末１６の利用者が承認画面で承認操作を行うと（S26）、端末１６が配信サーバ１３にアプリAの配信要求を送信する（S27）。第１の実施の形態では、アプリAは配信サーバのメインメモリに保持されているので、配信サーバ１３は、配信要求に応答して即刻、アプリAを端末１６にダウンロードする（S27）。そして、端末１６はダウンロードしたアプリAをインストールする（S28）。また、配信サーバ１３は、ダウンロード完了後に、そのアプリAをメモリから削除する（S29）。以上で、アプリAの複数の端末１４、１５への一斉配信が完了する。

次に、第１の実施の形態における配信サーバのアプリ配信処理について詳述する。図１２は、配信サーバによるアプリ配信処理の概略を示すフローチャート図である。配信サーバ１３は、管理サーバからある端末に対して配信するアプリがあることを通知されることで、端末に配信するアプリがある状態になると（S40のYES）、その端末とアプリの情報をPNSサーバ１０に通知し、PNSサーバにプッシュ通知を登録する（S41、図９のS9）。配信サーバは、アプリ配信のPNSサーバへの登録（S41）を、アプリが配信状態になった時に一回だけ行う。これで、配信サーバはアプリ配信を開始する。

そこで、配信サーバ１３は、アプリ管理プログラム４４２（図６参照）を実行して、配信するアプリの管理サーバからのダウンロード処理と、ダウンロード済みアプリのメインメモリ内に保持するか削除するかの処理を行う（S42）。やがて、端末からアプリ配信要求を受信すると（S43）、端末にアプリをダウンロードする（S44）。処理S43,S44では、前述のマニフェストファイルの配信要求とダウンロードについての説明を省略している。

図１３は、配信サーバによるアプリ管理処理の詳細を示すフローチャート図である。図１２で示したとおり、アプリ管理処理S42は配信サーバの処理に含まれる処理であり、配信サーバはアプリ管理プログラム４４２によりアプリ管理処理を実行する。

アプリ管理処理では、配信サーバは、管理サーバからパソコン１５，１７の操作ログを取得する（S51）。これにより、配信サーバは、新たなアプリ利用申請が行われたことを検出する（S52）。図９の例では、パソコン１５，１７でアプリAについてアプリ利用申請が行われている（図９のS2,S3）。

このように新たなアプリ利用申請が行われていた場合（S52のYES）、配信サーバは、過去の各端末へのアプリ配信実績内の、アプリ利用申請時刻T0_1からアプリ利用時刻T1_1までの間の時間t1＝T0_1-T1_1を算出（複数実績ならその平均値を算出）する。さらに、配信サーバは、今回の操作ログから抽出した今回のアプリ利用申請時刻T0_2と、算出した過去の時間t1とから、今回のアプリ配信要求時刻T1_2（＝T0_2＋t1）を予測する（S53）。この処理は、新たにアプリ利用申請が行われたアプリ配信タスクについてのみ実行される。

次に、配信サーバは、現在のネットワークの状況とアプリのデータ容量などに基づいて、アプリを管理サーバからダウンロードするのに要する時間（予測ダウンロード時間DL_T）を予測する（S54）。この予測ダウンロード時間は、具体的には管理サーバからダウンロードし配信サーバの内部メモリに格納するまでの時間である。この処理において、予測した今回のアプリ配信要求時刻T1_2をパソコンの操作ログに基づいて修正してもよい。この修正については第２の実施の形態で説明する。

次の処理は、アプリ利用申請が１つのみの場合はその端末のユーザについて処理され、アプリ利用申請が複数ある場合は予測アプリ配信要求時刻T1_2までの時間が最短の端末のユーザについて処理される。

また、次の処理は、直前にアプリ配信が完了したか否か（S55）によって、処理が異なる。即ち、直前にアプリ配信が完了していない場合（S55のNO）、現在時刻Tpから予測アプリ配信要求時刻T1_2までの時間t1_2＝Tp-T1_2が予測ダウンロード時間DL_Tより長い場合（S56のYES）、アプリのダウンロードは実行しない。一方、時間t1_2＝Tp-T1_2が予測ダウンロード時間DL_T以下の場合（S56のNO）は、アプリを内部メモリに保持していなければ（S57のNO）、管理サーバからアプリをダウンロードする（S58）。

つまり、最初のアプリ利用申請のユーザに対しては、配信予定のアプリは未だ配信サーバの内部メモリ内に保持されていないので、時間の経過に伴いTp-T1_2≦DL_Tのタイミングでアプリを管理サーバからダウンロードする。２番目以降のアプリ利用申請のユーザに対しては、直前のアプリ利用申請においてダウンロードして内部メモリに格納したアプリがそのまま保持されていれば、もはやダウンロードする必要はない。しかし、保持されていなければ、時間の経過に伴いTp-T1_2≦DL_Tのタイミングでアプリを管理サーバからダウンロードする。

一方、直前にアプリ配信が完了している場合（S55のYES）、つまり、アプリ配信が完了した直後のタイミングでは、まず、管理対象のユーザを予測アプリ配信要求時刻T1_2までの時間が最短のユーザに更新する。そして、配信サーバは、時間t1_2＝Tp-T1_2が予測ダウンロード時間DL_Tより長い場合（S60のYES）、内部メモリ内のアプリを削除する。一方、時間t1_2＝Tp-T1_2が予測ダウンロード時間DL_T以下の場合（S56のNO）は、アプリを内部メモリに保持する（S62）。そして、このユーザに対しては、その後時間が経過して次回からは工程S55はNOとなり、工程S56-S58が実行される。

すなわち、配信サーバは、あるアプリの端末へのダウンロードが完了するタイミングで、次の予測アプリ配信要求時刻T1_2までの時間Tp-T1_2が予測ダウンロード時間DL_Tより長ければメモリ内のアプリを削除し、以下であればメモリ内にアプリを保持する。また、初回のアプリ利用申請と、２回目以降のアプリ利用申請のユーザでアプリが内部メモリに保持されていないものに対しては、配信サーバは、時間の経過に伴いTp-T1_2≦DL_Tになるタイミングでアプリを管理サーバからダウンロードする。

以上のように、第１の実施の形態のアプリ管理処理では、アプリの端末への配信前で且つアプリが配信サーバ内のメモリに格納されていない場合、配信サーバは、ユーザの端末からアプリ配信要求が送信されてくる前の最適なタイミングで管理サーバからアプリをダウンロードして内部メモリに格納する。そして、アプリの配信が完了したタイミングで、次の同じアプリの配信のために、配信サーバは、次のアプリ配信要求が送信されてくるまでの時間が管理サーバからアプリをダウンロードしてメモリ内の格納するまでに要する時間以下の場合は、メモリ内のアプリを保持し続ける。逆に、配信サーバは、次のアプリ配信要求が送信されてくるまでの時間が管理サーバからアプリをダウンロードしてメモリ内の格納するまでに要する時間より長い場合は、メモリ内のアプリを削除し、アプリによる無駄なメモリの占有を抑制する。

図１４は、端末の動作例を示すフローチャート図である。端末は、PNSサーバにアクセスしてアプリ配信通知有無（アプリ配信タスクの登録有無）の確認を行う（S71、図１０のS15）。PNSサーバからアプリ配信通知有りの返信があると（S72のYES）、端末は、配信サーバにマニフェストファイルの配信要求を送信する（S73、図１０のS17）。PNSサーバからアプリ配信通知有りの返信があると、端末のOSが自動的に配信サーバにマニフェストファイルの配信要求を送信する。つまり、PNSサーバからのアプリ配信通知有りの返信には、ダウンロード先の配信サーバのアドレスが含まれている。また、配信サーバへのマニフェストファイルの配信要求には、予め端末が配信サーバから取得した認証情報が添付される。

端末は、配信サーバからダウンロードされたマニフェストファイルを実行して、アプリのインストール可否の確認画面を表示する（S74、図１０のS18）。そこで、端末のユーザが画面上でインストール可の操作を行うと（S75のYES）、端末は、配信サーバへアプリ配信要求を送信する（S76、図１０のS19）。このアプリ配信要求には前述の認証情報が添付される。そして、端末は、ダウンロードしたアプリをインストールする（S77、図１０のS20）。

このように、端末は、個人所有であり、端末へのアプリを管理するPNSサーバにより許可されたアプリについて、PNSサーバとの間でアプリ配信通知有無の確認処理を経由して、PNSサーバが許可する配信サーバにマニフェストファイルの配信要求及びアプリの配信要求を行う。

図１５は、第１の実施の形態におけるパソコンの操作ログとアプリ配信実績の一例を示す図である。管理サーバは、パソコンの操作ログの修正について、収集すべきパソコンの操作ログの種類を予め指定しておき、指定された操作が行われると、その操作が行われたパソコンのIDと、そのユーザIDと、操作内容と、操作時刻とを収集する。図１５の例では、３月１０日のユーザUser_1によるパソコンPC1でのアプリ利用申請などの操作ログと、３月２２日の同じユーザによるアプリ利用申請などの操作ログとが含まれる。前者のアプリ利用申請の時刻は過去のアプリ配信実績に含まれるアプリ利用申請時刻T0_1に対応する。また、後者のアプリ利用申請の時刻は今回のアプリ利用申請時刻T0_2に対応する。

管理サーバは、アプリの配信実績を収集する。図１５の例では、ユーザUser_1による第１のオペレーションシステムOSAの端末と、第２のオペレーションシステムOSBの端末のアプリ配信要求時刻の履歴が含まれている。本実施の形態は、PNSサーバからのプッシュ通知に応答してマニフェストファイルをダウンロードしユーザによるインストール許可を要求する第１のオペレーションシステムOSAの端末について適用される。

［第２の実施の形態］
第２の実施の形態では、図１３の工程S54で予測アプリ配信要求時刻T1_2をユーザのパソコン操作に基づいて修正する。第１の実施の形態では、ユーザの過去のアプリ配信実績に基づいてパソコンからのアプリ利用申請時刻T0_1から端末によるアプリ配信要求時刻T1_1までの時間t1の平均値を求めた。これは、ユーザが従事する業務内容と、ユーザがパソコンを操作してアプリ利用申請後、そのパソコンの操作を一旦終了して端末でアプリ配信要求するまでの時間とが一定の相関関係を有することに基づくものであり、過去のアプリ配信実績を元に時間t1を算出し、それに基づいて今回の端末でのアプリ配信要求時刻T1_2を予測した。つまり、ユーザの業務が主にパソコン操作を伴う業務か、パソコン操作を伴わない業務かに応じて、時間t1が異なることに基づく。

しかしながら、ユーザが過去の実績よりも今回のパソコン操作が長くなる場合や短くなる場合は、上記の予測アプリ配信要求時刻T1_2が変動する。

そこで、第２の実施の形態では、配信サーバが、管理サーバが収集する利用者毎のパソコンの操作ログを利用して、今回のパソコンの操作が完了するタイミングを検出し、その検出したタイミングから所定時間後またはほぼ直後に端末でアプリ配信要求の操作が行われると見なして、予測したアプリ配信要求時刻T1_2を修正する。

図１４は、予測アプリ配信要求時刻T1_2の修正処理の一例について説明する図である。

（１）実績t1は、過去のアプリ配信実績から算出したユーザのアプリ利用申請から配信要求までに要する時間t1を示す。ユーザは、パソコンを操作してアプリ利用申請を行い（時刻T0_1）、その後パソコンの操作を継続した後操作を完了し（操作時間t2）、操作完了から所定時間t3後に端末からアプリ配信要求を行う（時刻T1_1）。所定時間t3は短い時間またはほとんどゼロ時間である。

（２）修正t1_cは、ユーザが過去の実績のパソコン操作時間t2が短くなった例である。第２の実施の形態では、管理サーバが収集するユーザによるパソコンの操作ログを監視し、パソコン操作が完了したタイミングを検出する。

具体的には、ユーザの過去の操作ログからパソコンの操作のインターバル時間（操作していない時間）dt_pcの平均値を算出し、今回の操作ログから操作していない時間が過去のインターバル時間dt_pcを越えた時点で操作が完了すると見なす。つまり、図中、dt_end＞dt_pcを検出したとき操作が完了すると見なし、今回の操作完了までの時間t2に基づいて、予測アプリ配信要求時刻T1_2を修正する。

逆に、実績の時間t1に基づいて予測したアプリ配信要求時刻T1_2が近づいてもdt_end＞dt_pcを検出できない場合、検出できるまで予測アプリ配信要求時刻T1_2の修正を繰り返す。

第２の実施の形態では、予測アプリ配信要求時刻T1_2を修正することで、より高精度にアプリ配信要求時刻T1_2を求めることができる。それにより、配信サーバは、アプリ配信が完了したタイミングでメモリ内のアプリを保持するか削除するかの判断の精度を高めることができる。また、配信サーバは、事前にアプリをダウンロードするタイミングの判断の精度を高めることができる。

１０：PNSサーバ
１１：管理サーバ
１２：社内アプリストア
１３：配信サーバ
１４，１６：端末
１５，１７：パソコン
NET1：イントラネット
NET2：インターネット

Claims

端末装置に対するアプリケーションの導入または更新に用いられるデータの配信を行うデータ配信装置に、
前記データの格納元から取得され前記配信装置の記憶部に記憶された前記データが第１の端末装置に配信された場合、第２の端末装置の利用者の前記第２の端末装置と異なる第２の他の端末装置のログ情報と、データの前記第２の端末装置への配信実績情報とに基づいて、前記第２の他の端末装置にて前記データの利用申請が実行されたタイミング後に、前記配信装置が前記第２の端末装置から配信要求を受け付けるタイミングの第１の時刻を特定し、
前記データの格納元から前記配信装置の記憶部への前記データのダウンロードに要する時間が、前記特定した第１の時刻までの時間より長い場合は、前記記憶部に記憶された前記データを保持し、前記ダウンロードに要する時間が前記特定した第１の時刻までの時間より短い場合は、前記記憶部に記憶された前記データを消去する、
処理を実行させるデータ配信制御プログラム。
さらに、
前記第１の端末装置の利用者の前記第１の端末装置と異なる第１の他の端末装置のログ情報と、データの前記第１の端末装置への配信実績情報とに基づいて、前記第１の他の端末装置にて前記データの利用申請が実行されたタイミング後に、前記配信装置が前記第１の端末装置から配信要求を受け付けるタイミングの第２の時刻を特定し、前記ダウンロードに要する時間が、前記特定した第２の時刻までの時間以下になるタイミングで、前記格納元から前記データを前記記憶部にダウンロードする、
処理を実行させる請求項１に記載のデータ配信制御プログラム。
前記第１の時刻を特定する処理は、前記第２の他の端末装置のログ情報に含まれる前記第２の他の端末装置にて前記データの利用申請が実行された時刻と、前記第２の端末装置への配信実績情報に含まれる前記利用申請から配信要求までの時間とに基づいて、前記第１の時刻を特定する処理を有する、
請求項１に記載のデータ配信制御プログラム。
前記第１の時刻を特定する処理は、前記第２の他の端末装置のログ情報に含まれる前記第２の他の端末装置での無操作時間に基づいて前記第２の他の端末装置での操作が完了したと見なす処理と、前記特定された第１の時刻を前記利用申請の操作から操作完了までの時間に基づいて修正する処理とを有する、
請求項３に記載のデータ配信制御プログラム。
前記修正する処理は、前記第２の他の端末装置での操作が完了したとみなした時点で、前記特定された第１の時刻を所定の時間またはゼロに変更する、
請求項４に記載のデータ配信制御プログラム。
端末装置に対するアプリケーションの導入または更新に用いられるデータの配信を行うデータ配信装置が、
前記データの格納元から取得され前記配信装置の記憶部に記憶された前記データが第１の端末装置に配信された場合、第２の端末装置の利用者の前記第２の端末装置と異なる第２の他の端末装置のログ情報と、データの前記第２の端末装置への配信実績情報とに基づいて、前記第２の他の端末装置にて前記データの利用申請が実行されたタイミング後に、前記配信装置が前記第２の端末装置から配信要求を受け付けるタイミングの第１の時刻を特定し、
前記データの格納元から前記配信装置の記憶部への前記データのダウンロードに要する時間が、前記特定した第１の時刻までの時間より長い場合は、前記記憶部に記憶された前記データを保持し、前記ダウンロードに要する時間が前記特定した第１の時刻までの時間より短い場合は、前記記憶部に記憶された前記データを消去する、
処理を有するデータ配信制御方法。
端末装置に対するアプリケーションの導入または更新に用いられるデータの配信を行うデータ配信装置であって、
前記データの格納元から取得され前記配信装置の記憶部に記憶された前記データが第１の端末装置に配信された場合、第２の端末装置の利用者の前記第２の端末装置と異なる第２の他の端末装置のログ情報と、データの前記第２の端末装置への配信実績情報とに基づいて、前記第２の他の端末装置にて前記データの利用申請が実行されたタイミング後に、前記配信装置が前記第２の端末装置から配信要求を受け付けるタイミングの第１の時刻を特定する第１の時刻特定部と、
前記データの格納元から前記配信装置の記憶部への前記データのダウンロードに要する時間が、前記特定した第１の時刻までの時間より長い場合は、前記記憶部に記憶された前記データを保持し、前記ダウンロードに要する時間が前記特定した第１の時刻までの時間より短い場合は、前記記憶部に記憶された前記データを消去するデータ管理部、
とを有するデータ配信装置。