Система обновления, основанная на различиях версий

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

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

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

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

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

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

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

Заменить строку 102 на [<Данные>];

Добавить к строке 103 [<Данные>];

Удалить строку 121.

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

На данный момент появляется тенденция увеличивать частоту обновлений через Интернет до 15 минут, а иногда даже и до 5 минут (особенно часто она проявляется в области борьбы с различными вирусами, троянами, спам-сообщениями, червями, рекламным и шпионским программным обеспечением). Для обеспечения такого обмена обновлениями между клиентским и серверным компьютерами требуется структуризация системы сообщений между ними.

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

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

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

Одна из систем обновления описана, например, в патенте US 6,651,249, где клиенту нужно загрузить один или более каталогов и затем запустить их на клиентской стороне. Это увеличивает нагрузку на сервер и увеличивает количество обработок, необходимых клиентской стороне.

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

Раскрытие полезной модели

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

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

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

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

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

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

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

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

В частном варианте реализации средство контроля обновлений также предназначено для инициализации средства обновления, если обновление является критическим.

В частном варианте реализации средство контроля обновлений также предназначено для составления очереди обновлений, если обновления не являются критическими.

В частном варианте реализации средство контроля обновлений также предназначено для инициализации средства обновления и передаче ему очереди обновлений в определенный момент времени.

В частном варианте реализации средство контроля обновлений устанавливает момент времени при возникновении следующих ситуаций:

(а) количество обновлений в очереди превышает заранее предустановленное значение;

(б) наступает момент времени по расписанию.

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

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

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

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

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

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

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

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

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

Фиг.2 показывает вариант схемы приложения с набором файлов для обновления.

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

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

Фиг.5 показывает вариант реализации алгоритма обновления на стороне клиента.

Фиг.6 показывает другой вариант реализации алгоритма обновления на стороне клиента.

Фиг.7 показывает пример компьютерной системы, с помощью которой может применяться представленная полезная модель.

Описание вариантов осуществления полезной модели

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

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

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

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

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

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

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

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

Средство предоставления информации о последних версиях файлов содержит множество файлов, каждый из которых имеет историю изменений. Данные файлы обычно располагаются на FTP, DFTP, HTTP серверах и доступны для загрузки. Содержимое файла содержит данные об актуальности данной базы данных. Файл описания состояний может содержать информацию об именах файлов, а также их хэш-суммы. Для каждого файла помимо его последнего состояния сервер хранит и множество различий. Каждый файл коррекции содержит информацию, необходимую для преобразования содержимого файла версии CURRENT - X в текущую версию CURRENT или в версию CURRENT - Y, где Y<X. Имена файлов могут быть в этом случае сформированы следующим образом:

<имя файла>. <хэш-сумма>

Количество различий в общем случае относится к понятию «степени» обновления. Другими словами можно сказать, что когда размер суммы различий превышает размер финального состояния файла, то проще загрузить именно финальное состояние. Однако, следует учитывать некоторые поправки к принятию различий, связанные с затратами на то или иное решение. Например, решение о преобразовании файла или загрузке файла целиком зависит от того, насколько много различий (преобразование производится при различиях <80%).

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

Каждый раз при появлении новой версии, обновляется и множество различий, а также публикуется новое множество файлов и различий.

Итак, для любых Файла 1 и Файла 2 можно создать некоторое различие такое, что Файл 1+=Файл 2. Для создания последовательности обновлений файлы, которые представляют не финальное состояние, могут быть сравнены друг с другом для вычисления различия между ними. Данные различия затем сохраняются в некоторой компактной форме. Если различий больше, чем размер самого файла, то принимается решение о том, чтобы сохранить сам файл, а не различия.

Отметим, что для некоторых файлов различия создаются достаточно легко, а для других - нет. Например, текстовые файлы, ASCII файлы, MS Word файлы, и т.д. могут легко сравниваться со своими следующими версиями. Однако существуют зашифрованные файлы, упакованные файлы (например, ZIP, RAR и т.д.), для которых сложно просчитать разницу, даже если были незначительные изменения в оригинальных файлах (тех файлах, для которых было проведено шифрование или сжатие). И обычно результатом сравнения двух версий данного файла приведет к созданию большого числа различий.

