Результат интеллектуальной деятельности: СПОСОБ ИСКЛЮЧЕНИЯ ПРОЦЕССОВ ИЗ АНТИВИРУСНОЙ ПРОВЕРКИ НА ОСНОВАНИИ ДАННЫХ О ФАЙЛЕ

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

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

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

В настоящее время существует большое количество разновидностей вредоносного программного обеспечения (ПО), к которым относятся сетевые черви, троянские программы и компьютерные вирусы, которые предназначены для проникновения в компьютерную систему с целью получения контроля над ней и совершения незаконных действий, например кражи конфиденциальной информации. Поэтому многие владельцы компьютерных устройств (например, персональных компьютеров) для защиты используют различные антивирусные приложения, которые позволяют обнаруживать и удалять вредоносные программы. Примерами таких приложений являются приложение «Kaspersky Anti-Virus» от компании «ЗАО Лаборатория Касперского» и приложение «Avast! Pro Antivirus» от компании AVAST Software. Как правило, современные антивирусные приложения являются многокомпонентными сложными системами, которые содержат в себе различные модули, реализующие различные способы защиты, в том числе и обнаружение вредоносных программ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 2 описывает способ работы настоящего изобретения;

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

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

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

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

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

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

Доверенный процесс - процесс, запущенный из доверенного файла.

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

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

- доверенный процесс открывает недоверенный файл;

- доверенный процесс обменивается данными с недоверенным процессом, используя методы межпроцессного взаимодействия (например, семафоры или разделяемая память);

- запуск нового потока в процессе;

- создание процессом еще одного процесса;

- запись в адресное пространство другого процесса;

- загрузка процессом библиотеки из альтернативного потока NTFS;

- открытие сетевого соединения с любым удаленным ресурсом (как в локальной сети, так и в сети Интернет).

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

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

Стоит отметить, что процесс является, по сути, контейнером ресурсов, необходимых для выполнения кода программы исполняемого файла. Процесс имеет виртуальное адресное пространство. В виртуальное адресное пространство процесса загружаются необходимые секции исполняемого файла, из которого загружен процесс, а также связанные с ним динамические библиотеки DLL (англ. dynamic-link library, динамически подключаемая библиотека). Также в адресном пространстве процесса хранятся различные структуры данных, например стек. Каждый процесс содержит по крайней мере один поток выполнения. Поток использует системные ресурсы (например, файлы, ключи системного реестра, объекты синхронизации) и виртуальное адресное пространство процесса. Выполнение программного кода происходит в рамках выполнения потоков процесса. Анализ же процесса подразумевает анализ всех совершающихся событий во время выполнения программного кода. Стоит отметить, что на Фиг. 1 изображен поток совершающихся событий, а не поток процесса.

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

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

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

Далее согласно текущему статусу процесса средство 120 задает по крайней мере один необходимый тип событий для последующего контроля и анализа. Таким образом, для процесса со статусом доверенный (на Фиг. 1 примером такого процесса является процесс VISIO.EXE) средство 120 будет отслеживать среди всех совершающихся событий только обязательные события, информация о которых содержится в базе данных обязательных событий 140. Обязательными событиями являются события, которые необходимы для контроля и анализа в независимости от статуса процесса, т.к. данные события могут повлиять на изменения текущего статуса процесса. Примером обязательных событий могут являться события, указывающие на запуск или закрытие исполняемого файла, на открытие (установление) сетевого соединения или чтения какого-либо файла. Для процесса со статусом недоверенный (на Фиг. 1 примером такого процесса является процесс explorer.exe) средство 120 будет отслеживать среди всех совершающихся событий как обязательные события, так и критические события, информация о которых содержится в базе данных критических событий 150. Критическими событиями являются события, на основании которых может быть выявлено исполнение вредоносного кода в анализируемом процессе. Примерами критических событий могут являться события, указывающие на создание нового файла (вызов функции CreateFile), нового процесса (CreateProcess) и нового потока (CreateThread/CreateRemoteThread), на запись в файл (WriteFile), на внедрение в адресное пространство другого процесса, на изменение настроек ОС (в частности, настроек безопасности) и на доступ к ключам реестра, отвечающим за автозагрузку.

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

После выявления по крайней мере одного необходимого (обязательного или критического) события в зависимости от статуса процесса средство мониторинга событий 120 передает информацию о выявленном событии (например, вызванная API функция) и текущем статусе процесса средству обработки событий 160. Средство обработки событий 160 производит анализ полученной информации с помощью критериев оценки, информация о которых хранится в базе данных критериев оценки 170.

Определение статусов доверенный/недоверенный процесс/файл дано выше, как и критерии оценки по изменению статусов.

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

После проведения анализа средство 160 выносит решение о необходимости изменения статуса процесса, которое передаст средству мониторинга процессов 120. Также средство 160 произведет изменения в базе данных доверенных объектов 130 в случае изменения статуса у файла. Изменениями являются добавление в базу данных 130 информации о новом доверенном файле (который ранее был неизвестным или недоверенным) или удаление из базы данных 130 информации о доверенном файле, т.к. статус файла стал недоверенным.

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

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

