Как Google объединял локальные результаты (файлы, email) с веб-результатами на стороне клиента (Google Desktop)

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

Article Type (Тип статьи)

Классификация контента, основанная на формате данных. Примеры: Email, File (текстовый документ, PDF, аудио, видео), Chat message, Web page. Используется для организации отображения результатов.

Client Device (Клиентское устройство)

Устройство пользователя (ПК), на котором выполняется локальная индексация, перехват запроса и генерация объединенного интерфейса.

Global Index (Глобальный индекс)

Удаленный индекс, не специфичный для конкретного пользователя (например, основной веб-индекс Google).

Local Index (Локальный индекс)

Индекс данных, специфичных для пользователя или клиентского устройства (личные файлы, email, история чатов). Хранится локально.

Spatially Segregated Sections (Пространственно разделенные разделы)

Отдельные визуальные блоки в пользовательском интерфейсе, используемые для отображения результатов разных Article Types (как показано на FIG. 3 патента).

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

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

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

1. Генерация и хранение Local Index на клиенте, содержащего статьи различных типов (Article Types).
2. Выполнение поискового запроса по Local Index на клиенте, получение первого набора результатов.
3. Получение на клиенте второго набора результатов от удаленной поисковой системы (Global Index).
4. Получение от пользователя параметров отображения (user-defined display parameters), включая выбор Article Types для показа.
5. Генерация пользовательского интерфейса на основе выбранных типов. Интерфейс включает несколько Spatially Segregated Sections, каждый из которых ассоциирован с одним из выбранных типов статей.
6. Отображение первого и второго наборов результатов, причем статьи из первого (локального) набора распределяются по соответствующим разделам согласно их Article Type.

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

Claim 19 (Независимый пункт): Альтернативное описание процесса с фокусом на инициацию поиска.

1. Генерация Local Index.
2. Идентификация глобального запроса (Global Query), направленного к удаленной системе.
3. Выполнение локального запроса (Local Query) на клиенте, основанного на глобальном запросе.
4. (Далее повторяются шаги из Claim 1: получение результатов, настроек пользователя, генерация интерфейса с Spatially Segregated Sections и отображение результатов по разделам).

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

Claim 21 (Зависимый от 19): Вводит механизм тайм-аута: игнорирование результатов из Local Index, если они не получены в течение определенного времени после получения результатов из Global Index. Это делается для минимизации задержек для пользователя.

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

Важно понимать, что этот патент НЕ применяется в стандартной серверной архитектуре веб-поиска Google. Он описывает работу отдельного продукта — Google Desktop Search или аналогичного клиентского программного обеспечения.

CRAWLING & INDEXING (Локальные)
Клиентское приложение сканирует локальные ресурсы пользователя (файлы, почтовые ящики, историю чатов) и создает Local Index, который хранится на Client Device. Это не связано с Googlebot.

Q. UNDERSTANDING (Локальное)
Система на клиенте (реализованная как Browser Plug-in, Proxy Server или Firewall) перехватывает поисковый запрос пользователя.

RANKING (Параллельное)
Запрос обрабатывается и отправляется как в Global Index, так и выполняется по Local Index. Ранжирование происходит независимо в каждом индексе. Патент указывает (Claim 20), что запросы могут выполняться параллельно.

METASEARCH & BLENDING (Локальное)
Основной этап применения патента. Клиентское приложение получает Result Sets из обоих источников. Оно выполняет их объединение (Blending). Ключевой механизм — классификация локальных результатов по Article Types и генерация интерфейса с Spatially Segregated Sections для их отображения.

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

• Поисковый запрос пользователя.
• Local Index.
• Результаты (HTML или XML), полученные от Global Index.
• Пользовательские настройки отображения (выбранные Article Types).

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

• Пользовательский интерфейс (обычно HTML-страница), отображающий объединенные результаты, сегментированные по типам контента.

На что влияет

• Типы контента: Влияет на отображение всех типов локального контента (Email, Files, Chat) совместно с веб-результатами в рамках специализированного клиентского ПО.
• Влияние на веб-поиск: Не влияет на ранжирование, индексирование или отображение сайтов в основном поиске Google (google.com) для широкой аудитории.

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

• Условия работы: Алгоритм применяется только в том случае, если у пользователя установлено и активно соответствующее клиентское программное обеспечение (например, Google Desktop).
• Триггеры активации: Перехват поискового запроса, инициированного пользователем и направленного к Global Index.
• Ограничения: Если локальный поиск занимает слишком много времени, его результаты могут быть проигнорированы (согласно Claim 21), чтобы не задерживать отображение глобальных результатов.

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

