АРХИТЕКТУРА СИСТЕМЫ РАСПРОСТРАНЕНИЯ ОБНОВЛЕНИЙ И СПОСОБ РАСПРОСТРАНЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Российский патент 2010 года по МПК G06F15/16 

Область техники, к которой относится изобретение

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

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

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

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

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

Хотя Интернет в настоящее время широко используется в качестве канала для распространения обновлений программного обеспечения от поставщиков программного обеспечения, часто возникает ряд вопросов. Два таких вопроса включают в себя:

(1) эффективность, относящуюся к инфраструктуре/ресурсам распространения обновлений, и

(2) административный контроль над распространением и установкой обновлений программного обеспечения.

Что касается эффективности ресурсов распространения, сети, включая Интернет, располагают лишь конечным объемом ресурсов связи, которые обычно называют пропускной способностью. Конечная величина пропускной способности приводит к узким местам, особенно в отношении обновлений программного обеспечения для популярных программных продуктов, как то семейству операционных систем Windows® фирмы Microsoft Corporation и связанных с ними программных продуктов. Такие узкие места существуют даже, когда обновления программного обеспечения сделаны доступными во многих местах загрузки, распределенных по Интернету. Одна из причин возникновения таких узких мест состоит в модели неструктурированного доступа, обеспечиваемой Интернетом. Например, если первый пользователь на компьютере А запрашивает новейшую загрузку программного продукта, то загрузка проходит через независимого поставщика услуг (НПУ) первого пользователя. Кроме того, запрос обрабатывается как единичный, индивидуализированный доступ, и это значит, что запрос обрабатывается независимо от любого другого сетевого трафика и/или запроса и без связи с ним. Поэтому, если второй пользователь на компьютере В, который имеет того же НПУ, запрашивает ту же загрузку, что и первый пользователь, то запрос от второго пользователя также обрабатывается как единичный, индивидуализированный доступ. В этом примере одна и та же загрузка будет дважды передаваться по одной и той же инфраструктуре, поскольку каждый запрос обрабатывается по отдельности. Очевидно, что при существенном увеличении количества пользователей, конечная пропускная способность канала связи приведет к появлению узкого места. В этом примере, который является весьма общим, было бы гораздо эффективнее, если бы загрузка кэшировалась в одном месте и каждый пользовательский запрос удовлетворялся из локального кэша.

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

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

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

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

Раскрытие изобретения

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

Согласно дополнительным аспектам настоящего изобретения представлен узел службы обновлений для распространения обновления программного обеспечения на компьютеры-клиенты и дочерние узлы службы обновлений. Узел службы обновлений также содержит интерфейс веб-службы, через который узел службы обновлений получает обновления программного обеспечения от своего родительского узла службы обновлений и через который узел службы обновлений распространяет обновления программного обеспечения на дочерние узлы службы обновлений. Узел службы обновлений также содержит программный интерфейс приложения (API) администрирования, через который администратор, используя пользовательский интерфейс администрирования, устанавливает правила для распространения обновлений программного обеспечения на дочерние узлы службы обновлений. Узел службы обновлений также содержит модуль обновления потомков для определения, какие обновления программного обеспечения доступны для распространения на дочерние узлы службы обновлений, согласно установленным правилам.

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

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

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

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

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

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

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

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

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

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

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

фиг.8 - логическая блок-схема иллюстративной процедуры для обработки запроса обновления от дочернего узла службы обновлений.

Осуществление изобретения

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

На фиг.1 показана наглядная схема иллюстративной системы 100 распространения обновлений, сформированной согласно аспектам настоящего изобретения. Согласно настоящему изобретению на «вершине» системы распространения обновлений, например, показанной системы 100 распространения обновлений, находится корневой узел 102 службы обновлений. Поставщики программного обеспечения, например поставщик 110 программного обеспечения, распространяют свои обновления программного обеспечения через систему 100 распространения обновлений, подавая обновления на корневой узел 102 службы обновлений. Согласно аспектам настоящего изобретения поставщики программного обеспечения, например поставщик 110 программного обеспечения, могут подавать свои обновления программного обеспечения на корневой узел 102 службы обновлений через сеть, например, Интернет 108.

Иерархическая система распространения обновлений, например, иллюстративная система 100 распространения обновлений, вероятно, включает в себя, по меньшей мере, один другой узел службы обновлений помимо корневого узла 102 службы обновлений. Согласно фиг.1 иллюстративная система 100 распространения обновлений содержит корневой узел 102 службы обновлений и два дополнительных узла службы обновлений: узел 104 службы обновлений и узел 106 службы обновлений. Согласно настоящему изобретению каждая иерархическая система распространения обновлений организована в виде древовидной структуры под корневым узлом 102 службы обновлений. Другими словами, каждый узел службы обновлений в системе распространения обновлений имеет нуль или более дочерних узлов службы обновлений. Таким образом, хотя в иллюстративной системе 100 распространения обновлений показано, что каждый родительский узел службы обновлений, т.е. корневой узел 102 службы обновлений и узел 104 службы обновлений, имеет по одному дочернему узлу, это показано только в иллюстративных целях и не следует рассматривать как ограничение настоящего изобретения. Поэтому, за исключением корневого узла 102 службы обновлений, каждый узел службы обновлений в системе распространения обновлений имеет один родительский узел службы обновлений. Соответственно, согласно фиг.1 узел 104 службы обновлений является дочерним узлом по отношению к корневому узлу 102 службы обновлений и узел 106 службы обновлений является дочерним узлом по отношению к узлу 104 службы обновлений. Согласно альтернативному варианту осуществления дочерний узел службы обновлений может принимать обновления от множественных родительских узлов службы обновлений (не показаны). Можно видеть, что каждый узел службы обновлений, за исключением корневого узла 102 службы обновлений, может быть как дочерним узлом службы обновлений, так и родительским узлом службы обновлений.

Как показано в иллюстративной системе 100 распространения обновлений, корневой узел 102 службы обновлений осуществляет связь с узлом 104 службы обновлений через Интернет 108. Однако следует понимать, что это показано только в иллюстративных целях и не следует рассматривать как ограничение настоящего изобретения. Каждому узлу службы обновлений в системе распространения обновлений нужно иметь возможность связи только со своим предком и/или потомком через некоторую сеть связи. Таким образом, хотя узел 104 службы обновлений осуществляет связь со своим предком, корневой узел 102 службы обновлений, через Интернет 108, может альтернативно осуществлять связь со своими дочерними узлами службы обновлений, например узлом 106 службы обновлений, через локальную сеть 124.

