УСОВЕРШЕНСТВОВАННАЯ ПЕРЕДАЧА ПО СЕТИ Российский патент 2011 года по МПК H04H60/90 H04L12/66 H04M11/06 

Предшествующий уровень техники

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

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

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

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

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

Описание чертежей

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

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

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

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

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

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

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

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

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

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

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

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

На фиг.1 изображена блок-схема среды 100 IP-телефонии для предоставления услуг IP-телефонии различным «VoIP-клиентам». Используемый в настоящем документе термин «VoIP-клиент» или «клиент» относится к определенной контактной точке, такой как человек, организация, прикладные программы («автоматическая программа (ВОТ)»), устройство, агент, компания и т.д., одному или нескольким связанным VoIP-устройствам и уникальному идентификатору VoIP-клиента. Например, один человек, пять связанных VoIP-устройств и уникальный идентификатор VoIP-клиента могут совместно определить состав VoIP-клиента. Подобным образом компания, включающая в себя пятьсот человек и более тысячи связанных VoIP-устройств, также может быть названа VoIP-клиентом, и этот VoIP-клиент может быть идентифицирован с помощью уникального идентификатора VoIP-клиента. Кроме того, VoIP-устройства могут быть связаны с множеством VoIP-клиентов. Например, компьютер (VoIP-устройство), расположенный на месте жительства, где проживают три разных человека и каждый человек связан с отдельными VoIP-клиентами, может быть связан с каждым из этих трех VoIP-клиентов. Независимо от комбинации устройств уникальный идентификатор VoIP-клиента может быть использован в системе передачи речевых сигналов для достижения контактной точки VoIP-клиента.

В целом описываемая среда 100 IP-телефонии может включать в себя IP-сеть 108 передачи данных, такую как сеть Интернет, внутренняя сеть, глобальная сеть (WAN), локальная сеть (LAN) и т.п. Среда 100 IP-телефонии также может включать в себя поставщиков 126, 132 VoIP-услуг, предоставляющих VoIP-клиентам 124, 125, 134 VoIP или другие услуги обмена данными. Сеанс речевого вызова VoIP может быть заменен потоком пакетов данных, соответствующих речевой информации, мультимедийной информации и/или контекстуальной информации. Как будет более подробно обсуждаться ниже, контекстуальная информация включает в себя метаданные (информацию об информации), относящиеся к сеансу речевой связи VoIP, к устройствам, используемым в сеансе речевой связи, к контактной точке соединенных VoIP-клиентов и/или к людям, идентифицированным с помощью контактной точки (например, к сотрудникам).

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

Среда 100 IP-телефонии также может включать в себя сторонних поставщиков 140 VoIP-услуг. Поставщики 126, 132, 140 VoIP-услуг могут предоставить различные функции вызова, например фильтрацию входящих вызовов, текстовых данных, интеграцию речевых сигналов и мультимедийных данных, а также интегрированную передачу данных в качестве части сеанса речевого вызова VoIP. VoIP-клиенты 104, 124, 125, 136 могут создавать, сохранять, а также предоставлять информацию, связанную с правилами и установками, относящимися к принимаемым элементам данных, а также раскрывать функциональные возможности, предоставленные устройством клиента. Кроме того, поставщики 126, 132, 140 VoIP-услуг также могут генерировать, сохранять и предоставлять отдельный набор информации метаданных различных установок, которые зависят от человека (людей), с которым(и) было установлено соединение для вызова.

Поставщики 132 VoIP-услуг могут быть соединены с частной сетью, такой как локальная сеть 136 (LAN) компании, предоставляя услуги IP-телефонии (например, внутренние вызовы в пределах частной сети, внешние вызовы за пределы частной сети и т.п.), а также услуги передачи мультимедийных данных нескольким VoIP-клиентам 134 коммуникационно соединенным с локальной сетью 136 (LAN) компании. Подобным образом поставщики VoIP-услуг, такие как поставщик 126 VoIP-услуг, могут быть связаны с поставщиком 122 услуг Интернет (ISP), предоставляя клиентам поставщика 122 услуг Интернет (ISP) услуги IP-телефонии, а также VoIP-услуги.

В одном варианте осуществления один или несколько поставщиков 106, 122 услуг в сети Интернет (ISP) могут быть настроены для предоставления VoIP-клиентам 104, 124, 125 доступа в сеть Интернет, чтобы VoIP-клиенты 104, 124, 125 могли поддерживать каналы сеанса речевой связи, установленные по сети Интернет. VoIP-клиенты 104, 124, 125, соединенные с поставщиком 106, 122 услуг в сети Интернет (ISP), могут использовать проводные и/или беспроводные линии связи. Кроме того, каждый VoIP-клиент 104, 124, 125, 134 может взаимодействовать со старыми традиционными услугами телефонии (POST) 115 через коммутируемую телефонную сеть 112 общего пользования (PSTN) или через частную телефонную сеть 113 (PBX) 113. Интерфейс 114 коммутируемой телефонной сети общего пользования (PSTN), такой как шлюз коммутируемой телефонной сети общего пользования (PSTN), может предоставить доступ между POTS/PSTN и IP-сетью 108 передачи данных. Интерфейс 114 коммутируемой телефонной сети общего пользования (PSTN) может преобразовать пакеты данных VoIP в коммутируемый речевой трафик для коммутируемой телефонной сети общего пользования (PSTN) и наоборот. Коммутируемая телефонная сеть 112 общего пользования (PSTN) может включать в себя устройство 116 наземной линии связи, мобильное устройство 117 и т.п.

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

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

