JP2004514360A - 郵便料金支払証を印刷した郵便物を管理する方法 - Google Patents

Abstract

本発明は、郵便料金支払証を印刷した郵便物を管理する方法にあって、この場合、顧客システムが料金通知センタからデータ線を経由して料金をロードし、この場合、この顧客システムは、郵便物への郵便料金支払証の印刷を制御し、この場合、この料金通知センタは、データパケットをこの顧客システムに送信する方法に関する。本発明は、料金通知センタが鍵を生成し、この鍵を顧客システムに伝送すること、データがこの顧客システム内で生成され、この料金通知センタがこれらのデータを復号化できるように、これらのデータがこの鍵で暗号化されること、これらのデータはこの顧客システムから料金通知センタに送信されること、及びこの料金通知センタは乱数を生成し、引き続きこれらのデータをこの乱数と共にこの顧客システムに秘密の鍵とこの顧客システムの安全モジュールに既知の鍵とによって暗号化し、引き続きこうして暗号化されたデータをこの顧客システムに伝送することを特徴とする。さらに本発明は、郵便物の郵便料金支払証を別納する顧客システム及び郵便料金別納方法で使用する料金通知センタに関する。

Description

【０００１】
本発明は、郵便料金支払証を印刷した郵便物を管理する方法に関する。この場合、顧客システムが料金通知センタからデータ線を経由して料金をロードする。この場合、この顧客システムは、郵便物への郵便料金支払証の印刷を制御する。この場合、この料金通知センタは、データパケットをこの顧客システムに送信する。
【０００２】
このような方法は、国際特許出願公開第 ９８ １４９０７ 号明細書から公知である。
【０００３】
その他の方法は、ドイツ連邦共和国特許発明第 ３１ ２６ ７８５号明細書から公知である。この方法の場合、郵便物の郵便料金を別納するために決められた事後的請求信号が、郵便配達会社によって運営されている料金通知センタの独立した部署内で生成される。
【０００４】
同様に、ドイツ連邦共和国未公開特許出願第 １００ ２０ ５６６．６／５３号明細書は、郵便料金支払証を印刷した郵便物を管理する方法を記す。
【０００５】
この方法の場合、顧客システムが、データパケットの形態の料金を料金通知センタからデータ線を経由して負担する。この顧客システムは、郵便料金支払証を作成するためにこの料金を利用する。料金通知センタが、これらのデータを復号化できるように、これらのデータが、顧客システムから料金通知センタに送信されるように、及び料金通知センタが、これらのデータを復号化し、引き続きこれらのデータを顧客システムに秘密の鍵で新たに暗号化し、引き続きこうして暗号化されたデータを顧客システムに伝送するように、これらのデータが顧客システム内で生成されることをこの方法は特徴とする。この方法の好適な実施形は、暗号化が顧客システム内で認証子として使用される乱数を使用して実行されることを特徴とする。さらに、この方法は、顧客システムのユーザがアクセスしない安全モジュール内で乱数が生成されることを特徴とする。
【０００６】
認証子として使用されるこのような乱数は、全システムの改竄信頼性に関して重要な役割をするので、これらの乱数を発生させる品質又は「コンティンジェンシ （Ｚｕｆａｅｌｌｉｇｋｅｉｔ）」が非常に重要である。多くの場合に顧客システム内に存在して経済的な理由から限定された内部機能とアルゴリズムに対してしかメモリ空間を提供しない安全モジュールが乱数の品質に対して高い要求を満たす必要があるという問題が実際にここから発生する。
【０００７】
安全モジュールを使用しなくても有効に発行される郵便料金支払証を不正に無料で作成することが乱数を知ることによって可能になるので、無資格者が乱数を知ることを阻止する必要が特にある。
【０００８】
本発明の課題は、郵便料金支払証を不正に作成することを阻止する方法を提供することにある。
【０００９】
この課題は、本発明により、料金通知センタが鍵を生成し、この鍵を顧客システムに伝送すること、データがこの顧客システム内で生成され、この料金通知センタがこれらのデータを復号化できるように、これらのデータがこの鍵で暗号化されること、これらのデータがこの顧客システムからこの料金通知センタに送信されること、そしてこの料金通知センタがこれらのデータを復号化し、引き続きこれらのデータをこの顧客システムに秘密の鍵で新たに暗号化し、引き続きこうして暗号化されたデータをこの顧客システムに伝送することによって解決される。
【００１０】
安全モジュール内で生成される品質の悪い乱数を予想しうることによる不正を阻止するため、乱数が料金通知センタ内で全ての安全モジュールに対して負担処理ごとに集中的にも生成される。料金通知センタと顧客システム内のそれぞれの安全モジュールとの間の電子的なデータ通信の範疇では、鍵が暗号化されデジタル署名されて伝送される。高品質の乱数の準備は、中心的な料金通知センタ内のほうが顧客システム内の安全モジュール内よりも良好に保証され得る。
【００１１】
本発明の方法の特に好適な実施形は、身元確認と認証と所望のアクションのためのデータが顧客システム内で生成され、料金通知センタがデータを復号化できるように、これらのデータが暗号化されること、これらのデータが顧客システムから料金通知センタに送信されること、そしてこの料金通知センタがこれらのデータを復号化し、引き続きこれらのデータをこの顧客システムに秘密の鍵で新たに暗号化し、引き続きこうして暗号化されたデータをさらに新たに伝送すべき暗号化されたデータと一緒にこの顧客システムに伝送し、これらの暗号化されたデータが顧客システムによって復号化され得ることを特徴とする。
【００１２】
本発明の方法の１つの好適な実施形は、料金通知センタ内の暗号化が乱数を使用して実行されることを特徴とする。
【００１３】
乱数が顧客システムから送信されるセッション鍵と顧客システムの公開鍵とによって暗号化されることが好ましい。さらに、この方法は、料金通知センタがこれらのデータを個人鍵で署名することを特徴とする。
【００１４】
さらに、顧客がアクセスしない顧客システムの安全モジュール内で復号化が実行されることが好ましい。
【００１５】
この方法のもう１つの好適な実施形は、顧客がアクセスしない顧客システムの安全モジュール内に復号化された乱数が記憶されることを特徴とする。
【００１６】
料金通知センタから送信されたデータを完全に復号化することができないものの、郵便センタがこれらのデータを復号化できるように、顧客システムが特に構成されている。この郵便センタ内では、郵便料金支払証が正当であるかどうか郵便物を検査する。
【００１７】
料金通知センタは、いろいろに構成され得る。料金通知センタ（Ｗｅｒｔｕｅｂｅｒｔｒａｇｕｎｇｓｚｅｎｔｒｕｍ）の概念は、公知の料金通知センタと新しい形態の料金通知センタとの双方を網羅する。
【００１８】
本発明は、特にこのような料金通知センタに関する。インターネット又は電話線に接続されているデータサーバのように、これらの料金通知センタを通じてデータ通信線に直接アクセスできる。
【００１９】
この方法の好適な実施形及び料金通知センタの好適な構成は、料金通知センタ内の暗号化が乱数を使用して実行されることを特徴とする。
【００２０】
乱数が料金通知センタの保護された領域内で生成されることが好ましい。
【００２１】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、乱数が料金通知センタから送信されるセッション鍵と顧客システムの保護モジュールの公開鍵とによって暗号化されることを特徴とする。
【００２２】
料金通知センタがデータを個人鍵で署名することが好ましい。
【００２３】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、個人鍵が料金通知センタの特に保護された領域内に記憶されていることを特徴とする。
【００２４】
データが料金の要求ごとに顧客システムから料金通知センタに伝送されることが好ましい。
【００２５】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、料金通知センタが伝送されたデータに基づいて顧客システムの身元を確認することを特徴とする。
【００２６】
料金通知センタがこの料金通知センタによって暗号化されたデータを顧客システムに送ることが好ましい。
【００２７】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、料金通知センタから顧客システムに送信されたデータがこの顧客システムによって復号化され得ない第１成分を有すること、及び、これらのデータがこの顧客システムによって復号化され得る第２成分をさらに有することを特徴とする。
【００２８】
データのうちの顧客システム内で復号化可能な部分がこの顧客システムのＩＤに関する情報を有することが好ましい。
【００２９】
データのうちの顧客システム内で復号化可能な部分が料金通知センタ内で生成された乱数を有することが好ましい。
【００３０】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、データのうちの顧客システム内で復号化可能な部分が料金の高さに関する情報を有することを特徴とする。
【００３１】
最も定額の料金を顧客システム内でロードしなければならないときにだけ、データが顧客システムから料金通知センタに送信されることが好ましい。
【００３２】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、ハッシュ関数が料金通知センタ内で生成されることを特徴とする。
【００３３】
ハッシュ関数が送信データに関するステートメントと共に生成されることが好ましい。
【００３４】
方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、ハッシュ関数が受信され中間記憶された乱数と共に生成されることを特徴とする。
【００３５】
ハッシュ関数がロード処理ＩＤ番号と共に生成されることが好ましい。
【００３６】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、郵便料金支払証が論理データを有することを特徴とする。
【００３７】
郵便料金支払証が送信データに関する情報を有することが好ましい。
【００３８】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、論理データが暗号化された乱数に関する情報を有することを特徴とする。
【００３９】
論理データが暗号化されたロード処理ＩＤ番号に関する情報を有することが好ましい。
【００４０】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、論理データがハッシュ関数に関する情報を有することを特徴とする。
【００４１】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、郵便料金支払証が料金通知センタから伝送された情報とドキュメントの作成者から入力されたデータとの双方を有することを特徴とする。
【００４２】
郵便料金支払証はハッシュ関数を有し、このハッシュ関数は基準センタ（Ｖｏｒｇａｂｅｚｅｎｔｒｕｍ）から伝送された値とドキュメントの作成者から入力された値との組合わせから生成されるように、方法を実施すること又は顧客システム若しくは料金通知センタを構成することが好ましい。
【００４３】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、これらの方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成が以下の方法ステップを有することが好ましい：ドキュメントの作成者及び／又はこの作成者によって構築された顧客システムのＩＤが料金通知センタに伝送されることによって、顧客システム又はこの顧客システムに接続されている安全モジュールがロード処理を初期化する。
【００４４】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、乱数が料金通知センタ内で生成されることを特徴とする。
【００４５】
料金通知センタが、ロードＩＤ番号を生成し、一方では郵便センタだけがこのロードＩＤ番号と生成された乱数を復号化し引続きロードＩＤ番号を生成するようにこの生成された乱数と共に暗号化する方法で、方法を実施すること又は顧客システム若しくは料金通知センタを構成することが好ましい。
【００４６】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、他方では安全モジュールだけが顧客システム内で生成されたロードＩＤ番号と乱数を復号化できるように、この生成されたロードＩＤ番号がこの生成された乱数と共に暗号化されることを特徴とする。
【００４７】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、ハッシュ関数が料金通知センタの特に保護された領域内でロードＩＤ番号とその他のデータとから形成されることを特徴とする。
【００４８】
郵便料金支払証がハッシュ関数を有するように、郵便料金支払証が作成されるように、方法を実施すること又は顧客システム及び／又は料金通知センタを構成することが好ましい。
【００４９】
この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は、郵便料金支払証の有効性が郵便センタ内で検査されることを特徴とする。
【００５０】
郵便センタ内の検査が、郵便料金支払証中に含まれているデータを分析することによって実行されるように、方法を実施すること又は顧客システム及び／又は料金通知センタを構成することが好ましい。
【００５１】
検査部（Ｐｒｕｅｆｕｎｇｓｓｔｅｌｌｅ） は、郵便料金支払証中に含まれるデータからハッシュ関数を生成し、このハッシュ関数がこの郵便料金支払証中に含まれるハッシュ関数に一致するかどうかを検査し、一致しないときはこの郵便料金支払証を偽造されたものとして記録することを、この方法の好適な実施形並びに顧客システム及び料金通知センタの好適な構成は特徴とする。
【００５２】
本発明のさらなる利点，特徴及び好適なその他の構成は、図面に基づく以下の好適な実施形に記載されている。
【００５３】
以下の実施の形態は、ドイツ郵便株式会社の範囲内で提供される使用に基づいて本発明を説明する。しかしながら、本発明をその他の書類の郵便料金の別納に対して使用すること、特にその他の郵送会社の範囲内での使用に対して明らかに同様に可能である。
【００５４】
本発明は、郵便料金の別納の可能な新しい形態を提供する。顧客は、この新しい形態によって既存のプリンタ付きのパーソナルコンピュータ（ＰＣ），付加的なソフトウェア，場合によってはハードウェア及びインターネットへのアクセスを利用して手紙，はがき等上に郵便料金支払証をデジタル式に印刷できる。
【００５５】
顧客によって印刷された郵便料金支払証の料金を清算するための支払いは、いろいろな方法で実施可能である。例えば、記憶された預金が減る。この預金は、特にデジタル式に記憶されている。デジタル記憶が、例えば特別な顧客カード，標準のキャッシュカード又は例えばユーザのコンピュータ内に存在する仮想記憶器内で実行される。特に、郵便料金支払証の料金が印刷される前に、預金額が引き落とされる。この預金額は、借り方の方法の特に好適な実施形で引き落とされる。
【００５６】
図１中には、本発明の郵便料金支払証を郵便物に印刷する基本的なプロセスが示されている。この方法は、特に完全に循環しうる多数のステップを有する。このことは、特に好ましいものの必須ではない。以下に示した８つのステップは、同様に好ましいものの同様に必須ではない。
１．郵便会社の顧客が、（場合によっては付加的なソフトウェア／ハードウェア、例えばマイクロプロセッサ・チップカードを使用して）パーソナルコンピュータによってインターネットを通じて郵便料金の額を負担する。
２．徴収が、郵便料金の額に基づいて例えば顧客の口座の引き落としによって実行される。
３．顧客の電子財布内に記憶されている郵便料金の額から、預金があるまで、任意の額の有効な郵便料金支払証の料金が顧客自身のプリンタによって印刷され得る。
４．この顧客によって印刷された郵便料金支払証は、読取り可能な標記と機械的に読取り可能なバーコードを有する。このバーコードは、ドイツ郵便会社によって有効性を検査するためにチェックされる。
５．郵便料金が別納された郵便物は、ドイツ郵便会社によって提供された可能性、例えば郵便ポストや簡易郵便局を通じて出され得る。
６．郵便料金支払証に表示されているバーコード、特に２次元バーコードが、郵便センタ内で宛名自動読取装置によって読取られる。有効性が、プロダクションの間に論理妥当性チェックに基づいて検査される。
７．郵便料金支払証で読取られるデータは、特に対価保全のためにバックアップシステムに伝送される。
８．清算が、不正を確認するために負担した決算額とプロダクションされた郵便物との間で実行される。
【００５７】
特に、多数の当事者が郵便料金の別納に関与する。この場合、これらの当事者の特に好ましい分割が、図２中に示されている。
【００５８】
これらの示された当事者は、顧客，顧客システム及び郵便会社である。
【００５９】
顧客システムは、ハードウェアとソフトウェアを有する。このハードウェアとソフトウェアは、顧客によってパーソナルコンピュータで郵便料金支払証を別納するために使用される。顧客システムは、顧客との対話中に決算額の負担と記憶及び郵便料金支払証の印刷を制御する。顧客システムに対する個々の要素が、許可条件を制御する。
【００６０】
郵便会社は、郵便物のプロダクションを伝送し、必要な対価保全を実行する。
【００６１】
料金通知センタは、いろいろな方法で構成され得る：
・料金通知センタの稼働が、パーソナルコンピュータの郵便料金支払証の別納の信頼性アーキテクチャに関連して郵便料金支払証の対称な暗号化方法の使用を可能にする。これによって、郵便料金支払証の有効性の検査に必要な時間が短縮する。対称な方法の使用に対して必要なことは、同一の構成による料金通知センタと郵便センタの稼働である。このような加速したプロダクションは、非対称な信頼性要素を郵便料金支払証で使用した場合は不可能である。
・特に内部の改竄と外部の改竄を阻止するための全ての必要な信頼性要求の実現：
差出人の消印を押す場合とは違って、通信が、解放され潜在的に安全でないインターネットを通じて実行される。通信パス，インターネットサーバ及び改竄の内部の可能性へのアクセスが、より高い信頼性対策を必要とする。
【００６２】
郵便会社によって提供される暗号鍵の集中的な管理によって、信頼性の向上が可能である。郵便センタ内でのプロダクション時に関連する鍵が常に交換でき、鍵の長さが変更できる。
・対価保全に対する検査が、一貫した検査方法にしたがって可能であり、常に実行可能である。
・新規の契約加入者と契約の変更が、郵便会社の全ての必要なシステムに通知され得る。
対価保全が、特に郵便料金支払証の構成要素を確認しながら実行される。
さらに、取決めデータ（顧客データ／顧客システムデータ）が、中枢のデータバンクから取り決め通りに対価保全を検査するために必要であるシステムに伝送される。
【００６３】
郵便会社、特に郵便業務の営業者が、郵便業務会社のデータ保護命令（ＰＤＳＶ）のような法律上の規定を考慮して記憶すべきデータの大きさを決定する。基本的には、取り決め通りの確認，決算及び判定に対して並びに対価の正当性を証明するために必要である全てのデータが、これにしたがって記憶され得る。基本的には、これらのデータは受取人の名前及び場合によっては受取人の宛名／郵便番号以外の全ての発送物の情報である。
【００６４】
バックアップシステムは、貯金されている預金額が顧客システム内で郵便料金支払証として印刷される料金で実際に減額されるかどうかを検査する。
【００６５】
特に検出システムが、取決めデータを検出するために設けられている。
【００６６】
顧客と顧客システムのそれぞれの基本データ（例えば、安全モジュールＩＤ）を伴うパーソナルコンピュータによる郵便料金の別納のための取決めデータが、例えばその他の郵便料金の別納方法に対して使用可能なデータバンクによって準備され使用される。
【００６７】
存在する郵便料金別納データバンクを使用する場合、例えばデータバンク内のパーソナルコンピュータによる郵便料金の別納のための独立した部分領域が実行される。これらのデータは、料金通知センタと郵便センタの対価保全システム内で準備される。
【００６８】
このシステムがその他のシステムとデータ及び情報の交換を可能にするインターフェースを有することが特に好ましい。
【００６９】
図３中には、３つのインターフェースが示されている。
【００７０】
これらのインターフェースは、「許可」，「郵便料金支払証」及び「徴収」という。決算データが、決算インターフェースを通じて顧客システムと郵便業務の管理部との間で交換される。例えば、金額が決算インターフェースを通じて引き落としできる。
【００７１】
郵便料金支払証が郵便センタ又は郵送センタ内で読取られ検査され得るように、郵便料金支払証インターフェースはどのように郵便料金支払証が実現されるかを決定する。
【００７２】
図３中に示されたインターフェースの実行の場合、決算インターフェースと徴収インターフェースとが互いに分離されている。しかしながら、例えばキャッシュカード，クレジットカード又はデジタルマネー、特にデジタル貨幣による決算の場合、決算インターフェースと徴収インターフェースとが統合されていることが同様に可能である。徴収インターフェースは、決算インターフェースを通じて伝送された料金がどのように決算されるかを決定する。郵便料金の別納方法のその他のパラメータは選択された徴収インターフェースに依存しないものの、全システムの効率が効率のよい徴収インターフェースによって向上する。好ましい徴収の可能性は、借方記入と決算である。
【００７３】
以下に、郵便料金の別納方法の信頼性の目的が用途に固有な内容に関する信頼性要求によってどのようにして達成されるかを説明する。
【００７４】
この場合、この概念の焦点は、システムに対する信頼性要求の技術的な仕様に向けられている。顧客の申請通知，取消し通知や変更通知のような顧客システムが実行する必要のない信頼性に関連しない処理は、独立して決定され得る。技術的な処理がここで示された信頼性の基準に一致するように、これらの技術的な処理が顧客システムと顧客システムの開発者との間で特に決定される。
【００７５】
以下に記された信頼性の目的が、本発明の方法によって実現される。
・架空の郵便料金支払証及び汚れた郵便料金支払証、すなわち郵送に対して適正
に許可がおりていないか又はその他の理由から読取れない郵便料金支払証が無
効と認定される。
・複製品、すなわち郵送に対して適正に許可がおりている有効な郵便料金支払証の正確なコピーが後で確認され得る。
・顧客システムで任意に処理できる預金額のつり上げが阻止される。預金額の変更が、後でも確認可能であり、特にプロトコルリストに基づいて後で証明され得る。
・資格のない利用が確認され、第三者による権限のない利用が発生した場合に適正なユーザに負担を負わせない。
・これに対して、適正なユーザが気づかなくても、適正に伝送される電子データ又は有効で適正に発行された郵便料金支払証の不正使用が記録される。
・これに対して、プログラム変更による顧客システムの不正使用が記録される。
・これに対して、インターネットを介した未知のソフトウェア・エージェントによる顧客システムの資格のない利用が記録される。
・これに対して、アクセスソフトウェア（トロイアの木馬，危険な贈り物）によるＰＩＮの攻撃が記録される。
・これに対して、料金の引き落としの記入がされるものの、預金が引き落とされなかったという種類の、例えば料金通知センタのＩＤのなりすまし又は引き落とし処理の改竄による過剰負荷アクセス（サービス拒否，ＤｏＳ）が記録される。
・決算額の必要のない負担が、料金通知センタ内の技術的な安全措置によって不可能になる。決算額の必要のない負担は、例えば以下のことによって実行されうる：
・顧客の顧客システム内に固有の財布（預金額）をつり上げるために郵便料金通知センタのＩＤになりすます。
・犯人が安全モジュールの信頼性に重要な秘密を知って、それに基づいて気づかれないように偽の顧客システムを構築できるように、改竄した顧客システム又は虚偽の顧客システムによって認証した顧客システムになりすます。
・顧客システムと料金通知センタとの間の取り決め通りの通信を記録し、この通信を不正な意図で再利用する（リプレイアタック）。
・顧客システムが料金通知センタよりも高く負担する料金を受信するように、この顧客システムとこの料金通知センタとの間でリアルタイムでやりとりされる通信（顧客システム内で受信し送信するデータの流れ）を改竄する。
・第三者が料金を或る顧客のコストに上積みするように、顧客のＩＤ番号を不正に使用する。
・不完全な取り消しトランザクション。
【００７６】
これらの信頼性の問題の最初の２つの問題は、主にシステム概念と全システムの手段とによって解決される。最後の３つの問題は、特に信頼性モジュールのソフトウェアとハードウェアを実行することによって解決される。
【００７７】
以下に、信頼性の基準を高めるハードウェアの好適な構成を示す：
・ハードウェアの基本特性
１．全ての暗号化，復号化，復号／暗号化及び暗号検査処理が、顧客システムの暗号安全モジュールの権限のないアクセスに対して特に保護された領域内及び／又は料金通知センタの保護された領域内で実行される。付随する鍵が、これらの信頼性領域内に同様に記憶されている。
２．信頼性に関連するデータ及びルーチン（例えば、鍵，プログラム）が、権限のない変更から保護される。そして、秘密のデータ（例えば、鍵，ＰＩＮ）が、権限のない読取りから保護される。このことは、特に以下の手段によって保証される：
・場合によっては安全モジュールのソフトウェアの信頼性機構に連動するこの安全モジュールの構造。
・プログラムが、作成時又はロード処理の暗号的な保護時にだけ安全モジュール内にロードされる。
・信頼性に関連するデータ、特に暗号鍵のロードが、暗号的に保護される。
・モジュールが破損してしまうアクセスによる読取り前でも、秘密のデータを安全モジュール内で保護する必要がある。
ａ．認めうる経費によるアクセスがモジュールの寿命の間に不可能であるように、安全モジュール内の変更又は読取りに対してデータとプログラムを保護することが非常に必要である。この場合、必要な拒否に対して必要な経費をこの拒否から得られる利用に対して慎重に検討する必要がない。
ｂ．望まない機能は、安全モジュールによって実行してはならない。
・望まない付加機能及び望まない情報をさらに出力する余計なデータチャネル、特にインターフェース（サイドチャネル）が防御される。
安全モジュールの構造によって、アクセス者が秘密に保持すべきデータと鍵に関する情報を別の目的に対して想定されているインターフェースを通じて読み取ることができないことが保証される。検査される典型的な可能性は：
１．暗号解読の間の電力消費の変化から秘密データを推論することを試みるシングルパワーアタック（ＳＰＡ）及び分散型パワーアタック（ＤＰＡ）。
２．暗号解読期間から秘密データを推論することを試みるタイミングアタック。
以下に、データ処理の好適な特性を示す：
・ルーチンコントロール：
ルーチンコントロールが実行されることが特に好ましい。このルーチンコントロールは、例えば標準ＦＩＰＳ ＰＵＢ １４０−１にしたがった例えば状態マシンによって実行される。これによって、特別なトランザクション及びこのときに使用されるシステムの信頼性に関連するデータのルーチンが改竄できないことが保証される。
関与した機関、特にユーザは、安全モジュールによってトランザクションのルーチンを交換してはならない。
・完全性の情報：
１．情報のうちの全ての信頼性に関連する情報が、伝送の前後にシステムの構成要素内で適切な方法によって権限のない変更から保護される。
２．信頼性に関連する情報に対する変更が、チップカード保護された支払いシステムの構成要素間の伝送の間に確認される。完全性が損なうときは適切に応答する必要がある。
３．情報の権限のない入力が確認される。再入力された情報に対しても適切に応答する必要がある。
【００７８】
情報の権限のない変更と再入力が確認され得る場合、システムの標準情報がシステムコンセプトを決定することによって保証される。安全モジュールのソフトウェアは、確認が実際に実行されそれに応じて応答されることを保証する必要がある。信頼性に関連し作成者に固有の情報に対して（例えば、安全モジュールの保守のカスタム化の範囲内で）、それに応じて適切な機構が確定され使用される。
【００７９】
情報の完全性の保護に関連したこれらの情報は、特に安全モジュールの改竄から保護された領域内に記憶される。このような情報は、特にＩＤデータ，信頼性データ，シーケンスカウンタ又は料金である。
・ＰＩＮの秘密保持及び暗号鍵
１．保護された領域の外側のＰＩＮは平文で伝送してはならないものの、特に平文の伝送が、全システムと顧客システム内に存在するハードウェア要素　（キーボード，モニタ）とのユーザに対する使いやすさの理由からパーソナルコンピュータの郵便料金の別納時に許可される。しかしながら、ＰＩＮが平文で処理されるか又は記憶される局所的なシステム要素は最小限に低減されている。ＰＩＮの保護されない伝送は実行してはならない。
２．暗号鍵は、保護されない環境における電子伝送経路上では決して平文で伝送してはならない。暗号化鍵がシステム要素内で利用されるか又は記憶される場合、これらの秘密鍵を権限のない読み取りと変更から保護する必要がある。
３．システム要素は、消耗する探索に基づいてＰＩＮを決定する可能性を具備してはならない。
・プロトコル化
１．全てのデータが、顧客システム内部でプロトコル化される。これらのデータは、該当するルーチンを再構築するために必要になる。さらに、改竄の疑いが強いエラー状況（Ｆｅｈｌｅｒｆａｅｌｌｅ）もプロトコル化される。
２．記憶されたプロトコルデータは、権限のない変更から保護する必要があり、かつ評価機関に確実に伝送され得る。
・その他のアプリケーションの処理
その他のアプリケーションが安全モジュール内で同時に処理される場合、これによってパーソナルコンピュータ郵便料金別納システムの信頼性に影響を及ぼしてはならない。
【００８０】
データの信頼性が以下の手段によってさらに上がる：
・秘密データを一時記憶器から消去する。
・（例えば、カスタム化の範囲内で）作成者に固有の機能の安全な実行；例えば、三重ＤＥＳ又は秘密のカスタム化データを暗号化する対照的な方法の使用。四つ目原理（Ｖｉｅｒ−Ａｕｇｅｎ−Ｐｒｉｎｚｉｐ）による分割された秘密（例えば、鍵の半分）の形態の平文鍵のロード（Ｅｉｎｂｒｉｎｇｅｎ）。
・安全でない付加機能（例えば、システムの鍵を有する自由に選択可能なデータの暗号化，復号化又は信号化）が存在してはならない；鍵の機能の交換が可能であってはならない。
その他の観点
・顧客システム内で使用される安全モジュールのほかに、その他の安全モジュールも検査する必要がある：特に、いろいろな認証局（ＣＡ）の安全モジュールを安全モジュールの作成時に検査する必要がある。
・顧客システムソフトウェアのパーソナルコンピュータ側の部分もその信頼性に関連するタスク（例えば、ＰＩＮ入力）に関して検査する必要がある。
・安全モジュールからユーザにＰＩＮを安全に伝送する（例えば、ＰＩＮ文書の送信）を保証する方法を顧客システムの作成者によって提供する必要がある。このような概念が、信頼性と監視を検査することができる。
・作成者の環境、特に鍵のロード等の信頼性；信頼性代理者（Ｓｉｃｈｅｒｈｅｉｔｓｂｅａｕｆｔｒａｇｔｅ）、一般に：規定された方法にしたがう作成者による構成的な信頼性対策の許可。詳しくは：
鍵の管理：
１．鍵の割り当て，管理，場合によっては一定の順番の交換及び取り替えのため、制御を実行する必要がある。
２．信頼性を落とす疑いのある鍵は、全システム内でもはや使用してはならない。
【００８１】
安全モジュールの作成時とカスタム化時の好適な手段は：
１．安全モジュールの作成とカスタム化（秘密鍵，場合によってはユーザに固有のデータの最初のロード）をプロダクション環境（Ｐｒｏｄｕｋｔｉｏｎｓｕｍｇｅｂｕｎｇ） 下で実施する必要がある。このプロダクション環境は、
・鍵の信頼性がカスタム化時に低下し、
・カスタム化処理が不正に又は権限なく実行され、
・権限のないソフトウェアとデータがロードされ、
・安全モジュールが盗まれることを阻止する。
２．信頼性に関連する機能を実行する権限のない構成要素（コンポーネント）がシステム内にロードされ得ないことを保証する必要がある。
３．全ての安全モジュールの稼働変化を連続して記録する必要がある。
説明：
安全モジュールの稼働変化の記録には：
・作成データ及びカスタム化データ、
・残り容量／残り時間、
・修復と保守、
・稼働停止（Ａｕｓｓｅｒｂｅｔｒｉｅｂｎａｈｍｅ）
・安全モジュールを有するデータファイル，ドングル，クリプト，サーバ又はチップカードのようなデータ記憶器の紛失又は窃盗、
・作成データとカスタム化データ、
・アプリケーションのロード、
・アプリケーションの変更、
・鍵の変更、
・稼働停止、
・紛失又は窃盗がある。
信頼性アーキテクチャ
基本的な信頼性アーキテクチャが、パーソナルコンピュータの郵便料金の別納に対して設けられる。このパーソナルコンピュータの郵便料金の別納は、いろいろに存在する用途の利点に関連し、簡単な手段で信頼性をより向上させる。
【００８２】
特に信頼性アーキテクチャは、主に３つのユニットを有する。これらのユニットは、好適な配置で図４中に示されている：
・料金通知センタ。顧客とその顧客の顧客システムのＩＤがこの料金通知センタ内で既知である。
・安全モジュール。この安全モジュールは、顧客によって改竄不可能なハードウェア／ソフトウェア（例えば、オフラインの場合のドングル若しくはチップカード又はオンラインの場合の同価値のサーバ）として顧客システム内の信頼性を保証する。
・郵便センタ。この郵便センタ内では郵便料金支払証の有効性が検査されるか又は料金と郵便料金支払証に対する改竄が確認される。
以下に、料金通知センタ，顧客システム及び郵便センタ内で実行される個々の処理ステップを原理図の形態で示す。これに対して、正確な技術的な通信処理は、この原理図と相違する（例えば、ここで示された伝送を得るための多数の通信ステップ）。特にこの図では、身元確認されかつ認証された通信相手間での秘密でかつ完全な通信が前提条件になる。
顧客システム
０．鍵が、ロードシステム内部で生成され、引き続き顧客システムに伝送される。特にこの鍵が、暗号化されて場合によってはデジタル式に信号化される。特に、鍵がデジタル式のエンベロープ内に存在することが好ましい。
１．料金通知センタだけが復号化を実行することができるように、顧客システムの一義的なＩＤ番号（安全モジュールＩＤ）が安全モジュールによって暗号化され料金通知センタに伝送される。特に好適な実施形では、問い合わせが料金通知センタの公開鍵によって暗号化され、安全モジュールの個人鍵によってデジタル署名される。これによって、決算額の引き落としごとの問い合わせが同一のフォーム（Ｇｅｓｔａｌｔ） を有し、そして決算額が不正に引き落とされうること（リプレイアタック）が阻止される。
２．顧客システムからの暗号処理された情報が、決算額の負担の範囲内で料金通知センタに伝送される。顧客も第三者もこれらの情報を復号化できない。
【００８３】
実際には、通信相手（料金通知センタ又は安全モジュール）の公開鍵による非対称な暗号化が使用される。
【００８４】
鍵を事前に交換する可能性の場合、対称な鍵が同様に使用される。
料金通知センタ
３．特に安全モジュールのＩＤ番号（安全モジュールＩＤ）が、料金通知センタ内で復号化される。
４．この安全モジュールＩＤは、データバンクの郵便料金別納内の問い合わせによってドイツ郵便会社の顧客に割り当てられる。
５．１つの乱数が、料金通知センタ内で生成される。
【００８５】
この料金通知センタ内では、安全モジュールＩＤの一部，決算額の大きさ等を含むロード処理ＩＤ番号（Ｌａｄｅｖｏｒｇａｎｇｓｉｄｅｎｔｉｆｉｋａｔｉｏｎｓｎｕｍｍｅｒ） が生成される。
６．一方では顧客システムがこのＩＤ番号と生成された乱数を復号化できないように、このロードＩＤ番号がこの生成された乱数と一緒に暗号化される。実際には、この暗号化は、ＴＤＥＳにしたがった対称な鍵によって実行される。この対称な鍵は、料金通知センタと郵便センタ内だけに存在する。この場所で対称な鍵を使用することは、プロダクションによる迅速な復号化方法にしたがった要求に起因している。
７．他方では顧客システム内の安全モジュールだけがこのロードＩＤ番号と生成された乱数を復号化できるように、このロードＩＤ番号がこの生成された乱数と一緒に暗号化される。
８．ロード処理ＩＤ番号及び乱数の異なって暗号化された複数の対が、顧客システムに伝送される。顧客も第三者もこれらの情報を復号化できない。郵便局固有の特に対称な鍵を料金通知センタ内と郵便センタ内で単独で管理することによって、鍵が常に交換され得、鍵の長さが必要に応じて変更され得る。これによって、高い改竄信頼性が簡単に保証される。
顧客システム
９．顧客システム内の安全モジュールが暗号化された乱数を復号化できるように、この暗号化された乱数は、顧客システムの信頼性モジュール内で復号化され記憶される。
１０． 顧客は、郵便料金支払証の範囲内で郵送に固有の情報又は郵送データ（例えば、郵便料金，郵便物の種類等）を入手する。これらの情報又はデータは、安全モジュール内に伝送される。
１１． ハッシュ関数が、料金通知センタ安全な領域内で特に以下の情報から生成される。
・郵送データから成る主な情報（例えば、郵便料金，郵便物の種類，日付，ＰＬＺ等）、
・（決算額の負担の範囲内で受け取った）中間記憶された乱数、
・場合によってはロード処理ＩＤ番号。
【００８６】
特に以下のデータが、郵便料金支払証中に伝送される：
・平文の郵送データから成る主な情報（例えば、郵便料金，郵便物の種類，日付，ＰＬＺ等）、
・料金通知センタからの暗号化された乱数と暗号化されたロード処理ＩＤ番号、及び、
・安全モジュール内部で生成された郵送データ，受け取って中間記憶された乱数及びロード処理ＩＤ番号から成るハッシュ関数。
郵便センタ
１１． 郵便センタ内で最初に検査される。郵便料金支払証中に伝送された郵送データが郵便物と一致しない場合は、偽造の郵便料金支払証，架空の郵便料金支払証又は汚れた郵便料金支払証が存在する。その郵便物を対価を保全する部署に引き渡す必要がある。
１２． 決算額の範囲内で顧客システムに伝送された乱数及びロード処理ＩＤ番号が、郵便センタ内で復号化される。これに対して、（対称な）鍵が郵便センタ内で１つだけ必要である。しかしながら個別の鍵を使用する場合は、この代わりに多数の鍵を使用する必要がある。
１３． 以下の情報から成るハッシュ関数が、安全モジュール内と同様な方法にしたがって郵便センタ内で生成される：
・郵送データから成る主な情報、
・復号化された乱数、
・復号化されたロード処理ＩＤ番号。
１４． 郵便センタ内では、それ自身で生成されたハッシュ関数が伝送されたハッシュ関数と比較される。両ハッシュ関数が一致した場合、その伝送されたハッシュ関数は、決算額の範囲内で用金通知センタにも伝送された乱数によって生成されたものである。したがって、本当に有効な決算額と安全モジュールに公開された郵送データの双方が重要である（妥当性検査）。復号化し、ハッシュ関数を生成し、そして２つのハッシュ関数を比較する経費は、署名検査の経費に一致する。しかしながら、対称的な復号化のために、この署名検査に比べて時間的な利点がある。
１５． ロードされる決算額と郵便料金支払証の額との差額が、後でバックアップシステム内の検証試験によって確認され得る（バックアップシステム内での郵送のダブり，差引残高に関する検査）。
【００８７】
示された基本的な信頼性アーキテクチャは、決算額の独立して保護する管理　（財布機能），顧客システムと料金通知センタとの間の通信の保護，顧客システムと料金通知センタとの相互の身元確認及び新規の顧客システムを確実に企業登録（Ｂｅｔｒｉｅｂｓａｕｆｎａｈｍｅ）するための初期化を有さない。
【００８８】
信頼性アーキテクチャへのアクセス
この記された信頼性アーキテクチャは、以下のためにアクセスに対して安全である：
・第三者は、インターネット内で記録された（コピーされた）顧客システムと料金通知センタとの間の良好な通信を不正な目的で利用できない（リプレイアタック）。
・第三者又は顧客は、料金通知センタに対して改竄した顧客システムによって取り決め通りの顧客システムを使用することができない。第三者又は顧客が、安全モジュール内部で生成されないでその第三者又は顧客に既知である乱数とセイフボックスＩＤの伝送を本当であると思わせた場合、決算額のロードが、独立に実行されるユーザの名前と暗証による正当な顧客の身元確認に対して又はその顧客に絶対に知られてはならない安全モジュールの個人鍵の知識に対して失敗する。（したがって、安全モジュール内で鍵を生成するための初期化処理及び顧客システム提供者による公開鍵の認証を適切に実行する必要がある。）
・第三者又は顧客は、ほんとうと思わせた料金通知センタによって有効な決算額を顧客システムにロードできない。第三者又は顧客が、料金通知センタの機能を本当と思わせた場合、郵便センタ内で取り決め通りに復号化される暗号化されたロード処理ＩＤ番号をこの本当と思わせた料金通知センタに生成させることは不可能である。さらに、料金通知センタの公開鍵の認証は偽造され得ない。
・顧客は、料金通知センタを通さないで郵便料金支払証を作成することはできない。この郵便料金支払証のロード処理ＩＤ番号が郵便センタ内で有効として復号化され得るように、この郵便料金支払証のロード処理ＩＤ番号は暗号化されている。
【００８９】
特に探索時にデータの信頼性を高めるためには、多数の乱数をハッシュ関数の作成のために使用する必要がある。
・乱数の長さは、それ故に可能な限り大きく、特に少なくとも１６バイト（１２８ ビット）である。
【００９０】
使用される信頼性アーキテクチャは、復号化のために特定の場所、特に郵便センタ内で鍵を既に保管する必要なしに顧客に固有の鍵を使用するという可能性によって公知の方法よりも優れている。この好適な構成は、Ｉｎｆｏｒｍａｔｉｏｎ−Ｂａｓｅｄ Ｉｎｄｉｃａｎ Ｐｒｏｇｒａｍ （ＩＢＩＰ）による公知のシステムとは著しく相違する。
信頼性アーキテクチャの利点
この説明した信頼性アーキテクチャは、米国のこのＩＢＩＰモデルに比べて以下の特徴を有する：
・実際の信頼性が、ドイツ郵便会社（料金通知センタ，郵便センタ，対価保全センタ）のシステム内で保証され、したがって完全にドイツ郵便会社の影響の範囲内にある。
・署名が郵便料金支払証内で使用されるのではなくて、技術的に同価値でかつ同様に安全に（対称的に）暗号化されたデータ及びハッシュ関数が使用される。これに対して、最も簡単な場合は、対称的な鍵だけが使用される。この鍵は、ドイツ郵便会社の影響の範囲内だけにあり、したがって容易に交換可能である。
・郵便センタ内では、（抜き取り検査だけではなくて）全ての郵便料金支払証の検査が可能である。
・信頼性概念が、それ自体閉ざされている簡単な検査ループに基づく。この検査ループは、これに適合されたバックアップシステムと一致している。
・このシステムは、そうでなければほとんど確認不可能なコピーを確認可能にする。
・有効でない架空の郵便料金支払証が、この方法によって高い精度で確認可能である。
・妥当性検査のほかに、ロード処理ＩＤ番号が、全ての郵便料金支払証でリアルタイムで検査できる。
郵便物の種類
例えば発送業務による事前の決定にしたがった（追加サービスを含む）”Ｂｒｉｅｆ ｎａｔｉｏｎａｌ”及び”Ｄｉｒｅｋｔ Ｍａｒｋｅｔｉｎｇ ｎａｔｉｏｎａｌ” のような発送業務の全ての郵便物の郵便料金が、パーソナルコンピュータによって別納され得る。
【００９１】
小包便や速達便のようなその他の郵送形態に対しても同様に適用可能である。
【００９２】
料金通知センタによって最大に請求され得る料金は、適切な額に固定される。この額は、顧客の要求と郵便業務の要求に応じて選択され得る。その一方で、最大で何百通のダイレクトメールに相当する料金が、私的な顧客の範囲内での使用に対して特に好ましい場合は、より高額な料金が、多数の顧客の適用に対して設定される。約 ５００通以内のダイレクトメールでの額は、要求の多い個人の家と自由業者と中小企業に対して適している。財布内に記憶された額は、特に２倍の料金をシステム技術的に超えてはならない。
郵便料金を誤って別納した郵便物
有効に郵便料金を別納しかつ郵便料金を誤って別納した郵送できない既に印刷された手紙，封書等が、顧客の貸方に記入される。
【００９３】
適切な手段によって、例えば郵便センタに到着した郵便物の押印によって、郵便物が既に郵送されたかどうかを確認することが可能である。これによって、顧客が既に郵送された郵便物を受取人から返送され、そしてこれらの郵便物を郵便業務会社、例えばドイツ郵便株式会社での貸方記入のために提出することが回避される。
【００９４】
郵便業務会社、例えばドイツ郵便会社の中枢的な部署の返送することは、決算額のデータの清算による対価保全をかなりの程度で可能にし、かつ最も多い送達理由に関して知ることを可能にする。これによって、返送分担額の低減を目的とした設定条件の変更による追徴の可能性が場合によっては存在する。
料金の有効性
顧客に請求される決算額は、対価保全の理由から例えば３ヶ月だけ有効である。適切な指示を顧客との取決めで記録する必要がある。郵便料金の別納額が３ヶ月以内に調達できない場合、郵便料金支払証を新たに作成するための料金通知センタのコンタクトを顧客システムによって記録する必要がある。決算額の規定通りの請求時のようなこのコンタクトの場合、古い決算額の残高が、新たに支払われる決算額に加算され、新たなロード処理ＩＤ番号下で顧客によって任意に処理される。
特別な経営上の処理
基本的に、郵便料金支払証は任意の形態を有し得る。この郵便料金支払証中に含まれる情報が、この形態で再生成され得る。しかしならが、郵便料金支払証が少なくとも領域的にバーコードの形態を有するように、郵便料金支払証を構成することが好ましい。２次元バーコードのこの示された手段及びそこから生じる対価保全の場合、以下の特徴をプロダクションで考慮する必要がある：
パーソナルコンピュータで郵便料金を別納した郵便物は、全ての提出可能性によって、郵便ポストによっても出され得る。
【００９５】
郵便料金別納システムのインターフェースに関連した構成要素の作成者、特に顧客システムの作成者及び／又は運営者に対する許可条件を決定することによって、示された信頼性手段の保守がさらに向上する。
優先規格，標準及び基準Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｏｓｔａｇｅ Ｍｅｔｅｒ Ａｐｐｒｏｖａｌ Ｒｅｑｕｉｒｅｍｅｎｔｓ （ＩＰＭＡＲ）
全ての規格や標準のような使用と同様に、特に文書の実際の表現様式の規則Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｏｓｔａｇｅ Ｍｅｔｅｒ Ａｐｐｒｏｖａｌ（ＩＰＭＡＲ ），ＵＰＳ Ｓ−３０が公知である。本明細書では、このＩＰＭＡＲ を参照する。ここで記された全ての「要求」の遵守は、顧客システムが有効である限り可能である。
デジタル郵便切手：アプリケーション，セキュリティ・デザイン
全ての規格や標準のような使用と同様に、基本的には、文書の実際の表現様式の規則であるデジタル郵便切手：アプリケーション，セキュリティ・デザイン　（ＵＰＵ：技術標準マニュアル）が公知である。本明細書では、このＵＰＵを参照する。この文書の「規定」内容の遵守及び「情報」内容の十分な考慮は、顧客システムが有効である限り可能である。
特に、郵便業務会社の規定と規則が同様な用途で公知である。
郵便業務会社の全ての規格や標準のような全ての法律上の規則を同様に満たすこのようなシステムだけを認可することによって、システムのデータ信頼性と信頼性がユーザに対して簡単に保証される。
その他の法律，条例，要綱，規則，規格及び標準
基本的に、その都度有効な表現様式の全ての法律，条例，要綱，規則，規格及び標準を使用できる。これらの法律，条例，要綱，規則，規格及び標準は、技術的な顧客システムを改良し稼働させるために具体的に明記する必要がある。
システム技術的な相互通用性
システム技術的な相互通用性は、顧客システムのインターフェースの機能又はインターフェースの使用説明書中に詳細に記された基準の遵守に関する。
インターフェース決算額
通信路，プロトコル
通信が、インターフェース決算額を通じて、特にプロトコルＴＣＰ／ＩＰ及びＨＴＴＰに基づく公開されたインターネットを通じて実行される。データが、ＨＴＴＰによって選択的に交換され得、ＳＳＬによって暗号化され得る （ｈｔｔｐｓ）。ここでは、必要な伝送の目標処理が実行されている。
【００９６】
このデータ交換は、特にＨＴＭＬとＸＭＬでコード化されたデータの範囲内で実行される。ＨＴＭＬ側のテキスト的な内容とグラフィック的な内容を顧客システム内で実行する必要がある。
【００９７】
通信の観点では、信頼できるＨＴＭＬバージョンにアクセスすること、及びフレーム，埋め込まれたオブジェクト（アプレット，アクティブＸ等）、場合によっては動画化したＧＩＦを省略することが好ましい。
決算額のロードの申し込み（安全モジュールから料金通知センタへの最初の伝送）
安全モジュールから料金通知センタへの最初の伝送の範囲内では、安全モジュールの認証及び動作指標Ａが暗号化されず署名されずに伝送される。
申し込みに対する応答（料金通知センタから安全センタへの最初の返事）
料金通知センタの応答は、料金通知センタの固有の認証，暗号化されたセッション鍵及びこの暗号化されたセッション鍵のデジタル署名を含む。
安全モジュールから料金通知センタへの２回目の伝送
この伝送の範囲内では、安全モジュールが、新規に暗号化されたセッション鍵と利用データ（前もってロードされた決算額の大きさ，実際の決算額の残高，全ての決算額の発生する記録，最後のロード処理ＩＤ番号）を有するデータセットとを（料金通知センタの公開鍵によって全て非対称に暗号化して）料金通知センタに送信する。同時に、この安全モジュールは、これらの暗号化されたデータのデジタル署名を料金通知センタに送信する。同時に、顧客システムが、暗号化しなくて署名しなかったその他の利用プロトコル又は利用プロファイルを料金通知センタに送信する。
【００９８】
利用データが利用プロトコル内に書き込まれること、及び、利用プロトコル及び／又はそこに記憶された事項がデジタル署名されることが好ましい。
料金通知センタから安全モジュールへの２回目の応答
料金通知センタが、対称に暗号化された乱数及び対称に暗号化されたロード処理ＩＤ番号を安全モジュールに伝送する。さらに、料金通知センタは、安全モジュールの公開鍵によって作成したロード処理ＩＤ番号，生成された乱数，安全モジュールに関するログイン情報及び新規のセッション鍵を安全モジュールに伝送する。これらの伝送される全てのデータが、さらにデジタル署名される。
安全モジュールから料金通知センタへの３回目の伝送
３回目の伝送の範囲内では、新規のセッション鍵及び新規のロード処理ＩＤ番号が、問題のない通信を確認するための利用データと一緒に暗号化されデジタル化された形態で安全モジュールから料金通知センタに伝送される。
料金通知センタから安全モジュールへの３回目の応答
この３回目の応答の場合、料金通知センタが、暗号方法を使用することなしに伝送結果を証明する。
デインストレーション
顧客システムのデインストレーションの可能性が、顧客によって可能でなくてはならない。
【００９９】
インターフェース決算額を郵便に固有の料金通知センタの概念によって技術的に詳しく説明する。
利用プロトコル及び利用プロファイル
顧客システム内では、郵便料金支払証の各作成の範囲内でプロトコルに書き込む必要がある。このプロトコルの書き込みは、−デジタル署名した−その都度の郵便料金支払証の全てのデータを含まなくてはならない。さらに、この書き込みの手動の消去が検査時に確認されるように、安全モジュールの各エラー状態がプロトコル内で記録されなくてはならない。
【０１００】
利用プロトコルは、料金通知センタとの最後の通信以降に常に利用データの評価書を有する。
【０１０１】
顧客システムが顧客に存在する要素と中枢に（例えば、インターネット内に存在する要素とに分割されている場合、利用プロトコルは、特に中枢の要素内に設けなくてなならない。
インターフェース郵便料金支払証
構成要素及び（郵便料金支払証の）作成
顧客システムは、ドイツ郵便会社の基準又は一般的なＣＥＮ標準及びＵＰＵ標準の範囲に正確に合致するパーソナルコンピュータの郵便料金支払証を作成できることが必要ある。
【０１０２】
パーソナルコンピュータの郵便料金支払証は、特に以下の３つの要素から構成される：
・郵便物に固有の情報が機械的に読取り可能な形態で表示されている２次元のユニットコード，バーコード又はマトリックスコード。（目的：ドイツ郵便会社のプロダクションと対価保全の自動化。）
・ユニットコードの重要な部分を読取り可能な形態で表示する平文テキスト。（目的：顧客用の管理可能性並びにドイツ郵便会社のプロダクション及び対価保全における管理可能性。）
・郵便業務会社、例えばドイツ郵便会社を示す例えばポストホルンのような標識。
データ内容の内訳
パーソナルコンピュータの郵便料金支払証のユニットコード及び平文は、以下の情報を有する：
【０１０３】
【表１】

