KR20230124884A - 원격 시스템 업데이트를 사용하는 온디바이스 기능 - Google Patents

Abstract

사용자 디바이스는 초기 검색 레코드 및 초기 검색 기능을 포함하는 로컬 애플리케이션을 저장한다. 각 초기 검색 레코드에는 애플리케이션 페이지를 여는 애플리케이션 링크와 애플리케이션 페이지를 설명하는 검색 데이터가 포함된다. 초기 검색 기능은 초기 검색 레코드에서 선택하도록 구성된다. 사용자 디바이스는 원격 시스템에서 검색 업데이트 데이터를 요청하고 수신하기 위해 로컬 애플리케이션을 실행한다. 검색 업데이트 데이터는 업데이트된 검색 레코드 및 업데이트된 검색 기능을 포함한다. 사용자 디바이스는 업데이트된 검색 레코드 및 업데이트된 검색 기능으로 초기 검색 레코드 및 초기 검색 기능을 업데이트한다. 사용자 디바이스는 요청 애플리케이션으로부터 검색 질의를 수신하고, 검색 질의 및 업데이트된 검색 기능에 기초하여 업데이트된 검색 레코드 세트를 선택하고, 업데이트된 검색 레코드 세트로부터의 애플리케이션 링크를 포함하는 요청 애플리케이션에 대한 응답을 제공한다.

Description

원격 시스템 업데이트를 사용하는 온디바이스 기능

관련 출원에 대한 상호 참조

본 출원은 2020년 8월 17일에 출원된 미국 가출원(출원번호 63/066,576); 2020년 8월 20일에 출원된 미국 가출원(출원번호 63/068,118); 및 2021년 3월 16일에 출원된 미국 가출원(출원번호 63/161,541)의 우선권을 주장하며. 상기 각 출원의 전체 내용은 참조로서 본 명세서에 포함된다.

본 발명은 애플리케이션을 위한 검색 결과, 광고 및 기타 기능을 제공하는 것에 관한 발명이다.

소프트웨어 개발자는 다양한 컴퓨팅 디바이스들 및 운영 체제들과 같은 다양한 플랫폼에서 사용자들에 의해 액세스되는 웹사이트 및 애플리케이션을 개발할 수 있다. 웹사이트/애플리케이션의 일례는 전자상거래(e-commerce) 애플리케이션, 미디어 스트리밍 애플리케이션, 비즈니스 리뷰 애플리케이션, 소셜 미디어 애플리케이션 및 뉴스 애플리케이션을 포함할 수 있다. 웹사이트 및 애플리케이션 검색 엔진은 사용자를 위해 웹사이트 및 애플리케이션을 검색할 수 있다. 예를 들어, 사용자는 검색 엔진에 검색 질의를 입력하고 그리고 검색 엔진 결과 페이지(SERP: search engine results page)에서 검색 질의에 대한 웹 사이트 및 애플리케이션 검색 결과를 수신할 수 있다. 애플리케이션 개발자 및 기타 사업체와 같은 광고주는 다양한 컴퓨팅 플랫폼을 통해 SERP에서 자신의 애플리케이션/웹사이트, 서비스 및 기타 제품을 광고할 수 있다. 자신의 애플리케이션/웹사이트, 서비스 및 기타 제품을 효율적으로 광고하기 위해 광고주는 대상 청중에게 광고할 수 있다.

일 예에서, 사용자 디바이스는 메모리 및 프로세싱 유닛을 포함한다. 메모리는 초기 검색 레코드들 및 초기 검색 기능을 포함하는 로컬 서비스 모듈 애플리케이션을 저장한다. 각각의 초기 검색 레코드는 애플리케이션 페이지를 여는 애플리케이션 링크를 포함한다. 각각의 초기 검색 레코드는 초기 검색 레코드와 연관된 애플리케이션 페이지를 설명하는 검색 데이터를 포함한다. 초기 검색 기능은 초기 검색 레코드들 중에서 선택하도록 구성된다. 프로세싱 유닛은 로컬 서비스 모듈 애플리케이션을 실행하도록 구성된다. 로컬 서비스 모듈 애플리케이션의 실행은 상기 프로세싱 유닛으로 하여금 원격 시스템으로부터 검색 업데이트 데이터를 요청하게 하고 그리고 원격 시스템으로부터 검색 업데이트 데이터를 수신하게 하며, 상기 검색 업데이트 데이터는 업데이트된 검색 레코드 및 업데이트된 검색 레코드를 선택하기 위한 업데이트된 검색 기능을 포함한다. 로컬 서비스 모듈 애플리케이션의 실행은 상기 프로세싱 유닛으로 하여금 업데이트된 검색 레코드들 및 업데이트된 검색 기능으로 상기 초기 검색 레코드들 및 초기 검색 기능을 각각 업데이트하게 한다. 또한, 프로세싱 유닛은 사용자 디바이스에 설치된 요청 애플리케이션으로부터 검색 질의를 수신하고, 업데이트된 검색 기능에 따라 검색 질의에 기초하여 업데이트된 검색 레코드들의 세트를 선택하고, 및 검색 응답을 요청 애플리케이션에 제공한다. 검색 응답은 업데이트된 검색 레코드들의 선택된 세트로부터의 애플리케이션 링크를 포함한다.

일 예에서, 비일시적 컴퓨터 판독가능 매체는 사용자 디바이스의 프로세싱 유닛이 초기 검색 레코드 및 초기 검색 기능을 저장하게 하는 컴퓨터 실행가능 명령들을 포함한다. 각각의 초기 검색 레코드는 애플리케이션 페이지를 여는 애플리케이션 링크를 포함한다. 각각의 초기 검색 레코드는 초기 검색 레코드와 연관된 애플리케이션 페이지를 설명하는 검색 데이터를 포함한다. 상기 초기 검색 기능은 초기 검색 레코드들 중에서 선택하도록 구성된다. 프로세싱 유닛은 원격 시스템으로부터 검색 업데이트 데이터를 요청하고 그리고 원격 시스템으로부터 검색 업데이트 데이터를 수신하도록 구성된다. 상기 검색 업데이트 데이터는 업데이트된 검색 레코드 및 업데이트된 검색 레코드를 선택하기 위한 업데이트된 검색 기능을 포함한다. 프로세싱 유닛은 업데이트된 검색 레코드들 및 업데이트된 검색 기능으로 상기 초기 검색 레코드들 및 초기 검색 기능을 각각 업데이트하도록 구성된다. 프로세싱 유닛은 사용자 디바이스에 설치된 요청 애플리케이션으로부터 검색 질의를 수신하고, 업데이트된 검색 기능에 따라 검색 질의에 기초하여 업데이트된 검색 레코드들의 세트를 선택하고, 그리고 검색 응답을 요청 애플리케이션에 제공하도록 구성된다. 상기 검색 응답은 업데이트된 검색 레코드들의 선택된 세트로부터의 애플리케이션 링크를 포함한다.

본 발명은 상세한 설명 및 첨부된 도면으로부터 보다 완전하게 이해될 것이다.
도 1은 본 발명의 로컬 서비스 모듈을 실행하는 사용자 디바이스를 포함하는 환경을 도시한다.
도 2a-2b는 로컬 서비스 모듈의 예시적인 구현을 도시한다.
도 3은 로컬 서비스 모듈의 획득, 동작 및 업데이트를 설명하는 예시적인 방법을 도시한다.
도 4a-4b는 로컬 온-디바이스 검색 기능을 제공하는 로컬 서비스 모듈의 예시적인 구현을 도시한다.
도 5는 로컬 온-디바이스 검색 기능을 제공하는 로컬 서비스 모듈의 동작을 서술하는 예시적인 방법을 도시한다.
도 6은 예시적인 검색 레코드를 도시한다.
도 7은 온-디바이스 검색 기능을 제공하는 로컬 서비스 모듈을 포함하는 런처 애플리케이션의 동작을 설명하는 예시적인 방법을 도시한다.
도 8a-8b는 로컬 디바이스 광고 기능을 제공하는 로컬 서비스 모듈의 예시적인 구현을 도시한다.
도 9는 로컬 온-디바이스 광고 기능을 제공하는 로컬 서비스 모듈의 동작을 설명하는 예시적인 방법을 도시한다.
도 10은 예시적인 광고 레코드를 도시한다.
도 11은 로컬 온-디바이스 광고 기능을 제공하는 로컬 서비스 모듈의 동작을 설명하는 예시적인 방법을 도시한다.
도 12는 로컬 온-디바이스 검색 및 광고 기능을 제공하는 로컬 서비스 모듈의 동작을 설명하는 예시적인 방법을 도시한다.
도 13은 로컬 검색 기능, 광고 기능 및 추가 기능을 제공하는 로컬 서비스 모듈을 포함하는 예시적인 런처 애플리케이션을 도시한다.
도 14는 로컬 서비스 모듈에 대한 업데이트를 제공하는 예시적인 원격 서비스 시스템을 도시한다.
도 15는 로컬 서비스 모듈에 대한 예시적인 아키텍처의 기능 블록도이다.
도 16-17은 로컬 서비스 모듈을 포함하는 애플리케이션에 의해 생성될 수 있는 예시적인 그래픽 사용자 인터페이스(GUI)를 도시한다.
도 18은 로컬 서비스 모듈을 구현하는 사용자 디바이스 그룹과 통신하는 예시적인 원격 서비스 시스템을 도시한다.
도면에서 참조 번호들은 유사한 및/또는 동일한 요소들을 식별하기 위해 재사용될 수 있다.

도 1은 본 발명의 로컬 서비스 모듈(102-1)을 실행하는 사용자 디바이스(100)(예를 들어, 스마트폰)를 포함하는 환경을 도시한다. 복수의 예시적인 로컬 서비스 모듈이 여기에서 도시되고 설명된다. 로컬 서비스 모듈은 102-1, 102-2, … 102-9로 넘버링될 수 있으며, 일반적으로 로컬 서비스 모듈(102)로 지칭된다. 로컬 서비스 모듈(102)은 사용자 디바이스(100)를 위한 하나 이상의 로컬 기능들을 제공할 수 있다. 예를 들어 , 로컬 서비스 모듈(102)은 사용자 디바이스(100)에 설치된 애플리케이션을 위한 검색 기능, 광고 기능 및 기타 기능을 제공할 수 있다. 로컬 서비스 모듈(102)은 본원의 로컬 서비스 모듈(102)에 기인하는 다양한 기능들을 제공하는 복수의 모듈을 포함할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102)은 애플리케이션에 대한 검색 기능을 제공할 수 있다(예를 들어, 도 4a-7 참조). 일부 구현예에서, 로컬 서비스 모듈(102)은 애플리케이션을 위한 광고 기능을 제공할 수 있다(예를 들어, 도 8a-12 참조). 일부 구현예에서, 로컬 서비스 모듈(102)은 검색 광고 기능과 함께 검색 기능과 같이 여기에 설명된 기능의 조합을 제공할 수 있다(예를 들어, 도 13 참조). 여기에 설명된 추가적인 로컬 서비스 모듈 기능은 애플리케이션 의도 결과, 바로가기 결과(shortcut result), 제로 상태 기능(zero state functionality)(예: 제로 상태 링크 및/또는 질의 힌트) 및 자동제안을 포함할 수 있지만 이에 제한되지 않는다.

로컬 서비스 모듈(102)은 로컬 기능을 제공하기 위해 로컬 데이터(104-1)(일반적으로 "로컬 데이터(104)"라고 함)를 사용할 수 있다. 로컬 데이터(104)는 로컬 서비스 모듈(102)에 의해 제공되는 기능의 유형에 따라 달라질 수 있는 다양한 유형의 데이터를 포함할 수 있다. 예를 들어, 로컬 데이터(104)는 검색을 위해 이용되는 로컬 데이터, 가령 설치된 애플리케이션의 목록, 로컬 검색 인덱스들, 및/또는 사용자 디바이스(100)에서의 애플리케이션 사용량을 나타내는 데이터 등을 포함할 수 있다. 다른 일례로서, 예를 들어, 로컬 데이터(104)는 광고에 사용되는 데이터, 가령 로컬 광고 콘텐츠, 광고 타겟팅 파라미터, 및/또는 애플리케이션 설치/사용 데이터 등을 포함할 수 있다. 일부 구현예에서, 로컬 데이터(104)는 사용자가 로컬 서비스 모듈(102)(예를 들어, 검색/광고 상호작용 히스토리) 및/또는 다른 애플리케이션과 어떻게 상호작용했는지를 나타내는 사용 데이터를 포함할 수 있다.

일부 구현예에서, 로컬 데이터(104)는 설치된 애플리케이션의 목록과 같은 사용자 디바이스(100) 상의 원시(raw) 데이터를 포함할 수 있다. 일부 구현예에서, 로컬 데이터(104)는 사용자 디바이스(100)에 포함된 원시 데이터에 기초하여 계산된 데이터와 같은 프로세싱된 데이터를 포함할 수 있다. 예를 들어, 로컬 서비스 모듈(102)은 사용자 디바이스에 저장된 연락처 목록을 획득할 수 있고 그리고 로컬 검색 중에 매칭을 위해 사용할 연락처에 대한 약어들(abbreviations)의 목록을 생성할 수 있다. 다른 예로서, 로컬 서비스 모듈(102)은 사용자 디바이스(100)에 설치된 애플리케이션 목록을 획득할 수 있고 그리고 로컬 검색 동안 매칭에 사용하기 위해 애플리케이션들과 관련된 약어/두문자어(acronyms) 목록을 생성할 수 있다. 일부 구현예에서, 로컬 데이터(104)는 원격 서비스 시스템(들)(106-1)(일반적으로 "원격 서비스 시스템(들)(106)"이라고 함)으로부터 수신되고 로컬 데이터에 캐싱되는 데이터, 예컨대 여기에 설명된 업데이트된 검색/광고 데이터를 포함할 수 있다.

로컬 서비스 모듈 기능은 업데이트 가능하거나/재구성가능할 수 있다. 예를 들어, 로컬 서비스 모듈(102)은 상이한 기능과 연관된 알고리즘 및 데이터를 업데이트할 수 있다. 일 예에서, 검색 알고리즘(예를 들어, 스코어링/선택 알고리즘) 및/또는 검색 데이터(예를 들어, 검색 인덱스)가 업데이트될 수 있다. 다른 예에서, 광고 알고리즘(예를 들어, 스코어링/선택 알고리즘) 및/또는 광고 데이터(예를 들어, 광고 콘텐츠)가 업데이트될 수 있다. 로컬 서비스 모듈(102)은 로컬 서비스 모듈 기능에 대한 업데이트를 획득하는 업데이트 모듈(108-1)(일반적으로 "업데이트 모듈(108)"이라고 함)을 포함할 수 있다. 업데이트 모듈(108)은 원격 서비스 시스템(들)(106)로부터 업데이트를 획득할 수 있다.

일부 구현예에서, 원격 서비스 시스템(들)(106)은 또한 로컬 서비스 모듈(102)에 대한 추가적인 원격 특징/기능을 제공할 수 있다. 예를 들어, 원격 서비스 시스템(들)(106)은 로컬 서비스 모듈(102)에 대한 검색/광고 특징을 제공할 수 있다. 원격 서비스 시스템(들)(106)은 여기에서 원격 서비스 시스템(들)(106)에 의해 제공되는 업데이트 및/또는 기능에 따라 지칭될 수 있다. 예를 들어, 도 1 및 도 4a 내지 도 4b에서, 검색 데이터 업데이트 및/또는 검색 기능을 제공하는 원격 서비스 시스템은 본 명세서에서 "원격 검색 시스템(110)" 또는 "검색 시스템(110)"으로 지칭될 수 있다. 다른 예로서, 도 1 및 도 8a-8b에서, 광고 데이터 업데이트 및/또는 기능을 제공하는 원격 서비스 시스템은 본 명세서에서 "원격 광고 시스템(112)" 또는 "광고 시스템(112)"으로 지칭될 수 있다. 비록, 상이한 기능들 및 업데이트들을 제공하는 다수의 원격 서비스 시스템들이 구현될 수 있지만, 일부 경우에 원격 서비스 시스템들은 다수의 상이한 기능들을 제공하는 단수형의 "원격 서비스 시스템"으로 설명될 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102)은 로컬 서비스 모듈(102) 및/또는 사용자 디바이스 상의 하나 이상의 애플리케이션(114)과의 사용자 상호작용 이벤트와 같은 로컬 데이터를 획득할 수 있다. 예시적인 상호작용들은, 검색 상호작용(예: 검색 질의, 결과 선택 등), 광고 상호작용(예: 광고 선택), 런처 상호작용(예: GUI 상호작용) 및/또는 기타 웹/애플리케이션 상호작용(예: 애플리케이션 설치/오픈)을 포함할 수 있다. 로컬 서비스 모듈(102)은 획득한 데이터를 사용하여 개인화된 검색 결과 및/또는 광고와 같은 로컬 기능을 제공할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 획득된 데이터를 원격 서비스 시스템(106)으로 전송할 수 있다. 원격 서비스 시스템(106)은 하나 이상의 사용자로부터 획득한 데이터에 기초하여 원격 기능(예를 들어, 검색 결과 및/또는 광고)을 제공할 수 있다. 일부 구현예에서, 원격 서비스 시스템(106)은 사용자/집계 획득 데이터에 기초하여 로컬 서비스 모듈(102)에 업데이트 데이터를 제공할 수 있다.

사용자 디바이스(100)는 운영 체제(116) 및 런처 애플리케이션, 웹 브라우저 애플리케이션, 검색 애플리케이션 및/또는 추가 애플리케이션과 같은 설치된 애플리케이션(114)을 포함할 수 있다. 로컬 서비스 모듈(102)은 사용자 디바이스(100) 상의 하나 이상의 애플리케이션(114)에 다양한 기능을 제공할 수 있다. 예를 들어, 하나 이상의 애플리케이션은 로컬 서비스 모듈(102)이 사용자에게 기능을 제공할 수 있는 중개 애플리케이션의 역할을 할 수 있다.

로컬 서비스 모듈(102)은 다양한 방식으로 사용자 디바이스(100)에서 구현될 수 있다. 일부 구현예에서, 로컬 서비스 모듈은 다른 애플리케이션에 서비스(예를 들어, 검색/광고)를 제공하는 독립형 애플리케이션으로 실행할 수 있다(예를 들어, 도 2a 참조). 예를 들어, 로컬 서비스 모듈은 사용자 디바이스에서 백그라운드 서비스(예를 들어, 백그라운드 서비스, 백그라운드 프로세스 또는 데몬이라고 함)로 실행될 수 있다. 이 예에서 사용자 디바이스의 애플리케이션은 로컬 서비스 모듈에 의해 제공되는 기능에 액세스할 수 있다. 또한, 이 예에서 로컬 서비스 모듈은 일반적으로 사용자를 위한 독립형 그래픽 사용자 인터페이스를 제공하지 않을 수 있다. 대신, 이 예에서 로컬 서비스 모듈 기능에 액세스하는 애플리케이션은 사용자 상호작용을 위한 GUI를 제공할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102)은 사용자 디바이스(100) 상의 하나 이상의 애플리케이션에 통합될 수 있다. 예를 들어, 일부 구현예에서, 런처 애플리케이션은 로컬 서비스 모듈을 포함할 수 있다(예를 들어, 도 4b 참조). 이 예에서 런처 애플리케이션은 런처 검색 페이지, 런처 검색 바(예: 검색어 입력 상자), 런처 광고 공간(예: 광고 링크를 위한 하나 이상의 공간) 및/또는 하나 이상의 제스처와 같이 로컬 서비스 모듈에 액세스하는 사용자 인터페이스 및 다른 GUI 요소를 제공할 수 있다. 비록, 로컬 서비스 모듈이 런처 애플리케이션(예를 들어, 도 4b 참조)에 통합되는 것으로 본 명세서에서 예시 및 설명되지만, 로컬 서비스 모듈은 다른 애플리케이션에 통합될 수 있다. 하나의 구체적인 예에서, 로컬 서비스 모듈은 뉴스 애플리케이션에 통합될 수 있다. 이 특정 예에서, 로컬 서비스 모듈은 뉴스 애플리케이션에 대한 검색 기능을 제공할 수 있다. 다른 예에서, 로컬 서비스 모듈은 하나 이상의 디지털 배포 플랫폼(118)에서 이용가능한 애플리케이션을 검색하는 검색 애플리케이션에 포함될 수 있다. 로컬 서비스 모듈을 포함하는 애플리케이션은 로컬 서비스 모듈에 더하여 자체 애플리케이션 기능을 포함할 수 있음에 유의한다(예를 들어, 도 2b 및 도 4b에서 추가 앱 기능 모듈로 예시됨).

로컬 서비스 모듈(102)을 포함하는 애플리케이션은 다양한 방식으로 사용자 디바이스(100)에서 구현될 수 있다. 일부 구현예에서, 사용자는(예를 들어, 디지털 배포 플랫폼(118)으로부터) 애플리케이션을 다운로드하고 사용자 디바이스(100)에 애플리케이션을 설치할 수 있다. 다른 구현예에서, 애플리케이션은 사용자가 사용자 디바이스를 구입하기 전에 사용자 디바이스에 설치될 수 있다.(예: 미리 로드된 애플리케이션). 경우에 따라 애플리케이션을 "네이티브 애플리케이션" 또는 "위젯"이라 지칭하기도 한다.

로컬 서비스 모듈(102)은 사용자가 사용자 디바이스를 구매하기 전에 당사자들에 의해 통합될 수 있다. 예를 들어, 디바이스 제조업체, 휴대폰 서비스 제공자/통신사 또는 기타 비즈니스는 사용자에게 사용자 디바이스를 판매하기 전에 사용자 디바이스에 애플리케이션을 로드할 수 있다. 일부 구현예에서, 로컬 서비스 모듈은 사용자 디바이스가 캐리어 네트워크에 접속할 때 캐리어(예를 들어, 휴대폰 캐리어)에 의해 설치될 수 있다. 일부 구현예에서, 로컬 서비스 모듈은 애플리케이션으로의 통합을 위해 소프트웨어 개발자에게 제공될 수 있으며, 이는 이후에 사용자 구매 또는 사용자 디바이스의 첫 번째 활성화의 일부로서 또는 그 이전에 사용자 디바이스로의 통합을 위해 당사자(예를 들어, 디바이스 제조업체, 휴대폰 서비스 제공자 등)에게 제공된다. 일부 구현예에서, 로컬 서비스 모듈은 애플리케이션으로의 통합을 위해 소프트웨어 개발자에게 제공될 수 있으며, 이는 이후에 하나 이상의 디지털 배포 플랫폼(118)으로부터 다운로드를 위해 제공된다. 일부 경우, 로컬 서비스 모듈의 개발자는 로컬 서비스 모듈을 그들 자체의 애플리케이션(예: 자체 런처 애플리케이션)에 통합할 수 있으며, 이후 디바이스 제조업체, 휴대폰 서비스 제공업체/통신업체 및/또는 다른 당사자에게 사용자 디바이스에 통합하기 위해 애플리케이션을 제공한다. 다른 경우에, 로컬 서비스 모듈의 개발자는 로컬 서비스 모듈을 그들 자신의 애플리케이션에 통합할 수 있고 이어서 하나 이상의 디지털 배포 플랫폼(118)으로부터 다운로드를 위해 애플리케이션을 제공할 수 있다.

애플리케이션/시스템은 로컬 서비스 모듈(예를 들어, 도 2a의 I/F 모듈(202) 참조)과 통신하는 인터페이스 모듈을 포함할 수 있다. 일부 구현예에서, 로컬 서비스 모듈의 개발자는 인터페이스 모듈을 개발하고 통합(예: 런처 애플리케이션 또는 다른 애플리케이션으로의 통합)을 위해 다른 애플리케이션 개발자에게 인터페이스 모듈을 제공할 수 있다. 로컬 서비스 모듈, 다른 설치된 애플리케이션 및/또는 원격 시스템 간의 예시적인 통신 기술은 API 호출, 프로세스 간 통신, 동일한 디바이스의 로컬 네트워크 호출, 공유 로컬 스토리지/메모리 및/또는 기타 통신 기술을 포함할 수 있지만 이에 한정되는 것은 아니다.

로컬 서비스 모듈 및/또는 로컬 서비스 모듈과 인터페이스하는 애플리케이션에 의해 제공되는 기능의 범위는 구성가능할 수 있다. 예를 들어, 로컬 서비스 모듈은 검색, 광고, 제로 상태 및/또는 기타 기능과 같이 여기에 설명된 기능의 임의의 조합을 제공하도록 구성될 수 있다. 마찬가지로 애플리케이션 개발자는 애플리케이션 UI 또는 기타 기능을 구성하여 다양한 방식으로 로컬 서비스 모듈과 인터페이스할 수 있다. 일부 구현예에서 업데이트 번들은 인터페이스 모듈에 대한 업데이트 또는 구성을 변경하는 명령들을 포함할 수도 있다. 추가로 또는 대안적으로 애플리케이션 개발자는 로컬 서비스 모듈과 별도로 인터페이스 모듈을 업데이트할 수 있다. 일부 구현예에서 로컬 서비스 모듈은 배포 후 기능을 변경할 수 있다. 예를 들어 당사자는 검색만 활성화된 상태에서 로컬 서비스 모듈을 배포한 다음, 나중에 추가 기능(예: 광고, 제로 상태 등)을 활성화할 수 있다.

일부 구현예에서, 로컬 서비스 모듈은 로컬 요청 및 로컬 응답 통신 기술을 사용하여 애플리케이션과 통신할 수 있다. 예를 들어, 애플리케이션은 로컬 서비스 모듈에 요청 데이터 구조를 보낼 수 있다. 수신된 요청 데이터 구조에 응답하여 로컬 서비스 모듈은 기능을 수행한 다음, 요청에 대한 로컬 응답을 제공할 수 있다. 요청을 생성하는 애플리케이션은 경우에 따라 "요청 애플리케이션"으로 언급될 수 있다. 본 명세서에서 요청/응답의 이름은 로컬 서비스 모듈에서 요청한 기능 유형에 따라 달라질 수도 있다. 예를 들어, 검색 결과를 요청하는 애플리케이션은 검색 요청 데이터 구조(즉, "검색 요청")를 생성하고 검색 응답 데이터 구조(즉, "검색 응답")를 수신할 수 있다. 다른 예로서, 광고를 요청하는 애플리케이션은 광고 요청 데이터 구조(즉, "광고 요청")를 생성하고 광고 응답 데이터 구조(즉, "광고 응답")를 수신할 수 있다. 여기에서 로컬 서비스 모듈의 이름은 로컬 서비스 모듈이 제공하는 기능 유형에 따라 달라질 수도 있다. 예를 들어, 검색 기능 또는 광고 기능을 제공하는 로컬 서비스 모듈은 각각 "로컬 검색 서버" 또는 "로컬 광고 서버"라고 지칭될 수 있다.

사용자 디바이스는 본 명세서에 기술된 로컬 서비스 모듈의 하나 이상의 구현예들을 포함할 수 있다. 예를 들어, 단일 사용자 디바이스는 백그라운드 서비스로서 하나 이상의 로컬 서비스 모듈을 포함하거나 및/또는 하나 이상의 추가 애플리케이션에 포함된 하나 이상의 로컬 서비스 모듈을 포함할 수 있다.

도 2a-2b는 로컬 서비스 모듈(102)의 예시적인 구현을 도시한다. 도 2a에서, 로컬 서비스 모듈(102-2)은 하나 이상의 애플리케이션(200)에 대한 서비스로서 작용한다. 애플리케이션 1(200-1)은 인터페이스 모듈(202) 및 애플리케이션 1에 대한 애플리케이션 기능을 제공하는 추가 모듈(204)을 포함한다. 도 2a에 도시된 바와 같이, 애플리케이션(200)은 로컬 서비스 모듈(102-2)에 요청을 하고 로컬 서비스 모듈(102-2)로부터(예를 들어, 인터페이스 모듈(202)을 통해) 응답을 수신할 수 있다.

도 2b에서, 로컬 서비스 모듈(102-3)은 애플리케이션 1(206-1)에 통합된다. 애플리케이션 1(206-1)은 또한 애플리케이션 1(206-1)에 의해 제공되는 UI 모듈 및 기타 기능과 같은 애플리케이션 1(206-1)과 연관된 기능을 제공하는 추가 모듈(208)을 포함한다. 예를 들어, 애플리케이션 1(206-1)이 뉴스 애플리케이션인 경우, 애플리케이션 1 모듈은 뉴스 기사를 취득하여 사용자에게 표시할 수 있다. 이 예에서, 로컬 서비스 모듈(102-3)은 뉴스 기사 검색 수행 및/또는 뉴스 애플리케이션에 대한 광고 제공과 같은 추가 기능을 제공할 수 있다. 도시되지는 않았지만, 애플리케이션 1(206-1)은 또한 로컬 서비스 모듈(102-3)과 다른 애플리케이션 1 모듈(208) 사이의 통신을 제공하는 인터페이스 모듈을 포함할 수 있다. 애플리케이션 1 모듈(208)과 로컬 서비스 모듈(102-3) 사이의 통신은 도 2b에서 또한 일부 예에서 로컬 요청/응답 통신으로 특징지어질 수 있다.

일부 구현예에서, 로컬 서비스 모듈은 사용자 디바이스 상의 다른 애플리케이션에 비하여 특별한 우선권을 제공받을 수 있다. 예를 들어, 로컬 서비스 모듈은 일반적으로 다른 애플리케이션에서 액세스할 수 없는 로컬 데이터에 대한 액세스 및 특수 권한을 제공받을 수 있다. 로컬 서비스 모듈은 주문자 상표 부착 생산자(OEM) 또는 다른 당사자(예: OS 개발자)가 로컬 서비스 모듈을 OS에 통합한 경우 및/또는 로컬 서비스 모듈이 사용자 디바이스가 사용자에게 처음 판매될 때 OS와 함께 제공되는 OEM 제공 제품의 일부인 경우, 특별한 권한/허가를 제공받을 수 있다.

도 3은 로컬 서비스 모듈(102)의 획득, 동작 및 업데이트를 설명하는 예시적인 방법을 도시한다. 블록(300)에서, 사용자 디바이스는 초기 로컬 서비스 모듈을 획득한다. 로컬 서비스 모듈은 하나 이상의 애플리케이션에 대한 독립형 서비스로 구현되거나 및/또는 애플리케이션에 포함될 수 있다. 본 명세서에 기술된 바와 같이, 초기 로컬 서비스 모듈은 디바이스 제조자 또는 다른 당사자에 의해 여러 다양한 방식으로 사용자 디바이스에 포함될 수 있다. 초기 로컬 서비스 모듈은 원격 서비스 시스템(106)으로부터 임의의 업데이트가 수신되기 전에, 개발자에 의해 제공되는 로컬 서비스 모듈의 초기 버전을 참조할 수 있다. 초기 로컬 서비스 모듈은 초기 검색/광고 알고리즘(예: 초기 스코어링/선택 기능) 및/또는 초기 검색/광고 데이터(예: 초기 검색/광고 레코드)와 같은 초기 구성 파라미터 및 데이터를 포함할 수 있다.

블록(302)에서, 사용자 디바이스는 초기 로컬 서비스 모듈 버전에 포함된 초기 구성 파라미터 및 데이터를 사용하여 로컬 서비스 모듈(102)을 동작시킨다. 블록(304)에서, 로컬 서비스 모듈(102)은 업데이트된 기능(예를 들어, 알고리즘) 및/또는 업데이트된 데이터를 포함할 수 있는 업데이트를 수신한다. 예를 들어, 업데이트 모듈(108)은 업데이트 데이터(예를 들어, 검색 업데이트 데이터 및/또는 광고 업데이트 데이터)를 요청했을 수 있다. 블록(306)에서, 사용자 디바이스는 업데이트된 데이터에 의해 수정된 바와 같이 로컬 서비스 모듈(102)을 동작시킬 수 있다.

