добыча данных для услуг

Формула изобретения

1. Способ добычи данных из пакетов [500] данных из оцифрованного речевого разговора, содержащий:

выбор профиля [1315] добычи данных для использования в пакетах добычи данных из оцифрованного речевого разговора;

определение, во время оцифрованного речевого разговора, предназначен ли пакет данных оцифрованного речевого разговора дальнейшей для добычи данных [1305]; и

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

2. Способ по п.1, дополнительно содержащий:

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

3. Способ по п.1, дополнительно содержащий:

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

4. Способ по п.1, дополнительно содержащий:

определение правил добычи данных [1317]; и

модификацию профиля добычи данных [1319] на основе правил добычи данных.

5. Способ по п.1, дополнительно содержащий:

сохранение пакета данных с профилем добычи данных [1331] для пост-обработки.

6. Способ по п.5, дополнительно содержащий:

идентификацию правил [1325] пост-обработки; и

сохранение правил пост-обработки с профилем добычи данных и пакета данных для пост-обработки [1331].

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

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

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

10. Читаемая компьютером среда, имеющая исполняемые компьютером компоненты для обработки добытых данных, содержащая:

компонент [1300] управления добытыми пакетами данных, идентифицирующий, во время оцифрованного речевого разговора, пакеты данных, релевантные для профиля добычи данных;

компонент [1405] изменения добытых пакетов данных, определяющий, должны ли быть изменены добытые пакеты данных; и

компонент [1409] обработки добытых пакетов данных, выполняющий обработку пакетов данных, релевантных для профиля добычи данных.

11. Читаемая компьютером среда по п.10, в которой компонент изменения добытых пакетов данных изменяет контент пакетов данных на основе правил [1407], применяемых к профилю добычи данных.

12. Читаемая компьютером среда по п.11, в которой правила применяются провайдером [132] услуг.

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

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

15. Читаемая компьютером среда по п.10, в которой обработка добытого пакета данных происходит в реальном масштабе времени.

16. Читаемая компьютером среда по п.10, дополнительно содержащая:

компонент пост-обработки [1331] для сохранения добытых пакетов данных с правилами пост-обработки.

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

обработку пакета данных [1300] разговора, во время оцифрованного речевого разговора, для идентификации контента, релевантного для профиля добычи данных;

получение информации [1409], относящейся к идентифицированному контенту; и

предоставление информации, относящейся к идентифицированному контенту.

18. Способ по п.17, в котором обработка выполняется третьей стороной.

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

20. Способ по п.17, в котором пакет данных идентифицируется для обработки, исходя из заголовка этого пакета данных.

Описание изобретения к патенту

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

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

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

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

Это краткое описание предоставлено с целью введения в упрощенной форме ряда концептов, которые описаны ниже в разделе ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ . Это краткое описание не предназначено для определения ключевых признаков заявленного объекта изобретения и при этом это не предназначено для использования с целью определения объема заявленного объекта изобретения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На фиг.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 телефонного разговора может происходить обмен данными в виде потока пакетов данных, соответствующих речевой информации, медиаинформации и/или контекстной информации. Как более подробно описано ниже, данные могут быть добыты из разговора клиентом, клиентским устройством, провайдером услуг, третьей стороной, предоставляющей услуги, или их комбинацией. В одном из вариантов осуществления для каждого клиента в разговоре и/или для третьих сторон (например, провайдеров услуг) может быть определен один или несколько профилей добычи данных . Профиль добычи данных определяет типы данных/контент, который представляет интерес для клиента и/или третьей стороны и который должен быть выполнен после идентификации данных/контента. Например, клиент может создать профиль добычи данных, который указывает, что он интересуется обувью. Такой речевой профиль может быть использован для обработки разговора и добычи информации из пакетов данных, которые включают в себя дискуссии относительно обуви. Затем добытые пакеты данных могут быть дополнительно обработаны для определения того, что разговор относится к обуви фирмы Nike®, и может быть получена и представлена дополнительная информация относительно обуви фирмы Nike®.

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

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

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

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

