СИСТЕМА ДЛЯ ПРИОРИТЕТА ПРИЛОЖЕНИЯ, ОСНОВАННОГО НА РЕЖИМЕ РАБОТЫ УСТРОЙСТВА Российский патент 2009 года по МПК G06F13/14 G06F13/38 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

ОПИСАНИЕ ПРЕДШЕСТВУЮЩЕГО УРОВНЯ ТЕХНИКИ

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

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

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

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

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

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

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

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

фиг.5 показывает один из вариантов осуществления способа для работы арбитра ресурса для обеспечения одного из вариантов осуществления системы приоритета приложения;

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

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

ПОДРОБНОЕ ОПИСАНИЕ

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

В одном или более вариантах осуществления система приоритета приложения взаимодействует со средой выполнения, выполняющейся на устройстве, которая используется для упрощения работы устройства, к примеру, посредством предоставления обобщенных вызовов касательно специфичных устройству ресурсов. Одной из таких сред выполнения является программная платформа Binary Runtime Environment for Wireless™ (двоичной среды выполнения для беспроводной связи, BREW®), разработанная корпорацией QUALCOMM, Сан-Диего, штат Калифорния. В последующем описании будет предполагаться, что один из вариантов осуществления системы приоритета приложения реализован с использованием беспроводного устройства, которое приводит в исполнение среду выполнения, такую как программная платформа BREW. Однако один или более вариантов осуществления системы приоритета приложения пригодны для использования с другими типами сред выполнения, чтобы динамически выделять наиболее заметный ресурс на проводных или беспроводных устройствах. Кроме того, термин «наиболее заметный ресурс» используется в материалах настоящей заявки для описания любого типа аппаратного и/или программного ресурса на устройстве, который используется для представления текущего фокуса устройства, в том числе, но не в качестве ограничения, комбинации дисплея и кнопочной панели.

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

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

Устройство 102 включает в себя приложения 116, которые выполняются на устройстве, чтобы обеспечивать свойства и функции, требуемые пользователю устройства. Например, приложения 116 могут загружаться на устройство 102 с сервера 108, как показано траекторией 120. Во время выполнения приложения 116 пытаются получить доступ к наиболее заметному ресурсу 118 устройства 102, который в одном из вариантов осуществления содержит дисплей и кнопочную панель устройства.

В одном из вариантов осуществления каждое из приложений 116 имеет один или более ID (идентификаторов) групп, которые указывают права и привилегии приложения. Например, ID группы идентифицирует, является ли приложение привилегированным (Р) или непривилегированным (nP) по отношению к наиболее заметному ресурсу. В одном из вариантов осуществления оба, привилегированное и непривилегированное, приложения могут осуществлять доступ к наиболее заметному ресурсу, однако привилегированным приложениям предоставлена возможность задавать выбранные приложения или группы, которым будет передаваться управление наиболее заметным ресурсом.

В одном из вариантов осуществления устройство 102 содержит арбитр 112 и правила 114 арбитража. Например, арбитр 112 и правила 114 арбитража могут загружаться на устройство 102 с сервера 108, как показано траекторией 120. Арбитр 112 действует, чтобы осуществлять арбитраж запросов на наиболее заметный ресурс 118 от конкурирующих приложений, выполняющихся на устройстве 102. Арбитр 112 разрешает запросы арбитража на основании информации о запрашивающем приложении и владеющем ресурсом приложения. В одном из вариантов осуществления состояние привилегии владеющего приложения и правила 114 арбитража используются для выработки арбитражного решения, которое указывает, каким образом выделять наиболее заметный ресурс 118 конкурирующим приложениям. Таким образом, посредством ассоциативного связывания конкретного состояния привилегии с выбранным приложением и загрузки конкретного набора правил 114 арбитража с сервера 108 на устройство 102, для сервера 108 является возможным управлять тем, каким образом наиболее заметный ресурс 118 на устройстве выделяется приложениям 116.Это предоставляет серверу 108 возможность управлять пользовательским впечатлением, обеспечиваемым устройством 102.

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

Фиг.2 показывает функциональную схему одного из вариантов осуществления системы 200 приоритета приложения для выделения наиболее заметного ресурса в устройстве, например устройстве 102, показанном на фиг.1. Система 200 содержит диспетчер 202 наиболее заметного ресурса, состояние 204 наиболее заметного ресурса, арбитр 206 ресурса и правила 208 арбитража. Также показаны наиболее заметный ресурс 210 устройства и приложения (1-4), которые выполняются на устройстве, которые в целом показаны у 212.

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

