JP4809247B2

JP4809247B2 - 電子装置の構成方法

Info

Publication number: JP4809247B2
Application number: JP2006552704A
Authority: JP
Inventors: クラウスペデルセン; ヤコブハンセン
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2004-02-14
Filing date: 2004-02-14
Publication date: 2011-11-09
Anticipated expiration: 2024-02-14
Also published as: CN1914937A; JP2007535832A; US20070226749A1; BRPI0418564A; CN1914937B; EP1714508A1; WO2005086511A1; US8341302B2; CA2555183C; CA2555183A1; EP1714508B1

Description

本発明の複数の実施態様は、電子装置の構成に関する。具体的な複数の実施態様は、たとえば販売時点にある複数のセルラー式携帯電話機を構成するための標準的なプロセスに関する。

現在の傾向の１つは、電子装置により多くの特徴が設けられることである。この結果、電子装置の構成が難しいこともある。

装置を正しく、および／またはユーザの望みどおりに作動させるために、装置のユーザは装置の設定を構成するために相当の時間と手間を要することもある。この時間と手間が極めて大きくなりうることから、新しい装置がユーザに魅力的でないことがありうる。

これは、とりわけセルラー式携帯電話機について言えることである。携帯電話機は一般には、さまざまな運用業者によって管理されているさまざまなセルラー式無線電話網の何れかで使用するために構成できるように設計されている。ただし、電話機を正しく、または運用業者が望むように作動させるために、各運用業者がそれぞれ異なる設定を要求することもある。携帯電話機を必要な設定によってカスタマイズすることを運用業者（サービスプロバイダ）が望むこともある。また、携帯電話機は個人の装置であるので、ユーザがお気に入りの呼び出し音、インターネットブックマーク、スクリーンセーバーなどで電話機を構成したいと望むことが考えられる。

したがって、電子装置、特にセルラー式携帯電話機、のための何らかの自動セットアッププロセスを提供することが望ましい。

このセットアッププロセスは、複数の電子装置に使用でき、各電子装置固有の適応化が不要であることが望ましいであろう。たとえば、このセットアッププロセスをすべてのセルラー式携帯電話機または大半のセルラー式携帯電話機の初期構成に使用しうることが望ましいであろう。

発明者らは、１つのＳｙｎｃＭＬメッセージを用いてデータを対象装置に転送し、対象装置においてこの転送されたデータに基づき実行ファイルを実行すれば自動セットアップが可能になるのではないかと考えた。

ＳｙｎｃＭＬ（商標）ＤＭ（ＤｅｖｉｃｅＭａｎａｇｅｍｅｎｔ）は、世界共通のオープンな業界標準である。これによって、サービスプロバイダおよび企業の情報管理部門などの第三者は、管理ツリーを携帯装置に作成し、携帯装置に格納されている管理ツリーを管理することができる。「ＳｙｎｃＭＬ装置管理ツリーおよび解説（ＳｙｎｃＭＬＤｅｖｉｃｅＭａｎａｇｅｍｅｎｔＴｒｅｅａｎｄＤｅｓｃｒｉｐｔｉｏｎ）」のバージョン１．１．１、２００３年２月１０日（ｗｗｗ．ｓｙｎｃｍｌ．ｏｒｇ）には、管理ツリーの作成および管理について記載されている。管理ツリーは複数のノードを有し、これらのノードは複数の枝によって接続されている。ＵＲＩによって各ノードを一意にアドレス指定することができる。ノードは、インテリアノードまたはリーフノードにしうる。インテリアノードは、子（従属）ノードをいくつでも持てるが、どのような値も格納できない。リーフノードは、子（従属）ノードを一切持てないが、値を格納できる。文字列、ファイル、数字などが値となりうる。したがって、ＳｙｎｃＭＬＤＭは、データをオンザフライで携帯装置に提供するための機構を提供する。

「ＳｙｎｃＭＬ表現プロトコル（ＳｙｎｃＭＬＲｅｐｒｅｓｅｎｔａｔｉｏｎＰｒｏｔｏｃｏｌ）」のバージョン１．１、２００２年２月１５日（ｗｗｗ．ｓｙｎｃｍｌ．ｏｒｇ）には、ＤａｔａＭａｎａｇｅｍｅｎｔ（ＤＭ）プロトコルを含むすべてのＳｙｎｃＭＬプロトコルで使用可能な共通の拡張マークアップ言語（ＸＭＬ）構文と意味とが規定されている。これらのコマンドは、Ａｄｄ、Ｃｏｐｙ、Ｄｅｌｅｔｅ、Ｅｘｅｃ、Ｇｅｔ、Ｒｅｐｌａｃｅを含む。Ｅｘｅｃでは、コマンドの発信元は、指定した実行ファイルを受信側から呼び出すように要求できる。

