СИСТЕМА И СПОСОБ УПРАВЛЕНИЯ И ПЕРЕДАЧИ ОБНОВЛЕНИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Область техники

Настоящее изобретение относится к программному обеспечению и компьютерным сетям и, в частности, настоящее изобретение относится к системе и способу управления и передачи обновлений программного обеспечения.

Уровень техники

Большинство коммерчески доступных программных продуктов подвергаются процессу непрерывного пересмотра, чтобы исправлять или совершенствовать признаки и/или функции. Каждый пересмотр программного продукта или компонента может требовать дополнения новыми файлами и/или замены существующих файлов на файлы более новых версий. Как только поставщик находит проблему в программном продукте и создает решение для этой проблемы, он хочет поместить это исправление в обновление и сделать это обновление широко доступным для потребителей. Поставщики программного обеспечения имеют коммерческий стимул распространять обновления программного обеспечения потребителям настолько быстро и бесперебойно, насколько возможно.

Интернет предоставляет важный канал для потребителей получать самые последние обновления для программных продуктов. Взрывной рост использования Интернета создал общее потребительское ожидание, что программные продукты и обновления должны предоставляться для загрузки по сети. Продвигать использование Интернета для распространения обновлений тоже в интересах поставщиков программного обеспечения, так как это уменьшает их затраты и позволяет потребителям получать исправление для найденной проблемы, как только исправление становится доступным для загрузки. Сайты поставщиков в Интернет могут проектироваться, чтобы делать очень простым обнаружение и нахождение расположения файлов обновления для приложения. Технические аспекты загрузки файлов в основном стали незаметными для пользователей, и теперь обычно обрабатываются операционной системой.

В стандартном подходе поставщик программного обеспечения строит обновление программного обеспечения в виде "пакета" для загрузки. Этот пакет обычно является саморазворачивающимся исполняемым файлом с программой установки и каждым обновленным файлом продукта, вложенным и сжатым, чтобы сделать пакет меньше. Размер пакета в общем есть сумма сжатых размеров каждого измененного файла, плюс размер самого кода извлечения. По исполнении, пакет извлекает каждый из содержащихся файлов во временное местоположение, затем запускает программу установки, чтобы установить каждый файл в корректное местоположение в директории системы. Файлы, отправленные в сжатой форме, подвергаются декомпрессии при их установке. Любой существующий файл с тем же именем в том же местоположении будет просто перезаписан файлом замены.

Даже хотя Интернет делает возможным широкое и быстрое распространение обновлений программного обеспечения, ограниченная пропускная способность сетевой передачи вызывает проблемы. Только размеры обыкновенных программных приложений являются причиной того, что размеры загрузок обновлений становились неумеренно большими. Обычно множество исправлений для разнообразных проблем продукта группируется в одно обновление. Если поставщик обновляет программный продукт на регулярной основе, размер загрузки пакета обновления будет непрерывно расти, так как поставщик не может пропускать файлы, предполагая, что пользователь уже имеет эти файлы из более ранних обновлений. Так как пакет обновления комбинирует некоторое число целых файлов, он может быть достаточно большим, даже когда эти файлы сжаты. Иногда, даже на самых быстрых модемных соединениях, эффективность пропускной способности загрузки уменьшена.

Аспект потребления времени в стандартном процессе загрузки является, конечно, нежелательным. В некоторых случаях потребители несут расходы за дальнее расстояние или время соединения в течение этих загрузок файлов. Любые уменьшения во времени соединения уменьшат прямые денежные затраты для этих потребителей. Поставщики обычно также имеют некоторые ощутимые затраты, относящиеся к размерам загрузок, которые они предоставляют, таким образом, уменьшение размеров также может дать им прямые денежные выгоды. Уменьшение размеров загрузок увеличит их имеющуюся сетевую пропускную способность, позволяя им обслуживать больше потребителей с помощью существующего сетевого серверного оборудования.

Длительное время, затраченное на загрузку большого обновления, также делает процесс загрузки более уязвимым для различных проблем сетевого соединения. Имеется ряд причин, почему Интернет сессия может быть преждевременно отключена, включающих в себя шум телефонной линии, сигналы ожидания-вызова и непреднамеренные команды. Некоторые поставщики Интернет услуги навязывают ограничение времени соединения, ограничивая количество времени, которое пользователь может находиться в сети за единичную сессию. Если пользователь загружает большой файл, когда сетевое соединение обрывается, возможно, ему придется начать с начала. Большинство распространенных операционных систем и протоколов передачи файлов не позволяют возобновлять передачу файлов, таким образом любой промежуточный результат будет потерян, и передачу придется запускать с начала. Возможности для неудачи так многочисленны, что многие пользователи находят почти невозможным получить обновление по сети. Если размер пакета обновления слишком большой, пользователи могут никогда не получить возможности полностью загрузить его.

Одна попытка уменьшить размер обновлений программного обеспечения и увеличить эффективность пропускной способности относится к использованию дельта-«заплат» (корректировок), или бинарных «заплат». Специалисту в данной области должно быть понятно, что дельта-«заплата» соответствует специализированному программному коду, который модифицирует существующий файл, при исполнении вычислительным устройством. Так как дельта-«заплата» включает в себя специализированный программный код, требуется уникальная дельта-«заплата» для каждой уникальной версии файла. При применении к обновлениям программного обеспечения сервис обновления программного обеспечения может передавать дельта-«заплату» обновления меньшего размера вместо передачи полного, обновленного файла. Дельта-«заплата» обновления затем используется, чтобы модифицировать существующий файл в обновленный файл.

Хотя дельта-«заплаты» обновления могут потенциально уменьшать количество данных, требуемых для обновления файлов, текущие подходы к наложению дельта-«заплат» недостаточны в плане управления выбором применимых дельта-файлов в ситуациях, где существует большое число версий файла. Так как требуется единственная дельта-«заплата» для каждой версии файла, обычные системы обновления программного обеспечения часто могут требовать сотни, если не тысячи, уникальных дельта-«заплат» для соответствия каждой уникальной версии файла. В одном подходе, некоторые сервисы обновления, поддерживающие наложение дельта-«заплат», передают все возможные дельта-«заплаты» клиентскому вычислительному устройству. Однако этот подход обычно увеличивает количество данных, требуемых для осуществления обновления программного обеспечения, так как число возможных дельта-«заплат» обновления увеличивается. Соответственно, число потенциально применимых дельта-«заплат» может быстро вырасти до того же размера, что и полный обновленный файл. В другом подходе, сетевой сервис обновления программного обеспечения сканирует клиентскую машину, чтобы выбрать, какая дельта-«заплата» может быть применима для каждой клиентской машины. Хотя это уменьшает количество передаваемой информации дельта-«заплаты», требуется дополнительная логика на сервисе обновления программного обеспечения для сканирования клиентских машин и выбора применимой дельта-«заплаты». Использование дополнительной логики увеличивает системные ресурсы, которые должны предоставляться этим сервисом. Дополнительно, этот подход обычно препятствует использованию сетевого кэширования, который обычно выполняется традиционными серверами сети Web.

В дополнение к вышеописанным недостаткам, существующие системы не способны доставлять определенные типы обновлений программного обеспечения, такие как драйверы аппаратного обеспечения. Как известно в данной области, специализированные обновления программного обеспечения, такие как те, что применяются к драйверам аппаратного обеспечения, трудно предоставлять в крупномасштабном распределении пользователям, так как большинство специализированных обновлений программного обеспечения будут работать только на клиентских компьютерах с конкретным аппаратным обеспечением. В большинстве случаев, например, если клиентский компьютер получает несовместимое обновление драйвера аппаратного обеспечения, установка обновления драйвера может вызвать неисправимую ошибку, или даже воспрепятствовать компьютеру производить операции.

Как легко понять из предшествующего описания, имеется необходимость в системе и способе с улучшенной возможностью передачи обновлений программного обеспечения между сервером и некоторым числом клиентов. В дополнение, существует необходимость в системе обновления программного обеспечения и способе с улучшенными механизмами, чтобы позволять сервисам обновления ориентироваться на конкретные типы клиентов, при доставке специализированных обновлений.

Сущность изобретения

Настоящее изобретение направлено на систему и способ для управления обновлениями программного обеспечения. Более конкретно, настоящее изобретение направлено на систему и способ для облегчения выбора и реализации обновлений программного обеспечения при минимизации ресурсов пропускной способности и обработки, требуемых, чтобы выбирать и реализовывать обновления программного обеспечения. В соответствии с аспектом настоящего изобретения предоставляются система и компонентная архитектура для обработки обновлений программного обеспечения.

В соответствии с аспектом настоящего изобретения предоставляется способ для передачи обновлений программного обеспечения от сервиса обновления программного обеспечения клиентскому вычислительному устройству. Этот способ может быть осуществлен в компьютерной системе, включающей в себя клиентское вычислительное устройство во взаимодействии с сервисом обновления программного обеспечения. В соответствии с этим способом, сервис обновления программного обеспечения получает запрос синхронизации от клиентского вычислительного устройства. Запрос синхронизации включает в себя идентификатор установленного обновления программного обеспечения, если клиентское вычислительное устройство хранит установленное обновление программного обеспечения. Сервис обновления программного обеспечения определяет, содержит ли запрос синхронизации идентификатор по меньшей мере одного установленного обновления программного обеспечения. Если сервис обновления программного обеспечения определяет, что запрос синхронизации содержит идентификатор по меньшей мере одного установленного обновления программного обеспечения, сервис обновления программного обеспечения выбирает дополнительное обновление программного обеспечения для передачи на клиентское вычислительное устройство. Выбор дополнительного обновления программного обеспечения зависит от выполнения предварительного условия, определенного в дополнительном обновлении программного обеспечения, причем это предварительное условие требует, чтобы запрос синхронизации включал в себя идентификатор для по меньшей мере одного установленного обновления программного обеспечения. Альтернативно, если сервис обновления программного обеспечения определяет, что запрос синхронизации не содержит идентификатор по меньшей мере одного установленного обновления программного обеспечения, сервис обновления программного обеспечения выбирает обновление программного обеспечения на первом уровне для передачи клиентскому вычислительному устройству, причем обновление программного обеспечения на первом уровне не включает в себя какого-либо предварительного условия. Затем сервис обновления программного обеспечения передает командный компонент выбранного обновления программного обеспечения клиентскому вычислительному устройству из сервиса обновления программного обеспечения. Затем сервис обновления программного обеспечения сохраняет командные компоненты выбранного обновления программного обеспечения в клиентском вычислительном устройстве, как установленное обновление программного обеспечения, если клиентское вычислительное устройство содержит по меньшей мере один компонент, который удовлетворяет условию правила применимости, хранимого в выбранном обновлении программного обеспечения.