На фиг.1 также показано, что узел 106 службы обновлений находится в подсети 126 локальной сети 124. Например, локальная сеть 124 может соответствовать общей корпоративной сети 124 организации, и узел 104 службы обновлений представляет связь корпорации с системой 100 распространения обновлений через свое соединение со своим родителем корневым узлом 102 службы обновлений. Кроме того, подсеть 126 может соответствовать идентифицируемой группе компьютеров в корпоративной сети, например группе испытания/оценки, отдельно расположенному офису или группе, важной для работы. Как будет подробно описано ниже, согласно аспектам настоящего изобретения администратор на узле 104 службы обновлений способен контролировать распространение обновлений на узел 106 службы обновлений и, в итоге, на компьютеры-клиенты.

Следует понимать, что каждый узел службы обновлений, в том числе корневой узел 102 службы обновлений и узлы 104 и 106 службы обновлений, способен распространять обновления программного обеспечения как на дочерние узлы службы обновлений, так и на компьютеры-клиенты. Согласно фиг.1 иллюстративная система 100 распространения обновлений содержит компьютеры-клиенты 112-122. Каждый узел службы обновлений, в том числе корневой узел 102 службы обновлений, распространяет обновления программного обеспечения на дочерние узлы службы обновлений и компьютеры-клиенты согласно информации локальной конфигурации. Согласно одному варианту осуществления администратор задает группы и связывает правила распространения обновления с этими группами.

В порядке примера, иллюстрирующего работу системы распространения обновлений, предположим, что локальная сеть 124 соответствует корпоративной сети коммерческой организации, администратор на узле 104 службы обновлений может задавать множественные группы распространения для корпоративной сети 124, в том числе группу оценки, соответствующую подсети 126, содержащей узел 106 службы обновлений и компьютеры-клиенты 120 и 122, для оценки пригодности обновления для всей корпоративной сети 124, а также общую корпоративную группу, содержащую узел 104 службы обновлений и компьютеры-клиенты 114-118.

Что касается группы оценки, администратор включает узел 106 службы обновлений в качестве члена и связывает правила для этой группы с этой группой, так что обновления немедленно распространяются на члены группы оценки по мере своего появления. Альтернативно, в отношении общей корпоративной группы, администратор добавляет компьютеры-клиенты 114-118 и связывает правило, так что обновления распространяются на члены общей корпоративной группы только по особому разрешению администратора. Предположим также, что администратор для дочернего узла 106 службы обновлений создает группу по умолчанию, состоящую из компьютеров-клиентов 120 и 122 в подсети 126 оценки, на которые может немедленно распространяться обновление программного обеспечения.

Согласно вышеприведенному примеру поставщик 110 программного обеспечения подает обновление программного обеспечения на корневой узел 102 службы обновлений. Согласно правилам, установленным на корневом узле 102 службы обновлений, обновление, в конечном итоге, распространяется на корпоративный узел 104 службы обновлений. Получив обновление, согласно правилам, установленным администратором, корпоративный узел 104 службы обновлений распространяет обновление на члены группы оценки (заданные как только дочерний узел 106 службы обновлений), но удерживает обновление от общей корпоративной группы, ожидая особого разрешения на распространение обновления на эту группу.

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

По-прежнему продолжая вышеприведенный пример, когда администратор корпоративного узла 104 службы обновлений достаточно удовлетворен тем, что обновление пригодно для распространения по всей корпоративной сети 124, администратор в явном виде разрешает распространение обновления на члены общей корпоративной группы. Корпоративный узел 104 службы обновлений соответственно делает обновление доступным для компьютеров-клиентов 114-118. Следует понимать, что оценочный узел 106 службы обновлений также может входить в состав общей корпоративной группы. Однако, поскольку оценочный узел 106 службы обновлений уже обновлен, для распространения обновления на подсеть 126 оценки не требуется никаких дополнительных действий, связанных с обновлением.

Из вышеприведенного примера можно видеть, что настоящее изобретение дает значительные преимущества в отношении локального контроля распространения и эффективности загрузки. Помимо вышеописанных аспектов локального контроля распространения, реализуется также значительная экономия пропускной способности канала связи. Например, хотя иллюстративная корпоративная сеть 124, показанная на фиг.1, содержит пять компьютеров-клиентов, обновление от поставщика программного обеспечения было загружено с корневого узла 102 службы обновлений на корпоративный узел 104 службы обновлений только один раз. Очевидно, что, по мере увеличения количества компьютеров-клиентов, обслуживаемых узлом службы обновлений, использование пропускной способности канала связи между родительским узлом службы обновлений и клиентским узлом службы обновлений остается постоянным, что существенно уменьшает величину пропускной способности канала связи по сравнению с используемой в противном случае. Дополнительно, система распространения обновлений является расширяемой и масштабируемой. Система распространения обновлений имеет возможность расширения двумя путями: к родительскому узлу службы обновлений можно добавлять любое количество дочерних узлов службы обновлений, и дочерние узлы службы обновлений также могут быть родительскими узлами службы обновлений. Каждое поддерево системы распространения обновлений можно, таким образом, конфигурировать в соответствии с индивидуальными потребностями.

