(57)【特許請求の範囲】
【請求項１】
画像を検知するように適合されたエリアイメージセンサと、
該検知された画像を保存するように適合されたメモリー記憶装置と、
重力に関してカメラの向きを検知するように適合された向きセンサと、
変換された画像を形成するために前記検知された画像に向き依存性の変換を適用することにより、前記検知されたカメラの向きを利用して前記検知された画像を加工するように適合されたプロセッサと、
前記変換された画像をプリントメディアに印刷するための内蔵式プリンターと、
を備え、
前記向き依存性の変換は、
（ｉ）  前記検知されたカメラの向きを使用して、検知された画像中に少なくとも１つの顔を検出し、前記変換された画像を形成するために、該検出された少なくとも１つの顔に関連して前記検知された画像を変更すること、
（ｉｉ）  前記検知されたカメラの向きと調和する向きで、前記変換された画像を形成するために前記検知された画像中に文字情報を出すこと
のグループから選択される、
カメラデバイス。
【請求項２】
前記向き依存性の変換は、前記変換された画像を形成するために、前記検知された画像の中に特徴を変形させることを含む、
請求項１に記載のカメラデバイス。
【請求項３】
画像を検知するように適合されたエリアイメージセンサと、
該検知された画像を保存するように適合されたメモリー記憶装置と、
重力に関してカメラの向きを検知するように適合された向きセンサと、
変換された画像を形成するために前記検知された画像を加工するように適合されたプロセッサと、
前記変換された画像を印刷するように適合された内蔵式プリンターと、
を備え、
（ａ）前記向きセンサーによって、重力に関してカメラの向きを検知するステップ
（ｂ）前記プロセッサによって、前記変換された画像を形成するため、前記検知された画像へ向き依存性の変換を適用することにより前記検知されたカメラの向き利用して前記検知された画像を加工するステップ
（ｃ）該変換された画像を前記内蔵式のプリンターによって印刷するステップ
を含み、前記向き依存性の変換は、
（ｉ）  前記検知されたカメラの向きを使用して、検知された画像中に少なくとも１つの顔を検出し、前記変換された画像を形成するために、該検出された少なくとも１つの顔に関連して前記検知された画像を変更すること、
（ｉｉ）  前記検知されたカメラの向きと調和する向きで、前記変換された画像を形成するために前記検知された画像中に文字情報を出すこと
のグループから選択される、
デジタルカメラデバイスによってキャプチャされた画像を加工する方法。
【請求項４】
さらに、前記向き依存性の変換は、
（ｉｉｉ）前記変換された画像を形成するために前記検知された画像中に特徴を歪曲させること、
（ｉｖ）前記変換された画像を形成するために、画像中に登場する動物や人間の顔の特徴に関連する情報を配置すること
のいずれか、又は両方を含む、請求項３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理方法及び装置に関し、特に、画像処理機能を有するデジタルインスタントカメラを開示する。
【０００２】
本発明は、さらに、デジタルカメラ技術の分野に関し、特に、一体型カラープリンタ付きのデジタルカメラを開示する。
【背景技術】
【０００３】
従来のカメラ技術は、長年に亘り、感光性フィルムに映し出される画像のネガに依存する光学処理システムの設備に依存してきている。この感光性フィルムは、“定着（ｆｉｘ）”して、原画像の再生を行うポジプリントの作成を許容するために後で化学的処理される。そのような画像処理技術は、標準的になってきていたけれども、画像のフルカラー処理においては不経済で困難な技術が必要とされるため、過度に複雑になり得る。近年、デジタルカメラが利用可能になってきている。これらのカメラは、標準的には、際立った画像を検知するための電荷結合素子（ＣＣＤ）の利用に依存している。該カメラは標準的には、続けて行う画像処理（manipulation）や印刷のためにコンピュータ装置に画像を転送するためのコネクターに加え、検知したシーンのストレージのためのストレージ・メディアを有する。
【０００４】
そのような装置は、全ての画像がカメラによって保存されており、しばらく後でないと印刷できないという点で不便である。また、該カメラは、多数の画像の保存のために十分なストレージ能力を有していなければならず、加えて、カメラのユーザは、画像のダウンロードやコンピュータ・プリンターによる印刷等のためにコンピュータシステムにアクセスしなければならない。
【０００５】
さらに、インスタント画像の生成を可能にするポラロイド（登録商標）タイプのインスタントカメラは、しばらくの間、使用されてきた。しかしながら、このタイプのカメラは、限定されたサイズの画像のみの作成に限られていて、また、化学物質の使用には多くの問題があり、特に、これらのタイプのカメラで作られた写真は劣化する。
【０００６】
このような装置や他の画像キャプチャー装置を使用する場合、写真撮影の際、音声ひや他の環境の情報を適切に取り込めることが望ましい。
【０００７】
さらに、左眼に与えられる第１画像と右眼に与えられる第２画像とで三次元面の錯覚を起こすという立体視の生成が、よく知られている。しかしながら、従前のシステム複雑な準備を必要とし、現物に極めて近い画像（ハイファイ画像）は通常不可能であった。さらに、画像の一般的な選択は、特別に準備された画像のみに限定されている。
【０００８】
現物に極めて近い立体画像（ハイファイ立体画像）を要求に応じて生成できること、特に、立体画像を自由に撮影することのできるポータブル・カメラ装置によって画像を作成することが一般的に必要である。
【０００９】
さらに、カメラ装置によってキャプチャーされた画像を片面に有すると共に、もう片面に郵便料金払い済み印と住所を有する、自動的にカスタマイズされた葉書を、そのようなカメラ写真画像作成システムが作成できれば、非常に便利だろう。
【００１０】
近年、画像の長い“パノラマ”ビューを作成する写真再生技術については、ますます一般的になってきている。これらの画像は写真用紙などの上に作成される。また、さらなる“パノラマ”のタイプのビューを作成するため、画像の構成は、幅に比べて長さが長くされる。残念ながら、画像が形成される写真用紙は、小径のロールの状態で保存されていた場合に問題が発生する。
【００１１】
近年、フィルターを配置して、人気のある芸術的な絵のスタイルに似せた効果を画像に生じさせるようにすることがかなり一般的になってきている。これらのフィルターは、画像を撮影すると共に、芸術的なスタイルの一つについての芸術的演出を最初の画像に与えて第２の画像を得るように設計されている。現代において極めて人気のある芸術家の一人は、ビンセント・ファン・ゴッホである。彼の絵画のフラット・エリアにおけるブラッシュストローク（筆さばき）の方向が、その絵画における主要な物のエッジの方向を積極的にたどるというのが、この芸術家の芸術作品の一つの特徴である。例えば、“糸杉と星の見える道”や“星月夜”や“医師ガッシュ”と題された彼の作品は、この処理の説明に役立つ実例である。入力されてきた任意の画像に“ファン・ゴッホ”効果を自動的に生じさせ、それを携帯用カメラシステムから出力するというコンピュータ・アルゴリズムの提供が望まれるだろう。
【００１２】
残念ながら、ワーピングのシステムは、ハイエンドコンピュータにて使用されることが一般的であり、画像をコンピュータの中にスキャンすることやプリントアウトすることは一般には不便である。携帯用カメラ等を使って画像を取得するような場合は、取得画像を画像処理のためにコンピュータシステムに後で転送し、次に、要求に従ってそれらの画像を処理するという必要があるため、一般的には特に不便である。
【００１３】
さらに、多様な画法を真似るという効果に大きな価値があるとしばしば考えられる。さらに進んで、１つの簡単な形態の中にこれらの効果を組み入れることができれば、それらの効果は、デジタル撮影能力を有する携帯用カメラ装置と合体させるのに適切であり、それによって、カメラ装置で撮影されるシーンについて、所望のフィルター処理された画像を生成することができるだろう。
【００１４】
残念ながら、今日  製造されるカメラにおいて厄介なシステムの要求である、デジタル画像変換技術やフィルター交換技術は、明らかに、未だ利用できない技術を利用することができず、今までのところ、創造も着想もできていないフィルターを利用することもできない。
【００１５】
カメラ技術の極めて一般的な方式の一つは、伝統的なネガフィルムとポジプリント写真である。このケースでは、ネガフィルムにシーンを撮影するためにカメラが使用され、該ネガフィルムは陰画を定着させるために処理される。続いて一連のプリントがネガフィルムから作成される。さらに、一連のプリントはネガからどんなときにでも直ぐに作成されることができる。残念ながら、デジタルカメラ（本願にて提案されるものも含む）では、後においてさらなる画像のコピーが要求されるなら、キャプチャーされ印刷される写真をデジタル形式で永久的に保存することが必要であろう。“写真”のコピーが単に最初のプリントを必要とするということは一般的には不便かも知れない。もちろん、その代わりに、高品質なカラー写真コピー装置を使用してコピーしても差し支えない。残念ながら、そのような装置はコピー能力に限界があり、そのようなコピーの形態が行われるとき、しばしば信号の劣化が生じる。明らかに、カメラプリントのコピーを作成する、より好適な形態が望まれる。
【００１６】
さらに、下塗りの際のメディアの選択に起因して色が制限され、風景についてのほとんど全ての芸術的絵画は限定的な色域（gamut）を使用している。このような制限は、様々な芸術的効果を生じさせるために芸術家によってしばしば使われる。この処理の古典的な見本は、次のような周知の芸術作品を含む：
−  カミーユ・ピサロ  “Ｌ’ｌｅ  Ｌａｃｒｏｉｘ−Ｒｏｕｅｎ、霧の効果”  １８８８年、フィラデルフィア美術館
−  シャルル・アングラン  “セーヌ河、朝”−１８８９年、プティ・パレ・コレクション、ジュネーブ
−  アンリ・ヴァン・ド・ヴェルド  “Ｃｒｅｐｕｓｃｕｌｅ”  −１８９２年、クレラー＝ミュラー国立美術館、オッテルロー
−  ジョルジョ・スーラ  “バ＝ビュタンの砂浜、オンフルール”１８８６年−トゥルーネ美術館
【００１７】
任意の入力画像から、上記リストのそれと似たような効果や特性を持つ出力画像を作成することが望ましい。
【００１８】
何らかの衣服が創造されるとき多くの創造的な判断がなされる。初めに、衣服の形状やスタイルであり、加えて、布の色や種類である。しばしは、ファッションデザイナーは、衣服を完成させる前に、多くの異なる代替案にトライし、最終的なファッションの製品を描こうとする。
【００１９】
このようなプロセスは、衣服の迅速かつ柔軟な変更や、ファッション製品の最終外観の迅速な判断機会のためには一般的に不十分である。
【００２０】
双眼鏡や望遠鏡は良く知られている。特に、双眼鏡を例にすると、該装置は、ユーザの視力の能力を高めるために景色の望遠の拡大を提供する。さらに、夜間用双眼鏡等のような装置も、また、ユーザの視力の能力を高めるために使われる。残念ながら、これらのシステムは、リアルタイムの、アナログの光学部品に依存し、見えた景色の永久記録は困難である。シーンの永久コピーの記録に適していると思われる１つの方法は、シーンを取得するＣＣＤ等のようなセンサー装置を取り付けることと、後に行う印刷のためにストレージデバイスに保存することである。残念ながら、そのような構造は、野外で、携行性に富む状態での双眼鏡の使用が望まれる場合には特に邪魔となる。
【００２１】
圧縮した状態での情報のストレージについては、多くの形態のものが周知である。例えば、コンピュータ装置の分野では、固定された、或いは携行できる磁気ディスク装置の使用は一般的である。携行できるディスクについては、“フロッピーディスク”や“ジップディスク”や、ポータブル磁気ストレージメディアの他の方式が、市場において大量に受け入れられている。携帯可能なストレージの他の形式は、一連の細長いピット（螺旋状のトラックに沿って配置されたものであり、レーザビーム装置によって読み取られるもの）を利用するコンパクトディスク“ＣＤ”である。ＣＤの利用は、ストレージについての極めて低コストの形態を提供する。しかしながら、必要とされる技術はかなり複雑であり、書き換え可能なＣＤタイプの装置の使用は極めて限定される。
【００２２】
ストレージの他の方式としては磁気カードがあり、しばしばクレジットカードや同種のものに使用される。これらのカードは、標準的には、カードのユーザに関連する情報を記録するため、裏面に磁気の帯を有している。近年、集積回路タイプの装置をカードに組み込むというスマートカード技術の形で、磁気カードの利便性が伸びてきている。残念ながら、そのような装置のコストはしばしば高く、使用される技術の複雑さもまた著しい。
【００２３】
従来の銀塩カメラの処理システムは、多数のプリントの作成のため、周知の“ネガ”の使用を生じさせてきた。そのネガは、標準的にはプリントの生産源となり、その実施は、連続使用のためのケアや保護のために成長してきた。
【００２４】
フォールトトレラント方法にて検知される符号化システムでは、効率的な復号化が可能となる符号化がどのようにすれば可能かという、重要な懸案がある。したがって、効率的な符号化システムの提供が望まれる。
【００２５】
本発明の概要
本発明は、一体型カラープリンタ付きデジタルカメラを備えたカメラシステムの代替形態の提供に関する。加えて、該カメラは、イメージ・センシング・システムの見かけの解像度を増加させ、様々な“芸術的なスタイル”やグラフィック強化（graphic enhancement）に画像を変換するためのハードウェア及びソフトウェアを備える。
【００２６】
本発明のさらなる態様に従って、シーンを撮像するための少なくとも１つのエリアイメージセンサーと、前記撮像されたシーンを所定のシーン変換要求に従って処理するためのカメラ処理装置（camera processor means）と、前記処理された画像のシーンをプリントメディアに印刷するためのプリンターと、前記カメラシステム内部の一つの取り外し可能なモジュールに収納されたプリントメディア及び印刷用インクと、を備えたカメラシステムが提供される。該カメラシステムは、前記エリアイメージセンサーによるシーンの撮像、及び前記プリンターによって前記シーンを印刷したものを前記カメラシステムから直接出力するためのハンドヘルドユニットを備える。
【００２７】
前記カメラシステムは、好ましくは、プリントメディアの保管のためのプリントロールと、前記プリンターにより使用される印刷用インクを備えている。該プリントロールは前記カメラシステムから取り外し可能である。さらに、該プリントロールが前記カメラシステムに挿入されたときに認証が実行されるように、該プリントロールは、認証情報を含む認証チップを備え、前記カメラ処理装置は該認証チップを確認（ｉｎｔｅｒｒｏｇａｔｅ）するように適合されている。
【００２８】
さらに、前記プリンターは、ドロップ・オン・デマンドのインクプリンターと、印刷された写真の分離のための裁断装置とを含む。
【００２９】
本発明の第１態様に従って、シーンを撮像するための少なくとも１つのエリアイメージセンサーと、前記撮像されたシーンを所定のシーン変換要求に従って処理するためのカメラ処理装置と、前記処理された画像のシーンをプリントメディアに印刷するためのプリンターと、前記カメラシステム内部の一つの取り外し可能なモジュールに収納されたプリントメディア及び印刷用インクと、を有するカメラシステムが提供される。該カメラシステムは、前記エリアイメージセンサーによるシーンの撮像、及び前記プリンターによって前記シーンを印刷したものを前記カメラシステムから直接出力するためのハンドヘルドユニットを備える。
【００３０】
好ましくは、該カメラシステムは、前記プリンターにより使用されるプリントメディア及び印刷用インクを収納するためのプリントロールを備えている。該プリントロールは前記カメラシステムから取り外しが可能である。さらに、該プリントロールが前記カメラシステムに挿入されたときに認証が実行されるように、該プリントロールは、認証情報を含む認証チップを備え、前記カメラ処理装置は該認証チップを確認（ｉｎｔｅｒｒｏｇａｔｅ）するように適合されている。
【００３１】
さらに、前記プリンターは、ドロップ・オン・デマンドのインクプリンターと、印刷された写真の分離のための裁断装置とを含む。
【００３２】
本発明のさらなる態様に従って、装置を操作するためのユーザ・インターフェースが提供される。該ユーザ・インターフェースは、装置に挿入されるカードを有しており、該カードの表面には、前記装置の出力に関して該カードが有する効果について目に見える説明が含まれている。
【００３３】
本発明のさらなる態様に従って、
シーンを撮像するための少なくとも１つのエリアイメージセンサーと；
前記撮像されたシーンを所定のシーン変換要求に従って処理するためのカメラ処理装置と；
前記処理された画像のシーンをプリントメディアに印刷するためのプリンターと；
前記プリンターのための前記プリントメディアと印刷用インクとを収納するための取り外し可能なモジュールと；
を備えたカメラシステムが提供される。該カメラシステムは、前記エリアイメージセンサーによるシーンの撮像、及び前記プリンターによって前記シーンを印刷したものを前記カメラシステムから直接出力するためのハンドヘルドユニットを備える。
【００３４】
本発明のさらなる態様に従って、
画像を検知するセンサー装置（sensor means）と；
検知された画像を所定の処理要求に従って処理するための処理装置と；
もしあるならば、音声信号を検知画像に関連付けて一致させるための音声録音装置と；
前記カメラシステムで供給されるプリントメディアの第１エリアに処理された検知画像を印刷し、前記プリントメディアの第２エリアに前記音声信号の符号化されたバージョンを印刷するための印刷装置と；
を備えたカメラシステムが提供される。好ましくは、該検知画像は前記プリントメディアの第１面に印刷され、前記音声信号の符号化されたバージョンは該プリントメディアの第２面に印刷される。
【００３５】
本発明に従って、
画像を検知するエリアイメージセンサー装置と；
該検知した画像を保管するための画像ストレージ装置と；
画像検知時におけるカメラの向きを検出する定位装置と；
検知したカメラの向きを使用して前記検知画像を処理するための処理装置と；
を備えたカメラシステムが提供される。
【００３６】
本発明のさらなる態様に従って、
焦点調整技術を使用して画像をキャプチャーし；
画像における構成の位置の指示器として焦点設定を利用し；
該焦点設定に特有の効果を生成するために該焦点設定を利用して画像を処理し；
その画像を印刷すること；
からなるデジタル画像処理方法が提供される。
【００３７】
好ましくは、前記画像はズーム技術を使用してキャプチャーされ、そのズーム設定は、前記画像の部分を処理するように発見的な方法で使用される。
【００３８】
本発明のさらなる態様に従って、アイポジション検知装置付きデジタルカメラにて撮影された画像を処理する方法が提供される。該方法は、空間的に変化するｓｅｎｓｅ（アイポジション情報に依存するもの）で画像を処理するため、検知画像にアイポジション情報を使用するステップを含む。
【００３９】
前記ステップは、興味のあるエリアの位置を前記検知画像の中で特定するためにアイポジション情報を使用することを含む。その処理は、画像への吹き出しの配置や、画像への特定のゆがみの適用を含むことができる。代わりに、その処理は、前記アイポジション情報のエリアに、より細かい画像のためにブラッシュストロークフィルターを適用することも含む。理想的には、前記カメラは、処理の結果を大体直ぐに印刷することができる。
【００４０】
本発明のさらなる態様に従って、自動露出設定を有するデジタルカメラで撮影された画像の処理方法が提供され、該処理方法は、検知画像を処理するために前記情報を使用するステップを含む。
【００４１】
上述の、情報を使用するステップは、画像中の色が前記自動露出設定の計算に変換されてなる補正画像を生成するため、画像中の色のリマッピングを決定するために自動露出設定を使用することを含む。その処理は、露出設定が暗い状態を示すときは、リマッピングされる画像の色が、より深く、より鮮やかになるようにし、露出設定が明るい状態を示すときは、リマッピングされる画像の色が、より明るく、より飽和するようにする。
【００４２】
最近、デジタルカメラはますます一般的になってきている。これらのカメラは、標準的には、電荷結合素子（ＣＣＤ）配列を使用した所望の画像の取得、並びに、撮像されたシーンの電子ストレージメディアへの保存（続けて行う画像処理や印刷のために、コンピュータシステムに後で行われるダウンロードのためのもの）を行う。標準的に、画像を印刷するためにコンピュータシステムを使用するとき、洗練されたソフトウェアが、要求に従って画像を処理するために使用される。
【００４３】
残念ながら、そのようなシステムは、キャプチャーされた画像の重要な後処理を必要とし、通常は、撮影された向きに画像を提示し、キャプチャーされた画像の必要な修正又は要求された修正を実行するため、後処理工程に依存する。さらに、写真が撮影される際の多くの環境情報が失われる。
【００４４】
本発明のさらなる態様に従って、デジタルカメラ及びフラッシュを使用してキャプチャーされた画像の処理方法が提供され、該方法は、以下のステップを含む。
(a)   前記フラッシュの使用に起因した、前記キャプチャーされた画像のゆがみ（ディストーション、distortion）の発見（特定）
(b)   前記ゆがみの影響を局部的に減少させるように前記画像の修正
【００４５】
本発明の第２の態様に従って、キャプチャーされた画像におけるフラッシュのゆがみ（ｄｉｓｔｏｒｔｉｏｎ）の影響を減少させるデジタルカメラであって、
(a)   画像のキャプチャーのために画像をキャプチャーするデジタル画像キャプチャー装置と；
(b)   フラッシュが誘発した色のゆがみの、前記キャプチャー画像内での位置を探すためのゆがみ位置決定装置と；
(c)   該ゆがみ位置決定装置及び前記デジタル画像キャプチャー装置に接続されて、前記ゆがみの影響を減少させるように前記キャプチャー画像を処理するように適合された画像ゆがみ是正装置と；
(d)   表示のために前記画像ゆがみ是正装置に接続されている表示装置と；
を備えたデジタルカメラが提供される。
【００４６】
本発明のさらなる態様に従って立体写真画像を作り出す方法が提供され、該方法は、
(a)   シーンを立体画像的に撮像するためにカメラ装置を使用し；
(b)   レンズシステムが第２面に形成された透明なプリントメディアにおける第１面部分の所定位置に、一体的に形成された画像のような立体撮影画像を印刷して、該印刷された立体撮影画像の観察者の左右の眼が前記シーンを立体画像的に見るようにする；
ことを含む。
【００４７】
本発明のさらなる態様に従って、プリントメディア及びインク供給装置が提供される。該供給装置は、インクと該インク付着用のプリントメディアとをプリント装置に供給するように適合されている。該供給装置は、メディア・フォーマーの上に巻かれた、ロール状のメディアを内部に有している。また、該供給装置は、前記メディア及びインク供給装置の内部に一体的に形成されると共に、インク及びプリントメディアの前記プリント装置への供給のために前記プリント装置に接続されるように適合された少なくとも１つのインク・リザーバを有している。
【００４８】
本発明のさらなる態様に従って、カメラ画像システムにて使用されるプリントロールであって、フォーマットされた多数の葉書情報が、所定の間隔で裏面に印刷されてなるプリントロールが提供される。
【００４９】
本発明の第２の態様に従って、カスタマイズされた葉書の作成方法が提供される。該作成方法は、次のステップを含む。すなわち、フォーマットされた多数の葉書情報区域を所定位置に有する裏面を備えるプリントロールを備えるカメラ装置の使用と、該プリントロールの対応する画像面へのカスタマイズされた画像の撮像と、該カメラ装置によって葉書を作成するための前記プリントロールの使用。
【００５０】
本発明の第３の態様に従って、カメラ画像を有する葉書を郵便制度を通じて送る方法が提供され、該方法は、次のステップを含む。すなわち、前払いの郵便料金が含まれているプリントロールを売るステップと、葉書を作成するために該プリントロールをカメラシステムで使用するステップと、該前払いした葉書を郵便で送るステップ。
【００５１】
本発明は、さらに、一体型プリンター装置付きカメラシステムを対象とする。そのプリントメディアは、カメラシステムから取り外し自在であり、該プリントメディアに関する重要な情報を保存するための装置を含む。
【００５２】
本発明は、さらに、一体型プリンター装置付きカメラシステムを対象とする。そのプリントメディアは、カメラシステムから取り外し自在であり、該プリントメディアへの認証アクセスを提供する。
【００５３】
本発明のさらなる態様に従って、使用に際してカールする度合いが低い、平らなプリントメディアが提供される。該プリントメディアは、前記平面の方向に異方性の剛性を有している。本発明の第２の態様に従って、異方性剛性を有する平らなプリントメディアにプリントされた画像においてカールを減少させる方法が提供される。該方法は、前記プリントメディアの部分に局所的な圧力を与えるものである。
【００５４】
本発明はさらに、一体型プリンター装置を有するカメラシステムを対象とする。該カメラシステムは、プリンターに残っている画像の数のインジケータを有する。該インジケータは、多くの異なるモードで、残っているプリントの数を表示することができる。
【００５５】
本発明のさらなる態様に従って画像の自動処理方法が提供される。該処理方法は、高い空間的な変化を持つ特徴を、画像の中で位置特定し、高い空間的な変化を持つそれらの領域から放射する一連のブラッシュストロークを画像に描くことを含む。好ましくは、そのブラッシュストロークは、重要な特徴付けるものの近傍ではサイズが小さい。加えて、ブラッシュストロークの所定部分の位置はジッタリングの下になる。
【００５６】
本発明のさらなる態様に従って、入力画像を歪ませるようなワーピング方法が提供される。該方法は、
所定の寸法Ａ×Ｂである任意の出力画像のためのワープマップであって、該ワープマップの各要素は、理論上の入力画像における対応領域を、前記要素の座標位置に対応した前記任意の出力画像の画素位置にマッピングするワープマップを入力するステップと；
縮小されたワープマップを形成するためにワープマップをワープ画像の次元に縮小するステップと；
該縮小されたワープマップの各要素のため、該要素の値と隣接する要素の値とから前記入力画像における貢献領域を計算するステップと；
該貢献領域から前記要素に対応するワープ画像の画素のため、出力画像の色を決定するステップと；
を含む。
【００５７】
本発明のさらなる態様に従って、センサー装置によって読み取るため、メディアに保存されたデータの復元力を増加させる方法が提供される。該方法は、
(a)   回復可能な方法で保存されているデータを、高周波成分を有する変調信号にて変調するステップと；
(b)   前記データを変調された形式で前記メディアに保存するステップと；
(c)   該変調され保存されているデータを前記センサー装置によって検知するステップと；
(d)   変調され前記メディアに保存されているデータの位置の分離を探知するため、変調され保存されているデータの変調を中立化するステップと；
(e)   保存データの内の変調されていないものを、保存データの内の変調されているものから回収するステップと；
を含む。
【００５８】
本発明の好適な実施例は、カメラシステムの中に設けられたシステムであって、後で復号化が行えるように、ＣＣＤタイプの装置を介してデータを読み込むためのカード読み取りシステムに関して説明される。さらに、該好適な実施例の説明は、誤差制御システムの分野に大きく依存する。したがって、この仕様が案内される人は、誤差制御システムのエキスパートになるべきである。特に、“デジタル・コミュニケーションやストレージのための誤差制御システム”ステファン．Ｂ．ウィッカー著、プレティス・ホール社出版、１９９５年、特にリード・ソロモン・コードの考察のような標準的なテキストや他の標準的なテキストにしっかりと精通すべきである。
【００５９】
本発明の目的は、スキャンされた画素を含むスキャンされた画像を、対応するビットマップイメージに変換する方法を提供することであって、該方法は、ビットマップイメージにおける各ビットのために、次のステップを有する。すなわち、
ａ．スキャンされた画像における周囲のビットの位置から現在のビットにおけるスキャンされた画像での予期された位置を決定するステップ、
ｂ．前記スキャンされた画像における期待された対応画素の位置での値から前記ビットの適当な値を決定するステップ、
ｃ．前記予期された位置での予期された強度の中心の重心の寸法を決定するステップ、
ｄ．前記スキャンされた画像における現在のビットの周囲に近接した画素のため、重心の寸法を決定するステップ、
ｅ．前記重心の寸法が前記予期された位置に関連して伸びる場合、伸びた重心の寸法を有する画素に該予期された位置を調整するステップ、
とを有する。
【００６０】
本発明のさらなる態様に従って、
画像を検知できるデジタルカメラ装置と；
該画像を処理すべく該デジタルカメラ装置に挿入されて該デジタルカメラ装置に画像処理の指示（画像にテキストを付加する指示）を与えるように適合された画像処理データ入力カードと；
前記画像に付加する新たなテキスト文字を作成するために、前記画像処理指示に関連して前記デジタルカメラ装置により使用される一連の非ローマ・フォント文字を有するテキスト入力装置であって、前記画像に付加する前記文字を入力するために前記デジタルカメラ装置に接続されるテキスト入力装置と；
を備えた、画像を編集する、テキストのための装置が提供される。
【００６１】
望ましくは、前記新しいテキスト文字を作成するために前記画像処理指示に従って前記装置により要求された場合に、フォント文字が前記デジタルカメラ装置に送られる。前記画像処理データ入力カードは、ローマフォント文字のセットと、ヘブライ語、キリル文字、アラビア語、漢字及び中国文字（ｃｈｉｎｅｓｅ  ｃｈａｒａｃｔｅｒ）の少なくとも１つを含む非ローマ文字とを含む。
【００６２】
本発明のさらなる態様に従って、
画像を検知できるデジタルカメラ装置と；
該画像を処理すべく該デジタルカメラ装置に挿入されて該デジタルカメラ装置に画像処理の指示（画像にテキストを付加する指示）を与えるように適合された画像処理データ入力カードと；
前記画像に付加する新たなテキスト文字を作成するために、前記画像処理指示に関連して前記デジタルカメラ装置により使用される一連の非ローマ・フォント文字を有するテキスト入力装置であって、前記画像に付加する前記文字を入力するために前記デジタルカメラ装置に接続されるテキスト入力装置と；
を備えた、画像を編集する、テキストのための装置が提供される。
【００６３】
本発明の目的は、作り出される新しいフィルターの利点、及び、プリントアウトするデジタル画像の処理のための柔軟性のある方法の利点に加えて、アップデートされる技術の利点を利用することである。
【００６４】
本発明のさらなる態様に従って、一連のインクドットからなる入力画像の再生のための画像コピー装置が提供され、該装置は、
(a)   対応した見本画像を作成するため、前記ドットの周波数よりも高いサンプリングレートで前記入力画像を撮像するイメージング・アレイ装置と；
(b)   前記見本画像中の印刷ドットの位置を決定するために前記画像を処理する処理装置と；
(c)   前記印刷ドットの位置に対応する、プリントメディア上の位置にインクドットを印刷するプリント装置と；
を含む。
【００６５】
２．  前記コピー装置が前記入力画像のフルカラーコピーを印刷する、請求項１に記載された画像コピー装置。
【００６６】
本発明のさらなる態様に従って、ボケ修正画像を出力するためのカメラシステムが提供される。該カメラシステムは、
画像を検知するイメージ・センサーと；
外部環境に関連した前記画像の何らかの動きを検知して、その動きを示す速度出力を生成するための速度検出手段と；
それらのイメージ・センサーや速度検出手段に接続されると共に、前記画像のボケ修正を行ってボケ修正画像を出力するように適合されたプロセッサー手段と；
を備えている。
【００６７】
望ましくは、前記カメラシステムは、前記ボケ修正画像を直ぐに出力するために印刷装置に接続されるものであって、携帯用のハンドヘルドユニットである。前記速度検出手段は、微小電気機械（ＭＥＭＳ）装置のような加速度計を含むことができる。
【００６８】
本発明のさらなる態様に従って、フォトセンサー読み取り形成品が提供され、該形成品は、
(a)   発光素子の挿入のための、一連の発光体収納部と；
(b)   前記一連の発光素子から発光された光を、撮像されるべきオブジェクトの表面に焦点を合わせるための発光素子合焦装置と；
(c)   一連のフォトセンサー列を挿入するためのフォトセンサー収納部と；
(d)   撮像されるべきオブジェクトからの反射光を、前記ＣＣＤ列の特徴的な部分に焦点を合わせる合焦装置と；
を備える。
【００６９】
本発明の態様に従って、コンピュータシステムに接続されるプリンター装置が提供される。該プリンター装置は、プリントメディアに画像を印刷するためのインクジェット・プリントヘッドからなるプリントヘッドユニットを備え、さらに、消耗財であるプリントロールユニットを挿入するための空洞を有する。該プリントロールユニットは、該空洞に挿入される消耗財であるプリントメディアとインクとを含み、該インクは前記プリントメディアに画像を印刷するため、前記インクジェット・プリントヘッドにより使用される。
【００７０】
本発明のさらなる態様に従って、
画像を検知するセンサー装置（sensing means）と；
カメラに入力される修正指示に従って前記検知した画像を修正する修正装置と；
該修正された画像を出力するための出力装置と；
を備えたデジタルカメラシステムであって、前記修正装置が、中央のクロスバー・スイッチの周りに配列された一連のＰＥ（Ｐｒｏｃｅｓｓｉｎｇ  ｅｌｅｍｅｎｔ）であるものが提供される。望ましくは、該ＰＥは、書き込み可能なコントロール・ストアを有するマイクロコード・ストアの制御下で動作する算術論理演算ユニット（ＡＬＵ）を有する。前記ＰＥは、該素子にて使用される画素データを保存するための内部入出力ＦＩＦＯを含むことができ、前記修正装置は、該装置へ画像の画素データを書き込んだり読み込んだりするための読み書きＦＩＦＯに接続されている。
【００７１】
それぞれのＰＥは輪になるように配置されることができ、また、それぞれのＰＥは最も近い隣のＰＥに単独で接続される。前記ＡＬＵは、内部クロスバースイッチを介してＡＬＵ内の一連の中央演算装置に接続された一連の入力を受け、テンポラリーデータのストレージのための多くの内部レジスターを有する。該中央演算装置は、乗算器、加算器及びバレル・シフターの内の少なくとも１つを有している。
【００７２】
前記ＰＥはさらに、該ＰＥに画素データを転送するためのコモン・データバスに接続されている。該データバスはデータキャッシュに接続され、該データキャッシュは前記ＰＥと、画像を保管するメモリーストアとの間で中間キャッシュとして機能する。
【００７３】
本発明のさらなる態様に従って、カードに高ピッチレートで保存された検知画像データを、リアルタイムで短時間に復号化する方法が提供され、該方法は、
前記画像データの初期位置を検出するステップと；
該画像データの対応するビットパターンを決定すべく、該画像データを復号化するステップと；
を含む。
【００７４】
本発明のさらなる態様に従って、カードに高ピッチレートで保存されて回転やワーピングやマーキングがされる検知画像データをフォールトトレラント方法によって短時間で復号化する方法が提供され、該方法は、
前記画像データの開始の初期位置を決定するステップと；
前記ピッチレートよりも高いサンプリングレートで前記画像データを検知するステップと；
カラム処理によってカラム中の検知画像データを処理し、次のカラムの各ドットの中心（重心）の期待される位置をキープし、期待される次の重心の位置をアップデートするように、各カラムを処理する場合に該重心の微細な調整を行うステップと；
を有する。
【００７５】
本発明のさらなる態様に従って、ドット配列からなり、画素配列を形成するため、該ドット配列のピッチ周波数よりも高いレートでサンプリングされた検知画像データのドットの値を正確に検出する方法が提供され、該方法は、
前記画素配列の内で、期待された重心位置に対応した、期待された中央画素を決定するステップと；
前記画素の位置を中心とするドットの値を出力するルックアップテーブルのインデックスとして、前記中央画素の検知値、及び、多くの隣接画素の検知値を使用するステップと；
からなる。
【００７６】
本発明のさらなる態様に従って、カードに高ピッチレートで保存され、回転やワーピングやマーキングの効果を前提とする検知画像データのドットの位置を正確に決定する方法が提供され、該方法は、
カラム中の前記画像データをカラム形式によって処理するステップと；
画素の前記処理されたカラムのドットパターンを記録するステップと；
前記処理された画素の記録されたドットパターンから、期待されたドットパターンを最新のカラム位置にするステップと；
前記期待されたドットパターンを、前記最新のカラム位置での検知画像データの実際のドットパターンと比較するステップと；
その比較が所定の誤差内である場合に、新しい実際のドット位置を生成するため、前記期待されたドットパターンに適合させるため、実際のドット位置を前記最新のカラム位置に帰るように前記最新のカラム位置を使用するステップと；
次のカラムのドット位置を決定する際に、最新のカラム位置にて前記実際のドット位置を利用するステップと；
を含む。
【００７７】
本発明のさらなる態様に従って、画像に絵画の効果を擬態するために画像バンプマップを結合させる方法が提供され、該方法は、
絵の具が塗られる表面を生じさせる、画像キャンバスバンプマップを規定し、
該表面に描かれるオブジェクトのペイントバンプマップを規定し、
前記画像キャンバスバンプマップによる、前記ペイントバンプマップの修正の程度を決定する剛性因子を使用し、最終的な結合バンプマップを作成するために前記画像キャンバスバンプマップと前記ペイントバンプマップとを結合すること、
を含む。
【００７８】
本発明のさらなる態様に従って、芸術的な効果を生じさせるため、入力されてきた画像を自動的に処理する方法が提供され、該方法は、
目的とする芸術的効果を作成するため、所定の出力ガモットへの入力ガモットのマッピングを決定し、
所定の出力ガモットを有する出力画像に前記入力画像をマップするマッピングを利用する、
ことを含む。
【００７９】
望ましくは、前記方法は、さらに、ブラッシュストローク・フィルターを使用した、出力画像の後処理のステップを含む。
【００８０】
さらに、望ましくは、前記出力ガモットは、所定数の入力ガモット値を、対応する出力色ガモット値にマッピングすると共に、入力ガモット値から出力色ガモット値へのマッピングの維持を挿入することによって形成される。その挿入プロセスは、出力色ガモット値への入力ガモット値の所定数のマッピングの加重和を含む。
【００８１】
本発明の第２の態様に従って、出力色ガモットに入るように入力色ガモットを圧縮する方法が提供され、該方法は、
現在の入力色の強さにてゼロクロミナンス値を決定するステップと；
前記ゼロクロミナンス値から前記入力色ガモットのエッジまでの距離であるソース距離を決定するステップと；
前記出力色ガモットの好適なエッジを決定するステップと；
前記ゼロクロミナンス値から前記出力色ガモットのエッジまでの距離であるターゲット距離を決定するステップと；
前記ソース距離と前記ターゲット距離との比から導き出される因子により、現在の入力色強さを計るステップと、
を備える。
【００８２】
好ましくは、前記現在の入力色強さは、前記ゼロクロミナンス値ポイントからの前記現在の入力色の距離に基づく因子により計られる。
【００８３】
本発明のさらなる態様に従って、カメラによって検知された画像の出力のための携帯用カメラが提供され、該カメラは、
画像を検知するためのセンサー装置（sensing means）と；
タイル状画像を作成すべく、検知された画像にタイル効果を付与するタイル装置と；
該タイル状画像を表示するための表示装置と；
を備えている。
【００８４】
本発明のさらなる態様に従って、カメラによって検知された画像の出力のための携帯用カメラが提供され、該カメラは、
画像を検知するためのセンサー装置（sensing means）と；
テクスチャが付加された画像を作成すべく、検知された画像にテクスチャ効果を付与するテクスチャマッピング装置と；
該テクスチャが付加された画像を表示するための表示装置と；
を備える。
【００８５】
本発明のさらなる態様に従って、カメラにより検知された画像を出力するための携帯用カメラが提供され、該カメラは、
画像を検知するためのセンサー装置（sensor means）と；
該検知された画像にて光を放つ光源の効果を真似たイルミネーション画像を作成すべく、検知画像に照明効果を付与する照明装置と；
該イルミネーション画像を表示するためのディスプレイ装置と；
を備えている。
【００８６】
本発明のさらなる態様に従って、
検知画像の特徴を有する布製衣料を描くディスプレイ装置への出力のため、前記検知画像の処理のためにカメラそうちに入力される一連の入力トークン信号と；
前記出力画像を形成するために、前記入力トークン信号を読み、画像を検知し、読み込んだ入力トークン信号に従って該画像を処理するように適合されたカメラ装置と；
前記出力画像を表示するように適合されたディスプレイ装置と；
からなる衣類創作システムが提供される。
【００８７】
本発明のさらなる態様に従って、画像センサー装置と画像表示装置とを有し、画像センサー装置によって検知された任意の画像の部分を衣類にマッピングして、前記画像表示装置にて表示する衣類創作システムが提供される。
【００８８】
本発明のさらなる態様に従って、処理された画像を形成する方法が提供され、該方法は、一連のカメラ処理ユニット（camera manipulation unit）を接続することを含み、それぞれのカメラ処理ユニットは、処理された出力画像を形成すべく、入力画像に画像処理を与えるものである。それらのカメラ処理ユニットの最初の１つは周囲から画像を検知し、それらのカメラ処理ユニットの少なくとも最後の１つは、色落ちしない出力画像を形成する。
【００８９】
本発明のさらなる態様に従って、遠い所にある被写体を眺めるための携帯用撮像装置が提供され、該撮像装置は、
遠く離れたところに見える被写体を拡大するための光学レンズシステムと；
該被写体を同時に検知するための検知システムと；
該検知された画像を処理してプリンター装置に送るために前記検知システムに接続される処理装置と；
要求に応じて前記携帯用撮像装置により検知された画像をプリントメディアに印刷するため前記処理装置に接続されたプリンター装置と；
を備えている。
【００９０】
好ましくは、前記システムは、さらに、前記プリンター装置にロール状のプリントメディアとインクとを供給するため、前記プリンター装置に接続される、取り外し可能なモジュールに配置された、取り外し可能なプリントメディア供給装置を有する。
【００９１】
前記プリンター装置は、検知した画像を出力するための、フルカラープリンターを提供する、インクジェットプリント装置を備えることができる。
【００９２】
さらに、好ましい実施例は、遠い所の被写体を前記検知システムに投影するためのビームスプリッタ装置を備えた双眼鏡システムとして実施される。
【００９３】
本発明のさらなる態様に従って、カードに印刷された一連のドットとして、フォールトトレラント方法により符号化されている録音済み音声を再生するシステムが提供される。該システムは、
録音済み音声の目に見える形式のスキャニングのためのオプティカル・スキャナー装置と；
スキャンされた音声符号を復号化して音声信号を生成するように、該オプティカル・スキャナー装置に接続された処理装置と；
要求に応じて該音声信号を再生するように、該処理装置に接続された音声エミッター装置と；
を備える。
【００９４】
前記符号化は、録音済み音声のリード・ソロモン符号化を含むことができ、スキャニングを補助するために高周波変調されたインクドット列を含むことができる。
【００９５】
前記システムは、前記カードを挿入するための細長い穴を有する棒状のアームを備える。
【００９６】
本発明のさらなる態様に従って、印刷されたカードに情報を担持させる方法を提供するものであって、該方法は、
カードの表面を多くの所定のエリアに分割するステップと；
該所定のエリアの内の第１エリアに格納されるべき第１のデータを印刷するステップと；
前記カードに保存されている情報を読み取るときに前記印刷された第１の所定エリアを使用するステップと；
該カードに保存された情報をアップデートするときに、該カードに保存されるさらなる情報が印刷される、データの印刷に使用されていない第２の所定エリアを決定するステップと；
を有する。
【００９７】
望ましくは、それらのエリアは、予め決められた順番で選択される。また、例えば、データのリード・ソロモン符号化によってもたらされるフォールトトレラントを有するデータを印刷するため、高解像度のインクドットプリンターを使用して印刷される。前記エリアのボーダーの線引きをするボーダー領域が印刷されて提供され、さらに、該ボーダー領域の位置を示すのに役立つ、多数のボーダー・ターゲット・マーカーが提供される。それらのボーダー・ターゲットは、第１色の大きなエリアと、該エリアの中心に配置される、第２色の小さなエリアとからなる。
【００９８】
望ましくは、前記データは、市松模様パターンのような高周波変調信号を使用して印刷されている。その印刷されたものは、１インチにつき約１２００ドットよりも大きい解像度のドット配列であり、好ましくは、１インチにつき少なくとも１６００ドットよりも大きい解像度を有するドット配列である。該所定のエリアは、該カードの表面にて標準の配列に配列することができ、該カードは、一般的な長方形のクレジットカードのようなサイズ及び形状にすることができる。
【００９９】
本発明のさらなる態様に従って、画像処理のための一連の指示を作成する方法が提供される。該方法は、
ユーザが選択するため、見本画像の初期配列を表示するステップと；
該見本画像の少なくとも１つをユーザが選択することを受諾するステップと；
見本画像のさらなる配列を作成するため、その選択結果を利用するステップと；
ユーザが最終的な最適画像を少なくとも１つ選択するまで、上述のステップを繰り返して適用するステップと；
前記一連の指示に従って見本画像を作成するステップと；
該一連の指示を出力するステップと；
を含む。
【０１００】
さらに、前記方法は、ユーザの写真をスキャンすることと、各見本画像の作成のための初期画像として該スキャンされた写真を使用すること、を含む。前記指示は、前記カードの第２面に視覚表示されるように印刷されるのに加えて、第１面にエンコード形式で印刷されることができる。加えて、処理画像自体は印刷される。
【０１０１】
前記配列を形成するため、遺伝的アルゴリズムや遺伝的プログラミング技術を含む画像の形成に様々な技術が使用され得る。さらに、さらなる画像の形成において、‘これまでのところベスト（best so far）’の画像が使用のために保存される。
【０１０２】
望ましくは、カードや写真を販売する自動販売機に組み込まれたコンピュータシステムにこの方法が実行される。
【０１０３】
本発明のさらなる態様に従って、挿入されたカードに情報を保存するための情報保存装置が提供され、該装置は、
カードの面に印刷されたパターンであって、カードの所定数の可能動作領域（possible active area）に配置されたパターンを検知するセンサー装置と；
該検知したパターンを対応するデータに復号化するためのデコード装置と；
カード表面であって前記活動領域の１つにドットパターンを印刷するための印刷装置と；
前記センサー装置及び前記印刷装置の公知の相対位置に、検知されるカードを配置する位置決め装置と；
を備え、
前記検知装置は、前記カードの最新の動作プリント領域にて印刷されたパターンを検知するように適合され、
前記デコード装置は、該検知したパターンを対応する最新のデータに復号化するように適合化され、
前記印刷装置は、最新のデータのアップデートが要求された場合に、カードの正確な位置決めのために位置決め装置が駆動された後、前記活動領域の内の最新の１つに、アップデートされた最新データをプリントするように適合される。
【０１０４】
前記印刷装置は、望ましくは、１度にカード幅の印刷が可能なカード幅プリントヘッドからなるインクジェットプリンタ装置を備える。前記位置決め装置は、カードを挟んでカードの移動をコントロールするための一連のピンチローラーを備えることができる。前記印刷されたパターンは、例えば、リードソロモン復号化を使用して、フォールトトレラント方法により配列され、前記デコード装置は、該フォールトトレラントパターンのために好適なデコーダを有する。
【０１０５】
本発明のさらなる態様に従って、
画像を検知するイメージ・センサーと；
検知画像及び関連するシステム構成を保存するためのストレージ装置と；
前記検知画像を修正するために画像修正データモジュールを入力するためのデータ入力装置と；
前記検知画像の処理に加えて前記カメラシステムのコントロールのために、前記イメージ・センサーや前記ストレージ装置や前記データ入力装置に接続された処理装置と；
供給されるプリントメディアに、要求に応じて前記検知画像を印刷するための印刷装置と；
を備えたデジタルカメラシステム、並びに、
さらなる画像修正モジュールの挿入に基づき、前記デジタルカメラシステムの操作の修正を前記処理装置にさせるように適合された、画像修正データモジュールの提供方法が提供される。
【０１０６】
望ましくは、符号化されたデータをその表面に有するカードを前記画像修正データモジュールが有し、そのデータの符号化は印刷により行われ、前記データ入力装置は、カード表面をスキャンするための光学スキャナーを有する。操作の修正は、繰り返し、同じ画像に、一連の画像修正モジュールが挿入される順にそれぞれ画像修正を行う。
【０１０７】
本発明のさらなる態様に従って、
画像を検知するイメージ・センサーと；
検知画像及び関連するシステム構成を保存するためのストレージ装置と；
前記検知画像を修正するために画像修正データモジュールを入力するためのデータ入力装置と；
前記検知画像の処理に加えて前記カメラシステムのコントロールのために、前記イメージ・センサーや前記ストレージ装置や前記データ入力装置に接続された処理装置と；
供給されるプリントメディアに、要求に応じて前記検知画像を印刷するための印刷装置と；
を備え、画像修正データモジュールは、デジタルカメラシステムにて一連の診断テストの実施、及び前記印刷装置を介した結果の印刷を前記処理装置が行うように適合されたデジタルカメラシステムが提供される。
【０１０８】
望ましくは、符号化された指示データをその一面に有するカードを前記画像修正データモジュールが有し、前記処理装置は、該カードに符号化された指示データを読み取るための装置を有する。前記診断テストは、連続した全てが黒の帯を印刷するなどによって、プリンター装置の操作を向上させるため、プリンター装置のためのクリーニングサイクルを有することもできる。代わりに、インクジェットプリンターの操作を向上させるため、前記診断テストがノズルの調節を含むこともできる。加えて、カメラシステムの様々な内部操作パラメータを印刷することもできる。重力衝撃センサーをカメラシステムに装備した場合には、前記診断テストは、該センサーの局地を印刷することもできる。
【０１０９】
本発明のさらなる態様に従って、画像を生成するためのカメラシステムが提供され、該カメラシステムは、画像を検知するセンサーと；何らかの所定の処理要求に従って前記検知画像を処理するための処理装置と；プリントメディアの面に前記検知画像を印刷するための印刷装置と；前記プリントメディアに形成された磁気感受性面に関連情報を記録するための磁気記録装置とを備える。前記関連情報は、検知画像に関連した音声情報を含み、前記印刷装置は、望ましくは、検知画像を前記プリントメディアの第１面に印刷し、前記磁気記録装置は前記プリントメディアの第２面に前記関連情報を記録する。前記プリントメディアは、前記カメラシステムの内部の取り外し可能なロールに収納されることができる。１つの実施例では、前記磁気感受性面は、前記プリントメディアの裏面に貼り付けられた帯片を含むことができる。
【０１１０】
本発明のさらなる態様に従って、携帯用カメラ装置のイメージセンサーにキャプチャーされた画像の、色落ちしないコピーを作る方法が提供される。前記携帯用カメラ装置は、該カメラ装置に格納されているプリントメディアに印刷するための一体型コンピュータ装置と一体型プリンター装置とを備えており、前記方法は、前記イメージセンサーにて画像を検知するステップと；フォールトトレラントの符号性質を持つ符号化形式に前記画像を変換するステップと；前記一体型プリンター装置を使用して画像の色落ちしない記録としての画像の符号化形式を印刷するステップとからなる。
【０１１１】
好ましくは、前記一体型プリンター装置は、プリントメディアの第１面及び第２面に印刷するための装置を備え、前記検知画像やその視覚的な処理は第１面に印刷され、符号化された形式は第２面に印刷される。検知画像のサムネイルは、前記画像のエンコード形式の横に印刷されることができる。また、そのフォールト・トレラント符号化は、永久的な録音が、反復可能な高周波スペクトラル成分を有する符号化形式に市松模様のような高周波変調信号を適用するのに加えて、画像のリードソロモン符号化バージョンを形成することも含む。
【０１１２】
本発明の第１の態様に従って、カメラ装置で使用される画像処理カードの販売のための販売システムが提供される。該カメラ装置は、画像処理カードの挿入のためのカード処理インターフェースを有する。該画像処理カードは、前記カメラ装置での画像の処理のためのものである。前記販売システムは、
画像処理カードを出力するための複数の印刷装置と；
該画像処理カードの作成のために必要な一連の画像処理カードデータのストレージのために、それぞれの印刷装置が対応するコンピュータシステムに接続されている。
【０１１３】
望ましくは、前記コンピュータシステムは、コンピュータ・ネットワークを介してキャッシュされる方法で、一連の画像処理カードデータを保存する。そして、カード配布コンピュータは、新しい画像処理カードをコンピュータシステムへ配布する。
【０１１４】
前記画像処理カードにイベントカード（季節ごとのイベントに利用すべくカードをプリントアウトするため、前記コンピュータシステムに分配される季節ごとのカード）が含まれる場合、本発明は特定用途を有する。
【０１１５】
本発明のさらなる態様に従って、オブジェクトの表面に符号化された、一連のブロックデータ領域を有するデータ構成が提供され、それぞれのブロックデータ領域は、
符号化された形式に復号化されるデータを含む符号化データ領域と；
該符号化データ領域の第１の周辺部を囲むように配置された、一連のクロックマーク構成と；
該符号化データ領域の第２の周辺部を囲むように配置された、一連の、簡単に特定できるターゲット構成と；
からなる。
【０１１６】
前記ブロックデータ領域は、さらに、前記符号化データ領域の第３の周辺部の周りに配置された方向データ構成（orientation data structure）を含む。該方向データ構成は、前記周辺部のエッジに沿った、等データ点の線（a line of equal data points）を含むことができる。
【０１１７】
前記クロックマーク構成は、符号化データ領域のエッジに沿って配置されたデータ点の実質的近接第２の線（a substantially adjacent second line）に加えて、等データ点の第１の線を有することができる。該クロックマーク構成は、符号化データ領域の反対側に配置されることができる。
【０１１８】
前記ターゲット構成は、間隙を有するように配置された一連のデータポイントブロック（data points blocks）のセットを有し、該データポイントは、中央部以外では、第１の大きさ（magunitude）の定値を有し、中央部では、前記第１の大きさとは逆の大きさを有する。前記ブロックのセットは、さらに、前記逆の大きさの連続群の値を有する、ターゲット数表示構成を含む。
【０１１９】
前記データ構成は、理想的には基材表面に印刷された一連のドットにて活用される。
【０１２０】
本発明の第２の態様に従って、オブジェクトの表面に符号化されたデータ構成を復号化する方法が提供され、該データ構成は一連のブロックデータ領域を有し、それぞれのブロックデータ領域は、
符号化された形式に復号化されるデータを含む符号化データ領域と；
該符号化データ領域の第１の周辺部を囲むように配置された、一連のクロックマーク構成と；
該符号化データ領域の第２の周辺部を囲むように配置された、一連の、簡単に特定できるターゲット構成と；
からなり、前記方法は、
(a)   前記データ構成をスキャンするステップと；
(b)   前記データ構成のスタートの位置を探すステップと；
(c)   前記ターゲット構成の最新の方向を判断して該ターゲット構成の位置を探すステップと；
(d)   前記ターゲット構成の位置から前記クロックマーク構成の位置を探すステップと；
(e)   前記符号化データ領域のビットデータの期待される位置を決定するために前記クロックマーク構成を使用するステップと；
(f)   各ビットデータのために期待されるデータ値を決定するステップと；
を有する。
【０１２１】
前記クロックマーク構成は、符号化データ領域のエッジに沿って配置されたデータ点の実質的近接第２の線（a substantially adjacent second line）に加えて、等データ点の第１の線を有することができる。前記(e) の、使用するステップは、前記クロックマーク構成中の最新の位置を維持するため、疑似位相ロックループタイプのアルゴリズムを使用してデータポイントの第２の線に沿ってランすることも含む。
【０１２２】
さらに、決定するステップ(f)
は、
検知したビット値を３つの隣接する領域（すなわち、中央領域、第１のｌｏｗｅｒ  ｅｘｔｒｅｍｅ  領域、及び第２のｕｐｐｅｒ  ｅｘｔｒｅｍｅ  領域）に分けることを含み、
第１の領域にそれらの値が含まれ、該第１の領域に対応するビット値を決定し；
第２の領域にそれらの値が含まれ、該第２の領域に対応するビット値を決定し；
前記中央領域にそれらの値が含まれ、その値が第１の値か第２の値かを決定するために空間的に囲まれる値を使用する。
【０１２３】
本発明のさらなる態様に従って、検知データの出力データ値を決定する方法が提供され、該方法は、
(a)   検知されたデータ値を３つの隣接する領域（すなわち、中央領域、第１のｌｏｗｅｒ  ｅｘｔｒｅｍｅ  領域、及び第２のｕｐｐｅｒ  ｅｘｔｒｅｍｅ  領域）に分けることを含み、
第１の領域にそれらの値が含まれ、該第１の領域に対応するビット値を決定し；
第２の領域にそれらの値が含まれ、該第２の領域に対応するビット値を決定し；
前記中央領域にそれらの値が含まれ、その値が第１の値か第２の値かを決定するために空間的に囲まれる値を使用する。
【０１２４】
本発明のさらなる態様に従って、複数の異なる供給スロットに複数の異なる流体を供給するための流体供給装置が提供される。該供給スロットは、交互に配置するという方法で周期的な間隔を置いて配置され、前記流体供給装置は、
複数の異なる流体のそれぞれのための流体注入口装置と；
異なる流体のそれぞれのための流路であって、前記供給スロットのそれぞれに接続されたメインチャンネル流路と；
前記供給スロットのそれぞれを、対応するメインチャンネル流路に接続するサブチャンネル流路と；
を備えている。流体の数は２よりも多く、成形された流体供給ユニットの第１面に少なくとも２本のメインチャンネル流体装置が形成され、他のメインチャンネル流体装置は、成形品の表面を貫通する貫通孔を介して前記スロットに接続されたサブチャンネル流路で該成形品の上面に形成される。
【０１２５】
望ましくは、前記供給装置は、プラスチック射出成形されており、前記スロットのピッチレートは、１インチ当たり１０００に等しいか、１０００よりも少ない。さらに、スロットの集合が、写真の幅に形成される。望ましくは、前記流体供給装置は、１又はそれ以上のピンチローラーを収容するためのローラースロット装置を複数有しており、前記流体はインクからなり、前記ローラーは、前記スロットに接続されたプリントヘッドをプリントメディアが横切るように制御される。前記スロットは、カラムに配置された一連のカラースロットに分割される。
【０１２６】
好ましくは、前記流体供給装置の少なくとも１つのチャンネルは、製造時に露出され、該露出面をシーリングテープにてシールされている。有利なことには、前記流体供給装置は、テープによる自動結合されたワイヤを得るため、ＴＡＢスロットにより提供される。
【０１２７】
本発明のさらなる態様に従って、インク供給路を介して供給するインク吐出装置を少なくとも１つ使用する画像印刷用プリンター装置が提供され、該装置は、
前記プリンターへのインク供給のためのインク供給装置に連動するように適合された、１つの出力色につき１つで一連のインク供給口と；
前記プリンター装置の外表面に沿った、一連の導電性コネクタパッドと；
インクを吐出させる一連のインク吐出装置を有するページ幅プリントヘッドと；
前記インク供給口から前記ページ幅プリントヘッドの前記インク吐出装置にインクを供給するインク供給システムと；
前記ページ幅プリントヘッドを前記導電性コネクタパッドに接続する、複数の相互接続ワイヤと；
を備え、
前記プリンター装置は、ハウジング装置の中に取り外し可能に挿入されるように適合され、該ハウジングは、前記導電性コネクタパッドとの相互接続のための相互接続部や、前記インク供給装置によるインクの供給のため、前記インク供給口との相互接続のためのインク供給コネクタを有している。
【０１２８】
望ましくは、前記複数の相互接続ワイヤは、前記プリンター装置の外面を包み込むと共に、導電性コネクターパッドに接続されたテープ自動ボンディング・シートを形成する。該相互接続されたワイヤーは、
前記導電性コネクターパッドに相互接続されると共に、プリントヘッドの全長に沿って互いにほぼ平行な配置された第１のセットのワイヤーと、
該プリントヘッドの表面から互いにほぼ平行に配置された第２のセットのワイヤーと、
を有している。第１のセットのワイヤーのそれぞれは、第２のセットのワイヤの多くに接続されている。前記インク供給口は、薄いダイアフラム部を有している。該ダイアフラム部は、前記インク供給コネクタが前記ハウジング装置に挿入されることに基づき穴が開けられている。
【０１２９】
前記ページ幅プリントヘッドは、それぞれに所定数のインク吐出装置を有する、実質的に等しく繰り返し可能なユニット（substantially identical repeatable unit）を多数備えることができる。該ユニットは、所定数の接続ワイヤを有する標準インターフェースを有し、各標準インターフェース装置は、導電性コネクタパッドにグループで接続される。該プリントヘッド自体は、シリコンウェハから作成されることができ、ページ幅ストリップに分離される。
【０１３０】
本発明のさらなる態様に従って、電流の変動をモニターするという方法によって集積回路のモニタリングに対する抵抗を与える方法が提供され、前記方法は、前記集積回路の一部であるスプリアスノイズ発生回路を形成するステップを含む。
【０１３１】
前記ノイズ発生回路はＬＦＳＲ（リニア・フィードバック・シフト・レジスタ）のような乱数発生器を含むことができる。
【０１３２】
本発明のさらなる態様に従って、低消費電力のＣＭＯＳ回路が提供される。該回路は、第１のクロックと入力とに接続されたゲートを有するｐタイプのトランジスタ、及び、第２のクロックと入力とに接続されたｎタイプのトランジスタを備え、該ＣＭＯＳ回路は、オーバーラップしない方法により前記第１及び第２のクロックが切り換えられることに稼動される。
【０１３３】
該回路は、高出力スイッチング特性（high power switching characteristics）を持つ第２の回路に実質的に隣接されることができる。該第２の回路は、ノイズ発生回路を有することができる。
【０１３４】
本発明のさらなる態様に従って、異なる出力状態に対応する複数のレベル状態を有する、メモリー回路のモニタリングに対する抵抗を与える方法が提供され、該方法は、有効な出力状態のためだけに中間状態を利用することを含む。該メモリーはフラッシュメモリーにすることができ、さらに、１かそれ以上のパリティビットを有することができる。
【０１３５】
本発明のさらなる態様に従って、集積回路に手を加える攻撃（attempt）をモニターするため、ランダムノイズ発生器に取り付けられた回路（circuit path）を使用する、前記集積回路に手を加えることに対する抵抗を与える方法が提供される。
【０１３６】
前記回路（circuit
path）は、互いに逆であって、様々な回路に接続され、リセット出力信号を生成するための排他的ＯＲ回路となる、第１パス及び第２パスを有する。
【０１３７】
本発明の第２の態様に従って、接地された大きな抵抗に一端が接続され、電源に接続された第２の大きな抵抗に他端が接続されたタンパー検出ラインが提供される。該タンパー検出ラインは、さらに、期待される電圧が所定の許容範囲内にあるかを比較するコンパレータに接続される。一連のテストに接続される抵抗の中間には、そのテストの１つによってタンパリングが検出された場合にコンパレータがリセット信号を出力するように大きな抵抗が出力される。
【０１３８】
本発明のさらなる態様に従って、認証されるべき付属ユニットの有効性を判断するための認証システムが提供され、該システムは、
第１及び第２のセキュアキーの確認のための中央システムユニットと；
該中央システムユニットに取り付けられた第１及び第２のセキュアキーを保持するオブジェクトと；
を備え、
第２のセキュアキーを保持するオブジェクトは取り外せないような方法で取り付けられ、
前記中央システムユニットは、
第１のレスポンスを決定するために前記第１のセキュアキーを保持するオブジェクトに問い合わせを行い、
第２のレスポンスを決定するために前記第２のセキュアキーを保持するオブジェクトに問い合わせを行うために前記第１のレスポンスを利用し、
さらに、
前記第２のセキュアキーを保持するオブジェクトが、有効な取り付けユニットに取り付けられているかどうかを判断するために、前記第１のレスポンスと前記第２のレスポンスを比較するように適合されている。
【０１３９】
前記取り付けユニットの所定の使用の後に該ユニットが作動を止めるように、前記第２のセキュアキーを保持するオブジェクトは、さらに、効果的に単調減少するマグニチュード・ファクターを有するレスポンスを含む。したがって、取り付けられたユニットは、消耗品を含むことができる。
【０１４０】
さらに、前記中央システムユニットは、前記第１のレスポンスを受け取った数を前記第１のセキュアキーを保持するオブジェクトに問い合わせることができ、そのとき、該中央システムユニットは、第２のレスポンスの判断のための前記第２のセキュアキーを保持するオブジェクトへの問い合わせに際して前記第１のレスポンスを使用し、該中央システムユニットは、前記第２のレスポンスの有効範囲を判断するため、前記第１のセキュアキーを保持するユニットに問い合わせを行うために前記第２のレスポンスを使用する。
【０１４１】
該システムは、理想的には、インクジェットプリンターにおけるインクのように、プリンターの消耗品を認証するために使用される。
【０１４２】
実際に、内蔵型インクジェットプリンターを有するカメラシステムにおいて、消耗品であるインクに関連して、好ましい実施例が論じられるだろうけれども、本発明がそのことに限定されるものではない。
【好適なその他の実施例の説明】
【０１４３】
好適な実施例により構成されたデジタル画像処理カメラシステムは、図１に示されている。カメラユニット１は、一体的なプリントロール（図示しない）を挿入する手段を含む。カメラユニット１は、カメラによって撮影される像３を検出するエリアイメージセンサ２を含む。オプションとして、シーン３を映像化し、オプション的に立体画法の出力効果の生成物を得るため、第２のエリアイメージセンサを搭載してもよい。
【０１４４】
カメラ１は、センサ２によって検出された像を表示するためのオプションのカラーディスプレイ５を含む。シンプルな像がディスプレイ５に表示されるとき、ボタン６を押下することが可能であり、その結果、印刷された画像８がカメラユニット１によって出力される。以下では、Ａｒｔｃａｒｄ（アートカード）９と呼ばれる一連のカードは、一方の面に符号化された情報を含み、もう一方の面に、Ａｒｔｃａｒｄ９により生成された特定の効果によって歪められた画像を含む。Ａｒｔｃａｒｄ９は、カメラ１の側面にあるＡｒｔｃａｒｄリーダー１０に挿入され、挿入されると、Ａｒｔｃａｒｄ９の面に現れた歪みと同じ方法で歪められた出力画像８が得られる。したがって、この簡単なユーザインタフェースを使用することにより、特定の効果を生じさせることを望むユーザは、多数のＡｒｔｃａｒｄ９のうちの一枚をＡｒｔｃａｒｄリーダー１０に挿入し、像３の写真を撮影するためボタン１９を利用することが可能であり、その結果、対応した歪んだ出力画像８が得られる。
【０１４５】
カメラユニット１は、カメラユニットの内部プリントロールに残っているプリントアウトの数を含む説明情報を表示するための簡単なＬＣＤ出力ディスプレイ１５に加えて、多数の他の制御ボタン１３、１４を含み得る。更に、様々な出力フォーマットがＣＨＰスイッチ１７によって制御され得る。
【０１４６】
次に図２を参照すると、カメラ１の内部ハードウェアの概略図が示されている。内部ハードウェアは、Ａｒｔｃａｍ（アートカム）中央プロセッサユニット（ＡＣＰ）３１を中心としている。
【０１４７】
Ａｒｔｃａｍ中央プロセッサ３１
Ａｒｔｃａｍ中央プロセッサ３１は、システムの心臓部を形成する多数の機能を提供する。ＡＣＰ３１は、好ましくは、複雑な高速ＣＭＯＳシステムオンチップとして実現される。一部のフルカスタム領域を有する標準的なセル設計を利用することが推奨される。０．２５ミクロンＣＭＯＳプロセス上の製作は、合理的に小さいダイ面積と共に、要求され
る密度及び速度を実現する。
【０１４８】
ＡＣＰ３１によって与えられる機能には次の機能が含まれる：
１． エリアイメージセンサ２の制御及びデジタル化。ＡＣＰの３次元立体視バージョンは、第２のオプションのイメージセンサ４が立体視効果のために設けられた二つのエリアイメージセンサインタフェースを必要とする；
２． エリアイメージセンサ補償、再フォーマッティング、及び画像強調；
３． 記憶装置３３に対するメモリインタフェース及び管理；
４． Ａｒｔｃａｒｄ９からのデータの読み出しのために設けられたＡｒｔｃａｒｄリーダーのリニアイメージセンサ３４のインタフェース、制御及びアナログ・デジタル変換；
５． デジタル化された符号化Ａｒｔｃａｒｄ画像からの未加工Ａｒｔｃａｒｄデータの抽出；
６． Ａｒｔｃａｒｄの符号化データのリード・ソロモン誤差検出及び訂正。Ａｒｔｃａｒｄ９の符号化された面は、Ａｒｔｃａｒｄ９の画像歪み面に表示された効果を生成するためどのように画像を処理するかに関する情報を含む。この情報は、以下では、「Ｖａｒｋスクリプト」と呼ばれるスクリプトの形式である。Ｖａｒｋスクリプトは、望ましい効果を生成するためＡＣＰ３１内で実行されるインタープリタによって利用される；
７． Ａｒｔｃａｒｄ９上のＶａｒｋスクリプトの解釈；
８． Ｖａｒｋスクリプトによって指定されたとおりの画像処理動作の実行；
９． 用紙輸送３６、ズームレンズ３８、自動焦点３９、及びＡｒｔｃａｒｄドライバ３７のための様々なモーターの制御；
１０． プリントロール４２からの写真８を裁断する裁断機４１の動作用の裁断機アクチュエータ４０の制御；
１１． 印刷用画像データの中間調化；
１２． 適当な時におけるプリントヘッド４４へのプリントデータの供給；
１３． プリントヘッド４４の制御；
１４． プリントヘッド４４へのインク圧送の制御；
１５． オプションのフラッシュユニット５６の制御；
１６． 方位センサ４６、自動焦点４７及びＡｒｔｃａｒｄ挿入センサ４９を含むカメラ内の様々なセンサの読み出し及びそれに基づく処置；
１７． ユーザインタフェースボタン６、１３、１４の読み出し及びそれに基づく処置。
１８． 状態ディスプレイ１５の制御；
１９． ビューファインダー及びプレビュー画像のカラーディスプレイ５への供給；
２０． 電力管理回路５１によるＡＣＰ電力消費を含むシステム電力消費の制御；
２１． 汎用コンピュータへの外部通信５２の提供（パートＵＳＢを使用）；
２２． プリントロール認証チップ５３の情報の読み出し及び保存；
２３． カメラ認証チップ５４の情報の読み出し及び保存；
２４． テキスト修正用のオプションのミニキーボード５７との通信。
【０１４９】
水晶振動子５８
水晶振動子５８は、システムクロック用の周波数基準として使用される。システムクロックは非常に高いため、ＡＣＰ３１は水晶５８から得られた周波数を増大させるため位相ロックループクロック回路を含む。
【０１５０】
イメージセンシング
エリアイメージセンサ２
エリアイメージセンサ２は、そのレンズを通る像を電気信号へ変換する。エリアイメージセンサは、電荷結合素子（ＣＣＤ）でもよく、アクティブ画素センサ（ＡＰＳ）ＣＭＯＳイメージセンサでもよい。現在のところ、利用可能なＣＣＤは、通常、かなり高い画質を有するが、ＣＭＯＳイメージャの開発は、現在、非常に盛んに行われている。ＣＭＯＳイメージャは、最終的には、画素数の少ないＣＣＤよりも実質的に安価になり、駆動回路及び信号処理を組み込み得ることが予想される。ＣＭＯＳイメージャは、１２インチウェハーに移行しているＣＭＯＳ製造技術で製作することが可能である。したがって、ＣＣＤとＣＭＯＳイメージャの間の製造コストの差は増加し、徐々にＣＭＯＳイメージャの方が支持される可能性が高い。しかし、現在のところ、ＣＣＤは、最良の選択肢である。
【０１５１】
Ａｒｔｃａｍユニットは、１５００×１０００型のエリアイメージセンサで適切な結果を生じるであろう。しかし、例えば、７５０×７００型のような小型のセンサも、様々な市場で適切であろう。Ａｒｔｃａｍは、従来のデジタルカメラと比べると、イメージセンサの解像度に対する感度が低い。その理由は、Ａｒｔｃａｒｄ９に入っている殆どのスタイルは、解像度の不足をわかりにくくするように画像を処理するからである。例えば、画像が印象派の絵画へ変換される効果をシミュレートするため歪められる場合、原画像の低解像度は最小の影響で使用可能である。低解像度入力画像が典型的に気付かれない更なる例には、極めて歪んだ画像を生じる画像ワープ、画像の複数の縮写（例えば、パスポート写真）、ベースレリーフメタルルックのためのバンプマッピングのようなテクスチャ処理、及び構造化されたシーンへの写真合成が含まれる。
【０１５２】
このように低解像度イメージセンサを許容することは、Ａｒｔｃａｍユニット１カメラの製造コストを低下させる重要なファクタである。低コストの７５０×５００型イメージセンサを用いるＡｒｔｃａｍは、しばしば、非常に高価な１５００×１０００型イメージセンサを用いる従来のデジタルカメラよりも優れた結果を生じる。
【０１５３】
オプションの立体視３次元イメージセンサ４
Ａｒｔｃａｍユニット１の３次元バージョンは、立体視動作のため補助イメージセンサ４を備える。このイメージセンサは、主イメージセンサと同一である。オプションのイメージセンサを駆動する回路は、設計コストの増大を低減するため、ＡＣＰチップ３１の標準部品として収容してもよい。或いは、別個の３次元Ａｒｔｃａｍ 
ＡＣＰを設計してもよい。このオプションは、主流の単一センサ型のＡｒｔｃａｍの製造コストを削減する。
【０１５４】
プリントロール認証チップ５３
小型チップ５３は、各プリントロール４２に収容される。このチップは、ＡＰＳ（新写真システム）フィルムカートリッジのような他の形態のカメラフィルムユニット上のバーコード、光学センサ及びホイール、並びに、ＩＳＯ／ＡＳＡセンサの機能を置き換える。
【０１５５】
認証チップは、以下のその他の機能も提供する：
１． ＡＰＳロールから機械的及び光学的に検出されるデータではなく、データの保存；
２． 高解像度の正確さの媒体の残りの長さの表示；
３． 粗悪な模造プリントロールコピーを防止するための認証情報。
【０１５６】
認証チップ５３は、１０２４ビットのフラッシュメモリを含み、１０２４ビットのうちの１２８ビットは認証鍵であり、５１２ビットは認証情報である。更に、認証鍵が直接アクセスされないことを保証するため、暗号化回路が収容される。
【０１５７】
プリントヘッド４４
Ａｒｔｃａｍユニット１は、十分に小規模、十分に低電力、十分に高速、十分に高品質、及び十分に低コストであり、プリントロールに適合したどのようなカラー印刷技術でも利用可能である。以下、当該印刷ヘッドについて具体的に説明する。
【０１５８】
インクジェットヘッドの仕様は以下の通りである。
【０１５９】
【表１】
0004309954.tif 000002
オプションのインク圧コントローラ（図示せず）
インク圧コントローラの機能は、Ａｒｔｃａｍに組み込まれたインクジェットプリントヘッド４４のタイプに依存する。一部のタイプのインクジェットでは、インク圧は単純に大気圧であるため、インク圧コントローラを使用しなくても済む。他のタイプのプリントヘッドは、安定化した正のインク圧を必要とする。この場合、インプレッシャ・コントローラは、ポンプ及び圧力トランスデューサを含む。
【０１６０】
その他のプリントヘッドは、インク圧力に、典型的に約１００ＫＨｚの規則的な振動を生じさせるため超音波トランスデューサが必要である。この場合、ＡＣＰ３１は、これらの振動の周波数位相及び振幅を制御する。
【０１６１】
用紙輸送モーター３６
用紙輸送モーター３６は、プリントロール４２内からプリントヘッドの傍を通して、一定速度で用紙を移動させる。モーター３６は、用紙を移動させるローラーを駆動するため適切な速度までギアダウンされた小型モーターである。機械的なガタ又はその他の振動が印刷されたドット行間隔に影響を与えるので、高画質を実現するためには、高品質モーターと機械式ギアが必要である。
【０１６２】
用紙輸送モータードライバ６０
モータードライバ６０は、ＡＰＣ３１からのデジタルモーター制御信号をモーター３６の駆動に適切なレベルまで増幅する小型回路である。
【０１６３】
用紙プルセンサ
用紙プルセンサ５０は、印刷プロセス中にユーザによるカメラユニットからの写真の引っ張りを検出する。ＡＰＣ３１は、このセンサ５０を読み出し、この状況を検出した場合、裁断機４１を作動する。用紙プルセンサ５０は、動作中にカメラをより絶対確実にするために組み込まれる。ユーザが印刷中に強引に用紙を引き出そうとした場合、プリント機構４４又はプリントロール４２は、（極端なケースでは）破損するであろう。ポッドが完全に排出される前にポラロイド式カメラからポッドを引き出すことが許されるので、一般の人々はこのような動作を行うことに慣れている。したがって、一般の人々は、用紙を引き出してはならないという印刷された指示に留意しない可能性が高い。
【０１６４】
Ａｒｔｃａｍは、好ましくは、引っ張り検出後に裁断機４１が用紙を裁断した後、写真印刷プロセスを再開する。
【０１６５】
引っ張りセンサは、歪みゲージセンサとして実現してもよく、又は用紙が引っ張られたときに用紙ドライブローラーに発生するトルクによって偏向される小さいプラスチック製のフラグを検出する光学センサとして実現してもよい。後者の実現形態は、低コストのため推奨される。
【０１６６】
用紙裁断機アクチュエータ４０
用紙裁断機アクチュエータ４０は、写真の終わりに、又は用紙引っ張りセンサ５０が作動されたときに、裁断機４１に用紙を裁断させる小型アクチュエータである。
【０１６７】
用紙裁断機アクチュエータ４０は、ＡＰＣからの裁断機制御信号をアクチュエータ４１によって要求されるレベルまで増幅する小型回路である。
【０１６８】
Ａｒｔｃａｒｄ９
Ａｒｔｃａｒｄ９はＡｒｔｃａｍユニット用のプログラム記憶媒体である。前述の通り、プログラムは、Ｖａｒｋスクリプトの形式である。Ｖａｒｋは、特に、Ａｒｔｃａｍユニットのため開発された強力な画像処理言語である。各Ａｒｔｃａｒｄ９は一つのＶａｒｋスクリプトを格納し、これによって、一つの画像処理スタイルを規定する。
【０１６９】
好ましくは、ＶＡＲＫ言語は高度に画像処理専用である。高度に画像処理専用とすることにより、カード上に詳細を記憶するために要する記憶容量は実質的に減少する。更に、機能強化された効果を含む新しいプログラムを作成できる簡便さは、実質的に向上する。好ましくは、この言語は、ワープマップによる画像ワーピング、コンボリューション、カラールックアップテーブル、画像のポスタリゼーション、画像へのノイズ付加、画像強調フィルタ、ペインティングアルゴリズム、ブラシジッタリング及び操作エッジ検出フィルタ、タイリング、光源による照明、バンプマップ、テキスト、顔検出及び物体検出属性、３次元フォントを含むフォント、並びに、任意の複合予備レンダリングアイコンを含む多数の画像処理機能を取り扱う機能を含む。Ｖａｒｋ言語インタープリタの動作のより詳細な内容は以下に記載される。
【０１７０】
したがって、作成された言語によって定義されるような言語構造を利用することにより、任意の画像に対する新しい影響を作成し、Ａｒｔｃａｒｄ上の安価な記憶装置のために構築し、その後、カメラの所有者に配布することが可能である。更に、カードの片面には、カードのもう一方の面に記憶された特定のＶＡＲＫスクリプトが任意の撮影像に与える影響を説明する例が設けられる。
【０１７１】
このようなシステムを利用することにより、ＶＡＲＫインタープリタがカメラ装置に組み込まれているならば、装置に依存しないシナリオが与えられ、その結果として、根本的な技術が長期のうちに完全に変えられるという点で、カメラ技術は、著しく陳腐化する虞を伴わずに普及させることができる。更に、新しいフィルタが作成され、カード読み出し用の簡単なカードを用いるような、安価な方式で配布されたときに、Ｖａｒｋスクリプトを更新することが可能である。
【０１７２】
Ａｒｔｃａｒｄ９は、クレジットカード（長さ８６ｍｍ、幅５４ｍｍ）と同一フォーマットの薄い白色プラスチック製の片である。Ａｒｔｃａｒｄは、高解像度インクジェットプリンタを使用して両面印刷されている。このインクジェットプリンタ技術は、１６００ｄｐｉ（６３ｄｐｍｍ）の解像度のＡｒｔｃａｍに使用される技術と同じ技術であると考えられる。Ａｒｔｃａｒｄ９の主要な特徴は、安価な製造コストである。Ａｒｔｃａｒｄは、プラスチックフィルムの幅広いウェブと同様に高速で製造可能である。プラスチックウェブは、親水性の染料固着層で両面を覆われる。ウェブは、ページ幅のカラーインクジェットプリンタを用いて両面同時に印刷される。次に、ウェブは、個別のカードに切断され打ち抜かれる。カードの一方の面は、Ａｒｔｃａｒｄ９が検出された像に与える影響を人が読める形で表現したものが印刷される。これは、カードの裏面に記憶されたＶａｒｋスクリプトを使用して処理された単純な標準画像でもよい。
【０１７３】
カードの裏面には、画像処理シーケンスを定義するＶａｒｋスクリプトに復号化され得るドットの配列が印刷される。この印刷面積は８０ｍｍ×５０ｍｍであり、全部で１５８７６０００ドットがある。このドットの配列は、少なくとも１．８９ＭＢｙｔｅのデータを表現することができる。高信頼性を実現するため、広範な誤り検出及び訂正がドットの配列に組み込まれる。これにより、カードの実質的な部分が汚損され、損耗され、皺を付けられ、或いは、汚されても、データの完全性に影響が及ばないようにすることができる。使用されるデータ符号化方式はリード・ソロモン符号化であり、データの半分が誤り訂正のために用いられる。これにより、各Ａｒｔｃａｒｄ９には、誤り訂正された９６７Ｋｂｙｔｅのデータを記憶させることができる。
【０１７４】
リニアイメージセンサ３４
Ａｒｔｃａｒｄリニアセンサ３４は、上記のＡｒｔｃａｒｄデータ画像を電気信号へ変換する。エリアイメージセンサ２、４の場合と同様に、リニアイメージセンサは、ＣＣＤ又はＡＰＳ 
ＣＭＯＳ技術を用いて製造可能である。イメージセンサ３４の有効長さは５０ｍｍであり、Ａｒｔｃａｒｄ９上のデータ配列の幅と一致する。ナイキストのサンプリング定理を充たすため、リニアイメージセンサ３４の解像度は、イメージセンサに到達するＡｒｔｃａｒｄ光学像の最高空間周波数の少なくとも２倍でなければならない。実際上、データ検出は、イメージセンサ解像度がこれよりも実質的に高くなった場合、より簡単になる。４９００ｄｐｉ（１８０ｄｐｍｍ）の解像度が選ばれた場合、全部で９４５０画素が与えられる。この解像度は、５．３μｍの画素センサピッチを必要とする。これは、千鳥状にされた４行の２０μｍ画素センサを使用することによって簡単に実現することができる。
【０１７５】
リニアイメージセンサは、ライトパイプ（図示せず）によってＡｒｔｃａｒｄ９を照明するためのＬＥＤ６５を含む特殊なパッケージに装着される。
【０１７６】
Ａｒｔｃａｒｄリーダーのライトパイプは、以下の数機能を備えた成形ライトパイプでもよい：
１． ライトパイプは、全ての内部反射ファセットを使用してカードの幅に亘ってＬＥＤからの光を拡散する。
２． ライトパイプは、集積化されたシリンドリカルレンズを使用してＡｒｔｃａｒｄ９の１６μｍ幅のストリップ上に光を集める。
３． ライトパイプは、成形されたマイクロレンズの配列を使用してＡｒｔｃａｒｄから反射された光をリニアイメージセンサの画素に集める。
【０１７７】
次に、Ａｒｔｃａｒｄリーダーの動作を説明する。
【０１７８】
Ａｒｔｃａｒｄリーダーモーター３７
Ａｒｔｃａｒｄリーダーモーターは、比較的一定の速度でＡｒｔｃａｒｄを進めてリニアイメージセンサ３４を通過させる。厳密な精度の機械コンポーネントをＡｒｔｃａｒｄリーダーに収容することは費用対効果がよくないので、モーター３７は、Ａｒｔｃａｒｄ９を動かすローラーのペアを駆動するため適切な速度までギアダウンされた標準的な小型モーターである。速度変動、ガタ、及びその他の振動は、未加工の画像データに影響を与えるので、ＡＰＣ３１内の回路は、Ａｒｔｃａｒｄデータを確実に読むためこれらの効果の広範な補償を行う。
【０１７９】
モーター３７は、Ａｒｔｃａｒｄを取り出すとき、逆向きに駆動される。
【０１８０】
Ａｒｔｃａｒｄモータードライバ６１
Ａｒｔｃａｒｄモータードライバ６１は、モーター３７を駆動するために適切なレベルまでＡＰＣ３１からのデジタルモーター制御信号を増幅する小型回路である。
【０１８１】
カード挿入センサ４９
カード挿入センサ４９は、カードリーダー３４に挿入されているカードの有無を検出する光学センサである。このセンサ４９からの信号の後、ＡＰＣ３１はカード読み出しプロセスを開始し、そのプロセスには、Ａｒｔｃａｒｄリーダーモーター３７の作動が含まれる。
【０１８２】
カードイジェクトボタン１６
カードイジェクトボタン１６（図１）は、現在のＡｒｔｃａｒｄを取り出すためユーザによって使用され、他のＡｒｔｃａｒｄを挿入できるようになる。ＡＰＣ３１は、ボタンの押下を検出し、カードを取り出すため、Ａｒｔｃａｒｄリーダーモーター３７を反転させる。
【０１８３】
カード状態インジケータ６６
カード状態インジケータ６６は、Ａｒｔｃａｒｄ読み出しプロセスの状態をユーザへ報せるために設けられる。これは、標準的な２色（赤／緑）ＬＥＤでもよい。カードが正しく読み出され、データの完全性が検証されたとき、ＬＥＤは連続的に緑色で発光する。カードが不良である場合、ＬＥＤは赤色で発光する。
【０１８４】
カメラが３Ｖのバッテリではなく１．５Ｖのバッテリから給電される場合、電源電圧は、緑色ＬＥＤの前向き電圧降下よりも小さく、ＬＥＤは発光しない。この場合、赤色ＬＥＤが使用されるか、又はそのＬＥＤは、より高い電圧を必要とするＡｒｔｃａｍ内の他の回路に給電する電圧ポンプから給電される。
【０１８５】
６４ＭビットＤＲＡＭ３３
多種多様な画像処理効果を実行するため、カメラは８Ｍｂｙｔｅのメモリ３３を利用する。これは、単一の６４Ｍビットメモリチップによって設けることができる。勿論、メモリ技術の変化に伴って、より大容量のＤＲＡＭ記憶容量サイズで置き換えても構わない。
【０１８６】
メモリチップへの高速アクセスが要求される。これは、Ｒａｍｂｕｓ
ＤＲＡＭ（毎秒５００メガバイトのバーストアクセス速度）、又はダブルデータレート（ＤＤＲ）ＳＤＲＡＭ又はシンクリンク（ＳｙｎｃＬｉｎｋ）ＤＲＡＭチップを使用することによって達成できる。
【０１８７】
カメラ認証チップ
カメラ認証チップ５４は、異なる情報を記憶している点を除くと、プリントロール認証チップ５３と同一のものである。カメラ認証チップ５４には、以下の三つの主要な目的がある：
１． 認証コードをプリントロール認証チップと比較するセキュア手段を設けること；
２． カメラの製造番号のような製造情報用の記憶装置を設けること；
３． ユーザ情報の記憶用の小容量の不揮発性メモリを設けること。
【０１８８】
ディスプレイ
Ａｒｔｃａｍは、オプションのカラーディスプレイ５及び小型状態ディスプレイ１５を含む。最低コストの民生用カメラは、ある種のデジタルカメラ及びビデオカメラで見られるような小型ＴＦＴ 
ＬＣＤ５のようなカラー画像ディスプレイを含む。カラーディスプレイ５は、これらのバージョンのＡｒｔｃａｍの主要なコストのかかる要素であり、バックライトを加えたディスプレイ５は主要な電力消費元である。
【０１８９】
状態ディスプレイ１５
状態ディスプレイ１５は、小型の受動セグメントに基づくＬＣＤであり、現在のハロゲン化銀式カメラ及びデジタルカメラに設けられているＬＣＤと類似している。その主要な機能は、プリントロール４２に残っているプリントの数と、フラッシュ状態及びバッテリ状態のような様々な標準的なカメラ機能に対するアイコンと、を表示することである。
【０１９０】
カラーディスプレイ５
カラーディスプレイは、完全動画像ディスプレイであり、ビューファインダーとして、印刷される画像の確認として、及びユーザインタフェースディスプレイとして動作する。ディスプレイ５のコストは、その面積にほぼ比例するので、大型ディスプレイ（例えば、４インチ対角）ユニットは、Ａｒｔｃａｍユニットの高価なバージョンに限定される。例えば、カラービデオカメラの約１インチのビューファインダーＴＦＴのようなより小さいディスプレイは、中程度のＡｒｔｃａｍに有効である。
【０１９１】
ズームレンズ（図示せず）
Ａｒｔｃａｍはズームレンズを含むことができる。これは、標準的な電子カメラに使用されるズームレンズと同一であり、ポケットカメラのズームレンズに類似している標準的な電子制御ズームレンズでもよい。Ａｒｔｃａｍユニットの好適なバージョンは、標準的な交換可能な３５ｍｍＳＬＲレンズを含む。
【０１９２】
自動焦点モーター３９
自動焦点モーター３９はズームレンズの焦点を変更する。モーターは、自動焦点機構を駆動するため適切な速度にギアダウンされた小型モーターである。
【０１９３】
自動焦点モータードライバ６３
自動焦点モータードライバ６３は、モーター３９を駆動するため適切なレベルまでＡＰＣ３１からのデジタルモーター制御信号を増幅する小型回路である。
【０１９４】
ズームモーター３８
ズームモーター３８は、ズームのフロントレンズを出入りするように動かす。モーターは、ズーム機構を駆動するため適切な速度にギアダウンされた小型モーターである。
【０１９５】
ズームモータードライバ６２
ズームモータードライバ６２は、モーターを駆動するため適切なレベルまでＡＰＣ３１からのデジタルモーター制御信号を増幅する小型回路である。
【０１９６】
通信
ＡＣＰ３１は、パーソナルコンピュータとの通信用のユニバーサルシリアルバス（ＵＳＢ）インタフェース５２を含む。必ずしも全てのＡｒｔｃａｍモデルがＵＳＢコネクタを組み込むことを予定されているわけではない。しかし、ＵＳＢ回路５２のために必要なシリコン面積は小さいので、インタフェースを標準的なＡＣＰに収容することが可能である。
【０１９７】
オプションのキーボード５７
Ａｒｔｃａｍユニットは、Ａｒｔｃａｒｄによって指定されたテキストをカスタマイズするオプションの小型キーボード５７を含む。Ａｒｔｃａｒｄ画像に現れるあらゆるテキストは、複雑なメタリック３次元フォントの形である場合でも編集可能である。小型キーボードは、元のテキストと編集されたテキストを表示するため単一ラインの英数字ＬＣＤを含む。このキーボードは標準装備品でもよい。
【０１９８】
ＡＣＰ３１は、小型キーボートとの間でデータを転送するシリアル通信回路を含む。
【０１９９】
電源
Ａｒｔｃａｍユニットは、バッテリ４８を使用する。Ａｒｔｃａｍのオプションに依存して、このバッテリは、３Ｖのリチウム電池、１．５ＶのＡＡアルカリ電池、又はその他のバッテリ装置のいずれでもよい。
【０２００】
電源管理ユニット５１
電源消費は、Ａｒｔｃａｍにおける重要な設計制約条件である。標準的なカメラバッテリ（例えば、３Ｖのリチウムバッテリ）又は標準的なＡＡ若しくはＡＡＡアルカリ電池の何れかが使用可能であることが望ましい。Ａｒｔｃａｍユニットの電子回路の複雑さの程度は３５ｍｍ写真カメラよりも著しく高いが、電力消費量が相応に高いとは限らない。Ａｒｔｃａｍの電源は、全てのユニットが未使用時には電源をオフされるように慎重に管理される。
【０２０１】
最も重大な電力浪費元は、ＡＰＣ３１、エリアイメージセンサ２及び４、プリンタ４４の様々なモーター、フラッシュユニット５６、並びに、オプションのカラーディスプレイ５である。次に各部品について別々に取り扱う：
１． ＡＣＰ：０．２５μｍのＣＭＯＳを使用して製造され、１．５Ｖで動作するならば、ＡＣＰ電力消費は非常に小さくすることができる。ＡＣＰチップの様々な部品へのクロックも非常に小さくすることができる。ＡＣＰチップの様々な部品へのクロックは、未使用時にオフにすることができ、スタンバイ電流消費を殆ど取り除く。ＡＣＰは、印刷される写真毎に約４秒間だけ完全に使用される；
２． エリアイメージセンサ：電力は、ユーザがボタンに指を置いたときに限りエリアイメージセンサに供給される；
３． プリンタ電力は、実際に印刷しているときに限りプリンタへ供給される。これは、１枚の写真につき約２秒間である。たとえそうであっても、適度に低い電力消費印刷が使用されるべきである；
４． Ａｒｔｃａｍで必要になるモーターは、全て低電力小型モーターであり、典型的に、１枚の写真について数秒間だけ作動される；
５． フラッシュユニット４５は、一部の写真だけに対して使用される。その電力消費は、妥当なバッテリ寿命の３Ｖのリチウムバッテリによって容易に供給される。
６． オプションのカラーディスプレイ５は、次の二つの理由から主要な電流浪費元である。カラーディスプレイは、カメラの使用中の全ての時間に亘ってオンにする必要があり、液晶ディスプレイが使用された場合には、バックライトが必要になる。カラーディスプレイを組み込むカメラは、許容可能なバッテリ寿命を達成するため、より大型のバッテリを要求する。
【０２０２】
フラッシュユニット５６
フラッシュユニット５６は民生用カメラの標準的な小型電子フラッシュである。
【０２０３】
ＡＣＰ３１の概要
図３は、Ａｒｔｃａｍ中央プロセッサ（ＡＣＰ）３１を詳細に示す図である。Ａｒｔｃａｍ中央プロセッサは、Ａｒｔｃａｍの処理能力の全てを提供する。ＡＣＰは、０．２５ミクロンＣＭＯＳプロセス用に設計され、約１５０万個のトランジスタと、約５０ｍｍ2の面積を有する。ＡＣＰ３１の設計は複雑であるが、設計の手間は、データパスコンパイレーション技術、マクロセル、及びＩＰコアを使用することによって軽減できる。ＡＣＰ３１は、
ＲＩＳＣ型ＣＰＵコア７２と、
４ウェイＶＬＩＷベクトルプロセッサ７４と、
ダイレクトＲＡＭｂｕｓ（ラムバス）インタフェース８１と、
ＣＭＯＳイメージセンサインタフェース８３と、
ＣＭＯＳリニアイメージセンサインタフェース８８と、
ＵＳＢシリアルインタフェース５２と、
赤外線キーボードインタフェース５５と、
数字ＬＣＤインタフェース８４と、
カラーＴＦＴ ＬＣＤインタフェース８８と、
プログラム記憶装置７０用４Ｍバイトフラッシュメモリ７０と、
を含む。ＲＩＳＣ型ＣＰＵ、ダイレクＲＡＭｂｕｓインタフェース８１、ＣＭＯＳセンサインタフェース８３、及びＵＳＢシリアルインタフェース５２は、ベンダーによって供給されるコアでもよい。ＡＣＰ３１は、電力消費を最小限に抑えるため、外部３Ｖ及び内部１．５Ｖに基づいて２００ＭＨｚのクロック速度で動作することが意図されている。ＣＰＵコアは１００ＭＨｚで動作すればよい。以下の二つのブロック図、即ち、
単独のＡＣＰ３１の説明図、及び
Ａｒｔｃａｍの残りのハードウェアに接続されたＡＣＰ３１の上位レベルの図を与える例示的なＡｒｔｃａｍ、
はＡＣＰ３１の２通りの見方を与える。
【０２０４】
画像アクセス
前述の通り、ＤＲＡＭインタフェース８１は、ＡＣＰチップの他のクライアント部と、ラムバスＤＲＡＭとの間を接続する役割を担う。実際上、ＤＲＡＭインタフェース内の各モジュールはアドレス生成器である。
【０２０５】
ＡＣＰによって操作される画像には三つの論理タイプがある。それらは、
−ＣＣＤから撮影された入力像であるＣＣＤ画像と、
−Ａｒｔｃａｍ装置によって内部的に利用される画像フォーマットである内部画像フォーマットと、
−Ａｒｔｃａｍによって印刷される出力画像フォーマットである印刷画像と、
である。
【０２０６】
これらの画像は、典型的に、色空間、解像度、並びに、カメラ間で変動のあり得る出力及び入力色空間の点で相違する。例えば、低価格カメラのＣＣＤ画像は、高価格カメラで使用されるものとは異なる解像度、又は異なる色特性を揺する。しかし、あらゆる内部画像フォーマットは、全てのカメラを通じて色空間の点で同一フォーマットである。
【０２０７】
その上、３種類の画像タイプは、どちらの方向が「上向き」であるかに関しても異なり得る。カメラの物理的な向きは、人物像であるか、又は風景像であるかについての観念を生じさせ、この観念は処理全体を通じて維持されるべきである。このため、内部画像は常に正しく向きを決められ、印刷動作中にＣＣＤから獲得された画像に対して回転が実行される。
【０２０８】
ＣＰＵコア（ＣＰＵ）７２
ＡＣＰ３１は、Ｖａｒｋ画像処理言語インタープリタを動作させ、Ａｒｔｃａｍの汎用オペレーティングシステムの役割を実行するため３２ビットＲＩＳＣ型ＣＰＵ７２を内蔵する。多種多様なＣＰＵコアが適当であり、要求されたコア計算及び制御機能を消費者の期待を満足する十分な速さで実行するために足りる処理能力を備えていればどのようなプロセッサコアでも構わない。適当なコアの例には、ＬＳＩロジック社のＭＩＰＳ 
Ｒ４０００、Ｓｔｒｏｎｇ ＡＲＭコアが含まれる。異なるＡｒｔｃａｍモデルの間で命令セットの継続性を維持する必要はない。Ａｒｔｃａｒｄの互換性は、将来のプロセッサの進歩及び変更とは無関係に維持される。なぜならば、Ｖａｒｋインタープリタは、新しい命令セット毎に再コンパイルをするだけで済むからである。したがって、ＡＣＰ３１のアーキテクチャは、自由に進化させることができる。種々の製造者は、ＣＰＵコアの使用許諾や移植をすることなく、様々なＡＣＰ３１チップ設計を製造することができる。この装置非依存性によって、ＰＣ市場においてインテル社が行っているようなチップベンダーのロックインが避けられる。ＣＰＵは１００ＭＨｚで動作し、単一サイクルタイムは１０ｎｓである。このＣＰＵは、ＶＬＩＷベクトルプロセッサ７４が時間的に重大な演算を担うとしても、Ｖａｒｋインタープリタを実行するために十分な高速性が必要である。
【０２０９】
プログラムキャッシュ７２
プログラムコードがオンチップフラッシュメモリ７０に保存されるとしても、ウェルパックされたフラッシュメモリ７０がＣＰＵによって要求される１０ｎｓのサイクルタイムで動作できる可能性は低い。したがって、優れた性能のために小規模のキャッシュが要求される。各々が３２バイトの１６個のキャッシュラインは、全部で５１２バイトになり、十分な大きさである。プログラムキャッシュ７２は、プログラムキャッシュ７２という名前の章に規定されている。
【０２１０】
データキャッシュ７６
小規模のデータキャッシュ７６が優れた性能のために要求される。この要求は、概して、ラムバスＤＲＡＭを使用しているために生じる。ラムバスＤＲＡＭは、高速データをバーストで提供することができるが、単一バイトのアクセスには不十分である。ＣＰＵは、ＣＰＵデータキャッシュ７６のサイズをフレキシブルに操作することを可能にさせるメモリキャッシングシステムにアクセスする。最小限で１６個のキャッシュライン（５１２バイト）が優れた性能のために推奨される。
【０２１１】
ＣＰＵメモリモデル
ＡｒｔｃａｍのＣＰＵメモリモデルは、３２ＭＢのエリアにより構成される。Ａｒｔｃａｍの基本モデルでは、ＣＰＵメモリモデルは、８ＭＢの物理的ＲＤＲＡＭオフチップにより構成され、最大で１６ＭＢのオフチップメモリが設けられる。ＡＣＰ３１にはプログラム記憶用に４ＭＢのフラッシュメモリ７０が存在し、最終的に、４ＭＢのアドレス空間がＡＣＰ３１の様々なレジスタ及びコントロールに割り当てられる。したがって、Ａｒｔｃａｍ用のメモリマップは以下の通りである。
【０２１２】
【表２】
0004309954.tif 000003
アドレスをデコードする簡単な方法は、アドレスビット２３−２４を使用することである。即ち、
ビット２４がクリアされている場合、アドレスは下位側１６ＭＢのレンジに含まれるので、ＤＲＡＭ及びデータキャッシュ７６から充たされる。殆どの場合に、ＤＲＡＭは８ＭＢに過ぎないが、より上位のメモリモデルＡｒｔｃａｍを考慮に入れるため１６ＭＢが割り当てられる。
ビット２４がセットされ、ビット２３がクリアされている場合、アドレスは、フラッシュメモリ７０の４Ｍバイトレンジを表現し、プログラムキャッシュ７２によって充たされる。
ビット２４＝１及びビット２３＝１である場合、アドレスは、ＣＰＵメモリデコーダ６８によって、低速バス経由によるＡＣ内の要求されたコンポーネントへのアクセスに変換される。
【０２１３】
フラッシュメモリ７０
ＡＣＰ３１は、Ａｒｔｃａｍプログラムを記憶する４Ｍバイトのフラッシュメモリ７０を含む。フラッシュメモリ７０はマスクＲＯＭよりも高い充填率を有し、カメラプログラムコードを試験するためより高いフレキシビリティを許容することが想定される。フラッシュメモリ７０の弱点はアクセス時間であり、このアクセス時間はＣＰＵの１００ＭＨｚの動作速度（１０ｎｓのサイクルタイム）に対して十分に高速であるとはいえない。したがって、高速プログラム命令キャッシュ７７が、ＣＰＵと低速のフラッシュメモリ７０との間のインタフェースとして作用する。
【０２１４】
プログラムキャッシュ７２
優れたＣＰＵ性能のために小型キャッシュが要求される。この要求は、プログラムコードを記憶するフラッシュメモリ７０が低速であることに起因する。各々が３２バイトの１６個のキャッシュラインは、全部で５１２バイトになり、十分な大きさである。プログラムキャッシュ７２は読み出し専用キャッシュである。ＣＰＵプログラムによって使用されるデータは、ＣＰＵメモリデコーダ６８を通過し、アドレスがＤＲＡＭ内にある場合、汎用データキャッシュ７６を通る。分離によって、ＣＰＵをＶＬＩＷベクトルプロセッサ７４とは独立して動作させることができる。所定のプロセスに対するデータ要求量が少ない場合、結果的に、そのプロセスは完全にキャッシュによって動作し得る。
【０２１５】
最後に、プログラムキャッシュ７２は、ＣＰＵによって純粋にプログラム命令としてではなく、データとして読み出すことが可能である。これにより、テーブル、即ち、ＶＬＩＷのためのマイクロコード等をフラッシュメモリ７０からロードすることが可能になる。ビット２４がセットされ、ビット２３がクリアされているアドレスは、プログラムキャッシュ７２から充足される。
【０２１６】
ＣＰＵメモリデコーダ６８
ＣＰＵメモリデコーダ６８は、ＣＰＵデータアクセスに沿う簡単なデコーダである。デコーダは、データアドレスを、内部低速バスによる内部ＡＣＰレジスタアクセスに変換し、これにより、ＡＣＰレジスタのメモリマップドＩ／Ｏを可能にさせる。ＣＰＵメモリデコーダ６８は、ビット２４がセットされ、ビット２３がクリアされているアドレスだけを解釈する。ＣＰＵメモリデコーダ６８内ではキャッシングは行われない。
【０２１７】
ＤＲＡＭインタフェース８１
Ａｒｔｃａｍによって使用されるＤＲＡＭは、１．６ＧＢ／秒で動作する単一チャンネルの６４Ｍビット（８Ｍバイト）ＲＡＭｂｕｓ（ラムバス）ＲＤＲＡＭである。ＲＤＲＡＭアクセスは、単一チャンネル（１６ビットデータパス）コントローラによる。ＲＤＲＡＭは、低電力動作用の数種の有効な動作モードを有する。ラムバス仕様書には、９５％以上の効率を達成可能であるようなランダムな３２バイト転送のあるシステムが記載されているが、これは、３２バイトのうちの一部しか使用されない場合には成り立たない。同一のデバイスに対する２回の読み出しに続いて２回の書き込みを行うことによって８６％以上の効率が得られる。基礎的なレイテンシーは、書き込みから読み出しへ変化するバスのターンアラウンドのために必要であり、遅延書き込み機構が存在するので、効率を更に改善することが可能である。書き込みに関して、書き込みマスクは、特定のバイトのサブセットへの書き込みを可能にさせる。これらの書き込みマスクは、内部キャッシュの「ダーティビット」によってセットされるであろう。ラムバスダイレクトＲＤＲＡＭは、要するに、１ＧＢ／秒を超えるスループットを簡単に達成可能であり、３２バイトの転送知識を十分に利用する知的アルゴリズムと組み合わされ（殆どのプロセスで）書き込み毎に複数回の読み出しを伴い、１．３ＧＢ／秒を超える転送レートが期待されるということである。１０ｎｓ毎に、コアとの間で１６バイトを転送することができる。
【０２１８】
ＤＲＡＭ構成
基本モデル（８ＭＢ ＲＤＲＡＭ）のＡｒｔｃａｍ用のＤＲＡＭ構成を次に示す。
【０２１９】
【表３】
0004309954.tif 000004
注：非圧縮形式の印刷画像は４．５ＭＢ（１チャンネル当たり１．５ＭＢ）を必要とする。他の対象を８ＭＢモデルに収容するため、印刷画像は圧縮されるべきである。クロミナンスチャンネルが４：１に圧縮された場合、各クロミナンスチャンネルは０．３７５ＭＢしか必要としない。
【０２２０】
ここで説明されるメモリモデルは、単一の８ＭＢのＲＤＲＡＭを想定している。Ａｒｔｃａｍのその他のモデルの中にはより多くのメモリを具備し、印刷画像を圧縮しなくてもよいものがある。その上、メモリ量が増加すると、最終画像の大部分を同時に操作できるようになり、速度が向上する可能性がある。
【０２２１】
Ａｒｔｃａｒｄの取り出し又は挿入は、印刷画像、拡大された写真画像の１チャンネル、及び画像ピラミッドを保持する５．５ＭＢエリアを無効にすることに注意すべきである。この空間は、Ａｒｔｃａｒｄデータを復号化するためＡｒｔｃａｒｄインタフェースによって安全に使用される。
【０２２２】
データキャッシュ７６
ＡＣＰ３１は、専用ＣＰＵ命令キャッシュ７７及び汎用データキャッシュ７６を含む。データキャッシュ７６は、ＣＰＵ、ＶＬＩＷベクトルプロセッサ７４及びディスプレイコントローラ８８からの全てのＤＲＡＭ要求（データの読み出し及び書き込み）を取り扱う。これらの要求は、メモリ使用量及びアルゴリズム的タイミング必要条件の点で非常に異なる側面を有する。例えば、ＶＬＩＷプロセスは、リニアメモリ内の画像を処理し、画像内の値毎にテーブルの値をルックアップする。画像の大半をキャッシュする必要な殆ど無いが、実際のメモリアクセスが必要ではないように、ルックアップテーブル全体をキャッシュすることが望ましい。このように必要条件が相違しているため、データキャッシュ７６は、キャッシングを知的に定義することが可能である。
【０２２３】
ラムバスＤＲＡＭインタフェース８１は、非常に高速のメモリアクセス能力を備えているが（平均スループットは２５ｎｓで３２バイト）、単一バイトの要求を処理するためには不十分である。実効的なメモリレイテンシーを低下させるため、ＡＣＰ３１は、１２８個のキャッシュラインを含む。各キャッシュラインは３２バイト幅である。このようにして、データキャッシュ７６の総容量は４０９６バイト（４ＫＢ）である。１２８個のキャッシュラインは、１６個のプログラム可能なサイズのグループに構成される。１６個のグループの各々は、連続したキャッシュラインのセットでなければならない。ＣＰＵは、各グループに割り付けるキャッシュラインの個数を決定する役割を担う。各グループ内で、キャッシュラインは、簡単なＬＲＵ（最低使用頻度）アルゴリズムに従って詰められる。ＣＰＵデータ要求に関して、データキャッシュ７６は、アドレスビット２４がクリアされたメモリアクセス要求を取り扱う。ビット２４がクリアされている場合、アドレスは下位側１６ＭＢのレンジに収まるので、ＤＲＡＭ及びデータキャッシュ７６から応じることができる。殆どの場合に、ＤＲＡＭは、８ＭＢしかないが、よりメモリ量の多いモデルのＡｒｔｃａｍを考慮に入れて１６ＭＢが割り付けられる。ビット２４がセットされている場合、アドレスはデータキャッシュ７６によって無視される。
【０２２４】
全てのＣＰＵデータ要求はキャッシュグループ０から応じられる。優れたＣＰＵ性能のためには１６個の最小のキャッシュラインが推奨されるが、ＣＰＵは、（０個以外の）任意の個数のキャッシュラインをキャッシュグループ０に割り当てることができる。残りのキャッシュグループ（１から１５）は、現在の必要条件に従って割り付けられる。これは、ＶＬＩＷベクトルプロセッサ７４プログラム又はディスプレイコントローラ８８への割付を意味することもある。例えば、常時利用可能であることが要求される２５６バイトのルックアップテーブルは、８個のキャッシュラインが必要であろう。順次画像を書き出すためには、（生成されたレコードのサイズと、書き込み要求が多数のサイクルに亘って書き込み遅延されているかどうかと、に応じて）２から４個のキャッシュラインだけが必要であろう。各キャッシュラインのバイトには、メモリをＤＲＡＭへ書き込む際に書き込みマスクを作成するため使用されるダーティビットが関連付けられる。各キャッシュラインには別のダーティビットが関連付けられ、このダーティビットは、キャッシュラインのバイトの何れかに書き込みがされたかどうか（したがって、ＤＲＡＭを再使用する前に、キャッシュラインをＤＲＡＭへ書き戻さなければならないかどうか）を示す。二つの異なるキャッシュグループがメモリの同じアドレスをアクセスし、同期が外れる可能性があることに注意する必要がある。ＶＬＩＷプログラムライターは、これが問題にならないことを保証する役割を担う。例えば、あるキャッシュグループには画像を読み出す役割を与え、別のキャッシュグループには変更された画像をメモリに書き戻す役割を与えることは完全に合理的である。画像が順番に読み出し又は書き込みされる場合、キャッシュラインをこのようにして割り付けることは有利である。全部で８本のバス１８２は、ＶＬＩＷベクトルプロセッサ７４をデータキャッシュ７６へ接続する。各バスは、Ｉ／Ｏアドレス生成器に接続される。（１個の処理ユニット１７８当たりに２個のＩ／Ｏアドレス生成器１８９及び１９０が存在し、ＶＬＩＷベクトルプロセッサ７４には４個の処理ユニットが存在する。したがって、バスの総数は８本である。） 
所与のサイクルにおいて、ＣＰＵのキャッシュグループ（グループ０）への単一の３２ビット（４バイト）アクセスの他に、残りのキャッシュグループへの１６ビット（２バイト）の四つ同時のアクセスが８本のＶＬＩＷプロセッサ７４のバス上で許容される。データキャッシュ７６は要求を公平に処理する役割がある。ある所与のサイクルで、特定のキャッシュグループへのたった一つの要求が処理される。ＶＬＩＷベクトルプロセッサ７４に８個のアドレス生成器１８９、１９０が存在する場合、アドレス生成器の各々は個別のキャッシュグループを参照する可能性がある。しかし、２個以上のアドレス生成器１８９、１９０が同じキャッシュグループにアクセスする可能性があり、場合によっては、その方が合理的である。ＣＰＵは、キャッシュグループに正確なキャッシュラインの個数が割り付けられることを保証し、ＶＬＩＷベクトルプロセッサ７４の様々なアドレス生成器１８９、１９０が特定のキャッシュグループを正確に参照することを保証する役割を担う。上述のようにデータキャッシュ７６は、ディスプレイコントローラ８８及びＶＬＩＷベクトルプロセッサ７４が同時に動作状態になることを許容する。これらの二つのコンポーネントの動作が決して同時に出現しないと考えられるならば、全部で９個のキャッシュグループがあれば足りる。ＣＰＵはキャッシュグループ０を使用し、ＶＬＩＷベクトルプロセッサ７４及びディスプレイコントローラ８８は残りの８個のキャッシュグループを共用し、（４ビットではなく）３ビットだけで特定の要求に応じるキャッシュグループを定めることができる。
【０２２５】
ＪＴＡＧインタフェース８５
標準的なＪＴＡＧ（ジョイントテスト部会）インタフェースはテスト目的用にＡＣＰ３１に収容される。チップの複雑さのため、ＢＩＳＴ（ビルトインセルフテスト）及び機能的ブロック分離等を含む様々なテスト技術が必要である。チップ面積の１０％のオーバーヘッドが全チップテスト回路のため想定される。テスト回路は本文書の範囲外の事項である。
【０２２６】
シリアルインタフェース
ＵＳＢシリアルポートインタフェース５２
これは標準的なＵＳＢシリアルポートであり、内部チップの低速バスに接続されるので、ＣＰＵがそれを制御することができる。
【０２２７】
キーボードインタフェース６５
これは標準的な低速シリアルポートであり、内部チップ低速バスに接続されるので、ＣＰＵがそれを制御することができる。キーボードインタフェースは、プリントをカスタマイズするための簡単なデータ入力を許容するためオプション的にキーボードへ接続できるように設計される。
【０２２８】
認証チップシリアルインタフェース６４
これらは、二つの標準的な低速シリアルポートであり、内部チップ低速バスに接続されるので、ＣＰＵがこれらを制御できる。二つのポートを具備する理由は、別個のラインを使用して、オンカメラ認証チップとプリントロール認証チップの両方に接続するためである。１個のラインしか使用しない場合、模造プリントロールの製造者は、認証コードを生成するのではなく、カメラの認証チップによって生成されたコードを使用するようにカメラを誤動作させるチップを設計することができる。
【０２２９】
パラレルインタフェース６７
パラレルインタフェースはＡＣＰ３１を個別の静的な電気信号に接続する。ＣＰＵは、低速バスを介して、メモリマップドＩ／Ｏとしてこれらの配線の各々を制御することができる。以下の表は、パラレルインタフェースへの配線の一覧である。
【０２３０】
【表４】
0004309954.tif 000005
ＶＬＩＷ入力及び出力ＦＩＦＯ７８、７９
ＶＬＩＷ入出力ＦＩＦＯは、プロセスとＶＬＩＷベクトルプロセッサ７４との間を接続するため使用される８ビット幅のＦＩＦＯである。両方のＦＩＦＯはＶＬＩＷベクトルプロセッサ７４によって制御されるが、ＣＰＵによってクリアしたり、（例えば、状態について）問い合わせをしたりすることができる。
【０２３１】
ＶＬＩＷ入力ＦＩＦＯ７８
クライアントは、ＶＬＩＷベクトルプロセッサ７４にデータを処理させるため、８ビットデータをＶＬＩＷ入力ＦＩＦＯ７８に書き込む。クライアントには、イメージセンサインタフェース、Ａｒｔｃａｒｄインタフェース、及びＣＰＵが含まれる。これらのプロセスの各々は、単にデータをＦＩＦＯに書き込み、ＶＬＩＷベクトルプロセッサ７４に重い仕事の全ての実行を任せることによって、処理から解放される。クライアントによるＶＬＩＷ入力ＦＩＦＯ７８の使用を用いる一例は、イメージセンサインタフェース（ＩＳＩ８３）である。イメージセンサインタフェース８３は、イメージセンサからデータを取得し、そのデータをＦＩＦＯに書き込む。ＶＬＩＷプロセスは、ＦＩＦＯからデータを取得し、データを正しい画像データフォーマットへ変換し、それをＤＲＡＭへ書き出す。イメージセンサインタフェース８３は、その結果として、非常に簡単化される。
【０２３２】
ＶＬＩＷ出力ＦＩＦＯ７９
ＶＬＩＷベクトルプロセッサ７４は、８ビットデータをＶＬＩＷ出力ＦＩＦＯ７９に書き込み、クライアントはＶＬＩＷ出力ＦＩＦＯでデータを読み出すことができる。クライアントには、プリントヘッドインタフェース及びＣＰＵが含まれる。これらのクライアントの両方は、単にＦＩＦＯから処理済みのデータを読み出し、ＶＬＩＷベクトルプロセッサ７４に重い仕事の全ての実行を任せることにより、処理から解放される。ＣＰＵは、データがＶＬＩＷ出力ＦＩＦＯ７９に収容されたときはいつでも中断させることができ、ＦＩＦＯを絶えずポーリングするのではなく、データが利用可能になったときに限りそのデータを処理できるようになる。クライアントによるＶＬＩＷ出力ＦＩＦＯ７９の使用を用いる一例は、プリントヘッドインタフェース（ＰＨＩ６２）である。ＶＬＩＷプロセスは、画像を取得し、画像を正しい向きへ回転し、色変換を行い、プリントヘッド必要条件に応じて得られた画像をディザリングする。プリントヘッドインタフェース６２は、ＶＬＩＷ出力ＦＩＦＯ７９からディザリングされたフォーマット後の８ビットデータを読み出し、その８ビットデータをＡＣＰ３１の外部にあるプリントヘッドに渡すだけでよい。プリントヘッドインタフェース６２はその結果として非常に簡単化される。
【０２３３】
ＶＬＩＷベクトルプロセッサ７４
Ａｒｔｃａｍの高い処理要求を実現するため、ＡＣＰ３１は、ＶＬＩＷ（超長命令語）ベクトルプロセッサを含む。ＶＬＩＷプロセッサは、クロスバースイッチ１８３によって接続され並列に動作する４個の同一処理ユニット（例えば、ＰＵ１７８）の組である。各処理ユニット、例えば、ＰＵ１７８は、各サイクルに、４回の８ビット乗算、８回の８ビット加算、３回の３２ビット加算、Ｉ／Ｏ処理、及び様々な論理演算を実行することができる。処理ユニット、例えば、ＰＵ１７８はマイクロコード化され、各々は、２個のアドレス生成器１８９、１９０を具備し、データ処理のため利用可能なサイクルを完全に使用できる。４個の処理ユニット、例えば、ＰＵ１７８は、通常、密接に相互作用するＶＬＩＷプロセッサを実現するため同期させられる。２００ＭＨｚのクロックにより、ＶＬＩＷベクトルプロセッサ７４は、１２Ｇｏｐ（毎秒１２０億回の演算速度）で動作する。命令は、ワーピング、芸術的なブラッシング、複雑な合成照明、色変換、画像フィルタリング、及び合成のような画像処理機能のために調整される。これらは、デスクトップコンピュータよりも２桁加速されている。
【０２３４】
図３（ａ）に詳細に示されるように、ＶＬＩＷベクトルプロセッサ７４は、クロスバースイッチ１８３によって接続された４個の処理ユニット、例えば、ＰＵ１７８であり、各処理ユニット、例えば、ＰＵ１７８は、クロスバースイッチ１８３へ２入力を供給し、クロスバースイッチ１８３からの２出力を取得する。２個の共通レジスタは、処理ユニット、例えば、ＰＵ１７８のための制御及び同期機構を形成する。８本のキャッシュバス１８２は、データキャッシュ７６を介してＤＲＡＭへの接続を可能にさせ、２本のバスは各処理ユニット、例えば、ＰＵ１７８へ至る（Ｉ／Ｏアドレス生成器毎に１本のバス）。各処理ユニット、例えば、ＰＵ１７８は、（データを処理するための多数のレジスタ及びある種の算術論理を格納する）ＡＬＵ（算術論理ユニット）１８８と、ある種のマイクロコードＲＡＭ１９６と、外界（他のＡＬＵを含む）への配線と、を具備する。ローカルＰＵ状態機械は、マイクロコードで動き、この手段によって処理ユニット、例えば、ＰＵ１７８が制御される。各処理ユニット、例えば、ＰＵ１７８は、ＤＲＡＭ（データキャッシュ７６経由）とＡＬＵ１８８（入力ＦＩＦＯ及び出力ＦＩＦＯ経由）の間のデータフローを制御する二つのＩ／Ｏアドレス生成器１８９、１９０を含む。アドレス生成器は、データ（特に、様々なフォーマットの画像）、並びに、ＤＲＡＭ内のテーブル及びシミュレーティッドＦＩＦＯを読み書きすることが可能である。フォーマットはソフトウェア制御の下でカスタマイズ可能であるが、マイクロコード化されない。データキャッシュ７６から取得されたデータは、１６ビット幅の入力ＦＩＦＯを介してＡＬＵ１８８へ転送される。出力データは、１６ビット幅の出力ＦＩＦＯに書き込まれ、そこからデータキャッシュ７６へ書き込まれる。最後に、全ての処理ユニット、例えば、ＰＵ１７８は、単一の８ビット幅ＶＬＩＷ入力ＦＩＦＯ７８と、単一の８ビット幅ＶＬＩＷ出力ＦＩＦＯ７９を共用する。低速データバス接続によって、ＣＰＵは、処理ユニット、例えば、ＰＵ１７８のレジスタを読み書きし、マイクロコードを更新し、ＶＬＩＷベクトルプロセッサ７４の全ての処理ユニット、例えば、ＰＵ１７８によって共用される共通レジスタを読み書きすることが可能になる。次に、図４を参照すると、単独の処理ユニット、例えば、ＰＵ１７８の内部のより詳細が示され、以下では、コンポーネント及び制御信号を詳述する。
【０２３５】
マイクロコード
各処理ユニット、例えば、ＰＵ１７８は、その特定の処理ユニット、例えば、ＰＵ１７８用のプログラムを保持するマイクロコードＲＡＭ１９６を含む。マイクロコードをＲＯＭに収容するのではなく、マイクロコードはＲＡＭに収容され、ＣＰＵはマイクロコードをアップロードする役割を担う。チップ上の同じ空間であるため、このトレードオフは、ある一つの機能の最大サイズをＲＡＭ１９６のサイズまで縮小するが、マイクロコードに書き込まれる機能の数は無制限である。マイクロコードを用いて実現された機能は、Ｖａｒｋアクセラレーション、Ａｒｔｃａｒｄ読み取り、及び印刷を含む。ＶＬＩＷベクトルプロセッサ７４の方式は、ＡＣＰ３１のケースでは、以下の幾つかの利点がある：
ハードウェア設計の複雑さが低減される；
ハードウェアのリスクは複雑さの低減によって低減する；
ハードウェア設計時間は、専用シリコンに組み込まれる全てのＶａｒｋ機能に依存しない；
チップ上の空間が全体的に縮小される（多数のプロセスをマイクロコードとして組み込むことができるため）；
ハードウェア設計時間に影響を与えることなく、（マイクロコードによって）Ｖａｒｋに機能を加えることができる。
【０２３６】
サイズ及び内容
各処理ユニット、例えば、ＰＵ１７８を制御するＣＰＵによってロードされたマイクロコードＲＡＭ１９６は１２８ワードであり、各ワードは９６ビット幅である。処理ユニット、例えば、ＰＵ１７８の様々なユニットを制御するためのマイクロコードサイズの概要は以下の表に掲載されている。
【０２３７】
【表５】
0004309954.tif 000006
１２８個の命令ワードによって、処理ユニット、例えば、ＰＵ１７８毎の全マイクロコードＲＡＭ１９６は、１２２８８ビット、即ち、正確に１．５ＫＢである。ＶＬＩＷベクトルプロセッサ７４は、４個の同一の処理ユニット、例えば、ＰＵ１７８により構成されるので、これは、６１４４バイト、即ち、正確に６ＫＢと一致する。マイクロコードワード内の一部のビットは、制御ビットとしてそのまま使用され、一方、他のビットはデコードされる。マイクロコードワードのビットの各々の解釈を詳細に記述する種々のユニット説明を参照せよ。
【０２３８】
処理ユニット、例えば、ＰＵ１７８の間の同期
各処理ユニット、例えば、ＰＵ１７８は、４ビット同期レジスタ１９７を含む。それは、一体的に動作する処理ユニット、例えば、ＰＵ１７８を決定するため使用されるマスクであり、単一プロセスとして機能する対応した処理ユニット、例えば、ＰＵ１７８の各々に対して１ビットがセットされる。例えば、全ての処理ユニット、例えば、ＰＵ１７８が単一プロセスとして機能する場合、４個の同期レジスタ１９７の各々は、全て４ビットがセットされるであろう。２個の処理ユニット、例えば、ＰＵ１７８毎に二つの同期プロセスが存在するならば、２個の処理ユニット、例えば、ＰＵ１７８は、（そのＰＵ自体に対応した）同期レジスタ内の２ビットがセットされ、他の２個の処理ユニットは、（そのＰＵ自体に対応した）同期レジスタ内の別の２ビットがセットされる：
同期レジスタ１９７は、以下の二つの基本的な方式で使用される；
同期した所定のプロセスを停止及び開始する；
プロセス内で実行を一時停止する。
【０２３９】
停止及び開始プロセス
ＣＰＵは、マイクロコードＲＡＭ１９６にロードし、第１の命令の実行アドレス（通常は０）をロードする役割を担う。ＣＰＵがマイクロコードを実行し始めるとき、マイクロコードは指定されたアドレスから始まる。
【０２４０】
マイクロコードが実行されるのは、同期レジスタ１９７の全てのビットが共通同期レジスタ１９７にもセットされたときに限られる。したがって、ＣＰＵは、全ての処理ユニット、例えば、ＰＵ１７８をセットアップし、次に、共通同期レジスタ１９７への１回の書き込みでプロセスを開始又は停止する。
【０２４１】
この同期方式は、複数のプロセスが処理ユニット、例えば、ＰＵ１７８上で非同期的に実行されることを可能にさせ、同時に１個の処理ユニット、例えば、ＰＵ１７８としてではなく、プロセスとして停止及び開始される、
プロセス内の実行の一時停止
所与のサイクルにおいて、処理ユニット、例えば、ＰＵ１７８は、（現在のマイクロコード命令のオペレーションコードに基づいて）ＦＩＦＯからの読み出し、又はＦＩＦＯへの書き込みのために必要である。ＦＩＦＯが読み出し要求時にエンプティであるか、又は書き込み要求時にフルである場合、ＦＩＦＯ要求は完了し得ない。処理ユニット、例えば、ＰＵ１７８は、したがって、プロセス一時停止制御信号１９８をアサートする。全ての処理ユニット、例えば、ＰＵ１７８からのプロセス一時停止信号は、全ての処理ユニット、例えば、ＰＵ１７８へフィードバックされる。同期レジスタ１９７は、４個のプロセス一時停止ビットと論理積演算され、結果が非零であるならば、処理ユニット、例えば、ＰＵ１７８のレジスタのライトイネーブル、又はＦＩＦＯストローブはセットされない。したがって、そのタスクを終了できなかった処理ユニット、例えば、ＰＵ１７８と同じプロセスグループを形成する処理ユニット、例えば、ＰＵ１７８の中に、自分のレジスタ又はＦＩＦＯがそのサイクル中に更新された処理ユニットは存在しない。この簡単な技術は、所定のプロセスグループを同期状態に保つ。後の各サイクルで、処理ユニット、例えば、ＰＵ１７８の状態機械は、同じアドレスのこのマイクロコード命令を再実行することを試み、成功するまでそのようにし続ける。勿論、共通同期レジスタ１９７は、必要に応じてプロセス全体を停止させるため、ＣＰＵによって書き込むことができる。この同期方式は、任意の処理ユニット、例えば、ＰＵ１７８の組み合わせが一体となって動作することを可能にさせ、各グループは、データを読み書きする準備ができていないことを原因とする一時停止に関しては、協働して動作する処理ユニットだけに影響を与える。
【０２４２】
制御及び分岐
各サイクル中、処理ユニット、例えば、ＰＵ１７８のＡＬＵ１８８内の４個の基本入力及び計算ユニットの各々（読み出し、アダー／ロジック、乗算／補間、及びバレルシフタ）は、そのサイクル中の演算結果が０であるか又は負であるかを示す零フラグ及び負フラグの二つの状態ビットを生成する。各サイクルに、これらの４個の状態ビットのうちの一つが、処理ユニット、例えば、ＰＵ１７８から出力されるマイクロコード命令によって選択される。４個の状態ビット（一つの処理ユニット、例えば、ＰＵ１７８のＡＬＵ１８８について１個）が４ビット共通状態レジスタ２００に組み合わされる。次のサイクル中に、各処理ユニット、例えば、ＰＵ１７８のマイクロコードプログラムは、共通状態レジスタ２００からのビットのうちの１ビットを選択し、状態ビットの値に依存して別のマイクロコードアドレスへ分岐することが可能である。
【０２４３】
状態ビット
各処理ユニット、例えば、ＰＵ１７８のＡＬＵ１８８は、多数の入力及び計算ユニットを含む。各ユニットは、負フラグと零フラグの二つの状態ビットを生成する。これらの状態ビットのうちの一つは、特別なユニットが１ビット３状態の状態ビットバス上の値をアサートするときに、処理ユニット、例えば、ＰＵ１７８から出力される。一つの状態ビットが処理ユニット、例えば、ＰＵ１７８から出力され、次に、共通状態レジスタ２００を更新するため、他の処理ユニット、例えば、ＰＵ１７８の状態ビットと組み合わされる。出力状態ビットを決定するマイクロコードは以下の形式をとる。
【０２４４】
【表６】
0004309954.tif 000007
ＡＬＵ１８８内で、２ビット選択プロセッサブロック値は、４個の１ビットイネーブルビットにデコードされ、異なるイネーブルビットが各プロセッサユニットブロックへ送信される。状態選択ビット（零又は負を選択する）は、状態ビットバスへ出力されるべきビットを決定するため全てのユニットへ渡される。
【０２４５】
マイクロコード内の分岐
各処理ユニット、例えば、ＰＵ１７８は、実行中の現在のマイクロコードアドレスを保持する７ビットプログラムカウンタ（ＰＣ）を含む。普通のプログラム実行はリニアであり、即ち、あるサイクルのアドレスＮから次のサイクルのアドレスＮ＋１へ進む。しかし、サイクル毎に、マイクロコードプログラムは、異なる場所へ分岐する能力、又は共通状態レジスタ２００からの状態ビットをテストして分岐する能力を備えている。次の実行アドレスを決定するマイクロコードは以下の形式をとる。
【０２４６】
【表７】
0004309954.tif 000008
ＡＬＵ１８８
図５はＡＬＵ１８８を詳細に示す図である。ＡＬＵ１８８内部には、多数の専用処理ブロックが存在し、マイクロコードプログラムによって制御される。専用処理ブロックには、
入力ＦＩＦＯからのデータを受け取る読み出しブロック２０２と、
出力ＦＩＦＯを介してデータを送り出す書き込みブロック２０３と、
加算及び減算と、比較及び論理演算のためのアダー／ロジックブロック２０４と、
乗算タイプの補間及び乗算／累算のための乗算／補間ブロック２０５と、
要求に応じてデータをシフトするバレルシフトブロック２０６と、
外部クロスバースイッチ１８３からのデータを受け取る入力ブロック２０７と、
外部クロスバースイッチ１８３へデータを送り出す出力ブロック２０８と、
一次記憶装置にデータを保持するレジスタブロック２１５と、
が含まれる。
【０２４７】
４個の専用３２ビットレジスタは、４個の主要な処理ブロックの結果を保持する：
Ｍレジスタ２０９は、乗算／補間ブロックの結果を保持する；
Ｌレジスタ２０９は、アダー／ロジックブロックの結果を保持する；
Ｓレジスタ２０９は、バレルシフタブロックの結果を保持する；
Ｒレジスタ２０９は、読み出しブロック２０２の結果を保持する。
【０２４８】
更に、データ転送用の二つの内部クロスバースイッチ２１３及び２１４が存在する。多様な処理ブロックは、各ブロックに属するマイクロコード定義と共に後続のセクションで更に展開される。尚、マイクロコードは、内部の様々なユニットへ制御信号を供給するためブロック内でデコードされる。
【０２４９】
処理ユニット、例えば、ＰＵ１７８間のデータ転送
各処理ユニット、例えば、ＰＵ１７８は、外部クロスバーを介してデータを交換することができる。処理ユニット、例えば、ＰＵ１７８は、二つの入力を取得し、２個の値を外部クロスバーへ出力する。このようにして、処理用の２個のオペランドが単一サイクルで獲得できるが、実際には、次のサイクルまで演算に使用されない。
【０２５０】
入力２０７
このブロックは図６に示され、外部クロスバーからのデータを受け取る２個のレジスタＩｎ1及びＩｎ2を含む。レジスタはサイクル毎にロードすることが可能であり、又はそのままの状態を保つことが可能である。８入力から選択するための選択ビットは、外部クロスバースイッチ１８３へ出力される。マイクロコードは以下の形式をとる。
【０２５１】
【表８】
0004309954.tif 000009
出力２０８
入力は出力２０８によって補完される。出力ブロックは図７に詳細に示されている。出力は、Ｏｕｔ1及びＯｕｔ2の２個のレジスタを含み、両方のレジスタは、他の処理ユニット、例えば、ＰＵ１７８によって使用するためサイクル毎に外部クロスバーへ出力される。また、書き込みユニットは、Ｏｕｔ1とＯｕｔ2のうちの一方を、ＡＬＵ１８８に取り付けられた出力ＦＩＦＯの一つに書き込むことが可能である。最終的に、両方のレジスタは、第１クロスバー２１３への入力として利用可能であり、第１クロスバー２１３は、そのレジスタ値がＡＬＵ１８８内の他のユニットへの入力として利用できるようにする。各サイクルで、２個のレジスタのうち何れか一方は、マイクロコード選択に応じて更新することができる。指定されたレジスタにロードされたデータは、（第１クロスバー２１３から選択された）Ｄ0−Ｄ3のうちの一つ、（第２クロスバー２１４から選択された）Ｍ、Ｌ、Ｓ及びＲのうちの一つ、２個のプログラマブル定数のうちの一つ、又は固定値０若しくは１である。出力用のマイクロコードは以下の形式をとる。
【０２５２】
【表９】
0004309954.tif 000010
ＡＬＵ１８８内のローカルレジスタ及びデータ転送
前述の通り、ＡＬＵ１８８は、以下の４個のブロックの結果を保持するため、４個の専用３２ビットレジスタを含む：
Ｍレジスタ２０９は乗算／補間ブロックの結果を保持する；
Ｌレジスタ２０９はアダー／ロジックブロックの結果を保持する；
Ｓレジスタ２０９はバレルシフタブロックの結果を保持する；
Ｒレジスタ２０９は読み出しブロック２０２の結果を保持する。
【０２５３】
ＣＰＵはこれらのレジスタに直接アクセスを行い、他のユニットは、第２クロスバー２１４経由の入力としてそれらを選択することができる。場合によっては、演算を１サイクル以上遅延させる必要がある。レジスタブロックは、４個の３２ビットレジスタＤ0−Ｄ3を含み、処理中の一時変数を保持する。各サイクルに、レジスタのうちの一つを更新可能であり、一方、全てのレジスタは、他のユニットが（同様に、Ｉｎ１、Ｉｎ2、Ｏｕｔ1及びＯｕｔ2を含む）第１クロスバー２１３を介して使用するために出力される。ＣＰＵはこれらのレジスタへ直接アクセスを行う。指定されたレジスタにロードされたデータは、（第１クロスバー２１３から選択された）Ｄ0−Ｄ3のうちの一つ、（第２クロスバー２１４から選択された）Ｍ、Ｌ、Ｓ及びＲのうちの一つ、２個のプログラマブル定数のうちの一つ、又は固定値０若しくは１である。レジスタブロック２１５は図８に詳細に示されている。レジスタ用のマイクロコードは以下の形式をとる。
【０２５４】
【表１０】
0004309954.tif 000011
第１クロスバー２１３
第１クロスバー２１３は図９に詳細に示されている。第１クロスバー２１３は、入力Ｉｎ１、Ｉｎ2、Ｏｕｔ1、Ｏｕｔ2、Ｄ0−Ｄ3から選択するため使用される。７個の出力が第１クロスバー２１３から発生され、３個が乗算／補間ユニットへ、２個がアダーユニットへ、１個がレジスタユニットへ、１個が出力ユニットへ向けられる。第１クロスバー２１３用の制御信号は、クロスバー入力を使用する様々なユニットから到来する。第１クロスバー２１３のため分離された特定のマイクロコードは存在しない。
【０２５５】
第２クロスバー２１４
第２クロスバー２１４は図１０に詳細に示されている。第２クロスバー２１４は、汎用ＡＬＵ１８８レジスタＭ、Ｌ、Ｓ及びＲから選択するため使用される。６個の出力が第１クロスバー２１３から発生され、２個が乗算／補間ユニットへ、２個がアダーユニットへ、１個がレジスタユニットへ、１個が出力ユニットへ向けられる。第２クロスバー２１４用の制御信号は、クロスバー入力を使用する様々なユニットから到来する。第２クロスバー２１４のため分離された特定のマイクロコードは存在しない。
【０２５６】
処理ユニット、例えば、ＰＵ１７８とＤＲＡＭ又は外部プロセスとの間のデータ転送
図４を参照すると、処理ユニット、例えば、ＰＵ１７８は、外部クロスバーを介して、直接的に相互にデータを共有する。また、処理ユニットは、外部プロセス並びにＤＲＡＭとの間でデータを転送する。各処理ユニット、例えば、ＰＵ１７８は、２個のＩ／Ｏアドレス生成器１８９及び１９０を含み、ＤＲＡＭとの間でデータを転送する。処理ユニット、例えば、ＰＵ１７８は、Ｉ／Ｏアドレス生成器の出力ＦＩＦＯ、例えば、１８６を介してＤＲＡＭへデータを送出し、又はＩ／Ｏアドレス生成器の入力ＦＩＦＯ１８７を介して、ＤＲＡＭからデータを受け取る。これらのＦＩＦＯは、処理ユニット、例えば、ＰＵ１７８に局在する。また、外部プロセスとの間で、全てのＡＬＵによって共有される共通ＶＬＩＷ入力ＦＩＦＯ７８及び共通ＶＬＩＷ出力ＦＩＦＯ７９の形でデータを送受する機構が存在する。ＶＬＩＷ入力及び出力ＦＩＦＯは、８ビット幅しかなく、印刷、Ａｒｔｃａｒｄ読み出し、ＣＰＵ等へのデータ転送に使用される。ローカル入力及び出力ＦＩＦＯは１６ビット幅である。
【０２５７】
読み出し
図５の読み出しプロセスブロック２０２は、ＡＬＵ１８８のＲレジスタ２０９を更新する役割を担い、Ｒレジスタは、ＶＬＩＷマイクロコード化プロセスへの外部入力データを表現する。サイクル毎に、読み出しユニットは、共通ＶＬＩＷ入力ＦＩＦＯ７８（８ビット）、又は２個のローカル入力ＦＩＦＯ（１６ビット）のうちの何れかから読み出すことが可能である。３２ビット値が生成され、そのデータの全部又は一部がＲレジスタ２０９へ転送される。プロセスは図１１に示されている。読み出し用のマイクロコードは以下の表に掲載されている。一部のビットパターンの解釈はデコーディングを補助するため意図的に選択される。
【０２５８】
【表１１】
0004309954.tif 000012
書き込み
書き込みプロセスブロックは、各サイクルに、共通ＶＬＩＷ出力ＦＩＦＯ７９、又は２個のローカル出力ＦＩＦＯの一方の何れかへの書き込みを行うことができる。所与のサイクル中に書き込まれるＦＩＦＯは１個しかないので、１個の１６ビット値が全てのＦＩＦＯへ出力され、下位８ビットがＶＬＩＷ出力ＦＩＦＯ７９へ達することに注意する必要がある。マイクロコードは、どのＦＩＦＯがその値を受け付けるかを制御する。データ選択のプロセスは図１２により詳細に示されている。ソース値Ｏｕｔ1及びＯｕｔ2は出力ブロックから到来する。それらは、単に２個のレジスタである。書き込み用のマイクロコードは以下の形式をとる。
【０２５９】
【表１２】
0004309954.tif 000013
計算ブロック
各ＡＬＵ１８８は、２個の計算プロセスブロック、即ち、アダー／ロジックプロセスブロック２０４と、乗算／補間プロセスブロック２０５と、を含む。更に、これらの計算ブロックを補助するためバレルシフタブロックが設けられる。レジスタブロック２１５からのレジスタは、パイプライン演算中に一時記憶装置として使用することも可能である。
【０２６０】
バレルシフタ
バレルシフタプロセスブロック２０６は図１３に詳細に示され、その入力は、アダー／ロジック、若しくは、乗算／補間プロセスブロックの出力、又はそれらのブロック（ＡＬＵレジスタＬ及びＭ）の前のサイクルの結果から得られる。選択された３２ビットは、（必要に応じて符号を拡張して）何れかの向きに任意のビット数だけバレルシフトされ、ＡＬＵ１８８のＳレジスタ２０９へ出力される。バレルシフトプロセスブロック用のマイクロコードは以下の表に記載されている。一部のビットパターンの解釈はデコーディングを助けるため意図的に選択されることに注意する必要がある。
【０２６１】
【表１３】
0004309954.tif 000014
アダー／ロジック２０４
アダー／ロジックプロセスブロックは、図１４により詳細に示され、簡単な３２ビット加算／減算、比較、及び論理演算用に設計されている。単一サイクルで、１回の加算、比較、又は論理演算を実行することができ、その結果はＡＬＵ１８８のＬレジスタ２０９に保存される。二つの主オペランドＡ及びＢが存在し、これらは、二つのクロスバーの何れか、又は４個の定数レジスタから選択される。一方のクロスバーの選択によって、前のサイクルの算術演算の結果を使用することが可能になり、もう一方は、このＡＬＵ又は他のＡＬＵ１８８によって前に計算されたオペランドへアクセスする。ＣＰＵは、４個の定数（Ｋ1−Ｋ4）にアクセスする唯一のユニットである。例えば、（Ａ＋Ｂ）×４のような演算が要求される場合、アダーからの直接出力は、バレルシフタへの入力として使用可能であり、先にＬレジスタ２０９にラッチしなくても２個分だけ左シフトさせることができる。アダーからの出力は、乗算−累算演算のため乗算ユニットで利用することができる。アダー／ロジックプロセスブロック用のマイクロコードは以下の表に掲載されている。一部のビットパターンの解釈はデコーディングを補助するため意図的に選択される。
アダー／ロジックユニット用のマイクロコードビット解釈
【０２６２】
【表１４】
0004309954.tif 000015
乗算／補間２０５
乗算／補間プロセスブロックは、図１５に詳細に示され、４個の８×８形補間ユニットのセットであり、４個の８×８形補間ユニットは、１サイクル毎に４回の別個の８×８形補間を実行する能力を備えているか、又は１回の１６×１６形乗算を実行するため組み合わせることができる。これは、単一サイクル中に最大で４回のリニア補間、１回のバイリニア補間、又はトライリニア補間の半分を実行可能であることを示す。補間又は乗算の結果はＡＬＵ１８８のＭレジスタ２０９に保存される。二つの主オペランドＡ及びＢは、ＡＬＵ１８８の汎用レジスタの何れかから選択されるか、又は乗算／補間プロセスブロックの内部にある４個のプログラマブル定数から選択される。各補間ブロックは、簡単な８ビット補間器［結果＝Ａ＋（Ｂ−Ａ）ｆ］として機能するか、又は簡単な８×８形乗算［結果＝Ａ＊Ｂ］として機能する。演算が補間である場合、Ａ及びＢは、４個の８ビット数値Ａ0からＡ3（Ａ0は下位バイトである）、及びＢ0からＢ3として取り扱われる。ＡＧＥＮ、ＢＧＥＮ及びＦＧＥＮは、実行される演算に適合するように補間ユニットへの入力を並べる役目を果たす。例えば、バイリニア補間を実行するため、４個の値の各々は、異なる係数によって乗算され、その結果が加算され、一方、１６×１６形の乗算は、係数を０にする必要がある。アダー／ロジックプロセスブロック用のマイクロコードは、以下の表に掲載されている。尚、一部のビットパターンの解釈はデコーディングを補助するため意図的に選択される。
【０２６３】
【表１５】
0004309954.tif 000016
同じ４ビットがＶ及びｆの選択のために使用されるが、Ｖの直前の４個の選択肢は、一般的にｆ値として意味をなさない。１又は０の係数を用いる補間は無意味であり、前の乗算若しくは現在の結果がｆに対する有意な値である可能性は少ない。
【０２６４】
Ｉ／Ｏアドレス生成器１８９と１９０
Ｉ／Ｏアドレス生成器は図１６に詳細に示されている。ＶＬＩＷプロセスはＤＲＡＭに直接アクセスしない。アクセスは２個のＩ／Ｏアドレス生成器１８９、１９０を介して行われ、各々のＩ／Ｏアドレス生成器は固有の入力ＦＩＦＯ及び出力ＦＩＦＯを含む。処理ユニット、例えば、ＰＵ１７８は、２個のローカル入力ＦＩＦＯの一方からデータを読み出し、２個のローカル出力ＦＩＦＯの一方にデータを書き込む。各Ｉ／Ｏアドレス生成器は、ＤＲＡＭからデータを読み出し、そのデータを入力ＦＩＦＯに入れる責任があり、その入力ＦＩＦＯにおいて、データは処理ユニット、例えば、ＰＵ１７８によって読み出すことができる。各Ｉ／Ｏアドレス生成器は、その出力ＦＩＦＯから（処理ユニット、たとえば、ＰＵ１７８によって入れられた）データを取り出し、それをＤＲＡＭに書き込む役割を担う。Ｉ／Ｏアドレス生成器は、データキャッシュ７６を介してＤＲＡＭのデータを取得及び記憶するためのアドレスを生成し制御を行う状態機械である。それは、ＣＰＵソフトウェア制御の下でカスタマイズ可能であるが、マイクロコード化できない。アドレス生成器は、
多種多様な方式で画像の画素の最初から最後までを繰り返すため（読み、書き、もしくはその両方）使用される画像イタレータと、
画像の画素、テーブルのデータをランダムにアクセスし、ＤＲＡＭのＦＩＦＯをシミュレートするため使用されるテーブルＩ／Ｏと、
の二つに大別されるアドレスを生成する。
【０２６５】
Ｉ／Ｏアドレス生成器１８９と１９０の各々は、データキャッシュ７６への固有のバス配線を具備し、１個の処理ユニット、例えば、ＰＵ１７８について２本のバス配線があり、ＶＬＩＷベクトルプロセッサ７４全体で合計８本のバスがある。データキャッシュ７６は、サイクル毎に、４個の処理ユニット、例えば、ＰＵ１７８からの最大で８個の要求のうちの４個のために作用することが可能である。入力ＦＩＦＯ及び出力ＦＩＦＯは、深さが８エントリーで、幅が１６ビットのＦＩＦＯである。多種多様のアドレス生成（画像イタレータ及びテーブルＩ／Ｏ）が後のセクションで説明される。
【０２６６】
レジスタ
Ｉ／Ｏアドレス生成器は、アドレス生成を制御するため使用されるレジスタの組を有する。また、アドレッシングモードは、データがどのようにフォーマットされ、ローカル入力ＦＩＦＯへ送られるか、並びに、データが出力ＦＩＦＯからどのように解釈されるかを決定する。ＣＰＵは、低速バスを介して、Ｉ／Ｏアドレス生成器のレジスタにアクセス可能である。第１のレジスタの組は、Ｉ／Ｏ生成器のためのハウスキーピングパラメータを定義する。
【０２６７】
【表１６】
0004309954.tif 000017
状態レジスタは以下の値をとる。
【０２６８】
【表１７】
0004309954.tif 000018
キャッシュ処理
複数のレジスタがキャッシュ処理機構を制御するため使用され、入力、出力等に使用するキャッシュグループを指定する。キャッシュグループのより詳細な情報についてはデータキャッシュ７６に関するセクションを参照のこと。
【０２６９】
【表１８】
0004309954.tif 000019
画像イタレータ＝順次自動画素アクセス
ソフトウェア及びハードウェアアルゴリズム用の主な画像絵素アクセス方法は画像イタレータによる。画像イタレータは、画像チャンネル内の画素のキャッシュのアドレッシング及びアクセスの全てを実行し、それらのクライアントのため画素を読み出し、書き込み、或いは、読み書きする。読み出しイタレータは、そのクライアントのための特定の順序で画素を読み出し、書き込みイタレータはそのクライアントのための特定の順序で画素を書き込む。イタレータのクライアントは、ローカル入力ＦＩＦＯから画素を読み出し、又はローカル出力ＦＩＦＯを介して画素を書き込む。
【０２７０】
読み出し画像イタレータは、特定の順序で画像の中を読み、画素データをローカル入力ＦＩＦＯに入れる。クライアントが入力ＦＩＦＯから画素を読み出す毎に、読み出しイタレータは（データキャッシュ７６経由で）画像からの次の画素をＦＩＦＯに入れる。
【０２７１】
書き込み画像イタレータは、画像全体を書き出すため、特定の順序で画素を書き込む。クライアントは画素を出力バッファに書き込み、この出力バッファが次に書き込み画像イタレータによって読み出され、データキャッシュ７６を介してＤＲＡＭに書き込まれる。
【０２７２】
典型的に、ＶＬＩＷプロセッサは、読み出しイタレータに結合された入力と、対応した書き込みイタレータに結合された出力と、を有する。処理ユニット、例えば、ＰＵ１７８のマイクロプログラムの観点では、ＦＩＦＯは、ＤＲＡＭへの効率的なインタフェースである。記憶を（データの論理的な順序ではなく）実際に実行する方法は無関係である。ＦＩＦＯは、長さが実質的に制限されていると考えられるが、実際上、ＦＩＦＯは長さが有限であり、特に、複数のメモリアクセスが競合する場合、データをソートし、取り出す遅延が生じる。画像処理アルゴリズムの最も一般的なアドレッシング必要条件に対処する様々な画像イタレータが存在する。殆どの場合に、各読み出しイタレータには、対応した書き込みイタレータが存在する。種々のイタレータが以下の表に掲載されている。
【０２７３】
【表１９】
0004309954.tif 000020
４ビットアドレスモードレジスタがイタレータタイプを決定するため使用される。
【０２７４】
【表２０】
0004309954.tif 000021
アクセス専用レジスタは以下のように使用される。
【０２７５】
【表２１】
0004309954.tif 000022
フラグレジスタ（アクセス専用１）は、データの読み出し及び書き込みに影響を与える要因を決定する多数のフラグを含む。フラグレジスタは以下のように構成される。
【０２７６】
【表２２】
0004309954.tif 000023
読み出しイネーブル及び書き込みイネーブルに関する注意：
読み出しイネーブルがセットされたとき、Ｉ／Ｏアドレス生成器は読み出しイタレータとして動作するので、特定の順序で画像を読み出し、画素を入力ＦＩＦＯに収容する。
【０２７７】
書き込みイネーブルがセットされたとき、Ｉ／Ｏアドレス生成器は書き込みイタレータとして動作するので、特定の順序で画像を書き込み、出力ＦＩＦＯから画素を取り出す。
【０２７８】
読み出しイネーブルと書き込みイネーブルの両方がセットされたとき、Ｉ／Ｏアドレス生成器は、読み出しイタレータ及び書き込みイタレータとして動作し、入力ＦＩＦＯ内の画素を読み出し、出力ＦＩＦＯからの画素を書き込む。画素は読み出された後に限り書き込まれる。即ち、書き込みイタレータは読み出しイタレータよりも先に進むことはない。このモードが使用されるときには、ＶＬＩＷマイクロコードによる入力処理と出力処理の間のバランスを確保するように注意すべきである。尚、CasheGroup1とキャッシュグループ２に異なる値をロードすることによって、別々のキャッシュグループを読み出しと書き込みに関して指定することも可能である。
【０２７９】
PassX及びPassYに関する注意：
PassXとPassYの両方がセットされた場合、Ｙ縦座標はＸ縦座標よりも前に入力ＦＩＦＯに収容される。
【０２８０】
PassX及びPassYは、読み出しイネーブルビットがクリアされたときに限りセットされる。縦座標をアドレス生成器に渡すのではなく、縦座標は入力ＦＩＦＯに直接収容される。縦座標はＦＩＦＯから取り出されるときに前進する。
【０２８１】
書き込みイネーブルビットがセットされた場合、ＶＬＩＷプログラムは、入力ＦＩＦＯからの縦座標の読み出しを、出力ＦＩＦＯへの書き込みと確実にバランスさせる必要がある。なぜならば、書き込みは、縦座標までしか発生しないからである（読み出しイネーブル及び書き込みイネーブルに関する上記の注意を参照せよ。）
ループに関する注意：
ループビットがセットされた場合、読み出しは、一旦［最終画素、最終行］に達すると、［開始画素、開始行］で再開する。これは、データを繰り返し読み出す必要があるコンボリューションカーネルやディザセルマトリックスのような構造体を処理する場合に理想的である。
【０２８２】
読み出しイネーブル及び書き込みイネーブルがセットされた状態のループ処理は、単一ラインの履歴を維持する環境で役に立ち得るが、書き込みの前に読み出しが行われる場合に限り有効である。（長さに制約のある形式で書き込みが読み出しの前に行われる）ＦＩＦＯの効果がある場合、画像イタレータではなく、適切なテーブルＩ／Ｏアドレッシングモードが使用される。
【０２８３】
書き込みイネーブルだけがセットされたループ処理は、直前のＮ画素の書き込み窓を作成する。これは、窓からデータを読み出す非同期的プロセスを用いて使用される。Ａｒｔｃａｒｄ読み出しアルゴリズムは、このモードを利用する。
【０２８４】
順次読み出し及び書き込みイタレータ
図１７は、画素データフォーマットの説明図である。最も簡単な画像イタレータは、順次読み出しイタレータ、及び対応した順次書き込みイタレータである。順次読み出しイタレータは、チャンネルからの画素を、同時に１行ずつ、上から下に示し、同じ行内では、画素は左から右へ示される。パディングバイトはクライアントに示されない。これは、画像からの各画素にある種のプロセスを実行する必要があるが、処理される画素の順序を問題にしないか、又はデータが特にこの順序であることを要求するアルゴリズムにとって最も有益な点である。順次読み出しイタレータを補完するのは、順次書き込みイタレータである。クライアントは出力ＦＩＦＯに画素を書き込む。順次書き込みイタレータは、適切なキャッシュ処理及び適切なパディングバイトを使用して、有効画像を書き出す。各順次イタレータは、２本のキャッシュラインへのアクセスを必要とする。読み出し時に、３２画素が１本のキャッシュラインから示されるが、他のキャッシュラインはメモリからロードされ得る。書き込み時、３２画素は１本のキャッシュラインに書き込まれるが、他の画素はメモリに書き込まれる。画像の各画素に独立に演算を実行するプロセスは、典型的に、画素を得るために順次読み出しイタレータを使用し、新しい画素値を目的画像内の対応した場所に書き込むため順次書き込みイタレータを使用するであろう。このような処理は図１８に示されている。
【０２８５】
殆どの場合に、原画像及び目的画像は異なり、２個のＩ／Ｏアドレス生成器１８９と１９０によって表現される。しかし、原画像と目的画像を一致させることも有効である。なぜならば、ある種の入力画像は１回しか読み出されないからである。その場合、同じイタレータを入力と出力の両方に使用することが可能であり、読み出しイネーブルレジスタ及び書き込みイネーブルレジスタの両方が適切にセットされる。最大効率の場合、読み出し用と書き込み用の２個の異なるキャッシュグループを使用することが必要である。データがＶＬＩＷプロセスによって作成され、順次書き込みイタレータによって書き込まれるべき場合、PassXフラグ及びPassYフラグは座標を生成するため使用され、その座標は、次に、入力ＦＩＦＯへ伝えられる。ＶＬＩＷプロセスは、これらの座標を使用し、出力データを適切に作成することができる。
【０２８６】
ボックス読み出しイタレータ
ボックス読み出しイタレータは、汎用フィルタ及びコンボルブのような演算を実行するため最も便利な順序で画素を提示するため使用される。このイタレータは、順次に読み出された画素の周りの正方形のボックス内の画素値を提示する。このボックスは、Ｘ及びＹの方向の幅が１、３、５又は７画素になるように制限される（Ｘボックスサイズ及びＹボックスサイズは同じ値であるか、一方の次元の値が１であり、他方の次元の値が３、５又は７である）。この処理は図１９に示されている。
【０２８７】
ボックスオフセット：この専用レジスタは、どの入力画素がボックスの中心として使用されるかに関してサブサンプリングを決定するため使用される。通常値は１であり、これは、各画素がボックスの中心として使用されることを意味する。”２”という値は、画像ピラミッドを構築する場合のように画像を４：１に縮小する際に便利である。上記の図からの画素アドレスを使用すると、ボックスは、画素０、２、８及び１０の順に中心が置かれる。ボックス読み出しイタレータは、最大で１４（２×７）本のキャッシュラインにアクセスする必要がある。画素が７本のラインの中の１組から提示される間に、他のキャッシュラインはメモリからロードすることが可能である。
【０２８８】
ボックス書き込みイタレータ
対応するボックス書き込みイタレータは存在しない。なぜならば、画素の複製は入力時だけに要求されるからである。入力用のボックス読み出しイタレータを使用するプロセスは、殆ど確実に、同期しているので出力用の順次書き込みイタレータを使用するであろう。その良い例はコンボルバである。コンボルバでは、Ｎ個の入力画素が１個の出力画素を計算するため読み出される。そのプロセスフローは、図２０に示されているようなフローである。ボックス読み出しイタレータを使用するとき、原画像及び目的画像は同じメモリを使ってはならない。なぜならば、後続の画像のラインが（新たに計算されたものではなく）元の値を必要とするからである。
【０２８９】
垂直ストリップ読み出し及び書き込みイタレータ
ある種の例では、画像を出力画素の順序で書き込む必要があるが、出力画素に対する入力画素のコヒーレンスの方向がわからない。その一例は回転である。画像が９０度回転され、出力画像を水平方向に処理する場合、キャッシュコヒーレンスの完全に失われる。これに対して、出力画像を処理する同時に１本のキャッシュラインの幅の画素に基づいて出力画像を処理し、（同じライン上の次のキャッシュラインに相当する画素へ進むのではなく）次のラインへ進む場合、入力画像の画素に対するキャッシュコヒーレンスが得られる。入力画素に（色コヒーレンスのような）既知の「ブロック」コヒーレンスが存在する場合も同様であり、この場合、読み出しが処理順序を支配し、同期させられるべき書き込みは、同じ画素順序に従わなければならない。入力として提示された画素の順序（垂直ストリップ読み出し）、又は出力に予想される順序（垂直ストリップ書き込み）は同一である。順序は、ライン０の画素０から画素３１、次に、ライン１の画素９から画素３１、以下、画像の全てのラインに対して同様であり、次に、ライン０の画素３２から６３というように続く。最後の垂直ストリップでは、正確に３２画素が存在しないかもしれない。この場合、画像の実際の画素だけが入力として、提示されるか、又は予定される。この処理は図２１に示されている。
【０２９０】
垂直ストリップ書き込みイタレータだけを必要とするプロセスは、典型的に、出力画素座標が与えられた場合に入力画素座標をマッピングする方法を備えている。そのプロセスは、このマッピングに従って入力画像の画素にアクセスし、コヒーレンスは、入力画像用の「ランダムアクセス」リーダー上に十分なキャッシュラインを設けることによって決定される。図２２のプロセス概要に示されるように、座標は、典型的に、垂直ストリップ書き込みイタレータのPassXフラグ及びPassYフラグをセットすることによって生成される。
【０２９１】
書き込みイタレータを順次読み出しイタレータ又はボックス読み出しイタレータとペアにすることは重要ではないが、垂直ストリップ書き込みイタレータは、入力座標と出力座標の間に重要なマッピングが存在するとき、性能に著しい改良を加える。
【０２９２】
垂直ストリップ読み取りイタレータと垂直ストリップ書き込みイタレータをペアにすることは重要である。この場合、入力画像と出力画像が同じであるならば、垂直ストリップ読み取りイタレータと垂直ストリップ書き込みイタレータを一つのＡＬＵ１８８に割り当てることが可能である。座標が必要であるならば、更なるイタレータをセットされたPassXフラグ及びPassYフラグと共に使用しなければならない。垂直ストリップ読み取り／書き込みイタレータは、入力ＦＩＦＯに画素を提示し、出力ＦＩＦＯからの出力画素を受け取る。適切なパディングバイトが書き込み時に挿入される。入力及び出力の各々は、優れた性能のために少なくとも２本のキャッシュラインを必要とする。
【０２９３】
テーブルＩ／Ｏアドレッシングモード
（画像のような）テーブル内の値を調べることはしばしば必要になる。テーブルＩ／Ｏアドレッシングモードは、この機能を提供し、クライアントがインデックスを出力ＦＩＦＯに入れることを要求する。Ｉ／Ｏアドレス生成器は、インデックスを保有し、適切にデータを調べ、ＶＬＩＷクライアントによる後の処理のため、調べた値を入力ＦＩＦＯに返す。
【０２９４】
１次元、２次元及び３次元のテーブルがサポートされ、特定のモードは補間を対象としている。ＶＬＩＷのクライアント側の複雑さを軽減するため、インデックス値は、固定小数点の数値として取り扱われ、アクセス専用レジスタは、固定小数点を定め、インデックスの整数部として取り扱われるべきビットを定める。データフォーマットは、画素オフセットレジスタが無視される点で、汎用画像特徴の制限された形式であり、データは行内で連続していると仮定され、データ要素毎に、８ビット又は１６ビット（１バイト又は２バイト）だけが許容される。４ビットのアドレスモードレジスタはＩ／Ｏタイプを決定するため使用される。
【０２９５】
【表２３】
0004309954.tif 000024
アクセス専用レジスタは次の通りである。
【０２９６】
【表２４】
0004309954.tif 000025
FractX、FractY及びFractZは、インデックスに基づいてアドレスを生成し、有意ビット及び整数／小数コンポーネントに関するインデックスのフォーマットを解釈するため使用される。種々のパラメータは、索引付けされたテーブルの次元数によって必要に応じて定められる。１次元テーブルは、FractXだけが必要であり、２次元テーブルは、FractX及びFractYを必要とする。各Fract値は、対応したインデックスの小数ビットの個数により構成される。例えば、Ｘインデックスは、５：３のフォーマットである。これは、整数が５ビットで、小数が３ビットであることを示す。したがって、FractXは３にセットされる。簡単な１次元ルックアップは、８：０のフォーマットであり、即ち、小数コンポーネントが全く無い。FractXは０になる。零オフセットは、３次元ルックアップの場合に限り必要になり、２種類の解釈を採用する。これは３次元テーブルルックアップのセクションに詳述されている。フラグレジスタ（アクセス専用１）は、データの読み取り（あるケースでは、書き込み）に影響を与える要因を決定するため使用される多数のフラグを含む。フラグレジスタは以下のように構成される。
【０２９７】
【表２５】
0004309954.tif 000026
１次元直接ルックアップとＤＲＡＭのＦＩＦＯを除くと、全てのテーブルＩ／Ｏモードは、読み出しだけをサポートし、書き込みをサポートしていない。したがって、上記の二つのモードを除く全てのＩ／Ｏモードでは、読み出しイネーブルビットはセットされ、書き込みイネーブルビットはクリアされる。１次元直接ルックアップは、
読み出しイネーブルビットがセットされ、書き込みイネーブルビットがクリアされている読み出し専用と、
読み出しイネーブルビットがクリアされ、書き込みイネーブルビットがクリアされている書き込み専用と、
読み出しイネーブルビットと書き込みイネーブルビットの両方がセットされているリード・モディファイ・ライトと、
の３モードをサポートする。
【０２９８】
異なるモードは、以下の１次元ルックアップのセクションに記載されている。ＤＲＡＭ
ＦＩＦＯモードは、
読み出しイネーブルビットと書き込みイネーブルビットの両方がセットされているライト・リード・モード
という一つのモードだけをサポートする。
【０２９９】
このモードは、以下のＤＲＡＭ ＦＩＦＯのセクションに記載されている。DataSizeフラグは、テーブルの各データ要素のサイズが８ビットであるか、１６ビットであるかを決定する。２種類のデータサイズだけがサポートされる。３２ビットの要素は、プロセスの必要条件に依存して、以下の２種類の方法の何れかで作成することができる：
二つの１６ビットテーブルから同時に読み出し、その結果を合成する。これは、タイミングが問題となるときに都合が良いが、二つのＩ／Ｏアドレス生成器１８９と１９０を無駄に使用する点で欠点があり、各３２ビット要素はＣＰＵによって３２ビットのエンティティとして読むことができない；
１６ビットテーブから２回に亘って読み出し、その結果を合成する。これは、一つのルックアップだけが使用されるので都合が良いが、異なるインデックスを生成し、ルックアップへ伝えなければならない。
【０３００】
１次元構造
直接ルックアップ
直接ルックアップは、１次元ルックアップテーブルへの簡単なインデキシングである。クライアントは、フラグレジスタに適切なビットをセットすることにより、三つのアクセスモード、即ち、
読み出し専用
書き込み専用
リード・モディファイ・ライト
の間で選択可能である。
【０３０１】
読み出し専用
クライアントは、固定小数点インデックスＸを出力ＦＩＦＯに送り、テーブル[Int(X)]の８又は１６ビット値が入力ＦＩＦＯに返される。インデックスＸの小数コンポーネントは完全に無視される。インデックスが範囲外である場合、エッジ繰り返しフラグは、エッジ画素が返されるか、一定画素が返されるかを決定する。アドレス生成は、次のように簡単である：
データサイズが８ビットを示す場合、Ｘは右へバレルシフトされたFractXのビットであり、結果はテーブルのベースアドレスImageStartに加算される；
データサイズが１６ビットを示す場合、Ｘは右へバレルシフトされたFractXのビットであり、左へ１ビットシフトされた（ビット０が０になる）結果は、テーブルのベースアドレスImageStartに加算される。
【０３０２】
結果として得られたアドレスにおける８又は１６ビットデータ値は入力ＦＩＦＯに入れられる。アドレス生成には１サイクルを要し、要求されたデータをキャッシュから出力ＦＩＦＯへ転送するためにも（キャッシュヒットを仮定したとき）１サイクルを要する。例えば、各エントリーが１６ビットであり、インデックスが１２ビットの８：４の固定小数点フォーマットである２５６エントリーのテーブルの値を引く場合を想定すると、FractXは４であり、データサイズは１である。インデックスがルックアップへ渡されたとき、４ビットだけ右へシフトし、その結果を１ビットだけ左へシフトし、ImageStartに加算する。
【０３０３】
書き込み専用
クライアントは、固定小数点インデックスＸを出力ＦＩＦＯへ渡し、その後、テーブルの指定された場所へ書き込まれるべき８又は１６ビット値を渡す。完全な転送には最低でも２サイクル、即ち、アドレス生成のための１サイクルと、ＦＩＦＯからＤＲＡＭへのデータ転送のための１サイクルを要する。ＶＬＩＷプロセスがインデックスをＦＩＦＯに収容してから書き込まれるべき値をＦＩＦＯに収容するまでの間に任意の数のサイクル数を設けることができる。アドレス生成は、読み出し専用モードと同様に行われるが、データがそのアドレスから読み出されるのではなく、出力ＦＩＦＯからのデータがそのアドレスに書き込まれる。アドレスがテーブルの範囲外である場合、そのデータはＦＩＦＯから削除され、ＤＲＡＭには書き込まれない。
【０３０４】
リード・モディファイ・ライト
クライアントは、固定小数点インデックスＸを出力ＦＩＦＯに送り、テーブル[Int(X)]の８又は１６ビット値が入力ＦＩＦＯへ返される。出力ＦＩＦＯに収容された次の値は、テーブル[Int(X)]に書き込まれ、前に返された値を置き換える。汎用処理ループは、ある場所から値を読み出し、値を変更し、その値を書き戻すプロセスである。全体的な時間は、
インデックスからアドレスを生成するサイクルと、
テーブルからの値を返却するサイクルと、
ある種の方法で値を変更するサイクルと、
変更した値をテーブルへ書き戻すサイクルと、
の４サイクルである。
【０３０５】
クライアントが「Ｘからの読み出し」又は「Ｘへの書き込み」を表すフラグを提示する特定の読み出し／書き込みモードは存在しない。クライアントは、元の値を書き込むことにより「Ｘからの読み出し」のシミュレーションを行い、返された値をただ無視することによって「Ｘへの書き込み」のシミュレーションを行うことができる。しかし、このようなモードの使用が促進されることはない。なぜならば、各動作は、最低でも３サイクル（モディファイは必要ではない）を使用し、特定の読み出し及び書き込みモードによって行われるような１回のアクセスではなく２回のデータアクセスを使用するからである。
【０３０６】
補間テーブル
これは、所定の固定小数点インデックスＸに対して、１個の値ではなく２個の値が返される点を除くと、読み出しモードにおける直接ルックアップと同じである。返される値は、テーブル[Int(X)]とテーブル[Int(X)+1]である。いずれかのインデックスが範囲外である場合、エッジ繰り返しフラグは、エッジ画素が返されるか、一定画素が返されるかを決定する。アドレス生成は、８ビットデータであるか１６ビットデータであるかに応じて、２番目のアドレスが単に（１番目のアドレス＋１）又は（１番目のアドレス＋２）である点を除くと、直接ルックアップと同じである。要求されたデータを出力ＦＩＦＯへ転送するためには２サイクルを要するが（キャッシュヒットを想定）、１回の１６ビットフェッチによって２個の８ビット値がキャッシュからアドレス生成器へ実際に返される。
【０３０７】
ＤＲＡＭ ＦＩＦＯ
読み出し／書き込み１次元テーブルの特殊なケースは、ＤＲＡＭ ＦＩＦＯである。ＤＲＡＭ及び付随したキャッシュを使用して所定の長さのＦＩＦＯをシミュレーションすることがしばしば必要である。ＤＲＡＭのＦＩＦＯによって、クライアントは、テーブルに明示的に索引付けをせずに、あたかもＦＩＦＯの一方の端であるかのようにして出力ＦＩＦＯへ書き込み、同じ論理的ＦＩＦＯのもう一方の端であるかのようにして入力ＦＩＦＯから読み出す。２個のカウンタがシミュレーティッドＦＩＦＯの入力位置と出力位置を追跡し、必要に応じてＤＲＡＭへキャッシュする。クライアントは、フラグレジスタの読み出しイネーブルビットと書き込みイネーブルビットの両方を見る必要がある。
【０３０８】
ＤＲＡＭ ＦＩＦＯの用法の一例は、ある値のシングルライン履歴を保持することである。初期履歴は処理が始まる前に書き込まれる。一般的なプロセスがラインを完了するとき、前のラインの値がＦＩＦＯから獲得され、このラインの値はＦＩＦＯに入れられる（このラインは、次のラインを処理するときには前のラインになる）。入力と出力が平均的に相互に一致する限り、出力ＦＩＦＯは常に一杯である。その結果として、この種のＦＩＦＯの場合、アクセス遅延が無く効率的である（但し、ＦＩＦＯ全長が非常に短い場合、例えば、３又は４バイトの場合を除くが、その場合にはＦＩＦＯの目的を損なうであろう）。
【０３０９】
２次元テーブル
直接ルックアップ
２次元直接ルックアップはサポートされていない。２次元ルックアップの全てのケースはバイリニア補間のためアクセスされることが予定されているので、特別なバイリニアルックアップが実現された。
【０３１０】
バイリニアルックアップ
この種のルックアップは、２次元テーブルからのデータのバイリニア補間のために必要である。固定小数点Ｘ座標及びＹ座標が与えられた場合（Ｙ、Ｘの順に出力ＦＩＦＯに入れられた場合）、４個の値がルックアップ後に返される。それらの値は（順番に）：
Table[Int(X), Int(Y)]
Table[Int(X)+1, Int(Y)]
Table[Int(X), Int(Y)+1]
Table[Int(X)+1, Int(Y)+1]
である。
【０３１１】
返される値の順序は、最良のキャッシュコヒーレンスを与える。データが８ビットである場合、２個の値が２サイクルの間のサイクル毎に返され、下位バイトは第１のデータ要素である。データが１６ビットである場合、１サイクル毎に１エントリーずつで、４個の値が４サイクルに返される。アドレス生成には２サイクルを要する。第１サイクルでは、FractYビットだけ右へバレルシフトされたインデックス（Ｙ）がRowOffsetによって乗算され、その結果がImageStartに加えられる。第２サイクルは、ＸインデックスをFractXビットだけ右へシフトし、（８ビットデータの場合）その結果、又は（１６ビットデータの場合）その結果を１ビットだけ左へシフトしたものの何れかが第１サイクルからの結果に加算される。これにより、アドレスAdrは、Table[Int(X), 
Int(Y)]のアドレスである：
Adr = ImageStart
+ ShiftRight(Y, FractY)*RowOffset
+ ShiftRight(X, FractX)
Adrのコピーは後続のエントリーをフェッチするためAdrOldに保持される：
データが８ビットであるならば、タイミングは、アドレス生成の２サイクルであり、その後、データが返却される２サイクルが続く（１サイクル毎に２個のテーブルエントリー）；
データが１６ビットであるならば、タイミングはアドレス生成の２サイクルであり、その後、データが返却される４サイクルが続く（１サイクル毎に１エントリー）。
【０３１２】
以下の二つの表は、８ビットデータサイズ及び１６ビットデータサイズ用のアドレス計算方法を示している。
【０３１３】
【表２６】
0004309954.tif 000027
【０３１４】
【表２７】
0004309954.tif 000028
両方のケースにおいて、アドレス生成の第１サイクルは、ＸインデックスのＦＩＦＯへの挿入と重なってもよく、実効タイミングは、アドレス生成のための１サイクル、及び返却データの４サイクルと同程度に低い。インデックスの生成がその結果よりも２ステップ進んでいる場合、実効アドレス生成時間は無く、データは単に適切なレート（１セット毎に２サイクル又は４サイクル）で生成される。
【０３１５】
３次元ルックアップ
直接ルックアップ
２次元ルックアップの全てのケースはトライリニア補間のためアクセスされることが予想されるので、二つの特別なトライリニアルックアップが実現される。１番目は単純なルックアップテーブルであり、２番目は画像ピラミッドからのトライリニア補間用である。
【０３１６】
トライリニアルックアップ
このタイプのルックアップは、色変換テーブルのような３次元データテーブルに有効である。標準的な画像パラメータは、データの単一のＸＹ平面を定義し、即ち、各平面は、ImageHight個の行により構成され、各行は、RowOffset個のバイトを含む。殆どの環境において、連続した平面を想定すると、一つのＸＹ平面は、ImageHight×RowOffsetバイトの連なりである。このオフセットを仮定又は計算するのではなく、ＣＰＵによるソフトウェアは、そのオフセットを１２ビットZOffsetレジスタの形で提供しなければならない。この形式のルックアップの場合、Ｚ、Ｙ、Ｘの順の３個の固定小数点インデックスが与えらると、ルックアップテーブルから８個の値：
Table[Int(X), Int(Y), Int(Z)]
Table[Int(X)+1, Int(Y), Int(Z)]
Table[Int(X), Int(Y)+1, Int(Z)]
Table[Int(X)+1, Int(Y)+1, Int(Z)]
Table[Int(X), Int(Y), Int(Z)+1]
Table[Int(X)+1, Int(Y), Int(Z)+1]
Table[Int(X), Int(Y)+1, Int(Z)+1]
Table[Int(X)+1, Int(Y)+1, Int(Z)+1]
が順番に返される。
【０３１７】
返される値の順序は、最良のキャッシュコヒーレンスを与える。データが８ビットである場合、２個の値が４サイクルの間のサイクル毎に返され、下位バイトは第１のデータ要素である。データが１６ビットである場合、１サイクル毎に１エントリーずつで、４個の値が８サイクルに返される。アドレス生成には３サイクルを要する。第１サイクルでは、FractZビットだけ右へバレルシフトされたインデックス（Ｚ）が１２ビットのZOffsetによって乗算され、ImageStartに加えられる。第２サイクルでは、FractYビットだけ右へバレルシフトされたインデックス（Ｙ）がRowOffsetによって乗算され、その結果が前のサイクルの結果に加算される。第２サイクルは、ＸインデックスをFractXビットだけ右へシフトし、（８ビットデータの場合）その結果、又は（１６ビットデータの場合）その結果を１ビットだけ左へシフトしたものの何れかが第２サイクルからの結果に加算される。これにより、アドレスAdrは、Table[Int(X), 
Int(Y), Int(Z)]のアドレスである：
Adr = ImageStart
+ (ShiftRight(Z, FractZ)*ZOffset)
+ (ShiftRight(Y, FractY)*RowOffset)
+ ShiftRight(X, FractX)
Adrのコピーは後続のエントリーをフェッチするためAdrOldに保持される：
データが８ビットであるならば、タイミングは、アドレス生成の２サイクルであり、その後、データが返却される２サイクルが続く（１サイクル毎に２個のテーブルエントリー）；
データが１６ビットであるならば、タイミングはアドレス生成の２サイクルであり、その後、データが返却される４サイクルが続く（１サイクル毎に１エントリー）。
【０３１８】
以下の二つの表は８ビットデータサイズ及び１６ビットデータサイズ用のアドレス計算方法を示している。
【０３１９】
【表２８】
0004309954.tif 000029
【０３２０】
【表２９】
0004309954.tif 000030
両方のケースにおいて、アドレス生成のサイクルは、ＸインデックスのＦＩＦＯへの挿入と重なってもよく、単一の１回限りのルックアップの実効タイミングは、アドレス生成のための１サイクル、及び返却データの４サイクルと同程度に低い。インデックスの生成がその結果よりも２ステップ進んでいる場合、実効アドレス生成時間は無く、データは単に適切なレート（１セット毎に４サイクル又は８サイクル）で生成される。
【０３２１】
画像ピラミッドルックアップ
ブラッシング、タイリング及びワーピングの間に、画像の特定エリアの平均カラーを計
算することが必要である。所与のエリア毎に値を計算するのではなく、これらの機能は画像ピラミッドを利用する。画像ピラミッドの説明及び構造は、この文書のＤＲＡＭインタフェース８１の章の内部画像フォーマットに関するセクションに詳述される。このセクションは、順序付きの３個の固定小数点インデックス：レベル（Ｚ）、Ｙ、及びＸに関して、ピラミッド内の所与の画素をアドレッシングする方法に関連する。画像ピラミッドルックアップは８ビットのデータエントリーを想定するので、DataSizeフラグは完全に無視される。Ｚ、Ｙ、及びＸの指定後、以下の８画素：
[Int(X), Int(Y)]のレベルInt(Z)の画素
[Int(X)+1, Int(Y)]のレベルInt(Z)の画素
[Int(X), Int(Y)+1]のレベルInt(Z)の画素
[Int(X)+1, Int(Y)+1]のレベルInt(Z)の画素
[Int(X), Int(Y)]のレベルInt(Z)+1の画素
[Int(X)+1, Int(Y)]のレベルInt(Z)+1の画素
[Int(X), Int(Y)+1]のレベルInt(Z)+1の画素
[Int(X)+1, Int(Y)+1]のレベルInt(Z)+1の画素
が入力ＦＩＦＯを介して返される。
【０３２２】
８個の画素は４×１６ビットのエントリーとして返却され、ＸエントリーとＸ＋１エントリーはハイ／ローに合成される。例えば、拡大縮小された（Ｘ，Ｙ）座標が（１０．４，１２．７）であるならば、最初に返される４個の画素は、（１０，１２）、（１１，１２）、（１０，１３）及び（１１，１３）であろう。座標が有効レンジ外であるとき、クライアントは、エッジ画素繰り返し及び定数画素レジスタ（下位８ビットだけが使用される）によって、エッジ画素繰り返し、又は定数カラー値の返却を選択することができる。画像ビラミッドが構築されたとき、レベル０の座標からレベルＺの座標までの簡単なマッピングが存在する。この方法は、単に、Ｘ又はＹ座標をＺビットだけ右へシフトさせる。これは、座標の整数部を獲得するため既にシフトされたビット数（即ち、Ｘ座標に対するFractXビットの右シフト及びＹ座標に対するFractYの右シフト）に加えて行う必要がある。画像ピラミッドの所与のレベルに対するImageStart及びRowOffsetを見つけるため、２４ビットのZOffsetレジスタがレベル情報テーブルへのポインタとして使用される。このテーブルは、レコードの配列であり、各レコードは、レベル数によって順序付けられた所与のピラミッドのレベルを表現する。各レコードは、ImageStartからそのピラミッドのレベルまでの１６ビットのオフセットZOffset（オフセットの下位６ビットのような６４バイトの整列したアドレスは存在しない）と、そのレベルのための１２ビットのZRowOffsetと、により構成される。テーブルの要素０は、ZOffsetが０であり、単にフルサイズ画像を指示するとき、ZRowOffsetが汎用レジスタRowOffsetと一致する。テーブルの要素ＮにおけるZoffset値は、画像ピラミッドのレベルNの実効ImageStartを得るため、ImageStartに加算されるであろう。テーブルの要素ＮのRowOffset値は、レベルＮに対するRowOffset値を格納する。ＣＰＵ上で動かされるソフトウェアは、このアドレッシングモードを使用する前にテーブルを適切にセットアップしなければならない。実際のアドレス生成の概要は、以下で１サイクル毎に説明される。
【０３２３】
【表３０】
0004309954.tif 000031
上述のアドレス生成は、単一のバレルシフタ、２個のアダー、及び２４ビットを生じる単一の１６×１６乗算／加算ユニットを使用して実現できる。一部のサイクルには２回のシフトが含まれるが、それらは、シフト値が同じであるか（即ち、バレルシフタの出力が２回使用されるか）、又はシフトが１ビットであるかのどちらかであり、ハードワイヤード可能である。次の内部レジスタ：ZAdr, Adr, ZInt, YInt, XInt, ZRowOffset, ZImageStartが必要である。_Int形のレジスタは最大で８ビットだけが必要であるが、他のレジスタは最大２４ビットになり得る。このアクセス方法は、画像ピラミッドから読み出すだけであり、画像ピラミッドへ書き込まないので、キャッシュグループ２(CacheGroup2)が（Zadrを用いて）画像ピラミッドアドレステーブルをルックアップするため使用される。CacheGroup1は、（Adrを用いて）画像ピラミッド自体をルックアップするため使用される。アドレステーブルは、（原画像サイズに応じて）約２２エントリーがあり、各エントリーは４バイトである。したがって、３又は４本のキャッシュラインをキャッシュグループ２に割り付けるべきであり、できるだけ多数のキャッシュラインをCasheGroup1に割り付けるべきである。データのセットを返すためのタイミングは８サイクルであり、サイクル８とサイクル０は動作が重なり合うと考えられ、即ち、次の要求のサイクル０はサイクル８の間に生じる。これが許される理由は、サイクル０がメモリにアクセスせず、サイクル８が特定の演算を含まないからである。
【０３２４】
ＶＬＩＷベクトルプロセッサ７４を用いる座標の生成
書き込みイタレータにリンクされた一部の関数は、処理パイプラインの一部で処理されている現在画素のＸ及び／又はＹ座標を必要とする。特定の処理は、処理されている各行又は列の最後に行われる必要がある。殆どの場合に、PassX及びPassYフラグは全ての座標を完全に生成するために十分である。しかし、特別な必要条件が存在する場合、以下の関数を使用することができる。この計算は、単一サイクル生成のため多数のＡＬＵに展開することが可能であり、或いは、多数サイクル生成のため単一のＡＬＵ１８８内で行ってもよい。
【０３２５】
シーケンシャル［Ｘ，Ｙ］生成
プロセスが順次読み出しイタレータに従って順次に画素を処理するとき（又は、画素を生成し、順次書き込みイタレータへその画素を書き出すとき）、以下のプロセスは、図２３に示されるように、PassXフラグ／PassYフラグの代わりに、Ｘ、Ｙ座標を生成するため使用可能である。
【０３２６】
座標生成器は、Ｘ座標に関して画像幅ImageWidthまでカウントアップし、ImageWidth個の画素毎に１回ずつＹ座標をインクリメントする。実際のプロセスは図２４に示され、以下の定数がソフトウェアによってセットされる。
【０３２７】
【表３１】
0004309954.tif 000032
以下のレジスタは一時変数を保持するため使用される。
【０３２８】
【表３２】
0004309954.tif 000033
必要条件は以下のように要約される。
【０３２９】
【表３３】
0004309954.tif 000034
垂直ストリップ［Ｘ，Ｙ］生成
プロセスが、画素を垂直ストリップ書き込みイタレータへ書くために画素を処理し、ある種の理由からPassXフラグ／PassYフラグを使用できないとき、図２５に示されるようなプロセスがＸ、Ｙ座標を生成するため使用できる。この座標生成器は、Ｘ座標に関して画像幅ImageWidthまでカウントアップし、ImageWidth個の画素毎に１回ずつＹ座標をインクリメントするだけである。実際のプロセスは図２６に示され、以下の定数がソフトウェアによってセットされる。
【０３３０】
【表３４】
0004309954.tif 000035
以下のレジスタは一時変数を保持するため使用される。
【０３３１】
【表３５】
0004309954.tif 000036
必要条件は以下のように要約される。
【０３３２】
【表３６】
0004309954.tif 000037
垂直ストリップ毎に１回ずつ出現する計算（２回の加算、そのうち一つはＭＩＮ演算と関連付けられている）は、一般的なタイミング統計量に含まれない。なぜならば、それらは、画素タイミング毎の実際の一部ではないからである。しかし、それらは、特定の関数用のマイクロコードのプログラミングに考慮しなければならない。
【０３３３】
イメージセンサインタフェース（ＩＳＩ８３）
イメージセンサインタフェース（ＩＳＩ８３）は、ＣＭＯＳイメージセンサからデータを取得し、データをＤＲＡＭに蓄積するため利用できるようにする。イメージセンサは、３：２のアスペクト比をもち、典型的な解像度は７５０×５００サンプルであり、３７５Ｋ（１画素当たり８ビット）を生ずる。２×２画素ブロックの各々は、図２７に示されるような構造を有する。ＩＳＩ８３は、画像を読み出すため、フレーム同期パルス及びPixelClockパルスを含む制御情報をイメージセンサへ送信する状態機械である。画素は、イメージセンサから読み出され、ＶＬＩＷ入力ＦＩＦＯ７８に入れられる。ＶＬＩＷは、次に、画素を処理及び／又は蓄積することが可能である。これは図２８に示されている。ＩＳＩ８３は、検出された写真画像をＤＲＡＭに蓄積するＶＬＩＷプログラムと組み合わせて使用される。処理は次の２ステップで行われる：
小規模ＶＬＩＷプログラムはＦＩＦＯから画素を読み出し、順次書き込みイタレータを介して画素をＤＲＡＭへ書き込む；
ＤＲＡＭ内の写真画像は、写真が撮影されたときのカメラの向きに応じて９０、１８０又は２７０度回転させられる。
【０３３４】
回転が０度である場合、ステップ１は、写真画像を最終的な写真画像格納場所へ書き出すだけであり、ステップ２は実行されない。回転が０度以外である場合、画像は一時エリア（例えば、プリント画像記憶エリア）に書き込まれ、次に、ステップ２の間に、回転させられ最終的な写真画像格納場所へ入れられる。ステップ１は、非常に簡単なマイクロコードであり、ＶＬＩＷ入力ＦＩＦＯ７８からデータを取り出し、そのデータを順次書き込みイタレータに書き込む。ステップ２の回転は、加速Ｖａｒｋアフィン変換関数を用いて実行される。処理は、設計の複雑さを軽減し、画像のために既に必要とされたＶａｒｋアフィン変換回転ロジックを再使用するため、２ステップで行われる。これが許容できる理由は、両方のステップが、Ａｒｔｃａｍのオペレータにとってごくわずかな時間である約０．０３秒内に終了するからである。たとえそうであったとしても、読み出しプロセスは、センサ速度による制限を受け、フレーム全体を読み出すために０．０２秒を要し、画像を回転するため約０．０１秒を要する。
【０３３５】
検出された写真画像と内部フォーマット画像との間で変換を行うために向きは重要である。なぜならば、Ｒ画素、Ｇ画素及びＢ画素の相対位置は向きと共に変化するからである。処理された画像は、印刷のため正しい向きにするために、印刷プロセス中に回転させる必要がある。Ａｒｔｃａｍの３次元モデルは、２個のイメージセンサを具備し、それらの入力は単一のＩＳＩ８３（マイクロコードは異なるが、ＡＣＰ３１は同一）に多重化される。各センサはフレーム蓄積型であるため、両方の画像を同時に取得し、同時にメモリへ転送することができる。
【０３３６】
ディスプレイコントローラ８８
Ａｒｔｃａｍ上の「撮影」ボタンが半押しされたとき、ＴＦＴはイメージセンサからの（簡単なＶＬＩＷプロセスによって変換された）現在の像を表示する。撮影ボタンが完全に押下されたとき、撮影像が表示される。ユーザが印刷ボタンを押下し、画像処理が始まると、ＴＦＴはターンオフされる。画像が印刷されると、ＴＦＴは再度ターンオンされる。ディスプレイコントローラ８８は、フラットパネルディスプレイを内蔵するＡｒｔｃａｍモデルで使用される。例示的なディスプレイは、２４０×１６０画素の解像度を有するＴＦＴ型ＬＣＤである。ディスプレイコントローラ８８の構成は図２９に示されている。ディスプレイコントローラ８８の状態機械はレジスタを含み、レジスタは同期生成のタイミングを制御し、表示画像はそこから（特定のキャッシュグループによるデータキャッシュ７６を介してＤＲＡＭに）取得され、レジスタは、ＴＦＴをその時点で（ＴＦＴイネーブルを用いて）動作可能状態にすべきであるかどうかを制御する。ＣＰＵは、低速バスを介してこれらのレジスタへ書き込むことが可能である。２４０×１６０画素の画像をＲＧＢ方式ＴＦＴに表示するためには、１画素当たりに３個のコンポーネントが必要になる。ＤＲＡＭから取得された画像は３個のＤＡＣを介して表示され、ＤＡＣは、Ｒ、Ｇ及びＢの出力信号の各々に対して１個ずつ設けられる。毎秒３０フレーム（毎秒６０フィールド）の画像リフレッシュレートで、ディスプレイコントローラ８８は、
２４０×１６０×３×３０＝３．５ＭＢ／秒
のデータ転送速度を必要とする。
【０３３７】
このデータ速度は、システムの他の部分よりも低速である。しかし、集約的な画像処理中にＶＬＩＷプログラムを減速させるためには十分に高い。ＴＦＴ動作の一般的な原理はこれを反映している。
【０３３８】
画像データフォーマット
上述の通り、ＤＲＡＭインタフェース８１は、ＡＣＰチップの他のクライアント部と、ＲＡＭＢＵＳ 
ＤＲＡＭとの間を接続する。事実上、ＤＲＡＭインタフェース内の各モジュールはアドレス生成器である：
ＡＣＰによって操作される画像には３種類の論理的タイプがある。それらは、
−ＣＣＤから捕捉された入力像であるＣＣＤ像
−Ａｒｔｃａｍ装置によって内部的に利用される内部画像フォーマット
−Ａｒｔｃａｍによって印刷される出力画像フォーマットである印刷画像
である。
【０３３９】
これらの画像は、典型的に、色空間、解像度、並びに、カメラ間で変動し得る出力及び入力色空間が相違する。例えば、低価格カメラのＣＣＤ像は、高価格カメラで使用されるＣＣＤとは、解像度やカラー特性が異なる。しかし、全ての内部画像フォーマットは、あらゆるカメラの中で色空間に関して同一フォーマットである。
【０３４０】
その上、３種類の画像タイプは、どちらの方向が「上向き」であるかに関して異なる可能性がある。カメラの物理的な向きは、人物像であるか、又は風景像であるかについての観念を生じさせ、この観念は処理全体を通じて維持されるべきである。このため、内部画像は常に正しく向きを決められ、印刷動作中にＣＣＤから獲得された画像に対して回転が実行される。
【０３４１】
ＣＣＤ像編成
多種多様なＣＣＤイメージセンサを利用可能であるが、ＣＣＤ自体は７５０×５００形イメージセンサであり、３７５０００バイト（１画素当たり８ビット）を生成する場合を想定する。２×２画素ブロックの各々は図３０に示されるような構造を有する。
【０３４２】
ＤＲＡＭに蓄積されたときのＣＣＤ像は、メモリ内で隣接している所定のラインと連続した画素を有する。各ラインは、次々に蓄積される。イメージセンサインタフェース８３は、ＣＣＤからデータを取得し、そのデータを正しい向きでＤＲＡＭに格納する役割を担う。このようにして、回転０度のＣＣＤ像は、Ｇ、Ｒ、Ｇ、Ｒ、Ｇ、Ｒ．．．のような第１ラインを含み、Ｂ、Ｇ、Ｂ、Ｇ、Ｂ、Ｇ．．．のような第２ラインを含む。ＣＣＤ像が人物像であり、９０度回転されているならば、第１ラインはＲ、Ｇ、Ｒ、Ｇ、Ｒ、Ｇであり、第２ラインはＧ、Ｂ、Ｇ、Ｂ、Ｇ、Ｂ、．．．（以下同様に続く）となるであろう。
【０３４３】
画素は、インターリーブ形式で蓄積される。なぜならば、全てのカラーコンポーネントが内部画像フォーマットを変換するために必要になるからである。
【０３４４】
ＡＣＰ３１はＣＣＤ画素フォーマットに関して仮説を立てないことに注意する必要がある。なぜならば、イメージング用の実際のＣＣＤは、Ａｒｔｃａｍの間で経時的に変化し得るからである。ハードウェアによって行われる全ての処理は、ＡＣＰ３１の有用性を拡大するために主要なマイクロコードによって制御される。
【０３４５】
内部画像編成
内部画像は、典型的に、多数のチャンネルにより構成される。Ｖａｒｋ画像には、
Ｌａｂ
Ｌａｂα
ＬａｂΔ
αΔ
Ｌ
が含まれるが、これらに限定されるものではない。
【０３４６】
Ｌ、ａ及びｂは、Ｌａｂ色空間のコンポーネントに対応し、αは（コンポジットのため使用される）マットチャンネルであり、Δは（ブラッシング、タイリング、及びイルミネーティングの間に使用される）バンプマップチャンネルである。
【０３４７】
ＶＬＩＷプロセッサ７４は、画像が平面的な構造で編成されることを要求する。そのため、Ｌａｂ画像は、三つの別個のメモリブロック、即ち、
Ｌチャンネル用の１ブロック
ａチャンネル用の１ブロック
ｂチャンネル用の１ブロック
として記憶される。
【０３４８】
各チャンネルのブロック内において、画素は（幾つかのオプションのパディングバイトと共に）所定の行に対し隣接して記憶され、行は次々に記憶される。
【０３４９】
図３１には、論理的画像１００の記憶形式の一例が示されている。論理的画像１００は、逐次記憶されたカラーコンポーネントＬ１０１、ａ１０２及びｂ１０３を有する平面形式で記憶される。或いは、論理的画像１００は、非圧縮Ｌコンポーネント１０１と、圧縮Ａコンポーネント１０５及び圧縮Ｂコンポーネント１０６を有する圧縮フォーマットで記憶してもよい。
【０３５０】
図３２を参照すると、ラインｎ（１１０）の画素は、ラインｎ＋１（１１１）の画素の前に一緒に格納されている。画像は単一チャンネル内の隣接したメモリに記憶されている。
【０３５１】
８ＭＢメモリモデルの場合、全処理の終了後の最終的な印刷画像は、クロミナンスチャンネルにおいて圧縮する必要がある。クロミナンスチャンネルの圧縮は、４：１にすることができ、全体的な圧縮は１２：６又は２：１になる。
【０３５２】
最終的な印刷画像を除くと、Ａｒｔｃａｍの画像は典型的に圧縮されない。メモリ制約のため、ソフトウェアは、クロミナンスチャンネルの最終的な印刷画像を、これらのチャンネルの各々を２：１でスケーリングすることによって圧縮することを選択してもよい。これが行われた後、画像を印刷するために利用されるプリントＶａｒｋ関数は、圧縮されたものとして指定されたクロミナンスチャンネルを取り扱うように指示されるべきである。プリント関数は、圧縮されたクロミナンスを取り扱う方法を知っている唯一の関数であるが、たとえそうであるとしても、プリント関数は、固定の２：１圧縮比で処理するだけである。
【０３５３】
画像を圧縮し、次に、最終印刷画像を作成するため圧縮画像に基づいて動作することは可能であるが、これは、解像度の損失を生ずるので推奨できない。その上、画像は、プリントアウト前の最終段階として一回だけ圧縮されるべきである。１回の圧縮は実質的には気付かれないのに対し、多数回の圧縮はかなりの画像劣化を生じさせる。
【０３５４】
クリップ画像編成
Ａｒｔｃａｒｄに記憶されたクリップ画像はＡＣＰ３１によって明示的にはサポートされない。ソフトウェアは、現在のＡｒｔｃａｒｄから画像を取り出し、ＡＣＰで認識できる形式にデータを編成する役割を担う。画像がＡｒｔｃａｒｄ上に圧縮形式で記憶されているならば、ソフトウェアは、それらを伸長する役割を担う。なぜならば、Ａｒｔｃａｒｄ画像の伸長をサポートする特定のハードウェアは存在しないからである。
【０３５５】
画像ピラミッド編成
画像を操作するため利用されるブラッシング、タイリング、及びワーピングプロセス中に、しばしば、画像の特定のエリアの平均カラーを計算することが必要である。所与の各エリアの値を計算するのではなく、これらの関数は、画像ピラミッドを利用する。図３３に示されるように、画像ピラミッドは、事実上の多重解像度画素マップである。原画像１１５は１：１表現である。各次元におけるローパスフィルタリング及び２：１のサブサンプリングによって、元のサイズの１／４の画像１１６が得られる。このプロセスは、画像全体が単一画素によって表現されるまで続けられる。画像ピラミッドは、原始的な内部フォーマット画像から構築され、原画像が占めていたサイズの１／３（１／４＋１／１６＋１／６４＋．．．）を使用する。１５００×１０００の原画像の場合、対応した画像ピラミッドは約１／２ＭＢである。画像ピラミッドは特定のＶａｒｋ関数によって構築され、他のＶａｒｋ関数のパラメータとして使用される。
【０３５６】
印刷画像編成
処理画像全体は、それを印刷するため同時に必要になる。しかし、印刷画像出力は、ＣＭＹディザ画像を含み、唯一の一時的な画像フォーマットであり、印刷画像機能内で使用される。しかし、内部色空間から印刷色空間への色変換が必要であることに注意しなければならない。その上、色変換は、インク特性の異なるカメラのプリントロールの種類毎に別々に調整することができる。例えば、セピア出力は特定のセピア調色Ａｒｔｃａｒｄを使用して実行され、又はセピア色調プリントロールを使用して実行される（したがって、全てのＡｒｔｃａｒｄはセピア色調で機能する）。
【０３５７】
色空間
上述の通り、Ａｒｔｃａｍでは、画像タイプの種類に対応して三つの色空間が使用される。
【０３５８】
ＡＣＰは、特定の色空間についての直接的な知識を持たない。その代わりに、ＡＣＰは、ＣＣＤ色空間、内部色空間、及びプリンタ色空間、即ち、
ＣＣＤ色空間：ＲＧＢと、
内部色空間：Ｌａｂと、
プリンタ色空間：ＣＭＹと、
の間の変換のためクライアントの色空間変換テーブルに依存する；
ＡＣＰ３１から色空間変換を取り除くことによって、
−様々なカメラで様々なＣＣＤを使用すること
−同じカメラで（長期間に異なるプリントロールの）異なるインクを使用すること
−ＡＣＰ設計パスからＣＣＤ選定を分離すること
−正確なカラー処理のため内部色空間を巧く定義すること
が可能になる。
【０３５９】
Ａｒｔｃａｒｄインタフェース８７
Ａｒｔｃａｒｄインタフェース（ＡＩ）は、Ａｒｔｃａｒｄがリニアイメージセンサの下を通過するときに、リニアイメージセンサからデータを取得し、どのデータをＤＲＡＭに記憶するため利用する。イメージセンサは、１走査線当たりに１１０００個の８ビットサンプルを生成し、Ａｒｔｃａｒｄを４８００ｄｐｉでサンプリングする。ＡＩは、画像を読み出すため、LineSyncパルス及びPixelClockパルスを含む制御情報をリニアセンサへ送る状態機械である。画素は、リニアセンサから読み出され、ＶＬＩＷ入力ＦＩＦＯ７８に収容される。ＶＬＩＷは、次に、画素を処理する、及び／又は、画素を蓄積することが可能である。ＡＩは以下の数個のレジスタを含む。
【０３６０】
【表３７】
0004309954.tif 000038
尚、ＣＰＵは、走査を始動する前にＶＬＩＷ入力ＦＩＦＯ７８をクリアしなければならない。状態レジスタは以下のように解釈されるビットを有する。
【０３６１】
【表３８】
0004309954.tif 000039
Ａｒｔｃａｒｄインタフェース（ＡＩ）８７
Ａｒｔｃａｒｄインタフェース（ＡＩ）８７は、Ａｒｄｃａｒｄリーダー３４からＡｒｔｃａｒｄ画像を取得し、それをオリジナルデータ（通常は、Ｖａｒｋスクリプト）に復号化する役割を担う。特に、ＡＩ８７は、ＡｒｔｃａｒｄスキャナリニアＣＣＤ３４から信号を受け取り、カードに印刷されたビットパターンを検出し、ビットパターンをオリジナルデータに変換し、読み出しエラーを訂正する。
【０３６２】
Ａｒｔｃａｒｄ９が挿入されていない場合、Ａｒｔｃａｍから印刷された画像は、任意の標準的な画像処理ルーチンによって整理された検出写真画像に過ぎない。Ａｒｔｃａｒｄ９は、ユーザがプリントアウトする前に写真を修正するための手段である。特定のＡｒｔｃａｒｄ９をＡｒｔｃａｍに挿入するという簡単なタスクによって、ユーザは、写真画像に対して実行される複雑な画像処理を定義することができる。
【０３６３】
Ａｒｔｃａｒｄが挿入されていない場合、写真画像は、印刷画像を作成するため通常の方法で処理される。１枚のＡｒｔｃａｒｄ９がＡｒｔｃａｍに挿入されているとき、そのＡｒｔｃａｒｄの効果は、印刷画像を生成するため写真画像に適用される。Ａｒｔｃａｒｄ９が取り外されたとき（取り出されたとき）、印刷された画像は標準的な方法で処理された写真画像に戻る。ユーザがＡｒｔｃａｒｄを取り出すためボタンを押下したとき、Ａｒｔｃａｍ中央プロセッサ３１で実行されるオペレーティングシステムによって維持されるイベントキューにイベントが収容される。イベントが処理されるとき（例えば、現在のプリントが行われた後）、以下の状況が発生する。
【０３６４】
現在のＡｒｔｃａｒｄが有効であるならば、印刷画像は無効としてマークされ、「プロセス標準」イベントがイベントキューに入れられる。イベントが最終的に処理されたとき、印刷画像を生成するため、写真画像に標準的な画像処理演算が加えられる。
【０３６５】
モーターはＡｒｔｃａｒｄを取り出すため始動され、時間的に規定された「モーター停止」イベントがイベントキューに追加される。
【０３６６】
アートカードの挿入
ユーザがＡｒｔｃａｒｄ９を挿入したとき、Ａｒｔｃａｒｄセンサ４９はそれを検知し、ＡＣＰ７２へ報せる。これにより、ソフトウェアは、「Ａｒｔｃａｒｄ挿入済み」イベントをイベントキューに挿入する。このイベントが処理されると、以下の数個の状況が発生する：
現在のＡｒｔｃａｒｄは無効としてマークされる（「無し」ではない）；
印刷画像は無効としてマークされる；
Ａｒｔｃａｒｄモーター３７はＡｒｔｃａｒｄを取り込むため始動される；
Ａｒｔｃａｒｄインタフェース８７はＡｒｔｃａｒｄを読み取るように命令される；
Ａｒｔｃａｒｄインタフェース８７は、ＡｒｔｃａｒｄスキャナリニアＣＣＤ３４から信号を受け取り、カードに印刷されたビットパターンを検出し、検出されたビットパターンの誤りを訂正し、有効ＡｒｔｃａｒｄデータブロックをＤＲＡＭに生成する。
【０３６７】
ＡｒｔｃａｒｄＣＣＤからのデータ読み出し−一般的考察
図３４に示されるように、データカード読み出しプロセスは、画素データがカードから読み出される間に４フェーズを有する。フェーズは以下の通りである：
フェーズ１ Ａｒｔｃａｒｄ上のデータエリア検出
フェーズ２ ＣＣＤ画素に基づくＡｒｔｃａｒｄからのビットパターン検出と、バイトとしての書き込み
フェーズ３ バイトパターンのスクランブル解除及びＸＯＲ演算
フェーズ４ データ復号化（リード・ソロモン復号）。
【０３６８】
図３５に示されるように、Ａｒｔｃａｒｄ９は、ナイキストの定理を充足するため、少なくとも印刷された解像度の２倍でサンプリングされなければならない。実際には、これよりも高いレートでサンプリングする方がよい。好ましくは、画素は、各次元で印刷されたドットの解像度の３倍でサンプリングされ（２３７）、１個のドットを定義するために９個の画素が必要になる。したがって、Ａｒｔｃａｒｄ９の解像度が１６００ｄｐｉであり、センサ３４の解像度が４８００ｄｐｉである場合、５０ｍｍのＣＣＤイメージセンサを使用することにより、１列毎に９４５０画素が得られる。即ち、２ＭＢのドットデータ（１ドット当たり９画素の場合）が必要であるならば、２ＭＢ＊８＊９／９４５０＝１５９７８列＝約１６０００列が必要になる。勿論、ドットがサンプリングＣＣＤと厳密に揃えられていないならば、考えられる最悪のケースでは、ドットは１６（４×４）画素エリア（２３１）で検出されるであろう。
【０３６９】
Ａｒｔｃａｒｄ９は、熱損傷のため多少歪みが生じ、Ａｒｔｃａｒｄリーダーへの挿入のばらつきによって僅かに（最大で、例えば、１度）回転し、リーダーモーター３７の速度の変動を原因として真のデータレートに僅かな偏差が現れる可能性がある。これらの変化のために、カードからのデータの列は、対応した画素データの列として読み出せなくなる。図３６に示されるように、Ａｒｔｃａｒｄ９の１度の回転によって、カード上のある列からの画素は、１６６列に亘る画素として読み出されることになる。
【０３７０】
最後に、Ａｒｔｃａｒｄ９は、人間のオペレータにとって合理的な時間内に読み取られなければならない。Ａｒｔｃａｒｄ上のデータはＡｒｔｃａｒｄ表面の大部分を覆っているので、タイミングの問題はＡｒｔｃａｒｄデータ自体に制限され得る。１．５秒の読み出し時間は、Ａｒｔｃａｒｄ読み出しとして適切である。
【０３７１】
Ａｒｔｃａｒｄは１．５秒内に取り込まれなければならない。したがって、１６０００列の全ての画素データがＣＣＤ３４から１．５秒以内に、即ち、１秒当たり１０６６７列で読み出される必要がある。したがって、１列を読み取るために利用できる時間は１／１０６６７秒、即ち、９３７４７ナノ秒である。画素データは画素データを読み出すプロセスとは完全に独立に、同時に１列ずつＤＲＡＭへ書き込むことが可能である。
【０３７２】
１列のデータ（１画素当たり４ビット、したがって、１バイト当たりに２×４ビット画素の読み出しが可能であるので、９４５０／２バイト）をＤＲＡＭへ書き込むための時間は、８個のキャッシュラインを使用することによって短縮される。４ラインが同時に書き込まれるならば、４バンクを独立にかきこむことが可能であり、オーバーラップレイテンシーが短縮される。この場合、４７２５バイトは１１８４０ｎｓ（４７２５／１２８＊３２０ｎｓ）で書き込み可能である。このようにして、所定の列データをＤＲＡＭへ書き込むために要する時間は、利用可能な帯域幅の１３％未満しか使用しない。
【０３７３】
Ａｒｔｃａｒｄの復号化
単純にデータサイズを見ると、リニアＣＣＤ３４によって読み取られるようなＡｒｔｃａｒｄ画素データ全体（各ビットが３×３配列として読まれるならば１４０ＭＢ）が維持される場合、プロセスを８ＭＢのメモリ３３に適合させることは不可能に思われる。このため、リニアＣＣＤの読み取り、ビットマップの復号化、及びアンビットマッププロセスは、（Ａｒｔｃａｒｄ９がリニアＣＣＤ３４の傍を通過する間に）リアルタイムで行われるべきであり、これらのプロセスは、全ての画像データ蓄積が利用可能にされなくても効率的に作用しなければならない。
【０３７４】
Ａｒｔｃａｒｄ９が挿入されたとき、古い蓄積された印刷画像と拡大された写真画像は無効になる。新しいＡｒｔｃａｒｄ９は、現在の撮影写真画像に基づいて新しい画像を作成する命令を含み得る。古い印刷画像は無効であり、拡大された写真画像及び画像ピラミッドを保持するエリアは無効であり、読み出しプロセス中にスクラッチメモリとして使用できる５ＭＢよりも多くの量が残される。厳密に説明すると、Ａｒｔｃａｒｄの新しい生データが書き込まれるべき１ＭＢのエリアは、最終的なリード・ソロモン復号化が行われるときまで、Ａｒｔｃａｒｄ読み出しプロセス中にスクラッチデータとして使用可能であり、その１ＭＢエリアが再度開放される。ここで説明している読み出しプロセスは、（データの最終的な宛先としての利用を除いて）余分な１ＭＢエリアを利用しない。
【０３７５】
また、スクランブル解除プロセスは、スクランブル解除を所定の場所で行うことができないので、２組の２ＭＢのメモリエリアを必要とすることに注意すべきである。幸運にも、５ＭＢのスクラッチエリアはこの目的のために十分なスペースを含む。
【０３７６】
図３７を参照すると、Ａｒｔｃａｒｄデータを復号化するために必要なステップのフローチャート２２０が示されている。これらのステップには、Ａｒｔｃａｒｄ２２１を読み込むステップと、対応した符号化され、ＸＯＲ演算され、スクランブル処理されたビットマップデータ２２３を生成するため、読まれたデータを復号化するステップと、を含む。次に、符号化され、スクランブル処理されたデータ２２４を生成するため、チェッカーボードＸＯＲ演算がそのデータに適用される。このデータは、次に、データ２２５を生成するためにスクランブル解除２２７され、その後、このデータは、元の生データ２２６を生成するため、リード・ソロモン復号化を受ける。或いは、スクランブル解除及びＸＯＲ演算プロセスは、一緒に行ってもよく、別々のデータのパスを必要としない。上記のステップの各々は、以下で詳述される。図３７を参照して説明したように、Ａｒｔｃａｒｄインタフェースは、４フェーズを有し、そのうちの最初の二つは、時間的に重大であり、画素データがＣＣＤから読み出される間に行われなければならない：
フェーズ１ Ａｒｔｃａｒｄ上のデータエリア検出
フェーズ２ ＣＣＤ画素に基づくＡｒｔｃａｒｄからのビットパターン検出と、バイトとしての書き込み
フェーズ３ バイトパターンのスクランブル解除及びＸＯＲ演算
フェーズ４ データ復号化（リード・ソロモン復号）。
【０３７７】
これらの４フェーズを次に詳細に説明する。
【０３７８】
フェーズ１：Ａｒｔｃａｒｄ９がＣＣＤ３４を通過するとき、ＡＩは、データエリアの左側でＡｒｒｃａｒｄ上の特別ターゲットを確実に検出することにより、データエリアのスタートを検出しなければならない。特別ターゲットが検出され得なかった場合、カードは無効としてマークされる。この検出は、Ａｒｔｃａｒｄ９がＣＣＤ３４を通過する間に、リアルタイムで行われる必要がある。
【０３７９】
必要に応じて、回転不変性が与えられる。この場合、ターゲットは、Ａｒｔｃａｒｄの右側で繰り返されるが、上隅ではなく、下右隅に関連している。このようにして、もし、カードが「間違った」やり方で挿入された場合、ターゲットは、結局、正しい向きにされる。後述のフェーズ３は、データの向きを検出し、回転の可能性を考慮するように変更してもよい。
【０３８０】
フェーズ２：データが一旦決定されると、主たる読み出しプロセスが始まり、ＣＣＤからの画素データを「Ａｒｔｃａｒｄデータ窓」に入れ、この窓からのビットを検出し、検出されたビットをバイトに組み立て、ＤＲＡＭにバイトイメージを構築する。これは、ＡｒｔｃａｒｄがＣＣＤを通過する間に全て行われる必要がある。
【０３８１】
フェーズ３：全ての画素がＡｒｔｃａｒｄデータエリアから読み出されると、Ａｒｔｃａｒｄモーター３７は停止させられ、バイトイメージはスクランブル解除され、ＸＯＲ演算される。リアルタイム性能は要求されないが、このプロセスは、人間のオペレータを煩わせない程度に高速でなければならない。このプロセスは、２ＭＢのスクランブル化されたビットイメージを取得し、スクランブル加除され／ＸＯＲ演算されたビットイメージを別々の２ＭＢイメージに書き込む。
【０３８２】
フェーズ４：Ａｒｔｃａｒｄ読み出しプロセスの最終フェーズは、リード・ソロモン復号化プロセスであり、２ＭＢビットイメージが１ＭＢの有効Ａｒｔｃａｒｄデータエリアに復号化される。再び、リアルタイム性能は要求されないが、人間のオペレータからみて素早く復号化を行うことが必要である。復号プロセスが有効であるならば、カードは有効としてマークされる。復号に失敗した場合、ビットイメージ内のデータの複製の復号化が試みられ、プロセスは、成功するか、又はビットイメージ内にデータの複製イメージが存在しなくなるまで繰り返される。
【０３８３】
上記の４フェーズプロセスは、４．５ＭＢのＤＲＡＭを必要とする。２ＭＢはフェーズ２の出力のために確保され、０．５ＭＢはフェーズ１及び２の間のスクラッチデータ用に確保される。残りの２ＭＢのスペースは、１列当たりに４７２５バイトとして４４０列以上を保持することができる。実際上、読み出されている画素データはフェーズ１のアルゴリズムよりも数列分だけ先行しており、最悪のケースでは、約１８０列だけフェーズ２よりも遅れるが、４４０列の限界の範囲内に十分に収まる。
【０３８４】
次に、各フェーズの実際の動作を詳細に説明する。
【０３８５】
フェーズ１−Ａｒｔｃａｒｄ上のデータエリア検出
このフェーズは、Ａｒｔｃａｒｄ９上のデータエリアの左側を確実に検出することと関係がある。データエリアの正確な検出は、カードの左側に印刷された特殊ターゲットの正確な検出によって実現される。これらのターゲットは、特に、最大１度までの回転がある場合でも簡単に検出できるように設計されている。
【０３８６】
図３８を参照すると、Ａｒｔｃａｒｄ９の左側の拡大図が示されている。このカードの左側は１６個のバンド２３９に分割され、ターゲット、例えば、２４１は各バンドの中心に設けられる。バンドは、バンドを分離するための線が引かれていないという点で論理的である。図３９には、１個のターゲットが示されている。ターゲット２４１は、単一の白色ドットを含む印刷された黒色正方形である。この考え方は、最初にできるだけ多数のターゲット２４１を検出し、次に、少なくとも８個の検出された白色ドットの場所を単一の論理的な直線に繋ぎ合わせるというものである。この考え方が実行できれば、データエリア２４３のスタートは、この論理的な直線から一定距離になる。実行できない場合、カードは無効であるとして拒否される。
【０３８７】
図３８に示されるように、カード９の高さは３１５０ドットである。ターゲット（Target0）２４１は、データエリアの左上隅２４４から２４ドットの一定距離だけ離れた場所に置かれるので、ターゲットは、１９２ドット（５７６画素）の等しいサイズの１６個の領域のうちの最初の領域２３９の範囲に巧く収まり、カードの最後の画素領域にターゲットは存在しない。ターゲット２４１は、簡単に検出できるように十分に大きくしなければならないが、カードが１度回転したときに領域の外側へ出る程に大きくしてはならない。ターゲットの適当なサイズは、白色ドット２４２を含む３１×３１ドット（９３×９３個の検出画素）の黒色正方形２４１である。
【０３８８】
最悪の１度の回転がある場合、１列分のシフトは５７画素毎に起こる。したがって、５９０画素のサイズのバンドの場合、カードが最悪の回転状態であるならば、このシンボルの何れかの部分を、上部若しくは下部の１２画素、又はバンドのその場所に配置することは不可能であり、或いは、シンボルはＣＣＤ読み出し時に間違ったバンドで検出されるであろう。
【０３８９】
したがって、矩形の黒色部分が５７画素の高さ（１９ドット）である場合、少なくとも９．５個の黒色画素は、ＣＣＤによって同一列で確実に読み出すことができる（画素の半分が１列に収まり、あとの半分が次の列に収まる最悪ケース）。同一列で少なくとも１０個の黒色ドットが確実に読み出されるようにするため、高さを２０ドットにする必要がある。黒色ドットのスタートのエッジでの誤検出に備えて、ドットの個数を３１まで増加させ、ターゲットのローカル座標（１５，１５）に置かれた白色ドットの両側に１５ドットずつを置く。３１ドットは９１画素であり、列内のシフトは最大でも３画素であり、５７６画素のバンドの範囲内に容易に収まる。
【０３９０】
このように、各ターゲットは、３１×３１ドット（９３×９３画素）のブロックであり、各ターゲットは、
各列に３１個の黒色ドットを含む１５列（９３画素のうちの４５画素幅の列）と、
１５個の黒色ドット（４５画素）、１個の白色ドット（３画素）、及び更なる１５個の黒色ドット（４５画素）を含む１列と、
各列が３１個の黒色ドットを含む１５列（９３画素のうちの４５画素幅の列）と、
により構成される。
【０３９１】
ターゲット検出
ターゲットは、ドットを検出するのではなく、同時に１列ずつ画素の列を読み出すことにより検出される。所定のバンド内で、ターゲットの左側を構築する多数の隣接した黒色画素により構成された多数の列を探索することが必要である。次に、更なる黒色列の中心で白色領域を見つけることが期待され、最後に、ターゲットの中心の左側で黒色列が見つけられる。
【０３９２】
画素の読み出しの際に優れたキャッシュ性能を得るためには８個のキャッシュラインが必要である。論理的な読み出し毎に、４回のサブ読み出しによって４個のキャッシュラインが満たされ、一方、その他の４個のキャッシュラインは使用される。これは、利用可能なＤＲＡＭ帯域幅の１３％までを効率的に使用する。
【０３９３】
図４０に示されるように、ターゲットを検出する検出機構ＦＩＦＯは、フィルタ２４５、ランレングスエンコーダ２４６、及びランダムアクセスのため最上部３要素（Ｓ１、Ｓ２及びＳ３）の特別な配線を必要とするＦＩＦＯ２４７を含む。
【０３９４】
入力画素の列は、全てのターゲットが検出されるか、又は指定された数の列が処理されるまで、同時に１列ずつ処理される。列を処理するため、画素はＤＲＡＭから読み出され、０又は１を検出するためフィルタ２４５の中を通され、次に、ランレングス符号化２４６される。ビット値、及び同じ値の隣接したビットの個数は、ＦＩＦＯ２４７に入れられる。ＦＩＦＯ２４９の個々のエントリーは８ビットに収まり、７ビット２５０はランレングスを保持し、１ビット２４９は検出されたビットの値を保持する。
【０３９５】
ランレングスエンコーダ２４６は、５７６画素（１９２ドット）領域内の隣接した画素だけを符号化する。
【０３９６】
ＦＩＦＯ２４７の最上部３要素は、ランダムな順序でアクセス２５２され得る。これらのエントリーの（画素の）ランレングスは、以下の表に従って、ショート、ミディアム、及びロングの３個の値にフィルタ処理される。
【０３９７】
【表３９】
0004309954.tif 000040
ＦＩＦＯ２４７の最上部の３個のエントリーに着目すると、３種類の興味深い特殊ケースが存在する。
【０３９８】
【表４０】
0004309954.tif 000041
好ましくは、領域バンド毎に以下の情報が保持される。
【０３９９】
【表４１】
0004309954.tif 000042
全部で７バイトが与えられる。合計が８バイトであるならば、アドレス生成が簡単化される。そこで、１６個のエントリーは、１６＊８＝１２８バイトが必要であり、これは、４個のキャッシュラインとぴったり合う。アドレスレンジは、０．５ＭＢのＤＲＡＭエリアのスクラッチの内側に入るべきである。なぜならば、他のフェーズが残りの４ＭＢデータエリアを利用するからである。
【０４００】
所定の画素列を処理し始めるとき、レジスタ値S2StartPixel２５４は０にリセットされる。ＦＩＦＯ内のエントリーがＳ２からＳ１へ進むとき、それらは、既存のS2StartPixel値に加算され（２５５）、現在Ｓ２で定義されているランの正確な位置を与える。ＦＩＦＯ内の３個の興味深いケースの各々を調べると、S2StartPixelはターゲットの黒色エリアのスタートを判定するため使用可能であり（ケース１及び２）、ターゲットの中心にある白色ドットのスタートを判定するため使用可能である（ケース３）。列を処理するアルゴリズムは以下のように表される。
【０４０１】
【表４２】
0004309954.tif 000043
列の処理に関与するステップ（プロセスColumn）は以下の通りである。
【０４０２】
【表４３】
0004309954.tif 000044
３種類のケース（処理ケース）の各々に対する処理は以下の通りである。
【０４０３】
ケース１：
【０４０４】
【表４４】
0004309954.tif 000045
ケース２：
ケース３を識別するためPrevCaseWasCase2フラグ（前のケースはケース２であった）をセットする以外に特別な処理は記録されない（上記の列を処理するステップ３を参照）。
【０４０５】
ケース３：
【０４０６】
【表４５】
0004309954.tif 000046
所与の列を処理する最後に、現在の列がターゲット検出のための列の最大番号と比較される。許容された列の番号を超えたとき、検出されたターゲットの個数をチェックする必要がある。検出されたものが８個未満であるならば、カードは無効であると見なされる。
【０４０７】
プロセス ターゲット
ターゲットが検出された後、ターゲットを処理する必要がある。全部のターゲットが利用可能であるか、又は一部のターゲットだけが利用可能である。一部のターゲットは誤って検出された可能性もある。
【０４０８】
この処理のフェーズは、できるだけ多数のターゲットの中心を通る数学的な直線を決定する。その直線が通過するターゲットの個数が多いほど、より高い信頼度でターゲット位置が検出される。限界は８ターゲットに設定される。直線が少なくとも８個のターゲットを通過する場合、正しい直線である見なされる。
【０４０９】
力ずくではあるが、簡単なアプローチを採用することは差し支えない。なぜならば、そのように行うための時間があり（以下を参照）、複雑さを低減することによりテストが簡単化されるからである。Target0とTarget1（両方のターゲットが有効であると見なされる場合）の間で直線を決定し、この直線上にあるターゲットの個数を決定する必要がある。次に、Target0とターゲット２の間の直線を決定し、このプロセスを繰り返す。最終的に、Target1と２の間の直線、１と３の間の直線等に同じプロセスを実行し、以下同様に続き、最終的に、Target1４とTarget1５の間の直線に同じプロセスを実行する。全てのターゲットが検出された場合を想定すると、１５＋１４＋１３＋．．．＝９０回の計算（各計算の組は１６回のテストを必要とするので、実際には、１４４０回の計算）を実行し、その直線に沿って最大個数のターゲットが検出された直線を選択する必要がある。ターゲット位置を見つけるためのアルゴリズムは、例えば、以下のようになる：
0004309954.tif 000047
図３４に示されるように、上記アルゴリズムにおて、TargetA２６１及びTargetBからCurrentLine２６０を決定するため、ターゲット２６１、２６２と、ターゲットＡの位置との間でΔrow（２６４）及びΔcolumn（２６３）を計算することが必要である。Δrow及びΔcolumnを加算することにより、Target0からTarget1、以下同様、へ移動することが可能になる。検出された（実際に検出されたならば）TargetNの位置は、直線上のTargetNの計算された予測位置と比較することができ、許容範囲内に収まるならば、TargetNは直線上にあることが判定される。
【０４１０】
Δrow及びΔcolumnは、
Δrow = (rowTargetA
- rowTargetB)/(B - A)
Δcolumn =
(columnTargetA- columnTargetB)/(B-A)
により計算される。次に、Target0の位置を、
row = rowTargetA - (A * Δrow)
column = columnTargetA - (A * Δcolumn)
により計算する。
【０４１１】
また、(row,
column)を実際のrowTarget0及びcolumnTarget0と比較する。ある予測ターゲットから次のターゲット（例えば、Target0からTarget1）へ移動するためには、Δrow及びΔcolumnをそれぞれrow及びcolumnに加算すればよい。各ターゲットが直線上にあるかどうかをチェックするため、Target0の予測位置を計算し、次に、各ターゲットの座標に対して１回の加算及び１回の比較を実行することが必要である。
【０４１２】
１６個全てのターゲットと最大で９０本の直線との比較の終了後、得られる結果は有効ターゲットを通る最良直線である。その直線が少なくとも８個のターゲットを通過するならば（即ち、MaxFound >= 8）、直線を形成するために十分なターゲットが検出されたことが認められるので、カードを処理することができる。最良直線の通過するターゲットが８個未満であるならば、カードは無効であると見なされる。
【０４１３】
結果として生じるアルゴリズムは、Δrow及びΔcolumnを計算するための１８０回の除算と、Target0の位置を計算するための１８０回の乗算／加算と、２８８０回の加算／比較と、を要する。この処理を実行するための時間は、３６列の画素データを読み出すために要する時間、即ち、３３７４８９２ｎｓである。加算は除算よりも所要時間が短いという事実までを考慮しない場合、３２４０回の数学的演算を３３７４８９２ｎｓ内に実行しなければならない。これは、１演算当たりに約１０４０ｎｓ、即ち、１０４サイクルに相当する。したがって、ＣＰＵは、ターゲットの全ての処理を無事に実行することが可能であり、設計の複雑さは低減される。
【０４１４】
データエッジ境界及びクロックマークに基づく重心の更新
ステップ０：データエリアの位置検出
Target0（図３８の２４１）からデータエリアの左上境界２４４までの行及び列に関する距離は所定の固定距離であり、更に、垂直クロックマーク２７６までには１ドットの列がある。したがって、前の段階で見つかったTargetA、Δrow及びΔcolumn（Δrow及びΔcolumnはターゲット間の距離を表す）は、上述のようにTarget0の重心又は予測位置を計算するため使用される。
【０４１５】
Target0からデータエリアまでの固定画素オフセットはターゲット間の距離（ターゲット間は１９２ドット、Target0とデータエリア２４３の間は２４ドット）と関連付けられるので、単に、Δrow/8をTarget0の重心の列座標に加算すればよい（ドットのアスペクト比は１：１）。最上部座標は、
(columnDotColumnTop= columnTarget0
+ (Δrow/8)
(rowDorColumnTop= rowTarget0
+ (Δcolumn/8)
として定義される。
【０４１６】
次のΔrow及びΔcolumnは、ターゲット間のドット数によってそれらを除算することにより、（ターゲット間ではなく）単一列内のドット間の画素数を与えるために更新される：
Δrow = Δrow/192
Δcolumn = Δcolumn/192
更に、currentColumnレジスタ（フェーズ２を参照）には−１をセットすることにより、ステップ２の後、フェーズ２が開始したとき、currentColumnレジスタは−１から０へインクリメントする。
【０４１７】
ステップ１：初期重心デルタ（Δ）及びビット履歴の書き出し
これは、フェーズ２のために必要なセットアップ情報を書き込むだけである。
【０４１８】
これは、各行のすべてのΔrow及びΔcolumnのエントリーと、ビット履歴に０を書き込むことによって実現できる。ビット履歴は実際には予測ビット履歴である。なぜならば、クロックマーク列２７６の左側には境界列２７７があり、その前には、白色エリアが存在することがわかっているからである。したがって、ビット履歴は、０１１、０１０、０１１、０１０等である。
【０４１９】
ステップ２：読み出された実際の画素に基づく重心の更新
ビット履歴は、予測クロックマーク及びデータ境界に従ってステップ１でセットアップされる。各ドット行の実際の重心は、予測データを実際の画素値と比較することによって、より正確にセットされる（初期的には０である）。重心更新機構は、フェーズ２のステップ３を実行するだけで実現される。
【０４２０】
フェーズ２−読み出された画素に基づくＡｒｔｃａｒｄからのビットパターン検出及びバイトとしての書き込み
Ａｒｔｃａｒｄ９からのドットは、３列に亘って検出された少なくとも９個の画素が提示されることを要求するので、検出された画素列毎にドット検出計算を実行するポイントは殆ど無い。処理に要する時間は、平均ドット出現に亘って平均化し、利用可能な処理時間を最大化した方がよい。これにより、Ａｒｔｃａｒｄ９からのドットの列の処理を、Ａｒｔｃａｒｄから３列のデータを読み出すために要する時間内に収めることが可能になる。最も可能性の高いケースでは、ドットを提示するために４列を要するが、４番目の列は、あるドットの最後の列であり、且つ次のドットの最初の列である。したがって、処理は３列だけに制限されるべきである。
【０４２１】
ＣＣＤからの画素は、利用可能な時間の１３％内でＤＲＡＭに書き込まれるので、８３％の時間、即ち、９３７４７＊３の８３％＝２８１２４１ｎｓの８３％＝２３３４３０ｎｓは、ドットの１列を処理するために利用可能である。
【０４２２】
利用可能な時間内に、３１５０ドットを検出し、それらのビット値をメモリの生データエリアに書き込むことが必要である。したがって、この処理は以下のステップを必要とする：
Ａｒｔｃａｒｄ上のドットの列毎に、
ステップ０：次のドット列へ進む；
ステップ１：Ａｒｔｃａｒｄドット列の上端及び下端を検出する（クロックマークをチェックする）；
ステップ２：ドット列を処理し、ビットを検出し、ビットを適切に記憶する；
ステップ３：重心を更新する。
【０４２３】
Ａｒｔｃａｒｄの論理的なドット列を処理し、論理的なドット列は１６５画素に亘ってシフトする可能性があるので、最悪のケースでは、少なくとも１６５列がＤＲＡＭに読み込まれるまで、最初の列を処理できない。したがって、フェーズ２は、読み出しプロセスが終了した後、同じ時間で終了する。最悪ケースの時間は、１６５＊９３７４７ｎｓ＝１５４６８２５５ｎｓ、即ち、０．０１５秒である。
【０４２４】
ステップ０：次のドットへ前進
次のドットの列へ進むため、Δrow及びΔcolumnをdotColumnTopに加算し、列の上端のドットの重心を得る。最初にこれを行うとき、ビットイメージ画像データエリアの左側のクロックマーク列２７６の所にいるので、第１のデータ列へ進む。Δrow及びΔcolumnは、１列内のドット間の距離を表すので、ドット列の間を移動するために、ΔrowをcolumndotColumnTopに加算し、ΔcolumnをrowdotColumnTopに加算することが必要である。
【０４２５】
処理中の列番号を追跡するため、列番号は、CurrentCoulmnという名称のレジスタに記録される。センサが次のドット列へ進むたびに、CurrentColumnレジスタをインクリメントする必要がある。CurrentColumnレジスタが最初にインクリメントされとき、それは、−１から０へインクリメントされる（フェーズ１のステップ０を参照）。CurrentColumnレジスタは、（maxColumnsに達したときに）読み出しプロセスを終了するときを決定し、（８ドット列毎に１回ずつ）８ビット全部がバイトに書き込まれた後、DataOutPointerを次のバイト情報の列へ進めるために使用される。下位３ビットは、現在のバイトにどのビットまで入るかを決定する。
【０４２６】
ステップ１：Ａｒｔｃａｒｄドット列の上端及び下端の検出
Ａｒｔｃａｒｄからのドット列を処理するため、列の上端及び下端を検出することが必要である。列は、（局所的な歪み等を除いて）列の上端と下端の間に直線を形成すべきである。初期的に、dotCoulumnTopはクロックマーク列２７６を指定する。予測値をトグルさせ、予測値をビット履歴に書き込み、ステップ２へ進むだけでよく、その最初のタスクは、列の最初のデータドットに到達するため、Δrow及びΔcolumnの値をdotColumnTopに加算することである。
【０４２７】
ステップ２：Ａｒｔｃａｒｄのドット列を処理
列の上端及び下端の重心が画素座標に与えられたならば、列は、それらの間に歪み等を原因とする変動ができる限り少ない直線を形成する。
【０４２８】
処理が列の上端（上端重心座標）でスタートし、列の下端へ下がる場合を想定すると、後続の予測ドット重心は、
rownext= row + Δrow
columnnext= column + Δcolumn
として与えられる。
【０４２９】
これは、列の次のドットの予測重心のアドレスを与える。しかし、局部的な歪み及び誤差を考慮するため、直前に所定の行で検出したドットに基づく別のΔrow及びΔcolumnを加算する。このようにして、列の上端から下端を繋ぎ合わせる直線からあるパーセンテージの最大のドリフトに累積する小さいドリフトを考慮することができる。
【０４３０】
したがって、行毎に２個の値を保持するが、行履歴はこのフェーズのステップ３で使用されるので、それらの２個の値は別々のテーブルに格納する：
＊Δrow及びΔcolumn（それぞれ２＠４ビット＝１バイト）；
＊行履歴 （１行毎に３ビット、１バイト当たり２行が格納される）。
【０４３１】
行毎に、重心への変化を決定するため、Δrow及びΔcolumnを読み出すことが必要である。読み出しプロセスは、帯域幅の５％と２個のキャッシュラインを要する：
７６＊（３１５０／３２）＋２＊３１５０＝１３８２４ｎｓ＝帯域幅の５％。
【０４３２】
重心が決定されると、重心の周辺画素は、ドットの状態、即ち、ビットの値を検出するために調べられる。換言すると、ドットは、４×４画素のエリアを覆う。しかし、ドットの解像度の３倍の解像度でサンプリングしているので、ドットの状態、即ち、ビットの値を検出するために必要な画素数はこれよりも遙かに少ない。１回につきアクセスすべき画素列は、３列に過ぎない。
【０４３３】
１％の回転による画素ドリフトのある最悪ケースでは、重心は５７画素行毎に１列ずつシフトするが、ドットの直径が３ドットであるため、ある列は、１７１画素行（３＊５７）に対して有効であろう。１バイトは２画素を含むので、各バッファ読み出し（４個のキャッシュライン）で有効なバイト数は、最悪の場合に（１２８の読み出しのうちの）８６であろう。
【０４３４】
ビットが検出されると、ビットはＤＲＡＭへ書き出すことが必要である。ＤＲＡＭ遅延を最小限に抑えるため、８列からのビットが隣接したバイトのセットとして格納される。所与のドット列からの全てのビットは、データバイト内の次のビット位置に対応するので、そのバイトの古い値を読み出し、新しいビット内でシフトしＯＲ演算し、そのバイトを書き戻すことが可能である。
【０４３５】
読み出し／シフト及びＯＲ演算／書き込みプロセスは２個のキャッシュラインを必要とする。
【０４３６】
所定の行に対するビット履歴を更新するとき、そのビット履歴を読み出し、書き込むことが必要である。１行当たりに必要なビット履歴は３ビットだけであり、２行の履歴を単一バイトに格納することが可能である。読み出し／シフト及びＯＲ演算／書き込みプロセスは２個のキャッシュラインを必要とする。
【０４３７】
ビット検出及び蓄積のために要する総帯域幅は以下の表に掲載されている。
【０４３８】
【表４６】
0004309954.tif 000048
ドットの検出
重心を与えるドットの値（即ち、ビットの値）を検出するプロセスは、３個の画素値を検査し、ルックアップテーブルから結果を取得することによって実現される。この処理は、かなり簡単であり、図４２に示されている。ドット２９０の半径は約１．５画素である。したがって、重心を支える画素２９１は、その画素内の重心の実際の位置とは無関係に、完全にそのドット値であろう。重心が画素２９１の中心と正確に一致するならば、重心画素の上画素２９２及び下画素２９３、並びに、重心画素の左画素２９４及び右画素２９５は、大部分そのドット値であろう。重心が画素２９５の正確な中心から離れているならば、中心画素以外の画素がそのドットによって１００％覆われる可能性が高い。
【０４３９】
図４２には、中心の左及び下へ偏っている重心だけが示されているが、同じ関係が中心の上側及び右側の重心に対しても成り立つことは明白である。ケース１では、重心は、中央画素２９５の中心と正確に一致する。中心画素２９５はそのドットによって完全に覆われ、上、下、左、及び右の画素もそのドットによって十分に覆われている。ケース２では、重心は、中央画素２９１の中心の左側にある。中心画素は、依然としてドットによって完全に覆われ、中心の左の画素２９４はドットによって完全に覆われている。上画素２９２及び下画素２９３は依然として十分に覆われている。ケース３では、重心は、中央画素２９１の中心の下側にある。中心画素２９１は、依然としてドット２９１によって完全に覆われ、中心の左の画素はドットによって完全に覆われている。中心の左画素２９４及び右画素２９５は依然として十分に覆われている。ケース４では、重心は中央画素の中心の左下にある。中心画素２９１は依然としてドット２９１によって完全に覆われ、中心の左画素２９４、及び中心の下画素２９４はドットによって完全に覆われている。
【０４４０】
重心を更新するアルゴリズムは、以下の３個の代表的な画素を選択し、ドットの値を決定するため、中央画素２９１の中心から重心までの距離を使用する：
第１画素：重心を含む画素
第２画素：重心のＸ座標（列値）が＜１／２である場合、第１画素の左側の画素であり、さもなければ、第１画素の右側の画素
第３画素：重心のＹ座標（行値）が＜１／２である場合、第１画素の上側の画素であり、さもなければ、第１画素の下側の画素。
【０４４１】
図４３に示されるように、各画素の値は、予め計算されたルックアップテーブル３０１へ出力される。３個の画素は１２ビットのルックアップテーブルへ供給され、このルックアップテーブルはドットの値、即ち、オン又はオフを示す単一ビットを出力する。ルックアップテーブル３０１は、チップ定義時に構築され、約５００ゲートにまとめられる。ルックアップテーブルは、簡単な閾値テーブルでもよいが、但し、中心画素（第１画素）は重く重み付けされる。
【０４４２】
ステップ３：列において行毎に重心Δｓの更新
Δｓ処理の考え方は、現在列において、行毎に予測重心位置で完全なドットを生成するため、前のビット履歴を使用することである。実際の（ＣＣＤからの）画素は、予測完全画素と比較される。両方が一致する場合、実際の重心位置は正確に予測位置に含まれるので、重心Δｓは有効であり、更新する必要がない。さもなければ、予測重心位置を実際のデータに最も良く適合させるため、重心Δｓを更新するプロセスを行うことが必要である。新しい重心Δｓは次の列のドットを処理するために使用される。
【０４４３】
重心Δｓの更新は、下記の理由で、ステップ２からの後続のプロセスとして実行される：なぜならば、
設計の複雑さを軽減し、それにより、十分な帯域幅が残っているフェーズ１のステップ２として実行でき、ＤＲＡＭバッファを再使用できるようになり、
重心更新に必要な全てのデータが特殊なパイプライン化を行うことなく、プロセスのスタート時に利用できることが保証されるからである。
【０４４４】
重心Δは、複雑さを低減するため、Δcolumn及びΔrowとして処理される。
【０４４５】
所与のドットは直径が３ドットであるが、４×４の画素エリアに出現する可能性が高い。しかし、あるドットのエッジは、結果的に、次のドットのエッジと同じ画素に含まれる。このため、重心更新のためには、所与の単一ドットに関する情報以外の情報が必要である。
【０４４６】
図４４には、前の列からの単一のドット３１０が所与の重心３１１と共に示されている。本例では、ドット３１０は、４個の画素列３１２から３１５の範囲にΔが広がり、実際上、前のドット列のドット（座標=(Prevcolumn, 
CurrentRow)）の一部は、現在行のドットの現在列に入り込んでいる。現在の行及び列のドットが白色であるならば、前の列のドットからのドット情報（現在の列のドットは白色）しか存在しないので、前のドット列から最も右側にある画素列３１４は小さい値であると予測される。このことから、この画素列３１５における画素値が高くなればなるほど、重心がより右側になることがわかる。勿論、右側のドットも黒色であるならば、サブピクセルから情報を獲得できないので、重心を調整することができる。同様のことは、ドット座標(Prevcolumn, CurrentRow)における左、上及び下のドットについても成り立つ。
【０４４７】
このことから、最大で５個の画素列及び画素行が必要であることがわかる。行及び列の重心Δｓを別々に考慮し、それらを９０度だけ回転した同じ問題として取り扱うことにより、状況を簡単化することが可能である。
【０４４８】
水平方向のケースを最初に説明すると、予測画素が検出画素と一致しない場合、列重心Δｓを変更することが必要である。ビット履歴から、現在ドット列の現在行に対して見つかったビットの値、直前のドット列、及び二つ前のドット列がわかる。予測重心位置もわかっている。これらの二組の情報を使用することにより、読み出しが完全であるならば、２０ビットの予測ビットパターンを生成することが可能である。２０ビットのビットパターンは水平方向次元で５画素毎の予測Δ値を表現する。１番目のニブルは、最も左側のドットの最も右側の画素を表現する。次の３個のニブルは、前の列からドット３１０の中心を通る３画素を表現し、最後のニブルは（現在列から）最も右側のドットの最も左側の画素３１７を表現する。
【０４４９】
予測重心が画素の中心である場合、２０ビットパターンは以下の表に基づくことが予測される。
【０４５０】
【表４７】
0004309954.tif 000049
中心ドットの左側及び右側の画素は、ビットが０であるか、又は１であるかに応じて、それぞれ、０又はＤである。中心の３画素は、ビットが０であるか、又は１であるかに応じて、それぞれ、０００又はＤＦＤである。これらの値は、所与の画素に対してドットによって占められた物理的なエリアに基づいている。画素の正確な中心から重心までの距離に依存して、僅かにシフトしたデータを予測し、これは、実際に中心画素の両側の画素だけに影響を与える。１６通りの可能性があるので、中心からの距離を１６で除算し、予測画素をシフトさせるためその量を使用することができる。
【０４５１】
２０ビットの５個の画素予測値が決定されると、それは読み出された実際の画素と比較される。これは、画素単位で、読み出された実際の画素から予測画素を減算し、最後に、予測Δ値からの距離を獲得するため、それらの差をまとめて加算することにより行われる。
【０４５２】
図４５は、上記アルゴリズムを実現する一形態の説明図であり、ビット履歴３２２及び重心小数コンポーネント３２３を受け取り、対応した２０ビットの数３２４を出力するルックアップテーブル３２０が含まれ、２０ビットの数３２４は、中心画素入力３２６から減算３２１され、画素差３２７が生成される。
【０４５３】
このプロセスは、予測重心に関して、Δcolumnの量１による重心の左シフト及び右シフトに対して１回ずつ実行される。実際の画素からの差が最も小さい重心は、「勝者」であると見なされ、それに応じてΔcolumnが更新される（「変更無し」が望ましい）。その結果として、Δcolumnは、ドット列毎に１よりも大きく変更されることはない。
【０４５４】
このプロセスは垂直方向画素に対しても繰り返され、その結果としてΔrowが更新される。
【０４５５】
ここで、並列化できる見通しはかなり高い。ＡＣＰユニット３１に対して選択されたクロックのレートに依存して、これらのユニットは直列に配置することができ（これにより、３種類のΔのテストは連続したクロックサイクルで行われる）、又は並列に配置することができ、これにより、３種類のテストを同時に行うことができる。クロックレートが十分に高速であるならば、並列化の必要性はない。
【０４５６】
帯域幅初期化
Δｓの古いΔを読み出し、それらを再度書き出すことが必要である。これは、帯域幅の１０％を要する：
２＊（７６（３１５０／３２）＋２＊３１５０）＝２７６４８ｎｓ＝帯域幅の１０％。
【０４５７】
Δｓを更新するとき、所与の列のビット履歴を読み出すことが必要である。各バイトは２個の行のビット履歴を含むので、帯域幅の２．５％を要する：
７６（（３１５０／３２）／２）３２）＋２＊（３１５０／２）＝４０８５ｎｓ＝帯域幅の２．５％。
【０４５８】
１％の回転によって画素がドリフトする最悪ケースでは、重心は５７画素行毎に１列だけシフトするが、ドットの直径は３画素であるため、所与の画素列は、１８１画素行（３＊５７）に対して有効である。バイトは２画素を収容するので、キャッシュ読み出しにおいて有効なバイト数は最悪のケースで（１２８回の読み出しのうちの）８６である。５列に対する最悪ケースのタイミングは、したがって、３１％帯域幅である：
５＊（（（９４５０／（１２８＊２））＊３２０）＊１２８／８６）＝８８１１２ｎｓ＝帯域幅の３１％。
【０４５９】
重心Δを更新するために必要な総帯域幅は以下の表に掲載されている。
【０４６０】
【表４８】
0004309954.tif 000050
フェーズ２のメモリ使用量
２ＭＢのビットイメージＤＲＡＭエリアは、フェーズ２処理中に読み書きされる。２ＭＢ画素データＤＲＡＭエリアは読まれる。
【０４６１】
０．５ＭＢのスクラッチＤＲＡＭエリアは行データを格納するため使用される。即ち、
【０４６２】
【表４９】
0004309954.tif 000051
フェーズ３−生データのスクランブル解除及びＸＯＲ演算
図３７を参照すると、復号化の次のステップは、生データのスクランブル解除及びＸＯＲ演算である。Ａｒｔｃａｒｄから取得されるような２ＭＢバイト画像は、スクランブル処理され、ＸＯＲ演算された形式である。これは、フェーズ４におけるリード・ソロモンデコーダに必要なビットイメージを得るためにスクランブル解除及び再ＸＯＲ演算を必要とする。
【０４６３】
図４６を参照すると、スクランブル解除プロセス３３０は、２ＭＢのスクランブル付きのバイト画像３３１を取得し、スクランブル解除された２ＭＢ画像３３２を書き込む。このプロセスは、同じ場所で合理的に実行することが不可能であるため、２組の２ＭＢエリアが利用される。スクランブル付きのデータ３３１は、１６×１６配列に並べられたシンボルブロック順であり、シンボルブロック０（３３４）は、ランダムな順序の、あらゆる符号語からの全てのシンボル０を含む。シンボルブロック１は、ランダムな順序で全ての符号語からの全てのシンボル１を含み、以下同様である。２５５個のシンボルしかないので、２５６番目のシンボルブロックは、現時点では使用されない。
【０４６４】
線形フィードバックシフトレジスタは、シンボルブロック、例えば、シンボルブロック３３４内の位置と、そのシンボルブロックが由来する符号語、例えば、符号語３５５との間の関係を決定するため使用される。これは、元のＡｒｔｃａｒｄ画像を生成したときと同じシードが使用される限り機能する。時間のボトルネックは、ＤＲＡＭの非順次アドレスへの読み出し／書き込みの準備完了を待機することであるため、他のソースラインからのバイトと、０ｘＡＡ及び０ｘ５５とのＸＯＲ演算は、（時間的に）実質的に制約がない。
【０４６５】
スクランブル解除及びＸＯＲ演算プロセスのタイミングは、実質的に、２ＭＢのランダムバイト読み出しと、２ＭＢのランダムバイト書き込みであり、即ち、
２＊（２ＭＢ＊７６ｎｓ＋２ＭＢ＊２ｎｓ）＝３２７１５５７１２ｎｓ、つまり、約０．３３秒である。このタイミングはキャッシュ処理を想定していない。
【０４６６】
フェーズ４−リード・ソロモン復号
このフェーズはループであり、ビットイメージ内のデータのコピーに対して繰り返され、復号が成功するか、又は復号しようとするコピーが無くなるまで、データのコピーをリード・ソロモン復号モジュールへ送る。
【０４６７】
使用されるリード・ソロモンデコーダは、適切にプログラミングされたＶＬＩＷプロセッサでもよく、或いは、ＬＳＩロジックのL64712のような別個のハードワイヤードでもよい。L64712は、１秒当たり５０Ｍビット（毎秒約６．２５ＭＢ）のスループットを備えているので、時間は、２ＭＢの読み出し及び１ＭＢの書き込みのためのメモリアクセス時間（順次アクセスの場合５００ＭＢ／秒）ではなく、むしろ、リード・ソロモンデコーダの速度によって制約される。最悪ケースで要する時間は、２／６．２５秒＝約０．３２秒である。
【０４６８】
フェーズ５ Ｖａｒｋスクリプトの実行
Ａｒｔｃａｒｄ９を読み出し、それを復号化するために要する総時間は、約２．１５秒である。ユーザにとっての明らかな遅れは、実際には、０．６５秒（フェーズ３及び４の合計）に過ぎない。なぜならば、Ａｒｔｃａｒｄは、１．５秒後に動きを止めるからである。
【０４６９】
Ａｒｔｃａｒｄがロードされると、Ａｒｔｖａｒｋスクリプトは解釈される。直ちにスクリプトを実行するのではなく、スクリプトは、「プリント」」ボタン１３（図１）を押したときに限り実行される。スクリプトを実行するために取られる措置は、スクリプトの複雑さに大きく依存し、プリントボタン及び実際のプリントボタンを押下し、実際のプリントが行われるまでの間に認識される遅れを考慮しなければならない。
【０４７０】
代替Ａｒｔｃａｒｄフォーマット
勿論、他のａｒｔｃａｒｄのフォーマットも考えられる。以下では、多数の好適な特徴を備えたこのような新しい代替ａｒｔｃａｒｄフォーマットについて説明する。以下では、代替Ａｒｔｃａｒｄデータフォーマット、ユーザデータを代替Ａｒｔｃａｒｄ上のドットにマッピングする機構、及びリソースが不足している組込型システムで使用するための高速代替Ａｒｔｃａｒｄ読み出しアルゴリズムを説明する。
【０４７１】
代替Ａｒｔｃａｒｄの概要
代替Ａｒｔｃａｒｄは、組込型アプリケーション及びＰＣ型アプリケーションの両方で使用され、大容量のデータ又はコンフィギュレーション情報への使い易いインタフェースを提供する。
【０４７２】
代替Ａｒｔｃａｒｄの裏面は（データを保存するので）アプリケーションとは無関係に同一の外観を有するが、代替Ａｒｔｃａｒｄの表面はアプリケーションに依存している。表面はアプリケーションとの関係においてユーザに意味がなければならない。
【０４７３】
代替Ａｒｔｃａｒｄ技術は、印刷解像度とは独立にすることができる。カード上にドットとしてデータを保存する考え方は、（解像度を上げることによって）同じ空間により多くのドットを配置することができるならば、それらのドットがより多くのデータを表現し得るということを意味するに過ぎない。好適な実施例は、例示的なＡｒｔｃａｒｄとしての８６ｍｍ×５５ｍｍカード上で１６００ｄｐｉの印刷を利用することを想定するが、他の等価的なレイアウト、他のカードサイズのためのデータサイズ、及び／又は、他の印刷解像度に決定することは容易である。印刷解像度とは無関係に、読み出し技術はそのまま維持される。全ての復号化及びその他のオーバーヘッドを考慮した後、代替Ａｒｔｃａｒｄは、１６００ｄｐｉまでの印刷解像度で、最大で１メガバイトのデータを保存することが可能である。代替Ａｒｔｃａｒｄは、１６００ｄｐｉを超える印刷解像度で、数メガバイトのデータを保存することが可能である。以下の二つの表は、ある印刷解像度に対する代替Ａｒｔｃａｒｄの実効データ記憶容量を要約するものである。
【０４７４】
代替Ａｒｔｃａｒｄのフォーマット
代替Ａｒｔｃａｒｄ上のデータ構造は、データの復元を補助するため特別に設計されている。このセクションは代替Ａｒｔｃａｒｄのデータ（裏）面のフォーマットを説明する。
【０４７５】
ドット
代替Ａｒｔｃａｒｄのデータ面のドットはモノクロでもよい。例えば、黒色ドットが、所定の望ましい印刷解像度で白色背景に印刷される。その結果として、「黒色ドット」は物理的に「白色ドット」から区別される。図４７には、黒色ドット及び白色ドットの拡大図の様々な例が示されている。白色背景上の黒色ドットのモノクロ方式は、好ましくは、ブラー効果のある読み出し環境においてダイナミックレンジを最大にするために選択される。黒色ドットが特定のピッチ（例えば、１６００ｄｐｉ）で印刷されているとしても、ドット自体は、ドットが隣接させて印刷されたときに、隣接した直線が作成されるように、少し大きくされる。ドットは、実際には滲みの結果として一つに併合されるかもしれないが、図４７の例示的な画像では併合されていない。黒色のキザキザはもっと取り除かれるであろう。好適な実施例に記述された代替Ａｒｔｃａｒｄは、ドットサイズの柔軟に変化することを許容するが、最良の結果を得るためには、正確なドットサイズ、及び特定の印刷技術用のインク／印刷動作をより詳細に調べるべきである。
【０４７６】
このＡｒｔｃａｒｄの実施例の説明中、用語ドットは、代替Ａｒｔｃａｒｄ上に物理的に印刷されたドット（インク、熱、電子写真、ハロゲン化銀等）を意味する。代替Ａｒｔｃａｒｄリーダーが代替Ａｒｔｃａｒｄを走査するとき、ドットは、ナイキストの定理を充たすために、少なくとも印刷された解像度の２倍でサンプリングされる必要がある。用語画素は、代替Ａｒｔｃａｒｄリーダー装置からのサンプル値を意味する。例えば、１６００ｄｐｉのドットが４８００ｄｐｉで走査されるとき、ドットの各次元に３個の画素、即ち、１ドット当たりに９個の画素が存在する。サンプリングプロセスは後述される。
【０４７７】
図４８を参照すると、典型的な代替Ａｒｔｃａｒｄのデータ面１１０１が示されている。各代替Ａｒｔｃａｒｄは、白色境界領域１１０３によって囲まれた「アクティブ」領域１１０２により構成される。白色境界１１０３は、データ情報を格納しないが、代替Ａｒｔｃａｒｄリーダーによってホワイトレベルを較正するため使用される。アクティブ領域は、データブロック、例えば、１１０４の配列であり、各データブロックは、８個の白色ドット、例えば、１１０６のギャップによって隣のデータブロックから分離されている。印刷解像度に依存して、代替Ａｒｔｃａｒｄ上のデータブロック数は変化する。１６００ｄｐｉの代替Ａｒｔｃａｒｄ上で、配列は８×８でもよい。各データブロック１１０４は、６２７×３９４ドットの次元を有する。ブロック間ギャップ１１０６が８白色ドットである場合、代替Ａｒｔｃａｒｄのアクティブエリアは、５０７２×３２０８ドット（１６００ｄｐｉのとき、８．１ｍｍ×５．１ｍｍ）である。
【０４７８】
データブロック
図４９を参照すると、単一のデータブロック１１０７が示されている。代替Ａｒｔｃａｒｄのアクティブ領域は、同一構造のデータブロック１１０７の配列により構成される。各データブロックの構造は、クロックマーク１１０９によって囲まれたデータ領域１１０８と、境界１１１０と、Target1１１１である。データ領域は、符号化データだけを含み、クロックマーク、境界、及びターゲットは、特に、データ領域の位置検出を補助し、領域内からのデータの正確な復元を保証するために設けられる。
【０４７９】
各データブロック１１０７の次元は、６２７×９３４ドットである。この中で、５９５×３８４ドットの中央エリアはデータ領域１１０８である。周囲ドットは、クロックマーク、境界、及びターゲットを保持するため使用される。
【０４８０】
境界及びクロックマーク
図５０はデータブロックを示し、図５１及び図５２は、そのデータブロックの拡大エッジ部分を示す。図５１及び図５２に示されるように、二つの５ドット高の境界及びクロックマーク領域１１７０及び１１７７が各データブロックに存在し、一方はデータ領域の上方に、もう一方はデータ領域の下側にある。例えば、上端の５ドット高領域は、（データブロックの長辺を引き延ばす）外側黒色ドット境界線１１１２と、（境界線が独立していることを保証する）白色ドット分離線１１１３と、３ドット高のクロックマークの組１１１４と、により構成される。クロックマークは、白色及び黒色行の間で交互に代わり、黒色ブロックの両端から８番目の列で黒色クロックマークから始まる。クロックマークドットとデータ領域内のドットとの間は分離されていない。
【０４８１】
クロックマークは、代替Ａｒｔｃａｒｄが１８０度回転させて挿入された場合に、同じ相対的な境界／クロックマーク領域が出現するという点で対称性がある。境界１１１２、１１１３は、データがデータ領域から読み出されるときに、垂直方向に追従するため、代替Ａｒｔｃａｒｄが使用することを意図されている。クロックマーク１１１４は、データがデータ領域から読み出されるときに、水平方向に追跡することが意図されている。白色のドット直線による境界とクロックマークの分離は、読み取り中にブラー効果が発生する結果として望ましい。境界は、このようにして、両側が白色の黒色直線になり、読み出し時の周波数応答の改良に役立つ。白色と黒色の間で交互に代わるクロックマークは、垂直次元ではなく、水平次元である点を除いて、類似した結果を生ずる。任意の代替Ａｒｔｃａｒｄは、追跡のために使用することを意図しているならば、クロックマーク及び境界の位置を見つけなければならない。次のセクションは、クロックマーク、境界及びデータへの方向を示すため設計されたターゲットを取り扱う。
【０４８２】
ターゲット領域内のターゲット
図５４に示されるように、二つの１５ドット幅のターゲット領域１１１６及び１１１７が各データブロックに存在する。一方はデータ領域の左側に存在し、他方はデータ領域の右側に存在する。ターゲット領域は、方位のため使用される１列のドットによってデータ領域から分離される。ターゲット領域１１１６及び１１１７の目的は、クロックマーク、境界、及びデータ領域までの進み方を指定することである。各ターゲット領域は、６個のターゲット、例えば、１１１８を含み、６個のターゲットは、代替Ａｒｔｃａｒｄリーダーによって簡単に検出できるように設計される。次に、図５３を参照すると、単一Target1１２０の構造が示されている。各Target1１２０は、１５×１５ドットの黒色正方形であり、中心構造１１２１とランレングス符号化ターゲット番号１１２２と、を含む。中心構造１１２１は、単純な白色十字であり、ターゲット番号コンポーネント１１２２は、単純な２列の白色ドットであり、各列はターゲット番号の各部分に対し２ドットの長さである。したがって、ターゲット番号１のターゲットｉｄの１１２２は２ドットの長さであり、ターゲット番号２のターゲットｉｄの１１２２は４ドット幅であり、以下同様に続く。
【０４８３】
図５４に示されるように、ターゲットは、カード挿入に関して回転不変性を有するように配置される。即ち、左のターゲットと右のターゲットは、１８０度回転している点を除いて同じである。左のターゲット領域１１１６において、ターゲットは、Target1から６が上端から下端へそれぞれ位置決めされるように配置される。右のターゲット領域において、ターゲットは、ターゲット番号１から６が下端から上端へ位置決めされるように配置される。ターゲット番号ｉｄは、常に、データ領域までの半分のところにある。図５４の拡大部分図は、右のターゲットが、１８０度回転している点を除いて、左のターゲットと同一である様子を明瞭に示している。
【０４８４】
図５５に示されるように、Target1１２４及び１１２５は、特に、中心が５５ドット離されてターゲット領域内に配置される。その上、Target1（１１２４）の中心から上部クロックマーク領域の第１のクロックマークドット１１２６までの距離は５５ドットであり、ターゲットの中心から下部クロックマーク領域の第１のクロックマークドット（図示せず）までの距離は５５ドットである。両方の領域の第１の黒色クロックマークは、ターゲット中心とちょうど一致して始まる（８番目のドット位置は１５ドット幅のターゲットの中心である）。
【０４８５】
図５５の略構成図には、ターゲット中心の間の距離と、上部境界／クロックマーク領域内オンTarget1（１１２４）から第１の黒色クロックマーク（１１２６）の第１のドットまでの距離が示されている。上部及び下部の両方のターゲットからクロックマークまでの距離は５５ドットであり、代替Ａｒｔｃａｒｄの両側は対称性があるため（１８０度回転しているため）、カードは、左から右へ、又は右から左へ読み出される。読み出し方向とは無関係に、方位はデータ領域からデータを抽出するため決定する必要がない。
【０４８６】
方位列
図５６に示されるように、各データブロックには２個の１ドット幅の方位列１１２７及び１１２８が存在する。一方はデータ領域の直ぐ左側にあり、他方はデータ領域の直ぐ右側にある。方位列は、代替Ａｒｔｃａｒｄリーダーに方向情報を与えるため設けられる。（左ターゲットの右にある）データ領域の左側には、単一の白色ドット列１１２７が隣接する。（右ターゲットの左にある）データ領域の右側には、単一の黒色ドット列１１２８が隣接する。ターゲットは回転不変性があるので、これらの二つのドット列によって、代替Ａｒｔｃａｒｄリーダーは、代替Ａｒｔｃａｒｄの方向、即ち、カードが正しく挿入されたか、又は逆向きに挿入されたかを決定できるようになる。代替Ａｒｔｃａｒｄの観点からは、ドットの劣化が無いと仮定すると、次の二つの可能性が存在する。即ち：
＊データ領域の左側のドット列が白色であり、データ領域の右側の列が黒色であるならば、リーダーは、カードが書き込まれたときと同じように挿入されたことを認識する；
＊データ領域の左側のドット列が黒色であり、データ領域の右側の列が白色であるならば、リーダーは、カードが後ろ向きに挿入され、データ領域がそれに応じて回転していることを認識する。リーダーは、代替Ａｒｔｃａｒｄから正しく情報を復元するため、適切な動作を選択しなければならない。
【０４８７】
データ領域
図５７に示されるように、データブロックのデータ領域は、各列が３８４ドットを含む５９５列により構成され、全部で２２８４８０ドットがある。これらのドットは、原データを得るために、解釈され、復号化される。各ドットは単一ビットを表現するので、２２８４８０ドットは２２８４８０ビット、即ち、２８５６０バイトを表現する。各ドットの解釈は以下の通りである。
【０４８８】
【表５０】
0004309954.tif 000052
しかし、ドットから得られたビットの実際の解釈は、原データから代替Ａｒｔｃａｒｄのデータ領域内のドットへのマッピングの理解が必要である。
【０４８９】
原データのデータ領域ドットへのマッピング
次に、最大サイズが９１００８２バイトの原データファイルを取得し、それを、１６００ｄｐｉ代替Ａｒｔｃａｒｄ上の６４個のデータブロックのデータ領域内のドットへマッピングするプロセスを説明する。代替Ａｒｔｃａｒｄリーダーは、代替Ａｒｔｃａｒｄ上のドットから原データを抽出するためこのプロセスを逆転するであろう。一見して、データをドットにマッピングすることは簡単なことに思われ、即ち、２値データは１と０により構成されるので、黒色ドット及び白色ドットを簡単にカードに書き込むことができるであろう。しかし、この方式は、インクがフェイドし、カードの一部がごみ、汚れ、或いは、場合によっては傷によって損なわれることを許容しない。誤り検出符号化を行わない限り、カードから取得されたデータが正確であるかどうかを検出する方法は無い。更に、冗長符号化を行わない限り、検出された誤りを正す方法はない。したがって、マッピングプロセスの目的は、データ復元を非常に確実に行い、代替Ａｒｔｃａｒｄリーダーに、データを正しく読み出したことを認識する能力を与えることである。
【０４９０】
原データファイルをデータ領域ドットへマッピングするために、以下の三つの基本的なステップが関係する：
＊原データを冗長符号化する；
＊局部的に生じた代替Ａｒｔｃａｒｄの損傷の影響を低減するため、符号化データをシ決定論的にャッフルする；
＊シャッフルされた符号化データをドットとして代替Ａｒｔｃａｒｄのデータブロックに書き込む。
【０４９１】
これらの各ステップは以下のセクションで詳細に考察される。
【０４９２】
リード・ソロモン符号化を使用する冗長符号
データの代替Ａｒｔｃａｒｄへのマッピングは、冗長符号化を利用する方法に大きく依存している。バースト誤りを取り扱い、最小限の冗長性で効率的に誤りを検出し訂正する能力を備えているリード・ソロモン符号化を選択する方が好ましい。リード・ソロモン符号化は、Ｗｉｃｋｅｒ，
Ｓ． と  Ｂｈａｒｇａｖａ，
Ｖ． による'&apos;Ｒｅｅｄ−Ｓｏｌｏｍｏｎ Ｃｏｄｅｓ ａｎｄ
ｔｈｅｉｒ Ａｐｐｌｉｃａｔｉｏｎ'&apos;，ＩＥＥＥ Ｐｒｅｓｓ， １９９４、Ｒｏｒａｂａｕｇｈ，
Ｃによる'&apos;Ｅｒｒｏｒ Ｃｏｄｉｎｇ Ｃｏｏｋｂｏｏｋ'&apos;，ＭｃＧｒａｗ−Ｈｉｌｌ，
１９９４、及びＬｙｐｐｅｎｓ， Ｈ．による'&apos;Ｒｅｅｄ−Ｓｏｌｏｍｏｎ Ｅｒｒｏｒ
Ｃｏｒｒｅｃｔｉｏｎ'&apos;，Ｄｅ． Ｄｏｂｂ'ｓ Ｊｏｕｒｎａｌ，
Ｖｏｌｕｍｅ ２２，
Ｉｓｓｕｅ １，
Ｊａｎｕａｒｙ １９９７のような標準的なテキストで適切に説明されている。
【０４９３】
リード・ソロモン符号化用の様々なパラメータを使用することが可能であり、異なるシンボルサイズ及び異なる冗長性レベルが含まれる。好ましくは、以下の符号化パラメータ、
＊ｍ＝８
＊ｔ＝６４
が使用される。
【０４９４】
ｍ＝８とすることは、シンボルサイズが８ビット（１バイト）であることを意味する。また、リード・ソロモン符号化されたブロックサイズｎは２５５バイト（２8−１シンボル）であることを意味する。最大でｔ個のシンボルの訂正を行うため、最終的なブロックサイズで２ｔ個のシンボルが冗長シンボルを用いて採用されなければならない。ｔ＝６４とすることは、誤りがある場合に、１ブロック毎に６４バイト（シンボル）を訂正可能であることを意味する。２５５バイトの各ブロックは、１２８（２×６４）冗長バイトを有し、残りの１２７バイト（ｋ＝１２７）は原データを保持するため使用される。このようにして、
＊ｎ＝２５５
＊ｋ＝１２７
である。
【０４９５】
実際の結果では、１２７バイトの原データが符号化され、２５５バイトブロックのリード・ソロモン符号化データが得られる。符号化された２５５バイトブロックは、代替Ａｒｔｃａｒｄ上に記憶され、その後、代替Ａｒｔｃａｒｄリーダーの復号化によって元の１２７バイトに戻される。データブロックのデータ領域の単一列内の３８４ドットは、４８バイト（３８４／８）を保持し得る。５９５列は２８５６０バイトを保持し得る。これは、１１２個のリード・ソロモンブロックに達する（各ブロックは２５５バイトを含む）。完全な代替Ａｒｔｃａｒｄの６４個のデータブロックは、全部で７１６８個のリード・ソロモンブロック（１リード・ソロモンブロック当たりに２５５バイトのとき、１８２７８４０バイト）を保持し得る。７１６８個のリード・ソロモンブロックのうちの２個は、制御情報のため確保されるが、残りの７１６６個はデータを記憶するため使用される。各リード・ソロモンブロックは１２７バイトの実際のデータを保持し、代替Ａｒｔｃａｒｄ上に記憶できるデータの総量は９１００８２バイト（７１６６×２７）である。原データがこの総量未満である場合、データは、正確な個数のリード・ソロモンブロックに適合させるため、符号化することができ、次に、符号化されたブロックは、７１６６個の全てが使用されるまで複製可能である。図５８は利用される符号化の全体的な形態の説明図である。
【０４９６】
２個の制御ブロック１１３２及び１１３３の各々は、残りの７１６６個のリード・ソロモンブロックを復号化するために必要な同じ符号化情報、即ち、
フルメッセージ（１６ビット格納ロー／ハイ）中のリード・ソロモンブロックの個数と、メッセージ（８ビット）の最後のリード・ソロモンブロック内のデータバイトの個数と、を収容する。
【０４９７】
これらの２個の数は、３２回繰り返され（９６バイトを消費）、残りの３１バイトは確保され、０にセットされる。各制御ブロックは、次に、リード・ソロモン符号化され、１２７バイトの制御情報は２５５バイトのリード・ソロモン符号化データに変換される。
【０４９８】
制御ブロックは、生き残る可能性を高くするため２回記憶される。その上、制御ブロック内のデータの繰り返しは、リード・ソロモン符号を使用する場合に特に重要である。間違いの無いリード・ソロモン符号化ブロックにおいて、データの最初の１２７バイトは、正しく原データであり、もし、制御ブロックが復号化に失敗したとき（６４個を超えるシンボルに誤りがあるとき）、原メッセージを復元するために参照することができる。このようにして、制御ブロックが復号化に失敗した場合、２個の復号化パラメータの最も確からしい値を決定するために、３バイトのセットを検査することができる。復元可能であることは保証されないが、冗長性によって可能性は高くなる。例えば、制御ブロックの最後の１５９バイトが破壊され、最初の９６バイトは完全に大丈夫である。最初の９６バイトを参照すると、数字の繰り返しセットが見つかる。これらの数字は、残りの７１６６個のリード・ソロモンブロックにあるメッセージの残りの部分を復号化するため巧く利用することができる。
【０４９９】
一例として、正確に９９６７バイトのデータを含むデータファイルを想定する。必要なリード・ソロモンブロックの数は７９個である。最初の７８個のリード・ソロモンブロックは完全に利用され、９９０６バイト（７８×１２７）が使用される。７９番目のブロックには、６１バイトのデータしか含まれない（残りの６６バイトは全て０である）。
【０５００】
代替Ａｒｔｃａｒｄは、７１６８個のリード・ソロモンブロックにより構成される。最初の２ブロックは制御ブロックであり、次の７９ブロックは符号化データであり、次の７９ブロックは符号化データの複製であり、次の７９ブロックは符号化データの別の複製であり、以下同様に続く。７９個のリード・ソロモンブロックを９０回記憶した後、残りの５６個のリード・ソロモンブロックは、７９ブロックの符号化データのうちの最初の５６ブロックの別の複製である（符号化データの最後の２３ブロックは、代替Ａｒｔｃａｒｄ上に十分な場所が存在しないので、これ以上記憶されない）。リード・ソロモン符号化される前の各制御ブロックデータ内の１２７バイトの１６進表現が図５９に示されている。
【０５０１】
符号化データのスクランブル処理
全ての符号化ブロックがメモリ内に隣接して格納されているならば、最大で１８２７８４０バイトのデータ（２個の制御ブロックと、７１６６個の情報ブロックとを合わせて全部で７１６８個のリード・ソロモン符号化ブロック）を代替Ａｒｔｃａｒｄ上に記憶することができる。好ましくは、データは、この段階で代替Ａｒｔｃａｒｄ上にそのまま記憶されるのではなく、即ち、１個のリード・ソロモンブロックの２５５バイトの全てがカード上で物理的に一体として記憶されるのではない。カードに物理的な破損を生じさせるごみ、汚れ、又は歪みは、一つのリード・ソロモンブロック内の６４バイト以上を破壊する可能性があり、そのブロックは復元できなくなる。リード・ソロモンブロックの複製が無い場合、代替Ａｒｔｃａｒｄの全体を復号化し得ないことになる。
【０５０２】
これに対するソリューションは、代替Ａｒｔｃａｒｄ上に多数のバイトが存在し、代替Ａｒｔｃａｒｄは合理的な物理サイズを有するという点を活かすことである。したがって、データはスクランブル処理され、一つのリード・ソロモンブロックからのシンボルが相互に接近しないことが保証される。勿論、カードが劣化する異状ケースでは、リード・ソロモンブロックを復元することは不可能であるが、平均的に、データのスクランブル処理によってカードを非常に頑強にすることができる。選択されたスクランブル方式は単純であり、図１４に概略的に示されている。リード・ソロモンブロックからのバイト０の全ては、まとめて配置され（１１３６）、次に、全てのバイト１等も同様である。したがって、７１６８個のバイト０と、７１６８個のバイト１等が存在する。代替Ａｒｔｃａｒｄ上の各データブロックは２８５６０バイトを記憶することができる。この結果として、代替Ａｒｔｃａｒｄ上の６４個のデータブロックの各々に、各リード・ソロモンブロックからの約４バイトが収容される。
【０５０３】
このスクランブル方式の下では、代替Ａｒｔｃａｒｄ上の１６個のデータブロック全体に対する完全なダメージによって、１リード・ソロモンブロック毎に６４個のシンボル誤りが生じる。即ち、代替Ａｒｔｃａｒｄにその他のダメージが無い場合、たとえデータの複製が無くても、全てのデータは完全に復元可能である。
【０５０４】
スクランブル処理された符号化データを代替Ａｒｔｃａｒｄへ書き込み
原データがリード・ソロモン符号化され、複製され、スクランブル処理されると、１８２７８４０バイトのデータを代替Ａｒｔｃａｒｄに記憶する必要がある。代替Ａｒｔｃａｒｄ上の６４個のデータブロックの各々は、２８５６０バイトを記憶する。
【０５０５】
データは、単純に代替Ａｒｔｃａｒｄのデータブロックへ書き出されるので、第１のデータブロックはスクランブル付きデータのうちの最初の２８５６０バイトを格納し、第２のデータブロックは次の２８５６０バイトを格納し、以下同様に続く。
【０５０６】
図６１に示されるように、データブロック内で、データは列に関して左から右へ書き込まれる。このため、データブロック内の最も左側の列は、２８５６０バイトのスクランブル付きデータのうちの最初の４８バイトを格納し、最後の列は、２８５６０バイトのスクランブル付きデータのうちの最後の４８バイトを格納する。列内では、バイトは、ビット７から始めて、同時に１ビットずつ、上から下へ書き込まれ、ビット０で終了する。ビットがセット（１）されている場合、黒色ドットが代替Ａｒｔｃａｒｄに配置され、ビットがクリア（０）されている場合、ドットは配置されず、カードの白色背景カラーのまま残される。
【０５０７】
例えば、１８２７８４０バイトのデータの組は、代替Ａｒｔｃａｒｄに記憶されるべき７１６８個のリード・ソロモン符号化ブロックをスクランブル処理することによって作成できる。最初の２８５６０バイトのデータは最初のデータブロックに書き込まれる。最初の２８５６０バイトのうちの最初の４８バイトはデータブロックの最初の列に書き込まれ、次の４８バイトは次の列に書き込まれ、以下同様に続く。２８５６０バイトのうちの最初の２バイトが１６進のＤ３ 
５Ｆである場合を想定する。バイト０のビット７が最初に格納され、次にビット６が格納され、以下同様に続く。次に、バイト１のビット７からバイト１のビット０までが格納される。各「１」は黒色ドットとして格納され、各「０」は白色ドットして格納されるので、これらの２バイトは、代替Ａｒｔｃａｒｄ上では、以下のドットの組として表現され、
＊D3(1101 0011)は、黒、黒、白、黒、白、白、黒、黒になり、
＊5F(0101 1111)は、白、黒、白、黒、黒、黒、黒、黒になる。
【０５０８】
代替Ａｒｔｃａｒｄの復号化
このセクションは、代替Ａｒｔｃａｒｄから正確かつ確実な形で原データを抽出する処理を取り扱う。特に、前の章で説明した代替Ａｒｔｃａｒｄのフォーマットを前提として、代替Ａｒｔｃａｒｄから元の予め符号化されたデータを抽出する方法を説明する。
【０５０９】
代替Ａｒｔｃａｒｄを復号化する前提の一部として多数の一般的な考察が存在する。
【０５１０】
ユーザ
代替Ａｒｔｃａｒｄの目的は、様々なアプリケーションで使用するためのデータを保存することである。ユーザは、代替Ａｒｔｃａｒｄを代替Ａｒｔｃａｒｄリーダーに挿入し、データが「妥当な時間」内にロードされることを期待する。ユーザの観点からは、モーター輸送が代替Ａｒｔｃａｒｄを代替Ａｒｔｃａｒｄリーダーへ動かす。これは、問題となる遅れとしては認識されない。なぜならば、代替Ａｒｔｃａｒｄは動いているからである。代替Ａｒｔｃａｒｄが停止した後の時間は遅延として認識され、代替Ａｒｔｃａｒｄ読み出し方式において最低限に短縮されるべきである。理想的な状態では、代替Ａｒｔｃａｒｄの全体が移動中に読み出され、これにより、カードの移動が停止した後に遅延が認識されない。
【０５１１】
好適な実施例の目的のため、代替Ａｒｔｃａｒｄを物理的にロードするための妥当な時間は１．５秒に決める。代替Ａｒｔｃａｒｄの移動が停止した後の付加的な復号化のための時間を最低限に短縮すべきである。代替Ａｒｔｃａｒｄのアクティブ領域は代替Ａｒｔｃａｒｄの表面の大部分を覆うので、時間的な関心をその領域に限定することができる。
【０５１２】
ドットのサンプリング
代替Ａｒｔｃａｒｄ上のドットは、ナイキストの定理（Ｎｙｇｕｉｓｔ‘ｓ
Ｔｈｅｏｒｅｍ）を充たすため、少なくとも印刷された解像度の２倍でＣＣＤリーダー等によってサンプリングしなければならない。実際には、これよりも高いレートでサンプリングする方がよい。代替Ａｒｔｃａｒｄリーダーの環境では、ドットは、好ましくは、各次元に関してドットが印刷された解像度、即ち、単一ドットを定義するために９画素を必要とする解像度の３倍の解像度でサンプリングされる。代替Ａｒｔｃａｒｄのドットの解像度が１６００ｄｐｉである場合、代替Ａｒｔｃａｒｄリーダーのイメージセンサは、４８００ｄｐｉで画素を走査しなければならない。勿論、ドットがイメージセンサと正確に位置合わせされていない場合、図６２に示されるような最悪の最も起こり易いケースでは、ドットは４×４画素エリアに亘って検出されるであろう。
【０５１３】
サンプリングされる各画素は１バイト（８ビット）である。各画素の下位２ビットは、有意なノイズを含む可能性がある。したがって、復号化アルゴリズムは、耐ノイズ性が要求される。
【０５１４】
位置合わせ／回転
ユーザが代替Ａｒｔｃａｒｄを回転なしに完全に位置合わせされた状態で代替Ａｒｔｃａｒｄリーダーに挿入する可能性は極めて低い。リーダーの入口及びモーター輸送のグリップにおけるある種の物理的制約は、挿入された後、代替ＡｒｔｃａｒｄがＣＣＤに対して挿入時の最初の角度で保たれることを保証する。好ましくは、この回転角度は、図６３に示されるように最大で１度である。読み出しプロセス中にジッタ及びモーターのガタによって角度が僅かに外れる可能性はあるが、基本的に１度の限界内に収まると考えられる。
【０５１５】
代替Ａｒｔｃａｒｄの物理的寸法は８６ｍｍ×５５ｍｍである。１度の回転は、８６ｍｍがＣＣＤの下を通過したとき、カードの実効高さを１．５ｍｍ（８６ｓｉｎ１°）だけ長くするので、必要なＣＣＤ長に影響を与える。
【０５１６】
代替Ａｒｔｃａｒｄの読み出しに対する１度の回転の影響は、ＣＣＤからの１本の走査線が代替Ａｒｔｃａｒｄからの多数の異なるドット列を含むことである。これは、画素の列に対するドットのドリフトを表した図６３に拡大された形態で示されている。同図では誇張されているが、実際のドリフトは、５７画素毎に最大で１画素列になる。
【０５１７】
代替Ａｒｔｃａｒｄが回転していないとき、単一のドット列は３本の画素走査線によって読むことができる。代替Ａｒｔｃａｒｄの回転が大きくなると、局部的な影響が増加する。読み出されるドットの数が増加すると、回転の影響が加わる時間が長くなる。これらの要因のうちのいずれかが増大すると、代替Ａｒｔｃａｒｄ上の単一列から所定のドットの組を得るために読み出す必要がある画素走査線の数が増加する。以下の表は、特定の代替Ａｒｔｃａｒｄ構造において単一のドット列のために必要な画素走査線の本数を示している。
【０５１８】
【表５１】
0004309954.tif 000053
代替Ａｒｔｃａｒｄの全体を読むため、８７ｍｍ（８６ｍｍと１°の回転による１ｍｍの和）を読む必要がある。４８００ｄｐｉの場合、これは、１６２５２列の画素列に相当する。
【０５１９】
ＣＣＤ（又はその他のリニアイメージセンサ）の長さ
ＣＣＤ自体の長さは、
−代替Ａｒｔｃａｒｄの物理的高さ（５５ｍｍ）
−物理的な代替Ａｒｔｃａｒｄの挿入時の垂直方向動き（１ｍｍ）
−最大１°の挿入時回転（８６ｓｉｎ１°＝１．５ｍｍ）
に適合しなければならない。
【０５２０】
これらの要因を組み合わせると、全体の長さは５７．５ｍｍになる。
【０５２１】
代替Ａｒｔｃａｒｄリーダーの代替ＡｒｔｃａｒｄイメージセンサＣＣＤが４８００ｄｐｉで走査するとき、１本の走査線は１０８６６画素である。簡単のため、この数字を１１０００画素に切り上げる。代替Ａｒｔｃａｒｄのアクティブ領域の高さは３２０８ドット、即ち、９６２４画素である。データ領域の高さは３８４ドット、即ち、１１５２画素である。
【０５２２】
ＤＲＡＭサイズ
代替Ａｒｔｃａｒｄの読み出し及び復号化に必要なメモリ量は、理想的には最低限に削減される。典型的な代替Ａｒｔｃａｒｄリーダーの配置は、内蔵型システムであり、その場合、メモリリソースは貴重である。このことは、回転の影響によって更に重大な問題になる。上述の通り、代替Ａｒｔｃａｒｄの回転が大きくなると、原ドットを効率的に復元するために要する走査線の数が増加する。
【０５２３】
アルゴリズムの複雑さと、ユーザの認知する遅延と、頑強性と、メモリ使用量との間にはトレードオフがある。最も簡単なリーダーアルゴリズムの一つは、単に代替Ａｒｔｃａｒｄの全体を走査し、次に、リアルタイムの制約無しに全データを処理することであろう。これは、大規模のメモリ容量を必要とするだけではなく、代替Ａｒｔｃａｒｄの読み出しプロセスと並行に行われるリーダーアルゴリズムよりも長時間を要するであろう。
【０５２４】
代替Ａｒｔｃａｒｄの読み出し及び復号化のために実際に必要なメモリ量は、符号化されたデータを、少量のスクラッチ空間（１から２ＫＢ）と共に保持するために必要なスペースの量の２倍である。１６００ｄｐｉの代替Ａｒｔｃａｒｄの場合、これは、４ＭＢのメモリ必要量を意味する。実際のメモリ使用量は以下のアルゴリズムの説明で詳述される。
【０５２５】
転送レート
ＤＲＡＭ帯域幅の前提条件は、タイミングを考慮するために行う必要があり、特に、代替Ａｒｔｃａｒｄリーダーは、典型的に、内蔵型システムの一部であるので、アルゴリズム設計にある程度の影響を与える。
【０５２６】
Ｒａｍｂｕｓ Ｉｎｃの'&apos;Ｄｉｒｅｃｔ Ｒａｍｂｕｓ 
Ｔｅｃｈｎｏｌｏｇｙ Ｄｉｓｃｌｏｓｕｒｅ'&apos;， Ｏｃｔ １９９７に記載されているような標準的なＲａｍｂｕｓ 
Ｄｉｒｅｃｔ（ラムバスダイレクト）ＲＤＲＡＭアーキテクチャが想定され、ピークデータ転送レートは１．６ＧＢ／秒である。７５％の効率（容易に実現できる）を想定すると、平均で１．２ＧＢ／秒のデータ転送レートが得られる。したがって、１６バイトのブロックにアクセスするために要する平均時間は１２ｎｓである。
【０５２７】
汚染データ
物理的に破損した代替Ａｒｔｃａｒｄがリーダーに挿入されることがあり得る。代替Ａｒｔｃａｒｄは、傷を付けられるか、汚れ若しくはごみによって歪みを生じるかもしれない。代替Ａｒｔｃａｒｄリーダーが全てを完全に読み出すことは想定できない。汚染データの影響は、ブラー効果によって更に悪化させられる。なぜならば、汚染データが周囲のきれいなドットに影響を与えるからである。
【０５２８】
ブラー効果環境
ブラー効果は、次の２種類の経路で代替Ａｒｔｃａｒｄ読み取り環境に組み込まれる：＊代替ＡｒｔｃａｒｄからＣＣＤ間での距離の特性を原因とする自然的なブラー効果；
＊代替Ａｒｔｃａｒｄの歪み。
【０５２９】
代替Ａｒｔｃａｒｄ像の自然的なブラー効果は、ＣＣＤから検出されたデータのオーバーラップが存在するときに生じる。ブラー効果は役に立つ場合がある。なぜならば、ブラー効果は、検出データに高周波数が存在しないこと、及びＣＣＤによって失われたデータが存在しないことを保証するからである。しかし、ＣＣＤ画素によって覆われたエリアが非常に広い場合、非常に多くのブラー効果が現れ、データを復元するために要するサンプリングの条件が充たされない。図６４は検出データの重なり合いの略説明図である。
【０５３０】
別の形態のブラー効果は、代替Ａｒｔｃａｒｄが熱ダメージのために僅かに歪むときに生じる。垂直方向の次元に歪みがあるとき、代替ＡｒｔｃａｒｄとＣＣＤの間の距離は一定ではなく、ブラー効果のレベルはそのエリアの中で変化する。
【０５３１】
黒色ドット及び白色ドットは、代替Ａｒｔｃａｒｄがブラー効果のある読み出し環境で最良のダイナミックレンジを与えるように選択された。ブラー効果は、所与のドットが黒色であるか、又は白色であるかを決定するときに問題を生じる。
【０５３２】
ブラー効果が増大すると、所与のドットは周辺ドットから受ける影響が大きくなる。その結果として、特定のドットのダイナミックレンジは減少する。白色ドット及び黒色ドットの各々が起こり得るあらゆるドットの組によって囲まれる場合を考える。９個のドットにブラー効果が現れ、中央ドットがサンプリングされる。図６５は、黒色ドット及び白色ドットに対して得られた中央ドット値の分布の説明図である。
【０５３３】
この図は、典型的なブラー効果を意図している。０から約１８０までの曲線１１４０は黒色ドットのレンジを示す。７５から２５０までの曲線１１４１は白色ドットのレンジを示す。しかし、ブラー効果が大きくなると、２本の曲線はレンジの中央の方へ向かってシフトし、交わるエリアが増大し、所与のドットが黒色であるか、白色であるかを判定することがより困難になる。交わりの中心点での画素値は曖昧であり、ドットが黒色である可能性と白色である可能性は等しい。
【０５３４】
ブラー効果が増大すると、読み出しビット誤りの確率が増加する。都合良く、リード・ソロモン復号化アルゴリズムは、ｔ個のシンボル誤りまで正常にこれらに対処することができる。図６５は、特定のシンボル誤り率の場合に復元できない代替Ａｒｔｃａｒｄのリード・ソロモンブロックの予測数のグラフである。リード・ソロモン復号化方式が優れた性能を示し、次に、実質的に低下することに注意すべきである。リード・ソロモンブロックの複製が無い場合、１ブロックに誤りが生じるだけでデータを復元できなくなる。勿論、ブロック複製を行った場合、代替Ａｒｔｃａｒｄ復号化の機会が増加する。
【０５３５】
図６６は、誤りのあるリード・ソロモンブロックの個数に対応するシンボル（バイト）誤りだけを示している。対処可能なブラー効果の量と、カードに生じたダメージの量との間にはトレードオフが存在する。全ての誤り検出及び訂正はリード・ソロモンデコーダによって行われるので、リード・ソロモンデータブロック毎に対処可能な誤りの個数は有限である。ブラー効果によって取り込まれる誤りが増加すると、代替Ａｒｔｃａｒｄのダメージによる誤りの中で対処可能な誤りの個数は減少する。
【０５３６】
代替Ａｒｔｃａｒｄ復号化の概要
上述の通り、ユーザが代替Ａｒｔｃａｒｄを代替Ａｒｔｃａｒｄ読み取りユニットに挿入するとき、モーター輸送は、理想的には、代替Ａｒｔｃａｒｄを運び、モノクロリニアＣＣＤイメージセンサの傍らを通過させる。カードは次元毎に印刷された解像度の３倍の解像度でサンプリングされる。代替Ａｒｔｃａｒｄ読み取りハードウェア及びソフトウェアは、１度までの回転と、モーター輸送によって生じるジッタ及び振動と、代替ＡｒｔｃａｒｄからＣＣＤまでの距離の変動によって生じるブラー効果を補正する。データのデジタルビットイメージが、以下に説明される複雑な方法によって、サンプリングされた像から抽出される。リード・ソロモン復号化は、代替Ａｒｔｃａｒｄ上の生データの２５％までの任意に分布したデータコラプションを訂正する。約１ＭＢの訂正データが１６００ｄｐｉカードから抽出される。
【０５３７】
復号化に関連するステップは図６７に示されるようなステップである。
【０５３８】
復号化プロセスに必要なステップは、
＊印刷された解像度の３倍の解像度で代替Ａｒｔｃａｒｄを走査する（例えば、４８００ｄｐｉで１６００ｄｐｉの代替Ａｒｔｃａｒｄを走査する）ステップ１１４４と、
＊カード上で走査されたドットからデータビットマップを抽出するステップ１１４５と、
＊代替Ａｒｔｃａｒｄが逆向きに挿入された場合に、ビットマップを反転するステップ１１４６と、
＊符号化データをスクランブル解除するステップ１１４７と、
＊ビットマップからのデータをリード・ソロモン復号化するステップ１１４８と、
である。
【０５３９】
アルゴリズムの概要
フェーズ１−リアルタイムExtractingBitImage
利用可能なメモリ（４ＭＢ）と、１６００ｄｐｉの代替Ａｒｔｃａｒｄの走査された全画素を保持するための必要メモリ（１７２．５ＭＢ）との簡単な比較によって、カードが複数回読み出されない限り（現実的な選択肢ではない）、画素データからのビットマップの抽出は、代替ＡｒｔｃａｒｄがＣＣＤの傍を通過させられる間に、オンザフライ方式でリアルタイムに実行する必要がある。このフェーズでは、二つのタスク、即ち、
＊代替Ａｒｔｃａｒｄを４８００ｄｐｉで走査するタスク
＊カード上で走査されたドットからデータビットマップを抽出するタスク
を実行しなければならない。
【０５４０】
ビットイメージの回転及びスクランブル解除は、ビットイメージ全体が抽出されるまで行えない。したがって、抽出されたビットイメージを保持するためにメモリ領域を割り当てることが必要である。ビットイメージは、２ＭＢの範囲内で容易に収容され、抽出プロセスで使用するための２ＭＢが確保される。
【０５４１】
ＣＣＤからの現在の走査線だけを調べる間にビットイメージを抽出するのではなく、窓として機能するバッファを代替Ａｒｔｃａｒｄに割り付け、最新のＮ本の走査線読み出しを記憶することが可能である。メモリ必要量は、代替Ａｒｔｃａｒｄの全体がこのようにして記憶されることは許容しないが（１７２．５ＭＢが必要になるであろう）、１９０画素列を記憶するため２ＭＢを割り付けることは（各走査線は１１０００バイト以上を必要としない）、ExtractingBitImageプロセスを簡単化させる。
【０５４２】
したがって、４ＭＢメモリの使用法は以下の通りである：
＊抽出されたビットイメージのための２ＭＢ；
＊走査された画素のための〜２ＭＢ；
＊フェーズ１のスクラッチデータのために１．５ＫＢ（アルゴリズムによる要求次第）。
【０５４３】
フェーズ１に要する時間は１．５秒である。なぜならば、この時間は、代替ＡｒｔｃａｒｄがＣＣＤの傍を通過し、物理的にロードされるために要する時間であるからである。
【０５４４】
フェーズ２−ビットイメージからのデータ抽出
ビットイメージが抽出されると、ビットイメージはスクランブル解除され、場合によっては１８０°回転させることが必要である。ビットイメージは次に復号化される。フェーズ２は、Ａｒｔｃａｒｄの動きが停止している点でリアルタイム必要条件が無く、ユーザが時間経過を認識することだけが問題である。したがって、フェーズ２は、代替Ａｒｔｃａｒｄを復号化する残りのタスクに関係する。即ち、
＊ビットイメージを再編成し、代替Ａｒｔｃａｒｄが逆向きに挿入された場合には反転する；
＊符号化されたデータをスクランブル解除する；
＊ビットイメージからのデータをリード・ソロモン復号化する。
【０５４５】
フェーズ２への入力は２ＭＢビットイメージバッファである。スクランブル解除及び回転は、その場では実行し得ないので、第２の２ＭＢバッファが必要である。フェーズ１で走査された画素を保持するため使用される２ＭＢバッファは不要になっているので、回転させられたスクランブル無しデータを記憶するため使用可能である。
【０５４６】
リード・ソロモン復号化タスクは、スクランブル無しのビットイメージを取得し、それを９１００８２バイトに復号化する。復号化は元の位置で実行可能であるが、指定された別の場所で実行してもよい。復号化プロセスは、補助的なメモリバッファを必要としない。
【０５４７】
したがって、４ＭＢのメモリの使用法は以下の通りである：
＊（フェーズ１からの）抽出されたビットイメージのための２ＭＢ；
＊スクランブル無しの、回転された可能性のあるビットイメージのための〜２ＭＢ；
＊フェーズ２のスクラッチデータのための＜１ＫＢ（アルゴリズムによる要求次第）。
【０５４８】
フェーズ２に要する時間はハードウェアに依存し、リード・ソロモン復号化のために要する時間によって制限される。ＬＳＩロジックのL64712のような専用コア、又は等価的なＣＰＵ／ＤＳＰの組み合わせを使用することにより、フェーズ２は０．３２秒を要することが推定される。
【０５４９】
フェーズ１−ExtractingBitImage
これは、アルゴリズムのリアルタイムフェーズであり、ＣＣＤによって走査されたような代替Ａｒｔｃａｒｄからビットイメージを抽出することに関連する。
【０５５０】
図６８に示されるように、フェーズ１は、二つの非同期的なプロセスストリームに分解することができる。そのうちの第１のストリームは、単に、ＣＣＤからの代替Ａｒｔｃａｒｄの画素をリアルタイムで読み出し、その画素をＤＲＡＭへ書き込む。第２のストリームは、画素を参照し、ビットを抽出する。第２のプロセスストリームは、それ自体が二つのプロセスに分解される。第１のプロセスは、大域的なプロセスであり、代替Ａｒｔｃａｒｄのスタートの位置検出に関する。第２のフェーズはExtractingBitImage固有である。
【０５５１】
図６９は、データ／プロセスの観点からのデータフロー説明図である。
【０５５２】
タイミング
１６００ｄｐｉ代替Ａｒｔｃａｒｄの全体に対して、最大で１６２５２画素列を読み出すことが必要である。代替Ａｒｔｃａｒｄの全体に対する合計時間が１．５秒である場合、これは、様々なプロセスの経過中に、１画素列当たりの最大時間が９２２９６ｎｓであることを意味する。
【０５５３】
プロセス１−ＣＣＤからの画素読み出し
ＣＣＤは、代替Ａｒｔｃａｒｄを４８００ｄｐｉで走査し、１列当たりに１１０００個の１バイト画素を生成する。このプロセスは、ＣＣＤからデータを取得し、それをＤＲＡＭへ書き込むだけであり、ＤＲＡＭから画素データを読み出している他のプロセスからは完全に独立している。図７０には関連したステップが示されている。
【０５５４】
画素は、１９０列の全画素列を保持し得る２ＭＢバッファに連続して書き込まれる。バッファは、常に、最近に読み出された１９０列を保持する。その結果として、画素データを読み出そうとするプロセス（例えば、プロセス２及びプロセス３）は、最初に、所定の列が探索する場所を知る必要があり、次に、要求されたデータが実際にバッファ内に存在することが確実であるように十分に高速でなければならない。
【０５５５】
プロセス１は、現在のCurrentScanLineが他のプロセスから利用できるようにさせるので、他のプロセスは、未だ読み出されていない走査線からの画素へのアクセスを試みないことを保証することができる。
【０５５６】
単一のデータ列（１１０００バイト）をＤＲＡＭへ書き出すために要する時間は、１１０００／１６＊１２＝８２５６ｎｓである。
【０５５７】
プロセス１は、したがって、利用可能なＤＲＡＭ帯域幅の９％未満（８２５６／９２２９６）しか使用しない。
【０５５８】
プロセス２−代替Ａｒｔｃａｒｄのスタート検出
このプロセスは、走査された代替Ａｒｔｃａｒｄ上のアクティブエリアの位置検出と関連している。このステージへの入力はＤＲＡＭ（プロセス１によってそこに収容された）からの画素データである。出力は、代替Ａｒｔｃａｒｄ上の最初の８個のデータブロックに対する境界の組であり、プロセス３への入力として要求される。プロセス３の上位レベル概要が図７１に示されている。
【０５５９】
代替Ａｒｔｃａｒｄは、挿入時に垂直方向の動きが１ｍｍある。１度の回転によって、更に、１．５ｍｍ（８６ｓｉｎ１°）の垂直方向の動きが生じる。その結果として、全部で垂直方向の動きは２．５ｍｍである。１６００ｄｐｉのとき、これは、約１６０ドットの動きに相当する。単一のデータブロックの高さは３９４ドットに過ぎないので、この動きは、データブロックの半分よりも少し少ない。データブロックが存在する場所をより良く推定するためには、代替Ａｒｔｃａｒｄ自体を検出しなければならない。
【０５６０】
したがって、プロセス２は、
＊代替Ａｒｔｃａｒｄのスタートを位置検出する部分と、もし、検出されたならば、
＊代替Ａｒｔｃａｒｄのスタートに基づいて最初の８個のデータブロックの境界を計算する部分と、
を含む。
【０５６１】
代替Ａｒｔｃａｒｄのスタート位置検出
代替Ａｒｔｃａｒｄエリアの外側で走査された画素は黒色である（表面は黒色のプラスチック、又はその他の非反射型表面でもよい）。代替Ａｒｔｃａｒｄエリアの境界は白色である。画素列を１列ずつ処理し、画素を黒色又は白色の何れかに関してフィルタ処理するならば、黒色から白色への変化点は、代替Ａｒｔｃａｒｄ上のスタートを特徴付ける。最高レベルのプロセスは以下の通りである：
0004309954.tif 000054
ProcessColumn関数は単純である。走査された列の二つのエリアからの画素は、それらが黒色又は白色のどちらであるかを判定するため閾値フィルタに通される。一定数の白色画素を待ち、所定の個数が検出されたとき、代替Ａｒｔｃａｒｄのスタートを報せることが可能である。画素列を処理するロジックは以下の疑似コードに示されている。列中に代替Ａｒｔｃａｒｄが検出されなかった場合、０が返される。さもなければ、検出された位置の画素数が返される：
0004309954.tif 000055
データブロック境界の計算
このステージでは、代替Ａｒｔｃａｒｄが検出されている。代替Ａｒｔｃａｒｄの回転に応じて、代替Ａｒｔｃａｒｄの上部又は代替Ａｒｔｃａｒｄの下部の何れかが検出されている。プロセス２の第２ステップはどちらが検出されたかを判定し、フェーズ３のためのデータブロック境界を適切にセットする。
【０５６２】
フェーズ３を見ると、フェーズ３はデータブロックセグメント境界に関して動作することがわかる。各データブロックは、データブロックのデータ領域を位置検出するためにターゲットを探索すべき場所を決定するため、StartPixel及びEndPixelを含む。
【０５６３】
画素値がカードの上半分に存在する場合、それを第１のStartPixel境界としてそのまま使用することができる。画素値がカードの下半分に存在する場合、画素値が最後のセグメントのEndPixel境界になるように逆行させることが可能である。代替Ａｒｔｃａｒｄのデータサイズの幅で前進又は後退し、各セグメントに適切な境界をセットする。これにより、代替Ａｒｔｃａｒｄからのデータ抽出を開始する準備が整う：
0004309954.tif 000056
MaxPixel値はプロセス３で定義され、SetBounds関数は、0及びMaxPixelに対するStartPixel及びEndPixelクリッピングをセットするだけである。
【０５６４】
プロセス３−画素からのビットデータ抽出
これは代替Ａｒｔｃａｒｄリーダーアルゴリズムの心臓部である。このプロセスは、ＣＣＤ画素データからのビットデータ抽出処理に関係する。このプロセスは、本質的に、プロセス２によって作成され、プロセス３によって維持されたスクラッチ情報に基づいて、画素データからビットイメージを作成する。このプロセスの上位レベル概要は図７２に示されている。
【０５６５】
単に代替Ａｒｔｃａｒｄの画素列を読み出し、どの画素がどのデータブロックに属しているかを判定するのではなく、プロセス３は、その逆の作用をする。プロセス３は、所定のデータブロックの画素を探索すべき場所がわかっている。プロセス３は、これを行うため、論理的な代替Ａｒｔｃａｒｄを８個のセグメントに分割する。各セグメントは、図７３に示されるように８個のデータブロックを含む。
【０５６６】
図示されたセグメントは論理的な代替Ａｒｔｃａｒｄと一致する。物理的に、代替Ａｒｔｃａｒｄはある量だけ回転させられている可能性が高い。セグメントは、論理的な代替Ａｒｔｃａｒｄ構造に固定されたままであるため、回転に依存しない。あるセグメントは、以下の２状態のうちの一方をとり得る：
＊LookingForTaregets：この状態では、このセグメントの正確なデータブロック位置は未だ決定されていない。ターゲットは、セグメント境界によって指定された境界内の画素列データを走査することによって位置検出されている。ターゲット、並びに、黒色及び白色のためにセットされた境界を用いてデータブロックが位置検出されると、状態は、ExtractingBitImageへ変化する；
＊ExtractingBitImage：この状態では、データブロックは正確に位置検出されており、データビットは同時に１ドット列ずつ抽出され、代替Ａｒｔｃａｒｄビットイメージに書き込まれる。データブロッククロックマークの追跡は、回転とは無関係に正確なドット復元を与えるので、セグメント境界は無視される。データブロック全体が抽出されると、新しいセグメント境界が、現在位置に基づいて次のデータブロックに対して計算される。状態は、LookingForTargetsへ変化する。
【０５６７】
このプロセスは、各領域から８個ずつの６４データブロックの全てが抽出されたときに終了する。
【０５６８】
各データブロックは５９５のデータ列により構成され、各データ列は４８バイトである。好ましくは、データブロック用の２個の方位列がそれぞれ４８バイト毎に抽出され、全部で１データブロック当たりに２８６５６バイトが抽出される。簡単のため、２ＭＢのメモリを６４×３２Ｋのチャンクに分割することができる。所定のセグメントのｎ番目のデータブロックは、
SrartBuffer + (256k*n)
で表される場所に格納される。
【０５６９】
セグメントのデータ構造
８個のセグメントの各々は、データ構造が関連付けられる。各セグメントを定義するデータ構造は、スクラッチデータエリアに格納される。その構造は以下の表に列挙することができる。
【０５７０】
【表５２】
0004309954.tif 000057
プロセス３の上位レベル
プロセス３は、各セグメントに対して繰り返して、セグメントの現在状態に依存して単一ラインの処理を実行するだけである。擬似コードは以下のように簡潔である：
0004309954.tif 000058
プロセス３は、指定された時間が経過しても終了しない場合には、外部制御プロセスによって停止される必要がある。これは、データが抽出できなかった場合に限られるであろう。簡単な仕組みは、プロセス１が代替Ａｒｔｃａｒｄの読み出しを終了した後にカウントダウンを開始する仕組みである。プロセス３がその時間までに終了しなかった場合、代替Ａｒｔｃａｒｄからのデータは復元不可能である。
【０５７１】
CurrentState ＝LookingForTargets
ターゲットは、同時に１画素列ずつ画素の列を読み出すことによって検出されるのであって、（StartPixelとEndPixelの間にある）所定の画素のバンド内のドットを検出することによって画素のある種のパターンが検出されるのではない。画素列は、全てのターゲットが検出されるか、又は指定された数の列が処理されるまで、同時に１列ずつ処理される。その時点で、ターゲットを処理することが可能であり、データはクロックマークを用いて位置検出される。状態は、データを抽出する時であることを示すためExtractingBitImageに変更される。十分な数の有効ターゲットを位置検出できなかった場合、データブロックは無視され、失敗したデータブロック内の列を確実にスキップし、次のデータブロック内でターゲットを探索するプロセスを再開する。これは以下の擬似コードで表すことができる：
0004309954.tif 000059
ProcessPixelColumn関数
各画素列は、ターゲットを識別するある種の画素のパターンを探索するため、指定された境界内（StartPixelとEndPixelの間）で処理される。単一ターゲット（ターゲット番号２）の構造は、既に図５４に示されている通りである。
【０５７２】
画素の観点から、ターゲットは、以下の事項によって識別することができる：
＊左の黒色領域：これは、多数の隣接した黒色画素により構成された多数の画素列であり、ターゲットの最初の部分を構築する；
＊ターゲット中心：これは、更なる黒色列の中心にある白色領域である；
＊ターゲット番号：これは、黒色で囲まれた白色領域であり、白色領域はその長さによってターゲット番号を定義する；
＊第３の黒色領域：これは、ターゲット番号の後の二つの黒色ドット領域である。
【０５７３】
要求されるプロセスの概要は図７４に示されている。
【０５７４】
識別は黒色又は白色画素だけに基づいているので、各列からの画素１１５０は、黒色又は白色を検出するためフィルタ１１５１を通され、次に、ランレングス符号化１１５２される。ランレングスは、次に、状態機械１１５３へ送られ、状態機械は、最後の３個のランレングスと、最後から４番目の色を取得する。これらの値に基づいて、ターゲット候補は、識別ステージの各々を通過する。
【０５７５】
最大及び最小収集プロセスGatherMin&Max１１５５は、セグメントの処理中に見つかった最小値及び最大値を保持するだけである。これらは、ターゲットが位置検出されたとき、BlackMax、WhiteMin、及びMidRange値をセットするため使用される。
【０５７６】
各セグメントは、ターゲットの探索においてターゲット構造体の組を保持する。ターゲット構造体自体はメモリ内を動き回らないが、幾つかのセグメント変数はこれらのターゲット構造体へのポインタのリストを指示する。これらの３個のポインタリストを再度示す。
【０５７７】
【表５３】
0004309954.tif 000060
これらのリストポインタの各々と関連したカウンタ、即ち、TargetsFound、PossibleTargetCount、及びAvailableTargetCountが存在する。
【０５７８】
代替Ａｒｔｃａｒｄがロードされる前に、TargetsFound及びPossibleTargetCountは０にセットされ、AvailableTargetCountは２８（ターゲット境界の最小サイズは４０画素であり、データエリアは約１１５２画素であるので、調査中のターゲット構造体候補の最大数）にセットされる。ターゲットポインタレイアウトの一例は図７５に示される。
【０５７９】
新しいターゲット候補が検出されるとき、それらは、AvailableTargetsリスト１１５７から取得され、ターゲットデータ構造体は更新され、この構造体へのポインタはPossibleTargetsリスト１１５８に追加される。ターゲットが完全に検証されたとき、そのターゲットはLocatedTargetsリスト１１５９へ追加される。ターゲット候補が最終的にターゲットではないことが判明した場合、ターゲット候補はAvailableTargetsリスト１１５７へ戻される。この結果として、いつでも循環している２８個のターゲットポインタが常に存在し、リストの間を移動している。
【０５８０】
ターゲットデータ構造体１１６０は以下の形式をとり得る。
【０５８１】
【表５４】
0004309954.tif 000061
ターゲット検出モジュール１１６２（図７４）内のProcessPixelColumn関数は、全てのランレングスを一つずつ調べ、（StartPixelによって）ランを既存のターゲット候補と比較するか、又は今までに知られていないターゲット候補が検出された場合に、新しいターゲット候補を作成する。全てのケースにおいて、比較はS0.colorが白色であり、S1.colorが黒色である場合に限り行われる。
【０５８２】
次に、ProcessPixelColumnの擬似コードを示す。第１のターゲットが肯定的に識別された場合、ターゲットをチェックすべき最後の列は、そこから最大距離の範囲内にあるとして決定される。１°の回転がある場合、最大距離は１８画素列である：
0004309954.tif 000062
0004309954.tif 000063
AddToTargetはターゲット検出モジュール内の関数であり、特定のランを所与のターゲットに加算することができるかどうかを判定する：
＊ランがターゲットの開始位置の許容範囲内に入るならば、そのランは現在のターゲットと直接的に関連付けられるので、それに適用することが可能である；
＊ランがターゲットの前で始まる場合、既存のターゲットが依然としてOKであり、そのランとは関係がないと想定する。したがって、ターゲットはそのままの状態で残され、返値FALSEは、ランが適用されなかったことを呼び出し元へ通知する。呼び出し元は、引き続いてランをチェックして、ランがその固有の全く新しいターゲットを開始するかどうかを調べる；
＊ランがターゲットの後で始まる場合、そのターゲットが候補ターゲットではなくなったと考える。状態は、NotATargetに変更され、返値TRUEが返される；
ランをターゲットに適用すべき場合、特別の動作が現在の状態と、S1、S2及びS3のランの組に基づいて実行される。AddToTargetの擬似コードは以下の通りである：
0004309954.tif 000064
画素ランのタイプはDeterminRunTypeにおいて以下のように識別される。
【０５８３】
【表５５】
0004309954.tif 000065
状態推定手続EvaluateStateは現在の状態及びランタイプに依存して動作する。
【０５８４】
その動作は以下に表形式で示される。
【０５８５】
【表５６】
0004309954.tif 000066
ターゲット処理
位置検出されたターゲット（LocatedTargetsリスト内）は、位置検出された順序で記憶される。代替Ａｒｔｃａｒｄの回転に依存して、これらのターゲットは、画素昇順又は画素降順である。その上、ターゲットから復元されたターゲット番号は、誤りがあるかもしれない。また、間違ったターゲットを復元したかもしれない。クロックマーク推定量が取得できる前に、ターゲットは、無効ターゲットが確実に廃棄されるように処理する必要があり、有効ターゲットは、間違っているならばターゲット番号が修復される（例えば、ごみのために破損されたターゲット番号）。二つの主要なステップが関連している：
＊ターゲットを画素昇順にソートするステップ；
＊誤りのあるターゲット番号を見つけ、修復するステップ。
【０５８６】
最初のステップは簡単である。ターゲット検索の性質は、データが画素昇順又は画素降順の何れかで常に記憶されるべきことを意味する。簡単なスワップソートは、６個のターゲットが既に正しくソートされているならば、最大で１４回の比較がスワップ無しに行われる。データがソートされていない場合、１４回の比較は３回の３回のスワップと共に行われる。以下の擬似コードはソーティングプロセスを示す：
0004309954.tif 000067
誤ったターゲット番号を位置検出し修復することは、多少複雑になる。順番に、検出されたＮ個のターゲットの各々が正しいと仮定される。他のターゲットは、この「正しい」ターゲットと比較され、TargetNが正しい場合に変更を必要とするターゲットの個数がカウントされる。変更の回数が０であるならば、全てのターゲットは既に正しい筈である。さもなければ、他のターゲットに対して要求する変更の回数が最も少ないターゲットが変更の基準として使用される。所与のターゲットのターゲット番号及び画素位置が、「正しい」ターゲットの画素位置及びターゲット番号と比較されたときに、相互に関連しないならば、変更が登録される。この変更は、ターゲットのターゲット番号の更新を意味し、或いは、ターゲットの削除を意味する。上昇するターゲットは、（既にソートされているので）昇順の画素を有すると仮定することができる：
0004309954.tif 000068
多くの場合、この関数は
bestChanges = 0 
で終了しており、これは変更が要求されないことを意味している。そうでない場合、変更を適用する必要がある。変更を適用する機能は、targetNumber との比較までは、（上述の擬似コードにおいて）変更をカウントすることと同一である。変更アプリケーションは以下の通りである：
0004309954.tif 000069
変更ループの最後に、LocatedTargetsリストをコンパクトにして、全てのヌルターゲットを削除する必要がある。
【０５８７】
この手続の最後に、数個のターゲットが存在する可能性がある。残っている全てのターゲット（少なくとも２個のターゲットが必要である）は、クロックマーク及びデータ領域の位置を検出するため使用される。
【０５８８】
図５５に示されるように、上側領域の第１のクロックマークドット１１２６は、第１のTarget1１２４の中心から５５ドット離れている（これはターゲット中心間の距離と同じである）。クロックマークドットの中心は更に１ドット遠ざかり、黒色境界線１１２３は第１のクロックマークドットから更に４ドット離れている。下側領域の第１のクロックマークドットは、上側領域の第１のクロックマークドット１１２６から正確に７ターゲットの距離（７×５５ドット）離れている。
【０５８９】
Target１及び６が見つかっていると仮定し得ないので、最も上側のターゲット及び最も下側のターゲットを使用する必要があり、どのターゲットが使用されているかを判定するためターゲット番号を使用する。この時点で少なくとも２個のターゲットが必要である。その上、ターゲット中心は、実際のターゲット中心の推定値に過ぎない。それは、ターゲット中心をより正確に位置検出することである。ターゲットの中心は、黒色に囲まれた白色である。したがって、画素次元と列次元の両方で極大を見つけることが望ましい。これには、連続した画像を再構築することが必要である。なぜならば、最大値が整数バウンダリ（本例の推定値）に厳密に合わせられる可能性は殆ど無いからである。
【０５９０】
連続した画像をターゲットの中心の周りに構築する前に、２個のターゲット中心のより良い推定値を作成することが必要である。既存のターゲット中心は、実施には、ターゲット中心の境界ボックスの左上座標である。ターゲットの中心を画成するエリアを見つけるため各画素を一つずつ調べ、最高値を有する画素を検出することは、簡単なプロセスである。同じ最高画素値を有する画素は２個以上存在する場合もあるが、中心値の推定には１個の画素があればよい。
【０５９１】
擬似コードは簡単であり、２個のターゲットの各々に対して実行される：
0004309954.tif 000070
このプロセスの最後に、ターゲット中心座標は、実際の中心の１画素の範囲に収まるべきターゲットの最も白い画素を指示する。ターゲット中心のより正確な位置を構築するプロセスには、推定されたターゲット中心の両側に３個ずつで、ターゲットの７個の走査線スライスの連続信号を再構築することが含まれる。検出された７個の最大値（上記の画素スライスの各々につき１個ずつ）は、列次元において連続信号を再構築し、次に、その次元における最大値の位置を検出するために使用される：
0004309954.tif 000071
FindMaxは、元の１次元信号に基づくサンプル点を再構築し、最大値の位置及び検出された最大値を返す関数である。使用される信号再構築／再サンプリング方法は、図７６に示されるように、Lanczos3窓sinc関数である。
【０５９２】
Lancoz3窓sinc関数は、再構築された次元から、推定位置Xの周りに集められた、即ち、Ｘ−３、Ｘ−２、Ｘ−１、Ｘ、Ｘ＋１、Ｘ＋２、Ｘ＋３にある７（画素）サンプルを取得する。Ｘ−１からＸ＋１の間に、０．１の間隔で点を再構築し、最大となる点を決定する。最大値である位置が新しい中心になる。カーネルの性質上、ＸとＸ＋１の間の点に対してコンボリューションカーネルに必要なエントリーは６個だけである。Ｘ−１からＸに対して６個の点と使用し、ＸからＸ＋１に対して６個の点を使用し、Ｘ−１からＸ＋１間での画素値を得るために全体として７点が必要である。なぜならば、要求された画素の一部は一致するからである。
【０５９３】
最も上側のターゲットから最も下側のターゲットまでに正確な推定値が与えられた場合、上側領域及び下側領域に対して第１のクロックマークドットの位置を以下のようにして計算することができる：
0004309954.tif 000072
これにより第１のクロックマークドットが得られる。列位置は、クロックマークの中心へ到達するため、データエリアから更に１ドット遠くへ動かすことが必要である。また、画素位置は、境界線の中心へ到達するため、更に４ドット遠ざける必要がある。deltaColumn及びdeltaPixelの疑似コード値は、５５ドットの距離（ターゲット間の距離）に基づいているので、これらのデルタは、クロックマーク座標に適用される前に、それぞれ、１／５５及び４／５５によって縮小しなければならない。これは以下の通りに表現される：
kDeltaDotFactor =
1/DOTS_BETWEEN_TARGET_CENTRES
deltaColumn *= kDeltaDotFactor
deltaPixel *= 4 * kDelteDotFactor
UpperClock.pixel -= deltaPixel
UpperClock.column -= deltaColumn
LowerClock.pixel += deltaPixel
LowerClock.column += deltaColumn
UpperClock及びLowerClockは、ターゲットの中心とちょうど合致した第１のクロックマークに対する有効クロックマーク推定値である。
【０５９４】
黒色及び白色画素／ドットレンジの設定
データをデータエリアから抽出する前に、黒色及び白色ドットの画素レンジを確認する必要がある。LookingForTaregets中に現れた最小値及び最大値は、それぞれ、WhiteMin及びBlackMaxに保存されているが、これらは、データ抽出に関してこれらの変数の有効な値を表現していない。それらは、単に、記憶の便宜上、使用されるだけである。以下の疑似コードは、出現した最小画素及び最大画素に基づいてWhiteMin及びBlackMaxの良い値を獲得する方法を示している：
MinPixel = WhiteMin
MaxPixel = BlackMax
MidRange = (MinPixel + MaxPixel)/2
WhiteMin = MaxPixel - 105
BlackMax = MinPixel + 84
CurrentState = ExtractingBitImage
ExtractingBitImage状態は、データブロックが、ターゲットによって既に正確に位置検出された状態であり、ビットデータは、同時に１ドット列毎に抽出中であり、代替Ａｒｔｃａｒｄビットイメージに書き込まれている。データブロッククロックマーク／境界の追跡によって、回転とは無関係に正確なドット復元が行われ、セグメント境界は無視される。データブロック全体（５９５個のデータ列と２個の方位列を併せて、４８バイトずつの５９７列）が抽出されると、新しいセグメント境界が現在位置に基づいて次のデータブロックのために計算される。この状態は、LookingForTargets状態に変更される。
【０５９５】
所与のドット列の処理には以下の二つのタスクが必要である：
＊第１のタスクは、クロックマークを用いて特定のデータのドット列の位置を検出することである；
＊第２のタスクは、ドット列を追跡して、１ドットにつき１ビットずつビット値を集めることである。
【０５９６】
これらの二つのタスクは、列のデータが代替Ａｒｔｃａｒｄから読み出され、ＤＲＡＭへ転送された場合に限り行うことができる。これは、プロセス１がどの走査線まで到達しているかをチェックし、それをクロックマーク列と比較することによって判定される。ドットデータがＤＲＡＭに存在するとき、クロックマークを更新し、クロックマークを次のドット列に対する推定値へ進める前に、列からデータを抽出することが可能である。このプロセスの概要は、以下の疑似コードに示されている。具体的な関数については後述する：
0004309954.tif 000073
ドット列の位置検出
所定のドット列は、ドットを読み出し、データを抽出する前に、位置検出されなければならない。これは、データブロックの上側及び下側境界に沿ってクロックマーク／境界線を追跡することによって実現される。位相ロックループと等価的なソフトウェアが使用され、たとえクロックマークが破損されていても、クロックマーク位置の良い推定が確実に行われる。図７７は、例示的なデータブロックの左上の説明図であり、そのデータブロックのコーナーには、ターゲットエリアの外側へ広がる３ドット高のクロックマーク１１６６と、白色行と、黒色境界線と、が現されている。
【０５９７】
初期的に、第１の黒色クロックマークの位置の推定値が（ターゲット位置に基づいて）提供される。正確な垂直位置（画素）を得るため黒色境界が使用され、正確な水平位置（列）を得るため、例えば、クロックマーク１１６６が使用される。これらは、UpperClock及びLowerClockの位置に反映される。
【０５９８】
クロックマーク推定値が取得され、その近傍の画素を調べることにより、連続した信号が再構築され、正確な中心が決定される。２次元をクロックマークと境界に分解しているので、これは、簡単な１次元プロセスであり、２回実行する必要がある。しかし、これは、位置合わせの相手側の黒色クロックマークが存在するとき、２ドット列について１回だけ行われる。白色クロックマークの場合、単に推定値を使用し、推定値はそのままにしておく。或いは、（常に存在するので）ドット列毎に境界に基づいて画素座標を更新してもよい。実際上、（黒色クロックマークを含む）１列おきに両方の座標を更新すれば十分である。なぜならば、この動作中の解像度は非常に精細だからである。したがって、このプロセスは次のようになる：
0004309954.tif 000074
所定の許容度（MAX_CLOCKMARK_DEVIATION）を上回る偏差が存在する場合、検出された信号は無視され、推定値からの最大許容度に収まる偏差だけが許容される。この点に関して、この機能はフェーズロックループの機能と類似している。したがって、DetermineAccurateUpperDotCenter関数は以下の疑似コードによって実現される：
0004309954.tif 000075
また、DetermineAccurateLowerDotCenter関数は、境界からクロックマークまでの向きが負方向である（＋３ドットではなく、−３ドットである）点を除くと同様である。
【０５９９】
GetAccuratePixel及びGetAccurateColumnは、座標が与えられた場合に、一次元だけの観点で正確なドット中心を決定する関数である。正確なドット中心の決定は、信号を再構成し、最小信号値が検出された位置を見つけるプロセスである（これは、ターゲット中心は黒色ではなく白色であるために、信号の最大値の位置を検出することによりターゲット中心の位置を検出するプロセスとは異なる）。このアプリケーションの信号再構成／再サンプリングのために選択された方法は、図７６を参照して説明したようなLanczos3窓sinc関数である。
【０６００】
クロックマーク又は境界は何らかの方法で、おそらくは、ひっかきによって、傷つけられている可能性がある。再サンプリングによって得られた新しい中心値と推定値との差が許容量を超える場合、中心値は最大許容量だけ動かされる。それが無効な位置である場合、データ回復に使用するために十分に接近しているはずであり、更なるクロックマークはその位置に再度合わせられる。
【０６０１】
第１のデータドットの中心と後続のドットへのデルタの決定
正確なUpperClock及びLowerClock位置が決定されると、第１のデータドットの中心（CurrentDot）と、列内の後続のドットへ進めるためにその中心位置に加算されるべきデルタ量（DataDelta）とを計算することができる。
【０６０２】
最初に行うべきことは、ドット列のデルタを計算することである。これは、単に、LowerClockからUpperClockを減算し、２点間のドット数で除算することによって実現される。実際にはドット数の逆数を乗算することが可能である。なぜならば、ドット数は代替Ａｒｔｃａｒｄに関して定数であり、且つ乗算の方が高速に行われるからである。画素次元のデルタと列次元のデルタを獲得するため、異なる定数を使用することが可能である。画素のデルタは二つの境界間の距離であり、列のデルタは二つのクロックマークの中心間である。このようにして、関数DeternineDataInfoは二つの部分からなる。第１の部分は次の擬似コードによって表される：
kDeltaColumnFactor =
1/(DOTS_PER_DATA_COLUMN+2+2-1)
kDeltaPixelFactor =
1/(DOTS_PER_DATA_COLUMN+5+5-1)
delta = LowerClock.column -
UpperClock.column
DataDelta.column = delta *
kDeltaColumnFactor
delta = LowerClock.pixel - UpperClock.pixel
DataDelta.pixel = delta * kDeltaPixelFactor
次に、列の第１のデータの中心を決定することが可能である。クロックマークの中心から第１のデータドットの中心までの距離は２ドットであり、境界の中心から第１のデータドットの中心までの距離は５ドットである。この関数の第２の部分は次の擬似コードによって表される：
CurrentDot.column = UpperClock.column + (2*DataDelta.column)
CurrentDot.pixel = UpperClock.pixel +
(5*DataDelta.pixel)
ドット列の追跡
ドット列はクロックマークに追従する位相ロックループから見つけられたので、残っていることは、その列を下って各ドットの中心でドット列をサンプリングすることだけである。変数CurrentDot点は現在列の第１のドットの中心に決定される。列の次のドットへ進むためには、DataDeltaを加算するだけでよい（２回の加算：１回は列座標のため、もう１回は画素座標のため）。所定の座標におけるドットのサンプリング（バイリニア補間）が行われ、ドットの中心を表現する画素値が決定される。画素値は、次に、そのドットのビット値を決定するため使用される。しかし、より良いビット判定を行うため、同一ドットライン上の２個の周辺ドットに対する中心値と関連して、その画素値を使用することが可能である。
【０６０３】
抽出されたドット列内のドットに対する全ての画素はこの時点でＤＲＡＭにロードされていると仮定してもよい。なぜならば、ラインの両端（クロックマーク）がＤＲＡＭに存在するならば、これらの２個のクロックマークの間のドットも間違いなくＤＲＡＭに存在するからである。更に、データブロック高さは十分に低いので（３８４ドット高にすぎない）、単なるデルタだけがラインの全長を越えるために十分であることが保証される。カードが８個のデータブロック高さに分割されている理由の一つは、単一のデータブロックに関して行うことができる保証と同じ厳格な保証を、カードの全高に亘って行うことが不可能だからである。
【０６０４】
単一ラインのデータ（４８バイト）を抽出する上位レベルプロセスは、以下の疑似コードで表される。データバッファポインタは、各バイトが保存されるのに伴ってインクリメントされ、連続したバイト及びデータの列が確実に連続的に保存される：
0004309954.tif 000076
GetPixel関数はドット座標（固定小数点）を取得し、バイリニア補間によって中心画素値に達するため、４個のＣＣＤ画素をサンプリングする。
【０６０５】
DetermineCenterDot関数は、ビット値が決定されたドットの両側にあるドット中心を表現する画素値を取得し、その中心ドットのビット値の値を知的に推定することを試みる。図６４の一般化されたブラー効果曲線から、以下の三つの一般的なケースが考えられる：＊ドットの中心画素値はWhiteMinよりも小さいので、確実に黒色ドットである。したがって、ビット値は必ず１である；
＊ドットの中心値はBlackMaxよりも大きいので、確実に白色ドットである。したがって、ビット値は必ず０である；
＊ドットの中心値は、BlackMaxとWhiteMinの間のどこかにある。ドットは黒色かもしれないし、白色かもしれない。したがって、このビットの値が問題になる。ビットの値を合理的に推定するため、多数の方式が考えられている。これらの方式は、精度に対して複雑さのバランスを取り、ある種のケースでは、保証された解決策が存在しないことを考慮する必要がある。誤ったビット判定を行うケースでは、ビットのリード・ソロモンシンボルに誤りが生じ、フェーズ２のリード・ソロモン復号化ステージで訂正しなければならない。
【０６０６】
画素値がBlackMaxとWhiteMinの間に入るときにドットの値を決定するため使用される方式は、あまり複雑ではないが、優れた結果を与える。この方式は、門対となっているドットの左及び右にあるドット中心の画素値を使用して、中心ドットのよりもっともらしい値を決定する。即ち、
＊両側の２個のドットがMidRange（平均ドット値）の白色側に存在する場合、中心ドットが白色であるならば、「確実に」白色であると推定することができる。その中心ドットが不確実な領域に存在するということは、そのドットが黒色であり、その値をより不確実にするため周辺の白色ドットによる影響を受けたということを示す。したがって、そのドット値は黒色であると考えられるので、そのビット値は１である；
＊両側の２個のドットがMidRangeの黒色側に存在する場合、中心ドットが黒色であるならば、「確実に」黒色であると推定することができる。その中心ドットが不確実な領域に存在するということは、そのドットが白色であり、その値をより不確実にするため周辺の黒色ドットによる影響を受けたということを示す。したがって、そのドット値は白色であると考えられるので、そのビット値は０である；
＊一方のドットがMidRangeの黒色側に存在し、もう一方のドットがMidRangeの白色側に存在するならば、中心ドット値をそのまま使用して決定する。中心ドットがMidRangeの黒色側に存在するならば、黒色（ビット値１）を選択する。さもなければ、白色（ビット値０）を選択する。
【０６０７】
このロジックは以下のように表現される：
0004309954.tif 000077
ここから、周辺画素値の使用は、中心ドットの状態の優れた指標を与え得ることが認められる。ここで説明した方式は、同じ行からのドットだけを使用しているが、単一のドットライン履歴（前のドットライン）の使用は、明らかに代替的な構成になるであろう。
【０６０８】
次の列のためのクロックマーク更新
ある列の第１のデータドットの中心が決定されると、クロックマーク値は不要になる。それらは、その列に対するデータが獲得された後、次の列の準備のため更新する方が好都合である。クロックマークの向きは、ドット列に沿って下りるドットの追跡方向に対して垂直であるため、列を更新するため画素デルタを使用し、両方のクロックの画素を更新するため列デルタを使用することが可能である：
UpperClock.column += DataDelta.pixel
LowerClock.column += DataDelta.pixel
UpperClock.pixel -= DataDelta.column
LowerClock.pixel -= DataDelta.column
この時点で、次のドット列の推定値が得られる。
【０６０９】
タイミング
タイミングの必要条件は、ＤＲＡＭ利用率が１００％を超えない限り充たされ、並列アルゴリズムの追加によってタイミングが増大されるがＤＲＡＭ利用率は１００％を超えない。ＤＲＡＭ利用率はプロセス１に関して特定され、このプロセス１は各画素を１回ずつ連続的に書き込み、ＤＲＡＭ帯域幅の９％を消費する。
【０６１０】
このセクションに記載されるようなタイミングは、ＤＲＡＭが代替Ａｒｔｃａｒｄリー
ダーアルゴリズムの要求に容易に対処し得ることを示す。したがって、タイミングのボトルネックは、ＤＲＡＭアクセスではなく、ロジック速度に関するアルゴリズムの実装であろう。しかし、アルゴリズムは、アーキテクチャの単純さに留意して設計され、メモリサイクル毎に最小限の個数の論理演算しか要求しない。この点で、実装された状態機械又は等価的なＣＰＵ／ＤＳＰアーキテクチャが以下のサブセクションに記載されているように実行可能である限り、目標速度は達成されるであろう。
【０６１１】
ターゲット位置検出
ターゲットは画素列の境界内の画素を読み出すことによって位置検出される。各画素は高々１個ずつ読み出される。ランレングスエンコーダが十分高速に動作する場合を考えると、ターゲットの位置検出の限界はメモリアクセスである。したがって、アクセスはプロセス１のタイミング、即ち、ＤＲＡＭ帯域幅の９％利用率よりは悪化しないであろう。
【０６１２】
したがって、ターゲット位置検出中の（プロセス１を含む）ＤＲＡＭの総利用率は１８％であり、ターゲットロケータは、常に、代替Ａｒｔｃａｒｄのイメージセンサ画素リーダーに追従している。
【０６１３】
ターゲットの処理
ターゲット番号をソートしチェックするためのタイミングは取るに足らない。２個のターゲット中心の各々のより良い推定値を見つけるためには、１２組の１２画素の読み出し、即ち、全部で１４４回の読み出しを必要とする。しかし、正確なターゲット中心の修復は些細ではなく、２組の推定を必要とする。各ターゲット中心の調整には、８組の２０種類の６エントリー型コンボリューションカーネルが必要である。このようにして、その合計は、８×２０×６回の乗算−累算＝９６０に達する。その上、７組の７画素を獲得するため４９回のメモリアクセスが必要である。したがって、１ターゲット当たりの総数は、１４４＋９６０＋４９＝１１５３であり、これは、画素の列内の画素数（１１５２）とほぼ同数である。このように、各ターゲット推定は、１行の画素を処理するために要する時間を消費する。ターゲットが２個の場合、実質的に２列の画素列に要する時間を消費する。
【０６１４】
ターゲットは、第１の画素列上でターゲット番号の後に確実に識別される。方位列の前には２列のドット列が存在するので、６列の画素列が存在する。ターゲット位置検出プロセスは、最初の画素列を使い果たすが、残りの５列の画素列は全く処理されない。したがって、データエリアは、他のプロセス時間に影響を与えることなく、利用可能な時間の２／５内に位置検出することができる。
【０６１５】
利用可能な時間の残りの３／５は、白色及び黒色画素のレンジを割り当てる些細なタスクのために十分であり、１タスクは高々２から３マシーンサイクルを使用する。
【０６１６】
データ抽出
タイミングに関して、次の二つの部分を考慮すべきである：
＊正確なクロックマーク及び境界値を取得すること；
＊ドット値を抽出すること。
【０６１７】
クロックマーク及び境界値は、１ドット列おきにしか収集されない。しかし、より正確にするためにクロックマーク推定値を更新する毎に、２０種類の６エントリー型コンボリューションカーネルを評価しなければならない。平均的に、１ドット列当たりにそのうちの２個が存在する（２ドット列毎に４個）。境界に基づいて画素座標を更新するためには、同じ画素走査線からの７画素だけが必要である。しかし、列座標を更新するためには、異なる列、即ち、異なる走査線からの７画素が必要である。走査線エントリー毎に１回のキャッシュミスが生じ、同じ走査線内の画素に対して２回のキャッシュミスが生じる最悪ケースの状況を想定すると、全部で８回のキャッシュミスが起こる。
【０６１８】
ドット情報を抽出するためには、１ドット毎に（ドットを定義する平均９個ではなく）４画素だけを読み出す。１１５２画素（３８４ドット）のデータエリアを想定すると、せいぜい、これは、９画素ドットではなく４画素ドットを読み出すことによって、７２回のキャッシュ読み出しを節約するに過ぎない。最悪ケースは、５７画素毎に１列だけ移動する１°の回転であるが、節約の程度が僅かに悪化するだけである。
【０６１９】
最悪の場合、読み出すキャッシュラインの数は、データエリア内の画素によって使われたキャッシュラインよりも少なくなる、といっても構わない。したがって、アクセスはプロセス１、即ち、ＤＲＡＭ帯域幅の９％利用率よりも悪化することはない。
【０６２０】
したがって、データ抽出中（プロセス１を含む）のＤＲＡＭ総利用率は１８％であり、データ抽出部は、常に、代替Ａｒｔｃａｒｄのイメージセンサ画素リーダーに追従する。これにより実装されるターゲット処理プロセスでは、ターゲットの処理は、かなり非効率的な方法によって実行されるが、依然として、必要に応じて、データ抽出プロセス中に迅速に追従する。
【０６２１】
フェーズ２−ビットイメージ復号
フェーズ２は、代替Ａｒｔｃａｒｄのデータ復元アルゴリズムの非リアルタイムフェーズである。フェーズ２の先頭で、ビットイメージは代替Ａｒｔｃａｒｄから抽出されている。ビットイメージは、代替Ａｒｔｃａｒｄのデータ領域から読み出されたビットを表現する。一部のビットには誤りがあり、おそらく、代替Ａｒｔｃａｒｄは挿入時に回転させられているので、データ全体は１８０°回転している。フェーズ２は、この符号化されたビットイメージから原データを確実に抽出することに関係している。基本的に、図７９に示されるように３ステップが実行される：
＊代替Ａｒｔｃａｒｄが逆向きに挿入されているならば反転して、ビットイメージを再編成する；
＊符号化されたデータをスクランブル解除する；
＊ビットイメージからのデータをリード・ソロモン復号化する。
【０６２２】
３ステップの各々は別個のプロセスとして定義され、あるプロセスの出力は次のプロセルの入力として要求されるので、連続して実行される。最初の２ステップを単一プロセスに併合することは簡単であるが、説明の便宜上、ここでは、別個のプロセスとして取り扱う。
【０６２３】
データ／プロセスの観点からみると、フェーズ２は図８０に示されるような構造を有する。
【０６２４】
プロセス１及び２のタイミングは無視することが可能であり、その間に１／１０００秒未満しか消費しない。プロセス３（リード・ソロモン復号）は、約０．３２秒を消費し、これがフェーズ２のために必要な合計時間になる。
【０６２５】
ビットイメージ再編成、必要に応じて反転
ＤＲＡＭ内のビットマップは、この時点で、代替Ａｒｔｃａｒｄから取得されたデータを表現する。しかし、ビットイメージは連続していない。ビットイメージは６４個の３２ｋ単位のチャンクに分割され、データブロック毎に１チャンクがある。３２ｋチャンクの各々は、２８６５６個の有効バイトだけ、即ち、
最も左側の方位列からの４８バイトと、
真のデータ領域からの２８５６０バイトと、
最も右側の方位列からの４８バイトと、
未使用の４１１２バイトと、
を格納する。
【０６２６】
画素データ（フェーズ１のプロセス１によって格納）のために使用される２ＭＢバッファは、再編成されたビットイメージを保持するために使用可能である。なぜならば、画素データはフェーズ２の間では要求されないからである。再編成の最後に、正しく向きを与えられた連続したビットイメージは、２ＭＢ画素バッファに収容され、リード・ソロモン復号化のための準備ができている。
【０６２７】
カードの向きが正しい場合、最も左側の方位列は白色であり、最も右側の方位列は黒色である。カードが１８０°回転している場合、最も左側の方位列は黒色であり、最も右側の方位列は白色である。
【０６２８】
カードが正しい向きにされているかどうかを判定する簡単な方法は、白色ビットに対する黒色ビットの比率が圧倒的であるブロックが見つかるまで、各データブロックを一つずつ使用して、データの最初及び最後の４８バイトをチェックすることである。以下の擬似コードはこの方法を例示し、カードが正しい向きに置かれているときTRUEを返し、そうではなければFALSEを返す：
0004309954.tif 000078
データは、この時点で、カードが正しい向きであるかどうかに基づいて認識できるはずである。最も簡単なケースは、カードが正しい向きにされている場合である。この場合、データは、方位列を除去し、データ全体を連続させるために、少しだけ動かす必要がある。これは、以下の擬似コードに示されるように元の位置で非常に簡単に実現される：
0004309954.tif 000079
それ以外の場合は、データを実際に反転させる必要がある。データを反転させるアルゴリズムは非常に簡単であるが、簡単にするために、２５６バイトのテーブルReverseを用いる。ここで、Reverse[N]の値はNのビット反転である：
0004309954.tif 000080
両方のプロセスのタイミングは無視することが可能であり、１／１０００秒未満しか消費しない：
＊２ＭＢ連続読み出し（２０４８／１６×１２ｎｓ＝１５３６ｎｓ）；
＊２ＭＢ実効的連続バイト書き込み（２０４８／１６×１２ｎｓ＝１５３６ｎｓ）。
【０６２９】
符号化画像のスクランブル解除
ビットイメージは、１８２７８４０個の連続した、正しい向きにされた、スクランブル付きのバイトである。バイトは、１ブロックが２５５バイト長からなる７１６８個のリード・ソロモンブロックを生成するために、スクランブル解除されなければならない。スクランブル解除プロセスは非常に簡単であるが、スクランブル解除処理は元の場所で実行できないので、別個の出力バッファを必要とする。図８０は、スクランブル解除プロセスが行われるメモリの説明図である。
【０６３０】
以下の疑似コードはスクランブル解除プロセスの実行方法を規定する：
0004309954.tif 000081
このプロセスのためのタイミングは無視することが可能であり、１／１０００秒未満しか消費しない：
＊２ＭＢ連続読み出し（２０４８／１６×１２ｎｓ＝１５３６ｎｓ）；
＊２ＭＢ非連続バイト書き込み（２０４８×１２ｎｓ＝２４５７６ｎｓ）。
【０６３１】
このプロセスの終了時、スクランブル無しデータがリード・ソロモン復号化のために準備できる。
【０６３２】
リード・ソロモン復号化
代替Ａｒｔｃａｒｄの読み出しの最後の部分は、リード・ソロモン復号化プロセスであり、ここでは、約２ＭＢのスクランブル無しデータが約１ＭＢの有効代替Ａｒｔｃａｒｄデータに復号化される。
【０６３３】
このアルゴリズムは、同時に一つのリード・ソロモンブロックを復号化し、（必要であれば）元の場所で実行可能である。なぜならば、符号化されたブロックは復号化されたブロックよりも大きく、冗長バイトがデータバイトの後に格納されているからである。
【０６３４】
最初の２個のリード・ソロモンブロックは制御ブロックであり、ビットイメージから抽出されるべきデータのサイズに関する情報を含んでいる。このメタ情報は、最初に復号化する必要があり、得られた情報が真のデータを復号化するため使用される。真のデータの復号化は、単に同時に一つずつデータブロックを復号化する問題である。特定のブロックの復号化が失敗した場合、控えのデータブロックを使用することが可能である。
【０６３５】
最上位レベルのリード・ソロモン復号化を疑似コードで提示する：
0004309954.tif 000082
DecodeBlockは、標準的なリード・ソロモンブロックデコーダであり、ｍ＝８及びｔ＝６４を使用する。
【０６３６】
GetControlData関数は、復号化エラーが生じない限り簡単である。この関数は、成功するまで、同時に一つの制御ブロックを復号化するためDecodeBlockを呼び出すだけである。制御パラメータは、復号化されたデータの最初の３バイトから抽出することができる（destBlocksはバイト０及び１に格納され、lastBlock 
はバイト２に格納される）。復号化エラーが存在する場合、この関数は、３２組の３バイトをトラバースし、最も確からしい値の組を決定しなければならない。一つの簡単な方法は、３バイトの中から２個の連続した等しいコピーを見つけ、これらの値が正しい値であるとして決めることである。他の方法は、出現する３バイトの組の種類数をカウントし、最もよく出現する組が正しい組であると決める。
【０６３７】
リード・ソロモン復号化に要する時間は実装に依存する。リード・ソロモン復号化プロセスを実行するために専用コア（例えば、ＬＳＩロジックのL64712）を使用可能であるが、アプリケーションに応じて（通常、復号化されたデータを用いて何かを実行するために）内蔵型システムの全体でより汎用的に使用できるＣＰＵ／ＤＳＰの組み合わせを選択する方が好ましい。勿論、復号化時間はＣＰＵ／ＤＳＰの組み合わせの場合にも十分に高速でなければならない。
【０６３８】
L64712は、毎秒５０Mビット（毎秒約６．２５ＭＢ）のスループットがあるので、時間は、最大で２ＭＢ読み出し及び１ＭＢ書き込みのメモリアクセス時間ではなく、リード・ソロモンデコーダの速度によって制約される。最悪のケース（全ての２ＭＢが復号化を必要とするケース）に要する時間は、従って、２／６．２５秒＝約０．３２秒である。勿論、以下の改良を含む多数の改良を考えることができる。
【０６３９】
読み出し環境のブラー効果が大きいほど、所定のドットは周辺ドットからより大きい影響を受ける。好適な実施例による現在の読み出しアルゴリズムは、ドット値に関してより優れた決定を行うため、同一列内の周辺ドットを使用する能力を備えている。前の列のドットは既に復号化されているので、前の列のドット履歴は、画素値が不確実なレンジに含まれるドットの値を決定する際に役に立つ。
【０６４０】
初期ステージに関する別の可能性は、それを完全に取り除き、データブロックの初期境界を必要とされる境界よりも広くし、ターゲット処理関数をより知的にすることである。これは、全体的な複雑さを軽減する。データブロックの独立性を維持するために注意する必要がある。
【０６４１】
制御ブロック機構はより頑強にすることができる：
＊制御ブロックは、（本例のケースのように）隣接させるのではなく、最初のブロック及び最後のブロックでもよい。これは、ある種の異常なダメージ状況に対する保護を高めるであろう；
＊第２の改良は、リード・ソロモン復号化ステップが失敗した場合に使用される補助的なレベルの冗長性／誤り検出を制御ブロック構造に取り入れることである。パリティのような簡単な仕組みは、リード・ソロモンステージが失敗した場合に、制御情報のもっともらしさを改良する。
【０６４２】
フェーズ５ Ｖａｒｋスクリプト実行
Ａｒｔｃａｒｄ９を読み出し、それを復号化するために要する総時間は、したがって、約２．１５秒である。ユーザがはっきりとわかる遅延は、実際には０．６５秒（フェーズ３及び４の合計）に過ぎない。なぜならば、Ａｒｔｃａｒｄは１．５秒後に移動を停止するからである。
【０６４３】
Ａｒｔｃａｒｄがロードされると、Ａｒｔｖａｒｋスクリプトを解釈しなければならない。スクリプトを直ちに実行するのではなく、スクリプトは「プリント」ボタン１３（図１）が押下されたときだけに実行される。スクリプトを実行するための所要時間は、スクリプトの複雑さに応じて変化し、プリントボタンの押下と、実際のプリントボタンと、実際の印刷動作との間で認識される遅延を考慮しなければならない。
【０６４４】
上述の通り、ＶＬＩＷプロセッサ７４は、コンピュータ利用の費用がかかるＶａｒｋ関数を加速するデジタル処理システムである。ＣＰＵコア７２によってソフトウェアで実行される関数と、ＶＬＩＷプロセッサ７４によってハードウェアで実行される関数のバランスは、実装に依存する。ＶＬＩＷプロセッサ７４の目的は、全てのＡｒｔｃａｒｄスタイルがユーザからみて遅いと感じられない時間内で実行することを助けることである。ＣＰＵが高速で強力になると共に、ハードウェア加速を必要とする関数の数は減少し続ける。ＶＬＩＷプロセッサは、以下の時間的に重要な関数の汎用ハードウェア高速化を可能にさせるマイクロコード化されたＡＬＵサブシステムを含む：
１）汎用ソフトウェア処理のための画像アクセス機構
２）画像コンボルバ
３）データ駆動型画像ワーパー
４）画像スケーリング
５）画像モザイク
６）アフィン変換
７）画像コンポジッター
８）色空間変換
９）ヒストグラムコレクタ
１０）画像の照明
１１）ブラシスタンパー
１２）ヒストグラムコレクタ
１３）ＣＣＤイメージから内部画像への変換
１４）画像ピラミッドの構築（ワーパーによってブラッシングのため使用される）。
【０６４５】
以下の表は、ＡＬＵモデルに実装された場合の各Ｖａｒｋ演算の所要時間を要約したものである。ＡＬＵモデルを使用する関数を実装する方法は後述される。
【０６４６】
【表５７】
0004309954.tif 000083
例えば、ＣＣＤ画像を変換するため、ヒストグラム収集、及び（画像強調用）ルックアップ色置換のために１画素当たりに９＋２＋０．５サイクル、即ち、１１．５サイクルを要する。１５００×１０００画像の場合、これは、１７２５０００００、即ち、１コンポーネント当たりに約０．２秒、即ち、全３コンポーネント当たりに０．６秒である。簡単なワープを追加すると、全体で、０．６＋０．３６、即ち、ほぼ１秒になる。
【０６４７】
画像コンボルバ
コンボルブは中心画素周りの重み付き平均化である。この平均は、単純な加算でもよく、絶対値の和でもよく、和の絶対値でもよく、或いは、０で丸められた和でもよい。
【０６４８】
画像コンボルバは汎用コンボルバであり、可変サイズ係数カーネル内の値を変えることによって様々な関数を実現できる。サポートされるカーネルサイズは、３×３、５×５、及び７×７だけである。
【０６４９】
図８２を参照すると、コンボリューションプロセスの一例３４０が示されている。コンボルバプロセス３４１に供給される画素コンポーネント値は、ボックス読み出しイタレータ３４２から与えられる。イタレータ３４２は行単位で画像データを供給し、各行内では、画素毎に画像データを供給する。コンボルバ３４１からの出力は、順次書き込みイタレータ３４４へ送られ、順次書き込みイタレータ３４４は有効画像フォーマットで合成画像を格納する。
【０６５０】
係数カーネル３４６は、ＤＲＡＭ内のルックアップテーブルである。カーネルは、ボックス読み出しイタレータ３４２と同じ順序に係数が並べられる。各係数エントリーは８ビットである。単純な順次読み出しイタレータは、カーネル３４６を指定し、係数を与えるため使用される。これは、カーネルサイズと一致する画像幅ImageWidthの画像をシミュレーションし、ループオプションがセットされるので、カーネルは連続して供給される。
【０６５１】
ＡＬＵユニット上のコンボルブプロセスの一実施形態は図８１に示されている。以下の定数がソフトウェアによってセットされる。
【０６５２】
【表５８】
0004309954.tif 000084
制御ロジックは、１画素当たりの乗算／加算の回数をカウントダウンするため使用される。カウント（ラッチ２に累算）が０に達するとき、生成される制御信号は（ラッチ１からの）現在のコンボルブ値を書き出し、カウントをリセットするため使用される。このようにして、一つの制御ロジックブロックは、多数の並列コンボルブストリームのために使用される。
【０６５３】
各サイクルに、乗算ＡＬＵは、画素の適切な部分を組み込むため、１回の乗算／加算を実行することができる。全ての値を総計するために要するサイクル数は、したがって、カーネル内のエントリーの個数である。これは計算制約であるため、画像を複数のセクションに分割し、それらを異なるＡＬＵユニットで並列に処理することが適切である。
【０６５４】
７×７カーネル上で、各画素に要する時間は４９サイクル、即ち、４９０ｎｓである。各キャッシュラインは３２画素を保持するので、メモリアクセスのために利用可能な時間は、（（３２−７＋１）×４９０ｎｓ）、即ち、１２７４０ｎｓである。７本のキャッシュラインを読み出し、１本を書き込むために要する時間は、より悪いケースであって、１１２０ｎｓ（全てのアクセスが同じＤＲＡＭバンクへのアクセスであるとして、８＊１４０ｎｓ）である。その結果として、リソースが無制限であるならば、最大１０画素を並列に処理することが可能である。ＡＬＵの個数が限定されている場合、最高で４画素を並列に処理することができる。従って、７×７カーネルを使用してコンボリューションを実行するために要する時間は、０．１８３７５秒（１５００＊１０００＊４９０ｎｓ／４＝１８３７５００００ｎｓ）である。
【０６５５】
５×５カーネル上で、各画素に要する時間は２５サイクル、即ち、２５０ｎｓである。各キャッシュラインは３２画素を保持するので、メモリアクセスのために利用可能な時間は、（（３２−５＋１）×２５０ｎｓ）、即ち、７０００ｎｓである。５本のキャッシュラインを読み出し、１本を書き込むために要する時間は、より悪いケースであって、８４０ｎｓ（全てのアクセスが同じＤＲＡＭバンクへのアクセスであるとして、６＊１４０ｎｓ）である。その結果として、リソースが無制限であるならば、最大７画素を並列に処理することが可能である。ＡＬＵの個数が限定されている場合、最高で４画素を並列に処理することができる。従って、５×５カーネルを使用してコンボリューションを実行するために要する時間は、０．０９３７５秒（１５００＊１０００＊２５０ｎｓ／４＝９３７５００００ｎｓ）である。
【０６５６】
３×３カーネル上で、各画素に要する時間は９サイクル、即ち、９０ｎｓである。各キャッシュラインは３２画素を保持するので、メモリアクセスのために利用可能な時間は、（（３２−３＋１）×９０ｎｓ）、即ち、２７００ｎｓである。３本のキャッシュラインを読み出し、１本を書き込むために要する時間は、より悪いケースであって、５６０ｎｓ（全てのアクセスが同じＤＲＡＭバンクへのアクセスであるとして、４＊１４０ｎｓ）である。その結果として、リソースが無制限であるならば、最大１０画素を並列に処理することが可能である。ＡＬＵ及び読み出し／書き込みイタレータの個数が限定されている場合、最高で４画素を並列に処理することができる。従って、３×３カーネルを使用してコンボリューションを実行するために要する時間は、０．０３３７５秒（１５００＊１０００＊９０ｎｓ／４＝３３７５００００ｎｓ）である。この結果として、各出力画素は、計算をするためにカーネルサイズ／３サイクルを要する。実際のタイミングは以下の表に要約されている。
【０６５７】
【表５９】
0004309954.tif 000085
画像コンポジッター
コンポジット処理は、最終画像における前景及び背景の適切な比率を制御するため、マット又はチャンネルを使用して前景画像を後景画像に加算することである。好ましくは、通常コンポジット処理及び付随コンポジット処理の二つのスタイルのコンポジット処理がサポートされる。二つのスタイルの規則は、
通常コンポジット処理：新しい値＝前景＋（背景−前景）ａ
付随コンポジット処理：新しい値＝前景＋（１−ａ）背景
である。
【０６５８】
相違点は、付随コンポジット処理の場合、前景はマットによって予め乗算されているのに対して、通常コンポジット処理の場合、そのようにされていないことである。コンポジットプロセスの一例は図８３に示されている。
【０６５９】
アルファチャネルは、レンジ０から１に対応した０から２５５の値をとる。
【０６６０】
通常コンポジット
通常コンポジットは、
背景＋（背景−前景）＊α／２５５
として実装される。
【０６６１】
Ｘ／２５５による除算は、２５７Ｘ／６５５３６によって近似される。コンポジットプ
ロセスの実装例は図８４に詳細に示され、以下の定数がソフトウェアによってセットされる。
【０６６２】
【表６０】
0004309954.tif 000086
４個のイタレータが必要であるため、コンポジットプロセスは１画素当たりに１サイクルを要し、ＡＬＵの半分しか利用しない。コンポジットプロセスは一つのチャンネルだけで実行される。３チャンネル画像を互いにコンポジットするためには、コンポジッターは、各チャンネルに１回ずつの合計３回実行されなければならない。
【０６６３】
フルサイズの単一チャンネルをコンポジットするための所要時間は、０．０１５秒（１５００＊１０００＊１＊１０ｎｓ）であり、３チャンネル全てをコンポジットするために０．０４５秒を要する。
【０６６４】
２５５による除算を近似するため、２５７倍した後に６５５３６で除算する。これは、１回の加算（２５６＊ｘ＋ｘ）と、その結果の最後の１６ビットの無視（丸めの目的を除く）とによっても実現可能である。
【０６６５】
図４２に示されるように、コンポジットプロセスは、３個の順次読み出しイタレータ３５１−３５３と、１個の順次書き出しイタレータ３５５とを必要とし、乗算器ＡＬＵと共にアダーＡＬＵと共にアダーを使用するマイクロコードとして実装される。コンポジット時間は１画素当たり１サイクル（１０ｎｓ）である。付随コンポジット処理と通常コンポジット処理は別々のマイクロコードを必要とするが、１画素当たりの平均時間は同じである。
【０６６６】
コンポジット処理は単一チャンネルだけで実行される。一つの３チャンネル画像を互いにコンポジットするために、コンポジッターは、チャンネル毎に１回ずつ、併せて３回実行される。ａチャンネルは各コンポジットに対して同一であるため、それは毎回読み出される必要がある。しかし、最良ケースでの４×３２バイトのキャッシュラインの転送（読み出し又は書き込み）は３２０ｎｓを要する。パイプラインは、平均で１画素コンポジット当たりに１サイクルを与え、３２画素をコンポジットするために３２サイクル、即ち、３２０ｎｓ（１００ＭＨｚ）を要するので、チャンネルは実質的に無制限で読み出される。したがって、全チャンネルは、
１５００／３２＊１０００＊３２０ｎｓ＝１５０４００００ｎｓ＝０．０１５秒
でコンポジットされる。
【０６６７】
フルサイズの３チャンネル画像をコンポジットするための所要時間は０．０４５秒である。
【０６６８】
画像ピラミッド構築
ワーピング、タイリング、及びブラッシングのような幾つかの関数は、所定の画素のエリアの平均値を必要とする。所与の各エリアの値を計算するのではなく、これらの関数は、好ましくは、画像ピラミッドを利用する。既に図３３に示されたように、画像ピラミッド３６０は、実質的に多重解像度画素マップである。原画像は１：１表現である。各次元での２：１によるサブサンプリングは、元のサイズの１／４の画像を生成する。このプロセスは画像全体が単一画素によって表現されるまで続く。
【０６６９】
画像ピラミッドは原画像から構築され、原画像によって占められたサイズの１／３（１／４＋１／１６＋１／６４＋．．．）を使う。原画像が１５００×１０００である場合、対応した画像ピラミッドは約１／２ＭＢである。
【０６７０】
画像ピラミッドは、コンボルブのカーネルを各次元で２画素ずつ前進させるワン・イン・フォー入力画像に基づいて実行される３×３コンボルブによって構築することができる。３×３コンボルブは、単純な４画素の平均化よりも高い精度を生じ、異なるピラミッドレベルの座標の差が１レベル毎に１ビットだけシフトすることによって得られるという付加的な利点がある。
【０６７１】
ピラミッド全体の構築は、ピラミッドの各レベルで１回ずつピラミッドレベル構築関数を呼び出すソフトウェアループに依拠している。
【０６７２】
ピラミッドの１レベルを生成するためのタイミングは、入力画像の解像度の（９／４）＊（１／４）である。なぜならば、原画像の１／４のサイズの画像を生成しているからである。このようにして、１５００×１０００画像に対して、
ピラミッドのレベル１を生成するためのタイミング＝９／４＊７５０＊５００＝８４３７５０サイクルであり、
ピラミッドのレベル２を生成するためのタイミング＝９／４＊３７５＊２５０＝２１０９３８サイクルであり、
ピラミッドのレベル３を生成するためのタイミング＝９／４＊１８８＊１２５＝５２７３５サイクルであり、
以下同様に続く。
【０６７３】
総時間は、原画像１画素当たりに３／４サイクル（画像ピラミッドは原画像サイズの１／３であり、各画素は計算に９／４サイクルを要し、即ち、（１／３）＊（９／４）＝３／４）である。１５００×１０００画像の場合、（１００ＭＨｚ）で１１２５０００サイクル、即ち、０．０１１秒である。このタイミングは単一色チャンネルに対するタイミングであり、３色チャンネルは０．０３４秒の処理時間を要する。
【０６７４】
汎用データ駆動型画像ワーパー
ＡＣＰ３１は、入力画像の画像ワーピング操作を実行可能である。画像ワーピングの原理は理論的に周知である。ワーピングのプロセスに関する一つの完全な教科書は、Ｇｅｒｏｇｅ 
Ｗｏｌｂｅｒｇによる'&apos;Ｄｉｇｉｔａｌ Ｉｍａｇｅ Ｗａｒｐｉｎｇ'&apos;， ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｐｒｅｓｓ，
Ｌｏｓ Ａｌａｍｉｔｏｓ，
Ｃａｌｉｆｏｒｎｉａ， 
１９９０である。ワーピングプロセスは、Ａｒｔｃａｒｄ９によって供給されたデータの一部を形成するワープマップを使用する。ワープマップは、必要条件に応じて任意的に寸法を決めることができ、入力画素の出力画素へのマッピングの情報を提供する。残念なことに、任意的に寸法を決められたワープマップの利用は、画像ワーパーによって解決されるべき多数の問題を生じる。
【０６７５】
図８５を参照すると、Ａ×Ｂ次元のワープマップ３６５は、ある大きさ（例えば、０から２５５の８ビット値）の配列値により構成され、この配列値は理論的な入力画像の座標を表現し、理論的な入力画像の座標は同じ配列座標インデックスを有する対応した「理論的な」出力画像へマップされる。残念ながら、出力画像、例えば、出力画像３６６は固有の次元Ｃ×Ｄを有し、これは、固有の次元Ｅ×Ｆを有する入力画像とは全く異なる。したがって、出力画像３６６が、出力画素毎に、対応した入力画像のエリア又は領域を決定できるように、ワープマップ３６５のマッピングを容易に行えるようにする必要がある。出力画素色データは、対応した入力画像のエリア又は領域から構築される。出力画像３６６内の各出力画素に対して、最初に、ワープマップ３６５から対応したワープマップ値を決定することが必要である。このため、出力画像画素がワープマップテーブル３６５内の小数位置にマッピングされるときに、周辺ワープマップ値をバイリニア補間することが必要である。このプロセスの結果は、ワープマップ３６５内の各データ値のサイズによって寸法が決められる「理論的な」画像内での入力画像画素の位置を与える。これらの値は、理論的な画像を対応した実際の入力画像３６７へマッピングするため再度スケーリングしなければならない。
【０６７６】
実際の値を決定するため、出力画像画素はエイリアシング効果を回避するように選ばれるべきであり、最終的な出力画像画素値に寄与する入力画像画素３６７の領域を決定するために隣接した出力画像画素を調べる必要がある。この点に関して、以下でより明らかにされるように、画像ピラミッドが利用される。
【０６７７】
画像ワーパーは画像をワープさせるため以下の幾つかのタスクを実行する：
−出力画像サイズに一致するようにワープマップをスケーリングする；
−各出力画素に表現される入力画像画素の領域のスパンを決定する；
−入力画像ピラミッドからトライリニア補間によって最終的な出力画素値を計算する。
【０６７８】
ワープマップスケーリング
前述の通り、データ駆動型ワープでは、ワープマップは、出力画素毎に、対応した入力画像マップの中心を記述することが必要である。前述のように単一ワープマップを用いる代わりに、インターリーブされたｘ及びｙ値情報を格納すると、Ｘ座標及びＹ座標を別個のチャンネルとして取り扱うことが可能である。
【０６７９】
その結果として、好ましくは、二つのワープマップが設けられ、ＸワープマップはＸ座標のワーピングを表し、ＹワープマップはＹ座標のワーピングを示す。前述のように、ワープマップ３６５は、スケーリング中の画像とは異なる空間解像度でもよい（例えば、３２×３２ワープマップ３６５は、１５００×１０００画像３６６のワープを適切に記述する）。その上、ワープマップは、ワープ中の画像のサイズに対応した８又は１６ビット値によって表現可能である。
【０６８０】
所定のワープマップから入力画像空間に点を生成するために幾つかのステップが含まれる：
１．出力画像に対してワープマップ内に対応した位置を決定する；
２．次のステップのため、ワープマップから値をフェッチする（これは、ワープマップがほんの８ビット値である場合に、解像度ドメインにおけるスケーリングを必要とする）；
３．実際の値を決定するためワープマップのバイリニア補間を行う；
４．入力画像ドメインに対応するように値をスケーリングする。
【０６８１】
最初のステップは、出力画像における現在のＸ／Ｙ座標にスケール倍率（ＸとＹで異なる場合がある）を乗算することにより実行される。例えば、出力画像が１５００×１０００であるならば、ワープマップは１５０×１００であり、ＸとＹの両方は１／１０によってスケーリングされている。
【０６８２】
ワープマップから値をフェッチするためには、二つのルックアップテーブルにアクセスすることが必要である。一方のルックアップテーブルは、ルックアップテーブルから８又は１６ビットのエントリーを読み出し、常に１６ビット値を返す（元の値が８ビットしかない場合、上位８ビットをクリアする）。
【０６８３】
パイプラインの次のステップは、参照されたワープマップ値をバイリニア補間することである。
【０６８４】
最後に、バイリニア補間からの結果がスケーリングされ、ワープされるべき画像と同じドメインに収容される。このようにして、ワープマップのレンジが０から２５５である場合、Ｘを１５００／２５５でスケーリングし、Ｙを１０００／２５５でスケーリングする。
【０６８５】
補間プロセスは図８６に示されているようなプロセスであり、以下の定数がソフトウェアによってセットされる。
【０６８６】
【表６１】
0004309954.tif 000087
以下のルックアップテーブルが使用される。
【０６８７】
【表６２】
0004309954.tif 000088
スパン計算
ワープマップ３６５からの点は入力画像３６７内の画素領域の中心の位置を示す。隣接した出力画像画素の入力画像画素の間の距離は領域のサイズを示し、この距離は、スパン計算によって近似することができる。
【０６８８】
図８７を参照すると、ワープマップＰ１の所定の現在点に対して、同じライン上の前のポイントはＰ０であり、前のラインの同じ位置にあるポイントはＰ２である。Ｐ１とＰ０の間、並びに、Ｐ１とＰ２の間で、Ｘ及びＹの絶対距離を決定する。Ｘ又はＹの最大距離は、実際の形状を近似する正方形であるスパンになる。
【０６８９】
好ましくは、点は、垂直方向ストリップの出力順に処理され、Ｐ０はストリップ内の同じ線で先行する点であり、Ｐ１がストリップ内の最初の点であるとき、Ｐ０は、前のストリップの対応した線の最後の点を表す。Ｐ２は同一ストリップ内の前の線の点であるため、３２エントリーの履歴バッファに保持され得る。スパン計算プロセスの原理は図８８に示され、そのプロセスの詳細は図８９に示されている。
【０６９０】
以下のＤＲＡＭのＦＩＦＯが使用される。
【０６９１】
【表６３】
0004309954.tif 000089
３２ビット精度のスパン履歴が保持されるので、１５００画素幅の画像がワープされる場合、１２０００バイトの一時記憶が必要になる。
【０６９２】
スパン３６４の計算は、二つのアダーＡＬＵ（一方はスパン計算用であり、もう一方はＰ０及びＰ２の履歴をループしカウントするためのものである）を使用し、以下のように７サイクルを要する。
【０６９３】
【表６４】
0004309954.tif 000090
履歴バッファ３６５、３６６は、キャッシュ型のＤＲＡＭである。「前のライン」（Ｐ２履歴の場合）バッファ３６６は、３２エントリーのスパン精度である。「前の点」（Ｐ０履歴の場合）バッファ３６５は、（ストリップの線の点１から３１の計算のため）殆どの場合に使用される１個のレジスタを必要とし、ＤＲＡＭにバッファされた履歴値の組はストリップの線の点０の計算に使用される。
【０６９４】
スパン履歴の３２ビット精度は、Ｐ２履歴を保持するため４本のキャッシュラインと、Ｐ０履歴のための２本のキャッシュラインと、を必要とする。Ｐ０の履歴は、３２画素からなる８本の線毎に１回ずつ、（ImageHeight＊４）バイトの一時記憶空間に書き込まれ、読み出される。このようにして、１５００画素の高さの画像がワープされるとき、６０００バイトの一時記憶が必要であり、全部で６本のキャッシュラインが必要である。
【０６９５】
トライリニア補間
平均化されるべき入力画像からエリアの中心及びスパンを決定した後、ワーププロセスの最終部分は、出力画素の値を決定することである。単一の出力画素は、理論的に入力画像全体によって表現できるので、出力画素に寄与する入力画像の特定のエリアを実際に読み出し平均化するためには、非常に時間を消費する可能性がある。その代わりとして、入力画像の画像ピラミッドを使用することにより画素値を近似することができる。
【０６９６】
スパンが１以下である場合、所与の座標の周辺で原画像の画素を読み出し、バイリニア補間を実行するだけでよい。スパンが１よりも大きい場合、二つの適切なレベルの画像ピラミッドを読み出し、トライリニア補間を実行する必要がある。二つのレベルの画像ピラミッドの間にリニア補間を実行することは、厳密に正確ではないが、許容可能な結果を与える（それは結果画像にブラー効果が生じる側で判断を誤る）。
【０６９７】
図９０を参照すると、一般的には、あるスパン「ｓ」が与えられた場合に、ln2s（３７０）及びln2s+1（３７１）によって与えられる画像ピラミッドレベルを読み出すことが必要である。Ln2sは、ｓの上位ビットセットを復号化するだけである。ピラミッドの二つのレベル３７０、３７１の各々で画素値の値を決定するためバイリニア補間を実行し、レベル間で補間を実行しなければならない。
【０６９８】
図９１に示されるように、最終的な出力値３７３を得るため、ピラミッドレベル間で補間を行う前に、最初に各画素ピラミッドレベルのＸ及びＹに関して補間を行うことが必要である。
【０６９９】
画像ピラミッドアドレスモードは、ピラミッドレベルｓ及びｓ＋１上の（ｘ，ｙ）における画素座標に対するアドレスを生成する。各レベルの画像ピラミッドは、ｘの方向に連続した画素を格納する。したがって、ｘに関する読み出しはキャッシュヒットする可能性が高い。
【０７００】
適度なキャッシュヒットのコヒーレンスは、出力画像の局所領域が典型的に入力画像と局所的にコヒーレントである（おそらく、スケールは異なるが、同じスケールでコヒーレントである）ときに獲得される。入力画像と出力画像との関係を知ることはできないが、出力画素は、キャッシュコヒーレンスを最大限に利用するため、（垂直ストリップイタレータによって）確実に垂直ストリップに書き込まれる。
【０７０１】
トライリニア補間は、パイプラインとして４個の乗算ＡＬＵ及び４個全てのアダーＡＬＵを使用し、メモリアクセスの必要がない場合を想定すると、平均的に２サイクル程度で完了し得る。しかし、全ての補間値は画像ピラミッドから得られるので、補間速度はキャッシュコヒーレンスに完全に依存する（その他のユニットはワープマップスケーリング及びスパン計算を実行するためビジーであることは言うまでもない）。できるだけ多数のキャッシュラインを画像ピラミッド読み出しのために利用できるべきである。最良の速度は、２個の乗算ＡＬＵを使用して８サイクルである。
【０７０２】
出力画素は、二つのキャッシュラインを使用する垂直ストリップ書き込みイタレータによってＤＲＡＭに書き込まれる。この速度は、従って、１出力画素当たりに８サイクルの最小値で制限される。ワープマップのスケーリングに必要なサイクルが８サイクル以下であるならば、全体的な速度は変化しない。さもなければ、スループットはワープマップをスケーリングするために要する時間である。殆どの場合に、ワープマップは写真のサイズと適合するまで拡大される。
【０７０３】
１画素当たりに必要なサイクル数が８サイクル以下のワープマップをスケーリングする場合、画像の１個のカラーコンポーネントを変換するための所要時間は０．１２秒（１５００＊１０００＊８サイクル＊１サイクル当たりに１０ｎｓ）である。
【０７０４】
ヒストグラムコレクタ
ヒストグラムコレクタは、入力として画像チャンネルを取得し、出力としてヒストグラムを生成するマイクロコードプログラムである。チャンネルの画素の各々は、レンジ０−２５５に収まる値をとる。その結果として、ヒストグラムテーブルには全部で２５６画素が存在し、各エントリーは３２ビットであり、１５００×１０００の全画像のカウントを十分に収容することができる。
【０７０５】
図９２に示されるように、ヒストグラムは全画像の要約を表現するので、順次読み出しイタレータ３７８は入力として十分にである。ヒストグラム自体は、完全にキャッシュされ、３２個のキャッシュライン（１Ｋ）を必要とする。
【０７０６】
マイクロコードは二つのパスを有し、初期化パスでは、全てカウントを０にセットし、次に、「カウント」ステージは、画像から読み出された各画素の適切なカウンタをインクリメントする。第１のステージは、アドレスユニットと単一のアダーＡＬＵとを必要とし、ヒストグラムテーブル３７７のアドレスを初期化する。
【０７０７】
【表６５】
0004309954.tif 000091
第２のステージは、画像からの実際の画素を処理し、４個のアダーＡＬＵを使用する。
【０７０８】
【表６６】
0004309954.tif 000092
アダー２のサイクル２からの零フラグは、入力画素が同じである間、マイクロコードアドレス２に留まるため使用される。入力画素が変化したとき、新しいカウントはマイクロコードアドレス３に書き出され、処理はマイクロコードアドレス２で再開する。マイクロコードアドレス４は最後に使用され、それ以上読み出される画素は存在しない。
【０７０９】
ステージ１は、２５６サイクル、即ち、２５６０ｎｓを要する。ステージ２は、画素の値に応じて変わる。ルックアップテーブル置換のための最悪ケースの時間は、あらゆる画素がその近傍と同じではない場合に、１画像画素当たりに２サイクルである。単一カラーのルックアップに要する時間は０．０３秒（１５００×１０００×１画素当たり２サイクル×１サイクル当たり１０ｎｓ＝３０００００００ｎｓ）である。３個のカラーコンポーネントに要する時間はこの量の３倍、即ち、０．０９秒である。
【０７１０】
色変換
色変換は、
ルックアップテーブル置換、及び
色空間変換
の二つの主要な方法で実現される。
【０７１１】
ルックアップテーブル置換
図８６に示されるように、画素の色を変換するための最も簡単な方法の一つは、任意に複雑な変換関数をルックアップテーブル３８０にエンコードすることである。画素のコンポーネントカラー値は、画素の新しいコンポーネント値をルックアップ３８１するため使用される。順次読み出しイタレータから読み出された画素毎に、その新しい値が新カラーテーブル３８０から読み出され、順次書き込みイタレータ３８３へ書き込まれる。入力画像は、メモリ帯域幅を効率的に利用するため、半分ずつ同時に処理される。以下のルックアップテーブルが使用される。
【０７１２】
【表６７】
0004309954.tif 000093
総プロセスは、二つの順次読み出しイタレータ及び二つの順次書き込みイタレータを必要とする。二つの新カラーテーブルは、２５６バイト（１バイトからなる２５６個のエントリー）を保持するため、各々に８個のキャッシュラインが必要である。
【０７１３】
したがって、ルックアップテーブル置換に要する平均時間は１画像画素当たり１／２サイクルである。単一カラーのルックアップに要する時間は０．００７５秒（１５００×１０００×１画素当たり１／２サイクル×１サイクル当たり１０ｎｓ＝７５０００００ｎｓ）である。三つのカラーコンポーネントのための所要時間はこの量の３倍、即ち、０．０２２５秒である。各カラーコンポーネントは、ソフトウェアの制御下で次々に処理される。
【０７１４】
色空間変換
色空間変換は、色空間の間を動くときに限り必要である。ＣＣＤ画像はＲＧＢ色空間で撮影され、印刷はＣＭＹ色空間で行われ、一方、ＡＣＰ３１のクライアントは、Ｌａｂ色空間で画像を処理する可能性が高い。入力色空間チャンネルの全ては、典型的に、各出力チャンネルのコンポーネント値を決定するために要求される。このような論理的プロセスが図９４の３８５に示されている。
【０７１５】
簡潔に言うと、Ｌａｂ、ＲＧＢ及びＣＭＹの間の変換は、かなり簡単である。しかし、特定の装置の個別の色プロファイルは著しく変化し得る。その結果として、将来のＣＣＤ、インク、及びプリンタを可能にさせるため、ＡＣＰ３１は、色空間変換ルックアップテーブルからのトライリニア補間によって色空間変換を実行する。
【０７１６】
色コヒーレンスは、線ベースではなく、エリアベースである傾向がある。トライリニア補間ルックアップ中にキャッシュコヒーレンスを補助するため、画像を垂直ストリップで処理することが最良である。このようにして、読み出しイタレータ３８６−３８８及び書き出しイタレータ３８９は、垂直ストリップイタレータである。
【０７１７】
トライリニア色空間変換
各出力カラーコンポーネントに対して、入力色空間を出力色空間へマッピングする単一の３次元テーブルが必要になる。例えば、ＣＣＤ画像をＲＧＢからＬａｂへ変換するため、ＣＣＤの物理的特性に較正された３個のテーブル、即ち、
ＲＧＢ->Ｌ
ＲＧＢ->ａ
ＲＧＢ->ｂ
が必要になる。
【０７１８】
ＬａｂからＣＭＹへ変換するため、インク／プリンタの物理的特性に較正された３個のテーブル、即ち、
Ｌａｂ->Ｃ
Ｌａｂ->Ｍ
Ｌａｂ->Ｙ
が必要になる。
【０７１９】
８ビット入力カラーコンポーネントは、変換テーブルへのインデックス付けのため、固定小数点数（３：５）として取り扱われる。整数の３ビットはインデックスを与え、小数の５ビットは補間として使用される。３ビットは８個の値を与えるので、３次元で５１２エントリー（８×８×８）が得られる。各エントリーのサイズは１ビットであり、１テーブル当たり５１２バイトが必要である。
【０７２０】
したがって、色空間変換プロセスは図９５に示されるように実装され、以下のルックアップテーブルが使用される。
【０７２１】
【表６８】
0004309954.tif 000094
トライリニア補間は、８個の値の間の補間を返す。ルックアップから各８ビット値を返すために１サイクルを要し、全部で８サイクルを要する。トライリニア補間は、１サイクル当たり２個の乗算ＡＬＵが使用されたとき、８サイクルを使用する。一般的なトライリニア補間情報はこの文書のＡＬＵセクションに記載されている。ルックアップテーブル用の５１２バイトは１６個のキャッシュラインに詰め込まれる。
【０７２２】
画像の単一のカラーコンポーネントを変換するための時間は０．１０５秒（１５００＊１０００＊７サイクル＊１サイクル当たり１０ｎｓ）である。３コンポーネントを変換するため、０．４１５秒を要する。都合良く、プリントアウト用の色空間変換は、プリントアウト中にオンザフライ方式で行われる。
【０７２３】
カラーコンポーネントが別々に変換される場合、それらは入力色空間コンポーネントを上書きしなければならない。なぜならば、入力色空間からの全てのカラーコンポーネントは各コンポーネントを変換するために必要になるからである。
【０７２４】
補間を実行するために１個の乗算ユニットだけが使用されるので、Ｌａｂ->ＣＭＹ変換の全体を単一パスとして行うことが可能である。このためには、三つの垂直ストリップ読み出しイタレータと、三つの垂直ストリップ書き込みイタレータと、が必要であり、３個の変換テーブルに同時にアクセスする。その場合、入力画像へ書き戻し、余分なメモリを使用しないことも可能である。しかし、３個の変換テーブルへのアクセスは、各々に対するキャッシュ処理の１／３に相当し、プロセス全体では高いレイテンシーを生じることになる。
【０７２５】
アフィン変換
写真を用いて画像をコンポジットする前に、画像を回転、スケーリング、及び並進することが必要である。画像が並進だけされている場合、直接的なサブピクセル平行移動関数を使用する方が高速になる。しかし、回転、拡大、及び並進は、単一のアフィン変換に組み込むことができる。
【０７２６】
汎用アフィン変換は、加速関数として組み込みことが可能である。アフィン変換は２次元に制限され、縮小される場合、入力画像はスケール関数によって予めスケーリングされるべきである。汎用アフィン変換を備えることにより、出力画像を同時に１ブロックずつ構築することが可能になり、画像に対して多数の変換を実行するために要する時間を削減できる。なぜならば、多数の変換の全てを同時に適用できるからである。
【０７２７】
変換行列はクライアントによって与えられる必要があり、行列は、望まれる変換の逆行列でなければならない。即ち、その行列を出力画素座標に適用することによって入力座標が得られる。
【０７２８】
２次元行列は、通常、以下の３×３配列、即ち、
【０７２９】
【数１】
0004309954.tif 000095
によって表現される。
【０７３０】
第３列は常に［０，０，１］であるため、クライアントはそれを指定しなくてもよい。その代わりに、クライアントはａ，ｂ，ｃ，ｄ，ｅ，ｆを指定する。
【０７３１】
左上画像画素の座標が（０，０）として表される入力画像内の座標（ｘ，ｙ）が与えられた場合、入力座標は、（ａｘ＋ｃｙ＋ｅ，ｂｘ＋ｄｙ＋ｆ）によって指定される。入力座標が決定されると、入力画像は、その画素値に達するためサンプリングされる。入力画像画素のバイリニア補間は、計算された座標における画素の値を決定するため使用される。アフィン変換は平行線を保存するので、画像は、最高の平均入力画像キャッシュコヒーレンスを得るため３２画素幅の出力垂直ストリップで処理される。
【０７３２】
３個の乗算ＡＬＵは、バイリニア補間を２サイクル内で実行するために必要である。乗算ＡＬＵ１及び２は、線Ｙ及び線Ｙ＋１のそれぞれについてＸに関してリニア補間を実行し、乗算ＡＬＵ３は、乗算ＡＬＵ１及び２によって出力された値の間でＹに関するリニア補間を実行する。
【０７３３】
Ｘに関して出力線を横切って右へ移動するとき、２個のアダーＡＬＵは、「ａ」を現在のＸ値に加算し、「ｂ」を現在のＹ値に加算することによって、実際の入力画像座標を計算する。次の線（最大で３２画素を処理した後の垂直ストリップ内の次の線、又は新しい垂直ストリップの最初の線）へ進んだとき、Ｘ及びＹを所与のブロックに対する予め計算されたスタート座標値定数に更新する。
【０７３４】
入力座標を計算するプロセスは図９６に示され、同図では、以下の定数がソフトウェアによってセットされる。
【０７３５】
画素計算
入力画像座標が得られると、入力画像をサンプリングする必要がある。ルックアップテーブルは、バイリニア補間の準備として指定された座標における値を返すため使用される。基本プロセスは図９７に示され、以下のルックアップテーブルが使用される。
【０７３６】
【表６９】
0004309954.tif 000096
アフィン変換は、全部で４個の乗算ＡＬＵ及び全部で４個のアダーＡＬＵを必要とし、良好なキャッシュコヒーレンスがある場合、１出力画素当たり平均２サイクルでアフィン変換を実行できる。このタイミングは優れたキャッシュコヒーレンスを前提とし、この前提は画像に歪みが無い場合には成立する。最悪ケースでは、画像がかなり歪み、重要なＶａｒｋスクリプトが含まれている可能性は低い。
【０７３７】
１２８×１２８画像を変換するために要する時間は、０．０００３３秒（３２７６８サイクル）である。これが４チャンネル（ａチャンネルを含む）を備えたクリップ画像である場合、必要な総時間は０．００１３１秒（１３１０７２サイクル）である。
【０７３８】
垂直ストリップ書き込みイタレータは画素を出力するため必要である。読み出しイタレータは不要である。しかし、アフィン変換アクセラレータは、入力画像画素にアクセスするために要する時間によって制約されるので、できるだけ多数のキャッシュラインが入力画像からの画素の読み出しに割り付けられるべきである。少なくとも３２が利用可能であり、好ましくは、６４以上が利用可能である。
【０７３９】
スケーリング
スケーリングは、基本的に画像の再サンプリングである。画像の拡大はアフィン変換関数を用いて実行できる。縮小を含む一般化された画像のスケーリングは、ハードウェア加速型スケール関数によって行われる。スケーリングはＸ及びＹに関して独立に行われるので、異なるスケール倍率を各次元で使用することができる。一般化されたスケールユニットは、位置合わせに関して、アフィン変換スケール関数と適合しなければならない。
【０７４０】
一般化されたスケーリングプロセスは図９８に示されている。Ｘに関するスケールは図９９に示されるようにＦａｎｔの再サンプリングアルゴリズムによって達成される。
【０７４１】
以下の定数がソフトウェアによってセットされる。
【０７４２】
【表７０】
0004309954.tif 000097
以下のレジスタは一時変数を保持するため使用される。
【０７４３】
【表７１】
0004309954.tif 000098
Ｙに関するスケールプロセスは図１００に示され、Ｘ画素の順番の処理を考慮するためＦａｎｔの再サンプリングアルゴリズムの僅かに変更されたバージョンによっても実現される。
【０７４４】
以下の定数がソフトウェアによってセットされる。
【０７４５】
【表７２】
0004309954.tif 000099
以下のレジスタが一時変数を保持するため使用される。
【０７４６】
【表７３】
0004309954.tif 000100
以下のＤＲＡＭ ＦＩＦＯが使用される。
【０７４７】
【表７４】
0004309954.tif 000101
画像モザイク処理
画像のモザイク処理はタイリングの一形態である。モザイク処理は、特別に設計された「タイル」を、水平方向及び垂直方向に複数回、第２の（通常はより大きい）画像空間へコピーする処理を含む。モザイク処理されたとき、小さいタイルは継ぎ目のないピクチャーを形成する。この一例は、レンガ壁の区画の小さいタイルである。それは、モザイク処理されたときに、完全なレンガ壁を形成するように設計される。尚、モザイク処理には、スケーリング、又はサブピクセル平行移動が含まれないことに注意すべきである。
【０７４８】
モザイク処理を行うために最もキャッシュコヒーレントな方法は、画像をライン毎に順次に出力し、同じ入力画像のラインを、そのラインの区間の間、繰り返すことである。ラインが終了したとき、入力画像は次のラインへ進められるべきである（出力ラインをはさんで複数回それを繰り返すべきである）。
【０７４９】
モザイク関数の概要は図１０１の３９０に示されている。順次読み出しイタレータ３９２は入力タイルの単一ラインを連続して読み出すようにセットアップされる（スタートラインは０であり、エンドラインは１である）。各入力画素は、書き込みイタレータ３９３−３９５の三つ全てに書き込まれる。アダーＡＬＵのカウンタ３９７は、出力ライン中の画素数をカウントダウンし、ラインの最後にシーケンスを終了する。
【０７５０】
ラインの処理の最後に、小さいソフトウェアルーチンは、マイクロコード及び順次読み出しイタレータ（これは、ＦＩＦＯをクリアし、タイルのライン２を繰り返す）を再始動する前に、順次読み出しイタレータのスタートライン及びエンドラインレジスタを更新する。書き込みイタレータ３９３−３９５は更新されず、出力画像の対応した部分へ書き込み続けるだけである。正味の効果として、タイルが出力ラインをはさんで１ライン繰り返され、タイルが垂直方向に繰り返される。
【０７５１】
このプロセスはメモリ帯域幅を完全には使用しない。なぜならば、入力画像におけるキャッシュコヒーレンスは優れているが、モザイク処理を他のサイズのタイルと共に機能させることができないからである。このプロセスは、１個のアダーＡＬＵを使用する。３個の書き込みイタレータ３９３−３９５の各々が、画像の１／３に書き込む（画像をタイルサイズの境界に分割する）ならば、モザイクプロセスの全体は１出力画像画素当たり１／３サイクルの平均速度で行われる。１５００×１０００の画像の場合、これは、０．００５秒（５００００００ｎｓ）と一致する。
【０７５２】
サブピクセルトランスレータ
画像を背景とコンポジットする前に、Ｘ及びＹの両方に関してサブピクセル量で画像を平行移動させることが必要である。サブピクセル平行移動は、各次元に１画素ずつ画像のサイズを増加することができる。画像の外側の領域の値は、定数値（例えば、黒色）又はエッジ画素繰り返しのようなクライアントによって決定される値である。典型的に、黒色を使用する方がよい。
【０７５３】
サブピクセル平行移動プロセスは図１０２に示されている。所定の次元のサブピクセル平行移動は、
Pixelout = Pixelin * 
(1-Translation) + Pixelin-1 *
Translation
によって定義される。
【０７５４】
これは、補間の形式、即ち、
Pixelout= Pixelin-1 +
(Pixelin - Pixelin-1)
* Translation
として表現することができる。
【０７５５】
単一の乗算ＡＬＵ及び単一のアダーＡＬＵを組み合わせて使用する単一（又は平均）サイクル補間エンジンの実装は簡単である。Ｘ及びＹの両方に関するサブピクセル平行移動は、二つの補間エンジンを必要とする。
【０７５６】
Ｙに関するサブピクセル平行移動を行うため、二つの順次読み出しイタレータ４００、４０１が必要になり（一方は、同じ画像から他の画像よりも進んでいるラインを読み出す）、一つの順次書き込みイタレータ４０３が必要になる。
【０７５７】
第１の補間エンジン（Ｙに関する補間）は、二つのストリームからのデータペアを受け取り、それらの間を線形に補間する。第２の補間エンジン（Ｘに関する補間）は、単一の１次元ストリームとしてそのデータを受け取り、値の間を線形に補間する。両方のエンジンは平均として１サイクルで補間を行う。
【０７５８】
各補間エンジン４０５、４０６は、平均的に１出力画素当たり１サイクルでサブピクセル平行移動を実行する能力を備えている。したがって、全体的な時間は１出力画素当たり１サイクルであり、２個の乗算ＡＬＵと２個のアダーＡＬＵが必要である。
【０７５９】
サブピクセル平行移動関数から３２画素を出力するために要する時間は、平均で３２０ｎｓ（３２サイクル）である。これは、ＤＲＡＭへの完全な４個のキャッシュラインアクセスに十分な時間であり、３個の順次イタレータの使用はタイミング原価以内に十分に収まる。
【０７６０】
画像をサブピクセル平行移動するために要する総時間は、したがって、出力画像の１画素当たり１サイクルである。サブピクセル平行移動されるべき典型的な画像は、サイズ１２８＊１２８のタイルである。出力画像サイズは１２９＊１２９である。このプロセスは、１２９＊１２９＊１０ｎｓ＝１６６４１０ｎｓである。
【０７６１】
画像タイル貼り関数もサブピクセル平行移動アルゴリズムを使用するが、サブピクセル平行移動処理されたデータを書き出す必要はなく、そのデータを更に処理する。
【０７６２】
画像タイルタイラー
画像をタイル貼りする上位レベルアルゴリズムはソフトウェアで実行される。タイルの配置が決定されると、適切な着色タイルを合成しなければならない。各タイルの画像への実際のコンポジット処理は、マイクロコード化されたＡＬＵによってハードウェアで行われる。タイルのコンポジット処理は、背景画像へのテクスチャ貼り付けとカラー貼り付けの両方を含む。ある種のケースでは、背景に加えられる実際のテクスチャ量と、予定されたテクスチャ量とを比較し、貼り付けられるカラーをスケーリングするためこれを使用することが望ましい。これらのケースでは、テクスチャを先に貼り付けることが必要である。
【０７６３】
カラー貼り付け機能及びテクスチャ貼り付け機能はある程度独立しているので、これらはサブ関数に分離される。
【０７６４】
種々のテクスチャスタイル及びカラーリングスタイルのための４チャンネルタイルコンポジット当たりのサイクル数は以下の表に要約されている。
【０７６５】
【表７５】
0004309954.tif 000102
タイルカラーリング及びコンポジット処理
タイルは、（タイル全体に）一定色を具備するか、又は入力画像から各画素値を取るようにセットされる。これらの両方のケースは、不透明度を拡大縮小するため、テクスチャ処理ステージからのフィードバックがある（シニングペイントと同様）。
【０７６６】
４ケースに対するステップは以下のように要約できる：
−タイルの不透明度値をサブピクセル平行移動する；
−（テクスチャ貼り付けからのフィードバックが有効である場合）タイルの不透明度を選択的にスケーリングする；
−画素の色を（一定に、又は画像マップから）決定する；
−画素を背景画像上でコンポジットする。
【０７６７】
４ケースの各々は、関数を実行するために要する時間を最小限に抑えるため、別々に取り扱われる。単一カラーチャンネルのカラーコンポジット処理スタイル当たりの時間は以下の表に要約されている。
【０７６８】
【表７６】
0004309954.tif 000103
一定色
この場合、タイルは、ソフトウェアによって決定された一定色を具備する。ＡＣＰ３１が一つのタイルを設置する間に、ソフトウェアは次のタイルの配置及びカラーリングを決定することができる。
【０７６９】
タイルの色は、タイル貼りされている画像をスケーリングした画像へのバイリニア補間によって決定することが可能である。スケーリングされた画像は、作成し、画像ピラミッドの所定の位置に保存することが可能であり、タイル演算の全体に対して１回だけ実行すればよい。サイズが１２８×１２８である場合、画像は、各次元に関して、１２８：１で縮小される。
【０７７０】
フィードバック無し
タイルのテクスチャ処理からのフィードバックが無いとき、タイルは、指定された座標に設置されるだけである。タイル色は、画素の色毎に使用され、コンポジットのための不透明度は、タイルのサブピクセル平行移動処理された不透明度チャンネルから由来する。このケースでは、カラーチャンネル及びテクスチャチャンネルは、タイル貼りパスの間に完全に独立して処理可能である。
【０７７１】
プロセスの概要は図１０３に示されている。タイルのサブピクセル平行移動４１０は、１出力画素当たり１サイクルの平均時間の場合、２個の乗算ＡＬＵ及び２個のアダーＡＬＵを使用して実行することができる。サブピクセル平行移動からの出力は、背景順次読み出しイタレータからの背景画像で一定タイル色４１２をコンポジット処理４１１する際に使用されるべきマスクである。
【０７７２】
コンポジット処理は、１コンポジット当たり１サイクルの平均時間の場合、１個の乗算ＡＬＵ及び１個のアダーＡＬＵを用いて実行できる。したがって、必要条件は、３個の乗算ＡＬＵ及び３個のアダーＡＬＵである。４個の順次イタレータ４１３−４１６が必要であり、それらの内容を読み書きするために３２０ｎｓを要する。サブピクセル並行移動及びコンポジットのために要する１画素当たりの平均サイクル数の場合、バッファを読み書きするための十分な時間がある。
【０７７３】
フィードバック付き
タイルのテクスチャ処理からのフィードバックがあるとき、タイルは指定された座標に配置される。タイル色は、画素の色毎に使用され、コンポジットのための不透明度は、フィードバックパラメータによってスケーリングされたサブピクセル平行移動処理された不透明度チャンネルから由来する。このようにして、テクスチャ値は、カラー値が貼り付けられる前に計算しなければならない。
【０７７４】
プロセスの概要は図９７に示されている。タイルのサブピクセル平行移動は、１出力画素当たり１サイクルの平均時間の場合、２個の乗算ＡＬＵ及び２個のアダーＡＬＵを使用して実行することができる。サブピクセル平行移動からの出力は、フィードバック順次読み出しイタレータ４２０から読み出されたフィードバックに応じてスケーリングされるべきマスクである。このフィードバックはスケーラ（１個の乗算ＡＬＵ）４２１へ送られる。
【０７７５】
コンポジット処理４２６は、１コンポジット当たり１サイクルの平均時間の場合、１個の乗算ＡＬＵ及び１個のアダーＡＬＵを用いて実行できる。したがって、必要条件は、４個の乗算ＡＬＵ及び４個のアダーＡＬＵである。プロセス全体は、平均的に１サイクル内で完了可能であるが、ボトルネックはメモリアクセスである。なぜならば、５個の順次イタレータが必要になるからである。十分なバッファリングが行われる場合、平均時間は１画素当たり１．２５サイクルである。
【０７７６】
入力画像からの色
タイルの画素に着色する一つの方法は、入力画像の画素から色を取り出すことである。ここでも、コンポジット処理には、テクスチャ処理からのフィードバック付きとフィードバック無しの二つの可能性がある。
【０７７７】
フィードバック無し
この場合、タイル色は、入力画像内の対応する画素から簡単にもたらされる。コンポジット処理用の不透明度は、サブピクセルシフトされたタイルの不透明度チャンネルに由来する。
【０７７８】
プロセスの概要は図１０５に示されている。タイルのサブピクセル平行移動４２５は、１出力画素当たり１サイクルの平均時間の場合、２個の乗算ＡＬＵ及び２個のアダーＡＬ
Ｕを使用して実行することができる。サブピクセル平行移動からの出力は、（入力画像４２８から読み出された）タイルの画素色を背景画像４２９とコンポジット処理４２６する際に使用されるべきマスクである。このフィードバックは、スケーラ（１個の乗算ＡＬＵ）４３１へ送られる。
【０７７９】
コンポジット処理４３４は、１コンポジット当たり１サイクルの平均時間の場合、１個の乗算ＡＬＵ及び１個のアダーＡＬＵを用いて実行できる。したがって、必要条件は、３個の乗算ＡＬＵ及び３個のアダーＡＬＵである。プロセス全体は平均して１サイクル以内に完了可能であるが、ボトルネックはメモリアクセスである。なぜならば、５個の順次イタレータが必要になるからである。十分なバッファリングが行われる場合、平均時間は１画素当たり１．２５サイクルである。
【０７８０】
フィードバック付き
この場合、タイル色は、やはり入力画像内の対応する画素から簡単にもたらされるが、コンポジット処理用の不透明度は、テクスチャ処理パス中に実際に適用されたテクスチャ高さの相対的な量による影響を受ける。このプロセスは図１０６に示されている。
【０７８１】
タイルのサブピクセル平行移動４３１は、１出力画素当たり１サイクルの平均時間の場合、２個の乗算ＡＬＵ及び２個のアダーＡＬＵを使用して実行することができる。サブピクセル平行移動からの出力は、フィードバック順次読み出しイタレータ４３２から読み出されたフィードバックに応じてスケーリング４３１されるべきマスクである。
【０７８２】
コンポジット処理は、１コンポジット当たり１サイクルの平均時間の場合、１個の乗算ＡＬＵ及び１個のアダーＡＬＵを用いて実行できる。
【０７８３】
したがって、必要条件は、４個の乗算ＡＬＵ及び３個のアダーＡＬＵである。プロセス全体は平均して１サイクル以内に完了可能であるが、ボトルネックはメモリアクセスである。なぜならば、６個の順次イタレータが必要になるからである。十分なバッファリングが行われる場合、平均時間は１画素当たり１．５サイクルである。
【０７８４】
タイルテクスチャ処理
各タイルはそのテクスチャチャンネルによって定義される表面テクスチャを有する。テクスチャは、サブピクセルへ移行移動され、次に、出力画像に貼り付けられる。テクスチャコンポジット処理には、
テクスチャ配置と、
２５％背景＋タイルのテクスチャと、
平均高さアルゴリズムと、
の３種類のスタイルがある。
【０７８５】
更に、平均高さアルゴリズムはカラーコンポジット処理のためのフィードバックパラメータを節約する。
【０７８６】
テクスチャコンポジット処理スタイル毎に要する時間は以下の表に要約される。
【０７８７】
【表７７】
0004309954.tif 000104
テクスチャ置換
このケースでは、タイルからのテクスチャは、図１０７に示されるように、画像のテクスチャチャンネルを置き換える。タイルのテクスチャのサブピクセル平行移動４３６は、１出力画素当たり１サイクルの平均時間で、２個の乗算ＡＬＵ及び２個のアダーＡＬＵを使用して実行できる。サブピクセル平行移動からの出力は、順次書き込みイタレータ４３７へそのまま供給される。
【０７８８】
テクスチャ置換コンポジット処理に要する時間は１画素当たり１サイクルである。テクスチャ値の１００％が常に背景に貼り付けられるので、フィードバックは無い。したがって、チャンネルを特定の順序で処理する必要はない。
【０７８９】
２５％背景＋タイルのテクスチャ
この例では、タイルからのテクスチャは既存テクスチャ値の２５％に加えられる。新しい値は元の値以上でなければならない。その上、テクスチャチャンネルは８ビットしかないので、新しいテクスチャ値は２５５でクリップされる。利用されるプロセスは図１０８に示されている。
【０７９０】
タイルのテクスチャのサブピクセル平行移動４４０は、１出力画素当たり１サイクルの平均時間で、２個の乗算ＡＬＵ及び２個のアダーＡＬＵを使用して実行できる。サブピクセル平行移動４４０からの出力は、アダー４４１へ供給され、背景テクスチャ値の１／４ 
４４２に加算される。最小値及び最大値関数４４４は、サブピクセル平行移動のために使用されない２個のアダーによって設けられ、出力は順次書き込みイタレータ４４５に書き込まれる。
【０７９１】
このスタイルのテクスチャコンポジット処理のために要する時間は１画素当たり１サイクルである。テクスチャ値の１００％は、（たとえ、２５５でクリッピングされたとしても）背景に貼り付けられたと考えられるので、フィードバックは無い。したがって、チャンネルを特定の順序で処理する必要はない。
【０７９２】
平均高さアルゴリズム
このテクスチャ貼り付けアルゴリズムでは、タイルに基づいて平均高さが計算され、各画像の高さは平均高さと比較される。画素の高さが平均よりも小さい場合、ストローク高さが背景高さに加えられる。画素の高さが平均以上である場合、ストローク高さが平均高さに加えられる。このようにして、背景ピークはストロークを細くする。この高さは、背景がストローク貼り付けを０まで細くすることを避けるため、最小限の量で増加するように拘束される（しかし、最小限の量は０になり得る）。高さは、テクスチャチャンネルが８ビット解像度であるため、２５５で切り取られる。
【０７９３】
貼り付けられたテクスチャと貼り付けられる予測量との差のフィードバックが存在し得る。フィードバック量は、タイルの色の貼り付けの際に倍率として使用可能である。
【０７９４】
両方のケースで、平均テクスチャは、ソフトウェアによって提供され、スケーリングされたテクスチャマップに関するバイレベル補間を実行することにより計算される。ソフトウェアは、現在のタイルが貼り付けられている間に、次のタイルの平均テクスチャ高さを決定する。ソフトウェアは、付加する最小限の厚さを与え、この最小限の厚さは、典型的に、タイル貼り付けプロセスの全体で一定である。
【０７９５】
フィードバック無し
フィードバックが無い場合、テクスチャは、図１０９に示されるように、背景テクスチャに貼り付けられるだけである。
【０７９６】
４個の順次イタレータが必要であり、これは、プロセスが１サイクルの間でパイプライン化できるならば、メモリの高速性が遅れないために十分であることを意味する。
【０７９７】
タイルのテクスチャのサブピクセル平行移動４５０は、１出力画素当たり１サイクルの平均時間で、２個の乗算ＡＬＵ及び２個のアダーＡＬＵを使用して実行できる。最小値及び最大値関数４５１、４５２は、１サイクル以内に全演算を完了するため、別個のアダーＡＬＵを必要とする。テクスチャのサブピクセル平行移動によって既に２が使用されているので、１サイクル平均時間のために十分な残り時間が無い。
【０７９８】
したがって、１画素のテクスチャを処理するための平均時間は２サイクルである。フィードバックが存在せず、コンポジット処理のカラーチャンネルの順序は無関係であることに注意する必要がある。
【０７９９】
フィードバック付き
これは、概念的にはフィードバック無しの場合と同じであるが、但し、標準的なテクスチャ貼り付けアルゴリズムの処理の他に、実際に貼り付けられたテクスチャの割合を記録しなければならない。この割合は、引き続きタイルの色を背景画像にコンポジット処理するための倍率として使用可能である。フローチャートは図１１０に示され、以下のルックアップテーブルが使用される。
【０８００】
【表７８】
0004309954.tif 000105
ソフトウェアで設けられた１／Ｎテーブル４６０の２５６個のエントリーの各々は１６ビットであり、連続して保持するため１６個のキャッシュラインが必要である。
【０８０１】
タイルのテクスチャのサブピクセル平行移動４６１は、１出力画素当たり１サイクルの平均時間で、２個の乗算ＡＬＵ及び２個のアダーＡＬＵを使用して実行できる。最小値関数４６２及び最大値関数４６３の各々は、１サイクル以内に全演算を完了するため、別個のアダーＡＬＵを必要とする。テクスチャのサブピクセル平行移動によって既に２が使用されているので、１サイクル平均時間のために十分な残り時間が無い。
【０８０２】
したがって、１画素のテクスチャを処理するための平均時間は２サイクルである。フィードバックデータエリア（タイルサイズの画像チャンネル）のために十分な空間を割り付けるべきである。テクスチャは、タイルの色が貼り付けられる前に貼り付けられるべきである。なぜならば、フィードバックがタイルの不透明度をスケーリングするため使用されるからである。
【０８０３】
ＣＣＤ画像インターポレータ
ＩＳＩ８３（図３）によってＣＣＤから獲得される像は７５０×５００画素である。像がＩＳＩによって撮影されたときのカメラの向きは、画像の上部が「上」に対応するように、画素を０、９０、１８０又は２７０度回転させるために使用される。全ての画素は、（最大で３というよりも）Ｒ、Ｇ又はＢカラーコンポーネントだけを有するので、これらが回転しているという事実は、画素値を解釈する際に考慮されなければならない。カメラの向きに応じて、２×２画素ブロックの各々は、図１１１に示されたコンフィギュレーションの何れかを有する。
【０８０４】
ＣＣＤ撮影された像を処理のために有用な形式に変換するために、ＣＣＤ撮影された像に以下の幾つかの処理を行うことが必要である：
−ＣＣＤ像の低サンプルレートカラーコンポーネントのアップ補間（画素の正しい向きを解釈）；
ＲＧＢから内部色空間への色変換；
−７５０×５００から１５００×１０００へ内部空間画像をスケーリング；
−プレーナーフォーマットで像を書き込み。
【０８０５】
像のチャンネル全体は、ワーピングを可能にさせるため、同時に利用できることが必要である。小規模メモリモデル（８ＭＢ）の場合、一時的オブジェクトとして全解像度で単一のチャンネルを保持するための空間しかない。このため、色変換は単一のカラーチャンネルへの変換である。このプロセスに関する制約要因は色変換である。なぜならば、色変換は、ＲＧＢから内部色空間へのトライリニア補間を含み、このトライリニア補間は、１チャンネル当たり０．０２６ｎｓ（７５０×５００×１画素当たり７サイクル×１サイクル当たり１０ｎｓ＝２６２５００００ｎｓ）を要するプロセスだからである。
【０８０６】
内部色空間画像をスケーリングする前に色変換を実行することが重要である。なぜならば、これは、スケーリングされる画素数（したがって、全体のプロセス時間）を４の倍率で削減するからである。
【０８０７】
全ての変換に対する必要条件がＡＬＵスキームに当てはまる訳ではない。変換は、したがって、以下の二つのフェーズに分解される：
フェーズ１：ＣＣＤ像の低サンプルレートカラーコンポーネントのアップ補間（画素の正しい向きを解釈）；
ＲＧＢから内部色空間への色変換；
プレーナーフォーマットでの像の書き込み；
フェーズ２：７５０×５００から１５００×１０００へ内部空間画像をスケーリング。
【０８０８】
スケール関数の分離は、小さい色変換後の画像は大きい画像と同時にメモリ内に存在すべきであることを意味する。フェーズ１からの出力（０．５ＭＢ）は、通常、画像ピラミッド（１ＭＢ）のために確保されたメモリエリアに安全に書き込まれる。フェーズ２からの出力は、一般的な拡大されたＣＣＤ像である。スケーリングの分離によって、更に、スケーリングをアフィン変換によって実現することが可能になり、これは、簡単な１：２の拡大ではない様々なＣＣＤ解像度を許容する。
【０８０９】
フェーズ１：低サンプルレートカラーコンポーネントのアップ補間
３カラーコンポーネント（Ｒ、Ｇ及びＢ）の各々は、所与の画素に対して色変換を実行するためアップ補間される必要がある。色変換は７サイクルを使用するので、補間を実行するため１画素当たりに７サイクルがある。
【０８１０】
Ｇの補間は簡単であり、図１１２に示されている。向きに応じて、実際の画素値Ｇは、
奇数ライン上の奇数画素及び偶数ライン上の偶数画素と、偶数ライン上の奇数画素及び奇数ライン上の偶数画素との間で交互に代わる。両方のケースで、リニア補間が要求される全てである。Ｒコンポーネント及びＢコンポーネントの補間は、図１１３及び図１１３に示されるようにもっと複雑である。なぜならば、水平方向及び垂直方向において、同図から分かるように、３行の画素に同時にアクセスすることが要求されるので、３個の順次読み出しイタレータが必要であり、各順次読み出しイタレータは単一行によってオフセットされる。その上、各行のためのラッチを用いて、同じ行の前の画素へアクセスする。
【０８１１】
したがって、各画素は、ＣＣＤからの１個のコンポーネントと、他の２個のアップ補間されたコンポーネントと、を格納する。一方のコンポーネントがバイリニア補間されているとき、他方はリニア補間されている。補間係数は定数０．５であるため、補間は、加算及び１ビット右シフトによって（１サイクル以内に）計算することが可能であり、係数０．５のバイリニア補間は、３回の加算及び２ビット右シフト（３サイクル）によって計算可能である。必要な総サイクル数は、単一の乗算ＡＬＵを使用した場合４である。
【０８１２】
図１１５は、回転０の偶数ライン偶数画素（ＥＬ，ＥＰ）及び奇数ライン奇数画素（ＯＬ，ＥＰ）のケースを示し、図１１６は、回転０の偶数ライン奇数画素（ＥＬ，ＯＰ）及び奇数ライン偶数画素（ＯＬ，ＯＰ）のケースを示している。他の回転は、これらの２個の表現の少し異なる形式である。
【０８１３】
色変換
ＲＧＢからＬａｂへの色空間変換は、汎用色空間変換関数に関して説明された方法と同じ方法を使用して実現され、１画素当たり８サイクルを要するプロセスである。フェーズ１の処理は図１１７を参照して説明される。
【０８１４】
ＲＧＢのアップ補間は４サイクル（１個の乗算ＡＬＵ）を必要とするが、色空間の変換は、ルックアップ転送時間のため、１画素当たり８サイクル（２個の乗算ＡＬＵ）を必要とする。
【０８１５】
フェーズ２
画像スケーリング
このフェーズは、ＣＣＤ解像度（７５０×５００）から作業用写真解像度（１５００×１０００）への画像のアップ補間と関係する。スケーリングは、１：２の縮尺のアフィン変換を実行させることにより行われる。汎用アフィン変換のタイミングは１出力画素当たり２サイクルであり、本ケースでは、０．０３秒のスケーリング時間の経過を意味する。
【０８１６】
画像照明
画像が処理された後、画像を一つ以上の光源によって照明することができる。光源は以下の何れの型でもよい：
１．指向性型−無限の距離があるので、単一方向へ平行光を投じる；
２．オムニ型−全方向へ非焦点光を投じる；
３．スポット型−特定の目標点へ焦点ビームを投光する。スポット光に関連した円錐及び半影部が存在する。
【０８１７】
シーンは、反射角を変化させるため関連したバンプマップを有する。周辺光も選択的に照明されたシーンに存在する。
【０８１８】
加速された照明のプロセスでは、単一の光源によって一つの画像チャンネルを照明することに関心がある。多数の光源を、１光源当たりに１パスの多数のパスとして、単一の画像チャンネルに適用することが可能である。多数のチャンネルは、バンプマップがある場
合も無い場合も、同時に一つずつ処理可能である。
【０８１９】
ある画素における法線表面ベクトル（Ｎ）は、もし存在するならば、バンプマップから計算される。バンプマップが存在しない場合、デフォルト法線ベクトルは、画像面に垂直、即ち、Ｎ＝［０，０，１］である。
【０８２０】
ビューイングベクトルＶは、常に、画像平面に垂直、即ち、Ｖ＝［０，０，１］である。
【０８２１】
指向性光源の場合、画素から光源への光源ベクトル（Ｌ）は、画像全体中で一定であり、画像全体に対して１回計算される。（有限の距離にある）オムニ光源の場合、光源ベクトルは、画素毎に独立に計算される。
【０８２２】
周辺光の画素の反射は、IakaOdに従って計算される。
【０８２３】
光源の画素の散乱及び鏡面反射は、Phongモデル：
fattIp[kdOd(N・L) + ksOs(R・V)n]
に従って計算される。
【０８２４】
光源が無限大である場合、光源強度は画像全体に亘って一定である。
【０８２５】
各光源は１画素当たりに３個の寄与度、即ち、
周辺光寄与度
散光寄与度
鏡面寄与度
を有する。
【０８２６】
光源は以下の変数を用いて定義される。
【０８２７】
【表７９】
0004309954.tif 000106
同じ反射係数（ｋａ，ｋｓ，ｋｄ）がカラーコンポーネント毎に使用される。
【０８２８】
所与の画素の値は、周辺光寄与と、各光の拡散寄与及び鏡面寄与の合計との和に一致する。
【０８２９】
照明計算のサブプロセス
散光寄与度を計算するため、様々なその他の計算が必要である。それらの計算の中には、
１／ΔＸ
Ｎ
Ｌ
Ｎ・Ｌ
Ｒ・Ｖ
ｆatt
fcp
の計算が含まれる；
サブプロセスは、
周辺光
散光
鏡面
の寄与度を計算するためにも定義される。
【０８３０】
サブプロセスは、光源の全体的な照度を計算するために使用できる。４個の乗算ＡＬＵしか存在しないので、特定のタイプの光源に対するマイクロコードは、性能のため適切に混ぜられたサブプロセスを含み得る。
【０８３１】
１／√Ｘの計算
Ｖａｒｋ照明モデルはベクトルを使用する。殆どの場合に、正規化の目的のため、ベクトルの長さの逆数を計算することが重要である。長さの逆数を計算するためには、1/（[x]の平方根）の計算が必要である。
【０８３２】
論理的に、このプロセスは、図１１８に示されるような入力及び出力を有するプロセスとして表現可能である。図１１９を参照すると、この計算は、推定値をルックアップし、次に、以下の関数：
Vn+1 = 1/2 Vn(3-XVn2)
を１回繰り返すことによって行うことが可能である。
【０８３３】
繰り返しの回数は、要求される精度に応じる。このケースでは、１６ビットの精度が必要である。したがって、テーブルは、８ビットの精度であり、１回の繰り返しだけが必要である。以下の定数はソフトウェアによってセットされる。
【０８３４】
【表８０】
0004309954.tif 000107
以下のルックアップテーブルが使用される。
【０８３５】
【表８１】
0004309954.tif 000108
Ｎの計算
Ｎは表面法線ベクトルである。バンプマップが存在しない場合、Ｎは一定である。バンプマップが存在する場合、Ｎは画素毎に計算しなければならない。
【０８３６】
バンプマップ無し
バンプマップが無いとき、固定法線Ｎは、以下の性質、即ち、
Ｎ＝［ＸＮ，ＹＮ，ＺＮ］＝［０，０，１］
｜｜Ｎ｜｜＝１
１／｜｜Ｎ｜｜＝１
正規化されたＮ＝Ｎ
を有する。
【０８３７】
これらの性質は、具体的に法線ベクトル及び１／｜｜Ｎ｜｜を計算する代わりに使用することが可能であり、他の計算を最適化することができる。
【０８３８】
バンプマップ有り
図１２０に示されるように、バンプマップが存在する場合、Ｎは、Ｘ次元とＹ次元のバンプマップ値を比較することによって計算される。図１２０は、同じ行及び列における画素に関して画素Ｐ１に対するＮの計算を示しているが、Ｐ１自体での値も含まれる。Ｎの計算は、スケール倍率（Ｘ及びＹで同じ倍率）で乗算することにより、解像度に依存しないようにされる。このプロセスは、図１２１に示されるような入力及び出力（ＺＮは常に１である）を有するプロセスとして表現できる。
【０８３９】
ＺＮは常に１である。ＸＮ及びＹＮは未だ正規化されていない（なぜならば、ＺＮ＝１である）。Ｎの正規化は、Ｎ．Ｌが計算されるまで遅延されるので、１／｜｜Ｎ｜｜による乗算は、３回ではなく１回である。
【０８４０】
Ｎを計算する実際のプロセスは図１２２に示されている。
【０８４１】
以下の定数がソフトウェアによってセットされる。
【０８４２】
【表８２】
0004309954.tif 000109
Ｌの計算
指向性光
光源が無限遠であるとき、光源は実効的な一定光ベクトルＬを有する。Ｌは、
Ｌ＝［ＸＬ， ＹＬ， ＺＬ］
｜｜Ｌ｜｜＝１
１／｜｜Ｌ｜｜＝１
のようにソフトウェアによって正規化され、計算される。
【０８４３】
これらの性質は、具体的にＬ及び１／｜｜Ｌ｜｜を計算する代わりに使用することが可能であり、他の計算を最適化することができる。このプロセスは図１２３に示されている。
【０８４４】
オムニ光及びスポット光
光源が無限遠ではないとき、Ｌは現在点Ｐから光源ＰＬまでのベクトルである。Ｐ＝［ＸＰ，
ＹＰ， ０］であるため、Ｌは、
Ｌ＝［ＸＬ， ＹＬ， ＺＬ］
ＸＬ＝ＸＰ−ＸＰＬ
ＹＬ＝ＹＰ−ＹＰＬ
ＺＬ＝−ＺＰＬ
によって与えられる。１／｜｜Ｌ｜｜を乗算することにより、ＸＬ、ＹＬ、及びＺＬの各々を正規化する。（後で正規化の際に使用される）１／｜｜Ｌ｜｜の計算は、
Ｖ＝ＸＬ２＋ＹＬ２＋ＺＬ２
を計算し、次に、
Ｖ−１／２
を計算することによって実行される。
【０８４５】
このケースでは、Ｌの計算は、図１２４に示されるような入力及び出力を有するプロセスとして表現可能である。
【０８４６】
ＸＰ及びＹＰは照度が計算されている画像の座標である、ＺＰは常に０である。
【０８４７】
Ｌを計算する実際のプロセスは図１２５に示されている。
【０８４８】
以下の定数がソフトウェアによってセットされる。
【０８４９】
【表８３】
0004309954.tif 000110
Ｎ．Ｌの計算
ベクトルＮとベクトルＬの内積の計算は、
ＸＮＸＬ＋ＹＮＹＬ＋ＺＮＺＬ
によって定義される。
【０８５０】
バンプマップ無し
バンプマップが無いとき、Ｎは一定［０，０，１］である。したがって、Ｎ．ＬはＺＬに簡約化される。
【０８５１】
バンプマップ有り
バンプマップが存在するとき、内積を直接計算する必要がある。正規化されたＮコンポーネントを取り込むのではなく、正規化されていないＮと正規化されたＬの内積を得た後に正規化を行う。Ｌは、（一定であるとき）ソフトウェアによって正規化されるか、又はＬ計算プロセスによって正規化される。このプロセスは図１２６に示されている。
【０８５２】
ＺNは、１になるように定義されているので、入力として不要である。しかし、その代わりに、結果を正規化するために１／｜｜Ｎ｜｜が必要とされる。Ｎ．Ｌを計算する実際の一プロセスは、図１２７に示されている。
【０８５３】
Ｒ・Ｖの計算
Ｒ・Ｖは鏡面寄与度の計算への入力として必要である。Ｖ＝［０，０，１］であるため、Ｚコンポーネントだけが必要である。したがって、Ｒ・Ｖは、
Ｒ・Ｖ＝２ZN（Ｎ．Ｌ）−ＺＬ
に簡約化される。
【０８５４】
加えて、非正規化ＺＮ＝１であるため、正規化ＺＮ＝１／｜｜Ｎ｜｜である。
【０８５５】
バンプマップ無し
最も簡単な実装は、Ｎが一定（即ち、バンプマップ無し）のときである。Ｎ及びＶは定数であるため、Ｎ．Ｌ及びＲ・Ｖは、
Ｖ＝［０， ０，
１］
Ｎ＝［０， ０，
１］
Ｌ＝［ＸＬ， ＹＬ， ＺＬ］
Ｎ．Ｌ＝ＺＬ
Ｒ・Ｖ＝２ＺＮ（Ｎ．Ｌ）−ＺＬ
＝２ＺＬ−ＺＬ
＝ＺＬ
として簡単化される。
【０８５６】
Ｌが一定（指向性光源）であるとき、正規化ＺＬは、Ｒ・Ｖが要求されるときに、定数の形で与えることができる。Ｌが変化するとき（オムニ光及びスポット光のとき）、正規化ＺＬはオンザフライ方式で計算しなければならない。それは、Ｌ計算プロセスの出力として獲得される。
【０８５７】
バンプマップ有り
Ｎが一定ではないとき、Ｒ・Ｖを計算するプロセスは、一般化された式、即ち、
Ｒ・Ｖ＝２ＺＮ（Ｎ．Ｌ）−ＺＬ
を実施するだけである。入力及び出力は図１２８に示され、実際の実装は図１２９に示されている。
【０８５８】
減衰定数の計算
指向性光
光源が無限遠であるとき、光の強度は画像一面で変化しない。したがって、減衰定数ｆａｔｔは１である。この定数は、無限遠光源の照明計算を最適化するために使用可能である。
【０８５９】
オムニ光及びスポット光
光源が無限遠ではないとき、光の強度は次式、
ｆａｔｔ＝ｆ０＋ｆ１／ｄ＋ｆ２／ｄ２
に従って変化する。
【０８６０】
係数ｆ０、ｆ１及びｆ２を適切にセットすることにより、光強度を一定に、距離に関して線形に、或いは、距離の平方によって減衰させることができる。
【０８６１】
ｄ＝｜｜Ｌ｜｜であるため、ｆａｔｔの計算は、図１３０に示されるような入力及び出力を有するプロセスとして表現可能である。
【０８６２】
ｆａｔｔを計算する実際のプロセスは図１３１に定義される。
【０８６３】
以下の定数がソフトウェアによってセットされる。
【０８６４】
【表８４】
0004309954.tif 000111
円錐及び半影ファクタの計算
指向性光及びオムニ光
これらの二つの光源は集光されないので、円錐又は半影を持たない。円錐−半影スケーリングファクタｆｃｐは１である。この定数は、指向性光源及びオムニ光源の照明計算を最適化するために使用できる。
【０８６５】
スポット光
スポット光は特定の目標点（ＰＴ）に集光する。スポット光の強度は、像の特定の点が円錐内にあるか、半影にあるか、又は円錐／半影領域の外側にあるかによって変化する。
【０８６６】
図１３２を参照すると、半影一に対するｆｃｐのグラフが示されている。円錐の内部４７０でｆｃｐは１であり、半影の外部４７１でｆｃｐは０である。円錐のエッジから半影の終わりまで、光強度は３次関数４７２に従って変化する。
【０８６７】
半影４７５及び円錐４７６の計算のための様々なベクトルが図１３３及び図１３４に示されている。
【０８６８】
図１３４に示されているように１次元に関して像の表面を調べることにより、３個の角Ａ、Ｂ及びＣが定義される。Ａは、目標点４７９と光源４７８と円錐の終端４８０の間の角度である。Ｃは、目標点４７９と光源４７８と半影の終端４８１の間の角度である。これらの両方は所与の光源に対して一定である。Ｂは、目標点４７９と光源４７８と計算対象一４８２の間の角度であり、像上で計算される点毎に変化する。
【０８６９】
ここで、レンジＡからＣを０から１に正規化し、Ｂが、次式、
（Ｂ−Ａ）／（Ｃ−Ａ）
によってその角度レンジの間に収まる距離を見つける。
【０８７０】
そのレンジは０から１のレンジに丸められ、この値は、ｆｃｐの３次近似のためのルックアップとして使用される。
【０８７１】
したがって、ｆａｔｔの計算は、図１３５に示されるような入力及び出力を有するプロセスとして表現可能であり、ｆｃｐを計算する実際のプロセスは図１３６に示され、以下の定数がソフトウェアによってセットされる。
【０８７２】
【表８５】
0004309954.tif 000112
以下のルックアップテーブルが使用される。
【０８７３】
【表８６】
0004309954.tif 000113
周辺光寄与の計算
像に当てられる光の数とは無関係に、周辺光寄与が各画素に対して１回ずつ実行され、バンプマップには依存しない。
【０８７４】
周辺光計算プロセスは図１３１に示されるような入力及び出力を備えたプロセスとして表現可能である。このプロセスを実装するためには、図１３８に示されるように入力画像からの各画素（Ｏｄ）を定数値（Ｉａｋａ）によって乗算することが必要であり、以下の定数がソフトウェアによってセットされる。
【０８７５】
【表８７】
0004309954.tif 000114
散光寄与の計算
表面に当てられた各光は拡散照明を生じる。拡散照明は、次式、
散光＝ｋｄＯｄ（Ｎ．Ｌ）
によって表される。２種類の実装形態を考えることができる。
【０８７６】
実装例１−定数Ｎ及びＬ
Ｎ及びＬの両方が定数であるとき（指向性光でバンプマップが無いとき）、
Ｎ．Ｌ＝ＺＬ
である。したがって、
散光＝ｋｄＯｄＺＬ
である。
【０８７７】
Ｏｄだけが変数であるため、散光寄与を計算する実際のプロセスは図１３９に示されるようなものであり、以下の定数がソフトウェアによってセットされる。
【０８７８】
【表８８】
0004309954.tif 000115
実装例２−非定数Ｎ及びＬ
Ｎ又はＬの何れかが非定数であるとき（ビットマップ、又はオムニ光若しくはスポット光からの照明であるとき）、散光計算は、次式、
散光＝ｋｄＯｄ（Ｎ．Ｌ）
に従って直接実行される。
【０８７９】
散光計算プロセスは図１４０に示されるような入力を備えたプロセスとして表現可能である。Ｎ．Ｌは、Ｎ．Ｌ計算プロセスを使用して計算するか、又は定数として与えられる。散光寄与を計算する実際のプロセスは図１４１に示されるようなプロセスであり、以下の定数がソフトウェアによってセットされる。
【０８８０】
【表８９】
0004309954.tif 000116
鏡面寄与の計算
表面に当てられた各光は鏡面照明を生ずる。鏡面照明は、次式、
鏡面光＝ ｋｓＯｓ（Ｒ・Ｖ）ｎ
によって表される。ここで、
Ｏｓ＝ｋｓｃＯｄ＋（１−ｋｓｃ）Ｉｐ
である。
【０８８１】
鏡面光計算プロセスは二つの実装形態がある。
【０８８２】
実装例１−定数Ｎ及びＬ
第１の実装例は、Ｎ及びＬの両方が定数であるとき（指向性光でバンプマップ無し）である。Ｎ、Ｌ及びＶは一定であるので、Ｎ．Ｌ及びＲ・Ｖも一定である：
Ｖ＝［０， ０，
１］
Ｎ＝［０， ０，
１］
Ｌ＝［ＸＬ， ＹＬ， ＺＬ］
Ｎ．Ｌ＝ＺＬ
Ｒ・Ｖ＝２ＺＮ（Ｎ．Ｌ）−ＺＬ
＝２ＺＬ−ＺＬ
＝ＺＬ
このようにして、鏡面光計算は、
鏡面光＝ｋｓＯｓＺＬｎ
＝ｋｓＺＬｎ（ｋｓｃＯｄ＋（１−ｋｓｃ）Ｉｐ）
＝ｋｓｋｓｃＺＬｎＯｄ＋（１−ｋｓｃ）ＩｐｋｓＺＬｎ
として簡略化される。
【０８８３】
鏡面光計算ではＯｄだけが変数であるため、鏡面光寄与の計算は、図１４２に示されるような入力及び出力を備えたプロセスとして表現可能であり、鏡面光寄与を計算する実際のプロセスは図１４３に示され、以下の定数がソフトウェアによってセットされる。
【０８８４】
【表９０】
0004309954.tif 000117
実装例２−非定数Ｎ及びＬ
この実装例は、Ｎ又はＬの何れかが一定ではないとき（ビットマップ、又はオムニ光若しくはスポット光からの照明であるとき）である。これは、Ｒ・Ｖを与える必要があることを意味し、Ｒ・Ｖｎを計算しなければならない。
【０８８５】
鏡面光計算プロセスは、図１４４に示されるような入力及び出力を備えたプロセスとして表現可能である。図１４５は、鏡面光寄与を計算する実際のプロセスを表し、以下の定数がソフトウェアによってセットされる。
【０８８６】
【表９１】
0004309954.tif 000118
以下のルックアップテーブルが使用される。
【０８８７】
【表９２】
0004309954.tif 000119
周辺光が唯一の照明であるとき
周辺光寄与が唯一の光源である場合、このプロセスは非常に簡単である。なぜならば、図１４６に示されているようなプロセス全体で周辺光を加える必要がないからである。像は、垂直方向に二つの区画に分割し、周辺光ロジックを複製することにより、半分の各々を同時に処理することが可能である（このようにして、全部で２個の乗算ＡＬＵ及び４個の順次イタレータを使用する）。したがって、タイミングは、周辺光を適用する１画素当たり１／２サイクルである。
【０８８８】
典型的な照明のケースは、一つ以上の光によって照らされるシーンである。これらのケースでは、周辺光計算は非常に手軽であるため、周辺光計算は各光源の処理と共に収容される。処理されるべき最初の光は、正確なＩａｋａ設定値を持つべきであり、後続の光は、Ｉａｋａの値を０にすべきである（多重の周辺光寄与を避けるため）。
【０８８９】
周辺光が別個のパスとして（第１のパスではなく）処理されるならば、周辺光を現在の計算値に加えることが必要である（同じアドレスへの読み書きが必要である）。プロセスの概要は図１４７に示されている。
【０８９０】
このプロセスは、３個の像イタレータと１個の乗算ＡＬＵを使用し、平均で１画素当たり１サイクルを要する。
【０８９１】
無限光源
無限光源のケースでは、像全体で一定の光源強度が得られる。Ｌ及びｆａｔｔの両方は定数である。
【０８９２】
バンプマップ無し
バンプマップが無いとき、一定法線ベクトルＮ［０，０，１］が存在する。照明の複雑さは、Ｎ、Ｌ及びｆａｔｔが一定であることによって著しく軽減される。バンプマップ無しの単一の指向性光を当てるプロセスは図１４７に示され、以下の定数がソフトウェアによってセットされる。
【０８９３】
【表９３】
0004309954.tif 000120
単一の無限光源の場合、図１４８に示されるような論理演算を実行することが求められ、ここで、Ｋ１からＫ４は以下の値をもつ定数である。
【０８９４】
【表９４】
0004309954.tif 000121
このプロセスは、Ｋ２、Ｋ３及びＫ４が定数であるため簡単化することができる。基本的に（乗算ＡＬＵのうちの３個を使用する）鏡面光寄与と散光寄与の計算が複雑であるため、周辺光計算を４番目の乗算ＡＬＵとして安全に加えることが可能である。処理される第１の無限光源は、真の周辺光パラメータＩａｋａを備え、後続の全ての無限光は、Ｉａｋａに０をセットすることができる。周辺光計算は実質的に無くなる。
【０８９５】
無限光源が照射される第１の光である場合、他の光源による既存の寄与度を取り込む必要はなく、その状況は図１４９に示され、定数は以下の値をとる。
【０８９６】
【表９５】
0004309954.tif 000122
無限光源が照射される第１の光ではない場合、先行して処理された光によって生成された既存の寄与度を取り込む必要があり（同じ定数が当てはまる）、状況は図１４８に示されている。
【０８９７】
第１のケースでは、２個の順次イタレータ４９０、４９１が必要であり、第２のケースでは、３個の順次イタレータ４９０、４９１、４９２が必要である（余分のイタレータは先行の光の寄与度を読み出すために必要である）。両方のケースで、バンプマップ無しの無限光源の適用は１画素当たり１サイクルを要し、オプションとして周辺光の適用が含まれる。
【０８９８】
バンプマップ有り
バンプマップが存在するとき、法線ベクトルＮは画素毎に計算することが必要であり、一定光源ベクトルＬに適用される。１／｜｜Ｎ｜｜はＲ・Ｖを計算するために使用され、Ｒ・Ｖは鏡面光計算２プロセスへの入力として要求される。以下の定数がソフトウェアによってセットされる。
【０８９９】
【表９６】
0004309954.tif 000123
バンプマップ順次読み出しイタレータ４９０は、バンプマップの現在ラインを読み出す役割を担う。現在ラインは、Ｘに関するスロープを決定するため入力として与えられる。バンプマップ順次読み出しイタレータ４９１、４９２は、現在ラインの上下のラインを読み出す役割を担う。それらはＹに関するスロープを決定するため入力を提供する。
【０９００】
オムニ光
オムニ光源のケースでは、光ベクトルＬ及び減衰定数ｆａｔｔは像の中で画素毎に変化する。したがって、Ｌ及びｆａｔｔの両方は画素毎に計算しなければならない。
【０９０１】
バンプマップ無し
バンプマップが無いとき、一定法線ベクトルＮ［０，０，１］が存在する。Ｌは画素毎に計算しなければならないが、Ｎ．Ｌ及びＲ・Ｖの両方は、ＺＬに簡単化される。バンプナップが無いとき、オムニ光の適用は図１４９に示されるように計算され、以下の定数がソフトウェアによってセットされる。
【０９０２】
【表９７】
0004309954.tif 000124
このアルゴリズムは、オプションとして、先行の光源からの寄与を取り込み、周辺光計算を含む。周辺光は１回だけ取り込めばよい。他の全ての光パスに対して、周辺光計算プロセスにおける適切な定数は０にセットされるべきである。
【０９０３】
図示されるようなアルゴリズムは全部で１９回の乗算／累算を必要とする。ルックアップのために必要な時間は、Ｌの計算中の１サイクルと、鏡面光寄与計算中の４サイクルである。したがって、５サイクルの処理時間が実現可能な最良のものである。その関数のためにＡＬＵを最適にマイクロコード化できない場合には、必要な時間は６サイクルまで増加する。オムニ光を関連したビットマップの無い像へ適用するための速度は１画素当たり６サイクルである。
【０９０４】
バンプマップ有り
オムニ光が関連したバンプマップを備えた像に照射されるとき、Ｎ、Ｌ、Ｎ．Ｌ及びＲ・Ｖの計算は全てが必要である。オムニ光を関連したバンプマップを備えた像に適用するプロセスは図１５０に示され、以下の定数がソフトウェアによってセットされる。
【０９０５】
【表９８】
0004309954.tif 000125
このアルゴリズムは、オプションとして、先行の光源からの寄与を取り込み、周辺光計算を含む。周辺光は１回だけ取り込むことが必要である。他の全ての光パスに対し、周辺光計算プロセス内の適切な定数は０にセットされるべきである。
【０９０６】
図示されるようなアルゴリズムは全部で３２回の乗算／累算を必要とする。ルックアップのために要する時間は、ＬとＮの両方の計算中に１サイクルずつと、鏡面光寄与計算のための４サイクルである。しかし、ＮとＬのために必要なルックアップは同じである（したがって、２個のＬＵが３個のＬＵを実装する）。８サイクルの処理時間が適切である。その関数のためのＡＬＵを最適にマイクロコード化できない場合、必要な時間は９サイクルまで延長される。オムニ光を関連したビットマップ付きの像に適用する速度は１画素当たり９サイクルである。
【０９０７】
スポット光
スポット光はオムニ光と類似しているが、減衰定数ｆａｔｔが、目標の周りに効率的に光を集める円錐／半影ファクタｆｃｐによって変更されている点が相違する。
【０９０８】
バンプマップ無し
バンプマップが無いとき、一定法線ベクトルＮ［０，０，１］が存在する。Ｌは画素毎に計算しなければならないが、Ｎ．Ｌ及びＲ・Ｖの両方は、ＺＬに簡単化される。図１５１は、像へのスポット光の照射の説明図であり、以下の定数がソフトウェアによってセットされる。
【０９０９】
【表９９】
0004309954.tif 000126
このアルゴリズムは、オプションとして、先行の光源からの寄与を取り込み、周辺光計算を含む。周辺光は１回だけ取り込めばよい。他の全ての光パスに対して、周辺光計算プロセスにおける適切な定数は０にセットされるべきである。
【０９１０】
図示されるようなアルゴリズムは全部で３０回の乗算／累算を必要とする。ルックアップのために必要な時間は、Ｌの計算中の１サイクルと、鏡面光寄与計算中の４サイクルと、円錐／半影計算における２組の４サイクルルックアップである。
【０９１１】
バンプマップ有り
スポット光が関連したバンプマップを備えた像に照射されるとき、Ｎ、Ｌ、Ｎ．Ｌ及びＲ・Ｖの計算は全てが必要である。単一のスポット光を関連したバンプマップを備えた像に適用するプロセスは図１５２に示され、以下の定数がソフトウェアによってセットされる。
【０９１２】
このアルゴリズムは、オプションとして、先行の光源からの寄与を取り込み、周辺光計算を含む。周辺光は１回だけ取り込むことが必要である。他の全ての光パスに対し、周辺光計算プロセス内の適切な定数は０にセットされるべきである。図示されるようなアルゴリズムは全部で４１回の乗算／累算を必要とする。
【０９１３】
プリントヘッド４４
図１５３は、論理的に８セグメントにより構成され、各々がページの一部分に２層のシアン、マゼンタ、及びイエローを印刷する単一のプリントヘッドの論理的レイアウトの説明図である。
【０９１４】
印刷用セグメントのローディング
何かを印刷する前に、プリントヘッドの８セグメントの各々は、最終出力画像における以下の相対的な行に対応した６行のデータがロードされなければならない：
行０＝ラインＮ、イエロー、偶数ドット０、２、４、６，８、．．．
行１＝ラインＮ＋８、イエロー、奇数ドット１、３、５、７、．．．
行２＝ラインＮ＋１０、マゼンタ、偶数ドット０、２、４、６，８、．．．
行３＝ラインＮ＋１８、マゼンタ、奇数ドット１、３、５、７、．．．
行４＝ラインＮ＋２０、シアン、偶数ドット０、２、４、６，８、．．．
行５＝ラインＮ＋２８、シアン、奇数ドット１、３、５、７、．．．
各セグメントは、ページの異なる部分にドットを印刷する。各セグメントは、１色の７５０ドット、即ち、ある行に３７５個の偶数ドットと、別の行に３７５個の奇数ドットを印刷する。８個のセグメントは、位置に対応したドットを含む。
【０９１５】
【表１００】
0004309954.tif 000127
各ドットは、プリントヘッドセグメントに１ビットで表現される。データは、データをセグメントのＢｉｔＶａｌｕｅ（ビット値）ピンに置くことによって、同時に１ビットだけロードされ、ＢｉｔＣｌｏｃｋ（ビットクロック）に従ってそのセグメントのシフトレジスタへクロック供給されなければならない。データは単一のレジスタにロードされるので、ビットをローディングする順序は正しい筈である。データは１０ＭＨｚの最大レートでプリントヘッドにクロック供給することができる。
【０９１６】
全てのビットがロードされると、ビットはプリントヘッド出力バッファへ並列に転送され、印刷の準備が完了する。この転送はセグメントのＰａｒａｌｌｅｌＸｆｅｒＣｌｏｃｋピン上の１個のパルスによって実行される。
【０９１７】
印刷制御
電力を節約するため、プリントヘッドの全てを必ずしも同時に印刷しなくてもよい。制御ラインの組は、特定のドットの印刷を可能にさせる。ＡＣＰのような外部コントローラは、速度及び／又は電力の必要条件に応じて、同時に印刷されるドット数、並びに、プリントパルスの間隔を変更することが可能である。
【０９１８】
各セグメントは、５本のＮｏｚｚｅｌＳｅｌｅｃｔ（ノズル選択）ラインを含み、ノズル選択ラインは１行当たり３２組のノズルを選択するため復号化される。各行には３７５個のノズルがあるので、各組には１２個のノズルがある。更に、色の偶数行と奇数行に１本ずつの、２本のＢａｎｋＥｎａｂｌｅ（バンクイネーブル）ラインが設けられる。最後に、各セグメントは、Ｃカラー、Ｍカラー及びＹカラーの各々に１本ずつの、３本のＣｏｌｏｒＥｎａｂｌｅ（カラーイネーブル）ラインを含む。あるＣｏｌｏｒＥｎａｂｌｅライン上のパルスは、カラーの指定行の指定されたノズルに印刷を行わせる。パルスは、典型的に、２ 
ｓの間隔である。
【０９１９】
全てのセグメントが、ＮｏｚｚｅｌＳｅｌｅｃｔラインと、ＢａｎｋＥｎａｂｌｅラインと、ＣｏｌｏｒＥｎａｂｌｅライン（プリントヘッドへ外部から配線されている）の同じ組によって制御される場合、以下の事項が成立する。
【０９２０】
奇数バンク及び偶数バンクの両方が同時に印刷をする場合（両方のＢａｎｋＥｎａｂｌｅビットがセットされている場合）、１セグメント当たり２４個のノズル、即ち、全部で１９２個のノズルが同時に発射し、５．７ワットを消費する。
【０９２１】
奇数バンクと偶数バンクが独立に印刷をする場合、１セグメント当たり１２個のノズルだけが、即ち、全部で９６個が同時に発射し、２．８５ワットを消費する。
【０９２２】
印刷ヘッドインタフェース６２
印刷ヘッドインタフェース６２は、ＡＣＰをプリントヘッドに接続し、データと適切な信号の両方を外部プリントヘッドへ供給する。プリントヘッドインタフェース６２は、ＶＬＩＷプロセッサ７４と、ＣＰＵ上で実行されるソフトウェアアルゴリズムの両方と協働して動作し、約２秒のうちに写真を印刷する。
【０９２３】
プリントヘッドインタフェースへの入出力の概要は図１５４に示されている。アドレス及びデータバスがＣＰＵによって使用され、プリントヘッドインタフェースの種々のレジスタのアドレスを指定する。単一のＢｉｔＣｌｏｃｋ出力ラインは、プリントヘッド上の８セグメントの全てに繋がる。８本のＤａｔａＢｉｔｓ（データビット）ラインは、１本ずつが各セグメントに接続され、（ＢｉｔＣｌｏｃｋパルスに基づいて）プリントヘッドの８セグメントへ同時にクロックインされる。例えば、同時に、ドット０はセグメント０へ転送され、ドット７５０はセグメント１へ転送され、ドット１５００はセグメント２へ転送され、以下同様である。
【０９２４】
ＶＬＩＷ出力ＦＩＦＯは、ディザ処理された２レベルＣ、Ｍ及びＹの６０００×９０００解像度印刷画像を、８本のＤａｔａＢｉｔｓラインへ出力するために正しい順序で格納する。ＰａｒａｌｌｅｌＸｆｅｒＣｌｏｃｋは、プリントヘッドの８セグメントの各々へ接続されるので、単一パルスによって、全てのセグメントがそれぞれのビットを同時に転送する。最後に、ＮｏｚｚｌｅＳｅｌｅｃｔライン、ＢａｎｋＥｎａｂｌｅライン及びＣｏｌｏｒＥｎａｂｌｅラインが８セグメントの各々へ接続され、プリントヘッドインタフェースは、Ｃ、Ｍ及びＹドロップパルスの間隔、並びに、各パルスで印刷されるドロップの数を制御できるようになる。プリントヘッドインタフェースのレジスタは、０から６μｓのパルス間隔、典型的に２μｓの間隔を指定することができる。
【０９２５】
画像印刷
画像がＡｒｔｃａｍのユーザの管理下に置かれる前に、以下の２フェーズ、即ち、
１．印刷されるべき画像の準備
２．準備された画像の印刷
を行うことが必要である。
【０９２６】
画像の準備は１回だけ実行すればよい。画像印刷は必要に応じて何回で実行できる。
【０９２７】
画像準備
印刷用の画像の準備には、
１．写真画像の印刷画像への変換
２．プリンタの向きの出力に揃えるために印刷画像（内部色空間）の回転
３．（必要に応じて）圧縮されたチャンネルのアップ補間
４．内部色空間から特定のプリンタ及びインクに適したＣＭＹ色空間への色変換が含まれる。
【０９２８】
画像準備の最後に、４．５ＭＢの正しく向きを決められた１０００×１５００ＣＭＹ色空間画像の印刷準備が完了する。
【０９２９】
写真画像の印刷画像への変換
写真画像を印刷画像へ変換するためには、画像処理を実行するためＶａｒｋスクリプトを実行することが必要である。このスクリプトは、デフォルト画像強調スクリプト、又は現在挿入中のＡｒｔｃａｒｄから取り出されたＶａｒｋスクリプトである。Ｖａｒｋスクリプトは、ＣＰＵによって実行され、ＶＬＩＷベクトルプロセッサによって実行される関数で加速される。
【０９３０】
印刷画像の回転
メモリ内の画像は、最初、上端が上向きになるように方向を合わされる。これにより、Ｖａｒｋ処理を簡単にすることができる。画像が印刷される前に、画像は、プリントロールの向きと揃えられなければならない。再アライメントは１回だけ実行すればよい。印刷画像の引き続くプリントは、予め適切に回転されているであろう。
【０９３１】
適用されるべき変換は、ユーザがＡｒｔｃａｍの「撮像」ボタンを押したときに、ＣＣＤからの捕捉中に適用された変換の単に逆変換である。元の回転が０であるならば、変換は不要である。元の回転が＋９０度であるならば、印刷前に−９０度（２７０度と同じである）回転する必要がある。この回転を適用するために使用される方法は、Ｖａｒｋ加速されたアフィン変換関数である。アフィン変換エンジンは、各カラーチャンネルを独立に回転させるため呼び出される。カラーチャンネルは元の位置で回転できないことに注意する必要がある。その代わりに、カラーチャンネルは、拡大された単一チャンネル（１．５ＭＢ）のために先に使用されたスペースを利用することが可能である。
【０９３２】
図１５５は、Ｌａｂ画像の回転の一例の説明図であり、ａチャンネル及びｂチャンネルは４：１に圧縮されている。Ｌチャンネルは、不要になったスペース（単一チャンネルエリア）へ回転させられ、次に、ａチャンネルは、Ｌの後に残された空きスペースに回転させられ、最後に、ｂを回転させることができる。三つのチャンネルを回転するために要する総時間は０．０９秒である。これは、最初の画像印刷の前に許容可能な時間の経過である。後続のプリントは、このオーバーヘッドを生じない。
【０９３３】
アップ補間及び色変換
Ｌａｂ画像は、印刷前にＣＭＹへ変換しなければならない。Ｌａｂ画像のａチャンネル及びｂチャンネルが圧縮されているかどうかに応じて、様々な処理が行われる。Ｌａｂ画像が圧縮されているならば、ａチャンネル及びｂチャンネルは色変換が行われる前に伸長されなければならない。Ｌａｂ画像が圧縮されていないならば、色変換は唯一の必要なステップである。Ｌａｂ画像は、（ａチャンネル及びｂチャンネルが圧縮されているならば）アップ補間し、ＣＭＹ画像へ変換される。スケール及び色変換を組み合わせた単一のＶＬＩＷプロセスを使用することができる。
【０９３４】
色変換を実行するために使用される方法は、Ｖａｒｋ加速型色変換関数である。アフィン変換エンジンは、各カラーチャンネルを独立に回転させるため呼び出し可能である。カラーチャンネルはそのままの位置で回転できない。その代わりに、カラーチャンネルは拡大された単一チャンネル（１．５ＭＢ）のために先に使用されたスペースを利用することが可能である。
【０９３５】
画像印刷処理
画像印刷処理は、正しい向きに置かれた１０００×１５００ＣＭＹ画像を取り込み、外部プリントヘッドへ送信されるべきデータ及び信号を生成することに関係する。このプロセスは、ＶＬＩＷプロセス及びプリントヘッドインタフェースと協働するＣＰＵを必要とする。
【０９３６】
Ａｒｔｃａｍ内の画像の解像度は１０００×１５００である。印刷された画像は、６０００×９０００ドットの解像度があり、非常に簡単な関係：１画素＝６×６＝３６ドットが得られる。図１５６に示されるように、各ドットは１６．６μｍであるため、６×６平方ドットは１００平方μｍである。各ドットは２レベルであるため、出力をディザ処理する必要がある。
【０９３７】
画像は約２秒で印刷されるべきである。９０００行のドットの場合、これは、各行を印刷する間の時間が２２２μｓの時間であることを意味する。プリントヘッドインタフェースは、この時間内に６０００ドットを生成しなければならず、平均して１ドット毎に３７ｎｓである。しかし、各ドットは３色により構成されるので、プリントヘッドインタフェースは、約１２ｎｓ内に、即ち、ＡＣＰの１クロックサイクル（１００ＭＨｚで１０ｎｓ）のうちに各カラーコンポーネントを生成しなければならない。一つのＶＬＩＷプロセスは、印刷されるべき次の６０００ドットのラインを計算する役割を担う。奇数と偶数のＣ、Ｍ及びＹドットは、６種類の１０００×１５００画像ラインからの入力をディザ処理することによって生成される。第２のＶＬＩＷプロセスは、先に計算された６０００ドットのラインを取り込み、１回の転送でプリントヘッドインタフェースからプリントヘッドへ転送されるべき８個のセグメントのための８ビットのデータを正確に生成する役割がある。
【０９３８】
ＣＰＵプロセスは、プリントライン毎に３回ずつ（１カラーコンポーネント当たり１回ずつ＝２秒間に２７０００回）第１のＶＬＩＷプロセス３内のレジスタを更新し、第２のＶＬＩＷプロセス内のレジスタをプリントライン毎に１回ずつ（２秒間に９０００回）更新する。ＣＰＵは、これを行うために、ＶＬＩＷプロセスよりも１ラインだけ先に進んでいる。
【０９３９】
最後に、プリントヘッドインタフェースは、ＶＬＩＷ出力ＦＩＦＯから８ビットデータを取り込み、それをそのままプリントヘッドへ出力し、ＢｉｔＣｌｏｃｋ信号を適切に生成する。全てのデータの転送が終わった後、ＰａｒａｌｌｅｌＸｆｅｒＣｌｏｃｋ信号が次のプリントラインのデータをロードするため生成される。データのプリントヘッドへの転送と連動して、別個のタイマーが、プリントヘッドインタフェース内部レジスタによって指定されたＮｏｚｚｌｅＳｅｌｅｃｔライン、ＣｏｌｏｒＥｎａｂｌｅライン及びＢａｎｋＥｎａｂｌｅラインを使用して、プリントヘッドの異なるプリントサイクルのための信号を生成する。
【０９４０】
更に、ＣＰＵは、印刷プロセス中にパラレルインタフェースを介して種々のモーター及び裁断機を制御する。
【０９４１】
Ｃ、Ｍ及びＹドット生成
このプロセスへの入力は、印刷のため正しい向きに置かれた１０００×１５００ＣＭＹ画像である。この画像は圧縮されていない。図１５７に示されるように、ＶＬＩＷマイクロコードプログラムは、ＣＭＹ画像を取り込み、プリントヘッドインタフェースによって要求された、ディザ処理されるＣ、Ｍ及びＹ画素を生成する。
【０９４２】
このプロセスは、三つのカラーコンポーネントの各々に対して１回ずつの３回実行される。このプロセスは、並列に実行される二つのサブプロセスを含未、一方は奇数ドットを生成し、他方は偶数ドットを生成する。各サブプロセスは入力画像から１画素を取り込み、３個の出力ドットを生成する（なぜならば、１画素＝６出力ドットであり、各サブプロセスは偶数ドットと奇数ドットの何れかに関連しているからである）。１個の出力ドットが１サイクル毎に生成されるが、入力画素は３サイクル毎に１回だけ読み出される。
【０９４３】
元のディザセルは６４×６４形のセルであり、各エントリーは８ビットである。この元のセルは、奇数セルと偶数セルに分割されるので、各々は６４の高さのままであるが、３２エントリーの幅しかない。偶数ディザセルは、元のディザセル画素０、２、４等を格納し、一方、奇数ディザセルは、元のディザセル画素１、３、５等を格納する。ディザセルはラインを超えて繰り返されるので、２個のディザセルの各々の単一の３２バイトラインは、ライン全体の間に必要であり、したがって、完全にキャッシュすることができる。単一のプロセスラインのうちの奇数ライン及び偶数ラインは、８ドットラインだけ離して交互にされるので、奇数ディザセルの８ライン毎に回転させることが好都合である。したがって、奇数ディザセルと偶数ディザセルの両方に同じオフセットを使用することが可能である。この結果として、偶数ディザセルのラインは元のディザセルのラインＬの偶数エントリーに対応し、奇数ディザセルのラインは元のディザセルのラインＬ＋８の奇数エントリーに対応する。
【０９４４】
このプロセスは、カラーコンポーネントの各々に対して１回ずつの３回実行される。ＣＰＵソフトウェアルーチンは、奇数ライン及び偶数ライン用の順次読み出しイタレータがプリントヘッドに対応した正しい画像ラインを確実に指定しなければならない。例えば、１組の１８０００ドット（３組の６０００ドット）を生成するため、
・イエロー偶数ドットライン＝０、したがって、入力イエロー画像ライン＝０／６＝０
・イエロー奇数ドットライン＝８、したがって、入力イエロー画像ライン＝８／６＝１
・マゼンタ偶数ドットライン＝１０、したがって、入力マゼンタ画像ライン＝１０／６＝１
・マゼンタ奇数ドットライン＝１８、したがって、入力マゼンタ画像ライン＝１８／６＝３
・シアン偶数ドットライン＝２０、したがって、入力シアン画像ライン＝２０／６＝３
・シアン奇数ドットライン＝２８、したがって、入力シアン画像ライン＝２８／６＝４
である。この後に続く入力画像ラインの組は、
・Ｙ＝［０，１］， Ｍ＝［１，３］， Ｃ＝［３，４］
・Ｙ＝［０，１］， Ｍ＝［１，３］， Ｃ＝［３，４］
・Ｙ＝［０，１］， Ｍ＝［２，３］， Ｃ＝［３，５］
・Ｙ＝［０，１］， Ｍ＝［２，３］， Ｃ＝［３，５］
・Ｙ＝［０，２］， Ｍ＝［２，３］， Ｃ＝［４，５］
である。
【０９４５】
しかし、ディザセルデータはカラーコンポーネント毎に更新しなくてもよい。３カラーのディザセルは同じになるが、コンポーネント毎に２ドットラインずつオフセットしている。
【０９４６】
ディザ処理された出力は順次書き込みイタレータに書き込まれ、奇数及び偶数のディザ処理されたドットは２個の別々の出力に書き込まれる。同じ２個の書き込みイタレータが３個の全てのカラーコンポーネントに対して使用されるので、それらは、奇数及び偶数ドットの分割の範囲内で連続的である。
【０９４７】
１組のドットがプリントラインに対して生成される間に、先に生成されたドットの組が、次のセクションで説明されるような第２のＶＬＩＷプロセスによって併合される。
【０９４８】
併合８ビットドット出力生成
このプロセスは、図１５８に示されるように、１ラインのディザ処理されたドットを取り込み、ＶＬＩＷ出力ＦＩＦＯを介してプリントヘッドインタフェースへ出力するための８ビットのデータストリームを生成する。このプロセスは、ライン全体が準備されることを必要とする。なぜならば、このプロセスは、ディザ処理されたラインの殆どを同時に準ランダムアクセスする必要があるからである。以下の定数がソフトウェアによってセットされる。
【０９４９】
【表１０１】
0004309954.tif 000128
順次読み出しイタレータは、前に生成されたドットのラインを指定し、イタレータのレジスタは単一カラーコンポーネントへのアクセスを制限するためセットアップされている。後続の画素の間の距離は３７５であり、あるラインと次のラインとの間の距離は１バイトになるように与えられる。その結果として、８個のエントリーが「ライン」毎に読み出される。単一の「ライン」は、プリントヘッドへロードされる８ビットに対応する。画像の「ライン」総数は３７５にセットされる。少なくとも８個のキャッシュラインを順次読み出しイタレータに割り当てることにより、完全なキャッシュコヒーレンスが維持される。８ビットをカウントする代わりに、８個のマイクロコードステップが暗黙的にカウントを行う。
【０９５０】
生成プロセスは、最初に、偶数ドットから全てのエントリーを読み出し、８個のエントリーを１バイトに合成し、その１バイトをＶＬＩＷ出力ＦＩＦＯへ出力する。３０００個の全部の偶数ドットが読み出された後、３０００個の奇数ドットが読み出され、処理される。ソフトウェアルーチンは、１カラーコンポーネント毎に１回ずつ、即ち、１ライン毎に３回ずつ奇数及び偶数の順次読み出しイタレータのドットのアドレスを更新しなければならない。二つのＶＬＩＷプロセスは、全部で８個のＡＬＵとＶＬＩＷ出力ＦＩＦＯを必要とする。ＣＰＵが上述のように二つのプロセスでレジスタを更新できる限り、ＶＬＩＷプロセッサは、プリンタに追従するために十分な速さでディザ処理された画像ドットを生成し得る。
【０９５１】
データカードリーダー
図１５９は、読み出すためＡｒｔｃａｒｄ９を挿入することができるカードリーダー５００の一形態を示す図である。図１５８は図１５９のリーダーの分解斜視図である。カードリーダーはコンピュータシステムに相互連結され、ＣＣＤ読み出し機構３５を含む。カードリーダーは、挿入されたＡｒｔｃａｒｄ９を挟むピンチローラー５０６及び５０７を含む。一方のローラー、例えば、ローラー５０６は、二つのローラー５０６及び５０７の間のカード９を一様な速度で前進させるためのＡｒｔｃａｒｄモーター３７によって駆動される。Ａｒｔｃａｒｄ９は、一連のＬＥＤライト５１２の上を通過させられ、一連のＬＥＤライトは、半円形の断面を有する透明なプラスチックモールド５１４内に収容される。この断面は、例えば、ＬＥＤ５１２からの光を、カード９がＬＥＤ５１２の傍を通過するときに、カード９の表面に集める。その表面から、光は、約４８０ｄｐｉの解像度に構成された高解像度リニアＣＣＤ３４へ反射される。Ａｒｔｃａｒｄ９の表面は、約１６００ｄｐｉのレベルまでエンコードされているので、リニアＣＣＤ３４は、約３倍の乗数でＡｒｔｃａｒｄ表面をスーパーサンプルする。Ａｒｔｃａｒｄ９は、リニアＣＣＤ３４が１インチ当たり約４８００回の読み出しのレートでＡｒｔｃａｒｄの移動方向にスーパーサンプルできるような速度で更に駆動される。走査されたＡｒｔｃａｒｄのＣＣＤデータはＡｒｔｃａｒｄリーダーからＡＣＰ３１へ送られ処理される。光センサにより構成できるセンサ４９は、カード１３の有無を検出するために機能する。
【０９５２】
ＣＣＤリーダーは、下側基板５１６と、透明な成形されたプラスチックを含む上側基板５１４と、を有する。二つの基板の間に、半導体製造プロセスによって製作された薄く長いリニアＣＣＤアレイを含むリニアＣＣＤアレイ３４が挿入される。
【０９５３】
図１６０を参照すると、ＣＣＤリーダーユニットの一構成例の部分断面斜視側面図が示されている。一連のＬＥＤ、例えば、ＬＥＤ５１２は、カード９がＣＣＤリーダー３４の表面を通過するときに発光するように動作する。放出された光は、上側基板５２３の一部分を透過する。この基板は、ＬＥＤ５１２から放出された光を、カード９上の表面上の点、例えば、点５３２に集めるように湾曲した周囲を有する部分、例えば、部分５２９を含む。焦点が合わされた光は、点５３２から、ＣＣＤアレイ３４の方へ反射される。誇張されて示された一連のマイクロレンズ、例えば、マイクロレンズ５３４は、上側基板５２３の表面に形成される。マイクロレンズ５２３は、表面全体から受光した光を、ＣＣＤアレイ３４の感光部に入射する光を検知するＣＣＤリーダー３４の表面上の点に対応した下の焦点５３６に集めるように作用する。
【０９５４】
上記の装置には多数の改良が考えられる。例えば、リニアＣＣＤ３４上の感知デバイスは千鳥状でもよい。対応したマイクロレンズ３４は、千鳥状のＣＣＤセンサに対応するように、光を千鳥状の一連のスポットへ集光させるために相応に形成することができる。
【０９５５】
読み出しを助けるため、Ａｒｔｃａｒｄ９のデータ表面エリアは、図３８を参照して既に説明したように、チェッカー盤のようなパターンで変調させてもよい。その他の形態の高周波変調も実現可能である。
【０９５６】
Ａｒｔｃａｒｄプリンタが記憶装置Ａｒｔｃａｒｄ上のデータをプリントアウトするものとして提供できることは明らかである。したがって、Ａｒｔｃａｒｄシステムは、Ａｒｔｃａｍ装置の外部に情報を配信する一般的な形態として利用することが可能である。Ａｒｔｃａｒｄプリンタは、Ａｒｔｃａｒｄを高品質印刷面にプリントアウトすることが可能であり、多数のＡｒｔｃａｒｄを同じ用紙に印刷し、後で分離することができる。Ａｒｔｃａｒｄ９の第２の面には、引き続く記憶のために、Ａｒｔｃａｒｄ９に記憶されたファイル等に関する情報を印刷することができる。
【０９５７】
したがって、Ａｒｔｃａｒｄシステムは、ＣＤ−ＲＯＭ、磁気ディスク等の他の形態の記憶装置の代わりに使用するために適した簡単化された形態の記憶装置を可能にさせる。Ａｒｔｃａｒｄ９は、大量生産可能であり、そのため、再分配用に実質的に低価格の形態で生産できる。
【０９５８】
プリントロール
図１６２には、Ａｒｔｃａｍのプリントロール４２及びプリントヘッド部が示されている。用紙／フィルム６１１は、連続した「ウェブのような」プロセスで、印刷機構１５へ送られ、印刷機構１５は、更なるピンチローラー６１６−６１９、及びプリントヘッド４４を含む。
【０９５９】
ピンチローラー６１３は、駆動機構（図示せず）に連結され、プリントローラー６１３の回転時に、フィルム６１１の形態の「用紙」は、印刷機構６１５の中へ通され、ピクチャー出力スロット６から出される。回転式裁断機構（図示せず）は、要求された写真サイズで用紙６１１のロールを切断するために利用される。
【０９６０】
したがって、プリンタロール４２は、写真用にイメージ化されたピクチャーを印刷する印刷機構６１５に「用紙」６１１を供給する役割を果たすことが明白である。
【０９６１】
図１６３には、プリントロール４２の分解斜視図が示されている。プリントロール４２は、ピンチローラー６１２、６１３の動作の下で出力される出力プリンタ用紙６１１を含む。
【０９６２】
次に、図１６４には、「用紙」フィルムロールが除かれた図１６３のプリントロール４２のより完全な分解斜視図が示されている。プリントロール４２は、インク貯蔵セクション６２０、用紙ロールセクション６２２、６２３、及び外側ケーシングセクション６２６、６２７からなる三つの主要部品を含む。
【０９６３】
最初にインク貯蔵セクション６２０を参照すると、インクリザーバ又はインク供給セクション６３３が設けられている。印刷用インクは、三つのブラダー型の容器６３０から６３２に収容される。プリンタロール４２は、フルカラー出力インクを提供するものとする。したがって、第１のインクリザーバ又はブラダー容器６３０はシアン色インクを収容する。第２のリザーバ６３１はマゼンタ色インクを収容し、第３のリザーバ６３２はイエロー色インクを収容する。リザーバ６３０から６３２の各々は、容積寸法が異なっているかもしれないが、実質的に同じ容積サイズを有するように設計される。
【０９６４】
インク貯蔵セクション６２１、６３３は、カバー６２４と共に、プラスチックセクションから製作することが可能であり、ヒートシール、紫外線照射等を用いて一体的にできるように設計される。サイズが等しくされたインクリザーバ６３０から６３２の各々は、対応したインクチャンネル６３９から６４１に連結され、リザーバ６３０から６３２より対応したインク出力ポート６３５から６３７へのインクの流れを可能にさせる。インクリザーバ６３２はインクチャンネル６４１及び出力ポート６３７を具備し、インクリザーバ６３１はインクチャンネル６４０及び出力ポート６３６を具備し、インクリザーバ６３０はインクチャンネル６３９及び出力ポート７６３７を具備する。
【０９６５】
動作中に、インクリザーバ６３０から６３２は、対応したインクで充たされ、セクション６３３はセクション６２１に接合される。インク貯蔵セクション６３０から６３２は、折り畳み可能なブラダーでもよく、インクがインクチャンネル６３９−６４１を行き来できるようにさせ、インク出力ポート６３５から６３７と流体的に連通される。更に、必要に応じて、空気取り入れ口が設けられ、インクチャンネルリザーバ６３０から６３２に関連した圧力を要求通りに維持することができる。
【０９６６】
キャップ６２４は、空気圧取り入れ口からアクセス可能な加圧型キャビティを形成するため、インク貯蔵セクション６２０に接合することができる。
【０９６７】
インク貯蔵セクション６２１、６３３及び６２４は、一体的なユニットとして一つに連結され、プリンタロールセクション６２２、６２３の内側へ挿入できるように設計される。プリンタロールセクション６２２、６２３は、対応したメス型部分（図示せず）と結合するオス型部分６４５から６４７を用いてスナップフィットによって一体的に結合されるように設計される。同様に、メス型部分６５４から６５６は、対応したオス型部分６６０から６６２と結合するように設計される。用紙ロールセクション６２２、６２３は、したがって、一体的にスナップで留められるように設計される。ロール内のフィルムの一端は、二つのセクション６２２、６２３が一つに接合されたとき、二つのセクション６２２、６２３の間で締め付けられる。プリントフィルムは、必要に応じて、プリントロールセクション６２２、６２５上で回転させることができる。
【０９６８】
前述の通り、インク貯蔵セクション６２０、６２１、６３３、６２４は、用紙ロールセクション６２２、６２３の内側に挿入できるように設計される。プリンタロールセクション６２２、６２３は、オンデマンドでフィルムを与えるため、静止したインク貯蔵セクション６２１、６３３及び６２４の周りで回転することができる。
【０９６９】
外側ケーシングセクション６２６及び６２７は、更に、プリントロールセクション６２２、６２３の周りで結合できるように設計される。更に、ピンチローラー、例えば、６１２、６１３のそれぞれの端は、カバー６２６、６２７内で対応したキャビティ、例えば、６７０に留められるように設計され、ローラー６１３は、プリントフィルムを供給し、プリントロールから排出するため外部（図示せず）から駆動される。
【０９７０】
最後に、キャビティ６７７は、プリントロール４２に関連した情報を記憶するためのシリコンチップ集積回路型装置５３を挿入し案内するため、インク貯蔵セクション６２０、６２１に設けることが可能である。
【０９７１】
図１５５及び図１６４に示されるように、プリントロール４２は、Ａｒｔｃａｍカメラ装置に挿入され、カップリングユニット６８０と結合するように設計され、カップリングユニット６８０は、シリコンチップ５３との配線を行うコネクタパッド６８１を含む。更に、コネクタ６８０は、インク供給ポート６３５から６３７との４個の接続用のエンドコネクタを含む。インク供給ポートは、次に、インク供給ライン、例えば、６８２へ接続され、インク供給ラインは、次に、プリントヘッド供給ポート、例えば、６８７へ相互連結され、必要に応じてインクをプリントヘッド４４へ流す。
【０９７２】
ロールを形成するため利用される「メディア」６１１は、適当な画像を上に印刷するために設計された様々な材料により構成することが可能である。例えば、不透明な回転可能なプラスチック材料が利用され、透明なプラスチックシートを使用することにより透明性が使用され、メタリックシートフィルムの利用によってメタリック印刷が行われ得る。更に、プリンタロール４２内に布を利用し、布に画像を印刷することも可能であるが、適当な剛性又は適当な裏当てを有する材料だけが利用できることに注意する必要がある。
【０９７３】
印刷メディアがプラスチックであるとき、インクを定着させ、吸収する層でその印刷メディアを覆うことが可能である。更に、幾つかのタイプの印刷メディア、例えば、不透明白色マット、透明フィルム、艶消し透明フィルム、３次元立体印刷用のレンチキュラーアレイフィルム、金属化フィルム、格子又はホログラムのようなエンボス方式の光学的に可変のデバイス、裏面に予め印刷が施されたメディア、及び磁気記録層を含むメディア、を使用できる。金属泊を利用するとき、金属泊は、ポリマーベースをもつことが可能であり、薄い（数ミクロンの）アルミニウム又はその他の金属の蒸着層で覆われ、次に、インクプリンタ機構を介してインクを受容するように適合した透明な保護層で覆われる。
【０９７４】
使用されるプリントロール４２は、カメラ装置の内部に挿入され、要求に応じて画像の印刷用のインク及び用紙を提供できるように設計される。インク出力ポート６３５から６３７は、カメラ装置内の対応したポートと適合する。ピンチローラー６７２、６７３は、カメラ装置の制御下で用紙をカメラ装置へ供給できるように作動される。
【０９７５】
図１６４に示されるように、実装されたシリコンチップ５３は、プリントロール４２の一方の端に挿入される。図１６５では、認証チップ５３がより詳細に示され、この認証チップ５３は、チップ５３からチップが挿入されている対応したカメラへ詳細を通信する４本の通信リード線６８０から６８３を含む。
【０９７６】
図１６５を参照すると、チップは、小型集積回路６８７をエポキシに入れ、ボンディングリード線、例えば、６８８を外部通信リード線６８０から６８３へ繋ぐことにより、単独で作成され得る。集積チップ６８７は、約４００平方ミクロンであり、スクライブ境界は１００ミクロンである。続いて、チップは、プリントロール４２のキャビティの適切な表面に貼り付けられる。図１６５の装置の分解図である図１６６には、ボンディングパッド６８１、６８２に相互連結された集積回路６７が示されている。
【０９７７】
図１６４Ａから１６４Ｅにおいて、参照番号１１００は、全体的にプリントカートリッジ１１００を示す。プリントカートリッジ１１００は、本発明によれば、インクカートリッジ１１０２を含む。
【０９７８】
プリントカートリッジ１１００はハウジング１１０４を含む。図２により詳細に示されているように、ハウジング１１０４は、上側成形部品１１０６及び下側成形部品１１０８によって画成される。成形部品１１０６及び１１０８は、クリップ１１１０によって挟まれる。ハウジング１１０４はラベル１１１２によって被われ、ラベル１１１２はカートリッジ１１００に魅力的な外観を与える。ラベル１１１２は、ユーザがカートリッジ１１００を使えるようにするための情報を搭載する。
【０９７９】
ハウジング１１０４はチャンバー１１１４を画成し、チャンバー内にインクカートリッジ１１０２が収まる。インクカートリッジ１１０２は、ハウジング１１０４のチャンバー１１１４に固定して担持される。
【０９８０】
フォーマーに巻き付けられたフィルム／メディア１１１８のロール１１２６を含むプリントメディア１１１６の補給品はハウジング１１０４のチャンバー１１１４に収容される。フォーマー１１２０は、インクカートリッジ１１０２に摺動自在に収容され、インクカートリッジに対して回転自在である。
【０９８１】
図１６４Ｂに示されるように、上側成形部品１１０６及び下側成形部品１１０８は一体としてクリップされ、出口スロット１１２２が画成され、用紙１１１８の舌状部は出口スロットを通して排出される。
【０９８２】
カートリッジ１１００はローラー組立体１１２４を含み、ローラー組立体１１２４は、用紙１１１８がロール１１２６から供給されるときに用紙１１１８のカールを取り除くために役立ち、スロット１１２２を介して用紙１１１８を押し出すために役立つ。ローラー組立体１１２４は、駆動ローラー１１２８と、２個の従動ローラー１１３０と、を含む。従動ローラー１１３０は、リブ１１３２に回転自在に支持され、リブ１１３２は、ハウジング１１０４の下側成形部品１１０８のフロア１１３４から盛り上がっている。ローラー１１３０は、駆動ローラー１１２８と一体となって、用紙１１１８がハウジング１１０４から排出されるときに、用紙１１１８の速度及び位置を制御するため、用紙１１１８に正のトラクションを与える。ローラー１１３０は、ポリスチレンのような適当な合成プラスチック材料の射出成形部品である。この点に関して、上側成形部品１１０６及び下側成形部品１１０８は、同様に、ポリスチレンのような適当な合成プラスチック材料の射出成形部品である。
【０９８３】
駆動ローラー１１２８は、ハウジング１１０４の上側成形部品１１０６及び下側成形部品１１０８の各々の側壁に画成された合わせリセス１１３８及び１１４０の間に回転自在式に係留されている駆動シャフト１１３６を含む。駆動ローラー１１２８の反対側の端１１４２は、ハウジング１１４０の上側成形部品１１０６と下側成形部品１１０８に適当な構成（図示せず）で回転自在に保持されている。
【０９８４】
駆動ローラー１１２８は、ツーショット射出成形部品であり、高衝撃ポリスチレン製のシャフト１１３６を含み、シャフト１１３６の上に、エラストマ又はゴムローラー部分１１４４の形をした軸受手段が成形されている。これらの部分１１４４は、用紙１１１８を確実に係止し、用紙１１１８がカートリッジ１１００から供給されるときに、用紙１１１８の滑りを防止する。
【０９８５】
ハウジング１１０４から突起するローラー１１２８の端は、十字形構造体１１４６（図１６４Ａ）の形をした係合体を有し、この十字形構造体は、プリントカートリッジ１１００が取り付けられるカメラのような装置のプリントヘッド組立体の歯車付き駆動インタフェース（図示せず）と結合する。この構造体は、用紙１１１８がプリントヘッドに供給される速度を、プリントヘッドによる印刷と確実に同期させるので、インクが用紙１１１８上で正確に位置合わせされることを保証する。
【０９８６】
インクカートリッジ１１０２は、直円柱押出成形部品の形をした容器１１４８を含む。この容器１１４８は、ポリスチレンのような適当な合成プラスチック材料から押出成形される。
【０９８７】
本発明の好適な実施形態において、プリントカートリッジ１１００が共に使用されるプリントヘッドは、多色プリントヘッドである。したがって、容器１１４８は、複数の、より詳細には、４個のコンパートメント、即ち、リザーバ１１５０に分割される。各リザーバ１１５０は、異なる色、又は異なるタイプのインクを収容する。一実施形態では、リザーバ１１５０に収容されるインクは、シアンインク、マゼンタインク、イエローインク、及びブラックインクである。本発明の他の実施形態では、３種類の有色インクであるシアンインク、マゼンタインク及びイエローインクがリザーバ１１５０のうちの３個に収容され、４番目のリザーバ１１５０は、赤外線スペクトルだけで可視化されるインクを収容する。
【０９８８】
図１６４Ｃ及び１６４Ｄに明瞭に示されているように、容器１１４８の一端は、エンドキャップ１１５２によって閉じられる。エンドキャップ１１５２は複数の開口１１５４が画成されている。開口１１５４は各リザーバ１１５０と関連付けられているので、エンドキャップ１１５２が設けられた容器１１４８の端でリザーバ１１５０内は大気圧で維持される。
【０９８９】
シール構造体１１５６は、エンドキャップ１１５２が設けられている端側で容器１１４８に設けられる。シール構造体１１５６は、各リザーバ１１５０に摺動自在に受容されたゲル状材料からなる四分円形ペレット１１５８を含む。ペレット１１５８のゲル状材料は、熱硬化性ゴムと炭化水素からなる化合物である。炭化水素は白色鉱物油である。熱硬化性ゴムは、ペレット１１５８が通常の動作温度でその形状を維持し、同時に、ペレット１１５８がその関連したリザーバ１１５０内で摺動できるように、鉱物油に十分な剛性を与える共重合体である。適当な熱硬化性ゴムは、シェル石油会社によって「Ｋａｒｔｏｎ」（登録商標）の名前で販売されている熱硬化性ゴムである。共重合体は、ゲルのような粘度を各ペレット１１５８に与えるために十分な量でその化合物内に存在する。典型的に、共重合体は、使用されるタイプに応じて、約３％から２０％の重量パーセントの量で存在するであろう。
【０９９０】
使用中に、この化合物は加熱され、その結果として流体になる。各リザーバ１１５０に特定のタイプのインクが詰められると、溶融状態の化合物は各リザーバ１１５０に注入され、化合物はペレット１１５８を形成するため固まる。ペレット１１５８の裏側の大気圧、即ち、エンドキャップ１１５２と向かい合うペレットの端における大気圧は、インクがリザーバ１１５０から引き出されるときに、自動注油式であるペレット１１４８が容器１１４８の反対側へ向かって滑ることを保証する。ペレット１１５８は、逆さにされた容器からインクが出て空になることを止め、リザーバ１１５０内のインクが汚れることを妨げ、リザーバ１１５０内のインクが乾燥することを妨げる。更に、ペレット１１５８は、リザーバ１１５０からのインクの漏れを防止するため疎水性である。
【０９９１】
容器１１４８の反対側の端は、インク鍔成形部品１１６０によって閉じられる。成形部品１１６０に支持されたバッフル１１６２は、エラストマーシール成形部品１１６４を受容する。疎水性であるエラストマーシール成形部品１１６４は、内部にシーリング幕１１６６が画成されている。各シーリング幕１１６６にはスリット１１６８が設けられているので、プリントヘッド組立体からの合わせピン（図示せず）は、スリット１１６８を通して挿入可能であり、容器１１４８のリザーバ１１５０と流体的に連通される。中空突起１１７０は、インク鍔成形部品１１６０の反対側から突起する。各突起１１７０は、関連したリザーバ１１５０とぴったり合うように成形され、インク鍔成形部品を容器１１４８の端に位置決めする。
【０９９２】
図１６４Ｃを参照すると、インク鍔成形部品１１６０は、キャリア又は隠し板成形部品１１７２によって正しい位置に維持される。隠し板成形部品１１７２には、四つ葉のクローバー形状の窓１１７４が画成され、この窓１１７４を介して、エラストマーシール成形部品１１６４へアクセスすることができる。隠し板成形部品１１７２は、ハウジング１１０４の上側成形部品１１０６と下側成形部品１１０８との間に係留される。隠し板成形部品１１７４と、ハウジング１１０４の上側成形部品１１０６及び下側成形部品１１０８のそれぞれの内面から延びるウェブ１１７６及び１１７８は、コンパートメント１１８０を画成する。エアーフィルタ１１８２はコンパートメント１１８０に収容され、端部成形部品１１７４によって正しい位置に保たれる。エアーフィルタ１１８２はプリントヘッド組立体と協働する。エアーは、プリントヘッド組立体のノズルガードの至る所へ吹き付けられ、ノズルガードのクリーニングを行う。このエアーは、隠し板１１７２内の入口側開口１１８４に収容されたピン（図示せず）を用いてエアーフィルタ１１８２を通して引き出すことによって濾過される。
【０９９３】
エアーフィルタ１１８２は、図１６４Ｅに更に詳細に示されている。エアーフィルタ１１８２はフィルタ媒体１１９２を含む。フィルタ媒体１１９２は、合成ファイバに基づくものであり、フィルタリング目的のため利用可能な表面積を増加させるため溝付きの形で配置される。紙ベースのフィルタ媒体１１９２の代わりに、他の繊維性芯材を使用してもよい。
【０９９４】
フィルタ媒体１１９２は密閉容器１１９４に収容される。密閉容器１１９４は、底成形部品１１９６及び蓋１１９８を含む。ハウジング１１０４のコンパートメント１１８０に収容するために、密閉容器１１９４は、部分的に環状、即ち、馬蹄形にされる。このようにして、密閉容器１１９４は、一対の対向端１２００を有する。吸気開口１２０２が各端１２００に画成される。
【０９９５】
排気開口１２０４は蓋１１９８に画成される。排気開口１２０４は、最初、フィルム、又は膜１２０６によって閉鎖されている。フィルタ１１８２がコンパートメント１１８０の正しい位置に取り付けられたとき、排気開口１２０４は隠し板成形部品１１７２の開口１１８４と位置合わせされる。プリントヘッド組立体からのピンがフィルム１２０６を貫通し、エアーがノズルガードとプリントヘッド組立体のプリントヘッドに吹き付けられる前に、エアーフィルタ１１８２を介して雰囲気からエアーを引き込む。
【０９９６】
底成形部品１１９４は、密閉容器１１９４の正しい位置にフィルタ媒体１１９２を設置するための位置決め構造体１２０８及び１２１０を含む。位置決め構造体１２０８は複数のピンの形をなし、一方、位置決め構造体１２１０は、フィルタ媒体１１９２の端１２１４を係止するリブの形をしている。
【０９９７】
フィルタ媒体１１９２が底成形部品１１９６の正しい位置に設置された後、蓋１１９８は、蓋１１９８で底成形部品１１９６を密閉するため超音波溶接、又は類似した方法によって、底成形部品１１９６に固定される。
【０９９８】
プリントカートリッジ１１００が組み立てられたとき、膜又はフィルム１１８６は、窓１１７４を閉鎖するために隠れ板成形部品１１７２の外側端に被せられる。この膜又はフィルム１１８６は、使用するために、ピンによって孔を開けられ、又は破裂されられる。フィルム１１８６は、破片がインクリザーバ１１５０に侵入することを防止する。
【０９９９】
認証チップ１１８８の形の認証手段は、隠れ板成形部品１１７２の開口１１９０に収容される。認証チップ１１８８は、プリントカートリッジ１１００が装置のプリントヘッド組立体と互換性があり、準拠していることを保証するため、プリントヘッド組立体１１８８による問い合わせを受ける。
【１０００】
認証チップ
認証チップ５３
好適な実施形態の認証チップ５３は、正しく製造されたプリントロールだけがカメラシステムで利用されることを保証する責任がある。認証チップ５３は、プリントロールシステムに限定されない任意の消耗品に関して利用されるときに一般的に有用である技術を利用する。消耗品を必要とする（トナーカートリッジを必要とするレーザープリンタのような）他のシステムの製造者は、消耗品を認証する問題で苦労し、成功のレベルは様々である。その殆どは、専用化されたパッケージングに頼っている。しかし、これは、家庭での詰め替え作業や複製品製造を抑えない。コピー作成を防止することは、不完全に製造された代用消耗品が基本システムを損傷することを防ぐために重要である。例えば、濾過が不十分なインクは、インクジェットプリンタのプリントノズルを詰まらせ、消費者はシステム製造者に責任を負わせ、許可されていない消耗品の使用を認めない。
【１００１】
認証の問題を解決するために、認証チップ５３は、認証コードと、コピー防止のために特別に設計された回路と、を含む。このチップは、標準的なフラッシュメモリ製造プロセスを使用して製造され、インク及びトナーカートリッジのような消耗品に組み込むことができる程度に低価格である。一旦プログラミングされると、認証チップは、後述するように、ＮＳＡ持ち出し（エクスポート）ガイドラインに準拠する。認証は、非常に大規模であり、且つ常に成長している分野である。以下の説明は、消耗品の認証だけに関連している。
【１００２】
記号名
以下の記号名が本実施形態の説明を通じて使用される。
【１００３】
【表１０２】
0004309954.tif 000129
基本用語
Ｍで示されたメッセージは平文である。Ｍを、Ｍの実体が隠された暗号文Ｃに変換するプロセスは、暗号化と呼ばれる。ＣをＭへ逆変換するプロセスは、復号化と呼ばれる。暗号化関数をＥで表し、復号化関数をＤで表すことにより、以下の恒等式：
Ｅ［Ｍ］＝Ｃ
Ｄ［Ｃ］＝Ｍ
が得られる。したがって、以下の恒等式：
Ｄ［Ｅ［Ｍ］］＝Ｍ
が成り立つ。
【１００４】
対称暗号化方式
対称暗号化アルゴリズムとは：
暗号化関数Ｅが鍵Ｋ１に依存する；
復号化関数Ｄが鍵Ｋ２に依存する；
Ｋ２はＫ１から導出可能である；
Ｋ１はＫ２から導出可能である；
というアルゴリズムである。
【１００５】
殆どの対称アルゴリズムにおいて、Ｋ１は通常Ｋ２と等しい。しかし、Ｋ１がＫ２と等しくない場合であっても、一方の鍵がもう一方の鍵から導出可能であるならば、数学的な定義のためには単一の鍵があれば十分である。したがって、
ＥＫ［Ｍ］＝Ｃ
ＤＫ［Ｃ］＝Ｍ
と表せる。
【１００６】
誰でも知っている教科書から洗練された現代のアルゴリズムまでの非常に多数の対称アルゴリズムが存在する。それらの殆どは、現在の暗号解読技術がＫを導出し得る程度で攻撃に成功し得るという点において不確かである。特定の対称アルゴリズムの安全性は、通常、アルゴリズムの強度、及び鍵の長さからなる二つの事項の関数である。以下のアルゴリズムは、認証チップに利用するために適した特徴を含んでいる：
ＤＥＳ；
ブローフィッシュ（Ｂｌｏｗｆｉｓｈ）；
ＲＣ５；
ＩＤＥＡ。
【１００７】
ＤＥＳ
ＤＥＳ（データ暗号化規格）は米国及び国際規格であり、暗号化と復号化に同じ鍵が使用される。鍵の長さは５６ビットである。これは、ハードウェアとソフトウェアで実装されるが、当初の設計はハードウェア専用であった。ＤＥＳで使用される当初のアルゴリズムは、米国特許第３９６２５３９号に記載されている。トリプルＤＥＳの変形と称されるＤＥＳの変形はより安全性が高いが、３個の鍵：Ｋ１、Ｋ２及びＫ３を必要とする。これらの鍵は、
ＥＫ３［ＤＫ２［ＥＫ１［Ｍ］］］＝Ｃ
ＤＫ３［ＥＫ２［ＤＫ１［Ｃ］］］＝Ｍ
という形で使用される。
【１００８】
トリプルＤＥＳの主な利点は、既存のＤＥＳの実装を使用して単一鍵のＤＥＳよりも安全性を高くすることができる点である。特に、トリプルＤＥＳは、１１２ビットの鍵の長さと等価的な保護を与える。トリプルＤＥＳは、単純に期待されるような１６８ビット鍵（３×５６）と等価的な保護を与えるものではない。トリプルＤＥＳの復号化及び／又は符号化を実行する機器は米国から持ち出すことができない。
【１００９】
ブローフィッシュ（Ｂｌｏｗｆｉｓｈ）
Ｂｌｏｗｆｉｓｈは、１９９４年にＳｃｈｎｅｉｅｒによって最初に提案された対称ブロック暗号方式である。これは、３２ビットから４４８ビットまでの可変長鍵を使用する。更に、これはＤＥＳよりもかなり高速である。Ｂｌｏｗｆｉｓｈアルゴリズムは、鍵拡張部と、データ暗号化部の二つの部分により構成される。鍵拡張は、最大で４４８ビットの鍵を、全部で４１６８バイトの複数のサブ鍵配列へ変換する。データ暗号化は、１６ラウンドのＦｅｉｓｔｅｌネットワークによって行われる。全ての演算は、３２ビット語上でのＸＯＲと加算であり、１ラウンド当たりに４回のインデックス配列ルックアップを含む。復号化は、サブ鍵が逆順に使用されることを除いて暗号化と同じである点に注意する必要がある。したがって、実装の複雑さは、このような対称性をもたない他のアルゴリズムよりも低減される。
【１０１０】
ＲＣ５
１９９５年にＲｏｎ Ｒｉｖｅｓｔによって設計されたＲＣ５は、ブロックサイズ、鍵のサイズ、及びラウンド回数が可変である。しかし、典型的に、ＲＣ５は、６４ビットのブロックサイズと１２８ビットの鍵を使用する。ＲＣ５アルゴリズムは、鍵拡張部と、データ暗号化部の二つの部分により構成される。鍵拡張は、鍵を２ｒ＋２個のサブ鍵（ここで、ｒ＝ラウンド回数である。）に変換し、各サブ鍵はｗビットである。６４ビットのブロックサイズで、１６回のラウンドの場合（ｗ＝３２，ｒ＝１６）、サブ鍵配列は全部で１３６バイトである。データ復号化は、モジュロー２ｗの加算と、ＸＯＲと、ビット回転と、を使用する。
【１０１１】
ＩＤＥＡ
１９９０年にＬａｉ及びＭａｓｓｅｙによって開発されたＩＤＥＡ暗号方式の最初の具体化された形はＰＥＳと呼ばれる。１９９１年にＢｉｈａｍ及びＳｈａｍｉｒによって差分解読法が発見された後、このアルゴリズムは強化され、その結果は１９９２年にＩＤＥＡとして発表された。ＩＤＥＡは、６４ビットの平文ブロックを操作するために１２８ビット鍵を使用する。暗号化と復号化のために同じアルゴリズムが使用される。このアルゴリズムは、一般的に、現在利用可能な最も安全なブロックアルゴリズムであると考えられている。これは、１９９３年に発行された米国特許第５２１４７０３号に記載されている。
【１０１２】
非対称暗号化方式
他に使用できるアルゴリズムは非対称アルゴリズムである。非対称暗号化アルゴリズムとは：
暗号化関数Ｅが鍵Ｋ１に依存する；
復号化関数Ｄが鍵Ｋ２に依存する；
Ｋ２は合理的な時間内にＫ１から導出不能である；
Ｋ１は合理的な時間内にＫ２から導出不能である；
というアルゴリズムである。
【１０１３】
したがって、
ＥＫ１［Ｍ］＝Ｃ
ＤＫ２［Ｃ］＝Ｍ
である。
【１０１４】
これらのアルゴリズムは、一方の鍵Ｋ１が公開されるので、公開鍵とも称される。したがって、誰でも（Ｋ１を使用して）メッセージを暗号化し得るが、対応した復号鍵（Ｋ２）を持っている人だけがそのメッセージを復号化して読むことができる。殆どの場合に、以下の恒等式：
ＥＫ２［Ｍ］＝Ｃ
ＤＫ１［Ｃ］＝Ｍ
が成立する。
【１０１５】
この恒等式は非常に重要である。なぜならば、公開鍵Ｋ１を所持する人は誰でもＭを見ることができ、そのＭはＫ２の所有者からのものであることが分かるからである。他の人はＣを生成することができない。なぜならば、Ｃを生成し得ることは、Ｋ２を知っていることを意味するからである。合理的な時間内にＫ２からＫ１を導出できないこと、並びに、その逆にＫ１からＫ２を導出できないことは、当然、合理的な時間という概念によって曖昧になる。再々実証されているように、長時間を要することが予想される計算は、より高速化されたコンピュータ、新しいアルゴリズム等の導入によって実現可能になる。非対称アルゴリズムの安全性は、大きい数（より具体的には、二つの大きい素数の積である大きい数）を素因数分解すること、及び有限において離散対数関数を計算することの困難さの二つの問題のうちの一方の困難さに基づいている。大きい数の素因数分解は、現代の数学の理解においては難問であることが推測される。しかし、素因数分解は予測されるよりも速く容易になっているということが問題である。Ｒｏｎ 
Ｒｉｖｅｓｔは、１９７７年に、１２５桁の素因数分解には４００００兆年かかると言っていた。１９９４年に１２９桁の素因数分解が行われた。Ｓｃｈｎｅｉｅｒによれば、１９８０年代における５１２ビットの数から得られた安全性のレベルを現在得るためには、１０２４ビットの数が必要であるとされている。その鍵が数年続くとすると、１０２４ビットでも十分ではない。Ｒｉｖｅｓｔは１９９０年に鍵の長さの評価を改め、２００５年まで高い安全性を維持するためには１６２８ビットを提唱し、２０１５年まで持ちこたえる高い安全性のためには１８８４ビットを提唱している。一方、Ｓｃｈｎｅｉｅｒは、２０１５年まで企業及び政府からの保護を得るためには２０４８ビットが必要であることを示唆している。
【１０１６】
多数の公開鍵暗号化アルゴリズムが存在する。その殆どは実際には実装不可能であり、その多くは、所与のＭに対して非常に大きいＣを生成するか、又は巨大な鍵を必要とする。更に、その他のものは、たとえ安全であるとしても、非常に低速であるため数年の間には実施できない。このため、多数の公開鍵システムは、ハイブリッド方式であり、公開鍵の仕組みは対称セッション鍵を送信するために使用され、セッション鍵が実際のメッセージのために使用される。全てのアルゴリズムは、鍵選択の点で問題がある。乱数はどうしても安全性が不十分である。大きい素数ｐ及びｑは慎重に選ぶことが必要であり、ある種の組み合わせは簡単に素因数分解できるという弱点がある（一部の弱い鍵は検査することができる）。しかし、それにもかかわらず、鍵選択は、例えば、単に、１０２４ビットをランダムに選択するというような単純なことではない。その結果として、鍵選択プロセスも安全でなければならない。
【１０１７】
公開の精査の下で使用中の実際的なアルゴリズムの中で、以下のアルゴリズム：
ＲＳＡ；
ＤＳＡ；
ＥＩＧａｍａｌ；
は利用するために適している。
【１０１８】
ＲＳＡ
Ｒｉｖｅｓｔ、Ｓｈａｍｉｒ及びＡｄｌｅｍａｎの名前にちなんで命名されたＲＳＡ暗号システムは、最も広く使用されている公開鍵暗合システムであり、世界中の多くで事実上の標準である。ＲＳＡの安全性は、２個の素数（ｐ及びｑ）の積である大きい数の素因数分解の困難さに依存していると考えられる。ｐ及びｑの生成には多数の制約がある。それらは、両方共に大きいことが必要であり、ビット数が同じであり、しかも、互いに近似していてはならない（そうでなければ、ｐｑは√ｐｑと近似する）。その上、多くの場合に、ｐ及びｑは強い素数でなければならないことが指摘されている。ＲＳＡアルゴリズムの特許は１９８３年に発行された（米国特許第４４０５８２９号）。
【１０１９】
ＤＳＡ
ＤＳＡ（デジタル署名規格）は、デジタル署名標準（ＤＳＳ）の一部として設計されたアルゴリズムである。規定されているとおり、このアルゴリズムは一般的な暗号化には使用できない。その上、ＲＳＡに対して、ＤＳＡは署名検証の際に１０から４０倍速度が遅い。ＤＳＡは、ＳＨＡ−１ハッシュアルゴリズム（以下の一方向関数の定義を参照せよ。）を明示的に使用する。ＤＳＡ鍵生成は、ｑがｐ−１を割り切るような２個の素数ｐ及びｑの検出に依拠している。Ｓｃｈｎｅｉｅｒによれば、１０２４ビットのｐ値が長期間のＤＳＡ安全性のために必要である。しかし、ＤＳＡ標準は、ｐの値が１０２４ビットよりも大きくなることを認めていない（ｐは、更に、６４ビットの倍数でなければならない）。米国政府はＤＳＡアルゴリズムを所有し、少なくとも一つの関連特許（１９９３年に発行された米国特許第５２３１６８８号）を保持する。
【１０２０】
ＥＩＧａｍａｌ
ＥＩＧａｍａｌ方式は、暗号化とデジタル署名の両方に使用される。その安全性は有界で離散対数関数を計算することの困難さに依拠している。鍵選択には、ｇ及びｘがｐよりも小さくなるような、素数ｐと２個の乱数ｇ及びｘの選択が必要である。次に、ｙ＝ｇｘ 
ｍｏｄ ｐを計算する。公開鍵は、ｙ、ｇ及びｐである。秘密鍵はｘである。
【１０２１】
暗号によるチャレンジ−レスポンスプロトコル及びゼロ知識証明
チャレンジ−レスポンスプロトコルの一般的な原理は、カメラシステムに適したアイデンティティ認証を提供することである。チャレンジ−レスポンスの最も簡単な形態は秘密パスワードの形態をとる。ＡはＢに秘密パスワードを尋ね、Ｂが正しいパスワードで応答したとき、ＡはＢが真正であることを表明する。この種の簡単なプロトコルには三つの主要な問題点がある。第一に、一旦Ｂがパスワードを公表すると、任意のオブサーバＣはパスワードが何であるかを知る。第二に、Ａはパスワードを検証するためにパスワードを知ることが必要である。第三に、ＣがＡになりすました場合、Ｂは（ＣがＡであると思い）Ｃにパスワードを与え、これにより、Ｂを危険にさらす。著作権のあるテキスト（例えば、俳句）を使用することは、弱い代用である。なぜならば、（例えば、知的所有権が遵守されない国では）誰でもパスワードをコピーすることができると考えられるからである。暗号によるチャレンジ−レスポンスプロトコルの考え方は、唯一のエンティティ（要求者）が、そのエンティティに関して知られている秘密情報の知識を実証することによって、プロトコル中に秘密情報自体を検証者に明かすことなく、自分のアイデンティティを他者（検証者）へ渡すことである。暗号によるチャレンジ−レスポンスプロトコルの一般化されたケースでは、ある種の方式により検証者はその秘密情報を知り、それ以外の場合には、その秘密情報は検証者にさえ知られていない。この実施形態の説明は、特に認証に関係しているので、認証の試し要される実際の暗号によるチャレンジ−レスポンスプロトコルは、適当なセクションで詳述される。しかし、ゼロ知識証明の概念はここで説明する。最初に、Ｆｅｉｇｅ、Ｆｉａｔ及びＳｈａｍｉｒによって明らかにされたゼロ知識証明プロトコルは、認証目的用のスマートカードで広く使用されている。このプロトコルの有効性は、未知の素因数分解による大きい合成整数の平方根モジュローの計算がコンピュータの能力で実施不可能である、という仮定に基づいている。これは、おそらく、大きい整数の素因数分解が困難であるという仮定と等価であろう。尚、要求者は著しい計算パワーをもっていなくてもよいことに注意する必要がある。スマートカードは、数回のモジュロー乗算だけを使用してこの種の認証を実現する。ゼロ知識証明プロトコルは米国特許第４７４７６６８号に記載されている。
【１０２２】
一方向関数
一方向関数Ｆは、入力Ｘに作用し、ＸがＦ［Ｘ］から判定できないようなＦ［Ｘ］を返す。Ｘのフォーマットに制限が無く、Ｆ［Ｘ］がＸよりも少ないビットを格納する場合、衝突が存在する筈である。衝突は、同じＦ［Ｘ］値を生ずる２個の異なるＸ値、即ち、Ｘ１≠Ｘ２であり、しかも、Ｆ［Ｘ１］＝Ｆ［Ｘ２］となるようなＸ１及びＸ２として定義される。ＸがＦ［Ｘ］よりも多数のビットを格納する場合、入力は、出力を生成するために何らかの方法で圧縮されなければならない。殆どの場合に、Ｘは、特定のサイズのブロックに分割され、多数のラウンドに亘って圧縮され、あるラウンドの出力が次のラウンドへの入力である。このハッシュ関数の出力は、Ｘが使い尽くされた後の最後の出力である。圧縮関数ＣＦの疑似衝突は、２個の異なる初期値Ｖ１及びＶ２として定義され、２個の入力Ｘ１及びＸ２（同一であるかもしれない）は、ＣＦ（Ｖ１，Ｘ１）＝ 
ＣＦ（Ｖ２，Ｘ２）となるように与えられる。疑似衝突が存在しても、所与のＸ１に対するＸ２の計算が簡単になるわけではないことに注意する必要がある。
【１０２３】
高速に計算できる一方向関数だけに関心がある。更に、様々な実装において再現可能である決定論的な一方向関数だけに関心がある。一例として、Ｆ［Ｘ］がＦの呼び出しの間の時間であるＦを考える。所与のＦ［Ｘ］に対して、Ｘは決定可能である。なぜならば、ＸはＦによって均等に使用されないからである。しかし、Ｆからの出力は様々な実装において異なる。したがって、この種のＦに興味はない。
【１０２４】
本実施形態の認証チップの実装の説明の範囲では、以下の形式の一方向関数：
未知鍵を使用する暗号化；
乱数シーケンス；
ハッシュ関数；
メッセージ認証コード；
だけに関心がある。
【１０２５】
未知鍵を使用する暗号化
メッセージが未知鍵Ｋを使用して暗号化されたとき、暗号化関数Ｅは事実上一方向性である。この鍵が無い場合、ＥＫ［Ｍ］からＭをＫ無しに獲得することはコンピュータ能力的に実施不能である。暗号化関数は、鍵が隠されている限り一方向性である。暗号化アルゴリズムは衝突を生成しない。なぜならば、Ｅは、関数Ｄを使用してＭを再構築できないようなＥＫ［Ｍ］を生成するからである。この結果として、Ｆ［Ｘ］は、一方向関数ＦがＥであるならば、少なくともＸと同数のビットを格納する（情報は失われない）。（上記の）対称暗号化アルゴリズムは、暗号化に基づく一方向関数を生成する非対称アルゴリズムよりも有利である。その理由は、
所定の強さの暗号化アルゴリズム用の鍵は、非対称アルゴリズムよりも対称アルゴリズムの方が短くなり、
対称アルゴリズムの方が高速に計算でき、必要なソフトウェア／シリコンが少ない、からである。
【１０２６】
優れた鍵の選択は選択された暗号化アルゴリズムに依存する。ある種の鍵は特定の暗号化アルゴリズムの場合に強くないので、全ての鍵の強さをテストすることが必要である。鍵選択のために実行されるべきテストの回数が増えるほど、その鍵が隠された状態を保つ可能性が低くなる。
【１０２７】
乱数シーケンス
乱数シーケンスＲ０，Ｒ１，．．．，Ｒｉ，Ｒｉ＋１を考える。Ｆ［Ｘ］が乱数シーケンス内のＸ番目の乱数を返すような一方向関数を定義する。しかし、Ｆ［Ｘ］は様々な実装において所定のＸに関して再現可能であることを保証しなければならない。したがって、乱数シーケンスは、本当の意味でランダムではない。その代わりに、乱数シーケンスは疑似乱数であり、生成器は特殊なシードを利用する。
【１０２８】
優れた乱数生成器の定義に関して多数の問題がある。Ｋｎｕｔｈは、生成器を「良くする」要因（統計的テストを含む）、生成器の構築に関する一般的な問題を説明している。大半の乱数生成器は、ｉ−１番目の状態からｉ番目の乱数を生成し、ｉ番目の数を決定するための唯一の方法は、０番目の数からｉ番目の数までを繰り返すことである。ｉが大きい場合、ｉ回の繰り返しを待つことは実際的ではない。しかし、あるタイプの乱数生成器はランダムアクセスを許可しない。Ｂｌｕｍ、Ｂｌｕｍ及びＳｈｕｂは、理想的な生成器に関して、「短いシードから、校正なコインの連続的な反転によって完全に発生させられたように見える長い（ビットの）シーケンスを素早く生成するためには疑似ランダムシーケンス生成器が好ましい」のように定義している。彼らは、Ｘ２ 
ｍｏｄ ｎ型の生成器、一般的には、ＢＢＳ生成器と呼ばれる生成器を定義した。現在の暗号化方式が依拠しているある種の仮定を前提とした場合、ＢＢＳ生成器は非常に厳しい統計的テストに合格することを示した。
【１０２９】
ＢＢＳ生成器は、Ｂｌｕｍ整数であるｎの選択に依拠している（ｎ＝ｐｑであり、ｐ及びｑは大きい素数であり、ｐ≠ｑであり、ｐ
ｍｏｄ ４＝３であり、ｑ
ｍｏｄ ４＝３である）。生成器の初期状態は、ｘ０によって与えられ、ここで、ｘ０＝ｘ２
ｍｏｄ ｎであり、ｘは、ｎよりも相対的に優良なランダム整数である。ｉ番目の疑似ランダムビットは、ｘｉの最下位ビットであり、ｘｉ＝ｘｉ−１２ 
ｍｏｄ ｎである。付加的な性質として、ｐ及びｑの知識は、ｘｉ＝ｘ０ｙ
ｍｏｄ ｎ、但し、ｙ＝２ｉ
ｍｏｄ （（ｐ−１）（ｑ−１））によって、シーケンス内のｉ番目の数の直接的な計算を可能にさせる。
【１０３０】
ｐ及びｑの知識がない場合、生成器は、繰り返しを実行しなければならない（計算の安全性は大きい数の素因数分解の困難さに依存する）。当初定義されたとき、ＢＢＳ生成器に関する主要な問題は、単一の出力ビットのために必要な作業量であった。このアルゴリズムは、殆どのアプリケーションに対して遅すぎると考えられていた。しかし、モンゴメリ型リダクション演算の出現によって、より実際的な実装形態が生じた。その上、Ｖａｚｉｒａｎｉ及びＶａｚｉｒａｎｉは、ｎのサイズに依存して、生成器の安全性を譲歩することなく、より多数のビットをｘｉから安全に取り出せることを示した。ｘｉ毎に１ビットだけが必要であるとするならば、Ｎビット（したがって、ビット生成器関数のＮ回の反復）がＮビット乱数を発生させるために必要である。外部オブザーバーにとって、特定のビットの組が与えられた場合に、半々の確率以外で次のビットを決定する方法は無い。ｘ、ｐ及びｑが秘密にされている場合、それらは鍵として作用し、出力ビットストリームを取り出し、ｘ、ｐ及びｑを計算することはコンピュータ能力的に実施不能である。また、所定の疑似ランダムビットの組を発生させるために使用されたｉの値を決定することは、コンピュータ能力的に実施不能である。この最後の特徴によって、生成器は一方向性になる。異なるｉの値が、所定の長さの同じビットシーケンス（例えば、３２ビットのランダムビット）を生じさせる可能性がある。たとえ、ｘ、ｐ及びｑが既知であるとしても、予定のＦ［ｉ］に対して、ｉは確率の組として導出できるだけであり、特定の値として導出できない。（勿論、ｉのドメインが既知であるならば、確率の組は更に限定される）。しかし、良好なｐ及びｑと、良好なシードｘの選択に関して問題がある。特に、Ｒｉｔｔｅｒは、ｘを選択する際の問題について記述している。この問題の性質は、ＢＢＳ生成器が既知長さの単一のサイクルを生成しないことである。その代わりに、ＢＢＳ生成器は、縮退（長さゼロ）サイクルを含む様々な長さのサイクルを生成する。このように、ＢＢＳ生成器は、短いサイクルかもしれないランダム状態を用いて初期化することが不可能である。
【１０３１】
ハッシュ関数
ハッシュ関数として知られている特殊な一方向関数は、任意長さのメッセージを固定長さのハッシュ値へマップする。ハッシュ関数はＨ［Ｍ］のように表される。入力は任意長さであるため、ハッシュ関数は固定長さの出力を生ずるため圧縮コンポーネントを有する。また、ハッシュ関数は、衝突の検出を困難にさせ、Ｈ［Ｍ］からＭに関する情報の決定を困難にさせるため、オブファスケイションコンポーネントを含む。衝突は実際に存在するので、殆どのアプリケーションは、所与のＸ１に対して、Ｈ［Ｘ１］＝Ｈ［Ｘ２］となるようなＸ２を見つけることが困難であるという点で、ハッシュアルゴリズムが耐プレイメージ性であることを必要とする。その上、殆どのアプリケーションは、ハッシュアルゴリズムが耐衝突性である（即ち、Ｈ［Ｘ１］＝Ｈ［Ｘ２］となるような２個のメッセージＸ１及びＸ２を見つけることが困難である）ことを要求する。耐衝突性のあるハッシュ関数が理想的な意味で存在し得るかどうかは、未確定の問題である。ハッシュ関数の主なアプリケーションは、デジタル署名アルゴリズムを適用する前に、入力メッセージをデジタル「指紋」に変形することである。デジタル署名との衝突の一つの問題は以下の例に示されている。
【１０３２】
Ａは、「私はＢに１００ドルの借りがある。」という長いメッセージＭ１を持っている。Ａは、自分の秘密鍵を用いてＨ［Ｍ１］を署名する。どん欲なＢは、Ｈ［Ｍ２］＝Ｈ［Ｍ１］であり、Ｍ２がＢにとって有利であるような衝突メッセージＭ２、例えば、「私はＢに１００万ドルの借りがある。」を探索する。明らかに、このようなＭ２を見つけることが困難であることを保証することはＡの利益である。
【１０３３】
耐衝突性のある一方向ハッシュ関数の例は、ＳＨＡ−１、ＭＤ５、及びＲＩＰＥＭＤ−１６０であり、これらは全てＭＤ４から導かれる。
【１０３４】
ＭＤ４
Ｒｏｎ Ｒｉｖｅｓｔは１９９０年にＭＤ４を発表した。他の全ての一方向ハッシュ関数はＭＤ４から何らかの方法によって導出されるので、ここでは、ＭＤ４を説明する。ＭＤ４は、衝突を探索されるのではなく、計算可能であるという点で、現在では、完全に破られたと考えられている。上記の例において、Ｂは、元のメッセージＭ１と同じハッシュ値を用いて、代わりのメッセージＭ２を普通に発生させることができる。
【１０３５】
ＭＤ５
Ｒｏｎ Ｒｉｖｅｓｔは１９９１年に、安全性の高まったＭＤ４として、ＭＤ５を発表した。ＭＤ４と同様に、ＭＤ５は１２８ビットのハッシュ値を生成する。Ｄｏｂｂｅｒｔｉｎは、最近の攻撃後のＭＤ５の状態を説明している。彼は、ＭＤ５において疑似衝突を見つける方法を説明し、圧縮関数の弱点を指摘し、つい最近、衝突が発見された。即ち、ＭＤ５は、衝突の存在がひどい結果を招くデジタル署名スキームの圧縮に使用されるべきではない。しかし、ＭＤ５は、一方向関数として依然として使用することができる。その上、ＨＭＡＣ−ＭＤ５の構造は、これらの最近の攻撃による影響を受けない。
【１０３６】
ＳＨＡ−１
ＳＨＡ−１はＭＤ５と非常に類似しているが、１６０ビットのハッシュ値を有する（ＭＤ５は１２８ビットのハッシュ値しかない）。ＳＨＡ−１は、デジタル署名標準（ＤＳＳ）で使用するため、ＮＩＳＴ及びＮＳＡによって設計され発表された。最初に発表された説明はＳＨＡと呼ばれたが、その後直ぐに、おそらくＳＨＡの安全性の欠陥を訂正するために改訂され、ＳＨＡ−１となった（但し、ＮＳＡは変更の原因となった数学的な理由を発表していない）。ＳＨＡ−１に対する暗号攻撃は知られていない。また、ＳＨＡ−１は、単にハッシュ結果が長くなったという理由で、力ずくの攻撃に対する耐性がＭＤ４又はＭＤ５よりも強い。米国政府は、ＳＨＡ−１及びＤＳＡアルゴリズム（ＤＳＳの一部として定められたデジタル署名認証アルゴリズム）を保有し、少なくとも一つの関連特許（１９９３年に発行された米国特許５２３１６８８号）を保持する。
【１０３７】
ＲＩＰＥＭＤ−１６０
ＲＩＰＥＭＤ−１６０は、その前進であるＲＩＰＥＭＤ（１９９２年に欧州委員会のＲＩＰＥプロジェクトのために開発された）から導出されたハッシュ関数である。その名前から分かるように、ＲＩＰＥＭＤ−１６０は、１６０ビットのハッシュ結果を生成する。３２ビットアーキテクチャのソフトウェア実装のため合わされたＲＩＰＥＭＤ−１６０は、１０年間以上に亘って高いセキュリティレベルを提供することを予定されている。ＲＩＰＥＭＤ−１６０に対する攻撃の成功例は存在しないが、ＲＩＰＥＭＤ−１６０は比較的新しく、大規模に解読されていない。最初のＲＩＰＥＭＤアルゴリズムは、従来のＭＤ４に対する暗号攻撃に対抗するために特に設計された。最近のＭＤ５に対する攻撃は、ＲＩＰＥＭＤの１２８ビットハッシュ関数においても類似した弱点を明らかにした。この攻撃は理論的な弱点を示しただけであるが、Ｄｏｂｂｅｒｔｉｎ、Ｐｒｅｎｅｅｌ及びＢｏｓｓｅｌａｅｒｓは、ＲＩＰＥＭＤを新しいアルゴリズムＲＩＰＥＭＤ−１６０へ更に強化した。
【１０３８】
メッセージ認証コード
メッセージ認証の問題は以下のようにまとめることができる：
Ａは、Ｂからのメッセージであると推測されるメッセージが本当にＢからのメッセージであることをどのようにして確信するか？
メッセージ認証はエンティティ認証とは異なる。エンティティ認証の場合、一つのエンティティ（要求者）は、自分のアイデンティティを他者（検証者）に対して照明する。メッセージ認証の場合、所定のメッセージが自分の思う人からのメッセージであることを保証すること、即ち、メッセージが発信元から宛先までの途中で改ざんされていないことを保証することに関係する。一方向ハッシュ関数はメッセージに対する保護が十分ではない。ＭＤ５のようなハッシュ関数は、元の入力を代表するハッシュ値を発生させ、元の入力がハッシュ値から導出できないことに基づいている。ＡとＢの間にいるＥからの簡単な攻撃は、Ｂからのメッセージを途中で盗み、自分のメッセージで置き換えることである。たとえ、Ａが元のメッセージのハッシュを送信したとしても、Ｅは自分の新しいメッセージのハッシュで簡単に置き換えることができる。一方向ハッシュだけを使用した場合、ＡはＢのメッセージが変更されたかどうかを知る方法がない。メッセージ認証の問題に対する一つのソリューションは、メッセージ認証コード、即ち、ＭＡＣだえる。ＢがメッセージＭを送信するとき、Ｂは、受信者にＭが本当にＢからのメッセージであることがわかるようにＭＡＣ［Ｍ］を送信する。これを実現するため、ＢだけがＭのＭＡＣを生成可能であり、更に、ＡはＭＡＣ［Ｍ］と対照してＭを検証し得ることが必要である。これは、Ｍを秘密にする必要がないときに、Ｍ−ＭＡＣの暗号化が有効であることとは異なることに注意する必要がある。ハッシュ関数からＭＡＣを構築する最も簡単な方法は、対称アルゴリズムを用いてハッシュ値を暗号化すること、即ち、
入力メッセージをハッシュ化 Ｈ［Ｍ］
ハッシュを暗号化 ＥＫ［Ｈ［Ｍ］］
である。
【１０３９】
これは、最初にメッセージを暗号化して、次に、暗号化されたメッセージをハッシュ化するよりも安全性が高い。任意の対称又は非対称暗号化関数を使用することができる。しかし、（上記のような）暗号化を使用する技術の代わりに、鍵依存型の一方向ハッシュ関数を使用する方が以下の幾つかの点で有利である：
速度：一方向ハッシュ関数は一般的に暗号化よりも高速に動作するため；
メッセージサイズ：ＥＫ［Ｈ［Ｍ］］は少なくともＭと同じサイズであるが、Ｈ［Ｍ］は固定サイズ（通常、Ｍよりもかなり小さい）であるため；
ハードウェア／ソフトウェア必要条件：鍵付きの一方向ハッシュ関数は、典型的に、それらの暗号ベースの代案よりも遙かに複雑さが抑えられている；
一方向ハッシュ関数の実装は、暗号化装置又は復号化装置であるとはみなされないので、米国の国外持ち出し規制の対象ではない。
【１０４０】
尚、ハッシュ関数は、当初は、鍵を格納したり、メッセージ認証をサポートしたりするためには設計されていなかったことに注意する必要がある。その結果として、メッセージを秘密プレフィックス、サフィックス、又は両方と連結する種々の関数を含む、メッセージ認証を実行するためにハッシュ関数を使用する、ある種のアドホックな方法が提案されている。これらのアドホックな方法の殆どは、洗練された手段によって巧く攻撃された。付加的なＭＡＣは、ＸＯＲスキーム及びテプリッツ（Ｔｏｅｐｌｉｔｚ）行列に基づいて提案されている（ＬＦＳＲベース構造の特殊なケースを含む）。
【１０４１】
ＨＭＡＣ
特にＨＭＡＣ構造は、インターネットメッセージ認証セキュリティプロトコル用のソリューションとして認められ始めている。ＨＡＭＣ構造は、基礎となるハッシュ関数をブラックボックス的に使用して、ラッパーとして作用する。ハッシュ関数の置換は、安全性又は性能上の理由から求められるならば、簡単に行われる。しかし、ＨＭＡＣ構造の主要な利点は、基礎となるハッシュ関数がある程度の合理的な暗号強度を有するならば、ＨＭＡＣ構造は安全であることが証明できること、即ち、ＨＭＡＣの強度は、ハッシュ関数の強度と直接的に関連していることである。ＨＭＡＣ構造はラッパーであるため、任意の反復ハッシュ関数をＨＭＡＣで使用することが可能である。その例には、ＨＭＡＣ−ＭＤ５、ＨＭＡＣ−ＳＨＡ１、ＨＭＡＣ−ＲＩＰＥＭＤ１６０等が含まれる。以下のような定義：
Ｈ＝ハッシュ関数（例えば、ＭＤ５又はＳＨＡ−１）
ｎ＝Ｈから出力されたビット数（例えば、ＳＨＡ−１の場合１６０ビット、ＭＤ５の場合１２８ビット）
Ｍ＝ＭＡＣ関数が適用されるべきデータ
Ｋ＝２当事者によって共有される秘密鍵
ｉｐａｄ＝０ｘ３６の反復６４回
ｏｐａｄ＝０ｘ５Ｃの反復６４回
を与えると、ＨＭＡＣアルゴリズムは：
０ｘ００バイトをＫの最後に付加することによってＫを６４バイトへ拡張する；
（１）で作成された６４バイト文字列をｉｐａｄでＸＯＲ演算する；
（２）で作成された６４バイトにデータストリームＭを付加する；
（３）で発生されたストリームにＨを適用する；
（１）で作成された６４バイト文字列をｏｐａｄでＸＯＲ演算する；
（４）からの結果Ｈを（５）からの結果である６４バイトに付加する；
（６）の出力にＨを適用し、結果を出力する；
のようになる。したがって、
ＨＭＡＣ［Ｍ］＝Ｈ［（ＫAｏｐａｄ）｜Ｈ［（ＫAｉｐａｄ）｜Ｍ］］
である。
【１０４２】
推奨される鍵長さは少なくともｎビットであるが、６４バイト（ハッシュ化ブロックの長さ）よりも長くなってはならない。ｎビットよりも長い鍵は、関数の安全性を上乗せしない。ＨＭＡＣは、オプションとして、最終的な出力の丸め、例えば、１６０ビットから１２８ビットへの丸めを行うことできる。ＨＭＡＣ設計者の規約（ＲＦＣ）は、このアルゴリズムが最初に発表された１年後の１９９７年に発行された。設計者は、ＨＭＡＣに対する既知の最強の攻撃は、ハッシュ関数Ｈに対する衝突の頻度に基づく攻撃であり、最低限度で適当なハッシュ関数に対して全く実際的ではないということを公表している。より最近では、リプレイ防止機能付きＨＭＡＣプロトコルが、所定の時間内でのＭ、ＨＭＡＣ［Ｍ］コンビネーションの捕捉及び再生を防止するために規定されている。
【１０４３】
乱数及び時変性メッセージ
一方向関数としての乱数生成器の使用については既に説明した。しかし、乱数生成器の理論は、暗号法、セキュリティ、及び認証と非常に絡み合っている。優れた乱数生成器の定義に関して多数の問題がある。Ｋｎｕｔｈは、生成器をよくするもの（統計的テストを含む）、及び生成器の構築に関する一般的な問題を説明している。乱数の用法の一つは、メッセージが時間的に変化することを保証することである。Ａがコマンドを暗号化し、それをＢへ送信するシステムを想定する。暗号化アルゴリズムが所与の入力と同じ出力を生成する場合、攻撃者は、簡単にメッセージを記録し、Ｂを欺くためにそれを再生することが可能である。攻撃者は、暗号化機構を破壊する必要がなく、（Ａになりすましている間に）Ｂに対して再生すべきメッセージがわかれればよい。その結果として、メッセージは、しばしば、そのメッセージ（したがって、その暗号化された対応部分）が常に変化することを保証するため、乱数及びタイムスタンプを含む。乱数生成器は、しばしば、鍵を生成するためにも使用される。したがって、現時点では、全ての生成器は、この目的のためには不確かであると言って差し支えない。例えば、Ｂｅｒｌｅｋａｍｐ−Ｍａｓｓｅｙアルゴリズムは、ＬＦＳＲ乱数生成器に対する従来の攻撃法である。ＬＦＳＲの長さがｎであるならば、２ｎビットのシーケンスは、鍵生成器を構成するＬＦＳＲを決定するために十分である。しかし、乱数生成器の唯一の役目は、メッセージが時間的に変化することを保証することであるならば、生成器及びシードのセキュリティは、セッション鍵生成の場合のように重要ではない。しかし、乱数シード生成器が危険にさらされ、攻撃者が未来の「乱数」を計算可能であるならば、一部のプロトコルが攻撃者に対して開放されたままにされ得る。新しいプロトコルはこの状況に関して検討されるべきである。要求される実際のタイプの乱数生成器は、インプリメンテーションと、その生成器の使用目的と、に依存するであろう。生成器には、Ｒｏｎ 
ＲｉｖｅｓｔによるＲＣ４のようなＢｌｕｍ、Ｂｌｕｍ、及びＳｈｕｂストリーム暗号、ＳＨＡ−１及びＲＩＰＥＭＤ−１６０のようなハッシュ関数、並びに、ＬＦＳＲ（線形フィードバックシフトレジスタ）及びそれらのより最近の対応物であるＦＣＳＲ（キャリー付きフィードバックシフトレジスタ）のような従来の生成器が含まれる。
【１０４４】
攻撃
このセクションは、認証チップのような認証暗号システムを破るために行われる可能性のある様々なタイプの攻撃を説明する。攻撃は、物理的な攻撃と論理的な攻撃に大別される。物理的な攻撃は、暗号システムの物理的な実装を破壊する（例えば、鍵を取り出すためにチップを壊して開ける）方法を表し、論理的な攻撃は、実装に依存しない暗号システムへの攻撃を含む。論理的なタイプの攻撃は、プロトコル又はアルゴリズムに対して機能し、以下の三つのうちの何れかを実行しようとする：
認証プロセスを完全に回避する；
あらゆる質問に回答できるように、力ずく又は推論によって秘密鍵を取得する；
鍵を用いることなく各質問に正しい回答を与えるため、認証用の質問及び回答の性質を十分に検出する。
【１０４５】
次に、攻撃のスタイル及び形式を詳細に説明する。セキュリティチップによって使用されるアルゴリズム及びプロトコルとは無関係に、チップの認証部の回路は物理的な攻撃を受ける可能性がある。物理的な攻撃は、以下の４つの主要な形で現れるが、攻撃の形態は変化し得る：
認証チップを完全に回避する；
動作中にチップを物理的に検査する（破壊的及び非破壊的）；
チップを物理的に分解する；
チップを物理的に改変する。
【１０４６】
次に、攻撃のスタイル及び形式を詳細に説明する。このセクションは、これらの攻撃に対するソリューションを提案するものではない。このセクションは、各攻撃タイプを説明するだけである。調査は、（インターネット認証のような他のある種のシステムではなく）あるシステムに取り付けられた認証チップ５３の状況に限定されている。
【１０４７】
論理的な攻撃
これらの攻撃は、暗号システムの物理的な実装形態に依存しない。これらは、プロトコル、アルゴリズムの安全性、及び乱数生成器に作用する。
【１０４８】
暗号文だけの攻撃
これは、攻撃者が、全て同じアルゴリズムを使用して暗号化された一つ以上の暗号化メッセージをもつ場合である。攻撃者の目的は暗号化メッセージから平文メッセージを獲得することである。理想的には、鍵を復元することが可能であり、その結果、将来のすべてのメッセージを復元可能である。
【１０４９】
既知平文攻撃
これは、攻撃者が、平文と、平文の暗号化形式の両方をもつ場合である。認証チップの場合、既知の平文の攻撃は、攻撃者がシステムと認証チップの間のでーたフローを見ることができる場合である。入力及び出力は（攻撃者によって選別されることなく）観測され、弱点を見つけるため解析され得る（例えば、バースデー攻撃、又は区別の付く興味ある入力／出力のペアの探索によって）。既知平文攻撃は、選択平文攻撃よりも弱いタイプの攻撃である。なぜならば、攻撃者はデータフローしか観測できないからである。既知平文攻撃は、ロジックアナライザを、システムと認証チップの間の配線に接続することによって実行し得る。
【１０５０】
選択平文攻撃
選択平文攻撃は、暗号解読者が任意の選択されたメッセージを暗号システムへ送信し、その応答を観測できる能力を備えている場合である。暗号解読者がアルゴリズムを知っているならば、特定の出力を別の関数の入力へ供給することによって利用可能な入力と出力の間の関係があるであろう。内蔵型認証チップを使用するシステムでは、選択平文攻撃を防止することは難しい。なぜならば、暗号解読者は、論理的に自分がシステムであるふりをして、任意の選択されたビットパターンストリームを認証チップへ送信できるからである。
【１０５１】
適応的選択平文攻撃
このタイプの攻撃は選択平文攻撃と類似しているが、攻撃者が先行の試験の結果に基づいて後続の選択された平文テキストを変更し得る点で異なる。上述のシステム／認証チップのシナリオがコピー機及びトナーカートリッジのような消耗品のために利用されるときは、確実にこのケースである。なぜならば、特に、システムと消耗品の両方は誰でも入手できるようにされているからである。
【１０５２】
ブルートフォース攻撃
鍵ベースの暗号システムアルゴリズムを破るための保証付きの方法は、単純に全ての鍵を試してみることである。最終的に正しい鍵が見つけられるであろう。これは、ブルートフォース攻撃として知られている。しかし、鍵候補の数が増加すると、より多くの鍵を試してみる必要があり、正しい鍵を見つけるために（平均的に）要する時間が長くなる。Ｎ個の鍵がある場合、最大でＮ回の試行が必要である。鍵の長さがＮビットであるならば、最大で２Ｎ回の試行が必要であり、半分だけの試行（２Ｎ−１）後に鍵を見つけるチャンスは５０％である。Ｎが長くなればなるほど、鍵を見つけるために要する時間が長くなるので、鍵の安全性が高まる。勿論、攻撃が最初の試行で鍵を当てる可能性はあるが、この可能性は鍵が長くなると共に低下する。ここで、５６ビットの鍵長さを考える。最悪ケースでは、鍵を見つけるために全部で２５６回のテスト（７．２×１０１６回のテスト）を行わなければならない。１９７７年に、ＤｉｆｆｉｅとＨｅｌｌｍａｎは、１００万個のプロセッサにより構成され、各プロセッサが毎秒１００万回のテストを実行刷る能力を備えたＤＥＳ解読専用機械を発表した。このような機械は任意のＤＥＳコードを破るためには２０時間を要する。鍵長さが１２８ビットの場合を考える。最悪ケースでは、鍵を見つけるために全部で２１２８回のテスト（３．４×１０３８回のテスト）を行わなければならない。これは、各々が毎秒１０億回のテストを実行する１兆個のプロセッサ上で１０億年を要する。鍵長さが十分に長い場合、ブルースフォース攻撃は非常に長い時間を要するので、攻撃者の努力に値しない。
【１０５３】
推測攻撃
このタイプの攻撃は、攻撃者が単に鍵を「推測」しようとする場合である。攻撃としては、ブルースフォース攻撃と同じであり、成功の確率は鍵の長さにかかっている。
【１０５４】
量子コンピュータ攻撃
ｎビット鍵を解読するため、適切なアルゴリズムに埋め込まれたｎキュビットを有する量子コンピュータ（ＮＭＲ、オプティカル、又はケージドアトム）を構築しなければならない。量子コンピュータは、実効的に、２ｎ個の同時コヒーレント状態に存在する。デコヒーレントを生じることなく正しいコヒーレント状態を抽出することが要領である。今までのところ、これは、２キュビットのシステム（４コヒーレント状態で存在する）によって達成されている。数年の間に、これを６キュビット（６４の同時コヒーレント状態をもつ）まで拡張することは可能であると思われる。
【１０５５】
残念なことに、キュビットを付加する毎に、鍵を表現する信号の相対強度が半分になる。これは、特に、暗号方式的に安全なシステムで使用される長い鍵の場合に、直ぐに鍵取り出しの重大な障害になる。その結果として、量子コンピュータを使用した、暗号方式的に安全な鍵（例えば、１６０ビット）に対する攻撃は、おそらく実施される可能性はなく、量子コンピュータが、認証チップの商業的な耐用年限中に５０キュビット以上のキュビット数を達成する可能性は非常に低い。たとえ、５０キュビットの量子コンピュータを使用しても、１６０ビット鍵を解読するために、２１１０回のテストが必要である。
【１０５６】
意図的なエラー攻撃
一部のアルゴリズムの場合、攻撃者は悪い入力の結果から有用な情報を収集することができる。有用な情報の範囲は、エラーメッセージ文から、エラーを発生させるために要した時間までに亘る。簡単な一例は、ユーザＩＤ／パスワードのスキームである。エラーメッセージが通常「間違ったユーザＩＤ」であるならば、攻撃者が「間違ったパスワード」というメッセージを取得したとき、ユーザＩＤが正しいことを知る。メッセージが常に「間違ったユーザＩＤ／パスワード」であるならば、攻撃者に与えられる情報は遙かに少ない。より複雑な例は、最近発表された、安全なウェブサイトから暗号コードを解読する方法である。この攻撃には、特定のメッセージをサーバーへ送信することと、エラーメッセージ応答を観測することとが含まれる。応答は、鍵を学習するために十分な情報を与え、応答が無くても何らかの情報が得られる。アルゴリズムの一例として、時間は、誤りのあるビットが入力メッセージ中に検出されたときに直ちにエラーを返すアルゴリズムの場合に知ることができる。ハードウェア実装形態に依存して、攻撃者が、応答の時間を計り、エラー応答に要した時間に基づいて１ビットずつ変更し、このようにして鍵を獲得することは、簡単な方法である。チップ実装形態の場合、必要な時間がインターネット経由の場合よりもかなり高い精度で観測できることは確実である。
【１０５７】
バースデー攻撃
この攻撃は、有名な「バースデーパラドックス」（実際には全くパラドックスではない）にちなんで命名された。ある人が他の人と同じ誕生日である確率は３６５分の１である（閏年は考えない）。したがって、室内の１８３人のうちの一人があなたと同じ誕生日である確率は５０％よりも高い筈である。しかし、室内に２３人の人がいれば、何れか二人の誕生日が同じである確率は５０％を超える。その理由は、２３人によって２５３通りのペアが生じるからである。バースデー攻撃は、ハッシングアルゴリズム、特に、ハッシングとデジタル署名を組み合わせるアルゴリズムに対する一般的な攻撃である。メッセージが生成され、既に署名されている場合、攻撃者は、同じ値にハッシュする衝突メッセージを探す必要がある（あなたと同じ誕生日の人を見つけることと類似している）。しかし、攻撃者がメッセージを生成可能であるならば、バースデー攻撃が作用し始める。攻撃者は、同じハッシュ値をもつ二つのメッセージを探し（何れか二人が同じ誕生日である場合と類似している）、一方のメッセージだけがそれに署名をした人に受け入れられ、もう一方は攻撃者の役に立つ。その人が元のメッセージに署名をし終えたならば、攻撃者は、その人は別のメッセージに署名をしたことを主張するだけでよく、数学的にどちらのメッセージが原本であるかを示す方法は無い。なぜならば、両方のメッセージは同じ値にハッシュするからである。ブルートフォース攻撃が一致を判定するための唯一の方法であるとすると、バースデー攻撃によるｎビット鍵の脆弱化は２ｎ／２である。バースデー攻撃を受ける可能性のある１２８ビットの長さの鍵は、事実上６４ビットの長さしかない。
【１０５８】
連鎖攻撃
これらの攻撃は、ハッシュ関数の連鎖性に対して行われる攻撃である。連鎖攻撃は、ハッシュ関数の圧縮関数に的を絞る。このアイデアは、ハッシュ関数が一般的に任意の長さの入力をとり、入力ｎビットを同時に処理することによって、一定の長さの出力を生成する点に基づいている。１ブロックからの出力は次のブロックへの連鎖変数セットとして使用される。入力全体に対する衝突を見つけるのではなく、このアイデアは、入力連鎖変数セットが与えられた場合に、本来のメッセージと同じ出力連鎖変数を生じる代用ブロックを見つけることである。特定のブロックの選択数は、ブロックの長さに基づいている。連鎖変数がｃビットであり、ハッシング関数はランダムマッピングのように挙動し、ブロック長さがｂビットであるならば、このようなｂビットブロックの個数は、約２ｂ／２ｃ個である。代用ブロックを見つけるためのチャレンジは、このようなブロックが考えられる全てのブロックのうちの疎部分集合であることである。ＳＨＡ−１の場合、５１２ビットブロックの個数は、約２５１２／２１６０、即ち、２３５２個である。ブルートフォース検索によってブロックを見つける見込みは２１６０分の１である。
【１０５９】
完全ルックアップテーブルによる代用
チップへ送信された可能性のあるメッセージの数が少ない場合、鍵を解読するために複製品製造者は不要である。その代わりに、複製品製造者は、システムによって送信されたコードに対する純正チップからのレスポンスの全てを記録したＲＯＭをチップに組み込むことが可能である。鍵が長くなり、レスポンスが長くなると共に、このようなルックアップテーブルに必要な空間が大きくなる。
【１０６０】
疎ルックアップテーブルによる代用
チップへ送られたメッセージが、実効的にランダムではなく、ある程度予測可能であるならば、複製品製造者は完全ルックアップテーブルを提供しなくてもよい。例えば：
メッセージが単なるシリアル番号であるならば、複製品製造者は、過去及び未来の予測シリアル番号を格納するルックアップテーブルを提供すればよい。これらのシリアル番号が１０１９個を超える可能性は低い；
テストコードが単なる日付であるならば、複製品製造者はアドレスとして日付を使用してルックアップテーブルを生成することができる；
テストコードが、シリアル番号又は日付をシードとして用いる疑似乱数であるならば、複製品製造者は、まさに、システム内の疑似乱数生成器を解読する必要がある。これは、おそらく難しくはないであろう。なぜならば、複製品製造者はシステムのオブジェクトコードを入手できるからである。複製品製造者は、蓄積された認証コードへアクセスするためこれらのコードを使用して、内容アドレス可能メモリ（又は、その他の疎配列ルックアップ）を生成するであろう。
【１０６１】
差分暗号解読
差分暗号解読は、入力ストリームのペアが既知差分を用いて生成され、符号化ストリームの差分が解析される攻撃を表す。既知差分攻撃は、ＤＥＳ及びその他の同様のアルゴリズムで使用されるようなＳボックスの構造にかなり依存している。ＨＭＡＣ−ＳＨＡ１のような他のアルゴリズムはＳボックスを持たないが、攻撃者は、
最小差分入力及びそれに対応した出力
最小差分出力及びそれに対応した入力
の統計的解析を行うことによって差分的な攻撃を実行し得る。
【１０６２】
殆どのアルゴリズムは、差分暗号解読のプロセスが記載された後、差分暗号解読に対して補強された。これは、各暗号化方式に専用のセクションで対称とされている。しかし、一部の密かに開発された近年のアルゴリズムは破られている。なぜならば、開発者がある種のスタイルの差分攻撃を考慮せず、自分のアルゴリズムを公開の精査の対象としなかったからである。
【１０６３】
メッセージ置換攻撃
ある種のプロトコルでは、媒介物はメッセージの一部又は全部を置換可能である。これは、真の認証チップが消耗品内の再使用可能な複製チップにプラグインされる場合である。複製チップは、システムと認証チップの間の全てのメッセージを盗み取り、多数の置換攻撃を実行し得る。ヘッダとその後に続く内容とを格納したメッセージを例として考える。攻撃者は有効ヘッダを生成し得ないが、特に、有効レスポンスが「はい、あなたのメッセージを受信しました。」のようなものであるならば、メッセージの固有の内容を置換することができる。たとえ、リターンメッセージが「はい、以下のメッセージを受信しました．．．」であったとしても、攻撃者は、肯定応答を本来の送信者へ返信する前に、元のメッセージを置換することができる。メッセージ認証コードは、殆どのメッセージ置換攻撃に対抗するために開発された。
【１０６４】
鍵生成器のリバースエンジニアリング
疑似乱数生成器が鍵を生成するため使用される場合、複製品製造者は、生成器プログラムを取得するか、又は使用されたランダムシードを推測する可能性がある。これは、ネットスケープのセキュリティプログラムが最初に破られたときの方法である。
【１０６５】
認証全体の回避
認証プロトコルには認証プロセス全体の回避を可能にする問題があり得る。この種の攻撃の場合、鍵は全く無関係であり、攻撃者は鍵を復元する、又は鍵を推定する必要がない。電源投入時に認証を行なうが、その他のときには認証しないシステムを例として考える。複製認証チップを含む再使用可能な消耗品は、真正認証チップを利用する場合もある。複製認証チップ５３は、認証呼び出しのため真正チップを使用し、次に、その後の真正認証チップの状態データをシミュレーションする。認証を回避する別の例は、消耗品が使用された後に限りシステムが認証する場合である。複製認証チップは、消耗品の使用後で、認証プロトコルが完了する前に（或いは、開始される前に）コネクションの失敗をシミュレーションすることにより単純な認証回避を実行できる。「ケンタッキーフライドチップ」ハックと呼ばれる悪名の高い攻撃は、衛星テレビジョンシステム用のマイクロコントローラチップを置換する。加入者が受信料の支払いを停止したとき、システムは、「使用不能」メッセージを送出するであろう。しかし、新しいマイクロコントローラは、このメッセージを検出するだけで、それを消費者の衛星テレビジョンシステムへ渡さない。
【１０６６】
強盗／賄賂攻撃
鍵を知っている人は、それを他の誰かに教える可能性がある。この秘密の暴露は、強制（賄賂、強盗等）、報復（例えば、不満を抱いている従業員）、又は単に信条のために行われる。これらの攻撃は、通常、鍵を推測する他の試みよりも安価かつ容易である。一例として、Ｄｉｖｘ規格の開発に関わることを要求した多数の人々は、近年（１９９８年５／６月）、Ｄｉｖｘ仕様解読解読装置の開発に参加したいという趣旨で、即ち、信条によって、多種多様なＤＶＤニュースグループで主張している。
【１０６７】
物理的攻撃
以下の攻撃は、攻撃者が物理的にアクセスできるシリコンチップに認証機構が実装されていることを前提としている。最初の攻撃であるＲＯＭ読み出しは、鍵がＲＯＭに保存されているときの攻撃を表し、残りの攻撃は秘密鍵がフラッシュメモリに保存されることを前提としている。
【１０６８】
ＲＯＭ読み出し
鍵がＲＯＭに保存されている場合、鍵を直接読み出すことが可能である。ＲＯＭは、このように（非対称暗号方式で使用するための）公開鍵を保持するため安全に使用することができるが、秘密鍵を保持するためには使用できない。対称暗号方式では、ＲＯＭは全く当てにならない。著作権付きテキスト（例えば、俳句）を鍵として使用することは不十分である。なぜならば、鍵の複製は、知的所有権が遵守されない国で行われることが想定されるからである。
【１０６９】
チップのリバースエンジニアリング
チップのリバースエンジニアリングでは、攻撃者は、チップを分解し、回路を解析する。回路が解析されてしまうと、チップのアルゴリズムの内部動作を復元することができる。ルーセント・テクノロジー社は、回路を映像化するため、ＴＯＢＩＣ（ツー・フォトンＯＢＩＣの略であり、ＯＢＩＣはＯｐｔｉｃａｌ 
Ｂｅａｍ Ｉｎｄｕｃｅｄ  Ｃｕｒｒｅｎｔ光ビーム誘導電流の頭文字である。）と呼ばれるアクティブな方法を開発した。主としてスタティックＲＡＭ解析のために開発されたプロセスは、全ての裏材を取り除き、裏面を鏡面仕上げまで磨き、表面に光を集光させる。励起波長は、特にＩＣに電流を誘導しないように選択される。１９世紀にケルクホフスは、アルゴリズムの内部動作がスキームの単なる秘密であるならば、スキームは解読されたも同然である、という暗号解読に関する基本的な仮説を立てた。ケルクホフスは、秘密性は完全に鍵の中に存在しなければならない、ということを明記している。その結果として、チップのリバースエンジニアリングに対する最良の保護策は、内部動作を無関係にすることである。
【１０７０】
認証プロセスの不当使用
あらゆる複製品製造者はシステムと消耗品の両方のデザインを入手していることを想定しなければならない。同じチャンネルが、システムと信頼できるシステム認証チップとの間、並びに、信頼できない消耗品認証チップとの間の通信のために使用されるならば、信頼できないチップが「正しい回答」を得るために信頼できるチップに問い合わせをする可能性がある。もしそうであるならば、複製品製造者は鍵を決定する必要がないであろう。彼らは、システム認証チップからの応答を使用してシステムをだますだけでよい。認証プロセスを不当使用する別の方法は、論理的攻撃「認証プロセスの回避」と同じ方法に従って、認証プロセスが行われるとき、システムとの接続の失敗をシミュレーションし、電源遮断等をシミュレーションする。
【１０７１】
システムの変更
この種の攻撃は、システム自体が複製消耗品を受け入れるように変更される攻撃である。攻撃は、システムＲＯＭの変更、消耗品の配線し直し、又は極端なケースでは、完全な複製システムである。この種の攻撃は、各個のシステムが変更されることが必要であり、殆どの場合に所有者の承諾が必要であろう。通常は、消費者がこのような変更を行うために明らかな利益が必要である。なぜならば、このような変更は、典型的に、保証を無効にさせ、殆どの場合に費用が掛かるからである。消費者にとって明らかな利益のあるこのような変更の一例は、固定リージョン型ＤＶＤプレーヤーをリージョンフリー型ＤＶＤプレーヤーに変更するソフトウェアパッチである。
【１０７２】
従来のプロービングによるチップ動作の直接視
チップ動作がＳＴＭ又は電子ビームを使用して直接監視できるならば、鍵は、内部不揮発性メモリから読み出され、作業レジスタへ取り込まれるときに記録できる。従来の３形態のプロービングは、ＩＣの通電中にＩＣの上面又は前面に直接アクセスすることが必要である。
【１０７３】
不揮発性メモリの直接視
チップが、フラッシュメモリのフローティングゲートを放電させることなく露出するためにスライスされているならば、鍵は、おそらく、ＳＴＭ又はＳＫＭ（走査ケルビン顕微鏡）を使用して直接監視できる。しかし、ゲートを放電させることなくこのレベルでチップをスライスすることはおそらく実施不可能である。湿式エッチング、プラズマエッチング、イオンミリング（集光イオンビームエッチング）、又は化学機械研磨は、ほぼ確実にフローティングゲート上に存在する小さい電荷を放出する。
【１０７４】
状態変化によって生じる光バーストの監視
ゲートの状態が変化するとき、少量の赤外線エネルギーが放出される。シリコンは赤外線透過性であるため、これらの変化はチップの下側から回路を注視することによって観測できる。放出プロセスは弱いが、天文学で使用するために開発された超高感度機器を用いて検出できる程度に輝いている。ＩＢＭによって開発されたこの技術は、ＰＩＣＡ（ピコセコンド・イメージング・サーキット・アナライザ）と呼ばれる。レジスタの状態が時点ｔで既知であるならば、レジスタ切り替わり時間の監視によって、時点ｔ＋ｎにおける正確な値が明らかになり、データが鍵の一部分であるならば、その部分は解読される。
【１０７５】
ＥＭＩの監視
電子回路が動作しているときには、かならず微弱な電磁信号が放出される。比較的低価格（数千ドル）装置はこれらの信号を監視できる。これは、攻撃者が鍵を推測するために十分な情報を与える。
【１０７６】
Ｉｄｄ変動の監視
鍵を監視できないとしても、レジスタが状態を変化させるときにはかならず電流の変動が生じる。信号対雑音比が十分に高い場合、攻撃者は、ハイビット又はロービットをプログラミングするときに生じるＩｄｄの差を監視することができる。Ｉｄｄの変化は鍵に関する情報を示し得る。このような攻撃は、スマートカードを解読するために既に使用されている。
【１０７７】
差分故障解析
この攻撃は、イオン化、マイクロ波放射、又は環境ストレスによってビット誤りが取り込まれることを前提としている。殆どのケースでは、このような誤りは、鍵を明らかにするであろう役に立つ変更ではなく、チップに悪影響を与える（例えば、プログラムコードを破壊させる）可能性が高い。ＲＯＭ上書き、ゲート破壊等のような目標としている故障は、有用な結果を生じる可能性が更に低い。
【１０７８】
クロック誤作動攻撃
チップは、典型的に、一定のクロック速度レンジ内で適切に動作するように設計されている。一部の攻撃者は、チップを非常に高いクロック速度で動作させることによってロジックに故障を生じさせ、又は特定の間隔で特定の時間にクロック誤作動を生じさせることを試みる。このアイデアは、回路が適切に機能しない乱調状態を作ることである。一例として、ＡＮＤゲートは、（乱調状態のために）入力１と入力２の論理積ではなく、常に入力１をスルーする。攻撃者がチップの内部構造を知っているならば、攻撃者は、アルゴリズム実行中の正確な時点で乱調状態を取り入れ、これにより、鍵に関する情報を明らかにすることができる（或いは、最悪ケースでは、鍵自体を明らかにする）。
【１０７９】
電源攻撃
クロック信号に誤動作を引き起こす代わりに、攻撃者は電源に誤動作を生じさせることができ、電力は動作電圧レンジを外れるように増加又は減少させられる。正味の効果はクロック誤動作の場合と同じであり、特定の命令の実行に誤りを生じさせる。このアイデアは、ＣＰＵが鍵をＸＯＲ演算することを停止させること、又はデータを１ビット位置だけシフトすることを停止させること等である。鍵に関する情報を明らかにするために、特定の命令が目標にされる。
【１０８０】
ＲＯＭの上書き
ＲＯＭの単一ビットは、レーザーカッター顕微鏡を使用して、ロジックの向きに応じて、１又は０に書き換えることができる。あるオペコード／オペランドのセットがある場合、攻撃者が条件付きジャンプを無条件ジャンプへ書き換えること、又はたぶんレジスタ転送の宛先を変更することは簡単なことである。目標命令が慎重に選択されたならば、鍵が明らかにされるであろう。
【１０８１】
ＥＥＰＲＯＭ／フラッシュの変更
ＥＥＰＲＯＭ／フラッシュ攻撃は、ＲＯＭ攻撃と類似しているが、レーザーカッター顕微鏡技術が個別のビットのセットとリセットの両方に使用できる点で異なる。これは、アルゴリズムの変更の適用範囲を非常に拡大する。
【１０８２】
ゲート破壊
ＡｎｄｅｒｓｏｎとＫｕｈｎは、ＢｉｈａｍとＳｈａｍｉｒがＤＥＳに関する攻撃を発表した高速ソフトウェア暗号化に関する１９９７年のワークショップのランプセッションで、ゲート破壊を説明している。この攻撃は、従来のブロック暗号（ＤＥＳ）のハードウェア実装内の個々のゲートを破壊するためレーザーカッターを使用するものであった。この攻撃の正味の効果は、レジスタの特定のビットを強制的に「無価値」にすることである。ＢｉｈａｍとＳｈａｍｉｒは、特定のレジスタに強制的にこのような影響を与えることの効果−丸め関数からの出力の最下位ビットが０にセットされる、を説明している。左半分と右半分の最下位６ビットを比較することにより、鍵の数ビットを復元することができる。このようにして多数のチップにダメージを加えると、完全な鍵の復元を容易に行うために、鍵に関する十分な情報を明らかにすることができる。このように変更された暗号化チップは、暗号化と復号化はもはや逆の関係ではなくなるという性質をもつであろう。
【１０８３】
上書き攻撃
フラッシュメモリを読み出す代わりに、攻撃者は、単に、レーザーカッター顕微鏡を用いて単一ビットをセットする。攻撃者が前の値を知らないとしても、新しい値がわかる。チップが動作し続けるならば、そのビットの元の状態は、新しい状態と同じであるはずである。チップが動作しなくなった場合、そのビットの元の状態は、現在の状態の論理否定ＮＯＴである。攻撃者は、鍵の各ビットに対してこの攻撃を実行し、最大でｎチップを使用してｎビット鍵を獲得することができる（新しいビットが古いビットと一致するならば、新しいビットは次のビットを決定するために必要ではない）。
【１０８４】
テスト回路攻撃
殆どの回路は、製造上の欠陥を検査するために特に設計されたテスト回路を備えている。これは、ＢＩＳＴ（ビルト・イン・セルフ・テスト）とスキャンパスとを含む。非常に頻繁に、スキャンパス及びテスト回路は、内蔵された全てのラッチへのアクセス及びリードアウト機構を含む。一部のケースでは、テスト回路は特定のレジスタの内容に関する情報を与えるために使用される可能性がある。テスト回路は、しばしば、チップが全ての製造上のテストに合格すると、一部のケースではチップ内の特定の配線を切ることによって、無効状態にされる。しかし、やる気のある攻撃者は、テスト回路を再接続して、動作可能状態にし得る。
【１０８５】
残留メモリ
値は、電源が取り外された後、長期間ＲＡＭに残存するが、不揮発性とみなされるまで長期間残存することはない。攻撃者は、機密情報がＲＡＭ（例えば、作業用レジスタ）へ移された後、電源を取り外し、ＲＡＭから値を読み出そうとすることが可能である。この攻撃は、通常のＲＡＭチップを有するセキュリティシステムに対して最も有効である。典型的な例として、セキュリティシステムは、コンピュータケースが開けられたときにトリガーされる自動電源遮断機能付きで設計されていた。攻撃者は、単にケースを開け、ＲＡＭチップを取り外し、メモリ残留を利用して鍵を取り出せばよかった。
【１０８６】
チップ窃盗攻撃
認証チップの耐用期間に多数のステージが存在する場合、これらのステージの各々は、チップが盗み取られた場合のセキュリティ用の派生問題の観点で調べる必要がある。例えば、情報が複数のステージでチップにプログラミングされる場合、ステージ間でチップを窃盗したならば、攻撃者は鍵情報を入手できるか、又は攻撃のための労力が軽減される可能性がある。同様に、チップが、製造直後であり、プログラミングの前に盗み取られた場合、攻撃者に論理的利益又は物理的利益があるだろうか？
必要条件
消耗品を認証する問題に対する従来のソリューションは、典型的に、物理的なパッケージングについての特許に依存している。しかし、これは、家庭での詰め替え作業や産業財産権の保護の弱い国における複製品製造を止められない。その結果、より高レベルの保護が必要である。したがって、認証メカニズムは、システムが消耗品を安全かつ容易に認証できるようにする認証チップ５３内に構築される。ここでは、消耗品を認証するシステムだけに限定すると（システムを認証する消耗品については考えない）、次の２レベルの保護を考えることができる：
プレゼンスオンリー認証
この場合、認証チップが存在することだけがテストされる。認証チップは、最プログラミングすることなく、別の消耗品で再使用することができる；
消耗品ライフタイム認証
この場合、認証チップの存在がテストされるだけではなく、認証チップ５３は、消耗品の耐用期間に限り持続しなければならない。チップを再使用する場合、チップは、完全に消去され、再プログラミングされなければならない。これらの二つの保護レベルは、異なる必要条件を取り扱う。ここでは、主に、大量生産消耗品の複製品を防止するため、消耗品ライフタイム認証に関心がある。このケースでは、各チップは、認証対象である消耗品に関するセキュア状態情報を保持しなければならない。尚、消耗品ライフタイム認証チップは、プレゼンスオンリー認証チップを必要とするあらゆる状況で使用できることに注意する必要がある。認証の必要条件、データ記憶完全性の必要条件、及び製造の必要条件は、別々に検討すべきである。以下のセクションは各々の必要条件を簡単に説明する。
【１０８７】
認証
プレゼンスオンリー認証と消耗品ライフタイム認証の両方に対する認証必要条件は、システムが消耗品を認証するケースに限定される。プレゼンスオンリー認証の場合、認証チップが物理的に存在することが保証されなければならない。消耗品ライフタイム認証の場合、状態データが実際に認証チップに由来すること、及び状態データが途中で改ざんされていないこと、が保証される必要がある。これらの問題は切り離すことができず、改ざんされたデータは新しい送信元からのものであり、送信元を判定できない場合、改ざんの問題を解決できない。機密性があり、セキュリティ専門家によって精査されていない自家製のセキュリティ法に基づく認証方法を提供するだけでは不十分である。したがって、主要な必要条件は、専門家の精査に耐えた手段による認証を提供することである。認証チップ５３によって使用される認証スキームは、論理的手段による打破に抵抗できなければならない。論理的タイプの攻撃は費用が掛かり、次の三つの事柄：
認証プロセスを完全に回避する；
あらゆる質問に回答できるように、力ずく又は推論によって秘密鍵を取得する；
鍵を用いることなく各質問に正しい回答を与えるため、認証用の質問及び回答の性質を十分に検出する；
のうちの一つを実行しようとする。
【１０８８】
データ記憶完全性
認証プロトコルは、通信されるメッセージ中のデータ完全性の保証に対押しているが、データ記憶完全性も必要である。次の２種類のデータ：
秘密鍵のような認証データ；
シリアル番号及びメディア残量等の消耗品状態データ；
を認証チップ内に記憶しなければならない。
【１０８９】
これらの二つのデータタイプのアクセス必要条件は全く異なる。したがって、認証チップ５３は、各タイプの完全性必要条件を考慮する記憶／アクセス制御メカニズムを必要とする。
【１０９０】
認証データ
認証データは機密保持されなければならない。認証データは、チップの耐用期間の製造／プログラミングステージの間にチップに記憶される必要があるが、それ以降、チップから取り出されることは許可されるべきではない。認証データは、不揮発性メモリから読み出されることに対抗できなければならない。認証スキームは鍵が推論によって取得できないことを保証する役目があり、製造プロセスは鍵が物理的手段によって取得できないことを保証する役目がある。認証データ記憶エリアのサイズは、必要な鍵、及び認証プロトコルによって義務づけられるような秘密情報を保持するために十分な大きさでなければならない。
【１０９１】
消耗品状態データ
各認証チップ５３は、消耗品状態データのうちの２５６ビット（３２バイト）を記憶できる。消耗品状態データは以下のタイプに分類される。アプリケーションに依存して、以下のタイプのデータ項目の各々の数は異なる。単一のデータ項目に対する最大数は３２ビットであると仮定する：
リードオンリー；
リードライト；
デクリメントオンリー。
【１０９２】
リードオンリーデータは、チップの耐用期間の製造／プログラミングステージの間にチップに保存できなければならないが、それ以降、変更を許されるべきではない。リードオンリーデータの例は、消耗品バッチ番号及びシリアル番号である。
【１０９３】
リードライトデータは、変更可能な状態情報であり、例えば、特定の消耗品が使用された最後の時間である。リードライトデータ項目は、消耗品の耐用期間中、無制限の回数で読み書きをすることができる。それらは、消耗品に関するあらゆる状態情報を記憶するため使用できる。このデータに対する唯一の必要条件は、不揮発性メモリに保持されるべきである、ということである。攻撃者はシステムへのアクセス権を獲得し得るので（リードライトデータへの書き込みが可能であり）、攻撃者はこのタイプのデータフィールドを変更する可能性がある。このデータタイプは秘密情報のために使用されるべきではなく、不確かであると考えるべきである。
【１０９４】
デクリメントオンリーデータは、消耗品リソースの利用可能度をカウントダウンするため使用される。例えば、コピー機のトナーカートリッジは、デクリメントオンリーデータ項目としてトナー残量を記憶する。カラープリンタ用のインクカートリッジは、各インク色の量をデクリメントオンリーデータ項目として記憶し、３個（シアン、マゼンタ及びイエローの各々に１個ずつ）、又は５から６個のデクリメントオンリーデータ項目を必要とする。この種のデータ項目の必要条件は、一旦、製造／プログラミングステージで初期値を用いてプログラミングされると、値を減少させることだけが可能である、ということである。それは、最小値に達すると、それ以上は減少し得ない。デクリメントオンリーデータ項目は、消耗品ライフタイム認証だけで必要になる。
【１０９５】
製造
認証チップ５３は、理想的には、低価格消耗品の認証メカニズムとして組み込むことができるように低製造コストであるべきである。認証チップ５３は、フラッシュのような標準的な製造プロセスを使用すべきである。これは：
製造場所の非常に広範囲の選択を可能にさせること；
明確であり、且つ正常に動作するテクノロジーを使用すること；
コストを低減すること；
が必要である。
【１０９６】
使用される認証スキームとは無関係に、チップの認証部の回路は物理的攻撃に対抗できなければならない。物理的な攻撃は、以下の４つの主要な形で現れるが、攻撃の形態は変化し得る：
認証チップを完全に回避する；
動作中にチップを物理的に検査する（破壊的及び非破壊的）；
チップを物理的に分解する；
チップを物理的に改変する。
【１０９７】
理想的には、チップは米国から持ち出せるべきであるので、認証チップ５３をセキュア暗号化装置として使用可能であってはならない。これは優先度の低い必要条件である。なぜならば、他の国にも認証チップを製造し得る多数の企業が存在するからである。いずれにせよ、米国からの国外持ち出し規制は変わり得る。
【１０９８】
認証
消耗品を認証する問題に対する従来のソリューションは、典型的に、物理的なパッケージングについての特許に依存している。しかし、これは、家庭での詰め替え作業や産業財産権の保護の弱い国における複製品製造を止められない。したがって、より高レベルの保護が必要である。機密性があり、セキュリティ専門家によって精査されていない自家製のセキュリティ法に基づく認証方法を提供するだけでは不十分である。ネットスケープの最初の独自に開発したシステム、及び携帯電話で私用されるＧＳＭ不正防止ネットワークは、設計秘密主義によって生じたセキュリティの脆弱性である。両方のセキュリティシステムは、それらの企業がオープン設計プロセスに従っていたならば検出できたであろう従来の手段によって破られた。ソリューションは、専門家の精査に耐えた手段による認証を提供することである。多数のプロトコルを消耗品認証のために使用することが可能である。ここでは、公表されたセキュリティ方法だけを使用し、この新しい方法によって知られた動作を使用する。全てのプロトコルにおいて、スキームの安全性は、秘密アルゴリズムではなく、秘密鍵に依拠する。プロトコルの全ては、時変性チャレンジ（即ち、毎回異なるチャレンジ）に依存し、レスポンスはチャレンジと秘密情報に依存する。チャレンジは乱数を含むので、観測者は後続のアイデンティフィケーションに関する有益な情報を集めることができない。プレゼンスオンリー認証と消耗品ライフタイム認証の各々のために二つのプロトコルが提案される。プロトコルは認証プロセスのために必要な認証チップの個数が異なるが、全てのケースで、システムは消耗品を認証する。ある種のプロトコルは、１個又は２個のチップで動作するが、他のプロトコルは２個のチップだけで動作する。使用される認証チップが１個であるか２個であるかとは無関係に、システムは認証判定を行う役割を担う。
【１０９９】
シングルチップ認証
唯一の認証チップ５３が認証プロトコルのために使用される場合、単一チップ（チップＡと呼ぶ）は、システム（システムと呼ぶ）に対し、チップＡが真正であることを伝える責任がある。プロトコルの開始時に、システムは、チップＡの真正性を確信できない。システムは、チップＡとチャレンジ−レスポンスプロトコルを実行し、チップの真正性を判定する。全てのプロトコルにおいて、消耗品の真正性は、チップの真正性に直接的に基づいている。即ち、チップＡが真正であるとみなされるならば、消耗品も真正であるとみなされる。データフローは図１６７に示されている。シングルチップ認証プロトコルの場合、システムは、ソフトウェア、ハードウェア、又は両者の組み合わせのどれでもよい。重要なことは、システムは安全ではなく、攻撃者がＲＯＭを調べることによって、又は回路を調べることによって容易にリバースエンジニアリングをすることができる、ということである。システムは、それ自体で安全になるようには特に設計されていない。
【１１００】
ダブルチップ認証
別のプロトコルでは、２個の認証チップが図１６８に示されるように必要になる。単一のチップ（チップＡ）は、システム（システムと呼ぶ）に対し、チップＡが真正であることを伝える責任がある。認証プロセスの一部として、システムは、信頼できる認証チップ（チップＴと呼ぶ）を利用する。ダブルチップ認証プロトコルでは、システムは、ソフトウェア、ハードウェア、又は両者の組み合わせのどれでもよい。しかし、チップＴは物理的な認証チップでなければならない。あるプロトコルでは、チップＴ及びチップＡは同じ内部構造を備え、他のプロトコルでは、チップＴ及びチップＡは異なる内部構造を備えている。
【１１０１】
プレゼンスオンリー認証（不確かな状態データ）
このレベルの消耗品認証の場合、認証チップ５３の存在を確認することだけに関心がある。認証チップは状態情報を格納し得るが、その状態情報の伝送は安全であるとは考えられない。二つのプロトコルが提案される。プロトコル１は２個の認証チップが必要であり、プロトコル２は１個又は２個の認証チップを使用して実現可能である。
【１１０２】
プロトコル１
プロトコル１はダブルチッププロトコルである（２個の認証チップが必要になる）。各認証チップは以下の値を格納する：
Ｋ ＦＫ［Ｘ］用の鍵。秘密でなければならない；
Ｒ 現在の乱数。秘密でなくてもよいが、チップインスタンス毎に異なる初期値でシードされなければならない。Ｒａｎｄｏｍ関数の呼び出し毎に変化する。
【１１０３】
各認証チップは以下の論理関数を格納する：
Ｒａｎｄｏｍ［］ Ｒを返し、Ｒをシーケンス内で次へ進める；
Ｆ［Ｘ］ 一方向関数Ｆを秘密鍵Ｋに基づいてＸに適用した結果であるＦＫ［Ｘ］を返す。
【１１０４】
プロトコルは以下の通りである：
システムはチップＴからのＲａｎｄｏｍ［］を要求する；
チップＴはＲをシステムへ返す；
システムはチップＴ及びチップＡの両方からのＦ［Ｒ］を要求する；
チップＴはＦＫＴ［Ｒ］をシステムへ返す；
チップＡはＦＫＡ［Ｒ］をシステムへ返す；
システムは、ＦＫＴ［Ｒ］をＦＫＡ［Ｒ］と比較する。それらが一致しているならば、チップＡは有効であるとみなされる。一致しないならば、チップＡは無効であるとみなされる。
【１１０５】
データフローは図１６９に示されている。システムは、ＦＫ［Ｒ］メッセージを理解する必要がない。システムは、チップＡからの応答とチップＴからの応答が同じであることをチェックするだけでよい。したがって、システムは鍵を必要としない。プロトコル１の安全性は以下の２カ所にある：
Ｆ［Ｘ］の安全性。認証チップだけが秘密鍵を格納するので、
信頼できる認証チップ５３（チップＴ）によって生成されたＦ［Ｘ］と一致するＦ［Ｘ］をＸから生成し得るチップは真正に違いない；
全ての認証チップによって生成されたＲのドメインは大きく、非決定論的である筈である。全ての認証チップによって生成されたＲのドメインが小さいならば、複製品製造者は鍵を解読しなくてもよい。その代わりに、複製品製造者は、システムによって送信されたコードに対する純正チップからのレスポンスの全てが記録されたＲＯＭを自分のチップに組み込むことができる。Ｒａｎｄｏｍ関数は厳密に認証チップ内に収容しなくてもよい。なぜならば、システムは、同じ乱数シーケンスを生成する可能性を秘めているからである。しかし、それは、システムの設計を簡単化し、乱数生成器の安全性が認証チップを使用する全ての実装形態に対して同一であり、システム実装においてエラーが起こる可能性を減少させる。
【１１０６】
プロトコル１には複数の利点がある：
Ｋは認証プロセス中に明らかにされることがない；
Ｘが与えられたとき、複製チップは、Ｋを用いないで、又は実際の認証チップへアクセスしないで、ＦＫ［Ｘ］を生成できない；
システムは、特に、インクジェットプリンタのような低価格システムにおいて容易に設計できる。なぜならば、暗号化又は復号化がシステム自体によって要求されないからである；
広範囲の鍵付き一方向関数が存在し、対称暗号化、乱数シーケンス、及びメッセージ認証コードが含まれる；
一方向関数は必要なゲート数が少なく、非対称アルゴリズムよりも簡単に検証することができる；
鍵付き一方向関数のための安全な鍵サイズは、非対称（公開鍵）アルゴリズムの場合と同程度に大きくする必要がない；
Ｆ［Ｘ］が対称暗号化関数であるならば、最小限の１２８ビットは、適切な安全性を提供することができる。
【１１０７】
しかし、このプロトコルには問題がある：
これは選択テキスト攻撃の対象になりやすい。攻撃者は、チップを自分専用のシステムにプラグインし、選択されたＲを生成、出力を観測することができる。鍵を見つけるため、攻撃者は、特定のＦ［Ｍ］を生成するＲを探索することも可能である。なぜならば、多数の認証チップを並列にテストできるからである；
選択された一方向関数に応じて、鍵生成は複雑化し得る。よい鍵を選択する方法は、使用されるアルゴリズムに依存する。ある種の鍵は一定のアルゴリズムに対して弱い；
鍵付き一方向関数の選択自体は重要ではない。特許保護に由来するライセンスを必要とする場合もある。
【１１０８】
媒介物は、平文メッセージＭをチップＡへ渡す前に平文メッセージＭに作用することが可能であり、これは、チップＡがＭを見るまで媒介物がＭを見ない場合には好ましい。媒介物がＭを全く見ない場合にはより好ましい。
【１１０９】
Ｆが対称暗号化である場合、適切なセキュリティのために必要な鍵サイズのため、チップは米国から国外へ持ち出せない。なぜならば、チップは強い暗号化装置として使用できるからである。
【１１１０】
プロトコルが非対称暗号アルゴリズムとしてＦを用いて実現されるならば、対称の場合を上回る利点は無く、鍵をより長くする必要があり、シリコン内の暗号化アルゴリズムがより高価になる。プロトコル１は、鍵の安全性を維持するため、２個の認証チップを用いて実現しなければならない。すなわち、各システムは認証チップが必要であり、各消耗品は認証チップが必要である。
【１１１１】
プロトコル２
あるケースでは、システムは大規模の処理能力を備えている。或いは、例えば、大量に製造されたシステムの場合、チップＴをシステムに統合することは望ましい。非対称暗号アルゴリズムの使用によって、システムのチップＴ部を不確かにすることが許容される。したがって、プロトコル２は非対称暗号方式を使用する。このプロトコルの場合、各チップは以下の値を格納する：
Ｋ ＥＫ［Ｘ］及びＤＫ［Ｘ］用の鍵である。チップＡ内で秘密にされるべきである。チップＴ内で秘密にする必要がない；
Ｒ 現在の乱数。秘密でなくてもよいが、チップインスタンス毎に異なる初期値でシードされなければならない。Ｒａｎｄｏｍ関数の呼び出し毎に変化する。
【１１１２】
以下の関数が定義される：
Ｅ［Ｘ］ チップＴだけ。ＥＫ［Ｘ］を返す。但し、Ｅは非対称暗号化関数Ｅである；
Ｄ［Ｘ］ チップＡだけ。ＤＫ［Ｘ］を返す。但し、Ｄは非対称暗号化関数Ｄである；
Ｒａｎｄｏｍ［］ チップＴだけ。Ｒ｜ＥＫ［Ｒ］を返す。ＲはシードＳに基づく乱数である。乱数シーケンス内でＲを次へ進める。
【１１１３】
公開鍵ＫＴはチップＴ内にあり、一方、秘密鍵ＫＡはチップＡにある。ＫＴがチップＴにあることは、チップＴをソフトウェア又はハードウェアで実現できるという利点がある（但し、Ｒのシードはチップ又はシステム毎に異なる）。したがっって、プロトコル２は、シングルチッププロトコルとしてもダブルチッププロトコルとしても実現できる。認証のためのプロトコルは以下の通りである：
システムはチップＴのＲａｎｄｏｍ関数を呼び出す；
チップＴはＲ｜ＥＫＴ［Ｒ］をシステムへ返す；
システムはチップＡの関数Ｄを呼び出し、ＥＫＴ［Ｒ］を渡す；
チップＡは、ＤＫＡ［ＥＫＴ［Ｒ］］によって獲得されたＲを返す；
システムは、チップＡからのＲとチップＴによって生成された元のＲを比較する。それらが一致しているならば、チップＡは有効であるとみなされる。一致しないならば、チップＡは無効であるとみなされる。
【１１１４】
データフローは図１７０に示されている。プロトコル２には次の利点がある：
ＫＡ（秘密鍵）は認証プロセス中に明らかにされることがない；
ＥＫＴ［Ｘ］が与えられたとき、複製チップは、ＫＡを用いないで、又は実際のチップＡへアクセスすることなく、Ｘを生成できない；
ＫＴ≠ＫＡであるため、チップＴは、完全にソフトウェアで、不確かなハードウェアで、又はシステムの一部として実現できる。チップＡ（消耗品内）だけが安全な認証チップであることを要求される；
チップＴが物理的なチップであるならば、システムは容易に設計できる；
多数の十分に文書化され暗号解読された非対称アルゴリズムの中から、特許が開放されライセンスフリーであるソリューションを含む、インプリメンテーション用のアルゴリズムを選択することができる。
【１１１５】
しかし、プロトコル２には多数の固有の問題がある：
十分な安全性のため、各鍵は２０４８ビットにする必要がある（これに対して、プロトコル１の対称暗号方式の場合、最小値は１２８ビットである）。暗号化及び復号化アルゴリズムによって使用される関連した中間メモリは、相応に大きくなる；
鍵生成は重要である。乱数は優れた鍵ではない；
チップＴがコアとして実装された場合、チップＴを所与のシステムＡＳＩＣに連結することが難しい；
チップＴがソフトウェアとして実装された場合、システムの実装がプログラミングエラー及び厳密ではないテストに対して無防備であるだけではなく、コンパイラ及び数学的プリミティブの完全性をシステムのインプリメンテーション毎に厳密にチェックしなければならない。これは、単純に十分にテストされたチップを使用する場合よりも複雑であり、且つコスト高である；
多数の対称アルゴリズムが特に差分暗号解読（選択テキスト攻撃に基づいている）に対抗するため強化されているにもかかわらず、秘密鍵ＫＡは選択テキスト攻撃の対象になりやすい；
チップＡ及びチップＴが同じ認証チップのインスタンスである場合、各チップは、非対称暗号化及び復号化の両方の機能を備える必要がある。その結果として、各チップは、プロトコル１のために必要なチップよりも大型化し、複雑化し、高価になる；
認証チップが、コストを節約し、設計／テストの複雑さを低減するため２個のチップに分割された場合、２個のチップを依然として製造する必要があり、スケールメリットが減少する。これは、システムの消耗品に対する相対的な個数によって相殺されるが、依然として考慮することが必要である；
プロトコル２の認証チップは、米国から国外へ持ち出すことができない。なぜならば、それらは、強力な暗号化装置であるとみなされるからである。
【１１１６】
たとえ、プロトコル２用の鍵を選択するプロセスが簡単であるとしても、プロトコル２は、（鍵サイズ及び機能的実装の両方の）シリコン実装のコストが高いため、現時点では実際的ではない。したがって、プロトコル１がプレゼンスオンリー認証のためのプロトコルとして選択される。
【１１１７】
本物の認証チップを使用する複製消耗品
プロトコル１及び２は、チップＡが本物の認証チップであるかどうかをチェックするだけである。それらは、消耗品自体が有効であるかどうかを調べるためのチェックを行わない。認証に関する基本的な前提として、チップＡが有効であるならば、消耗品は有効である。したがって、複製品製造者は本物の認証チップを複製消耗品に挿入することが可能である。以下の二つのケースを検討する：
状態データが認証チップに書き込まれないケースでは、チップは完全に再使用可能である。したがって、複製品製造者は、有効な消耗品を複製消耗品にリサイクルすることができる。これは、認証チップを消耗品の物理的パッケージングに融合することによって困難になるが、詰め替え作業者を止められないであろう；
状態データが認証チップに書き込まれるケースでは、チップは、新品か、部分的に使用されているか、又は完全に使い切られている。しかし、これは、複製品製造者によるピギーバック攻撃の使用を止められず、複製品製造者はピギーバックとして本物の認証チップを具備したチップを構築する。攻撃者のチップ（チップＥ）は、媒介物である。電源投入時、チップＥは、本物の認証チップ５３から固有のメモリへ全ての記憶状態値を読み込む。チップＥは、次に、システムからの要求を検査し、要求に応じて様々な動作をとる。認証要求は、本物の認証チップ５３へそのまま渡すことができ、一方、リード／ライト要求は、本物の認証チップの動作と似ているメモリによってシミュレーションされ得る。このようにして、認証チップ５３は、常に、電源投入時に新品であるかのように見える。チップＥがこれを行うことができるのは、データアクセスは認証されないからである。
【１１１８】
システムを欺いて、システムのデータアクセスが成功したと思わせるために、チップＥは、依然として本物の認証チップを必要とし、第２のケースでは、複製チップが本物のチップの他に必要になる。その結果として、プロトコル１及び２が有効になるのは、複製品製造者が本物の認証チップ５３を消耗品に埋め込むことの費用対効果がよくない場合である。消耗品をリサイクルできない、又は簡単に詰め替えできないならば、プロトコル１又はプロトコル２の使用によって十分な保護が得られる。複製動作を成功させるためには、各複製消耗品は、有効な認証チップを具備しなければならない。そのチップは、まとめて盗み取るか、又は古い消耗品から取り出さなければならない。これらの再生チップの量は（それらを再生する労力と共に）ビジネスの基盤とするためには不十分であり、セキュアデータ転送（プロトコル３及び４を参照）の保護を追加する実益はない。
【１１１９】
鍵の寿命
上記の二つのプロトコルの一般的な問題は、一旦、認証鍵が選択されると、それを変更することが容易ではない点である。ある種の状況では、鍵が危険にさらされることは問題ではないが、他の場合には、鍵を危うくすることは致命的である。例えば、車／車キーシステム／消耗品のシナリオでは、消費者は、１組の車／車キーだけを保有する。各車は異なる認証鍵を有する。その結果として、車キーの損失は個々の車を危うくするだけである。所有者がこのことを問題であると考えるならば、所有者は、車のエレクトロニクス内のシステムチップを交換することによって、新しい「車キー」を入手しなければならない。所有者の鍵は、新しい「車のシステム認証チップ」と連動するように再プログラミング／交換する必要がある。これに対して、大量消耗品市場（例えば、プリンタのインクカートリッジ）の鍵が危うくなることは、複製インクカートリッジ製造者が自分専用の認証チップを製造可能にさせる。既存のシステムに対する唯一のソリューションはシステム認証チップを更新することであり、これは、コストが掛かり、物流的に困難な課題である。いずれにしても、消費者のシステムは既に正常に機能し、既存の機器を妨害しようとする動機がない。
【１１２０】
消耗品ライフタイム認証
この消耗品認証のレベルでは、認証チップの存在を確認すること、並びに、認証チップが消耗品と同じ期間だけ確実に存続することに関心がある。認証チップが存在することを確認することに加えて、認証チップのメモリ空間の書き込み及び読み出しも同様に認証されなければならない。このセクションでは、認証チップのデータ記憶完全性は安全であると仮定し、メモリの一部はリードオンリーであり、他の一部はリード／ライトであり、その他はデクリメントオンリーである（より詳しくは、データ記憶完全性というタイトルの章を参照のこと）。二つのプロトコルが存在する。プロトコル３は２個の認証チップを必要とし、プロトコル４は１個又は２個の認証チップを使用して実現することができる。
【１１２１】
プロトコル３
このプロトコルはダブルチッププロトコルである（２個の認証チップが必要になる）。このプロトコルの場合、各認証チップは以下の値を格納する：
Ｋ１ ＦＫ１［Ｘ］を計算するための鍵。秘密にしなければならない；
Ｋ２ ＦＫ２［Ｘ］を計算するための鍵。秘密にしなければならない；
Ｒ 現在の乱数。秘密でなくてもよいが、チップインスタンス毎に異なる初期値でシードされなければならない。Ｔｅｓｔ関数によって定義されるように認証が成功する毎に変化する；
Ｍ 認証チップ５３のメモリベクトル。この空間の一部はチップ毎に異なるべきである（乱数でなくてもよい）。
【１１２２】
各認証チップは以下の論理関数を格納する：
Ｆ［Ｘ］ 内部関数専用。一方向関数Ｆを鍵Ｋ１又は鍵Ｋ２の何れかに基づいてＸに適用した結果であるＦＫ［Ｘ］を返す；
Ｒａｎｄｏｍ［］ Ｒ｜ＦＫ１［Ｒ］を返す；
Ｔｅｓｔ［Ｘ，Ｙ］ ＦＫ２［Ｒ｜Ｘ］＝Ｙであるならば、１を返しＲを進める。そうでなければ、０を返す。０を返すために要する時間は、全ての不良な入力に対して同じでなければならない；
Ｒｅａｄ［Ｘ．Ｙ］ ＦＫ１［Ｘ］＝Ｙであるならば、Ｍ｜ＦＫ２［Ｘ｜Ｍ］を返す。そうでなければ、０を返す。０を返すために要する時間は、全ての不良な入力に対して同じでなければならない；
Ｗｒｉｔｅ［Ｘ］ Ｍのうち正当に書き換え可能な部分にＸを書き込む。
【１１２３】
チップＡを認証し、チップＡのメモリＭを読み出すためには、
システムはチップＴのＲａｎｄｏｍ関数を呼び出し、
チップＴはＲ｜ＦＫ［Ｒ］を生成し、これをシステムへ返し、
システムはチップＡのＲｅａｄ関数を呼び出し、Ｒ、ＦＫ［Ｒ］を渡し、
チップＡはＭ及びＦＫ［Ｒ｜Ｍ］を返し、
システムはチップＴのＴｅｓｔ関数を呼び出し、Ｍ及びＦＫ［Ｒ｜Ｍ］を渡し、
システムはチップＴからのレスポンスをチェックする。レスポンスが１であるならば、チップＡは真正であるとみなされる。０であるならば、チップＡは無効であるとみなされる。
【１１２４】
チップＡのメモリＭへのＭｎｅｗの書き込みを認証するためには、
システムはチップＡのＷｒｉｔｅ関数を呼び出し、Ｍｎｅｗを渡し、
読み出しのための認証手続きが実行され、
チップＡが真正であり、Ｍｎｅｗ＝Ｍであるならば、書き込みは成功である。そうでなければ、書き込みは失敗した。
【１１２５】
読み出し認証のデータフローは図１７１に示されている。プロトコル３に関して最初に注意しなければならないことは、ＦＫ［Ｘ］を直接呼び出せないことである。その代わりに、ＦＫ［Ｘ］は、Ｒａｎｄｏｍ、Ｔｅｓｔ及びＲｅａｄによって間接的に呼び出される：
Ｒａｎｄｏｍ［］はＦＫ１［Ｘ］を呼び出す。Ｘは呼び出し元によって選択されない。ＸはＲａｎｄｏｍ関数によって選択される。攻撃者は、希望のＸ、ＦＫ１［Ｘ］のペアを獲得するためには、Ｒａｎｄｏｍ、Ｒｅａｄ、及びＴｅｓｔの複数回の呼び出しを使用してブルートフォース検索を実行しなければならない；
Ｔｅｓｔ［Ｘ，Ｙ］はＦＫ２［Ｘ］を呼び出す。結果をそのまま返すのではなく、結果をＹと比較し、１又は０を返す。所定のＸに対してＦＫ２［Ｒ｜Ｘ］の様々な値を試して、Ｔｅｓｔを複数回呼び出すことによってＫ２を推論しようとする試みは、Ｒが攻撃者によって選択できないブルートフォース検索まで軽減される；
Ｒｅａｄ［Ｘ，Ｙ］はＦＫ１［Ｘ］を呼び出す。Ｘ及びＦＫ１［Ｘ］は、呼び出し元によって供給されなければならないので、呼び出し元は、前もってＸ、ＦＫ１［Ｘ］ペアが分かっていなければならない；
この呼び出しは、Ｙ≠ＦＫ１［Ｘ］であるならば０を返すので、呼び出し元は、Ｋ１に対するブルートフォース攻撃のためＲｅａｄ関数を使用することができる；
Ｒｅａｄ［Ｘ，Ｙ］はＦＫ２［Ｘ｜Ｍ］を呼び出す。Ｘは呼び出し元によって供給されるが、ＸはＲａｎｄｏｍ関数によって既に与えられた値だけをとり得る（なぜならば、Ｘ及びＹはＫ１によって検証されている）。このため、選択テキスト攻撃は、最初に、Ｒａｎｄｏｍからペアを収集しなければならない（事実上、ブルートフォース攻撃である）。その上、Ｍの一部だけが選択テキスト攻撃で使用される。なぜならば、Ｍの一部は一定であり（リードオンリー）、Ｍのデクリメントオンリー部分は、消耗品毎に１回ずつ使用できる。次の消耗品で、Ｍのリードオンリー部分は異なる。
【１１２６】
ＦＫ［Ｘ］が間接的に呼び出されることは、認証チップへの選択テキスト攻撃を阻止する。攻撃者は、望ましいＲが現れるまで、Ｒａｎｄｏｍ、Ｒｅａｄ、及びＴｅｓｔを複数回呼び出すことによって選択されたＲ、ＦＫ１［Ｒ］ペアしか獲得できないので、Ｋ１へのブルートフォース攻撃は、Ｋ２への制限選択テキスト攻撃を実行するために必要である。Ｋ２への選択テキスト攻撃における試みは制限されるであろう。なぜならば、テキストを完全に選択できないからであり、Ｍの一部はリードオンリーであり、依然として各認証チップに対して異なる。２番目に注意すべきことは、２個の鍵が使用されることである。小さいサイズのＭが与えられた場合、２種類の鍵Ｋ１及びＫ２は、Ｆ［Ｒ］とＦ［Ｒ｜Ｍ］の間に相関が無いことを保証するため使用される。したがって、Ｋ１は、差分攻撃からＫ２を保護するために使用される。１個のより長い鍵を使用することは不十分である。なぜならば、Ｍは２５６ビットだけであり、Ｍの一部分しか消耗品の耐用期間中に変化しないからである。そうでなければ、攻撃者は、ある種の未発見の技術によって、限定されたＭの変化が、特定のＲのビット組み合わせに与える影響を判定し、ＦＫ１［Ｘ］に基づいてＦＫ２［Ｘ｜Ｍ］を計算できる可能性がある。付加的な事前計算として、チップＡのＲａｎｄｏｍ関数及びＴｅｓｔ関数は無効にされるべきであり、その結果、Ｒ、ＦＫ［Ｒ］のペアを生成するため、攻撃者は、チップＴのインスタンスを使用する必要があり、その各々はチップＡよりも高価である（なぜならば、システムは各チップＴに対して獲得されなければならないからである）。同様に、Ｒａｎｄｏｍ、Ｒｅａｄ及びＴｅｓｔの呼び出しの間の遅れは最小限にされるべきであり、その結果として、攻撃者はこれらの関数を高速で呼び出すことができない。このようにして、各チップは、ある時間に、特定の個数のＸ、ＦＫ［Ｘ］のペアだけを明らかにする。プロトコル３の唯一の特有のタイミング必要条件は、返り値０（不良な入力を示す）が、誤りが入力のどこに存在するかとは無関係に、同じ時間で生成されるべきである、ということである。したがって、攻撃者は、入力値に関する誤りが何であるかに関して学習できない。これは、ＲＤ関数とＴＳＴ関数の両方に対しても成り立つ。
【１１２７】
プロトコル３に関して注意すべき別の事項は、チップＡからのデータ読みだしにもチップＡの認証が必要になる、ということである。システムは、ＦＫ２［Ｒ｜Ｍ］が正しく返された場合に、メモリ（Ｍ）の内容はチップＡが主張している内容そのものであることを確認できる。複製チップは、Ｍがある値であると偽る（例えば、消耗品が一杯詰まっているように見せかける）かもしれないが、複製チップは、システムによって渡された任意のＲに対して、ＦＫ２［Ｒ｜Ｍ］を返すことができない。このように、事実上の署名、ＦＫ２［Ｒ｜Ｍ］は、認証チップＡがＭを送信したことだけではなく、ＭがチップＡとシステムの間で改ざんされていないことをシステムに保証する。最後に、上述のＷｒｉｔｅ関数は書き込みを認証しない。書き込みを認証するため、システムは、各書き込みの後に読み出しを実行しなければならない。プロトコル３には幾つかの基本的な利点がある：
Ｋ１及びＫ２は認証プロセス中に明らかにされることがない；
Ｘが与えられたとき、複製チップは、Ｋを用いないで、又は本物のチップＡへアクセスすることなく、ＦＫ２［Ｘ｜Ｍ］を生成できない；
システム自体によって暗号化又は復号化が必要ではないため、特に、インクジェットプリンタのような低コストシステムにおいて、システムは簡単に設計できる；
対称暗号方式、乱数シーケンス、及びメッセージ認証コードを含む広範囲の鍵ベースの一方向関数が存在する；
鍵付き一方向関数は必要なゲート数が少なく、非対称アルゴリズムよりも簡単に検証することができる。）；
鍵付き一方向関数のための安全な鍵サイズは、非対称（公開鍵）アルゴリズムの場合と同程度に大きくする必要がない。Ｆ［Ｘ］が対称暗号化関数であるならば、最小限の１２８ビットで適切な安全性を提供することができる。
【１１２８】
したがって、プロトコル３の場合、チップＡを認証する唯一の方法は、チップＡのメモリの内容を読み出すことである。このプロトコルの安全性は、基本となるＦＫ［Ｘ］スキームと、すべてのシステムの組に亘るＲのドメインと、に依存する。ＦＫ［Ｘ］は鍵付き一方向関数であればよいが、それを非対称暗号として実現することに利点はない。鍵はより長くすることが必要であり、暗号化アルゴリズムはシリコン内でより高価になる。このため、非対称アルゴリズムと共に使用するための第２のプロトコル、即ち、プロトコル４が生じる。プロトコル３は、鍵を秘密のまま保つために２個の認証チップで実現する必要がある。即ち、各システムは認証チップを必要とし、各消耗品は認証チップを必要とする。
【１１２９】
プロトコル４
あるケースでは、システムは大規模の処理能力を備えている。或いは、例えば、大量に製造されたシステムの場合、チップＴをシステムに統合することは望ましい。非対称暗号アルゴリズムの使用によって、システムのチップＴ部を不確かにすることが許容される。したがって、プロトコル４は非対称暗号方式を使用する。このプロトコルの場合、各チップは以下の値を格納する：
Ｋ ＥＫ［Ｘ］及びＤＫ［Ｘ］用の鍵である。チップＡ内で秘密にされるべきである。チップＴ内で秘密にする必要がない；
Ｒ 現在の乱数。秘密でなくてもよいが、チップインスタンス毎に異なる初期値でシードされなければならない。Ｔｅｓｔ関数によって定義されるように認証が成功する毎に変化する；
Ｍ 認証チップ５３のメモリベクトル。この空間の一部はチップ毎に異なるべきである（乱数でなくてもよい）。
【１１３０】
Ｒｅａｄ関数で何かを検証する意味はない。なぜならば、誰でも公開鍵を使用して暗号化できるからである。したがって、以下の関数が定義される：
Ｅ［Ｘ］ 内部関数だけ。ＥＫ［Ｘ］を返す。但し、Ｅは非対称暗号化関数Ｅである；
Ｄ［Ｘ］ 内部関数だけ。ＤＫ［Ｘ］を返す。但し、Ｄは非対称暗号化関数Ｄである；
Ｒａｎｄｏｍ［］ チップＴだけ。ＥＫ［Ｒ］を返す；
Ｔｅｓｔ［Ｘ，Ｙ］ ＤＫ［Ｒ｜Ｘ］＝Ｙであるならば、１を返しＲを進める。そうでなければ、０を返す。０を返すために要する時間は、全ての不良な入力に対して同じでなければならない；
Ｒｅａｄ［Ｘ］ Ｍ｜ＥＫ［Ｒ｜Ｍ］を返す。但し、Ｒ＝ＤＫ［Ｘ］である（入力をテストしない）；
Ｗｒｉｔｅ［Ｘ］ Ｍのうち正当に書き換え可能な部分にＸを書き込む。
【１１３１】
公開鍵ＫＴはチップＴ内にあり、一方、秘密鍵ＫＡはチップＡにある。ＫＴがチップＴにあることは、チップＴをソフトウェア又はハードウェアで実現できるという利点がある（但し、Ｒはシステム毎に異なる乱数でシードされる）。チップＡを認証し、チップＡのメモリＭを読み出すためには、
システムはチップＴのＲａｎｄｏｍ関数を呼び出し、
チップＴはＥＫＴ［Ｒ］を生成し、これをシステムへ返し、
システムはチップＡのＲｅａｄ関数を呼び出し、ＥＫＴ［Ｒ］を渡し、
チップＡはＭ｜ＥＫＡ［Ｒ｜Ｍ］を返し、最初にＤＫＡ［ＥＫＴ［Ｒ］］によってＲを獲得し、
システムはチップＴのＴｅｓｔ関数を呼び出し、Ｍ及びＥＫＡ［Ｒ｜Ｍ］を渡し、
チップＴはＤＫＴ［ＥＫＡ［Ｒ｜Ｍ］］を計算し、それをＲ｜Ｍと比較し、
システムはチップＴからのレスポンスをチェックする。レスポンスが１であるならば、チップＡは真正であるとみなされる。０であるならば、チップＡは無効であるとみなされる。
【１１３２】
チップＡのメモリＭへのＭｎｅｗの書き込みを認証するためには、
システムはチップＡのＷｒｉｔｅ関数を呼び出し、Ｍｎｅｗを渡し、
読み出しのための認証手続きが実行され、
チップＡが真正であり、Ｍｎｅｗ＝Ｍであるならば、書き込みは成功である。そうでなければ、書き込みは失敗した。
【１１３３】
読み出し認証のデータフローは図１７２に示されている。有効なチップＡだけにＲの値がわかる。なぜならば、Ｒは認証関数に渡されないからである（それは暗号化された値として渡される）。ＲはＥ［Ｒ］を復号化することによって獲得しなければならず、これは、秘密鍵ＫＡを使用することによってのみ行える。Ｒが獲得されると、ＲはＭに付加され、結果が再符号化される。チップＴは、復号化された形式のＥＫＡ［Ｒ｜Ｍ］＝Ｒ｜Ｍを検証することができ、これにより、チップＡは有効である。ＫＴ≠ＫＡであるため、ＥＫＴ［Ｒ］≠ＥＫＡ［Ｒ］である。プロトコル４には以下の利点がある：
ＫＡ（秘密鍵）は認証プロセス中に明らかにされることがない；
ＥＫＴ［Ｘ］が与えられたとき、複製チップは、ＫＡを用いないで、又は実際のチップＡへアクセスすることなく、Ｘを生成できない；
ＫＴ≠ＫＡであるため、チップＴは、完全にソフトウェアで、不確かなハードウェアで、又はシステムの一部として実現できる。チップＡだけが安全な認証チップであることを要求される；
チップＴ及びチップＡは異なる鍵を格納するので、チップＴの激しいテストによってもＫＡに関して何も明らかにならない；
チップＴが物理的なチップであるならば、システムは容易に設計できる；
多数の十分に文書化され暗号解読された非対称アルゴリズムの中から、特許が開放されライセンスフリーであるソリューションを含む、インプリメンテーション用のアルゴリズムを選択することができる；
チップＡの要求がチップＴへ向けられるようにシステムを再配線できるとしても、ＫＴ≠ＫＡであるため、チップＴはチップＡに対して回答できない。攻撃は、認証プロトコルを回避するため、システムＲＯＭ自体へ向けられるべきであろう。
【１１３４】
しかし、プロトコル４には多数の問題がある：
全ての認証チップは、非対称暗号化及び復号化の両方の機能を収容する必要がある。その結果として、各チップは、プロトコル３のために必要なチップよりも大型化し、複雑化し、高価格化する；
十分な安全性のため、各鍵は２０４８ビットにする必要がある（これに対して、プロトコル１の対称暗号方式の場合、最小値は１２８ビットである）。暗号化及び復号化アルゴリズムによって使用される関連した中間メモリは、相応に大きくなる；
鍵生成は重要である。乱数は優れた鍵ではない；
チップＴがコアとして実装された場合、チップＴを所与のシステムＡＳＩＣに連結することが難しい；
チップＴがソフトウェアとして実装された場合、システムの実装がプログラミングエラー及び厳密ではないテストに対して無防備であるだけではなく、コンパイラ及び数学的プリミティブの完全性をシステムのインプリメンテーション毎に厳密にチェックしなければならない。これは、単純に十分にテストされたチップを使用する場合よりも複雑であり、且つコスト高である；
多数の対称アルゴリズムが特に差分暗号解読（選択テキスト攻撃に基づいている）に対抗するため強化されているにもかかわらず、秘密鍵ＫＡは選択テキスト攻撃の対象になりやすい。
【１１３５】
プロトコル４の認証チップは、米国から国外へ持ち出すことができない。なぜならば、それらは、強力な暗号化装置であるとみなされるからである。
【１１３６】
プロトコル３の場合と同様に、プロトコル４の唯一の特有のタイミング必要条件は、返り値０（不良な入力を示す）が、誤りが入力のどこに存在するかとは無関係に、同じ時間で生成されるべきである、ということである。したがって、攻撃者は、入力値に関する誤りが何であるかに関して学習できない。これは、ＲＤ関数とＴＳＴ関数の両方に対しても成り立つ。
【１１３７】
ＴＳＴ呼び出しの変化
２個の認証チップが使用される場合、理論的には、複製品製造者はシステム認証チップを、ＴＳＴの各呼び出しに１（成功）を返すもので置換することが可能である。システムは、多数回、間違ったハッシュ値を用いてＮ回に亘ってＴＳＴを呼び出すことによってこれをテストし、その結果が０であることを予測することができる。ＴＳＴが最後に呼び出されたとき、チップＡからの真の戻り値が渡され、その戻り値は信頼できる。ＴＳＴを呼び出す回数が問題になる。呼び出しの回数はランダムでなければならない。これにより、複製チップ製造者は前もって回数を知り得ない。システムがクロックを持っているならば、クロックからのビットは、間違ったＴＳＴ呼び出しを何回行わなければならないかを決めるために使用される。それ以外の場合、チップＡからの戻り値を使用できる。後者のケースでは、攻撃者は、依然として、複製チップＴがチップＡからの戻り値を監視できるようにするため、システムを書き換えることができ、これにより、正しいハッシュ値を知ることができる。最悪のケースは、勿論、システムが、認証された消耗品を必要としない複製システムによって完全に置き換えられた場合であり、これは、システムを書き換え、変更する限界のケースである。このため、ＴＳＴ呼び出しの変化はオプションであり、システム、消耗品、及び変更が行われる可能性に依存する。このようなロジックをシステムに追加することは、システムがより複雑になるので、（例えば、小型デスクトッププリンタの場合）それだけの価値があるとは考えられない。これに対して、このようなロジックをカメラに追加することは、それだけの価値があると考えられる。
【１１３８】
本物の認証チップを使用する複製消耗品
消耗品部分を使用する前に消耗品残量をデクリメントすることは重要である。消耗品が先に使用されると、複製消耗品は、特別の既知アドレスへの書き込みの間に、接触の不備のふりをして、新しい消耗品のように見えるからである。この攻撃は、依然として、各消耗品に本物の認証チップが必要であることが重要である。
【１１３９】
鍵の寿命
上記の二つのプロトコルの一般的な問題は、一旦、認証鍵が選択されると、それを変更することが容易ではない点である。ある種の状況では、鍵が危険にさらされることは問題ではないが、他の場合には、鍵を危うくすることは致命的である。
【１１４０】
プロトコルの選択
プロトコル２及び４の鍵の選択が簡単であるとしても、両方のプロトコルは、（鍵サイズと機能的な実装の両面で）シリコン実装のコストが高いため、現時点では実際的ではない。したがって、選択されるプロトコルは、プロトコル１及び３である。しかし、プロトコル１及び３は、多数の同じコンポーメントを含み、
どちらも書き込み及び読み出しアクセスが必要であり、
どちらも鍵付き一方向関数の実装が必要であり、
どちらも乱数生成機能が必要である。
【１１４１】
プロトコル３は付加的な鍵（Ｋ２）が必要であると共に、ある種の最小限の状態機械の変化：
Ｒａｎｄｏｍ中にＦＫ１［Ｘ］を呼び出せるような状態機械の変更と、
ＦＫ２［Ｘ］を呼び出すＴｅｓｔ関数と、
ＦＫ１［Ｘ］及びＦＫ２［Ｘ］を呼び出すために状態機械のＲｅａｄ関数への変更と、が必要である。
【１１４２】
プロトコル３はプロトコル１に対して最小限の変更だけが必要である。プロトコル３の方が安全性が高く、プレゼンスオンリー認証（プロトコル１）が要求されるような全ての状況で使用可能である。したがって、それは特に優れたプロトコルである。プロトコル１及び３の両方が鍵付き一方向関数を使用する場合に、一方向関数の選択をより詳細に説明する。以下の表は、適用可能な選択肢の属性の概要を示している。属性は、その属性が利点であることが分かるように表されている。
【１１４３】
【表１０３】
0004309954.tif 000130
この表を検討することによって、事実上、３種類のＨＭＡＣ構造とランダムシーケンスとの間で選択されることがわかる。鍵サイズ及び鍵生成の問題は、ランダムシーケンスを除外する。多数の攻撃が既にＭＤ５に対して実行されていることを考えると、ハッシュ結果は１２８ビットに過ぎないので、ＨＭＡＣ−ＭＤ５も除外される。したがって、ＨＭＡＣ−ＳＨＡ１とＨＭＡＣ−ＲＩＰＥＭＤ１６０の間で選択を行うことになる。ＲＩＰＥＭＤ−１６０は比較的新しく、ＳＨＡ１のようには大規模に暗号解読されていない。しかし、ＳＨＡ−１はＮＳＡによって設計されているので、これは、否定的な属性として見られることもある。
【１１４４】
両者の間に大差がないのであれば、ＳＨＡ−１がＨＭＡＣ構造用に使用されるであろう。
【１１４５】
乱数生成器の選択
上述の各プロトコル（１−４）は、乱数生成器を必要とする。生成器は、全てのシステムの耐用期間に亘って生成される乱数が予測不能であるという意味で「優良」でなければならない。乱数が各システムに対して同一であるならば、攻撃者は、簡単に、本物の認証チップからの正しいレスポンスを記録し、そのレスポンスを複製チップ用のＲＯＭルックアップに収容することが可能である。このような攻撃の場合、Ｋ１又はＫ２を獲得しなくてもよい。したがって、各システムからの乱数は、予測不能であるために、即ち、非決定論的であるために十分に異なることが必要である。このようにして、Ｒ（ランダムシード）の初期値は、特定のビットが１であるか、又は０であるかに関する情報が存在しない物理的にランダムな現象から収集された物理的に生成された乱数を用いてプログラミングされるべきである。Ｒのシードは、決して、コンピュータ上で実行される乱数生成器で生成してはならない。そうでなければ、生成器アルゴリズム及びシードが解読され、攻撃者は、全てのシステムの全てのＲの組を生成し、知ることができるようになる。
【１１４６】
各認証チップのＲシードが異なることは、最初のＲはランダムであり、且つあらゆるチップで予測不能であるということである。したがって、各チップで後続のＲをどのようにして生成するかが問題になってくる。
【１１４７】
基本的なケースでは、Ｒは全く変更されない。その結果としてＲ及びＦＫ１［Ｒ］は、Ｒａｎｄｏｍ［］の各呼び出しに対して同じである。それらが同一である場合、ＦＫ１［Ｒ］は、計算されるのではなく、定数にすることができる。攻撃者は、有効なルックアップテーブルを生成するために、単一の有効認証チップを使用し、そのシステムのために特にプログラミングされた複製チップ内でそのルックアップテーブルを使用することが可能である。定数Ｒは安全ではない。
【１１４８】
Ｒを変化させる最も簡単な概念的な方法は、Ｒを１ずつインクリメントすることである。Ｒは乱数から始められるので、種々のシステムにおけるその値はランダムである可能性が高い。しかし、初期Ｒを与えると、後続の全てのＲ値は直接的に決定できる（１００００回繰り返すまでもなく、ＲはＲ０からＲ０＋１００００までの値をとる）。Ｒをインクリメントすることは、定数Ｒに対する上記の攻撃を受ける心配はない。Ｒは常に異なるので、代用される複製チップと同数の認証チップを無駄にすること無しに、特定のシステムに対するルックアップテーブルを構築する方法がない。
【１１４９】
アダーを使用するインクリメントの他に、Ｒを変化させる別の方法は、それをＬＦＳＲ（線形フィードバックシフトレジスタ）として実現することである。これは、アダーよりもシリコンが少ないという利点があり、また、ＬＦＳＲの値ドメインは順次アクセスによって決定されるので、攻撃者が特定のシステムに対するＲのレンジを直接的に決定できないという利点もある。所定の初期Ｒが生成する値を決定するためには、攻撃者は、可能性を反復し、それらを列挙しなければならない。Ｒを変化させることの利点は、ＬＦＳＲソリューションの場合にも明白である。Ｒは常に相違するので、（特定のシステムに専用の）複製チップが置換する認証チップと同数の認証チップを使い果たすこと無しに、特定のシステムに対するルックアップテーブルを構築する方法がない。したがって、Ｒを変更するために、これ以上複雑な関数を導入する利点はない。関数とは無関係に、攻撃者は、常に、シミュレーションによって値の組を、耐用期間を通じて繰り返すことが可能である。本来の安全性は、Ｒの初期ランダム性にある。Ｒを変更するためＬＦＳＲを使用することは、（アダーよりもシリコン使用量が少ない点を別にして）連続した数値レンジに限定されないという利点があるだけである（即ち、Ｒ、ＲＮを計算によって直接知ることができないので、攻撃者はＬＦＳＲをＮ回繰り返さなければならない）。
【１１５０】
したがって、認証チップ内の乱数生成器は、１６０ビットのＬＦＳＲである。最大周期ＬＦＳＲ用の１６０ビットのタップ選択（即ち、ＬＦＳＲは、０が有効な状態ではないので、全部で２１６０−１状態を循環する）によって、図１７３にしめされるようなビット１５９、４、２及び１が得られる。ＬＦＳＲは疎構造であり、多数のビットがフィードバックに使用されるわけではない（１６０ビットの中から４ビットだけが使用される）。これは、暗号アプリケーションの場合に問題であるが、非順次数生成のアプリケーションの場合には問題ではない。Ｒの１６０ビットシード値は０以外の任意の乱数をとり得る。なぜならば、０が詰められたＬＦＳＲは０の際限のないストリームを生成するからである。上述のＬＦＳＲは最大周期ＬＦＳＲであるため、全ての１６０ビットをそのままＲとして使用することができる。出力ビットｂ０から順番に数を構築する必要がない。ＴＳＴの呼び出しが成功する毎に、乱数（Ｒ）はビット１、２、４及び１５９をＸＯＲ論理演算し、その結果を上位ビットへシフトすることによって進められる。新しいＲ及び対応したＦＫ１［Ｒ］は、次のＲａｎｄｏｍへの呼び出しの際に取り出すことができる。
【１１５１】
論理的攻撃への対抗
プロトコル３は認証チップによって使用される認証スキームである。このため、論理的手段による無効化に対し耐性であるべきである。プロトコル３に対する様々なタイプの攻撃の効果を説明したが、このセクションでは、プロトコル３の観点から攻撃の各タイプを詳述する。
【１１５２】
ブルートフォース攻撃
ブルートフォース攻撃はプロトコル３を破ることが保証されている。しかし、鍵の長さは、攻撃者がブルートフォース攻撃を実行するために要する時間が非常に長いので労力に値しない、ということを意味する。攻撃者は、複製認証チップを構築するためＫ２を破るだけでよい。Ｋ１は、その他の形態の攻撃に対してＫ２を強化するために設けられているだけである。Ｋ２へのブルートフォース攻撃は、したがって、１６０ビット鍵を破らなければならない。Ｋ２に対する攻撃は、最大で２１６０回の試行が必要であり、２１５９回の試行後に鍵を検出する確率は５０％である。１兆個のプロセッサのアレイを想定すると、各々が毎秒１００万回のテストを実行すると、２１５９回（７．３×１０４７）のテストには２．３×１０２３年を要し、これは宇宙の寿命よりも長い。世界には１億台のパーソナルコンピュータしか存在しない。それらが攻撃の際に（例えば、インターネットを介して）接続されたとしても、その数は、上述の１兆個のプロセッサの攻撃よりも１００００倍少ない。更に、１兆個のプロセッサの製造がナノコンピュータの時代に可能になったとしても、鍵を獲得するために要する時間は宇宙の寿命よりも長い。
【１１５３】
推測攻撃
攻撃者が単に「鍵を推測」することは理論的に可能である。実際上、十分な時間があり、あらゆる数を試すならば、攻撃者は鍵を獲得するであろう。これは、上述のブルートフォース攻撃と同じであり、５０％の成功率を達成する前に、２１５９回の試行をしなければならない。ある人が最初の試行で単に鍵を推測する機会みは２１６０である。これに対して、ある人が米国宝くじで一等賞を獲得し、同じ日に稲光によって死亡する確率は、２２６分の１に過ぎない。ある人が最初の試行で鍵を推測する確率は、２１６０分の１であり、これは、地球上の全ての原子の中から二人が全く同一の原子を選択することに匹敵することであり、即ち、非常に可能性が低い。
【１１５４】
量子コンピュータ攻撃
Ｋ２を破るため、適切なアルゴリズムに組み込まれた１６０キュビットを含む量子コンピュータを構築することが必要である。１６０ビット鍵に対する攻撃は実施不可能である。量子コンピュータの可能性のぎりぎりの見込みは、５０年以内に５０キュビットを達成することである。５０キュビット量子コンピュータを使用したとしても、１６０ビット鍵を解読するためには、２１１０回のテストが必要になる。１億台の５０キュビット量子コンピュータのアレイを想定し、各量子コンピュータが１マイクロ秒に２５０回の鍵（現時点での最も乱暴な推定を超えている）を試すことができるとするならば、鍵を見つけるために平均で１８０億年を要する。
【１１５５】
暗号文だけの攻撃
攻撃者は、ＲＮＤ及びＲＤへの呼び出しを呼び出し監視することによってＫ１に対する暗号文だけの攻撃に出ること、及びＲＤ及びＴＳＴへの呼び出しを監視することによってＫ２に対する暗号文だけの攻撃に出ることが可能である。しかし、これらの全ての呼び出しが、平文と、平文のハッシュ形式を明らかにするならば、攻撃は、より強力な攻撃の形態、即ち、既知平文攻撃に変わるであろう。
【１１５６】
既知平文攻撃
ロジックアナライザを、システムと認証チップの間の配線に接続し、これにより、データのフローを監視することは容易である。このデータのフローは、既知平文と、平文のハッシュ形式とを生じ、Ｋ１とＫ２の両方に対する既知平文攻撃に出るため使用できる。Ｋ１に対する攻撃に出るため、ＲＮＤ及びＴＳＴへの多数の呼び出しを行うことが必要である（ＴＳＴへの呼び出しが成功し、有効チップ上のＲＤへの呼び出しが必要になる）。これは簡単であり、攻撃者は、システム認証チップと消耗品認証チップの両方をもつことが必要である。Ｋ１、Ｘ、ＨＫ１［Ｘ］の各ペアが明らかになると、Ｋ２、Ｙ、ＨＫ２［Ｘ］のペアも明らかになる。攻撃者は更なる解析のためこれらのペアを収集しなければならない。このデータを用いて意味のある攻撃に出るためには何個のペアを収集すべきであるかという問題が生じる。統計的解析のためのデータの収集を必要とする攻撃の一例は差分暗号解読である。しかし、ＳＨＡ−１又はＨＭＡＣ−ＳＨＡ１に対する攻撃は知られていないので、現時点では、収集されたデータの使い道はない。
【１１５７】
選択平文攻撃
暗号解読者が先行の調査の結果に基づいて後続の選択平文を変更する能力を備えているならば、Ｋ２は、単純な選択平文攻撃よりも強い攻撃の形式である適応的選択平文攻撃の一部の形式に無防備である。選択平文攻撃はＫ１に対しては起こり得ない。なぜならば、呼び出し元には、ＲＮＤ関数への入力として使用されるＲを変更する方法がないからである（ＲＮＤはＫ１によるハッシュ化の結果を与える唯一の関数である）。Ｒをクリアすることは、鍵をクリアする効果があるので有用ではなく、ＳＳＩコマンドは新しいＲ値を格納する前にＣＬＲを呼び出す。
【１１５８】
適応的選択平文攻撃
このタイプの攻撃はＫ１に対して起こり得ない。なぜならば、Ｋ１は選択平文攻撃を許さないからである。しかし、この攻撃の一部の形式はＫ２に対して起こる可能性があり、特に、システムと消耗品の両方は、典型的に、攻撃者が入手可能であるからである（システムは、特定の車のようなある種の場合には攻撃者からアクセスできない）。ＨＭＡＣ構造は、選択平文攻撃のあらゆる形式に対して安全性を提供する。その理由は主として、ＨＭＡＣ構造が２個の秘密入力変数（元のハッシュの結果と秘密鍵）を有するからである。このようにして、入力変数が秘密であるときに、ハッシュ関数自体の衝突を検出することは、平文ハッシュ関数の衝突を見つけることよりも難しい。その理由は、前者は、ＳＨＡ−１から入力／出力のペアを生成するため、ＳＨＡ−１への直接アクセス（プロトコル３では許可されない）を必要とするからである。攻撃者によって収集できる唯一の値は、ＨＭＡＣ［Ｒ］及びＨＭＡＣ［Ｒ｜Ｍ］である。これらは、ＳＨＡ−１ハッシュ関数自体への攻撃ではなく、収集されたデータ間の統計的差分を調べる差分暗号解読攻撃まで攻撃を低減させる。ＳＨＡ−１又はＨＭＡＣに対して知られている差分暗号解読攻撃がないとすれば、プロトコル３は適応的選択平文攻撃に対抗する。
【１１５９】
意図的なエラー攻撃
攻撃者は、ＴＳＴ関数及びＲＤ関数に対しては意図的なエラー攻撃しか出すことができない。なぜならば、これらは、鍵に対する入力を検証する唯一の関数であるからである。ＴＳＴとＲＤの両方の関数の場合、０値は、入力にエラーが見つかったときに生成され、それ以上の情報は与えられない。その上、０結果を生成するために要する時間は入力に依存せず、攻撃者はどのビットにエラーが存在するかに関する情報を得られない。したがって、意図的なエラー攻撃は効果がない。
【１１６０】
連鎖攻撃
全ての形式の連鎖攻撃は、ハッシュされるべきメッセージが数ブロックに広がっているか、又は入力変数を何らかの方法でセットできることを前提としている。プロトコル３で使用されるＨＭＡＣ−ＳＨＡ１アルゴリズムは、同時に単一の５１２ビットのブロックしかハッシュできない。その結果として、連鎖攻撃はプロトコル３に対してはあり得ない。
【１１６１】
バースデー攻撃
ＨＭＡＣに対して知られている最強の攻撃は、ハッシュ関数の衝突の頻度に基づくバースデー攻撃である。しかし、これは、ＳＨＡ−１のような必要最小限度で合理的なハッシュ関数には全く実際的でない。また、バースデー攻撃は、攻撃者が署名付きのメッセージを管理するときに限り実現可能である。プロトコル３は、デジタル署名の形式としてハッシングを使用する。システムは、有効人種チップからのレスポンスに組み込まれるべき数を送信する。認証チップはＨ［Ｒ｜Ｍ］を用いて応答しなければならないが、入力値Ｒをコントロールできないので、バースデー攻撃は実現不能である。なぜならば、メッセージは、事実上、既に生成され、署名されているからである。その代わりに、攻撃者は、同じ値にハッシュした衝突メッセージを探索しなければならない（あなたと同じ誕生日の人を見つける場合と類似している）。したがって、複製チップは、Ｒ２のハッシュと選択されたＭ２がＨ［Ｒ｜Ｍ］と同じハッシュ値を生ずるような新しい値Ｒ２を見つけようとしなければならない。しかし、システム認証チップは正しいハッシュ値を明らかにしない（ＴＳＴ関数はハッシュ値が正しいかどうかに依存して１又は０を返すだけである）。したがって、（衝突を見つけるために）正しいハッシュ値を見つける唯一の方法は、本物の認証チップに問い合わせることである。しかし、正しい値を見つけることは、Ｍを更新することを意味し、Ｍのデクリメントオンリー部分、及びＭのリードオンリー部分は変更できないので、複製消耗品は、衝突を見つけようとする前に、本物の消耗品を更新しなければならない。代案は、成功を見つけるためのＴＳＴ関数へのブルートフォース攻撃探索である（各複製消耗品はシステム消耗品へアクセスできることが必要である）。ブルートフォース検索は、上述の通り、この例では認証毎に、宇宙の寿命よりも長い時間を要する。ハッシュ値を適時に収集することは本物の消耗品をデクリメントしなければならないことを意味するので、複製消耗品がこの種の攻撃を仕掛ける意味がない。
【１１６２】
完全ルックアップテーブルによる代用
各システムの乱数シードは１６０ビットである。認証チップの最悪ケースの状況では、状態データが変更されない。その結果、一定値がＭとして戻される。しかし、複製チップは、１６０ビット値であるＦＫ２［Ｒ｜Ｍ］を返し続けなければならない。結果が１６０ビットの１６０ビットルックアップテーブルを想定すると、これは、７．３×１０４８バイト、即ち、６．６×１０３６テラバイトを必要とし、近い将来に実施可能である空間よりも間違いなく大きい。これは、勿論、ＲＯＭのための値を収集する方法さえを考慮していない。したがって、完全なルックアップテーブルは完全に実現不可能である。
【１１６３】
疎ルックアップテーブルによる代用
疎ルックアップテーブルは、認証チップへ送信されたメッセージが、実効的にランダムではなく、ある程度予測可能である場合に限り実施可能である。乱数Ｒは、自然界のランダム事象から収集された未知乱数でシードされる。複製品製造者は全てのしすてむに対して考えられるＲのレンジを知る可能性はない。なぜならば、各ビットが１であるか、又は０である確率は５０％であるからである。全てのシステムにおけるＲのレンジは未知であるため、全てのシステムで使用可能な疎ルックアップテーブルを構築することは不可能である。したがって、一般的な疎ルックアップテーブルによる攻撃は考えられない。しかし、複製品製造者は、ある特定のシステムに対するＲのレンジを知ることは可能である。これは、ＬＦＳＲに、特定のシステム認証チップのＲＮＤ関数への呼び出しからの現在の結果をロードし、将来に向けて数回繰り返すことによって実現できる。これが行われた場合、特定のＲのレンジに対するレスポンスだけを格納した特別なＲＯＭ、即ち、その特定のシステムの消耗品に専用のＲＯＭを構築できる。しかし、攻撃者は、正しい情報をＲＯＭに収容し続けなければならない。したがって、攻撃者は、有効認証チップを検出し、Ｒの値毎にそれを呼び出すことが必要である。
【１１６４】
複製認証チップが完全な消耗品をリポートし、接続のロスと新しい完全な消耗品の挿入をシミュレーションする前に１回だけ使用できる場合を想定する。複製消耗品は、完全な消耗品の認証に対するレスポンス、及び部分的に使用された消耗費にに対するレスポンスを格納しなければならない。最悪ケースで、ＲＯＭは、システムの耐用期間に亘るＲに関して、完全な消耗品及び部分的に使用された消耗品のエントリーを格納する。しかし、有効認証チップは、情報を生成するために使用され、部分的にそのプロセスで使用されるべきである。所定のシステムがｎ個のＲ値だけを生成するならば、必要な疎ルックアップＲＯＭは、Ｍに対する異なる値の個数によって乗算された１０ｎバイトである。ＲＯＭを構築するために要する時間は、ＲＤ呼び出しの間に課された時間に依存する。
【１１６５】
それにもかかわらず、複製品製造者は、詰め替えのため返品される消耗品に頼らざるを得ない。なぜならば、最初の場所にＲＯＭを構築するコストは１個の消耗品を消費するからである。このような状況における複製品製造者のビジネスは、結果的に詰め替えにある。時間及びコストは、Ｒのサイズと、ルックアップに組み込まれるべきＭの値の種類の数と、に依存する。その上、カスタム複製ＲＯＭは、一つ一つのシステムに適合する必要があり、（完全なデータ及び部分的に使用されたデータを提供するため）異なる有効認証チップがシステム毎に使用されなければならない。システム内の認証チップの使用は、したがって、この種の攻撃が複製品製造者にとって価値があるかどうかを判定するために検査しなければならない。一例は、耐用期間に約１００００プリントを有するカメラシステムである。単一のデクリメントオンリー値（残りプリント数）と、ＲＤの呼び出しの間に１秒の遅延がある場合を想定する。このようなシステムにおいて、疎テーブルは、構築に約３時間を要し、１００Ｋを消費する。ＲＯＭを構成するためには、有効認証チップを消費することが必要であるので、料金は、１個の消耗品と複製消耗品の合計よりも高くしなければならないことに注意すべきである。このようにして、１個の消耗品に対してこの機能を実行することは（複製消耗品が同等の多数の認証消耗品に何とかして収容されない限り）費用対効果がよくない。複製品製造者がシステムの所有者毎にカスタムＲＯＭを構築する労力を惜しまないのであれば、より簡単なアプローチは、認証チップを完全に無視するようにシステムを更新することであろう、したがって、この攻撃は、システム毎の攻撃として実現可能であり、所定のシステム／消耗品の組み合わせに対してこのようなことが起こる可能性を判定しなければならない。その可能性は、消耗品及び認証チップのコストと、消耗品の寿命と、消耗品の利益幅と、ＲＯＭを生成するために要する時間と、得られるＲＯＭのサイズと、顧客が同じ複製チップ等を使用する詰め替えのために複製品製造者へ戻ってくるかどうかと、に依存する。
【１１６６】
差分暗号解読
既知差分攻撃は、ＤＥＳ及びその他の同様のアルゴリズムで使用されるようなＳボックスの構造にかなり依存している。プロトコル３で使用されるＨＭＡＣ−ＳＨＡ１のような他のアルゴリズムはＳボックスを持たないが、攻撃者は、
最小差分入力及びそれに対応した出力
最小差分出力及びそれに対応した入力
の統計的解析を行うことによって差分的な攻撃を実行し得る。
【１１６７】
この性質の攻撃に出るため、入力／出力ペアの組が収集される。プロトコル３からの収集は、既知平文攻撃、又は部分適応的選択平文攻撃による。明らかに、後者が選ばれる方が有用である。一般的にハッシュ化アルゴリズムは差分解析に対抗するように設計されている。特に、ＳＨＡ−１は、特に８０語の拡張によって、強化されているので、入力における最小限の差は、（１２８ビットハッシュ関数と比較して）多数のビット位置が変わる出力を生成するであろう。その上、収集される情報は、ＨＭＡＣアルゴリズムの性質により、直接的なＳＨＡ−１入力／出力ではない。ＨＭＡＣアルゴリズムは、既知の値を、未知の値（鍵）でハッシュし、このハッシュの結果が次に別個の未知の値で再ハッシュされる。攻撃者は、秘密値も、最初のハッシュの結果もわからないので、ＳＨＡ−１からの入力及び出力は不明であり、あらゆる差分攻撃を極めて難しくさせる。以下では、認証チップからの最小限度の差の入力及び出力をより詳細に説明する。
【１１６８】
最小限度の差の入力
この場合、攻撃者は、Ｘ値、ＦＫ［Ｘ］値の組を取得し、Ｘ値が最小限度の差であり、出力ＦＫ［Ｘ］の間の統計的な差を検査する。攻撃は、最小限度のビット数だけの差があるＸ値に依存する。ＦＫ［Ｘ］値を比較するために最小限度の差のＸ値をどのようにして獲得するかが問題である。
【１１６９】
Ｋ１：Ｋ１の場合、攻撃者は、最小限度の差Ｘ、ＦＫ１［Ｘ］ペアを統計的に検査しなければならない。しかし、攻撃者は、Ｘ値を選択できず、関連したＦＫ１［Ｘ］値を獲得できない。Ｘ、ＦＫ１［Ｘ］ペアは、システム認証チップ上のＲＮＤ関数を呼び出すことによってのみ生成することができるので、攻撃者はＲＮＤを複数回呼び出し、観測された各ペアをテーブルに記録する。次に、ＦＫ１［Ｘ］の統計的解析を行うため、観測された値の中で十分に最小限度の差Ｘ値を探索しなければならない。
【１１７０】
Ｋ２：Ｋ２の場合、攻撃者は、最小限度の差Ｘ、ＦＫ２［Ｘ］ペアを統計的に検査しなければならない。Ｘ、ＦＫ２［Ｘ］ペアを生成する唯一の方法は、ＲＤ関数によるものであり、所定のＹ、ＦＫ１［Ｙ］ペアに対してＦＫ２［Ｘ］を生成し、ここで、Ｘ＝Ｙ｜Ｍである。これは、Ｙと、Ｍの変更可能部分が攻撃者によって限られた範囲で選択され得ることを意味する。選択の量は、したがって、できる限り多くされるべきである。
【１１７１】
攻撃者の選択を制限する第１の方法はＹを制限することである。なぜならば、ＲＤはフォーマットＹ、ＦＫ１［Ｙ］の入力を要求するからである。有効なペアはＲＮＤ関数から容易に獲得できるが、それは、ＲＮＤの選択によるペアである。攻撃者は、ＲＮＤから適切なペアを獲得した場合に限り、又はＫ１を知っている場合に限り、固有のＹを提供することが可能である。ＲＮＤから適切なペアを獲得するためには、ブルースフォース探索が必要になる。Ｋ１を知ることは、ＲＮＤ関数から獲得されたペアへの暗号解読を実行することによってのみ、即ち、事実上の既知テキスト攻撃によってのみ論理的に実現可能である。ＲＮＤは１秒当たりに呼び出せる回数は決まっているが、Ｋ１はシステムのチップで共通である。したがって、既知ペアは並列に生成できる。攻撃者の選択を制限する第２の方法は、Ｍを制限すること、又は少なくとも攻撃者のＭ選択能力を制限することである。Ｍの制限は、Ｍの一部をリードオンリーにさせ、認証チップ毎に相違させ、Ｍの他の部分をデクリメントオンリーにすることで実現される。Ｍのリードオンリー部分は、理想的には、認証チップ毎に異なるべきであるので、シリアル番号、バッチ番号、又は乱数のような情報でもよい。Ｍのデクリメントオンリー部分は、攻撃者が異なるＭを試すとき、その回数だけＭのその部分だけをデクリメントすることができ、Ｍのデクリメントオンリー部分が０まで低下した後、その部分は再度変更し得ない、ということを意味する。新しい認証チップ５３を獲得すると、新しいＭを与えるが、リードオンリー部分は、前の認証チップのリードオンリー部分とは異なり、したがって、攻撃者のＭを選択する能力が更に低下する。その結果として、攻撃者は、Ｙ及びＭに対する値を選択するチャンスが少ししか高めることができない。
【１１７２】
最小限度の差の出力
この場合、攻撃者は、Ｘ値、ＦＫ［Ｘ］値の組を取得し、ＦＫ［Ｘ］値が最小限度の差を表し、Ｘ値の間の統計的な差を検査する。攻撃は、最小限度のビット数だけの差があるＦＫ［Ｘ］値に依存する。Ｋ１とＫ２の両方に対し、攻撃者は所与のＦＫ［Ｘ］に対するＸ値を生成する方法がない。そうするためには、Ｆは一方向関数であるという事実に違反するであろう。その結果として、攻撃者がこの性質をもつ攻撃を組み込む唯一の方法は、全ての観測されたＸ、ＦＫ［Ｘ］ペアをテーブルに記録することである。検索は、Ｘ値の統計的解析を行うため十分に最小限度の差ＦＫ［Ｘ］値を見つけるため観測値の中で行われる。これが（Ｍに関する制限及びＲの選択に関する制限のために非常に限定されている）最小限度の差の入力攻撃よりも多くの作業を必要とするならば、この攻撃は無益である。
【１１７３】
メッセージ置換攻撃
この種の攻撃を実行するためには、複製物製造者は本物の認証チップ５３を格納する必要があるが、それは減少しないので、事実上、再使用可能である。複製認証チップは、メッセージを盗み取り、それを自分のメッセージで置き換える。しかし、この攻撃は攻撃者にとって成功しない。複製認証チップは、ＷＲコマンドを本物の認証チップへ渡さないように選択するかもしれない。しかし、後続のＲＤコマンドは（ＷＲが成功したかのうよう）正しいレスポンスを戻さなければならない。正しいレスポンスを返すためには、特定のＲ及びＭについてのハッシュ値がわかっていなければならない。バースデー攻撃のセクションで説明したように、攻撃者は、本物のチップ内のＭを実際に更新しなければハッシュ値を決定できないが、攻撃者はこれを行うことを望まない。システムによって送信されたＲを変更することさえ役に立たない。なぜならば、システム認証チップは引き続くＴＳＴの間にＲをマッチさせなければならないからである。したがって、メッセージ置換攻撃は成功しない。これは、システムが消耗品を使用する前に消耗品残量を更新する場合に限り成り立つ。
【１１７４】
鍵生成器のリバースエンジニアリング
疑似乱数生成器が鍵を生成するため使用される場合、複製品製造者は、生成器プログラムを取得するか、又は使用されたランダムシードを推測する可能性がある。これは、ネットスケープのセキュリティプログラムが最初に破られたときの方法である。
【１１７５】
認証全体の回避
プロトコル３は、システムが消耗品の使用前に消耗品状態データを更新し、（書き込みを認証するため）全ての書き込みの後に読み出しを続けることを要求する。このように、消耗品の使用毎に認証を要求する。システムがこれらの二つの簡単なルールに固執するならば、複製品製造者は（疎ＲＯＭルックアップのような）上述の方法により認証をシミュレーションしなければならない。
【１１７６】
認証チップの再使用
上述のように、プロトコル３は、システムが消耗品の使用前に消耗品状態データを更新し、（書き込みを認証するため）全ての書き込みの後に読み出しを続けることを要求する。このように、消耗品の使用毎に認証を要求する。消耗品が使い切られた場合、その認証チップの適切な状態データ値は０まで減少している。したがって、チップは別の消耗品で使用できない。このことが成り立つのは、デクリメントオンリーデータ項目を保持する認証チップの場合だけであることに注意する必要がある。使用される毎にデクリメントさせられる状態データが無い場合、チップの再使用を阻止するものはない。これは、プレゼンスオンリー認証と消耗品ライフタイム認証との間の基本的な差異である。プロトコル３はその両方を可能にさせる。結論として、消耗品がシステムによって使用されるデクリメントオンリーデータ項目を備えている場合、認証チップは、秘密鍵を知っている有効なプログラミングステーションによって完全に再プログラミングされない限り、再使用不能である。
【１１７７】
コスト節約のため認証を省略する経営上の判断
外部攻撃には限られないが、コストを節約するため将来のシステムでは認証を省略する判断は、様々なマーケットに種々の影響を与えるであろう。大量生産消耗品の場合、販売開始後に認証を導入することは極めて困難であるということに留意しなければならない。なぜならば、認証された消耗品を要求するシステムは、流通中の旧式の消耗品と連携しないからである。同様に、ある段階で認証を打ち切ることも非現実的である。なぜならば、旧式のシステムは、新しい認証されていない消耗品と連携しないからである。第２のケースでは、旧式のシステムは、システム認証チップを、同じプログラミングインタフェースを具備しているが、そのＴＳＴ関数が常に成功する単純なチップで置換することによって、個別に改造することが可能である。勿論、そのシステムは、常に成功するＴＳＴ関数をテストし、停止するようにプログラミングしてもよい。車／車キー、又は扉／扉の鍵、又はその他の類似した状況のような特殊化したペアの場合、将来のシステムで認証を省くことは重要ではなく影響もない。なぜならば、消費者は、システムと消耗品認証チップの組全体を同時に購入しているからである。
【１１７８】
強盗／賄賂攻撃
この形態の攻撃は、以下の二つの環境の何れかでしか成功しない：
Ｋ１、Ｋ２、及びＲはチッププログラマによって既に記録されているか、又は
攻撃者は、将来のＫ１、Ｋ２、及びＲの値を強制的に記録させることができる。
【１１７９】
プログラミングステーションの外部の人間又はコンピュータシステムが鍵を知らないとき、暴力や賄賂をもってしてもそれらを明らかにできない。この種の攻撃に対する安全性のレベルは、究極的に、システム／消耗品所有者が望ましいサービスのレベルに応じて行う判断である。例えば、自動車会社は、製造した全てのキーの記録を保存しようとするので、その車のため新しいキーの作成を要求することができる。しかし、これは、キーデータベースの全体が危険にさらされる可能性があり、攻撃者は製造者の既存の車に対するキーを作成できるようになる。これは、攻撃者が新しい車キーを作成することを可能にさせない。勿論、キーデータベース自体は、別の鍵で暗号化され、キーデータベースにアクセスするためには、一定の人数の人のそれぞれの鍵部分を一つに組み合わせることが必要である。特定の車にどのキーが使用されているかについての記録が保存されていないならば、キーを紛失した場合に補助キーを作成する方法はない。この場合、所有者は自分の車の認証チップと自分の車キーの全てを交換しなければないであろう。これは、必ずしも困った状況ではない。これに対して、プリンタのインクカートリッジのような消耗品の場合、一つの鍵の組み合わせが全てのシステム及び全ての消耗品に対して使用される。勿論、鍵のバックアップが保存されていないならば、誰もその鍵がわからず、攻撃はあり得ない。しかし、バックアップの無い状況は、インクカートリッジのような消耗品の場合に望ましくない。なぜならば、鍵が失われた場合、それ以上消耗品を製造できないからである。したがって、製造者は鍵情報のバックアップを幾つかの部分に保存すべきであり、何人かの人は、鍵全体の情報を明らかにするため、それぞれの部分を一つに結合することが必要である。これは、チッププログラミングステーションに再ロードしなければならない場合に要求される。いずれにしても、これらの攻撃はプロトコル３自体に対する攻撃ではない。なぜならば、人が認証プロセスに関与していないからである。そのかわりに、これは、チップのプログラミングステージに対する攻撃である。
【１１８０】
ＨＭＡＣ−ＳＨＡ１
認証のためのメカニズムは、ＨＭＡＣ−ＳＨＡ１アルゴリズムであり、
ＨＭＡＣ−ＳＨＡ１（Ｒ１，Ｋ１）又は
ＨＭＡＣ−ＳＨＡ１（Ｒ｜Ｍ，Ｋ２）
の一方に従って動作する。
【１１８１】
次に、ＨＭＡＣ−ＳＨＡ１アルゴリズムをここまでの説明よりも詳しく検討し、本来の定義よりもメモリリソース必要量が少なくなるアルゴリズムの最適化を説明する。
【１１８２】
ＨＭＡＣ
ＨＭＡＣアルゴリズムは、以下の定義を前提として進む：
Ｈ＝ハッシュ関数（例えば、ＭＤ５又はＳＨＡ−１）；
ｎ＝Ｈから出力されるビット数（例えば、ＳＨＡ−１の場合に１６０ビット、ＭＤ５の場合に１２８ビット）；
Ｍ＝ＭＡＣ関数が適用されるデータ；
Ｋ＝両当事者で共有される秘密鍵；
ｉｐａｄ＝０ｘ３６の６４回の繰り返し；
ｏｐａｄ＝０ｘ５Ｃの６４回の繰り返し。
【１１８３】
ＨＭＡＣアルゴリズムは次の通りである：
０ｘ００バイトをＫの最後に追加することによりＫを６４バイトに拡張する；
（１）で作成された６４バイト文字列をｉｐａｄでＸＯＲ論理演算する；
（２）で作成された６４バイト文字列にデータストリームＭを追加する；
（３）で生成されたストリームにＨを適用する；
（１）で作成された６４バイト文字列をｏｐａｄでＸＯＲ論理演算する；
（４）からの結果Ｈを（５）から得られた６４バイト文字列に追加する；
（６）の出力にＨを追加し、その結果を出力する。
【１１８４】
これにより、
ＨＭＡＣ［Ｍ］＝Ｈ［（ＫAｏｐａｄ）｜Ｈ［（ＫAｉｐａｄ）｜Ｍ］］
である；
ＨＭＡＣ−ＳＨＡ１アルゴリズムは、単にＨ＝ＳＨＡ−１となるＨＭＡＣである。
【１１８５】
ＳＨＡ−１
ＳＨＡ−１ハッシングアルゴリズムは以下で要約するアルゴリズムに規定される。
【１１８６】
９個の３２ビット定数が定義される。５個の定数は連鎖変数を初期化するため使用され、４個の付加的定数がある。
【１１８７】
【表１０４】
0004309954.tif 000131
最適化されていないＳＨＡ−１は、全部で２９１２ビットのデータ記憶を必要とする：
５個の３２ビット連鎖変数：Ｈ１、Ｈ２、Ｈ３、Ｈ４及びＨ５が定義される；
５個の３２ビット作業変数：Ａ、Ｂ、Ｃ、Ｄ及びＥが定義される；
１個の３２ビット一時変数：ｔが定義される；
８０個の３２ビット一時レジスタ：Ｘ０−７９が定義される。
【１１８８】
以下の関数はＳＨＡ−１のために定義される。
【１１８９】
【表１０５】
0004309954.tif 000132
ハッシングアルゴリズムは、最初に、５１２ビットの倍数になるまで入力メッセージをパディングし、連鎖変数Ｈ１−５をｈ１−５で初期化する。パッドされたメッセージは、次に、５１２ビットチャンクで処理され、出力ハッシュ値は、連鎖変数：Ｈ１｜Ｈ２｜Ｈ３｜Ｈ４｜Ｈ５の連結によって与えられる最後の１６０ビット値である。次に、ＳＨＡ−１アルゴリズムのステップを詳細に説明する。
【１１９０】
ステップ１ 処理
ＳＨＡ−１の第１ステップは、以下のように入力メッセージを５１２ビットの倍数になるまで詰め込み、連鎖変数を初期化する。
【１１９１】
【表１０６】
0004309954.tif 000133
ステップ２ 処理
詰め込まれた入力メッセージが処理可能である。５１２ビットのブロック内でメッセージを処理する。各５１２ビットのブロックは、１６×３２ビット語の形であり、ＩｎｐｕｔＷｏｒｄ０−１５として表される。
【１１９２】
【表１０７】
0004309954.tif 000134
ステップ３ 終了
詰め込まれた入力メッセージの全ての５１２ビットのブロックが処理された後、出力ハッシュ値は、Ｈ１｜Ｈ２｜Ｈ３｜Ｈ４｜Ｈ５によって与えられる最後の１６０ビット値である。
【１１９３】
ハードウェア実装用の最適化
ＳＨＡ−１のステップ２の手続は、ハードウェアのために最適化されていない。特に、８０個の一時的な３２ビットレジスタは、ハードウェア実装上の貴重なシリコンを使い果たす。このセクションは、１６個の一時レジスタだけを使用するＳＨＡ−１アルゴリズムへの最適化を説明する。シリコンの削減は、２５６０ビットから５１２ビットまでへの減少であり、２０００ビット以上の節約になる。これは、一部のアプリケーションでは重要でないが、認証チップの場合、記憶スペースはできるだけ縮小されるべきである。最適化の基礎は、元の１６ワードメッセージブロックが８０ワードメッセージブロックに拡張されるが、８０ワードはアルゴリズムの間に更新されないことにある。その上、ワードは、前の１６ワードだけに依存しているので、拡張されたワードは、１６ワードが後方参照のため保持される限り、処理中にオンザフライ方式で計算可能である。どのレジスタを使おうとしているかを追跡するために循環カウンタが必要になるが、その効果は大量の記憶量を節約することである。単一の値ｊでＸをインデックス付けするのではなく、繰り返しを通してカウントするため５ビットのカウンタを使用する。これは、５ビットレジスタを１６又は２０で初期化し、０に達するまでそれをデクリメントすることによって実現される。１６個の一時変数を８０個であるかのようにして更新するため、４個のインデックスが必要であり、各インデックスは４ビットレジスタである。４個の全てのインデックスはアルゴリズムの途中（ラップアラウンド付きで）インクリメントされる。
【１１９４】
【表１０８】
0004309954.tif 000135
ラウンド０及び１Ａの間のＮ１、Ｎ２及びＮ３のインクリメントは随意的である。ソフトウェア実装は、時間を要するので、それらをインクリメントせずに、１６巡のループの最後に、全４個のカウンタは元の値になる。ハードウェアの設計者は、制御ロジックを節約するため、全４個のカウンタを同時にインクリメントしようとする。呼び出し元が５１２ビットのＸ０−１５をロードするならば、ラウンド０は完全に省くことができる。
【１１９５】
ＨＭＡＣ−ＳＨＡ１
認証チップ実装の場合、ＨＭＡＣ−ＳＨＡ１ユニットは、二つのタイプの入力：Ｋ１を使用するＲ、及びＫ２を使用するＲ｜Ｍにハッシングを実行するだけである。入力は２個の一定長さであるため、ＨＭＡＣとＳＨＡ−１をチップ上に別個のエンティティとして設けるのではなく、それらを合成し、ハードウェアを最適化することができる。ＳＨＡ−１のステップ１におけるメッセージのパディング（１ビット、０ビットの文字列、及びメッセージの長さ）は、異なるメッセージがパディング後に同じように見えないことを保証するために必要である。２タイプのメッセージしか取り扱わないので、パディングは定数０でもよい。その上、ＳＨＡ−１アルゴリズムの最適化バージョンが使用され、１６個の３２ビットワードだけが一時記憶のために使用される。これらの１６個のレジスタは、最適化されたＨＭＡＣ−ＳＨＡ１ハードウェアによって直接ロードされる。９個の３２ビット定数ｈ−１−５及びｙ１−４は依然として必要であるが、それらが定数であることは、ハードウェア実装に有利である。ハードウェアの最適化されたＨＭＡＣ−ＳＨＡ−１は、全部で、以下の１０２４ビットのデータ記憶を必要とする：
５個の３２ビット連鎖変数：Ｈ１、Ｈ２、Ｈ３、Ｈ４及びＨ５が定義される；
５個の３２ビット作業変数：Ａ、Ｂ、Ｃ、Ｄ及びＥが定義される；
一時記憶及び最終結果のための５個の３２ビット変数：Ｂｕｆｆ１６０１−５が定義される；
１個の３２ビット一時変数：ｔが定義される；
１６個の３２ビット一時レジスタ：Ｘ０−１５が定義される。
【１１９６】
以下の２セクションは、ＨＭＡＣ−ＳＨＡ１への２タイプの呼び出しのためのステップを説明する。
【１１９７】
Ｈ［Ｒ，Ｋ１］
Ｋ１を使用してＲの鍵付きハッシュを生成するケースでは、元の入力メッセージＲは、１６０ビットの一定長さである。したがって、処理中にこのことを有利に活用することができる。ＳＨＡ−１アルゴリズムの最初の部分の間にＸ０−１５をロードするのではなく、Ｘ０−１５を直接ロードし、これにより、ＳＨＡ−１の最適化プロセスブロック（ステップ２）のラウンド０を省く。擬似コードは次のステップを行う。
【１１９８】
【表１０９】
0004309954.tif 000136
Ｈ［Ｒ｜Ｍ，Ｋ２］
Ｋ２を使用してＲ｜Ｍの鍵付きハッシュを生成するケースでは、元の入力メッセージは、４１６（２５６＋１６０）ビットの一定長さである。したがって、処理中にこのことを有利に活用することができる。ＳＨＡ−１アルゴリズムの最初の部分の間にＸ０−１５をロードするのではなく、Ｘ０−１５を直接ロードし、これにより、ＳＨＡ−１の最適化プロセスブロック（ステップ２）のラウンド０を省く。擬似コードは次のステップを行う。
【１１９９】
【表１１０】
0004309954.tif 000137
データ記憶完全性
確認証チップは、認証プロトコル３によって要求される変数を保持するため、不揮発性メモリを含む。以下の不揮発変数が定義される。
【１２００】
【表１１１】
0004309954.tif 000138
これらの変数がフラッシュメモリにあるならば、古い値を置き換えるため新しい値を書き込むことは簡単ではないことに注意する必要がある。メモリは、最初に消去され、次に、適切なビットをセットされる。これは、フラッシュメモリベースの変数を変更するため使用されるアルゴリズムに影響を与える。例えば、フラッシュメモリはシフトレジスタとして簡単に使用できない。汎用演算でフラッシュメモリ変数を更新するためには、以下のステップが必要になる：
Ｎビット値全体を汎用レジスタに読み込む；
汎用レジスタに演算を実行する；
変数に対応したフラッシュメモリを消去する；
汎用レジスタにセットされたビットに基づいてフラッシュメモリロケーションのビットをセットする。
【１２０１】
認証チップのリセットはこれらの不揮発性変数に影響を与えない。
【１２０２】
Ｍとアクセスモード
変数Ｍ［０］からＭ［１５］は、シリアル番号、バッチ番号、及び消耗品残量のような消耗品状態データを保持するため使用される。各Ｍ［ｎ］レジスタは１６ビットであり、Ｍベクトル全体で２５６ビット（３２バイト）になる。クライアントは個々のＭ［ｎ］変数を読み書きできない。その代わりに、Ｍで表されるベクトル全体が単一論理アクセスによって読み出し、又は書き込みをされる。ＭはＲＤ（リード）コマンドを使用して読み出され、ＷＲ（ライト）コマンドを使用して書き込まれる。これらのコマンドは、Ｋ１とＫ２の両方が確定し（ＳＩＷｒｉｔｔｅｎ＝１）、認証チップが消耗品の信頼できないチップ（ＩｓＴｒｕｓｔｅｄ＝０）である場合に限り成功する。Ｍは多数の異なるデータタイプを格納するが、それらは書き込み許可が異なるだけである。各データタイプは常に読み出すことができる。一旦クライアントメモリに入ると、２５６ビットはクライアントによって選択された何らかの方法で解釈できる。Ｍの２５６ビット全体は、認証の章で説明したようにセキュリティの理由から少量ずつ読み出すのではなく、同時に読み出される。様々な書き込み許可が以下の表に列挙されている。
【１２０３】
【表１１２】
0004309954.tif 000139
書き込みに要求される保護を実現するため、２ビットアクセスモード値がＭ［ｎ］毎に定められる。以下の表は、２ビットアクセスモードビットパターンの解釈を定義する。
【１２０４】
【表１１３】
0004309954.tif 000140
１６個のＭ［ｎ］レジスタのための１６組のアクセスモードビットは、単一のアクセスモードＡｃｃｅｓｓＭｏｄｅレジスタにまとめられる。３２ビットのＡｃｃｅｓｓＭｏｄｅレジスタは、以下のように、ｎ付きのＭ［ｎ］に対応する。
【１２０５】
【表１１４】
0004309954.tif 000141
各２ビット値は、上位／下位のフォーマットで記憶される。したがって、Ｍ［０−５］がアクセスモードＭＳＲであり、Ｍ［６−１５］がアクセスモードＲＯであるならば、３２ビットＡｃｃｅｓｓＭｏｄｅレジスタは、
１１−１１−１１−１１−１１−１１−１１−１１−１１−１１−０１−０１−０１−０１−０１−０１
である。
【１２０６】
ＷＲ（ライト）コマンドの実行中に、ＡｃｃｅｓｓＭｏｄｅ［ｎ］は各Ｍ［ｎ］について調べられ、新しいＭ［ｎ］値が古い方を置き換えるかどうかを判断する。ＡｃｃｅｓｓＭｏｄｅレジスタは認証チップのＳＡＭ（セットアクセスモード）コマンドを使用してセットされる。デクリメントオンリー比較は符号無しであり、負のレンジを要求するデクリメントオンリー値は、正のレンジにシフトさせなければならない。例えば、−５０から５０のレンジのデクリメントオンリーデータ項目を含む消耗品は、そのレンジが０から１００へシフトされる。システムは、そのレンジ０から１００を−５０から５０として解釈する。尚、殆どの場合に、デクリメントオンリーレンジはＮから０であり、レンジシフトは必要ない。デクリメントオンリーデータ項目の場合、データは、最上位１６ビット量から最下位１６ビット量の順にＭ［ｎ］から前方へ並べられる。最上位１６ビット（Ｍ［ｎ］に記憶されている）に対するアクセスモードは、ＭＳＲにセットされるべきである。残りのレジスタ（Ｍ［ｎ＋１］、Ｍ［ｎ＋２］等）は、それらのアクセモードがＮＭＳＲにセットされるべきである。誤ってＮＭＳＲにセットされ、関連したＭＳＲ領域が無い場合、各ＮＭＳＲ領域は、倍精度比較ではなく、独立であるとみなされる。
【１２０７】
Ｋ１
Ｋ１は認証プロトコル中にＲを変換するため使用される１６０ビット秘密鍵である。Ｋ１は、ＳＳＩ（秘密情報セット）コマンドでＫ２及びＲと共にプログラミングされる。Ｋ１は秘密にされなければならないので、クライアントはＫ１を直接読み出し得ない。Ｋ１を利用するコマンドはＲＮＤ及びＲＤである。ＲＮＤは、Ｒ、ＦＫ１［Ｒ］のペアを返し、Ｒは乱数であり、一方、ＲＤは入力としてＸ、ＦＫ２［Ｒ］のペアを要求する。Ｋ１は鍵付き一方向ハッシュ関数ＨＭＡＣ−ＳＨＡ１で使用される。したがって、Ｋ１は、物理的にランダムな現象から収集された、物理的に生成された乱数でプログラミングされるべきである。Ｋ１は、決して、コンピュータ上で実行される乱数生成器で生成してはならない。認証チップの安全性は、決定論的では無い方法で生成されたＫ１、Ｋ２及びＲに依存する。例えば、Ｋ１をセットするため、ある人は公正なコインを１６０回トスし、表を１として記録し、裏を０として記録する。Ｋ１は、ＣＬＲコマンドの実行時に自動的に０にクリアされる。それは、ＳＳＩコマンドだけによって非零値にセットすることができる。
【１２０８】
Ｋ２
Ｋ２は認証プロトコル中にＭ｜Ｒを変換するため使用される１６０ビット秘密鍵である。Ｋ２は、ＳＳＩ（秘密情報セット）コマンドでＫ１及びＲと共にプログラミングされる。Ｋ２は秘密にされなければならないので、クライアントはＫ２を直接読み出し得ない。Ｋ２を利用するコマンドはＲＤ及びＴＳＴである。ＲＤは、Ｍ、ＦＫ２［Ｍ｜Ｘ］のペアを返し、Ｘはパラメータのうちの一つとしてＲＤ関数へ渡される。ＴＳＴは入力としてＭ、ＦＫ２［Ｍ｜Ｒ］のペアを要求し、Ｒは認証チップのＲＮＤ関数から獲得された。Ｋ２は鍵付き一方向ハッシュ関数ＨＭＡＣ−ＳＨＡ１で使用される。したがって、Ｋ２は、物理的にランダムな現象から収集された、物理的に生成された乱数でプログラミングされるべきである。Ｋ２は、決して、コンピュータ上で実行される乱数生成器で生成してはならない。認証チップの安全性は、決定論的では無い方法で生成されたＫ１、Ｋ２及びＲに依存する。例えば、Ｋ２をセットするため、ある人は公正なコインを１６０回トスし、表を１として記録し、裏を０として記録する。Ｋ２は、ＣＬＲコマンドの実行時に自動的に０にクリアされる。それは、ＳＳＩコマンドだけによって非零値にセットすることができる。
【１２０９】
ＲとＩｓＴｒｕｓｔｅｄ
Ｒは、ＳＳＩ（秘密情報セット）コマンドでＫ１及びＲと共にプログラミングされる１６０ビットの乱数シードである。Ｒは秘密にする必要がない。なぜならば、それは、ＲＮＤコマンドによって自由に呼び出し元へ与えられるからである。しかし、Ｒを変更できるのは認証チップだけであり、呼び出し元によって任意の選択した値にセットできない。Ｒは、ＴＳＴコマンド中に使用され、前のＲＮＤ呼び出しからのＲが、信頼できない認証チップ（チップＡ）においてＦＫ２［Ｍ｜Ｒ］を生成するために使用されたことを保証する。ＲＮＤ及びＴＳＴの両方は、信頼されている認証チップ（チップＴ）だけで使用される。
ＩｓＴｒｕｓｔｅｄは１ビットフラグレジスタであり、認証チップが信頼されているチップ（チップＴ）であるかどうかを決定する：
ＩｓＴｒｕｓｔｅｄビットがセットされているならば、チップは信頼されているチップであるとみなされるので、クライアントはＲＮＤ関数及びＴＳＴ関数を呼び出すことができる（ＲＤ又はＷＲではない）；
ＩｓＴｒｕｓｔｅｄビットがクリアされているならば、チップは信頼されているチップであるとみなされない。したがって、ＲＮＤ関数及びＴＳＴ関数を呼び出すことができない（その代わり、ＲＤとＷＲを呼び出しても構わない）。システムは、消耗品上のＲＮＤ又はＴＳＴを決して呼び出す必要がない（なぜならば、複製チップはＴＳＴのような関数に１を返すだけであり、ＲＮＤに対して一定値を返すだけである）。
【１２１０】
ＩｓＴｒｕｓｔｅｄビットは、攻撃者によって獲得できる利用可能なＲ、ＦＫ１［Ｒ］の個数を減少させる付加的な利点があり、しかも認証プロトコルの完全性を維持する。有効なＲ、ＦＫ１［Ｒ］のペアを獲得するため、攻撃者は、システム認証チップが必要であり、これは、消耗品よりも高価であり入手が困難である。Ｒ及びＩｓＴｒｕｓｔｅｄビットの両方はＣＬＲコマンドによって０にクリアされる。これらは共に、ＳＳＴコマンドの発行によって書き込まれる。ＩｓＴｒｕｓｔｅｄビットは、ＳＳＩコマンドによって、非零シード値をＲに格納することによってのみセットすることができる（Ｒは有効なＬＦＳＲ状態であるために非零であり、これは全く合理的である）。Ｒは、ビット１、２、４及び１５９にタップが付いた１６０ビットの最大限の周期のＬＦＳＲによって変更され、ＴＳＴへの呼び出しが成功したときだけに（１が返された場合）変更される。
【１２１１】
システムで信頼されているチップ（チップＴ）になることが予定されている認証チップは、プログラミング中にそのＩｓＴｒｕｓｔｅｄビットがセットされるべきであり、消耗品で使用される認証チップ（チップＡ）は（プログラミング中にＳＳＩコマンドでＲに０を格納することにより）そのＩｓＴｒｕｓｔｅｄビットがクリアのままにされるべきである。ＩｓＴｒｕｓｔｅｄビットを直接読み書きするためのコマンドは存在しない。認証チップの安全性は、Ｋ１及びＫ２のランダム性、並びに、ＨＭＡＣ−ＳＨＡ１アルゴリズムの強度だけに依存するわけではない。攻撃者が疎ルックアップテーブルを構築することを妨げるため、認証チップの安全性は、全てのシステムの耐用期間に亘るＲのレンジにも依存する。したがって、Ｒは、物理的にランダムな現象から収集された、物理的に生成された乱数でプログラミングされるべきである。Ｒは、決して、コンピュータ上で実行される乱数生成器で生成してはならない。Ｒの生成は決定論的であってはならない。例えば、信頼できるシステムチップで使用するためのＲを生成するため、ある人は公正なコインを１６０回トスし、表を１として記録し、裏を０として記録する。０は信頼できるＲに対する唯一の有効でない初期値である（又は、ＩｓＴｒｕｓｔｅｄビットはセットされない）。
【１２１２】
ＳＩＷｒｉｔｔｅｎ
ＳＩＷｒｉｔｔｅｎ（秘密情報書き込み（Ｓｅｃｒｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｗｒｉｔｔｅｎ）１ビットレジスタは、認証チップ内に記憶された秘密情報の状態を保持する。秘密情報はＫ１、Ｋ２及びＲである。クライアントはＳＩＷｒｉｔｔｅｎビットに直接アクセスできない。その代わりに、ＳＩＷｒｉｔｔｅｎビットはＣＬＲコマンドによってクリアされる（このコマンドは、Ｋ１、Ｋ２及びＲもクリアする）。認証チップが、ＳＳＩコマンド（書き込まれる値とは無関係に）を使用して秘密鍵及び乱数シードでプログラミングされたとき、ＳＩＷｒｉｔｔｅｎビットは自動的にセットされる。Ｒは厳密には秘密ではないが、攻撃者が選択されたＲ、ＦＫ１［Ｒ］のペアを獲得するために自分の固有の乱数シードを生成し得ないことを保証するため、ＲはＫ１及びＫ２と一緒に書き込まなければならない。ＳＩＷｒｉｔｔｅｎ状態ビットは、Ｋ１、Ｋ２又はＲにアクセスする全ての関数によって使用される。ＳＩＷｒｉｔｔｅｎビットがクリアされている場合、ＲＤ、ＷＲ、ＲＮＤ及びＴＳＴの呼び出しはＣＬＲの呼び出しとして解釈される。
【１２１３】
ＭＩＮＴＩＣＫＳ
攻撃者が短時間の間にＴＳＴ及びＲＤ関数への多数の呼び出しを生成できないようにする二つのメカニズムが存在する。第１のメカニズムは、内部クロックが特定の最大値（例えば、１０ＭＨｚ）を超える速度で動作することを妨げるクロック制限ハードウェアコンポーネントである。第２のメカニズムは３２ビットのＭｉｎＴｉｃｋｓ（最小チック）レジスタであり、これは、鍵付き関数への呼び出しの間に経過しなければならない最小のクロックチック回数を指定するため使用される。ＭｉｎＴｉｃｋｓ変数はＣＬＲコマンドによって０にクリアされる。ビットは、ＳＭＴ（ＭｉｎＴｉｃｋｓセット）コマンドによってセットされる。ＳＭＴへの入力パラメータは、ＭｉｎＴｉｃｋｓのどのビットをセットすべきであるかを表現するビットパターンを含む。実際の効果は、攻撃者がＭｉｎＴｉｃｋｓの単位でしか値を増加し得ないことである（なぜならば、ＳＭＴ関数はビットをセットするだけである）。その上、呼び出し元がこのレジスタの現在の値を読み出すことができる関数は設けられていない。ＭｉｎＴｉｃｋｓの値は、動作クロック速度と、鍵付き関数呼び出しの間の合理的な時間の定め方（アプリケーションに固有）と、に依存する。１チックの間隔は動作クロック速度に依存する。これは、入力クロック速度と認証チップのクロック制限ハードウェアの最大値である。例えば、認証チップのクロック制限ハードウェアは１０ＭＨｚにセットされるが（これは変更できない）、入力クロックは１ＭＨｚである。このケースでは、１チックの値は１０ＭＨｚではなく、１ＭＨｚが基準になる。入力クロックが１ＭＨｚではなく２０ＭＨｚであるならば、１チックの値は１０ＭＨｚが基準になる（なぜならば、クロック速度は１０ＭＨｚで制限されている）。
【１２１４】
１チックの間隔がわかると、ＭｉｎＴｉｃｋｓ値をセットすることができる。ＭｉｎＴｉｃｋｓの値は、鍵付きＲＤ及びＴＳＴ関数への呼び出しの間に経過することが要求されるＭｉｎＴｉｃｋｓ数である。この値は、リアルタイム数であり、動作チックの長さで除算される。入力クロック速度が１０ＭＨｚの最大クロック速度と一致する場合を想定する。鍵付き関数の呼び出しの間に１秒の最小値を求めるならば、ＭｉｎＴｉｃｋｓの値は１０００００００にセットされる。攻撃者がＲＮＤ、ＲＤ及びＴＳＴを何回も呼び出すことによってＸ、ＦＫ１［Ｘ］のペアを収集しようとしている場合を考える。ＴＳＴへの呼び出しの間の時間が１秒になるようにＭｉｎＴｉｃｋｓ値がセットされているならば、各ペアを生成するために１秒が必要になる。２２５個のペア（１．２５Ｇｂの記憶量しか必要にならない）を生成するため、攻撃者は１年以上を必要とする。２６４個のペアが必要になる攻撃は、１個のチップを使用すると、５．８４×１０１１年が必要になり、１０億個のチップが使用されるならば、５８４年が必要になり、このような攻撃は時間的に全く非現実的になる（記憶必要量については言うまでもない！）。
【１２１５】
Ｋ１に関しては、ＭｉｎＴｉｃｋｓ変数は攻撃者を遅くさせ、攻撃のコストを高くするだけである。なぜならば、ＭｉｎＴｉｃｋｓは攻撃者が多数のシステムチップを並列に使用することを止めるものではないからである。しかし、ＭｉｎＴｉｃｋｓは、本当にＫ２への攻撃をより困難にさせる。なぜならば、各消耗品は異なるＭを有するからである（Ｍの一部はランダムなリードオンリーデータである）。差分攻撃に出るためには、最小限度の差の入力が必要であり、これは、単一の消耗品（Ｍの実効的に定数部を含む）によって実現できる。最小限度の差の入力は、攻撃者が単一チップを使用することを要求し、ＭｉｎＴｉｃｋｓは、単一チップの使用をスローダウンさせる。差分攻撃を始めるために値の検索を開始するためのデータを取得するだけに１年を要するのであれば、これは攻撃のコストを上昇させ、複製消耗品の実効的な販売期間を短縮する。
【１２１６】
認証チップコマンド
システムは簡単なオペレーションコマンドセットによって認証チップと通信する。このセクションは、プロトコル３の実装のために必要な実際のコマンド及びパラメータを詳述する。認証チップは、最低限の実装としてシリアルインタフェースによってシステムと通信するものとして定義される。より幅広いインタフェース（例えば、８、１６又は３２ビット）によって動作する等価的なチップを定義することは慣用的なことである。オペコードの解釈は、ＩｓＴｒｕｓｔｅｄビットの現在の値と、ＩｓＷｒｉｔｔｅｎビットの現在の値と、に依存し得る。以下のオペレーションが定義される。
【１２１７】
【表１１５】
0004309954.tif 000142
Ｏｐ＝オペコード、Ｔ＝ＩｓＴｒｕｓｔｅｄ値、Ｗ＝ＩｓＷｒｔｔｅｎ値、
Ｍｎ＝ニューモニック、［ｎ］＝パラメータに必要なビット数。
【１２１８】
この表に定義されていないコマンドは、ＮＯＰ（ノーオペレーション）として解釈される。その例には、（ＩｓＴｒｕｓｔｅｄ値又はＩｓＷｒｉｔｔｅｎ値とは無関係である）オペコード１１０及び１１１と、ＩｓＷｒｉｔｔｅｎ＝０のときのＳＳＩ以外のオペコードと、が含まれる。ＲＤ及びＲＮＤのオペコードは同じであり、ＷＲ及びＴＳＴのオペコードも同じであることに注意する必要がある。オペコードの受け取り後に動かされる実際のコマンドは、（ＩｓＷｒｉｔｔｅｎが１である限り）ＩｓＴｒｕｓｔｅｄビットの現在値に依存する。ＩｓＴｒｕｓｔｅｄビットがクリアされているところでは、ＲＤ及びＷＲ関数が呼び出される。ＩｓＴｒｕｓｔｅｄビットがセットされると、ＲＮＤ及びＴＳＴ関数が呼び出される。２組のコマンドは、信頼されている認証チップと信頼されていない認証チップとの間で相互に排他的であり、同じオペコードはこの関係を強いる。各コマンドは引き続くセクションで詳細に検討される。一部のアルゴリズムは具体的に設計される。なぜならば、フラッシュメモリが不揮発変数の実現形態として想定されるからである。
【１２１９】
【表１１６】
0004309954.tif 000143
ＣＬＲ（クリア）コマンドは、全ての認証チップメモリの内容を完全に消去するため設計される。これは、全ての鍵及び秘密情報と、アクセスモードビットと、状態データと、を含む。ＣＬＲコマンドの実行後、認証チップは、新しく製造されたときと丁度同じように、プログラマブル状態になる。それは、新しい鍵として再プログラムして、再使用することができる。ＣＬＲコマンドは、ＣＬＲコマンドオペコードだけにより構成される。認証チップはシリアルであるため、これは同時に１ビットずつ転送される。ビット順序は、各コマンドコンポーネントのＬＳＢからＭＳＢである。したがって、ＣＬＲコマンドは、ＣＬＲオペコードのビット０から２として送られる。全部で３ビットが転送される。ＣＬＲコマンドはいつでも直ちに呼び出すことができる。消去の順序は重要である。ＳＩＷｒｉｔｔｅｎｂｉｔ値は、（ＲＮＤ、ＴＳＴ、ＲＤ及びＷＲのような）鍵アクセス関数への更なる呼び出しを禁止するため、最初に消去されなければならない。ＡｃｃｅｓｓＭｏｄｅビットがＳＩＷｒｉｔｔｅｎの前にクリアされると、攻撃者は、それらがクリアされた後のある時点で電源を取り外し、Ｍを操作し、これにより、部分選択テキスト攻撃で秘密情報を取り出すよい機会を得る。ＣＬＲコマンドは以下のステップで実現される。
【１２２０】
【表１１７】
0004309954.tif 000144
チップがクリアされると、チップは再プログラミングと再使用の準備が完了する。ブランクチップは攻撃者にとって無用である。なぜならば、Ｍに対して任意の値を作成することが可能であるとしても（Ｍは読み出し及び書き込みが可能である）、Ｋ１及びＫ２が間違っているので鍵付き関数は全く情報を提供しないからである。ＣＬＲがＣＬＲ以外の任意のオペコードのために要求されるならば、入力パラメータビットを費やす必要がない。攻撃者はチップをリセットするだけでよい。ＣＬＲを呼び出す理由は、全ての秘密情報が破壊され、チップが攻撃者にとって無用になることを保証するためである。
【１２２１】
ＳＳＩ−秘密情報セット（ＳＥＴ ＳＥＣＲＥＴ ＩＮＦＯＲＭＡＴＩＯＮ）
入力：Ｋ１、Ｋ２、Ｒ＝［１６０ビット，１６０ビット，１６０ビット］
出力：無し
変更内容：Ｋ１、Ｋ２、Ｒ、ＳＩＷｒｉｔｔｅｎ、ＩｓＴｒｕｓｔｅｄ。
【１２２２】
ＳＳＩ（秘密情報セット（Ｓｅｔ Ｓｅｃｒｅｔ 
Ｉｎｆｏｒｍａｔｉｏｎ））コマンドは、Ｋ１、Ｋ２及びＲ変数にロードし、ＲＮＤ、ＴＳＴ、ＲＤ及びＷＲコマンドを後で呼び出すためＳＩＷｒｉｔｔｅｎ及びＩｓＴｒｕｓｔｅｄフラグをセットするため使用される。ＳＳＩコマンドは、ＳＳＩコマンドオペコードと、その後に続く、Ｋ１、Ｋ２及びＲレジスタに格納されるべき秘密情報と、を含む。認証チップはシリアルであるため、これは同時に１ビットずつ転送されるべきである。ビット順序は、各コマンドコンポーネントのＬＳＢからＭＳＢである。したがって、ＳＳＩコマンドは、ＳＳＩオペコードのビット０−２と、その後に続く、Ｋ１に対する新しい値のビット０−１５９と、Ｋ２に対する新しい値のビット０−１５９と、最後に、Ｒに対するシード値のビット０−１５９として送られる。全部で４８３ビットが転送される。Ｋ１、Ｋ２、Ｒ、ＳＩＷｒｉｔｔｅｎ、及びＩｓＴｒｕｓｔｅｄレジスタはＣＬＲコマンドによって全て０にクリアされる。それらは、ＳＳＩコマンドを使用することによってのみセットすることができる。
【１２２３】
ＳＳＩコマンドは、データがＫ１、Ｋ２及びＲにロードされた事実を格納するためフラグＳＩＷｒｉｔｔｅｎを使用する。ＳＩＷｒｉｔｔｅｎフラグ及びＩｓＴｒｕｓｔｅｄフラグをクリアされているならば（これは、ＣＬＲ命令後のケースである）、Ｋ１、Ｋ２及びＲに新しい値がロードされる。何れかのフラグがセットされているならば、ＳＳＩの呼び出しの試みによって、ＣＬＲコマンドが実行される。なぜならば、攻撃者又は間違ったクライアントだけが、ＣＬＲを先に呼び出すことなく、鍵又はランダムシードを変更しようとするからである。また、ＳＳＩコマンドは、Ｒに対する値に依存してＩｓＴｒｕｓｔｅｄフラグをセットする。Ｒ＝０であるならば、チップは信用できないとみなされ、したがって、ＩｓＴｒｕｓｔｅｄは０のまま維持される。Ｒ≠０であるならば、チップは信用できるとみなされ、ＩｓＴｒｕｓｔｅｄは１にセットされる。ＩｓＴｒｕｓｔｅｄビットの設定は、ＳＳＩコマンドの間だけで行われることに注意する必要がある。認証チップが再使用されるならば、ＣＬＲコマンドは最初に呼び出されなければならない。その後、鍵は、ＳＳＩコマンドで安全にプログラムされ、新たな状態情報がＳＡＭ及びＷＲコマンドを用いてＭへロードされる。ＳＳＩコマンドは以下のステップで実行される。
【１２２４】
【表１１８】
0004309954.tif 000145
ＲＤ−読み出し
入力：Ｘ、ＦＫ１［Ｘ］＝［１６０ビット、１６０ビット、１６０ビット］
出力：Ｍ、ＦＫ２［Ｘ｜Ｍ］＝［２５６ビット、１６０ビット］
変更内容：Ｒ。
【１２２５】
ＲＤ（リード）コマンドは、信頼されない認証チップから状態データ（Ｍ）の２５６ビット全体を安全に読み出すために使用される。有効認証チップだけがＲＤ要求に正しく応答する。ＲＤコマンドからの出力ビットは、入力ビットとして、検証用の信頼された認証チップ上のＴＳＴコマンドへ供給でき、最初の２５６ビット（Ｍ）は、ＴＳＴが（期待通りに）１を戻す場合に後で使用するため保存される。認証チップはシリアルであるため、コマンド及び入力パラメータは同時に１ビットずつ転送されるはずである。ビット順序は、各コマンドコンポーネントのＬＳＢからＭＳＢである。したがって、ＲＤコマンドは、ＲＤオペコードのビット０−２と、その後に続く、Ｘのビット０−１５９と、ＦＫ１［ｘ］のビット０−１５９である。全部で３２０ビットが転送される。Ｘ及びＦＫ１［Ｘ］は信頼された認証チップのＲＮＤコマンドを呼び出すことによって獲得される。信頼されたチップのＲＮＤコマンドから出力された３２０ビットは、したがって、信頼されないチップのＲＤコマンドへそのまま供給することが可能であり、それらのビットをシステムによって保存しなくてもよい。ＲＤコマンドは、以下の条件が充たされたときに限り使用できる：
ＳＩＷｒｉｔｔｅｎ＝１ Ｋ１、Ｋ２、ＲがＳＳＩコマンドによってセットアップされたことを示す；
ＩｓＴｒｕｓｔｅｄ＝０ 乱数シーケンスを生成することが許可されないのでチップは信頼されないことを示す。
【１２２６】
加えて、ＲＤの呼び出しは、ＭｉｎＴｉｃｋｓＲｅｍａｉｎｉｎｇレジスタが０に達するまで待たなければならない。そうなった後、レジスタには、ＭｉｎＴｉｃｋｓが再ロードされ、ＲＤへの呼び出しの間に最小限度の時間が確実に経過する。ＭｉｎＴｉｃｋｓＲｅｍａｉｎｉｎｇにＭｉｎＴｉｃｋｓが再ロードされると、ＲＤコマンドは入力パラメータが有効であることを検証する。これは、入力Ｘに対するＦＫ１［Ｘ］を内部的に生成し、次に、得られた結果を入力ＦＫ１［Ｘ］と比較することによって行われる。この生成及び比較は、入力パラメータが正しいかどうかとは無関係に同じ時間を使用しなければならない。時間が同一ではない場合、攻撃者は、ＦＫ１［Ｘ］のどのビットが間違っているかに関する情報を得ることができる。入力パラメータが無効になるのは、間違ったシステム（誤ったビットを渡す）、間違ったシステムに間違った消耗品がある場合、不良の信頼されるチップ（不良なペアを生成する）、又は認証チップへの攻撃に限られる。一定値０は入力パラメータが間違っている場合に返される。０が返されるまでに要する時間は、あらゆる不良な入力に対して同じでなければならないので、攻撃者は何が無効であるかに関する情報を全く学習できない。入力パラメータが検証されると、出力値が計算される。Ｍの２５６ビットの内容は、Ｍ［０］のビット０−１５、Ｍ［１］のビット０−１５から、Ｍ［１５］のビット０−１５の順番に転送される。ＦＫ２［Ｘ｜Ｍ］は計算され、ビット０−１５９として出力される。Ｒレジスタは、Ｘ、ＦＫ１［Ｘ］ペアの検証中に、値を格納するため使用される。その理由は、ＲＮＤとＲＤが相互に排他的であるためである。ＲＤコマンドは以下のステップで実施される。
【１２２７】
【表１１９】
0004309954.tif 000146
ＲＮＤ−ランダム
入力：無し
出力：Ｒ、ＦＫ１［Ｒ］＝［１６０ビット、１６０ビット］
変更内容：無し。
【１２２８】
ＲＮＤ（ランダム）コマンドは、ＲＤ及びＴＳＴコマンドによって、後続の認証で使用するための有効Ｒ、ＦＫ１［Ｒ］ペアを獲得するためクライアントによって使用される。入力パラメータが無いので、ＲＮＤコマンドは単にＲＮＤオペコードのビット０−２である。ＲＮＤコマンドは以下の条件が充たされた場合に限り使用できる：
ＳＩＷｒｉｔｔｅｎ＝１ Ｋ１およびＲがＳＳＩコマンドによってセットアップされたことを示す；
ＩｓＴｒｕｓｔｅｄ＝１ チップは乱数シーケンスを生成することが許可されていることを示す。
【１２２９】
ＲＮＤは、ＲとＦＫ１［Ｒ］の両方を呼び出し元へ返す。ＲＮＤコマンドの２８８ビット出力は、信頼されないチップのＲＤコマンドに入力パラメータとして供給することが可能である。クライアントはそれらを全く格納する必要が無い。なぜならば、それらは再度要求されないからである。しかし、ＴＳＴコマンドは、ＲＤコマンドに渡された乱数が最初にＲＮＤコマンドから取得されたものである場合に限り成功する。呼び出し元がＲＮＤだけを複数回呼び出すならば、同じＲ、ＦＫ１［Ｒ］のペアが毎回返されるであろう。Ｒは、ＴＳＴへの呼び出しが成功であった後、シーケンス内の次の乱数へ進む。より詳しくはＴＳＴの説明を参照せよ。ＲＮＤコマンドは以下のステップで実施される。
【１２３０】
【表１２０】
0004309954.tif 000147
ＴＳＴ−テスト（ＴＥＳＴ）
入力：Ｘ、ＦＫ２［Ｒ｜Ｘ］＝［２５６ビット、１６０ビット］
出力：１又は０＝［１ビット］
変更内容：Ｍ、Ｒ及びＭｉｎＴｉｃｋｓＲｅｍａｉｎｉｎｇ（又は攻撃が検出されたならば全てのレジスタ）。
【１２３１】
ＴＳＴ（テスト（Ｔｅｓｔ））コマンドは、信頼されない認証チップからのＭの読み出しを認証するため使用される。ＴＳＴ（テスト）コマンドは、ＴＳＴコマンドオペコードと、その後に続く入力パラメータ：Ｘ及びＦＫ２［Ｒ｜Ｘ］と、により構成される。認証チップはシリアルであるため、これは同時に１ビットずつ転送されなければならない。ビット順序は、各コマンドコンポーネントのＬＳＢからＭＳＢである。したがって、ＴＳＴコマンドは、ＴＳＴオペコードのビット０−２と、その後に続く、Ｍのビット０−２５５と、ＦＫ２［Ｒ｜Ｍ］のビット０−１５９である。全部で４１９ビットが転送される。最後の４１６入力ビットは、ＲＤコマンドから信頼されない認証チップへの出力ビットとして獲得されるので、データ全体をクライアントが保存する必要はない。その代わりに、ビットは、信頼された認証チップのＴＳＴコマンドへそのまま渡すことができる。Ｍのうちの２５６ビットだけがＲＤコマンドに秘密にされるべきである。ＴＳＴコマンドは、以下の条件が充たされたときに限り使用できる：
ＳＩＷｒｉｔｔｅｎ＝１ Ｋ２およびＲがＳＳＩコマンドによってセットアップされたことを示す；
ＩｓＴｒｕｓｔｅｄ＝１ チップは乱数シーケンスを生成することが許可されていることを示す。
【１２３２】
加えて、ＴＳＴの呼び出しは、ＭｉｎＴｉｃｋｓＲｅｍａｉｎｉｎｇレジスタが０に達するまで待たなければならない。そうなった後、レジスタには、ＭｉｎＴｉｃｋｓが再ロードされ、ＴＳＴへの呼び出しの間に最小限度の時間が確実に経過する。ＴＳＴは、内部Ｍ値を入力Ｍ値によって置き換えさせる。次に、ＦＫ２［Ｍ｜Ｒ］が計算され、１６０ビット入力ハッシュ値と比較される。生成される単一出力ビットは、両者が同じであるならば１であり、両者が異なるならば０である。内部Ｍ値を使用することは、チップ上のスペースを節約し、ＲＤ及びＴＳＴが相互に排他的なコマンドであることの理由である。出力ビットが１であるならば、Ｒはシーケンス内の次の乱数になるように更新される。これは、ＲＤ及びＴＳＴテストが呼び出される毎に、呼び出し元に強制的に新しい乱数を使用させる。結果の出力ビットは、入力文字列全体が比較されるまでは出力されないので、ＴＳＴ関数内の比較を評価するために要する時間は常に同じである。このようにして、攻撃者は、実行時間、又は出力が与えられる前に処理されたビット数を比較できない。
【１２３３】
次の乱数は、１６０ビットの最大周期のＬＦＳＲ（タップはビット１５９、４、２及び１で選択）を使用してＲから生成される。Ｒの初期１６０ビット値はＳＳＩコマンドによってセットアップされ、０以外のいかなる乱数でもよい（０で満たされたＬＦＳＲは際限のない０のストリームを生成する）。Ｒはビット１、２、４及び１５９をまとめてＸＯＲ論理演算し、ＸＯＲ論理演算の結果をｂ１５９への入力として用いて１６０ビット全部を右へ１ビットシフトすることにより変換される。新しいＲは次のＲＮＤ呼び出しの際に返される。ＴＳＴから０を返すために要する時間は、全ての不良な入力に対して同じであり、攻撃者は無効な入力に関して何も学習し得ないことに注意する必要がある。
【１２３４】
ＴＳＴコマンドは以下のステップで実施される。
【１２３５】
【表１２１】
0004309954.tif 000148
尚、ステップ７では、単純にそのままＲを進めることができない。なぜならば、Ｒはフラッシュメモリであり、セットされたビットが０になるためには消去しなければならないからである。電源が、古いＲの値を消去した後で新しいＲの値が書き込まれる前に、ステップ７の間に認証チップから取り外された場合、Ｒは消去されるが再プログラミングされない。したがって、ＩｓＴｒｕｓｔｅｄ＝１でありながら、Ｒ＝０であるという状況が生まれ、この状況が起こり得るのは攻撃者が原因となる場合だけである。ステップ４はこの事象を検出し、攻撃が検出された場合に動作する。この問題は、Ｒのための第２の１６０ビットフラッシュレジスタと有効性ビットとを設け、新しい値がロードされた後にトグル切替することで防ぐことができる。これは、スペースの理由で本実施形態には組み込まれていないが、チップ空間がそれを許容するならば、補助的な１６０ビットフラッシュレジスタがこの目的のために有用であろう。
【１２３６】
ＷＲ−書き込み（ＷＲＩＴＥ）
入力：Ｍｎｅｗ＝［２５６ビット］
出力：無し
変更内容：Ｍ。
【１２３７】
ＷＲ（書き込み（Ｗｒｉｔｅ））コマンドは、認証チップ状態データを格納するＭの書き込み可能な部分を更新するため使用される。ＷＲコマンド自体は安全ではない。ＷＲコマンドの後には、（ＲＤコマンドによる）認証されたＭの読み出しが続き、指定されたとおりに変更がなされたことを保証する。ＷＲコマンドは、ＷＲコマンドオペコードと、その後に続くＭへ書き込まれるべき新しい２５６ビットのデータと、を渡すことによって呼び出される。認証チップはシリアルであるため、Ｍの新しい値は同時に１ビットずつ転送されなければならない。ビット順序は、各コマンドコンポーネントのＬＳＢからＭＳＢである。したがって、ＷＲコマンドは、ＷＲオペコードのビット０−２と、その後に続く、Ｍ［０］のビット０−１５と、Ｍ［１］のビット０−１５からＭ［１５］のビット０−１５まである。全部で２５９ビットが転送される。ＷＲコマンドは、ＳＩＷｒｉｔｔｅｎ＝１のとき、即ち、Ｋ１、Ｋ２、ＲがＳＳＩコマンドによってセットアップされたことを示すときに限り使用できる（ＳＩＷｒｉｔｔｅｎが０であるならば、Ｋ１、Ｋ２、Ｒは未だセットアップされていないので、代わりにＣＬＲコマンドが呼び出される）。特定のＭ［ｎ］への書き込みの可能性は、ＡｃｃｅｓｓｓＭｏｄｅレジスタに格納されているような対応したアクセスモードビットにより支配される。ＡｃｃｅｓｓＭｏｄｅビットはＳＡＭコマンドを用いてセットできる。新しい値をＭ［ｎ］へ書き込みとき、Ｍ［ｎ］はフラッシュメモリであるということを考慮しなければならない。Ｍ［ｎ］の全てのビットを消去した後、適切なビットをセットしなければならない。二つのステップが別々のサイクルで行われるので、攻撃の可能性は無防備のままである。攻撃者は、消去後、しかし、新しい値をプログラミングする前に、電源を取り外すことが可能である。しかしながら、攻撃者はこれを行っても利益がない：
この手段によってリード／ライトＭ［ｎ］が０に変更されることは全く利益がない。なぜならば、攻撃者はＷＲコマンドを使用して任意の値を書き込めるからである；
この手段によってリードオンリーＭ［ｎ］が０に変更されることによって、付加的なテキストペアを知ることができる（ここで、Ｍ［ｎ］は元の値ではなく０である）。将来Ｍ［ｎ］値を使用する場合、それらは既に０であるため、全く情報が与えられない；
デクリメントオンリーＭ［ｎ］が０に変更されると、消耗品が使い切られる時間が早まるだけである。これは、消耗品を使用することによって得られるような何ら新しい情報を攻撃者に与えることはない。
【１２３８】
ＷＲコマンドは以下のステップで実施される。
【１２３９】
【表１２２】
0004309954.tif 000149
ＳＡＭ−アクセスモードセット（ＳＥＴ ＡＣＣＥＳＳ ＭＯＤＥ）
入力：ＡｃｃｅｓｓＭｏｄｅｎｅｗ＝［３２ビット］
出力：ＡｃｃｅｓｓＭｏｄｅ＝［３２ビット］
変更内容：ＡｃｃｅｓｓＭｏｄｅ。
【１２４０】
ＳＡＭ（アクセスモードセット（Ｓｅｔ Ａｃｃｅｓｓ Ｍｏｄｅ））コマンドは、ＡｃｃｅｓｓＭｏｄｅレジスタの３２ビットをセットするため使用され、消耗品認証チップでの使用だけが有効である（ＩｓＴｒｕｓｔｅｄフラグ＝０の場合）。ＳＡＭコマンドは、ＳＡＭコマンドオペコードと、その後に続く、ＡｃｃｅｓｓＭｏｄｅレジスタにビットをセットするために使用される３２ビット値と、を渡すことによって呼び出される。認証チップはシリアルであるため、データは同時に１ビットずつ転送されなければならない。ビット順序は、各コマンドコンポーネントのＬＳＢからＭＳＢである。したがって、ＳＡＭコマンドは、ＳＡＭオペコードのビット０−２と、その後に続く、ＡｃｃｅｓｓＭｏｄｅにセットされるビットのビット０−３１と、である。全部で３５ビットが転送される。ＡｃｃｅｓｓＭｏｄｅレジスタはＣＬＲコマンドの実行時に限り０にクリアされる。００というアクセスモードはＲＷ（リード／ライト）のアクセスモードを示すので、ＣＬＲ後にＡｃｃｅｓｓＭｏｄｅビットをセットしないことは、全てのＭが読み書きできることを意味する。ＳＡＭコマンドだけがＡｃｃｅｓｓＭｏｄｅレジスタのビットをセットする。したがって、クライアントは、３２ビット語に適当なビットをセットし、入力パラメータとしての３２ビット値を用いてＳＡＭを呼び出すことにより、Ｍ［ｎ］に対するアクセスモードビットをＲＷからＲＯ（リードオンリー）へ変更可能である。これは、様々な時点での、おそらく製造プロセスの種々のステージにおけるアクセスモードビットのプログラミングを可能にさせる。例えば、リードオンリーランダムデータは、初期鍵プログラミングステージ中に書き込むことが可能であり、一方、消耗品シリアル番号のような項目のための第２のプログラミングステージが許可される。
【１２４１】
ＳＡＭコマンドはビットをセットするだけであるので、その効果は、Ｍ［ｎ］に対応するアクセスモードビットをＲＷからＭＳＲ、ＮＭＳＲ又はＲＯの何れかへ進行させ得ることである。尚、ＭＳＲのアクセスモードはＲＯへ変更可能であるが、これは、攻撃者には役立たないことに注意する必要がある。なぜならば、不正に加工された認証チップへの書き込み後のＭの認証は、書き込みが不成功であったことを検出し、オペレーションを中止するからである。ビットの設定は、フラッシュメモリが最も巧く機能する方法に対応する。ＡｃｃｅｓｓＭｏｄｅレジスタ内のビットをクリアする唯一の方法は、例えば、デクリメントオンリーＭ［ｎ］をリード／ライトに変更するための唯一の方法は、ＣＬＲコマンドを使用することである。ＣＬＲコマンドは、ＡｃｃｅｓｓＭｏｄｅレジスタを消去（クリア）するだけではなく、鍵及び全てのＭをクリアする。このようにして、Ｍ［ｎ］に対応するＡｃｃｅｓｓＭｏｄｅ［ｎ］ビットは、ＣＬＲコマンドの間で１回だけ有効に変更することができる。ＳＡＭコマンドは（適切なビットが入力パラメータによってセットされた後）ＡｃｃｅｓｓＭｏｄｅレジスタの新しい値を返す。入力パラメータを０としてＳＡＭを呼び出すことにより、ＡｃｃｅｓｓＭｏｄｅは変更されず、したがって、ＡｃｃｅｓｓＭｏｄｅの現在値が呼び出し元へ返される。
【１２４２】
ＳＡＭコマンドは以下のステップで実施される。
【１２４３】
【表１２３】
0004309954.tif 000150
ＧＩＴ−ＩｓＴｒｕｓｔｅｄを取得（ＧＥＴ ＩＳＴＲＵＳＴＥＤ）
入力：無し
出力：ＩｓＴｒｕｓｔｅｄ＝［１ビット］
変更内容：無し。
【１２４４】
ＧＩＴ（ＩｓＴｒｕｓｔｅｄ取得（Ｇｅｔ ＩｓＴｒｕｓｔｅｄ）コマンドは、認証チップ上のＩｓＴｒｕｓｔｅｄビットの現在値を読むため使用される。戻されるビットが１であるならば、認証チップは信頼できるシステム認証チップである。戻されるビットが０であるならば、認証チップは消耗品認証チップである。ＧＩＴコマンドは、ＧＩＴコマンドオペコードだけを含む。認証チップはシリアルであるため、これは同時に１ビットずつ転送されなければならない。ビット順序は、各コマンドコンポーネントのＬＳＢからＭＳＢである。したがって、ＳＡＭコマンドは、ＳＡＭオペコードのビット０−２として送信される。全部で３ビットが転送される。ＧＩＴコマンドは以下のステップで実施される。
【１２４５】
【表１２４】
0004309954.tif 000151
ＳＭＴ−ＭｉｎＴｉｃｋｓセット（ＳＥＴ ＭＩＮＴＩＣＫＳ）
入力：ＭｉｎＴｉｃｋｓｎｅｗ＝［３２ビット］
出力：無し
変更内容：ＭｉｎＴｉｃｋｓ。
【１２４６】
ＳＭＴ（ＭｉｎＴｉｃｋｓセット（Ｓｅｔ ＭｉｎＴｉｃｋｓ））コマンドは、ＭｉｎＴｉｃｋｓレジスタのビットをセットし、ＴＳＴ及びＲＤへの呼び出しの間に経過すべきＭｉｎＴｉｃｋｓ数を定めるため使用される。ＳＭＴコマンドは、ＳＭＴコマンドオペコードと、その後に続く、ＭｉｎＴｉｃｋｓレジスタにビットをセットするために使用される３２ビット値と、を渡すことによって呼び出される。認証チップはシリアルであるため、データは同時に１ビットずつ転送されなければならない。ビット順序は、各コマンドコンポーネントのＬＳＢからＭＳＢである。したがって、ＳＭＴコマンドは、ＳＭＴオペコードのビット０−２と、その後に続く、ＭｉｎＴｉｃｋｓにセットされるビットのビット０−３１と、である。全部で３５ビットが転送される。ＭｉｎＴｉｃｋｓレジスタはＣＬＲコマンドの実行時に限り０にクリアされる。０という値は、鍵付き関数の呼び出しの間にチックを経過させなくてもよいことを示す。したがって、この関数は、クロック速度制限ハードウェアがチップに動作を許可する頻度で呼び出される。
【１２４７】
ＳＭＴコマンドはビットをセットするだけなので、その効果は、クライアントが値をセットできるようにさせ、更なる呼び出しが行われた場合に時間遅延を増大させるだけである。既にセットされたビットをセットすることは効果がなく、クリアされているビットをセットすることだけが、チップを更に遅くさせるために作用する。ビットの設定はフラッシュメモリが最も巧く機能する方法に対応する。ＭｉｎＴｉｃｋｓレジスタ内のビットをクリアする唯一の方法は、例えば、１０チックの値を４チックの値に変更するための唯一の方法は、ＣＬＲコマンドを使用することである。しかし、ＣＬＲコマンドは、ＭｉｎＴｉｃｋｓレジスタを０にクリアするだけではなく、全ての鍵及びＭをクリアする。したがって、それは攻撃者にとっては役に立たない。このようにして、ＭｉｎＴｉｃｋｓレジスタは、ＣＬＲコマンドの間で１回だけ有効に変更することができる。
【１２４８】
ＳＭＴコマンドは以下のステップで実施される。
【１２４９】
【表１２５】
0004309954.tif 000152
認証チップのプログラミング
認証チップは物理的に安全な環境内で論理的に安全な情報でプログラミングしなければならない。その結果として、プログラミング手続は論理的セキュリティと物理的セキュリティの両方を取り扱う。論理的セキュリティは、Ｋ１、Ｋ２、Ｒ及び乱数Ｍ［ｎ］の値が、コンピュータではなく、物理的にランダムなプロセスによって生成されることを保証するプロセスである。また、それは、チップの部品のプログラミングされる順序が最も論理的に安全であることを保証するプロセスでもある。物理的セキュリティは、プログラミングステーションが物理的に安全であり、したがって、鍵生成ステージ期間と鍵の記憶の耐用期間の両方で、Ｋ１及びＫ２が秘匿されることを保証するプロセスである。その上、プログラミングステーションは、鍵を獲得又は破壊する物理的攻撃に対抗しなければならない。認証チップは、Ｋ１及びＫ２が秘匿されることを保証するための固有のセキュリティメカニズムを備えているが、プログラミングステーションはＫ１及びＫ２を安全に保持しなければならない。
【１２５０】
概要
製造後、認証チップは使用可能にされる前にプログラミングする必要がある。全てのチップにおいて、Ｋ１及びＫ２の値を確定しなければならない。チップがシステム認証チップを目的としているならば、Ｒの初期値を決めなければならない。チップが消耗品認証チップを目的としているならば、Ｒは０にセットし、Ｍ及びＡｃｃｅｓｓＭｏｄｅの初期値も設定しなければならない。したがって、以下のステージが確認される：
システムと消耗品の間の繰り返しを決定する；
システム及び消耗品用の鍵を決定する；
システム及び消耗品用のＭｉｎＴｉｃｋｓを決定する；
鍵、ランダムシート、ＭｉｎＴｉｃｋｓ及び未使用Ｍをプログラムする；
状態データ及びアクセスモードをプログラムする。
【１２５１】
消耗品又はシステムが必要でなくなると、取り付けられた認証チップは再使用可能である。これは、もう一度ステージ４から始めて、チップを再プログラミングすることによって簡単に実現できる。各ステージは以下のセクションで説明する。
【１２５２】
ステージ０：製造
認証チップの製造は特別なセキュリティを必要としない。製造ステージでは、チップにプログラミングされている秘密情報はない。アルゴリズム及びチッププロセスは特別ではない。標準的なフラッシュプロセスが使用される。チップ製造者とプログラミングステーションの間での認証チップの盗難は、複製品製造者にブランクチップを与えることになるだけである。これは、認証チップの販売を危うくすることは殆どなく、認証チップによって何も認証されない。プログラミングステーションは、消耗品及びシステムのプロダクト鍵を含む唯一のメカニズムであるため、複製品製造者は、正しい鍵を用いてチップをプログラムできない。複製品製造者は、自分専用のシステム及び消耗品用にブランクチップをプログラミングすることは可能であるが、それらの品を見破られずに販売することは困難であろう。その上、１回の盗みではビジネスの基礎を置くことは難しいであろう。
【１２５３】
ステージ１：システムと消耗品の間の相互作用の決定
システムとは何か、及び消耗品とは何か、の判断は、認証チップのプログラミングが可能になる前に決定されるべきである。どの消耗品がどのシステムで使用可能であるかに関する判断をする必要がある。なぜならば、接続されるシステムと消耗品だけが同じ鍵情報を共有しなければならないからである。また、それらは、状態データの一部の解釈が未決定であっても、状態データ使用メカニズムを共有すべきである。簡単な例は、車と、車キーの場合である。車自体はシステムであり、車キーは消耗品である。各車には数個の車キーがあり、各キーは特定の車と同じ鍵情報を格納する。しかし、各車（システム）は（その車キーと共有される）異なる鍵をもつであろう。なぜならば、ある車の車キーが別の車で機能することが求められないからである。別の例は、特定のトナーカートリッジを必要とするコピー機の場合である。簡単に言えば、コピー機はシステムであり、トナーカットリッジは消耗品である。しかし、カートリッジとコピー機の間にどのような互換性があるかを判断する必要がある。この判断は、従来、トナーカートリッジの物理的パッケージングによって行われ、ある種のカートリッジは、新しいモデルのコピー機の設計判断に基づいて、その新しいモデルのコピー機に適合し、或いは、適合しない。認証チップが使用されるとき、連動すべきコンポーネントは同じ鍵情報を共有しなければならない。
【１２５４】
更に、消耗品はタイプ毎に、Ｍ（状態データ）の異なる分割方法が必要になる。Ｍの使用法は、アプリケーション毎に変化するものであり、Ｍ［ｎ］及びＡｃｃｅｓｓＭｏｄｅ［ｎ］の割付方法も同様である：
特定用途の消耗品状態データを定義する；
将来の使用のため（必要に応じて）一部のＭ［ｎ］レジスタを確保する。それらを０にセットし、リードオンリーにセットする。値は互換性を保つためにシステムでテストすることができる；
残りのＭ［ｎ］レジスタ（少なくとも１個、しかし、Ｍ［１５］であってはならない）をリードオンリーにセットし、各Ｍ［ｎ］の内容を完全にランダムにする。これによって、複製品製造者は認証鍵への攻撃がより困難になる；
以下の例は、状態データが編成される方法を示す。
【１２５５】
例１
車キーが付随した車を想定する。１６ビット鍵番号は、所定の車の車キーを一意に識別するために十分足りる。Ｍの２５６ビットは以下の通り分割される。
【１２５６】
【表１２６】
0004309954.tif 000153
車製造者が全ての車の全ての論理的鍵を保持するならば、車キーを紛失したときに、新しい物理的な車キーを製造することは些細な問題である。新しい車キーは、Ｍ［０］に新しい鍵番号を格納するが、その車の認証チップと同じＫ１及びＫ２を含む。車システムは、特定の鍵番号を無効にすることができる（例えば、鍵を紛失したとき）。このようなシステムは、鍵０（マスター鍵）を最初に挿入し、次に全ての有効な鍵を挿入し、次に、鍵０をもう一度挿入することを要求するかもしれない。これらの有効な鍵だけが車と連動するようになる。最悪のケースでは、例えば、全ての車キーを紛失すると、その車に対する新しい論理的な鍵の組を生成し、必要に応じて、関連した物理的な車キーを生成することができる。カーエンジン番号は、その鍵を特定の車に結びつけるために使用される。将来用データは、レンタル情報、例えば、ドライバ／貸出者の詳細情報のような事項を格納する。
【１２５７】
例２
１０００００回のコピー毎に交換しなければならないコピー機画像ユニットの例を想定する。残りページ数を記憶するため３２ビットが必要になる。Ｍの２５６ビットは次の通り分割される。
【１２５８】
【表１２７】
0004309954.tif 000154
１００００回のコピー毎に交換しなければならない低品質画像ユニットが製作されたとき、３２ビットのページカウントは、既存コピー機との互換性のためにそのまま使用される。これにより、数タイプの消耗品を同じシステムで使用できるようになる。
【１２５９】
例３
２５枚の写真を格納するポラロイド型カメラの例を考える。残り写真数を記憶するためには１６ビットのカウントダウンだけあればよい。Ｍの２５６ビットは次の通り分割される。
【１２６０】
【表１２８】
0004309954.tif 000155
Ｍ［２］の残り写真数は、同じカメラシステムと使用するための多数の消耗品タイプの構築を可能にさせる。例えば、写真数３６の新しい消耗品は簡単にプログラムできる。カメラの発表後、２年が経過した場合を考えると、新しいタイプのカメラが発表されている。それは、古い消耗品を使用することが可能であるが、新しいフィルムタイプも処理できる。Ｍ［３］はフィルムタイプを定義するため使用できる。古いフィルムタイプは０であり、新しいフィルムタイプは他の新しい値である。新しいシステムはこれを利用することができる。元のシステムはＭ［３］に非零値を検出し、新しいフィルムタイプとの非互換性を認識する。新しいシステムは、Ｍ［３］の値を理解し、適切に応じる。古い消耗品との互換性を保つため、新しい消耗品及びシステムは、古いものと同じ鍵情報をもつことが必要である。新しいシステム及びその専用消耗品と完全に断ち切るためには、新しい鍵セットが必要になるであろう。
【１２６１】
例４
シアン、マゼンタ、及びイエローの三つのインクを格納するプリンタ消耗品の例を考える。各インク量は別々にデクリメントされるべきである。Ｍの２５６ビットは次の通り分割される。
【１２６２】
【表１２９】
0004309954.tif 000156
ステージ２：システム及び消耗品の鍵の決定
どのシステムとどの消耗品が同じ鍵を共有すべきであるかに関する決定がなされると、それらの鍵を定義しなければならない。したがって、Ｋ１及びＫ２の値が決定される。殆どのケースでは、Ｋ１及びＫ２は全体で１回だけ生成される。連動すべき（現在及び将来の）全てのシステム及び消耗品は、同じ鍵Ｋ１及びＫ２の値をもつ。したがって、Ｋ１及びＫ２は秘匿されなければならない。なぜならば、システム／消耗品の組み合わせに対するセキュリティメカニズム全体は、鍵が見られてしまうと、役に立たなくなるからである。鍵が暴露されると、その損害は、システム及び消耗品の数、並びに、それらを新たな暴露されていない鍵で再プログラミングすることの容易さに依存する。トナーカートリッジを用いるコピー機の場合、最悪のケースでは、複製品製造者は固有の認証チップを製造し（又は、さらに悪い場合には、それらを購入し）、判明した鍵でチップをプログラムし、固有の消耗品に挿入する。車キー付きの車のケースでは、各車は、異なる鍵の組をもつ。このことにより、２通りの一般的なシナリオが生まれる。第１のシナリオでは、車及び車キーがそれらの鍵を用いてプログラムされた後、Ｋ１及びＫ２が削除され、それらの値の記録が保持されず、即ち、Ｋ１及びＫ２を暴露する方法がない。しかし、その車のための予備の車キーは、車の認証チップを再プログラミングしない限り製作できない。第２のシナリオでは、車製造者はＫ１及びＫ２を保持し、その車のための新しいキーを製作可能である。Ｋ１及びＫ２の暴露は、ある者が特定の車専用の車キーを製作できることを意味する。
【１２６３】
したがって、認証チップで使用される鍵及びランダムデータは、非決定論的な手段によって生成されるべきである（完全にコンピュータで生成された疑似乱数は使用できない。なぜならば、それは、生成器のシードを知ることによって将来の全ての数が得られるという点で決定論的であるからである）。Ｋ１及びＫ２は、コンピュータではなく、物理的にランダムなプロセスによって生成されるべきである。しかし、ランダム性の自然発生源に基づくランダムビット生成器は、外因の影響を受けやすく、故障し易い。そのような装置は、統計的なランダム性を定期的にテストすべきであることが避けられない。
【１２６４】
簡単ではあるが、有用な乱数発生源は、ＳＧＩからのＬａｖａｒａｎｄ（登録商標）システムである。この生成器は、数分間隔で６個のラバランプを撮影するデジタルカメラを使用する。ラバランプは無秩序なタービュラント系を含む。得られたデジタル画像はＳＨＡ−１実装部に供給され、ＳＨＡ−１実装部は、７方向のハッシュを生成し、デジタル化された画像から７バイト毎に１６０ビット値を生じる。７組の１６０ビットの合計は１４０バイトになる。この１４０バイトの値がＢＢＳ生成器に供給され、出力ビットストリームのスタート位置を決める。ＢＢＳからの出力１６０ビットは、鍵、又は認証チップ５３である。
【１２６５】
非決定論的なランダムプロセスの極端な例は、クリーンルーム内で、Ｋ１のためにコインを１６０回トスし、Ｋ２のためにコインを１６０回トスすることである。それぞれの表又は裏に応じて、１又は０が鍵プログラマ装置のパネルに入力される。このプロセスは、（検証のための）数人の観測者が沈黙した状態（誰かが隠しマイクを持っているかもしれない）で行われる。重要なことは、安全なデータ入力及び記憶は、それほど簡単ではないということである。鍵プログラマ装置及び付随するプログラミングステーションの物理的セキュリティは、その固有の完全なドキュメントが必要である。鍵Ｋ１及びＫ２が決定された後、それらは、認証チップがその鍵を使用する必要のある限り保持されなければならない。最初の車／車キーのシナリオでは、Ｋ１及びＫ２は、単一のシステムチップ及び数個の消耗品チップがプログラムされた後に破壊されている。コピー機／トナーカートリッジのケースでは、Ｋ１及びＫ２は、トナーカートリッジがコピー機の役に立っている間に限り保持されなければならない。それらは秘匿されるべきである。
【１２６６】
ステージ３：システム及び消耗品のＭｉｎＴｉｃｋｓの決定
ＭｉｎＴｉｃｋｓの値は、認証チップの動作クロック速度（システム固有）と、ＲＤ又はＴＳＴ関数呼び出しの間の妥当な時間の根拠（アプリケーション固有）と、に依存する。単一チックの間隔は動作クロック速度に依存する。これは、入力クロック速度と認証チップのクロック制限ハードウェアの最大値である。例えば、認証チップのクロック制限ハードウェアは１０ＭＨｚにセットされるが（これは変更できない）、入力クロックは１ＭＨｚである。このケースでは、１チックの値は１０ＭＨｚではなく、１ＭＨｚが基準になる。入力クロックが１ＭＨｚではなく２０ＭＨｚであるならば、１チックの値は１０ＭＨｚが基準になる（なぜならば、クロック速度は１０ＭＨｚで制限されている）。１チックの間隔がわかると、ＭｉｎＴｉｃｋｓ値をセットすることができる。ＭｉｎＴｉｃｋｓの値は、鍵付きＲＤ又はＳＴ関数への呼び出しの間に経過することが要求されるＭｉｎＴｉｃｋｓ数である。入力クロック速度が１０ＭＨｚの最大クロック速度と一致する場合を想定する。ＴＳＴの呼び出しの間に１秒の最小値を求めるならば、ＭｉｎＴｉｃｋｓの値は１０００００００にセットされる。２秒のような値は、（１ページ当たりに１回の認証で、１ページが２から３秒毎に生成される）プリンタのようなシステムの場合には全く妥当な値である。
【１２６７】
ステージ４：鍵、ランダムシード、最終チック及び未使用Ｍのプログラム
認証チップは、製造後、状態が不明である。或いは、認証チップは、ある消耗品で既に使用済みであり、別の消耗品で使用するために再プログラムしなければならない。確認証チップの各々は、クリアされ、新しい鍵及び新しい状態データでプログラムされる。認証チップのクリア処理及びその後のプログラミングは、安全なプログラミングステーション環境で行われる。
【１２６８】
信頼されたシステム認証チップのプログラミング
チップが信頼されたシステムチップであるならば、Ｒのシード値が生成される。それは、物理的にランダムなプロセスから抽出された乱数であり、０ではない。以下のタスクは、以下の順に、安全なプログラミング環境で行われる：
リセット チップをリセット
ＣＬＲ［］
Ｌｏａｄ Ｒ
Ｒ（１６０ビットレジスタ）に物理的ランダムデータをロード
ＳＳＩ［Ｋ１，Ｋ２，Ｒ］
ＳＭＴ［ＭｉｎＴｉｃｋｓＳｙｓｔｅｍ］。
【１２６９】
ここで、認証チップはシステムへ挿入するための準備が完了している。認証チップは完全にプログラムされている。システム認証チップがこの時点で盗まれたならば、複製品製造者は、Ｋ１への既知テキスト攻撃に出るために、又はＫ２への部分選択テキスト攻撃に出るために、Ｒ、ＦＫ１［Ｒ］のペアを生成すべくそれらを使用できる。これは、各々が信頼された認証チップを含む多数のシステムの購入と差がない。セキュリティは、認証プロトコルの強度と、Ｋ１及びＫ２のランダム性と、に依存する。
【１２７０】
信頼されない消耗品認証チップのプログラミング
チップが信頼されない消耗品認証チップである場合、プログラミングは信頼されたシステム認証チップのプログラミングとは少し異なる。最初に、Ｒのシード値は０である。それは、Ｍ及びＡｃｃｅｓｓＭｏｄｅの値用の付加的なプログラミングを行う。未使用Ｍ［ｎ］は０でプログラムされ、ランダムＭ［ｎ］はランダムデータでプログラムされる。以下のタスクは、以下の順に、安全なプログラミング環境で行われる：
リセット チップをリセット
ＣＬＲ［］
Ｌｏａｄ Ｒ
Ｒ（１６０ビットレジスタ）に０をロード
ＳＳＩ［Ｋ１，Ｋ２，Ｒ］
Ｌｏａｄ Ｘ
Ｘ（２５６ビットレジスタ）に０をロード
Ｓｅｔ 適当なＭ［ｎ］に対応したＸに物理的ランダムデータをセット
ＷＲ［Ｘ］
Ｌｏａｄ Ｙ
Ｙ（３２ビットレジスタ）に０をロード
Ｓｅｔ 適当なＭ［ｎ］に対応したＹにリードオンリーアクセスモードをセット
ＳＡＭ［Ｙ］
ＳＭＴ［ＭｉｎＴｉｃｋｓＣｏｎｓｕｍａｂｌｅ］。
【１２７１】
ここで、信頼されない消耗品チップは一般的な状態データでプログラムする準備が完了している。認証チップがこの時点で盗まれたならば、攻撃者は、制限選択テキスト攻撃を実行できる。最もよい状況では、Ｍの一部分はリードオンリー（０及びランダムデータ）であり、Ｍの残りは攻撃者によって（ＷＲコマンドを用いて）完全に選択される。攻撃者による多数のＲＤ呼び出しは、限定されたＭに対するＦＫ２［Ｍ｜Ｒ］を獲得する。最悪の状況では、Ｍは攻撃者によって完全に選択される（なぜならば、２５６ビットの全てが状態データに使用されるためである）。しかし、どちらの場合でも、攻撃者はＲの値を選択できない。なぜならば、ＲはＲＮＤへの呼び出しによってシステム認証チップから供給されるためである。選択されたＲを獲得する唯一の方法は、ブルートフォース攻撃である。ステージ４及び５が同じプログラミングステーションで実行された場合（好ましく、且つ理想的な状況）、認証チップはステージ間で取り外せないことに注意すべきである。この場合、認証チップがこの時点で盗まれる可能性はない。認証チップを１回でプログラムするか、又は２回でプログラムするかの決定は、システム／消耗品製造者の要求次第である。
【１２７２】
ステージ５：状態データ及びアクセスモードのプログラム
このステージは、消耗品認証チップの場合だけに必要である。なぜならば、Ｍ及びＡｃｃｅｓｓＭｏｄｅレジスタはシステム認証チップ上では変更できないからである。Ｍ［ｎ］の未使用及びランダム値は既にステージ４でプログラムされている。残りの状態データをプログラムする必要があり、関連したＡｃｃｅｓｓＭｏｄｅ値をセットする。このステージの速度は、ＭｉｎＴｉｃｋｓレジスタに格納された値によって制限されることに注意する必要がある。このステージは、ステージ４とステージ５が実行される場所／時間の物理的場所の違い又は時間の違いを考慮して、ステージ４から分離されている。理想的には、ステージ４及び５は同時に同じプログラミングステーションで実行される。ステージ４は有効認証チップを生成するが、それらに初期状態値（０以外）をロードしない。これは、チップのプログラミングを消耗品の生産ラインの運行と一致させることができる。ステージ５は何回も実行し、毎回、異なる状態データ値及びアクセスモード値を設定することが可能であるが、１回だけ実行され、残りの全ての状態データ値をセットし、残りの全てのアクセスモード値をセットする可能性の方が高い。例えば、生産ラインがセットアップされ、認証チップのバッチ番号及びシリアル番号が生産される物理的な消耗品に応じて生成される。これを一致させることは、状態データが物理的に異なる工場でロードされる場合にはかなり難しくなる。
【１２７３】
ステージ５のプロセスは、最初に、チップが有効消耗品チップであることを保証するために検査を行い、ここでは、認証チップからデータを収集するＲＤが含まれ、次に、初期データ値のＷＲが行われ、更に、新しいデータ値を永久的にセットするためＳＡＭが行われる。これらのステップの概要を次に記載する：
ＩｓＴｒｕｓｔｅｄ＝ＧＩＴ［］；
ＩｓＴｒｕｓｔｅｄがセットされているならば、エラー（間違った種類のチップ！）で終了する；
有効な入力ペアを取得するため有効システムチップのＲＮＤを呼び出し；
有効な入力ペアを渡して、プログラムされるべきチップのＲＤを呼び出し；
認証チップのＲＤからの結果をＸ（２５６ビットレジスタ）にロードする；
Ｘ及び消耗品チップが有効であることを保証するため有効システムチップのＴＳＴを呼び出し；
ＴＳＴが０を返したならば、エラー（システムに対し間違った消耗品チップ）で終了する。
Ｘのビットに初期状態値をセット；
ＷＲ［Ｘ］；
Ｙ（３２ビットレジスタ）に０をロード；
新しい状態値のためのアクセスモードに対応したＹのビットをセット；
ＳＡＭ［Ｙ］。
【１２７４】
勿論、検証（ステージ１から７）は、ステージ４及び５が同じプログラミングステーションで次々と行われる場合には行わなくてもよい。しかし、この検証は、ステージ５がステージ４とは別個のプログラミングプロセスとして実行される他の全ての状況では行われるべきである。これらの認証チップがここで盗まれた場合には、それらは既に特定の消耗品で使用するためにプログラムされている。攻撃者は、盗んだチップを複製消耗品に取り付けることができる。このような盗難は、複製された製品の個数を盗難されたチップの個数に制限する。１回の盗難では、複製品製造者が費用対効果に優れたビジネスを行うために十分な供給数が得られない。このチップの別の用途は、攻撃者が部分選択テキスト攻撃又はブルートフォース攻撃に出るために、認証チップ付きの同数の消耗品を購入しなくても済むことである。このような攻撃が行われても、鍵の特別な安全性の欠陥はない。
【１２７５】
製造
認証チップの回路は物理的攻撃に対抗できなければならない。製造インプリメンテーションガイドラインの概要を説明し、その後に、チップの物理的防御の仕様を（攻撃の順に）説明する。
【１２７６】
製造のガイドライン
製造に関する認証チップの実装用の一般的なガイドラインを以下に列挙する：
標準プロセス
最小サイズ（なるべく）
クロックフィルタ
雑音発生器
タンパー防止及び検出回路
タンパー検出付き保護メモリ
プログラムコードのローディング用ブート回路
鍵データパス用のＦＥＴの特殊実装
可能な場所でのポリシリコン層内のデータコネクション
過小過多電力検出ユニット
テスト回路無し。
【１２７７】
標準プロセス
認証チップは（フラッシュのような）標準的な製造プロセスで実装できる。これは、製造場所の非常に広範囲の選択を可能にさせること
明確であり、且つ正常に動作するテクノロジーを使用すること
コストを低減すること
を充たすために必要である。標準プロセスは物理的な保護メカニズムを可能にさせることに注意する必要がある。
【１２７８】
最小サイズ
認証チップ５３は、低コスト消耗品のための認証メカニズムとして組み込むことができるように製造コストを低くしなければならない。したがって、チップサイズはできるだけ小さいままにすることが望ましい。各認証チップは、８０２ビットの不揮発性メモリが必要である。その上、最適化されたＨＭＡＣ−ＳＨＡ１に必要な記憶容量は１０２４ビットである。チップの残りの部分（状態機械、プロセッサ、ＣＰＵ、又はプロトコル３を実施するために選択されたもの）は、トランジスタの個数が最小限に抑えられ、チップ当たりのコストが最小限になるように最低限に維持される。秘密鍵情報を保有する回路面積、また亜ｈ、鍵に関する情報が漏れる虞のある回路面積も最小限に抑えられるべきである（特殊データパスのための以下のノンフラッシングＣＭＯＳを参照せよ）。
【１２７９】
クロックフィルタ
認証チップ回路は特定のクロック速度レンジで動作するように設計される。ユーザはクロック信号を直接供給するので、攻撃者は、処理中の特定の時点で回路に乱調状態を生じさせ用とする可能性がある。この一例は、高いクロック速度（回路が設計対象とした速度よりも高い）は、ＸＯＲが適切に動作することを妨げ、２個の入力のうちの最初の入力がそのまま返される場合である。このようなスタイルの過渡現象障害攻撃は、秘密鍵情報を復元する際に非常に有効である。ここらか学ぶべきことは、入力クロック信号は信頼できないということである。入力クロック信号は信頼できないので、最大周波数までで動作するように制限されるべきである。これはいろいろな方法で実現できる。クロック信号をフィルタ処理する一つの方法は、「エッジオン」を遅延器へ渡すエッジ検出ユニットを使用することであり、次に、遅延によって入力クロック信号の通過を許可する。図１７４は、クロックフィルタ内のクロック信号フローの説明図である。遅延は、最大クロック速度が特定の周波数（例えば、４ＭＨｚ）になるようにセットされる。この遅延はプログラマブルではなく、固定であることに注意すべきである。フィルタ処理されたクロック信号は、必要に応じて内部で更に分周される。
【１２８０】
雑音発生器
各認証チップは連続した回路雑音を発生する雑音発生器を含む。雑音は、チップの通常の動作からの他の電磁放射と干渉し、雑音をＩｄｄ信号に加える。雑音発生器の設置は、放射波長の長さのために認証チップに問題を起こさない。雑音発生器は、電子雑音、クロックサイクル毎の複数状態変化を発生し、タンパー防止及び検出回路用の疑似ランダムビットソースとして使用される。雑音発生器の簡単な実装は、非零の数でシードされた６４ビットＬＦＳＲである。雑音発生器で使用されるクロックは、できるだけ多くの雑音を発生させるため、チップの最大クロックレートで動く。
【１２８１】
タンパー防止及び検出回路
１組の回路が認証チップへの物理的攻撃のテスト及び防止のために必要である。しかし、実際に攻撃として検出される者は、意図的な物理的攻撃ではないかもしれない。したがって、認証チップ内で以下の２タイプの攻撃、即ち、
物理的攻撃の出現を確信できる場合
物理的攻撃の出現を確信できない場合
を区別することが重要である。
【１２８２】
この２タイプの検出は、検出の結果として実行されることが違う。第１のケース、即ち、物理的攻撃の出現を確信できる場合、フラッシュメモリ鍵情報の消去が目的にかなった動作である。第２のケース、即ち、物理的攻撃の出現を確信できない場合、何かの間違いがあるかもしれない。動作を行うべきではあるが、秘密鍵情報を消去する動作ではない。第２のケースでとるべき適切な動作は、チップリセットである。検出されたものがチップに永久的な損傷を加える攻撃であるならば、次にも同じ状態が出現し、チップは再度リセットする。これに対して、検出されたものがチップの通常の動作環境の一部であるならば、このリセットは鍵を損ねない。
【１２８３】
回路が状況を理解できない事象の良い例は、電源誤動作である。この誤動作は、鍵に関する情報を暴こうとする意図的な攻撃かもしれない。しかし、それは、接続間違い、又は単に、電源遮断シーケンスの開始かもしれない。したがって、チップをリセットだけすることが最良であり、鍵を消去しない。チップが電源遮断中であれば、何も失われない。システムが故障している場合、リセットの繰り返しによって、消費者はシステムを修理する。両方のケースで、消耗品は損なわれていない。回路が状況を理解できる事象の良い例は、チップ内のデータラインの切断である。この攻撃が何らかの方法で検出された場合、これは、チップの故障（製造欠陥）、又は攻撃の結果に限られる。何れのケースでも、秘密情報の消去は、目的にかなった選択すべきステップである。
【１２８４】
この結果として、各認証チップは図示されるように２本のタンパー検出ラインを含む。一方は明確な攻撃用であり、もう一方は攻撃可能性のためのものである。これらのタンパー検出ラインには、多数のタンパー検出テストユニットが接続され、各ユニットは様々な形態のタンパーリングをテストする。その上、タンパー検出ライン及び回路自体は不正に手を加えられないことを保証したい。
【１２８５】
タンパー検出ラインの一方の端は、（一般的な動作回路よりも高速でクロッキングする）疑似ランダムビットのソースである。上記の雑音発生器回路は適当なソースである。生成されたビットは、２種類のパスを通り、一方のパスは原データを搬送し、他方は原データの反転を搬送する。これらのビットを搬送する配線は、一般的なチップ回路（例えば、メモリ、鍵操作回路等）よりも上の層にある。配線はランダムビット発生器もカバーする。ビットは、ＸＯＲゲートによって多数の場所で再結合される。ビットが異なる場合（そうあるべきである）、１が出力され、特定のユニットによって使用される（例えば、メモリ読み出しからの各出力ビットはこのビット値とＡＮＤ演算される）。ラインは、最終的に、フラッシュメモリ消去回路に集まり、そこで、ＸＯＲからの０によって完全な消去がトリガーされる。ラインには多数のトリガーが取り付けられ、各々はチップ上の物理的攻撃を検出する。各トリガーは、ＧＮＤへ繋がれた大型ｎＭＯＳトランジスタを有する。タンパー検出ラインは、このｎＭＯＳトランジスタを物理的に通る。テストが失敗したとき、トリガーはタンパー検出ラインを０にする。ＸＯＲテストは、このクロックサイクル、又は次のクロックサイクル（平均的に）の何れかで失敗し、チップをリセット又は消去する。図１７５は、テストと、消去回路又はリセット回路の何れかに接続されたＸＯＲと、を用いるタンパー検出回路の基本原理の説明図である。
【１２８６】
タンパー検出ラインは、図１７６の大型ｎＭＯＳトランジスタのレイアウトに示されているように、各Ｔｅｓｔの出力トランジスタのドレインを通る。タンパー検出ラインは切断できない。なぜならば、これは、ランダムソースからの１と０の流れを止めるからである。それにより、ＸＯＲテストは失敗する。タンパー検出ラインは、各テストを物理的に通るので、タンパー検出ラインを切断することなく、特定のテストを除去することは不可能である。重要なことは、ＸＯＲは、攻撃の機会を減らすため、タンパー検出ラインに沿って様々な場所からの値を取ることである。図１７７は、チップの様々な部分で使用されるタンパー検出ラインから多数のＸＯＲをとる状況を示している。これらのＸＯＲの各々は、各ユニット又はサブユニットで使用されるチップ正常ビットＣｈｉｐＯＫを生成しているとみなすことができる。
【１２８７】
サンプル用途としては、各ユニットにＯＫビットを設け、これを各サイクルで与えられたＣｈｉｐＯＫビットとＡＮＤ演算することがある。ＯＫビットはリセットで１がロードされる。ＯＫビットが０であるならば、ユニットは次のリセットまで失敗（フェイル）である。タンパー検出ラインが正しく機能するならば、チップは、リセットを行うか、又は全ての鍵情報を消去する。リセット回路又は消去回路が破壊されているならば、このユニットは機能しないので、攻撃者を阻止する。リセットライン及び消去ライン、並びに、関連した回路の行き先は、非常に状況に敏感である。それは、個別のタンパーテストと非常に類似した方法で保護されるべきである。攻撃者がリセット回路に繋がる配線を簡単に切断できるのであれば、リセットパルスを生成しても意味がない。実際の実装形態は、リセットでクリアされるべき項目と、それらの項目をクリアする方法と、に依存する部分が大きい。
【１２８８】
最後に、図１７８は、タンパーラインがチップの雑音発生器回路を保護する様子を示す図である。発生器及びＮＯＴゲートは同じ高さにあり、一方、タンパー検出ラインは発生器よりも高いところを通る。
【１２８９】
タンパー検出付き保護メモリ
秘密情報又はプログラムコードはフラッシュメモリに記憶するだけでは不十分である。フラッシュメモリ及びＲＡＭは、プログラムコード又は鍵情報の特定のビットを変更（又はセット）使用とする攻撃者から保護されなければならない。使用されるメカニズムは、（上述の）タンパー検出回路で使用されているメカニズムに準拠する。ソリューションの第１の部分は、タンパー検出ラインが各フラッシュ又はＲＡＭビットの直ぐ上を確実に通ることである。これは、攻撃者がフラッシュ又はＲＡＭの内容をプローブできないことを保証する。配線の保護部の破損はタンパー検出ラインの切断である。この破損は、消去信号をセットするので、メモリの内容が消去される。タンパー検出ライン上の高周波雑音も受動的な観測の妨げになる。
【１２９０】
フラッシュに対するソリューションの第２の部分は、多重レベルデータ記憶装置を使用し、しかも、それらの多重レベルのうちのサブセットだけを有効ビット表現のために使用することである。一般的に、多重レベルフラッシュ記憶装置が使用されるとき、単一のフローティングゲートが２ビット以上を保持する。例えば、４電圧状態トランジスタは、２ビットを表現できる。最小電圧及び最大電圧がそれぞれ００及び１１で表すことにすると、２個の中間電圧は０１及び１０を表す。認証チップの場合、単一ビットを表現するために２個の中間電圧を使用し、両端の２個は無効状態であるとみなす。攻撃者がゲートの回路を閉じる、又は切断することにより、ビットの状態を強制的にある方向又は別の方向にさせようとした場合に、無効電圧（従って、無効状態）が現れる。
【１２９１】
ＲＡＭに対するソリューションの第２の部分は、パリティビットを使用することである。レジスタのデータ部分は（攻撃後には一致しなくなる）パリティビットを使って検査できる。フラッシュ及びＲＡＭから到来するビットは、共通タンパー検出ラインに接続された（１ビットに一つずつの）多数のテストユニットによって確認される。タンパー検出回路は、データが通過する最初の回路である（したがって、攻撃者によるデータラインの切断を阻止する）。
【１２９２】
プログラムコードのローディング用ブート回路
プログラムコードは、ＲＯＭではなく、多重レベルフラッシュに保持されるべきである。なぜならば、ＲＯＭはテストできない方法で変更されやすいからである。したがって、ブートメカニズムは、プログラムをフラッシュメモリに取り込むために必要である（フラッシュメモリは製造後中間状態になっている）。ブート回路はＲＯＭ内には置かれず、小型の状態機械で十分である。そうでなければ、ブートコードは検出できない方法によって変更される。ブート回路は、全てのフラッシュメモリを消去し、消去が正しく動作したことを確認し、次に、プログラムコードをロードする。フラッシュメモリは、プログラムをローディングする前に消去しなければならない。そうでなければ、攻撃者はチップをブート状態に置き、既存の鍵を抽出しただけのプログラムをロードすることができる。状態機械は、新しいプログラムコードをロードする前に、全てのフラッシュメモリがクリアされていることを保証するため（攻撃者が消去ラインを切断していないことを保証するため）検査を行う。プログラムコードのローディングは、（鍵のような）秘密情報がロードされる前に、安全なプログラミングステーションによって行われる。
【１２９３】
鍵データパス用の特殊なＦＥＴの実装
ＣＭＯＳインバータ（ｎＭＯＳトランジスタと組み合わされたｐＭＯＳトランジスタを含む）場合の通常のＦＥＴ実装の状況が図１７９に示されている。遷移中に、ｎＭＯＳトランジスタとｐＭＯＳトランジスタの両方が中間的な抵抗値をもつ短い期間が存在する。その結果としての電源−グラウンド短絡回路は、電流を一時的に増大させ、実際上、ＣＭＯＳ装置によって消費される電流の大部分を占める。少量の赤外線光が短絡回路の期間に放出され、シリコン基板を介して観測することができる（シリコンは赤外線を透過する）。また、少量の光がトランジスタゲート容量と伝送ライン容量の充電中及び放電中に放出される。
【１２９４】
秘密鍵情報を操作する回路の場合、このような情報は秘匿されなければならない。代替的なノンフラッシングＣＭＯＳ実装が、鍵、又はその鍵に基づいて部分的に計算された値を操作する全てのデータパスのため使用される。二つの重なり合わないクロックφ１及びφ２の使用によって、フラッシュしないメカニズムが得られる。φ１は全てのｎＭＯＳトランジスタの第２ゲートに接続され、φ２は全てのｐＭＯＳトランジスタの第２ゲートに接続される。遷移は、クロックと組み合わされた場合に発生する。φ１及びφ２は重なり合わないので、ｐＭＯＳ及びｎＭＯＳトランジスタは、同時に中間的な抵抗値をとることがない。その構成は図１８０に示されている。
【１２９５】
最後に、通常のＣＭＯＳインバータは、重要なノンフラッシングＣＭＯＳコンポーネントの近傍に配置することができる。これらのインバータは上記のタンパー検出ラインからそれらの入力信号を取り出す。タンパー検出ラインは通常の動作回路の何倍も高速に動作するので、正味の影響は、ノンフラッシングＣＭＯＳコンポーネントの各々の場所付近に高いレートで生じる光バーストである。明るい光は、付近の弱い光の観測を邪魔するので、観測者は、チップそのものでどのようなスイッチング動作が行われているかを検出し得ない。これらの通常のＣＭＯＳインバータは、回路雑音の量を効果的に増加させ、ＳＮ比を低下させ、役に立つＥＭＩを覆い隠す。
【１２９６】
ノンフラッシングＣＭＯＳの使用によって多数の副作用が現れる：
チップの実効速度は、１クロックサイクル当たりのクロック立ち上がり時間の２倍だけ減少する。これは、認証チップの場合、問題にならない；
ノンフラッシングＣＭＯＳによって引き出される電流量が減少する（なぜならば、短絡回路が現れないからである）。しかし、これは、通常のＣＭＯＳインバータの使用によって相殺される；
クロックの配線によってチップ面積が増加し、特に、φ１及びφ２の多数のバージョンが様々な伝搬のレベルを考慮に入れるために要求されるからである。チップ面積の推定量は通常の実装の２倍である；
認証チップのフラッシュしないエリアの設計は、通常のＣＭＯＳ設計を用いた場合よりも多少複雑になる。特に、標準的なセルコンポーネントが使用できず、そのエリアがフルカスタム化されるからである。これは、認証チップのように小さいものの場合、特に、チップ全体をこの方法で保護しなくても構わないときには、問題にならない。
【１２９７】
可能な場所でのポリシリコン層内の配線
どこでも可能であれば、鍵又は秘密データが流れる配線は、ポリシリコン層内に作られるべきである。必要であれば、メタル１に設けられるが、決して（タンパー検出ラインを含む）最上部のメタル層に設けるべきではない。
【１２９８】
過小過多電力検出ユニット
各認証チップは、電源攻撃を妨げるため、過小過多電力検出ユニットが必要である。過小過多電力検出ユニットは、電源誤動作を検出し、電源レベルがある許容範囲に収まることを保証するため、電圧基準に対して電源レベルをテストする。このユニットは、単一の電圧基準と、２個のコンパレータを含む。過小過多電力検出ユニットは、リセットタンパー検出ラインに接続してもよく、これにより、トリガーされたときにリセットを引き起こす。過小過多電力検出ユニットの副作用は、電源遮断中に電圧が降下したとき、リセットがトリガーされ、作業レジスタを消去することである。
【１２９９】
テスト回路無し
認証チップ上のテストハードウェアは簡単に脆弱性を持ち込み得る。その結果として、認証チップは、ＢＩＳＴ又はスキャンパスを含むべきではない。したがって、認証チップは外部テストベクトルを用いてテスト可能にされる。これは、認証チップが複雑ではないので実現可能である。
【１３００】
ＲＯＭ読み出し
この攻撃は、鍵がアドレス指定可能なＲＯＭに記憶されていることに依存する。各認証チップはその認証鍵を、アドレス指定可能なＲＯＭではなく内部フラッシュメモリに記憶しているので、この攻撃は無関係である。
【１３０１】
チップのリバースエンジニアリング
チップのリバースエンジニアリングは、認証の安全性がアルゴリズムに由来している場合に限り有用である。しかし、本発明の認証チップは、アルゴリズムの秘密性ではなく、秘密鍵に依存している。これに対して、本発明の認証アルゴリズムは公開されていて、いずれにしても、大量生産消耗品の攻撃者は、チップの内部の詳細な設計図を獲得する可能性があったと考えられる。これらの要因から見て、チップ自体のリバースエンジニアリングは、記憶されたデータとは対照的に、脅威ではない。
【１３０２】
認証プロセスの不当使用
この攻撃がとり得る形態は幾つかあり、各々の形態は成功の程度に違いがある。全てのケースにおいて、複製品製造者はシステム設計と消耗品設計の両方を入手できると考えられる。ある攻撃者は、認証コードを生成するのではなく、システムを騙して有効なコードを返すチップを構築しようとする。この攻撃は以下の二つの理由から実現不可能である。第１の理由は、システム認証チップ及び消耗品認証チップは、物理的には同じであるとしても、別々にプログラムされている点にある。特に、ＲＤオペコード及びＲＮＤオペコードは同一であり、ＷＲオペコードとＴＳＴオペコードも同様である。システム認証チップはＲＤコマンドを実行できない。なぜならば、全ての呼び出しは、ＲＤではなく、ＲＮＤへの呼び出しとして解釈されるからである。この攻撃が失敗する第２の理由は、別々のシリアルデータラインがシステムからシステム認証チップ及び消耗品認証チップへ設けられるからである。その結果として、どちらのチップも、もう一方へ送信される内容、或いは、もう一方から受信される内容を見ることができないからである。攻撃者が、（消耗品残量をデクリメントする）ＷＲコマンドを無視する複製チップを構築した場合、プロトコル３は、その後のＲＤがＷＲは出現しなかったことを検出することを保証する。システムは、したがって、消耗品を使用しなくなり、攻撃者を阻止する。これは、攻撃者が認証前に接触の欠損をシミュレートした場合にも成り立ち、認証が行われないので、消耗品の使用は発生しない。したがって、攻撃者は、複製消耗品が受け付けられるように各システムを変更する範囲に制限される。
【１３０３】
システムの変更
変更の最も簡単な方法は、システムの認証チップを、ＴＳＴへの呼び出し毎に成功だけを通知するチップと置き換えることである。これは、認証毎に何回もＴＳＴを呼び出し、最初の数回は偽の値を与え、ＴＳＴからの失敗の通知を要求するシステムによって妨げられる。ＴＳＴへの最後の呼び出しは成功することが予想される。ＴＳＴの偽の呼び出しの回数は、ＲＤ、又はシステムクロックから戻された結果の一部分から決定してもよい。残念ながら、攻撃者は、単に、システムを書き換えることができるので、新しいシステム複製認証チップ５３は、消耗品チップ又はクロックから返された結果を監視できる。複製システム認証チップは、監視された値がそのＴＳＴ関数へ与えられたときに、成功しか返さない。複製消耗品はＲＤのハッシュ結果として任意の値を返すことができ、複製システムチップはその値を有効であることを明らかにする。したがって、システムがシステム認証チップを何回も呼び出しても意味がない。なぜならば、書き換え攻撃は、全てのシステムに対してではなく、再配線されたシステムだけに対して正しく動作するからである。システムに対する類似した攻撃の形態は、システムＲＯＭの取り替えである。ＲＯＭプログラムコードは、認証が行われることの無いように変更可能である。これに関しては何もできない。なぜならば、システムは消費者の手にあるからである。勿論、これはあらゆる保証を無効にするが、消費者は、複製消耗品が非常に安価であり、且つ本物の品物よりも簡単に入手できるのであれば、変更する価値があると考えるであろう。
【１３０４】
システム／消耗品製造者は、したがって、この種類の攻撃がどの程度起こり得るかを判断しなければならない。このような調査は、システム及び消耗品の価格構成、システムサービスの頻度、物理的な変更を加えたときの消費者の利益、消費者がその変更を実行するために出向く場所を当然に含む。システムを変更する限界のケースは、複製品製造者が、複製消耗品を必要とする完全な複製システムを提供する場合である。これは、単なる競合、又は特許権の侵害である。いずれにしても、これは認証チップの目的の範囲外であり、複製される技術やサービスに依存する。
【１３０５】
従来のプロービングによるチップ動作の直接視
チップ動作を視察するためには、チップは動作していなければならない。しかし、タンパー防止及び検出回路は、鍵を処理又は保持するチップの区域を覆う。これらの区域を、タンパー防止ラインを通して見ることは不可能である。攻撃者は、単にタンパー防止層を通してチップをスライスできない。なぜならば、そうすることによって、タンパー検出ラインが破断し、電源投入時に全ての鍵を消去するからである。単に消去回路を破壊するだけでは不十分である。なぜならば、認証チップ内の多数のユニットに供給される多数のＣｈｉｐＯＫビット（このとき全て０）は、チップの通常の動作回路の機能を停止させるからである。攻撃のためにチップをセットアップするためには、攻撃者は、タンパー検出ラインを削除し、フラッシュメモリの消去を停止し、ＣｈｉｐＯＫラインを信頼していたコンポーネントを何とかして書き換えることが必要である。たとえ、この全てを実行できたとしても、チップをこのレベルまでスライスする動作は、鍵を保持する不揮発性メモリ内の電荷パターンを殆ど破壊し、プロセスを無益にするであろう。
【１３０６】
不揮発性メモリの直接視
認証チップがフラッシュメモリのフローティングゲートを露出させるようにスライスされ、それらを放電させない場合、鍵は、おそらくＳＴＭ又はＳＫＭを用いて直接視できるであろう。しかし、ゲートを放電させずにチップをこのレベルまでスライスすることは、おそらく不可能である。湿式エッチング、プラズマエッチング、イオンミリング、又は化学機械研磨は、ほぼ確実にフローティングゲート上に存在する小さい電荷を放出する。これは、通常のフラッシュメモリの場合に成り立つが、多重レベルフラッシュメモリの場合にはより確かである。
【１３０７】
状態変化によって生じる光バーストの監視
秘密鍵情報を操作する回路の全ての区域は、上記のノンフラッシングＣＭＯＳに実現される。これは、大部分の光バーストの放出を阻止する。ノンフラッシングＣＭＯＳの直ぐ近くに配置された通常のＣＭＯＳインバータは、キャパシタの充電及び放電によって生じる僅かな放射を見えなくする。インバータはタンパー検出回路に接続されるので、インバータは、ノンフラッシングＣＭＯＳの状態変化毎に何回も（高いクロックレートで）状態を変化する。
【１３０８】
ＥＭＩの監視
上記の雑音発生器は回路雑音を誘起する。雑音は、チップの通常の動作からの他の電磁放射を妨害し、内部データ転送の有意な読み出しが曖昧になる。
【１３０９】
Ｉｄｄ変動の監視
この種の攻撃に対するソリューションは、Ｉｄｄ信号におけるＳＮ比を減少させることである。これは、回路の雑音量を増大させ、信号量を減少させることにより実現される。雑音発生器回路（これは、ＥＭＩ攻撃に対する防御としても機能する）は、Ｉｄｄ中の重要な情報を目立たなくするため、サイクル毎に十分な状態変化を引き起こす。その上、チップの鍵を伝搬するデータパスの特別なノンフラッシングＣＭＯＳ実装は、状態変化が生じたときに電流が流れることを阻止する。これは、信号量を減少させる利点がある。
【１３１０】
差分故障解析
差分故障ビット誤りは、イオン化、マイクロ波放射、又は環境ストレスによって、目標とした形ではなく、取り込まれる。この種の攻撃の最も起こりやすい影響は、フラッシュメモリの変更（無効な状態を引き起こす）又はＲＡＭの変更（不良パリティ）である。無効な状態及び不良なパリティは、タンパー検出回路によって検出され、鍵の消去を生じさせる。タンパー検出ラインは鍵操作回路を覆うので、鍵操作回路に取り込まれたあらゆる誤りは、タンパー検出ラインの誤りによって反映される。タンパー検出ラインが影響されるならば、チップは、継続的にリセットをするか、又は単にパワーアップ時に鍵を消去し、攻撃を無益にする。目標としていない攻撃に頼り、「チップのちょうど良い部分がちょうど良い方法で影響を受ける」ことを望むのではなく、攻撃者は、（上書き攻撃、ゲート破壊等の）目標とした故障を持ち込むことをやってみる方がよい。
【１３１１】
クロック誤作動攻撃
（上記の）クロックフィルタはクロック誤動作攻撃の実現性を除外する。
【１３１２】
電源攻撃
（上記の）過小過大電力検出ユニットは電源攻撃の実現性を除外する。
【１３１３】
ＲＯＭの上書き
認証チップは、プログラムコード、鍵、及び秘密情報を、ＲＯＭではなく、フラッシュメモリに格納する。したがって、この攻撃は可能性がない。
【１３１４】
ＥＥＰＲＯＭ／フラッシュの変更
認証チップは、プログラムコード、鍵、及び秘密情報をフラッシュメモリに格納する。しかし、フラッシュメモリは、２本のタンパー防止及び検出ラインによって覆われている。これらのラインの何れか一方が（ゲートを破壊するプロセスにおいて）破断されると、攻撃はパワーアップ時に検出され、各チップは、（連続的に）リセットするか、又はフラッシュメモリから鍵を消去する。しかし、たとえ、攻撃者が何とかしてフラッシュメモリのビットへアクセスし、特定のビットを保持しているゲートを破壊するか、若しくは、省くことができるとしても、これは、そのビットを強制的に無充電、又はフル充電の状態にする。これらはどちらも、認証チップの多重レベルフラッシュメモリの使用法では無効状態である（二つの中間状態だけが有効である）。データ値がフラッシュから転送されたとき、検出回路は、消去タンパー検出ラインをトリガーさせ、これにより、フラッシュメモリの残りの部分を消去し、チップをリセットする。したがって、ＥＥＰＲＯＭ／フラッシュメモリの変更攻撃は無益である。
【１３１５】
ゲート破壊攻撃
ゲート破壊攻撃は、単一ゲートを変更し、動作中にチップに情報を暴露させる攻撃者の能力に依存している。しかし、秘密情報を操作する回路は、２本のタンパー防止及び検出ラインの一方によって覆われている。これらのラインの何れか一方が（ゲートを破壊するプロセスにおいて）破断されると、攻撃はパワーアップ時に検出され、各チップは、（連続的に）リセットするか、又はフラッシュメモリから鍵を消去する。この種の攻撃に出るためには、攻撃者は、最初に、どのゲートを目標にすべきかを決定するためにチップをリバースエンジニアリングしなければならない。目標ゲートの場所が決定された後、攻撃者は、保護しているタンパー検出ラインを破断し、フラッシュメモリの消去を停止し、ＣｈｉｐＯＫラインを信頼していたコンポーネントを何とかして書き換えることが必要である。回路の書き換えはチップをスライスすることなく実行できず、たとえ、実行できたとしても、チップをこのレベルまでスライスする動作は、鍵を保持する不揮発性メモリ内の電荷パターンを殆ど破壊し、プロセスを無益にするであろう。
【１３１６】
上書き攻撃
上書き攻撃は、鍵の個々のビットを、その前の値を知ることなく、セットし得ることに依存している。それは、従来のプロービング攻撃と同じようにチップをプロービングし、ゲート破壊攻撃と同じようにゲートを破壊することに依存する。これらの両方の攻撃は（それぞれのセクションで説明したように）タンパー防止及び検出回路とＣｈｉｐＯＫラインを使用しているので成功しない。しかし、たとえ、攻撃者が何とかしてフラッシュメモリのビットへアクセスし、特定のビットを保持しているゲートを破壊するか、若しくは、省くことができるとしても、これは、そのビットを強制的に無充電、又はフル充電の状態にする。これらはどちらも、認証チップの多重レベルフラッシュメモリの使用法では無効状態である（二つの中間状態だけが有効である）。データ値がフラッシュから転送されたとき、検出回路は、消去タンパー検出ラインをトリガーさせ、これにより、フラッシュメモリの残りの部分を消去し、チップをリセットする。同じように、ＲＡＭから読み出された改ざんされている値のパリティチェックによって、消去タンパー検出ラインがトリガーされる。したがって、上書き攻撃は無益である。
【１３１７】
残留メモリ攻撃
認証チップ内の作業用レジスタ又はＲＡＭは、電源が取り外されたとき、認証鍵の一部を保持している。作業用レジスタ及びＲＡＭは、電源の取り外し後、ある時間その情報を保持し続ける。チップがスライスされ、レジスタ／ＲＡＭのゲートが、それらを放電させることなく露出されたとき、データは、ＳＴＭを使用して、おそらく直接視できるであろう。第１の防御は、上述の電源誤動作攻撃に対する防御の説明からわかる。電源が取り外されると、リセット状態がメモリのクリアを引き起こすのとちょうど同じように、全てのレジスタ及びＲＡＭがクリアされる。この攻撃が成功する見込みは、フラッシュメモリの読み出しの見込みよりもひくり。ＲＡＭ電荷は（本質的に）フラッシュメモリよりも簡単に失われる。ＲＡＭを明らかにするためのチップのスライス化は、（電荷が、単に、メモリがリフレッシュされていないこと、及びスライス化を実行するために要する時間を原因として失われていないとしても）確実に電荷を失わせる。したがって、この攻撃は無益である。
【１３１８】
チップ窃盗攻撃
認証チップの耐用期間には、区別可能なフェーズが存在する。チップは、以下のステージの何れかのときに盗まれる可能性がある：
製造後、鍵をプログラミングする前；
鍵のプログラミング後、状態データをプログラミングする前；
状態データのプログラミング後、消耗品又はシステムに挿入する前；
システム又は消耗品に挿入された後。
【１３１９】
チップ製造とプログラミングステーションの間の盗難は、複製品製造者にブランクチップを与えるだけである。これは、認証チップの販売を危うくするだけであり、認証チップによって認証されるものはない。プログラミングステーションは、消耗品及びシステム製品鍵をもつ唯一のメカニズムであり、複製品製造者はチップを正しい鍵でプログラミングできない。複製品製造者は、自分専用のシステム及び消耗品用にブランクチップをプログラミングすることは可能であるが、それらの品を見破られずに販売することは困難であろう。盗難の第２の形態は、認証チップが２以上の別個のプログラミングフェーズを通るような状況だけで起こり得る。これは起こり得るが、可能性は低い。いずれにしても、最悪の状況は、状態データがプログラミングされておらず、全てのＭがリード／ライトになっている場合である。このケースでは、攻撃者はチップに対して適応的選択テキスト攻撃に出ることが可能である。ＨＭＡＣ−ＳＨＡ１アルゴリズムはこの攻撃に対抗できる。盗難の第３の形態は、プログラミングステーションと取付工場との間で行われる。認証チップは、既に特定のシステム用、又は特定の消耗品用にプログラムされている。これらのチップの唯一の用途として、泥棒はこれらを複製システム又は複製消耗品に収容する。複製システムは見当違いであり、複製システムは認証チップ５３を必要とさえしないであろう。複製消耗品の場合、このような盗難は、複製品の数を盗み取られたチップの数に制限する。１回の窃盗は、複製品製造者が費用対効果に優れたビジネスを行うために十分な供給数が得られない。盗難の最後の形態は、システム又は消耗品自体の盗難である。盗難が製造者側で発生した場合、物理的セキュリティプロトコルを強化しなければならない。盗難が他の場所で行われた場合、それは、その品の所有者、及び警察又は保険会社だけの問題である。認証チップが使用するセキュリティメカニズムは、消耗品及びシステムが一般の人の支配下にあることを前提としている。その結果として、それらが盗まれても、鍵の安全性に重大な影響はない。
【１３２０】
認証チップ設計
認証チップは、物理的及び論理的外部インタフェースをもつ。物理的インタフェースは認証チップをどのように物理的システムに接続できるかを規定し、論理的インタフェースはシステムがどのように認証チップと通信できるかを規定する。
【１３２１】
物理的インタフェース
認証チップは、小型の４ピンＣＭＯＳパッケージである（実際の内部サイズは、０．２５μｍフラッシュプロセスを使用する約０．３０ｍｍ２である）。４ピンは、グランド（ＧＮＤ）、クロック（ＣＬＫ）、パワー（Ｐｏｗｅｒ）、及びデータ（Ｄａｔａ）である。パワーは公称電圧である。電圧が公称電圧からある量以上変動すると、チップはリセットする。推奨されるクロック速度は４から１０ＭＨｚである。内部回路は、クロック信号をフィルタ処理し、安全最大クロック速度を超えないことを保証する。データは、シリアルデータラインに沿って、同時に１ビットずつ送受信される。チップは、パワーアップ時、パワーダウン時にリセットを実行する。その上、チップ内のタンパー検出及び防止回路は、攻撃が検出された場合、（検出された攻撃に応じて）チップをリセットさせるか、又はフラッシュメモリを消去させる。特殊プログラミングモードは、ＣＬＫ電圧を特定レベルに保持することによってイネーブル状態にされる。これは次のセクションで更に説明される。
【１３２２】
論理的インタフェース
認証チップは、ノーマルモードとプログラミングモードの二つの動作モードを有する。二つのモードが必要になる理由は、動作プログラムコードは、（安全性の理由から）ＲＯＭではなくフラッシュメモリに記憶されるからである。プログラミングモードは、製造後にテスト目的のため使用され、動作プログラムコードを詰め込み、一方、ノーマルモードは、その後のチップの使用のために用いられる。
【１３２３】
プログラミングモード
プログラミングモードはＣＬＫライン上に特定電圧を所定の時間だけ維持することによって有効にされる。チップがプログラミングモードに入るとき、全てのフラッシュメモリは消去される（全ての秘密鍵情報及びプログラムコードを含む）。認証チップは、次に、消去を検証する。消去が成功であるならば、認証チップは、新しいプログラムコードに対応した３８４バイトのデータを受け取る。バイトは、バイト０からバイト３８３の順に転送される。ビットは、ビット０からビット７の順に転送される。３８４バイト全部のプログラムコードがロードされると、認証チップはハングする。消去が成功しなかった場合、認証チップは全くデータをフラッシュメモリにロードすることなくハングする。チップがプログラムされた後、チップを再スタートすることができる。チップがＣＬＫライン上の通常電圧でリセットされたとき、ノーマルモードに入る。
【１３２４】
ノーマルモード
認証チップは、プログラミングモードではないときには、ノーマルモードである。認証チップがノーマルモードでスタートアップしたとき（例えば、パワーアップリセット）、認証チップは、そのときフラッシュメモリのプログラムコード領域に格納されているプログラムを実行する。プログラムコードは、システムと認証チップの間に通信メカニズムを組み込み、システムからのコマンド及びデータを受け取り、出力値を生成する。認証チップはシリアル通信をするので、ビットは同時に１ビットずつ転送される。システムは、簡単なオペレーションコマンドセットによって認証チップと通信する。各コマンドは３ビットオペコードによって定義される。オペコードの解釈は、ＩｓＴｒｕｓｔｅｄビット及びＩｓＷｒｉｔｔｅｎビットの現在値に依存する。
【１３２５】
以下のオペレーションが定義される。
【１３２６】
【表１３０】
0004309954.tif 000157
Ｏｐ＝オペコード、Ｔ＝ＩｓＴｒｕｓｔｅｄ値、Ｗ＝ＩｓＷｒｉｔｔｅｎ値、
Ｍｎ＝ニューモニック、［ｎ］＝パラメータに必要なビット数。
【１３２７】
この表に定義されていないコマンドは、ＮＯＰ（ノーオペレーション）として解釈される。その例には、（ＩｓＴｒｕｓｔｅｄ値又はＩｓＷｒｉｔｔｅｎ値とは無関係である）オペコード１１０及び１１１と、ＩｓＷｒｉｔｔｅｎ＝０のときのＳＳＩ以外のオペコードと、が含まれる。ＲＤ及びＲＮＤのオペコードは同じであり、ＷＲ及びＴＳＴのオペコードも同じであることに注意する必要がある。オペコードの受け取り後に動かされる実際のコマンドは、（ＩｓＷｒｉｔｔｅｎが１である限り）ＩｓＴｒｕｓｔｅｄビットの現在値に依存する。ＩｓＴｒｕｓｔｅｄビットがクリアされているところでは、ＲＤ及びＷＲ関数が呼び出される。ＩｓＴｒｕｓｔｅｄビットがセットされると、ＲＮＤ及びＴＳＴ関数が呼び出される。２組のコマンドは、信頼されている認証チップと信頼されていない認証チップとの間で相互に排他的である。認証チップ上でコマンドを実行するため、（システムのような）クライアントは、コマンドオペコードと、その後に続く、そのオペコードに必要な入力パラメータと、を送る。オペコードは、最下位ビットから最上位ビットまで送られる。例えば、ＳＳＩコマンドを送るため、ビット１、０及び０がこの順に送られる。各入力パラメータも同じ方法で送られ、最初に最下位ビットから送られ、最後に最上位ビットまでが送られる。戻り値はこの方法で読み出され、最初に最下位ビットが読まれ、最後に最上位ビットが読まれる。クライアントは獲得するビット数がわかっていなければならない。
【１３２８】
一部のケースでは、あるチップのコマンドからの出力ビットは、別のチップのコマンドへの入力ビットとしてそのまま供給される。この一例は、ＲＮＤコマンドとＲＤコマンドである。信頼された認証チップ上のＲＮＤへの呼び出しからの出力ビットはシステムによって保持されなくてもよい。その代わりに、システムは、その出力ビットをそのまま信頼されない認証チップのＲＤコマンドの入力へ転送することができる。各コマンドの説明は、それがその場合であるかを示している。各コマンドは後続のセクションで詳細に検討される。一部のアルゴリズムは、常駐レジスタがフラッシュメモリに保持されているので、特別に設計されている。
【１３２９】
レジスタ
認証チップ内のメモリは認証プロトコルによって要求される変数を記憶するため不揮発性メモリを含む。以下の不揮発性メモリ（フラッシュ）変数が定義される。
【１３３０】
【表１３１】
0004309954.tif 000158
アーキテクチャ概要
このセクション・章は、認証チップの必要な機能を実装することができる専用ＣＰＵの上位定義を与える。このＣＰＵは汎用ＣＰＵではないことに注意する必要がある。認証ロジックを実装するためオーダーメードされている。ＷＲＩＴＥ、ＴＳＴ、ＲＮＤ等のような認証チップのユーザが目にする認証コマンドは、ＣＰＵ命令セットでかかれた小型プログラムとして全て実装される。ＣＰＵは、３２ビットのアキュムレータ（殆どのオペレーションで使用される）と、多数のレジスタと、を含む。ＣＰＵは、認証ロジックを実装するため専用に仕立てられた８ビット命令を含む。各８ビット命令は、典型的に、４ビットのオペコードと、４ビットのオペランドと、により構成される。
【１３３１】
動作速度
内部クロック周波数リミッタユニットは、チップが所定の周波数よりも速い速度で動作することを防止する。この周波数は、製造中にチップに組み込まれ、変更不可である。この周波数は約４から１０ＭＨｚであることが推奨される。
【１３３２】
コンポジション及びブロック図
認証チップは以下のコンポーネントを含む。
【１３３３】
【表１３２】
0004309954.tif 000159
図１８１は認証チップの概略ブロック図である。タンパー防止及び検出回路は図示されない。雑音発生器、過小過大電力検出ユニット、及びプログラミングモード検出ユニットは、タンパー防止及び検出回路に接続され、残りのユニットへは接続されない。
【１３３４】
メモリマップ
図１８２はメモリマップの一例を示す図である。認証チップは外部メモリを持たないが、内部メモリを有する。内部メモリは９ビットによってアドレス指定され、３２ビット幅又は８ビット幅である（アドレスに依存する）。３２ビット幅メモリは不揮発性データ、ＨＡＭＣ−ＳＨＡ１のため使用される変数、及び定数を保持するため使用される。８ビット幅メモリは、プログラムと、プログラムによって使用される様々なジャンプテーブルと、を保持するため使用される。アドレス分割（予備メモリレンジを含む）はアドレス生成及び復号化を最適化するため設計される。
【１３３５】
定数
図１８３は定数メモリマップの一例の説明図である。定数領域は３２ビット定数により構成される。これらは、（３２ビットの全部が０、及び３２ビットの全部が１のような）単純な定数、ＨＡＭＣアルゴリズムによって使用される定数、並びに、ＳＨＡ−１アルゴリズムで使用するため必要な定数ｙ０−３及びｈ０−４である。これらの値はリセットによって影響を受けない。定数を利用する唯一のオペコードはＬＤＫである。このケースでは、オペランド及びメモリ配置は、アドレス生成及び復号化を最小限に抑えるため、密接に関連付けられている。
【１３３６】
ＲＡＭ
図１８４はＲＡＭメモリマップの一例の説明図である。ＲＡＭ領域は、認証チップの汎用機能のために必要な３２個のパリティチェック付き３２ビットレジスタを含むが、チップの動作中だけである。ＲＡＭは揮発性メモリであり、一旦電源が取り外されると、値は失われる。実際上、メモリは、（メモリ残留のために）その値をパワーダウン後のある時間は維持するが、パワーアップ後に利用可能であるとは考えられない。これは、この文書の他のセクションで記載されているセキュリティの問題である。ＲＡＭは、ＨＭＡＣ−ＳＨＡ１アルゴリズムで使用される変数、即ち、Ａ−Ｅ、一時変数Ｔ、１６０ビット作業用ハッシュ値のためのスペースＨ、（ＨＭＡＣによって要求される）ハッシュ結果の一時記憶のためのスペースＢ１６０、及び拡張ハッシングメモリの５１２ビット用のスペースＸを含む。全てのＲＡＭ変数は、リセット後に０にクリアされるが、プログラムコードはこれを当てにしてはならない。ＲＡＭアドレスを利用するオペコードは、ＬＤ、ＳＴ、ＡＤＤ、ＬＯＧ、ＸＯＲ及びＰＲＬである。全てのケースで、オペランド及びメモリ配置は、アドレス生成及び復号化を最小限に抑えるため、密接に関連付けられている（マルチワード変数は最上位ワードが先に格納される）。
【１３３７】
フラッシュメモリ−変数
図１８５はフラッシュメモリ変数メモリマップの一例の説明図である。フラッシュメモリ領域は、認証チップ内の不揮発性情報を格納する。フラッシュメモリは、電源の取り外し後もその値を維持し、次に電源が入れられたとき、変化していないことが期待できる。マルチステートフラッシュメモリに保持された不揮発性情報は、２個の１６０ビット鍵（Ｋ１及びＫ２）と、現在ランダム値（Ｒ）と、状態データ（Ｍ）と、ＭｉｎＴｉｃｋｓ値（ＭＴ）と、ＡｃｃｅｓｓＭｏｄｅ値（ＡＭ）と、ＩｓＷｒｉｔｔｅｎ（ＩＳＷ）フラグと、ＩｓＴｒｕｓｔｅｄ（ＩＳＴ）フラグと、を含む。フラッシュ値は、リセットによって変わらないが、プログラミングモードに入ったときに（０に）クリアされる。フラッシュアドレスを利用するオペレーションは、ＬＤ、ＳＴ、ＡＤＤ、ＰＲＬ、ＲＯＲ、ＣＬＲ及びＳＥＴである。全てのケースで、オペランド及びメモリ配置は、アドレス生成及び復号化を最小限に抑えるため、密接に関連付けられている。マルチワード変数Ｋ１、Ｋ２及びＭは、アドレッシングの必要条件のため、最上位ワードから先に格納される。使用されるアドレッシングスキームは、Ｎで始まり、０で終わるインデックスによるベースアドレスオフセットである。このようにして、ＭＮは最初にアクセスされるワードであり、Ｍ０は、ループ処理でアクセスされる最後の３２ビットワードである。マルチワード変数Ｒは、同じインデキシングスキームを使用するＬＦＳＲ生成を簡単にするため、最下位ワードから先に格納される。
【１３３８】
フラッシュメモリ−プログラム
図１８６はフラッシュメモリのプログラムメモリマップの一例の説明図である。第２のマルチステートフラッシュメモリ領域は、３８４×８ビットである。この領域は、ＪＳＲ、ＪＳＩ及びＴＢＲ命令のためのアドレステーブルと、ＤＢＲコマンド用のオフセットと、定数と、プログラム自体と、を格納する。フラッシュメモリは、リセットによって変わらないが、プログラミングモードに入ったときに（０に）クリアされる。一旦、プログラミングモードに入ると、８ビットフラッシュメモリに、新しい３８４バイトの組をロードすることができる。これが終了すると、チップはリセットされ、通常のチップ動作が行われる。
【１３３９】
レジスタ
多数のレジスタが認証チップに定義される。それらは、関数実行中に一時記憶として使用される。一部は算術関数用であり、他の一部はカウンティング及びインデキシングに使用され、その他はシリアルＩ／Ｏのため使用される。これらのレジスタは不揮発性（フラッシュ）メモリに保持しなくてもよい。それらは、（フラッシュメモリとは異なり）消去サイクル無しで読み出し又は書き込みをすることができる。秘密情報を格納する一時記憶レジスタは、タンパー防止及び検出回路並びにパリティチェックによって、物理的攻撃から保護されなければならない。全てのレジスタはリセット後に０にクリアされる。しかし、プログラムコードは特定の状態を前提とすべきではなく、レジスタ値を適切に設定すべきである。これらのレジスタは、タンパー防止及び検出回路のために定義された様々なＯＫビットを含まなくてもよいことに注意する必要がある。ＯＫビットは種々のユニットに散在され、リセット後に１にセットされる。
【１３４０】
サイクル
１ビットサイクル値は、ＣＰＵがフェッチサイクル（０）であるか、実行サイクル（１）であるかを決める。サイクルは、実際には、前のサイクル値を保持する１ビットレジスタから得られる。サイクルは命令セットから直接アクセスできない。それは内部レジスタ専用である。
【１３４１】
プログラムカウンタ
６レベルの深さの９ビットプログラムカウンタアレイ（ＰＣＡ）が定義される。それは、３ビットスタックポインタ（ＳＰ）によってインデキシングされる。現在プログラムカウンタ（ＰＣ）は、現在実行中命令のアドレスを格納し、事実上、ＰＣＡ［ＳＰ］である。更に、９ビットAdrレジスタが定義され、（インデックス付きアクセス、又は間接メモリアクセスのための）現在メモリ基準の分解アドレスを格納する。ＰＣＡ、ＳＰ及びAdrレジスタは、命令セットから直接アクセスできない。これらは内部レジスタ専用である。
【１３４２】
ＣＭＤ
８ビットＣＭＤレジスタは、現在実行中のコマンドを保持するため使用される。ＣＭＤレジスタレジスタは命令セットから直接アクセス不可であるが、内部レジスタ専用である。
【１３４３】
アキュムレータ及びＺフラグ
アキュムレータは３２ビット汎用レジスタである。これは、算術演算への入力の一つとして使用され、メモリレジスタ間で情報を転送するため使用されるレジスタである。Ｚレジスタは１ビットフラグであり、アキュムレータが書き込まれるときに更新される。Ｚレジスタはアキュムレータの零性を格納する。アキュムレータに最後に書き込まれた値が０であるならば、Ｚ＝１であり、最後に書き込まれた値が非０であるならば、Ｚ＝０である。アキュムレータとＺレジスタの両方は命令セットから直接アクセス可能である。
【１３４４】
カウンタ
多数の専用カウンタ／インデックスレジスタが定義される。
【１３４５】
【表１３３】
0004309954.tif 000160
これらの全てのカウンタ・レジスタは、命令セットから直接アクセス可能である。これらに特定の値をロードするための専用命令が存在し、別の命令は、それらをデクリメント又はインクリメントし、或いは、特定のカウンタが零であるかどうかに応じて分岐する。２個の専用フラグ（レジスタではない）がＣ１及びＣ２に関連付けられ、これらのフラグはＣ１又はＣ２の零性を保持する。これらのフラグは、ループ制御のために使用され、以下に列挙される。これれのフラグはレジスタではないが、レジスタと同様にテストできる。
【１３４６】
【表１３４】
0004309954.tif 000161
フラグ
ＣＰＵ動作モードに対応する多数の１ビットフラグが定義される。
【１３４７】
【表１３５】
0004309954.tif 000162
これらの全ての１ビットフラグは命令セットから直接アクセス可能である。専用命令がこれらのフラグをセット及びクリアするため設けられる。
【１３４８】
書き込み完全性のため使用されるレジスタ
【１３４９】
【表１３６】
0004309954.tif 000163
Ｉ／Ｏのため使用されるレジスタ
４個の１ビットレジスタがクライアント（システム）と認証チップの間の通信のため定義される。これらのレジスタは、InBit（入力ビット）、InBitValid（入力ビット有効）、OutBit（出力ビット）、及びOutBitValid（出力ビット有効）である。InBit及びInBitValidは、クライアントがコマンド及びデータを認証チップへ送るための手段を提供する。OutBit及びOutBitValidはクライアントが認証チップから情報を受けるための手段を提供する。クライアントは、コマンド及びパラメータビットを、同時に１ビットずつ認証チップへ送る。認証チップはスレーブ装置であるため、認証チップの観点では：
InBitからの読み出しは、InBitValidがクリアされている間はハングする。InBitValidは、クライアントが次の入力ビットをInBitに書き込むまでクリアされたままである。InBitの読み出しはInBitValidビットをクリアし、次のInBitをクライアントから読み出せるようになる。クライアントは、InBitValidビットがクリアされるまでビットを認証チップに書き込めない；
OutBitへの書き込みは、OutBitValidがセットされている間はハングする。OutBitValidは、クライアントがOutBitからビットを読み出すまでセットされたままである。OutBitの書き込みはOutBitValidビットをセットし、次のOutBitをクライアントが読み出せるようにする。クライアントは、OutBitValidビットがセットされるまで認証チップからビットを読み出せない。
【１３５０】
タイミングアクセスのため使用されるレジスタ
１個の３２ビットレジスタがタイマーとして使用するため定義される。ＭＴＲ（ＭｉｎＴｉｃｋｓＲｅｍａｉｎｉｎｇ）レジスタは、命令が実行されると、その都度デクリメントする。ＭＴＲレジスタが０になると、それは零に留まる。ＭＴＲは１ビットフラグＭＴＲＺに関連付けられ、ＭＴＲＺはＭＴＲの零性を格納する。ＭＴＲＺが１であるならば、ＭＴＲレジスタは零である。ＭＴＲＺが０であるならば、ＭＴＲレジスタは未だ零ではない。ＭＴＲは（リセット後、又は特定の鍵アクセス関数後）常にＭｉｎＴｉｃｋｓ値から始まり、最終的に０まで減少する。ＭＴＲをセットし、ＭＴＲＺを専用命令でテストすることができるが、ＭＴＲの値は命令によって直接読み出せない。
【１３５１】
レジスタの要約
以下のテーブルは（レジスタ名の順に）全ての一時レジスタを要約する。そのテーブルは、レジスタ名と、サイズ（ビット単位）と、その指定されたレジスタがどこにあるかを列挙する。
【１３５２】
【表１３７】
0004309954.tif 000164
命令セット
ＣＰＵは、認証ロジックを実現するため特別に用意された８ビット命令で動作する。８ビット命令の大半は、４ビットオペコードと、４ビットオペランドと、により構成される。上位４ビットはオペコードを含み、下位４ビットがオペランドを含む。
【１３５３】
オペコード及びオペランド（要約）
オペコードは以下の表に要約されている。
【１３５４】
【表１３８】
0004309954.tif 000165
以下の表は、どのオペランドがどのオペコードと共に使用できるかを要約した表である。この表は、オペコードのニューモニックによってアルファベット順に並べられている。各オペランドのバイナリ値は、その次の表に示されている。
【１３５５】
【表１３９】
0004309954.tif 000166
以下のオペランド表は、４ビットオペランドの解釈を示し、全ての４ビットが直接解釈のため使用されている。
【１３５６】
【表１４０】
0004309954.tif 000167
以下の命令は、オペランドの最上位ビットに基づいて選択を行う。
【１３５７】
【表１４１】
0004309954.tif 000168
オペランドの下位３ビットは、オフセット（ＤＢＲ，ＴＢＲ）か、専用テーブル（ＳＣ）からの値であるか、ＬＯＧの場合のように、それらは論理演算のための第２の入力を選択する。解釈は、ＡＤＤ、ＬＤ、及びＳＴオペコードの解釈と一致する。
【１３５８】
【表１４２】
0004309954.tif 000169
ＡＤＤ−アキュムレータへの加算
ニューモニック： ＡＤＤ
オペコード： １０００
用法： ＡＤＤ
値。
【１３５９】
ＡＤＤ命令は、指定されたオペランドを、モジュロー２３２の加法でアキュムレータに加算する。オペランドは、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｔ、ＡＭ、ＭＴ、ＡＥ［Ｃ１］、Ｈ［Ｃ１］、Ｂ１６０［Ｃ１］、Ｒ［Ｃ１］、Ｋ［Ｃ１］、Ｍ［Ｃ１］、又はＸ［Ｎ４］のうちの一つである。また、Ｚフラグはこの演算中に、ロードされた値が零か非零かに応じてセットされる。
【１３６０】
ＣＬＲ−ビットをクリア
ニューモニック： ＣＬＲ
オペコード： ０１１０
用法： ＣＬＲ
フラグ／レジスタ。
【１３６１】
ＣＬＲ命令は、指定された内部フラグ、又はフラッシュメモリレジスタをクリアさせる。フラッシュメモリのケースでは、ＣＬＲ命令はある時間を要するが、次の命令は、フラッシュメモリの消去が終了するまで引き延ばされる。クリアできるレジスタは、ＷＥ及びＫ２ＭＸである。クリアできるフラッシュメモリは、Ｒ、Ｍ［Ｃ１］、Ｇｒｏｕｐ１、及びＧｒｏｕｐ２である。Ｇｒｏｕｐ１は、ＩＳＴ及びＩＳＷフラグである。それらがクリアされると、唯一の有効な上位レベルコマンドはＳＳＩ命令である。Ｇｒｏｕｐ２は、ＭＴ、ＡＭ、Ｋ１及びＫ２レジスタである。Ｒは別個に消去される。なぜならば、ＲはＴＳＴへの呼び出し毎に更新されるからである。また、Ｍは、インデックスメカニズムによって消去され、Ｍの個々の部分を更新することができる。また、対応したＳＥＴ命令がある。
【１３６２】
ＤＢＲ−デクリメント及びブランチ
ニューモニック： ＤＢＲ
オペコード： ０００１
用法： ＤＢＲ
カウンタ、オフセット。
【１３６３】
この命令は、簡単なループを構築するメカニズムを提供する。オペランドのハイビットは、Ｃ１のテストか、Ｃ２のテスト（２個のカウンタ）を選択する。指定されたカウンタが非零であるならば、カウンタはデクリメントされ、所定のオフセットの値（符号拡張）がＰＣに加算される。指定されたカウンタが零であるならば、カウンタはデクリメントされ、処理はＰＣ＋１で継続する。８エントリーのオフセットテーブルがアドレス０１１００００００（プログラムメモリの６４番目のエントリー）に格納される。オフセットの８ビットは符号付き数として取り扱われる。このようにして、０ｘＦＦは−１として扱われ、０ｘ０１は＋１として取り扱われる。典型的に、その値はループで使用するため負である。
【１３６４】
ＪＳＩ−サブルーチン間接ジャンプ
ニューモニック： ＪＳＩ
オペコード： ０１００１
用法： ＪＳＩ（Ａｃｃ）。
【１３６５】
ＪＳＩ命令は、アキュムレータの現在値に依存したサブルーチンへのジャンプを可能にさせる。この命令は、現在ＰＣをスタックへプッシュし、ＰＣに新しい値をロードする。新しいＰＣの上位８ビットはジャンプテーブル２からロードされ（オフセットはアキュムレータの下位５ビットによって与えられる。）、ＰＣの最下位ビットは０にクリアされる。このようにして、全てのサブルーチンは偶数アドレスでスタートしなければならない。スタックは、６個の実行レベル（５回のサブルーチン深さ）を提供する。プログラマは、この深さを超えないこと、又は戻り値が上書きされること（スタックがラップするため）を保証する責任がある。
【１３６６】
ＪＳＲ−サブルーチンジャンプ
ニューモニック： ＪＳＲ
オペコード： ００１
用法： ＪＳＲ
オフセット。
【１３６７】
ＪＳＲ命令は、最も一般的なサブルーチン構造の用法を提供する。この命令は、現在ＰＣをスタックへプッシュし、ＰＣに新しい値をロードする。新しいＰＣの上位８ビットはアドレステーブル１から与えられ、テーブルへのオフセットは５ビットオペランド（３２通りのアドレスを実現できる）によって与えられる。ＰＣの最下位ビットは０にクリアされる。このようにして、全てのサブルーチンは偶数アドレスでスタートしなければならない。スタックは、６個の実行レベル（５回のサブルーチン深さ）を提供する。プログラマは、この深さを超えないこと、又は戻り値が上書きされること（スタックがラップするため）を保証する責任がある。
【１３６８】
ＬＤ−アキュムレータへのロード
ニューモニック： ＬＤ
オペコード： １０１１
用法： ＬＤ
値。
【１３６９】
ＬＤ命令は、指定されたオペランドからアキュムレータにロードする。オペランドは、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｔ、ＡＭ、ＭＴ、ＡＥ［Ｃ１］、Ｈ［Ｃ１］、Ｂ１６０［Ｃ１］、Ｒ［Ｃ１］、Ｋ［Ｃ１］、Ｍ［Ｃ１］、又はＸ［Ｎ４］のうちの一つである。また、Ｚフラグはこの演算中に、ロードされた値が零か非零かに応じてセットされる。
【１３７０】
ＬＤＫ−定数のロード
ニューモニック： ＬＤＫ
オペコード： １１１０
用法： ＬＤＫ
定数。
【１３７１】
ＬＤＫ命令は、アキュムレータに指定された定数をロードする。定数は、ＨＭＡＣ−ＳＨＡ１のために必要な３２ビット値と、汎用処理のために最も有用な全て０及び全て１と、である。したがって、
０ｘ００００００００
０ｘ３６３６３６３６
０ｘ５Ｃ５Ｃ５Ｃ５Ｃ
０ｘＦＦＦＦＦＦＦＦ
又は、Ｃ１でインデックス付けされたｈ及びｙ定数テーブルからの選択肢がある。ｈとｙの定数テーブルは、ＨＭＡＣ−ＳＨＡ１に必要な３２ビットの表形式の定数を保持する。また、Ｚフラグはこの演算中に、ロードされた値が零か非零かに応じてセットされる。
【１３７２】
ＬＯＧ−論理演算
ニューモニック： ＬＯＧ
オペコード： １００１
用法： ＬＯＧ
演算 値。
【１３７３】
ＬＯＧ命令は、アキュムレータと指定された値に対して、３２ビットのビット論理演算を実行する。ＬＯＧ命令によってサポートされる２個の演算は、ＡＮＤ及びＯＲである。ビットＮＯＴ及びＸＯＲ演算は、ＸＯＲ命令によってサポートされる。アキュムレータとＡＮＤ演算又はＯＲ演算される３２ビット値は、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｔ、ＭＴ及びＡＭのうちの一つである。また、Ｚフラグはこの演算中に、（アキュムレータにロードされる）得られた３２ビット値が零か非零かに応じてセットされる。
【１３７４】
ＲＯＲ−右回転
ニューモニック： ＲＯＲ
オペコード： １１００
用法： ＲＯＲ
値。
【１３７５】
ＲＯＲ命令は、アキュムレータを設定されたビット数だけ右へ回転する方法を提供する。アキュムレータの最上部に現れるビット（ビット３１になる）は、アキュムレータの前のビット０の値でもよく、又は（フラグ、又はシリアル入力コネクションのような）外部１ビットフラグからでもよい。回転して溢れたビットはシリアルコネクションから出力してもよく、又は外部フラグと結合してもよい。許容されるオペランドは、InBit、OutBit、ＬＦＳＲ、ＲＬＦＳＲ、ＩＳＴ、ＩＳＷ、ＭＴＲＺ、１、２、２７、及び３１である。また、Ｚフラグはこの演算中に、（アキュムレータにロードされる）得られた３２ビット値が零か非零かに応じてセットされる。最も簡単な形式では、ＲＯＲ命令用のオペランドは、アキュムレータを回転させるビット位置数を示す１、２，２７、３１のうちの一つである。これらのオペランドの場合、外部入力又は出力はなく、アキュムレータのビットが単に右へ回転させられる。オペランドがＩＳＴ、ＩＳＷ及びＭＴＲＺの場合、適切なフラグがアキュムレータの最上位ビットへ転送される。アキュムレータの残りの部分は、１ビット位置だけ右へシフトされ（ビット３１がビット３０になる等）、アキュムレータの最下位ビットはシフトされて溢れる。オペランドがInBitである場合、次のシリアル入力ビットがアキュムレータの最上位ビットへ転送される。次に、InBitValidビットはクリアされる。クライアントから入力ビットが得られない場合、実行は入力ビットが現れるまで一時停止される。アキュムレータの残りの部分は、１ビット位置だけ右へシフトされ（ビット３１がビット３０になる等）、アキュムレータの最下位ビットはシフトされて溢れる。
【１３７６】
オペランドがOutBitである場合、アキュムレータは右へ１ビット位置だけシフトされる。ビット０からシフトで送り出されたビットはOutBitフラグに格納され、OutBitValidフラグがセットされる。したがって、それは、クライアントによる読み出しの準備が完了する。OutBitValidフラグが既にセットされている場合、命令の実行は、OutBitがクライアントによって読み出される（そして、OutBitValidフラグがクリアされる）まで引き延ばされる。ビット３１へシフトされた新しいビットはガーベッジ（実際には、現在のInBitレジスタの値）であると考えられる。最後に、ＲＢ及びＸＢＲオペランドは、ＬＦＳＲと倍精度シフトレジスタの実装を可能にさせる。ＲＢの場合、シフトで送り出されたビット（形式的にビット０）は、ＲＴＭＰレジスタに書き込まれる。ＲＴＭＰレジスタの現在のレジスタはアキュムレータの新しいビット３１になる。数個の３２ビット値に複数のＲＯＲ
ＲＢコマンドを実行すると、倍精度の右回転／シフトが実現される。ＸＲＢは、ＲＢと同様に動作し、ＲＴＭＰレジスタの現在値がアキュムレータオン新しいビット３１になる。しかし、ＸＲＢ命令の場合、形式的にビット０であることが分かっているビットは、（ＲＢ命令の用に）単純にＲＴＭＰを置き換えない。その代わりに、そのビットはＸＯＲとＲＴＭＰ演算され、その結果がＲＴＭＰに格納される。これにより、認証プロトコルによって要求される長いＬＦＳＲを実現できる。
【１３７７】
ＲＰＬ−ビット置換
ニューモニック： ＲＰＬ
オペランド： １１０１
用法： ＲＯＲ
値。
【１３７８】
ＲＰＬ命令は、上位レベルＷＲＩＴＥコマンドを認証チップに組み込むため設計された。この命令は、アキュムレータの上位１６ビットを、（アクセスモード値に依存して）最終的にＭアレイに書き込まれた値で置き換えることを予定している。この命令は、３個のオペランド：Ｉｎｉｔ、ＭＨＩ及びＭＬＯをとる。Ｉｎｉｔオペランドは、全ての内部フラグをセットし、後続の処理のためＡＬＵ内のＲＰＬユニットを準備する。アキュムレータは内部ＡｃｃｅｓｓＭｏｄｅレジスタへ転送される。アキュムレータは、ＷＲＩＴＥコマンドを実行する場合には、ＲＰＬ 
Ｉｎｉｔへの呼び出しの前に、ＡＭフラッシュメモリ場所からロードされるべきであり、ＴＳＴコマンドを実行する場合には、０でロードされるべきである。アキュムレータはそのまま変化しない。ＭＨＩ及びＭＬＯオペランドは、Ｍ［Ｃ１］の上位１６ビット又は下位１６ビットが（常に）アキュムレータの上位１６ビットとの比較に使用されるかどうかを参照する。実行されるＭＨＩ及びＭＬＯ命令の各々は、初期化されたＡｃｃｅｓｓＭｏｄｅ値からの引き続く２ビットを使用する。最初のＭＨＩ又はＭＬＯの実行は最下位２ビットを使用し、次の実行はその次の２ビットを使用し、以下同様である。
【１３７９】
ＲＴＳ−サブルーチンからのリターン
ニューモニック： ＲＴＳ
オペコード： ０１０００
用法： ＲＴＳ。
【１３８０】
ＲＴＳ命令は、直前に実行されたＪＳＲ又はＪＳＩ命令の後の命令で実行を再開させる。したがって、サブルーチンからの復帰と呼ばれる。実際には、この命令は、セーブされたＰＣをスタックからプルし、１を加え、得られたアドレスから実行を再開する。６個の実行レベル（５回のサブルーチン）が提供されるが、ＪＳＲ及びＪＳＩ命令の各々と、ＲＴＳを合わせることはプログラマの責任である。先行するＪＳＲ無しに実行されたＲＴＳは、スタックからプルされたアドレスから実行を開始させる。
【１３８１】
ＳＣ−カウンタセット
ニューモニック： ＳＣ
オペコード： ０１０１
用法： ＳＣ
カウンタ 値。
【１３８２】
ＳＣ命令はカウンタに特定の値をロードするため使用される。オペランドは、カウンタＣ１とＣ２のうちのどちらにロードするかを決める。ロードされるべき値は、２、３、４、７、１０、１５、１９及び３１のうちの一つである。カウンタ値は、ループ処理及びインデックス処理のため使用される。Ｃ１とＣ２の両方は、（ＤＢＲ命令と組み合わされたとき）ループ構造のため使用されるが、一方、Ｃ１だけが倍精度変数の３２ビット部分をインデックス付けするため使用できる。
【１３８３】
ＳＥＴ−ビットセット
ニューモニック： ＳＥＴ
オペコード： ０１１１
用法： ＳＥＴ
フラグ／レジスタ。
【１３８４】
ＳＥＴ命令は、特定のフラグ又はフラッシュメモリの設定を可能にさせる。また、対応したＣＬＲ命令がある。ＷＥオペランド及びＫ２ＭＸオペランドの各々は、後の処理のため指定されたフラグをセットする。ＩＳＴオペランド及びＩＳＷオペランドの各々は、フラッシュメモリの適切なビットをセットし、一方、ＭＴＲオペランドはアキュムレータの現在値をＭＴＲレジスタへ転送する。ＳＥＴ 
Ｎｘコマンドは、Ｎ１からＮ４に以下の定数をロードする。
【１３８５】
【表１４３】
0004309954.tif 000170
参照される各初期Ｘ［Ｎｎ］は、最適化されたＳＨＡ−１アルゴリズムのインデックスＮ１からＮ４に対する初期状態と一致することに注意すべきである。各インデックス値Ｎｎがデクリメントするとき、有効なＸ［Ｎ］がインクリメントする。なぜならば、Ｘ個のワードは、最上位ビットの方からメモリに格納されるからである。
【１３８６】
ＳＴ−アキュムレータを保存
ニューモニック： ＳＴ
オペコード： １１１１
用法： ＳＴ
ロケーション。
【１３８７】
ＳＴ命令は、アキュムレータの現在値を指定されたロケーションに格納する。ロケーションは、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｔ、ＡＭ、ＭＴ、ＡＥ［Ｃ１］、Ｈ［Ｃ１］、Ｂ１６０［Ｃ１］、Ｒ［Ｃ１］、Ｋ［Ｃ１］、Ｍ［Ｃ１］、又はＸ［Ｎ４］のうちの一つである。Ｘ［Ｎ４］オペランドはＮ４インデックスを進める副作用がある。格納が行われた後、Ｎ４はＸアレイの次の要素を指示する。Ｎ４は１ずつデクリメントされるが、Ｘアレイはハイからローへ並べられているので、インデックスをデクリメントすると、アレイ内の次の要素へ進む。格納先がフラッシュメモリである場合、ＳＴ命令の効果は、アキュムレータ内のビットに対応したフラッシュメモリのビットがセットされることである。アキュムレータからの正確な値が格納されることを保証するために、適切なメモリロケーションを先に消去するＣＬＲ命令を確実に使用すべきである。
【１３８８】
ＴＢＲ−テスト及びブランチ
ニューモニック： ＴＢＲ
オペコード： ００００
用法： ＴＢＲ
値 インデックス。
【１３８９】
テスト及びブランチ命令は、アキュムレータが零か非零かをテストし、アキュムレータの現在状態がテスト相手の状態と一致しているならば、所与のアドレスへ分岐する。ＺフラグがＴＲＢテストと一致するならば、ＰＣを９ビット値で置き換え、ここで、ｂｉｔ０＝０であり、上位８ビットはＭＵから与えられる。そうでなければ、ＰＣを１だけインクリメントする。値オペランドは０又は１である。０は、アキュムレータが零であることについてのテストであることを示す。１は、アキュムレータが非零であることについてのテストであることを示す。インデックスオペランドは、テストが成功したときに実行をジャンプさせる場所を示す。オペランドインデックスの残りの３ビットはジャンプテーブル１の最下位８エントリーをインデックス付けする。上位８ビットはテーブルから取り出され、最下位ビット（ビット０）は０にクリアされる。ＣＭＤはリセット時に０にクリアされる。０はＴＢＲ０として翻訳され、これは、アキュムレータ＝０である場合に、アドレスオフセット０に格納されたアドレスへ分岐することを意味する。アキュムレータ及びＺフラグもリセット時にクリアされるので、テストが真であり、正味の効果はジャンプテーブルの０番目のエントリーに格納されたアドレスへのジャンプである。
【１３９０】
ＸＯＲ−排他的論理和
ニューモニック： ＸＯＲ
オペコード： １０１０
用法： ＸＯＲ
値。
【１３９１】
ＸＯＲ演算は、アキュムレータとの３２ビットのビットＸＯＲを実行し、結果をアキュムレータに格納する。オペランドは、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｔ、ＡＭ、ＭＴ、Ｘ［Ｎ１］、Ｘ［Ｎ２］、Ｘ［Ｎ３］又はＸ［Ｎ４］のうちの一つである。また、Ｚフラグは、結果に応じて（即ち、アキュムレータにロードされた値に応じて）、この演算中にセットされる。ビットＮＯＴ演算は、（ＬＤＫ命令を用いて）アキュムレータを０ｘＦＦＦＦＦＦＦＦとＸＯＲ演算することによって実行される。Ｘ［Ｎ］オペランドは、（演算後に）適切なインデックスを次の値へ進める副作用がある。ＸＯＲが行われた後、インデックスはＸアレイの次の要素を指示する。Ｎ４は、ＳＴ 
Ｘ［Ｎ４］命令によって進められる。インデックスは１ずつデクリメントされるが、Ｘアレイはハイからローへ並べられているので、インデックスをデクリメントすると、アレイ内の次の要素へ進む。
【１３９２】
プログラミングモード検出ユニット
プログラミングモード検出ユニットは入力クロック電圧を監視する。クロック電圧が特定の値であるならば、消去タンパー検出ラインはトリガーされ、全ての鍵、プログラムコード、秘密情報等を消去し、プログラムモードに入る。プログラミングモード検出ユニットは通常のＣＭＯＳを用いて実装可能である。なぜならば、鍵はこのユニットを通過しないからである。このユニットはノンフラッシングＣＭＯＳで実現しなくてもよい。プログラミングモード検出ユニットをタンパー検出ラインで覆うべき特別の必要性はない。なぜならば、攻撃者は、ＣＬＲ入力によってチップをプログラミングモードに移すことができるからである。プログラミングモードへ入るための信号として、消去タンパー検出ラインを使用することは、攻撃者が攻撃の一部としてプログラミングモードを使用したい場合に、消去タンパー検出ラインをアクティブにし、且つ機能させなければならないことを意味する。これは、認証チップへの攻撃を非常に困難にさせる。
【１３９３】
雑音発生器
雑音発生器は通常のＣＭＯＳで実現できる。なぜならば、鍵はこのユニットを通らないからである。このユニットはノンフラッシングＣＭＯＳで実現しなくてもよい。しかし、雑音発生器は、両方のタンパー検出及び保護ラインで保護されるべきであり、この結果として、攻撃者がこのユニットを改ざん使用とする場合、チップは、リセットするか、又は全ての秘密情報をクリアする。その上、ＬＦＳＲのビットは、それらが改ざんされていないことを保証するため検証されるべきである（即ち、パリティチェック）。パリティチェックが失敗した場合、消去タンパー検出ラインがトリガーされる。最後に、雑音発生器の６４ビット全部が単一ビットにＯＲ演算される。このビットが０であるならば、消去タンパー検出ラインがトリガーされる。なぜならば、０はＬＦＳＲの無効状態だからである。ＯＫビットセットアップを使用することは意味がない。なぜならば、雑音発生器はタンパー検出及び防止回路だけによって使用されるからである。
【１３９４】
状態機械
状態機械は、ＣＰＵの二つの動作サイクルを生成し、長いコマンドオペレーション中に引き延ばしを行い、オペレーティングサイクル中にオペコード及びオペランドを記憶する。状態機械は通常のＣＭＯＳで実現可能であり、その理由は、鍵がこのユニットを通らないからである。このユニットはノンフラッシングＣＭＯＳで実現しなくてもよい。しかし、オペコード／オペランドのラッチは、パリティチェックされるべきである。状態機械に格納されるロジック及びレジスタは、両方のタンパー検出ラインによって覆われるべきである。これは、実行される命令が攻撃者によって変更されないことを保証する。
【１３９５】
認証チップは、汎用ＣＰＵの高速性及びスループットを要求しない。それは、認証プロトコルを実行できる速さで動作すればよく、それ以上に高速である必要はない。分岐制御を最適化し、又は次のオペコードをフェッチしている間にオペコードを実行する専用回路（及び、それに関連した全ての複雑さ）を具備するよりは、状態機械は、単純化した考え方を採用する。これは、設計時間を最小限に抑え、実装にエラーが起こる可能性を低減することに役立つ。
【１３９６】
状態機械の一般的な動作は、以下のサイクルの組を生成することである：
サイクル０：フェッチサイクル。これは、オペコードがプログラムメモリからフェッチされ、フェッチされたオペコードから実効アドレスが生成されるサイクルである；
サイクル１：実行サイクルこれは、オペランドが（サイクル０で）生成された実効アドレスによってルックアップされ（かもしれない）、オペレーション自体が実行されるサイクルである。
【１３９７】
正常な条件下で、状態機械は、サイクル：０、１、０、１、０、１．．．を生成する。しかし、あるケースでは、状態機械は、引き延ばしを行い、引き延ばし条件が終了するまで、各クロックチックでサイクル０を生成する。引き延ばし条件には、フラッシュサイクルの消去サイクル待ち、クライアントのシリアルデータの読み書きの待機、又は（タンパーリングによる）無効オペコード等が含まれる。フラッシュメモリがそのとき消去中であるならば、次の命令は、フラッシュメモリが消去され尽くすまで実行できない。これは、メモリユニットから送られるＷａｉｔ信号によって判定される。Ｗａｉｔ＝１であるならば、状態機械はサイクル０だけを生成する。シリアルＩ／Ｏ動作を原因とする引き延ばしには、２通りのケースがある：
オペコードがＲＯＲ
OutBitであり、既にOutBitValid＝１であるケース。これは、現在オペレーションは、ビットをクライアントへ出力することを要求するが、クライアントは最後のビットを未だ読み出していないケースである；
オペレーションがＲＯＲ
InBitであり、InBitValid＝０であるケース。これは、現在オペレーションがクライアントからのビットの読み出しを要求するが、クライアントが未だそのビットを供給していないケースである。
【１３９８】
両方のケースで、状態機械は、引き延ばし条件が終了するまで引き延ばしをしなければならない。したがって、次の「サイクル」は、古いサイクル又は前のサイクルと、ＣＭＤ、Ｗａｉｔ、OutBitValid、及びInBitValidの現在値と、に依存する。ＷａｉｔはＭＵに由来し、OutBitValid及びInBitValidはＩ／Ｏユニットに由来する。サイクルが０であるとき、８ビットオペコードはメモリユニットからフェッチされ、８ビットＣＭＤレジスタに収容される。ＣＭＤレジスタの書き込みイネーブルは、−サイクルである。このユニットからの二つの出力は、サイクルとＣＭＤである。両方の値は、認証チップ内の他の全ての処理ユニットへ渡される。１ビットのサイクル値は、各ユニットにフェッチ又は実行サイクルが行われているかどうかを報せ、一方、８ビットのＣＭＤは、各ユニットが特定のユニットに関連したコマンドのための適切な動作を行えるようにする。
【１３９９】
図１８７は、状態機械のコンポーネント間のデータフロー及び関係を示す図であり、同図では、
【１４００】
【表１４４】
0004309954.tif 000171
である。
【１４０１】
Ｏｌｄ及びＣＭＤは、共にリセットで０にクリアされる。この結果によって第１のサイクルは１であり、これは、０ＣＭＤを実行させる。０はＴＢＲ 
０として翻訳され、即ち、Ａｃｃｍｕｌａｔｏｒ＝０ならば、アドレスオフセット０に格納されたアドレスへ分岐する。アキュムレータもリセットで０にクリアされるので、テストは真であり、正味の効果はジャンプテーブルの０番目のエントリーに格納されたアドレスへのジャンプである。２個のＶＡＬユニットがそれらを通過する値を検証するため設計される。各ＶＡＬは、両方のタンパー防止及び検出ラインに接続されたＯＫビットを含む。ＯＫビットはリセットで１にセットされ、サイクル毎に両方のタンパー防止及び検出ラインからのＣｈｉｐＯＫ値とＯＲ演算される。ＯＫビットはそのユニットを通過する各データビットとＡＮＤ演算される。ＶＡＬ１の場合、チップが改ざんされたならば、実効サイクルは常に０である。このようにして、決してサイクル１にならないので、プログラムコードは実行されない。Ｏｌｄが改ざんされたかどうかを検査する必要はない。なぜならば、攻撃者がＯｌｄ状態を止めるならば、チップはそれ以上命令を実行しないからである。ＶＡＬ２の場合、実効８ビットＣＭＤ値は、チップ改ざんされたならば、常に０であり、これは、ＴＢＲ 
０命令である。これは、あらゆるプログラムコードの実効を停止する。ＶＡＬ２は、ＣＭＤが改ざんされていないことを保証するため、ＣＭＤからのビットにパリティチェックを行う。パリティチェックが失敗したならば、消去タンパー検出ラインがトリガーされる。
【１４０２】
Ｉ／Ｏユニット
Ｉ／Ｏユニットは外界とシリアル通信する。認証チップは、スレーブシリアル装置として動作し、クライアントからのシリアルデータを受け取り、コマンドを処理し、得られたデータをクライアントへシリアル送信する。Ｉ／Ｏユニットは通常のＣＭＯＳで実現できる。なぜならば、鍵がこのユニットを通らないからである。このユニットはノンフラッシングＣＭＯＳで実現しなくてもよい。更に、ラッチはパリティチェックしなくてもよい。なぜならば、攻撃者にとってそれらを破壊又は変更する利益がないからである。Ｉ／Ｏユニットは、タンパー検出ラインの何れかが破断された場合、０を出力し０を入力する。これは、攻撃者がリセット及び／又は消去回路を動作禁止状態にした場合に限り有効になる。なぜならば、タンパー検出ラインの何れかを破断することは、リセット又は全フラッシュメモリの消去を生じるからである。
【１４０３】
InBit、InBitValid、OutBit、及びOutBitValidの１ビットレジスタは、クライアント（システム）と認証チップとの間の通信のため使用される。InBit及びInBitValidは、クライアントがコマンド及びデータを認証チップへ送る手段を提供する。OutBit及びOutBitValidは、クライアントが認証チップから情報を得る手段を提供する。チップがリセットされたとき、InBitValid及びOutBitValidは共にクリアされる。クライアントは、同時に１ビットずつ、コマンド及びパラメータビットを認証チップへ送る。認証チップの観点では：
InBitからの読み出しは、InBitValidがクリアされている間はハングする。InBitValidは、クライアントが次の入力ビットをInBitに書き込むまでクリアされたままである。InBitの読み出しはInBitValidビットをクリアし、次のInBitをクライアントから読み出せるようになる。クライアントは、InBitValidビットがクリアされるまでビットを認証チップに書き込めない；
OutBitへの書き込みは、OutBitValidがセットされている間はハングする。OutBitValidは、クライアントがOutBitからビットを読み出すまでセットされたままである。OutBitの書き込みはOutBitValidビットをセットし、次のOutBitをクライアントが読み出せるようにする。クライアントは、OutBitValidビットがセットされるまで認証チップからビットを読み出せない。
【１４０４】
実際のコマンドの引き延ばしは、状態機械によって管理されるが、種々の通信レジスタ及び通信回路がＩ／Ｏユニットに存在する。
【１４０５】
図１８８はＩ／Ｏユニットのコンポーネント間のデータフロー及び関係を示す図である。
【１４０６】
【表１４５】
0004309954.tif 000172
シリアルＩ／Ｏユニットは、データピンを使って外界と外部的に通信する回路を含む。InBitＵｓｅｄ制御信号は、所定のクロックサイクル中にInBitを使用する何れかのユニットによってセットされるべきである（サイクルのあらゆる状態になり得る）。２個のＶＡＬユニットは、タンパー防止及び検出回路に接続された検証ユニットであり、各ＶＡＬはＯＫビットを含む。ＯＫビットはリセットで１にセットされ、サイクル毎に両方のタンパー防止及び検出ラインからのＣｈｉｐＯＫ値とＯＲ演算される。ＯＫビットはそのユニットを通過する各データビットとＡＮＤ演算される。
【１４０７】
ＶＡＬ１の場合、チップが改ざんされたならば、チップからの実効ビット出力は常に０である。このようにして、攻撃者は有用な出力を生成できない。ＶＡＬ２の場合、チップ改ざんされたならば、チップへの実効ビット入力は常に０である。このようにして、攻撃者は有用な入力を選択できない。Ｉ／Ｏユニットのレジスタを検証する必要はない。なぜならば、攻撃者はそれらを破壊又は変更することによる利益がないからである。
【１４０８】
ＡＬＵ
図１８９は、算術論理ユニットの概略ブロック図である。算術論理ユニット（ＡＬＵ）は、３２ビットＡｃｃ（アキュムレータ）レジスタと、簡単な算術及び論理演算用の回路を含む。ＡＬＵ及び全てのサブユニットは、ノンフラッシングＣＭＯＳで実現されるべきである。なぜならば、鍵がその中を通るからである。その上、アキュムレータはパリティチェックされる。ＡＬＵに収容されたロジック及びレジスタは、両方のタンパー検出ラインによってカバーされる。これは、鍵及び中間計算値が攻撃者によって変更されないことを保証する。１ビットのＺレジスタは、アキュムレータの零性を格納する。Ｚ及びアキュムレータレジスタの両方は、リセット後にクリアされる。Ｚレジスタはアキュムレータが更新されたときに更新され、アキュムレータは、ＬＤ、ＬＤＫ、ＬＯＧ、ＸＯＲ、ＲＯＲ、ＲＰＬ及びＡＤＤの何れかのコマンドに対して更新される。各算術及び論理ブロックは、二つの３２ビット入力、即ち、アキュムレータの現在値と、ＭＵの現在３２ビット出力と、に基づいて動作する。ここで、
【１４０９】
【表１４６】
0004309954.tif 000173
である。
【１４１０】
Ａｃｃ及びＺのＷｒｉｔｅＥｎａｂｌｅｓは、（Ｌｏｇｉｃ１により）ＣＭＤ７及びサイクルを考慮するので、これらの２ビットは、出力を選択するためにマルチプレクサＭＸ１により要求されない。ＭＸ１の出力選択は、ＣＭＤのビット６−３だけを要求するので、結果としてより簡単である。
【１４１１】
【表１４７】
0004309954.tif 000174
２個のＶＡＬユニットは、タンパー防止及び検出ラインに接続された検証ユニットであり、各ＶＡＬはＯＫビットを含む。ＯＫビットはリセットで１にセットされ、サイクル毎に両方のタンパー防止及び検出ラインからのＣｈｉｐＯＫ値とＯＲ演算される。ＯＫビットはそのユニットを通過する各データビットとＡＮＤ演算される。ＶＡＬ１の場合、チップが改ざんされたならば、アキュムレータから出力された実効ビットは常に０である。これは、攻撃者がアキュムレータに関する何かを処理することを妨げる。ＶＡＬ１はアキュムレータに対するパリティチェックを実行し、チェックが失敗したならば、消去タンパー検出ラインをセットする。ＶＡＬ２の場合、アキュムレータの実効Ｚ状態は、チップ改ざんされたならば、常に真である。このようにして、攻撃者はループ構造を作成できない。ＡＬＵの残りの機能ブロックは後述する。すべてがフラッシュしないＣＭＯＳで実現されるべきである。
【１４１２】
【表１４８】
0004309954.tif 000175
ＲＰＬ
図１９０はＲＰＬユニットの概略ブロック図である。ＲＰＬユニットはＡＬＵ内のコンポーネントである。これは、認証チップのＲＰＬ
ＣＭＰ機能を実現するため設計されている。ＲＰＬ ＣＭＰコマンドは、ＡｃｃｅｓｓＭｏｄｅの値に基づいて、フラッシュメモリＭへの安全な書き込みに使用するため特に設計された。ＲＰＬユニットは、シフトパルス毎に２ビット右シフトを実行するＡＭＴ（ＡｃｃｅｓｓＭｏｄｅＴｅｍｐ）と呼ばれる３２ビットシフトレジスタと、ＷＲ擬似コードのＥｑＥｎｃｏｕｎｔｅｒｅｄフラグ及びＤｅｃＥｎｃｏｕｎｔｅｒｅｄフラグに直接基づいているＥＥ及びＤＥと呼ばれる１ビットレジスタと、を含む。全てのレジスタはリセット後に０にクリアされる。ＡＭＴは、ＰＲＬ 
ＩＮＩＴコマンドを用いて（アキュムレータを介して）３２ビットＡＭ値がロードされ、ＥＥ及びＤＥは、ＲＰＬ
ＭＨＩへの呼び出し及びＲＰＬ
ＭＬＯへの呼び出しを用いて汎用書き込みアルゴリズムに従ってセットされる。ＥＱブロック及びＬＴブロックはＷＲコマンド擬似コードに記載されている通りの機能を備えている。ＥＱブロックは、２個の１６ビット入力がビット一致であるならば、１を出力し、ビット一致でなければ、０を出力する。ＬＴブロックは、アキュムレータから入力された上位１６ビットがＭＸ２によってＭＵから選択された１６ビット値よりも小さい場合に、１を出力する。比較は符号無しである。オペランドのビットパターンは組み合わせロジックがより簡単化されるように特に選択される。オペランドのビットパターンを利用するので、そのパターンをもう一度列挙する。
【１４１３】
【表１４９】
0004309954.tif 000176
ＭＨＩ及びＭＬＯは、ハイビットがセットされているので、Ｉｎｉｔのビットパターンと簡単に区別することができ、最下位ビットはＭＨＩとＭＬＯを区別するために使用できる。ＥＥフラグ及びＤＥフラグは、ＲＰＬコマンドが発行されるたびに更新される。Ｉｎｉｔステージのため、２個の値を設定し、ＭＨＩ及びＭＬＯのため、ＥＥ及びＤＥの値を適切に更新する。したがって、ＥＥ及びＤＥのためのＷｒｉｔｅＥｎａｂｌｅは以下の通りである。
【１４１４】
【表１５０】
0004309954.tif 000177
３２ビットのＡＭＴレジスタに関して、このレジスタには、ＲＰＬ Ｉｎｉｔコマンドのときに、（ＭＵから読み出された）ＡＭの内容をロードし、ＲＰＬ ＭＬＯコマンド及びＲＰＬ 
ＭＨＩコマンドのためにＡＭＴレジスタを右へ２ビット位置シフトさせる。これは、ＲＰＬオペランドの最上位ビット（ＣＭＤ３）に対して簡単にテストできる。したがって、ＡＭＴレジスタのためのＷｒｉｔｅＥｎａｂｌｅ及びＳｈｉｆｔＥｎａｂｌｅは、以下の通りである。
【１４１５】
【表１５１】
0004309954.tif 000178
Ｌｏｇｉｃ３からの出力は、マルチプレクサＭＸ１への入力としても有用である。なぜならば、それは、現在の２個のアクセスモードビット、又は００（これは、アクセスモードＲＷを表すので、ＤＥ及びＥＥレジスタをリセットさせる）の何れかを通すために使用されるからである。したがって、ＭＸ１は次の通りである。
【１４１６】
【表１５２】
0004309954.tif 000179
ＲＰＬロジックは、アキュムレータの上位１６ビットだけを置換する。下位１６ビットはそのまま通過する。しかし、（Ｍ［０−１５］のうちの一つに対応する）ＭＵからの３２ビットのうちの、上位又は下位１６ビットだけが使用される。したがって、ＭＸ２はＭＨＩとＭＬＯを区別するためにＣＭＤ０をテストする。
【１４１７】
【表１５３】
0004309954.tif 000180
ＤＥレジスタ及びＥＥレジスタを更新するロジックは、ＷＲコマンドの擬似コードと一致する。ＡｃｃｅｓｓＭｏｄｅ値が００（＝ＲＷ、これはＲＰＬ 
ＩＮＩＴ中に出現する）である入力は、ＤＥとＥＥの両方に０（正しい初期値）をロードさせることに注意する必要がある。ＥＥはＬｏｇｉｃ４からの結果がロードされ、ＤＥはＬｏｇｉｃ５からの結果がロードされる。
【１４１８】
【表１５４】
0004309954.tif 000181
アキュムレータの上位１６ビットはＭへ書き込まれるべき値によって置き換えられる。したがって、Ｌｏｇｉｃ６はＷＲコマンド擬似コードからのＷＥフラグと一致する。
【１４１９】
【表１５５】
0004309954.tif 000182
Ｌｏｇｉｃ６からの出力は、マルチプレクサＭＸ３による、アキュムレータからの元の１６ビットと、Ｍ［０−１５］からの値との間の選択を駆動するためそのまま使用される。アキュムレータからの１６ビットが選択された場合（アキュムレータは変更されないで残される場合）、これは、アキュムレータ値がＭ［ｎ］に書き込まれることを意味する。Ｍからの１６ビット値が選択された場合（アキュムレータの上位１６ビットを変更する場合）、これは、Ｍの１６ビット値が変更されないことを意味する。したがって、ＭＸ３は以下の形式をとる。
【１４２０】
【表１５６】
0004309954.tif 000183
ＡＭＴをパリティチェックする意味はない。なぜならば、攻撃者はＭＸ３への入力を強制的に０にする方がよいからである（これにより、攻撃者は任意の値をＭに書き込めるようになる）。しかし、攻撃者がチップ（全てタンパー検出テスト及び回路を含む）をレーザー切断する手間を選ぶならば、ＭＸ３の入力を固定することにより制限選択テキスト攻撃を可能にさせるよりも優れたターゲットがある。
【１４２１】
ＲＯＲ
図１９１は、ＡＬＵのＲＯＲブロックの概略ブロック図である。ＲＯＲユニットは、ＡＬＵ内のコンポーネントである。ＲＯＲユニットは、認証チップのＲＯＲ機能を実現するため設計される。ＲＴＭＰという名前の１ビットレジスタは、ＲＯＲユニットに格納される。ＲＴＭＰはリセットで０にクリアされ、ＲＯＲ 
ＲＢコマンド及びＲＯＲ ＸＲＢコマンド中にセットされる。ＲＴＭＰレジスタは、任意のタップ構造をもつ線形フィードバックシフトレジスタの実装を可能にさせる。ＸＯＲブロックは、２個の１ビット入力、１ビット出力のＸＯＲである。ＲＯＲｎは、ブロックが便宜上示されているが、実際には、マルチプレクサＭＸ３に配線接続される。なぜならば、各ブロックは、単に、右へＮビットシフトされた、３２ビットの書き換えである。３個全てのマルチプレクサ（ＭＸ１、ＭＸ２及びＭＸ３）は８ビットのＣＭＤ値に依存する。しかし、ＲＯＲオペコードのビットパターンはロジック最適化の目的のために並べられる。オペランドのビットパターンを利用するので、このパターンを再度列挙する。
【１４２２】
【表１５７】
0004309954.tif 000184
Ｌｏｇｉｃ１は、ＲＴＭＰにＷｒｉｔｅＥｎａｂｌｅ信号を与えるために使用される。ＲＴＭＰレジスタは、ＲＯＲ 
ＲＢ及びＲＯＲ ＸＯＲコマンドの間だけ書き込まれるべきである。Ｌｏｇｉｃ２は、InBitが使われたときならいつでも、制御信号を与えるために使用される。２個の組み合わせロジックブロックは次の通りである。
【１４２３】
【表１５８】
0004309954.tif 000185
マルチプレクサＭＸ１を用いて、ＲＴＭＰに格納されるビットを選択する。Ｌｏｇｉｃ１は、予めＲＢとＸＲＢの一方へのＣＭＤ入力の範囲を限定する。したがって、これらの二つを区別するため、ＣＭＤ０をテストするだけでよい。以下の表は、ＣＭＤ０とＭＸ１から出力される値との間の関係を表現する。
【１４２４】
【表１５９】
0004309954.tif 000186
マルチプレクサＭＸ２を用いて、アキュムレータ入力のビット０を置換する予定の入力ビットを選択する。ここでは、少しの量の最適化を行う。なぜならば、個別の入力ビットは、典型的に、特定のオペランドに関係するからである。以下御表は、ＣＭＤ３−０とＭＸ２から出力される値との間の関係を表現する。
【１４２５】
【表１６０】
0004309954.tif 000187
最後のマルチプレクサＭＸ３は３２ビット値の最終的な回転を行う。再度、ＣＭＤオペランドのビットパターンが利用される。
【１４２６】
【表１６１】
0004309954.tif 000188
ＭｉｎＴｉｃｋｓユニット
図１９２は、ＭｉｎＴｉｃｋｓユニットのコンポーネント間のデータフロー及び関係を示す図である。ＭｉｎＴｉｃｋｓユニットは、認証チップ内の鍵付きオペレーションの間のプログラマブル最小遅延（カウントダウンを利用）の役目を担う。ＭｉｎＴｉｃｋｓユニットに収容されるロジック及びレジスタは、両方のタンパー検出ラインによってカバーする必要がある。これは、攻撃者が鍵付きの関数への呼び出しの間の時間を変更できないことを保証する。殆ど全てのＭｉｎＴｉｃｋｓユニットは通常のＣＭＯＳで実現可能である。なぜならば、鍵は、殆どのこのユニットを通らないからである。しかし、アキュムレータは、ＳＥＴ 
ＭＴＲ命令で使用される。その結果として、この回路のこの小さい区域は、ノンフラッシングＣＭＯＳで実現しなければならない。ＭｉｎＴｉｃｋｓユニットの残りの部分はノンフラッシングＣＭＯＳで実現しなくてもよい。しかし、ＭＴＲＺラッチ（以下を参照）はパリティチェックしなければならない。
【１４２７】
ＭｉｎＴｉｃｋｓユニットは、ＭＴＲ（ＭｉｎＴｉｃｋｓ残量（ＭｉｎＴｉｃｋｓＲｅｍａｉｎｉｎｇ））という名前の３２ビットレジスタを含む。ＭＴＲレジスタは、次の鍵付き関数を読み出せるまでの残りクロックチック数を格納する。各サイクルに、ＭＴＲの値は、その値が０になるまで１ずつ減少させられる。ＭＴＲが０に達すると、それ以上減少しない。ＭＴＲＺ（ＭｉｎＴｉｃｋｓ残量レジスタ零ＭｉｎＴｉｃｋｓＲｅｇｉｓｔｅｒＺｅｒｏ）という名前の補助的な１ビットレジスタは、ＭＴＲレジスタの現在の零性を反映する。ＭＴＲＺレジスタが０である場合、ＭＴＲＺは１であり、ＭＴＲＺレジスタが０ではない場合、ＭＴＲＺは０である。ＭＴＲレジスタはリセットによってクリアされ、ＳＥＴ 
ＭＴＲコマンドを用いて新しいカウントにセットされ、アキュムレータの現在値をＭＴＲレジスタへ転送する。
【１４２８】
ここで、
【１４２９】
【表１６２】
0004309954.tif 000189
であり、且つ
【１４３０】
【表１６３】
0004309954.tif 000190
である。
【１４３１】
サイクルはＭＴＲ及びＭＴＲＺのＷｒｉｔｅＥｎａｂｌｅに接続されるので、これらのレジスタは実行サイクル中に、即ち、サイクル＝１であるときに限り更新される。２個のＶＡＬユニットは、タンパー防止及び検出ラインに接続された検証ユニットであり、各ＶＡＬはＯＫビットを含む。ＯＫビットはリセットで１にセットされ、サイクル毎に両方のタンパー検出ラインからのＣｈｉｐＯＫ値とＯＲ演算される。ＯＫビットはそのユニットを通過する各データビットとＡＮＤ演算される。ＶＡＬ１の場合、ＭＴＲからの実効出力は０であり、これは、デクリメンターユニットからの出力が全て１であることを示し、これにより、ＭＴＲＺは０のままであり、攻撃者が鍵付き関数を使用することは阻止される。また、ＶＡＬ１は、ＭＴＲレジスタのパリティを検証する。パリティチェックが失敗した場合、消去タンパー検出ラインがトリガーされる。ＶＡＬ２の場合、チップ改ざんされたならば、ＭＴＲＺからの実効出力は０であり、ＭｉｎＴｉｃｋｓＲｅｍａｉｎｉｎｇレジスタは未だ０に到達していないことを示し、これにより、攻撃者が鍵付き関数を使用することは阻止される。
【１４３２】
プログラムカウントユニット
図１９２は、プログラムカウントユニットのブロック図である。プログラムカウントユニット（ＰＣＵ）は、９ビットのＰＣ（プログラムカウンタ）と、分岐及びサブルーチン制御用のロジックと、を含む。プログラムカウントユニットは、通常のＣＭＯＳで実現できる。なぜならば、鍵はこのユニットを通らないからである。このユニットはノンフラッシングＣＭＯＳで実現しなくてもよい。しかし、ラッチはパリティチェックされる。その上、メモリユニットに収容されたロジック及びレジスタは、ＰＣが攻撃者によって変更できないことを保証するため、両方のタンパー検出ラインで覆う必要がある。ＰＣは実際には６レベル×９ビットのＰＣＡ（ＰＣアレイ）として実装され、３ビットのＳＰ（スタックポインタ）レジスタによってインデックス付けされる。ＰＣ及びＳＰレジスタはリセットで全てクリアされ、オペコードに従ってプログラム制御のフロー中に更新される。ＰＣの現在値は、サイクル０（フェッチサイクル）の間にＭＵへ出力される。ＰＣは、実行されるコマンドに基づいてサイクル１（実行サイクル）の間に更新される。殆どのケースで、ＰＣは単に１ずつ増加する。しかし、（サブルーチン、又はその他のジャンプの形式により）分岐が現れたとき、ＰＣはあ多らしい値で置き換えられる。新しいＰＣ値を計算するメカニズムは、処理されるオペコードに依存する。
【１４３３】
ＡＤＤブロックはモジュロー２９の単純なアダーである。入力は、ＰＣ値と、１（ＰＣを１ずつ増加するため）、又は９ビットオフセット（ハイビットがセットされ、下位８ビットはＭＵから）の何れか一方である。“＋１”ブロックは、３ビット入力を使用し、１ずつ増加する（ラップ付き）。“−１”ブロックは、３ビット入力を使用し、１ずつ減少する（ラップ付き）。種々のＰＣ制御の形式は以下の通りである。
【１４３４】
【表１６４】
0004309954.tif 000191
ＪＳＲとＪＳＩ（ＡＣＣ）に対して同じ動作がとられるので、Ｌｏｇｉｃ１でそのケースを具体的に検出する。同じ考え方によって、Ｌｏｇｉｃ２でＪＳＩ 
ＲＴＳを具体的にテストする。
【１４３５】
【表１６５】
0004309954.tif 000192
ＰＣを更新するとき、ＰＣが完全に新しい項目によって置き換えられるべきか、又はアダーの結果によって置き換えられるべきかを決定しなければならない。これは、ＪＳＲ及びＪＳＩ（ＡＣＣ）の場合に成り立つが、テストビットがアキュムレータの状態と一致する限り、ＴＢＲにも成り立つ。ＴＢＲ以外の全ては、Ｌｏｇｉｃ１によってテストされるので、Ｌｏｇｉｃ３はＬｏｇｉｃ１の出力を入力として含む。Ｌｏｇｉｃ３からの出力は、次に、新しいＰＣ値を得るため、マルチプレクサＭＸ２によって使用される。
【１４３６】
【表１６６】
0004309954.tif 000193
【１４３７】
【表１６７】
0004309954.tif 000194
９ビットアダーへの入力は、１ずつ増加するか（普通のケース）、又はＭＵから読み出されたオフセットを加算するか（ＤＢＲコマンド）に依存する。Ｌｏｇｉｃ４はｔｅｓｔを生成する。Ｌｏｇｉｃ４からの出力は、これに応じてマルチプレクサＭＸ３によってそのまま使用される。
【１４３８】
【表１６８】
0004309954.tif 000195
【１４３９】
【表１６９】
0004309954.tif 000196
最後に、どのＰＣエントリーを使用するかについての選択は、ＳＰの現在値に依存する。サブルーチンに入るとき、ＳＰインデックス値はインクリメントされ、サブルーチンから戻るとき、ＳＰインデックス値はデクリメントされる。全てのケースで、且つコマンドをフェッチしたいとき（サイクル０）、ＳＰの現在値を使用する。Ｌｏｇｉｃ１は、サブルーチンに入るときを通知し、Ｌｏｇｉｃ２はサブルーチンから戻るときを通知する。マルチプレクサ選択は、したがって、以下のように定義される。
【１４４０】
【表１７０】
0004309954.tif 000197
２個のＶＡＬユニットは、タンパー防止及び検出ラインに接続された検証ユニットであり、各ＶＡＬはＯＫビットを含む。ＯＫビットはリセットで１にセットされ、サイクル毎に両方のタンパー検出ラインからのＣｈｉｐＯＫ値とＯＲ演算される。ＯＫビットはそのユニットを通過する各データビットとＡＮＤ演算される。両方のＶＡＬユニットは、データビットをパリティチェックし、それらが有効であることを保証する。パリティチェックが失敗した場合、消去タンパー検出ラインがトリガーされる。ＶＡＬ１の場合、ＳＰレジスタからの実効出力は、チップが改ざんされたならば、常に０である。これにより、攻撃者がサブルーチンを実行することは阻止される。ＶＡＬ２の場合、実効ＰＣ出力は、チップが改ざんされたならば、常に０である。これにより、攻撃者がプログラムコードを実行することは阻止される。
【１４４１】
メモリユニット
メモリユニット（ＭＵ）は、認証チップの内部メモリを含む。内部メモリは、９ビットのアドレスによってアドレス指定され、９ビットのアドレスはアドレス生成器ユニットから渡される。メモリユニットは、アドレスに応じて、適切な３２ビット及び８ビット値を出力する。また、メモリユニットは、特殊なプログラミングモードを担い、これにより、プログラムがフラッシュメモリに入力される。メモリユニット全体の内容は、タンパーリングから保護されるべきである。したがって、メモリユニットに収容されたロジック及びレジスタは、両方のタンパー検出ラインによって覆われるべきである。これは、プログラムコード、鍵、及び中間データ値が攻撃者によって変更できないことを保証する。全てのフラッシュメモリは、マルチステートであり、無効電圧で読み出されたときにチェックしなければならない。３２ビットＲＡＭもパリティチェックされるべきである。メモリユニットを通る３２ビットデータパスは、ノンフラッシングＣＭＯＳで実現できる。なぜならば、鍵はそのデータパスに沿って送られるからである。８ビットデータパスは、通常のＣＭＯＳで実現できる。なぜならば、鍵はそのデータパスに沿って送られないからである。
【１４４２】
定数
定数メモリ領域のアドレスレンジは、０００００００００−０００００１１１１である。したがって、レンジは０００００ｘｘｘｘである。しかし、次の４８アドレスが予備であるならば、これは復号化中に利用できる。定数メモリ領域は、アドレスの上位３ビット（Adr８−６＝０００）によって選択され、下位４ビットは組み合わせロジックへ供給され、その４ビットは、以下の通り、３２ビット出力値にマッピングされる。
【１４４３】
【表１７１】
0004309954.tif 000198
ＲＡＭ
３２エントリーの３２ビットＲＡＭのアドレス空間は、００１００００００−００１０１１１１１である。したがって、レンジは００１０ｘｘｘｘｘである。ＲＡＭメモリ領域は、したがって、アドレスの上位４ビット（Adr８−５＝００１０）によって選択され、下位５ビットはアドレス指定する値を選択する。連続的な３２エントリーのアドレス空間が与えられた場合、ＲＡＭは、単純な３２×３２ビットＲＡＭとして簡単に実現できる。ＣＰＵは、特殊な方法でレンジ０００００−１１１１１からの各アドレスを取り扱うが、ＲＡＭアドレスデコーダ自体は、アドレスを特別に取り扱うわけではない。全てのＲＡＭ値はリセットで０にクリアされるが、プログラムコードはこのことを当てにしてはならない。
【１４４４】
フラッシュメモリ−変数
３２ビット幅フラッシュメモリのアドレス空間は、００１１０００００−００１１１１１１１である。したがって、レンジは００１１ｘｘｘｘｘである。フラッシュメモリ領域は、したがって、アドレスの上位４ビット（Adr８−５＝０１１１）によって選択され、下位５ビットはアドレス指定する値を選択する。フラッシュメモリは特別な消去が必要である。フラッシュメモリの消去を完了するためにはかなり長い時間を要する。したがって、Ｗａｉｔ信号は、ＣＬＲコマンドの受信時にフラッシュコントローラの内部にセットされ、要求されたメモリが消去されたときに限りクリアされる。内部的に、特定のメモリレンジの消去ラインは一つに結合され、その結果として、以下の表に示されるように、２ビットだけが要求される。
【１４４５】
【表１７２】
0004309954.tif 000199
フラッシュ値はリセットによって変更されないが、プログラムコードは、ガーベッジ以外では、（製造後に）フラッシュの初期値をとるべきではない。フラッシュアドレスを利用するオペレーションは、ＬＤ、ＳＴ、ＡＤＤ、ＲＰＬ、ＲＯＲ、ＣＬＲ及びＳＥＴである。全てのケースで、オペランド及びメモリ配置は、アドレス生成及び復号化を最小限に抑えるため、密接に連結される。フラッシュメモリの全変数区域は、プログラミングモードへ入ったとき、及び明確な物理的攻撃を検出したときに消去される。
【１４４６】
フラッシュメモリ−プログラム
３８４エントリーの８ビット幅プログラムフラッシュメモリのアドレスレンジは、０１０００００００−１１１１１１１１１である。したがって、レンジは０１ｘｘｘｘｘｘｘ−１１ｘｘｘｘｘｘｘである。ＲＯＭスタートアドレスとアドレスレンジが与えられるならば、復号化は簡単である。ＣＰＵはアドレスレンジの一部を特殊は方法で取り扱うが、アドレスデコーダ自体はアドレスを特別に取り扱うわけではない。フラッシュ値はリセットによって変わらず、プログラムモードへ入ることによってのみクリアされる。製造後、フラッシュ内容はガーベッジであると見なされるべきである。３８４バイトは、プログラミングモードにあるときに限り、状態機械によってロードされる。
【１４４７】
ＭＵのブロック図
図１９３は、メモリユニットのブロック図である。図示されたロジックは、３２ビットデータ及び８ビットデータが別々のコマンドによって要求され、その結果として、復号化のために必要なビットが少なくなるということを利用する。図示されるように、３２ビット出力及び８ビット出力は常に生成される。認証チップの残りの適切なコンポーネントは、単に、実行されるコマンドに依存して、３２ビット値又は８ビット値を使用する。マルチプレクサＭＸ１は、真理表定数、ＲＡＭ、及びフラッシュメモリの選択から出力された３２ビットを選択する。３出力の間で選択するためには、２ビットだけが、即ち、Adr６及びAdr５が要求される。このようにして、ＭＸ２の形式は以下の通りである。
【１４４８】
【表１７３】
0004309954.tif 000200
３２ビットフラッシュメモリの特定の部分を消去するロジックはＬｏｇｉｃ１によって満たされる。消去部分制御信号は、サイクル＝１の間に、メモリの正しい部分へのＣＬＲコマンド中に限りセットされるべきである。単一のＣＬＲコマンドがあるレンジのフラッシュメモリをクリアすることに注意する必要がある。Adr６はＣＬＲのためのアドレスレンジとして十分である。なぜならば、レンジは、有効オペランドに対して常にフラッシュの範囲内に治まり、有効ではないオペランドに対して０である。３２ビット幅フラッシュメモリのレンジ全体は、（攻撃者によって、又は意図的にプログラミングモードに入ることによって）消去検出ラインがトリガーされたときに消去される。
【１４４９】
【表１７４】
0004309954.tif 000201
フラッシュメモリの特定の部分に書き込むためのロジックは、Ｌｏｇｉｃ２によって満たされる。ＷｒｉｔｅＥｎａｂｌｅ制御信号は、サイクル＝１の間に、フラッシュメモリレンジへの適切なＳＴコマンド中に限りセットされるべきである。Adr６−５だけのテストが許容される。なぜならば、ＳＴコマンドだけがフラッシュまたはＲＡＭへ有効に書き込むからである（Adr６−５が００であるならば、Ｋ２ＭＸは０でなければならない。）。
【１４５０】
【表１７５】
0004309954.tif 000202
ＷＥ（ＷｒｉｔｅＥｎａｂｌｅ）フラグは、ＳＥＴ ＷＥコマンドとＣＬＲ 
ＷＥコマンドの実行中にセットされる。Ｌｏｇｉｃ３はこれらの二つのケースをテストする。ＷＥに書き込まれる実際のビットはＣＭＤ４である。
【１４５１】
【表１７６】
0004309954.tif 000203
メモリのＲＡＭ領域へ書き込むためのロジックは、Ｌｏｇｉｃ４によって満たされる。ＷｒｉｔｅＥｎａｂｌｅ制御信号は、サイクル＝１の間に、ＲＡＭメモリレンジへの適切なＳＴコマンド中に限りセットされる。しかし、これは、Ｘ［Ｎ］への書き込みが許可されるかどうかを管理するＷＥフラグによって改ざんされる。Ｘ［Ｎ］レンジはＲＡＭの上位半分であり、これは、Adr４を使用してテストできる。ＲＡＭのフルアドレスレンジとしてAdr６−５だけをテストすることが容認できる。なぜならば、ＳＴコマンドはフラッシュ又はＲＡＭだけに書き込むからである。
【１４５２】
【表１７７】
0004309954.tif 000204
３個のＶＡＬユニットは、タンパー防止及び検出ラインに接続された検証ユニットであり、各ＶＡＬはＯＫビットを含む。ＯＫビットはリセットで１にセットされ、サイクル毎に両方のタンパー防止及び検出ラインからのＣｈｉｐＯＫ値とＯＲ演算される。ＯＫビットはそのユニットを通過する各データビットとＡＮＤ演算される。ＶＡＬユニットは、データビットをパリティチェックし、それらが有効であることを保証する。ＶＡＬ１及びＶＡＬ２は、各データビットの状態をチェックすることにより検証し、ＶＡＬ３はパリティチェックを実行する。妥当性テストが失敗したとき、消去タンパー検出ラインがトリガーされる。ＶＡＬ１の場合、プログラムフラッシュからの実効出力は、チップが改ざんされているならば、常に０である（ＴＢＲ 
０として解釈される）。これは攻撃者が有用な命令を実行することを阻止する。ＶＡＬ２の場合、実効３２ビットは、チップが改ざんされたならば、常に０である。これにより、攻撃者は、鍵、又は中間記憶値を入手できない。８ビットフラッシュメモリは、プログラムコード、ジャンプテーブル、及びその他のプログラム情報を保持するため使用される。３８４バイトのプログラムフラッシュメモリは、（アドレスレンジ０１ｘｘｘｘｘｘｘ−１１ｘｘｘｘｘｘｘを使用して）完全な９ビットのアドレスにより選択される。プログラムフラッシュメモリは、（攻撃者によって、又はプログラミングモード検出ユニットが原因でプログラミングモードに入ることによって）消去検出ラインがトリガーされたときに限り消去される。消去検出ラインがトリガーされたとき、プログラムフラッシュメモリユニット内の小型状態機械は、８ビットフラッシュメモリを消去し、消去を検証し、シリアル入力から新しい内容（３８４バイト）にロードする。以下の擬似コードは、消去検出ラインがトリガーされたときに実効される状態機械ロジックを説明する：
0004309954.tif 000205
プログラミングモード状態機械実行中に、０が８ビット出力にセットされる。０コマンドは、認証チップの残りの部分に、コマンドをＴＢＲ 
０として解釈させる。チップが全部で３８４バイトをプログラムフラッシュメモリへ読み込んだとき、チップはハングする（無限ループに入る）。次に、認証チップはリセットされ、プログラムは正常に使用される。消去は、８ビットプログラムフラッシュメモリの新しい内容をロードするために使用される８ビットレジスタによって検証されることに注意すべきである。これは、攻撃が成功する見込みを低下させるために役立つ。なぜならば、プログラムコードは、消去を認証するため使用されるレジスタが攻撃者によって破壊された場合に、適切にロードされ得ないからである。更に、状態機械全体は、両方のタンパー検出ラインによって保護される。
【１４５３】
アドレス生成器ユニット
アドレス生成器ユニットは、メモリユニット（ＭＵ）へアクセスするための実効アドレスを生成する。サイクル０において、ＰＣは次のオペコードをフェッチするためＭＵへ渡される。アドレス生成器は、サイクル１の実効アドレスを生成するため、戻されたオペコードを解釈する。サイクル１において、生成されるアドレスはＭＵへ渡される。アドレス生成器ユニットに格納されたロジック及びレジスタは、両方のタンパー検出ラインによってカバーされる。これは、攻撃者が生成されたアドレスを変更し得ないことを保証する。殆ど全部のアドレス生成器ユニットは通常のＣＭＯＳで実現できる。なぜならば、鍵が殆どのこのユニットを通らないからである。しかし、アキュムレータの５ビットはＪＳＩアドレス生成で使用される。この結果として、回路のこの小さい区域は、ノンフラッシングＣＭＯＳで実現される。アドレス生成器ユニットの残りの部分は、ノンフラッシングＣＭＯＳで実現しなくてもよい。しかし、カウンタ及び計算されたアドレスのラッチはパリティチェックされるべきである。タンパー検出ラインの何れかが破断しているならば、アドレス生成器ユニットは、各サイクルでアドレス０を生成し、全てのカウンタは０に確定される。これは、攻撃者がリセットを禁止状態にするか、及び／又は、消去回路を禁止状態にした場合に始めて効果がある。なぜならば、正常な状況下では、タンパー検出ラインの破断は、リセット又は全てのフラッシュメモリの消去を生じさせるからである。
【１４５４】
アドレス生成の背景
アドレス生成用ロジックは、種々のオペコードとオペランドの組み合わせを調べることが必要である。オペコード／オペランドと、アドレスとの関係はこのセクションで検討され、アドレス生成器ユニットの基礎として使用される。
【１４５５】
定数
下位４エントリーは、汎用用途、並びに、ＨＭＡＣアルゴリズムのための簡単な定数である。ＬＤＫオペランドの下位４ビットは、これらの４個の値、即ち、００００、０００１、００１０及び００１１のメモリ内アドレスの下位３ビットにそのまま対応する。ｙ定数及びｈ定数もＬＤＫコマンドによってアドレス指定される。しかし、アドレスは、オペランドの下位３ビットをＣ１カウンタ値のインバースでＯＲ演算し、そのままのオペランドの第４ビットを保持することによって生成される。このようにして、ＬＤＫ 
ｙの場合、ｙオペランドは０１００であり、ＬＤＫ ｈの場合、ｈオペランドは１０００である。反転したＣ１値は、ｙに対して０００−０１１の範囲にあり、ｈに対して、０００−１００の範囲にあり、ＯＲ演算結果は正確なアドレスを与える。全ての定数に対して、最終アドレスの上位５ビットは常に０００００である。
【１４５６】
ＲＡＭ
変数Ａ−Ｔは、それらのオペランド値の下位３ビットに直接関係したアドレスをもつ。即ち、ＬＤ、ＳＴ、ＡＤＤ、ＬＯＧ、及びＸＯＲコマンドのオペランド値００００−０１０１の場合、並びに、ＬＯＧコマンドのオペランド値１０００−１１０１の場合、下位３ビットのオペランドアドレスビットは、最終アドレスを生成するため、００１０００の一定上位６ビットアドレスと共に使用される。残りのレジスタ値は、インデックス付きメカニズムによってアクセスできる。変数Ａ−Ｅ、Ｂ１６０及びＨは、Ｃ１カウンタ値によるインデックス付きとしてのみアクセス可能であり、Ｘは、Ｎ１、Ｎ２、Ｎ３及びＮ４によってインデックス付けされる。ＬＤ、ＳＴ及びＡＤＤコマンドの場合、Ｃ１によってインデックス付けされたＡＥのアドレスは、オペランドの下位３ビット（０００）を取り、Ｃ１カウンタ値とＯＲ演算することにより生成される。しかし、Ｈ及びＢ１６０のアドレスは、同じ方法では生成できない（そうでなければ、ＲＡＭアドレス空間は不連続になるであろう）。したがって、簡単な組み合わせロジックは、ＡＥを００００に、Ｈを０１１０に、Ｂ１６０を１０１１に変換する。最終アドレスは、Ｃ１を４ビット値に加算し（４ビット値が得られる）、００１００の一定上位５ビットアドレスを前に付加することによって得られる。最後に、レジスタのＸレンジは、Ｎ１、Ｎ２、Ｎ３及びＮ４によるインデックス付きとしてのみアクセス可能である。ＸＯＲコマンドの場合、インデックス付けのため任意のＮ１−４を使用可能であり、一方、ＬＤ、ＳＴ及びＡＤＤの場合、Ｎ４だけが使用可能である。ＬＤ、ＳＴ及びＡＤＤにおけるＸのオペランドは、ＸＮ４オペランドと同じであるため、オペランドの下位２ビットは、使用すべきＮを選択する。アドレスは、このようにして、００１０１の一定上位５ビット値と、選択されたＮカウンタに由来する下位４ビットとして生成される。
【１４５７】
フラッシュメモリ−変数
変数ＭＴ及びＡＭのアドレスは、関連したコマンドのオペランドから生成される。オペランドの４ビットはそのまま使用され（０１１０及び０１１１）、００１１０の一定上位５ビットアドレスが前に付加される。変数Ｒ１−５、Ｋ１１−５、Ｋ２１−５、及びＭ０−７は、Ｃ１カウンタ値のインバースによるインデックス付きとしてのみアクセス可能である（付加的には、Ｒの場合には実際のＣ１値による）。簡単な組み合わせロジックは、Ｒ及びＲＦを０００００に、Ｋ１又はＫ２がアドレス指定されているかどうかに応じてＫを０１０００又は１１０００に、Ｍ（ＭＨＩ及びＭＬＯを含む）を１００００に変換する。最終アドレスは、Ｃ１を５ビット値とＯＲ演算（又は加算）し（ＲＦの場合には、Ｃ１をそのまま使用し）、００１１の一定上位４ビットを前に付加することによって獲得される。変数ＩＳＴ及びＩＳＷは各々が１ビット値に過ぎないが、任意のビット数によって実装できる。データは、０ｘ００００００００又は０ｘＦＦＦＦＦＦＦＦの何れかとして読み書きされる。それらは、ＲＯＲ、ＣＬＲ及びＳＥＴコマンドだけによってアドレス指定される。ＲＯＲの場合、オペランドの下位ビットは、００１１１１１１の一定上位８ビット値と合成され、ＩＳＴ及びＩＳＷに対して、それぞれ、００１１１１１１１０及び００１１１１１１１が得られる。なぜならば、他のＲＯＲオペランドはメモリを使用せず、ＩＳＴ及びＩＳＷ以外の場合には、返された値は無視できるからである。ＳＥＴ及びＣＬＲの場合、ＩＳＴ及びＩＳＷは、００１１の一定上位４ビットをＩＳＴ（０１００）から１１１１０へのマッピング、及びＩＳＷ（０１０１）から１１１１１へのマッピングと組み合わせることによりアドレス指定される。ＩＳＴ及びＩＳＷは、ＲＡＭからのＥ及びＴと同じオペランド値を共有するので、同じ復号化ロジックを下位５ビットのため使用することが可能である。最終アドレスは、ビット４、３及び１がセットされることを要求する（これは、オペランド値０１０ｘのテストの結果にＯＲ演算することより行われる）。
【１４５８】
フラッシュメモリ−プログラム
プログラムフラッシュメモリ内でルックアップするためのアドレスは９ビットＰＣ（サイクル０の場合）又は９ビットAdrレジスタ（サイクル１の場合）から直接もたらされる。ＴＢＲ、ＤＢＲ、ＪＳＲ及びＪＳＩのようなコマンドは、プログラムメモリ内の特定のアドレスでテーブルに記憶されたデータにしたがってＰＣを変更する。その結果として、アドレス生成は、一部の定数アドレスコンポーネントを利用し、コマンドオペランド（又はアキュムレータ）は実効アドレスの下位ビットを形成する。
【１４５９】
【表１７８】
0004309954.tif 000206
アドレス生成器ユニットのブロック図
図１９４はアドレス生成器ユニットの概略ブロック図である。アドレス生成器ユニットからの一次出力は、以下の表に示されるように、マルチプレクサＭＸ１によって選択される。
【１４６０】
【表１７９】
0004309954.tif 000207
ＣＭＤデータとＭＵからの８ビットを区別することが重要である：
サイクル０では、８ビットデータラインは、後のサイクル１で実行されるべき次の命令を保持する。この８ビットコマンド値は実効アドレスをデコードするため使用される。これに対して、ＣＭＤの８ビットデータは前の命令を保持するので、無視されるべきである；
サイクル１では、ＣＭＤラインは現在実行中の命令（サイクル０中に８ビットデータラインに保持されていた命令）を保持し、一方、８ビットデータラインは命令からの実効アドレスのデータを保持する。ＣＭＤデータはサイクル１中に実行されなければならない。
【１４６１】
したがって、ＭＵ又はＣＭＤからの９ビットデータの選択は、以下の表に示されるようにマルチプレクサＭＸ３によって行われる。
【１４６２】
【表１８０】
0004309954.tif 000208
９ビットAdrレジスタはサイクル０毎に更新されるので、AdrのＷｒｉｔｅＥｎａｂｌｅは〜サイクルに接続される。カウンタユニットはカウンタＣ１、Ｃ２（内部的に使用される）と、選択されたＮインデックスを生成する。その上、カウンタユニットは、プログラムカウンタユニットによって使用されるフラグＣ１Ｚ及びＣ２Ｚを出力する。様々な＊ＧＥＮユニットは、サイクル０中に、特有のコマンドタイプのアドレスを生成し、マルチプレクサＭＸ２は、ＰＣ（即ち、８ビットデータライン）によってプログラムメモリから読み出されるようなコマンドに基づいてそれらの間で選択を行う。生成された値は以下の通りである。
【１４６３】
【表１８１】
0004309954.tif 000209
マルチプレクサＭＸ２は以下の選択規準をもっている。
【１４６４】
【表１８２】
0004309954.tif 000210
ＶＡＬ１ユニットは、タンパー防止及び検出回路に接続された検証ユニットである。それはＯＫビットを含み、ＯＫビットはリセットで１にセットされ、サイクル毎に両方のタンパー防止及び検出ラインからのＣｈｉｐＯＫ値とＯＲ演算される。ＯＫビットは、使用可能前の９ビットの実効アドレスとＡＮＤ演算される。チップが改ざんされているならば、アドレス出力は常に０であり、これにより、攻撃者はメモリの他の部分へのアクセスが妨げられる。ＶＡＬ１ユニットは、実効アドレスビットにパリティチェックを実行し、それらが改ざんされていないことを保証する。パリティチェックが失敗であるならば、消去タンパー検出ラインがトリガーされる。
【１４６５】
ＪＳＩＧＥＮ
図１９５はＪＳＩＧＥＮユニットの概略ブロック図である。ＪＳＩＧＥＮユニットはＪＳＩ
ＡＣＣ命令のためのアドレスを生成する。実効アドレスは、単に、
ＪＳＩテーブル（０１０１）用のアドレスの４ビット上位部分と、
アキュムレータ値の下位５ビットと、
の連結である。
【１４６６】
アキュムレータは他の時点（ジャンプアドレスが生成されないとき）で鍵を保持することがあるので、その値は秘匿されなければならない。その結果として、このユニットはノンフラッシングＣＭＯＳで実現される。マルチプレクサＭＸ１は、単に、コマンドがＪＳＩＧＥＮであるかどうかに基づいて、アキュムレータからの下位５ビット又は０の間で選択を行う。マルチプレクサＭＸ１は以下の選択規準をもっている。
【１４６７】
【表１８３】
0004309954.tif 000211
ＪＳＲＧＥＮ
図１９６はＪＳＲＧＥＮユニットの概略ブロック図である。ＪＳＲＧＥＮユニットはＪＳＲ及びＴＢＲ命令のためのアドレスを生成する。実効アドレスは、単に、
ＪＳＲテーブル（０１００）用のアドレスの４ビット上位部分と、
オペランドからのテーブル内のオフセット（ＪＳＲコマンド用の３ビットと、ＴＢＲ用の３ビット＋定数０ビット）と、
の連結からもたらされる。ここで、Ｌｏｇｉｃ１は実効アドレスのビット３を生成する。このビットはＪＳＲの場合にはビット３であり、ＴＢＲの場合には０である。
【１４６８】
【表１８４】
0004309954.tif 000212
ＪＳＲ命令はビット５に１があるので（これに対して、ＴＢＲはこのビットが０である）、これをビット３とＡＮＤ演算することにより、ＪＳＲの場合にはビット３を生成し、ＴＢＲの場合には０を生成する。
【１４６９】
ＤＢＲＧＥＮ
図１９７は、ＤＢＲＧＥＮユニットの概略ブロック図である。ＤＢＲＧＥＮユニットはＤＢＲ命令のためのアドレスを生成する。実効アドレスは、
ＤＢＲテーブル（０１１０００）用のアドレスの６ビット上位部分と、
オペランドの下位３ビットと、
の連結からもたらされる。
【１４７０】
ＬＤＫＧＥＮ
図１９８は、ＬＤＫＧＥＮユニットの概略ブロック図である。ＬＤＫＧＥＮユニットはＬＤＫ命令のためのアドレスを生成する。実効アドレスは、
ＬＤＫテーブル（０００００）用のアドレスの５ビット上位部分と、
オペランドのハイビットと、
オペランドの下位３ビット（下位が定数の場合）、又はＣ１とＯＲ演算されたオペランドの下位３ビット（インデックス付き定数の場合）と
の連結からもたらされる。
【１４７１】
ＯＲ２ブロックは、Ｃ１の３ビットを、ＭＵからの８ビットデータ出力からの下位３ビットとＯＲ演算するだけである。マルチプレクサＭＸ１は、オペランドの上位ビットがセットされているか、又はセットされていないかに基づいて、実際のデータビットと、Ｃ１がＯＲ演算されたデータビットとの間で選択を行うだけである。マルチプレクサへのセレクタ入力は、簡単なＯＲゲートであり、ｂｉｔ２をｂｉｔ３とＯＲ演算する。マルチプレクサＭＸ１は以下の選択規準をもっている。
【１４７２】
【表１８５】
0004309954.tif 000213
ＲＰＬＧＥＮ
図１９９は、ＲＰＬＧＥＮユニットの概略ブロック図である。ＲＰＬＧＥＮユニットはＲＰＬ命令のためのアドレスを生成する。Ｋ２ＭＸが０であるとき、実効アドレスは定数０００００００００である。Ｋ２ＭＸが１であるとき（Ｍからの読み出しが有効な値を返すことを示す）、実効アドレスは、
Ｍ（００１１１０）用のアドレスの６ビット上位部分と、
Ｃ１の現在値の３ビットと、
の連結からもたらされる。
【１４７３】
マルチプレクサＭＸ１は、Ｋ２ＭＸの現在値に基づいて、２個のアドレスの間で選択を行う。したがって、マルチプレクサＭＸ１は以下の選択規準をもっている。
【１４７４】
【表１８６】
0004309954.tif 000214
ＶＡＲＧＥＮ
図２００は、ＶＡＲＧＥＮユニットの概略ブロック図である。ＶＡＲＧＥＮユニットはＬＤ、ＳＴ、ＡＤＤ、ＬＯＧ及びＸＯＲ命令のためのアドレスを生成する。Ｋ２ＭＸ 
１ビットフラグは、Ｍからの読み出しが定数０アドレス（０を返すが、書き込み不可である）にマッピングされるか、オペランドがＫを指定したとき、Ｋ１とＫ２のどちらがアクセスされるか、を決定するため使用される。４ビットアダーブロックは２組の４ビット入力をとり、モジュロー２４の加法で、４ビットの出力を生成する。シングルビットレジスタＫ２ＭＸは、ＣＬＲ 
Ｋ２ＭＸ命令、又はＳＥＴ Ｋ２ＭＸ命令の実行中だけに書き込まれる。Ｌｏｇｉｃ１は、これらの条件に基づいてＫ２ＭＸ
ＷｒｉｔｅＥｎａｂｌｅをセットする。
【１４７５】
【表１８７】
0004309954.tif 000215
ＳＥＴ命令中にＫ２ＭＸ変数に書き込まれるビットは１であり、ＣＬＲ命令中は０である。入力ビットのソースとして、オペコードの下位ビット（ｂｉｔ４）を使用するのが好都合である。アドレス生成中に、組み合わせロジックとして実装された真理表は、以下の通り、ベースアドレスの一部を決定する。
【１４７６】
【表１８８】
0004309954.tif 000216
真理表は５ビットの出力を生成するが、下位４ビットは４ビットアダーへ送られ、そこで、下位４ビットはインデックス値（Ｃ１、Ｎ又はオペランド自体の下位３ビット）に加算される。最上位ビットはアダーへ送られ、５ビット結果を生成するために、アダー結果からの４ビット結果の前に付加される。アダーへの第２の入力はマルチプレクサＭＸ１に由来し、マルチプレクサＭＸ１は、Ｃ１、Ｎ、及びオペランド自体の下位３ビットからインデックス値を選択する。Ｃ１は３ビットしかないが、４番目のビットは定数０である。マルチプレクサＭＸ１は以下の選択規準をもっている。
【１４７７】
【表１８９】
0004309954.tif 000217
実効アドレスの第６ビット（ｂｉｔ５）は、ＲＡＭアドレスの場合に０であり、フラッシュメモリアドレスの場合に１である。フラッシュメモリアドレスは、ＭＴ、ＡＭ、Ｒ、Ｋ、及びＭである。ｂｉｔ５の計算はＬｏｇｉｃ２によって与えられる。
【１４７８】
【表１９０】
0004309954.tif 000218
定数１ビットが表現され、実効アドレスは全部で７ビットになる。これらのビットは、Ｋ２ＭＸが０でなく、命令がＬＤ、ＡＤＤ又はＳＴ 
Ｍ［Ｃ１］ではない限り、実効アドレスを形成する。後者では、実効アドレスは定数アドレス０００００００である。両方のケースで、２個の０ビットが最終的な９ビットアドレスを形成するため前に追加される。この計算は、以下に示され、Ｌｏｇｉｃ３及びマルチプレクサＭＸ２によって行われる。
【１４７９】
【表１９１】
0004309954.tif 000219
【１４８０】
【表１９２】
0004309954.tif 000220
ＣＬＲＧＥＮ
図２０１は、ＣＬＲＧＥＮユニットの概略ブロック図である。ＣＬＲＧＥＮユニットはＣＬＲ命令のためのアドレスを生成する。実効アドレスは常に、有効メモリアクセスオペランド用のフラッシュメモリにあり、無効オペランドに対して０である。ＣＬＲ 
Ｍ［Ｃ１］命令は、（ＶＡＲＧＥＮユニットに保持された）Ｋ２ＭＸフラグの状態とは無関係に、常に、Ｍ［Ｃ１］を消去する。真理表は、単純な組み合わせロジックであり、以下の関係を実現する。
【１４８１】
【表１９３】
0004309954.tif 000221
真理表に必要なロジックを削減することは簡単である。なぜならば、全部で４種類の主要なケースにおいて、実効アドレスの最初の６ビットは００であり、その後にオペランド（ｂｉｔ３−０）が続く。
【１４８２】
ＢＩＴＧＥＮ
図２０２は、ＢＩＴＧＥＮユニットの概略ブロック図である。ＢＩＴＧＥＮユニットはＲＯＲ及びＳＥＴ命令のためのアドレスを生成する。実効アドレスは常に、有効メモリアクセスオペランド用のフラッシュメモリにあり、無効オペランドに対して０である。ＲＯＲ及びＳＥＴ命令は、ＩＳＴ及びＩＳＷフラッシュメモリアドレスだけにアクセスし（オペランドの残りはレジスタにアクセスする）、簡単な組み合わせロジック真理表はアドレス生成に十分である。
【１４８３】
【表１９４】
0004309954.tif 000222
カウンタユニット
図Ｙ３７は、カウンタユニットの概略ブロック図である。カウンタユニットは、カウンタＣ１、Ｃ２（内部で使用）と、選択されたＮインデックスと、を生成する。更に、カウンタユニットは、外部で使用するための出力フラグＣ１Ｚ及びＣ２Ｚを出力する。レジスタＣ１及びＣ２は、ＤＢＲ命令又はＳＣ命令のターゲットであるときに更新される。オペランドのハイビット（実効コマンドのｂｉｔ３）は、Ｃ１とＣ２の間で選択を行う。Ｌｏｇｉｃ１及びＬｏｇｉｃ２は、それぞれ、Ｃ１及びＣ２のためのＷｒｉｔｅＥｎａｂｌｅを判定する。
【１４８４】
【表１９５】
0004309954.tif 000223
シングルビットフラグＣ１Ｚ及びＣ２Ｚは、それらのマルチビットＣ１及びＣ２の対応した部分のＮＯＲ演算によって生成される。このようにして、Ｃ１Ｚは、Ｃ１＝０のときに１であり、Ｃ２Ｚは、Ｃ２＝０のときに１である。ＤＢＲ命令中に、Ｃ１又はＣ２の何れかの値が１ずつデクリメントされる（ラップ付き）。デクリメンターユニットへの入力は、以下の通り、マルチプレクサＭＸ２によって選択される。
【１４８５】
【表１９６】
0004309954.tif 000224
Ｃ１又はＣ２に書き込まれた実際の値は、ＤＢＲ命令又はＳＣ命令が実行されたかどうかに依存する。マルチプレクサＭＸ１は、デクリメンターからの出力（ＤＢＲ命令用）と、真理表からの出力（ＳＣ命令用）との間で選択を行う。５ビット出力のうちの最下位３ビットだけがＣ１に書き込まれることに注意する必要がある。マルチプレクサＭＸ１は、したがって、以下の選択規準をもっている。
【１４８６】
【表１９７】
0004309954.tif 000225
真理表は、ＳＣ命令を用いて、Ｃ１及びＣ２へロードされるべき値を保持する。真理表は、以下の関係を実現する簡単な組み合わせロジックである。
【１４８７】
【表１９８】
0004309954.tif 000226
レジスタＮ１、Ｎ２、Ｎ３及びＮ４は、ＸＯＲ命令によって参照されたとき、次の値−１（ラップ付き）によって更新される。レジスタＮ４は、ＳＴ 
Ｘ［Ｎ４］命令が実行されるときにも更新される。ＬＤ及びＡＤＤ命令はＮ４を更新しない。その上、全部で４個のレジスタはＳＥＴ 
Ｎｘコマンド中に更新される。Ｌｏｇｉｃ４−７は、レジスタＮ１からＮ４のＷｒｉｔｅＥｎａｂｌｅを生成する。どれもがＬｏｇｉｃ３を使用し、Ｌｏｇｉｃ３は、コマンドがＳＥＴ 
Ｎｘである場合に１を生成し、そうでなければ０を生成する。
【１４８８】
【表１９９】
0004309954.tif 000227
送出された、又はデクリメンターへの入力として使用された実際のインデックス値は、マルチプレクサＭＸ４がオペランドの下位２ビットを使用して簡単に選択する。
【１４８９】
【表２００】
0004309954.tif 000228
インクリメンターは、（マルチプレクサＭＸ４によって選択された）入力値のうちの４ビットを取得し、１を加え、４ビット結果を生成する（モジュロー２４の加法による）。最後に、マルチプレクサＭＸ３は４時点で、（Ｎ毎に異なり、ＳＥＴ 
Ｎｘコマンド中にロードされる）定数値と、（ＸＯＲ又はＳＴ命令中の）デクリメンターの結果と、の間で選択を行う。その値は、適当なＷｒｉｔｅＥｎａｂｌｅフラグがセットされている場合に限り書き込まれ（Ｌｏｇｉｃ４−Ｌｏｇｉｃ７を参照せよ）、Ｌｏｇｉｃ３はマルチプレクサのために安全に使用できる。
【１４９０】
【表２０１】
0004309954.tif 000229
ＳＥＴ Ｎｘコマンドは、Ｎ１からＮ４に以下の定数をロードする。
【１４９１】
【表２０２】
0004309954.tif 000230
参照される各初期Ｘ［Ｎｎ］は、最適化されたＳＨＡ−１アルゴリズムのインデックスＮ１からＮ４の初期状態と一致する。各インデックス値Ｎｎがデクリメントするとき、実効Ｘ［Ｎ］はインクリメントする。その理由は、Ｘワードは最上位ワードから先にメモリに格納されているからである。３個のＶＡＬユニットは、タンパー防止及び検出回路に接続された検証ユニットであり、各ＶＡＬはＯＫビットを含む。ＯＫビットはリセットで１にセットされ、サイクル毎に両方のタンパー防止及び検出ラインからのＣｈｉｐＯＫ値とＯＲ演算される。ＯＫビットはそのユニットを通過する各データビットとＡＮＤ演算される。全てのＶＡＬユニットは、データビットをパリティチェックし、カウンタが改ざんされていないことを保証する。パリティチェックが失敗であるならば、消去タンパー検出ラインがトリガーされる。ＶＡＬ１の場合、カウンタＣ１からの実効出力は、チップが改ざんされているならば、常に０である。これは、攻撃者が鍵の最初から最後までインデックス付けをするループ構造を実行することを阻止する。ＶＡＬ２の場合、カウンタＣ２からの実効出力は、チップが改ざんされたならば、常に０である。これは、攻撃者がループ構造を実行することを阻止する。ＶＡＬ３の場合、Ｎカウンタ（Ｎ１−Ｎ１４）からの実効出力は、チップが改ざんされているならば、常に０である。これは、攻撃者がＸの最初から最後までインデックス付けをするループ構造を実行することを阻止する。
【１４９２】
次に、図２０３を参照すると、フラッシュメモリ記憶装置７０１に格納された情報７０５が示されている。このデータには以下のものが含まれる。
【１４９３】
工場コード
工場コードは、プリントロールが製造された工場を示す１６ビットコードである。これは、プリントロールテクノロジーの所有者に属する工場、又は許可を得てプリントロールを製造する工場を識別する。この数値の目的は、品質の問題がある場合に、プリントロールの由来する工場を追跡できるようにすることである。
【１４９４】
バッチ番号
バッチ番号は、プリントロールの製造バッチを示す３２ビット番号である。この数値の目的は、品質の問題がある場合に、プリントロールの由来するバッチを追跡することである。
【１４９５】
シリアル番号
４８ビットシリアル番号は、最大で２８兆個まで各プリントロールを一意に識別できるようにするため設けられる。
【１４９６】
製造日
１６ビット製造日は、有効期限が制限されている場合に、プリントロールの経年を追跡するため組み込まれる。
【１４９７】
メディア長さ
ロール上に残っているプリントメディアの長さはこの数値によって表される。この長さは、ミリメータ、又はプリントロールを使用するプリンタ装置の最小ドットピッチのような小さい単位で表現され、周知のＣ、Ｈ及びＰの各フォーマット、並びに、印刷されるその他のフォーマットで残り写真数の計算を可能にさせる。この小さい単位を使用することによって、プレ印刷されたメディアとの同期を保つために高解像度が使用できることを保証する。
【１４９８】
メディアタイプ
メディアタイプデータはプリントロールに格納されているメディアを列挙する：
（１）透明
（２）乳白色
（３）不透明着色
（４）３次元レンチキュラー
（５）プレ印刷：長さ限定
（６）プレ印刷：非長さ限定
（７）金属箔
（８）ホログラフィック／光学的可変デバイス箔。
【１４９９】
プレ印刷メディア長さ
例えば、プリントロールの裏面に収容されているプレ印刷メディアの繰り返しパターンの長さがここに保存される。
【１５００】
インク粘性
各インクカラーの粘性が８ビット数値として格納される。インク粘性数は、粘性を補償するためプリントヘッドアクチュエータ特性を調節する際に使用される（典型的に、粘性が高くなると、同じドロップボリュームを実現するためにはより長いアクチュエータパルスが必要になる）。
【１５０１】
１２００ｄｐｉ用の推奨ドロップボリューム
各インクカラーの推奨ドロップボリュームは８ビット数値として格納される。最も適切なドロップボリュームは、インク及び印刷メディア特性に依存する。例えば、要求されるドロップボリュームは、色素濃度又は吸収性が増加すると減少する。また、透明メディアは乳白色メディアの約２倍のドロップボリュームを必要とする。なぜならば、光は、透明メディアの場合、色素層を１回しか通過しないからである。
【１５０２】
プリントロールは、インクとメディアの両方を収容するので、顧客適合を実現することができる。ドロップボリュームは、推奨ドロップマッチに過ぎない。なぜならば、プリンタは１２００ｄｐｉではないかもしれないし、また、プリンタは、印刷の明暗について調節されるかもしれないからである。
【１５０３】
インクカラー
染料色の各々のカラーが格納され、印刷前に画像に適用されるデジタル中間調を精細調整するために使用できる。
【１５０４】
残りメディア長さインジケータ
ロールに残っている印刷メディアの長さが数値によって表現され、カメラ装置によって更新される。長さは、Ｃ、Ｈ及びＰの各フォーマット、並びに、印刷されるその他のフォーマットで残り写真数を計算できるように、小さい単位（例えば、１２００ｄｐｉピクセル）で表現される。プレ印刷メディアとの同期を保つために高解像度を使用してもよい。
【１５０５】
著作権又はビットパターン
この５１２ビットパターンは、保存されたフラッシュメモリの内容を著作権保護可能にするために十分なＡＳＣＩＩ文字列を表現する。
【１５０６】
図２０４を参照すると、Ａｒｔｃａｍ認証チップの記憶テーブル７３０が示されている。テーブルは、製造コード、バッチ番号、シリアル番号、及び日付を含み、上述のフォーマットと同じである。テーブル７３０は、更に、Ａｒｔｃａｍ装置内のプリントエンジン上の情報７３１を含む。蓄積された情報は、プリンタエンジンタイプ、プリンタのＤＰＩ解像度、及びプリンタ装置によって作成されたプリント数のプリンタカウントを含む。
【１５０７】
更に、認証テスト鍵７１０が設けられ、これは、チップとチップの間でランダムに変化し、上述のアルゴリズムにおけるＡｒｔｃａｍランダム識別コードとしても利用される。１２８ビットのプリントロール認証鍵７１３も設けられ、これはプリントロール内に保存されたキーと同等である。次に、５１２ビットパターンが保存され、その後に、Ａｒｔｃａｍの利用に適した１２０ビットの予備エリアが続く。
【１５０８】
上述のように、Ａｒｔｃａｍは、好ましくは、液晶ディスプレイ１５を含み、液晶ディスプレイは、Ａｒｔｃａｍに格納されているプリントロールに残されたプリント数を示す。更に、Ａｒｔｃａｍは、３状態スイッチ１７を含み、これにより、ユーザは、３種類の標準的なフォーマットＣ、Ｈ及びＰ（クラシック、ＨＤＴＶ及びパノラマ）を切り換えることが可能である。三つの状態間の切替後、液晶ディスプレイ１５は、選択された特定のフォーマットが使用されるならば、プリントロールに残っている画像の枚数を反映するため更新される。
【１５０９】
液晶ディスプレイを正しく動作させるため、Ａｒｔｃａｍプロセッサは、プリントロールを挿入し、認証テストに合格した後、プリントロールチップ５３のフラッシュメモリ記憶装置から読み出し、用紙残量を判定する。次に、出力フォーマット選択スイッチ１７の値がＡｒｔｃａｍプロセッサによって判定される。プリント長さを、選択された出力フォーマットの対応した長さで除算することにより、Ａｒｔｃａｍプロセッサは、プリント可能数を判定し、残りプリント数で液晶ディスプレイ１５を更新する。ユーザが出力フォーマット選択スイッチ１７を変更すると、Ａｒｔｃａｍプロセッサ３１は、そのフォーマットに応じて出力ピクチャーの数を再計算し、再度、ＬＣＤディスプレイ１５を更新する。
【１５１０】
プロセス情報をプリントロールテーブル７０５（図１６５）に保存することによって、Ａｒｔｃａｍ装置はプロセスの変化、及びプリントロールのプリント特性の変化を利用することができる。
【１５１１】
特に、プリントヘッド内の各ノズルに加えられたパルス特性は、プロセス特性の変化を考慮するために変更可能である。図２０５を参照すると、Ａｒｔｃａｍプロセッサは、補助メモリＲＯＭチップに記憶されたソフトウェアプログラムを動かすために適合し得る。ソフトウェアプログラムであるパルスプロファイルキャラクタライザ７７１は、プリントロールから多数の変数を読み出すことができる。これらの変数には、プリントロール７７２上の残りロールメディア、プリンタメディアタイプ７７３、インクカラー粘性７７４、インクカラードロップボリューム７７５、及びインクカラー７７６が含まれる。これらの変数の各々は、パルスプロファイルキャラクタライザによって読み出され、対応した最も適しているパルスプロファイルは、従来の試行錯誤法によって決定される。パラメータは、インク出力の安定性を高めるために、各プリンタノズルで受け取られるプリンタパルスを変更する。
【１５１２】
明らかなように、認証チップは、重要かつ価値ある情報がプリンタロールと一体のプリンタチップに格納されている点で著しく進歩している。この情報は、対象となっているプリントロールのプロセス特性を、プリントロールのタイプ及びプリントロールに残っている用紙量と共に含む。
【１５１３】
更に、プリントロールインタフェースチップは、貴重な認証情報を提供し、耐タンパー性の形で構築することが可能である。また、このチップを利用する耐タンパー性のある方法が提供される。プリントロールチップの利用は、Ａｒｔｃａｍ装置の迅速な出力フォームのために便利かつ効率的なユーザインタフェースを提供することができ、多数の写真フォーマットを出力でき、同時に、印刷装置に残っている写真の数のインジケータを提供することができる。
【１５１４】
プリントヘッドユニット
図２０６には、図１６２のプリントヘッドユニット６１５の分解斜視部分断面図が示されている。
【１５１５】
プリントヘッドユニット６１５は、像を形成するように要求に応じてインクドロップをプリントメディア６１１へ噴射するプリントヘッド４４が中心に置かれる。プリントメディア６１１は、第１セット６１８及び６１６と、第２セット６１７及び６１９からなる２組のローラーの間に挟まれている。
【１５１６】
プリントヘッド４４は電源、グランド、及び信号線８１０の制御下で動作し、電源、グランド、及び信号線８１０は、プリントヘッド４４用の電源及び制御を提供し、テープ自動ボンディング（ＴＡＢ）によってプリントヘッド４４の表面に接合されている。
【１５１７】
重要なことは、適当に分離されたシリコンウェハー装置から構築することができるプリントヘッド４４は、一連の異方性エッチ８１２に依拠し、ウェハーを介して、ほぼ垂直な側壁を有する。ウェハーを貫通するエッチ８１２は、後で取り出すためウェハーの裏側からインクをプリントヘッド表面に直接供給することができる。
【１５１８】
インクは、インクヘッド供給ユニット８１４を用いてインクジェットプリントヘッド４４の裏側に供給される。インクジェットプリントヘッド４４は、その表面に沿って、別々の色のインクを供給するため３つの別個の行をもつ。インクヘッド供給ユニット８１４は、インクチャンネルをシールする蓋８１５を含む。
【１５１９】
図２０７から図２１０には、インクヘッド供給ユニット８１４の多数の斜視図が示されている。図２０７から図２１０の各々は、長さに制限のないインクヘッド供給ユニットの一部だけを示し、図示された部分は典型的な細部を示す。図２０７には、底側斜視図が示され、図１４８は上側斜視図を示し、図２０９は拡大斜視部分断面図を示し、図２１０はインクチャンネルの詳細を示す上側斜視図であり、図２１１は上側斜視図であり、図２１２も同様である。
【１５２０】
インクヘッド供給ユニット８１４は、例えば、マイクロマシーン加工されたシリコンからではなく、射出成形プラスチックから形成する方がコスト的にかなり有利である。プラスチックインクチャンネルの製造コストは非常に低く、製造は十分に容易である。添付図面に示された設計は、所定の長さの１６００ｄｐｉの３色モノリシックプリントヘッドを想定している。与えられた流速計算は、１００ｍｍフォトプリンタに対するものである。
【１５２１】
インクヘッド供給ユニット８１４は、必要な精細部の全てを含んでいる。蓋８１５（図２０６）は、インクヘッド供給ユニット８１４に永久的に接着されるか、又は超音波溶接され、インクチャンネルのシールを提供する。
【１５２２】
図２０９を参照すると、シアン、マゼンタ、イエローのインクが、インクインレット８２０−８２２に流入し、マゼンタインクはスルーホール８２４，８２５の中を流れ、マゼンタメインチャンネル８２６，８２７（図１４１）に沿って流れる。シアンインクは、シアンメインチャンネル８３０に沿って流れ、イエローインクはイエローメインチャンネル８３１に沿って流れる。図２０９に最もよく示されているように、シアンインクメインチャンネル内のシアンインクは、シアンサブチャンネル８３３に流れ込む。イエローサブチャンネル８３４は、同様に、イエローメインチャンネル８３１からイエローインクを受け取る。
【１５２３】
図２１０の最もよく示されているように、マゼンタインクもマゼンタメインチャンネル８２６，８２７からマゼンタスルーホール８３６，８３７へ流れる。図２０９に戻ると、マゼンタインクはスルーホール８３６，８３７から流出する。マゼンタインクは、マゼンタサブチャンネル、例えば、８３８に沿って流れ、次に、第２のマゼンタサブチャンネル、例えば、８３９に沿って流れ、その後、マゼンタトラフ８４０に流入する。マゼンタインクは、次に、マゼンタバイア、例えば、８４２を流れ、マゼンタバイアは、対応したインクジェットヘッドスルーホール（例えば、図１６６の８１２）と整列させられ、それらは、次に、インクをプリントアウト用のインクジェットノズルへ供給する。
【１５２４】
同様に、シアンサブチャンネル８３３内のシアンインクはシアンピットエリア８４９に流入し、それは、インクを二つのシアンバイア８４３，８４４に供給する。同様に、イエローサブチャンネル８３４は、イエローピットエリア４６へ供給し、イエローピットエリアはイエローバイア８４７，８４８へ供給する。
【１５２５】
図２１０に示されるように、プリントヘッドは、プリントヘッドスロット８５０に収容できるように設計され、種々のバイア、例えば、８５１は、プリントヘッドウェハー内で対応したスルーホール、例えば、８５１と揃えられる。
【１５２６】
図２０６に戻ると、適切なインクがプリントヘッドチップ４４の全体へ流れ、同時に、射出成形プロセスの制約を満たすように注意すべきである。プリントヘッドチップの裏側にあるインクスルーウェハーホール８１２のサイズは、約１００μｍ×５０μｍであり、異なる色のインクを運ぶスルーホールの隙間は約１７０μｍである。このサイズの形状は容易にプラスチック成形でき（コンパクトディスクはミクロンサイズの形状である）、理想的には壁の高さは、適当なスティフネスを維持するため、壁の厚さの数倍を超えてはならない。好適な実施形態は、少しずつ小さくなるインクチャンネルの階層構造を使用することによってこの問題を解決している。
【１５２７】
図２１１には、プリントヘッド４４の表面の小部分８７０が示されている。表面は、シアン系列８７１、マゼンタ系列８７２、及びイエロー系列８７３からなる３系列のノズルに分割される。ノズルの各系列は、更に、２列、例えば、８７５、８７６に分割され、プリントヘッド４４は、電源及び制御信号を接合する接合パッド８７８の系列を含む。
【１５２８】
プリントヘッドは、好ましくは、Ａｒｔｃａｍ装置を含む用途のため創作された非常に多数のインクジェットの異なる形態に応じて構築される。これらのインクジェット装置は以下で詳述される。
【１５２９】
プリントヘッドノズルは、図２０６の異方性エッチホール８１２と同等のインク供給チャンネル８８０を含む。インクは、ウェハーの裏側から、供給チャンネル８８１を通り、次に、フィルタグリル８８２を通り、インクノズルチャンバー、例えば、８８３へ流れる。ノズルチャンバー８８３及びプリントヘッド４４（図１）の動作は、既に説明した通りであり、上述の特許明細書に記載されている。
【１５３０】
インクチャンネル流体フロー解析
次に、インクフローの解析を説明すると、メインインクチャンネル８２６、８２７、８３０、８３１（図２０７、図１４１）は、約１ｍｍ×１ｍｍであり、１色の全てのノズルに供給する。サブチャンネル８３３、８３４、８３８、８３９（図２０９）は約２００μｍ×１００μｍであり、一つが約２５のインクジェットノズルへ供給する。プリントヘッドスルーホール８４３、８４４、８４７、８４８及びウェハースルーホール、例えば、８８１（図２２１）は、１００μｍ×５０μｍであり、プリントヘッドスルーホールのそれぞれの側で３個のノズルに供給する。各ノズルフィルタ８８２は８スリットを有し、各スリットは２０μｍ×２μｍの面積を有し、一つのノズルに供給する。
【１５３１】
上記のように構成されたインクジェットプリンタの圧力必要条件の解析を行った。解析は、写真印刷用の１６００ｄｐｉの３色プロセスプリントヘッドに対するものである。プリント幅は１００ｍｍであり、１色毎に６２５０のノズルがあり、全部で１８７５０のノズルがある。
【１５３２】
フルブラック印刷の場合に種々のチャンネルで必要な最大インク流速が重要である。これは、インクチャンネルに沿った圧力降下を決定し、したがって、プリントヘッドが表面張力だけで充満した状態を保つかどうか、保てない場合に、プリントヘッドを充満した状態に保つために必要なインク圧を決定する。
【１５３３】
圧力降下を計算するため、１６００ｄｐｉ動作に対して２．５ｐＩのドロップボリュームを利用した。ノズルはもっと高速に動作する能力を備えているが、選択されたドロップ繰り返しレートは５ｋＨｚであり、これは、１５０ｍｍ長さの写真を２秒以内に印刷するために適当である。このようにして、極端なケースでは、プリントヘッドは、１８７５０ノズルを有し、すべてが毎秒最大５０００ドロップで印刷をする。このインクフローは、インクチャンネルの階層構造全体に広がる。各インクチャンネルは、全てのノズルが印刷をしているとき、事実上、一定数のノズルに供給する。
【１５３４】
圧力降下Δρは、Ｄａｒｃｙ−Ｗｅｉｓｂａｃｈ式に従って計算した：
Δρ＝ρＵ２ｆＬ／２Ｄ
ここで、ρはインクの密度であり、Ｕは平均流速であり、Ｌは長さであり、Ｄは水力直径であり、ｆは無次元摩擦係数であり、以下の式で計算した：
ｆ＝κ／Ｒｅ
ここで、Ｒｅはレイノルズ数であり、κは、チャンネルの断面積に依存する無次元摩擦係数であり、以下の式で計算した：
Ｒｅ＝ＵＤ／ν
ここで、νはインクの運動学的粘性である。
【１５３５】
矩形断面の場合、κは、
κ＝６４／（２／３＋（１１ｂ／２４ａ）（１１ｂ／２４ａ）（２−ｂ／ａ））
によって近似できる。
【１５３６】
式中、ａは矩形断面の長辺であり、ｂは短辺である。矩形断面に対する水力直径Ｄは、
Ｄ＝２ａｂ／（ａ＋ｂ）
によって与えられる。
【１５３７】
インクは、チャンネルの長手方向の２５０点でメインインクチャンネルから抜かれた。インク粘性はチャンネルの先端から線形に降下し、チャンネルの終端で０まで降下するので、平均流速Ｕは最大流速の半分である。したがって、メインインクチャンネルに沿った圧力降下は、最大流速を用いて計算した圧力降下の半分である。
【１５３８】
これらの式を利用して、圧力降下を計算することにより、次の表が得られた。
【１５３９】
インクチャンネル寸法と圧力降下の表
【１５４０】
【表２０３】
0004309954.tif 000231
インクインレットからノズルまでの総圧力降下は、したがって、シアン及びイエローに関して約７０１Ｐａであり、マゼンタに関して８４５Ｐａである。これは、大気圧の１％未満である。勿論、印刷された画像がフルブラック未満の場合、インクフロー（したがって、圧力降下）はこれらの値よりも低下するであろう。
【１５４１】
インクヘッド供給ユニット用の金型製作
インクヘッド供給ユニット１４（図１）は５０μの外形と１０６ｍｍの長さがある。射出成形ツールを従来の方法で加工することは実施不可能である。しかし、全体的な形状が複雑であるとしても、複雑な曲線は不要である。射出成形ツールは、メインインクチャンネル及びその他のミリメートルスケールの形状については従来のミリングを使用して製作可能であり、精細な形状はリソグラフ的に製作されたインセットを用いる。ＬＩＧＡプロセスをインセットのために使用できる。
【１５４２】
単一の射出成形ツールは、簡単に５０以上のキャビティを含む。ツールの複雑さの殆どはインセットにある。
【１５４３】
図２０６を参照すると、印刷システムはインク供給ユニット８１４及び蓋８１５を一体的に成形し、上述のようにそれらを一体的にシーリングする。次に、プリントヘッド４４が対応したスロット８５０に設置される。粘着性シーリングストリップ８５２、８５３がマゼンタメインチャンネル上に置かれ、それらが適切にシールされることを保証する。テープ自動ボンディング（ＴＡＢ）ストリップ８１０がインクジェットプリントヘッド４４に接続され、タブボンディングワイヤはキャビティ８５５内に通る。図２０６、図２０７及び図２１２からよく分かるように、アパーチャスロット８５５から８６２は、ローラーの挿入の際のスナップのために設けられる。スロットは、ある程度の遊びをもってローラーを「クリッピングイン」し、次に、ローラーを容易に回転させる。
【１５４４】
図２１３から図２１７には、最終的に組み立てられたＡｒｔｃａｍ装置の内部の様々な斜視図が示され、装置には適当な番号が付されている：
・図２１３は、Ａｒｔｃａｍカメラの内部の上面側の斜視図であり、平らにされた部品が示されている；
・図２１４は、Ａｒｔｃａｍカメラの内部の底面側の斜視図であり、平らにされた部品が示されている；
・図２１５は、Ａｒｔｃａｍカメラの内部の第１の上面側の斜視図であり、Ａｒｔｃａｍに収容された部品が示されている；
・図２１６は、Ａｒｔｃａｍカメラの内部の第２の上面側の斜視図であり、Ａｒｔｃａｍに収容された部品が示されている；
・図２１７は、Ａｒｔｃａｍカメラの内部の第２の上面側の斜視図であり、Ａｒｔｃａｍに収容された部品が示されている。
【１５４５】
ポストカードプリントロール
図２１８を参照すると、好適な実施形態の一形態として、出力プリンタ用紙１１は、画像が印刷されない面に、多数のプレ印刷された「ポストカード」型裏書き部分８８５を含む。ポストカード型セクション８８５は、プリペイド式郵便料金「スタンプ」８８６を含み、この「スタンプ」８８６は、関連した郵便当局からの印刷された認証により構成され、その当局の管轄区域内で、そのプリントロールが販売若しくは利用される。関連した管轄区域の郵便当局との合意によって、プリントロールは様々な郵便料金を利用できる。これは、特に、外国からの旅行者が国内の管轄内にいて、自国へ多数のポストカードを送る場合に便利である。更に、住所書式部分８８７が設けられ、通常のポストカードの形式で宛先発送の詳細を記入できる。最後に、メッセージ領域８８７が設けられ、私信を記入することができる。
【１５４６】
図２１８及び図２１９を参照して、カメラ装置の動作を説明すると、一連の画像８９０から８９２がプリントロールの第１面に印刷されたときの、対応した裏書き面が図２１８に示されている。したがって、各画像、例えば、８９１がカメラによって印刷されると、画像の裏面は、既にポストカード８８５になっているので、直ちに、管轄区域内の最も近い郵便ポストへ投函することができる。このように、パーソナル化されたポストカードを作成することができる。
【１５４７】
図２１９及び図２２０に示されるようなポストカードシステムを利用するとき、予め定められた画像サイズだけが可能であることは明白である。なぜならば、裏面のポストカード部分８８５と、表面の画像８９１との対応関係を維持しなければならないからである。これは、各ポストカードの裏書き書式シート８８５の長さの詳細を記憶するためプリントロール内に収容された認証チップのメモリ部分を利用することによって実現される。これは、各ポストカードのサイズを同じサイズにすること、又はそれぞれのサイズをプリントロールのオンボードプリントチップメモリに格納することによっても実現される。
【１５４８】
Ａｒｔｃａｍカメラ制御システムは、予め書式化されたポストカードを利用するとき、プリントロールは、各画像がポストカードの境界に収まるように画像を印刷するためだけに使用されることを保証することができる。勿論、多少の位置合わせ誤差を考慮できるように境界領域を各写真のエッジに設けることによってある程度の「遊び」が与えられる。
【１５４９】
図２２０から明らかであるように、ポストカードロールは、それを利用可能な特定の管轄区域内に旅行するとき、カメラユーザが事前に購入できる。ポストカードロールは、その外面に、購入国、各ポストカードの郵便料金、各ポストカードのフォーマット（例えば、Ｃ、Ｈ、Ｐ、又はこれらの画像モードの組み合わせ）、使用するのに適した国名、及びその日以降に郵便料金が不足になるかもしれない郵便料金期限を含む情報が印刷されている。
【１５５０】
したがって、カメラ装置のユーザは、関連したシーンに向けられた自分のハンドヘルドカメラを利用して、写真を撮影して、その画像が一方の面に掲載され、もう一方の面にはプリペイド式ポストカードの詳細が記載されている郵便で発送するためのポストカードを製作することが可能である。次に、このポストカードに宛先を指定し、短いメッセージを記入し、その後、直ぐに郵便で発送することができる。
【１５５１】
Ａｒｔｃａｍ装置のソフトウェア動作に関して、種々のソフトウェア設計が可能であるが、ある設計では、各Ａｒｔｃａｍ装置は、１組の緩く結合した機能モジュールにより構成され、これらの機能モジュールは、一つの埋め込み型アプリケーションによって連係した形で利用できるようにされ、装置の中心目的のために機能する。機能モジュールは、様々なクラスのＡｒｔｃａｍ装置において、異なる組み合わせで再使用され、アプリケーションはＡｒｔｃａｍのクラスに特有である。
【１５５２】
殆どの機能モジュールは、ソフトウェアとハードウェアの両方のコンポーネントを含む。ソフトウェアは、ハードウェア抽象化レイヤによって、ハードウェアの細部からシールドされ、一方、モジュールのユーザは、抽象化ソフトウェアインタフェースによってソフトウェアインプリメンテーションからシールドされている。システムは、全体として、ユーザ始動、及びハードウェア始動のイベントによって駆動されるので、殆どのモジュールは、一つ以上の同期的なイベント駆動型プロセスを動かすことができる。
【１５５３】
一般的なＡｒｔｃａｍ装置を構成する殆どの重要なモジュールが図２２１に示されている。同図及びその後の図には、ソフトウェアコンポーネントが左側にｓめされ、垂直点線９０１によって右側のハードウェアコンポーネントから分離されている。これらのモジュールのソフトウェアの面を次に説明する。
【１５５４】
ソフトウェアモジュール−Ａｒｔｃａｍアプリケーション９０２
ＡｒｔｃａｍアプリケーションはＡｒｔｃａｍ装置の上位レベル機能を実現する。これは、通常、像の撮影、像に対する芸術的効果の適用、及び像の印刷を含む。カメラ指向のＡｒｔｃａｍ装置の場合、画像は、カメラマネージャ９０３によって捕捉される。プリンタ指向のＡｒｔｃａｍ装置の場合、画像は、ネットワークマネージャ９０４によって捕捉され、おそらく、この画像は他の装置によって送出された結果物である。
【１５５５】
芸術的効果は、ファイルマネージャ９０５によって管理される統合ファイルシステム内で行われる。芸術的効果は、スクリプトファイルとリソースのセット途により構成される。スクリプトは、画像処理マネージャ９０６によって翻訳され、画像に適用される。スクリプトは、通常、Ａｒｔｃａｒｄとして知られているＡｒｔＣａｒｄｓで出荷される。デフォルトとして、システムは、現在搭載されているＡｒｔｃａｒｄに格納されているスクリプトを使用する。
【１５５６】
画像はプリントマネージャ９０８によって印刷される。
【１５５７】
Ａｒｔｃａｍ装置がスタートアップしたとき、ブートストラッププロセスが、アプリケーションを開始する前に種々のマネージャプロセスを始動する。これにより、アプリケーションは、スタートしたときに、直ちに様々なマネージャからのサービスを要求できる。
【１５５８】
初期化後、アプリケーション９０２は、それ自体を以下に列挙されたイベントのハンドラーとして登録する。アプリケーションはイベントを受け取ったとき、表に記載された動作を実行する。
【１５５９】
【表２０４】
0004309954.tif 000232
カメラがディスプレイを含むとき、アプリケーションはユーザインタフェースマネージャ９１０によってグラフィカルユーザインタフェースを構築し、ユーザは現在日時、及びその他の編集可能なカメラパラメータを編集できるようになる。アプリケーションは、全ての常駐パラメータをフラッシュメモリに保存する。
【１５６０】
リアルタイムマイクロカーネル９１１
リアルタイムマイクロカーネルは、割込とプロセス優先順位に基づいて、予めプロセスをスケジューリングする。それは、プロセススケジューリングに非常に密接している統合プロセス間通信及びタイマーサービスを提供する。全ての他のオペレーティングシステム機能はマイクロカーネルの外部で行われる。
【１５６１】
カメラマネージャ９０３
カメラマネージャは、画像捕捉（撮像）サービスを提供する。それは、Ａｒｔｃａｍに組み込まれたカメラハードウェアを制御する。それは、抽象的カメラ制御インタフェースを提供し、カメラパラメータの問い合わせ及び設定、画像捕捉を可能にさせる。この抽象的インタフェースは、アプリケーションを他のカメラインプリメンテーションの細部から切り離す。カメラマネージャは以下の入力／出力パラメータ及びコマンドを利用する。
【１５６２】
【表２０５】
0004309954.tif 000233
【１５６３】
【表２０６】
0004309954.tif 000234
【１５６４】
【表２０７】
0004309954.tif 000235
カメラマネージャは、非同期イベント駆動型プロセスとして動く。それは、連結された状態機械の組を含み、各状態機械は一つの非同期オペレーションに対応する。それらは、オートフォーカス、フラッシュ充電、セルフタイマのカウントダウン、及び像の撮影を含む。初期化時、カメラマネージャはカメラハードウェアを既知状態にセットする。これは、通常の焦点距離の設定、及びズームの戻しを含む。カメラマネージャのソフトウェア構造は、図２２２に示されている。ソフトウェアコンポーネントは以下のサブセクションに記載されている。
【１５６５】
フォーカス固定９１３
ロックフォーカスは、フォーカス制御モード、露出制御モード、及びフラッシュモードに応じて、現在シーンに対して自動的にフォーカスと露出を調整し、必要に応じてフラッシュを動作可能状態にする。ロックフォーカスは、通常、ユーザが撮影ボタンを半押しすることによって始動される。これは、正常な像撮影シーケンスの一部であるが、ユーザが撮影ボタンを半押しのままにした場合、時間的に、実際の像の撮影からは分離される。これは、ユーザがスポットフォーかシング及びスポット測距をできるようにする。
【１５６６】
撮影９１４
撮影（像捕捉）は、現在シーンの像を撮影する。フラッシュモードがレッドアイ除去を含む場合、レッドアイランプを点灯し、シャッターを制御し、動作可能状態であれば、フラッシュをトリガーし、イメージセンサによって像を検知する。それは、カメラの向き、即ち、撮影像の向きを判定し、これにより、後の画像処理で、像は適切に向きを決められる。また、それは、後の画像処理中にブラーを取り除くため、撮像中にカメラの動きの有無を検出する。
【１５６７】
セルフタイム撮影９１５
セルフタイム撮影は、２０秒タイマーのカウントダウン後に、現在シーンの像を撮影する。これは、カウントダウン中に、セルフタイマーＬＥＤを用いて、ユーザにフィードバックを与える。最初の１５秒間に、それは、ＬＥＤを点灯できる。最後の５秒間にＬＥＤは点滅する。
【１５６８】
ビューシーン９１７
ビューシーンは、周期的に、イメージセンサを通して現在シーンを検知し、そのシーンをカラーＬＣＤに表示させ、ユーザにＬＣＤベースのビューファインダーを提供する。
【１５６９】
オートフォーカス９１８
オードフォーカスは、像の選択された領域が焦点が合っていると言えるまで十分に鮮明になるまで、焦点距離を変化させる。それは、イメージセンサの指定された領域から抽出された画像鮮明さメトリックが固定の閾値を超えた場合に領域の焦点が合うということを前提とする。それは、鮮明さの微分に関する勾配降下法を実行し、必要に応じて方向及びステップサイズを変えることによって、最適焦点距離を見つける。焦点制御モードがマルチポイントオートであるならば、視野全体に水平に配置された３個の領域が使用される。焦点制御モードがシングルポイントオートであるならば、視野の中心にある一つの領域が使用される。オートフォーカスは、フォーカスコントローラによって指定された有効焦点距離の範囲内で機能する。固定焦点装置の場合、これは、事実上、無効にされる。
【１５７０】
オートフラッシュ９１９
オートフラッシュは、シーンの照度がフラッシュを必要とする程度に薄暗いかどうかを判定する。これは、シーンの照度が所定の閾値以下であるならば、照度が十分に薄暗いとみなす。シーンの照度は、照度センサから獲得され、照度センサはイメージセンサの中央領域から照度メトリックを抽出する。フラッシュが必要であれば、フラッシュを充電する。
【１５７１】
自動露出９２０
シーン照度、絞り、および、シャッター速度は、撮影像の露出を決定する。望ましい露出は固定値である。露出制御モードがオートであるならば、自動露出は、所定のシーン照度に対して望ましい露出を生じる絞りとシャッター速度の組み合わせを決定する。露出制御モードが絞り優先であるならば、自動露出は、所定のシーン照度及び現在の絞りに対して望ましい露出を生じるシャッター速度を決める。露出制御モードがシャッター優先であるならば、自動露出は、所定のシーン照度及び現在のシャッター速度に対して望ましい露出を生じる絞りを決める。シーン照度は照度センサから取得され、照度センサはイメージセンサの中央領域から照度メトリックを抽出する。
【１５７２】
自動露出は、絞りコントローラ及びシャッター速度コントローラによって指定された有効絞り及びシャッター速度の範囲内で機能する。シャッター速度コントローラ及びシャッターコントローラは、殆どのＡｒｔｃａｍ装置では機械的シャッターの無いことを隠す。
【１５７３】
フラッシュが、マニュアル又はオートで有効にされている場合、実効的なシャッター速度はフラッシュの間隔であり、これは、典型的に、１／１０００秒から１／１００００秒である。
【１５７４】
画像処理マネージャ９０６（図２２１）
画像処理マネージャは、画像処理と芸術的効果サービスを提供する。これは、高速画像処理を実行するためＡｒｔｃａｍに組み込まれたＶＬＩＷベクトルプロセッサを利用する。画像処理マネージャは、Ｖａｒｋ画像処理言語で記述されたスクリプト用のインタープリタを具備する。したがって、芸術的効果は、Ｖａｒｋスクリプトファイルと、フォント、クリップ画像のような関連したリソースと、を含む。画像処理マネージャのソフトウェア構造は図２２３により詳細に示され、以下のモジュールを含む。
【１５７５】
画像の変換及び強調９２１
画像処理マネージャは、装置に依存しないＣＩＥ ＬＡＢ色空間において、Ａｒｔｃａｍプリンタハードウェアの生成能力に適した解像度で、画像処理を実行する。撮影された像は、最初に、ノイズをフィルタ処理して強調される。それは、オプションとして、動きによって生じたブラー効果を取り除くために行われる。画像は、次に、装置に依存したＲＧＢ色空間から、ＣＩＥ 
ＬＡＢ色空間へ変換される。像は、撮影時のカメラ回転の影響を相殺するため回転させられ、作業用画像解像度へスケール変換される。画像は、そのダイナミックレンジを利用可能なダイナミックレンジへスケーリングすることによって強調される。
【１５７６】
顔検出９２３
顔は、色相及び局部的特徴解析に基づいて撮影された像内で検出される。検出された顔領域のリストは、ワーピング及び吹き出しの配置のような顔専用効果を適用するためＶａｒｋスクリプトによって使用される。
【１５７７】
Ｖａｒｋ画像処理言語インタープリタ９２４
Ｖａｒｋは、豊富な画像処理のセットで拡張された汎用プログラミング言語を含む。それは、プリミティブデータタイプの範囲（整数、実数、ブール、文字）、より複雑なタイプを構築するための集合データタイプの範囲（配列、文字列、レコード）、算術演算及び論理演算の豊富な組、条件付き及び反復制御フロー（ｉｆ−ｔｈｅｎ−ｅｌｓｅ、ｗｈｉｌｅ−ｄｏ）、及び再帰的関数及び手続を提供する。また、それは、画像処理データタイプの範囲（画像、クリップ画像、マット、カラー、カラールックアップテーブル、パレット、ディザ行列、コンボリューションカーネル、等）、グラフィックデータタイプ（フォント、テキスト、パス）、画像処理関数の組（カラー変換、コンポジット処理、フィルタ処理、空間変換及びワーピング、イルミネーション、テキスト設定及びレンダリング）、及び上位レベルの芸術的関数の組（タイリング、ペインティング、及びストローキング）を提供する。
【１５７８】
Ｖａｒｋプログラムは二つの意味でポータブルである。それは、インタープリットされるので、ＣＰＵ及びホストの画像処理エンジンに依存しない。装置に依存しないモデル空間及び装置に依存しない色空間を使用するので、それは、入力色特性、ホスト入力装置の解像度、出力色特性、及びホスト出力装置の解像度に依存しない。
【１５７９】
Ｖａｒｋインタープリタ９２４は、Ｖａｒｋスクリプトを構成するソースステートメントを解析し、そのスクリプトの意味を表現するパースツリーを生成する。パースツリーのノードは、プログラムのステートメント、エクスプレッション、サブエクスプレッション、変数、及び定数に対応する。ルートノードはメインプロシジャーステートメントリストに対応する。このインタープリタは、パースツリーのルートステートメントを実行することにより、プログラムを実行する。パースツリーの各ノードはその子にそれ自体を適切に評価又は実行するように要求する。例えば、ｉｆステートメントノードは、条件表現ノードと、ｔｈｅｎステートメントノードと、ｅｌｓｅステートメントノードの三つの子を持つ。ｉｆステートメントは、条件表現ノードに、それ自体を評価し、返されたブール値に基づいて、ｔｈｅｎステートメント又はｅｌｓｅステートメントにそれ自体を実行させる。それは、実際の条件表現又は実際のステートメントは知らない。
【１５８０】
殆どのデータタイプの演算はパースツリーの実行中に行われるが、画像データタイプの演算は、パースツリーの実行後まで、延期される。これにより、画像演算が最適化され、最終的な画像に寄与する中間画素だけが計算される。これは、最終画像を、空間細分によって多数のパスで計算することを可能にさせ、これにより、必要なメモリ量を減少させる。
【１５８１】
パースツリーの実行中に、各画像関数は画像グラフを返すだけであり、この画像グラフは、ノードが画像オペレータを表し、リーフが画像を表すものであり、対応した画像オペレータをルートとし、その画像パラメータをルートの子とすることによって構築される。画像パラメータは勿論それ自体が画像グラフである。このようにして、それぞれの逐次的な画像関数は、より深い画像グラフを返す。
【１５８２】
パースツリーの実行後、最終画像に対応した画像グラフが得られる。この画像グラフは、次に、（任意の表現ツリーと同じように）深さ優先方式で実行され、以下の２点で最適化される。（１）最終画像に寄与する画素だけが所定のノードで計算される。（２）ノードの子は、メモリ必要量を最小限に抑える順番で実行される。画像グラフ中の画像オペレータは、最終画像を生成するために最適化された順序で実行される。計算集約的な画像オペレータは、Ａｒｔｃａｍ装置に組み込まれたＶＬＩＷプロセッサを使用して加速される。画像グラフを実行するために必要なメモリ量が利用可能なメモリを超えたとき、最終画像領域は、必要なメモリが利用可能なメモリを超えなくなるまで細分される。
【１５８３】
巧く構築されたＶａｒｋプログラムの場合、最初の最適化は特に大きな効果があるとは思えない。しかし、最終画像領域が細分された場合、最適化はかなりの効果を生ずる可能性がある。細分化がメモリ必要量を減少させる効果的な技術として使用することができることが、まさにこの最適化である。画像オペレーションの実行を遅らせることの結果の一つは、プログラム制御フローを画像内容に依存させられないことである。なぜならば、画像内容はパースツリー実行中には分からないからである。実際上、これはそれほど制約にはならないが、それにもかかわらず、言語設計中には注意しなければならない。
【１５８４】
画像オペレーションの延期実行（又は遅延評価）の考え方については、Ｇｕｉｂａｓ
ａｎｄ Ｓｔｏｌｆｉによって記載されている（Ｇｕｉｂａｓ，
Ｌ．Ｊ，．， ａｎｄ  Ｊ．Ｓｔｏｌｆｉ， '&apos;Ａ Ｌａｎｇｕａｇｅ ｆｏｒ Ｂｉｔｍａｐ Ｍａｎｕｐｕｌａｔｉｏｎ'&apos;，ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ
ｏｎ Ｇｒａｐｈｉｃｓ，Ｖｏｌ．１，
Ｎｏ．３，Ｊｕｌｙ １９８２， 
ｐｐ．１９１−２１４）。彼らは、プログラムの実行中に同様に画像グラフを構築し、後続のグラフ評価中に、最終画像に寄与しない画素の計算を回避するため、結果領域を逆伝搬させる。Ｓｈａｎｔｚｉｓは、更に、利用可能な画素を画像グラフ評価中に前方へ伝搬させる（Ｓｈａｎｔｚｉｓ，
Ｍ．Ａ．，'&apos;Ａ Ｍｏｄｅl ｆｏｒ Ｅｆｆｉｃｉｅｎｔ ａｎｄ
Ｆｌｅｘｉｂｌｅ
Ｉｍａｇｅ Ｃｏｍｐｕｔｉｎｇ'&apos;， Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｅｄｉｎｇｓ， Ａｎｎｕａｌ
Ｃｏｎｆｅｒｅｎｃｅ
Ｓｅｒｉｅｓ， １９９４，ｐｐ．１４７−１５４）。Ｖａｒｋインタープリタは、Ｃａｍｅｒｏｎによって提案された、より洗練されたマルチパス型ビットディレクショナル領域伝搬スキームを使用する（Ｃａｍｅｒｏｎ， 
Ｓ．，'&apos;Ｅｆｆｉｃｉｅｎｔ
Ｂｏｕｎｄｓ ｉｎ
Ｃｏｎｓｔｒｕｃｔｉｖｅ
Ｓｏｌｉｄ Ｇｅｏｍｅｔｒｙ'&apos;， ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ ＆ Ａｐｐｋｉｃａｔｉｏｎｓ，
Ｖｏｌ．１１， Ｎｏ．３，
Ｍａｙ
１９９１， ｐｐ．６８−７４）。メモリ使用量を最小限に押させるため実行順序を最適化する方法は、Ｓｈａｎｔｚｉｓに由来するが、標準的なコンパイラ理論に基づいている（Ａｈｏ， 
Ａ． Ｖ．，
Ｒ． Ｓｅｈｉ，
ａｎｄ Ｊ．Ｄ．
Ｕｌｌｍａｎ，
&apos;'ＧｅｎｅｒａｔｉｎｇＣｏｄｅ ｆｒｏｍ ＤＡＧｓ'&apos;， ｉｎ Ｃｏｍｐｉｌｅｒｓ： Ｐｒｉｎｃｉｐｌｅｓ， Ｔｅｃｈｎｉｑｕｅｓ，
ａｎｄ Ｔｏｏｌｓ，
Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ， １９８６，  ｐｐ．５５７−５６７）。Ｖａｒｋインタープリタは、Ｓｈａｎｔｚｉｓよりも洗練されたスキームを使用するが、可変サイズ画像バッファをサポートする。メモリ使用量を減少させるため、領域伝搬と組み合わせて結果領域を細分することは、Ｓｈａｎｔｚｉｓに由来している。
【１５８５】
プリンタマネージャ９０８（図２２１）
プリンタマネージャは画像プリンティングサービスを提供する。それは、Ａｒｔｃａｍに組み込まれたインクジェットプリンタハードウェアを制御する。それは、抽象的プリンタ制御インタフェースを提供し、プリンタパラメータの問い合わせと設定を可能にさせ、画像を印刷される。この抽象的インタフェースは、アプリケーションをプリンタインプリメンテーションの詳細から切り離し、以下の変数を含む。
【１５８６】
【表２０８】
0004309954.tif 000236
【１５８７】
【表２０９】
0004309954.tif 000237
【１５８８】
【表２１０】
0004309954.tif 000238
【１５８９】
【表２１１】
0004309954.tif 000239
プリンタマネージャは非同期イベント駆動型プロセスとして実行される。それは、連結された状態機械の組を含み、各状態機械は一つの非同期オペレーションに対応している。これらは、画像を印刷し、プリントロールを自動マウントする。プリンタマネージャのソフトウェア構造は図２２４に示されている。ソフトウェアコマンドは後述される。
【１５９０】
プリントイメージ９３０
プリントイメージは供給された画像を印刷する。これは、印刷用の画像を準備するためＶＬＩＷプロセッサ回路を使用する。ＶＬＩＷプロセッサ回路は、画像色空間を装置固有ＣＭＹに変換し、プリントヘッドで期待されるフォーマットで中間調バイレベルデータを生成する。
【１５９１】
プリントの間に、プリントロールを取り外すことができるように、用紙はプリントロールのリップに引き込まれ、ノズルはインク漏れ及び乾燥を防ぐためにキャップを被せることができる。実際の印刷がスタートする前に、従って、ノズルはキャップを取り外され、きれいにされ、用紙はプリントヘッドへ進められる。印刷自体は、画像が完全に印刷されるまで、ＶＬＩＷプロセッサからラインデータを転送し、ラインデータを印刷し、用紙を進める。印刷の終了後、用紙は裁断機で切断され、プリントロールに引き込まれ、ノズルにキャップが被せられる。残りメディア長さはプリントロールで更新される。
【１５９２】
プリントロール自動マウント１３１
プリントロール自動マウントは、プリントロールの装着と取り外しに応答する。それは、プリントロールの装着と取り外しのイベントを生成し、このイベントは、アプリケーションによって処理され、状態表示を更新するため使用される。プリントロールは、プリントロールに組み込まれた認証チップと、Ａｒｔｃａｍに組み込まれた認証チップとの間でプロトコルに従って認証される。プリントロールが認証を失敗した場合、プリントロールは拒絶される。種々の情報がプリントロールから抽出される。用紙及びインク特性は、印刷プロセス中に使用される。残りメディア長さ及びメディアの固定ページサイズは、いずれにしても、プリントマネージャにより公表され、アプリケーションによって使用される。
【１５９３】
ユーザインタフェースマネージャ９１０（図２２１）
ユーザインタフェースマネージャは図２２５により詳細に示され、ユーザインタフェース管理サービスを提供する。それは、状態表示及び入力ハードウェアを制御し物理的ユーザインタフェースマネージャ９１１と、カラーディスプレイ上の仮想グラフィカルユーザインタフェースを管理するグラフィカルユーザインタフェースマネージャ９１２と、を含む。ユーザインタフェースマネージャは、仮想及び物理的入力をイベントに翻訳する。各イベントはそのイベントのために登録されたプロセスのイベントキュー入れられる。
【１５９４】
ファイルマネージャ９０５（図２２２）
ファイルマネージャは、ファイルマネージメントサービスを提供する。それは、統合階層ファイルシステムを提供し、その中では、全てのマウントされたボリュームのファイルシステムが現れる。Ａｒｔｃａｍで使用される一次着脱式記憶媒体はＡｒｔＣａｒｄである。Ａｒｔｃａｒｄは、２値のドットのブロックによって高解像度で印刷され、２値のドットのブロックは、誤差を許容するリード・ソロモン符号化２値データを直接表現する。ブロック構造は、（Ａｒｔｃａｍで初期には使用されていない）適当なリード−ライトＡｒｔＣａｒｄ装置における追記及び追記−書き換えをサポートする。より高いレベルでは、ＡｒｔＣａｒｄは、拡張型追記−書き換え可能ＩＳＯ９６６０準拠ＣＤ−ＲＯＭファイルシステムを含み得る。ファイルマネージャのソフトウェア構造、及び特に、ＡｒｔＣａｒｄ装置コントローラは、図２２６に示されている。
【１５９５】
ネットワークマネージャ９０４（図２２２）
ネットワークマネージャは、赤外線（ＩｒＤＡ）及び汎用シリアルバス（ＵＳＢ）を含む様々なインタフェース上での家電製品ネットワーキングサービスを提供する。これは、Ａｒｔｃａｍシステムが撮影された画像を共有し、印刷のための画像を受信できる。
【１５９６】
クロックマネージャ９０７（図２２２）
クロックマネージャは日付及び時刻のクロックサービスを提供する。それは、Ａｒｔｃａｍに組み込まれたバッテリバックアップ型リアルタイムクロックを利用し、ユーザが時刻をセットしたときに実行される自動キャリブレーションに基づいて、クロック変動を自動的に調節する程度までそれを制御する。
【１５９７】
パワーマネージメント
システムが使用されていないとき、システムは、入力イベントの周期的走査が行われる休止電力状態に入る。入力イベントは、ボタンの押下、又はＡｒｔＣａｒｄの挿入を含む。入力イベントが検出されると直ぐに、Ａｒｔｃａｍ装置は、動作電力状態に戻る。その後、システムは入力イベントをいつもの通りに取り扱う。
【１５９８】
システムが動作電力状態であるときでさえ、個々のモジュールに関連したハードウェアは、典型的に窮し電力状態にある。これは、全体的な電力消費を削減し、プリンタの用紙切断機のような特に浪費のもとになるハードウェアコンポーネントが動作中に電源を独占できるようする。カメラ指向のＡｒｔｃａｍ装置は、デフォルトで、画像撮影モードである。即ち、カメラは動作状態であり、プリンタのような他のモジュールは休止状態である。つまり、カメラ以外の機能が始動されたとき、アプリケーションはカメラモジュールを明白に一時停止させなければならない。他のモジュールは、待機状態になると、自発的に一時停止する。
【１５９９】
ウォッチドッグタイマー
システムは、周期的な優先度の高いウォッチドッグタイマー割込を生成する。割込ハンドラーは、システムが最後の割込以降、進んでいない、即ち、システムが故障していると判断した場合、システムをリセットする。
【１６００】
代替プリントロール
他の一実施形態では、適切に簡単に一つにはめ込まれた射出成形プラスチック部品によって大部分を構築することができる改良された形態のプリントロールが提供される。改良された形態のプリントロールは、多少構造が単純化されると共に、インク貯蔵容量が増加している。画像が印刷されるべきプリントメディアは、構造を簡単化するため、プラスチック製スリーブフォーマーの周りに巻き付けられる。インク媒体リザーバは、インクが流れ出る可能性ができるだけ少なくなる構造にされた一連の通気孔を有する。更に、ラバーシールがインク出口孔に設けられ、ラバーシールはプリントロールをカメラシステムに挿入する際に穿刺される。更に、プリントロールは、プリントメディア排出スロットを含み、排出スロットは周囲に成形された表面を有し、その表面は、プリントメディア放出スロットが、印刷又はカメラシステム内のプリントヘッドに対して正確な位置に置かれるように補助する。
【１６０１】
次に、図２２７から図２３１を参照すると、図２２７には、組み付けられた形式のシングルポイントロールユニット１００１が示され、部分的に切断されてプリントロールの内部が表されている。図２２８及び図２２９は、それぞれ、左側及び右側の分解斜視図である。図２３０及び図２３１は図２２７から図２２９の内部コア部１００７の拡大斜視図である。
【１６０２】
プリントロール１００１は、内部インク補充部を含む内部コア部１００７の周りに構築される。コア部１００７の外側にはフォーマー１００８が設けられ、フォーマーの周りに、用紙又はフィルム補給品１００９が巻き付けられる。用紙補給品の周りには、二つのカバー部品１０１０、１０１１が設けられ、プリントロールの周りで一体としてスナップ式に留まり、図２２７に示されるようにカバーユニットを形成する。下側カバー部品１０１１はスロット１０１２を含み、そのスロットを通って、プリントメディア１００４の出力がカメラシステムと相互連結する。
【１６０３】
二つのピンチローラー１０３８、１０３９が用紙を駆動ピンチローラー１０４０に圧迫するため設けられるので、それらは、一体として、ローラー１０４０の周りで用紙のカールを取り去る。このカールの取り除きは、長期間に亘ってプリントロールの形で蓄えられている用紙に加わる強いカールを打ち消すように作用する。ローラー１０３８、１０３９は、カバーベース部１０７７の端部及びローラーとスナップ式にフィットするため設けられ、ローラー１０４０は、駆動用の歯車付きの端部１０４３を含み、上側カバー部品１０１０とスナップ式にフィットし、用紙１００４を間でしっかりと締め付ける。
【１６０４】
カバー部品１０１１は、端部隆起又はリップ１０４２を含む。端部リップ１０４２は用紙の出口孔を、カメラシステム内の対応した印刷熱プラテン構造体と正確にアライメントするため設けられる。このようにして、既存の用紙は、近傍のプリントヘッドに対して、正確にアライメント又は位置決めされ、用紙をプリントヘッドへ完全に案内する。
【１６０５】
図２３０及び図２３１を参照すると、射出成形部品から形成可能である内部コア部の分解斜視図が示され、このコア部は、内部スポンジ部分１０３４から１０３６を有する３個のコアインクシリンダが中心に置かれている。
【１６０６】
コア部の一端には、一連の通気チャンネル、例えば、１０１４から１０１６が設けられる。各通気チャンネル１０１４から１０１６は、第１の孔、例えば、１０１８を外部接点１０１９と相互連結し、外部接点は雰囲気に相互連結される。通気チャンネル、例えば、１０１４が後に続く通路は、好ましくは、曲がりくねった性質があり、あちこちに曲がりくねっている。通気チャンネルは、シーリングテープ１０２０の一部分によってシールされ、シーリングテープはコア部の端に被せられる。シーリングテープ１０２０の表面は、好ましくは、疎水性を高めるため、疎水性的に処理されているので、流体部分が通気チャンネルに進入することを防ぐ。
【１６０７】
コア部１００７の第２の端には、３個の厚くなった部分１０２４、１０２５及び１０２６を含むラバーシーリングキャップ１０２３が設けられ、厚くなった各部分は一連の疎らな孔が存在する。例えば、部分１０２４は、疎らな孔１０２９、１０３０及び１０３１を含む。疎らな孔は、別個の厚くなった部分の各々からの１個の孔は１本の直線に並ぶように配置される。例えば、疎らな孔１０３１、１０３２及び１０３３（図２３０）は、全てが１本の線に並び、各孔は別個の厚くなった部分に由来する。厚くなった部分の各々は、対応したインク供給リザーバと対になり、３個の孔が穿刺されたとき、対応したリザーバと流体連通する。
【１６０８】
端部キャップユニット１０４４は、コア部１００７に取り付けられる。端部キャップ１０４４は、認証チップ１０３３を挿入するためのアパーチャ１０４６を含み、その上、３個の突起を含む延長されたアダプタ（図示せず）を含み、３個の突起は、対応した孔（例えば、１０４８）を貫通し、シール１０２３の厚くなった部分（例えば、１０３３）を穿刺し、対応したインクチャンバー（例えば、１０３５）と相互連結する。
【１６０９】
更に、端部１０４４には、認証チップ１０３３が挿入され、認証チップは、プリントロールのカメラシステムへのアクセスを認証するため設けられる。したがって、このコア部は、３個の別個のチャンバーに分割され、各チャンバーは、別の色のインクと、内部スポンジと、を収容する。各チャンバーは、第１の端にインク出口を含み、第２の端に通気孔を含む。シーリングテープ１０２０のカバーは通気チャンネルを覆うために設けられ、ラバーシール１０２３はインクチャンバーの第２の端をシールするため設けられる。
【１６１０】
内部インクチャンバースポンジ、及び疎水性チャンネルは、プリントロールを移動可能な環境、多種多様な向きでも利用できるようにさせる。更に、スポンジは、それ自体に疎水化処理をすることができるので、インクをコア部から順序正しく追い出すことができる。
【１６１１】
一連のリブ（例えば、１０２７）は、コア部１００７とプリントロールフォーマー１００８との間の摩擦的接触を最低限にさせるため、コア部の表面に設けることができる。
【１６１２】
プリントロールの殆どの部分は、射出成形プラスチックから構成することが可能であり、プリントロールは、大きい内部インク貯蔵容量をもつ。簡単化された構造は、用紙のカールを取り除くメカニズムと、漏れを最小限に抑えるインクチャンバー通気孔と、を含む。ラバーシールは、インク供給チャンバーとの間に効率的な通路を設けるので、動作的能力が高まる。
【１６１３】
Ａｒｔｃａｒｄは、勿論、それ以外の様々な環境で使用される。例えば、Ａｒｔｃａｒｄは、組み込み型及びパーソナルコンピュータ（ＰＣ）アプリケーションの両方で使用可能であり、大量のデータ又はコンフィギュレーション情報への使い勝手のよいインタフェースを提供する。
【１６１４】
この結果として、多数のアプリケーションが見込まれる。例えば、ＡｒｔＣａｒｄリーダーはＰＣに取り付けてもよい。ＰＣのアプリケーションは多種多様である。最も簡単なアプリケーションは、低コスト読み出し専用配布媒体である。ＡｒｔＣａｒｄは印刷されるので、社内のデータ配布のため使用されるならば、監査の証跡を与える。
【１６１５】
更に、ＰＣは、しばしば、クローズドシステムのベースとして使用されるが、多数のコンフィギュレーション上のオプションが存在する。複雑なオペレーティングシステムのユーザ用インタフェースに頼るのではなく、ＡｒｔＣａｒｄをＡｒｔＣａｒｄリーダーに単に挿入するだけで、あらゆるコンフィギュレーション上の必要条件を満たすことができる。
【１６１６】
ＡｒｔＣａｒｄの裏面は、アプリケーションとは無関係に、同一の視覚的外観を備えているが（なぜならば、データを格納しているからである）、ＡｒｔＣａｒの表面はアプリケーションに依存している。表面は、アプリケーションの状況においてユーザに理解される。
【１６１７】
したがって、図Ｚ３５の装置は、本、新聞、雑誌、技術マニュアル等の形で情報の効率的な配信を行う。
【１６１８】
更なるアプリケーションでは、図Ｚ３６に示されるように、Ａｒｔｃａｒｄ８０の表面は、サンプル画像に適用される芸術的な効果を含む画像を表示する。カード８０の裏面にプログラムされたデータを読み出すカードリーダー８２を含むカメラシステム８１を準備し、アルゴリズム的なデータをサンプル画像８３に適用して出力画像８４を生成することが可能である。カメラユニット８１は、オンボードインクジェットプリンタと、サンプル画像データを処理するために十分な処理手段と、を含む。ＡｒｔＣａｒｄの構想の更なるアプリケーションは、ＢｉｚＣａｒｄと呼ぶものであり、会社情報を名刺に記憶させる。ＢｉｚＣａｒｄは、会社情報の新しいコンセプトである。ｂｉｚＣａｒｄの表面は、図Ｚ３７に示されるように、外観と機能の点で現在の普通の名刺と全く同じである。それは、写真と連絡先情報とを含み、名刺と同じように多種多様なカードスタイルがある。しかし、各ｂｉＺＣａｒｄの裏面は、黒色ドットと白色ドットの印刷された配列を含み、会社に関する１から２メガバイトの情報を保持する。その結果は、３．５インチ形ディスケットの記憶装置が各名刺に取り付けられていることと同じである。
【１６１９】
情報は、会社情報、特定製品シート、ウェブサイトポインタ、電子メールアドレス、経歴等、ｂｉｚＣａｒｄの所有者が望む情報であれば何でも構わない。ＢｉｚＣａｒｄは、ＵＳＢポートを用いて標準的なＰＣに接続可能なＰＣ付属型カードリーダーのような如何なるＡｒｔＣａｒｄリーダーでも読むことが可能である。ＢｉｚＣａｒｄは、ドキュメントとして専用組み込み装置に表示させてもよい。ＰＣの場合、ユーザはそのｂｉｚＣａｒｄをリーダーに挿入するだけでよい。ｂｉｚＣａｒは、好ましくは、ウェブサイトと全く同様に、通常のウェブブラウザを使用してナビゲートされる。
【１６２０】
所有者の写真及びデジタル署名を、会社の公開鍵へのポインタと共に収容することによって、各ｂｉＺＣａｒｄは、その人が、本当にその人本人であり、且つ指定の会社のために実際に働いている人であることを電子的に検証するために使用できる。その上、会社の公開鍵を指すことにより、ｂｉＺＣａｒｄは、安全な通信を簡単に開始させることができる。
【１６２１】
ＴｏｕｒＣａｒｄと呼ばれる更なるアプリケーションは、ある都市への旅行者及び訪問者のための情報を格納したＡｒｔＣａｒｄのアプリケーションである。ｔｏｕｒＣａｒｄがＡｒｔｃａｒｄブックリーダーに挿入されると、情報は次の形式をとり得る：
＊地図
＊公共輸送機関時刻表
＊名所
＊郷土史
＊行事及び催事
＊レストラン案内
＊ショッピングセンター
ＴｏｕｒＣａｒｄは、観光客用パンフレット、ガイドブック、及び街角案内の低コスト代替物である。製造コストがカード１枚当たりわずか１セントであれば、ｔｏｕｒＣａｒｄは、観光客案内所、ホテル、及び観光地で、最低限のコスト、又は広告による資金援助があれば無料で配布可能である。ブックリーダーの携帯性は、これを旅行者にとって完璧なソリューションにする。ＴｏｕｒＣａｒｄは、ＡｒｔＣａｒｄリーダーを備わっているコンピュータが任意のウェブブラウザ上でｔｏｕｒＣａｒｄに符号化された情報を復号化することができる情報キオスクでも使用可能である。
【１６２２】
ブックリーダーの双方向性は、ｔｏｕｒＣａｒｄを非常に多用途化する。例えば、地図に格納されたハイパーテキストリンクは、呼び物ビルディングの歴史的物語を表示するために選択可能である。このように、旅行者は、その都市のガイド付きツアーに出かけることが可能であり、関連した交通機関の路線図及び時刻表は何時でも利用可能である。ｔｏｕｒＣａｒｄは、地図と、ガイドブックと、時刻表と、レストラン案内と、を別々にする必要性を無くし、各個の旅行者に対する簡単なソリューションを作成する。勿論、データカードにはこの他にも多くの利用可能性がある。例えば、新聞、学習案内、ポップグループカード、ベースボールカード、時刻表、音楽データファイル、製品パーツ、広告、テレビガイド、映画ガイド、見本市情報、雑誌のクーポンカード、レシピ、求人広告、医療情報、プログラム及びソフトウェア、競馬新聞、電子新聞、年次報告書、レストランガイド、ホテルガイド、バケーションガイド、翻訳プログラム、ゴルフコース情報、ニュース放送、コミック、気象詳細等がある。
【１６２３】
例えば、ＡｒｔＣａｒｄは、本の内容、又は新聞の内容を含み得る。このようなシステムの一例は図Ｚ３５に示され、ＡｒｔＣａｒｄ７０は、一方の面に本のタイトルを含み、もう一方の面には本の符号化された内容が印刷されている。カード７０はリーダー７２に挿入され、リーダー７２には、カードリーダー７２の折り畳みを可能にさせるフレキシブルディスプレイ７３が含まれ得る。カードリーダー７２は表示制御部７４を含み、表示制御部は、前ページへの移動、次ページへの移動、及びカードリーダー７２のその他の制御を可能にさせる。
アートカードの特別の使用
技術説明
技術０４の説明
【１６２４】
さらなる改善では、アートカム装置は、マイクロフォン装置や関連の録音技術を装備するように適当に変更される。写真が撮られる時、周囲の音環境か、その画像に関係するメッセージのいずれかを録音する機会が与えられる。そして、録音された音声は、エンコード形式により出力写真の裏面に印刷される。そのエンコード化は高い復元性を有することが望ましい。その録音された音声は写真に関係する、永久的な音声録音を提供する。次に、再生装置は、エンコードされた音声をスキャンし、この情報を復号化するために提供される。
【１６２５】
ここで、図２３３を参照すると、アートカム配列のさらなる改善１６０１が概略形式で示されており、該配列では、画像１６０２がＣＣＤセンサー１６０３により検知され、重要な計算リソースを有するアートカム中央プロセッサ１６０４に転送されるようになっている。該アートカム中央プロセッサ１６０４は、メモリー１６０５に画像を格納でき、該メモリ１６０５は、好ましくは、メモリーに結合された高速ＲＡＭＢＵＳ（登録商標）を備える。アートカム中央プロセッサ１６０４は、また、要求に応じてインスタント写真を提供するため、フルカラー写真、例えば１６０７の印刷のためにプリントヘッド１６０６の駆動を制御するようになっている。
【１６２６】
さらなる改善では、そのカメラ編成１６０１はサウンドチップ１６１０も備えており、該サウンドチップ１６１０は、ＡＣＰプロセッサ１６０４の制御下で、ＲＡＭＢＵＳ１６１１を介してメモリー１６０５に接続されている。そのサウンドチップ１６１０は、標準的又は専用形式であることができ、例えばサウンドマイクロフォン１６１３からアナログ入力１６１２を取り込むＤＳＰプロセッサを備えることができる。或いは、チップの複雑度が増大するのに従い（ムーアの法則）、サウンドチップ１６１０の機能はＡＣＰチップ１６０４内に組込まれることができ、ＡＣＰチップ１６０４は、最先端のＣＭＯＳ型集積回路チップを備えるのが好ましい。本発明の範囲内に該当する他の多くの種類の編成を提供できることは容易に明白であろう。
【１６２７】
サウンドチップ１６１０は、アナログ入力１６１２を対応するデジタル形式へ変換し、それをメモリー１６０５に格納するために転送する。録音プロセスは、カメラ装置上のボタン（図示せず）を押すことによって作動させることができ、そうでなければ、ボタンがＡＣＰプロセッサ１６０４の制御下にあって、録音プロセスは写真を撮るときに実質的に自動化されることができる。録音されたデータは、メモリ１６０５に格納される。
【１６２８】
図２３４を参照すると、カメラ編成は、好ましくは、２つのプリントヘッド１６１５，１６１６からなるプリンター装置１６０６を有し、第１のプリントヘッド１６１５はプリントメディア１６１７に画像を印刷するのに使用され、第２のプリントヘッド１６１６はプリントメディアの裏面に情報を印刷するのに使用される。
【１６２９】
図２３５を参照すると、写真メディア１６１７の裏面への見本の出力が示されている。該出力は図２３４のプリントヘッド１６１６にて印刷されたものである。その情報は、場所や日付や時間のデータ１６２０を含むことができる。そして、場所のデータは、キーボード入力により、或いは、ＧＰＳや同様のもののような、付属の位置決めシステムの利用によって与えられる。それらの情報１６２０は、印刷された画像の記録をユーザが整備するために、視認可能な形式で呈示される。重要なことは、画像１６１７の裏面には、エンコード形式の音声情報１６２２も印刷されているということである。エンコード形式は多種多様であることができるが、擦り傷、汚れ、書き込み、磨耗、回転、退色などを許容するよう、エンコード化は高い障害許容力を有する方法で行われるのが好ましい。図２３６には、データ１６２５の一部分が概略形式で示され、そのデータは、図２３４のプリントヘッド１６１６により印刷されるドット列を有する。その開示された手法は写真の裏面に約２．５メガバイトの任意のデータを保管し、この特別な場合には、音声データを含めることができる。符号化フォーマットは、データのリード・ソロモン符号化の利用に強く依存し、高い障害許容力を提供する。さらに、画像の検知を補助するよう、図２３６に示されるように、高周波“チェッカーボード状”模様がデータに追加されるように記載される。図２３４のプリントヘッドにより印刷されるドット列をデータが含むようなデータ部１６２５が図２３６に概略形式で示される。
【１６３０】
録音された音声を“再生”したいときは、読み取り装置１６２６を通り抜けるように写真１６１７を移動させる。その読み取り装置１６２６はピンチローラーを有しており、該ピンチローラーは写真を挟んだ状態で回転し、ＣＣＤリニアセンサー装置１６２７を該写真が通過するようにする。
【１６３１】
図２３８を参照すると、図２３７の音声読み取り装置１６２６の操作を示す概略形式が示されている。前記ＣＣＤリニアセンサー１６２７は第２のアートカム中央プロセッサ１６２８に接続されており、該プロセッサ１６２８は、写真の裏面に格納されているデータを読み取り復号化するよう適切に適合化されている。復号化された音声情報は、サウンド処理チップ１６３３を介してスピーカー１６２９で再生するためにメモリー１６３２に格納される。そのサウンド処理チップ１６３３はＡＣＰデコーダ１６２８の制御下で動作でき、ＡＣＰデコーダ１６２８は、音量制御、巻戻し、再生および早送り制御などを含むことのできる、種々のユーザ入力制御１６３３の下で動作する。
【１６３２】
重要なことには、上述の通り、アートカードの裏面にあたかも情報が印刷されているかのように、ＣＣＤリニアセンサー１６２７及びＡＣＰデコーダ１６２８は読み取りプロセスを実行する。
【１６３３】
好適な実施の形態の上記の説明から分るように、写真と関係する音声録音を提供するように、出力画像と関係する音声の自動録音のためのシステムが提供される。写真の裏面の画像出力を読み取るための音声読み取りシステムも開示される。
技術０６の説明
【１６３４】
さらなる改善では、先述したアートカムは、後のデジタル画像の生成に利用されるカメラの向きを自動的に決定するための装置を含む。そして、そのアートカムは、画像生成に向きの情報を利用することを適切にプログラムされている。
【１６３５】
ところで、向きの情報を使用する多くの例が添付図面を参照して説明される。図２３９を参照すると、第１のポートレート写真１８０１が示されており、該写真１８０１には、カメラシステムに入力された日付けや撮影場所情報のような、ポートレート１８０１に関連した情報を配置するために領域１８０２が用意されている。さらに、そのポートレート１８０１は、顔などのような、画像の特定の目に見える部分を変形させる画像処理技術により処理されるかも知れないと予想される。これらの変形は、写真１８０１を撮影するカメラの向き決定に依存する。また、図２３９には、カメラが回転されたポートレートモードで使用された第２のポートレートモード画像１８０３が示されている。残念なことに、横向きモードの画像１８０１の画像データ１８０２が同じ位置にあるならば、該データは、最後の画像における望まれない領域１８０５に現われる。理想的には、ポートレートモードで写真が撮影されるとき、画像の特定の情報は場所１８０６に現われるべきであろう。なお、直角で、異方性で、画像内容の特定の方法で画像に与えられる画像処理効果は、画像が回転されるときに無駄になってしまうだろう。
【１６３６】
前記向きセンサー１８４６は向きを検知し、該検知された向きはＡＣＰ１８３１によって、対応するデジタル向き角度に変換される。前記エリアイメージセンサー１８０２はカメラにより撮影される画像を検知し、該画像はＡＣＰ１８３１に転送され、メモリー記憶装置１８３３に保存される。次に、検知された向きは、撮影された画像がポートレートモードか風景モードであるかを決定するために使用される。該検知された画像はメモリー記憶装置１８３３から読み取られ、再びメモリー記憶装置１８３３に出力される前に回転される。最後の結果が回転された画像１８０８である。また、検知された向きの情報を利用するための他の技術を挙げることができる。例えば、メモリー記憶装置１８３３に保存されている検知画像は、向き情報と関連付けて保存されることができ、該向き情報は、従来の回転マトリクスマッピング、世界座標系及び局所座標系マッピングに利用される。続いて、その情報の処理を行うコンピュータ・グラフィック・アルゴリズムは、回転向きに画像を操作するように処理している最中にその座標系を使用することができる。位置検知情報（例えば、図２３９の符号１８０６）が画像に組み入れられる場合には、このテキストは正しい向きに配置されることができる。さらに、カメラの向きは、顔検出のような、画像に適用される画像を特定するアルゴリズム技術に使用されることができる。顔の位置は大体分るので、向きの情報の利用は顔検出アルゴリズムを大幅に単純化する。
【１６３７】
向きセンサーは、例えばマーキュリーセンサのような、単純で安価な重力スイッチを含むことができ、或いは、マイクロマシンシリコン加速度計のような、より複雑な小規模の装置にすることができる。
技術０７の説明
【１６３８】
さらに、プリントローラーの他の形態が構成されることができる。図２４１を参照すると、前述した装置の修正版に利用されるようなプリントロールの他の配列が概略的に示されている。重要なことには、使い捨てのプリントロール（例えば、１９１０）は、インクを集めることを許容するスポンジ部１９１２を有する“延長されたリーフ部分１９１１”を備える。従って、プリントヘッドを横切るように搬送されるフィルムや紙の端縁部へのプリントヘッドによる印刷を許容するため、運転中、前記スポンジ部１９１２はプリントヘッドの下方に配置される。
【１６３９】
そのスポンジ部１９１２は、使い捨てのプリントロール１９１０の一部を形成するので、プリントロールを使い切ったときにカメラの外に取り出され、それによって、余分の不用なインクがプリントヘッドから取り除かれる。
技術０８の説明
【１６４０】
さらなる実施例では、最大のコントラストを確保するＣＣＤデータストリームの処理によりオートフォーカスが実行される。ＣＣＤデータストリームに基づき焦点位置を決定する技術は公知である。例えば、Ｂｕｔｔｅｒｗｏｒｔｈ−Ｈｅｉｎｅｍａｎｎによって１９９３年に出版され、Ｌｅｓｌｉｅ  ＳｔｒｏｅｂｅｌとＲｉｃｈａｒｄ  Ｚａｋｉａにより編集された“Ｔｈｅ  Ｅｎｃｙｃｌｏｐｅｄｉａ  ｏｆ  Ｐｈｏｔｏｇｒａｐｙ”や、“Ａｐｐｌｉｅｄ  Ｐｈｏｔｏｇｒａｐｈｉｃ  Ｏｐｔｉｃｓ（ロンドン及びボストン、フォーカルプレス、１９８８年）”にて言及されている。これらの技術は、第一に、入力画像の一部を覆う隣接画素間のコントラスト測定を行う。その画像は、正確なオートフォーカス設定を決定するためにＡＣＰにより処理される。
【１６４１】
このオートフォーカスの情報は、特定のモード、例えば、画像の中に顔の位置を見つけようとする場合にＡＣＰによって使用され、画像における顔の大体のサイズを案内することによって顔位置検知プロセスを簡素化している。
【１６４２】
図２４２を参照すると、顔検出アルゴリズムによる調査のために大体の画像の特徴を決定すべく使用される方法の見本２００１が示されている。
【１６４３】
例えば、２００２，２００３，２００４のような様々な画像がカメラ装置により取得される。焦点設定の詳細は、オートフォーカスの操作の副産物としてＡＣＰに保存される。加えて、ズーム・モータの現在位置もまた使用される（２００６）。これらの設定のいずれもがＡＣＰにより決定される。次に、大体の奥行き位置（depth location）に応じた大きさとなる、画像中のオブジェクト（興味のあるオブジェクト）を含む画像を出力する前に、ＡＣＰは、検知した値に分析技術２００８を適用する。
【１６４４】
次に、画像におけるオブジェクトの位置を見つけるため、該奥行きの値（depth value）が、入力された検知画像２０１１に加えてＡＣＰ２０３１の顔検出アルゴリズム２０１０に利用される。近距離値２００９はポートレート画像の高い可能性を示し、中距離値はグループ写真の高い可能性を示し、遠距離値は風景画像の高い可能性を示す。この可能性の情報は顔検出の目的としても使用されることができ、オブジェクトまでの距離に依存して適用される他の技術やクリップアートと共に、画像中に“描いた”ような効果を生成したり、画像を描いたりする場合に、様々なパラメータを選択するために使用されることができる。
技術０９の説明
【１６４５】
さらなる実施例では、アートカム装置は、そのときのアイポジションを検知するアイポジションセンサーを有するように変更されることができる。その検知されたアイポジション情報は、その検知されたアイポジションに従った修正や変形等を行うため、カメラにより撮影されたデジタル画像を処理するために使用される。
【１６４６】
アイポジションセンサーの構成は当業者に知られており、多くの製品のカメラ（特に、キヤノン社のカメラ）にて使用されている。アイポジションセンサーは、ビューファインダから視聴者の目への赤外線の照射と、大体のアイポジションを決定するために検出され使用される反射とに依存している。
【１６４７】
図２４３を参照すると、アイポジション情報２１１０と画像２１１１とはアートカムのメモリーに格納されており、ＡＣＰによって処理が行われ（２１１２）、その処理画像は、プリントヘッドにより写真として印刷するために出力される。画像処理２１１２の形態は、アイポジション情報２１１０に依存してかなり変化されることができる。例えば、画像処理の第１の形態においては、画像中の顔の位置を検出して、様々なグラフィック・オブジェクト（例えば、顔との関係で一般的にオフセットしている吹き出し）を適用するために、顔検出アルゴリズムが画像２１１１に適用される。そのようなプロセスの一例が図２４４に示されており、第１の画像２１１５は３人の人間を示している。前記顔検出アルゴリズムの適用により、３つの顔２１１６，２１１７，２１１８が検出される。そして、アイポジション情報は、フレーム中に推定された目に最も近い顔選択するために使用される。第１の例においては、吹き出しは頭２１１６に対して配置される。第２の例２１２０においては、吹き出しは頭２１１７に対して配置され、第３の例２１２１においては、吹き出しは頭２１１８に対して配置されている。したがって、画像中の所定の顔の上方に吹き出し文字を配置するために、アートカードは、吹き出し適用アルゴリズムのコード化された形態と、処理された画像とを含むように提供される。
【１６４８】
アイポジション情報は多くの異なる方法で画像２１１１を処理するために使用することができるということは容易に理解される。局所的な、或いは特定の方法で焦点合わせの効果を適用し、顔やオブジェクトに特定の変形を与えることができる。さらに、行われた画像処理は、画像の芸術的な演出を含み、該演出は、芸術的な絵筆技術を適用することを含む。その芸術的なブラッシング方法は、アイポジション情報２１１０に従って特定の方法で適用され得る。最終的な処理画像２１１３は、要求に応じて印刷され得る。さらなる画像が撮影され、異なる出力画像の生成のため、異なるアイポジションが検出され使用される。
技術１０の説明
【１６４９】
さらなる改善では、アートカムは、撮影画像の明るさのレベルを決定するために自動露出センサーを有するように構成変更されている。この自動露出センサーは、画像の一部分を引き立たせるため、設定された露光量に従って画像を処理するために使用される。
【１６５０】
望ましくは、前記エリアイメージセンサーは、画像を撮影するときの光の状態を決定するための装置を有する。該エリアイメージセンサーは、検出したレベルに従って、ＣＣＤにより取得されたダイナミックレンジの値を調整する。取得した画像はアートカム中央プロセッサに送られ、メモリーストアに格納される。前記エリアイメージセンサーにより測定された強度情報は、また、ＡＣＰに転送される。この情報は、保存されている画像に特定の効果を与えるため、ＡＣＰによって使用される。
【１６５１】
図２４５を参照すると、ＡＣＰによって画像を処理するため、自動露出設定情報２２０１が、保存されている画像２２０２に関連して使用される。処理された画像は、後でプリンターで印刷２２０４するためにメモリーに戻される。
【１６５２】
所定の光の状態に従って多数の処理ステップが実施されることができる。暗い場所で画像が撮影されたことを自動露出設定情報２２０１が示す場合には、画像の色をより強く、より深く、より鮮やかにするために、画像の画素の色が選択的にリマップされる。
【１６５３】
写真が撮影されるときが明るい状態であると自動露出情報が示す場合には、より明るく、よりサチュレートするように画像の色が処理される。画像の再配色は、色相・彩度・明度（ＨＳＶ）フォーマットに画像を変換し、要求に従ってピクセル値を変更することにより行うことができる。該ピクセル値は、印刷の出力色フォーマットに変換して出力することができる。
【１６５４】
もちろん、数多くの異なる再配色技術が使用されるかも知れない。それらの技術は、好ましくは、読み出し装置に挿入されるアートカードに明確に示されている。他の方法としては、ある状態での使用のため、画像処理アルゴリズムが自動的に適用され、カメラの中に組み込まれることができる。
【１６５５】
他の方法としては、挿入されたアートカードは、画像に適用される、自動露出設定に限定された、多くの取扱いを有することができる。例えば、暗い画像には、蝋燭等を含むクリップ・アートが挿入されることができ、明るい画像には大きな太陽が挿入されることができる。
技術１１の説明
【１６５６】
フラッシュを使用した結果、取得画像に生じる“赤目”の影響を除去することは、重要な処理の１つである。図２４６を参照すると、さらなる改善において、ＣＣＤ装置により取得された画像は、フラッシュが使用されていた場合には、印刷のために処理された出力画像を形成するため、処理ステップ３を受けさせる。図２４７を参照すると、ＣＣＤ装置による画像の取得の際にフラッシュが使用されていた場合に使用されることのできる、１つの特別な画像処理アルゴリズム２３１０が、より詳細に示されている。そのアルゴリズムは、好ましくは、ＣＣＤにより画像を取得するためにフラッシュが使用されたときにのみ使用される（２３１１）。そのアルゴリズムの目的は、フラッシュの利用による画像への影響を低減することである。そのような画像の影響は、写真画像において個々の眼が赤く見えるという、周知の“赤目”影響を含むことができる。また、フラッシュ光の反射面からの反射などのような他の影響は、別途、他のアルゴリズムを使用して処理することができる。画像における赤目の影響を排除するための第１ステップは、画像中における顔を決定することである（２３１２）。何らかの他の画質増強や色修正を行った後、通常光の下で人間の顔の色についてのＨＳＶの値の地図で近接する範囲を決定することにより、顔検出プロセスが実行される。検出された範囲については、目や口や全体形状や重なりの決定を含む、様々な簡単なテストがなされる。その簡単なテストは、顔の可能性についての結果を生じさせることができ、閾値以上の場合には、画像での顔の位置を決定することができる。
【１６５７】
画像の中で顔が決定されると（２３１２）、その顔の中で眼の位置が見つけられる（２３１３）。そして、赤目除去処理が必要かどうかを決定するため、特別な範囲の色を判断する処理がそれぞれの眼に個別に行われる。もし、赤目除去処理が必要とされるならば、出力画像において、如何なる不連続さや起こり得る不自然さを生じないようにさせながら、赤色を減少させるようにすべく、目のエリアに対して修正アルゴリズムが適用される。もちろん、眼の中心点の周りのガウシアン・デグリーの形式を含む多くの異なる技術が使用される。最後に、メモリーストア２３３３の裏にアップデートされた形式で画像が書き込まれる（２３１６）。
【１６５８】
望ましくは、この時点で、フラッシュ光のスペクトル特性の影響を受けた色をリマップすることを含む、他の修正アルゴリズムが使用される。代わりに、挿入されるアートカードが、画像に適用される多くの処理（フラッシュの設定を特定する処理）を行うようにしても良い。例えば、蝋燭や光の球体（light globe）等のクリップアートが、如何なる閃光も無い画像中に閃光や大きな太陽が挿入されても良い。
技術１２の説明
【１６５９】
さらなる改善においては、第２のインクジェットが写真の裏面への印刷のために用意されている。図２４８には、標準的な配列の概略図が示されている。ローラー（例えば、２４０４）に挟まれる紙２４０３に写真を印刷するためにプリントヘッド２４０２が用意されている。２つのインクジェット・プリントヘッド２４０２，２４１１を備えるという実施例に従い、図２４９には代替案２４１０が示されている。プリントヘッド２４１１は、写真に関連のある重要な情報を写真２４０３の裏面に印刷するために用意されている。例えば、その写真を撮った時間や日付が、そのインクジェット・プリントヘッド２４１１によってその裏面に印刷されることができる。加えて、そのアートカム装置はグローバル・ポジショニング・センサーを備えるかも知れない。該センサーは、アートカム中央プロセッサによってデータ取り出しが行われ、その写真が撮られた場所を確定するために利用されるかも知れない。この付加情報は、また、写真出力２４０３の裏面に印刷されるかも知れない。
技術１３の説明
【１６６０】
プリントロールは堅く巻かれた形態で提供される。残念なことに、プリントロールを堅く巻いた結果として、プリントメディアの特性が、アートカムシステムにより出力される写真には過量のカールがもたらされるというようになるかも知れない。
【１６６１】
図２５０を参照すると、３個のローラー配列２５１１−２５１３を有するシステムを提供する、プリントロールの別の配列が示されている。そのローラー配列は、プリントロールを抜け出たプリントメディア２５１４に、しっかりとしたアンチカールを与える。それらの３つのローラー２５１１−２５１３はメディア２５１４を挟み込み、ピンチローラー（例えば、２５１７）によってプリントヘッド２５１６へ搬送される前にその紙にアンチカールを与える。それらの３つのローラー２５１１−２５１３は、プリントロールケース、或いはアートカム装置の内部に配置されることができる。
技術１５の説明
【１６６２】
図２５１を参照すると、さらなる改善では、観察者２７０３に、立体的、或いは疑似三次元的な効果で見せるような写真画像を作ることが望まれる。これらの効果は、２つの画像をすぐ近くに同時に記録し、１つ目の画像を観察者の右眼２７０４に与え、２つ目の画像を観察者の左眼２７０５に与えることにより得ることができる。左眼と右眼のために画像を記録し、そして左眼には左の立体的画像を見せ、右眼には右の立体的画像を見せることにより、３次元の立体効果を作り出すことができる。
【１６６３】
さらなる改善では、左右の眼の画像を取得する、一連のレンズ状の透明な柱によって、写真や立体画像２７０２は、以下のように、よりはっきりとなるように、構成されるだろう。
【１６６４】
図２５２を参照すると、写真紙２７０２の表面部分の断面図が示されている。断面図２７１０に明らかなように、写真紙は、左右の立体視が可能となるようにデザインされた、一連のレンズ状の列を有する。画像は、透明な写真紙２７１０の底面２７１２に印刷される。
【１６６５】
１つの画素のピッチ２７１３は８０μｍで、ドットの配列ピッチ２７１４は２０μｍである。それ故に、１つの画素につき４つのドット２７１４−２７１７が配置される。２つのドット２７１４−２７１５は左側の立体視のために用意され、２つのドット２７１６−２７１７は右側の立体視のために用意される。その写真紙を見る右眼は右側の画素ドット２７１６，２７１７の像を取得し（２７２０，２７２１）、左眼は左側のドット２７２５，２７２６の像を取得する（２７２３，２７２４）。それ故、２つの画像がそれぞれの眼に別々に示され、実体写真効果が生じる。主として、２７１１のような各列（ｃｏｌｕｍｎ）のレンズ状の外形に起因する実体写真効果。
【１６６６】
ここで、図２５３を参照すると、紙２７１０の下面部の斜視図が示されている。図２５３の説明図は、４つのドット２７３１−２７３４を有する画素のピッチに加えて、各ドット２７３０のドットピッチを示すために作図線を含む。図２５３に明らかなように、右側立体視のために用意された２つのドット２７３１−２７３２、及び、左側立体視のために用意された２つのドット２７３３−２７３４の４つのドットにより各画素が構成される。そのドット、例えば、２７３０はプリントメディア２７１０に配置されているので、該メディアが裏返された時に、正しい立体視が行われる。
【１６６７】
ここで、図２５４を参照すると、立体画像を撮像する１つの方法が論じられるだろう。望ましくは、携帯用カメラ装置に配置されたＣＣＤカプラー２７４０，２７４１により２つの画像が撮像される。各ＣＣＤ装置２７４０，２７４１は別々の画像を取得し、それら別々の画像は、図２３５に示されるような左右交互の方法で、立体処理ユニット２７４２にて結合されるべきである。画像が立体処理ユニット２７４２にて正しく交互配置されると、その画像は、プリントエンジン２７４３、及び、写真紙２７１０の表面２７４６にその画像をプリントするプリントヘッド２７４４に送られる。
【１６６８】
写真紙２７１０の現在位置が位置合わせユニット２７５０により検知され、その現在位置が、プリントヘッド２７４４の制御のためにプリントエンジン２７４３によりフィードバックされる。その位置は、ＬＥＤタイプの装置２７８０がプリントメディア２７１０のレンズ状面を照らすと共に、プリントメディア２７１０の反対側の光導電体２７８１が周期的な明るさの変化を測定することにより決定される。
【１６６９】
図２５５を参照すると、破線２７５０により示される位置合わせユニットの動作がここでさらに説明される。写真紙２７１０はローラー２７５１，２７５２に挟まれ、ローラー２７５２は、写真紙（プリントメディア）２７１０のレンズ状面２７５４に一致する面を有するように構成されている。その写真紙２７１０のレンズの周期が２７８０ｍｍのオーダーなので、ローラー２７５２の表面は、写真紙２７１０のレンズ状面のように、誇張して示される。レンズ状写真紙の緻密な周期は、ローラー２７５２がプリントメディアの他の形態にも同様に使用できることを意味している。
【１６７０】
ローラー２７５２の表面は、ローラー２７５２との一定の空間的関係をプリントメディア２７１０が維持することを保証する。従って、要求に応じてローラー２７５２を回転し、それによってプリントヘッド２７４４を通過するようにプリントメディア２７１０を搬送するように、プリントローラー２７５１，２７５２はプリントエンジン２７４３の制御下で位置合わせユニット２７５０によりモニターされながら駆動される。結果として、プリントヘッド２７４４により印刷されるドットとレンズ状列との位置の合致が維持される。
【１６７１】
プリントメディア２７１０がプリントヘッドを通過するように搬送される際に、プリントヘッド２７４４により立体画像をプリントすることができる。プリントヘッド２７４４としては、フルページ幅のプリントヘッドが望ましい。
【１６７２】
もちろん、プリントヘッド２７４４に関連する、プリントメディア２７１０の現在位置を他の装置により決定することも可能である。
【１６７３】
図２５６を参照すると、好適な形状のレンズ状紙２７６１と、対応するインク供給（不図示）とを有するプリンターロール２７６０を結合することにより、カメラ装置が、提案された実施例の原則に従って提供され得る。その紙２７６１は、プリントローラー２７６０からピンチローラー２７６３，２７６３によってプリント装置２７６４に取り出される。該プリント装置２７６４は、さらに、ピンチローラー２７６５，２７６６、カッター２７６７、プラテン２７６９、ピンチローラー２７５１，２７５２、及びプリントヘッド２７４４を有する。立体画像はプリントヘッド２７４４によってプリントされ、その紙２７６１がカッター２７６７により切断された後に取り出される。その出力２７７０は透明な形態である。
【１６７４】
図２５７を参照すると、画像の排出物２７７０の上に、平坦な白の面２７７１を付着することができる。これは、透明２７７０を貼り付ける粘着面の使用により成し遂げられる。続いて、左右のステレオ画像を生成して、撮影画像に三次元効果を与えるように、図２５１に示されるように、レンズシステムを通して画像が視認される。図２５６に描かれたカメラシステムは、理想的には、写真を撮影して直ぐに立体写真を得たい場所に運ぶことができるような携帯用である。
技術１７の説明
技術２１の説明
【１６７５】
さらなる改善では、堅くロール状に巻かれて格納される画像メディアは、異方性のリブ構造を持つように処理され、ロール状で運ぶのに好適で、該プリントメディアに印刷された画像を見るときには該プリントメディアのカール度合いが減少されるようになっている。
【１６７６】
ここで図２５９を参照すると、この改善の本質に従って取り扱われるプリントメディア３３１１が示されている（３３１０）。該プリントメディア３３１１は、他の形態が好適だけれども、プラスチックの平面的なフィルムにて構成される。該プリントメディア３３１１は、図２５９の拡大図に示されるように、ポリマーのリブ状構造３３１２を有するように前処理されており、実際の列のピッチが約２００ｍである。したがって、該プリントメディア３３１の一方の表面は、該プリントメディア３３１の全長を上下に走行する一連の列３３１２を有するように処理されている。該列３３１２の断面は図に拡大図で示されている。
【１６７７】
一連の列３３１２を使用することのメリットは、プリントメディア３３１１の表面部分に力３３１３が加えられた場合に明らかである。その列３３１２は、プリントメディア３３１１が堅く巻かれることを許容する一方で、３３１６の向きにプリントメディア３３１１が巻かれることに抵抗する。従って、加えられた如何なる力３３１３も、３３１５及び３３１６の両向きに伝達しそうである。そのメディア３３１１の異方性の性質は、３３１５及び３３１６の両向きに支持を与えるように機能するリブ３３１２によってもたらされ、それによってメディア３３１１のカールを制限する。また、その材料の異方性の強度は、ロールの中心軸に沿った強度で格納されることが許容される。
【１６７８】
図２６０を参照すると、ユーザの手３３２０，３３２１の中で画像３３１１を単に保持して、ポイント３３２４，３３２５に僅かな圧力を与えることによって、カーリングによる効果を減少させて、メディア３３１０上の画像を見ることができる。
【１６７９】
もちろん、異方性のメディアは、該メディアがプラスチック材料を含んでいる場合には多くの技術を利用して製造されることができる。例えば、それは、押し出し成形法により製造されることができる。或いは、他の技術が利用され得る。例えば、１つの製造方法が図２６１に模式的に示される（３３４０）。該方法では、ローラー３３４２，３３４３の間でメディア３３４１がプレスされるようになっている。図２６１（ａ）に示すように、ローラー３３４３はフラットな面を有し、ローラー３３４２はギザギザのある面３３４５を有している。説明のため、鋸状の外形は図２６１に拡大されている。
【１６８０】
メディアがそのようなプロセス３３４０での利用に適していない場合、異方性メディアは、互いに貼り合わされた２枚のフィルムの面を利用することによってもたらされる。そのようなプロセス３３５０は図２６２に示される。画像の印刷が望まれる第１面３３５１は、接着剤や熱融合等の方法によって要求通りに第２面３３５２に貼り付けられる。
【１６８１】
さらに、プリントメディアの製造の他の方法が可能である。例えば、図２６３及び図２６４を参照すると、プリントメディア３３６０の構造が断面図で示される。該プリントメディア３３６０の構造は、繊維型の中に引かれる、軟ポリエチレン・ナフタレートにより形成された繊維からなる強化ポリマーを含む第１繊維材料３３６１から形成される。ポリエチレン等を含む第２の熱流動ポリマー（ｈｅａｔ−ｆｌｏｗａｂｌｅ−ｐｏｌｙｍｅｒ）３３６２は、インク／画像の化学薬品のキャリッジのための“紙”の基材を提供するために使用される。繊維３３６１と印刷ベース３３６２とが、図２６４に示すように一体ユニットを形成するように、メディア・ポリマー３３６２は粘着力が残っている間（例えば、加熱後）繊維材料３３６１に押し付けられる。図２６３及び図２６４のメディアの配列は、多くの技術に従って作られることができる。次に、図２６５を参照すると、繊維状材料の成型スプール３３８０を使用する、第１のそのような技術が示されている。その技術では、多くのスプールと、対応する繊維３３８１とが、所望のプリントロール長に相当している。それらのスプール３３８０は、対応する繊維３３８１が第１ローラー３３８２に供給されるように配列されている。そして、それらの繊維３３８１は、加熱された粘着性のあるプリントメディアの層を該繊維に供給するプリントメディア塗布ユニット３３８４を通過するように引かれる。その後、ローラー３３８５，３３８６が、繊維とプリントメディアとが一つに融合するように必要な圧力を供給すると共に、最後に異方性面３３８８を形成するようにプリントメディアの面を平らにする。その後、該面３３８８は裁断され、上述のように異方性プリントメディアを形成するように巻かれる。
【１６８２】
もちろん、要望に応じて繊維状材料の形成を他の形態で行うことが可能である。例えば、図２６６には、タンク３３９０からファイバ３３９１を引く方法により繊維状材料を押し出して生成する１つの形態が示されている。図２６６の装置は図２６５のスプール３３８０に置き換えることができる。
技術２４の説明
【１６８３】
さらなる改良版では、前記アートカムシステムに利用されるアルゴリズムが説明される。該アルゴリズムは、入力画像中における一群の画素を、出力画像では“ブラッシュストローク”で置き換えることにより、写真画像を“描いた”ような演出に自動変換するものである。該アルゴリズムは、ブラッシュストロークをヴァン・ゴッホ・スタイルに近付けるように、画像中のフラットな部分での主要なエッジを自動検出し、該エッジの方向の情報を増殖させる（propagate）ように働く。該アルゴリズムは、前述のアートカム装置にて履行するのに好適である。
【１６８４】
まず、図２６７を参照すると、そのアルゴリズムは多くのステップ３６０１を含む。これらのステップは、エッジを検出するために画像のフィルタリングをする第１ステップ（３６０２）を含む。次に、それらのエッジは、最終的なエッジを決定する処理（３６０５）の前に、閾値処理、或いは“スケルトン処理（３６０４）”される。そして、それらのエッジにベジエ曲線が適合（ｆｉｔ）される。次に、該曲線はオフセットされ（３６０７）、最終的な画像にブラッシュストロークが描かれる（３６０８）。それらの処理３６０７，３６０８は、画像がブラッシュストロークにより十分に覆われるようになるまで繰り返される。その後、画像への最後の“修正”が実行される（３６０９）。
【１６８５】
次にそれぞれのステップをより詳細に説明する。エッジを検出するためにフィルタリングをする第１のステップ（３６０２）では、図２６８に示すような係数の集合３６１２，３６１３を持つソーベル（Ｓｏｂｅｌ）の３×３のフィルターが前記画像に適用される。ソーベルフィルターはデジタル画像処理にて使用される、良く知られたフィルターであり、その特性は、マサチューセッツのＡｄｄｉｓｏｎ−Ｗｅｓｌｅｙ出版社により１９９２年に出版された、規範となる教科書“デジタル画像処理”にてＧｏｎｚａｌｅｚ及びＷｏｏｄｓにより１９７−２０１頁に完全に討論されている。ソーベル微分フィルターは、フィルタリング前に画像をグレースケールに変換するか、或いは、画像を各カラーチャネルにフィルタリングして最大値を取ることにより適用されることができる。ソーベルフィルタリングにより、画像の画素単位のエッジ強度を示すグレースケール画像が作成される。
【１６８６】
次に、対応する二値画像を作成するために閾値処理が行われる（３６０３）。その閾値を変化させることができるが、最大強度値の５０％の値が適切である。エッジを強化した画像（edge strength image）中の各画素が該閾値と比較され、もし閾値よりも大きければ“１”が出力され、閾値よりも小さければ“０”が出力される。この処理の結果、閾値エッジマップ（threshold edge map）が作成される。
【１６８７】
次に、図２６７のステップ３６０４では前記閾値エッジマップが“スケルトン処理”される。画像をスケルトンする処理は、上述参考教科書の４９１〜４９４頁や、他の標準的な教科書に完全に明確に記載されている。そのスケルトン処理は、前記閾値エッジマップにおける相当数の特徴を維持しつつ、“薄く”スケルトン化されたエッジマップを作成する。
【１６８８】
次のステップでは、画像におけるポイントのリストを含むデータ構造を生じさせる、スケルトン化されたエッジマップにおけるエッジが決定される。好ましくは、予め決められた最小値よりも長いエッジのみがリストに加えられる。
【１６８９】
前記スケルトン化された画像は、多重分岐が可能な１画素幅のエッジのみを有するので、Ｃ＋＋コード片（code fragment）で表された次のアルゴリズムは、スケルトン化された画像において切れ目のないエッジに属するポイントを決定したり同定したりする１つの方法を提示する。それは、分岐したエッジを別々のエッジに分解し、各分岐の湾曲を最小限にする方向にエッジに沿って伸びることを選択する。例えば、分岐ポイントにて、最小の湾曲を生じさせる分岐を助ける。そのコードは以下の通りである。：
0004309954.tif 000240
0004309954.tif 000241
0004309954.tif 000242
0004309954.tif 000243
【１６９０】
スケルトン化されたエッジマップにこのアルゴリズムを使用することにより、少なくとも所定のサイズを有するエッジのリストが生成される。好適なサイズは、２０画素長であることが分っている。
【１６９１】
図２６７の次のステップ３６０６では、ステップ３６０５にて得られた各エッジリストのそれぞれにベジエ曲線が適合される。エッジリストのそれぞれのため、区分的なベジエ曲線がポイントのリストに適合される。区分的ベジエ曲線を適合させる好適なアルゴリズムは、“デジタル化された曲線を自動的に適合させるためのアルゴリズム”シュナイダー，Ｐ．Ｊ．著、Ｇｌａｓｓｎｅｒ，Ａ．Ｓ．編集、Ｇｒａｐｈｉｃｓ  Ｇｅｍｓ、Ａｃａｄｅｍｉｃ出版、１９９０年にて説明されるようなシュナイダー曲線適合アルゴリズムである。このアルゴリズムは、パラメトリックの連続性ではなく幾何学的な連続性のみを目的とし、素早く収束するようにしている。シュナイダーアルゴリズムは機能的であり、もし適合度が乏しければ、最大エラー部で曲線を再分割し、該分割されたものに曲線を適合させる。次に、その分割部分での接線の推定は、分割点のいずれかのみを使用してなされる。密集した点集合のために、ローカルノイズが増幅される傾向がある。曲線を適合することの、改良された品質は、接線の基礎とした分割点から遠ざかる点を使用することで得られる。
【１６９２】
図２６７の次のステップ３６０７では、所望の“ブラッシュストローク幅”の半分だけ初期のカーブリストから曲線がオフセットされる。そのオフセットは、最初の主曲線の両側に平行となるように、互いにほぼ１ストローク幅だけ離れる２つの曲線を生じさせる。
【１６９３】
特定の区分的ベジエ曲線にほぼ平行な区分的ベジエ曲線を生成するため、次のステップを含むアルゴリズムが使用される。
i．  空のポイントリストの作成
ii．  空の接線（ベクトル）リストの作成
iii．  区分的ベジエ曲線を形成する曲線部分のそれぞれに選択されたポイントを評価し、特定のオフセット値によりそれらをオフセットさせる。前記ポイントリストにオフセットポイントを付け足し、対応する接線を前記接線リストに付け足す。
iv．  得られたポイントリストに区分的ベジエ曲線を適合させる。曲線を適合させるプロセスにおいて接線を予測するのではなく、オフセットポイントに関連した正確な接線を使用する。
【１６９４】
各曲線の区分は次のようにオフセットさせる：
i．  曲線値と、標準化された接線と、標準化された法線とを求める。その法線は、０．０以上１．０以下の、等間隔に配置されるパラメータ値（例えば、０．２５の間隔）で画像のサイズが標準化される。
ii．  前記特定のオフセット値により法線をｓｃａｌｅする。
iii．  前記曲線のポイントと縮小された法線とを使用して線分を組み立てる。
iv．  もし、２本の線分が交差するならば、１本の線分に関連するポイントを削除する。
v．  存続するポイント（surviving point）をポイントリストに付け足し、それらに対応する接線を接線リストに付け足す。もし、問題の線分が区分的曲線の最後のものであったなら、パラメータ値１．０に関連するポイントのみを付け足し、次の線分のパラメータ値０．０に関連するポイントは複写する。
【１６９５】
各曲線部分をオフセットさせるプロセスは次のように行われる。すなわち、
１．  初めに、０．０以上１．０以下の、ベジエ曲線上に等間隔に配置されるパラメータ値のため、各パラメータ値Ｐｎ（図２６９）のため、曲線値３６３０と、標準化された接線３６３１と、標準化された法線３６３２とが計算される。
２．  次に、特定のオフセット値により前記法線３６３２がｓｃａｌｅされる。
３．  次に、ポイント３６３０からポイント３６３６（ｓｃａｌｅされた法線３６３４の端のポイント）までの線分が計算される。
４．  次に、その線分３６３０−３６３９は、曲線上の他の全てのポイント（例えば、３６３８，３６３９）がチェックされる。もし、いずれか２つの線分が交差しているならば、ポイントの１つ３６３６は廃棄される。存続するポイント（surviving point）をポイントリストに付け足し、それらに対応する接線を接線リストに付け足す。もし、問題の線分が区分的曲線の最後のものであったなら、パラメータ値１．０に関連するポイントのみを付け足し、次の線分のパラメータ値０．０に関連するポイントは複写する。
【１６９６】
図２７０を参照すると、一連のベジエ曲線区分（例えば、Ｃ１，Ｃ２等）を作成するため、図２６７のステップ３６０７に従った曲線のオフセットの最終結果が示されている。最初に、一定間隔で配置された一連のパラメータポイントＰ１−Ｐ５。次に、各ポイントＰ１−Ｐ５に対して、法線のポイントＮ１−Ｎ５（図２６９のポイント３６３６に対応する）が作成される。次に、それらのポイントＮ１−Ｎ５を利用して、区分的ベジエ曲線３６４０が作成される。このプロセスは、ポイントＮ６−Ｎ１０を含む反対側の曲線３６４１にも適用される。このプロセスは、続く区分的曲線Ｃ２等にも適用される。この結果、互いに平行で、ほぼ１ブラッシュストロークの幅だけ離れて配置される２本の曲線３６４０，３６４１が得られる。
【１６９７】
次に、一連のブラッシュストロークが、前記曲線に沿って、出力画像中に配置される。それらのストロークは、曲線の接線方向に方向付けられる。各ブラッシュストロークは、他のブラッシュストロークと重ならない場所を規定するフットプリントによって規定される。そのフットプリントが出力画像中に既に表示されているフットプリントと重ならない場合には、ブラッシュストロークはその曲線に沿うようにのみ配置される。ブラッシュストロークが配置されていない曲線は廃棄され、ステップ３６０７と３６０８のプロセスが、曲線がなくなるまで（若干の修正を加えられながら）繰り返される。ステップ３６０７における若干の修正は、図２７０の曲線Ｃ１から曲線をオフセットさせる場合に必要な、半分のブラッシュストロークよりも大きく曲線をオフセットさせることである。
【１６９８】
上述の方法は、画像中の興味のあるオブジェクトから一連のブラッシュストロークが放射されるようにすることにも利用できる。
【１６９９】
与えられたサイズのブラッシュストロークで画像が覆われるのに続いて、より小さなブラッシュストロークでさらなる処理がなされ、画像においてブラッシュストロークの重要な特徴をさらに正しくするように、閾値レベルが高められる。そのようなテクニックは、細かさが要求される特定の部分にゴッホが使用するテクニックに近似している。
技術２６の説明
【１７００】
何らかの画像（例えば、写真）のために、該写真等の中の興味を引く領域（例えば、顔等の位置）を割り出せることが望まれる。一旦、画像中における顔の位置が特定されると、図２７１に示されるように、顔領域に対して吹き出しを配置するような、多くの奇抜な効果を実行する画像処理を単純にできる。顔領域が一旦検出されると、眼鏡のような顔に関連する物を配置する等、顔を変形させるというような他の効果を履行することができる。
【１７０１】
前述したように、画像における領域の検出は、領域に限定して芸術的効果を適用するというような、領域特異的処理に適用できる。例えば、背景の空の領域は幅広のブラッシュストロークで描き、最前面の顔の領域は細かいブラッシュストロークで描くと言った処理である。また、画像における特徴の決定等である。色を基準にした領域の検出は、検出される色が肌の自然な色合いであって、画像における人の顔の検出を行う時に極めて役に立つ。
【１７０２】
照明を変化させると、特定のスペクトルの色のオブジェクトが、輝度や彩度が変化されて画像中に現われるかも知れない。色相はオブジェクトの優位周波数（卓越周波数、dominant frequency）を評価するので、オブジェクトの色は、色相よりも輝度や彩度においての方が大きく異なる傾向がある。図２７２に示されるように、さらなる改善の方法３８０１は、輝度や彩度から色相を区別する色空間に、取得した画像をまず変換するという第１のステップを有する。そのようなもので、良く知られている２つの色空間としてはＨＬＳ色空間とＨＳＶ色空間がある。これらの色空間を含む様々な色空間は、フォーリー,Ｊ．Ｄ．、ヴァン・ダム、Ａ．、フェイナー、Ｓ．Ｋ．、ヒューズ、Ｊ．Ｆ．、コンピュータグラフィックス、原理と実行、第二版、アディソンウェスレー、１９９０年、５８４―５９９ページのような標準的なテキストで十分に説明されている。
【１７０３】
次のステップは、多数の入力カラーシード（color seed）を入力することである（３８０４）。各シード３８０５は次のように定義される。：
（１）色値のシードカラー範囲
（２）局部的な色の差の制限（a
local color difference limit）
（３）全体的な差の制限（a
global color difference limit）
【１７０４】
次のステップ３８０８はビットマップを構築するためにシードを処理することである。
【１７０５】
図２７１の方法における最後のステップ３８０７は、入力画像と同じ容量であって、入力画像中の画素が、シードのリスト３８０５により定義される色域に属することを示すビットマップを出力することである。この方法３８０１は、別々のパス３８０８の各シードの処理と、各パスの出力ビットマップと全体の出力ビットマップの結合を含む。個々のビットマップのどんなセット・ビットも全体のビットマップに書かれている。
【１７０６】
図２７３を参照すると、図２７２のステップ３８０８がより詳細に示されている。第１のステップ３８２０では、問題になっているシードが定義されるシードカラーレンジにシードがある全ての色について、シードビットマップが割り出される。次のステップ３８２１では、該シードビットマップにおける各シードのため、シード位置に連結される入力画像中の４コネクト又は８コネクトの領域を検出する“シード充填”アルゴリズムのためのシード位置として利用される。そのシード充填アルゴリズムは、シード出力ビットマップの領域に属する画素にフラッグを立てる。ステップ３８２１にてシード出力ビットマップ中でフラッグが立てられたシードは、それらが次のシード充填のためのスタートポイントとして使用されないように、ステップ３８２０で作成されたシードビットマップから消去される。
【１７０７】
全てのシードがシード充填処理のために使用されると、シードの全てのリストのために、シード出力ビットマップは全体的な出力ビットマップと結合される。
【１７０８】
上述の参考文献の９７９頁〜９８６頁に開示されているように、シード充填アルゴリズムは標準タイプである。しかしながら、該シード充填アルゴリズムは特定の画素関係テストを有する。
【１７０９】
もし、色が、前述の画素の色と局部的色差制限と同程度までに異なり、シードカラーと全体的色差制限と同程度までに異なるならば、画素は現在の領域の一部となる。その色差制限は各色成分毎に別々に決められる。スパンは検出されるか、左右から処理されるので、前述の画素は現在の画素の左の画素である。新しいスパンの初めの部分で、前述の画素の色は、もとのスパンの平均色となるようにされる。シードカラーは、シードカラー範囲の中間色となるようにされる。
【１７１０】
区別できる色の特徴であるが良く知られた顔のような領域を同定するために、１つのシードを使用するのではなく、シードのリストが使用される。
【１７１１】
局部的色差制限及び全体的色差制限の使用は、画像中の不連続を横切らずに、可能な限り領域を検出するために使用される。領域は様々な色を含むかも知れないが、これらは、その領域にわたって穏やかに変化する。領域における全体の色の変化は、局部的な色の変化よりも一般的に大きい。局部的色差制限の使用（imposing）は、画像の不連続部を横切るというリスクを減少させる。また、それは、全体的色差制限が控えめにならないことを許容する。その領域の検出は、例えば、徐々に明るく或いは暗くなる領域においてでさえより完全にできる。
【１７１２】
入力画像の色空間が色相を基準としている場合、低輝度又は低飽和のため、色相は少々当てにならないので、色相差制限は好ましくは輝度（又は輝度値）及び飽和によって縮小される。したがって、領域中の暗いエリアや飽和していないエリアにおいて色相が当てにならない場合には、検出された領域にそれらのエリアが含まれるようにその効果は縮小される。これは、もちろん、輝度及び飽和に関しての差制限が前提となっている。
【１７１３】
また、色相六角形の円の特性に一致して、色相差は正確に計算される。
【１７１４】
画像中のオブジェクトを検出する上記アルゴリズムを使用した場合に、非常に適切な結果がしばしば得られることは分っている。例えば、上記の方法は、多くの固体を有する画像であって、カラーシードが標準的な皮膚の色調にセットされた画像に利用された。その結果は、画像中の個々の顔の位置を正確に探すことができる。
技術２７の説明
【１７１５】
さらなる改善では、図２７４に示すように、ソースとなる画像３９０１が、対応する“タイル状”のカラー画像３９０２に変換される。その変換処理については後述する。第１の実施例では、各タイル３０９４は、出力画像３９０２において標準的配列を取る。さらに、各タイル３９０４の色は、入力画像３９０１における対応画素３９０５の色から引き出したものである。出力画像におけるタイル化処理は、入力画像３９０１よりも高解像度で行われ、よって、そのタイル化処理は実際において低解像度画像にするために使用される。
【１７１６】
もちろん、タイルの形状としては、多くの異なるものが可能である。画像をタイル化するタイルの形状は、好ましくは、全体の画像をタイル化して複製する場合に“パターンユニット”に結合されると良い。例えば、図２７６に示すように、タイル３９０８と３９０９は、複製される際に画像をタイル状にして、パターンユニット３９０７として結合される。
【１７１７】
さらなる実施例においては、一つ一つのタイルは２つのチャンネルを持つ画像により規定される。第１のチャンネル３９７０は、図２７６に示すように、タイルの形状と不透明とを規定する。零でない不透明な領域３９７１は、タイルの一部である画素を規定する。各画素３９７１の値はその画素の不透明度を示す。図２７７及び図２７８を参照すると、第２のチャンネル３９８０は、高さ（height field）として、タイルにおける画素表面テクスチャを定義する。図２７８では、図２７７のＡ−Ａ’線に沿った断面図が示されており、強度やピーク３９９１や傾斜３９９２，３９９３が示されている。
【１７１８】
そのアルゴリズムへの入力は以下の通りである。すなわち、
タイルとして再生されるべきカラー画像
上述したようなタイルのパターン
出力解像度
【１７１９】
付加される光学上の入力パラメータは下記のものである。
【１７２０】
該アルゴリズムからの出力は、入力画像にタイル状の演出を行うことである。
【１７２１】
繰り返しのタイル“パターンユニット”は次のように規定できる：
(1)   パターンユニットのサイズ（行の数、列の数）
(2)   画像の第１画素のため、パターンユニットにおけるスタートポイントへのオフセット（行及び列のオフセット）
(3)   連続するパターンユニットの配置についての、垂直方向のオフセット
(4)   パターンユニットを構成するタイルのリスト
(5)   １つのパターンユニットにおける、水平方向の連続的なタイルの配置のオフセット
(6)   該パターンの解像度（例えば、該パターンのタイル画像の解像度）
【１７２２】
該パターンの幅は、水平方向に連続的に配置されるタイルの列オフセットの合計により定義される。
【１７２３】
全てのオフセットは、連続する画素の組み合わせ（例えば、実数値の行及び列のオフセット）の中にある。このことは、タイルがサブ画素の正確さで配置されることを許容する。このことは、入力画像や出力画像や独立するタイルパターンの解像度を許容する。
【１７２４】
基本的なタイリング・アルゴリズムは、次のＣ＋＋コードフラグメントにより実施される。すなわち、：
0004309954.tif 000244
0004309954.tif 000245
0004309954.tif 000246
【１７２５】
上述の通り、一つ一つのタイルは、その形状／不透明性チェンネルにより特徴付けられる形態を有している。そのタイルの形状並びにタイルの画像中における配置は、一緒になって、そのタイルによって覆われるところの、入力画像中の一連の画素を決定する。出力画像における、そのタイルの色は、その一連の画素に基づく。色を付与するという機能は、限定するものではないが、入力される色を１画素ずつコピーしたり、入力される色の平均を取ったり、入力される色の中央を取ったりすること等を含むようにしても良い。
【１７２６】
このように色が付されたタイルは、不透明度を無視して出力画像に直接描かれるかも知れないし、或いは、タイルの不透明度に従って出力画像に合成されるかも知れない。後者のケースでは、出力画像は最初に何らかの明度（例えば、黒）や何らかの任意の画像（例えば、入力画像自体）に初期化されなければならない。不透明なマスクやチャンネルを使用した合成画像は、例えばＴｏｍａｓ  Ｐｏｒｔｅｒ  ａｎｄ  Ｔｏｍ  Ｄｕｆｆ（１９８４）“合成デジタル画像”ＳＩＧＧＲＡＰＨ会報１９８４年、２５３ページから２５９ページのような一般的な記事に開示されている標準的な合成技術を使用することができる。
【１７２７】
それぞれのタイルは、テクスチャチャンネルにより定義される表面テクスチャマップを有している。そのテクスチャチャンネルは、タイル中における各画素の相対的な表面高さを規定する。この高さ（height field）は、模擬的な入射光の反射角決定に使用される表面法線を決定するために後で使用される。タイルや、そのタイルが配置される部分の画像に模擬的な光が与えられる場合、表面テクスチャは視覚的により明白になる。
【１７２８】
タイルが出力画像に直接描かれるか、出力画像に合成されるか、いずれにせよ、最も単純なケースでは、タイルのテクスチャは出力画像のテクスチャチャンネルに直接書かれる。
【１７２９】
各タイルの不透明チャンネルは、タイルの背景への合成を制御する。加えて、画像サイズの不透明チャンネルは、タイル全体の背景への合成を制御するかも知れない。最も単純なケースでは、タイルの不透明度は、タイルの合成に使用される不透明度を生じさせる、大域的な不透明度（global opacity）によって測られる。図２７９を参照すると、大域的な不透明度を使用するプロセスの一例が示されている。第１のプロット４０００では、折り返された不透明度プロフィール（例えば、４００１，４００２等）の単純な形状を持つ各タイルの、断面の輪郭の例が示されている。次に、不透明度４００５の段階的増加からなる、好ましい大域的不透明度チャンネル４００４が示されている。上述した単純なケースでは、増加している不透明度のエリア（例えば、４００７）を有する不透明度４００６を生じさせるため、大域的不透明プロフィール４００４でタイル不透明プロフィール４００１が測られる。
【１７３０】
もちろん、大域不透明チャンネルを伴った局所タイル不透明度の組み合わせのスキームは可能である。例えば、最初に、各タイルについて、画素の不透明度が平均化され、画素毎の不透明度は、画素毎の大域的不透明度ではなく、この平均化された不透明度によって測られる。
【１７３１】
上述したタイリング・アルゴリズムが、僅かな簡単な修正を行うことによって、描いたような効果を簡単に生じさせる上で役立つということは、驚きを持って発見されている。パターンユニットをブラッシュストロークの堆積として取扱い、各タイル画像がブラッシュストローク（例えば、ブラッシュヘアーの層や、ストローク端部で厚みを有するもの）に見えるようにすることにより、ストロークがオーバーラップされて、描いたような効果がタイル内やパターンユニット内に実行される。次に、このアルゴリズムは、連続的にパターン内でタイルを反復するよりもむしろ、無作為にストロークコレクションからストロークを選択するために修正される。さらに、下に描かれた、多くののテクスチュアリング、配置、彩色効果は代替的付加的に供給され得る。
【１７３２】
第一に、入力イメージ内に一般的には様々なレベルの細部がある。入力イメージは、タイリング又は彩色アルゴリズムを介して再現されたとき異なったレベルの細部を要求する。これは、多様な変化内でイメージの加工、それぞれの変化内の異なった程度のストロークコレクションの利用、それぞれの変化と（累積的な）バックグラウンドの合成によって達成され得る。画素単位の詳細な寸法で構成された、イメージサイズにされた細部マップは、それぞれの変化過程のイメージ部分を制御するために利用され得る。それぞれの変化は、その上でイメージの対応部分が処理される“細部境界”が与えられる。継続的な変化に、細部のレベルの増加とストロークコレクション割合の減少が与えられる。最初の変化はこのように、例えば全体のイメージを加工処理し、第２の変化は細部の確定したレベルを加え、第３の変化はなお多くの細部を加える、などである。これは、画家がどんどん細部を加えていくことによって絵画を精密にしていくのにいくらか類似している。この細部マップ自体は、イメージ内にエッジを配置すること、言い換えると派生したフィルターの間をイメージが通過することによって、簡単かつ自動的に生成され得る。
【１７３３】
タイルは概念上は柔軟性の無いもの（ｒｉｇｉｄ）である。その表面のテクスチャは、背景の表面テクスチャや、重なり合う他のタイル（通常は如何なる他のタイルとも重なり合わないが）の表面テクスチャからの影響を受けることはない。他方では、ブラッシュストロークは概念的には柔軟である。その厚さや表面テクスチャは、背景の表面テクスチャや、重なり合う他のブラッシュストロークの表面ストラクチャの影響を受ける。特に、そのブラッシュストロークは、背景の凹部に充填される傾向があるが、背景の頂点（peak）では薄くなる傾向がある。（背景は、そのストロークに先行するブラッシュストロークの影響を含んでいる。）
【１７３４】
別の実施例においては、ブラッシュストロークが描かれる場合、幾つかの方法の内の一つによって、そのテクスチャは背景のテクスチャと結合される。まず、新しい背景高さを生じさせるために、ストローク高さは背景高さの一定割り合い（例えば、２５％）だけ付加されるが、その高さは減少しないようにされる。このテクスチャの効果は図２８０(a) から(c) を参照して説明される。図２８０(a) においては、シングルタイルのブラッシュの断面輪郭の例が示されている。図２８０(b) においては、図２８０(a) のブラッシュパターン４０１０を覆う、画像部分の断面が一例として示されている。図２８０(c) においては、上述したルールを使用した結合処理の結果が示されている。線分４０１３，４０１４，４０１６，４０１７は、画像値４０１１が対応するブラッシュ値４０１０を超えるように、画像４０１１から直接取られたものである。しかしながら、４０１５の部分は、画像４０１１の対応部分の２５％に、スト録４０１０のストローク高さを加えて計算されたものである。ストロークの下の背景が計算される。個々の画素において、背景の高さがもし平均よりも低ければ、ストローク高さは単に背景高さに加えられる。このようにして、背景の凹部にストロークが“充填”されるような擬態が行われる。もし、背景高さが平均に等しいか、平均よりも高ければ、ストローク高さはその平均に加えられる。このようにして、背景のピークによってストロークは薄くなる。背景がストロークを実質的に打ち破らない（例えば、ゼロまで薄くならない）ようにするため、その高さは、最小量（もちろん、ゼロを含む、最小ストローク厚さ）に応じて増加するようにされている。
【１７３５】
さらに、テクスチャー結合アルゴリズムの結果である、ストロークの正味の薄さを計算するため、ストロークの不透明度が計られるかも知れない。このようにして、背景のピークによりストロークが薄くなる場所は、より透明になる。
【１７３６】
タイル／ストロークの位置が決定されると、さらに、多くの方法によって処理がされるかも知れない。例えば、手によるタイルやストロークのポジショニングにおける自然なバリエーションを真似るため、タイル／ストロークの位置は、特定の範囲や特定の速度で任意にジッターされるかも知れない。ストロークよりもタイルを真似た場合、通常は、タイルが重ならないように、タイルのジッターの範囲が限定される。例えば、“内部タイルのギャップ”の幅のみが変化される。ブラッシュストロークを真似る場合、ブラッシュストロークは通常は重なるので、ストロークジッター範囲は通常はより狭く限定される。
【１７３７】
さらに、タイルやストロークの位置についてのより標準的なバリエーションを真似るため、置換マップに従って各タイルの位置が置換される。その置換マップは２つのチャンネルからなる。第１は行の置換を含み、第２は列の置換を含む。
【１７３８】
タイル／ストロークの色自体は、芸術的な効果のためにさらに処理されるかも知れない。例えば、
(1)   制限されたタイルや制限されたペイントパレットを真似るため、その色は、任意のパレットにマッピングされるかも知れない。
(2)   タイルカラーの不完全性や、絵の具を混合するバリエーションを真似るため、その色は、特定の範囲及び特定の速度で任意にジッターされるかも知れない。
(3)   その色のクロミナンスは、特定の速度で任意に変換されて、反対色を使用した印象派のスタイルを真似るかも知れない。
【１７３９】
タイル／ストロークの平均大域不透明度が決定されると、芸術的効果のためにさらに処理されるかも知れない。例えば、平均化された不透明度が、ゼロの不透明度や１００％の不透明度に二値化されるかも知れない。このことは、タイルの不存在や存在を作り出す。もし、平均化された不透明度が二値化されたなら、大域的不透明度の再生は、入力画像に部分的に誤差拡散を行うことによって改良されるかも知れない。これは、画像中に重要な効果を生成するために見出されている。
【１７４０】
さらなる実施例が、アートカム装置の適切なプログラミングにより実行される。キャンバスに画像を“描く”ときの画家は、通常は、絵の具の色が限定されたパレットと、制約されたセットのものであって特徴的な筆遣いを形成するブラシとを用いて仕事をし、そして、独特の色や質感のキャンバスに描いている。そのことに気付くことにより、さらなる実施例が構築される。描くシーンをより真実に近付けたり真実から遠ざけたりするため、そのシーンについての画家のビジョンを描くため、画家は、異なる色の筆遣いを行う。いくつかの絵のスタイルが、シーンの特徴や色を再生するために試みられる。他のスタイルが、シーンの特徴や色についてのより多くの印象を取得するために試みられ、より単純で一様なブラッシュストロークや絵の具を混合したり重ね塗りしないことによって特徴づけられる。これらの印象派のスタイルは、写実派のスタイルに比べると  より明るくより鮮明な色を達成するが、詳細な描写は犠牲にされる。
【１７４１】
“描かれた”演出となるように写真画像を自動的に変換するコンピュータシステムが、一般的には、入力画像中の画素から何らかの方法で取得した色のブラッシュストロークを出力画像中に入れる。そのようなシステムの課題は、上述したような、人が描くという行為の態様を取り入れることにある。印象派の演出を作り出す部分的解決法は、実際の芸術家の絵の具の色に基づくカラーパレットの構築と、入力画像に可能な限り一致させるような該パレットからのブラッシュストローク色の選択と、入力画像と整合する全体的な色を維持するための色の誤差拡散とにある。
【１７４２】
さらなる実施例においては、生の色だけを基準とするのではなく、ブラッシュストロークの最終的な色を基準とした画像を誤差拡散させるアルゴリズムが構築されている。この最終的な色は、絵の具の色や、ブラッシュの構成や、キャンバスの色や生地によって決定される。
【１７４３】
該アルゴリズムの入力は以下の通りである。すなわち、
＊  絵の具の色が限定されたパレット
＊  それぞれが不透明マップ（opacity
map）やバンプマップ（bump
map）にて定義された一連のブラッシュストロ菣꾂胣邃菣鞃菣莃菣꺁뷤ꢔ臣覸곦莅苣ꦃ菣ꎂ菣꾂볦몇臣鎽ꗦ薀臣꾉臣ꖟ苣貂臣蒁臣膀뻤袁臣膀볯銽뷯邽뷯覽뷯₃Ꞽ뷯趽뷯꺁볯뮷볯鎼볯銈볯鎼볯骃菣뢂臣風볨閁苣ꚁ臣讂胣㲂牢ਾ볯₊늉铧较苣邃菣鞃菣莃菣ꮁ苣誂ꛨ骮臣貂苣궂菣뎃菣릂戼㹲誼†뗧뮔臣鞁臣趆铧閁苣讂苣ꦃ菣뮔菥એ⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯钼胣㲑䐯噉ਾ†觥風苣ꮃ苣ꪃ苣ꂃ臣몇諥꾁胣ꖅ諥閁苣龁铧较臣钼蟥膀臣뺁苣膀菣ꒂ菣袃菣것菣袃臣袂臣ꚁ鷧늉臣貂臣隃菣莃苣ꖃ苣袃菣벃苣ꞁ苣ꎃ菣邃苣ꮁ胢辏臣鶀臣ꢁ臣芁苣芀ꧨ궂菣뎃菣릂苣隃菣莃苣ꖃ苣袃菣벃苣꾁菣꾂苣膃菣벃臣貂臣蒁苣ꢁ藥ꮁ胣鎁苣覂臣蚃苣릂菣ꎃ菣꾁菣ꒂ菣蚃苣뎃苣ꖷ꣧꺁雩꾁뗧袐臣貂臣蒁苣꺁臣膀鳦芵髧ꪁ菣ꒂ菣蚃苣뎃苣꾁룤릖郥蒚臣ꞅ苣閁苣讂臣节鿧貂臣蒁胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯閼胣㲑䐯噉ਾ†迦讁苣龁苣蚁臣릊黦銂裦鞁臩銁苣龁苣膀蟥鮊铧较臣ꖅ諥뮔菥ꢁ臣鎖臣膀苣誂蓥貂臣늉闦袐苣邈臣芁臣讂臣膂臣몟鳦뾂苣ꪃ菣낂苣ꮃ苣ꪃ苣ꂃ볯璈汩湩⁧污潧楲桴覼臣뾽铧閁苣讂胣肜裥꺁菣궃苣릂臣膀菣ꦃ菣랂菣릂菣궃菣꾂臣醃菣莃菣閃苣벃菣邃菣꾂苣ꮃ苣ꪃ苣ꂃ臣芁苣芀臣꺁菣궃苣릂臣膀苣袃菣벃苣꺁苣ꦃ菣醃菣莃菣꺁ꇨ銂뷤邈臣ꚁ껥財臣貂苣芀鯥銼볯醼臣몤臣ꢡ볯邼볯閼臣膀菣ꦃ菣랂菣릂菣궃菣꾂볯醼볯ꊼ볯貼볯鎼귧ꮁ苣誂賥蚈臣閁苣ꚁ臣讂胣隃菣莃苣ꖃ苣袃菣벃苣뮂菣袃룤꺁郥隃菣莃苣ꖃ苣袃菣벃苣ꊼ뷯꺁臣膂胣鶁臣ꚁ胣骃苣뎃菣醃菣莃菣뮂菣袃룤꺁郥骃苣뎃菣ꮂ菣벃볯醼裢ꎼ볯꺁臣膂胣릂菣궃菣꾂苣ꦃ菣뎼볯銈볯钼臣膀鯥銼볯銼臣閃菣벃菣ꎃ菣袃苣芏藧鞁臣겪飦閁苣讂胩誂胣ꆬ臣袂臣ꮁ뇦骮臣貂苣芀臣ꪁ苣ꆁ胣㲁牢ਾ볯躼†苣蚃菣鞃볯邼볯醼臣ꚁ胣뺯뿥馁苣隃菣莃苣ꖃ苣袃菣벃苣ꊼ볯銂觨颻臣讂臣膂臣骃苣뎃菣ꮂ菣벃볯醼臣뾽铧閁苣讂胣㲂牢ਾ볯躼†臣鞁臣膀룤辀飦麃菣鞃臣邃菣鞃菣莃菣ꢁ苣뾽铧鞁臣膀觨ꒁ臣꺁菣ꦃ菣랂菣릂菣궃菣꾂臣목臣궂菣뎃菣릂臣袐裦閁苣讂胣㲂牢ਾ볯躼†苣蚃菣鞃볯邼볯鎼臣ꚁ胣辏臣貂臣릂菣궃菣꾂臣뎹鷥늉臣袨껧閁苣讂胣鎁臣뎹鷥늉臣膀鯥銼볯醼臣릂菣궃菣꾂苣ꦃ菣뎼볯ꞁ臣讂胣鶁臣ꚁ胣鶃苣뎃苣벃볯趸鯥몤볯貁胣릂菣궃菣꾂苣ꦃ菣醃菣莃菣ꖅ諥뎼볯讁苣膀꿥鲿臣讂菣ꒂ菣袃苣ꦃ菣醃菣莃菣ꖅ諥ꎼ볯ꮁ菣ꒂ菣袃臣讂臣膂臣뮂菣袃臣貂苣芀戼㹲钼볯₎鶁臣ꚁ胣릂菣궃菣꾂菣ꮂ菣벃菣蚃菣隃菣貁觨ꮁ苣誂苣벃菣閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯隼胣㲑䐯噉ਾ†铧较苣辏臣뒠郥膀鯥銼볯鎼臣몤臣貂苣袂臣ꮁ胣蒐菣ꦃ菣랂菣릂菣궃菣꾂臣骀룥꺁雦閳臣뢁諦閁苣讂胣鶁臣ꚁ胣蒐菣ꦃ菣랂菣릂菣궃菣꾂臣肉鳦꺁觨貁藥鮊铧较臣覂胩뢸臣릖돦ꞁ뇦骮臣貂苣芀臣讁臣ꪁ臣覂胣骃苣뎃菣ꮂ菣벃菣것菣袃룤ꞁ鳦节뿨蒁菣ꒂ菣袃苣ꦃ菣ꎼ뷯꾁뷤ꢔ臣貂臣蒁胣鶁臣뾛苣誂胣鶁臣隃菣莃苣ꖃ苣袃菣벃苣꺁臣膂胣릂菣궃菣꾂苣ꦃ菣醃菣莃菣꺁룤ꞁ鳦节뿨蒁苣袃菣벃苣ꮂ菣벃볯躽臣뾽铧閁苣讂胣ꆬ臣膀臣꺁菣ꦃ菣랂菣릂菣궃菣꾂臣龁苣꺁菣ꒂ菣袃苣ꦃ菣ꢁ臣ꚁ胣뺯뿥馁苣骃苣뎃菣ꮂ菣벃볯躽臣떵臣랅臣늉臣鞁臣뾽铧閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯鞼胣㲑䐯噉ਾ†ꧨ骃苣뎃菣醃菣莃菣궸臣ꦈ铧ꞁ臣讂觨꺁꿧늛臣뚈駩閁苣ꚁ臣讂臣膂胣骀룥꾁胣肉鳦꺁觨ꢁ臩麊臣趁苣늉볯躽臣꺁雩ꮁ臣蒁臣覂臣꺁臩蒁臣芁苣芀臣꺁臩蒁胣隈臣꾁ꫨ꺷臣膀ꫨ꺷详ꎕ苣財臣骀룥꺁雦閳臣膀藥鮊铧较臣醿軦鞁臣ꢃ裥ꮁꫨ꺷详ꎕ臣貂苣鎁臣貁臣趁苣芀触鮜臣늉臣骃苣뎃菣ꮂ菣벃볯躽臣閁臣꺁ꫨ꺷臣뾽铧閁苣ꪁ臣芀믤辂苣ꮁ胣肉鳦꺁觨ꢁ苣袃菣벃苣ꮂ菣벃볯躽臣꺁臩蒁臣芁苣꒪럥貁胣鎁臣꺛髧꺁臣膂胣릂菣궃菣꾂苣ꪨ雦馁苣뎹鷥늉臣鞁臣뾽铧閁苣讂胣龮髩꺁菣ꦃ菣랂菣릂菣궃菣꾂臣隻臣릂菣궃菣꾂臣趇臣讂臣ꮁ꿥鞁臣膀苣袃菣벃苣醃菣莃菣궸臣릂菣궃菣꾂臣목臣궂菣뎃菣릂臣辏臣貂苣꺁臣膀臣꺁맥螝觨뎼뷯貁苣袃菣벃苣醃菣莃菣ꮁ臣醁苣뎹鷥늉臣낕臣讂臣节鿧貂臣蒁臣ꢁ臣鞰믤辁胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯颼胣㲑䐯噉ਾ†臣꺁雦閳臣膀믤꺁菣ꒂ菣蚃苣뎃苣뮃菣ꦃ菣벃苣꺁諥鲞臣貐臣릖돦ꞁ迥誂藥貂苣貂苣袂臣ꮁ详떼臣讂臣ꢁ臣ꞁ臣讂胣鎁苣꾁胣骃苣뎃菣ꎂ菣낂菣ꆃ菣ꎂ苣ꂃ臣꺨ꇩ袼菣ꒂ菣릲胣膃菣벃苣膀菣ꎃ苣벃菣覭볯蒂胣궂菣뎃菣릂臣꺨ꇩ袼菣꾂苣膃菣벃듧膀苣ꦃ苣覭볯ꪁ臣銂郥肂胣蒐菣ꦃ菣벃苣꾁胣릂菣궃菣꾂苣ꦃ菣醃菣莃菣꺁ꓥꆬ藥ꢡ臣ꆬ藥銂諥袁苣貁胣겜돨蒚臣ꊂ菣뒂菣몂菣꾁ꓥ隌臣ꪁ臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖 뢊ꇨ뚮臣膀駦颊胣醼臣꺁菣ꦃ菣랂菣릂菣궃菣꾂臣銼觨袏臣鶁苣ꖻ룤銂럦袐臣鮁苣芀跥ꆱ듦꺁苣뾂苣ꮃ臣꾁胣鎁苣覂臣늉臣鞁臣鞁臣膍裥ꮁ臣랷郥閁苣骁胣뺁臣膀럦袐臣貂臣蒁觨貁苣袃菣벃苣꺁裥ꊛ臣貂臣邈裥ꢁ臣ꚁꛨ趪臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 誸뿨鞁臣ꊂ菣뒂菣몂菣ꮁ臣蒁臣膀ꓥ낕觨꺁菣ꦃ菣랂菣릂菣궃菣꾂臣醼觨꺁菣ꦃ菣랂菣릂菣궃菣꾂臣肸裨隌臣馁苣鎁臣貁臣趁苣芀臣貂臣膀ꓥ낕臣趸胩躘뫥麃菣鞃臣袂苣ꦁ껥閁苣讂臣ꢁ臣ꞁ臣讂胣鎁苣覂臣趸胩躘뫥麃菣鞃臣膀菣ꦃ菣랂菣릂菣궃菣꾂臣놅胩꺁軦隻髧颠鿥꺁臣膂胣벂菣ꞁ臣蒁룤辀飦ꚺ苣骮뻧馁苣芀臣貂苣꾁胣ꢅ뷤蒚臣隃菣莃苣ꖃ苣袃菣벃苣꺁뷥뚊苣辦껥馁苣芀臣꺁苣ꮃ苣ꪃ苣ꂃ臣ꆬ臣꺿귦銂냥ꖅ臣讂臣ꢁ臣袂苣膀ꓥ낕觨꺁菣ꦃ菣랂菣릂菣궃菣꾂臣邏뻤閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯醼胣㲑䐯噉ਾ†룤ꒁ룤ꒁ臣隃菣莃苣ꖃ苣袃菣벃苣꺁臣膂臣릂菣궃菣꾂苣ꦃ菣醃菣莃菣貁꟦覯臣貂苣뒠郥膀菣ꒂ菣袃苣ꦃ菣醃菣莃菣讁苣꺁菣뎃菣ꮂ菣벃臣꾏菨ꪁ뗧뾁郥辂臣ꞁ菣ꦃ菣랂菣릂菣궃菣꾂臣늉臣鞡苣貂苣芀臣꺁臣ꢁ臣膀냥閁臣骃苣뎃菣ꮂ菣벃菣것菣袃臣龁苣躘苣讁臣립ꯧꒁ胣蒐苣袃菣벃苣ꮂ菣벃菣것菣袃臣ꖅ諥꾁胩뢸臣릖돦ꞁ꟦覯臣膀郥릂菣궃菣꾂苣ꦃ菣醃菣莃菣꾁꿥鲿臣讂ꓥ낕臣骃苣뎃菣ꮂ菣벃菣것菣袃藥芑냦螮胣뮔菥銂迦辁ꃥ袐胣骀룥꺁雦閳臣膀苣袃菣벃苣ꮂ菣벃菣것菣袃룤ꞁ鳦节뿨蒁苣袃菣벃苣ꮂ菣벃苣讦臣醁苣芀臣讁臣膀苣袃菣벃苣꾁胣骤闦꺁菣ꒂ菣袃苣ꦃ菣ꞁ觨ꖁ臣閁苣讂胣㲂牢ਾ諦鎡볯邼臣겪飦઎⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯銼胣㲑䐯噉ਾ†鯥銼볯钼苣芏藧馁苣ꢁ胣ꊂ菣袃苣ꂃꏨ꺽臣鞃菣낂菣ꂃ臣閁苣ꪁ苣릔雥꺁苣蚃菣鞃臣몤臣貂臣蒁苣芀꣦隺髧ꪁ諦閳臣骀苣膀菣ꦃ菣랂菣릂菣궃菣꾂臣몌裥蒚菣뢂苣늛럧ꢁ臣ꚁ觧뒾믤醁苣貂苣ꢁ菦骮臣貂苣芀菣ꦃ菣랂菣릂菣궃菣꾂臣肉껥꺁軥뾁苣膌臣ꢁ菦骮臣貂苣芀臣꺁菣ꦃ菣랂菣릂菣궃菣꾂臣肸胩꺁菣뢂苣늛럧讁苣ꪁ苣芀곧醼臣릂菣莃菣钼볯醼볯꾁郥몌裥蒚菣뢂苣늛럧銂蟥蚐臣讂臣ꢁ臣芁苣芀臣貂臣貂臣馃苣ꢂ鯦骷臣膀꣦隺髧ꪁ諦鎡苣뾽铧鞁臣膀鳦鶈臣颊苣骷臣覤迦閁苣讂볯钼볯醼볯覼胣ꆬ臣膀胢肜苣龀臣鶀苣莃苣袼臣꺁蓦뎑臣ꖻ룤ꞁ飦覂臣ꮁ臣讂볯貁胣肉껥꺁苣뎃苣ꪃ菣뎃菣ꮁ臣醁苣肜苣龀臣ꢂ菣뢂苣鲀蟥몙臣讂볯鎽뷯薽뷯ₐ膽뷯辽뷯螽볯龁苣ꮁ뷤ꢔ臣貂苣芀臣꺁뷤꺽臣膀菣ꦃ菣랂菣릂菣궃菣꾂볯銼볯钼苣袐裦馁苣龁苣ꮁ뷤ꢔ臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 뎛볯颼볯銂迥ꞅ臣讂臣膀菣ꦃ菣랂菣릂菣궃菣꾂볯銼볯醼臣몟ꓧ銂뷥邈臣讂곧醼臣馃苣ꢂ鯦骷볯銼볯邼臣몤臣貂臣蒁苣芀臣꺁菣뢂苣늛럧钼볯銼볯銂꿥鲿臣讂룤ꎀ臣骷裥袼뻤袁臣膀볯銼볯銼볯ꮁꓥ鮏臣讂菣궃苣릂胣颊苣骷臣몌裥ꮁ럧ꊽ뿨벼臣讂菣궃苣릂臣馨뫦蒚臣꾉臣ꖟ苣貂臣誁苣膀駦骀臣馕꟧뢛臣随苣誸臣覂苣ꚁ臣讂胣鶁臣骷뷥醿볤鞃菣뮂苣꺁룤낒臣鞁臣膀郥骷臣꾫苧꺁돦骷볯设臣낁胣钼볯銼볯覼臣뺁臣몱껥閁苣讂胣鶁苣覂臣閳럧꾁胣薿ꛨꪁ苣낁胣骷臣뺂臣銂ꏨ鎖臣讂雦閳臣袂臣ꚁ胣릂볯设臣낁胣钼볯銼볯覼臣ꎚ軦閁苣讂럧讁苣몱껥閁苣讂臣ꢁ臣ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯钼胣㲑䐯噉ਾ†鯥銼볯隼苣芏藧馁苣ꢁ胣銼鳦꺁럧蚈볯銼볯鎼볯钼볯鎼볯꺁详Ꞥ鯥貁ꓧ閁苣ꚁ臣讂胣蒐苧袼뻤袁臣膀볯銼볯銼볯꺁臣膂臣膀돦骷볯设臣낁胣钼볯鎼볯貼볯銼볯钼볯꾁胣鶁苣麁苣꺁臥ꮁ菣ꦃ菣랂菣릂菣궃菣꾂臣薹臣鶷鯩ꂁ臣膪臣몇臣蒁苣芀苧钼볯鎼볯꾁ꫧ趁蟥龁돦骷볯銼볯鞼볯钼볯鎼볯銂鳦鞁臣蒁苣芀곦ꮁ胣閳럧钼볯鎼볯ꢁ돦骷볯銼볯鞼臣꺁雩꺁럨ꊛ볯銼볯馼臣겸껥閁苣膀돦骷볯銼볯钼臣閳럧钼볯鎼볯ꢁ臣鎖臣鶷鯩钼볯钼볯貁룦骮臣貂苣芀苣莃苣钼볯鎼볯ꮁ닦ꎁ臣뮧该馁苣芽뷯蒽뷯貁胣ꢂ菣뢂볯銼볯邼臣뾲臣袂苣节韦辁꟧開臣ꪁ臣貂臣ꪁ苣ꪁ臣ꢁ臣蚁蓦뎑臣膀鳦节闩蒁럨ꊛ苣覜臣讂臥ꮁ胢肜苣龀臣鶀苣莃苣貁껥ꦾ臣貂苣芀臣龁臣ꎁ臣膀鳦节胩蒁苣莃苣꾁鯦骷臣뢇諧꺁苣莃苣ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯閼胣㲑䐯噉ਾ†鳦节胩蒁苣莃苣꾁胣覭臣蒁蟩ꂁ臣ꊛ苣龁菣ꦃ菣벃苣ꢁ臣ꚁ臣肉껥낕臣鶃苣뎃菣銂껥ꦾ臣讂臣膂臣뾽铧閁苣讂胣뎛볯颼볯꺁뻤꾁胣骷볯銼볯馼臣뾲臣ꚁ귧鎖髩ꮁꛨ骮臣貂臣鎼臣꺁菣ꒂ菣袃볯銼볯鎼裢钼볯钼볯貁ꓧ閁苣ꚁ臣讂胣뮁臣鎂臣꺁雩钚臣뎛볯颼볯ꮁꓧ閁苣龁苣꺁苣誂苣랕臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 ꆬ臣膀郥鶃苣뎃菣꺁菣것菣벃苣趽뷧貁뇦骮臣貂胣骷볯銼볯邼臣뾲臣龁菣ꦃ菣벃苣鶃苣뎃菣銂뇦骮臣讂臣膂臣뾽铧閁苣讂胣鶁臣趽뷧꾁胣隃菣莃苣ꖃ苣袃菣벃苣貁藩꺽臣貂苣趽뷧ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯鞼胣㲑䐯噉ਾ†鯥銼볯鞼苣芏藧馁苣ꢁ胣肸胩꺁菣ꦃ苣릂苣뎃菣钼볯钼볯貼볯銼볯鞼볯钼볯钼볯貁ꓧ閁苣ꚁ臣讂胣銼臣꺁苣뾂菣鞃볯銼볯隼볯钼볯钼볯꾁럧꺁ꯧ꺁菩蚈臣뾽铧閁苣膀菩蚈볯銼볯鞼臣骷臣궸ꓥꢃ裥ꮁ닦ꎁ臣ꎀ뛧蒚臣뾽铧閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯颼胣㲑䐯噉ਾ†ꧨ隃菣랂苣뾂菣鞃臣膀菣莃菣膃菣趃菣膀菣뎃菣麃菣鞃菣ꎃ菣ꮃ迥뎁菣莃菣鞃菣뎃菣膃菣趃菣꺁볯ꒁ臣ꖈ胣꺁菣ꎃ菣ꮃ臣袂苣骮뻧閁苣讂胣뎛볯颼볯꺁뻤ꞁ臣膀菣ꦃ菣랂菣꺁菣莃菣膃菣趃菣貁ꓧ閁苣ꚁ臣讂胣鲀鳦Ꞥ胢蚃苣讃菣꾂臣鞁臣ꖟ苣貂臣蒁苣膀곧醼臣蚃苣讃菣꾂臣誁臣ꚁ臣膀菣莃菣膃菣趃菣蒂菣뎃菣麃菣鞃菣ꎃ菣ꮃ臣膀裥ꊛ臣貂臣隃菣莃苣뎃苣邃菣閃苣ꮁ臣蒁臣隃菣莃苣ꖃ苣袃菣벃苣銂꟦覯臣讂臣膂臣뾽铧閁苣讂胣鎁臣袐裦肊ꇨꮁ臣蒁臣꾁胣隃菣莃苣ꖃ臣肜ꓥ趸胩躘뫥銂迥讂臣ꢁ臣袂苣讧꿧閁苣讂胣鶁臣邃菣閃苣ꮁ臣낖臣蒁룤辀飦ꚺ臣꒏臣趸胩躘뫥銂뛨袁苣뒠郥膀臣꺁룤辀飦ꚺ臣낖臣蒁룤辀飦ꚺ臣꺽臣鮏臣覂苣讂胣龔裦閁苣龁뗧鲞臣膀菣ꦂ菣랂菣莃菣ꮁ臣醁苣ꢂ苣벃菣ꦃ苣蒂菣ꒂ菣蚃苣뎃苣ꮁ뿨벼臣龁苣꺁臣ꪁ苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 견볯꺁郥邈諦鎡臣誁臣ꚁ臣膀胢閃菣袃菣ꪃ菣袃胢肊ꇨꢁ臣ꚁ鿧覂苣讂胣뺏鳥꺁菣ꒂ菣꺁臣膂臣趉뿨鞁臣隃菣莃苣ꖃ苣뾂菣鞃臣뮔듧꺁臣膂臣隃菣莃苣ꖃ菣莃菣ꆂ臣뢛臣벾臣貂臣讁臣龁ꃥ袐臣꺁臣麃菣袃胥貁ꓥ뒛臣貂苣袂臣ꮁ胣閃菣袃菣ꪃ菣袃菣ꎃ菣ꮃ臣뾽铧閁苣讂胣견볯꺁諦鎡臣誁臣ꚁ臣膀菣莃菣膃菣趃菣蒂菣뎃菣麃菣鞃菣ꎃ菣ꮃ臣뾽铧閁苣讂臣膀臣꺁臣趁胣麃菣袃菣ꎃ菣ꮃ苣邃菣鞃菣莃菣膃菣趃臣肜냥ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯邼胣㲑䐯噉ਾ†룤風臣肊ꇨ꾁胣릉臣뒰뷥뮔臣릊黦銂鳧벼苣뒠郥ꮁ觨蒁뗧鲞苣节臣覂臣鎁臣貁裥ꎁ臣蒁苣芀곦꺁苣벃菣뮂苣ꆃ菣袃臣膀臣覂臣릔觨閁苣龁껥붖뻤꺁蟥蚐苣몤臣芀볯㲚牢ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㜴⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐲㰸愯㰾䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㤴⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔲㰰愯㰾䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰ㄵ⼼㹡⼼䥄㹖肊ꇨ鎼볯꺁ꫨ躘㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 뎛볯颼볯銂迥ꞅ臣讂臣膀苣벃菣ꮂ菣薣뷧钼볯邼볯銂郥肂胣閁苣ꪁ苣릔雥꺁藩鞈볯钼볯醼볯覼臣몤臣貂臣誁苣膀ꧨꊂ菣袃苣ꂃꏨ꺽볯鎼볯銼臣膀臩螈臣螖귥趪귨꺁臣趁苣뾂菣膃菣莃菣겼볯꒼臣覂臣讂雦ꂫ藥鮊ꏨ꺽볯鎼볯鎼臣ꖎ뛧閁苣ꚁ臣讂胣ꎻ苣誂臣膀苣벃菣벃菣ꖅ諥薣뷧袼뻤袁臣膀볯鎼볯钼볯銂雦ꂫ藥鮊ꏨ꺽臣馁苣鎁臣貁臣趁苣芀雦ꂫ藥鮊ꏨ꺽臣붥臩ꪁ뷥讅臣膀觥風苣벃菣ꮂ菣薣뷧钼볯邼볯ꮁ軦骶臣貂苣袂臣ꮁ臩鲿臣貂菣궃苣ꦃ菣閁苣龁苣莃菣ꮃ臣讃菣벃菣뎃볯뮙賩蚕꣦覼ꏨ꺽臣ꚁ꟦邈臣貂뻥讂胣뺁臣膀雦ꂫ藥鮊ꏨ꺽볯鎼볯鎼臣隻臣ꊽ藦貁裥ꢔ臣貂苣鎁臣节臣趁苣芀臣覂臣膀苣벃菣ꮂ菣薣뷧钼볯邼볯ꮁ賦ꖅ臣貂苣ꊂ菣袃苣벃菣薣뷧钼볯邼볯貁迦鮾臣貂胣늩苣벃菣ꮂ菣覃臣ꢡ鷩ꮁ迦讁苣ꚁ臣讂鯥ꮁ뻥ꎁ臣鲤鿧뮔菥銂볯袺苣膍裥ꮁꓦ躨臣貂臣袂臣ꮁ볯ꚇ郧馁苣袂臣ꮁ臣ꎁ臣蒁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 뎛볯颼볯銂迥ꞅ臣讂臣膀臣覂臣讂铦꾉觧꺁鏦鲽臣ꊖ臣ꚁ臣붥臣鞁臣ꊽ藦貁ꓧ閁苣ꚁ臣讂胣鎁臣趓뷤꺁뷥讅臣誁臣ꚁ臣膀苣벃菣ꮂ菣覃볯鎼볯閼臣膀菣벃菣鞭臣辦껥閁苣讂菣ꦂ菣袃臣膀ꧨ閃苣뎃菣ꞁ觧ꖈ臣螖귥銂뷤邈臣讂雦閳臣겪飦ꢁ苣ꮐ苣뚼뷯銽뷯릂苣ꪃ菣袃臣ꚬ迥隌臣貂臣蒁苣芀뻤袁臣膀臣꺁ꫨ躘臣膀臣꺁菣ꦂ菣袃臣낖臣蒁雦鞭苣鲽裦馁苣龁苣ꮁꓥꊽ苣ꚇ郧馁苣릖돦銂郥肂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯鎼胣㲑䐯噉ਾ†藥鮊ꏨ꺽볯鎼볯鎼볯钼볯邼볯꾁藥鮊ꏨ꺽菣ꦂ菣袃苣覜臣讂胣鶁臣ꖅ諥薣뷧閃苣뎃菣꾁胣薃ꃥ銂ꇨ몤臣讂臣膂臣蚃苣릂菣ꖅ諥薣뷧钼볯邼볯貼볯鎼볯钼臣袂臣ꚁ뷤ꢔ臣貂苣芀觧ꮁ胣麝菣벃菣鞭臣뾽铧閁苣讂胣鞁臣貁臣ꚁ胣ꖅ諥薣뷧钼볯邼볯貼볯鎼볯钼臣膀苣벃菣ꮂ菣覃볯鎼볯閼臣袂臣ꚁꛨ花臣貂苣蚃苣릂菣꺁藥鮊臣龁苣ꮁ뷤ꢔ臣貂苣芀藥鮊臣몟臣趁胣閃苣뎃菣꺁苣Ꚃ菣ꦃ苣뎃臣膀觧ꖈ臣螖귥꺁뷤邈臣龁苣ꮁ苣벃菣ꮂ菣覃볯鎼볯閼臣ꚬ迥隌臣貂臣螌ꓧꮁ뻥ꎁ臣ꊂ苣袃菣ꒂ菣銂蟥蚐臣讂苣벃菣ꮂ菣ꚃ菣莃菣钼볯邼볯ꮁ菣Ꚃ菣궃菣覃臣貂苣芀臣貂苣꺁雦鞭臣ꊂ菣袃苣ꂃꏨ꺽볯鎼볯銼臣袂臣ꚁ뷤邈臣貂胣낍裥閁苣讂蟥鮊铧较臣肸菩ꢁ臣ꚁꇨ몤臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 鎁臣趓뷤릖돦銂뷤ꢔ臣讂臣ꢁ臣膀苣벃菣ꮂ菣薣뷧钼볯邼볯蒂苣벃菣ꮂ菣覃ꏨ꺽볯鎼볯閼臣閃苣뎃菣꺁藩鞈苣鶿귥馁苣鎁臣ꮁ臣鞁臣ꊂ菣袃苣ꂃꏨ꺽볯鎼볯銼臣钟믨Ꞁ臣ꆋ볥閁苣讂胣鎁臣릖돦ꮁ苣貂臣膀鷩궃菣麃귥肨ꫨꊽ볥ꞁ苣벃菣ꮂ菣薣뷧钼볯邼볯銂鏦鲽臣讂臣膂臣ꦈ铧閁苣讂菣螃菣꺁ꓨ醛臣銂룦醰臣릁臣膀菣궂苣袃藥鮊ꏨ꺽볯设臣낁胣钼볯邼볯貼볯鎼볯钼볯貁郥붛臣ꢁ臣芁苣鎁臣꺁臣貁뿥膦臣芁苣芀戼㹲肊ꇨ鎼볯꺁ꫨ躘㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 閁苣ꪁ苣릔雥ꞁ臣膀菣뢂苣ꮃ铧较苣ꆃ菣ꞁ鋦놽臣膀觥낿臣릉꣨몇ꇩꮁ臣讖ꓧ閁苣ꚁ臣讂苣蚁臣肉껥꺁뷯邽뷯袼뻤袁臣膀볯隼볯邼뷯邽뷯覼苣膌臣ꒂ菣꾂苣Ꞃ菣袃菣ꪃ菣뾂菣꺁苣蚁臣鞃菣뎃菣薣뷧ꞁ跥랈臣讂臣蒁臣膀苣ꆃ菣뮔菥꺁蛥龔臣鮜臣貂苣鎁臣貁觥邏臣芁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 뎛볯馼볯銂迥ꞅ臣讂臣膀臣꺁苣蚁臣螃苣뾂菣뮔菥ꮂ菣ꦃꏨ꺽볯閼볯醼臣膀꣦隺髧ꪁ蟥鮊꟨较뫥꺁铧较볯閼볯銼苣鞃菣뎃菣ꊂ苣袃臣讂苣蚁臣궨꣨閁苣ꚁ臣讂胣鶁臣뮔菥钼볯邼볯꾁胣麃菣膃苣ꦃ菣몇諥袼苣ꊂ菣膀菣벂菣뾂胣ꒂ苣궃菣覼臣芁臣ꚁ胣ꖅ諥뮔菥꺁郥늉裦蚈臣龁苣꺁菣莃菣꺁藩鞈臣覂臣讂苣뎃苣뢂苣莃菣鞃菣뎃苣벃ꏨ꺽臣袂臣ꚁ跥랈臣貂苣芀蟥鮊臣貂臣馆鳧钼볯邼볯꺁苣钃菣銂룥鮜臣讂ꃥ袐臣꾁胣뺁臣뮔菥貁苣궂菣뎃臣貂胣ꦁ裥ꪁ觨邈裥貁諦몇臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 閁苣ꮁ铦꾉臣貂臣릖돦貁鯥銼볯醼臣몤臣貂臣蒁苣芀臣꺁雦閳臣꾁胣馆鳧뮔菥钼볯邼볯貁菣讃苣ꎼ볯꒼볯閼볯邼臣袂臣ꚁ郥늉裦蚈臣릂苣ꎃ菣閁苣讂胣ꦁ裥ꪁ菣讃苣ꎼ볯꒼臣肊ꇨ蒚臣ꖟ苣貂臣蒁苣芀菣讃苣ꎼ볯꒼ꏨ꺽臣讧裦誏臣趓뷤꺁ꫨ躘臣龁苣ꮁ胣貀胢ꎼ볯꒼苣것苣膀苣ꆃ菣膀菣ꎂ苣鞃菣ꒂ胢Ꞽ뷯銽뷯貽뷯㲄牢ਾ볯₣볯辽뷯鎽뷯鞑胣醼볯馼볯뒹駧財胣뎼볯ꦼ볯㲥牢ਾ苣鞃菣ꎂ苣ꮃ苣뎃苣讃苣ꪃ菣낂蟥袉胣꺁苣蚁臣馨뫦蒚臣螖賧貁迥莀臣閁苣讂胣閁苣ꮁ胣ꦁ裥ꪁ苣뎃苣벃ꏨ꺽臣膀껥뮛臣ꒁ臣ꚁ臣뮛냦뮛귥肊ꇨ薀跥骼ꃥ誑鯦ꞁ껥龜髧ꮁ뿨릁苣貂臣蒁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 ꎼ볯꒼苣것苣钼볯醼볯꾁胣ꎼ볯꒼菣莃菣꺁룤銂胩躁臣讂铧较苣릂苣ꎃ菣鞁臣ꆿ迥銂铧邈臣膀苣誃菣낂뿤랏苣螃苣뾂菣ꆿ迥ꮁꓥ鮏臣讂胣ꎼ볯꒼苣것苣钼볯醼볯꾁胣馆鳧꺁菣莃菣ꎧ菥ꚺ臣鎼胥ꞁ臣讂胣醼苣뎃菣鎽臣誂볯颼볯邼菣莃菣ꮁ臣讂胣늩볯ꎼ볯ꊂ菣ꒂ볯閼볯邼臣膀郥늉臣뺯臣ꚁ룤ꒁ臣ꒁ룤龎觨膀菣ꎂ菣뾂菣膀볯ꎼ볯銂鳦馁苣芀볯颼볯邼뷯邽뷯꾁룤ꎀ臣莍돩超裥ꎼ볯꒼苣것苣銂뷤ꢔ臣讂臣ꢁ臣袂苣钁裦閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯馼胣㲑䐯噉ਾ†觥風菣벃苣ꒀ臣閃菣벃菣邃菣閃苣뎂菣袃菣벃菣钼볯醼볯ꮁ믨膀臣貂胣늉裦蚈꿦ꮁ菣것菣ꂃ菣莃菣ꆂ볯閼볯鎼臣鶿귥閁苣讂胣鶿귥閁苣龁铧较臣膀蛥龜臣誸臣鞃菣뎃菣閁苣膀觥낿臣龁苣蚁臣膀跥랈駦꺁듧鎼胥꺁꟨较뫥ꞁ臣讂볯ꎼ볯릂苣ꎃ菣뎃苣ꎧ菥ꚺ臣ꚁ볯ꎼ볯ꮁ苣誂苣궂菣뎃臣貂苣ꢁ臣膀鳦ꖝ臣覃菣袃臣趽뷧ꮁ藩꺽臣貂苣袂臣ꮁ蟥蚐臣貂苣芀껦떿臣貁苣膀苣궂菣뎃臣貂臣뮔菥ꮁ臣骤臣꺁곦ꖙ臣颭鳥馁苣讁苣ꖟ苣ꪁ臣芀臣貂苣꺁곦ꖙ臣膀蛥龜볯閼볯銼臣ꎼ볯꒼苣궂菣誃菣钼볯醼볯ꮁ胩覂苣讂臣趁臣馆鳧钼볯邼볯꺁뻥薀臣讂鯥ꊻ臣ꂊ臣ꚁ胣馆鳧钼볯邼볯꺁若蒂귦뾁臣놽鿩銂郥肂胣릂苣ꎃ菣뎃苣ꖷ꣧ꮁ雩ꎀ臣龁곦ꖙ苣ꮐ苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖 醃苣벃菣蒂菣莃菣銂뇦膂苣龁苣꺁触蚠臣膀蛥龜볯閼볯銼臣麛믨銂諦몇臣讂菣궃苣릂臣뾽铧ꮁ뻤颭臣讂胣鶁臣袂臣ꪁ鯥ꊻ苣늉苣몇臣袼敤整浲湩覼臣膂胣骤臣꺁雦閳苣ꦈ铧馁苣鎁臣貁臣趁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖 设臣낁胣ꒂ菣꾂菣莃菣꺁苣궂菣뎃臣貂臣醃苣벃菣꾁觥風鯥ꊻ臣몟臣辁鿥겜髧릉뻥ꢑ돦낕볯暈湵慤敭瑮污挠慨慲瑣牥獩楴⁣牦煥敵据敩覼苣覜臣讂胣馆鳧ꮁ臣膀菣莃菣꺁룤겈髧ꪁ藩鞈臣ꒂ菣꾂臣낍裥閁苣讂臣ꞁ胣鶁臣뮔菥꺁菣벃菣ꢂꓥ鮏臣膀뗨鎁苣鞾苣麛믨銂觥誂蟥馁臣膂臣뾽铧閁苣讂胣鶁臣ꎻꇦꢁ臣ꚁ臣膀蛥龜臣莢闧袼扡畲瑰戠畯摮牡覼苣ꎼ볯꒼臣许雦꺁苣궂菣讃菣낂鷩袼桴⁥湵敤湲慥桴猠慣湮湩⁧畳晲捡⁥景琠敨䌠䑃볯讁苣ꮂ菣覃臣ꢂ菣뢂苣늉苣몇臣鎁臣貁臣趁苣芀臣覂臣膀铧ꂴ臣肉鳦꺁菣莃菣钃菣膃臣몱껥袼敤整浲湩覼臣貂苣袼볯隼볯邼뷯邽뷯覼胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯銼胣㲑䐯噉ਾ†蛥龜臣릂苣ꎃ菣뮔菥꺁룤꾫룧讁苣膀菣莃菣貁臣貂臣貂臣몇諥覃菣袃뷤꺽臣超뷧閁苣ꚁ臣讂臣ꦁ臣讁苣ꒈ雦馁苣龁苣꺁蟥蚐臣ꪁ臣貂苣芀蟩膦臣鎁臣꾁胣몇諥覃菣袃臣ꒈ껥銂ꇨ蚁苣蚁臣膀苣벃菣銂꣦螈苣貐鳦銂뛧膌臣讂臣蒁臣릖돦貁뷤ꢔ臣貂苣芀볯ꒁ臣ꮂ菣ꂃ臣覂곦꺁苣ꦃ菣뢁臣鎖髩ꮁ臣蒁臣꺁뇥ꢃ髧ꪁꓥ隌臣떥苣ꚁ냥閁臣膀ꓥ辁臣覤賥꾁铧较臣랕臣銂뛨袁苣鎁臣꾁飦覂臣ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯鎼胣㲑䐯噉ਾ†鯥ꊻ苣膀髩ꖎ臣讂菣莃菣꺁雩钚苣늉苣몇臣ꚇ郧꺁볯ꊽ藦꾁胣覃菣袃룤莿볯鲀蟩莿胢ꢁ臣ꚁ鿧覂苣龁苣꺁볯꺁裥銂꣨늌臣袼敫灥볯膀苣ꦃ菣궸臣趇뿥銂苣ꦃ菣릖돦ꮁ苣ꎁ臣뢛臣鮏臣讂볯疈摰瑡覼臣ꢁ臣芁苣芀鯥銼볯銼苣芏藧馁苣ꢁ胣趇뿥ꚇ郧꺁룤ꊽ藦貁ꓧ閁苣ꚁ臣誂胣뮔菥颠鿥钼볯銼볯꾁胣ꮂ菣覃臣ꢡ鷩ꢃ裥ꮁ臣讦鳦꺁苣뎃苣覃菣袃볯閼볯醼苣覜臣ꚁ臣讂胣蒐铧ꂴ臣誁臣讂郥ꒂ菣꾂菣莃菣꺁苣ꒂ苣꾁胣뺯뿥馁苣뮔듧떂菣鞃菣뎃苣것菣袃臣蒴볯趀臣芁苣芀룤ꎀ臣趇뿥꺁菣벃苣袼뻤袁臣膀볯閼볯銼볯꾁胣蒐苣ꦃ菣ꮁ뿤膌볯殈敥覼臣貂臣蒁苣芀苣ꦃ菣ꎼ뷯讼볯꺁蟩莿菣벃苣ꮁ臣蒁臣鶈鳦꺁蟩莿臣麛믨銂觥誂蟥馁臣膂臣膀觥ꮁ꣨鞮臣貂臣蒁臣趇뿥麃菣꾂苣膀髩ꖎ臣讂苣ꦃ菣ꎼ뷯꺁蟩莿菣벃苣貁裥ꢔ臣貂苣芀뻤袁臣膀蟩莿菣벃苣钼볯銼볯꺁裥龜뷤꺽苣늉苣몇臣龁苣ꮁ胣趇뿥麃菣꾂볯閼볯銼볯钼볯銼볯貼볯閼볯閼臣ꦈ铧閁苣讂胣鶈鳦趽뷧貁觥誂蟥閁苣讂臣膀臣覂臣讂ꫨ뒕臣薿ꛨ讁臣蚁臣꺁裥궖臣龁苣膀蟩莿菣벃苣钼볯銼볯꺁釥誂臣뮔듧ꒀ臣뾪臣覂苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯钼胣㲑䐯噉ਾ†鳦薾臣貂苣趽뷧讁苣趇뿥钼볯銼볯貁该蒁臣蒁苣ꢁ臣ꒈ껥꾁胣늩菣ꒂ菣袃볯閼볯鎼臣ꢑ苣꺁铧ꂴ胥銂ꫨ릁苣鎁臣ꮁ苣誂냥趁蟥閁苣讂胣鶁臣뾪鿦꾁볯誏臣림雦醐臣ꖈ胣ꮁꇨ辂苣膀臣꺁꟧開臣膀臣貂苣꺁雦醐臣ꖈ胣ꮁꇨ辂苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯閼胣㲑䐯噉ਾ†ꓥ辁臣낕臣讂雦閳臣뾽铧閁苣鞾苣芀蟩莿볯閼볯鎼臣꺾냥ꪁ뿤ꎭ臣薿ꛨ讁臣蚁臣銂裥궖臣讂臣膂臣醼臣꺁雦閳臣膀鯥銼볯鎼臣鎾臣ꚁ뿨릁苣貂苣芀臣꺁雦閳臣袂苣낁胣邙껥閁苣龁闦꺁苣뎃苣覃菣袃藩鞈臣뾁臣꾏菨ꞁ臣讂臣ꢁ臣鞰믤辁胣鎁苣覂臣꾏菨ꪁ藩鞈臣膀鯥銼볯鎼臣钼볯鎼볯ꞁꓧ閁苣讂胩誂臣节臣ꞁ臣ꎁ臣膀迧ꢜ臣뮔듧袼畣牲湥⁴楰數覼볯閼볯醼臣膀髩ꖎ臣讂볯ꒁ臣뮔듧钼볯鎼볯貼볯閼볯鎼苣몤臣芀臣貂臣貂臣ꒂ菣꾂菣莃菣钼볯鎼볯銈볯閼볯鎼臣膀볯ꎼ볯뮂菣떂菣ꮁ臣鲤鿧閁苣讂臣鎁苣꺁胣뮁臣鎼臣꺁铧ꂴ胥銂鳦馁苣芀鯥銼볯鎼臣誁臣讂郥뮔듧醃苣벃菣钼볯鎼볯꺁臣膂胣螃苣뾂菣覤迦閁苣龁뻥꺁볯ꎼ볯몇諥ꒀ볯閼볯閼臣设苣몤臣芀볯ꎼ볯꺁苣뎃菣ꪃ菣낂諥鲞苣膀믤꺁ꧦ낢髧誏臣躘苣閁臣릊黦꺁臣膂胣覃菣袃菣뾂菣뎃臣ꎼ볯꒼胥钼볯鎼볯꾁胣ꆼ볯覤迦閁苣龁苣Ꚃ苣늛럧袼裦蒁臣膀臣꺁룤ꢃ볯ꢁ郥覭臣节臣銂臣낁臣낁郥肂胣鞁臣貁臣ꚁ胣螈苣讫臣龁苣莃苣꾁胩뢸臣躸臣覂苣ꪁ臣芀臣讁臣ꪁ臣覂胣龜뻥閁苣龁雦ꊝ臣膀鳦节뿨蒁雦ꊝ苣늉苣몇臣龁苣ꮁ뻥覂苣龁苣꺁苣뾪臣讂臣ꢁ臣ꞁ臣膀ꫨ꺷臣鶁苣뮁臣Ꞥ臣辁臣ꪁ臣膀苣誂菣ꎂ菣袃臣讂臣膂臣뚈駩薆臣뾪闦閁苣讂胣鎁臣릖돦ꮁ苣貂臣膀雦鞁臣趇뿥趽뷧꾁곧醼臣螃苣ꆃ菣뢂菣뎃蛥ꮁ臣鞾苣貂苣芀苣ꆁ苣鎂胣趇뿥銂ꫨ뒕臣讂臣蒁臣늪ꇩ꾁볯ꒁ臣릖郥ꮁ臣蒁臣뺯꟧蒚臣芁苣膀郥颁蟥蚐苣蚃菣鞃臣隻臣螃苣ꆃ菣뢂菣뎃臣誁臣ꚁ苣ꦁ铧閁苣讂胣骤闦꺁믤꺁諦鎡臣膀ꛨ겜铧较臣覂菣것菣讃菣낂臣貂臣讃菣벃菣ꮃ菣趃菣袃菣벃苣꺁苣蚁臣膀苣誂駧閱臣龁諦鎡臣뾽铧閁苣讂臣节鿧貂臣蒁胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯隼胣㲑䐯噉ਾ†ꫨ뒕臣龁뷤꺽臣늉苣몇臣貂苣ꢁ胣趇뿥钼볯銼볯袼鯥銼볯銼볯貁菥讁臣뾪闦閁苣膀蟩莿觥誂蟥鞁臣ꚇ郧貁뛧財臣貂苣芀臣꺁雦鞁臣趇뿥趽뷧讁苣膀觧骮臣趇뿥趽뷧꺁臣膂臣ꪂ菣袏臣ꪂ菣꺁苣뎃苣覃菣袃臣ꒀ臣風賩閁苣讂臣趁臣ꦁ臣讁苣ꒈ雦馁苣龁苣ꮁ釥늛臣讦鳦꺁胥貁ꫨ릁苣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖 뎛볯馼볯ꮁ裦讂臣膀꣨늌臣貂臣ꒂ菣꾂菣莃菣ꒀ臣ꒂ菣꾂菣莃菣超裥钼볯醼볯ꮁ뿤颭臣貂胣貐臣ꎧ菥ꚺ볯醼볯邼볯蒽뷯覽볯讁闧ꪁ苣ꎧ菥ꚺ臣鞃菣뎃苣벃볯设臣낁胣钼볯醼볯ꮁꓧ馁苣꺁臣芁臣ꚁ胣ꪂ菣뢂菣ꮃ蛥龜볯閼볯銼臣覭臣蒁苣뎃苣覃菣袃臣馆鳧钼볯醼볯銂苣钃菣馁苣龁苣꺁苣꺁볯ꮁ臣낍裥馁苣龁苣ꮁ裥ꢔ臣貂苣芀臣꺁雦閳臣袂苣낁胣趃苣꺁뷤ꢔ苣膀铧较苣螃苣뾂菣ꞁ裥늉臣ꚁ뿤颭臣讂臣ꢁ苣鞁臣辁臣节胣ꪂ菣뢂菣ꮃ蛥龜臣覂臣뎂菣벃臣芁苣颫鏥ꪳ蛥龜臣뎂菣벃臣鞾苣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖 节臣趂苣膀蟥蚐臣릂菣벃菣ꊂ菣鞃臣膀ꓥ릮蟩꺁菣벃苣꺁苣莃菣銂菣것菣ꂃ菣莃菣ꆂ귧ꮁ뿤颭臣讂뿥膦苣銎駩馁苣龁苣膀苣릂苣麃苣몂臣貂臣ꪃ苣ꮃ苣ꒂ菣꺁菣ꒂ菣ꦃ苣뎃臣몟鳦궨꣨芦뿥꺁裥ꢔ苣ꮐ苣膀ꓥ辁臣릔雥貁迥붃臣节鿧貂臣蒁胣㲂牢ਾ諦鎡볯钼臣겪飦઎⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯馼胣㲑䐯噉ਾ†臣覂臣讂铦蒖臣꾁胣ꊂ菣袃苣ꂃꏨ꺽臣膀볯꒼菣벃苣ꞃ菣뮂菣떂菣銂郥肂苣蚁臣覤鯦閁苣芀臣꺁菣벃苣ꞃ菣뮂菣떂菣꾁胣銼믨ꞁ臣開臣銂ꓦ몇臣讂냥閁臣꺾냥뮛냦龩ꋦ랂苣蚃菣袼볯ꖼ볯뎼볯薣뷧蒂胣隻臣붥臩ꪁꏨ꺽苣馂臣讂臣ꢁ臣ꞁ臣讂胣鶁臣ꊃ菣랂菣뎃苣뎃苣벃臣ꮂ菣ꦃꏨ꺽臣随苣颻臣讂臣ꢁ臣ꞁ臣膀臣꺁蟥鮊臣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣ꮁ苣誂菣讃苣벃臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖 뎛볯馼볯銂迥ꞅ臣讂臣膀臣覂臣讂铦蒖臣붥臣鞁臣超裥꺁ꛦꖕ鯥貁ꓧ閁苣ꚁ臣讂胣ꂊ胩ꚺ꣨钼볯邼볯꾁胣ꎼ볯꒼ꏨ꺽臣覂룤꺮飦ꪁꓦꖟ铧较苣鞏臣随苣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣钼볯邼볯ꮁ蟥鮊臣讂胣鶁臣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣钼볯邼볯꾁胣馆鳧貁鋦놽臣貂臣ꢁ臣꺁苣ꆃ菣꺁꟨龀뫥銂뇦骮臣讂臣膂臣膀觥風諥龀駦袨臣겸껥ꒀ苣뾽铧馁苣芀臣鞁臣膀臣꺁룦骮胥袼胩ꚺ鯥邭볯꾁胣붥臩ꮁ菣궃苣ꦃ菣閁苣龁苣벃菣ꮂ菣覃菣궃苣莃苣벃볯隼볯銼臣袂臣ꚁ裥ꢔ臣貂胣趸껩躘臣鲤鿧뮔菥钼볯邼볯ꮁ꿥鞁臣鲃苣꺿귦貁ꇨ辂苣膀菣놂臣ꆄ臣몇諥뮔菥钼볯邼볯貁蟥鮊臣貂苣芀苣벃菣ꮂ菣覃菣궃苣莃苣钼볯邼볯ꮁ臣醁苣鲃苣꺿귦鞃菣낂菣ꂃ臣鞁臣꾁胣뎂菣钃菣벃苣鞃菣낂菣龃菣낂苣螃苣뾂菣뮔菥꺿뻥꺁뷥궥胨ꮁ苣誂鿧覂苣ꚁ臣讂꣦隺髧ꪁ苣ꮃ苣ꪃ苣ꂃ臣뾽铧閁苣讂胣设臣낁胣鲀볯薽뷯薽뷯钽뷯蒽†볯膽뷯薽뷯鎽†뷯躽†볯覽뷯覽뷯膽뷯₌ꦼ뷯膽뷯薽†볯薽뷯钽뷯銽뷯钽뷯辽뷯鶀胣궼볯ꦼ뷯銽뷯袽뷯趽†볯薽뷯膽뷯ꢷ鯩膀볯낼볯ꖼ†볯覽뷯薽뷯钽뷯躽뷯랂菣벃苣膀볯钼럥膀觧ꮁ蛥袉臣醼볯鞼裢醼볯閼菣벃苣貁迥ꞅ臣貂苣芀鯦ꮁ胣ꆰ飦隌臣貂臣肊ꇨ꾁胢ꦼ뷯膽뷯薽†볯銽뷯莽뷯鎽뷯覽뷯螽†볯膽뷯蒽뷯辽뷯讽胢₝견볯袉胣ꪼ뷯袽뷯₎ꎼ볯늼뷯鎽뷯鞑胣ꎼ볯ꎼ蟥袉駧財胣鎼볯隼裢鎼볯醼菣벃苣ꞁ飦覂臣ꮁ臣貂臣蒁苣芀戼㹲肊ꇨ鎼볯꺁ꫨ躘㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖 뎛볯馼볯銂迥ꞅ臣讂臣膀臣覂臣讂铦蒖臣릖郥ꮁ뻥ꎁ臣讧裦ꢁ臣ꚁ胣颻뇥꺁菣ꪃ菣뾂菣閼볯醼볯꺁뷥讅臣몤臣貂臣蒁苣芀ꧨ鞃菣뎃苣벃볯邼볯邼臣膀ꧧ麴볯邼볯銼臣궸臣뾌藥閁苣讂菣ꪃ菣袃菣벃菣閼볯醼볯銂鳦馁苣袂臣ꮁ꣨袨臣貂臣蒁苣芀ꧨ鞃菣뎃菣궃菣ꮃ볯邼볯醼臣목듦閼볯醼볯ꮁ賦ꖅ臣貂苣ꢁ藥ꮁ胣궃菣ꦃ菣袼뻤袁臣膀볯邼볯鎼볯閼볯醼볯覼苣覜臣ꚁ臣讂胣늩菣벃菣벃臣膀蛥ꢃ臣馴苣龌苣ꢁ藥ꮁ胣뮔菥꺁跥랈臣龁苣膀ꛨ花臣鲿臣ꚁꧨ馴苣鞃菣뎃菣颃菣覃볯邼볯閼臣겐胩馁苣芀郧뎃髧ꮁ臣膀ꧨ鞃菣뎃菣궃菣ꮃ볯邼볯醼臣膀뛦鞀臣貂苣ꒂ菣꾂苣鮾뗧馁苣薣뷧ꮁ諥袁胣鞃菣뎃菣ꆃ菣ꎂ苣銂若袁臣蒁苣芀苣뎃苣꾁胣뮔菥꺁跥랈臣鮚臣鞃菣뎃菣颃菣覃볯邼볯閼臣袂苣袶胨閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯銼胣㲑䐯噉ਾ†菣ꪃ菣뾂菣閼볯醼볯꾁胣ꊂ菣袃苣ꂃ臣龮雦设臣ꦁ裥ꪁ蛥ꂊ럥ꮁ苣誂꟦覯臣貂苣鎁臣貁臣趁苣芀菣ꪃ菣뾂菣꾁胣떼볯ꊼ菣벃菣銂믤鞁臣뎂菣钃菣벃苣閼볯銼볯ꢁ胩ꆿ臣讂胣鞃菣뎃苣벃菣讃菣袃볯邼볯颼臣鞃菣릂菣莃苣邈뷥꺁苣벃苣ꞁ臣誂胣뮔菥銂跥랈臣讂臣膂臣薆菩鞃菣뎃菣颃菣覃볯邼볯閼苣覜臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯鎼胣㲑䐯噉ਾ†臣꺁菣ꪃ菣袃菣莃菣閼볯醼볯꾁胣ꪇ该鲃菣螃苣뎃苣肊ꇨꮁ苣誂菣ꪃ菣袃菣莃菣膃菣鞃볯邼볯邼臣ꖎ뛧閁苣ꚁ臣讂胣鞃菣뎃苣벃菣讃菣袃볯邼볯颼臣떂苣몂苣鮸냥閁臣讂臣膂胣늩菣ꪃ菣袃菣莃菣膃菣鞃볯邼볯邼臣閃菣궂苣隃菣ꪁ鯥꾷鿥뾝臣随苣颻臣覂苣ꚁ臣讂胣떼볯ꊼ胩ꆿ苣벃菣ꮃ볯邼볯銼苣讻臣ꚁ菣ꪃ菣뾂菣ꚃ菣莃菣閼볯醼볯ꮁ믨膀臣貂苣辏蛥袼뷯薽뷯莽뷯覽뷯钽뷯辽뷯覼臣覂铧较苣龔裦馁苣龁苣膀ꧨ鞃菣뎃菣颃菣覃菣莃菣꾁胣肜雦꺁跥躰뷤붣胩肊ꇨꮁ苣誂뷤覂苣膀雩ꎀ臣龁菣ꊃ菣벃귧銂鳦鞁臣蒁苣芀苣ꆁ苣鎂胣隻臣骤臣꺁苣뎃苣벃菣Ꞃ菣릂臣ꊽ볥貁裥ꢔ臣貂뻥讂胣鞃菣뎃苣颃菣覃菣莃菣꾁胣袺苣겪飦閁苣鞾苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖 鎾臣ꚁ胣뮔菥꺁跥랈臣鮜臣貂苣ꢁ臣膀菣ꪃ菣뾂菣ꚃ菣莃菣閼볯醼볯ꮁ軦骶臣貂臣蒁苣뎂菣钃菣벃苣랂苣蚃菣閼볯銼볯꾁胣놂菣隃菣閼볯銼볯銂믤鞁臣鞃菣뎃菣ꚃ菣莃菣閼볯醼볯ꮁ菣벃苣風뿨肨ꫨ袼慰敧搠獥牣灩楴湯覼苣ꊻ胩馁苣芀菣ꪃ菣袃菣莃菣閼볯銼볯꾁胣貾臣鞃菣뎃苣颃菣覃볯邼볯閼臣낍裥閁苣讂铧较苣隺若馁苣芀菣ꪃ菣袃菣벃菣閼볯醼볯꾁胣袶胨閁苣讂菣ꪃ菣袃菣螃苣ꊂ苣ꒂ菣꾂苣膀뷤蒁苣馁臣ꊽ藦ꞁ뻤ꚵ臣膀菣ꪃ菣뾂菣ꚃ菣莃菣閼볯醼볯ꮁ苣誂뷤ꢔ臣貂苣ꢁ胣鶁臣鞃菣뎃菣궃菣ꮃ臣낖臣蒁菣ꪃ菣袃菣벃菣ꮁ뷧趁迦袁苣貂苣芀戼㹲肊ꇨ钼볯꺁ꫨ躘㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖 閁苣ꪁ苣ꦁ뿥ꞁ臣膀苣ꆃ菣랂苣蚃菣誏臣낍裥랂苣蚃菣꾁藥꒙臣貂胣Ꞥ臣ꪁ苣꾂菣벃菣꺁ꫨ뾁迥誂ꏨ꺽볯沈牡敧猠牣敥⁮敲摡牥볯ꮁ뷧趁迦袁苣貂苣芀苣벃菣ꮂ菣覃臣膀ꏨꊝ臣薃ꃥ貁鯦趁뻨뺁苣膀臣꺁菦놠臣ꢡꓧ貁믤꺁鷩ꮁ跥랈臣貂苣袂臣ꮁ꣨骮臣貂臣蒁苣芀뻤袁臣膀苣벃菣ꮂ菣覃臣겜臣뎂菣蚃菣蒃苣낖臨꺁苣뎃菣뎃菣銂郥肂臣ꢁ臣ꞁ臣讂胣鶁臣袂臣ꪁ苣릂菣ꂃ臣肸뻤貁鯥銼볯隼臣몤臣貂苣节臣ꞁ臣ꎁ臣膀苣벃菣ꮂ菣覃볯銼볯邼臣鶁臣肸鷩ꮁ鳦꺁苣ꒂ菣ꮃ苣覜臣膀믤꺁鷩ꮁ臣膀跥랈臣貂臣뎂菣覃賥閁苣龁菣벃苣銂鳦馁苣芀苣벃菣閼볯醼볯꾁ꫨ뾁迥誂ꏨ꺽볯銼볯銼臣뾌藥閁苣讂胣鎁臣궪臣随苣薣뷧閼볯醼볯꾁胣颊苣뎕苣鎁臣貁臣趁苣袂臣ꮁ菣것苣랂菣ꮃ臣螃苣릂菣것苣閼볯醼볯銂若袁苣芀苣벃菣꺁ꫨ뾁迥誂ꏨ꺽볯銼볯銼臣膀觥蒂뻥趂臣骃菣뢂苣膂臣ꎁ臣誂胣隻臣뚈뻥銂ꇨꎁ臣誂臣讂臣膂臣螃苣릂菣것苣뚈뻥薣뷧閼볯醼볯銂鳦馁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖 鞁臣貁臣ꚁ胣뎛볯馼볯꺁꟦邈臣节臣꾁胣겜苣낖臨蒂鯩貪苣肊ꇨ麃菣ꖃ苣ꮃ귧꺁뷥込臣薃ꃥ銂諥螎觨辁藩莸臣趁苣鎁臣貁裥讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯鞼胣㲑䐯噉ਾ†闦骤臣꺁ꓥ뒛迥뎁볯袏臣꺿귦貁胣Ꞥ臣讁臣겪飦閁苣龁鳦몙飦꺁닧麥臣龁臣蒯鯥讁苣뢀蓨馁苣鎁臣ꪁ臣膀觧骮臣龮雦꺁뷥讅臣몤臣貂苣袂臣ꪁ鳦몙飦뢁臣閁苣ꚁ苣袂臣鎁臣꾁胣鎽ꗦ薀臣袂臣ꚁ郧ꎧ臣貂苣蚁胣鞁臣貁臣ꚁ胣겜껥붖뻤꾁胣뎛ꓧ閁苣ꚁ臣ꚁ苣閁苣ꚁ臣ꪁ臣ꚁ苣膀臣覂苣讂苧ꞁ胨꺅臣貂苣릁臣ꞁ臣讂胣㲂牢ਾ諦鎡볯鞼臣겪飦઎⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯颼胣㲑䐯噉ਾ†臣覂臣讂铦꾉臣膀鏦벼髧ꪁ菣ꦃ菣랂菣릂菣궃菣꾂苣뾽铧鞁臣궂菣뎃菣릂臣誸臣뮔菥銂胢辏臣鶀臣蒁臣ꚇ郧ꮁ臣蒁臣隫臣覂苣讂胣邃菣鞃菣莃菣肊ꇨ貁뷤ꢔ臣貂苣鎁臣貁觥邏臣芁苣膀觧ꮁ胣뾽铧閁苣讂郥뮔菥貁胣뮔菥ꢡ鷩꺁菣꾂苣膃菣벃苣辦껥馁苣邃菣鞃菣莃菣銂鳦馁苣鎁臣貁觥邏臣芁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖 뎛볯馼볯ꮁ臣膀ꛨ겜臣鞁臣꺁菣Ꚃ菣覃菣ꦃ菣랂菣뮃菣뎃菣麃菣鞃볯馼볯醼臣몤臣貂臣蒁苣芀鯥銼볯颼臣꾁胣뎛볯馼볯꺁볯銈볯馀럧꺁雦ꊝ臣몤臣貂胣늩雦ꊝ臣膀룤겈髧ꪁ菣Ꚃ菣覃菣ꦃ菣랂菣릂菣궃菣꾂볯馼볯醼臣ꢡ鷩꺁룤겈髧隤뷥閼볯邼볯銂鳦馁苣芀鯥銼볯鞼臣邃菣鞃菣莃菣銂鳦馁苣隃菣莃苣ꖃ苣袃菣벃苣銂룤겈髧ꪁ臣랂苣뎃뷥꺁胢궂菣뎃菣릂胢뮔菥袼菣뎃菣麃菣鞃臣뎛볯馼볯ꮁꓧ閁苣膀볯銈볯馀럧꺁ꯩ閁臣뎛볯邼볯ꮁꓧ閁苣龁苣꺁볯ꮁꇥ讂臣ꢁ臣趉迦ꞁ臣讂胣鶁臣颫臣꾁胣ꊳ諧꺁菣벃苣袼뻤袁臣膀볯馼볯隼볯讁苣ꪁ苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖 閁苣ꪁ苣릔雥ꞁ臣膀鳦芵髧ꪁ菣뎃菣麃菣鞃臣ꊽ裦꺁臣膂臣膀鯥銼볯颼臣邃菣鞃菣莃菣ꢁ鯥鎼볯邼臣邃菣鞃菣莃菣ꢁ臣膀뻤ꚵ臣貂臣鮉胦ꂛ귥ꮁ뻥ꎁ臣꺨胣꺁雦閳臣邵郥閁苣讂胣鶁臣鮉胦ꂛ귥꾁胣鲀觥Ꞁ胢꺁菣ꒂ菣袃胣袏臣鲀菣것苣랂菣ꮃ胢꺁菣ꒂ菣袃苣뾽臣龁諥鲞苣龔臣讂苣蚁臣궨꣨閁苣讂胣뎛볯邼볯ꞁ臣膀鯥銼볯颼臣뎛볯邼볯꺁볯ꒁ臣邃菣鞃菣莃菣貁뷤蒁觥Ꞁ臣隃菣莃苣ꖃ菣ꒂ菣袃臣龁苣ꮁ뗧袐臣貂臣设臣몤臣貂臣蒁苣芀鯥鎼볯銼臣꾁胣뎛볯馼볯ꢁ鯥鎼볯邼臣銼臣꺁菣뎃菣麃菣鞃臣颫臣鮉胦꺁菣ꦃ菣랂菣骃苣뎃菣꺁臣膂臣邵郥閁苣龁뻤貁ꓧ閁苣ꚁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯醼胣㲑䐯噉ਾ†臣覂臣讂铦蒖臣꾁胣떵臣랅臣覂臣讂菣ꦃ菣랂菣릂菣궃菣꾂臣肸껥꺁迥醡胦銂鳦鞁臣蒁臣貃駦꺁蟥ꢃ臣肺臣閁苣讂臣ꞁ胣邃菣鞃菣莃菣꺁뗧袐臣鮚臣ꚁ胣邃菣鞃菣莃菣꾁跥钴臣颻諥閁苣꾁臣ꪁ臣芀臣龁臣ꎁ臣膀鯥鎼볯醼苣뎛볯邼볯꺁諥鲞苣邈臣芁臣讂臣膂臣꾁胣隃菣莃苣ꖃ苣袃菣벃苣꺁菣뎃菣麃菣鞃臣膀菨꾙臣邃菣鞃菣莃菣ꞁ臣ꎁ臣궃菣醃苣閃苣ꮃ苣벃臣貂臣节臣ꮁ믤ꂊ臣貂苣芀臣꺁菣ꦂ菣醃苣閃苣ꮃ苣벃臣膀뗧꺁藥꺁觥Ꞁ鯥邭臣袂臣ꚁ뇦뺁苣蒯鯥袼뷯膽뷯覽뷯鎽볯銂鳦鞁臣蒁苣芀ꧨ鮉胦ꂛ귥貁ꯩ醁苣낁ꯩ蒁臣ꦁ胣閃苣ꮃ苣벃臣蒯鯥꾁뫥辁臣誂胣辀臣鞁臣讦臣讂菨꾙臣ꢡ鷩蚃苣릂菣ꎃ臣醰臣辁臣讂胣隃菣莃苣ꖃ苣袃菣벃苣貁雨讁臣龁苣膀뷤节蓧讁臣龁苣馁苣뒠触袼臣ꢁ苣ꦁ臣膸菩ꮁ닦ꎁ臣蒁苣覼臣꾁菣ꎂ菣뾂菣貁臣醁苣貂臣貃駦꺁ꇨꊝ菣꾂苣膃菣貁胣龮髩꺁菨꾙臣ꢡ鷩蚃苣릂菣ꎃ臣躏雦馁苣袂臣ꮁ胣궃菣醃苣閃苣ꮃ苣벃臣蒯鯥꾁菣ꦃ菣랂菣릂菣궃菣꾂軥閁臣鲿臣ꚁꓥ開臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖 뎛볯邼볯誏臣뎛볯邼볯銂迥ꞅ臣讂臣膀裥龜臣貃駦邃菣鞃菣莃菣銂ꓧ馁鯥鎼볯鎼苣ꢔ臣龁蟥蚐臣设臣몤臣貂臣蒁苣芀菣뎃菣麃菣鞃볯馼볯醼臣膀菣벃菣릂菣ꎂ菣뾂菣貁臣醁苣貂臣节臣銂ꛨ蚁諧讅臣膀觥Ꞁ臣颫臣骃苣뎃菣閼볯醼볯銂鯥鎼볯钼臣몤臣膀菣벃菣릂菣ꎂ菣뾂菣貁臣醁苣貂臣邃菣鞃菣莃菣閼볯醼볯銂ꛨ蚁諧讅臣膀觥Ꞁ臣躽臣骃苣뎃菣閼볯醼볯銂鯥鎼볯閼臣몤臣ꚁ臣讂胣㲂牢ਾ諦鎡볯颼臣겪飦઎⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯鎼胣㲑䐯噉ਾ†臣覂臣讂铦蒖臣꾁胣ꖅ諥뮔菥꺁觨龟볯授汯牯朠浡瑵볯꾁蟥鮊铧较臣늉鿥袼潣潬⁲戼㹲朊浡瑵볯ꮁ胢ꊃ菣閃볯消牯桰摥볯鶀臣貂苣芀臣꺁蟥鮊铧较臣늉鿥꾁胣낕臣讂ꓨ낕臣늉鿥꺁ꧨ財臣蒁臣릖돦ꮁ苣ꎁ臣겋雦蒚臣몱껥閁苣龁苣꺁臣芁苣芀臣覂臣讂铦蒖臣꾁胣蚐菦蒚臣꾁胣릉껥꺁苣뾂苣ꮃ臣隃菣莃苣ꖃ苣袃菣벃苣ꞁ铧较苣꺽臣鮏臣讂臣蒁臣袂臣ꪁ胣閁苣ꪁ苣뢊ꇨ蒚臣ꚇ郧ꮁ菣것蟥蚐苣蚃菣鞃臣뾽铧閁苣讂胣鶁臣隃菣莃苣ꖃ苣袃菣벃苣꾁胣뮔菥讁苣늉苣붊蟥鞁胣늩菣ꦃ菣랂菣릂菣궃菣꾂臣肉鳦늉鿥ꮁ雩ꎀ臣讂觨銂鳦馁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖 肜뗧蒚臣몇諥뮔菥銂뷤邈臣讂苣蚃菣鞃臣膀鯥鎼볯隼臣ꚬ迥隼볯醼볯ꞁꓧ閁苣龁苣꺁臣芁苣芀곧醼臣릂菣莃菣隼볯醼볯꾁胣鮜臣鞁臣꾁苣벃菣ꮂ菣薣뷧ꮁ苣誂ꓦꖟ臣貂臣뮻蓦꺁藥鮊铧较苣ꖅ諥馁苣鎁臣ꞁ臣讂胣鶁臣ꖅ諥뮔菥꺁觨龟臣膀触骮꿧늛臣늉鿥꺁蟥鮊铧较苣鲽裦馁苣龁苣ꮁ胢ꊃ菣閃볯䶈牯桰摥볯鶀迥꾁胢꾃菣鞃볯垈牡数覼胢閁苣讂볯隼볯醼볯覼胣ꊃ菣閃苣뎃苣ꚇ郧ꮁ臣蒁臣꾁뻥낿臣讂胣몇諥꺁觨龟臣鲽裦閁苣讂臣膀곦꺁苣蚃菣鞃臣꾁胣ꦁ귦ꪁ菣ꦃ菣랂菣릂菣궃菣꾂諦鎡臣ꦁ铧閁苣讂胣隃菣莃苣ꖃ苣袃菣벃苣肊ꇨ꾁胣Ꞥ臣ꪁ苣覤賥銂苣龁苣馁臣ꢁ臣ꞁ臣讂蟥蚐臣芁苣芀뷤ꢔ臣貂苣隃菣莃苣ꖃ苣袃菣벃苣꺁껥鮚臣ꊽ藦ꞁ臣膀觥낿臣龁諦鎡臣겜駧躘臣뚵꿥薿ꛨꞁ臣讂꣨ꞁ臣ꪁ臣芀藥鮊铧较臣뺯臣ꚁ胣늉鿥銂裥邙臣龁볦몇苣財臣ꚁ蟥鮊铧较苣ꊽ裦馁苣龁苣ꮁ臣꺁菣ꦃ菣랂菣릂菣궃菣꾂諦鎡臣ꦁ铧閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯閼胣㲑䐯噉ਾ†鯥鎼볯鞼苣芏藧馁苣ꢁ胣겂菣莃菣麃菣钃菣낂臣ꊃ菣閃苣뎃苣꺁闥財臣肸뻤貁ꓧ閁苣ꚁ臣讂胣겼볯膽볯芽볯늉ꧧ鎖臣芁苣ꚃ菣邃菣떂菣늉ꧧ鎖볯邼볯醼臣骤臣꺁迥붃臣늉胥貁껥ꦾ臣貂臣랂菣낂菣꺁觨목雩貁뷤ꢔ臣貂苣鎁臣貁觥邏臣芁苣芀臣꺁觨목雩꺁蛥ꢃ臣膀藥鮊苣뎃苣벃臣膀臣讂꿧늛臣躘뫥隼볯銼볯銂ꓦꖟ臣讂臣ꢁ臣ꞁ臣讂胣閁苣ꮁ胣몇諥鞃菣뎃菣薣뷧꾁胣鞃菣뎃苣벃觨龟볯邼볯鎼臣誁臣讂觧骮臣蒯鯥꺁觨銂蟥鮊臣趁苣节臣ꢁ믤骮臣讂胣늩菣ꪃ菣뾂菣늉鿥꾁藥鮊苣뎃苣벃臣늉鿥隼볯銼볯袂苣节냥閁臣讁苣ꖟ苣ꪁ臣鞁ꓥ趁臣讁苣ꖟ苣ꪁ臣芀諨鎡髧늉鿥隼볯銼볯꾁觧骮臣릂苣ꒂ菣ꮁ뻥ꎁ臣辦껥閁苣讂胣鶁臣뢊ꇨ蒚觨龟볯邼볯钼臣膀꟦薀臣肊ꇨ꺁뷤ꢔ苣骀臣ꚁ藦趇臣讧꿧馁苣鎁臣貁臣趁苣芀뻤袁臣膀触鮜臣몇諥뮔菥貁苣궂菣뎃臣貂胣肉鳦꺁蟥鮊铧较臣膀볯誼뷯誼뷯誼觨목雩꺁蛥ꢃ臣릉껥꺁꿧늛苣ꮐ苣袂臣ꮁ胣늉臣銃苣袃苣ꦃ菣貁꟦覯臣貂苣芀触骮臣躘뫥꺁볯ꆬ藥꺁볯誼뷯誼뷯誼觨목雩꺁苣蚁臣뎛볯邼볯貁꟨袇臣趁苣鎁臣꾁胣뎂菣钃菣벃苣낂菣閃苣莃苣ꊖ뿤꺁뷥궥胨ꮁ苣貂臣蚐꟨閁苣鞾苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖 鞁臣貁臣ꚁ胣ꖅ諥뮂菣떂菣늉鿥隼볯銼볯꺁룤꺁觨銂諨鎡髧늉鿥隼볯銼볯ꮁ꟧馁볯消灡볯鎁臣貁뿥膦臣芁苣芀臣覂臣膀껦떿臣貁苣膀諨鎡髧늉鿥隼볯銼볯꾁胣릉껥꺁蟥鮊菣ꪃ菣뾂菣늉鿥隼볯銼볯ꮁ臣ꎁ臣鲀臣뾁蟥讂觨龟胢꺁觨銂郥鎂臣蒁苣芀臣꺁苣蚁臣놂菣릂臣꾁胣몇諥꺁觨貁菣ꪃ菣뾂菣늉鿥隼볯銼볯薆臣芁苣龁苣ꮁ胣뢊ꇨ蒚臣늉鿥隼볯銼볯銂꟧馁볯消灡볯薿ꛨ貁臣讂臣趂臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖 뎛볯邼볯銂迥ꞅ臣讂臣膀룤膦臣膦뇦꾁胣겼볯膽볯芽볯ꒀ볯邼볯醼苣겼볯膽볯芽볯몇諥ꒀ볯邼볯銼臣뮧臣龁苣꺁볯ꆬ藥ꮃ菣꾂苣莃菣蚃菣隃菣袼뻤袁臣膀볯邼볯邼볯銂苣벃菣ꮂ菣覃臣覜臣讂臣蒁臣鎁臣ꞁ臣讂胣붥臣鞁臣꾁胣鶁臣鎼곦莅菣莃苣ꊂ菣鞃菣벃菣ꮃ볯邼볯邼臣膀볯ꆬ藥麃菣钃菣낂臣龁苣ꮁ껥ꦾ臣貂苣릉껥꺁菣ꒂ菣袃臣膀껥ꦾ臣貂臣鶃苣뎃菣鎖臣궸雩ꒀ臣麃菣钃菣낂臣龁苣ꮁ裥ꢔ臣貂苣鎼곦鲣雩ꢁ苣覜臣讂苣뎃菣꾂菣ꪁ뷥込臣邏뻤閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯颼胣㲑䐯噉ਾ†鯥鎼볯馼苣芏藧馁苣ꢁ胣醼臣꺁껥ꪳ髧ꮁ믤辄臣ꖅ諥겂菣莃菣릂菣벃苣隼볯钼볯讁苣견볯꺁触鮜臣몇諥겂菣莃菣뾂菣늂菣袃苣骃菣릂볯邼볯醼臣꺁苣ꊃ菣袃菣ꊃ菣閃苣뎃苣銂臩ꢔ臣讂臣膂臣ꚇ郧ꮁ臣蒁臣꺁ꗦ膂臣肸裨蒚臣设臣몤臣貂臣蒁苣芀뷦ꢜ髧ꮁ臣膀藥鮊苣ꊃ菣袃苣骃菣릂볯邼볯邼臣薆臥ꞁ臣ꎁ臣몇諥겂菣莃菣뾂菣늂菣袃苣骃菣릂볯邼볯醼臣隤臥ꮁ臣讂菣ꒂ菣袃볯设臣낁胣隼볯钼볯覼苣겂菣莃菣麃菣钃菣낂蟥蚐臣ꚇ郧鞁臣醁苣낁臣覂臣蒁胣趉꣨鎼곦莅苣ꦃ菣ꮃ菣꾂苣莃菣蚃菣隃菣隼볯鎼볯꾁볯銼猼灵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰躽⼼畳㹰볯醼볯㲉畳⁰浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯㲓猯灵꺁苣ꒂ苣銂鳦馁苣芀뷯꾁胣醼臣覂胣肜ꓥ늉苣뎃菣벃菣뎃菣뮃菣것苣뢂菣뎃볯设臣낁胣骀룥꾁볯鎃菣袃볯뺁臣꺁꿧늛臣芁苣芀믤辄臣꾃菣鞃臣ꮃ菣꾂苣莃菣蚃菣隃菣薆臣ꚬ迥隌臣貂苣芀ꧨ蚃菣隃菣꺁뷤ꢔ臣膀臣龁胣ꖈ胣ꮁ뫦馂臣貂臣ꚬ迥隌菣벃菣閃苣뎃苣랂菣뎃苣겋ꯧ閁臣讂苣ꮃ苣ꪃ苣ꂃ苣龔臣閁臣讂胣鶁臣ꊂ菣뒂菣몂菣꾁胣뮻蓦꺁菣벃菣ꊖ闦꺁臣膂臣袺룦ꞁ臣讂胦붃苣覜臣ꚁ臣讂胣꾃菣鞃雩낕臣ꎀ뛧馁苣鎁臣꾁ꛨ花臣貂臣蒁胣鞁臣貁臣ꚁ胣鶁臣ꊂ菣뒂菣몂菣ꮁ臣蒁臣꾁胣뮻蓦꺁菣벃菣ꊖ闦ꮁ臣ꎁ臣랼鯥ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯鞼볯馼胣㲑䐯噉ਾ†臣꺁菣莃苣ꊂ菣鞃菣벃菣ꮃ臣膀闦낕臣鎼볯超裥ꞁ臣誂胣龮闦꺁蟥鮊觨뎂菣螃苣趃菣袃臣ꖅ諥뎂菣螃苣趃菣袃臣蚠臣超裥閁苣讂胣鎁臣袂臣ꮁ臣ꚁ胣趉雦꾃菣鞃雩낕臣ꚬ迥隌臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖 膦뇦閁苣龁铧较臣ꮂ菣벃菣꾃菣鞃臣膀볯뮔듧躯胣몇諥뮔菥꺁ꃩꮁ꣨鞮臣貂苣芀臣꺁苣ꮃ苣ꪃ苣ꂃ臣鎼볯ꮂ菣벃菣莃苣ꊂ菣鞃菣벃菣ꮃ臣꺁菣뎃菣ꂃ臣ꊂ苣뮂苣銂뿥膦臣馁苣貁胣ꖅ諥늉臣목雩궸臣꾁믦覂臣ꮁꓥ隌臣讂臣ꞁ胣ꦃ菣肃菣ꪁ苣꾂苣릂臣肸裨蒚臣꾁뗧肸胦袼潣敨敲瑮볯貁臣讂胣ꖅ諥誏臣몇諥뮔菥뢁臣랂菣놂菣랂菣ꮃ臣ꊂ苣뮂苣貁ꛨ花臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖 趸迥ꂬ臣袃菣ꪃ菣ꊂ菣꾃菣鞃菣ꊂ菣뒂菣몂菣꾁곦꺁雧벼볯讼볯뎂菣覃臣龮雦閁苣讂胣㲂牢ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㈵⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖 趉꣨겂菣莃菣Ꞝ룧鞃菣뮂苣꾁胣붂菣릂苣ꊃ菣袃臣誁臣讂觨꺁臩蒁苣궶賦鞁臣ꒁ胣趪鿧ꞁ臣讂觨꺁ꓥ隌苣肜냥邙臣馁苣ꢁ臣蚁雦閳臣膀苣벃苣겂菣莃菣꺁觨銂胣袂苣辰臣ꪁ苣벃苣莃菣겂菣莃菣꺁觨ꮁ菣莃菣閁臣袂臣ꢁ臣讂胣겂菣莃菣Ꞝ룧꺁꣨鞮臣늉臣꾃菣钃菣낂臣覂裥궖臣貂苣꺁臣膀諥鲞髧ꪁ苣ꊃ菣袃鳥꺸臣誸뿨鞁臣ꮃ菣꾂苣莃菣蚃菣隃菣ꞁ꟩開臣貂苣鞃菣뮂苣銂铧蒁臣龮雦閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鎼胣㲑䐯噉ਾ†苣ꊃ菣袃鳥꺸苣ꮃ苣ꪃ苣ꂃ臣鎼곦莅菣莃苣ꊂ菣鞃菣벃菣ꮃ臣讧꿧銂郥뾁胣뎛볯邼볯銂迥ꞅ臣ꚁ뿨릁臣袂臣ꪁ곦꺁雧벼苣벃菣ꞁ껥붖臣貂苣芀戼㹲㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔲㰳愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯钼胣㲑䐯噉ਾ†苣벃苣겂菣莃菣袏臣뾂菣늂菣袃苣ꊃ菣袃臣蒁臣貂臣貁菣것菣袃菣ꦂ菣ꂃ臣ꚁ鿧覂苣ꚁ臣讂臣覂臣膀苣ꊃ菣袃ꓥꊝ뷤꾁菣것菣袃菣ꒂ菣袃臣뢇賥讁苣袨껧閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯閼胣㲑䐯噉ਾ†鯥鎼볯邼苣芏藧馁苣ꢁ胣뢊ꇨ蒚諥鲞臣떉胩ꮁ臣蒁臣肸裨蒚臣뮴铧閁苣讂蟥蚐臣芁臣ꚁ胣貾뿨꺁ꛥ辁苣ꊃ菣袃菣ꊃ菣閃苣뎃苣ꢁ꟧閁苣讂蟥蚐苣뾽铧鞁臣膀뷤覂臣꺁苣벃苣뮃苣ꊃ菣袃볯邼볯邼苣뾂菣늂菣袃菣겂菣莃菣隼볯閼볯ꮁ菣莃菣閁臣讂臣膂臣誸꣨ꚇ郧貁뷤ꢔ臣貂뻥讂胣겂菣莃菣뮃菣벃菣ꎂ菣낂臣膀苣벃苣뮃苣ꊃ菣袃룤꺁觨銂苣벃苣莃菣뮃苣ꊃ菣袃룤꺁觨뢁臣麃菣钃菣낂苣뒛軦뎂菣袃菣벃菣馁苣龁苣ꮁ뷤ꢔ臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖 겂菣莃菣Ꞝ룧ꢁ郥颧臣膀苣ꊃ菣袃菣ꊃ菣閃苣뎃苣꾁胣뮔菥꺁觨龟볯겂菣莃菣覼苣릉껥꺁諨鎡髧릂苣ꒂ菣ꮁ볤閁臣讂臣膂臣뾽铧閁苣讂臣节鿧貂臣蒁胣겂菣莃菣뮃菣벃菣꺁꣨鞮臣ꮂ菣벃菣벃菣뎃苣ꚇ郧讁苣蚈雦閁苣讂臣ꞁ胣겂菣莃菣Ꞝ룧ꢁ郥颧臣膀諥鲞髧ꪁ苣ꊃ菣袃菣ꊃ菣閃苣뎃苣꾁胣ꮃ菣꾂苣莃菣蚃菣隃菣銂꟩開臣讂苣ꮃ苣ꪃ苣ꂃ臣袂臣ꚁ껥붖臣貂苣鎁臣貁臣趁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖 겂菣莃菣뮃菣벃菣ꎂ菣낂臣놅臣膀ꓥ辁臣붂菣릂菣겂菣莃菣늉볯设臣낁胣隼볯閼볯覼臣膀郥낕臣뺯뿥馁苣뾂菣늂菣袃苣ꊃ菣袃觨袼뻤袁臣膀볯邼볯钼볯ꮁ鯧ꖎ菣莃菣閁苣讂胣ꮃ菣꾂苣莃菣蚃菣隃菣궸臣麃菣鞃臣貂臣뾂菣늂菣袃臣议귥鞁臣蒁苣뾂菣늂菣袃觨꾁胣릉껥꺁苣벃苣莃菣늉볯设臣낁胣隼볯閼볯覼臣ꂊ蟩貒臣鞁臣袨껧閁苣讂胣鶁臣뾂菣늂菣袃觨꾁ꗥ뺁臣辁臣膀郥ꮃ菣꾂苣莃菣蚃菣隃菣꺁菣ꒂ菣袃臣覂꿥鲿臣讂苣벃苣ꮂ菣벃臣ꞁ臣鶷鯩꺁뫤鞹臣蚀闦ꮁ苣誂蟩뾁믤醁臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖 겂菣莃菣뮃菣벃菣ꎂ菣낂菣ꊂ菣뒂菣몂菣貁곦꺁雧벼苣벃菣ꮁ苣誂藥뺏賥閁苣讂胣㲂牢ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㐵⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖 趉뿨꺁諦鎡臣肜裥ꮁ铧较臣겂菣莃菣銂触骮臣ꢂ菣ꊂ臣邙껥馁苣龁苣ꮁ뷤ꢔ臣趁苣鎁臣꾁胣뎂菣钃菣벃苣낂菣閃苣莃苣릂臣誁臣讂뷥궥胨ꮁ臣躘駧ꞁ臣趂臣芀뛧蒁臣膀뻤袁臣膀胢릂迦뮔돦鶀諦鎡臣袂臣ꚁ룤袁苣貂苣ꢁ郥颧臣릊黦銂铧颁臣鮁苣龁苣膀裥邙臣貂臣겂菣莃菣뮔菥ꮁ菣ꦃ菣랂菣릂菣궃菣꾂菣ꎂ菣뾂菣貁臩ꢔ臣貂苣芀戼㹲肊ꇨ閼볯꺁ꫨ躘㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖 趉뿨꺁苣벃菣ꮂ菣랂苣蚃菣꺁鿥겜臣뎛볯醼볯ꮁ곧랏볯閼볯醼臣몤臣貂臣蒁苣芀臣꺁苣벃菣ꮂ菣랂苣蚃菣隼볯邼볯꾁胣ꖅ諥ꢁ臣ꚁ苣벃菣ꮂ菣覃볯閼볯鎼苣薿ꛨꢁ臣讂苣벃菣ꮂ菣隼볯邼볯ꮁ뻤颭臣ꚁ臣讂胣늩苣벃菣ꮂ菣覃볯閼볯鎼臣膀蟥鮊蛥龜볯閼볯閼臣鲽裦꺁臣膂胣뮔菥꺁苣벃菣袼浩条⁥捳湥覼볯閼볯钼苣ꚇ郧馁苣龁苣꺁苣벃菣隌臣貂臣薃ꃥ袼賦몤菦놠볯銂鳦鞁胣몇諥馆鳧꾁胣鶁臣ꊂ菣袃苣벃菣隼볯邼볯꺁賦몤菦놠臣鎾臣ꚁꓥ薹臣뮔菥ꚇ郧閁苣讂胣늩苣벃菣ꮂ菣覃볯閼볯鎼臣떥뫥ꮁꯩꆾ臣꾁臣覂臣蒁苣蚁臣閁苣ꚁ臣誂胣肸鷩ꮁ臣뎂菣覃賥閁苣龁菦놠苣ꮐ臣膀믤꺁鷩ꮁ臣膀苣벃菣ꮂ菣隼볯邼볯ꮁ賦ꖅ臣貂臣뒠郥ꮁ铧邈臣貂苣ꞁ臣趂臣릊黦꺁迦馆苣ꮐ苣ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯醼胣㲑䐯噉ਾ†臣覂臣讂铦蒖臣릖돦ꮁ뻥ꎁ臣膀鯥鎼볯銼臣몤臣袂臣ꮁ胣骤闦꺁苣벃菣ꮂ菣覃볯閼볯邼臣ꢔ蓦閁苣膀菣莃苣ꞁ단늣臣貂苣芀郥醃菣꾂臣膀觧骮臣떂苣몂臣ꎡ鳦꺁鷧ꢔ臣ꊖ胩鞁臣誁苣膀苣ꆃ菣ꮁ苣誂鋦놽臣貂臣뮔菥貁菣莃菣뎃苣閁苣ꚁꇨ趜볯閼볯銼苣肝铧鞁臣ꊃ菣ꮃ臣뮔菥袼뻤袁臣膀볯閼볯醼볯銂鳦馁苣芀臣꺁菣莃菣뎃苣꾁胣낕臣讂苣벃菣ꮂ菣覃볯閼볯邼臣梧㱡牢ਾ闧ꪁ苣ꎡ鳦ꊂ苣蚃菣ꢁ臣讂臣ꢁ苣꾏菨ꞁ臣讂胣麃菣钃菣낂苣ꮃ苣ꪃ苣ꂃ臣醼臣꺁뷥讅臣뎛볯醼볯꺁볯閼볯邼臣몤臣貂苣芀ꧨꊂ菣뒂菣몂菣ꞁ臣膀귩鮊髧ꪁ菣벃菣뎃苣꺁諥鲞苣龔裦馁苣趏뻥뾂苣ꪃ菣낂菣뾂菣뎃臣뮔菥銂菣莃菣馁苣ꢁ臣蚁菣벃菣麃菣鞃苣뾽铧鞁臣膀藥鮊铧较臣肜裥ꮁ菣벃菣閁苣讂볯隼볯銼볯覼胣节臣趂苣膀苣벃菣ꮂ菣覃볯閼볯鎼볯뎛볯醼볯覼臣袂苣躸臣覂苣讂胣骤臣꺁믤꺁뷥込臣ꊂ菣뒂菣몂菣貁胣邝雦꺁귩鮊髧ꪁ뷥込苣龔裦馁苣龁苣ꮁ뫦馂臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖 ꆬ臣膀곧銼臣꾃菣鞃볯閼볯銼臣膀곧醼臣꾃菣鞃菣莃菣隼볯銼볯꺁蟥鮊苣膀苣벃菣ꮂ菣覃룤꺁觧骮臣ꊃ菣ꮃ臣뮔菥ꮁ菣벃菣馁苣龁苣ꮁ铧辄臣貂苣芀臣龁臣ꎁ臣膀菣벃菣隼볯銼볯꾁苣벃菣ꮂ菣覃觧覜臣芁苣芀臣꺁뗧鲞臣膀苣벃菣ꮂ菣馆鳧隼볯邼볯ꢁ臣ꚁ跥랈臣貂苣龁苣ꮁ蟥鮊臣貂苣袼볯閼볯鎼볯芀臣龁臣ꎁ臣膀菣벃苣꾁胣鮜臣꺁铧较볯閼볯钼苣ꊂ菣袃苣ꂃ볯閼볯銼臣몤臣鎁臣貁臣趁胣膵ꇨ꺁ꇨ趜臣ꊃ菣ꮃ苣覜臣讂铧较臣ꚇ郧邃菣뢂菣뎃苣覜臣讂苣벃菣ꮂ菣馆鳧隼볯邼볯銂뷤邈臣讂臣ꢁ臣ꞁ臣讂胣鎁臣ꚇ郧꾁胣貸鳦꺁뗧鲞臣鞾苣貂苣뺁臣骶臣讂臣ꢁ臣ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鎼胣㲑䐯噉ਾ†곦ꮁ胣莸臣ꒁ臣ꚁ臣肜뗧蒚臣뢁諦貁臣閁苣龁ꃥ袐臣꾁胣뎛볯醼볯ꮁꓧ閁苣讂苣蚁臣膀苣뎃苣뢂苣莃菣莸菣ꪃ菣뾂苣ꊖ胩꺁꟩開裥ꆾ鯩邭ꧦꢙ귧銂鳦馁苣莸菣ꪃ菣뾂菣隼볯鎼볯ꮁ볯뎼볯鶃菣袃苣讻臣ꚁ苣벃菣ꮂ菣隼볯邼볯貁軦骶臣貂苣袼볯閼볯鎼볯芀苣벃菣ꮂ菣隼볯邼볯袏臣ꒂ菣꾂苣Ꞃ菣袃菣ꪃ菣뾂볯閼볯钼臣ꦁ臣覂臣貁胣莸볯閼볯閼臣겂菣ꆃ菣袃菣벃苣袼뻤袁臣膀볯閼볯隼볯銂跥랈臣讂苣蚁臣鞃菣낂菣ꂃ臣貂臣蒁苣芀苣벃菣뎃菣钃菣릂臣膀苣벃菣ꮂ菣覃臣ꊃ菣ꮃ臣袂苣鶼臣覂苣讂臣ꢁ郥颁ꇨ麡苣鲽裦馁苣龁苣膀苣ꪃ苣誃菣꺁菣벃菣뮔菥銂臣꺁ꇨꊝ臣覜臣ꚁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯钼胣㲑䐯噉ਾ†蟥鮊臣貂臣莸臣膀苣벃菣뎃菣钃菣릂苣讹臣袐苣鮁苣龁苣꺁賦몤볯閼볯邼臣ꂊ臣ꚁ胣趽뷧袐苣鮁臣莢闧颠鿥袼뻤袁臣膀볯閼볯馼볯꺁臣膂臣뾂菣ꢃ볯设臣낁胣隼볯鎼볯覼苣覜臣ꚁ臣讂胣붥臣鞁臣꾁胣鶁臣몇諥鞃菣낂菣ꂃ臣膀ꇨ趜臣꒺럥鞁臣馶臣꺛룤ꮁ胩骶臣ꚁ駧龔臣鮁苣龁苣ꮁ룧随苣ꢃ裥꺁菣벃菣麃菣膃菣낂臣꺁迦鮾苣ꮐ苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖 閁苣ꮁ胣ꚃ菣뚂菣ꒂ菣뾂菣閃苣벃苣꾁胣낕臣ꎁ臣ꊽ臣鲃菣ꎂ菣銂胨꺅臣ꖅ苣讂臣膂胣骤臣꺁闧ꪁ臣龁蟥鮊苣ꒂ苣銂鳦馁苣貐臣ꮂ菣覃臣ꦈ铧ꮁ若袁苣貂苣芀苣벃菣ꮂ菣肊ꇨ꺁裥ꢔ臣몟臣蒁臣膀苣벃菣ꮂ菣龩꟦隼볯邼볯꺁裥ꢔ臣袂臣ꚁ胣ꮂ苣뾂菣閁苣龁ꇨ麡臣龔铧ꢁ臩鎽臣邵黦꺁뿨龀臣辏蛥꺁臣膂臣랂苣蚃菣銂迦鮾臣讂臣ꢁ臣몇鷦讂胣㲂牢ਾ諦鎡볯钼臣겪飦誼볯㲊牢ਾ諦鎡볯隼臣겪飦઎⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯隼胣㲑䐯噉ਾ†臣覂臣讂铦蒖臣꾁胣뮔菥꺁諥鲞苣ꊻ胩馁苣龁苣ꮁ胣袅뿨鞁臣袂臣ꪁ苣벃菣ꮂ菣薣뷧貁ꓨ낕胣떼볯ꊼ菣벃菣銂믤鞁臣ꖎ뛧閁苣ꚁ臣讂胣蒐苣벃菣ꮂ菣꺁蛥ꢃ臣뎂菣钃菣벃苣ꢃ臣ꦁ裥ꪁ菣궃苣ꦃ菣ꮁ苣誂胣뮔菥릊黦꺁믨膀臣邈臣芁臣覂苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鞼胣㲑䐯噉ਾ†ꗥ뺁臣蒁藩鞈臣膀鯥鎼볯閼臣몤臣貂臣蒁苣袂臣ꮁ胣肸胩꺁苣벃菣ꮂ菣袼뻤袁臣膀볯颼볯銼볯隼볯邼볯貼볯颼볯钼볯貁臣貂苣꺁볯뎼볯鶃菣袃苣讻臣ꚁ軦骶臣貂臣蒁苣ꢁ臣蚁苣꺁臣芁苣袼볯颼볯閼볯芀臣貂臣貂臣ꊂ菣袃苣ꂃ볯颼볯銼볯隼볯邼볯貼볯颼볯钼臣꾁胣붥臩ꪁ铧较蟥蚐菣궃苣ꦃ菣貁ꃦ趴臣貂臣ꊂ菣袃苣벃菣隼볯邼볯貼볯颼볯颼볯隼볯邼볯貁若袁苣貂臣蒁苣芀臣覂臣膀菣莃菣꾃菣꾂鋧莢苣ꦈ铧馁苣ꢁ臣蚁賦몤苣ꊂ菣袃苣벃菣隼볯邼볯貼볯颼볯颼볯隼볯邼볯ꮁ苣誂룤袁苣鎁臣貁臣趁苣芀臣鞁臣膀苣벃菣ꮂ菣隼볯邼볯ꮁ苣誂ꓦꖟ臣貂臣뮔菥隼볯醼볯꾁胣ꊂ菣袃苣벃菣隼볯邼볯誸臣ꚇ郧鞃菣낂菣ꂃ臣袂臣ꚁ蟥蚐臣貂苣芀苣벃菣ꮂ菣覃볯颼볯颼臣袂臣ꚁ铧较蟥蚐ꧦ붃臣ꦁ铧閁苣讂苣벃菣ꮂ菣薣뷧袼룤ꎀ臣ꊂ菣袃苣ꂃꏨ꺽臣薆臣ꆬ臣ꊂ菣袃苣ꂃꏨ꺽볯隼볯邼볯ꮁ胣鶁臣邵黦貁믨膀臣貂苣袼볯颼볯閼볯芀臣꺁苣蚁臣꺛髧꺁臣膂胣蒐苣벃菣ꮂ菣薣뷧꾁볯ꒁ臣떼볯ꊼ菣벃菣銂賦ꒁ苣蚁臣꺿귦閁苣ꚁ臣讂胣肜뻥꺁苣벃菣ꮂ菣薣뷧隼볯邼볯꾁胣趉뿨鞁臣뮔菥ꚇ郧꺁鯩趩臣芁苣몇諥隼볯醼볯銂뷤邈臣讂臣膂胣ꊂ菣袃苣벃菣隼볯邼볯ꮁꃦ趴臣貂臣ꚇ郧銂臩ꢔ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯颼胣㲑䐯噉ਾ†臣龁臣ꎁ臣膀鯥鎼볯閼臣讧裦隼볯邼볯꾁胣醼臣꺁ꓦꖟ铧较臣뺯臣ꚁꓥ颧臣릊黦銂룤袁苣鎁臣貁臣趁苣芀苣ꆁ苣鎂胣骤臣꺁臣覂臣讂铦꾉臣꾏菨ꞁ臣讂胣设臣낁胣鶁苣麁苣꺁苣벃菣ꮂ菣꾁胣ꆬ臣ꊂ菣袃苣ꂃ臣뮔菥銂믨膀臣讂臣ꢁ臣ꂊ臣ꚁ胣ꪇ뫨貁蟥蚐臣龁铧较苣낍裥馁苣鎁臣节臣誂뻥讂胣ꂊ臣ꚁ胣貵럨銂裥ꊛ臣ꚁ胣醼臣꺁苣벃菣ꮂ菣銂볯ꒁ臣낕臣ꎁ臣许뗦뒁苣벃菣ꮂ菣ꮁ蟥鮊臣膀闧ꪁ苣肜뗧뮔菥銂蟥鮊臣讂苣蚁臣馁苣芀諥袁臣膀菣벃菣覭苣ꦈ铧閁苣讂胣㲂牢ਾ諦鎡볯鞼臣겪飦઎⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯馼胣㲑䐯噉ਾ†臣覂臣讂铦蒖臣꾁胣讖ꓧ閁苣ꚁ臣讂諦鎡臣膀迥벜迩뮂菣袃臣蒵臣벾臣貂苣袂臣ꮁ臩袐臣貂臣蒁臣膀迥벜迩꺁菣벃苣讁苣꺁ꛨ花臣袂苣뮔菥銂跥랈臣趁苣袂臣ꮁ臣ꎁ臣蒁苣芀臣骁胣뎛볯醼볯銂迥ꞅ臣讂臣膀迥벜迩랂苣蚃菣꺁룤设臣讖ꓧ閁苣ꚁ臣讂胣늩迥벜迩隼볯邼볯꾁胣겅鿧꺁苣ꒂ菣꺁苣꺁臣芁苣膀鳦몙飦꺁軥蚐臣鎾臣ꚁꓥꊽ臣貂苣芀ꧨ貏鳧ꆏ臣膀菣뎃苣ꖅ諥銂鳦馁苣骀룥꺁藥ꚭ菣뎃苣랂苣蚃菣隼볯邼볯貼볯馼볯銼苣覜臣讂胣銼臣꺁菣뎃苣랂苣蚃菣꾁胣뎂菣꾂苣벃菣것菣袃볯馼볯隼臣銃菣뢂苣릂菣ꂃ볯馼볯钼볯隼볯邼볯銂믤鞁臣随苣颻臣覂苣ꚁ臣讂胣鶁臣超裥꾁ꓥ鎽뻥ꖝ髧ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯邼胣㲑䐯噉ਾ†곧醼臣覅귥것菣몂苣릂菣ꂃ볯馼볯銼臣鎃菣ꂃ菣릂菣ꪃ菣뾂ꏨ꺽볯馼볯颼苣覜臣ꚁ臣誂胣늩ꏨ꺽臣膀藥ꚭ苣릂菣ꂃ볯馼볯銼臣ꖅ냥閁苣龁藥꺁藥꾷볯馼볯馼苣銼臣꺁藥꾷臣蚈觥馁苣芀곧醼臣覅럨隼볯醼볯꾁胣ꎼ볯꒼苣릂菣ꂃ볯馼볯钼臣随苣颻臣覂苣龁臥ꮁ郥醁苣貂苣芀곧銼臣覅럨隼볯醼볯꾁胣ꖎ鳧ꢃ볯馼볯閼臣릖郥뢁郥醁苣貂苣芀ꧨ鎃菣ꂃ菣릂菣ꪃ菣뾂ꏨ꺽볯馼볯颼臣膀藥骷볯馼볯醼臣몇諥랼뫥銂볥辁臣鮁苣鎁臣ꢁ臣讂胣鞁臣貁臣ꚁ胣覅귥것菣몂苣릂菣ꂃ볯馼볯銼臣궸臣鎃菣ꂃ菣릂菣ꪃ菣뾂ꏨ꺽볯馼볯颼臣袂苣鮸ꇨꢁ룤뒇臣鮁苣袂臣ꮁ臣讂臣膂胣鮸ꇨ閃苣ꮃ苣벃볯馼볯颼苣超뷧鞁臣节觨蒁胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯醼胣㲑䐯噉ਾ†臣龁臣ꎁ臣膀볯ꎼ볯꺒뷥薣뷧隼볯醼볯꾁胣覅귥것菣몂苣릂菣ꂃ볯馼볯銼臣讦苣꺁臣貐臣랂菣뎃苣꺒뷥馁苣鎁臣ꢁ臣讂胣늩볯ꎼ볯薣뷧隼볯醼볯꾁胣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣蒂菣ꊃ菣벃ꏨ꺽苣覜臣讂菣ꪃ菣袃鿥뾝볯馼볯邼臣随苣颻臣覂苣龁蟥蚐苣릂菣ꂃ臣ꖎ뛧閁苣ꚁ臣讂胣鶁臣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣薣뷧꾁胣趇ꛨꪁ铧较蟥蚐ꧦ붃苣覜臣ꚁ臣誂胣뮔菥銂苣ꎃ菣膃菣벃臣讂苣蚁臣趉꣨ꎼ볯꒼ꏨ꺽苣뚈뻥鞁胣鞃菣뎃菣颃菣覃ꏨ꺽볯馼볯鎼苣뾽铧鞁臣뮔菥銂跥랈臣讂苣蚁臣馁苣芀菣ꪃ菣뾂菣ꮁ臣膀菣ꪃ菣袃菣螃苣ꊂ臣ꒂ菣꾂苣邐蟥馁苣ꒂ菣꾂苣Ꞃ菣袃菣ꪃ菣袃ꏨ꺽苣뾽铧馁苣芀ꧨ鞃菣뎃菣ꆃ菣ꎂ苣꾁胣鞃菣뎃菣ꆃ菣ꎂ苣ꢁ跥랈铧ꒂ菣꾂臣銂郥肂鷧놄迥붃臣뾽臣ꢍ臣讞菣ꪃ菣袃菣벃菣隼볯銼볯讁苣鮾뗧閁苣讂胢馴胢閃苣ꮃ菣袼껥鮚臣꾁胣ꦁ裥ꪁ菣ꪃ菣벃볯讁苣ꪁ苣芀ꧨ鞃菣뎃菣궃菣ꮃ볯馼볯閼臣较苣뢂菣낂볯馼볯閼臣躏껥閁苣ꚁ臣誂胣늩菣Ꚃ苣뎃苣ꮁ臣邃菣蚃菣벃볯馼볯鞼臣肝蓨꾏菨ꮁ藩꺽臣貂臣蒁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖 ꚃ菣뚂臣鲃苣뎃볯馼볯馼苣벊臣许臣讂臣膀苣벃菣ꮂ菣궸ꓥꚇ郧薣뷧꾁胣랂菣뎃苣꺒뷥馁苣龁苣ꮁ볯ꎼ볯隼볯醼볯銂뷤開臣鮁苣芀볯ꎼ볯薣뷧隼볯醼볯ꮁ苣ꎁ臣궂菣鞃菣ꎃ菣閁苣龁铧较臣ꆼ볯낼菣궃苣莃苣ꮁ苣ꎁ臣ꚇ郧閁苣膀鋦놽臣龁苣벃菣銂跥Ꞻ臣뢰매蒚臣風賩馁臣辁胣鞃菣뎃菣颃菣覃臣ꊻ胩閁苣ꚁ跥Ꞻ臣낍裥閁苣讂胣鞃菣뎃菣颃菣覃臣趆臣誸뿨꺁苣蚁臣ꪁ苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖 骤臣꺁铦꾉臣膀臣覂臣讂铦蒖苣邈臣芁臣讂臣ꢁ臣ꞁ臣讂胣设臣낁胣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣벃臣ꖎ뛧閁苣讂볯뎼볯鶃菣袃臣邏뻤閁苣ꚁ胣뮔菥ꚇ郧ꊂ菣뒂菣몂菣銂迥벜迩隼볯邼볯ꮁ菣것菣벃菣ꞁ臣讂苣蚁臣鞁臣节觨蒁胣鶁臣ꮃ菣膃菣銂뷤開臣鮁苣龁苣꺁룤ꎀ臣鲃苣뎃苣超뷧馁苣袂臣ꮁ臣ꚁ苣꾉臣芀臣꺁菣벃菣뎃臣颧胣ꪁ铧较볥뾪鏦鲽귧銂郥肂胣ꂊ臣ꚁ胣뮔菥꺁觧뒾苣랼ꫨ馁苣龁苣膀ꓥ辁臣낕臣讂雦閳臣몇諥뮔菥銂뿤ꎭ臣讂苣蚁臣鞁臣节觨蒁胣ꖗ駦蒂ꃥ肉臣ꒁ臣ꚁ臣ꊖ胩薃ꃥ銂铧较臣ꪇ该蒚臣늎볨馁苣鎁臣ꮁ苣誂铧较苣閁苣ꮁ觧뒾믤醁苣袂臣ꮁ臣ꚁ苣꾉臣芀諥袁臣膀ꛨ龯胨꺁뫥馨苣뺁臣몇諥뮔菥ꮁ跥Ꞻ臣낍裥閁苣讂苣蚁臣膀ꧨ貏鳧ꆏ苣Ꞽ볯뎼臣ꖎ뛧鞁臣誁臣ꚁ苣꾉臣芀諥袁臣膀ꋨ馆뷤꺁ꃥ肉苣릉껥馁苣龁苣꺁럨ꊛ룦骮ꏨ꺽臣邏뻤蒂胣늩ꋨ馆뷤ꮁ雩馁苣薃ꃥ꺁觥風蟥鮊铧较臣꺁ꇨ몤臣袂臣ꪁ믤꺁苣鞃苣ꞃ菣貁ꇨ辂苣讂苣蚁臣鞁臣节觨蒁胣㲂牢ਾ諦鎡볯颼臣겪飦㲎牢ਾ諦鎡볯馼臣겪飦઎⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯钼胣㲑䐯噉ਾ†臣覂臣讂铦蒖臣꾁胣讖ꓧ閁苣龁諦鎡臣膀苣벃菣ꢡ鷩ꮁ菣ꦂ菣ꮃ菣뮃菣것菣뎃菣뮃菣벃苣超裥銂룤袁苣龁苣ꮁ裥ꢔ臣貂苣芀ꧨ螃菣뾂臣膀믤꺁菣ꦂ菣ꮃ菣뮃菣것菣뎃菣超裥ꮁ鯦趁迦袁苣鎁臣ꮁ苣誂苣莃菣螃菣袃臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖 뺁臣膀鯥鎼볯鞼苣芏藧馁苣ꢁ胣ꮂ菣覃ꇨꊝ臣螃菣뾂볯设臣낁胣鞼볯邼볯覼臣뢛臣벾臣貂臣膀껥ꢅ臣螃菣뾂藩鞈臣뢛臣벾臣貂臣貾臣ꮂ菣覃볯鞼볯醼臣몤臣貂臣蒁苣芀郥螃菣뾂藩鞈볯设臣낁胣鞼볯邼볯覼臣膀苣벃菣ꢡ鷩ꮁꓧ閁苣ꚁ臣讂볯钼胥꺁菣벃苣隃菣莃苣꺁藩鞈臣膀듧銼볯ꮼ볯꺁菦놠臣ꚬ迥隌臣貂苣芀苣ꆁ苣鎂胣隻臣超裥꾁胣蒐菣벃苣隃菣莃苣袼뻤袁臣膀볯醼볯銼볯꺁룤ꮁ鯦趁뻨뺁苣讂菣벃苣辇苣袂苣醰臣辁臣讂臣ꢁ苣膀苣誂ꓥ辁臣讂臣ꢁ苣꾏菨ꞁ臣讂胣鶈鳦뚊藦ꞁ臣膀ꧨꮂ菣覃볯醼볯醼臣螃菣뾂菣궃菣꾂臣覜臣ꚁ臣ꪁ臣芀믤辂苣ꮁ胣骤裥膀볯ꒁ臣ꦈ铧螃菣뾂菣궃菣꾂臣鶁臣ꮂ菣覃臣ꢡ鷩ꮁ鯦趁뻨뺁苣ꚁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯隼胣㲑䐯噉ਾ†鯥鎼볯颼苣芏藧馁苣ꢁ곧銼臣ꮂ菣覃볯醼볯閼臣몤臣貂臣誁苣膀ꧨꮂ菣覃臣꾁胣뢛臣벾臣貂臣肜뻥꺁菣벃苣隃菣莃苣ꞁ臣讂臣鎁苣꺁鳦낖臣螃菣뾂菣궃菣꾂볯醼볯隼臣醼볯麛胢ꊂ菣鞃菣벃菣鶀臣貂臣蒁苣芀臣龁臣ꎁ臣膀郥ꮂ菣覃볯设臣낁胣鞼볯邼볯覼臣膀ꧨꮂ菣覃臣躸臣覂苣龁菣벃苣隃菣莃苣낕臣鎾臣ꚁ苣莃菣螃菣袃臣貂胣閽鯥节뷤ꢔ臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖 뎛볯醼볯銂迥ꞅ臣讂臣膀볯ꒁ臣螃菣뾂菣궃菣꾂볯设臣낁胣鞼볯邼볯覼臣讧裦貁ꓧ閁苣ꚁ臣讂胣늩菣궃菣꾂臣膀胢ꊂ菣袃苣ꂃ胢肊ꇨ꺁룧辰菣벃苣ꞃ菣ꞁ臣讂胣鶁臣螃菣뾂菣궃菣꾂볯醼볯颼臣螃菣뾂苣ꪃ苣鞼볯邼볯讁苣ꪁ苣膀ꧨꢂ菣ꊂ臣膀跥랈臣貂臣覃菣袃藩鞈苣覜臣膀ꧨ覃菣袃臣膀룧ꮁ닦ꎁ臣肸胩꺁苣궃菣꾂菣麃菣꾂臣ꂊ臣ꚁ胣醼铧ꂴ맥꺁菣벃菣벃苣覜臣讂胣鶁臣螃菣뾂苣ꪃ苣鞼볯邼볯꺁苣莃苣ꮁ닦ꎁ臣뾂菣늂菣袃볯醼볯邼臣超뷧閁苣膀ꧨ螃菣뾂苣ꪃ苣鞼볯邼볯꺁뷤꺽뇦膂迥뎁ꫨ뾁迥誂苣ꊂ苣릂菣馁苣袂臣ꮁ臣ꎁ臣蒁苣芀郥뾂菣늂菣袃볯醼볯邼臣讧裦꾁鯥鎼볯邼臣몤臣貂苣骀苣ꞁ臣ꎁ臣膀臣ꎁ臣肸臣꺁駧꺁菣莃菣銂鯥肂胣Ꞥ臣ꪁ믩ꢂ菣ꊂ臣覂臣讂胣节臣趂苣膀믤꺁꟦邈苣꾏菨ꞁ臣讂胣늩苣벃苣莃菣鞼볯醼볯꾁菣벃苣ꢂ菣ꊂ볯醼볯馼苣ꎭꋧꮁ뷤꺽뇦膂臣讂臣膂臣邏뻤閁苣讂胣閁苣ꮁ胣鶁苣覂臣뾂菣늂菣袃볯醼볯邼臣膀臣覂臣膀귦몢臣鲤鿧閁苣膀귦몢臣趽뷧薃ꃥ銂냥趁蟥馁臣膂臣邏뻤閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯颼胣㲑䐯噉ਾ†鯥鎼볯醼苣芏藧馁苣ꢁ胣ꮂ菣覃ꫨ뾁迥誂迥뎁鯦趁뻨뾁ꏨ꺽볯醼볯邼臣몤臣貂臣蒁苣芀鯥鎼볯醼臣膦苧ꢃ裥꺁详Ꞥ臣뎛볯銼볯ꮁꓧ閁苣ꚁ臣讂胣늩ꏨ꺽볯醼볯邼臣膀菦놠臣낍裥閁苣讂苣벃菣鞼볯銼볯銂賦ꖅ臣讂臣膂臣내闩蒁髩鎖볯醼볯醼苣覜臣ꚁ臣讂胣骤臣꺁菣뎃菣궃菣ꦃ菣袼뻤袁臣膀볯醼볯鎼볯鞼볯銼볯覼臣膀菣ꪃ菣袃菣莃菣鞼볯銼볯蒂菣讃苣ꎼ볯꒼苣궂菣誃菣鞼볯銼볯銂꣦螈苣袂臣ꮁ苣벃菣꺁꟧開苣뚈뻥馁苣芀ꧨ릂苣ꎃ菣벃볯醼볯隼臣膀룤銂胩躁臣讂菣벃苣銂苣궂菣뎃臣讂胣뎛볯銼볯ꮁ臣膀賦ꖅ臣貂臣ꮂ菣覃볯銼볯꺁臣膂臣鞃菣뎃菣颃菣覃볯醼볯閼迥뎁볯ꎼ볯릂苣ꎃ菣벃볯醼볯隼臣超裥꺁详Ꞥ鯥貁ꓧ閁苣ꚁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯馼胣㲑䐯噉ਾ†鯥鎼볯鎼苣芏藧馁苣ꢁ胣ꎼ볯꒼苣궂菣誃菣鞼볯銼볯뢁苣벃菣鞼볯銼볯貁賦ꖅ臣貂苣颧귥貁ꛦꖕ髧ꮁꓧ閁苣ꚁ臣讂胣ꎼ볯꒼苣궂菣誃菣鞼볯銼볯꾁胣늩苣궂菣誃菣銂胩躁臣讂苣蚁臣ꮂ菣覃볯醼볯銼苣겐胩鞁胣ꮂ菣覃볯醼볯銼臣鶿귥閁苣ꚁ臣讂菦놠臣膀볯ꎼ볯릂苣ꎃ菣벃볯醼볯隼臣随苣颻臣覂苣ꚁ臣讂苣벃菣ꮂ菣궸ꓥ鞃菣뮂菣떂菣讃菣袃臣袂臣ꚁ菣뎂菣覃臣貂苣芀苣벃菣ꪃ菣肃菣讁苣ꮂ菣覃볯醼볯銼苣随苣몇臣龁臣뒠郥膀雦龁臣隃菣莃苣꺁苣벃菣뢁臣뢛臣벾臣貁뿥膦臣Ꚑ臣꺁뇦骮臣ꪁ臣貂苣芀雦龁臣隃菣莃苣꺁뷤꺽臣趉臣릂苣ꎃ菣閁苣龁볯ꎼ볯螃菣뾂臣覂裥讂胣ꮂ菣覃臣随苣몇臣꾁胣ꮂ菣覃苣鞃菣뎃菣颃菣覃볯醼볯閼迥뎁볯ꎼ볯릂苣ꎃ菣벃볯醼볯隼苣骀臩馁苣袂臣ꮁ胣뎛볯銼볯ꮁꓧ閁苣讂苣蚁臣鞁臣財苣貂苣芀苣궂菣誃菣鞼볯銼볯꾁苣벃菣鞼볯銼볯꺁迧ꢜ뷤꺽苣ꊃ菣뾂菣鞁臣誁苣膀鯥鎼볯閼臣몤臣袂臣ꮁ胣鮛꟨꺁ꃩ龟볯醼볯颼苣낖臣蒁菣벃苣ꞁ苣莃菣螃菣袃臣讂臣ꢁ臣鮜臣貂苣뒠郥꾁胣鞃菣뎃菣颃菣覃볯醼볯閼臣袂苣ꒂ菣꾂믦銂郥몇臣讂胣鶁臣ꚁ胣閃菣莃菣벃菣ꎂ苣꾂臣ꦁ臣벼臣袂臣ꪁ雦閳臣ꮂ菣覃臣薣뷧⢮鯥鎼볯醼볯讁苣随苣몇臣貂苣芀臣鞁臣膀臣꺁苣벃菣꾁胣ꢅ臣꺁菣벃苣릂菣벃苣貁鿥膂냥辁臣貂臣낖臣ꪁ苣벃菣貁뷤邈臣貂苣뺁臣膀뛧骶髧ꮁ뷤ꢔ臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖 鶁苣蚂臣膀苣벃菣銂껥ꆾ臣鲽裦鞁胣薃ꃥ超뷧꺁臣膂볥鮊髧ꪁ雦閳臣ꦈ铧꾏菨ꞁ臣讂臣蒁臣릂臣膀觥낿臣ꮂ菣覃苣릂菣ꂃ臣ꦈ铧꾁胣薃ꃥ超뷧꺁諥鲞髧ꞁ껥ꆾ臣ꊽ볥銂迦鮾臣讂臣蒁臣鎁臣貁飦붙臣趂臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖 뎛볯銼볯銂迥ꞅ臣讂臣膀苣벃菣ꮂ菣覃ꫨ뾁迥誂ꏨ꺽臣ꦈ铧閁苣讂闧ꪁ苣龩菨꺁菣궃菣꾂鯥貁ꓧ閁苣ꚁ臣讂胣鞃菣뎃菣颃菣覃볯醼볯閼苣ꪃ菣ꊂ볯ꎼ볯鞼볯銼볯꾁胣ꦁ裥ꮁ菣궃苣ꦃ菣閁苣龁苣벃菣ꮂ菣궸ꓥ鞃菣뮂菣떂菣袼볯ꎼ볯覼菣莃菣袼볯ꎼ볯覼볯醼볯邼臣뚈뻥ꮁ苣誂鏦鲽臣貂苣芀볯ꎼ볯鞼볯鎼볯꾁胣릂苣ꎃ菣閁苣龁菣벃苣蒂믤꺁菣벃苣誏臣鞃菣낂菣ꂃ苣鶿껧馁苣ꆃ菣ꪃ菣鞼볯鎼볯銂若袁臣蒁苣芀臣覂臣膀볯ꎼ볯꾁胣钃菣膃菣벃菣벃苣鲽该閁臣讂꣧薀臣ꊃ菣뾂볯醼볯銼苣뚈뻥馁苣芀苣ꆁ苣鎂胣膦뇦ꮁ뿥颁臣隻臣뚈뻥鲃苣뎃귧节藩꺽臣貂뻥讂胣鶁臣袂臣ꪁ럧邈臣ꦈ铧꾁胣ꮂ菣覃ꇨꊝ臣베듧閁苣龁菦놠臣ꊃ菣뾂菣뎃苣蒂苣莃菣螃菣袃臣龁苣꺁苣릂菣ꂃ苣邏뻤馁苣芀戼㹲肊ꇨ隼볯꺁ꫨ躘㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖 閁苣ꪁ苣릔雥ꞁ臣膀菣벃苣꺁ꛨ花臣鲿臣ꚁ蟨ꮺ臣ꊂ菣袃苣벃菣銂뷤邈臣趁苣ꊂ菣袃苣벃菣馆鳧ꪇ该ꦲꏥ龩臣邏뻤閁苣讂胣늩蟨開단늣ꧦ꾁胩뢸臣馆鳧ꪇ该ꦲꏥ龩臣貐꟦꺁雦閳臣讧裦閁苣讂臣膀룤袁苣貂臣芙雩薆臣ꊂ菣袃苣벃菣銂蟨開뷤邈臣讂苣蚁臣讧裦閁苣龁苣뎃菣ꖃ菣蚃苣랂菣誃菣뮃菣붂菣릂臣膦뇦꺁臣貁鳦ꪳ髧膦듧ꞁ臣ꪁ臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖 뺁臣膀鯥鎼볯鞼苣芏藧馁苣ꢁ胣閁苣ꪁ苣릔雥鞼볯邼볯꺁ꧦ붃ꛨꂴ臣뎛꟨蒚臣몤臣貂臣蒁苣芀臣覂臣讂铦蒖볯銼볯醼臣膀菣벃苣벃臣讦鳦馆鳧鞼볯邼볯銂苣궂菣뎃臣讂臣膂臣颫꟨较뫥릂苣ꎃ菣벃볯銼볯銼苣覜臣ꚁ臣讂胣뺁臣肸雦膀臣꺁苣궂菣誃菣鞼볯邼볯銂苣鞃苣ꞃ菣ꢁ臣ꚁ胣颻諥閁苣龁뫥袐臣꺁菣ꊂ菣몂菣銂苣벃菣ꮂ菣覃뷤邈苣릂菣ꂃ臣躸臣讂臣膂胣ꚃ菣뚂臣벽苣꺁蛥龜苣ꚇ郧馁苣鎁臣銂꣨릮臣ꚁ苣꾉臣芀苣궂菣誃菣鞼볯邼볯ꮁ苣ꎁ臣릂苣ꎃ菣閁苣龁蛥龜볯銼볯鎼臣膀臩ꎭ臣ꪂ菣것菣蚃苣뎃苣랂苣蚃菣ꢁ菣궃苣ꦃ菣銂鳦馁苣较苣ꢂ菣覃臣낼볯뾂苣鞃臣뎂菣钃菣벃苣ꞁ臣讂鿥릹苣뎃菣ꖃ菣뾂苣릂菣ꂃ볯銼볯钼臣ꊻ胩閁苣讂胣늩苣뎃菣ꖃ菣뾂볯銼볯钼臣膀苣궂菣뎃臣貂臣馆鳧꺁苣袃菣벃苣膀룤뎁臣馆鳧鞃菣뎃苣벃迥뎁苣벃菣ꮂ菣覃菣ꪃ菣뾂菣鞼볯邼볯꺁苣뎃菣궃菣ꮃ苣馁苣芀蛥龜菣ꪃ菣뾂菣誏臣ꊂ菣袃苣벃菣鞃菣뎃苣벃볯銼볯閼臣膀ꗥ뺁臣辁臣몇諥閁苣龁菣ꪃ菣袃菣螃苣ꊂ臣ꆸ鷩ꮁ跥랈臣讂臣ꢁ臣ꞁ臣膀觥ꮁ雩몤臣龁苣蚁臣낍裥肊ꇨ銂뷤ꢔ臣讂臣ꢁ臣ꞁ臣讂胣늩菣ꪃ菣뾂菣鞼볯邼볯꾁胣ꊂ菣袃苣벃菣鞼볯邼볯ꮁ諥袁臣ꚃ菣뚂臣馆鳧鞼볯邼볯꺁蟥蚐臣貂臣节臣銂蟥鮊臣讂胣ꊂ菣袃苣벃菣꾁룤ꊝ臣낍裥閁苣讂胣馆鳧鞼볯邼볯銂铧邈臣讂臣膂胣馆鳧鞼볯邼볯꺁铧较蟥蚐臣龁苣꺁곧랏賥閁苣龁賦몤苣ꮐ苣芀ꧨꚬ迥隌臣貂臣螌ꓧ꾁苣벃菣ꮂ菣覃菣ꦂ菣麃菣袃臣몇諥閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯钼胣㲑䐯噉ਾ†ꧨ뎂菣钃菣벃苣랂苣蚃菣鞼볯邼볯꾁胣뺁臣膀꣦隺髧ꪁ苣莃菣뮃苣꾂菣벃菣뮃苣ꒂ菣꺁苣蚁臣ꚃ菣뚂菣ꒂ菣뾂菣閃苣벃苣鞼볯邼볯銂鳦鞁臣蒁苣芀ꧨ뎂菣钃菣벃苣랂苣蚃菣鞼볯邼볯꾁胣뺁臣膀铦閉臣랂苣蚃菣鞼볯醼볯銂苣뎃菣궃菣ꮃ迥꾁蛥떔臣ꚁ臣讂胣늩铦閉臣랂苣蚃菣鞼볯醼볯꾁胣馨뫦蒚臣뎂苣뎃迥꾁듧ꎹ臣꾔触蒁苣릂菣ꂃ胣隈臣꾁胣随볥꺁触趪臣龁苣꺁苣것苣莃菣ꮂ菣覃臣떂菣鎃苣鞃菣邃苣肃臣ꦁ裥ꪁ菣莃菣꾃菣꾂軦骶苣馁苣꾂菣뢂菣袃铦閉臣랂苣蚃菣袂苣邈苣芀諥袁臣膀苣閃菣鶃苣袼볯ꚼ볯낼볯뎼볯궨若貁迦鮾臣貂苣讁苣ꖟ苣ꪁ臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖 ꚃ菣뚂臣벽苣꺁蛥龜볯銼볯鎼苣릂苣ꎃ菣벃苣궃菣袃볯銼볯銼臣뾌藥馁苣ꢁ胣馆鳧꾁苣궂菣뎃臣貂胣鶿껧閁苣膀뛧蒁臣銎蟥閁苣讂胣ꆬ臣膀胢閃苣袃菣隃菣릂胢薆臣趽뷧馁苣ꚃ菣뚂菣ꒂ菣뾂菣閃苣벃苣鞼볯邼볯銂菣벃苣貁鏦鲽臣讂胣늩菣벃苣뮃苣뎃苣벃菣Ꞃ菣릂볯銼볯馼臣꾔触蒁苣릂菣ꂃ볯銼볯邼臣醇苣꾔触蚁臣膂臣螌ꓧ銂鳦鶈臣財臣芀臣讁臣ꪁ臣覂胣늩菣벃苣뮃苣뎃苣벃菣Ꞃ菣릂볯銼볯馼臣궸ꃦ꾁胣뾂菣膃苣꾂菣벃菣ꮁ苣讂꟦薀臣ꊂ菣袃苣벃菣꺁觥鲽臣芁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖 붥臩ꪁ菣벃苣뮃苣뎃苣벃菣Ꞃ菣릂臣肸뻤꾁胣뎛볯銼볯ꮁꓧ閁苣讂胣늩菣벃苣뮃苣뎃苣벃菣Ꞃ菣릂臣궸ꃦ꾁胣貾臣낿臣讂雦閳臣ꚇ郧閁苣讂ꓥ辁臣讦鳦떂菣趃苣ꮃ铧较볯銼볯鎼苣ꚃ菣뚂臣몤臣鎁臣ꞁ꟦邈臣貂苣芀鳦鶈臣膀뻤袁臣膀볤뺤臣ꒂ菣뎃菣蒂胣閪铧ꖗ臣ꒂ菣뎃菣蒂胣ꎭ꿧꺁苣馃菣袃苣膀蟥蚐臣뾂苣鞃귧꺁苣蚁臣뮔菥꺁蟥蚐볯銼볯鎼臣떂菣뢂苣꾂菣ꢂ菣ꊂ臣超뷧閁苣讂胣ꚃ菣뚂臣膀苣莃菣릂苣ꪃ菣뎃臣袂臣ꚁꗥ뾁臣뮔菥袼뻤袁臣膀볯銼볯鎼볯銂臩麊臣讂胣붥臣꺁铧较臣颭鳥鞁臣蒁ꃥ袐胣ꚃ菣뚂臣ꊟ跥鲃苣뎃볯銼볯钼苣벊臣ꚁ胣隻臣ꚇ郧銂ꇨ몤臣鮁苣鎁臣貁臣趁苣芀菣벃苣貁铧较볯銼볯鎼苣뢁諦鞁臣ꢁ臣膀臣꺁铧较臣벼臣鲀菣벃菣鶀苣覜臣ꚁ胣肸胩꺁蟥蚐苣邏ꓧ馁苣ꎻ鯦ꦉ臣龔裦ꮁ臣꺁铧较臣뾽铧閁苣讂胣鶁臣ꚃ菣뚂臣膀臩麊臣貂臣꺨ꇩ讁苣뮔菥銂臩麊臣讂臣ꢁ苣馶뛧ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鞼胣㲑䐯噉ਾ†ꗥ뾁臣뮔菥꾁苣벃菣鲃苣뎃볯銼볯鞼臣뾽铧ꮁ苣誂苣벃菣馁苣鎁臣貁臣趁苣芀臣鞁臣膀臣꺁菣벃苣뮃苣뎃苣벃菣Ꞃ菣릂臣膀苣벃菣閁苣ꚁ臣讂臩麊볯銼볯颼苣몤臣芀菣鎃苣벃苣ꞃ菣뮃菣뾂菣鞼볯醼볯꾁觥뮔鷩ꮁ裦讂臣膂臣节臣ꞁ臣誂胣誃菣늂菣랂菣뎃菣鲃苣뎃볯銼볯隼뷯꾁룤趽臣뮈苣龁苣꺁苣꺁臣芁苣芀臣꺁雦閳臣袂苣낁胣ꚃ菣뚂臣膀뷥覂蟨ꮺ臣릉鳦꺁苣릂苣麃苣몂臣龁ꛨ花苣鲽苣龁苣膀꟦薀臣ꊂ菣袃苣벃菣銂ꓦꊴ臣讂臣ꢁ臣ꞁ臣讂胣鎁臣릖돦ꮁ苣貂臣膀诧릉臣뢊ꇨ蒚觥鲽듦開臣膀诧릉臣ꊂ菣袃苣벃菣꺁뷤邈苣莿臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖 鶁臣袂臣ꪁ꟦薀臣ꊂ菣袃苣벃菣꺁뷤邈臣膀뷤邈菣궃苣릂臣誁臣讂觥鲽胨꺁뷥늉苣ꚃ菣뚂臣躸臣讂臩鶼髧ꊂ菣뒂菣몂菣肊ꇨꮁ뻤颭臣ꚁ臣讂胣鎁臣ꞁ胣뎛볯銼볯銂迥ꞅ臣讂臣膀鯥鎼볯鞼臣뎂菣钃菣벃苣랂苣蚃菣ꮁ臣龮ꇨ閁苣讂苣鞃菣놂菣랂菣뎃臣붂菣袃苣Ꞃ苣뮃菣ꒂ苣Ꚃ菣꺁뻤貁ꓧ閁苣ꚁ臣讂胣늩苣閃菣Ꚃ苣ꊂ菣것苣ꊂ苣袃볯銼볯邼臣膀껥財臣趁苣뮔菥ꚇ郧꺁臩鶼髧鞃菣ꮃ볯銼볯醼臣膀觧骮臣뮔菥ꮁ臩袐臣鮁苣蚃菣麃蟥蚐臣銂若袁臣蒁苣芀臣꺁臩鶼髧鞃菣ꮃ臣膀雦龁臣꺨ꇩ袼뇥覼臣龔裦꺁臣膂臣몁볤蒚苣ꮃ苣ꪃ苣ꂃ菣뎂苣ꮁ苣ꎁ臣ꦈ铧閁苣讂胣몁볤蒚苣ꮃ苣ꪃ苣ꂃ臣馨뫦蒚臣蚃苣릂菣銂듧讻臣讂臣膀뻤袁臣膀臣꺁裥躇臣誁臣ꚁ鳦낖臣ꚇ郧貁諥袁苣貂臣蒁苣鲀臩鶼髧ꊂ菣뒂菣몂菣鶀볯辽뷯芽뷯銽뷯鞑臣芁苣芀裦蒁臣膀臩鶼귥꺁菣궃苣ꦃ菣뎃苣꺁裥躇臣ꦈ铧閁苣鞾胣鶁臣ꚁ胣鎁臣릂臣膀胢몁볤邭菣궃苣ꦃ菣뎃苣鶀臣財郥ꖁ臣覂苣龁볯辽뷯膽臣袂苣肸裨蒚臣钠ꧧ銂迥ꞅ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯馼胣㲑䐯噉ਾ†觥風臩鶼髧ꊂ菣뒂菣몂菣꺁苣ꊂ臣膀臣龁胣낖臣ꞁꗥꦁ臣뮔菥銂뷤邈臣讂髩ꮁ胣ꚃ菣뚂臣뢁諦鞼볯銼볯銂뷤ꢔ臣讂臣ꢁ臣ꞁ臣讂胣늩臩鶼髧ꊂ菣뒂菣몂菣꺁苣ꊂ臣몇諥꾁胣뾂菣膃苣꾂菣벃菣螃苣릂菣것苣ꮁꇨ몤臣讂臣膂臣ꚃ菣뚂苣뎃苣벃菣Ꞃ菣릂菣뢂菣벃菣鞼볯銼볯ꮁ믨膀臣貂苣膀臩螈臣낖臣蒁铧较苣ꮐ苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖 趆臣뎛볯銼볯ꮁ裦讂臣膀菣벃苣貁ꗥ뾁臣뢁諦銂駧讦臣讂臣膀迥醁믤醁菣뾂菣鞼볯醼볯銂諦馁臣ꢁ臣ꞁ臣讂胣鎁苣ꮁ苣誂胣ꚃ菣뚂臣袂苣꾔触蒁臣膦뇦閁苣讂臣ꢁ苣ꮁ迥醁믤醁苣貂苣芀臣龁胣ꊂ菣袃苣벃菣鞼볯邼볯銂迥醁藥貂苣隻臣薣뷧袼뻤袁臣膀룤낿臣龁苣벃菣ꮂ菣薣뷧覼臣ꚃ菣뚂臣ꦈ铧ꞁ臣讂苣蚁臣膀苣벃菣ꮂ菣覃볯銼볯鞼臣꾁胣肸胩꺁铧较蟥蚐臣ꂊ臣ꚁ菣ꪃ菣뾂볯銼볯閼臣뮔菥銂蟥鮊臣鮁苣螌ꓧ貁苣뎃菣ꖃ菣뾂苣릂菣ꂃ볯銼볯钼볯뎛볯銼볯覼臣袂苣ꪁ臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖 鞁臣貁臣ꚁ胣ꚃ菣뚂臣ꖈ胣ꮁ裥ꢔ臣讂臣ꢁ臣ꞁ臣讂胣螤鯩ꪁ胣ꪇ裥꺁郥趉苣風藥馁苣袂臣ꮁ苣릂苣麃苣몂臣貂臣뮔菥銂뷤邈臣讂苣릂菣ꂃ臣閁苣ꪁ苣릔雥ꮁ苣ꎁ臣邏뻤閁苣讂臣ꢁ臣膀뷥궥胨ꮁ臣躘苣讁臣趂臣芀ꓥ辁臣뮔菥꺁裥ꢔ臣膀郥颧臣趇ꛨꪁ胥Ꞁ賥ꮁ냥辁臣ꢁ臣ꞁ臣讂苣벃菣ꮂ菣覃臣趇ꛨꪁ뗧袐臣ꖀꓥ開苣节臣覂臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖 节臣趂苣膀ꓥ辁臣隻臣뾂苣鞃臣궸ꃦ肊ꇨ貁铧较臣讧꿧ꮁ뷤ꢔ臣貂苣鎁臣貁臣趁苣芀뻤袁臣膀믤꺁鷩몁볤蒚諦鎡臣ꦁ臣讂臣节鿧貂臣蒁胣肜苦꺁ꃥ袐胣蒐铧较臣뢁諦꾁触開臣ꢔ蓦閁苣讂胣閁苣ꮁ胣隻臣ꚃ菣뚂菣ꒂ菣뾂菣閃苣벃苣龩꟦貁迦鮾臣貂뻥讂胣ꂊ臣ꚁ胣겜駧躘臣膀꣦隺臣뎂菣钃菣벃苣랂苣蚃菣꺁苣蚁臣膀蟨開단늣ꧦꞁ蓧蒁鋧莢臣龮ꇨ閁苣讂臣ꢁ苣ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鎼胣㲑䐯噉ਾ†鯦ꪁ苣릔觨꺁鏦鲽臣膀胥몺臣떉胩Ꞁ臣趇ꛨꪁꇨ뺏臣馂臣讂胣鶁臣ꚁ胣뢊ꇨ뚮臣袂苣讀胣꺁觥ꂀ臣讀胣꺁諨鎡껥覭臣ꊂ菣袃苣벃菣鲀苣ꪃ菣몂胢銂迦鮾臣讂髩ꮁ蟩膦臣ꆾ胥銂釥馁苣讁苣鞁苣ꪁ臣ꢁ胨袁苣貂苣芀戼㹲肊ꇨ隼볯꺁ꫨ躘戼㹲肊ꇨ隼볯꺁ꫨ躘㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖 誸뿨鞁臣ꊂ菣袃苣ꂃ藩鞈臣몟鳦꾁胣芦闧뎛臣ꊽ藦ꞁ鯥鎼볯邼臣몤臣貂臣蒁苣芀臣꺁藩鞈臣膀铧较苣랂菣뎃苣鲤鿧馁苣龁苣꺁볯ꎼ볯뮂菣떂菣鞼볯邼볯銂鳦馁苣芀諥袁臣膀ꓦꖟ铧较苣ꚇ郧馁苣龁苣꺁铧较蟥蚐苣ꮃ苣ꪃ苣ꂃ臣芁臣ꚁ苣벃菣隌臣貂臣节臣ꮁ臣蒁臣꺁胣ꊂ菣袃苣벃菣鞼볯邼볯꺁ꫨ뾁迥誂苣財臣龁苣ꮁ胣ꊂ菣袃苣벃菣궪臣벾臣뮂菣떂菣鞼볯邼볯貁迦鮾臣貂苣芀ꧨꎼ볯꒼苣뎃苣벃볯钼볯銼臣늩苣벃菣ꮂ菣覃ꫨ뾁뻨뾁苣뎃苣벃볯钼볯鎼臣ꆸ雦꾁胣鲤鿧鞁臣뮔菥꺁蟥蚐臣龁苣ꮁꓨ醛臣袨껧붃諥銂룤袁苣ꊂ菣袃苣벃菣궸ꓥꚇ郧ꚃ菣莃菣袼볯ꎼ볯覼볯钼볯钼臣ꖎ뛧閁苣ꚁ臣讂胣ꂊ臣ꚁ胣ꆃ菣ꪃ菣ꚃ菣莃菣鞼볯邼볯貁胣뮔菥蒂胣鲤鿧鞁臣螃菣뾂苣膀菣궃苣ꦃ菣ꪁ臣銂뿤颭臣ꚁ臣辁臣膂臣ꢔ蓦閁苣ꚁ臣讂胣ꆼ볯낼볯钼볯钼臣ꖎ뛧閁苣ꚁ臣讂臣꾁胣薆菩꺁菣ꪃ菣袃菣벃菣讁苣鮾뗧閁苣讂菣ꪃ菣袃菣螃苣ꊂ臣肜뗧蒚臣馆鳧鞼볯邼볯銂跥랈臣讂臣膂臣鞃菣뎃菣颃菣覃볯钼볯隼臣芁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖 閁苣ꪁ苣릔雥ꞁ臣膀诧릉臣肸胩꺁苣벃菣ꮂ菣覃볯钼볯颼臣ꊂ菣袃苣벃菣뮃菣벃菣벃볯钼볯鎼臣뾌藥閁苣讂臣ꢁ臣袂苣膀苣벃菣ꮂ菣궸ꓥ鞃菣뮂菣떂菣鞼볯邼볯꺁诧릉臣뎂菣袃菣벃菣貁臣閁苣讂胣견볯꺁뻤꾁胣뎛볯銼苣뎛볯鎼볯ꮁꓧ閁苣讂苣꺁臣芁臣ꚁ胣趇臣袐苣鮁臣膀裦蒁臣鞢ꓥ馁苣뮔菥꺁諥鲞苣躸臣讂臣膂臣麃菣蚃苣鞃菣뮃苣벃菣ꮂ菣覃臣뾽铧銂迦鮾臣讂胣ꦁ裥ꪁꓨ붣苣벃菣ꮂ菣覃臣膀鯥鎼볯銼臣鞼볯醼볯ꞁꓧ閁苣龁苣꺁臣芁臣ꚁ胣릊黦銂铧颁臣鮁苣龁苣ꮁ臣꺁苣蚁臣ꮂ菣ꦃꏨ꺽苣趓뷤馁苣讁臣ꊖ臣ꚁ臣螌ꓧ貁룤뒁鷩ꮁ꣨醁苣貂臣蒁苣芀믤뒁臣ꊝ臣꾁胣鶁臣릊黦銂铧颁臣鮁苣龁苣꺁苣벃菣ꮂ菣薣뷧꺁鏦鲽臣螌ꓧ貁꣨醁苣貂臣蒁苣芀鯥鎼볯醼苣芏藧馁苣ꢁ胣蒵臣袐苣鮁臣릊黦銂铧颁臣鮁苣龁苣꺁菣钃菣ꎂ苣ꞃ菣ꮂ菣覃臣趓뷤꺁뻤貁ꓧ閁苣ꚁ臣讂胣ꊂ菣袃苣ꂃ苣릂菣ꂃ臣膀臣讂苣벃菣꺁ꓦꖟ铧较迥꾁뿤颭铧较苣覜臣ꚁ臣讂胣견볯꺁苣蚃菣鞃臣膀菣钃菣ꎂ苣ꞃ菣뮃菣벃菣ꮁ臣讂臣膂胣ꊂ菣袃苣ꂃ苣릂菣ꂃ臣趓뷤銂ꓥ뒛臣讂苣벃菣銂鳦馁苣ꪃ菣蚃苣랂菣뎃苣벃菣鞼볯醼볯銂賦ꖅ臣讂臣ꢁ臣芁苣芀뛧蒁臣膀곧醼臣ꊂ菣袃苣벃菣鞼볯醼볯貁苣벃菣ꮂ菣覃ꫨ뾁뻨뾁苣뎃苣벃볯钼볯鎼臣뾌藥閁苣膀臣꺁苣벃菣鞼볯醼볯꺁賦몤臣鎾臣ꚁ铧较臣견볯꺁諥鲞臣躸臣覂苣讂볯ꚬ迥鞼볯醼볯芏藧覼胣骶臣ꚁ胣ꪃ菣蚃苣랂菣뎃苣벃菣貁蛥뎁賦ꖅ臣貂볯ꚬ迥鞼볯醼볯覼胣ꆬ臣膀곧銼臣ꊂ菣袃苣벃菣鞼볯醼볯貁賦ꖅ臣貂胣设臣낁胣뮔菥ꮁ菣궂苣袃菣莃苣벃苣銂藩꺽臣讂臣蒁臣견볯꺁諥鲞臣躸臣覂苣讂볯ꚬ迥鞼볯醼볯覼胣ꆬ臣膀蛥뎁菣钃菣ꎂ苣ꞃ菣ꮂ菣覃볯钼볯馼臣뾌藥閁苣膀臣꺁뻥膀곧鎼臣ꊂ菣袃苣벃菣鞼볯銼볯貁賦ꖅ臣貂臣膀臣覂臣讂諥鲞臣뮔菥鞼볯銼볯ꮁ룤袁苣貂苣芀鯥鎼볯醼臣鞃菣뮂苣꾁胣肉鳦꺁蟥鮊铧较臣ꊽ裦꺁臣膂胣膦뇦ꮁ뻥ꎁ臣낹苣钿臣財苣貂苣芀臣꺁雦閳臣袂苣낁胣醼臣꺁諥鲞臣醁苣覜臣讂苣벃菣ꮂ菣覃臣覂뗧뾁郥辂臣꺁諥鲞苣鲽裦馁苣龁苣膀鿦龻胦銂賦ꎁ臣誸뿨鞁臣薣뷧貁뷤ꢔ臣貂苣芀臣覂臣膀迦鮾臣貂苣ꚃ菣뚂菣ꒂ菣뾂菣閃苣벃苣꾁胣蒵臣袐苣鮁臣릊黦銂뷤邈臣讂룤ꮁ臣蒁臣膀苣뎃菣ꮃ臣릊黦蒚臣芁苣芀苣ꆁ苣鎂胣骤臣꺁ꓥ뒛苣財臣鎁臣貁臣趁苣芀뻤袁臣膀裥꺁껥붖뻤ꮁ臣蒁臣꾁胣ꪃ菣蚃苣랂菣뎃苣벃菣꾁볯麛臣醁賦ꖅ臣貂胣肸胩꺁苣벃菣ꮂ菣覃臣鶁臣ꪃ菣蚃苣랂菣뎃苣벃菣ꮁ뛧蒁臣뾌藥閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯隼胣㲑䐯噉ਾ†鯥鎼볯鎼苣芏藧馁苣ꢁ胣ꊂ菣袃苣ꂃ苣릂菣ꂃ臣薆菩蚃苣袃臣龁苣꺁胣ꖈ臣ꊂ菣袃苣벃菣鞼볯鎼볯貁ꓧ閁苣ꚁ臣讂胣肸臣肸臣꺁苣벃菣ꮂ菣랂苣蚃菣ꮁ臣骤臣꺁蛥ꢃ菣릂菣ꮃ菣膃菣貁蛥ꢃ볯꾼볯ꮁ铧辄臣貂臣蒁苣芀臣꺁菣릂菣꾁胣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣벃臣ꢔ蓦閁苣龁뿧뎨꣨麪臣꺁胣릉裥ꪁ雩낕釥몇臣ꮁ苣誂苣꾂苣릂臣貂苣芀臣꺁菣벃菣뎃臣膀苣벃菣ꮂ菣薣뷧꺁믤颧臣芁苣膀뻤袁臣膀戼㹲鞃菣뎃菣颃菣覃臣開뷤뚊藦銂裥궖臣讂臣膂臣蚃苣袃菣뾂菣뎃臣鞃菣뎃菣ꊂ苣袃臣鮼戼㹲躃苣ꮃ臣꾂菣벃菣뎃苣꺁臣膂胣誏臣鞃菣뎃菣颃菣覃臣趓뷤貁铦꾉臣貂苣袂臣ꪁ菣몂菣超裥꺁臣膂胣鞃菣뎃菣颃菣覃臣趓뷤ꚇ郧銂ꇨ蚁菣릂菣醃苣벃菣꺁菣ꪃ菣袃苣Ꚃ菣袼뻤袁臣膀藥ꚁ臣銻臣鞃菣뎃菣覼臣鮼戼㹲鞃菣뎃菣颃菣覃臣趓뷤꺁鳦릊胦銂ꓧ馁臣膂胣貾臣蚈黦꺁臣膂臣蚃苣袃菣뾂菣뎃臣鞃菣뎃菣閁苣讂臣ꢁ볯㲛牢ਾ臣ꮐ臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖 뎛볯鎼볯銂迥ꞅ臣讂臣膀菣릂菣醃苣벃菣鞼볯鎼볯꺁菣ꪃ菣袃苣Ꚃ菣ꮁ諥袁胣芏胨ꮁ臣讂꟦薀臣薆菩螃菣뾂苣覜臣讂菣릂菣뮃苣Ꚃ菣鞃菣袃볯钼볯閼臣讦鳦貁ꓧ閁苣ꚁ臣讂胣鶁臣蚃苣袃菣뾂菣뎃볯钼볯鞼臣膀臣꺁苣ꆃ菣랂苣蚃菣ꮁ귥ꢜ臣ꚁ臣讂臣节鿧貂臣蒁뷤覂臣꺁闥財苣늉苣몇臣ꪇ该蒚迥꾁룤躰髧ꪁ雦閳臣袂臣ꚁ뻥ꞁꫨ뮟臣讂臣ꢁ臣ꞁ臣讂胣閁苣ꪁ苣릔雥꾁胣ꊂ菣袃苣ꂃꏨ꺽臣鞃菣낂菣ꂃ臣貂胣늼볯궼菣ꊃ菣벃臣베듧閁苣ꚁ臣讂苣閃菣Ꚃ苣ꊂ菣ꮃ菣膃菣꺁뷤ꢔ苣骀臣ꚁ껥財臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖 节臣趂苣膀觥風菣벃菣뎃臣ꊂ菣鞃菣벃菣閁苣龁苣膀ꓥ뒛臣貂臣誂臣讂臣ꢁ臣膀ꓥ辁臣릔雥貁뫤뎃臣貂뻥讂胣骤臣꺁菣릂菣꾁껥鮚臣꾁裥邙臣貂臣蒁胣鎁臣릖돦ꮁ苣貂臣膀苣ꆃ菣薣뷧꺁鏦鲽臣膀賦ꖅ臣貂苣ꮂ菣覃臣鎾臣ꚁꓥ뒛臣貂뻥讂胣㲂牢ਾ諦鎡볯鎼臣겪飦㲎牢ਾ諦鎡볯钼臣겪飦઎⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯馼胣㲑䐯噉ਾ†臣覂臣讂铦蒖臣꾁胣몇諥馆鳧꺁ꏨꊝ臣뎟ꏥꆃ菣뮂菣뢂苣風賩馁苣龁苣ꮁꏧ鞰蓦鞏胦鞃菣뎃菣ꆃ菣ꎂ苣邝雦貁뷤ꢔ臣貂苣芀苣벃菣ꮂ菣薣뷧꾁胣馆鳧꺁藥ꊝ苣蚦臣膣냦것苣벃菣꺁藩鞈苣膀裦蒁臣膀뻤袁臣膀ꏧ鞰髧龄迥Ꞁ臣芁苣馆鳧궸ꓥꢃ臣袂臣ꪁ胣膣냦꾸臣覂臣讂ꏧ鞰꣨늌ꏨ꺽苣ꮐ苣袂臣ꮁ铦覤臣貂苣芀ꧨꊂ菣袃苣ꂃꏨ꺽臣꾁臣覂臣貾臣趆铧馁苣龁苣꺁鿩낣菣莃苣벃苣銂賩뎟臣趁苣붃諥貁룤袁苣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 閁苣ꪁ苣릔雥ꞁ臣膀苣벃菣ꮂ菣薣뷧꾁胣麃苣꾂菣閃苣뎃ꏨ꺽苣ꊖ胩꺁賩뎟諦鎡苣薣若馁苣袂臣ꮁ臩鎽臣覤鯦閁苣讂胣馆鳧銂鋦놽臣讂臣趁胣ꢑ鯥꺁鿩낒ꋥ讁胣鶁臣뮔菥ꮁ雩芿臣讂菣莃苣벃苣꺁臣骁苣讁苣늌鿩馁苣龩볤貁룤袁苣貂苣芀臣꺁菣ꪃ菣袃菣螃苣ꊂ迥꾁菣ꎂ菣ꂃ臣膀菣벃菣ꆃ菣ꎂ苣ꢁ郥颁苣蚁臣膀ꏧ鞰蓦鞏胦銂鳦馁苣袂臣ꮁ觥ꚇ郧閁苣ꚁ臣讂胣몇諥馆鳧꺁ꏨꊝ藥鎽胣隈臣꾁ꏧ鞰蓦鞏胦꾸臣늌鿩貁臣閁苣讂胣늌鿩閁苣龁鿩낣臣膀苣벃菣隌臣貂臣ꊽ볥ꞁ蟥鮊蛥龜臣辣鷩ꮁ뿤膌臣貂苣芀臣꺁苣벃菣隌臣膀ꗥ뺁臣辁臣膀ꯩꚺ臣螃苣뾂菣趆迧Ꞁ臣芁苣ꊽ볥ꞁ臣讂胣鶁臣늌鿩閁苣龁鿩낣臣馆鳧ꮁ雩芿臣讂胣뢰매蒚臣뎟ꏥ늌鿩銂迦鮾臣讂胣ꆬ臣膀蛥龔ꏨ꺽臣膀苣벃菣隌臣貂臣뎟ꏥ銂苣궂菣뎃臣膀臣꺁菦놠苣ꦾ迥隌臣讂臣膂臣邏뻤閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯醼胣㲑䐯噉ਾ†鯥鎼볯閼苣芏藧馁苣ꢁ胣誸뿨鞁臣讧裦膀臣뺁苣膀铧较볯隼볯銼臣ꎼ볯꒼苣뎃苣벃볯隼볯鎼臣袂苣鲤鿧閁苣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣鞼볯邼볯ꮁ믨膀臣貂苣ꢁ臣蚁꟦邈苣ꮐ苣閁苣ꪁ苣릔雥鞼볯邼볯貁胣芦闧ꊽ볥ꮁ臣몤臣貂臣蒁苣芀ꧨꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣鞼볯邼볯꾁胣붥臣鞁臣꾁ꯩ龀볯ꆼ볯ꊼ볯뎼볯뮙賩蚕꣦覼苣뎃苣벃菣Ꞃ菣릂臣ꆃ菣ꪃ菣讁苣ꪁ苣ꆃ菣ꪃ菣鞼볯邼볯ꮁ铧较苣베듧馁苣芀臣龁胣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣鞼볯邼볯꾁胣馆鳧꺁ꏨꮁ꣨늌苣馁苣龁苣꺁ꏧ鞰꣨늌菣莃菣鞼볯醼볯ꮁ諥袁胣鞃菣뎃菣颃菣覃볯隼볯隼볯膦뇦ꮁ뿥颁臣ꒂ菣릂苣뎃菣뮔菥銂迦鮾臣讂臣膂胣閃菣ꮂ菣벃蛥龜볯隼볯鞼苣낍裥馁苣龁苣꺁苣꺁볯꺁鏦鲽苣뎂菣袃菣벃菣馁苣袂臣ꮁ臣ꎁ臣蒁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 閁苣ꪁ苣릔雥ꞁ臣膀苣ꆃ菣ꢷ裦鞼볯邼볯꾁胣ꆼ볯낼菣궃苣莃苣鞼볯邼볯꺁裥ꆾ룤ꞁ볯ꆼ볯ꊼ볯뎼菣릂볯隼볯醼뗧놔臣ꆃ菣ꪃ菣鞼볯邼볯ꮁ苣뎃苣벃菣Ꞃ菣릂軦骶臣貂臣蒁苣떂苣뎃菣膃菣鞃볯隼볯邼苣馂臣ꚁ臣讂胣늩苣Ꚃ菣覃菣莃菣鞼볯醼볯꾁胣馨뫦蒚뷥込臣馁苣鎁臣节胣隈臣꾁냥ꢔ뷥込臣馁苣鎁臣节臣趁胣设臣낁胣떂苣뎃菣麃苣꾂菣閃苣뎃볯隼볯鎼臣覂臣ꊂ菣궃苣ꖅ諥鞼볯醼볯銂迥鞾臣讂볯뎼볯鞃菣뮂菣떂苣馂臣讂臣ꢁ臣ꞁ臣讂胣节臣肸臣꺁雦閳臣鞁臣膀菣莃菣꺁ꓨ醛臣ꮁ볤ꎁ臣袼菣벃苣꺁돦螉볯膀苣Ꚃ菣覃菣莃菣鞼볯醼볯꺁ꧦ붃苣膀ꗥ뺁臣辁臣肜藥꾫臣ꎼ볯꾼볯讞鯩趩鯥꾷菣莃菣銂若袁苣ꆼ볯낼菣莃菣鞼볯邼볯ꮁ뗧뾁뻨肂臣ꢁ臣ꞁ臣讂胣겜駧躘臣蒯鯥薆臣늩뷥馁苣隻臣骤臣꺁꣧麡臣ꢷ裦銂迦鮾臣趁苣鎁臣꾁껥鎘臣躘駧ꞁ臣趂臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 떂苣뎃菣膃菣鞃볯隼볯邼臣膀苣誃菣낂藥鮊볯隼볯銼苣뺯뿥馁苣螃苣뾂菣ꊽ볥뢁ꓥ鮏臣膀臣貂苣ꆃ菣ꪃ菣鞼볯邼볯ꮁꃦ趴臣讂臣膂臣ꊻ胩馁苣芀臣꺁苣蚁臣風賩鞃菣뮂苣꾁胣ꮂ菣ꦃꏨ꺽룤꺁菣뾂菣袼鯥몤臣骁볯銂諦馁臣ꢁ臣袂臣ꚁ뷤開臣鮁苣鎁臣貁臣趁苣芀ꧨ鲃苣뎃臣ꆼ볯낼菣궃苣莃苣鞼볯邼볯꺁裥ꆾ룤ꮁ臣讂臣膀臣蚁臣ꪁ臣貂臣膀蛥龜苣꺒苣ꢁ臣ꮁ껥ꪳ髧ꮁ蟨開賥閁苣讂臣ꢁ臣ꞁ臣讂胣風賩閁苣龁菣벃苣꾁胣ꆃ菣ꪃ菣鞼볯邼볯ꮁꃦ趴臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 뎛볯鎼볯銂迥ꞅ臣讂臣膀苣ꆃ菣ꢷ裦꾁胣붥臣鞁臣꾁胣鞃菣뎃苣벃ꏨ꺽볯隼볯隼볯鞃菣뎃菣ꆃ菣ꎂ苣鞼볯醼볯ꮁ铧较苣낍裥馁苣꺁臣뾽铧閁苣讂菣ꪃ菣袃菣莃菣銂鳦馁苣覼臣膣냦風賩鞃菣뎃菣颃菣覃볯隼볯隼볯鞃菣뎃菣ꆃ菣ꎂ苣鞼볯醼볯꺁ꏨꊝ臣薃ꃥ銂跥랈臣讂臣ꮁ뷤ꢔ臣貂苣覼臣銂若袁臣蒁苣芀鯥鎼볯鞼苣芏藧馁苣ꢁ胣閃苣袃菣螃苣ꊂ볯隼볯鞼臣辣鷩ꮁ뷥邈臣貂臣膣냦꾸볯隼볯颼臣몇諥设臣몤臣貂臣蒁苣芀臣꺁ꏧ鞰룥꾁鯥鎼볯隼臣風賩颃菣覃볯隼볯隼臣袂臣ꚁ꣨늌臣貂苣芀꣨늌臣貂臣薃ꃥ꾁胣뒠触蒂韦颻苣芙雩꺁菣벃苣銂郥뾁胣뒠触꺁菣벃苣꾁苣벃菣벃菣ꖅ諥ꮁ苣誂胣隈臣꾁胣Ꞽ볯뎼苣貐꟦꺁苣꺁臣袂臣ꪁ胣颻뇥꺁뷤꺽뇦膂苣릂菣ꂃ臣ꦈ铧ꮁ苣ꎁ臣躸臣覂苣讂胣趇ꛨꪁ臣ꢁ臣꾁胣뮔菥鞼볯醼볯꺁ꏨꊝ臣膀苣벃菣隌臣貂臣뎟ꏥ薃ꃥ貁꣨늌臣貂苣芀苣벃菣隌臣릖돦ꮁ臣骤臣꺁꟦薀臣节臣ꢁ臣讂臣ꢁ臣ꞁ臣讂臣膀ꗥ뺁臣辁臣膀苣ꦃ菣銂꣨릮臣讂苣蚁臣膀ꯩꚺ臣閃苣벃菣袃菣것菣뎃菣릖돦ꞁ苣벃菣隌臣貂苣芀臣꺁ꯩꚺ賥꺁뷥込臣膀ꯩꚺ臣閃苣벃菣袃菣것菣뎃菣銂迦鮾臣讂臣膂胣螃菣뾂臣ꪃ菣覃菣붂菣ꊃ菣ꚬ迥隌苣ꦈ铧馁苣袂臣ꮁ臣ꚁ苣꾉臣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 뎛볯鎼볯銂迥ꞅ臣讂臣膀賩뎟臣貂臣뎟ꏥ銂胢趆铧鶀臣龁臣ꢁ臣꾁ꫨ뾁迥誂ꏨ꺽볯隼볯隼苣ꢔ臣膀菣뎃菣궃菣ꦃ菣ꮁ臣馆鳧鞼볯醼볯銂賦뾁뻨뾁臣貁苣膣냦뮂菣떂菣薣뷧鞼볯銼볯銂胩躁臣鮁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 뎛볯鎼볯銂迥ꞅ臣讂臣膀鯥鎼볯颼臣뎟ꏥ궪臣随苣薣뷧鞼볯銼볯꺁鏦鲽臣芦闧ꊽ볥ꞁꓧ閁苣ꚁ臣讂胣趉꣨膣냦뮂菣떂菣鞼볯銼볯꾁곧銼臣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣鞼볯銼볯ꮁ軦骶臣貂臣蒁臣膀蛥龜臣辣鷩ꮁꃦ趴臣貂臣蒁苣螃菣뾂苣궪臣随臣ꚁ뻥랏賥馁苣袂臣ꮁ臣ꎁ臣蒁苣芀臣꺁뻥랏賥閁苣龁鿩낣菦놠臣ꆃ菣ꪃ菣鞼볯鎼볯ꮁꃦ趴臣貂胣떂苣뎃菣ꚇ郧膃菣鞃볯隼볯鎼苣讻臣ꚁ苣钃菣ꮂ菣鞼볯銼볯ꞁ蛥龔臣貂苣芀臣꺁苣Ꚃ菣覃蟥蚐菣莃菣鞼볯鎼볯꾁볯ꎼ볯螃苣벃菣벃볯隼볯颼臣뚈뻥许臣趓뷤閁苣膀菣ꪃ菣벃菣뎂菣袃菣벃菣蒂럥趁裦鞁苣趆铧蒂韦膀苣覭臣膀菣벃苣꺁꟦薀臣ꖅ諥뚈뻥鞼볯鎼볯ꮁ鿥ꖁ臣蚠臣趓뷤閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鞼胣㲑䐯噉ਾ†臣覂臣讂铦蒖臣ꒁ臣ꚁ臣誸꣨겪飦讁苣蚐꟨ꞁ臣讂苣蚁臣膀蟥鮊铧较臣ꊖ뿤馁苣뎟ꏥ꺁蟨開賩뎟臣龁苣꺁苣릂菣ꂃ臣邏뻤閁苣膀蛥龜臣ꊖ뿤馁苣뎟ꏥ늌鿩貁ꇨ辂苣讂胣뺁臣膀蛥龜臣辣鷩ꮁ꣨늌臣貂臣뮔菥銂ꫨ뾁迥讂臣膂臣뎟ꏥ궪臣随苣랂苣蚃菣节雩몤臣貂苣芀闦骤臣꺁ꓥ뒛迥뎁볯袏臣꺿귦貁胣Ꞥ臣讁臣겪飦閁苣龁鳦몙飦꺁닧麥臣龁臣蒯鯥讁苣뢀蓨馁苣鎁臣ꪁ臣膀觧骮臣龮雦꺁뷥讅臣몤臣貂苣袂臣ꪁ鳦몙飦뢁臣閁苣ꚁ苣袂臣鎁臣꾁胣鎽ꗦ薀臣袂臣ꚁ郧ꎧ臣貂苣蚁胣设臣낁胣릂菣것苣誁苣뎁볯閃苣벃菣莃菣肊ꇨ覭臣袂臣ꪁ胣袂苣螤鯩ꪁ鿩낣賩뎟蛥龔諦鎡臣꺁裥ꢔ臣芁苣芀戼㹲肊ꇨ隼볯꺁ꫨ躘㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖 閁苣ꪁ苣릔雥ꞁ臣膀菣ꪃ菣袃菣莃菣銂뷤ꢔ臣ꚁ胢趃苣鶀苣낍裥馁苣袂臣膀룤낿臣龁苣벃菣ꮂ菣薣뷧貁臩ꎭ臣鞃菣낂菣ꂃ臣貂苣芀ꧨ趃苣꾁胣ꊂ菣袃苣벃菣뮃苣뎃苣벃ꏨ꺽臣뾌藥閁苣ꚁ裥ꢔ臣趁苣袂臣膀꣦隺髧ꪁ苣벃菣ꮂ菣覃뷥込臣ꦁ郥鞁臣蒁苣芀苣벃菣ꮂ菣覃菣뮂菣떂菣薣뷧꾁胢趃苣鶀苣벃菣ꮂ菣覃臣베듧閁苣龁菦놠苣鲤鿧鞁胣馆鳧銂跥랈臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯馼胣㲑䐯噉ਾ†臣骁胣뎛볯钼볯銂迥ꞅ臣讂臣膀ꛨ花臣鲿臣ꚁ铧较苣鲤鿧馁苣뮂菣떂菣薣뷧鞼볯邼볯ꢁ胣ꊂ菣袃苣벃菣薃ꃥ銂ꓦꖟ臣讂臣膂臣ꮂ菣覃ꫨ뾁迥誂苣뎃苣벃볯鞼볯鎼臣銂若袁臣馨뫦蒚臣ꊂ菣袃苣ꂃꏨ꺽볯鞼볯醼臣膀ꛦꖕ뷥込臣몤臣貂臣蒁苣芀臣貂苣꺁苣뎃苣벃볯鞼볯銼볯鞼볯邼볯꾁胣ꊂ菣袃苣ꂃꏨ꺽臣趓뷤꺁臣膂臣趇ꛨꪁ꣨鞮触떮臣芁苣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣鞼볯邼볯꺁裥ꆾ룤ꞁ鏦鲽臣貂苣芀臣꺁苣벃菣ꮂ菣궸ꓥ鞃菣뮂菣떂볯鞼볯钼臣膀껥ꢅ臣馃苣袃菣隌臣貂臣뚼볯ꦼ볯袼敶祲氠湯⁧湩瑳畲瑣潩⁮潷摲볯궸ꓥ鞃菣뮂菣떂臣ꂊ臣ꚁ胣ꪂ菣鲃菣覃볯낼볯銂郥肂臣ꢁ臣ꞁ臣讂胣ꆼ볯낼볯鞼볯钼臣膀迥鞾臣龁铧较볯鞼볯銼臣ꚇ郧ꮁ諥袁臣膀苣벃菣ꮂ菣覃ꫨ뾁迥誂ꏨ꺽볯鞼볯鎼臣ꚁꫨ뾁迥ꎁ臣ꊂ菣袃苣벃菣袼菦놠볯꺁蟥蚐迥뎁뻥랏賥銂ꇨ蚁胣薆菩鞃菣뎃菣궃菣ꮃ臣袂苣鮾뗧閁苣讂菣ꪃ菣袃菣螃苣ꊂ臣鞃菣뎃菣颃菣覃볯鞼볯隼臣袂苣낍裥馁苣ꚇ郧뮔菥銂뷥邈臣膀蛥龜볯鞼볯鞼苣몇諥馁苣龁苣膀볯ꎼ볯鞼볯邼볯꾁菣ꊃ菣벃볯鞼볯閼臣꺁雩ꞁ臣ꚇ郧銂ꇨ蚁볯榈瑮牥捡覼胣늩苣벃菣ꮂ菣랂苣蚃菣鞼볯邼볯꾁胣貮藥ꪁ菣벃苣隃菣ꮂ菣ꦃ苣릂菣ꂃ苣讧꿧馁苣袂臣ꮁ꣨袨臣貂臣誁苣膀菣ꪃ菣袃菣莃菣鞼볯邼볯袼ꧨ鞃菣뎃菣颃菣覃臣膀볯ꎼ볯鞃菣뮂菣떂볯鞼볯钼臣뚈뻥许臣誁臣ꚁꛨ花臣袂苣馆鳧鞼볯邼볯꺁跥랈苣財臣龁苣꺁苣꺁臣芁苣覼臣ꖎ뛧閁苣龁菣ꪃ菣袃菣벃菣袼蛥떔黥ꞁ뷤蒁跦ꚁ臣趁苣节臣ꞁ臣ꎁ臣膀跥랈菣螃苣ꊂ迥뎁苣뎃苣銂뻤ꚵ臣讂臣膂臣节臣ꞁ臣讂볯銂若袁臣蒁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 뎛볯钼볯銂迥ꞅ臣讂臣膀鯥鎼볯邼臣ꊂ菣袃苣ꂃ苣릂菣ꂃ臣趓뷤꺁苣蚃菣鞃臣芁臣ꚁ胣閁苣ꪁ苣릔雥ꮁ뻥ꎁ臣节臣鞼볯醼볯貁ꓧ閁苣ꚁ臣讂胣閁苣ꪁ苣릔雥ꞁ臣膀臣骁胣견볯꺁苣벃菣ꮂ菣薣뷧銂뷤ꎁ臣肉鳦꺁铧较臣꺒뷥閁苣讂볯鞼볯醼볯覼胣ꆬ臣膀ꯩꚺ臣閃苣벃菣袃菣것菣뎃菣ꞁ臣ꎁ臣膀鯥ꦾ臣貂苣몇諥螃菣뾂뷥込苣邏뻤馁臣辁胣늩鋦놽铧较臣ꚇ郧閁苣讂胣鶁臣ꚇ郧꾁胣뮔菥膀ꓨ붣臣貂臣螃菣뾂胣螃菣뾂胥꺁藩鞈臣螃菣뾂苣醖볤ꦃ菣肃菣ꮁ뇥讖臣讂臣ꮁ諥袁臣ꪃ菣覃裢붂菣ꊃ菣ꚬ迥隌菣벃苣꺁鳥꺸苣ꮐ苣鎁臣貁臣趁苣芀臣꺁蟥鮊뷥込臣膀뿥膦臣覂胣뮔菥꺁鳥꺸臣ꂊ臣膀룤낿臣龁苣蚁臣鲀苣벃菣ꮂ菣覃胢薣뷧ꮁ苣誂迦鮾臣貂苣꺁臣貐臣ꮁ臣趁苣芀苣벃菣ꮂ菣覃臣몇諥螃菣뾂臣ꂊ臣膀ꓦꖟ铧较臣떂菣趃苣ꮃ铧较臣鶁臣ꚬ迥隌臣貂臣螃菣뾂臣뾲臣ꚁ跥랈臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 鶁臣ꊂ菣袃苣벃菣ꢷ裦꾁胣뎛볯钼볯ꮁꓧ閁苣讂苣蚁臣膀볯ꎼ볯뮂菣떂菣鞼볯邼볯ꮁ苣ꎁ臣뮔菥鞼볯銼볯銂迥鞾臣讂臣놅臣膀苣벃菣ꮂ菣꺁胢趃苣鶀臣节臣鞼볯銼볯銂蟥鮊臣讂苣벃菣ꮂ菣薣뷧鞼볯邼볯銂若袁臣蒁苣芀ꧨ鲀菣겂胢ꊽ볥꺁苣꺁臣膀藥鮊铧较臣떂菣趃苣ꮃ볯鞼볯钼臣膀ꓦꖟ铧较苣颫뫥ꮁ곧랏賥鞁臣节臣鞼볯銼볯ꢁ苣ꮐ苣芀鯥鎼볯銼臣꾁ꓧ閁苣ꚁ臣ꪁ臣醁苣ꦁ苣膀臣꺁蟥鮊臣貂臣节臣꾁胣ꊂ菣袃苣ꂃꏨ꺽볯鞼볯醼蛥꺁ꏨ궖ꏨ꺽臣袂臣ꚁ럧鞼볯銼볯ꮁ닦ꎁ臣骀룥꾁裥誂迥覂苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯銼胣㲑䐯噉ਾ†菣벃苣ꢂ菣ꊂ볯鞼볯銼臣膀ꧨꢂ菣ꊂ볯鞼볯銼臣뒁룧ꮁ닦ꎁ臣肸胩꺁跥袼뻤袁臣膀볯鞼볯鞼볯鞼볯銼볯覼臣놅臣낍裥閁苣讂胣鶁苣覂臣낍볯鞼볯鞼볯鞼볯銼볯꾁胣릂苣ꎃ菣閁苣讂臣趁臣螃菣뾂苣ꪃ苣鞼볯銼볯꺁귦몢臣趽뷧銂룤袁苣芀胢趃苣鶀볯鞼볯醼苣낍裥馁苣鎁臣ꮁ苣誂胣뮔菥꺁跥뢰매蒚臣風賩貁뻥覂苣讂胣鎁臣鲀菣겂胢鞼볯銼볯꾁胣馆鳧꺁菣겂苣鶿귥馁苣꺁臣貐꟦꺁雦閳臣袂苣鶿귥閁苣讂胣随뻥鞁臣뮔菥꺁胣閁苣ꪁ苣膀ꯩ膓돨ꪁ苣钃菣銂뿥膦臣馁苣뒠郥ꮁ臣膀觥風苣벃菣ꮂ菣覃胢趃苣鶀臣膀鯥鎼볯銼臣ꊂ菣袃苣ꂃꏨ꺽臣ꊂ菣袃苣벃菣궪臣随苣薣뷧鞼볯邼볯꺁룤뢁賦ꖅ臣貂볯뎛볯钼볯꺁볯鞼볯鎼볯膀苣벃菣ꮂ菣覃菣벃苣꾁胩뢸臣릖돦ꞁ뻥랏賥閁苣膀苣ꪃ苣誃菣뮔菥貁뻥覂苣讂胣ꚬ迥隌臣貂臣蒁苣螃菣뾂臣膀苣ꪃ苣誃菣ꪁ铧较臣膀ꧨ뮔菥銂苣벃菣ꮂ菣薣뷧ꮁ苣誂跥랈臣讂臣膂臣薿ꛨꪁ賦몤苣ꮐ苣鎁臣貁臣趁苣芀ꓦꖟ臣貂臣ꮂ菣覃臣ꦾ迥隌臣貂볯뎛볯钼볯꺁볯鞼볯钼볯膀ꛨ花臣鲿臣ꚁ뷤ꚺ苣낍裥閁苣袼볯鞼볯閼볯膀苣ꪃ苣誃菣뮔菥貁뻥覂苣讂胣ꒁ臣誂胣鲤鿧閁苣龁铧较臣몇諥閁苣讂胣袂臣ꚁ胣鲤鿧閁苣龁铧较苣颫꟨较뫥ꢁꯩ蒁鯥ꦾ諥ꞁ苣钃菣馁苣랂苣蚃菣貁뻥覂苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鎼胣㲑䐯噉ਾ†믤꺁껥붖뻤节꟦邈臣讂臣ꢁ臣ꞁ臣讂胣设臣낁胣趉꣨鲀菣겂胢螃菣뾂苣膀蛥龜鷩꺁ꏨꊝ臣ꪇ该낍裥馁苣ꢷ裦銂裥ꢔ臣ꚁ苣꾉臣芀臣꺁苣蚁臣ꢷ裦꾁鯥鎼볯鎼臣몤臣貂苣芀ꧨ뎛臣몤臣貂苣节臣꾁胣馆鳧鞼볯鎼볯꺁ꏨꊝ臣芁苣膀苣ꂃ菣ꒂ菣ꢃ裥鞼볯鎼볯ꮁ諥袁臣膀菣벃苣ꚬ迥隌苣ꪃ苣鞼볯鎼볯貁跥랈臣貂臣蒁苣芀臣龁臣ꎁ臣膀ꧨ螃菣뾂苣ꪃ苣鞼볯鎼볯꾁胣늩苣벃菣鞼볯鎼볯꺁ꇨꊝ臣誁臣ꚁ胣뮔菥ꮁ雩鞁臣꺁胣認냦薹髧ꞁ胣颫臣뺲뫥꺁꣨늌苣邏뻤馁苣鎁臣貁臣趁苣芀戼㹲肊ꇨ隼볯꺁ꫨ躘㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 閁苣ꪁ苣릔雥ꞁ臣膀菣뎃菣ꂃ臣몇諥꺁ꛨ花臣鲿臣ꚁꓥ낕臣ꊂ菣袃苣벃菣銂蟥鮊臣趁苣ꊂ菣袃苣벃菣뮃菣ꪃ菣뾂菣貁迦鮾臣貂苣芀臣꺁ꏨ膓臣鞃菣뎃苣벃臣膀菣莃菣꾃菣꾂苣讻臣ꚁ믤꺁ꏨ膓臣鞃菣뎃苣벃臣ꖎ뛧閁苣膀럧袐苣뎃菣ꖃ菣뾂苣릂菣ꂃ臣膀触骮臣膦뇦ꮁ뻥ꎁ臣ꊂ菣袃苣벃菣銂裥超臣讂臣膂臣趃菣袃菣벃苣銂裥ꆾ臣讂胣鎁臣袂臣ꪁ雦閳臣膀ꯩ蒁鿦龻胦銂룤袁苣龁苣膀苣벃菣ꮂ菣覃臣붣胩貁苣뎃菣궃菣ꮃ臣貂苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 뎛볯钼볯銂迥ꞅ臣讂臣膀臣ꎁ臣肸臣꺁苣벃菣ꮂ菣覃菣ꪃ菣뾂菣鞼볯邼볯貁ꛦꖕ鯥꺁뷥込臣몤臣貂臣蒁苣芀ꧨ鞃菣뎃苣벃臣膀苣벃菣ꮂ菣覃臣誸鷩ꮁ铧较苣낍裥馁苣龁苣꺁菣ꪃ菣袃菣莃菣鞼볯邼볯膀迥뎁苣벃菣ꮂ菣覃臣许鷩ꮁ铧较迥놉ꫨ躘鯦袼곧랏賥閁苣龁苣꺁볯銂跥랈臣讂臣膂臣鞃菣뎃菣颃菣覃볯颼볯鎼臣銼臣꺁菣ꪃ菣袃菣莃菣鞼볯邼볯貼볯颼볯鎼苣馂臣ꚁ臣讂胣늩菣ꪃ菣袃菣莃菣鞼볯邼볯꾁苣뎃苣鮾뗧ꢃ볯颼볯隼苣覜臣讂볯늉臣鞃菣뎃菣颃菣覃臣馁苣鎁臣貁臣趁苣芀룤ꊝ菣ꪃ菣뾂菣鞼볯邼볯꾁볯ꒁ臣ꒂ菣꾂뻤ꚵ菩鞼볯邼볯銂鳦馁苣颍觨鞃菣뎃菣颃菣覃臣馁苣鎁臣貁臣趁苣芀菣ꪃ菣뾂菣鞼볯邼볯꾁胣膦뇦ꮁ뿥颁臣ꊂ菣袃苣벃菣銂菣ꪃ菣袃苣Ꚃ菣馁臣辁苣뎃菣ꖃ菣뾂苣릂菣ꂃ臣뚈뻥ꮁ臣趓뷤閁苣讂胣낍裥鞁臣貾胣馃菣릂菣것菣袃볯颼볯邼볯膵胩꺛髧꺁臣膂臣骤闦꺁苣벃菣ꮂ菣覃臣超뷧閁苣龁苣꺁볯讁苣ꊂ菣袃苣벃菣銂触ꆁ蟥馁臣膂臣醃菣膃ꏨ꺽볯颼볯馼臣超뷧閁苣ꚁ臣讂胣肉껥꺁賥龟臣膦뇦ꮁ뻥ꎁ臣蚈藩芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 뎛볯钼볯銂迥ꞅ臣讂臣膀苣벃菣ꮂ菣覃뫤颻苣릂菣ꂃ臣뚈뻥趃菣袃菣벃苣鞼볯銼볯꺁룤겈髧ꪁ藩鞈臣몤臣貂臣蒁苣芀룤ꎀ臣鞃菣뎃苣벃苣뎃菣ꖃ菣뾂ꏨ꺽볯设臣낁胣鞼볯銼볯覼臣超뷧閁苣膀ꛨ花臣鲿臣ꚁ꟦薀臣ꊽ藦銂迥讂臣ꢁ臣ꞁ臣讂菣莃菣꾃菣꾂볯颼볯銼臣肸럧ꮁ軦骶臣貂臣蒁苣芀룤꺤뗧袐苣뎃菣ꖃ菣뾂볯颼볯鎼臣趃菣袃菣벃苣鞼볯銼볯誏臣鞃菣뎃苣벃苣뎃菣ꖃ菣뾂볯设臣낁胣鞼볯銼볯覼苣뚈뻥鞁臣膀菣ꪃ菣뾂菣뎂菣钃菣벃苣袼뻤袁臣膀볯颼볯醼볯ꮁ苣ꎁ臣ꊂ菣袃苣벃菣꺁뗧뾁郥辂臣龁苣꺁苣낍裥馁苣螌ꓧ銂胩讂苣蚁臣ꪁ臣ꚁ臣讂胣鞃菣뎃苣벃苣뎃菣ꖃ菣뾂볯设臣낁胣鞼볯銼볯覼臣膀ꛨ花臣鲿臣ꚁ鳥릖臣超뷧馁苣鎁臣貁臣趁苣芀裦蒁臣膀臣貂苣꺁菣ꪃ菣뾂菣뎂菣钃菣벃苣銂룤莿볯授湥牴污祬볯ꮁ藩꺽臣ꚁ苣꾉臣貁胣颧胣ꪁ鳥릖臣膀苣貂胣隈臣꾁胣颧胣ꪁꛨ花苣肺뛨馁苣龁苣ꮁ釥꒻臣貂苣讁苣ꖟ苣ꪁ臣芀臣貂臣貂臣鞃菣뎃苣벃苣뎃菣ꖃ菣뾂臣膀苣벃菣ꮂ菣覃臣Ꞥ臣ꪁ苣ꎃ菣랂菣銂鳦馁苣鎁臣貁臣趁苣芀臣꺁苣ꎃ菣랂菣꾁胣ꆃ菣ꪃ菣蒂胣螃苣릂苣蒂胣蒐菣ꪃ菣뾂菣뎂菣钃菣벃苣ꮁ臩鲮藩莸臣貂苣ꎼ볯銈볯꾼볯ꮁ꣨醁苣鎁臣貁臣趁苣芀룤꺤뗧袐苣뎃菣ꖃ菣뾂臣膀菣ꪃ菣뾂菣뎂菣钃菣벃苣ꮁ苣ꎁ臣낍裥閁苣讂臣趁苣벃菣ꮂ菣覃臣ꪃ苣袃苣超룥馁苣芀諥袁臣膀雦鞁臣ꊂ菣袃苣벃菣貁ꧨ궸ꓥ놵郥뎂菣钃菣벃苣鞼볯鎼볯ꮁꫨ뾁뻨뺁苣膀ꛨ花臣鲿臣膀雩ꎀ臣讂菣ꪃ菣뾂菣뎂菣钃菣벃苣袼뻤袁臣膀볯颼볯醼볯ꮁ胩覂苣讂胣鶁臣超룥꾁胣궂菣莃苣ꖃ臣貂臣超룥超裥꺁뷥込臣芁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖 뎛볯钼볯銂迥ꞅ臣讂臣膀菣ꪃ菣뾂菣뎂菣钃菣벃苣꺁ꗥꦁ臣ꢷ裦鞼볯鎼볯꺁볯ꒁ臣ꊽ藦貁ꓧ閁苣ꚁ臣讂胣鶁臣ꢷ裦鞼볯鎼볯꾁鿥릹苣뎃菣ꖃ菣뾂苣릂菣ꂃ볯颼볯醼苣馂臣膀ꧨ뎂菣钃菣벃苣랂苣蚃菣鞼볯鎼볯꾁胣Ꞥ臣ꪁ菣ꊃ菣蒂菣ꎂ苣꾂苣ꎃ菣랂菣ꎂ苣膌臣膀菣ꒂ苣뎃菣꺁볯ꎼ苣ꒂ菣꺁苣뎃菣ꖃ菣뾂臣芁苣芀臣꺁苣뎃菣ꖃ菣뾂苣릂菣ꂃ臣鞼볯鎼볯꾁胣뎛볯钼볯꺁럧邈臣鎾臣ꚁ藩鞈臣貂臣ꊂ菣袃苣벃菣鞃菣뎃苣벃볯颼볯銼臣ꖎ뛧閁苣ꚁ臣讂胣늩苣뎃菣ꖃ菣뾂苣릂菣ꂃ볯颼볯醼臣膀菣莃菣꾃菣꾂볯颼볯钼臣ꂊ臣ꚁ胣궂菣莃苣ꖃ臣貂苣ꊂ菣袃苣벃菣鞼볯鎼볯꺁ꓥ趁臣릂菣ꊂ苣馂臣ꚁ臣讂胣袂臣ꚁ胣鞃菣뎃菣ꊂ苣袃臣貂苣릁臣ꊂ菣袃苣벃菣꺁菣릂菣꾁觥風룤꺤苣뎃菣ꖃ菣뾂臣覂郥鞃菣뎃苣벃苣뎃菣ꖃ菣뾂臣膀苣벃菣ꮂ菣覃臣낍裥꺁臣膂臣ꊻ胩閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯颼胣㲑䐯噉ਾ†鯥鎼볯閼臣ꢷ裦ꞁ臣膀ꓥ趁臣蒵臣袐苣鮁臣螤鯩ꪁ藩莸臣辕ꇩ貁触讖臣貂胣超룥꺁苣릂菣ꂃ臣릔觨閁苣龁뷥讅臣芁苣鎁臣貁裥讂胣㲂牢ਾ苣뎃苣뢂苣莃菣肊ꇨઓ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯馼胣㲑䐯噉ਾ††鳦몙飦꺁껥붖뻤꾁苣뎃苣뢂苣莃菣鞃菣뎃苣讞ꏨ꺽苣뾽铧鞁臣蒁苣芀苣ꆁ苣鎂胣骤臣꺁闧ꪁ苣薣뷧銂뷤ꢔ臣讂臣ꢁ臣ꞁ臣讂胣鞁臣鞁臣貁苣膀迧ꢜ菣钃菣ꦃ菣ꪁ苣뎃苣뢂苣莃菣鞃菣뎃菣肊ꇨ꾁臩鞁臣蒁臣蚁臣节蓧蒁胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯邼胣㲑䐯噉ਾ††苣벃菣ꮃ苣뎃苣뢂苣莃菣ꞁ臣肜苣趇ꛨꪁ闥財臣뮛諥袶단ꞁ臣讂胣ꒂ菣꾂믦꺁냥몇臣ꢂ菣ꮃ苣벃諥螎臣ꪂ臣鎁臣ꮁ뗨ꂛ臣膀ꯩ龀臣龁苣ꮁ뿥膦臣뮛諥꾁듧醼볯邼胥ꞁ臣讂胣ꒂ菣꾂苣邐蟥閁臣讂鋨鞰돦銂铧邈臣讂臣膂臣膀냦꺁뿨龀臣뢲꣩銂뿥膦臣馁苣讁苣ꞁ臣讂胣뒰臣Ꞥꓥ颫臣놆껥辇苣覜臣ꚁ臣ꚁ胣떂菣麃菣ꒂ菣꾂苣Ꞃ菣袃臣ꦈ铧ꮁ臣蒁臣躁蛧閁苣讂胣鎁苣꾁胣뮛냦꺁藥鮊苣讁该꺁蟥鮊臣覤迦馁苣龁苣膀듧邼볯邼볯薼臣릊軧銂뿥膦臣馁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖 †钃苣뺂苣것苣袃菣莃苣ꒂ菣꾂苣Ꞃ菣袃臣꺁鳦节蟩膦臣辕ꇩ꾁苣ꒂ苣ꢁ苣릂菣ꞁ臣讂胣钃苣뺂苣것苣袃菣莃苣꾂菣릂苣ꮃ臣ꦁ뷥ꪁ꟩開鯩Ꞝ臣ꚁ鷩뢸臣辰臣ꪁ菣閃菣꾂苣ꞃ菣袼뷯薽뷯貽뷯莽뷯覽뷯躽볯銂鳦鞁臣蒁臣膀臣貂闦膀郥躃苣ꮃ臣龁苣ꮁꓥ趁臣ꢂ菣ꊂ臣薿ꛨꢁ臣讂胣뺁臣膀郥钃苣뺂苣것苣袃菣莃苣꺁苣꾂菣ꖃ苣벃苣꾁胣蚈鯩鞁臣몟鷦꺁꟩開鯥꾷臣ꖎ뛧閁苣ꪁ臣貂臣ꪁ苣ꪁ臣芀臣꺁臣ꢁ臣膀볯邼볯讨뫥꺁菣몂菣꺁鯩膵裥邙臣誁臣ꚁ臣趇ꛨꪁ闥財臣꾁臣蒁臣膀볯馼볯銼볯邼臣躃苣ꮃ苣覜臣讂菣벃苣薹菣ꪃ菣袃菣莃菣꺁ꏨꂀ臣꾁ꓥ趁臣鲚껥ꢁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯銼胣㲑䐯噉ਾ††郧뎃臣鞁臣꾁胣뾽铧閁苣龁苣뎃苣뢂苣莃菣肊ꇨ꾁胣麝藥讖臣螃苣뾂菣ꮂ菣벃菣ꪃ菣蚃苣뎃苣蒂胣隻臣较苣꾂苣ꪃ菣ꎂ臣较苣릂菣벃菣ꞁ菣벃苣릂菣꺁菣ꪃ菣袃裥ꢔ臣膦뇦閁苣讂胣螃苣뾂菣馆鳧꺁ꛨ花臣袐苣鮁苣龁苣膀雦龁臣ꒂ菣꾂苣Ꞃ菣袃諦鎡臣떉蟥閁苣ꚁ臣龁胣꺛髧꺁觧뒾臣ꆬ臣节臣ꞁ臣讂胣骼臣ꪁ苣ꆁ胣㲁牢ਾ뷤뮛諥袼볯邼菣莃菣ꪜ뫦覼戼㹲颫꟨较뫥Ꞁ菨袼볯貼볯邼볯蒽뷯覽迥꾁臣貂믤誸볯㲉牢ਾ蛥龜苣ꦂ菣蚃苣꺁蟥鮊戼㹲躽ꏨꂀ苣릂菣㲈牢ਾ냥떂苣몂볯ꪨ裥誂맥貁鳦辰臣ꪁ苣袂臣ꮁ菣벃苣薹苣뾪闦馁苣覼戼㹲较苣릂菣벃菣袼볯醼ꃩ鎽臣誂볯銧볯ઉ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鎼胣㲑䐯噉ਾ††臣貂苣꺁觧뒾臣ꢅ臣꾁胣貾뿨馁苣ꒂ菣꾂苣Ꞃ菣袃苣릂菣ꂃ臣袂苣膀闧ꪁ苣것菣ꮃ臣낛鯩閁臣膪ꃧ閁苣讂臣ꢁ臣꾏菨ꞁ臣讂胣钼볯讀臣낕臣讂苣뎃苣뢂苣莃菣肊ꇨ꾁胣颫菣ꪃ菣벃菣꺁ꏨꂀ臣龁苣ꮁ맥莺臣뢁諦銂룤袁苣袂臣膀迥醁뛧邁胨ꮁ苣ꎁ臣몙뇥閁苣ꚁ臣龁胣鎁苣覂臣肊ꇨ꾁胣貾臣風볨馁苣ꢡ臣몤臣袂臣ꮁ胣겜蟥颡뫤ꮁ賦骮臣貂臣蚈鯩閁苣龁뿥ꢔ苣ꊽ裦馁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖 †鎁臣ꮁꓧ閁苣讂苣뎃苣뢂苣莃菣꺁꣨袨볯螃苣ꒂ菣覼臣膀鯩ꂱ臣蚧该閁苣讂볯麛뷤ꢔ臣螃苣뾂菣ꮂ菣ꦃ臣覂胣鎍룤꺁菣莃菣꾃菣꾂菣ꪃ菣뾂苣궥该ꢔ臣鞃菣뎃菣랂苣蚃菣뺁臣膀맥꺁뫥蒁菣뢂苣ꮃ菣ꪃ菣袃苣릂菣ꂃ臣ꦁ臣ꚁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯閼胣㲑䐯噉ਾ††꣦隺臣薣뷧銂뷤ꢔ臣ꚁ냧颍臣붣胩馁苣龁苣ꮁ胣趉꣨鞃菣뎃菣颃菣覃臣膀볯ꖼ볯뎼뻥ꚇ郧閳臣袂臣ꚁ胣ꊃ菣ꪃ苣莃苣꺁볯躼볯龃苣궃菣꺁볯궼볯뎼菣莃菣ꮁ꣨袨臣貂苣芀苣ꦃ菣馆鳧꺁뿥ꢔ臣龁苣膀觥風菣ꪃ菣袃菣莃菣꾁볯邼볯趽뷯꺁闩閁臣膀苣뎃苣뢂苣莃菣꺁苣ꒂ菣ꮁ뿥颁臣薹苣覜臣讂胣肜냥꺁菣ꪃ菣袃菣莃菣꾁볯ꪼ볯颼臣芁苣膀맥꾁볯躼볯閼뷯趽臣膀볯閼뷯趽猼灵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰銼⼼畳㹰臣膃菣鞃鷩趩苣覜臣讂胣鶁臣鞃菣뎃菣颃菣覃臣醼볯貼볯邼볯讀臣躃苣ꮃ臣螃菣뾂迥뎁裥ꆾ鯥꾷苣覜臣ꚁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯隼胣㲑䐯噉ਾ††苣뎃苣꾁胣蒰蟥邈뷥閁苣龁菣ꦃ苣膃菣꾂ꏨ꺁苣뎃苣骀럨銂뗧놔臣ꚁ胣鞃菣뎃菣颃菣覃臣貃鷩ꮁ뻤ꚵ臣貂苣芀臣꺁菣벃菣螃苣뎃苣꾁볯邼菣꾂菣꺁觧뒾볯蚽뷯膽뷯閽뷯薽뷯覼臣薿ꛨꢁ臣貂苣芀臣꺁觧뒾臣膀꣦隺髧ꪁ냥몇裦讞럥랅臣궸臣ꪃ苣낂菣閃苣ꞁ菣ꒂ苣궃菣랂菣ꂊ럥閁苣龁苣뎃苣벃菣銂뷤ꢔ臣ꚁ뷥邈臣貂苣鎁臣貁臣趁苣芀苣뎃苣꾁胣Ꚃ苣较臣ꎭ鷩ꮁ뷥邈臣貂臣躃苣ꮃ菣膃菣뎃菣벃臣膀苣ꢂ菣銂단骀臣讂苣蚁臣ꊽ裦閁苣龁귥銂胩ꎁ臣膵苣讂胣鶁臣鞃菣뎃菣颃菣覃臣뒼볯ꊼ臣袂苣ꮂ菣ꦃ鯥꾷臣ꖎ뛧閁苣ꚁ臣讂胣㲂牢ਾ㰠牢ਾ鯧銺迥ꞅ믤趁臣ꊂ菣ꪃ苣벃苣ꞃ菣ળ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鞼胣㲑䐯噉ਾ††곦ꢡ臣膀鳦醿蟥颡臣貂臣뎱鯥릉꣨몇ꇩ꺁苣ꒂ菣ꞁ臣讂胣鶁苣覂臣몇ꇩ꾁胣鎁苣ꢁ藥ꮁ룤視臣邏蟥閁苣膀觧ꖈ臣놂菣릂臣肨迥馁苣ꢁ臣ꮁ胣鶁臣貾臣ꢡ臣뾽铧閁苣讂迥莀苣ꢔ臣ꚁꓦ躨臣貂臣蒁苣芀臣貂苣꺁蟥颡臣膀臣龁胣뺯뿥馁苣芏胨ꪕ迥銂鳦馁苣ꪂ菣릂菣ꦃ菣ꊂ믤릉꣨몇ꇩ袼觥낿臣ꢡ臣ꚁꓧ閁苣龁苣蚁臣覼臣袂臣ꮁ蟥颡臣貂臣蒁苣芀戼㹲㰊䥄㹖胣ꢡ볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔲㰵愯㰾䐯噉ਾ㰊䥄㹖胣ꢡ볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔲㰶愯㰾䐯噉ਾ覃菣莃菣뮃苣뎃菣螃菣뎃菣릖볥꺁苣뎃苣뢂苣莃菣ઈ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯颼胣㲑䐯噉ਾ††胥薀臣ꒂ菣꾂苣Ꞃ菣袃菣몂菣꺁鿥겜该鲽臣ꊖ臣讂볯醼胥꺁蟩膦臣릉뻥貁觧骮臣貂臣趁臣蒁苣芀臣貂苣꺁觧뒾臣Ꞥ뷤꾁鯧銧볯辽뷯钽뷯辽뷯辽뷯膽뷯覼臣芁苣膀臣龁臣ꎁ臣膀볯醼곦莅臣麃菣ꪃ苣릂臣鞁臣ꎧ飦閁苣讂臣ꢁ臣ꞁ臣讂胣鎁臣麃菣ꪃ苣릂臣醼볯뢻臣뮁臣鎂臣꾁胣겜蟥颡뫤ꮁ苣誂駧閱臣貂臣風藥论ꃩ銂郥肂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯馼胣㲑䐯噉ਾ††곦꺁ꇨ꾁胣ꒂ菣꾂苣Ꞃ菣袃苣ꒂ菣꺁볯醼곦莅臣ꢡ臣뢻苣ꊽ裦馁苣芀戼㹲ꊂ苣膃菣ꢂ菣뾂菣ꆃ苣讃苣ꂃ볯醼볯뾂苣鞃볯㲉牢ਾ鿥겜该鲽菣벃菣袼볯뾂苣鞃볯㲉牢ਾꏨꦊ臣ꊂ苣膃菣ꢂ菣뾂볯颼苣ꒂ菣覼戼㹲ꊂ苣膃菣ꢂ菣뾂臣鞢맥誏臣릔觨릖돦袼볯鞼苣ꒂ菣覼戼㹲ꊂ苣膃菣ꢂ菣뾂臣開臣袼볯馼苣ꒂ菣覼戼㹲躃苣ꮃꏨꚵ雦閳볯钼苣ꒂ菣覼戼㹲뢐藥ꎏ臣꺁胩膵苣뚈駩馁苣릖돦袼볯邼苣ꒂ菣覼戼㹲躃苣ꮃ臣莎駩릖돦袼볯뾂苣鞃볯㲉牢ਾ菣몂菣鞃菣벃菣讧胩袼볯뾂苣鞃볯㲉牢ਾ믦꺁駥몇雦醐볯閼苣ꒂ菣覼戼㹲ꒂ菣꾂苣ꒂ菣袼볯뾂苣鞃볯ઉ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯邼胣㲑䐯噉ਾ††臣貂苣꺁믨ꮁ苣誂ꇨ몤臣貂臣貮藥ꪁ볯醼곦莅臣ꢡ臣膀苣뎃苣뢂苣莃菣躃苣ꮃ臣ꊖ臣膀볯隼볯蒄臣꾏菨ꪁ뷥讅苣ꮐ苣芀꟦薀臣ꒂ菣꾂苣Ꞃ菣袃諦鎡臣誁臣ꚁ臣貂苣꺁藥ꚁ臣龮迧꾏菨ꞁ臣ꪁ臣醁苣ꦁ苣膀闦뺙룤꾁껥財迥붃臣芁苣芀迥붃臣ꊽ藦꺁藥ꚁ苣겪飦馁苣鎁臣꾁胣躘苣讁臣麝迧龮髧ꞁ臣讂胣鶁臣ꎻ苣誂胣蒁臣ꒁ臣꺁苣뎃苣뢂苣莃菣뾂苣鞃臣뎩듧ꮁ郥뎑臣貂臣趁臣芀臣貂苣貁胣誸뿨꺁胣螌郥閁苣龁볯ꪼ볯醼臣覂볯ꪼ볯閼臣芁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖 †隻臣ꒂ菣꾂苣Ꞃ菣袃臣ꊽ藦꾁胣醼볯뢻臣醼迥꾁臣貂믤誸臣뾲臣ꚁ믤뾛臣ꪁ苣ꊽ藦ꮁ뷧趁迦袁苣鎁臣ꮁ苣誂胣鎁苣覂臣钼볯꺁뻤讁苣뒛臣ꮁ냥趁蟥馁臣ꢁ臣ꞁ臣讂胣ꦼ볯邼볯讁苣ꦼ볯钼볯꺁臣ꢁ苣ꦁ臣膀뷤覂臣꺁迧ꢜ裥ꢔ臣趁苣ꒂ菣꾂苣Ꞃ菣袃諦鎡苣誂룤趽臣芁苣릉뻥銂胣ꒂ菣꾂苣Ꞃ菣袃菣ꪃ菣袃菣莃菣ꮁ뷤誂뻨肂臣ꢁ臣ꞁ臣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯銼胣㲑䐯噉ਾ††駧躘胨ꮁ鿧覂苣ꚁ臣讂藥財諦鎡뻤貁臣讂ꃥ袐臣꾁胣鎁苣覂臣醼迥꾁臣貂믤誸臣膀룤風臣ꢡ臣设臣蒬臣몤臣貂苣芀ꧨꦼ볯邼볯讁苣ꦼ볯钼볯꺁苣ꪃ菣몂臣뺁臣膀뻤꺁곦ꮁ苣몤臣貂臣蒁苣芀맥ꒁ臣꺁苣벃苣ꞁ臣膀菣ꪃ菣뾂臣膀볯ꒁ믤誸臣릉뻥銂藥覜臣讂ꃥ袐臣꾁胣醼臣꺁ꇨꮁ볯麛믤誸ꓧ閁苣讂臣节鿧貂臣蒁胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鎼胣㲑䐯噉ਾ††ꗥꦁ臣鲿铧꾁믤许臣节臣銂郥肂胣馁臣辂臣膀껥궺铧鞃菣뎃苣膀苣閃苣릂铧趃菣袃菣벃苣鞃菣뎃苣膀鿧龜铧螃苣뾂菣鞃菣뎃苣膀ꗦ馋铧鞃菣뎃菣랂苣蚃菣膀룥ꢔ菣ꪃ菣뾂胣鶃苣莃菣鞃菣뎃苣膀苣뎃苣벃菣莃菣鞽뷯鞽菣ꪃ菣뾂胣鎃菣ꪂ菣ꪃ菣뾂胣뮌駧ꢔ铧较胣Ꞥ裥鞃菣뎃苣膀菣벃菣讞菣붂苣뎃铧鞃菣뎃苣膀菣ꆂ菣꾂苣龩胣ꖷꗦꢔ菣ꪃ菣袃苣릂菣ꂃ胣馆鳧뎂菣벃ꧦ膀蛥龜迧较뫥覭胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯钼胣㲑䐯噉ਾ††觥낿臣龁볯醼곦莅臣麃菣ꪃ苣릂臣ꊖ胩颻臣覂苣龁菦놠臣ꖻ룤꺁ꇨꮁꓧ閁苣讂胣ં⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯閼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㜵⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯隼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㠵⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鞼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㤵⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯颼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰〶⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯馼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰ㄶ⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯邼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㈶⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯醼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㌶⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯銼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㐶⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鎼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㔶⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯钼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㘶⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯閼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㜶⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯隼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㠶⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯鞼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㤶⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯颼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰〷⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯颼볯馼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰ㄷ⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯邼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㈷⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯醼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㌷⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯銼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㐷⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯鎼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㔷⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯钼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㘷⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯閼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㜷⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯隼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㠷⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯鞼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㤷⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯颼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰〸⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯馼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰ㄸ⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯邼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㈸⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯醼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㌸⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯銼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㐸⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯鎼胣㲑䐯噉ਾ䐼噉邀ꇨ銼볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㔸⼼㹡⼼䥄㹖ਊ苣뎃苣뢂苣莃菣鞃菣뎃菣ꎂ菣낂㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖 뢛뷥낕臣낖黥꺁苣뎃苣뢂苣莃菣鞃菣뎃苣貁胣붥臩ꪁ껥붖뷥讅臣鞁臣膀苣뎃苣뢂苣莃菣肊ꇨꮁ迥ꎁ臣ꎻ苣讂臣膂臣몙뇥鞁臣趁臣蒁苣芀苣뎃苣뢂苣莃菣螃菣ꒂ苣꺁꟦薀臣蒵臣袐苣鮁臣膀鳦몙飦꺁룤ꢃ臣鞁臣讖ꓧ閁苣ꚁ臣讂菣ꪃ菣뾂菣邃苣릂臣궸臣ꮐ苣讂臣ꢁ臣ꞁ臣讂胣뢛뫤芏藧ꢡ臣袂苣릉裥ꮁꓧ閁苣讂胣鎁苣覂臣ꒂ菣꾂苣Ꞃ菣袃臣ꊖ胩馁苣ꪂ菣릂菣ꦃ菣ꊂ臣꺻觧놨臣躘듧뢛臣芁苣芀臣ꪁ苣ꆁ胣㲁牢ਾ䐼噉邀ꇨ銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㘸⼼㹡⼼䥄㹖ਊ䐼噉邀ꇨ銼볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㜸⼼㹡⼼䥄㹖ਊ苣뎃苣뢂苣莃菣꺁铧ꎔ㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖 閁苣ꮁ胣겜蟥颡臣膀ꓥ낕臣ꒂ菣꾂苣Ꞃ菣袃菣ꪃ菣뾂臣讧꿧ꮁ胣颫뫥ꪁ跥躰뷤붣胩肊ꇨ貁뷤ꢔ臣貂苣讁苣ꖟ苣ꪁ臣芀ꗥꦁ臣붣胩肊ꇨ꾁胣ꆬ臣뢛뫤芏藧ꢡ臣몤臣貂臣蒁苣ꪂ菣릂菣ꦃ菣ꊂ믤릉꣨꺁飦내鯦궸臣讖ꓧ閁苣ꚁ臣讂胣㲂牢ਾ䐼噉邀ꇨ銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㠸⼼㹡⼼䥄㹖ਊ䐼噉邀ꇨ銼볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㤸⼼㹡⼼䥄㹖ਊ䐼噉邀ꇨ銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰〹⼼㹡⼼䥄㹖ਊ뗦鎽臣鮾뗧દ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯隼胣㲑䐯噉ਾ†臣覂臣膀鳦龮雦设臣膀苣뎃苣뢂苣莃菣颃菣覃臣꺁苣뎃苣超胩랂苣蚃菣銂裥ꢔ臣ꚁ苣꾉臣芀룤ꎀ臣ꒂ菣꾂苣Ꞃ菣袃菣몂菣ꮁ苣뎃苣銂뻤ꚵ臣讂臣膂臣超胩랂苣蚃菣꾁胣ꆬ臣뢛뫤芏藧ꢡ臣몤臣貂臣蒁苣ꪂ菣릂菣ꦃ菣ꊂ믤릉꣨꺁飦내鯦궸臣讖ꓧ閁苣ꚁ臣讂胣㲂牢ਾ䐼噉邀ꇨ銼볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰ㄹ⼼㹡⼼䥄㹖ਊ볯ꖼ볯뎼諦鎡㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖 閁苣ꮁ胣겜ꇩ꾁胣ꒂ菣꾂苣Ꞃ菣袃菣ꪃ菣뾂臣超裥銂ꇨ蚁髩ꮁꯩꚺ臣認냥鎽菣ꒂ苣궃苣것苣袃菣ꆃ苣讃苣ꮃ諦鎡볯궼볯궼볯肊ꇨ覼苣ꦈ铧鞁臣节觨蒁胣붥臩ꪁ菣ꒂ苣궃苣것苣袃菣ꆃ苣讃苣ꮃ諦鎡臣膀곦꺁鯧銺迥ꞅꇨꮁꓧ閁苣ꚁ臣讂苣벃苣袃菣ꪃ苣꺻觧놨臣躘듧뢛룤ꮁ雩몤臣貂臣蒁苣芀戼㹲㰊䥄㹖胣ꢡ볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤲㰲愯㰾䐯噉ਾ㰊䥄㹖胣ꢡ볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤲㰳愯㰾䐯噉ਾꦼ볯肊ꇨઓ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯颼胣㲑䐯噉ਾ†臣覂臣膀鳦颡臣膀곦꺁鯧銺迥ꞅꇨꮁꓧ閁苣ꚁ臣讂苣벃苣袃菣ꪃ苣꺻觧놨臣躘듧뢛룤ꮁ雩몤臣貂臣蒁苣袂臣ꪁ뷤蒁跦ꚁ苣ꆃ菣랂苣蚃菣銂裥ꢔ臣讂苣蚁臣鞁臣节觨蒁胣㲂牢ਾ䐼噉邀ꇨ銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㐹⼼㹡⼼䥄㹖ਊ菣莃菣ꮂ菣覃諦鎡㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖 閁苣ꮁ胣겜ꇩ꾁胣ꆬ臣뢛뫤芏藧ꢡ臣몤臣貂臣蒁苣ꪂ菣릂菣ꦃ菣ꊂ믤릉꣨꺁飦내鯦궸臣讖ꓧ閁苣ꚁ臣讂苣蚁臣螃菣뾂藩ꆿ苣릂菣ꂃ苣뾽铧馁苣袂臣ꮁ臣ꚁ苣꾉臣芀戼㹲㰊䥄㹖胣ꢡ볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤲㰵愯㰾䐯噉ਾꊂ菣袃苣ꂃ諦鎡㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖 閁苣ꮁ胣겜ꇩ꾁胣ꆬ臣뢛뫤芏藧ꢡ臣몤臣貂臣蒁苣ꪂ菣릂菣ꦃ菣ꊂ믤릉꣨꺁飦내鯦궸臣讖ꓧ閁苣ꚁ臣讂苣벃菣ꮂ菣讞ꏨ꺽臣袂臣ꪁ苣ꆃ菣ꢁ菣벃苣ꚇ郧肊ꇨ銂뷤ꢔ臣讂苣蚁臣鞁臣节觨蒁胣㲂牢ਾ䐼噉邀ꇨ銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㘹⼼㹡⼼䥄㹖ਊ䐼噉邀ꇨ銼볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㜹⼼㹡⼼䥄㹖ਊ䐼噉邀ꇨ銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㠹⼼㹡⼼䥄㹖ਊ⼼䥄㹖㰊䥄㹖䐼噉邀볯馼볯醼胣㲑䐯噉ਾ†뷥궥胨ꮁ臣ꎁ臣膀觧骮臣龮雦设臣몤臣貂臣겜駧躘臣뺯臣ꚁ胣莺꿧ꮁ뿨릁苣貂臣몙飦꺁꿧늛迥뎁닧麥臣覂鯩놄臣讂臣ꢁ臣辁ꓥ颧臣覤뷥蒂ꓥ뒛苣ꂊ臣讂臣ꢁ臣꾏菨ꞁ臣讂胣겜껥붖뻤꾁胣鎾臣ꚁ뻤隤髧ꪁ苣꺁臣芁苣膀裥邙髧ꪁ苣꺁臣꾁臣蒁苣꺁臣芁苣蚂苣ꊝ臣莀藦馁臣趁臣芁苣芀㰊䐯噉ਾ䐼噉㰾䥄㹖胣뎛鷩꺁냧颍臣겪飦醀⼼䥄㹖㰊䥄㹖胣醼볯銼볯醀⼼䥄㹖㰊䥄㹖胣뎛볯醀ꗥꦁ臣龮雦设臣袂臣ꚁ꟦邈臣貂臣ꊂ菣袃苣ꂃꏨ꺽臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醀룤膦臣ꊂ菣袃苣ꂃ鯩邭苣뎃菣벃菣뎃菣꺁ꛦꖕ菣궃菣꾂鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼胣ꊂ菣袃苣ꂃ룤꺤菣궃苣莃苣꺁ꛦꖕ菣궃菣꾂鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯膽볯醀볯겼볯랼菣꾂菣ꮃ菣궃苣莃苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼胣ꚇ郧ꚃ菣莃菣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥閼胣ꆼ볯떼볯颼볯꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼胣ꖅ諥隃菣莃苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鞼胣몇諥隃菣莃苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥颼胣것苣릂苣隃菣莃苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥馼胣꾂菣릂菣벃볯꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀苣궃苣邃菣銼臣뎩듧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣궪臣몇臣鞃菣뮂苣隃菣莃苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀ꫨ뾁蟥鞁菣궃苣릂菣궃菣꾂臣뎩듧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣邃菣ꮃ苣閃苣隃菣莃苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀苣肃菣込菣뢂菣꾂菣궃菣꾂臣뎩듧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼胣鞹껧隃菣莃苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀볯込볯ꊂ菣것苣龔裦ꢙ臣뎩듧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣뮔듧蒓ꧧ閃苣벃菣莃菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀ꃩꆬꫨ뾁蟥鞁苣뾂菣벃苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀菣莃苣릂ꫨ뾁蟥鞁苣뾂菣벃苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀菣莃苣릂鯦趁뻨뾁苣뾂菣벃苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀黥뒛苣袃菣莃菣궪臣몇臣込鯦趁뻨뾁苣뾂菣벃苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀黥뒛苣袃菣莃菣궪臣몇臣込鯦趁뻨뾁苣뾂菣벃苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀苣벃苣뎃苣ꎃ菣龔裦鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀苣벃苣뎃苣ꎃ菣龔裦鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀黥뒛苣袃菣莃菣龔裦鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀黥뒛苣袃菣莃菣龔裦鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀铧ꂴ菣벃苣讧胩꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀铧ꂴ蟥蚐菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣ꢡꓧ뎂菣袃菣벃菣꺁ꛦꖕ菣궃菣꾂鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀볯ꎼ볯较럧邈臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣隫郧蒚铧较铧꺁鏨趩菣ꦂ菣麃菣袃臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣薆菩뮔菥ꆃ菣ꪃ菣蒓ꧧ閃苣벃菣莃菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀铧较菣ꦃ菣莃菣蒓ꧧ閃苣벃菣莃菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀苣벃菣ꮂ菣覃苣떂菣鞃菣뎃苣馁苣鞃菣뮂苣꺁駦뮳裥꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀苣벃菣벃苣뎃菣ꪃ菣낂菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼胣麛믨鞁臣ꊂ菣袃苣벃菣銂ꫨ뾁迥讂菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣ꊂ菣袃苣벃菣銂뻥랏賥馁苣龁苣ꮁ뿥膦臣릂菣莃菣꺁菣궃菣膃菣벃菣ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀跥肸臣ꊂ菣袃苣벃菣꺁럥薚臣ꆋꓥ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣鲤蟥ꢔ臣颍룤뾂菣늂菣袃臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼胣뾂菣늂菣袃苣鲤蟥馁苣龁苣뾽铧閁苣讂雦閳臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣貺臣꺁苣벃苣莃菣鎖臣鶷鯩銂꣨鞮臣讂雦閳臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣趇뿥覃菣閃菣꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣趇뿥ꮃ菣꾂苣莃菣蚃菣隃菣꺁룤ꊽ藦銂ꓧ馁鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼볯醀蟩莿鯦낖菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼胣붥臩ꪁ껥붖뻤ꮁ臣蒁臣ꦈ铧閁苣讂菣ꮃ苣ꚇ郧ꢔ菣莃苣ꊂ菣鞃菣벃菣ꮃ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼胣ꊂ菣袃苣벃菣꺁苣꾂菣뎃菣ꮃ苣ꎧ駩馁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼볯醀菣莃菣꺁돧鞈臣ꆋꓥ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼胣覃菣袃苣벃菣꺁菣벃苣ꊝ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣颍룤螃菣뾂菣궃菣꾂臣芦闧겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼胣颍룤螃菣뾂菣궃菣꾂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣뎛볯邼臣螃菣뾂菣궃菣꾂臣ꢃ裥ꆋꓥ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣뎛볯邼臣螃菣뾂菣궃菣꾂臣ꢃ裥ꆋꓥ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣颍룤뾂菣늂菣袃꟦ꂀ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼胣螃菣뾂菣궃菣꾂臣뾂菣늂菣袃꟦ꂀ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼胣螃菣뾂ꃩ龟臣鲃菣肃菣꾂菣莃苣ꢔꃩ龟臣뺯臣讂苣벃苣莃菣꺁뷤꺽雩芿臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼胣螃菣뾂菣궃菣꾂臣ꪂ菣ꢂ菣蚃菣랂菣뎃苣ꦃ菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥閼볯醀菣벃苣隃菣莃苣꺁菣莃菣꺁苣것苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥閼볯醀菣벃菣뮃苣궃菣뎃곧랏賥꺁菣벃苣꺁꟦ꂀ臣芦闧겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣设ꓧ蒚臣ꪃ菣覃菣붂菣ꊃ菣ꚬ迥隌菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼胣ꪃ菣覃菣붂菣ꊃ菣ꚬ迥隌菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣螃菣뾂菣궃菣꾂蛥꺁곧랏賥閁苣龁菣벃苣꺁菣ꒂ苣Ꚃ菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀믤뾛髧ꪁ苣벃菣ꮂ菣覃苣떂菣鞃菣뎃苣馁苣鮚臣떂菣鞃菣뎃苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀鯥ꊻ臣龁믤뾛髧ꪁ苣벃菣ꮂ菣覃苣떂菣鞃菣뎃苣馁苣肸뻤꺁详Ꞥ鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀苣궂菣讃菣낂菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼胣릂苣ꎃ菣뎃苣鞃菣뮂苣꺁뗨鎁苣鞾苣릂苣ꎃ菣뎃苣蚈룥꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀苣뎃菣ꮃꫨ誂臣ꪃ菣覃菣붂菣ꊃ菣隃菣莃苣꒪苣꺁ꋧ螎臣鎖臣ꊖ뿤銂ꓧ馁鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀뻥랏賥鞃菣뮂苣꺁菣궃菣膃菣벃菣ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀뻥랏賥鞃菣뮂苣꺁菣궃苣릂꣧趃鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀뻥랏賥ꮁ臣醁苣螃菣뾂菣궃菣릂菣莃菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鞼볯醀ꫨ뾁蟥鞁菣궃苣릂臣뎩듧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣ꎻ鯦蒚臣ꊂ菣袃苣벃菣꺁雩讧苣鲤蟥馁苣鞃菣뮂苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鞼볯醀菣莃菣螃菣뾂諦몇菣궃苣릂臣뎩듧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣ꦾ迥隌菣궃苣릂臣ꦈ铧閁苣讂苣낂菣뎃菣벃苣ꞃ菣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鞼볯醀苣벃苣莃菣銂ꛨꒁ臣讂뻥랏賥鞃菣뮂苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鞼볯醀苣벃苣莃菣銂ꛨꒁ臣讂髩ꮁ裥ꢔ臣貂苣螃菣뾂꟦ꂀ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼胣겼뷯躽뷯辽뷯鎼雩낕꟦ꂀ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣꾂菣莃苣麃菣꾂迥뎁菣벃菣벃ꃩ龟苣몤臣螃菣뾂菣궃菣꾂臣ꢃ裥ꆋꓥ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼胣鎃菣袃苣ꆃ菣뢂苣ꦾ迥隌臣讂髩꺁蟥蚐苣蚃菣鞃臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣鎃菣袃苣ꆃ菣뢂苣ꦾ迥隌臣讂髩꺁菣벃苣閃菣벃苣蚃菣鞃臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼胣붥臩ꪁ껥붖뻤꺁苣꾂菣뎃菣ꮃ꟨꒙菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣뎂菣鲃菣邃臣肸껥붖뷥讅臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣뎂菣鲃菣隃菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣뎂菣鶃苣莃菣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥颼볯醀胩뢸臣뎂菣鶃苣莃菣鞃菣뮂苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥颼볯醀菣벃菣麃菣鞃苣뾽铧馁苣꾃菣鞃菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼胣꾃菣鞃菣ꒂ菣讃苣鲣雩鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥颼볯醀苣醃菣袨껧꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼胣몟鳦릂菣뎃꣨鞮菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣릂菣뎃꣨鞮菣궃苣릂臣뎩듧ꪁ룤龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥馼볯醀铧较菣ꦃ菣莃菣것菣ꮃ苣궪臣随苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥馼볯醀菣ꒂ菣讃苣鲣雩꺁臣膂菣ꦃ菣莃菣蚃菣隃菣銂뷤ꢔ臣讂雦閳臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣銃苣袃苣ꦃ菣躏鯩鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥馼볯醀觨覤迦鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥馼볯醀觨覤迦鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥馼볯醀觨목雩覤迦鞃菣뮂苣꺁ꧨ내鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥馼볯醀藥鮊뫥馨苣袨껧馁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥馼볯醀菣ꎂ菣覃菣莃苣颻臣뎂菣鶃苣莃菣ꚇ郧馁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥馼볯醀뇦ꢔ苣놂菣ꪃ菣낂菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣뢼苣놂菣ꪃ菣낂菣궃苣릂臣誁臣讂苣놂菣ꮃ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀볯릂苣벃菣뎃苣鞃菣뮂苣ꮁ臣醁苣릂苣벃菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醼胣ꊃ苣ꒂ苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯銼胣떂菣钃苣뮂菣뮧该鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鎼胣뎂菣鶃苣莃菣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯钼胣閃苣벃菣邃菣꾂믤趁臣뎂菣鶃苣莃菣馁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯閼胣ꖅ諥뮔菥讁苣꺁觨ꞁ苣ꒂ菣벲苣馁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯隼胣閃苣벃菣邃菣꾂믤趁臣뾂苣ꮃ단誂臣讂菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀菣꾂苣膃菣꺽迦ꞁ苣ꒂ菣벲苣馁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯颼胣ꖅ諥뮔菥讁苣꺁觨ꞁ苣ꒂ菣벲苣馁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯颼胣ꖅ諥뮔菥讁苣꺁觨ꞁ苣ꒂ菣벲苣馁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯馼胣閃苣벃菣邃菣꾂蓧鞁臣蚃苣릂菣ꎃ苣躸臣讂菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀菣ꎂ菣覃菣莃苣颻臣ꞁ菣꾂苣膃菣銂룤袁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醼胣ꎼ볯꒼铧ꂴ臣麛믨꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀럧늉苣隃菣꾂苣ꮃ臣鲣雩꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀鷩늉苣隃菣꾂苣ꮃ臣鲣雩꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀뗨늉苣隃菣꾂苣ꮃ臣鲣雩꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀ꗥ낕铧ꂴꇨꮁ꿥鞁볯ꚺ鯥ꊻ臣ꎼ볯꒼铧ꂴꏨ鎖臣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯隼胣뚁闦뮔듧財臣뺯臣邼뫥麛믨꺁볯ꎼ볯뮔듧鲣雩꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀볯膽뷯늉ꧧ鎖臣꺁觨覤迦꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀볯込裢뢼臣袨껧꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀볯込裢뢼臣袨껧꺁껥붖뻤꺁ꧨ내ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯邼胣邃菣鞃菣莃菣ꮁ苣讂돦骷꣨鞮臣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醼胣邃菣鞃菣莃菣ꮁ苣讂藧ꚺ꣨鞮臣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯銼胣邃菣鞃菣莃菣ꮁ苣讂藧ꚺ꣨鞮臣鞃菣뮂苣꺁ꧨ내ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鎼胣螌郥Ꞁ菣ꒂ菣銂뷤ꢔ臣讂볯꺁꣨鞮臣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯钼胣ꪂ菣讃菣ꒂ菣誏臣릂菣莃菣ꦃ苣袃苣뾽铧馁苣겼臣袨껧꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀苣ꂃ菣ꦃ苣袃迥뎁苣鶃菣袃菣ꒂ菣銂뷤ꢔ臣讂볯꺁꣨鞮臣肸껥붖뷥讅臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀볯躼볯薆ꧧ銂꣨鞮臣讂菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀볯躼볯薆ꧧ銂꣨鞮臣讂菣궃苣릂臣뎩듧겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀볯躼볯薆ꧧ銂꣨鞮臣讂菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀볯躼볯薆ꧧ銂꣨鞮臣讂菣궃苣릂臣뎩듧겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀룦낡꣨鞮臣ꖅ諥誏臣몇諥꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醼胣鮸ꇨ袨껧꺁껥鮚臣龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯銼胣蚆賩閃苣꾂苣꺁苣ꦃ菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鎼胣認뷥袨껧꺁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀跥놽꣨鞮臣ꦈ铧閁苣讂꟨꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯閼胣認뷥袨껧뢁臣ꖅ諥誏臣몇諥꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯隼胣認뷥袨껧꺁껥鮚臣龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鞼胣ꢑ뻨覅꣨鞮臣꺁藥鮊迥뎁蟥鮊臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀釥몾藥袨껧꺁껥鮚臣龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯馼胣ꎕ藥袨껧꺁껥鮚臣龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯邼胣ꎕ藥袨껧뢁臣ꖅ諥誏臣몇諥꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醼胣ꎕ藥袨껧꺁껥鮚臣龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯銼胣趏냥袨껧뢁臣ꖅ諥誏臣몇諥꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鎼胣趏냥袨껧꺁껥鮚臣龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯钼胣趏냥袨껧뢁臣ꖅ諥誏臣몇諥꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯閼胣趏냥袨껧꺁껥鮚臣龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯隼胣ꢑ뻨覅臣醁臣겋꣨鞮臣龮髩꺁껥붖뷥讅臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀藥袨껧꺁菣궃苣릂ꛦ膦臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀跥肸蓧邙藥邺铧꺁藧躘꣨鞮臣肸뻤꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯馼胣邃菣鞃菣莃菣銂铧蒁臣蒁苣ꂃ菣覅뫦ꢔ臣ꞅ飦袨껧꺁룤设臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀菣뎃菣麃菣鞃苣ꢔ臣讂苣ꂃ菣覅뫦ꢔ臣ꞅ飦袨껧꺁룤设臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀菣뎃菣麃菣鞃苣ꢔ臣ꪁ臣릂菣莃菣ꦃ苣袃藥邺铧꺁藧躘꣨鞮臣肸뻤꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯銼胣ꊖ胩鞁臣邃菣鞃菣莃菣銂铧蒁臣뮔菥ꮁ跥肸苣鶃菣袃菣ꒂ菣銂뷥ꚁ苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鎼胣颍룤鞃菣뎃菣颃菣覃臣隫郧蒚菣ꒂ苣Ꚃ菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯钼胣鞃菣뎃菣颃菣覃苣뎃苣閃苣벃苣꺁꟦ꂀ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀볯膽뷯뮔菥꺁鯥ꊻ臣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯隼胣낍裥뮔菥꺁铧ꂴ臣閃苣벃菣莃菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鞼胣螃苣뚂菣뎃苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯颼胣颼菣莃菣覃菣袃蟥鮊苣龔裦馁苣鞃菣뮂苣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯馼胣ꮂ菣覃菣벃菣벃臣鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀苣벃菣ꪃ菣肃菣꺁뇥讖雦隦鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醼胣ꊂ菣袃苣벃菣ꪃ菣肃菣꺁苣궃菣몂苣莃菣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀菣ꪃ菣袃菣벃菣誏臣鞃菣뎃菣颃菣覃臣鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀菣ꪃ菣袃菣벃菣꺁곧醼臣閱雩鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀菣ꪃ菣袃菣벃菣꺁곧銼臣閱雩鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀菣ꪃ菣袃菣벃菣趪꣨膃菣鞃臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀菣ꪃ菣袃菣벃菣趪꣨膃菣鞃臣ꆋꓥ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀룤떮髩趪꣨膃菣鞃菣벃苣鞃菣袃苣ꮃ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀뫤떮髩趪꣨膃菣鞃菣벃苣鞃菣袃苣ꮃ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀곧醼臣鞃菣벂菣릂苣뎃菣벃菣궃菣뎂菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯邼胣견볯꺁菣것苣뎃苣ꪂ菣ꪃ菣鞃菣袃苣ꮃ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀곧鎼臣螃菣뾂菣궃菣뎂菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯銼胣견볯꺁菣벃苣鞃菣袃苣ꮃ臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀鳦랕鳦鎖볯ꚼ볯늼臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀苣궃菣꾂裥邙菣ꎂ菣뾂菣꺁ꛦꖕ菣궃菣꾂鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯閼胣뾂菣醃菣鲤蟥ꦃ苣뎃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀觧Ꞥ臣躽볯꾼볯袃菣뎃苣릂苣꺁ꛦꖕ菣궃菣꾂鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鞼胣뾂菣醃菣鲤蟥ꦃ苣뎃臣覂臣骤闦꺁볯꾼볯꺁迥誂蟥鞁苣겪飦馁苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀苣뎃菣벃菣ꒂ菣貁菣ꒂ苣몙铧麛럨銂ꛨ蚁諧讅臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀胩뢸臣ꚼ볯뒼臣龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯邼胣붥臩ꪁ껥붖뻤꺁뿤ꎭ臣貂臣ꚼ볯뒼臣龮雦ꊽ藦꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醼胣趪꣨膃菣鞃臣ꖕ菣궃菣꾂臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀菣ꊃ菣麃菣鞃臣肸뻤꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鎼胣骮闦ꆃ菣ꪃ菣莃菣꺁룤设臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀볯ꆼ볯ꆃ菣ꪃ菣莃菣꺁룤设臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀菣ꦃ菣랂菣ꆃ菣ꪃꓥ낕菣ꊃ菣麃菣鞃臣肸뻤꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯隼胣閃菣莃苣ꖃ菣ꊃ菣鞃菣낂菣ꂃ菣ꊃ菣麃菣鞃臣肸뻤꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯鞼胣뚊藦龩ꋦ꺁苣뎃菣벃菣뎃菣鎖臣螃菣뾂菣궃菣誏臣ꊖ뿤銂ꓧ馁鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯颼胣ꦼ볯꾼菣讃菣袃臣뎂菣鶃菣趃菣袃雩꺁菣벃苣閃菣벃迥뎁雩芿苣몤臣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀껧鎡ꯨ蚐菣讃菣袃볯ꆼ볯떼볯꺁ꛦꖕ菣궃菣꾂鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯邼胣늼볯겼菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀볯겼볯꺁볯꾼볯隃菣莃苣꺁ꛦꖕ菣궃菣꾂鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯銼胣鞃菣낂菣ꂃ苣Ꚃ菣뾂菣讃菣袃臣隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀菣ꊃ菣벃菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀苣覃菣릂铧邈菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀볯뎼볯Ꞽ볯꺼菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀볯뎼볯Ꞽ볯꺼菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀볯ꊼ볯Ꞽ볯꺼菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀볯꒼볯Ꞽ볯꺼菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀볯낼볯Ꞽ볯꺼菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀볯ꆼ볯Ꞽ볯꺼菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀볯겼볯Ꞽ볯꺼菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀볯ꦼ볯Ꞽ볯꺼菣讃菣袃臣芦闧隃菣莃苣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀菣ꪃ菣袃菣벃菣趪꣨膃菣鞃臣風蛦閁苣龁菦놠苣몤臣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀苣벃菣ꮂ菣趪꣨膃菣鞃蛥ꮁ꣨뚆臣貂臣螃菣뾂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀菣ꪃ菣袃菣莃菣醃菣릂觧뒾믤醁菣궃苣릂臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀菣ꪃ菣袃菣莃菣ꒂ菣꾂뻤ꚵꧦ讧臣ꆋꓥ궖鷩鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀苣뎃苣颃菣覃뻤ꚵ菣讃菣袃臣閺鷩鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀苣뎃苣颃菣覃뻤ꚵ菣讃菣袃臣閺鷩뒁臣궖鷩뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀苣뎃苣颃菣覃뻤ꚵ菣讃菣袃臣誸鷩鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀苣뎃苣颃菣覃뻤ꚵ菣讃菣袃臣誸鷩뒁臣궖鷩뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀菣ꪃ菣袃菣莃菣꺁룤ꢃ裥꺁雦隦鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯銼胣鞃菣뎃菣颃菣覃菣讃菣袃臣ꆋꓥ鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀苣벃菣ꮂ菣ꮂ菣ꦃ臣薆菩꺁룤ꊝ臥꺁雦隦鯥ꞁ臣誂胣뎹苣ꮁ臣貂臣ꢃ鏥貁ꓧ閁苣ꚁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯钼胣ꊂ菣袃苣ꂃ苣ꆃ菣꺁蛥ꢃ臣閺鷩뒁臣鲖ꛨ뎛臣芁苣膀맥覂臣閁苣龁菩膓臣몤臣貂臣蒁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀苣벃菣ꮂ菣ꮂ菣ꦃ臣薆菩꺁곧醼臣誸鷩뒁臣鲖ꛨ뎛臣芁苣膀苣벃菣ꮂ菣ꮁ迥릮臣貂臣ꢃ鏥貁ꓧ閁苣ꚁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯隼胣ꊂ菣袃苣ꂃ苣ꆃ菣꺁蛥ꢃ臣견볯꺁룤ꊝ臥꺁雦隦鯥ꞁ臣誂胣ꊂ菣袃苣ꂃ臣躏껥閁苣龁菩膓臣몤臣貂臣蒁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀苣벃菣ꮂ菣ꮂ菣ꦃ臣薆菩꺁곧銼臣誸鷩뒁臣鲖ꛨ뎛臣芁苣膀苣벃菣ꮂ菣ꮁ迥릮臣貂臣ꢃ鏥貁ꓧ閁苣ꚁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯颼胣覑鯦鞃菣뎃菣궃菣ꮃ臣辣鯦趁菩蚈臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀铧较跥랈뻥꺁釨뢛菣ꪃ菣袃菣벃菣꺁꿥鲿臣龁ꇨ뮔菥꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯邼胣ꞡ껥貁돨ꖅ臣趁苣뚊藦꺁菣ꪃ菣袃菣벃菣꺁뷥讅臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀苣벃菣ꮂ菣ꊂ菣ꪃ苣벃苣ꞃ菣ꢅ뷤꺁苣閃菣Ꚃ苣ꊂ볯较菣覃苣Ꞃ苣ꊃ苣ꖃ菣ꮃ臣것苣ꊂ苣袃臣겪飦뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀苣ꆃ菣麃菣벃苣ꎃ臣붂菣袃苣Ꞃ苣込菣벃菣Ꚃ苣ꊂ菣뢂菣벃菣꺁菣ꒂ苣Ꚃ菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯鎼胣뮔菥ꚇ郧麃菣벃苣ꎃ臣붂菣袃苣Ꞃ苣込菣벃菣Ꚃ苣ꊂ菣뢂菣벃菣꺁菣ꒂ苣Ꚃ菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯钼胣鞃菣뎃苣麃菣벃苣ꎃ臣붂菣袃苣Ꞃ苣込菣벃菣Ꚃ苣ꊂ菣뢂菣벃菣꺁菣ꒂ苣Ꚃ菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯閼胣뮔菥ꚇ郧麃菣벃苣ꎃ臣붂菣袃苣Ꞃ苣込菣벃菣Ꚃ苣ꊂ菣뢂菣벃菣꺁菣ꒂ苣Ꚃ菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯隼胣閃苣ꒂ菣麃菣벃苣ꎃ臣붂菣袃苣Ꞃ苣込菣벃菣Ꚃ苣ꊂ菣뢂菣벃菣꺁菣ꒂ苣Ꚃ菣꺁ꫨ躘鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯鞼胣ꎻ鯦蒚臣ꊽ藦꺁菣ꪃ菣袃菣벃菣꺁菩蚈雦ꊝ雦隦鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯颼胣뎛볯銼볯꺁菣ꪃ菣袃菣벃菣꺁럥뒁臣ꆋꓥ鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀跥肸菣ꪃ菣袃菣벃菣꺁迥뒁臣ꆋꓥ鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀菣ꪃ菣袃菣벃菣꺁苣ꊂ菩蚈臣ꢃ裥궖鷩ꆋꓥ鲖ꛨ뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀菣ꪃ菣袃菣벃菣꺁苣ꊂ菩蚈臣견볯꺁详Ꞥ雦隦鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯銼胣颀볯覽뷯莽뷯銽뷯馀臣ꎭ鷩뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀臣覂臣讂铦꾉臣鎾臣ꚁ꟦邈臣貂臣ꮂ菣ꦃ苣릂菣ꂃ苣芦闧蒚臣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀蟥鮊菣螃苣ꊂ臣ꢡ鷩ꢁꏨꊝ臣낍裥銂臣讂臣膂臣鞃菣뎃苣벃ꏨ꺽苣芦闧蒚臣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀蛥龜臣辣鷩ꮁ臣醁苣몇諥螃菣뾂臣ꊽ볥銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯隼胣몇諥ꆃ菣ꎂ苣꺁详Ꞥ臣貂臣ꢃ裥銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯鞼胣馆鳧꺁ꏨꊝ臣覂菣벃苣銂ꫨ뾁뻨肂臣膂臣뾽铧閁苣讂ꫨ뾁迥誂ꏨ꺽苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀臣覂臣讂铦꾉臣薣뷧꺁裥ꢔ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀铧较臣醐臣꺁藥鎽髧ꪁ蟥蚐臣芦闧蒚臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀臣覂臣讂铦꾉臣鎾臣ꚁ꟦邈臣貂臣ꮂ菣ꦃ苣뾽铧鞁臣뒠郥꺁铧较臣릉鳦꺁諥鲞苣鲽苣릖돦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯醼胣閁苣ꪁ苣릔觨ꮁ뻥ꎁ臣鞃菣뎃菣궃菣ꮃ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀臣覂臣릔觨閁苣龁껥붖뻤꺁雦閳苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀臣覂臣讂铦꾉臣趓뷤릖돦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯钼胣閁苣ꪁ苣릔觨ꮁ뻥ꎁ臣뮔菥ꚇ郧꺁룤ꊽ藦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯閼胣閁苣ꪁ苣릔觨꺁鏦鲽雦閳苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀铧较臣궂菣鞃菣ꎃ菣誏臣몇諥꺁菣궃苣릂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀뗨꺛駩뮎臣鞃菣뮂苣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯颼胣馨뫦蒚臣ꊂ菣袃苣ꂃꏨ꺽臣鎾臣ꚁ꟦邈臣貂臣馆鳧낍裥ꢷ裦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯馼胣閁苣ꪁ苣릔觨ꮁ뻥ꎁ臣讧裦閁苣龁菣ꖃ苣ꮃ菣ꪃ菣袃菣莃菣ꢷ裦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯邼胣閁苣ꪁ苣릔觨꺁苣벃菣꒙軥薣뷧銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯醼胣讫뷤馆鳧뮔菥銂ꛨ讂菣궃苣릂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀ꯧ鎽蛥龜諥鲞苣鲽裦馁苣龁苣ꮁ꣨袨臣貂臣膀臣覂臣讂铦蒖臣것菣몂苣릂菣ꂃ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀ꯧ鎽蛥龜铧较臣떉胩銂ꓧ馁菩蚈雦隦鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯钼胣閁苣ꪁ苣릔觨ꮁ뻥ꎁ臣讫뷤馆鳧뮔菥銂뷤讂臣膂臣薣뷧銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯閼胣뎛볯閼볯꺁뷤꺽뇦膂菣讃菣袃苣閁苣ꮁꧨ내臣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀ꯧ鎽蛥龜铧较臣鲽裦ꮁꗥꦁ臣ꮂ菣ꦃꏨ꺽苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀ꯧ鎽蛥龜諥鲞苣릔觨馁臣辁胣趸胩躘臣辣뷥ꚁ苣뾽铧馁苣鞃菣뮂苣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯颼胣鞃菣뎃菣ꆃ菣ꎂ苣ꮁ铧较苣龔裦馁苣릖돦銂ꛦꖕ髧ꮁꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯馼胣겜駧躘臣鎾臣ꚁ꟦邈臣貂臣鞃菣뎃菣ꆃ菣ꎂ苣꺁꟦ꂀ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀臣覂臣讂铦꾉臣鎾臣ꚁ꟦邈臣貂臣鞃菣뎃菣ꆃ菣ꎂ苣꺁裥ꢔ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀臣覂臣讂铦꾉臣鎾臣龁菣ꪃ菣袃菣螃苣ꊂ臣讧胩꺁곧醼뷥讅苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀鳦몙飦ꮁ뻥ꎁ臣鞃菣뎃菣ꆃ菣ꎂ苣꺁꟦ꂀ臣閁苣ꪁ苣ꊽ藦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯鎼胣겜駧躘臣鎾臣龁菣ꪃ菣袃菣螃苣ꊂ臣讧胩꺁臣覂臣讂뷥讅臣芦闧蒚臣궖鷩뎛苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀鳦몙飦ꮁ뻥ꎁ臣鞃菣뎃菣ꆃ菣ꎂ苣꺁꟦ꂀ臣閁苣ꪁ苣ꊽ藦꺁ꛦꖕ髧ꪁ雦ꊝ鯥銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯閼胣뎛볯隼볯誏臣鞼臣鎾臣龁菣ꪃ菣袃菣螃苣ꊂ꟦邈臣붣胩꺁룤ꊽ藦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯隼胣뎛볯隼볯꺁럧邈苣ꦈ铧馁苣龁苣ꮁ맧궶鷦首苣벊臣몇臣鎁臣ꮁ苣讂ꏨꂀ臣ꖈ臣ꊽ藦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯鞼胣閁苣ꪁ苣릔觨꺁룤膦苣蚃菣鞃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀臣覂臣讂铦꾉臣ꚁ뷤ꢔ臣貂苣뎼뷯芽뷯貽菣ꎂ菣뾂菣꺁諥鲞苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀臣覂臣讂铦꾉臣ꚁ뷤ꢔ臣貂苣늛럧꺁苣閃苣莃菣릖돦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯邼胣閁苣ꪁ苣릔觨ꮁ臣뾽铧閁苣讂鯦骷臣ꪂ菣뮂菣袃雦閳苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀ꫨ颭臣貂臣钡苣ꮐ苣馨뫦蒚臣뮔菥銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯銼胣袈釥꺁ꃩ龟苣몱껥馁苣龁苣꺁곧醼臣閃菣벃菣ꎃ菣袃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀裨뎑臣颠鿥銂뇦骮臣讂臣膂臣견볯꺁菣궃菣膃菣벃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯钼胣뮔菥銂苣ꒂ菣뎃苣馁苣肜裥꺁럥讨苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀铧较臣뾂苣ꪃ菣낂臣龁苣꺁裥꺁苣ꒂ菣醃苣벃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯隼胣뾂苣ꮃ臣趸胩躘臣麃苣꾂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀鯥銼볯隼臣뾂苣ꮃ臣龁苣꺁胣뺯뿥馁苣ꢡ鷩蚃苣릂菣ꎃꯩ閁苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀鯥銼볯隼臣뾂苣ꮃ臣龁苣꺁胣뺯뿥馁苣ꢡ鷩蚃苣릂菣ꎃꯩ閁苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀铧较苣꺿귦馁苣龁苣ꮁ汧扯污灯捡杩祴苣뾽铧馁苣ꖷ꣧銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯邼胣龮髩꺁菣ꒂ菣袃苣랷郥閁臣讂諥鲞苣龜볤讂臣膂臣膀苣袃菣벃苣뎃苣릊黦銂뿤ꎭ臣讂雦閳苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀菣ꦃ菣랂菣릂菣궃菣꾂臣蚃菣隃菣銂뷤邈臣讂럥讨苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀苣袃菣벃苣ꮂ菣벃菣것菣袃苣鲽裦馁苣ꖷ꣧銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯鎼胣邵黦ꢁ臣ꚁ뗨鎁苣骃苣뎃菣ꎂ菣낂럥讨苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀菣ꦃ菣랂菣릂菣궃菣꾂苣袐裦馁苣閁苣ꪁ苣龮雦设臣誁臣讂苣蚃菣鞃臣閃菣벃菣ꎃ菣袃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀菣뢂苣늛럧꺁賥蚈髧骷裥뢁臣覤迦릖돦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯隼胣隃菣莃苣ꖃ苣袃菣벃苣鞃菣뮂苣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯鞼胣閁苣ꪁ苣龮雦设臣뾽铧閁苣讂胣붥臩ꪁ菣ꦃ菣랂菣릂苣뎃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯颼胣閁苣ꪁ苣릔觨꺁곧醼臣ꢷ裦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯馼胣閁苣ꪁ苣릔觨꺁鏦鲽臣閃菣벃菣ꎃ菣袃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀ꯩꎧ菥ꚺ臣낍裥閁苣龁铧较臣讧裦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯醼胣뎂菣벃苣鲽裦馁苣龁苣꺁胣뎛볯馼볯꺁铧较苣ꚇ郧馁苣龁苣꺁ꏨ꺽苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀散瑮潲摩臣ꚇ郧릂菣莃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯鎼胣肸胩꺁ꓦꖟ臣龁菣뾂菣뎃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀臣覂臣讂铦꾉臣龮雦꺁鯥銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯閼胣閁苣ꪁ苣릔觨銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯隼胣閁苣ꪁ苣龮雦设臣ꮂ菣覃ꫨ뾁迥誂ꏨ꺽苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀菣ꦃ苣뮃菣뎃菣麃菣鞃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀菣ꦃ苣뮃菣뎃菣麃菣鞃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀菨꾙苣ꎃ菣邃苣꺁菣뎃菣麃菣鞃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀菨꾙苣ꎃ菣邃苣꺁菣뎃菣麃菣鞃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀菣뎃菣麃菣鞃苣邵郥馁苣鞃菣뮂苣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯銼胣邃菣鞃菣莃菣銂뗧袐臣讂菣궃苣릂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀菣莃菣꺁菨꾙苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀臣覂臣讂铦꾉臣鎾臣ꚁ菣뎃菣麃菣鞃苣邵郥馁苣鞃菣뮂苣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯閼胣閁苣ꪁ苣릔觨ꮁ뻥ꎁ臣邃菣鞃菣莃菣銂뗧袐臣讂菣궃苣릂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀諨鎡髧ꪁ铧较臣龔裦꺁臣覂臣讂铦꾉臣릖돦ꮁ臣醁苣릂菣莃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯鞼胣肸臣꺁苣ꊃ菣袃苣견볯꺁苣ꊃ菣袃臣麃菣钃菣낂臣讂菣궃苣릂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀臣覂臣讂铦꾉臣肸껥붖뷥讅苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀苣ꊃ菣袃菣麃菣钃菣낂臣붥臣鞁臣ꊽ藦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯邼胣閁苣ꪁ苣릔雥ꮁ臣뾽铧閁苣讂苣ꊃ菣袃菣ꊃ菣閃苣뎃苣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醼胣ꊂ菣袃苣ꂃꏨ꺽臣몟鳦趓뷤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯銼胣閁苣ꪁ苣릔觨ꞁ뷤ꢔ臣貂苣肸胩꺁苣벃菣ꮂ菣覃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀臣覂臣讂铦꾉臣뾽铧閁苣讂苣ꮃ苣ꪃ苣ꂃ臣閃菣벃菣ꎃ菣袃鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯钼胣겜駧躘臣鎾臣ꚁ뷤邈臣貂苣膀跥랈臣貂臣莸臣몇諥꺁ꛦꖕ鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯閼胣閁苣ꪁ苣릔觨꺁軦骶雦込苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀菩蚈髧ꮁ雦ꊝ臣辏臣貂臣膀臣覂臣讂铦꾉臣鲖ꛨ뎛苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀鯦趁뻨뾁菣벃苣ꢂ菣ꊂ藩鞈苣覜臣讂苣벃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯颼胣邙껥閁苣龁闦꺁鯦趁뻨뾁菣벃苣颠鿥꺁臣銂鳦馁苣ꮂ菣覃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀菣벃苣颠鿥꺁꟦邈苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀苣벃苣莃菣讧裦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醼胣閁苣ꪁ苣릔觨꺁ꏨ꺽苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀鯥鎼볯醼苣醿臣蒁臣讦臣뚊藦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯鎼胣궪臣随苣薣뷧꺁룤ꮁ苣벃菣銂賦ꖅ臣讂菣궃苣릂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀苣벃菣銂迥誂蟥馁菣궃苣릂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀苣벃菣ꮁ菣벃苣颠鿥銂鯦辁菣궃苣릂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀苣벃菣ꪃ菣肃菣꺁꟦ꂀ臣芦闧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀臣覂臣讂铦蒖臣芦闧蒚臣超裥銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯颼胣閁苣ꪁ苣릔雥꺁苣뎃苣벃菣Ꞃ菣릂臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀臣覂臣讂铦蒖臣붂菣袃苣Ꞃ苣ꊃ苣ꖃ菣ꮃ臣讧裦꺁룤ꊽ藦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯邼胣ꊂ菣袃苣ꂃ苣릂菣ꂃ臣趓뷤꺁ꛦꖕ鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醼胣ꊂ菣袃苣ꂃ苣릂菣ꂃ臣覤뷥閁苣龁鏦鲽臣견볯꺁뻤貁ꓧ閁苣ꚁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯銼胣ꊂ菣袃苣ꂃ臣趓뷤銂ꓥ뒛臣讂菣钃菣ꎂ苣ꞃ菣ꮂ菣覃臣몤臣貂臣蒁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀苣벃菣ꮂ菣꺁鏦鲽苣覤鯦馁苣龁苣꺁苣벃菣ꮂ菣覃菣릂菣ꮂ菣覃臣몤臣貂臣蒁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀苣벃菣ꮂ菣薣뷧꺁蟥鮊菣릂菣邵黦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯閼胣閁苣ꪁ苣릔觨ꮁ뻥ꎁ臣讧裦閁苣龁苣ꆃ菣랂苣蚃菣銂ꛦꖕ髧ꮁꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯隼胣閁苣ꪁ苣릔觨꺁菣ꪃ菣뾂菣薣뷧誏臣늌鿩薣뷧銂ꛦꖕ髧ꮁꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯鞼胣馆鳧꺁ꏨꊝ臣膣냦꾸臣讧裦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯颼胣馆鳧꺁ꏨꊝ臣늌鿩閁苣龁菣벃苣銂ꫨ肂臣膂臣뾽铧閁苣讂ꫨ뾁迥誂ꏨ꺽苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀臣覂臣讂铦꾉臣薣뷧꺁뷤ꢔ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀苣벃菣ꮂ菣薣뷧꺁ꧦ붃菩蚈臣芦闧뎛苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀臣覂臣讂铦꾉苣뾽铧馁苣릂菣莃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯銼胣閁苣ꪁ苣릔觨ꮁ뻥ꎁ臣ꊂ菣袃苣ꂃꏨ꺽臣趓뷤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯鎼胣몇諥閁苣龁胢馆鳧鶀臣辣鷩ꮁ跥랈臣貂臣隻臣龮雦设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀臣覂臣讂껥붖뻤ꮁ뻥ꎁ臣讧裦閁苣龁菣ꪃ菣뾂菣薣뷧꺁蛥ꢃ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀臣覂臣讂껥붖뻤ꮁ뻥ꎁ臣讧裦閁苣龁菣莃菣꾃菣꾂藩莸苣릂菣ꂃ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀鯥鎼볯閼臣鞃菣뎃苣벃苣뎃菣ꖃ菣뾂臣趓뷤銂ꛦꖕ髧ꮁꓧ馁胣㲂䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀鯥醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㈰㤹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〳㰰愯㰾䐯噉ਾ䐼噉邀鯥鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㄰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯袼뷯覼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〳㰳愯㰾䐯噉ਾ䐼噉邀鯥閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〳㰵愯㰾䐯噉ਾ䐼噉邀鯥鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〳㰷愯㰾䐯噉ਾ䐼噉邀鯥馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㤰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰〱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰ㄱ⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㌱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㔱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㜱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㤱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰〲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰ㄲ⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㌲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㔲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㜲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㤲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰〳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰ㄳ⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㌳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㔳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㜳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㤳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰〴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰ㄴ⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㌴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㔴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㜴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㤴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰〵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰ㄵ⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㌵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㔵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㜵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㤵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰〶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰ㄶ⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㌶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㔶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㜶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㤶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰〷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰ㄷ⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㌷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㔷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㜷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㤷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰〸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰ㄸ⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㌸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㔸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㜸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㤸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰〹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰ㄹ⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㈹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㌹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㐹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㔹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㘹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㜹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㌰㠹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤳㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〴㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〴㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〴㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〴㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〴㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄴ㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄴ㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄴ㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄴ㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄴ㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈴㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈴㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈴㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈴㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈴㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌴㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌴㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌴㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌴㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌴㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐴㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐴㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐴㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐴㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐴㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔴㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔴㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔴㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔴㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔴㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘴㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘴㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘴㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘴㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘴㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜴㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜴㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜴㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜴㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜴㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠴㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠴㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠴㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠴㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠴㰹愯㰾䐯噉ਾ䐼噉邀鯥醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰〹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤴㰱愯㰾䐯噉ਾ䐼噉邀鯥醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㈹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤴㰳愯㰾䐯噉ਾ䐼噉邀鯥醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㐹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤴㰵愯㰾䐯噉ਾ䐼噉邀鯥醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㘹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤴㰷愯㰾䐯噉ਾ䐼噉邀鯥醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㐰㠹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤴㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〵㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〵㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〵㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〵㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〵㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄵ㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄵ㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄵ㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄵ㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄵ㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈵㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈵㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈵㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈵㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈵㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌵㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌵㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌵㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌵㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌵㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐵㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐵㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐵㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐵㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐵㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔵㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔵㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔵㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔵㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠵⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㔵㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘵㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘵㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘵㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘵㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠶⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㘵㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜵㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜵㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜵㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鞼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜵㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠷⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㜵㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠵㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠵㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠵㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠵㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠸⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㠵㰹愯㰾䐯噉ਾ䐼噉邀鯥銼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰〹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤵㰱愯㰾䐯噉ਾ䐼噉邀鯥銼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㈹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤵㰳愯㰾䐯噉ਾ䐼噉邀鯥銼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㐹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤵㰵愯㰾䐯噉ਾ䐼噉邀鯥銼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㘹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯馼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤵㰷愯㰾䐯噉ਾ䐼噉邀鯥銼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㔰㠹⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㤵㰹愯㰾䐯噉ਾ䐼噉邀鯥鎼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰〰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〶㰱愯㰾䐯噉ਾ䐼噉邀鯥鎼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㈰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〶㰳愯㰾䐯噉ਾ䐼噉邀鯥鎼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㐰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〶㰵愯㰾䐯噉ਾ䐼噉邀鯥鎼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㘰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯邼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〶㰷愯㰾䐯噉ਾ䐼噉邀鯥鎼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㠰⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰〶㰹愯㰾䐯噉ਾ䐼噉邀鯥鎼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰〱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄶ㰱愯㰾䐯噉ਾ䐼噉邀鯥鎼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㈱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄶ㰳愯㰾䐯噉ਾ䐼噉邀鯥鎼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㐱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄶ㰵愯㰾䐯噉ਾ䐼噉邀鯥鎼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㘱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄶ㰷愯㰾䐯噉ਾ䐼噉邀鯥鎼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㠱⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰ㄶ㰹愯㰾䐯噉ਾ䐼噉邀鯥鎼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰〲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈶㰱愯㰾䐯噉ਾ䐼噉邀鯥鎼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㈲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈶㰳愯㰾䐯噉ਾ䐼噉邀鯥鎼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㐲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈶㰵愯㰾䐯噉ਾ䐼噉邀鯥鎼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㘲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈶㰷愯㰾䐯噉ਾ䐼噉邀鯥鎼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㠲⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㈶㰹愯㰾䐯噉ਾ䐼噉邀鯥鎼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰〳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌶㰱愯㰾䐯噉ਾ䐼噉邀鯥鎼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㈳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌶㰳愯㰾䐯噉ਾ䐼噉邀鯥鎼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㐳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌶㰵愯㰾䐯噉ਾ䐼噉邀鯥鎼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㘳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌶㰷愯㰾䐯噉ਾ䐼噉邀鯥鎼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㠳⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㌶㰹愯㰾䐯噉ਾ䐼噉邀鯥鎼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰〴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐶㰱愯㰾䐯噉ਾ䐼噉邀鯥鎼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㈴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐶㰳愯㰾䐯噉ਾ䐼噉邀鯥鎼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〰㐰〳㤹㐵琮晩㸢〰㐰〳㤹㐵琮晩ꃂ〰㘰㐴⼼㹡⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦〢〰㌴㤰㔹⸴楴≦〾〰㌴㤰㔹⸴楴쉦゠〰㐶㰵愯㰾䐯噉ਾ⼼䥄㹖㰊戯摯㹹㰊栯浴㹬