特許7419482 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ ホアウェイクラウドコンピューティングテクノロジーズカンパニーリミテッドの特許一覧

特許7419482ソフトウェアアップグレード管理方法、サーバ、端末、装置及び記憶媒体

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13

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

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

(11)【特許番号】

(24)【登録日】2024-01-12

(45)【発行日】2024-01-22

(54)【発明の名称】ソフトウェアアップグレード管理方法、サーバ、端末、装置及び記憶媒体

(51)【国際特許分類】

G06Q 50/10 20120101AFI20240115BHJP

【ＦＩ】

G06Q50/10

【請求項の数】 34

【外国語出願】

(21)【出願番号】P 2022177600

(22)【出願日】2022-11-04

(62)【分割の表示】P 2020542946の分割

【原出願日】2019-01-29

(65)【公開番号】P2023017926

(43)【公開日】2023-02-07

【審査請求日】2022-12-05

(31)【優先権主張番号】201810146366.8

(32)【優先日】2018-02-12

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】521486206

【氏名又は名称】ホアウェイクラウドコンピューティングテクノロジーズカンパニーリミテッド

【氏名又は名称原語表記】ＨｕａｗｅｉＣｌｏｕｄＣｏｍｐｕｔｉｎｇＴｅｃｈｎｏｌｏｇｉｅｓＣｏ．，Ｌｔｄ．

【住所又は居所原語表記】ＨｕａｗｅｉＣｌｏｕｄＤａｔａＣｅｎｔｅｒ，ＪｉａｏｘｉｎｇｇｏｎｇＲｏａｄ，ＱｉａｎｚｈｏｎｇＡｖｅｎｕｅ，Ｇｕｉ’ａｎＮｅｗＤｉｓｔｒｉｃｔ，Ｇｕｉｚｈｏｕ，５５００２５，Ｃｈｉｎａ

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100133569

【弁理士】

【氏名又は名称】野村進

(72)【発明者】

【氏名】朱 ▲錦▼涛

【審査官】宮地匡人

(56)【参考文献】

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

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

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

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

【文献】米国特許出願公開第２０１７／０２３０７１３（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０１５４０１６（ＵＳ，Ａ１）

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

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

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

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

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

【請求項1】

モノのインターネット（IOT）端末が登録されることに成功したことをサーバによって決定するステップであって、IOTシステムは前記サーバとIOT端末を含み、前記サーバは前記IOT端末にクラスタ管理を実行するように構成されている、ステップと、
アップグレードパッケージを前記サーバによって取得するステップと、
前記IOT端末のターゲットアップグレードモードを前記サーバによって決定するステップであって、前記ターゲットアップグレードモードは、端末判断型アップグレードモードを備える、ステップと、
アップグレードパッケージ優先度を前記IOT端末に前記サーバによって送るステップであって、前記アップグレードパッケージ優先度は、ソフトウェアアップグレードプロシージャを開始するために前記アップグレードパッケージ優先度及び前記IOT端末でのサービスのサービスステータス情報に基づいて判断するのに前記IOT端末によって用いられ、前記サービスステータス情報は、サービスステータス及びサービス優先度のうちの少なくとも一方を備え、前記サービスステータスは、前記サービスのアイドル状態又は非アップグレード状態を示すために用いられる、ステップと、
前記アップグレードパッケージを前記IOT端末に前記サーバによって送って、前記IOT端末の前記ソフトウェアアップグレードプロシージャを実行するステップと
を備えるソフトウェアアップグレード管理方法。

【請求項2】

前記アップグレードパッケージを前記IOT端末に送る前記ステップの前に、前記方法は、
アップグレード要求を前記IOT端末から受けた後、前記アップグレード要求を前記サーバによって承認して肯定応答を前記IOT端末に送るステップであって、前記アップグレード要求は、前記IOT端末が前記ソフトウェアアップグレードプロシージャの開始を決定した後に送信される、ステップ
をさらに備える、請求項1に記載の方法。

【請求項3】

前記IOT端末のターゲットアップグレードモードを決定する前記ステップは、
アップグレードモードが前記IOT端末で設定されている場合、設定されている前記アップグレードモードを前記IOT端末から前記サーバによって受けるステップであって、前記端末判断型アップグレードモードは、前記IOT端末の前記ソフトウェアアップグレードプロシージャを開始するか否か、及び／又は、前記IOT端末の前記ソフトウェアアップグレードプロシージャをいつ開始するかを前記IOT端末が決定するモードである、ステップ
を備える、請求項1に記載の方法。

【請求項4】

前記端末が登録されることに成功したことを決定する前記ステップの後、前記方法は、
前記サーバによって、前記IOT端末に対するリソースディスカバリ動作を開始して、前記アップグレードモードが前記IOT端末で設定されているか否かを検出するステップ
をさらに備える、請求項1に記載の方法。

【請求項5】

前記方法は、
アップグレードパッケージタイプを前記IOT端末に前記サーバによって送るステップであって、前記アップグレードパッケージタイプは、前記ソフトウェアアップグレードプロシージャを開始するために前記アップグレードパッケージタイプ、前記アップグレードパッケージ優先度、及び前記IOT端末でのサービスのサービスステータス情報に基づいて判断するのに前記IOT端末によって用いられる、ステップ
をさらに備える、請求項1に記載の方法。

【請求項6】

前記アップグレードパッケージタイプは、セキュリティタイプ、機能タイプ、設定タイプや汎用タイプのうちの1つを備える、請求項5に記載の方法。

【請求項7】

前記方法は、
少なくとも2つのタイプのアップグレードパッケージの優先度を比較した後、前記少なくとも2つのタイプのアップグレードパッケージのうちの最高の優先度を持つアップグレードパッケージが前記アップグレードパッケージ優先度として用いられることを前記サーバによって決定するステップ
をさらに備える、請求項1に記載の方法。

【請求項8】

アップグレードパッケージ優先度を前記IOT端末に送るステップの前に、前記方法は、
前記サーバによって、アップグレードパッケージ優先度情報を取得し、前記優先度情報に基づいて前記アップグレードパッケージ優先度を決定するステップであって、前記優先度情報は前記アップグレードパッケージ優先度を明示的又は黙示的に示す、ステップ
をさらに備える、請求項1に記載の方法。

【請求項9】

モノのインターネット（IOT）端末によって、サーバに登録するステップであって、IOTシステムは前記サーバと前記IOT端末を含み、前記サーバは前記IOT端末にクラスタ管理を実行するように構成されている、ステップと、
前記IOT端末によって、アップグレードパッケージ優先度を受けるステップと、
前記IOT端末によって、前記アップグレードパッケージ優先度及びサービスステータス情報に基づいて前記IOT端末のソフトウェアアップグレードプロシージャを開始することを決定するステップであって、前記サービスステータス情報は、サービスステータス及びサービス優先度のうちの少なくとも一方を備え、前記サービスステータスは、サービスのアイドル状態又は非アップグレード状態を示すために用いられる、ステップと、
前記IOT端末によって、アップグレードパッケージを前記サーバから取得し、ターゲットアップグレードモードに基づいて、前記ソフトウェアアップグレードプロシージャを開始するステップであって、前記ターゲットアップグレードモードは、端末判断型アップグレードモードを備える、ステップと
を備えるソフトウェアアップグレード管理方法。

【請求項10】

前記アップグレードパッケージを取得する前記ステップの前に、前記方法は、
アップグレード要求を前記サーバに前記IOT端末によって送るステップと、
肯定応答を前記サーバから前記IOT端末によって受けるステップと
をさらに備える、請求項9に記載の方法。

【請求項11】

前記アップグレードモードが前記IOT端末で設定されている場合、前記ターゲットアップグレードモードを前記サーバに前記IOT端末によって送るステップであって、前記端末判断型アップグレードモードは、前記IOT端末の前記ソフトウェアアップグレードプロシージャを開始するか否か、及び／又は、前記IOT端末の前記ソフトウェアアップグレードプロシージャをいつ開始するかを前記IOT端末が決定するモードである、ステップ
をさらに備える、請求項9に記載の方法。

【請求項12】

前記端末のソフトウェアアップグレードプロシージャを開始することを決定するステップは、
アップグレードパッケージタイプを前記サーバから前記IOT端末によって受けるステップと、
前記IOT端末の前記ソフトウェアアップグレードプロシージャを開始するために前記アップグレードパッケージタイプ、前記アップグレードパッケージ優先度、及び前記IOT端末でのサービスのサービスステータス情報に基づいて前記IOT端末によって判断するステップと
を備える、請求項9に記載の方法。

【請求項13】

前記アップグレードパッケージタイプは、セキュリティタイプ、機能タイプ、設定タイプや汎用タイプのうちの1つを備える、請求項12に記載の方法。

【請求項14】

前記IOT端末のソフトウェアアップグレードプロシージャを開始することを決定する前記ステップは、
前記IOT端末の前記ソフトウェアアップグレードプロシージャを開始する時期を前記IOT端末によって決定するステップ
を備える、請求項9に記載の方法。

【請求項15】

モノのインターネット（IOT）端末が登録されることに成功したことを決定するように構成された処理モジュールであって、IOTシステムはサーバと前記IOT端末を含み、前記サーバは前記IOT端末にクラスタ管理を実行するように構成されている、処理モジュールと、
アップグレードパッケージを取得するように構成された送受信器モジュールと、
前記IOT端末のターゲットアップグレードモードを決定するように構成された前記処理モジュールであって、前記ターゲットアップグレードモードは、端末判断型アップグレードモードを備える、前記処理モジュールと、
アップグレードパッケージ優先度を前記IOT端末に送るように構成された前記送受信器モジュールであって、前記アップグレードパッケージ優先度は、ソフトウェアアップグレードプロシージャを開始するために前記アップグレードパッケージ優先度及び前記IOT端末でのサービスのサービスステータス情報に基づいて判断するのに前記IOT端末によって用いられ、前記サービスステータス情報は、サービスステータス及びサービス優先度のうちの少なくとも一方を備え、前記サービスステータスは、前記サービスのアイドル状態又は非アップグレード状態を示すために用いられる、前記送受信器モジュールと
を備え、
前記送受信器モジュールによって、前記アップグレードパッケージを前記IOT端末に送って、前記IOT端末の前記ソフトウェアアップグレードプロシージャを実行する
サーバ。

【請求項16】

前記送受信器モジュールは、アップグレード要求を前記IOT端末から受けるように構成され、前記処理モジュールは、前記アップグレード要求を承認して肯定応答を前記IOT端末に送り、前記アップグレード要求は、前記IOT端末が前記ソフトウェアアップグレードプロシージャの開始を決定した後に送信される、請求項15に記載のサーバ。

【請求項17】

前記送受信器モジュールは、アップグレードモードが前記IOT端末で設定されている場合、設定されている前記アップグレードモードを前記IOT端末から受けるように構成され、前記端末判断型アップグレードモードは、前記IOT端末の前記ソフトウェアアップグレードプロシージャを開始するか否か、及び／又は、前記IOT端末の前記ソフトウェアアップグレードプロシージャをいつ開始するかを前記IOT端末が決定するモードである、請求項15に記載のサーバ。

【請求項18】

IOT端末が登録されることに成功したことを決定した後、前記処理モジュールは、前記IOT端末に対するリソースディスカバリ動作を開始して、前記アップグレードモードが前記IOT端末で設定されているか否かを検出するように構成されている、請求項15に記載のサーバ。

【請求項19】

前記送受信器モジュールは、アップグレードパッケージタイプを前記IOT端末に送るように構成され、前記アップグレードパッケージタイプは、前記ソフトウェアアップグレードプロシージャを開始するために前記アップグレードパッケージタイプ、前記アップグレードパッケージ優先度、及び前記IOT端末でのサービスのサービスステータス情報に基づいて判断するのに前記IOT端末によって用いられる、請求項15に記載のサーバ。

