JP2014182461A - 通信装置、通信方法、通信システム、およびプログラム - Google Patents

Abstract

【課題】組込機器ノードに搭載するインターフェイス定義を機種別に最適化する。
【解決手段】実施形態によれば、第１の格納部、判定部、第１の処理部を含む通信装置が提供される。第１の格納部は、複数の機種判別符号と、該機種判別符号に対応する複数の構造化文書符号文法とを関連付けて記憶する。判定部は、通信対象の機種を判定する。第１の処理部は、前記判定部により判定された機種の機種判別符号に対応する構造化文書符号文法を前記第１の格納部から選択し、該構造化文書符号文法を用いて構造化文書を符号化し、または受信した構造化文書符号を、前記構造化文書符号文法を用いて復号する。
【選択図】図１

Description

本発明の実施形態は通信装置、通信方法、通信システム、およびプログラムに関する。

メータ等の機器ノードによるＸＭＬ(Extensible Markup Language)互換のデータ処理は、ＥＸＩ(Efficient XML Interchange)を利用して効率的に行うことができる。ＥＸＩはＸＭＬのバイナリ表現である。ＥＸＩは、機器ノード間においてアプリケーションが通信を行う際のインターフェイスを構成する。

米国特許第７，８５３，７２４号明細書

組込機器ノードには種々の制約があり、その機能は限定的である。このような組込機器ノードに搭載するインターフェイス定義を機種別に最適化することが必要とされている。

実施形態によれば、第１の格納部、判定部、第１の処理部を含む通信装置が提供される。第１の格納部は、複数の機種判別符号と、該機種判別符号に対応する複数の構造化文書符号文法とを関連付けて記憶する。判定部は、通信対象の機種を判定する。第１の処理部は、前記判定部により判定された機種の機種判別符号に対応する構造化文書符号文法を前記第１の格納部から選択し、該構造化文書符号文法を用いて構造化文書を符号化し、または受信した構造化文書符号を、前記構造化文書符号文法を用いて復号する。

実施形態に係る通信システムを示す図 構造規定簡約の概念図 実施形態に係るサーバ側通信装置を示すブロック図 簡約構造規定の簡単な例を示す図 簡約構造規定のインスタンス例を示す図 簡約処理の具体例（Ｏｐｔｉｏｎａｌ要素および属性の省略）を示す図 簡約処理の別の具体例（間接参照の直接参照化）を示す図 簡約処理の別の具体例（型統合）を示す図 実施形態に係る構造規定簡約エンジンの処理手順を示すフローチャート 別の実施形態に係る通信システムを示す図 OASIS EIにおける機能の相互参照関係を示す図 実施例に係る簡約処理結果を示す図 実施例に係る簡約処理結果を示す図 実施例に係る簡約処理結果を示す図 別の実施例に係る基準構造規定を示す図 別の実施例に係る基準構造規定のインスタンス例を示す図 別の実施例に係る簡約処理結果を示す図 別の実施例に係る簡約処理結果のインスタンス例を示す図

以下で説明する実施形態は、構造化文書がＸＭＬ(Extensible Markup Language)、構造規定がＸＭＬスキーマ、構造化文書符号がＥＸＩ(Efficient XML Interchange)であることを想定している。しかしながら、実施形態はＸＭＬ、ＸＭＬスキーマ、ＥＸＩを利用する装置、方法、システム、およびプログラムへの適用のみに限定されない。

図１は、実施形態に係る通信システムを示す図である。このシステムにおいて、サーバ側通信装置１と、クライアント側通信装置（以下「組込機器」という）２とがネットワーク３を介して接続されている。図１では組込機器２が１つだけ示されているが、機種が異なる複数の組込機器２がサーバ側通信装置１に接続される。サーバ側通信装置１は、組込機器２の機種別に最適化されたインターフェイスを用いて当該組込機器２と通信する。

