JP2848298B2 - 電文送受信方式と電文送受信方法 - Google Patents
電文送受信方式と電文送受信方法Info
- Publication number
- JP2848298B2 JP2848298B2 JP7331324A JP33132495A JP2848298B2 JP 2848298 B2 JP2848298 B2 JP 2848298B2 JP 7331324 A JP7331324 A JP 7331324A JP 33132495 A JP33132495 A JP 33132495A JP 2848298 B2 JP2848298 B2 JP 2848298B2
- Authority
- JP
- Japan
- Prior art keywords
- message
- transmission
- application
- serial number
- tcp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Computer And Data Communications (AREA)
- Communication Control (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
Description
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明はＴＣＰ／ＩＰプロト
コルを利用する電文送受信方式および電文送受信方法に
関し、特に通信障害時の送信側ＡＰと受信側ＡＰの障害
認識を一致させることの出来る通信システムの電文送受
信方式と電文送受信方法に関する。
コルを利用する電文送受信方式および電文送受信方法に
関し、特に通信障害時の送信側ＡＰと受信側ＡＰの障害
認識を一致させることの出来る通信システムの電文送受
信方式と電文送受信方法に関する。
【０００２】
【従来の技術】従来、ＵＮＩＸ−ＯＳ上でノード間の電
文の送受信はＴＣＰ／ＩＰプロトコルを実装する場合、
ソケットインタフェースを利用するのが一般的である。
ソケットインタフェースとは、ＧＳＩ−ＮＩＣ（Gevern
ment System Inc-Network Information Center）が公開
するＲＦＣ（Request for Comments）にのっとってアプ
リケーションに提供するＴＣＰ／ＩＰとのインタフェー
スの俗称である。
文の送受信はＴＣＰ／ＩＰプロトコルを実装する場合、
ソケットインタフェースを利用するのが一般的である。
ソケットインタフェースとは、ＧＳＩ−ＮＩＣ（Gevern
ment System Inc-Network Information Center）が公開
するＲＦＣ（Request for Comments）にのっとってアプ
リケーションに提供するＴＣＰ／ＩＰとのインタフェー
スの俗称である。
【０００３】図４に示すように、ソケットインタフェー
ス７としての機能は、ユーザアプリケション（ユーザＡ
Ｐ）６からの電文送信要求（ステップ４−１）に対して
受けつけられる状態であれば、要求を受理した旨をユー
ザＡＰ６へ電文受理応答（ステップ４−２）として応答
する。ユーザＡＰ６としては、この応答を受けて要求が
完了したと判断し、次の処理を実施する。実際にはＴＣ
Ｐ／ＩＰ以下８〜１０で、非同期にリモートホストのユ
ーザＡＰ１２との通信が行なわれる（ステップ４−２〜
ステップ４−７）。平常時は、ＴＣＰ／ＩＰプロトコル
の信頼性の範囲で送信側ＡＰ６と受信側ＡＰ１２で認識
のずれが発生することはないが、ノード障害またはネッ
トワーク障害等で、コネクションが切断された場合、Ｔ
ＣＰ／ＩＰ以下のキューイングバッファ内の電文が亡失
する恐れがある。すなわち、送信側のユーザＡＰ６は送
信したという認識であるにもかかわらず、受信側ユーザ
ＡＰ１２では実際には受信していないという認識のずれ
が発生する可能性がありうる。
ス７としての機能は、ユーザアプリケション（ユーザＡ
Ｐ）６からの電文送信要求（ステップ４−１）に対して
受けつけられる状態であれば、要求を受理した旨をユー
ザＡＰ６へ電文受理応答（ステップ４−２）として応答
する。ユーザＡＰ６としては、この応答を受けて要求が
完了したと判断し、次の処理を実施する。実際にはＴＣ
Ｐ／ＩＰ以下８〜１０で、非同期にリモートホストのユ
ーザＡＰ１２との通信が行なわれる（ステップ４−２〜
ステップ４−７）。平常時は、ＴＣＰ／ＩＰプロトコル
の信頼性の範囲で送信側ＡＰ６と受信側ＡＰ１２で認識
のずれが発生することはないが、ノード障害またはネッ
トワーク障害等で、コネクションが切断された場合、Ｔ
ＣＰ／ＩＰ以下のキューイングバッファ内の電文が亡失
する恐れがある。すなわち、送信側のユーザＡＰ６は送
信したという認識であるにもかかわらず、受信側ユーザ
ＡＰ１２では実際には受信していないという認識のずれ
が発生する可能性がありうる。
【０００４】上記亡失を防止するため、従来は復旧後、
ユーザＡＰレベル間で、複雑な制御情報の交換を行って
電文の亡失をリカバリしていた。具体的なリカバリ方法
としては、 １）ユーザＡＰレベルで通過番号の管理を行い、障害復
旧時に通過番号合わせを行い、自動でリカバリする。
ユーザＡＰレベル間で、複雑な制御情報の交換を行って
電文の亡失をリカバリしていた。具体的なリカバリ方法
としては、 １）ユーザＡＰレベルで通過番号の管理を行い、障害復
旧時に通過番号合わせを行い、自動でリカバリする。
【０００５】２）オペレータが介入し、送受双方の送受
信記録を参照し、再送を実施することにより、双方の認
識のずれを補正しリカバリする。などの方法が行われて
いた。
信記録を参照し、再送を実施することにより、双方の認
識のずれを補正しリカバリする。などの方法が行われて
いた。
【０００６】
【発明が解決しようとする課題】上述した従来の電文送
受信方式は、ネットワーク及びノードの障害から引き起
こされる電文亡失により、送信側と受信側とで電文送受
の認識のずれが生じる場合があり、その結果、ユーザＡ
Ｐレベル間で、複雑な制御情報の交換を行って電文の亡
失をリカバリしていたが、上述の１）のリカバリ方法で
は、専用のロジックをユーザＡＰに持たせる必要があ
り、そのためステップ数の増加、プログラム品質の低下
を招くという欠点があり、また、２）による方法では、
人手により処理するため、回復に時間を要するという欠
点があった。
受信方式は、ネットワーク及びノードの障害から引き起
こされる電文亡失により、送信側と受信側とで電文送受
の認識のずれが生じる場合があり、その結果、ユーザＡ
Ｐレベル間で、複雑な制御情報の交換を行って電文の亡
失をリカバリしていたが、上述の１）のリカバリ方法で
は、専用のロジックをユーザＡＰに持たせる必要があ
り、そのためステップ数の増加、プログラム品質の低下
を招くという欠点があり、また、２）による方法では、
人手により処理するため、回復に時間を要するという欠
点があった。
【０００７】
【課題を解決するための手段】 第１の発明は、ＴＣＰ
／ＩＰプロトコルを利用するアプリケーション間での電
文送受信方式において、前記アプリケーションと前記Ｔ
ＣＰ／ＩＰプロトコル以下の処理層との間にあって、送
信側アプリケーションから送信要求された前記電文に対
し前記送信側アプリケーションに通番を付して電文受理
応答を行い、該電文が受信側アプリケーションに送達さ
れたことを確認してから前記送信側アプリケーションに
前記送信要求の次の処理に進むことを指示する電文送信
完了を同じ通番を付して通知するとともに、前記電文受
理応答の通番が前記電文送信完了に付されて通知されて
いない電文があれば、該電文をノード障害またはネット
ワーク障害により亡失した電文として再送するＬＡＮ通
信ドライバを具備したことを特徴とする。
／ＩＰプロトコルを利用するアプリケーション間での電
文送受信方式において、前記アプリケーションと前記Ｔ
ＣＰ／ＩＰプロトコル以下の処理層との間にあって、送
信側アプリケーションから送信要求された前記電文に対
し前記送信側アプリケーションに通番を付して電文受理
応答を行い、該電文が受信側アプリケーションに送達さ
れたことを確認してから前記送信側アプリケーションに
前記送信要求の次の処理に進むことを指示する電文送信
完了を同じ通番を付して通知するとともに、前記電文受
理応答の通番が前記電文送信完了に付されて通知されて
いない電文があれば、該電文をノード障害またはネット
ワーク障害により亡失した電文として再送するＬＡＮ通
信ドライバを具備したことを特徴とする。
【０００８】 また、第２の発明は、ＴＣＰ／ＩＰプロ
トコルを利用するアプリケーション間での電文送受信方
法において、前記アプリケーションと前記ＴＣＰ／ＩＰ
プロトコル以下の処理層との間にＬＡＮ通信ドライバを
用意し、送信側アプリケーションは前記送信側アプリケ
ーションから送信要求した前記電文に対し通番が付され
た電文受理応答を受信し、該電文が受信側アプリケーシ
ョンに送達されたことを前記ＬＡＮ通信ドライバを介し
て同じ通番が付された電文送信完了を通知されることに
より確認してから前記送信要求の次の処理に進むととも
に、前記電文受理応答の通番が前記電文送信完了に付さ
れて通知されていない電文があれば、該電文をノード障
害またはネットワーク障害により亡失した電文として前
記ＬＡＮ通信ドライバにより再送処理することを特徴と
する。
トコルを利用するアプリケーション間での電文送受信方
法において、前記アプリケーションと前記ＴＣＰ／ＩＰ
プロトコル以下の処理層との間にＬＡＮ通信ドライバを
用意し、送信側アプリケーションは前記送信側アプリケ
ーションから送信要求した前記電文に対し通番が付され
た電文受理応答を受信し、該電文が受信側アプリケーシ
ョンに送達されたことを前記ＬＡＮ通信ドライバを介し
て同じ通番が付された電文送信完了を通知されることに
より確認してから前記送信要求の次の処理に進むととも
に、前記電文受理応答の通番が前記電文送信完了に付さ
れて通知されていない電文があれば、該電文をノード障
害またはネットワーク障害により亡失した電文として前
記ＬＡＮ通信ドライバにより再送処理することを特徴と
する。
【０００９】
【発明の実施の形態】次に、本発明について図面を参照
して説明する。
して説明する。
【００１０】図１は本発明の正常通信時の一実施例を示
す動作フロー図、図２および図３は通信異常時の一実施
例を示す動作フロー図である。
す動作フロー図、図２および図３は通信異常時の一実施
例を示す動作フロー図である。
【００１１】図１を参照すると、本発明は、従来のユー
ザアプリケーションとソケットインタフェース（従来技
術を参照）との間にＬＡＮ通信ドライバを有することを
特徴とする。
ザアプリケーションとソケットインタフェース（従来技
術を参照）との間にＬＡＮ通信ドライバを有することを
特徴とする。
【００１２】以下、図１の実施例に基き正常通信時の動
作を説明する。
作を説明する。
【００１３】送信側ユーザアプリケーション（以下ユー
ザＡＰと称す）からの電文送信要求（ステップ１−１）
に対してＬＡＮ通信ドライバ２は０〜１２７のサイクリ
ック通番を付与して、送信側ソケットインタフェースと
受信側ソケットインタフェースとの間の処理を示すソケ
ット間インタフェース３に対して電文送信要求を行う
（ステップ１−２）。ステップ１−３の電文受理応答
は、ソケット間インタェース３におけるＴＣＰ／ＩＰド
ライバが、ＬＡＮ通信ドライバ２の要求を認識し、責任
がＴＣＰ／ＩＰドライバに移行したことを意味する。
ザＡＰと称す）からの電文送信要求（ステップ１−１）
に対してＬＡＮ通信ドライバ２は０〜１２７のサイクリ
ック通番を付与して、送信側ソケットインタフェースと
受信側ソケットインタフェースとの間の処理を示すソケ
ット間インタフェース３に対して電文送信要求を行う
（ステップ１−２）。ステップ１−３の電文受理応答
は、ソケット間インタェース３におけるＴＣＰ／ＩＰド
ライバが、ＬＡＮ通信ドライバ２の要求を認識し、責任
がＴＣＰ／ＩＰドライバに移行したことを意味する。
【００１４】受信側ユーザＡＰ５からの電文受信要求
（ステップ１−４）に対してＬＡＮ通信ドライバ４はソ
ケット間インタフェース３に対して電文受信要求を行う
（ステップ１−５）。ＬＡＮ通信ドライバ４はソケット
間インタフェース３から電文取得時（ステップ１−６）
に、０〜１２７のサイクリック通番も取得し管理する。
（ステップ１−４）に対してＬＡＮ通信ドライバ４はソ
ケット間インタフェース３に対して電文受信要求を行う
（ステップ１−５）。ＬＡＮ通信ドライバ４はソケット
間インタフェース３から電文取得時（ステップ１−６）
に、０〜１２７のサイクリック通番も取得し管理する。
【００１５】ＬＡＮ通信ドライバ４はユーザＡＰ５へ実
際の電文を渡した後（ステップ１−７）、ソケット間イ
ンタフェース３に対して送達確認の送信要求を行う（ス
テップ１−８）。この時のステップ１−９の受理応答
は、ソケット間インタェース３におけるＴＣＰ／ＩＰド
ライバが、ＬＡＮ通信ドライバ４の要求を認識し、責任
がＴＣＰ／ＩＰドライバに移行したことを意味する。送
信側のＬＡＮ通信ドライバ２は、送達確認受信要求（ス
テップ１−１０）に対するこの送達確認取得（ステップ
１−１１）をもって、送信電文が確実に受信側へ届けら
れたことを認識しユーザＡＰ１に対して電文送信完了を
通知する（ステップ１−１２）。
際の電文を渡した後（ステップ１−７）、ソケット間イ
ンタフェース３に対して送達確認の送信要求を行う（ス
テップ１−８）。この時のステップ１−９の受理応答
は、ソケット間インタェース３におけるＴＣＰ／ＩＰド
ライバが、ＬＡＮ通信ドライバ４の要求を認識し、責任
がＴＣＰ／ＩＰドライバに移行したことを意味する。送
信側のＬＡＮ通信ドライバ２は、送達確認受信要求（ス
テップ１−１０）に対するこの送達確認取得（ステップ
１−１１）をもって、送信電文が確実に受信側へ届けら
れたことを認識しユーザＡＰ１に対して電文送信完了を
通知する（ステップ１−１２）。
【００１６】この方法により、正常時は送信側ユーザＡ
Ｐ１と受信側ユーザＡＰ５との間で、送信された電文に
ついての認識のずれはない。
Ｐ１と受信側ユーザＡＰ５との間で、送信された電文に
ついての認識のずれはない。
【００１７】次に、図２はステップ１−３の電文受理応
答は完了しているが、ステップ１−３−１でネットワー
クまたはノードの障害が発生したため、ステップ１−７
の電文取得が未完の場合の動作フロー図である。
答は完了しているが、ステップ１−３−１でネットワー
クまたはノードの障害が発生したため、ステップ１−７
の電文取得が未完の場合の動作フロー図である。
【００１８】ステップ１−３−２で、再びコネクション
が確立された時、送信側はステップ１−３の電文受理応
答における受信通番の中でステップ１−１１の送達確認
取得を処理していないものがあれば、再びステップ１−
２を行う。したがってユーザＡＰからはコネクションが
確立されると同時に暗黙のうちにリカバリが行なわれて
いることになり、アプリケーション間での送受の認識の
ずれはなくなる。
が確立された時、送信側はステップ１−３の電文受理応
答における受信通番の中でステップ１−１１の送達確認
取得を処理していないものがあれば、再びステップ１−
２を行う。したがってユーザＡＰからはコネクションが
確立されると同時に暗黙のうちにリカバリが行なわれて
いることになり、アプリケーション間での送受の認識の
ずれはなくなる。
【００１９】次に、図３はステップ１−９の受理応答は
完了しているが、ステップ１−９−１でネットワークま
たはノードの障害が発生したため、ステップ１−１１の
送達確認取得が未完の場合の動作フロー図である。
完了しているが、ステップ１−９−１でネットワークま
たはノードの障害が発生したため、ステップ１−１１の
送達確認取得が未完の場合の動作フロー図である。
【００２０】ステップ１−９−２で再びコネクションが
確立された時、送信側はステップ１−３の電文受理応答
における受信通番の中でステップ１−１１の送達確認取
得を処理していないものがあれば、再びステップ１−２
を行う。しかし、受信側ではその通番の電文はすでに受
信側ユーザＡＰ５へ渡しているため、ＬＡＮ通信ドライ
バ４内で重複電文として破棄する。そして次の電文から
受信を行う。したがって、ユーザＡＰからは、コネクシ
ョンが確立されると同時に暗黙のうちにリカバリが行な
われていることになり、アプリケーション間での送受の
認識のずれはなくなる。
確立された時、送信側はステップ１−３の電文受理応答
における受信通番の中でステップ１−１１の送達確認取
得を処理していないものがあれば、再びステップ１−２
を行う。しかし、受信側ではその通番の電文はすでに受
信側ユーザＡＰ５へ渡しているため、ＬＡＮ通信ドライ
バ４内で重複電文として破棄する。そして次の電文から
受信を行う。したがって、ユーザＡＰからは、コネクシ
ョンが確立されると同時に暗黙のうちにリカバリが行な
われていることになり、アプリケーション間での送受の
認識のずれはなくなる。
【００２１】
【発明の効果】以上説明したように、本発明の電文送受
信方式は、ユーザＡＰはＬＡＮ通信ドライバからの電文
送信完了を受けてから次の処理に進むようにし、かつネ
ットワークまたはノードの障害が発生しても、ＬＡＮ通
信ドライバ間で回復処理を行うようにしたことにより、
ネットワークやノード障害発生時において、オペレータ
の介入や、ユーザＡＰに対する通番合わせのための複雑
なロジックを追加することなしに、ユーザＡＰ間での送
受の認識のずれを完全になくすことができるという効果
がある。
信方式は、ユーザＡＰはＬＡＮ通信ドライバからの電文
送信完了を受けてから次の処理に進むようにし、かつネ
ットワークまたはノードの障害が発生しても、ＬＡＮ通
信ドライバ間で回復処理を行うようにしたことにより、
ネットワークやノード障害発生時において、オペレータ
の介入や、ユーザＡＰに対する通番合わせのための複雑
なロジックを追加することなしに、ユーザＡＰ間での送
受の認識のずれを完全になくすことができるという効果
がある。
【図１】本発明の正常通信時の一実施例を示す動作フロ
ー図である。
ー図である。
【図２】本発明の通信異常時の一実施例を示す動作フロ
ー図である。
ー図である。
【図３】本発明の他の通信異常時の一実施例を示す動作
フロー図である。
フロー図である。
【図４】従来例の一実施例を示す動作フロー図である。
１，５ ユーザＡＰ（ユーザアプリケーション） ２，４ ＬＡＮ通信ドライバ ３ ソケット間インタフェース ６，１２ ユーザＡＰ ７，１１ ソケットインタフェース ８，１０ ＴＣＰ／ＩＰ以下の層 ９ ＬＡＮ
Claims (2)
- 【請求項１】 ＴＣＰ／ＩＰプロトコルを利用するアプ
リケーション間での電文送受信方式において、前記アプ
リケーションと前記ＴＣＰ／ＩＰプロトコル以下の処理
層との間にあって、送信側アプリケーションから送信要
求された前記電文に対し前記送信側アプリケーションに
通番を付して電文受理応答を行い、該電文が受信側アプ
リケーションに送達されたことを確認してから前記送信
側アプリケーションに前記送信要求の次の処理に進むこ
とを指示する電文送信完了を同じ通番を付して通知する
とともに、前記電文受理応答の通番が前記電文送信完了
に付されて通知されていない電文があれば、該電文をノ
ード障害またはネットワーク障害により亡失した電文と
して再送するＬＡＮ通信ドライバを具備したことを特徴
とする電文送受信方式。 - 【請求項２】 ＴＣＰ／ＩＰプロトコルを利用するアプ
リケーション間での電文送受信方法において、前記アプ
リケーションと前記ＴＣＰ／ＩＰプロトコル以下の処理
層との間にＬＡＮ通信ドライバを用意し、送信側アプリ
ケーションは前記送信側アプリケーションから送信要求
した前記電文に対し通番が付された電文受理応答を受信
し、該電文が受信側アプリケーションに送達されたこと
を前記ＬＡＮ通信ドライバを介して同じ通番が付された
電文送信完了を通知されることにより確認してから前記
送信要求の次の処理に進むとともに、前記電文受理応答
の通番が前記電文送信完了に付されて通知されていない
電文があれば、該電文をノード障害またはネットワーク
障害により亡失した電文として前記ＬＡＮ通信ドライバ
により再送処理することを特徴とする電文送受信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP7331324A JP2848298B2 (ja) | 1995-12-20 | 1995-12-20 | 電文送受信方式と電文送受信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP7331324A JP2848298B2 (ja) | 1995-12-20 | 1995-12-20 | 電文送受信方式と電文送受信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09171495A JPH09171495A (ja) | 1997-06-30 |
| JP2848298B2 true JP2848298B2 (ja) | 1999-01-20 |
Family
ID=18242416
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP7331324A Expired - Fee Related JP2848298B2 (ja) | 1995-12-20 | 1995-12-20 | 電文送受信方式と電文送受信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2848298B2 (ja) |
-
1995
- 1995-12-20 JP JP7331324A patent/JP2848298B2/ja not_active Expired - Fee Related
Non-Patent Citations (1)
| Title |
|---|
| Ｍ．Ｔ．ロース著，「実践的ＯＳＩ論」株式会社トッパン，１９９１−４−３０，ｐ３６９−ｐ３９１ |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09171495A (ja) | 1997-06-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0464014A2 (en) | Communications systems using a fault tolerant protocol | |
| US6760766B1 (en) | Data transmission method and device | |
| JP5695558B2 (ja) | サーバ故障時におけるクライアント・アプリケーションのより速い回復を可能にするための方法 | |
| JPS63197259A (ja) | ネットワーク通信方法 | |
| JPS63109624A (ja) | 一斉通信方式 | |
| US6097731A (en) | Data retransmission method used in confirmation information transmissions | |
| JP2848298B2 (ja) | 電文送受信方式と電文送受信方法 | |
| JP3194868B2 (ja) | パケット転送装置 | |
| JPH10243050A (ja) | データ通信システム | |
| JP3428883B2 (ja) | データ通信方法およびデータ通信装置 | |
| JPH1070523A (ja) | パケット伝送方法及び装置 | |
| CN111464514A (zh) | 一种tcp热备份方法及系统 | |
| JP4759418B2 (ja) | メッセージ回復システムおよび回復方法 | |
| CN111417116B (zh) | 通过att、读写和异常处理来适配的通信方法及系统 | |
| JPH09224017A (ja) | 無線パケット再送制御方法 | |
| JP3219070B2 (ja) | 回線復旧方式 | |
| KR100517974B1 (ko) | 무선통신 시스템의 시퀀스 동기화 방법 | |
| JP3131455B2 (ja) | 通信データ保証方式 | |
| JPH0622000A (ja) | メッセージ紛失防止機能を有するメッセージ通信システム | |
| EP2405627B1 (en) | Method for operating a remote procedure call handler in a client and a server and computer system comprising the same | |
| CN111817825A (zh) | 一种tcp数据重传方法及系统 | |
| JP2834006B2 (ja) | 障害回復処理方式及び方法 | |
| JP2001077881A (ja) | パケット通信ネットワークシステム | |
| JP2759574B2 (ja) | データ伝送処理方法およびデータ伝送処理装置 | |
| CN117082125A (zh) | 一种基于tcp/ip协议和对等端通信程序的数据交换方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071106 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081106 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081106 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091106 Year of fee payment: 11 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091106 Year of fee payment: 11 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101106 Year of fee payment: 12 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111106 Year of fee payment: 13 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111106 Year of fee payment: 13 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121106 Year of fee payment: 14 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121106 Year of fee payment: 14 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131106 Year of fee payment: 15 |
|
| LAPS | Cancellation because of no payment of annual fees |