JP3645537B2 - 通信制御システム - Google Patents
通信制御システム Download PDFInfo
- Publication number
- JP3645537B2 JP3645537B2 JP2002161342A JP2002161342A JP3645537B2 JP 3645537 B2 JP3645537 B2 JP 3645537B2 JP 2002161342 A JP2002161342 A JP 2002161342A JP 2002161342 A JP2002161342 A JP 2002161342A JP 3645537 B2 JP3645537 B2 JP 3645537B2
- Authority
- JP
- Japan
- Prior art keywords
- communication
- program
- series
- communication device
- control program
- 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
Images
Landscapes
- Communication Control (AREA)
Description
【０００１】
【発明の技術分野】
この発明は通信制御システムに関し、特に通信の連続性の管理に関するものである。
【０００２】
【従来の技術および課題】
銀行業務に用いるデータの転送プロトコルとして、全銀協手順が知られている。この全銀協手順は、データの交換を行う通信装置間において、まず、通信路を形成した後、交互にデータの交換を行うものである。最後に、通信路を切断して終了する。
【０００３】
図１に、全銀協手順の概要を示す。通信を希望する通信装置Ａは、伝送制御手順（ＢＳＣ）のプログラムインターフェイスを使用し、通信装置Ｂに対してダイヤルをして、回線を接続する。次に、通信装置Ａは、開局要求電文を通信装置Ｂに送信する。これを受けて、通信装置Ｂは、開局回答電文を返信して開局要求に応じる。さらに、通信装置Ａは、開始要求電文を通信装置Ｂに送信する。これを受けて、通信装置Ｂは、開始回答電文を返信して開始要求に応じる。
【０００４】
このようにして、通信の準備が整うと、通信装置Ａは、通信内容をテキスト１〜テキストｎとして送信する。これらのテキストの送信を終えると、通信装置Ａは、終了要求電文を通信装置Ｂに送信する。これを受けて、通信装置Ｂは、終了回答電文を返信する。さらに、通信装置Ａは、閉局要求電文を通信装置Ｂに送信する。これを受けて、通信装置Ｂは、閉局回答電文を返信する。その後、通信装置Ａは回線を切断する。以上のようにして、データの送信が行われる。
【０００５】
なお、上記の手順実行中に何らかの障害が発生することがある。たとえば、テキストを所定回数再送しても通信装置Ｂが正しく受信できない等の障害が生じることがある。このような場合には、障害を検知した通信装置Ｂが回線を切断する。通信装置Ａは、回線が切断されたことにより、障害が発生したことを知ることができる。
【０００６】
また、ＴＣＰ／ＩＰにおいて運用できるよう改良された全銀ＴＣＰ／ＩＰ手順や拡張Ｚ手順も用いられている。全銀ＴＣＰ／ＩＰ手順や拡張Ｚ手順では、物理的な回線の切断に代えて、伝送制御手順（ＴＣＰ／ＩＰ）レベルでの切断により、障害の発生を検知するようにしている。具体的には、ＴＣＰ／ＩＰのプログラムインターフェイス（ソケットと呼ぶ）での切断を、全銀協手順における物理的な回線の切断に対応させている。
【０００７】
いずれにしても、これら従来の方式では、物理的な接続や伝送手順レベルでの接続が通信中は永続的に続くという前提に立っている。したがって、かかる接続が中断した場合には、障害が生じたと判断できるのである。
【０００８】
ところで、インターネットの発達により、ＨＴＴＰプロトコルの重要性が高まっており、上記の全銀協手順もＨＴＴＰプロトコルでの運用が望まれている。しかしながら、全銀協手順、全銀ＴＣＰ／ＩＰ手順、拡張Ｚ手順のように物理的な回線の切断、ソケットの切断に基づいて、障害の判断を行う手順を、そのままＨＴＴＰプロトコル上で運用することはできない。ＨＴＴＰプロトコルでは、一連の通信が終了した後も物理的回線としては接続された状態が維持される場合があるからである。したがって、全銀協手順を用いた場合には、物理的回線の接続状態に基づいて、一連の通信の終了や障害の発生を知ることはできない。
【０００９】
また、ソケットの接続状態に基づいて判断を行う全銀ＴＣＰ／ＩＰ手順を用いた場合には、次のような問題を生じる。ＨＴＴＰプロトコルのバージョン1.0においては、１回の通信毎にソケットを切断するように規定されている。つまり、ソケットを接続している間に、１回しか通信文を送ることができず、通信文を複数回送信する場合には、複数回ソケットの接続と切断を繰り返す必要がある。したがって、ＨＴＴＰプロトコルのバージョン1.0上の通信において、仮に、全銀ＴＣＰ／ＩＰ手順そのものを実装した場合、ＨＴＴＰプロトコルでは、正常な通信が続いているにもかかわらず、ソケットを切断することにより、ＴＣＰ／ＩＰコネクションが切断され、全銀ＴＣＰ／ＩＰでは、障害が発生したと判断してしまうことになる。ただし、全銀ＴＣＰ／ＩＰ手順は、ＨＴＴＰプロトコルでは規定されていないため、ＨＴＴＰ上で全銀ＴＣＰ／ＩＰ手順を用いるには、何らかの伝送制御プログラムが必要となる。
【００１０】
なお、ＨＴＴＰプロトコルのバージョン1.1においては、ソケットを接続している間に、複数回にわたって通信文を送信することが可能である。したがって、双方の通信装置がＨＴＴＰプロトコルのバージョン1.1を用いれば、前述の伝送制御プログラムを実装して、全銀ＴＣＰ／ＩＰ手順を用いることも不可能ではない。
【００１１】
しかし、何れか一方の通信装置がバージョン1.0を用いていれば、他方もバージョン1.0に合わせて通信を行わねばならない。したがって、このような場合には、全銀ＴＣＰ／ＩＰ手順を用いることはできない。
【００１２】
また、双方が、ＨＴＴＰプロトコルのバージョン1.1を用いていても、プロキシを介して通信する場合には、互いの通信装置がソケットによって直接接続されないことになる。したがって、一方の通信装置がソケットの切断を行っても、それを、他方の通信装置が知ることができない。よって、双方の通信装置がＨＴＴＰプロトコルのバージョン1.1を用いる場合であっても、プロキシを経由する場合等を考慮すると、全銀ＴＣＰ／ＩＰ手順を適用することはできない。
【００１３】
この発明は上記のような問題点を解決して、全銀協手順、全銀ＴＣＰ／ＩＰ手順、拡張Ｚ手順などのように一連の通信データのやりとり中において接続の永続性があることを前提とした手順を、ＨＴＴＰプロトコルなどのように一連の通信データのやりとり中にコネクションの切断が起こりうるようなプロトコル上において運用可能とするシステムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
(1)(2)(3)この発明の通信制御システムは、第１の通信装置と、通信路を介して第１の通信装置に接続された第２の通信装置とを備えた通信制御システムであって、
前記第１および第２の通信装置は、一連の通信データのやりとり中に、通信路のコネクションが切断されたことにより障害発生を判断する処理プログラムを備え、
さらに、前記第１および第２の通信装置は、前記一連の通信データのやりとり中に前記コネクションの切断が生じうる通信プロトコルを使用するものであり、
前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定する処理を行う制御プログラムを、第１および第２の通信装置に設けたことを特徴としている。
【００１５】
したがって、ＨＴＴＰプロトコルのようにコネクションの切断が起こりうるプロトコルであっても、セッション識別子により、あたかも接続の永続性が維持されているかのように処理することができる。すなわち、一連の通信データのやりとり中において接続の永続性が保持され続けることを前提とした手順を、ＨＴＴＰプロトコルのように一連の通信データのやりとり中にコネクションの切断が起こりうるようなプロトコル上においても支障なく運用することができる。
【００１６】
(4)この発明の通信制御システムは、制御プログラムが、接続の永続性を切断する旨の永続性切断通知を相手方の通信装置に対して送信することを特徴としている。
【００１７】
したがって、相手方の通信装置に対して、接続の永続性が失われたことを通知することができ、接続の永続性に基づいて処理を行う従来手順の処理プログラムを用いることが可能となる。
【００１８】
(5)この発明の通信制御システムは、制御プログラムが、正常に通信が終了した場合に永続性切断通知を送信することを特徴としている。
【００１９】
したがって、相手方の通信装置に対して、通信の正常終了による接続の永続性の喪失を通知することができ、接続の永続性に基づいて通信の終了処理を行う従来手順の処理プログラムを用いることが可能となる。
【００２０】
(6)この発明の通信制御システムは、制御プログラムが、障害が発生した場合に前記永続性切断通知を送信することを特徴としている。
【００２１】
したがって、相手方の通信装置に対して、障害発生による接続の永続性の喪失を通知することができ、接続の永続性に基づいて障害処理を行う従来手順の処理プログラムを用いることが可能となる。
【００２２】
(7)この発明の通信制御システムは、制御プログラムが、相手方からの永続性切断通知を受けると、前記処理プログラムに対してコネクションの切断があった旨の通知を行うことを特徴とするもの。
【００２３】
したがって、コネクションの切断に基づいて処理を行う従来手順の処理プログラムを用いることが可能となる。
【００２４】
(8)この発明の通信制御システムは、制御プログラムが、相手方の通信装置に対して通信データを送信してから、相手方の通信装置から通信データが送信されてくるまでの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴としている。
【００２５】
したがって、相手方が通信データを送信したにもかかわらず、何らかの要因によって通信データが届かないような場合においても、障害を検出することができる。
【００２６】
(9)この発明の通信制御システムは、制御プログラムが、一連の通信データのやりとりの開始から、終了までの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴としている。
【００２７】
したがって、やりとりの開始から終了までの間に、何らかの要因にてやりとりが停止し、双方の通信装置においてこのやりとりの停止を直接検出できないような場合においても、障害の発生を知ることができる。
【００２８】
(10)この発明の通信制御システムは、制御プログラムが、一連の通信データのやりとりの開始を通信装置から要求された際に、当該要求に応えられない状況の場合には、当該通信装置に対して他の通信装置の接続先を返答することを特徴としている。
【００２９】
したがって、通信を拒否された通信装置は、直ちに他の通信装置に対して通信開始の要求を行うことができる。
【００３０】
(11)この発明の通信制御システムは、プロトコルが、ＨＴＴＰプロトコルであることを特徴としている。
【００３１】
したがって、ＨＴＴＰプロトコル上において、一連の通信データのやりとりの終了を、通信の永続性の切断により判断するような手順を運用することができる。
【００３２】
(12)この発明の通信制御システムは、制御プログラムが、ＨＴＴＰヘッダ部分に、永続性切断通知を記述して相手方通信装置に送信することを特徴としている。
【００３３】
したがって、ＨＴＴＰプロトコル上において、永続性切断通知を送信することができる。
【００３４】
(13)この発明の通信制御システムは、セッション識別子が、ＰＯＳＴメソッドのＨＴＴＰ拡張ヘッダを用いて実現されることを特徴としている。
【００３５】
したがって、ＨＴＴＰプロトコル上において、容易にセッションの連続性を識別することができる。
【００３６】
(14)この発明の通信制御方法は、一連の通信データのやりとり中に、コネクションが切断されたことにより障害発生を判断するプログラムを用いつつ、前記一連の通信データのやりとり中に前記コネクションの切断が生じうるプロトコルを使用して、前記一連の通信データのやりとりを行う通信制御方法であって、
前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定することを特徴としている。
【００３７】
したがって、ＨＴＴＰプロトコルのようにコネクションの切断が起こりうるプロトコルであっても、セッション識別子により、あたかも接続の永続性が維持されているかのように処理することができる。すなわち、一連の通信データのやりとり中において接続の永続性が保持され続けることを前提とした手順を、ＨＴＴＰプロトコルのように一連の通信データのやりとり中にコネクションの切断が起こりうるようなプロトコル上においても支障なく運用することができる。
【００３８】
この発明において、「接続の永続性の切断」とは、継続的に接続されている状態を切断することをいい、継続的に接続されている通信路の物理的な切断だけでなく、継続的に接続されているソケットの切断等も含む概念である。
【００３９】
「コネクションの切断」とは、通信路の物理的な切断だけでなく、ソケットの切断等も含む概念である。
【００４０】
「プログラムを記録した記録媒体」とは、プログラムを記録したＲＯＭ、ＲＡＭ、フレキシブルディスク、ＣＤ−ＲＯＭ、メモリカード、ハードディスク等の記録媒体をいう。また、電話回線、搬送路等の通信媒体も含む概念である。ＣＰＵに接続されて、記録されたプログラムが直接実行されるハードディスクのような記録媒体だけでなく、一旦ハードディスク等にインストールした後に実行されるプログラムを記録したＣＤ−ＲＯＭ等の記録媒体を含む概念である。
【００４１】
「プログラム」とは、ＣＰＵにより直接実行可能なプログラムだけでなく、ソース形式のプログラム、圧縮処理がされたプログラム、暗号化されたプログラム等を含む概念である。
【００４２】
【発明の実施の形態】
図２に、この発明の一実施形態による通信制御システムの概念図を示す。通信装置２は、アプリケーションプログラム２２と制御プログラム２４を備えている。また、通信装置４は、アプリケーションプログラム４２と制御プログラム４４を備えている。両通信装置２、４は、インターネット６を介して接続されている。
【００４３】
アプリケーションプログラム２２は、制御プログラム２４に指令を与えて、アプリケーションプログラム４２との間で通信データのやりとりを行う。同様に、アプリケーションプログラム４２は、制御プログラム４４に指令を与えて、アプリケーションプログラム２２との間で通信データのやりとりを行う。
【００４４】
制御プログラム２４、４４は、ＨＴＴＰプロトコルを用いて通信を行う。制御プログラム２４、４４は、１回のＨＴＴＰリクエスト／レスポンス毎にソケットを切断する。制御プログラム２４、４４は、セッション識別子を用いて通信データを交換することにより、ソケットの切断によって切り離された各回の通信を関連づけ、一連の通信を特定するようにしている。
【００４５】
上記のように、制御プログラム２４、４４は、１回のＨＴＴＰリクエスト／レスポンス毎にコネクションを切断するにもかかわらず、アプリケーションプログラム２２、４２は、一連の通信データの送受信中には、接続の永続性が維持され続けるものとして処理を実行する。したがって、制御プログラム２４は、一連の通信が終了すると、アプリケーション２２に対してコネクションが切断された旨を通知する（永続性切断通知）。また、何らかの障害が発生し、通信の続行ができなくなった場合にも、制御プログラム２４は、アプリケーション２２に対して永続性切断通知を送信する。制御プログラム４４も同様の処理を行う。
【００４６】
図３に、上記一実施形態による通信データの伝送手順を概念的に示す。送信側のアプリケーションプログラム２２は、ファイル名等を指定してファイル伝送指令３０を生成する。送信側の制御プログラムの全銀協対応部分は、このファイル伝送指令に基づいて全銀協手順電文３２を生成する。さらに、送信側のＨＴＴＰ対応部分は、この全銀協手順電文３２に基づいて、ＨＴＴＰメッセージ３４を生成する。このようにして生成されたＨＴＴＰメッセージ３４は、インターネットを介して、受信側に送られる。
【００４７】
受信側の制御プログラムのＨＴＴＰ対応部分は、ＨＴＴＰメッセージ３４を受けて、これを解釈する。これとともに、全銀協手順電文３２を復元する。受信側の制御プログラムの全銀協対応部分は、全銀協手順電文３２を解釈して、通信の制御や全銀協手順電文の受信側アプリケーションへの引き渡しを行う。受信側のアプリケーションは、制御プログラムからの報告を受けて、上位処理を行う。
【００４８】
なお、受信側は、受信後に確認等を返信する必要があるので、送信側と受信側は交互に入れ替わることになる。また、１つのファイル伝送指令に対して、複数の電文が作成されるので、上記の処理は、複数回繰り返されることになる。
【００４９】
図４に、上記実施形態において用いた通信装置２のハードウエア構成を示す。通信装置２は、ＣＰＵ５２、メモリ５４、ディスプレイ５６、ハードディスク５８、ＣＤ−ＲＯＭドライブ６０、通信部６４、キーボード／マウス６６を備えている。ハードディスク５８には、オペレーティングシステム７０（マイクロソフト社のウインドウズ（商標）など）が記録されている。また、制御プログラム７２、アプリケーションプログラム７４も記録されている。さらに、通信可能な相手先のＵＲＬなどを定義した事前定義情報、送信対象となる様々なファイル７８が記録されている。ＣＰＵ５２は、制御プログラム等にしたがって処理を行うものである。
【００５０】
制御プログラム７２、アプリケーションプログラム７４は、オペレーティングシステム７０と協働して処理を行うものである。また、これらは、ＣＤ−ＲＯＭドライブ６０を介して、ＣＤ−ＲＯＭ６２からインストールされたものである。
【００５１】
通信部６４は、インターネットとの通信を行うための回路部であり、いわゆる、通信ボードと呼ばれているものである。
【００５２】
なお、図示しないが、通信装置４も上記通信装置２と同等の構成を有している。
【００５３】
図５、図６に、この実施形態による通信制御システムにおける通信データのやりとりを示す。この図においては、通信装置２が通信装置４に対してファイル７８を伝送する場合を説明している。この実施形態では、伝送を希望する通信装置２がクライエントになり、伝送を受ける通信装置４がサーバとなるようにしている。
【００５４】
まず、通信装置２のアプリケーションプログラム７４は、ファイル名、相手側通信装置名等を指定して転送指示を行う（図５の▲１▼）。これを受けて、制御プログラム７２は、事前定義情報７６を参照して、相手側通信装置のＵＲＬを取得する。事前定義情報７６には、通信装置名とＵＲＬが対応づけて記録されている。制御プログラム７２は、取得したＵＲＬに基づいて、相手側通信装置４とのソケットを接続する（図５の▲２▼▲２▼'）。これにより、コネクションが確立される。
【００５５】
続いて、通信装置２の制御プログラム７２は、全銀協手順に基づく開局要求電文を、ＨＴＴＰメッセージとして送信する（図５の▲３▼）。通信装置４の制御プログラム７２は、このＨＴＴＰメッセージから、開局要求電文を復元し、アプリケーション７４に渡す。アプリケーション７４は、通信装置４の事前定義情報７６を参照して、開局要求電文中に記載された相手方通信装置が、送受信の権限を有しているか否かを判断する。
【００５６】
権限を有していれば、アプリケーション７４は、開局回答電文を返信するように制御プログラム７２に指令を行う。これを受けて、通信装置４の制御プログラム７２は、開局回答電文を送信装置２に送信する。通信装置２の制御プログラムは、この開局回答電文を受信する（図５の▲４▼）。
【００５７】
次に、通信装置２の制御プログラム７２は送信対象であるファイルのファイル名などを含む開始要求電文を送信し（図５の▲５▼）、これを受けた通信装置４の制御プログラム７２は開始回答電文を返信する。
【００５８】
以上のようにしてファイル送信の準備が整うと、通信装置２の制御プログラム７２は、ファイル７８を分割した１または複数のレコードをまとめたテキストを、ＨＴＴＰメッセージとして送信する（図５の▲６▼）。このＨＴＴＰメッセージを受信した通信装置４の制御プログラムは、テキストからレコードを復元して、アプリケーション７４に渡す。アプリケーション７４は、開始要求電文に記述されていたファイル名を付して、このレコードを記録する。また、通信装置４の制御プログラム７２は、全銀協手順に従ってレコードを受信した旨を示す電文を、ＨＴＴＰメッセージとして返信する。
【００５９】
このようにして、１つのレコードの送信が完了すると、通信装置２の制御プログラム７２は、次のレコードを送信する。同様に、通信装置４の制御プログラム７２は、返信を行う。
【００６０】
上記の処理を繰り返して全てのレコードを送信し終えると、通信装置２の制御プログラム７２は、全銀協手順に従う終了要求電文を、ＨＴＴＰメッセージとして送信する（図５の▲７▼）。これに対して、通信装置４の制御プログラム７２は、全銀協手順に従う終了回答電文を、ＨＴＴＰメッセージとして返信する（図５の▲８▼）。
【００６１】
さらに、通信装置２の制御プログラム７２は、全銀協手順に従う閉局要求電文を、ＨＴＴＰメッセージとして送信する（図５の▲９▼）。これに対して、通信装置４の制御プログラム７２は、全銀協手順に従う閉局回答電文を、ＨＴＴＰメッセージとして返信する（図５の10）。この際、通信装置４の制御プログラム７２は、ＨＴＴＰヘッダ中に、永続性切断通知を埋め込んで送信する。
【００６２】
また、永続性切断通知をヘッダに含む閉局回答電文を受けた通信装置２の制御プログラム７２は、ソケットを切断する（図５の11）。さらに、通信装置２の制御プログラム７２は、通信装置２のアプリケーションに対して、コネクションが切断された旨を伝える。これにより、通信装置２のアプリケーション７４は、一連のやりとりが終了したことを知ることができる。
【００６３】
なお、クライエント側となった通信装置２においては、送信に用いたポートに対するソケットのＴＣＰセッション（ファイルディスクリプタ）に対してサーバ側の通信装置４から返答が送られてくる。したがって、そのファイルディスクリプタを保持しておくことにより、たとえ、複数のサーバに対して通信を行っていたとしても、それぞれの通信を区別することができる。
【００６４】
また、サーバ側となった通信装置４においては、返信時にセッションＩＤをＨＴＴＰヘッダに記述して送信し、クライエント側の通信装置２は、次回に送信を行う際にはこのセッションＩＤを付すようにしている。これにより、通信装置４は、たとえ、複数のクライエントに対して通信を行っていたとしても、ぞれの通信を区別することが可能である。
【００６５】
図５、図６においては、このセッションＩＤについての処理の詳細を示していない。また、図５、図６においては、障害を発見するためのタイマ処理の詳細も示していない。図７、図８に、これらセッションＩＤとタイマに関する処理を含む制御プログラムのフローチャートを示す。
【００６６】
まず、クライエントである通信装置２の制御プログラム７２（以下クライエント）は、サーバである通信装置４の制御プログラム７２（以下サーバ）に対し、ＨＴＴＰプロトコルにおけるソケットの接続を要求する（ステップＳ１）。サーバは、要求に応じてソケットの接続を行う（ステップＳ５１）。
【００６７】
次に、クライエントは、開局要求メッセージを送信する（ステップＳ２）。この実施形態では、開局要求メッセージは、図１１に示すように、ＰＯＳＴメソッドを用いて行われる。すなわち、ヘッダ部分２０１にＰＯＳＴメソッドによる記述を行い、本文部分２０２に開局要求電文を記述している。
【００６８】
サーバは、この開局要求メッセージを受信する（ステップＳ５２）。これにより、サーバは一連の通信が開始したことを認識し、この一連の通信を特定するためのセッションＩＤを決定する。サーバは、決定したセッションＩＤを、相手先通信装置２を特定する情報、ファイル名等と関連づけて、メモリ５４に記憶する。次に、サーバは、開局回答メッセージを返信する（ステップＳ５５）。この際、決定したセッションＩＤをヘッダ中に記述する（ステップＳ５４）。サーバから返送される開局回答メッセージを図１１に示す。ヘッダ部分３０１の拡張ＨＴＴＰヘッダ（図中では、X-ZGH-Session）の項目に、セッションＩＤとして、234f4f13aa7525が記述されている。開局回答電文は、本文部分３０２に記述されている。
【００６９】
クライエントは、この開局回答メッセージを受信する（ステップＳ８）。さらに、クライエントは、受信した開局回答メッセージから、セッションＩＤを取り出してメモリ５４に記憶する（ステップＳ９）。続いて、クライエントは、開始要求メッセージを送信する（ステップＳ１１）。この際、記憶しておいたセッションＩＤをヘッダ中に記述する（ステップＳ１０）。図１１に、開始要求メッセージを示す。ヘッダ部分２０３の拡張ＨＴＴＰヘッダ（図中ではX-ZGH-Session）の項目に、セッションＩＤとして、234f4f13aa7525が記述されている。開始要求電文は、本文部分２０４に記述されている。
【００７０】
サーバは、この開始要求メッセージを受信する（ステップＳ６０）。さらに、サーバは、受信した開始要求メッセージから、セッションＩＤを取り出す（ステップＳ６１）。サーバは、このセッションＩＤに基づいて、いずれのクライエントとの通信であるかを特定する。したがって、複数のクライエントとのやりとりを同時に行っていても、相手方クライエントを特定することができる。
【００７１】
サーバは、同じセッションＩＤをヘッダに付して（ステップＳ６２）、開始回答メッセージを返信する。したがって、一連の通信をセッションＩＤによって特定することが可能となる。
【００７２】
以下、レコードの送信においても同様の処理が行われる。
【００７３】
一連の通信を終了する際には、終了要求−終了回答、閉局要求−閉局回答の各メッセージがやりとりされる。これらメッセージのやりとりは、上記と同じようにして、セッションＩＤが付されて行われる（図８参照）。
【００７４】
ただし、閉局する場合には、ソケットの切断を行う必要がある。この実施形態では、図８のステップＳ７５、図１１の３０５に示すように、閉局回答メッセージのヘッダ中の拡張ＨＴＴＰヘッダ（図中ではX-ZGH-Session）の項目に、永続性切断通知としてcloseを記述している。これを受けたクライエントは、ソケットを切断する。このように、サーバの側から永続性切断通知を行って、これを受けたクライエントが切断処理を行うことにより、クライエントとサーバの双方がコネクションの切断を認識することができる。
【００７５】
なお、サーバは、永続性切断通知を行った後、当該通信に対して付していたセッションＩＤをメモリ５４から削除する。また、このセッションＩＤに関連して記憶していた相手先通信装置２を特定する情報、ファイル名等も削除する（ステップＳ７６）。さらに、アプリケーション７４に対して、コネクションが切断された旨を通知する。
【００７６】
一方、永続性切断通知を受けたクライエントの制御プログラムは、アプリケーション７４に対して、コネクションが切断された旨を通知する。以上のようにして、ＨＴＴＰプロトコルを用いて、全銀協手順における一連の通信を処理することができる。
【００７７】
また、この実施形態では、一連の通信の途中における障害についても、処理できるようにしている。従来の全銀協手順では、障害発生時に、接続を物理的に切断すれば相手方もこれを認識することができた。しかし、ＨＴＴＰプロトコルでは、そのような認識を行うことができない。この実施形態では、以下のようにして、障害の検出と相手方への通知を実現している。
【００７８】
図７のステップＳ２においてメッセージを送信した後、タイマーをリセットしている。このタイマーは、障害検出のためのタイマーである。このタイマーが所定時間経過するまでに、相手方からのメッセージ（ステップＳ８参照）が送信されてこなければ、障害が発生したものと判断する。
【００７９】
図９に、タイムアウト処理のフローチャートを示す。タイムアウト（タイマーが所定時間経過）になっても相手方からの通信がない場合には、拡張ＨＴＴＰヘッダにセッションＩＤおよび永続性切断通知を記述（図中では、X-ZGH-SessionにセッションＩＤ、X-ZGH-Connectionにcloseを記述）して、切断メッセージを送信する（ステップＳ５０５、Ｓ５０６、Ｓ５０７）。
【００８０】
この切断メッセージを受けた相手側通信装置は、このあとのエラー関連処理に使用するため、ＨＴＴＰ拡張ヘッダからセッションＩＤを取り出し（ステップＳ５０４）、その後、ソケットを切断する。
【００８１】
自分がサーバ側である場合には、セッションＩＤ等をメモリから削除する（ステップＳ５１０）。その後、アプリケーション７４へのコネクション切断の通知などエラー関連処理を行う（ステップＳ５１１）。
【００８２】
また、レコードを記録するための容量不足や通信異常などの障害が発生した場合の処理を、図１０にフローチャートで示す。まず、障害の発生を検知すると（ステップＳ６００）、セッションＩＤ、永続性切断通知をヘッダに記述して（ステップＳ６０１、Ｓ６０２）、切断メッセージを送信する（ステップＳ６０４）。図１２に、切断メッセージのヘッダ部分４５１を示す。
【００８３】
なお、当該通信装置がサーバ側である場合には（ステップＳ６０９）、セッションＩＤ等をメモリ５４から削除する処理を行う（ステップＳ６１０）。その後、アプリケーション７４へのコネクション切断の通知などのエラー関連処理を行う（ステップＳ６１１）。
【００８４】
なお、この実施形態では、ＨＴＴＰプロトコルを使用しているため、ＨＴＴＰプロトコル特有の障害も生じうる。したがって、これら特有の障害（たとえば、相手先ＵＲＬの誤り等）が発生した場合も、上記に示す処理によって、コネクションの切断を行うようにしている。
【００８５】
また、サーバ側の通信装置が開局要求電文を受信した際に、接続セッション数オーバなどの原因で、当該要求に応えられない場合がある。この場合に、サーバ側の通信装置の制御プログラムは、開局要求電文を送ってきたクライエント側の通信装置に対して、開局に応えられない旨の電文を返信する。この電文返信の際、代替通信先の通信装置のＵＲＬをＨＴＴＰヘッダに埋め込んで送信するようにしてもよい。これを受けたクライエント側の通信装置は、容易に代替可能な他の通信装置に対して開局要求を行うことができる。
【００８６】
この際、クライエント側の制御プログラムは、サーバが開局に応えられない旨を直ちに処理プログラムに知らせず、代替可能な他のサーバから開局に応えられる旨を受信した後、これを処理プログラムに知らせる。また、制御プログラムは、代替可能な他のサーバが全て開局に応えられない場合には、その旨を処理プログラムに知らせる。
【００８７】
なお、上記実施形態では、ＰＯＳＴメソッドのＨＴＴＰ拡張ヘッダにセッションＩＤを記述するようにしている。しかし、Cookieの項目にセッションＩＤを記述するようにしてもよい。
【００８８】
また、上記実施形態では、全銀協手順をＨＴＴＰプロトコル上で実現した場合について説明している。しかし、全銀協手順だけでなく、通信時にのみ接続を行い、通信中は接続を維持するような手順一般に適用することができる。また、ＨＴＴＰプロトコルだけでなく、１回の通信毎にコネクションを切断するようなプロトコル一般に適用することができる。
【図面の簡単な説明】
【図１】全銀協手順を示す図である。
【図２】この発明の一実施形態による通信制御システムの概要を示す図である。
【図３】この発明の一実施形態による通信の処理概要とデータとを示す図である。
【図４】通信装置のハードウエア構成を示す図である。
【図５】アプリケーションプログラムと制御プログラムの処理内容を示す図である。
【図６】アプリケーションプログラムと制御プログラムの処理内容を示す図である。
【図７】制御プログラムのフローチャートを示す図である。
【図８】制御プログラムのフローチャートを示す図である。
【図９】タイムアウトおよび切断メッセージ受信の際の処理フローチャートを示す図である。
【図１０】障害発生の際の処理フローチャートを示す図である。
【図１１】メッセージのやりとりを示す図である。
【図１２】障害発生時のメッセージのやりとりを示す図である。
【符号の説明】
２・・・通信装置
４・・・通信装置
２２・・・アプリケーション
２４・・・制御プログラム
【発明の技術分野】
この発明は通信制御システムに関し、特に通信の連続性の管理に関するものである。
【０００２】
【従来の技術および課題】
銀行業務に用いるデータの転送プロトコルとして、全銀協手順が知られている。この全銀協手順は、データの交換を行う通信装置間において、まず、通信路を形成した後、交互にデータの交換を行うものである。最後に、通信路を切断して終了する。
【０００３】
図１に、全銀協手順の概要を示す。通信を希望する通信装置Ａは、伝送制御手順（ＢＳＣ）のプログラムインターフェイスを使用し、通信装置Ｂに対してダイヤルをして、回線を接続する。次に、通信装置Ａは、開局要求電文を通信装置Ｂに送信する。これを受けて、通信装置Ｂは、開局回答電文を返信して開局要求に応じる。さらに、通信装置Ａは、開始要求電文を通信装置Ｂに送信する。これを受けて、通信装置Ｂは、開始回答電文を返信して開始要求に応じる。
【０００４】
このようにして、通信の準備が整うと、通信装置Ａは、通信内容をテキスト１〜テキストｎとして送信する。これらのテキストの送信を終えると、通信装置Ａは、終了要求電文を通信装置Ｂに送信する。これを受けて、通信装置Ｂは、終了回答電文を返信する。さらに、通信装置Ａは、閉局要求電文を通信装置Ｂに送信する。これを受けて、通信装置Ｂは、閉局回答電文を返信する。その後、通信装置Ａは回線を切断する。以上のようにして、データの送信が行われる。
【０００５】
なお、上記の手順実行中に何らかの障害が発生することがある。たとえば、テキストを所定回数再送しても通信装置Ｂが正しく受信できない等の障害が生じることがある。このような場合には、障害を検知した通信装置Ｂが回線を切断する。通信装置Ａは、回線が切断されたことにより、障害が発生したことを知ることができる。
【０００６】
また、ＴＣＰ／ＩＰにおいて運用できるよう改良された全銀ＴＣＰ／ＩＰ手順や拡張Ｚ手順も用いられている。全銀ＴＣＰ／ＩＰ手順や拡張Ｚ手順では、物理的な回線の切断に代えて、伝送制御手順（ＴＣＰ／ＩＰ）レベルでの切断により、障害の発生を検知するようにしている。具体的には、ＴＣＰ／ＩＰのプログラムインターフェイス（ソケットと呼ぶ）での切断を、全銀協手順における物理的な回線の切断に対応させている。
【０００７】
いずれにしても、これら従来の方式では、物理的な接続や伝送手順レベルでの接続が通信中は永続的に続くという前提に立っている。したがって、かかる接続が中断した場合には、障害が生じたと判断できるのである。
【０００８】
ところで、インターネットの発達により、ＨＴＴＰプロトコルの重要性が高まっており、上記の全銀協手順もＨＴＴＰプロトコルでの運用が望まれている。しかしながら、全銀協手順、全銀ＴＣＰ／ＩＰ手順、拡張Ｚ手順のように物理的な回線の切断、ソケットの切断に基づいて、障害の判断を行う手順を、そのままＨＴＴＰプロトコル上で運用することはできない。ＨＴＴＰプロトコルでは、一連の通信が終了した後も物理的回線としては接続された状態が維持される場合があるからである。したがって、全銀協手順を用いた場合には、物理的回線の接続状態に基づいて、一連の通信の終了や障害の発生を知ることはできない。
【０００９】
また、ソケットの接続状態に基づいて判断を行う全銀ＴＣＰ／ＩＰ手順を用いた場合には、次のような問題を生じる。ＨＴＴＰプロトコルのバージョン1.0においては、１回の通信毎にソケットを切断するように規定されている。つまり、ソケットを接続している間に、１回しか通信文を送ることができず、通信文を複数回送信する場合には、複数回ソケットの接続と切断を繰り返す必要がある。したがって、ＨＴＴＰプロトコルのバージョン1.0上の通信において、仮に、全銀ＴＣＰ／ＩＰ手順そのものを実装した場合、ＨＴＴＰプロトコルでは、正常な通信が続いているにもかかわらず、ソケットを切断することにより、ＴＣＰ／ＩＰコネクションが切断され、全銀ＴＣＰ／ＩＰでは、障害が発生したと判断してしまうことになる。ただし、全銀ＴＣＰ／ＩＰ手順は、ＨＴＴＰプロトコルでは規定されていないため、ＨＴＴＰ上で全銀ＴＣＰ／ＩＰ手順を用いるには、何らかの伝送制御プログラムが必要となる。
【００１０】
なお、ＨＴＴＰプロトコルのバージョン1.1においては、ソケットを接続している間に、複数回にわたって通信文を送信することが可能である。したがって、双方の通信装置がＨＴＴＰプロトコルのバージョン1.1を用いれば、前述の伝送制御プログラムを実装して、全銀ＴＣＰ／ＩＰ手順を用いることも不可能ではない。
【００１１】
しかし、何れか一方の通信装置がバージョン1.0を用いていれば、他方もバージョン1.0に合わせて通信を行わねばならない。したがって、このような場合には、全銀ＴＣＰ／ＩＰ手順を用いることはできない。
【００１２】
また、双方が、ＨＴＴＰプロトコルのバージョン1.1を用いていても、プロキシを介して通信する場合には、互いの通信装置がソケットによって直接接続されないことになる。したがって、一方の通信装置がソケットの切断を行っても、それを、他方の通信装置が知ることができない。よって、双方の通信装置がＨＴＴＰプロトコルのバージョン1.1を用いる場合であっても、プロキシを経由する場合等を考慮すると、全銀ＴＣＰ／ＩＰ手順を適用することはできない。
【００１３】
この発明は上記のような問題点を解決して、全銀協手順、全銀ＴＣＰ／ＩＰ手順、拡張Ｚ手順などのように一連の通信データのやりとり中において接続の永続性があることを前提とした手順を、ＨＴＴＰプロトコルなどのように一連の通信データのやりとり中にコネクションの切断が起こりうるようなプロトコル上において運用可能とするシステムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
(1)(2)(3)この発明の通信制御システムは、第１の通信装置と、通信路を介して第１の通信装置に接続された第２の通信装置とを備えた通信制御システムであって、
前記第１および第２の通信装置は、一連の通信データのやりとり中に、通信路のコネクションが切断されたことにより障害発生を判断する処理プログラムを備え、
さらに、前記第１および第２の通信装置は、前記一連の通信データのやりとり中に前記コネクションの切断が生じうる通信プロトコルを使用するものであり、
前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定する処理を行う制御プログラムを、第１および第２の通信装置に設けたことを特徴としている。
【００１５】
したがって、ＨＴＴＰプロトコルのようにコネクションの切断が起こりうるプロトコルであっても、セッション識別子により、あたかも接続の永続性が維持されているかのように処理することができる。すなわち、一連の通信データのやりとり中において接続の永続性が保持され続けることを前提とした手順を、ＨＴＴＰプロトコルのように一連の通信データのやりとり中にコネクションの切断が起こりうるようなプロトコル上においても支障なく運用することができる。
【００１６】
(4)この発明の通信制御システムは、制御プログラムが、接続の永続性を切断する旨の永続性切断通知を相手方の通信装置に対して送信することを特徴としている。
【００１７】
したがって、相手方の通信装置に対して、接続の永続性が失われたことを通知することができ、接続の永続性に基づいて処理を行う従来手順の処理プログラムを用いることが可能となる。
【００１８】
(5)この発明の通信制御システムは、制御プログラムが、正常に通信が終了した場合に永続性切断通知を送信することを特徴としている。
【００１９】
したがって、相手方の通信装置に対して、通信の正常終了による接続の永続性の喪失を通知することができ、接続の永続性に基づいて通信の終了処理を行う従来手順の処理プログラムを用いることが可能となる。
【００２０】
(6)この発明の通信制御システムは、制御プログラムが、障害が発生した場合に前記永続性切断通知を送信することを特徴としている。
【００２１】
したがって、相手方の通信装置に対して、障害発生による接続の永続性の喪失を通知することができ、接続の永続性に基づいて障害処理を行う従来手順の処理プログラムを用いることが可能となる。
【００２２】
(7)この発明の通信制御システムは、制御プログラムが、相手方からの永続性切断通知を受けると、前記処理プログラムに対してコネクションの切断があった旨の通知を行うことを特徴とするもの。
【００２３】
したがって、コネクションの切断に基づいて処理を行う従来手順の処理プログラムを用いることが可能となる。
【００２４】
(8)この発明の通信制御システムは、制御プログラムが、相手方の通信装置に対して通信データを送信してから、相手方の通信装置から通信データが送信されてくるまでの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴としている。
【００２５】
したがって、相手方が通信データを送信したにもかかわらず、何らかの要因によって通信データが届かないような場合においても、障害を検出することができる。
【００２６】
(9)この発明の通信制御システムは、制御プログラムが、一連の通信データのやりとりの開始から、終了までの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴としている。
【００２７】
したがって、やりとりの開始から終了までの間に、何らかの要因にてやりとりが停止し、双方の通信装置においてこのやりとりの停止を直接検出できないような場合においても、障害の発生を知ることができる。
【００２８】
(10)この発明の通信制御システムは、制御プログラムが、一連の通信データのやりとりの開始を通信装置から要求された際に、当該要求に応えられない状況の場合には、当該通信装置に対して他の通信装置の接続先を返答することを特徴としている。
【００２９】
したがって、通信を拒否された通信装置は、直ちに他の通信装置に対して通信開始の要求を行うことができる。
【００３０】
(11)この発明の通信制御システムは、プロトコルが、ＨＴＴＰプロトコルであることを特徴としている。
【００３１】
したがって、ＨＴＴＰプロトコル上において、一連の通信データのやりとりの終了を、通信の永続性の切断により判断するような手順を運用することができる。
【００３２】
(12)この発明の通信制御システムは、制御プログラムが、ＨＴＴＰヘッダ部分に、永続性切断通知を記述して相手方通信装置に送信することを特徴としている。
【００３３】
したがって、ＨＴＴＰプロトコル上において、永続性切断通知を送信することができる。
【００３４】
(13)この発明の通信制御システムは、セッション識別子が、ＰＯＳＴメソッドのＨＴＴＰ拡張ヘッダを用いて実現されることを特徴としている。
【００３５】
したがって、ＨＴＴＰプロトコル上において、容易にセッションの連続性を識別することができる。
【００３６】
(14)この発明の通信制御方法は、一連の通信データのやりとり中に、コネクションが切断されたことにより障害発生を判断するプログラムを用いつつ、前記一連の通信データのやりとり中に前記コネクションの切断が生じうるプロトコルを使用して、前記一連の通信データのやりとりを行う通信制御方法であって、
前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定することを特徴としている。
【００３７】
したがって、ＨＴＴＰプロトコルのようにコネクションの切断が起こりうるプロトコルであっても、セッション識別子により、あたかも接続の永続性が維持されているかのように処理することができる。すなわち、一連の通信データのやりとり中において接続の永続性が保持され続けることを前提とした手順を、ＨＴＴＰプロトコルのように一連の通信データのやりとり中にコネクションの切断が起こりうるようなプロトコル上においても支障なく運用することができる。
【００３８】
この発明において、「接続の永続性の切断」とは、継続的に接続されている状態を切断することをいい、継続的に接続されている通信路の物理的な切断だけでなく、継続的に接続されているソケットの切断等も含む概念である。
【００３９】
「コネクションの切断」とは、通信路の物理的な切断だけでなく、ソケットの切断等も含む概念である。
【００４０】
「プログラムを記録した記録媒体」とは、プログラムを記録したＲＯＭ、ＲＡＭ、フレキシブルディスク、ＣＤ−ＲＯＭ、メモリカード、ハードディスク等の記録媒体をいう。また、電話回線、搬送路等の通信媒体も含む概念である。ＣＰＵに接続されて、記録されたプログラムが直接実行されるハードディスクのような記録媒体だけでなく、一旦ハードディスク等にインストールした後に実行されるプログラムを記録したＣＤ−ＲＯＭ等の記録媒体を含む概念である。
【００４１】
「プログラム」とは、ＣＰＵにより直接実行可能なプログラムだけでなく、ソース形式のプログラム、圧縮処理がされたプログラム、暗号化されたプログラム等を含む概念である。
【００４２】
【発明の実施の形態】
図２に、この発明の一実施形態による通信制御システムの概念図を示す。通信装置２は、アプリケーションプログラム２２と制御プログラム２４を備えている。また、通信装置４は、アプリケーションプログラム４２と制御プログラム４４を備えている。両通信装置２、４は、インターネット６を介して接続されている。
【００４３】
アプリケーションプログラム２２は、制御プログラム２４に指令を与えて、アプリケーションプログラム４２との間で通信データのやりとりを行う。同様に、アプリケーションプログラム４２は、制御プログラム４４に指令を与えて、アプリケーションプログラム２２との間で通信データのやりとりを行う。
【００４４】
制御プログラム２４、４４は、ＨＴＴＰプロトコルを用いて通信を行う。制御プログラム２４、４４は、１回のＨＴＴＰリクエスト／レスポンス毎にソケットを切断する。制御プログラム２４、４４は、セッション識別子を用いて通信データを交換することにより、ソケットの切断によって切り離された各回の通信を関連づけ、一連の通信を特定するようにしている。
【００４５】
上記のように、制御プログラム２４、４４は、１回のＨＴＴＰリクエスト／レスポンス毎にコネクションを切断するにもかかわらず、アプリケーションプログラム２２、４２は、一連の通信データの送受信中には、接続の永続性が維持され続けるものとして処理を実行する。したがって、制御プログラム２４は、一連の通信が終了すると、アプリケーション２２に対してコネクションが切断された旨を通知する（永続性切断通知）。また、何らかの障害が発生し、通信の続行ができなくなった場合にも、制御プログラム２４は、アプリケーション２２に対して永続性切断通知を送信する。制御プログラム４４も同様の処理を行う。
【００４６】
図３に、上記一実施形態による通信データの伝送手順を概念的に示す。送信側のアプリケーションプログラム２２は、ファイル名等を指定してファイル伝送指令３０を生成する。送信側の制御プログラムの全銀協対応部分は、このファイル伝送指令に基づいて全銀協手順電文３２を生成する。さらに、送信側のＨＴＴＰ対応部分は、この全銀協手順電文３２に基づいて、ＨＴＴＰメッセージ３４を生成する。このようにして生成されたＨＴＴＰメッセージ３４は、インターネットを介して、受信側に送られる。
【００４７】
受信側の制御プログラムのＨＴＴＰ対応部分は、ＨＴＴＰメッセージ３４を受けて、これを解釈する。これとともに、全銀協手順電文３２を復元する。受信側の制御プログラムの全銀協対応部分は、全銀協手順電文３２を解釈して、通信の制御や全銀協手順電文の受信側アプリケーションへの引き渡しを行う。受信側のアプリケーションは、制御プログラムからの報告を受けて、上位処理を行う。
【００４８】
なお、受信側は、受信後に確認等を返信する必要があるので、送信側と受信側は交互に入れ替わることになる。また、１つのファイル伝送指令に対して、複数の電文が作成されるので、上記の処理は、複数回繰り返されることになる。
【００４９】
図４に、上記実施形態において用いた通信装置２のハードウエア構成を示す。通信装置２は、ＣＰＵ５２、メモリ５４、ディスプレイ５６、ハードディスク５８、ＣＤ−ＲＯＭドライブ６０、通信部６４、キーボード／マウス６６を備えている。ハードディスク５８には、オペレーティングシステム７０（マイクロソフト社のウインドウズ（商標）など）が記録されている。また、制御プログラム７２、アプリケーションプログラム７４も記録されている。さらに、通信可能な相手先のＵＲＬなどを定義した事前定義情報、送信対象となる様々なファイル７８が記録されている。ＣＰＵ５２は、制御プログラム等にしたがって処理を行うものである。
【００５０】
制御プログラム７２、アプリケーションプログラム７４は、オペレーティングシステム７０と協働して処理を行うものである。また、これらは、ＣＤ−ＲＯＭドライブ６０を介して、ＣＤ−ＲＯＭ６２からインストールされたものである。
【００５１】
通信部６４は、インターネットとの通信を行うための回路部であり、いわゆる、通信ボードと呼ばれているものである。
【００５２】
なお、図示しないが、通信装置４も上記通信装置２と同等の構成を有している。
【００５３】
図５、図６に、この実施形態による通信制御システムにおける通信データのやりとりを示す。この図においては、通信装置２が通信装置４に対してファイル７８を伝送する場合を説明している。この実施形態では、伝送を希望する通信装置２がクライエントになり、伝送を受ける通信装置４がサーバとなるようにしている。
【００５４】
まず、通信装置２のアプリケーションプログラム７４は、ファイル名、相手側通信装置名等を指定して転送指示を行う（図５の▲１▼）。これを受けて、制御プログラム７２は、事前定義情報７６を参照して、相手側通信装置のＵＲＬを取得する。事前定義情報７６には、通信装置名とＵＲＬが対応づけて記録されている。制御プログラム７２は、取得したＵＲＬに基づいて、相手側通信装置４とのソケットを接続する（図５の▲２▼▲２▼'）。これにより、コネクションが確立される。
【００５５】
続いて、通信装置２の制御プログラム７２は、全銀協手順に基づく開局要求電文を、ＨＴＴＰメッセージとして送信する（図５の▲３▼）。通信装置４の制御プログラム７２は、このＨＴＴＰメッセージから、開局要求電文を復元し、アプリケーション７４に渡す。アプリケーション７４は、通信装置４の事前定義情報７６を参照して、開局要求電文中に記載された相手方通信装置が、送受信の権限を有しているか否かを判断する。
【００５６】
権限を有していれば、アプリケーション７４は、開局回答電文を返信するように制御プログラム７２に指令を行う。これを受けて、通信装置４の制御プログラム７２は、開局回答電文を送信装置２に送信する。通信装置２の制御プログラムは、この開局回答電文を受信する（図５の▲４▼）。
【００５７】
次に、通信装置２の制御プログラム７２は送信対象であるファイルのファイル名などを含む開始要求電文を送信し（図５の▲５▼）、これを受けた通信装置４の制御プログラム７２は開始回答電文を返信する。
【００５８】
以上のようにしてファイル送信の準備が整うと、通信装置２の制御プログラム７２は、ファイル７８を分割した１または複数のレコードをまとめたテキストを、ＨＴＴＰメッセージとして送信する（図５の▲６▼）。このＨＴＴＰメッセージを受信した通信装置４の制御プログラムは、テキストからレコードを復元して、アプリケーション７４に渡す。アプリケーション７４は、開始要求電文に記述されていたファイル名を付して、このレコードを記録する。また、通信装置４の制御プログラム７２は、全銀協手順に従ってレコードを受信した旨を示す電文を、ＨＴＴＰメッセージとして返信する。
【００５９】
このようにして、１つのレコードの送信が完了すると、通信装置２の制御プログラム７２は、次のレコードを送信する。同様に、通信装置４の制御プログラム７２は、返信を行う。
【００６０】
上記の処理を繰り返して全てのレコードを送信し終えると、通信装置２の制御プログラム７２は、全銀協手順に従う終了要求電文を、ＨＴＴＰメッセージとして送信する（図５の▲７▼）。これに対して、通信装置４の制御プログラム７２は、全銀協手順に従う終了回答電文を、ＨＴＴＰメッセージとして返信する（図５の▲８▼）。
【００６１】
さらに、通信装置２の制御プログラム７２は、全銀協手順に従う閉局要求電文を、ＨＴＴＰメッセージとして送信する（図５の▲９▼）。これに対して、通信装置４の制御プログラム７２は、全銀協手順に従う閉局回答電文を、ＨＴＴＰメッセージとして返信する（図５の10）。この際、通信装置４の制御プログラム７２は、ＨＴＴＰヘッダ中に、永続性切断通知を埋め込んで送信する。
【００６２】
また、永続性切断通知をヘッダに含む閉局回答電文を受けた通信装置２の制御プログラム７２は、ソケットを切断する（図５の11）。さらに、通信装置２の制御プログラム７２は、通信装置２のアプリケーションに対して、コネクションが切断された旨を伝える。これにより、通信装置２のアプリケーション７４は、一連のやりとりが終了したことを知ることができる。
【００６３】
なお、クライエント側となった通信装置２においては、送信に用いたポートに対するソケットのＴＣＰセッション（ファイルディスクリプタ）に対してサーバ側の通信装置４から返答が送られてくる。したがって、そのファイルディスクリプタを保持しておくことにより、たとえ、複数のサーバに対して通信を行っていたとしても、それぞれの通信を区別することができる。
【００６４】
また、サーバ側となった通信装置４においては、返信時にセッションＩＤをＨＴＴＰヘッダに記述して送信し、クライエント側の通信装置２は、次回に送信を行う際にはこのセッションＩＤを付すようにしている。これにより、通信装置４は、たとえ、複数のクライエントに対して通信を行っていたとしても、ぞれの通信を区別することが可能である。
【００６５】
図５、図６においては、このセッションＩＤについての処理の詳細を示していない。また、図５、図６においては、障害を発見するためのタイマ処理の詳細も示していない。図７、図８に、これらセッションＩＤとタイマに関する処理を含む制御プログラムのフローチャートを示す。
【００６６】
まず、クライエントである通信装置２の制御プログラム７２（以下クライエント）は、サーバである通信装置４の制御プログラム７２（以下サーバ）に対し、ＨＴＴＰプロトコルにおけるソケットの接続を要求する（ステップＳ１）。サーバは、要求に応じてソケットの接続を行う（ステップＳ５１）。
【００６７】
次に、クライエントは、開局要求メッセージを送信する（ステップＳ２）。この実施形態では、開局要求メッセージは、図１１に示すように、ＰＯＳＴメソッドを用いて行われる。すなわち、ヘッダ部分２０１にＰＯＳＴメソッドによる記述を行い、本文部分２０２に開局要求電文を記述している。
【００６８】
サーバは、この開局要求メッセージを受信する（ステップＳ５２）。これにより、サーバは一連の通信が開始したことを認識し、この一連の通信を特定するためのセッションＩＤを決定する。サーバは、決定したセッションＩＤを、相手先通信装置２を特定する情報、ファイル名等と関連づけて、メモリ５４に記憶する。次に、サーバは、開局回答メッセージを返信する（ステップＳ５５）。この際、決定したセッションＩＤをヘッダ中に記述する（ステップＳ５４）。サーバから返送される開局回答メッセージを図１１に示す。ヘッダ部分３０１の拡張ＨＴＴＰヘッダ（図中では、X-ZGH-Session）の項目に、セッションＩＤとして、234f4f13aa7525が記述されている。開局回答電文は、本文部分３０２に記述されている。
【００６９】
クライエントは、この開局回答メッセージを受信する（ステップＳ８）。さらに、クライエントは、受信した開局回答メッセージから、セッションＩＤを取り出してメモリ５４に記憶する（ステップＳ９）。続いて、クライエントは、開始要求メッセージを送信する（ステップＳ１１）。この際、記憶しておいたセッションＩＤをヘッダ中に記述する（ステップＳ１０）。図１１に、開始要求メッセージを示す。ヘッダ部分２０３の拡張ＨＴＴＰヘッダ（図中ではX-ZGH-Session）の項目に、セッションＩＤとして、234f4f13aa7525が記述されている。開始要求電文は、本文部分２０４に記述されている。
【００７０】
サーバは、この開始要求メッセージを受信する（ステップＳ６０）。さらに、サーバは、受信した開始要求メッセージから、セッションＩＤを取り出す（ステップＳ６１）。サーバは、このセッションＩＤに基づいて、いずれのクライエントとの通信であるかを特定する。したがって、複数のクライエントとのやりとりを同時に行っていても、相手方クライエントを特定することができる。
【００７１】
サーバは、同じセッションＩＤをヘッダに付して（ステップＳ６２）、開始回答メッセージを返信する。したがって、一連の通信をセッションＩＤによって特定することが可能となる。
【００７２】
以下、レコードの送信においても同様の処理が行われる。
【００７３】
一連の通信を終了する際には、終了要求−終了回答、閉局要求−閉局回答の各メッセージがやりとりされる。これらメッセージのやりとりは、上記と同じようにして、セッションＩＤが付されて行われる（図８参照）。
【００７４】
ただし、閉局する場合には、ソケットの切断を行う必要がある。この実施形態では、図８のステップＳ７５、図１１の３０５に示すように、閉局回答メッセージのヘッダ中の拡張ＨＴＴＰヘッダ（図中ではX-ZGH-Session）の項目に、永続性切断通知としてcloseを記述している。これを受けたクライエントは、ソケットを切断する。このように、サーバの側から永続性切断通知を行って、これを受けたクライエントが切断処理を行うことにより、クライエントとサーバの双方がコネクションの切断を認識することができる。
【００７５】
なお、サーバは、永続性切断通知を行った後、当該通信に対して付していたセッションＩＤをメモリ５４から削除する。また、このセッションＩＤに関連して記憶していた相手先通信装置２を特定する情報、ファイル名等も削除する（ステップＳ７６）。さらに、アプリケーション７４に対して、コネクションが切断された旨を通知する。
【００７６】
一方、永続性切断通知を受けたクライエントの制御プログラムは、アプリケーション７４に対して、コネクションが切断された旨を通知する。以上のようにして、ＨＴＴＰプロトコルを用いて、全銀協手順における一連の通信を処理することができる。
【００７７】
また、この実施形態では、一連の通信の途中における障害についても、処理できるようにしている。従来の全銀協手順では、障害発生時に、接続を物理的に切断すれば相手方もこれを認識することができた。しかし、ＨＴＴＰプロトコルでは、そのような認識を行うことができない。この実施形態では、以下のようにして、障害の検出と相手方への通知を実現している。
【００７８】
図７のステップＳ２においてメッセージを送信した後、タイマーをリセットしている。このタイマーは、障害検出のためのタイマーである。このタイマーが所定時間経過するまでに、相手方からのメッセージ（ステップＳ８参照）が送信されてこなければ、障害が発生したものと判断する。
【００７９】
図９に、タイムアウト処理のフローチャートを示す。タイムアウト（タイマーが所定時間経過）になっても相手方からの通信がない場合には、拡張ＨＴＴＰヘッダにセッションＩＤおよび永続性切断通知を記述（図中では、X-ZGH-SessionにセッションＩＤ、X-ZGH-Connectionにcloseを記述）して、切断メッセージを送信する（ステップＳ５０５、Ｓ５０６、Ｓ５０７）。
【００８０】
この切断メッセージを受けた相手側通信装置は、このあとのエラー関連処理に使用するため、ＨＴＴＰ拡張ヘッダからセッションＩＤを取り出し（ステップＳ５０４）、その後、ソケットを切断する。
【００８１】
自分がサーバ側である場合には、セッションＩＤ等をメモリから削除する（ステップＳ５１０）。その後、アプリケーション７４へのコネクション切断の通知などエラー関連処理を行う（ステップＳ５１１）。
【００８２】
また、レコードを記録するための容量不足や通信異常などの障害が発生した場合の処理を、図１０にフローチャートで示す。まず、障害の発生を検知すると（ステップＳ６００）、セッションＩＤ、永続性切断通知をヘッダに記述して（ステップＳ６０１、Ｓ６０２）、切断メッセージを送信する（ステップＳ６０４）。図１２に、切断メッセージのヘッダ部分４５１を示す。
【００８３】
なお、当該通信装置がサーバ側である場合には（ステップＳ６０９）、セッションＩＤ等をメモリ５４から削除する処理を行う（ステップＳ６１０）。その後、アプリケーション７４へのコネクション切断の通知などのエラー関連処理を行う（ステップＳ６１１）。
【００８４】
なお、この実施形態では、ＨＴＴＰプロトコルを使用しているため、ＨＴＴＰプロトコル特有の障害も生じうる。したがって、これら特有の障害（たとえば、相手先ＵＲＬの誤り等）が発生した場合も、上記に示す処理によって、コネクションの切断を行うようにしている。
【００８５】
また、サーバ側の通信装置が開局要求電文を受信した際に、接続セッション数オーバなどの原因で、当該要求に応えられない場合がある。この場合に、サーバ側の通信装置の制御プログラムは、開局要求電文を送ってきたクライエント側の通信装置に対して、開局に応えられない旨の電文を返信する。この電文返信の際、代替通信先の通信装置のＵＲＬをＨＴＴＰヘッダに埋め込んで送信するようにしてもよい。これを受けたクライエント側の通信装置は、容易に代替可能な他の通信装置に対して開局要求を行うことができる。
【００８６】
この際、クライエント側の制御プログラムは、サーバが開局に応えられない旨を直ちに処理プログラムに知らせず、代替可能な他のサーバから開局に応えられる旨を受信した後、これを処理プログラムに知らせる。また、制御プログラムは、代替可能な他のサーバが全て開局に応えられない場合には、その旨を処理プログラムに知らせる。
【００８７】
なお、上記実施形態では、ＰＯＳＴメソッドのＨＴＴＰ拡張ヘッダにセッションＩＤを記述するようにしている。しかし、Cookieの項目にセッションＩＤを記述するようにしてもよい。
【００８８】
また、上記実施形態では、全銀協手順をＨＴＴＰプロトコル上で実現した場合について説明している。しかし、全銀協手順だけでなく、通信時にのみ接続を行い、通信中は接続を維持するような手順一般に適用することができる。また、ＨＴＴＰプロトコルだけでなく、１回の通信毎にコネクションを切断するようなプロトコル一般に適用することができる。
【図面の簡単な説明】
【図１】全銀協手順を示す図である。
【図２】この発明の一実施形態による通信制御システムの概要を示す図である。
【図３】この発明の一実施形態による通信の処理概要とデータとを示す図である。
【図４】通信装置のハードウエア構成を示す図である。
【図５】アプリケーションプログラムと制御プログラムの処理内容を示す図である。
【図６】アプリケーションプログラムと制御プログラムの処理内容を示す図である。
【図７】制御プログラムのフローチャートを示す図である。
【図８】制御プログラムのフローチャートを示す図である。
【図９】タイムアウトおよび切断メッセージ受信の際の処理フローチャートを示す図である。
【図１０】障害発生の際の処理フローチャートを示す図である。
【図１１】メッセージのやりとりを示す図である。
【図１２】障害発生時のメッセージのやりとりを示す図である。
【符号の説明】
２・・・通信装置
４・・・通信装置
２２・・・アプリケーション
２４・・・制御プログラム
Claims (14)
- 第１の通信装置と、通信路を介して第１の通信装置に接続された第２の通信装置とを備えた通信制御システムであって、
前記第１および第２の通信装置は、一連の通信データのやりとり中にを、通信路のコネクションが切断されたことにより障害発生を判断する処理プログラムを備え、
さらに、前記第１および第２の通信装置は、前記一連の通信データのやりとり中に前記コネクションの切断が生じうる通信プロトコルを使用するものであり、
前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定する処理を行う制御プログラムを、第１および第２の通信装置に設けたことを特徴とする通信制御システム。 - 一連の通信データのやりとり中に、通信路のコネクションが切断されたことにより障害発生を判断する処理プログラムを用いつつ、前記一連の通信データのやりとり中に前記コネクションの切断が生じうるプロトコルによる通信を可能とするための制御プログラムであって、
前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定する処理を行うことを特徴とする制御プログラム。 - 請求項２のプログラムを記録した記録媒体。
- 請求項１〜３のいずれかのシステム、プログラムまたは記録媒体において、
前記制御プログラムは、接続の永続性を切断する旨の永続性切断通知を相手方の通信装置に対して送信することを特徴とするもの。 - 請求項４のシステム、プログラムまたは記録媒体において、
前記制御プログラムは、正常に通信が終了した場合に前記永続性切断通知を送信することを特徴とするもの。 - 請求項４または５のシステム、プログラムまたは記録媒体において、
前記制御プログラムは、障害が発生した場合に前記永続性切断通知を送信することを特徴とするもの。 - 請求項４〜６のいずれかのシステム、プログラムまたは記録媒体において、
前記制御プログラムは、相手方からの永続性切断通知を受けると、前記処理プログラムに対してコネクションの切断があった旨の通知を行うことを特徴とするもの。 - 請求項１〜７のいずれかのシステム、プログラムまたは記録媒体において、
前記制御プログラムは、相手方の通信装置に対して通信データを送信してから、相手方の通信装置から通信データが送信されてくるまでの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴とするもの。 - 請求項１〜８のいずれかのシステム、プログラムまたは記録媒体において、
前記制御プログラムは、一連の通信データのやりとりの開始から、終了までの時間が、所定時間を超えた場合には、障害が発生したものとすることを特徴とするもの。 - 請求項１〜９のいずれかのシステム、プログラムまたは記録媒体において、
前記制御プログラムは、一連の通信データのやりとりの開始を通信装置から要求された際に、当該要求に応えられない状況の場合には、当該通信装置に対して他の通信装置の接続先を返答することを特徴とするもの。 - 請求項１〜１０のいずれかのシステム、プログラムまたは記録媒体において、
前記プロトコルは、ＨＴＴＰプロトコルであることを特徴とするもの。 - 請求項１１のシステム、プログラムまたは記録媒体において、
前記制御プログラムは、ＨＴＴＰヘッダ部分に、前記永続性切断通知を記述して相手方通信装置に送信することを特徴とするもの。 - 請求項１１または１２のシステム、プログラムまたは記録媒体において、
前記セッション識別子は、ＰＯＳＴメソッドのＨＴＴＰ拡張ヘッダを用いて実現することを特徴とするもの。 - 一連の通信データのやりとり中に、コネクションが切断されたことにより障害発生を判断するプログラムを用いつつ、前記一連の通信データのやりとり中に前記コネクションの切断が生じうるプロトコルを使用して、前記一連の通信データのやりとりを行う通信制御方法であって、
前記コネクションの切断にかかわらず、一連の通信データのやりとりであることを認識可能とするために、セッション識別子を用いて一連の通信データのやりとりを特定することを特徴とする通信制御方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002161342A JP3645537B2 (ja) | 2002-06-03 | 2002-06-03 | 通信制御システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002161342A JP3645537B2 (ja) | 2002-06-03 | 2002-06-03 | 通信制御システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004015081A JP2004015081A (ja) | 2004-01-15 |
| JP3645537B2 true JP3645537B2 (ja) | 2005-05-11 |
Family
ID=30430441
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002161342A Expired - Fee Related JP3645537B2 (ja) | 2002-06-03 | 2002-06-03 | 通信制御システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3645537B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1806877A1 (en) * | 2004-10-26 | 2007-07-11 | Matsushita Electric Industrial Co., Ltd. | Transmitting device, receiving device, and file forwarding system |
| WO2006046445A1 (ja) * | 2004-10-29 | 2006-05-04 | Matsushita Electric Industrial Co., Ltd. | ファイル転送システム、送信機器及び受信装置 |
| JP2007141129A (ja) * | 2005-11-22 | 2007-06-07 | Hitachi Ltd | システム切替方法、その計算機システム及びプログラム |
-
2002
- 2002-06-03 JP JP2002161342A patent/JP3645537B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004015081A (ja) | 2004-01-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6304905B1 (en) | Detecting an active network node using an invalid protocol option | |
| US7966380B2 (en) | Method, system, and program for forwarding messages between nodes | |
| US7761588B2 (en) | System and article of manufacture for enabling communication between nodes | |
| KR101201140B1 (ko) | 요구-응답 전송 프로토콜들에 의한 신뢰성 있는 단방향메시징 | |
| JP4153502B2 (ja) | 通信装置及び論理リンク異常検出方法 | |
| US20080126517A1 (en) | File Transfer System, Transmitting Device and Receiving Device | |
| KR20030051264A (ko) | 데이터 전송시스템, 정보처리장치 및 방법,데이터중계장치 및 방법, 기록매체, 및 프로그램 | |
| JP2003283559A (ja) | データ通信方法、データ通信システム、データ通信プログラム及び記憶媒体 | |
| TWI248268B (en) | System and method for monitoring a connection between a server and a passive client device | |
| US7254739B2 (en) | Error recovery in a client/server application using two independent sockets for communication | |
| JP3645537B2 (ja) | 通信制御システム | |
| US8266253B2 (en) | Server system and event message transmission method therefor, client terminal and connection method and program therefor, and recording medium | |
| EP1575236B1 (en) | Connectivity confirmation method for network storage device and host computer | |
| JP3407002B2 (ja) | メッセージ中継装置及びメッセージ中継方法 | |
| KR20180018137A (ko) | 단방향 전송 장치, 단방향 수신 장치 및 이를 이용한 단방향 재전송 방법 | |
| KR100710766B1 (ko) | 감시 시스템, 피감시 장치, 감시 장치, 및 감시 방법 | |
| JPH1168884A (ja) | 伝送媒体接続装置および制御装置ならびに被制御装置および記憶媒体 | |
| TW561749B (en) | Link-lock device and method of monitoring and controlling a link for failures and intrusions | |
| CN110602339B (zh) | 一种基于语音网关的故障检测方法、系统及存储介质 | |
| CN113472568A (zh) | 语音网关报障呼叫方法和系统 | |
| Ko et al. | Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) | |
| JPH11112609A (ja) | 通信システムにおける通信障害回復方法ならびに同方法がプログラムされ記録される記録媒体 | |
| CN107819648A (zh) | 网络配置netconf连接检测方法和装置 | |
| KR102052892B1 (ko) | ＩｏＴ 환경에서 기밀성과 신뢰성 있는 메시지 통신 시스템 및 방법 | |
| WO2010069207A1 (zh) | 一种取消同步的方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050127 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050131 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050203 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3645537 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080210 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090210 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090210 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100210 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S631 | Written request for registration of reclamation of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313631 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100210 Year of fee payment: 5 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110210 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120210 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130210 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140210 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R370 | Written measure of declining of transfer procedure |
Free format text: JAPANESE INTERMEDIATE CODE: R370 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R370 | Written measure of declining of transfer procedure |
Free format text: JAPANESE INTERMEDIATE CODE: R370 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |