ИНДЕКСНАЯ СТРУКТУРА МЕТАДАННЫХ, СПОСОБ ПРЕДОСТАВЛЕНИЯ ИНДЕКСОВ МЕТАДАННЫХ, А ТАКЖЕ СПОСОБ ПОИСКА МЕТАДАННЫХ И УСТРОЙСТВО, ИСПОЛЬЗУЮЩЕЕ ИНДЕКСЫ МЕТАДАННЫХ Российский патент 2006 года по МПК G06F17/30 

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

Настоящее изобретение относится к индексной структуре метаданных, обеспеченной для поиска информации о содержании и способу предоставления индексов метаданных, а также к способу и устройству для поиска метаданных с использованием индексной структуры метаданных. В частности, настоящее изобретение относится к индексной структуре метаданных, содержащей информацию о ключе, по меньшей мере часть которой кодируется, с тем, чтобы предоставить возможность более эффективного поиска информации о содержании, когда метаданные XML (расширяемого языка разметки) для содержания в цифровой форме, определенного в документах TV-Anytime Forum (далее называется "TVA") (при этом упомянутые метаданные называют далее "метаданные TVA") делятся на фрагменты в независимом блоке и передаются по фрагментам; к способу для предоставления индексов метаданных, а также способу и устройству для поиска метаданных с использованием индексов метаданных. Данная заявка основана на патентных заявках Кореи № 2002-43097 и № 2002-62913, содержание которых включено сюда посредством ссылки.

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

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

TV-Anytime Forum имеет управляемые рабочие группы для моделей бизнеса, организации ссылок на систему/интерфейсы передачи/содержание, описаний, метаданных, управления правами и защиты и т.п. с целью установления стандартов. Что касается метаданных, которые имеют отношение к настоящему изобретению, то к июню 2002 года был разработан первый проект спецификации метаданных "1^st Draft of Metadata Specification SP003v1.3".

Далее со ссылками на фиг.1 кратко описывается конфигурация PDR. Устройство PDR 100 принимает видео/аудио сигналы и метаданные от провайдера (поставщика услуг) 200, предоставляющего видео/аудио сигналы, через множество различных сетей, использующих, к примеру, отраженные ионосферой сигналы и спутниковые сигналы, а также через сеть Интернет и т.п., собирает просматриваемые и прослушиваемые образцы, а также данные о личных вкусах пользователей, если это необходимо, и передает их провайдеру 200, предоставляющему видео/аудио сигналы. PDR 100 содержит запоминающее устройство большой емкости для хранения в нем принятых видео/аудио сигналов и метаданных. PDR 100, кроме того, содержит программные средства для сохранения и воспроизведения видео/аудио сигналов и приложение электронного гида по программам (EPG) для извлечения и отображения метаданных для видео/аудио сигналов. Пользователь знакомится с метаданными для видео/аудио данных, то есть названиями программ, временем воспроизведения программ и т.п. через экран гида с сеткой передач приложения EPG, показанный на фиг.2, выбирает требуемую программу и принимает ее через сеть в реальном времени либо воспроизводит видео/аудио данные, предварительно сохраненные в запоминающем устройстве большой емкости.

Метаданные относятся к данным, описывающим содержание (программ), таким как названия и краткое содержание программ, и определены здесь как "данные о данных". В спецификациях TV-Anytime Forum для метаданных TVA их структура задается путем использования языка схемы (логической структуры в базах данных) XML (см. XML 1.0 of W3C (Консорциум World Wide Web)), Стандартом от W3C (Консорциума для продвижения стандартов для XML); кроме того, задаются семантика и атрибуты соответствующих элементов метаданных. Метаданные TVA, относящиеся к содержанию вещания, сконфигурированы с помощью документа XML, имеющего корневой узел "TVAMain (300)", как показано на фиг.3. Метаданные TVA, относящиеся к программам, сконфигурированы, например, с помощью таких узлов, как таблица ProgramInformation (информация о программах), таблица GroupInformation (информация о группах), таблица ProgramLocation (местоположение программ), таблица ServiceInformation (информация об услугах) и т.п. под узлом "ProgramDescription" (описание программ).

В TV-Anytime Forum метаданные TVA передаются по фрагментам в виде независимого блока с целью передачи большого объема метаданных TVA в потоковом формате. Далее со ссылками на фиг.4 описывается концепция фрагментов. Фрагменты получают путем разделения метаданных TVA, сконфигурированных с помощью документов XML, показанных на фиг.3, на заранее определенные древовидные структуры. Например, если все метаданные TVA разделены на древовидную структуру (фрагмент TVAMain), включающую в себя верхний узел "TVAMain" и заранее определенные дочерние узлы под этим верхним узлом, древовидную структуру (фрагмент ProgramInformation), включающую в себя верхний узел таблицы ProgramInformation и дочерние узлы под этим верхним узлом, древовидную структуру (фрагмент BroadcastEvent (событие вещания)), включающую в себя верхний узел с информацией BroadcastEvent и дочерние узлы под этим верхним узлом, то каждая из выделенных древовидных структур становится фрагментом. Эти фрагменты могут передаваться независимо от других фрагментов, и к ним можно осуществлять доступ по отдельности.

