Способ и устройство для проверки исполняемой программы с использованием модели



Способ и устройство для проверки исполняемой программы с использованием модели
Способ и устройство для проверки исполняемой программы с использованием модели
Способ и устройство для проверки исполняемой программы с использованием модели
Способ и устройство для проверки исполняемой программы с использованием модели

Владельцы патента RU 2575985:

МОТОРОЛА МОБИЛИТИ, ИНК. (US)

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробное описание изобретения

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

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

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

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

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

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

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

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

Не отправлять сообщения после того, как файлы считаны.

Не выполнять запись в некоторые/все файлы.

Не выполнять запись в файлы, помимо stdout.

Не пытаться создавать каталог.

Не выполнять считывание из файла X.

Не открывать более X файлов.

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

Не разветвлять оболочку.

Не исполнять другую (или конкретную) программу.

Не создавать файлы, за исключением /tmp.dir.

Не осуществлять доступ к указываемому пользователями каталогу.

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

Не осуществлять доступ к службе коротких сообщений (SMS).

Не осуществлять доступ к службе мультимедийных сообщений (MMS).

Не осуществлять доступ к DIAL-службе.

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

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

Не осуществлять доступ к Bluetooth-службе.

Не выделять объем памяти сверх X.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сетевой инфраструктурный элемент затем разрабатывает 403 модель, как описано в данном документе (с использованием этой загруженной исполняемой программы), и проверяет 404 эту модель на предмет политик платформы конечного пользователя. Когда эта проверка приводит к недопустимым результатам, сетевой инфраструктурный элемент может предпринимать одно или более действий (не показаны), чтобы отклонять или иным образом препятствовать загрузке программы посредством платформы конечного пользователя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



 

Похожие патенты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изобретение относится к области программирования компонентов в объектах. Техническим результатом является программирование компонентов на основе местоположений для компонентов в объекте. Способ управления программируемым компонентом включает в себя: определение местоположения на объекте с использованием программирующего устройства на основании положения программирующего устройства относительно объекта, определение программной информации для программируемого компонента на основании местоположения на объекте, и программирование программируемого компонента с использованием программной информации для программируемого компонента, причем определение программной информации для программируемого компонента на основании местоположения на объекте включает в себя: определение связи между местоположением на объекте и несколькими точками в облаке точек для объекта, причем несколько точек в облаке точек связаны с обозначением компонента, хранящимся в базе данных, определение программной информации для программируемого компонента с использованием обозначения компонента, связанного с несколькими точками в облаке точек и базе данных. 2 н. и 33 з.п. ф-лы, 18 ил.
© Патентный поиск, поиск патентов на изобретения - FindPatent.RU 2012-2024
Политика конфиденциальности 2016-02-27 2016-02-29T20:26:25
Наверх