Подразумевается, что вышеупомянутая конфигурация в среде 100 является попросту иллюстративной. Специалистам в данной области техники будет понятно, что частью среды 100 могут являться любые подходящие конфигурации с различными VoIP-объектами. Например, VoIP-клиенты 134, связанные с локальной сетью 136 (LAN), могут иметь возможность взаимодействия с другими VoIP-клиентами 104, 124, 125, 134 с помощью поставщиков 132 VoIP-услуг или с помощью поставщиков 106, 122 услуг в сети Интернет (ISP), а также и без них. Кроме того, поставщик 106, 122 услуг в сети Интернет (ISP) также может предоставить своему клиенту VoIP-услуги.

На фиг.2 изображена блок-схема, иллюстрирующая иллюстративного VoIP-клиента 200, который включает в себя несколько VoIP-устройств и уникальный идентификатор клиента, в соответствии с вариантом осуществления настоящего изобретения. Каждое VoIP-устройство 202, 204, 206 может включать в себя запоминающее устройство, которое используется для сохранения речевых сообщений, адресных книг, определенных клиентом правил, ограничений и установок, относящихся к элементам данных, принимаемым одновременно с входящим или исходящим вызовом, и/или правил для раскрытия имеющихся на устройстве клиента функциональных возможностей, информации о приоритете, связанной с входящими вызовами, и т.д. Альтернативно или в дополнение к этому отдельное запоминающее устройство, поддерживаемое, например, поставщиком услуг, может быть связано с VoIP-клиентом, а также доступно каждому VoIP-устройству, которое содержит информацию, относящуюся к VoIP-клиенту. В варианте осуществления любое подходящее VoIP-устройство, например беспроводной телефон 202, IP-телефон 204 или компьютер 206 с надлежащими прикладными программами VoIP, может являться частью VoIP-клиента 200. VoIP-клиент 200 также поддерживает один или несколько уникальных идентификаторов 208 клиента. Уникальный идентификатор(ы) 208 клиента может быть постоянным или же изменяться со временем. Например, уникальный идентификатор(ы) 208 может изменяться с каждым вызовом. Уникальный идентификатор клиента используется для идентификации клиента, а также для соединения с контактной точкой 210, связанной с VoIP-клиентом. Уникальный идентификатор клиента может поддерживаться каждым VoIP-устройством, включенным в состав VoIP-клиента, и/или поддерживаться поставщиком услуг, который включает в себя ассоциацию с каждым VoIP-устройством, включенным в состав VoIP-клиента. В случае если уникальный идентификатор клиента поддерживается поставщиком услуг, то поставщик услуг может включать в себя информацию о каждом связанном VoIP-устройстве, а также данные о соединяемом устройстве(ах) для входящей связи. В альтернативном варианте осуществления VoIP-клиент 200 может поддерживать множество идентификаторов клиента. В этом варианте осуществления уникальный идентификатор клиента может временно назначаться VoIP-клиенту 200 для каждого сеанса речевого вызова.

Уникальный идентификатор клиента может быть использован подобно номеру телефона в коммутируемой телефонной сети общего пользования (PSTN). Однако вместо набора обычного номера телефона для звонка на определенное устройство коммутируемой телефонной сети общего пользования (PSTN), такое как домашний телефон, уникальный идентификатор клиента используется для достижения контактной точки, например человек или компания, которая связана с VoIP-клиентом. На основе расположения клиента для достижения контактной точки будет соединено соответствующее устройство(а). В одном варианте осуществления каждое VoIP-устройство, включенное в состав VoIP-клиента, также может иметь свой собственный физический адрес в сети или уникальный номер устройства. Например, если человек осуществляет телефонный вызов с клиентом POTS с использованием персонального компьютера (VoIP-устройства), то идентификационный номер VoIP-клиента совместно с IP-адресом персонального компьютера, в конечном счете, будет преобразован в номер телефона, распознаваемый в коммутируемой телефонной сети общего пользования (PSTN).

Фиг.3 изображает блок-схему VoIP-устройства 300, которое может быть связано с одним или несколькими VoIP-клиентами, а также может быть использовано в вариантах осуществления настоящего изобретения. Следует отметить, что VoIP-устройство 300 описывается в качестве примера. Подразумевается, что в вариантах осуществления настоящего изобретения может быть использовано любое подходящее устройство с различными другими компонентами. Для использования VoIP-услуги VoIP-устройство 300 может включать в себя компоненты, подходящие для приема, передачи и обработки различных типов пакетов данных. Например, VoIP-устройство 300 может включать в себя компонент 302 ввода/вывода мультимедийных данных, а также компонент 304 сетевого интерфейса. Компонент 302 ввода/вывода мультимедийных данных может быть выполнен с возможностью ввода и/или вывода мультимедийных данных (включая в себя аудиосигналы, видеосигналы и т.п.), биометрии пользователя, текстовой информации, данных файла прикладной программы и т.д. Компонент 302 ввода/вывода мультимедийных данных может включать в себя любые подходящие пользовательские компоненты ввода/вывода, например микрофон, видеокамеру, устройство отображения, клавиатуру, устройства распознавания биометрии пользователя и т.п. Компонент 302 ввода/вывода мультимедийных данных также может принимать и передавать мультимедийные данные через компонент 304 сетевого интерфейса. Компонент 304 сетевого интерфейса может поддерживать интерфейсы, например интерфейсы Ethernet, интерфейсы ретрансляции кадров, кабельные интерфейсы, интерфейсы DSL, интерфейсы маркерного кольца, радиочастотные интерфейсы (радиоинтерфейсы) и т.п. VoIP-устройство 300 может включать в себя аппаратный компонент 306, включающий в себя стационарное и/или съемное запоминающее устройство, такое как постоянные запоминающие устройства (ROM), оперативные запоминающие устройства (RAM), накопители на жестких дисках, накопители на оптических дисках и т.п. Запоминающее устройство может быть выполнено с возможностью сохранения программных команд для управления работой операционной системы и/или одной или нескольких прикладных программ, а также сохранения контекстуальной информации, относящейся к людям (например, речевые профили), связанных с VoIP-клиентом, в состав которого включено устройство. В одном варианте осуществления аппаратный компонент 306 может включать в себя карту интерфейса VoIP, которая позволяет устройству, не включенному в состав VoIP-клиента, передавать и принимать сеанс речевой связи VoIP.

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

