KR20170141224A - 개발자 교환 시스템 - Google Patents

Abstract

개발자 교환 시스템은 레코드를 저장하는 데이터 저장소를 포함한다. 각 레코드는 기능 모듈 및 기능 모듈에 의해 수행되는 기능을 지정하는 메타 데이터를 포함한다. 기능 온톨로지는 복수의 기능과 상호 관련된다. 기능 관리 모듈은 제1 개발자가 온톨로지로부터 제1 기능을 선택할 수 있게 한다. 통합 모듈은 제1 애플리케이션에 통합하기 위해 제1 개발자에게 프로세서 실행 가능 명령어를 제공한다. 프로세서 실행 가능 명령어는 제1 기능을 식별하는 기능 모듈 요청을 개발자 교환 시스템에 전송하는 단계 및 기능 모듈을 수신 및 실행하는 단계를 포함한다. 기능 모듈은 제1 애플리케이션에서 사용할 디스플레이 데이터를 제공한다. 전달 모듈은 사용자 장치로부터 원하는 기능의 식별자를 지정하는 기능 모듈 요청을 수신한다. 전달 모듈은 데이터 저장소로부터 원하는 기능에 대응하는 기능 모듈을 선택하고 선택된 기능 모듈을 사용자 장치에 전송한다.

Description

개발자 교환 시스템

본 발명은 애플리케이션 개발에 관한 것으로, 특히 모바일 장치용 공동 애플리케이션 개발을 위한 시스템 및 방법에 관한 것이다.

최근 몇 년 동안 스마트폰과 같은 인터넷 연결 장치의 사용이 기하급수적으로 증가했다. 이러한 장치에 이용할 수 있는 소프트웨어 애플리케이션(application; 앱)의 수와 종류는 비슷한 수준으로 증가했다. 현재 많은 다양한 기능이 실행될 수 있으며, 모든 임의의 인터넷 연결 장치 상에서 많은 다양한 데이터 세트가 분석될 수 있다. 이 기능성과 데이터를 제공하는 애플리케이션으로는 비즈니스 중점 애플리케이션, 교육 애플리케이션, 게임, 새로운 애플리케이션, 쇼핑 애플리케이션, 메시징 애플리케이션, 미디어 스트리밍 애플리케이션, 소셜 미디어 애플리케이션 등을 망라한다.

이러한 이용 가능한 애플리케이션이 무수한 경우, 인터넷 연결 장치의 많은 사용자는 기능을 수행하고/하거나 사용자에게 관심 있는 데이터를 제공할 수 있는 애플리케이션의 이용 가능성을 알지 못한다. 일반적으로 애플리케이션을 위한 시장의 한 부문에 중점을 두는 앱 개발자조차도 사용자가 다른 부문에서 유용하다고 생각할 수 있는 모든 애플리케이션을 최신 상태로 유지할 수 없다. 또한, 개발자는 애플리케이션 생태계에 걸쳐 사용할 수 있는 기능성의 영역의 일부도 전문적으로 구현할 수 없다.

본 명세서에서 제공되는 배경 설명은 일반적으로 본 명세서의 맥락을 제시하기 위한 것이다. 출원시 선행 기술의 자격을 갖지 않는 설명의 형태뿐만 아니라, 이 배경 단락에서 설명된 정도까지 본 발명자에 의한 작업은 명시적으로 또는 묵시적으로 본 개시의 선행 기술로서 인정되지 않는다.

개발자 교환 시스템은 레코드(record)를 저장하도록 구성된 데이터 저장소(data store)를 포함하며, 각 레코드는 기능 모듈(function module) 및 기능 모듈을 서술하는 메타 데이터(meta data)를 포함한다. 메타 데이터는 기능 모듈에 의해 수행되는 기능을 지정(specify)한다. 기능 온톨로지(function ontology) 내에 복수의 기능이 배치된다. 개발자 교환 시스템은 기능 온톨로지로부터 제1 기능을 선택하기 위해 제1 애플리케이션 개발자에게 그래픽 사용자 인터페이스를 제공하도록 구성된 기능 관리 모듈을 포함한다. 개발자 교환 시스템은 제1 애플리케이션에 통합(integration)하기 위해 프로세서 실행 가능 명령을 제1 애플리케이션 개발자에게 제공하도록 구성된 통합 모듈을 포함한다. 프로세서 실행 가능 명령어는 (i) 기능 모듈 요청을 개발자 교환 시스템에 전송하는 단계, (ii) 개발자 교환 시스템에 의해 제공되는 기능 모듈을 수신하는 단계, (iii) 제공된 기능 모듈을 실행하는 단계, 및 (iv) 제1 애플리케이션 내 제공된 기능 모듈로부터 디스플레이 데이터를 제공하는 단계를 포함한다. 기능 모듈 요청은 제1 기능을 식별한다. 상기 개발자 교환 시스템은 (i) 사용자 장치로부터 기능 모듈 요청을 수신하고, 상기 기능 모듈 요청은 원하는 기능의 식별자를 지정하고, (ii) 원하는 기능에 대응하는 데이터 저장소로부터 상기 레코드의 고려 세트를 식별하고, (iii) 상기 레코드의 고려 세트 중 하나의 레코드를 선택하고, (iv) 선택된 레코드에 대응하는 기능 모듈을 데이터 저장소로부터 사용자 장치에 선택적으로 전송하도록 구성된 전달 모듈을 포함한다.

다른 특징에서, 개발자 교환 시스템은 (i) 제2 애플리케이션 개발자로부터 기능 모듈을 수신하고 (ii) 제2 애플리케이션 개발자로부터 수신된 기능 모듈을 저장하기 위해 데이터 저장소에 새로운 레코드를 생성하도록 구성된 제작자 모듈을 생성하도록 구성된 제작자 모듈을 포함한다. 다른 특징으로, 제작자 모듈은 제2 애플리케이션 개발자로부터 갱신된 기능 모듈을 수신한 것에 응답하여 데이터 저장소 내의 새로운 레코드를 갱신하도록 구성된다. 다른 특징으로, 제작자 모듈은 제2 애플리케이션 개발자로부터의 메타 데이터를 새로운 레코드에 저장하도록 구성된다. 메타 데이터는 (i) 제2 애플리케이션 개발자로부터 수신된 기능 모듈의 사용자 인터페이스의 프리뷰 및 (ii) 제2 애플리케이션 개발자로부터 수신된 기능 모듈의 텍스트 서술 중 적어도 하나를 포함한다.

다른 특징에서, 상기 프로세서 실행 가능 명령어는 제공된 기능 모듈을 기능 모듈 데이터 저장소에 저장하는 단계를 포함한다. 다른 특징에서, 전달 모듈은 사용자 장치로부터 기능 모듈 요청을 수신한 것에 응답하여 기능 모듈의 식별자를 사용자 장치로 전송하도록 구성된다. 프로세서 실행 가능 명령어는 개발자 교환 시스템으로부터 기능 모듈 식별자를 수신하는 단계와, 수신된 기능 모듈 식별자가 기능 모듈 데이터 저장소에 저장된 기능 모듈 식별자와 일치하지 않는 것에 응답하여 수신된 기능 모듈 식별자에 의해 식별된 기능 모듈을 제공하기 위해 개발자 교환 시스템에 요청을 송신하는 단계를 포함한다.

다른 특징에서, 프로세서 실행 가능 명령어는 제공된 기능 모듈을 샌드박스(sandbox)에서 실행하는 것을 포함한다. 다른 특징들에서, 프로세서 실행 가능 명령어는 제1 애플리케이션의 기동(startup) 시에 기능 모듈 요청을 개발자 교환 시스템에 전송하는 단계를 포함한다. 다른 특징들에서, 프로세서 실행 가능 명령어는 사용자 장치 상의 제1 애플리케이션의 제1 기동 시에만, 기능 모듈 요청을 개발자 교환 시스템에 송신하는 단계를 포함한다. 다른 특징에서, 디스플레이 데이터는 제1 상태 템플릿에 대응하는 제1 애플리케이션의 상태에 제공된다. 프로세서 실행 가능 명령어는, 제1 상태 템플릿으로부터 인스턴스화된 상태에 응답하여, 기능 모듈 요청을 개발자 교환 시스템에 송신하는 단계를 포함한다.

다른 특징에서, 상기 프로세서 실행 가능 명령어는 상기 개발자 교환 시스템에 의해 제공된 상기 제공된 기능 모듈을 저장하는 단계 및 상기 개발자 교환 시스템이 다른 제2 기능 모듈을 제공하게 하는 상기 제1 상태 템플릿에 대한 후속 기능 모듈 요청에 응답하여 상기 제공된 기능 모듈을 저장소로부터 제거(purging)하는 단계를 포함한다. 다른 특징들에서, 프로세서 실행 가능 명령어는 제1 기능의 식별을 포함한다. 다른 기능에서, 기능 모듈 요청은 기능 모듈 요청의 소스를 식별한다. 전달 모듈은 기능 모듈 요청의 소스에 따라 원하는 기능을 인식하도록 구성된다.

다른 특징에서, 상기 통합 모듈은 상기 제1 애플리케이션 개발자에게 상기 제1 기능의 식별 정보(identification)를 제공하도록 구성된다. 프로세서 실행 가능 명령어는 제1 애플리케이션 개발자에 의해 삽입된 애플리케이션 프로그래밍 인터페이스 호출로부터 제1 기능의 식별 정보를 수신하는 단계를 포함한다. 다른 기능에서 통합 모듈은 제1 애플리케이션 개발자에게 소프트웨어 개발 키트를 제공하도록 구성된다. 소프트웨어 개발 키트는 제1 애플리케이션 개발자가 애플리케이션 프로그래밍 인터페이스 호출을 준비하도록 돕는다.

다른 특징들에서, 프로세서 실행 가능 명령어는 사용자 장치 상에 설치된 애플리케이션들을 식별하는 단계 및 식별된 애플리케이션들에 관련된 데이터를 포함함으로써 기능 모듈 요청을 준비하는 단계를 포함한다. 전달 모듈은 식별된 애플리케이션과 관련된 데이터에 따라 레코드의 고려 세트를 제한하도록 구성된다. 다른 특징들에서, 프로세서 실행 가능 명령어는 사용자 장치 상의 활성 계정을 식별하고 활성 계정에 관련된 데이터를 포함함으로써 기능 모듈 요청을 준비하는 단계를 포함한다. 전달 모듈은 (i) 활성 계정과 관련된 데이터에 따라 레코드의 고려 세트의 스코어를 조정하고 (ii) 조정된 스코어에 따라 선택된 레코드를 선택하도록 구성된다.

개발자 교환 시스템을 동작하는 방법은 복수의 기능을 포함하는 기능 온톨로지를 정의하는 단계를 포함한다. 이 방법은 데이터 저장소에 레코드를 저장하는 단계를 포함하며, 각 레코드는 기능 모듈 및 기능 모듈을 서술하는 메타 데이터를 포함한다. 메타 데이터는 기능 온톨로지에서 선택된 기능 모듈에 의해 수행되는 기능을 지정한다. 이 방법은 기능 온톨로지로부터 제1 기능을 선택하기 위해 그래픽 사용자 인터페이스를 생성하고 제1 애플리케이션 개발자에게 제공하는 단계를 포함한다. 이 방법은 제1 기능의 선택에 응답하여 제1 애플리케이션에 통합하기 위해 프로세서 실행 가능 명령을 제1 애플리케이션 개발자에게 전송하는 단계를 포함한다. 프로세서 실행 가능 명령어는 (i) 기능 모듈 요청을 개발자 교환 시스템에 전송하는 단계, (ii) 개발자 교환 시스템에 의해 제공되는 기능 모듈을 수신하는 단계, (iii) 제공된 기능 모듈을 실행하는 단계, 및 (iv) 제1 애플리케이션 내에서 제공된 기능 모듈로부터 디스플레이 데이터를 제공하는 단계를 포함한다.

다른 특징으로, 상기 방법은 제2 애플리케이션 개발자로부터 제1 기능 모듈을 수신하는 단계를 포함한다. 이 방법은 제1 기능 모듈의 수신에 응답하여 제1 기능 모듈을 저장하기 위해 데이터 저장소에 새로운 레코드를 생성하는 단계를 포함한다. 다른 특징에서, 상기 방법은 상기 제2 애플리케이션 개발자로부터 상기 제1 기능 모듈의 갱신 버전을 수신하는 단계를 포함한다. 이 방법은 제1 기능 모듈의 갱신 버전의 수신에 응답하여 데이터 저장소에서 새로운 레코드를 갱신하는 단계를 포함한다.

다른 특징으로, 새로운 레코드는 제2 애플리케이션 개발자로부터의 메타 데이터를 저장한다. 메타 데이터는 (i) 제2 애플리케이션 개발자로부터 수신된 기능 모듈의 사용자 인터페이스의 프리뷰 및 (ii) 제2 애플리케이션 개발자로부터 수신된 기능 모듈의 텍스트 서술 중 적어도 하나를 포함한다. 다른 특징에서, 상기 방법은 사용자 장치로부터 기능 모듈 요청을 수신하는 단계를 포함하고, 이 기능 모듈 요청은 원하는 기능의 식별자를 지정한다. 이 방법은 원하는 기능에 대응하는 데이터 저장소로부터의 레코드의 고려 세트를 식별하는 단계를 포함한다. 상기 방법은 상기 레코드의 고려 세트 중 하나의 레코드를 선택하는 단계를 포함한다. 이 방법은 데이터 저장소로부터 선택된 레코드에 대응하는 기능 모듈을 선택적으로 검색하는 단계 및 검색된 기능 모듈을 사용자 장치에 전송하는 단계를 포함한다.

다른 특징에서, 상기 프로세서 실행 가능 명령어는 제공된 기능 모듈을 기능 모듈 데이터 저장소에 저장하는 단계를 포함한다. 다른 특징으로, 상기 방법은 사용자 장치로부터 기능 모듈 요청의 수신에 응답하여, 기능 모듈의 식별자를 사용자 장치로 전송하는 단계를 포함한다. 프로세서 실행 가능 명령어는 개발자 교환 시스템으로부터 기능 모듈 식별자를 수신하는 단계와, 수신된 기능 모듈 식별자가 기능 모듈 데이터 저장소에 저장된 기능 모듈 식별자와 일치하지 않는 것에만 응답하여, 수신된 기능 모듈 식별자에 의해 식별된 기능 모듈의 제공을 위한 요청을 개발자 교환 시스템에 송신하는 단계를 포함한다.

다른 특징에서, 상기 방법은 상기 기능 모듈 요청이 발생된 애플리케이션의 식별자에 기초하여 원하는 기능을 인식하는 단계를 포함한다. 다른 특징에서, 프로세서 실행 가능 명령은 제공된 기능 모듈을 샌드박스에서 실행하는 것을 포함한다. 다른 특징에서, 프로세서 실행 가능 명령어는 제1 애플리케이션의 기동 시에 기능 모듈 요청을 개발자 교환 시스템에 송신하는 단계를 포함한다. 다른 특징에서, 프로세서 실행 가능 명령어는 사용자 장치 상의 제1 애플리케이션의 제1 기동 시에만, 기능 모듈 요청을 개발자 교환 시스템에 송신하는 단계를 포함한다.

다른 특징에서, 상기 프로세서 실행 가능 명령어는 제1 상태 템플릿으로부터 인스턴스화된 상태에 응답하여, 상기 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계를 포함한다. 디스플레이 데이터는 제1 상태 템플릿에 대응하는 제1 애플리케이션의 상태에 제공된다. 다른 특징에서, 프로세서 실행 가능 명령어는 개발자 교환 시스템에 의해 제공된 기능 모듈을 저장하는 단계를 포함한다. 명령어는 개발자 교환 시스템이 다른 제2 기능 모듈을 제공하게 하는 제1 상태 템플릿에 대한 후속 기능 모듈 요청에 응답하여, 제공된 기능 모듈을 저장 장치로부터 제거하는 단계를 포함한다.

다른 특징에서, 프로세서 실행 가능 명령어는 제1 기능의 식별 정보를 포함한다. 다른 특징에서, 이 방법은 제1 애플리케이션 개발자에게 제1 기능의 식별 정보를 제공하는 단계를 포함한다. 프로세서 실행 가능 명령어는 제1 애플리케이션 개발자에 의해 제1 애플리케이션에 삽입된 애플리케이션 프로그래밍 인터페이스 호출로부터 제1 기능의 식별 정보를 수신하는 단계를 포함한다.

다른 특징으로, 상기 방법은 제1 애플리케이션 개발자에게 소프트웨어 개발 키트를 제공하는 단계를 포함한다. 소프트웨어 개발 키트는 제1 애플리케이션 개발자에게 애플리케이션 프로그래밍 인터페이스 호출을 작성하기 위한 템플릿을 제공한다. 템플릿에는 제1 기능의 식별 정보가 채워진다. 다른 특징에서, 프로세서 실행 가능 명령어는 제1 애플리케이션이 실행중인 사용자 장치 상에 설치된 애플리케이션을 식별하는 단계를 포함한다. 명령어는 사용자 장치의 활성 계정을 식별하는 단계를 포함된다. 명령어는 활성 계정과 관련된 데이터 및 식별된 애플리케이션과 관련된 데이터를 포함함으로써 기능 모듈 요청을 준비하는 단계를 포함한다.

제1 애플리케이션을 개발하는 방법은 개발자 교환 시스템의 그래픽 사용자 인터페이스에 액세스(access)하는 단계를 포함한다. 이 방법은 개발자 교환 시스템의 그래픽 사용자 인터페이스를 사용하여, 기능 온톨로지 내의 복수의 기능들로부터 제1 기능을 선택하는 단계를 포함한다. 상기 방법은 상기 제1 애플리케이션에의 통합을 위해 상기 개발자 교환 시스템으로부터 프로세서 실행 가능 명령을 수신하는 단계를 포함한다. 프로세서 실행 가능 명령어는 (i) 기능 모듈 요청을 개발자 교환 시스템에 송신하는 단계, (ii) 개발자 교환 시스템에 의해 제공되는 기능 모듈을 수신하는 단계, (iii) 제공된 기능 모듈을 실행하는 단계, 및 (iv) 제1 애플리케이션에서 제공된 기능 모듈로부터 디스플레이 데이터를 제공하는 단계를 포함한다. 기능 모듈 요청은 제1 기능을 식별한다. 이 방법은 사용자에게 디스플레이 데이터를 디스플레이하는 영역을 지정하는 단계를 포함하여, 프로세서 실행 가능 명령을 제1 애플리케이션에 통합하는 단계를 포함한다.

다른 특징에서, 상기 프로세서 실행 가능 명령어는 수신된 기능 모듈을 기능 모듈 데이터 저장소에 저장하는 단계를 포함한다. 다른 특징에서, 프로세서 실행 가능 명령어는 기능 모듈 요청에 응답하여 개발자 교환 시스템으로부터 기능 모듈 식별자를 수신하는 단계를 포함한다. 명령어는 수신된 기능 모듈 식별자가 기능 모듈 데이터 저장소에 저장된 기능 모듈 식별자와 일치하지 않는 것에만 응답하여, 수신된 기능 모듈 식별자에 의해 식별된 기능 모듈의 제공을 위한 요청을 개발자 교환 시스템에 전송하는 것을 포함한다.

다른 특징에서, 상기 프로세서 실행 가능 명령어는 상기 제공된 기능 모듈을 샌드박스에서 실행하는 단계를 포함한다. 다른 특징에서, 프로세서 실행 가능 명령어는 제1 애플리케이션의 기동 시에 기능 모듈 요청을 개발자 교환 시스템에 전송하는 단계를 포함한다. 다른 특징에서, 프로세서 실행 가능 명령어는, 사용자 장치 상의 제1 애플리케이션의 제1 기동 시에만, 기능 모듈 요청을 개발자 교환 시스템에 송신하는 단계를 포함한다. 다른 특징에서, 상기 방법은 상기 기능 모듈로부터 상기 디스플레이 데이터의 디스플레이를 위해 상기 제1 상태 템플릿 내의 영역을 확보하는 단계를 포함하여, 상기 디스플레이 데이터를 제1 상태 템플릿에 통합하는 단계를 포함한다. 이 방법은 제1 상태 템플릿으로부터의 상태의 인스턴스화에 응답하여, 기능 모듈이 호출되고(invoked) 기능 모듈에 의해 생성된 디스플레이 데이터가 상기 확보된 영역에 디스플레이된다.