В соответствии с другим аспектом настоящего изобретения предоставляется способ для передач обновлений программного обеспечения от сервиса обновления программного обеспечения клиентскому вычислительному устройству. Этот способ может осуществляться в компьютерной системе, включающей в себя клиентское вычислительное устройство во взаимодействии с сервисом обновления программного обеспечения. В соответствии с этим способом сервис обновления программного обеспечения получает запрос авторизации от клиентского вычислительного устройства. Запрос авторизации содержит идентификатор клиентского модуля авторизации, хранимого на клиентском вычислительном устройстве. Сервис обновления программного обеспечения определяет, ассоциировано ли клиентское вычислительное устройство с целевой группой. Сервис обновления программного обеспечения устанавливает, что клиентское вычислительное устройство ассоциировано с целевой группой, если клиентский модуль авторизации показывает, что клиентское вычислительное устройство является ассоциированным с целевой группой. Сервис обновления программного обеспечения передает серверный идентификационный файл (cookie) от сервиса обновления программного обеспечения клиентскому вычислительному устройству, если устанавливается, что клиентское вычислительное устройство ассоциировано с целевой группой, причем серверный идентификационный файл идентифицирует целевую группу. Сервис обновления программного обеспечения получает запрос на по меньшей мере одно обновление программного обеспечения, хранимое в сервисе обновления программного обеспечения, причем этот запрос содержит серверный идентификационный файл. В ответ на получение запроса сервис обновления программного обеспечения определяет, ассоциировано ли обновление программного обеспечения с целевой группой, идентифицированной в серверном идентификационном файле. Дополнительно, если сервис обновления программного обеспечения определяет, что обновление программного обеспечения ассоциировано с целевой группой, идентифицированной в серверном идентификационном файле, сервис обновления программного обеспечения передает обновление программного обеспечения из сервиса обновления программного обеспечения клиентскому вычислительному устройству.

В соответствии с дополнительным аспектом настоящего изобретения предоставляется способ для передачи структуры данных от сервера клиентскому вычислительному устройству. Этот способ может осуществляться в компьютерной системе, включающей в себя клиентское вычислительное устройство во взаимодействии с сервером. В соответствии с этим способом сервис обновления программного обеспечения определяет, ассоциировано ли клиентское вычислительное устройство с целевой группой, если клиентское вычислительное устройство содержит модуль авторизации, показывающий, что клиентское вычислительное устройство ассоциировано с целевой группой. Сервис обновления программного обеспечения передает серверный идентификационный файл от сервера клиентскому вычислительному устройству, если определяется, что клиентское вычислительное устройство ассоциировано с целевой группой. Серверный идентификационный файл идентифицирует целевую группу. Сервис обновления программного обеспечения получает запрос на по меньшей мере одну структуру данных, хранимую на сервере. Этот запрос содержит серверный идентификационный файл. В ответ на получение запроса сервис обновления программного обеспечения определяет, ассоциирована ли структура данных с целевой группой, идентифицированной в серверном идентификационном файле. Если сервис обновления программного обеспечения определяет, что структура данных ассоциирована с целевой группой, идентифицированной в серверном идентификационном файле, сервис обновления программного обеспечения передает эту структуру данных от сервера клиентскому вычислительному устройству.

Краткое описание чертежей

Предшествующие аспекты и многие из сопутствующих преимуществ этого изобретения поясняются в последующем детальном описании, со ссылками на чертежи, на которых представлено следующее:

Фиг.1 - блок-схема системы обновления программного обеспечения, включающей в себя клиентский компьютер и сервис обновления, предоставляющий программное обеспечение обновления в соответствии с настоящим изобретением;

Фиг.2 - блок-схема системы обновления программного обеспечения из фиг.1, иллюстрирующая аутентификацию клиентского вычислительного устройства на сервисе обновления в соответствии с настоящим изобретением;

Фиг.3 - блок-схема системы обновления программного обеспечения из фиг.1, иллюстрирующая синхронизацию имеющихся обновлений между клиентским вычислительным устройством и сервисом обновления в соответствии с настоящим изобретением;

Фиг.4 - блок-схема системы обновления программного обеспечения из фиг.1, иллюстрирующая передачу информации обновления программного обеспечения клиентскому вычислительному устройству от сервиса обновления в соответствии с настоящим изобретением;

Фиг.5 - блок-схема системы обновления программного обеспечения из фиг.1, иллюстрирующая обработку и выбор информации обновления клиентским вычислительным устройством в соответствии с настоящим изобретением;

Фиг.6 - блок-схема системы обновления программного обеспечения из фиг.1, иллюстрирующая объединение дельта-«заплат» и установку обновленных файлов клиентским вычислительным устройством в соответствии с настоящим изобретением;

Фиг.7 - последовательность операций, иллюстрирующая процедуру обновления программного обеспечения, осуществляемую клиентским вычислительным устройством и сервисом обновления для идентификации обновлений программного обеспечения, доступных для установки на клиентском вычислительном устройстве, в соответствии с настоящим изобретением;

Фиг.8 - протокольная диаграмма процедуры авторизации для предоставления избирательного доступа к обновлениям, хранимым в сервисе обновления, в соответствии с настоящим изобретением;

Фиг.9 - блок-схема иллюстративного набора обновлений программного обеспечения, иллюстрирующая процедуру авторизации, в соответствии с настоящим изобретением;

Фиг.10 - протокольная диаграмма процедуры синхронизации для передачи выбранной группы обновлений программного обеспечения из сервиса обновления программного обеспечения клиентскому вычислительному устройству, в соответствии с настоящим изобретением;

Фиг.11 - блок-схема, иллюстрирующая иллюстративный раздел графического пользовательского интерфейса для отображения списка обновлений программного обеспечения, которые доступны для индивидуального клиентского вычислительного устройства, в соответствии с настоящим изобретением;

Фиг.12A и 12B - иллюстрация подпрограммы 1200 обработки обновлений программного обеспечения, осуществляемой клиентским вычислительным устройством 110 для извлечения и установки запрошенного программного обеспечения, в соответствии с настоящим изобретением; и

Фиг.13 - последовательность операций, иллюстрирующая подпрограмму, осуществляемую клиентским вычислительным устройством для обновления компонента базовой установки в соответствии с настоящим изобретением.

Подробное описание предпочтительного осуществления

Настоящее изобретение направлено на систему и способ для управления обновлениями программного обеспечения. Более конкретно, настоящее изобретение направлено на систему и способ для облегчения выбора и осуществления обновлений программного обеспечения при минимизации ресурсов пропускной способности и обработки, требуемых для выбора и осуществления обновлений программного обеспечения. В соответствии с настоящим изобретением обновления программного обеспечения могут относиться к обновлениям для конкретных программных приложений или операционных систем. Дополнительно обновления программного обеспечения могут включать в себя драйверы программного обеспечения или обновления для встроенных программ, таких как системный BIOS. В соответствии с аспектом настоящего изобретения предоставляются система и компонентная архитектура для обработки обновлений программного обеспечения. В соответствии с другим аспектом настоящего изобретения предоставляется протокол и интерфейс обновления для облегчения авторизации и синхронизации клиентских машин на сервисе обновления. В соответствии с дополнительным аспектом настоящего изобретения предоставляется способ для обновления установочного компонента и различных установленных файлов, использующего дельта-«заплаты». Специалисту в данной области должно быть понятно, что дополнительные аспекты настоящего изобретения также могут предоставляться в настоящем приложении. Специалисту в данной области также понятно, что каждый идентифицированный аспект может рассматриваться индивидуально или как часть общего аспекта изобретения.

На фиг.1 представлена блок-схема системы 100 обновления программного обеспечения в соответствии с настоящим изобретением. Система 100 обновления программного обеспечения может содержать одно или более клиентских вычислительных устройств 110, сервис 120 обновления и внешнего поставщика 130 обновлений. Сервис 120 обновления хранит и управляет распространением обновлений программного обеспечения, которые передаются и устанавливаются на клиентское вычислительное устройство 110. Обновления программного обеспечения могут предоставляться сервисом 120 обновления или любым количеством внешних поставщиков 130 обновлений.

Клиентское вычислительное устройство 110, сервис 120 обновлений и внешний поставщик 130 обновлений электронно взаимодействуют через сеть 101. Сеть может быть локальной сетью (LAN) или более крупной сетью, такой как глобальная сеть (WAN) или Интернет. Посредством использования широко известного программного обеспечения, система 100 обновления программного обеспечения может конфигурироваться для обмена документами, командами и другими известными типами информации между клиентским вычислительным устройством 110 и серверами 121, 122, 123 и 124 сервиса 120 обновлений. Специалистам в данной области должно быть понятно, что система 100 обновления программного обеспечения, показанная на фиг.1, является упрощенным примером подходящей системы для реализации настоящего изобретения, и что настоящее изобретение не ограничено этим примером.

Как будет описано более детально ниже, один вариант осуществления сервиса 120 обновлений содержит ряд серверов. Как показано на фиг. 1, сервис 120 обновлений включает в себя сервер 121 обновлений для управления всеобъемлющими процессами сервиса 120 обновлений и координирующие процессы серверов 121, 122, 123 и 124 сервиса 120 обновлений. Сервер 122 авторизации генерирует идентификационные файлы авторизации, как запрошено клиентом и в свою очередь идентификационные файлы авторизации используются, чтобы генерировать серверные идентификационные файлы, которые позволяют клиентским компьютерам получать доступ к обновлениям, предоставляемым сервисом 120 обновлений. Сервер 123 метаданных предоставляет общую информацию относительно обновлений, предоставляемых сервисом 120 обновлений. Сервер 123 метаданных позволяет системе настоящего изобретения идентифицировать конкретные обновления для конкретного типа клиентского компьютера или конкретной группы клиентских компьютеров. Сервер 124 загрузки предоставляет один или более программных компонентов для доставки файлов данных, ассоциированных с обновлениями программного обеспечения, предоставляемыми сервисом 120 обновлений.

Внешний поставщик 130 обновлений может включать в себя один или более серверов, которые распространяют обновления программного обеспечения. Внешний поставщик 130 обновлений может быть ассоциирован с модулем, который предоставляет программное обеспечение, обновления программного обеспечения или другие данные, которые должны распространяться группам клиентских компьютеров. Например, внешний поставщик 130 обновлений может быть ассоциирован с разработчиком программного обеспечения третьей стороны, желающим использовать сервис 120 обновлений, чтобы распространять обновления для одного или более программных приложений. В другом примере, внешний поставщик 130 обновлений может быть ассоциирован с системой 120 обновления программного обеспечения.

Клиентское вычислительное устройство 110 может быть любым вычислительным устройством, которое хранит и исполняет программные приложения 114. Клиентское вычислительное устройство 110 может формироваться из любого числа различных компьютерных продуктов, включающих в себя, но не ограниченных этим, персональные компьютеры (PC), персональные цифровые ассистенты (PDA), мобильные телефоны, двунаправленные пейджеры, и т.д. Специалистам в данной области должно быть понятно, что архитектура клиентского вычислительного устройства 110 может принимать любую подходящую форму. Например, клиентское вычислительное устройство 110 может включать в себя сетевой интерфейс для предоставления взаимодействия с сетью 101. Сетевой интерфейс может конфигурироваться для использования с любым проводным или беспроводным сетевым соединением, и может использоваться с любым подходящим коммуникационным протоколом, таким как протокол TCP/IP. В дополнение клиентское вычислительное устройство 110 может включать в себя обрабатывающее устройство, дисплей и запоминающее устройство. Запоминающее устройство может хранить программный код, необходимый для управления клиентским вычислительным устройством 110, такой как операционная система 116. В дополнение запоминающее устройство хранит компонент 112 управления обновлением для контроля и исполнения процессов настоящего изобретения.

Система 100 обновления программного обеспечения хранит программы программного обеспечения, которые при исполнении осуществляют настоящее изобретение. При исполнении, система 100 обновления программного обеспечения хранит, управляет и избирательно передает обновления программного обеспечения. Как описано более полно ниже, среди многих других выгод, настоящее изобретение предоставляет механизм для определения и выбора целевых групп клиентских вычислительных устройств, которые приемлемы для принятия обновлений программного обеспечения. Настоящее изобретение также предоставляет улучшенный механизм для загрузки файлов данных, ассоциированных с обновлениями программного обеспечения.

В целях иллюстрации настоящего изобретения предоставляется детальное описание рабочего примера настоящего изобретения. При описании рабочего примера делается ссылка на обновления программного обеспечения, которые могут ссылаться на конкретное обновление программного приложения, например обновление медиаплеера версии 6.0 до медиаплеера версии 7.0. Специалистам в данной области должно быть понятно, такое обновление программного обеспечения может включать в себя передачу и установку ряда файлов данных, ассоциированных с этим обновлением программного обеспечения. Таким образом, в целях иллюстрации настоящего изобретения делается различие между обновлением программного обеспечения и индивидуальным файлом данных, содержащим обновление программного обеспечения.

Ниже со ссылкой на фиг.2-6 описано иллюстративное взаимодействие между компонентами системы 100 обновления программного обеспечения для обновления одного или более файлов на клиентском вычислительном устройстве 110. Как показано на фиг.2, сервис обновления программного обеспечения инициируется передачей информации обновления программного обеспечения одним или более внешними поставщиками 130 обновлений. Как описано выше, внешние поставщики 130 обновлений могут быть ассоциированы с системой 100 обновления программного обеспечения. Альтернативно, информация обновления программного обеспечения может передаваться внешними поставщиками 130 обновлений третьей стороны. В иллюстративном осуществлении настоящего изобретения информация обновления программного обеспечения может включать в себя код программного обеспечения, используемый для обновления файла, код программного обеспечения, используемый для замены файла, различные правила для определения применимости обновлений программного обеспечения, и/или отображать информацию, описывающую это обновление программного обеспечения. Передача информации обновления программного обеспечения может завершаться в любое время и не обязана быть одновременной с инициированием других иллюстрируемых взаимодействий компонентов обновления программного обеспечения.

По получении информации обновления программного обеспечения от внешнего поставщика 130 обновлений, сервис 120 обновлений генерирует одну или более частей данных, чтобы облегчить передачу информации обновления. Эти данные могут включать в себя файл хранилища заплат, который соответствует набору дельта-«заплат» программного обеспечения для обновления разных версий файла. Данные могут также включать в себя манифест хранилища заплат, который соответствует индексу, отображающему конкретные файловые версии на соответствующие дельта, находящиеся в файле хранилища заплат. Эти данные могут дополнительно включать в себя саморазворачивающийся файл, который соответствует информации, которую агент обновлений будет использовать для запроса и установки данных конкретного обновления программного обеспечения, как будет описано более детально ниже. Специалисту в данной области должно быть понятно, что генерирование файла хранилища заплат, манифеста хранилища заплат и саморазворачивающихся файлов может совершаться в любое время и не обязано быть одновременным с другими иллюстрируемыми компонентными взаимодействиями.

Чтобы инициировать передачу информации обновления программного обеспечения к клиентам, клиентское вычислительное устройство 110 инициирует аутентификационный запрос к сервису 120 обновлений. В иллюстративном осуществлении настоящего изобретения аутентификационный запрос соответствует взаимодействию с протоколом обновлений между клиентским вычислительным устройством 110 и сервисом 120 обновлений, который будет описан более детально ниже. По завершении аутентификации, сервис 120 обновлений передает аутентификационный идентификационный файл (cookie) клиентскому вычислительному устройству 120. Согласно фиг.3, затем аутентифицированное клиентское вычислительное устройство 120 инициирует синхронизацию доступных обновлений с сервером 120 обновлений. В иллюстративном осуществлении настоящего изобретения запрос синхронизации также соответствует взаимодействию с протоколом обновлений между клиентским вычислительным устройством 110 и сервисом 120 обновлений, который описан более детально ниже. По завершении синхронизации клиентское вычислительное устройство 110 принимает информацию всех применимых обновлений программного обеспечения и информацию, описывающую эти обновления. Однако в иллюстративном осуществлении настоящего изобретения никакой программный код для запуска экземпляра обновления не был загружен.

Согласно фиг.3, в некоторое время в течение процесса обновления принимается выбор обновлений для установки. В иллюстративном осуществлении настоящего изобретения пользователю может быть представлена информация обновления программного обеспечения, принятая в течение синхронизации, и ему может быть предложено выбрать подходящее обновление. Альтернативно, клиентское вычислительное устройство 110 может быть конфигурировано так, чтобы автоматически выбирать все применимые обновления программного обеспечения. Дополнительно клиентское вычислительное устройство 110 может также иметь некоторые правила, которые позволяют ему автоматически выбирать подмножество из доступных обновлений программного обеспечения. Дополнительно пользователь может инициировать выбор обновления посредством взаимодействия с сервисом 120 обновлений, например через Веб страницу Интернет.

Согласно фиг.4, компонент 112 управления обновлением запускает экземпляр агента 118 обновлений на клиентском вычислительном устройстве 110, если агент обновлений еще не присутствует. Затем агент 118 обновлений запрашивает передачу пакета информации обновления программного обеспечения, такого как саморазворачивающийся файл. Агент 118 обновлений принимает саморазворачивающийся файл и выполняет любые обновления для установщика, как описано ниже. Дополнительно, агент 118 обновлений может запросить любую недостающую или разрушенную информацию от сервиса 120 обновлений.

Согласно фиг.5, как только агент 118 обновлений принимает пакет информации обновления программного обеспечения, агент 118 обновлений выполняет инвентаризацию файлов, которые установлены на клиентском вычислительном устройстве 110. Основываясь на сравнении инвентаризации и пакета информации обновления программного обеспечения, агент 118 обновлений определяет, какая дельта-«заплата» или другая информация обновления будет требоваться, чтобы завершить выбранные обновления. Затем агент 118 обновлений передает запрос на конкретные дельта-обновления. В одном варианте осуществления настоящего изобретения этот запрос на обновления программного обеспечения может соответствовать прямому запросу, передаваемому через прямое сетевое соединение, который будет упоминаться как ручное обновление. В другом варианте осуществления настоящего изобретения запрос на обновления программного обеспечения может быть фоновым запросом, который передается без требования явного пользовательского действия. Этот вариант осуществления будет упоминаться как автоматическое обновление.

В иллюстративном варианте осуществления настоящего изобретения, если обновление программного обеспечения соответствует дельта-«заплате», агент 118 обновлений передает запрос к сервису 120 обновлений, который идентифицирует конкретную дельта-«заплату», идентифицируемую манифестом хранилища заплат. Альтернативно, в случае, когда какая-либо дельта-«заплата» недоступна, или в случае неудачи для нескольких дельта-«заплат», агент 118 обновлений может инициировать процедуру нейтрализации неисправности. Процедура нейтрализации неисправности может включать в себя запрос на передачу полной копии всего обновленного файла из файла хранилища заплат. Процедура нейтрализации неисправности может также включать в себя запрос на передачу полной копии всего обновленного файла из автономного пакета.

В иллюстративном варианте осуществления настоящего изобретения сервер 124 загрузки из сервиса 120 обновлений может напрямую обрабатывать запрос обновления программного обеспечения от агента 118 обновлений. Альтернативно, запрос также может обрабатываться любым числом дополнительных внешних серверов загрузки, такими как традиционные серверы сети Web, которые тоже приняли запрошенные дельта-«заплаты» обновления от сервиса 120 обновлений. Например, корпорация может использовать внутренний сервер для обновления клиентских машин. Дополнительно, запрос может обрабатываться внешними серверами загрузки, в которых некоторые или все из дельта-«заплат» обновления кэшируются при обработке предыдущих запросов. Соответственно, в этом варианте осуществления загрузка может распространяться на ряд дополнительных серверов загрузки, допускающих обслуживание запросов данных протокола передачи гипертекстовых файлов ("HTTP").

Согласно фиг.6, как только информация обновления программного обеспечения принята, агент 118 обновлений объединяет дельта-«заплату» с установленным файлом для генерации обновленного файла. Дополнительно, агент 118 обновлений может удостоверять, успешно ли объединение обновило соответствующий файл. Как описано выше, если дельта-«заплата» не может быть объявлена действительной, агент 118 обновлений может снова запросить эту дельта-«заплату» или после некоторого числа неудач запросить весь обновленный файл. Как только агент 118 обновлений получает объявленный действительным и обновленный файл, этот файл устанавливается на клиентское вычислительное устройство 110.

На фиг.7 показана последовательность операций обрабатывающей процедуры 700 обновления программного обеспечения, иллюстрирующая взаимодействие между клиентским вычислительным устройством 110 и сервисом 120 обновления программного обеспечения в соответствии с настоящим изобретением. На этапе 702 сервис 120 обновления программного обеспечения авторизует доступ к клиентскому компьютеру 110. В иллюстративном варианте осуществления настоящего изобретения авторизация доступа к клиентскому компьютеру может включать в себя генерирование выпускаемого сервером идентификационного файла для разрешения доступа к обновлениям программного обеспечения, которые ассоциированы с конкретной группой компьютеров. Более детальное объяснение процесса авторизации описано со ссылкой на фиг.8.

На этапе 704 клиентский компьютер 110 и сервис 120 обновления программного обеспечения синхронизируют информацию обновления. В иллюстративном варианте осуществления настоящего изобретения сервис 120 обновления программного обеспечения передает метаданные, описывающие конкретные обновления программного обеспечения, клиентскому вычислительному устройству 110. Эти метаданные содержат информацию, описывающую доступные обновления программного обеспечения, чтобы позволить пользователю выбрать одно или более обновлений для установки. Более детальное описание процесса синхронизации описано ниже со ссылкой на фиг.9 и 10. На этапе 706 клиентское вычислительное устройство 110 получает выбор из применимых обновлений для загрузки. В иллюстративном варианте осуществления настоящего изобретения выбор из применимых обновлений может соответствовать использованию некоторого числа уникальных пользовательских интерфейсов для облегчения пользовательских выборов. Выбор пользовательских интерфейсов описан более детально со ссылкой на фиг.11.

На этапе 708 клиентское вычислительное устройство 110 обрабатывает пользовательский выбор применимых обновлений программного обеспечения и интерфейсов с помощью сервиса 120 обновления программного обеспечения, чтобы запросить конкретную информацию обновления. В иллюстративном варианте осуществления настоящего изобретения клиентское вычислительное устройство 110 выбирает и запрашивает одну или более применимых дельта-«заплат» обновления. Агент 118 обновлений на клиентском вычислительном устройстве 110 может затем обрабатывать запрошенные данные для осуществления выбранного обновления программного обеспечения. На этапе 710 процедура 700 завершается.