Состояние 204 наиболее заметного ресурса выполнено в виде аппаратных средств, программного обеспечения или любой их комбинации. В одном из вариантов осуществления состояние 204 наиболее заметного ресурса содержит информацию о наиболее заметном ресурсе 210 и/или информацию о текущем владельце ресурса (информацию о владельце). Например, приложение, которому в текущий момент выделен наиболее заметный ресурс 210, считается владельцем ресурса, текущим владельцем или владеющим приложением. Например, в одном из вариантов осуществления, состояние 204 наиболее заметного ресурса содержит информацию о текущем владельце, которая содержит идентификатор (ID), один или более ID группы, состояние привилегии, причину для захвата ресурса, список освобождения и/или любую другую информацию о текущем владельце или наиболее заметном ресурсе 210. В одном из вариантов осуществления список освобождения идентифицирует, каким приложениям или группам (то есть классам привилегий) текущий владелец способен освобождать наиболее заметный ресурс 210. В одном из вариантов осуществления этот список задействуется в управлении во время процесса арбитража, проводимого арбитром 206 ресурса. В еще одном варианте осуществления этот список освобождения считается только рекомендацией для арбитра 206 ресурса в отношении того, каким образом должны разрешаться арбитражи. Диспетчер 202 наиболее заметного ресурса действует, чтобы поддерживать, обновлять, изменять, дополнять, удалять или иным образом обрабатывать информацию, которая содержится в состоянии 204 ресурса.

Арбитр 206 ресурса содержит аппаратные средства, программное обеспечение или любую их комбинацию и действует, чтобы осуществлять арбитраж доступа к наиболее заметному ресурсу 210 с использованием правил 208 арбитража. Например, в одном из вариантов осуществления, арбитр 206 ресурса может быть программным модулем, а правила 208 арбитража могут быть параметрами, хранимыми в памяти, которые извлекаются арбитром 206 ресурса и обрабатываются для динамического выделения наиболее заметного ресурса 210. В одном или более вариантах осуществления диспетчер 202 наиболее заметного ресурса и арбитр 206 ресурса могут быть реализованы в виде загружаемых расширений к среде выполнения, исполняющейся на устройстве; например, они могут быть загружаемыми расширениями BREW.

Во время работы одного из вариантов осуществления динамической системы 200 приоритета приложения, приложение представляет на рассмотрение диспетчеру 202 наиболее заметного ресурса запрос выделения ради доступа к наиболее заметному ресурсу 210. Если наиболее заметный ресурс 210 имеется в распоряжении, диспетчер 202 наиболее заметного ресурса выделяет наиболее заметный ресурс 210 запрашивающему приложению. Если наиболее заметным ресурсом 210 в настоящий момент владеет другое приложение, диспетчер 202 наиболее заметного ресурса отвечает компоновкой запроса арбитража, который содержит информацию о запрашивающем приложении (информацию о запросчике) и информацию о текущем владельце ресурса (информацию о владельце). Информация о запрашивающем приложении извлекается из запроса выделения, а информация о текущем владельце ресурса извлекается из состояния 204 наиболее заметного ресурса. Запрос арбитража отправляется арбитру 206 ресурса, как показано у 214. Арбитр 206 ресурса обрабатывает запрос арбитража с использованием правил 208 арбитража для выработки арбитражного решения, которое отправляется обратно диспетчеру 202 наиболее заметного ресурса, как показано у 216. Диспетчер 202 наиболее заметного ресурса затем действует, чтобы выделять наиболее заметный ресурс 210 надлежащему приложению согласно арбитражному решению.

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

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

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

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

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

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

Фиг.3 показывает один из вариантов осуществления устройства 300, которое включает в себя один из вариантов осуществления системы приоритета приложения. Устройство 300 содержит обрабатывающую логику 302, память 304, логику 306 отображения, логику 308 кнопочной панели, и интерфейс 310 I/O (ввода/вывода), и все они присоединены к внутренней шине 312 данных. В целях ясности, будет предполагаться, что наиболее заметный ресурс 332 на устройстве 300 содержит логику 306 отображения и логику 308 кнопочной панели. Должно быть отмечено, что один или более вариантов осуществления системы приоритета приложения пригодны для использования с другими устройствами, имеющими разные конфигурации, и что является возможным определять наиболее заметный ресурс 332 с использованием разных функциональных элементов.