Еще одно преимущество, реализуемое настоящим изобретением, состоит в простоте, с которой администратор устанавливает и приводит в действие совместимую программную платформу на компьютерах-клиентах и сети, за которые отвечает администратор. Например, текущий процесс, в котором администратор гарантирует совместимость программной платформы на компьютерах-клиентах, в целом заключается в следующем: определить, что должна представлять собой программная платформа, т.е. какие обновления нужно устанавливать, а какие - нет; определить статус программных платформ на каждом компьютере-клиенте; и направить надлежащие обновления программного обеспечения на компьютеры-клиенты для установки. Даже после первоначальной попытки администратору приходится часто повторять процесс, чтобы гарантировать, что программная платформа остается совместимой. В отличие от этих подходов, отвечающих уровню техники, благодаря использованию вышеописанной системы распространения обновлений, а также инфраструктурной поддержки для группирования клиентских машин в разные целевые группы и возможности направлять разные обновления на разные целевые группы (описаны ниже), администратор может задавать нужное состояние для установки обновления программного обеспечения сетей и/или компьютеров-клиентов, за которые отвечает администратор. Администратор задает нужное состояние через API администрирования (также описанный ниже) для любого количества компьютеров-клиентов и/или групп компьютеров-клиентов. Установив/задав нужное состояние обновления, администратор может опираться на систему распространения обновлений, чтобы осуществлять распространение обновления по системе распространения обновлений. Система распространения обновлений действует так, чтобы гарантировать, что клиенты в системе согласуются с нужным состоянием, назначенным администратором. Совершая периодические действия, система распространения обновлений постоянно пытается привести те компьютеры-клиенты, которые не согласуются с нужным состоянием, в соответствие. Кроме того, связывая конкретные атрибуты установки с обновлениями программного обеспечения, например, обязательным атрибутом установки или атрибутом установки установка по крайнему сроку исполнения, система распространения обновлений освобождает администратора от существенной части деталей реализации, связанных с поддержанием совместимой программной платформы. Более подробное описание связывания атрибутов установки с обновлением программного обеспечения для управления ходом установки на клиентском вычислительном устройстве приведено в совместно рассматриваемой патентной заявке США с общим правопреемником, под названием «Управление ходом установки обновления на компьютере-клиенте» ["Controlling Installation Update Behaviors On a Client Computer"], поданной 12 марта 2004 г., реестр поверенного № MSFT-1-22459, которая включена сюда посредством ссылки.

На фиг.2 показана блок-схема иллюстративных логических компонентов узла 200 службы обновлений, например, корпоративного узла 104 службы обновлений (фиг.1) или оценочного узла 106 службы обновлений (фиг.1), сформированного согласно аспектам настоящего изобретения. Согласно фиг.2 узел 200 службы обновлений содержит веб-службу 202 обновлений, модуль 204 обновлений клиентов, модуль 206 обновлений потомков и модуль 208 отчетов. Иллюстративный узел 200 службы обновлений также содержит модуль 210 аутентификации/авторизации, программный интерфейс приложений (API) 212 администрирования, хранилище 214 содержимого обновлений, пользовательский интерфейс 218 администрирования и хранилище 216 информации обновлений.

Веб-служба 202 обновлений обеспечивает обычный набор веб-услуг, посредством которых компьютеры-клиенты, дочерние узлы службы обновлений и родительский узел службы обновлений могут осуществлять связь с узлом службы обновлений. Например, согласно фиг.1, чтобы дочерний/оценочный узел 106 службы обновлений мог получать обновление программного обеспечения от родительского/корпоративного узла 104 службы обновлений, клиент осуществляет связь через веб-службу 202 обновлений предка. Аналогично, когда родительский узел службы обновлений, например, корневой узел 102 службы обновлений, имеет информацию, в том числе обновления, подлежащую передаче на его дочерний узел 104 службы обновлений, родительский узел службы обновлений осуществляет связь через веб-службу 202 обновлений потомка.

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

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

Модуль 208 отчетов генерирует отчеты об обновлениях, например, какие группы получили или не получили конкретное обновление, какие компьютеры-клиенты загрузили/установили обновление или не сделали этого и т.п. Эти отчеты могут использоваться внутренне, например, администратором, а также передаваться на родительский узел службы обновлений через интерфейс 202 службы обновления предка. Согласно вышеописанному корпорациям часто требуется определять, какие компьютеры-клиенты установили то или иное обновление, например, в целях тарификации или в целях обслуживания. Информация/отчеты, сгенерированные модулем 208 отчетов, может служить основой этих отчетов.

Модуль 210 аутентификации/авторизации отвечает за аутентификацию, т.е. определение идентичности того или иного компьютера-клиента или дочернего узла службы обновлений, и определение, разрешен ли компьютеру-клиенту или дочернему узлу службы обновлений доступ к обновлениям, имеющимися на узле 200 службы обновлений. Тем компьютерам-клиентам и дочерним узлам службы обновлений, которые аутентифицированы и авторизованы для доступа к обновлениям на узле службы обновлений, модуль 210 аутентификации/авторизации выдает жетон авторизации, который нужно использовать для получения обновлений. Выдача и использование жетона авторизации более подробно описаны ниже со ссылкой на фиг.4А и 4В.

API 212 администрирования представляет интерфейс приложения, посредством которого осуществляется управление узлом 200 службы обновлений и посредством которого обновления окончательно сохраняются и распространяются. Когда веб-служба 202 обновлений принимает различные запросы, связанные с обновлениями, от компьютеров-клиентов и дочерних узлов службы обновлений, эти запросы, в конце концов, разбиваются на вызовы в API 212 администрирования либо напрямую, либо косвенно, через модуль 204 обновлений клиентов и модуль 206 обновлений потомков. С помощью пользовательского интерфейса 218 администрирования или какой-либо другой программы, установленной на узле 200 службы обновлений, надлежащим образом сконфигурированной для использования API 212 администрирования, администратор, в итоге, контролирует все аспекты процесса обновления для этого узла службы обновлений, а также любых дочерних узлов службы обновлений и компьютеров-клиентов.

Посредством пользовательского интерфейса 218 администрирования администраторы могут конфигурировать и обслуживать узел 200 службы обновлений через API 212 администрирования. Таким образом, посредством пользовательского интерфейса 218 администрирования администратор создает, изменяет и удаляет группы, а также соответствующие правила для каждой группы. Кроме того, используя пользовательский интерфейс 218 администрирования, администратор устанавливает, какой группе принадлежит компьютер-клиент или дочерний узел службы обновлений. Посредством пользовательского интерфейса 218 администрирования администратор также может в явном виде разрешать распространение обновлений на компьютеры-клиенты или дочерние узлы службы обновлений, конфигурировать узел 200 службы обновлений, чтобы он периодически запрашивал свой родительский узел службы обновлений на предмет новых обновлений, конфигурировать параметры составления отчета и просматривать внутренние отчеты и т.п. Согласно вышеуказанному, хотя пользовательский интерфейс 218 администрирования позволяет администратору осуществлять контроль над аспектами узла 200 службы обновлений, вместо пользовательского интерфейса 218 администрирования можно использовать другое приложение, установленное на узле 200 службы обновлений и приспособленное для работы с API 212 администрирования.

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

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

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