На фиг.4 изображена блок-схема, иллюстрирующая последовательность 400 операций сеанса речевой связи между VoIP-устройствами двух разных VoIP-клиентов по каналу сеанса речевой связи, в соответствии с вариантом осуществления настоящего изобретения. В течение фазы установления соединения VoIP-устройство первого VoIP-клиента 406 запрашивает установление канала сеанса речевой связи со вторым VoIP-клиентом 408. В иллюстративном варианте осуществления поставщик 402 VoIP-услуг (поставщик 1) для первого VoIP-клиента 406 принимает запрос на установление канала сеанса речевой связи и передает запрос поставщику 404 VoIP-услуг (поставщику 2) для второго VoIP-клиента 406. Несмотря на то что этот пример использует двух поставщиков VoIP-услуг и двух VoIP-клиентов, в вариантах осуществления настоящего изобретения может быть использовано любое количество, а также любая комбинация VoIP-клиентов и/или поставщики услуг. Например, для установления соединения может быть использован только один поставщик услуг. В другом примере связь между VoIP-устройствами может быть прямой, с использованием общественных и частных линий связи, следовательно, избавляя от потребности в поставщике VoIP-услуги. В контексте «точка-точка» связь между VoIP-устройствами также может быть прямой, без вовлечения поставщиков услуг.

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

Для простоты объяснения используется пример, в котором и первый VoIP-клиент 406, и второй VoIP-клиент 408 включают в себя одно VoIP-устройство. Соответственно, представленное здесь обсуждение относится к соединению этих двух VoIP-устройств. Человек, использующий устройство первого VoIP-клиента 406, может выбрать или ввести уникальный идентификатор вызываемого клиента. Поставщик 1 402 принимает запрос от устройства первого VoIP-клиента 408 и определяет отказ от поставщика услуг (например, поставщика 2 404 второго VoIP-клиента 408) на основе включенного в запрос уникального идентификатора клиента. Затем запрос переадресовывается поставщику 2 404. Это установление вызова будет переадресовано устройству второго VoIP-клиента. Затем между устройством первого VoIP-клиента 406 и устройством второго VoIP-клиента 408 может быть установлен канал сеанса речевой связи. Как будет подробно описываться ниже со ссылкой на фиг.8А, элементы данных могут быть переданы сразу же после установления канала связи. В результате чего человек может принять элемент данных после приема вызова. Кроме того, устройства клиента могут быть использованы для обмена элементами данных в любой точке после установления канала связи, а также перед разрывом канала связи.

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

Доступные типы мультимедийных данных, правила вызывающего и вызываемого клиентов, а также различные элементы данных могут являться частью контекстуальной информации, которая обменивается в течение фазы установления соединения. Контекстуальная информация может быть обработана и собрана одним из устройств первого VoIP-клиента 406, одним из устройств второго VoIP-клиента 408 и/или поставщиками VoIP-услуг (например, поставщиком 1 402 и поставщиком 2 404) в зависимости от содержания (природы) контекстуальной информации. В одном варианте осуществления поставщики 402, 404 VoIP-услуг могут добавить/или удалить некоторое количество информации в/из контекстуальной информации клиента перед переадресацией контекстуальной информации, выполнить фильтрацию входящей или исходящей контекстуальной информации и т.п.

В ответ на запрос на установление канала сеанса речевой связи второй VoIP-клиент 408 может принять запрос на установление канала сеанса речевой связи или же выполнить другие уместные действия, например отклонить запрос или вызывать контекстуальную информацию, например элемент данных, «буферизованный» поставщиком 2 404. Уместные действия могут быть определены на основе полученной контекстуальной информации. Если канал сеанса речевой связи установлен, то устройство первого VoIP-клиента 406 и устройство второго VoIP-клиента 408 начинают взаимодействовать друг с другом посредством обмена пакетами данных. Как будет более подробно описываться ниже, пакеты данных, включающие в себя пакеты данных сеанса речевой связи, а также пакеты контекстуальных данных обмениваются между соединенными устройствами по установленному каналу сеанса речевой связи.

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