Следует учесть, что вышеописанная конфигурация в среде 100 является только иллюстративной. Специалисту в данной области техники очевидно, что любое количество и комбинации подходящих конфигураций с различными VoIP объектами могут быть частью среды 100. Например, VoIP клиенты 134, соединенные с LAN 136, могут иметь возможность для установления коммуникации с другими VoIP клиентами 104, 124, 125, 134 при помощи провайдеров 132 VoIP услуг или ISP 106, 122, или без них. Более того, ISP 106, 122 также могут оказывать 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 может изменяться при каждом звонке. Уникальный VoIP идентификатор используется для идентификации клиента и для соединения с ответствующей контактной точкой 210, ассоциированной с этим VoIP клиентом. Уникальный VoIP идентификатор может поддерживаться каждым VoIP устройством, входящим в состав VoIP клиента, и/или поддерживаться провайдером услуг, который включает в себя ассоциацию с каждым VoIP устройством, входящим в состав VoIP клиента. В данном примере, в котором уникальный VoIP идентификатор поддерживается провайдером услуг, провайдер услуг может включать в себя информацию о каждом ассоциированном VoIP устройстве и знание о том, как с таким устройством(устройствами) соединиться для входящей коммуникации. В альтернативном варианте осуществления VoIP клиент 200 может поддержать множество VoIP идентификаторов. В этом варианте осуществления для каждой телефонной сессии уникальный VoIP идентификатор может временно назначаться для VoIP клиента 200.

Уникальный VoIP идентификатор может использоваться аналогично номеру телефона в PSTN. Однако вместо набора обычного номера телефона для осуществления звонка, используя определенное PSTN устройство, такое как домашний телефон, для достижения контактной точки, такой как человек или компания, ассоциированная с VoIP клиентом, используется уникальный 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 интерфейсы, интерфейсы маркерного кольца (TokenRing), радиочастотные (воздушные интерфейсы) и т.п. VoIP устройство 300 может включать в себя компонент 306 аппаратных средств, включая постоянную и/или сменную память, такую как постоянное запоминающее устройство (ROM), оперативная память (RAM), драйвера жестких дисков, драйвера оптических дисков и т.п. Память может быть выполнена с возможностью хранения программных инструкций для управления работой операционной системы и/или одного или нескольких приложений и для хранения контекстной информации, относящейся к людям (например, профили добычи данных), ассоциированным с VoIP клиентом, в котором содержится данное устройство. В одном из вариантов осуществления компонент 306 аппаратных средств может включать в себя карту VoIP интерфейса, которая позволяет не-VoIP устройству передавать и принимать VoIP разговор.

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

На фиг.4А показана блок-схема, иллюстрирующая последовательность 400 операций установки соединения при разговоре между VoIP устройствами двух различных VoIP клиентов по каналу разговора согласно варианту осуществления настоящего изобретения. Хотя пример, приведенный в настоящем описании, относится к коммуникации между двумя 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 услуг. Например, если для протокола сигнализации выбран Протокол Инициирования Сессии (SIP), то управляющая сессией информация и сообщения будут обмениваться по SIP пути/каналу сигнализации, а медиапотоки будут обмениваться по пути/каналу по транспортному протоколу реального времени (RTP). С целью обсуждения коммуникационный канал, как используется в настоящем описании, как правило, относится к любому типу пути/канала обмена данными или сигналами. Таким образом, очевидно, что в зависимости от протокола на этапах установки соединения и завершения соединения могут потребоваться дополнительные этапы в блок-схеме последовательности 400 операций установки соединения при разговоре.

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

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

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

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

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

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

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

Перед началом обмена речевыми пакетами данных между устройством первого VoIP клиента 406 и устройством второго VoIP клиента 408 первый VoIP клиент 406 и второй VoIP клиент 408 могут обменяться контекстной информацией. Обмен контекстной информацией может происходить с использованием структурированной организации, определенной первым VoIP клиентом 406. В одном из вариантов осуществления Провайдер 1 402 может идентифицировать конкретную контекстную информацию, которую должен получить Провайдер 1 402 от первого VoIP клиента 406. Первый VoIP клиент 406 может установить соответствующую структуру на основе контента контекстной информации. Идентификация структуры для обмена информацией и дополнительной контекстной информацией может быть передана второму VoIP клиенту 408 через Провайдер 2 404 и Провайдер 1 402.

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