На фиг.3 изображена блок-схема иллюстративных логических компонентов корневого узла 300 службы обновлений, например, корневого узла 102 службы обновлений, показанного на фиг.1, сформированного согласно аспектам настоящего изобретения. По аналогии с логическими компонентами узла 200 службы обновлений (фиг.2) корневой узел 300 службы обновлений содержит веб-службу 202 обновлений, модуль 206 обновлений потомков и модуль 210 аутентификации/авторизации. Кроме того, иллюстративный корневой узел 300 службы обновлений содержит (API) 212 администрирования, хранилище 214 содержимого обновлений и хранилище 216 информации обновлений. В необязательном порядке корневой узел 300 службы обновлений содержит модуль 204 обновлений клиентов, модуль 208 отчетов и пользовательский интерфейс 218 администрирования.

Модуль 204 обновлений клиентов является необязательным компонентом для корневого узла 300 службы обновлений в зависимости от того, предоставляет ли корневой узел. Службы обновлений проводят обновления программного обеспечения компьютерам-клиентам напрямую. Например, согласно фиг.1 корневой узел 102 службы обновлений содержит необязательный модуль 204 обновлений клиентов, поскольку он является корневым узлом службы обновлений, который напрямую обслуживает компьютер-клиент 112. Если же корневой узел 300 службы обновлений непосредственно не обслуживает компьютеры-клиенты, то модуль 204 обновлений клиентов можно исключить.

Модуль 208 отчетов является необязательным компонентом для корневого узла 300 службы обновлений, поскольку корневой узел службы обновлений не имеет родительского узла службы обновлений, которому нужно предоставлять отчеты об обновлениях. Однако в той степени, в какой отчеты об обновлениях требуются администратору корневого узла службы обновлений, модуль 208 отчетов может быть включен в необязательном порядке.

Помимо логических компонентов, входящих в состав узла 200 службы обновлений (фиг.2), корневой узел 300 службы обновлений содержит также интерфейс 302 поставщика программного обеспечения. Интерфейс 302 поставщика программного обеспечения обеспечивает интерфейс связи, посредством которого поставщик 110 программного обеспечения (фиг.1) передает обновления программного обеспечения непосредственно на корневой узел 300 службы обновлений и опосредованно на иллюстративную систему 100 распространения обновлений.

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

Чтобы можно было лучше понять, как обновление распространяется от корневого узла службы обновлений через систему 100 распространения обновлений, представлен пример обмена между родительским узлом службы обновлений и дочерним узлом службы обновлений. На фиг.4 показана блок-схема, иллюстрирующая обмен между родительским узлом 402 службы обновлений и дочерним узлом 404 службы обновлений при распространении обновления программного обеспечения от родительского узла службы обновлений к дочернему узлу службы обновлений согласно аспектам настоящего изобретения. Можно видеть, что иллюстративная схема 400 поделена пополам, причем левая половина соответствует действиям и событиям родительского узла 402 службы обновлений, а правая половина соответствует действиям и событиям дочернего узла 404 службы обновлений.

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

Как показано в иллюстративном обмене 400, начиная с события 406, родительский узел 402 службы обновлений принимает обновление программного обеспечения от поставщика 110 программного обеспечения либо напрямую, если родительский узел службы обновлений является корневым узлом 102 службы обновлений, либо косвенно, через систему 100 распространения обновлений. В какой-то момент после того, как родительский узел 402 службы обновлений получит обновление программного обеспечения от поставщика 110 программного обеспечения, дочерний узел 404 службы обновлений начинает процесс получения обновлений программного обеспечения с родительского узла службы обновлений.

Согласно одному варианту осуществления дочерний узел 404 службы обновлений можно сконфигурировать так, чтобы он автоматически получал доступные обновления программного обеспечения от родительского узла 402 службы обновлений на периодической основе. В частности, администратор, через пользовательский интерфейс 218 администрирования, может избирательно конфигурировать дочерний узел 404 службы обновлений, чтобы он автоматически получал последние обновления программного обеспечения, доступные на родительском узле 402 службы обновлений на периодической основе. Например, администратор может сконфигурировать дочерний узел 404 службы обновлений, чтобы он получал последние обновления программного обеспечения от своего родительского узла 402 службы обновлений ежедневно и/или ежечасно, а также задать время суток, когда должен совершаться процесс автоматического обновления. Можно также использовать другие периодические расписания и критерии. Аналогично, администратор может вручную инициировать процесс обновления через пользовательский интерфейс 218 администрирования.

Чтобы начать процесс обновления, в ходе события 408 дочерний узел 404 службы обновлений аутентифицирует и авторизует себя с помощью родительского узла 402 службы обновлений. Аутентификация и авторизация с помощью родительского узла 402 службы обновлений обеспечивает элемент контроля над распространением обновлений программного обеспечения, ограничивающий распространение обновлений авторизованными узлами службы обновлений. Методы аутентификации и авторизации общеизвестны в технике, и любые из них можно применять для аутентификации и авторизации дочернего узла 404 службы обновлений с помощью родительского узла 402 службы обновлений. Настоящее изобретение не ограничивается каким-либо одним методом.

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

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

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

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

В ходе события 414 родительский узел 402 службы обновлений возвращает каталог обновлений продуктов на дочерний узел 404 службы обновлений. В ходе события 416 дочерний узел 404 службы обновлений выбирает те продукты из каталога обновлений продуктов, обновление которых нужно в настоящее время. Заметим, что, хотя в каталоге обновлений продуктов могут быть перечислены только те программные продукты, которые распространяет дочерний узел 404 службы обновлений, дочерний узел службы обновлений может быть настроен на получение обновлений для разных программных продуктов в разное время или в соответствии с разными периодическими расписаниями.

В ходе события 418 дочерний узел 404 службы обновлений подает запрос синхронизации обновлений совместно с жетоном авторизации, идентифицируя выбранные продукты, для которых дочерний узел службы обновлений в данный момент ищет обновления. В запрос синхронизации входит информация, идентифицирующая самое последнее обновление, доступное для продукта на дочернем узле 404 службы обновлений. Информация, идентифицирующая последнее обновление продукта, будут называть «анкер обновления». Анкеры обновления для каждого программного продукта обычно хранятся в хранилище 216 информации обновлений (фиг.2). Согласно одному варианту осуществления анкер обновления содержит номер ревизии и дату, связанную с номером ревизии.

