RU2598988C2

RU2598988C2 - Способы и системы для поиска прикладных программ

Info

Publication number: RU2598988C2
Application number: RU2014131897/08A
Authority: RU
Inventors: Сиу-Пин ЛИНЬ; Чи-Цзень У
Original assignee: Фиизер Инк.
Priority date: 2013-08-07
Filing date: 2014-07-31
Publication date: 2016-10-10
Also published as: TWI553493B; TW201508523A; CN105354189A; EP2846273A1; BR102014019318A2; JP5859074B2; RU2014131897A; JP2015035216A

Abstract

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

Description

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

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

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

[0002] Поисковые машины являются важными инструментами для поиска информации онлайн. Также, мобильные приложения (далее именуемые “приложением или приложениями”) приобрели популярность благодаря широкому распространению смартфонов. В настоящее время, приложения либо заранее загружены в мобильные устройства, либо загружаются из интернета. Платформы распространения приложений, например, “APP store” фирмы Apple, “Google Play” фирмы Google или “bao.myapp.com” фирмы Tencent (далее именуемые “магазинами приложений”), позволяют пользователям обозревать и загружать нужные им приложения. Магазин приложений обычно организует приложения в категории и предоставляет традиционные утилиты поиска, позволяющие пользователям находить нужные приложения посредством поиска по ключевому слову. Такая традиционная поисковая утилита в магазине приложений исследует название и описание приложения, которые обычно подготавливает разработчик приложений, на предмет совпадения с ключевым(и) словом(ами), введенным(и) пользователем. Некоторые магазины приложений даже обеспечивают веб-интерфейсы, например, “Edit Application” в Google Play и “Manage Your Apps” в APP store фирмы Apple, позволяющие разработчикам выгружать и редактировать названия и описания своих приложений.

[0003] Когда приложение устанавливается и запускается, оно генерирует данные (далее именуемые “данными приложения”), которые являются динамическими по своей природе, помимо статических данных (например, названия или описания приложений). В частности, когда приложение выполняется на мобильном устройстве, приложение генерирует данные приложения в зависимости от различных триггеров, например, но без ограничения, поведения пользователя приложения. Например, если пользователь хочет узнать прогноз погоды с использованием метеорологического приложения, пользователь может ввести свое местоположение в интерфейсе приложения. Метеорологическое приложение будет доставлять релевантные данные приложения, в данном случае, прогноз погоды в местоположении пользователя. Другими словами, данные приложения могут быть динамическими на основании операции пользователя приложения, и могут либо происходить из одного или более серверов приложений, связанных с приложением, либо создаваться самим приложением.

[0004] Как указано выше, традиционные утилиты поиска, имеющиеся в магазинах приложений, ограничены поиском по ключевому слову статических данных. Объем поиска не распространяется на данные приложения. Другими словами, традиционные утилиты поиска не могут ни осуществлять поиск “внутри” файла пакета приложений, связанного с приложением (например, файла apk или файла ipa), ни искать данные приложения, генерируемые после того, как файл пакета приложений выполняется или выполнен на электронном устройстве пользователя. Это означает, что данные приложения, генерируемые приложением в ответ на ввод пользователя приложения, другой пользователь, который считает эту информацию ценной, никогда не сможет искать или найти.

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

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

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

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

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

Краткое описание нескольких видов чертежей

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

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

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

[0012] фиг. 3A и 3B - схемы, иллюстрирующие структуры данных согласно варианту осуществления настоящего изобретения;

[0013] фиг. 3C и 3D - схемы, иллюстрирующие структуры данных логической таблицы и ее строки согласно варианту осуществления настоящего изобретения;

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

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

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

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

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

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

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

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

[0022] фиг. 4I - схема, иллюстрирующая систему, включающую в себя модуль робота, объединяющий скрипт (сценарий), третий модуль, второй модуль и первый модуль, показанные на фиг. 4A, согласно варианту осуществления настоящего изобретения;

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

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

[0025] фиг. 5A-5E - схемы, иллюстрирующие иллюстративные пользовательские интерфейсы приложения согласно варианту осуществления настоящего изобретения;

[0026] фиг. 6A-6C - схемы, иллюстрирующие иллюстративные пользовательские интерфейсы служб, предоставляемых поисковыми машинами для приложений согласно варианту осуществления настоящего изобретения;

[0027] фиг. 7A-7H - иллюстративные варианты осуществления системы настоящего изобретения, использующей одну виртуальную машину или несколько виртуальных машин для выполнения одного или более приложений;

[0028] фиг. 8A - схема концептуального представления OS для модуля накопления данных при выборке или перехвате данных приложения из системных вызовов на уровне пользователя;

[0029] фиг. 8B - схема концептуального представления OS для модуля накопления данных при выборке или перехвате данных приложения из системных вызовов на уровне ядра;

[0030] фиг. 9A и фиг. 9B - примеры использования посредников, показанных на фиг. 7A-7H, для осуществления задачи модуля накопления данных;

[0031] фиг. 9C - упрощенная блок-схема последовательности операций модуля накопления данных или посредников, показанных на фиг. 7A-7H, при выборке или перехвате данных/контента, связанных с приложением согласно варианту осуществления;

[0032] фиг. 9D - упрощенная блок-схема последовательности операций планировщика согласно варианту осуществления; и

[0033] фиг. 9E - упрощенная блок-схема последовательности операций диспетчера виртуальной машины согласно варианту осуществления.

Подробное описание

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

[0035] На фиг. 1 показана схема концептуального представления, иллюстрирующая систему согласно примеру настоящего изобретения. Система может включать в себя серверный кластер 100 (или облако), серверы 200 приложений, первого пользователя 10 и второго пользователя 20, которые могут осуществлять связь друг с другом через сеть 30, которой может быть, но без ограничения, интернет или сотовая сеть. В этом примере, серверный кластер может включать в себя множество серверов (например, серверы 100a-100d, показанные на фиг. 1), каждый из которых выполнен с возможностью осуществления, по меньшей мере, части, задач, процессов или этапов настоящего изобретения, по отдельности, последовательно, параллельно или в их комбинации, для повышения эффективности системы. Сервер в серверном кластере 100 может включать в себя, но без ограничения, процессор, память, коммуникационный порт и запоминающее устройство, включающее в себя базу данных. Пример серверного кластера можно описать со ссылкой на фиг. 2.

[0036] Согласно фиг. 1, 4A и 4B, сервер 100a сконфигурирован как сервер веб-приложений (далее “сервер 100a веб-приложений”), который подключен к серверу 100b (далее “сервер 100b поисковой машины приложений”) для обслуживания первого пользователя 10 и второго пользователя 20. Основной функцией сервера 100a веб-приложений является обеспечение пользователям веб-утилит. Например, сервер 100a веб-приложений обеспечивает веб-интерфейсы, которые позволяют пользователям вводить поисковые запросы. Основной функцией сервера 100b поисковой машины приложений является обеспечение службы поисковой машины для поиска данных приложения. Заметим, что данные приложения могут включать в себя, но без ограничения, символы, атрибуты, описания, серийные номера, идентификаторы, статистику, исторические записи, гиперссылки, пути к файлам, аудио, видео и другую информацию в пригодных для поиска форматах и любую их комбинацию.

[0037] Сервер 100a веб-приложений может обеспечивать (или предписывать веб-браузеру показывать) поле поиска или кнопку 502 поиска на экране 131 первого пользователя 10 или на экране 231 второго пользователя 20 для обеспечения возможности доступа к утилитам поиска, обеспеченным сервером 100b поисковой машины приложений. Пользователь может вводить запрос посредством поля поиска для инициирования поиска. Специалистам в данной области техники понятно, что запрос в этом примере может быть в форме одного или более ключевых слов, изображений, видеопотоков, аудио или их комбинации. Например, пользователь может вводить ключевое слово в поле 502 поиска, набирая одно или более слов или произнося одно или более слов. В другом примере, пользователь может нажимать кнопку 502 поиска для подачи запросов в формате изображения, видео или аудио.

Согласно фиг. 4A, приложение может быть установлено на сервере 100b поисковой машины приложений или у первого пользователя 10. Когда приложение устанавливается, активируется и запускается/используется (далее, в целом, будем говорить “выполняется”), приложение может генерировать данные приложения в зависимости от того, как используется приложение. Данные приложения могут обеспечиваться сервером 200 приложений или генерироваться самим приложением. Затем сервер 100b поисковой машины приложений собирает такие данные приложения.

[0039] Согласно фиг. 4F, посредник 610 сбора данных может использоваться между сервером (например, сервером 100b поисковой машины приложений) и сетью 30 для выборки и/или кэширования данных приложения согласно одному варианту осуществления настоящего изобретения. Если посредник 610 сбора данных принимает поисковый запрос от второго пользователя 20, он может обратиться к своему локальному кэшу ранее сохраненных данных приложения в поисках совпадения. Если совпадение найдено, посредник 610 сбора данных может возвращать данные второму пользователю 20 без необходимости направлять запрос на сервер 100b поисковой машины приложений.

