JPH09171495A - System and method for transmitting/receiving telegraphic message - Google Patents
System and method for transmitting/receiving telegraphic messageInfo
- Publication number
- JPH09171495A JPH09171495A JP7331324A JP33132495A JPH09171495A JP H09171495 A JPH09171495 A JP H09171495A JP 7331324 A JP7331324 A JP 7331324A JP 33132495 A JP33132495 A JP 33132495A JP H09171495 A JPH09171495 A JP H09171495A
- Authority
- JP
- Japan
- Prior art keywords
- transmission
- message
- user
- application
- 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.)
- Granted
Links
Landscapes
- Maintenance And Management Of Digital Transmission (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
Abstract
Description
【０００１】[0001]
【発明の属する技術分野】本発明はＴＣＰ／ＩＰプロト
コルを利用する電文送受信方式および電文送受信方法に
関し、特に通信障害時の送信側ＡＰと受信側ＡＰの障害
認識を一致させることの出来る通信システムの電文送受
信方式と電文送受信方法に関する。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a telegram transmission / reception method and a telegram transmission / reception method using a TCP / IP protocol, and more particularly to a communication system capable of making fault recognition of a transmission side AP and a reception side AP coincident when a communication fault occurs. The present invention relates to a message sending / receiving method and a message sending / receiving method.
【０００２】[0002]
【従来の技術】従来、ＵＮＩＸ−ＯＳ上でノード間の電
文の送受信はＴＣＰ／ＩＰプロトコルを実装する場合、
ソケットインタフェースを利用するのが一般的である。
ソケットインタフェースとは、ＧＳＩ−ＮＩＣ（Gevern
ment System Inc-Network Information Center）が公開
するＲＦＣ（Request for Comments）にのっとってアプ
リケーションに提供するＴＣＰ／ＩＰとのインタフェー
スの俗称である。2. Description of the Related Art Conventionally, when a TCP / IP protocol is mounted on a UNIX-OS, transmission / reception of a message between nodes is
It is common to use the socket interface.
The socket interface is GSI-NIC (Gevern
ment System Inc-Network Information Center) is a generic name for an interface with TCP / IP provided to an application according to an RFC (Request for Comments) published by the Network Information Center.
【０００３】図４に示すように、ソケットインタフェー
ス７としての機能は、ユーザアプリケション（ユーザＡ
Ｐ）６からの電文送信要求（ステップ４−１）に対して
受けつけられる状態であれば、要求を受理した旨をユー
ザＡＰ６へ電文受理応答（ステップ４−２）として応答
する。ユーザＡＰ６としては、この応答を受けて要求が
完了したと判断し、次の処理を実施する。実際にはＴＣ
Ｐ／ＩＰ以下８〜１０で、非同期にリモートホストのユ
ーザＡＰ１２との通信が行なわれる（ステップ４−２〜
ステップ４−７）。平常時は、ＴＣＰ／ＩＰプロトコル
の信頼性の範囲で送信側ＡＰ６と受信側ＡＰ１２で認識
のずれが発生することはないが、ノード障害またはネッ
トワーク障害等で、コネクションが切断された場合、Ｔ
ＣＰ／ＩＰ以下のキューイングバッファ内の電文が亡失
する恐れがある。すなわち、送信側のユーザＡＰ６は送
信したという認識であるにもかかわらず、受信側ユーザ
ＡＰ１２では実際には受信していないという認識のずれ
が発生する可能性がありうる。As shown in FIG. 4, the function of the socket interface 7 is as follows.
P) If it is in a state of being able to accept the message transmission request from the device 6 (step 4-1), the fact that the request has been accepted is returned to the user AP 6 as a message acceptance response (step 4-2). Upon receiving this response, the user AP 6 determines that the request has been completed, and executes the next process. Actually TC
The communication with the user AP 12 of the remote host is asynchronously performed in 8 to 10 below P / IP (step 4-2).
Steps 4-7). In normal times, there is no discrepancy in recognition between the sending AP 6 and the receiving AP 12 within the reliability of the TCP / IP protocol, but if the connection is disconnected due to a node failure or network failure, T
The telegram in the queuing buffer below CP / IP may be lost. That is, although the transmission-side user AP6 recognizes that the user AP6 has transmitted, there is a possibility that the reception-side user AP12 may deviate from the recognition that the reception-side user AP12 has not actually received it.
【０００４】上記亡失を防止するため、従来は復旧後、
ユーザＡＰレベル間で、複雑な制御情報の交換を行って
電文の亡失をリカバリしていた。具体的なリカバリ方法
としては、 １）ユーザＡＰレベルで通過番号の管理を行い、障害復
旧時に通過番号合わせを行い、自動でリカバリする。In order to prevent the above-mentioned loss, conventionally, after recovery,
A complicated control information is exchanged between the user AP levels to recover the loss of the message. Specific recovery methods are as follows: 1) The pass number is managed at the user AP level, the pass number is adjusted at the time of failure recovery, and the recovery is automatically performed.
【０００５】２）オペレータが介入し、送受双方の送受
信記録を参照し、再送を実施することにより、双方の認
識のずれを補正しリカバリする。などの方法が行われて
いた。2) The operator intervenes, refers to the transmission / reception records of both the transmitting and receiving sides, and retransmits them to correct the deviation of recognition between the both sides and recover. And so on.
【０００６】[0006]
【発明が解決しようとする課題】上述した従来の電文送
受信方式は、ネットワーク及びノードの障害から引き起
こされる電文亡失により、送信側と受信側とで電文送受
の認識のずれが生じる場合があり、その結果、ユーザＡ
Ｐレベル間で、複雑な制御情報の交換を行って電文の亡
失をリカバリしていたが、上述の１）のリカバリ方法で
は、専用のロジックをユーザＡＰに持たせる必要があ
り、そのためステップ数の増加、プログラム品質の低下
を招くという欠点があり、また、２）による方法では、
人手により処理するため、回復に時間を要するという欠
点があった。In the above-mentioned conventional telegram transmission / reception system, the telegram transmission / reception may be misrecognized between the transmission side and the reception side due to the telegram loss caused by the failure of the network and the node. As a result, user A
Although complicated control information was exchanged between P levels to recover the loss of the telegram, the recovery method of 1) above requires the user AP to have a dedicated logic, which reduces the number of steps. However, the method according to 2) has the drawback of increasing the number of programs and degrading the program quality.
Since it is manually processed, there is a drawback that it takes time to recover.
【０００７】[0007]
【課題を解決するための手段】第１の発明は、ＴＣＰ／
ＩＰプロトコルを利用するアプリケーション間での電文
送受信方式において、前記アプリケーションと前記ＴＣ
Ｐ／ＩＰプロトコル以下の処理層との間にあって、送信
側アプリケーションから送信要求された前記電文が受信
側アプリケーションに送達されたことを確認してから前
記送信側アプリケーションに前記送信要求の次の処理に
進むことを指示する電文送信完了を通知するとともに、
ノード障害またはネットワーク障害により亡失した前記
電文を再送するＬＡＮ通信ドライバを具備したことを特
徴とする。A first invention is TCP /
In a method of transmitting and receiving a message between applications using the IP protocol, the application and the TC
Between the processing layers below the P / IP protocol, after confirming that the message requested to be sent by the sending application has been delivered to the receiving application, the sending application performs the next processing of the sending request. In addition to notifying the completion of message transmission to instruct to proceed,
A LAN communication driver for retransmitting the electronic message lost due to a node failure or a network failure is provided.
【０００８】また、第２の発明は、ＴＣＰ／ＩＰプロト
コルを利用するアプリケーション間での電文送受信方法
において、前記アプリケーションと前記ＴＣＰ／ＩＰプ
ロトコル以下の処理層との間にＬＡＮ通信ドライバを用
意し、送信側アプリケーションは前記送信側アプリケー
ションから送信要求した前記電文が受信側アプリケーシ
ョンに送達されたことを前記ＬＡＮ通信ドライバを介し
て確認してから前記送信要求の次の処理に進むととも
に、ノード障害またはネットワーク障害により亡失した
前記電文は前記ＬＡＮ通信ドライバにより再送処理する
ことを特徴とする。A second aspect of the present invention is a method of transmitting and receiving a message between applications using the TCP / IP protocol, wherein a LAN communication driver is prepared between the application and the processing layers below the TCP / IP protocol, The transmission side application confirms via the LAN communication driver that the message requested to be transmitted from the transmission side application has been delivered to the reception side application, and then proceeds to the next process of the transmission request, and the node failure or the network The electronic message lost due to a failure is retransmitted by the LAN communication driver.
【０００９】[0009]
【発明の実施の形態】次に、本発明について図面を参照
して説明する。Next, the present invention will be described with reference to the drawings.
【００１０】図１は本発明の正常通信時の一実施例を示
す動作フロー図、図２および図３は通信異常時の一実施
例を示す動作フロー図である。FIG. 1 is an operation flow chart showing an embodiment of the present invention during normal communication, and FIGS. 2 and 3 are operation flow charts showing an embodiment when communication is abnormal.
【００１１】図１を参照すると、本発明は、従来のユー
ザアプリケーションとソケットインタフェース（従来技
術を参照）との間にＬＡＮ通信ドライバを有することを
特徴とする。Referring to FIG. 1, the present invention is characterized by having a LAN communication driver between a conventional user application and a socket interface (see Prior Art).
【００１２】以下、図１の実施例に基き正常通信時の動
作を説明する。The operation during normal communication will be described below based on the embodiment shown in FIG.
【００１３】送信側ユーザアプリケーション（以下ユー
ザＡＰと称す）からの電文送信要求（ステップ１−１）
に対してＬＡＮ通信ドライバ２は０〜１２７のサイクリ
ック通番を付与して、送信側ソケットインタフェースと
受信側ソケットインタフェースとの間の処理を示すソケ
ット間インタフェース３に対して電文送信要求を行う
（ステップ１−２）。ステップ１−３の電文受理応答
は、ソケット間インタェース３におけるＴＣＰ／ＩＰド
ライバが、ＬＡＮ通信ドライバ２の要求を認識し、責任
がＴＣＰ／ＩＰドライバに移行したことを意味する。Request to send a message from the sending side user application (hereinafter referred to as user AP) (step 1-1)
On the other hand, the LAN communication driver 2 gives a cyclic serial number of 0 to 127 and makes a message transmission request to the inter-socket interface 3 indicating the processing between the transmitting side socket interface and the receiving side socket interface (step 1-2). The message acceptance response in step 1-3 means that the TCP / IP driver in the inter-socket interface 3 recognizes the request of the LAN communication driver 2 and the responsibility shifts to the TCP / IP driver.
【００１４】受信側ユーザＡＰ５からの電文受信要求
（ステップ１−４）に対してＬＡＮ通信ドライバ４はソ
ケット間インタフェース３に対して電文受信要求を行う
（ステップ１−５）。ＬＡＮ通信ドライバ４はソケット
間インタフェース３から電文取得時（ステップ１−６）
に、０〜１２７のサイクリック通番も取得し管理する。In response to a message reception request (step 1-4) from the receiving user AP 5, the LAN communication driver 4 makes a message reception request to the inter-socket interface 3 (step 1-5). When the LAN communication driver 4 acquires a message from the socket interface 3 (step 1-6)
In addition, the cyclic serial number of 0 to 127 is also acquired and managed.
【００１５】ＬＡＮ通信ドライバ４はユーザＡＰ５へ実
際の電文を渡した後（ステップ１−７）、ソケット間イ
ンタフェース３に対して送達確認の送信要求を行う（ス
テップ１−８）。この時のステップ１−９の受理応答
は、ソケット間インタェース３におけるＴＣＰ／ＩＰド
ライバが、ＬＡＮ通信ドライバ４の要求を認識し、責任
がＴＣＰ／ＩＰドライバに移行したことを意味する。送
信側のＬＡＮ通信ドライバ２は、送達確認受信要求（ス
テップ１−１０）に対するこの送達確認取得（ステップ
１−１１）をもって、送信電文が確実に受信側へ届けら
れたことを認識しユーザＡＰ１に対して電文送信完了を
通知する（ステップ１−１２）。After passing the actual message to the user AP 5 (step 1-7), the LAN communication driver 4 makes a transmission confirmation transmission request to the inter-socket interface 3 (step 1-8). The acceptance response in step 1-9 at this time means that the TCP / IP driver in the inter-socket interface 3 recognizes the request of the LAN communication driver 4 and the responsibility shifts to the TCP / IP driver. The LAN communication driver 2 on the transmission side recognizes that the transmission message has been reliably delivered to the reception side by the delivery confirmation acquisition (step 1-11) for the delivery confirmation reception request (step 1-10), and recognizes it to the user AP1. The completion of message transmission is notified to the user (step 1-12).
【００１６】この方法により、正常時は送信側ユーザＡ
Ｐ１と受信側ユーザＡＰ５との間で、送信された電文に
ついての認識のずれはない。According to this method, the user A on the sending side normally operates.
There is no difference in recognition of the transmitted electronic message between P1 and the receiving user AP5.
【００１７】次に、図２はステップ１−３の電文受理応
答は完了しているが、ステップ１−３−１でネットワー
クまたはノードの障害が発生したため、ステップ１−７
の電文取得が未完の場合の動作フロー図である。Next, in FIG. 2, the message acceptance response at step 1-3 is completed, but since a network or node failure occurs at step 1-3-1, step 1-7.
FIG. 7 is an operation flow diagram when the electronic message acquisition of is not completed.
【００１８】ステップ１−３−２で、再びコネクション
が確立された時、送信側はステップ１−３の電文受理応
答における受信通番の中でステップ１−１１の送達確認
取得を処理していないものがあれば、再びステップ１−
２を行う。したがってユーザＡＰからはコネクションが
確立されると同時に暗黙のうちにリカバリが行なわれて
いることになり、アプリケーション間での送受の認識の
ずれはなくなる。In step 1-3-2, when the connection is established again, the sender does not process the delivery confirmation acquisition in step 1-11 among the reception sequence numbers in the message acceptance response in step 1-3. If there is, step 1-again
Do 2 Therefore, the connection is established implicitly from the user AP at the same time that the connection is established, and there is no difference in recognition of transmission / reception between applications.
【００１９】次に、図３はステップ１−９の受理応答は
完了しているが、ステップ１−９−１でネットワークま
たはノードの障害が発生したため、ステップ１−１１の
送達確認取得が未完の場合の動作フロー図である。Next, in FIG. 3, although the acceptance response in step 1-9 is completed, the delivery confirmation acquisition in step 1-11 is incomplete because a network or node failure occurs in step 1-9-1. It is an operation | movement flow diagram in a case.
【００２０】ステップ１−９−２で再びコネクションが
確立された時、送信側はステップ１−３の電文受理応答
における受信通番の中でステップ１−１１の送達確認取
得を処理していないものがあれば、再びステップ１−２
を行う。しかし、受信側ではその通番の電文はすでに受
信側ユーザＡＰ５へ渡しているため、ＬＡＮ通信ドライ
バ４内で重複電文として破棄する。そして次の電文から
受信を行う。したがって、ユーザＡＰからは、コネクシ
ョンが確立されると同時に暗黙のうちにリカバリが行な
われていることになり、アプリケーション間での送受の
認識のずれはなくなる。When the connection is reestablished in step 1-9-2, the sending side may not process the delivery confirmation acquisition in step 1-11 among the reception serial numbers in the message acceptance response of step 1-3. If so, step 1-2 again
I do. However, on the receiving side, the message of that serial number has already been passed to the receiving-side user AP 5, so it is discarded as a duplicate message within the LAN communication driver 4. Then, it receives from the next message. Therefore, the user AP is implicitly performing the recovery at the same time as the connection is established, and there is no difference in the recognition of the transmission / reception between the applications.
【００２１】[0021]
【発明の効果】以上説明したように、本発明の電文送受
信方式は、ユーザＡＰはＬＡＮ通信ドライバからの電文
送信完了を受けてから次の処理に進むようにし、かつネ
ットワークまたはノードの障害が発生しても、ＬＡＮ通
信ドライバ間で回復処理を行うようにしたことにより、
ネットワークやノード障害発生時において、オペレータ
の介入や、ユーザＡＰに対する通番合わせのための複雑
なロジックを追加することなしに、ユーザＡＰ間での送
受の認識のずれを完全になくすことができるという効果
がある。As described above, the telegram transmission / reception method of the present invention allows the user AP to proceed to the next processing after receiving the telegram transmission completion from the LAN communication driver, and a network or node failure occurs. Even so, by performing recovery processing between LAN communication drivers,
When a network or node failure occurs, it is possible to completely eliminate the shift in the recognition of transmission / reception between the user APs without the intervention of an operator or the addition of complicated logic for matching the serial numbers to the user APs. There is.
【図１】本発明の正常通信時の一実施例を示す動作フロ
ー図である。FIG. 1 is an operation flow chart showing an embodiment during normal communication of the present invention.
【図２】本発明の通信異常時の一実施例を示す動作フロ
ー図である。FIG. 2 is an operation flow chart showing an embodiment of the present invention when communication is abnormal.
【図３】本発明の他の通信異常時の一実施例を示す動作
フロー図である。FIG. 3 is an operation flow chart showing another embodiment of the present invention at the time of communication abnormality.
【図４】従来例の一実施例を示す動作フロー図である。FIG. 4 is an operation flow chart showing an example of a conventional example.
１，５ ユーザＡＰ（ユーザアプリケーション） ２，４ ＬＡＮ通信ドライバ ３ ソケット間インタフェース ６，１２ ユーザＡＰ ７，１１ ソケットインタフェース ８，１０ ＴＣＰ／ＩＰ以下の層 ９ ＬＡＮ 1,5 user AP (user application) 2,4 LAN communication driver 3 inter-socket interface 6,12 user AP 7,11 socket interface 8,10 TCP / IP or lower layer 9 LAN
Claims (2)
リケーション間での電文送受信方式において、前記アプ
リケーションと前記ＴＣＰ／ＩＰプロトコル以下の処理
層との間にあって、送信側アプリケーションから送信要
求された前記電文が受信側アプリケーションに送達され
たことを確認してから前記送信側アプリケーションに前
記送信要求の次の処理に進むことを指示する電文送信完
了を通知するとともに、ノード障害またはネットワーク
障害により亡失した前記電文を再送するＬＡＮ通信ドラ
イバを具備したことを特徴とする電文送受信方式。1. In a telegram transmission / reception method between applications using the TCP / IP protocol, the telegram requested to be transmitted by a transmission side application is received between the application and a processing layer below the TCP / IP protocol. After confirming that the message has been delivered to the application on the sending side, the sending application is notified of the completion of sending a message instructing to proceed to the next processing of the transmission request, and the message lost due to a node failure or a network failure is retransmitted. A telegram transmission / reception system characterized by comprising a LAN communication driver for
リケーション間での電文送受信方法において、前記アプ
リケーションと前記ＴＣＰ／ＩＰプロトコル以下の処理
層との間にＬＡＮ通信ドライバを用意し、送信側アプリ
ケーションは前記送信側アプリケーションから送信要求
した前記電文が受信側アプリケーションに送達されたこ
とを前記ＬＡＮ通信ドライバを介して確認してから前記
送信要求の次の処理に進むとともに、ノード障害または
ネットワーク障害により亡失した前記電文は前記ＬＡＮ
通信ドライバにより再送処理することを特徴とする電文
送受信方法。2. A method of transmitting and receiving a telegram between applications using the TCP / IP protocol, wherein a LAN communication driver is provided between the application and a processing layer below the TCP / IP protocol, and the transmission side application performs the transmission. After confirming via the LAN communication driver that the message requested to be transmitted from the side application is delivered to the receiving application, the process proceeds to the next process of the transmission request, and the message lost due to a node failure or a network failure Is the LAN
A method of transmitting and receiving a message, characterized in that the communication driver performs a retransmission process.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP7331324A JP2848298B2 (en) | 1995-12-20 | 1995-12-20 | Message sending and receiving method and message sending and receiving method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP7331324A JP2848298B2 (en) | 1995-12-20 | 1995-12-20 | Message sending and receiving method and message sending and receiving method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09171495A true JPH09171495A (en) | 1997-06-30 |
| JP2848298B2 JP2848298B2 (en) | 1999-01-20 |
Family
ID=18242416
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP7331324A Expired - Fee Related JP2848298B2 (en) | 1995-12-20 | 1995-12-20 | Message sending and receiving method and message sending and receiving method |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2848298B2 (en) |
-
1995
- 1995-12-20 JP JP7331324A patent/JP2848298B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2848298B2 (en) | 1999-01-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0464014A2 (en) | Communications systems using a fault tolerant protocol | |
| US8738984B2 (en) | Apparatus for processing retransmission failure in radio link control (RLC) layer | |
| KR20060107350A (en) | Method and related apparatus for reconfiguring size of a receiving window in a communications system | |
| JPH073978B2 (en) | Broadcast system | |
| US6097731A (en) | Data retransmission method used in confirmation information transmissions | |
| CN114268991A (en) | Data transmission method and device, electronic equipment and storage medium | |
| JP3537015B2 (en) | Packet communication method | |
| JPWO2008023791A1 (en) | Wireless transmission device, wireless reception device, and wireless communication method | |
| CN112395237A (en) | Method and system for communication between at least two controllers | |
| WO2013123857A1 (en) | File transmission method, instant messaging terminal and system, and computer storage medium | |
| JP3194868B2 (en) | Packet transfer device | |
| JP2848298B2 (en) | Message sending and receiving method and message sending and receiving method | |
| JPH10243050A (en) | Data communication system | |
| JPH1070523A (en) | Method and equipment for packet transmission | |
| JP3428883B2 (en) | Data communication method and data communication device | |
| JP3655610B2 (en) | Method for handling unexpected transmission interruptions in wireless communication systems | |
| KR20110069501A (en) | Apparatus and method for controller area network on the basis of automotive open system architecture | |
| CN111464514A (en) | TCP hot backup method and system | |
| JPH09224017A (en) | Radio packet retransmission control method | |
| CN111417116B (en) | Communication method and system adapted through ATT, read-write and exception handling | |
| JPH0622000A (en) | Message communication system with function preventing the missing of message | |
| JPH11112609A (en) | Communication fault recovery method for communication system and record medium recorded with program for the method | |
| WO2011144094A2 (en) | Method and apparatus for data retransmission | |
| KR100517974B1 (en) | Sequence synchronization method for wireless communication system | |
| JP3219070B2 (en) | Line restoration method |
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 |