На Фиг.1 изображена блок-диаграмма, отображающая основную систему, представленную ранее. Как показано на Фиг.1, существует три основных элемента системы: компьютер пользователя 102 (или клиентский компьютер), средство предоставления информации о последних версиях файлов 106 и посредник обновления 104, которые может находиться как на разных компьютерах, так и на одном. Посредник обновления 104 обычно является сервером, таким как FTP или HTTP серверами, с которыми может сообщаться клиент 102, например, используя открытые сети (LAN, WAN и т.д.)

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

На примере антивирусного приложения представлен вариант реализации представленной полезной модели. На клиентском компьютере 102 установлено антивирусное программное обеспечение 120, например, антивирус, состоящий из исполняемого кода (средства хранения модулей приложения 108(x) и средства хранения файлов данных 110(x)). Вместе они составляют множество файлов 109(x), которое периодически необходимо обновлять. В описанном варианте реализации значение «x» обозначает версию файла, включая версию, которую сервер 104 не поддерживает. Значение n - текущая версия, значение (n+1) - следующая версия, которая появляется в случае, если что-то необходимо изменить, и, другими словами, будет являться последней доступной версией.

Также на стороне клиента находится средство обновления 122, которое основываясь на текущем состоянии файлов 109(x) и информации, полученной от посредника обновления 104, создает множество файлов 109(n+1), с исполняемым кодом модулей приложения 108(n+1) и файлами данных 110(n+1).

Для антивирусного приложения и антиспам-технологий, наиболее подходящим является обновление файлов путем деления данных на несколько файлов, нежели чем передавать всю обновленную информацию в одном файле. Например, в одном из нескольких файлов может храниться информация о масках вредоносных объектов, во втором файле - информация о правилах взаимодействия с файлами, в третьем файле - информация об именах файлов. В представленном примере могут быть файлы, которые нуждаются в обновлении - файлы модулей приложения и файлы данных. Следует также отметить, что частота обновления данных в файлах варьируется. Для оптимизации процесса обновления предусматривается частота их выпуска по времени. Например, возможен вариант выпускать обновления днем чаще, чем ночью. Это позволит значительно снизить нагрузку на сервера. Например, обновление модулей приложения 108 (другими словами изменение исполняемого кода приложения) может осуществляться не часто, например, обновляться раз в несколько недель или даже месяцев. Файлы данных 110, такие как, правила нахождения вирусов, могут обновляться чаще. Файлы, такие как, маски и имена вирусов могут обновляться практически непрерывно. Таким образом, одним из преимуществ системы обновления приложения на основе различий является возможность обновления только необходимых файлов.

Возвращаясь вновь к рассмотрению Фиг.1, рассмотрим средство предоставления информации о последних версиях файлов 106. Рассмотрим состояние множества файлов - 109(n), где n - состояние файлов в текущий момент времени. Представленное множество состоит из средства хранения модулей приложения 108(n) и средства хранения файлов данных 110(n). Возникновение новой версии (n+1) может быть связано с исправлением модуля приложений, обнаружением новых вирусов, изменением правил поиска некоторых вирусов, и т.д. На Фиг.1 обновление изображено значением (n+1), другими словами, это множество файлов 109(n+1), которое включает в себя модули приложений 108(n+1) и файлы данных 110(n+1). В одном из вариантов реализации средство предоставления информации о последних версиях файлов 106 может хранить информацию о последних версиях файлах в виде списка с указанием названия файла и его последней версии. Такой список может быть сохранен в виде файла описания, который может быть предоставлен посреднику обновления 104. Подобное действие может происходить периодически с заданными интервалами времени или же в тот момент, когда средство предоставления информации о последних версиях файлов 106 получает новую версию какого-либо файла. Механизм передачи информации о последних версиях файлов рассмотрен в таких патентах и заявках как JP2270029, JP7084775, JP4195567, W09825205, KR100288561.