В ответ на запрос синхронизации обновлений, в ходе события 420, родительский узел 402 службы обновлений определяет, какие, если таковые существуют, новые обновления доступны для дочернего узла 404 службы обновлений. Как отмечено выше, это определение базируется на конкретных правилах, связанных с конкретными обновлениями программного обеспечения и группой или группами, членом которой(ых) является дочерний узел 404 службы обновлений, а также анкер обновления. В этом примере, как было отмечено ранее, принятое ранее обновление программного обеспечения не было в явном виде авторизовано для дочернего узла 404 службы обновлений. Поэтому обновление программного обеспечения, принятое в ходе события 406, не определено как «доступное» для дочернего узла 404 службы обновлений. Соответственно, в ходе события 422 список обновлений возвращается дочернему узлу 404 службы обновлений без идентификации обновления программного обеспечения, принятого в ходе события 406. Согласно аспектам настоящего изобретения в списке обновлений указаны все обновления, «доступные» на родительском узле 402 службы обновлений, согласно запросу синхронизации. Согласно одному варианту осуществления список обновлений идентифицирует каждую информацию «доступного» обновления посредством уникального идентификатора, связанного с обновлением.

В ходе события 424, поскольку список обновлений пуст, т.е. в данный момент на родительском узле 402 службы обновлений нет «доступных» обновлений, процесс обновления дочернего узла 404 службы обновлений просто задерживается или замирает на определенный период времени. Согласно данному примеру в течение этого периода задержки, в ходе события 426, администратор на родительском узле 402 службы обновлений авторизует обновление программного обеспечения, принятое в ходе события 406, на распространение на дочерний узел 404 службы обновлений.

В ходе события 428 (фиг.4В) дочерний узел 404 службы обновлений вновь начинает процесс автоматического обновления, аутентифицируя и авторизуя себя с помощью родительского узла 402 службы обновлений. В ответ, в ходе события 430 родительский узел 402 службы обновлений возвращает жетон авторизации дочернему узлу 404 службы обновлений.

В ходе события 432 дочерний узел 404 службы обновлений подает запрос, совместно с жетоном авторизации, на родительский узел 402 службы обновлений. В ходе события 434 родительский узел 402 службы обновлений возвращает каталог обновлений продуктов дочернему узлу 404 службы обновлений. В ходе события 436 дочерний узел 404 службы обновлений выбирает продукты из каталога обновлений, для которых нужны обновления. В ходе события 438 дочерний узел 404 службы обновлений подает запрос синхронизации обновлений, идентифицирующий эти выбранные продукты с помощью жетона авторизации.

Поскольку дочернему узлу 404 службы обновлений уже разрешено получить обновление программного обеспечения, ранее принятое в ходе события 406, в ходе события 440 родительский узел 402 службы обновлений определяет, что обновление программного обеспечения «доступно» для дочернего узла 404 службы обновлений, и включает соответствующую информацию обновления в список обновлений. Затем, в ходе события 442 родительский узел 402 службы обновлений возвращает список обновлений, теперь идентифицирующий обновление программного обеспечения, принятое в ходе события 406, дочернему узлу 404 службы обновлений.

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

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

Согласно фиг.4В для обновления, идентифицированного в списке обновлений, в ходе события 444 дочерний узел 404 службы обновлений запрашивает метаданные обновления для «доступного» обновления программного обеспечения согласно его уникальному идентификатору в списке обновлений. Как и для большинства других коммуникационных обменов с родительским узлом 402 службы обновлений, запрос обновления подается с жетоном авторизации. Заметим, что, хотя в показанном примере все метаданные обновлений загружаются в одном сеансе доступа, согласно альтернативным аспектам настоящего изобретения (не показаны) метаданные обновления можно загружать в течение более одного сеанса доступа. Например, в первом сеансе доступа сначала загружают только элементы метаданных обновления, которые необходимы для определения, является ли обновление программного обеспечения применимым и/или желательным, например, правила применимости и зависимости от других обновлений программного обеспечения. Затем, после того, как определено, что обновление применимо и/или желательно, можно получить остальные метаданные. В ответ, в ходе события 446 родительский узел 402 службы обновлений возвращает метаданные обновления для обновления программного обеспечения дочернему узлу 404 службы обновлений, который, в свою очередь, сохраняет метаданные обновления в хранилище 216 информации обновления.

В необязательном порядке в ходе события 448 дочерний узел 404 службы обновлений подает запрос на загрузку полезной нагрузки обновления с родительского узла 402 службы обновлений. В ответ, в ходе события 450 родительский узел 402 службы обновлений возвращает полезную нагрузку обновления дочернему узлу 404 службы обновлений, который, в свою очередь, сохраняет ее в хранилище 214 содержимого обновлений. Согласно альтернативному варианту осуществления дочерний узел 404 службы обновлений загружает полезную нагрузку обновления из места хранения, которое может не являться родительским узлом 402 службы обновлений, из места, указанного метаданных обновления.

Поскольку деятельность по обновлению оказалась теперь на дочернем узле 404 службы обновлений, в ходе события 452 дочерний узел службы обновлений генерирует и подает отчет об обновлении на родительский узел 402 службы обновлений, в котором описаны действия по обновлению, которые только что были предприняты. После этого дочерний узел 404 службы обновлений снова задерживается до следующего раза, когда запланировано провести процесс обновления (не показано).

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

На фиг.5 показана логическая блок-схема иллюстративной процедуры 500, выполняемой на дочернем узле службы обновлений, например, на корпоративном узле 104 службы обновлений, показанном на фиг.1, для периодического получения обновлений от своего родительского узла службы обновлений. Начиная с блока 502 дочерний узел службы обновлений получает синхронизированный список обновлений из «доступных» обновлений от родительского узла службы обновлений. Получение синхронизированного списка обновлений из «доступных» обновлений от родительского узла службы обновлений описано ниже со ссылкой на фиг.6.

На фиг.6 показана логическая блок-схема иллюстративной подпроцедуры 600, пригодной для использования в иллюстративной процедуре 500, изображенной на фиг.5, для получения синхронизированного списка обновлений из «доступных» обновлений от родительского узла службы обновлений. Начиная с блока 602, как было описано выше со ссылкой на фиг.4А и 4В, дочерний узел службы обновлений аутентифицирует и авторизует себя с помощью родительского узла службы обновлений и, в случае правильной аутентификации и авторизации, принимает жетон авторизации. На блоке 604 с помощью жетона авторизации дочерний узел службы обновлений устанавливает параметры связи с родительским узлом службы обновлений. Установление параметров связи позволяет родительскому и дочернему узлам службы обновлений правильно устанавливать общую основу, которую понимает как предок, так и потомок. Параметры связи включают в себя, но не только: протоколы или версии передачи обновлений; группировки продуктов; и т.д.