【請求項20】

前記アップグレードパッケージタイプは、セキュリティタイプ、機能タイプ、設定タイプや汎用タイプのうちの1つを備える、請求項19に記載のサーバ。

【請求項21】

アップグレードパッケージ優先度を前記IOT端末に送る前に、前記送受信器モジュールは、アップグレードパッケージ優先度情報を取得し、前記優先度情報に基づいて前記アップグレードパッケージ優先度を決定するように構成され、前記優先度情報は前記アップグレードパッケージ優先度を明示的又は黙示的に示す、請求項15に記載のサーバ。

【請求項22】

前記送受信器モジュールは、アップグレードパッケージ優先度情報を取得し、前記優先度情報に基づいて前記アップグレードパッケージ優先度を決定するように構成され、前記優先度情報は前記アップグレードパッケージ優先度を明示的又は黙示的に示す、請求項15に記載のサーバ。

【請求項23】

モノのインターネット（IOT）端末であって、前記IOT端末は、
サーバに登録するように構成された処理モジュールであって、IOTシステムは前記サーバと前記IOT端末を含み、前記サーバは前記IOT端末にクラスタ管理を実行するように構成されている、処理モジュールと、
アップグレードパッケージ優先度を受けるように構成された送受信器モジュールと、
前記アップグレードパッケージ優先度及びサービスステータス情報に基づいて前記IOT端末のソフトウェアアップグレードプロシージャを開始することを決定するように構成された前記処理モジュールであって、前記サービスステータス情報は、サービスステータス及びサービス優先度のうちの少なくとも一方を備え、前記サービスステータスは、サービスのアイドル状態又は非アップグレード状態を示すために用いられる、前記処理モジュールと、
アップグレードパッケージを前記サーバから前記送受信器モジュールによって取得し、ターゲットアップグレードモードに基づいて、前記ソフトウェアアップグレードプロシージャを開始するように構成された前記送受信器モジュールであって、前記ターゲットアップグレードモードは、端末判断型アップグレードモードを備える、前記送受信器モジュールと
を備える、IOT端末。

【請求項24】

前記送受信器モジュールは、アップグレード要求を前記サーバに送り、肯定応答を前記サーバから受けるように構成された、請求項23に記載のIOT端末。

【請求項25】

前記送受信器モジュールは、前記アップグレードモードが前記IOT端末で設定されている場合、前記ターゲットアップグレードモードを前記サーバに送るように構成され、前記端末判断型アップグレードモードは、前記IOT端末の前記ソフトウェアアップグレードプロシージャを開始するか否か、及び／又は、前記IOT端末の前記ソフトウェアアップグレードプロシージャをいつ開始するかを前記IOT端末が決定するモードである、請求項23に記載のIOT端末。

【請求項26】

前記送受信器モジュールは、
アップグレードパッケージタイプを前記サーバから受け、
前記IOT端末の前記ソフトウェアアップグレードプロシージャを開始するために前記アップグレードパッケージタイプ、前記アップグレードパッケージ優先度、及び前記IOT端末でのサービスのサービスステータス情報に基づいて判断する
ように構成された、請求項23に記載のIOT端末。

【請求項27】

前記アップグレードパッケージタイプは、セキュリティタイプ、機能タイプ、設定タイプや汎用タイプのうちの1つを備える、請求項26に記載のIOT端末。

【請求項28】

前記処理モジュールは、前記IOT端末の前記ソフトウェアアップグレードプロシージャを開始する時期を決定するように構成された、請求項23に記載のIOT端末。

【請求項29】

少なくとも1つのプロセッサ、少なくとも1つのメモリ、及び少なくとも1つの送受信器を備え、
前記メモリは、プログラムコードを記憶するように構成されており、前記プロセッサは、前記メモリ中の前記プログラムコードを呼び出して、請求項1から8のいずれか一項に記載のサーバの動作を実行するように構成されている、
コンピュータ装置。

【請求項30】

少なくとも1つのプロセッサ、少なくとも1つのメモリ、及び少なくとも1つの送受信器を備え、
前記メモリは、プログラムコードを記憶するように構成されており、前記プロセッサは、前記メモリ中の前記プログラムコードを呼び出して、請求項9から14のいずれか一項に記載のIOT端末の動作を実行するように構成されている、
コンピュータ装置。

【請求項31】

命令を備え、前記命令がコンピュータ上で動作するとき、前記コンピュータが請求項1から8のいずれか一項に記載のサーバの動作を実行することが可能にされる、コンピュータ可読記憶媒体。

【請求項32】

命令を備え、前記命令がコンピュータ上で動作するとき、前記コンピュータが請求項9から14のいずれか一項に記載のIOT端末の動作を実行することが可能にされる、コンピュータ可読記憶媒体。

【請求項33】

コンピュータ上で動作し、前記コンピュータが請求項1から8のいずれか一項に記載のサーバの動作を実行することが可能にされる、コンピュータプログラムプロダクト。

【請求項34】

コンピュータ上で動作し、前記コンピュータが請求項9から14のいずれか一項に記載のIOT端末の動作を実行することが可能にされる、コンピュータプログラムプロダクト。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、2018年2月12日に中国特許庁に出願され、名称が「ソフトウェアアップグレード管理方法、サーバ、端末、装置及び記憶媒体」である中国特許出願第201810146366．8号の優先権を主張し、本中国特許出願の全体が参照により本明細書に援用される。

【0002】

本出願は、モノのインターネット技術の分野に関し、特に、ソフトウェアアップグレード管理方法、サーバ、端末、装置及び記憶媒体に関する。

【背景技術】

【0003】

モノのインターネットでは、モノのインターネットデバイスのソフトウェアアップグレードは、人による意思決定と手作業のアップグレードとを行なう専門要員に依存している。さらに、ソフトウェアアップグレードプロシージャが開始される前、モノのインターネットデバイスのサービスステータス情報がアップグレード条件を満たすか否かが判断されない。代わりに、ソフトウェアアップグレードプロシージャが直接開始される。現在のアップグレードパッケージが機能型や設定型であり、非アイドル状態での重要なサービス（たとえば、セキュリティサービス）がモノのインターネットデバイスでデプロイされている場合、ソフトウェアアップグレードプロシージャを直接開始すると、モノのインターネットデバイスで進行中の重要なサービスを中断させる場合がある。

【発明の概要】

【0004】

本出願は、ソフトウェアアップグレードがモノのインターネットデバイスで実行されるときにモノのインターネットデバイスでのサービスが中断される先行技術の課題を解決することができるソフトウェアアップグレード管理方法、サーバ、端末、装置及び記憶媒体を提供する。

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

【0005】

本出願の第1の態様はソフトウェアアップグレード管理方法を提供し、方法は、以下のステップを含んでもよい。

【0006】

アップグレードパッケージをサーバが取得し、端末のターゲットアップグレードモードを決定し、ターゲットアップグレードモードは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含む。

【0007】

アップグレードパッケージを端末にサーバが送って、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行する。

【0008】

既存の機構と比較して、本出願では、ターゲットアップグレードモードを決定した後、決定されたターゲットアップグレードモードに基づいてソフトウェアアップグレードプロシージャをサーバが自動的に実行することにより、アップグレードの無人自動スケジューリングを実施する。

【0009】

第1の態様に基づいて、第1の態様の第1の実現例において、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行するステップは以下を含む。

【0010】

アップグレードパッケージタイプ、アップグレードパッケージ優先度又は端末でのサービスのサービスステータス情報のうちの少なくとも1つに基づいて端末のソフトウェアアップグレードプロシージャをサーバがターゲットアップグレードモードで実行し、サービスステータス情報はサービスステータス及びサービス優先度のうちの少なくとも一方を含む。

【0011】

第1の態様の第1の実現例に基づいて、第1の態様の第2の実現例において、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、アップグレードパッケージタイプ、アップグレードパッケージ優先度又は端末でのサービスのサービスステータス情報のうちの少なくとも1つに基づいて端末のソフトウェアアップグレードプロシージャをサーバがターゲットアップグレードモードで実行することは以下のステップを含む。

【0012】

端末でのサービスのサービスステータスをサービスステータス情報からサーバが取得する。

【0013】

端末のサービスステータスがアイドル状態又は非アップグレード状態であると判断する場合にサーバが端末に指示情報を送り、この指示情報は、プリセット時間以内にサービスを中止するように端末に命令するのに用いられる。たとえば、サービスステータスがアイドル状態である場合、プリセット時間は0又は比較的短い時間間隔であってもよく、指示情報をサーバが端末に直ちに送ってもよい。サービスステータスが非アップグレード状態である場合、プリセット時間は0又は比較的短い時間間隔であってもよく、この場合も指示情報をサーバが端末に送ってもよい。プリセット時間の値は本出願では限定されない。

【0014】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0015】

第1の態様の第1の実現例に基づいて、第1の態様の第3の実現例において、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、アップグレードパッケージタイプ、アップグレードパッケージ優先度又は端末でのサービスのサービスステータス情報のうちの少なくとも1つに基づいて端末のソフトウェアアップグレードプロシージャをサーバがターゲットアップグレードモードで実行することは以下のステップを含む。

【0016】

端末でのサービスのサービスステータスをサービスステータス情報からサーバが取得する。

【0017】

アップグレードパッケージタイプが既定のタイプでありかつサービスステータスが非アップグレード状態である場合に指示情報をサーバが端末に送り、この指示情報は、サービスを中止するように端末に命令するのに用いられる。

【0018】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0019】

既定のタイプはセキュリティタイプであってもよい。アップグレードパッケージタイプがセキュリティタイプでありかつサービスステータスが非アップグレード状態である場合、サーバがサービスを中止するように端末に命令してソフトウェアアップグレードプロシージャを開始してもよい。

【0020】

いくつかの実現例では、アップグレードパッケージタイプが既定のタイプでありかつサービスステータスがアイドル状態である場合に指示情報をサーバが端末に送り、この指示情報は、プリセット時間以内にサービスを中止するように端末に命令するのに用いられる。プリセット時間については、第1の態様の第2の実現例の説明を参照する。

【0021】

いくつかの実現例では、これの代わりに、サービスを中止するように端末デバイスに命令する情報を送るか否かをアップグレードパッケージタイプのみに基づいてサーバが決定してもよい。たとえば、アップグレードパッケージタイプがセキュリティタイプである場合、サーバが指示情報を端末に直ちに送って、端末によって返された肯定応答を受けた後にソフトウェアアップグレードプロシージャを開始してもよい。

【0022】

第1の態様の第3の実現例に基づいて、第1の態様の第4の実現例において、指示情報は第1の時間又は既定の識別子を含んでもよい。第1の時間は、端末がサービスを中止してソフトウェアアップグレードプロシージャを実行する応答時間である。既定の識別子は、端末が指示情報を受けるときにサービスを中止するように端末に命令するのに用いられる。

【0023】

たとえば、アップグレードパッケージタイプがセキュリティタイプでありかつサービスステータスが非アップグレード状態である場合、サーバが端末に10秒を示し、10秒以内にサービスを中止して10秒後にソフトウェアアップグレードプロシージャを開始するように端末に命令してもよい。

【0024】

別の例では、アップグレードパッケージタイプがセキュリティタイプでありかつサービスステータスが非アップグレード状態である場合、サーバは端末に既定の識別子を示し、既定の識別子を端末が受けた直後にサービスを中止してソフトウェアアップグレードプロシージャを開始するように端末に命令してもよい。

【0025】

指示情報を用いることでソフトウェアアップグレードプロシージャの自動スケジューリングが実行されることが可能であり、人の介在が必要とされないことが分かる。

【0026】