「ＳｙｎｃＭＬ装置管理ツリーおよび解説（ＳｙｎｃＭＬＤｅｖｉｃｅＭａｎａｇｅｍｅｎｔＴｒｅｅａｎｄＤｅｓｃｒｉｐｔｉｏｎ）」のバージョン１．１．１、２００３年２月１０日（ｗｗｗ．ｓｙｎｃｍｌ．ｏｒｇ）には、管理ツリーを作成するためのＡｄｄの使用方法が記載されている。ＳｙｎｃＭＬＤＭでは、ＳｙｎｃＭＬＤＭを使用して特定のデータに対して実行ファイルを実行する方法が規定されていない。ｅｘｅｃコマンドはｉｔｅｍ要素を含み、ｉｔｅｍ要素はｔａｒｇｅｔ要素を含み、ｔａｒｇｅｔ要素はＬｏｃＵＲＩ要素を含む。ＬｏｃＵＲＩ要素は、装置内の実行ファイルの位置のみを指定する。したがって、ｅｘｅｃコマンドでは、実行ファイルが使用するデータを指定できない。

さらに、ｅｘｅｃコマンドでは、対象装置内の適切な実行ファイルを特定する必要がある。したがって、実行ファイルのＩＤをｅｘｅｃコマンドのＬｏｃＵＲＩ要素で指定するために、対象装置にある実行ファイルのＩＤを事前に知っておく必要がある。これは複雑かつ不便であり、単一のＳｙｎｃＭＬメッセージまたはパッケージを複数の携帯装置に対して使用することを妨げる。

１つの共通プロセスを、各装置固有の適応化を行わずに、複数の対象装置に対して実行するために適したＳｙｎｃＭＬコードの作成が望ましいであろう。

他の複数の装置に対しても再使用できるＳｙｎｃＭＬコードを使用して、特定のデータに対する実行ファイルの実行を指示できることが望ましいであろう。

本発明の一実施態様によると、電子装置を自動的に構成する方法であって、第１のデータを特定するコマンドを電子装置で受信するステップと、特定された第１のデータの特性を自動的に決定するステップと、決定された特性から実行ファイルを自動的に特定するステップと、特定された第１のデータに基づき、特定された実行ファイルを使用して操作するステップとを含む方法が提供される。

本発明の別の一実施態様によると、セルラー式携帯電話機を構成する方法であって、階層ノード型データ構造の第１のリーフノードを特定するコマンドを含むコードをセルラー式携帯電話機に転送するステップと、特定された第１のリーフノードの特性を決定するステップと、決定された特性から実行ファイルを特定するステップと、特定された第１のリーフノードに格納されているデータに基づき、特定された実行ファイルを使用して操作するステップと、を含む方法が提供される。

本発明の別の一実施態様によると、複数のセルラー式携帯電話機を構成する方法であって、
複数のリーフノードと複数のインテリアノードとを有し、第１のリーフノードに格納される第１のデータを含む階層ノード型データ構造を電子装置に作成するための複数のコマンドと、第１のリーフノードを特定する第１のコマンドとを含む再使用可能なコードをセルラー式携帯電話機に転送するステップと、
特定された第１のリーフノードの特性を決定するステップと、
決定された特性から実行ファイルを特定するステップと、
第１のリーフノードに格納されている第１のデータに基づき、特定された実行ファイルを使用して操作するステップと、を含む方法が提供される。

本発明の別の一実施態様によると、自動構成用に構成されているセルラー式携帯電話機であって、第１のデータを格納する手段と、第１のデータを特定するコマンドを受信する手段と、特定された第１のデータの特性を決定する手段と、決定された特性から実行ファイルを特定する手段と、特定された第１のデータに基づき、特定された実行ファイルを使用して操作する手段と、を含むセルラー式携帯電話機が提供される。

本発明の別の一実施態様によると、複数の異なるセルラー式携帯電話機のセットアップに再使用されるデータ構造であって、第１のデータを特定し、第１のデータに基づき未特定の実行ファイルを実行することを指定するコードを含むデータ構造が提供される。

本発明の別の一実施態様によると、複数の異なる電子装置のセットアップに再使用されるデータ構造であって、複数のリーフノードと複数のインテリアノードとを有し、第１のリーフノードに格納される第１のデータを含む階層ノード型データ構造を電子装置に作成するための複数のコマンドと、第１のリーフノードを特定し、第１のノードに格納された第１のデータに基づき未特定の実行ファイルを実行することを指定する第１のコマンドと、を含むデータ構造が提供される。

本発明の複数の実施態様は、対象装置に常駐している実行ファイルのＩＤを指定せずにその実行ファイルを実行することを可能にしうる。したがって、常駐している実行ファイルのＩＤが装置ごとに変わっても、ＳｙｎｃＭＬコードを再使用して１つの共通プロセスを複数の対象装置に対して実行することができる。

