 |
| |
|
| |
 |
 |
| |
|
|
| |
ブロック毎の置換なので更新順序を考慮しなくてもよい。
バイナリの差分パッチ（Windows UPDATEやSolarisなど）のようにパッチ適用（更新ファイル実行）順序を気にすることなく最新化が可能です。 |
|
|
| |
| 異なるベンダーのソフトウェア更新がワンストップで行えます。
ＯＳ、アプリケーションのみならず、ディストリビューションや開発元の異なるアプリケーション・ソフトウェアを扱え、対象機器に対して必要なパッチサービスをワンストップで提供可能です。 |
|
|
| |
パッチマネージメント（ソフトウェア更新）事業の独立
提供メーカーと電子機器との１：ｎの依存関係から、電子機器の提供メーカー：ソフトウェア更新管理：電子機器ユーザの関係が実現できます。最近の電子機器には複数ベンダー（メーカー）のソフトウェアが稼動しており、また、機器メーカーの保証範囲外のソフトウェアをダウンロード等してユーザが自由に稼動させています。この流れは益々大きくなり機器（ハードウェア）提供メーカーのコントロールでは対応しきれなくなっています。
この新しいソフトウェア更新の方式は、複数のアプリケーションソフトウェアの管理が容易になり、機器メーカーのみならず、ソフトウェア更新だけを引き受ける事業にも展開が可能です。
|
|
|
| |
| 既存のソフトウェア更新技術との連携
このソフトウェア更新方法は既存の技術と置き換えるだけではなく、既存のソフトウェア更新方法と組み合わせても有効にＴＣＯ削減ほかサービス範囲・レベルの拡張にも利用出来ます。たとえばLinuxのapt-getやWindowsのUPDATEシステムと組み合わせても有効でしょう。実際にクワンティが開発したLinuxサーバ向けパッチ適用ツール『Qloc
Engine』はrpmコマンドによるソフトウェア更新との組合せで利便性を向上しています。 |
|
|
| |
|
|
