JP5496113B2

JP5496113B2 - Ｏｍａｄｍプロトコルを用いて目標を絞り込むクエリー

Info

Publication number: JP5496113B2
Application number: JP2010546760A
Authority: JP
Inventors: ダン，ハン・エム
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2008-02-12
Filing date: 2008-12-29
Publication date: 2014-05-21
Anticipated expiration: 2028-12-29
Also published as: IL206686A0; CA2711509A1; EP2243250A4; ES2638873T3; EP2243250A2; JP2011515893A; BRPI0822103A2; RU2494554C2; EP2243250B1; WO2009102390A2; WO2009102390A3; MX2010008592A; CN101946462A; RU2010133660A; KR20100125243A; AU2008350306B2; AU2008350306A1; US20090204578A1

Description

[0001] 今日の技術界では、人々は種々の移動体デバイスをいつでも用いることができる。移動体デバイスの例には、パーソナル・ディジタル・アシスタント（ＰＤＡ）、ワイヤレス・フォン、ＰＤＡフォン、ラップトップ、車両用デバイス、および埋め込みデバイスが含まれ、その他にも多くの例をあげることができる。一部の移動体デバイスは、電話をかけるため、個人情報にアクセスするため、テキスト・メッセージおよび電子メールを送るため、そしてときとして会社のネットワーク・アプリケーションに遠方から接続するためにも用いられる。組織が移動体デバイスを管理するために、デバイス管理に関する技術が開発され、カスタム化、サービス提供、および個人化の選択肢が設けられた。デバイス管理技法は、移動体デバイスをプロビジョニングするため、または必要な動作パラメーターを移動体デバイスに提供するために用いることができる。移動体デバイスによって提供される機能が増大するにつれて、移動体デバイス上において管理する必要があるパラメーターおよび設定値の数も増大する。

[0002] デバイス管理技術の中には、業界標準として採用されているものもある。例えば、オープン・モバイル・アライアンス（ＯＭＡ）はデバイス管理（ＤＭ）規格をサポートする。ＤＭ規格は、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）プロビジョニング・フレームワークを、それ自体のデバイス管理構造と並行して利用して、デバイスにアプリケーション・アクセス情報およびある種のデバイス情報を提供する。例えば、ＯＭＡＤＭ規格は、デバイスの能力を、「．」と名付けたノードに起源を持つ名称付きノードのツリーとして表すことを指定する。ＯＭＡＤＭ管理セッションでは、サーバーおよび移動体デバイスは、ＯＭＡＤＭプロトコルと呼ばれる標準的プロトコルによって通信する。このようなセッションの間、ＯＭＡＤＭサーバーが移動体デバイスに送るコマンドは、ノードに問い合わせをしたりあるいはノードの構造または値を変更するeXtensible Markup Language（ＸＭＬ）フォーマットになっていることがある。

[0003] ＯＭＡＤＭプロトコルによって、サーバーは、移動体デバイス上の目標ノードにデーターについて問い合わせることができる。しかしながら、目標ノードがそれ自体のサブツリーのルートである場合、戻されるデーターは、サブツリー全体のデーターだけでなく、目標ノードのデーターも全て含む可能性がある。情報の一部のみを望む場合、その所望のデーターにたどり着くのが非効率的になる可能性がある。例えば、所望のデーターにたどり着くために採用することができる１つの手法では、サーバーがクエリーをデバイスに送り、応答を得て、この応答を解析する等の繰り返しを多数回行う。これは、必要でない余分なデーターの処理のため、そしてデーターを読み出すための余分な往復のために広がる帯域幅および長引く時間のために、遅くしかも非効率的となる可能性がある。採用することができる別の手法では、サーバーが、所望のノードがあるサブツリー全体を照会する。これもまた、必要でないデーター処理が行われ、余分なシステム資源を浪費することになる可能性がある。何故なら、サーバーがこのサブツリーにおいて少量のデーターだけを必要とする場合でも、サブツリー全体が戻されるからである。