Фиг.5 изображает блок-схему структуры 500 пакета данных, используемого в канале связи (сеанса речевой связи), в соответствии с вариантом осуществления настоящего изобретения. Структура 500 пакета данных может являться структурой пакета данных для пакета данных IP, подходящего для использования для транспортировки данных сеанса речевой связи (например, речевых сигналов, мультимедийных данных и т.п.) или контекстуальных данных (например, информации, относящейся к VoIP-услугам, и т.п.). Однако для транспортировки данных сеанса речевой связи или контекстуальных данных может быть использована любая другая подходящая структура данных. Структура 500 пакета данных включает в себя заголовок 502 и полезную нагрузку 504. Заголовок 502 может содержать информацию, необходимую для доставки вызываемой стороне соответствующего пакета данных. Кроме того, заголовок 502 может включать в себя информацию, используемую в процессе сеанса речевой связи. Такая информация может включать в себя идентификатор 506 (ID) сеанса речевой связи для идентификации сеанса речевой связи (например, вызова), идентификатор 508 (ID) вызываемой стороны, например уникальный идентификатор клиента вызываемого клиента, идентификатор 510 (ID) источника (уникальный идентификатор вызывающего клиента или идентификатор устройства), идентификатор 512 (ID) полезной нагрузки для идентификации типа полезной нагрузки (например, контекстуальной или относящейся к сеансу речевой связи), индивидуальный идентификатор (ID) (не показан) для идентификации человека, к которому относятся данные сеанса речевой связи, и т.п. В альтернативном варианте осуществления заголовок 502, в числе прочего, может содержать информацию, относящуюся к версиям Интернет-протокола, а также к длине полезной нагрузки. Полезная нагрузка 504 может включать в себя данные сеанса речевой связи или контекстуальные данные, относящиеся к идентифицированному сеансу речевой связи. Специалистам в данной области техники будет понятно, что для заголовков верхних уровней, таких как заголовок TCP, заголовок UDP и т.п., могут быть использованы дополнительные заголовки.

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

На фиг.6 изображена блок-схема 600, иллюстрирующая взаимодействие между двумя VoIP-клиентами для передачи контекстуальной информации, в соответствии с вариантом осуществления настоящего изобретения. Как было изображено на фиг.4, описанный в настоящем документе пример использует сценарий, по которому каждый клиент имеет только одно связанное с ним устройство и соединение устанавливается только между этими двумя устройствами. В одном варианте осуществления устройства VoIP-клиента 606 и VoIP-клиента 608 устанавливают канал сеанса речевой связи VoIP. Посредством VoIP-клиента 606 могут быть идентифицированы структурированные иерархии, которые будут использоваться для транспортировки определенной контекстуальной информации. Информация об идентифицированных структурированных иерархиях может включать в себя информацию о структурированных иерархиях, используемых для транспортировки контекстуальной информации, информацию о способе идентификации структурированной иерархии и т.п. Такая информация будет обмениваться между VoIP-клиентом 606 и VoIP-клиентом 608 перед обменом соответствующей контекстуальной информацией. После приема информации о структурированной иерархии, используемой для транспортировки контекстуальной информации, VoIP-клиент 608 выполняет поиск предварительно определенных структурированных иерархий (например, пространство имен XML и т.п.) для выбора идентифицированных структурированных иерархий. В одном варианте осуществления предварительно определенные структурированные иерархии могут быть глобально сохранены в доступном группе VoIP-клиентов централизованном местоположении, а также ими можно управлять оттуда. В этом варианте осуществления адрес универсального идентификатора ресурсов (URI) централизованного местоположения может быть передан от VoIP-клиента 606 VoIP-клиенту 608.

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

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

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

В иллюстративном варианте осуществления сторонний поставщик 601 услуг может принять контекстуальную информацию VoIP-клиентов 606, 608 от поставщиков 602, 604 VoIP-услуг. C целью обсуждения предположим, что с каждым клиентом связано только одно устройство и соединение устанавливается только между этими двумя устройствами. Кроме того, VoIP-клиент 606 имеет поставщика 1 602 для предоставления VoIP-услуг, а также стороннего поставщика 610, доступного для предоставления дополнительных VoIP-услуг. Несмотря на то что этот пример использует двух поставщиков VoIP-услуг и двух VoIP-клиентов, в вариантах осуществления настоящего изобретения может быть использовано любое количество, а также любая комбинация VoIP-клиентов и/или поставщиков услуг. В одном варианте осуществления устройства VoIP-клиента 606 и VoIP-клиента 608 устанавливают канал сеанса речевой связи посредством поставщика 1 602 и поставщика 2 604.

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

В иллюстративном варианте осуществления информация, относящаяся к идентифицированным структурированным иерархиям, также передается поставщику 2 604. Информация, относящаяся к идентифицированным структурированным иерархиям, может включать в себя информацию о структурированных иерархиях, которые будут использоваться для транспортировки контекстуальной информации, о способе идентификации структурированных иерархий и т.п. Поставщик 2 604 передает поставщику 1 602 информацию об идентифицированных структурированных иерархиях, а также контекстуальную информацию. В данном примере поставщик 2 604 является стороной, передающей контекстуальную информацию, а поставщик 1 602 является стороной, принимающей контекстуальную информацию. В случае необходимости поставщик 1 602 может собрать большее количество контекстуальной информации, а также обновить принятую контекстуальную информацию. Кроме того, поставщик 1 602 может добавить, удалить и/или изменить контекстуальные данные перед переадресацией принятой контекстуальной информации VoIP-клиенту 606. Поставщик 1 602 передает контекстуальную информацию VoIP-клиенту 606. Аналогичным образом VoIP-клиент 606 также может собрать контекстуальную информацию, а также передать собранную контекстуальную информацию и соответствующую информацию о структурированных иерархиях VoIP-клиенту 608 посредством поставщика 1 602 и поставщика 2 604.