Со ссылкой на фиг.8 ниже описана протокольная диаграмма 800 для авторизации доступа к клиентским вычислительным устройствам 110, соответствующая этапу 702 (фиг.7). В иллюстративном варианте осуществления настоящего изобретения сервис 120 обновления программного обеспечения использует расширяемый механизм нацеливания, чтобы контролировать доступ клиентского вычислительного устройства 110 к обновлениям и другому программному обеспечению. Сервис 120 обновления программного обеспечения включает в себя механизм, который связывает конкретные обновления программного обеспечения с одной или более целевыми группами из клиентских вычислительных устройств 110. Например, сервис 120 обновления программного обеспечения может ограничивать доступ конкретного обновления драйвера аппаратного обеспечения к конкретной марке клиентских вычислительных устройств 110, имеющих конкретное аппаратное устройство. В таком примере сервис 120 обновления программного обеспечения может определять целевую группу клиентских вычислительных устройств 110, имеющих конкретное название марки и конкретное аппаратное устройство, и ограничивать передачу загрузки конкретного программного обеспечения для этой целевой группы.

В иллюстративном варианте осуществления настоящего изобретения расширяемый механизм нацеливания облегчается посредством использования программных компонентов ("вставных модулей авторизации" (authorization plug-ins)), которые определяют принадлежность клиентского вычислительного устройства к одной или более целевых групп. Наличие вставного модуля авторизации на клиентском вычислительном устройстве 110 определяет, принадлежит ли клиентское вычислительное устройство к конкретной целевой группе вставного модуля авторизации. Целевая группа, например, может включать в себя все компьютеры, имеющие действительный номер идентификации продукта ("PID") для конкретного программного приложения. В таком примере, как описано более детально со ссылкой на фиг.8, вставной модуль 826 авторизации может быть установлен в клиенте, чтобы читать PID из модуля памяти клиентского вычислительного устройства и передавать полученный PID соответствующему PID серверному вставному модулю 829. Соответствующий PID вставной модуль, здесь также называемый как удостоверитель 829 PID, использует один или более способов для определения, что принятый PID является действительным. Как только установлено, что PID, хранимый на клиентском вычислительном устройстве 110, действителен, сервер генерирует серверный идентификационный файл, который показывает, что клиентское вычислительное устройство 110 является членом целевой группы, имеющей действительный PID. В другом примере, целевая группа может включать в себя клиентские вычислительные устройства, которые назначаются как бета-тестовые компьютеры.

В иллюстративном варианте осуществления настоящего изобретения сервер 122 авторизации из сервиса 120 обновления программного обеспечения содержит ряд вставных модулей серверной авторизации, который определяет набор целевых групп клиентских вычислительных устройств, которые сервер авторизации будет узнавать. Каждый вставной модуль серверной авторизации содержит компоненты для передачи данных с соответствующим вставным модулем клиентской авторизации, хранимым на клиентском вычислительном устройстве 110. Аналогичным способом каждое клиентское вычислительное устройство 110 включает в себя один или более вставных модулей клиентской авторизации, которые идентифицируют целевые группы, к которым этот клиент принадлежит. В иллюстративном варианте осуществления настоящего изобретения вставные модули клиентской авторизации могут устанавливаться в каждом клиентском вычислительном устройстве в течение установки или обновления какого-либо программного приложения, такого как установка или обновление операционной системы. Дополнительно вставные модули серверной авторизации могут быть динамически установлены или удалены администратором, желающим контролировать доступ к обновлениям программного обеспечения. Вставные модули авторизации, хранимые на клиентском вычислительном устройстве 110 и сервере 122 авторизации, могут являться действительным вставным модулем программного обеспечения, или вставные модули авторизации могут быть жестко закодированы в динамически подсоединяемых библиотеках.

Как показано на фиг.8, сервер 122 авторизации содержит три иллюстративных вставных модуля серверной авторизации: (1) первый вставной модуль 828 серверной авторизации, определяющий целевую группу, которая включает в себя все компьютеры (в дальнейшем "целевая группа всех компьютеров"); (2) второй вставной 829 модуль серверной авторизации, определяющий целевую группу, которая включает в себя компьютеры, имеющие действительные PID (в дальнейшем "PID целевая группа"); и (3) третий вставной модуль 830 серверной авторизации, определяющий целевую группу, которая включает в себя бета-тестовые компьютеры (в дальнейшем "бета-целевая группа"). Также на фиг.8 показано, что клиентское вычислительное устройство 110 содержит два вставных модуля клиентской авторизации: (1) первый вставной модуль 825 клиентской авторизации, обозначающий, что клиентское вычислительное устройство 110 является членом целевой группы всех компьютеров; и (2) второй вставной модуль 826 клиентской авторизации, обозначающий, что клиентское вычислительное устройство 110 является членом PID целевой группы. В этом примере клиентское вычислительное устройство 110 не содержит вставного модуля авторизации, показывающего, что оно является членом бета-целевой группы. Специалистам в данной области должно быть понятно, что каждый вставной модуль 825 и 826 клиентской авторизации может конфигурироваться для исполнения одной или более функций на клиентском вычислительном устройстве 110, чтобы способствовать процессу удостоверения действительности. Например, второй вставной модуль 826 клиентской авторизации может конфигурироваться, чтобы обследовать память клиентского вычислительного устройства 110 для проверки или получения PID для установленного программного приложения.

Как показано на фиг.8, подпрограмма 702 авторизации начинается, когда клиентское вычислительное устройство 110 передает запрос 803 конфигурирования серверу 122 авторизации. В иллюстративном варианте осуществления настоящего изобретения запрос 803 конфигурирования формируется из любого подходящего программного компонента, конфигурированного для получения информации, описывающей вставные модули авторизации, хранимые на сервере 122 авторизации. Специалистам в данной области должно быть понятно, что запрос 803 конфигурирования может использовать известный метод, называемый как "GetConfig". В ответ на принятие запроса 803 конфигурирования сервер 122 авторизации передает ответ 804 конфигурирования, который включает в себя информацию, идентифицирующую все вставные модули авторизации, хранимые на сервере 122 авторизации. В одном варианте осуществления ответ 804 конфигурирования включает в себя массив строк, который идентифицирует и описывает все вставные модули авторизации, хранимые на сервере 122 авторизации. В настоящем примере ответ 804 конфигурирования включает в себя информацию, которая идентифицирует первый вставной модуль 828 серверной авторизации, второй вставной модуль 829 серверной авторизации и третий вставной модуль 830 серверной авторизации.

На этапе 805 клиентское вычислительное устройство 110 генерирует один или более идентификационных файлов авторизации в ответ на принятие ответа 804 конфигурирования. В процессе этапа 805 клиентское вычислительное устройство 110 генерирует идентификационный файл авторизации для каждой пары соответствующих клиента и вставных модулей серверной авторизации. Таким образом, в настоящем примере первый вставной модуль 825 клиентской авторизации генерирует первый идентификационный файл авторизации, ассоциированный с целевой группой всех компьютеров, так как первый вставной модуль 825 клиентской авторизации и первый вставной модуль 828 серверной авторизации оба ассоциированы с целевой группой всех компьютеров. Далее, второй вставной модуль 826 клиентской авторизации генерирует второй идентификационный файл авторизации, ассоциированный с PID целевой группой, так как второй вставной модуль 826 клиентской авторизации и второй вставной модуль 829 серверной авторизации оба ассоциированы с PID целевой группой. Третий идентификационный файл авторизации не генерируется, так как клиентское вычислительное устройство 110 не имеет вставного модуля авторизации, показывающего, что оно является членом бета-целевой группы.

Специалистам в данной области также должно быть ясно, что осуществление процесса этапа 805 может включать в себя использование широко известного программного метода, называемого в данной области как "GetAuthCookie". Будет также принято во внимание, что генерирование каждого идентификационного файла авторизации может включать в себя дополнительную обработку. Например, второй вставной модуль 826 клиентской авторизации может конфигурироваться, чтобы обследовать информацию, хранимую в системном реестре клиентов для извлечения PID и включения PID в идентификационный файл авторизации. В других примерах процесс этапа 805 может включать в себя процессы для взаимодействий с другими компьютерами или устройствами. Например, вставной модуль клиентской авторизации может взаимодействовать с устройством, таким как аудиоплата, сканер, видеоплата и т.д., чтобы получить тип и модель этого устройства. В других неограничивающих примерах вставной модуль клиентской авторизации может взаимодействовать с устройством защиты, таким как считыватель отпечатков пальцев, чтобы получить информацию, описывающую пользователя.

В общем, вставной модуль клиентской авторизации может читать конфигурационную информацию из любого компонента клиентского вычислительного устройства 110 или любого другого вычислительного устройства, коммуникативно подсоединенного к клиентскому вычислительному устройству 110. В других примерах вставной модуль клиентской авторизации может конфигурироваться, чтобы использовать один или более общедоступных или специализированных интерфейсов прикладного программирования (API) для сбора и шифрования информации от клиента, которая будет проверяться соответствующим серверным вставным модулем; в таких примерах вставной модуль 826 удостоверителя PID использует специализированный API для шифрования клиентского PID для передачи зашифрованного PID на сервер для дешифрования и удостоверения действительности. В других вариантах осуществления другие вставные модули клиентской авторизации могут использовать биометрические измерения, такие как считыватели отпечатков пальцев или голосовые отпечатки, чтобы построить идентификационный файл авторизации для передачи серверу для проверки достоверности. В еще одном примере вставной модуль клиентской авторизации может вызвать сервис сети Web или любой другой сервис для передачи мандата авторизации или любого другого типа данных серверу 122 авторизации.

В иллюстративном варианте осуществления настоящего изобретения каждый идентификационный файл авторизации включает в себя строку, которая идентифицирует ассоциированную целевую группу. Например, строка может показывать, что конкретный идентификационный файл авторизации ассоциирован с PID целевой группой. Каждый идентификационный файл авторизации также включает в себя раздел данных для передачи данных между клиентом и сервером. Например, идентификационный файл авторизации, ассоциированный с PID целевой группой, может иметь раздел данных, который содержит действительный PID. Специалистам в данной области должно быть ясно, что раздел данных может содержать любой тип данных, который хранится в любом формате, таком как байтовый массив. Например, если вставные модули на клиенте и сервере требуют передачи открытых и секретных ключей, такие данные могут быть зашифрованы в разделе данных одного или более идентификационных файлов авторизации.

Как только клиентское вычислительное устройство 110 генерирует идентификационный файл авторизации для каждой пары соответствующих клиента и вставных модулей серверной авторизации, клиентское вычислительное устройство передает сформированные идентификационные файлы авторизации серверу 122 авторизации. Как показано на фиг.8, клиентское вычислительное устройство 110 передает идентификационные файлы авторизации в запросе 806 идентификационных файлов. Запрос 806 идентификационных файлов включает в себя любой подходящий формат для передачи массива идентификационных файлов авторизации, сформированных в процессе этапа 805. Осуществление этой части способа 702 авторизации может включать в себя использование широко известного программного метода, называемого в данной области как "GetCookie".