Установив параметры связи с родительским узлом службы обновлений, дочерний узел службы обновлений на блоке 606 получает каталог обновлений продуктов, описывающий программные продукты, для которых родительский узел службы обновлений обеспечивает/распространяет обновления. На блоке 608 дочерний узел службы обновлений выбирает те обновления программных продуктов, для которых в данный момент нужны обновления. На блоке 610 дочерний узел службы обновлений подает запрос синхронизации обновлений на родительский узел службы обновлений, содержащий жетон авторизации и «анкер», связанный с выбранными программными продуктами, идентифицирующий текущую ревизию и обновления уже на дочернем узле службы обновлений.

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

Возвращаясь к фиг.5, после получения синхронизированного списка обновлений от родительского узла службы обновлений, на блоке 504 принятия решения производится определение, «доступны» ли какие-либо обновления программного обеспечения для загрузки с родительского узла службы обновлений. Это определение производится в зависимости от того, перечислены ли какие-либо идентификаторы обновлений в синхронизированном списке обновлений. В отсутствие обновлений программного обеспечения, «доступных» в настоящее время для загрузки, иллюстративная процедура 500 переходит к блоку 510 задержки, где иллюстративная процедура задерживается/спит, пока не начнется следующий период обновления. Альтернативно, при наличии обновлений, «доступных» для загрузки с родительского узла службы обновлений, на блоке 506 дочерний узел службы обновлений получает обновления от родительского узла службы обновлений. Получение «доступных» обновлений от родительского узла службы обновлений описано ниже со ссылкой на фиг.7.

На фиг.7 показана логическая блок-схема иллюстративной подпроцедуры 700, пригодной для использования в иллюстративной процедуре 500, изображенной на фиг.5, для получения «доступных» обновлений программного обеспечения от родительского узла службы обновлений. Начиная с блока 702 выбирают первый идентификатор обновления с списке обновлений. На блоке 704 дочерний узел службы обновлений получает метаданные обновления, соответствующие выбранному идентификатору обновления, от родительского узла службы обновлений и сохраняет их в хранилище 216 информации обновлений.

Согласно одному варианту осуществления на блоке 706 дочерний узел службы обновлений получает полезную нагрузку обновления, соответствующую выбранному идентификатору обновления от родительского узла службы обновлений и сохраняет полезную нагрузку обновления в хранилище 212 содержимого обновлений. В необязательном порядке содержимое обновления не требуется немедленно загружать в дочерний узел службы обновлений. Как отмечено выше, дочерний узел службы обновлений можно избирательно конфигурировать, чтобы загружать обновления от родительского узла службы обновлений «точно вовремя». Согласно этой необязательной обработке, как показано на фиг.7, вместо того, чтобы переходить от блока 704 к блоку 706, иллюстративная процедура 700 в необязательном порядке переходит от блока 704 к блоку 708.

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

Вновь возвращаясь к фиг.5, получив «доступные» обновления от родительского узла службы обновлений, на блоке 508 дочерний узел службы обновлений сообщает о действиях по обновлению родительскому узлу службы обновлений. Затем, на блоке 510 задержки иллюстративная процедура 500 задерживается/засыпает на определенный период времени до следующего периода обновления, после чего переходит к блоку 502, чтобы повторить вышеописанные операции обновления.

Согласно фиг.5 на блоке 504 принятия решения даже в отсутствие «доступных» обновлений на родительском узле службы обновлений дочерний узел службы обновлений можно в необязательном порядке сконфигурировать так, чтобы он сообщал о своих действиях по обновлению родительскому узлу службы обновлений. Согласно этой альтернативной конфигурации в отсутствие доступных обновлений иллюстративная процедура 500 может перейти к блоку 508 для сообщения о действиях по обновлению.

На фиг.8 показана логическая блок-схема иллюстративной процедуры 800, реализованной на родительском узле службы обновлений для генерации синхронизированного списка обновлений, идентифицирующего «доступные» обновления в ответ на запрос синхронизации обновлений от дочернего узла службы обновлений. Начиная с блока 802, родительский узел службы обновлений принимает запрос синхронизации обновлений от дочернего узла службы обновлений для списка обновлений, идентифицирующего «доступные» обновления. На блоке 804 выбирают первый программный продукт, идентифицированный в запросе синхронизации обновления.

На блоке 806 принятия решения производится определение, имеются ли какие-либо доступные обновления для идентифицированного программного продукта. Это определение производится в соответствии с метаданными для программного продукта, хранящимися в хранилище 216 информации обновлений, в соответствии с анкером обновлений, обеспеченным дочерним узлом службы обновлений, и в соответствии с правилами распространения, связанными с группой, которой принадлежит дочерний узел службы обновлений. В соответствии с этим определением при наличии «доступных» обновлений на блоке 808 уникальные идентификаторы обновлений, связанные с «доступными» обновлениями, записываются в список обновлений. После записи уникальных идентификаторов обновлений для «доступных» обновлений в список обновлений, на блоке 810 принятия решений производится определение, имеются ли какие-либо еще программные продукты, идентифицированные в запросе синхронизации обновлений. При наличии дополнительных обновлений программных продуктов в запросе синхронизации обновлений на блоке 814 родительский узел службы обновлений выбирает следующий программный продукт, идентифицированный в запросе синхронизации обновлений, и возвращается к блоку 806 принятия решений для определения наличия «доступных» обновлений для выбранного программного продукта. Альтернативно, в отсутствие дополнительных программных продуктов, идентифицированных в запросе синхронизации обновлений, на блоке 814 список обновлений возвращается дочернему узлу службы обновлений. Затем иллюстративная подпроцедура 800 заканчивается.

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