本発明の複数の実施態様では、指定されたデータに基づき対象装置に常駐する実行ファイルを使用しうる。

本発明の別の一実施態様によると、複数の異なる電子装置のセットアップに再使用されるデータを作成するシステムであって、複数のユーザフレンドリなコマンドの各々を、１つまたは複数のコマンドをそれぞれ含む複数の異なるコード部分に対応付ける手段を含むシステムが提供される。

本発明の理解を深めるために、以下に添付図面を単なる例として参照する。

図１は、セルラー式無線電話網１８経由でサーバ２０と通信する携帯装置１０を含むクライアント・サーバシステム２を示す。この実施形態においては、携帯装置１０はセルラー式携帯電話機であり、プロセッサ１１と、セルラー式無線送受信器１２と、メモリ１３と、キーパッドなどの入力装置１４と、ディスプレイ１５と、スマートカード１６と、音声出力装置１７とを備える。

プロセッサ１１は、携帯電話機１０を制御する。プロセッサ１１は、メモリ１３への書き込みおよびメモリ１３からの読み出しを行うように接続されている。プロセッサ１１は、キーパッド１４から入力データを受け取り、出力データをディスプレイ１５と音声出力装置１７とに出力する。プロセッサ１１は、セルラー式電話網１８、たとえばＧＳＭまたはＷＣＤＭＡ網、で通信できるように、セルラー式無線送受信器を制御する。プロセッサは、スマートカード１６にも接続される。スマートカード１６は、少なくともユーザ識別情報、たとえばユーザの電話番号またはＩＭＳＩなど、をプロセッサに提供する。メモリ１３に格納され、プロセッサ１１に読み込まれるソフトウェアによって、プロセッサ１１の動作が制御される。動作時、プロセッサは送受信器１２経由でデータを受信および送信し、メモリ１３に対してデータの書き込みおよび読み出しを行う。

他の実施形態においては、セルラー式携帯電話機はスマートカード１６を備えなくてもよく、および／または複数のプロセッサを備えうることを理解されたい。

サーバ２０は、セルラー式無線網１８に直接または間接的に接続された入出力インタフェース２１と、プロセッサ２２と、メモリ２３とを備える。サーバ２０はＳｙｎｃＭＬＤＭサーバである。サーバ２０は入出力インタフェース２１を介して携帯電話機１０にＳｙｎｃＭＬＤＭコマンドを発行し、携帯電話機１０からの応答を正しく解釈する。

携帯電話機１０において、プロセッサ１１は管理クライアント（ＭＣ）として動作し、管理ツリーのデータ構造１００をメモリ１３内に維持することができる。ＭＣは、サーバから受信したＳｙｎｃＭＬＤＭコマンドを正しく解釈し、携帯電話機１０内で適切な動作を実行し、適切な応答を送受信器１２経由で発行元の管理サーバに送り返す。

管理ツリーは階層ノード型データ構造であり、これを介して管理クライアントは携帯電話機１０とやり取りする。ＭＣは、このツリーに対して値の格納または取り出しを行うことができ、このツリーの特性を操作しうる。この管理ツリーは、複数の枝によって接続された複数のノードを有する。ＵＲＩによって各ノードを一意にアドレス指定できる。ノードはインテリアノードまたはリーフノードにしうる。インテリアノードは、任意の数の子（従属）ノードを持ちうるが、どのような値も格納できない。リーフノードは、子（従属）ノードを持てないが、値を格納できる。文字列、ファイル、数字などが値となりうる。

ＭＣは、管理ツリーを操作することができる。新しいノードを作成し、特定のリーフノードの値を変更することができる。リーフノードとインテリアノードとに対する同期ランタイムアクセスがある。

以下により詳しく説明するように、ＭＣは、サーバ２０からのセットアップコードの受信に応じて、自動セットアッププロセスの一環として「ｏｐｅｒａｔｏｒ」管理オブジェクトを作成する。図３に示すように、この例においては、この「ｏｐｅｒａｔｏｒ」管理オブジェクト１０２は、管理ツリー１００のルート１０４からぶら下がっているサブツリーであり、セットアッププロセス中に使用される。

自動セットアッププロセスは、たとえば、スマートカード１６をセルラー式携帯電話機１０に挿入することによって開始してもよい。スマートカード１６は、自動セットアッププロセスを起動するために必要な情報を含んでいる。携帯装置１０は、図３に示すように、ダウンロード開始メッセージ６０をサーバ２０に送る。

サーバ２０は、適応化しなくても複数の装置で使用可能なセットアップコード５０をメモリ２３に格納している。サーバ２０は、ダウンロード開始メッセージに応じて、ＳｙｎｃＭＬＤａｔａＭａｎａｇｅｍｅｎｔ（ＤＭ）セッション６２を開始する。ＤＭセッション６２は、格納されているセットアップコード５０を携帯装置１０に転送するために使用される。