В одном варианте осуществления запрос 806 идентификационных файлов также включает в себя другие идентификационные файлы сервера авторизации, хранимые в памяти клиентского вычислительного устройства 110. Как поясняется в последующем описании, память клиентского вычислительного устройства 110 может хранить старые идентификационные файлы сервера авторизации, которые были созданы в предыдущих исполнениях процедуры 700 авторизации. Предоставляя эти сохраненные идентификационные файлы сервера авторизации в запросе 806 идентификационных файлов, клиентское вычислительное устройство 110 сможет поддерживать свои привилегии доступа, которые были предоставлены в предыдущих исполнениях подпрограммы 702 авторизации. В настоящем примере, так как не имеется идентификационных файлов сервера авторизации, хранимых в клиенте, запрос 806 идентификационных файлов включает в себя первый идентификационный файл авторизации, ассоциированный с целевой группой всех компьютеров, и второй идентификационный файл авторизации, ассоциированный с PID целевой группой.

Далее, как показано на этапе 807, в ответ на принятие запроса 806 идентификационных файлов сервер 122 авторизации генерирует серверный идентификационный файл. В одном варианте осуществления для каждого из принятых идентификационных файлов авторизации осуществляется вызов к подходящему вставному модулю серверной авторизации для генерирования данных серверного идентификационного файла. Данные серверного идентификационного файла, сформированные каждым вставным модулем серверной авторизации, включают в себя идентификатор для каждой целевой группы, идентифицированной в принятых идентификационных файлах авторизации. В настоящем примере, так как запрос 806 идентификационных файлов включает в себя первый идентификационный файл авторизации, ассоциированный с целевой группой всех компьютеров, и второй идентификационный файл авторизации, ассоциированный с PID целевой группой, сервер 122 авторизации генерирует данные серверного идентификационного файла, содержащие идентификатор для этих соответствующих целевых групп. На сервере 122 авторизации данные серверного идентификационного файла затем комбинируются с данными старых серверных идентификационных файлов, если старый серверный идентификационный файл принимается в запросе 806 идентификационных файлов, чтобы генерировать новый серверный идентификационный файл. В одном варианте осуществления, новый серверный идентификационный файл шифруется посредством использования общедоступного способа шифрования, такого как Triple DBS.

В иллюстративном варианте осуществления настоящего изобретения серверный идентификационный файл может включать в себя зашифрованную информацию, которая идентифицирует одну или более ассоциированных целевых групп. В дополнение, серверный идентификационный файл может включать в себя срок окончания действия, который хранится как в формате открытого текста, так и зашифрованном формате. Срок окончания действия, хранимый в формате открытого текста, используется клиентским вычислительным устройством 110 для контроля за прекращением срока действия серверного идентификационного файла. Срок окончания действия, хранимый в зашифрованном формате, используется сервисом 120 обновления программного обеспечения, чтобы определять, авторизовано ли клиентское вычислительное устройство 110 для принятия обновлений, ассоциированных с конкретной целевой группой. В одном варианте осуществления срок окончания действия серверного идентификационного файла применяется ко всем целевым группам, идентифицированным в серверном идентификационном файле. Альтернативно, или в дополнение ко времени окончания действия, которое применяется ко всему серверному идентификационному файлу, серверный идентификационный файл может включать в себя множество сроков окончания действия, каждый из которых может применяться к индивидуальным целевым группам. Специалистам в данной области должно быть ясно, что каждый серверный идентификационный файл может включать в себя дополнительные данные. Например, серверный идентификационный файл может конфигурироваться для хранения информации о состоянии клиента, такой как отметка времени последнего исполнения подпрограммы 702 авторизации.

Сформированный, идентификационный файл 809 сервера авторизации передается от сервера 122 авторизации клиентскому вычислительному устройству 110. Далее, как показано на этапе 811, серверный идентификационный файл затем сохраняется в памяти клиентского вычислительного устройства 110. Когда клиентское вычислительное устройство 110 определяет, что по меньшей мере для одного компонента серверного идентификационного файла истек срок действия, клиентское вычислительное устройство может снова исполнить метод 702 авторизации для получения нового серверного идентификационного файла. Как упомянуто выше, при каждом последующем исполнении метода 702 авторизации клиентское вычислительное устройство 110 может передавать свои хранимые серверные идентификационные файлы серверу 122 авторизации в запросе 806 идентификационных файлов. В одном варианте осуществления клиент не должен отправлять запрос 803 пока сервер не проинформирует клиента, что серверная конфигурация изменилась, т.е. был добавлен новый вставной модуль авторизации.

В соответствии с другим аспектом настоящего изобретения сервис 120 обновления программного обеспечения может предоставлять подпрограмму синхронизации для синхронизации информации обновления между сервером 123 метаданных и клиентским вычислительным устройством 110. Посредством использования единственной иерархии обновления программного обеспечения подпрограмма синхронизации может эффективно идентифицировать конкретные обновления, которые применяются к конкретному клиентскому вычислительному устройству. В дополнение, посредством использования серверного идентификационного файла, сформированного в подпрограмме 702 авторизации, подпрограмма синхронизации может избирательно предоставлять доступ к обновлениям, ассоциированным с конкретными целевыми группами.

В соответствии с иллюстративным вариантом осуществления настоящего изобретения каждое обновление программного обеспечения включает в себя три компонента: (1) командный компонент; (2) компонент локализованных данных и (3) компонент данных. Специалистам в данной области должно быть понятно, что каждое обновление может иметь один или более из вышеописанных компонентов. Например, обновление может содержать командный компонент, компонент локализованных данных и компонент потока данных. В другом примере обновление может содержать только командный компонент для проверки одного или более условий клиентского вычислительного устройства. Различные компоненты обновлений программного обеспечения описываются более детально ниже.

В общем случае командный компонент содержит два подкомпонента: (1) правило применимости, которое определяет одно или более условий для проверки клиентским вычислительным устройством 110, и (2) набор предварительных условий, которые идентифицируют одно или более обновлений, которые требуются для правильной установки индивидуального обновления. Как описано ниже, правило применимости может определять ряд условий, относящихся к компьютеру, и каждое из этих условий может быть ассоциировано с другими условиями посредством использования любых логических операторов. Например, командный компонент может включать в себя правило применимости, чтобы определять, установлена ли на компьютере конкретная версия Windows(R). Как описано ниже, набор предварительных условий может идентифицировать одно или более обновлений, которые должны быть установлены ранее. Например, как описано более детально ниже со ссылкой на фиг.9, индивидуальное обновление может содержать предварительное условие, которое перечисляет другие обновления, требуемые для корректной установки индивидуального обновления. В других примерах, как показано на фиг.9, набор предварительных условий может включать в себя использование логических операторов для определения более сложных правил предварительных условий.

Командный компонент также содержит код, такой как булев флаг (Boolean flag), который показывает, имеются ли другие обновления, которые зависят от конкретного обновления. В целях иллюстрации, обновление считается LEAF-обновлением, если не имеется других обновлений, которые зависят от конкретного обновления. Булев флаг, который используется, чтобы показывать является ли обновление LEAF-обновлением, динамически обновляется сервером 123 метаданных по мере того, как соответствующие обновления добавляются или удаляются.

Компонент локализованных данных каждого обновления включает в себя общую информацию, описывающую это обновление. Например, компонент локализованных данных может включать в себя информацию, описывающую признаки и выгоды этого обновления. Компонент локализованных данных также может включать в себя текстовое описание установочных процедур этого обновления. В дополнение компонент локализованных данных может включать в себя любые другие данные или информацию, относящиеся к этому обновлению. Например, локализованные данные могут показывать, что обновление является высокоприоритетным обновлением. В другом примере локализованные данные могут предоставлять специальные сообщения установки, такие как сообщение, которое показывает, что обновление не может быть установлено с другими обновлениями программного обеспечения. Локализованная информация может быть в формате, который позволяет отображать для пользователя ее содержащуюся информацию.

Компонент данных каждого обновления включает в себя один или более бинарных потоков данных обновления. В одном варианте осуществления компонент данных каждого обновления может быть ассоциирован с одним или более файлами данных, такими как исполняемый файл, документ, подсоединяемая библиотека и т.д. Как описано более детально ниже, каждое обновление может быть ассоциировано с комбинацией файлов данных, каждый из которых облегчает действительное обновление, установку или модификацию программного обеспечения, используемого клиентом. Например, установка обновления может быть облегчена посредством использования единичного CAB файла, включающего в себя всю информацию, требуемую для завершения выбранного обновления. Альтернативно, установка обновления может быть облегчена посредством использования ряда индивидуальных обновлений, используемых для обновления одного или более файлов, хранимых на клиентском вычислительном устройстве.

В иллюстративном варианте осуществления настоящего изобретения обновления программного обеспечения могут размещаться в иерархии, которая обеспечивает возможность контролируемого распространения обновлений программного обеспечения. В общем случае эта иерархия обновлений определяет взаимоотношения между обновлениями и, в частности, показывает, какие обновления зависят от других обновлений. В целях иллюстрации на фиг.9 представлен иллюстративный набор обновлений. Как показано, иерархия иллюстративных обновлений 900 включает в себя базовый набор обновлений 901, второй набор обновлений 902, и третий набор обновлений 903. В общем, каждое обновление в базовом наборе обновлений 901 не имеет предварительного условия, которое требует установки других обновлений. Однако шестое обновление 921 содержит предварительное условие, которое требует установки первого обновления 911, второго обновления 912 и третьего обновления 913. Седьмое обновление 922 содержит предварительное условие, которое требует установки четвертого обновления 914. Восьмое обновление 931 содержит предварительное условие, которое требует установки шестого обновления 921 и пятого обновления 915. Поэтому восьмое обновление 931 также требует установки первого обновления 911, второго обновления 912 и третьего обновления 913. В целях иллюстрации настоящего изобретения все обновления иллюстративного набора обновлений 900 ассоциированы с целевой группой всех компьютеров и PID целевой группой.

Как показано на фиг.9 и описано более детально ниже, каждое обновление содержит правило применимости, которое определяет условия для установки этого обновления. Например, первое обновление 911 требует установки английской версии операционной системы. Второе обновление 912 требует установки Windows(R) XP версии SP1. В другом примере, шестое обновление 921 требует установки заплаты программного обеспечения, указываемой как XP PATCH1. Соответственно, клиентское вычислительное устройство 110 не будет устанавливать обновления, если правила применимости не были удовлетворены.

Фиг.9 также показывает раздел командного компонента, который показывает, имеются ли другие обновления, которые зависят от конкретного обновления. Этот раздел, определяемый как LEAF, который может быть в форме Булева значения, показывает, что обновление программного обеспечения является последним обновлением из ряда связанных обновлений. В целях иллюстрации изобретения, конкретное обновление является LEAF-обновлением, если никакие другие обновления не перечисляют это конкретное обновление как предварительное условие. Как показано на фиг.9, только седьмое обновление 922 и восьмое обновление 931 являются двумя LEAF-обновлениями.