Обрабатывающая логика 302 содержит ЦПУ (центральное процессорное устройство, CPU), процессор, вентильную матрицу, дискретную логику, или другие аппаратные средства или программное обеспечение, или любую их комбинацию. Таким образом, обрабатывающая логика 302 обычно содержит логику для приведения в исполнение машиночитаемых инструкций, чтобы выполнять функции, описанные в материалах настоящей заявки. Например, инструкции могут загружаться в устройство 300 с машиночитаемого носителя, такого как гибкий диск, CDROM (ПЗУ на компакт-диске), флэш-память, или другого машиночитаемого носителя, который взаимодействует с устройством 300 через интерфейс 310. В еще одном варианте осуществления инструкции могут загружаться на устройство 300 с сетевого ресурса, такого как сетевой сервер, или любого другого типа сетевого ресурса, через интерфейс 310. Инструкции, когда выполняются обрабатывающей логикой 302, обеспечивают один или более вариантов осуществления системы приоритета приложения, как описано в материалах настоящей заявки.

Память 304 содержит любой тип ОЗУ (оперативного запоминающего устройства, RAM), ПЗУ (постоянного запоминающего устройства, ROM), жесткого диска, дискеты, флэш-памяти или любой другой тип устройства памяти. Логика 306 отображения содержит логику для управления устройством отображения, таким как ЭЛТ (электронно-лучевая трубка CRT), LCD (жидкокристаллический дисплей), или любым другим типом устройства отображения. Логика 308 кнопочной панели содержит логику для управления устройством пользовательского ввода, таким как кнопочная панель, перо, джойстик, или любым другим типом устройства пользовательского ввода, чтобы принимать пользовательский ввод. Интерфейс 310 I/O содержит аппаратные средства и/или программное обеспечение, или любую их комбинацию для предоставления устройству 308 возможности взаимодействовать с внешними устройствами или системами. Например, интерфейс 310 I/O содержит логику для взаимодействия с внешними запоминающими системами, такими как дисковые приводы или другие устройства памяти. Интерфейс 310 также содержит логику для взаимодействия с внешними системами, такими как система локального компьютера. В дополнение интерфейс также содержит логику для взаимодействия с сетью передачи данных, предоставляющей возможность связи с удаленными компьютерами и серверами.

Во время работы устройства программные инструкции, выполняемые обрабатывающей логикой 302, активируют среду 314 выполнения. Например, среда выполнения может быть средой выполнения BREW. Программные инструкции, выполняемые обрабатывающей логикой 302, также активируют диспетчер 318 наиболее заметного ресурса. Диспетчер 318 наиболее заметного ресурса действует, чтобы контролировать доступ к наиболее заметному ресурсу 332, чтобы предоставлять приложениям возможность управлять ресурсом 306 дисплея и ресурсом 308 кнопочной панели. Таким образом, диспетчер 318 наиболее заметного ресурса действует, чтобы контролировать доступ к наиболее заметному ресурсу 332 (дисплею 306 и кнопочной панели 308) для предоставления приложениям возможности взаимодействовать с пользователем устройства.

Диспетчер 318 наиболее заметного ресурса принимает запросы на доступ к наиболее заметному ресурсу 332 от приложений (320, 322, 324, 326), работающих на устройстве 300. Приложения (320, 322, 324, 326) могут быть любым типом приложений, пригодных для выполнения на устройстве 300. Например, приложения могут быть мультимедийными приложениями, календарными приложениями, приложениями электронной почты, приложениями голосовой обработки или любым другим типом приложений, которые, когда выполняются на устройстве 300, обеспечивают полезные свойства и/или функции. Для облегчения выделения наиболее заметного ресурса 332, диспетчер 318 наиболее заметного ресурса поддерживает состояние 328 наиболее заметного ресурса в памяти 304. Состояние 334 устройства идентифицирует текущий режим работы устройства, например, режим работы устройства может быть режимом простоя, работы приложения, приема сообщения, обработки голосового вызова, проигрывания игры, или любым другим типом режима работы устройства.