Изобретение относится к программному обеспечению и компьютерным сетям. Техническим результатом изобретения является расширение архитектуры распространения обновлений программного обеспечения и повышение эффективности контроля за распространением обновлений. Технический результат достигается благодаря тому, что корневой узел службы обновлений и множество узлов службы обновлений организованы в иерархическом порядке так, что корневой узел службы обновлений является родительским узлом службы обновлений по отношению к одному дочернему узлу службы обновлений, первый дочерний узел службы обновлений из множества дочерних узлов службы обновлений является родительским узлом по отношению ко второму дочернему узлу службы обновлений, корневой узел службы обновлений включает в себя первый программный интерфейс приложений API администрирования и первый пользовательский интерфейс администрирования, которые принимают от администратора первый набор правил для распространения обновлений программного обеспечения в некоторые из множества дочерних узлов службы обновлений. Узел службы обновлений содержит веб-службу обновлений, модуль обновлений клиентов, модуль обновлений потомков, модуль отчетов, модуль аутентификации/авторизации, программный интерфейс приложений API администрирования, пользовательский интерфейс администрирования, хранилище содержимого обновлений и хранилище информации обновлений. 6 н. и 23 з.п. ф-лы, 9 ил.

1. Система распространения обновлений программного обеспечения для распространения обновления программного обеспечения по сети связи для распространения на компьютеры-клиенты, содержащая:
корневой узел службы обновлений и
множество дочерних узлов службы обновлений, выполненных с возможностью распространения обновлений программного обеспечения на клиентские компьютеры,
в которой корневой узел службы обновлений и упомянутое множество узлов службы обновлений организованы в иерархическом порядке, так что корневой узел службы обновлений является родительским узлом службы обновлений по отношению к, по меньшей мере, одному дочернему узлу службы обновлений,
причем каждый из множества узлов службы обновлений имеет родительский узел службы обновлений, и
при этом первый дочерний узел службы обновлений из упомянутого множества дочерних узлов службы обновлений является родительским узлом службы обновлений по отношению ко второму дочернему узлу службы обновлений из упомянутого множества дочерних узлов службы обновлений,
причем корневой узел службы обновлений включает в себя первый программный интерфейс приложений (API) администрирования и первый пользовательский интерфейс администрирования, причем первый API администрирования и первый пользовательский интерфейс администрирования выполнены с возможностью приема от администратора первого набора правил для распространения обновлений программного обеспечения в, по меньшей мере, некоторые из упомянутого множества дочерних узлов службы обновлений;
при этом упомянутый, по меньшей мере, первый дочерний узел службы обновлений включает в себя второй API администрирования, отличный от первого API администрирования, и второй пользовательский интерфейс администрирования, отличный от первого пользовательского интерфейса администрирования, причем второй API администрирования и второй пользовательский интерфейс администрирования выполнены с возможностью приема второго набора правил для распространения обновлений программного обеспечения из упомянутого первого дочернего узла службы обновлений в, по меньшей мере, второй дочерний узел службы обновлений, при этом второй набор правил устанавливает второй дочерний узел службы обновлений, как принадлежащий к первой группе и определяет подмножество обновлений программного обеспечения, доступных для первой группы;
при этом корневой узел службы обновлений получает первое обновление программного обеспечения от поставщика программного обеспечения, и при этом, по меньшей мере, один из множества дочерних узлов службы обновлений получает первое обновление программного обеспечения для распространения путем получения первого обновления программного обеспечения от своего родительского узла службы обновлений.

2. Система распространения обновлений программного обеспечения по п.1, в которой корневой узел службы обновлений содержит:
хранилище обновлений для хранения обновлений программного обеспечения,
веб-службу обновлений, через которую корневой узел службы обновлений распространяет обновления программного обеспечения на свои дочерние узлы службы обновлений по сети связи, и
интерфейс поставщика программного обеспечения, через который поставщик программного обеспечения передает свое обновление программного обеспечения по сети связи на корневой узел службы обновлений.

3. Система распространения обновлений программного обеспечения по п.2, в которой каждый из множества дочерних узлов службы обновлений содержит:
хранилище обновлений для хранения обновлений программного обеспечения,
веб-службу обновлений, через которую дочерний узел службы обновлений получает обновления программного обеспечения от своего родительского узла службы обновлений по сети связи и через которую дочерний узел службы обновлений распространяет обновления программного обеспечения на свои дочерние узлы службы обновлений по сети связи, и
модуль обновлений потомков для определения, какие обновления программного обеспечения доступны для распространения на его дочерние узлы службы обновлений согласно установленным правилам.

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

5. Система распространения обновлений программного обеспечения по п.4, отличающаяся тем, что хранилище обновлений содержит хранилище содержимого обновлений, в котором хранится полезная нагрузка обновлений для обновления программного обеспечения, и хранилище информации обновлений, в котором хранятся метаданные обновлений для обновления программного обеспечения.

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

7. Система распространения обновлений программного обеспечения по п.6, отличающаяся тем, что дочерний узел службы обновлений получает полезную нагрузку обновлений для обновления программного обеспечения от родительского узла службы обновлений «точно вовремя».

8. Система распространения обновлений программного обеспечения по п.4, отличающаяся тем, что модуль обновлений клиентов распространяет обновления программного обеспечения на компьютеры-клиенты согласно правилам, установленным администратором через API администрирования с использованием пользовательского интерфейса администрирования.

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

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

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

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

13. Узел службы обновлений по п.12, отличающийся тем, что хранилище обновлений содержит хранилище содержимого обновлений, в котором хранится полезная нагрузка обновления для обновления программного обеспечения, и хранилище информации обновлений, в котором хранятся метаданные обновления для обновления программного обеспечения.

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

15. Узел службы обновлений по п.14, отличающийся тем, что узел службы обновлений получает полезную нагрузку обновления для обновления программного обеспечения от родительского узла службы обновлений «точно вовремя».

16. Узел службы обновлений по п.12, отличающийся тем, что модуль обновлений распространяет обновления программного обеспечения на компьютеры-клиенты согласно правилам, установленным администратором через API администрирования с использованием пользовательского интерфейса администрирования.

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

18. Способ получения дочерним узлом службы обновлений обновления программного обеспечения от родительского узла службы обновлений в системе распространения обновлений программного обеспечения по п.1 по сети связи, причем способ содержит этапы, на которых:
(a) получают от родительского узла службы обновлений список программных продуктов, для которых родительский узел службы обновлений обеспечивает обновления программного обеспечения;
(b) выбирают программный продукт из списка программных продуктов;
(c) подают запрос на родительский узел службы обновлений на предмет доступных обновлений программного обеспечения, соответствующих выбранному программному продукту;
(d) получают список обновлений программного обеспечения, идентифицирующий обновления программного обеспечения для выбранного программного продукта, доступные дочернему узлу службы обновлений;
(e) получают каждое обновление программного обеспечения в списке обновлений программного обеспечения от родительского узла службы обновлений.

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