Фиг.10 иллюстрирует протокольную диаграмму подпрограммы 704 синхронизации (фиг.7), сформированной в соответствии с настоящим изобретением. Подпрограмма 704 синхронизации избирательно передает командные компоненты определенных обновлений между клиентским вычислительным устройством 110 и сервером, таким как сервер 123 метаданных, для идентификации обновлений, которые могут применяться к клиентскому вычислительному устройству 110. Как показано на фиг.10, чтобы инициировать обновление, клиентское вычислительное устройство 110 сначала обрабатывает установленные обновления и передает запрос 1051 синхронизации серверу 123 метаданных, запрашивая одно или более обновлений, доступных для этого клиента. В ответ на принятие запроса 1051 синхронизации сервер 123 метаданных возвращает число обновлений клиентскому вычислительному устройству 110. Как поясняется в последующем описании, клиентское вычислительное устройство 110 обрабатывает локально хранимые данные до передачи запроса 1051 синхронизации.

Клиентское вычислительное устройство 110 обрабатывает командные компоненты каждого принятого обновления, чтобы определить, может ли удовлетворяться условие, определенное в правилах применимости. Если удовлетворяется условие, определенное в индивидуальном обновлении, в целях иллюстрации подпрограммы 1050 синхронизации, это индивидуальное обновление является "установленным", и это установленное обновление сохраняется в первом компоненте клиентского кэша обновлений. С другой стороны, если условие, определенное в индивидуальном обновлении, не удовлетворяется, индивидуальное обновление рассматривается как "потерпевшее неудачу", и это потерпевшее неудачу обновление сохраняется во втором компоненте клиентского кэша обновлений. В этом описании подпрограммы 1050 синхронизации, если обновление установлено, можно предполагать, что предварительные условия и условия правил применимости были удовлетворены. Установка обновления в целях описания этой подпрограммы не означает с необходимостью, что файлы данных, ассоциированные с этим обновлением, действительно устанавливаются в клиентском вычислительном устройстве 110.

В одном варианте осуществления два компонента клиентских кэшей обновлений могут использоваться для распределения принятых обновлений по категориям. Первый компонент используется для хранения установленных не LEAF-обновлений; и второй компонент используется для хранения всех других обновлений, принятых клиентом, т.е. обновлений, которые не были установлены. Второй компонент кэша обновлений также включает в себя хранение всех LEAF-обновлений. Как описано более детально ниже, обновления, хранимые в кэше обновлений, могут передаваться на сервер 123 метаданных и обрабатываться сервером 123 метаданных для идентификации других связанных обновлений, которые доступны для установки на этом клиентском вычислительном устройстве 110.

Со ссылкой на фиг.10 ниже описаны детали запроса синхронизации, которые иллюстрируются как элементы 1051, 1055, и 1060. Специалистам в данной области должно быть понятно, что запрос синхронизации может быть инициирован одним запрашивающим обновление из числа различных устройств, процессов, приложений, инициированных пользователем команд. Запрос синхронизации может инициироваться пользователем, запрашивающим список обновлений, автоматическим обновлением, инициированным клиентским агентом, или любым другим программным компонентом, запрашивающим информацию из сервера 123 метаданных или сервиса 120 обновлений. В одном варианте осуществления запрос синхронизации включает в себя идентификационный файл сервера авторизации, такой как идентификационный файл сервера авторизации, сформированный в процедуре 702 авторизации. Использование серверного идентификационного файла позволяет серверу определять, является ли клиент членом одной или более целевых групп.

Каждый запрос синхронизации может также включать в себя идентификаторы для каждого обновления, хранимого в клиентском кэше обновлений. Более конкретно, если одно или более обновлений хранятся в кэше обновлений, запрос синхронизации включает в себя первый компонент, имеющий идентификаторы для установленных не LEAF-обновлений; и второй компонент, имеющий идентификаторы для всех других обновлений, таких как LEAF-обновления, потерпевшие неудачу обновления и другие обновления, которые не были установлены. Идентификаторы обновлений могут быть в любом формате, включающем в себя, но не ограниченном этим, массив целых чисел. Альтернативно, если не имеется обновлений, хранимых в клиентском кэше обновлений, запрос синхронизации не конфигурируется с идентификатором обновления. Когда запрос синхронизации не конфигурирован с идентификатором обновления, запрос синхронизации предоставляет указание, что клиентское вычислительное устройство 110 не имеет каких-либо кэшированных обновлений.

Как показано на фиг.10, первый запрос 1051 синхронизации передается от клиентского вычислительного устройства 110 серверу 123 метаданных. В настоящем примере клиентский кэш обновлений не будет содержать каких-либо обновлений при условии, что это первое исполнение метода. Таким образом, первый запрос 1051 синхронизации не содержит идентификатора для кэшированного обновления. В ответ на принятие запроса синхронизации, как показано на этапе 1052, сервер 123 метаданных определяет содержит ли запрос синхронизации по меньшей мере один идентификатор обновления. Если определяется, что запрос синхронизации не включает в себя идентификатор обновления, сервер 123 метаданных отвечает посредством выбора обновлений на первом уровне для передачи клиентскому вычислительному устройству 110. Как описано выше, обновления на первом уровне могут включать в себя любые обновления, которые не имеют предварительного условия, идентифицирующего другие обновления.

Альтернативно, если определяется, что запрос синхронизации содержит по меньшей мере один идентификатор обновления, сервер 123 метаданных обследует предварительные условия серверных хранимых обновлений, чтобы выбрать дополнительные обновления для доставки клиенту. В одном варианте осуществления, сервер 123 метаданных выбирает обновления, имеющие выполненные предварительные условия. В обследовании этих предварительных условий, сервер использует обновления первого компонента запроса синхронизации, который включает в себя идентификаторы не LEAF-обновлений, которые установлены на клиенте.

В дополнение к выборам обновлений, имеющих выполненные предварительные условия, сервер также использует обновления, идентифицированные во втором компоненте запроса синхронизации, чтобы фильтровать эти выбранные обновления. Более конкретно, неустановленные обновления, LEAF-обновления и потерпевшие неудачу обновления, идентифицированные во втором компоненте запроса синхронизации, используются для фильтрации одного или более выбранных обновлений. Этот признак настоящего изобретения позволяет системе и способу настоящего изобретения избегать множества передач обновлений, хранимых на сервере 123 метаданных.

В рассматриваемом примере, так как первый запрос 1051 синхронизации не включает в себя идентификатор обновления, сервер 123 метаданных выбирает базовый уровень обновлений 901 для передачи клиентскому вычислительному устройству 110. Для иллюстративного набора обновлений, показанных на фиг.9, базовый уровень обновлений 901 включает в себя обновления, указанные как 911, 912, 913, 914, и 915.

В обработке этапа 1052 сервер 123 метаданных также обследует идентификационный файл сервера авторизации, содержащийся в запросе 1051 синхронизации, чтобы идентифицировать целевые группы, которые ассоциированы с клиентским вычислительным устройством 110. Сервер 123 метаданных также обследует целевые группы обновлений, выбранных в процессе этапа 1052. Процесс этапа 1052 затем отфильтровывает все выбранные обновления, которые не ассоциированы с целевой группой, идентифицированной в принятом идентификационном файле сервера авторизации. В настоящем примере, так как все выбранные обновления 911, 912, 913, 914 и 915 ассоциированы с PID целевыми группами и целевыми группами всех компьютеров, все выбранные обновления отправляются клиентскому вычислительному устройству 110.

Затем сервер 123 метаданных передает выбранные обновления в синхронизационном ответе 1053 клиентскому вычислительному устройству 110. В общем, каждый синхронизационный ответ включает в себя командный компонент каждого обновления, отправленного сервером 120. Таким образом, в настоящем примере первый синхронизационный ответ 1053 включает в себя командные компоненты для обновлений, указанных как 911, 912, 913, 914 и 915. В одном варианте осуществления каждый синхронизационный ответ не включает в себя компонент локализованных данных или компонент данных каждого обновления.

Далее, как показано в блоке 1054, клиентское вычислительное устройство 110 обрабатывает командные компоненты каждого принятого обновления, чтобы определить, может ли быть выполнено условие, определенное в правилах применимости. Согласно фиг.9, клиентское вычислительное устройство 110 обрабатывает командные компоненты принятых обновлений 911-915. В целях иллюстрации настоящего изобретения, согласно этому примеру, операционная система клиентского вычислительного устройства 110 является английской установкой Windows(R) версии XP SP1. Кроме того, клиентское вычислительное устройство 110 представляет собой Dell PC и использует 32-битный X86 процессор. Таким образом, в обработке командных компонентов иллюстративного набора обновлений клиентское вычислительное устройство 110 определит, что условие, определенное в первом обновлении 911, выполнено, так как компьютер содержит английскую OS. Условие, определенное во втором обновлении 912, выполнено, так как операционная система представляет собой Windows(R) версии XP SP1. Условие, определенное в третьем обновлении 913, выполнено, так как клиентское вычислительное устройство 110 использует X86 процессор. Условие, определенное в пятом обновлении 915, выполнено, так как клиентское вычислительное устройство 110 представляет собой Dell PC. Как результат, первое обновление 911, второе обновление 912, третье обновление 913, и пятое обновление 915 - все сохраняются в первом компоненте клиентского кэша обновлений. Условие, определенное в четвертом обновлении 914, не выполнено, так как клиентское вычислительное устройство 110 не использует 64-битный X86 процессор. Таким образом, четвертое обновление 914 рассматривается как потерпевшее неудачу обновление и сохраняется во втором компоненте клиентского кэша обновлений.

Согласно фиг.10, в обработке этапа 1054 клиентское вычислительное устройство 110 также определяет, требуется ли последующий запрос синхронизации. В одном варианте осуществления определяется, что последующий запрос синхронизации требуется, если по меньшей мере одно из принятых обновлений показывает, что оно не LEAF-обновление. В настоящем примере устанавливается, что требуется последующий запрос синхронизации, так как все принятые обновления не являются LEAF-обновлениями. Таким образом, клиентское вычислительное устройство 110 передает последующий запрос 1055 синхронизации серверу 123 метаданных.

Как указано выше, запрос синхронизации включает в себя идентификаторы для каждого обновления, хранимого в клиентском кэше обновлений. Таким образом, в настоящем примере последующий запрос 855 синхронизации включает в себя первый компонент данных, показывающий, что первое обновление 711, второе обновление 712, третье обновление 713 и пятое обновление 715 установлены в клиенте. В дополнение, последующий запрос 855 синхронизации включает в себя второй компонент данных, показывающий, что четвертое обновление 711 не было успешно установлено на клиенте.

В ответ на принятие последующего запроса 1055 синхронизации, как подытожено выше, сервер 123 метаданных определяет, содержит ли последующий запрос 1055 синхронизации по меньшей мере один идентификатор обновления. Если определяется, что последующий запрос синхронизации содержит по меньшей мере один идентификатор обновления, сервер 123 метаданных обследует предварительные условия всех сохраненных обновлений, чтобы выбрать дополнительные обновления для доставки к клиенту.

В соответствии с рассматриваемым примером в обработке блока 856, сервер 123 метаданных выберет шестое обновление 921, так как его предварительные условия выполнены. Более конкретно, как показано на фиг.9, шестое обновление 921 выбирается для передачи клиентскому вычислительному устройству 110, так как его предварительное условие, которое требует установки первого обновления 711, второго обновления 912 и третьего обновления 913, выполнено. Седьмое обновление 922 и восьмое обновление 931 не выбраны для передачи клиенту, так как их предварительные условия не выполнены. Более конкретно, запрос 1055 синхронизации не содержит идентификатора для четвертого обновления 914, которое является предварительным условием для седьмого обновления 922. В дополнение, запрос 855 синхронизации не содержит идентификатор для шестого обновления 921, которое является предварительным условием для восьмого обновления 931.