В то время как приложения (320, 322, 324, 326) выполняются на устройстве 300, они представляют на рассмотрение диспетчеру 318 наиболее заметного ресурса запросы на доступ к наиболее заметному ресурсу 332. В случае, когда наиболее заметный ресурс 332 не выделен в текущий момент, наиболее заметный ресурс 332 может беспрепятственно выделяться запрашивающему приложению. Однако, если наиболее заметный ресурс 332 выделен в текущий момент одному приложению, любому запросу на доступ к наиболее заметному ресурсу 332 от другого приложения необходимо подвергаться арбитражу для определения, какому приложению будет выделен наиболее заметный ресурс 332.

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

В одном из вариантов осуществления арбитр 316 ресурса обрабатывает запрос арбитража согласно правилам 330 арбитража, хранимым в памяти 304. Например, в одном из вариантов осуществления, правила 330 арбитража загружаются в устройство 300 с сетевого сервера, с тем чтобы сетевой сервер был способен предоставлять входные данные в отношении того, каким образом запросы ресурса подвергаются арбитражу в устройстве 300. Запрос арбитража обрабатывается арбитром 316 ресурса для выработки арбитражного решения, которое возвращается диспетчеру 318 наиболее заметного ресурса. Диспетчер 318 наиболее заметного ресурса затем выделяет ресурс на основании арбитражного решения.

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

Арбитр ресурса

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

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

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

A. Информация о владельце ресурса

1. Идентификатор класса владельца (CLSID) и указатель экземпляра

2. Причина для захвата TVR

3. Информация управления освобождением

a. Список идентификаторов освобождения

b. Номер по списку (-1 = все, 0 = ни одного, иначе - номер)

B. Информация о запросчике

1. Идентификатор класса запросчика (CLSID) и указатель экземпляра

2. Причина для захвата TVR

3. Информация управления освобождением

a. Список идентификаторов освобождения

b. Номер по списку (-1 = все, 0 = ни одного, иначе - номер)

Фиг.4 показывает один из вариантов осуществления способа 400 обеспечения одного из вариантов осуществления системы приоритета приложения для использования в устройстве: В целях ясности, работа по способу 400 будет описана со ссылкой на устройство 300, показанное на фиг.3. Например, способ 400 показывает, каким образом, в одном из вариантов осуществления, наиболее заметный ресурс 332 (дисплей 306 и кнопочная панель 308) динамически выделяются одному из приложений 320, 322, 324 и 326.

На этапе 402 первое приложение отправляет запрос выделения ресурса администратору 318 наиболее заметного ресурса, ассоциативно связанному с наиболее заметным ресурсом 332. Например, приложение 320 отправляет запрос выделения ресурса диспетчеру 318 наиболее заметного ресурса, чтобы запрашивать выделение наиболее заметного ресурса 332. Запрос выделения включает в себя информацию о приложении 320; например, запрос выделения включает в себя информацию о запросчике, которая описана выше.

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

На этапе 406 второе приложение отправляет запрос выделения ресурса администратору 318 наиболее заметного ресурса, ассоциативно связанному с наиболее заметным ресурсом 332. Например, приложение 322 отправляет запрос выделения ресурса диспетчеру 318 наиболее заметного ресурса, чтобы запросить выделение наиболее заметного ресурса 332. Запрос выделения включает в себя информацию о приложении 322; например, запрос выделения включает в себя информацию о запросчике, которая описана выше.

На этапе 408 диспетчер 318 наиболее заметного ресурса отправляет запрос арбитража арбитру 316 ресурса. Например, диспетчер 318 наиболее заметного ресурса отправляет запрос арбитража арбитру 316 ресурса. Запрос арбитража включает в себя информацию о владельце ресурса из состояния 328 наиболее заметного ресурса и информацию о запросчике из запроса выделения. Таким образом, запрос арбитража снабжает арбитра 316 ресурса информацией о текущем владельце и текущем запросчике наиболее заметного ресурса 332.