Как будет более подробно обсуждаться ниже, нужно подразумевать, что VoIP-объект приблизительно одновременно может являться как передающей стороной, так и принимающей стороной. Например, поставщик 1 602 также может принять первый набор контекстуальной информации от VoIP-клиента 606 в течение приема второго набора контекстуальной информации, относящейся к VoIP-клиенту 608, от поставщика 2 604. После приема контекстуальной информации поставщик 1 602 передает первый набор контекстуальной информации поставщику 2 604 в течение приема второго набора контекстуальной информации от поставщика 2 604. Аналогичным образом VoIP-клиенты 606, 608 могут принять контекстуальную информацию от своих поставщиков услуг в течение передачи контекстуальной информации своим поставщикам услуг. По существу, рассматривается, что контекстуальная информация будет непрерывно обмениваться между VoIP-объектами (например, поставщиком 1 602, VoIP-клиентом 606, поставщиком 2 604, VoIP-клиентом 608) перед, в течение, а также после сеанса речевой связи по двухстороннему каналу связи.

В одном варианте осуществления поставщик 1 602 передает VoIP-клиенту 606 информацию, относящуюся к идентифицированным структурированным иерархиям, а также контекстуальную информацию. Как было упомянуто выше, VoIP-клиент 606 дополнительно обрабатывает принятую контекстуальную информацию в соответствии с идентифицированными структурированными иерархиями. Например, после приема информации, относящейся к идентифицированным структурированным иерархиям, VoIP-клиент 606 выполняет поиск предварительно определенных структурированных иерархий для выбора идентифицированных структурированных иерархий для контекстуальной информации.

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

В конкретном варианте осуществления VoIP-клиент 606 может идентифицировать пространство имен XML для контекстуальной информации. Например, атрибут пространства имен XML может быть установлен в начальный тег передаваемого элемента. Должно быть понятно, что пространства имен XML, атрибуты, а также иллюстрированные в настоящем документе классы предоставлены исключительно в качестве примера структурированных иерархий, используемых в соединении с различными вариантами осуществления настоящего изобретения. После приема VoIP-клиентом 608 информации о пространстве имен XML VoIP-клиент 606 передает VoIP-клиенту 608 набор пакетов контекстуальных данных, определенных в соответствии с идентифицированным пространством имен XML. Если в начальном теге элемента определено пространство имен, то все подчиненные элементы с аналогичным префиксом связываются с тем же самым пространством имен. По существу, VoIP-клиент 608 и VoIP-клиент 606 могут передать контекстуальную информацию без включения префиксов во все подчиненные элементы, следовательно, сокращая количество пакетов данных передаваемых для контекстуальной информации.

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

Далее со ссылкой на фиг.8А будет описана иллюстративная программа 800 обработки команд. В целом описываемая программа 800 обработки команд реализует логику, которая предоставляет передающему клиенту возможность передачи принимающему клиенту выбранного элемента данных. В качестве основного объекта программа 800 может быть реализована в прикладной программе, которая предоставляет функциональные возможности для приема и передачи вызовов в VоIP-среде или иным способом упрощает обмен данными сеанса речевой связи. Например, перед выполнением программы 800 обработки команд вызывающий абонент может использовать прикладную программу и/или VoIP-устройства для установления канала связи с одной или несколькими принимающими сторонами.

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

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

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

Как иллюстрировано на фиг.8A, выполнение программы 800 обработки команд начинается на этапе 802, а на этапе 804 устанавливается контекстуальная информация, обмениваемая между клиентами, задействованными в сеансе речевого вызова. В одном варианте осуществления, а также как было описано выше, контекстуальная информация может быть обменена в качестве структурированных иерархий, которые были определены в соответствии с пространством имен XML. Кроме того, контекстуальная информация обменивается таким способом не только в течение начальной фазы установления (на этапе 802), но также контекстуальная информация может быть обменена и после начальной фазы установления в течение сеанса вызова или же после завершения вызова. Несмотря на то что иллюстративный вариант осуществления описан применительно к программе 800 обработки команд, сфокусированной на взаимодействии, происходящем между двумя клиентами, программа 800 также применима к случаям присутствия более двух клиентов или других VoIP-объектов, участвующих в вызове (например, в групповом вызове).

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

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

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

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

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

В одном варианте осуществления в течение вызова могут быть переданы пакетированные элементы данных графических представлений и/или анимаций. Например, при использовании обеспеченных посредством настоящего изобретения средств управления передающая сторона может выбрать графическое представление и/или анимации из пакета элементов данных, который включает в себя, в числе прочего, улыбки, хмурые взгляды, подмигивания или другое выражение лица, отображающее эмоцию человека. При этом контекстуальная информация, обмениваемая на фазе установления вызова (на этапе 804), может идентифицировать пакеты элементов данных, имеющиеся на передающем и принимающем клиентах. В одном варианте осуществления выполняемая на этапе 808 обработка включает в себя идентификацию пакетов элементов данных, локально доступных на принимающем клиенте. Если определенный элемент данных является локально доступным на принимающем клиенте, то элемент фактических данных не передается в ответ на прием соответствующей команды. Вместо этого передается ссылка на элемент данных, предоставляющая принимающему клиенту возможность повторного вызова и представления элемента данных. В одном варианте осуществления графические представления и/или анимации эмоций человека, относящиеся к контексту сеанса речевой связи, предоставляются посредством класса 904 основы вызова, описанного более подробно со ссылкой на фиг.10.

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