第1の態様の第1の実現例に基づいて、第1の態様の第5の実現例において、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、アップグレードパッケージタイプ、アップグレードパッケージ優先度又は端末でのサービスのサービスステータス情報のうちの少なくとも1つに基づいて端末のソフトウェアアップグレードプロシージャをサーバがターゲットアップグレードモードで実行することは以下のステップを含む。

【0027】

端末でのサービスのサービス優先度をサービスステータス情報からサーバが取得する。

【0028】

サーバが、アップグレードパッケージ優先度がサービス優先度よりも高いと判断する場合に指示情報を端末に送り、この指示情報は、サービスを中止するように端末に命令するのに用いられる。

【0029】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0030】

サービス優先度とアップグレードパッケージ優先度とを比較することによってアップグレードパッケージの重要度が考慮されることが分かる。これにより、端末のアップグレードプロシージャと端末でのサービスとのコンフリクトが避けられる。

【0031】

第1の態様の第1の実現例に基づいて、第1の態様の第6の実現例において、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、アップグレードパッケージタイプ、アップグレードパッケージ優先度又は端末でのサービスのサービスステータス情報のうちの少なくとも1つに基づいて端末のソフトウェアアップグレードプロシージャをサーバがターゲットアップグレードモードで実行することは以下のステップを含む。

【0032】

サービス優先度と端末でのサービスのサービスステータスとをサービスステータス情報からサーバが取得する。

【0033】

アップグレードパッケージ優先度がサービス優先度よりも高くかつサービスステータスがアイドル状態であると判断する場合にサーバが指示情報を端末に送り、この指示情報は、サービスを中止するように端末に命令するのに用いられる。

【0034】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0035】

いくつかの実現例では、サービス優先度及びサービスステータスを取得した後、アップグレードパッケージ優先度がサービス優先度よりも高くかつサービスステータスが非アップグレード状態であると判断する場合、サーバが端末に指示情報を送る。指示情報は、プリセット時間以内にサービスを中止するように端末に命令するのに用いられる。この場合、ソフトウェアアップグレードプロシージャを開始する時期がサービス優先度、アップグレードパッケージ優先度及びサービスステータスを考慮することによって決定されることが分かる。これにより、サービス優先度とアップグレードパッケージ優先度との差を考慮するだけで、アップグレードプロシージャを直ちに開始することによって起こるサービスの中断を避けることができる。

【0036】

第1の態様の第1の実現例に基づいて、第1の態様の第7の実現例において、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、アップグレードパッケージタイプ、アップグレードパッケージ優先度又は端末でのサービスのサービスステータス情報のうちの少なくとも1つに基づいて端末のソフトウェアアップグレードプロシージャをサーバがターゲットアップグレードモードで実行することは以下のステップを含む。

【0037】

サービス優先度と端末でのサービスのサービスステータスとをサービスステータス情報からサーバが取得する。

【0038】

アップグレードパッケージ優先度がサービス優先度よりも高くかつアップグレードパッケージタイプが非既定のタイプであり、かつサービスステータスがアイドル状態又は非アップグレード状態であると判断する場合にサーバが端末に指示情報を送り、この指示情報は、サービスを中止するように端末に命令するのに用いられる。

【0039】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0040】

サービス優先度、アップグレードパッケージ優先度、アップグレードパッケージタイプ及びサービスステータスを考慮することによってソフトウェアアップグレードプロシージャを開始する時期が決定されることが分かる。これにより、ソフトウェアアップグレードプロシージャを開始する時期の決定をさらに向上させることができ、より細かい粒度でスケジューリングを実現することができる。

【0041】

第1の態様の第1の実現例に基づいて、第1の態様の第8の実現例において、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、アップグレードパッケージタイプ、アップグレードパッケージ優先度又は端末でのサービスのサービスステータス情報のうちの少なくとも1つに基づいて端末のソフトウェアアップグレードプロシージャをサーバがターゲットアップグレードモードで実行することは以下のステップを含む。

【0042】

サービス優先度と端末でのサービスのサービスステータスとをサービスステータス情報からサーバが取得する。

【0043】

アップグレードパッケージ優先度がサービス優先度よりも高くなくかつサービスステータスがアイドル状態又は非アップグレード状態であると判断する場合、サービスを中止するように端末に指示するのに用いられる指示情報をサーバが端末に送る。

【0044】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0045】

アップグレードパッケージ優先度がサービス優先度よりも高くないときにはソフトウェアアップグレードプロシージャを開始する最適な時期になっていないことが分かる。サーバは端末のサービスステータスのアップデート版をリアルタイムで取得し、次いでその都度取得されるアップデートされたサービスステータスに基づいて、ソフトウェアアップグレードプロシージャを開始する時期になったか否かを判断してもよい。サーバによって取得されたアップデートされたサービスステータスがアイドルである場合、サーバがサービスを中止するように端末に命令してソフトウェアアップグレードプロシージャを実行してもよい。これの代わりに、サーバによって取得されたアップデートされたサービスステータスが非アップグレード状態である場合、サービスを中止したりプリセット時間以内にサービスを中止したりするようにサーバが端末に命令してもよい。動的な比較及び判断を通じて、アップグレードの自動スケジューリングをサーバが実行することができる。これにより、アップグレードパッケージ優先度がサービス優先度よりも高くないと判断される場合にソフトウェアアップグレードプロシージャが開始されないことが避けられる。

【0046】

第1の態様に基づいて、第1の態様の第9の実現例において、ターゲットアップグレードモードが端末判断型アップグレードモードである場合、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行するステップは以下のステップを含む。

【0047】

アップグレードパッケージ優先度を端末にサーバが送り、アップグレードパッケージ優先度は、ソフトウェアアップグレードプロシージャを開始するか否かをアップグレードパッケージ優先度及びサービス優先度に基づいて判断するのに端末によって用いられる。

【0048】

アップグレード要求を端末から受けた後、アップグレード要求をサーバが承認して端末のソフトウェアアップグレードプロシージャを実行する。

【0049】

端末判断型アップグレードモードでは、サーバが端末にアップグレードパッケージ優先度を提供して、ソフトウェアアップグレードプロシージャを開始するか否かを端末が判断する根拠を与えることが分かる。

【0050】

第1の態様に基づいて、第1の態様の第10の実現例において、ターゲットアップグレードモードがネゴシエート型アップグレードモードである場合、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行するステップは以下のステップを含む。

【0051】

アップグレードパッケージ優先度を端末にサーバが送り、アップグレードパッケージ優先度は、ソフトウェアアップグレードプロシージャを開始するか否かをアップグレードパッケージ優先度及びサービスステータスに基づいて判断するのに端末によって用いられる。

【0052】

待機持続時間を搬送する肯定応答を端末からサーバが受ける。

【0053】

タイミング持続時間が待機持続時間を超えた後に端末のソフトウェアアップグレードプロシージャをサーバが開始する。

【0054】

ネゴシエート型アップグレードモードでは、サーバが端末にアップグレードパッケージ優先度を提供して、ソフトウェアアップグレードプロシージャを開始するか否かを端末が判断する根拠を与えることが分かる。さらに、端末によって返される待機持続時間に基づいてソフトウェアアップグレードプロシージャをサーバが自動的に開始し、重ねてアップグレード要求を端末が開始する必要はない。本実現例は、端末での現在のサービスを終了させたり中断させたりすることが不適当であるシナリオに特に適用可能である。

【0055】

第1の態様の第1の実現例に基づいて、第1の態様の第11の実現例において、方法は以下をさらに含む。

【0056】

サーバはアップグレードパッケージ優先度を以下の仕方、すなわち、
アップグレードパッケージのメタデータからアップグレードパッケージ優先度をサーバが取得する、
又はアップグレードパッケージの記述ファイルからアップグレードパッケージ優先度をサーバが取得する、
又はアップグレードパッケージの提供元からアップグレードパッケージ優先度をサーバが取得する、
又はローカルポリシに従ってアップグレードパッケージ優先度をサーバが決定する、
ことのうちの少なくとも1つで取得する。

【0057】

本出願の第2の態様はソフトウェアアップグレード管理方法を提供し、方法は以下のステップを含む。

【0058】

端末において設定されているアップグレードモードをサーバに端末が送り、端末において設定されているアップグレードモードは、端末のターゲットアップグレードモードを決定するのにサーバによって用いられ、ターゲットアップグレードモードは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含む。

【0059】

アップグレードパッケージをサーバから端末が取得し、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行する。

【0060】

既存の機構と比較して、本出願の端末は、設定されているアップグレードモードをサーバに提供して、ターゲットアップグレードモードをサーバが決定する根拠を与え、これにより、サーバによって決定されたターゲットアップグレードモードに基づいてソフトウェアアップグレードプロシージャが自動的に実行されることが可能であることで、アップグレードの無人自動スケジューリングを実施する。

【0061】

第2の態様に基づいて、第2の態様の第1の実現例において、ターゲットアップグレードモードが端末判断型アップグレードモードである場合、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行するステップは以下のステップを含む。

【0062】

端末がアップグレードパッケージ優先度をサーバから取得し、ソフトウェアアップグレードプロシージャを開始するためにアップグレードパッケージ優先度及び端末でのサービスのサービス優先度に基づいて判断した後にアップグレード要求をサーバに送る。

【0063】

肯定応答をサーバから受けた後、アップグレードパッケージをサーバから端末が取得してソフトウェアアップグレードプロシージャを開始する。

【0064】

第2の態様に基づいて、第2の態様の第2の実現例において、ターゲットアップグレードモードがネゴシエーションアップグレードモードである場合、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行するステップは以下のステップを含む。

【0065】

端末がアップグレードパッケージ優先度をサーバから取得し、ソフトウェアアップグレードプロシージャを開始するまでの待機持続時間をアップグレードパッケージ優先度とサービス優先度と端末でのサービスのサービスステータスとに基づいて決定した後、待機持続時間を搬送する肯定応答をサーバに送る。

【0066】

タイミング持続時間が待機持続時間を超えた後、アップグレードパッケージをサーバから端末が取得してソフトウェアアップグレードプロシージャを実行する。

【0067】

第2の態様に基づいて、第2の態様の第1の実現例において、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行するステップは以下のステップを含む。

【0068】

端末でのサービスのサービスステータス情報をサーバに端末が送り、サービスステータス情報は、サービス優先度又は端末でのサービスのサービスステータスのうちの少なくとも一方を判断するのにサーバによって用いられる。

【0069】

サービスを中止するように端末に命令するのに用いられる指示情報をサーバから受けた後、アップグレードパッケージをサーバから端末が取得して端末のソフトウェアアップグレードプロシージャを実行する。

【0070】

本出願の第3の態様は、第1の態様で提供されているソフトウェアアップグレード管理方法に対応する方法を実施する機能を持つサーバを提供する。機能はハードウェアによって実施されてもよいし、対応するソフトウェアを実行するハードウェアによって実施されてもよい。ハードウェア又はソフトウェアは上記の機能に対応する1つ以上のモジュールを含み、モジュールはソフトウェア及び／又はハードウェアであってもよい。

【0071】

いくつかの実現例では、サーバは、
アップグレードパッケージを取得するように構成されている送受信器モジュールと、
処理モジュールであって、端末のターゲットアップグレードモードを決定し、ターゲットアップグレードモードは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含み、
アップグレードパッケージを端末に送受信器モジュールを用いて送って、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行する、ように構成されている処理モジュールと、
を含む。

【0072】

いくつかの実現例では、処理モジュールは以下を含む。

【0073】

【0074】

いくつかの実現例では、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、処理モジュールは、
端末でのサービスのサービスステータスをサービスステータス情報から送受信器モジュールを用いて取得し、
端末のサービスステータスがアイドル状態又は非アップグレード状態であると判断する場合に指示情報を端末に送受信器モジュールを用いて送り、指示情報は、プリセット時間以内にサービスを中止するように端末に命令するのに用いられ、
肯定応答を端末から送受信器モジュールが受けた後にソフトウェアアップグレードプロシージャを開始する、
ように構成されている。