サーバ側通信装置１と組込機器２の間の通信は、構造化文書符号７を利用して行なわれる。例えば、組込機器２は、同装置において計測されたデータを含んだ構造化文書８から、構造化文書符号の文法に従って構造化文書符号７を生成する。この生成された構造化文書符号７は、組込機器２の通信部９からネットワーク３を介してサーバ側通信装置１の通信部５に送られる。サーバ側通信装置１は、受信した構造化文書符号７を復号化することにより構造化文書６を取得する。構造化文書６は、これを処理するアプリケーションに渡される。

構造規定簡約エンジン４は、組込機器２の機種別に最適化されたインターフェイス定義を複数保持しており、通信を行う組込機器２の機種に応じて適切なインターフェイス定義を選択して用いる。サーバ側通信装置１と組込機器２の間の通信のインターフェイスは、構造化文書符号の文法（インターフェイス定義）に従う。構造化文書符号の文法は、構造化文書の構造規定に基づく。構造規定簡約エンジン４は、例えば組込機器２が初めて接続される前の設計段階において、このような構造規定を簡約することにより組込機器２の機種別の構造規定を生成する。簡約された構造規定に基づいて、当該組込機器２の構造化文書符号の文法が生成される。構造規定は、通信を行う際のデータ表現を規定するものであるが、規準の構造規定は、個々の組込機器から見て無駄な部分が多い。簡約された構造規定は、そのような無駄な部分を規準の構造規定から除いたものである。

図２は、機種別に構造規定を簡約する概念を示した図である。同図において、上の部分は対比のために簡約を行わない場合を示しており、下の部分は簡約を行う場合を示している。

構造規定の簡約を行わない場合、構造化文書（実データ）に構造規定（形式定義）を適用して構造化文書符号（構造化文書と等化なデータ）が得られる。構造規定の簡約を行う場合、構造化文書（実データ）に、簡約された構造規定を適用して、簡約された構造化文書符号が得られる。簡約された構造規定は、機種別に必要となる部分のみが抽出されたものであり、構造化文書符号文法の節約に寄与する。

また、構造規定の簡約を行わない場合、構造化文書および構造化文書符号は全機種で同一のものが用いられることになる。構造規定の簡約を行う場合、構造化文書は全機種で同一のものが用いられるが、構造化文書符号は機種別のものが用いられることになる。これは、サーバ側は統合的である一方、クライアント側は最適化されていると見ることができる。

図３は、サーバ側通信装置を示すブロック図である。

構造化文書の処理部１０は、ユーザにより記述されるアプリケーションに相当する。アプリケーションにより定義された構造化文書を入力として、同処理部１０はデータの加工、蓄積、参照などの処理を行い、構造化文書を出力する。

規準構造規定１１は、アプリケーション側が利用する構造規定である。規準構造規定１１は、特定のアプリケーション、あるいはこれに付随する通信規約により定められる。

機種別データ設計の格納部１２は、本システムにおいて通信を行う複数の組込機器２に対応する複数のデータ設計を記憶する。データ設計とは、どのようなメッセージを入出力に利用するかを与えられた規準構造規定に基づいて記述したものである。データ設計は、個々の組込機器２が入出力して意味のある可能性がある構造化文書の根（Ｒｏｏｔ）要素のリストと、個々の要素においてアクセスする可能性がある要素および属性のリストとで構成される。

構造規定簡約エンジン４は、規準構造規定１１と、機種別データ設計の格納部１２からの機種別データ設計とに基づいて、簡約された機種別構造規定を生成する（構造規定簡約）。機種別構造規定を生成する具体的な方法については後に詳しく説明する。

構造化文書符号文法のコンパイラ１３は、構造規定簡約エンジン４により生成された機種別構造規定を構造化文書符号文法に変換する。この変換には、参考文献［１］：John Schneider and Takuki Kamiya, Efficient XML Interchange (EXI) Format, W3C Recommendation, 2011に記載の方法を利用してもよい。

通信先機種の判定部１４は、通信先から与えられた情報（例えばＩＰアドレス、ＨＴＴＰヘッダ等）に基づいて通信先の機種を判定し、機種判別符号を返す。

機種別構造化文書符号文法の格納部１５は、機種判別符号と、これに対応する構造化文書符号文法とを関連付けて記憶する。構造化文書符号文法は、送信用と受信用で異なっていてもよいし、同一でもよい。また、構造化文書符号文法に構造規定ＩＤを割り当ててもよい。構造化文書を符号化する際、および構造化文書符号から構造化文書を復号する際に、構造規定ＩＤによって適切な構造化文書符号文法を参照することができる。