На этапе 810 выполняется определение того, можно ли локально получить доступ к принятому на этапе 806 элементу данных, который является объектом команды, с принимающего клиента. В некоторых случаях элемент данных либо локально недоступен на принимающем клиенте, либо может быть доступен исключительно передающему клиенту. Например, в одном варианте осуществления при вызове для обеспечения «музыкального фона» передающая сторона может выдать команду на мультиплексирование аудиофайла. Передающая сторона идентифицирует аудиофайл, а также выбирает средство управления для передачи аудиофайла и данных вызова в форме отдельного мультиплексного потока. В этом и других случаях, если элемент данных доступен только передающему клиенту, результатом проверки, выполняемой на этапе 810, будет «НЕТ» и выполнение программы 800 обработки команд перейдет на описанный ниже этап 814. И наоборот, элемент данных может быть локально доступным принимающему клиенту. Например, графические представления и/или анимации, которые изображают эмоции человека, или же другие пакетированные элементы данных и связанные процедуры, могут быть распределены множеству клиентов. В этом случае если пакет, который включает в себя выбранный элемент данных, был распределен принимающему клиенту, то выполняется определение того, что элемент данных является локально доступным. В этом и других случаях если выбранный элемент данных локально доступен принимающему клиенту, то результатом проверки, выполняемой на этапе 810, будет «ДА» и выполнение программы 800 обработки команд переходит на этап 812.

На этапе 812 признак, описывающий элемент данных, который будет доступен принимающей стороне, вставляется в поток данных, передаваемый принимающему клиенту. По достижении этапа 812 выполняется определение того, что элемент данных, выбранный передающей стороной, является локально доступным принимающему клиенту. В этом случае выбранный элемент данных передан не будет. Вместо этого между передающим и принимающим клиентами в качестве контекстуальной информации передается «признак» или сегмент текста, описывающий выбранный элемент данных и связанные процедуры. Специалисты в данной области техники должны понимать, что признак, который соответствует XML или другому стандартизированному формату, может быть использован для описания семантики идентификации и представления элемента данных на принимающем клиенте. Например, признак, вставленный на этапе 812 в поток данных, может включать в себя адреса назначения и передающих клиентов, команды обработки, идентичность выбранного элемента данных и т.п. Как будет более подробно описано ниже, после приема признака, вставленного в поток данных, для представления элемента данных принимающей стороне могут быть выполнены определенные команды. После чего выполнение программы 800 обработки команд переходит на этап 816, на котором оно завершается.

На этапе 814 программа 800 обработки команд передает элемент фактических данных, включаемый в передаваемый принимающему клиенту поток данных. Другими словами, пакеты данных с соответствующей информацией заголовка и элементом данных, представленным в полезной нагрузке, передаются принимающему клиенту по достижении этапа 814. В одном варианте осуществления контекстуальная информация в виде электронных документов (например, документы обработки текста, электронные таблицы, представления PowerPoint и т.п.), графические представления и/или анимации (картинки, изображения, пиктограммы и т.д.) вызовы процедуры и/или любой другой тип данных, который может быть представлен в цифровой форме и т.д., могут быть переданы в потоке данных. В другом варианте осуществления контекстуальная информация является постоянно вставленной или мультиплексированной с передаваемым потоком данных. Например, как было упомянуто выше, при вызове для обеспечения «музыкального фона» передающая сторона может выдать команду на мультиплексирование аудиофайла. В этом случае идентифицированный передающей стороной аудиофайл является постоянно мультиплексированным с данными сеанса речевой связи, которые передаются принимающему клиенту. Затем выполнение программы 800 обработки команд переходит на этап 816, на котором оно завершается.

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

Как иллюстрировано на фиг.8B, выполнение программы 850 обработки начинается на этапе 852, а на этапе 854 выполняется ожидание приема запроса на представление элемента данных от передающего клиента. Как было описано со ссылкой на фиг.8А выше, аспекты настоящего изобретения предоставляют средства управления для генерирования команды, принимаемой автоматически или на основе ввода с пользовательского интерфейса, для представления или создания доступности элемента данных на принимающей стороне иным образом. Программа 800 обработки команд может вставлять в передаваемый принимающему клиенту поток данных элемент опорных или фактических данных. После приема потока данных контекстуальная информация потока данных разбирается для определения того, был ли принят запрос на представление элемента данных. Например, команды на представление элемента данных могут быть вставлены в поток данных в признаке XML. После приема этого типа информации программа 800 обработки команд определяет, что команды на представление элемента данных были приняты, после чего выполняется переход на этап 856.

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

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

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

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

На этапе 858 определения программа 850 обработки на основе ограничений, если таковые вообще имеются, идентифицированных на этапе 856, определяет, будет ли выполняться дополнительная обработка. Как было упомянуто выше, ограничения могут быть установлены в тех случаях, когда идентифицирована вредоносная программа, установлена политика или правило и т.д. В этих случаях если представление элемента данных запрещено, то выполняется определение того, что результатом проверки, выполненной на этапе 858, является «НЕТ» и выполнение программы 850 обработки переходит на этап 868, на котором оно завершается. В случаях если ограничения, запрещающего выполнение связанных с элементом данных, не существует, то выполнение программы 850 обработки переходит на этап 860.