1. Перехват запроса: Система на клиентском устройстве (например, плагин браузера) получает или перехватывает поисковый запрос пользователя.
2. Параллельное выполнение поиска: Запрос передается в удаленный Global Index. Одновременно инициируется поиск по локальному Local Index.
3. Получение локальных результатов: Система получает первый набор результатов из Local Index, который может включать разные типы статей (Email, Files, Chat).
4. Получение глобальных результатов: Система получает второй набор результатов (веб-страницы) из Global Index.
5. Обработка тайм-аутов и Кэширование: Если один из поисков завершается раньше другого, система может кэшировать результаты. Если локальный поиск не завершен в течение заданного тайм-аута после получения глобальных результатов, он может быть прерван.
6. Обработка настроек пользователя: Система определяет, какие Article Types пользователь сконфигурировал для отображения.
7. Генерация интерфейса и Объединение: Система генерирует пользовательский интерфейс (например, модифицирует HTML-страницу, полученную от глобального поиска).
8. Сегментация по типам: Интерфейс конструируется с использованием Spatially Segregated Sections для каждого выбранного типа контента. Глобальные результаты помещаются в соответствующий раздел, а локальные результаты распределяются по своим разделам согласно их Article Type.
9. Отображение: Сгенерированный интерфейс отображается пользователю.

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

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

Патент фокусируется на инфраструктуре объединения и типах данных, а не на факторах ранжирования.

• Контентные и Мультимедиа факторы (Локальные): Содержимое локальных ресурсов. Патент явно упоминает текстовые файлы, электронные письма, сообщения чатов, PDF, аудиофайлы, видеофайлы и веб-страницы. Эти данные используются для индексации в Local Index.
• Структурные факторы (Локальные): Метаданные файлов и сообщений. Упоминается использование этих данных для формирования потоков сообщений (Email threads, Chat threads).
• Пользовательские факторы: Явно используются настройки пользователя (user-defined display parameters) относительно того, какие Article Types отображать в интерфейсе.

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

• В патенте не описаны конкретные метрики, формулы расчета оценок или алгоритмы ранжирования для локального или глобального индекса.
• Ранжирование объединенного списка: Упоминается возможность использования некой меры ранжирования (ranking measure) для сортировки, если результаты смешиваются в единый список (Claim 6).
• Взвешивание по индексу: Описана возможность взвешивания результатов в зависимости от источника. Например, результаты из Local Index могут быть взвешены выше, чем результаты из Global Index.
• Основной описанный механизм обработки результатов — это классификация по Article Type и отображение в соответствующих сегментированных разделах.

1. Патент описывает инфраструктуру клиентского приложения (Google Desktop) без прямых рекомендаций для SEO.
2. Унификация поиска на клиенте: Основная идея патента — создание механизма для объединения результатов из разнородных индексов (локального и глобального) непосредственно на устройстве пользователя.
3. Сегментация по типу контента как ключевой элемент: Изобретение акцентирует внимание на разделении результатов по типам (Article Types — Email, Files, Web) и их отображении в отдельных визуальных блоках (Spatially Segregated Sections), как описано в Claims 1 и 19.
4. Оптимизация производительности: Система включает механизмы для минимизации задержек, такие как параллельное выполнение запросов и тайм-ауты для локального поиска (Claim 21).
5. Отсутствие влияния на веб-ранжирование: Патент не содержит информации об алгоритмах, используемых Google для ранжирования веб-сайтов в основном поиске. Он полностью сфокусирован на пользовательском опыте в рамках специализированного, ныне устаревшего ПО.

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

Патент является инфраструктурным, описывает устаревший продукт (Google Desktop) и не дает практических выводов для современного SEO. Информация для применения в SEO отсутствует.

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

Информация отсутствует. Патент не направлен против каких-либо SEO-манипуляций и не описывает факторов ранжирования веб-сайтов.

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

Стратегическое значение для SEO отсутствует. Патент представляет исключительно исторический интерес, демонстрируя ранние попытки Google создать унифицированный поиск, объединяющий личные данные пользователя и веб-контент в рамках продукта Google Desktop Search.

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

Практических примеров для SEO нет, так как патент не связан с оптимизацией веб-сайтов или ранжированием в основном поиске Google.

Ниже приведен пример того, как функционировала система, описанная в патенте:

Сценарий: Использование Google Desktop

1. Установка: Пользователь установил ПО Google Desktop, которое проиндексировало его локальные файлы и почту.
2. Запрос: Пользователь вводит запрос "digital camera" в браузере на сайте Google.
3. Перехват и Параллельный поиск: Google Desktop перехватывает запрос, ищет локально и одновременно получает результаты из веб-поиска.
4. Результат: Пользователь видит единую страницу выдачи. На ней есть стандартные веб-результаты, а также отдельные блоки (Spatially Segregated Sections): блок "Email" с найденными письмами о камерах и блок "Files" с локальными документами, содержащими этот термин.