Как Google анализирует контент на экране мобильного устройства для распознавания сущностей и предложения контекстных действий (Google Lens/Screen Search)

Описание

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

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

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

Запатентована система (лежащая в основе технологий типа Google Lens, Circle to Search, Google Assistant Screen Context), которая анализирует данные с вводных устройств мобильного устройства (включая экран и камеру) для идентификации сущностей (entities). Система определяет наиболее релевантную сущность (Entity of Interest), оценивая их на основе истории поисковых запросов (пользователя или глобальной). Для выбранной сущности система предоставляет атрибуты (факты) и релевантные действия в виде Action Cards.

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

Система работает следующим образом:

• Сбор данных: Система захватывает контент с экрана (Screen Capture) или получает данные с других вводных устройств (например, камеры).
• Распознавание и Извлечение: Выполняется распознавание контента (OCR, распознавание изображений) и извлечение сущностей (Entity Extraction) с использованием NLP и сопоставления с Data Graph (Knowledge Graph) или контактами пользователя.
• Оценка и Ранжирование: Идентифицированные сущности ранжируются (Entity Ranking). Оценка базируется на источнике (контакты пользователя получают приоритет) и популярности запросов о сущности (user query data или global query data).
• Определение Атрибутов и Действий: Для топовых сущностей запрашивается информация у поисковой системы. Используются данные из Data Graph (Knowledge Panel) и журналы поиска (Search Logs) для определения того, какую информацию пользователи запрашивали ранее об этой сущности.
• Генерация и Отображение: Создаются Action Cards, содержащие факты и предлагаемые действия (например, звонок, маршрут, Deep Link в приложение), которые отображаются пользователю.

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

Высокая. Описанные технологии являются фундаментальными для современных функций Google, таких как Google Lens и Circle to Search (Обвести и найти). Контекстный и визуальный поиск, а также интеграция сущностей из Knowledge Graph в пользовательский интерфейс являются ключевыми направлениями развития поиска, особенно на мобильных устройствах.

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

Патент имеет высокое стратегическое значение (75/100) для понимания развития Google в области контекстного и проактивного поиска (Zero-Query Search). Хотя он не описывает алгоритмы ранжирования веб-страниц, он критически важен для оптимизации видимости бизнеса за пределами традиционной выдачи. Он подчеркивает абсолютную необходимость оптимизации сущностей (Entity Optimization) и надежного присутствия в Data Graph (Knowledge Graph), поскольку именно эти данные используются для генерации информации и действий, предлагаемых пользователю.

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

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

Action Card (Карточка действия)

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

Action Card Engine (Движок карточек действий)

Компонент системы, отвечающий за генерацию Action Cards на основе результатов поиска и типа сущности.

Automatic Action App (Приложение автоматических действий)

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

Data Graph (Граф данных / Knowledge Graph)

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

Deep Link (Глубокая ссылка)

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

Entity (Сущность)

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

Entity Extraction Engine (Движок извлечения сущностей)

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

Entity of Interest (Интересующая сущность)

Сущность, выбранная системой как наиболее релевантная для пользователя в данном контексте, обычно на основе наивысшей оценки (score).

Entity Ranking Engine (Движок ранжирования сущностей)

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

Global Query Data (Глобальные данные о запросах)

История поисковых запросов, связанных с сущностью, от множества пользователей (популярность запроса).

Knowledge Panel (Панель знаний)

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

Search Logs / Search Records (Журналы поиска)

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

User Query Data (Пользовательские данные о запросах)

История поисковых запросов конкретного пользователя устройства.

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

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

Claim 1 (Независимый пункт, Система): Описывает систему идентификации сущностей из данных вводных устройств.

1. Система получает данные от множества вводных устройств (экран, камера, GPS и т.д.).
2. Идентифицирует множество сущностей из этих данных.
3. Определяет Entity of Interest путем оценки (scoring) каждой сущности и выбора сущности с наивысшей оценкой.
4. Ключевой механизм оценки: Оценка основана на user query data (история запросов пользователя) ИЛИ global query data (история запросов других пользователей).
5. Определяет атрибуты (описательную информацию) для Entity of Interest.
6. Отображает сущность и ее атрибуты на устройстве.

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