【0075】

いくつかの実現例では、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、処理モジュールは、
端末でのサービスのサービスステータスをサービスステータス情報から送受信器モジュールを用いて取得し、
アップグレードパッケージタイプが既定のタイプでありかつサービスステータスが非アップグレード状態である場合に指示情報を端末に送受信器モジュールを用いて送り、指示情報は、サービスを中止するように端末に命令するのに用いられ、
肯定応答を端末から送受信器モジュールが受けた後にソフトウェアアップグレードプロシージャを開始する、
ように構成されている。

【0076】

いくつかの実現例では、指示情報は第1の時間又は既定の識別子を含む。第1の時間は、端末がサービスを中止してソフトウェアアップグレードプロシージャを実行する応答時間である。既定の識別子は、端末が指示情報を受けるときにサービスを中止するように端末に命令するのに用いられる。

【0077】

いくつかの実現例では、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、処理モジュールは、
端末でのサービスのサービス優先度をサービスステータス情報から送受信器モジュールを用いて取得し、
アップグレードパッケージ優先度がサービス優先度よりも高いと判断する場合に指示情報を端末に送受信器モジュールを用いて送り、指示情報は、サービスを中止するように端末に命令するのに用いられ、
肯定応答を送受信器モジュールが端末から受けた後にソフトウェアアップグレードプロシージャを開始する、
ように構成されている。

【0078】

いくつかの実現例では、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、処理モジュールは、
サービス優先度と端末でのサービスのサービスステータスとをサービスステータス情報から送受信器モジュールを用いて取得し、
アップグレードパッケージ優先度がサービス優先度よりも高くかつサービスステータスがアイドル状態であると判断する場合に指示情報を端末に送受信器モジュールを用いて送り、指示情報は、サービスを中止するように端末に命令するのに用いられ、
肯定応答を送受信器モジュールが端末から受けた後にソフトウェアアップグレードプロシージャを開始する、
ように構成されている。

【0079】

いくつかの実現例では、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、処理モジュールは、
サービス優先度と端末でのサービスのサービスステータスとをサービスステータス情報から送受信器モジュールを用いて取得し、
アップグレードパッケージ優先度がサービス優先度よりも高くかつアップグレードパッケージタイプが非既定のタイプでありかつサービスステータスがアイドル状態又は非アップグレード状態であると判断する場合に指示情報を端末に送受信器モジュールを用いて送り、指示情報は、サービスを中止するように端末に命令するのに用いられ、
肯定応答を送受信器モジュールが端末から受けた後にソフトウェアアップグレードプロシージャを開始する、
ように構成されている。

【0080】

いくつかの実現例では、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、処理モジュールは、
サービス優先度と端末でのサービスのサービスステータスとをサービスステータス情報から送受信器モジュールを用いて取得し、
アップグレードパッケージ優先度がサービス優先度よりも高くなくかつサービスステータスがアイドル状態又は非アップグレード状態であると判断する場合、サービスを中止するように端末に命令するのに用いられる指示情報を端末に送受信器モジュールを用いて送り、
肯定応答を端末から送受信器モジュールが受けた後にソフトウェアアップグレードプロシージャを開始する、
ように構成されている。

【0081】

いくつかの実現例では、ターゲットアップグレードモードが端末判断型アップグレードモードである場合、処理モジュールは、
アップグレードパッケージ優先度を端末に送受信器モジュールを用いて送り、アップグレードパッケージ優先度は、ソフトウェアアップグレードプロシージャを開始するか否かをアップグレードパッケージ優先度及びサービス優先度に基づいて判断するのに端末によって用いられ、
アップグレード要求を端末から送受信器モジュールが受けた後、アップグレード要求を承認して端末のソフトウェアアップグレードプロシージャを実行する、
ように構成されている。

【0082】

いくつかの実現例では、ターゲットアップグレードモードがネゴシエート型アップグレードモードである場合、処理モジュールは、
アップグレードパッケージ優先度を端末に送受信器モジュールを用いて送り、アップグレードパッケージ優先度は、ソフトウェアアップグレードプロシージャを開始するか否かをアップグレードパッケージ優先度及びサービスステータスに基づいて判断するのに端末によって用いられ、
待機持続時間を搬送する肯定応答を端末から送受信器モジュールを用いて受け、
タイミング持続時間が待機持続時間を超えた後に端末のソフトウェアアップグレードプロシージャを開始する、
ように構成されている。

【0083】

本出願の第4の態様は、第2の態様で提供されているソフトウェアアップグレード管理方法に対応する方法を実施する機能を持つ端末を提供する。機能はハードウェアによって実施されてもよいし、対応するソフトウェアを実行するハードウェアによって実施されてもよい。ハードウェア又はソフトウェアは上記の機能に対応する1つ以上のモジュールを含み、モジュールはソフトウェア及び／又はハードウェアであってもよい。

【0084】

いくつかの実現例では、端末は、
端末において設定されているアップグレードモードをサーバに送り、端末において設定されているアップグレードモードは、端末のターゲットアップグレードモードを決定するのにサーバによって用いられ、ターゲットアップグレードモードは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含む、ように構成されている送受信器モジュールと、
アップグレードパッケージをサーバから送受信器モジュールが取得した後にターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行するように構成されている処理モジュールと、
を含む。

【0085】

いくつかの実現例では、ターゲットアップグレードモードが端末判断型アップグレードモードである場合、処理モジュールは、
アップグレードパッケージ優先度をサーバから送受信器モジュールを用いて取得し、
ソフトウェアアップグレードプロシージャを開始することをアップグレードパッケージ優先度及び端末でのサービスのサービス優先度に基づいて判断した後にアップグレード要求をサーバに送受信器モジュールを用いて送り、
肯定応答をサーバから送受信器モジュールが受けた後、アップグレードパッケージをサーバから取得してソフトウェアアップグレードプロシージャを開始する、
ように構成されている。

【0086】

いくつかの実現例では、ターゲットアップグレードモードがネゴシエーションアップグレードモードである場合、処理モジュールは、
アップグレードパッケージ優先度をサーバから送受信器モジュールを用いて取得し、
ソフトウェアアップグレードプロシージャを開始するまでの待機持続時間をアップグレードパッケージ優先度とサービス優先度と端末でのサービスのサービスステータスとに基づいて決定した後、待機持続時間を搬送する肯定応答をサーバに送受信器モジュールを用いて送り、
タイミング持続時間が待機持続時間を超えた後、アップグレードパッケージをサーバから送受信器モジュールを用いて取得してソフトウェアアップグレードプロシージャを実行する、
ように構成されている。

【0087】

いくつかの実現例では、ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、処理モジュールは、
端末でのサービスのサービスステータス情報をサーバに送受信器モジュールを用いて送り、サービスステータス情報は、サービス優先度又は端末でのサービスのサービスステータスのうちの少なくとも一方を判断するのにサーバによって用いられ、
サービスを中止するように端末に命令するのに用いられる指示情報をサーバから送受信器モジュールが受けた後、アップグレードパッケージをサーバから送受信器モジュールを用いて取得して端末のソフトウェアアップグレードプロシージャを実行する、
ように構成されている。

【0088】

本出願のさらに別の態様は、少なくとも1つの接続されたプロセッサ、メモリ、送信器及び受信器を含むコンピュータ装置を提供し、メモリは、プログラムコードを記憶するように構成されており、プロセッサは、メモリ中のプログラムコードを呼び出して、上記の態様のサーバによって実行される動作又は上記の態様の端末によって実行される動作を実行するように構成されている。

【0089】

本出願のさらに別の態様はコンピュータ装置を提供し、コンピュータ装置は、
少なくとも1つのプロセッサ、少なくとも1つのメモリ及び少なくとも1つの送受信器を含み、
メモリは、プログラムコードを記憶するように構成されており、プロセッサは、メモリ中のプログラムコードを呼び出して、第1の態様のサーバによって実行される動作又は第2の態様の端末によって実行される動作を実行するように構成されている。

【0090】

送受信器が受信器及び送信器と置換されることも行なってもよく、受信器及び送信器が同じ物理的実在物であっても異なる物理的実在物であってもよい。同じ物理的実在物であるとき、受信器と送信器とがまとめて送受信器と称されてもよい。メモリがプロセッサに組み込まれてもよいし、プロセッサとは別体であってもよい。

【0091】

本出願のさらに別の態様は、命令を含むコンピュータ記憶媒体を提供する。命令がコンピュータ上で動作するとき、コンピュータが第1の態様の動作又は第2の態様の動作を実行することが可能にされる。

【0092】

本出願のさらに別の態様は、命令を含むコンピュータプログラムプロダクトを提供する。コンピュータプログラムプロダクトがコンピュータ上で動作するとき、コンピュータが第1の態様のサーバによって実行される動作又は第2の態様の端末によって実行される動作を実行することが可能にされる。

【図面の簡単な説明】

【0093】

【図1】本出願の実施形態に係るモノのインターネットシステムの概略アーキテクチャ図である。

【図2】本出願の実施形態に係るソフトウェアアップグレード管理方法の概略フローチャートである。

【図3】本出願の実施形態に係る、端末のアップグレードモードの設定の概略フローチャートである。

【図4】本出願の実施形態に係る、サーバ判断型アップグレードモードでのソフトウェアアップグレードプロシージャの実行の概略フローチャートである。

【図5】本出願の実施形態に係る、サーバ判断型アップグレードモードでのソフトウェアアップグレードプロシージャの実行の概略フローチャートである。

【図6】本出願の実施形態に係る、サーバ判断型アップグレードモードでのソフトウェアアップグレードプロシージャの実行の概略フローチャートである。

【図7】本出願の実施形態に係る、ネゴシエーションアップグレードモードでのソフトウェアアップグレードプロシージャの実行の概略フローチャートである。

【図8】本出願の実施形態に係る、端末判断型アップグレードモードでのソフトウェアアップグレードプロシージャの実行の概略フローチャートである。

【図9】本出願の実施形態に係るサーバの概略構成図である。

【図10】本出願の実施形態に係る端末の概略構成図である。

【図11】本出願の実施形態に係る、ソフトウェアアップグレード管理方法を実行するデバイスの概略構成図である。

【図12】本出願の実施形態に係るモノのインターネット端末の概略構成図である。

【図13】本出願の実施形態に係るサーバの別の概略構成図である。

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

【0094】

本出願の明細書、請求項及び添付の図面において、用語「第1」、「第2」などは、同様の物を区別することを意図しているが、特定の順序又は連続することを必ずしも示さない。このように用語を用いて記載されたデータはしかるべき状況で交換可能であり、したがって、本明細書で説明されている実施形態は本出願で図示されていたり記載されていたりする順序とは別の順序で実施されることが可能であると当然解する。これに加えて、「含む（include）」、「有する（have）」又はこれらについてのその他一切の異形は、限定を課さずに含むことをカバーすることを意図している。たとえば、一連のステップ又はモジュールを含むプロセス、方法、システム、プロダクト又はデバイスは明示的に記載されているステップ又はモジュールに必ずしも限定されないが、明示的に記載されていなかったりプロセス、方法、プロダクト又はデバイスに固有であったりする別のステップ又はモジュールを含んでもよい。本出願におけるモジュールの分割は論理的な分割にすぎず、実際の適用での実施の際には別の分割が存在してもよい。たとえば、複数のモジュールが別のシステムに組み入れられたり別のシステムに統合されたりしてもよいし、いくつかの特徴が無視されたり実行されなかったりしてもよい。さらに、表示されていたり説明されていたりする相互接続や直接接続や通信接続がいくつかのインタフェースによって実施されてもよい。モジュール間の間接接続や通信接続が電子的に実施されたり別の形態で実施されたりしてもよく、これは本出願では限定されない。さらに、別体の部分として説明されているモジュールやサブモジュールが物理的に分離されてもされなくてもよいし、物理的なモジュールであってもなくてもよいし、複数の回路モジュールに分散されてもよい。実際の要件に応じてモジュールの一部又は全部を選択することによって本出願の解決手段の目的が達成されてもよい。