[0004] オープン・モバイル・アライアンス（ＯＭＡ）デバイス管理（ＤＭ）プロトコルの機能を拡張するための種々の技術および技法を開示する。ＯＭＡＤＭプロトコルに追加を行い、サーバーが戻すべき目標ノードについてのデバイス管理データーの部分集合を示すために、移動体デバイス上における目標ノードに対するクエリーの一部として、ノード選別規準を指定することを可能にする。サーバーは、クエリーを移動体デバイスに送る。移動体デバイス上において要求を処理することに成功した場合、ノード選別規準を満たすデバイス管理データーの部分集合のみを含む応答が、移動体デバイスから受信される。

[0005] 別の実施態様では、ＯＭＳＤＭプロトコルに対して変更を行い、サーバーが、移動体デバイス上でどの属性を選択すべきか、Getコマンドの目標ＵＲＩの１つのパラメーターにおいて指定し、更にどのフォーマットでデバイス管理データーを戻すべきか、Getコマンドの目標ＵＲＩの別のパラメーターにおいて指定することを可能にする。

[0006] この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の鍵となる特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断する際に補助として用いられることを意図するのでもない。

図１は、一実施態様のＯＭＡＤＭ構造の模式図である。図２は、ＳＱＬシンタックスを用いて、Getコマンドの多数の位置においてノード選別規準を指定するためのソース・コードの一例(some exemplary)の模式図である。図３は、ＳＱＬクエリー・シンタックスを用いて、ＯＭＡＤＭクエリーのノード・フィルタ・パラメーターにおいてノード選別規準を指定するためのソース・コードの一例の模式図である。図４は、Xpathクエリー・シンタックスを用いて、ノード・フィルタ・パラメーターにおいて、そしてＯＭＡＤＭクエリーの別のデーター・パラメーターにおいて、ノード選別規準を指定するためのソース・コードの一例の模式図である。図５は、ＯＭＡＤＭプロトコルを用いて、ノード選別規準を有する要求を移動体デバイスに送る際に必要となる段階を示す、一実施態様のプロセス流れ図である。図６は、どの属性を選択すべきかを示す１つのパラメーターと、どのフォーマットでデバイス管理データーを戻すべきかを示す別のパラメーターを指定するためのソース・コードの一例の模式図である。図７は、一実施態様のコンピューター・システムの模式図である。

[0014] 本明細書では、前述の技術および技法について、オープン・モバイル・アライアンス（ＯＭＡ）デバイス管理（ＤＭ）プロトコルに対する拡張および／また変更として一般的なコンテキストで説明するが、本技術および技法は、これらに加えて、別の目的にも供するものである。

[0015] 前述のように、ＯＭＡＤＭ規格は、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）プロビジョニング・フレームワークを、それ自体のデバイス管理構造と並行して利用して、デバイスにアプリケーション・アクセス情報およびある種のデバイス情報を提供する。これらのデバイス管理構造は、図１のＯＭＡＤＭ構造１００において、ＯＭＡＤＭ管理オブジェクト１０２として示されている。ＯＭＡＤＭ規格は、デバイスの能力を、「．」と名付けたノードに起源を持つ名称付きノードのツリーとして表すことを指定する。この構造の一例について、端的に紹介する。ＯＭＡＤＭ管理セッションでは、サーバーおよび移動体デバイスは、ＯＭＡＤＭプロトコルと呼ばれる標準的プロトコルによって通信する。このようなセッションの間、ＯＭＡＤＭサーバーが移動体デバイスに送るコマンドは、ノードに問い合わせをしたりあるいはノードの構造または値を変更するeXtensible Markup Language（ＸＭＬ）フォーマットになっている場合がある。ＯＭＡＤＭプロトコルによって、サーバーは、移動体デバイス上の目標ノードにデーターについて問い合わせることができる。「目標ノード」という用語は、本明細書において用いる場合、特定のＯＭＡＤＭサーバー・コマンド（Getコマンドのような）のオブジェクトである、デバイスのＯＭＡＤＭ管理ツリーにおけるノードを指すことを意図している。目標ノードは、０個以上のチャイルド・ノードを含むことができる。