Claim 18 (Независимый пункт, Метод): Описывает метод использования журналов поиска для наполнения карточек действий.

1. Идентификация сущностей из данных, сгенерированных для презентации пользователю (например, контент экрана).
2. Выбор первой Entity of Interest.
3. Запрос к search log (журналу поиска) интернет-поисковика по этой сущности.
4. Идентификация в результатах информации, которую ранее запрашивали об этой сущности другие пользователи.
5. Генерация Action Card, включающей эту ранее запрошенную (т.е. популярную) информацию.
6. Предоставление Action Card для отображения.

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

Claim 24 (Независимый пункт, Метод): Описывает метод использования фактов из поисковой системы.

1. Идентификация сущностей.
2. Выбор первой Entity of Interest.
3. Запрос к поисковой системе по этой сущности, получение результатов, включающих факты о сущности (вероятно, из Data Graph).
4. Генерация Action Card, включающей эти факты.
5. Отображение Action Card.

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

Это изобретение описывает технологию на уровне приложения (Application Layer), такую как Google Lens или Google Assistant, а не традиционный процесс веб-ранжирования. Однако оно интенсивно использует инфраструктуру и данные Google Поиска.

INDEXING – Индексирование и извлечение признаков
Система полагается на данные, собранные и структурированные на этом этапе:

• Data Graph (Knowledge Graph): Необходим для распознавания сущностей и извлечения фактов/атрибутов.
• Document Collection (Индекс документов): Используется для предоставления ссылок и сниппетов.
• Search Records (Журналы поиска): Необходимы для определения популярности сущностей и часто запрашиваемой информации.

RANKING – Ранжирование (В контексте приложения)
Когда приложение активируется, оно выполняет два типа ранжирования:

1. Ранжирование Сущностей (Entity Ranking): Локальный процесс определения Entity of Interest среди всех сущностей на экране.
2. Запрос Информации: Использование основной поисковой системы (Search Engine) для получения информации о сущностях (где применяется стандартное ранжирование результатов поиска).

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

• Данные с вводных устройств (содержимое экрана, изображение с камеры, данные GPS).
• Метаданные устройства (время, активное приложение).
• Данные пользователя (Контакты, User Query Data).
• Глобальные данные (Data Graph, Global Query Data).

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

• Action Cards с атрибутами (фактами) и предлагаемыми действиями (ссылки, звонки, маршруты, Deep Links).

На что влияет

• Конкретные типы контента: Влияет на любой контент, содержащий распознаваемые сущности – текст (статьи, чаты) и изображения (фотографии, постеры).
• Специфические запросы: Это система проактивного контекстного поиска (Zero-Query Search). Она предвосхищает информационные или транзакционные потребности пользователя, возникающие в контексте просмотра контента.
• Конкретные ниши или тематики: Особенно сильно влияет на локальный бизнес, медиа (фильмы, музыка), события и продукты, так как для них часто существуют четко определенные действия (позвонить, купить билет, посмотреть трейлер).
• App SEO (ASO): Значительно влияет на вовлеченность мобильных приложений, так как система активно продвигает действия через Deep Links.

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

• Триггеры активации: Система активируется по явному действию пользователя (например, свайп, нажатие кнопки, активация Google Lens или Circle to Search).
• Условия работы: Применяется при наличии распознаваемого контента на экране или в поле зрения камеры и возможности идентификации сущностей, для которых существуют релевантные данные в Data Graph или контактах пользователя.

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

Процесс А: Идентификация и Ранжирование Сущностей

1. Захват контента: Screen Capture Engine захватывает контент текущего экрана или данные с вводных устройств (например, камеры).
2. Извлечение сущностей: Entity Extraction Engine выполняет распознавание (OCR, изображения) и идентифицирует сущности (используя NLP, сопоставление с Data Graph и контактами).
3. Запрос информации: Для каждой сущности формируется запрос в поисковую систему и локальные хранилища (с использованием контекста, например, местоположения).
4. Получение результатов: Система получает результаты: данные из контактов, Knowledge Panel (из Data Graph), ссылки на документы и метаданные о популярности запроса.
5. Ранжирование сущностей (Entity Ranking): Entity Ranking Engine ранжирует сущности на основе:
   • Источника результатов (контакты пользователя получают буст).
   • Частоты взаимодействия пользователя с контактом.
   • Наличия данных из Data Graph.
   • Популярности запроса (на основе User/Global Query Data).
   • Визуальной представленности на экране (размер шрифта, расположение).