블록(308)에서, 로컬 서비스 모듈(102)은 업데이트가 적절하게 기능하고 있는지 여부를 결정할 수 있다. 업데이트가 적절하게 기능하지 않는 경우, 블록(310)에서, 로컬 서비스 모듈(102)은 초기 구성/데이터(예: 알고리즘 및 데이터)를 사용하도록 되돌아가거나 또는 시간이 지남에 따라 여러 개의 이전 업데이트들이 수신된 경우 이전에 획득한 기능 업데이트(예: 안정적인 버전)를 사용하도록 되돌아갈 수 있다. 블록(312)에서, 로컬 서비스 모듈(102)(예를 들어, 업데이트 모듈 108)은 업데이트를 획득할지 여부를 결정할 수 있다. 본 명세서에 기술된 바와 같이, 일부 구현예에서, 원격 서비스 시스템(106)은 업데이트를 사용자 디바이스에 푸시할 수 있다.

블록(308-310)과 관련하여 설명된 바와 같이, 로컬 서비스 모듈(102)은 업데이트(예를 들어, 알고리즘/ 데이터)가 적절하게 기능하고 있는지 여부를 결정할 수 있다. 로컬 서비스 모듈(102)은 업데이트가 적절하게 기능하고 있지 않다고 다양한 방식으로 결정할 수 있는바, 가령, 1) 예외를 검출하거나(예를 들어, 하드웨어/소프트웨어 예외, 알고리즘 오류, SQL 오류 등을 검출), 2) 타임아웃(예를 들어, 네트워크 타임아웃 또는 다른 타임아웃)을 검출하거나, 및/또는 3) 결과가 없거나 불량한 결과가 생성되고 있음을 결정함으로써 이를 결정할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 오작동에 응답하여 이전 업데이트를 사용하기 시작할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 리턴될 결과를 기다리는 동안 로컬 서비스 모듈(102)이 적절하게 기능하지 않다는 것을 결정하도록 구성될 수 있다. 이러한 구현예에서 로컬 서비스 모듈은 결과를 기다리면서, 이전의 안정적인 업데이트를 로딩할 수 있다. 추가로, 로컬 서비스 모듈은 이전의 안정적인 업데이트를 사용하여 이전 기능을 실행할 수 있으므로 로컬 서비스 모듈은 새로 로드된 업데이트가 결과 제공을 완료하기 전에 오작동 가능성이 있는 업데이트가 결과를 반환하지 않는다고 가정하여 사용자에게 즉시 결과를 제공할 수 있다. 이전의 안정적인 업데이트로 대체하면, 오작동할 수 있는 현재 업데이트가 결과를 반환하는데 걸리는 대기 시간이 줄어들어 긍정적인 사용자 경험을 제공할 수 있다.

본 명세서에 기술된 바와 같이, 로컬 서비스 모듈은 로컬 서비스 모듈 또는 로컬 서비스 모듈을 포함하는 다른 애플리케이션의 설치 중에 정의된 소프트웨어 컴포넌트와 같은 여러 정의된 소프트웨어 컴포넌트를 포함할 수 있다. 본 명세서에서 추가로 설명되는 바와 같이, 로컬 서비스 모듈에 포함된 일부 모듈(예를 들어, 검색 및 광고 모듈)은 정의된 소프트웨어 컴포넌트에 추가하여 구성/수정가능한 기능을 가질 수 있다. 구성/수정가능한 기능은 시간 경과에 따라 수신된 업데이트 데이터(예: 업데이트 번들)에 의해 업데이트될 수 있다. 구성가능한 기능은 또한 검색 및 광고 결과를 각각 생성하는데 사용되는 검색 및 광고 데이터와 같은 구성가능/수정가능한 데이터를 포함할 수 있다.

업데이트될 수 있는 예시적인 구성가능한 기능/데이터는 검색 결과 선택/스코어링 알고리즘, 검색 레코드 데이터, 광고 선택 알고리즘(예를 들어, 광고 선택/스코어링 기능) 및 광고 레코드 데이터를 포함할 수 있다. 로컬 서비스 모듈은 다양한 유형의 업데이트를 수신할 수 있다. 경우에 따라 로컬 서비스 모듈은 데이터(예: 검색/광고 레코드)를 업데이트하지 않고 알고리즘(예: 검색/광고 알고리즘)을 업데이트할 수 있다. 다른 경우, 로컬 서비스 모듈은 알고리즘을 업데이트하지 않고 데이터를 업데이트할 수 있다. 다른 경우, 로컬 서비스 모듈은 알고리즘과 데이터를 모두 업데이트할 수 있다. 일부 구현예에서, 업데이트는 검색/광고 선택 알고리즘, UI 컴포넌트 및/또는 여기에 설명된 다른 기능과 같은 기능들을 활성화 및/또는 비활성화할 수 있다.

검색 및 광고 기능에 대한 업데이트와 같은 설치된 로컬 서비스 모듈 기능에 대한 업데이트는 다른 애플리케이션에 대한 업데이트와 다를 수 있다. 로컬 서비스 모듈이 독립 실행형 애플리케이션(예: 서비스)으로 설치된 경우, 로컬 서비스 모듈 기능(예: 검색/광고)에 대한 업데이트는 로컬 서비스 모듈에 대한 전체 업데이트와 다를 수 있다. 예를 들어, 전체 업데이트(예를 들어, 로컬 서비스 모듈의 재설치)는, 로컬 서비스 모듈 또는 로컬 서비스 모듈을 포함하는 애플리케이션의 정의된 소프트웨어 컴포넌트를 업데이트하는 것을 포함할 수 있는 반면, 로컬 서비스 모듈의 일부 기능에 대한 업데이트는 로컬 서비스 모듈과 관련된 구성가능한 데이터에 대한 업데이트를 포함할 수 있다. 로컬 서비스 모듈과 관련된 구성가능한 기능(예: 알고리즘) 및 데이터의 업데이트는 로컬 서비스 모듈이 사용자 디바이스에서 구동 중인(예: 실행 중인) 동안 수행될 수 있다. 또한, 로컬 서비스 모듈의 이전 구성으로 되돌아가는 것은 로컬 서비스 모듈이 사용자 디바이스에서 실행되는 동안 수행될 수 있다.

일부 구현예에서, 런처 애플리케이션과 같은 전형적인 애플리케이션에 대한 업데이트는 애플리케이션의 재시작 및/또는 사용자 디바이스의 재부팅을 요구할 수 있다. 로컬 서비스 모듈 기능에 대한 업데이트는 로컬 서비스 모듈 또는 로컬 서비스 모듈을 포함하는 애플리케이션의 재시작을 요구하지 않을 수 있다. 일부 구현예에서, 로컬 서비스 모듈 및/또는 로컬 서비스 모듈을 포함하는 애플리케이션은 업데이트 번들을 수신하기 이전 및 이후에 동일한 정의된 소프트웨어 컴포넌트를 가질 수 있는데, 이는 정의된 소프트웨어 컴포넌트가 로컬 서비스 모듈에 의해 수정/재작성되지 않을 수 있기 때문이다. 이러한 구현예에서, 로컬 서비스 모듈 및/또는 애플리케이션은 업데이트 이후 동일한 버전의 애플리케이션일 수 있는 반면, 로컬 서비스 모듈은 구성가능한 데이터의 업데이트된 버전을 실행할 수 있다.

로컬 서비스 모듈은 로컬 서비스 모듈을 포함하는 애플리케이션보다 더 자주 업데이트될 수 있다. 예를 들어, 로컬 서비스 모듈이 사용자 디바이스의 구매 이전에, 디바이스 제조사 또는 제3자에 의해 제공되는 런처 애플리케이션에 포함된 경우, 런처 애플리케이션은 업데이트 전에 더 긴 서비스 주기를 가질 수 있다. 예를 들어, 런처 애플리케이션은 업데이트하는데 몇 주 또는 몇 달이 걸릴 수 있는 반면, 로컬 서비스 모듈(예: 런처 애플리케이션에 포함됨)은 훨씬 더 빠른 속도로 업데이트를 수신할 수 있다(예: 하나의 런처 업데이트당 여러 개의 순차적 로컬 서비스 모듈 업데이트). 런처 애플리케이션과 로컬 서비스 모듈 사이의 이러한 비동기형 업데이트 주기 차이는 로컬 서비스 모듈 개발자가 일반적인 런처 애플리케이션 업데이트에 의존하지 않고 최신 기능(예: 검색/광고 기능)을 사용자에게 제공할 수 있게 한다. 일부 경우, 로컬 서비스 모듈 기능에 대한 이러한 더 짧은 업데이트 주기는 로컬 서비스 모듈 제공자가 더 나은 사용자 경험을 제공하기 위해 알고리즘과 데이터를 더 자주 업데이트/조정할 수 있게 한다.

일부 구현예에서, 로컬 서비스 모듈은 로컬 서비스 모듈을 포함하는 애플리케이션을 개발 및 지원하는 당사자와는 다른 당사자에 의해 개발 및 지원될 수 있다. 예를 들어, 런처 애플리케이션은 제 1 당사자가 개발하는 반면, 로컬 서비스 모듈은 제 2 당사자가 개발 및 지원한다. 제 1 당사자와 제 2 당사자는 각각의 애플리케이션/모듈에 대한 업데이트를 제공하는 서로 다른 서버를 운영할 수 있다. 예를 들어, 로컬 서비스 모듈 기능은 런처 개발자와는 다른 당사자에 의해 업데이트될 수 있다.

본 발명의 로컬 서비스 모듈(102)은 즉각적이고 관련된 결과(예를 들어, 검색 결과 및 광고)를 제공할 수 있다. 또한, 애플리케이션 설치/사용 데이터와 같은 로컬 사용자 데이터는 결과의 개인화 및 관련성을 높이는데 사용될 수 있다. 개인화 및 관련성을 향상시키기 위해 로컬 사용자 데이터를 사용하면 로컬 데이터가 사용자 디바이스에서 유지 관리될 수 있으므로 사용자의 개인 정보 보호도 유지할 수 있다.

로컬 서비스 모듈(102)은 또한 동작의 로컬 특성으로 인해 신뢰할 수 있는 방식으로 결과를 제공할 수 있다. 예를 들어, 로컬 서비스 모듈은 인터넷 연결 상태에 관계없이 결과를 제공할 수 있다. 로컬 서비스 모듈은 결과를 로컬적으로 제공할 수 있지만, 일부 구현예에서 로컬 서비스 모듈은 사용자에게 제공되는 기능 및/또는 콘텐츠를 향상시킬 수 있는 원격 서비스 시스템(들)(106)으로부터 결과를 검색할 수 있다.

도 4a-7은 검색 기능을 포함하는 로컬 서비스 모듈의 예시적인 구현을 도시한다. 도 8a-12는 광고 기능을 포함하는 로컬 서비스 모듈의 예시적인 구현을 도시한다. 도 13은 검색 기능, 광고 기능 및 추가 기능(예를 들어, 바로가기, 제로 상태 등)을 제공할 수 있는 로컬 서비스 모듈을 포함하는 런처 애플리케이션을 도시한다. 도 14-15는 원격 서비스 시스템 및 로컬 서비스 모듈의 예시적인 구현을 도시한다. 도 16-17은 질의 힌트 및 자동제안 기능을 위한 예시적인 GUI를 도시한다. 도 18은 유사/상이한 로컬 서비스 모듈을 실행할 수 있는 복수의 상이한 디바이스 그룹을 하나 이상의 원격 서비스 시스템이 업데이트하는 예시적인 환경을 도시한다.

도 1에 도시된 바와 같이, 예시적인 환경은 네트워크(120)(예를 들어, 인터넷)를 통해 하나 이상의 원격 서비스 시스템(들)(106)(예를 들어, 하나 이상의 서버 컴퓨팅 디바이스)과 통신하는 복수의 사용자 디바이스(100)를 포함한다. 네트워크(120)는 지역 통신망(LAN: Local Area Network), 광역 통신망(WAN: Wide Area Network) 및/또는 인터넷을 포함할 수 있다. 예시적인 사용자 디바이스(100)는 스마트폰, 랩탑, 태블릿, 데스크탑 및 웨어러블 컴퓨팅 디바이스를 포함할 수 있지만, 이에 제한되지 않는다. 다른 예시적인 사용자 디바이스는 스마트 어시스턴트 디바이스(예를 들어, 스마트 스피커 디바이스) 및 기기를 포함할 수 있다. 예시적인 스마트 스피커 디바이스는 아마존의 AMAZON ECHO® 스마트 스피커, 구글의 GOOGLE HOME® 스마트 스피커 또는 애플의 Apple HOMEPOD® 스마트 스피커를 포함할 수 있지만 이에 제한되지 않는다.

상기 환경은 하나 이상의 디지털 배포 플랫폼(118)을 포함한다. 디지털 배포 플랫폼은 애플리케이션을 사용자 디바이스에 배포하도록 구성된 컴퓨팅 시스템을 나타낼 수 있다. 예시적인 디지털 배포 플랫폼은 구글의 GOOGLE PLAY® 디지털 배포 플랫폼 및 애플의 APP STORE® 디지털 배포 플랫폼을 포함하지만 이에 제한되지 않는다. 사용자는 디지털 배포 플랫폼(118)으로부터 애플리케이션을 다운로드하고 그리고 사용자 디바이스(100)에 애플리케이션을 설치할 수 있다.

상기 환경은 로컬 서비스 모듈(102) 및 원격 서비스 시스템(들)(106)이 광고 기능을 제공하는 구현예에서 사용자 디바이스(100) 및/또는 원격 서비스 시스템(들)(106)과 통신할 수 있는 광고주 디바이스(122)를 포함한다. 예를 들어, 광고주는 광고주 디바이스(122)를 사용하여 광고 데이터를 사용자 디바이스(100)(예를 들어, 로컬 서비스 모듈) 및/또는 원격 서비스 시스템(들)(106)에 제공할 수 있다. 상기 환경은 또한 광고(예를 들어, 광고주 디바이스(122)에 의해 생성된)를 사용자 디바이스(100) 및/또는 원격 서비스 시스템(들)(106)에 제공하는 광고(ad) 네트워크(124)를 포함할 수 있다. 예를 들어, 여기에 설명된 바와 같이, 광고주 디바이스(122) 및 광고 네트워크(124)는 광고 데이터를 광고 시스템(112)에 제공할 수 있고, 광고 시스템(112)은 광고 데이터를 사용자 디바이스(100)에 제공할 수 있다.

환경은 하나 이상의 데이터 제공자(126)를 포함한다. 데이터 제공자(126)는 이벤트 데이터("외부 이벤트 데이터")를 원격 서비스 시스템(들)(106) 또는 다른 당사자에 의해 운영되는 다른 시스템(가령, 다른 검색 시스템 및 광고 시스템)에 제공하는 컴퓨팅 시스템을 나타낼 수 있다. 일부 구현예에서, 데이터 제공자(126)는 데이터 관리 및 분석 서비스를 제공하는 기업일 수 있다. 데이터 제공자는 사용자가 원격 서비스 시스템(106)(예를 들어, 검색/광고 시스템(110, 112)), 애플리케이션 및/또는 웹사이트를 사용하는 방법에 관한 데이터를 수집할 수 있다. 데이터 제공자 시스템(126), 원격 서비스 시스템(들)(106) 및 디지털 배포 플랫폼(들)(118)은 하나 이상의 당사자(예를 들어, 하나 이상의 사업체)에 의해 운영될 수 있다.

환경은 사용자 디바이스(100)에 설치된 애플리케이션과 관련된 원격 기능을 나타낼 수 있는 애플리케이션 특정 서버(128)를 포함할 수 있다. 예를 들어, Yelp 애플리케이션은 Yelp 특정 서버에 액세스하여 Yelp 애플리케이션을 위한 일부 기능을 제공할 수 있다. 일부 경우에, 애플리케이션 특정 서버(128)는 사용자 디바이스에 설치된 애플리케이션에 데이터를 제공할 수 있다. 일부 경우에, 애플리케이션 특정 서버(128)는 사용자 디바이스 상의 특정 애플리케이션에서의 사용자 행동을 나타내는 격리된 사용자 데이터를 획득할 수 있다.

도 4a-4b는 로컬 온-디바이스 검색 기능을 제공하는 로컬 서비스 모듈의 예시적인 구현을 도시한다. 로컬 검색 기능은 사용자 디바이스에 로컬적으로 저장된 데이터를 기반으로 검색 결과를 제공할 수 있다. 예를 들어, 로컬 검색 기능은 입력된 사용자 검색 질의 또는 기타 입력에 기초하여 검색 결과를 제공할 수 있다. 도 4a-4b는 또한 로컬 서비스 모듈(102)에 의해 제공되는 검색 기능에 대한 업데이트를 제공할 수 있는 원격 서비스 시스템(예를 들어, 검색 시스템 110)을 포함한다. 추가적으로, 일부 구현예에서, 검색 시스템(110)은 원격 검색 기능을 제공할 수 있다.

도 4a에서, 로컬 서비스 모듈(102-4)은 하나 이상의 애플리케이션(400-1 내지 400-N)에 대한 검색 서비스로서 작용한다. 도 4a에 도시된 바와 같이, 애플리케이션(400)은 로컬 서비스 모듈(102-4)에 검색 요청을 하고 로컬 서비스 모듈(102-4)로부터(예를 들어, 인터페이스 모듈(402)을 통해) 검색 응답(예를 들어, 검색 결과)을 수신할 수 있다. 도 4b에서, 로컬 서비스 모듈(102-5)은 런처 애플리케이션(404)에 통합된다. 또한, 런처 애플리케이션(404)은 런처 UI 모듈(406) 및 런처 애플리케이션(404)에 의해 제공되는 기타 기능(추가 런처 앱 모듈 408)과 같은 런처 애플리케이션(404)과 관련된 기능을 제공하는 추가 모듈을 포함한다.

런처 또는 다른 애플리케이션에 포함된 UI 모듈은 사용자에게 UI를 제공할 수 있다. 예를 들어, UI 모듈은 사용자에게 GUI를 제공할 수 있다. 런처 애플리케이션과 관련하여, GUI는 애플리케이션을 런칭하기 위해 사용자에 의해 선택될 수 있는 애플리케이션 아이콘을 포함할 수 있다. 런처 GUI는 홈 화면 및 제스처(예: 스와이핑)로 액세스할 수 있는 기타 화면과 같은 여러 화면을 제공할 수 있다. 또한, GUI는 검색 바(예: 런처 기반 검색), 검색 결과 페이지, 애플리케이션 및 웹사이트를 오픈하는 애플리케이션/웹 링크, 애플리케이션/웹 광고 링크, 그래픽 키보드 입력 및 기타 인터페이스와 같은 다른 인터페이스를 포함할 수 있다. 런처 애플리케이션(404)(예를 들어, UI 모듈 406)은 사용자 입력(예를 들어, 하나 이상의 터치/제스처)을 수신하고 그리고 입력에 응답하여 다양한 기능, 예를 들어 화면 간 변경, 애플리케이션 런칭, 검색 기능 시작, 기타 기능을 제공할 수 있다. 일부 구현예에서, 런처 애플리케이션(404)은 사용자 디바이스(100)의 운영 체제(116)와 함께 제공될 수 있다. 일부 구현예에서, 런처 애플리케이션(404)은 제3자 개발자에 의해서, 사용자 디바이스(100) 상에 설치될 수 있는 애플리케이션으로 제공될 수 있다. 비록 본 명세서에 기술된 런처 애플리케이션(404)에 의해서 다양한 기능이 제공될 수 있지만, 일부 구현예에서, 사용자 디바이스(100)는 런처 애플리케이션(404)에 기인한 기능을 제공하는 하나 이상의 다른 애플리케이션(예를 들어, 검색 애플리케이션)을 포함할 수 있다.

로컬 서비스 모듈(102-4, 102-5)은 로컬 검색 기능을 제공하는 검색 모듈(410) 및 로컬 데이터(104-4, 104-5)(예를 들어, 검색 데이터 및 기타 데이터)를 포함한다. 예를 들어, 검색 모듈(410)은 검색 요청을 수신하고 검색 요청에 기초하여 검색 응답(예: 검색 결과)을 생성할 수 있다. 요청 애플리케이션(예를 들어, 도 4a의 애플리케이션 1(400-1)) 또는 검색을 포함하는 런처 애플리케이션(예를 들어, 도 4b 참조)은 검색 GUI를 렌더링할 수 있는바, 이는 사용자 입력(예를 들어, 검색 질의)을 수신하고 검색 결과를 렌더링할 수 있다.

본 명세서에 기술된 바와 같이, 검색 기능을 포함하는 로컬 서비스 모듈(102)은 애플리케이션에 대한 서비스로서 또는 애플리케이션의 컴포넌트(예를 들어, 런처 애플리케이션의 검색 컴포넌트)로서 등과 같은 다양한 방식으로 구현될 수 있다. 일부 경우, 검색 모듈 기능은 도 4b의 구현예를 참조하여 본 명세서에서 설명될 수 있는바, 도 4b에서 로컬 서비스 모듈은 런처 애플리케이션에 포함된다. 이러한 경우, 검색 모듈이 제공하는 검색 기능은 일반적으로 로컬 서비스 모듈 및/또는 런처 애플리케이션에 기인할 수도 있다.

로컬 서비스 모듈(102)은 검색 기능, 광고 기능, 및/또는 여기에 설명된 다른 기능을 제공하기 위해 로컬 데이터(104)를 사용할 수 있다. 도면(예를 들어, 도 4a, 도 8a 등)에 도시된 로컬 데이터(104)는 다양한 유형의 데이터를 포함할 수 있으며, 이는 본 명세서에서 다양한 상이한 방식으로 언급될 수 있다. 본 명세서에 기술된 예시적인 로컬 데이터 분류는 검색 데이터, 광고 데이터 및 사용자 데이터를 포함할 수 있다. 검색 데이터는 검색 구성 데이터 및 검색 레코드 데이터(예를 들어, 도 6 참조)와 같이 검색에 사용되는 로컬 데이터를 포함할 수 있지만 이에 제한되지 않는다. 광고 데이터는 광고 구성 데이터 및 광고 레코드 데이터(예를 들어, 도 10 참조)와 같이 광고에 사용되는 로컬 데이터를 포함할 수 있으나 이에 한정되지 않는다. 사용자 데이터는 런처 애플리케이션 및/또는 다른 애플리케이션과 같이 사용자가 사용자 디바이스와 상호작용하는 방법을 나타내는 로컬 데이터를 포함할 수 있지만 이에 제한되지 않는다.

본 명세서에 기술된 바와 같이, 로컬 데이터는 상이한 기능(예를 들어, 검색 및 광고)을 위한 것과 같이 다양한 상이한 방식으로 사용될 수 있다. 이와 같이, 본 명세서에서 로컬 데이터의 예시적인 분류는 단지 설명/예시를 위한 것이며 특정 기능에 대한 로컬 데이터의 사용을 반드시 제한하지는 않는다. 예를 들어, 검색 데이터에 사용되는 일부 로컬 데이터는 광고 데이터에도 사용될 수 있다. 또한, 로컬 데이터의 예시 및 설명은(예를 들어, 도 4a 및 도 8a의 로컬 서비스 모듈에서) 반드시 로컬 데이터와 관련된 위치 및 액세스 권한을 제한하지 않는다. 예를 들어, 일부 로컬 데이터는 로컬 서비스 모듈에 의해 액세스 가능할 수 있는 반면, 다른 로컬 데이터는 애플리케이션, OS 등에 의해 액세스 가능할 수 있다. 이와 같이, 여기에 설명된 예시적인 로컬 데이터는 다양한 방식으로 저장/액세스될 수 있다.

로컬 서비스 모듈(102)은 검색 시스템(110)으로부터 초기 검색 데이터를 수신하고 그리고 검색 시스템(110)으로부터 수신된 검색 데이터 업데이트에 기초하여 로컬 검색 데이터를 후속적으로 업데이트할 수 있다. 검색 모듈(410)은 로컬 검색 데이터에 기초하여 검색을 수행할 수 있다. 검색 모듈(410)이 로컬 데이터를 사용하여 검색 결과를 생성할 수 있지만, 일부 구현예에서 검색 모듈(410)은 검색 시스템(110)으로부터 검색 결과를 요청할 수 있다. 검색 시스템(110)은 로컬 검색 모듈(410) 및 로컬 데이터(104)에 대한 업데이트를 제공할 수 있는 서버 검색 업데이트 모듈(412) 및 서버 검색 업데이트 데이터(414)를 포함할 수 있다. 검색 시스템(110)은 로컬 검색 모듈(410)과 유사한 방식으로 원격 검색 기능을 제공할 수 있는 서버 검색 모듈(416) 및 서버 검색 데이터(418)를 포함할 수 있다.

일부 구현예에서, 검색 모듈(410)은 검색 결과를 개인화할 수 있다(예를 들어, 개인화 검색을 수행할 수 있다). 예를 들어, 검색 모듈(410)은 사용자 디바이스에 어떤 애플리케이션이 설치되어 있는지 나타내는 로컬 사용자 데이터에 기초하여 검색 결과를 개인화할 수 있다. 검색 모듈(410)은 또한 설치된 애플리케이션에 대한 사용(usage) 데이터에 기초하여 검색 결과를 개인화할 수 있다. 사용 데이터는 이벤트가 발생한 시간과 함께 애플리케이션과 관련된 다양한 사용자 이벤트를 나타낼 수 있다. 사용자 이벤트의 예로는 애플리케이션 설치, 애플리케이션 제거, 재설치, 애플리케이션 열기, 애플리케이션 페이지 보기 및 상거래 이벤트(예: 장바구니에 추가 및/또는 구매 완료)가 포함될 수 있다. 일부 구현예에서, 검색 모듈(410)은 질의 히스토리 및 검색 결과 선택과 같은 검색 사용 데이터를 검색 시스템(110)에 보고할 수 있다.

검색이 사용자 디바이스에서 로컬적으로 수행되는 경우, 사용자 검색 질의 입력에 응답하여 검색 결과가 사용자에게 즉시 표시될 수 있다. 예를 들어, 검색 모듈(410)은 사용자가 단일 질의 문자를 검색 GUI에 입력하는 것에 응답하여 검색 결과를 (예를 들어, 런처 애플리케이션(404) 또는 다른 애플리케이션(400)에) 제공할 수 있다. 검색 모듈(410)은 또한 추가 검색 질의 문자의 입력에 응답하여 검색 결과를 즉시 업데이트할 수 있다.

원격 검색 시스템(110)으로부터 획득/업데이트될 수 있는 로컬 검색 데이터는 즉각적이고 관련된 검색 결과를 제공하기 위해 사용될 수 있다. 또한, 애플리케이션 설치/사용 데이터와 같은 로컬 사용자 데이터는 검색 결과의 개인화 및 관련성을 향상시키는데 사용될 수 있다. 로컬 데이터(104)가 사용자 디바이스(100) 상에 유지될 수 있기 때문에, 개인화 및 관련성을 향상시키기 위해 로컬 사용자 데이터를 사용하는 것은 또한 사용자의 프라이버시를 유지할 수 있다.

검색 결과가 로컬적으로 생성되는 경우, 검색 모듈(410)은 신뢰할 수 있는 방식으로 즉각적이고 관련성 있는 검색 결과를 제공할 수 있다. 예를 들어, 검색 모듈(410)은 인터넷 연결 상태와 상관없이 검색 결과를 제공할 수 있다. 구체적인 예에서, 인터넷 연결이 없거나 인터넷 연결이 좋지 않은 경우에도 검색 모듈(410)은 관련 검색 결과를 제공할 수 있다. 비록, 검색 모듈(410)이 로컬적으로 검색 결과를 제공할 수 있지만, 일부 구현예에서 검색 모듈(410)은 원격 검색 시스템(110)으로부터 검색 결과를 검색할 수 있다.

사용자는 런처 애플리케이션 검색 GUI에 검색 질의를 입력할 수 있다. 예를 들어, 사용자는 검색어를 입력하거나 말함으로써 검색 바에 검색 질의를 입력할 수 있다. 런처 애플리케이션(404)은 검색 질의 및 기타 데이터를 포함하는 로컬 검색 요청을 생성할 수 있다. 검색 요청 데이터 구조는 질의 객체라고 지칭될 수 있다. 질의 객체는 추가적인 사용자 검색 질의 데이터와 함께 사용자 검색 질의(예를 들어, 텍스트/숫자)를 포함할 수 있다. 일부 구현예에서, 런처 애플리케이션(404)(예를 들어, 로컬 서비스 모듈(102-5))은 질의 객체에 포함할 컨텍스트 데이터를 획득할 수 있다. 컨텍스트 데이터는 사용자 ID, 운영 체제 정보, 디바이스 유형 정보, 지리적 위치 데이터, 시간, 질의 히스토리 데이터(예: 런처 애플리케이션에서 하나 이상의 이전 질의), 애플리케이션 사용 데이터, 모션 데이터의 사용자 상태(예: 걷기, 자전거 타기, 운전), 사용자-히스토리컬 컨텍스트(예: 전술한 것들의 모든 이력들) 및/또는 질의의 카테고리(예: GUI에서 선택됨), 등과 같은 다양한 유형의 데이터를 포함할 수 있다. 일부 구현예에서, 런처 애플리케이션(404)은 런처 애플리케이션과 연관된 사용자 선호도 및/또는 사용자 히스토리 데이터와 같은 사용자 특정 데이터를 질의 객체에 포함할 수 있다. 예시적인 사용자 특정 데이터는 애플리케이션 사용 데이터(예: 앱 특정 사용 데이터), 사용자 인구통계 데이터, 사용자 지리적 위치 선호도, 과거 질의 및 요리 선호도 또는 호텔 선호도와 같은 수직/카테고리 선호도를 포함할 수 있지만 이에 제한되지 않는다. 런처 애플리케이션(404)은 사용자 특정 데이터를 저장할 수 있다. 일부 구현예에서, 여기에 설명된 일부 질의 객체 데이터는 검색 요청 시간에 검색 모듈(410)에 의해 획득될 수 있다.

검색 모듈(410)은 런처 애플리케이션(404)이 디스플레이할 검색 결과를 생성할 수 있다. 검색 결과는 다양한 데이터를 포함할 수 있다. 단일 검색 결과와 관련된 데이터는 "검색 결과 데이터 객체" 또는 "검색 결과 객체"라 지칭될 수 있다. 본 명세서에 기술된 바와 같이, 단일 검색 결과 객체는 디스플레이 데이터, 액세스 데이터 및 결과 스코어를 포함할 수 있다. 런처 애플리케이션(404)(예를 들어, UI 모듈(406))은 검색 GUI에서 검색 결과를 렌더링하기 위해 디스플레이 데이터를 사용할 수 있다. 디스플레이 데이터는 1) 애플리케이션 이름, 2) 결과 제목(예: 레스토랑 이름), 3) 결과와 관련된 상태에 대한 설명(예: 레스토랑에 대한 설명) 및 4) 애플리케이션/상태와 관련된 하나 이상의 이미지를 포함할 수 있다.

검색 결과 객체는, 검색 결과와 관련된 애플리케이션 상태(예를 들어, 다른 애플리케이션 중 하나에 대한 애플리케이션 상태)에 액세스하기 위해 사용자 디바이스 및/또는 런처 애플리케이션이 사용할 수 있는 액세스 데이터를 포함할 수 있다. 애플리케이션 상태는 일반적으로 애플리케이션의 페이지/화면을 의미할 수 있다. 경우에 따라 액세스 데이터에는 사용자 디바이스에서 애플리케이션 상태를 시작하는 애플리케이션 URI/URL(Uniform Resource Identifiers/Locator)이 포함될 수 있다. 다른 경우, 액세스 데이터는 애플리케이션/상태에 액세스하는데 애플리케이션이 사용할 수 있는 애플리케이션 메타데이터를 포함할 수 있다. 사용자는 다양한 애플리케이션들 및 상이한 애플리케이션들에서 애플리케이션 상태(예: 페이지)에 액세스할 수 있다.

