СИСТЕМА И СПОСОБ ДЛЯ ОБНОВЛЕНИЯ ИНСТАЛЛЯЦИОННЫХ КОМПОНЕНТОВ В СЕТЕВОЙ СРЕДЕ Российский патент 2009 года по МПК G06F9/445 

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

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

Описание известного уровня техники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Клиентское вычислительное устройство 110 может быть любым вычислительным устройством, которое сохраняет и исполняет программные приложения 114. Клиентское вычислительное устройство 110 может быть образовано любым из целого ряда различных вычислительных устройств, включающих в себя, без ограничения перечисленным, персональные компьютеры (ПК), персональные цифровые помощники (ПЦП), мобильные телефоны, двусторонние пейджеры и т.п. Специалистам будет понятно, что архитектура клиентского вычислительного устройства 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 обновлений передает идентификационный файл аутентификации в клиентское вычислительное устройство 120. Как показано на фиг.3, аутентифицированное клиентское вычислительное устройство 120 затем инициирует синхронизацию доступных обновлений с сервером 120 обновлений. В проиллюстрированном варианте настоящего изобретения запрос на синхронизацию также соответствует протокольному взаимодействию для обновления между клиентским вычислительным устройством 110 и службой 120 обновлений, которое более подробно описано ниже. После выполнения синхронизации клиентское вычислительное устройство 110 получает информацию обо всех применимых обновлениях программного обеспечения и информацию, описывающую эти обновления. Однако в иллюстративном варианте настоящего изобретения не был загружен никакой программный код для реализации обновления.

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

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

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

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

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

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

На фиг.7 изображен алгоритм выполнения программы 700 обработки обновления программного обеспечения, иллюстрирующий взаимодействие между клиентским вычислительным устройством 110 и службой 120 обновлений программного обеспечения согласно настоящему изобретению. В блоке 702 служба 120 обновлений программного обеспечения разрешает доступ к клиентскому компьютеру 110. В иллюстративном варианте настоящего изобретения авторизация доступа к клиентскому компьютеру может включать в себя создание в сервере cookie-файлов (идентификационных файлов) для разрешения доступа к тем обновлениям программного обеспечения, которые связаны с конкретной группой компьютеров. Более подробно процесс авторизации описан ниже со ссылками на фиг.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, имеющих конкретную торговую марку и конкретное аппаратное устройство, и ограничить передачу загрузки конкретного программного обеспечения этой целевой группой.

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

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

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

Как показано на фиг.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 создает второй авторизационный идентификационный файл, связанный с целевой группой "ИНП", потому что и второй клиентский авторизационный плагин 826, и второй серверный авторизационный плагин 829 связаны с целевой группой "ИНП". Третий авторизационный идентификационный файл не создается, так как клиентское вычислительное устройство 110 не имеет авторизационного плагина указывающего, что оно является членом целевой "бета-группы".

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

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

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

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

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

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

В одном иллюстративном варианте настоящего изобретения серверный идентификационный файл может содержать зашифрованную информацию, которая идентифицирует одну или более соответствующих целевых групп. Кроме того, серверный идентификационный файл может содержать данные истечения срока, которые хранятся как в формате открытого текста, так и в зашифрованном формате. Данные истечения срока, хранящиеся в открытом текстовом формате, используются клиентским вычислительным устройством 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®. Как описано ниже, набор предпосылок может идентифицировать одно или более обновлений, которые должны были быть инсталлированы раньше. Например, как более подробно описано ниже со ссылкой на фиг.9, отдельное обновление может содержать список предпосылок, в котором перечислены другие обновления, необходимые для правильной установки отдельного обновления. В других примерах, как показано на фиг.9, набор предпосылок может содержать использование логических операторов для определения дополнительных более сложных правил предпосылок.

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

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

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

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

Как показано на фиг.9 и более подробно описано ниже, каждое обновление содержит правило применимости, которое указывает условия инсталляции обновления. Например, первое обновление 911 требует инсталляции английской версии операционной системы. Второе обновление 912 требует инсталляции Windows^® XP, версии SPI. В другом примере шестое обновление 921 требует инсталляции программной заплаты с названием XPPATCH1. Соответственно, клиентское вычислительное устройство 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 метаданных и обработать там для идентификации других родственных обновлений, доступных для инсталляции в клиентском вычислительном устройстве 110.

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

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

Как показано на фиг.10, первый запрос 1051 на синхронизацию передается из клиентского вычислительного устройства 110 в сервер 123 метаданных. В данном примере клиентский кэш обновлений не будет содержать обновлений, если это первое выполнение данного метода. Следовательно, первый запрос 1051 на синхронизацию не содержит идентификатор кэшированного обновления. В ответ на прием запроса на синхронизацию, как показано в блоке 1052, сервер 1234 метаданных определяет, содержит ли данный запрос на синхронизацию по меньшей мере один идентификатор обновления. Если определено, что данный запрос на синхронизацию не содержит идентификатор обновления, то сервер 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 связаны с целевыми группами ИНП и "Все компьютеры", все выбранные обновления посылаются клиентскому вычислительному устройству 110.

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