Для индивидуального доступа к фрагментам необходимо знать узел, на который ссылается переданный фрагмент метаданных TVA, то есть узел, соответствующий верхнему узлу фрагмента метаданных TVA, во всей древовидной структуре метаданных, и описать соответствующие пути во фрагментах метаданных TVA ключей, содержащихся в переданном фрагменте метаданных TVA. С этой целью используют путь XPath, который представляет синтаксис для описания пути к одному или нескольким узлам в документе XML, определенный стандартом W3C. Термин "ключ" относится к специальному полю метаданных, используемому для индексации, а также означает дочерние узлы того узла, на который ссылается фрагмент. Указанным ключам соответствуют поля (для условий поиска), заполняемые пользователем, такие как "ID (идентификатор) услуги" и "Объявленное время".

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

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

В спецификации TV-Anytime Specification TV145, J.P. Evain, "1^st Draft of Metadata Specification SP003v1.3", TV-Anytime Forum 17^th meeting, Montreal, Canada, June 2002; далее называемой ссылка на предшествующий уровень техники для индексов ключей, предлагается потоковая структура индексных данных ключей для индекса фрагмента метаданных.

Описанию индексной структуры предшествует описание понятия "контейнер", определенного в документах TV-Anytime Forum.

TV-Anytime Forum определяет контейнер как запоминающее устройство верхнего уровня, на которое передаются все данные, относящиеся к вышеупомянутой индексной информации, и фрагменты метаданных, причем такую передачу называют передачей верхнего уровня. Если описать контейнер кратко, то каждый контейнер содержит множество секций, в каждой из которых хранится индексная информация или фрагменты метаданных. Контейнер может быть классифицирован на индексный контейнер и контейнер данных в зависимости от той информации, которая в нем хранится, причем индексный контейнер содержит секции с индексной информацией, такие как секция списка индексов ключей (key_index_list), секция индекса ключа (key_index), секция субиндекса ключа (sub_key_index), секция хранилища строк (string_repository) и секция хранилища данных фрагментов (fragment_data_repository), в то время как контейнер данных содержит секции фрагментов метаданных, такие как секция таблицы элементов (elements_table), секция хранилища строк (string_repository) и секция хранилища данных фрагментов (fragment_data_repository). Вышеуказанная классификация выполняется на основе содержания информации, находящейся в контейнерах. Конфигурация индексного контейнера идентична конфигурации контейнера данных.

Обратимся к контейнеру, определенному в документах TV-Anytime Forum, как это показано на фиг.5, где контейнер содержит поле данных идентификатора контейнера (container_id) (не показано) и большое количество секций. В каждой секции содержание, хранящееся в "section_body" (тело секции), идентифицируют в соответствии со значением, закодированным в "section_id". Например, секция 10, закодированное значение которой в "section_id" равно "0Х0004", идентифицируется как секция списка индексов ключей (key_index_list); секция 20, закодированное значение которой в "section_id" равно "0Х0005", идентифицируется как секция индекса ключа (key_index); секция 30, закодированное значение которой в "section_id" равно "0Х0006", идентифицируется как секция субиндекса ключа (sub_key_index); секция 40, закодированное значение которой в "section_id" равно "0Х0001", идентифицируется как секция таблицы элементов (elements_table), а секция 50, закодированное значение которой в "section_id" равно "0Х0003", идентифицируется как секция хранилища данных фрагментов (fragment_data_repository).

Фрагменты метаданных TVA сохраняются в секции 50 хранилища данных фрагментов (fragment_data_repository) контейнера данных, а затем выполняется их передача. Информация идентификатора (handle_value) для фрагментов метаданных TVA в контейнере данных содержится в секции 40 таблицы элементов контейнера данных.

В заключение следует сказать, что фрагмент метаданных TVA уникальным образом идентифицируется информацией идентификатора контейнера (container_id) и информацией идентификатора фрагмента метаданных (handle_value) контейнера, который включает в себя фрагмент метаданных TVA.

В вышеописанной ссылке на предшествующий уровень техники для индексов ключей предлагается индексная структура ключей для индексации фрагментов метаданных TVA, хранящихся в вышеупомянутом контейнере данных, то есть структура, состоящая из секции 10 списка индексов ключей (key_index_list), секции 20 индекса ключа (key_index) и секции 30 субиндекса ключа (sub_key_index). Поскольку синтаксис этой структуры подробно описан в вышеописанной ссылке на предшествующий уровень техники для индексов ключей, его подробное описание здесь опускается. Далее со ссылками на фиг.6 описывается структура, иллюстрируемая с помощью сегментов индексной информации.

Секция 10 списка индексов ключей (key_index_list), определенная в индексной структуре ключей, предоставляет список всех переданных ключей. Этот список включает в себя информацию о ключах, определяющую каждый ключ, и идентификационную информацию секции 20 индекса ключа (key_index), которая описывается ниже. Информация о ключе содержит: (1) информацию о местоположении фрагмента метаданных, относящегося к этому ключу; (2) информацию о местоположении ключа в этом фрагменте метаданных. Информация о местоположении фрагмента метаданных выражается в XPath (fragment_xpath_ptr) в TVA. Информация о местоположении ключа выражается в XPath (key_xpath_ptr) для относительного пути в подходящем фрагменте узлов, используемых в качестве ключа в TVA.

