ＩＣカードシステム、そのサーバ装置、プログラム
【課題】多数の決済端末に対する全体のデータ配信効率を向上させる。
【解決手段】データ配信権限管理部１１は、データ配信を同時にいくつまで実施するか（最大配信権限数）を管理・制御し、最大配信権限数を越える同時配信は行わない。データ転送処理保留管理部１２は、決済端末２０からの配信要求を、その保留数が最大処理保留数を越えない限り保留し、越える場合には要求を拒否することで要求元の決済端末２０にリトライを行わせる。データ配信権限管理部１１は、最大配信権限数を越えない状態では、保留管理部１２に保留されている配信要求がある場合にはこの配信要求に応じたデータ配信を開始する。その際、データ配信終了した決済端末からの完了応答を待つことなく、保留している配信要求に対するデータ配信開始を行える。
【解決手段】データ配信権限管理部１１は、データ配信を同時にいくつまで実施するか（最大配信権限数）を管理・制御し、最大配信権限数を越える同時配信は行わない。データ転送処理保留管理部１２は、決済端末２０からの配信要求を、その保留数が最大処理保留数を越えない限り保留し、越える場合には要求を拒否することで要求元の決済端末２０にリトライを行わせる。データ配信権限管理部１１は、最大配信権限数を越えない状態では、保留管理部１２に保留されている配信要求がある場合にはこの配信要求に応じたデータ配信を開始する。その際、データ配信終了した決済端末からの完了応答を待つことなく、保留している配信要求に対するデータ配信開始を行える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の決済端末とサーバがネットワークに接続したＩＣカードシステムに関する。
【背景技術】
【０００２】
例えば、非接触ＩＣカード等を利用して電子マネー決済等を実行するシステム（ＩＣカード決済システム）では、任意の決済端末に提示されたＩＣカードが無効カードであるか否かを判定する為に所謂“ネガ情報”を用いている。そして、処理スピード向上のため、ネガ情報を各決済端末で保持している。この為、各決済端末に対して、定期的に、ネガ情報を配信する必要がある。
【０００３】
上記ネガ情報とは、例えば遺失された非接触ＩＣカードの不正使用等を判定する為の情報であり、例えば鉄道関係等で、自動改札機（決済端末に相当）を包含した駅務システムにおいて、定期券として使用されている非接触ＩＣカードが紛失等した場合、ユーザが届け出ることで、この紛失した非接触ＩＣカードの固有番号等が上記ネガ情報としてサーバ等に登録されて、サーバ等から上記各決済端末の一例である各自動改札機等に、ネガ情報が配信されて記憶される。
【０００４】
これにより、各自動改札機は、サーバ等に逐一問い合わせる必要なく（つまり、上記処理スピード向上）、改札通過時に使用されたＩＣカード定期券の固有番号が、ネガ情報のなかにある場合等には、不正使用と判定することができる。但し、新たな紛失等が起こる毎にネガ情報として登録すべき固有番号等が増えていくものであり、各自動改札機が保持するネガ情報を、定期的に更新する必要がある。
【０００５】
上記駅務システムの例はＩＣカード決済システムの一例であり、この例に限らず、ＩＣカード決済システムにおいて、各決済端末にネガ情報（無効カードのカード番号リスト（ネガリスト））を保持させて、各決済端末において提示されたＩＣカードが無効カードであるか否かを判定するようにする場合、例えば定期的にサーバ装置から各決済端末にネットワークを介して最新のネガ情報を配信する必要がある。
【０００６】
ここで、ネガリストは、数万〜数十万件の情報（カード番号等）を含むことがあり、その場合、データサイズは数ＭＢ程度に達する。これに対して、サーバ装置側で旧ネガリストと新ネガリストとの差分（異なる部分；新たに追加された情報や削除された情報）を求めて、この差分データを各決済端末に配信する方法が知られているが、この場合でも、数百ＫＢ程度になる。これは、組込機器である決済端末（処理性能が低い）にとっては小さくないサイズであり、ネットワーク転送には数秒から数十秒を要する。また差分データ配信の場合には、決済端末において受信した差分データと自己が保持していた旧ネガリストとに基づいて最新ネガリストを生成する処理も必要となり、通常、この生成処理を完了したら正常受信できた旨をサーバ装置に通知して、この通知を以って配信処理は終了するので、配信処理全体として非常に時間が掛かるものとなる。
【０００７】
ネガリストを配信するサーバは、多数の決済端末を収容する（ネットワークを介して多数の決済端末の管理する）。これは、数千台から1万台程度になることもありえる。
このようなシステムで、一度に多くの決済端末からサーバへアクセスが集中すると、ネットワークのスループットが悪化し、全ての端末へのネガリスト配信に掛かる時間が非常に長くなってしまう恐れがある。これを防ぐために、サーバで同時接続数を制限し、サーバへの接続数が所定の最大同時接続数に達している状態のときには、新たに接続要求してきた決済端末に対しては、ビジーを返し、その決済端末に所定時間後にリトライさせるのが一般的である。
【０００８】
例えば、特許文献１記載の公知技術では、サーバの混雑具合を端末の接続数によって判断して端末に通知し、端末がデータ配信の中断／再開をおこなうことで制御をしている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００２−３０４３３４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ここで、図９に、決済端末−サーバ間の通信シーケンスの一例を示す。
この通信シーケンスでは、サーバ−決済端末間でデータ配信のためのネゴシエーション（データ配信要求（Ｓ１）→データ配信許可（Ｓ２））を行った後、サーバが決済端末へデータ（ネガリスト（上記の通り差分の場合もある））の配信を行う（Ｓ３）。その後、決済端末は、受信したデータを処理し（データ加工処理（Ｓ４））、結果（成功／失敗）をサーバに通知する（データ配信完了通知（Ｓ５））。このデータ加工処理は、例えば上述した差分データに基づく新ネガリストの生成処理等であるが、この例に限らず、新ネガリストが配信される場合でも何らかの処理が必要となる。上記完了通知を受けたサーバはデータ配信完了応答を返す（Ｓ６）。但し、失敗が通知された場合には、例えば再度データ配信（Ｓ３）を行う。
【００１１】
決済端末において、上記データ加工処理（受信した新ネガリストを既に保持している旧ネガリストとマージし、ソートする等の処理）を実施後、その成否をサーバに通知する、という処理を行うと、このような通信シーケンスになる。
【００１２】
この通信シーケンスでは、データ加工処理（Ｓ４）の間は、決済端末−サーバ間でデータ送受信は行われないが、接続は維持された状態となっている。したがって、従来技術である同時セッション数の制限を適用すると、このデータ加工処理の時間はサーバにとっては無駄な待ち時間となってしまい、またサーバへの接続数が所定の最大同時接続数に達している状態のときには、既にデータ配信は終了しているにも係わらずデータ加工処理が終了するまでは接続解除されないので、サーバは新たに接続要求がきても拒否してリトライさせることになり（図１０、図１１）、システム全体でみたとき、データ配信性能が低下してしまうという課題がある。
【００１３】
尚、上述した従来技術では、ネガリスト配信の場合を例にしたが、上記の問題はこの例に限るものではない。特に配信するデータがネガリストと同様にデータ量が多いものである場合に問題が大きくなる。更に、特に、サーバにアクセスが集中し易い時間帯がある場合にも、上記問題が大きくなる。
【００１４】
図１０、図１１は、従来のデータ配信動作例を示す図である。
図１０、図１１は、何れも、上記最大同時接続数（最大同時セッション数）が３であるものとし、図１０は等間隔アクセスの場合、図１１は同時アクセスの場合の動作例を示す。
【００１５】
図１０、図１１において、配信要求Seq（シーケンス）は、上記図９におけるＴＣＰ接続、データ配信要求（Ｓ１）、データ配信許可（Ｓ２）のシーケンスである。尚、サーバは、「現在の接続数＜上記最大同時接続数」であればデータ配信許可（Ｓ２）を返信するが、そうでなければビジーを返信する。ビジーを返信された決済端末は、所定のリトライ間隔をおいて再度、配信要求Seq（シーケンス）を行う。
【００１６】
サーバは、データ配信許可（Ｓ２）を返信した決済端末に対しては、続いて図示のデータ転送（図９のデータ配信（Ｓ３）に相当）を実行し、これに応じて決済端末は図示のデータ処理（図９のデータ加工処理（Ｓ４）に相当）を実行する。そして、最後に転送完了Seq（図９のデータ配信完了通知（Ｓ５）、データ配信完了応答（Ｓ６）、ＴＣＰ切断）を実行する。この転送完了Seqにおいて、サーバは、「現在の接続数」を更新（−１デクリメント）する。サーバへの接続数が所定の最大同時接続数に達している状態のときには、これによって新たな決済端末にデータ配信可能な状態となる。尚、上記データ配信許可（Ｓ２）を返信した際にも、「現在の接続数」を更新（＋１インクリメント）する。
【００１７】
ここで、図１０と図１１との違いは、図１０では、図示の通り、各決済端末のサーバに対するアクセスタイミング（上記データ配信要求を送るタイミング）が、少しずつズレた場合（これを上記等間隔アクセスというものとする）を例にしている。また、図１１は、図示の通り、上記アクセスタイミングが同時である場合を例にしている。
【００１８】
図１０、図１１に示す通り、何れの場合も、サーバに接続している決済端末の台数（現在の接続数）が最大同時接続数（本例では３台）である状態では、更に他の決済端末がアクセス（配信要求Seq）してきてもサーバは受付けずにビジーを返すので、その決済端末は所定のリトライ間隔を空けて（所定時間後に）再度アクセスすることになる。
【００１９】
この為、現在の接続数（同時接続数）が上記最大同時接続数未満となっても、直ちに新たなデータ配信が行われない場合がある。図１０、図１１に示す例では、端末１、端末２、端末３の全てにおいてデータ配信終了して「現在の接続数」が‘０’になった状態の後でも、しばらくの間は（配信要求Seq受信までは）データ配信処理が行われない。この例は極端にしても、サーバが新たな決済端末にデータ配信可能な状態になっても配信処理が行われない状態となる時間帯は発生するものであり、全体としてのデータ配信効率が悪いものとなる。この為、このサーバがデータ配信すべき全ての決済端末にデータ配信を行えるまでに、非常に時間が掛かることになる。つまり、サーバおよびネットワーク資源を有効利用できず、システム全体でのデータ配信性能が悪いものとなる。
【００２０】
具体的な状況として、例えば上記ネガリストを例にすると、様々な店舗等に設置された多数の決済端末が、毎日、所定の時間帯（例えば、朝の開店前の所定時間帯等）にサーバにアクセスしてネガリスト（または差分）の配信を受けることで、毎日、最新のネガリストを保持している状態で運用開始する状況等がある。この例の場合、各決済端末は、ネガリストの更新を、その店舗の開店に間に合うように行う必要がある。
【００２１】
ここで、一般的に、２４時間営業の店舗等を除くと、店舗の開店時間は１０時近辺である場合が多い。この為、多数の決済端末がほぼ一斉にサーバにアクセスすることが起こり得る（図１１の例）。これを避ける為に、各決済端末のサーバへのアクセスタイミングが少しずつズレるように予め設定しておくことも考えられる（図１０の例）。しかしながら、上記図１０、図１１で説明した通り、何れの場合でも、ネガリストのデータ量が大きい為（差分を送信する場合にはデータ加工処理に時間が掛かる為）に各決済端末それぞれに対するデータ配信処理に時間が掛かることもあって、アクセスしてもサーバに接続できない（拒否される）決済端末が多数発生する場合があり得る。
【００２２】
サーバに接続できなかったサーバは、リトライを行うが、上記の状況では多数の決済端末がリトライを行うことになり、リトライ時にもアクセスが集中していて接続できず、更にリトライを行うことになることも起こり得る。この様にリトライを繰り返し、ネガリスト取得までに非常に時間が掛かることになると、開店時間に間に合わない可能性がある。これは、サーバ側にとっては、ネガリストを配信すべき全ての決済端末にネガリストを配信するまでに掛かる時間（全体としてのデータ配信処理に掛かる時間）が非常に長くなることになり、一部の決済端末に関しては実質的に配信が間に合わない事態に陥ることになる。
【００２３】
アクセスを分散できれば、通信量が制限される回線を効率的に使えるので、スループットが高くなり、所定時間内にネガリストを更新できる。しかし、アクセスが集中すれば、通信に使われない時間帯が生じるため、効率的な通信を行えずにスループットが低下し、所定時間内にネガリストを更新できないことが起こり得る。
【００２４】
本発明の課題は、複数の決済端末とサーバがネットワークに接続したＩＣカードシステムに係わり、サーバおよびネットワーク資源を最大限に有効利用可能とすることで、システム全体でのデータ配信性能を向上させることができるＩＣカードシステム、そのサーバ装置、プログラム等を提供することである。
【課題を解決するための手段】
【００２５】
本発明のＩＣカードシステムは、複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムであって、前記ＩＣカード決済端末は、任意のときに又は定期的に、前記サーバ装置に対して前記ネットワークを介して、所定のデータの配信要求を送信して、該サーバ装置にデータ配信を行わせ、該配信されたデータに対して所定のデータ処理を実行後、前記サーバ装置に対して完了通知を送信するデータ取得手段を有し、前記サーバ装置は、データ配信処理の同時実行数に対する上限値を示す第１の閾値を記憶する閾値記憶手段と、前記配信要求を受信する毎に、現在の前記同時実行数が前記第１の閾値に達していない限りは該配信要求に応じてデータ配信を開始し、前記同時実行数が前記第１の閾値に達している場合には、該受信した配信要求を保留し、任意の決済端末に対する前記データ配信が完了したら前記完了通知を待つことなく前記保留してある配信要求に応じたデータ配信を開始するデータ配信制御手段とを有する。
【００２６】
上記構成のＩＣカードシステムでは、現在の同時実行数が第１の閾値に達している状態で新たな配信要求を受信した場合、従来では要求拒否して所定時間後のリトライを行わせたのに対して、当該配信要求を保持しておく。これにより、任意のＩＣカード決済端末に対するデータ配信が完了して同時実行数が第１の閾値未満となり新たな配信が可能な状況になったら、直ちに、保留してある配信要求に応じてデータ配信を開始できる。
【００２７】
従来では、新たな配信が可能な状況になってもリトライ等により新たな配信要求が来るまでは、データ配信が開始できず、データ配信の効率が悪いものであったが、本発明ではデータ配信の効率がよく、全体でのデータ配信性能を向上させることができる（全体でのデータ配信に掛かる時間を短縮できる。
【００２８】
また、本発明では、従来のように完了通知を待つことなく、データ配信終了した時点で次のデータ配信開始が可能となっており、更にデータ配信の効率がよく、全体でのデータ配信性能を更に向上させることができる。
【００２９】
この様に、本発明では、サーバ装置において新たなデータ配信が可能な状態であるにも係わらず新たなデータ配信が開始されずに待ち状態となる期間を、従来に比べて非常に短くすることができ、複数のＩＣカード決済端末全体に対するデータ配信効率が向上し、複数のＩＣカード決済端末全てに対してデータ配信完了するまでの時間を短くすることができる。
【００３０】
また、上記ＩＣカードシステムにおいて、例えば更に、前記閾値記憶手段には更に前記配信要求の保留数に対する上限値を示す第２の閾値が記憶され、前記データ配信制御手段は、現在の前記配信要求保留数が前記第２の閾値に達している場合には、前記受信した配信要求を保留せずに、該配信要求の送信元のＩＣカード決済端末に対して要求拒否を通知することで該ＩＣカード決済端末に所定時間後のリトライを実行させるようにしてもよい。
【００３１】
配信要求の保留を無制限に行うと、場合によっては配信要求保留数が非常に多数となり、要求元のＩＣカード決済端末の応答待ち時間が非常に長くなる可能性があるので、第２の閾値により配信要求保留数を制限する。
【００３２】
また、例えば、上記第２の閾値自体を、状況に応じて適切な値へと変更するようにしてもよい。すなわち、上記ＩＣカードシステムにおいて、例えば更に、予め各スループットに対応付けて任意の各第２の閾値候補を記憶する第２の閾値候補記憶手段と、前記各決済端末に対する各データ配信に係わるスループットを算出し、該算出したスループットに基づいて前記第２の閾値候補記憶手段から該当する第２の閾値候補を取得してこれを新たな前記第２の閾値として前記閾値記憶手段に記憶する第２の閾値更新手段を有するように構成してもよい。
【００３３】
これによって、現在のスループットに応じた適切な第２の閾値が設定されることになり、例えば現在のスループットが低く配信処理時間が掛かるにも係わらず、多数の配信要求が保留されている状態になり、その為に保留されている時間（決済端末側にとっては要求に対する応答（配信）待ち時間）が非常に長くなるという事態にはならないことになる。
【発明の効果】
【００３４】
本発明のＩＣカードシステム、そのサーバ装置、プログラム等によれば、複数の決済端末とサーバがネットワークに接続したＩＣカードシステムに係わり、サーバおよびネットワーク資源を最大限に有効利用可能とすることで、システム全体でのデータ配信性能を向上させることができる。
【図面の簡単な説明】
【００３５】
【図１】本例のＩＣカードシステムの構成例を示す図である。
【図２】データ配信時の通信シーケンスの一例（その１）を示す図である。
【図３】データ配信時の通信シーケンスの一例（その２）を示す図である。
【図４】データ配信時の通信シーケンスの一例（その３）を示す図である。
【図５】等間隔アクセスの場合のデータ配信動作例を示す図である。
【図６】同時アクセスの場合のデータ配信動作例を示す図である。
【図７】処理保留数テーブルの一例を示す図である。
【図８】コンピュータ・ハードウェア構成図である。
【図９】決済端末−サーバ間の通信シーケンスの一例を示す図である。
【図１０】従来の等間隔アクセスの場合のデータ配信動作例を示す図である。
【図１１】従来の同時アクセスの場合のデータ配信動作例を示す図である。
【発明を実施するための形態】
【００３６】
以下、図面を参照して本発明の実施の形態について説明する。
尚、以下の説明では上記従来技術に従ってネガリスト配信の場合を例にするが、本発明はネガリスト配信の場合に限るものではなく、配信するデータは基本的には何でもよい。但し、配信するデータがネガリストと同様にデータ量が大きなものである場合に（更に多数の決済端末からデータ配信サーバへアクセスが集中する場合に）、本発明は特に顕著な効果を奏する。上記ネガリスト以外の例としては、例えば、決済端末のファームウェアをオンラインで更新する場合におけるデータ配信サーバからネットワークを介して各決済端末に配信される当該ファームウェア等が考えられる。勿論、この例に限るものではない。
【００３７】
図１に、本例のＩＣカードシステムの構成例を示す。
図示のシステムでは、多数の決済端末２０とサーバ１０が、例えばＬＡＮ／ＶＰＮ（Virtual Private Network；仮想プライベートネットワーク）等であるネットワーク１に接続しており、ネットワーク１を介して相互に通信可能である。特に、サーバ１０は、各決済端末２０からの要求に応じて、任意のデータを配信するものである。
【００３８】
サーバ１０は、データ配信権限管理部１１、データ転送処理保留管理部１２、対決済端末通信機能部１３、及びデータ管理部１４を有する。
また、決済端末２０は、対サーバ通信機能部２１、データ管理部２２を有する。対サーバ通信機能部２１は、ネットワーク１を介してサーバ１０に接続して、例えば上記図９で説明したデータ配信を受ける為の処理（データ配信要求送信や配信されたデータの加工処理等）を行う機能処理部である。また、データ管理部２２は例えば配信されたネガリストや上記対サーバ通信機能部２１の処理機能を不図示のＣＰＵにより実行させる為の所定のアプリケーションプログラム等を記憶するメモリ等である。図示していないが、勿論、ネガリストを用いてＩＣカード決済処理を行う機能部等の他の各種機能部も存在するが、何れにしても決済端末２０の構成・処理機能自体は、従来と同じであってよく、ここでは特に説明しない。
【００３９】
ここで、サーバ１０に関して、上記図１に示す各構成要素（データ配信権限管理部１１、データ転送処理保留管理部１２、対決済端末通信機能部１３から成る構成）及びこれらによる後述する図２〜図４等の処理は、一例を示すものであり、この例に限るものではない。
【００４０】
サーバ１０の処理機能は、概略的には、データ配信処理の同時実行数に対する上限値を示す第１の閾値を登録しておき、任意の決済端末２０からの配信要求を受信する毎に、現在の上記同時実行数が上記第１の閾値に達していない限りはこの配信要求に応じてデータ配信を開始し、上記同時実行数が上記第１の閾値に達している場合には、受信した配信要求を保留し、任意の決済端末２０に対するデータ配信が完了したらこの決済端末２０からの完了通知を待つことなく保留してある配信要求に応じたデータ配信を開始するものである。従来では、現在の上記同時実行数が上記第１の閾値に達している場合には、要求元の決済端末２０にビジー応答等を返信することで所定時間後のリトライを実行させたが、上述してある問題が生じる。これに対して、本例のサーバ１０では、この様な場合でもビジー応答等を返信せずに受信した配信要求を保留しておくことで（更に完了通知を待たないことで）、この問題を解消できる。
【００４１】
また、サーバ１０の概略的な処理機能としては、例えば更に、配信要求の保留数に対する上限値を示す第２の閾値を更に登録しておき、現在の配信要求保留数が第２の閾値に達している場合には、受信した配信要求を保留せずに、ビジー応答等を返信するようにしてもよい。つまり、配信要求の保留数に制限を設けるようにしてもよい。配信要求の保留を無制限に行うと、場合によっては配信要求保留数が非常に多数となり、要求元の決済端末２０の応答待ち時間が非常に長くなる可能性があるので、第２の閾値により配信要求保留数を制限する。また、例えば、第２の閾値自体を、状況に応じて適切な値へと変更するようにしてもよい（後述する現在のスループットに応じた第２の閾値の設定変更等）。
【００４２】
以下、上記サーバ１０の構成、処理の一例としての上記各構成要素１１〜１３等について、説明する。尚、この例では、後述するように配信権限要求の保留とその保留数の管理等を行うものとなるが、これは実質的には上記配信要求の保留とその保留数の管理等と同じことである。また、尚、以下の説明における最大配信権限数が上記第１の閾値の一例であり、最大処理保留数が上記第２の閾値の一例である。
【００４３】
データ配信権限管理部１１は、決済端末２０へのデータ配信を同時にいくつまで実施するか（最大配信権限数；最大接続可能数とも言う）を管理・制御する。本説明の例では、最大配信権限数を３として管理するものとする。データ配信処理保留管理部１２は、決済端末２０からのデータ配信要求をいくつまで要求を拒否せずに処理保留として保持するかを制御する。本説明の例では最大処理保留数を１０とする。
【００４４】
尚、上記概略的な説明で示す通り、最大処理保留数による保留数の制限は、必ずしも必須のものではない。よって、受信したデータ配信要求は制限無しで全て保留するようにしてもよい。
【００４５】
尚、最大配信権限数は、例えばネットワーク帯域幅や決済端末２０の通信性能等に応じて設計者等が予め適切と思われる値を決定して記憶させておくものである。
対決済端末通信機能部１３は、決済端末２０との通信を行ってコマンド／データ送受信を行う機能部である（特にネガデータ配信要求の受信とこれに応じたネガデータの配信処理）。
【００４６】
尚、図では対決済センタ通信機能部１３を複数示しているが、これは、複数の決済端末２０に対して同時にＴＣＰコネクションを張って通信可能なことを示している。つまり、複数の対決済センタ通信機能部１３は、それぞれが任意の１つの決済端末２０に対するＴＣＰコネクションを受け持つスレッド等と考えてよい。別の言い方をすれば、サーバ１０には例えば上記複数の対決済センタ通信機能部１３を包含するプロセスがあり、個々の対決済センタ通信機能部１３はこのプロセス内におけるスレッド動作と見做すこともできる。
【００４７】
データ管理部１４は、例えばハードディスク等の記憶装置であり、例えば配信すべき新ネガ情報（あるいは差分を配信する場合には、新ネガ情報だけでなく旧ネガ情報等も保持しており、これらのよって生成した差分データも格納される）や、後述する図７のテーブル情報等が格納される。
【００４８】
尚、上記データ配信権限管理部１１、データ転送処理保留管理部１２、対決済端末通信機能部１３は、ここでは図示しないサーバ１０のＣＰＵ等が、記憶装置（ハードディスク等）に予め記憶されている所定のアプリケーションプログラムを読出し・実行することにより実現される処理機能部である。
【００４９】
図２、図３、図４に、サーバ１０から決済端末２０へのデータ配信時の通信シーケンスの一例を示す。図２は配信権限に空きがある場合、図３は配信権限に空きが無かった場合、図４は処理保留数が閾値を越えている場合の通信シーケンスを示している。
【００５０】
尚、図２〜図４において、図９に示した各処理（Ｓ１〜Ｓ６）と同じ処理には同一符号を付してある。
まず、図２〜図４の何れにおいても、各決済端末２０は、サーバ１０に何らかの要求を行う場合には、まず、サーバ１０の任意の対決済端末通信機能部１３とＴＣＰ接続確立後、「データ配信要求」を送信する（Ｓ１）。このデータ配信要求を受けた対決済端末通信機能１３は、このデータ配信要求を保持すると共に、データ配信処理保留管理部１２に対して配信権限の要求コマンド（配信権限要求）の登録を依頼する（Ｓ１１）。
【００５１】
データ配信処理保留管理部１２は、既に登録済みの「配信権限要求」の数（処理保留数）が、処理保留閾値（最大処理保留数）に達しているか否かを判定し、達していない場合のみ登録依頼を受け付けて当該新たな「配信権限要求」を記憶する。図２、図３は処理保留数が閾値に達していない場合を示している。
【００５２】
一方、図４は、処理保留数が最大処理保留数に達していた場合（空きがない場合）を示してあり、この場合には図４に示すようにデータ配信処理保留管理部１２は、要求元の対決済端末通信機能１３に対して「配信拒否」を返す（Ｓ１５）。これより、対決済端末通信機能１３は「データ配信ビジー応答」を要求元の決済端末２０へ返信して（Ｓ７）通信を終了する（ＴＣＰ切断）。これにより、この要求元の決済端末２０は、所定時間後にリトライすることになる。
【００５３】
尚、図４は、処理保留数が最大処理保留数に達している場合の処理例を示すものである為、データ配信権限管理部１１の処理は、図示していないが、随時、以下に説明する図２、図３と同様の処理を行っている。
【００５４】
以下、図２、図３を参照して、主にデータ配信権限管理部１１に係わる処理について説明する。
図２に示すように、データ配信権限管理部１１は、配信権限に空きがある場合、すなわち配信権限を割り当てている対決済端末通信機能１３の数（権限割当数；つまり同時実行数／同時接続数）が、上記最大配信権限数（＝３）に達していない場合には、随時、データ配信処理保留管理部１２を監視し、「配信権限要求」が保持されているか否かをチェックする。そして、保持されている場合には「配信権限要求」を取得する（Ｓ１２）。尚、複数の「配信権限要求」が保持されている場合には、そのなかで最も古い（最初に保持された）「配信権限要求」を取得する。尚、データ配信処理保留管理部１２は、例えば、ＦＩＦＯ（First-In/First-out）メモリ（キュー）に「配信権限要求」を格納する。よって、データ配信権限管理部１１が「配信権限要求」を取り出す際には自動的に最も古いものが取り出されることになる。
【００５５】
そして、取得した「配信権限要求」を出した対決済端末通信機能部１３に対して配信権限を割り当てる（Ｓ１３）。尚、例えば、「配信権限要求」にはその「配信権限要求」を出した対決済端末通信機能部１３を識別できる情報（ＩＤ等）が含まれている。
【００５６】
また、これより、データ配信処理保留管理部１２は、上記処理保留数を更新する（処理保留数＝処理保留数−１）。また、データ配信権限管理部１１は、上記「権限割当数」を更新し（権限割当数＝権限割当数＋１）、当該更新後の権限割当数に関して、再び上記の配信権限に空きがあるか否かの判定を行い、この判定結果に応じた処理を行う。もし、配信権限に空きがあり、更に保留管理部１２に保持されている「配信権限要求」がある場合には、上記と同様に、この「配信権限要求」を取得して配信権限を割り当てる処理を実行することになる。
【００５７】
上記配信権限を割り当てられた対決済端末通信機能部１３は、上記保持しておいたデータ配信要求に応じて、その送信元の決済端末２０に対するデータ配信を実施し（Ｓ３）、データ配信完了後にデータ配信権限管理部１１に対して配信権限解放を通知する（Ｓ１４）。これに応じて、データ配信権限管理部１１は、上記「権限割当数」を更新し（権限割当数＝権限割当数−１）、これによって配信権限に空きがある状態になることから、上記データ配信処理保留管理部１２を監視する処理を行うことになる。
【００５８】
尚、図２に示すように、上記データ配信を受けた決済端末２０は、従来と同様、データ加工処理（Ｓ４）を行い、処理完了したら対決済端末通信機能部１３に対してデータ配信完了通知（Ｓ５）を送信し、これに応じて対決済端末通信機能部１３からデータ配信完了応答（Ｓ６）が送られてきたら、ＴＣＰ切断し、通信を終了する。
【００５９】
上記の通り、本手法では、データ配信した決済端末２０からの上記データ配信完了通知を待つことなく、データ配信完了した時点で配信権限が解放されるので、上記の通り「権限割当数」が更新され、保持されている「配信権限要求」がある場合には、この時点で配信権限を割り当ててデータ配信処理開始することができる。よって、データ配信完了通知を待つ時間が無い分、データ配信効率が向上し、データ配信を必要とする決済端末２０全体でのデータ配信時間が短縮されることになる。
【００６０】
また、「配信権限要求」を保持しない場合、データ配信完了した時点で配信権限が解放されて新たな決済端末２０にデータ配信が可能となっても、任意の決済端末２０から（リトライ等により）「データ配信要求」が送られてくるまではデータ配信が行えないことになり、無駄な待機時間が生じることになる。これに対して、本手法では上記の通り「配信権限要求」を保持するので、この点でも無駄な待機時間が無い分、データ配信効率が向上し、全体でのデータ配信時間が短縮されることになる。
【００６１】
尚、上記の通り、データ配信完了通知を待たないことから、配信したデータを決済端末２０が正常に受信できたかは不明である。また、正常受信できた場合でもデータ加工処理において何らかのエラーが生じる可能性がある。この場合、決済端末２０は、データ配信完了通知の代わりに不図示のエラー通知を送信し、これに対してサーバ１０は不図示のエラー確認応答を返信する等して、ＴＣＰ切断を行う。そして、この場合には、決済端末２０はリトライを行うことになる。
【００６２】
一方、図３に示すように、データ配信権限管理部１１は、配信権限に空きがない場合、配信権限を割当済みの対決済端末通信機能部１３の何れかが配信権限を解放するのを待つ。そして、配信権限が解放されると、配信権限に空きがある状態になることから、上記の図２で説明した処理を行う。すなわち、データ配信処理保留管理部１２を監視し、「配信権限要求」が登録されていれば、その「配信権限要求」を登録した対決済端末通信機能部１３に対して配信権限を割り当てる。その後は図２で説明した通りであり、ここでは特に説明しない。
【００６３】
尚、既に述べてあるように、上記保留管理部１２における“「配信権限要求」の保持・管理”は、実質的に“「データ配信要求」の保持・管理”と同義である。上記の説明では、一例として、データ配信権限管理部１１に対する配信権限割当ての管理として説明したが、この例に限るものではない。本手法は、本質的には、従来では同時接続数の制限により新たな「データ配信要求」に対して拒否してリトライさせるような状態であっても、拒否せずに「データ配信要求」を保持しておき（但し、保持数にも上限を設ける；最大処理保留数）、配信権限に空きが生じたら（同時接続数が最大配信権限数未満となったら）、直ちに、保持している「データ配信要求」に応じてデータ配信が行えるようにすることで（更にデータ配信完了通知を待たないようにすることで）、データ配信可能であるにも係わらず配信できない状態となる時間（無駄な時間）の削減を実現でき、全体としてのデータ配信効率を向上させ、システム全体としてのデータ配信処理時間を短縮することができるものである。
【００６４】
この実施例によって決済端末８台に対してネガリスト配信をおこなった場合の例を図５、図６に示す。尚、図５、図６に示す配信要求Seq（シーケンス）、転送完了Seq（シーケンス）の意味は、上記図１０、図１１で説明した通りである。
【００６５】
図５は上記図１０に対応するもの（すなわち、等間隔アクセスの場合）、図６は上記図１１に対応するもの（すなわち、同時アクセスの場合）である。この例では、最大同時接続数は図１０、図１１等と同じく‘３’であるものとし、最大処理保留数は例えば‘５’であるものとする。よって、端末４〜端末８は何れもその配信権限要求が保留されることになり、リトライを行う必要はなく、配信権限待ち状態を経て、配信権限に空きが生じたら直ちにデータ転送が行われることになる。よって、無駄な待機時間が生じることなく、切れ目無くデータ転送を行うことが可能となり、効率的なデータ転送が行える。
【００６６】
また、本手法では上記の通り、配信先の決済端末２０からのデータ配信完了通知を待つことなく、データ配信完了した時点で配信権限解放を行うので、図示の通り例えば端末４に関しては、端末１へのデータ転送が完了した時点で配信権限が割り当てられ、データ転送開始することになる。従来では、端末１へのデータ転送が完了しても「転送完了Seq」までの間は端末４へのデータ転送が開始されないので、非効率であったが、本手法ではこの様な無駄な待ち時間が生じることなく、切れ目無くデータ転送を行うことが可能となり、効率的なデータ転送が行える。
【００６７】
以上、本手法によれば、図５、図６などに示すように、サーバ１０は、決済端末２０からのアクセスが集中した場合でも、データ配信を、権限割当数が最大配信権限数（＝３）の状態のまま切れ目無く実施することが可能となる。すなわち、サーバおよびネットワーク資源を最大限に有効利用することができ、この結果、アクセス集中時もネットワークトラフィックを一定以下に保ちつつ、サーバからのデータ配信のスループットを最大にすることができる。
【００６８】
通信セッションにおいて、データ転送が間欠的に発生するような通信形態において、サーバから決済端末へのデータ転送スループットを高く保つことが可能になる。
以上説明したように、本例のＩＣカードシステムによれば、複数の（特に多数の）決済端末にデータ量が大きいデータ（ネガリスト等）を配信するサーバ装置を有するシステムにおいて、特にアクセス集中する状況である為に決済端末からの接続数が最大接続可能数を越える場合に、従来ではビジー応答して決済端末に所定間隔を空けてリトライを実行させたのに対して、要求を保留してリトライを実行させることなく、配信権限に空きが生じたら直ちに保留しておいた要求に対する配信を実行する。つまり、最大接続可能数を越える場合でも、最大処理保留数に達するまでは、データ配信の権利が割りあてられるまで接続を保持したまま待機させる。更に、配信権限の解放を、決済処理側でのデータ処理完了（データ配信完了通知）を待つことなく、データ配信完了時点で行うようにしている。
【００６９】
これによって、サーバおよびネットワーク資源を最大限に有効利用可能とすることができ、効率的なデータ配信が行えるのでシステム全体でのデータ配信性能を向上させることができ、以って複数の（特に多数の）決済端末に対するデータ配信処理全体の実行時間を短縮することが可能となる。
【００７０】
上記システムにおいて更に以下に説明する処理を実行するようにしてもよい。
上記システムにおいて、データ配信権限管理部１１は、更に、各対決済端末通信機能部１３毎の配信権限の割当日時と解放日時、および配信したネガリストのデータサイズを記録する。そして、以下の算出式によりデータ配信スループットを算出する。
【００７１】
データ配信スループット ＝ データサイズ ／ （解放日時 − 割当日時）
データ配信権限管理部１１は、更に、過去複数回のデータ配信についての上記データ配信スループットの算出値を用いて、データ配信スループットの平均値を算出して記録する。
【００７２】
データ配信処理保留管理部１２は、任意のとき（例えば任意の対決済端末通信機能部１３が「配信権限要求」を登録してきた際）または定期的に、上記データ配信スループット平均値を参照し、その値で処理保留数テーブルを参照して、該当する最大処理保留数を取得する。そして、この取得した最大処理保留数を新たな最大処理保留数とする（最大処理保留数を更新する）。
【００７３】
ここで、上記処理保留数テーブルの一例を図７に示す。
図示の処理保留数テーブル３０においては、各所定のスループット値範囲を示すスループット３１に対応付けて、最大処理保留数３２（最大処理保留数の候補）が格納されている。
【００７４】
上記の処理では、算出されて記憶されている上記データ配信スループット平均値が該当するスループット３１を求め、これに対応する最大処理保留数３２を取得する。例えば、一例として、上記データ配信スループット平均値＝４．５Ｍbpsであった場合には、スループット３１＝“４Ｍbps〜５Ｍbps”が該当するので、最大処理保留数３２＝‘８０’が取得されて新たな最大処理保留数とすることになる。
【００７５】
この様にする理由は、上記本例のＩＣカードシステムでは、最大処理保留数を越えない限りは決済端末２０にビジーを返さずに要求を保留しておくが、この場合、決済端末２０側では要求に対する応答待ち状態となっており、他の処理（決済端末２０内での内部処理等）を実行することはできず、応答を待ち続けることになる（通常、決済端末２０の処理性能は、一般的なパソコン等と比べても低いものであり、マルチの処理はできない）。
【００７６】
この為、何らかの原因で（例えば他のトラフィックによって）ネットワークスループットが低下している状態で最大処理保留数が多い場合には、待ち時間が非常に長くなる可能性があり、決済端末２０側の処理効率が低下するという問題が生じる。この為、本例では、最大処理保留数の設定値を状況に応じて更新するものとし、上記の通り現在のスループット（上記の例では平均値を用いるがこの例に限らない）に応じた値へと、最大処理保留数を変更することで、上記の問題を解決する。
【００７７】
最後に、図８に、上記サーバ１０（コンピュータ５０）のハードウェア構成の一例を示す。
図８に示すコンピュータ５０は、ＣＰＵ５１、メモリ５２、入力部５３、出力部５４、記憶部５５、記録媒体駆動部５６、及びネットワーク接続部５７を有し、これらがバス５８に接続された構成となっている。
【００７８】
ＣＰＵ５１は、当該コンピュータ５０全体を制御する中央処理装置である。
メモリ５２は、任意の処理実行の際に、記憶部５５（あるいは可搬型記録媒体５９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ５１は、メモリ５２に読み出したプログラム／データを用いて、各種処理を実行する。
【００７９】
出力部５４は、例えばディスプレイ等であり、入力部５３は、例えば、キーボード、マウス等である。
ネットワーク接続部５７は、例えば上記ネットワーク１に接続して、各決済端末２０等との通信（コマンド／データ送受信等）を行う為の構成である。
【００８０】
記憶部５５は、例えばハードディスク等であり、上述した各種処理をＣＰＵ５１により実現させる為のアプリケーションプログラムが格納されている。すなわち、例えば、図１に示す各種管理部１１，１２や通信機能部１３の処理（図２〜図４で説明した処理等）を、ＣＰＵ５１により実現させる為のアプリケーションプログラムが格納されている。また、記憶部５５は、上記データ管理部１４も含むものと考えても良く、ネガリストや処理保留数テーブル３０等も記憶部５５に記憶してもよい。
【００８１】
ＣＰＵ５１は、上記記憶部５５に格納されている各種プログラムを読み出し・実行することにより、上述した各種処理を実現する。
あるいは、上記記憶部５５に格納される各種プログラム／データは、可搬型記録媒体５９に記憶されているものであってもよい。この場合、可搬型記録媒体５９に記憶されているプログラム／データは、記録媒体駆動部５６によって読み出される。可搬型記録媒体５９とは、例えば、ＦＤ（フレキシブル・ディスク）５９ａ、ＣＤ−ＲＯＭ５９ｂ、その他、ＤＶＤ、光磁気ディスク等である。
【００８２】
あるいは、また、上記プログラム／データは、ネットワーク接続部５７により接続しているネットワークを介して、他の装置内に記憶されているものをダウンロードするものであってもよい。あるいは、更に、インターネットを介して、外部の他の装置内に記憶されているものをダウンロードするものであってもよい。
【００８３】
また、本発明は、上記本発明の各種処理をコンピュータ上で実現するプログラムを記録した可搬型記憶媒体として構成できるだけでなく、当該プログラム自体として構成することもできる。
【００８４】
尚、決済端末２０の処理機能は、従来と同じであってよく、特にハードウェア構成を図示・説明しないが、決済端末２０はＣＰＵ、メモリ、通信機能部等を備え、このＣＰＵがこのメモリ（フラッシュメモリ、ＲＯＭ等）に予め記憶されている所定のアプリケーションプログラムを、読出し・実行することにより、上記対サーバ通信機能部２１等の処理を実現する。
【符号の説明】
【００８５】
１ ネットワーク（ＬＡＮ／ＶＰＮ等）
１０ サーバ
１１ データ配信権限管理部
１２ データ転送処理保留管理部
１３ 対決済端末通信機能部
１４ データ管理部
２０ 決済端末
２１ 対サーバ通信機能部
２２ データ管理部
３０ 処理保留数テーブル
３１ スループット
３２ 最大処理保留数
５０ コンピュータ
５１ ＣＰＵ
５２ メモリ
５３ 入力部
５４ 出力部
５５ 記憶部
５６ 記録媒体駆動部
５７ ネットワーク接続部
５８ バス
５９ 可搬型記録媒体
５９ａ ＦＤ（フレキシブル・ディスク）
５９ｂ ＣＤ−ＲＯＭ
【技術分野】
【０００１】
本発明は、複数の決済端末とサーバがネットワークに接続したＩＣカードシステムに関する。
【背景技術】
【０００２】
例えば、非接触ＩＣカード等を利用して電子マネー決済等を実行するシステム（ＩＣカード決済システム）では、任意の決済端末に提示されたＩＣカードが無効カードであるか否かを判定する為に所謂“ネガ情報”を用いている。そして、処理スピード向上のため、ネガ情報を各決済端末で保持している。この為、各決済端末に対して、定期的に、ネガ情報を配信する必要がある。
【０００３】
上記ネガ情報とは、例えば遺失された非接触ＩＣカードの不正使用等を判定する為の情報であり、例えば鉄道関係等で、自動改札機（決済端末に相当）を包含した駅務システムにおいて、定期券として使用されている非接触ＩＣカードが紛失等した場合、ユーザが届け出ることで、この紛失した非接触ＩＣカードの固有番号等が上記ネガ情報としてサーバ等に登録されて、サーバ等から上記各決済端末の一例である各自動改札機等に、ネガ情報が配信されて記憶される。
【０００４】
これにより、各自動改札機は、サーバ等に逐一問い合わせる必要なく（つまり、上記処理スピード向上）、改札通過時に使用されたＩＣカード定期券の固有番号が、ネガ情報のなかにある場合等には、不正使用と判定することができる。但し、新たな紛失等が起こる毎にネガ情報として登録すべき固有番号等が増えていくものであり、各自動改札機が保持するネガ情報を、定期的に更新する必要がある。
【０００５】
上記駅務システムの例はＩＣカード決済システムの一例であり、この例に限らず、ＩＣカード決済システムにおいて、各決済端末にネガ情報（無効カードのカード番号リスト（ネガリスト））を保持させて、各決済端末において提示されたＩＣカードが無効カードであるか否かを判定するようにする場合、例えば定期的にサーバ装置から各決済端末にネットワークを介して最新のネガ情報を配信する必要がある。
【０００６】
ここで、ネガリストは、数万〜数十万件の情報（カード番号等）を含むことがあり、その場合、データサイズは数ＭＢ程度に達する。これに対して、サーバ装置側で旧ネガリストと新ネガリストとの差分（異なる部分；新たに追加された情報や削除された情報）を求めて、この差分データを各決済端末に配信する方法が知られているが、この場合でも、数百ＫＢ程度になる。これは、組込機器である決済端末（処理性能が低い）にとっては小さくないサイズであり、ネットワーク転送には数秒から数十秒を要する。また差分データ配信の場合には、決済端末において受信した差分データと自己が保持していた旧ネガリストとに基づいて最新ネガリストを生成する処理も必要となり、通常、この生成処理を完了したら正常受信できた旨をサーバ装置に通知して、この通知を以って配信処理は終了するので、配信処理全体として非常に時間が掛かるものとなる。
【０００７】
ネガリストを配信するサーバは、多数の決済端末を収容する（ネットワークを介して多数の決済端末の管理する）。これは、数千台から1万台程度になることもありえる。
このようなシステムで、一度に多くの決済端末からサーバへアクセスが集中すると、ネットワークのスループットが悪化し、全ての端末へのネガリスト配信に掛かる時間が非常に長くなってしまう恐れがある。これを防ぐために、サーバで同時接続数を制限し、サーバへの接続数が所定の最大同時接続数に達している状態のときには、新たに接続要求してきた決済端末に対しては、ビジーを返し、その決済端末に所定時間後にリトライさせるのが一般的である。
【０００８】
例えば、特許文献１記載の公知技術では、サーバの混雑具合を端末の接続数によって判断して端末に通知し、端末がデータ配信の中断／再開をおこなうことで制御をしている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００２−３０４３３４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ここで、図９に、決済端末−サーバ間の通信シーケンスの一例を示す。
この通信シーケンスでは、サーバ−決済端末間でデータ配信のためのネゴシエーション（データ配信要求（Ｓ１）→データ配信許可（Ｓ２））を行った後、サーバが決済端末へデータ（ネガリスト（上記の通り差分の場合もある））の配信を行う（Ｓ３）。その後、決済端末は、受信したデータを処理し（データ加工処理（Ｓ４））、結果（成功／失敗）をサーバに通知する（データ配信完了通知（Ｓ５））。このデータ加工処理は、例えば上述した差分データに基づく新ネガリストの生成処理等であるが、この例に限らず、新ネガリストが配信される場合でも何らかの処理が必要となる。上記完了通知を受けたサーバはデータ配信完了応答を返す（Ｓ６）。但し、失敗が通知された場合には、例えば再度データ配信（Ｓ３）を行う。
【００１１】
決済端末において、上記データ加工処理（受信した新ネガリストを既に保持している旧ネガリストとマージし、ソートする等の処理）を実施後、その成否をサーバに通知する、という処理を行うと、このような通信シーケンスになる。
【００１２】
この通信シーケンスでは、データ加工処理（Ｓ４）の間は、決済端末−サーバ間でデータ送受信は行われないが、接続は維持された状態となっている。したがって、従来技術である同時セッション数の制限を適用すると、このデータ加工処理の時間はサーバにとっては無駄な待ち時間となってしまい、またサーバへの接続数が所定の最大同時接続数に達している状態のときには、既にデータ配信は終了しているにも係わらずデータ加工処理が終了するまでは接続解除されないので、サーバは新たに接続要求がきても拒否してリトライさせることになり（図１０、図１１）、システム全体でみたとき、データ配信性能が低下してしまうという課題がある。
【００１３】
尚、上述した従来技術では、ネガリスト配信の場合を例にしたが、上記の問題はこの例に限るものではない。特に配信するデータがネガリストと同様にデータ量が多いものである場合に問題が大きくなる。更に、特に、サーバにアクセスが集中し易い時間帯がある場合にも、上記問題が大きくなる。
【００１４】
図１０、図１１は、従来のデータ配信動作例を示す図である。
図１０、図１１は、何れも、上記最大同時接続数（最大同時セッション数）が３であるものとし、図１０は等間隔アクセスの場合、図１１は同時アクセスの場合の動作例を示す。
【００１５】
図１０、図１１において、配信要求Seq（シーケンス）は、上記図９におけるＴＣＰ接続、データ配信要求（Ｓ１）、データ配信許可（Ｓ２）のシーケンスである。尚、サーバは、「現在の接続数＜上記最大同時接続数」であればデータ配信許可（Ｓ２）を返信するが、そうでなければビジーを返信する。ビジーを返信された決済端末は、所定のリトライ間隔をおいて再度、配信要求Seq（シーケンス）を行う。
【００１６】
サーバは、データ配信許可（Ｓ２）を返信した決済端末に対しては、続いて図示のデータ転送（図９のデータ配信（Ｓ３）に相当）を実行し、これに応じて決済端末は図示のデータ処理（図９のデータ加工処理（Ｓ４）に相当）を実行する。そして、最後に転送完了Seq（図９のデータ配信完了通知（Ｓ５）、データ配信完了応答（Ｓ６）、ＴＣＰ切断）を実行する。この転送完了Seqにおいて、サーバは、「現在の接続数」を更新（−１デクリメント）する。サーバへの接続数が所定の最大同時接続数に達している状態のときには、これによって新たな決済端末にデータ配信可能な状態となる。尚、上記データ配信許可（Ｓ２）を返信した際にも、「現在の接続数」を更新（＋１インクリメント）する。
【００１７】
ここで、図１０と図１１との違いは、図１０では、図示の通り、各決済端末のサーバに対するアクセスタイミング（上記データ配信要求を送るタイミング）が、少しずつズレた場合（これを上記等間隔アクセスというものとする）を例にしている。また、図１１は、図示の通り、上記アクセスタイミングが同時である場合を例にしている。
【００１８】
図１０、図１１に示す通り、何れの場合も、サーバに接続している決済端末の台数（現在の接続数）が最大同時接続数（本例では３台）である状態では、更に他の決済端末がアクセス（配信要求Seq）してきてもサーバは受付けずにビジーを返すので、その決済端末は所定のリトライ間隔を空けて（所定時間後に）再度アクセスすることになる。
【００１９】
この為、現在の接続数（同時接続数）が上記最大同時接続数未満となっても、直ちに新たなデータ配信が行われない場合がある。図１０、図１１に示す例では、端末１、端末２、端末３の全てにおいてデータ配信終了して「現在の接続数」が‘０’になった状態の後でも、しばらくの間は（配信要求Seq受信までは）データ配信処理が行われない。この例は極端にしても、サーバが新たな決済端末にデータ配信可能な状態になっても配信処理が行われない状態となる時間帯は発生するものであり、全体としてのデータ配信効率が悪いものとなる。この為、このサーバがデータ配信すべき全ての決済端末にデータ配信を行えるまでに、非常に時間が掛かることになる。つまり、サーバおよびネットワーク資源を有効利用できず、システム全体でのデータ配信性能が悪いものとなる。
【００２０】
具体的な状況として、例えば上記ネガリストを例にすると、様々な店舗等に設置された多数の決済端末が、毎日、所定の時間帯（例えば、朝の開店前の所定時間帯等）にサーバにアクセスしてネガリスト（または差分）の配信を受けることで、毎日、最新のネガリストを保持している状態で運用開始する状況等がある。この例の場合、各決済端末は、ネガリストの更新を、その店舗の開店に間に合うように行う必要がある。
【００２１】
ここで、一般的に、２４時間営業の店舗等を除くと、店舗の開店時間は１０時近辺である場合が多い。この為、多数の決済端末がほぼ一斉にサーバにアクセスすることが起こり得る（図１１の例）。これを避ける為に、各決済端末のサーバへのアクセスタイミングが少しずつズレるように予め設定しておくことも考えられる（図１０の例）。しかしながら、上記図１０、図１１で説明した通り、何れの場合でも、ネガリストのデータ量が大きい為（差分を送信する場合にはデータ加工処理に時間が掛かる為）に各決済端末それぞれに対するデータ配信処理に時間が掛かることもあって、アクセスしてもサーバに接続できない（拒否される）決済端末が多数発生する場合があり得る。
【００２２】
サーバに接続できなかったサーバは、リトライを行うが、上記の状況では多数の決済端末がリトライを行うことになり、リトライ時にもアクセスが集中していて接続できず、更にリトライを行うことになることも起こり得る。この様にリトライを繰り返し、ネガリスト取得までに非常に時間が掛かることになると、開店時間に間に合わない可能性がある。これは、サーバ側にとっては、ネガリストを配信すべき全ての決済端末にネガリストを配信するまでに掛かる時間（全体としてのデータ配信処理に掛かる時間）が非常に長くなることになり、一部の決済端末に関しては実質的に配信が間に合わない事態に陥ることになる。
【００２３】
アクセスを分散できれば、通信量が制限される回線を効率的に使えるので、スループットが高くなり、所定時間内にネガリストを更新できる。しかし、アクセスが集中すれば、通信に使われない時間帯が生じるため、効率的な通信を行えずにスループットが低下し、所定時間内にネガリストを更新できないことが起こり得る。
【００２４】
本発明の課題は、複数の決済端末とサーバがネットワークに接続したＩＣカードシステムに係わり、サーバおよびネットワーク資源を最大限に有効利用可能とすることで、システム全体でのデータ配信性能を向上させることができるＩＣカードシステム、そのサーバ装置、プログラム等を提供することである。
【課題を解決するための手段】
【００２５】
本発明のＩＣカードシステムは、複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムであって、前記ＩＣカード決済端末は、任意のときに又は定期的に、前記サーバ装置に対して前記ネットワークを介して、所定のデータの配信要求を送信して、該サーバ装置にデータ配信を行わせ、該配信されたデータに対して所定のデータ処理を実行後、前記サーバ装置に対して完了通知を送信するデータ取得手段を有し、前記サーバ装置は、データ配信処理の同時実行数に対する上限値を示す第１の閾値を記憶する閾値記憶手段と、前記配信要求を受信する毎に、現在の前記同時実行数が前記第１の閾値に達していない限りは該配信要求に応じてデータ配信を開始し、前記同時実行数が前記第１の閾値に達している場合には、該受信した配信要求を保留し、任意の決済端末に対する前記データ配信が完了したら前記完了通知を待つことなく前記保留してある配信要求に応じたデータ配信を開始するデータ配信制御手段とを有する。
【００２６】
上記構成のＩＣカードシステムでは、現在の同時実行数が第１の閾値に達している状態で新たな配信要求を受信した場合、従来では要求拒否して所定時間後のリトライを行わせたのに対して、当該配信要求を保持しておく。これにより、任意のＩＣカード決済端末に対するデータ配信が完了して同時実行数が第１の閾値未満となり新たな配信が可能な状況になったら、直ちに、保留してある配信要求に応じてデータ配信を開始できる。
【００２７】
従来では、新たな配信が可能な状況になってもリトライ等により新たな配信要求が来るまでは、データ配信が開始できず、データ配信の効率が悪いものであったが、本発明ではデータ配信の効率がよく、全体でのデータ配信性能を向上させることができる（全体でのデータ配信に掛かる時間を短縮できる。
【００２８】
また、本発明では、従来のように完了通知を待つことなく、データ配信終了した時点で次のデータ配信開始が可能となっており、更にデータ配信の効率がよく、全体でのデータ配信性能を更に向上させることができる。
【００２９】
この様に、本発明では、サーバ装置において新たなデータ配信が可能な状態であるにも係わらず新たなデータ配信が開始されずに待ち状態となる期間を、従来に比べて非常に短くすることができ、複数のＩＣカード決済端末全体に対するデータ配信効率が向上し、複数のＩＣカード決済端末全てに対してデータ配信完了するまでの時間を短くすることができる。
【００３０】
また、上記ＩＣカードシステムにおいて、例えば更に、前記閾値記憶手段には更に前記配信要求の保留数に対する上限値を示す第２の閾値が記憶され、前記データ配信制御手段は、現在の前記配信要求保留数が前記第２の閾値に達している場合には、前記受信した配信要求を保留せずに、該配信要求の送信元のＩＣカード決済端末に対して要求拒否を通知することで該ＩＣカード決済端末に所定時間後のリトライを実行させるようにしてもよい。
【００３１】
配信要求の保留を無制限に行うと、場合によっては配信要求保留数が非常に多数となり、要求元のＩＣカード決済端末の応答待ち時間が非常に長くなる可能性があるので、第２の閾値により配信要求保留数を制限する。
【００３２】
また、例えば、上記第２の閾値自体を、状況に応じて適切な値へと変更するようにしてもよい。すなわち、上記ＩＣカードシステムにおいて、例えば更に、予め各スループットに対応付けて任意の各第２の閾値候補を記憶する第２の閾値候補記憶手段と、前記各決済端末に対する各データ配信に係わるスループットを算出し、該算出したスループットに基づいて前記第２の閾値候補記憶手段から該当する第２の閾値候補を取得してこれを新たな前記第２の閾値として前記閾値記憶手段に記憶する第２の閾値更新手段を有するように構成してもよい。
【００３３】
これによって、現在のスループットに応じた適切な第２の閾値が設定されることになり、例えば現在のスループットが低く配信処理時間が掛かるにも係わらず、多数の配信要求が保留されている状態になり、その為に保留されている時間（決済端末側にとっては要求に対する応答（配信）待ち時間）が非常に長くなるという事態にはならないことになる。
【発明の効果】
【００３４】
本発明のＩＣカードシステム、そのサーバ装置、プログラム等によれば、複数の決済端末とサーバがネットワークに接続したＩＣカードシステムに係わり、サーバおよびネットワーク資源を最大限に有効利用可能とすることで、システム全体でのデータ配信性能を向上させることができる。
【図面の簡単な説明】
【００３５】
【図１】本例のＩＣカードシステムの構成例を示す図である。
【図２】データ配信時の通信シーケンスの一例（その１）を示す図である。
【図３】データ配信時の通信シーケンスの一例（その２）を示す図である。
【図４】データ配信時の通信シーケンスの一例（その３）を示す図である。
【図５】等間隔アクセスの場合のデータ配信動作例を示す図である。
【図６】同時アクセスの場合のデータ配信動作例を示す図である。
【図７】処理保留数テーブルの一例を示す図である。
【図８】コンピュータ・ハードウェア構成図である。
【図９】決済端末−サーバ間の通信シーケンスの一例を示す図である。
【図１０】従来の等間隔アクセスの場合のデータ配信動作例を示す図である。
【図１１】従来の同時アクセスの場合のデータ配信動作例を示す図である。
【発明を実施するための形態】
【００３６】
以下、図面を参照して本発明の実施の形態について説明する。
尚、以下の説明では上記従来技術に従ってネガリスト配信の場合を例にするが、本発明はネガリスト配信の場合に限るものではなく、配信するデータは基本的には何でもよい。但し、配信するデータがネガリストと同様にデータ量が大きなものである場合に（更に多数の決済端末からデータ配信サーバへアクセスが集中する場合に）、本発明は特に顕著な効果を奏する。上記ネガリスト以外の例としては、例えば、決済端末のファームウェアをオンラインで更新する場合におけるデータ配信サーバからネットワークを介して各決済端末に配信される当該ファームウェア等が考えられる。勿論、この例に限るものではない。
【００３７】
図１に、本例のＩＣカードシステムの構成例を示す。
図示のシステムでは、多数の決済端末２０とサーバ１０が、例えばＬＡＮ／ＶＰＮ（Virtual Private Network；仮想プライベートネットワーク）等であるネットワーク１に接続しており、ネットワーク１を介して相互に通信可能である。特に、サーバ１０は、各決済端末２０からの要求に応じて、任意のデータを配信するものである。
【００３８】
サーバ１０は、データ配信権限管理部１１、データ転送処理保留管理部１２、対決済端末通信機能部１３、及びデータ管理部１４を有する。
また、決済端末２０は、対サーバ通信機能部２１、データ管理部２２を有する。対サーバ通信機能部２１は、ネットワーク１を介してサーバ１０に接続して、例えば上記図９で説明したデータ配信を受ける為の処理（データ配信要求送信や配信されたデータの加工処理等）を行う機能処理部である。また、データ管理部２２は例えば配信されたネガリストや上記対サーバ通信機能部２１の処理機能を不図示のＣＰＵにより実行させる為の所定のアプリケーションプログラム等を記憶するメモリ等である。図示していないが、勿論、ネガリストを用いてＩＣカード決済処理を行う機能部等の他の各種機能部も存在するが、何れにしても決済端末２０の構成・処理機能自体は、従来と同じであってよく、ここでは特に説明しない。
【００３９】
ここで、サーバ１０に関して、上記図１に示す各構成要素（データ配信権限管理部１１、データ転送処理保留管理部１２、対決済端末通信機能部１３から成る構成）及びこれらによる後述する図２〜図４等の処理は、一例を示すものであり、この例に限るものではない。
【００４０】
サーバ１０の処理機能は、概略的には、データ配信処理の同時実行数に対する上限値を示す第１の閾値を登録しておき、任意の決済端末２０からの配信要求を受信する毎に、現在の上記同時実行数が上記第１の閾値に達していない限りはこの配信要求に応じてデータ配信を開始し、上記同時実行数が上記第１の閾値に達している場合には、受信した配信要求を保留し、任意の決済端末２０に対するデータ配信が完了したらこの決済端末２０からの完了通知を待つことなく保留してある配信要求に応じたデータ配信を開始するものである。従来では、現在の上記同時実行数が上記第１の閾値に達している場合には、要求元の決済端末２０にビジー応答等を返信することで所定時間後のリトライを実行させたが、上述してある問題が生じる。これに対して、本例のサーバ１０では、この様な場合でもビジー応答等を返信せずに受信した配信要求を保留しておくことで（更に完了通知を待たないことで）、この問題を解消できる。
【００４１】
また、サーバ１０の概略的な処理機能としては、例えば更に、配信要求の保留数に対する上限値を示す第２の閾値を更に登録しておき、現在の配信要求保留数が第２の閾値に達している場合には、受信した配信要求を保留せずに、ビジー応答等を返信するようにしてもよい。つまり、配信要求の保留数に制限を設けるようにしてもよい。配信要求の保留を無制限に行うと、場合によっては配信要求保留数が非常に多数となり、要求元の決済端末２０の応答待ち時間が非常に長くなる可能性があるので、第２の閾値により配信要求保留数を制限する。また、例えば、第２の閾値自体を、状況に応じて適切な値へと変更するようにしてもよい（後述する現在のスループットに応じた第２の閾値の設定変更等）。
【００４２】
以下、上記サーバ１０の構成、処理の一例としての上記各構成要素１１〜１３等について、説明する。尚、この例では、後述するように配信権限要求の保留とその保留数の管理等を行うものとなるが、これは実質的には上記配信要求の保留とその保留数の管理等と同じことである。また、尚、以下の説明における最大配信権限数が上記第１の閾値の一例であり、最大処理保留数が上記第２の閾値の一例である。
【００４３】
データ配信権限管理部１１は、決済端末２０へのデータ配信を同時にいくつまで実施するか（最大配信権限数；最大接続可能数とも言う）を管理・制御する。本説明の例では、最大配信権限数を３として管理するものとする。データ配信処理保留管理部１２は、決済端末２０からのデータ配信要求をいくつまで要求を拒否せずに処理保留として保持するかを制御する。本説明の例では最大処理保留数を１０とする。
【００４４】
尚、上記概略的な説明で示す通り、最大処理保留数による保留数の制限は、必ずしも必須のものではない。よって、受信したデータ配信要求は制限無しで全て保留するようにしてもよい。
【００４５】
尚、最大配信権限数は、例えばネットワーク帯域幅や決済端末２０の通信性能等に応じて設計者等が予め適切と思われる値を決定して記憶させておくものである。
対決済端末通信機能部１３は、決済端末２０との通信を行ってコマンド／データ送受信を行う機能部である（特にネガデータ配信要求の受信とこれに応じたネガデータの配信処理）。
【００４６】
尚、図では対決済センタ通信機能部１３を複数示しているが、これは、複数の決済端末２０に対して同時にＴＣＰコネクションを張って通信可能なことを示している。つまり、複数の対決済センタ通信機能部１３は、それぞれが任意の１つの決済端末２０に対するＴＣＰコネクションを受け持つスレッド等と考えてよい。別の言い方をすれば、サーバ１０には例えば上記複数の対決済センタ通信機能部１３を包含するプロセスがあり、個々の対決済センタ通信機能部１３はこのプロセス内におけるスレッド動作と見做すこともできる。
【００４７】
データ管理部１４は、例えばハードディスク等の記憶装置であり、例えば配信すべき新ネガ情報（あるいは差分を配信する場合には、新ネガ情報だけでなく旧ネガ情報等も保持しており、これらのよって生成した差分データも格納される）や、後述する図７のテーブル情報等が格納される。
【００４８】
尚、上記データ配信権限管理部１１、データ転送処理保留管理部１２、対決済端末通信機能部１３は、ここでは図示しないサーバ１０のＣＰＵ等が、記憶装置（ハードディスク等）に予め記憶されている所定のアプリケーションプログラムを読出し・実行することにより実現される処理機能部である。
【００４９】
図２、図３、図４に、サーバ１０から決済端末２０へのデータ配信時の通信シーケンスの一例を示す。図２は配信権限に空きがある場合、図３は配信権限に空きが無かった場合、図４は処理保留数が閾値を越えている場合の通信シーケンスを示している。
【００５０】
尚、図２〜図４において、図９に示した各処理（Ｓ１〜Ｓ６）と同じ処理には同一符号を付してある。
まず、図２〜図４の何れにおいても、各決済端末２０は、サーバ１０に何らかの要求を行う場合には、まず、サーバ１０の任意の対決済端末通信機能部１３とＴＣＰ接続確立後、「データ配信要求」を送信する（Ｓ１）。このデータ配信要求を受けた対決済端末通信機能１３は、このデータ配信要求を保持すると共に、データ配信処理保留管理部１２に対して配信権限の要求コマンド（配信権限要求）の登録を依頼する（Ｓ１１）。
【００５１】
データ配信処理保留管理部１２は、既に登録済みの「配信権限要求」の数（処理保留数）が、処理保留閾値（最大処理保留数）に達しているか否かを判定し、達していない場合のみ登録依頼を受け付けて当該新たな「配信権限要求」を記憶する。図２、図３は処理保留数が閾値に達していない場合を示している。
【００５２】
一方、図４は、処理保留数が最大処理保留数に達していた場合（空きがない場合）を示してあり、この場合には図４に示すようにデータ配信処理保留管理部１２は、要求元の対決済端末通信機能１３に対して「配信拒否」を返す（Ｓ１５）。これより、対決済端末通信機能１３は「データ配信ビジー応答」を要求元の決済端末２０へ返信して（Ｓ７）通信を終了する（ＴＣＰ切断）。これにより、この要求元の決済端末２０は、所定時間後にリトライすることになる。
【００５３】
尚、図４は、処理保留数が最大処理保留数に達している場合の処理例を示すものである為、データ配信権限管理部１１の処理は、図示していないが、随時、以下に説明する図２、図３と同様の処理を行っている。
【００５４】
以下、図２、図３を参照して、主にデータ配信権限管理部１１に係わる処理について説明する。
図２に示すように、データ配信権限管理部１１は、配信権限に空きがある場合、すなわち配信権限を割り当てている対決済端末通信機能１３の数（権限割当数；つまり同時実行数／同時接続数）が、上記最大配信権限数（＝３）に達していない場合には、随時、データ配信処理保留管理部１２を監視し、「配信権限要求」が保持されているか否かをチェックする。そして、保持されている場合には「配信権限要求」を取得する（Ｓ１２）。尚、複数の「配信権限要求」が保持されている場合には、そのなかで最も古い（最初に保持された）「配信権限要求」を取得する。尚、データ配信処理保留管理部１２は、例えば、ＦＩＦＯ（First-In/First-out）メモリ（キュー）に「配信権限要求」を格納する。よって、データ配信権限管理部１１が「配信権限要求」を取り出す際には自動的に最も古いものが取り出されることになる。
【００５５】
そして、取得した「配信権限要求」を出した対決済端末通信機能部１３に対して配信権限を割り当てる（Ｓ１３）。尚、例えば、「配信権限要求」にはその「配信権限要求」を出した対決済端末通信機能部１３を識別できる情報（ＩＤ等）が含まれている。
【００５６】
また、これより、データ配信処理保留管理部１２は、上記処理保留数を更新する（処理保留数＝処理保留数−１）。また、データ配信権限管理部１１は、上記「権限割当数」を更新し（権限割当数＝権限割当数＋１）、当該更新後の権限割当数に関して、再び上記の配信権限に空きがあるか否かの判定を行い、この判定結果に応じた処理を行う。もし、配信権限に空きがあり、更に保留管理部１２に保持されている「配信権限要求」がある場合には、上記と同様に、この「配信権限要求」を取得して配信権限を割り当てる処理を実行することになる。
【００５７】
上記配信権限を割り当てられた対決済端末通信機能部１３は、上記保持しておいたデータ配信要求に応じて、その送信元の決済端末２０に対するデータ配信を実施し（Ｓ３）、データ配信完了後にデータ配信権限管理部１１に対して配信権限解放を通知する（Ｓ１４）。これに応じて、データ配信権限管理部１１は、上記「権限割当数」を更新し（権限割当数＝権限割当数−１）、これによって配信権限に空きがある状態になることから、上記データ配信処理保留管理部１２を監視する処理を行うことになる。
【００５８】
尚、図２に示すように、上記データ配信を受けた決済端末２０は、従来と同様、データ加工処理（Ｓ４）を行い、処理完了したら対決済端末通信機能部１３に対してデータ配信完了通知（Ｓ５）を送信し、これに応じて対決済端末通信機能部１３からデータ配信完了応答（Ｓ６）が送られてきたら、ＴＣＰ切断し、通信を終了する。
【００５９】
上記の通り、本手法では、データ配信した決済端末２０からの上記データ配信完了通知を待つことなく、データ配信完了した時点で配信権限が解放されるので、上記の通り「権限割当数」が更新され、保持されている「配信権限要求」がある場合には、この時点で配信権限を割り当ててデータ配信処理開始することができる。よって、データ配信完了通知を待つ時間が無い分、データ配信効率が向上し、データ配信を必要とする決済端末２０全体でのデータ配信時間が短縮されることになる。
【００６０】
また、「配信権限要求」を保持しない場合、データ配信完了した時点で配信権限が解放されて新たな決済端末２０にデータ配信が可能となっても、任意の決済端末２０から（リトライ等により）「データ配信要求」が送られてくるまではデータ配信が行えないことになり、無駄な待機時間が生じることになる。これに対して、本手法では上記の通り「配信権限要求」を保持するので、この点でも無駄な待機時間が無い分、データ配信効率が向上し、全体でのデータ配信時間が短縮されることになる。
【００６１】
尚、上記の通り、データ配信完了通知を待たないことから、配信したデータを決済端末２０が正常に受信できたかは不明である。また、正常受信できた場合でもデータ加工処理において何らかのエラーが生じる可能性がある。この場合、決済端末２０は、データ配信完了通知の代わりに不図示のエラー通知を送信し、これに対してサーバ１０は不図示のエラー確認応答を返信する等して、ＴＣＰ切断を行う。そして、この場合には、決済端末２０はリトライを行うことになる。
【００６２】
一方、図３に示すように、データ配信権限管理部１１は、配信権限に空きがない場合、配信権限を割当済みの対決済端末通信機能部１３の何れかが配信権限を解放するのを待つ。そして、配信権限が解放されると、配信権限に空きがある状態になることから、上記の図２で説明した処理を行う。すなわち、データ配信処理保留管理部１２を監視し、「配信権限要求」が登録されていれば、その「配信権限要求」を登録した対決済端末通信機能部１３に対して配信権限を割り当てる。その後は図２で説明した通りであり、ここでは特に説明しない。
【００６３】
尚、既に述べてあるように、上記保留管理部１２における“「配信権限要求」の保持・管理”は、実質的に“「データ配信要求」の保持・管理”と同義である。上記の説明では、一例として、データ配信権限管理部１１に対する配信権限割当ての管理として説明したが、この例に限るものではない。本手法は、本質的には、従来では同時接続数の制限により新たな「データ配信要求」に対して拒否してリトライさせるような状態であっても、拒否せずに「データ配信要求」を保持しておき（但し、保持数にも上限を設ける；最大処理保留数）、配信権限に空きが生じたら（同時接続数が最大配信権限数未満となったら）、直ちに、保持している「データ配信要求」に応じてデータ配信が行えるようにすることで（更にデータ配信完了通知を待たないようにすることで）、データ配信可能であるにも係わらず配信できない状態となる時間（無駄な時間）の削減を実現でき、全体としてのデータ配信効率を向上させ、システム全体としてのデータ配信処理時間を短縮することができるものである。
【００６４】
この実施例によって決済端末８台に対してネガリスト配信をおこなった場合の例を図５、図６に示す。尚、図５、図６に示す配信要求Seq（シーケンス）、転送完了Seq（シーケンス）の意味は、上記図１０、図１１で説明した通りである。
【００６５】
図５は上記図１０に対応するもの（すなわち、等間隔アクセスの場合）、図６は上記図１１に対応するもの（すなわち、同時アクセスの場合）である。この例では、最大同時接続数は図１０、図１１等と同じく‘３’であるものとし、最大処理保留数は例えば‘５’であるものとする。よって、端末４〜端末８は何れもその配信権限要求が保留されることになり、リトライを行う必要はなく、配信権限待ち状態を経て、配信権限に空きが生じたら直ちにデータ転送が行われることになる。よって、無駄な待機時間が生じることなく、切れ目無くデータ転送を行うことが可能となり、効率的なデータ転送が行える。
【００６６】
また、本手法では上記の通り、配信先の決済端末２０からのデータ配信完了通知を待つことなく、データ配信完了した時点で配信権限解放を行うので、図示の通り例えば端末４に関しては、端末１へのデータ転送が完了した時点で配信権限が割り当てられ、データ転送開始することになる。従来では、端末１へのデータ転送が完了しても「転送完了Seq」までの間は端末４へのデータ転送が開始されないので、非効率であったが、本手法ではこの様な無駄な待ち時間が生じることなく、切れ目無くデータ転送を行うことが可能となり、効率的なデータ転送が行える。
【００６７】
以上、本手法によれば、図５、図６などに示すように、サーバ１０は、決済端末２０からのアクセスが集中した場合でも、データ配信を、権限割当数が最大配信権限数（＝３）の状態のまま切れ目無く実施することが可能となる。すなわち、サーバおよびネットワーク資源を最大限に有効利用することができ、この結果、アクセス集中時もネットワークトラフィックを一定以下に保ちつつ、サーバからのデータ配信のスループットを最大にすることができる。
【００６８】
通信セッションにおいて、データ転送が間欠的に発生するような通信形態において、サーバから決済端末へのデータ転送スループットを高く保つことが可能になる。
以上説明したように、本例のＩＣカードシステムによれば、複数の（特に多数の）決済端末にデータ量が大きいデータ（ネガリスト等）を配信するサーバ装置を有するシステムにおいて、特にアクセス集中する状況である為に決済端末からの接続数が最大接続可能数を越える場合に、従来ではビジー応答して決済端末に所定間隔を空けてリトライを実行させたのに対して、要求を保留してリトライを実行させることなく、配信権限に空きが生じたら直ちに保留しておいた要求に対する配信を実行する。つまり、最大接続可能数を越える場合でも、最大処理保留数に達するまでは、データ配信の権利が割りあてられるまで接続を保持したまま待機させる。更に、配信権限の解放を、決済処理側でのデータ処理完了（データ配信完了通知）を待つことなく、データ配信完了時点で行うようにしている。
【００６９】
これによって、サーバおよびネットワーク資源を最大限に有効利用可能とすることができ、効率的なデータ配信が行えるのでシステム全体でのデータ配信性能を向上させることができ、以って複数の（特に多数の）決済端末に対するデータ配信処理全体の実行時間を短縮することが可能となる。
【００７０】
上記システムにおいて更に以下に説明する処理を実行するようにしてもよい。
上記システムにおいて、データ配信権限管理部１１は、更に、各対決済端末通信機能部１３毎の配信権限の割当日時と解放日時、および配信したネガリストのデータサイズを記録する。そして、以下の算出式によりデータ配信スループットを算出する。
【００７１】
データ配信スループット ＝ データサイズ ／ （解放日時 − 割当日時）
データ配信権限管理部１１は、更に、過去複数回のデータ配信についての上記データ配信スループットの算出値を用いて、データ配信スループットの平均値を算出して記録する。
【００７２】
データ配信処理保留管理部１２は、任意のとき（例えば任意の対決済端末通信機能部１３が「配信権限要求」を登録してきた際）または定期的に、上記データ配信スループット平均値を参照し、その値で処理保留数テーブルを参照して、該当する最大処理保留数を取得する。そして、この取得した最大処理保留数を新たな最大処理保留数とする（最大処理保留数を更新する）。
【００７３】
ここで、上記処理保留数テーブルの一例を図７に示す。
図示の処理保留数テーブル３０においては、各所定のスループット値範囲を示すスループット３１に対応付けて、最大処理保留数３２（最大処理保留数の候補）が格納されている。
【００７４】
上記の処理では、算出されて記憶されている上記データ配信スループット平均値が該当するスループット３１を求め、これに対応する最大処理保留数３２を取得する。例えば、一例として、上記データ配信スループット平均値＝４．５Ｍbpsであった場合には、スループット３１＝“４Ｍbps〜５Ｍbps”が該当するので、最大処理保留数３２＝‘８０’が取得されて新たな最大処理保留数とすることになる。
【００７５】
この様にする理由は、上記本例のＩＣカードシステムでは、最大処理保留数を越えない限りは決済端末２０にビジーを返さずに要求を保留しておくが、この場合、決済端末２０側では要求に対する応答待ち状態となっており、他の処理（決済端末２０内での内部処理等）を実行することはできず、応答を待ち続けることになる（通常、決済端末２０の処理性能は、一般的なパソコン等と比べても低いものであり、マルチの処理はできない）。
【００７６】
この為、何らかの原因で（例えば他のトラフィックによって）ネットワークスループットが低下している状態で最大処理保留数が多い場合には、待ち時間が非常に長くなる可能性があり、決済端末２０側の処理効率が低下するという問題が生じる。この為、本例では、最大処理保留数の設定値を状況に応じて更新するものとし、上記の通り現在のスループット（上記の例では平均値を用いるがこの例に限らない）に応じた値へと、最大処理保留数を変更することで、上記の問題を解決する。
【００７７】
最後に、図８に、上記サーバ１０（コンピュータ５０）のハードウェア構成の一例を示す。
図８に示すコンピュータ５０は、ＣＰＵ５１、メモリ５２、入力部５３、出力部５４、記憶部５５、記録媒体駆動部５６、及びネットワーク接続部５７を有し、これらがバス５８に接続された構成となっている。
【００７８】
ＣＰＵ５１は、当該コンピュータ５０全体を制御する中央処理装置である。
メモリ５２は、任意の処理実行の際に、記憶部５５（あるいは可搬型記録媒体５９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ５１は、メモリ５２に読み出したプログラム／データを用いて、各種処理を実行する。
【００７９】
出力部５４は、例えばディスプレイ等であり、入力部５３は、例えば、キーボード、マウス等である。
ネットワーク接続部５７は、例えば上記ネットワーク１に接続して、各決済端末２０等との通信（コマンド／データ送受信等）を行う為の構成である。
【００８０】
記憶部５５は、例えばハードディスク等であり、上述した各種処理をＣＰＵ５１により実現させる為のアプリケーションプログラムが格納されている。すなわち、例えば、図１に示す各種管理部１１，１２や通信機能部１３の処理（図２〜図４で説明した処理等）を、ＣＰＵ５１により実現させる為のアプリケーションプログラムが格納されている。また、記憶部５５は、上記データ管理部１４も含むものと考えても良く、ネガリストや処理保留数テーブル３０等も記憶部５５に記憶してもよい。
【００８１】
ＣＰＵ５１は、上記記憶部５５に格納されている各種プログラムを読み出し・実行することにより、上述した各種処理を実現する。
あるいは、上記記憶部５５に格納される各種プログラム／データは、可搬型記録媒体５９に記憶されているものであってもよい。この場合、可搬型記録媒体５９に記憶されているプログラム／データは、記録媒体駆動部５６によって読み出される。可搬型記録媒体５９とは、例えば、ＦＤ（フレキシブル・ディスク）５９ａ、ＣＤ−ＲＯＭ５９ｂ、その他、ＤＶＤ、光磁気ディスク等である。
【００８２】
あるいは、また、上記プログラム／データは、ネットワーク接続部５７により接続しているネットワークを介して、他の装置内に記憶されているものをダウンロードするものであってもよい。あるいは、更に、インターネットを介して、外部の他の装置内に記憶されているものをダウンロードするものであってもよい。
【００８３】
また、本発明は、上記本発明の各種処理をコンピュータ上で実現するプログラムを記録した可搬型記憶媒体として構成できるだけでなく、当該プログラム自体として構成することもできる。
【００８４】
尚、決済端末２０の処理機能は、従来と同じであってよく、特にハードウェア構成を図示・説明しないが、決済端末２０はＣＰＵ、メモリ、通信機能部等を備え、このＣＰＵがこのメモリ（フラッシュメモリ、ＲＯＭ等）に予め記憶されている所定のアプリケーションプログラムを、読出し・実行することにより、上記対サーバ通信機能部２１等の処理を実現する。
【符号の説明】
【００８５】
１ ネットワーク（ＬＡＮ／ＶＰＮ等）
１０ サーバ
１１ データ配信権限管理部
１２ データ転送処理保留管理部
１３ 対決済端末通信機能部
１４ データ管理部
２０ 決済端末
２１ 対サーバ通信機能部
２２ データ管理部
３０ 処理保留数テーブル
３１ スループット
３２ 最大処理保留数
５０ コンピュータ
５１ ＣＰＵ
５２ メモリ
５３ 入力部
５４ 出力部
５５ 記憶部
５６ 記録媒体駆動部
５７ ネットワーク接続部
５８ バス
５９ 可搬型記録媒体
５９ａ ＦＤ（フレキシブル・ディスク）
５９ｂ ＣＤ−ＲＯＭ
【特許請求の範囲】
【請求項１】
複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムであって、
前記ＩＣカード決済端末は、任意のときに又は定期的に、前記サーバ装置に対して前記ネットワークを介して、所定のデータの配信要求を送信して、該サーバ装置にデータ配信を行わせ、該配信されたデータに対して所定のデータ処理を実行後、前記サーバ装置に対して完了通知を送信するデータ取得手段を有し、
前記サーバ装置は、
データ配信処理の同時実行数に対する上限値を示す第１の閾値を記憶する閾値記憶手段と、
前記配信要求を受信する毎に、現在の前記同時実行数が前記第１の閾値に達していない限りは該配信要求に応じてデータ配信を開始し、前記同時実行数が前記第１の閾値に達している場合には、該受信した配信要求を保留し、任意の決済端末に対する前記データ配信が完了したら前記完了通知を待つことなく前記保留してある配信要求に応じたデータ配信を開始するデータ配信制御手段と、
を有することを特徴とするＩＣカードシステム。
【請求項２】
前記閾値記憶手段には更に前記配信要求の保留数に対する上限値を示す第２の閾値が記憶され、
前記データ配信制御手段は、現在の前記配信要求保留数が前記第２の閾値に達している場合には、前記受信した配信要求を保留せずに、該配信要求の送信元のＩＣカード決済端末に対して要求拒否を通知することで該ＩＣカード決済端末に所定時間後のリトライを実行させることを特徴とする請求項１記載のＩＣカードシステム。
【請求項３】
予め各スループットに対応付けて任意の各第２の閾値候補を記憶する第２の閾値候補記憶手段と、
前記各決済端末に対する各データ配信処理に係わるスループットを算出し、該算出したスループットに基づいて前記第２の閾値候補記憶手段から該当する第２の閾値候補を取得してこれを新たな前記第２の閾値とする第２の閾値更新手段と、
を更に有することを特徴とする請求項１または２記載のＩＣカードシステム。
【請求項４】
複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムであって、
前記ＩＣカード決済端末は、任意のときに又は定期的に、前記サーバ装置に対して前記ネットワークを介して、所定のデータの配信要求を送信して、該サーバ装置にデータ配信を行わせ、該配信されたデータに対して所定のデータ処理を実行後、前記サーバ装置に対して完了通知を送信するデータ取得手段を有し、
前記サーバ装置は、
前記配信要求を送信してくる各ＩＣカード決済端末それぞれに対応する各通信手段であって、自己が受信した前記配信要求に応じてデータ配信処理を行う為の配信権限を要求する配信権限要求をデータ配信処理保留管理手段に渡し、その後は配信権限が割り当てられるまで待機し、配信権限が割り当てられるとそのＩＣカード決済端末へのデータ配信処理を開始し、該データ配信処理を完了したら前記完了通知を待つことなく前記配信権限を解放する対決済端末通信手段と、
任意の前記対決済端末通信手段から前記配信権限要求が渡される毎に、該渡された配信権限要求を追加保留する前記データ配信処理保留管理手段と、
データ配信処理の同時実行数に対する上限値を示す第１の閾値に基づいて、現在の前記同時実行数が該第１の閾値に達していない場合、前記データ配信処理保留管理手段に前記配信権限要求が保留されている場合には該配信権限要求を取得して該配信権限要求に対応する対決済端末通信手段に前記配信権限を割り当てて前記データ配信処理を開始させ、また該配信権限の割り当て又は前記配信権限の解放に応じて前記同時実行数を更新するデータ配信権限管理手段と、
を有することを特徴とするＩＣカードシステム。
【請求項５】
前記データ配信処理保留管理手段は、前記配信権限要求の保留数に対する上限値を示す第２の閾値に基づいて、任意の前記対決済端末通信手段から前記配信権限要求が渡される毎に、現在の前記配信権限要求保留数が該第２の閾値に達している場合には、該渡された配信権限要求を保留することなくその対決済端末通信手段に配信拒否応答を返信し、第２の閾値に達していない場合には該渡された配信権限要求を追加保留し、
前記対決済端末通信手段は、前記データ配信処理保留管理手段から前記配信拒否応答があった場合には、自己が対応するＩＣカード決済端末にビジー応答を返信することで該ＩＣカード決済端末に所定時間後のリトライを実行させることを特徴とする請求項４記載のＩＣカードシステム。
【請求項６】
複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムにおける前記サーバ装置であって、
データ配信処理の同時実行数に対する上限値を示す第１の閾値を記憶する閾値記憶手段と、
任意の前記ＩＣカード決済端末からの配信要求を受信する毎に、現在の前記同時実行数が前記第１の閾値に達していない限りは該配信要求に応じてデータ配信を開始し、前記同時実行数が前記第１の閾値に達している場合には、該受信した配信要求を保留し、任意の決済端末に対する前記データ配信が完了したら、配信先のＩＣカード決済端末からの完了通知を待つことなく、前記同時実行数を更新して前記保留してある配信要求に応じたデータ配信開始を可能とするデータ配信制御手段と、
を有することを特徴とするＩＣカードシステムのサーバ装置。
【請求項７】
複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムにおける前記サーバ装置のコンピュータを、
データ配信処理の同時実行数に対する上限値を示す第１の閾値を記憶する閾値記憶手段と、
任意の前記ＩＣカード決済端末からの配信要求を受信する毎に、現在の前記同時実行数が前記第１の閾値に達していない限りは該配信要求に応じたデータ配信を開始し、前記同時実行数が前記第１の閾値に達している場合には、該受信した配信要求を保留し、任意の決済端末に対する前記データ配信が完了したら、配信先のＩＣカード決済端末からの完了通知を待つことなく、前記同時実行数を更新して前記保留してある配信要求に応じたデータ配信開始を可能とするデータ配信制御手段、
として機能させる為のプログラム。
【請求項１】
複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムであって、
前記ＩＣカード決済端末は、任意のときに又は定期的に、前記サーバ装置に対して前記ネットワークを介して、所定のデータの配信要求を送信して、該サーバ装置にデータ配信を行わせ、該配信されたデータに対して所定のデータ処理を実行後、前記サーバ装置に対して完了通知を送信するデータ取得手段を有し、
前記サーバ装置は、
データ配信処理の同時実行数に対する上限値を示す第１の閾値を記憶する閾値記憶手段と、
前記配信要求を受信する毎に、現在の前記同時実行数が前記第１の閾値に達していない限りは該配信要求に応じてデータ配信を開始し、前記同時実行数が前記第１の閾値に達している場合には、該受信した配信要求を保留し、任意の決済端末に対する前記データ配信が完了したら前記完了通知を待つことなく前記保留してある配信要求に応じたデータ配信を開始するデータ配信制御手段と、
を有することを特徴とするＩＣカードシステム。
【請求項２】
前記閾値記憶手段には更に前記配信要求の保留数に対する上限値を示す第２の閾値が記憶され、
前記データ配信制御手段は、現在の前記配信要求保留数が前記第２の閾値に達している場合には、前記受信した配信要求を保留せずに、該配信要求の送信元のＩＣカード決済端末に対して要求拒否を通知することで該ＩＣカード決済端末に所定時間後のリトライを実行させることを特徴とする請求項１記載のＩＣカードシステム。
【請求項３】
予め各スループットに対応付けて任意の各第２の閾値候補を記憶する第２の閾値候補記憶手段と、
前記各決済端末に対する各データ配信処理に係わるスループットを算出し、該算出したスループットに基づいて前記第２の閾値候補記憶手段から該当する第２の閾値候補を取得してこれを新たな前記第２の閾値とする第２の閾値更新手段と、
を更に有することを特徴とする請求項１または２記載のＩＣカードシステム。
【請求項４】
複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムであって、
前記ＩＣカード決済端末は、任意のときに又は定期的に、前記サーバ装置に対して前記ネットワークを介して、所定のデータの配信要求を送信して、該サーバ装置にデータ配信を行わせ、該配信されたデータに対して所定のデータ処理を実行後、前記サーバ装置に対して完了通知を送信するデータ取得手段を有し、
前記サーバ装置は、
前記配信要求を送信してくる各ＩＣカード決済端末それぞれに対応する各通信手段であって、自己が受信した前記配信要求に応じてデータ配信処理を行う為の配信権限を要求する配信権限要求をデータ配信処理保留管理手段に渡し、その後は配信権限が割り当てられるまで待機し、配信権限が割り当てられるとそのＩＣカード決済端末へのデータ配信処理を開始し、該データ配信処理を完了したら前記完了通知を待つことなく前記配信権限を解放する対決済端末通信手段と、
任意の前記対決済端末通信手段から前記配信権限要求が渡される毎に、該渡された配信権限要求を追加保留する前記データ配信処理保留管理手段と、
データ配信処理の同時実行数に対する上限値を示す第１の閾値に基づいて、現在の前記同時実行数が該第１の閾値に達していない場合、前記データ配信処理保留管理手段に前記配信権限要求が保留されている場合には該配信権限要求を取得して該配信権限要求に対応する対決済端末通信手段に前記配信権限を割り当てて前記データ配信処理を開始させ、また該配信権限の割り当て又は前記配信権限の解放に応じて前記同時実行数を更新するデータ配信権限管理手段と、
を有することを特徴とするＩＣカードシステム。
【請求項５】
前記データ配信処理保留管理手段は、前記配信権限要求の保留数に対する上限値を示す第２の閾値に基づいて、任意の前記対決済端末通信手段から前記配信権限要求が渡される毎に、現在の前記配信権限要求保留数が該第２の閾値に達している場合には、該渡された配信権限要求を保留することなくその対決済端末通信手段に配信拒否応答を返信し、第２の閾値に達していない場合には該渡された配信権限要求を追加保留し、
前記対決済端末通信手段は、前記データ配信処理保留管理手段から前記配信拒否応答があった場合には、自己が対応するＩＣカード決済端末にビジー応答を返信することで該ＩＣカード決済端末に所定時間後のリトライを実行させることを特徴とする請求項４記載のＩＣカードシステム。
【請求項６】
複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムにおける前記サーバ装置であって、
データ配信処理の同時実行数に対する上限値を示す第１の閾値を記憶する閾値記憶手段と、
任意の前記ＩＣカード決済端末からの配信要求を受信する毎に、現在の前記同時実行数が前記第１の閾値に達していない限りは該配信要求に応じてデータ配信を開始し、前記同時実行数が前記第１の閾値に達している場合には、該受信した配信要求を保留し、任意の決済端末に対する前記データ配信が完了したら、配信先のＩＣカード決済端末からの完了通知を待つことなく、前記同時実行数を更新して前記保留してある配信要求に応じたデータ配信開始を可能とするデータ配信制御手段と、
を有することを特徴とするＩＣカードシステムのサーバ装置。
【請求項７】
複数のＩＣカード決済端末と、サーバ装置がネットワークに接続されたＩＣカードシステムにおける前記サーバ装置のコンピュータを、
データ配信処理の同時実行数に対する上限値を示す第１の閾値を記憶する閾値記憶手段と、
任意の前記ＩＣカード決済端末からの配信要求を受信する毎に、現在の前記同時実行数が前記第１の閾値に達していない限りは該配信要求に応じたデータ配信を開始し、前記同時実行数が前記第１の閾値に達している場合には、該受信した配信要求を保留し、任意の決済端末に対する前記データ配信が完了したら、配信先のＩＣカード決済端末からの完了通知を待つことなく、前記同時実行数を更新して前記保留してある配信要求に応じたデータ配信開始を可能とするデータ配信制御手段、
として機能させる為のプログラム。
【図１】
【図２】
【図３】
【図４】
【図７】
【図８】
【図９】
【図５】
【図６】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図７】
【図８】
【図９】
【図５】
【図６】
【図１０】
【図１１】
【公開番号】特開２０１０−１８６４５０（Ｐ２０１０−１８６４５０Ａ）
【公開日】平成２２年８月２６日（２０１０．８．２６）
【国際特許分類】
【出願番号】特願２００９−３１８９５（Ｐ２００９−３１８９５）
【出願日】平成２１年２月１３日（２００９．２．１３）
【出願人】（０００００５２３４）富士電機ホールディングス株式会社 (3,146)
【Ｆターム（参考）】
【公開日】平成２２年８月２６日（２０１０．８．２６）
【国際特許分類】
【出願日】平成２１年２月１３日（２００９．２．１３）
【出願人】（０００００５２３４）富士電機ホールディングス株式会社 (3,146)
【Ｆターム（参考）】
[ Back to top ]