런처 애플리케이션은 검색 결과를 사용자 선택가능한 링크로서 렌더링할 수 있으며, 이는 사용자 디바이스에 설치된 애플리케이션을 열고 그리고 애플리케이션 및 웹사이트 내의 애플리케이션 콘텐츠에 액세스할 수 있다. 예를 들어, 일부 사용자 선택가능한 링크는 애플리케이션을 열 때 일반적으로 액세스되는 애플리케이션의 메인 페이지와 같은 애플리케이션 홈 상태(예: 애플리케이션 홈 페이지)에 액세스할 수 있다. 다른 예로서, 일부 사용자 선택가능한 링크는 애플리케이션 내의 엔티티에 대한 애플리케이션 콘텐츠 상태(예: 페이지)에 액세스할 수 있다. 사용자는 검색 GUI에서 사용자가 선택할 수 있는 검색 결과 중 하나를 선택(예: 터치/클릭)할 수 있다. 사용자 디바이스는 수신된 검색 결과에 포함된 액세스 데이터를 이용하여 검색 결과와 관련된 애플리케이션 상태를 열 수 있다. 그러면 사용자는 사용자 디바이스에서 액세스된 애플리케이션 상태와 상호 작용할 수 있다. 애플리케이션이 사용자 디바이스에 설치되어 있지 않은 경우, 사용자 디바이스는 애플리케이션을 다운로드한 후 사용자가 선택한 검색 결과와 관련된 상태에 액세스할 수 있다.

도 4a는 예시적인 검색 애플리케이션 GUI(예를 들어, 런처 애플리케이션(404) 또는 다른 애플리케이션의 UI 모듈(406)에 의해 생성됨)을 도시한다. 도 4a에서, 사용자는 검색 바(420)(예를 들어, 텍스트 박스)에 부분적인 검색 질의 "ama"를 입력하며, 이는 검색을 트리거할 수 있다. 예를 들어, 사용자는 "amazon"을 입력하고 아마존(Amazon) 쇼핑 애플리케이션 또는 다른 Amazon 애플리케이션을 열 의도로 "ama"를 입력하기 시작했을 수 있다. 런처 애플리케이션(예를 들어, 검색 모듈(410))은 설치된 아래의 애플리케이션들을 열기 위해 애플리케이션 링크들(422-1, 422-2, 422-3)를 로컬적으로 식별하고 순위를 매길 수 있다: 1) Amazon 쇼핑(Shopping) 애플리케이션, 2) AMAZON PRIME® 비디오 애플리케이션 , 및 3) Amazon Music 애플리케이션. 사용자는 검색 결과 중 임의의 것을 선택(예: 터치/클릭)하여 설치된 해당 애플리케이션을 열 수 있다. 일부 구현예에서, 검색 결과는 애플리케이션 내의 콘텐츠에 대한 추가 링크를 포함할 수 있다. 예를 들어, 도 4의 아마존 쇼핑 애플리케이션 링크(422-1)는 또한, 사용자의 주문이 포함된 장바구니를 볼 수 있는 링크와 같이 아마존 쇼핑 애플리케이션의 특정 애플리케이션 상태에 대한 애플리케이션 링크를 포함할 수 있다.

도 5는 도 4b의 동작 환경을 설명하는 예시적인 방법을 도시한다. 블록(500)에서, 로컬 서비스 모듈(102-5)은 검색 시스템(110)으로부터 검색 데이터(예를 들어, 검색 인덱스, 스코어링 기능 등)를 획득한다. 블록(502)에서, 런처 애플리케이션(404)은 사용자 검색 질의를 수신한다. 블록(504)에서, 검색 모듈(410)은 사용자 검색 질의 및/또는 다른 데이터(예를 들어, 사용자 데이터, 사용자 컨텍스트 데이터 등)에 기초하여 사용자 디바이스(100)에서 로컬적으로 검색 결과를 생성한다. 검색 결과는 사용자 디바이스에 설치된 애플리케이션을 오픈하는 링크를 포함할 수 있다. 검색 모듈(410)은 검색 결과를 생성하기 위해 검색 시스템(110)으로부터 캐시된 데이터 뿐만 아니라 온-디바이스 데이터를 사용할 수 있다.

블록(506)에서, 런처 애플리케이션(404)은 검색 결과를 렌더링한다. 그런 다음 사용자는 렌더링된 검색 결과 중 하나를 선택(예: 터치/클릭)할 수 있다. 블록(508)에서, 런처 애플리케이션(404)은 검색 결과의 사용자 선택을 검출한다. 블록(510)에서, 사용자 디바이스는 검색 결과의 선택에 응답하여 설치된 애플리케이션에 대한 애플리케이션 상태에 액세스한다. 대안적으로, 블록(510)에서, 설치되지 않은 애플리케이션에 대한 검색 결과가 디스플레이되는 경우, 사용자 디바이스는 검색 결과와 연관된 애플리케이션/웹 페이지에 액세스할 수 있다. 경우에 따라 사용자 디바이스는 애플리케이션을 다운로드하기 위해 디지털 배포 플랫폼의 애플리케이션/웹 페이지에 액세스할 수 있다. 경우에 따라 사용자 디바이스는 설치 후 애플리케이션 상태로 라우팅될 수 있다(예: "딥 링크").

도 4a를 참조하면, 로컬 서비스 모듈(102-4)은 검색 모듈(410)을 포함하며, 검색 모듈(410)은 로컬 검색 데이터(예를 들어, 검색 인덱스, 검색 구성 데이터 등) 및 로컬적으로 저장된 사용자 데이터(예: 애플리케이션 사용 데이터)에 기초하여 검색 결과를 생성한다. 로컬 서비스 모듈(102-4)은 검색 시스템(110)으로부터 업데이트를 검색하는 업데이트 모듈(108-4)을 포함할 수 있다. 업데이트는 검색 모듈(410)의 기능을 수정할 수 있다. 추가로 또는 대안적으로 업데이트는 로컬 검색 데이터를 수정할 수 있다.

검색 모듈(410)은 사용자 디바이스에 포함된 검색 데이터에 기초하여 검색 결과를 생성할 수 있다. 도 4a의 사용자 디바이스에 포함된 예시적인 검색 데이터는 애플리케이션 목록 및 관련 메타데이터로 표현될 수 있다. 예시적인 검색 데이터는 또한 검색 레코드로 표현될 수 있다(예를 들어, 도 4a 및 도 6 참조).

검색 데이터는 목록, 테이블, 하나 이상의 검색 인덱스 등과 같이 검색에 사용되는 다양한 데이터 구조를 포함할 수 있다. 일부 구현예에서, 검색 데이터는 애플리케이션 목록(예: 설치된 애플리케이션 목록) 및 목록의 각 애플리케이션에 대한 관련 애플리케이션 메타데이터를 포함할 수 있다. 예를 들어, 검색 데이터는 애플리케이션 식별자(ID)의 목록 및 애플리케이션 ID에 매핑될 수 있는 해당 검색 질의를 포함할 수 있다. 추가의 예시적인 애플리케이션 메타데이터는 애플리케이션과 관련된 다른 키워드를 포함할 수 있다. 검색 모듈(410)은 검색 질의 및 애플리케이션과 연관된 애플리케이션 메타데이터 사이의 매칭에 기초하여 검색 결과에 대한 애플리케이션을 식별할 수 있다. 애플리케이션 메타데이터는 다른 사용자들이 선택을 위해 애플리케이션을 식별하기 위해 사용할 수 있는 검색 질의 및 키워드의 유형을 나타내는 검색 시스템(110)으로부터 획득된 검색 데이터에 기초할 수 있다. 일부 경우에, 애플리케이션 메타데이터는 사용자가 선택한 애플리케이션에 대응하는 검색 질의를 나타내는 로컬적으로 획득된 사용자 데이터(예: 검색 참여 데이터: search engagement data)에 기반할 수 있다.

도 6은 예시적인 검색 레코드(600)를 도시한다. 검색 레코드(600)는 애플리케이션 오픈 상태(예를 들어, 애플리케이션 홈페이지) 및/또는 다른 애플리케이션 상태(예를 들어, 기업과 같은 엔티티에 대한 애플리케이션 콘텐츠)와 같은 애플리케이션과 연관된 데이터를 포함할 수 있다. 예를 들어, 검색 레코드(600)는 특정 비즈니스 리뷰 애플리케이션에 대한 데이터를 포함할 수 있다. 다른 예로서, 검색 레코드는 레스토랑 리뷰 애플리케이션의 특정 레스토랑에 대한 데이터를 포함할 수 있다. 검색 모듈(410)은 검색 질의 및 기타 질의 데이터에 기초하여 검색 레코드를 식별하고 스코어링/필터링할 수 있다. 검색 모듈(410)은 검색 레코드에 기초하여 검색 결과를 생성할 수 있다.

검색 레코드(600)는 검색 레코드(600)를 고유하게 식별하는 검색 레코드 ID(602)를 포함할 수 있다. 검색 레코드(600)는 애플리케이션 이름/ID(604)를 포함할 수 있으며, 이는 검색 레코드(600)와 관련된 애플리케이션을 식별하는(예를 들어, 애플리케이션을 고유하게 식별함) 애플리케이션 이름 및/또는 애플리케이션 ID를 포함할 수 있다. 검색 레코드(600)은 또한 애플리케이션이 사용자 디바이스(100)에 설치되어 있는지 및/또는 애플리케이션이 과거에 사용자 디바이스(100)에 설치되었는지를 표시하는 설치 상태 표시자(606)를 포함할 수 있다.

검색 레코드(600)는 검색 모듈(410)이 검색 레코드(600)를 식별하거나 및/또는 검색 레코드(600)에 스코어링하기 위해 상용할 수 있는 검색/스코어링 데이터(608)를 포함할 수 있다. 검색/스코어링 데이터(608)는 다양한 유형의 데이터를 포함할 수 있는바 가령, 애플리케이션 설명, 애플리케이션 상태 설명, 애플리케이션과 관련된 키워드, 애플리케이션과 관련된 가능한 부분적인/완전한 질의 및 애플리케이션을 식별하는데 사용되는 기타 데이터를 포함할 수 있다. 설명 데이터는 애플리케이션 상태로부터 획득(예를 들어, 크롤링/스크래핑)된 텍스트/숫자와 같이 애플리케이션/상태와 연관된 텍스트/숫자를 포함할 수 있다. 일부 구현예에서, 설명 데이터는 우편 주소 및/또는 지리적 위치 좌표(예를 들어, 위도/경도)와 같은 지리적 위치 데이터를 포함할 수 있다. 애플리케이션 상태 및/또는 웹페이지에 대한 예시적인 설명 데이터는 또한 애플리케이션 상태(예를 들어, 비즈니스, 영화, 노래 등), 사용자 리뷰, 평가 번호 및 비즈니스 시간과 관련된 엔티티의 간략한 설명을 포함할 수 있다.

검색/스코어링 데이터(608)는 스코어링/필터링 데이터를 포함할 수 있다. 스코어링/필터링 데이터는 검색 동안 검색 레코드를 스코어링하기 위해 검색 모듈(410)에 의해 사용되는 값을 포함할 수 있다. 예시적인 스코어링 값(예를 들어, 스코어링 피처)은 인기 스코어, 리뷰 수, 등급 수, 집계 사용량 값 및 애플리케이션 다운로드 수를 포함할 수 있지만 이에 제한되지 않는다. 인기 스코어는 애플리케이션의 인기도 및/또는 애플리케이션 상태의 인기도를 나타낼 수 있다. 집계 사용량 값은 일정 기간(예를 들어, 일별/월별) 동안 복수의 사용자가 애플리케이션 상태에 액세스한 횟수를 나타내는 데이터를 포함할 수 있다. 집계 사용량 값은 다양한 지리적 위치(예: 도시, 주, 국가), 언어, 디바이스 유형, 운영 체제, 시간, 요일 및 기타 파라미터 조합에 대한 집계 값을 포함할 수 있다.

일부 구현예에서, 검색 시스템(110)은 가령, 애플리케이션이 다운로드된 횟수 및/또는 애플리케이션/상태에 액세스된 횟수를 나타내는 집계 사용량 값과 같은 집계 사용량 데이터를 기반으로 애플리케이션 및/또는 애플리케이션 상태에 대한 인기 점수를 결정할 수 있다. 인기 점수는 다른 애플리케이션 및 애플리케이션 상태에 대해 계산된 값일 수 있다. 예를 들어, 애플리케이션 인기 점수는 애플리케이션이 다른 애플리케이션에 비해 다운로드된 횟수를 나타낼 수 있다. 다른 예로서, 애플리케이션 상태 인기 점수는 애플리케이션 및/또는 다른 애플리케이션 내의 다른 애플리케이션 상태에 비해 애플리케이션 상태가 액세스된 횟수를 나타낼 수 있다. 일부 구현예에서, 검색 레코드(600)는 애플리케이션/상태에 대한 복수의 인기 점수들(예를 들어, 상이한 국가, 언어 등에 대한 인기 점수)를 포함할 수 있다.

일부 구현예에서, 검색/스코어링 데이터(608)는 애플리케이션과 관련된 집계 검색/사용량 데이터를 포함할 수 있다. 집계 검색/사용량 데이터는 복수의 사용자들로부터 검색 및 애플리케이션 사용량과 관련된 데이터를 포함할 수 있다. 예를 들어, 검색 레코드(600)은 질의에 기초하여 선택된 애플리케이션 링크와 함께 다른 사용자에 의해 사용된 부분적인/전체적인 검색 질의를 포함할 수 있다. 특정 일례에서, 페이스북 애플리케이션에 대한 검색 레코드는 복수의 개인에 의해 페이스북 애플리케이션을 검색하는데 사용되는 질의들 또는 질의 세션들에 기초하는 "fb"라는 부분적인 질의를 포함할 수 있다. 집계 검색/사용량 데이터는 또한 복수의 사용자가 애플리케이션을 어떻게 사용했는지를 나타낼 수 있다.

검색 레코드(600)은 검색 결과(예를 들어, 텍스트/이미지)를 디스플레이하는데 사용되는 디스플레이 데이터(610)를 포함할 수 있다. 검색 레코드(600)는 또한 검색 레코드(600)와 연관된 애플리케이션 상태에 액세스하기 위한 액세스 데이터(612)(예를 들어, URI/URL)를 포함할 수 있다. 일부 경우에, 액세스 데이터는 애플리케이션이 애플리케이션 상태에 액세스하기 위해 사용할 수 있는 애플리케이션 메타데이터를 포함할 수 있다. 애플리케이션 상태에 액세스하는데 사용되는 예시적인 애플리케이션 메타데이터는 애플리케이션별 엔티티 ID, 가령 비즈니스 리뷰 애플리케이션에서 비즈니스를 나타내는데 사용되는 숫자 코드와 같은 것들을 포함할 수 있다. 일부 구현예에서, 액세스 데이터(612)는 또한 애플리케이션 상태에 대응하는 웹페이지(예를 들어, 애플리케이션 상태와 동일/유사한 정보를 포함하는 웹페이지)에 액세스하기 위한 웹 URL과 같은 웹 액세스 데이터를 포함할 수 있다. 또한, 일부 구현예에서, 액세스 데이터(612)는 애플리케이션이 사용자 디바이스에 설치되지 않은 경우에 디지털 배포 플랫폼(118)으로부터 애플리케이션을 다운로드하기 위한 다운로드 링크를 포함할 수 있다.

사용자 디바이스 상에서의 검색 데이터 적용 범위는 다양할 수 있다. 일부 구현예에서, 검색 데이터는 사용자 디바이스에 설치된 애플리케이션에 대한 데이터를 포함할 수 있다. 일부 구현예에서, 검색 데이터는 사용자 디바이스에 설치된 모든 애플리케이션(예를 들어, 제거된 애플리케이션 포함)에 대한 데이터를 포함할 수 있다. 일부 구현예에서, 검색 시스템(110)은 사용자 디바이스에 설치되지 않은 추가 애플리케이션(예를 들어, N개의 가장 인기 있는 애플리케이션 세트)에 대한 검색 데이터를 포함하는 검색 데이터를 사용자 디바이스에 제공할 수 있다. 일부 구현예에서, 검색 시스템(110)은 검색 시스템(110)에 보고된 데이터의 로컬 검색 질의 및/또는 검색을 위해 검색 시스템(110)을 온라인으로 사용하는 동안 검색 시스템(110)에 제출된 질의와 같은 사용자 디바이스로부터 수신된 검색 질의들에 기초하여 사용자 디바이스에 설치된 애플리케이션을 예측할 수 있다. 일부 구현예에서, 검색 모듈(410)은 검색 동안에 식별된 미설치 애플리케이션에 대한 검색 레코드를 필터링할 수 있다.

검색 모듈(410)은 본 명세서에 기술된 다양한 데이터에 기초하여 검색 레코드을 식별하고 스코어링/필터링할 수 있다. 예를 들어, 검색 모듈(410)은 가령, 검색 질의의 텍스트와 검색 레코드 간의 매칭과 같이 질의 객체에 포함된 데이터와 검색 레코드 간의 매칭에 기초하여 검색 레코드를 식별하고 스코어링/필터링할 수 있다. 검색 모듈(410)은 또한 검색 레코드에 포함된 스코어링 피처와 같은 검색 레코드와 연관된 데이터에 기초하여 식별된 검색 레코드를 스코어링/필터링할 수 있다. 일부 구현예에서, 검색 모듈(410)은 또한 설치된 앱 및 애플리케이션과의 이전 참여와 같은 사용자 데이터에 기초하여 검색 레코드를 식별하고 스코어링/필터링할 수 있다.

검색 모듈(410)은 각각의 검색 결과에 대한 결과 점수를 생성할 수 있다(예를 들어, 스코어링 기능을 사용하여). 결과 점수는 검색 질의 및 기타 질의 데이터에 대한 검색 결과의 관련성을 나타낼 수 있다. 검색 레코드에 대한 결과 점수는 검색 질의에 대한 다른 검색 레코드들 중에서 검색 레코드의 상대적 순위를 나타낼 수 있다. 일 예에서, 결과 점수가 더 클수록 검색 레코드가 검색 질의와 더 관련이 있음을 나타낼 수 있다. 일부 구현예에서, 결과 점수는 0.00에서 1.00까지의 십진수 값일 수 있으며, 1.00에 가까운 점수는 결과가 더 관련성이 있음을 나타낼 수 있다. 검색 모듈(410)은 결과 점수에 기초하여 GUI에서 검색 결과의 순위를 매길 수 있다. 예를 들어, 점수가 높은 검색 결과는 검색 엔진 결과 페이지에서 더 높은 순위에 있을 수 있다.

검색 모듈(410)은 다양한 상이한 방식으로 결과 점수를 생성할 수 있다. 일부 구현예에서, 검색 모듈(410)은 하나 이상의 스코어링 피처에 기초하여 검색 레코드에 대한 결과 점수를 생성할 수 있다. 스코어링 피처는 검색 레코드 및/또는 검색 질의(예를 들어, 질의 객체)와 연관될 수 있다. 검색 레코드와 관련된 예시적인 스코어링 피처는 인기 값, 집계 데이터 값, 평점 등을 포함할 수 있다. 검색 모듈(410)은 여기에 나열된 하나 이상의 스코어링 피처들 및/또는 명시적으로 나열되지 않은 추가적인 스코어링 피처들에 기초하여 결과 점수를 결정할 수 있다.

일부 구현예에서, 검색 모듈(410)은 스코어링 기능을 포함할 수 있다. 예를 들어, 스코어링 기능은 복수의 스코어링 피처들에 기초하여 결과 점수를 생성할 수 있다. 일부 구현예에서, 검색 모듈(410)은 하나 이상의 스코어링 피처를 수신하고 결과 점수를 출력하도록 구성된 하나 이상의 기계 학습 모델(예를 들어, 지도 학습 모델)을 포함할 수 있다.

일부 구현예에서, 검색 모듈(410)은 사용자 데이터에 기초하여 결과 점수를 생성함으로써 결과를 개인화할 수 있다. 예를 들어, 검색 모듈(410)은 사용자에 대한 애플리케이션들의 설치 상태 및/또는 사용자에 대한 애플리케이션 사용 빈도에 기초하여 결과를 스코어링/필터링할 수 있다. 일 예에서, 검색 모듈(410)은 설치된 및/또는 사용자에 의해 사용(예: 자주 사용)되는 애플리케이션들에 대한 점수를 부스트할 수 있다. 다른 예에서, 검색 모듈(410)은 사용자 디바이스에 설치되지 않은 애플리케이션에 대한 결과를 제거할 수 있다.

일부 구현예에서, 검색 모듈(410)은 검색 질의와 검색 레코드 간의 매칭(예를 들어, 텍스트 일치)와 같은 제 1 세트의 기준에 기초하여 검색 레코드를 초기에 식별할 수 있다. 이러한 구현예에서, 검색 모듈(410)은 초기에 식별된 검색 레코드 세트로부터 검색 결과를 선택할 수 있다. 일부 구현예에서, 처음에 식별된 검색 레코드 세트는 추가로 점수가 매겨질 수 있는 검색 레코드의 "고려 세트(consideration set)"로 간주될 수 있다. 예를 들어, 고려 세트는 가중 스코어링 기능 및/또는 기계 학습 모델과 같은 스코어링 함수/모델을 사용하여 추가로 스코어링될 수 있다.

본 명세서에 기술된 바와 같이, 일부 구현예에서, 검색 모듈(410)은 사용자 데이터에 기초하여 검색 결과를 생성할 수 있다. 비록, 사용자 데이터가 검색 데이터와 별개인 것으로 예시되지만, 사용자 데이터는 로컬적으로(예를 들어, 검색 레코드에서) 검색 데이터에 통합될 수 있다. 검색에 사용되는 사용자 데이터에는 다양한 유형의 데이터가 포함될 수 있다. 사용자 데이터에는 애플리케이션 설치 및 애플리케이션 사용 데이터가 포함될 수 있다. 예를 들어, 사용자 데이터는 현재 설치된 애플리케이션, 애플리케이션이 설치된 시기, 애플리케이션이 사용된 시기, 애플리케이션 사용 빈도, 애플리케이션에서 수행된 특정 이벤트(예: 애플리케이션 열기, 페이지 보기, 상거래 이벤트 및 사용자 지정 이벤트), 애플리케이션이 제거된 시기 및 기타 애플리케이션 사용 메트릭을 나타낼 수 있다. 사용자 데이터는 사용자가 런처 애플리케이션과 어떻게 상호작용했는지 나타내는 데이터를 포함할 수 있다. 예를 들어, 사용자 데이터는 과거 검색 질의들의 목록, 과거 검색 결과 및 결과 선택을 포함할 수 있다. 사용자 데이터는 애플리케이션 설치/사용, 검색 및/또는 결과 보기/선택에 대한 타임 스탬프와 같이 여기에 설명된 임의의 이벤트에 대한 타임 스탬프를 포함할 수 있다.

일 예에서, 검색 모듈(410)은 애플리케이션 사용 데이터에 기초하여 검색 레코드을 식별하고 스코어링/필터링할 수 있다. 예를 들어, 검색 모듈(410)은 사용자가 자주 사용하는 애플리케이션 및/또는 가장 최근에 사용한 애플리케이션과 관련된 검색 결과를 부스팅할 수 있다. 다른 예에서, 검색 모듈(410)은 특정 검색 질의에 대해 사용자에 의해 선택된 애플리케이션을 나타내는 사용자 데이터에 기초하여 검색 레코드를 식별할 수 있다. 예를 들어, 사용자 데이터는 사용자가 일반적으로 페이스북(Facebook) 애플리케이션을 찾을 때 "fb"를 입력한다는 것을 나타낼 수 있다. 검색 모듈(410)은 사용자 디바이스에 로컬적으로 학습되고 저장된 개인 사용자 데이터에 기초하여 검색 레코드를 식별할 수 있을 뿐만 아니라 다른 사용자로부터 학습된 사용자 행동 데이터를 집계할 수 있다. 본 명세서에 기술된 바와 같이, 집계 사용자 행동 데이터는 원격 검색 시스템(110) 및 원격 광고 시스템(112)으로부터 획득될 수 있다.

사용자는 검색 질의 입력에 응답하여 하나 이상의 특정 애플리케이션을 찾을 의도로 런처 애플리케이션(404)을 사용할 수 있다. 예를 들어, 사용자는 하나의 특정 애플리케이션을 찾을 의도로 검색 질의를 입력할 수 있다. 입력된 검색 질의에 대한 검색 결과에서 사용자가 찾고자 하는 특정 애플리케이션(또는 애플리케이션들)을 "의도된 애플리케이션"이라고 할 수 있다. 특정 예에서, 사용자가 페이스북 애플리케이션을 열기 위한 링크를 찾을 의도로 검색 질의 "fb"를 입력하면, 페이스북 애플리케이션은 검색 질의에 대한 의도된 애플리케이션으로 간주될 수 있다.

검색 모듈(410)은 다양한 방식으로 애플리케이션을 의도된 애플리케이션으로 식별(예컨대, 예측)할 수 있다. 일부 구현예에서, 검색 모듈(410)은 제 1 애플리케이션 결과(예를 들어, 최고 점수 결과)를 의도된 애플리케이션으로 지정할 수 있다. 일부 구현예에서, 검색 모듈(410)은 의도된 애플리케이션으로 지정될 애플리케이션에 대한 추가/대체 요구 사항을 포함할 수 있다. 예를 들어, 검색 모듈(410)은 검색 결과 점수(예: 애플리케이션의 관련성을 나타냄)가 임계 점수보다 큰 경우 애플리케이션을 의도된 애플리케이션으로 식별할 수 있다. 다른 예로, 검색 모듈(410)은 검색 결과 점수가 검색 결과에서 다른 검색 결과 점수보다 임계값 만큼 큰 경우 애플리케이션을 의도된 애플리케이션으로 식별할 수 있다. 일부 구현예에서, 검색 모듈(410)은 검색 질의의 전부(또는 일부)가 애플리케이션과 관련된 문자열(string)과 일치할 것을 요구할 수 있다(예를 들어, 애플리케이션 메타데이터에서). 일부 구현예에서, 검색 모듈(410)은 의도된 애플리케이션이 임계 사용량(예를 들어, 특정 기간 동안)과 연관될 것을 요구할 수 있다.

로컬 서비스 모듈(102)은 시간이 지남에 따라 자신의 검색 기능(예를 들어, 검색 레코드 식별, 스코어링 및 필터링 기능)을 업데이트할 수 있다. 로컬 서비스 모듈(102)은 또한 시간이 지남에 따라 자신의 검색 데이터를 업데이트할 수 있다. 예를 들어, 로컬 서비스 모듈(102)은 로컬 서비스 모듈(102)에 대한 기능 및 데이터를 업데이트하는 업데이트 모듈(108)을 포함할 수 있다. 업데이트 모듈(108)은 업데이트된 검색 기능 및 검색 데이터(예를 들어, 검색 레코드에 대한)를 검색 시스템(110)으로부터 획득할 수 있다.

일부 구현예에서, 업데이트 모듈(108)은 애플리케이션 사용, 검색 사용 및/또는 검색 결과 보기/선택 데이터를 검색 시스템(110)에 보고할 수 있으며, 따라서 검색 시스템(110)은 원격 사용자 및/또는 집계 데이터(예를 들어, 복수의 사용자로부터의 집계 데이터)를 업데이트할 수 있다. 예시적인 업데이트된 검색 데이터는 키워드(예: 대체 키워드), 인기 점수, 카테고리 정보 등을 포함하지만 이에 제한되지 않는 특정 애플리케이션(예: 애플리케이션 패키지)과 관련된 임의의 정보를 포함할 수 있다. 일부 구현예에서, 업데이트 모듈(108)은 주기적으로 및/또는 이전 업데이트 이후 임계 시간이 경과한 후와 같이 다양한 시간에서 검색 시스템(110)에 업데이트 요청을 할 수 있다. 일부 구현예에서, 업데이트 모듈(108)은 이전에 연결해제된/느린 인터넷 연결의 재개에 응답하여 업데이트를 획득하도록 구성될 수 있다. 일부 구현예에서, 검색 시스템(110)으로/으로부터 전송된 데이터는 특정 사용자 동작을 사용자의 디바이스에 연관시키는 것을 방지하기 위해 취합되거나, 난독화되거나, 또는 그렇지 않으면 프리-프로세싱(전처리)될 수 있다. 예를 들어, 차등 프라이버시(differential privacy)의 형태 또는 연합 학습(federated learning)의 형태가 구현될 수 있다.

업데이트 모듈(108)은 설치된 애플리케이션에 대한 업데이트 요청과 같이 개인화된 검색 시스템(110)에 대한 업데이트 요청을 생성할 수 있다. 일부 구현예에서, 업데이트는 새로 설치된 애플리케이션에 대한 검색 레코드 및/또는 마지막 로컬 서비스 모듈 업데이트 이후 검색 시스템(110)에서 업데이트된 데이터와 같은, 마지막 업데이트 이후 변경 사항으로 제한되는 "델타(delta)"일 수 있다. 일부 구현예에서 업데이트는 특정한 지리적 위치 또는 기타 데이터에 맞춤화될 수 있다. 일부 구현예에서, 검색 시스템(110)은 어떤 애플리케이션들이 사용자 디바이스에 설치되는지를 결정 및/또는 예측할 수 있다. 예를 들어, 설치된 애플리케이션의 목록(예를 들어, 블룸 필터, 차등 프라이버시 및/또는 보안 해싱 방법을 사용하여) 및/또는 어떤 애플리케이션이 설치되었는지를 검색 시스템(110)이 예측할 수 있게 하는 데이터(예를 들어, 질의 히스토리)가 사용자 디바이스에 의해 전송될 수 있다. 경우에 따라, 검색 데이터는 사용자에 대해 개인화되지 않을 수도 있다.

일부 구현예에서, 검색 시스템(110)은 업데이트를 사용자 디바이스에 푸시할 수 있다. 또한, 업데이트는 배터리 레벨 및/또는 네트워크 상태에 영향을 받을 수도 있다. 예를 들어, 업데이트를 요청하기 위한 결정은 임계 배터리 레벨 및/또는 연결 레벨과 같은 업데이트 기준을 가질 수 있다.

로컬 서비스 모듈(102)은 인터넷 연결 상태에 기초하여 거동을 수정할 수 있다. 예를 들어, 일부 검색 레코드에는 인터넷 연결 상태에 따라 검색 결과가 표시되어야 함을 나타내는 메타데이터가 포함될 수 있다. 일 예에서, 애플리케이션 재참여 결과(application re-engagement results)인 특정 애플리케이션 링크는 링크가 원격 리소스(예를 들어, 애플리케이션 특정 서버에서)에 액세스할 때와 같이, 인터넷 연결이 보여지기를 요구할 수 있다.

비록, 사용자 디바이스 상에서의 로컬 검색에 이용하기 위한 데이터를 검색 시스템(110)이 제공할 수도 있지만, 일부 구현예에서, 검색 시스템(110)은 로컬 서비스 모듈(102)에 검색 결과를 제공할 수 있다. 예를 들어, 일부 경우, 검색 모듈(410)은 검색 시스템(110)으로부터 검색 결과를 검색할 수 있다. 검색 시스템(110)(예를 들어, 서버 검색 모듈(416) 및 서버 검색 데이터(418))은 검색 모듈(410)과 유사한 동작(예를 들어, 식별/스코어링/선택 동작)을 사용하여 검색 결과를 생성할 수 있다. 일부 구현예에서, 충분히 관련된 결과가 로컬적으로 이용가능하지 않은 경우, 검색 모듈(410)은 대비책(fallback)으로서 원격 검색 시스템(110)으로부터 결과를 검색할 수 있다. 일부 구현예에서, 검색 모듈(410)은 인터넷 연결 불량/이용불가능으로 인해 원격 검색 시스템(110)을 사용할 수 없는 경우에 로컬 검색 결과를 제공할 수 있다.

도 7은 런처 애플리케이션(404)의 동작을 설명하는 예시적인 방법을 도시한다. 블록(700)에서, 로컬 서비스 모듈(102-5)(예를 들어, 업데이트 모듈 108-5)은 검색 시스템(110)으로부터 검색 데이터를 획득한다. 블록(702)에서, 로컬 서비스 모듈(102-5)(예를 들어, 검색 모듈 410)은 검색 질의(예를 들어, 런처 애플리케이션(404)에 입력된)를 수신한다. 블록(704)에서, 검색 모듈(410)은 수신된 검색 질의에 기초하여 검색 레코드의 고려 세트(consideration set)를 식별한다. 블록(706)에서, 검색 모듈(410)은 검색 결과의 최종 세트를 결정하기 위해 검색 레코드의 고려 세트를 스코어링한다. 블록(708)에서, 런처 애플리케이션(404)(예를 들어, UI 모듈 406)은 최종 검색 결과를 디스플레이한다(예컨대, 사용자 선택가능한 링크로서).