【0095】

本出願は、ソフトウェアアップグレード管理方法、サーバ、端末、装置及び記憶媒体を提供し、本出願はモノのインターネット技術の分野に適用されてもよい。以下、図1に示されているモノのインターネットシステムのアーキテクチャ図に基づいて本出願のデバイスを説明する。

【0096】

図1中、モノのインターネットシステムはサーバと複数の端末とを含む。各端末で同じサービスがデプロイされてもよいし、各端末で異なるサービスが別々にデプロイされてもよく、各端末で少なくとも1つのサービスがデプロイされることも行なってもよい。

【0097】

サーバは、これらの端末にクラスタ管理を実行するように構成されており、デプロイされたサービスのタイプに基づいてこれらの端末にクラスタ分割が実行されてもよい。アップグレードパケットを取得した後、サーバはアップグレードされる各端末に対するサブスクリプション要求を最初に開始してアップグレードされる端末でのサービスの中断を防止してもよい。サブスクリプション要求は端末のサービスステータス情報に登録する（subscribe）のに用いられ、サービスステータス情報はサービスのアイドル状態や非アップグレード状態を含んでもよく、サービスタイプ及びサービス優先度などのサービス関連情報をさらに含んでもよい。

【0098】

端末のターゲットアップグレードモードを決定した後、サーバは登録されたサービスステータス情報、アップグレードパッケージ優先度（upgrade package priority）及びアップグレードパッケージタイプなどの情報に基づいて、端末のソフトウェアアップグレードプロシージャを実行する時期を決定してもよい。

【0099】

さらに、これの代わりに、アップグレードパッケージ優先度及びアップグレードパッケージタイプなどの、サーバによって提供される情報に基づいて端末のソフトウェアアップグレードプロシージャを実行する時期を端末が決定してもよい。同じタイプのアップグレードパッケージに基づいてアップグレードされる複数の端末については、端末のソフトウェアアップグレードプロシージャがそれぞれの端末によって異なる時期に実行されてもよい。特に、選択されたターゲットアップグレードモードでソフトウェアアップグレードプロシージャが実行されるのであれば、判断はサーバで行なわれてもアップグレードされる端末で行なわれてもよい。

【0100】

上記の技術的課題を解決するために、本出願は以下の技術的解決手段を提供する。

【0101】

複数の予め設定されているアップグレードモードに基づいて、異なるソフトウェアアップグレードプロシージャを異なるシナリオでサーバが用いる。たとえば、ソフトウェアアップグレードプロシージャが開始されることになっている場合、アップグレードパッケージタイプ、アップグレードパッケージ優先度及びサービスステータス情報などの複数の諸元からソフトウェアアップグレードプロシージャを開始する時期をサーバが決定してもよい。たとえば、ソフトウェアアップグレードプロシージャ時に端末のサービス優先度とアップグレードパッケージ優先度とを比較することによってバッチでの端末の自動アップグレードが実行される。

【0102】

図2は本出願で提供されるソフトウェアアップグレード管理方法を説明している。方法は以下のステップを主に含む。

【0103】

201．アップグレードパッケージをサーバが取得する。

【0104】

アップグレードパッケージは、少なくとも1つのタイプのアップグレードパッケージ、たとえば、セキュリティタイプ、機能タイプ、設定タイプや汎用タイプのアップグレードパッケージを含んでもよい。アップグレードパッケージは、実行スクリプト、実行コードなどを含んでもよい。アップグレードパッケージは、端末のシステムや端末でデプロイされているサービスのアップグレードパッケージであってもよい。これは本出願において特に限定されない。本出願の本実施形態では、サーバは端末のシステム又はサービスのソフトウェアアップグレードプロシージャを別々に実行してもよいし、システム及びサービスのソフトウェアアップグレードプロシージャを同時に実行してもよい。

【0105】

いくつかの実現例では、サーバはアップグレードパッケージ優先度情報をさらに取得した後、優先度情報に基づいてアップグレードパッケージ優先度を決定してもよく、この優先度情報はアップグレードパッケージ優先度を明示的に示したり黙示的に示したりしてもよい。サーバはアップグレードパッケージ優先度を以下の仕方、すなわち、
アップグレードパッケージのメタデータからアップグレードパッケージ優先度をサーバが取得する、
又はアップグレードパッケージの記述ファイルからアップグレードパッケージ優先度をサーバが取得する、
又はアップグレードパッケージの提供元からアップグレードパッケージ優先度をサーバが取得する、
又はローカルポリシに従ってアップグレードパッケージ優先度をサーバが決定する、
ことのうちの少なくとも1つで取得する。

【0106】

いくつかの実現例では、サーバによって取得される少なくとも2つのタイプのアップグレードパッケージが存在する場合、ローカルポリシに従ってサーバがアップグレードパッケージ優先度を決定することは以下を含んでもよい。

【0107】

少なくとも2つのタイプのアップグレードパッケージが存在する場合、これらのタイプの優先度が比較されてもよく、少なくとも2つのタイプのアップグレードパッケージのうちの最高の優先度を持つアップグレードパッケージがアップグレードパッケージ優先度（upgrade package priority）として用いられる。たとえば、セキュリティタイプ及び設定タイプのアップグレードパッケージが含まれる場合、アップグレードパッケージ優先度がセキュリティレベルであるとサーバが判断してもよい。

【0108】

202．端末のターゲットアップグレードモードをサーバが決定する。

【0109】

ターゲットアップグレードモードは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含む。

【0110】

ステップ201の前で、端末で設定されているアップグレードモードをサーバが取得することがさらに必要である。図3の実施形態に示されているように、主要な取得の仕方は以下のステップを含んでもよい。

【0111】

1．端末が登録されることに成功した後、サーバが端末に対するリソースディスカバリ動作を開始して、アップグレードモードが端末で設定されているか否かを検出してもよい。

【0112】

2a．アップグレードモードが端末で設定されている場合、設定されているアップグレードモードを端末がサーバに送る。

【0113】

このようにして、端末で設定されているアップグレードモードに基づいてターゲットアップグレードモードをサーバが決定してもよい。

【0114】

2b．アップグレードモードが端末で設定されていない場合、所定の応答を端末がサーバに返す。

【0115】

3b．端末に対するアップグレードモードネゴシエーション要求をサーバが開始する。

【0116】

アップグレードモードネゴシエーション要求はアップグレードモードリストを搬送してもよく、このアップグレードモードリストは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含んでもよい。

【0117】

4b．アップグレードモードネゴシエーション要求を受けた後、端末が端末によってサポートされるアップグレードモードを選択し、アップグレードモード設定を完了し、選択されたアップグレードモードをサーバに返す。

【0118】

端末が少なくとも1つのアップグレードモードを選択して、少なくとも1つのアップグレードモードをサーバにアップグレードモードネゴシエーション応答を用いて送ってもよい。アップグレードモードネゴシエーション応答を受けた後、アップグレードモードネゴシエーション応答中で搬送されたアップグレードモードに基づいてターゲットアップグレードモードをサーバが決定してもよい。

【0119】

いくつかの実現例では、アップグレードモードが端末で設定されていない場合、サーバが端末のターゲットアップグレードモードとしてサーバ判断型アップグレードモードを直接決定して、サーバ判断型アップグレードモードで端末のソフトウェアアップグレードプロシージャを実行してもよい。

【0120】

いくつかの実現例では、アップグレードモードが端末で設定されていない場合、端末に対するアップグレードモードネゴシエーション要求をサーバが開始してもよく、このアップグレードモードネゴシエーション要求はアップグレードモードリストを搬送してもよく、アップグレードモードリストは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含んでもよい。所定の応答を端末からサーバが受け、この応答がアップグレードモードを搬送していない場合、サーバが端末のターゲットアップグレードモードとしてサーバ判断型アップグレードモードを直接決定して、サーバ判断型アップグレードモードで端末のソフトウェアアップグレードプロシージャを実行してもよい。

【0121】

203．サーバがアップグレードパッケージを端末に送って、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行する。

【0122】

204．端末がアップグレードパッケージをサーバから取得して、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行する。

【0123】

いくつかの実現例では、アップグレードパッケージタイプ、アップグレードパッケージ優先度及び端末でのサービスのサービスステータス情報をサーバがさらに取得してもよい。サービスステータス情報はサービスステータス及びサービス優先度のうちの少なくとも1つを含んでもよい。たとえば、サービスステータスはサービスのアイドル状態又は非アップグレード状態を含んでもよい。たとえば、サービスステータスは、サービスが端末で運用中であるか否かや、以前のソフトウェアアップグレードプロシージャが実行中であるか否か（たとえば、システムアップグレードやサービスアップグレードが端末に対して実行中である）を特に示してもよい。

【0124】

ターゲットアップグレードモードでは、アップグレードパッケージタイプ、アップグレードパッケージ優先度又は端末でのサービスのサービスステータス情報のうち少なくとも1つに基づいて端末のソフトウェアアップグレードプロシージャをサーバが実行してもよい。

【0125】

本出願の本実施形態では、ターゲットアップグレードモードを決定した後、決定されたターゲットアップグレードモードに基づいてソフトウェアアップグレードプロシージャをサーバが自動的に実行し、したがって、アップグレードの無人自動スケジューリングが実行されることが可能であり、アップグレードパッケージタイプ、アップグレードパッケージ優先度及びサービスステータス情報などの複数の諸元からソフトウェアアップグレードプロシージャを開始する時期が決定されることが可能である。

【0126】

オプションとして、本出願のいくつかの実施形態では、ターゲットアップグレードモードがそれぞれサーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードである場合のサーバと端末との間で実行されるソフトウェアアップグレードプロシージャを以下説明する。

【0127】

I．ターゲットアップグレードモードがサーバ判断型アップグレードモードである場合、ソフトウェアアップグレードプロシージャは主に以下のシナリオをカバーする。

【0128】

1．ソフトウェアアップグレードプロシージャを開始する時期をサービスステータスに基づいて決定する。

【0129】

端末でのサービスのサービスステータスをサービスステータス情報からサーバが取得する。

【0130】

【0131】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0132】

本出願では、サービスステータスに基づいてアップグレード時期が決定されることが分かる。これにより、アップグレードパケットが受信された後にソフトウェアアップグレードプロシージャが直ちに実行される場合の、端末で現在実行されているサービスの中断や、以前のソフトウェアアップグレードプロシージャが現在完了していない（たとえば、端末に対してシステムアップグレードやサービスアップグレードが実行中である）ときの、端末の以前のソフトウェアアップグレードプロシージャの中断を避けることができる。

【0133】

2．ソフトウェアアップグレードプロシージャを開始する時期をアップグレードパッケージタイプに基づいて決定する。

【0134】

図4に示されているように、実施形態は以下のステップを含んでもよい。

【0135】

401．サーバがアップグレードパッケージを取得して、ターゲットアップグレードモードとしてサーバ判断型アップグレードモードを決定する。

【0136】

402．端末でのサービスのサービスステータスをサービスステータス情報からサーバが取得する。

【0137】

403．アップグレードパッケージタイプが既定のタイプでありかつサービスステータスが非アップグレード状態である場合に指示情報をサーバが端末に送り、この指示情報は、サービスを中止するように端末に命令するのに用いられる。

【0138】

404．指示情報を受けた後、端末がサービスを中止して肯定応答をサーバに送る。

【0139】