【０１０４】
ここでは、郵便料金支払証の内容だけが記されている。番地を示す内容に関する郵便業務会社の規定が、その有効性を不変に維持する。
書類上への物理的な貼付の細則（レイアウト）
郵便料金支払証は、好ましくは宛名領域において郵便物上の宛名の左上に貼付されている。
【０１０５】
宛名領域は、郵便業務会社の規準のその都度有効な表現様式で規定される。したがって、特に以下の郵便料金支払証の貼付が可能になる：
・封筒上への印刷
・粘着シール上への印刷、又は、
・書簡の印刷が窓を通して完全に目視可能であるような窓付き封筒の使用。
特に以下のことが、郵便料金支払証の個々の要素に対して成立する：
・データマトリックス方式のユニットコードがまず使用される。このユニットコードの個々の画点の一辺が、少なくとも ０．５ｍｍでなくてはならない。読取り技術的な条件を考慮すると、好ましくは最少画素が ０．５ｍｍのデータマトリクス方式の２次元バーコードを使用しなくてはならない。場合によっては、画素の大きさを ０．３ｍｍに減少させる選択がある。
１画素当たりの表示の大きさが ０．５ｍｍである場合、全てのデータが説明したように入力したときに、全バーコードの一辺の長さは約 １８ｍｍ 〜 ２０ｍｍ になる。画素の大きさが ０．３ｍｍのバーコードをＡＬＭで読取ることに成功した場合は、一辺の長さを約 ０．３ｍｍに短くすることができる。
細則を同一データ内容のその他のバーコード（例えば、Ａｚｔｅｃ ）の使用に拡張することが可能である。
郵便料金支払証の個々の要素のレイアウトと位置決めの好適な実施形が、図５中に例示的に示されている。
「限界」値は、 ４５ｍｍ × ９０ｍｍ の大きさの窓付き封筒に示された窓の高さである。ここでは、約 １３ｍｍ の一辺の長さのデータマトリックスコードが示されている。この提言されているデータ領域を使用する場合、このデータマトリクスコードは、 ０．３ｍｍの画素分解能のときだけ可能である。 ２４ｍｍ の一辺の長さのコードが、任意の高さに関して宛名の記入用に十分な余白を残さない。
印刷の品質及び読取り能力
顧客システムの作成者は、許可方法の範囲内で郵便料金支払証の間違いのない印刷に対して責任がある。そして、顧客は、後の稼働中に郵便料金支払証の間違いのない印刷に対して責任がある。これに対しては、顧客が、ユーザーマニュアルと支援システムの適切な指示によって支持する必要がある。このことは、特にラベルの正確な貼付及び窓付き封筒の目視可能な領域以外の郵便料金支払証の　（一部の）滑って位置がずれることを阻止することにも当てはまる。
【０１０６】
郵便料金支払証の機械的な読取り能力は、使用される印刷の分解能とコントラストに依存する。黒色の代わりにその他の色も使用しなければならない場合は、より遅い読取り速度（ｇｅｒｉｎｇｅｒｅｎ Ｌｅｓｅｒａｔｅ） を考慮に入れる必要がある。これは、プリンタで適用される ３００ｄｐｉ（”ｄｏｔｓ ｐｅｒ ｉｎｃｈ”）の分解能の場合に高い印刷コントラストのときに、この要求される読取り速度が保証され得ることに起因する。このことは、１ｃｍ 当たり約 １２０個の画点に相当する。
試験印刷
顧客システムは、金額と大きさにおいて有効な郵便料金支払証に一致するものの、郵送用に定められてなくて、管理印刷とプリンタの微調整のために使用される郵便料金支払証を作成できることが必要である。
【０１０７】
特に試験印刷が郵送会社に識別可能な方法で実際の郵便料金支払証と区別されるように、顧客システムが構成されている。これに対して、文字「見本−郵送不可」が、例えば郵便料金支払証の中央に表記される。バーコードの少なくとも２／３が、この文字によって又はその他の方法で識別不能にしなければならない。
【０１０８】
適正な（別納済みの）郵便料金支払証のほかに、別個に認定された試験印刷以外は、０額面で印刷する必要がない。
顧客システム；基本システム；概要及び機能に対する要求：
基本システムは、ＰＣで郵便料金を別納するその他の要素間のリンクとして、すなわち料金通知センタと信頼性モジュールとプリンタと顧客との間のリンクとして使用される。この基本システムは、１つ又は多数のコンピュータシステム、例えば場合によってはネットワークによっても互いに接続され得る複数のＰＣから構成される。
【０１０９】
この基本システムは、顧客による全システムの快適な利用も保証する。
構成と信頼性に対する要求：
基本システムは、特に４つのステップを任意に処理可能である：
１．料金通知センタとの通信が説明したインターフェース決算額を通じて実行される。
２．安全モジュールに公表する必要のある全ての情報（決算額又はロード処理ＩＤ番号，個々の郵便料金の別納に対する郵便物に固有のデータ）が、この安全モジュールに対するインターフェースを通じて交換される。さらに、全てのデータ（暗号処理したデータ）が、これらのインターフェースを通じて安全モジュールと交換される。
３．プリンタがこのプリンタに対するインターフェースを通じて制御される。
４．ユーザ又は顧客が、このユーザ又は顧客に対するインターフェース（グラフィカルユーザインターフェース）を通じて全ての関連のある処理を可能な限り人間工学と相互に作用させることができる。
【０１１０】
さらに、以下のデータを基本システム内に記憶し処理しなくてはならない：
・ユーザに固有のセットアップ／データ、
・詳述した利用プロトコルと利用プロフィル、
・ＳＳＬを使用した場合：交換可能な証明、ＳＳＬの証明の有効性がこれらの証明によって証明され得る、及び、
・郵便業務会社の製品と価格に関する全ての関連情報。
機能範囲とルーチン
基本システムは、特に以下のルーチンをサポートする：
・ユーザの支援による最初のインストール、
・場合によっては決算額のロードと郵便料金支払証の作成に対する異なる権限の付与による；特に安全モジュールに対するユーザの身元確認、
・場合によっては多数のユーザの管理、
・決算額のロード時のユーザサポート（このとき、料金通知センタによってＨＴＭＬでコード化されたデータの形態で送信された情報の再生のサポート）、
・決算額のロード時の問題発生時のユーザサポート、
・ユーザに理解しやすい料金管理（口座透明性）、
・利用プロトコルの管理，利用プロファイルの評価及び利用プロトコル又は利用プロファイルの伝送、
・郵便料金支払証の作成時よ印刷時のユーザサポート（印刷すべき郵便料金支払証の見本のモニタ上での具体的な説明−ＷＹＳＩＷＹＧ ）、
・ドイツ郵便会社のサービス情報による妥当性保護された対価保全、
・電子支援システム、
・変更時のドイツ郵便会社の製品と価格に関する関連情報の自動的な実現並びに実行され終了されるこの実現に関する顧客情報、
・何回もの印刷と同一の郵便料金支払証の技術的な阻止
・顧客システムのデインストール
安全モジュール
機能及び信頼性レベル
安全モジュールは、ＦＩＰＳ ＰＵＢ １４０， Ｓｅｃｕｒｉｔｙ Ｒｅｑｕｉｒｅｍｅｎｔｓ ｆｏｒ Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｍｏｄｕｌｅｓ の意味の「安全モジュール」として顧客システムの実際の信頼性を保証する。この安全モジュールは、ハードウェア，ソフトウェア，ファームウェア又はこれらの組合わせから構成され、暗号論理部及び暗号処理部、すなわち暗号方法の管理部及びアプリケーション並びに料金の改竄を保護する記憶部を有する。
この安全モジュールが満たす必要のある要件は、
・信頼性標準に関しては例えばＦＩＰＳ ＰＵＢ １４０のような適切な規格によって規定され、
・郵便標準の遵守に関してはＦＩＰＳ ＰＵＢ １４０に記されているＵＰＵの刊行物”Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｏｓｔａｇｅ Ｍｅｔｅｒ Ａｐｐｒｏｖａｌ Ｒｅｑｕｉｒｅｍｅｎｔｓ （ＩＰＭＡＲ）” によって規定される。
【０１１１】
顧客システムに導入し稼働させるためには、ＦＩＰＳ ＰＵＢ １４０にしたがう−特に信頼性ステップ３（安全レベル３）にしたがう−安全モジュールとして導入方法の範囲内で適切に証明する必要がある。
安全モジュールの処理
安全モジュールは、特に初期化と料金通知センタとの通信とディアクティベーションとのために従来の操作のほかに主に以下の処理をサポートしなければならない。これらの処理は、補遺の後の部分Ｔｅｃｈｎｉｓｃｈｅ Ｂｅｓｃｈｒｅｉｂｕｎｇ Ｋｕｎｄｅｎｓｙｓｔｅｍ中に詳しく説明されている：
・鍵の作成
・公開鍵の発行
・証明の記憶
・署名の作成
・署名の検査
・証明の検査
・一時的な証明の記憶
・非対称な暗号化
・非対称な復号化
・乱数の作成
・セッション鍵の記憶
・２つのロード処理ＩＤ番号の記憶
・決算額の実際の記録値の記憶
・発生する記録値の記憶
・ユーザの身元確認
・決算額の有効性の状態出力
・決算額の記録値の状態出力
・発送人に固有のデータのハッシュ関数の作成
・ロードされた決算額の記録値の低減
・エラーのプロトコル化
・自己試験
・ディアクティベーション
自己試験
安全モジュールは、試験印刷時は使用されず、それ故にコンタクトもされない。
プリンタ
プリンタは、顧客システムの作成者に応じて商業的な標準プリンタでもよいし又は特注のプリンタでもよい。
【０１１２】
今日の大半のレーザプリンタ及びインクプリンタは、基本的にＰＣによる郵便料金の別納に適している。少なくとも３００ ｄｐｉ （ｄｏｔｓ ｐｅｒ Ｉｎｃｈ） の分解能のプリンタを推奨する。
顧客システム内部の処理
郵便料金支払証を作成する処理
郵便料金支払証を作成する場合、顧客は、顧客システムによって以下の部分処理実行する：
・安全モジュールに対するリンクの構築：安全モジュールに対するリンクが、基本システムによって構築される。
・ユーザの身元確認：ユーザの身元が、安全モジュールでパスワード／ＰＩＮによって個人的に確認され、この安全モジュールを起動させる。
・発送人に固有の情報の入力：顧客が、顧客システムのサポートによって必要な発送人に固有の情報を基本システムに入力する。この基本システムは、重要なデータを安全モジュールに渡す。
・郵便料金支払証の作成：基本システムは、発送人に固有のデータと安全モジュールからの暗号処理されたデータとから郵便料金支払証を作成する。
・郵便料金支払証の作成のプロトコル化：必要な各返送は、基本システムの利用プロトコルで決定される。顧客システムを顧客の局所要素と（例えば、インターネット内の）中枢要素とに分割する場合、この利用プロトコルを中枢要素に送る必要がある。
・通信関係の解除：全ての要求された郵便料金支払証が作成されると、通信関係が再び解除される。郵便料金支払証を新たに作成する場合は、−上述したように−ユーザの身元をまた確認する必要がある。
・試験印刷：この方法とは別に、郵便料金支払証の見本がモニタ上に表示できるように（ＷＹＳＩＷＹＧ ）、（有効でない）試験印刷物が印刷できるように、ユーザの行動を大幅に拡張させることが可能である。後の段階になって初めて、安全モジュールに関する上述した処理が実行される。
【０１１３】
この技術的なシステムの使用は、目的に合った組織的な手段によって守られる。その結果、郵便料金支払証の技術的に記録可能な何回もの発行が、発送人の取引条件に対する違反ともみなされる。
【０１１４】
さらに、郵便料金支払証が自動認識装置内でより良好に認識され得るように、郵便料金支払証の印刷に関する、特に印刷の品質に関する適切な技術パラメータを設けることが好ましい。
【０１１５】
システムを検査するため、適切な品質安全システムが、特に規格ＩＳＯ ９００１ ｆｆ． に基づいてもよい。
【図面の簡単な説明】
【図１】
本発明の方法の原理を示す。
【図２】
郵便物に郵便料金支払証を印刷するときに関与する当事者を強調した図１中に示された原理を示す。
【図３】
図１と図２中に示された郵便物に郵便料金支払証を印刷するシステムのインターフェースを示す。
【図４】
本発明の方法で使用される信頼性機構の原理を示す。
【符号の説明】
ＢＺ　　郵便センタ
ＫＳ　　顧客システム
ＬＺ　　ロードセンタ