블록(710)에서, 업데이트 모듈(108-5)은 검색 데이터를 업데이트할지 여부를 결정한다. 업데이트 모듈(108-5)이 업데이트를 요청/수신하면, 업데이트 모듈(108-5)은 블록(700)에서 수신된 업데이트에 기초하여 로컬 서비스 모듈(102-5)을 업데이트한다. 업데이트 모듈(108-5)이 업데이트를 요청/수신하지 않으면, 로컬 서비스 모듈(102-5)은 블록(702)에서 향후 검색 질의를 수신하고 이전에 수신된 업데이트 데이터를 사용하여 검색을 수행할 수 있다.

도 8a-8b는 로컬 온-디바이스 광고 기능을 제공하는 로컬 서비스 모듈(102)의 예시적인 구현을 도시한다. 로컬 광고 기능은 사용자 디바이스에 로컬적으로 저장된 데이터에 기초하여 광고 결과를 제공할 수 있다. 예를 들어, 로컬 광고 기능은 디바이스에서 액세스된 애플리케이션 페이지, 사용자 검색 질의, 검색 결과 및 기타 파라미터를 기반으로 광고 결과를 제공할 수 있다. 광고 결과는 "광고"로 지칭될 수 있으며, 이는 검색 GUI 또는 애플리케이션 페이지와 같은 GUI에서 광고 링크로 렌더링될 수 있다. 도 8a-8b는 또한 로컬 서비스 모듈(102)에 의해 제공되는 광고 기능에 대한 업데이트를 제공할 수 있는 원격 서비스 시스템(예를 들어, 광고 시스템 112)을 포함한다. 부가적으로, 일부 구현예에서, 광고 시스템(112)은 원격 광고 기능을 제공할 수 있다.

예시적인 광고는 사용자 디바이스에 설치되지 않은 애플리케이션을 광고하는 애플리케이션 설치 광고를 포함할 수 있다. 설치 광고(예: 설치 광고 링크)는 애플리케이션을 다운로드하기 위한 디지털 배포 플랫폼으로 사용자를 안내할 수 있다. 광고는 또한 사용자 디바이스에 설치된 애플리케이션을 오픈하는 재참여 광고를 포함할 수 있다(예컨대, 애플리케이션 홈페이지로 또는 특정 애플리케이션 엔티티 페이지로).

도 8a에서, 로컬 서비스 모듈(102-6)은 하나 이상의 애플리케이션(800, 802)(예를 들어, 검색 애플리케이션(800), 웹 브라우저, 또는 다른 애플리케이션)에 대한 광고 서비스(예를 들어, "로컬 광고 서버")의 역할을 한다. 도 8a에서, 애플리케이션(800, 802)은 로컬 서비스 모듈(102-6)에 광고 요청을 하고 그리고 로컬 서비스 모듈(102-6)로부터(예를 들어, 인터페이스 모듈을 통해) 광고 응답(예를 들어, 광고 결과)을 수신할 수 있다. 도 8b에서, 로컬 서비스 모듈(102-7)은 런처 애플리케이션(804)에 통합된다. 추가적으로, 도 8b의 로컬 서비스 모듈(102-7)은 도 4A-7을 참조하여 서술된 바와 같이 검색 기능을 포함한다. 또한, 런처 애플리케이션(804)은 런처 UI 모듈(806) 및 런처 애플리케이션(804)에 의해 제공되는 다른 기능(예를 들어, 추가 런처 앱 모듈(808))과 같이, 런처 애플리케이션(804)과 관련된 기능을 제공하는 추가 모듈을 포함한다.

로컬 서비스 모듈(102-6 , 102-7)은 로컬 광고 기능을 제공하는 광고 모듈(810)("ad 모듈 810") 및 로컬 데이터(104)(예를 들어, 광고 데이터 및 기타 데이터)를 포함한다. 예를 들어, 광고 모듈(810)은 광고 요청을 수신하고 광고 요청에 기초하여 광고 응답(예: 광고 결과)을 생성할 수 있다. 광고 요청 애플리케이션(예, 도 8a 참조) 또는 런처 애플리케이션 모듈(예, 도 8b 참조)은 광고 결과를 GUI에 렌더링할 수 있다. 도 8b의 로컬 서비스 모듈(102-7)은 본 명세서에 기술된 검색 기능을 제공할 수 있는 검색 모듈(410)을 포함한다. 비록, 광고를 생성하기 위해 검색 기능이 요구되는 것은 아니지만, 일부 구현예에서, 광고 모듈(810)은 검색과 관련된 다양한 파라미터에 기초하여 광고 결과를 제공할 수 있다. 예를 들어, 광고 모듈(810)은 검색 결과, 사용자의 검색 질의 및/또는 다른 검색 파라미터에 기초하여 광고를 타겟팅할 수 있다. 일부 구현예에서, 다른 검색 파라미터는 예측된 검색 카테고리, 예측된 사용자 의도 등과 같이, 검색과 관련하여 알고리즘적으로 생성된 신호를 포함할 수 있다.

본 명세서에 기술된 바와 같이, 광고 기능을 포함하는 로컬 서비스 모듈(102)은 애플리케이션에 대한 서비스 또는 애플리케이션의 컴포넌트(예를 들어, 런처 애플리케이션의 광고 컴포넌트)와 같은 다양한 방식으로 구현될 수 있다. 일부 경우에, 로컬 서비스 모듈(102-7)이 런처 애플리케이션(804)에 포함되는 도 8b의 구현예를 참조하여 광고 모듈 기능이 여기에서 설명될 수 있다. 이러한 경우에, 광고 모듈(810)에 의해 제공되는 광고 기능은 또한 일반적으로 로컬 서비스 모듈(102-7) 및/또는 런처 애플리케이션(804)에 기인될 수 있다.

로컬 서비스 모듈(102)은 광고 시스템(112)으로부터 초기 광고 데이터를 수신하고 그리고 광고 시스템(112)으로부터의 광고 데이터 업데이트에 기초하여 로컬 광고 데이터를 후속적으로 업데이트할 수 있다. 광고 모듈(810)은 광고 콘텐츠 및 광고 타겟팅 파라미터와 같이 사용자 디바이스에 로컬적으로 저장된 데이터에 기초하여 광고를 제공할 수 있다. 광고 모듈(810)이 로컬 데이터를 사용하여 광고를 선택할 수도 있지만, 일부 구현예에서, 광고 모듈(810)은 광고 시스템(112)으로부터 광고를 요청할 수 있다. 광고 시스템(112)은 원격 광고 기능을 제공하는 서버 광고 모듈(812) 및 서버 광고 데이터(814)를 포함할 수 있다. 광고 시스템(112)은 광고 기능/데이터 업데이트를 제공할 수 있는 서버 광고 업데이트 모듈(816) 및 서버 광고 업데이트 데이터(818)를 포함할 수 있다.

환경은 예를 들어 웹/애플리케이션 광고 캠페인 인터페이스를 통해 광고 시스템(112)과 통신하는 광고주 디바이스(122)를 포함한다. 광고주는 캠페인 인터페이스를 사용하여 광고 시스템(112)에 광고 데이터를 제공하기 위해 광고 디바이스(122)를 사용할 수 있다. 환경은 또한 광고 시스템(112)에 광고(예를 들어, 광고주 디바이스(122)에 의해 생성됨)를 제공할 수 있는 광고 네트워크(124)를 포함할 수 있다. 이후, 광고 시스템(112)은 광고를 사용자 디바이스에 제공할 수 있다. 광고 시스템(112)이 광고 데이터를 사용자 디바이스에 제공할 수 있지만, 일부 구현예에서, 광고주(예를 들어, 광고주 디바이스(122) 및/또는 광고 네트워크(124))는 광고 데이터를 사용자 디바이스에 직접 제공할 수 있다.

예시적인 광고 데이터는 사용자 디바이스 상에 광고 결과를 생성하기 위한 광고 콘텐츠(예를 들어, 이미지/텍스트)를 포함할 수 있다. 광고 데이터는 또한, 광고를 언제 보여줄지를 정의하는 광고 타겟팅 파라미터를 포함할 수 있다. 예를 들어, 광고주는 충족될 때 광고 디스플레이로 이어질 수 있는 광고에 대한 타겟팅 파라미터를 지정할 수 있다. 예시적인 광고 타겟팅 파라미터는 검색 결과와 관련된 데이터, 의도된 애플리케이션(예: 제 1 검색 결과), 사용자의 컨텍스트(예: 지리적 위치, 디바이스 파라미터 등), 사용자의 역사적인 웹/애플리케이션 사용예들 및/또는 사용자의 현재의 부분적인/전체적인 검색 질의를 포함할 수 있지만 이에 제한되지 않는다. 광고주는 질의 광고에 대한 입찰 가격을 지정할 수도 있다. 광고주는 또한 광고 표시 빈도에 대한 제한(예: 하루에 한 번 제한)을 지정할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102)은 광고를 개인화할 수 있다(예를 들어, 사용자 데이터에 기초하여 광고를 선택함). 일부 구현예에서, 로컬 서비스 모듈(102)은 사용 데이터를 광고 시스템(112)에 보고할 수 있다. 예시적인 사용 데이터는 광고 상호작용 데이터(예를 들어, 광고 보기/광고 선택)를 포함할 수 있다.

광고 선택이 로컬에서 수행는 경우, 가령, 검색 질의 입력에 응답하여 및/또는 애플리케이션 페이지에 액세스하는 것에 응답하는 것과 같이, 광고는 사용자에게 즉시 보여질 수 있다. 예를 들어, 로컬 서비스 모듈(102)은 사용자가 하나의 질의 문자를 입력하는 것에 응답하여 광고를 제공할 수 있다. 원격 광고 시스템(112)으로부터 획득/업데이트될 수 있는 로컬 광고 데이터는 즉각적이고 관련된 광고를 제공하기 위해 사용될 수 있다. 또한 애플리케이션 설치/사용 데이터와 같은 로컬 사용자 데이터를 사용하여 광고의 개인화 및 관련성을 향상시킬 수 있다. 개인화 및 관련성을 향상시키기 위해 로컬 사용자 데이터를 사용하면 사용자의 프라이버시도 또한 유지할 수 있는데, 이는 로컬 데이터가 사용자 디바이스에서 관리될 수 있기 때문이다.

광고가 로컬적으로 생성되는 경우, 로컬 서비스 모듈(102)은 즉각적이고 관련된 광고를 신뢰할 수 있는 방식으로 제공할 수 있다. 예를 들어, 로컬 서비스 모듈(102)은 인터넷 연결 상태에 상관없이 광고를 제공할 수 있다. 특정 예에서, 로컬 서비스 모듈(102)은 인터넷 연결이 없거나 인터넷 연결이 좋지 않은 경우에도 관련 광고를 제공할 수 있다. 비록, 로컬 서비스 모듈(102)이 로컬적으로 광고를 제공할 수 있지만, 일부 구현예에서 로컬 서비스 모듈(102)은 원격 광고 시스템(112)으로부터 광고를 검색할 수 있다.

런처 애플리케이션(804)은 검색 결과에 하나 이상의 광고를 디스플레이할 수 있다. 예를 들어, 광고는 애플리케이션 다운로드(예: 디바이스에 설치되지 않은 애플리케이션)에 관한 것이거나 및/또는 사용자가 자신의 디바이스에 설치한 애플리케이션에 대한 링크일 수 있다. 광고(예: 광고 링크)는 검색 결과와 유사한 데이터를 포함할 수 있다. 예를 들어, 재참여(re-engagement) 광고는 애플리케이션 홈페이지 및/또는 다른 애플리케이션 상태를 오픈할 수 있다. 다른 예로, 설치 광고는 링크에서 광고된 어플리케이션을 다운로드하기 위해 디지털 유통 플랫폼에 액세스하는 액세스 데이터를 포함할 수 있다.

도 8a는 광고(820)를 포함하는 예시적인 검색 GUI를 도시한다. 예시적인 GUI는 검색 애플리케이션, 런처 애플리케이션, 또는 다른 애플리케이션과 같은 사용자 디바이스 상의 애플리케이션에 의해 생성될 수 있다. GUI는 도 4A와 관련하여 본 명세서에서 설명된 바와 같이 생성될 수 있는 검색 결과를 포함한다. 도 8a에서, 사용자는 부분적인 검색 질의 "ama"를 검색 바(420)(예를 들어, 텍스트 박스)에 입력하며, 이는 검색 및 광고를 트리거할 수 있다. 도 8a에서, 로컬 서비스 모듈(102)(예를 들어, 광고 모듈 810)은 월마트(Walmart) 쇼핑 애플리케이션에 대한 광고를 로컬적으로 선택한다(예를 들어, 타겟팅 파라미터 및/또는 스코어링에 기초하여). 애플리케이션(예를 들어, 런처 애플리케이션)은 로컬적으로 선택된 광고를 렌더링할 수 있다. 사용자는 월마트 쇼핑 애플리케이션 광고 링크(820)를 선택(예를 들어, 터치/클릭)하여 디지털 배포 플랫폼에 액세스하고 그리고 월마트 쇼핑 애플리케이션을 다운로드할 수 있다. 광고가 특정 애플리케이션 상태에 대한 것인 경우, 사용자 디바이스는 월마트 쇼핑 애플리케이션을 설치 및 실행한 이후에 자동으로 특정 애플리케이션 상태로 안내될 수 있다.

도 9는 도 8A의 환경의 동작을 설명하는 예시적인 방법을 도시한다. 블록(900)에서, 광고주는 광고주 디바이스(122)를 이용하여, 광고 시스템(112)을 위한 광고 데이터를 생성한다. 블록(902)에서 광고 시스템(112)은 로컬 서비스 모듈(102-6)에 광고 데이터를 제공한다. 블록(904)에서, 사용자 디바이스 상의 애플리케이션(예를 들어, 요청 애플리케이션)은 로컬 서비스 모듈(102-6)로부터 광고를 요청한다.

요청 애플리케이션은 하나 이상의 트리거에 응답하여 로컬 광고 요청(local ad request)을 생성할 수 있다. 예시적인 트리거는 사용자가 애플리케이션을 여는 것, 애플리케이션의 특정 상태에 사용자가 액세스하는 것, 애플리케이션 내의 애플리케이션 상태들 사이에서 사용자가 전환하는 것, 및/또는 애플리케이션 내의 다른 동작을 포함할 수 있다. 일부 구현예에서 트리거는 애플리케이션 유형에 따라 달라질 수 있다. 예를 들어, 요청 애플리케이션이 검색 애플리케이션인 경우, 검색 박스를 보여주는 것 및/또는 검색을 실행하는 것에 응답하여 로컬 광고 요청이 트리거될 수 있다. 다른 예에서, 요청 애플리케이션이 런처 애플리케이션인 경우, 사용자가 런처의 특정 화면에 액세스하는 것에 응답하여 및/또는 사용자 제스처에 응답하여 로컬 광고 요청이 트리거될 수 있다. 일부 구현예에서, 요청 애플리케이션은 사용자 디바이스가 인터넷(예를 들어, 원격 광고 시스템(112))에 대한 충분한 연결을 갖지 않을 때 로컬 광고 요청을 생성하도록 구성될 수 있다. 일부 구현예에서, 사용자 디바이스가 가령, 셀룰러 데이터에서 WiFi 로 전환하는 것 또는 사용자가 빠른 이동 이후에 정적으로 되는 경우(예: 운전 이후에 걷거나/앉는 것)와 같이 사용자 상태의 변화를 나타낼 때, 요청 애플리케이션은 로컬 광고 요청을 생성하도록 구성될 수 있다.

일부 구현예에서, 로컬 광고 요청은 로컬 서비스 모듈이 광고를 선택하기 위해 사용할 수 있는 광고 요청 데이터를 포함할 수 있다. 예를 들어, 광고 요청은 특정한 애플리케이션 화이트리스트/블랙리스트, 애플리케이션 카테고리 제한 또는 기타 제한과 같은 광고 선택에 대한 제한을 포함할 수 있다. 제한 데이터를 사용하면, 로컬 서비스 모듈과 요청 애플리케이션은 사용자에게 광고되는 콘텐츠를 제어할 수 있다(가령, 사용자에게 광고될 수 있는 애플리케이션들). 일부 구현예에서, 광고 요청은 사용자에 대한 정보와 같이 요청 애플리케이션에 의해 제공되는 정보를 포함할 수 있다. 사용자에 대한 정보의 일례는 GPS 데이터, 사용자 인구통계 데이터(예: 연령 또는 성별), 예상 사용자 카테고리 또는 그룹 정보(예: "자주 클릭하는 사람", 스포츠를 좋아함 등), 요청 애플리케이션 자체에 대한 정보, 사용자가 입력한 검색 질의 및/또는 사용자가 보고 있는 현재 콘텐츠 또는 페이지 등과 같은 사용자 컨텍스트를 포함할 수 있다. 로컬 서비스 모듈은 광고 요청에 포함된 추가 정보를 기반으로 사용자에게 보다 관련성 있는/개인화된 광고를 제공할 수 있다. 일부 구현예에서, 광고 요청은 광고 크기(예를 들어, 픽셀 크기), 색상 또는 기타 렌더링 정보와 같은 광고 렌더링 정보를 포함할 수 있다.

블록(906)에서, 로컬 서비스 모듈(102-6)(예를 들어, 광고 모듈 810)은 광고 요청에 응답하여 광고를 선택한다. 블록(908)에서, 로컬 서비스 모듈(102-6)은 선택된 광고를 요청 애플리케이션에 제공한다. 블록(910)에서, 요청 애플리케이션은 광고를 사용자에게 디스플레이한다. 블록(912-914)에서, 사용자는 광고를 선택하고 사용자 디바이스는 선택에 응답한다. 예를 들어, 사용자 디바이스는 광고와 관련된 애플리케이션/웹 페이지에 액세스할 수 있다. 광고가 애플리케이션 다운로드를 위한 것이라면, 사용자 디바이스는 광고된 애플리케이션을 다운로드하기 위해 디지털 배포 플랫폼이 제공하는 애플리케이션/웹 페이지에 접속할 수 있다.

도 8a에 도시된 바와 같이, 광고 모듈(810)은 로컬 광고 데이터 및 로컬적으로 저장된 사용자 데이터(예를 들어, 애플리케이션/광고 사용 데이터)와 같은 다른 데이터에 기초하여 광고를 생성할 수 있다. 로컬 서비스 모듈은 또한 광고 시스템(112)으로부터 업데이트를 검색하는 업데이트 모듈(108-6)을 포함할 수 있다. 업데이트는 광고 모듈(810)의 기능을 수정할 수 있다. 추가로 또는 대안적으로 업데이트는 로컬 광고 데이터를 수정할 수 있다.

광고 데이터는(예를 들어, 광고 캠페인 인터페이스에서) 광고 시스템(112)과 상호작용하는 광고주에 의해 생성된 광고 레코드(1000)(예를 들어, 도 10 참조)을 포함할 수 있다. 광고 레코드(1000)는 광고와 관련된 데이터를 포함할 수 있다. 예를 들어, 광고 레코드(1000)는(예를 들어, 광고를 렌더링하는데 사용되는) 광고 콘텐츠(1006) 및 (예를 들어, 광고를 선택하는데 사용되는) 타겟팅 파라미터(1008)를 포함할 수 있다.

광고주는 광고주 디바이스(122)를 사용하여 광고 레코드에 포함된 광고에 대한 파라미터를 정의할 수 있다. 예를 들어, 광고주 디바이스는 광고 시스템(112)에 의해 제공되는 광고주 인터페이스(예를 들어, 웹/애플리케이션 기반 인터페이스)에 액세스할 수 있다. 광고주 인터페이스는 광고주가 광고와 관련된 데이터를 정의할 수 있게한다(예를 들어, 도 8A 및 도 10에 예시된 데이터).

광고주는 디스플레이되는 광고에 포함될 텍스트 및/또는 이미지와 같은 광고의 콘텐츠(예를 들어, 광고 콘텐츠 1006)를 정의할 수 있다. 예시적인 광고 콘텐츠는 애플리케이션, 애플리케이션 상태, 웹페이지, 제품 또는 서비스를 설명하는 앱 아이콘 및 이미지/텍스트와 같이 여기에 설명된 임의의 데이터를 포함할 수 있다. 일부 구현예에서, 광고주는 광고에 대한 사용자 선택에 응답하여 요청 애플리케이션에 의해 사용될 URI/URL과 같은, 광고 선택에 응답하여 취해질 조치를 지정할 수 있다. 또한, 광고주는 하나 이상의 광고 타겟팅 파라미터를 지정할 수 있다.

광고주는 광고주가 광고와 관련된 행동에 대해 지불할 금액을 나타내는 광고에 대한 입찰액(bid)(1010)을 지정할 수 있다. 예를 들어, 입찰액은 광고 노출, 광고 선택 및/또는 광고 선택 이후의 행위를 수행(예: 애플리케이션 설치, 구매 등)하기 위한 금액일 수 있다. 광고 레코드는 또한 광고 시스템(112)에서 광고를 고유하게 식별하는 광고 식별자/이름(1002)을 포함할 수 있다. 광고 레코드(1000)는 또한 광고주 이름 및 광고 캠페인 이름(1004)과 같이 광고주를 식별하는 다른 정보를 포함할 수 있다.

일부 구현예에서, 광고 레코드는 광고를 선택/스코어링하기 위해 사용될 수 있는 광고와 관련된 다른 데이터를 포함할 수 있다. 예를 들어, 광고 레코드는 다른 사용자 및/또는 사용자 디바이스에 의해 광고가 표시/선택되는 다른 시나리오에서 광고가 어떻게 수행되었는지를 나타내는 광고 성능 데이터를 포함할 수 있다. 다른 예로, 광고 레코드(예를 들어, 광고 파라미터)는 광고 인기도를 나타내는 데이터를 포함할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102)(예를 들어, 광고 모듈(810) 및/또는 로컬 데이터 모듈(424))은 성능 메트릭을 결정하고 및/또는 어트리뷰션(attribution) 기능을 수행할 수 있다. 예시적인 성능 메트릭은 광고 보기, 광고 선택, 애플리케이션 설치, 구매 및/또는 광고 선택과 관련된 기타 다운스트림 활동을 추적할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 애플리케이션이 설치되었음을 검출하는 것과 같이 사용자의 디바이스 상의 데이터를 모니터링함으로써 성능 메트릭을 결정하고 및/또는 어트리뷰션을 수행할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 디바이스의 다른 애플리케이션으로부터 통신을 수신하고 그리고 어트리뷰션, 광고 타겟팅 개선 및/또는 광고의 자동 생성 또는 업데이트를 위해 이를 활용할 수 있다. 예를 들어, 쇼핑 애플리케이션은 사용자가 구매했다는 메시지를 로컬 서비스 모듈(102)에 보낼 수 있다. 이러한 메시지는 사용자가 이전에 보았던 광고에 대한 어트리뷰션을 위해 이용되는 정보를 제공할 수 있다. 또한, 상기 정보는 광고 노출의 기회를 증가시키는 온-디바이스 모델을 업데이트하는데 사용될 수도 있다. 또한, 이러한 정보는 특정 쇼핑 앱에 대해 대기 중인 광고를 자동으로 비활성화하는데 사용될 수도 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 다른 소스들(예를 들어, 다른 데이터 제공자 및/또는 번들 업데이트)로부터 획득된 데이터에 기초하여, 성능 메트릭을 결정하고 및/또는 어트리뷰션을 수행할 수 있다.

광고 레코드는 본 명세서에 기술된 하나 이상의 타겟팅 파라미터를 포함할 수 있다. 일부 구현예에서, 타겟팅 파라미터는 광고를 선택하기 위해 검색 결과에서 의도된 애플리케이션으로 식별되어야 하는 하나 이상의 애플리케이션을 지정하는 "의도된 애플리케이션" 타겟팅 파라미터를 포함할 수 있다. 예를 들어 월마트 스토어(Walmart Stores)가 월마트 애플리케이션을 광고하는 경우, 월마트 스토어 광고주는 타겟 쇼핑 애플리케이션이 검색 결과에서 의도된 애플리케이션이라면, 월마트 쇼핑 애플리케이션이 디스플레이되도록 지정할 수 있다.

일부 구현예에서, 타겟팅 파라미터는 광고를 트리거하기 위해 검색 결과에서 제시되어야만 하는 하나 이상의 애플리케이션을 나타낼 수 있다. 광고주는 지정된 애플리케이션(들)이 처음 N개의 검색 결과들(예를 들어, 처음 3개의 검색 결과) 내에 나타나야 한다고 추가로 지정할 수 있다. 일부 구현예에서, 타겟팅 파라미터는 광고 선택을 트리거하는 하나 이상의 부분적인/완전한 검색 질의를 나타낼 수 있다. 일부 구현예에서, 타겟팅 파라미터는 검색 결과와 연관된 최소 점수를 나타낼 수 있다(예를 들어, 적어도 75% 관련/신뢰하는 경우에만 검색 결과를 고려함).

일부 구현예에서, 타겟팅 파라미터는 하나 이상의 애플리케이션이 설치되어야 하는지 여부를 나타낼 수 있다. 예를 들어, 재참여 광고의 경우, 재참여 광고와 관련된 애플리케이션이 설치되어야 한다. 다른 예에서, 광고주는 하나 이상의 애플리케이션이 설치되어야함(또는 설치되어서는 안 됨)을 나타낼 수 있다. 일부 구현예에서, 타겟팅 파라미터는 가령, 애플리케이션 또는 유사한 애플리케이션이 사용되는 빈도, 애플리케이션이 마지막으로 사용된 시기, 및 애플리케이션 카테고리들에 대한 사용자의 과거 참여(예를 들어, 애플리케이션들이 카테고리들과 연관되는 경우) 등과 같은 애플리케이션 사용예에 기초할 수도 있다. 일부 구현예에서, 타겟팅 파라미터는 의도된 애플리케이션 및/또는 검색 결과 내의 다른 애플리케이션들이 특정한 하나 이상의 애플리케이션 카테고리(예를 들어, 레스토랑, 소셜 미디어, 금융 등)에 대응하는 경우, 광고가 표시되어야 함을 나타낼 수 있다. 일부 구현예에서, 사용자의 행동(예를 들어, 앱 참여, 물리적 움직임 또는 기타 행동)은 운동, 건강 식품 또는 기타 관심사와 같은 사용자의 관심사(예를 들어, 관심 카테고리)를 제안할 수 있다. 이러한 구현예에서, 타겟팅 파라미터는 사용자의 관심사(예를 들어, 사용자 행동에 기초하여 결정됨)를 포함할 수 있다.

일부 구현예에서, 타겟팅 파라미터는 특정 애플리케이션이 삭제되었는지 또는 삭제된 적이 없는지 여부를 포함할 수 있다. 일부 구현예에서, 타겟팅 파라미터는 애플리케이션의 인기도(예를 들어, 다운로드 횟수 및/또는 집계 사용량에 기초함)를 포함할 수 있다. 일부 구현예에서, 타겟팅 파라미터는 사용자의 지리적 위치, 하루 중 시간 및 사용자 디바이스 데이터(예: 디바이스 유형, OS 등)를 포함할 수 있다.

일부 구현예에서, 타겟팅 파라미터는 광고가 표시된 횟수 및 사용자가 광고를 선택(예를 들어, 터치/클릭)했는지 및/또는 광고와 관련된 애플리케이션을 설치했는지를 지정할 수 있다. 사용자가 과거에 광고를 선택하지 않았고 광고된 애플리케이션/컨텐츠를 설치 및/또는 재참여하지 않은 경우, 광고주가 광고를 표시하는 것이 덜 바람직할 수 있다.

일부 구현예에서, 재참여 광고의 경우, 타겟팅 파라미터는 애플리케이션이 과거에 사용된 시기와 빈도 및 애플리케이션이 설치된 시기를 포함할 수 있다. 일부 구현예에서, 재참여에 대한 타겟팅 파라미터는 광고가 사용자 디바이스를 안내하는 애플리케이션 페이지의 인기도를 포함할 수 있다.

일부 구현예에서, 타겟팅 파라미터는 애플리케이션에서 사용자가 소비한 시간의 양을 포함할 수 있다. 예를 들어, 타겟팅 파라미터는 사용자가 하나 이상의 애플리케이션에서 임계 시간보다 많은 시간을 보낸 경우 광고가 선택되어야 함을 나타낼 수 있다. 일부 구현예에서, 타겟팅 파라미터는 하루 중 특정 시간, 요일 또는 사용자가 애플리케이션 내에서 작업을 수행했거나 일반적으로 수행하는 다른 시간들을 포함할 수 있다. 일부 구현예에서, 타겟팅 파라미터는 특정 애플리케이션에 의해서 로컬 서비스 모듈(102)에 제공되는 애플리케이션 특정 데이터에 기초할 수 있다. 예를 들어, 애플리케이션은 애플리케이션 내에서 특정 사용자의 사용 패턴에 대한 데이터 또는 애플리케이션에서 사용자가 "애완동물을 좋아하는지"와 같은 특정 사용자 콘텐츠 참여 정보를 제공할 수 있다.

광고 모듈(810)은 하나 이상의 광고를 선택한다(예를 들어, 애플리케이션 페이지, 웹페이지 또는 검색 결과에 삽입하기 위해). 광고 모듈(810)은 타겟팅 파라미터 및/또는 본 명세서에 기술된 다른 광고 스코어링/선택 파라미터에 기초하여 광고(예를 들어, 광고 레코드)를 선택하는 하나 이상의 구성가능한 광고 선택 기능을 구현할 수 있다. 예를 들어, 광고 모듈(810)은 타겟팅 파라미터를 만족하는 하나 이상의 광고를 선택할 수 있다. 일부 구현예에서, 광고 모듈(810)은 타겟팅 파라미터에 기초하여 광고들의 초기 세트를 식별할 수 있다. 그런 다음 광고 모듈(810)은 가령, 광고 입찰 가격 및/또는 광고와의 예상되는 상호작용(예: 사용자 선택, 앱 설치 등) 등과 같은 추가 요인에 기초하여 하나 이상의 최종 광고(예컨대, 검색 결과에 대한)를 선택할 수 있다. 일부 구현예에서, 광고 모듈(810)은 초기에 식별된 광고 세트에 점수를 매길 수 있으며 그리고 가장 높은 점수(들)(예를 들어, 광고 관련성 점수)를 갖는 광고(들)를 선택할 수 있다.

광고 모듈(810)은 광고 후보 선택 모듈("후보 선택 모듈"), 광고 스코어링 모듈 및 광고 선택 모듈을 포함할 수 있다. 후보 선택 모듈은 타겟팅 파라미터들의 충족에 기초하여 후보 광고들의 초기 세트를 선택할 수 있다. 광고 스코어링 모듈은 후보 광고들을 스코어링할 수 있다. 광고 선택 모듈은 후보 광고와 관련된 점수에 기초하여 하나 이상의 후보 광고를 선택할 수 있다(예를 들어, 검색 결과에 포함시키기 위해). 예를 들어, 광고 선택 모듈은 가장 높은 점수를 받은 광고를 선택할 수 있다(예를 들어, 검색 결과에 포함하기 위해). 광고들이 검색 결과에 삽입되는 경우, 이러한 광고들은 "광고 결과들"이라 지칭될 수 있다.

광고 스코어링 모듈은 후보 광고들을 스코어링하는 광고 스코어링 기능 및/또는 광고 스코어링 모델(예를 들어, 기계 학습 모델)을 구현할 수 있다. 후보 광고와 관련된 점수는 검색 결과에 대한 광고의 관련성, 검색 질의 및/또는 기타 데이터(예: 설치/사용 데이터)를 나타낼 수 있다. 광고 스코어링 모듈은 본 명세서에 기술된 임의의 광고 타겟팅 파라미터 및/또는 애플리케이션 참여 파라미터(예를 들어, 집합적/개인적 사용)에 기초하여 광고를 스코어링할 수 있다. 일부 구현예에서, 광고 스코어링 모듈은 배터리 레벨 및/또는 네트워크 상태와 같은 디바이스 인자들에 기초하여 광고를 스코어링할 수 있다.