405．サーバが端末から肯定応答を受けた後にソフトウェアアップグレードプロシージャを開始する。

【0140】

【0141】

いくつかの実現例では、アップグレードパッケージタイプが既定のタイプでありかつサービスステータスがアイドル状態である場合に指示情報をサーバが端末に送り、この指示情報は、プリセット時間以内にサービスを中止するように端末に命令するのに用いられる。プリセット時間については上記の説明を参照する。

【0142】

いくつかの実現例では、指示情報は第1の時間又は既定の識別子を含んでもよい。第1の時間は、端末がサービスを中止してソフトウェアアップグレードプロシージャを実行する応答時間である。既定の識別子は、端末が指示情報を受けるときにサービスを中止するように端末に命令するのに用いられる。

【0143】

【0144】

【0145】

【0146】

指示情報を用いることでソフトウェアアップグレードプロシージャの自動スケジューリングが実行されることが可能であり、人の介在が必要とされないことが分かる。さらに、アップグレードパッケージタイプ及びサービスステータスに基づいてアップグレード時期をサーバが決定する場合、アップグレードパッケージが受信された直後にソフトウェアアップグレードプロシージャを実行することによって現在のサービス又は以前のソフトウェアアップグレードプロシージャが中断されることが避けられることが可能である。

【0147】

3．サービス優先度とアップグレードパッケージ優先度とを比較することによってソフトウェアアップグレードプロシージャを開始する時期を決定する。

【0148】

（a）端末でのサービスのサービス優先度をサービスステータス情報からサーバが取得する。

【0149】

【0150】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0151】

【0152】

（b）サービス優先度と端末でのサービスのサービスステータスとをサービスステータス情報からサーバが取得する。

【0153】

【0154】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0155】

【0156】

いくつかの実現例では、さらに、サービス優先度及びアップグレードパッケージ優先度のみに基づいてソフトウェアアップグレードプロシージャを開始する時期をサーバが決定してもよい。図5に示されているように、実施形態は以下のステップを含んでもよい。

【0157】

501．サーバがアップグレードパッケージ優先度を取得して、ターゲットアップグレードモードとしてサーバ判断型アップグレードモードを決定する。

【0158】

502．サブスクリプション要求をサーバが端末に送り、このサブスクリプション要求は端末のサービスステータス情報に登録するのに用いられる。

【0159】

503．サブスクリプション応答を端末がサーバに返す。

【0160】

504．サービスのサービスステータス情報を端末からサーバが取得する。

【0161】

505．サーバがサービスステータス情報からサービス優先度を取得して、アップグレードパッケージ優先度とサービス優先度とを比較する。

【0162】

506．サーバがサービス優先度がアップグレードパッケージ優先度よりも低い場合に指示情報を端末に送る。

【0163】

507．端末が指示情報を受けた後にサービスを中止する。

【0164】

508．肯定応答を端末がサーバに返す。

【0165】

509．サーバが端末にアップグレードパッケージを送ってソフトウェアアップグレードプロシージャを開始する。

【0166】

4．ソフトウェアアップグレードプロシージャを開始する時期をサービス優先度及びサービスステータスに基づいて決定する。

【0167】

（a）サービス優先度と端末でのサービスのサービスステータスとをサービスステータス情報からサーバが取得する。

【0168】

アップグレードパッケージ優先度がサービス優先度よりも高くかつアップグレードパッケージタイプが既定のタイプではなくかつサービスステータスがアイドル状態又は非アップグレード状態であると判断する場合にサーバが端末に指示情報を送り、この指示情報は、サービスを中止するように端末に命令するのに用いられる。

【0169】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0170】

【0171】

いくつかの実現例では、さらに、サービス優先度及びアップグレードパッケージ優先度のみに基づいてソフトウェアアップグレードプロシージャの時期をサーバが決定してもよい。図6に示されているように、実施形態は以下のステップを含んでもよい。

【0172】

601．サーバがアップグレードパッケージ優先度を取得して、ターゲットアップグレードモードとしてサーバ判断型アップグレードモードを決定する。

【0173】

602．サブスクリプション要求をサーバが端末に送り、このサブスクリプション要求は端末のサービスステータス情報に登録するのに用いられる。

【0174】

603．サブスクリプション応答を端末がサーバに返す。

【0175】

604．サービスのサービスステータス情報を端末からサーバが取得する。

【0176】

605．サーバがサービスステータス情報からサービス優先度を取得して、アップグレードパッケージ優先度とサービス優先度とを比較する。

【0177】

607．サービス優先度がアップグレードパッケージ優先度よりも高い場合、アップデートされたサービスステータス情報を端末からサーバが取得し続ける。

【0178】

608．サービスステータス情報中のサービスステータスがアイドル状態又は非アップグレード状態である場合に指示情報を端末に送る。

【0179】

609．端末が指示情報を受けた後、プリセット時間以内にサービスを中止する。

【0180】

610．肯定応答を端末がサーバに返す。

【0181】

611．サーバが端末にアップグレードパッケージを送ってソフトウェアアップグレードプロシージャを開始する。

【0182】

（b）サービス優先度と端末でのサービスのサービスステータスとをサービスステータス情報からサーバが取得する。

【0183】

【0184】

肯定応答を端末から受けた後、ソフトウェアアップグレードプロシージャをサーバが開始する。

【0185】

アップグレードパッケージ優先度がサービス優先度よりも高くないときにはソフトウェアアップグレードプロシージャを開始する最適な時期になっていないことが分かる。サーバは端末のサービスステータスのアップデート版をリアルタイムで取得した後、その都度取得されるアップデートされたサービスステータスに基づいて、ソフトウェアアップグレードプロシージャを開始する時期になったか否かを判断してもよい。サーバによって取得されたアップデートされたサービスステータスがアイドルである場合、サーバがサービスを中止するように端末に命令してソフトウェアアップグレードプロシージャを実行してもよい。これの代わりに、サーバによって取得されたアップデートされたサービスステータスが非アップグレード状態である場合、サービスを中止したりプリセット時間以内にサービスを中止したりするようにサーバが端末に命令してもよい。動的な比較及び判断を通じて、アップグレードの自動スケジューリングをサーバが実行することができる。これにより、アップグレードパッケージ優先度がサービス優先度よりも高くないと判断される場合にソフトウェアアップグレードプロシージャが開始されないことが避けられる。

【0186】

II．ターゲットアップグレードモードがネゴシエート型アップグレードモードである。

【0187】

図7に示されているように、実施形態は以下のステップを含んでもよい。

【0188】

701．アップグレードパッケージ優先度をサーバが端末に送り、このアップグレードパッケージ優先度は、アップグレードパッケージ優先度及びサービスステータスに基づいて、ソフトウェアアップグレードプロシージャを開始するか否かを判断するのに端末によって用いられる。

【0189】

702．アップグレードパッケージ優先度をサーバから端末が取得して、ソフトウェアアップグレードプロシージャを開始するまでの待機持続時間をアップグレードパッケージ優先度とサービス優先度と端末でのサービスのサービスステータスとに基づいて決定した後に待機持続時間を搬送する肯定応答をサーバに送る。たとえば、待機持続時間は1時間に設定されてもよい。

【0190】

703．待機持続時間を搬送する肯定応答を端末からサーバが受ける。

【0191】

704．タイミング持続時間が待機持続時間を超えた後、端末のソフトウェアアップグレードプロシージャをサーバが開始する。

【0192】

705．端末がサーバからアップグレードパッケージを取得してソフトウェアアップグレードプロシージャを実行する。

【0193】

【0194】

III．ターゲットアップグレードモードが端末判断型アップグレードモードである。

【0195】

図8に示されているように、実施形態は以下のステップを含んでもよい。

【0196】

801．アップグレードパッケージ優先度をサーバが端末に送り、このアップグレードパッケージ優先度は、アップグレードパッケージ優先度及びサービス優先度に基づいて、ソフトウェアアップグレードプロシージャを開始するか否かを判断するのに端末によって用いられる。

【0197】

802．アップグレードパッケージ優先度をサーバから端末が取得して、ソフトウェアアップグレードプロシージャを開始するために、アップグレードパッケージ優先度と端末でのサービスのサービス優先度とに基づいて判断した後にアップグレード要求をサーバに送る。

【0198】

803．端末からアップグレード要求を受けてこれを承認した後、肯定応答をサーバが端末に送って端末のソフトウェアアップグレードプロシージャを実行する。

【0199】

804．これに対応して、肯定応答をサーバから受けた後、端末がサーバからアップグレードパッケージを取得してソフトウェアアップグレードプロシージャを開始する。

【0200】

【0201】

さらに、端末判断型アップグレードモードでは、アップグレードパッケージタイプをサーバが端末にさらに送ってもよく、アップグレードパッケージタイプ（サービスステータスと組み合わされることもしてもよい）に基づいて、ソフトウェアアップグレードプロシージャを開始する時期を端末が決定してもよい。これの代わりに、端末判断型アップグレードモードでは、さらに、アップグレード要求のみをサーバが端末に送ってもよく、このアップグレード要求はアップグレードパッケージ優先度やアップグレードパッケージタイプなどの情報を搬送しなくてもよく、アップグレードされるアップグレードパッケージが存在することを端末に示すことのみに用いられてもよい。アップグレード要求を受けた後、ソフトウェアアップグレードプロシージャを開始する時期をサービスステータス又は端末のサービス優先度に基づいて端末が単独で決定してもよい。

【0202】

ターゲットアップグレードモード、アップグレードパッケージ優先度、アップグレードパッケージタイプ、サービスステータス情報及び待機持続時間などの、上記の実施形態で説明されている技術的特徴は、本出願の図9～図11に対応する実施形態にも適用可能である。類似点についての詳細は以下重ねて説明されない。

【0203】

上記では本出願のソフトウェアアップグレード管理方法を説明している。以下、ソフトウェアアップグレード管理を実行するサーバと端末とを個別に説明する。

【0204】

図9はサーバの概略構成図である。本出願の本実施形態のサーバは、図2～図8のいずれかに対応する実施形態のサーバによって実行されるソフトウェアアップグレード管理のステップを実行することができる。サーバによって実施される機能がハードウェアによって実施されてもよいし、対応するソフトウェアを実行することによってハードウェアによって実施されてもよい。ハードウェア又はソフトウェアが上記の機能に対応する1つ以上のモジュールを含む。モジュールはソフトウェア及び／又はハードウェアであってもよい。サーバは送受信器モジュール及び処理モジュールを含んでもよい。処理モジュールの機能の実施については、図2～図8のいずれかに対応する実施形態の、ターゲットアップグレードモード、アップグレードパッケージ優先度及びアップグレードパッケージタイプをサーバによって決定すること、及びサービスステータス情報からサービス優先度及びサービスステータスを取得することなどの動作を参照する。詳細はここでは説明されない。送受信器モジュールの機能の実施については、図2～図8のいずれか1つに対応する実施形態の、アップグレードパッケージ及びサービスステータス情報をサーバによって取得すること、並びに肯定応答及びアップグレード要求を端末から受けることなどの動作を参照する。処理モジュールは、送受信器モジュールの送受信動作を制御するように構成されてもよい。

【0205】

いくつかの実現例では、送受信器モジュールは、アップグレードパッケージを取得するように構成されてもよい。

【0206】

処理モジュールは、端末のターゲットアップグレードモードを決定するように構成されてもよい。ターゲットアップグレードモードは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含む。

【0207】

処理モジュールは、送受信器モジュールを用いてアップグレードパッケージを端末に送信して、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行する。

【0208】

ターゲットアップグレードモードを決定した後、決定されたターゲットアップグレードモードに基づいてソフトウェアアップグレードプロシージャをサーバの処理モジュールが自動的に実行することにより、アップグレードの無人自動スケジューリングを実施することが分かる。

【0209】