[0016] 図１に示すように、一実施態様では、ＯＭＡＤＭプロトコル１０４に拡張を行い、１つ又は複数のノード選別規準１０８を目標ノード・クエリー仕様(specification)１０６に追加する。ノード選別規準１０８は移動体デバイスから戻されるべきデバイス管理データーの部分集合を、サーバーに指定させる。「ノード選別規準」という用語は、本明細書において用いる場合、１つ又は複数のパラメーター、規準、またはデバイス管理データーをどのように選別(filter)すべきか指定するその他の値を含むことを意味する。図２から図５において更に詳しく説明するが、一実施態様では、ノード選別規準の少なくとも一部が、Getコマンドに含まれる目標ＵＲＩに追加される新たなパラメーターに含まれる。他の実施態様についても、更に詳細に説明する。

[0017] ノード選別規準１０８の代わりにまたはこれに加えて、その他の規準１１０も変更することおよび／またはＯＭＡＤＭプロトコル１０４に含ませることができる。非限定的な一例として、どの属性を移動体デバイス上で選択すべきかを示すために１つのパラメーターを用い、どのフォーマットでデバイス管理データーを戻すべきかを示すために別のパラメーターを用いるように、ＯＭＡＤＭプロトコルを変更することができる。この非限定的な例について、図６において更に詳細に説明する。これより、ノード選別規準およびその他の概念を更に例示するために、図２から図６においていくつかの例を示す。

[0018] これより図２から図６に移り、ＯＭＡＤＭプロトコル１０４の１つ又は複数の実施態様を実現するためのソース・コードおよびプロセス例をいくつか、詳細に説明する。実施態様によっては、図２から図６における論述において説明するプロセスは、（図７の）コンピューティング・デバイス３００の動作ロジックにおいて少なくとも部分的に実現される場合もある。

[0019] 図２は、ＳＱＬシンタックスを用いて、Getコマンドの多数の位置においてノード選別規準を指定するためのソース・コードの一例の模式図である。図２に示すソース・コード例のシンタックスの詳細を論ずる前に、最初にノード選別の概念を更に例示するために、一例について説明する。

[0020] あるデバイス管理動作を行うために、サーバーにはデバイス管理データーの一部しか必要でないと仮定する。以下に、移動体デバイス上に存在する可能性があるデーターのツリーの仮説的例を示す。

[0021] サーバーは、全てのノード{.x/y/b, .x/y/c}の値だけを読み出したいと仮定する。ここで、対応する./x/y/d/e.値==５１とする。図２に示すようなクエリーをサーバーから移動体デバイスに発行することができる。これについては、この後更に詳細に説明する。移動体デバイス上において結果を処理した後、サーバーは次に以下と同様の結果を受信する。

[0022] 尚、上の結果のリストは、サーバーが実際に受け取るものの簡略化した表であり、例示のために簡略化した形態で紹介したことを注記しておく。実際の結果は、サーバーまたはクライアントによって指定されたフォーマットのように、ＸＭＬまたはその他のフォーマットで戻すことができる。以下は、ＸＭＬフォーマットでは結果がどのように見えるかの一例である。

[0023] 以上の例の双方では、戻されるノードは、指定されたノード選別規準を満たした、所望のフィールドだけを含む。この仮説的例では、選別規準は、値が５１に等しい「ｅ」ノードを有するノードについて、データーのある部分のみが戻されるという要件を含んでいる。その結果は、この指定された規準を満たしたノードのデーターから選択されたフィールドのみを含む。

[0024] ここで図２のソース・コード例に戻り、ＯＭＡＤＭプロトコルを用いてノード選別規準を実施する１つの方法は、ノード・フィルタ規準をGetコマンドに追加することである。Getコマンドは、ＯＭＡＤＭプロトコルにおいてサポートされており、サーバーがデバイス管理データーを移動体デバイスから取得することを可能にする。図２に示したソース・コード例では、GetコマンドのローカルＵＲＩパラメーター１３２が変更されて、ノード選別規準を表現するために用いられているクエリー言語１３６を指定するノード・フィルタ・パラメーター１３４を含むようになっている。この例では、実際のノード選別規準は、実際には、ノード・フィルタ・パラメーター１３４において指定されたクエリー言語シンタックスを用いて、データー・セクション１３８の中というように、Getコマンドのいずれかの位置において表現されている。この例では、ノード・フィルタ・パラメーター１３４は、用いられるクエリー言語シンタックス１３６がＳＱＬであることを指定する。そして、ＳＱＬクエリー１４０がデーター・セクション１３８に含まれる。ＳＱＬクエリーは、５１に等しい値を有するノードについて、レコードを「ｂ」および「ｃ」レコードに制限した先の例において用いられていた同じ規準を含む。

