Как Google определяет важность локальных файлов для выборочного индексирования (в Desktop Search)

Описание

Какую задачу решает

Патент решает проблему неэффективности и ресурсоемкости приложений для локального поиска (Desktop Search). Индексирование всех файлов на клиентском устройстве может значительно снижать его производительность (нагрузка на CPU и диск) и занимать дисковое пространство для хранения индекса неважных файлов. Изобретение предлагает механизм для выборочной индексации только той информации, которая предположительно важна для пользователя, оптимизируя использование ресурсов.

Что запатентовано

Запатентована система и метод для выборочного сбора (capturing) и индексирования информации на клиентском устройстве. Суть изобретения заключается в вычислении Capture Score (Оценки Сбора) для каждого файла или события (Event). Эта оценка определяет предполагаемую важность информации на основе метаданных файла (Article Data). Система индексирует данные только в том случае, если Capture Score превышает определенный порог (Threshold Value).

Как это работает

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

• Анализ данных: Для каждого события система анализирует Article Data: расположение файла (например, папка «Мои документы» важнее системных папок), тип файла (например, .doc важнее .tmp) и данные доступа (как часто и как давно файл использовался).
• Расчет оценки: На основе этих факторов, с учетом присвоенных им весов (Weights), вычисляется Capture Score.
• Фильтрация: Если оценка превышает динамический или статический порог, информация собирается и передается локальному индексатору.

Актуальность для SEO

Низкая. Патент подан в 2004 году и описывает технологии для продуктов класса Desktop Search, таких как Google Desktop, поддержка которого была прекращена. Описанные методы относятся к оптимизации локального индексирования и не имеют отношения к современному веб-поиску Google.

Важность для SEO

Минимальное (1/10). Патент не имеет отношения к веб-поиску Google. Он описывает исключительно внутренние механизмы работы программного обеспечения для индексации локальных файлов на компьютере пользователя. Он не содержит информации об алгоритмах ранжирования веб-сайтов, механизмах сканирования интернета (Googlebot) или факторах, влияющих на позиции сайта в поисковой выдаче.

Детальный разбор

Термины и определения

Article (Файл/Документ)

Любой элемент информации на клиентском устройстве: документ, электронное письмо, веб-страница (в истории), мультимедиа файл и т.д.

Article Data (Данные о файле)

Метаданные, используемые для оценки важности файла. Включают расположение файла (Location), тип файла (File Type) и данные доступа (Access Data).

Access Data (Данные доступа)

Информация о взаимодействии пользователя с файлом, включающая давность (Recency) и частоту (Frequency) доступа.

Capture Processor (Процессор Сбора)

Компонент локального ПО, который идентифицирует события, вычисляет Capture Score и собирает данные для индексации.

Capture Score (Оценка Сбора)

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

Event (Событие)

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

Event Schema (Схема события)

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

Historical Event (Историческое событие)

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

Threshold Value (Пороговое значение)

Минимальный уровень Capture Score, необходимый для того, чтобы событие было собрано и проиндексировано.

Weights (Веса)

Значения, присваиваемые различным факторам (например, типу файла или расположению) для расчета Capture Score.

Ключевые утверждения (Анализ Claims)

Claim 1 (Независимый пункт): Описывает основной метод работы системы локального поиска.

1. Идентификация события (взаимодействие пользователя с файлом на клиентском устройстве).
2. Идентификация данных, связанных с файлом (Article Data).
3. Определение Capture Score для события. Этот процесс включает:
   • Заполнение полей схемы события (Event Schema).
   • Присвоение весов (weights) этим полям, где вес указывает на относительную важность поля.
   • Генерацию Capture Score на основе весов и содержимого заполненных полей.
4. Сбор данных о событии (Compiling event data), если Capture Score соответствует пороговому значению (Threshold Value). Пороговое значение определяется на основе поведения пользователя (User Behavior).

Claim 2, 6, 9 (Зависимые): Уточняют состав Article Data.

• Claim 2: Расположение файла (Location).
• Claim 6: Тип файла (File Type).
• Claim 9: Данные доступа (Access Data), включая давность (Claim 10) и частоту (Claim 11).

Claim 3, 7 (Зависимые): Уточняют, что Capture Score определяется путем присвоения весов расположению или типу файла.

Claim 4, 8, 13 (Зависимые): Указывают, что веса, используемые для расчета Capture Score, могут определяться на основе поведения пользователя.

Где и как применяется

ВАЖНОЕ УТОЧНЕНИЕ: Этот патент не описывает работу веб-поиска Google. Он описывает исключительно работу локального программного обеспечения (например, Google Desktop) на устройстве пользователя. Применение к 6-этапной архитектуре веб-поиска невозможно.

В контексте локального поиска система применяется следующим образом:

• CRAWLING (Локальное сканирование и Сбор данных): Capture Processor мониторит активность пользователя (Real-time Events) и периодически сканирует файловую систему (Historical Events).
• INDEXING (Локальное индексирование): Ключевой этап применения патента. Система использует расчет Capture Score для фильтрации данных до фактического индексирования. Это позволяет решить, стоит ли тратить ресурсы на обработку данного файла.

Входные данные:

• Файлы, хранящиеся на локальных дисках.
• Метаданные файлов (Article Data): путь, расширение (тип), даты создания/изменения/доступа.
• Данные о поведении пользователя (для настройки весов и порогов).

Выходные данные:

• Собранные данные о событии (Event Data), переданные в очередь для индексации (если Capture Score выше порога).

На что влияет

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

• Конкретные типы контента: Влияет на все типы локальных файлов. Система может предпочитать определенные типы (например, .doc, .pdf) другим (например, .tmp, .log) за счет разных весов при расчете Capture Score.
• Структура хранения: Расположение файла критично. Файлы в пользовательских директориях имеют больший шанс быть проиндексированными, чем системные файлы.