いくつかの実現例では、処理モジュールは以下を含む。

【0210】

ターゲットアップグレードモードでは、アップグレードパッケージタイプ、アップグレードパッケージ優先度又は端末でのサービスのサービスステータス情報のうちの少なくとも1つに基づいて端末のソフトウェアアップグレードプロシージャをサーバが実行する。サービスステータス情報はサービスステータス及びサービス優先度のうちの少なくとも一方を含む。

【0211】

【0212】

【0213】

【0214】

【0215】

【0216】

【0217】

【0218】

【0219】

【0220】

図10は端末の概略構成図である。本出願の端末は、ユーザに音声及び／又はデータ接続性を提供するデバイスであってもよい。たとえば、端末は、ポータブル、ポケットサイズ、ハンドヘルド、コンピュータ内蔵又は車載モバイル装置、たとえば、水量計、電気メータ、天然ガスメータ、シェアサイクル、スマートホームや、音声及び／又はデータを無線アクセスネットワークを用いてやり取りする別のスマートデバイスであってもよい。たとえば、これは、パーソナル通信サービス（英語表記：Personal Communication Service（略称：PCS））電話器、コードレス電話器、セッションイニシエーションプロトコル（SIP）電話器、ワイヤレスローカルループ（Wireless Local Loop、（略称：WLL））局又はパーソナルデジタルアシスタント（英語表記：Personal Digital Assistant（略称：PDA））などのデバイスであってもよい。無線端末は、サブスクライバユニット（Subscriber Unit）、サブスクライバ局（Subscriber Station）、モバイル局（Mobile Station）、モバイル局（Mobile）、ユーザ端末（User Terminal）、ユーザエージェント（User Agent）、ユーザデバイス（User Device）、ユーザ装置（User Equipment）、ポイントオブセールス（英語表記：Point of Sales（略称：POS））や車載コンピュータなどの任意の端末でもあってもよい。

【0221】

本出願の本実施形態の端末は、図2～図8のいずれかに対応する実施形態の端末によって実行されるソフトウェアアップグレード管理のステップを実行することができる。端末によって実施される機能がハードウェアによって実施されてもよいし、対応するソフトウェアを実行することによってハードウェアによって実施されてもよい。ハードウェア又はソフトウェアが上記の機能に対応する1つ以上のモジュールを含む。モジュールはソフトウェア及び／又はハードウェアであってもよい。端末は送受信器モジュール及び処理モジュールを含んでもよい。処理モジュールの機能の実施については、図2～図8のいずれかに対応する実施形態の、アップグレードパッケージ優先度及びアップグレードパッケージタイプを端末によって決定すること、及びソフトウェアアップグレードプロシージャを開始する時期を決定することなどの動作を参照する。詳細はここでは説明されない。送受信器モジュールの機能の実施については、図2～図8のいずれか1つに対応する実施形態の、アップグレードパッケージ優先度、アップグレードパッケージタイプ、アップグレードパッケージ及びサービスステータス情報を端末によって取得すること、並びにアップグレードネゴシエーション要求、肯定応答及びアップグレード要求をサーバから受けることなどの動作を参照する。処理モジュールは、送受信器モジュールの送受信動作を制御するように構成されてもよい。

【0222】

いくつかの実現例では、送受信器モジュールは、端末において設定されているアップグレードモードをサーバに送るように構成されてもよく、端末において設定されているアップグレードモードは、端末のターゲットアップグレードモードを決定するのにサーバによって用いられる。ターゲットアップグレードモードは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含む。

【0223】

処理モジュールは、アップグレードパッケージをサーバから送受信器モジュールが取得した後にターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行するように構成されてもよい。

【0224】

端末の送受信器モジュールは、設定されているアップグレードモードをサーバに提供して、ターゲットアップグレードモードをサーバが決定する根拠を与えることが分かる。アップグレードパッケージを送受信器モジュールが取得した後、サーバによって決定されたターゲットアップグレードモードに基づいてソフトウェアアップグレードプロシージャを処理モジュールが自動的に実行することにより、アップグレードの無人自動スケジューリングを実施してもよい。

【0225】

いくつかの実現例では、ターゲットアップグレードモードが端末判断型アップグレードモードである場合、処理モジュールは、
アップグレードパッケージ優先度をサーバから送受信器モジュールを用いて取得し、
ソフトウェアアップグレードプロシージャを開始するためにアップグレードパッケージ優先度及び端末でのサービスのサービス優先度に基づいて判断した後にアップグレード要求をサーバに送受信器モジュールを用いて送り、
肯定応答をサーバから送受信器モジュールが受けた後、アップグレードパッケージをサーバから取得してソフトウェアアップグレードプロシージャを開始する、
ように構成されている。

【0226】

【0227】

【0228】

図11は、本出願の実施形態に係るソフトウェアアップグレード管理を実行するために設けられるデバイスの概略構成図である。デバイスは、少なくとも1つのプロセッサ、少なくとも1つの送受信器、メモリ及び少なくとも1つのバスを含んでもよい。少なくとも1つのプロセッサ、少なくとも1つの送受信器及びメモリは、バスによって接続されたり別の仕方で接続されたりしてもよい。図11では、例としてバス接続が用いられている。

【0229】

メモリは読出し専用メモリ及びランダムアクセスメモリを含んでもよく、命令及びデータをプロセッサに提供してもよい。メモリの一部は、不揮発性ランダムアクセスメモリ（英語表記：Non－Volatile Random Access Memory（略称：NVRAM））をさらに含んでもよい。メモリは、オペレーティングシステム及び動作命令、実行モジュール若しくはデータ構造又はこれらのサブネット又はこれらの拡張集合を記憶する。動作命令は、様々な動作を実行するための様々な動作命令を含んでもよい。オペレーティングシステムは様々なシステムプログラムを含んで、様々な基本的なタスクを実施し、ハードウェアベースのタスクを処理してもよい。

【0230】

プロセッサはソフトウェアアップグレード管理に用いられるデバイスの動作を制御し、プロセッサは中央処理装置（英語表記：Central Processing Unit（略称：CPU））とも称される場合がある。特定の用途では、ソフトウェアアップグレード管理に用いられるデバイスのすべての構成要素がバスによって接続され合う。バスはデータバスに加えて、電力供給バス、制御バス、ステータス信号バスなどを含んでもよい。ただし、説明を明確にするために、様々なバスが図11ではバスと称されている。

【0231】

本出願（図9及び図10に示されている実施形態を含む）の実施形態のすべての送受信器モジュールに対応する物理的なデバイスが送受信器であってもよく、すべての処理モジュールに対応する物理的なデバイスがプロセッサであってもよい点に留意するべきである。図9及び図10に示されている装置は図11に示されている構成を持ってもよい。装置の1つが図11に示されている構成を持つ場合、図11のプロセッサ及び送受信器はこの装置に対応する装置の実施形態にそれぞれ設けられた処理モジュール及び送受信器モジュールの同じ機能又は類似の機能を実施し、図11のメモリは、ソフトウェアアップグレード管理方法をプロセッサが実行するときに呼び出される必要があるプログラムコードを記憶する。送受信器が受信器及び送信器と置換されることも行なってもよく、受信器及び送信器が同じ物理的実在物であっても異なる物理的実在物であってもよい。同じ物理的実在物であるとき、受信器と送信器とがまとめて送受信器と称されてもよい。たとえば、送受信器は高周波（英語表記：Radio Frequency（略称：RF））回路であってもよい。メモリがプロセッサに組み込まれてもよいし、プロセッサとは別体であってもよい。

【0232】

本出願の上記の実施形態に開示されている方法が図11に示されているプロセッサに適用されてもよく、すなわち、図11に示されているプロセッサによって実施されてもよい。たとえば、いくつかの実現例では、図11のプロセッサがメモリに記憶されているプログラム命令を呼び出してもよく、プロセッサは、本出願の実施形態のソフトウェアアップグレード管理方法が実行されるときに呼び出される必要があるプログラムコードを特に実行する。

【0233】

たとえば、サーバが図11に示されている構成を持つ場合、図11のメモリは、サーバによって実行されるソフトウェアアップグレード管理方法をプロセッサが実行するときに呼び出される必要があるプログラムコードを記憶する。特に、図11のプロセッサはメモリ中のプログラムコードを呼び出して以下の動作を実行することができる。

【0234】

アップグレードパッケージを送受信器を用いて取得する。

【0235】

端末のターゲットアップグレードモードを決定し、ターゲットアップグレードモードは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含む。

【0236】

アップグレードパッケージを端末に送受信器を用いて送り、ターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行する。

【0237】

別の例では、端末が図11に示されている構成を持つ場合、図11のメモリは、端末によって実行されるソフトウェアアップグレード管理方法をプロセッサが実行するときに呼び出される必要があるプログラムコードを記憶する。特に、図11のプロセッサはメモリ中のプログラムコードを呼び出して以下の動作を実行することができる。

【0238】

端末において設定されているアップグレードモードをサーバに送受信器を用いて送り、端末において設定されているアップグレードモードは、端末のターゲットアップグレードモードを決定するのにサーバによって用いられ、ターゲットアップグレードモードは、サーバ判断型アップグレードモード、端末判断型アップグレードモード又はネゴシエート型アップグレードモードのうちの1つを含む。

【0239】

アップグレードパッケージをサーバから送受信器が取得した後にターゲットアップグレードモードに基づいて端末のソフトウェアアップグレードプロシージャを実行する。

【0240】

本出願の実施形態は別の端末をさらに提供する。例としてモノのインターネット端末が用いられる。図12は本出願の実施形態に係るモノのインターネット端末に関する構成部分のブロック図である。図12を参照して、モノのインターネット端末は少なくともRF回路1212、メモリ1220及びプロセッサ1280を含む。図12に示されているモノのインターネット端末の構成がモノのインターネット端末に対する限定を構成せず、図12に示されているものよりも多数であったり少数であったりする構成要素が含まれてもよいし、いくつかの構成要素が組み合わされてもよいし、異なる構成要素の配置が用いられてもよいことが当業者によって理解されるといえる。

【0241】

以下、図12を参照してモノのインターネット端末の各構成要素を詳述する。

【0242】

RF回路1212は、情報の送受信の際に信号を送受信するように構成されてもよく、特に、サーバから受けた情報を、処理のためにプロセッサ1280に送るように構成されてもよい。さらに、RF回路1212はモノのインターネット端末に関する情報をサーバに送る。大まかに言えば、RF回路1212は、アンテナ、少なくとも1つのアンプ、送受信器、カプラ、ローノイズアンプ（英語表記：low noise amplifier（LNA））、デュプレクサなどを含むが、これらに限定されない。さらに、RF回路1212は無線通信を通じてネットワーク及び別のデバイスとさらに通信してもよい。無線通信では、移動通信グローバルシステム（英語表記：global system of mobile communication（略称：GSM））、汎用パケット無線サービス（英語表記：general packet radio service（略称：GPRS））、符号分割多元接続（英語表記：code division multiple Access（略称：CDMA））、広帯域符号分割多元接続（英語表記：wideband code division multiple access（略称：WCDMA（登録商標）））、ロングタームエボリューション（英語表記：long term evolution（略称：LTE））、Eメールやショートメッセージサービス（英語表記：short messaging service（略称：SMS））などを含む（ただしこれらに限定されない）いかなる通信規格やプロトコルでも用いてもよい。RF回路1212は図9又は図10の送受信器モジュールや、図11に示されている送受信器に対応するものであってもよい。

【0243】