6. Выбор сущностей: Выбираются сущности с наивысшим рейтингом (Entities of Interest).

Процесс Б: Генерация Карточек Действий (Action Cards)

1. Определение типа сущности: Система определяет, является ли сущность контактом или общей сущностью.
2. Извлечение действий для контактов: Если это контакт, система извлекает информацию (телефон, email) из хранилища контактов для генерации действий.
3. Извлечение действий из Knowledge Panel: Система анализирует Knowledge Panel. Извлекаются действия (например, звонок, маршрут) и текстовые сниппеты. Информация может выбираться на основе того, что пользователи чаще всего запрашивали ранее (Claim 18).
4. Анализ ссылок и Deep Linking: Система извлекает ссылки из результатов поиска и проверяет, соответствует ли домен ссылки установленному мобильному приложению.
   • Если ДА: Генерируется Deep Link.
   • Если НЕТ: Используется ссылка для открытия в браузере.
5. Генерация и отображение: Action Card Engine генерирует Action Card с выбранными действиями и информацией и отображает карточки пользователю.

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

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

• Контентные факторы (с экрана/камеры): Текст, изображения, логотипы, визуальное расположение элементов, размер шрифта.
• Технические факторы (метаданные): Активное приложение, тип мобильного устройства, данные доступности (accessibility data).
• Поведенческие факторы (История): User Query Data (история запросов пользователя). Global Query Data (глобальная история запросов). Частота взаимодействия пользователя с контактами.
• Географические факторы: Текущее местоположение мобильного устройства (используется как контекст).
• Данные из Баз Знаний: Data Graph (Knowledge Graph). Document Collection (веб-индекс). Search Logs.
• Пользовательские данные: Contacts Data Store (контакты). Список установленных приложений (для Deep Linking).

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

Система использует оценку (Score) для определения Entity of Interest. Конкретные формулы не приведены, но указаны ключевые факторы:

• Популярность запроса (Query Popularity): Оценка основана на user query data или global query data (Claims 1, 9). Сущности, о которых часто спрашивают, получают более высокий рейтинг.
• Источник данных (Source): Сущности, найденные в Contacts Data Store пользователя, получают значительный буст.
• Частота взаимодействия (Frequency of Interaction): Для контактов учитывается, как часто пользователь взаимодействует с ними. Более частые контакты ранжируются выше.
• Наличие Knowledge Panel: Сущности с хорошо структурированными данными из Data Graph могут получать буст.
• Визуальная значимость (Visual Prominence): Учитывается расположение и оформление сущности на экране.

Также используются метрики для определения содержимого Action Card:

• Ранее запрошенная информация (Previously Requested Information): Определяется путем анализа Search Logs (Claim 18). Информация, которую часто ищут пользователи об этой сущности, включается в карточку.

Выводы

1. Оптимизация Сущностей (Entity Optimization) — это фундамент контекстного поиска: Патент подтверждает, что системы типа Google Lens полагаются на способность Google извлекать структурированные данные из Data Graph (Knowledge Graph). Видимость бизнеса в этом интерфейсе напрямую зависит от качества его представления в KG.
2. Поисковый спрос определяет, ЧТО будет показано и КАК ранжироваться: Система явно использует историю поисковых запросов (User/Global Query Data и Search Logs) для двух целей: (1) определения наиболее важной сущности на экране (Claims 1, 9) и (2) определения того, какие факты и действия показать об этой сущности (Claim 18). Показывается то, что пользователи чаще всего ищут.
3. Факты и Действия важнее ссылок: Цель системы — предоставить пользователю Action Cards с фактами (Claim 24) и возможностью совершить действие (звонок, маршрут). Это снижает зависимость от перехода на веб-сайты для получения базовой информации.
4. Deep Linking как предпочтительное действие: Система активно ищет возможность связать сущность с установленным мобильным приложением через Deep Link, предпочитая это открытию веб-страницы в браузере, что критично для App SEO.
5. Персонализация имеет приоритет: Сущностям, найденным в личных контактах пользователя или в его истории поиска, отдается наивысший приоритет при ранжировании.