Средство построения различий 112 - это программный модуль, который определяет и выбирает соответствующие различия между предыдущими файлами (со значением n) с новыми файлами (со значением (n+1)). Средство построения различий 112 создает множество различий 118(n,n+1), при описании, как преобразовать файл со значением n в файл (n+1). Например, этими различиями могут быть различия для модулей приложения 114 (то есть в исполняемом коде) и различия для файлов с данными 116. В одном из вариантов реализации метод работы средства построения различий 112 может основываться на нахождении наибольшей общей подпоследовательности (http://ru.wikipedia.org/wiki/Наибольшая_общая_подпоследовательность).

Представленные различия 114 и 116 затем передаются посреднику обновления 104, который обычно представляет собой FTP, DFTP или HTTP сервер. На сервере 104 публикуется множество различий, которые составляются последовательно (от версии к версии) между последней версией файлов (n+1) и более ранними версиями (1n). После публикации новых различий, которые указывают на наличие новых версий файлов, в одном из вариантов реализации средству обновления 122 отправляется информация о том, какие файлы имеют более новую версию. В другом варианте реализации средство обновления 122 периодически обращается к посреднику обновления 104 за информацией о новых версиях файлов.

На Фиг.2 изображен оптимизированный процесс обнаружения того, какие версии, для каких файлов необходимо загрузить. Как показано на Фиг.2, средство обновления 122 на компьютере клиента имеет доступ к информации о файлах, находящихся на нем, т.е. о модулях приложений 108 и файлах данных 110. Средство обновления 122 также может загружать с сервера 104 информацию 202 о том, какие файлы можно обновить. Средство обновления 122 компьютера пользователя может сравнить файл описания состояний с его версиями файлов, и легко определить, какие файлы нужно обновить. Средство контроля обновлений 124 предназначено для управления обновлениями, а именно, их инициализацией, управлением очереди обновлений для различных программ компьютерной системы пользователя. Например, средство контроля обновления 124 может инициализировать регулярные обновления программ в вечернее время, как только пользователь перестанет активно работать с системой. Однако средство контроля обновлений 124 также разрешает обновляться программам в случае, если необходимо загрузить критическое обновление.

Данная схема обновления также применима к приложениям, которые состоят из нескольких приложений. Например, антивирусный комплекс может состоять из межсетевого экрана, антивирусного модуля, антиспам модуля, и т.д. Каждый из этих компонентов содержит свое собственное множество модулей приложений и файлов данных, которые необходимо обновлять. Основное приложение также содержит эти файлы, которые также необходимо обновлять. Как показано на Фиг.2, программное обеспечение на клиентском компьютере может обмениваться небольшими порциями данных с сервером 104 для оптимизации процесса. Механизмы работы средства обновления 122 и средства контроля обновлений могут быть реализованы в виде систем, описанных в таких патентах как US6477703, US2002116665, US2004073900.

На Фиг.3А-3К изображен процесс обновления различий. Когда появляется новое обновления, текущее состояние различия отмечено значением n, а уже следующее состояние - значением (n+1). Как показано на Фиг.3А, для состояния n различие (n)(n) - нулевое. Другие различия (k)(n),(3)(n), (2)(n), (1)(n) считаются от предыдущих состояний (k 3, 2, 1) для текущего состояния n в момент времени t1.

На Фиг.3Б изображена ситуация, когда наступает состояние (n+1). В этот момент времени t2 существуют нулевые различия (n)(n) и (n+1)(n+1).

На Фиг.3В изображено среднее состояние между обновлениями, где различие, которое было (n)(n) становится различием (n)(n+1). Остальные различия не меняются, т.е. существует путь от любого предыдущего состояния до состояния (n+1), однако этот путь необязательно прямой.

На Фиг.3Г изображен следующий шаг процесса, где различия, указывающие на состояние n, перемещаются к различию, указывающему на состояние (n+1). В этом случае различие (k)(n) перемещается к различию (k)(n+1).

На Фиг.3Д изображена часть процесса в момент времени t5, а именно различие, изменяющее состояние 3 в состояние n (различие, описанное как (3)(n)), заменяется различием (3)(n+1).

На Фиг.3Е изображена часть процесса в момент времени t6, когда различие (2)(n) заменяется различием (2)(n+1). Процесс завершается в момент времени t7, как показано на Фиг.3Ж, где различие (1)(n) заменяется различием (1)(n+1).

На Фиг.3З-3К изображена ситуация, в которой новое обновление появилось до загрузки всех различий между текущим состоянием и обновленным. Например, на Фиг.3Д описывается момент времени t5, который на Фиг.3З представлен как t5a. На Фиг.3З в этот момент времени появляется новое состояние (n+2). В этом случае нулевое различие для этого состояния будет (n+2)(n+2). Однако, в этом случае еще нет прямого пути к состоянию (n+2) от предыдущих состояний.

На Фиг.3И вместо того, чтобы продолжать процесс, изображенный на Фиг.3Е-ЗЖ, добавляется различие (n+1)(n+2), для создания пути от состояния (n+1)к состоянию (n+2). Затем это различие заменяется на нулевое (n+1)(n+1). Вместе с этим различием получается путь от любого предыдущего состояния к финальному состоянию (n+2). Как показано на Фиг.3Й различие (n)(n+1) заменяется различием (n)(n+2), которое указывает на переход от состояния n к состоянию (n+2).

На Фиг.3К различие (к)(n+1) заменяется различием (k)(n+2). Процесс продолжается далее в соответствии с описанной полезной моделью, пока все различия не укажут с предыдущего состояния к финальному состоянию (n+2).

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

На Фиг.4 изображена блок-схема, описывающая ход работы представленной полезной модели на стороне средства предоставления информации о последних версиях файлов 106. Процесс начинается на шаге 402. На шаге 404 создается новое множество файлов F(i, n+1), которое представляет собой новые версии файлов предыдущего состояния n, и где i - индекс файла. На шаге 406 вводится значение k - номер версии, равный (n+1), а на шаге 408 вводится значение i - текущий индекс файла, равный n. На шаге 410 публикуется новый файл F(i, k), т.е. становится доступным на сервере 104.

На шаге 414 проверяется равенство k=n+1. Если равенство верное, то на шаге 416 создается нулевое различие. Если k не равно n, то на шаге 417 создается различие для текущего файла (где i - индекс файла) между последней (n+1) и текущей версией (k). После прохождения шагов 417 или 416, на шаге 418 проверяется, является ли различие больше, чем размер файла, для которого оно было создано. Если нет, то на шаге 422 различие публикуется на сервере 104 (в противном случае на шаге 420 различие удаляется). После прохождения шага 422 на шаге 423 проверяется, доступно ли новое множество. Если доступно, тогда ход процесса передается на шаг 404. Иначе процесс переходит на шаг 424. Если не доступно новое множество на шаге 423, то на шаге 424 проверяется равенство между i и 1, т.е. проверяется, остались ли файлы, для которых еще нужно создать различия. Если файлы не остались, то на шаге 432 i уменьшается на 1, и затем выполняется шаг 412. Иначе на шаге 426 проверяется для этого файла существование версии (k-1). Если она существует, то k уменьшается на 1 на шаге 434 и выполняется шаг 410. Иначе обновленный файл публикуется на шаге 428. Процесс заканчивается на шаге 430.

На Фиг.5 изображен случай применения алгоритма на стороне клиента в соответствии с вариантом реализации. Процесс начинается на шаге 502. Затем определяется значение k - версия текущей базы данных файлов на стороне клиента на шаге 504. На шаге 505 запрашивается различие для определенного файла. Если на шаге 510 различие для того файла доступно для загрузки, то различие (k) для файла F(k) загружается на шаге 514. На шаге 515 проверяется, пустой ли файл различия, а именно, есть ли различия между текущей версией и последней доступной на сервере. И если оказывается пустой, т.е. текущая версия является последней, то процесс завершается на шаге 518. Если же на шаге 510 не обнаружено доступных для загрузки различий, то на шаге 512 загружается файл F(n+1) целиком и процесс завершается на шаге 518. Если на шаге 515 полученное различие ненулевое, тогда на шаге 508 принимается различие, и файл на стороне клиента обновляется и выполняется шаг 504.

На Фиг.6 изображен другой вариант реализации части полезной модели, а именно работы на клиентской стороне. Как показано на Фиг.6 процесс начинается на шаге 602. Затем происходит соединение с сервером 104 и загрузка обновлений файлов (например, состояния файла описания) с сервера 104 на шаге 604, и, таким образом, получение информации о том, какие файлы необходимо обновить (как было оговорено ранее при рассмотрении Фиг.2.). На шаге 606 определяются файлы, которые необходимо обновить, если такие существуют, например, используя файл описания состояний 202 (этот шаг дополнительный - можно загружать различие для всех файлов, как нулевое, так и ненулевое.).

На шаге 607 проверяется, разрешает ли средство контроля 124 загрузку обновлений. И если не разрешает, то на шаге 608 процесс переводится в состояние ожидания инициализации обновления. Иначе на шаге 609 принимается значение i - индекс файла, который нужно заменить (другими словами, i может быть файлом маски вредоносной программы, файлом правил, и т.д.).

На шаге 612 для файла F(i, k) будет запрошено различие с сервера 104, где k - номер версии множества файлов 109 на стороне клиента. На шаге 614 выясняется, доступно ли для загрузки различие для представленного файла. Если различие не доступно, то на шаге 616 загружается файл последней версии целиком. Если различие доступно для загрузки, то оно загружается и применяется к файлу 109 на шаге 618. Если на шаге 620 получившийся файл соответствует ожидаемой версии, тогда на шаге 622 запрашивается верность равенства i=1. Если равенство верное, то процесс завершается на шаге 624. Если равенство неверное, то на шаге 626 индекс i уменьшается на 1, и выполнение процесса возвращается на шаг 612. Также после выполнения шага 616 процесс переходит на шаг 622 для того, чтобы проверить, остались ли еще файлы для обновления на сервере.

На Фиг.7 изображен примерный вариант реализации алгоритма проверки обновления средством контроля обновлений. Процесс начинается на шаге 702. На шаге 704 проверяется, появились ли приложения в системе, которым необходимо обновление. Если появились, то на шаге 706 проверяется, является ли обновление критическим (необходимым как можно скорее). Если обновление критическое, то на шаге 712 обновление загружается, иначе на шаге 708 проверяется, составлен ли список приложений для обновления. Данный список составляется с некоторой периодичностью и загружается после наступления определенного момента времени. Если список составлен для обновления, то обновления загружаются на шаге 710 и процесс завершается на шаге 714, иначе система переходит в состояние ожидания и выполнение возвращается на шаг 704.

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

Клиентский компьютер 802 включает в себя основную память 808, (RAM), и может также включать в себя вторичную память 810. Вторичная память 810 может включать в себя, например, внутренний диск или хранилище данных 812 (например, жесткий или оптический диск) и/или устройство чтения/записи 814 носителя данных 816 (устройство хранения данных на магнитной ленте, оптический привод и т.д.). Съемный запоминающий блок 816 представляет собой магнитную ленту, оптический диск или другие запоминающие носители, считываемые или записываемые с помощью соответствующего устройства чтения/записи 814 носителя данных 816. Как можно видеть, съемный запоминающий блок 816 может включать в себя машиночитаемый запоминающий носитель, имеющий хранимое на нем компьютерное программное обеспечение и/или данные.

В альтернативном варианте реализации вторичная память 810 включает в себя другие средства для загрузки компьютерных программ или других команд в клиентский компьютер 802. Она включает в себя, например, съемный блок памяти 822 и интерфейс 820. Она может включать в себя съемный чип памяти (такой как EPROM или PROM) и связанный с ним разъем или другие съемные блоки памяти 822 и интерфейсы 820, которые позволяют передавать программное обеспечение и данные со съемных блоков памяти 822 на клиентский компьютер 802.

Клиентский компьютер 802 также включает в себя один или более интерфейсов соединения, таких как сетевой интерфейс 824. Сетевой интерфейс 824 позволяет передавать данные между клиентским компьютером 802 и внешними устройствами. Например, сетевой интерфейс 824 включает в себя модем, сетевой интерфейс (например, карту Ethernet), порт соединения, PCMCIA слот и карту и т.д. Программное обеспечение и данные, передаваемые по сетевому интерфейсу 824, выполняются в форме сигналов 828, электронных, электромагнитных, оптических и других типов, которые могут быть приняты посредством сетевого интерфейса 824. Сигналы 828 выдаются сетевым интерфейсом 824 через канал связи 826. Этот канал 826 передает сигналы 828 и выполняется проводным или кабельным, оптоволоконным, радиочастотным каналом и другими каналами связи. В варианте осуществления полезной модели сигналы 828 содержат пакеты данных, отправленные процессору 801. Информация, представляющая обрабатываемые пакеты, может отправляться в форме сигналов 828 от процессора 801 через канал связи 826.

Термином «машиночитаемый носитель программ» или «машиночитаемый носитель информации» обычно называют носитель, такой как съемные носители данных 816 и 822, жесткий диск, установленный в виде встроенного жесткого диска 812, и сигналы 828, которые обеспечивают передачу программного обеспечения в клиентский компьютер 802.

Компьютерные программы хранятся в основной памяти 808 и/или вторичной памяти. Компьютерные программы могут быть также получены через сетевой интерфейс 824.

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

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

2. Система по п.1, в которой средство контроля обновлений также предназначено для инициализации средства обновления, если обновление является критическим.

3. Система по п.1, в которой средство контроля обновлений также предназначено для составления очереди обновлений, если обновления не являются критическими.

4. Система по п.3, в которой средство контроля обновлений также предназначено для инициализации средства обновления и передаче ему очереди обновлений в определенный момент времени.

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

(а) количество обновлений в очереди превышает заранее предустановленное значение;

(б) наступает момент времени по расписанию.

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

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

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

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

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

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