ダウンロード開始メッセージ６０は、ＳＭＳ（ＳｈｏｒｔＭｅｓｓａｇｅＳｅｒｖｉｃｅ）メッセージなどの何れか適切な手段によって送ってよく、あるいは装置が携帯電話機能のない携帯情報端末である場合は、ＩＲ、Ｂｌｕｅｔｏｏｔｈ、またはＵＳＢなどのシリアルデータ接続で送ってもよい。

セットアップコードは、ＳＭＳ（ＳｈｏｒｔＭｅｓｓａｇｅＳｅｒｖｉｃｅ）メッセージなどの何れか適切な手段によって送ってよく、あるいは装置が携帯電話機能のない携帯情報端末である場合は、ＩＲ、Ｂｌｕｅｔｏｏｔｈ、またはＵＳＢなどのシリアルデータ接続で送ってもよい。

セットアップコード５０を図４に図式的に示す。セットアップコード５０は、複数の異なる携帯装置のセットアップに再使用されるデータ構造である。

この例においては、セットアップコード５０は２つの部分を含む。これらの部分は、論理的に別個のものであるが、インタリーブさせうる。第１の部分５２は、管理ツリーの作成または既存の管理ツリーの更新のための部分である。第２の部分５４は、実行ファイルを実行するための部分である。

既存の管理ツリーを更新するための第１の部分５２は、管理ツリーのインテリアノードを作成するためのサブ部分と、管理ツリーのリーフノードを作成するためのサブ部分とを含む。

一例として、このコードは、次のコードに似たＸＭＬコードを使用して、ルート１０４からぶら下がったインテリアノード「Ｏｐｅｒａｔｏｒ」１０６を作成しうる。

<Add>
<CmdID>1</CmdID>
<Item>
<Meta>
<Format xmlns='syncml:metinf'>node/<Format>
<Type xmlns='syncml:metinf'>interior/<Type>
</Meta>
<Target>
<LocURI>/Operador</LocURI>
</Target>
</Item>
</Add>

一例として、このコードは引き続き、次のコードに似たＸＭＬコードを使用して、「Ｏｐｅｒａｔｏｒ」ノード１０６からぶら下がったインテリアノード１０８を作成しうる。

<Add>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format xmlns='syncml:metinf'>node/<Format>
<Type xmlns='syncml:metinf'>interior/<Type>
</Meta>
<Target>
<LocURI>/Operator/ring_tones</LocURI>
</Target>
</Item>
</Add>

一例として、このコードは、次のコードに似たＸＭＬコードを使用して、ノード１０８からぶら下がったリーフノード１１０を作成しうる。

<Add>
<CmdID>3</CmdID>
<Item>
<Meta>
<Format xmlns='syncml:metinf'>format/<Format>
<Type xmlns='syncml:metinf'>MIDI ringing tone/<Type>
</Meta>
<Target>
<LocURI>/Operator/ring_tones/smashhit#1</LocURI>
</Target>
<Data>the data</Data>
</Item>
</Add>

ここで、ｔｈｅｄａｔａは、ｆｏｒｍａｔで定義されたフォーマットでｓｍａｓｈｈｉｔ＃１呼び出し音を作成するためのデータである。

実行ファイルを実行するための第２の部分５４は、実行ファイルを実行するためのサブ部分を複数含む。これらのサブ部分の順番によって、実行ファイルの実行の順番が決まる。これらのサブ部分の少なくとも一部は、特定のデータを用いて実行ファイルを実行することを指定する。一例として、このようなサブ部分のコードは、次のコードに似たＸＭＬコードにしうる。

<Exec>
<CmdID>3</CmdID>
<Item>
<Source>
<LocURI>/Operator/ring_tones/smashhit#1</LocURI>
</Source>
</Item>
</Add>

このｅｘｅｃコマンドは、「ｓｏｕｒｃｅ」内に含まれているデータ、すなわちｓｍａｓｈｈｉｔ＃１呼び出し音に基づき、未特定の実行ファイルを実行することを指定している。このＥｘｅｃコマンドは使用すべき実行ファイルを指定していないので、このコマンドの意味は、このコマンドによって特定されたデータの内容種別に応じて決まることに注目されたい。

セルラー式携帯電話機のＤＭクライアントは、受信したセットアップコード５０を処理する。既存の管理ツリーを更新するための部分５２は、ＳｙｎｃＭＬＤＭ仕様に従って処理される。したがって、ＤＭクライアントは、この例によると、図２に示すように、ルートからぶら下がったサブツリー１０２を作成する。

実行ファイルを実行するための部分５４は、次のように処理される。コードが構文解析されて、第１のサブ部分が特定される。第１のサブ部分が構文解析されて、要素ｓｏｕｒｃｅに含まれている要素ＬｏｃＵＲＩによって指定されるＵＲＩが特定される。要素ＬｏｃＵＲＩは、管理ツリーに新しく作成されたサブツリー内のリーフノードを特定する。

ＤＭクライアントは、特定されたリーフノードにアクセスする。上の例では、Ｏｐｅｒａｔｏｒ／ｒｉｎｇ＿ｔｏｎｅｓ／ｓｍａｓｈｈｉｔ＃１にアクセスする。ＤＭクライアントは、特定されたリーフノードの特性、具体的にはｍｅｔａ内に含まれている特性を読み出す。

ＤＭクライアントは、特定されたリーフノードに格納されているデータの内容種別を特定するために、Ｆｏｒｍａｔ要素の内容および／またはＴｙｐｅの内容を使用する。

ＤＭクライアントは、たとえばルックアップテーブルを使用して、可能なＦｏｒｍａｔおよびＴｙｐｅを携帯電話機に常駐している複数の異なる実行ファイルに対応付ける。このように、ＤＭクライアントは、リーフノードのＦｏｒｍａｔおよび／またはＴｙｐｅを使用して、特定された１つのリーフノードを１つの実行ファイルに対応付けることができる。したがって、サウンドファイルを格納しているリーフノードは、オーディオプレーヤに対応付けられ、ビデオファイルを格納しているリーフノードは、ビデオプレーヤに対応付けられ、画像ファイルを格納しているリーフノードは、画像ビューワに対応付けられ、Ｊａｖａ（登録商標）Ｍｉｄｌｅｔを格納しているリーフノードは、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）に対応付けられ、リーフノードが連絡先の場合は、その連絡先を電話機の連絡先リストに追加する実行ファイルに対応付けられ、リーフノードがブックマークの場合は、そのブックマークを電話機のブックマークリストに追加する実行ファイルに対応付けられる。

ＳｙｎｃＭＬＤＭは、以下のコマンドを含むさまざまなコマンドを使用する。
Ａｄｄ：コマンドの発信元は、このコマンドに含まれている単一または複数のデータ要素を受信側がアクセス可能なデータに追加するように要求できる。たとえば、このコマンドをサーバから携帯端末に送ると、ノードをＤＭツリーに追加しうる。
Ｃｏｐｙ：コマンドの発信元は、このコマンドに含まれている、受信側がアクセス可能な単一または複数のデータ要素のコピーを要求できる。
Ｄｅｌｅｔｅ：コマンドの発信元は、このコマンドに含まれている、受信側がアクセス可能な単一または複数のデータ要素の削除を要求できる。たとえば、このコマンドをサーバから携帯端末に送ると、ノードをＤＭツリーから削除しうる。
Ｅｘｅｃ：コマンドの発信元は、指定または供給した実行ファイルを受信側から呼び出すように要求できる。
Ｇｅｔ：コマンドの発信元は、受信側に対して単一または複数のデータ要素を要求できる。たとえば、このコマンドを携帯端末からサーバに送ると、ＤＭツリーのノードの内容を取得しうる。
Ｒｅｐｌａｃｅ：発信元は、受信側がアクセス可能な単一または複数のデータ要素の上書きを要求できる。

ＳｙｎｃＭＬＤＭでは、コマンドごとに特殊な構文を使用する必要がある。各運用業者にとっては、ＳｙｎｃＭＬＤＭコマンド群とそれらの構文についての詳細な知識がなくとも、適切なセットアップコード５０を簡単に作成できることが望ましいであろう。これを行うコンピュータプログラムをサーバ２０に用意してもよい。このコンピュータプログラムは、単純なユーザフレンドリなコマンドを該当する正しい構文のＳｙｎｃＭＬＤＭコマンドに変換するマクロを効果的に提供する。

このコンピュータプログラムは、たとえば、以下のオプションを運用業者に与えうる。
ａ）Ｘのインストール
ｂ）Ｘのプレビュー（インストールあり）
ｃ）Ｘのプレビュー（インストールなし）
ｄ）Ｘの実行（インストールが暗黙で含まれる）

このコンピュータプログラムは、これらのオプションをたとえば次のコマンドに変換する。
ａ）ＳｙｎｃＭＬＡｄｄコマンド
ｂ）ＳｙｎｃＭＬＡｄｄコマンドと、これに続くＳｙｎｃＭＬＥｘｅｃコマンド
ｃ）ＳｙｎｃＭＬＡｄｄコマンドと、これに続くＳｙｎｃＭＬｅｘｅｃコマンド、およびこれに続くＳｙｎｃＭＬＤｅｌｅｔｅコマンド
ｄ）ＳｙｎｃＭＬＥｘｅｃコマンド