다른 특징에서, 프로세서 실행 가능 명령어는 제1 상태 템플릿으로부터의 상태의 인스턴스화에 응답하여, 기능 모듈 요청을 개발자 교환 시스템에 송신하는 것을 포함한다. 다른 특징들에서, 프로세서 실행 가능 명령어는 개발자 교환 시스템에 의해 제공된 기능 모듈을 저장하는 단계를 포함한다. 명령어는 상태가 제1 상태 템플릿에서 인스턴스화될 때마다 개발자 교환 시스템에 기능 모듈 요청을 송신하는 단계를 포함한다. 명령어는 개발자 교환 시스템이 다른 제2 기능 모듈을 제공하게 하는 제1 상태 템플릿에 대한 후속 기능 모듈 요청에 응답하여, 제공된 기능 모듈을 저장 장치로부터 제거하는 단계를 포함한다.

다른 특징에서, 상기 방법은 상기 개발자 교환 시스템으로부터 제1 기능의 식별 정보를 수신하는 단계를 포함한다. 이 방법은 제1 상태 템플릿과 연관된 코드 내에서 애플리케이션 프로그래밍 인터페이스 호출을 생성하는 단계를 포함한다. 응용 프로그래밍 인터페이스 호출은 제1 기능의 식별 정보를 포함한다. 다른 특징으로, 이 방법은 개발자 교환 시스템으로부터 소프트웨어 개발 키트를 수신하는 단계를 포함한다. 소프트웨어 개발 키트는 애플리케이션 프로그래밍 인터페이스 호출을 작성하기 위한 템플릿을 제공한다. 애플리케이션 프로그래밍 인터페이스 호출을 생성하는 것은 템플릿에 제1 기능의 식별 정보를 채우는 단계를 포함한다.

다른 특징에서, 프로세서 실행 가능 명령어는 사용자 장치 상에 설치된 애플리케이션을 식별하고, 사용자 장치 상의 활성 계정을 식별하고, 활성 계정에 관련된 데이터 및 식별된 애플리케이션에 관련된 데이터를 포함함으로써 기능 모듈 요청을 준비하는 단계를 포함한다. 다른 특징에서, 상기 방법은 상기 제1 애플리케이션의 적절한 서브세트(subset)의 기능성을 갖는 제1 기능 모듈을 생성하는 단계를 포함한다. 이 방법은 제1 기능 모듈을 개발자 교환 시스템에 제공하는 단계를 포함한다.

다른 특징에서, 본 방법은 적절한 서브세트의 기능성과 관련된 제1 애플리케이션의 코드를 갱신한 것에 응답하여, 제1 기능 모듈의 갱신 버전을 개발자 교환 시스템에 포함한다. 다른 특징에서, 본 방법은 제1 기능 모듈에 관한 메타 데이터를 개발자 교환 시스템에 제공하는 단계를 포함한다. 메타 데이터는 (i) 제1 기능 모듈의 사용자 인터페이스의 프리뷰 및 (ii) 제1 기능 모듈의 텍스트 서술 중 적어도 하나를 포함한다.

비일시적 컴퓨터 판독 가능 매체는 프로세서 실행 가능 명령어를 저장한다. 명령어는 네트워크 연결을 통해 기능 모듈 요청을 개발자 교환 시스템으로 전송하는 단계를 포함한다. 기능 모듈 요청은 수행될 특정 기능을 식별한다. 명령어는 개발자 교환 시스템으로부터 제1 기능 모듈을 수신하는 단계를 포함한다. 제1 기능 모듈은 수행될 특정 기능과 관련된 디스플레이 데이터를 생성하도록 구성된 코드를 포함한다. 명령은 기능 모듈 데이터 저장소에 제1 기능 모듈을 저장하는 단계를 포함한다. 명령어는 트리거링 이벤트(triggering event)에 응답하여 기능 모듈 데이터 저장소로부터 제1 기능 모듈을 검색하고 제1 기능 모듈을 실행하는 단계를 포함한다. 명령어는 제1 기능 모듈의 실행에 의해 생성된 디스플레이 데이터를 제공하는 단계를 포함한다.

다른 특징으로, 제1 기능 모듈은 샌드박스에서 실행된다. 다른 특징에서, 디스플레이 데이터는 명령어가 포함되는 애플리케이션의 제1 상태 내에 디스플레이된다. 트리거링 이벤트에는 애플리케이션의 사용자가 액세스하는 애플리케이션의 제1 상태가 포함된다. 다른 특징에서, 디스플레이 데이터는 상태가 인스턴스화되는 제1 애플리케이션의 제1 상태 템플릿에 포함(incorporated)된다. 트리거 이벤트는 제1 상태 템플릿으로부터 인스턴스화된 상태를 기반으로 한다.

다른 특징에서, 기능 모듈 요청은 제1 상태 템플릿으로부터 인스턴스화된 상태에 응답하여 전송된다. 명령어는 제1 상태 템플릿으로부터 인스턴스화된 상태의 다른 인스턴스에 응답하여 제2 기능 모듈 요청을 개발자 교환 시스템에 전송하는 단계를 포함한다. 명령어는 제2 기능 모듈 요청에 따라 개발자 교환 시스템으로부터 다른 제2 기능 모듈을 수신한 것에 응답하여, 기능 모듈 데이터 저장소로부터 제1 기능 모듈을 삭제하는 단계를 포함한다.

다른 특징에서, 명령어는 기능 모듈 요청에 응답하여 개발자 교환 시스템으로부터 기능 모듈 식별자를 수신하는 단계를 포함한다. 명령어는 수신된 기능 모듈 식별자가 기능 모듈 데이터 저장소에 저장된 기능 모듈 식별자와 일치하지 않는 것에만 응답하여, 제1 기능 모듈의 제공을 위한 요청을 개발자 교환 시스템에 전송하는 단계를 포함한다.

다른 특징에서, 명령어는 명령어가 저장된 장치 상에 설치된 애플리케이션을 식별하고, 장치 상의 활성 계정을 식별하며, 활성 계정과 관련된 데이터 및 식별된 데이터와 관련된 데이터를 포함함으로써 기능 모듈 요청을 준비하는 단계를 포함한다. 컴퓨팅 장치(computing device)는 비일시적 컴퓨터 판독 가능 매체 및 상기 비일시적인 컴퓨터 판독 가능 매체로부터의 명령을 실행하는 프로세싱 하드웨어를 포함한다. 다른 특징으로, 컴퓨팅 장치는 스마트폰이다.

본 발명의 적용 범위는 상세한 설명, 청구 범위 및 도면으로부터 명백해질 것이다. 상세한 설명 및 특정 예는 설명의 목적을 위한 것이며 본 발명의 범위를 제한하고자 하는 것은 아니다.

본 발명은 상세한 설명 및 첨부 도면으로부터 더욱 완전하게 이해될 것이다.
도 1은 본 개시의 원리에 따라 기능적 블록도와 그래픽 사용자 인터페이스 예시도의 결합도이다.
도 2는 예시적인 기능 온톨로지의 그래픽 표현도이다.
도 3은 본 개시의 원리가 모바일 애플리케이션 생태계에서 사용되는 방법을 나타내는 하이 레벨 기능 블록도이다.
도 4는 예시적인 개발자 포털의 단순화된 그래픽 사용자 인터페이스이다.
도 5는 기능 교환 시스템에 송신된 예시적인 기능 요청의 예시의 컨텐츠를 도시한다.
도 6a 내지 도 6c는 기능 요청에 응답하여 돌아온 응답의 예시적인 콘텐츠를 도시한다.
도 7은 예시적인 개발자 포털의 하이 레벨 기능 블록도이다.
도 8은 예시적인 기능 모듈 레코드 포맷의 그래픽 표현도이다.
도 9는 본 개시의 원리에 따라 개발된 애플리케이션에서의 예시적인 동적 실행 코드의 부분 블록도이다.
도 10은 개발자 포털의 예시적인 동작의 흐름도이다.
도 11은 애플리케이션 내의 동적 실행 코드의 예시의 동작의 흐름도이다.
도 12는 다수의 개발자와 기능 교환 시스템 간의 상호 작용을 나타내는 하이 레벨 도면이다.
도 13은 기능 모듈 레코드에 대한 다른 예시적인 포맷의 그래픽 표현도이다.
도 14는 기능 블록도와 그래픽 사용자 인터페이스 예시도의 결합도이다.
도 15는 예시적인 기능 교환 시스템 개발자 인터페이스의 그래픽 사용자 인터페이스이다.
도 16은 기능 교환 시스템을 위한 다른 개발자 인터페이스의 그래픽 사용자 인터페이스이다.
도 17은 개발자와 기능 교환 시스템 간의 예시적인 상호 작용의 흐름도이다.
도 18은 사용자 장치와 기능 교환 시스템 간의 예시적인 상호 작용의 흐름도이다.
도면에서, 참조 번호는 유사한 및/또는 동일한 요소를 식별하기 위해 재사용될 수 있다.

애플리케이션의 개발자(본 명세서에서 앱과 교대로 언급함)는 일반적으로 제한된 수의 기능에 대해 우수한 사용자 환경을 제공하는 데 중점을 둔다. 예를 들어, 앱 개발자는 정확하고 직관적으로 표시되는 영화 상영 시간을 제공하는 데 주력할 수 있지만, 영화관에 대한 지도 또는 내비게이션 방향과 같은 기타 관련 기능을 제공하는 데에는 투자하지 않는다. 앱이 제공하는 기능은 앱이 수행할 수 있는 작업으로 또한 설명될 수도 있다는 것에 유의해야 한다.

앱 개발자는 일반적으로 자신의 앱 내에 사용자를 유지하여 앱 참여를 늘리고 가장 원활한 사용자 환경을 제공하고 싶어한다. 그러나 다른 앱에서 어떤 기능을 복제한다는 것은 그 다른 기능이 개발자의 핵심 역량이 아닌 경우 사용자에게 양호한 경험을 제공할 수가 없다. 예를 들어, 개발자가 영화 상영 일정을 잘 제시하고 상영 시간과 관련된 귀중한 데이터 및 처리 알고리즘을 보유하고 있는 경우, 이 개발자는 GPS 기반 맵핑 소프트웨어 개발의 전문가가 아닐 가능성이 크다. 결과적으로 개발자는 맵핑 기능을 제공하기 위해 다른 개발자에게 의존해야 한다.

다른 앱의 기능성에 액세스하기 위해 개발자는 코드 작성시 해당 다른 앱에 대한 참조를 하드코딩(hardcode)할 수 있다. 경우에 따라 운영 체제상에서 특정 앱이 이용 가능할 가능성이 크다. 예를 들어, 개발자는 특히 미국 이외의 국가에서 일반적인 규칙에 예외가 있을 수는 있지만, 안드로이드(ANDROID) 운영체제를 실행하는 스마트폰에서 구글 맵(GOOGLE MAPS) 맵핑 소프트웨어를 사용할 수 있다고 합리적으로 기대할 수 있다.

그러나 하나의 앱이 설치되어 있는 경우에도 사용자는 다른 앱을 사용하고 싶어할 수도 있다. 영화 리뷰 앱이나 레스토랑 리뷰 앱과 같은 대부분의 카테고리의 앱에 대해서는, 특정 앱이 존재하리라는 보장이 없다. 따라서 하나 이상의 특정 앱에 대한 액세스를 하드코딩하는 것은 추측의 작업이 된다. 또한, 앱 생태계가 끊임없이 진화됨에 따라 임의의 카테고리에서 가장 인기 있고 가장 널리 설치되고 가장 유용한 앱이라는 것은 달라지고 시간이 지남에 따라 바뀔 수 있다.

특정 기능의 경우엔, 운영 체제에 요청을 보낼 수 있다. 예를 들어 위치를 맵핑하기 위해선 맵핑 요청을 운영 체제로 보낼 수 있다. 운영 체제는 맵핑 요청을 서비스하기 위해 설치된 앱의 리스트를 사용자에게 제공할 수 있다. 운영 체제는 사용자가 하나의 앱을 기본 값으로 선택하도록 허용할 수 있으며, 일단 기본 값이 선택되면 일반 사용자는 그 선택을 다시 방문하지 않아도 된다. 특정 운영체제는 사용자가 특정 구성을 변경하지 않는 한, 특정 요청에 대한 선택을 제공하지 않고 대신에 기본 앱이나 서비스에 요청을 보내게 된다.

앱 개발자가 다른 앱과 통합하여 사용자에게 값진 기능을 제공하고 싶어하지만 능력은 제한적이고 구현하기 어렵다. 개발자가 서로 비즈니스 관계를 맺을 수 있는 체계적인 방법도 없다. 본 개시는 개발자가 제작 개발자로서 기능하며 특정 기능과 관련된 기능 코드를 기능 교환 시스템에 제공할 수 있고, 소비 개발자로서 기능하는 개발자가 그 기능 코드를 그들 자신의 애플리케이션에 통합할 수 있는, 기능 교환 시스템을 설명한다.

이러한 통합은 영화 상영 앱 개발자가 제작 개발자로부터 맵핑용 기능 코드와 통합할 때와 같이, 개발 중에 수행될 수 있다. 다른 구현 예에서는, 상영 시간 앱은 이 앱이 사용자 장치에서 처음으로 또는 주기적 간격으로 실행될 때와 같이, 기능 교환 시스템으로부터 맵핑 기능 코드를 동적으로 요청할 수 있다. 다양한 구현 예에서, 맵핑 기능성이 관련되는 상영 시간 앱의 스크린('상태(state)'라고도 함)이 사용자에게 디스플레이될 때 기능 교환 시스템으로부터 기능 코드가 요구된다.

제작 개발자의 기능 코드가 갱신되면, 소비 개발자 앱은 기능 코드의 저장된 사본을 갱신할 수 있다. 이 갱신은 풀 구성(pull configuration)에서 수행될 수 있고, 이때 소비 앱은 갱신이 유용한지 알기 위해 기능 교환 시스템으로 주기적으로 확인한다. 다른 구현에서, 기능 교환 시스템은 앱에 갱신을 적용할 수 있다. 또 다른 예에서, 소비 앱이 기능 코드를 먼저 다운로드할 때 이 소비 앱은 기능 교환 시스템으로부터의 갱신에 동의(subscribe)할 수 있다.

이하 기능 모듈이라고 칭하게 되는, 제작 개발자에 의해 제공하는 기능 코드는 다양한 형태를 취할 수 있다. 예를 들어, 기능 모듈은 특정 개체에 한정될 수 있다. 즉, 제공된 기능 모듈은 단일 개체에 대한 기능을 수행할 수 있다. 예를 들어, 맵핑 소프트웨어의 제작 개발자는 기능 모듈을 제공할 수 있고, 각 가능한 위치에 대해 하나씩 맵핑된다. 소비 개발자는 관심 위치에 따라 어느 기능 모듈을 원하는지 지정하게 된다.

예를 들어, 영화 상영 시간 개발자는 극장의 위치에 특정적인 제작 개발자의 맵핑 소프트웨어로부터 기능 모듈을 선택할 수 있다. 그런 다음 소비 개발자는 영화 상영 시간표 앱에서 다루는 그 외 극장마다 기능 모듈을 선택한다. 다른 구현에서, 기능은 개체에 대해 일반적일 수 있다. 즉, 맵핑 소프트웨어의 제작 개발자는 모든 위치를 맵핑하거나 적어도 특정 지리(예를 들어, 미국 대륙) 내 가장 인기있는 위치를 맵핑하는 기능 모듈을 기능 교환 시스템에 제공할 수 있다.

기능 모듈 자체는 다양한 레벨의 복잡도를 갖는 소프트웨어 코드를 포함할 수도 있거나 단순히 정적 데이터를 포함할 수도 있다. 예를 들어 특정 위치의 기능 모듈에는 해당 위치를 포함하는 지도 이미지가 포함될 수 있다. 사용자가 이미지를 선택하면 사용자에게 대화식(interactive) 맵핑을 제공하게 되는 다른 앱에 사용자를 연결할 수 있다. 이미지는 앱의 명칭, 앱의 인기도에 대한 정보 등과 같은 텍스트 정보로 보완되고/되거나 대체될 수 있다.

결과 프리뷰는 딥 뷰 카드(deep view card)로 설명될 수 있으며, 대화형 지도 디스플레이, 내비게이션 방향 등을 제공하는 등으로, 다른 상호 작용을 제공할 수 있는 다른 앱에 대한 딥 링크(deep link)와 연관된다. 딥 링크는 사용자가 맵핑 애플리케이션의 기본 상태로 이동하는 것과 대조적으로, 맵핑 애플리케이션 내의 원하는 위치로 바로 이동하는 것을 의미한다.

애플리케이션에 대한 딥 뷰 카드 또는 애플리케이션의 상태는 애플리케이션 또는 애플리케이션 상태의 식별뿐만 아니라 추가 정보를 표시한다. 예를 들어, 정보는 애플리케이션 상태의 제목 또는 애플리케이션 상태에 대해 서술을 포함할 수 있으며, 애플리케이션 상태로부터의 텍스트 정보일 수 있다. 이미지, 위치, 리뷰 수, 평균 리뷰 및 상태 표시기를 포함하는, 다른 메타데이터가 애플리케이션 상태로부터 제공될 수 있다. 예를 들어, "현재 영업 중" 또는 "문 닫음"의 상태 표시기는 현재 시간이 영업 시간 내인지에 따라 비즈니스에 적용될 수 있다.

일부 딥 뷰 카드는 딥 뷰 카드가 검색 결과로서 선택되게 하는 정보를 강조할 수 있다. 예를 들어, 사용자의 쿼리(query)와 일치하는 딥 뷰 카드 내의 텍스트는 굵게 또는 이탤릭체로 표시될 수 있다. 딥 뷰 카드는 어떤 기관을 즉시 호출하거나 맵핑 애플리케이션으로 직접 전환하여 그 기관으로 가는 내비게이션 방향을 얻을 수 있는 능력과 같이, 직접적인 행동을 가능하게 하는 요소와 통합할 수도 있다. 딥 뷰 카드와의 다른 상호 작용(예를 들어, 딥 뷰 카드의 임의의 다른 부분을 탭핑(tapping)하거나 클릭)은 사용자를 표시된 상태 또는 애플리케이션으로 안내할 수 있다. 아래에서 더 자세히 설명하는 바와 같이, 이것은 관련 앱을 열거나, 앱이 설치되어 있지 않은 경우 원하는 애플리케이션 상태와 관련된 웹 사이트를 여는 것으로 달성될 수 있다. 다른 구현 예에서, 설치되지 않은 앱은 원하는 애플리케이션 상태에 도달하기 위해 다운로드되고, 설치된 다음에 실행될 수 있다.

즉, 딥 뷰 카드는 애플리케이션 또는 상태 자체로부터의 추가 콘텐츠뿐만 아니라, 애플리케이션 또는 상태의 표시를 포함한다. 추가 콘텐츠를 통해 사용자는 어떤 결과를 선택할지에 대해서 더욱 정보에 입각한 선택을 할 수 있으며 심지어 애플리케이션 상태로 탐색하지 않고도 사용자가 직접 작업을 수행할 수 있게 한다. 사용자가 취하길 원하는 동작이 정보를 얻는 것이라면, 일부 상황에서 딥 뷰 카드 자체가 필요한 정보를 제공할 수 있다.

기능 모듈은 상이한 크기의 딥 뷰 카드에 사용하기 위한 다수의 이미지를 포함할 수 있다. 소비 개발자는 딥 뷰 카드에 대한 상태의 특정 섹션을 보유할 수 있으며, 크기가 다양하기 때문에 이미지를 특별하게 원하는 크기로 맞출 수 있다. 기능 모듈은 딥 뷰 카드를 생성하기 위한 코드를 포함할 수 있으며, 이는 적절한 크기의 이미지를 선택하는 것 및/또는 이미지를 스케일링(scaling)하는 것을 포함할 수 있다.

또한, 기능 모듈은 프리뷰 이미지를 생성하는 딥 뷰 생성 코드를 포함할 수 있다. 예를 들어, 딥 뷰 생성 코드는 장치 또는 서버상의 앱에 쿼리(query)하여 관심 위치를 나타내는 이미지를 생성할 수 있다. 딥 뷰 생성 코드는 또한 딥 뷰 카드를 사용자가 선택할 때 따르게 되는 딥 링크를 생성할 수 있다. 딥 뷰 생성 코드는 소비 개발자가 작성한 코드로부터 어떤 한 위치와 같은 정보를 수신할 수 있다.