В ответ на требование инициировать канал разговора второй VoIP клиент 408 может принять требование или отклонить требование на установку канала разговора через Провайдера 2 404. Когда канал разговора установлен, устройства первого VoIP клиента 406 и второго VoIP клиента 408 начинают осуществлять коммуникацию друг с другом путем обмена пакетами данных, как обсуждалось выше. В одном из вариантов осуществления пакеты контекстных данных и/или данных разговора могут быть направлены провайдеру 410, 412 услуг, третьей стороне, от Провайдера 1 402, Провайдера 2 404, или от любого VoIP клиента 406, 408. Более того, направленные пакеты контекстных данных и/или данных разговора могут обмениваться между другими провайдерами 410, 412 услуг, третьей стороной. Любой из VoIP клиентов 406, 408, провайдеров 410, 412 услуг или провайдеров 410, 412 услуг, являющихся третьей стороной, может добывать пакеты контекстных данных и/или данных разговора на основе выбранных профилей добычи данных.

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

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

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

На фиг.6 показана блок-схема 600, иллюстрирующая взаимодействие между двумя VoIP клиентами для передачи контекстной информации, согласно варианту осуществления настоящего изобретения. Как и на фиг.4А и 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 клиент 606 в требовании на соединение с VoIP клиентом 608 может выбрать профиль добычи данных, который предназначен для использования во время разговора. Например, если VoIP клиент 608 является другом, то VoIP клиент 606 может выбрать профиль добычи данных, который создан для добычи данных, относящихся к пунктам, которые представляют собой общий интерес обоих друзей. В требовании на соединение и во время установки канала разговора VoIP клиент 606, через Провайдера 1 602 и Провайдера 2 604, может предоставить VoIP клиенту 608 выбранный профиль добычи данных. В качестве альтернативы, если клиенты заранее выбрали профили добычи данных, то VoIP клиент 606 может просто идентифицировать выбранный профиль добычи данных путем отправки идентификатора профиля добычи данных. Аналогично VoIP клиент 608 во время установки звонка или в любой момент во время звонка может предоставить профиль добычи данных (или его идентификатор) Провайдерам 604, 602 и VoIP клиенту 606 профиля добычи данных, выбранного VoIP клиентом 608 для добычи данных во время разговора.

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

При установлении канала разговора во время разговора VoIP клиенты 606, 608 и/или Провайдеры 602, 604 могут добывать обмениваемые пакеты данных разговора и контекстных данных для контента, релевантного профилям добычи данных. Например, если один из профилей добычи данных определяет, что добыче данных должны подвергнуться разговоры, относящиеся к гольфу , в которых человек, использующий VoIP клиента 608, говорит о том, что они собираются в это воскресенье играть в гольф на Pebble Beach в 1:00 дня и что человек, использующий VoIP клиента 606, приглашается, чтобы присоединиться к ним, то данные пакетов из такого оцифрованного речевого разговора могут быть добыты и далее обработаны. Например, устройство, которое производит добычу данных из пакета (пакетов) данных согласно профилю добычи данных может получить информацию о погоде в Pebble Beach, Калифорния, в 1:00 дня и предоставить эту информацию одному или нескольким VoIP клиентам во время разговора. Аналогично может быть определен другой профиль добычи данных для идентификации пунктов календаря. Такой же пакет (пакеты) данных, относящихся к требованию относительно игры в гольф в воскресенье в 1:00 дня, может быть добыт, и может быть активирована календарная программа. Затем VoIP клиенты могут получить требование на повестку дня относительно гольфа в воскресенье в 1:00 дня в Pebble Beach, таким образом, получая возможность для приема, модификации или отклонения требования и размещения его в своих календарях.

Дополнительно к добыче данных из пакетов данных разговора VoIP клиентами 606 и 608 и/или Провайдерами 602, 604 один или оба клиента могут потребовать или согласовать возможность добычи данных из пакетов данных из разговора Провайдером, третьей стороной, (не показано). Например, если один из клиентов согласился предоставить возможность магазину товаров для гольфа добывать пакеты данных из разговоров, такой же пример пакета(пакетов) данных может быть добыт третьей стороной, и в ответ клиентам может быть предоставлена реклама одежды или оборудования для игры в гольф во время или после звонка. Благодаря возможности собирать специфические участки разговора может быть предоставлена персонализированная реклама. Например, магазин товаров для гольфа также может произвести поиск погоды в воскресенье в 1:00 дня в Pebble Beach, Калифорния, и определить вероятность дождя в это время. В результате предоставляемая клиентам реклама может включать в себя информацию для одежды для дождя.

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

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

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

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