На этапе 410 арбитр 316 ресурса формирует арбитражное решение, которое указывает, какое приложение должно быть наделено наиболее заметным ресурсом 332. Например, арбитр 316 ресурса формирует арбитражное решение и передает решение диспетчеру 318 наиболее заметного ресурса. Арбитр 316 ресурса формирует арбитражное решение на основании правил 330 арбитража, хранимых в памяти 304. В одном из вариантов осуществления арбитр 316 ресурса и правила 330 арбитража загружаются от третьей стороны, такой как OEM/поставщик услуг, которая предоставляет возможность загрузки, и, к тому же, предусматривает механизм для третьей стороны, чтобы решать, каким образом наиболее заметный ресурс 332 выделяется на устройстве. Более подробное описание того, каким образом арбитр 316 ресурса формирует арбитражное решение, предусмотрено в другом разделе этого документа.

На этапе 412 диспетчер 318 наиболее заметного ресурса выделяет наиболее заметный ресурс 332 на основании арбитражного решения. Например, диспетчер 318 наиболее заметного ресурса выделяет наиболее заметный ресурс либо первому приложению 320, либо второму приложению 322 на основании арбитражного решения. Диспетчер 318 наиболее заметного ресурса также обновляет состояние 328 наиболее заметного ресурса новой информацией о владельце ресурса.

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

Фиг.5 показывает один из вариантов осуществления способа 500 работы арбитра ресурса для обеспечения одного из вариантов осуществления системы приоритета приложения. В целях ясности, работа по способу 500 будет описана со ссылкой на устройство 300, показанное на фиг.3. Таким образом, в одном из вариантов осуществления способ 500 реализован арбитром 316 ресурса, показанным на фиг.3.

На этапе 502 запрос арбитража принимается в арбитре 316 ресурса. Например, диспетчер 318 наиболее заметного ресурса представляет на рассмотрение запрос арбитража арбитру 316 ресурса. Запрос арбитража содержит информацию о текущем владельце (информацию о владельце) наиболее заметного ресурса 332 и информацию о приложении, запрашивающем (информацию о запросчике) доступ к наиболее заметному ресурсу 332.

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

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

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

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

Пример реализации

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

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

Фиг.6 показывает один из вариантов осуществления архитектуры 600 управления ресурсом, подходящей для использования с одним или более вариантами осуществления системы приоритета приложения. Для каждого наиболее заметного ресурса 602, являющегося диспетчеризируемым, есть интерфейс 604 ресурса, который управляет объектом, интерфейс 606 IResourceCtl для управления доступом, и диспетчер 608 наиболее заметного ресурса. Дополнительно предусмотрен арбитр 610 ресурса для арбитража доступа к наиболее заметному ресурсу 602.

Когда экземпляр интерфейса 604 ресурса создан, он включает в себя экземпляр 612 IResourceCtl. Экземпляр 612 IResourceCtl взаимодействует с диспетчером 608 наиболее заметного ресурса, чтобы захватывать и освобождать лежащий в основе наиболее заметный ресурс 602. Должно быть отмечено, что даже, если одно приложение обладает управлением наиболее заметным ресурсом 602, другое приложение могло бы получить управление тем же самым наиболее заметным ресурсом 602 в любой момент времени на основании существующих правил арбитража.

Фиг.7 показывает схему 700, которая иллюстрирует пример выделения, который описывает, каким образом наиболее заметный ресурс в устройстве распределяется между двумя приложениями, в соответствии с одним или более вариантами осуществления динамической системы арбитража. Например, схема 700 показывает взаимодействие между различными сущностями устройства, содержащими арбитр 702 ресурса, диспетчер 704 наиболее заметного ресурса, приложение А 706, экземпляр А 708 ресурса, приложение В 712 и экземпляр В 714 ресурса.

В начале примера выделения приложение А 706 выдает запрос 714 ресурса в экземпляр А 708 ресурса, чтобы захватить доступ к наиболее заметному ресурсу устройства, управляемому диспетчером 704 наиболее заметного ресурса. Запрос ресурса пересылается из экземпляра А 708 ресурса диспетчеру 704 наиболее заметного ресурса, как показано посредством 716. Будет предполагаться, что в этот момент времени наиболее заметный ресурс является невыделенным, так что диспетчер 704 наиболее заметного ресурса выделяет наиболее заметный ресурс приложению А 706 и выдает указатель «доступа», который прибывает обратно в приложение А 708, каковое показано у 718 и 720. В этот момент наиболее заметный ресурс был захвачен приложением А 708. Дополнительно приложение А 706 регистрирует функцию обратного вызова с помощью экземпляра А 708 ресурса, чтобы принимать информацию о любых изменениях состояния относительно наиболее заметного ресурса, как показано на 722.