맵핑 예에 이어서, 딥 뷰 생성 코드는 맵핑 데이터 및/또는 맵핑 데이터의 이미지를 제작 개발자와 관련된 소스로부터 요청한다. 이 소스는 사용자 장치에 설치된 제작 개발자의 앱이거나 제작 개발자가 운영하는 서버 시스템일 수 있다.

예를 들어, 소비 개발자는 일반 개체인 맵핑 벤더로부터의 기능 모듈을 통합할 수 있다. 영화관에 대한 상태가 사용자에게 보일 때, 소비 앱은 영화관 위치를 기능 모듈에 전달한다. 기능 모듈은 제작 개발자의 맵핑 서버에 쿼리하고 딥 뷰 카드를 만든다. 딥 뷰 카드는 일례로 지도 내의 극장 위치의 프리뷰 이미지 및 제작 개발자 앱 내의 영화관 위치에 대한 딥 링크를 포함한다.

딥 링크는 제작 개발자의 앱을 특정 상태로 여는 프로그래밍 호출(programming call)을 포함할 수 있다. 딥 링크에는 제작 개발자 앱의 웹 에디션에 대한 유니폼 리소스 로케이터(uniform resource locator; URL)가 포함될 수 있다. 딥 링크에는 제작 개발자의 앱을 기본 상태로 연 다음에 원하는 상태로 탐색하는 스크립트가 포함될 수 있다. URL은 제작 개발자의 앱이 사용자 장치에 설치되어 있지 않은 경우 사용될 수 있다.

일부 구현 예에서, 일부 또는 모든 기능 모듈은 딥 뷰 카드가 선택될 때 딥 뷰 카드를 제공할 뿐만 아니라 추가 기능을 제공하는 코드를 포함할 수 있다. 예를 들어, 맵핑 애플리케이션의 제작 개발자는 대화식 지도를 제공하는데 필요한 모든 코드를 포함하는 기능 모듈을 생성할 수 있다. 이때 이 기능 모듈은 다른 앱에 연결하지 않고 소비 개발자의 앱 내의 대화식 지도를 제공할 수 있다. 따라서, 기능 모듈은 딥 뷰 카드를 생성하기 위한 코드, GPS 및 Wi-Fi 신호에 기초하여 위치를 식별하기 위한 코드, 및 맵핑 서버로부터 지도 데이터를 검색하기 위한 코드를 포함할 수 있다.

또한, 기능 모듈은 사용자가 지도와 상호 작용할 수 있게 하는 사용자 인터페이스를 구현하기 위한 코드를 포함할 수 있다. 기능 모듈에 의해 생성된 사용자 인터페이스는 사용자가 지도의 딥 뷰 카드를 선택할 때 열리는 별도의 상태일 수 있다. 일부 구현 예에서, 기능 모듈은 다른 상태로 전이하지 않고 딥 뷰 카드 자체 내의 지도의 이미지가 조작되는 것을 허용할 수 있다.

소비 개발자가 앱(제1 앱이라고 칭함)을 개발하고 있을 때, 소비 개발자는 특정 제작 개발자로부터의 기능 교환 시스템으로부터 기능 모듈을 획득할 수 있다. 예를 들어, 소비 개발자는 기능 교환 시스템을 이용하여, 노키아 사(NOKIA Corp.)의 맵핑 기능 모듈을 확인할 수 있다.

다른 구현 예에서, 소비 개발자는 기능 교환 시스템에 의해 설정된 온톨로지(예를 들어, 도 2 참조)로부터 특정 기능을 선택할 수 있다. 즉, 소비 개발자는 "위치의 대화식 지도 표시"에 해당하는 기능을 선택할 수 있다.

제1 앱이 사용자 장치 상에서 실행될 때, 제1 앱은 기능 교환 시스템에 쿼리하여 위치의 대화식 지도를 제공하는 기능 모듈을 요구할 수 있다. 기능 교환 시스템은 사용자 장치에 관한 데이터 및 요청된 기능을 구현하는 다양한 기능 모듈에 관한 데이터를 기반으로 제1 앱에 기능 모듈을 다시 제공한다. 제1 앱은 기능 교환 시스템의 코드로 구현된 샌드박스 내에서와 같이, 기능 모듈을 실행한다. 샌드박스는 사용자 장치의 하드웨어 리소스, 다른 애플리케이션, 및 미리 정의된 범위를 벗어난 임의의 메모리에 대한 액세스를 제한하는 등으로, 기능 모듈의 사용자 장치와의 상호 작용을 상당히 제한할 수 있다.

따라서, 제1 앱은 특정 앱 개발자의 기능 모듈에 대한 하드코딩 참조 없이 원하는 기능을 제공할 수 있다. 제1 앱은 기능 교환 시스템에 쿼리하여 다운로드된 기능 모듈이 실행될 때마다 새로운 기능 모듈 또는 기존 기능 모듈의 새 버전이 권장되는지를 확인한다. 다른 구현에서, 제1 앱은 이전 쿼리 이후 24시간과 같이 미리 정해진 시간이 경과한 후에 기능 교환 시스템에 쿼리할 수 있다.

기능 교환 시스템은 기능 모듈을 동적으로 검색, 갱신 및 실행하는데 필요한 코드를 소비 개발자에게 제공할 수 있다. 이 코드는 개발 중에 제1 앱에 통합된다. 기능 교환 시스템이 제공하는 코드는 라이브러리 또는 패키지로 제공될 수 있으며 소프트웨어 개발 키트(SDK)의 일부로 포함될 수 있다. 소비 개발자가 어떤 기능을 원하는지에 대한 확인은 SDK를 사용하여 수행하거나 기능 교환 시스템의 웹 포털을 사용하여 지정할 수 있다.

도 1에서, 스마트폰과 같은 사용자 장치(104)상에서 실행되는 정교하지 않은 상영 시간 앱(100)이 도시되어 있다. 검색 바(108)로 사용자는 특정 영화(이 경우, 허구의 "The Hobbit XIII")를 검색할 수 있다. 상영 시간 앱(100)은 사용자 장치(104)의 현재 위치 주변의 극장을 보여줄 수 있거나 사용자가 "위치 변경" 버튼(112)을 사용하여 위치를 지정하게 할 수 있다.

AMC 플라자(20) 극장 결과(116-1) 및 MJR 타운플레이스 16 극장 결과(116-2)를 포함하는 결과가 도시된다. 결과(116-1)는 영화 시간(120), "티켓 구매" 버튼(124) 및 별 표시로 극장을 나타낸 극장의 위치의 예시적 지도를 보여주는 딥 뷰 카드(128)를 포함한다.

상영 시간 앱(100)은 활성화된 상영시간 앱(100)의 상태(또는, 스크린)에 응답하여 동작하는 기능 교환 시스템(132)으로부터의 코드를 포함한다. 코드는 기능 모듈 요청(136)을 기능 교환 시스템(132)에 송신한다. 기능 모듈 요청(136)은 어떤 기능을 원하는지를 기능 교환 시스템(132)에 표시하기 위해 기능 ID(140)를 지정한다. 이 경우 바람직한 기능은 위치의 지도를 보여주고 있다. 기능 모듈 요청(136)은 또한 어느 맵핑 애플리케이션이 사용자 장치(104)상에 설치되어 있는지와 같이, 수집된 정보(144)를 포함할 수 있다.

기능 교환 시스템(132)은 기능 모듈(148)로 응답한다. 기능 모듈(148)에 의하면 상영 시간 앱(100)은 딥 뷰 카드(128)의 지도를 디스플레이할 수 있다. 전술한 바와 같이, 기능 모듈(148)은 딥 뷰 카드(128)에 나타난 이미지를 포함하거나 이미지가 검색되고/되거나 생성되게 하는 코드를 포함할 수 있다. 기능 모듈이 개체 특정적이면, 다른 기능 모듈은 결과(116-2)에 대해서 기능 교환 시스템(132)으로부터 검색될 수 있다.

도 2에서, 기능 교환 시스템(132)의 운영자에 의해 개발된 기능 온톨로지(200)는 상이한 산업 분야를 나타낼 수 있는 다수의 브랜치 노드(branch node)(예컨대, 맵핑(204-1) 및 레스토랑(204-2))을 포함한다. 기능 온톨로지(200)는 맵핑 브랜치 노드(204-1) 아래의 거리 어드레스 맵핑(208-1) 및 위성 사진을 갖는 거리 어드레스(208-2)와 같은 리프 노드(leaf node)를 포함한다.

리프 노드들 각각은 하나 이상의 앱에 의해 제공되는 특정 기능에 대응한다. 맵핑 브랜치 노드(204-1) 아래의 내비게이션 방향 브랜치 노드(212)는 자동차 내비게이션 방향(216-1), 도보 내비게이션 방향(216-2) 및 대중교통 내비게이션 방향(216-3)을 위한 리프 노드를 포함한다. 기능 온톨로지(200)는 또한 레스토랑 브랜치 노드(204-2) 아래에 리뷰(220-1), 영업 정보(220-2), 예약(220-3)을 위한 리프 노드를 포함한다.

기능 온톨로지(200)는 다양한 방법으로 배열될 수 있고 다양한 모양으로 분할될 수 있다. 예를 들어, 리프 노드(208-1 및 208-2)는 공통 거리 어드레스 브랜치 노드 아래에서 결합될 수 있으며, 이때 리프 노드(208-1)는 단순히 위성 이미지를 지정하지 않는 반면 리프 노드(208-2)는 위성 이미지의 존재를 지정하게 된다.

기능 온톨로지(200)를 구조화하는 방법에 대한 결정은 예를 들어 얼마나 많은 앱이 각 기능을 수행하는지에 기초하여 기능 교환 시스템(132)의 조작자에 의해 이루어질 수 있다. 한 앱에서만 수행되는 기능을 지정하는 리프 노드가 존재하는 경우, 그 리프 노드는 다른 리프 노드와 결합되어 애플리케이션의 선택을 가능하게 한다.

소비 개발자가 자신의 앱에 대해 관심 기능을 지정하면, 해당 기능은 특정 기능에 해당하는 리프 노드 또는 다양한 기능에 해당하는 브랜치 노드로 지정될 수 있다. 예를 들어, 소비 개발자는 기능 모듈에 의해 제공되는 특정 맵핑 기능이 중요하지 않은 경우 원하는 기능으로서 맵핑(브랜치 노드(204-1))을 지정할 수 있다. 그러나 소비 개발자가 대중교통이 기능 모듈에 포함되는 것을 요구하는 경우, 소비 개발자는 대중 교통 내비게이션 방향에 대한 리프 노드(216-3)를 지정한다.

도 3에는 전반적인 앱 생태계에 대한 하이 레벨 개요가 도시된다. 제작 개발자(300)는 하나 이상의 기능 모듈을 기능 교환 시스템(304)에 제공한다. 소비 개발자(308)는 기능 교환 시스템(304)과 상호 작용하여 선택된 기능을 특정한다. 앱 개발자는 제작 개발자(300)로서의 제작 역할뿐만 아니라 소비 개발자(308)로서의 소비 역할을 수행할 수 있다.

기능 교환 시스템(304)은 소비 개발자(308)에게 하나 이상의 기능 모듈을 제공할 수 있다. 다른 구현 예에서, 기능 교환 시스템은 소비 개발자(308)에게 동적 실행 모듈을 제공할 수 있다. 동적 실행 모듈은 소비 개발자(308)에 의해 개발된 앱이 기능 교환 시스템(304)으로부터 기능 모듈을 검색하는 것을 가능하게 한다.

소비 개발자(308)는 동적 실행 모듈 또는 특정 기능 모듈을 개발중인 애플리케이션(도 3에서는 "앱 A"라고 함)에 통합된다. 앱 A는 구글 사(Google Inc.)에 의한 PLAY 디지털 배포 플랫폼 또는 애플 사(Apple Inc.)의 APP STORE 디지털 배포 플랫폼과 같은 디지털 배포 플랫폼(312)에 제공된다

사용자 장치(104)의 사용자는 디지털 분배 플랫폼(312)으로부터 앱 A를 다운로드한다. 앱 A를 사용자 장치에서 실행하면, 앱 A 내의 동적 실행 모듈(316)은 기능 교환 시스템(304)에 기능 요청을 하고, 기능 교환 시스템(304)으로부터 기능 모듈을 수신한다.

전술한 바와 같이, 동적 실행 모듈(316)은 기능 모듈이 요청된 상태가 사용자 장치(104)에 제공될 때만 활성화될 수 있다. 다른 구현 예에서, 동적 실행 모듈(316)은 앱이 시작될 때마다 매번 기능 요청을 행할 수 있다. 이러한 방식으로, 기능 모듈의 다운로드는 배경에서 수행될 수 있으므로, 대응 상태가 사용자에게 디스플레이될 때 대기가 없다.

도 3은 대부분의 상황에서, 구성 요소들 간에 데이터의 효율적인 흐름을 나타내고 있지만, 제작 개발자(300), 소비 개발자(308), 디지털 배포 플랫폼(312), 기능 교환 시스템(304) 및 사용자 장치(104)는 네트워크(320)를 통해 통신할 수 있다. 네트워크(320)는 단일 네트워크가 아니고, 근거리 통신망, 이동 전화 공급자의 독점적 네트워크 및 인터넷과 같은 분산 통신 네트워크를 포함할 수 있다.

도 4를 참조하면, 기능 교환 시스템(304)에 대한 개발자 포털(400)이 도시되어 있다. 소비 앱 개발자(앱 개발자 A로 지칭)는 404에서 나타낸 바와 같이 개발자 포털(400)에 로그인된다. 앱 개발자 A는 사용자 인터페이스 요소(408)를 사용하여 로그아웃할 수 있다. 앱 개발자 A는 애플리케이션 인터페이스(412)를 사용하여 특정 앱에 대한 기능 모듈을 선택할 수 있다. 이 경우, 특정 앱은 앱 A로 지칭된다.

다른 구현에서, 앱 개발자 A는 개발자 포털(400)이 어떤 앱에 대해 기능이 사용되는지에 대한 정보를 수신하지 않고도 사용 가능한 기능을 검토하고 관심 있는 기능 모듈을 선택할 수 있다. 애플리케이션 인터페이스(412)를 사용하면, 개발자 포털(400)은 앱 개발자 A가 구체적으로 앱 A를 위해 어떤 기능이 사용되었는지를 추적하는 것을 지원할 수 있다.

하나의 예로서, 앱 개발자 A는 "다음(Next)" 사용자 인터페이스 요소(416)를 사용하여 다음 앱에 대해 또는 "이전(Prev)" 사용자 인터페이스 요소(420)를 사용하여 이전 앱에 대한 정보를 볼 수 있다. 앱 개발자 A는 인터페이스 요소(424)를 사용하여 지불 선호를 특정할 수 있다. 예를 들어, 각각의 기능 모듈은 기능 모듈이 사용되는 횟수에 기초하여 계산될 수 있는 가격을 수반할 수 있다.

리스트(428)는 앱 A에 대해 설정된 기능들을 디스플레이한다. 리스트(428) 내의 기능들 중 하나를 클릭하면 신규/편집 기능 인터페이스(432)가 활성화될 수 있다. "X"와 같은 인터페이스 요소(436)는 그 기능이 기능의 리스트(428)로부터 삭제되게 할 수 있다. "추가" 사용자 인터페이스 요소(440)는 신규/편집 기능 인터페이스(432)를 사용하여 새로운 기능을 선택할 수 있게 한다.

차단 리스트(444)는 앱 개발자 A가 기능 모듈로서 사용하기를 원하지 않는 앱을 설정한다. 차단 리스트(444)는 또한 피하려고 하는 특정 개발자를 확인할 수 있다. 명시적인 앱 또는 앱 개발자의 리스트(448)는 "선택" 인터페이스 요소(452)를 사용하여 선택될 수 있다. "패턴 관리..." 사용자 인터페이스 요소(456)는 앱 개발자 A가 와일드카드와 같은 패턴을 지정하게 하여, 피해야 하는 앱이나 개발자를 확인할 수 있다.