[0025] 図２に示した例は、ＯＭＡＤＭプロトコルを変更してノード選別規準を含むことができる多くの可能な方法の一例に過ぎない。例えば、他の実施態様では、具体的なノード選別規準は、直接LocURIパラメーター１３２に含ませること、Getコマンドの他の何らかのセクションに含ませること、またはGetコマンドにアクセス可能ないずれかの外部位置に含ませることができる。

[0026] 図３は、図２の変形であり、同じＳＱＬノード選別規準１５６をどのようにすれば、代わりにLocURIパラメーター内に直接、ノード・フィルタ・パラメーター１５４の一部として、含ませることができるかを示す。言い換えると、デバイス管理データーの部分集合を選択するために用いるべき規準を示す実際のクエリー・ステートメントは、他の可能な変形のように、直接LocURIパラメーター１５２の中に埋め込むことができる。

[0027] 図４は、Xpathクエリー・シンタックスを用いて、ノード・フィルタ・パラメーターにおいて、そしてＯＭＡＤＭクエリーの別のデーター・パラメーターにおいて、ノード選別規準を指定するためのソース・コードの一例の模式図である。図４のソース・コード例は、図２の変形を示し、ＳＱＬシンタックスの代わりに、Xpathクエリー・シンタックスが仮説的クエリーに用いられている。この例では、GetコマンドのLocURIパラメーター１７２は、クエリー言語シンタックス１７６のXpathの値を示すノード・フィルタ・パラメーター１７４を含む。そして、Getコマンドのデーター・セクション１７８は、Xpathクエリー言語シンタックスで実際のノード選別規準を有するクエリーを含む。Xpathシンタックスで指定された規準は、先に導入したのと同じ選別規準であるが、例示のためにXpathシンタックスを代わりに用いている。このクエリーは図２および図４の例ではデーター・セクションにおいて示されており、図３におけるLocURIパラメーターの中に直接示されているが、ノード選別規準を表現するクエリーは、コンピューター・ソフトウェア技術における当業者に想起される多数の様式のいずれの１つでも指定できることは認められよう。ＯＭＡＤＭプロトコルのGetコマンド内にノード選別規準を直接表す、またはGetコマンドにアクセス可能なノード選別規準を表すのに適したいずれの変形でも、他の実施態様では用いることができる。

[0028] これより図５に移ると、ノード選別規準を有する要求を移動体デバイスに、ＯＭＡＤＭプロトコルを用いて送る際に必要となる段階を示す、一実施形態のプロセス流れ図２００が示されている。任意に、移動体デバイスから、デバイス管理セッションを開始することをサーバーに促す要求が受け取られる（段階２０２）。非限定的な一例として、移動体デバイスはサーバーとの接続を（ＨＴＴＰまたは他のプロトコルによって）確立して、更新を要求することができる。いずれの場合でも、サーバーは、何らかの方法で、デバイス管理データーを読み出すおよび／または更新するために移動体デバイスと通信すべきときであると判断する。サーバーは、デバイス管理データーを読み出すために、ノード選別規準を有するGetコマンドを含む要求を移動体デバイスに送る（段階２０４）。

[0029] 移動体デバイス上で要求の処理に成功した場合（判断点２０６）、サーバーは移動体デバイスから応答を受け取る。この応答は、ノード選別規準を満たさない他のノードに対立するものとして、ノード選別規準を満たすデバイス管理データーの部分集合のみを含む（段階２０８）。実施態様によっては、サーバーは、具体的に要求しノード選別規準を満たすデーターと共に、ステータス・インディケータまたはその他の付帯情報を受け取ることができる。このような想定場面では、サーバーは、ノード選別規準において排除するように具体的に要請された、ツリー内にあるデーターのノードを受け取らない。移動体デバイス上において要求の処理に成功しなかった場合（判断点２０６）、該当するのであれば、サーバーは移動体デバイスからエラーを受け取る（段階２１０）。例えば、サーバーと移動体デバイスとの間における通信エラーによってエラーが発生した場合、通信接続が失われたため、エラー・コードを受け取ることができない場合もある。