構造化文書符号の処理部１６は、通信部５から入力された構造化文書符号を、通信先の機種に対応する構造化文書符号文法に従って復号し、復号された構造化文書を構造化文書の処理部１０に渡す。また、構造化文書の処理部１０から入力された構造化文書を、通信先の機種に対応する構造化文書符号文法に従って符号化し、通信部５に出力する。

通信部５は、組込機器２との通信を行う。図１に示したネットワーク３から通信部５に入力された構造化文書符号（のメッセージ）７は、構造化文書符号の処理部１６により復号される。構造化文書の処理部１０から構造化文書符号の処理部１６を経由して出力された構造化文書符号（のメッセージ）７は、通信部５からネットワーク３を通じて該当する組込機器２に送信される。

（構造規定簡約）
構造化文書上での表現を維持したまま構造規定を簡約する一連の操作のことを本明細書では構造規定簡約と称する。これは、組込機器２の多くは機能が制約されており、規準構造規定で定義されている型空間のうち一部しかアクセスしないことに着目した操作である。

一般に、規準構造規定１１は、柔軟性を持たせて構築される。構造規定簡約エンジン４は、そのような基準構造規定１１を次の条件の下で機種別構造規定に簡約する。

１．機種別構造規定に基づく構造化文書符号文法に従って構造化文書符号から変換された構造化文書と、規準構造規定１１に基づく構造化文書符号文法に従って構造化文書符号から変換された構造化文書とが全く同じ表現であること。また、この構造化文書は規準構造規定１１によって正当性が検証可能である（ｖａｌｉｄである）こと。
２．当該機種の組込機器２がアクセスする必要がある全ての要素が当該機種の構造規定に含まれること。

機種別構造規定を生成するためには機種別データ設計が必要である。機種別データ設計の具体例を以下に示す。この具体例は、OASIS EnergyInterop（参考文献［２］：David Holmberg and William T. Cox, Energy interoperation version 1.0, OASIS Committee Specification 02, February 2012参照）の構造規定をもとに、Events要素に含まれるeiEvent要素と、その中でアクセスする可能性のある要素のリスト、すなわちeventID,modificationNumber,dtstart,duration,signalFloat,groupID,signalTypeで構成される。
eventID: イベントを識別するID
・/Events/eiEvent/eventDescriptor/eventID/text()
modificationNumber: イベントの改版数
・/Events/eiEvent/eventDescriptor/modificationNumber/text()
dtstart: イベントの開始時刻
・/Events/eiEvent/eiEventSignals/eiEventSignal/ic:dtstart/ic:date-time/text()
duration: イベントの継続時間
・/Events/eiEvent/eiEventSignals/eiEventSignal/ic:duration/text()
signalFloat: 目標電力消費量（ベースライン比）
・/Events/eiEvent/eiEventSignals/eiEventSignal/intervals/interval/signalPayload/payloadFloat/value/text()
groupID: 節電ターゲットとなる顧客グループのID
・/Events/eiEvent/eiEventSignals/eiEventSignal/eiTarget/groupID/text()
この機種別データ設計の具体例は、構造化文書のうちtargetで表わされる部分（XPath表記）についてアクセスすることを示したものである。また、本例におけるｋｅｙ毎の各項目の意味も示している。尚、本願と同一出願人による出願に係る特願２０１１−７０１９３号明細書は、このような機種別データ設計に基づく構造化文書符号の符号化器の例を開示している。

ここでは具体的に引用しないが、参考文献［２］において定義され参照される規準構造規定１１は７８ファイル、合計１８０００行の巨大な定義集合である。この中には物理単位の定義や貨幣単位のＩＳＯ定義、または地理的位置情報に関する定義なども存在する。一般に、組込機器のレベルではこのような定義にアクセスすることは少ないため、簡約を実施することで大幅な効率化を図ることができる。