도 4에서, 제1 패턴(460-1)은 그 패턴과 일치하는 2개의 앱 또는 앱 개발자와 함께 도시되는 반면, 제2 패턴(460-2)은 패턴과 일치하는 4개의 앱 또는 개발자를 나타낸다. 예를 들어, 앱 개발자 A가 샘의 클럽 웨어하우스 센터(SAM'S CLUB WAREHOUSE CENTER) 할인 소매 업체인 경우, 하나의 지정된 패턴은 코스트코(COSTCO) 할인 소매 업체에 해당할 수 있다. 코스트코 패턴에는 "코스트코" 전후에 와일드카드가 포함되어 있으므로 모든 코스트코 앱이 확인 및 차단된다.

신규/기능 인터페이스(432)에는 기능 특정적 차단 리스트(464)가 존재한다. 기능 특정적 차단 리스트(464)는 차단된 리스트(444)와 유사하게 배열될 수 있어, 앱 개발자 A가 앱 A로부터의 요청에 응답하여 제공되어서는 안 되는 앱 또는 앱 개발자를 확인할 수 있게 한다. 도 4에 도시하지는 않았지만, 차단 리스트(444)와 같은 차단 리스트가 전역적으로 앱 개발자 A에 대해 제공될 수 있으며, 이는 앱 개발자 A에 의해 개발된 모든 앱에 적용될 수 있다.

사용자 인터페이스 옵션 메뉴(468)에 의하면 앱 개발자 A는 지정된 기능을 제공하게 되는 기능 모듈에 대해 디스플레이 변수를 지정할 수 있다. 예를 들어, 옵션에는 기능 모듈의 프리뷰가 표시되는 폭과 높이가 포함될 수 있다. 사용자 인터페이스 옵션 메뉴(468)는 기능 모듈의 그래픽 출력이 폰트 유형, 폰트 크기, 색상 등과 같은 앱 A의 외형 및 느낌과 매칭되도록 하는 다수의 옵션을 제공할 수 있다.

이용 가능한 기능의 리스트(472)로 앱 개발자 A는 앱 A에 대해 관심 있는 기능을 확인할 수 있다. 필터(476)에 의해 앱 개발자 A는 예를 들어 키워드 검색에 기초하여 이용 가능한 기능의 리스트를 걸러낼 수 있다. 기능 중 하나는 소비 개발자가 선택된다. 일부 구현 예에서, 상술된 바와 같이, 소비 개발자는 기능 온톨로지의 브랜치 노드에 대응할 수 있는 기능 그룹 또는 기능 카테고리를 선택할 수 있다. 일부 구현 예에서, 리스트(472)는 기능 온톨로지의 그래픽 뷰(graphical view)에 의해 보충되거나 대체될 수 있다. 도 2에 도시된 바와 같은 트리 뷰(tree view)는 각각의 브랜치가 단일 노드로 나뉜 것으로 도시되므로 기능 온톨로지의 일부 또는 전부를 한 번에 볼 수가 있다. 이 때 사용자는 관심 기능으로의 경로를 따라 브랜치를 확장하기만 하면 된다.

일단 기능이 선택되면, 그 기능을 수행하는 현재 기능 모듈 세트가 개발자에게 보일 수 있다. 도 8과 관련하여 후술되는 바와 같이, 사용자가 기능 모듈과 어떻게 상호 작용하는지에 대한 스크린 샷을 포함하여, 각 기능 모듈에 관한 다양한 메타 데이터가 디스플레이될 수 있다. 이 스크린 샷을 사용하면 소비 개발자는 그 선택한 기능이 소비 개발자가 필요로 하는 것에 대응하는 것인지를 확인할 수 있다. 차단 리스트(464) 및 UI 옵션(468)에서 임의의 원하는 선택이 이루어지면, 사용자 인터페이스 요소(480)는 신규 또는 기존 기능의 편집이 완료되었음을 표시한다.

관심 있는 모든 기능이 결정되면, 앱 개발자 A는 다운로드 UI 요소(484)를 작동시킨다(actuate). 다운로드 UI 요소(484)를 작동시킬 때, 주문형 라이브러리는 앱 A에 통합하기 위해 앱 개발자 A에게 제공될 수 있다. 다양한 다른 구현들에서, 기능의 리스트(428)에 대응하는 API 호출 세트는 앱 개발자 A에게 제공된 일반적인 SDK 라이브러리 사용하기 위해 앱 개발자 A에 제공된다.

소프트웨어 개발 키트(SDK)는 앱이 구성되는 것과 동시에 다운로드될 수 있거나, 앱 개발자 A가 처음으로 개발자 포털(400)을 사용하여 시작할 때 다운로드될 수 있다. SDK는, 예를 들어 통합 개발 환경과 같은, 앱 개발자 A의 프로그래밍 환경과 통합될 수 있다.

SDK는 앱 개발자 A가 최소의 노력으로 기능들 중 하나를 삽입하도록 허용할 수 있다. 예를 들어, 앱 개발자 A는 하나의 기능이 제공되어야 하는 하나의 상태 영역을 지정할 수 있으며 SDK는 지정된 영역 내에서 해당 기능을 제공하도록 기능 모듈을 식별, 다운로드 및 실행하는 동적 실행 코드를 제공한다.

앱 개발자 A에 의해 전역으로, 앱 마다 또는 기능마다 선택된 세팅은 개발자 포털(400)에 의해 제공된 라이브러리에 대한 특정 API 호출과 같이, 앱 A 내에서 캡처될 수 있다. 마찬가지로, 이들 세팅 모두는 또한 기능 교환 시스템(304)으로 전송될 수 있다. 기능 교환 시스템(304)이 앱, 개발자 또는 요청된 기능을 인식하면, 기능 교환 시스템(304)은 설정된 세팅을 참조할 수 있다.

도 5에서, 기능 요청(504)의 예시적인 컨텐츠는 기능 교환 시스템(304)의 공개 키로 암호화되므로 컨텐츠가 도청자에 의해 차단될 수 없다. 기능 식별자(504-1)는 미리 배열된 코드를 사용하는 것과 같이, 송신 앱에 의해 어느 기능이 요구되는지를 확인한다. 원하는 프리뷰 위젯 크기 필드(504-2)는 기능 모듈에 대해 확보된 폭 및 높이의 구역을 지정할 수 있다.

504-3에서, 설치된 앱의 표현이 제공된다. 예를 들어 제목 및 버전 번호를 포함하여 설치된 모든 앱의 철저한 리스트가 포함될 수 있다. 일부 구현 예에서, 비트 필드는 가장 인기있는 100개의 앱에 대해 특정될 수 있다. 다시 말해, 100개의 2진 숫자는 이들 각 앱이 설치되었는지의 여부에 해당하고, 이때 0은 앱이 설치되어 있지 않음을 나타내고 1은 앱이 설치되었음을 나타낸다. 이 단축된 비트 필드 형식을 허용하려면 일련의 앱을 미리 정렬해야 한다. 예를 들어 100개가 사용되었지만, 효율적인 저장을 위해 (128과 같이) 2의 거듭제곱이 사용될 수 있다.

제한된 수의 비트를 사용하여 설치된 앱을 표시하는 또 다른 메커니즘으로 블룸 필터(Bloom filter)가 있다. 블룸 필터는 미리 정의된 세트의 앱들 중에서 하나의 앱이 장치에 설치되어 있는지 또는 그 앱이 절대 설치되어 있지 않는지를 지정한다. 즉, 저장소 압축을 수행하기 위해, 블룸 필터의 출력은 특정 앱이 존재한다는 것을 명시하는 것이 아니라; 블룸 필터 출력은 특정 앱이 존재하지 않는지의 여부를 명시하는 것이다.

설치된 계정 데이터 구조(504-4)는 어떤 계정이 사용자 장치 상에 존재하는지와, 이용 가능한 계정에 관한 임의의 관련 세부 사항을 보고할 수 있다. 이는 결과가 얼마나 관련성이 있는지에 영향을 줄 수 있다. 예를 들어 사용자가 영화를 스트리밍하는 데 관심을 표현하지만, 특정 서비스에 대한 계정이 해당 영화의 스트리밍을 허용하지 않으면, 해당 상태는 감소된 점수를 수신할 수 있다. 상기 계정 데이터 구조(504-4)는 추가적으로 또는 대안적으로 상기 사용자 장치 상에서 어떤 계정이 활성 상태인지와, 상기 계정이 얼마나 최근에 액세스되었는지와 같은 임의의 다른 이용 가능한 데이터를 보고할 수 있다.

504-5에서, 차단 리스트가 특정된다. 이 차단 리스트는 기능 교환 시스템(132)에 이미 존재하는 차단 리스트를 보완하거나 독립형 차단 리스트일 수 있다. 차단 리스트는 기능 교환 시스템(132)에 의해 사전에 알려진 기능 모듈 또는 앱 개발자의 고유 식별자에 기초하여 돌아오지 않을 기능 모듈을 리스트화한다.

504-6에서, 기능 요청(504)을 전송하는 장치의 사양은 운영 체제 및 운영 체제 버전 번호를 포함할 수 있다. 사양은 또한 장치에 대한 위치 정보 데이터, 기능 요청(504)을 송신하는 앱의 식별자, 앱의 앱 개발자의 식별자, 스크린 해상도, 세로/가로 방향, 및 센서 성능(가속도계의 정밀도, 심박 센서의 존재 등)를 포함할 수 있다.

앱 또는 앱 개발자의 식별자는 기능 교환 시스템(132)에 의해 사용되어 차단 리스트와 같은 개발자 포털(400)에 의해 제공되는 미리 배열된 매개 변수를 적용할 수 있다. 또한, 앱 식별자는 기능 교환 시스템(132)에 의해 사용되어 결과로부터 앱 그 자체와 관련된 기능을 제거할 수 있다 - 즉, 요청한 앱의 일부분의 기능을 단순히 복제하는 기능 모듈을 보내오는 것을 방지할 수 있다. 또한, 기능 교환 시스템(132)은 앱 식별자에서 원하는 기능으로의 맵핑을 저장하므로, 앱 식별자는 관심 있는 기능을 나타낼 수 있다. 이 경우에, 기능 식별자(504-1)는 생략될 수 있다.

도 6a를 참조하면, 기능 교환 시스템(304)이 동적 실행 모듈(316)로 보내는 제1 응답(550)이 도시되어 있다. 제1 응답(550)은 동적 실행 모듈(316)에 의해 요청된 기능과 일치하도록 기능 교환 시스템(304)에 의해 선택된 기능 모듈의 고유 ID를 지정하는 모듈 ID(550-1)을 포함한다.

기능 모듈 ID(5501)은 또한 버전 번호를 포함할 수 있다. 버전 번호는 동적 실행 모듈(316)이 더 새로운 버전의 기능 모듈이 이용 가능한지를 평가할 수 있게 한다. 동적 실행 모듈(316)이 기능 모듈 ID(550-1)에 의해 식별된 기능 모듈의 사본을 갖지 않거나 기능 모듈의 버전이 오래된 경우, 동적 실행 모듈(316)은 기능 교환 시스템(304)으로부터 기능 모듈을 요청한다. 이 요청은 단순히 기능 모듈 ID(550-1)의 사본를 포함할 수 있다.

기능 모듈에 대한 명시적인 요청에 응답하여, 도 6b에 도시된 바와 같은 제2 응답(560)이 송신될 수 있다. 제2 응답(560)은 기능 모듈 ID(550-1)에 의해 식별된 기능 모듈(560-1)의 사본을 포함한다. 암호 서명(560-2)은 중간자 공격(man-in-the-middle attack)에 의한 기능 모듈(5601)의 파괴를 방지할 수 있다.

다양한 구현 예에서, 결합된 응답(570)은 도 6c에 도시된 바와 같이 기능 교환 시스템(304)에 의해 전송될 수 있다. 결합된 응답(570)은 기능 모듈이 동적 실행 모듈(316)에 아직 전송되지 않았다는 것을 기능 교환 시스템(304)이 알 때 송신될 수 있다. 다른 구현 예에서, 결합된 응답(570)은 기능 모듈의 다운로드가 동적 실행 모듈(316)과 기능 교환 시스템(304) 간의 또 다른 통신 라운드를 기다리지 않도록 간단히 송신될 수 있다.

도 7을 참조하면, 기능 교환 시스템(304)의 예시적인 구현이 블록도로서 도시되어 있다. 기능 교환 시스템(304)의 사용자 인터페이스(600)에 의해 (제작 역할 또는 소비 역할로 동작할 수 있는) 앱 개발자(604)는 기능 교환 시스템(304)과 통신할 수 있다. 사용자 인터페이스(600)는 인터넷을 통해 이용 가능한 웹 사이트로서 구현될 수 있다.

개발자 인증 모듈(608)은 개발자를 위한 증명서를 저장하고 기능 교환 시스템(304)에 대해 각 개발자를 안전하게 인증해 준다. 개발자 인증 모듈(608)은 개발자 데이터 저장소(612)에 증명서를 저장할 수 있다. 이 증명서에 암호화 소금 값을 추가하고 PBKDF2(Password-Based Key Derivation Function 2; 암호 기반 키 유도 기능 2)와 같은 강력한 해시 기능을 사용하는 등과 같이, 최적의 실행에 따라 저장될 수 있다.

차단 관리 모듈(616)은 개발자가 기능 모듈 또는 기능 모듈의 개발자에 대해 일치하는 패턴을 공식화하도록 하고, 이때 일치는 기능 모듈 요청에 응답하여 제공되어서는 안 된다. 차단할 패턴 및 명시적으로 선택된 기능 모듈 및 앱 개발자는 개발자 데이터 저장소(612)에 저장되며, 이들 앱이 개발자의 모든 애플리케이션에 대해, 개발자의 특정 앱에 대해, 또는 하나 이상의 앱의 특정 기능에 대해 차단되었는지를 나타내는 관련 메타 데이터를 가질 수 있다.

제작자 모듈(620)은 제작 개발자가 기능 모듈을 기능 모듈 데이터 저장소에 제공하도록 한다. 제작 개발자는 프리뷰, 종속성 등을 포함하여, 각 기능 레코드에 저장된 메타 데이터를 제공할 수 있다. 제작 개발자는 그들의 기능 모듈의 사용을 추적하고 기능 모듈을 갱신할 수 있다.

수익 창출 선호 모듈(monetization preferences module)(624)은 소비 및 제작 앱 개발자가 기능 교환 시스템(304)에 지불하고/하거나 서로에게 지불하고, 지불을 수신하는 지불 선호 사항을 저장한다. 다양한 구현에서, 소비 앱 개발자는 트래픽을 제작 개발자의 기능 모듈이나 앱에 보내는 것에 대한 보상을 수신할 수 있다. 또한, 제작 개발자는 제작 개발자 기능 모듈을 사용하는 것이 제작 개발자와의 인식 및 계약을 증가시킬 수 있기 때문에, 기능 교환 시스템(304)에 지불할 수 있다.

또한, 광고는 기능 모듈에 의해 디스플레이된 사용자 인터페이스의 내부 또는 이에 인접하여 표시될 수 있고, 이러한 광고들에 관련된 수익은 기능 교환 시스템 및 생산 및 소비 개발자들 중 하나 또는 둘 모두와 공유될 수 있다. 즉, 제작 개발자는 소비 개발자의 앱을 사용하여 소비 개발자 및/또는 최종 사용자에게 앱을 홍보한 것에 대해 (예를 들어, 노출 당 비용, 클릭 당 비용 또는 설치 당 비용에 따라) 기꺼이 지불할 수 있다.

앱 기능 관리 모듈(628)에 의하면 소비 개발자는 기능 모듈 데이터 저장소(632)에 저장된 기능 온톨로지에 기초하여 하나 이상의 기능 또는 기능 모듈을 식별하고 선택할 수 있다. 다양한 구현에서, 소비 개발자는 기능 온톨로지로부터 기능을 선택하고, 실행시, 해당 기능과 일치하는 기능 모듈을 소비 개발자의 앱에 제공한다.

다른 구현들에서, 기능 모듈은 앱의 개발 동안 소비 개발자에게 제공될 수 있다. 어느 경우에나, 기능 교환 시스템(304)에 의하면 앱 개발자는 정확한 기능 모듈을 특정할 수 있고, 이것은 개발중인 앱에의 통합을 위해 앱 개발자에게 제공되거나 실행 중에 기능 교환 시스템(304)에 의해 앱에 제공되게 된다.

기능 모듈의 명백한 선택은 기능 교환 시스템(304)에는 바람직하지 않은데, 이것은 개량된 또는 보다 수익성 높은 기능 모듈을 소비 개발자에게 제공하는 미래의 기회를 제한하기 때문이다. 향상된 기능 모듈은 더 나은 사용자 경험을 제공하고, 더욱 대중적이고, 더욱 보안성이 있거나, 더 최근에 갱신될 수 있다. 또한, 앱 기능 관리 모듈(628)은 각 앱의 명칭과 그 외 변수를 포함하여, 각각의 개발자가 기능 교환 시스템(304)과 협력하여 개발중인 다양한 앱들을 추적할 수 있다.

통합 모듈(636)은 애플리케이션 개발자(604)에게 동적 실행 코드를 제공한다. 이 동적 실행 코드는 애플리케이션 개발자(604)에 의해 개발된 앱 내에서 기능 모듈이 실행될 수 있게 하는 샌드박스를 제공할 수 있다. 통합 모듈(636)은 동적 실행 코드를 개발자 데이터 저장소(612)에 저장한 선호에 맞추도록 하여, 기능 모듈 데이터 저장소(632)로부터 하나 이상의 기능 모듈을 포함할 수 있다.

통합 모듈(636)은 동적 실행 코드가 앱 개발자(604)에 의해 개발된 소프트웨어 루틴에 의해 호출되도록 하는 API(application programming interface; 애플리케이션 프로그래밍 인터페이스) 호출을 생성할 수 있다. 이러한 API 호출은 차단된 리스트 데이터, 사용자 인터페이스 사이징(sizing) 및 원하는 기능의 식별 정보와 같은, 개발자 데이터 저장소(612)로부터의 세부 사항을 지정할 수 있다.

통합 모듈(636)은 생성된 코드를 앱 개발자(604)에게 제공한다. 생성된 코드는 소스 코드, 오브젝트 코드, 라이브러리, 헤더 파일 및 리소스(이미지 및 폰트 등)를 포함할 수 있다. API 호출이 앱 개발자(604)에 특정한 모든 세팅을 인캡슐화하는 구현 예에서, 동적 실행 코드는 모든 개발자에 걸쳐 동일한 정적 라이브러리일 수 있다. 이러한 방식으로, 통합 모듈(636)에 의해 애플리케이션 개발자(604)에게 제공되는 API 호출에 의하면 동적 실행 라이브러리는 표준화된 라이브러리를 사용하면서 앱 개발자(604)로부터의 세팅을 사용하여 기능을 요청할 수 있다.

전달 모듈(640)은 앱 개발자(604)에 의해 개발된 앱의 실행 동안 동적 실행 모듈(316)로부터의 요청을 서비스한다. 전달 모듈(640)은 차단 리스트가 존재하는지 및 앱 개발자가 어떤 기능 ID를 의도했는지와 같은, 개발자 데이터 저장소(612)로부터 정보를 액세스할 수 있다.

다른 구현 예에서, 원하는 기능의 식별은 동적 실행 모듈(316)로부터 직접 수신된다. 보다 상세히 후술하는 바와 같이, 전달 모듈(640)은 원하는 기능을 제공하고 임의의 적격성 요건과 일치하는 후보 기능 모듈을 식별한다. 예를 들어 일부 기능 모듈에는 특정 운영 체제 또는 특정 운영 체제 버전이 필요할 수 있다. 다른 기능 모듈에는 특정 앱을 설치할 것을 필요로 할 수 있다.

전달 모듈(640)은 대중성, 기능 교환 시스템(304) 중 하나 이상에 대한 수익, 소비 앱 개발자 및 제작 개발자, 및/또는 그 외 얼마나 최근에 기능 모듈이 갱신되었는지와 같은 메트릭(metric) 등에 기초하여, 후보 기능 모듈을 등급화(rank)한다. 그 다음에, 전달 모듈(640)은 최상위의 기능 모듈을 동적 실행 모듈(316)에 제공한다.

도 8에는, 기능 모듈 데이터 저장소(632)에 저장된 기능 모듈 레코드에 대한 예시적인 포맷(700)이 도시되어 있다. 기능 모듈 ID(704)는 기능 모듈 데이터 저장소(632) 내의 기능 모듈을 고유하게 식별할 수 있다. 기능 모듈 메타 데이터(708)는 기능 온톨로지 내에서 고유하게 기능을 식별할 수 있는 기능 ID(708-1)를 포함한다. 기능 카테고리(708-2)는 기능 온톨로지 내의 기능 위의 브랜치 노드를 식별할 수 있다.

입력 파라미터(708-3)는 기능 모듈에 의해 제공되거나 요구될 수 있는 값들의 변수 및 유형을 나타낸다. 예를 들어, 맵핑 서비스를 제공하는 기능 모듈은 입력되게 위치된 목적지를 필요로 하고 선택적으로 현재 위치가 입력되게 할 수 있다.

의존성(dependencies) 필드(708-4)는 기능 모듈을 실행하기 위해 어떤 조건들이 사용자 장치에 의해 충족되어야 하는지를 지시한다. 오직 예시적으로만, 앱에 내장된 동적 실행 라이브러리의 버전이 특정될 수 있고, 운영 시스템 및 허용 가능 버전 번호가 특정될 수 있다. 의존성(708-4)은 또한 어떤 앱이나 앱들이 사용자 장치에 설치되어야하는지 및/또는 어떤 계정이 사용자 장치에서 활성화되어야 하는지를 지정할 수 있다.

프리뷰 크기 필드(708-5)는 기능 모듈을 위한 전체 딥 뷰 카드 또는 기능 모듈을 위한 딥 뷰 카드의 이미지 부분의 크기를 나타낸다. 예를 들어, 딥 뷰 카드는 기능 모듈에 의해 생성된 이미지를 기능 모듈 또는 호스트 앱에 의해 생성된 텍스트에 인접하게 위치 설정하여 형성될 수 있다. 프리뷰 크기는 픽셀 수로 지정될 수 있으며 높이와 폭을 포함할 수 있다.

대중성(popularity)/등급(rating) 필드(708-6)는 기능 모듈 또는 기능 모듈을 개발한 앱의 역대 대중성을 지정할 수 있다. 다른 구현 예에서, 대중성은 지난 달 또는 해와 같이, 제한된 시간대에 기초하여 결정될 수 있다. 대중성은 또한 대중성의 파생 가치(다운로드 속도 - 즉, 앱의 다운로드 속도가 얼마나 빨리 증가하고 있는지)를 반영할 수 있다.

또한, 대중성은 기능 모듈이 호스트 앱에 의해 얼마나 자주 사용되는지에 기초할 수 있다. 대중성은 기능 모듈이 동적 실행 모듈에 제공하기 위해 소비 개발자에 의해 또는 기능 교환 시스템(304)에 의해 얼마나 자주 선택되는지에 기초할 수도 있다. 등급은 앱 또는 기능 모듈의 사용자 피드백을 기반으로 하며, 리뷰, 블로그 게시물, 디지털 배포 플랫폼 등급 등과 같은, 외부 데이터 소스를 기반으로 할 수 있다.

예시적인 사용자 인터페이스 필드(708-7)는 사용자가 기능 모듈과 상호 작용하는 방법에 대한 하나 이상의 스크린 샷을 나타낼 수 있다. 이들은 개발자 포털에 표시되기 때문에 소비 개발자는 기능 모듈이 소비 개발자의 목표에 얼마나 잘 일치하는지를 결정할 수 있다.

기능 모듈(712)은 소비 개발자의 앱의 사용자 인터페이스에 사용할 딥 뷰 카드를 렌더링(render)하기 위한 프리뷰 생성 코드(712-1)를 포함한다. 프리뷰는 선택된 경우 기능 모듈이 무엇을 제공할지를 나타내는 그래픽 정보를 포함할 수 있으며, 또한, 독립적으로 실행 가능한 데이터를 포함할 수 있다. 이 독립적으로 실행 가능한 데이터에 의하면 사용자는 기능 모듈을 활성화하거나 소비 개발자의 앱의 현재 상태를 떠나지 않고도 기능 모듈로부터 필요한 정보를 얻을 수 있다.

동작 코드(712-2)는 기능 모듈이 일단 활성화되면 기능성을 구현할 수 있다. 예를 들어, 기능 모듈이 맵핑 능력을 제공하면, 프리뷰 생성 코드(712-1)는 특정 위치 근처 지도의 간단한 프리뷰를 제공할 수 있다. 기능 모듈을 활성화하게 되면, 동작 코드(712-2)는 패닝(panning), 스크롤링(scrolling), 주밍(zooming) 등을 허용할 수 있는 대화식 지도를 제공할 수 있다.

액세스 메커니즘(712-3)은 동작 코드(712-2) 대신에 사용될 수 있거나, 동작 코드(712-2)를 사용하여 이용 가능한 것 이상으로 추가의 기능성에 대한 액세스를 허용할 수 있다. 기능 모듈이 작동될 때, 액세스 메커니즘(712-3) 중 하나 이상은 기능성을 제공하기 위해서 원하는 상태로 다른 앱을 여는 데 사용될 수 있다. 맵핑의 예를 계속하면, 액세스 메커니즘(712-3) 중 하나는 기능 모듈을 개발한 동일한 개발자로부터 사용자 장치에 저장된 맵핑 앱을 열 수 있다. 따라서, 이 맵핑 앱은 의존성 필드(708-4)에서의 의존도로 지정될 수 있다. 동작 코드(712-2)는 팬 및 줌을 허용하는 대화식 지도를 허용하지만, 액세스 메커니즘(712-3) 중 하나는 위성 이미지 또는 자전거 경로와 같은 추가 정보를 표시할 수 있는 맵핑 앱에 이르기 위해 사용될 수 있다..

리소스(712-4)는 이미지, 폰트, 스타일 시트 등을 포함하는 사용자 인터페이스 생성에 필요한 요소를 포함할 수 있다.

도 9에는, 예시적인 애플리케이션(앱 A(800)) 내의 다양한 기능 블록의 예가 도시되어 있다. 앱 A(800)는 앱 상태에 대해 다수의 템플릿을 포함할 수 있다. 이 템플릿은 앱 A(800)의 각각의 상태(때로는 스크린으로 지칭됨)의 컨텐츠를 정의한다. 하나의 앱 상태 템플릿(804)은 기능 모듈에 의해 생성된 프리뷰가 표시되는 기능 프리뷰 위젯(808)을 포함한다.

앱 상태 템플릿(804)은 앱 상태 템플릿(804)에 기초하여 앱 상태가 인스턴스화될 때, 트리거 신호가 동적 실행 모듈(812)로 전송되는 것을 지정한다. 상기 동적 실행 모듈(812)은 기능 교환 시스템(304)에 의해 개발자 앱 A(800)에 제공되어 개발 동안 앱 A(800)에 통합된다..

동적 실행 모듈은 기능 교환 시스템(304)에 송신되는 쿼리(또는, 요청)를 공식화하는 쿼리 랩퍼 모듈(query wrapper module)(816)을 포함한다. 쿼리는 사용자 장치에 설치된 애플리케이션을 식별하고 설치된 애플리케이션의 표현을 쿼리 랩퍼 모듈(816)에 제공하는 설치된 애플리케이션 모듈(820)을 기반으로 할 수 있다.

계정 인식 모듈(824)은 사용자 장치 상의 활성 사용자 계정을 식별한다. 예를 들어, 스트리밍 비디오 오퍼레이터를 가지는 계정은 그 제공자로부터의 영화의 일부 또는 모두가 기존의 가입 서비스의 일부로서 스트리밍될 수 있다는 것을 나타낼 수 있다. 이로 인해 해당 스트리밍 비디오 오퍼레이터에 대응하는 기능 모듈은 기능 교환 시스템(304)에 의해 제공될 수 있다.

지정된 기능 저장소(828)는 각 앱 상태 템플릿에 대해 어떤 기능이 앱 개발자에 의해 선택되었는지를 저장한다. 기능 프리뷰 위젯(808)은 기능에 대응하고 지정된 기능 저장소(828)는 어떤 기능이 있는지 기록한다. 다른 구현 예에서, 동적 실행 모듈(812)은 라이브러리와 같이, 소프트웨어의 미리 설정된 부분일 수 있다. 이 경우, 지정된 기능 저장소(828)는 API 호출의 변수로 대체될 수 있다. 그 다음, 앱 상태 템플릿(804)은 이들 API 호출을 저장할 수 있고 쿼리 랩퍼 모듈(816)에 대한 트리거 메시지는 API 호출의 원하는 기능을 특정하게 된다.

트리거 메시지 및/또는 지정된 기능 저장소(828)는 또한 차단 리스트 기준과 같이, (기능 교환 시스템(304)에 의해 대안적으로 저장될 수 있는) 추가의 세팅을 쿼리 랩퍼 모듈(816)에 전달할 수 있다. 쿼리 랩퍼 모듈(816) 도 5에 도시된 것과 같은 쿼리를 공식화한다.

기능 교환 통신 모듈(832)은 기능 교환 시스템(304)과 통신한다. 기능 교환 통신 모듈(832)은 공식화된 쿼리를 기능 교환 시스템(304)에 제공하고, 응답하여 기능 모듈 및/또는 지정된 기능 모듈의 표시를 수신한다.

기능 교환 통신 모듈(832)은 기능 모듈의 식별자에 기초하여, 제공될 전체 기능 모듈을 요구할 수 있다. 다른 구현 예에서, 전술한 바와 같이, 기능 모듈은 기능 모듈이 동적 실행 모듈(812)에 의해 이미 수신되었는지에 상관없이 바로 송신될 수 있다. 기능 교환 통신 모듈(832)은 수신된 기능 모듈을 기능 모듈 데이터 저장소(836)에 저장한다.

기능 모듈 데이터 저장소(836)는 MySQL 오픈 소스 데이터베이스의 경량 구현과 같이, 관계형 데이터베이스로서 구현될 수 있다. 데이터베이스는 기능 교환 통신 모듈(832)을 통해 검색된 각 기능 모듈에 대한 레코드를 가질 수 있다. 각 레코드는 모듈 명칭, 버전 번호, 검색 날짜, 갱신 최종 검사 날짜, 인터넷 액세스가 필요한지 등의 필드를 가질 수 있다. 각 레코드는 또한 기능 모듈 코드를 포함하는 파일에 대한 포인터를 포함할 수도 있다. 다양한 구현에서, 기능 모듈 데이터 저장소(836)에 대한 데이터베이스 스키마(schema)는 기능 교환 시스템(304)의 기능 모듈 데이터 저장소(632)에 의해 사용되는 스키마의 서브세트일 수 있다.

기능 실행 모듈(840)은 앱 A(800)의 문맥 내에서 기능 프리뷰 위젯(808)에 대응하는 기능 모듈을 실행한다. 다른 구현 예에서, 기능 모듈은 앱 A(800) 내의 샌드박스 내에서 또는 앱 A(800)와는 별개인 샌드박스 내에서 실행될 수 있다. 샌드박스는 사용자 장치의 운영 시스템 또는 동적 실행 모듈(812) 자체에 의해 제공될 수 있다.

기능 모듈의 실행은 기능 프리뷰 위젯(808) 내에 디스플레이되는, 텍스트 및 그래픽과 같은 정보를 제공한다. 사용자가 기능 프리뷰 위젯(808)을 작동하면 (예를 들어, 터치하거나 클릭하는 등으로), 실행 기능 모듈은 부가의 동작이 요청되었다고 인식한다. 실행 기능 모듈은 새로운 상태를 생성할 수 있거나 또는 추가의 사용자 인터페이스 요소를 앱 상태 템플릿(804)에 대응하는 상태에 제공할 수 있다. 다른 구현 예에서, 실행 기능 모듈은 액세스 메커니즘을 사용하여 추가의 기능을 제공하는 앱을 열거나, 설치한 다음에 열 수 있다. 기능 모듈에 의해 생성된 상태 또는 사용자 인터페이스 요소에서 벗어나면, 앱 상태 템플릿(804)에 대응하는 상태가 다시 한번 앱 A(800)의 전면에 있을 수 있다.

도 10에서, 기능 교환 시스템(304)의 예시적인 동작은 904에서 시작한다. 기능 교환 시스템(304)에 인증된 개발자가 (제작 개발자로서의 개발자의 역할에서) 업로드할 기능 모듈을 갖는다면, 제어는 908로 진행하고; 그렇지 않으면, 제어는 912로 이동한다. 908에서, 제어는 제작 개발자로부터 기능 모듈을 수신하고 916에서 계속된다. 916에서, 제어는 수신된 기능 모듈을 기능 모듈 데이터 저장소에 저장하고 920에서 계속된다. 920에서, 제작 개발자가 각 기능 모듈에 대해 수익 창출 및 광고 변수를 지정할 수 있도록 제어된다. 제어는 912에서 계속된다.

912에서, 개발자가 (소비하는 개발자로서의 역할에서) 기능 모듈을 검색하고 있는 경우, 제어는 단계 924로 이동하고; 그렇지 않으면, 제어는 928로 이동한다. 924에서, 리스트 또는 트리와 같은 그래픽 표현 중에서 선택되는 식으로 기능이 선택되도록 제어된다. 리스트 또는 그래픽 표현은 개발자 의해 걸러지고/지거나 키워드 검색될 수 있다. 932에서, 차단된 리스트 세팅과 같이, 여러 세팅이 개발자에 의해 규정되도록 제어된다. 제어는 936에서 계속되고, 여기에서 동적 실행 코드는 소비 개발자에게 제공된다. 제어는 928에서 계속된다.

928에서, 제어는 쿼리가 기능에 대한 동적 실행 모듈로부터 수신되었는지를 결정한다. 그렇다면, 제어는 940으로 이동하고; 그렇지 않으면, 제어는 904로 복귀한다. 940에서, 쿼리에 의해 지정된 의존성에 기초하여 고려 세트의 기능 모듈을 식별한다. 예를 들어, 고려 세트는 지정된 기능 ID와 일치하고, 지정된 운영 체제와 버전에서 실행되고, 쿼리에 의해 설치되도록 지시된 앱을 필요로 하는 기능 모듈을 포함하게 된다. 제어는 944로 계속 진행되고, 여기에서 고려 세트가 비어 있으면 제어는 948로 진행되고; 그렇지 않으면 제어는 952로 진행한다. 948에서, 제어는 동적 실행 모듈에 오류 메시지를 보낸다. 이 오류 메시지는 동적 실행 모듈에 의해 사용자에게 표시될 수 있거나, 호스트 앱에 의해 트랩되고/되거나 처리될 수 있다. 다음에 제어는 904로 돌아간다.

952에서, 제어는 기능 모듈의 고려 세트를 등급화한다. 전술한 바와 같이, 등급 매김은 다양한 인자들의 가중된 합 또는 평균에 기초하여 각 앱에 대한 메트릭을 결정하는 단계를 포함할 수 있다. 요소들에는 대중성, 요청된 UI 위젯 크기 등이 포함될 수 있다. 이때 등급 매김은 가장 높은 메트릭을 갖는 기능 모듈을 식별한다. 기능 모듈의 고려 세트는 빠른 정렬 알고리즘을 사용하는 등으로 정렬될 수 있으므로, 첫 번째 또는 마지막 기능 모듈이 가장 높은 메트릭을 갖게 된다. 제어는 956에서 계속되고, 이때 상위 등급의 기능 모듈이 선택되어 동적 실행 모듈로 보내진다. 제어는 904로 되돌아간다.

도 11에서, 동적 실행 모듈을 포함하는 호스트 앱의 예시적인 동작은 1004에서 시작한다. 1004에서, 사용자는 디지털 분배 플랫폼으로부터 사용자의 장치로 앱(앱 A로 지칭됨)을 다운로드한다. 1008에서, 앱 A가 실행되면, 제어는 1012에서 계속되고; 그렇지 않으면, 제어는 1008에 유지된다. 1012에서, 제어는 기능 모듈을 갖는 상태가 앱 A 내에 입력되는지 결정한다. 그렇다면, 제어는 1016으로 진행되고; 그렇지 않으면, 제어는 1008로 되돌아간다.

1016에서, 설치된 애플리케이션 및 활성 계정과 같은, 사용자 장치 상의 데이터를 수집하도록 제어된다. 1020에서, 소정의 기능 식별자 및 수집된 데이터를 포함하는 요청을 기능 교환 시스템에 전송하도록 제어된다. 1024에서, 기능 교환 시스템으로부터의 응답을 대기하도록 제어된다. 일단 응답이 수신되면, 제어는 1028로 이동하고; 그렇지 않으면, 제어는 1024로 유지된다. 1028에서, 응답에 의해 지정된 기능 모듈이 이미 로컬 데이터 저장소에 저장되어 있는지 결정하도록 제어된다. 그렇다면 제어는 1032로 진행되고; 그렇지 않으면, 제어는 1036으로 진행된다.

1036에서, 제어는 기능 교환 시스템에 요청을 전송하는 등으로, 응답에 지정된 기능 모듈을 다운로드한다. 제어는 1032에서 계속된다. 제어는 샌드박스에서 기능 모듈을 실행한다. 1040에서, 제어는 기능 모듈로부터 그래픽 위젯을 그 상태 내에서 사용자에게 제공한다. 다음에 제어는 1008로 돌아간다.

도 12는 복수의 개발자(1200-1, 1200-2, 1200-3, ... 1200-N)와 기능 교환 시스템 간의 상호 작용을 나타낸다. 기능 교환 시스템은 앱 내(in-app) 기능을 기본적으로 제공하지 않는 애플리케이션에 앱 내 기능을 제공한다. 이러한 앱 내 기능은 기능 모듈에 포함될 수 있다. 기능 모듈은 기능 모듈이 연관되어 있는 오리지널 애플리케이션의 기능성의 일부를 포함하는 소프트웨어 모듈일 수 있다. 기능 교환 시스템은 서로 다른 애플리케이션에 대해 복수의 기능 모듈을 저장할 수 있다. 사용자 장치(예를 들어, 스마트폰)는 기능 교환 시스템으로부터 기능 모듈을 검색하고, 기능 모듈을 실행하여 일부 구현 예에서 "카드"로 지칭될 수 있는 기능 모듈 GUI를 통해 앱 내 기능성을 제공한다.

일부 구현 예에서, 애플리케이션의 개발자는 (예를 들어, 기능 모듈 생성 SDK를 사용하여) 애플리케이션을 위한 기능 모듈을 생성하고 기능 모듈을 기능 교환 시스템에 업로드할 수 있다.

기능 교환 시스템의 소유자/운영자는 기능 교환 시스템을 사용하여 개발자로부터 수익을 창출할 수 있다. 경우에 따라, 제작 개발자는 기능 교환 시스템에 기능 모듈을 업로드한 데에 대해 기능 교환 시스템에 의해 비용이 청구될 수 있다. 추가적으로 또는 대안으로, 소비 개발자에게 기능 교환 시스템을 사용한 것에 대해 비용이 청구될 수 있다. 예를 들어, 소비 개발자는 기능 모듈의 사용마다 요금이 부과되거나 다른 방식으로 청구될 수 있다(예를 들어, 선불 수수료, 반복적인 수수료 등). 기능 교환 시스템의 소유자/운영자는 지불된 수수료의 일부를 수령할 수 있다. 부가적으로 또는 대안으로, 제작 개발자는 지불된 수수료의 일부를 수령할 수 있다.

소비 개발자는 자신의 앱에 새로운 기능을 제공하기 위해 기능 교환 시스템을 사용하여 기능 모듈을 자신의 앱에 포함할 수 있다. 하나의 특정 예에서, 금융 애플리케이션 개발자는 기능 교환 시스템을 사용하여 금융 애플리케이션에 맵핑 기능을 갖는 기능 모듈을 포함할 수 있다. 이 예에서, 기능 모듈에 의해 구현된 그래픽 사용자 인터페이스(GUI)는 지도상에 여러 은행 지점 및/또는 ATM의 위치를 나타낼 수 있다. 다른 예에서, 레스토랑 리뷰 애플리케이션 개발자는 기능 교환 시스템을 사용하여 레스토랑 리뷰 애플리케이션에 대한 내비게이션 기능성을 갖는 기능 모듈을 포함할 수 있다. 이 예에서, 내비게이션 기능성은 식당 리뷰 애플리케이션을 사용하여 확인된 여러 레스토랑으로 사용자가 탐색할 수 있게 한다.

개발자 인터페이스에서, 소비 개발자는 기능 모듈과 관련된 기능(예를 들어, 텍스트/카테고리 검색)에 기초하여 기능 모듈을 검색할 수 있다. 개발자 인터페이스는 소비 개발자에게 검색된 기능과 관련된 다양한 기능 모듈의 리스트를 제공할 수 있다. 그런 다음 소비 개발자는 소비 개발자의 앱에 (예를 들어, 하나 이상의 앱 상태 내에서) 포함되는 기능 모듈 중 하나를 선택할 수 있다. 기능 교환 시스템의 일부 구현에서, 소비 개발자는 동일하거나 상이한 애플리케이션 상태에 포함하기 위해 다수의 상이한 기능 모듈을 선택할 수 있다.

소비 개발자는 선택된 기능 모듈을 액세스(예를 들어, 검색)하기 위해 기능 교환 시스템으로부터 기능 모듈 어드레스를 검색한다. 소비 개발자는 추가 코드와 함께 소비 개발자 애플리케이션에 기능 모듈 어드레스를 포함할 수 있다. 추가 코드는 기능 교환 시스템을 호출하여 기능 모듈을 요청하는 코드를 포함할 수 있다. 호출은 기능 모듈 어드레스를 변수로 포함할 수 있다. 추가 코드는 기능 교환 시스템으로부터 기능 모듈을 수신하면 사용자 장치가 무엇을 할 것인지를 제어하는 코드(예를 들어, 기능 모듈 GUI를 렌더링하기 위한 코드)를 포함할 수 있다. 어떤 경우에는, 추가 코드의 일부 또는 전부가 클라이언트 앱 모듈 및/또는 사용자 장치 모듈에 포함될 수 있다. 디지털 배포 플랫폼의 예로는 구글 사에서 개발한 구글 플레이(Google Play), 애플 사에서 개발한 앱 스토어(App Store) 및 마이크로소프트 사에서 개발한 윈도우폰 스토어(Windows Phone Store)가 있지만, 이에만 제한하는 것은 아니다.

사용자는 소비 개발자의 앱을 디지털 배포 플랫폼에서 다운로드한 다음 사용자 장치에 앱을 설치한다. 사용자가 기능 모듈 어드레스(및 추가 코드)를 포함하여 앱의 상태를 연 것에 응답하여, 사용자 장치는 기능 교환 시스템(1204)에 액세스하고 앱 상태 내에서 기능 모듈 GUI를 렌더링하기 위해 기능 모듈을 검색한다. 사용자 장치는 앱 상태를 여는 것 이외의 다른 조건들에 응답하여 기능 교환 시스템에 액세스할 수 있다. 예를 들어, 사용자 장치는 사용자가 GUI 요소와 상호 작용한 것에 응답하여 기능 교환 시스템에 액세스할 수 있다. 일 예시에서, GUI 요소는 선택시 기능 모듈의 GUI를 디스플레이하도록 확장한 확장 요소일 수 있다. 좀 더 구체적인 예에서, GUI 확장 요소는 검색된 기능 모듈에 의해 생성된 지도 GUI를 표시하기 위해 사용자 선택에 따라 확장한 "지도 찾기" 버튼일 수 있다.

도 12는 개발자 1(1200-1)와 기능 교환 시스템(1204) 간의 상호 작용에 관한 것이다. 통상적인 시나리오에서, 개발자 1(1200-1)은 애플리케이션 1(1208)을 개발하고 있을 수 있다. 개발자 1(1200-1)은 애플리케이션 1(1208)에 기능을 추가하기를 원할 수 있다. 예를 들어, 개발자 1(1208)은 애플리케이션 1(1208)에 맵핑/내비게이션 기능을 추가하기를 원할 수 있다. 개발자 1(1200-1)은 기능 교환 시스템(1204)을 사용하여 이 기능성을 애플리케이션 1(1208)에 삽입할 수 있다.

개발자 1-N(1200 1, ... 1200-N)은 다른 개발자의 앱에서 사용하기 위해 기능 모듈을 기능 교환 시스템(1204)에 업로드할 수 있다. 도 12에서, 개발자 1(1200-1)은 업로드된 기능 모듈을 가지는데, 이는 선택적일 수 있다. 개발자 1(1200-1)은 또한 "dev 인터페이스 통신"에 의해 예시된 바와 같이, 기능 교환 시스템(1204)과 상호 작용하여 애플리케이션 1(1208)에 대한 기능을 선택한다. 개발자 1(1200-1)은 기능 모듈에 대한 기능 모듈 어드레스를 검색한 다음에 기능 모듈 어드레스를 애플리케이션 1(1208)의 하나 이상의 상태에 삽입한다.

하나의 기능 모듈 어드레스가 검색되어 애플리케이션 1(1208)에 삽입되지만, 일부 구현 예에서, 개발자 1(1200)은 애플리케이션 1(1208)에 삽입하기 위해 다수의 기능 모듈 어드레스를 검색할 수 있다. 기능 모듈 어드레스 이외에, 개발자 1(1200-1)은 상술한 추가의 데이터를 검색할 수 있다(예를 들어, 기능 교환 시스템을 호출하기 위한 코드 및 기능 모듈 GUI를 렌더링하기 위한 코드). 일부 구현 예에서, 애플리케이션 1(1208)에 대한 클라이언트 앱 모듈(1212)의 일부/전부는 기능 모듈 어드레스와 함께 개발자 1(1200-1)에 의해 다운로드될 수 있다. 다른 경우, 개발자 1(1200-1)은 클라이언트 앱 모듈 및 기능 모듈 어드레스를 다른 시간에 검색할 수 있다.

기능 교환 시스템(1204)은 기능 교환 모듈(1216) 및 데이터 저장소(1220)를 포함한다. 기능 교환 모듈(1216)은 본 명세서에서 설명한 방법을 구현한다. 데이터 저장소(1220)는 본 명세서에서 설명한 방법을 구현하는데 사용되는 기능 모듈 레코드(1224) 및 클라이언트 앱 모듈(1228)을 저장한다.

도 13은 기능 모듈 레코드(1300)의 다른 예를 도시한다. 기능 모듈 레코드(1300)는 기능 모듈(1304) 및 기능 모듈(1304)과 관련된 데이터를 포함할 수 있는 데이터 구조이다. 기능 모듈 ID(1308)는 데이터 저장소(1220) 내의 다른 기능 모듈 사이에서 기능 모듈(1304)을 유일하게 식별할 수 있다. 기능 모듈 어드레스(1312)는 기능 교환 시스템(1204)에서 기능 모듈(1304)의 위치를 지시한다. 사용자 장치는 기능 모듈 어드레스(1312)를 사용하여 기능 모듈(1304)을 검색할 수 있다.

기능 모듈 레코드(1300)는 또한 기능 모듈(1304)과 관련된 다양한 다른 유형의 정보를 포함할 수 있다. 기능 모듈(1304)은 기능 명칭(1316-1)과 연관될 수 있다. 기능 명칭(1316-1)은 기능 모듈(1304)에 의해 사람이 판독 가능한 형태로 실행되는 기능을 설명한다. 어떤 경우에, 단일 기능 모듈은 다수의 상이한 명칭을 가질 수 있다.

예를 들어, 기능 명칭은 다수의 상이한 동의어를 가질 수 있다. 다른 경우에, 2개의 기능 모듈은 거의 동일하지만 상이한 언어일 수 있다. 이 경우, 제1 기능 명칭은 영어이고 제2 기능 명칭은 스페인어로 된 명칭일 수 있다. 일부 경우, 일부 기능 모듈은 기능 모듈이 하나 이상의 기능을 포함하기 때문에 다수의 명칭을 가질 수 있다. 예를 들어, 기능 모듈은 맵핑 기능 및 내비게이션 기능 둘 다를 제공할 수 있다.

기능 카테고리(1316-2)는 기능 모듈(1304)에 의해 수행되는 기능의 카테고리 (수직 부분(vertical))를 정의할 수 있다. 예시의 카테고리는 무엇보다도 여행 카테고리, 호텔 카테고리, 영화 카테고리 또는 티켓 카테고리를 포함할 수 있다.

기능 서술(1316-3)은 기능을 사람이 판독할 수 있는 서술일 수 있다. 예를 들어, "레스토랑 표시" 기능의 경우, 기능 서술은 기능 모듈(1304)에 대한 GUI가 표시한 것(예를 들어, 레스토랑 정보, 메뉴 및 리뷰) 및 기능 모듈(1304)이 사용자에게 어떤 다른 기능성을 제공하는지에 대한 서술을 포함할 수 있다. 이 서술은 개발자 인터페이스에서 개발자가 볼 수 있으므로 개발자는 기능의 신속한 기술을 읽을 수가 있다.

모듈 입력(1316-4)은 기능 모듈(1304)이 (예를 들어, 기능 모듈 GUI를 그 상태로 렌더링하기 위해) 동작 동안 사용할 수 있는 값 또는 다른 데이터를 서술한다. 예를 들어, 이 값은 무엇보다도 사용자 장치의 위치 정보, 시각, 그 외 위치(예를 들어, 지도용), 도시 이름(들), 공항 코드(들) 및/또는 요리 이름을 포함할 수 있다.

일부 구현 예에서, 기능 모듈은 다양한 상이한 특성(1316-5)을 포함할 수 있다. 모듈 특성(1316-5)은 기능 모듈(1304)이 "방향을 음성에서 텍스트로 표시"할 수 있는지와 같이, 기능 모듈(1304)의 여러 특성과 능력을 서술(예를 들어, 목록화)한다. "레스토랑 표시 기능"의 경우, 모듈 특성(1316-5)은 운영 시간이 GUI에 표시되는지, GUI에 표시되는 실외 좌석이 있는지, 채식주의자/엄격한 채식주자 요리법의 표시가 있는지, 또는 그 외 특성을 포함할 수 있다.

이 특성은 소비 개발자가 개발자 인터페이스에서 기능 모듈의 특성을 신속하게 결정할 수 있도록 중요 항목 포맷에 있을 수 있다. 일부 구현 예에서, 특성은 개발자 인터페이스에서 필터로 사용될 수 있다(예를 들어, 도 5a-5b 참조). 일부 구현 예에서, 특성은 미리 만들어진 특성의 세트 중에서 소비 개발자에 의해 선택될 수 있다. 예를 들어, 레스토랑과 관련된 기능 모듈은 GUI가 음식 사진, 메뉴, 예약 등을 포함하는지에 대한 것과 같이, 미리 만들어진 레스토랑 특성의 세트를 포함할 수 있다. 모듈 특성(1316-5)에 포함된 유사한 정보는 기능 서술 필드(1316-3)에 포함되어 설명될 수 있다.

GUI 속성 필드(1316-6)는 기능 모듈(1304)에 대해 렌더링된 GUI에 관한 정보를 포함할 수 있다. GUI 속성(1316-6)은 GUI와 연관된 치수 정보를 포함할 수 있다. 예를 들어, 치수 정보는 GUI의 길이 및 폭 치수(예를 들어, 화소로)를 포함할 수 있다. GUI 속성(1316-6)은 GUI가 2D인지 3D인지를 나타낼 수도 있다. GUI 속성(1316-6)은 또한, 기능 모듈에 특정적일 수 있는 다른 속성을 또한 포함할 수 있다. 예를 들어, 맵핑 기능 모듈의 경우, GUI 속성(1316-6)은 지도가 밤낮에 대해 다른 뷰를 갖는지 여부를 나타낼 수 있다.

일부 구현 예에서, 기능 모듈 레코드(1300)는 샘플 출력 데이터(1316-7)를 포함할 수 있다. 샘플 출력 데이터(1316-7)는 개발자 인터페이스에서 소비 개발자에게 프리뷰를 제공하도록 이용될 수 있다. 샘플 출력 데이터(1316-7)는 기능 모듈 GUI가 사용자 장치에서 어떻게 보이는지를 나타낼 수 있다. 이러한 샘플 출력은 소비 개발자가 잠재적으로 모호한 기능 명칭 및 서술 중에서 적절한 기능 모듈을 선택하는 것을 도울 수 있다.

기능 모듈 레코드(1300)에 포함된 데이터는 상기 설명된 데이터에 한정되지 않고, 개발자 이름, 기능 모듈이 기능 교환 시스템에 제출된 날짜, 기능 모듈의 대중성(예를 들어, 기능 모듈이 요청된 횟수) 및 그 외 데이터와 같은 추가 데이터를 포함할 수 있다.

도 14는 예시적인 사용자 장치(1404)와 기능 교환 시스템(1204) 간의 통신을 도시한다. 사용자 장치(1404)는 운영 시스템(1400) 및 애플리케이션 1(1408) 및 추가 네이티브 애플리케이션(1412)을 포함하는 복수의 네이티브 애플리케이션을 포함한다. 하나의 특정 네이티브 애플리케이션은 웹 브라우저 애플리케이션(1414)이다. 애플리케이션 1(1408)은 클라이언트 앱 모듈(1416)을 포함한다. 사용자 장치(1404)는 또한, 사용자 장치 모듈(1420)을 포함한다. 클라이언트 앱 모듈(1416) 및 사용자 장치 모듈(1420)은 기능 교환 시스템(1204)에 기능 모듈 요청을 행하도록 동작할 수 있다.

클라이언트 앱 모듈(1416)은 기능 교환 시스템(1204)에 의해 애플리케이션 1(1408)의 개발자에게 제공된 소프트웨어를 나타낼 수 있다. 개발자는 디지털 배포 플랫폼에 네이티브 애플리케이션을 위치시키기 전에 애플리케이션 1(1408)에 클라이언트 앱 모듈(1416)을 포함할 수 있다. 사용자 장치 모듈(1420)은 사용자가 사용자 장치(1404)를 구입하기 전에 및/또는 사용자 장치(1404) 상에 (예를 들어, 앱의 설치 외부에서) 다운로드되어 설치되기 전에 사용자 장치(1404)에 제공될 수 있는 소프트웨어를 나타낼 수 있다. 사용자 장치 모듈(1420)은 몇몇 경우 OEM(original equipment manufacturer; 주문자 상표 부착 생산자) 소프트웨어, 플랫폼 구성 요소 또는 프레임워크 구성 요소로 지칭될 수 있다.

클라이언트 앱 모듈(1416) 및 사용자 장치 모듈(1420)은 모두 사용자 장치(1404)에 포함될 수 있지만, 다른 구현 예에서, 사용자 장치 모듈(1420)에 기인하는 특성은 애플리케이션 1(1408)의 일부로 클라이언트 앱 모듈(1416)에 포함될 수 있다. 사용자 장치 모듈(1420) 및 클라이언트 앱 모듈(1416) 모두가 사용자 장치(1404) 상에 존재하는 경우, 모듈의 충돌을 방지하기 위해 적절한 규칙이 있을 수 있다. 예를 들어, 모듈들 중 하나는 다른 것에 대신할 수 있다. 하나의 특정 예에서, 클라이언트 앱 모듈(1416)은 사용자 장치 모듈(1420)보다 더욱 최신일 수 있으므로, 사용자 장치 모듈(1420)에 대체(supersede)할 수 있다.

도 14에서, 사용자는 애플리케이션 1(1408)의 애플리케이션 상태(1424)를 열었다. 애플리케이션 상태(1424)를 연 것에 응답하여, 클라이언트 앱 모듈(1416) 및 사용자 장치 모듈(1420) 중 적어도 하나는 기능 모듈 어드레스(1428) 및 사용자 장치(1404)의 유형을 나타내는 데이터(예를 들어, 제조자 모델, 크기, 스크린 해상도 등), 사용자 장치(1404)의 플랫폼(예를 들어, 운영 시스템, 앱의 버전, 앱 명칭), 및 사용자 장치(1404)의 지리적 위치와 같은, 부가의 데이터를 포함할 수 있는 기능 교환 시스템(1204)에 기능 모듈 요청을 생성한다. 기능 교환 시스템(1204)은 기능 모듈 요청에 응답하여 기능 모듈을 사용자 장치(1404)에 보낸다. 다음에 사용자 장치(1404)는 기능 모듈을 실행하고 1432에서 결과적인 그래픽 사용자 인터페이스를 디스플레이한다.

일부 구현 예에서, 애플리케이션 1(1408) 및 클라이언트 앱 모듈(1416)은 애플리케이션 상태(1424)가 열릴 때마다 기능 교환 시스템(1204)으로부터 기능 모듈을 요청하도록 구성될 수 있다. 다른 구현 예에서, 기능 모듈은 기능 모듈의 제1 수신 후에 사용자 장치(1404)상에 저장될 수 있다.

하나의 애플리케이션이 도 14의 클라이언트 앱 모듈을 포함하지만, 일부 경우에는 다수의 애플리케이션이 클라이언트 앱 모듈을 포함할 수 있다. 일부 구현 예에서, 동일한 클라이언트 앱 모듈은 다수의 상이한 애플리케이션에 포함될 수 있다. 다른 구현에서, 앱에 특정적일 수 있는 상이한 클라이언트 앱 모듈들이 상이한 애플리케이션들에 포함될 수 있다. 단일의 기능 모듈 어드레스가 도 14에서 도시되었지만, 다수의 기능 모듈 어드레스들(예를 들어, 동일하거나 상이한 기능 모듈 어드레스)이 하나의 클라이언트 앱 모듈에 포함될 수 있다.

도 15-16은 개발자 인터페이스의 예를 도시한다. 소비 개발자라고 불리는 개발자는 자신의 애플리케이션에 삽입하기 위해 기능 모듈을 검색할 수 있다. 개발자는 기능 모듈과 연관된 기능(예를 들어, 기능 명칭 및 서술을 위한 텍스트 검색)을 검색할 수 있다. 개발자는 또한 기능 카테고리별로 검색할 수 있다. 개발자는 모듈 입력(들), 모듈 특성 및 GUI 속성(예를 들어, 2D/3D 및/또는 차원들(dimensions))과 같은, 다양한 필터 변수를 기반으로 결과를 걸러낼 수 있다.

도 15의 개발자 인터페이스(1500)에서, 쿼리(1504)가 수행될 수 있고, 검색 결과(1508)는 기능 명칭 및 앱 명칭으로 열거된다. 동일한 기능 명칭이 상이한 기능 모듈들에 적용될 수 있음을 주목해야 한다. 이 경우, 앱 명칭은 소비 개발자에 의해 기능 모듈을 구분하는 데에 사용될 수 있다. 개발자는 카테고리 메뉴(1512)에 기초하여 최종 기능 리스트를 좁히거나, 쿼리를 완전히 생략하고 특정 카테고리 내의 모든 기능 모듈을 보는 것으로 할 수도 있다.

또한, 개발자는 다양한 기준에 기초하여 리스트(1508)를 걸러낼 수 있다. 예를 들어, 개별적으로 선택 가능한 필터(1514)의 리스트에서, 하나의 필터는 상호 작용을 허용하는 기능 모듈만을 나타낼 수 있다. 다른 필터는 네트워크 연결을 필요로 하지 않는 기능 모듈만 표시할 수 있다. 다른 필터는 자체 운영 코드를 가지는 기능 모듈만 표시할 수도 있어 다른 앱이나 웹 사이트로 단순히 딥 링크되지 않는다.

예를 들어, 선택 인터페이스 요소(1516)를 사용하는 등으로, 기능 모듈이 선택되면, 기능 모듈의 GUI의 프리뷰(1520)는 앱에 내장될 때 어떻게 출현하는지를 나타내기 위해서 보여진다. 다른 기능 정보는 1524에서 디스플레이된다.

도 16에서, 개발자 인터페이스(1550)는 각 요소에 대한 프리뷰(1562) 및 기능 정보(1566)를 포함하는 포맷으로, 쿼리(1558)로부터 결과될 수 있는 기능의 리스트(1554)를 디스플레이한다. 소비 개발자는 각각의 선택 버튼(1570)을 누름으로써 기능 모듈을 선택할 수 있다.

도 15 내지 도 16에 도시되지는 않았지만, 개발자 인터페이스 GUI는 플랫폼이 기능을 다르게 구현할 수 있기 때문에 기능 모듈에 이용 가능한 플랫폼(예를 들어, 장치 또는 운영 시스템) 및/또는 상이한 플랫폼에 대한 플랫폼 특정 프리뷰를 보여주는 필드를 또한 포함할 수 있다. 일부 경우, 검색 결과는 동일한 기능-앱 조합에 대해 상이한 기능 모듈 GUI들을 포함할 수 있다. 예를 들어, 제작 개발자는 동일한 기능에 대해 다수의 상이한 여러 GUI 형식들을 제공할 수 있다. 개발자 인터페이스는 또한 기능 모듈에 다른 정보를 포함할 수 있다. 예를 들어, 개발자 인터페이스는 기능 모듈을 끼워넣는(embedding) 것과 연관된 비용과 함께 기능 모듈을 끼워넣기 위한 조건을 포함할 수 있다.

도 17은 개발자와 기능 교환 시스템 간의 상호 작용을 설명하는 예시적인 방법을 나타낸다. 처음에, 1600에서, 하나 이상의 제작 개발자(또는 다른 당사자)가 기능 모듈을 생성하기 위한 기능 모듈 생성 SDK를 획득한다. 기능 모듈 생성 SDK는 제작 개발자에 의해 이용되어 자신의 애플리케이션으로부터 기능 모듈을 형성할 수 있다. 다음에 제작 개발자는 기능 모듈 형성 SDK를 사용하여 기능 모듈을 형성하고 이 형성된 기능 모듈을 기능 교환 시스템에 업로드한다.

1604에서, 제1 개발자(소비 개발자)는 기능 교환 시스템에 액세스하여 자신의 애플리케이션(예를 들어, 앱의 하나 이상의 상태)에 추가할 기능 모듈을 검색할 수 있다. 1608에서, 제1 개발자(소비 개발자)는 제2 애플리케이션 개발자(제작 개발자)에 의해 생성된 기능 모듈을 선택한다. 1612에서, 제1 개발자는 선택된 기능 모듈에 대한 기능 모듈 어드레스(및 다른 코드)를 제1 개발자의 앱에 포함시킨다. 1616에서, 제1 개발자는 사용자가 다운로드할 수 있도록 디지털 배포 플랫폼에 앱을 제공한다.

도 18을 참조하면, 처음에 1700에서, 사용자는 제1 개발자의 애플리케이션을 사용자 장치에 다운로드한다. 1704에서, 애플리케이션의 동작 동안, 사용자는 기능 모듈 어드레스를 포함하는 애플리케이션 상태에 액세스한다. 상태에 액세스한 것에 응답하여, 1708에서 사용자 장치는 기능 모듈 요청을 사용하여 기능 교환 시스템에 액세스한다. 요청에 응답하여, 기능 교환 시스템은 1712에서 기능 모듈을 사용자 장치에 전송한다. 1716에서, 사용자 장치는 다음에 액세스된 애플리케이션 상태 내 기능 모듈의 GUI를 렌더링한다.

사용자 장치는 수신된 기능 모듈을 실행하여 다양한 기능성을 제공할 수 있고, 기능 모듈은 다양한 데이터를 포함할 수 있다. 사용자 장치는 수신된 기능 모듈에 포함된 데이터에 기초하여 동작을 수행할 수 있다. 예를 들어, 사용자 장치는 GUI를 렌더링하고, 정보를 검색하고, 수신 기능 모듈에 포함된 데이터에 기초하여 정보를 전송할 수 있다.

기능 모듈은 기능 모듈 GUI(FMGUI)를 생성하기 위해 사용자 장치(예를 들어, 클라이언트 앱 모듈)에 의해 사용되는 데이터(예를 들어, 텍스트, 이미지 및 명령어)를 포함할 수 있다. 사용자 장치는 기능 모듈에 포함된 데이터를 기반으로 하여 FMGUI를 생성한다.

일부 예에서, 사용자 장치는 기능 모듈에 포함된 데이터만을 기초로 하여 FMGUI를 생성할 수 있다. 다른 예에서, 사용자 장치는 FMGUI를 생성하기 위해서 기능 모듈에 포함된 데이터 이외에 사용자 장치에 저장된 데이터를 검색할 수 있다. 또 다른 예에서, 사용자 장치는 FMGUI를 생성하기 위해 기능 모듈에 포함된 데이터 이외에 원격 장치(예를 들어, 원격 서버)로부터의 데이터를 검색할 수 있다.

일부 구현 예에서, 기능 모듈은 텍스트 데이터를 포함할 수 있다. 텍스트 데이터는 FMGUI에 포함될 임의의 텍스트를 포함할 수 있다. 예를 들어, 텍스트 데이터는 제한하는 것은 아니지만, 애플리케이션의 제목, 애플리케이션의 서술, 애플리케이션 기능의 서술, 및 추가의 텍스트를 포함한다. 일부 구현 예에서, 기능 모듈은 이미지 데이터를 포함할 수 있다. 이미지 데이터는 FMGUI에 포함될 임의의 이미지를 포함할 수 있다. 예를 들어, 이미지 데이터는 제한하는 것은 아니지만, 애플리케이션을 나타내는 애플리케이션 아이콘, 사용자 입력 요소(예를 들어, 버튼 이미지, 메뉴 이미지, 슬라이더 이미지 등)에 대한 스크린 샷 또는 이미지와 같이 FMGUI를 렌더링하는 데 사용되는 사용자 인터페이스 이미지를 포함할 수 있다. 이미지 데이터에는 애니메이션과 비디오가 포함될 수도 있다.

일부 구현 예에서, 기능 모듈은 하나 이상의 액세스 메커니즘을 포함할 수 있다. 예를 들어, 기능 모듈은 하나 이상의 애플리케이션 액세스 메커니즘(네이티브 애플리케이션 상태에 대한 링크), 하나 이상의 웹 액세스 메커니즘(예를 들어, URL과 같은 웹 링크), 및 하나 이상의 애플리케이션 다운로드 어드레스(예를 들어, 디지털 배포 플랫폼상의 애플리케이션 다운로드 링크)를 포함할 수 있다. 액세스 메커니즘은 FMGUI에 포함된 하나 이상의 링크와 연관될 수 있다. 본 명세서에 설명된 일부 예에서, 기능 모듈은 자동으로(예를 들어, GPS 변경 또는 다른 데이터에 기초) 또는 사용자 입력에 응답하여 액세스 메커니즘을 생성하기 위한 데이터를 포함할 수 있다.

일부 구현 예에서, 기능 모듈은 사용자에게 정보를 디스플레이하고 사용자 입력(예를 들어, 터치, 클릭, 음성(speech))을 수신하는 GUI 요소를 생성하기 위한 데이터를 포함할 수 있다. 사용자 장치는 기능 모듈의 데이터를 기반으로 하여 정보를 디스플레이하고 사용자 입력을 수신하는 사용자 인터페이스 요소를 생성할 수 있다.

다양한 사용자 인터페이스 요소들은 한정되는 것은 아니지만 다음을 포함할 수 있다: 1) 전경에 제시되어, 팝업이 배경과 중첩하게 이전의 인터페이스를 배경에 남겨두는 팝-업 윈도우(예를 들어, 메시지를 제공하고 추가 입력을 요청하는 대화 상자), 2) 사용자가 텍스트 정보를 입력할 수 있는 텍스트 상자, 3) 사용자가 선택 리스트 중에서 선택할 수 있는 메뉴(예를 들어, 메뉴/하위 메뉴 표시 줄), 4) 사용자가 선택(예를 들어, 탭)할 수 있는 버튼 요소(예를 들어, 푸시 버튼), 5) 사용자 장치가 링크의 사용자 선택에 응답하여 취할 수 있는 동작을 나타내는 텍스트를 포함하는 링크(예를 들어, 하이퍼링크), 6) 아이템의 리스트(예를 들어, 리스트 상자 또는 드롭-다운(drop-down) 리스트), 7) 데이터를 표 형식(예를 들어, 스프레드시트(spreadsheet))으로 표시하는 정보의 그리드 뷰(grid view), 8) 체크 상자, 9) 라디오 버튼, 10) 슬라이더 바, 11) 사용자가 FMGUI의 다수의 상이한 GUI들 사이에서 탐색하기 위해 선택할 수 있는 탭, 12) 날짜를 입력하기 위한 캘린더, 및 13) FMGUI의 크기 및 사용 가능한 기능성을 수정하기 위한 확장/축소 버튼(및 드래깅을 위한 앵커).