На этапе 860 выполняется поиск структуры данных для идентификации установок для доступности элемента данных для принимающей стороны. В одном варианте осуществления установки могут быть заданы принимающей стороной или же быть заданы «по умолчанию», они определяют способ представления различных типов элементов данных или иную доступность. При этом если принятый элемент данных придерживается конкретного типа файла (например, «.doc»), то могут быть заданы установки, которые запускают конкретную прикладную программу (например, Microsoft Word®), вследствие чего принимающая сторона может незамедлительно получить доступ к элементу данных. Кроме того, установки, которые зависят от переменных, могут затрагивать элементы данных, предоставляемые принимающей стороне. При этом принимающая сторона может установить правило для связи и воспроизведения аудиофайла, когда конкретный человек устанавливает вызов. Независимо от элемента данных, принятого в этом случае от передающей стороны, заданные принимающей стороной установки могут быть откорректированы тем, какой аудиофайл должен быть воспроизведен при установленном вызове. Однако специалистам в данной области техники должно быть понятно, что могут быть заданы и другие установки, которые зависят от любого количества различных типов переменных.

Как иллюстрировано на фиг.8B, на этапе 862 выполняется определение того, доступен ли конкретный элемент данных локально на принимающем клиенте. Если этап 862 достигнут, то ограничение, предназначенное для запрета представления элемента данных принимающей стороне, не было идентифицировано. В этом случае программа 850 обработки разрешает выполнение команд для обработки запроса, принятого на этапе 854. Однако, как было описано выше, элемент данных может являться локально доступным принимающему клиенту, или же фактический элемент данных может быть вставлен в поток данных. В альтернативном варианте осуществления элемент данных может являться доступным открытому для доступа в сети хранилищу данных. В любом случае признак XML может быть принят в случаях, когда элемент данных является локально доступным принимающему клиенту. Это может произойти, например, если элемент данных включен состав в пакета элементов данных, доступного как передающему, так и принимающему клиентам. В этом случае выполняется определение того, что элемент данных является локально доступным, а также выполнение программы 850 обработки переходит на этап 864. Альтернативно, если элемент фактических данных включен в состав потока данных, то выполняется определение того, что элемент данных является локально недоступным, и выполнение программы обработки переходит на этап 866.

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

На этапе 866, если элемент данных представлен или иначе доступен принимающему клиенту, сгенерированная передающей стороной команда удовлетворяется. Представление элемента данных может включать в себя применение установок, заданных принимающей стороной или заданных «по умолчанию». Например, как было упомянуто выше, представление элемента данных может включать в себя идентификацию соответствующей прикладной программы, запуск прикладной программы, а также использование прикладной программы для отображения элемента данных. Подобным образом, если принимающая сторона взаимодействует в настоящее время с соответствующей прикладной программой, то представление элемента данных может включать в себя «обновление» графического пользовательского интерфейса, при этом отображая элемент данных. Кроме того, представление элемента данных может включать в себя выдачу вызова процедуры для программного интерфейса, доступного принимающему клиенту. Например, функции могут быть выданы для побуждения устройства клиента к вибрированию, воспроизведению идентифицированного аудиофайла, отображению изображения и т.д. Затем выполнение программы 850 обработки переходит на этап 868, на котором оно завершается.

На фиг.9-12 изображены блок-схемы, иллюстрирующие различные классы и признаки структурированных иерархий, соответствующих контекстуальной информации VoIP. Как было упомянуто выше, структурированные иерархии являются предварительно определенными организационными структурами для упорядочивания контекстуальной информации, обмениваемой между двумя и более VoIP-устройствами. Структурированные иерархии могут быть определены, обновлены и/или изменены с помощью повторного определения различных классов и признаков. Обмениваемая между различными VoIP-объектами контекстуальная информация VoIP может соответствовать пространству 900 имен VoIP. В одном варианте осуществления пространство 900 имен VoIP представлено в качестве иерархически структурированного дерева узлов, где каждый узел соответствует подклассу, соответствующему подмножеству контекстуальной информации VoIP. Например, пространство 900 имен VoIP может быть определено в качестве иерархически структурированного дерева, содержащего класс 902 основы вызова, класс 910 контекста вызова, класс 920 типа устройства, класс 930 VoIP-клиента и т.п.

На фиг.10 изображена блок-схема класса 902 основы вызова. В иллюстративном варианте осуществления класс 902 основы вызова может соответствовать подмножеству контекстуальной информации VoIP, относящейся к соединению по каналу сеанса речевой связи (например, соединение для вызова PSTN, соединение для вызова VoIP и т.п.). Подмножество контекстуальной информации VoIP, относящейся к соединению по каналу сеанса речевой связи, может включать в себя инициирующие номера (например, идентификационный номер клиента вызывающей стороны), номера вызываемой стороны (например, идентификационные номера клиента или номера телефона вызываемой стороны), время соединения для вызова, информацию о поставщике VoIP-услуг и/или информацию о поставщике услуг в сети Интернет (ISP), например IP-адрес, МАС-адрес, информацию о пространства имен и т.п. Кроме того, контекстуальная информация, относящаяся к соединению по каналу сеанса речевой связи, может включать в себя информацию о приоритете вызова (которая определяет уровни приоритета номеров вызываемой стороны), информацию о типе вызова, правила для приема/передачи элементов данных и т.п. Информация о типе вызова может указать на то, был ли установлен канал сеанса речевой связи экстренной связи, широковещательной связи, связи компьютер-компьютер, связи компьютер-устройство POTS и т.д. В одном варианте осуществления контекстуальная информация, относящаяся к каналу сеанса речевой связи, может включать в себя предварительно определенные идентификаторы, которые представляют собой эмоции, звуки (например, «ах», «ой», «ничего себе» и т.д.), а также графические представления и/или анимации выражений лица. В одном варианте осуществления класс 902 основы вызова может быть определен в качестве структуры поддерева пространства 900 имен VoIP, которое включает в себя узлы, такие как приоритет 903 вызова, информация 904 о пространстве имен, тип 905 вызова, номер 906 вызываемой стороны, поставщик 907 услуг, предварительно определенные идентификаторы 908 и т.п.