Claims (34)

1. 郵便料金支払証を印刷した郵便物を管理する方法にあって、この場合、顧客システムが料金通知センタからデータ線を経由して料金をロードし、この場合、この顧客システムは、郵便物への郵便料金支払証の印刷を制御し、この場合、この料金通知センタは、データパケットをこの顧客システムに送信する方法において、料金通知センタが、鍵を生成し、この鍵を顧客システムに伝送すること、データが、この顧客システム内で生成され、この料金通知センタがこれらのデータを復号化できるように、これらのデータがこの鍵で暗号化されること、これらのデータは、この顧客システムから料金通知センタに送信されること、料金通知センタがこれらのデータを復号化すること、この料金通知センタは、乱数を生成すること、この料金通知センタは、これらのデータをこの乱数と共に顧客システムに秘密の鍵とこの顧客システムの安全モジュールに既知の鍵との双方によって暗号化し、引き続きこうして暗号化されたデータを顧客システムに伝送することを特徴とする方法。
2. 乱数は、料金通知センタの保護された領域内で生成されることを特徴とする請求項１に記載の方法。
3. 乱数は、セッション鍵と公開鍵のうちの１つの鍵によって暗号化されることを特徴とする請求項１又は２に記載の方法。
4. 料金通知センタは、データを個人鍵によって署名することを特徴とする請求項１〜３のいずれか１項に記載の方法。
5. 個人鍵は、料金通知センタの特に保護された領域内に記憶されていることを特徴とする請求項４に記載の方法。
6. データは、料金の要求ごとに顧客システムから料金通知センタに伝送されることを特徴とする請求項１〜５のいずれか１項に記載の方法。
7. 料金通知センタは、伝送されたデータに基づいて顧客システムを認証することを特徴とする請求項１〜６のいずれか１項に記載の方法。
8. 料金通知センタは、この料金通知センタによって暗号化されたデータを顧客システムに送信することを特徴とする請求項１〜７のいずれか１項に記載の方法。
9. 料金通知センタから顧客システムに送信されたデータは、この顧客システムによって復号化され得ない第１成分を有すること、及び、これらのデータは、この顧客システムによって復号化され得る第２成分をさらに有することを特徴とする請求項８に記載の方法。
10. データのうちの顧客システム内で復号化可能な部分が、乱数とロード処理に関する情報を有することを特徴とする請求項９に記載の方法。
11. データのうちの顧客システム内で復号化可能な部分が、料金の高さに関する情報を有することを特徴とする請求項９又は１０に記載の方法。
12. 料金通知センタから顧客システムにデータを伝送するごとに、多数の郵便料金支払証を作成するのに十分な料金が伝送されることを特徴とする請求項１〜１１のいずれか１項に記載の方法。
13. ハッシュ関数が、料金通知センタ内で生成されることを特徴とする請求項１〜１２のいずれか１項に記載の方法。
14. ハッシュ関数は、送信データに関するステートメントと共に生成されることを特徴とする請求項１３に記載の方法。
15. ハッシュ関数は、受信され中間記憶された乱数と共に生成されることを特徴とする請求項１３又は１４に記載の方法。
16. ハッシュ関数は、ロード処理ＩＤ番号と共に生成されることを特徴とする請求項１３〜１５のいずれか１項に記載の方法。
17. 郵便料金支払証は、論理データを有することを特徴とする請求項１〜１６のいずれか１項に記載の方法。
18. 郵便料金支払証は、送信データに関する情報を有することを特徴とする請求項１７に記載の方法。
19. 論理データは、暗号化された乱数に関する情報を有することを特徴とする請求項１７又は１８に記載の方法。
20. 論理データは、暗号化されたロード処理ＩＤ番号を有することを特徴とする請求項１７〜１９のいずれか１項に記載の方法。
21. 論理データは、ハッシュ関数に関する情報を有することを特徴とする請求項１７〜２０のいずれか１項に記載の方法。
22. 郵便料金支払証は、料金通知センタから伝送された情報とドキュメントの作成者から入力されたデータとの双方を有することを特徴とする請求項１〜２１のいずれか１項に記載の方法。
23. 郵便料金支払証は、ハッシュ関数を有し、このハッシュ関数は、基準センタから伝送された値とドキュメントの作成者から入力された値との組合わせから生成されることを特徴とする請求項１〜２２のいずれか１項に記載の方法。
24. 以下の方法ステップを有することを特徴とする請求項１〜２３のいずれか１項に記載の方法：
    秘密部分が、料金通知センタ内で又は料金通知センタに接続され保護された領域内で生成され、引き続きロード処理に関する情報と共に顧客システム内の安全モジュールに伝送される。