（簡約構造規定：組込機器受信用簡約符号化）
簡約構造規定の簡単な例を図４に示す。図５は、そのインスタンスの例である。これは、データ受信側（組込機器側）でアクセスされない非適合要素を構造化文書符号の処理部１６がフィルタし、通信量削減と機器側実装の軽量化を図る実施例に関する例示である。ここでは、郵便番号までを取得し、地域別人数をカウントする計量器に対してデータを送出する場合を想定している。

この例は、受信側である組込機器２がアクセスする要素以外は一切含めない簡約処理を行なったものである。このとき、受信側である組込機器２に構造化文書処理部１０が送付する構造化文書は規準構造規定に基づくものの、組込機器２に送付される構造化文書符号は規準構造規定では妥当性を検証できない点に注意が必要である。この場合、構造化文書符号の処理部１６は、機種別構造規定では記述できない要素について無視することが必要である。

以下では図６乃至図８を参照し、簡約された構造規定を構造規定簡約エンジン４が生成する具体的な方法について説明する。

簡約処理には、例えば、１．Ｏｐｔｉｏｎａｌ要素および属性の省略（図６）、２．間接参照の直接参照化（図７）、３．型統合（図８）、４．ワイルドカードの固定、などがある。ある実施形態は、これらの全ての簡約処理を実施するものであり、別の実施形態は、これら簡約処理のいずれかを実施するものである。尚、有効な簡約処理の条件は先に示した通りであり、簡約処理はこれらに限るものではない。

１．Ｏｐｔｉｏｎａｌ要素および属性の省略：
minOccur=0となっている要素や、optionalとなっている属性は、構造化文書中に出現しても良いし、出現しなくても良い。もし、入力となる機種別データ設計から、当該属性ならびに当該要素およびその子要素にアクセスしないことが判明すれば、構造規定から当該属性ならびに当該要素を削除することが可能である。

例えば図６において、optionalな要素であるs2を削除することにより構造規定を簡約する。

２．間接参照の直接参照化：
SubstitutionGroupにより、ある要素の子要素についての多様性を持たせることができる。ところが、機種別データ設計によっては、この多様性を限定しても良い場合がある。例えば、図７に示すように、さまざまなＩＤの種別がanyIDという名のSubstitutionGroupにより代替可能となっていたとしても、当該機種が（例えば）HomeIDという型で定義されるＩＤにしかアクセスしないとすれば、anyIDとあるSubstitutionGroupの参照をHomeIDへの直接参照で置き換えることが可能である。同様に、Sub-Typeの多様性も直接定義に置換することができる。

３．型統合：
型定義に柔軟性を持たせるために、抽象型から具象型に至るまで何段階かの抽象化レベルを持たせる場合がある。ところが、特定の機種に至っては特定の具象型のみ利用できればよい。他で参照されない抽象型は、具象型の定義と統合して単純化可能である。図８は、利用される「specificType」という型を統合して「SuperBazSpecificType」に単純化した例を示している。

４．ワイルドカードの固定：
ＸＭＰＰ（Extensible Messaging and Presence Protocol, IETF RFC6120）のように、ワイルドカードと動的スキーマ拡張を多用するメッセージフォーマットにおいては、機種別データ設計に基づいて構造規定を統合することができる。

具体的には、メッセージフォーマットの規定としては枠組みのみを決めておいて、具体的な通信メッセージは他の名前空間定義により、動的に他の構造規定を参照する仕組みである。構造化文書においては、ワイルドカード定義(xs:anyType)において、「processContent="lax"」などと指定することで利用できる機能である。構造化文書符号において、ワイルドカード定義はBuilt-in Grammarと呼ばれる非効率な方法で符号化される。

この方法は、メモリや帯域をより多く消費することから組込機器２には不向きである。そこで、機種別データ設計から当該組込機器２がどの拡張要素にアクセスする可能性があるかが判明すれば、それら拡張要素を定義した構造規定の全てをｉｎｃｌｕｄｅした構造規定を定義し、これを簡約したものを機種別構造規定とすることで、全てのワイルドカード定義に対して効率的な符号化方式(Schema-Informed Grammar)を利用しつつ、機種毎に最適な通信を実現することができる。