上の各段落では、さまざまな例を参照しながら本発明の複数の実施形態を説明してきたが、請求の範囲に記載されている本発明の範囲から逸脱することなく上記の各例を変更できることを理解されたい。たとえば、携帯電話機に関して説明してきたが、ユーザが構成可能な何れの電子装置にも本発明を適用できることを理解されたい。本発明は、携帯電話機および携帯情報端末などの携帯装置に特に適しているが、たとえばパーソナルコンピュータにも適用しうる。

上記の明細書本文においては本発明の特に重要と思われる特徴に注意を引くように努めたが、出願人は、特に強調されているか否かにかかわらず、上で言及した、および／または図面に示した特許可能なあらゆる特徴またはこれらの組み合わせに対する保護を請求する。

サーバ２０と通信する携帯装置を含むクライアント・サーバシステムを示す。管理ツリーのデータ構造を示す。セットアップコードのダウンロードのための信号方式図である。セットアップコード５０の内容を概略的に示す。

Claims

ＳｙｎｃＭＬＤＭプロトコルにおける第１のリーフノードに格納されている第１のデータに基づく実行ファイルの実行を指定する、異なる複数の電子装置において再使用可能なコマンドであって、前記実行ファイルを当該コマンドにおいて特定しないコマンドをサーバから電子装置で受信するステップと、
前記第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記第１のデータに基づき、前記特定された実行ファイルを使用して操作するステップと、を含む方法。
請求項１に記載の方法であって、前記コマンドが前記第１のデータの識別子を含む方法。
請求項２に記載の方法であって、前記識別子が階層ノード型データ構造のノードを特定する方法。
請求項３に記載の方法であって、前記コマンドがｅｘｅｃコマンドであり、前記識別子が前記ｅｘｅｃコマンドに含まれているｓｏｕｒｃｅ要素に含まれているＵＲＩである方法。
請求項１ないし４の何れか１項に記載の方法であって、前記コマンドがＸＭＬコードとして受信される方法。
請求項５に記載の方法であって、前記コマンドがＳｙｎｃＭＬコマンドである方法。
請求項１ないし６の何れか１項に記載の方法であって、前記第１のデータが電子装置に格納される方法。
請求項１ないし７の何れか１項に記載の方法であって、前記内容種別を決定する前記ステップが前記第１のデータに対応付けられている少なくとも一つのＦｏｒｍａｔ要素の値および／またはＴｙｐｅ要素の値を使用する方法。
請求項１ないし８の何れか１項に記載の方法であって、複数の異なる内容種別の各々を複数の異なる実行ファイルに対応付けるステップをさらに含む方法。
請求項９に記載の方法であって、前記複数の異なる実行ファイルが前記電子装置に格納される方法。
請求項１ないし１０の何れか１項に記載の方法であって、前記第１のデータに基づく実行ファイルの実行を指定する前記コマンドを受信するステップの前に、前記第１のデータを含む階層ノード型データ構造を前記電子装置に作成するためのコマンドを受信するステップをさらに含む方法。
ＳｙｎｃＭＬＤＭプロトコルにおける階層ノード型データ構造の第１のリーフノードに格納された第１のデータに基づく実行ファイルの実行を指定する、異なる複数の電子装置において再使用可能なコマンドであって、前記実行ファイルを当該コマンドにおいて特定しないコマンドを含むコードをサーバから電子装置に転送するステップと、
前記第１のデータの内容種別を前記第１のリーフノードのメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記特定された第１のリーフノードのメタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記特定された第１のリーフノードに格納されている第１のデータに基づき、前記特定された実行ファイルを使用して操作するステップと、を含む方法。
異なる複数の電子装置において再使用可能なコードをサーバから電子機器で受信するステップであって、前記コードが、
ＳｙｎｃＭＬＤＭプロトコルにおける複数のリーフノードと複数のインテリアノードとを有し、第１のリーフノードに格納される第１のデータを含む階層ノード型データ構造を前記電子装置に作成するための複数のコマンドと、
前記第１のリーフノードに格納された第１のデータに基づく実行ファイルの実行を指定する更なるコマンドであって、前記実行ファイルを当該コマンドにおいて特定しないコマンドと、を含むステップと、
前記第１のリーフノードに格納された第１のデータの内容種別を前記第１のリーフノードに格納されたメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記第１のリーフノードに格納されたメタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記第１のリーフノードに格納されている前記第１のデータに基づき、前記特定された実行ファイルを使用して操作するステップと、を含む方法。
ＳｙｎｃＭＬＤＭプロトコルの第１のリーフノードに第１のデータ及び前記第１のリーフノードのメタデータを格納するメモリと、
前記第１のデータに基づく実行ファイルの実行を指定する、異なる複数の電子装置において再使用可能なコマンドであって、前記実行ファイルを当該コマンドにおいて特定しないコマンドをサーバから受信する受信器と、
前記第１のデータの内容種別を第１のリーフノードのメタデータから決定し、内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定し、前記第１のデータに基づき、前記特定された実行ファイルを使用して操作するプロセッサと、を含む電子機器。
請求項１４に記載の電子装置であって、
前記受信器はセットアップコードを受信し、前記プロセッサは、複数のリーフノードと複数のインテリアノードとを有し、前記第１のデータを格納する第１のリーフノードを含む階層ノード型データ構造を作成するために、前記受信したセットアップコードを解釈する電子装置。
請求項１５に記載の電子装置であって、前記受信器は、セットアップコードにおけるコマンドを受信し、前記プロセッサは、前記第１のデータの内容種別を前記第１のリーフノードのメタデータから決定するために前記コマンドを解釈する電子装置。
ＳｙｎｃＭＬＤＭプロトコルにおける第１のリーフノードに格納されている第１のデータを特定し、前記第１のデータに基づく実行ファイルの実行を指定する、異なる複数の電子装置において再使用可能なコードであって、前記実行ファイルを当該コードにおいて特定しないコードを含むデータ構造であって、
前記コードを受信した電子装置において、
前記第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記第１のデータに基づき、前記特定された実行ファイルを使用して操作するステップと、が実行されるデータ構造。
請求項１７に記載のデータ構造であって、前記コードが前記第１のデータの電子装置への転送をさらに指定するデータ構造。
ＳｙｎｃＭＬＤＭプロトコルにおける複数のリーフノードと複数のインテリアノードとを有し、第１のリーフノードに格納される第１のデータを含む階層ノード型データ構造を電子装置に作成するための複数のコマンドと、
前記第１のリーフノードを特定し、前記第１のリーフノードに格納された前記第１のデータに基づく実行ファイルの実行を指定する、異なる複数の電子装置において再使用可能な更なるコマンドであって、前記実行ファイルを当該コマンドにおいて特定しないコマンドと、を含むデータ構造であって、
前記第１のデータに基づく実行ファイルの実行を指定するコマンドを受信した電子装置において、
前記第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記第１のデータに基づき、前記特定された実行ファイルを使用して操作するステップと、が実行されるデータ構造。
請求項１７、１８または１９に記載のデータ構造を使用するステップを含む方法。
請求項１７、１８または１９に記載のデータ構造を使用する電子デバイスをセットアップするステップを含む方法。
請求項１７、１８または１９に記載されたデータ構造を再使用し、異なる複数の電子装置をセットアップするステップを含む方法。
請求項１７、１８、または１９に記載のデータ構造を格納および送信するためのサーバ。
ＳｙｎｃＭＬＤＭプロトコルにおける第１のリーフノードに第１のデータを格納する手段と、
前記第１のデータに基づく実行ファイルの実行を指定する、異なる複数の電子装置において再使用可能なコマンドであって、前記実行ファイルを当該コマンドにおいて特定しないコマンドをサーバから受信する手段と、
前記特定された第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定する手段と、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定する手段と、
前記特定された第１のデータに基づき、前記特定された実行ファイルを使用して操作する手段と、を含む電子装置。
ＳｙｎｃＭＬＤＭプロトコルにおける第１のリーフノードに格納されている第１のデータを特定し、前記第１のデータに基づく実行ファイルの実行を指定するコードであって、前記実行ファイルを当該コードにおいて特定しないコードを送信するステップを含む方法であって、
前記第１のデータに基づく実行ファイルの実行を指定するコマンドを受信した電子装置において、
前記第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記第１のデータに基づき、前記特定された実行ファイルを使用して操作するステップと、が実行される方法。
ＳｙｎｃＭＬＤＭプロトコルにおける複数のリーフノードと複数のインテリアノードとを有し、第１のリーフノードに格納される第１のデータを含む階層ノード型データ構造を作成するためのコマンドを送信するステップと、
前記第１のリーフノードに格納される前記第１のデータに基づく実行ファイルの実行を指定する、異なる複数の電子装置において再使用可能な更なるコマンドであって、前記実行ファイルを当該コマンドにおいて特定しないコマンドをサーバから電子装置に送信するステップと、を含む方法であって、
前記第１のデータに基づく実行ファイルの実行を指定するコマンドを受信した電子装置において、
前記第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記第１のデータに基づき、前記特定された実行ファイルを使用して操作するステップと、が実行される方法。
ＳｙｎｃＭＬＤＭプロトコルにおける第１のリーフノードに格納されている第１のデータを特定し、前記第１のデータに基づく実行ファイルの実行を指定する、異なる複数の電子装置において再使用可能なコードあって、前記実行ファイルを当該コードにおいて特定しないコードを格納するメモリを含むサーバであって、
前記第１のデータに基づく実行ファイルの実行を指定するコマンドを受信した電子装置において、
前記第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記第１のデータに基づき、前記特定された実行ファイルを使用して操作するステップと、が実行されるサーバ。
請求項２７に記載のサーバであって、
前記コードが電子装置をセットアップするためのコードであるサーバ。
請求項２７または２８に記載のサーバであって、
前記コードが、異なる複数の電子装置のセットアップにおいて再使用されるサーバ。
ＳｙｎｃＭＬＤＭプロトコルにおける複数のリーフノードと複数のインテリアノードとを有し、第１のリーフノードに格納された前記第１のデータを含む階層ノード型データ構造を電子装置に作成し、前記第１のリーフノードに格納される前記第１のデータに基づく実行ファイルの実行を指定する前記第１のリーフを特定する、異なる複数の電子装置において再使用可能な第１のコマンドあって、前記実行ファイルを当該第１のコマンドにおいて特定しない第１のコマンドを格納するためのコマンドを格納するメモリを含むサーバであって、
前記第１のデータに基づく実行ファイルの実行を指定するコマンドを受信した電子装置において、
前記第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記第１のデータに基づき、前記特定された実行ファイルを使用して操作するステップと、が実行されるサーバ。
コンピュータを、
ＳｙｎｃＭＬＤＭプロトコルにおける第１のリーフノードに格納されている第１のデータに基づく実行ファイルの実行を指定する、異なる複数のコンピュータにおいて再使用可能なコマンドあって、前記実行ファイルを当該コマンドにおいて特定しないコマンドをサーバから受信する手段、
前記第１のデータの内容種別を当該第１のデータが格納されている第１のリーフノードのメタデータから決定する手段、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定する手段と、
前記第１のデータに基づいて、特定された実行ファイルを使用して操作可能とする手段、として機能させるプログラム。
電子装置において第１のコマンドを受信するステップであって、前記第１のコマンドはＳｙｎｃＭＬＤＭプロトコルにおける階層データ構造におけるリーフノードの作成を指定し、当該リーフノードに格納されるべき第１のデータを特定し、当該第１のデータが格納されている前記リーフノードのメタデータは前記第１のデータの内容種別を示す、第１のコマンド受信ステップと、
前記電子装置において前記リーフノードを作成するステップと、
前記電子装置において第２のコマンドをサーバから受信するステップであって、当該第２のコマンドは前記作成されたリーフノードにおいて格納される第１のデータに基づく実行ファイルの実行を指定する、異なる複数のコンピュータにおいて再使用可能な第２のコマンドあって、前記実行ファイルを当該第２のコマンドにおいて特定しない第２のコマンドである第２のコマンド受信ステップと、
前記第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定するステップと、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定するステップと、
前記特定された実行ファイルを用いて前記第１のデータに基づき操作するステップと、
を備える方法。
電子装置において第１のコマンドを受信する受信器であって、前記第１のコマンドはＳｙｎｃＭＬＤＭプロトコルにおける階層データ構造におけるリーフノードの作成を指定し、前記リーフノードにおいて格納されるべき第１のデータを特定し、当該第１のデータが格納されている前記リーフノードのメタデータは前記第１のデータの内容種別を示す、受信器と、
前記電子装置において前記リーフノードを作成するプロセッサと、
を備える電子装置であって、
前記受信器は更に、前記作成されたリーフノードにおいて格納された第１のデータに基づく実行ファイルの実行を指定する、異なる複数のコンピュータにおいて再使用可能な第２のコマンドあって、前記実行ファイルを当該コマンドにおいて特定しない第２のコマンドをサーバから受信し、前記プロセッサは更に、前記第１のデータが格納されているリーフノードのメタデータから前記第１のデータの内容種別を決定し、内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定し、そして、前記特定された実行ファイルを用いて第１のデータに基づき操作する、電子装置。
少なくとも一つのプロセッサと、一つ以上のコンピュータプログラムを含む少なくとも一つのメモリとを備える装置であって、
前記少なくとも一つのコンピュータプログラムがプロセッサによって実行されることにより、前記装置が、
ＳｙｎｃＭＬＤＭプロトコルにおける第１のリーフノードに格納されている第１のデータに基づく実行ファイルの実行を指定するコマンドであって、前記実行ファイルを当該コマンドにおいて特定しないコマンドを受信し、
前記第１のデータの内容種別を第１のデータが格納されている第１のリーフノードのメタデータから決定し、
内容種別と実行ファイルとを対応付けるルックアップテーブルに基づいて、前記メタデータから決定された内容種別に対応付けられた実行ファイルを特定し、
前記第１のデータに基づき、前記特定された実行ファイルを使用して操作する、装置。