XPath фрагмента метаданных - это путь к корневому узлу документа XML метаданных TVA, то есть абсолютный путь, а XPath узлов, используемых в качестве ключей, то есть XPath ключей, представляет относительный путь ключа для релевантного фрагмента метаданных. XPath для фрагмента метаданных и XPath для ключа хранятся в сегменте 11 "fragment_xpath_ptr" и сегменте 12 "key_xpath_ptr", соответственно.

Кроме того, секция 10 списка индексов ключей (key_index_list) включает в себя идентификационную информацию секции 20 индекса ключа (key_index) каждого ключа, описываемого ниже (то есть информацию идентификатора контейнера (container_id), хранящуюся в секции 20 индекса ключа (key_index), и информацию идентификатора индекса ключа). Информация идентификатора контейнера и информация идентификатора индекса ключа сохраняется в сегменте "index_container" секции 10 списка индексов ключей (key_index_list) и сегменте "key_index_identifier", соответственно, а затем выполняется передача этой информации.

Секция 20 индекса ключа (key_index), определенная в индексной структуре ключей, предоставляет список информации, представляющей диапазоны значений ключа, входящих в соответствующую секцию 30 субиндекса ключа (sub_key_index), то есть максимальное значение ключа из числа значений ключа в соответствующем диапазоне (далее называемое "репрезентативное значение ключа"), и идентификационную информацию секции 30 субиндекса ключа (sub_key_index), относящуюся к каждому репрезентативному значению ключа (то есть информацию идентификатора контейнера (container_id), относящуюся к контейнеру, в котором хранится секция субиндекса ключа, и информацию идентификатора субиндекса ключа).

Соответственно, секция 20 индекса ключа (key_index) включает в себя сегмент "key_index_identifier" для хранения в нем информации идентификатора индекса ключа, определенной в секции 10 списка индексов ключей (key_index_list), сегменты 13 "high_key_value" для сохранения в них репрезентативных значений ключа для соответствующих диапазонов значений ключа, включенных в секцию 30 субиндекса ключа (sub_key_index), а также сегменты "sub_index_container" и сегменты "sub_index_identifier" для идентификационной информации секции 30 субиндекса ключа (sub_key_index) (т.е., для информации идентификатора контейнера (container_id), относящейся к контейнеру, в котором хранится секция 30 субиндекса ключа (sub_key_index), и соответствующей информации идентификатора субиндекса ключа). Секция 30 субиндекса ключа (sub_key_index), определенная в структуре индексов ключей, предоставляет список значений ключа. Этот список дополнительно включает в себя идентификационную информацию фрагментов метаданных, соответствующих значениям ключа (то есть информацию идентификатора контейнера (container_id) для контейнеров, хранящих фрагменты метаданных, и информацию идентификаторов (handle_value) фрагментов метаданных).

Соответственно, секция 30 субиндекса ключа (sub_key_index) включает в себя сегмент "sub_index_identifier" для хранения в нем информации идентификатора субиндекса ключа, определенной в секции 20 индекса ключа (key_index), сегменты 14 "key_value" для хранения в них соответствующих диапазонов значений ключа, сегменты "target_container" для хранения в них соответствующей информации идентификатора контейнера (container_id) для контейнеров, в которых хранятся фрагменты метаданных, и сегменты "target_handle" для хранения в них соответствующей информации идентификаторов данных фрагментов (handle_value). Индексную структуру ключей можно будет легко понять, обратившись к фиг.7, где представлена информация об индексах.

На фиг.7 показана секция списка индексов ключей (key_index_list), включающая в себя ключи, относящиеся к идентификатору услуги (Service ID), объявленному времени (Published Time) и объявленной длительности (Published Duration). Верхний узел фрагмента метаданных, который включает в себя ключи, относящиеся к идентификатору услуги, объявленному времени и объявленной длительности, представляет собой "BroadcastEvent" 310, как показано на фиг.3 в виде заштрихованного блока. Соответственно, путь XPath "/TVAMain/ProgramDescription/ProgramLocation Table/BroadcastEvent" для фрагмента "BroadcastEvent" хранится в сегменте 11а "fragment_xpath_ptr", а пути XPath к ключам идентификатора услуги, объявленного времени и объявленной длительности для фрагмента "BroadcastEvent", то есть "@ServiceId" (311а на фиг.3), "EventDescription/PublishedTime" (311b на фиг.3) и "EventDescription/PublishedDuration" (311с на фиг.3) хранятся в сегменте 12а "key_xpath_ptr".

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

На фиг.7 показана секция списка индексов ключей (key_index_list), включающая в себя ключи для идентификатора услуги, объявленного времени и объявленной длительности, где верхний узел метаданных, относящихся к идентификатору услуги, объявленному времени и объявленной длительности, представляет собой "BroadcastEvent" 310, как показано на фиг.3 в виде заштрихованного блока. Соответственно, путь XPath для фрагмента "BroadcastEvent" "/TVAMain/ProgramDescription/ProgramLocation Table/BroadcastEvent" хранится в сегменте "fragment_xpath_ptr", а соответствующие пути XPath для ключей идентификатора услуги, объявленного времени и объявленной длительности для фрагмента "BroadcastEvent", "@ServiceId" (см. 311а на фиг.3), "EventDescription/PublishedTime" (см. 311b на фиг.3) и "EventDescription/PublishedDuration" (см. 311с на фиг.3) хранятся в сегменте "key_xpath_ptr".