構造規定簡約エンジン４の実際のアルゴリズムは、以上の簡約処理を順次実施し、簡約不可能になったところで停止するものである。簡便な方式として、図９に示すフローチャートによるものを示す。

まず、利用する構造化文書の根要素、および、利用する機能のリスト（XPathのリストで表現されたreq）を入力する。該リストは機種別データ設計に基づく。また、簡約化済型リストを初期化する（ステップＳ１）。次に、簡約化前型リストから型を１つ取り出す（ステップＳ２）。

ステップＳ２において取り出された型を簡約化可能であるかを判定し（ステップＳ３）、簡約化が可能であれば、これを簡約化する（ステップＳ４）。簡約化が可能な限りにおいてステップＳ４の処理を繰り返す（ステップＳ５）。簡約化された型は、簡約化済型リストに登録される（ステップＳ６）。

簡約化前型リストが空になるまで、ステップＳ２乃至Ｓ６の処理を繰り返す（ステップＳ７）。簡約化前リストからすべての型が取り出されて空になると、終了処理を行う（ステップＳ８）。簡約化済型リストには、必要な簡約型が全て含まれており、これを全て書き出す。次に、根要素の定義および型を書き出して終了する。

以上説明した実施形態によれば、通信に用いられるインターフェイス定義（構造化文書符号の文法）のうち、対象となる２つのノード（サーバ側通信装置１および組込機器２）が共通して利用するインターフェイス部分定義のみが残るようにインターフェイス定義を変形することができる。これは、構造規定の簡約化によるものである。

サーバ側通信装置１は、潤沢なリソースを持つノードでありながら、通信相手の各ノードに最適化されたインターフェイス定義による通信を行うことができる。このようなこのインターフェイスの定義の変形は、データの直列化のみに影響し、内部データ表現（例えばＸＭＬにおけるDocument Object Model）に影響しない。

具体的には、サーバ側通信装置１における処理プログラムのインターフェイス選択により、組込機器として構成されることが多いクライアント側通信装置２の機種に対応し、最小限のハードウェアリソースによる通信機能を実現することができる。この場合、クライアント側通信装置２については、個々の機器に最適な構造化文書符号の文法への最適化により、メモリ消費量、メッセージサイズ、処理時間を削減することができる。また、サーバ側通信装置１については、構造化文書アプリケーション側のAPIを変更することなく、構造化文書符号文法の最適化に対応することができる。

尚、上述した構造規定簡約エンジン４を含む実施形態に係る通信システムの各構成要素は、コンピュータのプログラムとして実現することができる。同プログラムは、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録されて提供され、あるいはＲＯＭ等に予め組み込んで提供されうる。

また、上述した実施形態は、構造規定簡約エンジン４がサーバ側通信装置１に実装される例（図１）として説明したが、図１０に示すように、構造規定簡約エンジン４がクライアント側通信装置２に実装されてもよい。この場合、クライアント側通信装置２からサーバ側通信装置１に対し、利用する構造規定をアップロードする。あるいは、クライアント側通信装置２からサーバ側通信装置１に対し、利用する構造規定のURL(schemaLocation)を通知し、サーバ側通信装置１はこれを利用して構造規定を取得する。あるいは、クライアント側通信装置２からサーバ側通信装置１に対し、利用する構造規定のＩｄを通知する。サーバ側通信装置１はこのIdを利用してリポジトリから該当する構造規定を獲得する。

（実施例）
以下、OASIS Energy Interop（以下「OASIS EI」という。参考文献［２］参照）におけるeiEvent要素を簡約した実施例を示す。OASIS EIは、エネルギー市場に必要とされるさまざまな機能を実現した仕組みである。図１１は、OASIS EIにおける機能の相互参照関係を示している。ここでは詳細は説明しないが、ei-payloadsを基盤として、ei-enrollやeiなどの仕様がemix（エネルギー交換仕様）、ISO42173A（通貨仕様）、ical（カレンダー仕様）、gml（地理的位置情報仕様）などに依存していることがわかる。