일부 구현예에서, 광고 스코어링 모듈은 입찰 가격 및/또는 광고와의 예상되는 상호작용(예를 들어, 광고 선택 및/또는 앱 설치)에 기초하여 스코어를 생성할 수 있다. 일부 구현예에서, 광고 스코어링 모듈은 광고의 예상 가치에 기초하여 스코어를 생성할 수 있다. 예상 가치는 사용자로 하여금 광고를 선택하고, 광고를 기반으로 애플리케이션을 설치하고, 광고를 기반으로 구매하도록 유도하는 것과 같이 광고가 예상된 방식으로 수행될 확률에 입찰 가격을 곱하여 계산될 수 있다.

예시적인 추가 광고 스코어링 피처들은 사용자에 의한 광고와의 이전 참여 데이터(예를 들어, 보여진 횟수, 선택된 횟수 등)를 포함할 수 있다. 추가적으로 또는 대안적으로, 일부 시스템은 집계된 사용자 행동 데이터를 수집하고 그리고 이를 다른 사용자에 대한 광고의 평균 CTR과 같은 광고 메타데이터와 연관시킬 수 있다. 광고 스코어링 피처는 광고된 애플리케이션의 인기도를 포함할 수 있다(예: 월마트는 훨씬 작은 쇼핑 애플리케이션보다 더 인기가 있을 수 있음). 광고 스코어링 피처는 또한 의도된 애플리케이션과의 개인적인 사용자 참여 데이터, 고려되는 광고(예: 광고가 재참여 광고인 경우) 및/또는 애플리케이션 카테고리(예를 들어, 사용자는 일주일에 10번 쇼핑 앱을 사용할 수 있음)를 포함할 수 있다. 광고 스코어링 피처는 또한 사용자가 과거에 "스니커즈 운동화(sneakers)"를 검색했는지 여부 및 애플리케이션이 스니커즈 운동화 판매에 특화되었는지와 같은 사용자 검색 행동을 포함할 수 있다. 일부 구현예에서, 광고 스코어링 피처는 하루 중 시간 및 해당 시간에 대한 카테고리의 관련 성능을 고려할 수 있다. 예를 들어, 쇼핑 앱은 늦은 저녁에 더 인기가 있는 반면, 날씨 앱은 아침에 더 인기가 있을 수 있다. 다른 광고 스코어링 피처는 데이터가 마지막으로 업데이트된 시기와 같은 광고 데이터의 나이가 포함될 수 있다. 예를 들어, 오래된 데이터는 더 낮은 점수와 연관될 수 있으며, 이는 최신 광고를 선호할 수 있다. 일부 예에서, 광고 스코어링 피처는 또한, 광고주 예산(예: 지출 금액 및/또는 남은 예산)을 포함할 수 있다.

광고 모듈(810)이 선택을 위해 광고를 스코어링할 수 있지만, 일부 구현예에서 광고 모듈(810)은 광고를 스코어링하지 않을 수 있다. 대신에, 광고 모듈(810)은 가장 인기 있는 광고, 가장 성과가 좋은 광고, 가장 인기 있는 애플리케이션과 관련된 광고, 가장 인기 있는 검색 결과와 관련된 광고 등을 선택하는 것과 같은 다른 광고 선택 규칙을 구현할 수 있다. 집계 광과 성능 및 기타 인기도 메트릭은 광고 시스템(112)으로부터 획득/업데이트될 수 있다.

일부 구현예에서, 광고 모듈(810)은 애플리케이션의 설치 상태에 기초하여 광고를 필터링할 수 있다. 예를 들어, 광고 모듈(810)은 설치되어 있는 애플리케이션에 대한 설치 광고를 제거할 수 있다. 광고 모듈(810)은 또한 설치되지 않은 애플리케이션에 대한 재참여 광고를 제거할 수 있다.

본 명세서에 기술된 바와 같이, 광고 모듈(810)은 사용자 데이터에 액세스할 수 있으며, 선택을 위해 광고를 식별/평가하기 위해 광고 모듈은 상기 사용자 데이터를 사용할 수 있다. 일부 경우, 여기에 설명된 사용자 데이터가 광고 레코드에 통합될 수도 있다. 사용자 데이터는 사용자가 이전 광고와 어떻게 상호작용했는지를 나타내는 데이터를 포함할 수 있다. 예를 들어, 사용자 데이터는 각 광고에 대한 조회수, 광고가 선택되었는지 여부, 조회/선택과 관련된 기타 데이터(가령, 결과를 산출한 검색과 관련된 데이터 및 광고를 선택하는데 사용된 광고 파라미터들)를 나타낼 수 있다. 사용자 데이터는 애플리케이션 설치/사용, 검색 및/또는 광고 시청/선택에 대한 타임 스탬프와 같이 여기에 설명된 임의의 이벤트에 대한 타임 스탬프를 포함할 수 있다.

로컬 서비스 모듈(102)은 시간이 지남에 따라 자신의 광고 기능(예: 광고 식별, 선택 및 스코어링 기능) 및 데이터(예: 광고 데이터 및 사용자 데이터)를 업데이트할 수 있다. 로컬 서비스 모듈(102)은 로컬 서비스 모듈(102)에 대한 광고 기능 및 데이터를 업데이트하는 업데이트 모듈(108)을 포함할 수 있다. 업데이트 모듈(108)은 광고 시스템(112)으로부터 업데이트된 광고 기능 및 광고 데이터를 획득할 수 있다. 예시적인 업데이트된 광고 데이터는 새로운 광고 및 새로운 타겟팅 파라미터 등과 같이 여기에 설명된(예: 광고 레코드에서) 임의의 새로운/수정된 광고 데이터를 포함할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102)은 애플리케이션 사용, 검색 사용 및/또는 광고 보기/선택 데이터를 광고 시스템(112)에 보고할 수 있으며, 따라서 광고 시스템(112)은 각각의 집합 데이터를 업데이트할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 차등 프라이버시, 연합 학습, 및/또는 로컬-집계 등과 같은 프라이버시 강화 기술의 형태를 사용하여 애플리케이션 사용, 검색 사용 및/또는 광고 보기/선택 데이터를 광고 시스템(112)에 보고할 수 있다. 일부 구현예에서, 업데이트 모듈(108)은 주기적으로 및/또는 이전 업데이트 이후 임계 시간이 경과한 후와 같은 다양한 시간들에 광고 시스템(112)에 업데이트 요청을 할 수 있다. 일부 구현예에서, 업데이트 모듈(108)은 이전에 연결해제된/느린 인터넷 연결의 재개에 응답하여 업데이트를 획득하도록 구성될 수 있다.

업데이트 모듈(108)은 설치된 애플리케이션에 대한 업데이트 요청 및 설치된 애플리케이션과 관련된 광고와 같은 개인화된 업데이트 요청을 생성할 수 있다. 일부 구현예에서, 업데이트는 새로 설치된 앱에 대한 광고 레코드 및/또는 마지막 업데이트 이후에 광고 시스템(112)에서 업데이트된 데이터와 같은, 마지막 업데이트 이후 변경 사항으로 제한되는 "델타(delta)"일 수 있다. 일부 구현예에서 업데이트는 특정 지리적 위치 또는 기타 데이터에 맞게 조정될 수 있다. 일부 구현예에서, 광고 시스템(112)은 사용자 디바이스에 어떤 애플리케이션이 설치되는지를 결정 및/또는 예측할 수 있다. 예를 들어, 사용자 디바이스는 설치된 애플리케이션의 목록 및/또는 광고 시스템(112)이 어떤 애플리케이션이 설치되었는지 예측할 수 있게 하는 데이터(예를 들어, 질의 히스토리)를 전송할 수 있다. 경우에 따라, 광고 데이터가 사용자에 대해 개인화되지 않을 수 있다. 일부 구현예에서, 로컬 데이터는 만료 날짜/시간(예를 들어, 광고 만료 날짜)을 가질 수 있다.

일부 구현예에서, 광고 시스템(112)은 업데이트를 사용자 디바이스에 푸시할 수 있다. 업데이트는 배터리 레벨 및/또는 네트워크 상태의 영향을 받을 수도 있다. 예를 들어, 업데이트를 요청하기로 한 결정은 임계 배터리 레벨 및/또는 연결 레벨과 같은 업데이트 기준을 가질 수 있다.

로컬 서비스 모듈(102)은 인터넷 연결 상태에 기초하여 행동을 수정할 수 있다. 예를 들어, 일부 광고 레코드는 인터넷 연결 상태에 기초하여 광고가 표시되어야 함을 나타내는 메타데이터를 포함할 수 있다. 예를 들어 특정 재참여 결과(예: 광고)는 인터넷 연결이 보여져야함을 요구할 수 있다. 또 다른 예로, 일부 애플리케이션 광고는 현재 인터넷 연결이 없을 때 지연된 설치를 제공할 수 있다(예: 연결되면 나중에 설치됨).

광고 시스템(112)이 사용자 디바이스 상의 로컬 광고에 사용하기 위한 데이터를 제공할 수 있지만, 일부 구현예에서, 광고 시스템(112)(예를 들어, 서버 광고 모듈(812) 및 데이터(814))은 로컬 서비스 모듈(102)에 광고를 제공할 수 있다. 예를 들어, 로컬 서비스 모듈(102)은 광고 시스템(112)으로부터 광고를 검색할 수 있다. 광고 시스템(112)은 로컬 서비스 모듈(102)과 유사한 동작(예를 들어, 식별/스코어링/선택 동작)을 사용하여 광고를 생성할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 충분히 관련된 광고가 로컬에서 이용가능하지 않을 때 대비책(fallback)으로서 원격 광고 시스템(112)으로부터 광고를 검색할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 원격 광고 시스템(112)이 불량한/이용불가능한 인터넷 접속으로 인해 이용가능하지 않은 경우, 로컬 광고를 제공할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 원격 광고 시스템(112)으로부터 결과를 수신하고 점수를 비교하여 어떤 광고를 보여줄지 결정할 수 있다.

도 11은 도 8A의 로컬 서비스 모듈(102-6)의 동작을 설명하는 예시적인 방법을 도시한다. 블록(1100)에서, 로컬 서비스 모듈(102-6)(예를 들어, 업데이트 모듈(108-6))은 광고 시스템(112)으로부터 광고 데이터/기능을 획득한다. 블록(1102)에서, 로컬 서비스 모듈(102-6)은 요청 애플리케이션으로부터 광고 요청을 수신한다. 블록(1104)에서, 광고 모듈(810)은 타겟팅 파라미터에 기초하여 후보 광고들의 초기 세트를 선택한다. 블록(1106)에서, 광고 모듈(810)은 후보 광고들로부터 하나 이상의 최종 광고를 선택한다(예를 들어, 광고와 관련된 점수에 기초하여). 블록(1108)에서, 로컬 서비스 모듈(102-6)은 선택된 광고(들)를 포함하는 응답을 요청 애플리케이션에 전송한다. 블록(1110)에서, 업데이트 모듈(108-6)은 광고 데이터를 업데이트할지 여부를 결정한다. 업데이트 모듈(108-6)이 업데이트를 요청/수신하면, 업데이트 모듈(108-6)은 블록(1100)에서 수신된 업데이트에 기초하여 광고 모듈(810) 및/또는 광고 데이터와 같은 로컬 서비스 모듈(102-6)을 업데이트한다. 업데이트 모듈(108-6)이 업데이트를 요청/수신하지 않는 경우, 방법은 블록(1102)에서 계속된다.

도 12는 도 8b의 런처(804)의 동작을 설명하는 예시적인 방법을 도시한다. 도 8b에서, 런처(804)는 로컬 검색 및 광고 기능을 제공하는 로컬 서비스 모듈(102-7)을 포함한다. 런처(804)는 검색 결과 및 광고를 제공하는 검색 인터페이스를 생성할 수 있다(예를 들어, 도 8a의 GUI 참조).

블록(1200)에서, 광고주는 광고주 디바이스(122)를 사용하여 광고 시스템(112)에서 광고 데이터를 생성할 수 있다. 블록(1202)에서, 로컬 서비스 모듈(102-7)은 광고 데이터 및 검색 데이터를 획득할 수 있다. 블록(1204)에서, 로컬 서비스 모듈(102-7)은 사용자 검색 질의(예를 들어, 런처 검색 GUI에 입력됨)를 수신한다. 블록(1206)에서, 검색 모듈(410)은 사용자 검색 질의에 기초하여 검색 결과(예를 들어, 로컬 결과)를 생성할 수 있다.

블록(1208)에서, 광고 모듈(810)은 본 명세서에 기술된 임의의 광고 타겟팅 파라미터에 기초하여 하나 이상의 광고를 선택할 수 있다. 예를 들어, 광고 모듈(810)은 검색 결과 데이터, 사용자 데이터(예를 들어, 이전 광고 참여 데이터, 컨텍스트 등) 또는 기타 파라미터에 기초하여 하나 이상의 광고를 선택할 수 있다. 광고 모듈(810)이 각각의 검색 결과 페이지에 대해 하나 이상의 광고를 선택할 수 있지만, 일부 경우, 광고 모듈(810)은 검색 결과 페이지에 대해 표시되어야 하는 임의의 광고를 식별하지 못할 수도 있다(예를 들어, 타겟팅 파라미터를 충족하는 광고가 없는 경우).

블록(1210)에서, 런처(804)는 검색 결과 및 광고(들)를 검색 GUI에서 렌더링한다. 일부 구현예에서, 런처(804)는 검색 결과 및 광고(들)를 동시에 렌더링할 수 있다. 다른 구현예에서, 런처(804)는 광고를 식별하기 전에(예를 들어, 광고가 선택되는 동안) 검색 결과를 렌더링할 수 있다. 사용자 디바이스 상에서의 광고의 로컬 선택은 사용자가 광고 및 검색 결과의 동시 렌더링과 광고(들)의 후속 렌더링을 구별하지 못할 정도로 충분히 빠르게 발생할 수 있다. 블록(1212)에서, 런처(804)는 검색 결과 또는 광고에 대한 사용자 선택을 검출한다. 블록(1214)에서, 사용자 디바이스는 검색 결과 또는 광고의 선택에 응답하여, 애플리케이션 상태에 액세스하거나 디지털 배포 플랫폼에 액세스할 수 있다.

일부 구현예에서, 로컬 서비스 모듈은 로컬 기능(예를 들어, 검색/광고)에 사용될 로컬 데이터(예를 들어, 로컬 검색/광고 레코드 데이터)를 생성할 수 있다. 한 예에서, 로컬 서비스 모듈은 결정된 사용자 행동을 활용하여 추가 로컬 데이터를 생성할 수 있다. 예를 들어, 로컬 서비스 모듈은 검색과의 상호 작용(예: 검색 질의, 결과 선택 등), 광고 참여(예: 광고 선택, 노출 등) 또는 사용자 디바이스 상에서의 다른 사용자 행동, 등과 같은 사용자 행동에 기초하여 검색/광고 데이터를 생성할 수 있다. 로컬적으로 생성된 데이터는 검색/광고 선택/스코어링과 같이 여기에 설명된 기능을 제공/강화하는데 사용될 수 있다. 로컬 데이터는 검색 기능, 광고 또는 기타 로컬 서비스 모듈 기능에 대한 사용자 참여와 같은 긍정적인 사용자 행동을 기반으로 생성될 수 있다. 로컬 데이터는 또한, 참여를 자제하는 것(예: 광고 선택 안함) 또는 다른 방식으로 사용자 인터페이스와 상호작용하는 것(예: 스크롤링, 스와이프 등) 등과 같은 다른 사용자 행동에 기초하여 생성될 수 있다.

검색 기능(예: 검색 레코드 식별, 스코어링 및 필터링 기능), 광고 기능(예: 광고 식별, 선택 및 스코어링 기능), 검색 데이터(예: 앱 목록/메타데이터 및 검색 레코드), 및 본 명세서에 기술된 광고 데이터(예를 들어, 광고 레코드)는 로컬 서비스 모듈(102)에 포함될 수 있는 예시적인 기능 및 데이터일 뿐이다. 이와 같이, 여기에 명시적으로 설명된 기능 및 데이터 이외에도, 추가적인/대체적인 기능/데이터 및 기능/데이터의 상이한 배열이 로컬 서비스 모듈(102)에 의해 구현될 수 있다.

도 13은 로컬 서비스 모듈(102-8)을 포함하는 예시적인 런처 애플리케이션(1300)을 도시한다. 로컬 서비스 모듈(102-8)은 사용자에게 다양한 기능을 제공할 수 있다. 기능의 일례는 1) 로컬/원격 검색 기능, 2) 로컬/원격 광고 기능, 3) 추가 기능(예: 제로 상태 기능, 바로가기, 자동제안 등), 4) 로컬 데이터 획득 및 프로세싱, 및 5) 업데이트 기능을 포함할 수 있지만 이에 국한되지 않는다.

도 13의 추가 모듈은 추가 기능을 제공할 수 있다. 추가 기능은 1) 애플리케이션 이름 의도 검색, 2) 애플리케이션 바로가기, 3) 제로 상태 기능, 4) 제안된 애플리케이션 기능, 및 5) 자동제안 기능을 포함할 수 있지만 이에 국한되지 않는다. 로컬 검색 및 광고 기능과 유사한 방식으로, 추가 기능은 다음과 같은 로컬 기능을 포함할 수 있다: 1) 사용자 디바이스의 개인 데이터에 액세스하기, 2) 네트워크 연결 없이 빠른 로컬 응답을 제공하기, 3) 기능들이 특별한 권한(예: 우선 실행)을 갖도록 사용자 디바이스에 통합되기.

일부 구현예에서, 로컬 서비스 모듈(102-8)은 부분/전체 질의에 기초하여 사용자가 특정 애플리케이션 또는 애플리케이션(들)을 찾고 있다고 결정하는 애플리케이션 이름 의도 검색 기능을 포함할 수 있다. 일부 경우에, 로컬 서비스 모듈(102-8)(예를 들어, 바로가기 모듈(1302))은 바로가기 링크를 애플리케이션에 제공하는 바로가기 링크 기능을 포함할 수 있다. 바로가기 링크 기능은 부분/전체 질의를 기반으로 사용자가 관심을 가질 수 있는 애플리케이션에 대한 딥 링크 목록을 식별할 수 있다. 바로가기(shortcut) 링크는 다양한 방법으로 생성될 수 있다. 일부 구현예에서, 바로가기는 개발자에 의해 제공될 수 있다. 예를 들어, 개발자는 애플리케이션을 다운로드하기 전에 애플리케이션에 대한 바로가기 링크를 제공할 수 있다(예: 애플리케이션 패키지 Android.apk 파일에서). 또 다른 예로서, 개발자는 업데이트에서 바로가기 링크를 제공할 수 있다. 일부 구현예에서, 바로가기 링크는 자동으로 생성될 수 있다. 예를 들어, 바로가기 링크는 인기도에 따라 자동으로 선택된 링크일 수 있다. 다른 예에서, 개인 사용예(예를 들어, 일반적으로 사용되는 애플리케이션 상태)에 기초하여 바로가기 링크가 생성될 수 있다. 바로가기 링크가 자동으로 생성되는 일례에서, 바로가기 링크는 애플리케이션이 사용됨에 따라 동적으로 생성될 수 있다. 예를 들어, 사용자가 액세스한 애플리케이션 링크들에 기초하여 신/구 바로가기 링크들이 추가/제거될 수 있다. 일부 구현예에서, 바로가기는 OS(116)로 딥링크를 레코딩하는 구동 앱에 의해서 제공되거나 또는 로컬 서비스 모듈(102-8)로 직접 제공될 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102-8)(예를 들어, 제로 상태 모듈(1304))은 제로 상태 기능을 제공할 수 있다. 제로 상태 기능은 제로 상태 트리거(예를 들어, 사용자 검색 질의 이외의)에 응답하여 사용자에게 제공되는 기능을 의미할 수 있다. 제로 상태 트리거의 예는 애플리케이션에서의 사용자 제스처(예를 들어, 사용자 스와이프), 애플리케이션의 특정 페이지(예를 들어, 특정 런처 페이지)에 사용자가 액세스하는 것, 하루 중 미리 결정된 시간, 사용자의 미리 결정된 지리적 위치 및/또는 사용자가 전화기를 "깨우는 것"(예컨대, 전화기가 정지 상태로 놓여있다가 움직이는 것), 등을 포함할 수 있지만 이에 제한되지 않는다. 사용자의 미리 결정된 지리적 위치 및/또는 전화를 "깨우는" 사용자(예: 전화가 정지된 후의 움직임). 일부 구현예에서, 검색 질의 상자를 포함하는 페이지에 액세스하는 것은, 사용자가 검색 질의를 입력하기 전에 제로 상태 기능을 트리거할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102-8)은 제로 상태 링크 및/또는 제로 상태 검색 질의(즉, 질의 힌트)를 제공할 수 있다. 제로 상태 링크는 사용자 선택에 응답하여, 애플리케이션 상태/페이지에 액세스하는 사용자 선택 가능 링크를 지칭할 수 있다. 제로 상태 검색 질의는 사용자 선택에 응답하여, 입력된 검색 질의의 역할을 하는 사용자 선택가능 검색 질의를 지칭할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102-8)은 검색 질의 없이 여기에 설명된 검색 기능을 사용하여 제로 상태 링크를 제공할 수 있다. 예를 들어, 로컬 서비스 모듈(102-8)은 사용자 컨텍스트(예를 들어, 위치, 시간 등) 및 이전 검색 활동 및/또는 애플리케이션 사용을 포함하는 다른 사용자 데이터에 기초하여 검색을 수행할 수 있다. 제로 상태 검색 질의는 질의 힌트들의 엄선된 목록(curated list), 과거의 애플리케이션 사용예(예컨대, 이전 검색 질의, 링크 선택 등) 또는 기타 요인에 기초하여, 사용자에게 제공될 수 있다. 일부 구현예에서, 검색 박스를 보여주는 것에 응답하여 제로 상태 검색 질의 목록이 디스플레이될 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102-8)(예를 들어, 제안된 앱 모듈 1306)은 제안된 애플리케이션 기능을 제공할 수 있다(예를 들어, 제로 상태 트리거에 응답하여). 제안된 애플리케이션 기능은 다양한 요인에 따라 오픈할 수 있는 애플리케이션들에 대한 제안 링크들의 목록을 사용자에게 제공하는 것을 포함할 수 있다. 제안된 애플리케이션을 디스플레이하기 위한 예시적인 요인들은, 애플리케이션 인기도, 기타 집계 애플리케이션 데이터, 개인 애플리케이션 사용예(예컨대, 더 많이 사용된 애플리케이션을 보여줌), 하루 중 시간(예: 해당 시간에 일반적으로 사용되는 애플리케이션을 보여줌), 최근 질의, 네트워크 상태(예: 사용자가 무제한 Wi-Fi에 연결된 경우 스트리밍 애플리케이션을 보여줌) 및 지리적 위치(예: 해당 위치에서 일반적으로 사용되는 애플리케이션을 보여줌)를 포함할 수 있지만 이에 국한되지 않는다. 일부 구현예에서 제안된 애플리케이션은 설치된 애플리케이션으로 제한될 수 있다. 다른 구현예에서, 제안된 애플리케이션은 사용자 디바이스에 현재 설치되지 않은 애플리케이션을 포함할 수 있다. 일부 구현예에서는, 제안된 앱과 함께 광고가 표시될 수 있다. 일부 구현예에서는, 잠재적인 수익(예: 설치 또는 재참여에 대한 비용을 지불하는 애플리케이션 개발자)이 순위에 영향을 미칠 수 있다. 제안된 애플리케이션 링크를 생성하는데 사용되는 데이터는 로컬적으로 저장되고 원격 서비스 시스템(106-4)에 의해 업데이트될 수 있다. 일부 구현예에서, 제안된 애플리케이션 링크를 생성하는데 사용되는 데이터는 로컬적으로 생성될 수 있다(예를 들어, 사용자 디바이스에서 유래됨).

일부 구현예에서, 로컬 서비스 모듈(102-8)(예를 들어, 자동제안 모듈 1308)은 자동제안 기능을 포함할 수 있다. 자동제안 기능은 부분적인/완성된 질의의 사용자 입력에 응답하여, 사용자 선택가능한 자동제안 질의들의 목록(예컨대, 검색 박스 아래)을 제공할 수 있다. 로컬 서비스 모듈(102-8)(예를 들어, 검색 모듈 410)은 선택된 자동제안 검색 질의를 사용하여 검색을 수행할 수 있다. 로컬 서비스 모듈(102-8)은 후보 자동제안 질의를 로컬적으로 생성하고(예를 들어, 로컬 데이터에 기초하여) 및/또는 원격 검색 시스템(110)으로부터 후보 자동제안 질의를 획득할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102-8)(예를 들어, 자동제안 모듈 1308)은 로컬 데이터(예를 들어, 이전 질의와 현재 입력된 질의 사이의 상관 관계)에 기초하여 후보 자동제안 질의들의 순위를 매길 수 있다.

로컬 서비스 모듈(102)은 로컬 데이터 획득 및 프로세싱 모듈(424-1, 424-2,… 424-6)(일반적으로, 로컬 데이터 모듈 424로 지칭됨)을 포함할 수 있으며, 이는 사용자 디바이스 상에서 로컬적으로 데이터를 획득하고 프로세싱할 수 있다. 획득된 데이터는 사용자 디바이스 상에서의 다양한 이벤트를 포함할 수 있는바, 가령, 로컬 서비스 모듈(102), 런처, 및/또는 사용자 디바이스 상의 하나 이상의 다른 애플리케이션과의 사용자 상호작용 등을 포함할 수 있다. 예시적인 이벤트는 UI 이벤트(예: 사용자 제스처 입력 및 기타 GUI 상호작용), 검색 이벤트(예: 검색 질의 입력, 결과, 결과 선택), 광고 이벤트(예: 광고 보여주기/선택), 애플리케이션 이벤트(예: 설치, 열기, 제거), 웹 이벤트(예: 웹 페이지 상호 작용), 추가 기능 이벤트(예: 제로 상태 상호 작용, 앱 이름 의도, 바로가기 선택, 추천 앱, 자동제안 이벤트 등) 및 기타 디바이스에서 발생하는 이벤트를 포함할 수 있다. 로컬 데이터(104)는 검색의 개인화, 광고 선택 및 추가 기능에 사용하기 위해 일부 데이터를 저장할 수 있다. 로컬 서비스 모듈(102)(예를 들어, 로컬 데이터 모듈 424)은 또한 원격 서비스 시스템(106)(예를 들어, 검색 시스템(110), 광고 시스템(112), 분석 시스템(1310) 등)에 이벤트 데이터를 제공할 수 있으며, 이는 원격 서비스 시스템(106)에서 다양한 데이터를 업데이트하는 것과 같은 분석 서비스를 제공할 수 있다.

획득된 이벤트는 이벤트를 설명하는 이벤트 데이터를 포함할 수 있다. 예를 들어, 이벤트 데이터는 이벤트와 관련된 어플리케이션(예: 어플리케이션 이름), 이벤트의 유형(예: 검색 이벤트, 광고 이벤트 등), 뿐만 아니라 이벤트가 발생한 시간 등을 나타낼 수 있다. 이벤트 데이터의 예시적인 일례는 질의 히스토리 데이터(예를 들어, 이전에 입력된 질의), 검색 결과 선택 데이터 및 광고 상호작용 데이터(예를 들어, 광고 보기/선택)를 포함할 수 있다. 추가의 예시적인 이벤트 데이터는 스크롤링 이벤트 또는 체류 시간(dwell time)과 같은 UI(예: 런처 UI)와의 사용자 상호작용을 포함할 수 있다.

일부 구현예에서, 일부 애플리케이션은 로컬 서비스 모듈(102)에 이벤트 데이터를 제공하는 모듈(예: SDK)을 포함할 수 있다. 예를 들어 , 애플리케이션 또는 OS는 애플리케이션 내의 다양한 동작을 나타내는 이벤트 데이터를 제공할 수 있다(예를 들어, 애플리케이션 열기, 애플리케이션 닫기, 상거래 이벤트 및/또는 커스텀 개발자 정의 이벤트). 이벤트 데이터를 로컬 서비스 모듈(102)에 보고하는 모듈을 애플리케이션이 포함하는 구현예에서, 로컬 서비스 모듈(102) 및 애플리케이션에 포함된 모듈은 동일한 당사자(예를 들어, 동일한 비즈니스)에 의해 개발될 수 있다.

로컬 데이터 모듈(102)이 데이터를 획득하는 정도는 구성가능하고 업데이트 가능할 수 있다. 예를 들어, 로컬 서비스 모듈의 상이한 구현예들은 상이한 정도로 이벤트를 획득 및 프로세싱할 수 있다. 또한, 이벤트 유형 및 획득된 데이터 양도 구성가능할 수 있다. 일례로, 서로 다른 OEM들은, 서로 다른 이벤트 유형들에 대한 이벤트 데이터를 획득하고 및/또는 서로 다른 양의 데이터를 획득할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102)은 이벤트 데이터를 원격 서비스 시스템(106) 및/또는 분석 시스템(1310)에 보고할 수 있다(예를 들어, 도 13 참조). 원격 서비스 시스템(들)(106)은 하나 이상의 사용자로부터 획득한 데이터에 기초하여 원격 기능(예를 들어, 검색 결과 및/또는 광고)을 제공할 수 있다. 일부 구현예에서, 원격 서비스 시스템(106)은 사용자/집계 획득 데이터에 기초하여 로컬 서비스 모듈(102)에 업데이트 데이터를 제공할 수 있다. 로컬 데이터가 원격 서비스 시스템(106)에 제공되는 정도는 구성가능할 수 있다. 예를 들어, 로컬 서비스 모듈의 상이한 구현예들은 상이한 유형의 이벤트들 및 상이한 분량의 데이터를 원격 서비스 시스템(106)에 제공할 수 있다. 일부 구현예에서, 분석 시스템(1310)은 다른 원격 서비스 시스템과 분리될 수 있다(예를 들어, 검색/광고 시스템과 분리됨). 분석 시스템(1310)은 원격 서비스 시스템(106)과 별개일 수 있지만, 일부 구현예에서 분석 기능은 원격 서비스 시스템(106)에 통합될 수 있다.

일부 구현예에서, 사용자 프라이버시를 보호하기 위해 프라이버시 강화 기술이 구현될 수 있다. 예를 들어 차등 프라이버시, 보안 집계 및/또는 해싱을 사용하여, 사용자 디바이스에 데이터가 관련될 가능성을 감소시키는 형태로 원시 분석 데이터를 변환할 수 있다.

일부 구현예에서, 분석 시스템(1310)은 원격 서비스 시스템(106)에 데이터를 전달하기 전에 저장-및-포워드(store-and-forward)) 캐싱 기술을 활용하여, 다수의 이벤트 메시지들을 축적할 수 있다. 일부 구현예에서, 분석 시스템(1310)은 이미 소비된 대역폭의 카운트들을 활용하여, 원격 서비스 시스템(106)과 언제 통신할지를 결정할 수 있다. 일부 구현예에서, 분석 시스템(1310)은 원격 서비스 시스템(106)으로 전달되는 데이터를 수정할 수 있다. 예를 들어, 사용자가 전날에 1000번 클릭했다면, 분석 시스템(1310)은 마지막 10개만 전송하도록 선택할 수 있다. 다른 예에서, 사용자가 로밍 중인 경우, 분석 시스템(1310)은 사용자에게 가장 인기 있는 애플리케이션에 대한 클릭과 같은 집계 데이터만 전송할 수 있다.

일부 구현예에서, 분석 시스템(1310)은 통신되는 데이터를 감소시키기 위해 압축 알고리즘을 활용할 수 있다. 일부 구현예에서, 분석 시스템(1310)은 권한이 없는 개인이 사용자 로그를 보는 것을 방지하기 위해 암호화를 사용할 수 있다.