[0030] これより図６に移り、どのようにしてGetコマンドのLocURIパラメーターにおけるデーター・フォーマット・セクションおよびノード設定セクションから別のパラメーターに、属性セクションを含ませることができるのかを示すために、ＯＭＡＤＭプロトコルに対する別の変更について説明する。ソース・コード例２４０は、リスト・パラメーター２４４を含むLocURIパラメーター２４２を有する。リスト・パラメーターは、デバイス管理データーを戻す際に用いるべきフォーマットを記載する。一実施態様では、リスト値が「StrucData」である場合、結果において、ノード毎の静止データー集合と共に、全てのノードが個々の項目において戻される。リスト・パラメーター２４４の値が「TDNS」である場合、ＸＭＬブロブを戻す。これは、全てのノードについて、ノード毎のデーター集合を記述する。この属性選択はカスタム化が可能であるが、カスタム化はTNDSリスト値自体に埋め込まれる。しかしながら、propsパラメーター２４６は属性セクションを、ノード設定セクションおよびデーター・フォーマット・セクションのような、クエリー・シンタックスの他の部分から解放するので、propsパラメーター２４６は、ノード集合選択またはデーター・フォーマット選択を指定する他のいずれの機能とでも一緒に指定することができる。このpropsパラメーター２４６自体は、どの属性を移動体デバイスの目標ノード集合から選択すべきかを示す。propsパラメーター２４６において指定される属性は、ノード値だけでなくノード・プロパティも含むことができ、多数の属性を一度に指定することができる。尚、これらのパラメーターは、図６において記述する名称とは異なることもあり得るが、これらは単なる一例であることを注記しておく。

[0031] 図７に示すように、本システムの１つ又は複数の部分を実現するために用いられるコンピューター・システム例は、コンピューティング・デバイス３００のようなコンピューティング・デバイスを含む。その最も基本的な構成では、コンピューティング・デバイス３００は、通例、少なくとも１つの演算装置３０２とメモリ３０４とを含む。コンピューティング・デバイスの正確な構成およびタイプに応じて、メモリ３０４は揮発性（ＲＡＭのような）、不揮発性（ＲＯＭ、フラッシュ・メモリ等のような）、またはこれら２つの何らかの組み合わせとすることができる。この最も基本的な構成は、図７によって破線３０６で示されている。

[0032] 加えて、デバイス３００は追加の機構／機能も有することができる。例えば、デバイス３００は、磁気あるいは光ディスクまたはテープを含むがこれらに限定されない追加のストレージ（リムーバブルおよび／または非リムーバブル）を含むこともできる。このような追加のストレージは、図７では、リムーバブル・ストレージ３０８および非リムーバブル・ストレージ３１０によって例示されている。コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、またはその他のデーターというような情報の格納のために任意の方法または技術で実現されている。メモリ３０４、リムーバブル・ストレージ３０８、および非リムーバブル・ストレージ３１０は、全てコンピューター記憶媒体の例である。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）またはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができ、しかもデバイス３００によってアクセスすることができる他の任意の媒体を含むが、これらに限定されるのではない。このようなコンピューター記憶媒体の内任意のものをデバイス３００の一部とすることもできる。

[0033] コンピューティング・デバイス３００は、当該コンピューティング・デバイス３００が他のコンピューター／アプリケーション３１５と通信することを可能にする１つ又は複数の通信接続３１４を含む。また、デバイス３００は、キーボード、マウス、ペン、音声入力デバイス、接触入力デバイスなどのような、入力デバイス（１つまたは複数）３１２も有することができる。ディスプレイ、スピーカー、プリンターなどのような出力デバイス（１つまたは複数）３１１も含むことができる。これらのデバイスは、当技術分野では周知であり、ここでは長々と論ずる必要はない。一実施態様では、コンピューティング・デバイス３００は移動体デバイス通信システム１０のコンポーネントの一部または全部を含む。