Когда применяется

• Триггеры активации:
  • Обнаружение нового или измененного файла при сканировании диска (Historical Event).
  • Фиксация действия пользователя в приложении (Real-time Event).
• Пороговые значения: Ключевым порогом является Threshold Value. Только события с Capture Score выше этого порога обрабатываются. Порог может быть статическим или динамическим (адаптирующимся под средние значения Capture Score или поведение пользователя).

Пошаговый алгоритм

Процесс выборочного сбора информации (на основе FIG. 3):

1. Идентификация события: Capture Processor обнаруживает событие, связанное с файлом.
2. Определение данных о файле (Article Data): Система извлекает метаданные: расположение файла, тип файла, частоту и давность доступа.
3. Предварительная фильтрация (Опционально): Система может проверить файл на соответствие стоп-критериям (например, файл старше определенного срока) и прекратить обработку до расчета оценки.
4. Вычисление Capture Score:
   • Система применяет весовые коэффициенты к полученным данным. Веса определяются на основе предполагаемой важности и могут корректироваться поведением пользователя.
   • Capture Score рассчитывается как комбинация этих весов (например, путем перемножения).
5. Сравнение с порогом: Полученный Capture Score сравнивается с Threshold Value.
6. Принятие решения:
   • Если оценка ниже порога: событие игнорируется (Do Not Capture).
   • Если оценка выше порога: переход к шагу 7.
7. Сбор данных и Индексация: Система компилирует данные о событии (Compile Event Data) и передает их локальному индексатору (Indexer).

Какие данные и как использует

Данные на входе

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

• Технические факторы:
  • Расположение файла (Location): Путь к файлу на диске. Файлы в пользовательских папках считаются более важными, чем в системных.
  • Тип файла (File Type): Расширение файла. Документы и медиафайлы считаются более важными, чем временные или лог-файлы.
• Временные и Поведенческие факторы (Access Data):
  • Давность доступа (Recency): Время последнего доступа к файлу. Недавние файлы считаются более важными.
  • Частота доступа (Frequency): Как часто пользователь взаимодействует с файлом. Часто используемые файлы считаются более важными.
• Пользовательские факторы (User Behavior): История поведения пользователя используется для калибровки системы (настройки весов и порогов).

Какие метрики используются и как они считаются

• Capture Score: Основная метрика важности. Рассчитывается путем комбинирования весов, присвоенных различным Article Data. В одном из вариантов реализации предлагается начать с базовой оценки 1 и умножать ее на веса различных факторов (вес > 1 увеличивает важность, вес < 1 уменьшает).
• Weights (Веса): Коэффициенты, присваиваемые различным факторам. Могут быть предопределены или рассчитываться на основе поведения пользователя.
• Threshold Value (Пороговое значение): Значение, с которым сравнивается Capture Score. Может быть адаптивным. В патенте упоминается возможность расчета порога на основе среднего значения (Average) и стандартного отклонения (Standard Deviation) оценок Capture Score для уже обработанных событий, возможно, отдельно для разных типов событий.

Выводы

1. Патент относится исключительно к локальному поиску: Изобретение описывает инфраструктуру и методы оптимизации для продуктов класса Desktop Search (например, Google Desktop). Оно не имеет отношения к алгоритмам веб-поиска Google.
2. Цель — оптимизация ресурсов клиентского устройства: Основная задача системы — снизить нагрузку на компьютер пользователя и сэкономить место на диске, избегая индексации неважной информации.
3. Интеллектуальная фильтрация перед индексацией: Ключевым механизмом является Capture Score — система пытается оценить важность файла до того, как потратить ресурсы на его индексацию.
4. Определение важности по метаданным: Важность определяется на основе простых метаданных: где файл хранится (Location), что это за файл (File Type) и как часто он используется (Access Data).
5. Адаптивность к поведению пользователя: Патент предусматривает возможность настройки как весов, так и порогового значения на основе анализа локального поведения пользователя.
6. Отсутствие практической ценности для SEO: Для специалистов, занимающихся оптимизацией веб-сайтов (SEO), этот патент не предоставляет никаких практических выводов или стратегических инсайтов.

Практика

ВАЖНО: Патент является инфраструктурным, относится исключительно к локальному поиску (Desktop Search) и не дает никаких практических выводов или рекомендаций для SEO-специалистов, занимающихся оптимизацией сайтов для веб-поиска Google.

Best practices (это мы делаем)

В патенте нет информации, применимой к Best Practices в SEO.

Worst practices (это делать не надо)

В патенте нет информации, применимой к Worst Practices в SEO.

Стратегическое значение

Стратегическое значение для SEO отсутствует. Патент интересен исключительно с точки зрения истории развития поисковых продуктов Google и методов оптимизации локального поиска. Он не влияет на понимание приоритетов Google в веб-поиске.

Практические примеры

Практических примеров применения в SEO нет.

Пример работы локальной системы (не SEO):

1. Сценарий: Система локального поиска сканирует диск C:\.
2. Файл А: C:\Users\User\Documents\Project_Report.docx. Открывался сегодня.
3. Файл Б: C:\Windows\System32\config\software.log. Системный файл.
4. Расчет Capture Score для Файла А: Высокий вес за расположение (Documents) + Высокий вес за тип (.docx) + Высокий вес за давность доступа (сегодня) = Высокий Capture Score.
5. Расчет Capture Score для Файла Б: Низкий вес за расположение (Windows) + Низкий вес за тип (.log) = Низкий Capture Score.
6. Результат: Файл А будет проиндексирован, Файл Б будет проигнорирован для экономии ресурсов.

Вопросы и ответы