일부 구현 예에서, 기능 모듈은 FMGUI의 행동(예를 들어, 자동 행동 또는 사용자 입력에 대해 응답)을 정의하는 명령어를 포함할 수 있다. 명령어는 사용자 장치가 수행하는 동작을 정의할 수 있다. 예를 들어, 명령어는 텍스트, 이미지 및 사용자 입력 요소의 레이아웃을 정의하는 마크업 언어와 같은, FMGUI의 레이아웃을 정의할 수 있다. 명령어는 또한 사용자 장치(예를 들어, 네이티브 애플리케이션, OS 등)가 수행할 작업을 정의할 수도 있다. 명령에 의해 정의된 동작은 몇 예에서 사용자 장치에 의해 자동으로 실행될 수 있다. 예를 들어, 사용자 장치는 (예를 들어, 사용자 장치 또는 인터넷 상의 원격 서버에 저장된) 데이터에 대해 참조를 자동으로 검색할 수 있다

또한, 명령어는 사용자 장치가 사용자 입력에 응답하여 수행할 동작을 정의할 수 있다. 예를 들어, 명령어는 사용자 장치가 본 명세서에서 기술된 사용자 인터페이스 요소 중 임의의 것과 사용자가 상호 작용(예를 들어, 터치)한 것에 응답하여 사용자 장치가 수행할 동작을 정의할 수 있다. 명령어는 또한 계산(예를 들어, 연산 및 그래픽)을 지원할 수 있다. 일부 구현 예에서, 명령어는 탭 타겟의 사용자 선택에 응답하여 하나 이상의 액세스 메커니즘을 생성하는 방법을 정의할 수 있다.