メモリ1220は、ソフトウェアプログラム及びモジュールを記憶するように構成されてもよい。プロセッサ1280はメモリ1220に記憶されているソフトウェアプログラム及びモジュールを実行してモノのインターネット端末の様々な機能アプリケーションとデータ処理とを実行する。メモリ1220はプログラム記憶エリア及びデータ記憶エリアを主に含んでもよい。プログラム記憶エリアは、オペレーティングシステム、少なくとも1つの機能（音声再生機能及び画像再生機能など）によって必要とされるアプリケーションプログラムなどを記憶してもよい。データ記憶エリアは、モノのインターネット端末の使用に基づいて生成されるデータ（オーディオデータ又は電話帳など）などを記憶してもよい。さらに、メモリ1220は高速ランダムアクセスメモリを含んでもよく、少なくとも1つの磁気ディスク記憶デバイス、フラッシュ記憶デバイスなどの不揮発性メモリや別の揮発性ソリッドステート記憶デバイスをさらに含んでもよい。

【0244】

プロセッサ1280はモノのインターネット端末の制御の中核であり、モノのインターネット端末の動作を制御するように構成されてもよい。特に、プロセッサ1280は様々なインタフェース及び配線を用いてモノのインターネット端末全体のすべての部分を接続し、メモリ1220に記憶されているソフトウェアプログラム及び／又はモジュールを動作させ、すなわち実行し、メモリ1220に記憶されているデータを呼び出すことによってモノのインターネット端末の様々な機能とデータ処理とを実行することで、モノのインターネット端末に対するモニタリング全体を行なってもよい。プロセッサ1280は図9又は図10の処理モジュールや、図11に示されているプロセッサに対応するものであってもよい。

【0245】

モノのインターネット端末は、入力／出力部1230、電源1290、表示部1240、オーディオ回路1260、スピーカ1261、マイク1262及びワイヤレスフィデリティ（英語表記：wireless fidelity（略称：Wi－Fi））モジュール1270をさらに含んでもよい。

【0246】

入力／出力部1230は、入力されたディジット情報や文字情報を受け、外部インタフェースを用いてディジット情報や文字情報を出力するように構成されてもよい。特に、入力／出力部1230はタッチパネル1231と別の入力デバイス1232とを含んでもよい。タッチ画面とも称されるタッチパネル1231は、タッチパネル1231上やその近傍でユーザによって行なわれるタッチ動作（たとえば、指やスタイラスなどの任意の適当な物体や付属品を用いてタッチパネル1231上やその近傍でユーザによって行なわれる動作）を収集してもよく、予め設定されたプログラムに基づいて対応する接続装置を駆動してもよい。

【0247】

電源1290は、モノのインターネット端末中の各構成要素に電力を供給するように構成されている。電源1290は、電源管理システムを用いて充電管理、放電管理及び電力消費管理などの機能を実施するように、電源管理システムを用いてプロセッサ1280に論理的に接続されてもよい。

【0248】

表示部1240は、ユーザによって入力された情報やユーザに提供される情報、及びモノのインターネット端末の様々なメニューを表示するように構成されてもよい。表示部1240は表示パネル1241を含んでもよい。オプションとして、表示パネル1241は、液晶ディスプレイ（英語表記：Liquid Crystal Display（略称：LCD））、有機発光ダイオード（英語表記：Organic Light－Emitting Diode（略称：OLED））などの形態で構成されてもよい。さらに、タッチパネル1231は表示パネル1241をカバーしてもよい。タッチパネル1231上やその近傍でのタッチ動作を検出した後、タッチパネル1231はタッチ動作をプロセッサ1280に渡してタッチイベントのタイプを決定する。その後、プロセッサ1280はタッチイベントのタイプに基づいて対応する視覚的出力を表示パネル1241上に提供する。図12では、タッチパネル1231と表示パネル1241とがモノのインターネット端末の入力機能と出力機能とを実施する2つの独立した構成要素として用いられている。いくつかの実施形態では、タッチパネル1231と表示パネル1241とが一体化されてモノのインターネット端末の入力機能と出力機能とを実施してもよい。

【0249】

オーディオ回路1260、スピーカ1261及びマイク1262がユーザとモノのインターネット端末との間のオーディオインタフェースを提供してもよい。オーディオ回路1260は、受けたオーディオデータから変換された電気信号をスピーカ1261に伝えてもよく、スピーカ1261は電気信号を、出力されるサウンド信号に変換する。さらに、マイク1262は収集したサウンド信号を電気信号に変換し、オーディオ回路1260は電気信号を受けてオーディオデータに変換してオーディオデータをプロセッサ1280に出力する。プロセッサ1280はオーディオデータを処理した後、処理されたオーディオデータをRF回路1212を通じてたとえば、別のモノのインターネット端末に送ったり、処理されたオーディオデータをさらなる処理のためにメモリ1220に出力したりする。

【0250】

Wi－Fiは短距離無線伝送技術である。モノのインターネット端末はWi－Fiモジュール1270を用いることで、ユーザがEメールを送信及び受信し、ウェブページを閲覧し、ストリーミング媒体にアクセスするなどを支援してもよい。Wi－Fiモジュール1270はユーザに無線ブロードバンドインターネット接続を提供する。図12はWi－Fiモジュール1270を示している。しかし、Wi－Fiモジュール1270は、モノのインターネット端末の必須の構成要素ではなく、本出願の本質を変更しない範囲で必要に応じて完全に省略されてもよいことが分かる。

【0251】

示されていないが、モノのインターネット端末はカメラ、Bluetoothモジュールなどをさらに含んでもよい。詳細はここでは説明されない。

【0252】

本出願の本実施形態では、モノのインターネット端末に含まれるプロセッサ1280は、端末によって実行される上記のソフトウェアアップグレード管理方法のプロシージャの実行をさらに制御する。

【0253】

本出願の実施形態は別のサーバを提供する。図13の概略構成図に示されているように、サーバ1300は構成やパフォーマンスの違いのために大幅に異なってもよく、1つ以上の中央処理装置（英語表記：central processing units（略称：CPU））1322（たとえば1つ以上のプロセッサ）、入力／出力インタフェース1358及びメモリ1332を含んでもよい。サーバは、データ1344やアプリケーションプログラム1342を記憶する1つ以上の記憶媒体1330（たとえば1つ以上の大容量記憶デバイス）をさらに含んでもよい。

【0254】

セントラルプロセッサ1322は記憶媒体1330と通信して記憶媒体1330中の一連の命令動作をサーバ1300上で実行するように構成されてもよい。CPU1322は図9又は図10の処理モジュールや、図11に示されているプロセッサに対応するものであってもよい。記憶媒体1330は、図11に示されているメモリに対応するものであってもよい。

【0255】

入力／出力インタフェース1358は図9又は図10の送受信器モジュールや、図11に示されている送受信器に対応するものであってもよい。

【0256】

メモリ1332及び記憶媒体1330は一時的なストレージ又は永続的なストレージであってもよい。記憶媒体1330に記憶されるプログラムは1つ以上のモジュール（図に示されていない）を含んでもよく、各モジュールはサーバのための一連の命令動作を含んでもよい。

【0257】

サーバ1300は、1つ以上の電源1326、1つ以上の有線若しくは無線ネットワークインタフェース1350、1つ以上の入力／出力インタフェース1358及び／又は1つ以上のオペレーティングシステム1341（Windows Server、Mac OS X、Unix、Linux（登録商標）及びFreeBSDなど）をさらに含んでもよい。

【0258】

上記の実施形態のサーバによって実行されるステップは図13に示されているサーバ構成に基づいてもよい。

【0259】

上記の実施形態では、実施形態の説明にそれぞれの注目点がある。実施形態で詳細に説明されていない部分については、別の実施形態の関連説明を参照する。

【0260】

説明を簡便にするために、説明されているシステム、装置及びモジュールの詳細な動作プロセスについては、上記の方法の実施形態の対応するプロセスを参照することが当業者によって明確に理解されるといえ、詳細はここでは重ねて説明されない。

【0261】

本出願で提供されているいくつかの実施形態では、開示されているシステム、装置及び方法が他の仕方で実施されてもよいと当然解する。たとえば、説明されている装置の実施形態は例にすぎない。たとえば、モジュールの分割は論理的な機能の分割にすぎず、実際の実施では他の分割であってもよい。たとえば、複数のモジュールやソフトウェアが別のシステムに組み入れられたり別のシステムに統合されたりしてもよいし、いくつかの特徴が無視されたり実行されなかったりしてもよい。さらに、表示されていたり説明されていたりする相互接続や直接接続や通信接続がいくつかのインタフェースによって実施されてもよい。装置間やモジュール間の間接接続や通信接続が電子的に実施されたり機械的に実施されたり他の形態で実施されたりしてもよい。

【0262】

別体の部分として説明されているモジュールが物理的に別体であってもなくてもよく、モジュールとして表示されている部分が物理的なモジュールであってもなくてもよいし、一箇所に配置されてもよいし、複数のネットワークモジュールに分散されてもよい。モジュールの一部又は全部が実施形態の解決手段の目的を達成するように実際の必要に応じて選択されてもよい。

【0263】

さらに、本出願の機能モジュールが1つの処理モジュールに統合されてもよいし、モジュールの各々が物理的に単独で存在してもよし、2つ以上のモジュールが1つのモジュールに統合される。統合されたモジュールがハードウェアの形態で実施されてもよいしソフトウェア機能モジュールの形態で実施されてもよい。統合されたモジュールがソフトウェア機能モジュールの形状で実施されて独立した製品として販売されたり使用されたりする場合、統合されたモジュールはコンピュータ可読記憶媒体に記憶されてもよい。

【0264】

上記の実施形態の全部又は一部が、ソフトウェア、ハードウェア、ファームウェア又はこれらの任意の組合せによって実施されてもよい。実施形態を実施するのにソフトウェアが用いられる場合、実施形態がコンピュータプログラムプロダクトの形態で全体的に実施されても部分的に実施されてもよい。

【0265】

コンピュータプログラムプロダクトは1つ以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされて実行されるとき、本出願の実施形態に係るプロシージャ又は機能の一部又は全部が生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク又は別のプログラム可能な装置であってもよい。コンピュータ命令はコンピュータ可読記憶媒体に記憶されてもよいし、コンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に伝送されてもよい。たとえば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバやデータセンタから別のウェブサイト、コンピュータ、サーバやデータセンタに有線方式（たとえば、同軸ケーブル、光ファイバやデジタル加入者回線（DSL））や無線方式（たとえば、赤外線、電波又はマイクロ波）で伝送されてもよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の利用可能な媒体や、1つ以上の利用可能な媒体を統合するサーバやデータセンタなどのデータ記憶デバイスであってもよい。利用可能な媒体は、磁気媒体（たとえば、フロッピーディスク、ハードディスクや磁気テープ）、光学媒体（たとえばDVD）、半導体媒体（たとえば、ソリッドステートドライブSolid State Disk（SSD））などであってもよい。

【0266】

本出願で提供される技術的解決手段が上記に詳細に説明されている。本出願の原理及び実現例が特定の例を通じてここで説明されている。実施形態についての説明は、本出願の方法及び中心思想を理解するのを助けるために提供されているのにすぎない。さらに、当業者は本出願の思想に係る特定の実現例及び適用範囲の点で本出願に変更及び修正を加えることができる。したがって、明細書の内容は本出願に対する限定として解釈されないものとする。

【符号の説明】

【0267】

1212 RF回路
1220 メモリ
1230 入力／出力部
1231 タッチパネル
1232 別の入力デバイス
1240 表示部
1241 表示パネル
1250 センサ
1260 オーディオ回路
1261 スピーカ
1262 マイク
1270 Wi－Fiモジュール
1280 プロセッサ
1290 電源
1320 サーバ
1322 中央処理装置、セントラルプロセッサ
1326 電源
1330 記憶媒体
1332 メモリ
1341 オペレーティングシステム
1342 アプリケーションプログラム
1344 データ
1350 有線又は無線ネットワークインタフェース
1358 入力／出力インタフェース

【図1】