На фиг.7 также показана секция 20 индекса ключа (key_index) и секция 30 субиндекса ключа (sub_key_index) для идентификатора услуги (путь XPath ключа: @ServiceID) среди секций списка индексов ключей (key_index_list).

В такой индексной структуре при вводе условия для поиска метаданных, определении информации о местоположении поля для введенного условия поиска в метаданных и сравнении определенной таким образом информации о местоположении с информацией о ключах в списке индексов ключей, с тем, чтобы найти ключ, имеющий определенную выше информацию о местоположении в списке индексов ключей, неизбежно чрезмерное расходование ресурсов из-за необходимости сравнения обоих путей XPath. Аналогичная проблема возникает в случае, когда ключи, указывающие относительные пути от фрагментов информации о ключах, сравниваются в отношении информации о местоположении. В частности, эта проблема становится особенно серьезной, когда сравнивают в отношении информации о местоположении фрагменты, более сложные, чем ключи. Поскольку путь XPath фрагмента, представляющего информацию о местоположении среди информации о ключах, описывает путь к релевантному узлу от корневого узла в документе XML, затраты на передачу оказываются не эффективными, а затраты на интерпретацию XPath в терминале оказываются высокими. Например, XPath фрагмента события вещания, указывающего информацию о местоположении программы среди фрагментов TV-Anytime, может быть представлен в виде "/TVAMain/ProgramDescription/ProgramLocation Table/BroadcastEvent". Между тем, для того, чтобы представить один узел в документе XML, путь XPath может быть выражен альтернативным образом. В случае для события вещания, помимо вышеупомянутого нормального представления, в альтернативном варианте путь XPath может быть выражен как "/TVAMain//BroadcastEvent" или "//BroadcastEvent" и т.д. Здесь "//" означает дочерний узел в структуре документа XML. Следовательно, операция для проверки того, являются ли фрагменты одинаковыми, путем использования XPath, оказывается не простой операцией, где только сопоставляются друг с другом простые строки. В частности при анализе/сравнении релевантного пути потребуются расходы ресурсов, если путь XPath выражен в сокращенном формате.

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

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

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

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

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

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

Другая часть информации о местоположении может быть выражена в виде другого заранее заданного кода или Xpath.

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

Одна из информации о местоположении фрагмента и информации о местоположении ключа может быть выражена в виде заранее заданного кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оставшаяся информация о местоположении может быть выражена в виде другого заранее заданного кода или Xpath.

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

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

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

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

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

Блок управления может осуществлять поиск репрезентативного значения ключа, удовлетворяющего условию поиска, среди репрезентативных значений ключа индекса, соответствующих диапазонам значений ключа, и поиск значения в диапазоне значений, соответствующем репрезентативному значению ключа. Метаданные могут иметь структуру метаданных, определенную организацией TV-Anytime Forum.

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

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

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

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

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

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

Перечень фигур чертежей

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

фиг.1 - схема, иллюстрирующая концепцию обычного PDR;

фиг.2 - экран гида с сеткой передач в обычном приложении EPG;

фиг.3 - блок-схема, иллюстрирующая структуру обычных метаданных, определенная TV-Anytime Forum;

фиг.4 - схема, иллюстрирующая концепцию обычного фрагмента, определенного TV-Anytime Forum;

фиг.5 - схема, иллюстрирующая концепцию обычного контейнера, определенного TV-Anytime Forum;

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

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

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

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

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

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

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

Наилучший вариант осуществления изобретения

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

В данном описании варианты осуществления изобретения в целях упрощения описываются на основе метаданных TVA; однако это не следует интерпретировать или понимать как ограничение объема охраны настоящего изобретения.

На фиг.8 показана индексная структура метаданных для поиска метаданных согласно варианту осуществления настоящего изобретения, при этом индексная структура включает в себя информацию для определения ключа с целью индексации фрагментов метаданных TVA, хранящихся в контейнере данных, как было описано выше. Ниже описываются секция 110 списка индексов ключей (key_index_list), секция 120 индекса ключа (key_index) и секция 130 субиндекса ключа (sub_key_index), а затем описывается индексная структура, включающая в себя закодированную информацию о ключах, определенную упомянутым синтаксисом.

Синтаксис, определяющий индексную структуру метаданных, соответствующую одному варианту осуществления настоящего изобретения и включающую в себя, в частности, закодированную информацию о ключах, отличается концептуально от синтаксиса, определенного в ссылке на предшествующий уровень техники для стандартных индексов ключей, в том что он содержит новые структуры, введенные для концепции кодирования информации о ключах, такие как fragment_descriptor() (дескриптор фрагмента) и key_descriptor() (дескриптор ключа), и реорганизует структуры секции 110 списка индексов ключей (key_index_list), секции 120 индекса ключа (key_index) и секции 130 субиндекса ключа (sub_key_index).

Секция 110 списка индексов ключей (key_index_list) содержит информацию о ключах, определяющую соответствующие ключи и идентификационную информацию секции 120 индекса ключа (key_index), которые описываются ниже.