일부 구현 예에서, 기능 모듈은 사용자 장치가 FMGUI에 포함하기 위해 검색하는 데이터에 대한 참조를 포함할 수 있다. 참조는 사용자 장치에 포함된 데이터에 대한 참조일 수 있다. 예를 들어, 하나 이상의 참조는 사용자 장치의 캘린더 정보에 대한 것이다(예를 들어, 사용자의 약속, 따라서 FMGUI는 사용자의 스케줄과의 중복을 표시할 수 있다). 다른 예로서, 하나 이상의 참조는 제한하는 것은 아니지만, 전화 번호, 사진(예를 들어, 연락처 사진), 문자 메시지, 이메일 등을 포함하여, 사용자 장치 상의 연락처 정보에 대한 것이다.

참조는 또한 사용자 장치 이외의 컴퓨팅 장치에 포함된 데이터에 대한 참조 일 수 있다. 예를 들어, 기능 모듈은 기능 교환 시스템 및/또는 제3자 서버에 포함된 서버와 같은, 원격 서버상의 데이터에 대한 참조를 포함할 수 있다. 제3자 서버는 예를 들어, 네이티브/웹 애플리케이션(예를 들어, 사용자 장치용 네이티브 애플리케이션)용 서버를 포함할 수 있다. 참조는 서버에 저장된 텍스트, 이미지 또는 기타 정보일 수 있거나 사용자 장치로부터 정보에 대한 요청에 응답하여 실시간으로 생성될 수 있다. 예들은 택시 위치, 식당 예약 시간, 티켓 구입 가능 여부 등이 있다.