ここで、デマンドレスポンス情報を受信し、なかでも電力量比率を受信した際にのみ空調を制御するような組込機器装置Ｘの設計を考える。このためには、Eventsメッセージ中のeiEvent要素を受信できればよい。個々のeiEvent要素により記述される情報を、特にイベントと呼ぶ。例えば、上記機種別データ設計のように、装置Ｘ（組込機器２）についての機種別データ設計を行う。装置Ｘの機種別データ設計を用いて簡約化を行うと、例えば図１２Ａ乃至図１２Ｃに示すような構造規定を得ることができる。

本システムのサーバ側通信装置１において、上記装置Ｘの機種別データ設計より簡約された機種別構造規定を生成し、これから機種別構造化文書符号文法を生成する。機種別構造化文書符号文法は、当該機種Ｘに導入され、サーバ側通信装置１との通信に利用される。装置Ｘは、自身の機種を示すために、ＨＴＴＰヘッダあるいは構造化文書符号ヘッダにおいて、機種Ｘに相当する符号を付与する。具体的には、ＨＴＴＰヘッダのContent-Typeにおいて、「dev=X」のようなパラメータを付与するか、構造化文書符号ヘッダのschemaIdにおいて、「app0+devX」のような機種別構造規定識別子を付与する、といった方式を採る。

本システムのサーバ側通信装置１は、装置Ｘからの通信に対して、対応する機種別構造化文書符号文法を利用する。この機種別構造化文書符号文法は、装置Ｘに導入された構造化文書符号文法と同一である。この結果、個々の組込機器を含むクライアント側通信装置２に対して最適化した構造化文書符号文法を利用しつつ、構造化文書の処理部１６においては、統合された（機種別最適化処理が隠蔽された）処理を実施することができる。

（簡約構造規定の具体例１）
上記の機種別データ設計に基づいて参考文献［２］の公開構造規定群を簡約したものの例を図１２Ａ乃至図１２Ｃに示す。これは、公開仕様であるOASIS EI（参考文献［２］参照）をもとに生成した派生著作物であり、原著作権はＯＡＳＩＳ（Organization for the Advancement of Structured Information Standards）に属する。

（簡約構造規定の具体例２）
例示のため、簡単な規準構造規定（ＸＭＬスキーマ）を対象とした簡約の例を示す。

＜規準構造規定＞
図１３は架空のアドレスブックのＸＭＬスキーマを示しており、図１４は架空のＸＭＬ文書インスタンスを示している。このＸＭＬスキーマは、そのインスタンス例に示すように、ある程度の柔軟性を持っている。すなわち、「personName」が「given（名）」、「middle（ミドルネーム）」、「family（姓）」、「prefix（称号）」を含んでいることから、個人名の表記方法に柔軟性がある。

＜簡約された構造規定：表現を変更しない範囲＞
ここで、日本国向けのアドレスブックアプリケーションにおいて、必ず姓名を用い、prefix（称号）は用いないこととする。そうすると、図１５のように簡約スキーマを作成することができる。そのインスタンス例を図１６に示す。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…サーバ側通信装置
２…クライアント側通信装置（組込機器）
３…ネットワーク
４…構造規定簡約エンジン
５，９…通信部
６，８…構造化文書
７…構造化文書符号

Claims (9)

1. 複数の機種判別符号と、該機種判別符号に対応する複数の構造化文書符号文法とを関連付けて記憶する第１の格納部と、
   通信対象の機種を判定する判定部と、
   前記判定部により判定された機種の機種判別符号に対応する構造化文書符号文法を前記第１の格納部から選択し、該構造化文書符号文法を用いて構造化文書を符号化し、または受信した構造化文書符号を、前記構造化文書符号文法を用いて復号する第１の処理部と、
   を具備する通信装置。
2. 前記構造化文書の内部データ表現を用いて前記構造化文書をアプリケーション処理する第２の処理部をさらに具備し、
   前記内部表現は、前記機種判別符号に対応する複数の構造化文書符号文法に依らず同一である請求項１に記載の装置。