[0034] 以上、構造的特徴および／または方法論的行為に特定的な文言で主題について説明したが、添付した特許請求の範囲において定められる主題は、必ずしも前述の特定的な特徴や行為には限定されないことは言うまでもない。むしろ、前述の特定的な特徴や行為は、特許請求の範囲を実現する形態例として開示したのである。本明細書に記載した、および／または以下の特許請求の範囲による実施態様の主旨に該当する全ての同等物、変更、および修正が保護されることが望まれる。

[0035] 例えば、コンピューター・ソフトウェア技術における当業者であれば、本明細書において論じた例は、前述の例において図示したものよりも少ないまたは多い選択肢または機構を含むように、１つ又は複数のコンピューターにおいて別々に編成できることが認められよう。

Claims

サーバーが、オープン・モバイル・アライアンス（ＯＭＡ）デバイス管理（ＤＭ）プロトコルを用いて、移動体デバイスの目標ノードにＧｅｔコマンドを提出し、前記目標ノードと関連するデバイス管理データーを読み出すための方法であって、前記方法は、
前記サーバーが、前記Ｇｅｔコマンドの目標ＵＲＩの１つのパラメーターにおいて、前記移動体デバイス上でどの属性を選択すべきか指定し、前記Ｇｅｔコマンドの目標ＵＲＩの他のパラメーターにおいて、前記デバイス管理データーを戻す際にどのフォーマットにすべきかを指定するステップと、
前記サーバーが、前記移動体デバイスに前記Ｇｅｔコマンドを送るステップと、
前記移動体デバイス上において前記Ｇｅｔコマンドの処理に成功した場合、前記サーバーが、前記デバイス管理データーを、前記移動体デバイスから受け取るステップと、
を備えていることを特徴とする方法。
請求項１記載の方法であって、更に、
前記移動体デバイス上において前記Ｇｅｔコマンドの処理に成功しなかった場合、前記サーバーが、前記移動体デバイス上で発生したエラーを記述するエラー・メッセージを前記移動体デバイスから受け取るステップを備えていることを特徴とする方法。
請求項１記載の方法であって、更に、
前記サーバーが、前記Ｇｅｔコマンドを送るステップの前に、前記デバイス管理データーを前記移動体デバイスに送る要求を催促する通信要求を、前記移動体デバイスから受け取るステップを備えていることを特徴とする方法。
オープン・モバイル・アライアンス（ＯＭＡ）デバイス管理（ＤＭ）プロトコルを用いて、移動体デバイスの目標ノードにＧｅｔコマンドを提供し、前記目標ノードと関連するデバイス管理データーを読み出すためのシステムであって、
サーバーを備え、
前記サーバーが、前記Ｇｅｔコマンドの目標ＵＲＩの１つのパラメーターにおいて、前記移動体デバイス上でどの属性を選択すべきか指定し、前記Ｇｅｔコマンドの目標ＵＲＩの他のパラメーターにおいて、前記デバイス管理データーを戻す際にどのフォーマットにすべきかを指定し、前記移動体デバイスに前記Ｇｅｔコマンドを送り、前記移動体デバイス上において前記Ｇｅｔコマンドの処理に成功した場合、前記デバイス管理データーを、前記移動体デバイスから受け取るように構成される、
ことを特徴とするシステム。
請求項４記載のシステムであって、更に、
前記移動体デバイス上において前記Ｇｅｔコマンドの処理に成功しなかった場合、前記サーバーが、前記移動体デバイス上で発生したエラーを記述するエラー・メッセージを前記移動体デバイスから受け取るよう構成されることを特徴とするシステム。
請求項４記載のシステムであって、更に、
前記サーバーが、前記Ｇｅｔコマンドを送るステップの前に、前記デバイス管理データーを前記移動体デバイスに送る要求を催促する通信要求を、前記移動体デバイスから受け取るよう構成されることを特徴とするシステム。
コンピュータに請求項１〜３の何れか１項記載の全ステップを実行させるためのプログラムを記録したコンピュータ読み取り可能記憶媒体。
コンピュータに請求項１〜３の何れか１項記載の全ステップを実行させるためのプログラム。