로컬 서비스 모듈(102)에 포함된 모듈은 로컬 서비스 모듈(102)과 관련된 기능을 나타낼 수 있다. 예를 들어, 검색 모듈(410) 및 광고 모듈(810)은 각각 검색 및 광고 기능을 나타낼 수 있다. 일부 구현예에서, 모듈들은 정의된 소프트웨어 컴포넌트들을 포함한다. 예를 들어, 로컬 서비스 모듈(102)은 로컬 서비스 모듈 또는 로컬 서비스 모듈을 포함하는 다른 애플리케이션의 설치 중에 정의되었던 정의된 소프트웨어 컴포넌트를 포함할 수 있다. 로컬 서비스 모듈 컴포넌트(예를 들어, 모듈)는 예를 들어, 디지털 배포 플랫폼(118)으로부터의 소프트웨어 업데이트에 의해 업데이트될 수 있다. 본 명세서에 기술된 바와 같이, 로컬 서비스 모듈에 포함된 일부 모듈(예를 들어, 검색 및 광고 모듈(410, 810))은 상기 정의된 소프트웨어 컴포넌트 이외에도 구성가능한/수정가능한 기능을 가질 수 있다. 구성가능한 기능은 도 4a 및 도 8a의 구성 데이터로서 예시된다. 구성가능한 기능은 로컬 데이터(104)에 저장될 수 있다. 본 명세서에 설명된 바와 같이, 상이한 로컬 서비스 모듈에 대한 구성 데이터는 업데이트될 수 있다(예를 들어, 업데이트 모듈(108)에 의해 요청된 수신된 업데이트 번들에 의해). 업데이트들은 구성 기능(예: 검색/광고 알고리즘) 및/또는 기타 데이터(예: 검색/광고 레코드)를 업데이트할 수 있다.

일부 구현예에서, 구성 데이터는 데이터 생성 및 조작 커맨드들의 세트와 같은 제한된 동작 세트를 포함할 수 있다. 제한된 동작 세트는 소프트웨어 보안을 위해 시행될 수 있다. 예시적인 동작은 테이블 생성, 테이블 삭제, 테이블 수정, 값들 또는 로우들(rows)의 삽입/삭제/업데이트/수정, 또는 인덱스 구축과 같은, 판독(read)/기입(write) 및 구조적 데이터 변경(예: 스키마 변경)을 포함할 수 있지만 이에 국한되지 않는다. 특정 구현예에서 구조화된 질의 언어(SQL)(예컨대, SQL 커맨드), 기타 언어 및/또는 풀 커스텀 커맨드(full custom command)가 사용될 수 있다. 특정 데이터 조작 커맨드는 검색을 위한 인기 점수 업데이트, 레코드 삭제, 및 검색을 위한 SQL 질의 변경을 포함할 수 있다. 일부 구현예에서, 검색 알고리즘은 SQL 질의일 수 있으며, 여기서 SQL 질의와 해당 바인딩은 데이터 저장소에 지정된다. 예를 들어, 앱 이름 검색 기능은 사용자의 질의로 시작하는 모든 애플리케이션을 선택할 수 있으며(예컨대, "select * from local_app_data where app_name like '< user_query >%'") 그리고 랭킹은 "order by last_time_opened desc"와 같은 일부 로컬 또는 기타 데이터에 기초할 수 있다. 특정 SQL 질의는 기능을 수정하도록 업데이트 번들에 의해 업데이트될 수 있다(예: 랭킹을 위해 다른 컬럼 사용 또는 다른 매칭 필터 사용). 일부 구현예에서, 스코어링 또는 랭킹 함수는 파라미터화될 수 있고 그리고 파라미터 및 그 가중치는 데이터 저장소에서 지정되고 번들에 의해 업데이트될 수 있다. 일부 구현예에서 구성 데이터는 모듈의 정의된 소프트웨어 컴포넌트의 동작을 변경하지 않을 수 있지만, 다른 구현예에서 구성 데이터는 구성가능한 소프트웨어 컴포넌트를 포함할 수 있다.

원격 서비스 시스템(106)은 업데이트 모듈(108)로부터 수신된 요청에 응답하는 것과 같이, 업데이트를 로컬 서비스 모듈(102)로 전송할 수 있다. 업데이트 데이터는 본 명세서에서 "업데이트 번들" 또는 "번들"로 지칭될 수 있는 업데이트 데이터 구조에 포함될 수 있다. 업데이트 번들은 가령, 업데이트된 검색 데이터(예: 검색 레코드, 목록 등), 광고 데이터(예: 질의, 사용자, 광고, CTR 추정, 견적의 가능한 조합을 포함하는 광고 레코드) 및 기타 데이터와 같은 로컬 데이터에 포함될 업데이트된 데이터를 포함할 수 있다. 업데이트 번들은 또한 상이한 모듈들(예를 들어, 검색 모듈(410) 및/또는 광고 모듈(810))에 의해 사용될 수 있는 업데이트된 구성 데이터(예를 들어, 데이터 조작 커맨드)를 포함할 수 있다. 따라서, 로컬 서비스 모듈(102)의 동작 및 로컬 서비스 모듈(102)이 동작하는 데이터는 수신된 업데이트 번들에 기초하여 구성될 수 있다. 업데이트 기능을 제공하는 것은, 설치된 로컬 서비스 모듈에 시간이 지남에 따라 관련 검색 결과들, 광고들 및 기타 새로운 기능이 제공됨을 보장하는데 도움을 줄 수 있다. 일부 구현예에서, 업데이트들은 사용자-특정(user-specific)(예컨대, 개인화)일 수 있으며, 따라서 서로 다른 디바이스는 서로 다른 업데이트를 수신할 수 있다. 다른 구현예에서, 업데이트는 사용자-특정이 아닐 수도 있다(예컨대, 범용 업데이트 번들). 일부 구현예에서, 업데이트는 현재 사용자의 지역이나 국가 또는 언어 설정과 같은 디바이스로부터의 익명 데이터에 따라 달라질 수 있다. 일부 구현예에서, 동일한 그룹의 모든 사용자들이 동일한 업데이트를 수신하도록, 업데이트들은 그룹으로 구성될 수 있다. 예를 들어, 그룹은 지역, OEM, 이동통신사(carrier), 전화 모델 또는 기타 그룹일 수 있다. 일부 구현예에서, 디바이스 및 사용자 컨텍스트의 속성들의 특정 조합은 번들을 결정하는데 사용될 수 있다(예를 들어, 사용자 국가 및 디바이스 유형). 일부 구현예에서, 번들은 그룹들에 기초한 부분적인 번들들의 조합일 수 있다. 예를 들어, 사용자는 지역에 기초하여 번들의 일부를 수신하고 그리고 OEM에 기초하여 번들의 일부를 수신할 수 있다.

로컬 서비스 모듈(102)은 모듈들이 정의된 소프트웨어 컴포넌트 기능을 포함할 수 있는 초기 구성(예: 기본/폴백 동작)으로 설치될 수 있다. 추가적으로, 로컬 서비스 모듈(102)에 포함된 데이터(예를 들어, 검색 데이터, 구성가능한 데이터 등)는 초기 구성 상태에 있을 수 있다. 로컬 서비스 모듈은 초기 시작시에, 원격 서비스 시스템(106)으로부터 업데이트를 요청하도록 구성될 수 있다. 현재 구성으로 업데이트한 후, 로컬 서비스 모듈(102)은 업데이트된 데이터(예를 들어, 업데이트된 검색 데이터, 광고 데이터, 구성 가능한 데이터 등)에 따라 동작할 수 있다. 일부 구현예에서, 모듈은 가령, 정의된 폴백 검색(fallback search) 및 광고 기능과 같은 정의된 폴백 기능을 포함할 수 있다. 로컬 서비스 모듈(102)(예를 들어, 하나 이상의 포함된 모듈)은 업데이트들 또는 다른 피처들이 적절하게 작동하지 않는 경우, 상기 정의된 폴백 기능을 사용할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102) 또는 다른 애플리케이션은 사용자 프라이버시 및 애플리케이션-특정 데이터 분리를 유지하기 위해 서로 다른 컴포넌트들 간의 데이터 사용에 제한을 둘 수 있다. 예를 들어, 일부 구현예에서, 로컬 서비스 모듈(102)은 사용자 데이터를 로깅하고 분석을 유지하기 위한 권한을 부여하도록 사용자에게 프롬프트할 수 있다. 추가적으로, 로컬 서비스 모듈(102)은 검색 및 광고를 위한 데이터 사용에 제한을 둘 수 있다. 예를 들어, 로컬 서비스 모듈(102)은 광고 및/또는 검색을 위해 애플리케이션들 전반에 걸쳐 데이터의 사용을 제한할 수 있다. 특정 예에서, 경우에 따라, 하나의 애플리케이션에 대한 사용자 데이터는 다른 애플리케이션에 대한 광고를 타겟팅하는데 사용되지 않을 수 있다.

일부 구현예에서, 업데이트 모듈(108)(예를 들어, 도 15의 번들 관리자)은 원격 서비스 시스템(106)에 업데이트 번들을 요청할 수 있다. 일부 구현예에서, 업데이트 모듈(108)은 상기 요청 내에 디바이스/사용자 ID를 포함할 수 있고 및/또는 현재 사용중인 번들 ID를 나타낼 수 있다. 일부 구현예에서, 업데이트 모듈(108)은 번들 최종 업데이트 시간과 같은 번들에 대한 추가 메타데이터를 포함할 수 있다. 일부 구현예에서, 업데이트 모듈(108)은 사용자의 현재 지리적 위치, 언어 설정 등과 같은 사용자 또는 디바이스에 대한 추가 메타데이터를 포함할 수 있다. 일부 구현예에서, 업데이트 모듈(108)은 가령, 예측된 사용자 카테고리(예컨대, 사용자는 게임을 좋아한다) 등과 같은 로컬적으로 생성된 데이터를 포함할 수 있다. 원격 서비스 시스템(106)은 요청에 응답하여 업데이트 번들을 사용자 디바이스로 전송할 수 있다. 업데이트 모듈(108)은 업데이트된 번들 데이터를 로컬 서비스 모듈(102)에 통합할 수 있다.

로컬 서비스 모듈(102)은 설치시에 제공되는 다양한 기능을 가질 수 있다. 일부 구현예에서는 업데이트된 번들은 추가 기능을 제공할 수 있다. 일례로서, 업데이트 번들은 새로운 검색/광고 피처, 새로운 제로 상태 서비스/피처, 질의 힌트 서비스/피처 및/또는 자동제안 서비스/피처 등과 같은 새로운 서비스/피처를 추가할 수 있다. 예를 들어, 업데이트 번들은 검색 결과를 생성하는 방법, 결과/광고를 렌더링하는 방법 및 제로 상태 기능을 트리거하는 방법을 나타낼 수 있다.

도 14는 로컬 서비스 모듈(102)에 대한 업데이트를 제공할 수 있는 예시적인 원격 서비스 시스템(106-5)을 도시한다. 설명을 위한 목적으로, 원격 서비스 시스템(106-5)의 선택 컴포넌트가 도 14에 도시된다. 이와 같이, 도 14에 포함되지 않은 추가/대체 모듈들 및 데이터 저장소들이 원격 서비스 시스템(106)에 포함될 수 있다. 원격 서비스 시스템(106-5)은 서버 검색 데이터 저장소(418), 서버 광고 데이터 저장소(814), 서버 업데이트 데이터 저장소(1400) 등과 같은 복수의 서버 데이터 저장소를 포함할 수 있다. 원격 서비스 시스템(106-5)에 포함된 데이터 저장소들은 사용자 디바이스에 대한 업데이트로서 전송되는 본 명세서에 설명된 임의의 데이터를 포함할 수 있다. 예를 들어, 서버 데이터 저장소는 검색 데이터(예: 검색 레코드, 목록 등), 광고 데이터(예: 광고 레코드) 및 기타 데이터(예: 제로 상태 데이터, 질의 힌트 데이터 등)를 포함할 수 있다. 서버 데이터 저장소는 또한 로컬 서비스 모듈(102)에 의해 사용될 수 있는 구성 데이터(예를 들어, 데이터 조작 커맨드)를 포함할 수 있다.

원격 서비스 시스템은 서버 데이터 저장소에 포함되는 데이터를 생성하는 서버 데이터 생성 모듈(1404)("데이터 생성 모듈 1404")과 같은 서버 업데이트 모듈(1402)을 포함할 수 있다. 예를 들어, 데이터 생성 모듈(1404)은 서버 검색 데이터(418), 서버 광고 데이터(814) 및 기타 서버 데이터를 생성할 수 있다. 일부 구현예에서, 데이터 생성 모듈(1404)은 획득한 사용자/분석 데이터에 기초하여 집계 데이터(예를 들어, 다른 서버 데이터)를 생성할 수 있다. 원격 서비스 시스템(106-5)은 광고 및 대규모 애플리케이션 세트에 대한 데이터를 포함할 수 있으며, 이들 중 일부는 각각의 사용자 디바이스에 설치될 수 있다. 원격 서비스 시스템(106-5)은 업데이트를 위한 번들 데이터를 생성하는 업데이트 번들 생성 모듈(1406)("번들 생성 모듈(1406)")을 포함할 수 있다. 번들 데이터는 번들 데이터 저장소(1408)에 저장될 수 있다. 번들 데이터 저장소(1408)는 또한 번들의 콘텐츠 및 번들의 히스토리(예를 들어, 번들 날짜, 업데이트된 데이터 등)을 나타내는 번들 메타데이터를 포함할 수 있다.

일부 구현예에서, 번들 생성 모듈(1406)은 사용자 디바이스에 설치된 애플리케이션 목록 및/또는 사용자 디바이스 상에서의 애플리케이션/광고 참여와 같은 다양한 파라미터에 기초하여 사용자를 위한 개인화된 업데이트 번들을 생성할 수 있다. 번들을 개인화하기 위해, 원격 서비스 시스템(106-5)은 사용자/디바이스 및 관련 서버 데이터를 고유하게 식별하는 번들 요청에서 수신된 사용자/디바이스 ID를 사용할 수 있다. 일부 구현예에서는, 업데이트 번들이 덜 개인화될 수 있다. 예를 들어, 업데이트된 데이터를 포함하는 일반 번들이 시간이 지남에 따라 생성 및 저장될 수 있다. 번들 생성 모듈(1406)은 업데이트 요청에 응답하여 새로운 일반 번들을 보낼 수 있다.

일부 구현예에서, 번들 생성 모듈(1406)은 현재 사용되는 번들과 다른 대부분의/오직 데이터만을 포함하는 번들을 동적으로 생성함으로써 번들의 크기를 최적화할 수 있다. 번들 생성 모듈(1406)은 디바이스 보고된 마지막 업데이트 번들 타임스탬프와 같은 현재 사용된 번들의 콘텐츠를 나타내는 번들 ID 및/또는 다른 번들 메타데이터에 기초하여 사용자 디바이스에서 현재 사용되는 번들의 콘텐츠를 결정할 수 있다. 일부 구현예에서, 번들 생성 모듈(1406)은 번들-id 또는 번들 메타데이터에 정보를 추가함으로써 사용자 디바이스가 실험 그룹에 할당됨을 명시할 수 있다. 일부 구현예에서, 번들 생성 모듈(1406)은 대역폭 제한에 응답하여 번들의 크기를 최적화(예를 들어, 최소화)할 수 있다. 일부 구현예에서, 번들 생성 모듈(1406)은 번들 크기를 최소화하기 위해 데이터를 제거하거나 일부 데이터의 전송을 금지할 수 있다. 일부 구현예에서, 번들 생성 모듈(1406)은 디바이스와 서버 사이의 공유 딕셔너리의 사용을 포함하여 압축을 이용할 수 있다. 일부 구현예에서, 번들 생성 모듈(1406)은 디바이스에 의해 공유되거나 디바이스에 의해서만 알려진 키 또는 비밀을 사용하여 각각의 번들을 암호화할 수 있다.

원격 서비스 시스템(106-5)은 번들을 사용자 디바이스에 제공하는 통신 모듈(1410)을 포함할 수 있다. 예를 들어, 통신 모듈(1410)은 사용자 디바이스로부터 업데이트 번들 요청을 수신하고, 상기 요청에 응답하여 사용자 디바이스에 업데이트 번들을 제공할 수 있다. 부가적으로 또는 대안적으로, 원격 서비스 시스템(106-5)은 사용자 디바이스에 업데이트를 푸시할 수 있다. 일부 구현예에서, 원격 서비스 시스템(106-5)은 특정 사용자 또는 디바이스 ID를 실험 그룹에 할당할 수 있다. 번들 요청은 할당된 실험 그룹과 관련된 정확한 데이터가 전송되는 것을 보장하기 위해 이전에 할당된 실험 그룹을 원격 서비스 시스템(106-5)에 지정할 수 있다.

로컬 데이터 모듈(424)은 사용자 상호작용 데이터를 로그(log)하고, 분석 데이터를 생성하고, 분석 시스템(1310) 및/또는 원격 서비스 시스템(106)에 분석 데이터를 제공할 수 있다. 분석의 일례들은, 검색 분석, 광고 분석, UI 분석(예: 사용자 입력), 디바이스 분석(예: 연결/배터리 상태) 및 기타 서비스 분석을 포함할 수 있지만, 이에 제한되지 않는다. 분석은 로컬 데이터 모듈(424) 뿐만 아니라 다른 모듈들에 의해 획득된 임의의 이벤트(예를 들어, 제로 상태, 질의 힌트 및 자동제안)와 같이 여기에 설명된 임의의 이벤트의 로그를 포함할 수 있다. 일부 구현예에서, 분석은 또한 로그된(logged) 에러 이벤트를 포함할 수 있다. 일부 구현예에서, 로컬 데이터 모듈(424)은 전송을 위해 분석 데이터를 압축하거나 집계할 수 있다. 일부 구현예에서, 로컬 데이터 모듈(424)은 사용자가 WiFi를 활성화했거나, 사용자가 디바이스 언어 또는 디폴트 지역을 변경한 것과 같은 디바이스 이벤트를 수신할 수 있다. 일부 구현예에서, 로컬 데이터 모듈(424)은 차등 프라이버시, 보안 집계 및/또는 해싱과 같은 프라이버시 강화 알고리즘을 활용할 수 있다.

분석 시스템(1310) 및/또는 원격 서비스 시스템(106)은 사용자 디바이스, 검색 시스템(110), 광고 시스템(112) 및/또는 제3자 데이터 제공자(126)로부터 분석을 수신할 수 있다. 또한, 분석 시스템(1310)은 원격 서비스 시스템(106)(예를 들어, 검색 시스템(110) 및/또는 광고 시스템(112)에 분석 데이터를 제공할 수 있다. 원격 서비스 시스템(106)은 분석 데이터 및 다른 사용자 데이터에 기초하여 여기에 기술된 서버 데이터를 업데이트할 수 있다.

도 15는 가령, 런처 애플리케이션에서 구현되는 로컬 서비스 모듈과 같은 로컬 서비스 모듈(102-9)에 대한 예시적인 아키텍처의 기능 블록도이다. 도 15의 예시적인 기능 블록도는 로컬 서비스 모듈(102-9)의 예시적인 컴포넌트를 도시한다. 예를 들어, 예시적인 아키텍처는 다음을 포함할 수 있다: 번들 관리자 모듈(1500)(예를 들어, 로더/프로세서), 로컬 데이터 모듈(424-6), 로컬 질의 실행 엔진(1502)(폴백 포함), 분석 이벤트 프로세서(1504), 로컬 질의 저장소(1506), 로컬(사설) 데이터 저장소(1508), 서버 동기화 데이터(1510) 및 하나 이상의 번들. 일부 구현예에서 번들은 사용자 디바이스에서 실행될 SQL 커맨드들의 모음을 포함할 수 있다. 로컬 서비스 모듈(102-9)은 타이머와 같은 "번들 요청 이벤트"를 포함할 수 있으며, 또는 이는 이벤트 또는 스케줄 기반일 수 있다. 번들 관리자(1500)는 원격 서비스 시스템(1606)에(예를 들어, 인터넷을 통해) 요청을 할 수 있으며, 원격 서비스 시스템(1606)은 하나 이상의 번들로 응답할 수 있다.

일부 구현예에서, 번들 관리자(1500)는 수신된 번들에 기초하여 타이머 또는 스케줄링된 리로드(reloads)를 설정할 수 있다(예를 들어, 수신된 번들은 24시간 내에 다시 로드되도록 요청할 수 있음). 상이한 서비스들(예: 광고, 앱 검색, 제로 상태, 힌트 등)에 대한 여러 번들이 있을 수 있다. 각각의 개별 서비스에는 번들 로드/요청을 위한 그 자신의 독립적인 스케줄을 가질 수 있다. 각각의 로딩된 번들은 트랜잭션으로 실행될 수 있다. 오류가 있는 경우, 서버 동기화 상태는 번들 로드가 시작되기 전으로 재설정되어 손상을 방지할 수 있다. 번들은 서버 동기화 데이터와 로컬 질의 저장소의 콘텐츠를 결정할 수 있다.

로컬 서비스 모듈(102-9)은 로컬 OS 기능에 대한 다양한 이벤트 또는 질의를 기반으로 로컬 프라이빗 데이터를 생성할 수 있다. 이벤트 또는 요청은 로컬 데이터 모듈에 대한 입력으로 원시 데이터를 제공할 수 있으며, 이는 이러한 데이터를 프로세싱하고 로컬 프라이빗 데이터를 생성/업데이트할 수 있다. 질의 입력, 결과 클릭, 스크롤링 동작 및/또는 다른 동작과 같은 로컬 서비스 모듈 또는 다른 애플리케이션과 관련된 사용자 동작은 로컬 데이터 내에 적절한 레코드를 생성하도록 로컬 데이터 모듈(424-6)을 트리거할 수 있다. 예를 들어, 사용자가 검색에서 결과를 클릭하거나 질의를 입력하면, 로컬 데이터 모듈(424-6)은 프라이빗 테이블을 업데이트할 수 있다(가령, 클릭 및 검색 히스토리를 저장(추가)함).

일부 구현예에서, 이벤트(예를 들어, 시스템/디바이스 이벤트)는 로컬 데이터 모듈(424-6)을 트리거할 수 있다. 예를 들어, 사용자가 애플리케이션을 설치하면, 시스템 이벤트가 트리거될 수 있으며, 시스템 이벤트는 설치된 패키지에 해당하는 로컬 테이블을 업데이트하기 위해 로컬 데이터 모듈을 활성화시킬 수 있다. 로컬 데이터 모듈은 설치 시간, 애플리케이션의 디스플레이 이름 및 디스플레이 이름에서 생성될 수 있는 정규화된 이름으로 로컬 데이터를 업데이트할 수 있다. 로컬 데이터 모듈(424-6)을 트리거링하는 이벤트들 이외에도, 로컬 서비스 모듈(102-9)은 시스템/OS 기능들을 주기적으로(이벤트 구동 또는 스케줄링) 질의할 수 있다. 예를 들어, 사용자가 애플리케이션(예: 런처 애플리케이션)을 오픈할 때다마 또는 특정 제스처를 사용할 때마다, 로컬 서비스 모듈은 설치된 애플리케이션에 대한 최신 데이터를 요청할 수 있다. 이를 통해 로컬 서비스 모듈은 최신 정보를 항상 사용할 수 있고 최신 상태로 유지할 수 있다.

로컬 질의 저장소(1506)는 다양한 온-디바이스 기능에 대한 검색 동작을 결정하는데 사용될 수 있다. 로컬 질의 저장소의 각각의 엔트리는 "로컬 검색" 또는 "광고", "질의"(예: SQL) 및 지정된 바인딩 세트와 같은 ID를 지정할 수 있다. 사용자 이벤트(예: 검색, 검색 애플리케이션 열기 등)가 검색(예컨대, 앱 이름 검색, 제로 상태 기회, 힌트 기회, 광고 기회 등)을 트리거하는 경우, 질의 실행 엔진(1502)은 로컬 질의 스토어(1506)로부터 대응하는 질의를 로드할 수 있다(예를 들어, 특정 SQL 질의 및 바인딩). 바인딩들은 "키 이름들"의 어레이일 수 있는바, 여기서 키 이름들은 사용자, 검색 및/또는 디바이스 컨텍스트의 속성들을 참조할 수 있다. 순서는 실행될 SQL 질의에서의 상대적인 위치에 기초할 수 있다. 예를 들어, 사용자가 가상 키보드를 열고 "AMa"를 입력하면, 이것은 앱 이름 검색 및 질의 기반 광고 검색을 트리거할 수 있다. 앱 이름 검색은 id " app_name_search "에 해당하는 SQLite 질의와 (normalized_user_query , normalized_user_query , normalized_user_query , geo_lat , geo_lng , is_connected)와 같은 바인딩을 로드할 수 있다. SQL 질의에는 여러 파라미터가 포함될 수 있으며 각 파라미터는 바인딩의 엔트리에 해당할 수 있다. 로컬 질의 실행 엔진(1502)은 사용자/앱 컨텍스트로부터의 값으로 바인딩을 채움으로써 SQL 질의를 실행할 수 있다. 컨텍스트는 예를 들어, is_connected(예컨대, 인터넷을 사용할 수 있는 경우) 또는 normalized_user_query 등과 같은 사용자의 디바이스 정보 또는 사용자 액션 컨텍스트를 포함할 수 있다. 이 경우, normalized_user_query 는 'ama'일 수 있고, 사용자의 디바이스가 현재 인터넷에 연결되어 있다면 is_connected 는 참(True)일 수 있다. 이와 병행하여, 동일한 질의는 광고 검색을 트리거할 수 있다. 앱 이름 검색과 유사하게 SQL 질의와 바인딩이 있을 수 있으며, 이는 값들로 채워질 수 있고 그리고 질의가 실행된다. 이 경우, id는 "ads_search"일 수 있다. 질의 실행 엔진(1502)은 상이한 결과 생성 서브시스템들의 실행을 제어하는 컴포넌트일 수 있다. 기본적인 흐름은 이벤트(예를 들어, 질의, 스와이프 업, 등)에 응답하여, 전술한 바와 같이 로컬 질의 저장소(1506)로부터 적절한 질의를 선택 및 실행하고, 다음으로 결과를 프로세싱하고 렌더링하는 것일 수 이다. 또한, 이벤트 및 결과에 응답하여 분석을 위한 데이터를 생성할 수 있다.

질의 실행 엔진(1502)은 동적으로 업데이트된 질의(예: SQL 질의) 및 데이터베이스/테이블을 사용하도록 구성될 수 있다. 경우에 따라, 타임아웃(예컨대, 느린 SQL 질의), 잘못된 질의(bad query), 또는 결과 생성을 시도할 때 발생하는 기타 오류와 같은 문제가 있을 수 있다. 오류가 있는 경우에도 원활한 사용자 경험을 보장하기 위해, 하드 코딩된 최소 기능 폴백 메커니즘(hard-coded minimally functional fallback mechanism)이 있을 수 있다. 오류 조건이 발생하면, 폴백 기능이 사용되어 기본 앱 이름 검색 기능을 제공할 수 있다. 오류 조건은 타임아웃/느린 질의, 내부 OS 오류(저장소 만충(full storage) 또는 기타 오류), SQL 오류(예: 유효하지 않은 질의, 유효하지 않거나 일관되지 않은 바인딩, 존재하지 않는 테이블 또는 컬럼에 대한 질의와 같은 데이터-트리거링 에러), 결과 생성 오류(예: 딥 링크의 유효성 확인 실패) 및 임의의 처리되지 않은 예외 또는 오류, 등을 포함할 수 있지만, 이에 한정되지는 않는다.

분석 이벤트 프로세서(1504)는 로깅가능한(loggable) 이벤트 데이터/오류를 수신하고 그리고 분석 데이터가 적절하게 구성되어 분석 시스템(1310) 및/또는 원격 서비스 시스템(들)(106)으로 전송되도록 보장할 책임이 있다. 서버-기반 검색 시스템(110)에서, 임의의 컴포넌트는 임의의 메시지들을 생성하고 그리고 이들을 로컬적으로 즉시 로그할 수 있으며, 이는 전체 시스템 로그에서 캡처될 수 있다. 또한, 사용자 활동(예컨대, 모든 사용자 활동)은 웹 URL 또는 API 요청을 통해 수행되어, 이들이 자동으로 로깅되게 할 수 있다. 일부 경우, 로컬 서비스 모듈(102)은 대역폭 및 프라이버시 제한과 함께 부분적인 연결해제 모드에서 동작할 수 있다. 사용자 액션은 중앙집중식 서버에서 알 수 없을 수도 있으며, 제한된 연결성 및 대역폭 가정으로 인해, 로깅가능한(loggable) 각각의 메시지를 정규(regular) 로그 수신 서버로 직접 보내는 것이 불가능할 수도 있다. 분석 이벤트 프로세서(1504)는 데이터/오류를 수신할 수 있고, 각각의 이벤트는 집계, 지속 또는 큐잉될 수 있고, 결국 분석 시스템(1310) 및/또는 원격 서비스 시스템(106-6)으로 전송될 수 있다.

분석 이벤트 프로세서(1504)는 다음의 기능들을 수행할 수 있다: 1) trackClick , trackFailure 등을 포함하는 상이한 APIs를 통한 메시지 집계, 2) 분석 페이로드로 메시지를 포맷함, 3) 연결이 없을 때, 또는 허용가능한 대역폭이 모두 사용되었을 때(예컨대, WiFi와 반대되는 셀룰러 네트워크에서) 페이로드 유지, 4) 지정된 조건 또는 이벤트(예컨대, 디바이스가 WiFi에 연결되거나 배터리가 75% 이상 충전됨)와 같이 전송이 허용될 때까지 이벤트들을 배치함(batch). 분석 이벤트 프로세서(1504)는 클릭, 임프레션(impression) 및 요청과 같은 적절한 이벤트가 로컬 분석(프라이빗) 데이터베이스에 저장되는 것을 보장하기 위해 분석 데이터베이스 업데이트를 수행할 수도 있다. 도 15에서, 로컬 데이터 모듈(424-6)은 분석 이벤트 프로세서(1504)를 포함하거나 그에 공급할 수 있다. 또한, 분석 이벤트 프로세서(1504)는 임프레션 추적을 수행하고 그리고 대역폭 사용량 뿐만 아니라 시스템 상태(예를 들어, WiFi, 셀룰러 데이터, 인터넷 없음, 느린 연결 등)를 모니터링할 수 있다. 분석 이벤트 프로세서(1504)는 또한 이벤트 데이터를 암호화/인코딩하여 인터셉트를 방지하고, 프라이버시 요구 사항을 시행하고, 비밀 정보가 전송되지 않도록(예를 들어, 필터링 또는 다른 규칙을 사용하여) 보장할 수 있다.

번들 생성 모듈(1406)은 새로운 서버 동기화 데이터를 수집하고 그리고 로컬 서비스 모듈(102)이 하나를 요청할 때 이를 최종 번들로 구축하는 일을 담당할 수 있다. 번들 생성 모듈(1406)에 의해 관리되는 데이터 모델에서, 각각의 번들은 번들 콘텐츠 내의 데이터 조작 커맨드가 수정할 수 있는 하나 이상의 데이터베이스를 포함할 수 있다. 예시적인 수정은 SQLite 호환 SQL에서 정의될 수 있으며, 새로운 SQLite 데이터베이스 및 마이그레이션 설명문(statement)(예컨대, 데이터베이스 내의 테이블 스키마를 생성, 삭제 또는 변경하는 명령)의 생성을 포함할 수 있다. 새로운 테이블들이 생성될 수도 있으며 또는 기존 테이블들이 제거될 수도 있다. 새로운 인덱스가 생성될 수도 있다. 예시적인 수정은 또한, 테이블 내의 로우(rows)를 삽입, 삭제 또는 업데이트하는 커맨드와 같은 데이터 업데이트 설명문을 포함할 수 있다. 데이터베이스의 데이터 모델과 함께, 각각의 데이터베이스는 로컬 서비스 모듈(102)에 의해 사용되어야 하는 방법에 대한 구성을 포함할 수 있다. 제공된 원격 구성은 다음과 같은 설정을 포함할 수 있다: 1) 앱 이름 질의를 프로세싱하는 것, 관련 광고를 디스플레이하는 것, 또는 제로 상태를 보여주는 것과 같이 태스크를 수행하기 위해 실행되어야 하는 SQL 질의들, 2) 로컬 서비스 모듈이 원격 서비스 시스템으로부터 업데이트된 데이터베이스를 가져와야 하는 빈도에 대한 리프레시 간격 계약, 및 3) 새로운 번들에 대한 다음번 요청시에 로컬 서비스 모듈에 의해 포함되어야 하는 데이터 버전 서명.