20. Способ по п.19, отличающийся тем, что на этапе получения полезной нагрузки обновления получают полезную нагрузку обновления «точно вовремя», когда это необходимо дочернему узлу службы обновлений или клиентскому узлу службы обновлений.

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

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

23. Способ по п.18, отличающийся тем, что этапы (а)-(е) выполняют на периодической основе.

24. Компьютерно-считываемый носитель, несущий компьютерно-выполняемые команды, которые при выполнении на компьютере осуществляют способ получения дочерним узлом службы обновлений обновления программного обеспечения от родительского узла службы обновлений в системе распространения обновлений программного обеспечения по п.1 по сети связи, упомянутый способ содержит этапы, на которых:
(a) получают от родительского узла службы обновлений список программных продуктов, для которых родительский узел службы обновлений обеспечивает обновления программного обеспечения;
(b) выбирают программный продукт из списка программных продуктов;
(c) подают запрос на родительский узел службы обновлений на предмет доступных обновлений программного обеспечения, соответствующих выбранному программному продукту;
(d) получают список обновлений программного обеспечения, идентифицирующий обновления программного обеспечения для выбранного программного продукта, доступные дочернему узлу службы обновлений;
(e) получают каждое обновление программного обеспечения в списке обновлений программного обеспечения от родительского узла службы обновлений.

25. Способ распространения обновлений программного обеспечения на дочерний узел службы обновлений из родительского узла службы обновлений, в системе распространения обновлений программного обеспечения по сети связи, причем дочерний и родительский узлы службы обновлений входят в состав иерархии узлов службы обновлений, содержащей корневой узел службы обновлений, способ осуществляется на родительском узле службы обновлений и содержит этапы, на которых:
(a) принимают запрос каталога обновлений программного обеспечения от дочернего узла службы обновлений, причем каталог обновлений программного обеспечения идентифицирует программные продукты, для которых родительский узел службы обновлений обеспечивает обновления программного обеспечения;
(b) возвращают каталог обновлений программного обеспечения на дочерний узел службы обновлений;
(c) принимают запрос списка обновлений программного обеспечения для выбранного программного продукта, доступных дочернему узлу службы обновлений;
(d) определяют, доступны ли какие-либо обновления программного обеспечения для выбранного программного продукта дочернему узлу службы обновлений;
(e) возвращают список обновлений программного обеспечения, идентифицирующий те обновления программного обеспечения для выбранного программного продукта, которые определены как доступные дочернему узлу службы обновлений, на дочерний узел службы обновлений, причем список обновлений программного обеспечения идентифицирует доступные обновления программного обеспечения согласно уникальному идентификатору обновления;
(f) принимают запрос обновления на предмет метаданных, соответствующих обновлению программного обеспечения, от дочернего узла службы обновлений, причем запрос обновления идентифицирует доступное обновление программного обеспечения по уникальному идентификатору обновления; и
(g) возвращают метаданные обновления, соответствующие обновлению программного обеспечения, идентифицированному в запросе обновления, причем метаданные обновления содержат информацию, соответствующую обновлению программного обеспечения, в том числе ссылку для получения соответствующей полезной нагрузки обновления.

26. Способ по п.25, отличающийся тем, что дополнительно содержит этапы, выполняемые до этапов (a)-(g), на которых:
принимают запрос аутентификации и авторизации от дочернего узла службы обновлений,
определяют, разрешено ли дочернему узлу службы обновлений получать обновления программного обеспечения от родительского узла службы обновлений, и
если дочернему узлу службы обновлений разрешено получать обновления программного обеспечения от родительского узла службы обновлений, возвращают жетон авторизации дочернему узлу службы обновлений и
каждую последующую передачу от дочернего узла службы обновлений на родительский узел службы обновлений осуществляют с помощью жетона авторизации.

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

28. Способ по п.25, отличающийся тем, что запрос списка обновлений программного обеспечения для выбранного программного продукта содержит анкер обновления, идентифицирующий последнюю информацию обновлений на дочернем узле службы обновлений, соответствующую выбранному программному продукту, и
при определении, доступны ли какие-либо обновления программного обеспечения для выбранного программного продукта дочернему узлу службы обновлений, определяют, существуют ли какие-либо обновления программного обеспечения, доступные дочернему узлу службы обновлений, в соответствии с анкером обновления и согласно правилам, связанным с распространением обновлений программного обеспечения на дочерний узел службы обновлений.

29. Компьютерно-считываемый носитель, несущий компьютерно-выполняемые команды, которые, при выполнении на компьютере родительского узла службы обновлений, осуществляют способ распространения обновлений программного обеспечения на дочерний узел службы обновлений из родительского узла службы обновлений, в системе распространения обновлений программного обеспечения по сети связи, причем дочерний и родительский узлы службы обновлений входят в состав иерархии узлов службы обновлений, содержащей корневой узел службы обновлений, упомянутый способ содержит этапы, на которых:
(a) принимают запрос каталога обновлений программного обеспечения от дочернего узла службы обновлений, причем каталог обновлений программного обеспечения идентифицирует программные продукты, для которых родительский узел службы обновлений обеспечивает обновления программного обеспечения;
(b) возвращают каталог обновлений программного обеспечения на дочерний узел службы обновлений;
(c) принимают запрос списка обновлений программного обеспечения для выбранного программного продукта, доступных дочернему узлу службы обновлений;
(d) определяют, доступны ли какие-либо обновления программного обеспечения для выбранного программного продукта дочернему узлу службы обновлений;
(e) возвращают список обновлений программного обеспечения, идентифицирующий те обновления программного обеспечения для выбранного программного продукта, которые определены как доступные дочернему узлу службы обновлений, на дочерний узел службы обновлений, причем список обновлений программного обеспечения идентифицирует доступные обновления программного обеспечения согласно уникальному идентификатору обновления;
(f) принимают запрос обновления на предмет метаданных, соответствующих обновлению программного обеспечения, от дочернего узла службы обновлений, причем запрос обновления идентифицирует доступное обновление программного обеспечения по уникальному идентификатору обновления; и
(g) возвращают метаданные обновления, соответствующие обновлению программного обеспечения, идентифицированному в запросе обновления, причем метаданные обновления содержат информацию, соответствующую обновлению программного обеспечения, в том числе ссылку для получения соответствующей полезной нагрузки обновления.