На фиг.11 изображена блок-схема класса 910 контекста вызова. В одном варианте осуществления подмножество контекстуальной информации VoIP, относящейся к контексту сеанса речевой связи, может соответствовать классу 910 контекста вызова. Контекстуальная информация, относящаяся к контексту сеанса, может включать в себя информацию, такую как ключевые слова, поставляемые клиентом, поставщиком услуг, сетью и т.д. Контекстуальная информация, относящаяся к контексту сеанса речевой связи, также, среди прочего, может включать в себя идентифицированные ключевые слова из данных файла документа, идентифицированные ключевые слова из пакета данных сеанса речевой связи (например, ключевые слова сеанса речевой связи), имена файлов для документов и/или мультимедийных файлов, обмениваемых в качестве части сеанса речевой связи, информацию, относящуюся к играм (например, тип игры, виртуальная пространственная близость в определенной игре), частоту использования (включая частоту и длительность вызовов, относящихся к определенному файлу, к определенному субъекту, а также к определенному клиенту) и идентификацию файла (например, номер дела, номер темы и т.п., относящийся к сеансу речевой связи. В соответствии с иллюстративным вариантом осуществления класс 910 контекста вызова может быть определен в качестве структуры поддерева пространства 900 имен VoIP, которое включает в себя узлы, соответствующие идентификации 912 файла, поставляемому ключевому слову 913, ключевому слову 914 сеанса речевой связи, частоте 915 использования, предмету 916 сеанса речевой связи и т.п.

На фиг.12 изображена блок-схема класса 920 типа устройства. В одном варианте осуществления класс 920 типа устройства может соответствовать подмножеству контекстуальной информации VoIP, относящейся к устройству VoIP-клиента, используемому для соединения по каналу сеанса речевой связи. Подмножество контекстуальной информации VoIP, относящейся к устройству VoIP-клиента, может включать в себя связанную информацию, относящуюся к звуку, которая может быть необходима для обработки аудиоданных, сгенерированных устройством VoIP-клиента. Относящаяся к звуку информация может включать в себя информацию, связанную со звуковыми функциональными возможностями устройства, а также с функциональной возможностью, такой как частота дискретизации, машинный тип, тип ввода/вывода, микрофон, информацию, относящуюся к карте цифровой обработки сигналов (DSP) или к функциональной возможности представления элементов данных и т.п. Подмножество контекстуальной информации VoIP, относящейся к устройству VoIP-клиента, может включать в себя информацию, относящуюся к видео, которая может быть необходима для обработки видеоданных, сгенерированных устройством VoIP-клиента. Информация, относящаяся к видео, может включать в себя информацию о разрешении, обновлении, типе и размере видеоданных, информацию о графической карте и т.п. Контекстуальная информация, относящаяся к устройствам VoIP-клиента, также может включать в себя определенную информацию о другом устройстве, такую как тип компьютерной системы, информацию о процессоре, сетевой пропускной способности, беспроводной/проводной связи, мобильности компьютерной системы, параметрах настройки компьютерной системы и т.п. В иллюстративном варианте осуществления класс 920 типа устройства может быть определен в качестве структуры поддерева пространства 900 имен VoIP, которая включает в себя узлы, соответствующие звуку 922, видео 924, специфике 926 устройства и т.п.

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

Кроме того, подмножество контекстуальной информации VoIP, относящейся к VoIP-клиенту, может включать в себя информацию о местоположении (включающую в себя определенное местоположение клиента, определенное местоположение VoIP, местоположение GPS/триангуляции, а также логическое/фактическое местоположение индивидуального пользователя), присвоенный телефонный номер, пользовательская контактная информация (например, имя, адрес, компания и т.п.), правила, установленные клиентом, поставщиком услуг, сетью и т.д., пользовательские правила и установки, управление цифровыми правами (DRM), ранг участника индивидуального пользователя в организации, приоритет, связанный с рангом участника, и т.п. Приоритет, связанный с рангом участника, может быть использован для присваивания приоритета клиенту для группового вызова. В одном варианте осуществления класс 930 VoIP-клиента может быть определен в качестве структуры поддерева пространства 900 имен VoIP, которая включает в себя узлы, соответствующие биометрии 931 пользователя, местоположению 932, правилам 933, идентификации 934 пользователя, приоритету 935 участника, установкам 936 клиента и т.п.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14. Машиночитаемый носитель по п.13, в котором ограничения могут быть установлены привилегированным пользователем.

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

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

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

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

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

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