На фиг.8-12B показаны блок-схемы, иллюстрирующие различные классы и атрибуты структурированных иерархий, соответствующих VoIP контекстной информации. Как упоминалось выше, структурированные иерархии определяют организационные структуры для размещения контекстной информации с целью обмена между двумя и большим количеством устройств. Структурированные иерархии могут определяться, обновляться и/или модифицироваться путем переопределения различных классов и атрибутов. VoIP контекстная информация, обмениваемая между различными VoIP объектами (например, клиентами, провайдерами услуг и т.д.), может соответствовать VoIP пространству 800 имен. В одном из вариантов осуществления VoIP пространство 800 имен представлено в виде иерархически структурированного дерева узлов, причем каждый узел соответствует подклассу, который соответствует поднабору VoIP контекстной информации. Например, VoIP Пространство 800 имен может быть определено в виде иерархически структурированного дерева, включающего в себя Класс 802 Основы Звонка, Класс 810 Контексты Звонка, Класс 820 Тип Устройства, Класс 830 VoIP Клиент и т.п.

На фиг.9 показана блок-схема Класса 802 Основы Звонка. В иллюстративном варианте осуществления Класс 802 Основы звонка может соответствовать поднабору VoIP контекстной информации, относящейся к соединению канала разговора (например, соединению PSTN звонка, соединению VoIP звонка и т.п.). Поднабор VoIP контекстной информации, относящийся к соединению канала разговора, может включать в себя исходные номера (например, номер ID звонящего клиента), номера адресата (например, номер ID вызываемого клиента или телефонные номера), время соединения звонка, информацию, относящуюся к провайдеру VoIP услуг, и/или информацию, относящуюся к провайдеру ISP, такую как IP адрес, МАС адрес, информацию о пространстве имен и т.п. Кроме того, контекстная информация, относящаяся к соединению канала разговора, может включать в себя информацию о приоритетных звонках (которая определяет приоритетные уровни номеров адресатов), информацию о типе звонка и т.п. Информация о типе звонка может указывать, установлен ли канал разговора для аварийной связи, широковещательной коммуникации, коммуникации компьютер-компьютер, коммуникации компьютер-POTS устройство и т.д. В одном из вариантов осуществления контекстная информация, относящаяся к соединению канала разговора, может включать в себя заданные идентификаторы, которые представляют эмоции, звуки (например, "ах," "ой", "ничего себе" и т.д.) и выражения лица в графических символах. В одном из вариантов осуществления Класс 802 Основы Звонка может быть определен в виде структуры поддерева VoIP Пространства 800 имен, которое включает в себя узлы, такие как приоритет 803 звонка, информация 804 о пространстве имен, тип 805 звонка, номер 806 адресата, провайдер 807 услуг, заданные идентификаторы 808 и т.п.

На фиг.10 показана блок-схема Класса 810 Контексты Звонка. В одном из вариантов осуществления поднабор VoIP контекстной информации, относящейся к контексту разговора, может соответствовать Классу 810 Контексты Звонка. Контекстная информация, относящаяся к контексту разговора, может включать в себя, среди прочего, такую информацию, как клиентские ключевые слова, идентифицированные ключевые слова, полученные из файловых данных документа, идентифицированные ключевые слова из пакета данных разговора (например, ключевые слова разговора), имена файлов для документов и/или мультимедийных файлов, обмениваемых в виде части разговора, информации, относящейся к играм (такой как тип игры, виртуальная близость к определенной игре), частота использования (включая частоту и продолжительность звонков, относящихся к определенному файлу, определенному объекту и определенному клиенту) и идентификация файла (такая как номер события, номер предмета обсуждения и т.п., относящиеся к разговору). Согласно иллюстративному варианту осуществления Класс 810 Контексты Звонка может быть определен в виде структуры поддерева VoIP Пространства 800 имен, которая включает в себя узлы, соответствующие идентификации 812 файлов, клиентских ключевых слов 813, ключевых слов 814 разговора, частоте 815 использования, предмета 816 разговора и т.п.