Информация о ключах служит для определения ключей, то есть информации о местоположении в метаданных, которую имеют поля метаданных, образующие ключи. Информация о ключах содержит информацию о местоположении того фрагмента метаданных, которому принадлежат поля, образующие ключи, в метаданных (далее это называется "информация о местоположении фрагмента", которая выражается в пути XPath фрагмента в TVR (fragment_xpath_ptr), и информацию о местоположении полей, образующих ключи, которые находятся в соответствующем фрагменте метаданных (далее это называют "информация о местоположении ключа", то есть XPath для относительного пути узла в подходящем фрагменте, используемом в качестве ключа в TVA, который в TVA выражается в виде XPath ключа (то есть key_xpath_ptr).

1. Секция списка индексов ключей (key_index_list)

Секция списка индексов ключей (key_index_list) предоставляет список всех переданных ключей.

В варианте осуществления настоящего изобретния "fragment_xpath_ptr", указывающий информацию о местоположении фрагмента в стандартной секции списка индексов ключей (key_index_list) (выраженной в XPath фрагмента в TVA), заменяется с fragment_descriptor().

Таблица 1Синтаксис№№ битов (заменяемые)key_index_list() { для (j=0; j<key_index_count;
j++) { fragment_descriptor() 16key_descriptor() 16Index_container 16key_index_identifier 8} } 

key_index_count: задает количество всех переданных ключей, то есть количество индексов для всего документа XML.

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

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

index_container: идентифицирует контейнер, в котором находится заданная секция индекса ключа (key_index).

key_index_identifier: идентифицирует секцию индекса ключа (key_index) в контейнере, заданном с помощью index_container. Секция индекса ключа (key_index) может быть идентифицирована уникальным образом в комбинации index_container и key_index_identifier.

2. Дескриптор фрагмента (fragment_descriptor)

"fragment_descriptor()" обеспечивает структуру кодирования специальных битов (которые могут кодироваться с произвольным числом бит, к примеру, 8 бит, 16 бит и т.д.) в отношении часто используемого типа стандартного фрагмента, и одновременно обеспечивает структуру, способную описывать XPath в качестве дополнительной информации по отношению к типу фрагмента метаданных, определенному пользователем. То есть, если fragment_descriptor равен "0xFF", то это указывает на определенный пользователем фрагмент, и таким образом сразу описывается XPath для соответствующего фрагмента, определенного пользователем.

Таблица 2Синтаксис№№ битов (заменяемые)fragment_descriptor() { fragment_type 8если (fragment_type == 0xFF)
{ fragment_xpath_ptr16} } 

fragment_type: представляет тип фрагментов, подлежащих индексации. Закодированные значения присваиваются часто используемым стандартным типам фрагментов. Если fragment_type имеет закодированное значение 0xFF, то в качестве дополнительной информации добавляется fragment_xpath_ptr.

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

Таблица 3ЗначениеОписание0х00Не обозначено0х01Фрагмент ProgramInformation0х12Фрагмент GroupInformation0х13Фрагмент CreditsInformation0х04Фрагмент ProgramReview 0х05Фрагмент SegmentInformation0х06Фрагмент ServiceInformation0х07Фрагмент BroadcastEvent0хFFФрагмент, обозначаемый пользователем0x08-0x0E
0x10-0xFFЗарезервировано

3. Дескриптор ключа (key_descriptor)

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

Таблица 4Синтаксис№№ битов (заменяемые)key_descriptor() { key_type 8если (key_type == 0xFF) { key_xpath_ptr 16} } 

key_type: представляет тип ключей, подлежащих индексации. Информации о местоположении часто используемых типов стандартных ключей при выполнении поиска присваивают закодированные значения. Если key_type имеет закодированное значение "0xFF", то key_xpath_ptr добавляется в качестве дополнительной информации.

key_xpath_ptr: относится к относительному пути, включенному в XPath фрагмента для узла, используемого в качестве ключа.

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

Поскольку определения секции индекса ключа (key_index) и секции субиндекса ключа (sub_key_index) аналогичны определенным в ссылке на предшествующий уровень техники для индексов ключей, их подробное описание опускается.

4. Секция индекса ключа (key_index)

Таблица 5Синтаксис№№ битов (заменяемые)key_index() { key_index_identifier8для (j=0; j<sub_index_count;
j++){ high_key_value 16sub_index_container 16sub_index_identifier 8} } 

5. Секция субиндекса ключа (sub_key_index)

Таблица 6Синтаксис№№ битов (заменяемые)sub_key_index() { sub_index_identifier 8для (j=0; j<reference_count; j++)
{ key_value16target_container 16target_handle 16} } 

Далее со ссылками на фиг.8 описывается структура метаданных, определенная посредством вышеописанного синтаксиса, где метаданные представлены в виде сегментов индексной информации.

Секция 110 списка индексов ключей (key_index_list), определенная в индексной структуре, предоставляет список всех переданных ключей. Этот список включает в себя информацию о ключах, определяющую каждый ключ (то есть информацию о местоположении фрагмента (fragment_descriptor) и/или информацию о местоположении ключа (key_descriptor); информация о местоположении фрагмента или информация о местоположении ключа может быть избирательно закодирована, либо эти данные могут кодироваться одновременно в зависимости от вариантов осуществления настоящего изобретения) и идентификационную информацию секции 120 индекса ключа (key_index), описываемой ниже. XPath фрагмента метаданных - это путь для корневого узла документа XML с метаданными TVA, то есть абсолютный путь, по аналогии со стандартной индексной структурой, а XPath узла, используемого в качестве ключа, то есть XPath ключа, представляет относительный путь ключа для фрагмента метаданных. Комбинация XPath фрагмента метаданных и XPath ключа представляет информацию о местоположении ключа для всего документа XML.

В настоящем изобретении закодированное значение, соответствующее XPath для фрагмента метаданных (то есть информация о местоположении группы фрагментов), и закодированное значение, соответствующее XPath ключа (то есть информация о местоположении ключа), сохраняются соответственно в сегменте 111 "fragment_descriptor" и сегменте 112 "key_descriptor".

Как было описано выше, если информация о местоположении фрагмента, составляющая часть информации о ключах, представляет собой тип стандартного фрагмента, который часто используется, то предоставляется закодированное значение (fragment_descriptor), выражающее XPath для фрагмента метаданных (fragment_xpath_ptr) с заранее заданными кодами. Примерами часто используемых типов стандартных фрагментов являются информация о программах (ProgramInformation), информация о группе программ (GroupInformation), информация о кредитах (CreditsInformation), обзор программ (ProgramReview), информация о сегментах (SegmentInformation), событие вещания (BroadcastEvent), служебная информация (ServiceInformation) и т.п. Если XPath фрагмента метаданных для этих типов фрагментов может быть просто выражен в виде закодированного значения, то можно уменьшить расход ресурсов на поиск метаданных.

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

В варианте осуществления, где фрагменты кодируют в соответствии с таблицей 3, информация о местоположении фрагмента метаданных, входящая в состав информации о ключах, имеет такие закодированные значения, как "0х01", "0х02" и "0х03". Информация о местоположении фрагмента данных, закодированная в "0х01", указывает XPath для "фрагмента информации о программах (ProgramInformation)". Кроме того, если информация о местоположении фрагмента метаданных представляет собой "0хFF", то это означает, что фрагмент метаданных определен пользователем, и поэтому предоставляется дополнительная область для возможности определения XPath фрагмента метаданных.

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

Кроме того, секция 110 списка индексов ключей (key_index_list) содержит идентификационную информацию секции 120 индекса ключа (key_index) для каждого ключа, которая описывается ниже (то есть информация идентификатора контейнера (container_id), относящаяся к контейнеру, где хранится секция 120 индекса ключа (key_index), и информация с идентификатором индекса ключа). Информация с идентификатором контейнера и информация идентификатора индекса ключа хранятся, соответственно, в сегменте "index_container" и сегменте "key_index_identifier" в секции 110 списка индексов ключей (key_index_list).

Поскольку секция 120 индекса ключа (key_index) и секция 130 субиндекса ключа (sub_key_index) аналогичны соответствующим секциям, описанным в ссылке на предшествующий уровень техники для индексов ключей, их описание опускается.

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

На фиг.9 показана секция 110 списка индексов ключей, в которой XPath фрагмента "BroadcastEvent" для идентификатора (ID) услуги закодирован в "0х07". Здесь секция 120 индекса ключа (key_index) и секция 130 субиндекса ключа (sub_key_index) аналогичны соответствующим секциям, описанным со ссылкой на фиг.7.

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

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

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

Информация о содержании, то есть метаданные, сначала обрабатывается по фрагментам, как было описано выше (S100). На этапе S200 кодируется по меньшей мере часть (информация о местоположении фрагмента или информация о местоположении ключа) информации в полях, которые будут включены в индекс метаданных, то есть информация о ключе (например, информация о местоположении фрагмента или информация о местоположении ключа). Другими словами, если информация о местоположении фрагмента метаданных, которому принадлежат поля, образующие ключ, или информация о местоположении ключа относится к типу стандартного фрагмента или типу стандартного ключа, причем и та и другая информация могут быть закодированы, то информация о местоположении фрагмента метаданных или информация о местоположении ключа, то есть XPath фрагмента метаданных или XPath ключа, кодируется в заранее заданное кодовое значение (например, фрагмент "события вещания (BroadcastEvent)" кодируют в "0х07") на фиг.9. Если информация о местоположении фрагмента метаданных или информация о местоположении ключа не идентифицирована с помощью закодированных значений, то информация о ключе, выраженная посредством XPath, задается так, как это делается в предшествующем уровне техники.

Ключ предоставляется посредством использования информации, образующей фрагменты, например, информации об "ID услуги" (Service ID) (S300). Затем предоставляется секция 130 субиндекса ключа (sub_key_index) для ключа, обеспеченного выше (S400). Секция 130 субиндекса ключа (sub_key_index) включает в себя сегменты 114, содержащие диапазоны значений ключа, идентификационную информацию фрагментов метаданных, соответствующую значениям ключа (то есть информацию идентификатора контейнера (container_id) и информацию идентификатора данных фрагмента (handle_value), хранящиеся, соответственно, в сегменте "target_container" и сегменте "target_container" по фиг.8).

Секция 120 индекса ключа (key_index), содержащая репрезентативное значение ключа, представляющее соответствующие диапазоны значений ключа, предоставляется на этапе S500. Например, вводится репрезентативное значение ключа (например, 509), указывающее заранее заданный диапазон (например, 500-509) ID услуги. Секция 120 индекса ключа (key_index) включает в себя идентификационную информацию для секции 130 субиндекса ключа (sub_key_index), причем идентификационная информация содержит информацию идентификатора контейнера (container_id), относящуюся к контейнеру, в котором хранится секция субиндекса ключа (sub_key_index), и информацию идентификатора субиндекса ключа, как показано на фиг.8.

Секция 110 списка индексов ключей (key_index_list), организующая информацию о ключах, полученная выше, то есть информацию о местоположении фрагмента и информацию о местоположении ключа, предоставляется на основе ключа на этапе S600. В то же время, если закодированная информация о местоположении фрагмента либо закодированная информация о местоположении ключа на этапе S200 существует, то вышеуказанную информацию о местоположении представляют в закодированном коде, когда предоставлена секция 110 списка индексов ключей (key_index_list). Другими словами, например, фрагмент "события вещания (BroadcastEvent)" на фиг.9 представлен как "0Х07". Если информацию о местоположении фрагмента или информацию о местоположении ключа нельзя различить с помощью закодированных значений, то можно использовать информацию о ключе, выраженную в XPath, как это делается в предшествующем уровне техники.

Секция 110 списка индексов ключей (key_index_list) в дополнение к информации о ключах дополнительно содержит идентификационную информацию секции 120 индекса ключа (key_index).

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

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

Условие поиска вводится, например, пользователем на этапе S1100, а на этапе S1210 определяется информация о местоположении метаданных, относящаяся к полю введенного условия поиска. Поиск ключа, соответствующего этой информации о местоположении, выполняется в секции 110 списка индексов ключей (key_index_list) (этап S1300), при этом по меньшей мере часть информации о местоположении, например, информация о местоположении фрагмента, включающего в себя ключ, или информация о местоположении ключа в этом фрагменте, определена с помощью заранее заданного кода, и соответствующие метаданные извлекаются путем использования найденного ключа (S1400).

Этап S1400 извлечения соответствующих метаданных содержит поиск репрезентативного значения ключа, удовлетворяющего условию поиска, путем сравнения с репрезентативным значением ключа и диапазоном значений ключа условия поиска, в секции 120 индекса ключа (key_index) и поиск в секции 130 субиндекса ключа (sub_key_index) сегмента 114, включающего в себя значения ключа в диапазоне, представленном найденным репрезентативным значением ключа (S1410), поиск значения ключа, удовлетворяющего условию поиска, в сегменте 114 секции 130 субиндекса ключа (sub_key_index), в которой выполнялся поиск (S1420), и извлечение соответствующих метаданных путем использования идентификационной информации фрагмента метаданных, соответствующего значению ключа (S1430), в результате чего извлекают фрагмент метаданных, удовлетворяющий условию поиска. Например на фиг.2 и 9, вводится условие поиска, соответствующее ключу идентификатора услуги "Service Id" в диапазоне 507-514, выполняется поиск репрезентативных значений ключа 509 и 519, и фрагменты, соответствующие условию поиска, извлекаются посредством использования идентификационной информации фрагментов, соответствующих значениям ключа.

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

На этапах S1410, S1420 и S1430 выполняется поиск соответствующей секции 120 индекса ключа (key_index) и секции 130 субиндекса ключа (sub_key_index) и извлечение соответствующего фрагмента путем использования идентификационной информации секции 120 индекса ключа (key_index), секции субиндекса ключа (sub_key_index) и фрагмента метаданных, соответственно.

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

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

Блок 1400 управления сравнивает входные данные, определяющие условие поиска и поступающие из блока 1100 ввода, со значением ключа, содержащимся в индексе метаданных, который хранится в блоке 1300 хранения данных.

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

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

Промышленная применимость

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

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

Заявленное изобретение относится к индексной структуре метаданных, обеспеченной для поиска информации о содержании. Техническом результатом является обеспечение быстрого поиска информации о содержании. Для этого, согласно способу по первому варианту, определяют информацию о местоположении, осуществляют поиск ключа и извлекают метаданные по найденному ключу, а согласно способу по второму варианту осуществляют доступ к списку комбинаций, в котором осуществляют поиск ключа метаданных, определяют идентификационную информацию метаданных и извлекают метаданные по найденной идентификационной информации. Устройства, реализующие эти способы, содержат блок ввода и блок управления. 4 н. и 17 з.п. ф-лы, 12 ил., 6 табл.

1. Способ поиска разделенных на фрагменты метаданных с использованием индекса, содержащего список ключей, соответствующих полям метаданных, и информации о местоположении для определения ключей, при этом способ содержит этапы, на которых определяют информацию о местоположении, соответствующую условию поиска в отношении метаданных, при этом по меньшей мере часть данной информации о местоположении выражена в виде значения заранее заданного кода, осуществляют поиск, на основе индекса метаданных, ключа, соответствующего упомянутому значению заранее заданного кода, и извлекают фрагмент метаданных путем использования найденного ключа.2. Способ по п.1, в котором извлечение фрагмента содержит этапы, на которых осуществляют поиск значения ключа, удовлетворяющего условию поиска, среди значений ключа из индекса, и извлекают фрагмент метаданных, используя идентификационную информацию фрагмента, соответствующего этому значению ключа.3. Способ по п.2, в котором в качестве реакции на множество значений ключа, удовлетворяющих условию поиска, извлечение фрагмента содержит этап, на котором извлекают те фрагменты метаданных, которые соответствуют значениям ключа, удовлетворяющим условию поиска.4. Способ по п.2, в котором поиск значения включает в себя этапы, на которых осуществляют поиск репрезентативного значения ключа, удовлетворяющего условию поиска, среди репрезентативных значений ключа индекса, соответствующих диапазонам значений ключа, и осуществляют поиск значения в диапазоне значений, соответствующем репрезентативному значению ключа.5. Способ по п.1, в котором индекс содержит секцию списка индексов ключей, содержащую список, секцию субиндекса ключа, содержащую диапазоны значений ключа и идентификационную информацию тех фрагментов метаданных, которые соответствуют упомянутым значениям ключа, и секцию индекса ключа, содержащую репрезентативные значения ключа, представляющие соответствующие диапазоны значений ключа.6. Способ по п.1, в котором информация о местоположении содержит информацию о местоположении фрагмента метаданных, включающего в себя ключ, и информацию о местоположении ключа в этом фрагменте.7. Способ поиска разделенных на фрагменты метаданных, включающий в себя этапы, на которых осуществляют доступ к списку, содержащему множество комбинаций информации о местоположении фрагмента и информации о местоположении, определяющей по меньшей мере один ключ в этом фрагменте, при этом одна из информации о местоположении фрагмента и информации о местоположении, определяющей по меньшей мере один ключ, выражена в виде заранее заданного кода, осуществляют поиск в этом списке комбинации, соответствующей условию поиска по меньшей мере одного ключа метаданных, определяют идентификационную информацию метаданных, идентифицируемых найденной комбинацией, на основе заранее заданного кода, соответствующего этой комбинации, и извлекают один или более фрагментов метаданных, соответствующих упомянутой идентификационной информации.8. Способ по п.7, в котором оставшаяся информация о местоположении может быть выражена в виде другого заранее заданного кода или Xpath.9. Устройство для поиска разделенных на фрагменты метаданных с использованием индекса, содержащего список ключей, соответствующих полям метаданных, и информацию о местоположении, определяющую ключи, включающее в себя блок ввода, выполненный с возможностью приема условия поиска, содержащего поле метаданных в качестве параметра поиска, и блок управления, выполненный с возможностью определения информации о местоположении, соответствующей условию поиска, при этом по меньшей мере часть информации о местоположении выражена в виде значения заранее заданного кода, поиска на основе индекса метаданных ключа, соответствующего упомянутому значению заранее заданного кода, и извлечения фрагмента метаданных путем использования найденного ключа.10. Устройство по п.9, в котором информация о местоположении содержит информацию о местоположении фрагмента метаданных, включающего в себя ключ, и информацию о местоположении ключа в этом фрагменте.11. Устройство по п.10, в котором одна из информаций о местоположении фрагмента и информаций о местоположении ключа выражена в виде значения заранее заданного кода.12. Устройство по п.11, в котором оставшаяся из информаций о местоположении фрагмента и информаций о местоположении ключа выражена в виде значения другого заранее заданного кода или Xpath.13. Устройство по п.11, в котором значение заранее заданного кода содержит Xpath в качестве дополнительной информации, при этом соответствующий фрагмент/ключ соответствует типу, определенному пользователем.14. Устройство по п.9, в котором блок управления выполнен с возможностью осуществления поиска значения ключа, удовлетворяющего условию поиска, среди значений ключа из индекса, и извлечения идентификационной информации фрагмента метаданных, соответствующего значению ключа.15. Устройство по п.14, в котором в качестве реакции на множество значений ключа, удовлетворяющих условию поиска, блок управления выполнен с возможностью извлечения тех фрагментов метаданных, которые соответствуют значениям ключа, удовлетворяющим условию поиска.16. Устройство по п.14, в котором блок управления выполнен с возможностью осуществления поиска репрезентативного значения ключа, удовлетворяющего условию поиска, среди репрезентативных значений ключа индекса, соответствующих диапазонам значений ключа, и поиск значения в диапазоне значений, соответствующем репрезентативному значению ключа.17. Устройство по п.9, дополнительно содержащее приемный блок, выполненный с возможностью приема метаданных, блок хранения данных, выполненный с возможностью сохранения в нем принятых метаданных, и блок вывода, выполненный с возможностью вывода результатов поиска, проведенного блоком управления.18. Устройство по п.9, в котором метаданные имеют структуру метаданных, определенную организацией TV-Anytime Forum.19. Устройство по п.9, в котором индекс содержит секцию списка индексов ключей, содержащую список, секцию субиндекса ключа, содержащую диапазоны значений ключа и идентификационную информацию тех фрагментов метаданных, которые соответствуют упомянутым значениям ключа, и секцию индекса ключа, содержащую репрезентативные значения ключа, представляющие соответствующие диапазоны значений ключа.20. Устройство для поиска разделенных на фрагменты метаданных, содержащее блок ввода, выполненный с возможностью приема условия поиска по меньшей мере одного ключа метаданных, и блок управления, выполненный с возможностью выбора из списка, содержащего множество комбинаций информации о местоположении фрагмента и информации о местоположении, определяющей по меньшей мере один ключ в этом фрагменте, той комбинации, которая соответствует условию поиска, при этом одна из информации о местоположении фрагмента и информации о местоположении, определяющей по меньшей мере один ключ, выражена в виде заранее заданного кода, определения идентификационной информации метаданных, идентифицируемых найденной комбинацией, на основе заранее заданного кода, соответствующего этой комбинации, и извлечения одного или более фрагментов метаданных, соответствующих упомянутой идентификационной информации.21. Устройство по п.20, в котором оставшаяся информация о местоположении выражена в виде другого заранее заданного кода или Xpath.