Практика

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

• Комплексная оптимизация сущностей и присутствие в Knowledge Graph: Необходимо обеспечить, чтобы ключевые сущности бизнеса (бренд, продукты, локации) были точно и полно представлены в Data Graph. Это включает использование структурированных данных (Schema.org), оптимизацию Google Business Profile (GBP) и работу над авторитетностью ресурса.
• Ориентация на удовлетворение интента вокруг сущности: Анализируйте поисковый спрос (Global Query Data), связанный с вашими сущностями. Убедитесь, что информация, которую пользователи ищут чаще всего (адрес, телефон, отзывы, ключевые характеристики), доступна Google для формирования Knowledge Panel и Action Cards (Claim 18).
• Обеспечение консистентности NAP (Name, Address, Phone): Критически важно для локального бизнеса. Точная контактная информация необходима для корректной работы действий «Позвонить» и «Маршрут», генерируемых системой на основе данных из GBP/Data Graph.
• Внедрение Deep Linking (для владельцев приложений): Если у бизнеса есть мобильное приложение, необходимо настроить Deep Linking (например, через App Indexing/Firebase). Это позволит системе направлять пользователей с Action Card напрямую в приложение, минуя веб-сайт.
• Оптимизация визуального контента (для Google Lens): Создавайте четкие, высококачественные изображения продуктов, логотипов и локаций. Это повышает вероятность корректного распознавания сущностей через камеру или анализ экрана системами визуального поиска.

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

• Игнорирование Knowledge Graph и Schema.org: Рассчитывать только на традиционное ранжирование веб-страниц. В контекстном поиске такие сайты будут невидимы, так как система не сможет извлечь структурированные данные о сущности.
• Предоставление противоречивой информации: Публикация разных адресов или телефонов на разных площадках. Это может привести к ошибкам в Data Graph и некорректной работе Action Cards.
• Отсутствие интеграции с мобильной экосистемой: Разработка приложения без поддержки Deep Links. Это лишает бизнес возможности бесшовного взаимодействия с пользователем через контекстные интерфейсы.

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

Этот патент демонстрирует стратегию Google по созданию проактивного, контекстного и визуального поиска, который не требует от пользователя ввода запроса (Zero-Query Search). Для SEO это означает смещение фокуса с оптимизации отдельных страниц на оптимизацию сущностей и их атрибутов в базе знаний Google. Стратегически важно стать надежным источником данных для Data Graph, чтобы обеспечить видимость бренда, когда пользователи взаимодействуют с релевантным контентом на своих устройствах.

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

Сценарий: Оптимизация ресторана для контекстного поиска (Google Lens/Screen Search)

1. Задача: Увеличить количество бронирований от пользователей, которые видят упоминание ресторана на своем телефоне (в чате, статье или через камеру).
2. Действия по патенту:
   • Оптимизация Сущности: Убедиться, что ресторан корректно представлен в Knowledge Graph. Активно управлять Google Business Profile, поддерживая актуальность NAP и часов работы.
   • Удовлетворение Спроса (Claim 18): Проанализировать, что пользователи ищут о ресторане (меню, отзывы, бронирование).
   • Структурирование данных: Разметить меню на сайте с помощью Schema.org. Интегрироваться с сервисами бронирования, которые поддерживаются Google.
   • Deep Linking: Настроить Deep Link на страницу бронирования в приложении ресторана (если оно есть) или обеспечить корректную работу ссылок на сервис бронирования.
3. Ожидаемый результат: Когда пользователь активирует Google Lens/Screen Search на контенте с упоминанием ресторана, система распознает сущность. Так как сущность популярна (Global Query Data) и хорошо структурирована, она выбирается как Entity of Interest. Система генерирует Action Card с действиями «Позвонить» (используя номер из GBP), «Маршрут» (используя адрес из GBP), и «Забронировать» (используя интеграцию или Deep Link). Пользователь совершает действие в один клик.

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