(57)【要約】【課題】基地局に接続する他の通信装置に影響を与えずに、更新対象である通信装置にソフトウェアを配信する。【解決手段】配信装置３は、通信装置１から、通信装置１を識別するための装置識別情報と、無線通信網の複数の基地局２のうち通信装置１が接続している基地局２を識別するための基地局識別情報とを取得する情報取得部３３１と、装置識別情報及び基地局識別情報に基づいて、基地局２ごとに、基地局２に接続している複数の通信装置１にソフトウェアを配信する順序を決定する決定部３３２と、決定部３３２が決定した順序に基づいて、通信装置１に対してソフトウェアを配信する配信部３３３と、を有する。【選択図】図２
2020022201.tif 000002
【特許請求の範囲】
【請求項１】
通信装置から、前記通信装置を識別するための装置識別情報と、無線通信網の複数の基地局のうち前記通信装置が接続している基地局を識別するための基地局識別情報とを取得する情報取得部と、
前記装置識別情報及び前記基地局識別情報に基づいて、前記基地局ごとに、前記基地局に接続している複数の前記通信装置にソフトウェアを配信する順序を決定する決定部と、
前記決定部が決定した前記順序に基づいて、前記通信装置に対してソフトウェアを配信する配信部と、
を有する配信装置。
【請求項２】
前記配信部は、前記順序に基づいて、前記複数の通信装置の中から閾値台数以下の台数の前記通信装置を選択し、選択した前記通信装置に対して前記ソフトウェアを配信する、
請求項１に記載の配信装置。
【請求項３】
前記配信部は、前記基地局の種別に基づいて前記閾値台数を決定する、
請求項２に記載の配信装置。
【請求項４】
前記配信部は、前記ソフトウェアのサイズに基づいて前記閾値台数を決定する、
請求項２又は３に記載の配信装置。
【請求項５】
コンピュータが実行する、
通信装置から、前記通信装置を識別するための装置識別情報と、無線通信網の複数の基地局のうち前記通信装置が接続している基地局を識別するための基地局識別情報とを取得するステップと、
前記装置識別情報及び前記基地局識別情報に基づいて、前記基地局ごとに、前記基地局に接続している複数の前記通信装置にソフトウェアを配信する順序を決定するステップと、
決定した前記順序に基づいて、前記通信装置に対してソフトウェアを配信するステップと、
を有する配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置にソフトウェアを配信するための配信装置及び配信方法に関する。
【背景技術】
【０００２】
複数の通信装置それぞれにソフトウェアを配信する装置が知られている。特許文献１には、配信装置が複数の通信装置にソフトウェアをブロードキャスト送信する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−１９９９５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
近年、ＩｏＴ（Internet of Things）の普及により、ネットワークを介して外部にあるサーバとデータを送受信するＩｏＴ機器が急速に増加している。ＩｏＴ機器においては、通信にかかる電力消費量を低く抑えることが要求されるため、パソコンやスマートフォン等に搭載されている通信デバイスに比べて低い通信速度で小容量のデータを送信可能な無線通信回線が使用されている。
【０００５】
ところで、ＩｏＴ機器が実行するソフトウェアに不具合が見つかった場合、製品の製造者又は通信業者から不具合を解消するために更新用ソフトウェアが提供される。例えば、ＦＯＴＡ（Firmware Over the Air）という技術を用いることで、人の手を介さずに自動でＩｏＴ機器のソフトウェアを更新させることができる。また、従来の技術を用いることで、複数のＩｏＴ機器に更新用ソフトウェアを配信することができる。しかし、更新用ソフトウェアは、ＩｏＴ機器が通常の動作としてサーバに送受信するデータ量よりもデータサイズが大きいため、更新用ソフトウェアを配信するのに時間がかかる。この場合において、大量のＩｏＴ機器に更新用ソフトウェアをブロードキャスト送信すると、基地局の通信帯域が逼迫し、他のＩｏＴ機器や通信装置に影響を及ぼす可能性がある。
【０００６】
そこで、本発明はこれらの点に鑑みてなされたものであり、基地局に接続する他の通信装置に影響を与えずに、更新対象である通信装置にソフトウェアを更新させることを目的とする。
【課題を解決するための手段】
【０００７】
本発明の第１態様に係る配信装置は、通信装置から、前記通信装置を識別するための装置識別情報と、無線通信網の複数の基地局のうち前記通信装置が接続している基地局を識別するための基地局識別情報とを取得する情報取得部と、前記装置識別情報及び前記基地局識別情報に基づいて、前記基地局ごとに、前記基地局に接続している複数の前記通信装置にソフトウェアを配信する順序を決定する決定部と、前記決定部が決定した前記順序に基づいて、前記通信装置に対してソフトウェアを配信する配信部と、を有する。
【０００８】
前記配信部は、前記順序に基づいて、前記複数の通信装置の中から閾値台数以下の台数の前記通信装置を選択し、選択した前記通信装置に対して前記ソフトウェアを配信してもよい。
【０００９】
前記配信部は、前記基地局の種別に基づいて前記閾値台数を決定してもよい。
【００１０】
前記配信部は、前記ソフトウェアのサイズに基づいて前記閾値台数を決定してもよい。
【００１１】
【００１２】
【００１３】
【００１４】
【００１５】
【００１６】
【００１７】
本発明の第２態様に係る配信方法は、コンピュータが実行する、通信装置から、前記通信装置を識別するための装置識別情報と、無線通信網の複数の基地局のうち前記通信装置が接続している基地局を識別するための基地局識別情報とを取得するステップと、前記装置識別情報及び前記基地局識別情報に基づいて、前記基地局ごとに、前記基地局に接続している複数の前記通信装置にソフトウェアを配信する順序を決定するステップと、決定した前記順序に基づいて、前記通信装置に対してソフトウェアを配信するステップと、を有する。
【発明の効果】
【００１８】
本発明によれば、基地局に接続する他の通信装置に影響を与えずに、更新対象である通信装置にソフトウェアを更新させることができるという効果を奏する。
【図面の簡単な説明】
【００１９】
【図１】第１実施形態に係るソフトウェアの配信方法の概要を説明するための図である。
【図２】第１実施形態に係る配信装置の構成を示す図である。
【図３】第１実施形態に係る配信状況ＤＢの構成を示す図である。
【図４】第１実施形態に係る配信待ちＤＢの構成を示す図である。
【図５】第１実施形態に係る配信装置が行う処理の流れを示すフローチャートである。
【図６】第１実施形態に係る配信処理の流れを説明するための図である。
【図７】第１実施形態に係る配信処理の流れを説明するための図である。
【図８】第２実施形態に係る配信待ちＤＢの構成を示す図である。
【図９】第２実施形態に係る配信順序を決定する処理の流れを説明するための図である。
【図１０】第２実施形態に係る配信装置が行う配信状況ＤＢ更新処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００２０】
＜第１実施形態＞
［ソフトウェアの配信方法の概要］
図１は、第１実施形態に係るソフトウェアの配信方法の概要を説明するための図である。図１に示す配信装置３は、基地局２を介して通信装置１とデータを送受信する。
【００２１】
通信装置１は、ネットワークを介して、サーバ又は他の通信装置１に対してデータを送受信する機器であり、例えば、ＩｏＴ機器又は人の手を介さずに複数の機器が相互に通信する機器間通信であるＭ２Ｍ（Machine to Machine）に対応した機器である。通信装置１は、例えば、通信モジュールを組み込んだ電力使用量を計測するスマートメータ、又はインターネットを介して操作することができる家電製品等である。本実施形態において通信装置１は、設置した場所から移動しない装置であるとして説明する。
【００２２】
基地局２は、無線通信網において、通信装置１と配信装置３との通信を中継する役割を有する。無線通信網は、例えば、携帯電話網、又はＩｏＴ機器の通信で利用されるＬＰＷＡ（Low Power Wide Area）であり、具体的にはＮＢ−ＩｏＴ（Narrow Band-IoT）、ＬｏＲａＷＡＮ（登録商標）、ＳＩＧＦＯＸ（登録商標）等である。
【００２３】
配信装置３は、ソフトウェアの配信を制御するＦＯＴＡサーバである。配信装置３は、例えば、ＰＣ（Personal Computer）である。ここで、配信装置３が配信するソフトウェアは、通信装置１にインストールされているソフトウェアを更新する更新用ソフトウェア及び通信装置１に実行させる機能を追加する追加用ソフトウェアを含む。本明細書においては、配信装置３が配信するソフトウェアが更新用ソフトウェアである場合について主に説明する。
【００２４】
配信装置３は、更新用ソフトウェアを提供する提供サーバと、更新用ソフトウェアの配信を制御するＦＯＴＡサーバとで分けてもよい。この場合、ＦＯＴＡサーバは、通信事業者によって設置され、提供サーバは、通信装置１の製造業者ごと又は通信事業者によって設置される。本明細書における配信装置３は、通信事業者が管理するサーバであって、提供サーバ及びＦＯＴＡサーバの機能を備えたサーバであるとして説明する。
【００２５】
図１に示す配信装置３が更新用ソフトウェアを配信する場合において、配信装置３は、予め記憶している配信対象である複数の通信装置１それぞれに応答要求を送信する。通信装置１は、応答要求を受信すると、通信装置１の装置識別情報である通信装置ＩＤと、無線通信網の複数の基地局２のうち通信装置１が属する基地局２の識別情報である基地局ＩＤとを配信装置３に送信する。
【００２６】
ところで、基地局２においては、無線通信回線の種類ごとに同時接続数が設定されている。そのため、更新用ソフトウェアの配信により、基地局２の無線通信回線の１つであるＬＰＷＡの同時接続数が上限に達すると、通常動作として通信を行う通信装置１がＬＰＷＡに接続することができなくなる。そこで、配信装置３は、通信装置１から通信装置ＩＤ及び基地局ＩＤを取得すると、通信装置ＩＤ及び基地局ＩＤに基づいて、基地局２ごとに、通信装置１に更新用ソフトウェアを配信する順序を決定し、閾値台数以下の台数の通信装置１に対して基地局２から更新用ソフトウェアを配信する。
【００２７】
ここで、１つの基地局２から更新用ソフトウェアを配信できる閾値台数が「５台」であり、順序が通信装置１のＩＤの昇順であるとする。更新用ソフトウェアを配信できる閾値台数は、基地局２がＬＰＷＡを用いて同時に更新用ソフトウェアを配信可能な台数である。ＬＰＤＷにおいては、限られた無線帯域を多数の機器が共有して使用するために、データを伝送する間だけ基地局２と通信装置１との間で無線接続される。閾値台数は、更新用ソフトウェアを配信するために基地局２が使用可能な無線チャネルの数に等しい。
【００２８】
閾値台数が５台の場合、図１に示す配信装置３は、基地局ＩＤ「１００１」に対応する基地局２に属する通信装置１のうち、例えば、まず通信装置ＩＤ「０００１」から「０００７」に対応する５台の通信装置１に対して、基地局２から同時に更新用ソフトウェアの配信を開始するか、またはその順序に従って配信開始時刻を変えて配信する。通信装置１は、更新用ソフトウェアの受信が完了すると、受信が完了したことを示す結果情報を配信装置３に通知する。配信装置３は、更新用ソフトウェアの受信が完了したことを示す結果情報を通信装置１から受信すると、当該通信装置１への更新用ソフトウェアの配信が完了したと判定する。
【００２９】
配信装置３は、通信装置１から更新用ソフトウェアの受信が完了したことを示す結果情報を受信すると、まだ更新用ソフトウェアを配信していない通信装置１に更新用ソフトウェアを配信する。配信装置３は、例えば、１台の通信装置１から更新用ソフトウェアの受信が完了したことを示す結果情報を受信した場合、まだ更新用ソフトウェアを配信していない通信装置１のうち、次の優先順位である通信装置ＩＤ「０００８」に対応する通信装置１に対して、基地局２から更新用ソフトウェアを配信する。配信装置３は、基地局ＩＤ「１００１」に対応する基地局２と同様に、基地局ＩＤ「１００２」に対応する基地局２をはじめとする他の基地局２に対して、閾値台数を超えないように更新用ソフトウェアの配信を制御する。
【００３０】
以上のとおり、配信装置３は、基地局２ごとに、更新用ソフトウェアを配信する通信装置１の台数を制御することにより、基地局２に接続する他の通信装置１に影響を与えずに、更新対象である大量の通信装置１にソフトウェアを更新させることができる。
以下、配信装置３の詳細について説明する。
【００３１】
［配信装置３の構成］
図２は、第１実施形態に係る配信装置３の構成を示す図である。配信装置３は、通信部３１、記憶部３２、及び制御部３３を備える。
通信部３１は、基地局２を介して、通信装置１にデータを送受信するための無線通信コントローラを含んでいる。
【００３２】
記憶部３２は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）及びハードディスク等の記憶媒体である。記憶部３２は、制御部３３が実行する各種のプログラムを記憶する。記憶部３２は、更新用ソフトウェアを配信する対象である通信装置１を識別するための通信装置ＩＤの一覧である配信対象一覧及び配信する更新用ソフトウェアを記憶する。また、記憶部３２は、更新用ソフトウェアを配信する通信装置１の通信装置IDを配信状況データベース（以下、配信状況ＤＢ（Database）という）に記憶し、更新用ソフトウェアをまだ配信していない通信装置１の通信装置IDを配信待ちデータベース（以下、配信待ちＤＢという）に記憶する。
【００３３】
図３は、第１実施形態に係る配信状況ＤＢの構成を示す図である。図３に示すように、配信状況ＤＢは、基地局ＩＤと、当該基地局ＩＤに属する通信装置１の通信装置ＩＤと、更新用ソフトウェアの配信状況を示す配信状況とを関連付けて記憶している。配信状況ＤＢにレコードが含まれている通信装置１は、更新用ソフトウェアの配信が可能であること、又は配信中であることを示す。レコードは、図３における基地局ＩＤと、通信装置ＩＤと、配信状況とを組み合わせたデータ、又は後述する図４における通信装置ＩＤと、基地局ＩＤとを組み合わせたデータである。
【００３４】
配信状況には、例えば、「未実行」と、「成功」と、「失敗」とがある。「未実行」は、更新用ソフトウェアの配信が可能であること、又は更新用ソフトウェアが配信中であることを示す。「成功」は、更新用ソフトウェアの配信が完了したこと、すなわち、通信装置１において更新用ソフトウェアの受信が完了したことを示す。「失敗」は、更新用ソフトウェアの配信が完了しなかったこと、すなわち、通信装置１において更新用ソフトウェアの受信が完了しなかったことを示す。配信状況ＤＢにおいては、１つのＤＢに複数の基地局ＩＤを混在させた構成としてもよいし、基地局ＩＤごとにＤＢを設けた構成としてもよい。本実施形態においては、１つの配信状況ＤＢに複数の基地局ＩＤを混在させた構成として説明する。
【００３５】
図４は、第１実施形態に係る配信待ちＤＢの構成を示す図である。図４に示すように、配信待ちＤＢは、通信装置ＩＤと、当該通信装置ＩＤに対応する通信装置１が属する基地局２の基地局ＩＤとを関連付けて記憶している。配信待ちＤＢにレコードが含まれている通信装置１は、更新用ソフトウェアがまだ配信されていないことを示す。初期の配信待ちＤＢにおいては、配信対象一覧に含まれる通信装置ＩＤが格納され、基地局ＩＤが空白となっており、後述する情報取得部３３１が通信装置１から基地局ＩＤを取得することにより、基地局ＩＤが格納される。
【００３６】
図２に戻り、制御部３３は、例えばＣＰＵ（Central Processing Unit）である。制御部３３は、記憶部３２に記憶されているプログラムを実行することにより、配信装置３に係る機能を制御する。制御部３３は、プログラムを実行することにより、情報取得部３３１、決定部３３２、及び配信部３３３として機能する。
【００３７】
情報取得部３３１は、通信部３１を介して、通信装置１との間でデータを送受信する。具体的には、情報取得部３３１は、記憶部３２に格納されている通信装置ＩＤの一覧情報に基づいて、通信部３１を介して通信装置１に応答要求を送信する。また、情報取得部３３１は、通信部３１を介して、通信装置１から、通信装置ＩＤと、無線通信網の複数の基地局２のうち通信装置１が属する基地局２を識別するための基地局ＩＤとを取得する。
【００３８】
情報取得部３３１は、更新用ソフトウェアを配信した通信装置１から受信が完了したか否かを示す結果情報を取得する。情報取得部３３１は、通信装置１から取得した通信装置ＩＤ及び基地局ＩＤ、又は結果情報を決定部３３２に入力する。
【００３９】
決定部３３２は、通信装置ＩＤ及び基地局ＩＤに基づいて、基地局２ごとに、基地局２に属する複数の通信装置１のソフトウェアを配信する順序を決定する。例えば、決定部３３２は、情報取得部３３１から入力された通信装置ＩＤ及び基地局ＩＤに基づいて、基地局２ごとに、更新用ソフトウェアを配信する通信装置１の順序を決定し、決定した順序に基づいて配信待ちＤＢに格納されているレコードの順序を並び替える。ソフトウェアを配信する順序は、通信装置ＩＤに基づく順序でもよいし、通信装置１からデータを取得した日時に基づく順序でもよい。本実施形態においては、通信装置ＩＤの昇順に順序が決定されるとする。
【００４０】
決定部３３２は、情報取得部３３１から入力された結果情報に基づいて、配信状況ＤＢを更新する。具体的には、決定部３３２は、情報取得部３３１から入力された結果情報に基づいて、配信状況ＤＢに格納されているレコードのうち、結果情報に含まれる通信装置ＩＤに対応する配信状況を更新する。決定部３３２は、結果情報が、更新用ソフトウェアの受信が完了したことを示している場合、配信状況を「成功」とし、更新用ソフトウェアの受信が完了していないことを示している場合、配信状況を「失敗」とする。
【００４１】
配信部３３３は、決定部３３２が決定した順序に基づいて、閾値台数以下の台数の通信装置１に対して基地局２から更新用ソフトウェアを配信する。具体的には、配信部３３３は、まず、決定部３３２が決定した順序で格納された配信待ちＤＢから複数の基地局２それぞれにおける閾値台数以下の数のレコードを抽出し、決定部３３２が決定した順序で配信状況ＤＢに格納する。そして、配信部３３３は、記憶部３２に格納されている更新用ソフトウェアを、配信状況ＤＢに格納したレコードの順番に、通信装置１に対して基地局２から配信する。
【００４２】
例えば、１つの基地局２における閾値台数が５台である場合、配信部３３３は、決定部３３２が決定した順序で配信待ちＤＢに格納されているレコードのうち、複数の基地局２それぞれにおける上位５つのレコードを抽出し、配信状況ＤＢに格納する。そして、配信部３３３は、配信状況ＤＢに格納したレコードの順番に、通信装置１に対して、基地局２から更新用ソフトウェアを配信する。
【００４３】
配信部３３３は、更新用ソフトウェアのサイズに基づいて閾値台数を決定してもよい。例えば、１つの基地局２における閾値台数が、更新用ソフトウェアのサイズが１００キロバイトを超える場合は１台減らした４台となり、２００キロバイトを超える場合は２台減らした３台となるように、１００キロバイト単位に閾値台数が少なくなるとする。この場合において、更新用ソフトウェアのサイズが２００キロバイトである場合、配信部３３３は、決定部３３２が決定した順序のうち、複数の基地局２それぞれにおける上位３台の通信装置１に対して基地局２から更新用ソフトウェアを配信する。このようにすることで、更新用ソフトウェアのサイズが大きい場合であっても、基地局２の通信容量が逼迫することを防ぐことができる。
【００４４】
配信部３３３は、更新用ソフトウェアを配信する時刻に基づいて閾値台数を決定してもよい。例えば、配信部３３３は、ＬＰＷＡの通信量が多くなる時間帯においては、更新用ソフトウェアを配信する閾値台数を少なくし、通信量が少なくなる時間帯においては、閾値台数を多くする。このようにすることで、更新用ソフトウェアの配信によって基地局２の通信に影響を与えることを防ぐことができる。
【００４５】
配信部３３３は、基地局２の種別に基づいて閾値台数を決定してもよい。例えば、基地局２の種別によって同時接続数が異なる場合、配信部３３３は、基地局２の種別に応じて閾値台数を決定する。このようにすることで、更新用ソフトウェアの配信によって基地局２それぞれの通信に影響を与えることを防ぐことができる。
【００４６】
配信部３３３は、通信装置１が所定のアプリケーションを実行していないタイミングで更新用ソフトウェアを配信してもよい。例えば、深夜時間帯においては通信装置１が所定のアプリケーションを実行していない場合、配信部３３３は、通信装置１が所定のアプリケーションを実行していないタイミングである深夜時間帯に更新用ソフトウェアを配信する。
【００４７】
配信部３３３は、例えば、アプリケーションの動作時間を示す動作時間情報を、通信装置１を管理する不図示のアプリケーションサーバから取得することにより、通信装置１が所定のアプリケーションを実行しているか否かを判定する。この場合、配信部３３３は、情報取得部３３１がアプリケーションサーバから取得した動作時間情報が示す動作時間以外のタイミングで更新用ソフトウェアを配信する。また、配信部３３３は、通信装置１に応答要求を送信し、応答要求に対して通信装置１から受信した、アプリケーションを実行中であるか否かを示す動作情報を含む応答情報に基づいて、通信装置１がアプリケーションを実行しているか否かを判定してもよい。この場合、配信部３３３は、応答情報に含まれる動作情報が、アプリケーションを実行中であることを示している場合、更新用ソフトウェアを配信しない。配信部３３３は、動作情報が、アプリケーションを実行中でないことを示している場合、更新用ソフトウェアを配信する。このようにすることで、更新用ソフトウェアの配信によって通信装置１が行う通常動作に影響を与えることを防ぐことができる。
【００４８】
配信部３３３は、閾値台数と等しい台数の通信装置１に対して更新用ソフトウェアを配信中に、複数の通信装置１のうち一以上の通信装置１への更新用ソフトウェアの配信が終了すると、決定部３３２が決定した順序に基づいて複数の通信装置１から選択した一以上の通信装置１への更新用ソフトウェアの配信を開始する。例えば、１つの基地局２における閾値台数が５台である場合において、ある基地局２に属する２台の通信装置１における更新用ソフトウェアの配信が終了したとする。
【００４９】
この場合において、配信部３３３は、まず、決定部３３２が決定した順序で格納された配信待ちＤＢから当該基地局２に属する上位２つのレコードを抽出し、配信状況ＤＢに格納する。そして、配信部３３３は、配信状況ＤＢに格納したレコードの順に、レコードに対応する２台の通信装置１に対して、基地局２から更新用ソフトウェアを配信する。このようにすることで、更新対象である通信装置１が大量にあっても、基地局２における他の通信に影響を与えずに、順次、全ての通信装置１に更新用ソフトウェアを更新させることができる。
【００５０】
配信部３３３は、配信状況ＤＢの配信状況に基づいて、配信状況ＤＢ及び配信待ちＤＢを更新する。具体的には、配信部３３３は、配信状況が「成功」である場合、すなわち、情報取得部３３１が通信装置１から取得した結果情報が、更新用ソフトウェアの受信が完了したことを示す場合、当該通信装置１のレコードを配信状況ＤＢから削除する。一方、配信部３３３は、配信状況が「失敗」である場合、すなわち、情報取得部３３１が通信装置１から取得した結果情報が、更新用ソフトウェアの受信が完了しなかったことを示す場合、当該通信装置１のレコードを配信状況ＤＢから抽出し、配信待ちＤＢに格納する。配信部３３３は、配信状況が「失敗」である場合、配信状況ＤＢから抽出したレコードを配信待ちＤＢの最後尾に格納してもよいし、通信装置ＩＤの昇順に合わせて格納してもよい。配信部３３３は、配信状況ＤＢにレコードがない場合、すなわち、配信対象の通信装置１がない場合、配信対象の通信装置１全てに更新用ソフトウェアの配信が終了したと判定する。
【００５１】
［配信装置３の処理］
続いて、配信装置３が行う処理の流れを説明する。図５は、第１実施形態に係る配信装置３が行う処理の流れを示すフローチャートである。本フローチャートは、配信装置３の管理者が記憶部３２に更新用ソフトウェアを格納したことを契機として開始する。
【００５２】
情報取得部３３１は、記憶部３２に格納されている通信装置ＩＤの一覧情報に基づいて、通信部３１を介して通信装置１に応答要求を送信する（Ｓ１）。応答要求を受信した通信装置１それぞれから応答情報が送信されると、情報取得部３３１は、通信部３１を介して、応答情報に含まれる基地局ＩＤを取得する（Ｓ２）。具体的には、情報取得部３３１は、通信装置１から、通信装置ＩＤ及び基地局ＩＤを取得する。情報取得部３３１は、取得した通信装置ＩＤ及び基地局ＩＤを決定部３３２に入力する。
【００５３】
決定部３３２は、情報取得部３３１から入力された通信装置ＩＤ及び基地局ＩＤに基づいて、更新用ソフトウェアを配信する通信装置１の順序を決定する（Ｓ３）。図６は、第１実施形態に係る配信処理の流れを説明するための図である。決定部３３２は、図６に示すバージョン１の配信待ちＤＢに、順序を通信装置ＩＤの昇順にした上で、通信装置ＩＤと基地局ＩＤとを対応付けて格納する。
【００５４】
図５に戻り、配信部３３３は、決定部３３２が決定した順序に基づいて、閾値台数以下の台数の通信装置１に対して基地局２から更新用ソフトウェアを配信する（Ｓ４）。例えば、１つの基地局２における閾値台数が５台である場合、配信部３３３は、まず、図６に示すバージョン１の配信待ちＤＢから基地局ＩＤ「１００１」に属する上位５つのレコードを抽出し、バージョン１の配信状況ＤＢに格納する。配信部３３３は、抽出したレコードをバージョン１の配信状況ＤＢから削除し、閾値台数を超えた通信装置ＩＤ「０００８」に対応するレコードをバージョン２の配信待ちＤＢに示すように最後尾に格納する。そして、配信部３３３は、バージョン１の配信状況ＤＢに格納したレコードに対応する通信装置１に対して、基地局２から更新用ソフトウェアの配信を開始する。配信部３３３は、他の基地局２に属する通信装置１に対しても同様の処理を行う。
【００５５】
図５に戻り、更新用ソフトウェアの配信が終了した通信装置１から、受信が完了したか否かを示す結果情報が送信されると、決定部３３２は、結果情報に基づいて、更新用ソフトウェアの配信が成功したか否かを判定する（Ｓ５）。具体的には、まず、情報取得部３３１は、通信装置１から結果情報を取得し、取得した結果情報を決定部３３２に入力する。そして、決定部３３２は、情報取得部３３１から入力された結果情報に基づいて、配信状況ＤＢを更新する。
【００５６】
図７は、第１実施形態に係る配信処理の流れを説明するための図である。例えば、通信装置ＩＤ「０００１」に対応する通信装置１から、受信が完了したことを示す結果情報が送信された場合、決定部３３２は、バージョン２の配信状況ＤＢに示すように、通信装置ＩＤ「０００１」に対応する配信状況を「成功」に更新する。
【００５７】
一方、通信装置ＩＤ「０００７」に対応する通信装置１から、受信が完了しなかったことを示す結果情報が送信された場合、決定部３３２は、バージョン２の配信状況ＤＢに示すように、通信装置ＩＤ「０００７」に対応する配信状況を「失敗」に更新する。図５に戻り、決定部３３２は、配信が成功したと判定した場合、処理をＳ６に進め、配信が失敗したと判定した場合、処理をＳ８に進める。
【００５８】
配信部３３３は、配信が成功したと判定した場合、配信が成功した通信装置１に対応するレコードを配信状況ＤＢから削除する（Ｓ６）。具体的には、配信部３３３は、図７に示す配信状況が「成功」であるレコードを配信状況ＤＢから削除する。続いて、配信部３３３は、配信待ちＤＢにレコードがあるか否かを判定する（Ｓ７）。配信部３３３は、配信待ちＤＢにレコードがあると判定した場合、処理をＳ１０に進め、配信待ちＤＢにレコードがないと判定した場合、処理をＳ１１に進める。
【００５９】
配信部３３３は、Ｓ５において決定部３３２が更新用ソフトウェアの配信が失敗したと判定した場合、配信待ちＤＢにレコードがあるか否かを判定する（Ｓ８）。配信部３３３は、配信待ちＤＢにレコードがあると判定した場合、処理をＳ９に進める。一方、配信部３３３は、配信待ちＤＢにレコードがないと判定した場合、すなわち、更新用ソフトウェアをまだ配信していない通信装置１がない場合、処理をＳ４に戻し、更新用ソフトウェアの配信が失敗した通信装置１に更新用ソフトウェアを再配信する。
【００６０】
配信部３３３は、Ｓ８において配信待ちＤＢにレコードがあると判定した場合、更新用ソフトウェアの配信が失敗した通信装置１に対応するレコードを配信状況ＤＢから抽出し、配信待ちＤＢの最後尾に格納する（Ｓ９）。具体的には、配信部３３３は、図７に示す配信状況が「失敗」であるレコードを配信状況ＤＢから抽出し、バージョン３の配信待ちＤＢの最後尾に格納する。配信部３３３は、抽出したレコードを配信状況ＤＢから削除する。
【００６１】
配信部３３３は、Ｓ９に続いて、又はＳ７において配信待ちＤＢにレコードがあると判定した場合、配信状況ＤＢの更新処理を行う（Ｓ１０）。具体的には、配信部３３３は、閾値台数と等しい台数の通信装置１に対して更新用ソフトウェアを配信中に、複数の通信装置１のうち一以上の通信装置１への更新用ソフトウェアの配信が終了すると、決定部３３２が決定した順序に基づいて複数の通信装置１から選択した一以上の通信装置１への更新用ソフトウェアの配信を開始する。
【００６２】
図７に示すバージョン２の配信状況ＤＢにおいて、通信装置ＩＤ「０００１」及び「０００７」に対応する２台の通信装置１への更新用ソフトウェアの配信が終了しているとする。この場合において、配信部３３３は、バージョン３の配信待ちＤＢから基地局ＩＤ「１００１」に対応するレコードのうち、上位２つのレコードを抽出し、バージョン３の配信状況ＤＢに示すように２つのレコードを配信状況ＤＢに格納する。そして、配信部３３３は、処理をＳ４に戻し、配信状況ＤＢに格納したレコードに対応する２台の通信装置１に対して、基地局２から更新用ソフトウェアの配信を開始する。
【００６３】
配信部３３３は、Ｓ７において配信待ちＤＢにレコードがないと判定した場合、配信状況ＤＢにレコードがあるか否かを判定する（Ｓ１１）。配信部３３３は、配信状況ＤＢにレコードがあると判定した場合、処理をＳ５に戻す。配信部３３３は、配信状況ＤＢにレコードがないと判定した場合、すなわち、配信対象の全ての通信装置１から、受信が完了したことを示す結果情報を受信し、配信対象の全ての通信装置１への更新用ソフトウェアの配信が完了したと判定した場合、処理を終了する。
【００６４】
［第１実施形態における効果］
以上説明した通り、第１実施形態に係る配信装置３は、基地局２ごとに、更新用ソフトウェアの配信順序を決定し、閾値台数以下の台数の通信装置１に対して基地局２から更新用ソフトウェアを配信する。また、配信装置３は、更新用ソフトウェアを配信中の通信装置１のうち、一以上の通信装置１から受信が完了したことを示す結果情報を受信したことにより更新用ソフトウェアの配信が終了したと判定した場合に、配信順序に基づいて、配信が終了した通信装置１の台数と同じ台数の通信装置１に更新用ソフトウェアを配信する。このようにすることで、配信装置３は、更新対象である通信装置１が大量にあっても、更新用ソフトウェアの同時配信数を制御しながら、全ての通信装置１に更新用ソフトウェアを配信することができる。その結果、配信装置３は、基地局２に接続する他の通信装置１に影響を与えずに、更新対象である大量の通信装置１にソフトウェアを更新させることができる。
【００６５】
＜第２実施形態＞
［移動可能な通信装置１に更新用ソフトウェアを配信する］
続いて、第２実施形態について説明する。第１実施形態に係る配信装置３は、通常の使用において移動しない通信装置１に更新用ソフトウェアを配信した。これに対して、第２実施形態に係る配信装置３は、移動しない通信装置１と移動する通信装置１（例えば、無線通信網を介して位置情報をサーバに送信するＧＰＳトラッカー等）とに対して更新用ソフトウェアを配信する点で第１実施形態と異なる。以下に、第１実施形態と異なる部分について説明を行う。第１実施形態と同じ部分については適宜説明を省略する。また、本実施形態における更新対象のソフトウェアは、通信事業者が自身のネットワークに接続するために提供された通信モジュールを制御するソフトウェアであるとして説明する。
【００６６】
図８は、第２実施形態に係る配信待ちＤＢの構成を示す図である。図８に示すように、配信待ちＤＢは、通信装置ＩＤと基地局ＩＤとに加えて、通信装置１が移動するか否かを示す装置種別と、通信装置１から応答情報を取得した日時を示す取得日時とを関連付けて記憶している。装置種別は、例えば、移動可能な通信装置１であることを示す「移動」と、固定して設置される通信装置１であることを示す「固定」とがある。装置種別は、例えば、予め通信装置ＩＤに関連付けて一覧情報に記憶されている。配信装置３は、更新用ソフトウェアの配信履歴を記憶部３２に記憶させておき、配信履歴において属していた基地局２と、最新の時点で属している基地局２とが異なる場合に「移動」であると判定してもよい。本実施形態においては、装置種別が予め通信装置ＩＤに関連付けて一覧情報に記憶されている場合について説明する。
【００６７】
第２実施形態に係る情報取得部３３１は、通信装置１から基地局ＩＤを取得した後に所定の時間が経過する前に配信部３３３が通信装置１に更新用ソフトウェアの配信を開始できない場合に、通信装置１が属する基地局２の基地局ＩＤを再び取得する。例えば、所定の時間が「１０分」である場合において、情報取得部３３１は、まず、配信待ちＤＢに格納されているレコードに対応する通信装置１に対して更新用ソフトウェアの配信が可能となった場合に、取得日時から１０分を経過した通信装置１に対して応答要求を再び送信する。そして、情報取得部３３１は、応答要求を受信した通信装置１から応答情報が送信されると、応答情報を取得し、応答情報に含まれる通信装置ＩＤ、基地局ＩＤ、及び応答情報を取得した日時を決定部３３２に入力する。
【００６８】
情報取得部３３１は、基地局２に属している移動可能な通信装置１の数に基づいて、通信装置１が属する基地局２の基地局ＩＤを再び取得する前に待機する所定の時間を決定してもよい。例えば、情報取得部３３１は、固定して設置された通信装置１より移動可能な通信装置１の方が多い場合、移動可能な通信装置１より固定して設置された通信装置１の方が多い場合に比べて、待機する時間を短い時間に決定する。一方、情報取得部３３１は、移動可能な通信装置１より固定して設置された通信装置１の方が多い場合、固定して設置された通信装置１より移動可能な通信装置１の方が多い場合に比べて、待機する時間を長い時間に決定する。このようにすることで、情報取得部３３１は、移動可能な通信装置１の数が多い基地局２に属する通信装置１の通信装置ＩＤを更新する頻度を高くすることができるので、配信部３３３が、通信装置１が属していない基地局２に対して更新用ソフトウェアを配信する確率を下げることができる。
【００６９】
情報取得部３３１は、装置種別に基づいて、通信装置１が属する基地局２の基地局ＩＤを再び取得する前に待機する所定の時間を決定してもよい。例えば、情報取得部３３１は、移動可能な通信装置１が待機する時間を、固定して設置された通信装置１が待機する時間に比べて短い時間に決定する。一方、情報取得部３３１は、固定して設置された通信装置１が待機する時間を、移動可能な通信装置１が待機する時間に比べて長い時間に決定する。
【００７０】
また、移動可能な通信装置１が加速度センサを備えている場合、情報取得部３３１は、通信装置１から加速度センサで計測された加速度の情報を含む応答情報を取得し、当該加速度の情報に基づいて、通信装置１が移動中であるか否かを判断してもよい。この場合、情報取得部３３１は、移動可能な通信装置１が移動中であると判断した場合、移動していないと判断した場合に比べて、待機する時間をより短い時間に決定する。このようにすることで、情報取得部３３１は、移動している通信装置１に対して、属する基地局２の基地局ＩＤを更新する頻度を高くすることができるので、配信部３３３が、通信装置１が属していない基地局２に対して更新用ソフトウェアを配信する確率をより下げることができる。
【００７１】
情報取得部３３１は、通信装置１が移動可能であることを条件として、通信装置１が属する基地局２の基地局ＩＤを、配信部３３３が更新用ソフトウェアを再び配信するタイミングの所定時間前に再び取得してもよい。具体的には、情報取得部３３１は、配信待ちＤＢに格納されているレコードに対応する通信装置１に対して更新用ソフトウェアの配信が可能となった場合において、当該通信装置１の装置種別が「移動」である場合に、通信装置１が属する基地局２の基地局ＩＤを再び取得する。情報取得部３３１は、通信装置１が移動中であることを条件として、通信装置１が属する基地局２の基地局ＩＤを再び取得してもよい。このようにすることで、情報取得部３３１は、固定して設置される通信装置１、すなわち、属する基地局２が変わらない通信装置１に対して、基地局ＩＤを再び取得することを防ぐことができる。
【００７２】
第２実施形態に係る決定部３３２は、情報取得部３３１が先に取得していた第１基地局ＩＤと、情報取得部３３１が再び取得した第２基地局ＩＤとが異なっている場合に、第１基地局ＩＤを情報取得部３３１が取得した時点で通信装置１が属していた第１基地局２、及び第２基地局ＩＤを情報取得部３３１が取得した時点で通信装置１が属する第２基地局２のそれぞれに対応する順序を再決定する。
【００７３】
図９は、第２実施形態に係る配信順序を決定する処理の流れを説明するための図である。バージョン１の配信状況ＤＢに示すように、３台の通信装置１が更新用ソフトウェアの受信に成功したことにより更新用ソフトウェアの配信が成功し、通信装置１それぞれが属する基地局２から１台の通信装置１に対して更新用ソフトウェアの配信が可能となった状況であるとする。また、バージョン１の配信待ちＤＢに示すように、情報取得部３３１が、閾値台数を下回った基地局２に属する通信装置１それぞれから基地局ＩＤを再び取得したところ、通信装置ＩＤ「０００８」に対応する通信装置１が属する基地局２が変わったとする。
【００７４】
この場合において、決定部３３２は、通信装置ＩＤ「０００８」に対応するレコードにおける基地局ＩＤを、基地局ＩＤ「１００２」から基地局ＩＤ「１００３」に変更する。その結果、基地局ＩＤ「１００２」の基地局２が更新用ソフトウェアを配信する対象となる通信装置１から通信装置ＩＤ「０００８」の通信装置１が削除され、配信する順序が更新される。また、基地局ＩＤ「１００３」の基地局２が更新用ソフトウェアを配信する対象となる通信装置１として通信装置ＩＤ「０００８」の通信装置１が追加され、配信する順序が更新される。
【００７５】
なお、決定部３３２は、通信装置ＩＤ「０００８」の通信装置１の移動に伴って、配信待ちＤＢにおける順番を変更し、例えばバージョン２の配信待ちＤＢに示すように最後尾に格納してもよい。決定部３３２が再決定する順序においては、属する基地局２が変わった通信装置１を、このように最後尾にしてもよいし、同じ基地局２に属する通信装置１の先頭にしてもよい。
【００７６】
また、決定部３３２は、取得日時に基づいて順序を決定する場合、第１基地局ＩＤと異なる第２基地局ＩＤを取得した日時に基づいて、配信待ちＤＢに格納されているレコードの順序を並び替えてもよい。例えば、決定部３３２は、第２基地局ＩＤを取得した日時が古い順に順序を決定する。
【００７７】
このように決定部３３２は、第１基地局ＩＤに基づいて決定した順序を、ある通信装置１が属する基地局２が、第１基地局ＩＤとは異なる第２基地局ＩＤに変わったことに応じて更新することにより、基地局２ごとに、通信装置１に更新用ソフトウェアを配信する順序を再決定する。その後、配信部３３３は、配信待ちＤＢに格納されているレコードのうち、基地局ＩＤ「１００１」、「１００２」、及び「１００３」の基地局２に属するそれぞれの通信装置１に対応するレコードを抽出し、バージョン２の配信状況ＤＢに示すように格納する。そして、配信部３３３は、配信状況ＤＢに格納した通信装置ＩＤ「０００７」、「０００９」、及び「００１１」に対応する通信装置１それぞれに対して、属する基地局２ごとに更新用ソフトウェアの配信を開始する。
【００７８】
このようにすることで、決定部３３２は、配信部３３３が、通信装置１が属していない基地局２に対して更新用ソフトウェアを配信する確率を下げつつ、基地局２ごとに、変動する通信装置１の台数に基づいて決定された順序に基づいて、更新用ソフトウェアを配信することができる。
【００７９】
決定部３３２は、基地局２に属する複数の通信装置１のうち移動可能な通信装置１の割合が閾値未満である場合に、移動可能な通信装置１の割合が閾値以上である場合よりも早いタイミングで順序を決定してもよい。例えば、決定部３３２は、固定して設置される通信装置１が多数を占めて、移動可能な通信装置１がほとんどない場合に、情報取得部３３１が通信装置１から基地局ＩＤを取得する前のタイミングで順序を決定する。一方、決定部３３２は、移動可能な通信装置１が多数を占めて、固定して設置される通信装置１がほとんどない場合に、情報取得部３３１が通信装置１から基地局ＩＤを取得する前においては順序を決定せずに、取得した後のタイミングで順序を決定する。このように決定部３３２が予め順序を決定することで、配信装置３の管理者は、更新用ソフトウェアの配信にかかる期間の見通しを立てることができる。
【００８０】
決定部３３２は、基地局２に属する複数の通信装置１のうち移動可能な通信装置１の割合が閾値以上である場合に、更新用ソフトウェアが配信可能な状態になった後に順序を決定してもよい。例えば、決定部３３２は、移動可能な通信装置１が多数を占めて、固定して設置される通信装置１がほとんどない場合に、予め順序を決定せず、情報取得部３３１が通信装置１から取得した基地局ＩＤに基づいて順序を決定する。このようにすることで、決定部３３２は、配信部３３３が、通信装置１が属していない基地局２に対して更新用ソフトウェアを配信する確率を下げることができる。
【００８１】
［配信状況ＤＢ更新処理］
続いて、配信装置３が行う処理の流れを説明する。第２実施形態に係る配信装置３が行う処理においては、図５の配信状況ＤＢ更新処理（Ｓ１０）のみ異なるため、当該処理のみについて説明する。図１０は、第２実施形態に係る配信装置３が行う配信状況ＤＢ更新処理の流れを示すフローチャートである。本フローチャートは、図５のＳ９に続いて、又はＳ７において配信部３３３が配信待ちＤＢにレコードがあると判定した場合を契機として開始する。
【００８２】
情報取得部３３１は、配信部３３３が閾値台数と等しい台数の通信装置１に対して更新用ソフトウェアを配信中に、複数の通信装置１のうち一以上の通信装置１への更新用ソフトウェアの配信が終了すると、順序に基づいて複数の通信装置１から選択した一以上の通信装置１が移動可能な通信装置１であるか否かを判定する（Ｓ１０１）。具体的には、情報取得部３３１は、配信待ちＤＢに格納されているレコードのうち、配信部３３３が選択した一以上のレコードの装置種別が「移動」であるか「固定」であるかを判定する。
【００８３】
また、配信待ちＤＢに格納されているレコードに加速度の状態が関連付けて記憶されている場合に、情報取得部３３１は、配信待ちＤＢに格納されているレコードのうち、配信部３３３が選択した一以上のレコードの加速度の状態が移動中であることを示しているか否かに基づいて、装置種別が「移動」であるか「固定」であるかを判定してもよい。また、更新用ソフトウェアの配信履歴が記憶部３２に記憶されている場合に、情報取得部３３１は、配信待ちＤＢに格納されているレコードのうち、配信履歴が示している過去に属していた基地局２と、現時点で属している基地局２とが異なるか否かに基づいて、装置種別が「移動」であるか「固定」であるかを判定してもよい。
【００８４】
情報取得部３３１は、装置種別が「固定」であると判定した場合、処理をＳ１０５に進める。一方、情報取得部３３１は、装置種別が「移動」であると判定した場合、基地局ＩＤを取得してから所定の時間が経過したか否かを判定する（Ｓ１０２）。
【００８５】
情報取得部３３１は、所定の時間が経過していないと判定した場合、処理をＳ１０５に進める。一方、情報取得部３３１は、所定の時間が経過したと判定した場合、通信装置１から基地局ＩＤを再び取得する（Ｓ１０３）。具体的には、情報取得部３３１は、まず、配信待ちＤＢに格納されているレコードのうち、取得日時から所定の時間が経過したレコードに対応する通信装置１に応答要求を送信する。そして、情報取得部３３１は、応答要求を受信した通信装置１から送信された応答情報に含まれる基地局ＩＤを取得する。情報取得部３３１は、取得した通信装置ＩＤ、基地局ＩＤ、及び応答情報を取得した日時を決定部３３２に入力する。
【００８６】
決定部３３２は、情報取得部３３１から入力された通信装置ＩＤ、基地局ＩＤ、及び取得日時に基づいて、配信順序を再決定する（Ｓ１０４）。具体的には、決定部３３２は、第１基地局ＩＤに基づいて決定した順序を、通信装置１が属する基地局２が、第１基地局ＩＤとは異なる第２基地局ＩＤに変わったことに応じて更新することにより、基地局２ごとに、通信装置１に更新用ソフトウェアを配信する順序を再決定する。
【００８７】
配信部３３３は、Ｓ１０１において情報取得部３３１が、装置種別が「固定」であると判定した場合、又はＳ１０２において情報取得部３３１が、所定の時間が経過していないと判定した場合に、閾値台数を超えない範囲において、配信待ちＤＢから更新用ソフトウェアを配信する対象となった通信装置１に対応するレコードを抽出し、配信状況ＤＢに格納する（Ｓ１０５）。
【００８８】
［第２実施形態における効果］
以上説明した通り、第２実施形態に係る配信装置３は、通信装置１から基地局ＩＤを取得した後に所定の時間が経過する前に更新用ソフトウェアの配信を開始することができない場合に、通信装置１から属する基地局ＩＤを再び取得する。そして、配信装置３は、再び取得した基地局ＩＤと先に取得した基地局ＩＤとが異なる場合に、更新用ソフトウェアを配信する順序を再決定する。このようにすることで、配信装置３は、更新用ソフトウェアの配信を開始するまでに時間がかかった場合であっても、移動可能な通信装置１が属する基地局２が変わったことを配信順序に反映させることができる。その結果、配信装置３は、通信装置１が属していない基地局２に対して更新用ソフトウェアを配信する確率を下げることができる。
【００８９】
［変形例］
以上の説明においては、配信部３３３が、決定部３３２が決定した順序に基づいてソフトウェアを配信することが想定されていた。これに対して、配信部３３３は、複数の基地局２を含む所定のエリア内でソフトウェアを配信する対象となる通信装置１の台数が所定の台数以上であることを条件として、決定部３３２が決定した順序に基づいて、閾値台数以下の台数の通信装置１に対して複数の基地局２からソフトウェアを配信してもよい。
【００９０】
例えば、ソフトウェアを配信する必要があるエリアに存在する通信装置１の台数が、１台の基地局２が同時にソフトウェアを配信可能な通信装置１の数以下である場合に、配信部３３３は、決定部３３２が決定した順序によらず、ソフトウェアを配信する対象である全ての通信装置１にソフトウェアを配信する。一方、ソフトウェアを配信する必要があるエリアに存在する通信装置１の台数が、１台の基地局２が同時にソフトウェアを配信可能な通信装置１の数よりも多い場合に、配信部３３３は、決定部３３２が決定した順序に基づいて、順次ソフトウェアを配信する。このようにすることで、ソフトウェアを配信する対象となる通信装置１の数が少ないエリアの通信装置１にソフトウェアを配信する際の配信装置３の処理の負荷を軽減することができる。
【００９１】
なお、エリアの決定方法は任意であるが、例えば、全国に網羅的に通信装置１が存在する場合、通信装置１の台数に基づいてエリアを決定することが考えられる。１つの配信装置３が全国の通信装置１にソフトウェアを配信する場合、配信装置３の負荷が重くなり過ぎないように、決定部３３２は、ソフトウェアを配信するエリアの順序を決定し、配信部３３３は決定された順序に基づいて、ソフトウェアを配信してもよい。
【００９２】
また、特定エリア（例えば関東地方）に多数の通信装置１が集中している場合、基地局２のリソースがソフトウェアの配信のために占有されるおそれがある。そこで、配信装置３は、特定エリアにおいてソフトウェアを配信する対象とする通信装置１の台数を複数のグループに分割し、分割したグループごとに、順次ソフトウェアを配信してもよい。この場合、決定部３３２は、各グループ内の配信順序を決定する。このようにすることで、配信装置３及び基地局２の両方の負荷を軽減することができる。
【００９３】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されず、その要旨の範囲内で種々の変形及び変更が可能である。例えば、装置の分散・統合の具体的な実施の形態は、以上の実施の形態に限られず、その全部又は一部について、任意の単位で機能的又は物理的に分散・統合して構成することができる。また、複数の実施の形態の任意の組み合わせによって生じる新たな実施の形態も、本発明の実施の形態に含まれる。組み合わせによって生じる新たな実施の形態の効果は、もとの実施の形態の効果を合わせ持つ。
【符号の説明】
【００９４】
１  通信装置
２  基地局
３  配信装置
３１  通信部
３２  記憶部
３３  制御部
３３１  情報取得部
３３２  決定部
３３３  配信部
【図１】
2020022201.tif 000003
【図２】
2020022201.tif 000004
【図３】
2020022201.tif 000005
【図４】
2020022201.tif 000006
【図５】
2020022201.tif 000007
【図６】
2020022201.tif 000008
【図７】
2020022201.tif 000009
【図８】
2020022201.tif 000010
【図９】
2020022201.tif 000011
【図１０】
2020022201.tif 000012