[0040] Согласно фиг. 1 и 4A, данные приложения могут храниться в базе данных либо на сервере 100a веб-приложений, либо на сервере 100b поисковой машины приложений, как показано на фиг. 2 и 4A. Данные приложения могут храниться в базе данных в виде строки() или двоичного(ых) кода(ов). Сервер 100a веб-приложений или сервер 100b поисковой машины приложений может управлять собранными данными приложения, осуществлять доступ к ним или запрашивать их с помощью языков программирования например, SQL, C, C++ или других инструментов управления данными. В одном примере, строку(и) или двоичный(е) код(ы) в базе данных можно искать на основании запроса. В другом примере, фрагменты данных, хранящихся в базе данных, могут быть связаны с одним или более уникальными ключами (например, первичным ключом), и конкретные фрагменты данных можно находить путем поиска ключей. До сохранения в базе данных, данные приложения сначала можно организовать во множество категорий, где каждая категория связана с множеством ключевых слов (например, такие ключевые слова, как “гостиница” и “бунгало” связаны с категорией “путешествие”). Данные, принадлежащие одной категории, могут храниться и быть привязаны к группе ключей, имеющих, например, последовательные или связанные номера (или имеющих конкретные номера, например, все четные или все нечетные номера, все номера, начинающиеся/заканчивающиеся цифрой “1”, “2” и т.д., или все номера, конкретный бит/цифра которых равна “1”, “2” и т.д.). Когда сервер 100b поисковой машины приложений ищет данные приложения, связанные с данным запросом, можно сначала выбирать ключи, связанные с множеством ключевых слов, которые совпадают с таким данным запросом. Затем производится поиск данных приложения в базе данных, которые соответствуют выбранным ключам, на основании релевантности запросу. Заметим, что сохранение и поиск собранных данных приложения может осуществляться с использованием других технологий поисковых машин. В одном примере, данные приложения могут храниться в логической таблице (например, BigTable) или файловой системе Hadoop (HFS) в инфраструктуре Hadoop. На Фиг. 3C показана логическая таблица 3000. Фиг. 3D иллюстрирует строку 320 логической таблицы 3000. Здесь, данные приложения могут храниться в сегментах 320-324 таблицы в дублированной файловой системе, к которой могут осуществлять доступ все серверы сегментов таблицы (не показаны, например, все серверы сегментов таблицы BigTable). Любые изменения в сегментах таблицы регистрируются в журнале транзакций, который сохраняется в совместно используемой файловой системе. В этом примере, данные хранятся в сегментах 320-324 таблицы на постоянной основе (т.е. данные, однажды записанные в логическую таблицу 3000, никогда не изменяются). В другом примере, для обеспечения обновления, более новые данные могут сохраняться в ОЗУ, тогда как более старые данные сохраняются в нескольких файлах логической таблицы 3000.

[0041] В другом примере (согласно фиг. 1 и 4B), данные приложения могут храниться в автономной базе данных 888’. Управление базой данных 888’ может осуществлять сервер 100a веб-приложений или сервер 100b поисковой машины приложений с помощью такого языка программирования, как SQL, C, C++, или других языков или инструментов управления данными. Поиск данных приложения, хранящихся в базе данных 888′, может осуществляться сервером 100b поисковой машины приложений.

[0042] Специалистам в данной области техники понятно, что либо сервер 100a веб-приложений, либо сервер 100b поисковой машины приложений может самостоятельно обеспечивать вышеупомянутые функции поиска. Соответственно, веб-приложение и функцию поиска не обязательно реализовать на двух отдельных серверах. Кроме того, эти функции можно также реализовать посредством PaaS, IaaS или SaaS.

В другом примере (согласно фиг. 1), серверный кластер 100 может дополнительно включать в себя сервер 100c (далее “сервер 100c управления базой данных”), выполненный с возможностью либо функционировать как первая база данных, либо предоставлять службы управления базой данных второй базе данных (не показана), которая подключена к серверу 100C и используется для хранения данных приложения. Например, вторая база данных может существовать в сети хранения данных (SAN), и сервер 100c управления базой данных может управлять второй базой данных в SAN. Данными приложения, хранящимися в первой или второй базе данных, можно управлять посредством языка программирования, например, SQL, C, C++ или других инструментов управления данными (т.е. сервер 100c управления базой данных может управлять первой или второй базой данных и осуществлять доступ к ним, когда сервер 100c управления базой данных осуществляет способ настоящего изобретения).

[0044] В другом примере, если данное приложение является изображением, видео, голосовым/аудиофайлом или текстом, оно может храниться в запоминающем устройстве (не показано) сервера 100a веб-приложений, запоминающем устройстве 19 сервера 100b поисковой машины приложений (см. фиг. 2), запоминающем устройстве (не показано) сервера 100c (см. фиг. 1) или запоминающем устройстве 19, подключенном к серверу 100a или 100b, или 100c (см. фиг. 4B). Соответствующее имя файла, название, описание или привязка (см., например, фиг.3A или 3B) таких данных могут храниться в виде строки() в базе данных сервера 100a веб-приложений, в базе данных сервера 100b поисковой машины приложений или в вышеупомянутой первой базе данных, или второй базе данных для обеспечения поиска.

[0045] В одном примере, каждая строка(и), соответствующая(ие) изображению, видео, голосовому/аудиофайлу или тексту, также может иметь путь к файлу, хранящемуся в базе данных, для указания местоположения данных. Например, серверный кластер 100 может дополнительно включать в себя сервер 100d (далее “сервер 100d управления файлами”, см. фиг. 1), который может связываться с серверами 100a, 100b или 100c и осуществлять службы управления файлами. Файл, строка(и) которого совпадает(ют) с ключевым словом, будет представлен как результат поиска. Файл извлекается через путь, соответствующий своей(им) строке(ам), когда строка(и), совпадающая(ие) с ключевым словом, найдена(ы) в базе данных.

[0046] Специалистам в данной области техники понятно, что сервер(ы) 100a, 100b и/или 100c также может(ут) предоставлять службы управления файлами хранилищу (или NAS).

[0047] В другом примере, множество серверов выполнено с возможностью работать параллельно для расширения серверного кластера 100 для предоставления служб большому количеству клиентов в сети. Здесь, запоминающие устройства и базы данных, подключенные к вышеупомянутому(ым) серверу(ам), также могут расширяться.

[0048] Кроме того, трафиком данных или службами, предоставляемыми сервером(ами) 100a, 100b, 100c и 100d, может управлять модуль или сервер балансировки нагрузки (не показан). Специалисту в данной области техники понятно, что способ(ы) настоящего изобретения не ограничивается количеством серверов в серверном кластере 100.

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

[0050] Также очевидно, что серверы 100a - 100d могут динамически меняться ролями. Серверы в серверном кластере 100 могут обмениваться задачей(ами), процессом(ами) или этапом(ами) друг с другом и все же поддерживать целостность системы.

[0051] Первый пользователь 10 может запускать приложения, выполняющиеся на вычислительном устройстве, для запрашивания данных приложения из релевантного сервера приложений или облака. Вычислительное устройство может представлять собой, но без ограничения, смартфон 10a, планшет (или “планшетный компьютер”) 10b (совместно именуемые мобильными устройствами), портативный компьютер 10c или персональный компьютер 10d, интеллектуальный телевизор, телевизионную игровую консоль, автомобильный компьютер или устройство записи вождения. Аналогично, второй пользователь 20 может выполнять такие же приложения в вышеописанном вычислительном устройстве. Специалисту в данной области техники понятно, что для получения данных приложения человеку не требуется оперировать приложениями. Машина, программа или робот также могут быть выполнены с возможностью автоматического выполнения приложений.

[0052] Фиг. 2 иллюстрирует систему, содержащую сервер 100b поисковой машины приложений, сервер 200 приложений, первого пользователя 10 и второго пользователя 20. Сервер 100b поисковой машины приложений может включать в себя, но без ограничения, память 12, канал 14 данных, контроллер 16 памяти, коммуникационный порт 17, процессор 18 и запоминающее устройство 19. В одном примере, запоминающее устройство 19 может включать в себя базу данных 888. Заметим, что база данных 888 или запоминающее устройство 19 также может быть выполнено с возможностью существования вне системы сервера, но связывается с сервером 100b поисковой машины приложений.

[0053] Первый пользователь 10 или второй пользователь 20 могут включать в себя память 139 или 239, канал 160 или 260 данных, контроллер 137 или 237 памяти, процессор 135 или 235, запоминающее устройство 118 или 218, периферийное устройство 134 или 234, модуль 132 или 232 AGPS (усовершенствованной глобальной системы позиционирования), РЧ (радиочастотный) модуль 140 или 240, систему 133 или 233 ввода/вывода, включающую в себя контроллер 133a или 233a отображения и контроллер 133b или 233b ввода, экран 131 или 231, включающий в себя пользовательский интерфейс 131a или 231a, и модуль или устройство 138 или 238 ввода. В одном примере, запоминающее устройство 118 или 218 может включать в себя считываемый компьютером носитель 118a или 218a, соответственно. В другом примере, запоминающее устройство 118 или 218 также можно рассматривать как считываемый компьютером носитель.