На фиг.11 показана блок-схема Класса 820 Тип Устройства. В одном из вариантов осуществления Класс 820 Тип Устройства может соответствовать поднабору VoIP контекстной информации, относящейся к клиентскому VoIP устройству, используемому для соединения канала разговора. Поднабор VoIP контекстной информации, относящийся к VoIP клиентскому устройству, может включать в себя информацию, относящуюся к аудио, которая может быть необходима для обработки аудиоданных, сгенерированных клиентским VoIP устройством. Информация, относящаяся к аудио, может включать в себя информацию, относящуюся к аудиофункциональным возможностям и способности устройства, таким как скорость сэмплирования, тип машины, тип вывода/ввода, микрофон, информация о карте цифровой обработки сигнала (DSP) и т.п. Поднабор VoIP контекстной информации, относящейся к VoIP клиентскому устройству, может включать в себя информацию, относящуюся к видео, которая может быть необходима для обработки видеоданных, сгенерированных VoIP клиентским устройством. Информация, относящаяся к видео, может включать в себя информацию о разрешающей способности, обновлении, печати и размере видеоданных, графической карте и т.п. Кроме того, если определена совместимость систем, может быть добавлен слой трансляции для распознавания обмениваемой информации для определения возможности осуществления коммуникации между различными типами систем. Контекстная информация, относящаяся к VoIP клиентским устройствам, также может включать в себя специфическую информацию о других устройствах, такую как тип компьютерной системы, информация о процессоре, пропускной способности сети, беспроводном/проводном соединении, мобильности компьютерной системы, установках обработки для компьютерной системы и т.п. В иллюстративном варианте осуществления Класс 820 Тип Устройства может быть определен в виде структуры поддерева VoIP Пространства 800 имен, которая включает узлы, соответствующие Аудио 822, Видео 824, специфике 826 устройства и т.п.

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

Биометрическая информация может включать в себя информацию об идентификации пользователя (например, отпечаток пальца), относящуюся к биометрической аутентификации, уровню напряжения пользователя, настроению и т.д. Кроме того, поднабор VoIP контекстной информации, относящейся к VoIP клиенту, может включать в себя информацию о местоположении (включая определенное местоположение клиента, определенное VoIP местоположение, местоположение согласно GPS/триангуляции и логическое/виртуальное местоположение отдельного пользователя), заданный номер телефона, контактную информацию о пользователе (такую как имя, адрес, компания и т.п.), правила, определенные клиентом, пользовательские предпочтения, управление цифровыми правами (DRM), ранг участника отдельного пользователя в организации, приоритет, ассоциированный с рангом участника, и т.п. Приоритет, ассоциированный с рангом участника, может использоваться для назначения приоритета клиенту для звонка, относящегося к конференции. В одном из вариантов осуществления Класс 830 VoIP Клиент может быть определен в виде структуры поддерева VoIP Пространства 800 имен, которое включает узлы, соответствующие биометрии 831 пользователя, местоположение 832, правила 833 для клиента, идентификацию 834 пользователя, приоритет 835 участника, предпочтение 836 пользователя, идентификацию 837 профиля добычи данных и т.п.

Фиг.13 представляет собой блок-схему процедуры добычи данных для добычи данных из пакетов данных из оцифрованного речевого разговора согласно варианту осуществления настоящего изобретения. Процедура 1300 добычи данных начинается на этапе 1301. На этапе 1303 получают пакет данных из речевого разговора. Очевидно, что процедура 1300 добычи данных может быть выполнена с использованием одного пакета данных или с использованием группы пакетов данных. На этапе 1305 принятия решения происходит определение, необходимо ли произвести добычу данных из этого пакета данных. Как обсуждалось выше, пакет данных может включать в себя идентификатор 513 добычи данных (фиг.5) в заголовке пакета данных, идентифицирующий, что полезная нагрузка пакета данных может включать в себя контент, ценный с точки зрения добычи данных. В качестве альтернативы с вариантами настоящего изобретения могут использоваться технологии идентификации пакетов данных, которые могут включать в себя контент, ценный с точки зрения добычи данных. Например, если пакет данных имеет конкретный размер, таким образом указывая, что он может содержать полезный контент, ценный с точки зрения добычи данных, пакет данных может быть выбран для добычи данных на этапе 1305 принятия решения.

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

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