25. 顧客システムが、暗号化された乱数を復号化することを特徴とする請求項２４に記載の方法。
26. ロードＩＤ番号が、顧客システムに伝送されることを特徴とする請求項２５に記載の方法。
27. ハッシュ関数が、安全モジュール内でロードＩＤ番号とその他のデータから生成されることを特徴とする請求項２６に記載の方法。
28. 郵便料金支払証がハッシュ関数を有するように、郵便料金支払証が生成されることを特徴とする請求項２７に記載の方法。
29. 郵便料金支払証の有効性が、郵便センタ内で検査されることを特徴とする請求項１〜２８のいずれか１項に記載の方法。
30. 郵便センタ内の検査は、郵便料金支払証中に含まれているデータを分析することによって実行されることを特徴とする請求項２９に記載の方法。
31. 郵便料金支払証が料金通知センタの暗号化されたデータを有するかどうかが、郵便料金支払証中に含まれているデータの分析時に検査されることを特徴とする請求項３０に記載の方法。
32. 検査部は、郵便料金支払証中に含まれるデータからハッシュ関数を生成し、このハッシュ関数がこの郵便料金支払証中に含まれるハッシュ関数に一致するかどうかを検査し、一致しないときはこの郵便料金支払証を偽造されたものとして記録することを特徴とする請求項１〜３１のいずれか１項に記載の方法。
33. 郵便物の郵便料金支払証を別納する顧客システムにおいて、この顧客システムは、データを暗号化する手段を有すること、この顧客システムは、暗号化されたデータを料金通知センタに出力するデータ出力部を有すること、この顧客システムは、料金通知センタによって別に暗号化されたデータを受信するデータ入力部を有すること、この顧客システムが料金通知センタから受信されたデータを完全に復号化できないように、安全モジュールが構成されていることを特徴とする顧客システム。
34. 請求項１〜３２のいずれか１項に記載の方法を使用する料金通知センタにおいて、この料金通知センタは、データ入力部を有し、この場合、顧客システムから送信された暗号データが、この入力部を通じて料金通知センタ内にロードされ、これらの受信されたデータを復号化する手段を有し、これらのデータを新たに復号化する手段を有し、この場合、これらのデータを暗号化するこの手段が、料金通知センタによって受信されたデータとは別にデータを暗号化するように、この手段は構成されている。

Images