Согласно фиг.10, подпрограмма 1050 синхронизации продолжается, передавая выбранные обновления в последующем ответе 1057 от сервера 123 метаданных к клиентскому вычислительному устройству 110. В рассматриваемом примере последующий ответ 1057 включает в себя информацию, относящуюся к шестому обновлению 721, и передается клиенту 110 в последующем ответе 1057.

По принятии последующего ответа 1057, клиентское вычислительное устройство 110 обрабатывает командные компоненты последующего ответа 857. Подобно процессу из блока 854, клиентское вычислительное устройство 110 обрабатывает командные компоненты каждого принятого обновления, чтобы определить, выполняется ли условие, определенное в правилах применимости. В настоящем примере, если дано, что в клиентском вычислительном устройстве установлен XP PATCH1, шестое обновление 921 рассматривается как установленное, и это обновление записывается в кэш обновлений клиентского вычислительного устройства 110. Так как шестое обновление 921 не является LEAF-обновлением, клиентское вычислительное устройство 110 отправляет другой запрос 1060 синхронизации, который включает в себя все обновления, хранимые в первом и втором компонентах клиентского кэша обновлений. Запрос 1060 синхронизации также включает в себя идентификационный файл сервера авторизации.

В настоящем примере посредством использования вышеописанного процесса сервера 123 метаданных запрос 1060 синхронизации обрабатывается на этапе 1061, где сервер выбирает восьмое 731 обновление. Восьмое 931 обновление выбирается, так как запрос 1060 синхронизации показывает, что пятое и шестое обновления 915 и 921 установлены в клиентском вычислительном устройстве 110. При условии, что восьмое обновление 931 ассоциировано с теми же целевыми группами, идентифицированными в идентификационном файле сервера авторизации, командный компонент восьмого обновления 931 передается клиентскому вычислительному устройству 110 в другом ответе 1062. Восьмое обновление 931 затем обрабатывается в блоке 1063 способом, аналогичным обработке из этапов 1054 и 1059. Так как все принятые обновления ответа 1062 являются LEAF-обновлениями, последующий запрос синхронизации не отправляется назад серверу метаданных 123.

В клиентском вычислительном устройстве 110, после того, как определяется, что все принятые обновления являются LEAF-обновлениями, или, если никаких обновлений не принято в ответе 1062, подпрограмма 1050 синхронизации передает запрос 1064 синхронизации драйверов от клиентского вычислительного устройства 110 серверу 123 метаданных. Специалистам в данной области должно быть понятно, что запрос 1064 синхронизации драйверов может включать в себя информацию, описывающую все аппаратные средства, установленные в клиентском вычислительном устройстве 110, и информацию, описывающую установленное программное обеспечение. Аналогично предыдущим программным запросам синхронизации (1051, 1055 и 1060), запрос 1064 синхронизации драйверов может сообщать установленные обновления серверу. В дополнение, все драйверные обновления, в настоящее время кэшированные на клиенте, если есть какие-либо, сообщаются серверу.

В ответ на принятие запроса 1064 синхронизации драйверов сервер 123 метаданных отвечает посредством отправки всех драйверных обновлений, которые применимы к клиентскому вычислительному устройству 110, которые еще не кэшированы на клиенте. Драйверное обновление посылается клиентскому вычислительному устройству 110 в ответ 1065, если его предварительные условия выполняются. Ответ 1065, передающий драйверные обновления, предпочтительно передает командный компонент каждого обновления. Затем драйверные обновления записываются в кэш обновлений клиентского вычислительного устройства.

После принятия ответа 1065, содержащего драйверные обновления, подпрограмма 1050 синхронизации отправляет запрос 1066 на локализованные данные каждого из принятых обновлений программного обеспечения и аппаратного обеспечения. Как подытожено выше, компонент локализованных данных каждого обновления включает в себя общую информацию, описывающую это обновление. Например, компонент локализованных данных может включать в себя информацию, описывающую признаки и выгоды этого обновления. Компонент локализованных данных может также включать в себя текстовое описание установочных процедур обновления. В дополнение, компонент локализованных данных может включать в себя любые другие данные или информацию, относящуюся к этому обновлению.

Таким образом, по принятии запроса 1066 на локализованные данные каждого из принятых обновлений программного обеспечения и обновлений аппаратного обеспечения, сервер 123 метаданных отвечает посредством отправки всех локализованных данных для всех принятых обновлений программного обеспечения и обновлений аппаратного обеспечения, сохраненных в кэше обновлений этого клиента. Будучи принятыми, локализованные данные могут обрабатываться программным приложением, чтобы определить, какие из обновлений должны быть установлены. Альтернативно, принятые локализованные данные могут отображаться для пользователя, чтобы информировать пользователя обо всех обновлениях, которые доступны для клиентского вычислительного устройства 110. В одном варианте осуществления принятые локализованные данные могут отображаться на странице сети Web. В настоящем примере локализованные данные могут приниматься клиентом для шестого и восьмого обновлений 921 и 931. Если локализованные данные хранятся в базовых обновлениях 911, 912, 913 и 915, локализованные данные для этого обновления также будут приниматься клиентом.

Фиг.11 иллюстрирует один пример страницы 1100 сети Web, отображающей пример локализованных данных, ассоциированных с обновлениями, которые доступны для клиента. В целях иллюстрации страница 1100 сети Web содержит первое детальное описание 1105 обновления и второе детальное описание 1106 другого обновления. Каждое обновление соответственно ассоциировано с механизмами 1103 и 1104 выбора для принятия пользовательского выбора из этих обновлений. Страница 1100 сети Web сформирована с кнопкой 1101 контроля, позволяя пользователю контролировать передачу выбора из обновлений серверу, такому как сервер 123 метаданных или сервер 124 загрузки.

В одном аспекте настоящего изобретения клиент выполняет ряд процессов, чтобы улучшить отображение страницы 1100 сети Web. Например, клиентское вычислительное устройство 110 обследует локализованные данные каждого обновления, чтобы определить, имеет ли конкретное обновление высокий приоритет. Такая функция может быть облегчена посредством расположения текста в локализованных данных, или в другом компоненте конкретного обновления, который показывает, что конкретное обновление является высокоприоритетным или аварийным обновлением. Если клиентское вычислительное устройство 110 обнаруживает высокоприоритетное обновление или аварийное обновление, клиент отображает это высокоприоритетное обновление в видимом разделе страницы 1100 сети Web, таком как верхний раздел этой страницы. В дополнение, клиент может генерировать визуальный индикатор, такой как специализированное текстовое сообщение 1120, показывающее, что это обновление является высокоприоритетным обновлением.

Клиентское вычислительное устройство 110 может также обследовать локализованные данные каждого обновления, чтобы определять, требует ли конкретное обновление исключительной установки, т.е. обновление, имеющее установочный файл, который не может быть одновременно установлен с установочным файлом другого обновления. Такая функция может быть обеспечена посредством помещения текста в локализованных данных или в другом компоненте конкретного обновления, который показывает, что это конкретное обновление требует исключительной установки. Если клиентское вычислительное устройство 110 обнаруживает такое обновление, клиент отображает визуальный индикатор, такой как текстовое сообщение 1122, показанное на фиг. 11, с описанием обновлений, которые требуют исключительной установки.

Согласно фиг.7, процедура 700 обновления программного обеспечения продолжается на этапе 708, где клиентское вычислительное устройство 110 принимает выбор из обновлений. Как отмечено выше, в ответ на приведение в действие кнопки 1101 контроля, выбор одного или более обновлений может быть получен сервером 123 метаданных или сервером 124 загрузки. Как только выбор одного или более обновлений принят, процедура 700 обновления программного обеспечения продолжается на этапе 708, где обрабатываются выбранные обновления программного обеспечения.

В соответствии с еще одним аспектом настоящего изобретения сервис 120 обновления программного обеспечения может предоставлять способ для выбора и передачи информации между сервисом обновления программного обеспечения и клиентским вычислительным устройством 110. Фиг.12A и 12B иллюстрируют подпрограмму 1200 обработки обновлений программного обеспечения, осуществляемую клиентским вычислительным устройством 110 для извлечения и установки запрошенного программного обеспечения в соответствии с настоящим изобретением. Как описано выше, подпрограмма 1200 обработки обновлений программного обеспечения может осуществляться, как только выбор обновлений программного обеспечения будет сгенерирован или принят. Согласно фиг.12A на этапе 1202 компонент 111 управления обновлением запускает экземпляр агента 118 обновлений. В иллюстративном варианте осуществления настоящего изобретения агент 118 обновлений является специализированным программным компонентом для определения того, какая информация обновления программного обеспечения требуется для завершения запрошенного обновления программного обеспечения, для генерирования затребованной версии установочного компонента агента обновлений, для генерирования обновленных файлов посредством объединения существующих файлов с дельта-«заплатами», и/или для инициирования установки обновленных файлов. В случае, когда агент 118 обновлений уже запущен, блок 1202 может быть пропущен.

На этапе 1204 агент 118 обновлений получает информацию обновления программного обеспечения из сервиса 120 обновлений. В иллюстративном варианте осуществления настоящего изобретения информация обновления программного обеспечения, переданная сервисом 120 обновлений, имеет форму пакета, такого как саморазворачивающийся файл, который включает в себя ряд данных, которые могут использоваться агентом обновлений. В одном аспекте этот пакет может включать в себя список всех файлов, которые соответствуют конкретному обновлению программного обеспечения. Дополнительно этот пакет может включать в себя копию по меньшей мере части манифеста хранилища заплат, которая отображает конкретные версии файлов для обновления в соответствующую дельта-«заплату» обновления программного обеспечения, хранимую в файле хранилища заплат на сервисе 120 обновлений. Пакет может также включать в себя установочную информацию для каждого файла для обновления, которая может включать в себя идентификацию версии установочного компонента, требуемого для завершения установки. Дополнительно пакет может также включать в себя установочный компонент для агента 118 обновлений или дельта-«заплату» для обновления версии установочного компонента, уже хранимого на клиентском вычислительном устройстве 110. Пакет также может включать в себя проверочную информацию, позволяющую агенту обновлений определять, было ли успешным обновление программного обеспечения. Например, проверочная информация может включать в себя опорные значения хеш-функции для обновленных файлов для сравнивания. Агент 118 обновлений может также проверять контенты пакета.

В блоке 1206 ветвления проводится проверка для определения, должен ли агент 118 обновлений обновить версию установочного компонента, чтобы реализовать это обновление. Специалисту в данной области понятно, что передача полной копии установочного компонента в саморазворачивающемся файле может увеличивать количество данных, передаваемых сервисом 120 обновлений для каждого обновления программного обеспечения. Соответственно в иллюстративном варианте осуществления настоящего изобретения базовая версия установочного компонента может храниться в клиентском вычислительном устройстве и обновляться специально для требований текущего обновления программного обеспечения с помощью дельта-«заплаты» установочного компонента. Соответственно, установочная информация в саморазворачивающемся файле инструктирует агента 118 обновлений, должны или нет какие-либо обновления включенных сюда установочных компонентов быть объединены с базовой версией установочного компонента на клиентском вычислительном устройстве 110. Если обновление требуется, на этапе 1208, агент 118 обновлений обновляет компонент базовой установки, как объяснено более детально ниже со ссылкой на фиг.13.