Если на этапе принятия решения 1313 определено, что внешние профили добычи данных предназначены для использования с целью добычи данных из полученного пакета данных, такие профили получают на этапе 1315. После получения внешних профилей добычи данных на этапе 1315, или если на этапе 1313 принятия решения определено, что внешние профили добычи данных отсутствуют, то на этапе 1317 принятия решения определяют, существуют ли какие-либо правила добычи данных, которые должны быть применены к добыче данных. Правила добычи данных могут представлять собой, например, правила, определенные компанией, из которой производится звонок. Например, если клиент звонит из компании, компания может иметь правила добычи данных, которые не позволяют никакую добычу данных из разговоров, исходящих из этой компании или включая разговоры внутри этой компании. В качестве альтернативы правила добычи данных могут определять, когда могут быть сделаны звонки из конкретного местоположения, такого как компания. Если на этапе 1317 принятия решения определено, что правила добычи данных существуют, то на этапе 1319 профили добычи данных, полученные на этапе 1311 и этапе 1315, модифицируются на основе этих правил добычи данных.

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

Дополнительно к добыче пакетов данных во время разговора на этапе 1323 принятия решения может быть определено, нужна ли какая-либо постобработка разговора или добытого пакета данных. Если на этапе 1323 принятия решения определено, что постобработка нужна, то на этапе 1325 принятия решения определяют, имеются ли какие-либо правила постобработки. Если на этапе 1325 принятия решения определено, что имеются правила постобработки, то на этапе 1327 эти правила постобработки применяют к добытому пакету данных. Правила постобработки могут представлять собой, например, правила относительно того, какой тип постобработки может быть выполнен для пакета данных, что может быть сделано с контентом, который добыт из пакета данных во время постобработки и т.д. Однако если на этапе 1325 принятия решения определено, что правила постобработки отсутствуют, или после применения правил постобработки на этапе 1327 применяются профили, полученные на этапе 1311 и этапе 1315, которые, возможно, были модифицированы на этапе 1319, и ассоциируются с добытым пакетом данных, предназначенным для постобработки. Пакеты данных, предназначенные для постобработки, ассоциируют с профилями добычи данных и правилами так, чтобы эти профили и правила могли быть идентифицированы и получены во время проведения постобработки пакетов данных. В качестве альтернативы профиль добычи данных может не применяться к добытому пакету данных. На этапе 1331 добытые пакеты данных, правила постобработки и необязательно применяемые профили сохраняют для постобработки. После сохранения на этапе 1331 пакетов данных и соответствующей информации для постобработки, если на этапе 1323 определено, что никакую постобработку проводить не нужно, или если на этапе 1305 принятия решения определено, что полученный пакет данных не предназначен для добычи данных, процедура 1300 VoIP добычи данных завершается, как показано на этапе 1333.

Фиг.14 представляет собой блок-схему процедуры добытого пакета данных или обработки пакета данных, который был добыт из оцифрованного речевого разговора согласно варианту осуществления настоящего изобретения. Процедура добытого пакета данных 1400 начинается на этапе 1401. На этапе 1403 идентифицируют пакет (пакеты) данных, который был добыт из оцифрованного речевого разговора. Аналогично фиг.13 процедура 1400 добытого пакета данных может проводиться с одним пакетом данных или группой пакетов данных. Кроме того, как обсуждалось выше, добытые пакеты данных могут содержать данные разговора или контекстные данные. На этапе 1405 принятия решения определяют, должен ли быть модифицирован добытый пакет данных или контент добытого пакета данных. Если на этапе 1405 принятия решения определено, что добытый пакет/контент данных должен быть модифицирован, то этот добытый пакет/контент данных модифицируют на этапе 1407. Добытые пакеты данных или контент может быть модифицирован на основе правил, относящихся к профилям добычи данных и/или на основе правил постобработки. Например, правило может определять, что все добытые пакеты данных, содержащие контент, относящийся к информации о коммерческой тайне корпорации, должны быть удалены из разговора и направлены сотруднику корпорации. В добытых пакетах данных и/или контенте этих пакетов может быть сделан любой тип изменения, включая, без ограничений, удаление пакета данных из разговора, замену контента пакета данных другим контентом, сохранение пакета данных для будущего использования, записи пакета данных или контента пакета данных и т.д.

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

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

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

После обработки на этапе 1409 добытого пакета данных на этапе 1411 определяют, были ли получены дополнительные добытые пакеты данных, предназначенные для обработки. Если на этапе 1411 принятия решения определено, что имеются дополнительные добытые пакеты данных, предназначенные для обработки, процедура возвращается на этап 1403 и продолжается. Однако если на этапе 1411 принятия решения определено, что дополнительные добытые пакеты данных, предназначенные для обработки, отсутствуют, на этапе 1413 процедура 1400 завершается.

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