Позже приложение В 710 выдает запрос 724 ресурса в экземпляр В 712 ресурса, чтобы захватить наиболее заметный ресурс, управляемый диспетчером 704 наиболее заметного ресурса. Запрос ресурса пересылается из экземпляра В 712 ресурса диспетчеру 704 наиболее заметного ресурса, как показано посредством 726. Запрос от приложения В 710 побуждает диспетчера 704 наиболее заметного ресурса запрашивать арбитраж у арбитра 702 ресурса, как показано у 728. Арбитр 702 ресурса обрабатывает запрос 730 арбитража в соответствии с вариантами осуществления, описанными в материалах настоящей заявки. Арбитр 702 ресурса предоставляет результат арбитража, который указывает, что наиболее заметный ресурс успешно выделялся приложению В 710, как показано посредством 730, 732 и 734. Поэтому, в этот момент, приложение В 710 захватило наиболее заметный ресурс. Так как приложение А 706 регистрировалось на уведомления (на 722) о изменении состояния, приложение А 706 предупреждается посредством функции 736 обратного вызова, потому что состояние наиболее заметного ресурса изменилось. Таким образом, в ответ на обратный вызов, приложение А 706 выдает команду 738 «получить состояние», которая возвращает уведомление, что наиболее заметный ресурс был выделен другому приложению и теперь занят.

Настройка арбитра ресурса

Арбитр ресурса является принимающим централизованное решение, который определяет, может ли наиболее заметный ресурс передаваться запрашивающему объекту. Модуль арбитра ресурса является настраиваемым OEM/поставщиком услуг и может быть реализован в виде загружаемого модуля, использующего идентификатор класса (CLSID). В одном из вариантов осуществления есть реализация одиночного арбитра ресурса (IResArbiter) для наиболее заметного ресурса. В одном из вариантов осуществления метод арбитра ресурса, IResArbiter_ConfirmAcquire, подвергается пересылке информации о владельце и информации о запросчике ресурса, как описано выше, для того, чтобы выработать арбитражное решение.

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

int OEMResArbiter_ConfirmAcquire (IResArbiter * po, AEECLSID clsReq,AEEResCtlInfo * pOwner, AEEResCtlInfo * pRequester)

{

CResArbiter * pMe = (CResArbiter*)po;

int status = EITEMBUSY;

int i;

//

// первый список класса проверки для просмотра, будет ли владелец его разрешать

//

switch (pOwner->nClsCount)

{

case -1: // разрешать любому захватывать ресурс

status = SUCCESS;

break;

case 0: // ни одному не разрешать захватывать ресурс

status = EITEMBUSY;

break;

default: // проверять список доступа (освобождения)

for (i=0; i<pOwner->nClsCount; i++)

{

uint32 privId = pOwner->pClsList[i];

if (privId < QVERSION)

{

// причина приемлема?

if (privId == pRequester->dwReason)

{

status = SUCCESS;

break;

}

}

else

{

// идентификатор класса запросчика соответствует или содержит привилегию группы?

if (ISHELL_CheckPrivLevel(pMe->m_pIShell, privId, TRUE))

{

status = SUCCESS;

break;

}

}

}

break;

}

// В этот момент, OEM может предпочесть принять

// проверки разрешения списка доступа

// и/или добавить дополнительные алгоритмы выбора

// решений, такие

// как исследование текущей причины для доступа или

// предоставление отдельных

// CLSID запросчиков, невзирая на список доступа

// владельца и т.п.

// BREW устанавливает dwReason в RESCTL_REASON_BUSY,

// если текущее

// приложение отвечает на EVT_BUSY.

if (pOwner->dwReason == RESCTL_REASON_BUSY && clsReq ==

AEECLSID_TOPVISIBLECTL)

status = EITEMBUSY;

return (status);

}

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

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

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

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

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

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

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

диспетчер ресурса, содержащий:

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

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

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

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

логику для выделения наиболее заметного ресурса на основании арбитражного решения.

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

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

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

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

средство для распределения наиболее заметного ресурса на основании арбитражного решения.

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

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

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

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

команды для выделения наиболее заметного ресурса на основании арбитражного решения.