Как только агент обновлений обновляет установочный компонент или если установочный компонент не требует обновления, на этапе 1210, агент 118 обновлений выполняет инвентаризацию файлов, установленных на клиентском вычислительном устройстве 110, и специальной версии этого файла. В иллюстративном варианте осуществления настоящего изобретения агент 118 обновлений может запросить файловую систему клиентского вычислительного устройства 110 обо всех файлах, идентифицированных в пакете как соответствующих выбранному обновлению. Альтернативно, если агент 118 обновлений недавно провел инвентаризацию, может использоваться кэшированная версия этой инвентаризации. На этапе 1212 агент 118 обновлений идентифицирует, какая требуется информация обновления программного обеспечения, чтобы завершить запрошенное обновление. В иллюстративном варианте осуществления настоящего изобретения манифест хранилища заплат включает в себя отображение версий установленного файла на требуемую дельта-«заплату». Соответственно, если доступно наложение дельта-«заплат», агент 118 обновлений будет использовать это отображение для идентификации конкретной дельта-«заплаты» и ее смещенного местоположения внутри файла хранилища заплат. Альтернативно, если дельта-«заплата» не доступна или не может быть осуществлена, агент 118 обновлений может идентифицировать весь файл для загрузки.

Согласно фиг.12B на этапе 1214 агент обновлений передает запрос на идентифицированную информацию обновления программного обеспечения. В иллюстративном варианте осуществления настоящего изобретения агент 118 обновлений может передавать запрос на конкретные дельта-«заплаты» путем показа конкретного ряда заплат, требуемых из файла хранилища заплат, серверу 124 загрузки из сервиса 120 обновлений. Как описано выше, файл хранилища заплат включает в себя большое число применимых дельта-«заплат», в котором каждая дельта-«заплата» идентифицируется по ее местоположению в файле хранилища заплат. Так как файл хранилища заплат в некоторых осуществлениях может быть достаточно большим, агент 118 обновлений может использовать запрос, который запрашивает данные только из конкретных местоположений в файле хранилища заплат, как показано в манифесте хранилища заплат. В альтернативном варианте осуществления настоящего изобретения агент 118 обновлений может запрашивать целую копию файла обновления и/или полную копию файла хранилища заплат.

В альтернативном варианте осуществления настоящего изобретения, другой сервер загрузки, который может не быть ассоциирован исключительно с сервисом 120 обновлений, может обрабатывать запрос агента 118 обновлений. В этом варианте осуществления запрошенный файл хранилища заплат может передаваться, весь или частично, любому числу дополнительных серверов загрузки в сети. Дополнительные серверы загрузки могут являться частью частной сети, используемой для обновления клиентов в этой частной сети. Дополнительно, дополнительный сервер загрузки может являться частью публичной сети. В среде частной сети серверы загрузки могут получать полную копию файла хранилища заплат для обработки клиентских запросов. Альтернативно, серверы загрузки могут также кэшировать части файла хранилища заплат при обработке предыдущих запросов данных от других клиентов и использовать кэшированные данные для выполнения загрузки. Соответственно, дополнительные серверы загрузки могут уменьшать нагрузку взаимодействий на сервер 124 загрузки из сервиса 120 обновлений.

На этапе 1216 агент 118 обновлений принимает запрошенную информацию обновления. В иллюстративном варианте осуществления настоящего изобретения, запрошенная информация обновления может передаваться в двух подходах. В первом подходе, определяемом как ручное обновление, запрос обновления отправляется сервису 120 обновлений с запросом на прямой ответ доставки HTTP данных. В этом подходе сервис 120 обновлений может использовать всю полную пропускную способность, доступную для передачи запрошенных данных агенту 118 обновлений. Во втором подходе, определяемом как автоматическое обновление, запрос обновления отправляется к сервису 120 обновлений с запросом на непрямой ответ доставки HTTP данных. В этом ответе сервис 120 обновлений передает запрошенные данные как фоновый процесс. Этот фоновый процесс может реализовываться так, чтобы использовать минимальное количество доступной пропускной способности. Дополнительно, фоновый процесс может быть прерван в течение процесса загрузки и запущен с начала в следующее доступное время. Описание системы и способа для передачи запрошенных данных через фоновый процесс описаны в совместно переуступленной и поданной патентной заявке США номер 09/505,735, на «Систему и способ передачи данных в сети» от 16 Февраля, 2000, которая включена в настоящее описание посредством ссылки. Специалисту в данной области должно быть понятно, что высокоприоритетная доставка данных или фоновая доставка данных не обязательно отражают приоритет выбранного обновления программного обеспечения, но скорее то, как распределяется пропускная способность для получения информации обновления.

Как только запрошенная информация принята от сервиса обновлений, на этапе 1218 агент 118 обновлений объединяет дельта-«заплату» с соответствующими установленными файлами. В иллюстративном варианте осуществления настоящего изобретения агент 118 обновлений может кэшировать исходную версию установленного файла, чтобы обеспечить, что выбранный файл не изменяется в течение процесса загрузки и объединения. Дополнительно, кэшированная исходная версия установленного файла может использоваться для отмены выбранного обновления.

В блоке ветвления 1220 проводится проверка для определения, является ли обновленный файл действительным. В иллюстративном варианте осуществления настоящего изобретения агент 118 обновлений может использовать алгоритм хеширования, чтобы сравнивать опорное значение хеш-функции, полученное из пакета информации обновления и соответствующее действительному файловому обновлению, с хеш-функцией из текущего модифицированного файла. Если хеш-функции не соответствуют, текущий модифицированный файл недействителен. Специалисту в данной области понятно, что может также использоваться любой из ряда альтернативных алгоритмов удостоверения действительности. Если обновленный файл не действительный, подпрограмма 1200 возвращается к этапу 1214, где агент обновлений может запросить информацию обновления снова. Альтернативно, если агент 118 обновлений неуспешно несколько раз пытался генерировать файл обновления, агент обновлений может реализовать одну из нескольких процедур нейтрализации неисправности. В одном варианте осуществления настоящего изобретения агент 118 обновлений может запросить полную копию обновленного файла, хранимого в файле хранилища заплат и идентифицированного из манифеста хранилища заплат из сервиса 120 обновлений. В другом варианте осуществления настоящего изобретения, агент 118 обновлений может запросить копию обновленного файла в автономном файле из сервиса 120 обновлений. В другом варианте осуществления настоящего изобретения подпрограмма 1200 может в противном случае потерпеть неудачу.

Когда выбранный файл является действительным, в блоке 1222 ветвления, проводится проверка для определения, требуются ли какие-либо дополнительные загрузки. В иллюстративном варианте осуществления настоящего изобретения подпрограмма 1200 входит в итеративный цикл, который непрерывно проверяет на дополнительные загрузки после завершения ранее выбранной загрузки. Если в течение загрузки состояние файла изменяется, агент 118 обновлений продолжил бы запрашивать дополнительные загрузки для нового изменения состояния. Если требуются дополнительные загрузки, на этапе 1224 агент 118 обновлений выполняет другую инвентаризацию и идентифицирует все применимые дельта-«заплаты». Затем подпрограмма 1200 возвращается к этапу 1214.

Когда все запрошенные загрузки обновления завершены, в блоке ветвления 1226 проводится проверка для определения, изменилось ли состояние клиентской машины. В иллюстративном варианте осуществления настоящего изобретения может пройти время между загрузкой и объединением информации обновления и действительной установкой обновленного файла. Соответственно, до установки обновленного файла, агент обновлений определяет, изменилось ли состояние клиентского вычислительного устройства. Если это состояние изменилось, файловое обновление может быть недействительным, и это обновление потерпит неудачу на этапе 1228. Альтернативно, если никакое изменение состояния не произошло, агент 118 обновлений устанавливает обновленный файл на этапе 1230, и подпрограмма 1200 возвращается на этап 1232.

Со ссылкой на фиг.13 ниже описана подпрограмма 1300, реализуемая клиентским вычислительным устройством 110 для обновления компонента базовой установки, соответствующая этапу 1208 (фиг. 12A). В блоке 1302 ветвления проводится проверка для определения, включен ли новый компонент базовой установки в саморазворачивающийся файл, передаваемый агенту 118 обновлений из сервиса 120 обновлений. В иллюстративном варианте осуществления настоящего изобретения, если дельта-«заплаты», требуемые для обновления базового установщика, соизмеримы по размеру с передачей обновленного установочного компонента, будет передан новый компонент базовой установки. Если обновленный установочный компонент включен, на этапе 1304 агент обновлений устанавливает этот обновленный компонент базовой установки как новый установочный компонент. Дополнительно, новый обновленный установочный компонент может сохраняться в памяти клиентского вычислительного устройства 110, чтобы служить в качестве базового установщика для дополнительных обновлений. На этапе 1306 подпрограмма возвращается.

Если обновленный компонент базовой установки не включается в саморазворачивающийся файл, на этапе 1308 агент 118 обновлений получает дельта-«заплату» компонента базовой установки из саморазворачивающегося файла. В иллюстративном варианте осуществления настоящего изобретения, дельта-«заплата» компонента базовой установки соответствует программному коду, который может быть объединен с компонентом базовой установки для генерирования обновленного компонента базовой установки. Соответственно, на этапе 1310, агент обновлений объединяет дельта-«заплату» компонента базовой установки с компонентом базовой установки. На этапе 1312, агент 118 обновлений затем назначает обновленный компонент базовой установки как текущий установочный компонент. В иллюстративном варианте осуществления настоящего изобретения, обновленный установочный компонент не будет сохранен после завершения установки. В соответствии с этим вариантом осуществления агент 118 обновлений поддерживает только ограниченное число компонентов базовой установки в памяти клиентского вычислительного устройства 110. Соответственно, агент обновлений генерирует временный, обновленный установочный компонент на каждой установке. Так как каждое клиентское вычислительное устройство 110 может соответствовать только ограниченному числу компонентов базовой установки, требуется только, чтобы сервис 120 обновлений передавал единичную дельта-«заплату» компонента базовой установки для каждого клиентского вычислительного устройства. На этапе 1314 подпрограмма 1300 возвращается.

Хотя проиллюстрирован и описан предпочтительный вариант осуществления изобретения, понятно, что могут быть осуществлены различные изменения без отклонения от сущности и объема изобретения. Например, хотя описанные иллюстративные примеры применяются к обновлениям программного обеспечения, объем настоящего изобретения включает в себя другие использования помимо распространения и передачи информации, относящейся к обновлениям программного обеспечения. Соответственно, если в этом раскрытии конкретная тема не исключается явно, следует иметь ввиду, что объем настоящего изобретения применяется к распространению и передаче любого типа данных, иных или в дополнение к обновлениям программного обеспечения.