[0054] Виртуальная машина является программной реализацией вычислительной среды, в которой можно устанавливать и выполнять операционную систему или программу. Виртуальная машина обычно эмулирует физическую вычислительную среду, но управление запросами к ЦП, памяти, жесткому диску, сети и другим аппаратным ресурсам осуществляется на уровне виртуализации, который переносит эти запросы на физическое оборудование более низкого уровня. Виртуальные машины создаются на уровне виртуализации, например, гипервизоре или платформе виртуализации, которая выполняется над операционной системой клиента (http://searchenterprisedesktop.techtarget.com/definition/client) или сервера. Эта операционная система называется OS узла. Уровень виртуализации может использоваться для создания большого количества индивидуальных, изолированных сред виртуальной машины. Виртуальные машины могут обеспечивать многочисленные преимущества над установкой OS и программного обеспечения непосредственно на физическом оборудовании. Изоляция гарантирует, что приложения и службы, которые выполняются на виртуальной машине, не могут конфликтовать с OS узла или другими виртуальными машинами. Виртуальные машины также можно легко перемещать, копировать и переназначать между серверами узлов для оптимизации использования аппаратных ресурсов.

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

[0056] В другом примере, представленном на фиг. 4G, упаковщик 630 может дополнительно использоваться сервером (например, сервером 100b поисковой машины приложений) для упаковки каждого приложения (или apk приложения) с помощью интерфейса прикладного программирования (API) исполнителя. С помощью API исполнителя, сервер может получать информацию, зависящую от операционной системы, приложений, что позволяет системе настоящего изобретения знать, в какой среде должны выполняться приложения.

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

[0058] В другом примере, представленном на фиг. 4H, модуль 640 гипервизора может использоваться сервером (например, сервер 100b поисковой машины приложений) для управления количеством виртуальных машин, выполняющих приложения. Например, модуль 640 гипервизора может генерировать, удалять, активировать или деактивировать виртуальные машины. Модуль 640 гипервизора может действовать как административный инструмент, который управляет ресурсами виртуальных машин, что позволяет эффективно выполнять приложения.

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

[0060] Данные приложения могут обеспечиваться сервером 200 приложений или самим приложением. Данные приложения сохраняются в базе данных 888. Второй пользователь 20 может проводить поиск через пользовательский интерфейс 231a. Сервер 100b поисковой машины приложений может проводить поиск и передавать результат поиска второму пользователю 20.

[0061] Специалистам в данной области техники понятно, что элементы, модули или устройства, описанные в вышеупомянутых системах, могут быть объединены в один модуль или единый кристалл. Кроме того, система сервера на сервере 100b поисковой машины приложений, первый пользователь 10 и второй пользователь 20 могут связываться друг с другом через интернет 30. Кроме того, система(ы) сервера на сервере 100a, 100c или 100d также может(ут) включать в себя те же элементы, модули или устройства, что показаны на фиг. 2.

База данных

[0062] На фиг. 3A и 3B показаны иллюстративные структуры данных базы данных 888 или 888′ согласно примеру настоящего изобретения. В этом примере, база данных 888 или 888′ является реляционной базой данных. Согласно фиг. 3A, структура данных включает в себя, но без ограничения, первое поле 300-1 для хранения имени приложения 1, второе поле 300-2 для хранения ID приложения используемого для идентификации приложения 1, третье поле 300-3 для хранения имени файла или имени пакета приложений приложения 1, четвертое поле 300-4 для хранения местоположения приложения 1, пятое поле 300-5 для хранения ID списка контента, шестое поле 300-6 для хранения количества загрузок приложения 1 или седьмое поле 300-7 для хранения количества лайков в отношении приложения 1. Кроме того, фиг. 3B представляет одну из иллюстративных структур данных для ID списка контента, хранящегося в 300-5, показанном на фиг. 3A. Специалистам в данной области техники понятно, что некоторые поля, показанные на фиг. 3A и 3B, являются необязательными.

[0063] В другом примере, структуру данных в базе данных 888 или 888′ можно реализовать в виде логической таблицы 3000 и/или HFS, проиллюстрированной на фиг. 3C и/или 3D, где каждый элемент данных в HFS или логической таблице 3000 является парой ключ-значение (или парой ключ-данные, где, например, имя приложения, “приложение Джозефа”, может быть ключом к данным, показанным на фиг. 3D).

Поисковая машина приложений

[0064] Фиг. 4A иллюстрирует систему для поиска данных приложения согласно примеру настоящего изобретения. Согласно фиг. 4A, система может включать в себя сервер 100b поисковой машины приложений, первого пользователя 10 и сервер 200 приложений. Сервер 200 приложений может осуществлять связь с приложением 1 для обеспечения динамических данных и/или данных в реальном времени помимо статических данных. В этом примере, сервер 100b поисковой машины приложений может включать в себя виртуальную машину 400, веб-приложение 500, поисковую машину 600 приложений и запоминающее устройство 19. Виртуальная машина 400 является средой имитации операционной системы (OS), на которой могут базироваться приложения. Другими словами, приложения могут выполняться на виртуальной машине 400, таким же образом, как они выполняются на мобильном устройстве.

[0065] В другом примере, для размещения приложений на сервере 100b или 100e также можно применять подход “голой” машины. Согласно подходу голой машины, программа (не показана), сконфигурированная как интерфейс между сервером 100b или 100e и размещаемыми приложениями, может использоваться для перевода системных вызовов размещаемых приложений в машинные коды и передачи машинных кодов непосредственно на сервер 100b или 100e, чтобы заниматься только связью между сервером 100b или 100e (или сервером 200 приложений) и размещаемыми приложениями (например, отправкой запроса, приемом данных приложения, и т.д.).

[0066] В одном примере, пакет прикладных программ для приложения 1 можно загружать с сервера 200 приложений или из других мест хранения данных (не показаны, например, магазина/торговой площадки приложений, например, “APP Store” или “Google Play”), где либо хранится пакет прикладных программ, либо обеспечена ссылка загрузки, связанная с пакетом прикладных программ.

[0067] В одном примере, виртуальная машина 400 может включать в себя первый модуль (или программу) 402, выполненный с возможностью установки пакета приложений на виртуальной машине 400. Здесь, виртуальная машина 400 может дополнительно включать в себя второй модуль (или программу) 404, выполненный с возможностью выполнения приложения 1. Второй модуль 404 может непрерывно или периодически выполнять приложение 1. В одном примере, если на виртуальной машине 400 выполняется более одного приложения, второй модуль или программа 404 может выполнять все приложения последовательно, случайным образом или параллельно, в зависимости от политик и правил, установленных во втором модуле 404.

[0068] В другом примере, виртуальная машина 400 может дополнительно включать в себя третий модуль (или программу) 406, выполненный с возможностью анализа выполняемого приложения 1. Этот модуль определяет, как приложение 1 осуществляет связь с сервером 200 приложений. Например, третий модуль 406 может обследовать разные функции, которые обеспечивает приложение 1, и как такие функции могут выполняться для запрашивания данных приложения с соответствующего сервера 200 приложений. После такого анализа, скрипт (405) можно запрограммировать для автоматического и систематического выполнения приложения 1 для генерации данных приложения.

[0069] На фиг. 5A-5E показаны иллюстративные пользовательские интерфейсы для приложения 1. В этом примере, приложение 1 предоставляет функцию для запрашивания данных у связанного с ним сервера 200 приложений при касании или щелчке кнопкой по элементу(ам) (например, 90-1), как показано на фиг. 5B. Здесь, третий модуль 406 может анализировать пользовательский интерфейс для определения местоположений и функций элементов с 90-1 по 90-5. И скрипт 405 может выполняться для имитации поведений пользователя приложения 1, например, щелчка кнопкой или касания элемента 90-1, для запрашивания данных у сервера 200 приложений. Один пример состоит в программировании скрипта 405 на сервере 100b поисковой машины приложений (или в третьем модуле 406), когда третий модуль 406 анализирует приложение 1. В другом примере, скрипт 405 может храниться в запоминающем устройстве 19 сервера 100b поисковой машины приложений и передаваться на третий модуль 406, когда приложение 1 анализируется.

[0070] В другом примере, скрипт 405, третий модуль 406, второй модуль 404 и первый модуль 402 могут объединяться для формирования одного модуля 650 робота, представленного на фиг. 4I. Модуль 650 робота выполнен с возможностью имитации поведений человека, что позволяет ему выполнять приложение, как это делал бы фактический человек. В еще одном примере, модуль 650 робота также может изучать/записывать, как использовать приложение, отслеживая и записывая команды пользователей-людей приложения. Например, модулю 650 робота может быть поставлена задача отслеживать историю пользовательского ввода для изучения/записи моделей поведения, связанных с приложением. В другом примере, модуль 650 робота может быть выполнен с возможностью анализа графических пользовательских интерфейсов (GUI) приложения с использованием алгоритма распознавания изображений.

[0071] В другом примере, алгоритм распознавания изображений может включать в себя алгоритм оптического распознавания символов (OCR). При использовании алгоритма OCR для анализа GUI приложения, можно распознавать кнопки, символы, линии, страницы и окна на GUI, и конкретное действие может осуществляться модулем робота соответственно.

[0072] В другом примере, модуль робота может использовать алгоритм случайного зондирования для анализа GUI. Алгоритм случайного зондирования предписывает модулю робота зондировать или активировать GUI приложения случайным образом, например зондировать или активировать пиксели на экране GUI случайным образом. Если конкретный пиксель или положение пикселя GUI генерирует данные приложения на основании этого алгоритма случайного зондирования, такой анализ может изучаться и записываться модулем робота, например, по принципу машинного обучения.

[0073] Виртуальная машина 400 может дополнительно включать в себя четвертый модуль (или программу) 408, выполненный с возможностью сохранения данных приложения в базе данных 888 или запоминающем устройстве 19 (или в любом(ых) другом(их) запоминающем(их) устройстве(ах), связанном(ых) с сервером 100b поисковой машины приложений).

[0074] Другой вариант осуществления изобретения можно описать следующим образом. Приложение 1 выполняется на виртуальной машине 400 вторым модулем 404. Третий модуль 406 на виртуальной машине 400 осуществляет анализ в отношении приложении 1. Затем, скрипт 450 выполняется для генерации активности в отношении приложения 1. Активность предусматривает запрашивание данных приложения у сервера 200 приложений. Сервер 200 приложений доставляет запрашиваемые данные приложения приложению 1. Доставляемые данные собираются и сохраняются в базе данных 888. Альтернативно, приложение 1 может само генерировать данные приложения. Любые данные приложения, генерируемые приложением, также собираются и сохраняются в базе данных 888. Таким образом, данные приложения, собранные и сохраненные поисковой машиной приложений, могут представлять собой данные, передаваемые с сервера 200 приложений, а также данные, генерируемые самим приложением 1. Удаленный пользователь 20 вводит запрос в поле 502 и нажимает кнопку 522 поиска на пользовательском интерфейсе 131a для генерации поискового запроса данных, релевантных ключевому слову. Поисковая машина 600 приложений, приняв поисковый запрос, ищет в базе данных 888 данные приложения, которые релевантны запросу. Если релевантные данные найдены, поисковая машина 600 приложений генерирует результат поиска, который включает в себя такие данные, список релевантных приложений, одну или более ссылок на одно или более релевантных приложений, связанных с такими данными, или одну или более ссылок загрузки для одного или более пакетов прикладных программ одного или более релевантных приложений. Затем, веб-приложение 500 передает результат поиска удаленному пользователю 20.

[0075] На фиг. 6A-6C показаны некоторые иллюстративные результаты поиска. Когда поисковая машина 600 приложений находит более одного элемента релевантных данных приложения, ссылки на данные приложения, ссылки загрузки на приложения, которые содержат такие данные приложения, или сами данные приложения могут быть показаны и ранжированы согласно количеству загрузок, лайков или регистраций для каждого приложения. В одном примере, количество загрузок, лайков или регистраций для каждого приложения может храниться в базе данных 888 (согласно фиг. 3A или 3B), и данные приложения из сервера приложений также могут сохраняться в запоминающем устройстве 19 для поисковой машины 600 приложений для поиска.

[0076] Фиг. 4B иллюстрирует другой вариант осуществления сети согласно примеру настоящего изобретения. Сеть на фиг. 4B аналогична сети на фиг. 4A, за исключением того, что виртуальная машина 400 сконфигурирована на сервере 100e имитации мобильной OS, отдельно от поисковой машины 600 приложений, которая теперь сконфигурирована на сервере 100b поисковой машины приложений. В другом примере, используя множество серверов, сконфигурированных как единый сервер 100e имитации мобильной OS (далее “множество серверов имитации мобильной OS”), можно добиться более высокой производительности при выполнении нескольких приложений или при обработке большого объема данных приложения от нескольких серверов приложений.

[0077] В еще одном примере, веб-приложение 500 может быть сконфигурировано внутри сервера 100a веб-приложений. Веб-приложение 500 отделено от поисковой машины 600 приложений, которая сконфигурирована внутри сервера 100b поисковой машины приложений. Чтобы эффективно обслуживать большое количество пользователей, множество серверов сконфигурировано как единый сервер 100a веб-приложений (далее “множество серверов веб-приложений”) или как единый сервер 100b поисковой машины приложений (далее “множество серверов поисковой машины приложений”). Сервер балансировки нагрузки (или множество серверов балансировки нагрузки) можно применять до множества серверов веб-приложений или множества серверов поисковой машины приложений, чтобы лучше обрабатывать поисковые запросы пользователя. Для достижения более эффективного объема хранилища и сокращения времени ответа при обращении/поиске в запоминающем(их) устройстве(ах) или базе(ах) данных, запоминающее устройство 19 сервера 100b поисковой машины приложений на фиг. 4A можно заменить запоминающим устройством 19x, расположенным вне сервера 100b поисковой машины приложений (но все же связанным с сервером 100b поисковой машины приложений). В одном примере, запоминающее устройство 19x может иметь более высокую емкость, чем встроенное запоминающее устройство 19 сервера 100b поисковой машины приложений на фиг. 4A. В другом примере, множество запоминающих устройств (например, массив запоминающих устройств), каждое из которых сконфигурировано как запоминающее устройство 19x, может обеспечивать повышенную емкость для сервера 100e имитации мобильной OS или сервера 100b поисковой машины приложений. В другом примере, запоминающее устройство 19x также может быть сконфигурировано на сервере 100d управления файлами.

[0078] Аналогично, базу данных 888 на фиг. 4A можно заменить базой данных 888′ на фиг. 4B. База данных 888′ может связываться с сервером управления базой данных или запоминающим устройством 19x. В другом примере, множество баз данных, сконфигурированных как база данных 888′, может использоваться как единая база данных 888’ для сокращения времени ответа.

[0079] Фиг. 4C иллюстрирует другой вариант осуществления сети согласно примеру настоящего изобретения. Пакет прикладных программ может выполняться на вычислительном устройстве 5000 в среде мобильной OS. Альтернативно, вычислительное устройство 5000 может включать в себя среду операционной системы компьютера для размещения таких приложений, как веб-приложения, расширения и подключаемые программы. В одном примере, приложение 1 может либо запрашивать данные приложения из сервера 200 приложений, либо генерировать данные самостоятельно, будучи запущено первым пользователем 10. Результирующие данные приложения собираются сервером 100b поисковой машины приложений. Собранные данные приложения могут храниться в запоминающем устройстве, подключенном к серверу 100b поисковой машины приложений. В одном примере, вычислительное устройство 5000 может представлять собой смартфон 10a, планшет 10b, портативный компьютер 10c или персональный компьютер 10d.

[0080] В другом примере, сервер 100b поисковой машины приложений может дополнительно включать в себя виртуальную машину 400, которая содержит модуль/программу 404 для выполнения приложения 1 на вычислительном устройстве 5000. В другом примере, виртуальная машина 400 также может включать в себя модуль 406, который запускает скрипт 405 для выполнения приложения 1 на вычислительном устройстве 5000. Скрипт 405 может храниться в запоминающем устройстве или быть встроен в модуль 406. Модуль 406 также может быть выполнен с возможностью сохранения данных приложения в запоминающем устройстве 19 или другом запоминающем устройстве, подключенном к серверу 100b поисковой машины приложений.

[0081] Фиг. 4D иллюстрирует другой вариант осуществления сети согласно примеру настоящего изобретения. Данные приложения могут передаваться от сервера 200 приложений или первого пользователя 10 непосредственно на сервер 100b поисковой машины приложений, и сервер 100b поисковой машины приложений будет сохранять данные в запоминающем устройстве 19 или другом запоминающем устройстве. В другом примере, сервер 200 приложений может передавать данные приложения непосредственно в запоминающее устройство, и данные приложения будут сохраняться в таком запоминающем устройстве. Сервер 100b поисковой машины приложений может искать в запоминающем устройстве данные, которые релевантны любому запросу.

[0082] Вариант осуществления, проиллюстрированный на фиг. 4D, не требует выполнения приложения для получения данных приложения из сервера приложений. Например, программа может быть реализована, сконфигурирована в или связана с сервером 200 приложений для переноса или обеспечения имеющихся на нем данных приложения, для сохранения в запоминающем устройстве настоящего изобретения. Программа может представлять собой скрипт или любые программные коды, которые могут осуществлять связь с сервером 200 приложений. Данные приложения на сервере 200 приложений могут переноситься. Получив пользовательский запрос, сервер 100b поисковой машины приложений может искать в запоминающем устройстве данные, которые релевантны запросу. Специалисту в данной области техники понятно, что настоящее изобретение не ограничивается раскрытыми здесь примерами. Возможны другие способы сбора данных на сервере 200 приложений без необходимости в выполнении приложения, и все они подлежат включению в объем настоящего изобретения. Например, программу можно реализовать на сервере 100b поисковой машины приложений в целях осуществления доступа к и/или получения данных приложения из сервера 200 приложений. Здесь, программе нужно знать только URL/URI, соответствующий серверу 200 приложений, чтобы искать данные приложения на сервере 200 приложений. В другом примере, сервер (например, сервер 100b поисковой машины приложений) может выполнять скрипт для анализа приложения 1 для определения, каким является и где находится соответствующий сервер 200 приложений для осуществления доступа к и/или получения данных приложения.

[0083] Согласно вышеописанному варианту осуществления, модуль или инфраструктуру 3000 накопления данных (см. фиг. 4E) можно также реализовать на сервере 100b поисковой машины приложений для анализа и обработки данных приложения, которые передаются непосредственно от сервера 200 приложений. Такая инфраструктура накопления данных может имитировать функции приложения для обработки и понимания данных приложения, обеспеченных сервером 200 приложений. Например, если данные приложения, передаваемые сервером 200 приложений, находятся в дискретных пакетах, инфраструктура накопления данных может собирать пакеты данных и перерабатывать их в значимые данные приложения, пригодные для поиска. Кроме того, инфраструктура накопления данных также может анализировать данные приложения для идентификации нужных данных приложения, исключения нежелательных данных приложения и категоризации данных приложения или их комбинации.

[0084] Описанные здесь программы/модули могут выполняться на процессоре вышеупомянутого(ых) сервера(ов) (например, процессоре 18 сервера 100b поисковой машины приложений). Временные данные программ/модулей также могут сохраняться в кэше процессора или памяти сервера(ов) (например, памяти 12 сервера 100b поисковой машины приложений). Однако специалисту в данной области техники понятно, что настоящие программы/модули можно также реализовать аппаратными средствами (например, в виде аппаратного модуля), например, в микросхеме или схеме.

Обходчик/глобальный поиск по сети

[0085] В одном примере, обходчик сети (поисковый модуль) (средство глобального поиска по сети) может использоваться для сбора пакетов прикладных программ, данных приложения, данных/информации (например, описаний), связанных с приложениями или ссылками на приложения. Сервер 100b поисковой машины приложений или сервер 100e имитации OS может загружать приложения, собранные обходчиком сети, и выполнять их на серверном кластере 100.

Извлечение информации

[0086] Извлечение информации можно применять к данным приложения, обеспеченным сервером приложений или самим приложением в ответ на запросы. Цель состоит в том, чтобы организовать и индексировать данные в значимые категории для достижения эффективности поиска.

Обозреватель приложений

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

Иллюстративное приложение

[0088] На фиг. 5A-5E представлены иллюстративные пользовательские интерфейсы приложения согласно примеру настоящего изобретения. На фиг. 5A, приложение имеет заставку (или страницу активации) 988, которая обычно включает в себя изображение. Заставка 988 может отображаться после активации или открытия приложения.

[0089] Согласно фиг. 5B-5E, пользовательский интерфейс может включать в себя контейнер 900, контент которого, показанный на контейнере 900, может изменяться в зависимости от выбранной вкладки (вкладки могут отображаться в нижней части контейнера 900 как вкладки 918, 920, 922 и 924). Например, на фиг. 5B показана структура контейнера 900, когда выбрана вкладка 918 (т.е. вкладка под названием “элемент”). Структура может включать в себя полоску действия или баннер 926 (который может дополнительно включать в себя ссылку, позволяющую пользователю войти в приложение), фон или рекламу 910 (например, видеоролик, анимацию, фон сменяющихся флэш-изображений). Элементы с 90-1 по 90-5 могут включать в себя необязательные изображения с 90-1p по 90-5p. В одном примере, элементы с 90-1 по 90-5 связываются с сервером веб-приложений для выборки динамических данных, данных в реальном времени приложения из сервера приложений методами http (например, методом “POST” или “GET”, например, “POST http://example.com/apiPurpose.php” или “GET http://example.com/apiPurpose.php?mode=GetData&ID=C00001”). Здесь, когда приложение запрашивает данные приложения у сервера приложений, сервер приложений может передавать ответ в структуре JavaScript Object Notation (JSON) или структуре eXtensible Markup Language (XML) (например, {"status":"OK", "result": {"name": "Happy Cafe", "display": "1", "addr": "3F., No.18-6, Jinhua St., Taipei, Taiwan, R.O.C", "desc": "This is the Introduction of Happy Cafe", "shophours": "0800-2200", "openweek": "0111110", "shoptel": "886-33433997", "shopurl": "http://anotherexample.com", "shopimage": [{"http://example.com/images/90-1p.jpg"}]}}). В примере настоящего изобретения, данные приложения, полученные выборкой из сервера приложений, могут включать в себя ссылку на один вид приложения, ссылку на данные приложения, ссылку загрузки на пакет прикладных программ приложения, текст, связанный с приложением или данными приложения, изображение, связанное с приложением или данными приложения, видео, связанное с приложением или данными приложения, и аудио, связанное с приложением или данными приложения.

Иллюстративные пользовательские интерфейсы, обеспечиваемые поисковыми машинами для приложений

[0090] На фиг. 6A-6C показаны другие иллюстративные пользовательские интерфейсы, обеспеченные сервером 100a веб-приложений или сервером 100b поисковой машины приложений пользователю (например, второму пользователю 20) согласно примеру настоящего изобретения. Пользовательские интерфейсы, показанные на фиг. 6A-6C, могут отображаться на экране устройства, например, компьютера, портативного компьютера, планшета/планшетного компьютера, смартфона или других мобильных устройств. Согласно фиг. 6A, приложения, релевантные ключевому слову, могут отображаться с соответствующими пиктограммами 2104, 2108 или 2112 приложений и именами приложений или описаниями 2106, 2110 или 2114 приложений в качестве результатов поиска. Согласно фиг. 6B, результаты поиска могут отображаться в виде списка контента 2118, 2120 или 2122 приложений или в виде ссылок на этот контент. Согласно фиг. 6C, результаты поиска также могут отображаться на карте 2124. Пиктограммы 2104, 2108 и 2112 приложений, в качестве результатов поиска, могут отображаться на карте 2124.

Веб-приложения, расширения и подключаемые программы

Поскольку веб-приложения, расширения и подключаемые программы (приложения) действуют аналогично приложениям, в настоящем изобретении также раскрыт способ поиска приложений. Заметим, что веб-приложения, расширения и подключаемые программы могут выполняться либо на интеллектуальном устройстве, либо на вычислительном устройстве (например, ПК). При выполнении приложений на персональном компьютере, пользователи этих приложений осуществляют связь с назначенными серверам приложений, выполняя при этом их задачи. Например, при использовании расширения “The Weather Channel” для обозревателя Chrome, расширение получает местоположение пользователя (или пользователь может ввести свое местоположение). Затем сервер приложений, совместно с расширением “The Weather Channel”, будет доставлять прогноз погоды для местоположения пользователя или выбранного пользователем местоположения на обозреватель пользователя на компьютере. Механизм здесь весьма аналогичен тому, как пользователи приложений запрашивают данные у сервера приложений.

Планировщик

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

[0093] В одном варианте осуществления, один или более планировщиков может быть выполнен с возможностью планирования виртуальных машин или серверов для выполнения приложений. В другом варианте осуществления, планировщики могут быть выполнены с возможностью планирования модулей робота для выполнения приложений. Планировщик реализуется с целью повышения общей производительности системы настоящего изобретения за счет эффективного выделения и использования системных ресурсов. Например, на фиг. 4J, планировщик 660 может использоваться для координации действий сервера (например, сервера 100b поисковой машины приложений), электронного устройства первого пользователя 10, сети 30, сервера 200 приложений и электронного устройства для второго пользователя 20, для облегчения выполнения приложений. Например, планировщик 660 может координировать их действия согласно требованиям системных компонентов, например, объему необходимых ресурсов, количеству выполняющихся задач, времени ожидания, приоритетам, зависимости данных и т.д. Планировщик 660 также может располагаться внутри сервера (например, на сервере 100b поисковой машины приложений) согласно примеру настоящего изобретения.

[0094] Планировщик может планировать различные компоненты систем на основании политики планирования. Политика планирования определяет режимы выполнения приложений. Например, политика может устанавливать правила, определяющие порядок, в котором приложения выполняются роботами, виртуальными машинами или серверами. Политика планирования также может задавать частоту выполнения приложений, чтобы система знала, сколько раз должно выполняться приложение, и интервал между выполнениями. Политика планирования также может определять время, частоту, приоритет и длительности выполнения и/или любую их комбинацию. Политика планирования может сохраняться в базе данных (например, базе данных 888 или 888′).

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

[0096] Порядок и приоритет выполнения приложений также могут задаваться политикой планирования. Например, политика планирования может включать в себя такие алгоритмы, как алгоритм планирования "первым вошел, первым обслужен", алгоритм планирования "от простого к сложному", алгоритм планирования на основе приоритета, карусельный алгоритм планирования, многоуровневый алгоритм планирования очереди, многоуровневый алгоритм планирования очереди с обратной связью и/или алгоритм планирования в реальном времени. Понимание состояний и ресурсов системы, а также установление категорий и характеристик приложений поможет определиться с применением тех или иных алгоритмов планирования. Например, политика планирования может динамически назначать каждому приложению статус, который будет определять приоритет, в котором приложения должны быть выполнены. В частности, время простоя или истекшее время (после первого выполнения приложения) можно регистрировать для каждого приложения, чтобы планировщик мог динамически менять порядок выполнения приложений в зависимости от статуса приложений.

[0097] Политика планирования может генерироваться согласно подходу искусственного интеллекта (AI) или ручного подхода. В рамках подхода AI, планировщик может обладать интеллектом более высокого уровня для изучения характеристик приложений, причем характеристики приложений могут включать в себя частоты выполнения или типы (т.е. категории) приложений, и т.д. Изучение типа или категории приложения может помочь планировщику в определении частоты выполнения такого приложения. Например, новостное приложение может требовать более высокой частоты выполнения, чем игровое приложение, поскольку новостное приложение обычно обновляет свой контент чаще, чем игровое приложение. Таким образом, если планировщику встречается новостное приложение, он может динамически повысить приоритет или частоту его выполнения, с помощью робота, виртуальной машины или сервера. Напротив, планировщик также может динамически снижать приоритет или частоту выполнения приложения, если ему встречается приложение, которое редко обновляет свой контент.

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

Модуль проверки безопасности приложения

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

[00100] В одном варианте осуществления, как представлено на фиг. 4K, модуль 670 проверки безопасности приложения может быть выполнен с возможностью проверки безопасности прикладных программ или приложений на основании множества уровней безопасности. В частности, множество разных уровней безопасности можно задать для разных требований к обработке приложения и можно использовать для блокировки приложения, не отвечающих конкретному уровню безопасности. Заметим, что модуль 670 проверки безопасности приложения может располагаться вне виртуальной машины 400, но все же на сервере (например, на сервере 100b поисковой машины приложений), в примере настоящего изобретения.

[00101] В другом варианте осуществления, модуль 670 проверки безопасности приложения выполнен с возможностью обеспечения сертификации безопасности для приложений. Приложения, найденные обходчиком, проверяются модулем 670 проверки безопасности приложения для определения, отвечают ли они какому-либо из пяти уровней безопасности, включающих в себя, например, уровень-1, уровень-2, уровень-3, уровень-4 и уровень-5.

[00102] Модуль 670 проверки безопасности приложения может включать в себя набор механизмов сертификации безопасности для каждого из уровней безопасности. Механизмы сертификации безопасности могут включать в себя сертификацию связи, обнаружение вредоносного ПО посредством манифеста и трассировки вызовов API и обнаружение подозрительных поведений системы.

Механизмы для одной/нескольких виртуальных машин

[00103] В вышеприведенных схемах (например, на Фиг. 4A-4K), для выполнения приложений планировщик использует единственную виртуальную машину. В других вариантах осуществления, несколько виртуальных машин может использоваться для одновременного выполнения нескольких приложений на одном сервере. Соответственно, данные приложения нескольких приложений могут одновременно генерироваться, обрабатываться и/или сохраняться на сервере настоящего изобретения. Для пользователя, использующего систему настоящего изобретения, данные приложения нескольких приложений могут одновременно демонстрироваться или отображаться на пользовательском интерфейсе, поддерживаемом сервером, с использованием нескольких виртуальных машин.

[00104] Фиг. 7A-7H иллюстрируют варианты осуществления настоящего изобретения, использующие одну виртуальную машину или несколько виртуальных машин для выполнения приложений.

[00105] Согласно фиг. 7A, иллюстративная система 700 может включать в себя сервер 701a и один или более серверов 201 и 202 приложений, и серверы 701a и 201/202 могут соединяться/осуществлять связь друг с другом через сеть 30. Серверы 201 и 202 приложений могут иметь примерно такие же функциональные возможности, как сервер 200 приложений. Серверы 201 и 202 приложений соответственно назначаются (соответствующим(и) разработчиком(ами) приложений) для обработки данных приложения разных приложений или разных потоков одного и того же приложения, например, сервер 201 приложений может быть конкретно назначен для обработки данных приложения, связанных с приложением “APP_kk” разработчиком приложений приложения APP_kk, и сервер приложений 202 может быть конкретно назначен для обработки данных приложения, связанных с приложением “APP_jj” разработчиком приложений приложения APP_jj. Сеть 30 действует как посредник между сервером 701a и серверами 201 и 202 приложений для передачи данных.

Сервер 701a можно спроектировать на основе сервера 100b, показанного на фиг. 4A-4K, но также может иметь дополнительные функциональные возможности. Сервер 701a может иметь планировщика 710, диспетчера 720 виртуальной машины (диспетчера VM), запоминающее устройство 740, упаковщика 750, модуль 760 хранения пакета приложений и одну или более виртуальных машин 88 и 89. Сервер 701a также, в необязательном порядке, может включать в себя конфигурируемую программно определяемую сеть (SDN) 730.

[00107] Диспетчер 720 VM выполнен с возможностью управления виртуальными машинами 88 и 89 согласно инструкции планировщика 710 (например, инструкции “Ctrl_sm5” для управления виртуальной машиной 89 или инструкции “Ctrl_sm4” для управления виртуальной машиной 88). Диспетчер 720 VM может управлять генерацией, удалением, активацией и/или деактивацией виртуальных машин на сервере 701a. Например, при наличии на сервере 701a приложения, которое должно быть активировано, планировщик 710 предписывает диспетчеру 720 VM создать новую виртуальную машину на сервере 701a для выполнения приложения. В другом примере, при наличии на сервере 701a приложения, которое должно быть деактивировано, планировщик 710 предписывает диспетчеру 720 VM удалить виртуальную машину, ранее назначенную приложению, с сервера 701a. Заметим, что диспетчер 720 VM может действовать на основании политики планирования планировщика 710.

[00108] Заметим, что в некоторых вариантах осуществления диспетчер 720 VM может быть реализован в составе вышеупомянутого модуля робота (например, в составе модуля 650 робота, показанного на фиг. 4I).

[00109] Заметим, что планировщик 710 может быть реализован в виде программных кодов или скриптов, хранящихся внутри сервера 701a, в некоторых вариантах осуществления настоящего изобретения.

[00110] В одном примере, упаковщик 750 выполнен с возможностью обеспечения множества входных событий и/или инструкций для использования приложения, что позволяет приложению выполняться непосредственно на сервере 701a. Входные события могут включать в себя событие-жест, например, событие прикосновения, перемещения или встряхивания в целях оперирования приложением.

[00111] В другом примере, упаковщик 750 выполнен с возможностью упаковки приложения с помощью интерфейса прикладного программирования (API) исполнителя, что позволяет приложению выполняться на сервере 701a с помощью API исполнителя. Приложение может не иметь возможности выполнения, не будучи упаковано с помощью API исполнителя, поскольку приложение может использовать конкретный формат/язык, который одна или более операционных систем, используемых сервером 701a, не в состоянии распознать (например, файл ipa, исполнимый в среде iOS, не может устанавливаться и/или исполняться в среде Android, не будучи упакованным с помощью API исполнителя для перевода/преобразования I/O этого соответствующего приложения iOS в формат(ы), приемлемый(е) для Android). С помощью API исполнителя, приложение будет исполнимым в операционных системах, используемых сервером 701a. Заметим, что приложения, которые должны быть упакованы упаковщиком 750, в некоторых примерах могут поступать от вышеупомянутого обходчика.

[00112] Модуль 760 хранения пакета приложений выполнен с возможностью хранения приложений для сервера 701a, например, хранения приложений APP_11, APP_12, …, APP_1m, APP_21, …, APP_ij, …, APP_n1, APP_n2, … и APP_nm.

[00113] Запоминающее устройство 740 выполнено с возможностью хранения данных приложения, генерируемых при выполнении одного или более приложений на сервере 701a.

[00114] Исходя из того, что виртуальная машина 88 генерируется диспетчером 720 VM специально для выполнения приложения APP_kk, виртуальная машина 88 также может включать в себя гипервизор 88a, который выполнен с возможностью динамически управлять ресурсами виртуальной машины 88. Например, гипервизор 88a может запрашивать ресурсы, необходимые виртуальной машине 88, у сервера 701a, или может освобождать ресурсы, полученные виртуальной машиной 88 обратно на сервер 701a. Гипервизор 88a может включать в себя операционную систему OS_kk. Операционная система OS_kk может включать в себя, по меньшей мере, диспетчера SM_kk приложений и посредника Pr_kk. Диспетчер SM_kk приложений может включать в себя контроллер IC_kk установки для установки приложения APP_kk из хранилища 760 пакета приложений с использованием идентификатора Apk_id_kk приложения APP_kk. Посредник Pr_kk выполнен с возможностью маршрутизировать или принимать данные приложения для приложения APP_kk. Заметим, что посредники на сервере 701a могут действовать как вышеупомянутый посредник 610 сбора данных.

[00115] Аналогично, виртуальная машина 89 генерируется диспетчером 720 VM специально для выполнения приложения APP_jj. Виртуальная машина 89 может включать в себя гипервизор 89a, который выполнен с возможностью динамически управлять ресурсами виртуальной машины 89. Например, гипервизор 89a может запрашивать ресурсы, необходимые виртуальной машине 89, у сервера 701a, или может освобождать ресурсы, полученные виртуальной машиной 89, обратно на сервер 701a. Гипервизор 89a может включать в себя операционную систему OS_jj. Операционная система OS_jj может включать в себя, по меньшей мере, диспетчера SM_jj приложений и посредника Pr_jj. Диспетчер SM_jj приложений может включать в себя контроллер IC_jj установки для установки приложения APP_jj из хранилища 760 пакета приложений.

[00116] Посредник Pr_jj выполнен с возможностью маршрутизировать или принимать данные приложения для приложения APP_jj.

[00117] В некоторых примерах, операционные системы сервера 701a могут представлять собой операционные системы для мобильных электронных устройств, например, iOS, Android, Android-x86 и т.д.

[00118] В некоторых примерах, гипервизоры 88a и 89a могут представлять собой виртуальные машины на основе ядра (KVM).

[00119] В некоторых примерах, виртуальные машины 88 и 89 могут выполняться над операционной системой на основе Linux, например, CentOS (например, CentOS 6.4) или Ubunto.

[00120] В некоторых вариантах осуществления настоящего изобретения, SDN 730 выполнена с возможностью управления передачей и/или приемом данных приложения между виртуальными машинами (например, виртуальными машинами 88 и 89) и соответствующими им серверами приложений (например, серверами 201 и 202 приложений). Конфигурируемая SDN 730 сохраняет адреса (например, IP-адреса) виртуальных машин, обеспеченных сервером 701a. Когда сервер приложений (например, сервер 201 приложений) запрашивает данные приложения для приложения (например, приложения APP_kk), конфигурируемая SDN 730 направляет данные приложения от виртуальной машины, выполняющей приложение (например, виртуальной машины 88), на соответствующий сервер согласно сохраненным адресам. Когда сервер 701a используется для одновременного размещения большого количества виртуальных машин, конфигурируемая SDN 730 будет помогать серверу 701a эффективно управлять трафиком данных приложения между виртуальными машинами и соответствующими им серверами.

[00121] В некоторых примерах, конфигурируемую SDN 730 можно реализовать посредством Open vSwitch.

[00122] Ниже объяснена иллюстративная последовательность операций сервера 701a. Когда сервер 701a подготавливается к выполнению приложения APP_kk, планировщик 710 предписывает диспетчеру 720 VM генерировать виртуальную машину 88. Контроллер IC_kk установки устанавливает приложение APP_kk из модуля 760 хранения пакета приложений на виртуальной машине 88. Затем диспетчер SM_kk приложений может выполнять приложение APP_kk для генерации данных приложения. Посредник Pr_kk может сохранять данные приложения в запоминающем устройстве 740, направлять данные приложения на сервер 201 приложений через сеть 30 (возможно, также с помощью конфигурируемой SDN 730 в некоторых вариантах осуществления настоящего изобретения), или принимать запрос с сервера 201. В результате, виртуальная машина 88 способна генерировать данные приложения в ответ на запрос от сервера 201 приложений и возвращать данные приложения обратно на сервер 201 приложений. После выполнения приложения APP_kk на виртуальной машине 88, гипервизор 88a динамически управляет ресурсами виртуальной машины 88.

[00123] Согласно фиг. 7B, сервер 702a реализован аналогично серверу 701a, за исключением того, что посредники виртуальных машин (например, посредники Pr_kk и Pr_jj) удалены, и для обслуживания виртуальных машин используется объединенный посредник 770.

[00124] Согласно фиг. 7C, сервер 703a реализован аналогично серверу 701a, за исключением того, что виртуальные машины (например, виртуальные машины 88 и 89) объединены в единую виртуальную машину 780. Заметим, что единая виртуальная машина (например, виртуальная машина 780) выполнена с возможностью управления несколькими гипервизорами (например, гипервизорами 88a и 89a) на сервере 703a, что позволяет виртуальной машине 780 одновременно выполнять одно или более приложений.

[00125] Согласно фиг. 7D, сервер 704a реализован аналогично серверу 702a, за исключением того, что виртуальные машины (например, виртуальные машины 88 и 89) объединены в виртуальную машину 790, и гипервизоры виртуальных машин (например, гипервизоры 88a и 89a) также объединены в единый гипервизор 88c. Заметим, что гипервизор (например, гипервизор 88c) выполнен с возможностью одновременно управлять одной или более операционными системами (например, операционными системами OS_kk и OS_jj) на сервере 704a.

[00126] Согласно фиг. 7E, сервер 701b реализован аналогично серверу 701a, за исключением того, что упаковщик 750 перенесен на диспетчера приложений, например, в качестве исполнителей 75a и 75b. Исполнитель 75a выполнен с возможностью упаковки приложения APP_kk с помощью API исполнителя, благодаря чему, приложение APP_kk может исполняться в операционной системе OS_kk. Исполнитель 75b выполнен с возможностью упаковки приложения APP_jj с помощью API исполнителя, благодаря чему, операционная система OS_jj может выполнять приложение APP_jj.

[00127] Согласно фиг. 7F, сервер 702b реализован аналогично серверу 702a, за исключением того, что упаковщик 750 перенесен на диспетчера приложений, например, в качестве исполнителей 75a и 75b.

[00128] Согласно фиг. 7G, сервер 703b реализован аналогично серверу 703a, за исключением того, что упаковщик 750 перенесен на диспетчера приложений, например, в качестве исполнителей 75a и 75b.

[00129] Согласно фиг. 7H, сервер 704b реализован аналогично серверу 704a, за исключением того, что упаковщик 750 перенесен на диспетчера приложений, например, в качестве исполнителей 75a и 75b.

[00130] Заметим, что изменение количества виртуальных машин, показанных на фиг. 7A-7H, также может находиться в объеме настоящего изобретения.

[00131] Заметим, что приемлемые объединение и/или перенос элементов, показанных на фиг. 7A-7H, также может находиться в объеме настоящего изобретения.

Модуль накопления данных

[00132] В некоторых вариантах осуществления, инфраструктуру 3000 накопления данных, показанную на фиг. 4E, можно также реализовать внутри диспетчеров VM, показанных на фиг. 7A-7H (например, диспетчеров SM_kk и SM_jj VM), для анализа и обработки данных приложения. Диспетчер VM можно реализовать в составе вышеописанного модуля робота (например, в составе модуля 650 робота, показанного на фиг. 4I). Модуль 3000 накопления данных может действовать как обработчик для перехвата вызовов API (т.е. системных вызовов), связанных с приложениями, упакованными с помощью API исполнителя, и может регистрировать и анализировать поведения приложений по принципу машинного обучения (или осуществляя выборку данных/контента приложения из системного(ых) вызова(ов)).

[00133] Фиг. 8A иллюстрирует схему концептуального представления OS модуля 3000 накопления данных для обработки данных приложения на уровне пользователя согласно примеру настоящего изобретения. Согласно фиг. 8A, сервер-обработчик 810 связан с или расположен на сервере 100b или 100e и выполнен с возможностью приема перехваченных данных приложения и их переноса в хранилище данных, запоминающее устройство или другое средство предварительной обработки. Программа-обработчик 820 выполнена с возможностью любого из выборки/перехвата, регистрации или анализа данных приложения при или после их приема библиотекой 840 посредством вызова 850 системы/ядра, который вызывает библиотеку 840.

[00134] Иллюстративное взаимодействие, происходящее в ходе выполнения приложения 830, можно описать со ссылкой на фиг. 8A в нижеследующих абзацах:

[00135] стадия 80A: сервер-обработчик 810 принимает выборочные/перехваченные данные приложения от программы-обработчика 820.

[00136] стадия 801: приложение 830 вызывает библиотеку 840 для генерации запроса данных приложения со своего удаленного сервера 200 приложений.

[00137] стадия 802: программа-обработчик 820 обрабатывает библиотеку 840 (например, вызывает API обработчика для обработки данных приложения, принятых библиотекой 840), для приема данных приложения, генерируемых после того, как системный вызов 850 вызывает библиотеку 840 (как это делается на стадии 804).

[00138] стадия 803: после вызова библиотеки 840 приложением 830, генерируется запрос (например, методом POST или GET HTTP) системного вызова 850. Системный вызов 850 может передавать запрос POST или GET HTTP на соответствующий(е) драйвер(ы), например, на драйвер карты сетевого интерфейса (NIC). Драйвер NIC будет преобразовывать/трансформировать/кодировать/внедрять запрос POST или GET HTTP для формирования пакета(ов) передавать его на удаленный сервер приложений, связанный с приложением 830 (например, сервер 200 приложений), через интернет посредством подуровня MAC (т.е. подуровня управления доступом к среде канального уровня модели OSI) и/или посредством уровня PHY (т.е. физического уровня модели OSI).

[00139] стадия 804: системный вызов 850 переносит данные приложения, принятые им от драйвера(ов), в библиотеку 840.

[00140] стадия 805: данные приложения, принятые библиотекой 840 из системного вызова 850, перехватываются или выбираются программой-обработчиком 820 на этой стадии.

[00141] стадия 806: результат в ответе на запрос на стадии 803 генерируется после приема данных приложения и вызова библиотеки 840 из системного вызова 850. Например, если исходный запрос является запросом контента, то после приема контента (например, статьи с множеством текстов) системным вызовом 850, он вызывает библиотеку 840, чтобы показать контент на UI (т.е. пользовательском интерфейсе) приложения 830 (например, класс для отображения сложенный вид/окно на UI приложения 830 можно использовать для отображения/демонстрации контента).

[00142] В одном примере, запрос может нести ключевые слова, данные приложения могут нести результаты поиска, соответствующие таким ключевым словам, и программу-обработчик 820 можно применять для приема результатов поиска. Результаты поиска могут сохраняться в запоминающем устройстве (например, запоминающем устройстве 740 или хранилище 8888 данных) после последовательности обработки, начатой на сервере-обработчике 810.

[00143] Фиг. 8B иллюстрирует схему концептуального представления OS модуля 3000 накопления данных для обработки данных приложения на уровне ядра согласно примеру настоящего изобретения. Согласно фиг. 8B, функциональные возможности элементов, показанных на фиг. 8B, примерно такие же, как у показанных на фиг. 8A, поэтому они здесь повторяться не будут.

[00144] Иллюстративное взаимодействие, происходящее в ходе выполнения приложений 830, показанных на фиг. 8B, описано в нижеследующих абзацах:

[00145] стадия 80A: такая же, как описана со ссылкой на фиг. 8A.

[00146] стадия 801: такая же, как описана со ссылкой на фиг. 8A.

[00147] стадия 812: после вызова библиотеки 840 приложением 830, запрос генерируется и перехватывается программой-обработчиком 820.

[00148] стадия 813: программа-обработчик 820 отправляет запрос на вызов 850 системы/ядра. Аналогично, вызов 850 системы/ядра передает запрос (например, методом POST или GET HTTP) на соответствующий(е) драйвер(ы), и драйвер(ы) преобразовывает/трансформирует/кодирует/внедряет запрос для формирования пакета(ов) и передает его на сервер приложений, связанный с приложением 830 (например, сервер 200 приложений) через интернет на уровне MAC или PHY.

[00149] стадия 814: вызов 850 системы/ядра переносит принятые данные приложения на программу-обработчик 820.

[00150] стадия 815: программа-обработчик 820 переносит данные приложения в библиотеку 840.

[00151] стадия 806: такая же, как описана со ссылкой на фиг. 8A.

[00152] В некоторых вариантах осуществления, часть задач модуля 3000 накопления данных может переноситься на посредников, показанных на фиг. 7A-7H, для освобождения загрузки диспетчеров VM, показанных на фиг. 7A-7H.

[00153] Фиг. 9A и 9B иллюстрируют примеры использования посредников, показанных на фиг. 7A-7H, для осуществления задач(и) модуля 3000 накопления данных в целях сбора данных приложения.

[00154] На фиг. 9A и фиг. 9B, “политика и логика” означает политику планирования планировщика, например, планировщика 710.

[00155] Ниже описаны стадии фиг. 9A:

[00156] стадия 901: планировщик запрашивает политику планирования, связанную с приложением.

[00157] стадия 902: в ответ на запрос осуществляется подтверждение.

[00158] стадия 903: планировщик активирует диспетчера VM, соответствующего приложению.

[00159] стадия 904: под управлением планировщика, диспетчер VM либо активирует или деактивирует приложение, либо использует приложение.

[00160] стадия 905: приложение отправляет запрос на соответствующий ему сервер приложений.

[00161] стадия 906: сервер приложений возвращает ответ, несущий данные или контент, связанные с запросом.

[00162] стадия 907: посредник, соответствующий приложению, выбирает/перехватывает и сохраняет данные или контент в ответе в запоминающее устройство или хранилище данных.

[00163] Ниже описаны стадии, показанные на фиг. 9B, включающие в себя механизм проверки безопасности приложений:

[00164] стадия 911: планировщик запрашивает политику планирования, связанную с приложением.

[00165] стадия 912: в ответ на запрос осуществляется подтверждение.

[00166] стадия 913: планировщик активирует диспетчера VM, соответствующего приложению.

[00167] стадия 914a: диспетчер VM вызывает модуль проверки безопасности приложения для отслеживания уровня безопасности приложения.

[00168] стадия 914b: диспетчер VM вызывает посредника для выборки/перехвата передаваемых данных, связанных с приложением, для дальнейшего анализа.

[00169] стадия 915: под управлением планировщика, диспетчер VM либо активирует или деактивирует приложение, либо использует приложение.

[00170] стадия 916: приложение отправляет запрос на соответствующий ему сервер приложений под контролем модуля проверки безопасности приложения и перехвата посредника.

[00171] стадия 917: сервер приложений возвращает ответ, несущий данные или контент, связанные с запросом, под контролем модуля проверки безопасности приложения и перехвата посредника.

[00172] стадия 918a: приложение запрашивает модуль проверки безопасности приложения прекратить контроль.

[00173] стадия 918b: приложение запрашивает посредника прекратить выборку/перехват данных, связанных с приложением.

[00174] стадия 919: посредник сохраняет выборочные/перехваченные данные или контент в запоминающее устройство или хранилище данных.

[00175] стадия 920: приложение отвечает на запрос прекращения.

[00176] стадия 921: посредник отвечает на запрос прекращения.

[00177] стадия 922: диспетчер VM отвечает на запрос прекращения.

[00178] стадия 923: планировщик сохраняет результаты процедуры сбора данных приложения в запоминающем устройстве или хранилище данных.

[00179] На фиг. 9C показана блок-схема последовательности операций модуля 3000 накопления данных или посредников, показанных на фиг. 7A-7H, при выборке/перехвате данных/контента, связанных с приложением.

[00180] стадия 931: принять запрос перехвата от диспетчера VM, когда приложение активировано. Заметим, что запрос перехвата может включать в себя идентификационную информацию приложения.

[00181] стадия 932: связать запрос перехвата с входящими данными/контентом, связанными с приложением, одновременно со сбором входящих данных/контента. Заметим, что входящие данные или контент можно связывать в форме стеков.

[00182] стадия 933: перехватывать и/или анализировать собранные данные/контент, связанные с приложением.

[00183] стадия 934: ответить на запрос прекращения и сохранить собранные данные/контент в запоминающем устройстве или хранилище данных.

[00184] Фиг. 9D иллюстрирует блок-схему операций планировщика согласно варианту осуществления.

[00185] стадия 941: извлечь политику планирования из запоминающего устройства или хранилища данных. Заметим, что в процессе извлечения политики планирования может быть вызвано событие таймера (например, установление метки времени).

[00186] стадия 942: отправить запрос перехвата диспетчеру VM.

[00187] стадия 943: ожидать извещения о прекращении и сохранить перехваченные данные/контент, связанные с приложением, по получении извещения о прекращении.

[00188] На фиг. 9E показана блок-схема последовательности операций диспетчера VM (робота) согласно варианту осуществления.

[00189] стадия 951: принять запрос перехвата от планировщика, когда приложение активировано, причем запрос перехвата предназначен для перехвата данных/контента, связанных с приложением.

[00190] стадия 952: диспетчер VM активируется планировщиком для перехвата данных/контента, связанных с приложением.

[00191] стадия 953: выполнить функции приложения согласно планировщику.

[00192] стадия 954: отправить запрос перехвата на модуль проверки безопасности приложения.

[00193] стадия 955: отправить запрос перехвата на модуль накопления данных или посредника.

[00194] стадия 956: сообщить планировщику о прекращении его активности и сохранить данные/контент, связанные с приложением, в запоминающее устройство или хранилище данных.

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

[00196] Специалисту в данной области техники понятно, что способ поиска, связанный с приложением, аналогичен способу поиска в контексте приложений, который был описан подробно ранее. Таким образом, все варианты осуществления, способы, системы и компоненты, связанные с приложениями, применимы к приложениям.

Claims

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15. Способ по п. 12, в котором этап имитации содержит:
имитацию поведений пользователя, регистрируя поведения пользователей-людей, которые управляют упомянутой одной или более прикладными программами.

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

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

18. Способ по п. 12, в котором упомянутая одна или более прикладных программ содержат мобильное приложение, веб-приложение, расширение и/или подключаемую программу, способные исполняться на персональном компьютере.

19. Способ по п. 12, в котором этап планирования дополнительно содержит планирование одного или более модулей робота для исполнения упомянутой одной или более прикладных программ согласно политике планирования.

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

21. Способ по п. 20, в котором этап исполнения содержит:
исполнение упомянутой по меньшей мере одной прикладной программы на виртуальной машине.

22. Способ по п. 20, в котором этап исполнения содержит:
исполнение упомянутой по меньшей мере одной прикладной программы посредством команды пользователя, модуля, программы, скрипта или робота.

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

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

25. Способ по п. 24, в котором этап сбора дополнительно содержит этап, на котором:
предписывают упомянутой одной или более прикладным программам или упомянутому одному или более серверам приложений передавать данные.

26. Способ по п. 24, дополнительно содержащий:
анализ упомянутой одной или более прикладных программ для нахождения URL/URI сервера приложений для сбора данных.