KR20070031378A

KR20070031378A - 디바이스 팀 모집을 위한 아키텍쳐 장치 및 방법 그리고보편적 디바이스 상호운용성 플랫폼 관련 애플리케이션들을위한 콘텐트 렌디셔닝

Info

Publication number: KR20070031378A
Application number: KR1020077000512A
Authority: KR
Inventors: 다니엘 일로우스키; 브루스 번스틴; 리차드 미라벨라; 울프강 피브; 레이몬드 시드니; 리차드 타이베리; 마이클 웨노커
Original assignee: 다트디바이시스 코포레이션
Priority date: 2004-06-08
Filing date: 2005-06-08
Publication date: 2007-03-19

Abstract

유사하거나 상이한 특성을 가지는 디바이스들 간의 통신을 제공하고 그 디바이스들 간의 원활한(seamless) 상호운용성을 도모하기 위한 시스템, 디바이스, 방법 및 컴퓨터 프로그램 및 컴퓨터 프로그램 제품들. 유사하거나 상이한 영구적으로 또는 단속적으로 연결된 전자 기기들에 걸쳐서 콘텐트, 애플리케이션들, 리소스들 및 컨트롤을 공유하기 위한 컴퓨터 소프트웨어, 방법들, 시스템들 및 디바이스들. 제공되는 프레임워크 내에서 통신하거나 상호 운용되는 디바이스들, 시스템들 및 기기들. 모집 상호운용 방법, 렌디셔닝 적응 및 상호운용성 분할 방법, 상호운용 소스, 상호운용 프레임워크, 상호운용 툴들, 상호운용 포맷, 상호운용 런타임, 선형 태스킹, 수직 레이어링, 애플리케이션 구동 전력 관리, 상호운용 애플리케이션 구동 에러 복구, 상호운용 인스트럭션 세트, 크리에이셔니즘, 상호운용 엔진, 상호운용 디바이스 인에이블링, 상호운용 시큐리티 모델, 소셜 싱크러니제이션 상호운용 방법, 소셜 시큐리티 상호운용 모델, 상호운용 모델, 상호운용 플랫폼, 버츄얼 포인터들, 다트 전용 버젼들 또는 이들의 구현 수단들.

상호 운용성, 상호운용 애플리케이션, 리크루트, 렌디셔닝, 다트

Description

디바이스 팀 모집을 위한 아키텍쳐 장치 및 방법 그리고 보편적 디바이스 상호운용성 플랫폼 관련 애플리케이션들을 위한 콘텐트 렌디셔닝{Architecture apparatus and method for device team recruitment and content renditioning for universal device interoperability platform}

본 발명은 유사 또는 비유사 특징들을 가진 장치들 간 통신을 제공하고 상기장치들 사이의 심리스(seamless) 상호운용성을 쉽게 하기 위한 시스템들, 장치들, 방법들, 그리고 컴퓨터 프로그램 소프트웨어 제품들에 관한 것으로서, 보다 구체적으로는, 유사 그리고 비유사한 영구적으로 또는 단속적으로 연결되는 전자 장치들 사이에서 콘텐츠, 애플리케이션들, 리소스들 및 제어의 공유를 위한 시스템들과 장치들의 소프트웨어 및 방법들에 관한 것이다.

본 출원은 발명의 명칭이 Architecture, Apparatus And Methods Thereof For An Efficient, Low Cost, Seamless Device Interoperability Software Platform이고, 발명자가 Daniellllowsky인 2004년 6월 8일에 출원된 미국 가특허출원번호 60/577,971의 35 U.S.C. 119(e) 하에서의 우선권의 이익을 주장하며, 상기한 가출원은 전체가 여기에서 참조로서 결합된다.

다음의 동시계류 미국 특허출원들과 PCT 국제특허출원들도 관련 출원들이고 이들 각각은 전체가 여기에서 참조로서 결합된다:

대리인 사건 번호 186245/US/8 2005년 6월 8일 출원, 발명의 명칭: Method And System For Device Recruitment Interoperability And Assembling Unified Interoperating Device Constellation;

대리인 사건 번호 186245/US/9 2005년 6월 8일 출원, 발명의 명칭: Method System and Data Structure For Content Renditioning Adaptation And Interoperability Segmentation Model;

대리인 사건 번호 186245/US/5 2005년 6월 8일 출원, 발명의 명칭: Method and System for Specifying Device Interoperability Source Specifying Renditions Data and Code for Interoperable Device Team;

대리인 사건 번호 186245/US/2 2005년 6월 8일 출원, 발명의 명칭: Device Interoperability Framework and Method For Building Interoperability Applications For Interoperable Team of Devices;

대리인 사건 번호 186245/US/14 2005년 6월 8일 출원, 발명의 명칭: Device Interoperability Tool Set and Method For Processing Interoperability Application Specifications into Interoperable Application Packages;

대리인 사건 번호 186245/US/15, 2005년 6월 8일 출원, 발명의 명칭: Device Interoperability Format Rule Set and Method for Assembling Interoperability Application Package;

대리인 사건 번호 186245/US/16 2005년 6월 8일 출원, 발명의 명칭: Device Interoperability Runtime Establishing Event Serialization and Synchronization Amongst a Plurality of Separate Processing Units and Method for Coordinating Control Data and Operations;

대리인 사건 번호 186245/US/11 2005년 6월 8일 출원, 발명의 명칭: Method and System For Linear Tasking Among a Plurality of Processing Units;

대리인 사건 번호 186245/US/10 2005년 6월 8일 출원, 발명의 명칭: Method and System For Vertical Layering Between Levels in A Processing Unit Facilitating Direct Event-Structures And Event-Queues Level-to-Level Communication Without Translation;

대리인 사건 번호 186245/US/7 2005년 6월 8일 출원, 발명의 명칭: System And Method For Application Driven Power Management Among Intermittently Coupled Interoperable Electronic Devices;

대리인 사건 번호 186245/US/17 2005년 6월 8일 출원, 발명의 명칭: System And Method For Interoperability Application Driven Error Management and Recovery Among Intermittently Coupled Interoperable Electronic Devices;

대리인 사건 번호 186245/US/4 2005년 6월 8일 출원, 발명의 명칭: Device and Method For Interoperability Instruction Set;

대리인 사건 번호 186245/US/3 2005년 6월 8일 출원, 발명의 명칭: Method and System For Customized Programmatic Dynamic Creation of Interoperability Content;

대리인 사건 번호 186245/US/12 2005년 6월 8일 출원, 발명의 명칭: Method and System for Interoperable Content Player Device Engine;

대리인 사건 번호 186245/US/18 2005년 6월 8일 출원, 발명의 명칭: Method and System for Interoperable Device Enabling Hardware Abstraction Layer Modification and Engine Porting;

대리인 사건 번호 186245/US/13 2005년 6월 8일 출원, 발명의 명칭: System Method and Model For Maintaining Device Integrity And Security Among Intermittently Connected Interoperating Devices;

대리인 사건 번호 186245/US/19 2005년 6월 8일 출원, 발명의 명칭: System Method and Model For Social Synchronization Interoperability Among Intermittently Connected Interoperating Devices;

대리인 사건 번호 186245/US/20 2005년 6월 8일 출원, 발명의 명칭: System Method and Model For Social Security Interoperability Among Intermittently Connected Interoperating Devices;

대리인 사건 번호 186245/US/6 2005년 6월 8일 출원, 발명의 명칭: System Device and Method for Configuring and Operating Interoperable Device having Player and Engine;

대리인 사건 번호 186245/US/21 2005년 6월 8일 출원, 발명의 명칭: Method and System For Specifying Generating and Forming Intelligent Teams of Interoperable Devices;

대리인 사건 번호 186245/US/22 2005년 6월 8일 출원, 발명의 명칭: Method and System For Configuring and Using Virtual Pointers to Access One or More Independent Address Spaces;

대리인 사건 번호 186245/PCT/2 2005년 6월 8일 출원, 발명의 명칭: Architecture Apparatus And Method For Seamless Universal Device Interoperability Platform; and

대리인 사건 번호 186245/PCT/3 2005년 6월 8일 출원, 발명의 명칭: Architecture Apparatus And Method For Device Team Recruitment and Content Renditioning for Universal Device Interoperability Platform.

애플리케이션 프로프램들의 종류들 및 장치 종류들에서의 팽창뿐만 아니라, 전자 디바이스들, 특히 휴대가능하고 무선인 장치들의 수와 종류의 막대한 팽창이 있었던 시기에, 다수의 디바이스들의 전자 및 프로그램에 따른 리소스들을 채용하므로써만 달성될 수 있는 애플리케이션들의 의도를 수행하기 위하여 이들 다양한 이종의 다른 디바이스 유형들 사이에서 직접 공유될 데이터와 코드를 위한 해당 필요성이 있었다. 필요성이 또한 생겨나서 사용자가 원하는 통신의 종류 또는 데이터 전송 또는 공유를 위하여 미리 설정되거나 혹은 설정되지 않을 수도 있는 다른 디바이스들과 디바이스 사용자가 통신할 수 있도록 계속해서 성장한다. 예를 들어, 디지털 카메라 상에서 사진 모음을 가지거나 생성하고 이후 사진들의 수집을 PDA형 디바이스, 텔레비젼, 또는 시청용 프로젝터, 또는 저장 디바이스 또는 프린터에 직접 전송할 수 있기를 원할 수도 있다. 사용자는 또한 선택적으로 사진들, 타이틀, 슬라이드들의 인덱스들 등을 인캡슐레이팅(encapsulating)하는 순차 슬라이드 쇼를 수행하는 코드를 또 다른 디바이스, 예를 들어, 상기 슬라이드 이미지들이 있는 디바이스보다 더 큰 스크린 해상도 또는 더 나은 그래픽 성능을 가진 디바이스로 전송하기를 원할 수도 있다. 사용자는 또한 이용가능한 프린터 상에서 상기 슬라이드 쇼 내의 사진들의 일부 집합을 선택하여 프린터할 수 있기를 원할 수도 있다. 그러한 코드, 데이터 그리고 콘텐트 공유의 많은 다른 예들이 있다.

종래의 상호운용성 이슈들, 문제들, 그리고 한계들

관련 디바이스 컴퓨팅 리소소들의 공유, 그리고 유사(동종의) 그리고 비유사(이종의) 디바이스들 또는 디바이스 유형들 사이의 디바이스 제어와 함께 데이터 및 코드의 공유는 "디바이스 상호운용성(device interoperability)" 또는 단순히 "상호운용성"으로서 선행기술에서 알려진다. 이러한 상호운용성을 제공하는데 포함되는 필요하고 선택적인 향상 이슈들의 일부는 (i) 콘텐트 적합; (ii) 콘텐트 포맷; (iii) 디바이스 드라이버들; (iv) 디바이스들간 통신; (v) 개별 디바이스 리소스들 및 성능들; (vi) 디바이스들 상에 상주하는 애플리케이션 프로그램들; (vii) 디바이스들 상의 로딩 애플리케이션 프로그램들; (viii) 상호운용성을 지원하기 위한 디바이스 리소스들을 제공하는 것과 관련된 비용들; (ix) 상호운용가능한 디바이스들의 파워 또는 에너지 관리; 그리고 (x) 디바이스들 사이의 연결들이 단속적이거나 신뢰할 수 없는 상호운용성 환경에서 실행하는 코드의 강력함의 이슈들을 포함한다. 또한, (xi) 상호운용성을 가능하게 하기 위하여 필요한 개발, 전개 및 테스팅 노력들의 범위; (xii) 심지어 상세한 상호운용성 표준들이 존재하는 독립적 으로 개발된 및/또는 분배된 상호운용성 성분들을 가지는 것에서 고유한 신뢰성 문제들; 및 (xiii) 높은 수준의 기술적 지식을 가져야만 하고 상호운용성을 관리하는 상당한 양의 시간과 노력들을 소비해야만 하는 최종 사용자들의 어려움; (xiv) 상호운용성 디바이스들, 데이터 그리고 콘텐트의 보안; (xv) 상호운용성 인프라구조에 대하여 행하여질 수 있는 크기, 성능, 파워 관리 및 비용 거래들이 추가적인 이슈들을 야기한다. 이들 이슈들은 아래의 추가적인 상세에서 강조된다.

콘텐트 적합에 대하여, 데이터, 애플리케이션 프로그램들 (애플리케이션들), 또는 제어를 한 디바이스로부터 다른 디바이스로 전송할 때 고려될 필요가 있는 사진 크기, 사용자 인터페이스, 컨트롤들 및 특별한 효과들, 콘텐트 포맷, 특징들 등과 같은 그러한 변수들(애플리케이션과 데이터 유형 의존)의 관점에서 콘텐트의 인텔리젼트 스켈링 또는 적합을 위한 필요가 있다. 이들은 집합적으로 "적합(adaptation)"으로서 언급된다. 콘텐트, 애플리케이션들 및 컨트롤을 공유할 때 적합의 세련됨이 좋을수록, 상호운용가능한 디바이스들의 집합이 더 크고; 각 디바이스에 대한 특징들이 더 진보될수록, 데이터, 정보 및/또는 다른 가능성이 더 효과적일 수 있고 애플리케이션들을 수행하기 위하여 디바이스들, 코드 데이터 및 콘텐트를 사용하는 것이 더 쉽다.

두 번째 운용가능성 이슈는 사용자가 일반적으로 콘텐트 포맷을 특정하거나 적어도 고려할 필요가 있을 수도 있다는 원치않는 요구로부터 생긴다. 다른 디바이스와 통신할 수 있을지라도 다른 디바이스와의 상호운용성을 원하는 사용자가 콘텐트 포맷 그리고/또는 다른 디바이스들이 콘텐트 포맷을 다루는 방법에 익숙하지 않 으면, 이 인자만이 상호운용성을 배제할 수도 있다.

세 번째 상호운용성 이슈는 상호운용성이 수행될 수 있기 전에 하나 이상의 디바이스들에 대하여 하나 이상의 특별한 목적의 드라이버들, 코드, 데이터 또는 콘텐트의 로딩을 특정하거나, 고려하거나 혹은 수행할 필요가 일반적으로 있을 수도 있다는 원치않는 요구로부터 생긴다.

네 번째 상호운용성 이슈는 사용자의 디바이스와 하나 이상의 다른 디바이스들 간의 통신에서 채용될 물리적 통신 메커니즘들 및 프로토콜들을 특정하거나, 고려하거나 혹은 수행할 필요가 일반적으로 있을 수도 있다는 원치않는 요구로부터 생기고, 상기 하나 이상의 디바이스들 각각은 통신 메커니즘, 프로토콜, 인터페이스 등을 가지거나 요구할 수도 있다.

다섯 번째 상호운용성 이슈는 어느 디바이스들이 사용자의 디바이스 또는 데이터 또는 요구되는 애플리케이션들과 상호운용하는데 필요한 가능성과 메모리, 프로세서 및 다른 특징들을 가질 것인지를 사용자가 고려하거나 선택할 필요가 있다는 원치않는 요구로부터 생긴다.

여섯 번째 상호운용성 이슈는 사용자가 일부 또는 모든 관련되고 잠재적으로 상호운용가능한 디바이스들에 상주해야만 하는 애플리케이션들을 특정하고, 고려하고 그리고/또는 로딩할 필요가 있을 수도 있다는 원치않는 요구로부터 생긴다.

일곱 번째 상호운용성 이슈는 하나 이상의 디바이스들 상에 코드, 데이터 또는 콘텐트의 누락, 소멸되거나 양립할 수 없는 버젼으로 인한 완전한 또는 부분적 애플리케이션 실패로부터 생긴다.

여덟 번째 상호운용성 이슈는 디바이스들이 제조시 또는 그들을 위한 필요가 생기기 전 일부 시간에 상주할 필요가 있거나 사용자에 의하여 일부 또는 모든 디바이스들 상에 명시적으로 로딩될 애플리케이션들을 수행하는 모든 코드를 가질 필요가 있다는 원치않는 요구로부터 생긴다.

아홉 번째 상호운용성 이슈는 상호운용하려고 하는 디바이스들 상에서 통신들 및 다른 프로토콜들 및 애플리케이션들을 수행하기 위하여 필요한 프로세서 또는 CPU 리소스들, 메모리 리소스들, 전자 게이트들 또는 로직, 또는 다른 물리적 인프라구조의 양을 제공하는 것과 관련된 재정적 비용으로부터 생긴다.

열 번째 상호운용성 이슈는 상호운용하고자 하는 휴대용 디바이스들을 위하여 필요한 배터리 수명을 연장하거나 배터리들의 크기를 감소시키기 위하여 효과적인 파워 또는 에너지 관리 방법학들을 제공하는 바람직함으로부터 생긴다. 단기간 상호운용성을 위하여 구체적으로 요구되지는 않았지만, 다른 디바이스들과 상호운용하는 것이 사용자들이 그 능력들을 거의 사용하지 않으려고 하거나 다른 사용자가 그들의 디바이스에 접속하는 것을 내키지 않아 하는 그러한 디바이스들에 대하여 그러한 배터리 파워 고갈을 생성하지 않도록 그러한 파워 관리는 매우 바람직하다.

열한 번째 상호운용성 이슈는 디바이스들간 연결들이 종종 끊기거나 일시적이고 신뢰할 수 없는 환경에서 계속 동작할 필요가 있는 애플리케이션들의 강력함 정도를 위한 필요로부터 생긴다. 예를 들어, 제2 디바이스와 상호운용하고 있고 통신하고 있는 제1 디바이스에 대한 애플리케이션을 수행하는 코드는 자체가 프리 즈(freeze), 행(hang)하지 말아야하거나, 그렇지 않으면 주요한 문제를 야기하거나 디바이스 자체가 프리징, 행잉하게 되거나, 제2 디바이스가 범위를 벗어나서 이동할 때 주요한 문제를 야기하거나 혹은 그렇지 않으면 제1 디바이스로부터의 통신에 응답하지 못하게 된다. 또한, 그러한 제2 디바이스가 신뢰성있게 다시 이용될 수 있게 되면, 상호운용성 애플리케이션을 수행하기 위하여 필요한 모든 코드, 데이터 및 콘텐트가 자동적으로 다시 저장되어 갱신되는 것이 바람직하다.

열두 번째 상호운용성 이슈는 현실적 및 미래 디바이스 필요성과 가능성들을 예간하는 그들의 능력 그리고 프로그래머들 또는 회로 설계자들이 완전하고 올바르게 이해하여 구현하고 그러한 구현들이 정확하게 전개되도록 하는 능력이 원래 약한 상호운용성 표준에 근거하여 디바이스들이 독립적인 제조자들에 의하여 제조되는 애플리케이션들의 비신뢰성으로부터 생긴다.

열세 번째 상호운용성 이슈는 그래픽들, 비디오, 사운드 등을 위하여 필요한 최적화들에 의존할 수 없는 실행 코드의 낮은 속도로부터 생긴다.

열네 번째 상호운용성 이슈는 사용자들과 공급자들 모두를 실망시키는 위에서 나열된 모든 이슈들로 인한 상호운용성을 위하여 채용될 수도 있었던 애플리케이션들과 디바이스들을 수행하는 상호운용가능한 코드, 데이터 및 콘텐트의 이용도의 부족으로부터 생긴다.

이들 열네 가지 상호운용성 이슈들은 생길수 있는 이슈들의 유형들 중 단지 예시적인 것으로서 완전한 리스트이거나 모든 상황들에서 생기는 이슈들을 구별하려는 의도는 아니다.

예를 들어, 제조시에 서로 상호운용하려고 의도한 두 개의 동일한 디바이스들 간의 상호운용성은 여기에서 설명된 이슈들 중 임의의 것 또는 모두에서 존재하지 않을 수도 있지만, 동종의 디바이스 상호운용성의 이 유형은 디바이스 사용자들이 오늘날 직면하는 더 일반적인 상황을 나타내지는 않고, 그리고 이종의 디바이스 상호운용성 이슈들을 강조하는 신중한 시도들은 불완전하였고, 매우 통찰력이 없었으며, 그리고 분명히 성공적이지 못하였다.

종래의 정적 그리고 절차적 솔루션 시도들

상호운용성 솔루션들을 제공하려는 종래의 시도들은 일반적으로 두 개의 카테고리들, 즉 (i) 정적 상호운용성 솔루션들 ('정적(static)') 또는 (ii) 절차적 상호운용성 솔루션들 ("절차적(procedural)")로 분류된다. 종래의 정적 솔루션들은 각 디바이스가 동일한 특정 통신 프로토콜들을 지원하도록 요구하고, 고정된 필드 레이아웃을 가진 특정의 단단하게 특화된 데이터 구조들을 전송한다. 정적 접근들에서, 의미론들, 코드, 그리고 디스플레이 능력들은 이들 디바이스들 간에 상호운용성이 확립될 수 있기 전에 모든 디바이스들 상에서 존재하여야만 한다. 각 콘텐트 유형, 애플리케이션, 또는 디바이스 능력은 알려지고, 이행되고 관련된 모든 디바이스들의 제조 시점에 설치되어야만 하거나; 또는 선택적으로, 사용자는 디바이스들, 소프트웨어 데이터 또는 콘텐트의 원하는 상호운용성을 시작하기에 앞서 요구되는 애플리케이션 프로그램들, 프로토콜들, 및/또는 드라이버들을 설치해야만 한다.

사용자가 훈련된 정보 기술 전문가가 아니거나 혹은 드라이버, 애플리케이 션, 구동시스템 부분, 프로토콜, 등의 사본을 알지 못하거나 갖고 있지 않을 때, 이용가능한 시간 내에 원하는 상호운용성을 제공하는 것이 불가능할 수도 있다. 또한, 정적 솔루션들로 특정 집합의 정적 솔루션들을 수행하는 것이 종종 필요하다.

예를 들어, 디지털 카메라와 텔레비젼 또는 표시장치(TV) 간 슬라이드쇼 능력을 가진 사진들의 집합의 공유는, 예를 들어, 슬라이드 이미지 데이터 및 슬라이드 명령 또는 순서 정보를 TV로 보내기 위한 블루투스 무선 능력과 같은, 공통의 정적 프로토콜을 요구했을 가능성이 있었다. 또한 그것은 그것이 다루는 방법을 아는 무언가로서 TV 상에서 인식될 슬라이드들 및 슬라이드 명령 정보를 위한 정적 콘텐트 포맷을 요구할 것이다. 그리고 특정 콘텐트 포맷을 가진 슬라이드 쇼를 제공하여 제어할 수 있는 적어도 하나의 정적 슬라이드 쇼 프로그램은 TV와 디지털 카메라 둘 모두에 존재하여야만 한다. 사용자는 이미지들 또는 사진들 및 슬라이드 명령 정보의 전달을 별도로 시작하여, 상기 정보를 TV 상에서 발견하여 연관시키고, 상기 TV 상에서 옳은 슬라이드 쇼 애플리케이션을 운용해야만 한다. 양 슬라이드들에서 정적 슬라이드쇼 프로그램들의 복잡도에 따라서, 디지털 카메라에 대한 제어들은 카메라에 대하여 시작되었던 TV 상에서의 슬라이드 쇼를 제어하기 위하여 사용되거나 사용되지 않을 수도 있다. 그러한 카메라에 근거한 제어가 가능하지 않는 곳에서 제어를 위한 일부 다른 메커니즘이 반드시 제공될 수도 있다. 정적 접근들은 상호운용할 수 있는 모든 디바이스 유형들의 제조시에 알려진 잘 이해되는 특정 애플리케이션들에 대하여 고도로 최적화된 솔루션들이다. 그러나, 정적 접근들은 알려질 모든 능력과 제조시 수행되는 습관, 제조후 오류들을 갱신하고 고정하기 위한 제한된 능력; 그리고 상호운용에 앞서 다른 디바이스들 상에서 동작하고 모든 디바이스들 상에 존재하도록 정적 프로그램 수행이 올바르게 그리고 완전하게 이식되어야한다는 종래의 요구를 포함하는 중요한 한계들을 가진다. 종종 이는 상호운용성이 요구되는 특정 애플리케이션들, 통신 매체들 그리고 원하는 디바이스들의 집합을 위한 특정 드라이버들의 로딩과 갱신에 의하여 달성된다.

정적 솔루션들이 이용가능할 때조차도, 다른 버젼들의 표준들 및 애플리케이션들의 불가피성으로 인하여 신뢰성이 제대로 발휘되지 못한다. 그러므로, 두 개의 디바이스들이 데이터 또는 절차들을 공유하기를 원할 때, 이들 디바이스들이 다른 버젼의 표준들을 고수할 때 또는 프로그램들이 다른 버젼의 표준들을 고수할 때, 또는 다른 버젼의 애플리케이션들이 상기 디바이스들에 상주할 때 실패(failure)가 일어날 수 있다. 추가적인 신뢰성 문제들은 부주의한 오류들 또는 상호운용하기 위하여 사용되는 표준들의 집합의 독립적 수행에서 이루어지는 지름길들로부터 생긴다. 그러한 표준들 수행들은 임의의 두 가지 수행들이 함께 작업하도록 시도할 때 예측할 수 없는 방향으로 상호작용할 수 있다. 일반적으로, 모든 디바이스들의 집합에 대하여, 특히 시작 디바이스가 상호운용해야만 하는 디바이스가 상기 시작 디바이스의 제조시 존재하지 않았던 모든 목표 디바이스들로서, 모든 표준 실행들의 모든 순열들을 테스트하는 것은 비현실적이거나 불가능하다.

정적 접근들에 대하여 더 중요한 한계들 중 하나는 N개의 디바이스들 또는 애플리케이션들을 상호운용가능하게 만드는 작업량이 디바이스들 및/또는 애플리케이션들의 수에 대한 값, N이 커짐에 따라 매우 빨리 성장한다. 제조업자들은 현재 늘 증가하는 디바이스들 및 애플리케이션들의 큰 집합에 대하여 상호운용가능한 디바이스들의 늘 제한된 크기의 집합들을 상호운용가능하게 하려고 시도하기 위하여 콘텐트 타입들, 애플리케이션 프로그램들 ("프로그램들"), 통신 프로토콜들 등을 위한 수백의 정적 표준들을 생성하는데 실패하고 있다. 이는 또한 모든 디바이스가 모든 원하는 상호운용가능한 디바이스들에 걸쳐서 모든 원하는 상호운용성 옵션들을 위한 모든 정적 솔루션을 지원하는 메모리, 스크린 사이즈, 제어들 및 프로세서 그리고 배터리 전원을 가지는 것을 요구한다. 그렇지 않으면, 실제 디바이스 및 애플리케이션 상호운용성은 달성되지 않는다. 이러한 종래의 문제와 한계를 더 잘 설명하기 위하여, 현재, 적합이 서로 다른 유형의 디바이스(N-1 디바이스들)를 공유해야만 하는 디바이스(N 디바이스들)들의 각 유형을 위한 소프트웨어 엔지니어링 개발 계획을 요구한다. 모두가 서로 상호운용하기를 원하는 N개의 디바이스 유형들의 보편집단에서, 고려하고, 개발하고, 수행하고 테스트해야할 N×(N-1)개의 접합들이 있기 때문에, 개발 관점으로부터, 이는 N×N 또는 N² 차수 문제이다.

더욱이, 디바이스들의 수가 증가하고 요구되는 적합들이 N²개쪽으로 상승함에 따라, 양질 제품을 얻는 비용과 어려움이 전체 복잡도의 증가로 인하여 더 빠른 속도로 증가하려는 경향이 있다. 이는 높은 신뢰성과 높은 품질의 소프트웨어 및 하드웨어 솔루션들을 얻는 어려움이 전체 복잡도가 증가함에 따라서 증가하기 때문이다. 이는 순전히 "소스 코드의 크기" 이슈가 아니지만, 거동의 불예측성, 사건들의 불예측성, 알려지지 않은 미래 능력들 등을 포함하여, 함께 작업하는 다른 제조 업자들로부터 디바이스들을 얻으려고 시도할 때 지배적인 인자들의 종류에 단지 기인한다.

예를 들어, 디바이스들의 수가 5개에서 6개로 증가함에 따라서, 상호운용성 접합 요구들은 N×(N-1)의 관계에 따라서 20개에서 30개까지 증가한다. 그리고 이의 증가에 따라서 프로젝트의 전체 복잡도는 더 빨리 성장하였다.

함께 작업하기 위한 N개의 디바이스를 얻는 것이 실질적으로 N²개의 적합들을 요구하는 이러한 N-제곱 차수 문제는 도 1에 예시되어 있다. 정적 접근을 이용한 종래의 디바이스간 협력은 사용하려는 사용자를 위하여 비교적 간단할 수도 있지만 높은 정도의 개발, 관리 및 전개 노력 그리고 구형 디바이스들, 애플리케이션들, 그리고 데이터 유형들 간, 그리고 새로운 디바이스들, 애플리케이션들, 그리고 데이터 간 정합성과 상호운용성을 유지하기 위한 계속적인 업데이트를 요구할 수도 있다는 것이 이해될 것이다.

도 2를 참조하면, 56개의 적합들과 추가적인 56개의 테스트 절차들을 요구하는 무식한 반복 접근을 이용하여 디바이스간 협력을 위한 상호작용들 또는 단지 8개의 디바이스 유형들을 위한 제한된 상호운용성이 도시되어 있다.

무식한 반복 방법의 N개의 문제와는 별도로, 대부분의 정적 접근들 또한 많은 표준 또는 표준들 노력들을 결합하는 것을 포함한다. 마이크로소프트가 처음으로 시도한 UPnP (Universal Plug and Play) 접근은 아마도 정적 접근들 중 가장 큰 지지자와 범위를 가진다. UPnP는 정적 (비-절차적인 것을 근거로 하는) 표준들의 집합을 결합하여 각각이 다른 XML 또는 데이터 구조 기반 설명을 갖는 디바이스들과 서비스들의 모든 다른 류들을 열거하려고 시도하므로써 디바이스 상호운용성과 관련된 일부 문제들을 해결하고자 하는 정적인 비절차적 접근이다. 그러나, UPnP 접근법 조차도 일부가 아래에서 간략하게 설명되는 중요한 제한들을 겪는다.

먼저, UPnP는 운용하기 위하여 모듈들 및 코드, 전력, 그리고 메모리의 큰 집합을 요구한다는 점에서 무겁다. 이는 매우 작은 프로세서, 아주 작은 랜덤 액세스 메모리, 작은 배터리 용량을 가질 수 있는 얇은 저비용 배터리 전원공급디바이스들을 위하여 부적합하게 한다.

두 번째로, UPnP는 콘텐트 또는 특성 최적화 능력을 거의 제공하지 않는다. UPnP는 일반적으로 한 사이즈 애플리케이션, 콘텐트, 또는 사용자 인터페이스가 모든 관련 디바이스들 상에서 잘 작동할 것이라고 가정한다. 이는 마이크로소프트 윈도우 기반의 데스크탑 퍼스널 컴퓨터들(PC들)의 경우 십년 전에는 타당한 가정이었을 수도 있지만, 다음 수십년 내에 생기는 하이브리드 및 다양한 전자 디바이스들의 유사 집합을 언급하지 않아도, 상호운용해야만 하고 호출기, 디지털 카메라 및 퍼스널 컴퓨터만큼 다른 디바이스들로 가득찬 세상에서 동작을 위한 빈약한 가정과 토대이다.

세 번째로, UPnP는 제한된 집합의 사용자 인터페이스들을 제공하고, 이들 사용사 인터페이스들은 지금 이용가능한 다양한 디바이스들의 큰 집합의 필요들을 충족시키지 못한다.

네 번째로, UPnP는 디바이스들이 사용될 수 있기 이전에 모든 디바이스들에 상주하는 요구된 작업을 수행하기 위하여 필요한 프로그램들과 드라이버들을 요구한다.

다섯 번째로, UPnP의 의도는 적어도 부분적으로는 N-제곱의 (N²) 문제를 피하기 위한 것이지만, 복잡한 표준들의 독립적 수행들의 모든 순열들이 신뢰성 있는 상호운용성으로 귀결되기 위해서라면, 현실은 UPnP를 상호운용성을 위한 토대로서 의 사용이, 위에서 설명된 것처럼, 대량의 N-제곱의 (N²) 개발/개발/테스팅 노력을 여전히 요구하여 모든 상호운용성 디바이스들을 위하여 이식되고, 배포되고 그리고 시험될 프로그램들, 코드, 데이터 및 콘텐트를 요구하는 새로운 애플리케이션들을 초래하게 할 것이라는 것이다.

여섯 번째로, 동일하거나 적어도 양립할 수 있는 버젼들 및 업데이터들이 동시에 전개되도록 UPnP 프로그램들, 디바이스들, 콘텐트 및 표준들은 모두가 동기화되어야만 한다.

일곱 번째로, 디바이스들 및 콘텐트 능력들이 발전함에 따라서, 존재하는 UPnP 프로그램들, 데이터 및 콘텐트 기반의 디바이스들은 새로운 디바이스를 지원하지 못하는 경향이 있다.

여덟 번째로, 존재하는 디바이스, UPnP를 포함하는 표준들, 그리고 애플리케이션 버젼들의 정합성을 유지하는 비용들은 전체 프로젝트 복잡도를 더욱더 빨리 증가시킨다.

아홉 번째로, 표준들-정적-근거한 접근으로서 UPnP의 복잡도와 다양성에서 고유한 문제들로 인하여 프로젝트 복잡도가 증가할수록, 사용편의성 및 신뢰성은 퇴화한다.

열 번째로, 특히 이 데이터 또는 이들 데이터 구조들이 2진 표현들보다 상당히 더 많은 전송 대역폭과 시간을 요구하는, 사람이 읽을 수 있는 텍스트 포맷으로 표시되는 디바이스들 사이에 전송되는 하나 또는 많은 데이터 구조들을 가질 빈번한 필요에 의하여 부여되는 요구들을 UPnP는 여전히 강조하지 않을 것이다. 또한, 디바이스들 간에 전송될 데이터 구조들 중 많은 것들은, XML을 위하여 요구되는 CPU의 광범위한 파 동작을 수행하기 위하여 XML포맷의 사용이 상당히 더 많은 CPU 동작들, 메모리, 및/또는 소프트웨어 프로그램 코드 사이즈를 요구하는 곳에서 2진 또는 덜 일반화된 포맷보다는 오히려 XML, 인간이 읽을 수 있는 텍스트 포맷으로 표현된다.

마지막으로, 디바이스 및 애플리케이션 상호운용성에 대한 종래의 정적 접근들에 의하여 부가되는 몇몇 한계들에 대하여 상대적으로, 정적 표준들은 종종 표준들 기반의 수행들의 전체 복잡도 및 크기를 감소시키기 위하여 프로토콜들, 콘텐트 타입들 및 애플리케이션 타입들의 수를 제한한다. 예로는 UPnP만이 TCP/IP를 기본 통신 프로토콜로서 허용하는 것이다. 이는 블루투스, USB, MOST, 그리고 IR과 같이 다른 중요한 현존 통신 프로토콜들과, 다른 모든 비-TCP/IP 프로토콜들의 효율적 사용을 효과적으로 감소시킨다.

종래의 절차적 솔루션 시도들

정적 표준들 접근에 대한 대안은 절차적 표준을 생성하는 것에 의존한다.

하드웨어에서 실행되거나 소프트웨어에서 에뮬레이트되는 절차적 표준들 기술들은 유비쿼터스(ubiquitous)이다.

많은 수의 하드웨어 마이크로프로세서들이 존재하고, 이들 각각은 문제들의 다른 클래스들에 대하여 최적화된 명령 집합과 인터페이스들을 가지며, 그리고 수 많은 더 높은 레벨의 소프트웨어 에뮬레이트된 명령 집합들과 환경들이 존재하고, 이들은 특정 태스크 집합들 주위에서 최적화된다. 예를 들어, 이들은 Java (프로그래밍의 휴대성과 쉬움을 위하여 일반적으로 최적화된 접근), PostScript (인쇄된 페이지들과 프린터 제어기능들을 표시하도록 일반적으로 최적화된 접근), 그리고 Storymail Stories (풍부한 멀티미디어 메시지들의 매우 넓은 범위를 효율적으로 표시하기 위하여 일반적으로 최적화된)를 포함한다. Java와 PostScript는 컴퓨터 기술들에서 잘 알려진다. Storymail Stories, 관련 시스템들 및 방법들의 측면들은, 예를 들어, 발명의 명칭이 "Hardware Architecture, Operating System And Network Transport Neutral System, Method And Computer Program Product For Secure Communications And Messaging"이고 발명자들이 Michael L Wenocur, Robert W. Baldwin, 그리고 Daniel H.lllowsky인 2003년 1월 9일에 공개된 미국특허출원 공개번호 20030009694 A1; 발명의 명칭이 "Secure Certificate And System And Method For Issuing And Using Same"이고 발명자들이 Michael L Wenocur, Robert W. Baldwin, 및 Daniel H.lllowskyin인 2002년 11월 7일에 공개된 미국특허출원 공개번호 20020165912 A1; 그리고 다른 특허 출원들에서 설명된다.

절차적 상호운용성 접근법들은 전형적으로 상호운용하고자 하는 모든 디바이스들 상에 공통의 실행시간 환경을 구축하거나, 그렇지 않으면 가지거나 제공하는 것을 포함하고, 그 결과 프로그램들, 절차들, 데이터 및 콘텐트가 정적 데이터 구조들 및 정적 애플리케이션들 외에도 디바이스들 사이에서 전송될 수 있다. 현재 하나의 선도적인 상호운용성 절차 솔루션은 자바 플랫폼이고, 그에 대한 JINI 익스텐션들(extensions)이 함께 사용된다. 자바 기반의 절차적 접근법의 예로서는, 자바로 작성된 슬라이드쇼는 사진들과 슬라이드 명령 또는 순서 데이터를 캡슐화하거나 참조부호를 달수 있을 것이고, 다른 디바이스에 응답지령신호를 보낼 수 있을 것이고, 콘텐트를 다른 디바이스에 적합시킬 수 있을 것이고, 정보와 자바 슬라이드쇼 프로그램을 TV에 보낼 수 있을 것이다. 예전에 TV에 존재하지 않았다면, 자바 슬라이드쇼 프로그램은 제조후 카메라에 탑재될 수 있을 것이고 자바 가능 TV와 상호운용성을 가능하게 할 수 있을 것이다.

자바가 널리 전개되었고 대응적으로 제한된 상호운용성을 제공하는데 있어서 일부 제한된 성공을 거두었지만, 광범위한 사용, 특히 비용, 전력 효율, 프로세서 효율, 프로그램 코드, 데이터를 저장하기 위한 메모리 효율 및 임시 버퍼들이 매우 중요한 이슈들인 작은 휴대용 디바이스들을 위한 광범위한 사용을 방해하였던 심각한 결함들을 가진다. 또한, 다른 디바이스들 상에서 동작하는 애플리케이션들의 2진 정합성에 대한 자바 버츄얼 머신(Java Virtual Machine, VM) 접근은 디바이스들이 존재하는 정당한 이유와 충돌한다. 자바와 다른 종래의 절차적 상호운용성 접근들은 여러 한계들을 가진다. 다섯 가지 예시적 한계들이 아래에서 설명된다.

첫 번째는, 자바 버츄얼 머신 접근이 동일한 2진 코드 (자바 2진 코드)로 하여금 모든 디바이스들 상에서 동작하도록 하기 위하여 모든 디바이스들이 애플리케이션들에 대하여 정확하고 동일한 버츄얼 컴퓨터처럼 보이도록 하거나 적어도 보이도록 하기 위하여 시도한다. 2진 정합성을 유지하기 위하여, 버츄얼 머신 정의와 실행의 일부로서 사전정의되지 않았던 디바이스 능력들에 접근하기 위한 시도들을 회피하는 것이 필요하다. 이처럼, 2진 정립성은 원래의 기능들이 공통의 버츄얼 머신 정의의 일부가 아닌 임의 디바이스의 능력들에 접속하기 위하여 필요하면 다수의 디바이스들에서 잃어버린다. 대부분의 PC가 아닌 디바이스 하드웨어 및 소프트웨어는 특별한 목적, 폼 인자, 가격점, 사용자 인터페이스 또는 기능성을 위하여 대부분이 종종 특별하게 되거나 최적화되므로, 그것은 종종 그들의 기본적인 독특한 원래 기능들 또는 능력들이 대부분 그 디바이스를 위하여 종종 목표로 하는 애플리케이션들을 위하여 접속되어져야만 하는 경우이다. 이는 디바이스들 모두를 애플리케이션에 대하여 동일하게 보이도록 하는 디바이스들 간 차이들을 숨기는 자바 버츄얼 머신 접근에 카운터를 운용한다.

두 번째로, 자바는 효율적 실행 및 효율적 메모리 사용 비용으로 프로그래밍의 쉬움을 위하여 최적화된 일반적 목적의 언어이다. 그러므로, 자바는 소규모의 처리 능력들과 작은 이용가능한 메모리를 갖거나 비용이 중요한 많은 얇은 디바이스들을 위한 가장 효율적이고 효과적인 솔루현은 아닐 것이다.

세 번째로, 멀티미디어 콘텐트 응답 시간들은 자바 절차적 접근을 이용하여 확실하게 될 수 없다. 대부분의 자바 프로그램들은 메모리 단편화를 일으키는 변화 하는 크기의 메모리 구조들의 빈번한 할당 또는 분리배정에 대하여 매우 의지한다. 이 메모리 단편화는 종종 메모리 내에서 가비지(garbage) 수집을 수행하는 동안 디바이스내의 프로세서가 콘텐트를 렌더링하는 것을 멈추어야만 할 때 주기들로 이끌린다. 이것이 발생할 때 사용자들은 종종 오디오 및 비디오 렌더링의 매끄러움의 분열을 경험할 것이다. 네 번째로, 자바는 충분한 속도와 크기 이슈들을 제공한다. 자바와, 상호운용성을 위하여 필요한 자바관련 기술들 및 라이브로리들은 상대적으로 아주 중요하고 실행을 위한 비교적 큰 수의 CPU 사이클들과 저장을 위한 비교적 큰 양의 메모리를 요구한다. 사용자 인터페이스들, 멀티미디어 렌더링, 디바이스 목록, 강력한 크로스 플랫폼 디바이스 상호운용성, 다른 유형들에게 보내는 코드 및 데이터의 동적 적합을 포함하는 자바로 작성된 상호운용성 프로그램들은 작성되고 교환될 많은 양의 코드를 요구하는데, 이는 이들 기능들 모두가 라이브러리들, 또는 특별한 목적의 자바 코드 순서들을 이용하여 구성되어야만 하기 때문이고, 이들 동작들 전부는 자바 명령 집합 또는 환경에 고유시스템용으로 만들어지지 않기 때문이다. 상호운용성을 위한 자바 프로그램들은 크고 느려서 제한된 프로세서 파워, 배터리 수명 또는 비용이 중요한 이슈들인 디바이스들에서 이러한 자바 프로그램들의 사용을 제한하는 결과로 된다. 디바이스들이 충분한 리소스들을 갖지 않는 곳에서, 자바 기반 상호운용성 솔루션은 가능하지 않다.

다섯 번째로, 자바는 적어도 상호운용성을 위한 제한되고 불완전한 베이스 실행을 제공한다. 이는 많은 수의 라이브러리들이 상호운용하려는 모든 디바이스들 상에 존재하도록 하거나 필요한 프로그램 코드를 포함하는 서버들에게 고속의 항상 연결을 가지도록 한다. 자바의 베이스 명령 집합에 포함되지 않은 동작들을 위한 성능은 자바 언어 자체로 제공되어야만 하고, 그렇지 않으면 이들 동작들을 실행하기 위하여 사용되었을 네이티브 코드의 그것에 대한 실행시간 성능을 크게 제한한다. 누락한 상호운용성 베이스 동작들은 (i) 멀티미디어 애니메이션 재생; (ii) 프로그램들, 데이터, 콘텐트, 사용자 인터페이스 또는 다른 디바이스들을 목표로 하는 제어들의 적합; (iii) 콘텐트를 시작한 디바이스들이 자동적으로 그리고 쉽게 상호운용성 프로그램들을 가진 콘텐트와 결합할 수 있도록 주문 프로그램의 컴퓨터 생성; (iv) 매우 다양한 프로토콜들에 대한 디바이스, 서비스 및 리소스 발견; (v) 다른 디바이스들에서 운영되는 프로세스들의 동기화 및/또는 연재; (vi) 디바이스 전원관리; (vii) 디바이스들이 단속적으로 그들의 연결들을 잃고 다시 얻을 때 애플리케이션과 동기화 회복을 위한 네이티브 지원을 포함한다.

종종 자바 VM 명세가 디바이스들 또는 애플리케이션들의 클래스를 위하여 부족한 것으로 판명될 때, 새로운 자바 VM 명세가 이 새로운 클래스의 디바이스들의 알려지지 않은 네이티브 지원 필요들을 강조하기 위하여 생긴다; 그러나 하나의 VM을 위하여 작성된 자바 프로그램들은 일반적으로 다른 VM 명세들에 들어맞는 디바이스들과 2진 양립하지 않거나 상호운용할 수 없다. 자바 VM 명세들은 J2ME, MIDP 1.0, MIDP 2.0, 그리고 CDC를 포함하여 다양한 디바이스들 클래스들을 위하여 존재하지만, 더 상호운용될 수 없는 자바 VM 명세들과 실행들의 이러한 증식은 자바 VM들의 사용을 통하여 심지어 작은 정도의 상호운용성을 달성하는 어떤 형태의 타입들의 단편화 그리고 프로그램들 및 디바이스들의 형태들을 계속해서 야기한다.

Xerox Palo Alto Research Complex (PARC)는 그들이 "Obje"라고 부르는 자바 플러스 Jini 상호운용성 기술들의 변화를 공표하였다. Obje는 명확히 자바를 기반으로 하거나, 대안으로서, 특정되지 않고 실현되지 않은 유사한 버츄얼 머신 기반 기술이다. Obje가 효과적으로 디바이스들을 조직하고 모든 디바이스들이 모든 머신들 상에 이식되거나 상주되는 프로그램들을 가지는 요구들을 제거하기 위하여 필요한 절차적 방법학들을 제공하는 몇 가지 방법들을 지적하지만, Obje 실행들은 사용될 절차적 베이스를 위한 자바 VM 모델로부터 일탈을 나타내는 상세들을 제공하지 않기 때문에 자바 플러스 Jini로서 유사한 능력들과 한계들을 가질 것이다.

또 다른 절차적 접근인 PostScript는 상당한 시간 동안 주위에 있었고, PostScript 문서들과 PostScript 프린터들 사이에서 높은 정도의 상호운용성을 구축하는데 매우 효과적이었던 인쇄된 페이지 설명 언어를 제공한다. PostScript 문서들은 프린터 내부의 PostScript 소프트웨어 엔진 상에서 실행될 때, 동작하고 있다는 것을 깨달은 프린터 상에서 가능한 최고 해상도의 장점을 취하면서, 하드웨어 프린터 엔진을 제어하고 인쇄된 페이지들의 이미지를 재생성하는 프로그램들이다. PostScript는 문서들과 프린터들의 상호운용성으로 크기 제한된다. 이러한 제한에 대한 이유들 중 일부는 PostScript 문서들이 인간이 읽을 수 있는 텍스트로 표현된다는사실을 포함한다. 이는 2진 프로그램들에 대한 문서들과 프로그램들의 크기를 크게 넓힌다. 텍스트는 프로그램들이 사용중일 때 파싱 동작을 요구하여 더 많은 프로세서 사이클들을 요구하고 이후 프로그램들이 2진수로 표현되었으면 스크래치 메모리가 필요하게 될 것이다. 또한, PostScript는 (i) 멀티미디어 비디오/오디오/ 애니메이션 녹음재생; (ii) 애플리케이션, 데이터, 콘텐트, 사용자 인터페이스 또는 다른 디바이스들을 목표로 하는 제어들의 적합; (iii) 디바이스, 서비스 및 리소스 발견; (iv) 다수의 디바이스들에서 사용중인 프로그램들의 동기화 및 연재; (v) 디바이스 전원 관리; (vi) 다른 디바이스들을 찾아서 사용하기; (vii) 디바이스들 간 강력한 연결을 유지; 또는 (viii) 현재 디바이스들에서 공통인 공통 플래시 메모리를 포함하는 다양한 저장 매체들에게로 효율적인 접속을 위한 상당한 네이티브 지원을 제공하지 않는다.

Storymail 스토리들은 멀티미디어 메시지들을 캡슐속에 넣기 위하여 설계된 가변적 길이의 절차적 명령 집합을 제공한다. Storymail 스트리들 그리고 관련 시스템들 및 방법들의 측면들은, 예를 들어, 2003년 1월 9일에 공개되었고 발명의 명칭이 Hardware Architecture, Operating System And Network Transport Neutral System, Method And Computer Program Product For Secure Communications And Messaging이고, 발명자가 Michael L Wenocur, Robert W. Baldwin, 그리고 Daniel H.lllowsky인 미국특허출원 공개번호 20030009694 A1; 2002년 11월 7일에 공개되었고 발명의 명칭이 Secure Certificate And System And Method For Issuing And Using Same이고, 발명자가 Michael L Wenocur, Robert W. Baldwin, 그리고 Daniel H.lllowsky인 미국특허출원 공개번호 20020165912 A1; 그리고 다른 특허 출원들에서 설명된다.

Storymail 스토리 구조를 포함하는 Storymail 발명과 관련 기술들은 본 특허의 발명자와 동일한 발명자인 DanielIllowsky에 의하여 발명되었다. 이러한 Storymail 명령 집합은 코드변환된 멀티미디어 콘텐트가 그 전에 먼저 알려진 멀티미디어 콘텐트 표시들에 대하여 상당한 장점들을 제공하였던 "Stories"라고 불리는 보편적 절차 포맷으로 표시되도록 한다. 그러나, Storymail 기술들은 디바이스들간 상호운용성 이슈들을 충분히 강조하지 못하였고 누군가 디바이스가 상호운용성을 달성하기 위한 Storymail 기술을 적용하려고 시도하였다면, 일부 문제들과 한계들은 재빨리 드러나게 되었을 것이다. 첫 번째로, Storymail 명령 집합은 많은 스크래치 메모리의 사용을 요구하는 작은 엔진 크기를 위하여 최적화된다. 두 번째, Storymail 명령 집합은 콘텐트를 사용하는 동안 특별하게 된 스레딩 모델의 실행에는 부담이다. 세 번째, Storymail Stories는 JPEG 또는 비트맵 이미지들과 같이, 심지어는 기본적 콘텐트 유형들의 코드변환을 요구한다. 네 번째로, Storymail Story 기술은 디바이스, 서비스 또는 리소스 발견을 위한 네이티브 지원을 제공하지 않는다. 다섯번째로, Storymail Story 기술은 다수의 디바이스들에서 사용되는 프로그램들의 동기화를 위한 네이티브 베이스 지원을 갖지 않는다. 그러므로, Storymail 기술과 유니버설 절차적 미디어 포맷이 종래의 기술에 비하여 상당한 진전을 제공하였더라도, 전자 및 컴퓨터 기술들에서 이제는 명백해진 디바이스들 간 상호운용성 이슈를 만족스럽게 해결하지 못하고 있다.

그러므로, 정적 그리고 현재의 절차적 접근들 모두는 만족스러운 디바이스간 상호운용성, 특히 이종 디바이스들과 선행의 미지의 애플리케이션들을 위한 만족할만한 상호운용성을 제공하지 못한다는 것이 분명해질 것이다. 이 문제는 현재의 클라이언트-서버 및 피어-투-피어(peer-to-peer) 디바이스간 상호운용성 모델들이 고 려될 때 더 복잡해진다.

종래의 클라이언트-서버 및 피어-투-피어 모델들

현재의 기술상태에서, 다수의 디바이스들에서 실행되는 상호운용 프로그램들은 일반적으로 클라이언트-서버 모델 또는 피어-투-피어(peer-to-peer) 모델 중 어느 하나를 사용한다.

클라이언트-서버 환경 모델에서, 하나의 디바이스(즉, 서버)는 서비스를 제공하고 다른 디바이스(즉, 클라이언트)는 서비스를 사용한다. 이는 다수의 클라이언트 디바이스들로 하여금 데이터를 저장하고 처리하기 위한 하나의 더 잘할 수 있는 서버 디바이스의 장점을 취하도록 하고, 반면에 더 가벼운 클라이언트 디바이스는 요구하고 결과들을 표시하기에 충분히 강력해질 필요가 있다. 클라이언트-서버 접근의 한계는 일반적으로 서버가 네트워크 상에 등록되어야만 하고 상대적으로 높은 속도의 연결로 클라이언트들에 항상 접속할 수 있어야 한다는 것이다.

피어-투-피어 환경 모델에서, 임의의 상호운용성 디바이스는 일반적으로 애플리케이션을 수행하는데 필요한 모든 수단들을 가지는 것으로 가정된다. 또한, 피어-투-피어 모델에서, 일반적으로 상호운용하는 모든 디바이스들이 적절한 결합과 프로토콜들에 동의할 수 있도록, 이들 디바이스들은 연결을 구축하기에 앞서 채용될 프로그램들 또는 서비스들의 지식을 가져야만 한다. 애플리케이션을 수행하기 위한 충분한 능력을 가져야만 하는 것과, 모든 상호운용성 디바이스들 상에 사전존재하는 피어드(peered) 프로그램 프로토콜 레이어들을 가질 필요는 피어-투-피어 모델을 디바이스 상호운용성에 적용하는데 있어서 중요한 제한들이다. 실제로, 피 어-투-피어 디바이스들은 종종 불완전한 실행들을 다르게 하는 것의 예측불가능한 반복들로 인하여 협력하지 못하게 될 소프트웨어의 다른 불완전한 실행들 또는 버젼들을 종종 만나게 될 것이다. 이들 문제들을 정정하기 위하여, 종종 드라이버들 또는 다른 소프트웨어는 업데이트, 배포 및 설치되어야만 한다. 이는 종종 상호운용성 문제들을 정정할 수 있지만, 실패와 관련된 관리, 실행, 배포 및 장애 그리고 이들을 고정하는데 필요한 복잡성, 세련도 및 시간이 피어-투-피어 기반 디바이스 상호운용성의 심각한 문제로 남는다.

퍼스널 컴퓨터들의 세상에서, 제한되지만 현재 가장 인기있는 상호운용성 플랫폼은 마이크로소프트^TM 동작 시스템이다. 마이크로소프트윈도우^TM 하에서, 이론적으로 임의의 애플리케이션 2진 이미지는 PC가 IBM, 도시바, 샤프, 델 또는 다른 제조업자에 의하여 제조되었는지에 상관없이, 마이크로소프트윈도우^TM 동작 시스템을 운용하는 임의의 표준 PC 아키텍쳐 디바이스 상에서 운용될 수 있고 사용될 수 있다. 그러나, 실질적인 사항들에서, 마이크로소프트 윈도우 조차도 실제 세상의 동작 환경들에서 상호운용성의 한계들을 가진다.

컴퓨터 디바이스들과 정보 기기들이 범용의 일반적 목적의 퍼서널 컴퓨터 모델로부터 휴대폰들, 휴대용 음악 재생기들, 원격 제어들, 네트워킹가능한 미디어 플레이어들 및 라우터들, 그리고 일련의 다른 디바이스들과 같이 더 특정한 특수 디바이스들로 분화됨에 따라서, 모든 (또는 적어도 대부분의) 디바이스들에 걸쳐서 2진 정립될 수 있을 뿐만아니라 각 디바이스의 리소스들에 근거를 둔 다수의 프로 토콜들에 대하여 on-the-fly 디바이스들의 ad-hoc 팀을 형성할 수 있는 애플리케이션들의 빠르고 효율적인 개발을 허용하는 애플리케이션 플랫폼에 대한 필요가 있다. 하나의 디바이스가 그 자신 상에서 실행되는데 필요한 모든 소프트웨어, 하드웨어 또는 다른 리소스들을 갖지 않는 애플리케이션들은 수행을 위하여 모든 디바이스들에 걸쳐서 그들의 실행을 스프레드할 필요가 있다.

현재 이 기술의 상태에서, 다수의 디바이스들에 걸쳐서, 특히 상기 스프레드될 디바이스들이 다양한 유형들로 이루어지고 이종의 디바이스 하드웨어, 소프트웨어, 그리고 동작 시스템(가령 있다 하더라도) 특성들을 가질 때, 자신들을 운용하고 스프레드할 수 있는 프로그램들을 생성하기 위한 효과적인 소프트웨어 플랫폼이 없다. 수많은 표준화된 임베디드 동작 시스템들이 있더라도, 디스플레이들과 제어들의 배열을 포함하는 디바이스의 독특한 능력들과 특징들에 접근하기 위한 애플리케이션들에 대한 필요 때문에, 또 다른 디바이스 상에서 운용되면, 양 디바이스들이 동일한, 임베디드 동작 시스템 및 프로세서를 사용하더라도, 하나의 디바이스를 위하여 내장된 프로그램이 이용될 기회는 아주 적다. 이처럼, 이제까지 알려진 선행기술 디바이스와 방법학들의 단점들과 결점들을 회피하면서, 신뢰성있고 사용하기 쉬운 디바이스, 애플리케이션 프로그램, 데이터 및 콘텐트 상호운용성을 제공하기 위한 개선된 방법 및 시스템을 위하여 이 기술에서 큰 필요가 있다.

본 발명은 지금까지 이 기술의 현재 상태에서보다 디바이스 및 시스템 상호운용성을 더 간단하게, 더 신뢰성있게, 더 활발하게, 더 강력하게, 더욱 비용 효과적이게 그리고 더 확실하게 하는 수많은 발명 시스템들, 디바이스들, 장치들, 컴퓨터 프로그램들 및 컴퓨터 프로그램 제품들, 절차들 및 방법학들을 포함한다. 채용된 기술은 절차적 상호운용성 기술들에 기반을 둔다. 본 발명은 중요하고 심오한 방법들이라는 점에서 존재하는 절차적 상호운용성 기술들과는 다르다. 동일한, 실행가능한 2진 이미지가 모든 디바이스들에서 운용될 수 있도록 현존 기술들은 디바이스들간 차이들을 숨기려고 하는 반면에, 본 발명은 그룹 내의 모든 디바이스들이 하나의 디바이스였던 것처럼 디바이스들의 그룹들에 걸쳐서 애플리케이션이 디바이스들의 ad-hoc 그룹들을 형성할 수 있고 효과적으로 그의 실행을 스프레드할 수 있도록 디바이스들의 자산들 모두에게 접속을 축하하고 제공한다.

대부분의 존재하는 상호운용성 기술들은 신뢰할 수 있는 고속망들상에 항상 연결되어 있고, 거의 재구성되지 않는 협력 또는 정부 망들에서 강력한 일반적 목적의 컴퓨터들을 위하여 수년에 걸쳐서 개발된 기술들의 연장으로서, 앰플 파워(ample power)에 대한 연속적인 접근을 가지고 훈련된 풀-타임 전문가들에 의하여 구성되고 유지된다. 이들 기술들은 이제는 이용할 수 있게 된, 모빌, 배터리 전원을 받는, 단속적으로 연결되고 비용 억제된 디바이스의 상호운용성에 적용될 때 기대에 미치지 못하고, 훈련받지 않은 개인들이 사용하거나 자신들을 상호운용성을 위하여 필요한 소프트웨어와 하드웨어를 구성하고 유지하는데 오히려 관여시키지 않으려고 한다.

본 발명은 필수적으로 간단함, 강력함, 비용 효율적, 이제는 점증율로 시장에 진입한 모바일 및 다른 특수 목적의 디바이스들의 상호운용성의 효율과 보안을 크게 진전시키기 위하여 함께 작업하는 방법학들의 새로운 소프트웨어 에코시스템(ecosystem)을 포함한다.

도 3은 자체가 상호운용성 플랫폼의 한 형태이고, 집합적으로는 DartPlatform이라 불리는 본 발명의 새로운 절차적이고 소프트웨어적 에코시스템의 실시예의 예시적 부분들을 보여준다. 소스, 여기서 DartSource(100)는 애플리케이션의 의도를 수행하는데 필요한 모든 코드, 데이터 및 콘텐트를 포함한다. DartSource는 DartTool들(200)에 의하여 2진수의 실행가능한 애플리케이션 패키지로 처리되는데, 이 패키지는 DartSource에 의하여 최초로 특정된 상호운용성 애플리케이션의 목적을 수행하기 위하여 필요한 모두를 캡슐 내에 넣는다. 상기 패키지의 2진 이미지는 DartFormat(300)에 맞추어진다. 캡슐내에 넣어진 애플리케이션들은 Dart들로 불리는데, 이들은 하나 이상의 DartDevice들(400)상에서 실행될 것이다. 이식된 DartEngine(600)을 포함하는 네이티브 코드 실행가능한 프로그램인 DartPlayer를 운용하고, 다른 DartDevice들과 통신하기 위한 적어도 하나의 통신 프로토콜(401)을 갖는 임의 디바이스는 자체가 Dart들을 운용할 수 있는 DartDevice로서 그들의 결합된 능력들과 리소스들을 사용하는 다른 DartDevice들까지 걸쳐서 그들의 실행을 연장할 수 있다. 도 4는 예시적인 DartDevice(3000)를 보여준다. 상부에는 디바이스(3000) 상에서 운용되는 세 개의 다트(Dart) 애플리케이션들(3001)이 도시되어 있다. 이들 다트들의 코드는 DartTool들에 의하여 생성되었고 (도 3의 200을 보라), 그의 개별적인 동작들이 DartEngine(3010)의 휴대용 부분과 디바이스 특정 부분, 하드웨어 앱스트랙션 레이어(Hardware Abstraction Layer (HAL)) (3020)에 의하여 안전한 방법으로 수행되는 본 발명의 DartInstructionSet에 적합하게 되었다.

DartEngine에 의하여 수행되는 DartlnstructionSet 동작들은 암호화 동작들, 그래픽들 및 텍스트 처리와 같이 상호운용성을 위하여 필요한 프로세서의 집중적인 동작들을 포함한다. 아울러, 본 장에서 뒤에서 보다 상세하게 설명될 집중적인 상호운용성 방법론들을 위한 엔진에서의 지원이 내장되어 있다. HAL은 디바이스의 특정 특징들과 그의 기능성을 판단하기 위한 다트의 PROFILE~INSTRUCTION 명령들을 통하여 접근되는 프로파일 방법을 포함한다. HAL은 또한 그들이 존재하는 공통의 다트 표준 하드웨어 기능들에 접근하는 엔진을 위한 방법들을 제공한다. 실행이 다른 디바이스들까지 연장되는 다트들에 의하여 이후 사용을 위하여 이용될 수 있는 디바이스들에서 운용되는 다트들 또는 다트들의 부분들에 디바이스의 모든 네이티브 애플리케이션들, 기능성 및 리소스들을 노출하는 것이 사용될 수 있는 HAL의 부분이 아마도 가장 심오하게 집중적이다.

상호운용성의 간략화, 신뢰성 및 강력함은 부분적으로는 이종 디바이스들에 걸쳐서 자체를 지적으로 그리고 효율적으로 스프레드하는 특별한 애플리케이션 목적을 위하여 필요한 코드, 데이터 및 콘텐트, 그리고 메타 코드, 데이터 및 콘텐트 모두를 캡슐 내에 넣어주므로써 부분적으로 달성된다. 상호운용성 디바이스들 상에서 운용되는 애플리케이션 코드, 데이터 및 콘텐트 모두는 하나의 다트 패키지로부터 시작하기 때문에, 독립적으로 발생되고 배포된 성분들과 관련된 비정립성 또는 관리 이슈들은 없다. 데이터 및 코드를 패키지로 만드는 것은 또한 데이터 포맷과 데이터를 관리하기 위하여 선택된 애플리케이션 프로그램 사이의 비정립성들을 버젼화하는 것으로부터 생기는 공통의 상호운용성 문제들을 제거한다.

크게는 강력한 일반적 목적의 컴퓨터 망들을 위하여 수년에 걸쳐서 개발된 기술들의 연장인 존재하는 상호운용성 기술들에 대하여 디바이스들의 상호운용성을 위한 강력함, 파워, 효율 및 보안의 향상에 기여하는 적어도 21개의 독특하게 설명되는 분리된 본 발명의 시스템들, 방법들, 컴퓨터 프로그램들 및 컴퓨터 프로그램 제품들 그리고/또는 수단들이 있다. 이들 혁신들은 아래에서 간략하게 요약되고 이후 상세한 설명 부분에서 더욱 상세하게 설명된다. 별도의 본 발명의 시스템, 방법, 컴퓨터 프로그램 제품, 그리고/또는 다른 수단의 각 유용한 조합이 결합될 때 훨씬 더 많아진다. 사용된 기술들 중 많은 것들은 특정 작업들을 실행하기 위하여 ad-hoc 팀들을 형성하여 함께 작업함에 따라 인간들에 의하여 채용된 사회화 측면들을 공유한다.

ad-hoc 팀들을 형성할 필요가 있고 단속적으로만 연결되는 더 많은 특별한 목적들과 모바일 디바이스들의 빠르게 성장하는 세상은 종종 종래의 상호운용성 기술들이 빌려온 일반적 목적의 컴퓨터 망들을 이용하는 것보다 공통적으로 인간과 유사한 더 많은 협력을 종종 가진다.

모집 상호운용성 모델. 모집은 존재하는 클라이언트/서버 및 피어-투-피어 디바이스 상호운용성 모델들에 대하여 유리한 대안이다. 모집은 하나의 소프트웨어 애플리케이션 패키지 또는 다트에 의하여 사용되어 그들의 능력들과 콘텐트에 기반하는 디바이스들의 팀들을 형성하고 이후 자신의 부분들을 다트 애플리케이션 패키지의 의도된 목적을 수행하기 위하여 이후에 함께 작업하는 디바이스들의 팀들에게 총명하게 스프레드한다.

렌디셔닝 적합 및 상호운용성 단편화 모델. 렌디셔닝은 다수의 타이트하게 집적되지만, 별도로 실행가능한 프로그램들로 상호운용성 애플리케이션의 단편화를 허용한다. 개별적인 렌디션들(renditions)은 개별적인 디바이스들의 능력들과 콘텐트로 조화된 접속을 제공하는 다른 디바이스들 상에서 운용되기 위하여 전송될 모집 과정동안 선택된다.

다트소스 ( DartSource )/상호운용성 소스. 다트소스(DartSource)는 패키지로 만들어진 다트 상호운용성 애플리케이션을 위하여 필요한 모든 프로그램 렌디션들 및 코드 콘텐트 그리고 데이터를 특정하기 위한 방법이다. DartSource는 특정 디바이스를 목표로 하나의 실행가능한 프로그램을 특정하기 위하여 공통적으로 사용되는 언어 구조들을 특정될 애플리케이션의 의도된 목적의 그 디바이스의 부분을 수행하기 위한 각 모집된 디바이스 상에서 운용하기 위하여 전송할 적합한 렌디션이 있도록 필요한 디바이스들과 렌디션들의 팀들의 지적 모집을 위하여 필요한 절차들을 또한 특정할 수 있는 언어로 연장한다.

다트프레임워크 ( DartFramework )/상호운용성 프레임워크. 다트프레임워크(DartFramework)는 프로그래머가 다트플랫폼(DartPlatform)의 원하는 상호운용성 특징들 중 많은 것을 이해해야만 하고 수행해야만 하는 필요를 없애는 DartPlatform의 유리한 특징들 중 많은 것에 대한 접근을 캡슐 내에 두는 상호운용성 애플리케이션들을 구축하는데 있어서 프로그래머들에 의한 사용을 위하여 제공되는 다트소스(DartSource)의 부분이다.

다트툴 ( DartTools )/상호운용성 툴들. 다트툴(DartTool)들은 다트소스(DartSource) 애플리케이션 명세를 다트 애플리케이션 패키지들로 처리한다.

다트포맷 ( DartFormat )/상호운용성 포맷. 다트포맷(DartFormat)은 다트디바이스(DartDevice)들 상에 로딩되어 운용할 수 있는 상호운용성 애플리케이션들을 위하여 필요한 모든 코드, 데이터 및 콘텐트를 캡슐 내에 두는 다트 패키지를 함께 두기 위한 규칙들로서, 운용하는 다트플레이어(DartPlayer)를 포함한다.

다트런타임 ( DartRuntime )/상호운용성 런타임. 다트런타임(DartRuntime)은 처리 장치들이 단일 디바이스 상에서 또는 모집된 디바이스들의 팀에 걸쳐서 운용되던지 운용하는 다트의 별개 처리 장치들 사이에서 제어, 데이터 및 동작들의 타이트한 조화를 구축하기 위한 시스템이다. 이는 처리 장치들 간 데이터와 동작들을 조화하고 동기화하기 위하여 필요한 동일한 차수로 모든 처리 장치들이 모든 명령들에 대한 접속을 가질 수 있도록 애플리케이션의 모든 처리 장치들을 통하여 흐르는 사건들의 시리얼리제이션(serialization) 및 동기화를 확실히 하는 사건 구동 시스템에 의하여 달성된다.

선형 태스킹. 선형태스킹(LinearTasking)은 다수의 동작들이 특정될 수 있고 그들의 동작이 동시에 실행되었던 것처럼 운용할 수 있도록 대부분의 디바이스들 상에서 공통적으로 사용되는 우선적이고 협력적인 스레딩 모델들에 대한 유리한 대안이다. LinearTasking은 매우 결정적이고 쉽게 시험되는 방법으로 그들의 활동들을 조화하는 처리 장치들을 위한 간단하고, 신뢰성있고, 유연하고 그리고 연장가능한 방법을 확실하게 한다.

수직 레이어링( Vertical Layering ). 수직 레이어링는 각 프로토콜 인터페이스의 다르게 하는 필요들에 맞추어서 정보를 종종 변환해야만 하는 모든 중간 레벨의 프로토콜들을 통하여 통신하는 다른 레벨의 프로토콜들을 요구하는 대부분의 디바이스들 상에서 공통적으로 사용되는 프로토콜들의 수평 레이어링에 대한 유리한 대안이다. 다트 처리 장치들은 그들의 레벨에 상관없이, 처리 장치들이 모든 다른 처리 장치들과 변환없이 모든 처리 장치들에 의하여 접근할 수 있고 이해될 수 있는 이벤트 구조들과 이벤트 큐들의 사용을 통하여 다른 모든 처리 장치들과 통신할 수 있도록 수직 레이어링를 사용한다.

애플리케이션 구동 파워 관리( Application driven power management ). 다트프레임워크(DartFramework)에 적어도 부분적으로 구체화된 선형태스킹(LinearTasking) 및/또는 수직 레이어링을 이용하여 탑재된 다트 애플리케이션들은 프로세서를 느리게 하는 것과 같이, 효율적인 파워 관리 기술들이 배터리 수명을 연장할 수 있고, 소비 에너지 양을 제한하거나 디바이스들에서 발생된 열의 양을 제한할 수 있도록 항상 그들의 정확한 응답 시간 필요들의 트랙을 유지한다. 현재의 기술 상태에서, 대부분의 애플리케이션들은 그들의 응답 시간 필요들의 트랙을 유지하지 않고, 만약 유지했다면, 애플리케이션으로부터 디바이스의 하드웨어까지 응답 시간 필요들과 통신하기 위한 인터페이스들을 포함하지 않는 명세들에 맞춘 프로토콜들의 존재하는 계층들을 통하여 이들 필요들과 통신하지 않았을 것이다.

상호운용성 애플리케이션 구동 에러 회복. 디바이스간 무선 통신 연결들은 종종 간섭, 거리 한계들, 그리고 낮은 배터리 전원으로 인한 급작스러운 정지로 인하여 신뢰할 수 없다. 디바이스들 상에서 종래의 수평적으로 계층화된 프로토콜 소프트웨어 실행들에서, 임의의 한 층에서 치명적인 에러는 회복될 수 없는 에러들이 될 것이고, 애플리케이션이 연결들과 연결들의 컨텍스트들을 쉽게 재구축하는 표준 인터페이스들을 갖지 않기 때뭉에 그리고 종래의 애플리케이션 프로그램들이 다른 디바이스들 상에서 운용하는 애플리케이션들 간 공유된 상태를 트랙킹하고 재구축하기 위한 많은 인프라구조를 갖지 않기 때문에, 애플리케이션이 회복하기는 어려울 것이다. 다트프레임워크(DartFramework)는 공유된 상태의 트랙을 유지하고, 렌디셔닝은 디바이스들 사이에서 잃어버린 상태를 쉽게 재구축하기 위하여 사용될 수 있고, 수직 레이어링는 통신 에러들이 다트에게 간단하게 중계되도록 하고 다트가 회복 정보를 통신 처리 디바이스들에게 직접 중계하도록 한다. 이처럼, 디바이스들에 걸쳐서 운용되는 다트들은 협력 디바이스들과 앞서 잃어버린 디바이스가 그의 모든 애플리케이션 상태를 잃는 곳에서 조차 연결이 회복될 때 디바이스들의 공유된 상태의 회복 사이에서 통신들의 단속적인, 완전한 손실들로부터 균일하게 회복할 수 있다.

상호운용성 인스트럭션세트 . 상호운용성 인스트럭션 세트(InteroperabilitylnstructionSet)는 다트의 코드 부분들을 표시하기 위하여 사용된다. DartEngine은 이들 명령들을 실행한다. 종래의 프로세서들의 종래의 페칭(fetching), 저장, 시험, 계산 및 분기 명령들과 함께, Interoperabilitylnstructionset는 동작 속도를 향상시키고, 상호운용성 방법학들을 수행하고, 디바이스들의 능력들과 콘텐트를 서로 노출하는 명령들을 포함한다. 특별히 주목할 것은 다른 디바이스들이 독특한 능력들과 콘텐트의 사전 지식을 갖지 않을 때 조차도 다른 디바이스들에 대한 디바이스들의 독특한 능력들과 콘텐트의 사용과 노출을 위한 명령들이 있다는 것이다.

창조설( Creationism ). 창조설은 특별한 목적 디바이스 및/또는 통신 세션 및/또는 목적을 위하여 고도로 사용자 지정된 다트들을 동적으로 생성하기 위하여 다트들에 의하여 사용된 방법이다. 다트인스트럭션세트(DartlnstructionSet) 내의 명령들은 운용하는 다트 자체의 부분들과 운용하는 다트에 의하여 수집되거나 계산될 수 있는 임의 정보로부터 다트들의 프로그램적 발생을 위하여 존재한다.

상호운용성 엔진/ DartEngine . 다트엔진(DartEngine)은 디바이스 상에서 다트들의 명령들을 실행하기 위하여 그리고 그들의 의도된 목적을 수행하기 위하여 사용되는 소프트웨어 및/또는 하드웨어이다. 다트엔진(DartEngine)과 다트엔진(DartEngine)이 내부에 캡슐화된 디바이스 특정 다트플레이어(DartPlayer)는 다트들의 의도된 목적을 최대로 수행하기 위하여 모집과 렌디셔닝으로 하여금 공통적 실행 및 디바이스들의 효율적인 팀들을 구축하고 그들의 코드, 데이터 및 콘텐트를 스프레드하도록 하는 공통 실행 및 DartRuntime 환경을 제공한다.

상호운용성 디바이스 인에이블링 ( Interoperability Device Enabling ). 상호 운용성 디바이스 인에이블링은 DartPlayer의 일부로서 DartEngine의 이식을 통하여 고도로 상호운용할 수 있는 DartDevice로 종래의 디바이스를 바꾸는 과정이다. 아울러, 디바이스 특정 정보, 디바이스의 능력들 및 콘텐트에 접급하기 위하여 필요한 하드웨어 앱스트랙션 레이어의 실행이 또한 요구된다. 적어도 하나의 통신 프로토콜이 DartPlayer를 가진 디바이스가 DartDevice로 되기 이전에 실행되어야만 한다.

상호운용성 보안 모델/ DartSecurity ., DartSecurity는 악의적이거나 우연한 사고로부터 디바이스의 온전함과 콘텐트를 보호하기 위하여 필요한 인프라구조를 제공하기 위한 시스템이다.

소셜 싱크러니제이션 상호운용성 방법/ Dart Social Synchronization. 소셜 싱크러니제이션는 매스터(master) 디바이스와 접촉하는 모든 디바이스 또는 매스터로서 기능하는 임의 디바이스를 위한 필요없이 임의 수의 디바이스들과 프로토콜들에 걸쳐서 데이터 및/또는 동작들의 특정 집합들을 동기화하기 위한 효율적이고 쉬운 관리 방법이다. 디바이스들과 콘텐트의 소셜 싱크러니제이션는 인간들이 정보와 작업들을 공유하는 방법과 유사하고 이 기술의 현재 상태에서 대부분 종종 사용되는 숙련된 동기화 기술들에 대한 유리한 대안이다.

소셜 시큐리티 상호운용성 모델/ Dart SocialSecurity . 소셜씨큐리티(SocialSecurity)는 단속적으로 연결되는 가능한 디바이스들의 팀들 사이에서 보안의 웹들을 형성하기 위한 특히 간단한 관리 방법이다. SocialSecurity는 인간들이 종종 서로 신뢰하게 되는 방법과 유사한 방법으로 작용한다. SocialSecurity를 위한 토대는 디바이스에서 디바이스로 과도적으로 이동하는 허용된 접속 권리들과 함께 DartSecurity 시스템을 이용하여 생성되는 독특한 ids을 스프레드하는 SocialSynchronization의 사용이다. 결코 직접 통신하지 않았던 디바이스들은 종종 그들이 더 이상의 모임 허용없이 어떤 접근 권리들과 상호운용하도록 허용된 디바이스들의 팀의 일부라는 것을 발견할 것이다.

상호운용성 디바이스 / DartDevice. 다트디바이스(DartDevice)는 다트엔진(DartEngine)과 다른 다트디바이스(DartDevice)에 연결하기 위한 적어도 하나의 통신 프로토콜을 포함하는 그의 운용 다트플레이어(DartPlayer)에 의하여 고도로 운용할 수 있는 디바이스이다.

상호운용성 플랫폼/ DartPlatform. 다트플랫폼(DartPlatform)은 다트디바이스(DartDevice)들의 명세, 생성, 지적 팀화를 수행할 수 있고 하나 이상의 다트디바이스(DartDevice)들에 걸쳐서 다트 상호운용성 애플리케이션들의 스프레딩과 운용을 손쉽게 할 수 있는 다트 방법론들의 임의 집합이다.

버츄얼 포인터들( Virtual Pointers ). 버츄얼포인터(VirtualPointers)는 단일 프로그램 내에 하나 이상의 독립적인 데이터 어드레스 공간들의 접속 및 사용을 위한 간단하고 효율적인 방법을 프로그래머들에게 제공하기 위한 방법학이다. 소프트웨어 프로그램들에 의하여 사용된 VirtualPointers는 빠르지만 작은 메인 메모리와 크지만 느린 저장용량의 크기들과 속도를 다르게 하면서 디바이스들 상에서 효율적으로 운용되도록 메인 메모리와 저장 장치의 사용을 적합하게 할 수 있다.

예시적인 실시예들의 상세한 설명은 첨부된 도면들과 연관되어 읽혀져야 ㅎ하고, 여기서

도 1은 상호운용하거나 함께 작업하기 위한 N개의 디바이스들을 얻는 것이 일반적으로 N-제곱의 적합들의 차수로 요구하는 상황을 보여주는 도면이다.

도 2는 함께 직접 작업하기 위한 8개의 디바이스들을 얻는 복잡함을 보여주고 56개의 적합들의 차수를 취하고 동작을 시험하고 증명하기 위하여 56개의 다른 테스트 배열들을 요구하는 도면이다.

도 3은 본 발명의 실시예의 주 성분들과 부성분들의 블럭도이다.

도 4는 본 발명의 실시예에 따르는 예시적이고 전형적인 DartDevice 개관을 보여주는 도면이다.

도 5는 흐름도의 형태로 모집 절차의 예시적 실시예를 보여주는 도면이다.

도 6은 최초의 제1 DartDevice 또는 다트 애플리케이션에 대하여 처음에 아무것도 알지 못하는 제2 DartDevice와 함께 제1 DartDevice 상에서 운용하는 (슬라이드 쇼 다트 애플리케이션과 같이) 다트 애플리케이션을 연장하고 공유하기 위한 본 발명의 모집 방법의 예를 예시하는 도면이다.

도 7은 최초의 DartDevice 상에서 동작하고 상기 최초의 DartDevice 또는 슬라이드 쇼 애플리케이션에 대하여 처음에 아무것도 알지 못하는 또 다른 DartDevice 상에서 동작하는 슬라이드 쇼 애플리케이션으로부터 원격 프린팅을 위한 모집의 예를 예시하는 도면이다.

도 8은 각 디바이스가 최초 다트의 다른 렌디션을 이용하고 있는 세 개의 디바이스들의 팀에 걸쳐서 동작하는 다트로서 표현되는 프린트 사진 애플리케이션의 예시적 실시예를 보여주는 도면이다.

도 9는 협력 디바이스들의 모집된 팀에 걸쳐서 동작하는 다트 애플리케이션의 동기화 및 연재의 실시예들을 보여주는 도면이다.

도 10은 노력이 N에만 비례하도록 모집들이 디바이스들의 그룹을 하나의 디바이스로서 기능하도록 하고 N개의 디바이스들의 상호운용성을 달성하기 위한 노력을 제한하는 방법의 도면이다.

도 11은 클래스 계층에서 메인 DartFramework 객체들과 그들의 상대적 위치의 실시예의 블럭도이다.

도 12는 다트 애플리케이션을 생성하기 위하여 사용된 애플리케이션 개발 디바이스와 그의 정적 및 절차적 성분들을 예시하는 블럭도이다.

도 13은 DartFormat의 실시예의 부분들 성분의 구조의 실시예의 구조를 예시하는 블럭도이다.

도 14는 DartProcedure의 실시예 구조를 별도로 묘사하면서, DartFormat의 PartTable 성분과 PartTable의 PartTable 기록 성분의 포맷의 실시예의 구조에 대한 블럭도이다.

도 15는 다트 애플리케이션에서 Gizmo 유도 객체들의 계층을 통한 패스를 위한 DartRuntime 처리의 흐름도이다.

도 16은 DartRuntime의 프로세스 이벤트 처리의 측면들을 예시하는 흐름도이다.

도 17은 하나의 DartDevice 상에서 시작하여 이후 모집을 이용하여 다른 DartDevice들을 거쳐서 동작하도록 자신을 연장하는 다트 애플리케이션의 실시예에 의하여 사용되는 DartDevice들 간 연결들을 예시하는 블럭도로서, 상기한 다른 DartDevice들은 이후 그들의 활동들을 조화하기 위하여 도시된 이벤트 데이터 구조의 형태로 메시지들을 교환한다.

도 18은 슬라이드 쇼 또는 미디어 디스플레이 애플리케이션의 예시적 실시예에서 사용되는 기즈모 처리 디바이스들의 실행의 계층적 처리 배열과 순서를 예시하는 블럭도이다.

도 19는 본 발명의 일실시예에 따르는 다트 애플리케이션 레벨 에러 회복의 실시예를 보여주는 도면이다.

도 20은 DartEngine에 의하여 수행된 빌트인구조(Builtinlnstruction) 및 OEM~빌트인구조 처리를 예시하는 흐름도이다.

도 21은 하나의 디바이스가 그의 독특한 능력들을 이들 독특한 능력들의 사전 지식을 갖지 않는 디바이스들에게 노출하는 방법을 보여주는 가설의 Neutrino Detector/모바일 폰의 예시적 실시예를 보여주는 도해이다.

도 22는 DartPlayer의 예시적 실시예와 DartEngine, 즉 휴대용 성분, 그리고 비휴대용 하드웨어 앱스트랙션 레이어 성분의 실시예의 특별한 실행의 두 개의 메인 성분들을 예시하는 블럭도이다.

도 23은 다트플레이어(DartPlayer)의 일 실시예의 메인 루프 프로세싱 플로우를 보여주는 흐름도이다.

도 24는 다트플레이어에 의한 다트엔진(DartEngine) 초기화 기능으로의 콜(call) 동안에 발생되는 프로세싱을 보여주는 흐름도이다.

도 25는 다트플레이어에서 구현되는 다트런타임(DartRuntime) 인스트럭션 프로세싱을 보여주는 흐름도이다.

도 26은 다트플레이어의 파일 시스템 인스트럭션 프로세싱을 보여주는 흐름도이다.

도 27은 다트엔진의 실시예의 비휴대형(non-portable) 하드웨어 앱스트랙션 레이어(Hardware Abstraction Layer)의 구성 요소들을 보여주는 블록도이다.

도 28은 다트로부터의 파일들로의 액세스는 제공하나 러닝(running) 다트의 보호 샌드박스(running Dart's protective Sandbox)의 부분으로 간주되지 않는 파일들로의 액세스를 위한 메카니즘은 제공하지는 않는 파일 시스템의 비휴대형 다트디바이스 특정 부분들을 보여주는 도면이다.

도 29는 다트디바이스의 다트시큐리티 구성 요소들의 실시예를 보여주는 블록도이다.

도 30은 소셜 싱크러니제이션 콘택 리스트의 일실시예를 보여주는 도면이다.

도 31은 전형적인 다트디바이스 및 그 소셜시큐리티 구성 요소들을 보여주는 블록도와 구 및 신 다트디바이스의 전/후 팀 소셜시큐리티 콘텐츠를 도시는 블록도들이다.

도 32는 특정 버츄얼 포인터 어드레스의 데이터 엘리먼트로 액세스하는데 사용되는 다트 버츄얼 포인터들의 예를 보여주는 도면이다.

I. 개요( Overview and Introduction )

일 형태에 있어서, 본 발명은 유사하거나 더 중요하게는 상이한 세트들의 디바이스들 및 시스템들 사이에서 디바이스들이 상이한 세트의 콘텐트(content), 컨트롤(control), 리소스(resources) 및 애플리케이션(applications)을 효율적으로 공유할 수 있게 하는 방법들 및 시스템들에 관한 것이다. 본 발명의 형태들은 "다트플랫폼(DartPlatform)"으로 구현된다. 본 명세서에 있어서, "다트(Dart)"라는 명칭은 그러한 응용 프로그램, 데이터 및/또는 다른 혼합된 형태의 프로세스들, 프로시져들, 데이터, 목적(intentions) 및 가능한한 넓은 의미의 다른 정보들이 스마트(sm ART )한 데이터( D ata)로 결합된다는 것을 의미하기 위하여 사용된 것이며, 또한 다양한 세트의 디바이스들, 디바이스 리소스들 및 디바이스 능력들 간에 고도의 간단함, 효율성, 강인성 확보 및 상호 운용성(interoperability)을 달성하도록 다트들(Darts), 다트프로시져들(DartProcedures) 및 다트파트들(DartParts) 형태의 데이터, 콘텐트 및 프로시져들의 완전하고 지능적인 패키지들이 디바이스들 사이에서 문자 그대로 다트(또는 전달)되는 방식을 나타내기 위하여 사용된 것이다.

더욱이, 본 발명의 상세한 설명에 있어서 "다트"라는 용어는 본 발명의 소정 실시예를 의미하며 "상호 운용성(interoperability)"이라는 용어는 다트가 상호 운용성의 소정 형태가 되는 청구된 발명의 형태들에 대한 포괄적인 용어로서 사용된다는 것을 이해할 수 있을 것이다.

본 발명에서는 지금까지 종래의 문헌에 설명된 적이 없는 새로운 패러다임들을 이루는 다수의 신규한 기술적인 시스템들, 디바이스들, 방법들, 컴퓨터 구조들 및 프로그램적인 특징들을 도입한다. 적어도 부분적으로는 기술적 및 컴퓨터 전문 용어법이 혁신적인 구성 요소들을 종래의 구성 요소들로부터 완전히 구분시킬 수 있는 컴팩트한 용어를 아직까지는 제공하고 있지 않기 때문에, 본 발명의 상세한 설명에서는 "다트(Dart)" 또는 "다티즘(Dartism)"이라는 용어를 다트 프로시져들(Dart Procedures), 다트 파트들(Dart Parts) 등과 같은 어구에서 사용되는 바와 같이 다른 용어의 접두어 또는 수식어로서 종종 사용된다. 예를 들어, 상기 두 용어들은 다트프로시져들(DartProcedures), 다트파트들(DartParts), 다트디바이스(DartDevice) 등에서와 같이 서로 연결되어 사용된다. 더욱이, 디바이스(device), 파트(part) 또는 프로시져(procedure)와 같은 보다 컴팩트한 용어 형태들이 본 발명의 형태들을 설명하는데 이용된다는 것을 이해할 수 있을 것이다. 이러한 의도된 의미는 대체적으로 상세한 설명의 문맥으로부터 알 수 있으며, 본 발명의 일 형태를 설명함에 있어서 "다트프로시져들(DartProcedures)"과 같이 대문자로 표기된 단일어의 형태가 "다트 프로시져들(Dart Procedures)", "다트 프로시져들(Dart procedures)" 또는 "프로시져들(procedures)"와 같은 복합어의 형태와 동등하다는 사실을 이해할 수 있을 것이다. 이는 다트 파트들(Dart Parts), 다트 플레이어(Dart Player), 다트 플랫폼(Dart Platform) 등과 같이 "다티즘들(Dartisms)"이라는 용어에도 적용된다. 다트들(Darts)은 그것의 가장 일반적인 형태로는 단순히 데이터도 아니며 프로시져들 또는 프로그램들도 아니고 콘텐트도 아니며, 다트들(Darts)은 그 모든 구성 요소들의 일부이거나 그 모든 구성 요소들의 결합일 수도 있다. "다트들(Darts)"은 상호 운용성 애플리케이션의 목적을 수행하도록 디바이스들 사이에서 그 자체 또는 그 자체의 부분들을 지능적으로 어셈 블(assemble), 세이브(save) 및 분배(distribute)하는데 이용될 수 있는 코드 데이터 및 콘텐트, 소프트웨어, 코드, 데이터 및/또는 콘텐트의 특수한 형태의 통합된 디지털 이진(binary) 패키지로 간주될 수 있다. 본 발명은 동종 디바이스들 간은 물론 이종 디바이스들 간의 간단하며 효율적이고 신뢰성이 있으며 안정된 상호 운용성을 가능하게 한다.

불행히도 현행의 컴퓨팅 패러다임과 정보 시스템들 및 디바이스들이 운용 시스템(Operating System: OS) 구성 요소들, 디바이스 드라이버, 컴퓨터 애플리케이션 프로그램들 및 사용자 또는 기타 데이터 구성 요소들을 구분하는데 있어서 너무나 그 방식이 견고히 확립되어 있어서, 컴퓨터 과학 기술 분야에서 통상적으로 허용되는 몇몇 용어들이 본 발명의 구성 요소들에 엄격히 적용되지 않는다. 그러므로 가능한 범위의 정도까지는 통상적인 컴퓨팅 및 컴퓨터 과학 용어들이 그 의미가 정확하지는 않지만 적절한 경우에 사용될 것이며, 많은 수식어들을 가지는 포괄적인 용어들의 사용을 피하기 위하여 좀 더 특수한 의미가 요구되는 경우에는 다양한 "다트" 표현들 및 용어들이 사용된다.

독자들이 다트 플랫폼, 시스템, 방법 및 컴퓨터 프로그램 구성 요소들에 익숙해 질 수 있도록, 본 발명의 실시예들의 몇몇 구성 요소들, 특징들 및 장점들을 우선적으로 설명한다. 상기 및 기타 구성 요소들 및 특징들은 후술되는 상세한 설명부에서 더 자세히 설명될 것이다. 본 발명의 모든 실시예들에 따른 구성 요소들, 특징들 또는 장점들 모두를 몇개의 단락만으로는 열거할 수 없기에, 하기의 설명은 몇몇 실시예들에 따른 구성 요소들 및 장점들과 선택적이지만 바람직한 형태의 구 성 요소들 및 특징들의 전형적인 예를 들고 있으며 그러한 설명이 한정적인 의미로 간주되어져서는 안된다는 사실에 유념해야 한다. 본 발명의 몇몇 실시예들은 여기에서 설명되는 일부 및 다수의 특징들을 제공 및 사용하거나 그 반대로 제공 및 사용하지 않을 수 있으며, 본 발명의 다른 실시예들은 여기에서 설명되는 특징들 및 구성 요소들을 전부는 아닐지라도 다수 또는 대부분을 제공하거나 사용할 수 있다는 사실에 유념해야 한다.

운용 시스템들, 프로그램 포맷들, 프로그래밍 툴들(tools) 및 통신 프로토콜들(protocols)을 위한 종래의 방법들은 주로 충분하며 신뢰성 있는 전원 공급장치와 신뢰성 있으며 고속이면서 항상 온 상태인 통신 프로토콜들에 액세스(access)한 다수의 강력한 범용 컴퓨터에 적합하도록 개발되었다. 더욱이, 종래에는 컴퓨터들의 네트워크들이 상대적으로 안정적이였으며 상호 작용하도록 구성되거나 재구성되어져야 하는 경우가 드물었다. 또한 종래의 방법들은 컴퓨터들, 네트워크들, 운용 시스템들 및 프로그램들을 설치, 구성, 재구성, 업데이트, 수리 또는 유지하는데 이용될 수 있는 시스템 관리자들로 이루어진 정통한 풀(pool)이 존재할 거라 가정하였다.

이러한 종래의 방법들은, 주로 배터리로 구동되고 제한적인 컴퓨팅 리소스를 가지며 저속의 신뢰성이 없는 무선 또는 전원 라인 프로토콜을 통해 통신하고 대부분은 휴대형이며 단속적으로만 연결되는 다른 디바이스들과 상호 작용하기 위해서는 항상 동적으로 재구성될 필요가 있는, 전용 디바이스들로 이루어지는 급격히 진화되고 있는 환경에 일반적으로 적용되기에는 적절하지 못하다. 증가하는 동적인 구성에 대한 필요성 및 함께 동작해야만 하는 디바이스들과 그 능력들의 다양성에도 불구하고, 그러한 디바이스들 및 그와 관련된 소프트웨어가 시스템 관리자들에 정통하지 못한 사람들에 의해 사용되고 유지되는 것이 매우 바람직할 경우가 종종 있다.

다트플랫폼(Dart Platform)은 소정 세트의 창의적인 방법들, 소프트웨어 구성 요소들 및/또는 하드웨어와 에코-시스템(eco-system)을 포함하는데 이는 전용 및 통신 장치들로 이루어지는 급속히 발전하고 있는 환경의 특성들과 필요성들을 위해 특별히 설계된 것이다.

본 발명의 일 실시예에 따르면, 다트 플랫폼(Dart Platform:DP)은 바람직하게는 하기와 같은 구성 요소들을 포함할 수 있다.

1. 다트인스트럭션세트(DartInstructionSet) - 상호 운용 인스트럭션 세트

2. 다트엔진(DartEngine) - 휴대형 상호 운용 엔진

3. 다트포맷(DartFormat) - 다트포맷 정보(일반적으로 비트파일(들) 또는 비트-이미지(들)과 같은 디지털 이진 세트의 형태임)를 상기 다트엔진에 의한 처리를 위해 해당 디바이스로 전달하기 위한 메카니즘과 다트엔진 모두를 포함하는 소정 디바이스 또는 서브시스템(subsystem) 상에서 데이터, 콘텐트, 코드, 프로시져들 또는 기타 정보를 최적으로(또는 거의 최적으로) 런(run), 세이브(save), 최적화(optimize), 카피(copy) 및/또는 공유(share)하는데 필요한 데이터, 콘텐트, 코드들, 프로시져들, 시맨틱스(semantics) 또는 기타 정보를 인캡슐레이트(encapsulate)하는 파일 또는 비트-이미지 포맷.

4. 다툴들(Dartools) - 다트 포맷 비트-이미지들 또는 파일들을 생성하기 위 한 소프트웨어 툴의 세트. 다트 툴들(Dart Tools)은 다트컴파일러(DartComplier), 다트링커(DartLinker) 및 다트마스터플레이어(DartMasterPlayer)와 기타 툴들을 포함할 수 있으며 이들 각각이 하기에서 더 상세히 설명된다.

5. 다트(Dart) 또는 다트들(Darts) - 다트포맷 파일 또는 비트-이미지 포맷에 따르는 다트엔진을 포함하는 디바이스에 의한 처리를 위한 상기 다툴들(Dartools)에 의해 생성되는 비트들, 비트 이미지 및/또는 파일 인스턴스들(instances)의 패키지. 상기 다트포맷은 다트포맷 비트-이미지들을 상기 다트엔진에 의한 처리를 위해 해당 디바이스로 전달하기 위한 메카니즘과 다트엔진 모두를 포함하는 소정 디바이스 또는 디바이스들의 세트 상에서 데이터/콘텐트/코드를 최적으로 런(run), 세이브(save), 최적화(optimize), 카피(copy) 및/또는 공유(share)하는데 필요한 데이터/콘텐트/코드의 조합 및 시맨틱스(semantics)를 인캡슐레이트할 수 있다. 다트들(Darts)은 다트(Dart)의 복수형이다.

6. 다트프로시져(들) - 해당 인스트럭션들(instructions)이 처리하는 데이터 이미지들과 데이터 이미지 값들과 결합된 상기 다트인스트럭션세트로부터의 인스트럭션들의 시퀀스들로 구성되는 자급식(self-contained) 경량(lightweight) 프로시져(들).

7. 다트플레이어(DartPlayer) - 다트엔진을 이용하여 다트들을 처리하는 소정 서브세트의 디바이스들 상에서 작동하도록 설계된 소프트웨어 프로그램.

8. 다트마스터(DartMaster) - 소위 상기 다트마스터플레이어인 특정 다툴로 처리하여 하나 이상의 효율적인 및/또는 특수화된 다트들 또는 다트로 더욱 최적화될 다트.

9. 다트프레임워크(DartFramework) 또는 다트오브젝트프레임워크(DartObjectFramework) - 다트들을 구성하는데 이용되는 베이스 클래스들(base classes)의 세트를 위한 방법들 및 데이터를 정의하는 소스 코드의 세트. 상기 다트오브젝트프레임워크는 코드 및 데이터와 입력 데이터 및 코드가 처리되는 순서를 제어하는 스트럭쳐들과 시맨틱스의 세트, 최초 오브젝트 데이터 포인터 및 최초 실행 포인트를 취한다. 이를 통해, 소정 개수의 팀 디바이스들을 가로지르는 런타임 동작들(activities)을 동기화(synchronize)하고 직렬화(serialize)하는 인터디바이스(interdevice)로 인트라-디바이스(intra-device) 런타임을 연장하기도 하는 다트런타임(DartRuntime)의 디바이스 인트라-디바이스 런타임 부분이 구현된다.

10. 다트런타임(DartRuntime) - 상기 다트프레임워크 또는 다트오브젝트 프레임워크는 바람직하게는 코드 및 데이터와 입력 데이터 및 코드가 처리되는 순서를 제어하는 스트럭쳐들과 시맨틱스의 세트, 최초 오브젝트 데이터 포인터 및 최초 실행 포인트를 취한다. 이를 "다트런타임"의 인트라-디바이스 부분으로 칭하기로 한다. 인터-디바이스 런타임도 존재하는데 이는 팀 디바이스들 간의 동작들의 동기화(synchronization) 및 동위화(coordination)와 데이터 교환들을 제어하는 이벤트 스트럭쳐 인스턴스들이 그 중에 하나가 각 디바이스의 다트엔진에 의해 유지되는 이벤트 큐들(queues) 간에 자동으로 직렬화되고 동기화된다고 가정한다. 상기 인트라-디바이스 다트런타임과 인터-디바이스 런타임들은 함께 사용의 용이성을 도모하 며 다트의 상이한 해석들(renditions) 각각이 팀 디바이스들의 세트에 사용되는 경우에는 다트의 목적(intent)를 수행하기 위한 매우 강인하고 효과적인 시스템들을 제공한다.

본 발명의 다른 형태들에 있어서, 본 발명은 소정 형태의 디바이스들 간의 상호 운용성을 개선하고 또한 일례로 단속적으로 연결되거나 항상 상호 연결된 디바이스들, 시스템들 또는 서브시스템들 간의 상호 운용성과 관련된 하기 또는 다른 문제점들을 해결하고자 한다.

1. 콘텐트, 애플리케이션(applications) 및 컨트롤(controls)을 이종 디바이스들 간에 이동하는 경우의 디스플레이, 컨트롤, 코드, 데이터 및 기능의 적합성(adaptation) 및 최적화 문제.

2. 프로그램들, 파일들 및/또는 콘텐트가 어디로 이동하든지 간에, 원하는 모든 것들이 동작하는(바람직하게는 가능한 잘 동작하는) 콘텐트인 경우에, 디바이스 사용자가 프로그램들, 콘텐트 포맷들, 드라이버들 및/또는 파일들을 고려할 필요성을 제거하는 문제.

3. 하나 이상의 디바이스들 간에 사용되는 디바이스 연결(들) 또는 통신들의 유형을 사용자가 구체화하거나 심지어는 알아야 할 필요성을 제거하는 문제.

4. 모든 인에블된 디바이스들 간의 콘텐트, 컨트롤들 및/또는 리소스들의 간단하고도 효율적인 공유를 허용하는 문제.

5. 고비용의 복잡한 CAP(Computer-aided tomography: 컴퓨터 기반 단층 X선 사진 촬영) 스캐너들로부터 (박형 프로세서/메모리) 광 스위치들(light switches) 또는 기타 단순한 디바이스들에 이르기까지의 소정의 디바이스 또는 시스템을 인에블시켜서 다큐먼트 및 그것들의 기능들, 리소스들, 능력들로의 접근 허용 및 다른 연결된 디바이스들에 필요한 것을 사용가능하도록 해야 하는 문제점.

6. 상기의 일부 또는 모두를 가능하게 하는 종래의 비절차적인 접근 방법들(non-prodecural approaches)을 이용하여 필요한 극도의 개발 노력을 상당히 작은 수의 개발 프로젝트들과 비용들로 쉽게 달성될 수 있는 정도로 낮추어야 할 문제점.

7. 저가, 비용 절감형 및/또는 소비전력 절감형 디바이스들에 적합하도록 (코드 사이즈, 실행 로직 및 메모리 측면에서) 충분히 경량(lightweight)이여야 할 문제점.

8. 예를 들어 하기 사항들의 하나 또는 그 조합을 위한 긴밀히 얽힌 서포트(support)를 포함시켜서 소정 개수의 다트디바이스들이 모든 다트디바이스들과 상호 작용할 수 있도록 소셜 시큐리티해야 할 문제점.

(a) 동적 멀티미디어는 디바이스 하드웨어가 그것을 지원할 수 있을 때마다 충분히 인터페이스하며, 디바이스 하드웨어가 그것을 지원하지 않는 경우에는 계층적으로 덜 충분하게 인터페이스 한다;

(b) 디바이스 전력 관리;

(c) 디바이스 발견(discovery);

(d) 서비스 발견;

(e) 리소스 발견;

(f) 다양한 통신 물리 및 프로토콜 레이어들의 항목들(details)을 알기 위해 다트 애플리케이션을 분리시킴(isolating);

(g) 물리 디스플레이 포맷들의 항목들(details)을 알기 위해 다트 애플리케이션을 분리시킴;

(h) 다수의 유사 또는 상이한 디바이스들 간에 동작하는 애플리케이션과의 동기화를 유지하기 위하여 다트 애플리케이션을 분리시킴;

(i) 국부적으로 작동하면서도 컨트롤 패널들이 복구되는 디바이스들을 실질적으로 제어하는 최적화된 컨트롤 패널들을 요청(requesting), 복구(retrieving) 및 작동(running)시킴; 및

(j) 개별적으로 생성된 다트 콘텐트를 하나 이상의 부모 다트들(parent Darts)의 인트라-디바이스 다트런타임(DartRuntime) 환경의 자녀 다트 확장 부분(child Dart Extensions)으로 로딩(loading), 작동(running) 및 최적화(optimizing)함.

9. 시발(originating) 디바이스 상의 다트에서 구현된 상호 운용(interoperability) 애플리케이션을 시작시키는 디바이스(initiating device: 시작 디바이스) 이외의 디바이스들 중의 어느 하나 상에서 기 존재하는 프로그램들, 데이터 또는 콘텐트에 대한 필요성을 제거해야 하는 문제점.

10. 마스터(master) 또는 슬레이브(slave)가 되는 어느 하나의 디바이스에 대한 필요성이 없이, 디바이스 능력들(capabilities) 및 제한들(limitations)의 일부 또는 모두에 근거하여, 디바이스들이 그것들의 리소스들을 효율적으로 공유하도 록 허용해야 하는 문제점.

11. 연결된 디바이스들이 애플리케이션을 사용을 위해 세이브하고 원래 또는 시작 디바이스가 더 이상 연결되지 않는 이후에도 다른 디바이스들에 확산되는 방식으로, 애플리케이션 코드, 데이터, 콘텐트 및 그 조합(다트들로 구현된 바와 같이)들이 동적으로 더욱 확산되도록 허용해야 하는 문제점.

12. 다른 경우라면 각 디바이스에 개별적으로 생성 및/또는 분배될 프로토콜 소프트웨어 구현 수단들(implementations), 코드, 데이타, 콘텐트 또는 개별적으로 생성 및 분배된 애플리케이션을 믹싱(mixing) 및 매칭(matching)하는 것과 관련된 문제점들을 제거하면서, 요구되는 바대로 다른 디바이스들 간에 스스로 확산되는 단일 패키지(또는 패키지들의 세트)에서 상호 운용 애플리케이션의 모든 코드, 데이터 및 콘텐트를 인캡슐레이팅(encapsulating) 함으로써 멀티-디바이스 작동들의 신뢰성을 개선해야 하는 문제점.

13. 상기한 바의 모두를 간단하고 신뢰성 있으면서도 확실한 방식으로 달성해야 하는 문제점.

도 8에는 픽쳐들(pictures)의 소스로서 사용하기 위한 네트워크 부착 저장 디바이스(Network Attached Storage Device)를 리크루트(recruit)한 셀폰(cell phone) 상에서 동작하는 프린트픽쳐 다트(PrintPicture Dart)와 픽쳐들의 프린팅을 수행하기 위한 목적지(destination)의 역할을 하는 프린팅 디바이스(Printing device)의 일례가 도시되어 있다. 상기의 모든 디바이스들은 각 디바이스들에 이식(port)된 다트플레이어(DartPlayer)를 포함하는 것으로 가정한다.

상기 셀폰 상의 다트는 다트플레이어 상에서 동작하는 경우에 각각 개별적으로 수행가능한 이미지들의 역할을 할 수 있는 세 개의 렌디션들(renditions)(R1, R2, R3)을 포함한다. 상기 렌디션(R3)은 상기 셀폰 상에서 동작하며, 상기 특정 네트워크 부착 저장 디바이스(Network Attached Storage Device)가 픽쳐들을 위한 최선의 소스의 기능을 하며 상기 프린터 디바이스가 프린팅 픽쳐들을 위한 목적지로서 최선으로 기능할 수 있을 것이라 판단한 후보 디바이스들(candidate devices) 상에서 수행되도록 다트프로시져들(DartProcedures)을 전달함으써 상기 다른 두개의 디바이스들의 리쿠루트먼트(recruitment)를 미리 수행한다.

그리고 나서 셀폰 상의 상기 렌디션(R3)은 상기 네트워크 부착 저장 디바이스(Network Attached Storage device: NAS )로부터 픽쳐들을 확인하고 복구하기 위한 이벤트 프로세싱 코드(event processing code)를 포함하는 상기 렌디션(R1)을 포함하는 다트를 위한 이미지를 생성한다. 그리고 나서 상기 다트를 포함하는 렌디션(R1)은 런_다트 타입 이벤트(RUN_DART type event)의 일부로서 상기 네트워크 부착 저장 디바이스에 전달된다. 상기 런_다트 타입 이벤트가 상기 NAS 디바이스 상의 다트엔진(DartEngine)에 의해 처리될 때, 렌디션(R1)은 로드(load)되어 상기 NAS 디바이스 상에 저장된 정보 또는 픽쳐들을 요청하는 소정 동기화 이벤트를 처리할 실행 동작(execution)을 시작한다. 마찬가지로, 프린트_픽쳐 타입 이벤트(PRINT_PICTURE type event)의 일부인 픽쳐들의 프린팅을 처리하는 렌디션(R2)이 형성되어 상기 선택된 프린터 디바이스상에서 동작하도록 전달된다.

상기 세 개의 렌디션들은 모두 원래 상기 셀폰 상에 상주하던 동일한 프린트 픽쳐 다트(PrintPicture Dart)로부터 생성된다. 이를 통해 애플리케이션이 종래의 상호 운용 방식들에서 요구되던 독립적으로 구현되고 이식되며 분배되는 구성 요소 보다는 그 자체의 부분들에 데이터를 전달하기 때문에 높은 호환성의 가능성을 소셜 시큐리티한다.

또한 상기 렌디션들은 코드, 데이터 및/또는 콘텐트를 공유하고 상기 프린트다트 (PrintDart) 애플리케이션에 특유한 이벤트 타입들의 서로 관련된 세트들을 알고 있다. 상기 렌디션(R3)은 상기 다른 두 다트디바이스들(DartDevices)을 미리 알지 못하며 그러한 디바이스들이 상기 셀폰 또는 프린트다트를 미리 알지 못한다 하더라도 프린트픽쳐 다트를 다트디바이스들에 지능적으로 확장(spread)할 수 있다.

상기 셀폰 상에서 동작하는 렌디션(R3)은 이벤트들을 알려서 상기 세 개의 디바이스들 상 또는 간에 수행되는 이벤트 구동 다트런타임(event driven DartRuntime) 동안의 상기 리쿠루트된 NAS 및 프린터 디바이스들 간의 픽처들의 선택 및 프린팅을 제어할 수 있다.

또한 프로토콜의 임의의 조합이 상기 셀폰과 상기 NAS 디바이스의 공통 프로토콜들에 따라 사용될 수 있으며 상기 모집된 프린터 디바이스의 임의의 공통 프로토콜들에 사용되도록 독립적으로 선택될 수 있다. 또한, 모든 디바이스들이 이식된 다트엔진을 다트플레이어의 일부로서 포함하기 때문에, 상기 디바이스들은 상이한 프로세스들 상에서 상이한 운용 시스템들을 동작시키더라도 상호 운용될 수 있다.

본 발명이 밀접하게 결합된 복잡한 상호 관련성들을 가질 수 있는 다수의 구 성 요소들을 구비하는 시스템을 포함하기 때문에, 구성 요소의 존재 이유와 구성 요소의 동작 및 다른 구성 요소와의 상호 동작 방식에 대한 이해를 도모하기 위하여, 상기 구성 요소들의 일부를 먼저 개략적으로 설명한다. 그리고 나서 다른 구성 요소들과의 상호 작용과 관련하여 각 구성 요소를 더 상세히 설명한다. 본 발명에서 구현되는 상호 운용성 측면에서 종래 기술을 크게 개선하기 위해서는 기능들로 패싱(passing)되는 데이터로부터 현재 널리 사용되는 객체 지향적(object oriented) 방법들로의 이동(move)과 유사한 새로운 형태의 소프트웨어 에코시스템(ecosystem)을 생성하는 것이 요구된다. 본 발명의 시스템, 데이터, 코드 및 구조를 더 용이하게 설명하기 위해서는 본 발명의 실시예들의 이론, 개념, 특징 및 구성 요소들을 설명하기 위하여 먼저 몇몇 새로운 용어들을 소개하는 것이 유용하다.

일 실시예에 있어서, 본 발명은 모집(Recruiment), 상호운용 인스트럭션 세트(Interoperability Instruction-set), 렌디셔닝(Renditioning), 크리에이셔니즘(Creationism), 수직 레이어링(Vertical Layering), 선형 태스킹(Linear Tasking), 소셜 싱크러니제이션(Social Synchronization), 소셜 시큐리티(Social Security) 및 버츄얼 포인터들(Virtual Pointers)과 같은 9개의 실시(enabling) 방법들을 구현하는데, 그 중의 일부는 선택적일 수 있으나 포함되는 것이 바람직하다.

디바이스 "모집"은 디바이스 상호 작용 모델(device interaction model) 및 관련된 구조 및 방법들을 포함할 수 있으며, 기존의 클라이언트/서버 및 리어-투- 피어(peer-to-peer) 모델들의 바람직한 대안이 된다. 상기 "상호운용 인스트럭션 세트"는 디바이스들 간에 공통적이고 효율적이며 실행가능한 환경을 제공하며 디바이스의 고유한 능력들(capabilities)을 다른 디바이스들에 노출시키기 위한 프로그램적 구조를 제공한다. "렌디셔닝"은 애플리케이션, 데이터, 콘텐트 및/또는 다른 정보들을 용이하게 테스트하고 효율적으로 적응시킬 수 있게 하는 구조 및 방식을 의미한다. 본 발명의 일부 형태들에 있어서, 렌디셔닝은 코드, 데이터 및 콘텐트의 그룹들을 독립적으로 실행가능한 이미지들로 효율적으로 구분(segment)하는 것을 포함할 수 있으며, "렌디션들(Renditions)"은 다수의 디바이스들에 걸쳐서 지능적으로 생성되고 분배된다. "크리에이셔니즘"은 연결된 디바이스들간 및 단속적으로 연결된 디바이스들에 걸쳐서 상이한 형태로 애플리케이션, 데이터, 콘텐트 및/또는 기타 정보를 동적이면서도 효율적으로 생성 및 분배할 수 있게 하는 구조 및 방식을 의미한다. "수직 레이어링"은 툴, 애플리케이션, 프레임워크, 엔진 및 인스트럭션-세트 레벨들에서의 긴밀한 협동(close cooperation)을 본질적으로 수반하는 특징들을 효율적이면서도 효과적으로 구현할 수 있게 하는 구조 및 방식을 의미한다. "선형 태스킹"은 상기 디바이스들의 프로세싱 유니트들 간의 프로세서 컨트롤 및 디바이스 리소스들의 간단한 결정 플로우를 가능하게 하여, 상기 프로세싱 유니트들이 다트로 컴파일(compile)된 프로세싱 유니트들, 개별적으로 컴파일된 다트들 및 심시지어는 다른 디바이스들 상에서 동작하는 다트들 또는 렌디션들을 포함하는 단일 하이어라키(hierarchy)로 용이하게 재구성될 수 있게 한다. "소셜 싱크러니제이션"은 사용자 개입이 최소이거나 전혀 없는 소정 개수의 디바이스들에 걸쳐셔 데 이터 또는 콘텐트를 동기화하기 위한 효율적인 시스템 및 방식을 의미한다. "소셜 시큐리티"는 최소의 사용자 개입으로 상호 운용할 적절한 권한을 가지는 디바이스들의 그룹들을 용이하게 구성(establish)하고 유지하기 위한 효율적인 시스템 및 방식을 의미한다. 상기 및 기타 구성 요소들은 디바이스의 프로세서 내에서의 수행을 위한 실행가능한 인스트럭션들을 포함하는 컴퓨터 프로그램 코드 세그먼트들의 형태로 구현될 수 있다. 더욱이 이러한 구성 요소들(components)의 성분(elements)들은 하드웨어 및/또는 소프트웨어를 구비하는 하드웨어 및/또는 펌웨어(firmware) 및/또는 마이크로코드(microcode)의 조합으로 구현될 수 있다.

선택적이지만 바람직하게는 제공되는 다른 실시 방법을 "버츄얼 포인터들(Virtual Pointers)"라 칭하며 이러한 버츄얼 포인터들은 예를 들어 하기와 같은 여러 가지 바람직한 특성들을 포함하는 가상(virtual) 메모리에 대한 여러 가지 중대한 개선점을 제공한다.

(a) 다수의 큰 독립 어드레스 스페이스들

(b) 실제(real) 메모리 페이지들의 수에 대한 애플리케이션 전용 제어(application specific control).

(c) 스토리지 디바이스 성능 특성을 매치하는 실제 메모리 페이지 사이즈들에 대한 디바이스 전용 제어.

(d) 프로그래머가 데이터 구조들과 리스트들을 위해 필요한 메모리의 양을 예측하고 관리할 필요가 없음.

(e) 페이지 사이즈 또는 페이지 개수에 무관한 형태로 데이터를 자동으로 세 이브(save)함.

(f) 크고 저속일 수 있는 데이터 기억 장치로부터의 데이터를 최소 용량의 값비싼 고속 RAM으로 효과적으로 저장(cache)하여 애플리케이션들이 실제 물리적으로 구비하는 것 보다 더 큰 RAM 메모리들을 구비하는 것처럼 동작하는 것을 허용함.

(g) 데이터 및 인덱스들이 상이한 버츄얼 포인터 어드레스 스페이스들에 보존되는 인덱스된 데이터베이스 동작을 위한 간단하면서도 효율적인 기본 인프라스트럭쳐(base infrastructure).

상기에서는 본 발명의 방식들, 구성 요소들 및 특징들을 개략적으로 설명하였으며, 하기에서는 본 발명의 원리들, 방식들, 구조들 및 방법들의 실시예들에 대해 상세히 설명한다. 본 발명의 프로시져들 및 방식들은, 마이크로컨트롤러(microcontroller), 프로세서, 마이크로프로세서(microprocessor), 중앙처리장치(central processing unit: CPU), 또는 컴퓨터 프로그램 코드로 소프트웨어, 펌웨어 또는 그 조합의 형태로 실행 또는 동작할 수 있는 기타 프로세싱 하드웨어 또는 로직 등과 같은 범용 또는 전용 프로세싱 로직으로 수행될 수 있는 하나 이상의 컴퓨터 프로그램들 또는 컴퓨터 프로그램 제품들로 구현될 수 있다.

제공되는 섹션 제목들은 독자들의 주의를 특정 형태 및 방법이 설명되는 명세서의 부분들로 환기하기 위한 것이며, 모든 방법들 및 구조들의 형태들은 명세서 전체에 걸쳐서 그리고 도면들 및 청구항들에서 설명되는 것으로서, 부제가 달린 섹션내에 존재하는 본 발명의 소정 형태의 포함 또는 배제가 한정적인 의미로 여겨져 서는 안된다.

II . 모집 상호 운용 모델 ( Recruitment Interoperability Model )

"리쿠루트먼트"는 본 발명의 구현을 통해 구체화되는 장치 상호 작용 모델 및 방법론을 포함한다. 리쿠루트먼트는 당해 기술 분야에서 현재 사용되는 방법론들 및 피어-투-피어 장치 상호 작용 모델들 및 클라이언트/서버에게 있어 바람직한 대안이 된다. 리쿠루트먼트 모델 및 방법론은 모든 장치에 대하여 동작하는 공통의 절차상 환경을 이용한다. 모든 장치들은 상호 운용하거나, 또는 가능한 상호 운용 계획에 있어서 리소스들에 대하여 인스펙션을 받는다. 본 발명의 일 실시예에 있어서, 이러한 공통의 절차상 환경은 다트 인스트럭션 세트(예를 들면, DartinstructionSet) 또는 본 명세서 또는 동등물에서 기술되는 공통의 절차상 환경에 대한 요구 조건들을 충족시키는 다른 이름의 임의의 인스트럭션세트 같은 인스트럭션세트에 의해 제공된다.

도 5를 참조하면, 리쿠루트먼트 프로시져의 일 실시예에 대한 순서도가 도시된다. 상기 순서도는 소프트웨어 애플리케이션이 마치 모든 장치들의 결합된 리소스들을 갖는 하나의 장치인 것처럼 복수의 장치들 또는 팀 장치들을 리쿠루트하고 후에 효과적으로 찾아내기 위한 방법을 제공한다. 또한 도 6에서 공유된 슬라이드 쇼(10000)를 위한 리쿠루트먼트의 예를 나타낸다. 도 7에서 슬라이드 쇼(20000)로부터 하나 이상의 슬라이드들의 원격 인쇄에 대한 장치 리쿠루트먼트의 예가 수행된다. 리쿠루트먼트는 소프트웨어 애플리케이션이 마치 모든 장치들의 결합된 리소스들을 갖는 하나의 장치인 것처럼 장치들의 집합체, 팀 장치들, 또는 다른 복수의 장치들 및/또는 시스템들을 리쿠루트하고 효과적으로 찾아내기 위한 방법을 제공한다.

리소스는 실질적으로 임의의 하드웨어, 소프트웨어, 펌웨어, 통신 성능, 구성, 데이터 또는 데이터 세트, 장치 또는 시스템에 의해 접근가능하거나 또는 소유되는 성능일 수 있다. 리소스는, 예를 들면, 프로세서, CPU, 메모리, 접촉 목록, 사운드 출력 장치, 디스플레이 타입, 다트들, 영상들, 또는 임의의 다른 절차상, 구조상, 또는 정보 아이템이 될 수 있다. 성능은, 예를 들면, 엠펙(mpeg) 파일을 복호화하거나 블루투스 장치들과 통신 등을 하도록 목록, 하드웨어 또는 소프트웨어를 분류하는 컴퓨터 코드가 될 수 있다. 시작 장치와는 별도로 리쿠루트가능하거나 리쿠루트된 장치의 적합성에 관하여 복잡한 결정들을 행하여 프로시져를 전송하려는 애플리케이션의 의도 또는 애플리케이션의 의도의 일부를 수행하도록(본 명세서에서 기술되는 프로그래밍 및 지지(supporting) 구조들, 플랫폼들, 엔진들 등에 의해) 리쿠루트먼트 프로시져는 지능을 갖는다.

하나의 실시예에서, 시작 장치는 우선 소스 또는 시작 장치로서 그 자체에서 복수의 통신 프로토콜들을 통하여 복수의 도달가능한 장치들로 메시지를 공통 실행가능한 형식에 있어서 인스펙션 프로시져 또는 프로시져들의 형식으로 전송 또는 브로드캐스트한다(도 6의 10011 및 도 7의 20011를 참고). 시작 장치는 필요한 리소스들 또는 성능들을 가진 다른 장치들을 찾아내기 위하여 메시지를 형성 및 전송한다. 공통의 절차상 환경에서 구조화된, 코드화된, 또는 구현된 복수의 프로시져들 또는 프로시져가 연결(들)을 통하여 다른 장치들(통신시에 알려짐 또는 알려지 지 않음)에 전송, 송신, 브로드캐스트, 또는 통신된다. 상기 다른 장치들 역시 공통의 절차상 환경을 포함한다. 시작 장치는 메시지를 전송 또는 브로드캐스트할 때에 어느 장치에 도달가능한지를 알 필요가 없다. 어느 장치들이 도달가능한지 여부는, 예를 들면, 후보 리쿠루트된 장치들의 가능한 세트와 비교하여 개시(initiator) 장치가 갖는 통신 채널들 및/또는 프로토콜들에 달려 있다.

이러한 소스 장치는 대안적으로 개시 장치라고 일컬어지며, 이는 소스 장치가 상호 작용을 개시(도 6의 10100 및 도 7의 20100을 참조)하기 때문이다. 소스 장치는 개시 장치라고 일컬어지기보다 리쿠루트된 장치들, 목적 장치들, 목표 장치들, 또는 단순하게 다른 장치들이라고 일컬어진다.

예를 들면, 만약 개시 장치가 블루투스 무선 통신 링크를 포함한다면, 적외선 통신 링크 및 IEEE 802.11(a)(b) 또는 (g) 통신 링크들이 이러한 채널들 각각을 통하여 메시지를 브로트캐스트한다. 이후 이러한 통신 링크들을 통하여 통신을 수신하도록 구성된 후보 리쿠루트가능한 장치들만이 리쿠루트먼트 메시지를 수신할 수 있다. 이러한 장치들 중 동작 환경을 제공 및 인스펙션 프로시져를 이해하고 실행할 수 있는 장치들만이 응답할 것이다. 이러한 응답가능한 장치들 중에서도, 다른 리쿠루트가능한 장치의 사용자가, 예를 들면, 보안 설정에 따라서 선택적으로 또는 포괄적으로 리쿠루트먼트 또는 인테러게이션(interrogation) 인스펙션 프로시져를 차단한다.

두번째, 필요한 리소스들 및 성능들 및/또는 장치의 리소스들 및 성능들의 상호 관련 세트들, 또는 애플리케이션 또는 애플리케이션의 의도의 일부를 수행하 기 위한 장치가 이용가능한 리소스들 등을 식별하기 위하여 인스펙션 프로시져는 응답한 및 발견된 각 장치에 대하여 인스트럭션들을 실행한다. 하나의 실시예에서, 특정 장치 및 장치의 특정 HAL(예를 들면, 도 27의 HAL(652)를 참조)에서 저장 또는 계산되는 상기 특정 장치의 리소스들 및 성능들 대한 정보에 액세스하도록, 이러한 인스펙션은 후보 리쿠루트가능한 장치의 HAL(Hardware Abstraction Layer)에 액세스 또는 상기 HAL의 호출로 귀착하는, 예를 들면, 다트 인스트럭션 세트 프로파일 인스트럭션(예를 들면, DartinstructionSet PROFILE_INSTRUCTION) 같은 인스트럭션 세트 프로파일 또는 겟(get) 프로파일 인스트럭션의 사용에 의해 수행된다.

세번째, 인스펙션 프로시져들은 프로시져들, 데이터, 콘텐트 또는 다른 정보를 메시지를 수신하였다는 것을 지시하는 프로토콜 및 통신 채널(도 6의 10012 및 도 7의 20012를 참조)을 통하여 시작 장치에 반환한다. 응답 장치는 통신 채널 및 프로토콜을 통해 수신되는 통신 채널 및 프로토콜의 지시와 선택적으로 장치의 식별 번호를 식별 및 저장할 수 있으며, 여기서 리쿠루트먼트 메시지는 상기 장치로부터 수신된다. 또는 응답 장치는 개시 장치에 의해 수신될 수 있는 응답을 브로트캐스트할 수 있다.

몇 가지 실시예들에서, 응답 장치는 특정 리소스 또는 리소스들의 세트(예를 들면, 칼라 인쇄 성능)의 이용가능성에 관한 개시자(initiator)의 문의에만 대답한다. 반면, 다른 실시예들에서, 인스펙션 프로시져는 특징들, 성능들, 및 리소스들의 완전환 목록을 식별 및 응답할 수 있다. 일반적으로, 필요한 리소스를 가지고 있다는 뜻으로 단순한 예스가 바람직하며, 그 결과 통신 사이즈가 최소화된다. 하 나 이상의 타입들 또는 클래스를 식별하는 코드들, 또는 리소스 또는 리소스 하위클래스의 코드들이 대안적으로 사용될 수 있다. 하나의 실시예에서, 인스펙션 프로시져들은 상기 인스펙션 프로시져들이 적용되는 장치의 리소스들 및 성능들에 관한 정보를 소스 장치에 반환한다. 이러한 정보는, 예를 들면, 정적 데이터 구조, 프로시져, 다트, 자유 형식 태그된 언어, 또는 임의의 다른 정보 형태를 취할 수 있다. 도 6의 슬라이드 쇼 예(10000)에 있어서 도 6의 예스 응답(10012) 및 MIPS에서의 처리 속도 및 도 6의 리쿠루트된 다트 장치(10200)의 바람직한 디스플레이 해상도, 그리고 도 7의 슬라이드 인쇄 예에 있어서 도 7의 예스 응답(20012) 및 도 7의 리쿠루트된 다트 장치(20200)의 바람직한 프린터 해상도를 참조하라.

네번째, 시작 장치에 관한 애플리케이션 코드는 도달 가능하고 응답하는 모든 장치들로부터의 프로시져들, 데이터, 콘텐트, 또는 다른 정보를 포함하는 모든 반환된 정보를 수집하고, 수신된 임의의 프로시져들을 실행하고, 도달가능한 장치들을 어떻게 사용할 것인가를 결정하기 위하여 상기 도달가능한 장치들 및 애플리케이션의 의도를 수행하도록 상기 도달가능한 장치들의 리소스들을 인스펙션한다.

다섯번째, 시작 장치에 관한 애플리케이션 특정 코드는 상기 네번째(도 6의 10020, 10021 및 도 7의 20020, 20021를 참조)에서의 결정에 따라서 필요로 하는 도달가능한 장치들 각각에 코드, 데이터, 콘텐트, 또는 임의의 다른 정보를 확산시킨다. 애플리케이션 코드, 데이터, 콘텐트, 또는 다른 정보는 본 발명의 실시예들에 따라서, 렌디션들 및 형성론과 관련되어 기술되는 방법들을 이용함으로써, 또는 다른 방법들 및 기법들에 따라서 단일의 공통 형태로 전송될 수 있거나 또는 개별 화(customize)될 수 있다.

여섯번째, 코드, 데이터 및 콘텐트는 도달가능한 장치들에 상주하는 애플리케이션 코드, 데이터 및 콘텐트와 함께 시작 장치들 및 초기에 도달가능한 장치들에 걸쳐서 선택적이지만 바람직하게 반복적으로 확산되고, 필요한 경우에는 도달 가능한 장치들의 초기 세트에 관한 상기 첫번째 단계 내지 다섯번째 단계를 이용하여 반복적으로 더욱 확산된다. 필요한 경우에 본래의 애플리케이션 의도를 수행하는데 필요로 하는 또는 요망되는 모든 장치들 및 리소스들에게 도달될 때까지, 상기 초기 세트는 시작 장치들(두번째 또는 후속의 시작 장치들)로서 역할을 하여 필요로 하는 애플리케이션을 다른 도달가능한 장치들에게 확장시키고, 효과적으로 장치들 및 상기 장치들의 관련된 리소스들의 완전한 팀을 형성한다. 만약 첫번째 라운드에서 필요한 리소스들을 구비한 장치들이 식별된다면, 리쿠루트먼트의 두번째 또는 후속 라운드가 필요하지 않다는 것은 자명하다. 반면에, 만약 초기에 필요한 또는 요망되는 리소스들이 발견될 수 없다면, 반복적인 리쿠루트먼트의 두번째 또는 후속 라운드가 필요할 수 있다. 첫번째 라운드 리쿠루트된 장치를 통해 동작하는 본래 개시자가 두번째 라운드 리쿠루트된 장치(예를 들면, 블루투스 통신을 하드웨어에 내장된 네트워크 연결로 번역하는 동작을 행함)와 통신할 수 있도록 반복적인 리쿠루트먼트 또한 브리지 또는 번역기로서 동작하는 첫번째 라운드 리쿠루트된 장치의 가능성을 증가시킨다.

일곱번째, 코드, 데이터 및 콘텐트는 시작 애플리케이션의 필요에 따라 디바이스들의 팀으로 부터 및 디바이스들에게 분배되어, 시발 애플리케이션의 의도를 수행하기 위하여 요망되는 동작들 및 리소스 액세스를 수행한다. 상기 본래 애플리케이션 의도는 시작 애플리케이션의 의도를 수행하도록 장치들의 팀에 걸쳐서 수행되는 동작들을 수행하거나 또는 조정하기 위해 필요로 하는 또는 요망되는 코드, 데이터, 콘텐트, 또는 다른 정보를 교환함으로써 그리고 코드를 실행함으로써 수행된다.

실행가능한 코드, 데이터, 및 콘텐트를 분배하는 단계는 애플리케이션의 진행중인 동작이 될 수 있으며, 기본적으로 상기 프로세스에 촛점이 맞춰져 있다. 팀의 멤버들을 설립하는 확산 데이터, 코드 및 콘텐트는 애플리케이션의 일부를 수행하기 위하여 필요한 수단으로 팀을 형성한다. 상기 프로세스는 애플리케이션의 의도 또는 태스크를 계속 수행한다. 슬라이드 쇼의 예에서, 슬라이드들(실제로 디지털 이미지들 또는 데이터 세트들)은 조인트 슬라이드 쇼에 추가되거나, 또는 슬라이드들은 모든 장치들을 뷰잉하기 위해 모든 디바이스들 상에서 플립(flip) 또는 연속적으로 디스플레이될 수 있다. 이러한 초기 리쿠루트먼트 단계를 넘어 상호작용을 계속하기 위한 프로시져들은 본 명세서의 다른 곳에서 기술된다.

이것은 초기 리쿠루트먼트 단계를 완성시키고, 리쿠루터(개시자) 또는 리쿠루티들(recrutees)(다른 팀 장치들)이 상호작용 및 리소스들을 공유하는 기회(본 명세서의 다른 곳에서 기술됨)를 제공한다. 이는 도 6의 10031, 10032, 10033을 참조하면 알 수 있다.

장치들에 걸친 애플리케이션의 동작들은 이후 이벤트들(800)(도 17을 참조)을 가짐으로써 동시에 진행될 수 있다. 이벤트들(800)은 본 명세서의 다른 곳에서 기술되는 애플리케이션의 프로세싱을 구동시킨다. 그리고 바람직하게 이벤트들(800)을 통해 애플리케이션에 대한 모든 입력이 얻어지고, 모든 리쿠루트하는 및 리쿠루트된 장치들의 큐에 위치되며, 여기서 장치들은 이벤트 타입을 위해 동시에 진행되는 것과 같이 표시된다. 이벤트들 및 큐잉(queuing)하는 이벤트는 도 17과 관련하여 이하에서 매우 상세하게 기술된다.

도 17를 참조하면, 이벤트들(800)은, 이러한 실시예에서, 도 17의 이벤트(800)에서 나타나는 바와 같이 이벤트 타입(801), 이벤트 파라미터(802) 및 이벤트 관련 파일(810)을 포함하는 데이터 구조 인스턴스들이 될 수 있으며, 여기서 이벤트 관련 파일(810)은 프로시져(811), 콘텐트(812), 및/또는 다트(813)를 포함할 수 있다. 이러한 이벤트들(800)은 입력을 제공하고, 데이터 및 시맨틱들을 통신하고, 런타임 동안 플로우되는 동기화 함수들을 수행한다. 상기 런타임은 다트런타임(8000)(도 15를 참조), 기즈모스(Gizmo) 계층구성(10000)(도 18를 참조), 또는 451-x로 라벨 붙여진 라인들을 따라 있는 다트 장치들(400) 사이가 될 수 있다.

이벤트들(800)은 참조들을 임의의 데이터 종류, 종류들 또는 많은 데이터를 위한 파일들(810)로 운반할 수 있다. 참조들은 바람직하게 개방 파일들로 형성될 수 있다. 전형적으로 상기 파일들은 하나 이상의 다른 다트 장치상에서 동작하는 다트프로시져들을 포함한다. 그리고 상기 파일들은 다른 다트 장치에 대하여 다트 애플리케이션의 도달을 연장시키는 다트들, 다른 장치에 대한 제어 패널을 포함하는 다트, 또는 도 17의 800에서 나타나는 바와 같이 이벤트의 다른 파라미터들에 다른 경우라면 적합하지 않은 일반적인 목록 또는 입력 정보를 완성시킨다. 이러한 그리고 다른 다트 타입들 및 일반적인 목록 또는 입력 정보는 본 명세서에의 다른 곳에서 매우 상세하게 기술된다. 이벤트 프로세싱은 도 15의 다트런타임 순서도들(8000) 및 도 16의 엔진 이벤트 프로세싱 내장 함수 순서도들(5000)에서 더 자세하게 도시된다.

이벤트(800)와 관련된 파일(810)은 이벤트와 관련된 파일을 이벤트로부터 분리된 것으로 또는 바람직하게 이벤트의 부분으로 생각할 수 있다. 이는 본 발명의 하나의 실시예에서 이벤트들을 전송하는 구조상 및 방법론상 기반구조가 이벤트들과 함께 관련된 파일을 자동적으로 전송하기 때문이다. 그러므로, 적어도 하나의 실시예에서, 이벤트가 이벤트 수신자의 이벤트 큐에 위치되기 전에, 통신 기반구조에 의하여 전송 측상에서 참조되는 파일이 수신자 측상의 파일로 복사된다. 수신자 측상의 파일은 수신자 장치상에 복사된 파일 이미지와 관련된(예를 들어, 보존) 파일 식별자을 이용하여 판독될 수 있다. 공통의 또는 구별되는 파일 이름들 또는 파일 식별자들이 송신자 및 수신자 측상에서 이용될 수 있다. 런 다트(예를 들어, RUN_DART 타입 이벤트) 또는 런 프로시져(예를 들어, RUN_PROCEDURE) 타입 이벤트 경우에 있어서, 상기 이벤트가 큐의 헤드 또는 상부에 도달하여 그 결과 큐의 다음에 위치하는 경우에, 엔진은 필드를 이용하여 판독될 수 있는 다트프로시져 또는 다트가 실행될 수 있게 한다. 어떠한 애플리케이션도 현재 동작하지 않는 경우에도 일반적으로 타트 엔진 자신에 의해 처리되는 이벤트들이 존재할 수 있다. 하나의 실시예에서, 언제나 이벤트 큐의 구동은 통신들을 계속하도록 엔진 이벤트 프로세싱 프로시져을 계속 호출하는 엔진 내에 내장된 아이들(idle) 프로시져(예를 들어, 다트아이들프로시져)또는 동작중인 다트가 된다. 이것은 본질적으로 처리할 이벤트가 있을 때까지 계속 동작하는 루프가 된다. 파워 관리(본 명세서의 다른 곳에서 기술됨)가 적용되는 경우에, 이러한 루프를 정지 및 이후 지정시간에 동작 또는 재시작시키기 위한 다양한 기법들이 구현될 수 있다.

따라서 상기 모집 모델, 방법 및 관련된 스트럭쳐들이 애드-혹(ad-hoc) 디바이스, 서비스 및 리소스 발견을 수행하여 필요한 디바이스들을 확인하고, 이벤트들(800)과 같은 이벤트 데이터 스트럭쳐를 이용하여 실시 프로시져들 및 정보를 상기 디바이스들에 전달하며, 디바이스들의 팀을 지능적 및 효과적으로 형성하고, 이벤트 데이터 스트럭쳐(이벤트들 800)를 다시 이용하여 상기 디바이스들의 팀을 조정(coordinate)하여 상기 소스 디바이스 상에서 원래 동작하던 다트(700) 또는 애플리케이션의 원래의 목적을 달성하도록 한다는 것을 이해할 수 있을 것이다.

도 10은 모집 연결된 디바이스들의 그룹을 마치 단일한 디바이스인 것처럼 동작하게 만드는 방식을 도시하고 있다. 이것의 가장 의미 있는 효과들 중의 하나는 새로운 상호운용 디바이스와 다트 기반 애플리케이션의 구현과 테스트가 디바이스들(N)의 갯수에 비례하는 노력만을 요구한다는 점이다. 종래의 정적 및 철차적인 접근 방식은, 상호 운용될 필요가 있는 모든 디바이스들로 구성 요소들을 개별적으로 구현하고 분배할 필요가 있는 경우에, N의 자승에 비례하는 속도로 증가하는 노력을 요구한다.

모집된 디바이스들 간의 이벤트들의 시리얼리제이션(serialization) 및 싱크러니제이션(synchronization)을 포함하는 모집의 다른 형태 및 상기 모집 상호운용 모델이 실시예들을 포함하는 본 명세서에서 설명된다. 상기 모집 상호운용 모델의 일부 특정 실시예들도 하기에서 설명된다.

일 실시예(1)에 따르면, 본 발명은 소스 디바이스에서 동작하는 소프트웨어 애플리케이션으로 디바이스들의 팀을 모집하는 방법에 있어서, 시작 소스 디바이스 및 그 자체가 도달될 디바이스 모두에 공통되는 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 필요한 리소스 또는 능력을 가지는 디바이스를 발견하도록 동작하는 인스펙션 프로시져를, 적어도 하나의 통신 링크를 통해 상기 시작 소스 디바이스와는 다른 적어도 하나의 도달가능한 디바이스로 전달하는 단계와; 상기 시작 디바이스에서 도달가능한 디바이스들 각각으로부터의 리턴 응답을 통신 링크를 통해 직접적으로 또는 간접적으로 수신하는 단계와; 상기 시작 디바이스에서 실행되는 프로시져를 통해 도달가능한 모든 응답 디바이스들로부터 수신된 리턴 응답들을 분석하여 상기 소프트웨어 애플리케이션의 목적을 가장 잘 수행할 수 있는 상기 도달가능한 응답 디바이스들과 상기 시작 소스 디바이스의 능력들 및 리소스들의 조합을 확인하기 위한 유틸리제이션 플랜(utilization plan)을 결정하는 단계와; 상기 시작 디바이스에서 실행되는 애플리케이션 프로그램을 통해 코드, 데이터, 콘텐트 및/또는 다트(Dart) 중의 적어도 하나를 상기 결정된 유틸리제이션 플랜에 따라 필요한 리소스 또는 능력을 가지는 것으로 확인된 상기 도달가능한 각 디바이스들 중의 적어도 하나에 분배하는 단계를; 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법을 제공한다.

다른 실시예(2)에 따르면, 본 발명은 디바이스들의 팀을 모집하는 방법에 있 어서, 수신 디바이스와 모집 디바이스 모두에 알려진 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 도달가능한 수신 후보 디바이스가 통신 링크 상의 다른 모집 디바이스에 요구되는 리소스 또는 능력를 구비하는지의 여부를 결정하도록 동작하는 인스펙션 프로시져를 후보 디바이스에서 수신하여 실행하는 단계와; 상기 수신된 인스펙션 프로시져를 위한 소스 디바이스를 확인하고 상기 도달가능한 수신 디바이스가 상기 시작 소스 디바이스에 의해 요구되는 것으로 확인된 리소스 내지 능력 또는 리소스들 및 능력들의 조합에 액세스하는지의 여부에 대한 상태 및 정보를 상기 소스 디바이스에 리턴 응답으로 전달하는 단계와; 상기 소스 디바이스에 의해 상기 도달가능한 디바이스가 소프트웨어 애플리케이션의 목적을 수행하기 위한 팀을 구성하는데 필요한 리소스들 또는 능력들을 구비하는 것으로 판단되는 경우, 실행가능한 코드, 데이터, 콘텐트 및/또는 다트 중의 적어도 하나를 상기 소스 디바이스, 모집 디바이스 또는 다른 후보 디바이스로부터 수신하는 단계를; 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법을 제공한다.

다른 실시예(3)에 따르면, 본 발명은 디바이스들의 팀을 모집하는 방법에 있어서, (a) 시작 소스 디바이스 및 그 자체가 도달될 디바이스 모두에 공통되는 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 필요한 리소스 또는 능력을 가지는 디바이스를 발견하도록 동작하는 인스펙션 프로시져를, 상기 시작 소스 디바이스로부터 적어도 하나의 통신 링크를 통해 상기 시작 소스 디바이스와는 다른 적어도 하나의 도달가능한 디바이스로 전달하는 단계와; (b) 상기 도달 가능한 디바이스들 각각에서 상기 인스펙션 프로시져들을 수신 및 실행하여 상기 시작 소스 디바이스에 의해 요구되는 상기 도달가능한 디바이스의 적어도 하나의 리소스 또는 능력이 존재하는지의 여부를 확인하는 단계와; (c) 적어도 상기 도달가능한 디바이스가 상기 시작 소스 디바이스에 의해 요구되는 것으로 확인된 리소스 또는 능력에 액세스하는 경우에 상기 시작 소스 디바이스로 리턴 응답을 전달하는 단계와; (d) 상기 도달가능한 디바이스들 각각으로부터 상기 리턴 응답을 상기 통신 링크를 통해 직접 또는 간접적으로 수신하는 단계와; (e) 상기 시작 디바이스에서 실행되는 프로시져를 통해 도달가능한 모든 응답 디바이스들로부터 수신된 리턴 응답들을 분석하여 상기 소프트웨어 애플리케이션의 목적을 가장 잘 수행할 수 있는 상기 도달가능한 응답 디바이스들과 상기 시작 소스 디바이스의 능력들 및 리소스들의 조합을 확인하기 위한 유틸리제이션 플랜(utilization plan)을 결정하는 단계와; (f) 상기 시작 디바이스에서 실행되는 애플리케이션 프로그램을 통해 코드, 데이터, 콘텐트 및/또는 다트(Dart) 중의 적어도 하나를 상기 결정된 유틸리제이션 플랜에 따라 필요한 리소스 또는 능력을 가지는 것으로 확인된 상기 도달가능한 각 디바이스들 중의 적어도 하나에 분배하는 단계를; 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법을 제공한다.

다른 실시예(4)에 따르면, 본 발명은 상기 적어도 하나의 도달가능한 디바이스로 상기 분배된 실행가능한 코드, 데이터, 콘텐트 및/또는 다트 중의 적어도 하나를 수신하는 단계를 더 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(5)에 따르면, 본 발명은 상기 실행가능한 코드, 데이터, 콘텐트 및/또는 다트 중의 적어도 하나가 분배된 상기 적어도 하나의 도달가능한 디바이스와 상호작용(interoperate)하여 상기 시작 디바이스의 애플리케이션의 목적의 적어도 일부를 수행하는 단계를 더 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(6)에 따르면, 본 발명은 제2 시작 소스 디바이스들의 역할을 하는 각각의 도달가능한 디바이스로, 실행가능한 코드, 데이터, 콘텐트 및/또는 다트를 상기 시작 및 도달가능한 디바이스들에 걸쳐서 선택적으로 확산하고, 이에 더하여 상기 도달가능한 디바이스들에 상주하는 애플리케이션 코드, 데이터, 콘텐트 및/또는 다트들을, 소정 디바이스들의 모든 또는 소정 기준들과 상기 원래의 시작 디바이스 애플리케이션의 목적을 수행하는데 요구되는 리소스들 또는 능력들이 도달될 때까지, 다른 도달가능한 디바이스들에 요구되는 애플리케이션을 확장하는데 필요한 만큼, 이전에 도달되고 팀 구성된 디바이스들에 의해 도달가능한 다른 디바이스들에 더욱 더 회귀적으로(recursively) 확산하는 단계와; 상기 시작 애플리케이션의 목적을 수행하도록 상기 디바이스들의 팀에 걸쳐서 수행될 동작들을 수행 및/또는 조정(coordinate)하는데 필요한 실행가능한 코드, 데이터, 콘텐트 및/또는 다트들을 교환하고 코드를 수행하여, 상기 시작 디바이스의 애플리케이션을 수행하도록 요구되는 동작들 및 리소스 액세스를 수행하는 상기 시작 디바이스 애플리케이션의 요구들에 따라 상기 시작 및 도달가능한 디바이스들의 팀 사이에, 실행가능한 코드, 데이터, 콘텐트 및/또는 다트를 분배하는 단계를; 더 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(7)에 따르면, 본 발명은 상기 시작 소스 디바이스가 상기 리턴 응답을 상기 시작 디바이스가 모집 메시지를 전달했던 처음에 도달된 디바이스로부터 직접적으로 수신하거나, 상기 시작 소스 디바이스가 상기 리턴 응답을 하나 이상의 단속적으로 도달가능한 디바이스들을 통해 직렬 또는 회귀적 방식으로 다른 도달가능한 디바이스로부터 간접적으로 수신하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(8)에 따르면, 본 발명은 상기 도달가능한 디바이스가 상기 시작 소스 디바이스에 의해 요구되는 것으로 확인된 리소스 또는 능력에 액세스하지 않은 경우에도, 상기 시작 소스 디바이스로의 상기 리턴 응답이 전달되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(9)에 따르면, 본 발명은 상기 시작 소스 디바이스로의 상기 리턴 응답이, 상기 시작 소스 디바이스에 의해 요구되는 것으로 확인된 상기 리소스 또는 능력을 자체적으로 구비하거나 액세스하는지(예: 참 또는 논리 "1") 아니면 자체적으로 구비하거나 액세스하는 것이 아닌지(예: 거짓 또는 논리 "0")를 확인하기 위한, 단순 파라미터(simple parameter)인 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(10)에 따르면, 본 발명은 상기 시작 소스 디바이스로의 상기 리턴 응답이 다트이벤트(DartEvent), 다트(Dart)의 일부, 데이터, 콘텐트, 실행가능한 프로시져들, 다트, 다수의 다트들(darts), 및 이들의 조합 중의 하나를 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(11)에 따르면, 본 발명은 상기 시작 소스 디바이스로의 상기 리턴 응답이 통신 프로토콜들로 상기 시작 디바이스로의 특정 도달가능한 디바이스의 리소스들 및/또는 능력들을 확인하기 위한 리턴된 데이터 또는 콘텐트를 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(12)에 따르면, 본 발명은 상기 인스펙션 프로시져가, 상기 시작 소스 디바이스에 의해 요구되는 적어도 하나의 확인된 특정 리소스 또는 능력을 검사(inspect)하여 상기 시작 소스 디바이스의 적어도 일부에서 수행되는 애플리케이션 태스크(task)의 목적을 수행하기 위한, 인스트럭션을 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(13)에 따르면, 본 발명은 디바이스들의 팀에 걸쳐서 애플리케이션을 모집하고 효과적으로 작동시키는 컴퓨터 프로그램 제품으로 인코드된 소프트웨어 애플리케이션에 의해 적어도 부분적으로 구현되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(14)에 따르면, 본 발명은 상기 모집하고 그리고 모집된 디바이스들이 그 디바이스들 모두의 결합된 리소스들을 구비하는 하나의 디바이스인 것처럼 상기 모집하고 그리고 모집된 디바이스들의 제어를 결합해서 허용하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(15)에 따르면, 본 발명은 상기 리턴 응답이, 노 리턴(no return), 데이터 또는 콘텐트 리턴, 디지털로 인코드된 소정 정보, 하나 이상의 프로시져들, 상기 디바이스가 유용할 것이라는 인디케이션(indication), 리턴된 이벤 트(returned event), 해당 파일 페이로드(payload)을 통한 소정량의 데이터 또는 데이터의 세트들(sets)을 포함하는 리턴 이벤트, 리턴 프로시져, 다트(Dart), 상기 시작 디바이스 상의 메뉴로부터 사용할 디바이스(들)을 선택할 수 있도록 텍스트 명칭들(text names) 및 상기 디바이스에 대한 설명들을 포함하는 리턴 이벤트, 상기 소스 디바이스 상에서 상주(reside)하거나 생성될 수 있는 실행가능한 코드, 데이터 및 콘텐트의 세트의 적어도 하나의 인스턴스(instance)의 소정 패키지의 식별자(identifier), 상기 디바이스 상에서 작동하기에 가장 적절한 렌디션(rendition) 또는 렌디션들의 세트, 또는 이들의 조합 중에 하나를 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(16)에 따르면, 본 발명은 상기 적어도 하나의 리소스 또는 능력이, (i) 이용가능한 리소드들 또는 소정의 요구되는 리소스; (ii) 이용가능한 능력들 또는 소정의 요구되는 능력; (iii) 상기 도달가능한 디바이스의 리소스들 및 능력들의 하나 이상의 상호 관련된 세트들 또는 상기 애플리케이션의 목적을 수행하기 위한 상기 도달 가능한 디바이스에 이용가능한 리소스들 및/또는 능력들; 및 (iv) 이들의 소정 조합으로 구성되는, 세트로부터 선택된 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(17)에 따르면, 본 발명은 상기 리소스들 또는 능력들이 리소스들 또는 능력들의 세트로부터 선택된 적어도 하나의 확인된 능력을 포함하되, 상기 리소들 또는 능력들의 세트가 확인된 데이터 조작(manipulation) 소프트웨어, 확인된 정보 프로세싱 소프트웨어, 확인된 계산 소프트웨어, 확인된 픽쳐 프로세싱 소 프트웨어, 확인된 통신 소프트웨어, 확인된 통신 하드웨어, 확인된 미디어(media), 확인된 데이터 세트(들), 확인된 콘텐트, 확인된 프로그램 또는 프로그램들, 확인된 구성(configuration) 정보, 확인된 그래픽 가속 하드웨어 또는 소프트웨어, 확인된 임시(temporary) 또는 영구(permanent) 저장 매체, 확인된 프린팅 능력, 확인된 팩싱 능력, 확인된 스캐닝 능력, 확인된 사용자 입력 및/또는 출력 인터페이스(interface) 장치, 상기 디바이스가 통신할 수 있으며 다른 디바이스들이 연속적인 체인(unending chain)으로 통신할 수 있게 하는 다른 디바이스들의 리소스들로의 액세스(access), 및 이들의 둘 이상의 조합으로 구성되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(18)에 따르면, 본 발명은 공통적인 실행가능한 형태의 상기 인스펙션 프로시져들이, 다트 인스트럭션 호환 엔진 (DartEngine) 또는 소정의 다른 상호 운용 인스트럭션 세트(Interoperability Instruction Set)로 구현된 다트 컴플라이언트 인스트럭션 세트(DartInstructionSet)로부터 형성된, 적어도 하나의 인스펙션 프로시져(inspection procedure)를 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(19)에 따르면, 본 발명은 상기 적어도 하나의 통신 링크가, 영구적으로(permanently) 또는 단속적으로(intermittently) 이용가능한 유선 또는 무선의 동종(homogeneous) 또는 이종(hetrogeneous) 통신 프로토콜들의 일부 또는 세트를 포함하는, 소정 개수의 통신 링크들, 채널들 및/또는 프로토콜들을 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(20)에 따르면, 본 발명은 상기 동종 및 이종 통신 링크들, 채널들 및 프로토콜들이, 둘 이상의 통신 디바이스들 상에서 동작하는 플레이어들(players)의 파트들(parts)인, 확인된 하드웨어 앱스트랙션 레이어 수단들(hardware abstraction layer implementations)에 의해 지원되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(21)에 따르면, 본 발명은 상기 확인된 하드웨어 앱스트랙션 레이어 수단들이, 다트엔진들(DartEngines)의 구성 요소들인, 다트 하드웨어 앱스트랙션 레이어 수단(Dart Hardware Abstraction implementation)을 포함하는 것을 특징으로 하는 상기 (20)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(22)에 따르면, 본 발명은 상기 적어도 하나의 통신 링크와 통신 프로토콜을 이용하여 런(run) 프로시져 타입의 이벤트들과 상기 도달가능한 디바이스 상에서 동작하는 상기 프로시져를 확인하는 파일을 참조(reference)하는 이벤트의 식별자를 전달하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(23)에 따르면, 본 발명은 상기 이벤트들이 다트이벤트들(DartEvents)을 포함하며 상기 런 프로시져 타입 이벤트가 다트 런_프로시져 타입 이벤트(Dart RUN_PROCEDURE type event)를 포함하는 것을 특징으로 하는 상기 (22)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(24)에 따르면, 본 발명은 상기 도달가능한 디바이스 상에서 동작하는 프로시져를 확인하는 파일을 참조하는 상기 이벤트 식별자가 상기 도달가능 한 디바이스 상에서 동작하는 프로시져의 이미지를 포함하는 파일을 참조하는 상기 이벤트의 파일 식별자를 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(25)에 따르면, 본 발명은 상기 파일이 상기 다트포맷(DartFormat)에 따르는 다트 컴플라이언트 파일 (DartFile)을 포함하며 상기 프로시져의 이미지가 다트 프로시져(Dart Procedure)의 이진 데이터 이미지(DartProcedure)를 포함하는 것을 특징으로 하는 상기 (24)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(26)에 따르면, 본 발명은 상기 인스펙션 프로시져들이 다트프로시져(DartProcedure) 또는 완전한 다트들(complete Darts)을 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(27)에 따르면, 본 발명은 상기 인스펙션 프로시져들이 이벤트와 관련된 상기 파일들로서 전달되며, 상기 이벤트와 관련된 상기 파일들로서 도달가능한 장치에 의해 상기 인스펙션 프로시져를 수신하는 것에 의해 상기 인스펙션 프로시져가 상기 도달가능한 디바이스들 상의 실행동작을 개시하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(28)에 따르면, 본 발명은 상기 인스펙션 프로시져가 다트프로시져(DartProcedure)를 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(29)에 따르면, 본 발명은 상기 도달가능한 디바이스의 기본 리 소스들 및 능력들을 포함하는 리소스들 및 능력들은 인스트럭션 세트 프로파일 인스트럭션(instruction set profile instruction)을 이용하여 결정되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(30)에 따르면, 본 발명은 상기 인스트럭션 세트 프로파일 인스트럭션이 다트 컴플라이언트 인스트럭션 세트(DartInstructionSet)의 다트 컴플라이언트 프로파일 인스트럭션(Dart PROFILE_INSTRUCTION)을 포함하는 것을 특징으로 하는 상기 (29)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(31)에 따르면, 본 발명은 도달가능한 각각의 디바이스 내에서의 상기 인스펙션 프로시져의 수행은 상기 도달가능한 디바이스 또는 그 각각에 전달되는 렌디션 결정 규칙(rendition determination rule)에 따라 상기 시작 다트 구현 애플리케이션(initiating Dart embodied application)의 최선의 렌디션을 결정하고 상기 결정된 최선의 렌디션(Randition)을 상기 리턴된 데이터의 일부로서 되돌려보내는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(32)에 따르면, 본 발명은 상기 렌디션 결정 규칙은, 소정 복잡도(complexity)의 소정의 필요한 계산을 수행하고 프로파일 인스트럭션을 통해 소정의 필요한 프로파일 정보를 액세스하여 상기 도달가능한 디바이스의 자원들, 능력 및/또는 상태를 결정하기 위한, 적어도 하나의 프로시져로 구현되는 것을 특징으로 하는 상기 (31)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(33)에 따르면, 본 발명은 상기 인스펙션 프로시져 실행은, 렌디션의 순서(order)를 정의하는 규칙들을 참조하여 다수의 렌디션들로부터 최선의 렌 디션을 결정하며, 도달가능한 장치 각각을 체크하여 상기 배열된 다수의 렌디션들 중에서 상기 렌디션의 요구조건들(Rendition's requirements)의 모두를 만족시키는 상기 제1 렌디션이 발견될 때까지 상기 다수의 렌디션들 각각의 모든 요구조건들이 렌디션 우선권의 기 정의된 순서에 부합되는지의 여부를 결정하는 것을 특징으로 하는 상기 (31)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(34)에 따르면, 본 발명은 상기 인스펙션 프로시져(들)가 소정의 통신 프로토콜을 이용하여 상기 통신 링크를 통하여 다트들(Darts), 프로시져들(procedures), 데이터 또는 콘텐트를 상기 시작 디바이스로 리턴(return)하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(35)에 따르면, 본 발명은 상기 리턴들은 리턴된 프로시져들, 데이터 또는 콘텐트 중의 적어도 하나와 완전한 다트들(complete Darts), 다트파트들(DartParts), 다트프로시져들(DartProcedures) 또는 다트이벤트들(DartEvents)의 하나 또는 그 조합을 포함하며, 상기 하나 또는 그 조합은 관련된 이벤트 파일을 이용하거나 이용하지 않고서 리턴되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(36)에 따르면, 본 발명은 상기 리턴은 리턴된 프로시져들, 데이터, 콘텐트 및/또는 다트 중의 적어도 하나를 포함하고 또한 발생된 에러를 나타내는 리턴 코드를 선택적으로 포함하며, 에러 코드를 이용하여 특정 에러 또는 불특정 에러 에러가 발생했음을 확인하고, 상기 에러 코드는 상기 특정 에러 및/또는 에러의 성질을 정정하거나 전달하는데 유용한 정보를 선택적으로 포함하는 것을 특 징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(37)에 따르면, 본 발명은 상기 애플리케이션 코드가 다트(Dart), 다트프로시져(DartProcedure) 또는 상기 시작 디바이스 또는 프로그램의 전달 또는 실행을 개시하고 그 실행의 결과를 이용하기 위해 상기 시작 디바이스에 액세스한 디바이스들 상에서 실행될 수 있는, 소정 형태의 프로그램 중의 적어도 하나인 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(38)에 따르면, 본 발명은 상기 애플리케이션 코드가 다트(Dart), 다트프로시져(DartProcedure) 또는, 실행할 수 있거나 아니면 상기 도달가능한 디바이스(들)로 상기 도달가능한 디바이스 상에서 실행되도록 프로시쥬얼 포맷이 상기 다트인스트럭션세트를 이용하는지의 여부에 대한 정보를 전달하는 제2 프로시쥬얼 포맷을 포함하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(39)에 따르면, 본 발명은 상기 장치들의 모집된 팀이 상기 애플리케이션을 실행하기 위한 소정 주기 동안의 요구에 따라 다른 도달가능한 디바이스들을 포함하도록 그 팀을 확장하거나 도달가능한 디바이스들을 배제하도록 그 팀을 축소하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(40)에 따르면, 본 발명은 상기 분배는 다트들(Darts), 다트프로시져들(DartProcedures), 데이터, 콘텐트 또는 다른 정보들 또는 이들의 소정 조합 중의 적어도 하나를 전달하는 것에 의해 수행되며, 이들은 필드(field)에 의해 참조된 정보가 상기 이벤트를 따라 또는 그 이벤트로서 전달되는지에 따라 다트 이벤 트들(DartEvents)의 일부로서 인캡슐레이트되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(41)에 따르면, 본 발명은 상기 시작 애플리케이션의 요구들에 따라 디바이스들의 팀들 사이에서 분배되는 상기 코드, 데이터 및 콘텐트는, 상기 시작 애플리케이션의 목적을 더 수행하도록 상기 디바이스들의 팀에 걸쳐서 수행될 동작들을 수행 또는 조정(coordinate)하는데 필요한 추가적 또는 상이한 코드, 데이터 및 콘텐트를 선택적으로 교환하고 코드를 수행하여, 상기 시발 애플리케이션의 목적을 수행하도록 요구되는 동작들 및 리소스 액세스를 수행하는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(42)에 따르면, 본 발명은 상기 애플리케이션이, 상기 모집 프로세스의 일부로서 모든 디바이스들에 분배되는 모든 코드를 포함하는, 단일한 이진 이미지로 구현되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(43)에 따르면, 본 발명은 상기 디바이스들의 팀 상의 동작들(activates)에 대한 싱크러니제이션(synchronization), 시리얼리제이션(serialization), 코오디네이션(coordination) 절차들을 더 포함하며, 상기 싱크러니제이션, 시리얼리제이션, 코오디네이션 절차들은 다트이벤트들(DartEvents) 또는 이벤트들과 관련된 파일로 이벤트들 또는 다트이벤트들을 단독적으로 또는 선택적으로 패싱(passing)하거나 교환하는 것에 의해 전체적으로 또는 부분적으로 수행되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(44)에 따르면, 본 발명은 상기 이벤트들은 적어도 하나의 파일을 참조하여 소정 복잡도의 파일 이미지들을 가지는 파일(들)을 효과적으로 포함하거나 병합하며, 상기 파일 이미지들은 상기 이벤트 스트럭쳐 콘텐츠와 함께 전달되는 것을 특징으로 하는 상기 (43)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(45)에 따르면, 본 발명은 상호 운용되고 통신하는 모집된 시작 디바이스들 간에 다트이벤트들(DartEvents)을 다트이벤트들 또는 이벤트들과 관련된 파일을 이용하여 단독적으로 또는 선택적으로 패싱하거나 교환하는 단계를 더 포함하되, 상기 이벤트들은 상기 다트이벤트 스트럭쳐(DartEvent structure)에서의 파일 식별자 (field) 참조에 의해 파일들, 기타 다른 데이터들 또는 소정 복잡도의 데이터 스트럭쳐들을 효과적으로 포함하며, 상기 파일 이미지들은 참조되는 경우에는 항상 상기 이벤트 스트럭쳐 콘텐츠와 함께 전달되는 것을 특징으로 하는 상기 (3)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(46)에 따르면, 본 발명은 상기 다트이벤트들 또는 이벤트들이 상기 다트프레임워크(DartFramework), 다트런타임(DartRuntime) 및/또는 다트엔진(DartEngine)에 의해 또는 넌-다트플랫폼 특정 이벤트 구동 수단(non-DartPlatform specific event driven implementation)에 의해 소정 개수의 팀 디바이스들의 이벤트 큐들(queues)에 걸쳐서 자동적으로 복사 및/또는 동기화되어서, 자동 싱크러니제이션을 위해 확인되고 다트에 의해 이벤트 큐 상에 위치하는 다트이벤트들 또는 이벤트들이 자동적이고 연속적이며 동기적인 방식으로 소정 개수의 팀 장치들의 이벤트 큐들 내부에서 발생되는 것을 특징으로 하는 상기 (43)의 디바 이스 팀 모집 방법을 제공한다.

다른 실시예(47)에 따르면, 본 발명은 시작 디바이스를 포함하는 다수의 상호 운용 디바이스들에 걸쳐서 동작하는 이벤트 구동 상호 운용 애플리케이션들(event driven cooperative applications), 기능들 또는 렌디션들에 대한 자동 시리얼리제이션 및 싱크러니제이션을 위한 프로시져에 의해 상기 자동 시리얼리제이션 및 싱크러니제이션 과정이 이루어지되, 요구되는 인터-디바이스 상호운용 기능(inter-device cooperative function) 각각을 위한 애플리케이션에 의해 상기 시작 디바이스 상의 연결 관리기 오브젝트 인스턴스(connection manager object instance)을 인스텐쉬에이팅(instantiating)하는 단계와; 상기 애플리케이션에 의해 절차적으로(procedurally) 모든 상호운용 디바이스들에 대하여 동기화되는 이벤트 타입들의 리스트를 상기 연결 관리기로 전달하는 단계와; 각 디바이스 상에 하나의 연결 관리기를 구비하는 상호운용 디바이스들의 팀을 구성하고 동일한 리스트의 싱크러니제이션 이벤트 타입들을 공유하는 단계와; 상기 연결 관리기에 의해 팀 구성된 장치들과 동기화되는 이벤트 타입들을 확인하기 위한 세션(sessions) 리스트를 유지하고, 상기 연결 관리기에 의해 상기 이벤트 큐에 위치하는 모든 이벤트들을 검사하며, 검사된 특정 이벤트가 상기 동기화되어져야 할 세션 리스트로부터 상기 연결 관리기가 알게 되는 이벤트 타입인 경우, 상기 다른 세션들과 동기화되는 이벤트로서 상기 이벤트를 마킹하고 상기 이벤트를 상기 연결 관리기 내에서 리스트된 장치들의 이벤트 큐들에 위치시키는 단계를; 포함하는 것을 특징으로 하는 상기 (46)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(48)에 따르면, 본 발명은 상기 이벤트 구동 상호운용 애플리케이션들, 기능들 또는 렌디션들 중의 어느 하나에 의해 상호운용 디바이스 이벤트 큐들상에 위치하는 모든 이벤트들이, 상기 어느 하나의 디바이스에 의해 직접적으로 상기 이벤트가 전달된 모든 상호운용 디바이스 이벤트 큐들이 상기 상호운용 디바이스들의 이벤트 큐들 상에 성공적으로 위치되었다는 긍정응답(acknowledgement)을 수신할 때까지, 이벤트가 상기 어느 하나의 디바이스의 이벤트 큐 상에 위치하는 것을 허용하지 않음으로써, 시리얼라이즈(serialize)되는 것을 특징으로 하는 상기 (47)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(49)에 따르면, 본 발명은 상기 이벤트 구동 상호운용 애플리케이션들, 기능들 또는 렌디션들 중의 어느 하나에 의해 수신되는 상호운용 디바이스 이벤트 큐들상에 위치하는 모든 이벤트들이, 상기 어느 하나의 수신 디바이스에 의해 상기 이벤트가 전달된 모든 상호운용 디바이스 이벤트 큐들이 상기 상호운용 디바이스들의 이벤트 큐들 상에 성공적으로 위치되었다는 긍정응답(acknowledgement)을 수신할 때까지, 이벤트가 상기 어느 하나의 수신 디바이스의 이벤트 큐 상에 위치하는 것을 허용하지 않음으로써, 시리얼라이즈(serialize)되는 것을 특징으로 하는 상기 (48)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(50)에 따르면, 본 발명은 상기 디바이스들이 직접적으로 통신하는지 아니면 직접적으로 통신하는 디바이스들의 체인(chain)을 통해 간접적으로 통신하는지에 따른 소정 개수의 상호운용 디바이스들의 이벤트 큐들이 모든 상호운용 디바이스들에 걸쳐서 큐잉된(queued) 이벤트들의 시리얼라이즈된 단일 시스템을 설 정하는 것을 특징으로 하는 상기 (48)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(51)에 따르면, 본 발명은 상기 디바이스들이 직접적으로 통신하는지 아니면 직접적으로 통신하는 디바이스들의 체인(chain)을 통해 간접적으로 통신하는지에 따른 소정 개수의 상호운용 디바이스들의 이벤트 큐들이 모든 상호운용 디바이스들에 걸쳐서 큐잉된(queued) 이벤트들의 시리얼라이즈된 단일 시스템을 설정하는 것을 특징으로 하는 상기 (49)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(52)에 따르면, 본 발명은 둘 이상의 상호운용 디바이스들로부터의 상기 상호운용 디바이이스들의 큐들상에 위치하는 이벤트들이, 오직 하나의 마스터 디바이스만이 상기 타입들의 상기 이벤트들을 동기화되는 이벤트 타입들의 리스트 내에 위치시키도록 허용되어 그러한 모든 이벤트들이 모든 상호운용 디바이스들에 걸쳐서 시리얼라이즈되는, 시스템에 의해 상기 상호운용 디바이스들의 큐들 내의 이벤트들의 단일 시리얼리제이션으로 동기화되는 것을 특징으로 하는 상기 (47)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(53)에 따르면, 본 발명은 상기 마스터 디바이스는, 상기 의도된 이벤트를 모든 상호운용 디바이스들의 큐들의 내부로 위치시키는데 필요한 모든 정보를 포함하는, 마스트 요청 이벤트 타입 이벤트(master request event type event)를 거쳐서 다른 상호운용 디바이스들을 대신하여 상기 이벤트들을 통지 받아서 생성시키는 것을 특징으로 하는 상기 (52)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(54)에 따르면, 본 발명은 상호운용 디바이스들의 세트 내부의 다른 디바이스에 의해 상호운용 디바이스들의 팀 내부로 모집된 각각의 디바이스는 그것의 상대적인 마스터 디바이스가 그것을 리크루트했던 장치라고 간주하는 것을 특징으로 하는 상기 (52)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(55)에 따르면, 본 발명은 상호운용 디바이스들의 세트 내부의 다른 디바이스에 의해 상호운용 디바이스들의 팀 내부로 모집된 각각의 디바이스는 그것의 상대적인 마스터 디바이스가 그것을 리크루트했던 장치라고 간주하는 것을 특징으로 하는 상기 (53)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(56)에 따르면, 본 발명은 마스터 요청 이벤트 타입 이벤트를 상대적인 마스터 디바이스의 큐 내부로 위치시키는 것에 의해, 상대적인 마스터가 없는 시작 마스터 디바이스가 상기 마스터 디바이스을 위해 필요한 정보를 이용하여 이벤트를 형성하고 상기 의도된 이벤트를 모든 상호운용 디바이스들의 내부로 위치시킬때 까지, 상기 이벤트가 소정 디바이스로부터 상대적인 마스터 디바이스로 전달되는 것을 특징으로 하는 상기 (54)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(57)에 따르면, 본 발명은 상기 지정된 마스터 디바이스는, 새로운 마스터 디바이스가 현재의 마스터 디바이스를 대체하는 동기화되고 시리얼라이즈된 방식으로 모든 디바이스들에게 알리는 시리얼라이즈된 이벤트들의 리스트 상에 존재하는, 변경 마스터 타입 이벤트(change master type event)를 상호운용 디바이스들의 동기화되거나 시리얼라이즈된 큐들에 생성함으로써 변경되는 것을 특징으로 하는 상기 (52)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(58)에 따르면, 본 발명은 상기 마스터 요청 이벤트는 상기 새로 운 마스터 디바이스가 상기 이벤트를 처리할 때까지 상호운용 디바이스들의 큐들을 통해 전달되는 것을 특징으로 하는 상기 (54)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(59)에 따르면, 본 발명은 상기 마스터 요청 이벤트는 상기 새로운 마스터 디바이스가 상기 이벤트를 처리할 때까지 상호운용 디바이스들의 큐들을 통해 전달되는 것을 특징으로 하는 상기 (55)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(60)에 따르면, 본 발명은 상기 마스터 요청 이벤트 타입 이벤트에 의해 전달되는 것으로 구체화된 상기 이벤트의 일부로서 확인된 상기 선택적 파일은, 그러한 파일 레퍼런스(reference)가 존재하는 경우에, 마치 상기 마스터에 의해 전달된 상기 이벤트의 일부로서 전달되었던 것처럼, 상기 마스터에 의해 전달된 이벤트와 재결합되는 것을 허용하는 식별자를 가지는 전달(propagating) 디바이스 각각에서 유지되며, 이를 통해 상기 마스터에 의해 처리된 마스터 요청 이벤트 타입의 결과로서 전달된 각각의 이벤트의 일부로서 전달되어야만 했던 정보의 양을 감소시키는 것을 특징으로 하는 상기 (53)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(61)에 따르면, 본 발명은 메모리와 결합되며 의도된 태스크의 수행을 위한 인스트럭션들을 포함하는 프로시져를 실행하도록 적응되는 프로세서와; 상기 의도된 태스크의 수행에 참여한 장치들과는 다르고 그 외부에 위치하며 상기 의도된 태스크의 수행 버젼(version)에 필요한 하드웨어 리소스들을 적어도 포함하는 적어도 하나의 모집된 디바이스를 리크루트하기 위한 메모리와 상기 프로 세서 내에서 적어도 부분적으로 실행하기 위한 수단과; 상기 하드웨어 리소스들과 실시 보완 리소스들(enabling supplemented resources)이 상기 모집된 장치를 상기 의도된 태스크를 수행하도록 충분히 인에이블하도록 상기 모집된 장치의 리소스들을 보완하기 위한 장치의 내부에 완전히 저장된 수단을; 포함하는 것을 특징으로 하는 이니쉬에이팅 장치를 제공한다.

다른 실시예(62)에 따르면, 본 발명은 상기 장치 및 상기 모집된 디바이스 각각이 공통적인 절차 환경에서 동작하며, 상기 리크루팅을 위한 메모리 및 프로세서 내부에서 적어도 부분적으로 실행하기 위한 수단이 상기 공통적인 절차 환경에서 구현되는 프로시져를 적어도 하나의 연결을 통해 역시 상기 공통적인 절차 환경에서 동작하는 다른 디바이스들로 방송하기 위한 수단을 포함하는 것을 특징으로 하는 상기 (61)의 이니쉬에이팅 장치를 제공한다.

다른 실시예(63)에 따르면, 본 발명은 상기 리크루트 수단이, 다른 디바이스들 상에서의 프로시져의 실행을 시작시켜서 상기 다른 디바이스들 각각의 리소스들 및 또는 능력들을 프로그램적으로 검사(inspect)함으로써 각각의 디바이스가 상기 특정 태스크의 수행에 참여하기 위해 필요한 자원과 능력을 구비하는지의 여부를 결정하기 위한, 수단을 더 포함하는 것을 특징으로 하는 상기 (62)의 이니쉬에이팅 장치를 제공한다.

다른 실시예(64)에 따르면, 본 발명은 상기 검사(inspection)는, 상기 특정 디바이스 내부에 저장되거나 그 특정 디바이스에 대하여 계산된 장치 전용 하드웨어 앱스트랙션 레이어 정보(device specific hardware abstraction layer information)를 액세스함으로써, 적어도 부분적으로 다른 특정 디바이스 각각에서 수행되는 것을 특징으로 하는 상기 (63)의 이니쉬에이팅 장치를 제공한다.

다른 실시예(65)에 따르면, 본 발명은 상기 보완을 위한 수단이, 각각의 디바이스를 인에이블시켜 그 자신의 상기 특정 태스크의 일부를 수행하도록 요청된, 실시 프로시져들, 데이터 및/또는 콘텐트를 전달하고 설치하기 위한 수단을 더 포함하는 것을 특징으로 하는 상기 (64)의 이니쉬에이팅 장치를 제공한다.

다른 실시예(66)에 따르면, 본 발명은 상기 시작 및 다른 디바이스들에 걸쳐서 동작들을 일시적으로 또는 영구적으로 동기화하기 위한 수단을 더 포함하되, 상기 동기화를 위한 수단이 태스크 이벤트 큐와 그 태스크 이벤트 큐를 유지하기 위한 수단을 포함하는 것을 특징으로 하는 상기 (61)의 이니쉬에이팅 장치를 제공한다.

다른 실시예(67)에 따르면, 본 발명은 프로세서와 그 프로세서에 결합된 메모리를 포함하는 하드웨어 리소스들의 세트와; 태스크들의 세트의 수행에 적합한 컴퓨터 프로그램 코드 리소스들과; 컴퓨터 프로그램 코드 통신과 데이터 통신 중의 적어도 하나를 포함하는 통신을 수신하기 위한 수단을 포함하되, 상기 하드웨어 리소스들은 적어도 특정 태스크의 수행의 버젼을 수행할 수 있으나 상기 컴퓨터 프로그램 코드 리소스들은 요구되는 버젼과 상기 특정 태스크 또는 그 특정 태스크의 일 형태를 수행하는 방법을 최초에는 수행할 수 없으며, 상기 컴퓨터 프로그램 코드 통신은 상기 요구되는 버젼, 방법 또는 상기 특정 태스크의 일 형태를 수행할 수 있게 하는 보완(supplemental) 컴퓨터 프로그램 코드 리소들을 포함하는 것을 특징으로 하는 모집된 장치를 제공한다.

다른 실시예(68)에 따르면, 본 발명은 상기 모집된 장치 및 상기 시작 디바이스 각각이 공통적인 절차 환경에서 동작하는 것을 특징으로 하는 상기 (67)의 모집된 장치를 제공한다.

다른 실시예(69)에 따르면, 본 발명은 상기 시작 디바이스로부터 수신된 상기 프로시져를 수행하여 프로그램적으로 상기 모집된 디바이스의 리소스들 및 능력들을 검사(inspect)함으로써 상기 모집된 장치가 상기 특정 태스크의 수행에 참여하는데 필요한 리소스 또는 능력을 구비하는 지의 여부를 결정하기 위한 수단을 더 포함하는 것을 특징으로 하는 상기 (68)의 모집된 장치를 제공한다.

다른 실시예(70)에 따르면, 본 발명은 상기 검사(inspection)는, 상기 모집된 디바이스 내부에 저장되거나 그 모집된 디바이스에 대하여 계산된 장치 전용 하드웨어 앱스트랙션 레이어 정보(device specific hardware abstraction layer information)를 액세스함으로써, 적어도 부분적으로 상기 모집된 디바이스 내부에서 수행되는 것을 특징으로 하는 상기 (69)의 모집된 장치를 제공한다.

다른 실시예(71)에 따르면, 본 발명은 상기 모집된 디바이스를 인에이블시켜 그 자신의 상기 특정 태스크의 일부를 수행하도록 요청된, 실시 프로시져들, 데이터 및/또는 콘텐트를 설치하기 위한 수단을 더 포함하는 것을 특징으로 하는 상기 (70)의 모집된 장치를 제공한다.

다른 실시예(72)에 따르면, 본 발명은 상기 시작 디바이스 및 상기 모집된 디바이스들에 걸쳐서 동작들을 일시적으로 동기화하기 위한 수단을 더 포함하되, 상기 동기화를 위한 수단이 태스크 이벤트 큐와 그 태스크 이벤트 큐를 유지하기 위한 수단을 포함하는 것을 특징으로 하는 상기 (71)의 모집된 장치를 제공한다.

다른 실시예(73)에 따르면, 본 발명은 특정 태스크의 수행에 참여하는 다수의 이종 디바이스들 사이에서 통합된(integrated) 에드-혹(ad-hoc) 온-더-플라이(on-the-fly) 분산(distributed) 정보 프로세싱 시스템을 구성하는 방법에 있어서, 상기 특정 태스크의 수행에 참여하기 위한 리소스 또는 능력을 포함하는 다른 모집된 디바이시들을 확인하기 위하여 적어도 하나의 통신 채널 및 프로토콜을 이용하여 메시지를 방송하는 것을 포함하는 과정으로서, 시작 디바이스에 의해 상기 분산 정보 프로세싱 시스템의 구성 과정을 시작시키는 단계와; 상기 모집된 디바이스들 각각이 그 자신의 상기 특정 태스크를 수행할 수 있도록 요구되는 프로시져들, 데이터 및 콘텐트 중의 적어도 하나를 상기 모집된 디바이스들 각각에 전달하는 단계를; 포함하는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(74)에 따르면, 본 발명은 상기 의도된 태스크의 수행에 참여한 장치들과는 다르고 그 외부에 위치하며 상기 의도된 태스크의 수행 버젼(version)에 필요한 하드웨어 리소스들을 적어도 포함하는 적어도 하나의 모집된 디바이스를 리크루트하기 위한 메모리와 프로세서 내에서 적어도 부분적으로 실행하기 위한 단계와; 상기 하드웨어 리소스들과 실시 보완 리소스들(enabling supplemented resources)이 상기 모집된 장치를 상기 의도된 태스크를 수행하도록 충분히 인에이블하도록 상기 모집된 장치의 리소스들을 보완하기 위한 프로시져 및 선택적 데이 터를 상기 시작 디바이스의 내부에 완전히 저장하는 단계를; 더 포함하는 것을 특징으로 하는 상기 (73)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(75)에 따르면, 본 발명은 상기 시작 디바이스 및 상기 모집된 디바이스 각각이 공통적인 절차 환경에서 동작하며, 상기 리크루팅을 위한 메모리 및 프로세서 내부에서 적어도 부분적으로 실행하기 위한 상기 프로시져가 상기 공통적인 절차 환경에서 구현되는 프로시져를 적어도 하나의 연결을 통해 역시 상기 공통적인 절차 환경에서 동작하는 다른 디바이스들로 방송하기 위한 단계를 포함하는 것을 특징으로 하는 상기 (74)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(76)에 따르면, 본 발명은 상기 리크루팅 단계가, 다른 디바이스들 상에서의 프로시져의 실행을 시작시켜서 상기 다른 디바이스들 각각의 리소스들 및 또는 능력들을 프로그램적으로 검사(inspect)함으로써 각각의 디바이스가 상기 특정 태스크의 수행에 참여하기 위해 필요한 자원과 능력을 구비하는지의 여부를 결정하는 단계를 더 포함하는 것을 특징으로 하는 상기 (75)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(77)에 따르면, 본 발명은 상기 검사(inspection)는 상기 특정 디바이스 내부에 저장되거나 그 특정 디바이스에 대하여 계산된 장치 전용 하드웨어 앱스트랙션 레이어 정보(device specific hardware abstraction layer information)를 액세스함으로써, 적어도 부분적으로 다른 모집된 디바이스 각각에서 수행되는 것을 특징으로 하는 상기 (76)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(78)에 따르면, 본 발명은 상기 보완 단계가 각각의 디바이스를 인에이블시켜 그 자신의 상기 특정 태스크의 일부를 수행하도록 요청된, 실시 프로시져들, 데이터 및/또는 콘텐트를 전달하고 설치하는 단계를 더 포함하는 것을 특징으로 하는 상기 (77)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(79)에 따르면, 본 발명은 상기 시작 및 다른 디바이스들에 걸쳐서 동작들을 일시적으로 또는 영구적으로 동기화하는 단계를 더 포함하되, 상기 동기화 단계가 태스크 이벤트 큐를 생성하고 유지하는 단계를 포함하는 것을 특징으로 하는 상기 (77)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(80)에 따르면, 본 발명은 상기 통신이 클라이언트-서버(client-server) 통신 인터액션(interaction)도 피어-투-피어(peer-to-peer) 통신 인터액션도 아닌 통신 및 인터액션인 것을 특징으로 하는 상기 (73)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(81)에 따르면, 본 발명은 상기 모집은 에드-혹 디바이스, 서비스 및 리소스의 발견하는 과정을 수행하여 필요한 디바이스들을 확인하고, 실시 프로시져들 및 정보를 이벤트들을 이용하여 상기 디바이스들로 전달하며, 디바이스들이 팀을 지능적 및 효과적으로 구성하고, 이벤트들을 이용하여 상기 디바이스들의 팀을 조정(coordinate)해서 상기 소스 시작 디바이스 상에서 원래 동작하던 다트(Dart) 또는 애플리케이션의 목적을 달성하도록 하는 것을 특징으로 하는 상기 (73)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(82)에 따르면, 본 발명은 상기 분산 정보 처리 시스템은 상기 디바이스들의 물리적인 능력들의 일부 또는 전부를 액세스하고 대등하게 이용하는 것을 포함하는 것을 특징으로 하는 상기 (73)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(83)에 따르면, 본 발명은 상기 디바이스의 물리적인 능력들은, 프린트 능력, 팩스 능력, 디스플레이 능력, 뮤직 렌더링 능력, 비디오 렌더링 능력, 다른 디바이스들을 제어하는 능력, 디지털 또는 아날로그 데이터를 미디어에 저장하는 능력, 제품을 제조하는 능력, 제거(elimination)하는 능력, 사진을 찍는 능력, 또는 상기 디바이스들의 프로세싱 능력들에 의해 액세스되거나 모니터링되거나 제어될 수 있는 기타 다른 물리적 능력들을 선택적으로 포함하는, 세트로부터 선택되는 것을 특징으로 하는 상기 (82)의 분산 정보 프로세싱 시스템의 구성 방법을 제공한다.

다른 실시예(84)에 따르면, 본 발명은 하나 이상의 디바이스 상에서 동작하는 상기 소프트웨어 애플리케이션은, 독립적으로 개발된 애플리케이션들 및/또는 독립적으로 분배된 애플리케이션들이 상기 상호운용 동작들을 수행하는데 사용되는 경우에 더 안정된 상호 운용성을 제공하기 위하여, 적어도 부분적으로 코드 및/또는 데이터 및/또는 콘텐트를 가지는 둘 이상의 디바이스들 상에서의 상호운용 동작들을 수행하는 것을 특징으로 하는 상기 (1)의 디바이스 팀 모집 방법을 제공한다.

다른 실시예(85)에 따르면, 본 발명은 컴퓨터 시스템 또는 정보 기기와 관련되어 사용되는 것으로서 컴퓨터로 판독가능한 저장 매체 및 내장된(embedded) 컴퓨 터 프로그램 메카니즘으로 구성되는 컴퓨터 프로그램 제품에 있어서, 상기 컴퓨터 프로그램 메카니즘이 상기 컴퓨터 시스템 또는 정보 기기가 소정의 방식으로 상호운용성을 위한 모집된 디바이스들의 팀을 리크루트하는 기능을 하도록 지시하는 프로그램 모듈을 포함하고, 상기 프로그램 모듈이, 시작 소스 디바이스 및 그 자체가 도달될 디바이스 모두에 공통되는 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 필요한 리소스 또는 능력을 가지는 디바이스를 발견하도록 동작하는 인스펙션 프로시져를, 적어도 하나의 통신 링크를 통해 상기 시작 소스 디바이스와는 다른 적어도 하나의 도달가능한 디바이스로 전달하는 단계와; 상기 시작 디바이스에서 도달가능한 디바이스들 각각으로부터의 리턴 응답을 통신 링크를 통해 직접적으로 또는 간접적으로 수신하는 단계와; 상기 시작 디바이스에서 실행되는 프로시져를 통해 도달가능한 모든 응답 디바이스들로부터 수신된 리턴 응답들을 분석하여 상기 소프트웨어 애플리케이션의 목적을 가장 잘 수행할 수 있는 상기 도달가능한 응답 디바이스들과 상기 시작 소스 디바이스의 능력들 및 리소스들의 조합을 확인하기 위한 유틸리제이션 플랜(utilization plan)을 결정하는 단계와; 상기 시작 디바이스에서 실행되는 애플리케이션 프로그램을 통해 코드, 데이터, 콘텐트 및/또는 다트(Dart) 중의 적어도 하나를 상기 결정된 유틸리제이션 플랜에 따라 필요한 리소스 또는 능력을 가지는 것으로 확인된 상기 도달가능한 각 디바이스들 중의 적어도 하나에 분배하는 단계를 위한 인스트럭션들을 포함하는 것을 특징으로 하는 상기 컴퓨터 프로그램 제품을 제공한다.

다른 실시예(86)에 따르면, 본 발명은 컴퓨터 시스템 또는 정보 기기와 관련 되어 사용되는 것으로서 컴퓨터로 판독가능한 저장 매체 및 내장된(embedded) 컴퓨터 프로그램 메카니즘으로 구성되는 컴퓨터 프로그램 제품에 있어서, 상기 컴퓨터 프로그램 메카니즘이 상기 컴퓨터 시스템 또는 정보 기기가 단일한 가상 디바이스의 역할을 하면서 특정 태스크의 수행에 참여하는 다수의 이종 디바이스들 사이에서 통합된(integrated) 에드-혹(ad-hoc) 온-더-플라이(on-the-fly) 분산(distributed) 정보 프로세싱 시스템 소정의 방식으로 구성하는 프로그램 모듈을 포함하고, 상기 프로그램 모듈이, 상기 특정 태스크의 수행에 참여하기 위한 리소스 또는 능력을 포함하는 다른 모집된 디바이시들을 확인하기 위하여 적어도 하나의 통신 채널 및 프로토콜을 이용하여 메시지를 방송하는 것을 포함하는 과정으로서, 시작 디바이스에 의해 상기 분산 정보 프로세싱 시스템의 구성 과정을 시작시키는 단계와; 상기 모집된 디바이스들 각각이 그 자신의 상기 특정 태스크를 수행할 수 있도록 요구되는 프로시져들, 데이터 및 콘텐트 중의 적어도 하나를 상기 모집된 디바이스들 각각에 전달하는 단계를 위한 인스트럭션들을 포함하는 것을 특징으로 하는 상기 컴퓨터 프로그램 제품을 제공한다.

본 발명의 상세한 설명부 또는 도면들에서 설명되는 실시예들의 특징들 및/또는 구성 요소들과 상기에서 설명된 실시예들에서 언급된 특징들 및/또는 구성 요소들은 다양한 방식으로 결합될 수 있는 것으로서, 상술한 실시예들은 본 발명을 한정하려는 것이 아니며 상기 특징들 및 구성 요소들의 상이한 조합 또는 변형을 가지는 추가적이거나 대안적인 실시예들도 본 발명의 실시예들에 포함된다.

III . 렌디셔닝 어답테이션 및 상호운영 세그멘테이션 모델( Renditioning Adaptation and Interoperability Segmentation Model )

본 발명의 일측면에 따르면, 렌디셔닝을 위한 시스템, 장치, 방법, 및 컴퓨터 프로그램이 제공된다. 렌디셔닝은 상호운영 애플리케이션들을 이산 실행 유니트들의 세트로 분할하는 방법론과 관련되며, 이러한 세트에서 선택된 어느 한 이산 실행 유니트가 주어진 환경과 시점에서 주어진 장치 또는 플레이어에서 실행된다.

본 발명의 바람직한 일실시예 및 구현예에 따르면, 다트(Dart) 애플리케이션 프레임워크(DartFramework)는 기즈모스(Gizmos)로 불리는 프로세싱 유닛들의 계층에서 최상위 계층으로 동작하는 렌디션 압젝트(object)들을 포함한다 (도 11 참조). 렌디션이 무엇인지 이해할 목적으로, 하나의 렌디션을 완전한 통상의 프로그램으로 생각해 볼 수 있다-물론, 통상의 프로그램의 경우, 상호운영 동작들을 실행하기 위해 필요한 콘텐트(content) 및 이와 연관된 기능들과 함께 생성되어 패키지된 복수의 렌디션들을 포함할 것이다-. 주어진 세트의 어느 렌디션도 그 자체로는 효과적으로 또는 효율적으로 애플리케이션 또는 렌디션들의 패키지에서 의도하는 바를 수행할 수 없는 경우가 종종 있다. 다트(Dart)와 같은 상호운영 애플리케이션은 프로그램 파트들의 통합된 집합이며, 동적 및 정적으로 결합되는 프로그램들을 형성하고 관리하기 위해 파트들을 어떻게 결합해야 하는지 아는 프로시져들, 데이터, 콘텐트, 및/또는 자원들을 포함할 수 있다 (도 3의 300, 도 13 및 도 14 참조). 또한, 상호운영 애플리케이션 또는 다트(Dart)는 디바이스들의 팀(team)에서 한 디바이스당 하나의 세트를 할당하는 식으로 같은 또는 다른 렌디션들 또는 렌디션들의 세트를 지적으로(intelligently) 분산하기 위한 수단을 포함하며, 이렇게 분산된 렌디션은 하나의 팀으로서 다른 디바이스들의 렌디션들과 상호 통신하고 작용하여 효과적이고 효율적으로 애플리케이션이 의도한 바를 수행할 수 있다. 렌디셔닝의 장점중 하나는 실행 유니트들간 파트를 공유할 수 있어서 상호운영 애플리케이션의 크기를 줄일 수 있다는 것이다. 종래의 프로그래밍 기술을 사용하는 경우 각각의 타깃 디바이스나 환경에 적합한 애플리케이션이 포함되도록 애플리케이션들을 세트로 패키지화해야 할 필요가 종종 있다. 렌디셔닝을 사용하지 않는 경우, 패키지의 각각의 프로그램에 불필요하게 프로시져들, 데이터 콘텐트 및 자원들을 저장해야 하는 경우가 종종 발생한다. 렌디셔닝의 다른 장점은, 타깃 디바이스나 환경에서 동작할 올바른 렌디션을 인텔리전트하게 선택하기 위해 렌디셔닝 모델에서 사용될 각각의 렌디션과 연관된 선택 프로시져들이 있을 수 있다는 것이다 (도 14의 4000 참조). 렌디셔닝을 통해 얻을 수 있는 또 다른 장점은, 어느 하나의 디바이스나 환경에서 작동되기에 적합한 적어도 하나의 렌디션을 포함할 수 있을 정도로 충분히 큰 세트를 형성할 수 있으면서도 어답테이션들(adaptations)의 수를 충분히 작은 세트로 한정할 수 있어서 상호운영 애플리케이션에 대한 철저한 테스트가 가능하다는 것이다.

렌디션들을 이용하여 Dart 툴들(도 12의 DartTools 200 참조)이 자동으로 파트들을 다른 디바이스로 보내질 특정 목적 Darts로 구성하도록 할 수 있다. 예를 들어, 렌디션들은 이미지나 문서의 인쇄를 위하여 준비될 수 있다. 이러한 렌디션들 또는 렌디션들의 세트들은 DartTools를 이용하여 정정으로 생성되거나, 본 명세서의 다른 부분에서 설명된 바와 같이 상기 DartInstructionSet와 같은 상호운영 인스트럭션 세트를 이용하는 생성론(Creationism methodology, 도 7의 20020참조)을 통하여 동적으로 생성되거나, 이들의 조합 또는 다른 기술들과 이들의 결합을 통해 생성될 수 있다.

렌디션들의 다른 용도는 사용자의 필요 또는 희망에 따라 선택될 언어 또는 문화 버전(cultural versions)의 세트를 생성하는 것이다. 예를 들어, 본질적으로 동일한 정보를 갖는 다른 렌디션들이 프랑스어 또는 중국어용으로 생성될 수 있으며, 다른 렌디션들이 본래의 일본 관객을 위한 의류 광고용 일본 모델들의 사진들 및 이탈리아나 유럽 관객을 위한 동일한 광고용 이탈리아 모델들의 사진들을 사용하는 것과 같은 다소 다른 정보에 대하여 생성될 수 있다.

렌디션들의 또 다른 용도는 어떤 이유로 인해 이의를 제기할 여지가 있거나 중요하지 않거나 또는 특정 그룹들에 적당하지 않은 콘텐트의 사용을 제한하는 것이다. 렌디션들의 또 다른 용도는 콘텐트가 아이들이나 Texas주의 사람들과 같은 특정 그룹들이나 디바이스들에 대하여 사용되도록 하는 것이다. 렌디션들의 또 다른 용도는 지역 날씨와 관련된 정보를 포함하는 Dart 렌디션들과 같이 다른 장소들을 목표로 설정하는 것 일 수 있다.

본 발명의 일측면에 따르면, 렌디셔닝은 소프트웨어 애플리케이션 세트의 파트들 및 이와 관련된 데이터, 프러시져들, 콘텐트, 및 선택 기준 프러시져들을 하나의 이진 이미지로 밀접하게 패키징하는 방법을 제공한다. 또한, 렌디셔닝은 이진 이미지에 있어서 파트들, 파트들의 특성들, 식별자들, 및 위치들에 대한 데이터베이스를 제공한다. 또한, 렌디셔닝은 파트들을 프로시져들 및/또는 데이터 및/또는 콘텐트로 이루어진 복수의 개별 실행 소프트웨어 애플리케이션들로 매핑하는 방법을 제공한다. 또한, 렌디셔닝은 주어진 디바이스, 사용자 선택, 통신 특성 및/또는 환경에 대하여 실행될 소프트웨어 애플리케이션을 이진 이미지에 대한 소프트웨어 애플리케이션들의 세트에서 결정하고 이와 관련된 데이터, 프러시져들 및 콘텐트를 결정하는 프러시져 또는 프로시져들의 세트를 제공한다. 또한, 렌디셔닝은 소스 재료들의 세트에 따라 파트들을 자동 생성하고 하나의 이진 이미지로 (또는, 필요에 따라, 복수의 이진 또는 다른 포맷의 이미지들로) 패키징하기위한 툴 세트를 제공한다. 또한, 렌디셔닝은 주어진 이진 이미지 내에서 파트의 데이터베이스를 찾고 접속하는 메커니즘을 제공한다.

렌디셔닝 어답테이션 및 상호운영 세그멘테이션 모델의 예시적 특정 실시예들이 아래에 설명된다.

본 발명의 일실시예(1)에 따르면, 소프트웨어 애플리케이션을 개별 실행 가능한 이미지들의 세트로 분할하기 위한 방법이 제공된다. 상기 분할 방법은, 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위한 잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하는 단계; 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위해 필요한 디스팅트(distinct) 렌더링 또는 다른 런타임 요구 사항들에 따라 직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하는 단계; 디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘 텐트 및 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하는 단계; 어느 디바이스들과 이에 대응하여 개별적으로 할당된 실행 가능한 이미지들이 후보 디바이스들의 리스트, 자원들 및 능력들, 그리고 요구되는 또는 바라는 환경 또는 작동 파라미터들이 주어진 경우 상기 애플리케이션의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 이용 계획을 생성하는 단계; 및 상기 이용 계획을 디바이스의 각 클래스 및 각 환경 또는 운영 요구 사항에 대하여 implement하고 carry out하기 위하여 필요한 데이터, 코드, 콘텐트 및 다른 디지털적으로 나타낼 수 있는 자원들을 특정하는 단계를 포함한다.

본 발명의 다른 실시예(2)에 따르면, 상기 일실시예(1)의 방법에 있어서, 상기 소프트웨어 애플리케이션은 하나 또는 그 이상의 동종 또는 이종 통신 디바이스들간에서 동작되는 애플리케이션이다.

본 발명의 다른 실시예(3)에 따르면, 상기 일실시예(1)의 방법에 있어서, 상기 실행 가능한 이미지들 중 정확하게 하나가 선택되어 특정 환경의 주어진 디바이스에서 작동한다.

본 발명의 다른 실시예(4)에 따르면, 상기 다른 실시예(3)의 방법에 있어서, 상기 실행 가능한 이미지들 중에서 정확하게 하나가 선택되고, 선택된 이미지는 자원, 각 디바이스의 능력, 환경, 및 운영 요구 상황에 대한 상기 애플리케이션의 요구에 따라 각 디바이스에서 작동한다.

본 발명의 다른 실시예(5)에 따르면, 상기 다른 실시예(3)의 방법에 있어서, 상기 디바이스들 중 적어도 하나는 Dart 디바이스이다.

본 발명의 다른 실시예(6)에 따르면, 상기 일실시예(1)의 방법은 상기 생성된 이용 계획을 실행하는 단계를 더 포함하는 것을 특징으로 하는 분할 방법.

본 발명의 다른 실시예(7)에 따르면, 상기 일실시예(1)의 방법에 있어서, 상기 소프트웨어 애플리케이션은 Dart로서 표현된다.

본 발명의 다른 실시예(8)에 따르면, 상기 일실시예(1)의 방법에 있어서, 상기 개별적으로 실행되는 이미지들은 렌디션들이다.

본 발명의 다른 실시예(9)에 따르면, 상기 다른 실시예(7)의 방법에 있어서, 상기 렌디션들은 DartTool들에 의해 DartFormat으로 패키지된 Dart Rendition들의 형태로 표현된다.

본 발명의 다른 실시예(10)에 따르면, 상기 다른 실시예(2)의 방법에 있어서, 상기 일실시예(1)의 이용 계획은 전체적으로 또는 부분적으로 상기 후보 디바이스들에서 작동되도록 전송된 프로시져들로서 실행되어 상기 디바이스의 특정 클래스, 자원들 및/또는 동작 환경을 결정한다.

본 발명의 다른 실시예(11)에 따르면, 상기 다른 실시예(10)의 방법에 있어서, 상기 프러시져들은 상호운영 명령 세트(Interoperability Instruction Set)의 명령들로서 적어도 일부분 구성된 DartProcedure들이다.

본 발명의 다른 실시예(12)에 따르면, 상기 다른 실시예(11)의 방법에 있어서, 상기 상호운영 명령 세트는 DartInstructionSet이다.

본 발명의 다른 실시예(13)에 따르면, 상기 다른 실시예(11)의 방법에 있어서, 상기 상호운영 명령 세트는 프로시져들이 실행되는 하나 또는 그 이상의 동종 또는 이종의 통신 디바이스들에서 실행 가능한 형태이다.

본 발명의 다른 실시예(14)에 따르면, 상기 다른 실시예(13)의 방법에 있어서, 상기 통신 디바이스들은 상기 디바이스의 특정 클래스, 자원들 및/또는 운영 환경을 결정하기 위하여 프러시져들을 실행한다.

본 발명의 다른 실시예(15)에 따르면, 상기 다른 실시예(10)의 방법에 있어서, 상기 프로시져들은 상기 애플리케이션의 일부인 Dart들로서 표현된다.

본 발명의 다른 실시예(16)에 따르면, 상기 다른 실시예(15)의 방법에 있어서, 상기 애플리케이션은 이종의 통신 디바이스들에서 상기 애플리케이션의 목적을 이행하기 위해 사용되는 다른 Dart들을 포함하는 하나의 Dart로서 표현된다.

본 발명의 다른 실시예(17)에 따르면, 상기 일실시예(1)의 방법에 있어서, 상기 일실시예의 모집 (recruitment) 방법은 이종 또는 동종의 디바이스들로 이루어진 팀(team)들을 형성하기 위하여 상기 프러시져들을 전송 및 분산하고 이미지들을 분할하는 데 사용된다.

본 발명의 다른 실시예(18)에 따르면, 상기 일실시예(1)의 방법에 있어서, 다른 타깃 디바이스들 및 프로세싱 환경들에서 개별적으로 실행되는 다른 이미지들간에 파트가 분배 가능하여 상호운영 애플리케이션의 크기가 제한될 수 있다.

본 발명의 다른 실시예(19)에 따르면, 상기 일실시예(1)의 방법에 있어서, 파트들이 개별적으로 실행되는 이미지들간에 분배 가능하여 상기 소프트웨어에 저장될 데이터의 양이 제한 될 수 있다.

본 발명의 다른 실시예(20)에 따르면, 상기 일실시예(1)의 방법에 있어서, 파트들이 개별적으로 실행되는 이미지들간에 분배 가능하여 상기 디바이스들 간에 전송될 데이터의 양이 제한 될 수 있다.

본 발명의 다른 실시예(21)에 따르면, 상기 다른 실시예(18)의 방법에 있어서, 상기 파트들은 코드, 데이터, 콘텐트, 프로시져들, 코드 세트들, 데이터 세트들, 콘텐트, 콘텐트 세트들, 상기 파트들을 어떻게 찾고 결합하는 지에 대한 메타 정보, 묘사적 텍스트(descriptive text), 그림들(pictures), 비디오, 이미지들, 데이터 테이블들, 또는 어떤 다른 단위의 정보 또는 디지털 방식을 표현될 수 있는 정보의 세트들 중 하나이다.

본 발명의 다른 실시예(21)에 따르면, 상기 다른 실시예(21)의 방법에 있어서, 상기 파트들은 DartPart들이고, 상기 메타 정보는 Dart RenditionsTable part, 및 또는 Dart RenditionTable parts, 및 또는 Dart PartTable, 및 또는 DartTrailer로 표현된다.

본 발명의 다른 실시예(22)에 따르면, 소프트웨어 애플리케이션을 개별 실행 가능한 이미지들의 세트로 분할하기 위한 방법이 제공된다. 상기 분할 방법은, 잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하는 단계; 직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하는 단계; 디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘텐트 및/또는 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하는 단계; 및 어느 디바이스들과 실행 가능한 이미지들이 상기 애플리케이션 의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 이용 계획을 생성하는 단계를 포함한다.

본 발명의 다른 실시예(23)에 따르면, 소프트웨어 애플리케이션을 개별 실행 가능한 이미지들의 세트로 분할하기 위한 장치가 제공된다. 상기 분할 장치는, 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위한 잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하기 위한 수단; 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위해 필요한 디스팅트(distinct) 렌더링 또는 다른 런타임 요구 사항들에 따라 직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하기 위한 수단; 디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘텐트 및 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하기 위한 수단; 어느 디바이스들과 이에 대응하여 개별적으로 할당된 실행 가능한 이미지들이 후보 디바이스들의 리스트, 자원들 및 능력들, 그리고 요구되는 또는 바라는 환경 또는 작동 파라미터들이 주어진 경우 상기 애플리케이션의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 이용 계획을 생성하기 위한 수단; 및 상기 이용 계획을 디바이스의 각 클래스 및 각 환경 또는 운영 요구 사항에 대하여 implement하고 carry out하기 위하여 필요한 데이터, 코드, 콘텐트 및 다른 디지털적으로 나타낼 수 있는 자원들을 특정하기 위한 수단을 포함하는 것을 특징으로 하는 장치.

본 발명의 다른 실시예(24)에 따르면, 컴퓨터 시스템 또는 정보 기기와 결합하여 사용되기 위한 컴퓨터 프로그램 제품이 제공된다. 상기 컴퓨터 프로그램 제품은 컴퓨터로 읽을 수 있는 저장 매체 및 상기 저장 매체에 구현된 컴퓨터 프로그램 메커니즘을 포함하며, 상기 컴퓨터 프로그램 메커니즘은, 상기 컴퓨터 시스템 또는 정보 기기가 특정 방식으로 작동하도록 하여 컴퓨터 프로그램 소프트웨어 코드 애플리케이션을 개별적으로 실행 가능한 컴퓨터 프로그램 소프트웨어 코드 이미지들의 세트로 분할하는 프로그램 모듈을 포함하며, 상기 프로그램 모듈은, 잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하는 단계; 직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하는 단계; 디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘텐트 및/또는 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하는 단계; 및 어느 디바이스들과 실행 가능한 이미지들이 상기 애플리케이션의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 이용 계획을 생성하는 단계를 위한 명령들을 포함한다.

본 발명의 다른 실시예(25)에 따르면, 컴퓨터 시스템 또는 정보 기기와 결합하여 사용되기 위한 컴퓨터 프로그램 제품이 제공된다. 상기 컴퓨터 프로그램 제품은 컴퓨터로 읽을 수 있는 저장 매체 및 상기 저장 매체에 구현된 컴퓨터 프로그램 메커니즘을 포함하며, 상기 컴퓨터 프로그램 메커니즘은, 상기 컴퓨터 시스템 또는 정보 기기가 특정 방식으로 작동하도록 하여 컴퓨터 프로그램 소프트웨어 코드 애 플리케이션을 개별적으로 실행 가능한 컴퓨터 프로그램 소프트웨어 코드 이미지들의 세트로 분할하는 프로그램 모듈을 포함하며, 상기 프로그램 모듈은, 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위한 잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하는 단계; 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위해 필요한 디스팅트(distinct) 렌더링 또는 다른 런타임 요구 사항들에 따라 직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하는 단계; 디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘텐트 및 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하는 단계; 어느 디바이스들과 이에 대응하여 개별적으로 할당된 실행 가능한 이미지들이 후보 디바이스들의 리스트, 자원들 및 능력들, 그리고 요구되는 또는 바라는 환경 또는 작동 파라미터들이 주어진 경우 상기 애플리케이션의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 이용 계획을 생성하는 단계; 및 상기 이용 계획을 디바이스의 각 클래스 및 각 환경 또는 운영 요구 사항에 대하여 implement하고 carry out하기 위하여 필요한 데이터, 코드, 콘텐트 및 다른 디지털적으로 나타낼 수 있는 자원들을 특정하는 단계를 위한 명령들을 포함한다.

상기한 예시적 실시예들 및 상세한 설명의 다른 부분에서 설명하는 예시적 실시예들 또는 도면 언급한 특징과 구성요소들은 다른 여러 가지 방법으로 조합될 수 있으며, 상기한 실시예들에 의해 본 발명의 한정되는 것은 아니다. 상기한 특징 및 구성요소들의 여러가지 가능한 조합이나 변형에 의한 추가적인 또는 대체적인 실시예들도 본 발명의 실시예에 포함된다.

IV . 다트소스 /상호운영 소스( DartSource / lnteroperability Source )

DartSource는 패키지된 Dart 상호운영 애플리케이션에 필요한 모든 프로그램 렌디션들, 코드 콘텐트, 및 데이터를 특정하기 위한 구조 및 방법을 제공한다는 것은 상기하기 바란다. DartSource는 특정 디바이스를 목표로 하는 하나의 실행 가능한 프로그램을 특정(specify)하는데 통상 사용되는 언어 구조를 확장하여 이러한 언어 구조가 디바이스들의 팀(team)에 대한 지적인 모집에 필요한 프러시져들 및 필요한 렌디션들을 특정하는데도 사용될 수 있게 하여, 특정된 애플리케이션의 의도한 목적에서 디바이스의 몫에 해당하는 부분을 수행하기 위해 모집된 각각의 디바이스에서 작동하도록 보내질 적당한 렌디션이 존재하게 한다.

본 발명의 일실시예(1)에 따르면, 디지털적인 방식으로 인코딩된 데이터, 코드 및 콘텐트의 소프트웨어 애플리케이션 패키지와 메타 정보를 하나 또는 그 이상의 연결된 또는 단속적으로(intermittently) 연결된 디바이스에서 의도한 목적(목표)을 수행하는 데 필요한 데이터, 코드 및 콘텐트의 형태로 특정하기 위한 방법을 제공한다; 상기 방법은 상호운영 소프트웨어 프로그래밍 언어에서 다음에서 나열하는 것의 어느 하나 또는 하나 이상 또는 어떠한 조합을 표현하는 것을 포함한다: (a) 객체 지향적인 프레임워크 또는 라이브러리; (b) 상기 애플리케이션의 논리를 수행하는 데 사용되는 메인 코드 및 데이터를 표현하기 위한 소스코드로서, 실행 가능한 하나의 이미지 또는 실행 가능한 이미지들의 통합 세트로 표현되는 소스코 드; (c) 디지털적인 방식으로 표현 가능한 자원들; 및 (d) 상기 애플리케이션의 논리를 상기 디바이스(들)의 원래의 기본적인 하드웨어 및 소프트웨어에 연결하기 위한 시스템 호출(system call)들 또는 명령 인보케이션(invocation)들.

본 발명의 다른 실시예(2)에 따르면, 상기 일실시예(1)에 의한 방법을 제공함에 있어서, 상기 시스템 호출들 또는 명령들은 상기 애플리케이션의 논리를 다음과 같은 상기 디바이스의 원래의 기본적인 하드웨어 및 소프트웨어 중에서 어느 하나 또는 그 이상에 연결하는데 사용된다: (a) 소프트웨어 엔진; (b) 소프트웨어 운영 체계; (c) 통신 서브시스템들; (d) 그래픽 서브시스템들; (e) 암호표기(cryptographic) 서브시스템; (f) 보안(security) 서브시스템; (g) 저장, 오디오 렌더링, 및 또는 입력/출력 서브시스템들; (h) 네이티브(native) 코드 표현 알고리즘들 또는 프로시져들; (i) 매체 압축 및 또는 압축해제 서브시스템들; (i) 데이터 프로세싱 도는 데이터베이스 프로세싱; (j) 애플리케이션 프로그램 인터페이스들을 통해 노출된 디바이스 지정(device specific) 고유 기능들 및 능력들; (k) 디바이스의 자원들, 콘텐트, 및 능력들에 대한 정보를 복구하기 위한 디바이스 지정 프로파일 정보; (l) 디바이스들에 대한 상기 애플리케이션의 동기 및 비동기 작동을 구동하기 위한 이벤트 큐 및 관련된 이벤트 큐 관리 서브시스템; (m) 사용자 인터페이스, 텍스트, 오디오, 비디오 또는 다른 트랜스코딩 또는 렌더링 동작, 및 또는 일반적인 계산 동작들, 및 또는 일반적인 데이터베이스 동작들; (n) 전원 관리, 일시정지/재작동, 및 또는 하나 이상의 상호 협력적 디바이스들간에 또는 내에서 소프트웨어, 데이터, 콘텐트, 및 상태의 공유 및 상호 협력적 작동을 이끌기 위해 이 벤트들을 통해 이루어지는 단속적 접속에 의한 애플리케이션 레벨 에러의 회복; (o) 파트들, 파트들의 패키지들, 프로시져들, 실행 이미지들, 또는 실행 가능한 이미지들의 패키지들을 물리적 저장장치로/으로부터 또는 다른 연결된 디바이스들로/으로부터 동적으로 저장(save), 구성(configure), 최적화(optimize) 및/또는 전송(send)하기 위한 서브시스템; 및 (p) 상이한 사항들의 조합.

본 발명의 다른 실시예(3)에 의하면, 상기 일실시예(1)에 의한 방법을 제공함에 있어서, 상기 프레임워크 또는 라이브러리 및/또는 소스 코드는 상기 (a) 내지 (p)에서 나열한 접속 가능한 원래의 기본적인 소프트웨어 또는 하드웨어들 중 하나 이상에 대한 실행, 캡슐화, 순서 접속, 및/또는 구조화를 위한 클래스 정의(definition)들과 객체 임플리멘테이션(implementation)들을 포함한다.

본 발명의 다른 실시예(4)에 따르면, 상기 일실시예(1)에 의한 방법을 제공함에 있어서, 상기 프레임워크 또는 라이브러리 및/또는 소스 코드는 하나 이상의 상호 협력적 디바이스들에 대한 또는 사이에서 이벤트에 의한 실행에 사용되기 위한 특정 런타임 컨벤션(convention)들을 충적하는 기초를 제공하기 위한 클래스 정의들 및 객체 임플리멘테이션을 포함한다.

본 발명의 다른 실시예(5)에 따르면, 상기 일시예(1)에 따른 방법을 제공함에 있어서, 상기 프레임워크 또는 라이브러리 및/또는 소스 코드는 상호운영 디바이스들의 세트 사이에 분산되어 작동하는 소프트웨어 애플리케이션의 파트들 사이의 이벤드들에 대한 프로세싱을 연속(serialize)함으로써 디바이스들 사이에서의 실행 가능하고 동기화된 동작의 범위내에서의 이벤트의 동기화된 프로세싱을 보증 하기 위한 클래스 정의들 및 객체 임플리멘테이션들을 포함한다.

V. 다트프레임워크 /상호운영 프레임워크( DartFramework / lnteroperability Framework)

DartFramework는 프로그래머가 DartPlatform의 상호운영 특징들의 많은 부분을 이해하고 실시해야 하는 필요가 없게 하는 DartPlatform의 바람직한 특징들의 많은 부분에 대한 접속을 캡슐화하는 상호운영 애플리케이션들을 프로그래머가 만들 때 사용할 목적으로 제공된 DartSource의 일부분임을 상기하자. 더욱 구체적인 DartFramework의 측면을 포함하여 상호운영 Framework의 다른 측면들이 본 명세서의 선형 태스킹 부분과 관련하여 상술된다.

본 발명의 일실시예(1)에 따르면, 객체 지향적인 클래스 정의들의 세트를 가지는 객체 지향적인 상호운영 프레임워크 및 이벤트 기반 소프트웨어 애플리케이션 패키지의 소스 규격(specification)의 일부로 사용될 그 실행 코드(implementation code)를 특정하는 방법을 제공한다. 상기 방법은, (i) 적어도 다음과 같은 데이터 및 코드 멤버들을 포함하는 기본 이벤트 프로세싱 클래스로서 객체 지향 언어를 사용하여 특정하는 단계; 및 (ii) 상기 멤버들과 소스 코드에서의 클래스 규격의 방법들을 실시하는 단계를 포함하며, 상기 데이터 및 코드 멤버들은: (a) 이벤트 데이터 구조의 일예의 카피(copy), 참조, 또는 파라미터로 작용하는 프로세스 멤버; 및 (b) 동일한 기본 클래스를 가지는 다른 이벤트 프로세싱 객체들의 예들가 되거나 이에 대한 참조가 되는 순서 리스트 멤버를 포함한다.

본 발명의 또 다른 실시예(2)에 따르면, 상기 일실시예(1)에 따른 방법을 제 공함에 있어서, 상기 소프트웨어 응용 패키지는 하나이상의 연결된 또는 단속적으로(intermittently) 연결된 디바이스들에 대해 의도한 목적(목표)을 실행하기 위해 설계되고 구현된다.

본 발명의 또 다른 실시예(3)에 따르면, 상기 다른 실시예(2)에 따른 방법을 제공함에 있어서, 상기 소프트웨어 애플리케이션 패키지는 상기 DartFormat을 충족한다.

본 발명의 또 다른 실시예(4)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 기본 클래스는 Dart Gizmo 클래스이다.

본 발명의 또 다른 실시예(5)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 기본 클래스에서 상속되고 상기 프로세스 멤버의 파라미터가 선택적으로 엠프티이거나 널(NULL) 참조인 상기 기본 클래스의 상속 단계 트리의 루트로 작용하는 렌디션 클래스가 있다.

본 발명의 또 다른 실시예(6)에 따르면, 상기 다른 실시예(5)에 따른 방법을 제공함에 있어서, 상기 렌디션 클래스는 출력 패키지 또는 상기 객체 지향적 상호운영 프레임워크를 이용하는 소스 코드로부터 생성되는 패키지들에서 구현되는 개별 실행 이미지의 시작 엔트리 포인트를 나타내데 사용된다.

VI . 다트툴즈 /상호운영 툴즈( DartTools / lnteroperabilitv Tools )

상기 DartTools는 상기 DartSource 애플리케이션을 상기 Dart 애플리케이션 패키지들로 처리한다는 것을 상기하다.

본 발명의 일실시예(1)에 따르면, 디지털적으로 인코딩된 정보의 상호운영 소프트웨어 애플리케이션 패키지를 하나 이상의 연결된 또는 단속적(intermittently)으로 연결된 디바이스들에 대한 의도한 목적(목표)을 수행하는 데 필요한 메타 정보와 함께 생성하는 방법을 제공한다. 상기 방법은, 객체 파일들을 생성하기 위한 상호운영 컴파일러 프로세스[소프트웨어 제품]를 통해 소스 재료들을 처리하는 단계; 및 라이브러리들 또는 상호운영 소프트웨어 애플리케이션 패키지를 생성하기 위해 상호운영 링커(linker) 프로세스를 통해 상기 객체 파일 및 선택적 라이브러리들을 처리하는 단계를 포함한다.

본 발명의 또 다른 실시예(2)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 디지털적으로 인코딩된 정보는 디지털적으로 인코딩된 데이터, 코드 및/또는 콘텐트를 포함하며, 상기 메타 정보는 데이터, 코드 및/또는 콘텐트 형태의 메타 정보를 포함한다.

본 발명의 또 다른 실시예(3)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 상호운영 컴파일러 프로세스는 컴파일러 컴퓨터 프로그램 소프트웨어 제품으로 구현되고, 상기 링커 프로세스는 링커 컴퓨터 프로그램 소프트웨어 제품으로 구현된다.

본 발명의 또 다른 실시예(4)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 소스 재료들은 상호운영 소스 방법에 따라 에셈블된다.

VII . 다트포맷 /상호운영 포맷( DartFormat / lnteroperability Format )

상기 DartFormat은 작동 DartPlayer를 포함하는 DartDevice들에 로드되어 작동될 수 있는 상호운영 애플리케이션들에 필요한 모든 코드, 데이터, 및 콘텐트를 Dart 포맷 패키지로 묶기위한 구조 및 규칙(rule)들을 포함한다는 것을 상기하자.

본 발명의 일실시예(1)에 따르면, 디지털적으로 인코딩된 데이터, 코드, 및 콘텐트의 상호운영 포맷을 충족하는 소프트웨어 어플레케이션 패키지를 하나이상의 연결된 또는 단속적으로 연결된 디바이스들에 대해 의도한 목적(목표)을 수행하기 위한 데이터, 코드 및 콘텐트의 형태의 메타 정보와 함께 저장하는 방법을 제공한다. 상기 방법은, 선형적으로 연속된 이진 인코딩 파트 이미지를 적어도 하나 생성하는 단계; 애플리케이션 패키지의 일부로서 식별, 로드, 선택, 실행, 및 처리에 사용될 이진 인코딩된 자원들 또는 프로그램 요소들의 조합으로 구성되는 선형적 연속 파트 이미지들을 필요에 따라 생성하는 단계; 메타 정보를 형성하는 단계; 및 파트 이미지들의 위치가 결정되고 독립적으로 실행 가능한 이미지들이 식별되고 로드되고 실행되도록 파트들 및 메타 정보를 함께 패키지하는 단계를 포함한다.

본 발명의 또 다른 실시예(2)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 적어도 하나의 선형적으로 연결된 이진 인코딩 파트 이미지는 메인 코드, 메인 데이터, 독립적으로 실행 가능한 이미지들 각각을 위한 기록 테이블, 및 독립적으로 실행 가능한 특정 이미지에 속하는 파트들 각각을 위한 기록 테이블 중 적어도 하나를 포함한다.

본 발명의 또 다른 실시예(3)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 적어도 하나의 선형적으로 연결된 이진 인코딩 파트 이미지는 메인 코드, 메인 데이터, 독립적으로 실행 가능한 이미지들 각각을 위한 기록 테이블, 및 독립적으로 실행 가능한 특정 이미지에 속하는 파트들 각각을 위한 기록 테 이블 각각을 포함한다.

본 발명의 또 다른 실시예(4)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 필요에 따라 생성되는 선형 연속 파트 이미지들은 (a) 프로그램들, Darts, DartProcedures, 또는 프로시져들; (b) 그림들, 비디오, 이미지, 오디오, 소리 또는 렌더링(rendering) 될수 있는 다른 종류의 매체; (c) 데이터 구조 단계들, 리스트들, 및 또는 파라미터들; (d) 데이터 리스트들 또는 데이터 테이블들; 및 (e) 이들의 조합으로 이루어진 세트에서 선택되는 어느 넘버(number) 또는 조합을 포함한다.

본 발명의 또 다른 실시예(5)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 메타 정보를 생성하는 단계는 (a) 식별자(identifier)가 주어진 파트들을 찾기 위한 테이블; (b) 파트들의 테이블을 찾기 위해 사용되는 제1 정보; (c) 상기 선형적 연속 파트 이미지들을 로드하고 실행하기 위한 제2 정보; 및 (d) 독립적으로 실행 가능한 이미지들의 리스트를 찾는 데 사용될 제3 정보 중 어느 하나의 메타 정보를 형성하는 단계를 포함한다.

본 발명의 또 다른 실시예(6)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 다음과 같은 선형적 연속 이진 인코딩 파트 이미들 중세서 하나 또는 그 이상이 또한 형성된다: (i) 프러시져들, Darts, DartProcedures; (ii) 그림들, 오디오, 비디오, 또는 다른 멀티미디어 콘텐트 또는 에니메이션들로 이루어진 콘텐트 아이템들의 세트로부터 선택된 콘텐트를 포함하는 콘텐트; (iii) 데이터베이스들; (iv) 인덱스들; (v) 리스트 아이템들 또는 테이블 아이템들을 위한 파라미 터들; (vi) 버추얼(virtual) 포인터 데이터; (vii) 애플리케이션 힙(heap) 데이터; 및 (viii) 연속된 이진 데이터 이미지로서 표현 가능한 어떤 것.

본 발명의 또 다른 실시예(7)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 다음과 같은 메타 정보가 하나 또는 그이상 또한 형성된다: (i) 서명(signature) 정보; (ii) 이름, 종류, 콘텐트 및 또는 상기 소프트웨어 애플리케이션 패키지의 용도를 식별하기 위해 접근되는 키위드들 또는 다른 정보; (iii) 리스트 아이템들 또는 테이블 아이템들을 위한 파라미터들; (iv) 버추얼 포인터 파라미터들; (v) 보안 체크섬(checksum), 및 또는 서명들, 및 또는 증명(certificate)들 및 또는 하쉬(hash)들; 및 (vi) 유일한 식별자들.

본 발명의 또 다른 실시예(8)에 따르면, 상기 일실시예(1)에 따른 방법을 제공함에 있어서, 상기 단계들은 상기 상호운영 컴파이러, 상호운영 링커 및 또는 상호운영 마스터 플레이어에 구현된 툴들에 의해 실시되는 된다.

VIlI . 다트런타임 /상호운영 런타임( DartRuntime / Interoperability Runtime )

본 발명의 다른 측면에 따르면, Dart 또는 디바이스 제어가 관련된 모든 소프트웨어 운영을 위하여 주로 또는 완전히 이벤트 기반형인 소프트웨어 런-타임 모델(예를 들어, DartRuntime model)이 제공된다. 애플리케이션과 저 레벨의 디바이스 제어 소프트웨어 모두에 공통인 이벤트의 의미, 종류, 구조 및 운용의 세트는 동기 애플리케이션 이벤트 프로세싱과 비동기 애플리케이션, 디바이스, 통신 및 상호운영 동작의 시퀀싱(sequencing)을 드라이브하고 각각의 상호운영 디바이스에서 상호운영 디바이스(도 17의 660 참조)의 팀으로 동작하는 하나의 이벤트 큐(queue) 에 의해 제공된다. 또한, 이벤트의 큐잉(queuing), 디큐잉(dequeuing) 및 프로세싱을 관리하기 위해 사용되는 명령 세트 또는 시스템 호출(call)이 제공된다. 또한, 선택적 로버스트 디바이스 상호운영 통신 런타임 모델이 제공되며, 이러한 모델에 있어서, 디바이스간의 통신이 유지되고 에러 보정되며, 필요한 경우 디바이스 간의 통신이 협력적으로 재수행되나 (reestablished) 이러한 재수행에 의해 상호운영 디바이스들(도 19 참조)간에 효율적으로 구동되는 Darts는 영향을 아주 적게 받거나 받지 않는다. 이러한 특징들은 선택적으로 개별 생성 Darts 및/또는 다른 디바이스들로 확장될 수 있다.

DartRuntime의 다른 측면들은 이하 상술되는 예들 및 예시적 실시예를 포함하여 본 명세서의 다른 부분에 설명된다.

본 발명의 일실시예(1)에 따르면, 하나 이상의 연결된 또는 단속적으로 연결된 디바이스들에 대해 의도한 목적(목표)을 수행하기 위해 필요한 데이터, 코드 및 콘텐트 형태의 메타 정보와 함께 디지털 인코딩 데이터, 코드 및 콘텐트로 이루어진 이벤트 기반 소프트웨어 애플리케이션 패키지를 상호운영 런타임 시스템이 실행하기 위한 방법을 제공한다. 상기 방법은, (a) 개별적으로 실행 가능한 이미지를 독립적으로 구동 가능한 이미지들의 패키지에서 선택하고 로딩하는 단계; (b) 상기 이미지를 실행하여 디바이스들을 팀으로 리크루팅하는 단계; (c) 코드, 렌디션들, 데이터 및/또는 콘텐트 중 적어도 하나를 모집된 디바이스의 팀으로 분배하는 단계; (d) 목적을 수행하기 위해 동기 및 비동기 이벤트들의 순으로 프로세싱하는 단계; (e) 팀으로 모집된 디바이스들 사이 또는 내에서 이벤트 프로세싱을 동기화하 고 시리얼라이징(serializing) 하는 단계; 및 (f) 데이터 및 상태를 저장매체에 저장하는 단계를 포함하는 개별 실행 가능한 이미지들의 런닝 패키지로의 저장 단계를 포함한다.

본 발명의 다른 실시예(2)에 따르면, 상시 일실시예(1)의 방법을 제공함에 있어서, 상기 개별적으로 실행 가능한 이미지를 독립적으로 구동 가능한 이미지들의 패키지에서 선택하고 로딩하는 단계 (a)는 독립적으로 실행 가능한 이미지들의 패키지에서 정확히 하나의 개별 구동 가능한 이미지를 선택하고 로딩하는 단계이다.

본 발명의 다른 실시예(3)에 따르면, 상시 일실시예(1)의 방법을 제공함에 있어서, 상기 런타임은 DartRuntime이다.

본 발명의 다른 실시예(4)에 따르면, 상시 일실시예(1)의 방법을 제공함에 있어서, 상기 선택 및 로딩 단계, 리크루팅 단계, 분배 단계, 프로세싱 단계, 및 동기화 및 리시리얼라이징(reserializing)하는 단계는 모집 절차에 따라 실시된다.

IX . 선형 태스킹( Linear Tasking )

본 발명의 다른 측면에 따르면, 선형 태스킹을 위한 시스템, 장치, 방법 및 컴퓨터 프로그램이 제공된다. 선형 태스킹은 프로세서 제어 및 프로세싱 유닛들간의 디바이스 자원의 간단하고 결정된 흐름을 가능하게 하는 방법론을 포함한다. 프로세싱 유닛들은 애플리케이션, 개별적으로 컴파일된 애플리케이션들, 및 다른 장치에서 동작하는 애플리케이션들로 컴파일된 프로세싱 유닛들을 포함하는 단일 계층체계로 쉽게 재구성될 수 있다.

상호운영 애플리케이션들은 대부분이 개별 사용자를 대상으로 하므로, 선형 태스킹의 장점은 특히 이러한 상호운영 애플리케이션에 적합하다. 여기서, 각각의 프로세싱 유닛으로 제어를 넘겨야 하는 런-타임 페널티(penalty)는 중요하지 않다. 왜냐하면, 인간이 필요로 하는 응답 시간은 통상 1/30초 또는 그 이상이기 때문이다.

본 발명의 선형 태스킹 모델과 방법은 많은 장점을 제공하지만, 단지 몇 가지만 여기서 설명한다. 다른 장점들은 본 명세서의 다른 부분에서의 설명으로부터 명백히 이해될 것이다.

첫번째 장점은, 모든 팀(team) 디바이스들의 모든 프로세싱 유닛들의 프로세싱 순서를 위한 결정론적(deterministic) 또는 이에 가까운(near-deterministic) 패스 덕분에 프로그램밍 모델이 더욱 간단해지고 동작(operations)이 잘 제어된 패턴에 따라 수행되도록 순서를 제한할 수 있어 버그가 상당히 줄어든다는 것이다.

둘째, 모든 프로세싱 유닛들이 방해 받거나 인터럽트 프로세스 동작에 영향 받지 않고 복잡한 동작 시퀀스을 완수 할 수 있다.

셋째, 예를 들어 전원 제어와 같은 애플리케이션에서 사용될 수 있는 셧다운 제어, 대기 및 복귀 제어, 및 수직 레이어링(Vertical Laying) 메커니즘이 손쉽게 지원된다.

넷째, 계층 체계를 구성하고 재구성하는 것이 사용자와의 동작 또는 상호 작용 모드의 변경에 따라 프로세싱 유닛 그룹을 작동(enabling) 및 비작동(disabling) 상태로 만들기 위한 쉬운 방법들 중 적어도 하나가 된다.

다섯째, 부모가 어떻게 비트맵과 같은 출력을 사용한다거나 시간의 센싱과 같은 환경 제어를 한다는 것과 관련된 코드를 자식이 가지고 있지 않아도 부모에 의해 환경이 상속, 변경, 왜곡될 수 있다.

여섯째, 개별적으로 만들어진 실행물(executable)이 쉽게 동작 실행물(running executable)의 프로세싱 계층으로 쉽게 동화(assimilate) 될 수 있다. DartPlatform에서, 이러한 특징 덕분에 Dart가 다른 Dart를 자신의 런타임으로 쉽게 동화(assimilate)할 수 있게 된다. 예를 들어, 상술한 슬라이드 쇼우 다트(SlideShow Dart) 애플리케이션이 쉽게 만들어 지고, 이러한 애플리케이션이 정지 JPEG 그림들을 슬리이드로서 쉽게 수집하듯이 개별적으로 생산된 Dart를 슬라이드로서 수집하여 포함할 수 있다. Dart container Gimo에 의해 Dart가 포함될 수 있는데 반해, 이러한 JPEG 그림은 정지 그림 디스플레이 Gizmo에 의해 포함될 수 있다(Gizmo는 이벤트 프로세싱 유닛들를 위한 기본 호출(base call)들이다).

본 발명의 일실시예에 따르면, 선형 태스킹은 Dart 플랫폼(DartPlatform, 도 3)의 실행을 통해 Dart 프레임워크(DartFramework, 도 11)에서 Dart 런타임(DartRuntime, 도 9, 도 16, 도 17), Dart 엔진(DartEngine, 도 22의 600) 및 Dart 명령 세트(DartInstructionSet, 도 20 및 25)의 명령들로 구현될 수 있는 장점이 있다. 다른 실시예들에 따르면, 완전한 Dart 인프라의 이점을 갖는 대안적 실시예와 함께 이러한 선형 태스킹이 사용될 수 있다.

본 발명의 일실시예에 따르면, 본 발명의 선형 태스킹은 소프트웨어 애플리케이션 프로그램들의 복수의 프로세싱 유닛들의 런타임 환경과 실행을 결정론적으 로 오더링(ordering) 하기 위한 방법을 제공한다. 소프트웨어 또는 펌웨어(firmware) 프로그램 이벤트 기반 런-타임 모델은 모든 프로세싱 유닛들이 상호간의 연결에 기초한 소정의 순서에 따라 실행되는 환경을 제공 또는 생성한다. 소프트웨어 객체 지향 프레임워크, 즉, DartFramework (도 11)이 제공되어, 다음과 같은 객체 멤버들(도 11의 115) 중 적어도 하나 또는 그 이상을 조합으로 포함하는 기본 프로세싱 유닛 클래스(도 11의 Gizmo 115)가 존재하게 된다:

(a) 부모 프로세싱 유닛에 대한 가능한 널 참조;

(b) 자식 프로세싱 유닛들에 대한 참조들의 가능한 엠프티(empty) 순서 선형 리스트;

(c) 이러한 프로세싱유닛에 의해 실시될 이벤트 타입 클래스들에 대응하는 선택 이진 플래그(flag)들;

(c) 더 이상의 자식이 나타나지 않을 때까지 부모에서 자식 프로세싱 체인을 따라 내려가는 자식 프로세싱 유닛들 중 어느 하나에 의해 실시될 이벤트 타입 클래스들에 대응하는 선택 이진 플래그(flag)들;

(d) 부모 및 자식 프로세싱 유닛들에 대한 참조들을 더하거나, 삭제하거나 리오더링(reordering)을 위한 절차적 방법들; 및

(e) 이벤트들의 프로세싱을 오더링(ordering) 하기 위한 절차적 방법. 적어도 하나의 실시예에 있어서, 이벤트들의 프로세싱을 오더링(ordering)하기 위한 상기 절차적 방법 다음 단계들을 포함한다(도 15 참조):

(1) 이벤트 종류, 이벤트에 의해 특정된 프로세싱 유닛의 태스크들 및 현재 의 런-타임 환경의 값들 및 참조들, 부모 및 디바이스의 상태(도 15의 8004 참조)를 기초로 필요한 이벤트의 이전-자식(pre-child) 프로세싱을 수행하는 단계;

(2) 자식 프로세싱 유닛 체인에 의해 어떤 이벤트 타입도 실시되지 않는다는 것을 나타내기 위해서 실시될 이벤트 타입 클래스와 대응하는 선택 플래그들을 세팅하는 단계;

(3) 각각의 자식 프로세싱에 필요한 환경 변화를 셋업하고, 자식 프로세싱 유닛들(도 15의 8005 참조)에 대한 참조 리스트의 순서대로 각각의 자식을 호출(call)하는 단계;

(4) 각각의 호출이 논리적으로 돌아옴에 따라, 결합된 이벤트 프로세싱 타입에 기반한 모든 자식들과 그들의 모든 데시던트(decedent)들의 요구들을 수집하기 위하여 직전에 호출한 자식에 의하여 처리될 필요가 있는 프로세싱 타입 이진 플래그를 오더(order)하는 단계;

(5) 이벤트 종류, 이벤트에 의해 특정된 프로세싱 유닛의 태스크들 및 현재의 런-타임 환경의 값들 및 참조들, 부모 및 디바이스의 상태(도 15의 8004 참조)를 기초로 필요한 이벤트의 이후-자식(post-child) 프로세싱을 수행하는 단계;

(6) 장래에 이러한 프로세싱 유닛에 의해 조정될 이벤트 타입의 플래그를 셋팅하는 단계;

(7) 참조가 널(null)이 아니면(도 15의 8006참조), 부모 프로세싱 유닛으로 제어를 돌려 주는 단계; 및

(8) 부모가 널(null)이면 (도 15의 8008참조), 제어를 주 프로세싱 루프로 돌려 주는 단계.

각각의 자식과 그들의 데시던트들에 의한 프로세싱에 필요하지 않는 이벤트 타입을 나타내기 위해 상기 플래그들이 사용될 수 있으므로, 상기 수집된 이진 플래그들은 선택적으로 호출 그래프를 전지(pruning)하는데 사용될 수 있다. 이벤트 타입 분류에 대응하는 자식이 정한 플래그 값이 1과 관련되지 않으면, 상기 자식과 그 데시던트들은 상기 이벤트를 처리할 필요가 없다.

선형 태스킹의 다른 예시적 실시예들을 이하 설명한다. 본 발명의 일 실시예(1)에 따르면, 소프트웨어 애플리케이션 패키지의 이벤트 프로세싱 유닛들의 이벤트 기반 실행 및 런타임 환경들을 오더하고 관리하기 위한 선형 태스킹 방법이 제공된다. 상기 방법은, 기본 이벤트 프로세싱 유닛 클래스 및 상기 기본 이벤트 프로세싱 유닛 클래스로부터 직접 또는 간접적으로 상속되는 제로 또는 그 이상의 이벤트 프로세싱 유닛 클래스들을 포함하는 소프트웨어 객체 지향형 프레임워크를 제공하는 단계; 이벤트 프로세싱 유닛들의 그래프 또는 토폴러지(topology)를 형성하는 링크들을 생성하거나, 유지하거나, 더하거나, 삭제하거나, 리오더링(reordering)하여 상기 링크들에 의해 형성된 프로세싱 유닛들의 그래프로 이벤트를 통과시키기 위한 선형 결정론적 오더링이 항상 존재하도록 하는 단계; 및 작동 소프트웨어의 필요에 따라 프로세싱 유닛들의 그래프 또는 토폴러지를 동적으로 변경하는 단계를 포함한다.

본 발명의 다른 실시예(2)에 따르면, 상기 일실시예(1)에 따른 선형 태스킹 방법에 있어서, 상기 그래프는 논리적으로 확장되어 하나 또는 그 이상을 다른 애 플리케이션 패키지들의 일부인 하나 또는 그 이상의 애플리케이션 패키지들을 정적으로 참조하여 개별적으로 생성된 애플리케이션 패키지들의 그래프들을 포함한다.

본 발명의 다른 실시예(3)에 따르면, 상기 일실시예(1)에 따른 선형 태스킹 방법에 있어서, 상기 그래프는 논리적으로 확장되어 상기 애플리케이션 패키지의 동작중에 동적으로 개별 생성된 애플리케이션 패키지들의 그래프들을 포함한다.

본 발명의 다른 실시예(4)에 따르면, 상기 다른 실시예(2)에 따른 선형 태스킹 방법에 있어서, 상기 개별적으로 생성된 애플리케이션 패키지 그래프의 노드 최상단에서의 이벤트 프로세싱 유닛은 이벤트 프로세싱 방법에 사용된 파라미터들을 이용하여 자신이 논리적으로 확장된 그래프의 일부분인지 아니면 다른 애플리케이션 패키지에 의해 확장되지 않은 최상위 애플리케이션 패키지의 시작점인지 결정한다.

본 발명의 다른 실시예(5)에 따르면, 상기 다른 실시예(3)에 따른 선형 태스킹 방법에 있어서, 상기 개별적으로 생성된 애플리케이션 패키지 그래프의 노드 최상단에서의 이벤트 프로세싱 유닛은 이벤트 프로세싱 방법에 사용된 파라미터들을 이용하여 자신이 논리적으로 확장된 그래프의 일부분인지 아니면 다른 애플리케이션 패키지에 의해 확장되지 않은 최상위 애플리케이션 패키지의 시작점인지 결정한다.

본 발명의 다른 실시예(6)에 따르면, 상기 다른 실시예(4)에 따른 선형 태스킹 방법에 있어서, 상기 파라미터들이 프로세스될 이벤트를 특정하지 않는 경우에 한해 최상위 노드는 그래프의 선형 오더에서 자신 및 다른 이벤트 프로세싱 유닛들 에 의한 프로세싱을 위한 이벤트의 큐(queue)에서 이벤트를 복구하려고 특정적으로 시도한다.

본 발명의 다른 실시예(7)에 따르면, 상기 다른 실시예(5)에 따른 선형 태스킹 방법에 있어서, 상기 파라미터들이 프로세스될 이벤트를 특정하지 않는 경우에 한해 최상위 노드는 그래프의 선형 오더에서 자신 및 다른 이벤트 프로세싱 유닛들에 의한 프로세싱을 위한 이벤트의 큐(queue)에서 이벤트를 복구하려고 특정적으로 시도한다.

X. 수직 레이어링( Vertical Layering )

본 발명의 다른 측면에 따르면, 수직 레이어링을 위한 시스템, 장치, 방법 및 컴퓨터 프로그램이 제공된다. 수직 레이어링은 본질적으로 툴, 애플리케이션, 프레임워크, 엔진, 렌디션 및 명령-세트 실시, 및 동작들 간의 밀접한 상호작용과 관련된 특성들의 효율적이고 효과적인 실시를 가능하게 한다.

프로그래밍 툴들, 애플리케이션들, 플레이어들, 런타임, 운영 체계, 및/또는 저-레벨 기능들이 데이터 구조와 통신 의미들(semantics)을 공유할 수 있는 경우, 종래의 수평 레이어링의 대안이 되는 본 발명의 수직 레이어링은 여러가지 이점을 제공한다.

일 이행 실시예에 따르면, 수직 레이어링은 선택적으로 그러나 유익하게 DartPlatform (도 3)의 실행으로 구현된다. 수직 레이어링이 DartPlatform에 유익하게 구현된 두 가지 예는 전원관리와 애플리케이션 레벨 에러 복구(도 19)이다.

예를 들어, 전원 관리 기능은 가장 낮은 레벨에서 검출되는 입력 또는 출력 에 기초한 발견법(heuristics)을 사용하는 종래의 디바이스들에서 가장 흔히 이용되는 기능이다; 그러나, 제어가 자신의 프로세싱으로 돌아가 1/30초 내에 비디오의 다음 프레임을 해독(decode)해야 하는지 아니면 사용자가 어떤 행위를 할 때까지는 더 이상의 프로세싱이 필요 없는지를 상기 애플리케이션 자체만이 실제로 알고 있다.

본 발명의 바람직한 일실시예에 따르면, Dart 런타임(DartRuntime)이 Gizmos(도 11, 도 15)라고 불리는 이벤트 프로세싱 유닛들의 단일 계층 선형 태스킹으로 각각의 패스를 만드는 동안, 다트 플랫폼(DartPlatform)은 프로세서 응답 요구사항을 수집한다. DartRuntime (도 15) 인트라-디바이스 파트들의 각각의 패스 이후에, 상기 Gizmo의 Dart 프레임워크(DartFramework) 계층 기반의 프로세싱 유닛들(도 11)을 이용하여 Dart가 만들어질 때 마다, 디바이스 엔진 (DartEngine, 도 22의 600)의 이벤트 큐(EventQueue, 도 22의 660)에서 상기 DartPlatform은 최소의 동기 Gizmo 트리 응답 시간 요구들(도 15의 8010)을 비동기 이벤트 타임 요구들과 결합하여 상기 디바이스가 DartPlayer의 제어로 돌아가기 전에 전원을 차단하거나 전원 레벨 또는 소비를 줄일 수 있는 시간을 정확하고 신뢰할 수 있게 결정한다. 프로세서 논리 시계를 줄이기, 논리 또는 전원 공급 레벨 줄이기, 또는 큰 회로의 일부로의 전원을 차단하는 것관 같은 전원관리 방법들은 종래에 알려져있다. 예를 들어, 상술한 상호운영 슬라이드 쇼 Dart 애플리케이션을 고려해 본다. 시발(originating) 디바이스상에서 작동하는 상기 애플리케이션은 예를 들어 다섯 디바이스로 이루어진 팀(team)을 모집을 통해 형성할 수 있으며, 비록 선택적으로 스 케일되거나 각각의 연결 및 디바이스에의 효과적인 전송과 디스플레이를 위해 수정되기는 하였지만, 팀의 각각의 디바이스들은 시발 애플리케이션과 동일한 슬라이드를 디스플레이 한다. 무선으로 연결되는 디바이스가 무선 통신 범위를 벗어나거나 휴대용 디바이스가 배터리를 아끼기 위해 자동으로 닫혀진 경우 어떤일이 발생하는가. 종래에 구현된 예에서는, 상기 디바이스가 갑자기 무선 통신 범위내로 되 돌아 오거나 또는 상기 휴대용 디바이스가 다시 커지는 경우, 슬리이드 쇼(SlideShow) 애플리케이션만이 어떻게 복구 절차를 수행해야 하는 지를 안다. 종래의 수평적 레이어 장치들의 모든 레벨에서 자연스럽게 복구 절차를 수행하기 위해서는 아주 많은 프로그래밍이 요구될 것이다. 특히, 시발 디바이스가 아닌 디바이스의 전원이 차단되고 모든 슬라이드 쇼 데이터와 상태가 소실된 경우, 더 많은 프로그래밍이 요구될 것이다. 종래의 소프트웨어 에코-시스템은 애플리케이션으로의 연결 중 잃어버린 연결을 검출하는 저-레벨 루틴부터 모든 레벨에 있어서 필요한 의미론적 수평 구조로 구성되지 않았기 때문에 상기와 같은 문제가 발생한다. 정보가 애플리케이션에서 저-레벨 통신 시스템 방향 및 그 역방향으로 흐를 수 있는 직접적인 메커니즘이 없이는, 애플리케이션을 프로그래밍하여 자동으로 데이터와 상태 정보가 연결이 복구된 디바이스로 보내도록 하는 것은 어렵다.

DartPlatform에 수직 레이어링이 채택되는 경우, 연결이 유실되는 경우 디바이스 팀에 대한 애플리케이션을 복구하기 위해 애플리케이션 데이터와 프로시져를 재전송하는 것이 DartFramework, DartRuntime, 및 DartEngine을 통해 상기 애플리케이션에 빌트된다. 따라서, DartFramework를 사용하여 빌트되고 DartPlayer에서 실행되는 애플리케이션은 로버스트(robust) 멀티-디바이스 애플리케이션 및 데이터 동기 복구를 위한 특별한 프로그래밍을 필요로 하지 않는다.

Dart 플랫폼의 일실시예에 따르면, 종래의 저-레벨 동작들 (예를 들어, 통신 동작)은 DartInstructionSet에서 구동하는 상기 Dart 애플리케이션과 통신을 조정하고 있는 네이티브 코드 사이에서 직접 DartEvent를 전송하는 방식으로 종래의 고-레벨 동작들(예를 들어, 상기 애플리케이션)과 직접적으로 상호작용 한다.

DartTools(도 3의 200, 도 12의 200), DartlnstructionSet, DartRuntime(도 9, 도 15, 도 16, 도 17) 및 선형 태스킹(도 18)은 애플리케이션이 DartEngine내의 통신 기능들과 정확히(또는 거의) 같은 구조 및 의미(semantics)로 DartEvent들을 생성하고 처리하는 앱스트랙션의 레이어가 거의 없는 환경을 제공하기 위하여 설계되었다. 따라서, 애플리케이션들이 쉽고 효과적인 방법으로 자신의 요구사항 및 상태를 수집하고, 수집된 요구사항 및 상태를 DartPlatform의 파트인 다른 소프트웨어 동작들에 대하여 동기화하고 통신할 수 있으며, 이는 모든 레벨의 상호운영 시스템의 모든 콤포넌트가 이해하는 이벤트의 전송 및 처리를 통해서 이루어진다. 여기서, 상기 콤퍼넌트가 애플리케이션, 상기 애플리케이션을 구동하는 엔진, 또는 디바이스 팀에 분산된 애플리케이션의 상호운영 파트들의 일부분인지는 문제되지 않는다.

본 발명의 일실시예에 따르면, 수직 레이어에 의해 제공되는 시스템, 방법, 및 컴퓨터 프로그램에 의하면, 소프트웨어 애플리케이션 및 디바이스 제어 소프트웨어의 동작들을 상기 애플리케이션과 디바이스 제어 소프트웨어 사이의 상호운영 기능성의 고-레벨로 결합할 수 있으며, 상기 결합은 복잡하지 않고, 프로세싱, 애플리케이션 프로그램 인터페이스 및 프로토콜 인터페이스가 적게 요구되는 방법 수행된다.

상기 애플리케이션 및 저-레벨 디바이스 제어 소프트웨어에 공통인 이벤트에 대한 이벤트 의미(semantics), 종류, 구조 및 동작의 세트뿐만아니라, 애플리케이션 또는 디바이스 제어의 관련여부에 상관없이 모든 소프트웨어 동작들에 대하여 거의 이벤트 기반 구동되는 소프트웨어 런-타임 모델이 또한 제공된다. 동기 애플리케이션 이벤트 프로세싱 및 비동기 애플리케이션, 디바이스, 통신 및 상호운영 동작들의 시퀀싱을 구동하기 위한 이벤트 큐가 제공된다. 또한, 수직 레이어링 시도는 이벤트의 큐잉(queuing), 디큐잉(dequeuing) 및 프로세싱을 관리하기 위한 명령 세트 또는 시스템 호출을 제공한다.

또한, 선택적 로버스트 디바이스 상호운영 통신 렌타임 모델이 제공될 수 있다. 이러한 모델에서, 디바이스간의 통신이 유지 및 에러 보정되며, 필요한 경우 상호운영에 의해 그러나 상호운영 디바이스의 팀간에서 효과적으로 구동되는 애플리케이션에 혼란은 작게 주면서 디바이스간의 통신이 재설정된다.

협력적인 디바이스 팀을 통과하는 이벤트에 대한 시리얼리제이션(serialization) 및 동기화를 위한 시스템이 비동기 동작의 상호운영 시스템의 모든 콤포넌트을 밀접하게 결합하는데 사용되는 경우 신뢰할 수 있고, 실시하기에 단순하고, 사용하기에 간단하고 효율적이다는 이점을 제공한다.

본 발명의 다른 실시예에 따르면, 디바이스 또는 통신 디바이스의 세트에서 의 소프트웨어 애플리케이션의 동작 및 디바이스 제어 소프트웨어 동작을 하나 또는 그 이상의 협력적 디바이스에서의 소프트웨어 동작간에 존재하는 고효율이고 아주 융통성있는(flexible) 협력적 기능성에 직접적으로 결함하기 위한 방법, 컴퓨터 프로그램 소프트웨어, 디바이스 및 시스템이 제공된다. 이는 소스 코드 및 자원, 소프트웨어 툴, 미리 패키지되거나 미리-정해진 소프트웨어 프레임웨크 또는 라이브러리, 이벤트 기반 런타임, 및 명령 세트 또는 시스템 호출의 세트를 포함하여 각각의 디바이스에 대한 이벤트 큐(queue)를 관리한다. 본 발명의 적어도 일실시예에 있어서, 정확하게 하나의 이벤트 큐가 각각의 디바이스에 대하여 상기한 목적을 위해 관리된다.

상기 애플리케이션은 Dart일 수 있고, 상기 디바이스 제어 소프트웨어는 DartEngine 또는 DartPlayer일 수 있다. 본 발명의 실시예에 따르면, 디바이스 세트는 본 명세서에서 설명된 모집(recruitment) 방법 또는 디바이스 팀을 리크루트하기 위한 다른 방법을 이용하여 구성된 팀을 포함하거나 이러한 팀이다. 본 발명의 일실시예에 따르면, 상기 소프트웨어 프레임워크는 DartFramework이다. 본 발명의 일실시예에 따르면, 상기 이벤트 기반 런타임은 DartRuntime이다. 본 발명의 일실시예에 따르면, 상기 소스 코드와 자원은 DartSource 소스 코드이고, 소프트웨어 툴은 DartTool이다. 본 발명의 일실시예에 따르면, 명령 세트와 시스템 호출은 DartInstructionSet 및/또는 빌트-인 타입의 명령의 일부로 행사될 수 있는 기능에 의해서 제공되며, 상기 빌트-인 타입 명령으로는 예를 들어 Dart BUILTINJNSTRUCTION (도 20의 670, 671, 672, 673) 및/또는 OEM_BUILTIN_INSTRUCTION. (도 20의 674, 680, 681 , 682)이 있다.

본 발명의 적어도 일실시예에 있어서, 디바이스 시스템(도 17의 800), 애플리케이션들, 및 통신 코드 사이에서 정보 및/또는 콘텐트 및/또는 상태에 대한 통신을 수행하기 위해 사용되는 공통적으로 이해되는 의미론(semantics)을 가지는 단일 데이터 구조를 가짐으로써 적어도 부분적인 효율성이 달성된다.

본 발명의 적어도 일실시예에 있어서, 예를 들어 DartEvents(도 17의 800)와 같은 이벤트는 단일 데이터 구조로서 사용된다.

본 발명의 적어도 일실시예에 있어서, 상기 디바이스 제어 소프트웨어 동작들은 통신, 디바이스 구성 관리, 디바이스 발견, 관리 할당, 메모리에 대한 할당해제(de-allocation) 및 접근, 물리적 저장매체, 물리적 디스플레이, 물리적 입/출력 장치 또는 디바이스의 다른 물리적 또는 소프트웨어 가상적 물리적 측면을 포함한다.

본 발명의 일실시예에 있어서, 소프트웨어 툴은 소프트웨어 소스코드 및 자원을 취해서 미리 구체화된(pre-specified) 소프트웨어 프레임워크를 이용하며, 이는 프레임워크는 이벤트의 인규잉(enqueuing), 프로세싱 및 디큐잉(dequeuing)을 관리하는데 사용되는 명령 세트 또는 시스템 호출의 세트에 대한 접속에 의해 지원받는 런타임의 이벤트 기반 실행 모델에 대한 순응을 소셜 시큐리티한다.

본 발명의 적어도 일실시예에 있어서, 상기 애플리케이션의 이벤트 프로세싱은 도 15, 9, 16, 및 17에 도시된다. 본 발명의 적어도 일실시예에서, 디바이스의 큐에 위치한 이벤트들은 시리얼라이즈(serialize)되고 동기화된다. 이러한 시리얼 라이즈 및 동기화는 도 9에 도시된 방법에 따라 수행된다.

수직 레이어링과 관련된 예시적 실시예들이 이하 설명된다. 본 발명의 일실시예(1)에 따르면, 하나 또는 그 이상의 팀을 이루는 디바이스들 간의 애플리케이션 레벨 동작, 디바이스 하드웨어 제어 레벨 동작, 통신 레벨 동작, 또는 다른 레벨 또는 동작의 서브세트를 수행하는 절차적(procedural)(software) 콤포넌트들 사이의 데이터의 이동 및 동작을 코디네이팅(coordinating)하기 위한 이벤트 기반 수직 레이어링 시스템을 제공하여, 절차적(소프트웨어) 콤포넌트들간의 효율적 및/또는 로버스트(robust) 협력 기능성을 구축할 수 있다. 상기 시스템은, (a) 데이터 필드 및 필드의미(field semantics)가 하나 또는 그 이상의 디바이스들간에서 생성되고 프로세싱되는 모든 이벤트들 및 하나 또는 그 이상의 디바이스들에서 구동하는 절차적(소프트웨어) 콤포넌트들에게 일반적으로 알려지고 이해되는 정적 이벤트 데이터 구조; (b) 이벤트 데이터 구조 인스턴스(instance)로의 접속을 저장, 제거, 관리 및 제어하는 팀을 이루는 각각의 디바이스상의 큐; (c) 모든 협력적 절차(소프트웨어) 콤포넌트에서 엑세스할 수 있는 큐상의 이벤트들을 위치하고 변경하고 제거하는 동작을 관리하기 위한 수단; (d) 협동하는 디바이스들의 큐들 사이에서 시리얼라이즈(serialize) 및 동기화될 이벤트 타입의 공통 리스트를 특정하고 유지하기위한 수단; 및 (e) 어떤 절차적(소프트웨어) 콤포넌트가 이벤트를 시작가 시작되도록 했는지 여부나 팀을 구성하는 디바이스 중 어느 것에서 상기 이벤트를 시작하게한 상기 절차적(소프트웨어) 컴포넌트가 구동되고 있는지 여부에 상관없이, 상기 공통 리스트의 어떤 타입의 모든 이벤트들이 상기 절차적(소프트웨어) 콤포넌트 들에 의해 모든 디바이스에 대해 정확히 동일한 순서로 처리되도록 보장하는 수단을 포함한다.

본 발명의 다른 실시예(2)에 따르면, 상기 일실시예(1)에 의한 시스템에서, 이벤트 데이터 구조 인스턴스(instance)로의 접속을 저장, 제거, 관리 및 제어하는 팀을 이루는 각각의 디바이스상의 상기 큐는 각각의 디바이스마다 정확히 하나가 구비된다.

본 발명의 다른 실시예(3)에 따르면, 상기 일실시예(1)에 의한 시스템에서, 모든 협력적 절차(소프트웨어) 콤포넌트에서 엑세스할 수 있는 큐상의 이벤트들을 위치하고 변경하고 제거하는 동작을 관리하기 위한 상기 수단은 상기 상호운영 디바이스들의 프로세서 논리에서 샐행되는 복수의 프로프램 명령들을 가지는 컴퓨터 프로프램으로서 구현된 프로시져를 포함한다.

본 발명의 다른 실시예(4)에 따르면, 상기 일실시예(1)에 의한 시스템에서, 협동하는 디바이스들의 큐들 사이에서 시리얼라이즈(serialize) 및 동기화될 이벤트 타입의 공통 리스트를 특정하고 유지하기위한 상기 수단은 상기 상호운영 디바이스들의 프로세서 논리에서 샐행되는 복수의 프로프램 명령들을 가지는 컴퓨터 프로프램으로서 구현된 프로시져를 포함한다.

본 발명의 다른 실시예(5)에 따르면, 상기 일실시예(1)에 의한 시스템에서, 어떤 절차적(소프트웨어) 콤포넌트가 이벤트를 시작가 시작되도록 했는지 여부나 팀을 구성하는 디바이스 중 어느 것에서 상기 이벤트를 시작하게한 상기 절차적(소프트웨어) 컴포넌트가 구동되고 있는지 여부에 상관없이, 상기 공통 리스트의 모든 타입의 이벤트들이 상기 절차적(소프트웨어) 콤포넌트들에 의해 모든 디바이스에 대해 정확히 동일한 순서로 처리되도록 보장하는 상기 수단은 상기 상호운영 디바이스들의 프로세서 논리에서 샐행되는 복수의 프로프램 명령들을 가지는 컴퓨터 프로프램으로서 구현된 프로시져를 포함한다.

본 발명의 다른 실시예(6)에 따르면, 상기 일실시예(1)에 의한 시스템에서, 다음 사항들 중에서 하나 또는 그 이상 또는 이들의 조합이 만족(true)된다: (1) 상기 정적 이벤트 데이터 구조는 DartEvent이다; (2) 상기 팀을 이루는 디바이스들은 상호협동을 위해 디바이스 모집을 통해 어셈블된다; (3) 이벤트를 위치시키고, 변경하고, 제거하는 동작을 관리하기 위한 방법은 상호운영 Instruction Set 또는 DartInstructionSet의 사용을 통해 엑세스된다; (4) 상기 시스템은 자신의 이벤트 기반 기능성을 상기 상호운영 Runtime 또는 DartRuntime을 통해 적어도 일부 수행한다; (5) 상기 공통 리스트를 특정하고 상기 공통 리스트의 어떤 타입의 이벤트들 모두가 동일한 순서로 처리되는 것은 모집에 대해 이벤트를 시리얼라이즈 및 동기화하기 위함이다; 및 (6) 상기 상호운영 툴 또는 DartTool은 상기 시스템의 소프트웨어 애플리케이션 동작 코드를 생성하기 위해 사용된다.

XI . 애플리케이션 이벤트 기반 전원 관리( Application Event Driven Power Management )

다트 프레임워크(Dart Framework)에서 적어도 부분적으로 예시된 것처럼 선형 태스킹 및/또는 수직 레이어링(layering)을 이용하여 구축된 다트(Dart) 애플리케이션은 항상 그것들의 정확한 반응 시간 요구를 기록하여, 프로세서를 늦추는 것 과 같은 효율적인 전원 관리 기술로 배터리의 수명을 늘리거나, 소비되는 에너지의 양, 또는 장치에서 발생하는 열을 제한할 수 있다는 것을 기억하라. 현 기술 상태에서 대부분의 애플리케이션은 그것들의 정확한 반응 시간 요구를 기록하지 않는다. 그리고, 애플리케이션이 존재하는 프로토콜의 레이어를 통해 이러한 요구를 의사소통할 수 없다면, 대부분의 애플리케이션은 그것들의 정확한 반응 시간 요구를 또한 기록하지 않는다. 여기서, 상기 존재하는 프로토콜의 레이어는 디바이스의 하드웨어에서부터 애플리케이션에 걸쳐 의사소통 반응 시간 요구에 대한 인터페이스를 포함하지 않는 규격(specification)을 따른다.

애플리케이션 구동 전원 관리를 특정 실시예를 이하 설명한다. 추가적인 실시예들이 또한 설명된다. 본 발명의 일실시예(1)에 따르면, 디바이스의 에너지 및 전원을 관리 및 에너지 및 전원 소비를 줄이는 방법을 제공한다. 상기 방법은: 에너지 및 전원 관리 및 소비를 감소시킬 수 있는 적어도 하나의 장치 내에서 이벤트 구동 런타임 환경을 구축하는 단계; 모든 동기 및 비동기 프로세싱 이벤트를 확인하는 적어도 하나의 이벤트 큐(queue)와 큐에서 프로세싱 이벤트에 대한 관련된 최소 기대 프로세싱 시간을 생성하고 유지하는 단계; 및 상기 큐에서의 기대되는 최소 동기 및 비동기 이벤트 프로세싱 시간에 기초한 마지막 최소 예상 반응 시간을 선택하는 단계를 포함한다.

본 발명의 다른 실시예(2)에 따르면, 상기 일실시예(1)의 방법은, 모든 비동기 프로세싱을 구동하고, 어떤 비동기 이벤트가 처리될 필요가 있기 전에 필요한 최소 시간을 모으는 제 1 비동기 이벤트 큐 상에서 모든 이벤트를 찾는 단계; 모든 동기 프로세싱을 구동하고, 어떤 동기 이벤트가 처리될 필요가 있기 전에 필요한 최소 시간을 모으는 제 2 비동기 이벤트 큐 상에서 모든 이벤트를 찾는 단계; 및 비동기 이벤트에 대해 필요한 최소 시간 및 동기 이벤트에 대해 필요한 최소 시간 중 더 짧은 시간을 선택함으로써 필요한 마지막 최소 반응 시간을 결정하는 단계를 더 포함한다.

본 발명의 다른 실시예(3)에 따르면, 상기 다른 실시예(2)의 방법은, 다른 이벤트를 더 프로세싱하기 전에 마지막 최소 반응 시간 값을 이용하여 전원 관리 또는 전원 소비 감소 작업을 수행하는 단계를 더 포함한다.

본 발명의 다른 실시예(4)에 따르면, 상기 다른 실시예(2)의 방법에서, 제 1 비동기 이벤트 큐 및 제 2 비동기 이벤트 큐는 같은 단일 통합 이벤트 큐이다.

본 발명의 다른 실시예(5)에 따르면, 상기 다른 실시예(2)의 방법에서, 제 1 비동기 이벤트 큐 및 제 2 비동기 이벤트 큐는 다른 이벤트 큐이다.

본 발명의 다른 실시예(6)에 따르면, 상기 다른 실시예(3)의 방법에서, 이벤트들은 다트 이벤트이다.

XII . 상호운영 애플리케이션 이벤트 기반 에러 복구( Interoperability Application Event Driven Error Recover )

간섭, 거리 제한 및 낮은 배터리 전력에 기인한 갑작스런 셧다운 때문에 디바이스간의 무선 통신 접속이 종종 불안정하게 된다는 것을 상기하자. 디바이스에 대한 종래의 수평 계층 프로토콜 소프트웨어 구현시에, 어느 한 계층에서의 치명적인 에러는 애플리케이션이 복구되기 어려운 회복불능의 에러를 초래할 것이다. 이 것은 상기 애플리케이션이 접속 및 접속의 상황정보(contexts)를 용이하게 복구하기 위한 표준 인터페이스를 갖고 있지 않으며, 종래 애플리케이션 프로그램들이, 다른 디바이스상에서 운용되는 애플리케이션간 공유 상태(state)를 트랙킹하고 복구하기 위한 많은 기반 구조를 가지고 있지 않기 때문이다. 다트 프레임워크(DarkFramework)는 공유 상태(shared state)의 트랙을 유지하고, 렌디셔닝(renditioning)하는 디바이스간 로스트 상태(lost state)를 용이하게 복구하기 위해 사용될 수 있으며, 수직 레이어링(Vertical Layering)은 통신 에러들이 다트(Dart)로 중계되는 것과 상기 다트(Dart)가 복구정보를 통신 처리 유닛들로 직접적으로 중계하는 동작을 간단하게 만든다. 따라서, 디바이스들에 걸쳐 동작하는 다트(Dart)들은 협동하는 디바이스들(cooperating devices)간 통신의 단속적인 완전 로스(loss)로부터 고르게 복구될 수 있으며, 이전에 로스트된 디바이스가 그 모든 애플리케이션 상태를 잃었을 경우에도 접속이 복구되면 디바이스들의 공유상태 복구를 할 수 있다.

상호운영 이벤트 기반 에러 복구의 추가적인 실시예에 대해서 설명하도록 하겠다. 일 실시예(1)에서, 본 발명은 로스트된 또는 단속적인 통신 환경에서 적절하게(gracefully) 운영을 계속하는 방법을 제공하며, 여기서, 다중의 팀으로 구성된 디바이스들에 걸쳐 협동적으로 동작하는 이벤트 기반 상호운영 애플리케이션 패키지는 그 운영을 적절하게 계속하고/계속하거나, 팀의 일부인 디바이스들과의 통신의 일시 중단(loosing)으로부터 부분적으로 복구된다. 상기 방법은, (1)애플리케이션 패키지의 목적(intent)의 일부를 수행하는 팀 멤버 디바이스로로부터 팀으로 구 성된 디바이스로의 통신이 로스트되거나 중단되어 소정의 또는 동적으로 결정된 시간내에 복구될 수 없을 때, 상기 팀 멤버 디바이스상에 통신 세션 로스트 타입 이벤트 인스턴스(instance)를 생성하는 단계; (2)직접적으로 또는 애플리케이션 패키지의 동기 운영을 동작시키는 이벤트 큐(queue)를 통해서, 통신 세션 로스트 이벤트들을 다루는 애플리케이션 이벤트 처리 유닛으로 상기 통신 세션 로스트 타입 이벤트를 전송하는 단계; (3) 통신이 로스트되거나 중단된 팀으로 구성된 디바이스 없이 그 운영을 계속할 수 있는 애플리케이션 패키지의 동작(behavior)을 상기 애플리케이션 패키지의 이벤트 처리 유닛이 변경하는 단계; (4) 팀 멤버 및 팀으로 구성된 디바이스들 간의 통신이 복구되면 통신 세션 복구 타입 이벤트 인스턴스를 생성하는 단계; (5) 직접적으로 또는 애플리케이션의 동기 운영을 운용하는 이벤트 큐(queue)를 통해서, 복구된 통신 세션들을 다루는 애플리케이션 이벤트 처리 유닛으로 상기 통신 세션 복구 타입 이벤트를 전송하는 단계; (6) 상기 애플리케이션의 이벤트 처리 유닛이, 상기 팀 멤버 디바이스가 상기 팀으로 구성된 디바이스를 잔여 이벤트 기반 상호운영 애플리케이션과 동기화 시키는데 필요한 코드, 데이터, 및 또는 콘텐트를 무엇이든 전송하도록 하는 단계; 및 (7) 상기 애플리케이션의 목적을 수행하는 과정에서 현재 복구된 팀으로 구성된 디바이스를 포함하도록 상기 애플리케이션의 이벤트 처리 유닛이 상기 애플리케이션의 동작을 변경하는 단계를 포함한다.

또 다른 실시예(2)에서, 본 발명은 상기 (1)의 방법을 제공하며, 여기서 다음의 하나 또는 그 이상의 어느 조합도 사실이다: (1) 이벤트 기반 상호운영 애플 리케이션 패키지가 상호운영 포맷을 따르거나, 다트포맷(DartFormat)이다; (2) 상호운영 애플리케이션은 본 상세한 설명의 다른 부분에 기술한 바와 같이 다트(Dart)이다; (3) 리크루트(recruit)방법은 다중의 팀으로 구성된 디바이스들간의 협동적인 동작을 설정하기 위해 사용된다; (4) 이벤트들은 다트이벤트(DartEvent)들이거나 상기 다트이벤트들을 포함한다; (5) 이벤트 처리 유닛은 다트 기즈모 클래스 인스턴스(Dart Gizmo class instance) 또는 다트 기즈모 클래스로부터 직접적으로 또는 간접적으로 승계된 어느 클래스의 인스턴스이다; (6) 이벤트들의 조정(coordination) 및 동기화는 상호운영 엔진에 의해 각 디바이스 별로 수행되거나, 다트엔진(DartEngine)에 의해 수행된다; 그리고 (7) 디바이스들 상 및 디바이스들 간의 이벤트들의 조정 및 동기화는 상호운영 실행 시간 또는 다트실행시간(DartRuntime)에 따라 수행된다.

또 다른 실시예(3)에서, 본 발명은 상기 (1)의 방법을 제공하며, 여기서 상기 팀으로 구성된 디바이스 없이 그 운영을 계속하기 위한 애플리케이션의 변경된 동작은 다음의 하나 또는 그이상의 어느 조합으로 구성된 변경 세트에서 선택적으로 선택된다:(1) 로스트된 디바이스는 애플리케이션이 디스플레이없이 계속되도록하는 상태(status)를 간단히 디스플레이하고 있다; (2) 로스트된 디바이스에 의해 수행되는 기능들은 중복(redundant)되며 따라서 애플리케이션의 목적(intent)를 수행할 필요가 없다; (3) 로스트된 디바이스에 의해 수행되는 기능들은 팀의 어느 잔류 멤버 또는 멤버들에 의해 대신 수행될 수 있다; (4) 로스트된 디바이스에 의해 수행되는 기능들은 상기 팀에 의해 도달 가능한 다른 디바이스에 의해 대신 수행될 수있으며, 그에 따라 상기 다른 디바이스는 상기 팀으로 리크루트될 수 있다; (5) 잔류 팀 디바이스들의 기능은 운영 축소 모드에서 수행될 수 있다; 및 (6) 위 사항들의 어느 조합.

XIII . 상호운영 명령 세트( interoperability instruction set )

또 다른 측면에서, 본 발명은 상호운영 방법, 소프트웨어 및 명령 세트를 제공한다. 상호운영성 명령 세트(interoperability instruction set: IIS)를 이행하는 소프트웨어나 하드웨어는: (ⅰ) 애플리케이션을 묶고(teaming) 분포시키거나(spreading) 분할(distributing)하기 위한; (ⅱ) 수정되지 않은 애플리케이션들을 그렇지 않으면 상이한 디바이스들 상에서 실행하기 위한; 그리고 (ⅲ) 고유 리소스들, 고유 자격(capability)들 및/또는 고유 콘텐트를 다른 애플리케이션들 및 디바이스들에 노출시키기 위한 모집 모델의 도움을 받는 공통의 절차적 환경을 제공하기 위한 효율적 방법론(methodology)이다.

본 발명의 일 실시예에서, 상기 상호운영성 명령-세트는 다트 엔진(DartEngine, 도 22의 600)으로 구체화 되거나 그것과 호환되는 다트 명령 세트(DartInstructionSet)이다.

컴퓨터 및 정보 시스템들의 콤포넌트(component)들과 디바이스들은 하드웨어, 펌웨어 및/또는 소프트웨어에 이행될 수 있고, 특정 이행의 특정 콤포넌트를 위해 하드웨어, 펌웨어 또는 소프트웨어 중 어떤 것을 사용할지에 대한 디자인 및 이행의 선택이 종종 존재한다는 것이 이해될 것이다. 따라서 다트(Dart) 엔진 및 상호운영성 명령 세트에 의한다. 그러므로 특정 실시예들의 특정 콤포넌트들이 하 드웨어, 펌웨어 또는 소프트웨어 중 하나로 표현되었더라도 선택 가능한 또 다른 실시예들은 원하는 기능이나 결과를 달성하는 수단을 제공하기 위해 하드웨어, 펌웨어 또는 소프트웨어의 다양한 조합을 사용할 수 있다.

일 실시예에서, 상호운영성 명령-세트를 실시하기 위한 상기 하드웨어 및/또는 소프트웨어는 11개의 요소들로 구성되는데, 다만 상기 요소들과 기능들은 달리 묶여질 수도 있어서 그 수가 명령 세트 또는 엔진의 구조나 작동에 의해 제한되지는 않는다(도 4의 3010 참조).

첫 번째, 디바이스 밖의 시스템, 디바이스, 네트워크 등에서 실행되고 그들 내외부로의 통신을 유지하는 프로그램들을 위한 프로세서 또는 중앙 처리 유닛(CPU), 메모리, 및 입출력(I/O) 자격.

두 번째, 적어도 종래의 일반적인 컴퓨팅 태스크(task)를 위해 메모리 액세스(memory access), 연산(computation), 테스트 및 분기(branch), 입출력 명령들이 있어야 한다.

세 번째, 공통 이진 애플리케이션들과 렌디션들(Renditions)의 실질적 범위를 저성능 디바이스들로 확장하기 위해 사용되는 상호운영 성능 향상 명령들이 유리하게 제공된다.

네 번째, 모집(Recrutiment), 렌디셔닝(Renditioning), 크리에이셔니즘(Creationism), 수직 레이어링(Vertical Layering), 선형 태스킹(Linear Tasking), 소셜 동기화(Social Synchronization), 소셜 시큐리티(Social Security) 및 버츄얼포인터(VirtualPointer)들의 다트 방법론(Dart methodology)을 수행하기 위한 상호운영 명령들이 유리하게 제공되는데, 다만 본 명세서의 다른 부분에서 언급된 것처럼 모든 실시예에 이러한 다트 요소들이 모두 필요한 것은 아니다.

다섯 번째, 특수한 디바이스로부터 소프트웨어 애플리케이션들과 기타 디바이스들에 액세스 가능한 또는 그에 지배되는 임의의 특성(characteristics), 자원(resources), 자격(capabilities) 및/또는 기능들을 노출시키는 데에 효과적인 특정 고유 자격 명령(capability instruction)들도 유리하게 제공된다.

여섯 번째, 보안 특징의 설정, 상호 디바이스 액세스 권리와 디바이스들의 결합 및/또는 애플리케이션의 디바이스들 및/또는 리소스들에 대한 액세스 권리의 설정을 제어하거나 아니면 액세스하기 위해 보안 유지 명령들이 유리하게 제공된다.

일곱 번째, 다트(Dart)들 또는 다트 호환 명령들이, 개시 다트(originating Dart)의 작동의 일부분으로 수집되고, 보존되고, 작동되는, 기타 별도로 생성된 다트들을 가로질러 개시 다트의 실행을 효과적으로 확장할 수 있도록 하기 위해 예컨대 다트 억제(DartContainment) 명령들과 같은 억제 명령들도 유리하게 제공된다.

여덟 번째, 그림, 비트맵, 사운드, 입력 이벤트, 텍스트 렌더링 등의 작업들의 조작 및 렌더링, 디코딩, 인코딩, 압축 및 압축 해제 중 하나 이상을 위한 공통적인 사용자 인터페이스(UI) 명령들이 유리하게 제공된다.

아홉 번째, 예컨대, 세션들과 그 세션들을 통해 지나다니는 데이터들을 열고, 닫고 보존하기 위한 통신 명령들이 유리하게 제공된다.

열 번째, 스토리지들, 스토리지 디바이스들, 스토리지 리소스들 등에 대한 액세스를 제어하고 보존하기 위해 저장 명령들이 유리하게 제공된다.

열한 번째, 데이터, 콘텐트 및/또는 코드의 다른 포맷들 또는 특성들 사이의 변환(convert) 또는 코드전환(transcode)을 위해 호환 명령들이 유리하게 제공된다.

예컨대 가상 컴퓨터(virtual machine)의 이용과 같은 기타 공통 방법론들에 걸친 상호운영성 명령-세트의 이점들은, 상호운영성 명령 세트 (특히 다트 상호운영성 명령 세트)가, 모든 필수 상호운영성 작업들을 디바이스 프로세서의 네이티브 코드(native code)로 컴파일(compile) 또는 어셈블(assemble)된 기능들에 배정된 명령들로서 수행하도록 설계되고 최적화되었다는 것이다. 몇가지 선택적인 특징들과 자격들을 포함하는 일 실시예에서, 상기 상호운영성 명령-세트는 이하의 전부 또는 대부분을 구비해야 한다: (ⅰ) 모집(Recruitment) 명령들, (ⅱ) 프로파일(Profile) 명령들, (ⅲ) 싱크로나이징(Synchronizing) 명령들, (ⅳ) 사용자 인터페이스 또는 UI 및 그래픽 명령들, (ⅴ) 전력 관리 명령들, (ⅵ) 커넥션 및 세션(Connection and Session) 관리 명령들, (ⅶ) 스토리지(Storage) 명령들, (ⅷ) 렌디션(Rendition) 명령들, (ⅸ) 크리에이셔니즘(Creationism) 명령들, (ⅹ) 애플리케이션 파트 관리 명령들, (xⅰ) 암호 대수 수학(cryptographic large number math) 명령들, (xⅱ) 텍스트 및/또는 기호 해석(parsing) 명령들, (xⅲ) 버츄얼 포인터(Virtual Pointer) 관리 명령들, 및 (xⅳ) 디바이스의 고유 자격들을 다트(DART)들에, 그리고 따라서 임의의 기타 다트디바이스(DartDevice)들이나 다트(Dart) 호환 디바이스들에 노출시킬 수 있는 명령들.

이하에서는 상호운영성 명령 세트의 또 다른 특정 실시예들을 설명한다. 일 실시예(1)에서, 본 발명은: 프로세서, 상기 프로세서에 결합된 메모리, 및 디바이스 외부의 실체(entity)에 의한 상기 프로세서와의 통신을 제공하는 입출력(I/O) 인터페이스; 모집(recruitment), 렌디셔닝(renditioning), 크리에이셔니즘(creationism), 수직 레이어링(vertical layering), 리니어-태스킹(linear-tasking), 소셜 동기화(social synchronization), 및 소셜 시큐리티(social security) 중 적어도 하나를 포함하는 방법론들을 수행하기 위한 실행 보조 상호운영성 수단; 및 통신 세션과 그 통신 세션 중 통신 디바이스들 사이에서 지나다니는 절차, 데이터, 콘텐트 또는 기타 정보를 열고 보존하는 통신 상호운영성 명령들을 포함하는, 상호운영성 명령 세트(IIS) 수행 디바이스를 제공한다.

또 다른 실시예(2)에서, 본 발명은 (2)에 있어, 상기 실행 보조 상호운영성 수단은 상기 방법론을 수행하는 상호운영성 명령들을 포함하는 것을 특징으로 하는 디바이스를 제공한다.

ⅩⅣ.형성론( creationism )

본 발명의 또 다른 측면에 따르면, 형성론을 위한 시스템, 장치, 방법 및 컴퓨터 프로그램이 제공된다. 형성론은 다른 상호운영 애플리케이션들(interoperability application)을 형성하기 위해 상호운영 애플리케이션을 가능케 하는 방법론을 포함하고, 이렇게 형성된 다른 상호운영 애플리케이션들은 또 다른 상호운영 애플리케이션들을 형성할 수 있다. 이러한 방식을 이용하면 상이한 형태의 애플리케이션, 데이터, 및 컨텐츠를 연결되거나 단속적으로 연결된 장치들의 계(world)에 걸쳐서 효율적이고 동적으로 생성하고 분배시킬 수 있다.

유리한 일실시예에 따르면, 이것은 다트들(Darts)이 다른 다트들(도 12의 700) 또는 다트 프로시져들(도 14의 4000)을 생성할 수 있는 능력이다. 그러면, 생성된 다트 또는 프로시져들은 또 다른 다트들 또는 다트 프로시져들을 생성할 수 있다. 생성론은 다트 플랫폼(도 3) 전반에 걸쳐 구현된다. 예를 들면, 다트 도구들(200)(도 3)은 소스 코드에 포함된 파트들을 열거할 수 있고, 소스 코드를 이러한 파트들을 포함하고 있는 다트 매스터(DartMaster)(도 12의 230)으로 컴파일한다. 다트 매스터가 매스터 플레이어(도12의 203) 상에 실행되면 필요한 경우 좀 더 많은 자원을 수집할 수 있고, 렌디션들(Renditions) 및 파트들이 출력된 다트 또는 다트 프로시져에 포함되도록 하는데 필요한 정보를 요구하기 위한 사용자 인터페이스를 제공한다.

다트 플레이어 상에서 실행되는 어떠한 다트도 다트 엔진에 지원을 받는 다트 명령세트(DartInstructionSet)로부터의 명령들을 포함하여 파트 및 패키지로부터의 렌디션들을 동적으로 형성함으로써 그것들을 효율적으로 다트 포맷 파일들로 합체시킬 수 있다. 사용자 정의된 다트들을 형성하는 이러한 과정은 형성된 다트 및 프로시져들이 그러한 과정을 수행하는데 필요한 데이터, 컨텐츠, 및 프로시져들로 형성되는 한 무한정 수행될 수 있다.

형성론은 다른 상호운영 애플리케이션들을 형성하기 위하여 상호운영 애플리케이션을 활성화하는 방법, 관련 프로시져, 컴퓨터 프로그램 코드 및 제품을 제공하고, 이러한 것들은 또한 순환적 및/또는 직렬적 및/또는 전개(fanout)적인 방식 으로 또 다른 상호운영 애플리케이션들을 생성한다. 소스코드(100)(도 3) 및 선택적인 소스 데이터 및/또는 소스 자원을 적어도 하나의 렌디션을 포함하는 이진 이미지로 컴파일하기 위한 도구들이 제공된다. 디지탈 파트들을 렌디션 세트(예를 들면, 다트 렌디션들) 및 상기 렌디션들이 통신 능력, 장치 특성 및 타켓 장치의 환경에 기초하여 어떤식으로 조립될 지를 제어하는 파트들을 포함하는 이진 이미지로 동적으로 조립시키기 위한 실행가능한 명령들 및/또는 애플리케이션 프로그래밍 인터페이스(들) 또한 사용되고 제공될 수 있다.

상기 도구들은 다트 도구(200)(도 12)를 포함할 수 있다. 상기 이진 이미지는 다트 포맷(300(도3), 도 13 및 도 14)으로 된 다트를 포함하거나 그러한 다트로 구성될 수 있다. 또는 상기 이진 이미지는 다른 방식으로 포맷된 이진 이미지 또는 비이진 (non-binary) 형태로 인코딩된 이미지일 수 있다. 상기 디지털 파트는 프로시져들, 데이터 세트들, 및/또는 구조화된 숫자열로 표현된 어떠한 타입 또는 형태의 컨텐츠일 수 있다.

생성론의 추가적인 구체적인 실시예들이 후술된다. 일실시예(1)에 따르면, 본 발명은 개별적으로 실행가능한 적어도 하나의 다른 타겟 데이터 이미지 또는 개별적으로 실행가능한 데이터 이미지들의 패키지를 동적으로 생성하여 개별적으로 실행가능한 이미지의 의도 또는 개별적으로 실행가능한 이미지들의 패키지의 의도를 수행하기 위한 개별적으로 실행가능한 초기 이미지 또는 개별적으로 실행가능한 이미지들의 패키지를 활성화하는 방법에 있어서, 장치들의 특징, 컨텐츠, 자원들, 또는 능력들, 또는 생성된 실행가능한 이미지들 또는 실행가능한 이미지 또는 패키 지를 생성하는 의도 또는 의도의 일부를 수행하는데 사용될 수 있는 이미지들의 패키지들을 수행하기 위한 다른 환경들 중 적어도 하나에 대한 제1 정보를 수집하고(1); 자원들, 능력들, 및 타켓 장치들 또는 정보가 수집된 환경들의 컨텐츠를 효율적으로 사용하기 위해 이미지 자체의 파트들(i), 수집된 정보(ii), 또는 프로그램적으로 생성된 정보 중 적어도 하나를 조립하는 방법을 결정하고(2); 생성된 실행가능한 타겟 이미지 또는 이미지 패키지의 의도를 비한정적인 순서로 수행하는데 필요한 하나 이상의 독립적으로 생성되며 실행가능한 데이터 이미지 또는 이미지 패키지들을 생성하기 위한 제2 정보를 수집하는 것(3)을 포함하여 구성된다.

ⅩⅤ. 상호운영 엔진/ 다트엔진

다트 엔진은 장치 상에 있는 다트들의 명령들을 실행하거나 그러한 명령들의 의도된 목적을 수행하는데 사용되는 소프트웨어 및/또는 하드웨어이거나 그것들을 포함한다는 사실을 상기하라. 다트 엔진 및 상기 다트 엔진이 내장되며 장치에 특유한 다트 플레이어는 일반적인 실행 및 다트런타임(DartRunTime) 환경을 제공하므로 모집(Recruitment) 및 렌디션은 효율적인 장치팀들을 구축할 수 있고, 의도된 다트의 목적을 수행하기 위해 코드, 데이터, 및 컨텐츠를 최대한 분산시킬 수 있다.

상호운영 엔진의 추가적인 구체적인 실시예와, 상호운영 엔진 및 다트 엔지 의 좀더 구체적인 실시예를 후술한다. 일실시예(1)에 따르면, 본 발명은 장치들로 하여금 서로 연동하도록 활성화하거나 도와주는 상호운영 엔진에 있어서, 코드를 구비한 상호운영 소프트웨어 패키지의 의도의 적어도 일부를 로딩, 실행, 및 수행 하기 위한 수단(1)을 포함하여 구성되고, 상기 코드의 적어도 일부는 상호운영 명령세트를 따르는 일련의 명령들에 포함되고; 다른 상호운영 장치을 발견하기 위한 수단(2); 및 다른 상호운영 장치들과 직접 또는 간접적으로 양방향 통신을 수행하기 위한 수단(3)을 포함한다.

또 다른 실시예(2)에 따르면, 본 발명은 실시예(1)에서와 같은 상호운영 엔진을 제공하되, 다음과 같은 사실들은 어떤 조합으로도 참이 성립한다: 즉, (1) 상기 엔진은 다트 엔진을 포함한다; (2) 상기 상호운영 소프트웨어 패키지는 상호운영 소프트웨어 패키지를 포함하거나 다트 포맷을 따르는 다트를 포함한다; (3) 다른 상호운영 장치들을 발견하기 위한 수단은 모집 프로시져 또는 다트 모집 프로시져를 사용하여 적어도 부분적으로 수행된다.

또 다른 실시예(3)에 따르면, 본 발명은 실시예(1)에서와 같은 상호운영 엔진을 제공하되, 상기 엔진은 이벤트 큐(event queue)를 포함하고, 상호운영 애플리케이션 패키지들이 이벤트 큐를 사용하는 것을 지원하기 위하여 명령들을 수행한다.

ⅩⅥ. 상호운영 장치 활성화

상호운영 장치 활성화는 다트 엔진을 다트 플레이어의 일부로 이식함으로써 종래의 장치를 매우 상호운영적인 다트 장치로 변화시키는 과정이라는 것을 상기하라. 또한, 장치에 특유한 정보, 장치의 능력 및 컨텐츠에 접근하기 위해 필요한 하드웨어 추상화 레이어를 실행할 필요가 있다. 다트 플레이어를 구비한 장치가 다트 장치가 되기 전에 적어도 하나의 통신 프로토콜을 수행하여야 한다.

상호운영 장치 활성화에 추가적인 구체적인 실시예들을 후술한다. 또 다른 실시예(1)에 따르면, 본 발명은 상호운영 엔진이 장치를 상호운영 장치로 만들기 위해 필요한 상호운영 소프트웨어를 생성하기 위한 일반적인 소프트웨어 소스 코드를 사용하는 방법에 있어서, 상호운영 엔진 오브젝트(object) 또는 인스턴스(instance)를 생성하고(1); 장치 하드웨어 추상화 레이어(device Hardware Abstraction Layer: HAL) 오브젝트 또는 인스턴스를 생성하고(2); 할베이스 클래스 (halBase class) 또는 사양을 가지고 미리 정의되고 요구된 모든 할베이스 멤버 기능들의 기능성을 식별하고 채우고(3); 연속적인 실행에서 엔진을 실질적으로 계속 실행하는 장치에 특화된 플레이어 오브젝트를 생성(4)하는 것을 포함한다.

또 다른 실시예(2)에 따르면, 본 발명은 실시예(1)에서와 같은 방법을 제공하되, 실행의 맥락에서 엔진을 실질적으로 계속 실행하는 장치에 특화된 플레이어 오브젝트를 생성하는 것은 엔진을 다음과 같이 실행시킨다: 즉, 엔진의 초기화 기능을 호출하고(a); 리턴된 값이 복구 불가능한 에러가 발생했음을 나타내거나 엔진이 다운될 것이라는 사실을 나타내는 경우에 멈추는 루프에서 엔진의 프로세스 기능을 호출하고(b); 엔진의 비초기화 기능을 호출하고(c); 연속적인 실행을 중단한다.

ⅩⅦ. 상호운영 보안 모델/다트 보안

다트보안은 장치의 완결성 및 그 컨텐츠를 악성 또는 우연한 손상으로부터 보호하는데 필요한 기반구조을 제공하기 위한 시스템 및 방법이라는 것을 상기하라.

견고한 보안 기반구조는 장치 및 그 컨텐츠 또는 기능이 남용, 오염, 또는 손상되거나 기타 바람직하지 않은 방식으로 사용되는 것을 방지하는 기초로 사용되는 것이 바람직하다. 그러한 기반구조로는 도 29에 도시된 다트 플랫폼의 구성요소에 의해 바람직한 방식으로 구현된 본 발명의 다트 보안 시스템이 제공된다.

바람직한 실시예에 따르면, 다트 장치가 다트 플레이어를 처음으로 실행시킬 때, 다트 엔진의 초기화 과정의 일부는 다음과 같이 수행된다:

1.공공적이며 개인적인 암호키 쌍 및 고유 아이디를 생성하는데 적합한 충분한 엔트로피를 생성하여 생성된 키 쌍 및 고유 아이디들이 유사한 방식으로 생성되었으나 수집된 다른 엔트로피를 사용하여 생성된 키 쌍 및 아이디들로부터 진실로 고유하도록 통계적으로 보증한다.

엔트로피는 장치 외부의 계(world)의 측면들을 디지털 방식으로 샘플링함으로써 다트 장치들에 의해 신뢰성 있게 수집될 수 있다. 이때, 그러한 측면들은 샘플링 하드웨어를 실행하는 클럭(clock)에 어떤 방식으로든 동기화되지 않는다. 다른 장치들과 이야기하는데 사용되는 통신 메카니즘들은 종종 엔트로피의 좋은 소스인데, 왜냐하면 패킷들의 정확한 타이밍, 타임아웃(timeouts), 및 데이터의 변이들은 샘플링을 제어하는 프로세서의 클럭에 연관되지 않은 전자기적 간섭 및 양자 잡음에 의해 영향을 받기 때문이다. 엔트로피의 또 다른 손쉬운 소스는 장치가 사용자의 입력을 요구하기 위한 것이고, 사용자가 어떠한 입력을 제공할 때마다 세밀하게 그레인드된 (fine grained) 클럭을 샘플링하기 위한 것이다. 타이밍과 데이터 샘플들을 포함하는 엔트로피는 난수 발생기를 도입하는데 사용되는 데이터 값들로 이루어진 하나의 집합으로 제공될 수 있다. 충분한 엔트로피가 수집되는 시기를 아는 것은 현실적으로 어렵지만, 추정을 하는 것은 가능하고, 충부한 엔트로피가 수집된 데이터 값들에 제공되었고 유지되었다는 사실을 보증하기 위하여 과도 샘플링(over-sampling)이 사용될 수 있다.

2.종래의 난수 발생 알고리즘 및 종래의 암호화 동작들을 사용하여 모든 시간에 대하여 장치를 고유하게 식별하기 위해 사용되는 일반적으로 고유한 공공/개인 키 쌍 및 일반적으로 고유한 다트 장치 아이디를 생성한다. 바람직한 실시예에 따르면, 모든 아이디들은 128 비트의 길이를 갖는다.

3.데이터 값들로 이루어진 개인키 및 엔트로피가 수집된 집합은 장치상에 있는 데이터를 모호화하거나 및/또는 숨기지만 엔진이 데이터를 사용하는 것은 여전히 현실적으로 만드는 종래기술에 공지된 종래의 방식으로 장치상에 저장된다.

4.이진 플래그(flags) 집합에 기초하여 장치의 데이터, 컨텐츠 자원들, 또는 기능들(faciilities)에 대한 접근을 제한한다. 바람직한 실시예에 따르면, 장치의 기능에 대응하는 데이터에의 접근이 차단되는 경우에는 이러한 플래그들은 1로 설정된다. 예를 들어, 개별적인 플래그들은 다음과 같은 자원들에 대해서 존재한다:

a. 개인으로 표시된 데이터 또는 컨텐츠에 대한 접근을 차단하는 자원들.

b. 또 다른 장치에게 통신 세션들을 개방하는 것에 대한 접근을 차단하는 자원들.

c. 원래의 저장 장치들에 대한 접근을 차단하는 자원들.

d. 화면, 키보드, 마우스, 및 음향 발생장치와 같은 사용자 인터페이스 구성 요소에 대한 접근을 차단하는 자원들.

5.로드되어 다트 엔진 상에서 실행되는 모든 다트 또는 다트 프로시져는 다트 장치의 자원들에 대한 접근을 제어하는 플래그 값들의 집합들을 명시적 또는 암시적으로 구비한다. 모든 다트 장치는 보안 레벨에 매핑(mapped)되는 접근 플래그들 집합들을 명시적 또는 암시적으로 구비한다. 만약, 애플리케이션 또는 애플리케이션을 전송하는 장치에서 접근에 필요한 자원들에 대한 모든 플래그가 타겟 장치상에서 제로로 설정되지 않으면, 다트 애플리케이션 또는 다트 프로시져는 장치가 사용자 또는 수용가능한 증명(credential) 또는 다트 또는 다트 프로시져로 하여금 특정한 장치상에서 실행되도록 권한을 부여하는 다른 장치로부터 적절한 권한을 먼저 얻어내지 않는 한 로드될 수 없을 것이다. 다트, 다트 프로시져들, 또는 다트 장치들의 아이디에 결합된 접근 플래그들은 타겟 다트 장치 상에 영구적, 또는 소정 시간동안, 또는 다트 또는 다트 프로시져가 실행되는 동안, 또는 장치들간의 통신 세션 동안 유지될 수 있다.

6.만약, 다트 애플리케이션이 다트 엔진으로 하여금 애플리케이션의 컨텍스트 플래그들(context flag)이 1로 설정된 자원들 중 어느 하나에 접근하도록 시도하면, 다트 엔진은 즉각적으로 애플리케이션의 명령들을 수행하는 것을 중지하고 애플리케이션을 다운시킬 것이다.

바람직한 일실시예에 따르면, 다트는 접근을 위해서 설정된 플래그들과 더불어 반드시 디지털 방식으로 서명되어야 한다. 파트들 또는 컨텐츠 또는 장치들간의 통신 세션들의 암호화/해독 역시 다트 보안 시스템의 일부를 이룬다.

도 25는 보안 시스템 요소들의 일부를 구비한 다트 장치(400)을 도시한다. 다트 엔진은 명령들에 기반하고 있고, 암호화(150), 엔트로피 수집(153), 난수 발생(152)을 지원하고, 두개의 다트 장치들간의 통신을 보증하기 위하여 다트 보안 프로토콜을 사용하여 장치들간의 모든 통신을 확보하는 방법들은 자동적으로 암호화될 수 있으므로, 다트 엔진 기반 통신은 데이터 통신을 보호하기 위하여 어떠한 외부의 프로토콜에도 의존할 필요가 없다. 다트 보안 프로토콜(153)은 보안 소켓 레이어 (Secure Socket Layer: SSL) 프로토콜 또는 장치간의 보안 통신 링크를 rnc축하는 기타 다른 프로토콜을 사용하여 구현될 수 있다. 바람직한 실시예에 따르면, SSL 프로토콜 표준에서의 기능성의 부분집합은 SSL에 포함된 많은 옵션들이 필요하지 않음에 따라 크기와 복잡성을 감소시키도록 구현된다. 모든 필요한 큰 수를 사용하는 수학적 암호화의 원형들(150,151)이 다트 엔진의 일부로 도시된다. 실행상의 이유 때문에, 수학적 암호화 원형들을 다트 내부 대신에 엔진의 본래 코드로 구현하는 것이 바람직하다.

도 25는 또한 다트 엔진이 보안 레벨에 대응하는 아이디들(155, 156)의 목록을 유지하는 것을 도시한다. 도 25는 또한 레벨 번호들을 접근권 플래그들(159)의 집합들에 매핑시키는 표가 존재하는 것을 도시한다. 특정 레벨의 권리의 일부를 이루는 장치 및 애플리케이션 아이디들의 목록은 다트 엔진에 의해 유지되고, 바람직한 동작 모드에서는 어떤 장치든지 증명을 더 이상 수집할 필요없이 새로운 장치에 대한 접근을 획득할 수 있도록 장치 및 애플리케이션 아이디들의 목록이 장치에서 장치로 전달되도록 허가된 경우에 전달적으로 전파될 수 있다. 특정한 보안, 사회 보안 레벨에서의 장치 및 애플리케이션들을 전달적으로 팀구성 하는 것에 관해서는 본 문건의 다른 부분에서 좀 더 설명할 것이다.

플래그들을 제시하고, 검열을 통과시키고, 로드한 이후에도 다트 애플리케이션 또는 다트 프로시져가 의도적이든 우연적이든 제한 밖에 있는 자원들에 접근하지 못하도록 보증하기 위하여, 그러한 모든 시도된 접근들은 컨텍스트(context) 데이터 구조(160,170)을 사용하는 엔진에 의해 점검된다. 이때 상기 컨텍스트 데이터 구조는 다트 또는 다트 프로시져가 원래 제시한 모든 허가 플래그들을 지니고 있다.

취소 목록(155)은 본 문건의 다른 부분(사회동조:SocialSynchronization)에서 설명되는 바와 같이 전달적으로 유지될 수 있으므로, 다른 장치들과 이전에 특정한 보안 레벨의 팀으로 구성된 장치에 있어서 그 장치의 접근권은 그 팀에 속한 다른 장치의 취소를 전달적으로 알 수 있는 장치와의 상호운영에 따라 논리적으로 취소될 수 있다는 사실을 상기하라. 바람직한 일실시예에 따르면, 만약 취소된 장치가 그 취소를 알고 있는 팀에 속한 장치와 접촉하면 다트 엔진은 취소된 장치를 동작불능되게 하거나 부분적으로 동작불능 상태로 만들 것이다. 일반적인 접근권을 가지고 있는 상호운영 가능한 장치들로 이루어진 팀 전체에 걸쳐서 접근권을 취소하는 것는 완벽하지 않지만, 많은 경우에, 이것은 손실되거나, 오동작하거나, 악성인 장치의 접근권을 단속적으로 연결될 수 있는 장치들로 이루어진 팀 전체에 걸쳐서 취소하는 실제적인 시스템으로 역할한다.

접근권 또는 그에 대한 취소를 확산시키는 방법은 욕 잘하는 사람에 대하여 자신의 친구들에게 이야기하는 사람의 경우에 비유적으로 다음과 같이 설명할 수 있다. 욕 잘하는 사람에 대한 소문은 잡담처럼 사람에서 사람으로 확산되어 비록 그 욕 잘하는 사람에 대한 난폭함을 처음 안 사람과 직접 이야기해 보지 않고도 대부분의 사람들이 그 욕잘하는 사람에 대해 알게 되어 그로부터 떨어져 있을 수 있다.

접근 플래그 뿐만 아니라 다트 엔진 컨텍스트 역시 실행중인 다트 또는 다트 프로시져가 실행중인 다트의 일부가 아닌 메모리, 저장장치, 또는 코드에 접근하는 것을 제한하기 위해 엔진이 사용하는 정보를 포함한다. 이런 방식으로 접근을 제한하는 것은 종래기술에 "샌드 박스(sandbox)"로 알려져 있다. 다트 엔진은 다트가 샌드박스에서 실행되는 다트 및 다트 프로시져에 의해 사용되도록 명시적으로 제공된 기능들, 메모리, 및 저장 영역 밖에 존재하는 장치에 접근하는데 사용되지 않도록 모든 다트들 및 다트 프로시져들 상에 샌드박스를 강제한다.

다트들

본 발명의 바람직한 일실시예에 따르면, 종래에 코드, 운영체계, 그래픽 또는 사용자 입력 서브시스템, 및 스레딩(threading)으로 간주되는 것들 간에 또는 그 문제에 관해서는 컨텐츠, 프로그램, 또는 심지어 장치들 간에 분화된 것이 거의 없다. 다트 플랫폼(도 3)은 소프트웨어 프로시져들, 코드, 데이터, 컨텐츠, 및 장치 전자공학을 다트 설계자가 설계하고 다트 소트(100)(도 3)에 구체적으로 기재된 애플리케이션의 의도를 수행하는 통합 가상 시스템 안으로 지능적으로 혼합 및 매치시킬 수 있다.

다트 도구들에 의해 생성된 다트들은 자기-최적화를 할 수 있고, 프로그램, 제어, 하드웨어 자원들, 및 컨텐츠를 다양한 장치들 간 및 장치들에 걸쳐서 효율적으로 공유하기 위하여 그 자신의 버전(version) 또는 확장자(extension)를 인식, 전송, 및 동기화할 수 있다.

다트들은 어떤 갯수의 비유사한 장치들에서도 잘 실행될 뿐만 아니라 수많은 유사 또는 비유사한 장치들에 걸쳐서 동시적으로 잘 실행될 수 있는 통합 작업 애플리케이션을 구축하기 위해 필요한 모든 데이터, 컨텐츠, 및 프로시져들을 이용하여 생성된다.

또한, 단일한 다트의 런타임 환경은 또한 다른 다트들을 부모 다트(parent Dart) 또는 다른 다트의 아들 다트(child Dart)로서 동적 또는 통계적으로 포함할 수 있다. 그러므로, 다트 런타임 환경은 미지의 장치들 및 개별적으로 생성된 미지의 다트들에 걸쳐서 고유한 도달범위를 갖는다.

현재 채용된 상호운영 기술과는 달리, 다트 기술은 그러한 작업들에 제한되지 않지만, 인간 크기 데이터 및 영상 슬라이드 쇼, 일정 달력, 접촉, 제어 패널, 및 메시지와 같은 작업들에 최적화된다. 시스템의 반응속도는 동영상을 실행시키고, 버튼 누름에 응답하거나, 1/5초 내에 개인 접촉 목록에서 특정 접촉을 발견하도록 요구할 수 있을 만큼 충분히 빠르다. 인간에게 있어서, 그러한 반응속도는 즉각적인 것과 거의 구분되지 않는다. 다트 반응속도 요건은 대부분의 애플리케이션 환경에 기반한 대부분의 실시간 운영체계에 비하여 훨씬 너그러운 편인데, 왜냐하면 실시간 운영체계는 일반적으로 초당 수백개의 동작을 처리해야 하는 데이터 서 버들과 같은 애플리케이션들을 실행하도록 기대되기 때문이다. 다트는 인간의 시간 감각에 맞도록 응답하기만 하면 되기 때문에, 유리하게도 간단하고 매우 견고하고 탄력적이 계층 이벤트 처리 메카니즘들은 현재의 종래기술에 따른 상호운영 운영 체계 및 관련 런타임 환경에 채용된 우선적이거나 연동적인 연속 시스템들(threaded systems) 대신에 채용된다.

슬라이드 쇼 다트 애플리케이션을 예로 들어 살펴보자. 어떤 프로그래밍 언어도 사용될 수 있겠지만, 일실시예에 따르면, 슬라이드 쇼 다트는 C++ 프로그램 코드 언어로 다트 프레임 워크(102)(도 11)를 사용하여 작성될 수 있고, 또한 C++로 작성되어 다트 도구(200)(도 12)를 사용하여 컴파일 및 링크될 수 있다. C++ 소스 코드는 또한 모든 다트 프로시져들, 렌디션들, 및 다른 상호운영 확장자들을 포함하도록 생성될 수 있는 애플리케이션들을 확장하는 다트에 특유한 C++ 프래그마(pragma) 스테이트먼트들을 포함한다. 다트 프로시져들, 렌디션들, 및 다른 상호운영 확장자들은 다트 애플리케이션들이 다른 장치들을 발견하고 검사하고 그 자신들의 최적화된 사본들 또는 일부를 상기 검사에 기초하여 전송하고, 다트 애플리케이션들이 자신들의 최적화된 사본들 또는 일부가 선택되고 발견된 장치들 상에서 실행되도록 하고, 모든 관련된 장치들 상에서 이벤트 큐(event queue)를 통해 상호운영하도록 한다. 그러한 장치들은 다트(도 9)에 포함된 상호운영 가능한 애플리케이션의 의도를 표현하기 위하여 애플리케이션의 모든 구성요소들이 매우 연동적이고 견고한 방식으로 동작하도록 이벤트들이 자동적으로 직렬화 및/또는 동기화된 상태에서 이벤트에 기반하여 구동될 수 있다. 바람직한 실시예에 따르면, 단일한 매스터 렌디션(113)(도 11)에서 도출되는 오브젝트로 구성되는 다트 도구(200)(도 12)로부터 직접적으로 생성되는 다트 매스터(230)(도 12)는 실행의 시작점으로서의 주요 방법을 제공한다. 이러한 실행은 다른 렌디션에서 도출되는 오브젝트(114)(도 11)에 대한 참조를 포함하는 매스터 렌디션 오브젝트에 의해 유지되는 목록을 생성한다.

다트 매스터들은 프로그래머들에 의해 C++로 또는 다른 고급 언어로 다트 명령 세트를 목표로 삼는 도구들과 프레임워크를 사용하여 일반적으로 생성된다. 다트가 그 자신이 실행되는 것을 발견하는 장치들의 전 영역을 다루기 위해, 매스터 다트는 매스터 플레이어가 하나의 렌디션과 다섯개의 상이한 렌디션들 사이에 생성하기 위해 사용하는 컨텐츠 및 프로시져들을 일반적으로 포함하여 할 것이다.

논리적으로, 렌디션들은 별개의 프로그램들 또는 실행가능한 이미지들로 간주될 수 있고, 바람직한 실시예에 따르면, 렌디션들 중 오직 한개의 렌디션만이 한 장치 상에서 주어진 시간에 실행되도록 선택될 것이다.

물리적으로, 렌디션들은 종종 실제적인 다트 포맷 이진 이미지 또는 파일에 유리히게도 극히 최소화된 복제량이 존재하도록 데이터, 코드, 및 컨텐츠 구성요소의 대부분을 공유하는 것이 유리하다.

다트의 다트소스(100)(도 3)는 어떤 렌디션이 장치 상에서 가장 잘 실행될지를 결정하기 위하여 장치 상에서 실행될 프로시져들을 또한 포함해야 한다.

예를 들면, 그림들의 집합체를 포함하는 슬라이드 쇼 다트는 다음과 같은 세가지 렌디션들을 구비할 수 있다: (i) 단일 라인 또는 서너줄의 텍스트 디스플레이 만을 포함하는 장치들을 위한 간단한 텍스트 렌디션은 슬라이드 쇼의 명칭 및 포함된 슬라이드들의 명칭 목록 전체를 스크롤한다; (ii)소형 화면 렌디션은 그 자체로서 화면크기가 작고 CPU 전력이 제한되어 있는 휴대전화기 및 PDA에 적합할 수 있다; (iii) 다중 디스플레이 옵션들, 색인들, 및 전이효과를 구비한 대형 화면을 보여주는하이엔드급의 대형 화면 렌디션은 대형 화면 개인용 컴퓨터(PCs) 또는 가정용 오락 시스템 상에서 실행되는데 적합할 수 있다.

특히 유리한 동작 모드에 따르면, 다트를 포함하는 다중 렌디션들이 장치 상에서 먼저 실행되면, 다트 프로시져는 다트 명령 세트의 프로파일 명령을 사용하여 그 장치 상에 있는 다트 엔진 안에 생성된 장치 프로파일을 검사하여 그 장치가 가장 고급의 렌디션을 실행하는데 필요한 특징들을 모두 구비하고 있는지를 결정한다. 만약 그 장치가 가장 고급의 렌디션을 실행하는데 필요한 특징들을 모두 구비하고 있으면, 가장 고급한 렌디션이 실행될 것이다. 만약 그 장치가 가장 고급의 렌디션을 실행하는데 필요한 특징들을 모두 구비하고 있지 않으면, 장치 프로파일은 장치상에서 효과적으로 실행될 수 있는 렌디션이 발견될 때까지 각각의 덜 고급한 렌디션에 대해서 절차적으로 점검한다.

내장된 다트 엔진을 구비하지 않은 타겟 장치들은 타겟 장치에 대한 상세 지식 및 타겟 장치들로의 연결에 대해서 장치에 대한 다트 엔진의 동작들을 대리 및 가시화하는 능력으로 생성된 다트 엔진을 구비한 장치들을 통해 접근될 수 있다. 일례로, 다트 엔진 없이 프린터를 사용하는 것을 들 수 있다. 이때, 다트 엔진은 그럼에도 불구하고 개인용 컴퓨터를 통해 인쇄를 하고자 하는 장치에 의해 접근될 수 있다. 상기 개인용 컴퓨터는 그 자체로서 프로파일 명령(PROFILE_INSTRUCTION)을 통해 인쇄자원을 노출시키는 다트 엔진을 실행한다. 다트 엔진을 구비한 다른 초기화 엔진은 PC 상에서 실행되는 다트 엔진이 인쇄 능력을 노출시키는 한 PC에서 사용가능한 프린터들에 접근할 것이고 프로파일 및 PC 상에 있는 다트 엔진의 하드웨어 추상화 레이어(HAL) 오브젝트 인쇄방법을 통해 접근할 것이다.

다트가 그 자신을 또 다른 장치로 전송할 것을 요구받으면, 대부분의 다트들에 있는 사용자 옵션들 중 어느 하나는 타겟 장치 상에서 실행될 수 있는 것들에 전송되고 한정되는 렌디션들의 집합을 구비하게 될 것이다. 이러한 방식으로 사용자는 타겟 장치로의 전송시간을 한정할 수 있고, 타겟장치에 관한 메모리 요구사항들을 한정할 수 있다. 물론, 새로운 장치는 좀 더 많은 가능한 장치들에게 재전송하기 위하여 더 높은 수준의 렌디션들을 가질 것이다.

많은 량의 컨텐츠 및 상기 컨텐츠를 생성하고 편집하는 애플리케이션 프로그램들은 PC에 기반하거나 인터넷에 기반하기 때문에, 다트 컨텐츠가 현존하는 소프트웨어 시스템에서 사용될 수 있는 형태로 컨텐츠를 입력(import) 또는 출력(export)하는 것이 중요하다.

다트는 JPEG 영상에 대한 표준 포맷 데이터, 또는 생성가능한 다른 형태의 데이터 또는 컨텐츠 및 그와 같은 것를 포함하는 것이 유리하고, 메뉴 옵션들은 다양한 구성요소들을 결합하는 그림, 비디오, 텍스트, XML 문서들을 입력 및 출력할 다트 컨텐츠 내에 형성될 수 있다.

다트 명령세트는 선택적이지만 유리하게 CPU 집약적인 복원 작 업(decompressing tasks)이 다트 엔진의 일부가 다트 장치의 CPU의 고유 명령세트 안으로 컴파일된 효율적인 기능으로 구현될 수 있도록 JPEG 및 다른 표준 미디어 포맷 복원 및 재생 명령들을 포함한다. 이러한 명령들은 또한 다트 내에 반드시 포함되어야 할 코드의 분량을 제한하는데, 왜냐하면 다트 엔진은 다트 명령세트를 실행하는 일부로서 복원 및 디스플레이의 많은 부분을 수행하기 때문이다. 유사하게, 텍스트, RTF, XML, 및 다른 텍스트 기반 문서들을 분석(parsing)할 때 애플리케이션 코드의 분량을 제한하고 고유한 코드 속도에 따른 잇점들을 제공하기 위하여 XML 및 기타 다른 텍스트 분석(parsing) 명령들이 존재한다.

또한, PC 애플리케이션들은 제조사들에 의해 다트 컨텐츠를 직접 입력하거나 출력하도록 용이하게 적응될 수 있다. 다트들은 다른 애플리케이션들 및 다트들로 하여금 텍스트 명칭 및 파트들의 기술(descriptions)와 더불어 JPEG 그림 및 오디오 클립들과 같은 컨텐츠 부분들을 프로그램적으로 열거하고 추출하도록 하는 컨텐츠 접근 API들 및 제어 API들을 포함할 수 있다.

API 기능들의 텍스트 기술(description)과 더불어 다트 제어 API들 또한 열거되고 접근되어 다른 다트들 또는 다트들 및 다트들이 작동시키는 장치들을 원격 제어하도록 하는 장치들로부터 다트 자신들의 동작을 제어할 수 있다.

다트 엔진을 장치로 이식( porting )하기 위한 과정에 대한 실시예

다트 엔진을 새로운 장치에 이식하기 위한 절차를 후술한다. 후술하는 예제는 다트 엔진이 C++ 코드 다트 엔진이라는 가정을 하고 있지만 그러한 가정을 한다고 해서 상기 과정의 일반성으로부터 벗어나는 것은 아니다.

우선, 할베이스 오브젝트로부터 상속받거나 직접적으로 생성하는 것과 같은 기타 다른 방식을 통해 사용자 자신의 하드웨어 추상화 레이어(3020(도 4), 650(도 22), 650(도 27)) 오브젝트를 생성한다.

둘째, 할베이스 부재 기능의 기능성을 채운다. 할베이스 부재 기능은 주어진 크기를 가진 메모리에 속한 연속적인 단일 블록을 할당하는 기능, 밀리 초(miliseconds) 후에 시간을 리턴하는 기능, 및 비트맵을 세가지 표준 인터넷 포맷들중 어느 하나로 이동시키는 기능을 포함한다. 또한, 시간 변수들을 주어진 위치에서 화면에 컴파일한다. 할베이스 클래스는 또한 다트 엔진 상에서 실행되는 다트들로 하여금 실제 장치의 CPU, 메모리, 화면, 통신, 사운드, 인쇄, 및 기타 특징들을 결정할 수 있도록 하는 프로파일 정보 단어들을 획득하기 위한 가상의 기능을 포함한다. 그렇지 않았더라면 기본 할베이스 클래스의 순수 가상 방법에 의해서는 노출되지 않았을 장치의 고유한 능력들, 컨텐츠, 또는 기능성을 노출시키기 위하여 할베이스 오브젝트의 OEM_Function 방법을 사용하여 프로그램적인 인터페이스를 설계하고 생성하는 것은 특히 이로운 일이다.

세째, 플레이어베이스 오브젝트로부터 상속 받음으로써 장치에 특유한 다트 엔진 오브젝트(600)(도 22)을 생성하거나, 상속에 의하지 않고 직접 생성한다.

네째, 장치의 실행가능한 다트 플레이어(600)(도 22)를 생성한다. 상기 실행가능한 다트 플레이어는 다트 엔진 오브젝트를 채용하고, 상기 다트 엔진 오브젝트는 영이 아닌 값과 같은 소정의 조건이 리턴될 때까지 다트 엔진이 프로세스() 부재 기능(예를 들면, 플레이어 베이스::프로세스() 부재기능(4003)(도 23)(611)(도 25)을 호출하는 루프를 포함한다. 통신을 포함하는 다트 플레이어의 모든 동기적인 작동(8010)(도 15) 및 비동기적인 작동(비동기적 이벤트 처리과정은 점선으로 표시된 박스 안에 도시되어 있다)은 멀티 스레드 OS가 필요하지 않도록 이러한 간단한 루프의 실행 스레드(thread)에 의해 구동될 수 있다.

장치 상호운영에 대한 다트 솔루션은 적응과 시험 복잡성 방정식을 N 제곱 방정식(도 1 및 도 2)에서 N 차 방정식으로 유리하게 변화시킨다. 새로운 장치가 어떻게 모든 다른 종류의 비유사한 장치와 컨텐츠를 공유하고 그러한 장치와 제어를 수행하고 개별적인 솔루션들을 실행할 것인지를 생각하는 대신, 사용자는 다트를 사용하여 다트 엔진을 장치에 특유한 다트 플레이어 내에 이식하기만 하면 된다 (도 10).

사용자는 장치가 구비하는 모든 통신 채널들을 이해하는 기능들을 실행하고 CPU 속도, 화면 크기 등을 보고하기 위한 루틴들을 생성할 필요가 있으나, 장치가 어떻게 컨텐츠와 제어를 공유할지에 대해서는 고려하지 않아도 된다. 다트 컨텐츠가 장치에 내장된 소프트웨어 대신 그러한 것들에 대해 고려한다.

이러한 이식은 N 제곱이 솔루션이 아닌 다룰 수 있는 N 차 솔루션을 제공하고, 다트 플레이어를 이식하는 것은 각각의 새로운 장치에 대해서 단지 한번 수행하면 되고, 각각의 새로운 장치 또는 애플리케이션이 단지 하나의 추가적인 작업 단위만을 요구하도록 각각의 새로운 애플리케이션에 대해 다트를 한번 개발하면 된다는 사실은 높이 평가될 것이다.

다트 플레이어에 대한 실시예

예를 들어 C++ 언어로 구현되고 종래의 프로그래밍 도구를 사용하거나 CPU가 따르는 다른 실시예에 따라 다트 장치의 프로세서의 고유한 명령 세트로 컴파일된 다트 플레이어(500)(도 22)의 일 실시예가 후술된다.

다트 플레이어 클래스가 상속받은 플레이어 베이스 클래스는 파라미터를 가진 일련의 조작부호들(opcodes)인 다트 프로그램들을 실행한다. 기본적으로, 다트 플레이어는 마이크로 프로세서로 설명될 수 있고, 다트 명령세트는 기계 명령들의 집합을 이용하여 설명될 수 있다; 그러나, 다트의 경우에는 대부분의 명령들이 전형적인 마이크로 프로세서에서보다 훨씬 높은 수준의 언어로 되어 있다. 다트 플레이어에 고유한 명령들은 예를 들면 JPEG 영상들을 버퍼 안에 복원하고, 버퍼들에 저장되어 있는 영상들을 올바른 포맷으로 물리적인 화면 상의 특정 위치로 이동시키고, 실행중인 DART의 전체 상태 및 그에 대한 모든 코드 및 데이터를 저장하는 단일한 명령들을 포함한다. 또한, 완전한 2D 그래픽 원형들, 고급 사용자 입력 처리, 및 오디오 복원 처리 명령들은 다트 명령 세트 내에 생성되는 것이 유리하다.

다트가: (i)그 자신을 전송하고, (ii) 그 자신의 최적화된 버전을 전송하거나, (iii) 제어 패널을 요구하거나, (iv) DART 프로시져를 요구하거나, (v) 또 다른 장치로부터 데이터를 요구하면, 다트는 열거 명령을 사용하거나, 내장 명령을 사용하여 열거 이벤트를 이벤트 큐 상에 놓는다. 열거 명령 또는 열거 이벤트는 플레이어로 하여금 연결할 수 있는 각각의 다트 장치의 명칭과 표현형(description)을 획득하는 할베이스 열거 멤버 기능을 호출하도록 한다. 선택적으로, 다트 프로시져는 각각의 그러한 장치에 전송될 수 있고, 그러한 장치는 프로시져를 실행하 고, 다트 프로시져 자체는 원래 장치 상에 실행되는 프로시져를 리턴한다. 그러므로, 일반적인 처리, 수학, 시험과 협력하는 열거 명령들과 제어 명령들은 연결된 장치를 효과적으로 검사하는데 사용되어 장치가 원하는 기능들의 집합을 수행할 수 있는지, 코드, 데이터 또는 사용 또는 흥미로운 컨텐츠를 포함하고 있는지를 알 수 있다.

다른 장치에 전송되고 다시 수신된 다트 프로시져들 또는 다트들의 기능은 어떤 것이든 수행하기 위한 코드를 포함할 수 있기 때문에, 이러한 기능성은 넓은 범위의 장치간 협력 작업을 위해 필요하다. 대부분의 경우에, 다른 장치에 연결을 수행할 때 어떤 종류의 물리적 연결들, 프로토콜들, 보안 조치들, 설계 선택을 택할 것인지를 결정하는 것은 플레이어를 장치에 이식시키는 사용자 또는 프로그래머에게 달려 있다. 특히 이로운 일실시예에 따르면, 다트 플레이어는 수신된 어떤 통신 블록도 에러가 보정되어 있고 이식하는 프로그래머가 할베이스 가상 기능 안에 생성시킨 어떤 보안 요건들도 이미 통과했다는 것을 가정한다. 장치에 특유한 HAL 기능들에서 그러한 블록들을 하위 레벨에서 전송하고 수신하는 것은 별도로, 보안 통신 세션들을 설정하고, 관련 데이터, 코드, 및 컨텐츠를 가진 이벤트들을 전송하고, 전송시 손실된 블록들을 자동적으로 요구 및 처리하고, 장치간에 잠정적으로 손실된 세션들을 자동적으로 복구하는 기능성은 다트 엔진의 휴대 코드 부분들에서 모두 수행된다. 이렇게 함으로써, 다트 장치 상에 있는 다양한 통신 프로토콜들을 지원하기 위해 필요한 작업의 분량이 감소되고, 장치간의 실시 신뢰성이 크게 향상되는데, 왜냐하면 다트 엔진의 휴대 가능한 부분들을 이식하기 위해 동일한 소스 코드 베이스가 사용되기 때문이다.

물리적 발견을 위해 다트 명령 세트를 사용하는 것에 대한 실시예

실시예에 따르면, 다트 명령 세트는 주로 장치, 서비스, 및 자원발견 및 장치간 통신을 매우 높은 수준의 기능성에서 다루는 것이 바람직하다. 몇몇 실시예에 따르면, 다트 명령 세트는 장치, 서비스, 및 자원발견 및 장치간 통신을 매우 높은 수준의 기능성에서 독점적으로 다룬다. 실행중인 다트가 통신 속도, 잠재성과 같은 실제 통신 특징들을 결정하기 위해 장치 프로파일을 검사하는 동안, 일반적으로 유리하게도 실행중인 다트는 장치간의 실제 통신이 HTTP, TCP IP, USB, 802.11b, 또는 다른 프로토콜인지, 또는 공유된 메모리 카드, 물리적으로 전달된 메모리 카드, 또는 기타 다른 물리적 매체 또는 프로토콜인지 여부를 신경쓰거나 알 필요가 없다.

비슷한 방식으로, 다른 장치들, 서비스들, 또는 자원들 또는 인증 및 보안을 발견하는 것은 포트를 구체화하고 구현하는 사람에 의해 할베이스 오버라이드(override) 기능들 안에 형성될 수 있다.

그러한 포트를 형성하기 위한 한가지 유리한 방법은 사용자 편집가능한 "호의적인" 장치 목록을 플레이어베이스에 기반한 다트 플레이어의 일부로서 생성하는 것이다. 이런 식으로 사용자는 인터넷 프로토콜(IP) 주소 및/또는 네트워크 명칭 및/또는 장치로 하여금 그렇지 않았으면 발견할 수 없었거나, 발견하기 어렵거나, 다른 수많은 네트워크 상의 장치들 중에서 다른 수단을 통해서는 정확하게 지적할 수 없는 원하는 모든 장치에 접근할 수 있게 하는 패스워드들을 지정할 수 있다.

본 발명의 실시예들은 유니코드(Unicode) 또는 멀티 바이트와 같은 어떠한 문자 표시 시스템도 유리하게 수용하기 위하여 다트 프로시져들에 의해 내부에서 특별히 처리되지 않고 모든 다트 플랫폼 문자들이 32 비트가 되도록 유리하게 구성될 수 있다. 특정 장치의 고유 능력들과 매치시키기 위해 이러한 32 비트 문자들을 주고 받는 것은 오브젝트를 구현하는 할베이스로부터 유도된 HAL에 달려있다. 그러나, 본 발명은 어떠한 특정한 비트 워드 크기에도 제한되지 않고, 그 보다 크거나 작은 비트 워드 크기들도 사용될 수 있다.

장치, 자원 및/또는 서비스 발견을 다루기 원하는 장치들은 적절한 표준들을 따라야 한다. 다트 열거 명령 인터페이스 또는 단일 이벤트 내장 명령(670)(도 20) 처리는 유리하게도 다트 애플리케이션들에 대한 다양한 장치 발견 표준들 간의 차이점들을 숨기는 한편, 도우미 기능들(helper functions)은 하드웨어 추상화 레이어에서 사용되도록 제공되어 IP, 적외선(IR), 블루투스(Bluetooth), 802.11x, 및 기타 연결되거나 연결될 수 있는 장치들 또는 시스템들을 위해 호환가능한 지원을 형성하는데 도움을 줄 수 있다.

적어도 하나의 예시적인 다트 플랫폼 상에 컨텐츠, 데이터, 및 프로시져들을 대부분 채용하는 것은 엔진 안에 형성되는 대신 다트에 의해 유리하게 수행된다. 어떤 렌디션이 타겟 장치 상에서 가장 잘 실행될 수 있는지를 결정하는 것은 다트 그 자신이다. 연결된 다트 장치들에 대해서 컨텐츠 재생을 적응시키는 것은 다트에 포함되어 있는 프로시져들이다.

유리하게도, 다트 플랫폼을 사용하면, 새로운 장치가 함께 동작할 필요가 있는 모든 애플리케이션 및 다른 장치에 대해서 계획을 세울 필요가 없는데, 왜냐하면 장치 간의 프로토콜은 매우 단순하면서도 강력하기 때문이다. 하나의 다트 장치는 타겟 다트 장치에서 자동으로 실행되는 다른 다트 장치에 대하여 다트 프로시져를 전송한 다음 원래 장치 상에서 자동으로 실행되거나 처리되는 이벤트 또는 프로시져를 리턴한다. 다트 장치들은 자신들이 실행하고 있는 프로시져들 또는 다트들이 데이터, 애플리케이션, 제어 패널 또는 단지 검사 능력들을 전달하고 있는지를 알 필요가 없다.

적어도 하나의 특히 유리한 실시예에 따르면, 다트 플랫폼은 장치간 상호운영의 클라이언트/서버 또는 피어-피어(Peer-to-Peer) 모드들을 사용하지 않는다. 대신에 다트 플랫폼은 모집 모델을 사용하는 것이 유리하다.

모집 및 모집 모델 및 방법은 다트 애플리케이션들로 하여금 복수개의 상이한 연결들 및 장치들에 걸쳐서 자동적으로 자신들의 도달영역 또는 접속성을 확장할 수 있도록 한다. 모집은 클라이언트/서버 또는 피어-피어 접속성 또는 통신으로부터 방사상으로 출발하고 다트 플랫폼에 고유하고 매우 바람직한 특징들을 부여한다.

모집 모델의 실시예에 따르면, 다트 애플리케이션들은 사람들이 작업을 수행하기 위하여 팀을 형성하는 것과 같은 방식으로 애플리케이션 주변에 장치들의 팀들을 구성할 수 있다. 만약 어떤 사람이 집을 짓고자 하는 건설 계약자라면, 그는 건설 작업에 필요한 기술과 자원을 가진 목수들과 재목 공급자들를 배치시킬 것이다. 그런 다음, 그는 재목 공급자들 및 목수들과 팀을 이루어 일하고 재목을 목수 들에게 공급하고 집의 건설을 처음 시작한 자신의 의도에 따라 집의 건설을 지휘할 것이다. 이와 유사하게, 다트 애플리케이션은 타켓 장치들 상에서 자동적으로 실행되도록 하는 프로시져들을 전송함으로써 현존하는 통신 매체를 통해 통신할 수 있는 모든 다트 장치들의 자원들에 도달하고 자원들을 검사할 수 있다. 실행중인 다트는 그 자신이 다트 장치들을 발견하고, 자격을 부여하고, 팀을 형성하고, 사용자의 애플리케이션에 영향을 주기 위해 팀 내에 있는 각각의 다트 장치에게 필요한 컨텐츠 및 코드를 전송한다. 장치 사용자의 간여는 필요치 않다.

다트들은 모집된 다트 장치들 전체에 걸쳐서 자신들의 작동을 확장시키고 모든 다트 장치들 내부에서 효과적으로 동시에 실행된다. 결과적으로, 유리하게는 클라이언트/서버 구성 또는 작동의 경우에서처럼 어떠한 중앙 제어 장치도 필요로 하지 않는 시스템이 마련된다. 유리하게도, 다트 시스템은 시발 장치(originating device)을 제외한 어느 장치에도 존재하기 위해 시발 다트(originating Dart)의 임무에 관련된 프로그램들을 필요로 하지 않는다. 이는 피어-피어 구성 및 작동과는 반대되는 것이다. 또한, 장치 사용자는 미디어 포맷들, 통신 프로토콜들, 로딩 드라이버들에 대해서는 고려할 필요가 없다. 모집 모델은 또한 또 다른 다트 장치가 팀 안으로 모집될 때마다 다트 애플리케이션들 및 데이터가 다트 장치에서 다트 장치로 확산되게 한다. 그러므로, 유리하게도, 애플리케이션들 또는 그에 관련된 데이터를 사용하거나, 애플리케이션들 또는 그에 관련된 데이터를 명시적으로 로딩 또는 저장하기 않아도 다트들 및 그 안에 포함된 컨텐츠, 프로그램들, 데이터는 분배될 수 있다. 보안은 종종 악성이거나 오동작하는 다트들 또는 기타 코드 및 데이 터의 확산을 방지하기 위한 다트 플랫폼의 필요부분일 수 있다. 이러한 보안은 부분적으로는 잠재적인 모집 장치를 필요로 하는 형태로 구성되어 다른 장치들과의 통신을 허가하지 않거나 다른 장치들로부터의 프로시져들 또는 다트들을 실행하는 것을 단순히 거절함으로써 모집을 수용 또는 거절한다.

특히 유리한 일실시예에 따르면, 모집 모델 및 방법은 다트 명령 세트에 기반하고 있다. 프로시져들은 장치 상호운영, 멀티미디어 사용자 인터페이스, 및 모집 모델 및 방법의 사용에 최적화되어 있는 다트 명령 세트을 사용하여 표현된다.

유리하게도, 대부분의 고급 언어는 다트 명령 세트를 목표로 컴파일 될 수 있다. 이러한 경우 특히 유리한 일실시예에 따르면, 사용되는 고급언어는 C++ 프래그마 기능을 통해 추가된 확장성들을 구비한 C++이다. 이러한 장점들은 C++ 프로그래밍 언어가 현재 널리 사용되고 있는 것에 기인하지만, 본 발명은 어느 특정한 언어로 한정되지 않으며 현존하거나 미래에 개발된 다른 언어들로 동일하게 또는 더 잘, 예를 들면 C++ 프로그래밍 언어로의 개선들, 향상들, 및/또는 확장성들을 통해 구현될 수 있다.

상호운영 보안 모델에 대한 추가적인 특정 실시예들, 또는 좀 더 구체적인 실시예에 따른 다트 보안 모델을 후술한다. 일실시예(1)에 따르면, 본 발명은 상호운영 애플리케이션 패키지의 자원들 또는 능력들 및/또는 상호운영 장치들에 대한 자원들 또는 능력들에 대한 접근 및/또는 이해를 제한하기 위한 방법에 있어서, (1) 다음와 같은 적어도 복수개의 단계들을 사용하는 보안 기초를 형성하고, 상기 복수개의 단계들은:(a) 장치와 관련된 엔트로피 상태 측정값을 자동적으로 수집하 는 단계; (b) 키쌍을 생성하는 단계; (c) 장치 아이디를 생성하는 단계; 및 (d) 장치가 활성화될 때마다 계속적인 사용을 위하여 키쌍들, 장치 아이디, 엔트로피 상태 측정값을 장치상에 저장하는 단계를 포함하고; (2) 제한된 접근을 허가하거나 방지하기 위한 규칙들을 형성하고; (3) 형성된 기초 및 형성된 규칙들을 사용하여 적어도 장치에 대해서 보안 작업을 제공하는 것을 포함한다.

또 다른 실시예(2)에 따르면, 본 발명은 상호운영 애플리케이션 패키지의 자원들 또는 능력들 및/또는 상호운영 장치들에 대한 자원들 또는 능력들에 대한 접근 및/또는 이해를 제한하기 위한 방법에 있어서, (1) 장치가 처음 작동을 시작할 때 다음의 단계들 중 적어도 어느 한 단계에서 보안의 기초를 형성하고, 상기 단계들은: (a) 엔트로피를 자동적으로 수집하는 단계; (b) 공공/개인 키쌍을 생성하는 단계; (c) 고유한 장치 아이디를 생성하는 단계; (d) 장치가 활성화될 때마다 계속적인 사용을 위하여 공공 및 개인 키쌍들, 장치 고유 아이디, 난수 발생기에 대한 엔트로피 상태를 장치 상에 저장하는 단계를 포함하고; (3) 다음의 보안 작업들 중 하나 이상을 위하여 형성된 기초를 사용하고, 상기 보안 작업들은: (a) 장치들, 애플리케이션들 및 자원들로의 접근에 대한 규칙을 집행하는 작업; (b) 인증되지 않는 사용자 또는 에이전트에 의해 변경되지 않도록 상기 규칙 자체에 대해 보안을 유지하는 작업; (c) 공공 및 개인 키쌍들, 장치의 고유한 아이디, 난수 발생기에 대한 엔트로피 상태의 저장에 대해 보안을 유지하는 작업: (d) 애플리케이션들 및 장치들간에 공유될 작동 파라미터들 또는 데이터를 확보하는 작업; (e)통신 채널을 확보하는 작업; (f) 특정한 장치 또는 장치들의 집합 및/또는 특정한 애플리케이션 또는 애플리케이션들의 집합에 의해서만 이해되거나 사용 및/또는 공유된 비밀을 사용하여 접근될 때만 이해되거나 사용될 수 있도록 자원들을 암호화하는 작업; 및 (g) 일반적으로 고유한 아이디들을 생성하고 모든 장치들 및/또는 애플리케이션들 및/또는 데이터 세트 또는 항목들에 대해서 유효한 장치들, 애플리케이션들, 데이터 포맷들, 집합체들(collections), 기록들, 개별적인 미디어 파일들, 또는 심지어 개별적인 데이터 항목들을 항시적으로 식별하기 위하여 생성된 아이디들을 사용하는 작업을 포함한다.

또 다른 실시예(3)에 따르면, 본 발명은 접근을 제한하기 위하여 사용된 규칙들을 취소하거나 변경하는 것을 더 포함하는 것을 특징으로 하는 상호운영 애플리케이션 패키지의 자원들 또는 능력들 및/또는 상호운영 장치들에 대한 자원들 또는 능력들에 대한 접근 및/또는 이해를 제한하기 위한 방법을 제공한다.

또 다른 실시예(4)에 따르면, 본 발명은 상기 자원들에 대한 접근 및/또는 이해를 제한하는 것은 다음과 같은 단계들의 어떠한 조합들 중 하나 이상의 단계들을 포함하고, 상기 단계들은: (1) 장치들로 하여금 서로 통신 및/또는 어떠한 목적으로 장치들이 통신하도록 허락하는지에 대한 규칙들을 집행하는 단계; (2) 데이터에 접근할 수도 있는 다른 장치들이 데이터를 이해하거나 사용할 수 없도록 장치들 간을 흐르는 데이터를 암호화하는 단계; (3) 데이터, 컨텐츠, 또는 다른 자원들의 패키지에 서명하여 서명이 이루어진 이후에는 패키지가 변경되지 않도록 보증하는 단계; (4) 디지털 권을 관리하여 다음과 같은 액션들 중 하나 이상에 대하여 데이터, 코드, 컨텐츠, 또는 기타 다른 디지털로 나타낼 수 있는 자원들을 취급하기 위 한 일련의 규칙들을 집행하는 단계를 포함하고, 상기 액션들은 공유, 복제, 인쇄, 디스플레이, 실행(performing), 분배, 재생, 렌더링, 실행(executing), 변경, 또는 이러한 것들의 조합을 포함한다.

ⅩⅧ. 사회 동기화 상호운영 방법/다트 사회 동기화

데이터 세트 또는 작동들을 복수개의 장치들에 대해서 동기화하는 것은 다른 모든 장치들이 직접적으로 자신들의 데이터 세트를 동기시키는 단일한 매스터 장치가 존재하는 것을 가정하는 전통적인 방법들에 의해 매우 자주 행해진다. 이러한 방법들은 훈련된 전문가들이 관리하고 유지보수하는 신뢰성 있는 고속의 네트워크들을 사용하여 서로 항시적으로 연결되는 일반적인 컴퓨터들로 구성되는 공사나 정부의 네트워크에 매우 견고한 동기화 시스템을 제공한다. 이동 전화기들, PDA들, 디지탈 카메라들과 같은 개인들의 장치들에 있어서의 대부분의 현재 동기화는 매스터 컴퓨터가 개인용 컴퓨터이거나 인터넷에 연결된 서버인 단일 매스터 장치 방법론에 촛점이 맞춰진 동일한 방식을 사용하여 현재 통상 수행되고 있다. 그러나, 단일한 매스터에 대하여 동기화해야 하는 것은 단속적으로 연결되며 많은 경우에 이동 장치들의 계(world)에 대해서는 다음과 같은 이유들에 비추어 매우 제한적이고, 상기 이유들은:

1.모든 장치들은 매스터 장치와 적어도 하나의 통신 프로토콜을 공유해야 한다.

2. 몇몇 이동 장치들은 매스터 장치에 매우 근접하는 경우에만 동기화할 수 있는데, 왜냐하면 상기 이동 장치들은 매스터 장치와 데이터 세트를 동기화하기에 적합한 제한된 범위의 유선 또는 무선을 통한 직접 연결을 구비하고 있기 때문이다.

3. 매스터 장치는 모든 장치들에 대해서 단일한 실패 소스를 제공한다.

4. 훈련받지 않은 개별적인 사용자는 장치에 특유한 동기화 소프트웨어를 매스터 장치에 로드시키는 것에 대해 주의를 기울여야 하고 이러한 소프트웨어를 구성하고 유지보수해야 한다.

5. 이동 장치들은 서로 매우 근접해 있고 공통의 통신 프로토콜을 공유하고 있는 경우에도 서로 직접적으로 동기화를 수행할 용이한 방법이 없다.

본 발명에 따른 사회 동기화는 종래기술에서 일반적으로 사용되는 기존의 매스터 장치를 이용하는 동기화 방법에 비해 많은 혜택들을 제공하는 다트 장치들을 동기화하기 위해 사용될 수 있는 방법들의 특유한 주제이다. 사회 동기화는 모든 장치가 매스터 장치에 접촉하지 않거나, 어느 한 장치를 매스터 장치로 작동하게 할 필요 없이 임의의 갯수의 장치들과 프로토콜들에 대해서 구체적인 데이터 세트들 또는 작동들을 동기화하기 위한 효율적이고 관리하기 쉬운 방법이라는 것을 상기하라. 장치들 및 컨텐츠의 사회 동기화는 인간이 정보와 작업들을 공유하는 방법과 유사하고 종래기술에서 가장 빈번하게 사용되는 매스터 장치를 사용하는 동기화 기법에 대한 유리한 대안이다.

본 발명에 따른 시스템 및 방법이 종래기술에서 일반적으로 사용되는 기존의 매스터 장치를 사용하는 동기화 방법들에 대해서 가지는 혜택들과 장점들은 다음과 같다. 즉:

1.동기화는 모든 장치들이 단일한 매스터와 직접적으로 통신할 필요가 없는 장치들의 팀들에 대해서 수행될 수 있다; 또한 동기화는 임의의 수의 장치들이 서로간에 통신을 수행하는 경로가 존재하는 한, 그리고 그러한 경로들이 동시에 구축될 필요가 없는 한 수행될 수 있다.

2.이동 장치들은 매스터 장치에 직접 연결될 수 있을 필요가 없다; 오히려 이동 장치들은 동기화를 위해 구축된 장치들의 팀에 속한 이동 장치들 중 어느 하나에 직접 연결될 수 있을 필요가 있을 뿐이다.

3.매스터 장치가 없으므로 단일한 실패 소스도 없다. 팀에 속한 고장난 장치들은 새로운 장치들로 교체될 수 있고, 교체된 새로운 장치들은 팀 내에 있는 다른 장치들과 쉽게 동기화될 수 있다.

4.장치들 중 어느 한 장치에도 장치에 특유한 소프트웨어를 설치하거나 그러한 소프트웨어를 적극적으로 유지보수 또는 구성할 필요가 없다; 오히려, 동기화 팀에 속한 어느 한 장치도 임의의 다른 장치를 팀에 직접적으로 추가할 수 있다.

5.장치들은 장치간의 임의의 연결 순서를 통한 연결 경로가 존재하고 심지어 그러한 연결들이 동시적으로 유효하지 않은 팀에 속한 어떤 다른 장치들과도 직접 동기화할 수 있다.

사회 동기화는 자신들이 우연히 만나는 다른 사람들과 정보를 공유한 다음 또 다른 사람들과 같은 정보를 공유하는 사람들의 팀과 어느 정도 유사하게 작동한다. 인간에 대한 유추설명은 매스터 장치를 사용하는 동기화가 지닌 한계점들을 설명하는데도 또한 사용될 수 있다. 한 사람의 상사에게 이야기하는 것을 제외하고는 동료들의 모든 활동과 신입사원들에 대한 정보를 공유할 방법이 없는 많은 수의 직원들을 거느린 회사를 생각해 보자. 단 한 사람의 상사를 통하거나 고정된 상사들의 계층들을 통하는 것이 공유할 필요가 있는 모든 지식들에 대해서 현실적이기 위해서 모든 필요한 정보를 분배하기 위해서 너무 많은 상호운영이 필요하다. 개개의 직원들은 자신들이 우연히 만나는 사람들과 직접적으로 공통의 관심사에 대한 정보를 공유하면 되고 그러한 정보가 매개자들을 통해 그 정보를 알 필요가 있는 다른 사람들에게 전달되기를 기대할 것이다. 실제에 있어서, 이러한 사회 동기화 방법들은 완벽하지는 않지만 인간 간에 또는 장치간에 발생하고 진행 진행중인 단속적이고 규칙적이지 않을 가능성이 있는 임의 갯수의 연결들이 존재하는 인간 또는 장치들의 집단 또는 팀 내에 정보를 분배시키는 매우 효과적인 방법들이다.

도 30은 본 발명의 바람직한 일실시예에 따른 사회 동기화가 수행되는 방식의 일예를 도시한다. 상기 예에 따르면, 간단한 접촉 목록에 발생된 간단한 변화들에 대한 동기화가 도시되어 있지만, 상기 동기화는 복잡한 데이터베이스에 대해서 수행될 수 있고 상기 동기화는 단지 데이터 뿐만 아니라 다트 장치들 및/또는 다트들로 구성된 팀의 작동들 또는 작동들의 결과들에 대해서 수행될 수 있다는 점은 높이 평가되어야 한다.

도 30의 예에 따르면, 초기에 두개의 입력 명칭들을 포함하고 있는 접촉 목록 다트 애플리케이션을 구비하는 초기화 장치 A가 존재한다. 두개의 장치들 B 및 C는 장치 A 상에서 실행되는 접촉 목록 다트의 존재 또는 특징들에 대한 지식을 초기에는 가지고 있지 않다. 바람직한 일실시예에 따르면, 장치 A 상에서 실행중인 접촉 목록 다트는 접촉 목록을 포함하고 제어하는 접촉 목록 다트를 공유할 수 있는 모든 장치들을 열거한다. 상기 접촉 목록 다트는 다트 리쿠르트 방법을 사용하고 렌디션닝 방법을 선택적으로 사용한다. 장치 B의 장치 A 상에 있는 접촉 목록 다트에 의한 모집은 사용자가 "다른 장치로의 팀" 메뉴 항목을 선택함으로써 시작된다. 그런 다음, 사용자는 도달가능한 장치들 상에서 실행되도록 전송된 하나 이상의 다트 프로시져들 또는 다트들에 의해 결정된 접촉 목록의 팀을 구성하기 위하여 현재 도달가능하고 적합한 장치들의 목록을 제공받고, 모집되기에 적합한지에 대한 정보를 리턴한다. 사용자는 컨텐츠 목록 구성요소들을 이루는 하나 이상 또는 모든 렌디션들 및 데이터를 포함하는 다트를 저장하고 있는 접촉 목록 다트로 귀결되는 목록에서 장치 B를 선택한다. 이렇게 저장된 다트는 실행 다트 타입 이벤트의 일부로서 장치 B에 전송된다. 다트가 장치 B 상에서 실행되면, 다트는 심지어 장치가 장치 A에서 연결해제되거나 전원이 꺼진 이후에도 장치 B 상에서 사용 가능하도록 그 자신을 저장한다. 두 장치 모두에 걸쳐서 실행중인 다트는 아직 아무것도 존재하지 않는 경우에도 각각의 장치에 있는 사회 동기화 아이디 목록에 등록된다. 상기 등록은 접촉 명칭들로 구성된 이러한 특정한 목록을 초기에 생성할 때 다트에 의해서 생성되었으며 공유될 두 명칭들을 포함하는 접촉 목록의 아이디를 포함한다. 아이디들은 본 문건의 다른 부분에 설명되어 있는 다트 보안 기반구조를 사용하여 생성된다. 등록은 또한 접촉 목록 다트의 아이디를 포함한다. 다트 도구들은 생성된 모든 다트 인스턴스 안에 아이디를 자동적으로 위치시킨다.

유사한 방식으로, 장치 A가 장치 B와 함께 영구적인 팀구성 동작을 마치고 난 후 어떤 시점에서 장치 B는 접촉 목록의 특정 팀구성 논리 사례를 식별하는 128 비트 아이디 A에 대한 등록을 구비한 사회 동기화 오브젝트 아이디/다트 핸들러 아이디 목록에로의 영구적인 팀구성을 위하여 사용된다. 상기 등록은 또한 상기 목록에 대해 접촉의 동기화를 수행하기 위하여 사용될 수 있는 동일한 장치 상에 저장되는 다트의 아이디를 포함한다. 일반적으로 핸들러 다트는 다트로 표현될 수 있는 어떠한 동기화 결정들, 작동들 또는 규칙들도 수행할 수 있고, 본 예제에서와 같은 간단한 데이터 동기화 작동들로 한정되지 않는다는 사실을 유념해야 한다.

세가지 장치들은 장치 C가 장치 A와 직접적으로 통신한 적이 없는 경우에도 이제 모두 아이디들과 두개의 명칭들을 포함하는 사회 동기화 등록들을 포함한다.

예제에 따르면, 장치들이 팀으로 구성된 후 연결들은 닫히고 새로운 명칭은 접촉 핸들러 다트 Z를 실행하는 사용자에 의해 장치 C 상에 있는 목록에 추가된다. 세가지 블록 다이어그램들은 세번째 명칭이 장치 C 상에 추가되자 마자 세가지 장치들의 상태를 표시한다.

다음, 접촉 핸들러 다트 Z 또는 장치 C 상에서 실행되는 어떠한 다른 다트도 장치 A로의 연결을 시작한다. 연결을 설정하는 동안, C 상에 있는 다트 엔진은 두개의 장치들 상에 있는 사회 동기화 아이디들을 자동적으로 비교하고 그것들이 128 비트 아이디를 공유할 것을 결정한다. 장치 C 상에 있는 다트 엔진은 접촉 핸들러 다트 Z를 자동적으로 시작할 것이고 다트들에 저장되어 있는지 개별적으로 저장되어 있는지에 따라 데이터의 동기화를 조정할 것이다. 이제 장치 A 및 C는 접촉 목록 안에 있는 모든 세가지의 명칭들을 포함한다.

장치 B가 장치 A 또는 C에 연결된 후, 장치 B는 장치 B와 장치 B에 연결되는 장치 간에 명칭에 대한 동기화를 수행할 접촉 핸들러 다트 Y를 유사한 방식으로 실행할 것이다. 장치 A를 통한 이벤트는 동기화전에는 장치 C와 통신한 적이 없다는 사실에 유의하라. 그것들은 개별적인 팀구성이 이루어지는 동안 매개 장치 B에 의해 통과된 다트 및 데이터 때문에 자신들이 동기화할 필요가 있다는 것을 알고 있으며 동기화하는 방법을 알고 있었다.

팀으로 구성될 때까지 새로운 장치들이 접촉목록/접촉 핸들러 다트 또는 시발 다트에 대해서 모르는 경우에도 어떤 갯수의 장치들도 이미 팀으로 구성된 어떠한 장치에 의해서도 용이하게 팀에 추가될 수 있다는 사실이 논리적으로 도출된다. 장치들의 팀들 간에 ad-hoc 연결들이 충분한 한, 모든 장치들은 어떠한 매스터 장치 없이도 접촉에 대한 공유 목록에 대해 높은 수준의 동기화를 자동적으로 유지한다.

본 발명의 시스템, 방법, 및 컴퓨터 프로그램들, 및 컴퓨터 프로그램 제품들은 또한 직렬성 및 동기화를 구비한 플랫폼을 제공한다. 도 15, 도 16, 및 도 18에 도시된 내부 장치 다트 런타임(intra-device DartRunTime)은 도 17에 도시된 장치간 다트 런타임(inter-device DartRuntime)과 더불어 모든 작동들이 모든 팀 구성된 장치들의 모든 처리 단위들에 걸쳐서 유리하고도 조심스럽게 직렬화되고 동기화되는 단일 이벤트로 구동된 다트 런타임을 생성한다. 도 9는 이러한 직렬화 및 동기화 기반구조가 다트 모집, 다트 렌디셔닝, 다트 소스, 다트 도구들, 다트 프레임워크, 다트 런타임, 및 다트 엔진을 포함하는 다트 플랫폼 전체에 걸쳐서 어떻게 구현될 수 있는지를 도시한다. 더불어, 이러한 시스템들, 방법들, 및 수단들은 다트 프로그래머들 측이 통신 및 다른 에러들에 직면하는 경우에도 다중 장치들 상 및 그것들 상이에서 연동하는 처리 장치들 전체에 걸쳐서 복잡한 상호운영 및 작동들의 순서를 설정하거나 조정할 필요에 대하여 노력을 거의 기울이지 않아도 다트 상호운영 애플리케이션들에 대한 견고한 상호운영을 보증하기 위한 기반구조를 제공한다.

다트 플랫폼 및 특히 다트 프레임워크를 사용하여 다트 애플리케이션들 작성하면,다트 프로그램머 측의 비교적 적은 노력으로 모든 다트 장치들에 걸쳐서 이진 휴대성(binary portability)이 자동적으로 제공되고, 견고한 전원관리, 견고한 애플리케이션 레벨 에러 복구, 간단하고 효율적인 장치들의 팀구성, 자원들과 장치들의 지능적 발견 및 사용, 다트 플랫폼의 다른 많은 혜택들이 자동적으로 제공된다. 이러한 혜택들을 전달하는 중요한 구성요소는 대체적으로 자동적인 도 9의 예에 도시된 바와 같은 이벤트의 직렬화 및 동기화를 통해 다트 런타임에서 구현된다.

다트 런타임은 상호운영하고 통신하는 초기의 모집된 장치들 간의 다트 이벤트들 및 관련 파일들의 통과 또는 교환을 조정한다. 다트 이벤트들은 자동적으로 복제 및/또는 임의의 갯수의 팀구성된 장치들의 이벤트 큐들 전체에 걸쳐서 동기화된다. 동기화 이벤트로 지정된 이벤트들은 동기화 이벤트 타입들의 목록을 공유하는 모든 장치들의 모든 이벤트 큐들 전체에 걸쳐서 견고하게 분포된다. 이러한 과정은 다음과 같이 도 9에 도시된 예에서 수행된다.

1.다트(700)의 초기 애플리케이션, 렌디션(701a)은 연결 관리자 오브젝트 사 례를 구체적인 불특정 장치간 협력 기능에 대한 시발 장치(400-1) 상에서 예를 들어 설명한다. 연결 관리자는 다트 프레임워크(102)(도 3)의 일부로 다트 플랫폼(도 3) 내에 제공된 연결 관리자 클래스의 사례이다.

2.초기 렌디션(701a)은 모집 및 렌디션닝을 사용하여 장치들의 팀을 모집하여 모든 협력 장치들에 걸쳐서 직렬화되고 동기화될 이벤트 타입들의 공유된 복제 목록을 구비하는 장치들의 팀을 생성한다. 이러한 목록은 각각의 팀구성된 장치들(400-1,400-2,400-3,400-N) 상에 있는 연결 관리자(420)의 사례에 의해 유지된다.

3.공유된 목록 상에 있는 팀구성된 장치들중 어느 한 장치 상의 큐 안으로 이벤트들이 위치될 때마다, 이벤트는 직접적으로 연결된 모든 팀구성된 장치들의 모든 큐들(660)에 우선 위치된 다음 이벤트가 직접적으로 팀구성된 모든 장치들의 큐들 상으로 성공적으로 위치되었음을 알리는 정보가 수신될 때까지 이벤트를 초기 장의 큐에 위치시키는 것이 지연된다. 다른 모든 장치들이 같은 동작을 수행하므로, 다른 모든 팀구성된 장치들, 심지어 초기 장치에 직접 연결되지 않은 장치들이 자신들의 큐에 이벤트를 구비할 때까지 원래의 이벤트는 초기 장치의 큐 안으로 위치되지 못한다. 이렇게 함으로써, 팀구성된 장치들의 큐들 중 어느 하나의 큐 상에도 이벤트가 위치되는 것을 방해하는 에러가 발생하면 팀구성된 장치들 중 어느 하나에 의해서도 이벤트들이 처리되지 않도록 보증된다. 에러들은 원래 이벤트가 직렬적으로 전파되어 리턴되는 것에 의해 이벤트가 리턴 상태에 있다는 것을 나타내는 에러 플래그 및 이벤트 구조 사례의 리턴값 워드에 포함된 에러 코드를 구비하 는 전송자에게 보고된다.

4.하나의 장치에 의해 생성된 이벤트들이 직접 연결된 장치들 상에 질서없이 도달하는 것을 방지하기 위해, 직접 연결된 팀구성된 장치들의 이벤트 큐들 상에 위치될 모든 이벤트들은 이전에 전송된 이벤트가 큐상에 성공적으로 위치되었음을 알리는 정보가 수신될 때까지 새로운 이벤트들이 팀구성된 장치의 큐에 위치되지 않도록 함으로써 직렬화된다. 이것이 필요적인 곳이 첫번째 이벤트가 새로운 슬라이드를 공유된 슬라이드 쇼에 추가하는데 사용되는 ADD_SLIDE 타입 이벤트이고 두번째 이벤트가 새로운 슬라이드임을 나타내는 쇼 슬라이드(SHOW_SLIDE) 타입 이벤트인 예가 도시된다. 매우 작은 크기 때문에 도달이 완료되기 전에 첫번째 이벤트 및 애플리케이션이 슬라이드를 보여주려고 시도하기 전에 두번째 이벤트 장치 상에 도달할 가능성이 크다. 이러한 이유 때문에 직접 연결된 모든 장치들 간에 이벤트들을 직렬화하는 것이 필요하다.

직접 연결된 모든 장치들에 전송된 이벤트들을 직렬화하면 개개의 장치로부터 전송된 모든 이벤트들이 모든 팀구성된 장치들 상에 전송된 정확한 순서로 처리될 것이다. 그러나, 두개 이상의 상이한 장치들이 동기화를 위해서 표시된 이벤트들을 독립적으로 전송할 때 팀구성된 모든 장치들 상에 제시된 공유되고 동기화된 이벤트 목록들(430) 상에 존재하는 것에 비추어 이벤트들의 정확한 순서를 동기화할 필요가 있다.

동기화된 이벤트들이 두개 이상의 장치에 의해 독립적으로 전송될 필요가 있는 경우에도 동기화된 모든 이벤트들이 모든 장치들 상에서 동일한 순서로 처리되 는 것을 보증하기 위한 바람직한 한 방법은 연결 관리자들에 의해 사용되기 위해 지정된 매스터 전송 이벤트 이벤트 타입을 사용하는 것이다. 각각의 연결 관리자는 직접 연결을 통해 모집한 장치를 논리적 매스터로 생각한다. 도 9를 참조하면, 장치(400-N)의 논리 매스터는 장치(400-3)이고 장치(400-3)의 논리 매스터는 장치(400-2)이고 장치(400-2)의 논리 매스터는 장치(400-1)이다. 장치(400-1)은 논리 매스터를 가지고 있지 않은데, 왜냐하면 장치(400-1)는 팀의 초기 모집을 수행하기 때문이다. 이것은 장치(400-1)을 팀의 매스터로 만든다. 논리 매스터의 연결 관리자를 구비하는 어떠한 장치도 그 논리 매스터에 의해 큐에 위치되지 않으면 큐 상에 위치될 이벤트들을 큐 안으로 위치시키지 않을 것이다. 오히려, 연결 관리자는 이벤트를 매스터 전송 이벤트 이벤트 타입 이벤트 안으로 전송하는데 필요한 모든 정보를 포함하고 직접 연결되고 팀구성된 모든 장치들 내에 위치시킬 것이다. 이러한 모든 매스터 전송 이벤트 이벤트들은 결국 팀 매스텅게 전파될 것이다. 이벤트가 그 큐 상에 위치될 예정이면, 그것이 팀 매스터라는 것을 아는 연결 관리자는 재구성된 원래 포함된 이벤트를 큐 상으로 위치시키도록 시도할 것이다. 만약 포함된 이벤트 타입이 연결 관리자들의 동기화 목록 상에 있으면, 이벤트 타입은 마치 그것이 팀 매스터에 의해 생성되었고 전송될 것처럼 팀에 기반한 모든 장치들에게 직렬 방식으로 전파될 것이다.

실제에 있어서, 팀 매스터는 다른 팀구성된 장치들의 큐들 상으로 위치될 동기화된 이벤트들을 전송하도록 허락된 유일한 장치이다. 다른 모든 장치들은 매스터가 다른 모든 장치들을 위해 동기화된 이벤트들을 전송하도록 요구할 필요가 있 다. 동기화된 모든 이벤트들은 직렬화된 채널을 통해 팀 매스터에 의해 전송되므로, 팀에 속한 모든 장치들은 자신들의 큐상에서 모든 이벤트들을 정확히 동일한 순서로 수신하고 원하는 모든 팀구성된 장치들에 걸쳐서 동기화된 작동들의 완결성을 보존할 것이다.

바람직한 일실시예에 따르면, 동기화된 이벤트들의 직렬화는 그 자체를 이용하여 모든 장치들 상에 있는 연결 매스터들이 동기화를 수행하기 위하여 이벤트 타입들의 정확하고 동일한 목록을 유지하는 것을 보증할 수 있다는 사실을 유의하라. 또한, 직렬 시스템은 새로운 장치가 팀 매스터로 간주될 것임을 나타내는 타입의 직렬화되고 동기화된 이벤트들을 전송하는데 사용될 수 있다. 새로운 매스터를 선언하는 이벤트는 직렬화되고 동기화되므로, 모든 장치들은 정확하고 동일한 순서로 그러한 이벤트들을 수신하고, 상이한 새로운 매스터들을 선언하는 이벤트들을 전송하는 다중 장치들 조차도 처리된 최종 이벤트가 완수되도록 동일한 최종 이벤트를 획득하는 모든 장치들과 함께 결국 변형되는 것을 보증할 것이다.

사회 동기화 상호운영 방법 또는 좀더 구체적인 다트 사회 동기화를 관련시키는 본 발명의 선택된 특정 실시예를 후술한다. 일실시예(1)에 따르면, 본 발명은 그 자체가 다른 팀구성된 장치들 간에 독립적으로 그리고 간혈적으로 수행될 수 있는 단속적으로 직접 연결 및/또는 일련의 직접 연결들을 통해 간접적으로 연결될 수 있는 동종 및/또는 이종의 장치들로 이루어진 하나 이상의 동적으로 생성된 팀들에 걸쳐서 자원들의 동기화를 유지하기 위한 방법을 제공하는 방법에 있어서, (1) 하나 이상의 독립적으로 실행가능한 이미지들로 구성된 초기의 상호운영 애플 리케이션 프로그램 패키지를 상호운영 장치 상에서 실행하고, 상기 이미지들은 논리적 또는 물리적으로 동기화될 자원 또는 자원들을 포함 및/또는 동기화될 자원들을 수집 및 관리하는데 필요한 모든 능력들을 포함하고; (2) 단속적 연결이 다른 장치들에 이루어지고 초기 애플리케이션이 상호운영 정보를 새롭게 팀으로 구성된 장치들에게 전파시키는 초기 상호운영 애플리케이션 프로그램을 이용하여 다른 장치들을 팀으로 구성하는 단계를 제공한다.

또 다른 실시예(2)에 따르면, 실시예(1)에 따른 방법에 있어서, 본 발명은 하나 이상의 팀구성된 장치들 상에서 실행되는 작용 애플리케이션 패키지들이 장치들로 구성된 팀이 한정적이거나 가능하게는 비한정적인 방식으로 계속 성장될 수 있도록 초기 상호운영 애플리케이션 프로그램 패키지로서 작용하는 하나 이상의 다른 장치들에 대한 팀구성을 반복하는 단계(3)를 선택적으로 더 포함한다.

또 다른 실시예(3)에 따르면, 실시예(1)에 따른 방법에 있어서, 본 발명은 장치들 간에 자원들을 동기화시키는 단계(4)를 선택적으로 더 포함한다.

또 다른 실시예(4)에 따르면, 실시예(1)에 따른 방법에 있어서, 본 발명은 하나 이상의 팀구성된 장치들 상에서 실행되는 작용 애플리케이션 패키지들이 장치들로 구성된 팀이 한정적이거나 가능하게는 비한정적인 방식으로 계속 성장될 수 있도록 초기 상호운영 애플리케이션 프로그램 패키지로서 작용하는 하나 이상의 다른 장치들에 대한 팀구성을 반복하는 단계(3); 및 장치들 간에 자원들을 동기화시키는 단계(4)를 더 포함한다.

또 다른 실시예(5)에 따르면, 실시예(3)에 따른 방법에 있어서, 본 발명은: 두개의 팀구성된 장치들 간에 통신 세션을 시작하는 단계(a); 한 장치 상에 있는 고유한 동기화 아이디들을 다른 장치들 상에 있는 고유한 동기화 아이디들과 비교하는 단계(b); 모든 매칭된 고유한 아이디와 관련된 상호운영 애플리케이션 프로그램을 실행하는 단계(c); 두개의 장치 모두에 걸쳐서 상호운영 애플리케이션 프로그램의 실행을 전파시키는 단계(d); 및 두 장치들에 걸쳐서 작동을 전파시키는 상호운영 애플리케이션 프로그램에 의해 상호운영 동기화 목적을 수행하기 위해 어떠한 동기화 방법이 필요하든지 그 방법을 수행하는 단계(e)를 선택적으로 더 포함한다.

또 다른 실시예(6)에 따르면, 실시예(4)에 따른 방법에 있어서, 본 발명은: 두개의 팀구성된 장치들 간에 통신 세션을 시작하는 단계(a); 한 장치 상에 있는 고유한 동기화 아이디들을 다른 장치들 상에 있는 고유한 동기화 아이디들과 비교하는 단계(b); 모든 매칭된 고유한 아이디와 관련된 상호운영 애플리케이션 프로그램을 실행하는 단계(c); 두개의 장치 모두에 걸쳐서 상호운영 애플리케이션 프로그램의 실행을 전파시키는 단계(d); 및 두 장치들에 걸쳐서 작동을 전파시키는 상호운영 애플리케이션 프로그램에 의해 상호운영 동기화 목적을 수행하기 위해 어떠한 동기화 방법이 필요하든지 그 방법을 수행하는 단계(e)를 선택적으로 더 포함한다.

또 다른 실시예(7)에 따르면, 실시예(1)에 따른 방법에 있어서, 상기 상호운영 정보는: 장치들이 특정한 동기화 목적을 위해 팀으로 구성된다는 사실을 알리는 데 사용되는 하나 이상의 범용적으로 고유한 상호운영 아이디들 (i); 및 동기화 목적을 수행하기 위해 실행될 수 있는 범용적으로 고유한 아이디들과 관련된 하나 이상의 상호운영 애플리케이션 패키지들 (ii)을 포함한다.

또 다른 실시예(8)에 따르면, 실시예(6)에 따른 방법에 있어서, 상기 상호운영 정보는: 장치들이 특정한 동기화 목적을 위해 팀으로 구성된다는 사실을 알리는 데 사용되는 하나 이상의 범용적으로 고유한 상호운영 아이디들 (i); 및 동기화 목적을 수행하기 위해 실행될 수 있는 범용적으로 고유한 아이디들과 관련된 하나 이상의 상호운영 애플리케이션 패키지들 (ii)을 포함한다.

또 다른 실시예(9)에 따르면, 실시예(1)에 따른 방법에 있어서, 다음 중 하나 이상은 어떠한 조합으로도 참이다: (1) 장치 모집 프로시져 또는 다트 모집을 사용하여 팀들이 적어도 부분적으로 형성되는 단계; (2) 하나 이상의 상호운영 장치들은 다트 장치들이고; (3) 상호운영 애플리케이션 프로그램 패키지는 상호운영 포맷 또는 다트 포맷을 따르거나 다트이고: (4) 독립적으로 실행가능한 이미지들은 렌디션들 또는 다트 렌디션들이고; (5) 자원들은 상호운영 소스의 기술(description)에 의해 자원들로 기재된 하나 이상의 타입들이고; (6) 범용적으로 고유한 상호운영 아이디들은 사회 보안 절차적 기반을 사용하여 생성하는 단계; 및 (7) 하나 이상의 상호운영 애플리케이션 프로그램 패키지들은 모집 방법 및 생성론 방법들 중 어느 하나 또는 두가지 방법 모두를 사용하여 생성되는 단계를 포함한다.

또 다른 실시예(10)에 따르면, 실시예(1)에 따른 방법에 있어서, 동기화는 다음 중 하나 이상을 어떠한 조합으로도 포함한다: (1) 독립적 사례들 및/또는 일반적으로 식별된 데이터베이스 사례들의 의미론 및/또는 데이터베이스 또는 데이터베이스에 포함되는 구성요소에 의해 유지될 수 있는 어떤 것을 개별적인 사례들에 독립적으로 초래된 변화들이 다음 중 하나 이상의 요소들을 유지하는데 필요한 어떠한 방식으로든지 변하도록 유지하는 단계를 포함하고, 상기 요소들은: (a) 일반적인 식별과 관련된 의도한 데이터 및 목적을 포함하는 데이터베이스의 완결성; (b) 데이터베이스의 구성요소들; (c) 데이터베이스 및/또는 데이터베이스의 구성요소들의 상호관계의 의미론; 및 (d) 데이터베이스들의 사례들의 일반적인 아이덴티티(identity)를 포함하고; (2) 독립적인 장치들 상에 독립적으로 저장 및/또는 변형된 항목들의 목록 상에 있는 구성요소들의 추가, 삭제, 또는 수정을 추적하는 단계; (3) 장치들로 구성된 팀에 의해 정보를 수집 및/또는 처리 및/또는 대조하는 단계; (4) 장치들의 자원들 또는 능력들에 대한 접근을 제어 및 제한하는데 필요한 고유 아이디들, 공유된 비밀들(secrets), 및 보안 설정들의 목록들을 유지하는 단계; (5) 장치들의 작동 또는 장치들의 세트에 영향을 주는 장치간 설정 관리; (6) 다중 장치들에 걸친 환경 설정 관리; (7) 다중 장치들에 걸친 소프트웨어 또는 컨텐츠 설치; 장치들 및/또는 장치들의 자원들 또는 장치들에 의해 도달될 수 있는 자원들 또는 정보가 하나 이상의 장치들에 의해 저장되거나 유지될 수 있는 자원들의 목록을 작성하는 단계(8); 소프트웨어 또는 컨텐츠를 분포시키거나 다중 장치들에 걸쳐서 갱신하는 단계(9); 및 전술한 단계들의 조합(10)을 포함한다.

XIX . 소셜시큐리티(SocialSecurity)의 상호운용성 모델/다트 소셜시큐리티

소셜시큐리티(SocialSecurity)는 가능한 단속적으로 접속되는 장치들의 팀들 사이에서 보안 웹(web)을 형성하는 방법을 관리하기 특히 간단하다는 것을 명심하라. 소셜시큐리티는 인간들이 흔히 서로 신뢰하게 되는 법과 유사한 방식으로 작동 한다. 소셜시큐리티의 기초는 장치에서 장치로 전이하며 이동하는 허락된 접속 권리와 함께 다트시큐리티(DartSecurity)를 이용하여 발생한 유일 아이디들(unique ids)을 유포하기 위해 소셜싱크로나이제이션(SocialSynchronization)을 이용하는 것이다. 직접 통신을 한 적이 없는 장치들은 더 이상의 허가를 얻을 필요 없이 일정한 접속 권리와 상호운용되도록 허용된 장치들 팀의 일부임을 종종 발견할 것이다.

보안 기술의 현 상태에서의 가장 큰 문제점 중의 하나는 최종 사용자가 보안 방법들을 이해하고 관리하기 너무 어려워서 결국에는 그것들을 전혀 사용하지 않는다는 것이다. 사용되는 보안 방법들의 강도와 관리의 복잡성 간에는 직접적인 관련성이 있다. 전통적인 기업 및 정부의 컴퓨터 네트워크에서는, 고도의 강도가 필요하다고 여겨졌으며 고도로 훈련된 상근 전문가들에 의해 불가피하게 관리되어져 왔다. 이러한 네트워크들이 좀처럼 변경되지 않는다는 사실은 관리할 분량이 전문가들에게 적절하게 하였다. 이와 같은 종래 보안 방법들은 훈련되지 않고 시간이 없는 개인들 또는 이동 장치들이 왕래함에 따라 일정한 관리를 필요로 하는 장치들의 네트워크들을 확보하는 전 시간(full-time) 관리에 대한 열정을 갖는 개인들에 의해 사용되는 발전적이고 성장하는 이동 장치의 세계에 흔히 적용된다. 본 발명의 소셜시큐리티 방법은 어쩌면 기업이나 정부 네트워크에서 채용되고 있는 전통적인 방법들과 같이 강력하진 않을지라도, 장치들을 관리하기 매우 쉬우며, 대부분 사람이 전통적인 방법들 사용하지 않거나 꺼버린 곳에서 실제로 사용하게 될 훌륭한 보안 레벨을 전해준다. 따라서, 소셜시큐리티는 어떠한 보안도 달리 사용되지 않는 상황에서 훌륭한 보안 레벨을 유익하게 전해준다.

이메일은 좋은 예이다. 전통적인 보안 이메일 프로토콜들은 이메일을 사용한 이래로 유용하였으며 대부분의 기존 이메일 사용자의 고객 소프트웨어에 내재하여 있다. 그러나 이러한 보안 이메일 프로토콜들을 사용하는 이메일 최종 사용자들은 거의 없다. 하나의 이유는 증명서를 얻고, 안전하게 하고 사용하며 안전하게 이메일을 보내고자하는 모든 이가 또한 증명서를 얻고, 안전하게 하고 이용하는 관리를 수행하는 지를 보증하는 데 필요한 관리 과정이 너무 복잡하고 지루하기 때문이다. 다른 예는 많은 가정용 무선 네트워크가 안전하지 않게 방치된 무선 접속 포트 상에서 보안 설정이 너무 힘들다는 데에 있다.

소셜시큐리티는 상호작용을 확보하기 위한 인간 모델과 유사하다. 어떤 이는 새로운 종업원이 조직 내 다른 이들에 의해 소개되었기 때문에 그 종업원에게 회사 비밀 정보를 털어놓게 됨을 배우게 된다. 구 종업원들은 새로운 종업원이 회사의 성실한 종업원이라는 초기 지식을 갖는 어느 누구에게도 직접적인 대화를 해본 적이 없이 새로운 종업원을 신뢰하기 시작할 것이다. 이러한 신뢰의 웹(web of trust)은 중앙의 코디네이션(coordination)이나 트래킹(tracking)의 필요 없이 수립된다. 흔히 휴대폰, 프린터, PDA, 랩톱 컴퓨터, 디지털 카메라 및 휴대용 뮤직 플레이어와 같은 장치들은 매체, 정보 또는 공유하기 위한 컨트롤(control)을 갖지만 이들은 모두 한번에 연결되지 않거나 어느 하나의 동일한 중앙 소오스(source)에 연결되지는 않는다. 그러나 장치에서 정보의 인티크리티(integrity)를 다른 장치 또는 소프트웨어에 의한 부적절한 사용 또는 손상으로부터 보호하기 위해 보안 방법을 사용하는 것이 바람직하다. 소셜시큐리티 방법은 신뢰된 장치 및 소프트웨어의 웹 또는 최소한의 관리와 함께 특정 세트(set)의 접근권한들을 갖는 다트 또는 장치 사용자에게 요구되는 훈련을 수립하며 접근 권한이 장치에서 장치로 통과되는 본 발명의 상호운용성 시큐리티 또는 본 발명의 다트플랫폼의 다트시큐리티 방법의 특별한 부분이다.

소셜시큐리티 방법은 본 명세서의 다른 곳에서 언급된 다트시큐리티 방법을 토대로 한다. 다트시큐리티(도 29)는 모든 다트디바이스 및 다트애플리케이션이 보편적 유일 식별자(universally unique identifier, uid) 를 갖는다는 것을 보증한다. 각 다트디바이스는 또한 바이너리 플래그(binary flag) 세트에 의해 지시된 바와 같은 접근권한들이 허용된 타 다트디바이스들의 uid들의 목록들을 유지한다. 각각의 바이너리 접근권한 플래그의 세트는 한 레벨에 할당된다.

소셜시큐리티는 장치들의 팀들을 형성하고 유지하며 팀으로 된 모든 장치들 상에 공통 접근 권한을 갖는 장치들의 목록을 배분하고 유지하기 위한 전이적인 (transitive) 방법이다. 도 31은 디바이스시큐리티 목록들(DeviceSecurity Lists), 취소 목록 (Revoked List), 소셜시큐리티의 디바이스 Uid 요소들과 함께 좌측에 다트디바이스(DartDevice)를 보여준다. 보여지는 소셜싱크(SocialSync) 목록은 본 명세서의 다른 곳에 언급된 것으로서 장치들 상에서 전이적으로(transitively) 다트리스트들을 유포하고 동기화하기 위해 적어도 부분적으로 바람직한 실시예에서 사용된 소셜싱크로나이제이션(SocialSynchronization) 방법의 일부이다.

도 31의 우측은 소셜시큐리티 방법을 설명하는 데 도움이 되도록 팀으로 하 기(teaming) 전과 후의 구/신 다트디바이스의 상태의 예를 보여준다. 팀으로 하기 전의 본 예에서, 올드 다트디바이스(Old DartDecvice) uidA는 목록 레벨에 해당하는 플래그의 접근권한 내에서 상호운용하도록 허용될 애플리케이션들 및 장치들의 uid들의 목록들을 갖는다. 팀으로 하기 전 뉴 다트디바이스(New DartDevice) uidZ의 디바이스시큐리티 목록(DeviceSecurity List)만이 장치 자체가 레벨 9에 해당하는 것과 함께 상호운용하도록 허용한다. 보통, 제조자로부터 디바이스와 함께 선적된 몇몇 다트 애플리케이션은 장치 및/또는 장치의 보안 형태를 구성하기 위해 높은 단계의 접근을 필요로 하게 되어 장치는 디바이스 자체에 대한 애플리케이션에 레벨 9 목록에 있는 장치 자신의 uid를 갖는 것에 의해 나타내어지는 바와 같은 높은 단계의 접근이 부여될 것이다.

새로운 장치에 대한 다트가 장치들의 구 장치와의 첫 번째 접촉을 시작하고 구 장치상에서 동작하기 위해 자체의 렌디션(rendition)으로부터 발생된 다트를 전송하고 동작하는 경우, 다트 내 그리고 새로운 장치의 접근 권한이 검사된다. 물론, 구 장치는 새로운 장치에 대해 아는 것이 없으며 본 예의 경우에는 구 장치로 실행을 펼치고자 시도하는 다트 애플리케이션의 접근 권한에 대해 아무런 보안 정보도 가지지 아니한다. 본 예에서, 사용자는 이 장치들이 다트의 플래그에 의해 통신된 접근 필요(access needs)에 따라 상호 운용하기 위해 허가를 위한 각 장치의 사용자 인터페이스를 통해 질문을 받게 될 것이다. 도 31은 하부의 우측에 도시된 바와 같이, 구 장치로 통과된 다트 내 특정된 모든 접근권한을 부여하는 접근 플래그 세트(access flags set)에 해당하는 단계 7에서 장치들이 상호 운용하도록 허락 된 이후의 장치 상태를 보여준다. 사용자 인터페이스를 통해 사용자로부터 허락을 얻은 후에, 구 및 신 다트디바이스들 모두 장치들의 uid들의 동일한 레벨 7 목록 및 허가 질문 없이 상호 운용하도록 허락된 다트들을 포함한다. 뉴 다트디바이스가 동일한 보안 접근 플래그 요구사항들을 갖는 새로운 단계 7의 다른 장치들의 어느 하나에 다트를 전송하기 위한 다음 시도를 해야하는 경우에는 사용자에게 질문을 할 필요없이 작동하도록 허용된다. 사실상 장치들은 알고 있는 모든 다른 장치들을 보증한다(vouch). 장치들의 신뢰되는 팀은 uid 팀 목록들이 팀의 다른 장치들에 대해 단속적일지라도 접속을 통해 장치들 상에 배분되었다면 전에 어떠한 접촉이 없다 하여도 서로 신뢰할 것이다. 바람직한 실시예에서, uid들의 목록들은 본 명세서의 다른 곳에서 언급된 소셜싱크로나이제이션(SocialSynchronization) 방법의 일부들을 이용하여 동기화된다.

오직 사용자 참여를 요구하거나 팀을 형성하고 유지하기 위해 이해를 요구하는 관리는 장치가 필요한 방식으로 상호 운용을 시작할 수 있기 전에 어떤 종류의 접근이 부여되어야 하는 지에 관한 질문에 직접적으로 대답하기 위한 능력임을 주의하여야 한다. 장치들과 다트들을 사용하는 단순한 임무들은 사용자로부터 허가들에 대해 쉽게 이해되는 적은 수의 요구들과 함께 접근 권한들을 모으고 배분하게 한다.

장치에 대한 접근권한의 취소도 소셜시큐리티를 이용하여 장치 및 다트의 취소된 uid들의 목록을 유포하도록 이루어질 수 있다. 바람직한 실시예에서, 필요로 되는 권리들을 갖는 장치의 취소된 목록들 중 하나인 장치들간에 상호 운용하기 위 한 어떠한 시도도 허락되지 않을 것이며, 보안의 적절한 단계에 대해 취소된 장치들의 팀들 목록의 uid들은 제거될 것이다.

본 발명의 소셜시큐리티 상호운용성 모델의 다른 특별한 실시예들 및 그 모델의 더 구체적인 버전, 즉 다트 소셜 시큐리티 모델을 이제 설명하기로 한다. 일 실시예(1)에서, 본 발명은 (1)상호운용가능한 장치들간의 접속 권한 및 자격증명서들을 자동적이며 전이되게 유포하는 방법을 제공하며, 그 방법은 유일한 id들을 상호운용성 장치 각각에 할당하는 단계; (2)초기의 접근권한 세트를 각 상호운용성 장치에 할당하는 단계; (3) 하나 이상의 유일 id들을 각 상호운용성 소프트웨어 패키지에 할당하고 유일 id들의 세트 및 애플리케이션 패키지의 일부인 독립적으로 수행가능한 이미지(image)의 전부 및/또는 각각에 의해 필요로 되는 관련된 접근 권한들을 상기 패키지에 심는 단계; 및 (4) 두 상호운용성 장치들이 통신 채널을 연 경우 장치 팀들에 대한 어느 기존의 접근권한들 또는 어느 한 장치에 대해 양 장치의 상호운용성을 위해 존재하는 그것들보다 더 제한적이지 않은 유일의 id들과 관련된 애플리케이션들이 다른 장치에 그것들과 동기화된다.

다른 실시예(2)에서, 본 발명은 하나 혹은 그 이상의 다음의 것들이 사실인 것을 특징으로 하는 (1)의 방법을 제공하되, 다음의 것들은 (1) 상호운용성 장치가 다트 서비스를 포함하고; (2) 유일의 id들의 기초는 상호운용성 보안 프로시쥬어이며; (3) 접근권한들은 상호운용성 보안 프로시쥬어에 언급된 바와 같으며; (4) 상기 패키지는 상호운용성 소프트웨어 패키지 및/또는 다트이고; (5) 통신 채널의 오프닝(opening)은 장치 모집 프로시쥬어(device recruitment procedure)의 일부로서 시작되고(5); 그리고, (6) 접근권한들은 소셜 싱크로나이제이션 프로시쥬어를 이용하여 동기화된다는 것을 포함한다.

다른 실시예(3)에서, 본 발명은 (1) 특정의 상호운용성 목표를 수행하기 위해 초기 상호운용성 장치를 동작하는 상호운용성 소프트웨어 패키지로부터 목표(target) 상호운용성 장치까지의 통신 세션(communication session)을 시작하는 단계; (2) 의도된 목적을 위해 장치들 사이에 적절한 접근권한들이 존재하는지에 대해 결정하는 단계; 및 (3) 적절한 접근권한들이 존재한다면 응용 소프트웨어 패키지는 독립적으로 수행가능한 이미지를 목표 장치로 전송하고 요구된 접근권한들과 함께 콘텍스트(context) 내에 이미지를 작동함으로써 목표장치까지 그 수행을 확장하도록 허가되는 단계를 포함하여 수행되는 것을 특징으로 하는 (1)의 방법을 제공한다.

XX . 상호운용성 장치/ 다트디바이스

다트디바이스는 다트엔진 및 다른 다트디바이스들로의 연결을 위한 적어도 하나의 통신 프로토콜을 포함한 다트플레이어를 운용하기에 고도로 상호운용가능한 장치임을 명심하라. 상호운용성 장치의 형태 및 더욱 구체화된 다트디바이스는 도 3(300) 및 도 4(3000)에 설명된다.

일 실시예(1)에서, 본 발명은 (1) 일반적인 계산 및 입/출력 작동을 수행할 수 있는 물리적 메모리와 결합한 프로세서를 기반으로 물리적 터닝(Turning) 완전 명령 세트; (2) 다른 장치들과 쌍방향 통신을 위한 적어도 하나의 수단; (3) 상기 프로세서상에서 작동하며 장치상에 탑재가능하고 수행가능하며 수행가능한 형식으로 구현된 상호운용성 플레이어 내에 캡슐화된(encapsulated) 상호운용성 엔진을 포함하여 이루어진 상호운용성 장치를 제공한다.

다른 실시예(2)에서, 본 발명은 상호운용성 플레이어를 더 포함하여 이루어진 (1)과 같은 상호운용성 장치를 제공한다.

다른 실시예(3)에서, 본 발명은 (1) 상호운용성 장치가 다트디바이스이고; (2) 상호운용성 엔진은 다트엔진을 포함하며; 그리고 (3) 상호운용성 플레이어는 다트플레이어를 포함한다는 것들 중 어느 하나 이상이 그 자체로 사실이거나 그들의 결합이 사실인 것을 특징으로 하는 상호운용성 장치를 제공한다.

다른 실시예(4)에서, 본 발명은 다른 유사 혹은 비유사 장치들과 상호운용성 모드로 장치를 작동하는 방법을 제공한다. 그 방법은 (1) 물리적 메모리와 결합하며 일반적인 계산 및 입/출력 작동들을 수행할 있도록 결합한 프로세서내에서 수행가능한 물리적 터닝(Turning) 완전 명령 세트를 제공하는 단계; (2) 적어도 장치와 다른 장치 간에 쌍방향 통신을 송수신하는 단계; 및 (3) 상기 프로세서상에서 그리고 장치상에 탑재가능하고 수행가능하며 수행가능한 형식으로 구현된 상호운용성 플레이어 내에 캡슐화된(encapsulated) 상호운용성 엔진을 작동하는 단계를 포함하여 이루어진다.

XXI . 상호운용성 플랫폼/ 다트플랫폼

다트플랫폼은 다트디바이스들의 지정(specification), 생성(generation) 및 지적인 팀 구성(intelligent teaming)을 수행할 수 있고 하나 이상의 다트디바이스 들에 다트 상호운용성 애플리케이션을 보급 및 작동하기 쉽게 할 수 있는 다트 방법의 어떤 세트일 수 있다는 것을 명심하라. 상호운용성 플랫폼의 형태 및 범용 상호운용성 플랫폼의 보다 특별한 다트플랫폼은 상세한 설명의 다른 부분뿐만 아니라 도 3에 설명되어 있다.

상호운용성 플랫폼의 다른 실시예들-그 다트 플랫폼이 구체적인 예-이 기술될 것이다. 일 실시예(1)에서, 본 발명은 안정되고, 신뢰성 있으며 효율적이고 강력한 방식으로 다수의 가능한 이종장치들에 대해 독립적으로 수행가능한 이미지의 상호운용성 소프트웨어 패키지의 의도를 지정, 구축, 분배 및 수행하기 위한 시스템을 제공하는 것으로, 상기 시스템은 (1) 상호운용성 컴퓨터 프로그램 소프트웨어 패키지를 지정하기 위한 상호운용성 소오스; (2) 프로시쥬어 명령들을 구축하기 위한 상호운용성 툴(tool); (3) 적어도 상기 프로시쥬어 명령들을 패키지하기 위한 상호운용성 포맷; (4) 상기 상호운용성 툴에 의해 생성되는 프로시쥬어 명령들을 나타내기 위한 상호운용성 명령 세트; (5) 상호운용성 소프트웨어 패키지를 작동하고 모든 상호운용성 장치들에 대해 공통 상호운용성 인프라를 제공하기 위한 상호운용성 엔진; 및 (6) 상호운용성 장치들의 팀을 형성, 분배 및 유지하기 위한 장치 모집(recruitment) 수단을 포함하여 이루어진다.

다른 실시예(2)에서, 본 발명은 디바이스 모집(device recruitment)이 시작 소스 디바이스 및 그 자체가 도달될 디바이스 모두에 공통되는 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 필요한 리소스 또는 능력을 가지는 디바이스를 발견하도록 동작하는 인스펙션 프로시져를, 적어도 하나의 통신 링 크를 통해 상기 시작 소스 디바이스와는 다른 적어도 하나의 도달가능한 디바이스로 전달하는 수단; 상기 시작 디바이스에서 도달가능한 디바이스들 각각으로부터의 리턴 응답을 통신 링크를 통해 직접적으로 또는 간접적으로 수신하는 수단; 상기 소프트웨어 애플리케이션의 목적을 가장 잘 수행할 수 있는 상기 도달가능한 응답 디바이스들과 상기 시작 소스 디바이스의 능력들 및 리소스들의 조합을 확인하기 위한 유틸라이제이션 플랜(utilization plan)을 결정하기 위하여 상기 시작 디바이스에서 실행되는 프로시쥬어를 통해 도달가능한 모든 응답 디바이스들로부터 수신된 리턴 응답들을 분석하는 수단; 및 상기 시작 디바이스에서 실행되는 애플리케이션 프로그램을 통해 코드, 데이터, 콘텐트 및/또는 다트(Dart) 중의 적어도 하나를 상기 결정된 유틸라이제이션 플랜에 따라 필요한 리소스 또는 능력을 가지는 것으로 확인된 상기 도달가능한 각 디바이스들 중의 적어도 하나에 분배하는 수단을 더 포함하여 이루어진 (1)의 시스템을 제공한다.

다른 실시예(3)에서, 본 발명은 다음의 선택적인 요소들 중 어느 하나 혹은 그 이상을 포함하여 이루어지거나 어떠한 컴비네이션(combination)으로 시스템에서 사용되어지는 것을 특징으로 하는 (1)의 상기 시스템을 제공한다. 상기 선택적인 요소들은 상호운용성 프래임워크(1); 선형 태스킹(tasking) 수단(2); 수직 계층 수단(3); 애플리케이션 구동 파워 관리 수단(4); 애플리케이션 구동 오차 회복(error recovery) 수단(5); 상호운용성 런타임(6); 상호운용성 애플리케이션 구동 런타임; 창조 수단(8); 버츄얼 포인터들(9); 상호운용성 보안 모델 수단(10); 소셜 싱크러니제이션 수단(11); 소셜 시큐리티 수단(12); 및 상호운용성 장치 인에블 수단(13) 을 포함한다.

다른 실시예(4)에서, 본 발명은 다음의 어느 하나 혹은 그 이상이 어떠한 컴비네이션 형태로 사실인 것을 특징으로 하는 (1)의 상기 시스템을 제공한다. 다음은 (1) 상기 시스템이 다트플랫폼을 포함하고; (2) 상호운용성 소프트웨어 패키지는 상기 상호운용성 포맷에 부합하거나 다트포맷에 부합하는 다트이며; (3) 독립적으로 수행가능한 이미지는 렌디션(rendition)이며; (4) 상호운용성 소오스는 다트소오스이며; (5) 상호운용성 툴은 다트툴이며; (6) 상호운용성 포맷은 다트포맷이며(6); (7) 상호운용성 명령 세트는 다트인스트럭션세트(DartInstructionSet)이며; 그리고 (8) 모집(recruitment) 방법은 다트 모집 방법을 포함한다.

XXII . 버츄얼 포인터들

종래의 프로그램들은 종종 대부분이 컴파일되고 오직 하나의 선형 데이터 주소 공간을 직접 어드레스 할 수 있는 종래의 프로세서를 표적 하도록 링크된다. 흔히, 프로세서들은 가상 메모리를 수행하여 제한된 수의 현실 메모리 블록 혹은 페이지들이 대용량 저속도의 저장장치 내외에서 자동으로 교환되는 가상메모리 시스템을 수행함으로써 프로그램 및 운영시스템이 물리적 메모리보다 더 큰 주메모리를 직접 어드레스하도록 허용한다. 이는 유익하게도 프로그래머가 직접적으로 주소지정 가능한 (addressable) 고속의 주메모리 및 저속의 대용량의 저장 장치 사이에 프로그램 교환을 직접 관리하는데 필요한 다른 로직에 대한 걱정으로부터 자유롭게 한다.

여전히 프로그래머들은 프로그램을 수행하는 동안 크기를 동적으로 변화함에 따라 독립된 데이터 구조들이 서로 간의 충돌(conflict)을 어드레스하지 않도록 하기 위한 메모리 관리 로직에 대해 종종 걱정을 해야만 한다. 가상 메모리 기술이 보다 크며 효율적인 데이터 주소 공간을 생성하는 데 사용된다 하여도 단일의 주소 공간의 공유 사용을 동적으로 분배하고 관리하는 것은 흔히 복잡하고 버그(bug)에 걸리기 쉽다.

종래의 가상 메모리 기술의 다른 한계는 크기가 동시에 로딩되는 프로그램들 전부 또는 프로그램들의 섹션들에 최적으로 부합되는 다중 프로그램에 사용되도록 실제 메모리 변화의 한 크기를 요구하는 방식으로 혹은 프로세서가 작동하는 프로그램의 성질에 관계없이 고정된 크기의 실제 메모리 페이지를 지원만 한다는 데 있다.

본 발명의 일 실시예에서, 각 프로그램에 의한 사용을 위해 다중의 독립적인 주소 공간들을 제공하고 실제 메모리 페이지들 및 그들의 크기가 유용한 실제 주메모리의 물리적 크기, 주메모리의 속도 및 성능 특성, 및 특정 프로그램의 특정 데이터 세트에 대한 예상되는 접근 패턴에 따라 유익하게 변화하도록 허용하기 위하여, 더 복잡한 어드레스 로직(addressing logic)이 하드웨어 프로세서와 소프트웨어 명령 세트 수행 엔진에 사용된다. 본 발명의 버츄얼포인터들(VirtualPointers)의 사용을 위해 제공하도록 본 발명의 프로그램 언어 확장(programming language extension)은 소오스 코드, 컴파일러 및 링커에서 지원된다. 버츄얼포인터들의 사용은 다음과 같은 유익한 점들을 갖는다.

1. 다중의 대용량 독립 주소 공간들. 각각의 동적으로 재크기화(resized)된 데이터 구조는 자신만의 다른 버츄얼포인터 주소 공간을 유지할 수 있어 데이터 구조가 다른 주소 공간에서의 충돌은 발생할 수 없다.

2. 각 개별적인 독립 주소 공간을 위한 실제 메모리 페이지들의 수에 대한 애플리케이션 특정 제어. 실제 메모리 페이지들의 최적의 수는 요구되는 실제 메모리의 양을 제한하고/제한하거나 실제 메모리 및 스토리지(storage)간에 데이터 교환에 필요한 저속의 블록 읽기(read) 및 쓰기(write) 수를 제한하기 위한 예상되는 접근 패턴들에 따라 설정될 수 있다. 예를 들어, 대용량 데이터가 0에서 시작하여 선형 차수로 계속하여 항상 접근이 된다면, 하나의 메모리 페이지보다 많은 메모리 페이지가 과잉될 것이다. 페이지 크기는 양호한 성능 속도를 보증하기 위해 혹은 장치가 낡지 않도록 스토리지 블록들에 대한 접근 수를 제한하기 위해 최적의 접근 블록 크기로 설정될 수 있다.

3. 저장 장치의 성능 특성을 조화시키거나 저장 장치의 수명을 향상시키기 위해 실제 메모리 페이지 크기에 대한 장치 특정 제어. 흔히 장치들은 저장용 플래시 메모리를 사용하며, 이는 오동작을 하기 전에 기지의 보증된 블록 접속의 제한 횟수를 갖는다. 하드 디스크는 특정 크기의 블록단위로 데이터를 저장하거나 캐쉬저장한다.

4. 버츄얼 포인터가 예상되는 가장 큰 데이터 구조 혹은 접근에 사용되는 목록더욱더 큰 주소 공간에 대한 값들을 자동으로 그리고 논리적으로 포함하므로, 프로그래머가 데이터 구조 또는 목록들에 대해 필요한 메모리 양을 예측하고 관리할 필요가 없다.

5. 페이지 크기나 페이지 수와 독립적인 형태로 데이터를 자동 저장. 다트소오스는 다트인스트럭션세트(DartInstructuonSet, SAVE_INSTRUCTION)를이용한 다트의 저장이 주소 공간의 모든 데이터 상태를 자동으로 저장할 것인지 여부를 나타내는 각 버츄얼포이터 변수의 파라미터를 정하기 위해 사용될 수 있다. 바람직한 일 실시예에서, 저장되어야 하는 각 버츄얼포인터 값들은 작동중인 다트에 의해 현재 사용되고 있는 페이지 크기나 수에 관계없이 값들의 범위의 스파스(sparse) 목록을 갖는 다트파트(DartPart)로서 유지된다. 이는 페이지 크기 및/또는 페이지 수를 다르게 할 필요가 있는 다른 장치들에 대해 저장된 다트를 작동하는 것을 가능케 한다.

6. 값비싼 주메모리 램(RAM)의 최소한의 용량과 함께 보다 대용량이나 저속도의 데이터 저장으로부터 효율적인 데이터를 캐쉬함으로써 응용장치는 물리적으로 보유하는 것보다 더 큰 램 메모리를 보유하고 있는 것처럼 작동하게 된다.

7. 데이터 및 인덱스들이 서로 다른 가상 주소 공간들에 간직되어 있는 인덱스된 데이터 운용을 위한 단순하고 효율적인 기반 인프라.

바람직한 실시예에서, 버츄얼포인터들은 다트소오스, 다트툴 및 다트엔진에 의해 지원되어 상기 언급된 유익한 점들을 제공한다.

다트소오스에서, 각각의 버츄얼 포인터는 파라미터들을 갖는 C 혹은 C++ 언어의 #프래그마(#pragma) 버츄얼포인터(파라미터들) 확장을 사용하여 구체화되며, 파라미터들은 다음을 포함한다.

1. 프로그램이 수행되기 시작할 때 가상 주소 공간의 시작 주소를 유지할 포인터 변수의 명칭.

2. 사용을 위해 제시된 실제 메모리 페이지들의 수.

3. 주소 공간내 값들이 애플리케이션을 따라 자동으로 저장되어야 하는지 여부에 대해 나타내는 바이너리 플래그(binary flag).

4. 실제 메모리 페이지들의 제시된 크기.

다트툴은 다트소오스 #프래그마문((#pragma statement)을 처리하여 개개의 주소 공간의 출발 오프셋으로서 효과적으로 작용하는 포인터 주소 값을 로딩할 다트를 생성한다. 이러한 출발 오프셋은 실제로 특정 버츄얼 포인터를 식별하기 위해 다트엔진에 의해 해석될 멀티 필드 주소의 부분이다.

다트 버츄얼 포인터의 예가 도 32에 보여진다. 바람직한 실시예에서, 다트의 주소 공간은 최대한 직접적으로 주소 지정가능한 공간이 2^32 8-비트 바이트인 대부분의 종래의 프로세서들 중 더 일반적인 8비트 바이트보다 오히려 32비트 워드 단위이다. 다트플랫폼은 사용될 주소 공간 유형을 지시하는 필드(field)로서 32-비트 어드레스 중 2개의 최상위 비트(most significant bit)를 이용한다. 다트엔진에 의해 수행되는 다트인스트럭션세트의 주소지정 가능한 단위는 32-비트 워드이므로, 2^30 32비트 워드인 주소지정 가능한 메모리의 크기에 손실이 없다. 도 32의 예는 주소 공간 유형 필드가 이것이 버츄얼포인터 주소 공간임을 나타내는 어드레스를 보여준다. 다음의 다섯 비트 필드는 버츄얼포인터1이 사용되고 있음을 나타내며, 이는 본 실시예에서 2^5=32 서로 다른 버츄얼포인터 주소 공간들까지 있을 수 있음 을 뜻한다. 나머지 25-비트는 버츄얼포인터1의 주소 공간 내 데이터 항목의 오프셋 혹은 어드레스이다.

도 32에 있는 예는 어떻게 버츄얼포인터1의 접속이 특정 주소, 0x50001에 대한 특정 장치에 대하여 다트엔진에 의해 관리되고 있는지를 구체적인 실시예로 보여주고 있다. 블록(페이지) 크기가 64K=2^16 워드이므로, 25-비트 오프셋의 상위 9-비트는 어느 64K 블록이 접속되는 데이터 값을 함유하는지를 나타낸다. 보여지는 예에서, 두 개의 실제 메모리 페이지들 중 어느 것도 그러한 블록을 현재 유지하고 있지 않고 있다. 또한, 버츄얼포인터1용 플래시 저장블록 파일들 중 어느 것도 필요로 되는 데이트 블록을 유지하고 있지 않고 있다. 이러한 파일들은 블록 100 및 101에 대한 실제 메모리 페이지들이 다른 페이지들에 의해 과거에 교환될 것을 요구했던 과거의 접속 결과이다. 다트엔진은 실제메모리를 교환하기 전에 이러한 블록들의 데이터 값들을 두 개의 플래시 메모리 파일에 자동으로 저장했다. 이러한 접근에 대한 실제 현재 데이터 값은 작동하는 다트 파일의 버츄얼포인터1 파트(Part)에 여전히 있다. 이 파트는 작동하는 다트가 데이터 값들을 이용하여 마지막으로 저장될 시에 생성되어 현재 그 버츄얼포인터1의 주소공간에 있다. 예에서 접속은 블록 101에 대한 데이터 값들이 파트내 제3영역으로부터 2개의 실제 메모리 페이지들 중 하나로 읽히는 경우에 완성된다. 만일 교환될 실제 메모리 페이지가 변화되거나 더티(dirty)한채로 데이터 마켓(data market)을 갖는다면, 새로운 플래시 저장 파일이 그 값들이 교환되기 전에 실제 메모리 페이지내 현재 값들을 저장하기 위해 기입될 것이다. 접근은 지금 실제 메모리내 0x50001 값에 대한 포인터가 접근중인 다트 명령에 의해 처리되기 위해 복귀되는 경우에 완성된다.

버츄얼 포인터들의 추가적인 형태들 및 실시예들과 다른 형태들에 관한 그들의 활용을 이제부터 설명하기로 한다. 일 실시예(1)에서, 본 발명은 (1) 물리적 메모리 및/또는 물리적 저장 장치들을 효과적으로 이용하는 소프트웨어 응용 프로그램 내에 접근가능한 다수의 대용량 독립 데이터 접근 주소 공간들을 제공하는 방법을 제공하는 것으로, 그 방법은 하나 이상의 독립 주소 공간들의 성질을 지정하는 단계; (2) 컴퓨터 프로그램 코드 소오스문(source statement)을 버츄얼 포인터 기능성을 지원하는 특정의 소프트웨어 엔진 및/또는 하드웨어 프로세서 상에 동작하기에 적합한 수행가능한 이미지로 처리하는 단계; 및 (3) 상기 수행가능한 이미지를 빠르나 접근이 제한된 크기의 주메모리 및 접근 속도는 느리나 대규모 크기의 제2 스토리지를 효과적인 방식으로 사용함으로써 주소 공간에 의해 참조된 데이터에 접근을 해결하는 명령 세트를 수행하는 특정 소프트웨어 엔진 또는 하드웨어 프로세서 상에서 작동하는 단계를 포함하여 이루어진다.

다른 실시예(2)에서, 본 발명은 하나 이상의 독립 주소 공간들의 성질을 지정하는 상기 단계가 그렇게 하기 위한 구문(syntax) 및 의미론(semantics)에 일치하는 문장들(statements)을 지원하는 컴퓨터 프로그래밍 언어를 사용하여 수행되는 것을 특징으로 하는 (1)의 방법을 제공한다.

다른 실시예(3)에서, 본 발명은 상기 처리 단계가 소오스 문장들을 특정의 소프트웨어 엔진 및/또는 하드웨어 프로세서 상에 동작하기에 적합한 수행가능한 이미지로 처리하는 소프트웨어 툴들을 동작하는 단계를 포함하여 이루어진 (1)의 방법을 제공한다.

다른 실시예(4)에서, 본 발명은 상기 효과적으로 이용하는 단계 및 상기 효과적인 방식은 적어도 다음의 것에 의해 부분적으로 수행되는 것을 특징으로 하는 (1)의 방법을 제공하며, 다음의 것은 (1) 각각의 독립적인 주소 공간에 대하여 단일의 특정 크기의 모든 실제 메모리 페이지들의 수를 생성하고 유지하는 단계; (2)다음의 과정을 이용하여, 독립적인 주소 공간내에서 논리적으로 데이터 접근이 행해지는 경우 접근을 해결하고 접근하기 위한 명령 또는 프로그램에 대한 값을 포함하는 주메모리로 값 또는 포인터를 복구하는 단계로서, 다음의 과정은 (a) 데이터가 주메모리 페이지들 중 하나에 있는지 여부를 결정하는 단계; (b) 만일 데이터가 상기 주메모리 페이지들 중 하나에 있지 아니한 경우 (i) 데이터가 제2 스토리지에 있는 지 여부를 결정하는 단계; (ii) 제2스토리지에 있지 아니한 경우 (1) 디폴트 값(defalut value)을 복구하고; (2) 디폴트값을 포함하는 주메모리 데이터 요소에 대해 포인터 대 포인터로 복구하며; 및 (3) 알려지지 않은 데이터 코드 또는 데이터에 대한 값이 알려지지 않은 다른 지시자(indicator)에 대한 접근으로 복구하는 절차들 중 하나 이상의 절차를 수행하는 단계; (c) 만일 데이터가 제2 스토리지에 있는 경우, (i) 실제 메모리 페이지를 선택하여 필요한 데이터 값을 포함하는 데이터의 블록을 유지할 어드레스를 시작하는 단계; (ii) 선택된 실제 메모리 페이지가 더티(dirty)로 표시된 경우 기입하거나 선택된 실제 메모리 페이지 내 값들이 제2 스토리지에 기입되게 하는 단계; (iii) 독출하거나 실제 메모리 페이지와 동일한 크기 및 동일한 새로운 시작 주소를 갖는 실제 메모리 페이지로 주소지정 가능한 데이터의 연속 범위를 로딩하는 단계; (iv) 더티(dirty)가 아닌 것으로 실제 메모리 페이지에 데이터를 표시하는 단계; 및 (v) 선택된 주메모리 페이지내의 데이터 값을 복구하거나 선택된 주메모리 페이지 내 데이터로 포인터를 복구하는 단계; 데이터가 주메모리 페이지들 중 하나에 있는 경우 (i) 만일 접근이 상기 값의 소비자가 데이터 값을 변화시킬 수 있음을 나타내는 어느 것에 알려진 경우, 상기 주메모리는 더티로 표시되는 단계; 및 데이터 주메모리 페이지의 값을 복구하거나 데이터를 포함하는 것으로 밝혀진 주메모리 페이지 내 데이터로 포인터를 복구하는 단계를 포함하여 이루어진다.

다른 실시예(5)에서, 본 발명은 데이터가 실제 메모리 페이지에 있지 아니하고 제2 스토리지에 있지 아니한 경우 제2스토리지로부터의 데이터로 선택된 실제 메모리 페이지를 로딩하는 대신 디폴트 값으로 선택된 실제 메모리 페이지를 채우는 것을 제외하고는 데이터가 제2 스토리지에 있는 것처럼 진행되는 것을 특징으로 하는 (4)의 방법을 제공한다.

XXIII . 예제 응용 및 응용 시나리오

A. 중성미자 검출기 ( Neutrino Detector )응용 예

도 21을 참조하면, 다트인스트럭션세트의 OEM_BUILTIN-INSTRUCTION의 사용을 통해 어떻게 다트플랫폼이 이동 전화기가 초기에 중성미자 검출기(3500)의 존재 및 특성에 대한 지식이 없을 때 조차도 이동 전화기 다트디바이스(3600)에 의해 발견될 수 있고 사용될 수 있는 새로운 유형의 다트디바이스, 가정용 중성미자 검출기(3500)의 고유한 기능을 만들어내도록 사용될 수 있는지가 본 발명의 실시예의 예로 도시되어 있다.

가정용 중성미자 검출기(3500)는 오늘날 이론적으로만 존재하는 장치이나, 존재한다고 하더라도 그러한 장치와 상호운용하기 위한 기존의 표준은 존재하지 않는다고 인식될 것이다. 그러나 비록 이런 장치의 기능에 대한 기존의 표준 또는 지식이 이동 전화기 다트디바이스(3600)의 제조자에게 알려지지 않다고 하여도 다트 플랫폼은 중성미자 검출기(Neutrino Detector, ND)가 다른 다트디바이스들, 이 경우에는 이동 전화기(3600)와 상호운용이 가능하게 하는 방법들을 제공한다.

ND의 제조자는 미라벨라 전자회사(Mirabella Electronics)에 의해 생성되고 사용되어진 OEM기능들이 다른 모든 제조자들에 의해 생성되고 사용되어지는 그것들과 구별하도록 기호(symbol)인 MIRABELLA_ELECTRONICS_ID에 할당된 유일한 id를 할당 받은 미라벨라 전자회사이다. 미라벨라는 다트디바이스와 상호운용가능한 자신의 장치를 가지고자 하며 ND상에 동작하는 다트플레이어의 일부로서 다트엔진을 이식하였다. 5초의 주기 내에 검출기를 통과하는 중성자의 수를 샘플링하는 장치의 유일한 능력을 밝히기 위해, 자체 내장된 기능인 수집을 야기하고 검출기를 통과한 중성미자들의 수를 반송하는 콜렉트샘플(CollectSamples)이 HAL의 OEM(<oemld>,<subfunction>) 방법으로부터 요구된다. 이어서, 미라벨라 전자회사가 다트소오스 및 다트툴을 사용하여 제어 패널용 사용자 인터페이스를 표시하는 R1 렌디션 및 샘플링이 발생하는 것을 알리기 위해 따로 남겨둔 다트 특정 이벤트들을 처리하는 R0 렌디션을 포함하는 제어 패널 다트를 생성한다.

사용자 인터페이스 능력을 구비한 모든 다트디바이스는 다트들이 다른 다트 디바이스들과 그 제어 패널 다트들을 공유하고자하는 도달할 수 있는(reachable) 다트디바이스들에 존재함에 따라 구현되는 모든 제어 패널들을 찾기 위해 사용되도록 보통 그에 내재하는 겟콘트롤패널 다트(GetControlPanel Dart)와 함께 실릴 것이다. 겟콘트롤패널 다트가 이동 전화기(3600)에서 시작되면, 통신 프로토콜 중 어떤 것에 의해 도달할 수 있는 모든 장치들 상에 동작하게 될 겟콘트롤패널리스트 다트프로시쥬어를 전송한다. 이 경우 이동 전화기는 양 장치에 공통적인 블루투스(Bluetooth) 프로토콜을 사용하여 통신 세션을 찾아서 수립하게 되며, 이어서 다트프로시쥬어를 런프로시쥬어(RunProcedure)형 이벤트의 일부로서 다트프로시쥬어를 동작시키는 중성미자 검출기에 전송한다. 다트프로시쥬어는 다트디바이스의 다트인스트럭션세트의 일부인 내장된 명령들의 사용을 통해 ND상에 수행되는 경우 이름과 기재사항들의 목록 및 콘트롤패널 다트의 유일 id를 수집한다. ND상에 존재하는 유용한 제어 패털 다트의 이름 및 기재사항은 이동 전화기로 다시 전송되며 사용자에 의한 선택을 위해 겟콘트롤패널 다트에 의해 표시된다. 이동 전화기 상의 리스트로부터 제어 패널을 선택한 후에, 이벤트는 유일 id에 의해 식별된 콘트롤 패널 다트가 ND상에 수행을 시작하고 수립된 통신 세션에 걸쳐 이동 전화기를 모집하는 것을 요청하기 위해 전송되는 데, 이는 전화기 상의 겟콘트롤패널 다트를 리쿠르팅 ND 콘트롤패털 다트의 동작하는 R0 렌디션에 의해 전송된 동작하는 R1 렌디션으로 자동 교환한다.

그런 후에 R1 렌디션은 이동 전화기 화면에 커다란 초록 샘플 버튼을 표시한다. 사용자가 그 버튼을 선택하면, R1은 샘플이 취해지도록 요청하는 동기화를 위 한 표지된 이벤트를 생성한다. 이벤트는 자동으로 다트런타임에 의해 팀으로 된 ND의 이벤트 대기열(queue)로 전송되며, 그 결과 OEM_BUILTIN_INSTRUCTION을 사용하여 이벤트의 처리가 다트엔진이 미라벨라 전자회사에 의해 할당된 파라미터를 갖는 할오이엠()(halOEM())방법을 요청하게 하여 콜렉트샘플()(CollectSamples()) 고유의 장치 기능을 유발하고 halOEM() 방법의 요청자에게 다시 엔진에 의해 수행중인 R0 렌디션으로 다시 보내어지는 샘플의 수를 회송함으로써 샘플링을 수행하게 된다. R0가 이어서 동기화를 위해 표지된 샘플표시수 유형 이벤트(DisplayNumberOfSamples type event)를 그 대기열 상에 배치하도록 요청하며, 그 결과 팀으로 된 이동 전하기의 대기열 상에 샘플표시수 유형 이벤트을 배치하게 된다. 그런 다음, 이동 전화기 상에 동작하는 R1 렌디션은 이벤트를 처리하고 샘플표시수 유형 이벤트의 파라미터 내 운반된 검출 중성미자의 수를 화면에 표시한다.

따라서, 도 21의 예는 유일 장치들의 존재, 특성 또는 능력들에 대한 사전 지식 없이도 매우 유일한 장치들의 능력 및 제어를 밝히고 다트디바이스들에 까지 확장하기 위해 유익하게 사용될 수 있음을 증명하고 있다.

상기 예 및 기재들로부터의 중요한 점 몇 가지는 다음과 같다.

첫째, 그 유일한 목적이 표준 위원회에 의해 고려될 수 없는 장치는 다트디바이스(400)가 될 수 있었으며 다른 장치가 다트디바이스(400)이 되는 것과 같은 동일한 정도의 개발노력을 요구하였다.

둘째, 이러한 새 장치는 이런 유형의 어떠한 장치가 존재하기 전에 존재했던 다른 장치들에 대해 유일한 하드웨어 능력을 쉽게 밝혀줄 수 있다. 이전에 존재하 던 다트디바이스(400)는 그 작용을 조절하면서 새롭고 유일하며 어떤 장치에게도 이전에 알려지지 않았던 새로운 장치와 상호운용가능하다.

셋째, 중성미자 검출기(3500)을 다트디바이스(400)으로 하기 위해 요구되었던 개발노력은 다른 장치들에 대한 추가적 작업 없이, 비록 이러한 장치들이 기술이 밝혀지기 전에 존재했더라도, 다른 장치를 다트디바이스(400)으로 하기 위한 것과 유사하다. 즉, 종래의 상호운용성 방법을 사용할 시 N 제곱으로 상승하던 개발 노력이 다트플랫폼으로 구현된 방법을 사용하여 실현할 경우 N차수 노력으로 족하다는 것이다. 다트애플리케이션의 렌디션은 동일한 원래의 다트로부터 다른 렌디션들과 통신을 하기 때문에, 상호운용성 요소들을 분리하여 실행하고 분포해야할 필요가 있었으며 불일치에 직면하기 매우 쉬웠던 종래의 상호운용성에 비해 고도의 신뢰성을 얻게 된다.

B. 슬리이드 쇼 응용 예-사용을 통한 발전 단계들

지금부터, 슬라이드 쇼 다트 애플리케이션을 근본적인 예의 응용으로서 이용하여 사용을 통한 발전을 기재하는 실례의 내용에 예시적인 시스템, 방법, 컴퓨터 프로그램 및 그들의 요소들(components)을 보다 상세히 설명하기로 한다. 이러한 슬라이드 쇼의 예는 단지 설명을 하기 위한 목적일 뿐이며 한 번에 한 장치 상에서, 순차적으로, 많은 장치 상에서 동시에 혹은 병렬적으로, 또는 이와는 다르게 동일한 기술이 어떤 장치 혹은 장치들의 세트 상에 동작할 필요가 있는 하드웨어와 서로 작용하거나 이용하거나 제어하는 소프트웨어 응용들을 포함한 어떠한 소프트 웨어 응용에도 사실상 유익하게 채용될 수 있음이 이해될 것이다.

본 실시예에서, 다트소오스(도3의 100) 파일(C++) 및 클래스 정의(class definitions)의 다트프레임워크(도3의 102) 및 알고리듬을 표현하기 위한 선택적인 기초 및 상호운용성 애플리케이션 구축에 필요한 코드로서 사용되도록 설계된 소오스코드(도 3의 101)

도 3을 참조하면, 예시적인 슬라이드 쇼 다트 애플리케이션은 도 3의 100의 도트소오스 파일로 시작한다. 애플리케이션 코드(101)은 일반적으로 표준 C++ 언어와 일치한다. 슬라이드쇼 다트 소오스(100)도 다트프레임워크(102)를 표현하는 표준 C++ 소오스 파일들을 포함한다. 다트프레임워크(102)는 클래스 정의의 세트이며 알고리즘을 표현하기 위한 선택적 기초로서 사용되도록 설계된 코드이고 상호운용성 애플리케이션을 다트포맷(300)로 하도록 구축하기 위해 필요한 코드이며 다트런타임(8000, 도 15 참조)과 일치한다.

다트소오스(100)로부터 다트 엔진 기능들로의 요청은 다트인스트럭션세트의 일부인 BUILTIN_INSTRUCTION (도 20의 670)을 통해 이루어진다. C++ 소오스 코드로부터 엔진 기능들로의 요청은 다트다바이스 (400, 도 4 참조) 상에 동작하는 특정 장치인 다트플레이어(500)의 일부인 독립된 장치 다트엔진(600)에 의해 수행되는 다트인스트럭션세트의 일부인 BUILTIN_INSTRUCTION (670, 도 20 참조)이 발생된 컴파일러(201)를 통해 이루어진다.

확장은 C++ 언어에 유익하게 확장되어 많은 유형의 리소스들(103)이 애플리케이션 코드(101) 및 다트프레임워크(102) 내부에서부터 참조될 수 있다. 이는 특 별하게 명명된 내재된 기능들, 특별하게 명명된 데이터 구조들 및 다트 컴파일러(201)에 의해 인식되는 키워드들을 갖는 #프래그마 확장들에 의해 행해진다.

리소스들은 어떤 유형의 데이터 또는 코드 또는 데이터에 대한 참조 또는 파일 시스템(도 22의 612, 도 27의 5100, 도 28의 5000 및 도 20 참조)을 경유하는 다트툴(200)에 의해 동적으로 생성되며 도달 가능하거나 혹은 파일 내 어느 곳에나 위치하는 코드 또는 어떤 형태의 네트워크 접속, 무선 접속 또는 어떤 형태의 통신을 포함할 수 있다. 슬라이드 쇼 응용의 예를 들면, 리소스들(103)은 예를 들어 JPEG형태의 배경 이미지 파일, PCM 형태의 사운드효과 파일, 및/또는 어떠한 화상 슬라이드 또는 이미지, 비디오, 텍스트, 기호, 또는 심지어 완전한 디폴트 선전 슬라이드로서 포함되는 다트파일들(700)을 포함할 수 있다. C++언어로 프래그마 확장은 메인코드(2103) 및 메일데이터(2102)에 포함되기보다는 기능들이 다트프로시쥬어(4000, 도 14 참조) 또는 파트(303)로 자동으로 만들어질 다트툴(200)에 대해 식별하기 위해 사용되어 질 수 있다. C++ 언어로의 파트넘버() 내재된 기능 확장은 기능에 대해 파라미터들로 사용되거나 다트인스트럭션세트의 부분인 빌드인 명령(buidin instructions)으로 사용되는 경우 파트를 참조하기 위해 사용되는 파트아이디(partId) 32-비트 값이 생성된 컴파일러(201)를 얻기 위해 소오스 코드에서 사용되어 질 수 있다.

다트프레임워크(102, 도 3 및 도 11 참조)는 클래스 지정(specification) 및 수행(implementation)의 계층(hierarchy)을 유익하게 포함한다. 중요한 기초 클래스의 하나는 기즈모(Gizmo, 115) 클래스이다. 기즈모들(115)는 단일의 기능의 처리 장치를 캡슐화 하는데 사용되어 질 수 있다. 기즈모(115) 유도된 계층들은 셋업()(Setup()) 및 프로세스()방법들을 포함하며 부모(parent) 기즈모 및 자식(child) 기즈모의 목록을 참조한다. 이러한 참조들은 선택적으로는 무의미한 참조들일 수 있다.

렌디션 114 클래스들은 기즈모 클래스로부터 물려받게 되며, 애플리케이션에서 다른 렌디션 114와 독립적으로 로딩되고 동작하는 애플리케이션의 일부에 대한 시작점으로 역할하도록 설계된다.

마스터렌디션 (MasterRendition, 113) 클래스는 렌디션 114 클래스로부터 물려받는다. 이는 마스터다트(230, 도 12 참조)에서 활성화된 렌디션 뿐이다. 마스터다트(230)은 바이너리(binary) 다트포맷(300) 혹은 단일 마스터렌디션 단계를 우선적으로 포함하는 다트툴(200, 도 3 및 도 12 참조)로부터의 이미지 출력이다. 유익하게, 마스터다트(230)는 소오스코드에 참조된 모든 코드, 데이터, 콘텐트, 프로시쥬어 및 리소스들을 포함할 수 있으며 마스터플레이서(203)에서 플레이될 때 자동으로 로딩된다. 마스트다트(230)을 로딩한 후, 주(main()) 입력 포인트의 시작 전에 동작해야하는 C++ 구성자 방법을 수행한다. 마스터 렌디션(113)의 메인(Main)() 방법은 마스터다트(230)에 대한 논리적 시작점으로서 역할한다.

도 12는 다트소오스(100)이 다트툴(200)으로 입력되는 실시예를 보여준다. 컴파일러(201)는 다트소오스를 다트인스트럭션세트로 한번에 하나의 파일을 오브젝트들(Objects, 200)으로, 그리고 이 오브젝트들의 집합을 라이브러리들(Libraries)로 변환한다. 이와는 달리, 이러한 라이브러리들은 라이브러리 툴(librarian tool) 에 의해 생성될 수 있다. 오브젝트들 및/또는 라이브러리들(220)은 다트마스터 및 다트 애플리케이션에 대해 다트소오스(100)의 리소스(103)로서 역할을 할 수 있다. 컴파일러(201)의 동작, 선택적 라이브러리 툴 및 링커(202)는 일정한 중요한 다른점들을 제외하고는 일반적으로 현재 사용중인 종래의 C++ 컴파일러, 라이브러리 및 링커의 그것들과 유사하다. 몇몇 이러한 차이점들은 다음을 포함한다.

첫째로, 타겟 명령 세트는 다트인스트럭션세트로부터이다. 둘째로, 수행가능한 출력은 실제 목표 타겟 장치들을 목표로 하기보다는 마스터플레이어(203) 상에 수행하기 위해 의도된 마스터다트(230)이고; 마스터다트 및 마스터플레이어는 본 발명에 독특한 요소들을 나타낸다. 셋째로, 사용 후에 보통 버려지는 종래의 컴파일러, 라이브러리안 및 링커들의 동작하는 동안 발생하는 많은 클래스 정의 및 연결 구조들(linkage structures)은 마스터플레이어에 의해 사용되기 위해 마스터다트에 보존된다.유지되는 클래스 정의 및 연결 구조들은 또한 종래의 컴파일러, 라이브러리안 및 링커들에 일시적으로 존재할 수 있는 그것들과는 다르다. 넷째로, 다트툴(200)은 (i) 수행하는 동안 필요할 런타임 리소스 요구사항들을 지정하고 자동으로 수집하기 위해; (ii) 파트(303, 도3 및 도 13)로서 리소스(103)의 마스터다트에 포함되기 위해서; 그리고 응용 프로시쥬어에 의한 사용을 위해 다트툴(200)에 의해 할당된 리소스의 식별자로 역할하는 파트 넘버를 제공하는 파트넘버() 소오스 코드 기능을 위하여 소오스 언어로의 확장을 처리한다.

다른 발명은 다트툴들에 의해 출력된 결과의 마스터다트들 및 다트들이 필요한 바와 같이 이러한 렌디션을 구성하기 위해 다트 및 마스터다트 이미지에서 가능 한 공유 파트들을 구성하는 데 필요한 어떤 수의 렌디션들 및 정보를 포함할 수 있다는 것이다. 또 다른 발명은 다트툴들에 의해 출력된 결과의 마스터다트들 및 다트들이 장치들의 애드혹(ad-hoc)팀들을 지적으로 수립하기 위해 모집을 수행하고 이어서 다트런타임에 따라 애플리케이션의 의도를 수행할 필요가 있는 프로시쥬어, 데이터, 코드 및 콘텐트를 포함할 수 있다는 것이다.

링커(도 12의 202)는 오브젝트/라이브러리(220)를 다트포맷(300, 도3)에 일치하는 단일 바이너리 이미지로 결합하고 패키지한다. 이러한 이미지는 다트마스터(230)이다. 다트마스터(230)는 다트엔진(500, 도 22 참조)을 포함하는 마스터플레이어(203) 상에 동작하도록 의도된다. 이러한 다트엔진(500)은 기호 테이블 파트들(2100, 도 13 및 14 참조)을 이용하는 다트엔진 시스템 기능들을 요청하기 위한 몇몇 빌트인인스트럭션(BuiltInInstruction, 도 25 및 20 참조) 서포트(support) 및 컴파일러(201) 및 링커(202)에 의해 생성된 메타-데이터 부분들(meta-data parts)를 포함한다. 이러한 기능들은 예를 들어 리소스들(103)의 수집, 데이터의 초기화, 파트(2100)의 조립 및 파트(2200)의 다트(700)로 혹은 다트(700) 세트로 부분화를 돕기 위해 마스터다트 내 코드에 의해 사용될 수 있다. 이러한 기능들은 또한 코드의 크기를 줄이거나 파트(2100) 및 생성될 다트 혹은 다트들 내 필요한 데이터에 의해 코드의 처리효율을 증가시키는 데 도움을 줄 수 있다.

마스터다트는 다트포맷(300, 도 3 참조)과 일치하지만, 렌디션 테이블(2101)에서 파트아이디(PartId)에 의해 참조된 오직 하나의 렌디션 테이블(2104)를 갖도록 제한될 수 있다. 파트아이디들은 다트(700)내에서 파트(도 12의 303)에 대한 참 고로서 사용되는 정수 값의 식별자들이다. 일 실시예에서, 파트아이디들은 32-비트이지만 16-비트, 24-비트, 40-비트, 48-비트, 64-비트 혹은 어떤 다른 수의 비트와 같이 다른 비트 수를 갖는 식별자들이 사용될 수 있다. 일 실시예에서, 오직 한 마스터렌디션 오브젝트 단계가 다트소오스에서 허용된다. 다트툴(200)은 마스터렌디션(113) 오브젝트 단계의 초기화를 위한 소오스 코드 내 정보 및 렌디션테이블(2101) 기록 내부의 파라미터들을 초기화하는 것을 참조하는 데이터 구조들을 사용한다. 마스터렌디션(113) 단계에 대응하는 렌디션테이블(2101) 기록의 몇몇 파라미터들은 다트툴(200)에 의해 자동으로 채워질 수 있다. 이러한 렌디션테이블 파라미터들은 이벤트 및 파일들의 수와 렌디션(114) 오브젝트 단계가 처음으로 로딩되고 다트플레이어(500)에 의해 작동 준비가 된 경우에 초기에 할당되어야 하는 힙 메모리(heap memory)의 양을 포함한다. 어떠한 다트(700)가 어떠한 다트플레이어(500) 상에 동작할 수 있기 전에, 다트디바이스(400) 상에 동작하는 다트플레이어(500)의 다트엔진(600)은 먼저 유리하게 렌디션을 선택하고 로딩해야 한다.

다트엔진(600)주변에 디바이스 특정 애플리케이션 수행가능한 셀 (device specific application executable shell)을 제공하는 다트플레이어(500)는 동작할 렌디션 파트아이디를 지정할 수 있고 또는 일 실시예에서 위법 파트아이드임을 지시하는 것으로서 "0"을 지정할 수 있다. 만일 0이 지정되면, 다트엔진은 렌디션테이블(2101)의 첫번째 기록의 파트아이디를 갖는 렌디션(114)을 로딩할 것이다.

렌디션 테이블을 찾기 위해, 다트엔진(600)은 일 실시예에서 다트(700)파일내 마지막 4개의 32-비트 워드인 트레일러(Trailer, 305)를 먼저 로딩해야한다 (도 3 참조). 트레일러(305)는 다트(700) 파일의 첫머리로부터 파트테이블(304)의 오프셋을 포함한다. 파트테이블레코드(314, 도 14참조), 파트테이블(304)에서 각각의 기록은 연속적인 파트(303)의 이미지가 다트(700)파일에서 발견되는 다트(700)의 첫머리로부터 시작오프셋 및 종료오프셋과 함께 32-비트 파트아이디와 같은 파트아이디를 포함한다.

하나의 렌디션체이블(도 13의 2101)만이 다트포멧(300) 파일에서 보통 허용될 수 있으며, 렌디션테이블(2101) 부분에 해당하는 파트테이블레코드(314)를 찾기 위하여 엔진에 의해 사용되는 영구의 할당된 파트아이드 값을 갖는다. 파트테이블레코드(314)에서 오프셋들은 렌디션테이블(2101)을 찾기 위하여 사용되고, 렌디션테이블 기록들은 그 기록의 파트아이디에 의해 참조되는 렌디션에 의해 필요한 메인데이터(2102) 및 메인코드(2103) 내에 있는 선형 세그먼트들에 관한 정보를 포함한다. 렌디션테이블(2101)은 또한 그러한 렌디션(114) 단계에 대한 수행을 시작하기 위하여 시작 코드 이미지 주소를 포함한다. 렌디션테이블(2104) 기록들은 우선적으로 렌디션(114) 단계에 속하는 부분의 파트아이드를 유지하는 모두 단지 하나의 32-비트 워드이다.

본 발명의 일 실시예에서, 몇몇 단계들은 다트(230)을 다트플레이어(203)에 로딩시키는 것과 관련되어 있다. 다트와 다트플레이어 각각에서 구체적인 실례인 바와 같이 동일한 단계들이 마스터다트를 마스터플레이어에 로딩하기 위하여 사용된다. 이러한 단계들은 선택적이나 유익하게 수행되는 단계들을 포함하는 다음의 단계들을 포함한다.

단계 1. 애플리케이션 개발 장치(900) (도 12 참조) 상의 다트플레이어(203)는, Rendition PartId를 영(0)값으로 시작하도록 명시하는 파라미터를 가지는 다트 엔지(600)의 lnit() 방법(도 24의 6000, 도 23의 4002)을 호출한다.

단계 2. 그런 다음, 다트엔진(600)은 다트(230) 파일의 끝부터 트레일러(trailer)를 읽고, 파트데이블(304)의 옵셋을 추출한다.

단계 3. 기록을 모든 렌디션 테이블들의 PartId에 대한 미리 할당된 고정값과 함께 찾을 때까지, 파트테이블(304)의 각 기록을 읽는다. 고정값 PartId를 가지는 단 하나의 렌디션 테이블이 모든 DartFormat 이미지에서 허용된다.

단계 4. 그런 다음, 다트엔진(600)은 렌디션 테이블(2101)의 startOffset과 endOffset을 추출하고, startOffset과 endOffset을 사용하여 첫 번째 렌디션 테이블 기록을 읽는다.

단계 5. 첫 번째 렌디션 테이블 기록을 읽고 힙(heap)과 스택(stack)에 메모리를 할당할 파일과 이벤트의 수 및 할당할 공간의 양과 같은 초기 런타임(runtime) 파라미터를 추출한다. 렌디션 테이블(2104) PartId도 추출한다.

단계 6. 렌디션 테이블 PartId를 사용하여 이 PartId에 대한 파트테이블(304)로부터 렌디션 테이블(2104)의 startOffset과 endOffset을 찾는다.

단계 7. 그런 다음, 렌디션 테이블(2104)의 각 기록을 읽는다. 일실시예에서, 각 기록은 렌디션에 속하는 파트의 PartId를 가지는 단 하나의 32비트 워드이다. 각 파트테이블레코드(314)는 로드시간에 발생하는 것을 관리하는 플래그와 파라미터를 포함한다. 예를 들어, 파트가 콘텐츠타입, 파라미터 0, 파라미터 1, 및/ 또는 파라미터 2 값들에 따라 또는 다른 파라미터 또는 조건에 따라 소정의 방식으로 처리되어야 할 경우 플래그가 있을 수 있다. 메인데이터 및 메인코드 파트들은 렌디션이 수행하기 전에 필요한 코드 및 데이터를 메모리에 위치시키기 위하여 로딩시 처리되어야 하는 파트들의 예로서 메인데이터 및 메인코드 파트가 있다.

단계 8. 요구되는 메인코드(2103) 파트테이블레코드(314)를 찾으면, 콘텐츠타입은 메인코드(2103) 콘텐츠타입에 할당된 고정값을 유지하며, 플래그 파라미터 워드의 오토-로드(Auto-load) 플래그 비트는 설정되어야 하며, 파라미터 0 및 파라미터 1은 메인코드(2103) 파트에 포함된 첫 번째 및 마지막 다트명령셋(DartInstructionSet) 코드 이미지 어드레스를 유지할 것이다. 널리 이용가능한 C++툴로부터 출력되는 대부분의 실행가능한 이미지들이 동일한 고정된 옵셋에서 항상 시작하는 코드 이미지의 결과를 낳게 되지만, 이것은 일반적으로 다트의 경우는 아닐 수 있다. 왜냐하면, 렌디션에 필요한 선형의 인접 영역들만이 마스터다트(230)의 실행 또는 백업을 위한 다트의 렌디션의 세트의 소정의 결과로써 출력되거나 다른 팀으로된 장치(another teamed device)로 보내지기 때문이다. 즉, 다트 코드 이미지는 동일한 고정된 옵셋에서 항상 시작하는 것은 아니며, 크리에이션이즘(Creationism) 또는 SAVE_INSTRUCTION 또는 save BUILTIN_INSTRUCTION의 사용을 통해 마스터다트(230) 또는 다트로부터 출력된 렌디션에 필요한 선형의 인접 영역들만 일반적으로 존재할 수 있다. 유익하게도, 다른 다트들을 형성하는 다트(700)는 생성된 다트에서 실제로 렌디션에 필요한 다트툴들(200)에 의해 출력된 원래의 코드 또는 데이터의 선형적인 인접하게 어드레스된 섹션들만 포함한다. 예를 들어, 마스터다트(230)의 정적 생성자 코드(static constructor code)가 로드 프로세스의 일부로서 구동되기만 하면, 생성자 코드는 마스터다트(230)를 작동시키는 동안 생성된 다트에서 공간을 차지할 필요가 없다. 이것은 생성된 다트가 마스터렌디션(Master렌디션)(230)을 일반적으로 포함하지 않기 때문이다. 마스터다트(230) 또는 다른 다트의 실행에 의해 생성된 다트 파일들의 메인데이터(2102) 파트의 데이터에도 동일하게 적용된다.

단계 9. 콘텍스트(Context) 구조 또는 콘텍스트 객체의 경우를 위한 메모리는 로딩중인 다트와 관련된 메모리, 접근 권한, 및 상태를 기록하도록 할당된다. 고유 contexId 값은 동일한 다트엔진(600)에서 구동할 수 있는 다트의 코드 또는 다른 다트들에 의해 호출을 위한 글로벌 레퍼런스로써 사용되도록 생성된다. 콘텍스트의 플래그들은, 특정한 구동중인 다트의 데이터, 다트힙, 또는 다트스택으로써 명백하게 할당된 메모리로의 다트 코드의 접근을 제한할 것이다. 또한, 콘텍스트의 플래그 값으로 나타난 바와 같이, 이러한 다트의 일부 또는 다트엔진 환경이 아니며, 또는 접근권한이 성립되지 않은 기능들, 메모리 또는 파일들에 접근하려는 노력들은 다트엔진 프로세스 호출(4003)로부터 음의 에러 리턴 코드들에서 일실시예가 나오며, 이는 불법 접근 위반이 발생하기 전에 다트의 실행을 종료시킨다.

단계 10. 환경적 초기 메모리는 파트테이블레코드(314)의 파라메터들에서 표시될 필요가 있으며, 렌디션테이블 기록들을 추출한다. 엔진이 유지된 EventInfo 구조, FileInfo 구조, 또는 CommSessionInfo 구조 중 어느 하나에 메모리를 할당하거나 재할당할 필요가 있을 경우, 또는 로딩될 다트의 예상된 실행에 필요한 다른 자원들이 있을 경우, 할당, 재할당, 초기화 등을 실행하여, 동일한 다트엔진 상에서 작동하는 Contexts, DartProcedureContexts, 및 DartIdleContexts가 공유하는 DartContext 및 DartEngine 환경을 준비한다.

단계 11. 서브파일(698)(도 26 참조)와 같은 서브파일은 우선적으로 열어 읽음으로써, 다트포맷(300) 이미지 파일의 파트들이 데이터를 개별 파일로 복사할 필요가 없이 독립된 파일인 것처럼 처리하고 실행한다.

유리하게도, 다트플랫폼(50)은 독특한 파일 시스템을 사용한다. 파일 시스템은 다트 코드에서 파일을 참조하는 데 또는 데이터를 읽고, 패스하고, 쓰거나 공유하려고 할 때 사용될 수 있는 파일 식별자 (필드) 값에 첨부된 파일 추상화(abstraction)를 생성하도록 처리된다 (612)(도 26 참조).

몇몇 빌트인인스럭션(BuiltinInstruction) (670) (도 20 참조) 운용 코드값들은 읽기, 쓰기, 열기, 닫기, 이름바꾸기, 및 위치 동작에 사용될 수 있다. 일대일 방식으로 각 필드와 관련된 FileInfo 구조는 현재 저장장치 위치, 파일로의 현재 포인터의 위치 등뿐만 아니라 저장장치 타입 및 형태, 특성 및 접근권한을 추적한다.

유리하게도, 다트디바이스(400) 상에서 동작할 필요가 있는 작은 세트의 기능들로 다트엔지(600)의 포터블 파트를 맵핑하는 장치 특정 halBase 오브젝트는, 실제 개별적 물리적으로 저장된 파일들의 것들과 관계없는 대부분의 동작은 도 26에 도시된 다트엔진에서 포터블 코드에 의해 가상화(vertualize)된기 때문에 작고 단순하게 유지된다.

파일들을 처리하기 위하여, HAL의 읽기, 쓰기, 열기, 닫기, 위치, 겟포지션(getPosition), 이름바꾸기, 및 삭제 방법들은 다트엔진(600)을 새로운 다트디바이스(400) 포트하도록 구현하는 데 필요하다. 다트엔진(600) 구현의 포터블 부분은 할당된 메모리(697)(도 26 참조)에 보유된 파일들 또는 다른 파일들의 서브파일들을 위한 파일 접근 추상화를 구축한다. 일단 서브파일을 열면, 서브파일은 다른 파일과 같이 읽혀질 수 있으나, 데이터의 소스 및 경계는 실제로 이전에 열었던 다른 파일의 적절한 부분집합이다.

유리하게도, 소스 파일들이 서브파일 전에 닫히더라도 서브파일은 동작상태로 유지된다. 실행을 위해 다트의 코드를 읽기 위한 서브파일을 사용하면, 코드가 적절하게 실행되기 때문에, 코드를 파일로부터 메모리로 로딩할 필요가 없다. 이는 다트가 롬(ROM)에 있거나 또는 다트디바이스의 파일 저장장치가 느린 하드디스크 드라이브와 같은 것보다는 빨리 읽을 수 메모리 장치로 구현될 때 특히 유리하다.

실행속도를 향상할 필요가 있거나 요구될 때, 실행할 렌디션과 관련있는 다트의 코드 위치은 다트콘텍스트를 위한 코드의 유지 및 실행을 위해 현재 할당된 메모리로 로딩될 수 있으며, 메모리 파일(도 26의 697) 또는 그의 균등한 기능성은 실제 다트코드를 실행하는 데 사용될 수 있다.

단계 12. 여기서 설명한 특히 유리한 실시예 및 구현에서, 초기 생성자를 여전히 포함할 수도 있는 마스터다트(230) 또는 다른 다트(700)를 위해 다트툴(200)에 의해 생성된 다트코드는 main()함수를 호출하기 전에 호출되어야 하는 초기 생성자 절차에서 실행을 시작할 수 있다. 실행을 시작할 코드 어드레스는 렌디션 인 스턴스에 해당하는 렌디션 테이블의 32-비트 워드들 중 하나에 있다.

단계 13. 다트툴(200)은 빌트인인스럭션(659)을 서브함수 값을 가지는 초기 생성자의 끝에 자동적으로 놓아, DartEngine.Process 방법(4003)이 처음으로 호출되면 마스터다트(230)의 연속적인 실행을 위해 다트엔진이 시작 실행 어드레스 및 이러한 오브젝트 인스턴스 포인터를 설정하도록 한다.

이는 본 발명에 따른 방법 및 컴퓨터 프로그램의 특정 실시예에 따른 다트의 생성 및 로딩에서 마지막 단계(단계 13)이다.

다트의 동적 생성 및 다트 프로시져 - 크리에이션이즘

다트 및 그 파생 다트에 의해 다트의 연속적인 동적 생성 및/또는 다트 프로시져를 위한 능력은 다트플랫폼(50) 및 다트 기술에 근거한 시스템 및 방법의 더 력한 특성들 중 하나이다. 다트플랫폼(50)의 실시예들은 이전 다트들로부터 다트의 연속적인 효율적 생성을 지원하도록 시스템에 전체에 걸쳐 설계되고 구성된다. 이를 위한 방법을 크리에이션이즘이라 부른다.

예를 들어, C++ 확장을 사용하여, 다트소스(100)는 원래 마스터다트(230)로부터 생성되거나 다른 다트툴에 의해 직접적으로 생성된 다트에서 렌디션의 생성시 혼합되고, 매칭되고, 공유될 수 있는 파트들을 위한 스펙을 포함할 수도 있다.

다트프레임워크(102)의 실시예들은 렌디션과, 각 렌디션에 포함될 모든 코드, 데이터 및 파트들을 구체화하기 위한 메커니즘 및 방법을 전적으로 제공한다. 이는 다트 및 다트프로시져(4000)의 동적 생성을 위해 필요한 코드, 데이터 및 자 원의 섹션의 효과적인 데이터베이스를 형성하도록 다트툴(200)이 컴파일러(201) 및 링커(202)에 의해 생성된 오브젝트들의 의존 트리를 통해 분석하도록 한다. 유사한 방식으로, 마스터플레이어(203)는 어떠한 시작점 세트에 대해서도 실행시간에서 도달가능한 모든 데이터, 코드, 방법 및 기능을 통해 추적할 수 있고 따라서 필요한 데이터, 코드 및 필요한 자원들만 포함할 수 있는 다트들을 생성하는 데 필요한 정보를 유리하게 형성할 수 있다. 도달할 수 없는 데이터, 코드 및 콘텐츠는 포함된 렌디션 시작점들과 데이터값에 근거하여 다트포맷 이미지로부터 자동적으로 배제된다.

필요한 코드 및 데이터의 양을 제한하는 데 유리하게 사용될 수도 있는 다트플랫폼(50)의 다른 메커니즘은 다른 다트(700) 또는 다트프로시져(4000)를 생성할 때 작동중인 다트의 전체 또는 선택된 데이터 상태의 자동저장 및, 상기 열거한 바와 같이 다트엔진의 다트 로딩 단계의 일부로써 전체 또는 선택된 데이터 상태의 자동 리로딩이다. 작동중인 다트의 데이터값과 콘텐츠가 다트포맷 이미지 자체의 일부이기 때문에, 작동시 쉽게 저장되고 복원되어, 다트플랫폼(50)이 최적화되고 의도한 사용자 중심 애플리케이션의 종류들 중 많은 것을 종종 구성하는 초기 생성자 및 셋업 코드가 생성된 다트에서 일반적으로 필요없다. 예를 들어, 마스터다트(230)가 먼저 로딩되면, 실행 전에 호출된 많은 생성자가 main() 함수에서 시작하도록 설정된다. 이것은 본 발명과 함께 사용될 수 있는 다른 소프트웨어 또는 프로그래밍 언어뿐만 아니라 모든 C++로 생성된 프로그램 대부분에 적용된다. 유리하게도, 마스터다트(230)는, 빌트인인스럭션(659)를 이용하여 다트엔진의 Save() 방 법을 접근하는 빌트인 함수를 이용하여 main()함수에서 최소한의 명령어 세트로 그 자신을 저장할 수 있다. 현재 데이터값의 완전한 이미지가 디폴트로 저장되고, 저장된 다트(700)가 로딩될 때 복원되기 때문에, 저장된 다트(700)에서 생성자 코드를 실행할 필요가 없다. 이러한 이유로, 마스터다트(230)는 저장 과정을 지시할 수 있어서, 이미 실행된 초기 생성자를 실행하는 코드의 연속적인 선형범위는 생성된 다트에서 렌디션들 어디에도 포함되지 않는다. 이러한 방식으로, 생성된 다트는 다트를 생성하는 마스터다트(230) 보다 상당히 작을 수 있다. 또한, 애플리케이션을 시작할 때마다 데이터 상태를 복구시킬 필요가 있는 정적 생성자 및 셋업 코드 모두를 유지시키는 통상의 유사한 기능성 애플리케이션 실행가능한 이미지보다 더 작을 것이다.

초기 생성자 코드를 포함할 필요를 제거하는 것은 생성된 다트의 크기, 복잡성 및 계산 요구를 최적화하는 데 사용되는 많은 메커니즘 및 방법들 중 단지 하나이다. 이러한 최적화는 일반적으로 종래의 메커니즘 및 방법을 이용시 요구되는 것보다 작은 크기, 낮은 복잡성 및 계산 요구의 결과를 낳는다.

데이터 멤버 데이터 또는 멤버 방법 제거는, 마스터플레이어(203) 상에서 동작하는 마스터다트(230) 또는 다트포맷(300)에 따르는 다트(700)가 다트 또는 다트 세트를 생성한다. 마스터플레이어(203)의 사용자 인터페이스 또는 마스터플레이어(203) 상에서 재생하는 다트의 실행을 통해 렌디션 오브젝트의 적절한 부분집합을 생성할 다트(700)에 포함되도록 선택될 수 있다.

선택된 렌디션에 필요한 코드 및 데이터의 파트들 및 섹션들만 일반적으로 생성된 다트(들)에 놓여야 한다. 이는 컴파일러(201) 및 링커(202)에 의해 생성된 메타데이터로부터 오브젝트들의 관계를 분석하고, 실행시간 데이터 멤버, 프로시져 방법 호출 및 실제 포인터값들을 통해 추적함으로써 다트툴(200) 및 마스터플레이어(203)에 의해 수행되어, 모든 데이터 멤버들, 코드 멤버들, 및 각 클래스의 방법을 찾은 후 오브젝트 인스턴스 및 액세싱 코드로부터, 시작 프로세스() 멤버 함수들로부터 선택된 렌디션을 실행함으로써 모든 레퍼런스 및 공간을 동적으로 제거한다. 따라서, 모든 클래스 정보는 모든 사작 위치들이 생성될 다트(들)(700)에 대해 확인되면 마스터플레이어(203) 상에서 동작하는 다트의실제 실행시간 셋업에 근거하여 효과적으로 최적화된다. 또한 유리하게도, 렌디션의 시작 방법으로부터 도달될수 없는 모든 셋업 코드 생성된 다트에 포함되지 않는다.

다트플랫폼이 주로 의도되는 것과 같은 사용자 중심 애플리케이션의 상당한 부분은 사용자 인터페이스 이미지를 위한 초기 스크린 부분을 설정하고, 데이터 구조를 초기화하고, 연결된 오브젝트의 그래픽을 만들고, 테이블 등을 생성하기 위한 셋업 코드 및 데이터로 이루어진다(consist of or include). 다트프레임워크(102)는 대부분의 클래스 정의에서 마스터렌디션 또는 다른 Setup() 호출로부터 네스팅된(nested) 호출에 의해 호출될 Setup()방법을 포함한다. 유리하게도, 마스터렌디션이 생성된 다트(들)(700)에 포함되도록 선택되지 않으면, Setup() 방법들 및 다른 방법들 및 함수들 및 선택된 렌디션으로부터 도달가능하지 않는 클래스 및 정적 데이터 요소들의 모든 데이터 멤버들 어느 하나도 생성된 다트(들)(700)에 포함되지 않는 것은 없다. 유리하게도, 선택된 실행시간 시작점으로부터 도달할 수 없 는 코드, 데이터, 방법 등은 다트툴(200)에 의해 생성된 다트(들)(700)에 포함되지 않을 것이기 때문에 이러한 최적화가 일어나도록 만드는 Setup() 호출에 관한 특별한 것은 없다.

게더리소스 프로시져(GatherResources Procedure)

게더리소스 프로시져 또는 방법은 생성된 다트(들)(700)에서 불필요한 코드 및 데이터를 제거하기 위하여 다트프레임워크(102)에서 사용될 다른 프로시져이다. Setup() 방법 또는 호출들로부터 파스터렌디션의 이러한 방법까지의 호출 트리는 게더리소스()와 관련된 방법들 함수들의 계층을 호출하여, 마스터다트(230)가 마스터플레이어(203) 상에서 동작될 때 사용자 인터페이스를 제공하거나 데이터, 콘텐츠 또는 다른 리소스를 동적으로 수집한다.

여기서 제공된 설명과 함께, 다트툴(200)은 마스터 플레이어(203)에 의해 상술한 최적화를 실행할 필요가 있는, 심볼 테이블, 클래스 정의, 다른 메타데이터를 유지하는 많은 파트들을 마스터다트(230)에 포함할 수도 있다. 이러한 파트들은 선택된 렌디션들 중 어느 것에도 포함되지 않을 경우, 유리하게도, 그것들은 생성된 다트(들)(700)에 포함되지 않을 것이다.

마트터다트의 몇몇 선택된 다른 사용

마스터다트(230)가 생성될 다트 애플리케이션(700)보다 훨씬 더 큰 크기 및 복잡성을 가진 다트플랫폼(50) 코드 및 데이터를 포함하는 것은 일반적이다(그러나 꼭 필요한 것은 아니다). 이러한 특별한 코드는 케이블의 접근, 요구, 초기화, 사용자 인터페이스, 미리 계산하고, 파트들을 어셈블리를 수행하는 데 사용된다. 따라서, 마스터다트(들)(230)은, 컴파일러(201)에 의해 컴파일되고 링커(202)에 의해 링크되면, 시간과 함께 또는 주가와 같이 다른 환경에 따라 변할 수 있는 새로운 파라메터, 리소스, 또는 다른 데이터를 이용하여 커스터마이징된(customized) 다트(들)(700)를 생성하는 데 프로그래머 또는 넌-프로그래머(non-programmer)에 의해 용되거나 재사용될 수도 있으며, 링커(202)에 의해 링크된 후 마스터플레이어(203) 상에 마스터다트(230)를 동작시킴으로써 사용자의 요구에서 자동적으로 ㅁ매우 다양하하게 다트 애플리케이션을 생성한다.

파트의 동적 재구성, 생성, 어셈블리, 및 최적화

다른 다트로부터 생성된 다트들뿐만 아니라 마스터다트(230)은 새로운 함수 및 타겟 트랜스포트 및 환경에 적합한 파생된 자식 다트(child dart)의 생성을 위하여 파트들 및 파트들의 파트의 선택을 동적으로 재구성하고, 생성하고, 어셈블리하고 최적화할 수 있는 능력을 보유하고 있다는 것을 알아야 한다.

콘텍스트타입 파라메터에 따른 파트들의 로딩

다트(230)의 렌디션이 각 렌디션을 위해 포함된 파트들을 각각 참조하는 렌디션 테이블을 참조하는 렌디션 테이블을 이용하여 로딩되면, 로딩을 요구하는 모든 파트들은 콘텐츠타입 파마메터에 따라 로딩된다. 다트인스트럭션셋트 및 다트인 스트럭션세트의 빌트인인스트럭션에 의해 구현된 확장은 다트(700) 또는 다트 프로시져(4000)로부터 매우 최적화된 다트(700) 및 다트프로시져(4000)의 효율적인 재구성 및 생성을 위해 만든다. 발람직한 일실시예에서, 파트테이블엔트리 레코드의 플래그 마라메터에서 플래그 비트는 로딩중 콘텍스트타입 특정 처리를 요구하는 파트를 위해 설정된다.

마스터다트는 일반적으로 메인코드 파트에서 마스터렌디션 오브젝트 인스턴스에서 시작하여 도달될 수 있는 모든 코드를 위한 완전한 코드 이미지를 포함할 수 있다. 유사하게, 마스터다트는 마스터렌디션 오브젝트 인스턴스에서 시작하여 도달될 수 있는 모든 데이터를 위하여 완전한 데이터 이미지를 종종 포함한다. 이것의 대부분은 생성된 다트포맷 이미지들로부터 제거될 것이다.

다트프레임워크, 다트런타임, 및 다트엔진

다트프레임워크(102), 다트런타임(8000), 및 다트엔진(600)을 더 자세하게 설명하기로 한다. 다트프레임워크는 다트엔진, 소정의 다트런타임 동작에 내재된 기능성의 효율 및 효과적인 사용을 위해 가정한다. 그러나, 대부분 C++ 프로그램은 성공적으로 만들어질 수 있으며 C++툴들의 표준세트 상에서 구현될 수 있거나 구현된 런타임 대부분을 이용하여 작동될 수 있다는 것을 알아야 한다. 다트프레임워크의 주 파워들 중 하나는 주로 다트엔진의 일부로써 구현된 명령어, 메커니즘, 프로시져, 및 함수들의 타이트한 통합 및 사용으로부터 나온다. 예를 들어, 압축된 JPEG 파일 또는 파트로부터 비트맵 이미지의 압축해제 및 만들기는 인터넷에서 널 리 이용가능한 JPEG 표준 예로부터 C++ 소스 코드를 컴파일링함으로써 수행될 수 있지만, 이와 같은 코드는, 다트엔진 방법을 호출하여, 다트엔진 소스 코드가 다트디바이스의 실제 프로세서를 위해 컴파일된 때 JPEG 압축해제 동작을 수행하는 빌트인인스럭션(본 명세서에서 BUILTIN_INSTRUCTION으로도 언급된)을 이용하는 빌트인 함수들의 단순한 이용보다 훨씬 더 느리게 수행될 것으로 예측될 수 있다.

유사하게, 다트프레임워크(102)는 예로써 몇몇 실시예에 실제 다트인스트럭션세트, 다트런타임(8000) 시스템, 통신 서브시스템, 이벤트 처리 시스템, 파일 시스템(도 26에서 파일 시스템(612)), 그래픽 및 입력 시스템, 전력 관리 시스템, 다트 어셈블리 압축 및 암호화 메커니즘, 및 압축해제, 접근, 보호, 디지털 권리 관리 및 생성 메커니즘을 포함하는 다트플랫폼(50)의 구현에서 빌트인 기능성의 생태계 및 환경을 이용하지만, 이들 모두를 요구하는 것은 아니며, 이에 한정되지 않는다.

모든 디바이스에서 구체화된 네이티브 프로세서(native processor)를 위해 생성된 코드의 효율로 표현된 사용자 중심 기능성의 잘 정의된 넓은 세트 또는 수집을 가진다는 것은 다른 실제 다바이스로 확장될 수 있는 포터블 애플리케이션에 필요한 함수 및 적합성을 만드는데 유리하며 몇몇 실시예에서 핵심이다는 것을 알아야 한다.

특히, 이론상 모든 투어링 컴파일런트(turing compliant) 명령어 세트는 다른 코드를 생성하거나 알로그즘을 수행하는 데 사용될 수 있지만, 실제로는 이러한 방법은 상대적으로 완전한 플랫폼을 제공하는 타이트하게 통합된 플랫폼만큼 실행, 메모리, 전력 또는 비용 측면에서 효율적이지 않을 것이며, 필요한 계산 또는 메모리를 요구하는 기능성을 다트인스트럭션세트의 다트엔진의 처리의 경우와 같이 플랫폼 특정방식으로 구현된다는 것을 알아야 한다.

일반적으로, 디바이스가 다트디바이스(DartDevice)(400)로 여겨지기 위해서는, 다트플레이어(500)와 같은 다트플레이어가 디바이스 상에 설치되어야 하며, 인에블된 디바이스 상에서 지원되는 적어도 하나의 통신 메커니즘이 있어야 한다. 다트플레이어(500)는 다트엔진(600)의 프로세서 제어 및 중단(closedown)을 시작하고, 초기화하고, 실행하는 데 필요한 환경 및 선택적 사용자 인터페이스를 제공하는 디바이스 특정 실행가능한 장치이다. 다트엔진(600)은 두 개의 상호연결된 클래스, 즉 포터블 플레이어베이스 클래스 및 디바이스 특정 halBase 클래스의 예로써 구축된다. 다트엔진(600)은 새로운 디바이스로 포트될 때, 디바이스 특정 다트플레이어(500) 애플리케이션은 다트엔진의 실행을 인캡슐레이트하도록 구축되어야 하며, 디바이스 halBase에 근거한 클래스는 브릿지를 다트엔진의 플랫폼 독립 파트로부터 실제 디바이스 운용체제 및/또는 하드웨어로 제공하도록 구현되어야 한다.

다트플레이어(500)의 메인 루프 흐름도는 도 23에 도시되어 있다. 먼저, DartEngine.Init()(6000) 함수는, 로딩될 다트(700)를 확인하는 파라메터로 호출된다. 그런 다음, DartEngine.Process()(도 23의 4002, 도 24의 6000) 함수는 음의 값이 리턴될때까지 루프에서 호출되어, DartPlayer.Uninit()이 호출되고 다트플레이어(500) 애플리케이션이 종료되도록 한다. 양의 리턴값은 값 특정 다트플레이어(value specific DartPlayer) 처리가 메인 루프(도 23의 4000 참조)로 복귀하기 전에 수행되도록 한다.

이와 같은 특정 다트플레이어 처리는 디바이스 상에서 동작하고 있을 수 있는 다른 애플리케이션 또는 처리에 대한 제어의 해제, 마우스 움직임 및 키보드 누름과 같은 입력의 수집, 및 이들을 다트엔진의 이벤트큐(EventQueue)(도 15의 8002 및 도 16의 5000 참조)를 이벤트(800)에 추가하는 호출로 변환하는 것을 포함한다. 양의 리턴 코드값이 다트가 처리를 종료되었다는 것을 의미하도록 남겨진 것이라면, DartProcess.Uninit()는 호출될 것이고 다트 처리는 중단될 것이다. 예를 들어, DONE 양의 리턴값으로 리턴하는 것은 동작중인 다트가 그 자신의 종료를 알리는 일반적인 방식이다.

DartEngine.Init() 처리는 도 24에 도시되어 있으며, DartEngine.Init()로의 호출은 로딩할 다트(700)에 대한 참조를 포함한다. 콘텍스트가 활성화되지 않았을 때 다트엔진(600)이 호출되고 로딩할 다트(700)가 없는 경우, 다트엔진의 내부로 아이들프로시져(IdleProcedure)가 다트(700) 대신 아이들콘텍스트로 로딩될 것이다. 아이들콘텍스트에서 동작하는 아이들프로세져는 다트엔진이벤트(도 23의 4003) 처리를 활성화시키는 데 필요한 처리를 수행하는 타드인스트럭션이션세트 명령어들의 루프로 구성된다. 바람직한 일구현에서, 아이들프로시져는 엔진이벤트프로세싱 함수(도 12 및 도 15의 8002)로 호출시키는 명령어들을 단지 실행시킨다. 바람직한 일실시예에서, 다트플레이어(500)의 하나의 인스턴스는 몇 가지 방식으로 실행중인 다트(700)를 일반적으로 다룰 수 있다. 하나의 방법은 메인 루프(4000)를 수정하거나 또는 개별의 다트엔진(600) 인스턴스를 생성하거나, 또는 이들의 개별의 스레 드(thread) 또는 조합을 이용함으로써 동일한 실행중인 네이티브 프로세서 스레드 내에서 개별적인 루프를 호출한다. 대안적으로, 다트가 명확하게 로딩되거나 실행중인 부모 다트의 서브다트 또는 자식다트서 동작한다. 여기서, 이벤트 처리 장치를 통과하는 이벤트 처리는, 컴파일되고 링크된 부모 다트의 일부인 것처럼 일단 로딩되면 서브다트의 이벤트 처리장치로 통과될 것이다. 바람직한 실시예에서, 이러한 이벤트 처리 장치는 Gizmos라 불리며 다트프레임워크 클래스 Gizmo의 예들이다.

Gizmos

다트(700) 자체는 다른 다트(700)를 직렬적으로, 또는 병렬적으로, 또는 다트가 다른 다트들의 처리 계층의 일부로서 동작하는 매우 협력적인 방식으로 실행시킬 수도 있다. 다트프레임워크(102)는 주로 Gizmoㄴ(115)에서 파생된 오브젝트들로 이루어질 수 있다. 이러한 Gizmoㄴ는 자식 및 부모 Gizmoㄴ 포인터들(도 18의 10000 참조)에서 레퍼런스에 따라 엄격하게 정의된 선형 순서로 유리하게 구성된다. 이 순서는 접근 권한 및 스크린 자산, 시간감각, 및 다른 환경적 특성의 측면에서 실행 및 관계의 순서를 결정하는 상호연결된 트리 그래픽으로 Gizmos를 수집하는 데 사용된다. 예를 들어, 부모는 자식(들) Gizmos 및 그 파생에 대해 시간을 변경하거나 명확한 시간 변경 속도를 변경할 수 있다. 이 모든 것은 도 18의 예에서 보인 바와 같이 처리의 구체화된 순서의 엄격한 준수에 의해 강력한 방식으로 구현하기 쉽게 한다.

도 18은 동작중인 슬라이드쇼 다트(700) 애플리케이션을 위한 Gizmo(115) 파 생 오브젝트의 계층의 예를 보여준다. 슬라이드쇼 다트(700) 애플리케이션는 다트엔진(600)을 이용하여 슬라이드쇼 다트의 코드를 구성하는 다트인스럭션세트 명령어를 실행하는 것이다. 특히, 다트엔진(600)을 함께 다트플레이어(500)는 다트디바이스(400)의 네이티브 프로세서 및 운용체제을 목표로 하는 표준 빌드 툴을 이용하여 컴파일되고, 링크되고, 로딩되고 실행된다는 것을 유의하여 한다. 다트툴(700)로부터 생성된 다트인스력션세트로부터의 명령어로부터 구성된 슬라이드쇼 다트(700) 코드를 실행하는 것은 다트엔진(600)이다. 도 18에 도시된 계층의 맨 위에 있는 Menu Gizmo는 먼저 다트엔진(600)이 다트(700)의 명령어의 처리를 시작하도록 하는 DartPlayer.Process() 호출의 결과로써 엔진 상에서 실행하면서 다트인스럭션세트 기반 Menu.Process() 방법이 시작될 때 제어를 한다. 바람직한 실시예에서, 계층의 맨 위에 있는 Gizmo는 도 11에서와 같이 베이스 Gizmo 클래스로부터 이어져 내려오는 클래스의 렌디션 오브젝트이다.

도 18의 예에서, 각 라운드진 코너 박스는 슬라이드쇼 애플리케이션을 위한 사용자 인터페이스의 장치를 다루는 Gizmo 파생 오브젝트를 나타낸다. 메뉴는, 슬라이드를 추가하고, 슬라이드의 자동 순서매기기를 시작하고, 슬라이드 전환 효과를 선택하는 것을 포함하는 다양한 기능들을 선택하기 위한 사용자 인터페이스를 다룬다. 메뉴로부터 선택될 수 있는 옵션들 중 하나는 슬라이드쇼의 뷰(view)이다. 이 예에서 화면들은 사용자가 슬라이드의 이름 또는 설명 위에서 클릭할 수 있는 하이퍼링크된 인텍스 뷰, 사용자가 슬라이드의 작은 썸네일 화면 상에서 클릭할 수 있는 썸네일 인덱스 뷰, 및 슬라이드가 대부분의 스크린을 차지하며, 스크린 화살 표, 물리적 버튼 또는 마우스 또는 펜을 사용하여 슬라이드의 계층을 통해 전후로 움직이는 슬라이드쇼 뷰를 포함할 수 있다. 메뉴만이 하나의 자식 Gizmo 파생 오브젝트를 가지만, 사용자가 메뉴에서 뷰를 선택하면, 자식 Gismo 파생 오브젝트에 대한 포인터가 선택된 뷰를 지원하는 Gizmo로 변경된다. 따라서, 유리하게도, 사용자가 슬라이드쇼를 보고 조정하는 방법을 변경할 필요가 있는 모든 것이 메뉴 Gizmo에서 하나의 포인터를 변경시킨다.

이 예에서 각 뷰는 도 18에서 행으로 도시된 세 개의 자식 Gismo(115) 파생 오브젝트에 대한 포인터들의 리스트를 가진다. 자식들은 모두 세 개의 뷰들의 자식 포이터 리스트들 각각에서 포인터 순서의 왼쪽에서 오른쪽으로 도시된 단순한 화면 또는 슬라이드이다. "3"으로 표시된 Gizmo 파생 오브젝트의 자식 포인터 리스트는 왼쪽에서 오른쪽 순서로 세 개의 자식들을 가르킨다. "4"로 표시된 오브젝트는 단일 슬라이드로써 슬라이드쇼에 포함되어 있지만 실제로 화면, 뷰 또는 다트(700) 및 그것의 모든 기능성을 포함하는 슬라이드들의 자체 계층을 포함할 수 있는 개별적으로 생성된 동작하는 서브다트를 인캡슐레이트하는 Gizmo(15) 파생 오브젝트를 가르킨다. "7" 및 "9"로 표시된 박스들은 실시간 재생 비디오/오디오 슬라이드를 디스플레이하는 Gizmo(115) 파생 오브젝트를 포함한다. 이러한 슬라이드에 대하여, Gizmo(115) 파생 오브젝트 및 다트 재생 Gizmo(115)의 포함된 다트들(700)의 처리는 자식으로부터 부모까지의 포인터들에 의해 생성된 그래프의 정확한 순서로 처리제어를 받는다는 것을 유의하여야 한다. 이 순서는 도 18에서 박스 내부에 보인 숫자의 순서로 명확하게 제시하였다.

Gizmo(115) 파생 오브젝트에 의한 대부분의 처리는 포인터를 가지는 Process() 방법에 대한 호출을 통해 파라메터로써 처리에 대한 이벤트까지 이기 때문에, 부모는 자식에 의해 보여진 이벤트의 파라메터 또는 타입을 생성 또는 변경하거나, 처리될 이벤트를 그 자식에게 전달할 것인지 아닌지를 결정할 수 있다. 따라서, 실제로, 부모는 모든 자식을 위해 환경을 설정할 수 있다. 예를 들어, 다트 컨테이너 Gizmo 오브젝트는 부모에게 이용가능한 스크린 자산을 제공하였다는 것을 알 필요가 없다. 유사하게, Gismo(115) 파생 오브젝트는 GetTime() 방법을 접근할 때, 부모가 자식에 대한 시간 소스라는 것을 알렸을 경우 빌트인 호출부터 보다는 그의 부모로부터 엔진으로 자동적으로 시간을 요구할 것이다. 자식의 런타임 환경을 제어할 수 있는 부모의 이러한 능력은 다트프레임워크(200) 및 다트런타임(8000)의 매우 강력한 특성이다. 이것은, 예를 들어, 슬라이드쇼의 슬라이드 쇼 및 다트를 수집하고 사용자가 실행시킬 하나를 선택하는 다트의 수집을 용이하게 한다. 이는 포인터 또는 다른 다트 인에블된 디바이스로부터 다트(700)의 형태로 제어 패널을 페치할 수 있으며, 페칭 다트 내부에 사각형으로 구현되어 동작된다.

다트엔진 구조 - 제어의 패싱

다트엔진(600)의 구조는, 포함하는 Gizmo(115) 파생 오브젝트가 포함된 다트(700)에 대한 다트콘텍스트를 생성하도록하며 다트(700)를 콘텍스트 내에 로딩되도록 하는 BUILTIN_INSTRUCTION 함수를 포함시키고, 계층에서 가장 위쪽의 Gizmo(115)의 다트의 Process() 방법에 대한 다트엔진의 BUILTIN_INSTRUCTION 호출 을 통해 포함된 다트(700) Process()를 호출함으로써 포함된 다트의 계층에서 다트 컨테이너 Gizmo(115) 파생 오브젝트로부터 맨 위쪽 Gizmo(115)로의 제어의 패싱을 제공한다.

포함된 다트(700)에 대한 처리를 관리하고 패싱하는 호출과 함께, 다트엔진(600)은 또한 포함된 다트에 의해 처리된 이벤트(800)에 대한 포인터를 포함하는 이벤트프로세싱 구조 인스턴스를 모든 다콘텍스트 사이에서 효과적으로 공유된 메모리에 대한 특별한 포인터(도 32의 포인터 타입 11 참조)의 사용을 통해 직접적으로 메모리에서 접근가능하도록 함으로써 컨테이너 다트(700) 코드로부터 포함된 다트의 코드로 더 효율적으로 변경한다. 이는 어드레스 공간을 각각 가지고 있는 다트들(700) 사이의 이벤트(800)와 다른 파라메터들의 효율적인 패싱을 가능하게 한다.

한 다트(700)에서 다른 다트(700)로 요청이 있는 경우, 다트엔진은 요청된(called) 다트의 다트콘텍스트가 최초의 요청이 이루어진 때와 같은 장소에 엔진 스택(stack)이 있는 경우 돈인스트럭션(DoneInstruction)을 수행할 때까지 요청하고 있는 다트의 다트콘텍스트(DartContext)를 기억하고 그런 다음 요청된 다트의 다트콘텍스트로부터 동작을 시작한다. 따라서, 다트엔진(600)은 다트들(700)이 하나의 다트(700)로서 다트툴들에 의해 생성되었다면 그러했을 것처럼 그것들은 기즈모(115) 유도된 계층의 일부로 다트(700) 애드 인피니템(ad infinitem)을 동작하는 다트들(700)을 동작하기 매우 쉽고 효율적이게 한다. 포함하는 다트들은 자식 기즈모(child Gizmo, 115) 유도된 오브젝트(object)에 할 수 있는 것처럼 포함된 다 트(700)에 원하는 어떤 환경을 제공할 수 있다.

전체 계층 아래의 간단한 제어 패싱(passing of control)은 재표시될 필요가 없는 정지 화면을 나타내는 기즈모(115) 유도된 오브젝트와 같이 프로세싱이 요구되지 않는 기즈모(115) 유도된 오브젝트들을 요청함에 있어서 프로세서 시간을 낭비할 것이라는 것을 추정할 수 있다. 이 문제는 바람직한 실시예에서 기즈모(115) 유도된 오브젝트 요청들의 트리를 줄이기 위한 시스템에 의해 방해받을 수 있다. 각각의 이벤트타입(801) 값은 정확히 하나의 비트가 설정될 카테고리 플래그 필드(category flag field) 및 그 카테고리에 속하며 처리될 특정 이벤트(800)에 대한 이벤트 서브타입 필드(event subtype field)를 채운다. 일 실시예에서, 이벤트 타입(801)의 카테고리 플래그들에 해당하는 두 세트의 플래그들이 있다. 한 플래그는 기즈모 유도된 오브젝트 자체가 이러한 유형의 이벤트들을 취급할 필요가 있는 경우 설정되며, 다른 하나는 그 자손들 중 어느 하나라도 이벤트(801)의 특정 카테고리를 참조할 필요가 있는 경우 설정된다. 일 실시예에서, 계층을 통한 모든 패스(pass)에 있어, 기즈모(115) 유도된 오브젝트들은 자신들을 위한 플래그들을 설정하고 요청한 모든 자식들에 의해 설정된 플래그들의 논리적으로 오어된(OR'ed) 모음을 수집한다. 따라서, 기즈모는 그 자식들이 처리될 이벤트(800)의 카테고리에 따라 요청되거나 요청되지않을 필요가 있는지를 항상 알고 있다. 카테고리들은 이벤트타입의 세트들에 의해 정의되어 불필요한 요청들의 제거를 효율적이게 한다. 예를 들어, 사용자 입력과 함께해야하는 이벤트들(800)은 사용자 입력을 처리할 필요가 있는 어떠한 기즈모(115) 유도된 오브젝트를 포함하지 않는 기즈모(115) 유도 된 오브젝트의 하부트리(down trees)들을 통과하게 될 필요가 없다.

다트엔진.프로세서()프로세싱

다트엔진.프로세서()프로세싱의 예는 도 23, 15 및 16의 실시예에 보여진다. 이것은 다트들의 다트인스트럭션세트 명령들(611)의 주요 실행을 드라이브한다. 주 루프(main loop)는 다트 명령 스트림(Dart's instruction stream)으로부터 다음 명령을 얻기 위해, 조작부호들(opcodes) 및 소스 및 명령들의 수신지란(destination field)을 디코딩하기 위해, 어드레스된 소스 및 데서티네이션 파라미터(destination parameter)가 다트의 다트콘텍스트의 데이터 영역의 외부에 있는 지를 체크하기 위하여, 그리고 나서 명령의 조작부호 필드에 의해 요청된 기능을 실시하는 다트플레이어(600)의 장치 프로세서 고유 코드 또는 기능을 건너 띄기 위해 수행된다. 명령의 소스 혹은 데스티네이션 필드가 접근되도록 허용된 그것들 외부의 파라미터들을 지정한다면, 조작부호들에 기초한 디스패치(dispatch)가 이루어지지 않으며 콘트롤은 다트플레이어.프로세서()가 특정 접근 위반을 반영하는 특정 음(negative)의 복귀값(return value)으로 요청한 직후에 복귀된다. 이는 다트플레이서(500)이 다트플레이어.유니닛()(DartPlayer.Uninit())을 요청하도록 하며 오류 메세지 또는 다른 선택적 지시자와 함께 다트 수행을 종료하도록 한다.

도 22는 다트플레이어(500), 다트엔진(600) 및 하드웨어 추상화 계층(Hardware Abstraction Layer(HAL), 650)의 관계 및 몇 가지 기능성을 보여준다. 하드웨어 추상화 계층(650)은 필요한 장치 특정 접근 기능들을 캡슐화하는데 사용 되는 할베이스(halBase)로부터 유도된 클래스로 수행되는 플레이어의 일부이다. 수행되도록 요구되는 할베이스 기능들의 수와 복잡성은 최소로 유지되어 새로운 다트디바이스(400) 타입으로의 포팅(porting)이 빠르고 쉽다. 할베이스 설계에 최소한의 접근을 하는 것은 개별적으로 수행되는 다트엔진들(600)이 대부분의 수행 소스 코드 기능들을 공유하기 때문에 매우 고도의 양립성(high degree of compatibility)을 획득한다는 것을 보증하는 데 또한 도움을 준다. 따라서, 다트플레이어(500)의 휴대용 장치의 독립적인 부분들로 가능한 많은 기능들로 이동하는 것이 매우 유익하다. 포팅의 용이(ease of porting)와 고도의 양립성은 어디서든 가능한 휴대용 코드의 사용 혹은 어디서든 가능한 모든 장치에 대한 동일한 소스 코드의 사용을 통해 부분적으로 구현되는 다트플랫폼(50)의 실시예의 중요한 특징이다. 그러므로, 재컴파일 및 링크가 각각 다른 유형의 장치에 흔히 필요할지라도, 대부분의 기능은 다른 장치와 협력하여 동작할 수 있도록 예상되는 다른 장치들과 동일한 소스로부터 컴파일될 것이다.

구조의 전력 관리 특징(Power Management Features of Architecture)

전력관리는 비록 선택적이지만 다트플랫폼(50)의 구조의 많은 부분들을 통해 작동되는 다른 특징이다. 다트플레이어(500)이 다트엔진.프로세스(4003) 방법을 요청하면, 기즈모 유도된 오브젝트 계층의 실행이 수 밀리세커드 (혹은 다른 단위들) 내 필요한 응답 시간을 나타낼 수 있는 최대값으로 유지하는 변수를 세팅함으로써 시작된다. 이벤트들이 기즈모(115) 유도된 오브젝트들의 정리된 트리들에 의해 처 리됨에 따라, 각 오브젝트는 BUILIN_INSTRUCTION을 사용하여 다트엔진(600)으로 다시 요청된 그 프로세스()를 가질 필요가 있을 때까지 얼마나 오랫동안 기다릴 수 있는가를 알린다.

예를 들어, 동영상을 표시하기 위한 오브젝트에 대하여, 이것이 비디오의 프래임 속도(frame rate)라면 이는 1초의 1/30이 될 것이다. 다트엔진(600)은 파라미터로서 패스되는 최저 응답 시간 요구들의 모집을 수행하는 BUILIN_INSTRUCTION에 의해 기록되는 최저 응답 속도 요구들을 수집한다. 콘트롤이 기즈모 트리 그래프의 계층을 완전히 통과한 후 다트플레이어(500)로 돌아오면, 다트플레이어(500) 또는 다트엔진(600)은 이러한 정보를 사용하여 전력이 적어도 지시된 시간 동안 필요하지 않은 쓰레드(thread) 혹은 다른 신호를 블록한다(block). 보통, 다트플레이어(500)는 수집된 최소 응답 시간과 같은 타임아웃(timeout)을 갖는 쓰레드를 블록할 것이다. 이러한 블록은 새로운 입력이 도착하면 다트(700)에 의해 처리될 그런 요구들은 또한 종료될 것이다. 많은 경우 프로세서 상에 동작하는 어플리케이션은 모든 시간에서 실제 응답 시간 요구들을 알고 있는 유일한 실체임을 이해할 수 있을 것이며, 다트 어플리케이션들은 다트플레이어(500)가 이러한 정보를 입수하기 쉽고 동적인 어플리케이션ㄷ르의 성능의 큰 저하 없이도 장치들의 필요로 하는 전력 및 에너지 소비를 크게 줄이기 위하여 사용하기 쉽게 하는 방식으로 유익하게 설계되고 생성될 수 있다.

이벤트 처리 큐잉 메카니즘 (Event processing queing mechanism)

엔진이벤트프로세싱(EngineEventProcessing, 도 15의 8002, 도 16의 5000) 처리 동안 수행되는 이벤트 처리 큐잉 메카니즘은 또한 계층을 요청하는 기즈모.프로세스(이벤트인포(EventInfo *))의 일부가 아닌 비동기식 프로세스(도 16의 점선 박스의 사항들)들의 응답 시간 요구들의 정보를 끊임없이 얻어내거나 모니터할 수 있다. 이런 식으로, 활성화된 다트들에 의해 기록되는 최소 응답 시간 요구들은 기즈모의 선형 태스킹(Linear Tasking)에 의해 수행되는 주류(mainstream)의 동기화 다트 어플리케이션 프로세싱 및 다트엔진(600)의 이벤트 처리 부분들에 의해 취급되는 비동기식 프로세스들의 결합된 요구들을 반영한다.

보안 및 무결성(Integrity)-명령 디코딩 단계에서 수행되는 실행 체크

다트플랫폼(50)의 보안, 무결성 및 강인성(robustness)은 적어도 부분적으로 다트인스트럭션세트의 명령들을 디코딩하는 동안 수행되는 실행 체크의 사용을 통해 확신될 수 있다. 데이터 주소들 및 명령들의 소스 필드들은 동작하는 다트콘텍스트(DartContext)에 따라 수행하는 다트의 합법적으로 접근가능한 데이터 범위 내의 데이터를 참조하는 것을 확신하기 위하여 엔진에 의해 테스트 된다. 유사하게, 어플리케이션들의 프로시쥬어들로 구성된 다트 어플리케이션 및 다트인스트럭션세트는 동작하는 다트에 속하는 오직 물리적 스토리지를 액세스하는데 제한이 있다. 이는 악성 또는 오동작 다트들이 동작중인 다트들에 의해 접근가능하지 않아야 하는 개인 데이터나 스토리지 리소스들을 액세스하기 위한 전력을 갖는 것을 방지하기 위함이다.

컨벤션(convention)을 명명하는 하드웨어 추상 계층(HAL) 파일 시스템은 다트 어플리케이션이 그의 법적 도메인 외부의 파일을 지정하는 방법이 없다는 것을 확신한다(그러나 선택적으로 의도적인 예외사항을 참조). 열기(open)나 삭제(delete)와 같은 작업을 위해 파일을 지정하는 경우, 다트 어플리케이션은 모든 파일 경로들을 지정할 수 없으며 단지 로케이션아이디(locationId) 및 수(number)만을 지정하거나, 도 28의 5010에 도시된 바와 같이 로케이션아이디 및 단말명 스트링(terminal name string)을 지정한다. 이와 같이, 접근가능한 물리적 스토리지는 도 28의 5020에 보이는 하드웨어 추상 계층(HAL)에서 로케이션들(Locations)까지 내에서 제한된다. 그것은 파일들을 지정하는 이러한 파라미터들만을 기초로 하여 열기, 닫기(close), 읽기(read), 쓰기(write), 위치하기(position), 다시 명명하기(rename), 위치획득(get-position) 작업을 수행하는 하드웨어 추상 계층(HAL)에 따라 정해진다. 한 의도적이나 하드웨어 추상 계층(HAL)이 강제된 샌드박스(sandbox) 외부의 접근 금지에 대한 선택적인 예외는 USER_SPECIFIED_LOCATION에 해당하는 로케이션아이디가 다트 콘텍스트 한계(limits) 밖의 파일들에 대한 접근을 제공하기 위하여 하드웨어 추상 계층(HAL) 내에서 선택적으로 지원될 수 있다는 것이다. 파일 선택을 위해 사용자를 명백히 재촉하기 위하여 파일을 열거나, 삭제하거나, 이름을 다시 명명하는 경우 하드웨어 추상 계층(HAL)에 따라 정해진다. 이는 사용자의 참여에 의해 부여된 내재하는 허가만을 갖고도, 어플리케이션들이 파일을 반입(import) 및 반송(export)하도록 허용한다.

비록 본 발명의 구조, 방법, 장치, 컴퓨터 프로그램들, 및 컴퓨터 프로그램 생성물들이 몇몇 구체적인 실시예들을 참조하여 설명되었으나, 이는 본 발명의 예시적이며 본 발명을 제한하는 것으로 해석되어서는 안 된다. 다양한 변형들이 첨부된 청구범위에 의해 정의된 발명의 진정한 사상 및 범주에서 벗어나지 않으면서 통상의 지식을 가진 자에게 일어날 수 있다. 여기에서 언급된 모든 참조사항들은 참조된 것에 의해 포함된다.

Claims

소스 디바이스에서 동작하는 소프트웨어 애플리케이션으로 디바이스들의 팀을 모집하는 방법에 있어서,

시작 소스 디바이스 및 그 자체가 도달될 디바이스 모두에 공통되는 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 필요한 리소스 또는 능력을 가지는 디바이스를 발견하도록 동작하는 인스펙션 프로시져를, 적어도 하나의 통신 링크를 통해 상기 시작 소스 디바이스와는 다른 적어도 하나의 도달가능한 디바이스로 전달하는 단계와;

상기 시작 디바이스에서 도달가능한 디바이스들 각각으로부터의 리턴 응답을 통신 링크를 통해 간접적으로 또는 직접적으로 수신하는 단계와;

상기 시작 디바이스에서 실행되는 프로시져를 통해 도달가능한 모든 응답 디바이스들로부터 수신된 리턴 응답들을 분석하여 상기 소프트웨어 애플리케이션의 목적을 가장 잘 수행할 수 있는 상기 도달가능한 응답 디바이스들과 상기 시작 소스 디바이스의 능력들 및 리소스들의 조합을 확인하기 위한 유틸리제이션 플랜(utilization plan)을 결정하는 단계와;

상기 시작 디바이스에서 실행되는 애플리케이션 프로그램을 통해 코드, 데이터, 콘텐트 및/또는 다트(Dart) 중의 적어도 하나를 상기 결정된 유틸리제이션 플랜에 따라 필요한 리소스 또는 능력을 가지는 것으로 확인된 상기 도달가능한 각 디바이스들 중의 적어도 하나에 분배(distribute)하는 단계를;

포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
디바이스들의 팀을 모집하는 방법에 있어서,

수신 디바이스와 모집 디바이스 모두에 알려진 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 도달가능한 수신 후보 디바이스가 통신 링크 상의 다른 모집 디바이스에 요구되는 리소스 또는 능력를 구비하는지의 여부를 결정하도록 동작하는 인스펙션 프로시져를 후보 디바이스에서 수신하여 실행하는 단계와;

상기 수신된 인스펙션 프로시져를 위한 소스 디바이스를 확인하고 상기 도달가능한 수신 디바이스가 상기 시작 소스 디바이스에 의해 요구되는 것으로 확인된 리소스 내지 능력 또는 리소스들 및 능력들의 조합에 액세스하는지의 여부에 대한 상태 및 정보를 상기 소스 디바이스에 리턴 응답으로 전달하는 단계와;

상기 소스 디바이스에 의해 상기 도달가능한 디바이스가 소프트웨어 애플리케이션의 목적을 수행하기 위한 팀을 구성하는데 필요한 리소스들 또는 능력들을 구비하는 것으로 판단되는 경우, 실행가능한 코드, 데이터, 콘텐트 및/또는 다트 중의 적어도 하나를 상기 소스 디바이스, 모집 디바이스 또는 다른 후보 디바이스로부터 수신하는 단계를;

포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
디바이스들의 팀을 모집하는 방법에 있어서,

(a) 시작 소스 디바이스 및 그 자체가 도달될 디바이스 모두에 공통되는 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 필요한 리소스 또는 능력을 가지는 디바이스를 발견하도록 동작하는 인스펙션 프로시져를, 상기 시작 소스 디바이스로부터 적어도 하나의 통신 링크를 통해 상기 시작 소스 디바이스와는 다른 적어도 하나의 도달가능한 디바이스로 전달하는 단계와;

(b) 상기 도달 가능한 디바이스들 각각에서 상기 인스펙션 프로시져들을 수신 및 실행하여 상기 시작 소스 디바이스에 의해 요구되는 상기 도달가능한 디바이스의 적어도 하나의 리소스 또는 능력이 존재하는지의 여부를 확인하는 단계와;

(c) 적어도 상기 도달가능한 디바이스가 상기 시작 소스 디바이스에 의해 요구되는 것으로 확인된 리소스 또는 능력에 액세스하는 경우에 상기 시작 소스 디바이스로 리턴 응답을 전달하는 단계와;

(d) 상기 도달가능한 디바이스들 각각으로부터 상기 리턴 응답을 상기 통신 링크를 통해 간접 또는 직접적으로 수신하는 단계와;

(e) 상기 시작 디바이스에서 실행되는 애플리케이션을 통해 도달가능한 모든 응답 디바이스들로부터 수신된 리턴 응답들을 분석하여 상기 소프트웨어 애플리케이션의 목적을 가장 잘 수행할 수 있는 상기 도달가능한 응답 디바이스들과 상기 시작 소스 디바이스의 능력들 및 리소스들의 조합을 확인하기 위한 유틸리제이션 플랜(utilization plan)을 결정하는 단계와;

(f) 상기 시작 디바이스에서 실행되는 애플리케이션 프로그램을 통해 코드, 데이터, 콘텐트 및/또는 다트(Dart) 중의 적어도 하나를 상기 결정된 유틸리제이션 플랜에 따라 필요한 리소스 또는 능력을 가지는 것으로 확인된 상기 도달가능한 각 디바이스들 중의 적어도 하나에 분배하는 단계를;

포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 적어도 하나의 도달가능한 디바이스로 상기 분배된 실행가능한 코드, 데이터, 콘텐트 및/또는 다트 중의 적어도 하나를 수신하는 단계를 더 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 실행가능한 코드, 데이터, 콘텐트 및/또는 다트 중의 적어도 하나가 분배된 상기 적어도 하나의 도달가능한 디바이스와 상호작용(interoperate)하여 상기 시작 디바이스의 애플리케이션의 목적의 적어도 일부를 수행하는 단계를 더 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

제2 시작 소스 디바이스들의 역할을 하는 각각의 도달가능한 디바이스로, 실행가능한 코드, 데이터, 콘텐트 및/또는 다트를 상기 시작 및 도달가능한 디바이스들에 걸쳐서 선택적으로 확산하고, 이에 더하여 상기 도달가능한 디바이스들에 상주하는 애플리케이션 코드, 데이터, 콘텐트 및/또는 다트들을, 소정 디바이스들의 모든 또는 소정 기준들과 상기 원래의 시작 디바이스 애플리케이션의 목적을 수행하는데 요구되는 리소스들 또는 능력들이 도달될 때까지, 다른 도달가능한 디바이스들에 요구되는 애플리케이션을 확장하는데 필요한 만큼, 이전에 도달되고 팀 구성된 디바이스들에 의해 도달가능한 다른 디바이스들에 더욱 더 회귀적으로(recursively) 확산하는 단계와;

상기 시작 애플리케이션의 목적을 수행하도록 상기 디바이스들의 팀에 걸쳐서 수행될 동작들을 수행 및/또는 조정(coordinate)하는데 필요한 실행가능한 코드, 데이터, 콘텐트 및/또는 다트들을 교환하고 코드를 수행하여, 상기 시작 디바이스의 애플리케이션을 수행하도록 요구되는 동작들 및 리소스 액세스를 수행하는 상기 시작 디바이스 애플리케이션의 요구들에 따라 상기 시작 및 도달가능한 디바이스들의 팀 사이에, 실행가능한 코드, 데이터, 콘텐트 및/또는 다트를 분배하는 단계를; 더 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 시작 소스 디바이스가 상기 리턴 응답을 상기 시작 디바이스가 모집 메시지를 전달했던 처음에 도달된 디바이스로부터 직접적으로 수신하거나, 상기 시작 소스 디바이스가 상기 리턴 응답을 하나 이상의 단속적으로 도달가능한 디바이스들을 통해 직렬 또는 회귀적 방식으로 다른 도달가능한 디바이스로부터 간접적으로 수신하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 도달가능한 디바이스가 상기 시작 소스 디바이스에 의해 요구되는 것으로 확인된 리소스 또는 능력에 액세스하지 않은 경우에도, 상기 시작 소스 디바이스로의 상기 리턴 응답이 전달되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 시작 소스 디바이스로의 상기 리턴 응답이, 상기 시작 소스 디바이스에 의해 요구되는 것으로 확인된 상기 리소스 또는 능력을 자체적으로 구비하거나 액세스하는지(예: 참 또는 논리 "1") 아니면 자체적으로 구비하거나 액세스하는 것이 아닌지(예: 거짓 또는 논리 "0")를 확인하기 위한, 단순 파라미터(simple parameter)인 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 시작 소스 디바이스로의 상기 리턴 응답이 다트이벤트(DartEvent), 다트(Dart)의 일부, 데이터, 콘텐트, 실행가능한 프로시져들, 다트, 다수의 다트들(darts), 및 이들의 조합 중의 하나를 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 시작 소스 디바이스로의 상기 리턴 응답이 통신 프로토콜들로 상기 시작 디바이스로의 특정 도달가능한 디바이스의 리소스들 및/또는 능력들을 확인하기 위한 리턴된 데이터 또는 콘텐트를 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 인스펙션 프로시져가, 상기 시작 소스 디바이스에 의해 요구되는 적어도 하나의 확인된 특정 리소스 또는 능력을 검사(inspect)하여 상기 시작 소스 디바이스의 적어도 일부에서 수행되는 애플리케이션 태스크(task)의 목적을 수행하기 위한, 인스트럭션을 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

디바이스들의 팀에 걸쳐서 애플리케이션을 모집하고 효과적으로 작동시키는 컴퓨터 프로그램 제품으로 인코드된 소프트웨어 애플리케이션에 의해 적어도 부분적으로 구현되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 모집하고 그리고 모집된 디바이스들이 그 디바이스들 모두의 결합된 리소스들을 구비하는 하나의 디바이스인 것처럼 상기 모집하고 그리고 모집된 디바이스들의 제어를 결합해서 허용하는 것을 특징으로 하는 상기 디바이스 팀 모집 방 법.
제3항에 있어서,

상기 리턴 응답이, 노 리턴(no return), 데이터 또는 콘텐트 리턴, 디지털로 인코드된 소정 정보, 하나 이상의 프로시져들, 상기 디바이스가 유용할 것이라는 인디케이션(indication), 리턴된 이벤트(returned event), 해당 파일 페이로드(payload)을 통한 소정량의 데이터 또는 데이터의 세트들(sets)을 포함하는 리턴 이벤트, 리턴 프로시져, 다트(Dart), 상기 시작 디바이스 상의 메뉴로부터 사용할 디바이스(들)을 선택할 수 있도록 텍스트 명칭들(text names) 및 상기 디바이스에 대한 설명들을 포함하는 리턴 이벤트, 상기 소스 디바이스 상에서 상주(reside)하거나 생성될 수 있는 실행가능한 코드, 데이터 및 콘텐트의 세트의 적어도 하나의 인스턴스(instance)의 소정 패키지의 식별자(identifier), 상기 디바이스 상에서 작동하기에 가장 적절한 렌디션(rendition) 또는 렌디션들의 세트, 또는 이들의 조합 중에 하나를 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 적어도 하나의 리소스 또는 능력이, (i) 이용가능한 리소드들 또는 소정의 요구되는 리소스; (ii) 이용가능한 능력들 또는 소정의 요구되는 능력; (iii) 상기 도달가능한 디바이스의 리소스들 및 능력들의 하나 이상의 상호 관련된 세트들 또는 상기 애플리케이션의 목적을 수행하기 위한 상기 도달 가능한 디바이스에 이용가능한 리소스들 및/또는 능력들; 및 (iv) 이들의 소정 조합으로 구성되는, 세트로부터 선택된 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 리소스들 또는 능력들이 리소스들 또는 능력들의 세트로부터 선택된 적어도 하나의 확인된 능력을 포함하되,

상기 리소들 또는 능력들의 세트가 확인된 데이터 조작(manipulation) 소프트웨어, 확인된 정보 프로세싱 소프트웨어, 확인된 계산 소프트웨어, 확인된 픽쳐 프로세싱 소프트웨어, 확인된 통신 소프트웨어, 확인된 통신 하드웨어, 확인된 미디어(media), 확인된 데이터 세트(들), 확인된 콘텐트, 확인된 프로그램 또는 프로그램들, 확인된 구성(configuration) 정보, 확인된 그래픽 가속 하드웨어 또는 소프트웨어, 확인된 임시(temporary) 또는 영구(permanent) 저장 매체, 확인된 프린팅 능력, 확인된 팩싱 능력, 확인된 스캐닝 능력, 확인된 사용자 입력 및/또는 출력 인터페이스(interface) 장치, 상기 디바이스가 통신할 수 있으며 다른 디바이스들이 연속적인 체인(unending chain)으로 통신할 수 있게 하는 다른 디바이스들의 리소스들로의 액세스(access), 및 이들의 둘 이상의 조합으로 구성되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

공통적인 실행가능한 형태의 상기 인스펙션 프로시져들이, 다트 인스트럭션 호환 엔진 (DartEngine) 또는 소정의 다른 상호 운용 인스트럭션 세트(Interoperability Instruction Set)로 구현된 다트 컴플라이언트 인스트럭션 세트(DartInstructionSet)로부터 형성된, 적어도 하나의 인스펙션 프로시져(inspection procedure)를 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 적어도 하나의 통신 링크가, 영구적으로(permanently) 또는 단속적으로(intermittently) 이용가능한 유선 또는 무선의 동종(homogeneous) 또는 이종(hetrogeneous) 통신 프로토콜들의 일부 또는 세트를 포함하는, 소정 개수의 통신 링크들, 채널들 및/또는 프로토콜들을 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 동종 및 이종 통신 링크들, 채널들 및 프로토콜들이, 둘 이상의 통신 디바이스들 상에서 동작하는 플레이어들(players)의 파트들(parts)인, 확인된 하드웨어 앱스트랙션 레이어 수단들(hardware abstraction layer implementations)에 의해 지원되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제20항에 있어서,

상기 확인된 하드웨어 앱스트랙션 레이어 수단들이, 다트엔진들(DartEngines)의 구성 요소들인, 다트 하드웨어 앱스트랙션 레이어 수단(Dart Hardware Abstraction implementation)을 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 적어도 하나의 통신 링크와 통신 프로토콜을 이용하여 런(run) 프로시져 타입의 이벤트들과 상기 도달가능한 디바이스 상에서 동작하는 상기 프로시져를 확인하는 파일을 참조(reference)하는 이벤트의 식별자를 전달하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제22항에 있어서,

상기 이벤트들이 다트이벤트들(DartEvents)을 포함하며 상기 런 프로시져 타입 이벤트가 다트 런_프로시져 타입 이벤트(Dart RUN_PROCEDURE type event)를 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 도달가능한 디바이스 상에서 동작하는 프로시져를 확인하는 파일을 참조하는 상기 이벤트 식별자가 상기 도달가능한 디바이스 상에서 동작하는 프로시져의 이미지를 포함하는 파일을 참조하는 상기 이벤트의 파일 식별자를 포함하는 것 을 특징으로 하는 상기 디바이스 팀 모집 방법.
제24항에 있어서,

상기 파일이 상기 다트포맷(DartFormat)에 따르는 다트 컴플라이언트 파일 (DartFile)을 포함하며 상기 프로시져의 이미지가 다트 프로시져(Dart Procedure)의 이진 데이터 이미지(DartProcedure)를 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 인스펙션 프로시져들이 다트프로시져(DartProcedure) 또는 완전한 다트들(complete Darts)을 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 인스펙션 프로시져들이 이벤트와 관련된 상기 파일들로서 전달되며, 상기 이벤트와 관련된 상기 파일들로서 도달가능한 장치에 의해 상기 인스펙션 프로시져를 수신하는 것에 의해 상기 인스펙션 프로시져가 상기 도달가능한 디바이스들 상의 실행동작을 개시하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 인스펙션 프로시져가 다트프로시져(DartProcedure)를 포함하는 것을 특 징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 도달가능한 디바이스의 기본 리소스들 및 능력들을 포함하는 리소스들 및 능력들은 인스트럭션 세트 프로파일 인스트럭션(instruction set profile instruction)을 이용하여 결정되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제29항에 있어서,

상기 인스트럭션 세트 프로파일 인스트럭션이 다트 컴플라이언트 인스트럭션 세트(DartInstructionSet)의 다트 컴플라이언트 프로파일 인스트럭션(Dart PROFILE_INSTRUCTION)을 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

도달가능한 각각의 디바이스 내에서의 상기 인스펙션 프로시져의 수행은 상기 도달가능한 디바이스 또는 그 각각에 전달되는 렌디션 결정 규칙(rendition determination rule)에 따라 상기 시작 다트 구현 애플리케이션(initiating Dart embodied application)의 최선의 렌디션을 결정하고 상기 결정된 최선의 렌디 션(Randition)을 상기 리턴된 데이터의 일부로서 되돌려보내는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제31항에 있어서,

상기 렌디션 결정 규칙은, 소정 복잡도(complexity)의 소정의 필요한 계산을 수행하고 프로파일 인스트럭션을 통해 소정의 필요한 프로파일 정보를 액세스하여 상기 도달가능한 디바이스의 자원들, 능력 및/또는 상태를 결정하기 위한, 적어도 하나의 프로시져로 구현되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제31항에 있어서,

상기 인스펙션 프로시져 실행은, 렌디션의 순서(order)를 정의하는 규칙들을 참조하여 다수의 렌디션들로부터 최선의 렌디션을 결정하며, 도달가능한 장치 각각을 체크하여 상기 배열된 다수의 렌디션들 중에서 상기 렌디션의 요구조건들(Rendition's requirements)의 모두를 만족시키는 상기 제1 렌디션이 발견될 때까지 상기 다수의 렌디션들 각각의 모든 요구조건들이 렌디션 우선권의 기 정의된 순서에 부합되는지의 여부를 결정하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 인스펙션 프로시져(들)가 소정의 통신 프로토콜을 이용하여 상기 통신 링크를 통하여 다트들(Darts), 프로시져들(procedures), 데이터 또는 콘텐트를 상기 시작 디바이스로 리턴(return)하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 리턴들은 리턴된 프로시져들, 데이터 또는 콘텐트 중의 적어도 하나와 완전한 다트들(complete Darts), 다트파트들(DartParts), 다트프로시져들(DartProcedures) 또는 다트이벤트들(DartEvents)의 하나 또는 그 조합을 포함하며, 상기 하나 또는 그 조합은 관련된 이벤트 파일을 이용하거나 이용하지 않고서 리턴되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 리턴은 리턴된 프로시져들, 데이터, 콘텐트 및/또는 다트 중의 적어도 하나를 포함하고 또한 발생된 에러를 나타내는 리턴 코드를 선택적으로 포함하며, 에러 코드를 이용하여 특정 에러 또는 불특정 에러 에러가 발생했음을 확인하고, 상기 에러 코드는 상기 특정 에러 및/또는 에러의 성질을 정정하거나 전달하는데 유용한 정보를 선택적으로 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 애플리케이션 코드가 다트(Dart), 다트프로시져(DartProcedure) 또는 상기 시작 디바이스 또는 프로그램의 전달 또는 실행을 개시하고 그 실행의 결과를 이용하기 위해 상기 시작 디바이스에 액세스한 디바이스들 상에서 실행될 수 있는, 소정 형태의 프로그램 중의 적어도 하나인 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 애플리케이션 코드가 다트(Dart), 다트프로시져(DartProcedure) 또는, 실행할 수 있거나 아니면 상기 도달가능한 디바이스(들)로 상기 도달가능한 디바이스 상에서 실행되도록 프로시쥬얼 포맷이 상기 다트인스트럭션세트를 이용하는지의 여부에 대한 정보를 전달하는 제2 프로시쥬얼 포맷을 포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 장치들의 모집된 팀이 상기 애플리케이션을 실행하기 위한 소정 주기 동안의 요구에 따라 다른 도달가능한 디바이스들을 포함하도록 그 팀을 확장하거나 도달가능한 디바이스들을 배제하도록 그 팀을 축소하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 분배는 다트들(Darts), 다트프로시져들(DartProcedures), 데이터, 콘텐트 또는 다른 정보들 또는 이들의 소정 조합 중의 적어도 하나를 전달하는 것에 의해 수행되며, 이들은 필드(field)에 의해 참조된 정보가 상기 이벤트를 따라 또는 그 이벤트로서 전달되는지에 따라 다트 이벤트들(DartEvents)의 일부로서 인캡슐레이트되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 시작 애플리케이션의 요구들에 따라 디바이스들의 팀들 사이에서 분배되는 상기 코드, 데이터 및 콘텐트는, 상기 시작 애플리케이션의 목적을 더 수행하도록 상기 디바이스들의 팀에 걸쳐서 수행될 동작들을 수행 또는 조정(coordinate)하는데 필요한 추가적 또는 상이한 코드, 데이터 및 콘텐트를 선택적으로 교환하고 코드를 수행하여, 상기 시발 애플리케이션의 목적을 수행하도록 요구되는 동작들 및 리소스 액세스를 수행하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 애플리케이션이, 상기 모집 프로세스의 일부로서 모든 디바이스들에 분배되는 모든 코드를 포함하는, 단일한 이진 이미지로 구현되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상기 디바이스들의 팀 상의 동작들(activates)에 대한 싱크러니제이션(synchronization), 시리얼리제이션(serialization), 코오디네이션(coordination) 절차들을 더 포함하며, 상기 싱크러니제이션, 시리얼리제이션, 코오디네이션 절차들은 다트이벤트들(DartEvents) 또는 이벤트들과 관련된 파일로 이벤트들 또는 다트이벤트들을 단독적으로 또는 선택적으로 패싱(passing)하거나 교환하는 것에 의해 전체적으로 또는 부분적으로 수행되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제43항에 있어서,

상기 이벤트들은 적어도 하나의 파일을 참조하여 소정 복잡도의 파일 이미지들을 가지는 파일(들)을 효과적으로 포함하거나 병합하며, 상기 파일 이미지들은 상기 이벤트 스트럭쳐 콘텐츠와 함께 전달되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제3항에 있어서,

상호 운용되고 통신하는 모집된 시작 디바이스들 간에 다트이벤트들(DartEvents)을 다트이벤트들 또는 이벤트들과 관련된 파일을 이용하여 단독적으로 또는 선택적으로 패싱하거나 교환하는 단계를 더 포함하되, 상기 이벤트들은 상기 다트이벤트 스트럭쳐(DartEvent structure)에서의 파일 식별자 (field) 참조에 의해 파일들, 기타 다른 데이터들 또는 소정 복잡도의 데이터 스트럭쳐들을 효과적으로 포함하며, 상기 파일 이미지들은 참조되는 경우에는 항상 상기 이벤트 스트럭쳐 콘텐츠와 함께 전달되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제43항에 있어서,

상기 다트이벤트들 또는 이벤트들이 상기 다트프레임워크(DartFramework), 다트런타임(DartRuntime) 및/또는 다트엔진(DartEngine)에 의해 또는 넌-다트플랫폼 특정 이벤트 구동 수단(non-DartPlatform specific event driven implementation)에 의해 소정 개수의 팀 디바이스들의 이벤트 큐들(queues)에 걸쳐서 자동적으로 복사 및/또는 동기화되어서, 자동 싱크러니제이션을 위해 확인되고 다트에 의해 이벤트 큐 상에 위치하는 다트이벤트들 또는 이벤트들이 자동적이고 연속적이며 동기적인 방식으로 소정 개수의 팀 장치들의 이벤트 큐들 내부에서 발생되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제46항에 있어서,

시작 디바이스를 포함하는 다수의 상호 운용 디바이스들에 걸쳐서 동작하는 이벤트 구동 상호 운용 애플리케이션들(event driven cooperative applications), 기능들 또는 렌디션들에 대한 자동 시리얼리제이션 및 싱크러니제이션을 위한 프로시져에 의해 상기 자동 시리얼리제이션 및 싱크러니제이션 과정이 이루어지되,

요구되는 인터-디바이스 상호운용 기능(inter-device cooperative function) 각각을 위한 애플리케이션에 의해 상기 시작 디바이스 상의 연결 관리기 오브젝트 인스턴스(connection manager object instance)을 인스텐쉬에이팅(instantiating)하는 단계와;

상기 애플리케이션에 의해 절차적으로 모든 상호운용 디바이스들에 대하여 동기화되는 이벤트 타입들의 리스트를 상기 연결 관리기로 전달하는 단계와;

각 디바이스 상에 하나의 연결 관리기를 구비하는 상호운용 디바이스들의 팀을 구성하고 동일한 리스트의 싱크러니제이션 이벤트 타입들을 공유하는 단계; 및

상기 연결 관리기에 의해 팀 구성된 장치들과 동기화되는 이벤트 타입들을 확인하기 위한 세션(sessions) 리스트를 유지하고, 상기 연결 관리기에 의해 상기 이벤트 큐에 위치하는 모든 이벤트들을 검사하며, 검사된 특정 이벤트가 상기 동기화되어져야 할 세션 리스트로부터 상기 연결 관리기가 알게 되는 이벤트 타입인 경우, 상기 다른 세션들과 동기화되는 이벤트로서 상기 이벤트를 마킹하고 상기 이벤트를 상기 연결 관리기 내에서 리스트된 장치들의 이벤트 큐들에 위치시키는 단계를;

포함하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제47항에 있어서,

상기 이벤트 구동 상호운용 애플리케이션들, 기능들 또는 렌디션들 중의 어느 하나에 의해 상호운용 디바이스 이벤트 큐들상에 위치하는 모든 이벤트들이, 상기 어느 하나의 디바이스에 의해 직접적으로 상기 이벤트가 전달된 모든 상호운용 디바이스 이벤트 큐들이 상기 상호운용 디바이스들의 이벤트 큐들 상에 성공적으로 위치되었다는 긍정응답(acknowledgement)을 수신할 때까지, 이벤트가 상기 어느 하나의 디바이스의 이벤트 큐 상에 위치하는 것을 허용하지 않음으로써, 시리얼라이즈(serialize)되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제48항에 있어서,

상기 이벤트 구동 상호운용 애플리케이션들, 기능들 또는 렌디션들 중의 어느 하나에 의해 수신되는 상호운용 디바이스 이벤트 큐들상에 위치하는 모든 이벤트들이, 상기 어느 하나의 수신 디바이스에 의해 상기 이벤트가 전달된 모든 상호운용 디바이스 이벤트 큐들이 상기 상호운용 디바이스들의 이벤트 큐들 상에 성공적으로 위치되었다는 긍정응답(acknowledgement)을 수신할 때까지, 이벤트가 상기 어느 하나의 수신 디바이스의 이벤트 큐 상에 위치하는 것을 허용하지 않음으로써, 시리얼라이즈(serialize)되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제48항에 있어서,

상기 디바이스들이 직접적으로 통신하는지 아니면 직접적으로 통신하는 디바이스들의 체인(chain)을 통해 간접적으로 통신하는지에 따른 소정 개수의 상호운용 디바이스들의 이벤트 큐들이 모든 상호운용 디바이스들에 걸쳐서 큐잉된(queued) 이벤트들의 시리얼라이즈된 단일 시스템을 설정하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제49항에 있어서,

상기 디바이스들이 직접적으로 통신하는지 아니면 직접적으로 통신하는 디바이스들의 체인(chain)을 통해 간접적으로 통신하는지에 따른 소정 개수의 상호운용 디바이스들의 이벤트 큐들이 모든 상호운용 디바이스들에 걸쳐서 큐잉된(queued) 이벤트들의 시리얼라이즈된 단일 시스템을 설정하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제47항에 있어서,

둘 이상의 상호운용 디바이스들로부터의 상기 상호운용 디바이이스들의 큐들상에 위치하는 이벤트들이, 오직 하나의 마스터 디바이스만이 상기 타입들의 상기 이벤트들을 동기화되는 이벤트 타입들의 리스트 내에 위치시키도록 허용되어 그러한 모든 이벤트들이 모든 상호운용 디바이스들에 걸쳐서 시리얼라이즈되는, 시스템에 의해 상기 상호운용 디바이스들의 큐들 내의 이벤트들의 단일 시리얼리제이션으로 동기화되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제52항에 있어서,

상기 마스터 디바이스는, 상기 의도된 이벤트를 모든 상호운용 디바이스들의 큐들의 내부로 위치시키는데 필요한 모든 정보를 포함하는, 마스트 요청 이벤트 타입 이벤트(master request event type event)를 거쳐서 다른 상호운용 디바이스들 을 대신하여 상기 이벤트들을 통지 받아서 생성시키는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제52항에 있어서,

상호운용 디바이스들의 세트 내부의 다른 디바이스에 의해 상호운용 디바이스들의 팀 내부로 모집된 각각의 디바이스는 그것의 상대적인 마스터 디바이스가 그것을 리크루트했던 장치라고 간주하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제53항에 있어서,

상호운용 디바이스들의 세트 내부의 다른 디바이스에 의해 상호운용 디바이스들의 팀 내부로 모집된 각각의 디바이스는 그것의 상대적인 마스터 디바이스가 그것을 리크루트했던 장치라고 간주하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제54항에 있어서,

마스터 요청 이벤트 타입 이벤트를 상대적인 마스터 디바이스의 큐 내부로 위치시키는 것에 의해, 상대적인 마스터가 없는 시작 마스터 디바이스가 상기 마스터 디바이스을 위해 필요한 정보를 이용하여 이벤트를 형성하고 상기 의도된 이벤트를 모든 상호운용 디바이스들의 내부로 위치시킬때 까지, 상기 이벤트가 소정 디 바이스로부터 상대적인 마스터 디바이스로 전달되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제52항에 있어서,

상기 지정된 마스터 디바이스는, 새로운 마스터 디바이스가 현재의 마스터 디바이스를 대체하는 동기화되고 시리얼라이즈된 방식으로 모든 디바이스들에게 알리는 시리얼라이즈된 이벤트들의 리스트 상에 존재하는, 변경 마스터 타입 이벤트(change master type event)를 상호운용 디바이스들의 동기화되거나 시리얼라이즈된 큐들에 생성함으로써 변경되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제54항에 있어서,

상기 마스터 요청 이벤트는 상기 새로운 마스터 디바이스가 상기 이벤트를 처리할 때까지 상호운용 디바이스들의 큐들을 통해 전달되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제55항에 있어서,

상기 마스터 요청 이벤트는 상기 새로운 마스터 디바이스가 상기 이벤트를 처리할 때까지 상호운용 디바이스들의 큐들을 통해 전달되는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
제53항에 있어서,

상기 마스터 요청 이벤트 타입 이벤트에 의해 전달되는 것으로 구체화된 상기 이벤트의 일부로서 확인된 상기 선택적 파일은, 그러한 파일 레퍼런스(reference)가 존재하는 경우에, 마치 상기 마스터에 의해 전달된 상기 이벤트의 일부로서 전달되었던 것처럼, 상기 마스터에 의해 전달된 이벤트와 재결합되는 것을 허용하는 식별자를 가지는 전달(propagating) 디바이스 각각에서 유지되며, 이를 통해 상기 마스터에 의해 처리된 마스터 요청 이벤트 타입의 결과로서 전달된 각각의 이벤트의 일부로서 전달되어야만 했던 정보의 양을 감소시키는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
메모리와 결합되며 의도된 태스크의 수행을 위한 인스트럭션들을 포함하는 프로시져를 실행하도록 적응되는 프로세서와;

상기 의도된 태스크의 수행에 참여한 장치들과는 다르고 그 외부에 위치하며 상기 의도된 태스크의 수행 버젼(version)에 필요한 하드웨어 리소스들을 적어도 포함하는 적어도 하나의 모집된 디바이스를 리크루트하기 위한 메모리와 상기 프로세서 내에서 적어도 부분적으로 실행하기 위한 수단과;

상기 하드웨어 리소스들과 실시 보완 리소스들(enabling supplemented resources)이 상기 모집된 장치를 상기 의도된 태스크를 수행하도록 충분히 인에이블하도록 상기 모집된 장치의 리소스들을 보완하기 위한 장치의 내부에 완전히 저 장된 수단을;

포함하는 것을 특징으로 하는 이니쉬에이팅 장치.
제61항에 있어서,

상기 장치 및 상기 모집된 디바이스 각각이 공통적인 절차 환경에서 동작하며, 상기 리크루팅을 위한 메모리 및 프로세서 내부에서 적어도 부분적으로 실행하기 위한 수단이 상기 공통적인 절차 환경에서 구현되는 프로시져를 적어도 하나의 연결을 통해 역시 상기 공통적인 절차 환경에서 동작하는 다른 디바이스들로 방송하기 위한 수단을 포함하는 것을 특징으로 하는 상기 이니쉬에이팅 장치.
제62항에 있어서,

상기 리크루트 수단이, 다른 디바이스들 상에서의 프로시져의 실행을 시작시켜서 상기 다른 디바이스들 각각의 리소스들 및 또는 능력들을 프로그램적으로 검사(inspect)함으로써 각각의 디바이스가 상기 특정 태스크의 수행에 참여하기 위해 필요한 자원과 능력을 구비하는지의 여부를 결정하기 위한, 수단을 더 포함하는 것을 특징으로 하는 상기 이니쉬에이팅 장치.
제63항에 있어서,

상기 검사(inspection)는, 상기 특정 디바이스 내부에 저장되거나 그 특정 디바이스에 대하여 계산된 장치 전용 하드웨어 앱스트랙션 레이어 정보(device specific hardware abstraction layer information)를 액세스함으로써, 적어도 부분적으로 다른 특정 디바이스 각각에서 수행되는 것을 특징으로 하는 상기 이니쉬에이팅 장치.
제64항에 있어서,

상기 보완을 위한 수단이, 각각의 디바이스를 인에이블시켜 그 자신의 상기 특정 태스크의 일부를 수행하도록 요청된, 실시 프로시져들, 데이터 및/또는 콘텐트를 전달하고 설치하기 위한 수단을 더 포함하는 것을 특징으로 하는 상기 이니쉬에이팅 장치.
제61항에 있어서,

상기 시작 및 다른 디바이스들에 걸쳐서 동작들을 일시적으로 또는 영구적으로 동기화하기 위한 수단을 더 포함하되, 상기 동기화를 위한 수단이 태스크 이벤트 큐와 그 태스크 이벤트 큐를 유지하기 위한 수단을 포함하는 것을 특징으로 하는 상기 이니쉬에이팅 장치.
프로세서와 그 프로세서에 결합된 메모리를 포함하는 하드웨어 리소스들의 세트와;

태스크들의 세트의 수행에 적합한 컴퓨터 프로그램 코드 리소스들과;

컴퓨터 프로그램 코드 통신과 데이터 통신 중의 적어도 하나를 포함하는 통 신을 수신하기 위한 수단을 포함하되,

상기 하드웨어 리소스들은 적어도 특정 태스크의 수행의 버젼을 수행할 수 있으나 상기 컴퓨터 프로그램 코드 리소스들은 요구되는 버젼과 상기 특정 태스크 또는 그 특정 태스크의 일 형태를 수행하는 방법을 최초에는 수행할 수 없으며,

상기 컴퓨터 프로그램 코드 통신은 상기 요구되는 버젼, 방법 또는 상기 특정 태스크의 일 형태를 수행할 수 있게 하는 보완(supplemental) 컴퓨터 프로그램 코드 리소들을 포함하는 것을 특징으로 하는 모집된 장치.
제67항에 있어서,

상기 모집된 장치 및 상기 시작 디바이스 각각이 공통적인 절차 환경에서 동작하는 것을 특징으로 하는 상기 모집된 장치.
제68항에 있어서,

상기 시작 디바이스로부터 수신된 상기 프로시져를 수행하여 프로그램적으로 상기 모집된 디바이스의 리소스들 및 능력들을 검사(inspect)함으로써 상기 모집된 장치가 상기 특정 태스크의 수행에 참여하는데 필요한 리소스 또는 능력을 구비하는 지의 여부를 결정하기 위한 수단을 더 포함하는 것을 특징으로 하는 상기 모집된 장치.
제69항에 있어서,

상기 검사는, 상기 모집된 디바이스 내부에 저장되거나 그 모집된 디바이스에 대하여 계산된 장치 전용 하드웨어 앱스트랙션 레이어 정보(device specific hardware abstraction layer information)를 액세스함으로써, 적어도 부분적으로 상기 모집된 디바이스 내부에서 수행되는 것을 특징으로 하는 상기 모집된 장치.
제70항에 있어서,

상기 모집된 디바이스를 인에이블시켜 그 자신의 상기 특정 태스크의 일부를 수행하도록 요청된, 실시 프로시져들, 데이터 및/또는 콘텐트를 설치하기 위한 수단을 더 포함하는 것을 특징으로 하는 상기 모집된 장치.
제61항에 있어서,

상기 시작 디바이스 및 상기 모집된 디바이스들에 걸쳐서 동작들을 일시적으로 동기화하기 위한 수단을 더 포함하되, 상기 동기화를 위한 수단이 태스크 이벤트 큐와 그 태스크 이벤트 큐를 유지하기 위한 수단을 포함하는 것을 특징으로 하는 상기 모집된 장치.
특정 태스크의 수행에 참여하는 다수의 이종 디바이스들 사이에서 통합된(integrated) 에드-혹(ad-hoc) 온-더-플라이(on-the-fly) 분산(distributed) 정보 프로세싱 시스템을 구성하는 방법에 있어서,

상기 특정 태스크의 수행에 참여하기 위한 리소스 또는 능력을 포함하는 다 른 모집된 디바이스들을 확인하기 위하여 적어도 하나의 통신 채널 및 프로토콜을 이용하여 메시지를 방송하는 것을 포함하는 과정으로서, 시작 디바이스에 의해 상기 분산 정보 프로세싱 시스템의 구성 과정을 시작시키는 단계와;

상기 모집된 디바이스들 각각이 그 자신의 상기 특정 태스크를 수행할 수 있도록 요구되는 프로시져들, 데이터 및 콘텐트 중의 적어도 하나를 상기 모집된 디바이스들 각각에 전달하는 단계를;

포함하는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제73항에 있어서,

상기 의도된 태스크의 수행에 참여한 장치들과는 다르고 그 외부에 위치하며 상기 의도된 태스크의 수행 버젼(version)에 필요한 하드웨어 리소스들을 적어도 포함하는 적어도 하나의 모집된 디바이스를 리크루트하기 위한 메모리와 프로세서 내에서 적어도 부분적으로 실행하기 위한 단계와;

상기 하드웨어 리소스들과 실시 보완 리소스들(enabling supplemented resources)이 상기 모집된 장치를 상기 의도된 태스크를 수행하도록 충분히 인에이블하도록 상기 모집된 장치의 리소스들을 보완하기 위한 프로시져 및 선택적 데이터를 상기 시작 디바이스의 내부에 완전히 저장하는 단계를;

더 포함하는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제74항에 있어서,

상기 시작 디바이스 및 상기 모집된 디바이스 각각이 공통적인 절차 환경에서 동작하며, 상기 리크루팅을 위한 메모리 및 프로세서 내부에서 적어도 부분적으로 실행하기 위한 상기 프로시져가 상기 공통적인 절차 환경에서 구현되는 프로시져를 적어도 하나의 연결을 통해 역시 상기 공통적인 절차 환경에서 동작하는 다른 디바이스들로 방송하기 위한 단계를 포함하는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제75항에 있어서,

상기 리쿠르팅 단계가,

다른 디바이스들 상에서의 프로시져의 실행을 시작시켜서 상기 다른 디바이스들 각각의 리소스들 및 또는 능력들을 프로그램적으로 검사(inspect)함으로써 각각의 디바이스가 상기 특정 태스크의 수행에 참여하기 위해 필요한 자원과 능력을 구비하는지의 여부를 결정하는 단계를 더 포함하는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제76항에 있어서,

상기 검사는 상기 특정 디바이스 내부에 저장되거나 그 특정 디바이스에 대하여 계산된 장치 전용 하드웨어 앱스트랙션 레이어 정보(device specific hardware abstraction layer information)를 액세스함으로써, 적어도 부분적으로 다른 모집된 디바이스 각각에서 수행되는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제77항에 있어서,

상기 보완 단계가 각각의 디바이스를 인에이블시켜 그 자신의 상기 특정 태스크의 일부를 수행하도록 요청된, 실시 프로시져들, 데이터 및/또는 콘텐트를 전달하고 설치하는 단계를 더 포함하는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제77항에 있어서,

상기 시작 및 다른 디바이스들에 걸쳐서 동작들을 일시적으로 또는 영구적으로 동기화하는 단계를 더 포함하되, 상기 동기화 단계가 태스크 이벤트 큐를 생성하고 유지하는 단계를 포함하는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제73항에 있어서,

상기 통신이 클라이언트-서버(client-server) 통신 인터액션(interaction)도 피어-투-피어(peer-to-peer) 통신 인터액션도 아닌 통신 및 인터액션인 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제73항에 있어서,

상기 모집은 에드-혹 디바이스, 서비스 및 리소스의 발견하는 과정을 수행하여 필요한 디바이스들을 확인하고, 실시 프로시져들 및 정보를 이벤트들을 이용하여 상기 디바이스들로 전달하며, 디바이스들이 팀을 지능적 및 효과적으로 구성하고, 이벤트들을 이용하여 상기 디바이스들의 팀을 조정(coordinate)해서 상기 소스 시작 디바이스 상에서 원래 동작하던 다트(Dart) 또는 애플리케이션의 목적을 달성하도록 하는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제73항에 있어서,

상기 분산 정보 처리 시스템은 상기 디바이스들의 물리적인 능력들의 일부 또는 전부를 액세스하고 대등하게 이용하는 것을 포함하는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제82항에 있어서,

상기 디바이스의 물리적인 능력들은, 프린트 능력, 팩스 능력, 디스플레이 능력, 뮤직 렌더링 능력, 비디오 렌더링 능력, 다른 디바이스들을 제어하는 능력, 디지털 또는 아날로그 데이터를 미디어에 저장하는 능력, 제품을 제조하는 능력, 제거(elimination)하는 능력, 사진을 찍는 능력, 또는 상기 디바이스들의 프로세싱 능력들에 의해 액세스되거나 모니터링되거나 제어될 수 있는 기타 다른 물리적 능력들을 선택적으로 포함하는, 세트로부터 선택되는 것을 특징으로 하는 상기 분산 정보 프로세싱 시스템의 구성 방법.
제1항에 있어서,

하나 이상의 디바이스 상에서 동작하는 상기 소프트웨어 애플리케이션은, 독립적으로 개발된 애플리케이션들 및/또는 독립적으로 분배된 애플리케이션들이 상기 상호운용 동작들을 수행하는데 사용되는 경우에 더 안정된 상호 운용성을 제공하기 위하여, 적어도 부분적으로 코드 및/또는 데이터 및/또는 콘텐트를 가지는 둘 이상의 디바이스들 상에서의 상호운용 동작들을 수행하는 것을 특징으로 하는 상기 디바이스 팀 모집 방법.
컴퓨터 시스템 또는 정보 기기와 관련되어 사용되는 것으로서 컴퓨터로 판독가능한 저장 매체 및 내장된(embedded) 컴퓨터 프로그램 메카니즘으로 구성되는 컴퓨터 프로그램 제품에 있어서,

상기 컴퓨터 프로그램 메카니즘이 상기 컴퓨터 시스템 또는 정보 기기가 소정의 방식으로 상호운용성을 위한 모집된 디바이스들의 팀을 리크루트하는 기능을 하도록 지시하는 프로그램 모듈을 포함하고,

상기 프로그램 모듈이,

시작 소스 디바이스 및 그 자체가 도달될 디바이스 모두에 공통되는 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 필요한 리소스 또는 능력을 가지는 디바이스를 발견하도록 동작하는 인스펙션 프로시져를, 적어도 하나의 통신 링크를 통해 상기 시작 소스 디바이스와는 다른 적어도 하나의 도달가능한 디바이스로 전달하는 단계와;

상기 시작 디바이스에서 도달가능한 디바이스들 각각으로부터의 리턴 응답을 통신 링크를 통해 간접적으로 또는 직접적으로 수신하는 단계와;

상기 시작 디바이스에서 실행되는 프로시져를 통해 도달가능한 모든 응답 디바이스들로부터 수신된 리턴 응답들을 분석하여 상기 소프트웨어 애플리케이션의 목적을 가장 잘 수행할 수 있는 상기 도달가능한 응답 디바이스들과 상기 시작 소스 디바이스의 능력들 및 리소스들의 조합을 확인하기 위한 유틸리제이션 플랜(utilization plan)을 결정하는 단계와;

상기 시작 디바이스에서 실행되는 애플리케이션 프로그램을 통해 코드, 데이터, 콘텐트 및/또는 다트(Dart) 중의 적어도 하나를 상기 결정된 유틸리제이션 플랜에 따라 필요한 리소스 또는 능력을 가지는 것으로 확인된 상기 도달가능한 각 디바이스들 중의 적어도 하나에 분배하는 단계를 위한 인스트럭션들을 포함하는 것을 특징으로 하는 상기 컴퓨터 프로그램 제품.
컴퓨터 시스템 또는 정보 기기와 관련되어 사용되는 것으로서 컴퓨터로 판독가능한 저장 매체 및 내장된(embedded) 컴퓨터 프로그램 메카니즘으로 구성되는 컴퓨터 프로그램 제품에 있어서,

상기 컴퓨터 프로그램 메카니즘이 상기 컴퓨터 시스템 또는 정보 기기가 단일한 가상 디바이스의 역할을 하면서 특정 태스크의 수행에 참여하는 다수의 이종 디바이스들 사이에서 통합된(integrated) 에드-혹(ad-hoc) 온-더-플라이(on-the-fly) 분산(distributed) 정보 프로세싱 시스템 소정의 방식으로 구성하는 프로그램 모듈을 포함하고,

상기 프로그램 모듈이,

상기 특정 태스크의 수행에 참여하기 위한 리소스 또는 능력을 포함하는 다른 모집된 디바이스들을 확인하기 위하여 적어도 하나의 통신 채널 및 프로토콜을 이용하여 메시지를 방송하는 것을 포함하는 과정으로서, 시작 디바이스에 의해 상기 분산 정보 프로세싱 시스템의 구성 과정을 시작시키는 단계와;

상기 모집된 디바이스들 각각이 그 자신의 상기 특정 태스크를 수행할 수 있도록 요구되는 프로시져들, 데이터 및 콘텐트 중의 적어도 하나를 상기 모집된 디바이스들 각각에 전달하는 단계를 위한 인스트럭션들을 포함하는 것을 특징으로 하는 상기 컴퓨터 프로그램 제품.
소프트웨어 애플리케이션을 개별 실행 가능한 이미지들의 세트로 분할하기 위한 방법에 있어서,

상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트(aspect)들을 수행하기 위한 잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하는 단계;

상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위해 필요한 디스팅트(distinct) 렌더링 또는 다른 런타임 요구 사항들에 따라 직면 할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하는 단계;

디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘텐트 및 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하는 단계;

어느 디바이스들과 이에 대응하여 개별적으로 할당된 실행 가능한 이미지들이 후보 디바이스들의 리스트, 자원들 및 능력들, 그리고 요구되는 또는 바라는 환경 또는 작동 파라미터들이 주어진 경우 상기 애플리케이션의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 유틸리제이션 플랜(utilization plan)을 생성하는 단계; 및

상기 유틸리제이션 플랜을 디바이스의 각 클래스 및 각 환경 또는 운영 요구 사항에 대하여 구현하고 실행하기 위하여 필요한 데이터, 코드, 콘텐트 및 다른 디지털적으로 나타낼 수 있는 자원들을 특정하는 단계를 포함하는 것을 특징으로 하는 방법.
제87항에 있어서,

상기 소프트웨어 애플리케이션은 하나 또는 그 이상의 동종 또는 이종 통신 디바이스들간에서 동작되는 애플리케이션인 것을 특징으로 하는 방법.
제87항에 있어서,

상기 실행 가능한 이미지들 중 정확하게 하나가 선택되어 특정 환경의 주어진 디바이스에서 작동하는 것을 특징으로 하는 분할 방법.
제89항에 있어서,

상기 실행 가능한 이미지들 중에서 정확하게 하나가 선택되고, 선택된 이미지는 자원, 각 디바이스의 능력, 환경, 및 운영 요구 상황에 대한 상기 애플리케이션의 요구에 따라 각 디바이스에서 작동하는 것을 특징으로 하는 분할 방법.
제89항에 있어서,

상기 디바이스들 중 적어도 하나는 다트(Dart) 디바이스인 것을 특징으로 하는 분할 방법.
제87항에 있어서,

상기 생성된 유틸리제이션 플랜을 실행하는 단계를 더 포함하는 것을 특징으로 하는 분할 방법.
제87항에 있어서,

상기 소프트웨어 애플리케이션은 다트(Dart)로서 표현되는 것을 특징으로 하는 분할 방법.
제87항에 있어서,

상기 개별적으로 실행되는 이미지들은 렌디션들인 것을 특징으로 하는 분할 방법.
제93항에 있어서,

상기 렌디션들은 다트툴(DartTool)들에 의해 다트포맷(DartFormat)으로 패키지된 다트 렌디션(Dart Rendition)들의 형태로 표현되는 것을 특징으로 하는 분할 방법.
제88항에 있어서,

제1항의 유틸리제이션 플랜은 전체적으로 또는 부분적으로 상기 후보 디바이스들에서 작동되도록 전송된 프로시져들로서 실행되어 상기 디바이스의 특정 클래스, 자원들 및/또는 동작 환경을 결정하는 것을 특징으로 하는 분할 방법.
제96항에 있어서,

상기 프러시져들은 상호운영 명령 세트(Interoperability Instruction Set)의 명령들로서 적어도 일부분 구성된 다트프로시져(DartProcedure)들인 것을 특징으로 하는 분할 방법.
제97항에 있어서,

상기 상호운영 명령 세트는 다트인스트럭션세트(DartInstructionSet)인 것을 특징으로 하는 분할 방법.
제97항에 있어서,

상기 상호운영 명령 세트는 프로시져들이 실행되는 하나 또는 그 이상의 동종 또는 이종의 통신 디바이스들에서 실행 가능한 형태인 것을 특징으로 하는 분할 방법.
제99항에 있어서,

상기 통신 디바이스들은 상기 디바이스의 특정 클래스, 자원들 및/또는 운영 환경을 결정하기 위하여 프러시져들을 실행하는 것을 특징으로 하는 분할 방법.
제96항에 있어서,

상기 프로시져들은 상기 애플리케이션의 일부인 다트(Dart)들로서 표현되는 것을 특징으로 하는 분할 방법.
제101항에 있어서,

상기 애플리케이션은 이종의 통신 디바이스들에서 상기 애플리케이션의 목적을 이행하기 위해 사용되는 다른 다트(Dart)들을 포함하는 하나의 다트(Dart)로서 표현되는 것을 특징으로 하는 분할 방법.
제87항에 있어서,

제1항의 모집(recruitment) 방법은 이종 또는 동종의 디바이스들로 이루어진 팀(team)들을 형성하기 위하여 상기 프러시져들을 전송 및 분산하고 이미지들을 분할하는 데 사용되는 것을 특징으로 하는 분할 방법.
제87항에 있어서,

다른 타깃 디바이스들 및 프로세싱 환경들에서 개별적으로 실행되는 다른 이미지들간에 파트가 분배 가능하여 상호운영 애플리케이션의 크기가 제한될 수 있는 것을 특징으로 하는 분할 방법.
제87항에 있어서,

파트들이 개별적으로 실행되는 이미지들간에 분배 가능하여 상기 소프트웨어에 저장될 데이터의 양이 제한될 수 있는 것을 특징으로 하는 분할 방법.
제87항에 있어서,

파트들이 개별적으로 실행되는 이미지들간에 분배 가능하여 상기 디바이스들 간에 전송될 데이터의 양이 제한될 수 있는 것을 특징으로 하는 분할 방법.
제104항에 있어서,

상기 파트들은 코드, 데이터, 콘텐트, 프로시져들, 코드 세트들, 데이터 세트들, 콘텐트, 콘텐트 세트들, 상기 파트들을 어떻게 찾고 결합하는 지에 대한 메타 정보(meta information), 묘사적 텍스트(descriptive text), 그림들(pictures), 비디오, 이미지들, 데이터 테이블들, 또는 어떤 다른 단위의 정보 또는 디지털 방식을 표현될 수 있는 정보의 세트 중 하나인 것을 특징으로 하는 분할 방법.
제107항에 있어서,

상기 파트들은 다트파트들(DartParts)이고, 상기 메타 정보는 다트 렌디션즈테이블 파트(Dart RenditionsTable part), 및 또는 다트 렌디션테이블 파트들(Dart RenditionTable parts), 및 또는 다트 파트테이블(Dart PartTable), 및 또는 다트트레이러(DartTailer)로 표현되는 것을 특징으로 하는 분할 방법.
소프트웨어 애플리케이션을 개별 실행 가능한 이미지들의 세트로 분할하기 위한 방법에 있어서,

잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하는 단계;

직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하는 단계;

디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘텐트 및/또는 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하는 단계; 및

어느 디바이스들과 실행 가능한 이미지들이 상기 애플리케이션의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 유틸리제이션 플랜을 생성하는 단계를 포함하는 것을 특징으로 하는 방법.
소프트웨어 애플리케이션을 개별 실행 가능한 이미지들의 세트로 분할하기 위한 장치에 있어서,

상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위한 잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하기 위한 수단;

상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위해 필요한 디스팅트(distinct) 렌더링 또는 다른 런타임 요구 사항들에 따라 직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하기 위한 수단;

디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘텐트 및 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하기 위한 수단;

어느 디바이스들과 이에 대응하여 개별적으로 할당된 실행 가능한 이미지들이 후보 디바이스들의 리스트, 자원들 및 능력들, 그리고 요구되는 또는 바라는 환경 또는 작동 파라미터들이 주어진 경우 상기 애플리케이션의 목적을 수행하기 위 해 동작할 것인지를 선택하기 위한 유틸리제이션 플랜을 생성하기 위한 수단; 및

상기 유틸리제이션 플랜을 디바이스의 각 클래스 및 각 환경 또는 운영 요구 사항에 대하여 구현하고 실행하기 위하여 필요한 데이터, 코드, 콘텐트 및 다른 디지털적으로 나타낼 수 있는 자원들을 특정하기 위한 수단을 포함하는 것을 특징으로 하는 장치.
컴퓨터 시스템 또는 정보 기기(information appliance)와 결합하여 사용되기 위한 컴퓨터 프로그램 제품에 있어서, 상기 컴퓨터 프로그램 제품은 컴퓨터로 읽을 수 있는 저장 매체 및 상기 저장 매체에 구현된 컴퓨터 프로그램 메커니즘을 포함하며, 상기 컴퓨터 프로그램 메커니즘은,

상기 컴퓨터 시스템 또는 정보 기기가 특정 방식으로 작동하도록 하여 컴퓨터 프로그램 소프트웨어 코드 애플리케이션을 개별적으로 실행 가능한 컴퓨터 프로그램 소프트웨어 코드 이미지들의 세트로 분할하는 프로그램 모듈을 포함하며, 상기 프로그램 모듈은,

잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하는 단계;

직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하는 단계;

디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘텐트 및/또는 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하는 단계; 및

어느 디바이스들과 실행 가능한 이미지들이 상기 애플리케이션의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 유틸리제이션 플랜을 생성하는 단계를 위한 명령들을 포함하는 것을 특징으로 하는 컴퓨터 프로그램 제품.
컴퓨터 시스템 또는 정보 기기와 결합하여 사용되기 위한 컴퓨터 프로그램 제품에 있어서, 상기 컴퓨터 프로그램 제품은 컴퓨터로 읽을 수 있는 저장 매체 및 상기 저장 매체에 구현된 컴퓨터 프로그램 메커니즘을 포함하며, 상기 컴퓨터 프로그램 메커니즘은,

상기 컴퓨터 시스템 또는 정보 기기가 특정 방식으로 작동하도록 하여 컴퓨터 프로그램 소프트웨어 코드 애플리케이션을 개별적으로 실행 가능한 컴퓨터 프로그램 소프트웨어 코드 이미지들의 세트로 분할하는 프로그램 모듈을 포함하며, 상기 프로그램 모듈은,

상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위한 잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하는 단계;

상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위해 필요한 디스팅트(distinct) 렌더링 또는 다른 런타임 요구 사항들에 따라 직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하는 단계;

디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션 의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행할 데 필요한 데이터, 코드, 콘텐트 및 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하는 단계;

어느 디바이스들과 이에 대응하여 개별적으로 할당된 실행 가능한 이미지들이 후보 디바이스들의 리스트, 자원들 및 능력들, 그리고 요구되는 또는 바라는 환경 또는 작동 파라미터들이 주어진 경우 상기 애플리케이션의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 유틸리제이션 플랜을 생성하는 단계; 및

상기 유틸리제이션 플랜을 디바이스의 각 클래스 및 각 환경 또는 운영 요구 사항에 대하여 구현하고 실행하기 위하여 필요한 데이터, 코드, 콘텐트 및 다른 디지털적으로 나타낼 수 있는 자원들을 특정하는 단계를 위한 명령들을 포함하는 것을 특징으로 하는 컴퓨터 프로그램 제품.
소스 디바이스에서 동작하는 소프트웨어 애플리케이션으로 디바이스들의 팀을 모집하고 소프트웨어 애플리케이션을 개별 실행 가능한 이미지들의 세트로 분할하기 위한 방법에 있어서,

시작 소스 디바이스 및 그 자체가 도달될 디바이스 모두에 공통되는 실행가능한 형태로 코드된 인스펙션 프로시져 인스트럭션들을 포함하며 필요한 리소스 또는 능력을 가지는 디바이스를 발견하도록 동작하는 인스펙션 프로시져를, 적어도 하나의 통신 링크를 통해 상기 시작 소스 디바이스와는 다른 적어도 하나의 도달가능한 디바이스로 전달하는 단계;

상기 시작 디바이스에서 도달가능한 디바이스들 각각으로부터의 리턴 응답을 통신 링크를 통해 간접적으로 또는 직접적으로 수신하는 단계;

상기 시작 디바이스에서 실행되는 프로시져를 통해 도달가능한 모든 응답 디바이스들로부터 수신된 리턴 응답들을 분석하여 상기 소프트웨어 애플리케이션의 목적을 가장 잘 수행할 수 있는 상기 도달가능한 응답 디바이스들과 상기 시작 소스 디바이스의 능력들 및 리소스들의 조합을 확인하기 위한 유틸라이제이션 플랜(utilization plan)을 결정하는 단계;

상기 시작 디바이스에서 실행되는 애플리케이션 프로그램을 통해 코드, 데이터, 콘텐트 및/또는 다트(Dart) 중의 적어도 하나를 상기 결정된 유틸라이제이션 플랜에 따라 필요한 리소스 또는 능력을 가지는 것으로 확인된 상기 도달가능한 각 디바이스들 중의 적어도 하나에 분배하는 단계;

상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위한 잠재적 자원들 및 능력들에 따라 직면할 디바이스들을 클래스들로 분할하는 단계;

상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 수행하기 위해 필요한 디스팅트(distinct) 렌더링 또는 다른 런타임 요구 사항들에 따라 직면할 수 있는 환경 또는 운영 요구 사항들을 클래스들로 분할하는 단계;

디바이스의 각 클래스 및 환경 또는 운영 조건에 대하여 상기 애플리케이션의 목적의 하나 또는 그 이상의 애스펙트들을 실행 가능한 이미지를 이용하여 수행하 데 필요한 데이터, 코드, 콘텐트 및 다른 디지털적인 방식으로 나타낼 수 있는 자원들을 특정하는 단계;

어느 디바이스들과 이에 대응하여 개별적으로 할당된 실행 가능한 이미지들이 후보 디바이스들의 리스트, 자원들 및 능력들, 그리고 요구되는 또는 바라는 환경 또는 작동 파라미터들이 주어진 경우 상기 애플리케이션의 목적을 수행하기 위해 동작할 것인지를 선택하기 위한 유틸리제이션 플랜을 생성하는 단계; 및

상기 유틸리제이션 플랜을 디바이스의 각 클래스 및 각 환경 또는 운영 요구 사항에 대하여 구현하고 실시하기 위하여 필요한 데이터, 코드, 콘텐트 및 다른 디지털적으로 나타낼 수 있는 자원들을 특정하는 단계를 포함하는 것을 특징으로 하는 방법.