【誤訳訂正書】
【提出日】平成19年9月20日(2007.9.20)
【誤訳訂正１】
【訂正対象書類名】明細書
【訂正対象項目名】特許請求の範囲
【訂正方法】変更
【訂正の内容】
【特許請求の範囲】
【請求項１】  顧客側システムが郵便物への郵便料金支払証の印刷を制御する、郵便料金支払証を郵便物に付ける方法において、印刷指令により作成した郵便料金支払証のうち、どの郵便料金支払証に対して郵便物の発送が行われなかったことがファイルに保存されることと、発送されない郵便物についての確認データを観客側システムがサーバーへ伝達することと、サーバーがその確認データを少なくとも一つの検査所へ転送することとを特徴とする方法。
【請求項２】  ファイルのデータが料金払戻しフォームに記入されることを特徴とする請求項１に記載の方法。
【請求項３】  ファイル及び／又は料金払戻しフォームは払戻し所に伝達されることを特徴とする請求項１或いは請求項２に記載の方法。
【請求項４】  伝達がサ−バ−へ行われることを特徴とする請求項３に記載の方法。
【請求項５】  伝達がｅ−メイルによって行われることを特徴とする請求項１乃至４のいずれか一項に記載の方法。
【請求項６】  伝達が一つのウエブサイトへ行われることを特徴とする請求項１乃至５のいずれか一項に記載の方法。
【誤訳訂正２】
【訂正対象書類名】明細書
【訂正対象項目名】発明の詳細な説明
【訂正方法】変更
【訂正の内容】
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、顧客システムが郵便物に郵便料金支払証の印刷を制御する、郵便料金支払証を郵便物に付ける方法に関する。
【０００２】
【従来の技術】  デジタル化したデ−タから符号化した形態に再生することにより郵便料金支払証を作成することは、公知である。この方法は、パ−ソナルコンピュ−タにおける好ましい実施のために以下に短く要約してＰＣ−郵便料金支払証と呼ばれるけれども、ＰＣ−郵便料金支払証との名称は、任意のコンピュ−タにおけるデジタルデ−タの作成が行われ得て、パ−ソナルコンピュ−タに限定されないから、決してこの名称に限定されないと理解すべきである。コンピュ−タと言う概念は、決して限定ではないと理解すべきである。これは、算出の実施に適した任意のユニット、例えば作業ステ−ション、パ−ソナルコンピュ−タ、マイクロコンピュ−タ、或いは算出の実施に適した回路でもよい。それは例えば個人的デジタルアシスタント（ＰＤＡ）にもできる。  
【０００３】
ドイツ郵便株式会社により計画された郵便料金前納手続の一つの紹介は、インタ−ネットに公表する公示を平易にした。
【０００４】
前述のＰＣ−郵便料金前納は、顧客が郵便料金額を支払って、郵便料金額から郵便料金支払証を作成し、プリンタで印刷すると言う多数のステップを包含する。この印刷は郵便料金支払証の有効性の検査を考慮できる機械読取り可能な二次元マットリックスコ−ドを含有する。
【０００５】
ＰＣ−郵便料金支払証を備える郵便物は郵便業務実行者に伝達され得る。郵便業務実行者は郵便料金支払証の有効性の検査後に郵便物を送付する。
【０００６】
郵便料金支払証の誤った使用の発生を阻止するために、適切な印刷指令が出されたら直ぐに、利用できる郵便料金額の減少が行われる。
【０００７】
この場合に、印刷指令の出力後であるが、郵便料金支払証の実際の印刷前に印刷データが失われ得ると言う問題が発生する。これは、例えばシステム破壊、電流中断、紙のよどみ、或いは空インキパトロ−ネ或いは空ト−ナ−カセットによる印刷の際に発生される。
【０００８】
【発明が解決しようとする課題】
この発明の課題は、郵便物を発送するために使用しなかった郵便料金支払証に関する郵便料金額による利用者の負担が回避されるために、この種の方法を新たに開発することにある。
【０００９】
【課題を解決するための手段】
この発明によると、この課題は、印刷指令により作成した郵便料金支払証が郵便物の発送と関連されていないことを表示するファイルに記入されることにより解決される。
【００１０】
郵便料金額の特に簡単な支払いは、ファイルが料金払戻しフォームに組み入れられることによって可能である。
【００１１】
目的に適って、ファイル及び／又は料金払戻しフォームが支払い箇所にて伝達されるような方法が実施される。
【００１２】
データ信頼性を向上させるために、サ−バ−への伝達が行われ、顧客側システムが発送すべきでない郵便物に関する確認データをサ−バ−へ伝達され、サ−バ−は確認データを少なくとも一つの検査箇所に転送することが、好ましい。
【００１３】
サ−バ−では、特に一つの通信ネットワ−クの一つの論理交点が重要であるが、インターフェイスを備えたそのようなコンピュ−タ、例えばそのような算出ユニットがサ−バ−として使用され得る。
【００１４】
確認データの伝達によって自動支払い可能性の誤使用が回避される。けれども、好ましくは郵便センタ−に配置されている検査箇所は、郵便センタ−の外部にも、一つ、或いは複数のセンタ−箇所に集約されていて、引き渡された郵便物は、その作成に使用された郵便料金支払証が顧客側システムにより送付されなかったと印されていたにもかかわず、認識できる。
【００１５】
それ故に、ファイルが、例えば料金払戻しフォームが符号化されないで顧客システムに記憶されることができる。郵便物を発送するために使用されなかった郵便料金支払証値に関する申告の誤使用入力は、郵便物が郵送しないものと見做される報告を郵便センタ−が得た郵送物の選別によって、見出され得る。
【００１６】
郵送データの手動入力も、この手動入力の誤使用が回避され得るから、システムにより許可され得る。
【００１７】
例えば、顧客側システムの利用者は発送されなかった郵送物に関する手動データを入力できる。この種の手動入力は選択的に−例えば符号化の採用によって−排除されるか、或いは許可される。手動入力が許可される場合には、顧客システムの利用者は、例えば利用者が郵便料金支払証を印した便箋を発送しないことを決定したならば、例えば郵便料金支払証を印した便箋を送付する前に郵便料金支払証を印した便箋を取り除くことができる。
【００１８】
データ信頼性の更なる向上は、支払うべき郵便料金支払証に関するフォームに非発送物や非印刷物に関する領収書が添付されるときにのみ、手数料支払いが行われることにより可能である。
【００１９】
この領収書が例えばシステムにより自動的に作成され、例えば該当する郵便料金支払証の走査によって或いは郵便料金支払証の印刷しないことに関するシステムデータの記録によって作成される。
【００２０】
このデータの電子的記憶は、自動化された検査が可能とされるから、特に好ましい。
【００２１】
特に、伝達は電子的に、例えば通信システムにおける報告によって、ｅ−メイル或いはウエブサイトへの入力によって行われる。
【００２２】
この発明のその他の利点、特色、目的に適った実施態様は従属請求項と図面に基づく好ましい実施例の次の表現から明らかになる。
【００２３】
【発明の実施の形態】
図１に図示された顧客側システムは、例えば画面２、キ−ボ−ド３、マウス４と接続されたプリンタ５を備えるパ−ソナルコンピュ−タを包含する。
【００２４】
顧客システムは、図示されたハ−ドウエアに依存せず、むしろ種々の物の形態を有し、例えば唯一のメモリ−モデル、例えばチップカ−ドに記憶される。
【００２５】
図２に図示された全システムでは、顧客側システムは外部サ−バ−と接触している。好ましくは外部サ−バ−は販売センタ−（価格伝達センタ−）によって形成されている。
【００２６】
サ−バ−では、任意のコンピュ−タが重要である。サ−バ−との名称は限定する意味を有しておらず、むしろインターフェイスを介して得られたデ−タを交換する追加的可能性を参照するよう指示する。    
【００２７】
インターフェイスの一つは好ましくは顧客システムによって用意される。顧客インターフェイスと呼ばれるこのインターフェイスは、電子的に作成されたけれども、郵便切手の発送のために利用されなかった郵便料金支払証に関するデ−タの入力を許す。  
【００２８】
好ましくは顧客側システムは、郵便料金支払証の偽造防止作成を可能とする安全モデルを含有する。
【００２９】
顧客側システムは、好ましくは総ての構成要素において検査機構と安全機構を含有する全システムの一部である。
【００３０】
全システムの一つの他の構成要素は例えば価格伝達センタ−である。清算額の無効な支払を阻止する価格伝達センタ−の特性は、顧客システムが任意のこのように保証された価格伝達センタ−と接続され得るので、図示されていない。  
【００３１】
安全構成    
ＰＣ−郵便料金前納のために、種々の現存の勘定の利点と結び付き且つ簡単な手段によりかなりの程度の安全性を提供する基本的安全構成が企図されている。
【００３２】
安全構成は好ましくは図２に好ましい配置で図示されている実質的に三つのユニットを包含する：
・顧客と顧客側システムの同一性が知られている価格伝達センタ−。
・顧客によらない操作可能なハ−ドウエア／ソフトウエアとして顧客システムにおける安全を保証する（例えばオフライン解決策におけるドングル（Ｄongle)或いはチップカ−ド又はオンライン解決策における等価のサ−バ−）安全モデル。
・郵便料金支払証の有効性が検査され、例えば価格額及び郵便料金支払証に関する操作が確認される郵便センタ−。              
【００３３】
価格伝達センタ−、顧客システムや郵便センタ−において行われる個々の処理工程は、次に原理スケッチの形態に図示されている。これに反して正確な技術的通信処理はこの原理的表現に反する（例えばここで図示された伝達を得る複数の通信工程）。特に、この表現では、親密で統一的通信が同一確認され且つ信頼された通信パ−トナ−間に仮定される。        
【００３４】
顧客側システム  
１．安全モデル内部に、顧客に知識をもたらさない乱数が作成されて一時的に記憶される。
２．安全モデル内部に、顧客システム、例えば安全モデルの明白な同一確認番号（安全モデル−ＩＤ）と一緒の乱数は、価格伝達センタ−のみが符号解読を実施する状態にあるように組合せられて符号化される。  
【００３５】
特に好ましい実施態様では、前もって価格伝達センタ−から配付された一回のキ−と通信（清算額の約分の申請）の利用データと一緒の乱数は、価格伝達センタ−の公開キ−により符号化され、安全モデルの個人的キ−によりデジタル番号化される。これにより清算額の各支払における照会はこの構成を有し、清算額の誤使用支払に対して発生され得る（リプレイアタック）。
【００３６】
３．顧客側システムからのクリプトグラフィ処理された情報は清算額の支払い範囲内で価格伝達センタ−に伝達される。顧客も第三者もこの情報を符号化できない。
【００３７】
実際には、通信パ−トナ−（価格伝達センタ−、例えば安全モデル）の公開キ−による非対称符号化が使用される。
【００３８】
キ−の前述の交換の可能性では、対称符号化が同様に考慮される。
【００３９】
価格伝達センタ−  
４．価格伝達センタ−では、なかんずく安全モデル（安全モデル−ＩＤ）の同一確認番号に付属され得る乱数が解読される。
５．郵便料金前納−デ−タバンクへの申請により安全モデル−ＩＤがドイツ郵便の顧客に署名される。
【００４０】
６．価格伝達センタ−では、支払手続確認番号が形成され、安全モデル−ＩＤの部分、清算額の額などが処理される。符号化された乱数は価格伝達センタ−のみが符号解読を実施する状態にあるように、支払手続確認番号と一緒に符号化される（支払手続確認番号は追加的に顧客システムにより解読可能な形態に符号化される）。実際には、符号化は、もっぱら価格伝達センタ−及び郵便センタ−に存在するＴＤＥＳによる対称キ−により行われる。この箇所における対称符号化の使用は生産による敏速な解読方法に基づく要件により設立されている。
【００４１】
７．符号化された乱数と符号化された支払手続確認番号とは、顧客側システムに伝達される。顧客も第三者もこの情報を符号化できない。価格伝達センタ−や郵便センタ−における郵便固有の特に対称キ−の単独の管理によって、キ−は何時も交換でき、キ−長さは必要に応じて変更され得る。これにより簡単な方法で高い操作安全性が保証される。実際には支払手続確認番号が顧客に追加的に符号化されない形態で使用される。
【００４２】
顧客側システム  
８．顧客は郵便料金支払証の作成の範囲内で郵送仕様情報或いは郵送デ−タ（例えば郵便料金，郵送種類など）を把握し、それらデ−タは安全モデルに伝達される。
【００４３】
９．安全モデル内部では、ハシュ値（Hash-Wert)はなかんずく次の情報から形成される。
・郵送デ−タ（例えば郵便料金，郵便種類，日付，ＰＬＺ（郵便コード）など）
・一時的に記憶された乱数（清算額の支払の範囲内で惹起されていた）と
・同様に支払経過同一確認番号から抽出。
【００４４】
１０．郵便料金支払証には、なかんずく、次のデ−タが記入される；
・郵送デ−タ（例えば郵便料金，郵便種類，日付，ＰＬＺ（郵便コード）など）からの抜粋(Klartext)，
・価格伝達センタ−からの符号化された乱数と符号化された支払手続確認番号，と
・郵便デ−タ，乱数と支払手続確認番号からの安全モデル内部に形成されたハシュ値から抽出。
【００４５】
郵便センタ−  
１１．郵便センタ−では、まず最初に郵送デ−タが検査される。郵便料金支払証に引用された郵送デ−タが郵送物と一致していないならば、誤郵便料金前納、想像マ−ク或いは汚れたマ−クが存在しない。郵送物は支払保証システムへ送付されなければならない。
【００４６】
１２．郵便センタ−では、清算額の範囲内で顧客システムに伝達された乱数と支払手続確認番号が符号化される。この為に郵便センタ−では、唯一の（対称）キ−のみが必要である。けれども、個々のキ−の使用の際にその代わりに多数のキ−を挿入すべきだろう。
【００４７】
１３．郵便センタ−では、安全モデルにおけるのと同じ方法に基づきハッシュ値は、次の情報から形成される：
・郵便デ−タ
・符号化された乱数と
・符号化された支払手続確認番号から抽出。
【００４８】
１４．郵便センタ−では、自動形成されたハシュ値と伝達されたハシュ値が比較される。両者が一致するならば、伝達されたハシュ値は、清算額の支払の範囲内において価格伝達センタ−に伝達された同じ乱数により形成された。それ故に、真の有効な清算額並びに安全モデル（有効性検査）に公表された郵便デ−タが重要である。費用により解読、ハシュ値の形成、二つのハシュ値の比較が理論的に信号検査に一致する。けれども、対称解読に基づき、信号検査に比べて時間的利点が生じる。  
【００４９】                                                                      １５．背景システムにおける再検査によって、あとから販売した清算額と郵便料金前納額との間の相違が確認され得る（郵送複写物に関する検査、背景システムにおける清算形成）。
【００５０】
示された根本的安全（セキュリテイ）構成は、清算額の別に防護された管理（財布機能）、顧客側システムと価格伝達センタ−の間の通信の安全保証と、新しい顧客システムの確実な開始の初期設定を包含しない。
【００５１】
安全（セキュリテイ）構成に関する攻撃
記載された安全構成は次により攻撃を受けない：
・第三者は顧客側システムと価格伝達センタ−の間の録画された（複写された）好効果の通信を不正目的に利用できない（再生開始）。
・第三者或いは顧客は操作された顧客側システムを使用することによって価格伝達センタ−に対して合法的顧客側システムをまね出来ない。或る第三者或いは或る顧客が安全モデルの内部で作成されなかったけれども、しかし知っている乱数とボックス−ＩＤの伝達を複写するならば、清算額の支払は利用者名や暗号による正当な顧客の別に実施された同一確認のために或いは決して顧客に知られない安全モデルの個人的キ−の知識のために失敗する。（それ故に、これは、なぜ安全モデルにおけるキ−形成用の初期設定管理と公開したキ−の認可とが顧客側システム提供者により適切に実施されなければならないかである。）
・第三者或いは顧客はまねた価格伝達センタ−を使用する顧客側システムに妥当な清算額を                                                                              払うことができない。或る第三者或いは或る顧客が価格伝達センタ−の機能を複写するならば、この複写された価格伝達センタ−は郵便センタ−で適切に解読できなかった符号化された支払手続確認番号を作成することがうまくできない。そのほかに、価格伝達センタ−の公開したキ−の証明書は偽造されることができない。
・顧客は郵便料金支払証を作成するために価格伝達センタ−の裏をかくことができなく、その支払手続確認番号は郵便センタ−にて有効なものとして解読できなかったという形式に符号化されている。
【００５２】
特に探索の際に、デ−タ安全性を向上するために、乱数からハシュ値の形成までの限定されなかった数を考慮すべきである。
・それ故、乱数の長さは出来るだけ大きく、特に少なくとも１２バイト（９６ビット）になる。
配置された安全構成は、顧客仕様キ−を挿入する可能性によって、解読のために決定された箇所、特に郵便センタ−にキ−を既に保持することを必要なしに公知の方法を伝達する。この好ましい構成は、情報基礎証印プログラム（ＩＢＩＰ）に基づく公知システムに対する実質的相違である。
【００５３】
安全構成の利点
次の特徴は米国の米国郵便サ−ビスの公知のＩＢＩＰ−モデルに比べて前記安全構成を目立つ：
・真の安全性はドイツ郵便のシステム（価格伝達センタ−，郵便センタ−，支払保証システム）において保証され、それでドイツ郵便の影響範囲で完全に読み取られる。
・郵便料金支払証では、署名ではなく、むしろ技術的に同じ値で同様に確実な（対称的）符号化されたデ−タやハシュ値が適用される。このために最も簡単な場合に、ドイツ郵便の影響範囲に単独で位置してそれで容易に交換できる対称的キ−のみが使用される。
・郵便センタ−では、あらゆる郵便料金支払証の検査（単なる無作為抽出検査でない）が可能である。
・安全性概念は、これに適合された背景システムと一致している簡単な閉鎖された検査回路に基づいている。            
・システムは、みずからその他は決して確認可能な複写を認識できない。
・無効な想像マ−クは高い正確さをもつこの方法により認識できる。
・同意性検査の外に、あらゆる郵便料金支払証の場合に真の時間における支払手続確認番号の再検査が行われ得る。
【００５４】
郵送の種類
ＰＣ−郵便料金前納によって、例えば「国内郵便」（Brief national（追加支払いを含めて）と「国内直接マーケテイング」(Direct Marketing national) のような郵送サ−ビス業者のあらゆる製品は郵送サ−ビス業者による前述の確定により郵便料金前納され得る。
【００５５】
小包郵便物と速達郵便物のような他の発送形態用挿入物が同様に可能である。最大に価格伝達センタ−を介して支払われ得る手数料額は適した額に確定される。その額は顧客の注文や郵便サ−ビス業者の安全要求に応じて選択され得る。個人顧客範囲内の挿入のために最大数百ドイツマルクの手数料額は目的にかなっている間に、大きな顧客における挿入のために実質的により高い手数料額が企図される。およそ５００ドイツマルクの範囲の額はレベルの高い個人家計及びフリ−タ−や小企業に適している。取引所に保管された値は特に二倍値額をシステム技術的に越えない。
【００５６】
誤って郵便料金前納された郵便物
誤って郵便料金前納され且つ輸送するのには適しておらず、有効な郵便料金支払証を備えるすでに印刷された手紙、封筒などは顧客の貸方に記入される。
【００５７】
適した処置によって、例えば郵便センタ−における詳細な郵送物の消印によって、郵送物が既に輸送されたか否かを確定することが可能である。これにより、顧客は既に郵送物を受領者から戻され得て、これを郵便サ−ビス業者、例えばドイツ郵便株式会社において貸方に提供されることが阻止される。
【００５８】
郵便サ−ビス業者、例えばドイツ郵便の中央係における払戻し送付は、清算額とデ−タとの比較によってかなりの程度の支払保証を可能とし、これは払戻しの最も頻繁な理由に関する知識である。これにより場合によっては戻し額の減少の目的を伴う記入必要条件の変更による追徴料の可能性が生じる。
【００５９】
郵便料金支払証の有効性
顧客により買われた清算値は支払保証の理由から３か月のみ有効である。適切な指示は顧客との合意で採用すべきである。郵便料金前納値が３か月内に調達され得ないならば、顧客システムにより価格伝達センタ−の連絡は郵便料金支払証の新たな作成に採用される。この連絡の際に、清算額の正常の支払いのように古い清算額の残額が新たに支払われた清算額に追加され、新たな支払手続確認番号の下で顧客に利用される。
【００６０】
特に経営的処理
原則的には郵便料金支払証は、含有される情報が複写され得る任意の形態を有し得る。けれども郵便料金支払証が少なくとも範囲にバ−コ−ドの形態を有するように、郵便料金支払証を形成することが目的に適っている。２Ｄ−バ−コ−ドとそれから生じる支払保証との示された解決策では、次の特色が処理中に考慮されなければならない：
【００６１】
ＰＣ−郵便料金前納郵送物は、あらゆる引渡し可能性を介して、郵便箱を介しても、引渡され得る。
【００６２】
郵便料金前納システムのインターフェスに関連した構成要素の製造業者、特に顧客システムの製造業者及び／又は経営者の承認必要条件を指定することによって、示された安全性処置の厳守がさらに高められる。
【００６３】
管理基準、規格と特典
国際郵便料金支払証印刷機承認条件（ＩＰＭＡＲ）
特に書類の現実の草案の規定は、国際郵便料金支払証印刷機認条件（ＩＰＭＡＲ），ＵＰＵ  Ｓ−３０，この書類に指示されるあらゆる基準と規格と同様に適用できる。あらゆる前記" 必要条件" の出来る限りの厳守が顧客システムのために推薦されている。
【００６４】
デジタル郵便料金マ−ク：応用，安全とデザイン
原則的には、デジタル郵便料金マ−ク：応用，安全とデザイン（ＵＰＵ：技術規格マニュアル）と表題された書類の現実の草案の規定は、この書類に指示されるあらゆる基準や規格に適用できる。この書類の”標準”内容の厳守並びに”情報”内容の十分な注意が顧客システムのために推薦されている。
【００６５】
上位基準と規格によってそれぞれの発送サ−ビス業企業の規則と規定が同様に適用される。
【００６６】
発送サ−ビス業者のあらゆる基準と規格並びにあらゆる法律的規定を満たすそのようなシステムのみを承認することによって、システムの安全性と信頼性はその利用者の親しみ易さと同様に保証される。
【００６７】
他の法律，法令，指針，規則，基準と規格  
原則的には、技術的顧客システムの開発と作用のために現実の作成において注意すべきであるあらゆる法律，法令，指針，規則，基準と規格のそれぞれの有効な草案は適用できる。
【００６８】
システム技術的相互操作性
システム技術的相互操作性は顧客システムのインターフェスの機能性に関連し、例えばインターフェス記述に明細にされた特典の厳守に関連する。
【００６９】
清算インターフェス
通信路，プロトコ−ル
清算インターフェスによる通信は特にプロトコ−ルＴＣＰ／ＩＰとＨＴＴＰに基づく公開のインタ−ネットにより行われる。デ−タ交換はＳＳＬを介してＨＴＴＰ当たり任意に符号化され得る。ここには必要な伝達の目標処理が示されている。
【００７０】
デ−タ交換は特に可能である限り、ＨＴＭＬ−とＸＭＬ−符号化されたデ−タにより行われる。ＨＴＭＬ−サイトの本文や写真内容が顧客システムにて示すべきである。
【００７１】
通信サイトを確認されたＨＴＭＬ−版に拠り、フレーム，埋め込まれた目的物( Applets ，ActiveX など) と場合によっては励まされたＧＩＦｓの使用を断念することが推薦に値するように現れる。
【００７２】
清算額を支払う申請（安全モデルから価格伝達センタ−までの第一伝達）
安全モデルから価格伝達センタ−まで第一伝達の範囲内では、安全モデルの証明書並びに作動表示器Ａは符号化されず且つ署名されずに伝達される。
【００７３】
申請に対する返答（価格伝達センタ−から安全モデルまでの第一返答）
価格伝達センタ−の返答は価格伝達センタ−の固有の証明書，符号化された着座キ−と符号化された着座キ−のデジタル署名を包含する。
【００７４】
安全モデルから価格伝達センタ−までの第二伝達
この伝達の範囲内では、安全モデルは新たな符号化された着座キ−，符号化された乱数と利用デ−タを備える符号化されたデ−タ文（前もって支払われた清算額の金額，現実の清算額の残値，あらゆる清算額の増加する登記録，その登記録は最終支払手続確認番号−すべてを非対称に公開のキ−により符号化する）を送付する。同時に安全モデルはこの符号化されたデ−タのデジタル署名を送付する。同じ時間に、顧客システムは他の符号化されず且つ署名されなかった利用プロトコ−ル或いは利用プロフィルを価格伝達センタ−に送付できる。
【００７５】
利用デ−タは利用プロトコ−ルに登記されること及び、利用プロトコ−ル及び／又はそのプロトコ−ルに記入した登記はデジタル署名されることが、目的に適っている。
【００７６】
価格伝達センタ−から安全モデルまでの第二返答  
価格伝達センタ−は対称的に符号化された乱数と対称的に符号化された支払手続確認番号を安全モデルに伝達する。その外に価格伝達センタ−は安全モデルの公開のキ−により作成された支払手続確認番号，安全モデルの論理情報並びに新たな着座キ−を安全モデルに伝達する。その上に、伝達する全デ−タはデジタル署名される。
【００７７】
安全モデルから価格伝達センタ−までの第三伝達
第三伝達の範囲内では、新たな着座キ−の安全モデルにより新たな支払手続確認番号は効果的通信を証明する利用デ−タと一緒に、符号化されてデジタル署名された形態で価格伝達センタ−に伝達される。
【００７８】
価格伝達センタ−から安全モデルまでの第三返答  
第三返答では、価格伝達センタ−は暗号方法の使用なしに伝達の成果に受領書を書く。
【００７９】
非設置
顧客により顧客システムの非設置の選択が出来なければならない。
清算インターフェスの詳細な技術的記載は郵便固有の価格伝達センタ−の概念により表現される。
【００８０】
利用プロトコ−ルと利用プロフィル
顧客システムでは郵便料金支払証の各作成の範囲内でプロトコ−ル登記を作成すべきであり、そのプロトコ−ル登記は−安全モデルのデジタル署名を備えるーそれぞれの郵便料金支払証のあらゆる報告を含有するにちがいない。さらに、プロトコ−ルにて安全モデルの各誤状態は、この登記の手動解決策が再検査にて記入されるように記録されなければならない。
【００８１】
利用プロトコ−ルは価格伝達センタ−との最終通信以来、利用デ−タの準備された要約を包含する。
【００８２】
顧客システムが顧客にある成分と中央（例えばインタ−ネットにある）成分とに分割されるならば、利用プロフィルは中央成分に案内されなければならない。
【００８３】
郵便料金支払証インターフェス
構成要素と実行
顧客システムはＰＣ−郵便料金支払証を作成する状態になければならず、それは正確にドイツ郵便の報告に、例えば慣用のＣＥＮ−とＵＰＵ−規格の範囲に一致する。
【００８４】
ＰＣ−郵便料金支払証は特に次の三つの要素から生じる：
・郵送仕様情報が機械読取り可能な形態に示されている一つの２次元穿孔コ−ド、バ−コ−ド或いはマトリックスコ−ド（目的：生産における自動化とドイツ郵便の支払保証システム）。
・穿孔コ−ド情報の重要部分を読取り可能な形態に引き渡す原文（目的：顧客並びに生産における制御の選択とドイツ郵便の支払保証システム）。
・例えばドイツ郵便システムの代表的コーチホルンのような発送サ−ビス業者、例えばドイツ郵便と確認するマ−ク。  
【００８５】
デ−タ内容の仕様
目的に適ってＰＣ−郵便料金支払証の穿孔コ−ドと原文は次の情報を含有する：
【００８６】
表：ＰＣ−郵便料金支払証の内容
ここで郵便料金支払証の内容のみが記載される。住所報告の内容用の発送サ−ビス業者の規定は変更されずに有効性を保持する。
用紙の物理的外観の仕様（レイアウト）
郵便料金支払証は好ましくは郵便物の宛て名の上部に左に整合されるように宛て名区分に印刷されている。    
【００８７】
宛て名区分は発送サ−ビス業者の基準の各有効な草案において明細に記入される。特に次の郵便料金前納が可能とされる  ：
・封筒上の印刷
・貼り付けラベル上の印刷
・手紙上の印刷が窓を通して完全に見ることができるような窓封筒の使用。
【００８８】
特に郵便料金支払証の個々の要素に適用する：
・まず最初にデ−タマトリックスタイプの穿孔コ−ドが使用されるならば、その個々の画像点が少なくとも０，５ミリメ−タの縁長さを有すべきであった。
読取り技術的必要条件を考慮して、２Ｄ−バ−コ−ドが０，５ｍｍの最小ピクセル値を備えるデ−タマトリックスの形態で特に適用されるべきであった。場合によっては目的に適った選択は、ピクセル値を０，３ｍｍに減少させることにある。
【００８９】
・ピクセル当たり０，５ｍｍの表示値では、すべてのデ−タが記載されるように入力する時におよそ１８から２０ｍｍまでの全バ−コ−ドの縁長さが生じる。ＡＬＭにおいて０，３ｍｍのピクセル値を備えるバ−コ−ドを読むことを成功する場合に、縁長さがおよそ１３ｍｍに減少される。
【００９０】
・同じ内容における他のバ−コ−ド（例えばAztec ）の使用に関する仕様書の著しい拡大が可能である。
【００９１】
郵便料金支払証のレイアウトと個々の要素の位置決めとの好ましい実施態様は次に図５に例として図示されている。
【００９２】
臨界的値は、４５ｍｍ×９０ｍｍの大きさを備える窓封筒の図示された窓の高さである。ここではおよそ１３ｍｍの縁長さを備えるデ−タマトリックス−コ−ドが図示され、提案されたデ−タ区分の使用では０，３ｍｍのピクセル分解においてのみ可能である。２４ｍｍの縁長さを備えるコ−ドは使用する高さに関して宛て名に対する報告用の十分な空間を与えない。
【００９３】
印刷品質と読取可能性
承認方法の範囲における顧客システムの製造業者並びにより後の経営の顧客は郵便料金支払証の申し分のない印刷に責任がある。このために、顧客は利用者ハンドブックにおける適した指示や補助システムによって指示すべきである。これは、特にラベルのきれいな付着と窓封筒の可視可能な領域の外部の（部分の）汚れの阻止に適する。  
【００９４】
郵便料金支払証の機械的読取り可能性は、使用された印刷分解とコントラストに依存して生じる。黒に代わって他の色が適用されるならば、僅かな読取り割合により算出すべきである。必要とされた読取り割合が高印刷コントラストにおける３００ｄｐｉ（インチ当たりドット）のプリンタに使用された分解において保証され得る；それはセンチメ−タ当たりのおよそ１２０画像点に一致する。
【００９５】
テスト印刷
顧客システムは、外観や大きさで有効な郵便料金支払証に一致するけれども、発送を決定してないが、むしろ管理印刷やプリンタ微調整に用いられる郵便料金支払証を作成する状態でなければならない。
【００９６】
特に顧客システムは、テスト印刷が実際の郵便料金支払証の発送企業に認識可能な形式において相違するように構成されている。このために、例えば郵便料金支払証の中心に宛て名”ＭＵＳＴＥＲ−発送されない”が取り付けられている。バ−コ−ドの少なくとも三分の二は宛て名によって或いは他の方法で見分けがつかなく作られる。
【００９７】
正当な（支払われた）郵便料金支払証の傍に、特に特徴としたテスト印刷の外に、無印刷が製作されないだろう。
【００９８】
顧客システムにおける注文
基礎システム
概観と機能性
基礎システムはＰＣ−郵便料金前納の他の成分間に、即ち価格伝達センタ−、安全モデル、プリンタと顧客の間に結合部材として用いられる。これは場合によってはネットワ−クによって互いに接続され得る一つ或いは複数のコンピュ−タシステム、例えばＰＣｓから成る。
【００９９】
この発明は、郵便料金支払証の作成の異なる工程では手数料額の算出のそれ以上の経過を中断することを可能とする。
【図面の簡単な説明】
【０１００】
【図１】
郵便料金支払証を作成する顧客システムを示す。
【図２】
顧客システムと外部サ−バ−とから成る全システムを示す。
【図３】
発送されていない郵便物に関する情報を含有する画面マスクを示す。
【符号の説明】
【０１０１】
Ａ．．．．．安全構成
Ｂ．．．．．支払センタ−        
４．．．．．乱数と確認の決定  
６．．．．．乱数と特典ＩＤの符号化      
７．．．．．符号化乱数と特典ＩＤの伝達  
Ｃ．．．．．顧客側システム          
Ｄ．．．．．顧客側システムにおける安全箱        
９．．．．．記憶された乱数と郵送デ−タからのハシュ値
２．．．．．乱数とＩＤ番号の符号化    
１．．．．．乱数の作成と記憶          
５．．．．．顧客側システムの確認    
８．．．．．顧客による郵送デ−タの入力
１０．．．．郵便料金支払証 
原文における郵送デ−タ
符号化された乱数と特典ＩＤ並びにハシュ値
Ｆ．．．．．ＰＣ−郵便料金前納    
１５．．．．再検査；特典額に対する郵便料金前納  
Ｅ．．．．．郵便センタ−          
１１．．．．郵送デ−タ検査、即ち郵送適合    
１２．．．．乱数と特典−ＩＤの解読、即ち有効性特典
１３．．．．符号化された乱数と郵送デ−タからのハシュ値
１４．．．．両ハシュ値の比較、即ち真の特典と輸送デ−タが安全箱から出る。