3. 規準構造規定を記憶する第１の格納部と、
   １つの機種について必要な少なくとも構造化文書の要素または属性を示す機種別データ設計を記憶する第２の格納部と、
   前記機種別データ設計に従って前記規準構造規定を簡約することにより、簡約された構造規定を生成する構造規定簡約エンジンと、
   前記機種の機種判別符合と、前記簡約された構造規定に基づく構造化文書符号文法とを関連付けて記憶する第４の格納部と、
   を具備し、前記機種を対象とした構造化文書の通信において、前記構造化文書符号文法が選択される通信装置。
4. 複数の機種判別符号と、該機種判別符号に対応する複数の構造化文書符号文法とを第１の格納部が関連付けて記憶するステップと、
   通信対象の機種を判定部が判定するステップと、
   第１の処理部が、前記判定部により判定された機種の機種判別符号に対応する構造化文書符号文法を前記第１の格納部から選択し、該構造化文書符号文法を用いて構造化文書を符号化し、または受信した構造化文書符号を、前記構造化文書符号文法を用いて復号するステップと、を含む通信方法。
5. 前記構造化文書の内部データ表現を用いて前記構造化文書を第２の処理部がアプリケーション処理するステップをさらに含み、
   前記内部表現は、前記機種判別符号に対応する複数の構造化文書符号文法に依らず同一である請求項４に記載の方法。
6. 第１の通信装置と第２の通信装置がネットワークを介して接続された通信システムであって、
   前記第１の通信装置と前記第２の通信装置のいずれか一方は、
   複数の機種判別符号と、該機種判別符号に対応する複数の構造化文書符号文法とを関連付けて記憶する第１の格納部と、
   通信対象の機種を判定する判定部と、
   前記判定部により判定された機種の機種判別符号に対応する構造化文書符号文法を前記第１の格納部から選択し、該構造化文書符号文法を用いて構造化文書を符号化し、または受信した構造化文書符号を、前記構造化文書符号文法を用いて復号する第１の処理部と、
   を具備し、
   前記第１の通信装置と前記第２の通信装置のいずれか他方は、その機種に対応する構造化文書符号文法を用いて前記第１の通信装置と前記第２の通信装置のいずれか一方と通信する、通信システム。
7. 第１の通信装置と第２の通信装置がネットワークを介して接続された通信システムであって、
   前記第１の通信装置と前記第２の通信装置のいずれか一方は、
   規準構造規定を記憶する第１の格納部と、
   １つの機種について必要な少なくとも構造化文書の要素または属性を示す機種別データ設計を記憶する第２の格納部と、
   前記機種別データ設計に従って前記規準構造規定を簡約することにより、簡約された構造規定を生成する構造規定簡約エンジンと、
   前記機種の機種判別符合と、前記簡約された構造規定に基づく構造化文書符号文法とを関連付けて記憶する第４の格納部と、
   を具備し、前記機種を対象とした構造化文書の通信において、前記構造化文書符号文法が選択され、
   前記第１の通信装置と前記第２の通信装置のいずれか他方は、その機種に対応する構造化文書符号文法を用いて前記第１の通信装置と前記第２の通信装置のいずれか一方と通信する、通信システム。
8. コンピュータを、
   複数の機種判別符号と、該機種判別符号に対応する複数の構造化文書符号文法とを関連付けて記憶する第１の格納部、
   通信対象の機種を判定する判定部、
   前記判定部により判定された機種の機種判別符号に対応する構造化文書符号文法を前記第１の格納部から選択し、該構造化文書符号文法を用いて構造化文書を符号化し、または受信した構造化文書符号を、前記構造化文書符号文法を用いて復号する第１の処理部、
   として機能させるためのプログラム。
9. コンピュータを、
   規準構造規定を記憶する第１の格納部、
   １つの機種について必要な少なくとも構造化文書の要素または属性を示す機種別データ設計を記憶する第２の格納部、
   前記機種別データ設計に従って前記規準構造規定を簡約することにより、簡約された構造規定を生成する構造規定簡約エンジン、
   前記機種の機種判別符合と、前記簡約された構造規定に基づく構造化文書符号文法とを関連付けて記憶する第４の格納部、
   として機能させるプログラムであって、前記機種を対象とした構造化文書の通信において、前記構造化文書符号文法が選択される、プログラム。

Images