일부 구현 예에서, 기능 모듈은 후원되는 광고 데이터를 포함할 수 있다. 예를 들어, FMGUI는 제작 개발자 또는 제3자 상품 또는 서비스로부터 상품 또는 서비스에 대한 스폰서 광고를 포함할 수 있다.

전술한 설명은 사실상 단순한 예시로서, 본 개시, 그 적용 또는 용도를 결코 제한하려고 하는 것은 아니다. 본 발명의 폭 넓은 개시는 다양한 형태로 구현될 수 있다. 따라서, 본 개시는 특정 예를 포함하지만, 본 발명의 진정한 범위는 도면, 명세서, 및 다음의 청구 범위에 따라 명백해질 것이므로 제한되어서는 안 된다. 방법 내의 하나 이상의 단계는 본 개시의 원리를 변경하지 않고 상이한 순서(또는 동시에)로 실행될 수 있다는 것을 이해해야 한다. 또한, 각각의 실시예는 소정의 특징을 갖는 것으로 설명하였지만, 본 개시의 어느 실시예에 관련하여 설명된 이들 특징들 중 하나 이상은 다른 실시예 중 임의의 것으로 구현되거나 이와 결합될 수 있으며, 이 조합이 명시적으로 기술되지 않아도 그렇다. 달리 말하면, 기술된 실시예들은 상호 배타적이지 않으며, 하나 이상의 실시예와 다른 것과의 치환은 본 개시의 영역 내에 있다.

요소들(예를 들어, 모듈들) 간의 공간적 및 기능적 관계는 "접속된", "결합된", "인터페이스된" 및 "결합된"을 포함하여 다양한 용어를 사용하여 기술된다. 명시적으로 "직접"이라고 기술하지 않는 한, 제1 요소와 제2 요소 간의 관계는 상기 개시 내용에서 설명되며, 그 관계는 제1 요소와 제2 요소 사이에 다른 개재 요소가 존재하지 않는 직접적인 관계와, 하나 이상의 개재 요소가 제1 요소와 제2 요소 사이에 (공간적으로 또는 기능적으로) 존재하는 비간접적인 관계를 포괄한다. 본 명세서에서 사용되는 바와 같이, A, B 및 C 중 적어도 하나의 구절은 배타적 논리합 OR을 이용하여, 논리(A 또는 B 또는 C)를 의미하는 것으로 해석되어야 하며, "A 중 적어도 하나, B 중 적어도 하나, C 중 적어도 하나"를 의미하는 것으로 해석되어서는 안 된다.

이하의 정의를 포함하는 본 출원에서, 용어 '모듈' 또는 용어 '제어기'는 '회로'라는 용어로 대체될 수 있다. '모듈'이라는 용어는 프로세서 하드웨어에서 실행되는 코드를 저장하는 코드 및 메모리 하드웨어(공유, 전용 또는 그룹)를 실행하는 프로세서 메모리(공유, 전용 또는 그룹)의 일부이거나 이를 포함하는 것일 수 있다.

모듈은 하나 이상의 인터페이스 회로를 포함할 수 있다. 일부 예에서, 인터페이스 회로는 근거리 통신망(LAN), 인터넷, 광역 통신망(WAN) 또는 이들의 조합에 연결된 유선 또는 무선 인터페이스를 포함할 수 있다. 본 발명의 임의의 모듈의 기능은 인터페이스 회로를 통해 연결된 다수의 모듈 사이에서 분산될 수 있다. 예를 들어 여러 모듈은 부하 균형 조정을 허용할 수 있다. 또 다른 예에서, 서버(원격 또는 클라우드로도 알려짐) 모듈은 클라이언트 모듈을 대신하여 일부 기능성을 수행할 수 있다.

전술한 바와 같이, 용어 코드는 소프트웨어, 펌웨어 및/또는 마이크로 코드를 포함할 수 있으며, 프로그램, 루틴, 기능, 클래스, 데이터 구조 및/또는 객체를 나타낼 수 있다. 공유 프로세서 하드웨어는 여러 모듈의 일부 또는 모든 코드를 실행하는 단일 마이크로프로세서를 포함한다. 그룹 프로세서 하드웨어는 추가 마이크로프로세서와 함께 하나 이상의 모듈로부터의 일부 또는 모든 코드를 실행하는 마이크로프로세서를 포함한다. 다중 마이크로프로세서에 대한 참조는 개별 다이 상의 다중 마이크로프로세서, 단일 다이 상의 다중 마이크로프로세서, 단일 마이크로프로세서의 다중 코어, 단일 마이크로프로세서의 다중 쓰레드(thread), 또는 상기의 조합을 포함한다.

공유 메모리 하드웨어는 다수의 모듈로부터의 일부 또는 모든 코드를 저장하는 단일 메모리 장치를 포함한다. 그룹 메모리 하드웨어는 다른 메모리 장치와 결합하여 하나 이상의 모듈로부터 일부 또는 모든 코드를 저장하는 메모리 장치를 포함한다.

용어 메모리 하드웨어는 용어 컴퓨터 판독 가능 매체의 서브세트이다. 용어 컴퓨터 판독 가능 매체는 본 명세서에서 사용되는 바와 같이, (반송파(carrier wave)와 같은) 매체를 통해 전파되는 일시적인 전기 또는 전자기 신호를 포함하지 않으므로; 용어 컴퓨터 판독 가능 매체는 유형적이고 비일시적인 것으로 생각된다. 비일시적 컴퓨터 판독 가능 매체의 비제한적인 예들로는 (플래시 메모리 디바이스, 소거 가능 프로그래머블 판독 전용 메모리 디바이스 또는 마스크 판독 전용 메모리 디바이스와 같은) 비휘발성 메모리 디바이스, (예를 들어, 정적 랜덤 액세스 메모리 장치 또는 동적 랜덤 액세스 메모리 장치와 같은) 휘발성 메모리 디바이스, (아날로그 또는 디지털 자기 테이프 또는 하드 디스크 드라이브와 같은) 자기 저장 매체, (CD, DVD 또는 블루-레이 디스크와 같은) 광학 저장 매체가 있다..

본 출원에서 설명된 장치 및 방법은 컴퓨터 프로그램에 구현된 하나 이상의 특정 기능을 실행하도록 범용 컴퓨터를 구성함으로써 생성된 특수 목적의 컴퓨터에 의해 부분적으로 또는 완전히 구현될 수 있다. 상기 설명된 기능 블록 및 흐름도 요소는 소프트웨어 사양으로 작용하며, 이는 숙련된 기술자 또는 프로그래머의 일상 작업에 의해 컴퓨터 프로그램으로 전환될 수 있다.

컴퓨터 프로그램은 적어도 하나의 비일시적 컴퓨터 판독 가능 매체상에 저장된 프로세서 실행 가능 명령어를 포함한다. 컴퓨터 프로그램은 또한 저장된 데이터를 포함하거나 이에 의존할 수 있다. 컴퓨터 프로그램은 특수 목적의 컴퓨터의 하드웨어와 상호 작용하는 기본 입/출력 시스템(BIOS), 특수 목적의 컴퓨터의 특정 장치와 상호 작용하는 장치 드라이버, 하나 이상의 운영 체제, 사용자 애플리케이션, 배경 서비스, 배경 애플리케이션 등을 포함할 수 있다.

컴퓨터 프로그램은 (i) 하이퍼텍스트 마크업 언어 (HyperText Markup Language; HTML) 또는 익스텐서블 마크업 언어 (Extensible Markup Language; XML)과 같이 파싱(parse)될 설명문 텍스트, (ii) 어셈블리 코드, (iii) 컴파일러에 의해 소스 코드로부터 생성된 오브젝트 코드, 컴파일러, (iv) 인터프리터에 의해 실행하기 위한 소스 코드, (v) 저스트-인-타임(just-in-time) 컴파일러에 의해 컴파일 및 실행 하기 위한 소스 코드 등을 포함할 수 있다. 예로서, 소스 코드는 C, C++, C#, 오브젝티브-C, 하스켈(Haskell), Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5, Ada, ASP(활성 서버 페이지), PHP, Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua 및 Python®을 포함하는 언어로부터의 씬택스(syntax)를 이용하여 작성된다.

구성 요소가 "를 위한 수단"을 이용하거나, 방법 청구항의 경우, "를 위한 동작" 또는 "를 위한 단계"를 이용하여 명백하게 인용되는 것이 아니라면, 청구 범위에 열거된 구성 요소 중 어느 것도 35 U.S.C.§112(f)의 의미 내에서 기능식 구성 요소가 되는 것은 아니다.

Claims (58)

1. 개발자 교환 시스템에 있어서,
   레코드를 저장하도록 구성된 데이터 저장소서, 상기 레코드 각각은 기능 모듈 및 상기 기능 모듈을 서술하는 메타 데이터를 포함하며, 상기 메타 데이터는 상기 기능 모듈에 의해 수행되는 기능을 특정하고, 복수의 기능은 기능 온톨로지 내에 배열-되는 데이터 저장소;
   상기 기능 온톨로지로부터 제1 기능을 선택하기 위해 제1 애플리케이션 개발자에게 그래픽 사용자 인터페이스를 제공하도록 구성되는 기능 관리 모듈;
   제1 애플리케이션에의 통합을 위해 상기 제1 애플리케이션 개발자에게 프로세서 실행 가능 명령어를 제공하도록 구성된 통합 모듈로서, 상기 프로세서 실행 가능 명령어는 (i) 기능 모듈 요청을 상기 개발자 교환 시스템으로 송신하는 단계, (ii) 상기 개발자 교환 시스템에 의해 제공된 기능 모듈을 수신하는 단계, (iii) 상기 제공된 기능 모듈을 실행하는 단계, 및 (iv) 상기 제1 애플리케이션 내에서 상기 제공된 기능 모듈로부터 디스플레이 데이터를 제공하는 단계를 포함하고, 상기 기능 모듈 요청은 상기 제1 기능을 식별-하는 통합 모듈; 및
   (i) 기능 모듈 요청을 사용자 장치로부터 수신하고, 상기 기능 모듈은 원하는 기능의 식별자를 지정하며, (ii) 상기 원하는 기능에 대응하는 상기 레코드의 고려 세트를 상기 데이터 저장소로부터 식별하고, (iii) 상기 레코드의 상기 고려 세트 중 하나의 레코드를 선택하고, 그리고 (iv) 상기 선택된 레코드에 대응하는 상기 기능 모듈을 상기 데이터 저장소로부터 상기 사용자 장치에 선택적으로 전송하도록 구성되는 전달 모듈
   을 포함하는 개발자 교환 시스템.
2. 제1항에 있어서,
   (i) 제2 애플리케이션 개발자로부터 기능 모듈을 수신하고, (ii) 상기 제2 애플리케이션 개발자로부터 수신된 상기 기능 모듈을 저장하기 위해 상기 데이터 저장소에 새로운 레코드를 생성하도록 구성되는 제작자 모듈을 더 포함하는 개발자 교환 시스템.
3. 제2항에 있어서,
   상기 제작자 모듈은 상기 제2 애플리케이션 개발자로부터 갱신된 기능 모듈을 수신한 것에 응답하여 상기 데이터 저장소 내의 상기 새로운 레코드를 갱신하도록 구성되는 개발자 교환 시스템.
4. 제2항에 있어서,
   상기 제작자 모듈은 상기 제2 애플리케이션 개발자로부터의 메타 데이터를 상기 새로운 레코드에 저장하도록 구성되며, 상기 메타 데이터는 (i) 상기 제2 애플리케이션 개발자로부터 수신된 상기 기능 모듈의 사용자 인터페이스의 프리뷰 및 (ii) 상기 제2 애플리케이션 개발자로부터 수신된 상기 기능 모듈의 텍스트 서술 중 적어도 하나를 포함하는 개발자 교환 시스템.
5. 제1항에 있어서,
   상기 프로세서 실행 가능 명령어는 제공된 기능 모듈을 기능 모듈 데이터 저장소에 저장하는 단계를 포함하는 개발자 교환 시스템.
6. 제5항에 있어서,
   상기 전달 모듈은 상기 사용자 장치로부터 상기 기능 모듈 요청을 수신한 것에 응답하여 상기 기능 모듈의 식별자를 상기 사용자 장치로 전송하도록 구성되며;
   상기 프로세서 실행 가능 명령어는:
   상기 개발자 교환 시스템으로부터 기능 모듈 식별자를 수신하는 단계; 및
   상기 수신된 기능 모듈 식별자가 상기 기능 모듈 데이터 저장소에 저장된 기능 모듈 식별자와 일치하지 않는 것에만 응답하여, 상기 수신된 기능 모듈 식별자에 의해 식별된 기능 모듈의 제공을 위한 요청을 상기 개발자 교환 시스템에 송신하는 단계
   를 포함하는 개발자 교환 시스템.
7. 제1항에 있어서,
   상기 프로세서 실행 가능 명령어는 상기 제공된 기능 모듈을 샌드박스(sandbox)에서 실행하는 단계를 포함하는 개발자 교환 시스템.
8. 제1항에 있어서,
   상기 프로세서 실행 가능 명령어는 상기 제1 애플리케이션의 기동(startup) 시에, 상기 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계를 포함하는 개발자 교환 시스템.
9. 제8항에 있어서,
   상기 프로세서 실행 가능 명령어는 상기 사용자 장치 상의 상기 제1 애플리케이션의 제1 기동 시에만, 상기 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계를 포함하는 개발자 교환 시스템.
10. 제1항에 있어서,
    상기 디스플레이 데이터는 제1 상태 템플릿에 대응하는 상기 제1 애플리케이션의 상태에 제공되고;
    상기 프로세서 실행 가능 명령어는, 상기 제1 상태 템플릿으로부터 인스턴스화된(instantiated) 상태에 응답하여, 상기 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계를 포함하는 개발자 교환 시스템.
11. 제10항에 있어서,
    상기 프로세서 실행 가능 명령어는:
    상기 개발자 교환 시스템에 의해 제공되는 상기 제공된 기능 모듈을 저장하는 단계; 및
    상기 개발자 교환 시스템이 다른 제2 기능 모듈을 제공하게 하는 상기 제1 상태 템플릿에 대한 후속 기능 모듈 요청에 응답하여, 저장소로부터 상기 제공된 기능 모듈을 제거하는 단계
    를 포함하는 개발자 교환 시스템.