Затем, как показано в боке 1054, клиентское вычислительное устройство 110 обрабатывает компоненты команд каждого принятого обновления, чтобы определить, можно ли удовлетворить условие, заданное в правилах применимости. На фиг.9 клиентское вычислительное устройство 110 обрабатывает компоненты команды принятых обновлений 911-915. В целях иллюстрации настоящего изобретения в данном примере предполагается, что операционная система клиентского вычислительного устройства 110 является английской версией Windows® XP SP1. Также предполагается, что клиентское вычислительное устройство 110 является компьютером марки DELL с 32-разрядным процессором Х86. Следовательно, при обработке компонентов команды примерного набора обновлений клиентское вычислительное устройство 110 определит, что условие, заданное в первом обновлении 911, удовлетворено, так как данный компьютер имеет английскую версию ОС. Условие, заданное во втором обновлении 912, будет удовлетворено, потому что данная операционная система является системой Windows® XP SP1. Условие, заданное в третьем обновлении 913, будет удовлетворено, потому что данное клиентское вычислительное устройство имеет процессор Х86. Условие, заданное в пятом обновлении 915, будет удовлетворено, потому что данное клиентское вычислительное устройство 110 является ПК DELL. В результате, первое обновление 911, второе обновление 912, третье обновление 913 и пятое обновление 915 сохраняются в первом компоненте клиентского кэша обновлений. Условие, заданное в четвертом обновлении 914, не будет удовлетворено, потому что клиентское вычислительное устройство 110 не имеет 64-разрядного процессора. Следовательно, четвертое обновление 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. В данном примере информация, относящаяся к шестому обновлению 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. В одном варианте принятые локальные данные могут отображаться на веб-странице. В данном примере локальные данные могут быть приняты клиентом для шестого и восьмого обновлений 921 и 931. Если локальные данные хранятся в базовых обновлениях 911, 912, 913 и 915, то локальные данные для этих обновлений будут также получены клиентом.

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

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

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

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

Согласно еще одному аспекту изобретения служба 120 обновления программного обеспечения может обеспечивать способ выбора и передачи информации между службой обновления программного обеспечения и клиентским вычислительным устройством 110. Фиг.12А и 12В иллюстрируют подпрограмму 1200 обработки обновления программного обеспечения, выполняемую клиентским вычислительным устройством 110, для нахождения и инсталляции запрошенного программного обеспечения, согласно настоящему изобретению. Как описано выше, подпрограмма 1200 обработки обновления программного обеспечения может быть реализована после того, как сделан или получен выбор обновлений программного обеспечения. На фиг.12А в блоке 1202 компонент 11 управления обновлениями создает агент 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 обновления может идентифицировать весь файл для загрузки.

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

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

В блоке 1216 агент 118 обновления принимает запрошенную информацию обновления. В одном иллюстративном варианте изобретения запрошенная информация обновления может передаваться с применением двух методов. При первом методе, называемом ручным обновлением, в службу 120 обновления посылается запрос на обновление, в котором запрашивается прямой ответ доставки данных НТТР. При этом служба 120 обновления может использовать всю ширину полосы, доступную для передачи запрошенных данных агенту 118 обновления. При втором методе, который называется автоматическим обновлением, в службу 120 обновления посылается запрос на обновление, в котором запрашивается непрямой ответ доставки данных НТТР. В этом ответе служба 120 обновления передает запрошенные данные как фоновый процесс. Фоновый процесс можно реализовать таким образом, чтобы использовать минимальную часть имеющейся ширины полосы. Кроме того, фоновый процесс может прерваться во время загрузки и возобновиться в следующее доступное время. Описание системы и способа передачи запрашиваемых данных с помощью фонового процесса содержится в совместно переуступленной и совместно поданной патентной заявке США 09/505735 на "Систему и способ для передачи данных по сети" от 16 февраля 2000 г., включенной в настоящее описание посредством ссылки. Специалистам будет понятно, что высокоприоритетная и фоновая доставка данных не обязательно отражают приоритет выбранного обновления программного обеспечения, а скорее отражают, какая ширина полосы выделена для получения информации обновления.

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

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

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

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

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

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

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

Изобретение относится к системам и способам для управления инсталляцией файлов в клиентском вычислительном устройстве. Техническим результатом является обеспечение управления инсталляцией файлов в вычислительном устройстве. Клиентское вычислительное устройство получает инсталляционную информацию, идентифицирующую версию основного инсталляционного компонента, хранящегося в клиентском вычислительном устройстве. Инсталляционная информация также содержит дельта-заплату инсталляционного компонента, которую объединяют с основным инсталляционным компонентом для создания обновленного инсталляционного компонента. Обновленный инсталляционный компонент используют для инсталляции одного или более файлов в клиентском вычислительном устройстве. После завершения инсталляции обновленный инсталляционный компонент можно удалить. 3 н. и 13 з.п. ф-лы, 14 ил.

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

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

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

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

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

6. Способ по п.1, в котором основной инсталляционный компонент выбирается из набора основных инсталляционных компонентов, причем набор основных инсталляционных компонентов организован согласно версии основных инсталляционных компонентов, и при этом выбор основного инсталляционного компонента включает в себя информацию выбора конкретной версии основного инсталляционного компонента из набора основных инсталляционных компонентов.

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

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

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

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

11. Способ по п.1, в котором прием выбора одного или более доступного обновления компонентов программного обеспечения содержит прием пользовательского выбора одного или более доступного обновления компонентов программного обеспечения через пользовательский интерфейс обновления на основе Web.

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

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

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

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

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