각 번들의 데이터베이스에 대한 데이터 업데이트 설명문을 구성하는 데이터는 하나 이상의 데이터 제공자로부터 채워질 수 있다. 이러한 데이터 제공자는 번들 생성 모듈 외부의 다른 데이터 소스들(예컨대, Python 및 Java 서비스 및 데이터 저장소)와 인터페이스한 다음, 검색된 데이터를 번들 데이터 모델의 일부인 SQL 커맨드로 변환할 수 있다.

번들 생성 모듈(1406)은 로컬 서비스 모듈(102)로부터 수신한 데이터 버전 서명을 사용하여, 각각의 서브-데이터베이스에 대해, 해당 데이터 버전 서명 이후에 발생한 데이터베이스 생성 및 마이그레이션 설명문의 목록을 구축할 수 있다. 번들 생성 모듈(1406)은 또한 각각의 데이터 제공자 페치(fetch) 커맨드를 실행하고, 데이터를 SQLite SQL 명령으로서 집계할 수 있다. 번들 생성 모듈(1406)은 또한 데이터 제공자마다 구성되는 최소 및 최대 예상 리프레시 간격을 집계하고 그리고 이를 로컬 서비스 모듈의 예상 리프레시 간격으로 설정할 수 있다. 예를 들어, 광고 제공자는 1시간의 최소 리프레시 간격 및 24시간의 최대 리프레시 간격을 예상할 수 있다. 본 일례에서, 다른 제공자(예: 엔터티 제공자)는 6시간의 최소 리프레시 간격 및 12시간의 최대 리프레시 간격을 예상할 수 있다. 최소 새로 고침 간격이 6시간이고 최대 새로 고침 간격이 12시간이라고 예상할 수 있다. 이러한 일례에서, 해당 데이터베이스에 대해 계산된 전체 최소 및 최대 리프레시 간격들은 최소 1시간에서 최대 12시간일 수 있다.

로컬 서비스 모듈 업데이트를 일관성 있게 유지하기 위해, 원격 서비스 시스템(106)에 대한 각각의 호출에 대해 데이터 버전 서명이 생성될 수 있다. 이것은 데이터베이스 버전 및 데이터 제공자의 페치된 데이터 버전에 대한 정보를 인코딩할 수 있다. 상기 서명은, 디바이스의 데이터 버전 서명에 기초하여 특정 디바이스에 대해 실행할 마이그레이션 설명문을 생성하고 그리고 원격 서비스 시스템(106)에서 사용가능한 최신 데이터베이스 마이그레이션과 비교하는데 이용될 수 있다. 일례로서, 로컬 서비스 모듈이 데이터베이스의 "버전 5"를 마지막으로 검색했으며, 원격 서비스 시스템이 알고 있는 최신 버전은 "버전 8"이라고 가정하자. 이 경우, 원격 서비스 시스템은 "버전 6", "버전 7" 및 "버전 8"의 커맨드들을 결합하여, 실행할 마이그레이션 설명문의 최종 목록을 작성할 수 있다.

서명은 또한 로컬 서비스 모듈이 원격 서비스 시스템으로부터 업데이트를 마지막으로 수신했을 때 데이터 제공자의 상태에 대한 메타데이터를 저장하는데 사용될 수 있다. 데이터 제공자를 위해 포함될 수 있는 버전 서명 정보의 일부 일례들은, 디바이스 로케일(locale) 정보 또는 디바이스 상태에 대한 기타 관련 변경 사항을 포함할 수 있는바 가령, 디바이스 로케일이 언제 영어에서 힌디어로 변경되었는지를 포함할 수 있으며, 언어별 정보를 제공한 소정의 데이터 제공자는 새로운 서버 동기화 데이터를 새로운 언어로 제공하기 전에 디바이스 상의 오래된 데이터를 삭제하기를 원할 수도 있다. 데이터 제공자를 위해 포함될 수 있는 버전 서명 정보의 또 다른 일례는 마지막 번들 리프레시 시간을 포함할 수 있으며, 이것은 요청을 디바운스(debounce)하는데 이용될 수 있어, 번들이 로컬 서비스 모듈 상에서 짧은 타임 윈도우 이전에 이미 리프레시된 경우 서비스 용량을 보존할 수 있다.

일부 구현예에서, 시스템은 번들 요청과 번들 서버 데이터 사이에서 지연 로드 캐시(lazy-load cache)를 구현할 수 있다. 요청이 양자화되면(그리고 오래된 시간으로 반올림), 요청이 많이 반복될 수 있으므로, 지연 로드(lazy-load)는 최소한의 실제 서버 백엔드 요청들을 갖는다. 옵션으로서, 마지막-시간(last-time)이 최대값보다 큰 요청들(또는 처음 요청들)의 경우, 원격 서비스 시스템은 미리 생성된 "이전 데이터 삭제가 포함된 전체 데이터(full data with delete old)" 번들을 보낼 수 있다.

서버 업데이트 모듈은 대역폭 제약(예를 들어, 하루에 1 MB의 셀룰러 데이터로 제한됨)을 겪을 수도 있다. 번들 생성 모듈(1406)은 최대 데이터 사이즈를 파라미터로 취할 수 있다. 서버 업데이트 모듈은 "오래된/마지막으로 업데이트된" 레코드들을 "대량 삭제(bulk-delete)"하도록 구성될 수도 있다. 예를 들어, 각각의 로우가 "마지막으로 터치된(last-touched)" 버전/날짜를 갖는다면, 번들 생성 모듈(1406)은 타임스탬프를 사용하여 일관성을 증가시키고 그리고 명시적인 삭제 요청을 감소시킬 수 있다. 이와 유사하게, 대역폭 제한이 있는 경우, 원격 서비스 시스템은 가장 중요한 데이터를 우선시할 수 있다. 임의의 엔트리의 중요도는, 앱/패키지의 인기도 또는 마지막 업데이트 이후의 점수 변화 등 여러 요인에 의해 결정될 수 있다.

로컬 서비스 모듈(102)(예를 들어, 바로가기 모듈(1302))은 애플리케이션 결과 및/또는 바로가기 결과(예를 들어, 애플리케이션 내의 딥링크)를 반환할 수 있다. 일 예에서, 사용자가 앱을 검색하는 경우(예컨대, 서브스트링 질의(substring query)에 의해), 로컬 서비스 모듈(102)은 애플리케이션을 열기 위해 선택될 수 있는 사용자 선택가능한 아이콘 링크와 같이 애플리케이션 자체를 반환할 수 있다. 부가적으로 또는 대안적으로, 로컬 서비스 모듈(102)은 바로가기를 애플리케이션에 반환할 수 있다. 바로가기는 애플리케이션의 중요하거나 인기있는 상태 또는 기능에 대한 딥링크를 참조할 수 있다. 예를 들어, 사용자가 "ama"를 검색하는 경우, 런처는 "장바구니 보기(view cart)", "과거 주문" 및 "인기 있는 전자 제품" 에 대한 바로가기 딥링크와 함께, 아마존 쇼핑 애플리케이션 링크(예컨대, 홈페이지에 대한 애플리케이션을 열기 위해)를 반환할 수 있다. 또 다른 일례로서, 로컬 서비스 모듈은 "유행하는 노래(Trending songs)", "개인 재생 목록(Personal Playlist)" 또는 기타 링크에 대한 딥링크(바로가기)와 함께 아마존 뮤직(Amazon Music)을 반환할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102)은 애플리케이션 이름 의도 질의를 처리하고 그리고 식별된 애플리케이션에 대한 애플리케이션 및 바로가기 결과를 포함하도록 구성될 수 있다. 온-디바이스 앱-이름 검색의 맥락에서, 사용 사례는 현재 디바이스에 설치되어 있는 사용 중인 애플리케이션을 찾는 사용자일 수 있다. 또한, 사용자는 단일 문자 질의만큼 적은 결과가 발견될 것으로 예상할 수 있다.

사용자가 아마도 어떤 앱을 찾고 있는지 및 각각의 앱이 부분적인 쿼리에 대한 얼마나 가능성이 있는지를 결정하는 것은, 로컬 서비스 모듈에 의해 구현될 수 있다. 로컬 서비스 모듈 앱 이름 검색 구현은 다음을 구현할 수 있다: 1) 매칭 및 랭킹 둘다를 위해 온-디바이스 획득 데이터를 고려함(예컨대, 애플리케이션 이름, 사용자 참여 클릭/오픈/과거 검색, 기타 앱 등), 2) 애플리케이션들의 매칭 및 랭킹을 향상시키기 위해 원격 서비스 시스템에서 원격 동기 데이터를 고려함, 3) 개발자와 원격 서버에서 보낸 앱 바로가기를 결합함, 4) 오류/버그가 있는 경우 폴백 사용, 및 5) 동적으로 온-디바이스 검색/랭킹 질의(SQLite SQL 설명문)를 동적으로 업데이트하고(예컨대, 번들을 통해), 원격 동기화 데이터를 기반으로 생성된 테이블을 동적으로 수정한다.

로컬 서비스 모듈(102)에 의해 제공될 수 있는 앱 의도 검색 기능의 예시적인 구현예가 이제 설명된다. 처음에, 사용자는 하나의 문자 또는 소수의 문자(예컨대, "am")와 같은 질의를 입력할 수 있다. 다음으로, 가능한 매칭 애플리케이션에 대해서 온-디바이스 로컬 데이터(예: 애플리케이션 데이터)가 조회될 수 있다. 이것은, 각 애플리케이션의 정규화된 디스플레이 이름과 사용자의 질의를 비교하는 것을 포함할 수 있으며, 애플리케이션 개발자는 디스플레이 이름을 설정할 수 있다. 애플리케이션 디스플레이 이름의 일례는 "구글 맵-내비게이션 등(Google Maps-Navigation and more)" 또는 "메일"(삼성 이메일의 경우)를 포함할 수 있다. 가능한 매칭 애플리케이션들과 사용자의 질의를 비교하는 것은 좌측-고정 매치(left anchored match)를 찾는 것을 포함할 수 있다. 예를 들어, query = "am"으로 시작하는 정규화된 앱 이름은, "Amazon Shopping"이라는 앱 이름과 매칭할 수 있다. 또한, 이것은 중간 단어들의 매칭 시작을 포함할 수 있으므로, "am"은 "Shopping by Amazon" 또는 "Who am I?" 와 매칭할 수 있다. 또한, 질의 및 애플리케이션 이름들에서 공백(space)을 제거하여 매칭될 수도 있으므로, "you tu"는 "youtube" 라는 애플리케이션과 매칭된다. 유사하게도, "eb"라는 사용자 질의는 "e-bay"라는 애플리케이션과 매칭할 수 있다. 임의의 매칭을 포함하는 다른 동작들도 구현될 수 있는바, 가령, "hey"는 "Who Are They"라는 이름의 애플리케이션에 매칭될 수 있을 뿐만 아니라, "Hey Duggee Adventures" 라는 이름의 애플리케이션에도 매칭될 수 있다.

다음으로, 사용자의 정규화된 질의는 수신된 업데이트 번들로부터 서버 동기화된 애플리케이션 데이터에서 조회될 수 있으며, 여기서 그것은 많은 애플리케이션들과 매칭될 수 있고, 매칭되는 일치하는 애플리케이션들은 설치된 애플리케이션 세트에 대해 체크될 수 있다. 서버 동기화 데이터는 대안예들을 포함할 수 있다(예컨대, "fb" --> "Facebook", "pau" --> "PayTm"). 서버 동기화 데이터는 가령, 많은 사용자들이 "pau"를 타이핑한 다음 이를 "pay"로 수정하고 PayTm 앱을 선택하는 것과 같은, 집계된 사용자 행동을 기반으로 원격 서비스 시스템에서 구축될 수 있다. 인간 편집자가 대안예들을 생성할 수도 있다. 또한, 맞춤법 교정, 두음문자 생성(acronym generation) 등과 같은 다른 알고리즘도 사용될 수 있다.

후보 앱들의 세트는, 로컬적으로 획득한 데이터로부터 매칭된 애플리케이션과 설치된 애플리케이션을 포함하도록 필터링된 로컬 서버 동기화 애플리케이션 데이터의 합집합일 수 있다. 후보 앱들은 버킷들/그룹들에 담을 수 있다. 앱을 그룹화/버킷화하는데 사용되는 일반적인 피처는 다음을 포함할 수 있지만 이에 국한되지는 않는다: 1) 참여의 최근성(예를 들어, 마지막 7일(last 7-days)은 버킷 B1에 있고 더오래된 것은 버킷 B2에 있음), 2) 매칭의 유형(예를 들어, 처음부터 매칭되는 것은 버킷 B1, 중간 단어에서 시작하여 매칭되는 것은 버킷 B2, 다른 모든 나머지는 버킷 B3), 및 3) 애플리케이션 인기도, 여기서 인기 있는 애플리케이션(예컨대, 서버 동기화 데이터에 의해 결정되거나 및/또는 사용자 참여로부터 생성됨)은 버킷 B1에 있을 수 있으며, 덜 인기 있는 애플리케이션은 버킷 B2에 있을 수 있다.

이후, 각 후보에 점수를 매길 수 있다. 점수는 그룹에 따라 다를 수 있다. 예를 들어, 버킷 B1은 참여의 최신성에 기초하여 스코어링될 수 있고, B2는 애플리케이션의 인기도를 기반으로 스코어링될 수 있다. 스코어링은 로컬적으로 획득된 데이터 뿐만 아니라 서버 동기화 데이터의 데이터를 모두 활용할 수 있다. 매칭의 유헝도 고려될 수 있다. 예를 들어 "처음부터 매칭"은 단어 중간에서 매칭되는 것보다 더 높은 점수가 받을 수 있다(또는 더 좋은 버킷에 넣을 수 있음). 일부 경우, 서버 동기화 데이터는 "맞춤법 오류(misspelling)"와 같은 "매칭 유형"을 지정하거나, 및/또는 "매칭의 유형"과 관련된 특정 점수를 제공할 수 있다. 스코어링의 예시적인 인자들은 다음을 포함할 수 있지만 이에 국한되지 않는다: 1) 온-디바이스 참여의 최신성(recency of engagement on-device)(예를 들어, 가장 최근에 사용자가 앱을 오픈한 시간), 2) 애플리케이션 설치의 최신성(예를 들어, 보다 더 최근에 설치된 애플리케이션일수록 순위가 더 높음), 3) 참여의 빈도(예: 지난 7일 동안 열린 횟수), 4) 애플리케이션 사용 시간(예: 지난 7일 동안 애플리케이션이 열린 시간), 5) 애플리케이션 인기도, 이는 집계 사용자 행동을 기반으로 원격 검색 시스템에서 생성될 수 있으며 그리고 사용자 위치에 따라 수정될 수 있음(예컨대, 페이팔(PayPal) 애플리케이션은 인도보다 미국에서 더 인기가 있을 수 있음), 6) 서버 동기화 데이터로부터의 질의별 의도 점수, 이는 사용자 행동 또는 기타 데이터에 기초하여 생성될 수 있다(예를 들어, "fca" --> "facebook"는 "fca" --> FCA 은행 보다 낮은 점수를 가질 수 있지만, "fac" --> "facebook"는 "fac" --> FCA 은행 보다 높은 점수를 가질 수 있다), 및 7) 애플리케이션 트렌드 점수, 덜 인기있는 애플리케이션이 유행중일 수 있으며, 그리고 인기가 절대적으로 높지만 하락세를 보이는 애플리케이션보다 더 높은 점수를 받을 수 있다.

다음으로, 각 그룹 내의 애플리케이션들은 점수별로 순위화/정렬될 수 있다. 일부 구현예에서, 애플리케이션들은 피처, 순위 등에 따라 필터링될 수 있다. 일부 구현예에서, 0개 이상의 애플리케이션들에 대해, 애플리케이션 바로가기들이 병합될 수 있다.

바로가기는 여러 소스에서 올 수 있다. 예를 들어, 바로가기는 온-디바이스 개발자(앱)에서 생성한 바로가기에서 가져올 수 있으며 그리고 정적 또는 동적 링크를 포함할 수 있다. 예를 들어, 사용자가 Yelp 애플리케이션을 열고 채식 식당을 검색하면, Yelp는 "나에게 가까운 채식 식당"이라는 바로가기를 추가할 수 있다. 일부 구현예에서, 바로가기는 서버에서 생성될 수 있다. 인기있는, 유행하는, 중요한, 및/또는 개인화된 바로가기가 원격 서비스 시스템(106)에서 생성된 다음 업데이트 번들로 전송될 수 있다. 저장되거나 또는 사용자 활동과 관련된 액션들에 대응하는 딥링크가 이들 바로가기들에 포함될 수 있다. 바로가기는 사용자 참여 엔터티/딥링크를 포함할 수 있다. 예를 들어, 사용자는 검색에서 액션을 수행한 다음(예컨대, "베이글"을 검색함), "Bagel Barn"에 대한 Yelp 결과를 클릭할 수 있으며, 여기서 해당 링크는 바로가기로 취급될 수 있다.

런처(1300)는 애플리케이션 검색을 개인화하는 것과 유사한 방식으로 바로가기를 개인화할 수 있다. 개인화는 많은 인자들에 기초할 수 있다. 예를 들어, 사용자 참여(예를 들어, 개인화 및 총계 모두) 바로가기가 그에 따라 선택, 필터링 및/또는 순위화될 수 있다. 바로가기 순위화/선택은 다양한 피처들에 기초할 수 있으며, 이러한 피처들은 다음을 포함할 수 있지만 이에 국한되지 않는다: 1) 사용자가 바로가기를 마지막으로 클릭한 시간, 2) 사용자가 바로가기를 클릭한 빈도 및 3) 사용자가 바로가기를 사용하는 방법. 예를 들어, 아마존(Amazon) 애플리케이션에서 사용자가 신발을 검색한 다음, "나이키 신발(Nike Shoes)"를 클릭하면, 해당 바로가기가 선택되고 다음에 "am"을 검색할 때 부스트(boost)될 수 있다. 바로가기 점수에 대한 서버 동기화 데이터는 인기도 점수를 포함할 수 있다. 상기 점수는 총 사용자 참여(절대적인 또는 상대적인)의 함수일 수 있다. 예를 들어, 나이키 신발에 대한 아마존 쇼핑 바로가기(Amazon shopping shortcut)는 많은 사용자가 클릭한 경우 높은 점수를 받을 수 있다. 또 다른 일례에서, 애플리케이션에 대한 "새로운 게임 시작(Start a New Game)" 바로가기는 지난주에 10배 클릭되는 부스트를 받을 수 있다. 로컬 서비스 모듈(102-8)은 또한 타임라인(timeliness), 신선도(freshness) 및 트렌딩 팩터를 고려할 수 있다. 예를 들어, 최근 뉴스 기사는 지난주 뉴스보다 더 많은 부스트를 받을 수 있다. 또 다른 예로, 인기있거나 유행하는 바로가기/콘텐츠는 덜 유행하는/인기있는 바로가기보다 부스트를 받을 수 있다. 바로가기는 과거 참여의 속성들에 기초하여 선택 및/또는 스코어링될 수 있다(예를 들어, 여기에서는 프라이버시 목적으로 온 디바이스 전용 데이터가 사용될 수 있음). 예를 들어, 사용자가 야구 애플리케이션에서 "스포츠 뉴스" 태그가 있는 바로가기를 자주 클릭하는 경우, "스포츠 뉴스" 태그가 있는 "마이 비즈니스 뉴스 앱"의 바로가기가 부스트를 받을 수 있다.

바로가기가 선택되고 스코어링된 후, 바로가기가 UI(예를 들어, 런처 또는 다른 애플리케이션 UI)에 포함/디스플레이되는 다양한 방법들이 있을 수 있다. 일부 경우, 최상위 순위의 애플리케이션들에 대한 바로가기만이 표시된다. 일부 경우, N개 이상의 애플리케이션이 매칭되면 바로가기가 표시되지 않을 수 있다. 예를 들어, 15개의 앱과 매칭되는 질의 "a"는 임의의 바로가기를 표시하지 않을 수 있지만, 3개의 애플리케이션과 매칭되는 "amazon" 이라는 질의는 바로가기를 표시할 수 있다. 바로가기에 대한 점수는, 얼마나 많은 및 어떤 바로가기들이 표시되는지를 결정할 수 있다. 예를 들어, 런처는 "a" 라는 질의를 가질 수 있으며, 이는 Amazon Shopping(1위), Amazing Adventures(2위) 및 Amazon Music(3위)를 가질 수 있다(예를 들어, 사용자의 마지막 참여에 의해 순위가 매겨질 수 있음). 만일, 아마존 뮤직(Amazon Music)의 "Helter Skelter에 대한 플레이를 재개하라" 가 100점을 갖고, "주문 상태 확인"이 90점을 갖고, "나이키 신발"이 25점을 갖는다면, 런처는 아마존 쇼핑 및 아마존 뮤직 각각에 대한 하나의 바로가기를 표시할 수 있다.

일부 구현예에서, 로컬 서비스 모듈(102)은 제로 상태 기능을 구현할 수 있다(예를 들어, 도 13의 제로 상태 모듈 1304을 사용하여). 일반적으로, 제로 상태 기능은 사용자가 검색 질의를 입력하지 않고도 구현될 수 있다. 달리 말하면, 검색 질의를 입력하지 않고도, 사용자는 다양한 방식으로 제로 상태 기능을 경험할 수 있다. 예를 들어, 사용자는 질의 힌트 및 제로 상태 링크로서 제로 상태 기능을 경험할 수 있다. 질의 힌트(즉, 힌트)는 사용자가 선택(예를 들어, 터치/클릭)할 때 마치 사용자가 문구를 질의하고 검색한 것처럼 사용자를 검색 경험으로 리디렉션(re-direct)할 수 있는 문구를 의미할 수 있다. 제로 상태 링크는 애플리케이션 바로가기 또는 애플리케이션의 특정 기사 또는 페이지와 같은, 검색 바(search bar)로부터의 가능한 검색 결과들을 포함할 수 있다. 링크를 클릭하면 해당 링크의 애플리케이션 바로가기나 애플리케이션의 특정 기사 또는 페이지로 사용자가 리디렉션될 수 있다. 서버는 제로 상태 기능을 위해 데이터를 채우고 동기화할 수 있으며, 로컬 서비스 모듈(102)(예를 들어, 제로 상태 모듈 1304)은 로컬 온-디바이스 데이터를 사용하여 사용자에게 디스플레이되어야 하는 것을 개인화할 수 있다. 제로 상태 기능은 배경에서, 스크린의 위젯에서, 사용자 제스처(예: 스와이프 업)에 응답하여 다양한 방식으로 트리거될 수 있으며, 디바이스는 일정 시간 동안 유휴 상태이고, 및/또는 스크린은 상호작용 없이 일정 시간 동안 켜져 있다. 제로 상태 기능에 대한 트리거는 여기에서 "제로 상태 트리거"로 언급될 수 있다.

제로 상태 기능은 이하에서 설명되는 다양한 피처들을 포함할 수 있다. 일부 구현예에서, 제로 상태 기능은 랭킹을 위해 온-디바이스 데이터를 고려할 수 있으며(예컨대, 애플리케이션 이름, 클릭/열기/과거 검색을 포함한 사용자 참여, 기타 설치된 애플리케이션 등) 그리고 질의 힌트 및 제로 상태 링크의 순위를 향상시키기 위해 "원격 서버(비개인화)" 동기화 데이터를 고려할 수 있다. 제로 상태 기능은 제로 상태 링크들에 대한 결합된 개발자 및 원격 서버 전송 앱 바로가기들을 포함할 수 있다. 일부 구현예에서, 제로 상태 기능은 온디바이스 검색/랭킹 질의(SQLite SQL 설명문)를 동적으로 업데이트하고(예컨대, 업데이트 번들을 통해) 그리고 원격 서버 데이터를 기반으로 생성된 테이블을 동적으로 수정할 수 있다.

일부 구현예에서, 질의 힌트는 원격 서비스 시스템(106)으로부터 동기화될 수 있으며, 질의 힌트는 제안된 애플리케이션들의 개인화되지 않은 목록 및 이러한 애플리케이션들에 대한 콘텐츠를 보여줄 제안된 질의 스트링을 가질 수 있다. 예시적인 힌트는 "zee5 tv shows"일 수 있다. 사용자가 제안된 질의를 클릭하면 검색 통합으로 이동하고, zee5 애플리케이션 내부의 콘텐츠에 대한 검색 결과가 표시될 수 있다. 디바이스에서, 이러한 예시적인 고려 사항들이 이용되어, 어떤 질의 힌트를 디스플레이할지를 결정할 수 있다: 1) 디바이스에 현재 설치된 애플리케이션으로 가능한 서버 동기화 힌트를 제한함, 2) 최근에 참여한 애플리케이션에 대한 선호도를 부스트함, 3) 힌트들을 가지며 그리고 최근에 참여한 3개 이상의 애플리케이션이 있는 경우, 가장 최근에 사용한 3개의 애플리케이션에 대한 임의 힌트를 표시함, 및 4) 최대 총 3개의 나머지 애플리케이션에 대해, 랜덤 애플리케이션과 해당 애플리케이션에 대한 임의 힌트를 포함한다.

원격 서비스 시스템(106)은 다양한 소스를 사용하여 로컬 서비스 모듈(102)로 전송될 수 있는 질의 힌트 목록을 채우고 생성할 수 있다. 예를 들어, 소스는 다음을 포함할 수 있지만 이에 제한되지 않는다: 1) 인기있는 콘텐츠 검색 질의들의 수동으로 엄선된 목록, 2) 수동으로 선택된 관심 콘텐츠, 3) 유행하는 콘텐츠 제목들로부터 자동으로 생성된 질의 힌트, 4) 모든 콘텐츠 제목에서의 인기 검색어, 및 5) 애플리케이션 사용예에 따른 개인화된 힌트들. 특정 예에서, 애플리케이션 사용에 기초한 개인화된 힌트와 관련하여, 아마존 쇼핑 카트를 자주 여는 사용자에게는 가령, "아마존 - 쇼핑 카트"와 같은 해당 행동에 특정한 힌트가 제공될 수 있다. 다른 예로서, 게임을 자주 하는 사용자에게는 "게임을 해라(Play a game)"라는 힌트가 주어질 수 있다.

제로 상태 링크는 원격 서비스 시스템(106)으로부터 동기화될 수 있으며, 이는 제안된 애플리케이션들 및 이들 애플리케이션에 대한 링크들의 개인화된 목록을 가질 수 있고, 그런 다음 첫 번째 상호작용시에 사용자에게 보여주기 위한 최상의 링크 세트를 결정하기 위해 애플리케이션 바로가기에 대한 온-디바이스 정보와 결합될 수 있다. 제로 상태 링크는 디스플레이 데이터(예를 들어, 이미지, 디스플레이 제목 등) 및 사용자가 콘텐츠를 보고 상호작용(예를 들어, 선택)하기 위한 링크 정보를 포함할 수 있다. 이러한 방식으로, 제로 상태 링크는 콘텐츠를 보기 전에 사용자 선택(예: 터치/클릭)을 요구할 수 있는 제안된 질의 스트링을 제공하는 질의 힌트와 다를 수 있다.

제로 상태 링크는 디바이스 상에서의 다음의 예시적인 프로세스들 중 하나 이상을 사용하여 디스플레이하기 위해 선택될 수 있다: 1) 디바이스에 현재 설치된 애플리케이션으로 가능한 서버 동기화 링크들을 제한한다, 2) 로컬 서비스 모듈(102)에 의해 발견된 온 디바이스 바로가기들과 이들 서버 동기화 링크들을 결합한다, 3) 최근에 참여한 애플리케이션들에 대한 선호도를 부스트한다, 4) 링크 정보의 소스에 기초하여 링크에 대한 선호도를 부스트하며, 여기서 가능한 순위는 로컬 바로가기 링크보다 원격 동기화 콘텐츠 링크가 선호된다, 5) 최근 참여 및 링크 소스 선호도를 사용하여 각 애플리케이션 당 1개의 링크가 있는 소수의(예컨대, 3개) 애플리케이션을 무작위로 선택한다, 및 6) 앱 인기도, 참여의 최근성(온-디바이스 프라이빗 데이터를 사용하여), 참여의 빈도(온-디바이스 프라이빗 데이터를 사용하여), 및/또는 링크/바로가기의 인기도(예를 들어, 온-디바이스 프라이빗 데이터 또는 서버 집계 데이터)의 함수로서 애플리케이션들 및/또는 각 애플리케이션에 대한 다수의 결과들을 선택한다.

원격 서비스 시스템(106)은 다양한 소스를 사용하여 로컬 서비스 모듈(102)로 전송되는 제로 상태 링크 목록을 채우고 생성할 수 있다. 예시적인 소스는 다음을 포함할 수 있지만 이에 제한되지는 않는다: 1) 수동으로 엄선된 인기 링크들의 목록, 2) 분석에 의해 추적된 참여를 갖는 애플리케이션들의 개인화된 소스들, 3) 검색 통합에서 사용되는 콘텐츠 시스템(예: 콘텐츠 Elasticsearch 시스템)으로부터의 필터링된 콘텐츠 결과 선택, 4) 인기 있는 트렌드 콘텐츠, 5) 활성 웹 크롤링 시스템.

일부 구현예에서, 로컬 서비스 모듈(102)(예를 들어, 자동제안 모듈(1308))은 자동제안 기능을 제공할 수 있다. 자동제안(autosuggest)은 사용자의 현재 질의 스트링에 대한 질의 제안들 을 제공할 수 있다. 도 17은 예시적인 자동제안 GUI를 도시한다. 일부 구현예에서, 자동제안은 사용자가 검색 바에 질의를 입력할 때 원격 서비스 시스템(106)에 의해 실행될 수 있다. 일부 구현예에서 자동제안은 제안된 질의들을 만들기 위해 검색 콘텐츠와 함께 애플리케이션 지식에 의해 구동될 수 있다. 완성 유형들은 다음을 포함할 수 있지만, 이에 한정되지 않는다. 1) 애플리케이션 이름 완성: "ama" → "amazon", 2) 애플리케이션 개발자 바로가기 완성: "amazon" → "amazon order", 3) 애플리케이션 탐색 바로가기 완성: "limeroad" → "limeroad women's clothing", 4) 애플리케이션 이름 철자 오류 "amz" → "amazon" 및/또는 5) 콘텐츠 완성: "covid" → "covid 19".

자동제안은 사용자의 질의와 매칭되는 완성들을 만들기 위해 검색 콘텐츠와 함께 의도 애플리케이션 지식에 의해 구동될 수 있다. 의도 데이터는 사용자 앱 이름 의도 질의(예컨대, 'am' 및 사용자가 Amazon 쇼핑을 원함)에 대해 예측된 의도를 참조할 수 있다. 이러한 데이터는 월간 액티브 사용자(MAU: monthly active user) 또는 서버 상호작용에 기초하는 사용자 행동 데이터를 사용하여 만들어질 수 있다. 또한, 고쳐쓰기(rewrites)과 같은 질의 행동을 사용하여 새로운 매핑(예컨대, "ana" --> "ama" --> Amazon 쇼핑 클릭)을 검색/스코어링할 수 있다.

로컬 서비스 모듈(102)의 컨텍스트에서 자동제안은 사용자의 컨텍스트 및 사용자가 아마도 앱 이름 검색 바를 사용하고 있다는 사실을 고려할 수 있다. 자동제안에서, 사용자의 질의는 원격 서비스 시스템(106)으로 전송될 수 있고, 제안들이 만들어질 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102)은 로컬 데이터를 사용하여 자동제안 제안들의 순위를 재지정할 수 있다. 일부 구현예에서, 가령, 앱 ID, 태그 또는 점수와 같은 메타데이터와 함께 자동제안 결과들이 전송될 수 있다. 로컬 서비스 모듈(102)은 사용자의 로컬 데이터에 기초하여 랭킹을 수정할 수 있다(예를 들어, 최근에 사용된 앱 대 최근에 사용되지 않은 앱에 대해 더 높은 "트렌딩" 유형의 결과를 보여줌). 자동제안은 또한 다음과 같은 다양한 방식으로 수정될 수 있다: 1) 원격 서비스 시스템(106)에 대한 자동제안 요청은 최근에 사용한 앱 목록을 포함하는 사용자 컨텍스트를 포함할 수 있다, 2) 자동제안은 또한 애플리케이션 목록을 인코딩할 수 있으며(예: 블룸 필터) 따라서 실제로 설치된 애플리케이션이 알려지거나 전송되지 않지만 원격 서비스 시스템(106)에서 제한된 개인화가 허용되며, 및/또는 3) 자동제안은, 순위를 수정하기 위해 최근 참여에 대한 원격 서버 지식을 사용할 수 있다.

분석 시스템(1310) 및/또는 원격 서비스 시스템(106)은 로컬 데이터 모듈(424)(예: 분석 이벤트 프로세서 모듈(1504))로부터 전송된 데이터를 획득하고 그리고 원시 데이터를 제품/비즈니스 운영을 확장하는데 도움이 되는 유용한 데이터 제품으로 변환할 수 있다. 일부 구현예에서, 로컬 서비스 모듈(102) 및 분석 시스템(1310)은 대역폭 및 프라이버시 제한이 있는 부분적인 연결해제 모드에서 사용될 수 있다. 일부 경우(예를 들어, 연결로 인해), 각각의 로그가능 메시지를 분석 시스템(1310)에 직접 보내는 것이 가능하지 않을 수 있다. 또한 일부 컴포넌트는 원격 서버에 대한 호출을 경험할 수 있다(예를 들어, 자동제안). 이로 인해 분석을 수행할 때 해결해야 할 여러 개의 서로 다른 데이터 소스가 생성될 수 있다. 이러한 경우에, 로그는 분석 이벤트 프로세서(1504)로부터의 로그와 별도로 유지되고 구조화된 제품(자동제안)으로부터 병합될 수 있다. 어떤 경우에는 이벤트가 동기화되지 않을 수 있다. 예를 들어, 불량한 네트워크 및 대역폭 제약으로 인해 분석 시스템(1310)은 동일한 이벤트에 대한 분석 로그를 다른 시간에 수신할 수 있다. 예를 들어, 사용자가 오후 7시 59분에 "flip"을 질의하는 경우, 해당 사용자의 네트워크가 오후 8시부터 30분 동안 중단되면, "f" 및 " fl " 질의에 대해 오후 8시에 1 세트의 로그가 수신될 수 있다. 이러한 로그를 전송한 후, 8시 30분에 서버로 전송된 " fli " 및 "flip" 에 대한 메시지를 수신할 것이다. 분석 시스템(1310)은 여전히 이들 2개의 이벤트를 파싱하고 그리고 사용자로부터의 동일한 검색의 일부로서 이들을 조정해야 할 수 있다.

분석 시스템(1310)은 위에서 설명한 복수의 컴포넌트에 의해 방출된 로그들을 소비할 역할을 하며 이러한 로그가 제품 성능, 사용자 참여 및 향후 제품 개발 기회를 높은 신뢰성, 프라이버시 보호, 셀프 서비스 방식으로 분석할 수 있는 유틸리티들로 변환되도록 보장할 수 있다. 서버 기반 컴포넌트(예: 자동제안) 및 디바이스 기반 컴포넌트(예: 앱 이름 검색 또는 제로 상태)를 포함하는 각 컴포넌트에 의해 데이터가 방출되면, 분석 시스템(1310)은 이를 데이터를 중앙 집중식 데이터 프로세싱 유닛로 사이펀(siphon)할 수 있는바, 시스템은 자동으로: 1) 사용자 설정에 따라 개인 식별 정보를 제거하고, 2) 디바이스에서 생성된 모든 사용자 식별자를 프라이버시 보존/보호 사용자 식별자로 대체하여 사용자가 재식별되지 않게하며(예컨대, 내부 직원에 의해서), 및 3) 사용자가 완료한 이벤트에 대한 세분화된 메타데이터와 사용자에 대한 파생 정보로 프라이버시-보호 사용자 신원 그래프를 강화한다. 사용자에 대한 데이터는 이전의 임프레션들/클릭들의 타임스탬프 및 일정 기간 동안 완료된 참여 수(예: 일정에 따라 제거됨)일 수 있다. 예시적인 이벤트는 구매, 클릭, 앱 열기 등을 포함할 수 있다. 시스템은 특정 카테고리의 콘텐츠에 대한 친화도, 이들의 사용 수명주기 스테이지(예: 신규 사용자 대 파워 사용자), 선호도(예: 위치, 언어 선호도 등) 및 할당된 코호트 및 그룹(예: 이러한 사용자가 실험을 통해 치료를 받았는지 알려주는 부울 플래그)과 같은 사용자에 대한 파생 정보를 저장할 수 있다. 또한, 데이터에는 특정 시간/시간 범위에서 사용자가 참여한 실험(들)이 포함될 수 있다(예컨대, 앱-이름 검색 번들 빌더가 7월 4일에 실험 데이터 ID:AN3334를 보냈고 일반 데이터는 7월 8일...).

도 16-17은 로컬 서비스 모듈을 포함하고 및/또는 로컬 서비스 모듈로부터 데이터를 수신하는 애플리케이션(예를 들어, 런처 애플리케이션)에 의해 생성될 수 있는 예시적인 GUI를 도시한다. 도 16은 제로 상태 기능의 예를 도시한다. 예를 들어, 검색 질의 박스(1600)에 검색 질의를 입력하지 않고, 로컬 서비스 모듈은 " gmail new message" 및 "chrome web store"에 대한 질의 힌트(1602)를 제공했다. 질의 힌트를 선택하면 질의에 대한 검색이 수행될 수 있다. 질의 힌트 외에도, 런처 GUI는 Fake GPS, ExpressVPN , Maps 및 Slack의 4개의 추천 애플리케이션들의 목록을 제공한다. 제안된 애플리케이션 링크들에 대한 선택은 사용자 디바이스(100)에서 애플리케이션을 런칭할 수 있다.

도 17은 추가적인 예시적인 로컬 서비스 모듈 기능을 도시한다. 도 17에서, 사용자는 검색 질의 박스(1700)에 부분 질의 "ma"를 입력하였다. 부분 질의에 응답하여, 로컬 서비스 모듈은 gmail, 지도(map), 메시지(message), 및 mahavitaran 을 포함하는 자동제안 질의(1702)를 제공했다. 또한 로컬 서비스 모듈은 지도 애플리케이션을 여는 바로가기를 제공했다. 도 17에서, 4개의 예시적인 바로가기(1704)가 도시되어 있다. "지도(map)" 바로가기는 애플리케이션 홈페이지에 대한 지도 애플리케이션을 열 수 있다. 다른 링크들(예컨대, 직장(Work), 집(Home), 또는 집으로 가는 길)을 선택하면, 바로가기 링크에 의해 정의된 특정 애플리케이션 페이지로의 지도 애플리케이션이 오픈될 수 있다. Gmail 애플리케이션으로의 추가적인 예시 바로가기(1706)가 도시되어 있다. Gmail 링크를 선택하면 애플리케이션 홈페이지에 대한 Gmail 애플리케이션을 열 수 있다. 새 메시지(New message) 링크를 선택하면 새 이메일 메시지가 작성을 위해 준비된 상태로 Gmail 애플리케이션이 열릴 수 있다. 도 17의 예시적인 바로가기 링크(1704, 1706)는 개발자에 의해 제공되었을 수 있고 및/또는 사용자 디바이스(100)에서 결정되었을 수 있다(예를 들어, 사용자 행동에 기초하여).

도 18은 예시적인 원격 서비스 시스템(1800) 및 N개의 사용자 디바이스 그룹(1802-1, 1802-2 ,… , 1802-N)(통칭하여 "사용자 디바이스의 그룹(1802)" 이라 함)을 도시한다. 사용자 디바이스의 그룹(1802)은 다른 운영 체제, 다른 셀 캐리어, 다른 OEM 및/또는 다른 당사자/피처들과 관련된 사용자 디바이스를 나타낼 수 있다. 예를 들어, 그룹 1(1802-1)은 제 1 OEM 디바이스(예를 들어, 제 1 제조업체)에 대해 제 1 OS(예를 들어, 안드로이드: Android)를 실행하는 디바이스를 포함할 수 있다. 이 예에서, 그룹 2-N(1802-2 내지 1802-N)은 다른 OEM들(예를 들어, 다른 제조업체)을 위해 제 1 OS(예를 들어, Android)를 실행하는 디바이스를 포함할 수 있다.

초기 구성의 로컬 서비스 모듈(1804)(예를 들어, "초기 로컬 서비스 모듈")은 본 명세서에 설명된 바와 같이 고객 획득 전 또는 후에 상이한 디바이스 그룹(1802)에 제공될 수 있다. 일부 구현예에서, 동일한 기능을 포함하는 동일한 초기 로컬 서비스 모듈들이 상이한 사용자 디바이스들의 그룹들(1802)에 제공될 수 있다. 다른 구현예에서, 상이한 기능을 갖는 상이한 초기 로컬 서비스 모듈들이 사용자 디바이스들의 그룹(1802)에 제공될 수 있다. 일부 경우에, 사용자 디바이스들의 그룹(1802)은 동일한 일반 기능(예: 검색 및 광고)을 제공할 수 있지만, 다른 알고리즘 및/또는 데이터를 사용하여 기능을 제공하는 모듈(예: 검색/광고 모듈)을 포함할 수 있다.

일부 경우, 원격 서비스 시스템(1800)은 사용자 디바이스들의 그룹들에 동일한 업데이트들을 제공할 수 있으므로, 서로 다른 디바이스 그룹들은 시간이 지남에 따라 동일한 기능으로 로컬 서비스 모듈을 실행할 수 있다. 일부 경우에, 원격 서비스 시스템(1800)은 상이한 디바이스 그룹에 상이한 업데이트를 제공할 수 있다. 이러한 경우 그룹이 동일한 초기 로컬 서비스 모듈로 시작된 경우에도 상이한 디바이스 그룹에서 제공하는 기능이 다를 수 있다. 경우에 따라 업데이트에는 동일한 일반 기능(예: 검색 및 광고)에 대한 업데이트가 포함될 수 있지만 다른 알고리즘 및/또는 데이터를 제공한다.

일부 구현예에서, 원격 서비스 시스템(1800)은 디바이스들 및/또는 기능들의 상이한 그룹들에 대해 격리된 데이터를 유지할 수 있다(예를 들어, 그룹 1-N 데이터(1806-1, 1806-2,..., 1806 - N)). 일부 구현예에서, 원격 서비스 시스템(1800)은 디바이스 그룹들 및 기능들에 걸쳐 데이터를 공유할 수 있다(예를 들어, 공유 데이터(1808)). 예를 들어, 서로 다른 그룹의 복수의 디바이스로부터 원격 서비스 시스템(1800)에서 획득한 검색 데이터는 공유되어 서로 다른 그룹들의 검색 기능을 업데이트하는데 사용될 수 있다. 상이한 디바이스 그룹들 간에 데이터를 공유하면 서로 다른 각 그룹의 디바이스에 도움이 될 수 있다. 예를 들어, 디바이스 그룹들에서 공유된 검색 데이터(또는 기타 데이터)는 개별 그룹들 각각에 대한 검색 기능(예: 검색 관련성)을 향상시킬 수 있는바, 공유 데이터가 집계 사용자 검색 행동 및 예측들(예컨대, 상이한 질의들에 대한 예상 결과들)에 대한 추가적인 인사이트를 제공할 수 있기 때문이다. 특정 예에서, 공유 검색 데이터는 디바이스 그룹들에서 사용되는 검색 알고리즘을 개선하는데 도움이 될 수 있다. 다른 공유 데이터도 로컬 서비스 모듈의 다른 기능을 개선하는데 도움이 될 수 있다. 예를 들어, 공유 광고 데이터(예: 광고 성과 데이터)는 광고 기능을 위한 광고 선택 알고리즘을 개선하는데 도움이 될 수 있다.

여기에 설명된 데이터 구조(예를 들어, 검색 레코드 및 광고 레코드) 및 데이터 저장소는 단지 예시적인 데이터 구조 및 데이터 저장소일 뿐이다. 이와 같이, 여기에 설명된 디바이스 및 시스템은 추가/대체 데이터 구조 및 데이터 저장소를 사용하여 본 발명의 기술을 구현할 수 있다.

시스템 및 디바이스에 포함된 모듈 및 데이터 저장소는 본 발명의 시스템 및 디바이스에 포함될 수 있는 기능을 나타낸다. 여기에 설명된 모듈 및 데이터 저장소는 전자 하드웨어, 소프트웨어, 펌웨어 또는 이들의 조합으로 구현될 수 있다. 서로 다른 기능을 별도의 모듈 및 데이터 저장소로 묘사한다고 해서 이들 모듈 및 데이터 저장소가 공통 또는 별도의 전자 하드웨어 또는 소프트웨어 컴포넌트로 구현되는지를 반드시 의미하지는 않는다. 일부 구현예에서, 여기에 묘사된 하나 이상의 모듈 및 데이터 저장소와 관련된 피처들은 공통 전자 하드웨어 및 소프트웨어 컴포넌트에 의해 실현될 수 있다. 일부 구현예에서, 여기에 묘사된 하나 이상의 모듈 및 데이터 저장소와 관련된 기능은 별도의 전자 하드웨어 및 소프트웨어 컴포넌트에 의해 실현될 수 있다.

모듈 및 데이터 저장소는 하나 이상의 프로세싱 유닛, 하나 이상의 메모리 컴포넌트, 하나 이상의 입력/출력(I/O) 컴포넌트, 상호연결 컴포넌트를 포함하지만 이에 제한되지 않는 전자 하드웨어 및 소프트웨어 컴포넌트에 의해 구현될 수 있다. 상호연결 컴포넌트는 하나 이상의 프로세싱 유닛, 하나 이상의 메모리 컴포넌트 및 하나 이상의 I/O 컴포넌트 간의 통신을 제공하도록 구성될 수 있다. 예를 들어, 상호연결 컴포넌트는 전자 컴포넌트들 사이에서 데이터를 전송하도록 구성된 하나 이상의 버스를 포함할 수 있다. 상호연결 컴포넌트는 또한 전자 컴포넌트 간의 통신을 제어하도록 구성된 제어 회로(예를 들어, 메모리 컨트롤러 및/또는 I/O 컨트롤러)를 포함할 수 있다.

하나 이상의 프로세싱 유닛들은 하나 이상의 중앙 처리 유닛(CPU), 그래픽 프로세시 유닛(GPU), 디지털 신호 처리 디바이스(DSP) 또는 기타 프로세싱 유닛을 포함할 수 있다. 하나 이상의 프로세싱 유닛은 메모리 컴포넌트 및 I/O 컴포넌트와 통신하도록 구성될 수 있다. 예를 들어, 하나 이상의 프로세싱 유닛은 상호연결 컴포넌트를 통해 메모리 컴포넌트 및 I/O 컴포넌트와 통신하도록 구성될 수 있다.

메모리 컴포넌트(예를 들어, 메인 메모리 및/또는 저장 디바이스)는 임의의 휘발성 또는 비휘발성 매체를 포함할 수 있다. 예를 들어, 메모리는 가령, RAM(Random Access Memory), ROM(Read-Only Memory), NVRAM(Non-Volatile RAM), EEPROM(electrically-erasable programmable ROM), 플래시 메모리, 하드 디스크 드라이브(HDD), 자기 테이프 드라이브, 광학 저장 기술(예: 컴팩트 디스크, 디지털 다목적 디스크 및/또는 블루레이 디스크) 또는 기타 메모리 컴포넌트와 같은 전기 매체, 자기 매체, 및/또는 광학 매체를 포함할 수 있지만 이에 제한되지 않는다.

메모리 컴포넌트는 본 명세서에 기술된 데이터를 포함(예를 들어, 저장)할 수 있다. 예를 들어, 메모리 컴포넌트는 데이터 저장소에 포함된 데이터를 포함할 수 있다. 메모리 컴포넌트는 하나 이상의 프로세싱 유닛에 의해 실행될 수 있는 명령들을 포함할 수도 있다. 예를 들어, 메모리는 하나 이상의 프로세싱 유닛에 의해 실행될 때 하나 이상의 프로세싱 유닛으로 하여금 여기에 설명된 모듈 및 데이터 저장소에 기인하는 다양한 기능을 수행하게 하는 컴퓨터 판독가능 명령들을 포함할 수 있다.

I/O 컴포넌트는 다양한 서로 다른 디바이스들과의 통신을 제공하는 전자 하드웨어 및 소프트웨어를 의미할 수 있다. 예를 들어, I/O 컴포넌트는 다른 디바이스들과 하나 이상의 프로세싱 유닛 및 메모리 컴포넌트 간의 통신을 제공할 수 있다. 일부 예에서, I/O 컴포넌트는 컴퓨터 네트워크와 통신하도록 구성될 수 있다. 예를 들어, I/O 컴포넌트는 다양한 물리적 연결, 무선 연결 및 프로토콜을 사용하여 컴퓨터 네트워크를 통해 데이터를 교환하도록 구성될 수 있다. I/O 컴포넌트는 네트워크 인터페이스 컴포넌트(예: 네트워크 인터페이스 컨트롤러), 리피터, 네트워크 브리지, 네트워크 스위치, 라우터 및 방화벽을 포함할 수 있지만 이에 제한되지 않는다. 일부 예에서, I/O 컴포넌트는 디스플레이 스크린, 키보드, 포인터 디바이스(예: 마우스), 터치스크린, 스피커, 그리고 마이크 등을 포함하지만 이에 한정되지 않는 다양한 휴먼 인터페이스 디바이스와 통신하도록 구성된 하드웨어 및 소프트웨어를 포함할 수 있다. 일부 예에서, I/O 컴포넌트는 외부 메모리(예: 외부 HDD)와 같은 추가 디바이스와 통신하도록 구성된 하드웨어 및 소프트웨어를 포함할 수 있다.

일부 구현예에서, 시스템은 여기에 설명된 기술을 구현하도록 구성된 하나 이상의 컴퓨팅 디바이스를 포함할 수 있다. 달리 말하면, 본 명세서에 기술된 모듈 및 데이터 저장소에 기인한 피처들은 하나 이상의 컴퓨팅 디바이스에 의해 구현될 수 있다. 하나 이상의 컴퓨팅 디바이스 각각은 전술한 전자 하드웨어, 소프트웨어 및/또는 펌웨어의 임의의 조합을 포함할 수 있다. 예를 들어, 하나 이상의 컴퓨팅 디바이스 각각은 전술한 프로세싱 유닛, 메모리 컴포넌트, I/O 컴포넌트 및 상호연결 컴포넌트의 임의의 조합을 포함할 수 있다. 시스템의 하나 이상의 컴퓨팅 디바이스는 또한 디스플레이 스크린, 키보드, 포인터 디바이스(예: 마우스), 터치스크린, 스피커, 그리고 마이크 등을 포함하지만 이에 한정되지 않는 다양한 휴먼 인터페이스 디바이스를 포함할 수 있다. 컴퓨팅 디바이스는 또한 외부 메모리(예: 외부 HDD)와 같은 추가 디바이스와 통신하도록 구성될 수 있다.

시스템의 하나 이상의 컴퓨팅 디바이스는 네트워크(120)와 통신하도록 구성될 수 있다. 시스템의 하나 이상의 컴퓨팅 디바이스는 또한(예를 들어, 컴퓨터 네트워크를 통해) 서로 통신하도록 구성될 수 있다. 일부 예에서, 시스템의 하나 이상의 컴퓨팅 디바이스는 사용자 디바이스와 통신하도록 구성된 하나 이상의 서버 컴퓨팅 디바이스를 포함할 수 있다. 하나 이상의 컴퓨팅 디바이스는 일부 예에서 단일 지리적 위치의 단일 머신 내에 상주할 수 있다. 다른 예에서, 하나 이상의 컴퓨팅 디바이스는 단일 지리적 위치에 있는 여러 머신 내에 상주할 수 있다. 또 다른 예에서, 시스템의 하나 이상의 컴퓨팅 디바이스는 다수의 지리적 위치에 걸쳐 분산될 수 있다.

Claims (30)

1. 사용자 디바이스로서,
   메모리; 및
   프로세싱 유닛을 포함하며,
   상기 메모리는,
   초기 검색 레코드들 및 초기 검색 기능을 포함하는 로컬 서비스 모듈 애플리케이션을 저장하고, 각각의 초기 검색 레코드는 애플리케이션 페이지를 여는 애플리케이션 링크를 포함하고, 각각의 초기 검색 레코드는 초기 검색 레코드와 연관된 애플리케이션 페이지를 설명하는 검색 데이터를 포함하며, 상기 초기 검색 기능은 초기 검색 레코드들 중에서 선택하도록 구성되며; 그리고
   상기 프로세싱 유닛은 로컬 서비스 모듈 애플리케이션을 실행하도록 구성되며, 로컬 서비스 모듈 애플리케이션의 실행은 상기 프로세싱 유닛으로 하여금:
   원격 시스템으로부터 검색 업데이트 데이터를 요청하게 하고,
   원격 시스템으로부터 검색 업데이트 데이터를 수신하게 하고, 상기 검색 업데이트 데이터는 업데이트된 검색 레코드 및 업데이트된 검색 레코드를 선택하기 위한 업데이트된 검색 기능을 포함하며;
   업데이트된 검색 레코드들 및 업데이트된 검색 기능으로 상기 초기 검색 레코드들 및 초기 검색 기능을 각각 업데이트하게 하고;
   사용자 디바이스에 설치된 요청 애플리케이션으로부터 검색 질의를 수신하게 하고;
   업데이트된 검색 기능에 따라 검색 질의에 기초하여 업데이트된 검색 레코드들의 세트를 선택하게 하고; 및
   검색 응답을 요청 애플리케이션에 제공하게 하며,
   상기 검색 응답은 업데이트된 검색 레코드들의 선택된 세트로부터의 애플리케이션 링크를 포함하는 것을 특징으로 하는 사용자 디바이스.
2. 제 1항에 있어서,
   상기 초기 검색 기능 및 업데이트된 검색 기능은 각각 초기 스코어링 기능 및 업데이트된 스코어링 기능을 포함하고, 업데이트된 스코어링 기능은 초기 스코어링 기능과 다르며, 상기 초기 스코어링 기능과 업데이트된 스코어링 기능은 초기 검색 레코드 및 업데이트된 검색 레코드에 대한 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 사용자 디바이스.
3. 제2항에 있어서,
   업데이트된 스코어링 기능은 업데이트된 검색 레코드의 검색 질의와 검색 데이터 간의 매칭에 기초하여 업데이트된 검색 레코드에 대한 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 사용자 디바이스.
4. 제2항에 있어서,
   업데이트된 스코어링 기능은 사용자 디바이스에 설치된 애플리케이션들에 기초하여 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 사용자 디바이스.
5. 제4항에 있어서,
   업데이트된 스코어링 기능은 사용자 디바이스에 설치된 애플리케이션과 관련된 사용량을 나타내는 애플리케이션 사용 데이터에 기초하여 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 사용자 디바이스.
6. 제2항에 있어서,
   상기 업데이트된 스코어링 기능은 업데이트된 검색 레코드에 포함된 스코어링 특징에 기초하여 상기 업데이트된 검색 레코드에 대한 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 사용자 디바이스.
7. 제 1항에 있어서,
   상기 로컬 서비스 모듈 애플리케이션의 실행은 상기 프로세싱 유닛으로 하여금:
   업데이트된 검색 기능이 제대로 작동하지 않는지를 결정하게 하고; 및
   업데이트된 검색 기능이 제대로 작동하지 않는다는 결정에 응답하여, 초기 스코어링 기능을 사용하도록 되돌리게 하는 것을 특징으로 하는 사용자 디바이스.
8. 제7항에 있어서,
   상기 로컬 서비스 모듈 애플리케이션의 실행은 상기 프로세싱 유닛으로 하여금 예외의 검출에 응답하여 상기 업데이트된 검색 기능이 제대로 작동하지 않는다고 결정하게 하는 것을 특징으로 하는 사용자 디바이스.
9. 제7항에 있어서,
   상기 로컬 서비스 모듈 애플리케이션의 실행은 상기 프로세싱 유닛으로 하여금 상기 업데이트된 검색 레코드들의 세트에 대한 선택 동안에 경과된 시간량에 기초하여 상기 업데이트된 검색 기능이 제대로 작동하지 않는다고 결정하게 하는 것을 특징으로 하는 사용자 디바이스.
10. 제 1항에 있어서,
    상기 메모리는 초기 광고 레코드들을 저장하도록 구성되고, 각각의 초기 광고 레코드는 초기 광고 콘텐츠 및 초기 광고 콘텐츠를 선택할 때를 나타내는 초기 타겟팅 파라미터를 포함하고, 상기 로컬 서비스 모듈 애플리케이션의 실행은 상기 프로세싱 유닛으로 하여금:
    원격 시스템으로부터 광고 업데이트 데이터를 요청하게 하고; 및
    원격 시스템으로부터 광고 업데이트 데이터를 수신하게 하며,
    상기 광고 업데이트 데이터는 업데이트된 광고 레코드들을 포함하되, 업데이트된 광고 레코드들 각각은 업데이트된 광고 콘텐츠 및 업데이트된 타겟팅 파라미터를 포함하는 것을 특징으로 하는 사용자 디바이스.
11. 제 10항에 있어서,
    상기 로컬 서비스 모듈 애플리케이션의 실행은 상기 프로세싱 유닛으로 하여금:
    선택된 업데이트된 광고 레코드와 관련된 업데이트된 타겟팅 파라미터의 만족에 기초하여 업데이트된 광고 레코드를 선택하게 하고; 및
    선택한 업데이트된 광고 레코드에서 업데이트된 광고 콘텐츠를 요청 애플리케이션에 제공하게 하는 것을 특징으로 하는 사용자 디바이스.
12. 제 11항에 있어서,
    업데이트된 타겟팅 파라미터는 사용자 디바이스에 설치된 하나 이상의 애플리케이션들의 목록을 포함하는 것을 특징으로 하는 사용자 디바이스.
13. 제 11항에 있어서,
    업데이트된 타겟팅 파라미터는 검색 질의와 관련된 타겟팅 파라미터를 포함하는 것을 특징으로 하는 사용자 디바이스.
14. 제 11항에 있어서,
    업데이트된 타겟팅 파라미터는 검색 응답과 관련된 타겟팅 파라미터를 포함하는 것을 특징으로 하는 사용자 디바이스.
15. 제 10항에 있어서,
    상기 로컬 서비스 모듈 애플리케이션의 실행은 상기 프로세싱 유닛으로 하여금 상기 사용자 디바이스에 설치된 추가 애플리케이션에 광고 콘텐츠를 제공하게 하는 것을 특징으로 하는 사용자 디바이스.
16. 컴퓨터 실행가능 명령들을 포함하는 비일시적 컴퓨터 판독가능 매체로서, 상기 컴퓨터 실행가능 명령들은 사용자 디바이스의 프로세싱 유닛으로 하여금:
    초기 검색 레코드들 및 초기 검색 기능을 저장하게 하고, 각각의 초기 검색 레코드는 애플리케이션 페이지를 여는 애플리케이션 링크를 포함하고, 각각의 초기 검색 레코드는 초기 검색 레코드와 연관된 애플리케이션 페이지를 설명하는 검색 데이터를 포함하며, 상기 초기 검색 기능은 초기 검색 레코드들 중에서 선택하도록 구성되며;
    원격 시스템으로부터 검색 업데이트 데이터를 요청하게 하고,
    원격 시스템으로부터 검색 업데이트 데이터를 수신하게 하고, 상기 검색 업데이트 데이터는 업데이트된 검색 레코드 및 업데이트된 검색 레코드를 선택하기 위한 업데이트된 검색 기능을 포함하며;
    업데이트된 검색 레코드들 및 업데이트된 검색 기능으로 상기 초기 검색 레코드들 및 초기 검색 기능을 각각 업데이트하게 하고;
    사용자 디바이스에 설치된 요청 애플리케이션으로부터 검색 질의를 수신하게 하고;
    업데이트된 검색 기능에 따라 검색 질의에 기초하여 업데이트된 검색 레코드들의 세트를 선택하게 하고; 및
    검색 응답을 요청 애플리케이션에 제공하게 하며,
    상기 검색 응답은 업데이트된 검색 레코드들의 선택된 세트로부터의 애플리케이션 링크를 포함하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
17. 제 16항에 있어서,
    상기 초기 검색 기능 및 업데이트된 검색 기능은 각각 초기 스코어링 기능 및 업데이트된 스코어링 기능을 포함하고, 업데이트된 스코어링 기능은 초기 스코어링 기능과 다르며, 상기 초기 스코어링 기능과 업데이트된 스코어링 기능은 초기 검색 레코드 및 업데이트된 검색 레코드에 대한 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
18. 제 17항에 있어서,
    업데이트된 스코어링 기능은 업데이트된 검색 레코드의 검색 질의와 검색 데이터 간의 매칭에 기초하여 업데이트된 검색 레코드에 대한 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
19. 제 17항에 있어서,
    업데이트된 스코어링 기능은 사용자 디바이스에 설치된 애플리케이션들에 기초하여 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
20. 제 19항에 있어서,
    업데이트된 스코어링 기능은 사용자 디바이스에 설치된 애플리케이션과 관련된 사용량을 나타내는 애플리케이션 사용 데이터에 기초하여 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
21. 제 17항에 있어서,
    상기 업데이트된 스코어링 기능은 업데이트된 검색 레코드에 포함된 스코어링 특징에 기초하여 상기 업데이트된 검색 레코드에 대한 관련성 점수를 생성하도록 구성되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
22. 제 16항에 있어서,
    상기 프로세싱 유닛은,
    업데이트된 검색 기능이 제대로 작동하지 않는지를 결정하고; 및
    업데이트된 검색 기능이 제대로 작동하지 않는다는 결정에 응답하여, 초기 스코어링 기능을 사용하도록 되돌리는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
23. 제22항에 있어서,
    상기 프로세싱 유닛은 예외의 검출에 응답하여 상기 업데이트된 검색 기능이 제대로 작동하지 않는다고 결정하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
24. 제22항에 있어서,
    상기 프로세싱 유닛은 상기 업데이트된 검색 레코드들의 세트에 대한 선택 동안에 경과된 시간량에 기초하여 상기 업데이트된 검색 기능이 제대로 작동하지 않는다고 결정하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
25. 제 16항에 있어서,
    상기 프로세싱 유닛은,
    초기 광고 레코드들을 저장하고, 각각의 초기 광고 레코드는 초기 광고 콘텐츠 및 초기 광고 콘텐츠를 선택할 때를 나타내는 초기 타겟팅 파라미터를 포함하며;
    원격 시스템으로부터 광고 업데이트 데이터를 요청하고; 및
    원격 시스템으로부터 광고 업데이트 데이터를 수신하며,
    상기 광고 업데이트 데이터는 업데이트된 광고 레코드들을 포함하되, 업데이트된 광고 레코드들 각각은 업데이트된 광고 콘텐츠 및 업데이트된 타겟팅 파라미터를 포함하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
26. 제25항에 있어서,
    상기 프로세싱 유닛은,
    선택된 업데이트된 광고 레코드와 관련된 업데이트된 타겟팅 파라미터의 만족에 기초하여 업데이트된 광고 레코드를 선택하고; 및
    선택한 업데이트된 광고 레코드에서 업데이트된 광고 콘텐츠를 요청 애플리케이션에 제공하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
27. 제26항에 있어서,
    상기 업데이트된 타겟팅 파라미터는 사용자 디바이스에 설치된 하나 이상의 애플리케이션들의 목록을 포함하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
28. 제26항에 있어서,
    상기 업데이트된 타겟팅 파라미터는 검색 질의와 관련된 타겟팅 파라미터를 포함하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
29. 제26항에 있어서,
    상기 업데이트된 타겟팅 파라미터는 검색 응답과 관련된 타겟팅 파라미터를 포함하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.
30. 제25항에 있어서,
    상기 프로세싱 유닛은 상기 사용자 디바이스에 설치된 추가 애플리케이션에 광고 콘텐츠를 제공하도록 구성되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 매체.