(57)【特許請求の範囲】
【請求項１】
データ通信のための方法において、
少なくとも１つの連続したデータ項目を含んでいるデータパケットを受信する段階と、
前記少なくとも１つの連続したデータ項目の始まりを最初は含んでいるウィンドウを定義する段階と、
前記ウィンドウが、第１部分を前記ウィンドウ内に、第２部分を前記ウィンドウ外に含んでいる分割されたデータ項目の部分を、含んでいるか否かを判定する段階と、
前記分割されたデータ項目が無いときには、前記少なくとも１つの連続したデータ項目を処理する段階と、
前記第１部分の前に生じる前記少なくとも１つの連続したデータ項目の全てを処理する段階と、
前記第１部分を記憶する段階と、
前記ウィンドウを動かし、前記第１部分及び前記第２部分を取り込む段階と、
前記記憶された第１部分を前記第２部分にアペンドして、アペンド済みパケットを作り出す段階と、
前記アペンド済みパケットを処理する段階と、を備えている方法。
【請求項２】
前記ウィンドウを動かす段階が、更に、
前記ウィンドウが、前記第１部分と前記第２部分を組み合わせたサイズよりも小さい場合は、前記ウィンドウのサイズを大きくする段階と、
入力ストリームの最後に達したときには、他のデータパケットを受信する段階と、
前記ウィンドウを動かして、前記第１部分と前記第２部分を取り込む段階と、を含んでいる、請求項１に記載の方法。
【請求項３】
前記アペンドする段階が、更に、
前記記憶された第１部分を検索する段階と、
前記記憶された第１部分を前記第２部分と繋ぎ合わせ、繋ぎ合わされたデータを作り出す段階と、
前記繋ぎ合わされたデータを処理する段階と、
前記ウィンドウを前記繋ぎ合わされたデータを通過して移動させる段階と、を含んでいる、請求項１に記載の方法。
【請求項４】
前記データパケットが、ヘッダを含んでいるＡＰＤＵを含んでおり、
前記記憶された第１部分が前記ヘッダに記憶されている、請求項１に記載の方法。
【請求項５】
少なくとも１つの連続したデータ項目を含んでいるデータパケットを受信する段階と、
前記少なくとも１つの連続したデータ項目の始まりを最初は含んでいるウィンドウを定義する段階と、
前記ウィンドウが、第１部分を前記ウィンドウ内に、第２部分を前記ウィンドウ外に含んでいる分割されたデータ項目の部分を、含んでいるか否かを判定する段階と、
前記分割されたデータ項目が無いときには、前記少なくとも１つの連続したデータ項目を処理する段階と、
前記第１部分の前に生じる前記少なくとも１つの連続したデータ項目の全てを処理する段階と、
前記第１部分を記憶する段階と、
前記ウィンドウを動かし、前記第１部分及び前記第２部分を取り込む段階と、
前記記憶された第１部分を前記第２部分にアペンドして、アペンド済みパケットを作り出す段階と、
前記アペンド済みパケットを処理する段階と、から成るデータ通信を実行するためにマシンで実行可能な命令のプログラムを具体化するマシンで読み取り可能なプログラム記憶装置。
【請求項６】
前記ウィンドウを動かす段階が、更に、
前記ウィンドウが、前記第１部分と前記第２部分を組み合わせたサイズよりも小さい場合は、前記ウィンドウのサイズを大きくする段階と、
入力ストリームの最後に達したときには、他のデータパケットを受信する段階と、
前記ウィンドウを動かして、前記第１部分と前記第２部分を取り込む段階と、を含んでいる、請求項５に記載のプログラム記憶装置。
【請求項７】
前記アペンドする段階が、更に、
前記記憶された第１部分を検索する段階と、
前記記憶された第１部分を前記第２部分と繋ぎ合わせ、繋ぎ合わされたデータを作り出す段階と、
前記繋ぎ合わされたデータを処理する段階と、
前記ウィンドウを前記繋ぎ合わされたデータを通過して移動させる段階と、を含んでいる、請求項５に記載のプログラム記憶装置。
【請求項８】
前記データパケットが、ヘッダを含んでいるＡＰＤＵを含んでおり、
前記記憶された第１部分が前記ヘッダに記憶されている、請求項５に記載のプログラム記憶装置。
【請求項９】
データ通信用の装置において、
プログラム命令を有する少なくとも１つのメモリと、
前記プログラム命令を使用して、
少なくとも１つの連続したデータ項目を含んでいるデータパケットを受信し、
前記少なくとも１つの連続したデータ項目の始まりを最初は含んでいるウィンドウを定義し、
前記ウィンドウが、第１部分を前記ウィンドウ内に、第２部分を前記ウィンドウ外に含んでいる分割されたデータ項目の部分を、含んでいるか否かを判定し、
前記分割されたデータ項目が無いときには、前記少なくとも１つの連続したデータ項目を処理し、
前記第１部分の前に生じる前記少なくとも１つの連続したデータ項目の全てを処理し、
前記第１部分を記憶し、
前記ウィンドウを動かして、前記第１部分及び前記第２部分を取り込み、
前記記憶された第１部分を前記第２部分にアペンドして、アペンド済みパケットを作り出し、
前記アペンド済みパケットを処理する、ように構成されている少なくとも１つのプロセッサと、を備えている装置。
【請求項１０】
前記記憶された第１部分に対するメモリ割当てが、前記少なくとも１つのプロセッサのコンピュータアーキテクチャに基づいている、請求項９に記載の装置。
【請求項１１】
前記少なくとも１つのプロセッサはｎビットのプロセッサを含んでおり、
前記記憶された第１部分に割り当てられた８ビットバイトの数は（ｎ／８）−１である、請求項９に記載の装置。
【請求項１２】
前記少なくとも１つのプロセッサは３２ビットのプロセッサを含んでおり、
前記記憶された第１部分には、３つの８ビットバイトが割り当てられている、請求項９に記載の装置。
【請求項１３】
前記少なくとも１つのプロセッサは１６ビットのプロセッサを含んでおり、
前記記憶された第１部分には、１つの８ビットバイトが割り当てられている、請求項９に記載の装置。
【請求項１４】
前記データパケットが、ヘッダを含んでいるＡＰＤＵを含んでおり、
前記記憶された第１部分が前記ヘッダに記憶されている、請求項９に記載の装置。
【請求項１５】
データ通信用の装置において、
少なくとも１つの連続したデータ項目を含んでいるデータパケットを受信するための手段と、
前記少なくとも１つの連続したデータ項目の始まりを最初は含んでいるウィンドウを定義するための手段と、
前記ウィンドウが、第１部分を前記ウィンドウ内に、第２部分を前記ウィンドウ外に含んでいる分割されたデータ項目の部分を、含んでいるか否かを判定するための手段と、
前記分割されたデータ項目が無いときには、前記少なくとも１つの連続したデータ項目を処理するための手段と、
前記第１部分の前に生じる前記少なくとも１つの連続したデータ項目の全てを処理するための手段と、
前記第１部分を記憶するための手段と、
前記ウィンドウを動かし、前記第１部分及び前記第２部分を取り込むための手段と、
前記記憶された第１部分を前記第２部分にアペンドして、アペンド済みパケットを作り出す手段と、
前記アペンド済みパケットを処理するための手段と、を備えている装置。
【請求項１６】
リソースに制約のある装置において、
少なくとも１つの連続したデータ項目を含んでいるデータパケットを受信し、
前記少なくとも１つの連続したデータ項目の始まりを最初は含んでいるウィンドウを定義し、
前記ウィンドウが、第１部分を前記ウィンドウ内に、第２部分を前記ウィンドウ外に含んでいる分割されたデータ項目の部分を、含んでいるか否かを判定し、
前記分割されたデータ項目が無いときには、前記少なくとも１つの連続したデータ項目を処理し、
前記第１部分の前に生じる前記少なくとも１つの連続したデータ項目の全てを処理し、
前記第１部分を記憶し、
前記ウィンドウを動かして、前記第１部分及び前記第２部分を取り込み、
前記記憶された第１部分を前記第２部分にアペンドして、アペンド済みパケットを作り出し、
前記アペンド済みパケットを処理する、ための一連の命令を備えているアプリケーションソフトウェアプログラムを記憶するためのメモリと、
３２ビット未満のアーキテクチャに基づくマイクロプロセッサ上で実行される仮想マシンとを備え、前記仮想マシンは前記データパケット内に含まれている命令を実行可能である装置。
【請求項１７】
スマートカードにおいて、
少なくとも１つの連続したデータ項目を含んでいるデータパケットを受信し、
前記少なくとも１つの連続したデータ項目の始まりを最初は含んでいるウィンドウを定義し、
前記ウィンドウが、第１部分を前記ウィンドウ内に、第２部分を前記ウィンドウ外に含んでいる分割されたデータ項目の部分を、含んでいるか否かを判定し、
前記分割されたデータ項目が無いときには、前記少なくとも１つの連続したデータ項目を処理し、
前記第１部分の前に生じる前記少なくとも１つの連続したデータ項目の全てを処理し、
前記第１部分を記憶し、
前記ウィンドウを動かして、前記第１部分及び前記第２部分を取り込み、
前記記憶された第１部分を前記第２部分にアペンドして、アペンド済みパケットを作り出し、
前記アペンド済みパケットを処理する、ための一連の命令を備えているアプリケーションソフトウェアプログラムを記憶するためのメモリと、
３２ビット未満のアーキテクチャに基づくマイクロプロセッサ上で実行される仮想マシンとを備え、前記仮想マシンは前記データパケット内に含まれている命令を実行可能であるスマートカード。
【請求項１８】
前記仮想マシンは、実質的にJava Card 仮想マシンである、請求項１７に記載のスマートカード。
【発明の詳細な説明】
【０００１】
（関連出願のクロス・リファレンス）
本出願は、以下のものに関連する：
アメリカ合衆国特許出願、１９９９年２月２日出願、ＳｕｓｓｅｒおよびＳｃｈｗａｂｅ、題名「リソース制約装置のためのオブジェクト指向命令セット（OBJECT-ORIENTED INSTRUCTION SET FOR RESOURCE-CONSTRAINED DEVICES」  アメリカ合衆国特許出願、１９９７年４月１５日出願、ＬｅｖｙおよびＳｃｈｗａｂｅ、題名「安全に分散されたバイトコード検証を伴う仮想マシン（VIRTUAL MACHINE WITH SECURELY DISTRIBUTED BYTECODE VERIFICATION）」
（技術分野）
本発明は、コンピュータ・システムに関する。より特定的には、本発明は、移動セット・データ通信に関する。
【０００２】
（背景技術）
仮想マシンは、プロセッサによって実行されるソフトウェア・アプリケーションまたは命令のシーケンスによって作られる抽象的計算機械である。“アーキテクチャ・ニュートラル（architecture-neutral）”という用語は、ＪａｖａTMプログラミング言語で書かれたようなプログラムを意味し、それは様々なコンピュータ・アーキテクチャを有する様々なコンピュータ・プラットフォーム上で仮想マシンによって実行することができる。例えば、ＷｉｎｄｏｗｓTMベース・パーソナル・コンピュータ・システムで実行される仮想マシンは、ＵＮＩＸTMベース・コンピュータ・システムで実行される仮想マシンとして、同じセットの命令を使用するであろう。仮想マシンの命令のシーケンスの、プラットフォーム独立コーディングの結果は、一つ以上のバイトコードのストリームであり、その各々は、例えば、１バイト長の数字コードである。
【０００３】
ＪａｖａTM仮想マシンは、仮想マシンの一例である。ＪａｖａTM仮想マシンによって実行されるコンパイルされたコードは、ハードウェア及びオペレーティング・システム独立バイナリ・フォーマットを用いて表され、クラス・ファイル・フォーマットとして知られるファイルに通常記憶される。前記クラス・ファイルは、ＪａｖａTMプログラミング言語で書かれたプログラムを表すことができるが、他のいくつかのプログラミング言語をサポートしていてもよい、オブジェクト指向構造を扱うように設計されている。クラス・ファイル・フォーマットは、プラットフォームに特化したオブジェクト・ファイル・フォーマットで当然とされるかもしれないバイト・オーダリング（byte ordering）等の詳細を含む、クラスまたはインターフェースの表示を精密に定義する。セキュリティのため、ＪａｖａTM仮想マシンは、強いフォーマットおよび構造上の制約を、クラス・ファイルでの命令に課す。有効なクラス・ファイルに関して表されることができる機能性を持つあらゆる言語は、ＪａｖａTM仮想マシンによってホストされることができる。クラス・ファイルは、ＪａｖａTMプログラミング言語で書かれたプログラムを表すことができるが、他のいくつかのプログラミング言語をサポートしてもよい、オブジェクト指向の構造を扱うように設計される。ＪａｖａTM仮想マシンは、Ｌｉｎｄｈｏｌｍら、“ＪａｖａTM仮想マシン仕様書（The Java TM Virtual Machine Specification）”、１９９９年４月、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ  Ｌｏｎｇｍａｎ，Ｉｎｃ．，第二版に詳細に説明されている。
【０００４】
リソース制約装置は、一般的に、通常のデスクトップ・コンピュータ等と比較して、メモリおよび／または計算能力あるいは速度において、相対的に制約されている装置であると考えられている。例として、他の、リソース制約装置は、セルラー電話、境界スキャン装置、フィールドプログラム可能装置、パーソナル・デジタル・アシスタント（personal digital assistants）（ＰＤＡｓ）ならびにページャ（pager）および他のミニチュアあるいは小さいフットプリント装置を含む。
【０００５】
スマート・カードは、インテリジェント・ポータブル・データ搬送カードとしても知られており、一種のリソース制約装置である。スマート・カードは、プラスチックまたは金属で作られており、およびプログラムを実行するための埋め込み型マイクロプロセッサまたはマイクロコントローラおよびプログラムならびにデータを記憶するためのメモリを含む、電子チップを有する。そのような装置は、クレジット・カードくらいの大きさでもよく、８ビットまたは１６ビット・アーキテクチャのコンピュータ・チップを有する。さらに、これらの装置は、通常、制約されたメモリ・キャパシティを有する。例えば、あるスマート・カードは、制約された読み取り専用メモリ（ＲＯＭ）と同様に、１キロバイト（１Ｋ）未満のランダム・アクセス・メモリ（ＲＡＭ）、および／または電子的に消すことができるプログラム可能読み取り専用メモリ（electrically erasable programmable read only memory）（ＥＥＰＲＯＭ）等の非揮発性を有する。
【０００６】
ＪａｖａTM仮想マシンは、ＪａｖａTMプログラミング言語で書かれた仮想マシン・コードを実行し、および３２ビット・アーキテクチャでの使用のために設計されている。スマート・カード等のリソース制約装置上での実行のために、ＪａｖａTM仮想マシンの完全な実装を使用するプログラムを書くことが望ましいであろう。しかしながら、スマート・カード等、リソース制約装置の制約されたアーキテクチャおよびメモリによって、完全なＪａｖａTM仮想マシン・プラットフォームは、そのような装置上に実装することができない。従って、個別のＪａｖａ  ＣａｒｄTM（ＪａｖａTMプログラミング言語をサポートするスマート・カード）技術は、リソース制約装置のためのＪａｖａTMプログラミング言語のサブセットをサポートする。
【０００７】
ここで図１を見ると、Ｊａｖａ  ＣａｒｄTM技術イネーブルド装置１２０にアプリケーションをインストールするための典型的な装置が示されている。Ｊａｖａ  ＣａｒｄTM技術において、Ｊａｖａ  ＣａｒｄTMコンバータ１００は、入力としてレギュラー・クラス・ファイル（regular class file）１０５を取り、およびそれらをＣＡＰ（converted applet）ファイル１１０に変換する。ＣＡＰフォーマットは、クラス・ファイル情報のサブセットをサポートする。各ＣＡＰファイル１１０は、一つのＪａｖａTMパッケージで定義されるクラスおよびインターフェースのすべてを含む。変換後に、ＣＡＰファイル１１０はカード・リーダー周辺装置（card reader peripheral）を有するデスクトップ・コンピュータ等、カード・ターミナルにコピーされる。それから、ターミナル上のインストール・ツール１１５は、ＣＡＰファイル１１０をロードし、それをＪａｖａ  ＣａｒｄTM技術イネーブルド装置１２０に送信する。Ｊａｖａ  ＣａｒｄTM技術イネーブルド装置１２０上のインストール・アプリケーション１２５は、Ｊａｖａ  ＣａｒｄTM技術イネーブルド装置１２０上にアプリケーションをインストールするために、前記ターミナルからのデータを受信し、および処理する。
【０００８】
典型的なＪａｖａ  ＣａｒｄTM技術イネーブルド装置１２０のリソースが制約される性質によって、相対的に小さい量のメモリのみがデータ通信に利用できる。このように、ターミナルと、Ｊａｖａ  ＣａｒｄTM技術イネーブルド装置１２０との間の通信は、通常、ターミナルからＪａｖａ  ＣａｒｄTMイネーブルド装置１２０送信された複数のアプリケーション・データ・ユニット（application data unit）（ＡＰＤＵｓ）１３５を含む。ＡＰＤＵ１３５は、３２バイトから２５６バイトの範囲のサイズを有するデータ部分を有するデータ・パケットである。ターミナルから送信されるデータは、Ｊａｖａ  ＣａｒｄTM技術イネーブルド装置１２０に送信される前に、一つ以上のＡＰＤＵｓ１３５に密閉される。
【０００９】
密閉された複数のデータ値のサイズは変化するので、前記データ値は、頻繁に、複数のＡＰＤＵｓ１３５の間で分割される。表１は、ＡＰＤＵ１３５のデータ部分を表す。表２は、ＡＰＤＵ１３５に密閉されるべきデータを示す。
【００１０】
【表１】
0004703930.tif 000002
【００１１】
【表２】
0004703930.tif 000003
【００１２】
表２に記載のデータが、表１で表されるＡＰＤＵ１３５に密閉される一方で、データの相対的順序を維持する場合、第二の１６ビット整数のための空間は不十分であり、その結果、“データ分割（data split）”問題を生じる。このデータ分割問題は、通常、データが分割されないことを保証するために、ターミナル側のデータを処理することによって扱われる。この、ターミナル側での処理は、例示的に、データ分割を避けるためにＡＰＤＵ１３５のサイズを変更し、またはＪａｖａ  ＣａｒｄTM技術イネーブルド装置１２０に送信する前に、ＡＰＤＵ内に前記データを記録することを含んでもよい。これらの解決の各々は、欠点を有する。
【００１３】
ＡＰＤＵ１３５のサイズを変更し、およびＡＰＤＵ１３５内にデータを記録することは、ターミナルとカードとの間で、複雑な交渉（negotiation）を必要とする。ターミナルは、データを変換し、および前記データを再構築するために、カードに十分な情報を供給しなければならない。カードは、ターミナルから情報を受信し、データを再構築し、およびターミナルに応答を供給しなければならない。ターミナルおよびカード・アプリケーションをデータ依存にすることによって、処理オーバーヘッドを増やす。このデータ依存性は、プログラム・サイズと、バッファされたデータを記憶するために必要なＲＡＭの量との両方に関して、メモリ・オーバーヘッドも増やす。
【００１４】
ターミナル側にインテリジェンスを課すことによって、セキュリティ問題も持ち上がる。データ分割問題が存在するかを知ることは、ターミナルが、送信される各データ・アイテムのサイズを知ることが必要となる。このサイズ情報は、データの種類に関連する。この情報は、データが暗号化されている場合は使用できない。このようにターミナルは、各データ・ユニットのサイズを決定するためにデータを翻訳する前に、暗号化されたデータを解読しなければならない。一度データが解読されると、ターミナルは個人情報にアクセスすることができる。あるアプリケーションにおいては、カードのみがデータを翻訳するものであり、ターミナルはしない。
【００１５】
従って、従来技術においては、ターミナルおよびスマート・カード・アプリケーションで、相対的に小さい処理およびメモリ・オーバーヘッドを必要とするターミナル装置とスマート・カードとの間のデータ通信のための、方法および装置に対する必要性が存在する。相対的に安全な、前記方法および装置に対するさらなる必要性が存在する。
【００１６】
（発明の開示）
データ通信のための方法は、少なくとも一つの連続的データ・アイテムを含むデータ・パケットを受信し、最初にデータ・アイテムの開始を含むウィンドウを定義し、前記ウィンドウが分割データ・アイテムの一部を含むかを決定し、および分割データ・アイテムがない時には、連続データ・アイテムを処理することを含む。前記方法は、分割データ・アイテムが見つかる時は、分割データ・アイテムの前に生じるすべてのデータ・アイテムを処理し、分割データ・アイテムの第一の部分を記憶し、分割データ・アイテムの両方の部分を含むようにウィンドウを動かし、追加パケットを作成するために、記憶された第一の部分を第二の部分に追加し、および前記追加パケットを処理することも含む。データ通信のための装置は、プログラム命令を有する、少なくとも一つのメモリと、および少なくとも一つの連続データ・アイテムを含むデータ・パケットを受信し、データ・アイテムの開始を最初に含むウィンドウを定義し、前記ウィンドウが、分割データ・アイテムの一部を含むか決定し、および分割データ・アイテムがない時には、連続データ・アイテムを処理するためのプログラム命令を使用するように構成された、少なくとも一つのプロセッサを含む。前記プロセッサは、分割データ・アイテムが見つかった時には、分割データ・アイテムの前に生じるすべてのデータ・アイテムを処理し、分割データ・アイテムの第一の部分を記憶し、分割データ・アイテムの両方の部分を含むように前記ウィンドウを動かし、記憶された第一の部分を第二の部分に追加し、および結果を処理するようにも構成される。
【００１７】
（発明を実施するための最良の形態）
通常の当業者は、本発明の以下の説明が、例示的なものにすぎないことを理解するであろう。本発明の他の実施例は、この開示の利益を有する当業者に容易に示唆されるであろう。
【００１８】
本発明は、コンピュータ・システムに関する。より特定的には、移動セット・データ通信に関する。本発明はさらに、（１）本発明のレイアウト・パラメータおよび／または（２）コンピュータでオペレーションを実行する際に本発明を使用するためのプログラム命令が記憶されている、マシン読み取り可能媒体に関する。そのような媒体は、例示的に、磁気テープ、磁気ディスク、ＣＤ  ＲＯＭや、ＰＣＭＣＩＡカード等の半導体メモリ等の光学読み取り可能媒体を含む。前記媒体は、小さいディスク、ディスケット、またはカセット等の携帯型アイテムの形式を取ってもよい。前記媒体は、ハード・ディスク・ドライブまたはコンピュータＲＡＭ等のより大きな、または移動式ではないアイテムの形式を取ってもよい。
【００１９】
リソース制約装置は、一般的に、典型的なデスクトップ・コンピュータ等と比較して、メモリおよび／または計算能力あるいは速度において相対的に制約される装置であると考えられる。後述される特定の実装は、スマート・カードを参照して説明されるが、本発明は、セルラー電話、境界スキャン装置、フィールドプログラム可能装置、パーソナル・デジタル・アシスタント（ＰＤＡ）およびページャを、他のミニチュアまたは小さなフットプリント装置と同様に含むが、それらに限定されない、他のリソース制約装置とともに使用されうる。本発明は、非リソース制約装置上でも使用されうる。
【００２０】
この開示の目的で、“プロセッサ”という用語は、物理的コンピュータまたは仮想マシンを意味するために使用されてもよい。また、データ処理は、Ｊａｖａ  ＣａｒｄTM技術イネーブルド装置１２０等、リソース制約装置にアプリケーションをインストールするのに必要な処理のことを意味する。
【００２１】
本発明に従って、物理的に区分化されたデータは、連続データ・ストリームとして概念的に取り扱われる。データは、移動セットとも呼ばれる、概念的なスライディング・ウィンドウ（sliding window）内で処理される。データ分割がない場合、データ処理は、通常通り生じる。データ分割が検出される場合、前記ウィンドウは、分割データの他の部分を含む、前記データの残りを見るために、概念的データ・ストリームのソースに向かって移動される。この処理は、すべてのデータが消費されるまで続く。
【００２２】
ここで図２を見ると、本発明の一つの実施例に従った移動データ・セット通信を示す流れ図が示されている。参照番号１５０において、データ・パケットが受信される。参照番号１５５において、ウィンドウの開始が、データ・パケットの開始に設定される。参照番号１６０において、データ値が分割されているかに関する決定がなされる。データ値が分割されていなかった場合、前記データは、参照番号１６５において、通常通り処理される。参照番号１７０において、前記ウィンドウは、前記ウィンドウ・サイズに等しい数のバイトを移動する。
【００２３】
データ値が分割されていた場合、分割データ値までのデータは、参照番号１６５において通常通り処理される。参照番号１７０において、存在する分割データ値の部分がセーブされる。参照番号１７５において、ウィンドウは、分割データの残りを含むように動く。参照番号１８０において、分割データのセーブされた部分は、新たに配置されたウィンドウから分割データの残りに追加される。参照番号１６５において、追加データは、通常通り処理される。
【００２４】
ここで図３を見ると、本発明の一つの実施例に従った、データ追加を示す流れ図が示されている。参照番号２００において、記憶されたデータが検索される。参照番号２０５において、記憶されたデータは、前記ウィンドウが、図２の参照番号１７５において分割データの残りを含むように移動した時に得られる新しいデータと連結される。参照番号２１０において、連結されたデータが処理される。参照番号２１５において、ウィンドウは、連結したデータを通過して移動する。
【００２５】
ここで図４を見ると、本発明の一つの実施例に従って、ウィンドウを動かすことを示す流れ図が示されている。参照番号２３０において、ウィンドウが、処理されないデータを廃棄することなく、前記動きに対応するのに十分に大きいかに関する決定がなされる。ウィンドウが十分に大きくない場合、ウィンドウ・サイズは、参照番号２３５において大きくされる。ウィンドウが十分に大きい場合、参照番号２４０において、入力ストリームの終わりに到達したかについて決定がなされる。入力ストリームの終わりに到達した場合、参照番号２４５において、少なくとも一つのデータ・パケットが読み取られる。入力ストリームの終わりに到達しなかった場合、参照番号２５０においてウィンドウが配置される。
【００２６】
本発明の理解を助けるために、本発明は、図５に記載の特定的な例に適用される。図５は、３２バイト・データ・パケット・バッファ２７０および４バイト・ウィンドウ２７５を用いて本発明を示す。前記データ・パケットの、２のデータ・アイテムを除くすべてのデータ・アイテムは、２バイト整数である。１バイトは、参照番号２８０によって表され、および４バイト整数の最初の２バイトは、参照番号２８５によって表される。図２の参照番号１５０において、第一のデータ・パケットが受信される。参照番号１５５において、ウィンドウ２７５は、データ・パケット２７０の開始に設定される。参照番号１６０において、ウィンドウ２７５におけるデータ値が分割されるかについての決定がなされる。ウィンドウ２７５の終わりは、２バイト整数２９０の終わりと一致するので、データ分割はない。参照番号１６５において、データ値２９０および２９５は、通常通り処理される。
【００２７】
参照番号１７０において、ウィンドウ２７５は動かされる。図４の参照番号２３０において、ウィンドウは、４バイト動くだけ十分に大きいと判定されるが、それは、そのウィンドウがその数のバイトを保持できるからである。参照番号２４０で、入力ストリームの終わりに達したか否かを判定するためのチェックが行われる。３２バイトのデータパケットの内４バイトだけが処理されているので、まだ入力ストリームの終わりには達していない。参照番号２５０で、ウィンドウは、入力ストリームのソースに向けて４バイト動かされる。位置付けられたウィンドウは、参照番号３００で表示されている。ウィンドウ３００は、１バイト３０５と、１つの２バイト整数３１０と、他の２バイト整数３１０の１バイトとを含んでいる。
【００２８】
図２の参照番号１６０では、データ値が分割されたか否かについての判定が行われる。ウィンドウは、２バイト整数３１５の１バイトだけしか含んでいないので、データ値は既に分割されている。参照番号１６５で、分割前に生じたデータ値が処理される。こうして、バイト３０５と、２バイト整数３１０とが処理される。参照番号１７０で、２バイト整数３１５の１バイトがセーブされる。参照番号１７５で、ウィンドウは動かされ、分割されたデータの残りを取り込む。再度位置付けられたウィンドウは、参照番号３３０で表示されている。ウィンドウ３３０は、分割された２バイト整数３１５の両方のバイトを包含している。
【００２９】
ウィンドウ３３５から３５５は、それぞれ２つの２バイト整数を含んでおり、ウィンドウ２７５と同じやり方で処理される。ウィンドウ３６０は、４バイト整数３６５の半分しか含んでいない。２バイト３６５は、図２の参照番号１７０で記憶される。参照番号１７５で、ウインドウは動かされ、データの残りを取り込む。入力ストリームの終わりに達したので、図４の参照番号２４５で別のデータパケットが読み込まれる。この例では、ウィンドウのサイズが３２バイトデータパケットのデータのサイズより小さいので、１データパケットだけが読み込まれる。図３の参照番号２００で、記憶されていたデータが検索される。参照番号２０５で、記憶されていたデータが、新しいデータパケットから読み取られたばかりのウィンドウ内の別のデータと繋ぎ合わされる。参照番号２１０で、繋ぎ合わされたデータが処理される。参照番号２１５で、ウィンドウは、繋ぎ合わされたデータを越して動かされる。
【００３０】
通常の当業者であれば、本発明を使うことにより出会うデータ分割の数はウィンドウサイズに反比例して変化することを理解頂けよう。ウィンドウサイズを上げてデータ分割を減らす効果は、大きいウィンドウにはメモリを増やさなければならないことと軽重比較せねばならない。
【００３１】
本発明のある実施形態によれば、分割されたデータ値を記憶するために割り当てられるバイトの数は、カード装置のコンピュータアーキテクチャに基づいて選択される。通常の１６ビットプロセッサは、２バイト整数ベースの型式を有している。殆どの１６ビットプロセッサ命令は、１６ビットのオペランドを期待している。従って、データパケットで出会う殆どのデータ値は２バイト以下である。２バイトのデータ値が分割されると、１バイトはウィンドウの内側、もう１バイトはウィンドウの外側となる。従って、殆どの状態に対し、１バイトバッファで十分である。
【００３２】
同様に、通常の３２ビットプロセッサは、４バイト整数ベースの型式を有している。４バイト整数が分割されると、ウィンドウ内のデータの量は、４バイトの内の１ないし３バイトということになる。従って、殆どの状態に対し、３バイトバッファで十分である。一般化すれば、ｎをビットの数として、ｎビットのプロセッサでは、記憶装置のバッファに割り当てられるバイトの数は（ｎ／８）−１となる。
【００３３】
本発明の他の実施形態によれば、データパケットのヘッダ部は、分割されたデータ値を記憶するのに使われる。例えば、ＡＰＤＵは、５バイトのヘッダを含んでいる。ＡＰＤＵは、コマンドか応答の何れかを含んでいる。表３に、代表的コマンドＡＰＤＵのフォーマットを示す。
【００３４】
【表３】
0004703930.tif 000004
【００３５】
表３において、ＣＬＡは命令のクラス、ＩＮＳは命令、Ｐ１とＰ２は命令のパラメータ、Ｌｃは命令のデータフィールドのバイト長、Ｄａｔａは命令のデータフィールド、Ｌｅは、応答のデータフィールドで予測される最大のバイト数である。ヘッダ内の各項目のサイズは１バイトである。従って、最大データフィールドサイズは２５６バイトである。ＡＰＤＵは、ＩＳＯ標準７８１６−４、１９９５，セクション５．３に詳しく述べられている。
【００３６】
通常、５つのＡＰＤＵヘッダバイト、ＣＬＡ、ＩＮＳ、Ｐ１、Ｐ２、Ｌｃは、ＡＰＤＵの受信時に調べられ、ＡＰＤＵのデータ部分をどのように解釈するかが決められる。一旦情報がヘッダバイトから抽出されると、ヘッダバイトのメモリ位置は、以降のＡＰＤＵデータ部の処理の間使用されることはない。本発明のこの実施形態によれば、ＡＰＤＵヘッダバイトは、分割されたデータ値用の記憶位置として再使用され、追加メモリの割当てを回避する。
【００３７】
特定のウィンドウサイズと特定のデータパケットサイズを使用した本発明の説明は、何らかの限定を意図したものではない。当業者であれば、本発明が様々なデータパケットフォーマット及びウィンドウサイズに適用できることを理解頂けよう。また、本発明をＪａｖａＣａｒｄTM技法に関して説明してきたが、当業者であれば、本発明が他の多くのプラットフォームにも適用できることも理解頂けよう。プラットフォームの例としては、Ｋ仮想マシン（ＫＶＭ）技法を挙げることができる。ＫＶＭ技法は、サンマイクロシステムズ社の１９９８年６月８日発行の「Ｋ仮想マシン（ＫＶＭ）−A White Paper」に述べられている。
【００３８】
本発明は、ソフトウェア又はファームウェア、並びにプログラム可能ゲートアレイ装置、特定用途集積回路（ＡＳＩＣｓ）及びその他のハードウェアで実行することができる。
以上、セットデータ通信を動かす新規な方法を説明してきた。本発明の実施態様及び用途を示し説明してきたが、本開示の利益を享受しようとする当業者には自明であるように、上に説明した以外にも、この発明的コンセプトから離れることなく、多くの修正を行うことができる。従って、本発明は、特許請求の範囲に述べる精神を除き、拘束されるものではない。
【図面の簡単な説明】
【図１】  図１は、Ｊａｖａ  ＣａｒｄTM技術イネーブルド装置にアプリケーションをインストールための典型的な装置を示すブロック図である。
【図２】  図２は、本発明の一つの実施例に従った、データ通信のための方法を示す流れ図である。
【図３】  図３は、本発明の一つの実施例に従った、分割データ値を追加するための方法を示す流れ図である。
【図４】  図４は、本発明の一つの実施例に従った、ウィンドウを動かすための方法を示す流れ図である。
【図５】  図５は、本発明を、３２バイト・データ・パケットおよび４バイト・ウィンドウに適用することを示すブロック図である。
【図１】
0004703930.tif 000005
【図２】
0004703930.tif 000006
【図３】
0004703930.tif 000007
【図４】
0004703930.tif 000008
【図５】
0004703930.tif 000009