12. 제1항에 있어서, 상기 프로세서 실행 가능 명령어는 상기 제1 기능의 식별 정보를 포함하는 개발자 교환 시스템.
13. 제1항에 있어서,
    상기 기능 모듈 요청은 상기 기능 모듈 요청의 소스를 식별하고;
    상기 전달 모듈은 상기 기능 모듈 요청의 상기 소스에 기초하여 상기 원하는 기능을 인식하도록 구성되는 개발자 교환 시스템.
14. 제1항에 있어서,
    상기 통합 모듈은 상기 제1 애플리케이션 개발자에게 상기 제1 기능의 식별 정보를 제공하도록 구성되며;
    상기 프로세서 실행 가능 명령어는 상기 제1 애플리케이션 개발자에 의해 삽입된 애플리케이션 프로그래밍 인터페이스 호출로부터 상기 제1 기능의 상기 식별 정보를 수신하는 단계를 포함하는 개발자 교환 시스템.
15. 제14항에 있어서,
    상기 통합 모듈은 상기 제1 애플리케이션 개발자에게 소프트웨어 개발 키트를 제공하도록 구성되며;
    상기 소프트웨어 개발 키트는 상기 제1 애플리케이션 개발자가 상기 애플리케이션 프로그래밍 인터페이스 호출을 준비하는 것을 지원하는 개발자 교환 시스템.
16. 제1항에 있어서,
    상기 프로세서 실행 가능 명령어는:
    상기 사용자 장치 상에 설치된 애플리케이션들을 식별하는 단계; 및
    상기 식별된 애플리케이션들에 관련된 데이터를 포함함으로써 상기 기능 모듈 요청을 준비하는 단계를 포함하고,
    상기 전달 모듈은 상기 식별된 애플리케이션들에 관련된 데이터에 따라 상기 레코드의 상기 고려 세트를 제한하도록 구성되는 개발자 교환 시스템.
17. 제1항에 있어서,
    상기 프로세서 실행 가능 명령어는:
    상기 사용자 장치 상의 활성 계정을 식별하는 단계; 및
    상기 활성 계정에 관련된 데이터를 포함함으로써 상기 기능 모듈 요청을 준비하는 단계를 포함하고,
    상기 전달 모듈은 (i) 상기 활성 계정에 관련된 데이터에 따라 상기 레코드의 상기 고려 세트의 스코어를 조정하고, (ii) 상기 선택된 레코드를 상기 조정된 스코어에 따라 선택하도록 구성되는 개발자 교환 시스템.
18. 개발자 교환 시스템을 동작하는 방법에 있어서,
    복수의 기능을 포함하는 기능 온톨로지를 정의하는 단계;
    데이터 저장소에 레코드를 저장하는 단계를 포함하되, 각 레코드는 기능 모듈 및 상기 기능 모듈을 서술하는 메타 데이터를 포함하며, 상기 메타 데이터는 상기 기능 온톨로지로부터 선택된 상기 기능 모듈에 의해 수행되는 기능을 특정하고;
    상기 기능 온톨로지로부터 제1 기능을 선택하기 위해 그래픽 사용자 인터페이스를 생성하여 제1 애플리케이션 개발자에게 제공하는 단계; 및
    상기 제1 기능의 상기 선택에 응답하여, 제1 애플리케이션에 통합하기 위해 상기 제1 애플리케이션 개발자에게 프로세서 실행 가능 명령어를 전송하는 단계를 포함하고,
    상기 프로세서 실행 가능 명령어는 (i) 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계, (ii) 상기 개발자 교환 시스템에 의해 제공된 기능 모듈을 수신하는 단계, (iii) 상기 제공된 기능 모듈을 실행하는 단계, (iv) 상기 제1 애플리케이션 내에서 상기 제공된 기능 모듈로부터 디스플레이 데이터를 제공하는 단계를 포함하고, 상기 기능 모듈 요청은 상기 제1 기능을 식별하는 방법.
19. 제18항에 있어서,
    제2 애플리케이션 개발자로부터 제1 기능 모듈을 수신하는 단계; 및
    상기 제1 기능 모듈을 수신한 것에 응답하여, 상기 제1 기능 모듈을 저장하기 위해 상기 데이터 저장소에 새로운 레코드를 생성하는 단계
    를 더 포함하는 방법.
20. 제19항에 있어서,
    상기 제2 애플리케이션 개발자로부터 상기 제1 기능 모듈의 갱신 버전을 수신하는 단계; 및
    상기 제1 기능 모듈의 상기 갱신 버전을 수신한 것에 응답하여 상기 데이터 저장소 내의 상기 새로운 레코드를 갱신하는 단계
    를 더 포함하는 방법.
21. 제19항에 있어서,
    상기 새로운 레코드는 상기 제2 애플리케이션 개발자로부터의 메타 데이터를 저장하고;
    상기 메타 데이터는 (i) 상기 제2 애플리케이션 개발자로부터 수신된 상기 기능 모듈의 사용자 인터페이스의 프리뷰 및 (ii) 상기 제2 애플리케이션 개발자로부터 수신된 상기 기능 모듈의 텍스트 서술 중 적어도 하나를 포함하는 방법.
22. 제18항에 있어서,
    사용자 장치로부터 기능 모듈 요청을 수신하는 단계를 포함하되, 상기 기능 모듈 요청은 원하는 기능의 식별자를 지정하고;
    상기 원하는 기능에 대응하는 상기 데이터 저장소로부터의 상기 레코드의 고려 세트를 식별하는 단계;
    상기 레코드의 상기 고려 세트 중 하나의 레코드를 선택하는 단계; 및
    상기 선택된 레코드에 대응하는 상기 기능 모듈을 상기 데이터 저장소로부터 선택적으로 검색하고 상기 검색된 기능 모듈을 상기 사용자 장치에 전송하는 단계
    를 더 포함하는 방법.
23. 제22항에 있어서,
    상기 프로세서 실행 가능 명령어는 제공된 기능 모듈을 기능 모듈 데이터 저장소에 저장하는 단계를 포함하는 방법.
24. 제23항에 있어서,
    상기 사용자 장치로부터 상기 기능 모듈 요청을 수신한 것에 응답하여, 상기 기능 모듈의 식별자를 상기 사용자 장치에 전송하는 단계를 더 포함하고,
    상기 프로세서 실행 가능 명령어는:
    상기 개발자 교환 시스템으로부터 기능 모듈 식별자를 수신하는 단계; 및
    상기 수신된 기능 모듈 식별자가 상기 기능 모듈 데이터 저장소에 저장된 기능 모듈 식별자와 일치하지 않는 것에만 응답하여, 상기 수신된 기능 모듈 식별자에 의해 식별된 기능 모듈의 제공을 위한 요청을 상기 개발자 교환 시스템에 송신하는 단계를 포함하는 방법.
25. 제22항에 있어서,
    상기 기능 모듈 요청이 발생한 애플리케이션의 식별자에 기초하여 상기 원하는 기능을 인식하는 단계를 더 포함하는 방법.
26. 제18항에 있어서,
    상기 프로세서 실행 가능 명령어는 상기 제공된 기능 모듈을 샌드박스에서 실행하는 단계를 포함하는 방법.
27. 제18항에 있어서,
    상기 프로세서 실행 가능 명령어는 상기 제1 애플리케이션의 기동 시에 상기 기능 모듈 요청을 상기 개발자 교환 시스템으로 송신하는 단계를 포함하는 방법.
28. 제27항에 있어서,
    상기 프로세서 실행 가능 명령어는 사용자 장치 상의 상기 제1 애플리케이션의 제1 기동 시에만 상기 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 방법.
29. 제18항에 있어서,
    상기 프로세서 실행 가능 명령어는:
    제1 상태 템플릿으로부터 인스턴스화된 상태에 응답하여, 상기 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계를 포함하고,
    상기 디스플레이 데이터는 상기 제1 상태 템플릿에 대응하는 상기 제1 애플리케이션의 상태에 제공되는 방법.
30. 제29항에 있어서,
    상기 프로세서 실행 가능 명령어는:
    상기 개발자 교환 시스템에 의해 제공된 상기 제공된 기능 모듈을 저장하는 단계; 및
    상기 개발자 교환 시스템이 다른 제2 기능 모듈을 제공하게 하는 상기 제1 상태 템플릿에 대한 후속 기능 모듈 요청에 응답하여, 상기 제공된 기능 모듈을 저장소로부터 제거하는 단계를 포함하는 방법.
31. 제18항에 있어서,
    상기 프로세서 실행 가능 명령어는 상기 제1 기능의 식별 정보를 포함하는 방법.
32. 제18항에 있어서,
    상기 제1 애플리케이션 개발자에게 상기 제1 기능의 식별 정보를 제공하는 단계를 더 포함하고,
    상기 프로세서 실행 가능 명령어는 상기 제1 애플리케이션 개발자에 의해 상기 제1 애플리케이션에 삽입된 애플리케이션 프로그래밍 인터페이스 호출로부터 상기 제1 기능의 식별 정보를 수신하는 단계를 포함하는 방법.
33. 제32항에 있어서,
    상기 제1 애플리케이션 개발자에게 소프트웨어 개발 키트를 제공하는 단계를 더 포함하고,
    상기 소프트웨어 개발 키트는 상기 제1 애플리케이션 개발자에게 상기 애플리케이션 프로그래밍 인터페이스 호출을 형성하기 위한 템플릿을 제공하고, 상기 템플릿은 상기 제1 기능의 상기 식별 정보로 채워지는(populated) 방법.
34. 제18항에 있어서,
    상기 프로세서 실행 가능 명령어는:
    상기 제1 애플리케이션이 실행중인 사용자 장치 상에 설치된 애플리케이션들을 식별하는 단계;
    상기 사용자 장치 상의 활성 계정을 식별하는 단계; 및
    상기 활성 계정들에 관련된 데이터 및 상기 식별된 애플리케이션과 관련된 데이터를 포함함으로써 상기 기능 모듈 요청을 준비하는 단계
    를 포함하는 방법.
35. 제1 애플리케이션을 개발하는 방법에 있어서,
    개발자 교환 시스템의 그래픽 사용자 인터페이스에 액세스하는 단계;
    상기 개발자 교환 시스템의 상기 그래픽 사용자 인터페이스를 사용하여, 기능 온톨로지 내의 복수의 기능들 중에서 제1 기능을 선택하는 단계;
    상기 개발자 교환 시스템으로부터 상기 제1 애플리케이션에의 통합을 위한 프로세서 실행 가능 명령어를 수신하는 단계로서, 상기 프로세서 실행 가능 명령어는 (i) 기능 모듈 요청을 상기 개발자 교환 시스템으로 송신하는 단계, (ii) 상기 개발자 교환 시스템에 의해 제공되는 기능 모듈을 수신하는 단계, (iii) 상기 제공된 기능 모듈을 실행하는 단계, (iv) 상기 제1 애플리케이션 내에서 상기 제공된 기능 모듈로부터 디스플레이 데이터를 제공하는 단계를 포함하고, 상기 기능 모듈 요청은 상기 제1 기능을 식별하고; 및
    상기 디스플레이 데이터를 사용자에게 디스플레이하기 위한 영역을 지정하는 단계를 포함하여 상기 프로세서 실행 가능 명령어를 상기 제1 애플리케이션에 통합하는 단계
    를 포함하는 방법.
36. 제35항에 있어서,
    상기 프로세서 실행 가능 명령어는 수신된 기능 모듈을 기능 모듈 데이터 저장소에 저장하는 단계를 포함하는 방법.
37. 제36항에 있어서,
    상기 프로세서 실행 가능 명령어는:
    상기 기능 모듈 요청에 응답하여 상기 개발자 교환 시스템으로부터 기능 모듈 식별자를 수신하는 단계; 및
    상기 수신된 기능 모듈 식별자가 상기 기능 모듈 데이터 저장소에 저장된 기능 모듈 식별자와 일치하지 않는 것에만 응답하여, 상기 수신된 기능 모듈 식별자에 의해 식별된 기능 모듈의 제공을 위한 요청을 상기 개발자 교환 시스템에 송신하는 단계
    를 포함하는 방법.
38. 제35항에 있어서,
    상기 프로세서 실행 가능 명령어는 상기 제공된 기능 모듈을 샌드박스에서 실행하는 단계를 포함하는 방법.
39. 제35항에 있어서,
    상기 프로세서 실행 가능 명령어는 상기 제1 애플리케이션의 기동 시에 상기 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계를 포함하는 방법.
40. 제39항에 있어서,
    상기 프로세서 실행 가능 명령어는 사용자 장치 상의 상기 제1 애플리케이션의 제1 기동 시에만 상기 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계를 포함하는 방법.
41. 제35항에 있어서,
    상기 기능 모듈로부터 상기 디스플레이 데이터의 디스플레이를 위한 제1 상태 템플릿 내의 영역을 확보하는 단계를 포함하여, 상기 디스플레이 데이터를 제1 상태 템플릿으로 통합하는 단계를 더 포함하고,
    상기 제1 상태 템플릿으로부터 상태의 인스턴스화에 응답하여, 상기 기능 모듈이 호출되고(invoked), 상기 기능 모듈에 의해 생성된 상기 디스플레이 데이터는 상기 확보된 영역에 디스플레이되는 방법.
42. 제41항에 있어서,
    상기 프로세서 실행 가능 명령어는, 상기 제1 상태 템플릿으로부터 상기 상태의 인스턴스화에 응답하여, 상기 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계를 포함하는 방법.
43. 제42항에 있어서,
    상기 프로세서 실행 가능 명령어는:
    상기 개발자 교환 시스템에 의해 제공된 상기 제공된 기능 모듈을 저장하는 단계;
    상기 제1 상태 템플릿으로부터 상태가 인스턴스화될 때마다 기능 모듈 요청을 상기 개발자 교환 시스템에 송신하는 단계; 및
    상기 개발자 교환 시스템이 다른 제2 기능 모듈을 제공하게 하는 상기 제1 상태 템플릿에 대한 후속 기능 모듈 요청에 응답하여, 상기 제공된 기능 모듈을 저장소로부터 제거하는 단계
    를 포함하는 방법.
44. 제41항에 있어서,
    상기 개발자 교환 시스템으로부터 상기 제1 기능의 식별 정보를 수신하는 단계; 및
    상기 제1 상태 템플릿과 연관된 코드 내에서 애플리케이션 프로그래밍 인터페이스 호출을 생성하는 단계를 더 포함하고, 상기 애플리케이션 프로그래밍 인터페이스 호출은 상기 제1 기능의 식별 정보를 포함하는 방법.
45. 제44항에 있어서,
    상기 개발자 교환 시스템으로부터 소프트웨어 개발 키트를 수신하는 단계를 더 포함하고,
    상기 소프트웨어 개발 키트는 상기 애플리케이션 프로그래밍 인터페이스 호출을 생성하기 위한 템플릿을 제공하고,
    상기 애플리케이션 프로그래밍 인터페이스 호출을 생성하는 단계는 상기 템플릿을 상기 제1 기능의 식별 정보로 채우는 단계를 포함하는 방법.
46. 제35항에 있어서,
    상기 프로세서 실행 가능 명령어는:
    사용자 장치 상에 설치된 애플리케이션을 식별하는 단계;
    상기 사용자 장치 상의 활성 계정을 식별하는 단계; 및
    상기 활성 계정들에 관련된 데이터 및 상기 식별된 애플리케이션과 관련된 데이터를 포함함으로써 상기 기능 모듈 요청을 준비하는 단계
    를 포함하는 방법.
47. 제35항에 있어서,
    상기 제1 애플리케이션의 기능성의 적절한 서브세트를 갖는 제1 기능 모듈을 생성하는 단계; 및
    상기 제1 기능 모듈을 상기 개발자 교환 시스템에 제공하는 단계
    를 더 포함하는 방법.
48. 제47항에 있어서,
    상기 기능성의 적절한 서브세트에 관련된 상기 제1 애플리케이션의 코드를 갱신한 것에 응답하여, 상기 제1 기능 모듈의 갱신 버전을 상기 개발자 교환 시스템에 제공하는 단계를 더 포함하는 방법.
49. 제47항에 있어서,
    상기 제1 기능 모듈에 관한 메타 데이터를 상기 개발자 교환 시스템에 제공하는 단계를 더 포함하며, 상기 메타 데이터는 (i) 상기 제1 기능 모듈의 사용자 인터페이스의 프리뷰 및 (ii) 상기 제1 기능 모듈의 텍스트 서술 중 적어도 하나를 포함하는 방법.
50. 프로세서 실행 가능 명령어를 저장하는 비일시적 컴퓨터 판독 가능 매체에 있어서, 상기 명령어는:
    기능 모듈 요청을 네트워크 연결을 통해 개발자 교환 시스템에 전송하는 단계를 포함하되, 상기 기능 모듈 요청은 수행될 특정 기능을 식별하고;
    상기 개발자 교환 시스템으로부터 제1 기능 모듈을 수신하는 단계를 포함하되, 상기 제1 기능 모듈은 수행될 상기 특정 기능과 관련된 디스플레이 데이터를 생성하도록 구성된 코드를 포함하고;
    상기 제1 기능 모듈을 기능 모듈 데이터 저장소에 저장하는 단계;
    트리거링 이벤트(triggering event)에 응답하여, 상기 기능 모듈 데이터 저장소로부터 상기 제1 기능 모듈을 검색하고 상기 제1 기능 모듈을 실행하는 단계; 및
    상기 제1 기능 모듈의 실행에 의해 생성된 디스플레이 데이터를 제공하는 단계
    를 포함하는 비일시적 컴퓨터 판독 가능 매체.
51. 제50항에 있어서,
    상기 제1 기능 모듈은 샌드박스에서 실행되는 비일시적 컴퓨터 판독 가능 매체.
52. 제50항에 있어서,
    상기 디스플레이 데이터는 상기 명령어가 포함되는 애플리케이션의 제1 상태 내에 디스플레이되고;
    상기 트리거링 이벤트는 상기 애플리케이션의 사용자에 의해 액세스되는 상기 애플리케이션의 상기 제1 상태를 포함하는 비일시적 컴퓨터 판독 가능 매체.
53. 제50항에 있어서,
    상기 디스플레이 데이터는 상태가 인스턴스화되는 제1 애플리케이션의 제1 상태 템플릿에 포함(incorporated)되고;
    상기 트리거링 이벤트는 상기 제1 상태 템플릿으로부터 인스턴스화된 상태에 기초하는 비일시적 컴퓨터 판독 가능 매체.
54. 제53항에 있어서,
    상기 기능 모듈 요청은 상기 제1 상태 템플릿으로부터 인스턴스화되는 상태에 응답하여 전송되고;
    상기 명령어는 상기 제1 상태 템플릿으로부터 인스턴스화된 상태의 또 다른 인스턴스에 응답하여 제2 기능 모듈 요청을 상기 개발자 교환 시스템으로 전송하는 단계를 포함하고;
    상기 명령어는 상기 제2 기능 모듈 요청에 따라 상기 개발자 교환 시스템으로부터 다른 제2 기능 모듈을 수신한 것에 응답하여, 상기 기능 모듈 데이터 저장소로부터 상기 제1 기능 모듈을 삭제하는 단계를 포함하는 비일시적 컴퓨터 판독 가능 매체.
55. 제50항에 있어서, 상기 명령어는:
    상기 기능 모듈 요청에 응답하여 상기 개발자 교환 시스템으로부터 기능 모듈 식별자를 수신하는 단계; 및
    상기 수신된 기능 모듈 식별자가 상기 기능 모듈 데이터 저장소에 저장된 기능 모듈 식별자와 일치하지 않는 것에만 응답하여, 상기 제1 기능 모듈의 제공을 위한 요청을 상기 개발자 교환 시스템에 송신하는 단계
    를 포함하는 비일시적 컴퓨터 판독 가능 매체.
56. 제50항에 있어서,
    상기 명령어는:
    상기 명령어가 저장된 장치에 설치된 애플리케이션들을 식별하는 단계;
    상기 장치 상의 활성 계정을 식별하는 단계; 및
    상기 활성 계정에 관련된 데이터 및 상기 식별된 애플리케이션과 관련된 데이터를 포함함으로써 상기 기능 모듈 요청을 준비하는 단계
    를 포함하는 비일시적 컴퓨터 판독 가능 매체.
57. 제50항의 비일시적 컴퓨터 판독 가능 매체; 및
    상기 비일시적인 컴퓨터 판독 가능 매체로부터 상기 명령어를 실행하는 프로세싱 하드웨어
    를 포함하는 컴퓨팅 장치.
58. 제57항에 있어서, 상기 컴퓨팅 장치는 스마트폰인 컴퓨팅 장치.

Images