В том случае, если событие будет являться критическим событием, средство 160 запросит средство антивирусной защиты 180 немедленно провести проверку недоверенного процесса (как было описано выше, только для недоверенных процессов отслеживаются критические события) и файла, из которого был запущен данный процесс. Средство 180 проведет проверку и предоставит средству 160 вердикт о вредоносности файла. Стоит отметить, что способы проверки файла и процесса зависит от возможностей средства антивирусной защиты 180. Средство 180 может использовать как более простой тип проверки, например, сигнатурный анализ файла, так и более сложный тип проверки, позволяющий провести более детальный анализ, например, используя экспертную систему, в основе которой лежит анализ совершенных событий. В том случае, если файл будет признан вредоносным файлом, файл будет заблокирован и, следовательно, процесс будет остановлен при помощи средства 180. В противном случае, если файл будет «безопасным», то средство 160 впоследствии добавит данный файл в базу данных доверенных объектов 130 и вынесет решение о необходимости изменении статуса процесса на доверенный процесс. После чего данное решение будет передано средству мониторинга процессов 120 для последующего контроля.

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

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

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

Приведем пример. Системная динамическая библиотека shell32.dll, которая используется различными системными процессами (explorer.exe) и пользовательскими процессами (например, word.exe), пытаясь повысить свою производительность при последующих запросах со стороны процессов, кеширует (пишет во временные файлы) результаты этих запросов. Это приводит к тому, что shell32.dll, будучи использованной из браузера, обновит временный файл и унаследует недоверенный статус, например, от процесса браузера (iexplorer.exe). При последующем обращении из доверенного процесса (explorer.exe) через shell32.dll файловый фильтр передаст статус недоверенный с файла shell32.dll доверенному процессу (explorer.exe). Данный процесс (explorer.ехе) обновит другие свои файлы через тот же shell32.dll, что приведет к быстрой передаче недоверенного статуса другим процессам в системе.

Фиг. 2 отображает способ определения формата файла для решения вышеуказанной проблемы. На этапе 210 доверенный процесс осуществляет попытку доступа к файлу (например, пытается его открыть) с помощью средства мониторинга процессов 120. На этапе 220 происходит определение формата файла с помощью средства обработки событий 160. Данный шаг может быть выполнен с помощью анализа заголовка файла и с использованием соответствующих сигнатур для определения формата файла.

Примеры сигнатур для определения формата файла:

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

Небезопасными форматами файлов являются исполняемые форматы файлов (например, РЕ или ELF формат) или так называемые контейнеры для других файлов (например, архивы). К небезопасным форматам файлов также можно отнести и те форматы, которые поддерживают интерпретируемый код (псевдокод). Например, в pdf документ можно добавлять код, написанный на языке сценариев, который может быть и вредоносным.

Примерами безопасного формата файла можно привести файлы префетчера с расширением .pf, а также цифровые подписи и сертификаты с расширением .cat.

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

На этапе 224 происходит определение стека вызова с помощью средства обработки событий 160. Вышеупомянутый пример описывает ситуацию (отображена на Фиг. 3), когда процесс shell32.dll будет осуществлять операции с временными файлами как доверенного процесса (word.exe), так и недоверенного (explorer.exe). Стек вызова отслеживает передачу запроса на открытие файла через другие процессы - например, системные. Это связано с тем, что многие файловые операции (например, кэширование) уже реализованы средствами операционной системы, которые используются многими приложениями.

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

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

Пример 1. Уровень опасности файловой операции подсчитывается как результат битовой операции AND по определенным данным о формате файла (этап 220), о процессе (этап 222), о стеке вызова (этап 224). Если хотя бы на одном из этих этапов было определено, что либо формат файла не является безопасным, либо процесс может содержать вредоносный/уязвимый код, то уровень опасности файловой операции считается опасным (превышает порог на этапе 230, в случае битовой операции порог равен 1), и на этапе 240 статус процесса меняется на недоверенный. В противном случае на этапе 250 статус процесса остается доверенным.

Пример 2. Уровень опасности файловой операции подсчитывается как число и высчитывается во время этапов 220-224. Например, если на этапе 220 формат файла определяется как безопасный, то это не увеличивает уровень опасности файловой операции, в случае опасного формата файла уровень опасности файловой операции будет увеличен на определенное значение (например, на 50). После подсчета уровня опасности файловой операции он будет сравнен с пороговым значением на этапе 230.

Таким образом, при открытии доверенным процессом файлов, чей формат определен как безопасный, статус процесса изменен не будет, что, в свою очередь, не приведет к увеличению использования ресурсов при дальнейшей антивирусной проверке (этап 250). В ином случае статус процесса меняется на недоверенный (этап 240). Изменение статуса процесса производится с помощью средства мониторинга процессов 120. Исключение процесса из антивирусной проверки выполняется средством антивирусной защиты 180.

Фиг. 4 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая, в свою очередь, память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26 содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20, в свою очередь, содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш-карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который, в свою очередь, подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 4. В вычислительной сети могут присутствовать также и другие устройства, например маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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